Material del 2do parcial

Anlisis de requerimientos

Un requerimiento es una condicin o capacidad a la que el sistema (siendo construido) debe conformar [ Rational ]. Un requerimiento de software puede ser definido como: Una capacidad del software necesaria por el usuario para resolver un problema o alcanzar un objetivo. Una capacidad del software que debe ser reunida o poseda por un sistema o componente del sistema para satisfacer un contrato, especificacin, estndar, u otra documentacin formal. Qu son los Requerimientos Los requerimientos de usuario representan el conjunto completo de resultados a ser obtenidos utilizando el sistema. Los requerimientos de sistemas deben mostrar todo lo que el sistema debe hacer mas todas las restricciones sobre la funcionalidad. Los requerimientos forman un modelo completo, representando el sistema total a algn nivel de abstraccin.

Cmo identificamos los Requerimientos Los Requerimientos toman vida desde que realizamos nuestro primer encuentro de interlocucin con usuarios o clientes. Este puede desarrollarse utilizando cualquiera de una variedad de tcnicas como entrevistas para intercambiar opiniones, rainstorming, prototipeo, cuestionarios, etc. Cuando los requerimientos se logran redactar a un significativo nivel de detalle, tendremos listo el documento denominado Especificacin de Requerimientos.

Beneficios de una Buena Administracin de Requerimientos Mejor control de proyectos complejos. Mejora en la calidad del software y en la satisfaccin del cliente. Reduccin en los retrasos y en los costos del proyecto. Mejora en la comunicacin del equipo. Facilita la conformidad con estndares y regulaciones.

Ej. Definicin de Requerimientos de Usuario

1. El software debe proveer un medio para representar y acceder a archivos externos creados por otras herramientas. Al usuario se le proveer con los recursos para definir el tipo de archivos externos. 1.2 Cada tipo de archivo externo tendr una herramienta asociada que ser aplicada al archivo. 1.3 Cada tipo de archivo externo se representar como un icono especfico sobre la pantalla del usuario. 1.4 Se proveern recursos para que el usuario defina el icono que representa un tipo de archivo externo. 1.5 Cuando un usuario selecciona un icono que representa un archivo externo, el efecto de esa seleccin es aplicar la herramienta asociada con este tipo de archivo al archivo representado por el icono seleccionado.

Planeacin de la administracin del riesgo La Administracin de riesgos es una herramienta de gestin que nos permiten mejorar la gestin a travs de la implementacin de acciones preventivas que nos conlleven evitar o minimizar los efectos negativos que puedan afectar los objetivos. La metodologa establecida cuenta Con 4 fases: Identificacin de los riesgos Anlisis de los riesgos Valoracin de los riesgos Manejo de riesgos

Plan de manejo de riesgos en cada proceso. El responsable es cada Jefe de Proceso con su equipo de trabajo.

b.La priorizacin de aquellos riesgos que previamente han sido identificados, analizados, valorados y manejados en los procesos y que tienen mayor impacto en los objetivos institucionales. El responsable es el Vicerrector Administrativo

Administracin de riesgos de contexto estratgico: El responsable es el Jefe de Planeacin

Riesgo: Posibilidad de que ocurra un acontecimiento que impacte el alcance de los objetivos de los procesos y por consiguiente los objetivos institucionales..

Descripcin: Caractersticas generales o las formas en que se observa o manifiesta el riesgo identificado. Posibles consecuencias: Posibles efectos ocasionados por el riesgo, los cuales se pueden traducir en daos de tipo econmico, social, administrativo, entre otros.

Factores de riesgo EXTERNOS: Econmicos Sociales Orden Pblico Legales

Cambios Tecnolgicos

INTERNOS: Personas Sistemas de Informacin Recursos Econmicos Naturaleza de las actividades de la entidad

Casos de uso

Un caso de uso es una descripcin de los pasos o las actividades que debern realizarse para llevar a cabo algn proceso. Los personajes o entidades que participarn en un caso de uso se denominan actores. En el

contexto de ingeniera del software, un caso de uso es una secuencia de interacciones que se desarrollarn entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la comunicacin y el comportamiento de un sistema mediante su interaccin con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relacin entre los actores y los casos de uso en un sistema. Una relacin es una conexin entre los elementos del modelo, por ejemplo la especializacin y la generalizacin son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cmo reacciona a eventos que se producen en su mbito o en l mismo. Los ms comunes para la captura de requisitos funcionales, especialmente con el desarrollo del paradigma de la programacin orientada a objetos, donde se originaron, si bien puede utilizarse con resultados igualmente satisfactorios con otros paradigmas de programacin.

Actores Se le llama actor a toda entidad externa al sistema que guarda una relacin con ste y que le demanda una funcionalidad. Esto incluye a los operadores humanos pero tambin incluye a todos los sistemas externos, adems de entidades abstractas, como el tiempo. En el caso de los seres humanos se pueden ver a los actores como definiciones de rol por lo que un mismo individuo puede corresponder a uno o ms Actores. Suele suceder sin embargo, que es el sistema quien va a tener inters en el tiempo. Es frecuente encontrar que nuestros sistemas deben efectuar operaciones automticas en determinados momentos; y siendo esto un requisito funcional obvio, resulta de inters desarrollar alguna forma de capturar dicho requisito en el modelo de caso de uso final.

Relaciones:
o

Asociacin Es el tipo de relacin ms bsica que indica la invocacin desde un actor o caso de uso a otra operacin (caso de uso). Dicha relacin se denota con una flecha simple.

Dependencia o Instanciacin Es una forma muy particular de relacin entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relacin se denota con una flecha punteada.

Generalizacin Este tipo de relacin es uno de los ms utilizados, cumple una doble funcin dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>). Este tipo de relacin esta orientado exclusivamente para casos de uso (y no para actores). extends: Se recomienda utilizar cuando un caso de uso es similar a otro (caractersticas). Uses: Se recomienda utilizar cuando se tiene un conjunto de caractersticas que son similares en ms de un caso de uso y no se desea mantener copiada la descripcin de la caracterstica. De lo anterior cabe mencionar que tiene el mismo paradigma en diseo y modelamiento de clases, en donde est la duda clsica de usar o heredar.

Como ejemplo est el caso de una Mquina Recicladora: Sistema que controla una mquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar:

Registrar el nmero de temes ingresados. Imprimir un recibo cuando el usuario lo solicita: a. Describe lo depositado b. El valor de cada item c. Total El usuario/cliente presiona el botn de comienzo Existe un operador que desea saber lo siguiente: a. Cuantos temes han sido retornados en el da. b. Al final de cada da el operador solicita un resumen de todo lo depositado en el da. El operador debe adems poder cambiar: a. Informacin asociada a temes. b. Dar una alarma en el caso de que: i. Item se atora. ii. No hay ms papel.

Como una primera aproximacin identificamos a los actores que interactuan con el sistema:

Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar la informacin de un Item o bien puede

Imprimir informe:

un

Adems podemos notar que un item puede ser una Botella, un Tarro o una Jaba.

Otro aspecto es la impresin de comprobantes, que puede ser realizada despus de depositar algn item por un cliente o bien puede ser realizada a peticin de un operador.

Otros ejemplos:

Ejercicios Software de informacin de una biblioteca Actores - Bibliotecario - Usuario Bibliotecario Sistema de ingreso para verificar datos - Ingreso al sistema - Verifica datos - Consulta disponibilidad - Pedir documento Sistema para consultar multas - Verifica multas - Asigna multas Sistema para modificar informacin - Elimina informacin - Modifica informacin Sistema de registro de un libro - Registro de informacin del libro en prstamo - Registro de usuario Usuario Sistema para solicitar libro - Ingreso al sistema - Consulta disponibilidad de libros - Solicita libro

Ejemplo tienda

Ejemplo HOTEL

Relacin extends Un tema que genera mucha polmica entre la gente que modela casos de uso es la eleccin entre la relacin de <<include>> y <<extend>>. Lo peor es que muchas de esas discusiones generan muy poco valor en el resultado final en el modelo y en cambio quitan tiempo valioso del proyecto. Esto se debe a que dichas relaciones, muchas veces no son del todo comprendidas por la persona que la modela, y mucho menos son comprendidas por las personas que leen el modelo. As que al final no se le saca el provecho que en todo caso debera de tener dicha eleccin. Es mejor mantener el modelo simple, incluso si esto significa utilizar menos elementos grficos de UML, si eso va a facilitar el modelado y la comunicacin en el proyecto. Pero, despus de todo este tiempo y de los diferentes temas que hemos venido tratando, es importante avanzar y adentrarnos en algunos pormenores del lenguaje unificado. Relacin <<extend>> Un caso de uso extiende a otro cuando sin alterar a este, se incorpora su funcionalidad como parte integral del primero. Se denota con una relacin que apunta del caso extendido al caso base y la conexin se hace o bien al principio del flujo de eventos principal del caso base o en alguno de los puntos de extensin que este haya definido.

Antes que todo, qu es el include y el extend?

Grficamente lo que mostramos es una relacin de dependencia entre el par de casos de uso, con el nombre correspondiente al tipo de relacin de la que se trate: ya sea <<include>> o <<extend>>. Estas, son relaciones que usamos para ligar grficamente dos casos de uso, cuyos flujos de eventos estn unidos, normalmente en una sola sesin del usuario. En otras palabras, un caso de uso que est ligado, por medio de una de estas dos relaciones, a otro caso de uso; tambin podra leerse o ejecutarse como un slo caso de uso en lugar de dos. Obviamente, hay una razn por la cual decidimos separarlos en dos, lo cual explicaremos ms adelante. Imagina el conjunto de pasos que ocurren al realizar una compra en una tienda departamental. Seguramente no tendrs problema en visualizar el conjunto de pasos para solicitar la autorizacin de la tarjeta de crdito con la que vas a pagar, ligado a los pasos donde el vendedor registra los productos a comprar. Es decir, los flujos de eventos de ambos procesos forman una sola cosa; juntos podran formar un solo caso de uso, en lugar de dos casos de uso unidos por alguna de estas relaciones que aqu estamos tratando.

Figura 1. Relacionando casos de uso Include. En trminos muy simples, cuando relacionamos dos casos de uso con un include, estamos diciendo que el primero (el caso de uso base) incluye al segundo (el caso de uso includo). Es decir, el segundo es parte esencial del primero. Sin el segundo, el primero no podra funcionar bien; pues no podra cumplir su objetivo. Para una venta en caja, la venta no puede considerarse completa si no se realiza el proceso para cobrarla en ese momento. El caso de uso Cobrar Renta est incluido en el caso de uso Rentar Video, o lo que es lo mismo Rentar Video incluye (<<include>>) Cobrar Renta.

Figura 2. Ejemplo de Include Extend. La polmica al querer seleccionar una de las dos relaciones es que en el extend tambin podemos ver, desde la perspectiva del usuario, a los dos flujos como si fueran uno slo. Y en ciertos escenarios el caso de uso base no podra cumplir su objetivo si no se ejecutara la extensin. Pero, una de las diferencias bsicas es que en el caso del extend hay situaciones en que el caso de uso de extensin no es indispensable que ocurra, y cuando lo hace ofrece un valor extra (extiende) al objetivo original del caso de uso base. En cambio en el include es necesario que ocurra el caso includo, tan slo para satisfacer el objetivo del caso de uso base. Ejemplo: Puedes Realizar Venta sin Acumular Puntos de Cliente VIP, cuando no eres un cliente VIP. Pero, si eres un cliente VIP s acumulars puntos. Por lo tanto, Acumular Puntos es una extensin de Realizar Venta y slo se ejecuta para cierto tipo de ventas, no para todas.

Figura 3. Ejemplo de Extend Casos de Abuso

Uno de los riesgos que existe cuando la gente sabe que tiene estas relaciones como un elemento a utilizar en sus modelos de casos de uso, consiste en su abuso. Mucha gente, y sobre todo la que arrastra prcticas de mtodos estructurados, la suele utilizar en exceso. No es raro ver modelos de casos de uso que llegan a tener decenas de inclusiones y extensiones, incluso las inclusiones y extensiones se vuelven a extender a varios niveles, generando una maraa de casos de uso que no ofrecen valor al ser mostrados explcitamente.

Figura 4. Abuso de relaciones Es importante comprender que el objetivo de estos tipos de relaciones NO consiste (remarco la negacin) en motivar la divisin de los casos de uso en la mayor cantidad de pedazos. Debe de existir una razn importante para que decidamos dividir un caso de uso en dos que sern unidos por medio de alguna de estas relaciones. Si entendemos esto y somos congruentes, obtendremos un beneficio real para el proyecto; fin ltimo del uso de UML. La razn por la que la gente suele partir sus casos de uso en infinidad de include y extend es porque quieren conocer, entender y comunicar el mximo detalle de los casos de uso en el diagrama. Hay quien llega a utilizar, errneamente, estas relaciones para mostrar el orden en que se ejecutan estos casos de uso. Debemos de recordar que al modelar el diagrama de casos de uso no buscamos analizar el detalle, y mucho menos los flujos. Todo ese detalle lo podremos plasmar en otro tipo de diagramas, como los diagramas de interaccin, de actividad, de estados, o simplemente un texto en una especificacin. Relaciones de Anlisis o Diseo

Otra situacin donde abusamos de estas relaciones se da cuando queremos representar la unin de casos de uso por una decisin de diseo del sistema, especficamente por una decisin de navegabilidad entre funciones. Pensemos en cierta funcionalidad en un sistema, la cual corresponde a la ejecucin de cierto caso de uso (por ejemplo Registrar Prstamo de un Video). Y estando en dicho caso de uso tienes a la vista en la pantalla, y decides utilizar, un botn que te permitira iniciar otro caso de uso que tiene poco o nada que ver con el objetivo del caso de uso inicial (digamos, Consultar Promociones). Esto no debera de mostrarse como una relacin entre estos dos casos de uso en el modelo. No deberamos modelar al primer caso de uso incluyendo ni siendo extendido con el segundo caso de uso ni viceversa, pues la razn por la que se ligaron (no grficamente, sino en su ejecucin) fue por una facilidad otorgada por la manera en que se dise el sistema, la cual permite navegar fcilmente entre las diferentes funciones del sistema. La navegabilidad que otorga el sistema entre uno y otro caso de uso normalmente tiene que ver poco con que exista o no una relacin entre dichos casos de uso. Re uso: Evitando el Re trabajo

Una de las razones por las cuales deberas de considerar el uso de este tipo de relaciones, es porque identificas que hay pasos que son iguales en dos o ms casos de uso. No querrs tener que escribir y darle mantenimiento a esos pasos en los documentos asociados a cada uno de ellos. Peor an, no querrs correr el riesgo de que esos pasos se diseen, programen y prueben de maneras diferentes y con esfuerzos aislados por ti o tu equipo de desarrollo. Finalmente son la misma cosa, para qu querramos trabajar doble? Lo que queremos es economizar, ser ms eficientes en el desarrollo, y ah es cuando viene el beneficio de identificar estos tipos de relaciones; porque es una oportunidad de identificar reuso.

Figura 5. Identificacin de reuso Si te sientes preparado para desarrollar modelos de casos de uso ms sofisticados y de mayor valor, entonces considera la posibilidad de utilizar estos tipos de relaciones. Slo asegrate de aprovecharlas adecuadamente, buscando el beneficio real que deberan de proporcionar en tu modelo y proyecto con base en las recomendaciones mencionadas. Y recuerda unificar los criterios dentro de tu empresa para que el lenguaje sea realmente unificado o estandarizado dentro de tu empresa.

Modelos de desarrollo de software Proceso de software Es un conjunto de actividades y resultados asociados, que generan un producto de software, las cuales son llevadas a cabo por los ingenieros de software. Es una descripcin de un proceso del software que se presenta desde una perspectiva particular. Es una abstraccin de un proceso real. Existe una gran variedad de modelos o paradigmas de desarrollo de software: Enfoque de Cascada Desarrollo Evolutivo Desarrollo Formal Desarrollo basado en la reutilizacin

Modelo de cascada

Modelo en cascada

El modelo en cascada, es el enfoque metodolgico que ordena rigurosamente las etapas del ciclo de vida del software, de tal forma que el inicio de c3ada etapa debe esperar a la finalizacin de la inmediatamente anterior. El modelo en cascada puede ser aplicado para las necesidades especficas de una organizacin. Si bien modelos de desarrollo, como el cascada uno de los ms antiguos, es til para que el desarrollador

visualice lo que va hacer, han dado como resultado la aparicin de nuevas tcnicas ms desarrolladas. Un ejemplo de una metodologa de desarrollo en cascada es: Anlisis de requisitos Diseo del Sistema Diseo del Programa Codificacin Pruebas Implantacin Mantenimiento De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costes del desarrollo. La palabra cascada sugiere, mediante la metfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases ms avanzadas de un proyecto. Si bien ha sido ampliamente criticado desde el mbito acadmico y la industria, sigue siendo el paradigma ms seguido al da de hoy. V-modelo es un proceso del desarrollo del software cul se puede presumir para ser la extensin del modelo de la cascada. En vez de la mudanza abajo de una manera linear, los pasos de proceso estn doblados hacia arriba despus de codificacin fase, formar la forma de V tpica. El V-Modelo demuestra las relaciones entre cada fase del ciclo vital del desarrollo y su fase asociada de prueba

Modelo en Cascada El ms conocido, esta basado en el ciclo convencional de una ingeniera, el paradigma del ciclo de vida abarca las siguientes actividades: Ingeniera y Anlisis del Sistema Anlisis de los Requisitos Diseo Codificacin Prueba Mantenimiento

Ingeniera y Anlisis del Sistema: Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algn subconjunto de estos requisitos al software. Anlisis de los requisitos del software: el proceso de recopilacin de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software (Analistas) debe comprender el mbito de la informacin del software, as como la funcin, el rendimiento y las interfaces requeridas. Diseo: el diseo del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterizacin de la interfaz. El proceso de diseo traduce los requisitos en una representacin del software con la calidad requerida antes de que comience la codificacin. Codificacin: El diseo debe traducirse en una forma legible para la maquina. El paso de codificacin realiza esta tarea. Si el diseo se realiza de una manera detallada la codificacin puede realizarse mecnicamente. Prueba: una vez que se ha generado el cdigo comienza la prueba del programa. La prueba se centra en la lgica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren. Mantenimiento: El software sufrir cambios despus de que se entrega al cliente. Los cambios ocurrirn debido a que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos perifricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento. Problemas: No siempre se sigue el flujo secuencial. Es difcil tener un 100% de los requisitos al inicio. El cliente debe tener paciencia. Los primeros resultados sern hasta que ya este operando el sistema.

Ventajas Etapas y actividades estn bien definidas para facilitar la comprensin Auto de motivos de usuario Es tambin ayudan en la planificacin y las jornadas cuando se someten a los proyectos Claridad de los objetivos del proyecto. Estable requisitos del proyecto. El progreso del sistema se puede medir.

Desventajas Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay iteraciones y se crean problemas en la aplicacin del paradigma. Normalmente, es difcil para el cliente establecer explcitamente al principio todos los requisitos. El ciclo de vida clsico lo requiere y tiene dificultades en acomodar posibles incertidumbres que pueden existir al comienzo de muchos productos. El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estar disponible una versin operativa del programa. Un error importante no detectado hasta que el programa este funcionando puede ser desastroso. La ventaja de este mtodo radica en su sencillez ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software.

Relacin con el Modelo V El Modelo V tiende a ser muy relacionado con el Modelo de Cascada puesto que es una evolucin del mismo. Los planes de prueba son el nexo entre el desarrollo y la verificacin
ANALISIS DE REQUERIMIENTOS OPERACION Y MANTENIMIENTO

Plan de Pruebas de Aceptacin

PRUEBA DE ACEPTACION

Validar requerimientos
Plan de Pruebas del Sistema

DISEO DEL SISTEMA

PRUEBA DEL SISTEMA

Verificar diseo
Plan de Pruebas de Integracin

DISEO DETALLADO

PRUEBA DE INTEGRACION

IMPLEMENTACION DE PROGRAMAS Y PRUEBA UNITARIA

Puede notarse que su primera mitad es similar al Modelo en Cascada, y la otra mitad tiene como finalidad hacer pruebas e integracin asociado a cada una de las etapas de la mitad anterior.

Se puede identificar una ventaja principal con respecto al Modelo Cascada ms simple, y se refiere a que este modelo involucra chequeos de cada una de las etapas del modelo de cascada. Este modelo es una versin mejorada del modelo cascada, incorpora o se enfoca, de mejor manera al control de calidad, este modelo tambin muestra la relacin iterativa entre las distintas fases en el proceso de desarrollo de software y aade dos partes que son: La Verificacin: Que tiene relacin con la pregunta Se est haciendo correctamente el producto? La Validacin: Que tiene relacin con la pregunta Se est haciendo el producto , es decir, la demostracin de que el software cumple con exactitud la finalidad pretendida. En el modelo V podemos ver las mismas fases del modelo cascada pero con una mejor relacin entre ellas. Desventajas: El riesgo es mayor que el de otros modelos, pues en lugar de hacer pruebas de aceptacin al final de cada etapa, las pruebas comienzan a efectuarse luego de haber terminado la implementacin, lo que puede traer como consecuencia un roll-back de todo un proceso que cost tiempo y dinero. El modelo no contempla la posibilidad de retornar a etapas inmediatamente anteriores, cosa que en la realidad puede ocurrir. Se toma toda la complejidad del problema de una vez y no en iteraciones o ciclos de desarrollo, lo que disminuye el riesgo. A pesar de todo lo antes mencionado, definitivamente se trata de un modelo ms robusto y completo que el Modelo de Cascada, y puede producir software de mayor calidad que con el modelo de cascada.

VENTAJAS:

Especfica bien los roles de los distintos tipos de pruebas a relizar. Hace explcito parte de la iteracin y trabajo que hay que realizar. Este mtodo involucra chequeos de cada una de las etaopas del mtodo Cascada. Es un mtodo ms robusto y completo que el mtodo cascada y produce software de mayor calidad que con el modelo cascada. Es un modelo sencillo de y de fcil aprendizaje. Involucra al usuario en las pruebas.

Modelo en espiral

Este modelo, propuesto por Bohem en 1988 [BOE88], es un modelo de proceso de software evolutivo que acompaa la naturaleza evolutiva de con los aspectos controlados y sistemticos del ciclo de vida tradicional. Proporciona el potencial para el desarrollo rpido de versiones incrementales del software. En este modelo, el sistema se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones, la versin incremental podra ser un modelo en papel o un prototipo. Durante las ltimas iteraciones se producen versiones cada vez ms completas de ingeniera del sistema. . El Modelo en Espiral se divide en un nmero de actividades estructurales, tambin llamadas "regiones de tareas" . Generalmente existen entre tres y seis regiones de tareas: Comunicacin con el cliente.- Las tareas requeridas para establecer comunicacin entre el desarrollador y el cliente, sea revisar especificaciones, plantear necesidades, etc. Planificacin.- Las tareas requeridas para definir recursos, tiempos e informacin relacionada con el proyecto. Anlisis de riesgos.- Las tareas requeridas para evaluar riesgos tcnicos y de gestin. Ingeniera.- Las tareas requeridas para construir una o ms representaciones de la aplicacin Construccin y adaptacin.- Las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario. Evaluacin del cliente.- Las tareas requeridas para obtener la reaccin del cliente, segn la evaluacin de las representaciones del software creadas durante la etapa de ingeniera e implementada durante la etapa de instalacin Cada una de las regiones estn pobladas por una serie de tareas que se adaptan a las caractersticas del proyecto que va a emprenderse. Para proyectos pequeos el nmero de tareas y su formalidad es bajo, para proyectos mayores y ms crticos, cada regin contiene tareas que se definen para lograr un nivel ms alto de formalidad. Cuando empieza este proceso evolutivo, el equipo de trabajo gira alrededor de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral produce el desarrollo de una especificacin de productos, los pasos siguientes en la espiral se podran utilizar para desarrollar un prototipo y progresivamente versiones ms sofisticadas del software. Cada

paso de la regin de planificacin produce ajustes en el plan del proyecto. . El coste y la planificacin se ajustan en funcin de la evaluacin del cliente. Adems, el gestor del proyecto ajusta el nmero planificado de iteraciones requeridas para completar el proyecto o el producto software de que se trate. La siguiente figura muestra grficamente el Modelo Espiral, para las seis regiones de tareas y suponiendo un proyecto tal que forzosamente requiere iniciar en la conceptualizacin previa a la vuelta de desarrollo, an cuando hemos dicho que frecuentemente se puede iniciar desde esta tarea. Asimismo, se presenta la terminacin del proyecto en la ltima vuelta, como mantenimiento del mismo proyecto, pareciese que ah terminase el ciclo, sin embargo, la vuelta siguiente existe y correspondera al inicio de un nuevo proyecto que puede o no tomar como base el proyecto anterior. MODELO EN ESPIRAL

El modelo en espiral es un enfoque realista del desarrollo de sistemas y de software en gran escala. Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el usuario comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos. El modelo en espiral utiliza la construccin de prototipos como mecanismo de reduccin de riesgos, pero lo que es ms importante, permite a quien lo desarrolla aplicar el enfoque de construccin de prototipos en cualquier etapa de evolucin del producto. Mantiene el enfoque sistemtico de los pasos sugeridos por el ciclo de vida clsico, pero lo incorpora al marco de trabajo interactivo que refleja mejor el mundo real. El modelo demanda una consideracin directa de los riesgos tcnicos en todas las etapas del proyecto, y si se aplica adecuadamente, debe reducir los riesgos antes de que se conviertan en problemticos. Pero al igual que otros modelos, ste no es la panaca. Puede resultar difcil convencer a grandes clientes, (particularmente en situaciones bajo contrato) de que el

enfoque evolutivo que presenta este modelo es controlable. Requiere una considerable habilidad para la evaluacin del riesgo, y de ello depende el xito. Si un riesgo importante no es descubierto y gestionado, indudablemente surgirn problemas. Finalmente, en s mismo, el modelo es relativamente nuevo y no se ha utilizado tanto como otros. Todava tendr que pasar muchas pruebas para certificar los beneficios que la utilizacin de este prometedor modelo parece ofrecer para el desarrollo de sistemas de informacin.