Los 10 sitios más útiles para desarrolladores de Java
Fuente: Tarun Telang A continuación se muestra una lista de los recursos web más eficaces y confiables sobre la tecnología Java. Pueden resultar útiles tanto para programadores Java experimentados como para principiantes. He estado usando estos recursos durante años para encontrar la información más reciente sobre las tecnologías Java.
El recurso contiene información sobre casi todo lo que necesita saber sobre Java, incluidas noticias, artículos, blogs, materiales de referencia, opciones profesionales e información relacionada con proyectos Java. Recomiendo visitar este sitio periódicamente para estar al día con las últimas novedades sobre la plataforma Java.
No puede prescindir de este recurso si desea descargar e instalar la última versión del kit de desarrollo de Java. También contiene instrucciones detalladas sobre cómo ejecutar archivos de instalación de Java en varias plataformas.
Esta sección del sitio de Oracle contiene información de referencia sobre la API de Java SE. La documentación HTML se genera a partir del código fuente de Java utilizando la herramienta JavaDoc.
Existe una gran colección de tutoriales y materiales de referencia sobre el lenguaje de programación Java. Las lecciones también están disponibles en forma de libro, The Java Tutorial, Sixth Edition (en inglés). Puedes seguir este enlace para comprarlo en Amazon.
El sitio contiene pruebas de práctica y recursos útiles para aprender temas que van desde Java, bases de datos, Android hasta preparación para certificaciones. Este es un muy buen lugar para aprender Java mediante ejercicios prácticos.
Aquí puede encontrar proyectos relacionados con Java EE, así como proyectos previamente alojados en Java.net. Este sitio contiene muchos enlaces diferentes a proyectos con información adicional sobre ellos e información de contacto relacionada con estos proyectos.
Visite este sitio para seguir debates, preguntas y respuestas sobre tecnologías y marcos de Java. Javapedia.net es útil tanto para desarrolladores experimentados de Java y Java EE, como para principiantes y estudiantes que se preparan para entrevistas.
El sitio contiene información sobre las últimas tecnologías en Java Enterprise Edition. Este es un lugar donde los desarrolladores de Java discuten diversos temas relacionados con Java, Java EE, programación, software y tendencias en el desarrollo del lado del servidor. Esta es una comunidad en línea muy grande para arquitectos empresariales y desarrolladores de Java, donde puede encontrar noticias diarias, debates técnicos, seminarios web y otra información útil.
Este es el lugar donde puede encontrar el software Java más reciente (juegos, aplicaciones móviles y de escritorio). Este es un recurso legal y seguro para instalar complementos de Java. A diferencia de muchos otros sitios, no hay anuncios emergentes ni archivos de instalación dudosos que en realidad no estén relacionados con Java.
Aquí encontrará información actualizada sobre cómo Java respalda la innovación que impulsa nuestro mundo digital. El sitio contiene una colección de recursos sobre la plataforma Java para estudiantes, aficionados, desarrolladores y ejecutivos de empresas de TI. Aunque puede encontrar muchos sitios similares en Internet con enlaces a Java, la mayoría de ellos están desactualizados y muestran información relevante solo antes de Java 5. Desde Java 8, el lenguaje ha sufrido cambios importantes, lo que requiere que los desarrolladores adopten un nuevo enfoque para programación en Java. El lenguaje también está evolucionando muy rápidamente y cada seis meses se lanzan nuevas versiones de Java.
7 modelos de desarrollo de software que debes conocer
Fuente: DZone El ciclo de vida del desarrollo de software es el proceso de planificación, diseño, desarrollo, prueba e implementación de software al menor costo posible, preferiblemente en el menor tiempo posible. Para lograr este objetivo, los equipos de desarrollo deben elegir el modelo de desarrollo de software adecuado que cumpla con los requisitos del proyecto y las expectativas de todas las partes interesadas. Hay 7 modelos que debes conocer, desde Waterfall hasta V-Model y Scrum. Veamos cada uno de ellos.
1. Modelo en cascada (Cascada)
El modelo en cascada se considera uno de los primeros métodos de desarrollo de software. Ya por el nombre queda claro que este proceso de desarrollo incluye una progresión lineal en orden: análisis, diseño, desarrollo, pruebas, implementación y soporte. Cada etapa está claramente definida por resultados específicos. El modelo en cascada es secuencial, lo que significa que la siguiente etapa no puede comenzar hasta que se complete la actual. Una etapa se considera completa cuando se ha logrado el objetivo y alguien se compromete a seguir trabajando en el proyecto. No hay flexibilidad en este modelo: no se pueden omitir, retroceder ni cambiar pasos. Como resultado, el proceso de desarrollo puede resultar innecesariamente complejo y costoso. La falta de flexibilidad hace que este modelo sea más caro y requiera más mano de obra en comparación con otros modelos. Si los requisitos no están claros o se malinterpretan, utilizar este modelo es muy arriesgado. Además, este modelo no es ideal para proyectos complejos o en curso a largo plazo donde se requiere mayor flexibilidad. Aunque las deficiencias del modelo son notables y significativas, puede resultar útil para proyectos pequeños y únicos con requisitos limitados y plazos cortos porque es simple y rápido de configurar. Sin embargo, el equipo debe asegurarse de que todos los requisitos estén claramente definidos, sean inequívocos y no puedan cambiar en el futuro. El modelo Waterfall ha caído en desgracia a medida que los equipos de TI adoptan un desarrollo de software más ágil que permite mejoras continuas.
2. modelo V
El modelo V, o modelo de aprobación y verificación, amplía el modelo en cascada añadiendo un plan de pruebas. En lugar de moverse linealmente hacia abajo a través de las etapas de desarrollo de software, el modelo V desciende hasta la etapa de codificación, luego da la vuelta y comienza a avanzar a través de las etapas de prueba, formando una forma de V. Cada etapa de desarrollo corresponde a una actividad de prueba específica. Esto permite al equipo encontrar errores en las especificaciones, el código y la arquitectura al principio del proyecto. Agregar un plan de prueba le da al modelo V una mayor probabilidad de éxito que el modelo en cascada. Sin embargo, el modelo V sigue siendo lineal, lo que lo hace inflexible. Al igual que en el modelo de cascada, el equipo puede comenzar la siguiente etapa sólo después de que se haya completado la etapa anterior. Esto hace que los cambios sean difíciles, costosos y requieran mucho tiempo. Por lo tanto, este modelo es más adecuado para proyectos cortos con requisitos fijos, bien definidos y documentados, pero no es ideal para proyectos a largo plazo, complejos o en curso.
3. Modelo iterativo (incremental)
Al igual que otros modelos de desarrollo de software, el modelo iterativo (incremental) está diseñado para superar algunas de las desventajas del modelo en cascada. También comienza con la planificación y termina con el despliegue. Pero a diferencia del modelo en cascada, este modelo implica repetir ciclos a lo largo del proceso. Estos bucles pueden ser iterativos (repetidos) o incrementales (paso a paso). El proceso de desarrollo comienza con un pequeño conjunto de requisitos, y cada ciclo dentro del mismo va acompañado de un nuevo conjunto de requisitos. La naturaleza iterativa de este modelo permite que el software evolucione y crezca a medida que se pueden realizar pequeños cambios a lo largo del proceso. Esto sucede porque la nueva iteración se basa en la anterior. Los desarrolladores pueden realizar cambios basándose en la experiencia de ciclos anteriores. Debido a que no se establecen todos los requisitos al comienzo del proyecto y se realizan muchos cambios a lo largo del camino, el trabajo puede comenzar rápidamente. Sin embargo, los recursos pueden agotarse rápidamente ya que el proceso se repite con frecuencia, sin mencionar que la gestión se vuelve más compleja. Aunque el modelo permite algunos cambios, todavía consta de procesos claramente definidos, que a veces conducen a la inflexibilidad. El costo de realizar cambios es menor que los modelos en cascada y en V, pero este modelo no es ideal para proyectos donde los requisitos pueden cambiar durante la iteración. El modelo iterativo crea más riesgos debido a cambios frecuentes, costos y requisitos de recursos desconocidos y plazos inciertos.
4. Modelo de creación de prototipos
El modelo de creación de prototipos se centra en mejorar la comprensión por parte del equipo de desarrollo de los deseos y necesidades del cliente mediante la creación de prototipos. Al crear una pequeña copia funcional del programa deseado, se pueden eliminar malentendidos antes de que comience el desarrollo completo. El prototipo se desarrolla, prueba y finaliza teniendo en cuenta los deseos y comentarios del cliente. Una vez aceptado el prototipo, el equipo comienza a desarrollar el producto final. Un modelo de creación de prototipos puede reducir drásticamente el número de iteraciones. Esto ahorra tiempo y aumenta las posibilidades de satisfacción del cliente. Sin embargo, es necesario considerar el tiempo que dedica un desarrollador a desarrollar prototipos. Si el cliente requiere muchos cambios, cambia de opinión con frecuencia o hace solicitudes poco realistas, desarrollar un prototipo puede volverse complicado rápidamente. Por este motivo, es mejor limitar el número de iteraciones permitidas antes de aceptar el prototipo. Una vez que el prototipo final esté en desarrollo, no se podrán realizar más requisitos ni cambios al plan. Este es un inconveniente importante del modelo de creación de prototipos.
5. Modelo en espiral
El modelo en espiral se centra en la evaluación de riesgos. Por ello, cualquier equipo que desee utilizar este modelo debe contar con especialistas con conocimientos y habilidades en un área específica. El modelo consta de cuatro etapas: planificación, análisis de riesgos, desarrollo y evaluación. El número de vueltas de la espiral depende del proyecto específico y de los requisitos del director. En promedio, el desarrollo de software utilizando este modelo lleva 6 meses. El modelo Espiral combina las características del modelo en cascada y la creación de prototipos al enfatizar el diseño, incluida la creación de prototipos (durante la fase de diseño) y seguir pasos similares a los del modelo en cascada. El desarrollo continuo e iterativo permite a los desarrolladores realizar cambios y agregar nuevas funciones. Además, el desarrollo es sistemático, lo que simplifica el proceso. El cliente participa en la revisión de cada etapa del ciclo, lo que puede resultar una carga para el proceso de desarrollo si no hay una comunicación constante con el cliente. Dado que el número de ciclos o iteraciones no está definido, existe el riesgo de exceder el presupuesto y no cumplir con los plazos. Por lo tanto, crear un producto terminado a menudo requiere mucho dinero y tiempo.
Metodología flexible (Agile)
Agile es una metodología basada en 12 principios descritos en el Manifiesto Ágil . Es más una forma de pensar que un conjunto de protocolos estrictos. El método Agile está diseñado para desarrollar software de manera más eficiente que el uso de modelos anteriores, incluido el modelo en cascada. La esencia del modelo ágil es centrarse en la colaboración, la comunicación y el cambio constante. Hay varias opciones para el desarrollo ágil. Todos se centran en el trabajo en equipo, la colaboración interdisciplinaria, el desarrollo iterativo y los comentarios tempranos de los clientes. Las pruebas, los comentarios y los cambios permiten a los equipos desarrollar y lanzar un mejor software. Veamos los 2 modelos ágiles.
6. modelo scrum
El modelo Scrum es el modelo Agile más popular. Sus iteraciones de desarrollo se conocen como sprints. Durante estos sprints de 1 a 4 semanas, los equipos evalúan el sprint anterior, agregan nuevas funciones y planifican el siguiente sprint. No se permiten cambios después de que se definan las actividades del sprint. Después de cada sprint, se agregan nuevas características/elementos que se codificarán y probarán en el siguiente sprint. Esto continúa hasta que se hayan agregado todas las funciones y se considere que el proyecto está listo para su lanzamiento. Una mayor colaboración entre equipos multifuncionales y entre la organización y el cliente reduce los malentendidos y errores que a menudo surgen de una comunicación deficiente. Además, los pasos adicionales reducen el tiempo de comercialización. Una comunicación mejorada reduce el tiempo dedicado a solucionar errores y aumenta la probabilidad de que el usuario final esté satisfecho con el producto. Sin embargo, dicha cooperación requiere una participación significativa del cliente en el proceso de trabajo. También hay que tener en cuenta que si el cliente requiere añadir demasiadas funciones, el plazo del proyecto puede retrasarse.
7. Modelo Kanban
A diferencia de otros modelos, Kanban no tiene iteraciones distintas. Cuando un equipo planifica iteraciones, son sprints increíblemente cortos, a veces tan cortos como un día. Para indicar visualmente el estado del proyecto y otros detalles se utiliza un tablero con notas en forma de pegatinas (stickers). Esta visualización permite al equipo centrarse en la característica más importante en desarrollo en este momento. Además, el tablero Kanban enfatiza que hay margen para la mejora continua de las funciones. Si bien el método de las notas adhesivas puede ayudar a motivar a un equipo a concentrarse en la tarea importante, es una mala manera de definir y mantener cronogramas. Por este motivo, es muy difícil planificar proyectos a largo plazo. Dado que no existe una etapa de planificación establecida, se pueden realizar cambios en cualquier momento. Una de las desventajas comunes de Kanban es la falta de plazos. Este problema puede empeorar si se realizan cambios constantemente.
Transición a ágil
Cada uno de estos modelos fue creado para mejorar el proceso de desarrollo y entrega de software. Cualquier modelo de desarrollo puede funcionar bien para tipos específicos de proyectos. Sin embargo, los modelos manuales más antiguos, como el modelo en cascada, se están convirtiendo rápidamente en cosa del pasado. Los equipos de TI y las empresas en general deben actuar de forma más rápida y eficiente a la hora de crear software, satisfacer las necesidades de los clientes y mantenerse al día con la competencia. Un proceso de desarrollo de software más rápido, repetible y seguro se basa en la automatización. Y como el nivel de automatización y velocidad es inalcanzable para muchos modelos, la metodología Agile acaba volviéndose más popular.
Hay 7 modelos que debes conocer, desde Waterfall hasta V-Model y Scrum. Veamos cada uno de ellos.
El modelo en cascada se considera uno de los primeros métodos de desarrollo de software. Ya por el nombre queda claro que este proceso de desarrollo incluye una progresión lineal en orden: análisis, diseño, desarrollo, pruebas, implementación y soporte. Cada etapa está claramente definida por resultados específicos. El modelo en cascada es secuencial, lo que significa que la siguiente etapa no puede comenzar hasta que se complete la actual. Una etapa se considera completa cuando se ha logrado el objetivo y alguien se compromete a seguir trabajando en el proyecto. No hay flexibilidad en este modelo: no se pueden omitir, retroceder ni cambiar pasos. Como resultado, el proceso de desarrollo puede resultar innecesariamente complejo y costoso. La falta de flexibilidad hace que este modelo sea más caro y requiera más mano de obra en comparación con otros modelos. Si los requisitos no están claros o se malinterpretan, utilizar este modelo es muy arriesgado. Además, este modelo no es ideal para proyectos complejos o en curso a largo plazo donde se requiere mayor flexibilidad. Aunque las deficiencias del modelo son notables y significativas, puede resultar útil para proyectos pequeños y únicos con requisitos limitados y plazos cortos porque es simple y rápido de configurar. Sin embargo, el equipo debe asegurarse de que todos los requisitos estén claramente definidos, sean inequívocos y no puedan cambiar en el futuro. El modelo Waterfall ha caído en desgracia a medida que los equipos de TI adoptan un desarrollo de software más ágil que permite mejoras continuas.
El modelo V, o modelo de aprobación y verificación, amplía el modelo en cascada añadiendo un plan de pruebas. En lugar de moverse linealmente hacia abajo a través de las etapas de desarrollo de software, el modelo V desciende hasta la etapa de codificación, luego da la vuelta y comienza a avanzar a través de las etapas de prueba, formando una forma de V. Cada etapa de desarrollo corresponde a una actividad de prueba específica. Esto permite al equipo encontrar errores en las especificaciones, el código y la arquitectura al principio del proyecto. Agregar un plan de prueba le da al modelo V una mayor probabilidad de éxito que el modelo en cascada. Sin embargo, el modelo V sigue siendo lineal, lo que lo hace inflexible. Al igual que en el modelo de cascada, el equipo puede comenzar la siguiente etapa sólo después de que se haya completado la etapa anterior. Esto hace que los cambios sean difíciles, costosos y requieran mucho tiempo. Por lo tanto, este modelo es más adecuado para proyectos cortos con requisitos fijos, bien definidos y documentados, pero no es ideal para proyectos a largo plazo, complejos o en curso.
Al igual que otros modelos de desarrollo de software, el modelo iterativo (incremental) está diseñado para superar algunas de las desventajas del modelo en cascada. También comienza con la planificación y termina con el despliegue. Pero a diferencia del modelo en cascada, este modelo implica repetir ciclos a lo largo del proceso. Estos bucles pueden ser iterativos (repetidos) o incrementales (paso a paso). El proceso de desarrollo comienza con un pequeño conjunto de requisitos, y cada ciclo dentro del mismo va acompañado de un nuevo conjunto de requisitos. La naturaleza iterativa de este modelo permite que el software evolucione y crezca a medida que se pueden realizar pequeños cambios a lo largo del proceso. Esto sucede porque la nueva iteración se basa en la anterior. Los desarrolladores pueden realizar cambios basándose en la experiencia de ciclos anteriores. Debido a que no se establecen todos los requisitos al comienzo del proyecto y se realizan muchos cambios a lo largo del camino, el trabajo puede comenzar rápidamente. Sin embargo, los recursos pueden agotarse rápidamente ya que el proceso se repite con frecuencia, sin mencionar que la gestión se vuelve más compleja. Aunque el modelo permite algunos cambios, todavía consta de procesos claramente definidos, que a veces conducen a la inflexibilidad. El costo de realizar cambios es menor que los modelos en cascada y en V, pero este modelo no es ideal para proyectos donde los requisitos pueden cambiar durante la iteración. El modelo iterativo crea más riesgos debido a cambios frecuentes, costos y requisitos de recursos desconocidos y plazos inciertos.
El modelo de creación de prototipos se centra en mejorar la comprensión por parte del equipo de desarrollo de los deseos y necesidades del cliente mediante la creación de prototipos. Al crear una pequeña copia funcional del programa deseado, se pueden eliminar malentendidos antes de que comience el desarrollo completo. El prototipo se desarrolla, prueba y finaliza teniendo en cuenta los deseos y comentarios del cliente. Una vez aceptado el prototipo, el equipo comienza a desarrollar el producto final. Un modelo de creación de prototipos puede reducir drásticamente el número de iteraciones. Esto ahorra tiempo y aumenta las posibilidades de satisfacción del cliente. Sin embargo, es necesario considerar el tiempo que dedica un desarrollador a desarrollar prototipos. Si el cliente requiere muchos cambios, cambia de opinión con frecuencia o hace solicitudes poco realistas, desarrollar un prototipo puede volverse complicado rápidamente. Por este motivo, es mejor limitar el número de iteraciones permitidas antes de aceptar el prototipo. Una vez que el prototipo final esté en desarrollo, no se podrán realizar más requisitos ni cambios al plan. Este es un inconveniente importante del modelo de creación de prototipos.
El modelo en espiral se centra en la evaluación de riesgos. Por ello, cualquier equipo que desee utilizar este modelo debe contar con especialistas con conocimientos y habilidades en un área específica. El modelo consta de cuatro etapas: planificación, análisis de riesgos, desarrollo y evaluación. El número de vueltas de la espiral depende del proyecto específico y de los requisitos del director. En promedio, el desarrollo de software utilizando este modelo lleva 6 meses. El modelo Espiral combina las características del modelo en cascada y la creación de prototipos al enfatizar el diseño, incluida la creación de prototipos (durante la fase de diseño) y seguir pasos similares a los del modelo en cascada. El desarrollo continuo e iterativo permite a los desarrolladores realizar cambios y agregar nuevas funciones. Además, el desarrollo es sistemático, lo que simplifica el proceso. El cliente participa en la revisión de cada etapa del ciclo, lo que puede resultar una carga para el proceso de desarrollo si no hay una comunicación constante con el cliente. Dado que el número de ciclos o iteraciones no está definido, existe el riesgo de exceder el presupuesto y no cumplir con los plazos. Por lo tanto, crear un producto terminado a menudo requiere mucho dinero y tiempo.
El modelo Scrum es el modelo Agile más popular. Sus iteraciones de desarrollo se conocen como sprints. Durante estos sprints de 1 a 4 semanas, los equipos evalúan el sprint anterior, agregan nuevas funciones y planifican el siguiente sprint. No se permiten cambios después de que se definan las actividades del sprint. Después de cada sprint, se agregan nuevas características/elementos que se codificarán y probarán en el siguiente sprint. Esto continúa hasta que se hayan agregado todas las funciones y se considere que el proyecto está listo para su lanzamiento. Una mayor colaboración entre equipos multifuncionales y entre la organización y el cliente reduce los malentendidos y errores que a menudo surgen de una comunicación deficiente. Además, los pasos adicionales reducen el tiempo de comercialización. Una comunicación mejorada reduce el tiempo dedicado a solucionar errores y aumenta la probabilidad de que el usuario final esté satisfecho con el producto. Sin embargo, dicha cooperación requiere una participación significativa del cliente en el proceso de trabajo. También hay que tener en cuenta que si el cliente requiere añadir demasiadas funciones, el plazo del proyecto puede retrasarse.
A diferencia de otros modelos, Kanban no tiene iteraciones distintas. Cuando un equipo planifica iteraciones, son sprints increíblemente cortos, a veces tan cortos como un día. Para indicar visualmente el estado del proyecto y otros detalles se utiliza un tablero con notas en forma de pegatinas (stickers). Esta visualización permite al equipo centrarse en la característica más importante en desarrollo en este momento. Además, el tablero Kanban enfatiza que hay margen para la mejora continua de las funciones. Si bien el método de las notas adhesivas puede ayudar a motivar a un equipo a concentrarse en la tarea importante, es una mala manera de definir y mantener cronogramas. Por este motivo, es muy difícil planificar proyectos a largo plazo. Dado que no existe una etapa de planificación establecida, se pueden realizar cambios en cualquier momento. Una de las desventajas comunes de Kanban es la falta de plazos. Este problema puede empeorar si se realizan cambios constantemente.
GO TO FULL VERSION