You are on page 1of 3

Jhonis Bermudez

Tics

Ciclos de vida del software


Introducción
Cualquier producto a desarrollar tiene un comienzo y un fin. Así, el software tiene
una vida, un ciclo de vida, que determina qué tipo de producto se tendrá. Este ciclo
está compuesto de distintas etapas, y puede ser muy variado dependiendo de lo que
se quiere construir, de su tamaño, del presupuesto, de la capacidad del equipo, de la
experiencia de los desarrolladores, etc.
El ciclo de vida es un enfoque que sostiene que los sistemas son desarrollados de
mejor manera mediante el uso de un ciclo específico de actividades del analista, el
desarrollador y el usuario.

Etapas del ciclo de vida


Las etapas que constituyen el Ciclo de Vida pueden variar, según el autor que se
consulte; sin embargo, como mínimo deben estar contemplados los siguientes
elementos:
 Planeación: Especificaciones iniciales, factibilidad
 Desarrollo: Construcción del software
 Operación: Uso del sistema
 Mantenimiento: Corrección y actualización
El Ciclo de Vida más tradicional contempla:
 Análisis de Requerimientos
 Especificación
 Diseño
 Implementación
 Integración
 Mantenimiento
 Retiro

Análisis de Requerimientos
El equipo de desarrollo se reúne con el Cliente para entender la problemática y lo
que se espera que resuelva “el software”. El entregable esperado en esta etapa es
un documento que concentre los REQUERIMIENTOS DEL USUARIO.

Especificación
Considerando los Requerimientos, se genera una especificación de la “funcionalidad”
a ser incluida. Además establece una metodología de desarrollo y una estimación de
tiempos y costos.

Diseño
Tomando la especificación funcional, los diseñadores generan el diseño detallado y la
arquitectura general del software, así como la interfaz para el usuario.

Implementación
Basados en el diseño, los programadores codifican todos los componentes
relacionados.

Integración
Los componentes y módulos se combinan y prueban.
Jhonis Bermudez
Tics

Ciclo de Vida (SDLC)

Mantenimiento
Una vez aceptado el producto original, cualquier modificación posterior se considera
como mantenimiento.

Retiro
Cuando el producto es eliminado.

Mantenimiento de Software
Tipos de actividades durante el mantenimiento de software:
 Corregir errores (mantenimiento correctivo)
 Adaptación (revisión, funciones)
 Perfectivo (mejoras o modificaciones)
 Preventivo (reingeniería)

Problemas en el mantenimiento
 Es difícil o imposible seguir el proceso de evolución del software a través de
varias versiones. Los cambios no están documentados adecuadamente.
 Es muy difícil entender el programa de “alguien” más.
 Ese “alguien” muy a menudo no se encuentra para explicarlo, debido a la
rotación de personal.
 La documentación no existe o es inadecuada.
 Mucho software no está diseñado para el cambio.

Modelos de Ciclo de Vida del Software


Un primer ciclo de vida, desorganizado y cuyo resultado tiende al fracaso, es el de
construir y corregir o en inglés conocido como “build and fix”. En este ciclo el
desarrollador directamente se sienta a programar sin hacer diseño o análisis alguno,
corrigiendo continuamente hasta tener, en el mejor de los casos, el producto
terminado, difícilmente mantenible y/o modificable. Este ciclo de vida no se
recomienda en ningún caso, ya que se ha comprobado que incluso en desarrollos
atómicos (por ejemplo una función) algo de diseño, en papel, un diagrama burdo por
ejemplo, ayudan más que no haber hecho nada.
El ciclo de vida más difundido y el único utilizado hasta los años 80’s, es el conocido
como “cascada”. El ciclo de vida de cascada consiste, fundamentalmente, de las
etapas de análisis de requerimientos, diseño, construcción, pruebas e implantación.
Una etapa inicia hasta que termina la anterior con actividades de validación de los
entregables al final de cada etapa. Está basado en documentos y obliga a la
formalidad, atacando de esta manera desventajas del ciclo de construir y corregir.
Sin embargo, tiende a ser muy largo y dada que una etapa no inicia hasta que la
anterior termina, la retroalimentación del cliente es tardía y muchos de los proyectos
Jhonis Bermudez
Tics

utilizando este ciclo de vida fallan por no haber entendido los requerimientos del
usuario (documentos ambiguos y difíciles de leer) y por lo tanto, generando un
producto que el cliente no necesita y no va a utilizar. Otro problema con este ciclo de
vida es que ignora que los requerimientos no son estáticos sino que cambian
rápidamente y que el producto generado debe irse ajustando a dichos cambios.
A fin de garantizar que los requerimientos sean claros y que el producto se ajuste a
cambios en éstos, se han creado otros ciclos de vida como los siguientes:
 Prototipo rápido
 Incremental
 Evolutivo
 Espiral

Acorde con Craig Larman (2005) el ciclo de vida iterativo y evolutivo consiste de una
serie de iteraciones cortas y fijas en duración (entre dos y seis semanas). Al final de
cada iteración se tiene una parte del producto que se ha probado e integrado a la
anterior. Cada iteración a su vez, sigue las fases del ciclo de cascada. En las
primeras iteraciones se buscará implementar los requerimientos centrales del
sistema o los que impliquen mayor riesgo.
Ya que las iteraciones tienen duración fija, las fechas de entrega son inamovibles así
que si no se puede cumplir con los requerimientos establecidos, se cambiará el
alcance dejando requerimientos para una iteración posterior.
Los principales beneficios de este tipo de desarrollo son: [Larman, 2005]:
 Menor probabilidad de que el proyecto falle.
 Mayor productividad.
 Mitigación de riesgos en iteraciones tempranas.
 Progreso visible en un corto tiempo.
 Retroalimentación oportuna.
 En cada iteración se genera conocimiento que permitirá mejorar las subsecuentes
iteraciones.

Un proceso iterativo y evolutivo popular actualmente es el UP (Unified Process). Esta


metodología es implementada comercialmente en el RUP (Rational Unified Process),
un refinamiento del Proceso Unificado que provee las herramientas para realizar y
documentar las fases del proceso.

[Larman, 2005] Larman, Craig. “Applying UML and Patterns: an Introduction to


object-oriented análisis and design and iterative development”. Prentice Hall. 3rd ed.
2005.

You might also like