• Author / Uploaded
• rober3

Citation preview

ITBA

REPORTES TECNICOS

CAPIS

EL MODELO ESPIRAL Maestrando: Lic. Daniel Corcos Introducción El objetivo de este trabajo consiste en dar una visión más clara del modelo espiral. Esto viene motivado por su creciente importancia en el uso del mismo en grandes proyectos, los cuales cada vez más son permeables al riesgo aspecto que este modelo toma como su fundamento. Los pasos a seguir serán: Breve descripción del mismo, desarrollos de sus etapas, comentarios sobre sus fortalezas y debilidades, alternativas para su mejora y finalmente un enfoque personal del mismo. Nos consideraremos satisfechos si estas breves líneas ayudan a mejorar su entendimiento y contribuyen a su mejor difusión.

Estado de la Tecnología En la actualidad se pueden indicar una infinidad de modelos de ciclo de vida, sin embargo, y a pesar de esta proliferación es dable indicar, a mi entender, que buena parte de ellos se basan en una u otra medida en dos básicos los llamados en cascada y los prototipados. Dentro de los de cascada podrían incluirse: Mejora iterativa, emisión gradual, estándares militares. Dentro de los prototipados podrían incluirse: los alternativos evolutivos y los de producción de software operativos. El modelo espiral surge como un modelo no operativo de producción de software que tiende a poner énfasis allí donde los demás tiene sus debilidades, es decir, en el riesgo a asumir en cada etapa y el control del mismo. Debemos decir no obstante que como modelo reciente en comparación con los demás adolece de algunos inconvenientes que se indicarán pero tiene una manera original de generar software que supera con creces los inconvenientes, sobre todo allí donde los problemas financieros, de tecnologías innovativas o cualidades particulares del software hacen que los otros modelos tiendan a no conformar para su elección. _____________________________________________________________________________________ 1

ITBA

REPORTES TECNICOS

CAPIS

Identificación del Problema Estas líneas no pretenden ser de modo alguno una avanzada sobre el modelo a tratar, teniendo en cuenta que en su corta vida ya tiene varias decenas de libros y cientos o miles de artículos sobre el mismo Nuestro principal afán es el de dar una muy resumida síntesis del mismo y una pequeña aportación personal que no incluyen ninguno de los artículos y libros consultados. Bases Iniciales El modelo basa sus características en sucesivas iteraciones hasta cumplir cierto hito o condiciones prefijadas para derivar a partir de allí en los modelos clásicos (cascada o prototipado). En el primer caso una vez realizadas determinado número de iteraciones se pasará a un desarrollo acotado del modelo de cascada. En el ultimo caso lo que se indica es que se usará el ciclo de vida espiral para obtener un prototipo operativo y de allí en mas se utilizara el ciclo de vida propio del prototipo. (Ver Anexo 1). En ningún caso es necesario fijar este hito o las condiciones para pasar a los modelos clásicos en la primera iteración. A diferencia de la idea de estos modelos iterativos donde los espirales suelen ser hacia el centro, es decir, que los primeros ciclos involucran las tareas más importantes y los ciclos mas avanzados tareas de refinamiento hasta llegar al objetivo; en el modelo espiral las primeras iteraciones realizan tareas muy generales que se van ampliando a medida que se abarca los demás ciclos por lo que el espiral se va abriendo a medida que avanzamos y su culminación debe ser hecha por otros caminos y no por sí mismo. Un caso clásico de espiral hacia el centro puede verse en el modelo de Deming de circulo de calidad. (Ver Anexo 2) En el caso del modelo espiral de Boehm las etapas son las mismas para cada ciclo pero las tareas a realizar en cada una son mayoritariamente definidas por el ciclo anterior. El área del espiral así trazado vá abarcando cada vez mas requisitos, limites y condiciones de contorno. A los efectos de referirse diferenciadamente de los aspectos iterativos del inicio a los aspectos de los modelos clásicos Boehm llama a los primeros ciclos interiores y a los segundos ciclos exteriores, si bien estos últimos no tienen en general un aspecto iterativo. Dicho de otra manera los ciclos interiores tienen etapas diferenciadas de los ciclos exteriores siendo para el primer caso: Planificación, Análisis de Riesgo, Ingeniería, Evaluación, Toma de Decisiones, Refinamiento, y para el segundo caso (si hablamos del ciclo de cascada): Factibilidad, Requisitos, Desarrollo Preliminar, Desarrollo Detallado, Codificación, Integración y Prueba, Implementación, Operación y Mantenimiento y Retiro. _____________________________________________________________________________________ 2

ITBA

REPORTES TECNICOS

CAPIS

Un aspecto interesante señalado por el propio autor es que de acuerdo a la característica del modelo real este modelo en espiral, luego de los ciclos internos, deriva en sus ciclos externos directamente en las etapas del prototipado o el de cascada. (Las condiciones de pasaje de los ciclos internos a los externos se indicarán posteriormente). Etapas del Modelo Las etapas del modelo pueden ser las siguientes: TABLA 1. Etapas del Modelo Etapas Planificación

Aspectos a lograr Determinación de objetivos, limites y condiciones de contorno (condiciones que limitan de alguna manera el desarrollo, económicas, de tiempo, etc.) y alternativas.

Actividades Predecir la duración de las actividades y tareas de nivel individual, Recursos requeridos, concurrencia y solapamiento de tareas para el desarrollo en paralelo y camino crítico a través de la red de actividades. Estimar recursos: Predicción de personal esfuerzo y costo que se requerirán para terminar las actividades y productos conocidos asociados con el proyecto. Planificar tareas y solapamiento de actividades y tareas. Definir y desarrollar los requerimientos de software. Definir los requisitos de interfaz. Priorizar e integrar los requisitos de software.

Etapas

Aspectos a lograr

Actividades

_____________________________________________________________________________________ 3

ITBA

REPORTES TECNICOS

CAPIS

Análisis de Riesgo

Desarrollo de un plan para descubrir los riesgos más importantes y resolver los mismos. Eliminación de aspectos no compatibles con las condiciones, o condiciones de contorno o límites. (ver anexo 3)

Ingeniería

Desarrollo del producto o Realizar el diseño prototipo según las condiciones arquitectónico. de la etapa anterior. Analizar el flujo de información. Diseñar la base de datos. Seleccionar o desarrollar algoritmos. Realizar el diseño detallado de la etapa. Crear el código fuente.

Evaluación

Evaluar los resultados del Crear los datos de prueba prototipo obtenido, verificar y de código fuente. validar. Ejecutar las tareas de Verificación y validación.

Identificar ideas o necesidades. Formular soluciones potenciales. Conducir estudios de viabilidad. Planificar la transición del sistema. Refinar y finalizar la idea o necesidad. Analizar las funciones del sistema. Desarrollar la arquitectura del sistema. Descomponer los requisitos del sistema. Planificación de contingencias.

Recoger y analizar los datos de la métrica. Planificar las pruebas. Desarrollar especificaciones pruebas.

de

las las

Ejecutar las pruebas. Generación de los Aspectos de mejora, errores, defectos, ampliaciones.

_____________________________________________________________________________________ 4

ITBA

REPORTES TECNICOS

Etapas Toma de decisiones

Aspectos a lograr Se determina si se pasa al ciclo exterior o se realiza una nueva iteración.

Refinamiento

Si se toma la decisión de continuar en los ciclos internos Se sofistican las condiciones a tomar en cuenta en el planeamiento del nuevo ciclo, en los ciclos exteriores es una etapa que no se utiliza.

CAPIS Actividades Evaluación de resultados. Contraste con los hitos fijados o condiciones predeterminadas. Fijación de las Condiciones de pasaje a los ciclos externos de no haberlas fijado. Repetición del ciclo o pasaje a otro modelo. Técnicas de toma de decisiones (arboles de decisión, decisiones en condiciones de incertidumbre, etc.). No hay actividades específicas, sino aquellas que generan las posibilidades de sofisticar indicadas anteriormente.

Debe indicarse que el número de etapas pueden variarse o subdividirse generando entre cuatro y siete de ellas según la importancia que se pretende dar a cada una por lo que lo que aquí describimos es una interpretación posible de las mismas. La ultima indicada, por ejemplo, podría incorporase a la evaluación pero se la indica explícitamente para dar una idea más clara del fundamento del modulo. Alguna de las etapas tienen tareas o actividades que quizá no se contemplen en forma específica en la norma IEEE 1074-1989, ya que si bien esta norma es independiente del modelo, indica las tareas que se deben realizar pero no es excluyente. Algunas de las tareas no contempladas pueden ser: Análisis de riesgo, identificación, proyección, evaluación, resolución y gestión, toma de decisiones, técnicas de toma de decisiones. De la tabla anterior se podría indicar como ya lo han hecho otros autores que cuando el riesgo es todavía el dominante puede derivarse en un modelo evolutivo (control de interfases en riesgo o problemas con las especificaciones), o en una segunda fase del propio espiral. Si el riesgo es pequeño y se han resuelto todos los problemas de interfases (de usuario, de control, etc.) y como resultado de ello se obtuvo un prototipo operacional es posible derivar a un modelo de cascada. _____________________________________________________________________________________ 5

ITBA

REPORTES TECNICOS

CAPIS

Fortalezas y Debilidades Finalmente podemos indicar las fortalezas y debilidades de este modelo según expresan deferentes autores. Tabla 2. Fortalezas y Debilidades Fortalezas Debilidades Evita las dificultades que corresponden a otros No provee un proceso específico de guía modelos a través de un manejo del riesgo. para determinar los objetivos, alternativas, límites y condiciones de contorno. Trata de eliminar errores en fase temprana. Provee una flexibilidad mas que la conveniente para muchos proyectos. Es el mismo modelo para el desarrollo y el Se necesitan expertos para prever el mantenimiento. riesgo, no siendo una tarea fácil la resolución de dicho riesgo. Provee mecanismos para el aseguramiento de la Es un modelo en pleno desarrollo. calidad del software. Es aplicable a otras clases de proyectos, diferentes Es poco aplicable a proyectos bajo a las de producción de software contrato. Puede ser aplicado a proyectos complejos, No es aplicable a proyectos sencillos dinámicos y ambiciosos. donde su dominio de aplicación es conocido y previsible.

La debilidad citada en última instancia podría no considerarse una debilidad, por ejemplo: Si se fabricó un monitor blanco y negro no se puede decir que una de sus debilidades sea que no puede proyectar colores. Sin embargo, un modelo de ciclo de vida debería poder adaptarse a todas las circunstancias de un desarrollo de software y la única condición para adaptar un modelo de ciclo de vida u otro debería estar dada por el tipo y características intrínsecas del desarrollo y en este sentido algunos autores indican esto como una debilidad. Algunas alternativas para mejorar los aspectos de debilidad de esta teoría están en pleno desarrollo y podrían indicarse como: Tabla 3. Debilidades y Alternativas Debilidades No provee un proceso específico de guía para determinar los objetivos, alternativas, límites y condiciones de contorno.

Alternativas Se puede utilizar la teoría W, donde se trata de consensuar las restricciones de los distintos participantes de manera de obtener los objetivos ganadores (win objetives) de cada parte interviniente y consensuarlos. Del mismo modo se utiliza la teoría para fijar los limites y condiciones de contorno.

_____________________________________________________________________________________ 6

ITBA

CAPIS

REPORTES TECNICOS

Debilidades Alternativas Provee una flexibilidad mas que la conveniente Quizá la propuesta de un espiral para muchos proyectos. cuantitativo dada mas adelante pueda adaptarse mejor al problema de la excesiva flexibilidad pues tiende a contener el modelo en parámetros visibles. Se necesitan expertos para prever el riesgo, no Es un aspecto todavía no resuelto, si bien siendo una tarea fácil la resolución de dicho riesgo. se pueden utilizar técnicas de generación de ideas (brain storming) para mejorar este aspecto. El uso de teorías de decisión puede mejorar el aspecto de toma de decisiones. Es un modelo en pleno desarrollo y no probado en Es un aspecto que el tiempo y lo indicado muchos proyectos. en esta tabla contribuirán a solucionar. Es poco aplicable a proyectos bajo contrato. Están surgiendo nuevas modalidades de contratación como la contratación competitiva y contratos de diseño-costo. No es aplicable a proyectos sencillos donde el Es posible atenuar en algunos casos las dominio de aplicación es conocido y previsible. etapas del espiral a fin que pueda utilizarse en estos casos.

Espiral Cuantitativo (Contribución del Autor) Como idea personal se ha desarrollado un espiral que llamaremos cuantitativo que tiende a dar una imagen del espiral clásico pero adaptado a las situaciones de presupuesto, tiempo, etapas de iteración y avance del proyecto lo que permite a un solo golpe de vista verificar donde sé esta en el proyecto. La idea básica tiende a superponer sobre el espiral clásico 2 ejes cartesianos ortogonales que contiene respectivamente las siguientes características: Eje X positivo:

Cronograma del proyecto en una escala adecuada

Eje X negativo:

Vueltas del espiral por número a distancias regulares

Eje Y positivo:

Presupuesto para cada etapa (en porcentual)

Eje Y negativo;

Avance del proyecto (en porcentual)

La construcción que sigue se basa en las siguientes condiciones hipotéticas. Tabla 4. Datos para la Construcción del Gráfico del Espiral Cuantitativo Fase 1

Presupuesto (%) 20

Cronograma (Meses) 8

Requisitos Cumplidos (%) 40

2

40

12

50

Decisiones Tomadas Continuar el espiral Continuar el espiral

_____________________________________________________________________________________ 7

ITBA

CAPIS

REPORTES TECNICOS

Se puede agregar a cada eje una marca o hito (o más de una de ellas) que nos permitiría apreciar cuan cerca o lejos estamos de determinada restricción, limite o característica del proceso como puede ser el presupuesto para el ciclo interno o externo, los requisitos (en porcentaje) fijados como base y el tiempo límite para los ciclos internos o todo el desarrollo.

100 Presupuesto (%) 90 80 70 60 50

Determinación de objetivos, limites y condiciones de contorno

40

Análisis de riesgo y resolución de los mismos

30 20 Etapas o ciclos

5

Cronograma (en meses o escala adecuada)

10

4

3

2

4

1

8

12

16

20

10 20

Evaluación y toma de decisiones

30

Ingeniería

40 50 60 70 80 90

Avance (Cumplimiento de requisitos)

_____________________________________________________________________________________ 8

ITBA

REPORTES TECNICOS

CAPIS

ANEXO 1 En este anexo se trata de indicar las similitudes modelos de prototipado y el modelo espiral.

y diferencias entre los

Tabla 5. Similitudes y Diferencias entre el Modelo Espiral y el Prototipado Modelo Espiral y Modelo de Prototipado Similitudes

Modelo Espiral y Modelo Prototipado Diferencias

Ambos modelos contienen componentes para El modelo espiral es mas abarcativo que el establecer objetivos, desarrollo del modelo y modelo de prototipado. evaluación del mismo.

Ambos modelos pueden ser usados con una El modelo espiral incorpora el análisis de terminación en ciclo de vida en cascada. riesgo el cual no esta representado en el modelo prototipado.

La calidad del software es incluida como uno de El modelo prototipado es manejado los objetivos del modelo espiral y un crecimiento de primariamente por el código y pone una la calidad del software puede ser consecuencia del poca atención a la gestión del riesgo. modelo prototipado.

El prototipado es la llave técnica de la evaluación El modelo espiral es mas apropiado para del riesgo en el modelo espiral. grandes proyectos mientras que el de prototipado es apropiado para pequeños sistemas o proyectos.

Los prototipos evolutivos pueden ser incluidos en el La naturaleza de modelo manejado por el modelo espiral para el caso donde un prototipo riesgo del espiral hace que este pueda detallado sea útil. adaptarse a una mucho más amplia gama de proyectos de software que el prototipado.

_____________________________________________________________________________________ 9

ITBA

CAPIS

REPORTES TECNICOS

Anexo 2 Figura 1. Espiral de la Calidad de Deming Planificar Comercializar y Analizar

Hacer

Testear

El círculo de calidad de Deming suele también llamarse PDCA del ingles Plan, Do, Check, Act y Analyze, que en castellano podríamos indicar como Planificar, Hacer, Testear, Comercializar y Analizar. Como se observa el ciclo en el paso final se debe rediseñar y mejorar lo que provocará un nuevo ciclo. Sin entrar a analizar las bondades o defectos de este método, el citarlo es solamente para realizar unas consideraciones sobre el tipo de espiral que provoca. En el primer paso, cuando aún no se tiene el producto y debe hacerse el estudio de mercado, diseñarlo, planificar su producción, fabricarlo, verificar lo obtenido, imponerlo en el mercado y volver a realizar el estudio para posibilitar medir la respuesta de los consumidores estaríamos en la fase mas amplia del espiral. Los trabajos de rediseño, mejora etc. son generalmente menores que el primero dado que la base ya esta lanzada (salvo que nos hubiéramos equivocado en el primer paso estrepitosamente), de allí que esta segunda y demás vueltas del espiral son hacia adentro. Si bien podría decirse que siempre se pude mejorar, rediseñar etc., en general esto termina en algún momento para el producto lanzado y en vez de continuar las mejoras se piensa en otro que abarque todas las funciones de este y las mejore. Téngase en cuenta que de no ser así, no habría un modelo de fabricación y cada partida sería de alguna manera diferente a la anterior lo cual es contraproducente desde el punto de vista comercial

_____________________________________________________________________________________ 10

ITBA

REPORTES TECNICOS

CAPIS

Anexo 3 Diferentes Tipos de Riesgo y sus Formas de Tratarlos Riegos Identificación de Riesgos Análisis de Riesgos Costo y Calendario

Formas de Tratarlos Lista de Chequeo Taxonomía basada en riesgos Análisis de manejo de decisiones Arbol de Decisiones Modelo de Nodos (PERT) Trabajo de rotura de estructuras (WBS) Modelo de Putman Cocomo Método del Factor de Riesgo

Presupuesto

Resolución del Riesgo

Reducción Protección Transferencia Prototipado Modelado Simulación Benchmarking

Desarrollo de la Ingeniería

Lista de Chequeo

Recursos Humanos Monitoreo del Riesgo

Acciones de Proactividad Monitoreo de los 10 riesgos principales Revisión e Inspección Indice de Madurez del Software Métrica Entrenamiento Comunicación

Desarrollo, Control del Planeamiento

Aspectos Colaterales al Riesgo

Bibliografía: Andrea Gabor Granica SPC-93098-CMC

Deming, "El Hombre que Descubrió la Calidad", Editorial: "Evolucionary Spiral Process Model Guidebook"

Boehm Barry W. "A Spiral Model of Software Development and Enhancement" Humphrey, Watts S. "A Discipline for SoftwareEngineering" Herz M. "Relationship To The Spiral Model" Hertz M. "Strengths and Weaknesses of The Spiral Model" _____________________________________________________________________________________ 11

ITBA

REPORTES TECNICOS

CAPIS

Boehm, Barry W. y otros "Developing Multimedia Applications with the Win Win Spiral Model". Krumholtz, Nira "The Spiral Model of Technology Evolution: A Base for curriculum Development" Sullivan, Kevin J.

"Real Option in Software Engineering".

Ghezzi Carlo y otros "Fundamentals of Software Engineering". Pressman, Roger S. "Ingeniería del Software". Un Enfoque Práctico Kim, Jongseok: "Risk Management in the Spiral Model"

_____________________________________________________________________________________ 12