Desarrollo en Espiral

El proceso de desarrollo de software en Espiral

Ing. Jorge Luis Chuc Lpez
Instituto Tecnolgico de Campeche

Es una familia de procesos de desarrollo de software que se caracteriza por iterar de manera repetitiva un conjunto de procesos elementales de desarrollo y administrar los riesgos, buscando reducirlos de manera activa.

25/09/2007

Ing. Jorge Luis Chuc Lpez

25/09/2007

Ing. Jorge Luis Chuc Lpez

Determina alternativas de objetivos y restricciones

Evala alternativas Identifica, resuelve riesgos Anlisis de Riesgo Anlisis de Riesgo Prototipo operacional

Desarrollo en Espiral
El proceso se representa como una espiral y no como una secuencia de actividades con retroceso. Cada vuelta en la espiral representa una fase en el proceso. No existen fases fijas como especificacin o diseo
Las vueltas en la espiral se eligen dependiendo de lo que se requiera.

Anlisis de Riesgo Anlisis de REVISIN Riesgo Prototipo 2

Proto tipo 1

Prototipo 3

Plan de requerimientos Plan de ciclo de vida Concepto de operacin Plan de desarrollo

Validacin de requerimientos

Simulaciones, modelos, benchmarks

Requerimientos de software

Diseo del producto

Diseo detallado

Plan de la siguiente fase

Plan de integracin y pruebas

V y V del diseo
Pruebas de integracin

Cdigo Pruebas de unidad

Servicio

Pruebas de aceptacin

Desarrolla, verifica, el producto del siguiente

Los riesgos se evalan explcitamente y se resuelven a lo largo del proceso.

3 25/09/2007 Ing. Jorge Luis Chuc Lpez 4

25/09/2007

Ing. Jorge Luis Chuc Lpez

Desarrollo en Espiral
Establecimiento de objetivos
Se identifican los objetivos especficos para la fase.

Principales caractersticas del Modelo de desarrollo en Espiral

Ingeniera cclica concurrente. Determinacin del proceso y el producto conducido por el riesgo. Crecimiento del sistema mediante experimentacin y elaboracin conducido por el riesgo. Disminucin del costo de desarrollo mediante la eliminacin temprana de alternativas no viables y evitando el retrabajo.
25/09/2007 Ing. Jorge Luis Chuc Lpez 6

Evaluacin y reduccin de riesgos

Se evalan los riesgos y las actividades se realizan reduciendo los riesgos claves.

Desarrollo y validacin
Se elige un modelo de desarrollo para el sistema, el cual puede ser uno de los modelos genricos.

Planeacin
Se revisa el proyecto y se planea la siguiente fase del modelo en espiral.
25/09/2007 Ing. Jorge Luis Chuc Lpez 5

El Modelo de desarrollo en Espiral

Como resultado de la planeacin y el anlisis del riesgo, diferentes proyectos pueden elegir diferentes procesos. Diferentes patrones de riesgo pueden llevar a elegir un proceso incremental, en cascada, prototipo evolutivo u otros subconjuntos de los elementos de proceso en el diagrama del modelo en Espiral.

Malas interpretaciones a evitar

El modelo en espiral es slo una secuencia de incrementos en cascada. Todo en el proyecto sigue una nica secuencia en espiral. Cada elemento en el diagrama requiere ser visitado en el orden indicado. No puede haber marcha atrs para volver a visitar decisiones previas.
25/09/2007 Ing. Jorge Luis Chuc Lpez 8

25/09/2007

Ing. Jorge Luis Chuc Lpez

Definicin de Modelo de desarrollo en Espiral

El modelo de desarrollo en Espiral es un generador de modelo de proceso conducido por el riesgo. Se utiliza para guiar la ingeniera concurrente con mltiples personas interesadas de sistemas intensivos de software. Tiene dos caractersticas principales distintivas. Una es un enfoque cclico para crecer incrementalmente el grado de definicin e implementacin de un sistema mientras se decrementa su grado de riesgo. La otra es un conjunto de hitos de puntos ancla para asegurar el compromiso de las personas interesadas para con las soluciones del sistema factibles y mutuamente satisfactorias.
25/09/2007 Ing. Jorge Luis Chuc Lpez 9

Riesgos
Son situaciones o posibles eventos que pueden causar el fracaso de un proyecto en el logro de sus metas.
Impacto: de lo trivial a lo fatal. Probabilidad: de la certeza a lo improbable.

Un plan de administracin de riesgos enumera los riesgos y les asigna prioridades en el grado de importancia, medidos con base en el impacto y la probabilidad. Cada plan de riesgo tambin establece una estrategia de mitigacin para enfrentar el riesgo.
25/09/2007 Ing. Jorge Luis Chuc Lpez 10

Hitos de punta de ancla

Conducen la espiral para progresar hasta su terminacin y ofrecen los medios para comparar el progreso entre un proyecto en espiral y otro.

Invariantes del proceso en Espiral

Los ciclos del modelo en Espiral invariablemente despliegan seis caractersticas. 1. Determinacin de artefactos concurrente en lugar de secuencial.

25/09/2007

Ing. Jorge Luis Chuc Lpez

11

25/09/2007

Ing. Jorge Luis Chuc Lpez

12

Invariantes del proceso en Espiral

2. Consideracin en cada ciclo de la
espiral de los elementos principales:
Objetivos y restricciones de las partes interesadas crticas. Alternativas de procesos y producto. Identificacin y resolucin de riesgos. Revisin de las partes interesadas. Compromiso para proceder.
25/09/2007 Ing. Jorge Luis Chuc Lpez 13

Invariantes del proceso en Espiral

3. Utilizar consideraciones de riesgos
para determinar el nivel de esfuerzo a ser dedicado a cada actividad dentro de cada ciclo de la espiral. 4. Utilizar consideraciones de riesgos para determinar el grado de detalle de cada artefacto producido en cada ciclo de la espiral.
25/09/2007 Ing. Jorge Luis Chuc Lpez 14

Invariantes del proceso en Espiral

5. Administrar los compromisos de ciclo
Objetivos de ciclo de vida (Life Cycle Objectives, LCO). Arquitectura de ciclo de vida (Life Cycle Architecture, LCA). Capacidad Operacional Inicial (Initial Operational Capability, IOC).
25/09/2007 Ing. Jorge Luis Chuc Lpez 15

Invariantes del proceso en Espiral

6. nfasis en las actividades y artefactos
para el sistema y ciclo de vida en lugar de para el software y el desarrollo inicial.

de vida de las partes interesadas con tres hitos de punta de ancla:

25/09/2007

Ing. Jorge Luis Chuc Lpez

16

Invariante 1
Es crtico para el xito determinar concurrentemente una combinacin compatible y factible de artefactos clave:
Concepto operacional Requerimientos del sistema y del software. Los planes Arquitectura y diseo del sistema y del software. Componentes clave de cdigo incluyendo COTS, componentes reutilizados, prototipos, componentes crticos para el xito y algoritmos.
25/09/2007 Ing. Jorge Luis Chuc Lpez 17

Invariante 1
Por qu es una invariante?
Evita compromisos secuenciales prematuros para los requerimientos, diseo, COTS, combinacin de costo/calendario/eficiencia del sistema. Ejemplo: Tiempo de respuesta de un segundo.

Variaciones:
1a. Cantidad relativa de cada artefacto desarrollado en cada ciclo. 1b. Nmero de miniciclos concurrentes en cada ciclo.

Modelos excluidos:
Cascada secuencial incremental con alto riesgo de violar las suposiciones del modelo de cascada.
25/09/2007 Ing. Jorge Luis Chuc Lpez 18

Invariante 2
Identifica a las actividades en cada cuadrante del diagrama de espiral original que se requieren efectuar en cada ciclo de la espiral.
Consideracin de los objetivos y restricciones de las partes interesadas crticas. Elaboracin y evaluacin de alternativas del proyecto y el proceso para lograr los objetivos considerando las restricciones. Identificacin y resolucin de los riesgos cuidando las opciones de las soluciones alternativas. Revisin y compromiso para proceder de las partes interesadas con base en la satisfaccin de sus objetivos crticos y restricciones.
Ing. Jorge Luis Chuc Lpez 19

Invariante 2
Por qu es una invariante?
Evita el compromiso con alternativas demasiado riesgosas o inaceptables para las partes interesadas. Evita el desperdicio de esfuerzo en la elaboracin de alternativas no satisfactorias. 2a. Eleccin de tcnicas de resolucin de riesgos: elaboracin de prototipos, simulacin, modelado, benchmarking, verificacin de referencia, etc. 2b. Nivel de esfuerzo en cada actividad dentro de cada ciclo. Fases secuenciales con la exclusin de las partes interesadas clave.

Variaciones:

Modelos excluidos:

25/09/2007

25/09/2007

Ing. Jorge Luis Chuc Lpez

20

Invariante 2: Modelos excluidos: fases secuenciales sin las partes interesadas

Invariante 3
Dicta el uso de las consideraciones de riesgo para responder a las preguntas difciles sobre cunto-es-suficiente de una actividad especfica.
Cunto es suficiente de ingeniera de dominio? De elaboracin de prototipos? De pruebas? De administracin de la configuracin?

25/09/2007

Ing. Jorge Luis Chuc Lpez

21

25/09/2007

Ing. Jorge Luis Chuc Lpez

22

Invariante 3
Por qu es una invariante?
Determina cunto es suficiente de cada actividad: ingeniera de dominio, elaboracin de prototipo, pruebas, CM, etc. Evita la resolucin del riesgo exagerada o tarda. 3a. Eleccin de mtodos utilizados para el seguimiento de actividades: MBASE/WinWin, Rational RUP, JAD, QFD, ESP, 3b. Grado de detalle de los artefactos producidos en cada ciclo. Desarrollo incremental o evolutivo sin sensibilidad de los riesgos.

Invariante 3

Variaciones:

Modelos excluidos:

25/09/2007

Ing. Jorge Luis Chuc Lpez

23

25/09/2007

Ing. Jorge Luis Chuc Lpez

24

Invariante 4
Es la contraparte de producto de la invariante 3: qu consideraciones de riesgo determinan el grado de detalle de los productos como del proceso. Esto significa, por ejemplo, que el ideal tradicional de una especificacin de requerimientos completa, consistente, rastreable y verificable no es una buena idea para ciertos componentes del producto, como GUIs e interfaces COTS. Sin embargo, algunos patrones de riesgo hacen muy importante tener especificaciones precisas, tales como incompatibilidad de interfaces de seguridad crtica entre componentes de Hw y Sw o entre el software de un contratista principal y el de un organismo subcontratado.
25/09/2007 Ing. Jorge Luis Chuc Lpez 25

Invariante 4
Por qu es una invariante?
Determina cunto es suficiente de cada artefacto (OCD, requerimientos, diseo, cdigo, planes) en cada ciclo. Evita la resolucin del riesgo exagerada o tarda.

Variaciones:
4a. Eleccin de representaciones de artefactos (SA/DS, UML, SBASE, especificaciones formales, lenguajes de programacin, etc.

Modelos excluidos:
Especificacin de requerimientos completa, consistente, rastreable y verificable para sistemas que involucran niveles significativos de GUI, COTS o decisiones aplazadas.

25/09/2007

Ing. Jorge Luis Chuc Lpez

26

Invariante 5
Una dificultad principal del modelo en Espiral original era su carencia de hitos intermedios que sirvan como puntos de compromiso y puntos de verificacin de avance. Se ha remediado con el desarrollo de un conjunto de hitos de puntos ancla:

Invariante 5
Estos hitos se pueden describir como puntos de compromiso de las partes interesadas en el ciclo de vida del software:
LCO es el compromiso de las partes interesadas para apoyar la arquitectura; LCA es el compromiso de las partes interesadas para apoyar el ciclo de vida completo; y IOC es el compromiso de las partes interesadas para apoyar las operaciones.

Objetivos del ciclo de vida (Life Cycle Objectives, LCO). Arquitectura del ciclo de vida (Life Cycle Architecture, LCA). Capacidad operacional de inicio (Initial Operational Capability, IOC).
Ing. Jorge Luis Chuc Lpez 27

25/09/2007

25/09/2007

Ing. Jorge Luis Chuc Lpez

28

Invariante 5
Por qu es una invariante?
Evita la parlisis del anlisis, expectativas no reales, cambios sin control en el alcance del proyecto, deriva de la arquitectura, incompatibilidades o dficit de COTS, arquitecturas no sostenibles, sistemas no tiles, etc. 5a. Nmero de ciclos de la espiral o incrementos entre puntos ancla. 5b. Mezclas para situaciones especficas de los hitos de puntos ancla. Desarrollo evolutivo o incremental que no incluyen la arquitectura del ciclo de vida.

Invariante 5
En cada uno de los primeros dos puntos ancla (LCO y LCA) las partes interesadas clave revisan seis artefactos: descripcin del concepto operacional, resultados de prototipos, descripcin de requerimientos, descripcin de la arquitectura, plan del ciclo de vida y fundamento de factbilidad.
25/09/2007 Ing. Jorge Luis Chuc Lpez 30

Variaciones:

Modelos excluidos:

25/09/2007

Ing. Jorge Luis Chuc Lpez

29

Invariante 5
El fundamento de factibilidad trabaja con la pregunta clave de paso/falla: Si yo construyo este producto utilizando la arquitectura y procesos especificados, apoyar el concepto operacional, lograr los resultados de prototipos, satisfacer los requerimientos y finalizar dentro del presupuesto y calendario de los planes? Si la respuesta es no, deber volverse a trabajar.
25/09/2007 Ing. Jorge Luis Chuc Lpez 31

Invariante 5
La revisin de LCO se concentra en asegurar que cuando menos una opcin de arquitectura es viable desde una perspectiva de negocios. La revisin de LCA se concentra en comprometerse a una nica definicin detallada de los artefactos de la revisin. Los proyectos deben haber eliminado todos los riesgos significativos o tener elaborado un plan de administracin de riesgos aceptable.
25/09/2007 Ing. Jorge Luis Chuc Lpez 32

Invariante 5
El hito LCO es equivalente a un compromiso matrimonial. El hito LCA es equivalente a un matrimonio. El hito IOC constituye un compromiso an ms grande: es equivalente a tener un primer hijo.
25/09/2007 Ing. Jorge Luis Chuc Lpez 33

Invariante 6
Enfatiza que el desarrollo en espiral de sistemas intensivos en software requieren concentrarse no slo en los aspectos de construccin de software, sino tambin aspectos del sistema total y del ciclo de vida. Si tu mejor herramienta es un martillo, el mundo que ves es una coleccin de clavos

25/09/2007

Ing. Jorge Luis Chuc Lpez

34

Invariante 6
El nfasis del modelo en Espiral en usar los objetivos de las partes interesadas para conducir las soluciones del sistema, y en los hitos de punto de ancla del ciclo de vida, gua a los proyectos a concentrarse en los aspectos del sistema y del ciclo de vida. El uso de las consideraciones de riesgo del modelo para conducir las soluciones hace posible adecuar cada ciclo de la espiral a cualquier mezcla de Sw y Hw, opciones de capacidades o grado de productizacin que sea apropiada.

Invariante 6

25/09/2007

Ing. Jorge Luis Chuc Lpez

35

25/09/2007

Ing. Jorge Luis Chuc Lpez

36

Invariante 6
Por qu es una invariante? Variaciones:
Evita la suboptimizacin prematura sobre las consideraciones de hardware, software o desarrollo. 6a. Cantidad relativa de Hw y Sw determinado en cada ciclo. 6b. Cantidad relativa de capacidad en cada incremento del ciclo de vida. 6c. Grado de productizacin (alfa, beta, empacado, etc.) de cada incremento del ciclo de vida. Mtodos orientados a objetos puramente lgicos (debido a que no son sensibles a los riesgos, operacionales, de eficiencia y de costo).

Modelos excluidos:

25/09/2007

Ing. Jorge Luis Chuc Lpez

37