16-08-2025
ISW – Unidad 1
Modelos de Proceso de Software.
⚫ Modelo Cascada (tradicional).
⚫ Modelo V.
⚫ Modelo de prototipos.
⚫ Modelo desarrollo en fases (iterativo–incremental).
⚫ Modelo espiral.
⚫ Enfoque Orientado a Objetos – Proceso Unificado (RUP).
⚫ Métodos ágiles.
29
29
ISW – Unidad 1
Modelos de Proceso de Software.
El proceso de desarrollo de software consiste en un conjunto de actividades y pasos:
⚫ Requerimientos
⚫ Especificación
⚫ Arquitectura
⚫ Diseño
⚫ Implementación
⚫ Testing
⚫ Distribución
⚫ Mantención
⚫ Documentación
30
30
1
16-08-2025
ISW – Unidad 1
Modelo Cascada.
⚫ Es el más antiguo. Posterior al proceso primitivo
“Code and Fix”.
⚫ Fases representan “baldes”. Flujos de datos
representan “agua que fluye entre los baldes”.
⚫ Debe completarse una fase antes de comenzar
la siguiente.
⚫ Es útil para que el desarrollador visualice lo que va
a hacer.
⚫ Su principal problema es que no refleja la realidad.
31
31
ISW – Unidad 1
Modelo Cascada en la Práctica.
Actividades del modelo cascada mediante metodología estructurada:
⚫ Identificar todas las funciones/procesos actuales.
⚫ Identificar los flujos de datos entre las funciones.
⚫ Descomponer las funciones en subfunciones e identificar los flujos de datos respectivos.
⚫ Documentar mediante diagramas de flujos de datos, descripción de procesos y descripción de flujos
de datos.
32
32
2
16-08-2025
ISW – Unidad 1
Modelo Cascada – Resumen.
Funciona razonablemente bien si se cumplen las siguientes condiciones …
⚫ Los requerimientos son bien conocidos desde un principio.
⚫ Los requerimientos no incluyen ítems de alto riesgo no resueltos.
⚫ Los requerimientos no cambiarán durante el proceso de desarrollo.
⚫ El equipo de desarrollo tiene experiencia previa en proyectos similares, por lo que conocen las
condiciones involucradas en la construcción de la aplicación.
⚫ Los plazos del proyecto permiten una ejecución secuencial de las actividades.
Las metodologías aplicadas en cada fase pueden variar, desde aquellas planteadas en los enfoques
clásicos (BURCH–STRATER, ARDI), hasta la metodología estructurada (YOURDON, OSCAR BARROS).
33
33
ISW – Unidad 1
Modelo Cascada – Metodologías Tradicionales.
34
34
3
16-08-2025
ISW – Unidad 1
Modelo Cascada – Resumen.
Variación: Cascada con Retroalimentación.
⚫ Se aplica para considerar la corrección de errores, aunque el objetivo sigue siendo completar
cada paso antes de continuar con la siguiente.
⚫ Difícil de controlar y planificar, requiere hacer algunas predicciones.
⚫ Aumenta el presupuesto del proyecto.
Requerimientos
Diseño
Codificación
Testing
Despliegue
Mantención
35
35
ISW – Unidad 1
Modelo Cascada – Cronograma General de Actividades.
Existe una variación denominada “cascada de fases superpuestas”, en que las fases soportan cierto nivel de
traslape.
36
36
4
16-08-2025
ISW – Unidad 1
Modelo Cascada – Comentarios.
⚫ Envergadura del proyecto → Presenta una desventaja en proyectos muy extensos debido a la
escasa interacción entre el equipo de desarrollo y la comunidad de usuarios; esto representa un
riesgo de no saber con seguridad si se están desarrollando los requerimientos correctos. En
proyectos más pequeños, puede presentar ventajas dado que es menos probable que los
requerimientos cambien durante el período de desarrollo, y los errores en los requerimientos
representan costos más bajos.
⚫ Claridad de los requerimientos → Al existir requerimientos claros y estables, este modelo presenta
ventajas, al ser descritos y validados en la etapa inicial. Con requerimientos cambiantes este
modelo no es adecuado.
⚫ Capacidades técnicas del RRHH a cargo del proyecto → En equipos poco experimentados este
modelo presenta ventajas dado que es fácil de comprender y usualmente está detalladamente
normalizado en las Organizaciones que lo utilizan.
⚫ Duración del proyecto en base a los plazos establecidos → En este caso el modelo cascada presenta
ventajas, siempre que se cuente con los plazos suficientes para desarrollar las tareas en forma
secuencial.
37
37
ISW – Unidad 1
Modelo V.
⚫ Alemania 1992.
⚫ Variación del modelo cascada.
⚫ El “ángulo” es la codificación.
⚫ Los sucesivos testing proceden como contraparte de las actividades de desarrollo.
Tiempo
39
39
5
16-08-2025
ISW – Unidad 1
Modelo V – Fase de Descomposición.
1. Análisis de Requerimientos:
⚫ Se capturan requerimientos y se analizan necesidades de usuarios.
⚫ Se genera el documento de especificación de requerimientos de software, en dónde se
describen las funcionalidades del sistema y otros aspectos relacionados con requerimientos no
funcionales: interfaces, datos, seguridad, rendimiento, etc.
⚫ Se definen criterios de aceptación del sistema por parte de los usuarios.
⚫ Se diseñan pruebas de aceptación conceptuales.
⚫ Documentación según metodología estructurada.
2. Diseño del Sistema:
⚫ Se especifica el diseño de la arquitectura de software.
⚫ Se establecen políticas generales de testing.
⚫ Se diseñan pruebas de integración.
⚫ Se diseñan pruebas de sistema (test de entrega).
3. Diseño de Programas:
⚫ Se especifica el diseño detallado (interfaces, modelo de datos, módulos de software).
⚫ Se diseñan pruebas unitarias.
4. Codificación:
⚫ Se construyen los programas de acuerdo al diseño.
40
40
ISW – Unidad 1
Modelo V – Fase de Integración.
1. Testing Unitario / Integración:
⚫ Se ejecutan y gestionan las pruebas unitarias (preparación del entorno, preparación de los
datos)
⚫ Se puede usar una combinación de enfoques de caja blanca y caja negra, ejecutados por los
mismos desarrolladores o por un equipo externo de SQA.
⚫ Se preparan y ejecutan las pruebas de integración y pruebas de regresión, usualmente bajo un
enfoque de caja negra (módulos stub, driver).
⚫ Las pruebas exitosas (detectan defectos) se deben gestionar según las políticas de testing
predefinidas (procedimientos, documentación, etc).
⚫ Se documentan las pruebas ejecutadas y sus resultados.
2. Testing del Sistema:
⚫ Se preparan y ejecutan las pruebas de sistema, usualmente bajo un enfoque de caja negra.
⚫ Las pruebas exitosas (detectan defectos) se deben gestionar según las políticas de testing
predefinidas (procedimientos, documentación, etc).
⚫ Se documentan las pruebas ejecutadas y sus resultados.
3. Testing de Aceptación:
⚫ Se preparan y ejecutan las pruebas de aceptación, usualmente bajo un enfoque de caja negra.
⚫ Las pruebas exitosas (detectan defectos) se deben gestionar según las políticas de testing
predefinidas (procedimientos, documentación, etc).
⚫ Si no hay problemas, se inicia el trámite de aceptación del sistema.
41
41
6
16-08-2025
ISW – Unidad 1
Modelo V – Planificación del Testing / Criterios de Aceptación.
⚫ Son condiciones que se utilizan para verificar que la aplicación cumpla con los requerimientos.
⚫ Se deben diseñar en forma no ambigua, de manera que los stakeholder no puedan rechazar el
trabajo en forma arbitraria.
⚫ Algunos aspectos que se deben considerar:
− Comportamiento → Permite verificar el comportamiento observable del sistema. Por
ejemplo: “El usuario puede consultar la lista completa de órdenes pendientes”
− Reglas del negocio → Usualmente se definen como sentencias “Si … entonces”. Por
ejemplo: “Si un usuario ingresa 3 veces una contraseña errónea, entonces su cuenta se debe
bloquear durante 1 hora”
− Flujo de proceso → Especificación de pasos de un proceso, incluyendo pasos automatizados
y tareas de usuario. Por ejemplo “Cuando un cliente ingresa una solicitud, se debe crear una
tarea de aprobación en el sistema de ventas”
− Cálculos → Especificación de cálculos que pueden incluir reglas del negocio, algoritmos y/o
fórmulas. Por ejemplo: “Si se atiende a un cliente frecuente, se debe descontar 10% del
total”
− Eventos → Detalle de la generación y manipulación de eventos. Por ejemplo: “Si un cliente
no confirma su reserva dentro de 10 minutos, se libera el asiento reservado y se le envía
mensaje de cancelación de reserva”
− Validaciones → Se refiere al ingreso de datos. Por ejemplo: “Si la dirección de entrega no
está dentro de la región, mostrar mensaje … ”
− Usabilidad → Aspectos que facilitan el uso del producto. Por ejemplo: “Por defecto todos los
sonidos están deshabilitados” 44
44
ISW – Unidad 1
Modelo V – Planificación del Testing / Criterios de Aceptación (Cont).
⚫ Algunos aspectos que se deben considerar (cont):
− Implementación → Permite verificar algunos requerimientos no funcionales. Por ejemplo:
“La documentación del sistema cumple con las normas de auditoría”
− Rendimiento → Durante la operación del sistema. Por ejemplo: “El sistema no debe
demorar más de 3 segundos en cargar una página, habiendo 1000 usuarios concurrentes”
− Controles → Definición de controles internos. Por ejemplo “El sistema debe registrar todos
los intentos exitosos y fallidos de eliminación de datos (fecha, hora, usuario, dato)”
− Operaciones → Especificación de requerimientos de operaciones. Por ejemplo: “El sistema
se debe integrar con el sistema de planificación de producción, generando una lista de
materias primas necesarias
− Calidad → Indicaciones de aspectos de disponibilidad o similares . Por ejemplo: “El sistema
debe presentar estabilidad de operación en períodos peak, con uptime superior a 99% ”
− Diseño de interfaz → De acuerdo a indicaciones contenidas en los requerimientos o en
prototipos. Por ejemplo: “La interfaz cumple con las pautas organizacionales”
⚫ Algunas políticas de testing pueden incluir distribución de versiones Beta.
⚫ Recordar temas de “Ingeniería y Gestión de Requerimientos”:
− Enfoque RBT (Requirements Based Testing).
− Análisis causa/efecto para limitar casos de prueba.
45
45
7
16-08-2025
ISW – Unidad 1
Modelo V – Cronograma General de Actividades.
47
47
ISW – Unidad 1
Modelo V – Resumen.
En la práctica no hay mayores diferencias entre el modelo cascada y el modelo V, aunque este último
requiere mayor esfuerzo y tiempo, puesto que se enfoca en la calidad desde el inicio del proyecto.
Sin embargo, el resultado final es un proyecto con menos atrasos y menos reclamos por parte de los
usuarios.
Situaciones en que se puede utilizar el modelo V:
⚫ Los requerimientos son bien conocidos desde un principio.
⚫ Los requerimientos no incluyen ítems de alto riesgo no resueltos.
⚫ Los requerimientos no cambiarán durante el proceso de desarrollo.
⚫ El equipo de desarrollo tiene experiencia previa en proyectos similares, por lo que conocen las
condiciones involucradas en la construcción de la aplicación.
⚫ Los plazos del proyecto permiten una ejecución secuencial de las actividades.
⚫ Aspectos de calidad del software son prioritarios.
48
48
8
16-08-2025
ISW – Unidad 1
Modelo V – Comentarios.
⚫ Envergadura del proyecto → Este modelo presenta ventajas sobre el modelo cascada, dado que se
enfoca en la validación del sistema desde el principio del proyecto, luego disminuye el riesgo de
implementar requerimientos erróneos o innecesarios. Aún así los usuarios no ven resultados hasta
el término del proyecto, aspecto no recomendable en los tiempos actuales. En proyectos más
pequeños, ofrece grandes probabilidades de éxito debido a su enfoque en la calidad, aunque esto
representa un mayor esfuerzo, lo que se debe evaluar antes de aplicarlo.
⚫ Claridad de los requerimientos → Al existir requerimientos claros y estables, este modelo presenta
ventajas, al ser descritos y validados en la etapa inicial (similar al modelo cascada). Usualmente
este modelo se adopta si el proyecto implica riesgos de vidas humanas. Con requerimientos
cambiantes este modelo no es adecuado.
⚫ Capacidades técnicas del RRHH a cargo del proyecto → Requiere equipos con mayor experiencia
que el modelo cascada debido a que se necesitan habilidades específicas y experiencia para la
gestión de la calidad.
⚫ Duración del proyecto en base a los plazos establecidos → En este caso el modelo V presenta
ventajas, siempre que se cuente con los plazos suficientes para desarrollar las tareas en forma
secuencial y se tenga claridad acerca de la sobrecarga que significa la gestión de calidad.
49
49
ISW – Unidad 1
Modelo de Desarrollo en Fases (Enfoque Adaptativo).
⚫ El mercado actual no acepta grandes retardos.
⚫ Una forma de reducirlos es desarrollar y entregar el producto de software en fases.
⚫ El sistema se debe diseñar de manera que pueda ser entregado por partes.
⚫ El usuario tiene algo de funcionalidad mientras se desarrolla el resto.
⚫ Se tienen dos sistemas funcionando en paralelo:
− El de Producción. Usado por el cliente.
− El de Desarrollo. La siguiente versión que reemplazará a la actual versión en Producción.
51
51
9
16-08-2025
ISW – Unidad 1
Modelo de Desarrollo en Fases.
⚫ Hay dos modalidades básicas de organizar el desarrollo de las versiones:
− Incremental → El sistema se especifica y luego es particionado en subsistemas según
funcionalidad. Se comienza con un sistema pequeño y se van agregando nuevas
funcionalidades en las versiones sucesivas.
− Iterativo → Se entrega el sistema completo al comienzo y en cada nueva versión se van
haciendo cambios y mejoras.
52
52
ISW – Unidad 1
Modelo de Desarrollo en Fases.
Modelo de Desarrollo Incremental.
⚫ Clientes identifican a grandes rasgos la funcionalidad requerida.
⚫ Se identifican los servicios generales y los más importantes.
⚫ Se define una secuencia de incrementos, c/u implementa un subconjunto de la funcionalidad
total.
Definir esbozo Asignar prioridad Diseñar arquitectura
de requerimientos a los incrementos del sistema
Desarrollar incrementos Validar Integrar Validar
del sistema incrementos incrementos sistema
Sistema Final
53
53
10
16-08-2025
ISW – Unidad 1
Modelo de Desarrollo en Fases.
Modelo de Desarrollo Incremental (cont.)
Ventajas:
⚫ Primer incremento atiende requerimientos principales
⚫ Incrementos se pueden usar como prototipos
⚫ Bajo riesgo de fallo del proyecto
⚫ Funcionalidad primaria expuesta a mayor período de pruebas
Desventajas:
⚫ Incrementos deben ser relativamente pequeños
⚫ Cada incremento debe entregar una nueva funcionalidad
⚫ Dificultad de identificar los recursos comunes a todos los incrementos
54
54
ISW – Unidad 1
Modelo de Desarrollo en Fases.
Modelo de Desarrollo Iterativo.
⚫ Desarrollar y entregar una versión inicial y luego refinarla en versiones sucesivas, de acuerdo a
los comentarios de los usuarios.
Actividades
concurrentes
Especificación
Versión inicial
Esbozo de la
descripción Versiones
Desarrollo
intermedias
Validación Versión final
55
55
11
16-08-2025
ISW – Unidad 1
Modelo de Desarrollo Iterativo (cont.)
Desventajas:
⚫ Requiere desarrollar documentación repetitiva o incompleta.
⚫ Los cambios continuos pueden generar una estructura deficiente del sistema.
⚫ Problemas contractuales en casos de externalización del desarrollo.
⚫ Problemas de validación del software, al no haber una descripción detallada de las necesidades
de los usuarios.
⚫ Incorporar nuevos cambios puede resultar difícil y costoso.
⚫ Recomendable para sistemas pequeños.
56
56
ISW – Unidad 1
Modelo de Desarrollo en Fases.
⚫ En la práctica, las organizaciones generalmente utilizan una combinación de desarrollo iterativo
e incremental.
⚫ Este enfoque tiene los siguientes beneficios:
− El entrenamiento de los usuarios puede comenzar tempranamente, aunque falte
funcionalidad.
− La entrega frecuente de versiones (releases) permiten encontrar y resolver problemas, a
partir de las versiones operativas.
− El equipo de desarrollo puede enfocarse en diferentes áreas del conocimiento, en cada
versión.
https://www.sphereinc.com/blogs/iterative-vs-incremental-development/ 57
57
12
16-08-2025
ISW – Unidad 1
Modelo de Desarrollo en Fases – Cronograma General de Actividades.
⚫ Ejemplo de 3 iteraciones.
⚫ En cada iteración se desarrolla un incremento del sistema.
⚫ Cada incremento entrega una funcionalidad completa del sistema.
⚫ Defectos encontrados en un incremento se pueden resolver en un incremento posterior.
⚫ Algunas fases se podrían traslapar, dependiendo de la disponibilidad de recursos.
…
…
OBS: El modelo Proceso Unificado presenta una metodología completa orientada a objetos, en base
al enfoque Iterativo–Incremental.
58
58
ISW – Unidad 1
Modelo Desarrollo en Fases – Comentarios.
⚫ Envergadura del proyecto → Este modelo presenta ventajas sobre los modelos descriptivos, puesto
que es más flexible ante los cambios, ya sean externos, expectativas de los interesados,
presupuesto, cambios tecnológicos, debido a que las aplicaciones se construyen en forma
incremental. Se parte construyendo una aplicación pequeña que es razonablemente útil, luego se
agregan nuevas funcionalidades mediante una serie de incrementos de corta duración. Si se
detecta un error, basta rehacer el último incremento (aunque esto es poco probable puesto que
usualmente se reorienta el proyecto antes del inicio de cada incremento ).
⚫ Claridad de los requerimientos → Presenta buenos resultados ante la existencia de requerimientos
ambiguos. Tiene la ventaja que en los incrementos siguientes se obtiene mayor claridad en tales
requerimientos.
⚫ Capacidades técnicas del RRHH a cargo del proyecto → Requiere equipos con alta experiencia
debido a que usualmente se trabaja en equipos separados. Las habilidades en gestión son
imprescindibles en los proyectos que se desarrollan con este modelo.
⚫ Duración del proyecto en base a los plazos establecidos → Debido a la necesidad de ajustarse a los
cambios, los plazos establecidos no son bien manejados por este modelo.
59
59
13
16-08-2025
ISW – Unidad 1
Proceso Unificado.
El valor para el negocio se entrega en forma incremental, mediante iteraciones en el tiempo,
utilizando un conjunto de disciplinas.
https://en.wikipedia.org/wiki/Unified_Process
60
60
ISW – Unidad 1
Actividades del Proceso Unificado:
Inception:
⚫ Definir factibilidad del proyecto.
⚫ Desarrollar caso de negocio.
⚫ Establecer visión y alcance del producto.
⚫ Estimación preliminar de costo y plazo, incluyendo hitos principales.
⚫ Evaluación de riesgos críticos.
⚫ Construcción alternativa de prototipos conceptuales.
Elaboration:
⚫ Especificar requerimientos con mayor detalle.
⚫ Diseño preliminar de la arquitectura.
⚫ Implementación iterativa de la arquitectura básica.
⚫ Refinar evaluación inicial de riesgos y resolver aspectos más críticos.
⚫ Definir métricas.
⚫ Refinar el plan del proyecto, incluir plan detallado para iniciar las iteraciones de construcción.
61
61
14
16-08-2025
ISW – Unidad 1
Actividades del Proceso Unificado:
Construction:
⚫ Completar los requerimientos pendientes.
⚫ Construcción iterativa de los aspectos pendientes del diseño.
⚫ Prueba rigurosa y preparación del sistema para su distribución.
Transition:
⚫ Ejecución de beta testing.
⚫ Corrección de defectos.
⚫ Creación de manuales de usuarios.
⚫ Instalación del sistema en entorno de producción.
⚫ Capacitación de usuarios finales, clientes y equipo de soporte.
⚫ Análisis y registro de lecciones aprendidas.
62
62
ISW – Unidad 1
Proceso Unificado – Resumen.
Ventajas:
⚫ El enfoque iterativo de las fases de elaboración, construcción y transición permite definir los
requerimientos en forma incremental y luego ensamblar los incrementos de la aplicación.
⚫ Las iteraciones de la fase elaboración se enfocan en la mitigación de riesgos, lo que mejora la
probabilidad de éxito del proyecto.
⚫ Permite acomodar diversos modelos de desarrollo con flexibilidad, por ejemplo: enfoques
cascada o ágil en la fase de construcción.
⚫ Las fases de Inception y Elaboration generan gran volumen de documentación que puede guiar a
los desarrolladores que se incorporen al equipo de trabajo.
⚫ Permite implementar versiones incrementales si es necesario.
Desventajas:
⚫ Es un modelo complicado de gestionar y ejecutar.
⚫ Requiere más recursos y esfuerzo que los modelos más simples.
⚫ Puede significar un esfuerzo excesivo para proyectos más pequeños → El nivel de rigurosidad del
modelo puede no ser necesario en proyectos pequeños.
⚫ Originalmente el Proceso Unificado fue concebido para grandes proyectos → Muchos enfoques
más modernos se enfocan en el desarrollo de fases más pequeñas auto-contenidas.
⚫ La versión IBM RUP
63
63
15
16-08-2025
ISW – Unidad 1
Rational Unified Process – IBM.
⚫ La versión IBM del proceso unificado (RUP) contiene las mismas 4 fases: Inception, Elaboration,
Construction y Transition.
⚫ Además de las disciplinas del proceso unificado, agrega 3 disciplinas de apoyo: Gestión del
cambio y configuración, Gestión del proyecto, Entorno.
⚫ IBM provee herramientas que facilitan el proceso: Plantillas de artefactos, producción y
compartición de documentos, seguimiento de solicitudes de cambio, elementos de
modelamiento visual, perfil de rendimientos, etc.
Artefacto RUP:
⚫ Un artefacto RUP representa un resultado final o intermedio que es producido por el proyecto.
Incluye …
− Documentación (documentos de diseño, planes de implementación, etc.)
− Modelos (casos de uso, modelos UML, etc.)
− Elementos de modelos (clases, subsistemas, etc.)
Las ventajas/desventajas de RUP son las mismas que el proceso unificado.
64
64
ISW – Unidad 1
Modelo RUP – Comentarios.
⚫ Envergadura del proyecto → Este modelo presenta ventajas sobre el modelo cascada, dado que se
enfoca en la validación del sistema desde el principio del proyecto, luego disminuye el riesgo de
implementar requerimientos erróneos o innecesarios. Aún así los usuarios no ven resultados hasta
el término del proyecto, aspecto no recomendable en los tiempos actuales. En proyectos más
pequeños, ofrece grandes probabilidades de éxito debido a su enfoque en la calidad, aunque esto
representa un mayor esfuerzo, lo que se debe evaluar antes de aplicarlo.
⚫ Claridad de los requerimientos → Al existir requerimientos claros y estables, este modelo presenta
ventajas, al ser descritos y validados en la etapa inicial (similar al modelo cascada). Usualmente
este modelo se adopta si el proyecto implica riesgos de vidas humanas. Con requerimientos
cambiantes este modelo no es adecuado.
⚫ Capacidades técnicas del RRHH a cargo del proyecto → Requiere equipos con mayor experiencia
que el modelo cascada debido a que de necesitan habilidades específicas y experiencia para la
gestión de la calidad.
⚫ Duración del proyecto en base a los plazos establecidos → En este caso el modelo RUP presenta
ventajas, siempre que se cuente con los plazos suficientes para desarrollar las tareas en forma
secuencial y se tenga claridad acerca de la sobrecarga que significa la gestión de calidad.
66
66
16
16-08-2025
ISW – Unidad 1
Modelo Espiral.
⚫ Modelo descrito inicialmente en 1986 por Barry Boehm.
⚫ Se utiliza el análisis de riesgos para ayudar a los desarrolladores a decidir sobre el enfoque a
aplicar en diversas partes del proyecto y minimizar las probabilidades de fracaso del proyecto.
⚫ Cada ciclo del modelo consiste de cuatro fases principales:
− Planificación → Se determinan los objetivos, alternativas y restricciones del ciclo.
− Análisis de riesgo → Efectúa análisis de riesgos para determinar los factores más riesgosos de los
objetivos propuestos. Se resuelven los riesgos y se construye un prototipo adecuado (por ejemplo, un
prototipo de los requerimientos en el primer ciclo).
− Ingeniería → Equipo de desarrollo usa el prototipo para evaluar la solución, se prepara un producto
para presentar a los stakeholders.
− Evaluación → Se evalúa si el proyecto va en la dirección correcta, se asegura un acuerdo con los
stakeholders. Si se detectan errores, se debe realizar otro ciclo alrededor del espiral para resolver los
problemas detectados (identificar objetivos no logrados, evaluar alternativas, identificar y resolver
riesgos, producir otro prototipo). Si no hay errores, se inicia la planificación del siguiente ciclo.
⚫ En cada iteración se evalúan las diferentes alternativas y se selecciona una según los riesgos
asociados. Por ejemplo, si los requerimientos son poco claros se podría decidir el uso de un
enfoque iterativo-incremental para analizar los requerimientos.
67
67
ISW – Unidad 1
Modelo Espiral.
Planificación:
- Objetivos Evaluar alternativas
- Alternativas Resolver riesgos
- Restricciones
Evaluación Ingeniería:
del cliente - Desarrollo
- Verificación
Sommerville, Ian, Ingeniería deSoftware 9h Ed. Capítulo 2 68
68
17
16-08-2025
ISW – Unidad 1
Modelo Espiral – Ventajas y Desventajas.
⚫ Otorga a los stakeholders diversas oportunidades para revisar el avance del proyecto.
⚫ Si los riesgos se identifican y resuelven correctamente, se aumentan las probabilidades de éxito.
⚫ Soporte razonable a los cambios. Implica hacer los cambios necesarios y ejecutar un nuevo ciclo.
⚫ Estimaciones de tiempo y esfuerzo se hacen más exactos a medida que los ciclos se finalizan y
los riesgos se eliminan del proyecto.
Desventajas:
⚫ Modelo de gestión complicada.
⚫ Requiere más cantidad de recursos que un modelo más simple (cascada, V).
⚫ Análisis de riesgos requiere personal capacitado y experimentado.
⚫ Nivel excesivo de esfuerzo para proyectos más pequeños.
⚫ Stakeholders deben tener el tiempo y habilidades necesarias para revisar los proyectos en forma
periódica.
⚫ La estimación inicial de tiempo y esfuerzo es inexacta, debido a la probabilidad de tener que
repetir uno o más ciclos.
⚫ Desarrolladores inexpertos tienden a ejecutarlo como una serie de cascadas en espiral.
⚫ No apropiado para proyectos pequeños. Se puede gastar más tiempo y esfuerzo en el análisis de
riesgo, que en el necesario para completar el proyecto.
Modelo aplicable para proyectos muy grandes, muy riesgosos, o con requerimientos muy
cambiantes.
69
69
ISW – Unidad 1
Modelo Espiral – Cronograma General de Actividades.
⚫ La extensión de las tareas no representa su duración, sólo refleja la secuencia.
⚫ Si en la fase de evaluación de un ciclo se detectan errores, el ciclo se debe repetir (esta situación no está
reflejada en la carta Gantt). Por esta razón cobran mayor importancia las fases de Evaluación de Riesgos y de
Ingeniería.
70
70
18
16-08-2025
ISW – Unidad 1
Evolución Comparativa de las Funcionalidades del Sistema.
Versión 1 Versión 2 Versión 3 Versión 4
Predictivo
V, Espiral
Cascada
Fidelidad
Iterativo
Fidelidad
Incremental
Fidelidad
Fidelidad
Ágil
71
71
ISW – Unidad 2
Modelo Espiral – Ejercicio.
ACME-Telecom (A-T) inició un proyecto de un sistema de comunicación satelital para teléfonos
celulares, que permita la comunicación en cualquier parte del mundo. La idea es que dos celulares
se puedan comunicar siempre que ambos estén dentro de una zona con cobertura de alguna
estación base.
El sistema funcionaría a través de 70 satélites en órbitas geo-estacionarias. Los satélites captarían
directamente las señales de un teléfono origen y las re-transmitirían a un teléfono destino.
Dado que la distribución del conjunto de satélites cubriría toda la Tierra, sería posible la
comunicación entre puntos remotos, como en la Antártica o en medio del océano.
Los riesgos del proyecto son variados, por ejemplo: cómo realizar el traspaso de señales entre
satélites que están girando a gran velocidad.
Dado que no existe material publicado ni experiencia en desarrollo de sistemas similares,
muchos de los riesgos no se pueden identificar al inicio del proyecto y es probable que surjan a
medida que éste avanza. Se estima que el software requerirá varios millones de líneas de
código, luego se piensa en la utilización de un modelo espiral.
¿Qué actividades serían necesarias en el primer ciclo del modelo?
72
72
19
