You are on page 1of 9

Modelos del ciclo de vida del Software

l. Modelo en V
Es una representación gráfica del ciclo de vida del desarrollo del sistema. Resume
los pasos principales que hay que tomar en conjunción con las correspondientes
entregas de los sistemas de validación.

La corriente de especificación (parte izquierda, Project definition) consiste
principalmente de:

Conceptos de operaciones: que debe hacer el sistema a grandes rasgos.

Requisitos del sistema y arquitectura del mismo.

Diseño detallado.
La corriente de pruebas (parte derecha, Project test and integration), por su parte,
suele consistir de:

Integración de las distintas partes, prueba y verificación de las mismas.

Verificación y validación del sistema en conjunto.

Mantenimiento del sistema.

Formas de gestión del sistema. Modelo en espiral En cada vuelta o iteración hay que tener en cuenta:  Los Objetivos: qué necesidad debe cubrir el producto. ll. Modelo en espiral Este sistema es muy utilizado en proyectos grandes y complejos como puede ser. la creación de un Sistema Operativo.La corriente de desarrollo puede consistir (depende del tipo de sistema y del alcance del desarrollo) en personalización. Angular: Indica el avance del proyecto del software dentro de un ciclo. etc. requisitos a cumplir. desde diferentes puntos de vista como pueden ser: 1. Riesgo asumido con cada alternativa. configuración o codificación. La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones.  Desarrollar y Verificar: Programar y probar el software. Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades:  Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. Radial: Indica el aumento del coste del proyecto. Tareas . 2. 3. Al ser un modelo de Ciclo de Vida orientado a la gestión de riesgo 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 los riesgos. Características: experiencia del personal. la radial y la angular: 1.  Alternativas: las diferentes formas de conseguir los objetivos de forma exitosa. ya que con cada nueva iteración se pasa más tiempo desarrollando. por ejemplo. 2.

manual de usuario.  Dependiendo del resultado de la evaluación de los riesgos. 4. un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. se elige un modelo para el desarrollo.  Hay una cosa que solo se hace una vez: planificación inicial.' Determinar o fijar objetivos  Fijar también los productos definidos a obtener: requerimientos. cascada. el que puede ser cualquiera de los otros existentes.  Análisis de alternativas e identificación resolución de riesgos. Si lo riesgos de protección son la principal consideración. como formal. especificación. 'Planificación. 3.  Identificación de riesgos del proyecto y estrategias alternativas para evitarlos.  Fijar las restricciones. Así si por ejemplo si los riesgos en la interfaz de usuario son dominantes. 2. Desarrollar y probar. Desarrollar. verificar y validar(probar)  Tareas de la actividad propia y de prueba. Determinar Objetivos. Análisis del riesgo. un desarrollo basado en transformaciones formales podría ser el más apropiado. evolutivo. Análisis del riesgo .Para cada ciclo habrá cuatro actividades: 1. etc.

Son todos los requerimientos. Las 6 regiones que componen este modelo son las siguientes:  Comunicación con el cliente .  Planificación . el tiempo y otras informaciones relacionadas con el proyecto.  La dimensión angular mide el grado de avance del proyecto.  Ingeniería .Tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación.  Construcción y adaptación . 3 Modelo en espiral WIN WIN (Ganar Ganar) El modelo Win-Win es una adaptación del modelo espiral que se enfatiza en la participación del cliente en el proceso de desarrollo de un producto de software.  Análisis de riesgos – Tareas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto. a diferencia del modelo de proceso clásico que termina cuando se entrega el software. Se evalúan alternativas.  Evaluación del cliente . instalar y proporcionar soporte a los usuarios. probar. En resumen.Tareas requeridas para construir.Tareas necesarias para plantear la comunicación entre el desarrollador y el cliente. es para tener en cuenta de los riesgos de cada uno de los ámbitos Mecanismos de Control  La dimensión radial mide el coste. Se debe tener un prototipo antes de comenzar a desarrollar y probar. . Variaciones del modelo en espiral Modelo en Espiral Típico de seis regiones El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora.Tareas para construir una o más representaciones de la aplicación.Tareas inherentes a la definición de recursos. Se lleva a cabo el estudio de las causas de las posibles amenazas y probables eventos no deseados y los daños y consecuencias que éstas puedan producir.

Para lograr este objetivo. "ganar-ganar".En un caso ideal. que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos. y el desarrollador trabaja para alcanzar presupuestos y fechas de entrega. es decir. Sin embargo esto no suele ocurrir en la mayoría de los casos y es necesario que se establezcan negociaciones significativas entre ambas partes para equilibrar la funcionalidad y rendimiento con los costos y tiempo de salida al mercado del producto. 4 lll. De esta fase surge una memoria llamada SRD (documento de especificación de requisitos). El cliente recibe el producto que satisface la mayoría de sus necesidades. no pudiéndose requerir nuevos resultados a mitad del proceso de elaboración del software de una manera. el desarrollador simplemente pregunta al cliente lo que se requiere y el cliente proporciona suficiente información y detalles para proceder. Modelo en Cascada Fases: Análisis de requisitos En esta fase se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. El modelo Win-Win deriva su nombre del objetivo de estas negociaciones. Es importante señalar que en esta etapa se debe consensuar todo lo que se requiere del sistema y será aquello lo que seguirá en las siguientes etapas. se realizan varias actividades de negociación al principio de cada paso alrededor de la espiral. Diseño del Sistema .

ya programados. Diseño del Programa Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario así como también los análisis necesarios para saber qué herramientas usar en la etapa de Codificación Codificación Es la fase en donde se implementa el código fuente. Es conveniente distinguir entre diseño de alto nivel o arquitectónico y diseño detallado. Mantenimiento .Descompone y organiza el sistema en elementos que puedan elaborarse por separado. se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos. así como la manera en que se combinan unas con otras. Como resultado surge el SDD (Documento de Diseño del Software).. Con ello se define la arquitectura de la solución elegida. para ello el o los programadores ya realizaron exhaustivas pruebas para comprobar que el sistema no falle. Pruebas Los elementos.. El primero de ellos tiene como objetivo definir la estructura de la solución (una vez que la fase de análisis ha descrito el problema) identificando grandes módulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Verificación Es la fase en donde el usuario final ejecuta el sistema. aprovechando las ventajas del desarrollo en equipo. antes de ser entregado al usuario final. haciendo uso de prototipos así como de pruebas y ensayos para corregir errores. Dependiendo del lenguaje de programación y su versión se crean las bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucho más rápido. En la creación de desarrollo de cascada se implementa los códigos de investigación y pruebas del mismo. que contiene la descripción de la estructura relacional global del sistema y la especificación de lo que debe hacer cada una de sus partes. El segundo define los algoritmos empleados y la organización del código para comenzar la implementación.

en su versión española. Implementación y Prueba. El Proceso Unificado de Desarrollo de Software(ISBN 84-7829036-2) y fue publicado en 1999 por Ivar Jacobson. Características Iterativo e Incremental El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio. Por dicho motivo. Construcción y Transición. el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto. por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. es el mantenimiento del Software ya que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras expectativas. Grady Booch y James Rumbaugh. De la misma forma. el Proceso Unificado de Rational. El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes. Elaboración. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas. Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clásico o en cascada: Análisis de requisitos. Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que añade o mejora las funcionalidades del sistema en desarrollo. Desde entonces los autores que publican libros sobre el tema y que no están afiliados a Rational utilizan el término Proceso Unificado. centrado en la arquitectura y por ser iterativo e incremental. El Proceso Unificado no es simplemente un proceso. el Lenguaje Unificado de Modelado. . Modelo de proceso unificado El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso. Diseño.Una de las etapas más críticas. también es un marco de trabajo extensible. ya que se destina un 75% de los recursos. conocidos también por ser los desarrolladores del UML. lV. los dos nombres suelen utilizarse para referirse a un mismo concepto. mientras que los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational. El primer libro sobre el tema se denominó. El refinamiento más conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP. También permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra deRational Software Corporation en 2003). Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio puede incluir varias iteraciones en proyectos grandes). sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos.

cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad. Jim que menciona el tema. fontanería. Lenguaje unificado de modelado El Lenguaje unificado de modelado. Dirigido por los casos de uso En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. en especial los de la fase de Elaboración deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero.Diagrama ilustrando como el énfasis relativo en las distintas disciplinas cambia a lo largo del proyecto. etc. Enfocado en los riesgos El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos críticos en una etapa temprana del ciclo de vida. etc. Nota: en UP se está Dirigido por requisitos y riesgos de acuerdo con el Libro UML 2 de ARLOW. Centrado en la arquitectura El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos del sistema. La analogía con la construcción es clara. La idea es que cada iteración tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a través de las distintas disciplinas: diseño. sobre todo. los métodos de . Los resultados de cada iteración. El UML unifica. Por dicho motivo existen múltiples modelos y vistas que definen la arquitectura de software de un sistema. prueba. no es el sucesor de la oleada de métodos de análisis y diseño orientados a objetos que surgió a finales de la década de los 1980 y principios de la siguiente. El proceso dirigido por casos de uso es el rup. implementación.

visión. instalado y utilizado por el cliente sin ningún problema. nuevos requisitos y se ajustan las estimaciones. se debe comenzar a pensar en futuras novedades para la misma. Brühl (OMT) y Jacobson. Tantos el punto de vista Gerencial como el Técnico concuerdan en: La iteración. Construcción Esta abarca la evolución hasta convertirse en producto listo incluyendo requisitos mínimos. Aquí se afinan los detalles menores como los diferentes tipos de casos o los riesgos menores. Una vez finalizada esta fase. implementación y pruebas. la implementación iterativa del núcleo del de la aplicación. pero su alcance ha llegado a formar parte fundamental de la Ingeniería de Software tras su estandarización en 1997 con el OMG (Object Management Group o Grupo de administración de objetos). Transición En esta fase final. Elaboración En esta fase se obtiene la visión refinada del proyecto a realizar. metas. plazos. la resolución de riesgos altos. diseño. Rumbaugh. deseos del usuario. Inicio En la fase de inicio se define el negocio: facilidad de realizar el proyecto. Fases El Proceso Unificado de desarrollo puede ser dividido en cuatro fases para su mejor desarrollo. análisis. costos y viabilidad.Booch. se presenta un modelo. Estas fases ayudando tanto a la elaboración como a la resolución de problemas. Desde el punto de vista Técnico: el proyecto está formado por los flujos de trabajo fundamentales: captura de requerimientos. el programa debe estar listo para ser probado. .