CICLO DE VIDA DE DESARROLLO DE SOFTWARE MODELO ESPIRAL El Modelo en Espiral, es un modelo de proceso de software evolutivo y construccin de prototipos sistemticos

del modelo lineal secuencial. Ideal para realizar versiones incrementales de manera rpida El software se desarrolla en una serie de versiones incrementales. Proporciona el potencial para el desarrollo rpido de versiones incrementales del software. El modelo, representado mediante la espiral de la Figura 1 define cuatro actividades principales, representadas por los cuatro cuadrantes. 1. 2. 3. 4. Planificacin: determinacin de objetivos, alternativas y restricciones. Anlisis de riesgo: anlisis de alternativas e identificacin/resolucin de riesgos. Ingeniera: desarrollo del producto de siguiente nivel Evaluacin del cliente: valoracin de los resultados de la ingeniera

MODELO PROTOTIPO Un cliente define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, proceso o salida. En otros casos, el responsable del desarrollo del software puede no estar seguro de la eficacia de un algoritmo de la capacidad de adaptacin de un sistema operativo El paradigma de construccin de prototipos comienza con la recoleccin de requisitos. El desarrollador y el cliente encuentran y definen los objetivos para que identifique los requisitos donde aparese un diseo rpido lleva a la contraccin del prototipo. El prototipo evala al cliente y usuario y se utiliza para refinar los requisitos de software a desarrollar , el prototipo satisface al cliente al mismo tiempo q el desarrollador comprende mejor lo que se necesita hacer al usuario le gusta el sistema real y a los desarrolladores les interesa construirlo rpido pero no sabes q les puede ocasionar problemas como ser:

El cliente no tiene conocimiento del prototipo lo que pide es que se haga rpido sin saber que con la prisa le lleva a un software sin calidad. El desarrollador hace el compromiso de implementar el prototipo para que funcione rpido, y para ello utiliza herramientas inadecuadas como lenguajes de programacin inadecuado. MODELO DE CONSTRUCCIN DE PROTOTIPOS Ofrece su enfoque a travs del paradigma de construccin de prototipos.

Construir y Revisar Maqueta

Escuchar al Cliente

El cliente prueba la maqueta

TECNICAS DE LA CUARTA GENERACION Son herramientas de software que facilitan al desarrollador y que genera automticamente el cdigo fuente basndose. La ingeniera se orienta hacia la posibilidad de especificar el software usando lenguajes de notaciones graficas que describan el problema que hay que resolver en el trmino que el cliente los entienda.El cliente puede no estar seguro de lo que se necesite puede ser ambiguo en la especificacin de hechos que le son conocidos y que puede que no sea capaz.Para aplicaciones pequeas se puede ir directamente desde el paso de recoleccin de requisitos al paso de implementacin usando el lenguaje de cuarta generacin. La implementacin mediante L4D permite al que desarrolla el software teniendo resultados deseados que es lo que se traduce automticamente en cdigo fuente.

Recoleccin de requerimientos

Estrategia de diseo

Implementaci n usando T4G

Producto

Mantenimiento
Concepto. El paradigma de T4G para la ingeniera de software se orienta hacia la habilidad de especificar software a un nivel que sea ms prximo al lenguaje natural o a una notacin que proporcione funciones significativas. Abarca un amplio espectro de herramientas de software que facilitan el desarrollo del proyecto. Las herramientas incluyen lenguajes no procedimentales, generadores de pantallas, informes, cdigo automtico, etc. Se empieza con la recoleccin de requisitos. Para aplicaciones pequeas se puede ir directamente al paso de implementacin usando un lenguaje de cuarta generacin no procedimental (L4G). Sin embargo es necesario invertir algo de esfuerzo en plantear una estrategia de diseo, ya que sin este tendramos los mismos problemas de calidad y mantenimiento. Ventajas. El uso de T4G es un enfoque viable para muchas de las diferentes reas de aplicacin. Junto con las herramientas de la ingeniera de software asistida por computadora y los generadores de cdigo, T4G ofrece una solucin fiable a muchos problemas de software. La recoleccin de datos preliminares que acompaan al uso de T4G parece indicar que el tiempo requerido para producir software se reduce mucho para aplicaciones pequeas de trabajo medio as como tambin la cantidad e anlisis y diseo. Reducciones drsticas en el tiempo de desarrollo del software y una mejora significativa en la productividad de la gente que construye el software. Desventajas. Las T4G esta limitada a las aplicaciones de sistema de informacin comercial, y de la obtencin de informes en las grandes bases de datos. Las herramientas actuales de T4G no son mas fciles de utilizar que los lenguajes de programacin. El cdigo fuente producido por tales herramientas es ineficiente y el mantenimiento de grandes sistemas de software desarrollados mediante T4G, es cuestionable.

y y y

PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE (PUDS). Concepto. El Proceso Unificado "es un proceso de desarrollo de software configurable que se adapta a travs de los proyectos variados en tamaos y complejidad. El Proceso Unificado gua a los equipos de proyecto en cmo administrar el desarrollo iterativo de un modo controlado mientras se balancean los requerimientos del negocio, el tiempo al mercado y los riesgos del proyecto. El proceso describe los diversos pasos involucrados en la captura de los requerimientos y en el establecimiento de una gua arquitectnica lo ms pronto, para disear y probar el sistema hecho de acuerdo a los requerimientos y a la arquitectura. El proceso describe qu entregables producir, cmo desarrollarlos y tambin provee patrones. El Proceso Unificado ha adoptado un enfoque que se caracteriza por: o Interaccin con el usuario contina desde un inicio. o Mitigacin de riesgos antes de que ocurran. o Liberaciones frecuentes. o Aseguramiento de la calidad. o Implicacin del equipo en todas las decisiones del proyecto. o Anticiparse al cambio de requerimientos.

Ventajas. y Iteraciones ofrecen como resultado un incremento del producto desarrollado que aade o mejora las funcionalidades del sistema en desarrollo. UML proporciona la tecnologa necesaria para apoyar la prctica de la ingeniera de software orientada a objetos. Desventajas. Las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas vara a lo largo del proyecto. UML no provee el marco de trabajo del proceso que gui a los equipos a la aplicacin de la tecnologa. No todas las tareas identificadas para un flujo de trabajo del PUD se realizan para cualquier proyecto de software. Fases del PUDS. 1) Fase de Inicio En esta fase se establece la oportunidad y alcance el proyecto. Se identifican todas las entidades externas con las que se trata (actores) y se define la interaccin en un alto nivel de abstraccin: se deben identificar todos los casos de uso, y se deben describir algunos en detalle. La oportunidad del negocio incluye: definir los criterios de xito, identificacin de riesgos, estimacin de recursos necesarios, y plan de las fases incluyendo hitos. 2) Fase de elaboracin Definir y validar una arquitectura estable. Se hace un refinamiento de la Visin del sistema, basndose en nueva informacin obtenida durante esta fase, se establece una slida comprensin de los casos de uso ms crticos que definen las decisiones arquitectnicas y de planificacin. Creacin de los planes de desarrollo detallados para las iteraciones de la fase de construccin. 3) Fase de construccin Gestin de los recursos, optimizacin y control de los procesos de construccin del software. Se completa el desarrollo de los componentes y/o subsistemas, probndolos contra un conjunto definido de criterios aprobados al inicio del proyecto. 4) Fase de transicin Ejecucin de los planes de implantacin. Se finalizan los manuales de usuario y mantenimiento. Pruebas del sistema en el entorno de explotacin. Creacin de una relase del sistema. Validacin del sistema por los usuarios. Ajuste fino del sistema segn la validacin con el usuario. Se facilita la transicin del sistema al personal de mantenimiento. Se pone el producto a disposicin del usuario final. 5) Fase de produccin Coincide con la actividad de despliegue del proceso genrico. Durante esta fase se monitorea el uso subsiguiente del software se proporciona el soporte para el ambiente operativo y evalan los informes de defectos y los requerimientos de cambio. Flujo de trabajo. Un flujo de trabajo es anlogo a un conjunto de tareas. Un flujo de trabajo identifica las tareas necesarias para completar una accin importante de ingeniera de software y los productos de trabajo que se producen como consecuencia de la realizacin exitosa de tareas, se debe destacar que no todas las tareas identificadas para un flujo de trabajo de un PUDS se realizan para cualquier proyecto de software. El equipo debe adaptar el proceso (acciones, tareas, subtareas y productos de trabajo) para satisfacer sus necesidades importantes.

y y y

Recursito Paralelo El modelo recursivo paralelo funciona de la siguiente forma:

 Realizar los anlisis suficientes para aislar las clases del problema y las conexiones mas importantes  Realizar un pequeo diseo para determinar si las clases y conexiones pueden ser implementadas de manera practica  Extraer objetos reutilizables de una biblioteca para construir un prototipo previo  Conducir algunas pruebas para descubrir errores en el prototipo  Obtener realimentacin del cliente sobre el prototipo  Modificar el modelo de anlisis basndose en lo que se ha aprendido del prototipo, de la realizacin del diseo y de la realimentacin obtenida del cliente  Refinar el diseo para acomodar sus cambios  Construir objetos especiales (no disponibles en la biblioteca)  Realizar pruebas para descubrir errores en el prototipo Este enfoque continua hasta que el prototipo evoluciona hacia una aplicacin en produccin. El progreso se produce iterativamente. Lo que hace diferente al modelo recursivo/paralelo es el reconocimiento de que: 1.-El modelo de anlisis y diseo para sistemas orientado a objetos no puede realizarse a un nivel uniforme de abstraccin. 2.-El anlisis y diseo pueden aplicarse a componentes independientes del sistema de manera concurrente. Primeras Iteraciones en anlisis/ diseo Planificacin Anlisis Diseo
Revisin y refinamiento
Anlisis Diseo

Anlisis

Diseo

Revisin y refinamiento
Planificacin Anlisis Diseo Extraer clases Prototipo Probar Evaluacin del cliente

Primer Prototipo

Revisin y refinamiento
Planificacin Anlisis Diseo Extraer clases Prototipo Probar Evaluacin del cliente

Siguiente incremento

Revisin y refinamiento
Planificacin Anlisis Diseo Extraer clases Prototipo Probar Evaluacin del cliente

N-simo incremento

WIN WIN. Concepto. El modelo en espiral WIN WIN 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: Identificacin del sistema o subsistemas clave de los directivos. Determinacin de las condiciones de victoria de los directivos.

o o

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 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. El modelo espiral de WinWin acenta ciclos de la elaboracin concurrente. Diseo.

Ventajas. El impacto que tiene esta tcnica entre otras es que con ella se puede realizar un desarrollo de Software ms rpidamente de acuerdo a las voluntades de cooperacin de los stakeholders (poseedores de apuestas). Se aplica en el anlisis de requerimientos, calendario, caractersticas, etc. Adems sirve para separar las personas del problema, enfocarse en los intereses. Desventajas. La dificultad de esta tcnica ocurre cuando entre los stakeholders ocurre Win-Lose esto conlleva a LoseLose (perder y perder).

El modelo DRA

Equipo # 1

Equipo # 2

Equipo # 3

Modelado Modelado Modelado de de Gestin de Gestin Gestin Modelado de Modelado Modelado Datos de de Datos Modelado de Datos Modelado Procesos Modelado de Procesos de Generacin de Aplicaciones Procesos Generacin de Generacin de Aplicaciones Pruebas y Volumen
De 60 a 90 das

Aplicaciones Pruebas y Volumen

Modelado de Gestin

El Modelo DRA consiste en un desarrollo rpido de aplicaciones basado en el modelo lineal secuencial, pero donde se enfatiza un ciclo de desarrollo extremadamente corto. Es una adaptacin a alta velocidad del modelo lineal secuencial en el que se logra desarrolla rpido utilizando una construccin basada en componentes. Si se comprende bien los requisitos el proyecto DRA permite al equipo de desarrollo crear un sistema completamente funcional tendr del periodo corto de tiempo por ejemplo 60 a 90 das el modelo DRA comprende las siguientes fases: Modelo de gestin.- se modela de forma que responda las siguientes preguntas 1) 2) 3) 4) 5) Que informacin conduce el proceso de gestin? Qu informacin se genera? Quien la genera? A donde va la informacin? Quien la procesa?

Estas preguntas son para describir requerimientos mas detallados.

Modelo de Datos.- responde a una serie de preguntas especficas importantes para cualquier informacin del procesamiento de datos. 1) cuales son los objetos de datos primarios que van a procesar el sistema? 2) cual es la composicin de cada objeto de datos y que atributos describe el objeto? 3) Donde reciben los objetos actualmente? 4) Cual es la relacin entre los objetos? Para responder estas preguntas los mtodos del modelado de datos hacen uso del diagrama de entidad relacin. Modelo de proceso.- los objetos de datos definidos en la fase de modelado de datos quedan trasformados para formar el flujo de informacin necesario para implementar una funcin de gestin. Las descripciones del proceso se crean para aadir, modificar, suprimir o recuperar un objeto de datos Generacin de Aplicaciones.- el DRA utiliza de tcnicas de cuarta generacin. En lugar de crear software con lenguaje de programacin de tercera generacin el proceso DRA trabaja para volver utilizar componentes de programas ya existentes. En todo el caso se utilizan para facilitar la construccin del software. Pruebas y Entrega.- del los componentes los programas que facilitan la construccin del software hace que el tiempo de prueba sea muy reducido al igual que todos los modelos de proceso el DRA tiene inconvenientes: 1) para proyectos grandes el DRA requiriere de recurso humanos suficientes. DRA requiere clientes y desarrolladores comprometidos en las rpidas actividades para completar un sistema en un marco de tiempo. LINEAL El modelo lineal secuencial es el paradigma ms antiguo y ms extensamente utilizado en la ingeniera del software. Desventajas  Los proyectos reales raras veces segn el modelo secuencial que propone el modelo aunque el modelo lineal puede acoplar iteracin, lo hace indirectamente. Como resultado los cambios pueden causar confusin cuando el equipo del proyecto comienza.  A menudo es difcil que el cliente exponga explcitamente todos los requisitos. El modelo lineal secuencial lo requiere y tiene dificultades a lo hora de acomodar la incertidumbre natural al comienzo de muchos proyectos.

 El cliente debe tener paciencia. Un grave error puede ser desastroso sino se detecta hasta que se revisa el programa.

Ing. Requerimientos Anlisis Diseo Codificacin Pruebas Mantenimiento

MODELO INCREMENTAL.

y y y y

Concepto. El modelo incremental combina elementos del modelo en cascada aplicado en forma iterativa. Aplica secuencias lneas de manera escalonada conforme avanza el tiempo, Cada secuencia lineal produce incrementos del software. La descripcin del sistema es esencial para especificar y confeccionar los distintos incrementos hasta llegar al Producto global y final. Las actividades concurrentes (Especificacin, Desarrollo y Validacin) sintetizan el desarrollo pormenorizado de los incrementos, que se har posteriormente. Bajo este modelo se entrega software por partes funcionales ms pequeas, pero reutilizables, llamadas incrementos. En general cada incremento se construye sobre aquel que ya fue entregado. El modelo permite una implementacin con refinamientos sucesivos (ampliacin y/o mejora). Con cada incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien se mejora la versin previamente implementada del producto software. Ventajas. Se enfoca en la entrega de un producto operacional con cada incremento. los primeros incrementos proporcionan al usuario la funcionalidad que necesita y una plataforma para evaluarlo. Es til sobre todo cuando el personal necesario para una implementacin completa no est disponible. Desventajas. No es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto ndice de riesgos.