¡ The dream of each night ! *: 🔰 Cuadro comparativo de los modelos y metodologías de desarrollo de software ✔🔅

Métodos y metodologías en el desarrollo de software
Nombre	Cascada	Espiral	Extreme Programming	Metodologías Ágiles
Descripción	Denominado así por la posición de las fases en el desarrollo de esta, que parecen caer en cascada “por gravedad” hacia las siguientes fases. Es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior.	El Desarrollo en Espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1988, utilizado generalmente en la Ingeniería de software. Las actividades de este modelo son una espiral, cada bucle es una actividad. Las actividades no están fijadas a prioridad, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.	La programación extrema es una metodología de desarrollo ágil que tiene como principal objetivo aumentar la productividad a la hora de desarrollar un proyecto software. Da prioridad a los trabajos que dan un resultado directo y en los cuales se reduce la burocracia que pueda existir en el entorno de trabajo.	Las metodologías ágiles son métodos de desarrollo de software en los que las necesidades y soluciones evolucionan a través de una colaboración estrecha entre equipos multidisciplinarios. Se caracterizan por enfatizar la comunicación frente a la documentación, por el desarrollo evolutivo y por su flexibilidad.
Etapas	· Ingeniería y Análisis del Sistema: Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software. · Análisis de los requisitos del software: El proceso de recopilación de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas. · Diseño: El diseño del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz. El proceso de diseño tradúcelos requisitos en una representación del software con la calidad requerida antes de que comience la codificación. · Codificación: El diseño debe traducirse en una forma legible para la máquina. El paso de codificación realiza esta tarea. Si el diseño se realiza de una manera detallada la codificación puede realizarse mecánicamente. · Prueba: Una vez que se ha generado el código comienza la prueba del programa. La prueba se centra en la lógica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren. · Verificación: Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya realizaron exhaustivas pruebas para comprobar que el sistema no falle. · Mantenimiento: El software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debido a que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento.	· Determinar o fijar objetivos Analizar cuáles son los fines del software, determinar para que tipo de persona ira dirigido el software Identificación de riesgos del proyecto y estrategias alternativas para evitarlos. Hay una cosa que solo se hace una vez: planificación inicial. · Planificar Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad. · Análisis del riesgo Se lleva a cabo el estudio de las causas de las posibles amenazas y probables eventos no deseados y los daños y consecuencias que éstas puedan producir. · Desarrollar, verificar y validar (probar) · Probar el programa para validar o modificar el software.	Esta metodología tiene como base la simplicidad y como objetivo principal la satisfacción del cliente; para lograrlo se deben tomar en cuenta cuatro valores fundamentales: · Comunicación Es muy importante que haya una comunicación constante con el cliente y dentro de todo el equipo de trabajo, de esto dependerá que el desarrollo se lleve a cabo de una manera sencilla, entendible y que se entregue al cliente lo que necesita. · Simplicidad En la XP se refiere que ante todo y sin importar qué funcionalidad requiera el usuario en su sistema, éste debe ser fácil. El diseño debe ser sencillo y amigable al usuario, el código debe ser simple y entendible, programando sólo lo necesario y lo que se utilizará. · Retroalimentación Es la comunicación constante entre el desarrollador y el usuario. · Coraje Se refiere a la valentía que se debe tener al modificar o eliminar el código que se realizó con tanto esfuerzo; el desarrollador debe saber cuándo el código que desarrolló no es útil en el sistema y, por lo mismo, debe ser eliminado. También se refiere a tener la persistencia para resolver los errores en la programación.	· A los individuos sobre los procesos y herramientas. Pues nada sustituye a las personas a pesar de todas las ayudas que existen para desarrollar software. Toda la importancia hay que dársela a las personas, que deben permanecer en un primer plano. · Al software funcionando sobre la documentación exhaustiva. Esto se debe a que había llegado un punto en el que la documentación de un trabajo había alcanzado tanta importancia como el objeto de trabajo en sí mismo, el producto. Cuando realmente la mayor atención debe estar puesta siempre en lo que queremos construir, y lo demás debería ser secundario. · La colaboración del cliente sobre la negociación de un contrato. A la hora de sacar un proyecto adelante, la forma más productiva siempre será estableciendo un marco de colaboración y confianza con quien nos lo encarga. Lo que estaba cobrando mayor importancia antaño era cerrar un contrato atado que sirviese por encima de todo como una herramienta de protección, de manera que el cliente y el equipo parecían partes enfrentadas, cuando en realidad comparten objetivos e intereses. · La respuesta al cambio sobre seguir un plan. Se trata de apreciar la incertidumbre como un componente básico del trabajo, de tal manera que la adaptabilidad y la flexibilidad se convierten en virtudes y no en defectos de la manera de trabajar del equipo. Por norma general, el seguimiento ciego de un plan suele llevar al fracaso si no se puede corregir la dirección ante los inevitables cambios que van surgiendo.
Roles	Dentro del método de cascada existen 4 roles que son considerados los más importantes: · Analista(s) · Programador(es) · Diseñador(es) · Testing	· Programador. El programador escribe las pruebas unitarias y produce el código del sistema. · Cliente. El cliente escribe las historias de usuario y las pruebas funcionales para validar su implementación. · Tester. El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales.	En este tipo de métodos siempre se necesitara de: · Tester. · Programador. · Tracker. · Entrenador. · Consultor. · Gestor.	· Programador. El programador escribe las pruebas unitarias y produce el código del sistema. · Cliente. Escribe las historias de usuario y las pruebas funcionales para validar su implementación. Además, asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar mayor valor al negocio. · Encargado de pruebas (Tester). Ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas. · Encargado de seguimiento (Tracker). Proporciona realimentación al equipo. Verifica el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, para mejorar futuras estimaciones. Realiza el seguimiento del progreso de cada iteración. · Entrenador (Coach). Es responsable del proceso global. Debe proveer guías al equipo de forma que se apliquen las prácticas XP y se siga el proceso correctamente. · Consultor. Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto, en el que puedan surgir problemas. · Gestor (Big boss). Es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación
Ventajas	· Se tiene bien organizado y no se mezclan las fases · Ayuda a localizar errores en las primeras etapas del proyecto a un bajo costo · La documentación es muy exhaustiva y si se une al equipo un nuevo desarrollador, podrá comprender el proyecto leyendo documentación, · Al ser un proyecto bien estructurado, con bases definidas es fácil de entender.	· No requiere una definición completa de los requerimientos del software a desarrollar para comenzar su funcionalidad. · En la terminación de un producto desde el final de la primera iteración es muy factible aprobar los requisitos. · Sufrir retrasos corre un riesgo menor, porque se comprueban los conflictos presentados tempranamente y existe la forma de poder corregirlos a tiempo.	· Se adapta al desarrollo de sistemas pequeños y grandes · Optimiza el tiempo de desarrollo · Permite realizar el desarrollo del sistema en parejas para complementar los conocimientos · El código es sencillo y entendible, además de la poca documentación a elaborar para el desarrollo del sistema. · Programación organizada. · Menor taza de errores. · Satisfacción del programador.	Rápida respuesta a los cambios. Al ser procesos evolutivos, los equipos de trabajo pueden implementar soluciones sobre la marcha. Ya no es necesario esperar hasta el final para corregir fallos. Intervención del cliente en el proceso. El cliente interviene de una forma activa en cada una de las etapas del proceso. Puede aportar ideas y opinar sobre los resultados que se le van entregando progresivamente. Entregas del producto a intervalos. Las entregas parciales o en bloques mejoran la optimización de recursos y optimizan las labores de seguimiento y control. Eliminación de tareas innecesarias. Esta distinción ayuda a centralizar esfuerzos y a unificar criterios de actuación.
Desventajas	· Gran dependencia en los requerimientos iníciales · Difícilmente un cliente va a establecer al principio todos los requerimientos necesarios, por lo que provoca un gran atraso trabajando en este modelo, ya que este es muy restrictivo y no permite movilizarse entre fases. · El modelo genera pocos signos visibles de progreso hasta el final. Esto puede dar la impresión de un desarrollo lento, existe la incertidumbre de los clientes sí sus proyectos serán entregados a tiempo. · Inicio de la codificación muy tarde en el ciclo de vida del proyecto	· Existe complicación cuando se evalúa los riesgos. · Se requiere la participación continua por parte del cliente. · Se pierde tiempo al volver producir inicialmente una especificación completa de los requerimientos cuando se modifica o mejora el software.	· No se tiene la definición del costo y el tiempo de desarrollo · El sistema va creciendo después de cada entrega al cliente y nadie puede decir que el cliente no querrá una función más · Se necesita de la presencia constante del usuario, lo cual en la realidad es muy difícil de lograr. · Es recomendable emplearlo solo en proyectos a corto plazo. · Altas comisiones en caso de fallar.	Fuerte dependencia de los líderes. Los equipos de trabajo dependen en buena medida del liderazgo de la persona responsable. Las reuniones continuas y las evaluaciones periódicas hacen que la persona que encabeza el proyecto centralice casi todas las decisiones y responsabilidades. Falta de documentación. Las metodologías Ágile no plantean alternativas a para la recolección de la información de los proyectos. Simplemente plantea la manera cómo se llevarán a cabo las acciones. Soluciones erróneas en etapas largas. Cuando las iteraciones tienden a ser muy largas, se corre el riesgo de que las soluciones esbozadas al inicio de las etapas no sean las correctas. Una fase larga puede evolucionar mientras se está ejecutando y, por tanto, las medidas tomadas tienen a perder vigencia.
Número de integrantes de los equipos	Las estadísticas varían de acuerdo a autores pero lo recomendable es que lo integren 5 personajes.	Se recomienda de 5 a 9 personas.	Existen diversos números pero en lo sensato son 6 integrantes.	Solo existen un mínimo de 8 integrantes, el máximo depende de quien lo implemente, ya que no existe limite.
¿En la construcción de qué tipo de aplicaciones se usa?	Muchas empresas lo toman en cuenta por la eficiencia y los resultados obtenidos. Desarrollando software de seguridad.	Suele ser muy factible en cuanto al desarrollo para App, así como en páginas web.	Este tipo de método se le asocia las aplicaciones móviles.	Este método es moldeable para todo tipo de aplicaciones.
Nombre de una empresa que la emplea	Claméo Telecom Nokia	Google Amazon Yahoo	BBVA Ness	Appel Zara Facebook
País que emplea dicha metodología	México España Alemania	Corea del sur México	Panamá Ecuador E.U	China USA