Successfully reported this slideshow.
Your SlideShare is downloading. ×

CUADRO COMPARATIVO DE LOS MODELOS DE CICLO DE VIDA DE SOFTWARE

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
Modelo de prototipos
Modelo de prototipos
Loading in …3
×

Check these out next

1 of 10 Ad

More Related Content

Slideshows for you (20)

Similar to CUADRO COMPARATIVO DE LOS MODELOS DE CICLO DE VIDA DE SOFTWARE (20)

Advertisement

CUADRO COMPARATIVO DE LOS MODELOS DE CICLO DE VIDA DE SOFTWARE

  1. 1. CUADRO COMPARATIVO DE LOS MODELOS DE CICLO DE VIDA DE SOFTWARE MODELOS DE PROCESOS MODELOS DE CICLO DE VIDA DESCRIPCIÓN REPRESENTACIÓN GRÁFICA VENTAJAS DESVENTAJAS EN QUÉ CASOS SE RECOMIENDA USAR Cascada Este modelo sugiere un enfoque sistemático y secuencial para el desarrollo del software, que comienza con la especificación de los requerimientos por parte del cliente y avanza a través de planeación, modelado, construcción y despliegue. [1] (Ver gráfico: Anexo 1) ● Planificación sencilla. ● Es la de proveer un producto con un elevado grado de calidad sin necesidad de un personal altamente calificado. [2] ● Las desventajas del modelo en cascada pura se centra en la dificultad para especificar claramente los requerimientos al comienzo del proyecto, antes de que se realice ningún trabajo de diseño y antes de escribir ningún código. [2] ● La necesidad de contar con todos los requerimientos (o la mayoría) al comienzo del proyecto. [2] ● Si se han cometido errores y no se detectan en la etapa inmediata siguiente, es costoso y difícil volver atrás para realizar la corrección posterior. [2] ● El cliente debe tener paciencia. No se dispondrá de una versión funcional de los programas hasta que el proyecto esté muy avanzado. [1] El modelo en cascada pura se utiliza correctamente para ciclos de productos en los que se tiene una definición estable del producto, y también cuando se está trabajando con metodologías técnicas conocidas. En estos casos, el modelo en cascada ayuda a localizar errores en las primeras etapas del proyecto a un bajo coste. [2]
  2. 2. Evolutivo Los modelos evolutivos son iterativos. Se caracterizan por la manera en la que permiten desarrollar versiones cada vez más completas del software. [1] (Ver gráfico: Anexo 2) ● Se tiene más claro y un mayor feedback del cliente mediante el desarrollo de prototipos. ● La especificación puede desarrollarse de forma creciente. ● Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la calidad del software. ● El cliente tiene un informe constante acerca del avance y el validado del sistema software. ● Permite ir desarrollando sin conocer la mayoría de los requerimientos iniciales o no están completos los requerimientos. ● Si el sistema se necesita desarrollar rápido, no es efectivo producir documentos que reflejen cada versión del sistema. ● Los cambios continuos pueden ser perjudiciales para la estructura del software haciendo costoso el mantenimiento. ● Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar. ● El cliente considera la mayoría de las veces al prototipo como el producto final. ● La calidad del software o la factibilidad de mantenimiento puede que no se tomen en cuenta. ● El usuario no conoce de informática, nos pueden pedir modificaciones o hacer nuevas solicitudes en tiempos muy cortos. Resulta ser un modelo muy útil cuando desconocemos la mayoría de los requerimientos iniciales, o estos requerimientos no están completos. [2] Espiral Es un modelo evolutivo del proceso del software y se acopla con la naturaleza iterativa de hacer prototipos con los aspectos controlados y sistémicos del modelo de cascada. Tiene el potencial para hacer un (Ver gráfico: Anexo 3) ● Puede comenzar el proyecto con un alto grado de incertidumbre. [2] ● El bajo riesgo de retraso en caso de detección de errores, ya que se puede solucionar en la próxima rama del espiral [2].. ● El costo temporal que suma ● cada vuelta del espiral. ● La dificultad para evaluar los riesgos. ● La necesidad de la presencia o la comunicación continúa con el cliente o usuario. [2] Se observa que es un modelo adecuado para grandes proyectos internos de una empresa, en donde no es posible contar con todos los requerimientos desde el comienzo y el usuario está en nuestro mismo ambiente laboral. [2]
  3. 3. desarrollo rápido de versiones cada vez más completas. [1] Con el empleo del modelo espiral, el software se desarrolla en una serie de entregas evolutivas. [1] Basado en componentes Incorpora muchas de las características del modelo espiral. Es de naturaleza evolutiva y demanda un enfoque iterativo para la creación de software. Sin embargo, el modelo de desarrollo basado en componentes construye aplicaciones a partir de fragmentos de software prefabricados. [1] (Ver gráfico: Anexo 3) ● Pueden diseñarse como módulos de software convencional o clases orientadas a objetos o paquetes de clases. [1] ● Sin importar la tecnología usada para crear los componentes, el modelo de desarrollo basado en componentes incorpora las etapas siguientes (se implementan con el uso de un enfoque evolutivo): [1] ● El modelo del desarrollo basado en componentes lleva a la reutilización del software, y eso da a los ingenieros de software varios beneficios en cuanto a la mensurabilidad. [1] ● Si la reutilización de componentes se vuelve parte de la cultura, el equipo de ingeniería de software tiene la posibilidad tanto de reducir el ciclo de tiempo del desarrollo como el ● Genera tiempos de desarrollo altos debido a que toca identificar qué partes del software va a ser un componente ● Los compromisos de los requerimientos son inevitables esto puede dar lugar a un sistema que no cumple las necesidades ● Existe el riesgo en que la integración entre componentes sea complicada, problemas de compatibilidad, de versiones ● Confiabilidad de los componentes. Este modelo es muy útil cuando se pretende desarrollar funcionalidades muy genéricas o muy requeridas en otros sistemas debido a que sus principales consideraciones son la reutilización e integración con otros componentes.
  4. 4. costo del proyecto. [1] Desarrollo Ágil Un nombre más apropiado para el desarrollo ágil sería “ingeniería de software ligero”. Combina una filosofía con un conjunto de lineamientos: ● La filosofía pone el énfasis en la satisfacción del cliente y en la entrega rápida de software incremental, los equipos pequeños y muy motivados para efectuar el proyecto, los métodos informales, los productos del trabajo con mínima ingeniería de software y la sencillez general en el desarrollo.. ● Los lineamientos de desarrollo enfatizan la entrega sobre el análisis y el diseño. Permanecen las actividades estructurales fundamentales: comunicación, planeación, modelado, construcción y ● Capacidad de reducir los costos del cambio durante el proceso del software .[1] ● Puede adaptarse con facilidad para que satisfaga los desafíos que surgen de la demanda de agilidad. [1] ● Un proceso ágil bien diseñado “aplana” el costo de la curva de cambio, lo que permite que el equipo de software haga cambios en una fase tardía de un proyecto de software sin que haya un efecto notable en el costo y en el tiempo. [1] ● Toma en cuenta que podrían existir nuevos requerimientos y modificaciones. [1] ● Considera que algunas actividades podrían ejecutarse de forma simultánea. [1] ● El proceso se adapta a las necesidades de las personas y del equipo, no al revés. [1] ● Olvidan las flaquezas de las personas cuando construyen software (Los ingenieros de software no son robots). Resulta ser muy útil casi en todos los proyectos en los que el siguiente contexto es muy importante: ● En una economía moderna, las condiciones del mercado cambian con rapidez, los clientes y usuarios finales necesitan evolucionar y surgen nuevas amenazas competitivas sin aviso previo. ● Los profesionales deben enfocar la ingeniería de software en forma que les permita mantenerse ágiles para definir procesos maniobrables, adaptativos y esbeltos que satisfagan las necesidades de los negocios modernos.
  5. 5. despliegue. Pero se transforman en un conjunto mínimo de tareas que llevan al equipo del proyecto hacia la construcción y entrega. [1] Elaborado por: Freddy Aguilar R. BIBLIOGRAFÍA 1. Pressman, R. S. (2010). Ingeniería de software - Un enfoque práctico (7th ed.). The McGraw-Hill. 2. Canepa Sáenz, A. A., & García González, C. E. (2011). Comparativa de los modelos de ciclo de vida. Acalán Revista de la Universidad Autónoma del Carmen. http://www.repositorio.unacar.mx/jspui/handle/1030620191/199 ANEXOS
  6. 6. ANEXO 1: Modelo de cascada Representación gráfica del modelo de cascada Obtenido del libro: Pressman, R. S. (2010). Ingeniería de software - Un enfoque práctico (7th ed.). The McGraw-Hill.
  7. 7. ANEXO 2: MODELO EVOLUTIVO Representación gráfica del modelo evolutivo Obtenido del libro: Pressman, R. S. (2010). Ingeniería de software - Un enfoque práctico (7th ed.). The McGraw-Hill.
  8. 8. ANEXO 3: MODELO ESPIRAL Representación gráfica del modelo espiral Obtenido del libro: Pressman, R. S. (2010). Ingeniería de software - Un enfoque práctico (7th ed.). The McGraw-Hill.
  9. 9. ANEXO 4: MODELO BASADO EN COMPONENTES Representación gráfica del modelo basado en componentes Obtenido de: https://upload.wikimedia.org/wikipedia/commons/8/83/Component-based-Software-Engineering-example2.png
  10. 10. ANEXO 5: DESARROLLO ÁGIL Esquema general de una metodología ágil para desarrollo de software Obtenido de: https://upload.wikimedia.org/wikipedia/commons/1/19/Esquema_general_de_una_metodologia_agil.png

×