Datos personales

Mi foto
Catedrático: Patricia Arieta Melgarejo Jefa de Carrera de la Licenciatura en Sistemas Computacionales Administrativos.

Modelos del ciclo de vida de software

Los modelos de ciclo de vida de software es una lista de las actividades que ocurren durante el desarrollo de software, en el cual se intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.
Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software.



Codificar y Corregir

 Este es un modelo poco útil, pero bastante común. Al no haberse seleccionado explícitamente otro modelo, por omisión se estará utilizando éste.
Cuando se utiliza se empieza con una idea general de lo que se necesita construir, y se puede o no tener una especificación formal; se utiliza cualquier combinación de diseño, código, depuración y métodos de prueba no formales que sirven hasta que se tiene el producto listo para entregarlo.

Observaciones al modelo codificar y corregir

Puede resultar útil para proyectos pequeños que se intentan liquidar poco después de ser construidos, es decir, para programas pequeños de demostración de conceptos, demostraciones de duración corta o prototipos desechables.
No tiene cabida en un proyecto de desarrollo rápido, excepto para estos pequeños proyectos arriba señalados
Es un modelo no formal que se utiliza normalmente porque es simple, pero no porque funcione bien.

Análisis Estructurado

El método de desarrollo del análisis estructurado tiene como finalidad superar esta dificultad por medio de la división del sistema en componentes y la construcción de un modelo del sistema. El método incorpora elementos tanto de análisis como de diseño. El modelo de análisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicación.
No se establece como se cumplirán los requerimientos o la forma en que se implantarán la aplicación. Más bien permiten que las personas observen los elementos lógicos (lo que hará el sistema) separados de los componentes físicos (computadoras, terminales, sistemas de almacenamiento etc.)

Cascada Pura

Es el predecesor de todos los modelos de ciclo de vida y ha servido de base para otros modelos. En el modelo de cascada pura  un proyecto progresa a través de una secuencia ordenada de etapas, partiendo desde su concepto inicial hasta la prueba del mismo, así el proyecto realiza una revisión al final de cada etapa para determinar si está preparado para pasar a la siguiente.

Observaciones al modelo cascada pura

Es el modelo más conocido y ofrece una velocidad de desarrollo aceptable en algunas circunstancias, otros modelos sin embargo, proporcionan una velocidad de desarrollo superior a éste.
Los inconvenientes del modelo hacen que sea, a menudo, poco apropiado para un proyecto de desarrollo rápido, incluso en los casos en los que las ventajas del modelo superan los inconvenientes, los modelos de cascada modificada pueden funcionar mejor.

Espiral

Es un modelo orientado a riesgos que divide un proyecto en miniproyectos, cada miniproyecto se centra en uno o más riesgos importantes hasta que todos éstos estén controlados.
El concepto “riesgo” puede referirse a requerimientos y arquitecturas poco comprensibles, a problemas de ejecución importantes o a problemas con la tecnología subyacente. Una vez que se han controlado todos los riesgos importantes, el modelo finaliza del mismo modo que el modelo de ciclo de vida en cascada. 

Observaciones al modelo espiral

El modelo de espiral es un modelo de ciclo de vida orientado a riesgos, el cual se puede combinar con otros modelos de ciclo de vida.
La principal ventaja de este modelo es que mientras los costos suben, los riesgos disminuyen.

Cascadas Modificadas

El mayor problema del modelo de cascada pura es que trata las fases del ciclo de vida como etapas secuenciales disjuntas, pero, en contraste, permite corregir los inconvenientes más importantes en el modelo de cascada pura con pequeñas modificaciones:
Puede modificarse de forma tal que las etapas se solapen.
Se puede reducir el énfasis sobre la documentación.
                        Se puede permitir más regresión. 

Variantes del modelo de cascadas modificadas

Cascada con fases solapadas

Puede evitar algunos inconvenientes del modelo de cascada pura al solapar sus etapas, por ejemplo, sugiere que se debería tener bien hecho el diseño global y quizás a medio hacer el diseño detallado antes de considerar completo el análisis de requerimientos, no obstante, puede reducir sustancialmente la documentación necesaria entre etapas.

Cascada con subproyectos

Puede permitir la ejecución de algunas de las tareas de la cascada en paralelo (subproyectos), siempre que se haya realizado una cuidadosa planificación.

Cascada con reducción de riesgos

Incorpora una espiral en lo alto de la cascada para controlar el riesgo de los requerimientos, y una espiral para las demás etapas de desarrollo. A este nivel es posible desarrollar un prototipo de interfaz de usuario, tener entrevistas con los usuarios, observar cómo los usuarios interactúan con algún sistema previo, y utilizar otros métodos que se consideren apropiados para la identificación de los requerimientos.
Desventajas de las variantes

Modelo de cascada con fases solapadas

Debido al solapamiento entre las etapas, los hitos son más ambiguos, y esto hace más difícil trazar el progreso correctamente, además la realización de actividades en paralelo puede suponer una mala comunicación, suposiciones incorrectas e ineficacia.

Modelo de cascada con subproyectos
Existe presencia de interdependencias imprevistas.

Modelo de cascada con reducción de riesgos
Ninguno.

Prototipos de Sistemas

Este método hace que el usuario participe de manera más directa en la experiencia de análisis y diseño.
La construcción de prototipos es más eficaz bajo las circunstancias correctas sin embargo, al igual que los otros métodos, el método es útil sólo si se emplea en el momento adecuado y en la forma apropiada.
El prototipo es un sistema que funciona –no solo una idea en el papel- , desarrollado con la finalidad de probar ideas y suposiciones relacionadas con el nuevo sistema. Al igual que cualquier sistema basado en computadora, está constituido por software, que acepta entradas, realiza cálculos, produce información ya sea impresa o en pantalla, o que lleva a cabo otras actividades significativas.
            Los usuarios evalúan el diseño de información generada por el sistema y deben esperarse cambios a medida que el sistema es utilizado.

            Las razones por las cuales se deben utilizar los prototipos de sistemas son que los requerimientos de información no siempre están bien definidos; los prototipos permiten evaluar situaciones extraordinarias, donde los encargados de diseñar sistemas no tienen información ni experiencia, ya que en realidad es un modelo piloto o de prueba, y es un sistema que funciona debido a que está diseñado para ser modificado con facilidad.

Prototipado Evolutivo

Es un modelo de ciclo de vida en el que se desarrolla el concepto del sistema a medida que avanza el proyecto.
Normalmente se comienza desarrollando los aspectos más visibles del sistema, posteriormente se presenta la parte ya desarrollada del sistema al cliente y se continúa el desarrollo del prototipo en base a la realimentación que se recibe del cliente. Finalmente, el ciclo continúa hasta que el prototipo se convierte en el producto final de ingeniería.
Es conveniente utilizar el prototipado evolutivo cuando los requerimientos cambian con rapidez, cuando el cliente es reacio a especificar el conjunto de los requerimientos, cuando ni el analista ni el cliente identifican de forma apropiada el área de aplicación o cuando los desarrolladores no están seguros de la arquitectura o los algoritmos adecuados a utilizar.

Ciclo en V

Uno de los inconvenientes del modelo en cascada es que las pruebas del software son dejadas al final del desarrollo.
El ciclo de vida en V, es una variación del modelo en cascada que trata este problema, toma su nombre de la forma en la cual se visualiza y es una evolución del modelo en cascada en el cual se realizan actividades en paralelo y facilita las pruebas del sistema. Así, se basa en la premisa de que las pruebas de calidad no se deben dejar al final, sino realizarse a lo largo del proceso.

Entrega por Etapas o Implementación Incremental

El sistema se muestra al cliente en etapas refinadas sucesivamente.
A diferencia del modelo de prototipado evolutivo, se conoce exactamente qué es lo que se va a construir cuando se procede a construirlo.
Lo que hace diferente a este modelo es que el sistema no se entrega como un todo al final del proyecto, sino que éste se entrega por etapas sucesivas a lo largo del proyecto.

Diseño por planificación

Es similar al modelo entrega por etapas, la diferencia radica en que no siempre se conoce al principio si se tendrá el producto para la última entrega.
Se pueden tener cinco etapas planificadas, pero sólo se llega a la tercera etapa debido a que se tiene una fecha límite que no se puede cambiar.
Uno de los elementos críticos de este modelo es priorizar los requerimientos y planificar sus etapas de tal forma que las primeras contengan los requerimientos de mayor prioridad, y los requerimientos de baja prioridad se dejan para más tarde.

Entrega Evolutiva

                        Es un modelo que se encuentra entre el prototipado evolutivo y la entrega por etapas: se desarrolla una versión del producto, se muestra al cliente, se refina el producto en función de los comentarios del cliente. El parecido entre ambos modelos depende de hasta qué punto se lleva a cabo una planificación para adaptarse a las solicitudes de los clientes.
Si se planifica para adaptarse a la mayoría de las solicitudes, la entrega evolutiva se parecerá más al prototipado evolutivo, pero si se planifica para adaptarse a pocas solicitudes de modificación, la entrega evolutiva se aproximará a la entrega por etapas.

No hay comentarios:

Publicar un comentario en la entrada