PowerPoint Presentation

Modelo en Espiral

1IntroduccinEn el proceso de desarrollo de software un sistema informtico est compuesto por hardware y software. El buen funcionamiento del hardware es, en principio, comparable a la de cualquier otro equipo de cmputo existente. Sin embargo, respecto al software, su construccin y resultados han sido en el pasado cuestionados debido a los problemas asociados a ellos: Los sistemas no responden a las expectativas de los usuarios. Los programas se caen con cierta frecuencia. Los costes del software son difciles de prever y normalmente superan las estimaciones propuestas con anterioridad. La modificacin del software es una tarea difcil y costosa.En el desarrollo de software, se establece algunas particularidades como los modelos de ciclo de vida del software, uno de estos modelos es el llamado El Modelo Evolutivo Espiral cuyo autor es Barry Boehm (1988), este tipo de modelo permite tener en cuenta el riesgo que aparece al momento de desarrollar software, se comienza analizando las diferentes alternativas de procesos en el diseo del software, se selecciona el riesgo ms asumible y se hace un ciclo de la espiral. Si el usuario requiere hacer avances en el software, se evala las diferentes alternativas y riesgos y se realiza un nuevo giro a la espiral, as hasta que llegue un momento en el que el software diseado sea aceptado y no necesite mejorarse con un nuevo ciclo.PROCESO DE DESARROLLO DE SOFTWAREEl desarrollo de un software en s es complejo, es usualmente no viable conseguir un 100% de confiabilidad de un programa por pequeo que sea. Existe una gran combinacin de factores que imposibilitan realizar una verificacin minuciosa de todas las posibles situaciones de ejecucin que se puedan presentar. Poniendo como ejemplo la creacin de un sistema operativo, esto es una tarea que requiere proyecto, gestin, numerosos recursos y todo un equipo disciplinado de trabajo. Un desarrollo de software es imperceptible y por lo general muy abstracto, esto pone trabas en la definicin del producto y sus requisitos, ms que nada cuando no se tiene precedentes definidos de un desarrollo de software similar. Esta situacin va hacer que los requisitos sean difciles de consolidar con anterioridad. Es por esto que ahora los cambios en los requisitos son inevitables, no slo despus de entregado el producto sino tambin durante el proceso de desarrollo. Sea cual fuere el proceso utilizado y aplicado al desarrollo del software, casi siempre libremente de este proceso, se debe aplicar un modelo de ciclo de vida. Segn varias fuentes consultadas se estima que, del total de proyectos software grandes emprendidos, un 28% fracasan, un 46% caen en severas modificaciones que lo retrasan y un 26% son totalmente exitosos. Cuando un proyecto de desarrollo de software fracasa (28% estadsticamente), muy rara vez es causado por fallas tcnicas, principalmente el origen de los fallos y fracasos es la falta de aplicacin de una buena metodologa o procesos de desarrollo. Una fuerte tendencia, desde hace pocos aos, es mejorar las metodologas y procesos, o crear nuevas e incentivar a los profesionales de la informtica en su aplicacin adecuada, normalmente utilizan sus conocimientos especializados con modelos, paradigmas y procesos obsoletos que ya fueron diseados.2Definicin de un ModeloUn modelo para el desarrollo de software es una perspectiva de las actividades que ocurren durante el diseo y el desarrollo del software, se pretende determinar el orden de las etapas implicadas en el sistema y los criterios de transicin asociadas entre estas etapas. Un modelo de ciclo de vida del software: Describe las etapas primordiales del desarrollo de software. Define las etapas primarias esperadas para ser aplicadas durante esas etapas. Ayuda a administrar el progreso del desarrollo, y Provee un espacio de trabajo para la definicin de un detallado proceso de desarrollo de software.As, los modelos por una parte proveen una gua a los ingenieros de software con el fin de establecer las diversas actividades tcnicas en el proyecto, por otra parte suministran un marco para la administracin del desarrollo y el mantenimiento del software, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc. 3Ideologa del Modelo EspiralEl modelo espiral se basa en una estrategia para reducir el riesgo del proyecto en reas de incertidumbre, como tener requerimientos iniciales incompletos e inestables. El modelo enfatiza ciclos de trabajo, cada uno de los cuales estudia el riesgo antes de proceder al siguiente ciclo. Cada ciclo comienza con la identicacin de los objetivos, soluciones alternas y restricciones asociadas con cada alternativa, y nalmente se procede a su evaluacin. Cuando se encuentra que existe cierta incertidumbre, se utilizan diversas tcnicas para reducir el riesgo de las distintas alternativas.Cada ciclo del modelo espiral termina con una revisin que discute los logros actuales y los planes para El siguiente ciclo. Al igual que el modelo evolutivo, el modelo espiral incorpora una estrategia de uso de prototipos como parte del manejo del riesgo. Las creencias del modelo de espiral son que una actividad comienza cuando se entienden los objetivos y riesgos involucrados, se usan las herramientas que mejor reduzcan los riesgos basndose en la evaluacin de soluciones alternas, todo el personal relacionado debe involucrarse en una revisin que determine cada actividad (planeando y comprometindose con las siguientes actividades) y el desarrollo se incrementa en cada etapa, permitiendo prototipos sucesivos del producto. Al ser un modelo de ciclo de vida orientado a la gestin de riesgos se dice que uno de los aspectos fundamentales de su xito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente riesgos.El modelo evolutivo es una extensin al modelo incremental en la que los incrementos se hacen de manera secuencial, en lugar de en paralelo. Desde el punto de vista del cliente, el sistema evoluciona segn vayan siendo entregados los incrementos. Desde el punto de vista del desarrollador, los requerimientos que son claros al principio del proyecto dictan el incremento inicial, mientras que los incrementos para cada uno de los siguientes ciclos de desarrollo se clarican a travs de la experiencia de los incrementos anteriores.Este modelo considera que el desarrollo de sistemas es un proceso de cambios progresivos mediante deltas (cambios) de especicacin de requerimientos. El modelo evolutivo es tambin conocido como desarrollo rpido de aplicaciones (en ingls, RADrapid application development), que se basa tradicionalmente en el uso de prototipos (en ingls, rapid prototyping).Un prototipo de software se considera como un medio para especicar los requisitos y un enlace de comunicacin entre el usuario nal y el diseador, ayudando a reducir el riesgo de carecer de requerimientos iniciales completos y estables.Algunas de las creencias del modelo de cascada son la entrega temprana de parte del sistema, aunque no estn completos todos los requerimientos, ya que esto permite utilizarlo como herramienta para la generacin de requerimientos faltantes, obteniendo benecios para el sistema mediante entregas iniciales mientras las entregas posteriores se encuentran en desarrollo.4Etapas del EspiralDeterminar o fijar objetivosAnlisis del riesgoDesarrollar, verificar y validar (probar)Planificar

5Etapas del EspiralDeterminar o fijar objetivosAnlisis del riesgoDesarrollar, verificar y validar (probar)Planificar

6Determinar o fijar objetivosFijar tambin los productos definidos a obtener: requerimientos, especificacin, manual de usuario.Fijar las restriccionesIdentificacin de riesgos del proyecto y estrategias alternativas para evitarlosHay una cosa que solo se hace una vez: planificacin inicial o previa

7Anlisis del riesgo

Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgosRSGR para cada riesgo identificado

Reduccin, supervisin y gestin de riesgoTodas las actividades de anlisis de riesgo presentadas hasta ahora tienen un solo objetivo -ayudar al equipo del proyecto a desarrollar una estrategia para tratar los riesgos-. Una estrategia eficaz debe considerar tres aspectos: Evitar el riesgo Supervisar el riesgo Gestionar el riesgo y planes de contingencia.

El plan rsgr Se puede incluir una estrategia de gestin de riesgo en el plan del proyecto de software o se podran organizar los pasos de gestin del riesgo en un Plan diferente de reduccin, supervisin y gestin del riesgo (Plan RSGR). Todos los documentos del plan RSGR se llevan a cabo como parte del anlisis de riesgo y son empleados por el jefe del proyecto como parte del Plan del Proyecto general.

8Desarrollar, verificar y validar (probar)

Tareas de la actividad propia y de pruebaAnlisis de alternativas e identificacin de resolucin de riesgosDependiendo del resultado de la evaluacin de riesgos, se elige un modelo para el desarrollo, que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. As, por ejemplo, si los riesgos de la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podra ser la construccin de prototipos evolutivos. Planificar

Revisamos todo lo que hemos hecho, evalundolo y con ello decidimos si continuamos con las fases siguientes y planificamos la prxima actividad. Etapas en la versin de 6 actividades Comunicacin con el cliente: esta es una tarea requerida para establecer comunicacin entre el desarrollador y el cliente. Planificacin: esta tarea es necesaria aplicarla para pode definir los recursos, el tiempo y otras informaciones relacionadas con el proyecto, es decir, son todos los requerimientos. Anlisis de riesgos: esta es una de las tareas principales por lo que se aplica el modelo en espiral, es requerida para evaluar los riesgos tcnicos y otras informaciones relacionadas con el proyecto. Ingeniera: esta es una tarea necesaria ya que se requiere construir una o ms representaciones de la aplicacin. Construccin y adaptacin: esta tarea es requerida en el modelo espiral porque se necesita construir, probar, instalar y proporcionar soporte al usuario. Evaluacin el cliente: esta tambin es una tarea principal, necesaria para adquirir la reaccin del cliente segn la evaluacin de las representaciones del software creadas durante la etapa de ingeniera y la de implementacin creada durante la etapa de instalacin.

Modelo Win-WinEl modelo ganar-ganar (en ingls, win-win) extiende el modelo espiral, haciendo nfasis en la identi cacin de las condiciones de ganancia para todas las partes, creando un plan para alcanzar las condiciones ganadoras y evitar los riesgos correspondientes.Se establecen las reglas para denir el proceso de desarrollo del proyecto, tomando en cuenta todas las partes implicadas.El modelo no necesita mucho tiempo de gestin. Esto permite utilizarlo tanto en proyectos pequeos como grandes. Se consideran cuatro los ciclos, cada uno compuesto de cuatro actividades. Las cuatro actividades son: elaborar los objetivos, restricciones y alternativas del proceso y producto del sistema y subsistema; evaluar las alternativas con respecto a los objetivos y restricciones (identicando y resolviendo las fuentes principales de riesgo en el proceso y producto); elaborar la denicin del producto y proceso; y planear el siguiente ciclo, actualizando el plan del ciclo de vida, incluyendo la particin del sistema en subsistemas para ser considerados en ciclos paralelos, lo cual puede incluir un plan para terminar el proyecto si es muy riesgoso o no es factible, asegurando el compromiso de la administracin para continuar segn lo planeado. Una vez revisadas las actividades, los ciclos denen lneas especcas a seguir. En el Ciclo 0 (grupos de aplicacin) se determina la viabilidad de un grupo apropiado de aplicaciones. En el Ciclo 1 objetivos del ciclo de vida de la aplicacin) se desarrollan los objetivos del ciclo de vida, incluyendo prototipos, planes y especicaciones de aplicaciones individuales, y se verica la existencia de al menos una arquitectura viable para cada aplicacin. En el Ciclo 2 (arquitectura del ciclo de vida de la aplicacin) se establece una arquitectura del ciclo de vida detallado, se verica su viabilidad, y se determina que no existen riesgos mayores en satisfacer los planes y especicaciones. En el Ciclo 3 (capacidad de operacininicial) se alcanza una capacidad operacional inicial para cada etapa crtica del proyecto en el ciclo de vida del software.Las creencias del modelo son: crear software basado en componentes para lograr mayor calidad en los sistemas de mayor tamao, escribir software reutilizable para hacer eciente el proceso de desarrollo, medir la calidad del sistema como aspecto clave del desarrollo del producto, lograr mayor calidad en el proceso de ensamblaje a partir de componentes menores, usar tecnologas basadas en objetos como aspecto bsico para lograr la calidad, producir sistemas rpidamente (sencillos, conables y de calidad) empleando procesos bien denidos, utilizar el modelo espiral como base del proceso, hacer exible el proceso de creacin del software para lograr los objetivos generales de eciencia, involucrar al cliente mediante el manejo de prototipos y analizar los riesgos en el proceso del desarrollo del software para asegurar la calidad nal del sistema.

12Etapas del Modelo Win-WinIdentificacin del sistema o subsistemas clave de los directivos.Determinacin de las condiciones de victoria de los directivos.Negociacin de las condiciones de victoria de los directivos para reunirlas en un conjunto de condiciones para todos los afectados (incluyendo el equipo del proyecto de software).

El modelo en espiral WINWIN de Boehm, define un conjunto de actividades de negociacin al principio de casa paso alrededor de la espiral. Ms que una simple actividad de comunicacin con el cliente se definen las siguientes actividades:

El modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos de fijacin que ayudan a establecer la completitud de un ciclo alrededor del espiral y proporcionan hitos de decisin antes de continuar el proyecto de software.13Ventajas e InconvenientesVentajasEnfoque realistaGestin explcita de riesgos, lo que reduce riesgos del proyectoCentra su atencin en la reutilizacin de componentes y eliminacin de errores en informacin descubierta en fases iniciales Los objetivos de calidad son el primer objetivoIntegra el desarrollo con mantenimiento

DesventajasConvencer cliente enfoque controlableRequiere de experiencia en la identificacin de riesgosRequiere refinamiento para uso generalizado14Comparacin con otros ModelosLa distincin ms destacada entre el modelo en espiral y otros modelos de software es la tarea explcita de evaluacin de riesgos. Aunque la gestin de riesgos es parte de otros procesos tambin, no tiene una representacin propia en el modelo de proceso. Para otros modelos la evaluacin de riesgos es una subtarea, por ejemplo, de la planificacin y gestin global. Adems no hay fases fijadas para la especificacin de requisitos, diseo y pruebas en el modelo en espiral. Se puede usar prototipado para encontrar y definir los requisitos. La diferencia entre este modelo y el modelo de ciclo incremental es que en el incremental se parte de que no hay incertidumbre en los requisitos iniciales; en este, en cambio, se es consciente de que se comienza con un alto grado de incertidumbre. En el incremental suponemos que conocemos el problema y lo dividimos. Este modelo gestiona la incertidumbre.