Ciclos de vida del software
Es
la forma mediante la cual se describen los diferentes pasos que se deben seguir
para el desarrollo de un software, partiendo desde una necesidad hasta llegar a
la puesta en marcha de una solución y su apropiado mantenimiento. El ciclo de
vida para un software comienza cuando se tiene la necesidad de resolver un
problema, y termina cuando el programa que se desarrolló para cumplir con los
requerimientos, deja de ser utilizado.
Existen varias versiones del ciclo
de vida del software entre las cuales se destacan: el ciclo de vida clásico o
en cascada, el modelo en espiral, el desarrollo de prototipos, el modelo por
incrementos y el modelo extremo
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.
Estos
programas se originan en el hecho de que es muy costoso rectificar los errores
que se detectan tarde dentro de la fase de implementación. El ciclo de vida
permite que los errores se detecten lo antes posible y por lo tanto, permite a
los desarrolladores concentrarse en la calidad del software, en los plazos de
implementación y en los costos asociados.
El ciclo de vida básico de un software consta de
los siguientes procedimientos:
- Definición de objetivos:
definir el resultado del proyecto y su papel en la estrategia global.
- Análisis de los
requisitos y su viabilidad: recopilar, examinar y formular los requisitos del
cliente y examinar cualquier restricción que se pueda aplicar.
- Diseño general:
requisitos generales de la arquitectura de la aplicación.
- Diseño en detalle:
definición precisa de cada subconjunto de la aplicación.
- Programación (programación e
implementación): es la implementación de un lenguaje de programación para crear
las funciones definidas durante la etapa de diseño.
- Prueba de unidad:
prueba individual de cada subconjunto de la aplicación para garantizar que se
implementaron de acuerdo con las especificaciones.
- Integración:
para garantizar que los diferentes módulos se integren con la aplicación. Éste
es el propósito de la prueba
de integración que está
cuidadosamente documentada.
- Prueba beta (o validación), para garantizar
que el software cumple con las especificaciones originales.
- Documentación:
sirve para documentar información necesaria para los usuarios del software y
para desarrollos futuros.
- Implementación
- Mantenimiento:
para todos los procedimientos correctivos (mantenimiento correctivo) y las
actualizaciones secundarias del software (mantenimiento continuo).
El orden y la presencia de cada uno de estos
procedimientos en el ciclo de vida de una aplicación dependen del tipo de
modelo de ciclo de vida acordado entre el cliente y el equipo de
desarrolladores.
Métodos de Ciclo de Vida del Software
Para cada una de las fases o etapas listadas en
el ítem anterior, existen sub-etapas (o tareas). El modelo de proceso o modelo
de ciclo de vida utilizado para el desarrollo, define el orden de
las tareas o actividades involucradas, también
define la coordinación entre ellas, y su enlace y re alimentación Entre los más
conocidos se puede mencionar: modelo en cascada o secuencial, espiral, modelo. De los antedichos hay a su vez algunas
variantes o alternativas, más o menos atractivas según sea la aplicación
requerida y sus requisitos.
Modelo
en cascada:
En Ingeniería de
software el desarrollo en cascada, también
llamado modelo en cascada,
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.
Un ejemplo de una metodología de
desarrollo en cascada es:
1. Análisis de requisitos.
2. Diseño del Sistema.
3. Diseño del Programa.
4. Codificación.
5. Pruebas.
6. Implantación.
7. Mantenimiento.
De esta forma, cualquier error de
diseño detectado en la etapa de prueba conduce necesariamente al re-diseño y
nueva programación del código afectado, aumentando los costos del desarrollo.
La palabra cascada sugiere, mediante la metáfora de la
fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las
fases más avanzadas de un proyecto.
El modelo de ciclo de vida en cascada comenzó a
diseñarse en 1966 y se terminó alrededor de 1970. Se define como una secuencia
de fases en la que al final de cada una de ellas se reúne la documentación para
garantizar que cumple las especificaciones y los requisitos antes de pasar a la
fase siguiente:
Fases del modelo
Análisis de requisitos
En esta fase se
analizan las necesidades de los usuarios finales del software para determinar
qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD
(documento de especificación de requisitos), que contiene la especificación
completa de lo que debe hacer el sistema sin entrar en detalles internos.
Es importante
señalar que en esta etapa se debe consensuar todo lo que se
requiere del sistema y será aquello lo que seguirá en las siguientes etapas, no
pudiéndose requerir nuevos resultados a mitad del proceso de elaboración del
software.
Diseño del Sistema
Descompone y organiza el sistema en elementos que puedan
elaborarse por separado, aprovechando las ventajas del desarrollo en equipo.
Como resultado surge el SDD (Documento de Diseño del Software), que contiene la
descripción de la estructura relacional global del sistema y la especificación
de lo que debe hacer cada una de sus partes, así como la manera en que se
combinan unas con otras.
Es conveniente distinguir entre diseño de alto nivel o arquitectónico
y diseño detallado. El primero de ellos tiene como objetivo definir la
estructura de la solución (una vez que la fase de análisis ha descrito el
problema) identificando grandes módulos (conjuntos de funciones que van a estar
asociadas) y sus relaciones. Con ello se define la arquitectura de la solución
elegida. El segundo define los algoritmos empleados y la organización del
código para comenzar la implementación.
Diseño del Programa
Es la fase en donde se realizan los algoritmos necesarios para el
cumplimiento de los requerimientos del usuario así como también los análisis
necesarios para saber que herramientas usar en la etapa de Codificación.
Codificación
Es la fase en donde se implementa el código fuente, haciendo uso de
prototipos así como de pruebas y ensayos para corregir errores.
Pruebas
Los elementos, ya programados, se ensamblan para componer el
sistema y se comprueba que funciona correctamente y que cumple con los
requisitos, antes de ser entregado al usuario final.
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.
En la creación de desarrollo de cascada se implementa los códigos
de investigación y pruebas del mismo.
Mantenimiento
Una de las etapas más críticas, ya que se destina un 75% de los
recursos, es el mantenimiento del Software ya que al utilizarlo como usuario
final puede ser que no cumpla con todas nuestras expectativas.
Características
- Es lineal
- Las actividades están relacionadas secuencial mente
- Cada etapa tiene una entrada y una salida
- Es rígido y sistemático: La entrada de una
actividad es la salida de la etapa anterior, por lo cual no se puede dar inicio
a la siguiente fase.
- Es monolítico: Existe una única fecha de entrega.
- La implementación se pospone hasta que no se
comprendan los objetivos.
- Los documentos a entregar rigen el proceso de
software
- Impone la
necesidad de mucha disciplina planificación y administración, en el proceso de
desarrollo de software, venciendo así la filosofía de los procesos de codificar
y probar
- Impone la
necesidad de que la realización del producto debe ser pospuesta hasta que los
objetivos sean bien entendidos.
- Retrasa la detección de errores hasta el final por
lo cual es muy difícil realizar cambios cuando el proceso está en las últimas
fases.
- Toma mucho tiempo ver los resultados
- Es difícil mantener la trazabilidad entre los
requerimientos iniciales y el código final.
- Cuando los requerimientos no están bien definidos
no es posible aplicar éste modelo pues ello incrementaría los riesgos y
retrasaría el proceso.
- Si los requerimientos del usuario varían es muy
difícil satisfacerlo si el proceso se encuentra en las últimas fases.
- El costo de detectar errores en etapas avanzadas es
muy alto dado que ello modificaría todo lo que se ha desarrollado.
Modelo
en Espiral:
La
meta del modelo espiral del proceso de producción del software es proporcionar
un marco para diseñar tales procesos, dirigido por los niveles de riesgo en el
proyecto actual. En comparación con los actuales modelos, el modelo espiral se
puede ver como meta modelo, porque puede acomodar cualquier modelo de proceso
del desarrollo. Usándolo como referencia, se puede elegir el modelo de
desarrollo más apropiado (e.g., evolutivo con la cascada).
Los
riesgos son las circunstancias potencialmente adversas que pueden deteriorar el
proceso del desarrollo y la calidad del producto. Boehm [1989] define la
gerencia de riesgo como "disciplina cuyo objetivos es identificar, tratar,
y eliminar artículos del riesgo del software antes de que se conviertan en las
amenazas al adecuado funcionamiento del software o la fuente importante de la
reanudación costosa del software." El modelo de espiral se enfoca
en identificar y eliminar los
problemas de alto riesgo con
el diseño de un proceso cuidadoso, más
que tratar problemas triviales.
La
característica principal del modelo espiral es que es cíclico y no lineal como
el modelo de la cascada. Cada ciclo del espiral consiste en cuatro etapas, y
cada etapa es representada por un cuadrante del plano cartesiano. El radio del
espiral representa el coste acumulado hasta ahora en el proceso; la dimensión
angular representa el progreso en el proceso.
La
etapa 1 identifica los objetivos de la porción del producto bajo
consideración, en términos de calidades ha alcanzar. Además, identifica
alternativas -tales como si comprar, diseñar, o reutilizar cualesquier
software- y restricciones en el uso de las alternativas. Las alternativas
entonces se evalúan en la etapa 2 y se identifican y se tratan las áreas
potenciales del riesgo. La estimación del riesgo puede requerir la
planificación de diversas clases de actividades, por ejemplo Prototipaje o la
simulación. La etapa 3 consiste en el desarrollo y verificación del
próximo nivel del producto; otra vez, la estrategia seguida por el proceso es
dictada por el análisis del riesgo.
Cuando
los requerimientos están bien definidos, se puede elegir como opción un modelo
convencional como el de la cascada, que conduce a una simple vuelta a la
espiral. Cuando los requerimientos no
están claramente definidos, se puede seleccionar un modelo de naturaleza
evolutiva; en este caso se necesitarían varias vueltas a la espiral para alcanzar los resultados deseados.
También puede realizarse cualquier combinación con los modelos vistos anteriormente.
Finalmente,
la etapa 4 consiste en repasar
los resultados de las etapas transitadas hasta ahora y el planear la iteración
siguiente del espiral, si la hay.
El modelo espiral permite
obtener mayor robustez en el proceso de desarrollo del software.
Ciclos e Iteraciones
En cada vuelta o iteración hay que tener en cuenta:
- Los Objetivos: qué necesidad debe cubrir el producto.
- Alternativas: las diferentes formas de conseguir los objetivos de forma exitosa,
desde diferentes puntos de vista como pueden ser:
1. Características: experiencia del personal, requisitos a
cumplir, etc.
2. Formas de gestión del sistema
3. Riesgo asumido con cada alternativa.
- Desarrollar y Verificar: Programar
y probar el software.
- Si el resultado no es el adecuado o se
necesita implementar mejoras o funcionalidades:
- Se planificaran los siguientes pasos y se comienza
un nuevo ciclo de la espiral. La espiral tiene una forma de caracola y se dice que mantiene dos
dimensiones, la radial y la angular:
1.
Angular: Indica el avance del proyecto del software dentro de un ciclo.
2.
Radial: Indica el aumento del coste del proyecto, ya que con cada nueva
iteración se pasa más tiempo desarrollando.
Este sistema es muy utilizado en
proyectos grandes y complejos como puede ser, por ejemplo, la creación de un
Sistema Operativo.
Al ser un modelo de Ciclo de Vida
orientado a la gestión de riesgo se dice que uno de los aspectos fundamentales
de su éxito radica en que el equipo que lo aplique tenga la necesaria
experiencia y habilidad para detectar y catalogar correctamente los riesgos.
Características:
- Es un modelo que puede combinarse con
otros modelos de procesos de desarrollo.
- Es el mejor modelo que se utiliza para
desarrollar grandes sistemas.
- El análisis de riesgo requiere la participación de personal
con experiencia.
Ventajas
- Modelo de
proceso adaptable.
- El modelo de
espiral puede aplicarse a lo largo de la vida del software.
- Es apropiado
para desarrollar Sistemas Operativos.
Desventajas
- No se ha
utilizado mucho ya que es un modelo nuevo.
- Debido a la
complejidad no se recomienda utilizarlo en sistemas pequeños.
- Es un modelo
costoso.
https://www.google.com.co/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&ved=0CD4QFjAC&url=http%3A%2F%2Fwww.uruak.com%2Fubv%2FModelos.doc&ei=wgo8UaHZPJTe8wSQw4HQAQ&usg=AFQjCNHc8RH53XM8EaGDRQbhBrZ9gYd1PQ&sig2=i5qTGxEye4Yyxo9v0quT7A&bvm=bv.43287494,d.eWU
http://es.wikipedia.org
.png)
