2011

Modelos del Ciclo de Vida del Software

Ciclo de vida de software y ciclo de desarrollo, Modelos de ciclo de vida y Metodologas para el desarrollo de software.

Integrantes:

NDICE

1. INTRODUCCIN 2. CICLO DE VIDA DE SOFTWARE Y CICLO DE DESARROLLO 3. MODELOS DE CICLO DE VIDA 3.1. Ciclo de vida Code&Fix (codificar y corregir) 3.2. Ciclo de vida Lineal 3.3. Ciclos de vida en Cascada 3.3.1. Ciclo de vida en Cascada Puro 3.3.2. Ciclo de vida en V 3.3.3. Ciclo de vida Tipo Sashimi 3.3.4. Ciclo de vida en Cascada con Sub Proyectos 3.4. Modelos de Ciclos de vida en Espiral 3.4.1.Ciclo de vida en Espiral 3.4.2. Modelo en Espiral tpico de seis regiones 3.4.3. Espiral WINWIN 3.5. Modelo de Ciclo de vida Orientado a Objetos 3.5.1. Ciclo de vida Fuente 4. MODELOS DE CICLO DE DESARROLLO 4.1. Modelo de Desarrollo Iterativo 4.2. Modelo de desarrollo Evolutivo 4.3. Modelo de desarrollo Incremental 5. 5.1. Prototipos 5.2. Modelo Concurrente

1. INTRODUCCIN

En el presente trabajo se pretende explicar el desarrollo del software a travs de las diferentes etapas de cada uno de modelos de ciclo de vida para obtener un software de calidad as como las ventajas y desventajas que se dan al usar dichos modelos. Se abordarn los modelos de desarrollo de software y las metodologas para el desarrollo del software, con ello se pretende formar un criterio acerca de la eleccin de un adecuado modelo de ciclo de vida para poder abordar diversos problemas que se presentan durante el desarrollo de un proyecto de software, el modelo elegido va a depender de manera particular de las necesidades del cliente o de lo que se quiere lograr con el proyecto, ya que cada uno de estos modelos de ciclo de vida mencionados en el presente trabajo son adecuados para ciertas caractersticas de un proyecto. As como la importancia que tienen las metodologas de desarrollo de software las cuales buscan de una manera sistemtica realizar, gestionar y administrar un proyecto de forma que se tengan altas las posibilidades de xito.

2. CICLO DE VIDA DEL SOFTWARE Y CICLO DE DESARROLLO

Ciclo de vida del software y ciclo de desarrollo son trminos comnmente confundidos Ciclo de vida del software La ISO/IEC 12207 1995 nos dice que el ciclo de vida es el periodo de tiempo comprendido desde la definicin de los requisitos hasta el fin del su uso. Es decir, abarca desde que se comienza a concebir la idea de un nuevo sistema de software, hasta que este se retira y deja de funcionar. El ciclo de vida permite que los errores se detecten lo antes posible y por lo tanto, permite a los desarrolladores concentrarse en la calidad del software, en los plazos de implementacin y en los costos asociados. Ciclo de desarrollo El ciclo de desarrollo es un sub conjunto del ciclo de vida que empieza en el anlisisfinaliza en la entrega del sistema al usuario.

3. MODELOS DE CICLO DE VIDA

Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transicin asociadas entre estas 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 suministran una gua con el fin de ordenar las diversas actividades tcnicas en el proyecto, por otra parte suministran un marco para la administracin del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc. Las principales diferencias entre distintos modelos de ciclo de vida estn divididas en tres grandes visiones: El alcance del ciclo de vida, que depende de hasta dnde deseamos llegar con el proyecto: slo saber si es viable el desarrollo de un producto, el desarrollo completo o el desarrollo completo ms las actualizaciones y el mantenimiento. La cualidad y cantidad de las etapas en que dividiremos el ciclo de vida: segn el ciclo de vida que adoptemos, y el proyecto para el cual lo adoptemos. La estructura y la sucesin de las etapas, si hay realimentacin entre ellas, y si tenemos libertad de repetirlas (iterar).

Cabe resaltar que no existe un modelo de ciclo de vida nico ya que el tipo, orden y actividades en cada fase pueden cambiar adaptndose a las necesidades del producto a realizar y a la propia estructura de la organizacin que lo desarrolla a partir de las posibilidades que ofrece la tecnologa de software empleada.

3.1. CICLO DE VIDA CODE & FIX (CODIFICAR Y CORREGIR)

Contiene nicamente dos pasos: escribir cdigo y corregir problemas en el cdigo. Es as que se programaba, se correga, y se volva a programar sobre la misma marcha del proyecto. El ciclo de vida de este tipo de proyectos finalizaba cuando se satisfacan las especificaciones, no slo las primeras por las cuales naci la necesidad del programa, sino tambin todas aquellas que fueron surgiendo sobre la marcha. Ventaja: No gasta recursos en anlisis, planificacin, gestin de recursos, documentacin, etc., Desventajas: Cdigo de baja calidad. El cdigo es difcil de reparar por su pobre preparacin para probar y modificar. Despus de un nmero de correcciones, el cdigo puede tener una muy mala estructura, hace que los arreglos sean muy costosos. Frecuentemente, an el software bien diseado, no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstruccin es muy cara. Resulta apropiado para: Proyectos muy pequeos y que son llevados adelantepor uno o dos programadores.

3.2. CICLO DE VIDA LINEAL O SECUENCIAL

Este modelo, identificado ya a principios de la dcada de los 50, es el ms sencillo de todos los modelos. Consiste en descomponer la actividad global del proyecto en etapas separadas que son realizadas de manera lineal, es decir, cada etapa se realiza una sola vez, a continuacin de la etapa anterior y antes de la etapa siguiente, cada fase requiere como elemento de entrada el resultado completo de la anterior. Las actividades de cada una de las etapas deben ser independientes entre s, es decir, que es condicin primordial que no haya retroalimentacin entre ellas. Requiere que se conozca desde el primer momento, con excesiva rigidez, lo que va a ocurrir en cada una de las distintas etapas antes de comenzarla. Esto ltimo minimiza, tambin, las posibilidades de errores durante la codificacin y reduce al mnimo la necesidad de requerir informacin del cliente o del usuario.

Al aplicarlo en situaciones reales su rigidez genera problemas, porque muchas veces resulta difcil poder disponer de requisitos completos o del diseo pormenorizado del sistema en las fases iniciales, creando una barrera que impide avanzar. Desde el punto de vista de la gestin, es muy fcil dividir las tareas, y prever los tiempos (sumando linealmente los de cada etapa).

Requisitos Diseo

Codificacin Pruebas

Integracin
Operacin y mantenimient o

Ventaja: La sencillez de su gestin y administracin tanto econmica como temporal, ya que se acomoda perfectamente a proyectos internos de una empresa para programas muy pequeos que realizan altas, bajas y modificaciones sobre un conjunto de datos. Desventaja: No es apto para desarrollos que superen mnimamente requerimientos de retroalimentacin entre etapas, es decir, es muy costoso retomar una etapa anterior al detectar alguna falla. Resulta apropiado para: Desarrollo de aplicaciones que se dediquen exclusivamente a almacenar datos, sea una base de datos o un archivo plano. No se tiene la necesidad de realizar procesos sobre ellos ms que una consulta simple. Sistemas pequeos, sin previsin de evolucin a corto plazo. Desarrollar nuevas versiones de sistemas ya veteranos en los que el desconocimiento de las necesidades de los usuarios, o del entorno de operacin no plantea riesgos.

3.3. CICLOS DE VIDA EN CASCADA

3.3.1. Ciclo de vida en cascada puro

Es un ciclo de vida que admite iteraciones, contrariamente a la creencia de que es un ciclo de vida secuencial como el lineal. Despus de cada etapa se realiza una o varias revisiones para comprobar si se puede pasar a la siguiente. Es un modelo rgido, poco flexible, y con muchas restricciones. Refleja la necesidad impuesta por la realidad de retornar con frecuencia desde una fase hacia las anteriores con la informacin generada al avanzar el desarrollo. Reconoce la importancia de disponer de unos requisitos y un diseo previo antes de comenzar con la codificacin del sistema, pero al mismo tiempo se enfrenta con la realidad acerca de la dificultad que supone disponer de documentacin elaborada de requisitos y diseo antes de empezar a codificar que puede actuar como una barrera que bloquee el comienzo de la siguiente fase. Por estas razones los equipos que lo aplican pueden caer en la tentacin de comenzar con el diseo o incluso con la codificacin, sin tener un conocimiento suficiente de los requisitos. Se le critic, principalmente, el retardo en entregar partes del producto, su metodologa para la correccin de errores, su obstinacin por exigir requerimientos previos completos, y su alta rigidez. A pesar de todo no es errneo adaptarlo para alguna aplicacin en la que el modelo de ciclo lineal no sea del todo adecuado, y el uso de un modelo de gestin ms elaborado no lo justifique. Requisitos Diseo

Codificacin Pruebas

Integracin
Operacin y mantenimiento

Requisitos Diseo Ciclo de vida en cascada con el uso de prototipos Codificacin Pruebas
Diseo del prototipo Uso del prototipo

Integracin
Operacin y mantenimiento

Ventajas: Planificacin sencilla Provee un producto con un elevado grado de calidad sin necesidad de un personal altamente calificado.

Desventajas: Necesidad de contar con todos los requerimientos (o la mayora) al comienzo del proyecto, y, si se han cometido errores y no se detectan en la etapa inmediata siguiente, es costoso y difcil volver atrs para realizar la correccin posterior. Adems, los resultados no los veremos hasta que no estemos en las etapas finales del ciclo, por lo que, cualquier error detectado nos trae retraso y aumenta el costo del desarrollo en funcin del tiempo que insume la correccin de stos. Resulta apropiado para: Proyectos en los que se dispone de todos los requerimientos al comienzo, para el desarrollo de un producto con funcionalidades conocidas o para proyectos, que aun siendo muy complejos, se entienden perfectamente desde el principio. Desarrollar nuevas versiones de sistemas ya veteranos en los que el desconocimiento de las necesidades de los usuarios, o del entorno de operacin no plantean riesgos. Sistemas pequeos, sin previsin de evolucin a corto plazo.

3.3.2. Ciclo de vida en V

Este ciclo fue diseado por Alan Davis, y contiene las mismas etapas que el ciclo de vida en cascada puro. A diferencia de aqul, a ste se le agregaron dos sub-etapas de retroalimentacin utilizados para probar si la aplicacin cumple las especificaciones. Una fase adems de utilizarse como entrada para la siguiente, sirve para validar o verificar otras fases posteriores.

Requisitos Verifica r Diseo preliminar

Operacin y mantenimiento

Verifica r Diseo en detalle

Calificacin

Integracin Verifica r Pruebas

Codificacin

Ventajas: Desarrollo de planes de prueba en etapas tempranas del ciclo de vida para lograr una mayor correccin. Planificacin sencilla Provee un producto con un elevado grado de calidad sin necesidad de un personal altamente calificado. Desventajas: Necesidad de contar con todos los requerimientos (o la mayora) al comienzo del proyecto. Tiene poca flexibilidad y ajustar el alcance es difcil y caro. El modelo no proporciona cambios claros para problemas encontrados durante las fases de pruebas. Resulta apropiado para:

Aplicaciones, que si bien son simples (pequeas transacciones sobre bases de datos por ejemplo), necesitan una confiabilidad muy alta. Un ejemplo claro en el que no nos podemos permitir el lujo de cometer errores es una aplicacin de facturacin, en la que si bien los procedimientos vistos individualmente son de codificacin e interpretacin sencilla, la aplicacin en su conjunto puede tener matices complicados.

3.3.3. Ciclo de vida tipo Sashimi

Este ciclo de vida es parecido al ciclo de vida en cascada puro, con la diferencia de que en el ciclo de vida en cascada no se pueden solapar las etapas, y en ste s. Esto suele, en muchos casos, aumentar su eficiencia ya que la retroalimentacin entre etapas se encuentra implcitamente en el modelo. Ventajas: La ganancia de calidad en lo que respecta al producto final. La falta de necesidad de una documentacin detallada (el ahorro proviene por el solapado de las etapas). No se necesita terminar por completo una fase para pasar a la siguiente, por ejemplo, sin tener terminado del todo el diseo se comienza a implementar. El solapamiento de sus etapas nos permite en la prctica jugar un poco con el modelo de programacin en tres capas ahorrando recursos. Desventajas: Es muy difcil gestionar el comienzo y fin de cada etapa y los problemas de comunicacin. Es an ms difcil controlar el progreso del proyecto debido a que los finales de fase ya no son un punto de referencia claro. Al hacer cosas en paralelo si hay problemas de comunicacin pueden surgir inconsistencias.

Requisitos Diseo preliminar Diseo en detalle Codificacin Pruebas Integracin Calificacin Operacin y mantenimiento

Resulta apropiado para: Una aplicacin que compartir los recursos (CPU, memoria o espacio de almacenamiento) con otras aplicaciones en un ambiente productivo.

3.3.4. Ciclo De Vida En Cascada Con Subproyectos.

Es una variacin del Ciclo de vida en Cascada, en este modelo cada una de las etapas de cascada se dividen en sub etapas independientes, actividades que se pueden desarrollar en paralelo ideal para proyectos en los cuales se cuenta con varios programadores. Ventajas: Se puede tener gente trabajando al mismo tiempo. Se puede utilizar para gestionar cualquier tipo de proyectos mencionados en los anteriores modelos de ciclo de vida. Desventajas Puede haber dependencias en cada uno de los proyectos si es que no se tiene una adecuada gestin. La planificacin tiene que ser mucho ms cuidadosa.

3.3.5 Ciclo De Vida Iterativo.

El ciclo de vida iterativo es otro ms de los basados en el ciclo de vida en cascada puro, este modelo tiene como fin evitar que debido a malos entendidos, el producto final no sea lo que el cliente solicit en la etapa de requerimientos. Para alcanzar esto se realizan iteraciones de varios ciclos de vida en cascada, entregando una versin mejorada, o ampliada, luego de cada iteracin. Una vez que el avance del producto fue entregado el cliente debe de evaluar el producto, corregirlo, o proponer mejoras. Continuamente se sigue iterando hasta que el producto final sea el requerido. Este modelo de ciclo de vida es ideal para utilizar en aquellas situaciones en las cuales el cliente no est completamente seguro de los requerimientos, o estos no logran ser claramente explicados, por lo que el modelo va creando distintos prototipos que vayan cada vez ms siendo de la aprobacin del cliente. Esta tambin ideal para esas aplicaciones que pueden ser implementadas paulatinamente.

3.3.5 Ciclo De Vida por Prototipos

Al igual que en modelo anterior, el uso de los prototipos se utilizan para validar los requerimientos en cualquier ciclo de vida. Cuando se presenta la situacin de que los requerimientos no han sido detallados, entendidos o clarificados con exactitud, se realiza primero un prototipo con especificaciones iniciales, obteniendo as un producto parcial y provisional. Se trata de lograr un producto intermedio para analizar como respondern las funcionalidades previstas para el producto final. Cuando se desea realizar un prototipo se debe evaluar la inversin y el esfuerzo de hacerlo, para determinar que tan factible es. Se utiliza primordialmente en proyectos donde se desconoce con exactitud los resultados posibles, o el comportamiento de mismo, como cuando se estn probando nuevas tecnologas. Sin embargo, es sumamente costoso y la administracin es complicada.

3.36 Ciclo de vida evolutivo.

Este modelo acepta que los requerimientos pueden cambiar en cualquier momento. Obtener todos los requerimientos al comienzo del proyecto es extremadamente difcil, no solo por la dificultad del usuario de transmitir su idea, sino porque estos requerimientos evolucionan durante el desarrollo y de est manera, surgen nuevos requerimientos a cumplir. El

modelo de ciclo de vida evolutivo afronta este problema mediante una iteracin de ciclos requerimientos-desarrollo-evaluacin. Resulta ser un modelo muy til cuando desconocemos la mayora de los requerimientos iniciales, o estos requerimientos no estn completos. Ejemplo: Sistema centralizado de stock-ventas-facturacin.

3.3.7 Ciclo de vida incremental

Este modelo del ciclo de vida se basa en la filosofa de construir incrementando las funcionalidades del programa. Se realiza construyendo por mdulos que cumplen diferentes funciones del sistema. Esto permite ir aumentando gradualmente las capacidades del software. Este ciclo de vida facilita la tarea del desarrollo permitiendo a cada miembro del equipo desarrollar un mdulo particular en el caso de que el proyecto sea realizado por un equipo de programadores. Es una repeticin del ciclo de vida en cascada, aplicndose este ciclo en cada funcionalidad del programa a construir. Al final de cada ciclo le entregamos una versin al cliente que contiene una nueva funcionalidad. Este ciclo de vida permite realizar una entrega al cliente antes de terminar el proyecto.

El modelo de ciclo de vida incremental genera algunos beneficios tales como los que se describen a continuacin: Construir un sistema pequeo siempre es menos riesgoso que construir un sistema ms grande. Como se desarrollan independientemente las funcionalidades, es ms fcil relevar los requerimientos del usuario. Si de detecta un error grave, solo se desecha la ltima iteracin. No es necesario disponer de los requerimientos de todas las funcionalidades en el comienzo del proyecto y adems facilita la labor del desarrollo con la conocida filosofa de divide &conqueror.

Este modelo de ciclo de vida no est pensado para cierto tipo de aplicaciones, sino que est orientado a cierto tipo de usuario o cliente. Se puede utilizar este modelo de ciclo de vida para casi cualquier proyecto, pero ser verdaderamente til cuando el usuario necesite entregas rpidas, aunque sean parciales.

3.4. MODELOS DE CICLO DE VIDA EN ESPIRAL

Este modelo sirve de base para otros como el ciclo de vida de 6 regiones y el ciclo de vida winwin.

3.4.1. Ciclo de vida en espiral

Este modelo, definido por Boehm en 1988, introduce como elemento distintivo la actividad de anlisis de riesgo para guiar la evolucin del proceso de desarrollo. Las actividades se encuentran en cada iteracin puestas a modo de un espiral, estas actividades son colocadas de acuerdo a la evaluacin de riesgo de la iteracin anterior Entre los riesgos se puede mencionar: requisitos no comprendidos, mal diseo, errores en la implementacin. Especificaciones En las iteraciones se tendrn en cuenta algunas especificaciones que se utilizaran en las fases del proyecto: Objetivos: Se elaboran haciendo entrevistas a los clientes, cuestionarios. Alternativas: Son las otras formas de solucin para el desarrollo que permiten cumplir con los objetivos planteados. Se hacen de acuerdo a las caractersticas del producto y las formas de gestionar el proyecto. Restricciones:para encontrar las restricciones se harn diferentes puntos de vista, como: - Desde el punto de vista del producto: Interfaces de tal o cual manera, rendimiento, etc. - Desde el punto de vista organizativo: Coste, tiempo, personal, etc. Riesgos: Lista de riesgos identificados. Resolucin de riesgos: Se formula usando la construccin de prototipos. Resultados: Es lo que se obtiene despus de la resolucin de riesgos. Planes: Lo que se va a hacer en la siguiente fase. Compromiso: Decisiones de gestin sobre como continuar. Al finalizar cada iteracin se verifica si la misma cumple con los requisitos establecidos y si funciona correctamente.El mismo cliente evala el producto. Fases: El ciclo de iteracin de este modelo evolutivo se convierte en una espiral, que al representarse sobre ejes cartesianos muestra en cada cuadrante una fase particular de actividad: Planificacin, Anlisis de riesgo, Ingeniera y Evaluacin, que se suceden de forma consecutiva a lo largo del ciclo de vida del desarrollo. Planificacin: En la planificacin se determinan objetivos, alternativas y restricciones, sus objetivos se centran en:

Conocer los requisitos que debe satisfacer el sistema (funciones y limitaciones de contexto). - Asegurar que los requisitos son alcanzables. - Formalizar el acuerdo con los usuarios. Anlisis de riesgo: Se analizan las alternativas e identifican o solucionan los riesgos, sus objetivos se centran en: - Identificar soluciones tecnolgicas para cada una de las funciones del sistema. - Establecer mtodos de validacin del diseo. - Ajustar las especificaciones del producto. Ingeniera: Se desarrolla el producto del "siguiente nivel", sus objetivos se centran en: - Generar el producto o servicio pretendido con el proyecto. - Integrar los elementos subcontratados o adquiridos externamente. - Validar que el producto obtenido satisface los requisitos de diseo previamente definidos y realizar, si es necesario, los ajustes necesarios en dicho diseo para corregir posibles lagunas, errores o inconsistencias. Evaluacin del cliente:Valorizacin de los resultados de la ingeniera, entre sus objetivos se destacan: - Asegurar que el uso del proyecto cumpla con la funcin pretendida. - Realizar un mantenimiento que no se limite a reparar averas o desgastes habituales sino adaptaciones al usuario. Este modelo permite mltiples combinaciones ya que en la planificacin de cada ciclo se determina el avance que se va a ejecutar durante la vuelta. ste puede consistir en la obtencin y validacin de requisitos, o en el desarrollo del diseo, o el diseo junto con la codificacin, o en la obtencin de un subsistema completo (cascada de requisitos diseo codificacin pruebas integracin).

Ventajas: No necesita una definicin completa de los requisitos para empezar a funcionar. Al entregar productos desde el final de la primera iteracin es ms fcil validar los requisitos. El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido el tiempo y recursos invertidos en una iteracin (las anteriores iteraciones estn bien). El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en etapas tempranas hay tiempo de subsanarlos. Desventajas: Es difcil evaluar los riesgos. Necesita de la participacin continua por parte del cliente. Cuando se subcontrata hay que producir previamente una especificacin completa de lo que se necesita, y esto lleva tiempo. Resulta apropiado para:

Sistemas de gran tamao.(Sistemas Operativos para navegadores , y controles aeronuticos) Proyectos de alto riesgo. Cuando no sea posible definir al principio todos los requisitos.

3.5. MODELOS DE CICLO ORIENTADO A OBJETOS

El modelo se basa en componentes que se relacionan entre ellos a travs de interfaces, siendo modulares y dividendo el trabajo en mini proyectos. Sigue el paradigma de la programacin orientada a objetos. Cada funcionalidad o requerimiento del cliente es un objeto. Se utilizan las fichas CRC(Clase-Responsabilidad-colaboracin) permiten las abstracciones y mecanismos claves de los requerimientos. En las fichas se escriben los nombres de las clases, las responsabilidades(mtodos) y los colaboradores. Sirven para crear los casos de uso. El modelo ms usado orientado a objetos es el modelo fuente.

3.5.1. Modelo fuente

Fue creado por Henderson-Sellers y Edwards en 1990. Es el tipo de ciclo de vida mas usada por la orientacin a objetos. Un proyecto se divide en las fases: Planificacin del negocio Construccin. Es la ms importante y se divide a su vez en otras cinco actividades Planificacin Investigacin Especificacin Implementacin Revisin Entrega La primera y la tercera fase son independientes de la metodologa de desarrollo orientado a objetos. Y En las tres fases, existen dos periodos: Crecimiento: Es el tiempo durante el cual se construye el sistema Madurez: Es el periodo de mantenimiento del producto. Cada mejora se planifica igual que el periodo anterior, es decir, con las fases de Planificacin del negocio, Construccin y Entrega. Cada clase puede tener un ciclo de vida slo para ella debido a que cada una puede estar en una fase diferente en un momento cualquiera Ventajas: Se puede implementar independientemente del lenguaje obtenido.

Es un modelo verstil. Construccin de prototipos. Agiliza el desarrollo de software. Es iterativo e incremental. Desventajas: Se necesita un amplio conocimiento de objetos, para hacer una valida seleccin en el proceso. Se requiere un exhaustivo anlisis, y mucha disciplina para que los resultados resulten un xito. A veces se vincula con la programacin orientado a objetos, y su uso exclusivo. Resultados apropiado para: Sistemas complejos de transacciones de base de datos. Programas de monitoreo de Procesos. Programacin por lotes. Creacin de Programas visuales.

4. MODELOS DE CICLOS DE DESARROLLO

4.1. MODELO DE DESARROLLO ITERATIVO
Muchas veces surgen problemas en el anlisis de requisitos ya que stos casi siempre son incompletos al principio o cambian a medida que se va desarrollando el software por ellos es prcticamente imposible elaborar requisitos completos y estables en el primer intento ya que es difcil encontrar usuarios que conozcan lo suficientemente lo

que quieren conseguir y que se pongan de acuerdo, es por ello que se la opcin ms razonable sera estudiar una parte de los requisitos que tengan autonoma y disearla, programarla y probarla, una vez que el cliente haya dado su visto bueno realizar lo mismo con otra etapa. Este modelo se basa en iteraciones de cada ciclo de vida en cascada desde el anlisis hasta la prueba, al final de ello se le entrega al cliente una versin mejorada o con mayores funcionalidades del producto permitiendo as que el cliente evalu y proponga mejoras del producto. Es ideal a seguir cuando el usuario necesita entregas rpidas aunque el producto no est terminado.

Ventajas: Permite reducir los riesgos que surgen entre las necesidades del usuario final y el producto. Se puede utilizar en proyectos donde no estn claros los requerimientos del usuario. Se puede adoptar en aplicaciones medianas a grandes. Desventajas Puede ser un desarrollo lento. Aumente el costo del producto.

4.2. MODELO DE DESARROLLO EVOLUTIVO

En este modelo se acepta que los requerimientos de los usuarios evolucionan conforme se avanza en el desarrollo, es decir pueden cambiar en cualquier momento del ciclo de vida y no solo en la etapa de anlisis, de manera que este problema en este ciclo se afronta a travs de la iteracin de especificacin de requerimientos, desarrollo y evaluacin, despus de cada desarrollo se obtiene una versin nueva del producto.

Los requerimiento son evaluados cuidadosamente y aquellos que son bien comprendidos son seleccionados para desarrollar una implementacin parcial del sistema. Esencialmente se basa en obtener un sistema inicial y exponerlo a los comentarios del usuario para refinarlo realizando en N versiones hasta lograr el desarrollo del sistema adecuado.

Ventajas: Resulta ser un modelo muy til cuando desconocemos la mayora de los requerimientos iniciales, o estos requerimientos no estn completos. Los usuarios y desarrolladores logran un mejor entendimiento del sistema. El Cliente se va familiarizando con el nuevo entorno. Desventajas: Los cambios continuos pueden ser perjudiciales para la estructura del software haciendo costo su mantenimiento. Difcil de aplicar en sistemas transaccionales que requieren ser integrados y operar como un todo. Resulta apropiado para: Proyectos pequeos o medianos con poco tiempo para su desarrollo y sin generar documentacin para cada versin. Desarrollo de sistemas interactivos y de inteligencia artificial.

4.3. MODELO DE DESARROLLO INCREMENTAL

Los riesgos de desarrollar sistemas largos y complejos son enormes, una forma de poder recudir dichos riesgos es construir una parte del sistema reservando otros aspectos para revisiones posteriores. Se basa en construir incrementando las funcionalidades del sistema para satisfacer un conjunto de requisitos especificados por el cliente que van a permitir seguir aumentando las capacidades del software. En el caso que se cuente con un equipo de programadores facilita la tarea del desarrollo permitiendo a cada uno desarrollar un modulo en particular.

Cada proyecto de software requiere una forma particular de abordar el problema.

Ventajas: Permite realizar entregas al cliente antes de terminar el proyecto. Reducir riesgos. Resulta ms fcil relevar los requerimientos del usuario. Si se detecta un error grave solo se desecha la ltima iteracin. Se ajusta de alta incertidumbre (ya que en cada refinamiento se ampla los requerimientos y especificaciones de fases anteriores. Desventajas: Cada incremento debe aumentar la funcionalidad. Difcil de establecer la correspondencia de los requisitos contra los incrementos. Resulta apropiado para: Cierto tipo de usuario o cliente. Todo tipo de proyectos pero ser verdaderamente til cuando el usuario necesite entregas rpidas

5. MODIFICADORES DE LOS MODELOS

5.1. PROTOTIPOS
Prototipo: Representacin limitada del diseo de un producto que permite a los desarrolladores experimentar en su creacin, evaluar el desarrollo del producto y clarificar los requisitos de los usuarios para definir alternativas.

Este ciclo de vida es ideal si no se conoce como desarrollar un determinado producto o las especificaciones de forma precisa, para ello se recurre a definir especificaciones iniciales para hacer productos provisionales o parciales con el objetivo de lograr un producto intermedio antes de lograr el producto final permitiendo as conocer como van a responder las funcionalidades previstas para el producto final. Consiste en iterar la fase de anlisis cuanta veces sea necesario mostrando prototipos a los usuarios para que puedan experimentan con l, quienes proveen retroalimentacin de lo que les gusto y lo que no les gust acerca del prototipo proporcionado permitiendo as que se puedan capturar en la documentacin actual la especificacin de requerimientos, la informacin entregada por los usuarios para el desarrollo del producto final. Esta iteracin finalizar cuando el usuario d el visto bueno al prototipo.

Ventajas: Apto para desarrollo en los que no se conoce a priori sus especificaciones Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios. Desventaja: Es altamente costoso. No presenta calidad, ni robustez. Exige disponer de herramientas adecuadas. Resulta Apropiado para: Desarrollo de productos innovadores o en el uso de tecnologas nuevas o muy poco probadas.

5.2. MODELO CONCURRENTE:

El modelo concurrente est representado en forma de esquema como actividades tcnicas importantes, tareas y estados asociados a ellas. Representa un estado de una actividad de ingeniera del software. Al principio la actividad de comunicacin con el cliente ha finalizado su primera iteracin y est en el estado de cambios en espera. La actividad de anlisis ahora hace una transicin al estado bajo desarrollo. Si el cliente indica que se deben hacer cambios en los requisitos, la actividad anlisis cambia del estado bajo desarrollo al estado cambios en espera. El modelo concurrente define una serie de acontecimientos traer consigo transiciones de estado a estado para cada una de las actividades. Durante las primeras etapas del diseo, no se contempla una inconsistencia del modelo de anlisis. Esto genera la

correccin del modelo de anlisis de sucesos, que provocar a la actividad de anlisis del estado hecho al estado cambios en espera. El modelo concurrente se utiliza como paradigma de desarrollo de aplicaciones cliente/servidor, que cuando se aplica, define actividades en dos dimensiones: una dimensin de sistemas y una dimensin de componentes. Los aspectos del nivel de sistemas se afrontan mediante tres actividades: diseo, ensamblaje y uso. La dimensin de componentes se afronta con dos actividades: diseo y realizacin. La concurrencia se logra de dos formas: - las actividades de sistemas y de componentes ocurren simultneamente y pueden modelarse con el enfoque orientado a objetos. - una aplicacin cliente/servidor tpica se implementa con muchos componentes, cada uno de los cuales se pueden disear y realizar concurrentemente. Ventajas: Excelente para proyectos en los que se conforman grupos de trabajo independientes. Proporciona una imagen exacta del estado actual de un proyecto. El modelo de proceso concurrente es aplicable a todo tipo de desarrollo de software Desventajas: Si no existen grupos de trabajo no se puede trabajar en este mtodo.

Metodologas para el Desarrollo del Software

Para garantizar la calidad de la informacin de cualquier empresa es necesario que el personal colabore de forma eficiente en la construccin de aplicaciones, y esto se consigue definiendo de antemano una serie de etapas intermedias que permitan aumentar la eficiencia del trabajo. La Metodologa es el conjunto de procedimientos, tcnicas, herramientas, y un soporte documental que ayuda a los desarrolladores a realizar nuevas aplicaciones informticas. Normalmente consistir en un conjunto de fases descompuestas en subfases (mdulos, etapas, pasos, etc.). Esta descomposicin del proceso de desarrollo gua a los desarrolladores en la eleccin de las tcnicas que debe elegir para cada estado del proyecto, y facilita la planificacin, gestin, control y evaluacin de los proyectos. Una metodologa, por tanto, representa el camino para desarrollar aplicaciones informticas de una manera sistemtica.

Evolucin de las metodologas

En la siguiente tabla podemos ver cmo han surgido las metodologas ms representativas en la historia de la Ingeniera del Software.

Ao s

Metodologas

1968 1974 1975 1977 1978 1981 1985 1986 1987 1989 1990 1993 1995
Metodologa

Concepcin sobre la programacin estructurada de DIJKDTRA Tcnicas de programacin estructurada de WARNIER y JACKSON Primeros conceptos sobre diseo estructurado de MYERS y YOURDON Primeros conceptos sobre el anlisis estructurado GANE y SARSON Anlisis estructurado : DEMARCO y WIINBERG. Nace MERISE SSADM. InformationEngineering Anlisis y Diseo estructurado para sistemas de tiempo real de WARD y MELLOR SSADM Versin 3 Anlisis y Diseo estructurado para sistemas de tiempo real de HATLEY Y PIRHBAY METRICA SSADM Versin 4 METRICA Versin 2 METRICA Versin 2.1

Conjunto de actividades necesarias para transformar los requisitos de los usuarios en un sistema software

Conjunto de tcnicas, procedimientos que permiten idear, planificar y mantener un producto software desde que surge la necesidad del producto hasta que se cumple el objetivo por el cual fue creado Desarrollador: Gestin Cliente: Garantiza un nivel de calidad en el producto Confianza en los tiempos fijados del proyecto. Facilita el control y seguimiento del proyecto Optimiza los recursos disponibles. Facilita la comunicacin entre los usuarios y desarrolladores Ayuda a comprender el problema. Le permite la reutilizacin del producto.

CLASIFICACION: 1- M. ESTRUCTURADAS 2- M. ORIENTADA A OBJETOS 3- M. TRADICIONAL (NO 4- M. AGILES 1.1 ESTRUCTURA GENERAL MERISE
Las bases de MERISE comenzaron en 1.972 por un equipo universitario de ingenieros de Aix-enProvence. La primera versin sali a finales de 1.976. El proyecto parti del Centre TechniqueInformatique del Ministerio de Industria Francs en Septiembre de 1.977, para cubrir las necesidades tanto de la administracin como de las empresas. El proyecto finaliz en mayo de 1.978 dando lugar a MERISE como metodologa de Anlisis y Diseo de Sistemas de Informacin.

AGIL)

Aporta un ciclo de vida ms largo a los existentes hasta entonces que se materializa en un conjunto definido de etapas Fases: Estudio preliminar. Estudio detallado. Implementacin. Realizacin y puesta en marcha.

1.2 ESTRUCTURA GENERAL DE SSADM

El gobierno britnico plantea la necesidad de crear una metodologa y se desarroll entre el Central Computing and Telecommunications Agency (CCTA) y Learmonth and Burchett Management Systems (LBMS), dando como resultado la metodologa SSADM (StructuresSystemsAnalysis and DesignMethod).

Proporciona un conjunto de procedimientos para llevar a cabo el anlisis y diseo, pero no cubre aspectos como la planificacin estratgica ni entra en la construccin del cdigo.

Aspectos claves: nfasis en los usuarios : sus requisitos y participacin.

Definicin del proceso de produccin : qu hacer, cundo y cmo. Tres puntos de vista : datos, eventos, procesos. Mxima flexibilidad en herramientas y tcnicas de implementacin.

1.3 ESTRUCTURA GENERAL DE MTRICA V 2.0 Propuesta por el Ministerio de las Administraciones Pblicas para que todas las organizaciones sigan el mismo modelo y unificar los criterios para mayor homogeneidad y eficiencia en las aplicaciones informticas

Para construir Mtrica v 2.0 hay unas etapas intermedias en las que hay que asegurar la calidad en la construccin de las aplicaciones informticas relacionadas con el campo del tratamiento de la informacin, elaborando un marco homogneo de referencia para verificar que los productos que se generen tengan el nivel de calidad apropiado y que se cumplan las previsiones iniciales de plazo y coste. Mtrica est en versin 2 porque en 1.991 se decidi revisar el proyecto Mtrica con el objetivo de obtener una nueva versin por los siguientes motivos : Mejorar la anterior versin de 1.989 Responder a la demanda por parte de los centros informticos de una referencia para el desarrollo de sistemas de informacin. Contar con una metodologa compatible con EuroMtodo Aprovechar el mercado de herramientas CASE mucho mayor que cuando se realiz la primera versin de Mtrica.

Fases: Fase 0 : Plan de sistemas de informacin Fase 1 : Anlisis de sistemas Fase 2 : Diseo de sistemas Fase 3 : Construccin de sistemas Fase 4 : Implementacin de sistemas

A continuacin vamos a dar una breve descripcin de las fases de Mtrica v.2.0.

Fase 0 : Plan de sistemas de informacin

En esta fase de la metodologa de Mtrica v.2 se pretende definir :

La informacin necesaria para satisfacer los objetivos estratgicos de la organizacin. La arquitectura de la informacin, en cuanto a procesos y datos, y as satisfacer los objetivos estratgicos de la organizacin. Los nuevos sistemas a desarrollar para implantar dicha arquitectura.

PSI 1: DEFINIR OBJETIVOS, ORGANIZACION, AMBITO Y PLANIFICACION DEL PROYECTO

Especificacin de objetivos Identificacin de las Unidades afectadas Organizacin de los participantes Planificacin del proyecto

PSI 2: IDENTIFICAR LAS NECESIDADES DE INFORMACION DE LAS UNIDADES AFECTADAS

Identificacin de funciones y objetivos Identificacin de requisitos Identificacin de las necesidades de informacin

PSI 3: IDENTIFICAR LAS DIRECTRICES DE GESTION Y TECNICAS.

Identificacin de las directrices de gestin Identificacin de las directrices tcnicas

PSI 4: DISEAR LA ARQUITECTURA DE LA INFORMACION

Diseo del modelo conceptual de datos Diseo de la jerarqua de funciones Diseo de la Arquitectura de la Informacin

PSI 5: REVISAR LA SITUACION ACTUAL DE LOS SISTEMAS DE INFORMACION.

Identificacin y descripcin de los sistemas existentes Anlisis del entorno tecnolgico actual Diagnstico de la situacin actual

PSI 6: ESPECIFICAR LOS NUEVOS SISTEMAS.

Identificacin de mejoras en los sistemas actuales Identificacin de nuevos sistemas Determinacin de prioridades de desarrollo Especificacin de los sistemas

PSI 7: DEFINIR LAS ALTERNATIVAS TECNOLOGICAS.

Identificacin de necesidades tecnolgicas futuras Definicin de opciones tecnolgicas

PSI 8: ELABORAR EL PLAN DE ACCION.

Elaboracin de un plan de implantacin Mantenimiento del plan de sistemas

Fase 1 : Anlisis de sistemas

El objetivo de esta fases describir el alcance y los requisitos del sistema generando diferentes alternativas para solucionar el problema y recomendar una de ellas si es oportuno. Una vez seleccionada una alternativa se tiene que generar las especificaciones formales que describan al sistema y estas tienen que ser aprobadas por el usuario. ARS: ANALISIS DE REQUISITOS DEL SISTEMA

En este mdulo se identifican los requisitos que ha de satisfacer el sistema y se evalan las distintas alternativas que solucionan el problema recomendando una de ellas. ARS 1: ESTABLECER EL AMBITO Y ALCANCE DEL PROYECTO.

Definicin del Proyecto Identificacin de los usuarios participantes

ARS 2: IDENTIFICAR Y DEFINIR REQUISITOS

Planificacin y realizacin de entrevistas Identificacin de problemas y necesidades

ARS 3: DISEAR EL MODELO LOGICO ACTUAL

Construccin del modelo lgico actual de procesos. Construccin del modelo lgico actual de datos

ARS 4: ESTUDIAR ALTERNATIVAS DE CONSTRUCCION

Definicin de Alternativas. Seleccin de una Alternativa.

DOCUMENTACION ASOCIADA AL MODULO ARS EFS: ESPECIFICACION FUNCIONAL DEL SISTEMA En este mdulo se construyen las especificaciones detalladas del sistema partiendo de los requisitos y soluciones obtenidos del mdulo anterior. EFS 1: CONSTRUIR EL MODELO DE PROCESOS DEL NUEVO SISTEMA

Diseo del diagrama de contexto del sistema Identificacin y definicin de subsistemas Especificacin de interfaces con otros sistemas Descripcin de procesos manuales

EFS 2: CONSTRUIR EL MODELO DE DATOS DEL NUEVO SISTEMA

Construccin del modelo de datos Normalizacin del modelo de datos

EFS 3: REALIZAR EL ANALISIS DETALLADO DEL NUEVO SISTEMA

Construccin del modelo entidad-evento Consolidacin de los modelos de datos y procesos

EFS 4: DEFINIR INTERFASES DE USUARIO

Produccin de prototipos preliminares y dilogos Especificacin de informes y formularios

EFS 5: COMPLETAR ESPECIFICACIONES DEL SISTEMA

Especificacin de requisitos de seguridad y control Especificacin de requisitos de copias de respaldo, contingencias y recuperacin de errores Especificacin de requisitos de rendimiento

EFS 6: COMPLETAR ESPECIFICACIONES DE ENTREGA

Preparacin del plan de pruebas del sistema Especificacin del plan de entrega del sistema Verificacin y validacin de la especificacin funcional del sistema.

DOCUMENTACION ASOCIADA AL MODULO EFS

Fase 2 : Diseo de sistemas

En esta fase su objetivo es obtener las especificaciones fsicas del sistema para la construccin del mismo. DTS: DISEO TECNICO DEL SISTEMA En este mdulo se describe como ser el sistema desde el punto de vista fsico, para ello tenemos que disear la arquitectura fsica del sistema, el esquema externo de datos del sistema teniendo en cuenta el entorno tecnolgico en que va a funcionar. DTS 1: DISEAR LA ARQUITECTURA FISICA DEL SISTEMA.

Diseo de la Estructura modular del sistema Descripcin de interfaces entre mdulos del sistema Descripcin de interfaces con otros sistemas Descripcin de interfaces de usuario Definicin de componentes del sistema

DTS 2: DISEAR LA ESTRUCTURA FISICA DE DATOS DEL SISTEMA.

Elaboracin del modelo fsico de datos Optimizacin del modelo fsico de datos

DTS 3: ESPECIFICAR EL ENTORNO TECNOLOGICO DEL SISTEMA.

Definicin del entorno tecnolgico del sistema Especificacin de requisitos de comunicaciones del sistema Especificacin de requisitos de operacin, seguridad y control

DTS 4: COMPLETAR EL PLAN DE PRUEBAS DEL SISTEMA.

Diseo de planes de prueba del sistema Definicin del entorno y limitaciones de prueba.

DTS 5: COMPLETAR ESPECIFICACIONES DE DISEO.

Preparacin de planes de construccin Preparacin de planes para la implantacin Revisin del Diseo Tcnico del Sistema

DOCUMENTACION ASOCIADA AL MODULO DTS

Fase 3 : Construccin de sistemas

El objetivo de esta fase es construir y probar los componentes del sistema obtenidos en las especificaciones fsicas de la fase anterior de Diseo de Sistemas. DCS: DESARROLLO DE COMPONENTES DEL SISTEMA En este mdulo se realizan la construccin, pruebas unitarias y de integracin del equipo lgico y se desarrollan los procedimientos de operacin de componentes del sistema. DCS 1: PREPARAR ENTORNO DE DESARROLLO, PRUEBAS Y PROCEDIMIENTOS DE OPERACION.

Implantacin de la Base de Datos Fsica o ficheros de datos Preparacin del entorno de desarrollo Preparacin del entorno de pruebas Definicin de procedimientos de operaciones de produccin e implantacin

DCS 2: DESARROLLAR Y PROBAR COMPONENTES DEL SISTEMA

Generacin del cdigo de los componentes del sistema Preparacin, ejecucin y evaluacin de las pruebas unitarias Documentacin de los componentes del Sistema

DCS 3: REALIZAR PRUEBAS DE INTEGRACION

Preparacin y ejecucin de pruebas de integracin Evaluacin y documentacin de los resultados de las pruebas de integracin

DOCUMENTACION ASOCIADA AL MODULO DTS DPU: DESARROLLO DE PROCEDIMIENTOS DE USUARIO En este mdulo se definen todas las operaciones que han de realizar los usuarios para trabajar con el sistema y se les suministra a los usuarios toda la informacin necesaria para que sean capaces de utilizar el nuevo sistema de forma satisfactoria, obteniendo los mejores beneficios. DPU 1: COMPLETAR EL PLAN DE DESARROLLO DE PROCEDIMIENTOS DE USUARIO.

Preparacin de un borrador del plan de desarrollo de procedimientos de usuario. Especificacin de criterios de calidad y estndares de procedimientos de usuario.

DPU 2: ELABORAR PROCEDIMIENTOS DE USUARIO

Diseo de la estructura de los procedimientos de usuario Elaboracin de procedimientos de usuario

DPU 3: DETERMINAR NECESIDADES ESPECIALES PARA EL FUNCIONAMIENTO DEL SISTEMA

Identificacin de perfiles de usuario Especificacin de recursos necesarios

DPU 4: DESARROLLAR PLAN DE FORMACION DE USUARIOS

Identificacin de requisitos y recursos necesarios para la formacin de usuarios. Preparacin de los materiales de formacin de usuarios

DPU 5: CONSOLIDAR PROCEDIMIENTOS DE USUARIO

Organizacin de la documentacin de procedimientos de usuario. Consolidacin de la documentacin de procedimientos de usuario

Fase 4 : Implementacin de sistemas

El objetivo de esta fase es conseguir la aceptacin final del nuevo sistema por parte de los usuarios y poner en funcionamiento el nuevo sistema. PIA: PRUEBAS, IMPLANTACION Y ACEPTACION DEL SISTEMA En este mdulo se realizarn las pruebas de sistema y las de aceptacin, es decir, se comprueba el sistema en su totalidad y as posteriormente, poner en explotacin el nuevo sistema. PIA 1: DISEAR Y REALIZAR LAS PRUEBAS DEL SISTEMA

Preparacin de las pruebas del sistema Creacin del entorno de pruebas del sistema Realizacin de las pruebas del sistema

PIA 2: ACTUALIZAR EL PLAN DE IMPLANTACION

Revisin del plan de implantacin Preparacin del plan de trabajo de implantacin

PIA 3: REALIZAR LAS PRUEBAS DE ACEPTACION

Preparacin de las pruebas de aceptacin Preparacin del entorno de produccin Realizacin de las pruebas de aceptacin

PIA 4: ESTABLECER PROCEDIMIENTOS DE PRODUCCION

Instalacin de procedimientos automticos de produccin Instalacin de procedimientos manuales de produccin Inicio de procedimientos de produccin

2. ORIENTADA A OBJETOS: Proponen el Mtodo Unificado con la idea de conseguir una unificacin de sus mtodos y notaciones, que posteriormente da lugar al UnifiedModelingLanguage .

3. METODOLOGIA TRADICIONAL NO AGILES Son aquellas que estn guiadas por una fuerte planificacin durante todo el proceso de desarrollo

Se realiza una intensa etapa de anlisis y diseo antes de la construccin del sistema

4. METODOLOGIA AGILES INCREMENTAL: Entregas pequeas de software en un ciclo corto COOPERATIVO: Clientes y desarrolladores trabajan juntos SENCILLO: Mtodo fcil de aprender y modificar ADAPTABLE: Permite realizar cambios a ltimo momento.