Ing.

Félix Gerardo Díaz

CLASE 2
 CONTENIDO

MODELOS DE CICLO DE VIDA

▪ Cascada
▪ Iterativos e incrementales
▪ Espiral
▪ Prototipos
¿Qué es una metodología?
¿Qué es una metodología de desarrollo de software?
Las metodologías de desarrollo de software son un conjunto de
técnicas y métodos organizativos que se aplican para diseñar
soluciones de software informático.

El objetivo de las distintas metodologías es intentar organizar los

equipos de trabajo para que estos desarrollen las funciones de
un programa de la mejor manera posible.
NECESIDAD DE UNA METODOLOGÍA
 PRUEBA Y ERROR
En la década de 1970 los programas fueron creciendo en complejidad, por lo
que la antigua técnica de code & fix (codificar y corregir) terminó quedando
obsoleta. Esta técnica se basaba en requerimientos ambiguos y sin
especificaciones puntuales. Al no seguir normas para el proyecto, el cliente o
usuario sólo impartían especificaciones muy generales del producto final. Se
programaba, se corregía, y se volvía a programar sobre la misma marcha del
proyecto.

El ciclo de vida de este tipo de proyectos finalizaba cuando se satisfacían las

especificaciones, no sólo las primeras por las cuales nació la necesidad del
programa, sino también todas aquellas que fueron surgiendo sobre la marcha.
 PUNTO DE VISTA GENERAL
Planificación: idearemos un planeamiento detallado que guíe la gestión del
proyecto, temporal y económicamente.

Implementación: acordaremos el conjunto de actividades que componen la

realización del producto.

Puesta en producción: nuestro proyecto entra en la etapa de definición, allí

donde se lo presentamos al cliente o usuario final, sabiendo que funciona
correctamente y responde a los requerimientos solicitados en su momento.
Esta etapa es muy importante no sólo por representar la aceptación o no del
proyecto por parte del cliente o usuario final sino por las múltiples dificultades
que suele presentar en la práctica, alargándose excesivamente y provocando
costos no previstos.
 CLASIFICACIÓN DE LAS METODOLOGÍAS

Existen dos metodologías que tienen similitud en la práctica con los

paradigmas de programación:

• Metodología estructurada
• Metodología orientada a objetos.
 Metodología estructurada

Metodología estructurada: la orientación de esta metodología se dirige

hacia los procesos que intervienen en el sistema a desarrollar, es decir,
cada función a realizar por el sistema se descompone en pequeños
módulos individuales. Es más fácil resolver problemas pequeños, y luego
unir cada una de las soluciones, que abordar un problema grande.
 Metodología orientada a objetos

Metodología orientada a objetos: a diferencia de la metodología

mencionada anteriormente, ésta no comprende los procesos como
funciones sino que arma módulos basados en componentes, es decir,
cada componente es independiente del otro. Esto nos permite que el
código sea reutilizable. Es más fácil de mantener porque los cambios
están localizados en cada uno de estos componentes.
 PARADIGMA DE DESARROLLO ÁGIL
Los modelos de ciclo de vida ágiles, son de los más utilizados hoy en día.
El objetivo de este paradigma, es el desarrollo de proyectos en poco
tiempo. Para lo cual, se hace una eliminación de procesos tediosos, se
agilizan las fases de desarrollo, las iteraciones se hacen en un corto
periodo de tiempo, los riesgos se desechan y se evitan para no tener que
lidiar con ellos y siempre se da solución a los problemas de forma rápida.
Si algo demora mucho en dar solución, lo mejor es dejarlo de lado y
seguir avanzando. Una de las principales diferencias del paradigma de
desarrollo ágil con los paradigmas anteriores, es que el cliente se ve
involucrado en el proyecto durante el desarrollo de este
 PARADIGMA DE DESARROLLO ÁGIL

A diferencia del paradigma tradicional donde el cliente solo está al

principio, de igual forma en el paradigma orientado a objetos sucede lo
mismo. Acá el cliente interfiere, da mejoras, propone ideas y se mantiene
al tanto del desarrollo del producto. Lo que ayuda aún mas, pues el
producto final se realiza de forma satisfactoria en un menor lapso de
tiempo.
CICLO DE DESARROLLO CLÁSICO

ANALISIS

DISEÑO

DESARROLLO

TESTING
CICLO DE VIDA LINEAL
Es el más sencillo de todos los modelos. Consiste en descomponer la
actividad global del proyecto en etapas separadas que son realizadas de
manera lineal, es decir, cada etapa se realiza una sola vez, a continuación
de la etapa anterior y antes de la etapa siguiente.
CICLO DE VIDA CASCADA (SECUENCIAL)
El modelo de cascada es un método de gestión de proyectos, en el que el
proyecto se divide en distintas fases secuenciales, donde el equipo puede
pasar a la siguiente fase sólo cuando se haya completado la anterior.
 ¿Cuándo se aplica el método de cascada?

Los gerentes de proyecto suelen recurrir al método de cascada:

• Cuando hay una visión clara de lo que debería ser el producto

final.
• Cuando los clientes no tienen posibilidad de cambiar el alcance
del proyecto una vez que ha comenzado.
• Cuando el concepto y la definición son las claves del éxito (pero
no la velocidad).
• Cuando no hay requisitos ambiguos.
 DESVENTAJAS DEL MODELO CASCADA
• Si encuentra un error de requisito o necesita cambiar algo, su proyecto
debe iniciarse desde el principio con un nuevo código.
• Cuando su producto está en la etapa de prueba, no es fácil volver atrás y
cambiar algo que no está claro o no se ha formulado bien en la fase inicial.
• No puede resolver algunos problemas esenciales utilizando Waterfall para
proyectos complejos y orientados a objetos. Tampoco es una buena idea
usarlo para proyectos largos con requisitos complejos e imprecisos.
• El método no es apropiado para los proyectos en los que se sabe desde
inicio que hay muchas probabilidades que los requisitos cambien.
• Los clientes pueden no estar satisfechos con el producto entregado. Como
todas las tareas y los entregables se basan en requisitos documentados, es
posible que los clientes no vean lo que se entregará hasta que esté casi
terminado. Puede ser difícil cambiar algo en ese momento.
CICLO DE VIDA ITERATIVO
También derivado del ciclo de vida en cascada puro, este modelo busca
reducir el riesgo que surge entre las necesidades del usuario y el producto
final por malos entendidos durante la etapa de solicitud de
requerimientos.

Es la iteración de varios ciclos de vida en cascada. Al final de cada

iteración se le entrega al cliente una versión mejorada o con mayores
funcionalidades del producto. El cliente es quien luego de cada iteración,
evalúa el producto y lo corrige o propone me- joras. Estas iteraciones se
repetirán hasta obtener un producto que satisfaga al cliente
CICLO DE VIDA ITERATIVO
CICLO DE VIDA EVOLUTIVO
Este modelo acepta que los requerimientos del usuario pueden cambiar
en cualquier momento.

La práctica nos demuestra que obtener todos los requerimientos al

comienzo del proyecto es extremadamente difícil, no sólo por la dificultad
del usuario de transmitir su idea, sino porque estos requerimientos
evolucionan durante el desarrollo y de esta manera, surgen nuevos
requerimientos a cumplir. El modelo de ciclo de vida evolutivo afronta
este problema mediante una iteración de ciclos requerimientos–
desarrollo–evaluación.
CICLO DE VIDA EVOLUTIVO
CICLO DE VIDA INCREMENTAL
Este modelo de ciclo de vida se basa en la filosofía de construir
incrementando las funcionalidades del programa.
Se realiza construyendo por módulos que cumplen las diferentes
funciones del sistema. Esto permite ir aumentando gradualmente las
capacidades del software.

Es una repetición del ciclo de vida en cascada, aplicándose este ciclo en

cada funcionalidad del programa a construir. Al final de cada ciclo le
entregamos una versión al cliente que contiene una nueva funcionalidad.
Este ciclo de vida nos permite realizar una entrega al cliente antes de
terminar el proyecto.
CICLO DE VIDA INCREMENTAL
CICLO DE VIDA POR PROTOTIPOS
El uso de programas prototipo no es exclusivo del ciclo de vida iterativo.
En la práctica los prototipos se utilizan para validar los requerimientos de
los usuarios en cualquier ciclo de vida.

Si no se conoce exactamente cómo desarrollar un determinado producto

o cuáles son las especificaciones de forma precisa, suele recurrirse a
definir especificaciones iniciales para hacer un prototipo, o sea, un
producto parcial y provisional. En este modelo, el objetivo es lograr un
producto intermedio, antes de realizar el producto final, para conocer
mediante el prototipo cómo responderán las funcionalidades previstas
para el producto final.
CICLO DE VIDA POR PROTOTIPOS
CICLO DE VIDA ESPIRAL
Este ciclo puede considerarse una variación del modelo con prototipado,
fue diseñado por Boehm en el año 1988. El modelo se basa en una serie
de ciclos repetitivos para ir ganando madurez en el producto final. Toma
los beneficios de los ciclos de vida incremental y por prototipos, pero se
tiene más en cuenta el concepto de riesgo que aparece debido a las
incertidumbres e ignorancias de los requerimientos proporcionados al
principio del proyecto o que surgirán durante el desarrollo. A medida que
el ciclo se cumple (el avance del espiral), se van obteniendo prototipos
sucesivos que van ganando la satisfacción del cliente o usuario. A
menudo, la fuente de incertidumbres es el propio cliente o usuario, que
en la mayoría de las oportunidades no sabe con perfección todas las
funcionalidades que debe tener el producto.
CICLO DE VIDA ESPIRAL
En este modelo hay cuatro actividades que envuelven a las etapas.

Planificación: Relevamiento de requerimientos iniciales o luego de

una iteración.

Análisis de riesgo: De acuerdo con el relevamiento de

requerimientos decidimos si continuamos con el desarrollo.

Implementación: desarrollamos un prototipo basado en los

requerimientos.

Evaluación: El cliente evalúa el prototipo, si da su conformidad,

termina el proyecto. En caso contrario, incluimos los nuevos
requerimientos solicitados por el cliente en la siguiente iteración.
CICLO DE VIDA ESPIRAL
El espiral se repite las veces
que sea necesario hasta
que el cliente o usuario
obtiene la satisfacción de
sus necesidades, momento
en el cual nos retiramos del
espiral.
 CASO DE ESTUDIO
1. Completar el cuestionario que se encuentra en la plataforma.
2. Elegir una metodología y simular como la usaría en un proyecto de
software real.

• SUBIR EL PUNTO 2 AL FORO DE CONSULTAS, CON LA SIGUIENTE SINTAXIS: GRUPOX_ACT2.

• PLAZO DE ENTREGA HASTA LA FECHA 06/03.