1. Ciclo de Vida del Software
Introduccion
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.
El primer ciclo de vida del software, "Cascada", fue definido por Winston
Royce a fines del 70. Desde entonces muchos equipos de desarrollo han
seguido este modelo. Sin embargo, desde 10 a 15 años atrás, el modelo
cascada ha sido sujeto de numerosas críticas, debido a que es restrictivo y
rígido, lo cual dificulta el desarrollo de proyectos de software moderno. En
su lugar, muchos modelos nuevos de ciclo de vida han sido propuestos,
incluyendo modelos que pretenden desarrollar software más rápidamente, o
más incrementalmente o de una forma más evolutiva, o precediendo el
desarrollo a escala total con algún conjunto de prototipos rápidos.
Definición de un Modelo de Ciclo de Vida
Un modelo de ciclo de vida de software es una vista de las actividades que
ocurren durante el desarrollo de software, intenta determinar el orden de las
etapas involucradas y los criterios de transición asociadas entre estas
etapas.
Un modelo de ciclo de vida del software:
 Describe las fases principales de desarrollo de software.
 Define las fases primarias esperadas para ser ejecutadas durante
esas fases.
 Ayuda a administrar el progreso del proyecto, y
 Provee un espacio de trabajo para la definición de un detallado
proceso de desarrollo de software.
Así, los modelos por una parte suministran una guía para los
desarrolladores de software con el fin de ordenar las diversas actividades
técnicas en el proyecto, por otra parte suministran, un marco para la
administración del desarrollo y el mantenimiento, en el sentido en que
permiten estimar recursos, definir puntos de control intermedios, monitorear
el avance, etc.

2. Modelos de ciclo de vida
Es el conjunto de etapas que describen el proceso de desarrollo de software
desde su nacimiento hasta su reemplazo o eliminación.
Se compone de las siguientes fases:
¿…Que es Fase…?. Conjunto de actividades relacionadas con un objetivo en el
desarrollo de un proyecto. Se construye agrupando tareas (actividades
elementales) que pueden compartir un tramo determinado del tiempo de vida de
un proyecto. La agrupación temporal de tareas impone requisitos temporales
correspondientes a la asignación de recursos (humanos, financieros o materiales).
Cuanto más grande y complejo sea un proyecto, mayor detalle se necesitará en la
definición de las fases para que el contenido de cada una siga siendo manejable.
De esta forma, cada fase de un proyecto puede considerarse un “micro-proyecto”
en sí mismo, compuesto por un conjunto de micro-fases.

3. REQUISITOS

Definición de objetivos: definir el resultado del proyecto y su
papel en la estrategia global.
o
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.
o
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.
ANALISIS
DISEÑO
o
CODIFICACION
o
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.
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: el propósito de la prueba de integración es
garantizar que los diferentes módulos se integren con la
aplicación. esta debe estar cuidadosamente documentada en la
liberación.
Prueba beta (o validación), para garantizar que el software
cumple con las especificaciones originales.
PRUEBAS
o
o

4. LIBERACION (release)
o
o
o
Documentación: sirve para documentar información necesaria
para los usuarios del software y para futuros desarrollos.
Implementación definitiva de la aplicación.
Mantenimiento: para todos los procedimientos correctivos
(mantenimiento correctivo) y las actualizaciones secundarias del
software (mantenimiento continuo).
Los Enfoques o paradigmas de desarrollo de software
. Orientado por procedimientos o Estructurado
. Orientado por datos
. Orientado por objetos
PARADIGMAS DE CICLO DE VIDA DE DESARROLLO DE SOFTWARE
PARADIGMA DE CASCADA
Es el modelo más antiguo, propuesto por Winston Royce, comenzó a diseñarse en
1966 y terminó alrededor de 1970.
Es una secuencia de fases de un subconjunto de los procesos de desarrollo y
Administración, en la que al final de cada una de estas fases, se reúne la
documentación adecuada para garantizar que cumpla unas especificaciones y
requisitos, antes de pasar a su próxima fase.
En este paradigma se reconocen las siguientes etapas o fases para el desarrollo
del software:



El Análisis de Requerimientos
La Especificación de Requerimientos
El Diseño Externo o de la interfaz con el usuario.

5. Menús manejadores de entrada, pantallas o informes de salida,
sonidos de retroalimentación. (def: todo eco (salida de datos) que puede ser
reutilizado para pruebas.)
Diseño Interno
1.
2

Diseño estructural, Puede ser simultáneo con el de interfaz de
usuario. Aquí se definen la estructura del sistema (componentes
modulares y sus interrelaciones) y la mayoría de las estructuras de
datos.
Diseño detallado, Detalle de cómo implementar cada uno de los
componentes del diseño estructural.
La Implementación.
Codificación.
Prueba.
 El Mantenimiento.

6. DESVENTAJAS DEL PARADIGMA DE CASCADA





Gran énfasis en la producción de documentos completamente
elaborados, producto de las fases de análisis y especificación de
requerimientos y de diseño.
No muy aplicable a productos de software altamente interactivos
(dinámicos).
Es difícil tener todos los requerimientos, bien definidos al principio,
como lo requiere el modelo y además presenta dificultades para
acomodar posibles incertidumbres existentes al comienzo de los
proyectos.
Los productos de software raramente siguen el flujo secuencial que
propone el modelo.
Siempre hay iteraciones y se crean problemas en la aplicación del

7. 




paradigma.
Un error importante no detectado al principio puede ser desastroso.
Se requiere mucha paciencia por parte del cliente, porque solo hasta
las etapas finales del desarrollo podrá tener una versión operativa del
producto.
No aprovecha la iteración, ni el desarrollo exploratorio.
Dificultad para integrar administración del riesgo.
Hacer cambios es difícil y costoso.
VENTAJAS DEL PARADIGMA DE CASCADA






Fácil entendimiento e implementación.
Ampliamente utilizado y conocido (En teoría).
Refuerza buenos hábitos: definir antes que diseñar, diseñar antes
que codificar.
Identifica entregables (son los resultados del proyecto entregados al cliente) e
hitos(son las puntas finales de una actividad de un proceso).
Orientado a documentos.
Funciona bien en productos maduros y equipos débiles.
PARADIGMA CODIFICAR Y CORREGIR
El modelo codificar y corregir es el modelo utilizado cuando no nos paramos en
buscar el modelo más idóneo para nuestro proyecto. Es decir en este modelo no
se pierde el tiempo en la planificación, en la calidad, en los documentos que hay
que realizar cuando se terminan etapas o en cualquier otra actividad que no sea la
codificación. Por lo tanto este modelo no se necesita tener experiencia y una gran
cantidad de conocimientos.
Al no seguir un modelo no tenemos ningún medio de ver si se cumplen las
expectativas creadas, lo cual es un problema si encontramos un error casi al
finalizar el proyecto ya que hay que empezar de nuevo. Por consiguiente tardamos
más en ver los errores que en otro modelo que sigue un mínimo de planificación.
PARADIGMA EN V
Busca hacer la actividad de pruebas más efectiva y productiva.
Los planes (y casos de prueba) se van elaborando a medida que se avanza
en el desarrollo del proyecto.

8. Las actividades desde requerimientos hasta implementación se enfocan en
una representación detallada del sistema, mientras que las actividades de
implementación hasta operación se enfocan en la validación del sistema.

9. EL PARADIGMA DE PROTOTIPO
Puede tomar alguna de las siguientes formas:



Un escenario (simulación del uso del sistema)
Una demostración (porciones de código que realizan algunas funciones)
Una versión cero(0) ( aplicación liberada (release) que puede usarse bajo
condiciones preliminares añadiendo, cambiando o quitando funciones
existentes y creándole su documentación)
Cuando se Usa: Cuando los requerimientos no son claros o no se identifican en
forma detallada los requerimientos de entrada, salida y funciones.
Características:







El uso de prototipos no es exclusivo del ciclo de vida iterativo.
Los prototipos se pueden usar como una herramienta para obtener y
validar los requisitos de clientes y usuarios en cualquier ciclo de vida.
Lo habitual es usar prototipos de interfaz de usuario, que pueden
reutilizarse (ejecutables) o desecharse (papel).
Siempre se debe evaluar si el esfuerzo de desarrollo del prototipo
merece la pena (costo de errores).
Es fundamental la implicación de los usuarios.
Otro tipo de prototipos pueden utilizarse para evaluar diferentes
algoritmos antes de tomar decisiones de diseño.
Siempre se debe tener en cuenta que el prototipo no es el producto
final, ya que su calidad no suele ser la necesaria.
VENTAJAS DEL PARADIGMA DE PROTOTIPOS




Son reales y tangibles.
Permite al cliente aclarar lo que quiere que haga el sistema.
Siente que es oído y tenido en cuenta para el diseño (cliente).
Asegura que el trabajo se está haciendo bien y cumpliendo los
requerimientos del cliente.
DESVENTAJAS DEL PARADIGMA DE PROTOTIPOS

El cliente puede creer que el sistema ya está listo y pedir su entrega
rápida.
 Crea expectativas más allá de lo que realmente puede hacer.
 Se dificulta la dirección y control del proceso de desarrollo más que en el

10. método clásico.
 La presión por entregar rápido el producto compromete la calidad.
 Se dificulta mantener el entusiasmo del cliente después de aprobado el
prototipo porque creerá que se desperdicia el tiempo en detalles
insignificantes.
Componentes software

Cada vez es más frecuente el ensamblaje de componentes software
desarrollados por terceros en la construcción de nuevos sistemas
software.

El uso de componentes tiene implicaciones en todas las actividades del
desarrollo desde los requisitos hasta el mantenimiento.

11. Ingeniería inversa

A veces es necesario mantener sistemas heredados (legacy systems) que
fueron desarrollados sin documentación.
 La ingeniería inversa consiste en analizar el resultado de una etapa de
software para obtener el resultado o la solucion de la anterior; normalmente
analizar el código para obtener el diseño.
Reingeniería

La reingeniería utiliza la información obtenida por la ingeniería inversa
para aplicar cualquier tipo de mantenimiento:
o Perfectivo: modificación de un producto software después de la
entrega para mejorar el rendimiento o la mantenibilidad).
o Adaptativo: modificación de un producto software realizada después
de la entrega para permitir que un producto software siga
pudiéndose utilizar en un entorno diferente.

12. o Correctivo: modificaciones reactivas a un producto software hechas
después de la entrega para corregir defectos descubiertos.
o Preventivo: modificaciones reactivas a un producto software hechas
en base a una planeación y a un cronograma.
o Emergencia: cuando los cambios se deben hacer sin planificación
previa, para mantener un sistema en operación.

El mantenimiento preventivo del efecto 2000 (y2k) ha sido el mayor
esfuerzo de ingeniería inversa, reingeniería y mantenimiento en la historia
de la Ingeniería del Software.
PARADIGMA DE ESPIRAL
Es un modelo de proceso de software evolutivo. En el modelo espiral, el software
se desarrolla en una serie de versiones increméntales. Durante las primeras
iteraciones. La versión incremental podría ser un modelo en papel o un prototipo.
Durante las últimas iteraciones, se producen versiones cada vez más completas
de ingeniería del sistema.
Características










Propuesto por Bohem en 1987
Modelo centrado en la actividades
Introduce: manejo de riesgos y creación de prototipos, no incluidas
anteriormente.
Es el mejor modelo para grandes sistemas.
Su elevada complejidad desaconseja su uso en sistemas pequeños.
Las actividades son organizadas en ciclos.
Es ideal para crear productos con diferentes versiones mejoradas como se
hace con el software moderno de microcomputadoras.
La ingeniería puede desarrollarse y/o combinarse a través del ciclo de vida
clásico o el de construcción de prototipos.
Este es el enfoque más realista actualmente.
Un ciclo corresponde a la construcción de un producto intermedio,
Y este contempla los siguientes elementos:

Concepto de operación.

13. 








Requerimientos de software.
Diseño de productos del sistema.
Diseño detallado.
Código.
Prueba unitaria.
Integración y pruebas.
Prueba de aceptación.
Implementación.
Las fases de cada ciclo son:
1. Identificar alternativas, restricciones y objetivos.
2. Administrar Riesgos.
3. Desarrollar y validar un prototipo.
4. Planear la siguiente fase.
1
4
2
3
El proyecto P1 se encuentra en la actividad de análisis de riesgos asociados
con los requerimientos de software, mientras que el proyecto P2 está en el
desarrollo del diseño de productos del sistema.

14. El modelo en espiral se divide en un numero de actividades estructurales, también
llamadas regiones de tareas. Pero Generalmente, pueden existir entre cuatro y
seis regiones de tareas.
Comunicación con el cliente: las tareas requeridas para establecer
comunicación los desarrolladores y el cliente.
Planificación: las tareas requeridas para definir recursos, el tiempo y otras
informaciones relacionadas con el proyecto. Son todos los requerimientos.
Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras
informaciones relacionadas con el proyecto.
Ingeniería: las tareas requeridas para construir una o más representaciones de la
aplicación.
Construcción y adaptación: las tareas requeridas para construir, probar, instalar
y proporcionar soporte al usuario.
Evaluación el cliente: las tareas requeridas para obtener la reacción del cliente
según la evaluación de las representaciones del software creadas durante la etapa
de ingeniería e implementación durante la etapa de instalación.
Cuando empieza el 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 produce 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 mas sofisticadas del software. Cada

15. paso de la región de planificación produce ajustes en el plan del proyecto. El coste
y la planificación se ajustan según la reacción ante la evolución del cliente.
VENTAJAS:





El modelado en espiral puede adaptarse y aplicarse a lo largo de la vida del
software de computadora, no termina cuando se entrega el software.
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 niveles evolutivos.
Permite a quien lo desarrolla aplicar el enfoque de construcción de
prototipos en cualquier etapa de evolución del producto.
Demanda una consideración directa de los riesgos técnicos en todas las
etapas del proyecto.
Reduce los riesgos antes de que se conviertan en problemáticos.
Pero al igual que otros paradigmas puede resultar difícil convencer a grandes
clientes de que el enfoque evolutivo es controlable. Si un riesgo importante no es
descubierto y gestionado, indudablemente surgirán problemas. El modelo en sí
mismo es relativamente nuevo y no se ha utilizado tanto como los paradigmas
lineales secuenciales o de construcción de prototipos. Todavía tendrán que pasar
muchos años antes de que se determine con absoluta certeza la eficacia de este
nuevo e importante paradigma.
La siguiente figura define un eje de punto de entrada en el proyecto. Cada uno de
los cubos situados a lo largo del eje representa el punto de arranque para un tipo
diferente de proyecto. Un proyecto de desarrollo de conceptos comienza en el
centro de la espiral y continuara hasta que se completa el desarrollo del concepto.
Si el concepto se va a desarrollar dentro de un producto real, el proceso procede a
través del cubo siguiente y se inicia un nuevo proyecto de desarrollo.

16. PROBLEMAS:


Demostrar al cliente "exigente" (bajo contrato) que el enfoque evolutivo es
controlable.
Requiere gran habilidad y experiencia para valorar el riesgo y saber cuándo
detener la evolución
PARADIGMA DE PROCESO UNIFICADO
El Proceso Unificado de Desarrollo Software o simplemente Proceso
Unificado es un marco de desarrollo de software que se caracteriza por estar
dirigido por casos de uso (def: es una técnica para la captura de requisitos
potenciales de un nuevo sistema o una actualización de software), centrado en la
arquitectura y por ser iterativo e incremental. El refinamiento más conocido y
documentado del Proceso Unificado es el Proceso Unificado de Rational o
simplemente RUP.
El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo
extensible que puede ser adaptado a organizaciones o proyectos específicos. De
la misma forma, el Proceso Unificado de Rational, también es un marco de trabajo
extensible, por lo que muchas veces resulta imposible decir si un refinamiento

17. particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho
motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.
El nombre Proceso Unificado se usa para describir el proceso genérico que
incluye aquellos elementos que son comunes a la mayoría de los refinamientos
existentes. También permite evitar problemas legales ya que Proceso Unificado de
Rational o RUP son marcas registradas por IBM (desde su compra de Rational
Software Corporation en 2003). El primer libro sobre el tema se denominó, en su
versión española, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829036-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James
Rumbaugh que a la vez son los creadores de este paradigma.
Características principales
Iterativo e Incremental
El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto
de cuatro fases denominadas Inicio, Elaboración, Construcción y Transición.
Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que
recuerdan a las definidas en el ciclo de vida clásico o en cascada: Análisis de
requisitos, Diseño, Implementación y Prueba. Aunque todas las iteraciones suelen
incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada
una de ellas varía a lo largo del proyecto.
Dirigido por los casos de uso
En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos
funcionales y para definir los contenidos de las iteraciones
Centrado en la arquitectura
El Proceso Unificado asume que no existe un modelo único que cubra todos los
aspectos del sistema. Por dicho motivo existen múltiples modelos y vistas que
definen la arquitectura de software de un sistema. La analogía con la construcción
es clara, cuando construyes un edificio existen diversos planos que incluyen los
distintos servicios del mismo: electricidad, fontanería, etc.

18. Enfocado en los riesgos
El Proceso Unificado requiere que el equipo del proyecto se centre en identificar
los riesgos críticos en una etapa temprana del ciclo de vida. Los resultados de
cada iteración, en especial los de la fase de Elaboración, deben ser seleccionados
en un orden que asegure que los riesgos principales son considerados primero.
Más características



Consiste en varios ciclos.
Al final de cada uno, un producto es entregado al cliente.
Cada ciclo consiste de cuatro fases:





Inception (inicio - alcance y los objetivos del proyecto)
Elaboration
Construction
Transition
Una iteración construye un conjunto de casos de uso relacionados o
mitiga algún riesgo de los identificados.
DESARROLLO ITERATIVO Y EL PROCESO UNIFICADO

19. Modelo Team Software Process - TSP

20. TALLER
Investigar en qué consiste la norma ISO 12207.
BIBLIOGRAFIA
Bernd Bruegge, Dutoit Allen. Object-Oriented Software Engineering: Using
UML, Patterns, and Java, 2004, Prentice Hall, segunda edición.
http://standards.ieee.org/catalog/olis/arch_se.html