Cuadro Modelos de Ciclos de vida del software PDF

Preview

Summary

Modelos de Ciclos de vida del softwareDefinición Características Fases R. Grafica Ventajas DesventajasModelo Cuadro ComparativoCascada 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...

Description

Modelos de Ciclos de vida del software Definición

Características

Fases

Modelo Cascada

R. Grafica

Ventajas

Desventajas

Cuadro Comparativo 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. Al final de cada etapa, el modelo está diseñado para llevar a cabo una revisión final, que se encarga de determinar si el proyecto está listo para avanzar a la siguiente fase.













Primer modelo empleado (Royce, 1970), también denominado ciclo de vida clásico y modelo lineal secuencial. Consiste en la ejecución secuencial de una serie de fases que se suceden, lo que da nombre al modelo. Cada fase genera documentación para la siguiente. Esta documentación debe ser aprobada. Una fase no comienza hasta que la anterior ha terminado. Se disponga de unos requisitos completos y consistentes al principio del desarrollo. Sea un proyecto pequeño, en el que el período de congelación de los requisitos es corto, o un proyecto con unos requisitos bastante

      

Análisis de requisitos del software Diseño del sistema Diseño del programa Codificación Pruebas Verificación Mantenimiento







Realiza un buen funcionamiento en equipos débiles y productos maduros, por lo que se requiere de menos capital y herramientas para hacerlo funcionar de manera óptima. Es un modelo fácil de implementar y entender. Promueve una metodología de trabajo efectiva: Definir antes que diseñar, diseñar antes que codificar.







En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementación del modelo, lo cual hace que lo lleve al fracaso. Cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo. Una etapa determinada del proyecto no se puede llevar a cabo a menos de que se haya culminado la etapa anterior.

estables. En V

Iterativo

Es un proceso que representa la secuencia de pasos en el desarrollo del ciclo de vida de un proyecto. Se describen las actividades y resultados que deben producirse durante el desarrollo del producto. El lado izquierdo de la V representa la descomposición de las necesidades, y la creación de las especificaciones del sistema. El lado derecho de la V representa la integración de las piezas y su verificación. V significa «Verificación y validación». La idea principal detrás de mejoramiento iterativo es desarrollar un sistema de programas de manera incremental, permitiéndole al desarrollador sacar ventaja de lo que se ha aprendido a lo largo del desarrollo anterior, incrementando, versiones entregables del sistema. El aprendizaje viene de dos vertientes: el desarrollo del sistema, y su uso (mientras sea posible).

  





Minimización de los riesgos del proyecto Mejora y Garantía de Calidad Reducción de los gastos totales durante todo el proyecto y sistema de Ciclo de Vida

Provee de soporte para determinar la efectividad de los procesos y de la calidad del producto. Permite estudiar y después mejorar y ajustar el proceso para el ambiente en particular.

       







Análisis Especificación Diseño Programación Prueba Documentación Mantenimiento Reingeniería

Cualquier dificultad en el diseño, codificación y prueba de una modificación debería apuntar a la necesidad de rediseñar o recodificar. Las modificaciones deben ajustarse fácilmente a los módulos fáciles de encontrar y a los aislados. Si no es así, entonces se requiere algún grado de rediseño. Las modificaciones a las tablas deben ser especialmente fáciles de realizar. Si dicha modificación no

• La relación entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localización de fallos. • Es un modelo sencillo y de fácil aprendizaje. • Hace explícito parte de la iteración y trabajo que hay que revisar. • Especifica bien los roles de los distintos tipos de pruebas a realizar. • Involucra al usuario en las pruebas.



En el desarrollo de este modelo se da la retroalimentació n muy temprano a los usuarios. Permite separar la complejidad del proyecto, gracias a su desarrollo por parte de cada iteración o bloque. El producto es consistente y puntual en el desarrollo. Los productos desarrollados con este modelo tienen una menor probabilidad de



















Es difícil que el cliente exponga explícitamente todos los requisitos. El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida. Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas. • El producto final obtenido puede que no refleje todos los requisitos del usuario.

La entrega temprana de los proyectos produce la creación de sistemas demasiados simples que a veces se ven un poco monótonos a los ojos del personal que lo recibe. Los incrementos en si ya son estipulados desde antes de la entrega del proyecto, sin embargo hay que ver cómo se maneja el producto para ver si necesita otros cambios además de los estipulados antes de la entrega del proyecto.







Incremental

El modelo incremental de gestión de proyectos tiene como objetivo un crecimiento progresivo de la funcionalidad. Es decir, el producto va



Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta frecuencia.

ocurre rápidamente, se debe aplicar algo de rediseño. Las modificaciones deben ser más fáciles de hacer conforme avanzan las iteraciones. Si no es así, hay un problema primordial usualmente encontrado en un diseño débil o en la proliferación excesiva de parches al sistema. Los parches normalmente deben permanecer solo por una o dos iteraciones. Se hacen necesarios para evitar el rediseño durante una fase de implementación. La implementación existente debe ser analizada frecuentemente para determinar qué tal se ajusta a las metas del proyecto.





Requerimientos Definición de las tareas y las iteraciones Diseño de los









  

fallar. Se obtiene un aprendizaje en cada iteración que es aplicado en el desarrollo del producto y aumenta las experiencias para próximos proyectos.

Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se



Requiere de un cliente involucrado durante todo el curso del proyecto. Hay clientes que simplemente no estarán dispuestos a invertir el tiempo necesario. El trato con el cliente debe basarse en principios éticos y colaboración mutua, más que trabajar cada parte independientement e, defendiendo sólo su propio beneficio. La entrega de un programa que es parcial pero funcional puede hacer vulnerable al programa debido a la falta de robustez en su sistema, provocando que agentes ajenos puedan interferir con el correcto funcionamiento del programa en sí. Infunde responsabilidad en el equipo de desarrollo al trabajar directamente con el cliente, requiriendo de profesionales sobre el promedio. El modelo incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de

evolucionando con cada una de las entregas previstas hasta que se amolda a lo requerido por el cliente o destinatario. Este enfoque, que se usó inicialmente para proyectos de software aunque más tarde se aplicó a otros sectores, establece entregas parciales mediante un calendario de plazos.

  



 

El usuario se involucra más. Difícil de evaluar el costo total. Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo. Requiere gestores experimentados. Los errores en los requisitos se detectan tarde. El resultado puede ser positivo.

   

incrementos Desarrollo del incremento Validación de incrementos Integración de incrementos: Entrega del producto







implementa la funcionalidad parcial. También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del software. El modelo proporciona todas las ventajas del modelo en Cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento. Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.





seguridad, de procesamiento distribuido y/o de alto índice de riesgos. Requiere de mucha planeación, tanto administrativa como técnica. Requiere de metas claras para conocer el estado del proyecto.

Espiral

Consiste en una serie de ciclos que se repiten. Cada uno tiene las mismas fases y cuando termina da un producto ampliado con respecto al ciclo anterior. En este sentido es parecido al modelo incremental, la diferencia importante es que tiene en cuenta el concepto de riesgo.









 

Prototipos

El Modelo de prototipos, en Ingeniería de software, pertenece a los modelos de desarrollo evolutivo. El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar muchos recursos. El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es











Contiene una nueva etapa que es el análisis de riesgos, no incluida anteriormente. Este modelo es el indicado para desarrollar software con diferentes versiones actualizadas como se hace con los programas modernos de PC ´s. La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de construcción de prototipos. Este es el enfoque más realista actualmente. El prototipo es una aplicación que funciona. La finalidad del prototipo es probar varias suposiciones formuladas por analistas y usuarios. Los prototipos se crean con rapidez. Los prototipos evolucionan a través de un proceso.

   

Determinar Objetivos. Análisis del riesgo. Desarrollar y probar. Planificación.

  

    

Modelado, diseño rápido Construcción del Prototipo Desarrollo, entrega y retroalimentación Comunicación



Reduce riesgos del proyecto Incorpora objetivos de calidad Integra el desarrollo con el mantenimiento, etc.



Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. También ofrece un mejor enfoque cuando el responsable del desarrollo del software está



 

Genera mucho tiempo en el desarrollo del sistema Modelo costoso Requiere experiencia en la identificación de riesgos

El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a

evaluado por el cliente para una retroalimentación.

inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humanomáquina.

reconstruirlo una vez que el prototipo ha cumplido su función....