Ciclos de vida

Todas los estados intermedios que atraviesa un sistema desde que nace hasta que muere. Los
entregables y documentos asociados a cada una de las etapas también atraviesan estos estados.

Un sistema nace con un problema o necesidad de un sistema de información del que surgen ninguno,
uno o muchos ciclos de vida de software: Formas de encarar un proyecto de sistemas mediante las
cuales sabemos cuales van a ser las etapas que lo conforma, como y cuando se transiciona de una
etapa a otra, qué documentación generan y que actividades involucran cada una de las mismas.

Cada ciclo de vida de SW nace con un problema, del que se genera un proyecto y asimismo un
producto. El producto ha de ser mantenido hasta que no sea necesario y haya que retirarlo y
opcionalmente reemplazarlo. El ciclo de vida del desarrollo de SW comienza a la par que el
proyecto pero finaliza al comienzo del mantenimiento (comúnmente, es considerado un periodo de
mantenimiento dentro de los contratos de desarrollo).

Una vez que se terminan las actividades en un estado, se pasa al siguiente. Algunos tipos de ciclo de
vida permiten cierto paralelismo entre los estados pero todos tienen una característica progresiva.

Los mapas de actividades permiten visualizar la relación entre cada estado y las actividades que le
corresponden.

Parámetros de comparación

- Velocidad de desarrollo
- Calidad de producto
- Visibilidad interna del estado del proyecto: Que tanto puedo saber en un momento dado del
desarrollo en qué etapa me encuentro, que actividades lo conforman y cuál es la próxima
etapa.
- Visibilidad externa del avance del producto: Que tanto puede ver el cliente del producto en un
momento dado del desarrollo, previsualizaciones del software antes del cierre de todas las
etapas.
- Manejo de riesgos: Si no hay una etapa (o actividad dentro de una etapa) dedicada al mismo,
el CV no tiene manejo de riesgos.
- Respuesta a cambios: La adaptabilidad del CV ante el surgimiento de nuevos requerimientos
por parte del cliente o contexto.
- Costo
- Experiencia del líder de proyecto: Cuánta experiencia se requiere del equipo de trabajo o del
lider para poder implementar este CV.

Prueba y error: Code and fix

Hay una ida y vuelta constante con el cliente hasta que eventualmente se llega a un producto funcional
que cumple con los requisitos. Descrito como la ausencia de ciclo de vida por falta de una estructura
definida.
Las etapas que lo conforman son el desarrollo como “prueba y error”, la especificación o no del
cliente (poco clara, incompleta) y la entrega.

Parámetros:

- Velocidad: Dependiente de la complejidad del proyecto y la experiencia del desarrollador.

- Calidad: El producto pierde robustez al estar corrigiendo todo el tiempo.
- Visibilidad interna: No se sabe cuando va a terminar.
- Visibilidad externa: El cliente está siempre revisando el producto.
- Manejo de riesgos: No hay.
- Respuesta a cambios: En si el CV se basa en el cambio de requisitos constante, el cliente está
siempre dando feedback y actualizando los requisitos.
- Costo: Dependiente de la cantidad de tiempo que tome el desarrollo, sin organización los
costos siempre suben.
- Experiencia del líder: No hay complejidad.

Cascada puro: Pure waterfall

Si bien todas las etapas están perfectamente divididas y tienen sus actividades bien definidas, todos
los errores detectados de etapas anteriores en la actual, fuerzan al desarrollo del CV a volver a las
mismas para corregirlos.

‘En la etapa de relevamiento me comentan que cierto problema surge del área de logística. En el
organigrama generado en el estudio preliminar el área de logística NO existe. Debo volver a la etapa
anterior para realizar nuevamente el estudio de la estructura de la empresa.’

Las etapas que lo conforman son estudio preliminar, relevamiento, estudio de factibilidad, análisis,
diseño, desarrollo, pruebas e implementación. Sin embargo otras etapas de control o análisis pueden
ser agregadas entre las bases ya conocidas.
Parámetros:

- Velocidad: Lenta, cada etapa depende de la completitud total de la anterior y existe la

posibilidad de tener que volver atrás para corrección de errores.
- Calidad: El proyecto se encara siguiendo al pie de la letra la metodología de sistemas,
analizando los requisitos previamente y diseñando a medida para desarrollarlo robustamente.
- Visibilidad interna: Está todo documentado y las etapas están ordenadas.
- Visibilidad externa: El cliente debe esperar a las etapas finales para poder visualizar el
producto por primera vez.
- Manejo de riesgos: No hay.
- Respuesta a cambios: Dependiente de la etapa donde se encuentra el proyecto. Mala, dado que
hay que volver siempre a etapas anteriores cuando se presentan cambios que afectan a las
mismas.
- Costo: Cada etapa conlleva muchas actividades y genera muchos documentos, todas son muy
robustas pero por un costo.
- Experiencia del líder: La metodología de sistemas es clara sobre qué etapas existen y que
actividades se realizan en cada una. El líder de proyecto no debe tomar decisiones sobre que
se hace después y no debe manejar equipos en paralelo.

Cascada con fases superpuestas: Sashimi

Las etapas son las mismas que cascada puro, pero el ida y vuelta entre las etapas no es tan marcado.
Todos los errores detectados de etapas anteriores en la actual, abren la posibilidad de revisar
nuevamente las etapas que lo necesiten sin frenar el desarrollo actual del proyecto.

‘Mientras estoy desarrollando, surge un problema en el análisis y vuelvo a analizar parcialmente los
requisitos mientras sigo con el desarrollo. No hay un ida y vuelta marcado entre una etapa y otra.’
Parámetros en los que varía:

- Velocidad: No está la necesidad de retroceder a etapas anteriores cada vez.

- Visibilidad interna: Las etapas se superponen y mientras estoy en una etapa podría estar
ocupándome de problemas en unas anteriores.
- Visibilidad externa: Al haber más velocidad, hay una entrega más temprana. Si se llegó a la
etapa de implementación y surge un problema en etapas anteriores, el cliente puede aún
visualizar el producto sin tener que esperar a que se corrijan los desvíos.
- Respuesta a cambios: Los cambios son afrontados directamente, sin perder tiempo en volver
hacia atrás en las etapas.
- Experiencia del líder: El desvío del CV cascada puro requiere de un líder que pueda manejar
la superposición de etapas, necesita cierta experiencia en manejo de varios equipos en
paralelo.

- Ciclos de vida iterativos -

Cada etapa puede tener más de una instancia, paralelamente por más de un equipo o por el mismo
equipo alternadamente. La cantidad de iteraciones está definida desde el principio del proyecto.

[ITERATIVO] Cascada con subproyectos:

El diseño consta de una definición arquitectónica general donde se definen qué componentes se deben
implementar en el sistema, pero este está subdividido en módulos por cada gran funcionalidad que
desea cubrir el proyecto. Cada submódulo tiene su etapa de diseño, desarrollo y pruebas.

Finalmente, una vez que todos los módulos son cerrados, estos son integrados todos juntos y pasan
por una etapa final de pruebas e implementación.
El trabajo en esta etapa de diseño puede ser tomado por tantos equipos paralelos como módulos haya
o por un mismo equipo que recorre cada una de estas iteraciones una tras otra.

Parámetros en los que varía:

- Velocidad: Permite paralelizar las etapas y sus actividades.

- Visibilidad interna: Además de las etapas, los módulos también son claros y están ordenados.
- Costo: Cada módulo requiere su propio control y equipo.
- Experiencia del líder: El líder de proyecto necesita cierta experiencia en manejo de varios
equipos en paralelo.

- Ciclos de vida incrementales-

Caso particular de un CV iterativo donde se definen diversas entregas del producto a medida que este
se va desarrollando, desde la primera entrega este es funcional y puede utilizarlo el cliente (MVP).

[IDEM] Cascada iterativo incremental: Staged delivery

A cada iteración de diseño, desarrollo y pruebas se le suma una etapa de implementación, el cliente
puede visualizar el producto a medida que se van resolviendo los módulos, se pueden ir identificando
errores y el software puede comenzar a darle beneficios a la empresa por estar funcionando antes del
cierre oficial del proyecto.
Parámetros en los que varía:

- Velocidad: Si bien implementar cada módulo individualmente toma tiempo, las

funcionalidades son lanzadas con un orden de prioridad lógico y hay necesidad de esperar a la
completitud total del proyecto.
- Visibilidad externa: Desde la implementación del primer módulo, el cliente puede visualizar y
probar las primeras funcionalidades.
- Respuesta a cambios: Si el cambio se encuentra dentro de una de las etapas de un módulo, la
regresión afectaría únicamente a esa iteración, equipo y entrega. Cada implementación
permite cierto acercamiento a posibles cambios en requerimientos del cliente/errores del
producto.
- Costo: Hay una implementación individual de cada módulo y su debida integración con el
resto de los módulos de los que depende (pendientes/en desarrollo) del sistema viejo.

Velocidad de desarrollo de los distintos CV:

[IDEM] Entrega calendarizada: Design-to-schedule / Timebox
Siguiendo el esquema del CV iterativo incremental, ciertas funcionalidades de ciertos módulos van a
ser dictaminadas una fecha de entrega y serán priorizadas según su estado de completitud
acercándonos a esa deadline. Se reorganiza, en el momento, el esquema y el tiempo en función de una
fecha con la que tengo que cumplir.

‘La funcionalidad X del módulo 3 tiene que estar lista para navidad. Si el 22 de diciembre el
desarrollo del mismo no fue comenzado, se debe frenar todo desarrollo en otras etapas para llegar
con esa entrega en particular.’

Parámetros en los que varía:

- Experiencia del líder: El líder debe estar especialmente pendiente de las deadlines planteadas,
y conocer el avance de los distintos módulos para poder alertar a tiempo cuando cortar con el
desarrollo de uno y empezar con la funcionalidad crítica.

- Ciclos de vida evolutivos -

Como los incrementales, tenemos más de una instancia paralela por etapa. La cantidad de iteraciones
se va definiendo a medida que avanza el proyecto.

[EVOLUTIVO] Prototipado
Comienza con un concepto inicial relevado de los requerimientos del cliente y lo sigue un subciclo
que consiste en seleccionar un prototipo ya armado que responda a la necesidad del sistema, su
construcción y la obtención de feedback sobre el mismo.

Si este no cumple con lo pedido, se repite el subciclo hasta obtener el prototipo deseado. Una vez que
se llega al punto de acuerdo, se completa con lo faltante y se entrega el producto.
El prototipado puede utilizarse para obtener los requerimientos del sistema y una vez documentados,
se pasa al desarrollo con otro tipo de CV (desechable, recomendado).

- Prototipado evolutivo: Cuando el prototipo se considera aceptable, este se refina y se

entrega como producto terminado.
- Prototipado desechable: Cuando el prototipo se considera aceptable, este se destruye y
se desarrolla un producto con un proceso orientado a la calidad, utilizando el
conocimiento obtenido por la interacción del usuario con el prototipo y las reacciones
del cliente. Es en este momento donde se elige otro tipo de CV para tomar el resto de
las etapas.

Parámetros:

- Velocidad: Permite obtener los requerimientos más rápida y certeramente, pero está la
posibilidad de iterar indefinidamente en el subciclo.
- Calidad: Un prototipo evolutivo tiene una calidad semejante a prueba y error. La calidad del
producto final con prototipo desechable depende del CV elegido para continuar con el
desarrollo.
- Visibilidad interna: Semejante a prueba y error, donde no se sabe cuando va a terminar el
ciclo de feedback y corrección.
- Visibilidad externa: El cliente está siempre revisando el producto.
- Manejo de riesgos: No hay.
- Respuesta a cambios: Sobre la consulta constante al cliente, si surgen cambios se pueden
tomar.
- Costo: Dependiente de la cantidad de ciclos a realizar. Hay gran cantidad de recursos
dedicados a la construcción del prototipo pero esta robustez en el relevamiento de
requerimientos facilita etapas consiguientes como desarrollo.
- Experiencia del líder: No hay complejidad.
[IDEM] Entregas evolutivas: Evolutionary delivery
Se genera una primera versión siguiendo el CV de tipo prototipado, y se combina con un CV
de tipo iterativo incremental. A medida que se cicla se evalúa si hay nuevos requerimientos y
los mismos se refinan. Cada ciclo permite determinar si se vuelve a ciclar o si se continúa con
el desarrollo.

Cada iteración es una cascada que agrega valor sobre el producto. Luego de cada ciclo del
espiral se evalúa la conveniencia de realizar un nuevo ciclo (riesgos y beneficios potenciales).

[IDEM] Espiral

Parámetros:

- Velocidad: La etapa de prototipado y de análisis de riesgos reduce la velocidad.

- Calidad: Al cubrir el análisis de riesgos, todo el sistema parte de una base más sólida. Se
planifica y ejecuta ordenadamente, a la par del cliente.
- Visibilidad interna: Se puede volver a ciclar sobre la misma etapa las veces que sean
necesarias, se añaden ciclos evolutivamente y nunca se puede saber cuantos mas faltan para
cerrar definitiva esa etapa en el proyecto.
- Visibilidad externa: El cliente está siempre revisando el producto gracias a los prototipos.
- Manejo de riesgos: Hay en cada ciclo.
- Respuesta a cambios: Gracias a los prototipos, se puede tomar el feedback del cliente y las
iteraciones permiten poder volver a ciclar por las etapas e incorporar los cambios.
 - Costo: Si bien este se eleva por la complejidad del sistema, se reducen los que surgirían si
ciertos riesgos no hubiesen sido contemplados.
- Experiencia del líder: Alta, es un esquema complejo que involucra paralelismo, manejo de
riesgos y prototipado. Se necesitan tomar decisiones de cuando iterar, que etapas y cuantas
veces.

[IDEM] Cascada con reducción de riesgos

Se realiza un análisis de riesgos previo a un CV de tipo cascada tradicional. Cuando ya no son
identificados más riesgos, se avanza con la etapa de diseño naturalmente.

Riesgos

Lo componen una probabilidad de que ocurra un problema, un impacto en el caso de ocurrir

(cuánto nos va a afectar). La probabilidad se mide de 0 a 1 y el impacto en términos económicos. La
exposición es la probabilidad multiplicada por el impacto.

Planes para minimizar el riesgo

- Mitigación: Proactivo, disminuir exposición.

- Contingencia: Reactivo, acciones a llevar a cabo si ocurre.

Estrategias

- Evitar: Con mitigación.

- Transferir: En caso de que el riesgo ocurra, este sea problema de alguien más
(ejemplo: contratación de un seguro).
- Aceptar
El hecho de tener un plan, no asegura el cumplimiento: Cuando se identifica un riesgo
inherente, y se introducen controles, los controles lo traducen a riesgo residual con tendencia
al riesgo.

‘Se contrata un seguro como factor mitigante al riesgo de chocar. Si la cuota del seguro no
está paga, la póliza del seguro se cae. Se deben aplicar controles mínimos para validar el
correcto pago de la póliza, y controles eventuales para determinar si la cuota está
sobrecalculada, etc. La construcción de un plan solamente no alcanza.’

Planificación
Actividad que se mantiene a lo largo del ciclo de vida del sistema (CVS). Se aplica a todas
sus etapas, y para cada etapa en particular. La planificación va de la mano de la
documentación y el control.

- Objetivo: Qué se quiere lograr. Es cuantificable o no cuantificable.

- Recursos: Materiales/equipamiento (software de base y hardware), humanos (cantidad
y calidad) y estructura.
- Presupuesto a aplicar al desarrollo.
- Tareas: Detalle de cada tarea y su esquema de orden (precedencias).
- Programación: Tener los recursos necesarios disponibles en el momento oportuno de
realizar cada tarea.
- Tiempos a insumir para cada tarea.

Debe tenerse claro el alcance y la perspectiva del sistema en la organización. Participa desde
la dirección de la organización hasta el nivel técnico, alcanza a toda la organización.
No hay aplicación estricta de la tecnología (salvo tareas específicas), hay una política de
usuario (estamos interactuando con personas) que dicta el nivel de acercamiento del usuario
para integrarlo al proyecto.

Tipos de planificación

- Estratégica: Define el qué y se define desde el nivel directivo. Alcance importante,

rige los cursos de acción que la organización debe seguir. Plantean la necesidad de un
proyecto y tienen un panorama global de la organización.
- Táctica: Define el cómo y se define desde el nivel gerencial. Sirve de eje entre los
directivos y los operadores.
- Operativa: Ejecuta el plan y genera la base de la información para que la
organización pueda funcionar.
La información no varía entre los niveles, lo que cambia es el detalle. La información llega a
la punta de la pirámide lo más desestructurada posible.

La información es completa (todos los reportes), confiable (cómo fue obtenida) y oportuna
(a tiempo). La presentación de la información debe ser clara y precisa.

Técnicas de planificación

Las diferentes técnicas y herramientas para la planificación nos proveen la posibilidad de

documentar. Todas las etapas de la Metodología de Sistemas se caracterizan por su calidad
si están bien documentadas.

Es importante tener antecedentes de lo previamente realizado, un historial de lo planificado

en otras ocasiones para futuras estimaciones.

Hay que tener en cuenta la preparación de la presentación del plan:

- Para el nivel directivo, que autorizará su ejecución y otorgará el presupuesto del

mismo.
- Para el nivel gerencial y operativo, que lo pondrán en ejecución en su dia a dia y
deben entenderlo en un lenguaje común de trabajo.

Siempre debe haber puntos intermedios de control, estratégicamente ubicados, para analizar
desvíos, aplicar su corrección y asegurar el logro del objetivo final del plan.

Técnica Gantt: Planificación y documentación

- Escala de tiempo, relativa a la duración total del proyecto.

- Tareas y sus dependencias, tareas que para su ejecución requieren de la
finalización de otra/s anterior/es.
- Puntos de control, definidos según las tareas y repartidos a lo largo de todo el
proyecto para evitar desvíos.

Estudio preliminar
Única etapa que se puede saltear en el CVS siendo ya parte de la organización)

- Deben relevarse todas las áreas de la organización en general, sus funciones y

misiones. Qué y cómo hace lo que hace.
- Detecta los problemas o necesidades de información, expresadas o no por el usuario,
entiende sus expectativas y lo ayuda a definir el alcance tanto monetario como
temporal.
Elementos: Organigrama actualizado, estatutos y balances, manuales de procedimientos y
manuales de misiones y funciones.

Técnicas: Entrevista y observación personal.

Entrevista

Una entrevista tiene 3 etapas clave, la planificación, el desarrollo y el cierre.

La planificación requiere saber quién será el entrevistado (datos personales, cargo y

trayectoria en la empresa) y quienes entrevistan. La hora, duración y lugar. Los temas
a tratar, para mantener control sobre la reunión y duración de la misma, y la
modalidad general de la entrevista.

Una entrevista estructurada (segundas entrevistas) se basa sobre un cuestionario que

define cómo abordar cada tema a través de preguntas puntuales. Una entrevista no
estructurada (primeras entrevistas) está compuesta por preguntas abiertas que abren
la charla a temas determinados.

El desarrollo consta inicialmente de una presentación (a través de un aviso anticipado

del superior o una presentación presencial) y la presencia de los entrevistadores.

El cuerpo de la entrevista está compuesto por preguntas tanto abiertas como cerradas,
y puede tener 3 estructuras comunes:

Pirámide, permite iniciar con una pregunta abierta y luego profundizar sobre ciertos
aspectos que se van conociendo durante la entrevista con preguntas cerradas.

Triángulo, permite iniciar con una pregunta cerrada y, sumarizando toda la

información obtenida, cerrar con una pregunta abierta a modo de síntesis.

Rombo, comienza como una entrevista de tipo pirámide hasta que, en cierto punto
medio con suficiente información, se muta hacia una entrevista de tipo triángulo,
donde se sumariza lo obtenido hasta llegar nuevamente a una pregunta abierta de
cierre.

Es en el cierre de la reunión donde se planifican los siguientes encuentros y se

resumen los pasos a seguir junto al entrevistado. Se formaliza en esta etapa a través de
la minuta lo ocurrido realmente durante el encuentro y se compara contra lo
anteriormente planificado.
 La información obtenida requiere cierta conformidad del usuario (ejemplo, firma de la
minuta) para asegurar que todas las partes involucradas tienen un común
entendimiento de lo ocurrido o por ocurrir.

Relevamiento

Estudio de Factibilidad

Analisis