El término ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la fase final. El propósito de este programa es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicación, es decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo: se asegura de que los métodos utilizados son apropiados.
Los modelos prescriptivos de proceso se propusieron originalmente para ordenar el caos del desarrollo de software. Estos modelos convencionales proveen unas estructuras útilies para el trabajo de la ingeniería de software, y proporcionan un camino razonablemente efectivo a seguir a los equipos de software.
Un modelo prescriptivo del proceso llena el marco de trabajo con un conjunto de tareas aplicadas para las acciones de la ingeniera de software.
Los modelos presciptivos del software a menudo se denomian modelos "convencionales" de proceso.
Se les llama "prescriptivos" porque presciben un conjunto de elementos del proceso:
- Actividades del Marco de Trabajo
- Acciones de la Ing. del software
- Tareas
- Productos de trabajo
- Aseguramiento de la calidad
- Mecanismos de control del cambio para cada proyecto
Cada modelo también describe un "flujo de trabajo" ; esto es, la forma en la cual los procesos se interrelacionan entre sí.
Todos los medelos del proceso de software se ajustan a las actividades genericas del marco de trabajo (comunicación, planeación, modelado, construcción y desarrollo), pero cada uno aplica una importancia diferente a estas actividades, asi como a las tareas realizadas dentro de cada actividad.
Modelo en Cascada
Se puede hacer uso de este modelo cuando se presenten las siguientes condiciones, por ejemplo:
- Cuando los requisitos del problema se entienden razonablemente.
- Para hacer adaptaciones o mejorias bien definidas a un sistema existente.
- Limitadamente en proyectos de nuevos desarrollos, solo cuando los requisitos entan muy bien definidos y estables en forma razonable.
Problemas que se presentan al aplicar el modelo en cascada:
- Es raro que los proyectos reales sigan el flujo secuencial que propone el modelo. El modelo tiene iteracciones indirectas, lo cual confunde al equipo desarrollador.
- Con frecuencia es dificil para el cliente establecer todos los requisitos de manera explicita. El modelo lo require desde un principio.
- El Cliente debe tener paciencia. Una versión funcionando estará lista cuando el proyecto este muy avanzado.
"Clic para ver mejor"
MODELOS DE PROCESOS INCREMENTALES
Cuando hay una necesidad imperiosa de producir de manera rápida un conjunto limitado de funcionalidad para el usuario y después refinarla y expandirla en entregas posteriores de software. En estos casos se elige un modelo de proceso diseñado para producir el software de manera incremental.
El Modelo Incremental
El modelo incremental combina elementos del modelo en cascada aplicado en forma iterativa.
1. Combina elementos del modelo lineal con la filosofía de creación de prototipos
2. El primer incremento a menudo es un producto esencial (núcleo)
3. A partir de la evaluación se planea el siguiente incremento y así sucesivamente
4. Es interactivo por naturaleza
5. Aseguramiento de la calidad
6. Es útil cuando el personal no es suficiente para la implementación completa
"clic para ver mejor"
Ventajas:
Se puede financiar el proyecto por partes
Apropiado para proyectos grandes de larga duración
No se necesita tanto personal al principio como para una implementación completa
Desventajas:
Se necesitan pruebas de regresión
Pueden aumentar el coste debido a las pruebas
El Modelo DRA Desarrollo rápido de aplicaciones (DRA) es un modelo que resalta un ciclo de desarrollo corto. Si se entienden bien los requisitos y se limita bien el ámbito del proyecto, un equipo de
desarrollo puede crear un “sistema completamente funcional” dentro de un periodo muy corto.
Inconvenientes:
- Para proyectos grandes requiere recursos humanos suficientes
- Los clientes y desarrolladores deben estar comprometidos en las rápidas actividades
- Si el sistema no se puede modularizar será problemático no es adecuado con riesgos técnicos altos
MODELOS DE PROCESOS EVOLUTIVOS
El software como en casi todos los sistemas evolucionan con el tiempo. Por ejemplo, cuando se presentan algunas de las siguientes situaciones:
- Los requisitos del negocio y del producto cambian conforme se realiza el desarrollo.
- Las estrictas fechas topes del mercado imposibilitan la conclusión de un producto completo.
Los ingenieros de sotware necesitan un modelo de proceso que se adapte a un producto que evolucione conforme el tiempo.
Los modelos evolutivos son iterativos; los caracteriza la forma en que permiten que los ingenieros de software desarrollen versiones cada vez más completas de software.
Construcción de Prototipos
Un prototipo es una representación limitada del diseño de un producto que permite a las partes responsables de su creación experimentar, probarlo en situaciones reales y explorar su uso.
Un prototipo puede ser cualquier cosa, desde un trozo de papel con sencillos dibujos a un complejo software.
Un prototipo puede ser cualquier cosa, desde un trozo de papel con sencillos dibujos a un complejo software.
Un paradigma de construcción de protopitos puede tomar un mejor enfoque, por ejemplo para las siguientes situaciones:
- Cuando el cliente define los objetivos generales, pero no indentifica los requisistos detallados de entrada, salida o procesamiento.
- Cuando el desarrollador de software esta inseguro de la eficacia de una algoritmo, de la adaptavilidad de un sistema operativo o de la forma que debería tomar la interacción hombre-máquina
El paradigma de construcción de prototipos se inicia con la comunicación. El ingeniero de software y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es necesaria más definición. Entonces se plantea con rapidez una iteración de construcción de prototipos y se presenta el modelado (en la forma de un diseño rápido). El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el usuario final. El diseño rápido conduce a la construcción de un prototipo. Después, el prototipo lo evalúa el usuario y con la retroalimentación se refinan los requisitos del software que se desarrollará. La iteración ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo se desarrollador entienda mejor lo que se debe hacer.
Ventajas:
- No modifica el flujo del ciclo de vida.
- Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios.
- Reduce costos y aumenta la probabilidad de éxito.
- Exige disponer de las herramientas adecuadas.
- No presenta calidad ni robustez.
- Una vez identificados todos los requisitos mediante el prototipo, se construye el producto de ingeniería.
Inconvenientes:
A los usuarios les gusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. Sin embargo, la construcción de prototipos se torna problemática por las siguientes razones:
A los usuarios les gusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. Sin embargo, la construcción de prototipos se torna problemática por las siguientes razones:
- El cliente ve funcionando lo que para el es la primera versión del prototipo que ha sido construido con “chicle y cable para embalaje”, y puede decepcionarse al indicarle que el sistema aun no ha sido construido.
- El desarrollador puede caer en la tentación de aumentar el prototipo para construir el sistema final sin tener en cuenta los obligaciones de calidad y de mantenimiento que tiene con el cliente.
El Modelo en Espiral
Este es un modelo de proceso de software evolutivo, el cual enlaza la naturaleza iterativa de la construcción de prototipos, pero conservado aquellas propiedades del modelo en cascada.
El modelo en espiral fue desarrollado por Boehm, quien lo describe así: El modelo de desarrollo en espiral es un generador de modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniería de software concurrente y a la vez con muchos usuarios. Que tiene dos caracteristicas:
- Un enfoque cíclico para el crecimiento incremental del grado de definición e implementación de un sistema, mientras que disminuye su grado de riesgo.
- Un conjunto de puntos de fijación para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.
"clic pra ver mejor"
Cuando empieza este proceso evolutivo, el equipo de ingeniería del software gira alrededor de la espiral en la dirección de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral puede producir el desarrollo de una especificación de productos; los pasos siguientes en la espiral se podrían utilizar para desarrollar un prototipo y progresivamente versiones más sofisticadas del software. Cada paso por la región de planificación produce ajuste en el plan del proyecto. El coste y la planificación se ajustan con la realimentación ante la evoluación del cliente. Además, el gestor del proyecto ajusta el número planificado de iteraciónes requeridas para completar el software.
A diferencia del modelo de proceso clásico que termina cuando se entrega el software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. Una visión alternativa del modelo en espiral puede ser considerada examindo el eje de punto de entrada en el proyecto.
Cada uno de los cubos situados a lo largo del eje puede usarse para representar el punto de arranque para los diferentes tipos de proyectos. Un proyecto de desarrollo de concepto comienza en el centro del espiral continuara hasta que se completa el desarrollo del concepto. Si el concepto se va a desarrollar dentro de un producto real, el producto continúa a través del cubo siguiente y se inicia un nuevo proyecto de desarrollo.
DESVENTAJAS
- Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.
- Es nuevo (1988) y no se ha utilizado tanto como otros modelos de ciclo de vida.
- Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.
VENTAJAS
- El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora.
- Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los nivele evolutivos.
- El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.
- El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se conviertan en problemas.
- En la utilización de grandes sistemas a doblado la productividad.
El Modelo de Desarrollo Concurrente
El modelo de desarrollo concurrente, se representa de una forma esquematica como una serie de actividades del marco de trabajo, acciones de la ingenieria del software y sus estados asociados.
La figura siguiente proporciona una representación esquemática de una actividad dentro del modelo de proceso concurrente. La actividad “modelado” se puede encontrar en uno de los estados destacados anteriormente en cualquier momento dado. De forma similar otras actividades se pueden representar de una forma análoga. Todas las actividades existen concurrentemente, pero residen en estados diferentes. Por ejemplo: al principio del proyecto, la actividad de comunicación con el cliente (no mostrada en la figura) ha finalizado su primera interacción y existe en el estado de cambios en espera. La actividad de análisis (que existía en el estado ninguno mientras que comenzaba la comunicación inicial con el cliente) ahora hace una transición al estado bajo desarrollo. Sin embargo, si el cliente indica que se deben hacer cambios en requisitos, la actividad análisis cambia del estado bajo desarrollo al estado cambios en espera.
El modelo de proceso concurrente define una serie de acontecimientos que dispararan transiciones de estado a estado para cada una de las actividades de la ingeniería del software. Por ejemplo, durante las primeras etapas del diseño, no se contempla una inconsistencia del modelo de análisis. Esto genera la corrección del modelo de análisis de sucesos, que disparara la actividad de análisis del estado hecho al estado cambios en espera.
"clik para ver mejor"
