Modelos de Desarrollo de SI

Ciclos de Vida
• Los sistemas no responden a las expectativas
de los usuarios.
• Los programas “se caen” con cierta frecuencia.
• Los costos del software son difíciles de prever
y normalmente superan las estimaciones
propuestas con anterioridad.
• La modificación del software es una tarea
difícil y costosa.
Casi siempre se debe aplicar un modelo de ciclo de vida. Según varias
fuentes consultadas se estima que, del total de proyectos software
grandes emprendidos, un 28% fracasan, un 46% caen en severas
modificaciones que lo retrasan y un 26% son totalmente exitosos.

Cuando un proyecto de desarrollo de software “fracasa” (28%

estadísticamente), muy rara vez es causado por fallas técnicas,
principalmente el origen de los fallos y fracasos es la falta de aplicación
de una buena metodología o procesos de desarrollo.

Una fuerte tendencia, desde hace pocos años, es mejorar las

metodologías y procesos, o crear nuevas e incentivar a los
profesionales de la informática en su aplicación adecuada.
 Modelos de Desarrollo de SI
• Un modelo para el desarrollo de software es una perspectiva de las
actividades que ocurren durante el diseño y el desarrollo del software,
se pretende determinar el orden de las etapas implicadas en el
sistema y los criterios de transición asociadas entre estas etapas.

• Un modelo de ciclo de vida del software:

• Describe las etapas primordiales del desarrollo de software.
• Ayuda a administrar el progreso del desarrollo, y
• Provee un espacio de trabajo para la definición de un
detallado proceso de desarrollo de software.

• Así, los modelos por una parte proveen una guía a los ingenieros de
software con el fin de establecer las diversas actividades técnicas en el
proyecto, por otra parte suministran un marco para la administración
del desarrollo y el mantenimiento del software.
 Modelo de Cascada
• Este es el más básico de todos los modelos y
ha servido como bloque de construcción para
los demás paradigmas de ciclo de vida. Está
basado en el ciclo convencional de una
ingeniería y su visión es muy simple: el
desarrollo de software se debe realizar
siguiendo una secuencia de fases. Cada etapa
tiene un conjunto de metas bien definidas y
las actividades.
 Modelo de Cascada
El arquetipo del ciclo de vida abarca las siguientes actividades:
• Ingeniería y Análisis del Sistema: Debido a que el software es siempre parte de un
sistema mayor, el trabajo comienza estableciendo los requisitos de todos los elementos
del sistema y luego asignando algún subconjunto de estos requisitos al software.
• Análisis de los requisitos del software: el proceso de recopilación de los requisitos se
centra e intensifica especialmente en el software. El analista debe comprender el
ámbito de la información del software así como la función, el rendimiento y las
interfaces requeridas.
• Diseño: el diseño del software se enfoca en cuatro atributos distintos del programa; la
estructura de los datos, la arquitectura del software, el detalle procedimental y la
caracterización de la interfaz. El proceso de diseño traduce los requisitos en una
representación del software con la calidad requerida antes de que comience la
codificación.
• Codificación: el diseño debe traducirse en una forma legible para la maquina.
• Prueba: una vez que se ha generado el código comienza la prueba del programa. La
prueba se centra en la lógica interna del software y en las funciones externas,
realizando pruebas que aseguren que la entrada definida produce los resultados que
realmente se requieren.
• Mantenimiento: el software sufrirá cambios después de que se entrega al cliente. Los
cambios ocurrirán debidos a que se haya encontrado errores, a que el software deba
adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos)
o a que el cliente requiera ampliaciones funcionales o del rendimiento.
 Modelo de Cascada
• En el modelo vemos una ventaja evidente y radica en su sencillez, ya que sigue los pasos
intuitivos necesarios a la hora de desarrollar el software.
• Tiene una buena aplicación cuando el problema es estable . Este modelo será apropiado para la
migración de una aplicación o a una versión de mantenimiento bien definida.
• Con este modelo se tiene un seguimiento de todas las fases del proyecto y del cumplimiento de
todos los objetivos marcados en cada etapa tanto de costos, fechas de entrega y lo más
importante que pueden comprobar al final de cada etapa si el proyecto cumple todas las
necesidades del usuario.

Pero el modelo se aplica en un contexto, así que debemos atender también a él y saber
que:
• Los proyectos reales raramente siguen el flujo secuencial que propone el modelo. Siempre hay
iteraciones y se crean problemas en la aplicación del paradigma.
• Normalmente, al principio, es difícil para el cliente establecer todos los requisitos
explícitamente. El ciclo de vida clásico lo requiere y tiene dificultades en acomodar posibles
incertidumbres que pueden existir al comienzo de muchos productos.
• El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto no estará disponible
una versión operativa del programa. Un error importante que no pueda ser detectado hasta que
el programa esté funcionando,
• A su vez, si el usuario se da cuenta de que falta una tarea, una vez pasada esta etapa, el trabajo
que hay que realizar se retrasa en fechas de entrega y el costo es mayor.
•
 Modelo de Prototipos
Este fue el modelo inicial planteado para
organizar el proceso de desarrollo, aunque
antiguo tiene vigencia en algunos proyectos o
como parte de otros modelos, da la medida de
los pasos tradicionales de cualquier modelo:
análisis, diseño, codificación, prueba y
mantenimiento.
 Modelo de Prototipos
• El prototipo se construye en poco tiempo, usando
los programas adecuados y no se debe utilizar
muchos recursos.
• El diseño rápido se centra en una representación
de aquellos aspectos del software que serán
visibles para el cliente o el usuario final. Este
diseño conduce a la construcción de un
prototipo, el cual es evaluado por el cliente para
una retroalimentación del software que se
desarrollará.
 Modelo de Prototipos: Etapas
• Plan rápido.
• Modelado, diseño rápido
• Construcción del Prototipo
• Desarrollo, entrega y retroalimentación
• Comunicación
• Entrega del desarrollo final
 Modelo de Prototipos
• Este modelo es útil cuando el cliente conoce los objetivos generales para
el software, pero no identifica los requisitos detallados de entrada,
procesamiento o salida.
• También ofrece un mejor enfoque cuando el responsable del desarrollo
del software está inseguro de la eficacia de un algoritmo, de la
adaptabilidad de un sistema operativo o de la forma que debería tomar la
interacción humano-máquina.
• Se puede reutilizar el código.

• La construcción de prototipos se puede utilizar como un modelo del

proceso independiente, se emplea más comúnmente como una técnica
susceptible de implementarse dentro del contexto de cualquiera de los
modelos del proceso expuestos. Sin importar la forma en que éste se
aplique, el paradigma de construcción de prototipos ayuda al desarrollado
de software y al cliente a entender de mejor manera cuál será el resultado
de la construcción cuando los requisitos estén satisfechos. De esta
manera, este ciclo de vida en particular, involucra al cliente más
profundamente para adquirir el producto.
 Modelo de Prototipos
• El usuario tiende a crearse unas expectativas cuando ve el prototipo
de cara al sistema final. A causa de la intención de crear un
prototipo de forma rápida, se suelen desatender aspectos
importantes, tales como la calidad y el mantenimiento a largo plazo,
lo que obliga en la mayor parte de los casos a reconstruirlo una vez
que el prototipo ha cumplido su función. Es frecuente que el
usuario se muestre reacción a ello y pida que sobre ese prototipo se
construya el sistema final, lo que lo convertiría en un prototipo
evolutivo, pero partiendo de un estado poco recomendado.

• En aras de desarrollar rápidamente el prototipo, el desarrollador

suele tomar algunas decisiones de implementación poco
convenientes (por ejemplo, elegir un lenguaje de programación
incorrecto porque proporcione un desarrollo más rápido). Con el
paso del tiempo, el desarrollador puede olvidarse de la razón que le
llevó a tomar tales decisiones, con lo que se corre el riesgo de que
dichas elecciones pasen a formar parte del sistema final...
 Modelo en Espiral
• Las actividades de este modelo se conforman en una espiral, en la
que cada bucle o iteración representa un conjunto de actividades.
Las actividades no están fijadas a ninguna prioridad, sino en
función del análisis de riesgo, comenzando por el bucle interior.
• El modelo de la espiral es un modelo orientado a riesgo que divide
el proyecto de software en miniproyectos. Cada proyecto se
encargará de resolver uno o varios riesgos hasta que estén todos
controlados. Una vez que estén los riesgos más importantes
controlados se finaliza igual que el ciclo de vida en cascada.
En el ciclo de vida en espiral se localizan los riesgos, se genera un
plan para manejarlos y se establece una aproximación a la siguiente
iteración. Con cada iteración se produce una aproximación al
producto final.
 Modelo en Espiral
El modelo en espiral esta compartida en varias actividades estructurales,
también llamadas regiones de tareas. Existen seis regiones de tareas que son:
• Comunicación con el cliente: esta es una tarea requerida para establecer
comunicación entre el desarrollador y el cliente.
• Planificación: esta tarea es necesaria aplicarla para pode definir los
recursos, el tiempo y otras informaciones relacionadas con el proyecto, es
decir, son todos los requerimientos.
• Análisis de riesgos: esta es una de las tareas principales por lo que se
aplica el modelo en espiral, es requerida para evaluar los riesgos técnicos
y otras informaciones relacionadas con el proyecto.
• Ingeniería: esta es una tarea necesaria ya que se requiere construir una o
más representaciones de la aplicación.
• Construcción y adaptación: esta tarea es requerida en el modelo espiral
porque se necesita construir, probar, instalar y proporcionar soporte al
usuario.
• Evaluación el cliente: esta también es una tarea principal, necesaria para
adquirir la reacción del cliente según la evaluación de las representaciones
del software creadas durante la etapa de ingeniería y la de
implementación creada durante la etapa de instalación.
 Modelo en Espiral
• El análisis del riesgo se hace de forma explícita y clara.
• Une los mejores elementos de los modelos.
• Reduce riesgos del proyecto
• Incorpora objetivos de calidad
• Integra el desarrollo con el mantenimiento, etc.
• Además es posible tener en cuenta mejoras y nuevos requerimientos sin
romper con la metodología, ya que este ciclo de vida no es rígido ni
estático.

• Genera mucho tiempo en el desarrollo del sistema

• Modelo costoso
• Requiere experiencia en la identificación de riesgos

• Planificar un proyecto con esta metodología es a menudo imposible,

debido a la incertidumbre en el número de iteraciones que serán
necesarias. En este contexto la evaluación de riesgos es de la mayor
importancia y, para grandes proyectos, dicha evaluación requiere la
intervención de profesionales de gran experiencia.
 Modelo Incremental
• El desarrollo incremental es el proceso de
construcción siempre incrementando
subconjuntos de requerimientos del sistema.
• En este modelo se desarrolla el sistema para
satisfacer un subconjunto de requisitos
especificados y en posteriores versiones se
incrementa el sistema con nuevas
funcionalidades que satisfagan mas requisitos.
 Modelo Incremental
•Combina elementos del modelo de cascada con la filosofía interactiva de construcción de prototipos
• Cada secuencia lineal produce un producto operacional con cada incremento de la misma forma que
progresa el tiempo en el calendario
• El primer incremento es a menudo el núcleo
• Como un resultado de evaluación y/o utilización se desarrolla un plan para el incremento siguiente,
este proceso se repite hasta llegar al producto completo
• Este modelo es particularmente útil cuando la dotación de personal no es suficiente para una
implementación completa
• Los primeros incrementos se pueden implementar con menos recursos
• Si es muy riesgoso desarrollar el sistema completo de una sola vez, entonces debería considerar este
modelo
VENTAJAS.
• Construir un sistema pequeño es siempre menos riesgoso que construir un
sistema grande.
• Al ir desarrollando parte de las funcionalidades, es más fácil determinar si
los requerimientos planeados para los niveles subsiguientes son correctos.
• Si un error importante es realizado, sólo la última iteración necesita ser
descartada y utilizar el incremento previo.
DESVENTAJAS.
• Se presupone que todos los requisitos se han definido al inicio.
• Se requiere de una experiencia importante para definir los incrementos de
forma de distribuir en ellos las tareas en forma proporcional
• Si el sistema a desarrollar es de gran magnitud y se cuenta con un único
grupo para construirlo se corre el riesgo que el desarrollo se prolongue
demasiado en tiempo
 Scrum (XP)
Scrum es el nombre con el que se denomina a los marcos
de desarrollo ágiles caracterizados por:
• Adoptar una estrategia de desarrollo incremental, en
lugar de la planificación y ejecución completa del
producto.
• Basar la calidad del resultado más en el conocimiento
tácito de las personas en equipos auto organizados,
que en la calidad de los procesos empleados.
• Solapamiento de las diferentes fases del desarrollo, en
lugar de realizar una tras otra en un ciclo secuencial o
en cascada.
Actualidad
• Los tipos de ciclos de vida que se han visto hasta
ahora son relativos al análisis y diseño
estructurados, pero los objetos tienen una
particularidad, y es que están basados en
componentes que se relacionan entre ellos a
través de interfaces, o lo que es lo mismo, son
mas modulares y por lo tanto el trabajo se puede
dividir en un conjunto de miniproyectos.
• El ciclo de vida típico en una metodología de
diseño orientado a objetos es iterativo e
incremental.