Administración de Requerimientos

Administración de Requerimientos 1

Agenda Software Requirements Knowledge Areas. Requirement Statement. Requirement Specification. Agreement and Expectation Mgmt.. Las 5 dimensiones. Change Request Managment SRM Process Change Control Board Requerimientos y gestión de riesgos Ciclos de vida y riesgo. 2 2

Software Requirements Qué es? Una condición o capacidad necesaria para un usuario para resolver un problema o alcanzar un objetivo. Una condición o capacidad que se debe alcanzar o debe poseer un sistema o componente para satisfacer un contrato, estándar, especificación u otra formalidad impuesta. Una representación documentada de alguna condición o capacidad descrita en los dos puntos anteriores. 3 3

Proceso Esencial de Software Real World System Tiempo de exposición 2 Proceso esencial de software concebido bajo Tech Orientacion a objetos y la creacion de aplicaciones monoliticas. Ausencia de requerimientos de integracion up-front Transicion: Esto nos lleva a una integracion Add-hoc 4

Software Requirements - Areas de Conocimiento Requirement Engineering Requirement Development Requirement Management Elicitation Analysis Specification Validation 5 5

Requirements Statement Characteristics Complete Correct Feasible Necessary Prioritized Unambiguous Verfiable 6 6

Requirements Specification Characteristics Complete Consistent Modifiable Traceable 7 7

Software Requirements - Areas de Conocimiento Requirement Engineering Requirement Development Elicitation Requirement Management Project Agreement Analysis Specification Validation 8 8

Agenda Software Requirements Knowledge Areas. Requirement Statement. Requirement Specification. Agreement and Expectation Mgmt.. Las 5 dimensiones. Change Request Managment SRM Process Change Control Board Requerimientos y gestión de riesgos Ciclos de vida y riesgo. 9 9

Acuerdo: por qué? para qué? Cuándo? Para cumplir nuestros objetivos. Para encontrar mejores objetivos. A lo largo del proyecto, negociando Distintas cosas. En distintos niveles. En distintos procesos. De distinta manera. Con objetivos distintos. 10 10

La negociación es distinta en distintos procesos 11 11

Para lo que nos interesa aquí nos centramos... En la Iniciación La iniciación es el proceso de autorizar formalmente un nuevo proyecto o la de permitir que un proyecto ya existente continúe en su fase siguiente. Esta iniciación formal vincula el proyecto con el trabajo continuo de la organización ejecutante. Qué forma parte de la Gestión del Alcance del Proyecto? La gestión del alcance del proyecto incluye los procesos para asegurar que el proyecto incluya todo el trabajo requerido, y solamente el trabajo requerido, de manera tal de completar exitosamente el mismo.. 12 12

Negociar: Que cosas? Las 5 dimensiones Funcionalidades Recursos Humanos Calidad Tiempo Costo 13 13

Relación entre las dimensiones No son independientes entre sí No se relacionan linealmente Cada proyecto es crítico en algunas dimensiones y es mas libre en otras Cumplir con los objetivos requiere balancear las dimensiones 14 14

No todos las dimensiones son iguales Hay aspectos que nos limitan fuertemente y que no podemos controlar: restricción (constraint) Hay aspectos en los que tenemos objetivos que alcanzar: Conductor (driver) Hay aspectos que no son ni uno ni otro: Grado de libertad Esto define las prioridades relativas en el balance entre las dimensiones 15 15

Diagrama de Kiviat Al centro (restringido) <-> Afuera (libre) Recursos Humanos Funcionalidades Calidad Tiempo Costo 16 16

Houston, we have a problem Recursos Humanos Funcionalidades Calidad Tiempo Costo 17 17

Ser millonario y hippie Recursos Humanos Funcionalidades Calidad Tiempo Costo 18 18

Sistema de información interno Recursos Humanos Funcionalidades Calidad Tiempo Costo 19 19

Aplicación comercial competitiva Recursos Humanos Funcionalidades Calidad Tiempo Costo 20 20

Sistemas Quality Driven Recursos Humanos Funcionalidades Calidad Tiempo Costo 21 21

Lo importante Merece especial atención la negociación sobre el alcance del proyecto: es de las primeras cosas que se negocia... Y está en tensión todo el proyecto. Cuando cambia la realidad (e.g. Requerimientos, RR HH...) sirve para ver como hay que cambiar el proyecto. Las dimensiones sirven para pensar, negociar objetivos y tomar decisiones realistas. Para cada restricción: cuál es su valor límite? Para cada conductor: cuál es el objetivo? Para cada grado de libertad: cuáles son sus límites? El dibujo es sólo una ayuda gráfica. 22 22

Agenda Software Requirements Knowledge Areas. Requirement Statement. Requirement Specification. Agreement and Expectation Mgmt.. Las 5 dimensiones. Change Request Managment SRM Process Change Control Board Requerimientos y gestión de riesgos Ciclos de vida y riesgo. 23 23

Change Request Management Change Request Management es el almacenamiento, seguimiento y emisión de reportes de requerimientos provenientes de cualquier stakeholder para cambiar un sistema de software. 24 Change Request Management Change Request Management es el almacenamiento, seguimiento y emisión de reportes de requerimientos provenientes de cualquier stakeholder para cambiar un sistema de software. Esto incluye el proceso de toma de decisión en cuanto a que cambios realizar y el proceso de resolución utilizado para hacer esto posible. Sin almacenamiento, los requerimientos de cambio podrían ser perdidos o permanecer desconocidos por parte del team. Sin seguimiento, los cambios se saldrán de schedule o permanecerán indireccionados. 24

Qu Qué es Change Request? Change Request es un término general utilizado para identificar cualquier requerimiento proveniente de un stakeholder para cambiar un artifact o proceso. La documentación requerida para acompañar un requerimiento de cambio, es el origen y el impacto del problema, la solución propuesta y una evaluación de su costo. 25 Change Request Management Change Request es un término general utilizado para identificar cualquier requerimiento proveniente de un stakeholder para cambiar un artifact o proceso. La documentación requerida para acompañar un requerimiento de cambio es el origen y el impacto del problema, la solución propuesta y una evaluación de su costo. 25

Change Request Los requerimientos de cambio son divididos en dos categorías: enhancements y defects. Los Enhancement Requests especifican funciones nuevas o cambios en el diseño del comportamiento del sistema. Los Defects en cambio, son anomalías en el producto entregado, un error en el software generará un tema a ser seguido hasta ser resuelto. 26 Change Request Management Change Request Los requerimientos de cambio son divididos en dos categorías: mejoras y errores (enhancements and defects). Los Enhancement Requests especifican funciones nuevas o cambios en el diseño del comportamiento del sistema. Los errores (Defect) en cambio, son anomalías en el producto entregado, un error en el software generará un tema a ser seguido hasta ser resuelto. Indicar que la información recolectada es esencialmente distinta para cada uno de los casos. 26

CRM - Proceso El proceso de monitoreo de los change requests está representado en la mayoría de las herramientas de CRM como un workflow 27 Change Request Management Proceso El proceso está representado a través de un workflow que refleja el estado del Change Request en todos sus puntos de tratamiento. 27

CRM - Proceso Change Request submission Submitted Complete evaluation completion Evaluated Verified decision verification Revised In Process Send to development 28 Change Request Management Proceso Además de esto, las actividades podrían finalizar en la clausura del CR sin completarlo. Este esquema presentado es el ideal donde el CR es recibido, aceptado, categorizado, implementado, verificado y cerrado sin tener en cuenta el tratamiento de excepciones. 28

CRM - Proceso Registro del CR Change Request submission Submitted Complete evaluation completion Evaluated Verified decision verification Revised In Process Send to development 29 Change Request Management Proceso Registrado (Submitted) En esta etapa los cambios requeridos son registrados. Defect y Enhancements Requests difieren en el tipo de información que debe ser registrada. Para el caso de enhancements se necesita conocer la importancia del requerimiento para el cliente, con todo el detalle posible acerca del cambio, las restricciones de tiempo impuestas desde fuera de la compañía e identificar al solicitante inicial. En caso de defects, es de suma importancia identificar el modo en el cual han sido descubiertos los errores, como puede reproducirse el error, la severidad del mismo y quien lo ha descubierto. Existe el concepto de shortcut para los casos donde el cambio sea de emergencia. En estos casos el proceso presentado en estos slides alcanza directamente la fase de In Process proviniendo del Configuration Control Board. En resumen, defects y enhancement requests comparten los mismos datos claves, tendiendo en el caso de los defects la información asociada de severidad, usuario referente que identificó el error, y la versión de software que estaba siendo ejecutada. 29

CRM - Proceso Evaluación, categorización y establecimiento de prioridad Change Request submission Submitted Complete evaluation completion Evaluated Verified decision verification Revised In Process Send to development 30 Change Request Management Proceso Evaluado (Evaluated): Durante la evaluación alguien deberá revisar los nuevos cambios requeridos y determinar la severidad, duplicidad, determinar si efectivamente se trata de una mejora o un error y si el error puede efectivamente ser reproducido. Todo error debe ser reproducido y confirmado en esta etapa. La prioridad también será establecida en esta etapa basándose en la severidad del caso y en la importancia de que sea resuelta. Las mejoras requeridas no necesitan ser confirmadas, en este caso se establece simplemente la prioridad en relación con los demás requerimientos de mejora existentes. 30

CRM - Proceso Qué y cuando implementar Change Request submission Submitted Complete evaluation completion Evaluated Verified decision verification Revised In Process Send to development 31 Change Request Management Proceso Revisado (Revised): Aquí se decide cuando un cambio es implementado, si debe ser pospuesto o directamente rechazado. Los enhancement requests y defects son tratados en forma diferente. La implementación de los requerimientos de mejora es decidida por el gerente de producto o el analista. Todos estos requerimientos son medidos en forma conjunta para determinar en que release serán liberados, cuando deberían ser realizados basados en la información obtenida durante la etapa de evaluación. El tratamiento de los errores depende de la etapa del ciclo de vida en la cual han sido detectados y el tamaño del esfuerzo de desarrollo para corregirlos. En etapas iniciales del ciclo de vida los errores son resueltos de manera informal. En cambio, a medida que nos acercamos al final del ciclo de vida, queremos restringir los cambios solo a los casos en que sea estrictamente necesario hacerlos. Cambios sin control sobre el final del ciclo de desarrollo afectan el orden y seguimiento del proyecto, introducen nuevos riesgos y generalmente causan encarecimiento del costo y desviación de la agenda del proyecto. 31

Decision - Configuration Control Board el comité que monitorea el proceso de cambio consiste en representantes de todas las partes interesadas, incluyendo clientes, desarrolladores, y usuarios. En proyectos pequeños una sola persona, como por ejemplo el gerente de proyecto o el arquitecto de software, podría jugar dicho role. 32 Change Request Management Proceso Revisado (Revised): Configuration Control Board Organizaciones de mayor envergadura cuentan usualmente con procesos de revisión formal sobre los requerimientos de cambio realizados por una estructura de control llamada Change/Configuration Control Board. CCB está estructurada regularmente en forma matricial (abarca roles funcionales y de IS) y balancea en los casos que existe litigio entre el área de calidad y agenda del proyecto durante el desarrollo. Se puede definir como el equipo que monitorea el proceso de cambio consiste en representantes de todas las partes interesadas, incluyendo clientes, desarolladores, y usuarios. En proyectos pequeños una sola persona, como por ejemplo el gerente de proyecto o el arquitecto de software, podría jugar dicho role. the board that oversees the change process consisting of representatives from all interested parties, including customers, developers, and users. In a small project a single person, such as the project manager or software arquitect, may play this role [White 2000, page 260] CCB difiere enormemente de acuerdo al tipo de proyecto, la compañía y el tamaño y costo del programa. Sin embargo, en todos los casos donde encontremos CCB que no sean unipersonales deberemos contar con una estructura CCB. 32

Configuration Control Board - Estructura CCB del Proyecto CCB Funcional CCB Basis CCB Módulo FI CCB Módulo MM CCB Módulo WM CCB Hardware CCB Tech Support CCB App. Servers 33 Change Request Management Proceso Revisado (Revised): Configuration Control Board CCB Structure Estas estructuras normalmente conforman una especie de modelo de cascada donde contamos con un número bastante grande de CBs en los niveles inferiores que van siendo consolidados por niveles superiores en forma de pirámide hasta alcanzar un único CB. Los cambios generalmente son generados en los niveles inferiores donde la actividad de programación los genera. En otros casos, el camino inverso es tomado cuando un requerimiento de un cliente o un gerente de proyecto. Debería existir una ruta alternativa preparada para administrar cambios de emergencia de modo que la integridad de todo el proceso no se vea afectada por este tipo de situaciones. Dentro de la estructura jerárquica del CCB, la decisión final recae sobre una única persona. El nivel superior decide cuando un parche de emergencia debe ser implementado o una CR autorizado, en muchos casos donde los cambios son mínimos, esta decisión es delegada a los niveles inferiores de la estructura. 33

CRM - Proceso Change Request submission Submitted Complete evaluation completion Evaluated Verified decision verification Revised In Process Send to development System Artifact son modificados o creados. La documentación es actualizada. 34 Change Request Management Proceso En Proceso (In Process): Durante esta etapa los artifacts son modificados o creados en busca de satisfacer el requerimiento de cambio. En esta etapa las diferencias entre enhancement request y defect son mas significativas dado que el primer caso contempla una nueva funcionalidad que puede implicar un nuevo diseño. Defects en cambio, requieren que sea reproducido el entorno en el cual el error se presentó para poder reproducir el mismo y probar la solución implementada. 34

CRM - Proceso Change Request submission Submitted Complete evaluation completion Evaluated Verified decision verification Revised In Process Send to development El CR es usado para verificar que la nueva versión cumple con el CR. 35 Change Request Management Proceso Verificado (Verified): En esta etapa se verifica que la solución cumple con el CR. Para el caso de mejoras en el producto es simplemente verificar que el comportamiento del producto es el especificado por el CR con lo cual es suficiente con la ejecución del plan de test funcional. Para la verificación se trabaja exclusivamente sobre el nuevo release. En caso de errores, se debe poder reproducir el error en la versión anterior a los efectos de garantizar que el mismo a sido corregido. 35

CRM - Proceso Change Request submission Submitted Complete evaluation completion Evaluated Verified decision verification Revised In Process Send to development El solicitante es notificado y la información acerca de costos es almacenada. 36 Change Request Management Proceso Cerrado (Complete): El principal paso aquí es cerrar el tema abierto con el stakeholder que inicio el requerimiento de cambio. Dependiendo el nivel de madurez de la organización es en esta etapa que se dispara un nuevo proceso interno donde se intenta identificar los motivos del error y los nuevos errores que estos motivos puedan estar causando (defect prevention). La estadística de costo real y esfuerzo en encontrar la solución debe ser registrada para alimentar la experiencia del equipo del proyecto. 36

Agenda Software Requirements Knowledge Areas. Requirement Statement. Requirement Specification. Agreement and Expectation Mgmt.. Las 5 dimensiones. Change Request Managment SRM Process Change Control Board Requerimientos y gestión de riesgos Ciclos de vida y riesgo. 37 37

Ciclo de Vida Es el conjunto y la disposición de las actividades que suceden desde la concepción del sistema hasta que el mismo es desinstalado de la última maquina del usuario. Tiene como función establecer el criterio bajo el cual proceder de un tipo de tareas a otro. 38 Ciclo de Vida Dependiendo del ciclo de vida que uno elija, es posible mejorar la velocidad del desarrollo, mejorar la calidad, facilitar el seguimiento, reducir la exposición a riesgos o mejorar el contacto con el cliente. La elección errónea puede producir reducción en la productividad, retrabajo y frustración. 38

Code and Fix Especificación del sistema (Tal vez exista) Release (Tal vez) 39 Ciclo de Vida Code and Fix Este ciclo de vida es raramente útil pero sin embargo altamente utilizado. Si no se ha explícitamente elejido un ciclo de vida probablemente sea éste el que esté siendo usado. El ciclo comienza con una idea general sobre lo que debe ser construido. Es posible que exista una especificación, sin ser la misma necesaria para comenzar a construir. Luego se comienza a usar cualquier combinación de metodologías de diseño informal, codificación y testing hasta que el producto está listo para ser liberado. 39

Especific ación del sistema (Tal vez exista) Code and Fix Release (Tal vez) Puede llegar a ser útil para pequeños proyectos donde se sabe de antemano que el producto será rápidamente descartado. Dos ventajas: No posee overhead. No requiere ningún tipo de conocimiento. Muchas desventajas, entre otras: No tenemos forma de asegurar que existe progreso alguno. No tenemos forma de controlar la calidad ni de identificar riesgos. Es muy probable que se alcancen puntos en el proyecto donde sea necesario descartar absolutamente todo lo realizado. 40 Ciclo de Vida Code and Fix El modelo tiene dos ventajas. Primero, no posee overhead: uno salta directamente a codificar, uno cree que posee inmediatamente signos de progreso. Segundo, no requiere ningún tipo de conocimiento excepto saber programar: cualquiera puede usarlo. Para pequeños proyectos que uno sabe que serán descartados rápidamente luego de ser usados, este modelo puede llegar a ser útil (programas de conversión de datos para una migración, pruebas de concepto en general, etc.). Para cualquier otro projecto este modelo es peligroso. Puede ser que no tenga overhead pero tampoco tenemos forma de asegurar que existe progreso alguno. Uno codifica hasta que el producto se considera listo ( listo no tiene métrica asociada tampoco). No tenemos forma de controlar la calidad ni de identificar riesgos. Es muy probable aquí que se alcancen puntos en el proyecto donde sea necesario descartar absolutamente todo lo realizado justamente por no estar el objetivo bien definido y comprendido. 40

Pure Waterfall Concepto Análisis de Requerimientos Diseño Arquitectónico Diseño Detallado Codificación y Debugging Prueba de Sistema 41 Ciclo de Vida Pure Waterfall Bajo este ciclo de vida el proyecto progresa a través de una secuencia ordenada de pasos desde la concepción inicial del Software. El proyecto contempla una revisión al final de cada paso para determinar si se pasará al siguiente. Esto hace que sea posible permanecer por un tiempo indeterminado sobre uno de los pasos si dicha revisión no es alcanzada. El modelo waterfall es orientado a la documentación lo que significa que la gran mayoría de los productos de software que son intercambiados entre etapas son documentación. Las etapas no se solapan en este modelo. 41

Pure Waterfall Salmon s Model 42 Ciclo de Vida Pure Waterfall Salmon s Model Es posible retroceder en las fases pero esto puede costarnos el proyecto 42

Concepto Pure Waterfall Análisis de Requerimientos Diseño Arquitectónico Diseño Detallado Codificación y Debugging Prueba de Sistema Muy útil cuando los requerimientos de calidad dominan el costo y el cronograma. Debo conocer muy bien los requerimientos y los mètodos a ser usados. Ventajas Produce Sistemas Confiables y de alta calidad. Minimiza el overhead de planning. Desventajas Dificultad de obtener requerimientos completamente especificados al inicio del proyecto. La visualización de resultados se presenta al finalizar el proyecto. No es flexible. No apropiado para desarrollos rápidos por cantidad de documentación. 43 Ciclo de Vida Pure Waterfall En proyectos donde hay alta estabilidad funciona bien. La estabilidad se relaciona con un gran conocimiento de los requerimientos y de los métodos que serán usados. En estos casos no sólo es un modelo eficiente sino que es el correcto a usar puesto que tenemos la oportunidad de encontrar errores de alto impacto en etapas tempranas y de bajo costo. El modelo contribuye a minimizar el overhead en la planificación porque es posible hacer la actividad de planificación al inicio. Por otra parte, no tenemos resultados tangibles hasta el fin del proyecto. El avance debe ser entonces medido a partir de la documentación generada durante las etapas. Funciona bien cuando los requerimientos de calidad dominan el costo y el cronograma. Las desventajas del modelo radican en la dificultad de conocer los requerimientos al 100% antes de comenzar a diseñar. 43

Sashimi (Waterfall + Overlapping) Concepto Análisis de Requerimientos Diseño Arquitectónico Diseño Detallado Codificación y Debugging Prueba de Sistema 44 Ciclo de Vida Sashimi En el modelo puro Waterfall, la documentación ideal es la que es pasada de mano en mano entre los equipos de trabajo que operan en las diferentes fases. La pregunta es Por qué?. Si el equipo de trabajo es el mismo que opera en cada una de las fases, entonces no es necesaria la documentación creada para transmitir el conocimiento entre fases. Este cambio reduce la documentación a la necesaria para el posterior mantenimiento del Software. 44

Sashimi (Waterfall + Overlapping) Concepto Análisis de Requerimientos Diseño Arquitectónico Diseño Detallado Codificación y Debugging Prueba de Sistema Aplicable en condiciones similares al pure waterfall pero con equipos más pequeños. Asumimos que el mismo equipo realiza actividades en más de una fase. Ventajas Reduce la documentación necesaria en el purewaterfall. Mismas ventajas que el purewaterfall. Desventajas Mismas dificultades que el pure waterfall. Adicionalmente el solapamiento puede ocasionar conflictos relacionados con la comunicación entre fases solapadas. 45 Ciclo de Vida Sashimi Como existe solpamiento entre fases, los milestones son más ambiguos y esto hace más difícil realizar el seguimiento con cierto nivel de seguridad. Efectuar actividades en paralelo requiere que las actividades solapadas estén bien comunicadas, estamos expuestos a que cambios o novedades en actividades viejas no sean comunicadas a las actividades nuevas y por ende exista inconsistencia a lo largo del ciclo. 45

Waterfall with Subprojects Concepto Análisis de Requerimientos Diseño Arquitectónico Diseño Detallado Codificación y Debugging Prueba de SubSistema Diseño Detallado Codificación y Debugging Diseño Detallado Prueba de SubSistema Codificación y Debugging Prueba de SubSistema Integración Prueba de Sistema 46 Ciclo de Vida Waterfall with Subprojects Otro problema con el modelo waterfall puro es que se supone que debemos completar el 100% del diseño arquitectónico antes de comenzar con el diseño detallado, y que a su vez debemos completar el 100% del diseño detallado antes de comenzar a codificar.. Los sistemas tienen ciertas áreas donde existen sorpresas de diseño, pero también existen áreas donde la tarea es simple e incluso en algunos casos conocida. Por qué entonces retrasar el comienzo de los subsistemas simples a causa de la complejidad de parte de la arquitectura?. Si es posible partir la arquitectura en subsistemas lógicamente independientes se pueden obtener subproyectos que sean tratados independientemente y en paralelo hasta llegar al momento de integrarlos. 46

Concepto Waterfall with Subprojects Análisis de Requerimientos Diseño Arquitectónico Diseño Detallado Codificación y Debugging Diseño Detallado Diseño Detallado Codificación y Debugging Codificación y Debugging Prueba de SubSistema Prueba de SubSistema Integración Aplicable en condiciones similares al pure waterfall pero donde es posible identificar subsistemas independientes. El equipo de trabajo es suficientemente grande como para paralelizar el trabajo. Ventajas Prueba de SubSistema Prueba de Sistema Permite construir los subsistemas en paralelo. Mismas ventajas que el purewaterfall. Desventajas Posibles problemas de integración por interdependencias no identificadas. 47 Ciclo de Vida Waterfall with Subprojects El mayor riesgo de esto es que existan interdependencias no previstas que generen problemas de integración. Este riesgo es posible mitigarlo con una actividad de arquitectura más intenso que en el caso del pure waterfall, pero nunca podremos eliminarlo por completo. 47

Waterfall with Risk Reduction Concepto Análisis de Requerimientos Prototipación Diseño Arquitectónico Diseño Detallado Codificación y Debugging Prueba de Sistema 48 Ciclo de Vida Waterfall with Risk Reduction Otro de los problemas del waterfall puro es que es necesario tener una precisa definición de los requerimientos antes de comenzar con el diseño arquitectónico. Esta necesidad no solo se encuentra en los requerimientos sino que es necesario para ingresar en un fase contar con gran estabilidad en la anterior y con el total de los productos requeridos para ingresar en la nueva fase. Una posible modificación leve al pure waterfall es la propuesta por Risk Reduction, donde se incorpora una actividad de prototipado de interfaz o de aquellos componentes de mayor riesgo por la incertidumbre natural al desarrollo de Software. Esta actividad no necesariamente debe centrarse en los requerimientos sino que es posible extenderla al diseño e incluso a la codificación. 48

Concepto Waterfall with Risk Reduction Análisis de Requerimientos Diseño Arquitectónico Prototipación Diseño Detallado Lo aplico en los casos donde es posible identificar aquellas áreas donde hace falta mayor conocimiento. (*) Esto no siempre es posible. Codificación y Debugging Ventajas Prueba de Sistema Reduce el riesgo con respecto al pure waterfall proveniente de los requerimientos incompletos o mal definidos. Mismas ventajas que el purewaterfall. Desventajas Debo poder identificar las áreas donde sea necesaria mayor definición. 49 Ciclo de Vida Waterfall with Risk Reduction La actividad de prototipado es generalmente beneficiosa aunque existe la posibilidad de no poder recolectar mayor información incurriendo en gastos que no tienen rédito en el proyecto. Dado que luego de la actividad de prototipado el ciclo es idéntico al pure waterfall estamos frente a las mismas dificultades que en dicho modelo. 49

Spiral Objetivos Riesgos Planificación Desarrollo Profundidad: 1ero: análisis, 2do: diseño, 3ero construcción, 4to implementación 50 Ciclo de Vida Spiral El ciclo de vida spiral es un modelo orientado a riesgos, donde el proyecto es dividido en mini-proyectos. Cada uno de los mini-proyectos atiende a uno a más riesgos importantes hasta que finalmente todos los riesgos con alta exposición han sido atendidos. El concepto de riesgo es el visto en clase, se refiere a requerimientos pobremente entendidos, a arquitectura pobremente definida o comprendida, problemas potenciales de performance, problemas en la tecnología subyacente, y demás temas del proyecto donde sea requerido mayor conocimiento. Una vez que los riesgos han sido atendidos el ciclo de vida finaliza como el pure waterefall. La idea detrás del modelo es que uno comienza con un alcance reducido en el centro de la espiral, explora los riesgos ç, construye el plan para atender los riesgos encontrados, y luego planea el siguiente ciclo. Cada iteración mueve el proyecto hacia un alcance más extenso. 50

Spiral Determinar objetivos, alternativas y restricciones Compromiso para la siguiente iteración Revisión Planificar la siguiente iteración Plan de Prueba Inicio Plan de Req., Plan de Ciclo de Vida Plan de Desarrollo Plan de Integración Identificar y resolver riesgos Análisis de Riesgos Validación de Requer. Prototipo 1,.. 3 Simulaciones Diseño de V & V Requer. de Soft. Integr. y Prueba Prueba Acept. Release Modelos Prototipo Operacional Benchmarks Diseño Detallado Code Prueba Unidad Diseño de Producto Evaluar alternativas Construir el entregable de la iteración y verificar que es correcto. 51 Ciclo de Vida Spiral Cada iteración comprende 6 pasos representados en los cuadros que rodean la espiral del slide. 1. Determinar objetivos, alternativas y restricciones. 2. Identificar y resolver riesgos. 3. Evaluar alternativas. 4. Desarrollar los entregables de la iteración y verificar que son correctos. 5. Planificar la siguiente iteración. 6. Si se decide continuar, obtener compromiso para la siguiente iteraciòn. 51

Spiral Objetivos Planificación Riesgos Desarrollo Modelo orientado a manejo de riesgos. A medida que avanza el tiempo y dinero invertidos, la exposición al riesgo disminuye. Ventajas Equilibrio óptimo entre exposición al riesgo e inversión. Mayor o equivalente control que en el modelo pure waterfall. Desventajas Requiere gran conocimiento de gestión por parte de quien dirige el proyecto. Es posible que si en un momento del proyecto la exposición al riesgo es baja, el modelo se vuelva innecesariamente caro. 52 Ciclo de Vida Spiral En el modelo espiral las etapas tempranas son las más económicas. Uno gasta menos desarrollando el concepto de operación del Software de los que gasta en la ingeniería de requerimientos, y menos en los requerimientos de lo que gasta en el diseño, desarrollando el producto y probándolo. Una de las ventajas más importantes del modelo es que el costo aumenta a medida que el riesgo decrece. A mayor tiempo y dinero invertido, menor la exposición al riesgo. Esto es justamente uno de los atributos más buscados en un proyecto de Software. El modelo espiral provee igual o mayor control en la gestión del proyecto de la provista por el modelo tradicional pure waterfall. Uno cuenta con puntos de control al finalizar cada iteración. Si el proyecto es inviable debido a razones técnicas o funcionales, es descubierto ésto en forma temprana. La única desventaja del modelo radica en su complejidad. Requiere de quién gestiona el proyecto conciencia, atención y conocimiento en gestión. Puede llegar a ser difícil definir milestones objetivos y verificables, que indiquen cuando uno está en condiciones de agregar una nueva iteración. En algunos casos el producto alcanzado es suficiente, y los riesgos a los que estamos expuesto moderados lo suficiente como para que no sea requerido continuar pensando en riesgos, con lo que el modelo orientado a riesgos propuesto por el ciclo de vida espiral se vuelve redundante. 52