CICLO DE VIDA DE DESARROLLO DE SOFTWARE MODELO ESPIRAL El Modelo en Espiral, Espiral, es un un modelo modelo de proceso de software evolutivo y construcción de prototipos sistemáticos del modelo lineal secuencial. Ideal para realizar versiones incrementales de manera rápida El software se desarrolla en una serie de versiones incrementales. Proporciona el potencial para el desarrollo rápido 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.
Planificación: Planificació n: determinación de objetivos, alternati alternativas vas y restricciones. Análisis de riesgo: análisis de alternativas alternati vas e identificación/resolución identifi cación/resolución de riesgos. Ingeniería: desarrollo del producto de ³siguiente nivel´ Evaluación del cliente: valoración de los resultados de la ingeniería
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 adaptación de un sistema operativo El paradigma de construcción de prototipos comienza con la recolección de requisitos. El desarrollador y el cliente cliente encuentran y definen los objetivos para que identifique identifi que los requisitos donde aparéese un diseño rápido lleva a la contracción del prototipo. El prototipo evalúa al cliente y usuario y se utiliza para refinar los requisitos de software a desarrollar desarroll ar , el el prototipo satisface al cliente al mismo mismo tiempo q el desarrollador comprende mejor lo que se necesita hacer al usuario le gusta el sistema real y a los desarrolladores desarroll adores les interesa construirlo rápido pero no sabes q les puede ocasionar problemas como ser:
El cliente no tiene conocimiento del prototipo lo que pide es que se haga rápido 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 rápido, y para ello utiliza herramientas inadecuadas como lenguajes de programación inadecuado.
MODELO DE CONSTRUCCIÓN DE PROTOTIPOS Ofrece su enfoque a través del paradigma de construcción 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 automáticamente el código fuente basándose. La ingeniería se orienta hacia la posibilidad de especificar el software usando lenguajes de notaciones graficas que describan el problema que hay que resolver en el término que el cliente los entienda.El cliente puede no estar seguro de lo que se necesite puede ser ambiguo en la especificación de hechos que le son conocidos y que puede que no sea capaz.Para aplicaciones pequeñas se puede ir directamente desde el paso de recolección de requisitos al paso de implementación usando el lenguaje de cuarta generación. La implementación mediante L4D permite al que desarrolla el software teniendo resultados deseados que es lo que se traduce automáticamente en código fuente.
Recolección de requerimientos
Estrategia de diseño
Implementació n usando T4G
Pr duct
Mantenimient
Concepto. El paradigma de T4G para la i ngeniería de software se orienta hacia la habilidad de especificar software a un nivel que sea más próximo al lenguaje natural o a una notación 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, código automático, etc. Se empieza con la recolección de requisitos. Para aplicaciones pequeñas se puede ir directamente al paso de implementación usando un lenguaje de cuarta generación no procedimental (L4G). Sin embargo es necesario invertir algo de esfuerzo en plantear una estrategia de diseño, ya que sin este tendríamos los mismos problemas de calidad y mantenimiento.
Ventajas.
y
y
y
El uso de T4G es un enfoque viable para muchas de las diferentes áreas de aplicación. Junto con las herramientas de la ingeniería de software asistida por computadora y los generadores de código, T4G ofrece una solución fiable a muchos problemas de software. La recolección de datos preliminares que acompañan al uso de T4G parece indicar que el tiempo requerido para producir software se reduce mucho para aplicaciones pequeñas de trabajo medio así como también la cantidad e análisis y diseño. Reducciones drásticas en el tiempo de desarrollo del software y una mejora significativa en la productividad de la gente que construye el software.
Desventajas. y
y y
Las T4G esta limitada a las aplicaciones de sistema de i nformación comercial, y de la obtención de informes en las grandes bases de datos. Las herramientas actuales de T4G no son mas fáciles de utilizar que los l enguajes de programación. El código fuente producido por tales herramientas es ³ineficiente´ y el mantenimiento de grandes sistemas de software desarrollados mediante T4G, es cuestionable.
PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE (PUDS). Concepto. El Proceso Unificado "es un proceso de desarrollo de software configurable que se adapta a trav és de los proyectos variados en tamaños y complejidad´. El Proceso Unificado guía a los equipos de proyecto en cómo 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 guía arquitectónica lo más pronto, para diseñar y probar el sistema hecho de acuerdo a los requerimientos y a la arquitectura. El proceso describe qué entregables producir, cómo desarrollarlos y también provee patrones. El Proceso Unificado ha adoptado un enfoque que se caracteriza por: Interacción con el usuario continúa desde un inicio. o o Mitigación de riesgos antes de que ocurran. Liberaciones frecuentes. o Aseguramiento de la calidad. o Implicación del equipo en todas las decisiones del proyecto. o Anticiparse al cambio de requerimientos. o
Ventajas. Iteraciones ofrecen como resultado un incremento del producto desarrollado que añade o mejora las funcionalidades del sistema en desarrollo. UML proporciona la tecnología necesaria para apoyar la práctica de la ingeniería de software orientada a objetos. y
y
Desventajas. y
y y
Las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas varía a lo l argo del proyecto. UML no provee el marco de trabajo del proceso que guié a los equipos a la aplicación de la tecnología. 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 defi ne la interacción en un alto nivel de abstracción: 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, identificación de riesgos, estimación de recursos necesarios, y plan de las fases incluyendo hitos.
2) Fase de elaboración
Definir y validar una arquitectura estable. Se hace un refinamiento de la Visión del sistema, basándose en nueva información obtenida durante esta fase, se establece una sólida comprensión de los casos de uso más críticos que definen las decisiones arquitectónicas y de planificación. Creación de los planes de desarrollo detallados para las iteraciones de la fase de construcción.
3) Fase de construcción
Gestión de los recursos, optimización y control de los procesos de construcción del software. Se completa el desarrollo de los componentes y/o subsistemas, probándolos contra un conjunto definido de criterios aprobados al inicio del proyecto.
4) Fase de transición
Ejecución de los planes de implantación. Se finalizan los manuales de usuario y mantenimiento. Pruebas del sistema en el entorno de explotación. Creación de una reléase del sistema. Validación del sistema por los usuarios. Ajuste fino del sistema según la validación con el usuario. Se facilita la transición del sistema al personal de mantenimiento. Se pone el producto a disposición del usuario final.
5) Fase de producción
Coincide con la actividad de despliegue del proceso genérico. Durante esta fase se monitorea el uso subsiguiente del software se proporciona el soporte para el ambiente operativo y evalúan los informes de defectos y los requerimientos de cambio.
Flujo de trabajo.
Un flujo de trabajo es análogo a un conjunto de tareas. Un flujo de trabajo identifica las tareas necesarias para completar una acción importante de ingeniería de software y los productos de trabajo que se producen como consecuencia de la realización 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. Recursito Paralelo
El modelo recursivo paralelo funciona de la siguiente forma:
Realizar los análisis suficientes para aislar las clases del problema y las co nexiones mas importantes Realizar un pequeño diseño para determinar si las clases y conexiones puede n ser implementadas de manera practica Extraer objetos reutilizables de una biblioteca para co nstruir un prototipo previo Conducir algunas pruebas para descubrir errores en el prototipo O btener realimentación del cliente sobre el prototipo Modificar el modelo de análisis basándose en lo que se ha aprendido del prototipo, de la realización del diseño y de la realimentación obtenida del cliente Refinar el diseño para acomodar sus cambios Construir objetos especiales (no disponibles en la biblioteca) Realizar pruebas para descubrir errores en e l prototipo Este enfoque continua hasta que el prototipo evoluciona hacia una aplicación en producción. El progreso se produce iterativamente. Lo que hace diferente al modelo recursivo/paralelo es el reconocimiento de que: 1.-El modelo de análisis y diseño para sistemas orientado a objetos no puede rea lizarse a un nivel uniforme de abstracción. 2.-El análisis y diseño pueden aplicarse a componentes independientes del sistema de manera concurrente. Planificación
Análisis
Primeras Iteraciones en análisis/ diseño
Diseño
Revisión y refinamiento Análisis
Diseño
Análisis
«
Diseño
Revisión y refinamiento Planificación
Análisis
Diseño
Extraer clases
Prototipo
Probar
Evaluación del cliente
Revisión y refinamiento Planificación
Análisis
Diseño
Extraer clases
Prototipo
Probar
Evaluación del cliente
Primer Prototipo
Siguiente incremento
«
Revisión y refinamiento Planificación
Análisis
Diseño
Extraer clases
Prototipo
Probar
Evaluación del cliente
N-ésimo incremento
WIN WIN. Concepto.
o o
El modelo en espiral WIN WIN de Boehm, define un conjunto de actividades de negociación al principio de casa paso alrededor de la espiral. Más que una simple actividad de comunicación con el cliente se definen las siguientes actividades: Identificación del sistema o subsistemas clave de los directivos. Determinación de las condiciones de victoria de los directivos.
o
Negociación 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 fijación que ayudan a establecer la completitud de un ciclo alrededor del espiral y proporcionan hitos de decisión antes de continuar el proyecto de software. El modelo espiral de WinWin acentúa ciclos de la elaboración concurrente.
Diseño.
Ventajas. y
y
El impacto que tiene esta técnica entre otras es que con ella se puede realizar un desarrollo de Software más rápidamente de acuerdo a las voluntades de cooperación de los stakeholders (poseedores de apuestas). Se aplica en el análisis de requerimientos, calendario, características, etc. Además sirve para separar las personas del problema, enfocarse en los intereses.
Desventajas. y
La dificultad de esta técnica ocurre cuando entre los stakeholders ocurre Win-Lose esto conlleva a LoseLose (perder y perder).
El modelo DRA
Equipo # 1
Equipo # 2
Modelado de Gestión
Modelado de
Equipo # 3 Modelado de Gestión
Modelado de
Modelado de Datos
Modelado de Datos Modelado de Procesos
Modelado de
Modelado de Procesos Generación de Aplicaciones
Generación de Aplicaciones Pruebas y Volumen
Generación de Aplicaciones Modelado de Gestión
Pruebas y Volumen De 60 a 90 días
El Modelo DRA consiste en un desarrollo rápido de aplicaciones basado en el modelo lineal secuencial, pero donde se enfatiza un ciclo de desarrollo extremadamente corto. Es una adaptación a alta velocidad del modelo lineal secuencial en el que se logra desarrolla rápido utilizando una construcción 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 días el modelo DRA comprende las siguientes fases: Modelo de gestión.- se modela de forma que responda las siguientes preguntas 1) 2) 3) 4) 5)
¿Que información conduce el proceso de gestión? ¿Qué información se genera? ¿Quien la genera? ¿A donde va la información? ¿Quien la procesa?
Estas preguntas son para describir requerimientos mas detallados.
Modelo de Datos.- responde a una serie de preguntas específicas importantes para cualquier información del procesamiento de datos. 1) ¿cuales son los objetos de datos primarios que van a procesar el sistema? 2) ¿cual es la composición de cada objeto de datos y que atributos describe el objeto? 3) ¿Donde reciben los objetos actualmente? 4) ¿Cual es la relación entre los objetos? Para responder estas preguntas los métodos del modelado de datos hacen uso del diagrama de entidad relación. Modelo de proceso.- los objetos de datos definidos en la fase de modelado de datos quedan trasformados para formar el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir o recuperar un objeto de datos Generación de Aplicaciones.- el DRA utiliza de técnicas de cuarta generación. En lugar de crear software con lenguaje de programación de tercera generación el proceso DRA trabaja para volver utilizar componentes de programas ya existentes. En todo el caso se utilizan para facilitar la construcción del software. Pruebas y Entrega.- del los componentes los programas que facilitan la construcción 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 rápidas actividades para completar un sistema en un marco de tiempo.
LINEAL El modelo lineal secuencial es el paradigma más antiguo y más extensamente utilizado en la ingeniería del software. Desventajas
Los proyectos reales raras veces según el modelo secuencial que propone el modelo aunque el modelo lineal puede acoplar iteración, lo hace indirectamente. Como resultado los cambios pueden causar confusión cuando el equipo del proyecto comienza.
A menudo es difícil que el cliente exponga explícitamente 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
Análisis Diseño Codificación
Pruebas Mantenimiento
MODELO INCREMENTAL.
Concepto. El modelo incremental combina elementos del modelo en cascada aplicado en forma iterativa. Aplica secuencias líneas de manera escalonada conforme avanza el tiempo, Cada secuencia lineal produce ³incrementos´ del software. La descripción del sistema es esencial para especificar y confeccionar los distintos incrementos hasta llegar al Producto global y final. Las actividades concurrentes (Especificación, Desarrollo y Validación) sintetizan el desarrollo pormenorizado de l os incrementos, que se hará posteriormente. Bajo este modelo se entrega software ³por partes funcionales más pequeñas´, pero reutilizables, llamadas incrementos. En general cada incremento se construye sobre aquel que ya f ue entregado. El modelo permite una implementación con refinamientos sucesivos (ampliación y/o mejora). Con cada incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien se mejora la versión previamente implementada del producto software.
Ventajas. y y
y
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 implementación completa no está disponible.
Desventajas. y
No es recomendable para casos de sistemas de ti empo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos.
