Modelos de Proceso Tradicionales

Modelos de Proceso Tradicionales Capitulo 2,QJHQLHUtDGHO6RIWZDUH (VSHFLDOL]DFLyQHQ*HUHQFLDGH6LVWHPDVGH,QIRUPDFLyQ 8QLYHUVLGDG6DQWLDJRGH&DOL Profesor: MSc. MIGUEL ANGEL NIÑO ZAMBRANO Programación: Tiempo Tópico 90 minutos Diapositivas y ejemplos 30 minutos Taller 120 minutos Total

Contenido Modelos de Proceso de Software Tradicionales { CVC (Ciclo de Vida Clásico) { Construcción de Prototipos { RAD (Rapid Application Development) { Modelos Iterativos Incremental Espiral INTRODUCCION Aunque la denominación de modelos tradicionales rece sobre todo en el modelo de Ciclo de Vida Clásico, esto no quiere decir que éstos modelos estén mandados a recoger, sino que su utilización ha sido extensa y ya comprobada por muchas personas. En este capitulo se pretende analizar las principales características de los modelos y establecer cuando es importante su uso y cuando no. Esto permitirá al gestor de proyectos seleccionar el mejor modelo de desarrollo de software dependiendo de las característica del sistema de información, las personas, los recursos con los que se cuenta. 2

Ciclo del Vida Clásico (CVC) Ventajas * Es importante cuando se necesitan interconectar al sistema de información otros elementos de la empresa como hardware, persona y bases de datos. * Extensamente utilizado. Desventajas * Proyectos reales no siguen el modelo tal Como esta planteado, con problemas de Interacción entre los desarrolladores. * El Cliente no expone los requisitos en la * Primera fase. * El cliente debe tener paciencia. CICLO DE VIDA CLASICO (Royce 1970) También se le conoce como modelo lineal secuencia o modelo en cascada. Plantea un enfoque sistemático, secuencial para el desarrollo de software, que comienza en un nivel de sistemas y continúa con el análisis, diseño, codificación, pruebas y mantenimiento. Este modelo comprende una primera actividad como lo es La Ingeniería y modelado de sistemas / información, en el cual se establece el sistema de nivel superior y se deben establecer los requisitos de la empresa en la que se encuentra. Los requisitos se recogen del sistema con una pequeña parte de análisis y diseño. El análisis es un proceso de reunión de requisitos centrado en la información que manejaran los programas a construir. El diseño es un proceso de varios pasos de definición de estructuras de datos, arquitectura del software, representaciones de la interfaz y detalle procedimiental. La generación de código debe ser una representación del diseño pero que entienda la máquina, se puede apoyar en herramientas CASE para ello. Una vez generado el código comienzan las pruebas del programa, se centra en validaciones y funcionalidad. Finalmente el mantenimiento vuelve aplicar los fases anteriores para realizar el mismo. 3

Construcción de Prototipos Ventajas Una aplicación que funciona. Aclarar Requisitos. Se crean con rapidez. Evolucionan (Proc. Iterativo). Costo bajo de desarrollo. *El Cliente ve una versión de trabajo del software el cual cree es la aplicación Final a utilizar. *El desarrollador se compromete con HW o SW para crear el prototipo rápidamente y éstos deben ser evaluados. Desventajas CONSTRUCCION DE PROTOTIPOS Este paradigma se inicia con la recolección de requerimientos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es obligatoria más definición. Luego aparece un diseño rápido. El diseño rápido está centrado en una representación de los aspectos del software que serán visibles para el usuario-cliente. El diseño rápido lleva a la construcción de un prototipo. El prototipo lo evalúa el cliente-usuario y lo utiliza para refinar los requisitos del software a desarrollar. La interacción ocurre cuando el prototipo satisface las necesidades del cliente, a la vez que permite que el desarrollador comprenda mejor lo que se necesita hacer. Cuando utilizar prototipos? Cuando el cliente tiene una necesidad legítima, pero está desorientado sobre los detalles, el primer paso es desarrollar un prototipo. Cuando no se conocen los requerimientos. Cuando los requerimientos necesiten evaluarse. Costos Altos Alto Riesgo Nueva Tecnología Que hacer con el prototipo una vez evaluado por el cliente? Abandonar la Aplicación Implantar la Aplicación. (raras veces) Volver a Desarrollar la Aplicación (Aconsejado) Comenzar un Nuevo Prototipo La clave para que funcione adecuadamente este modelo es definir reglas de juego claras entre los desarrolladores y los usuarios, dividiendo responsabilidades y funciones detalladas. 4

Desarrollo Rápido de Aplicaciones (DRA) Cada equipo de desarrollo maneja el mismo conjunto de pasos. Desventajas Ventajas * Desarrollo completo de una Aplicación en poco tiempo. Para proyectos grandes el DRA requiere recursos humanos suficientes. Requiere clientes y desarrolladores comprometidos con las actividades rápidas. No Todas las aplicaciones son candidatas a utilizar DRA. No es Adecuado en altos riesgos. EL MODELO DRA El Desarrollo Rápido de Aplicaciones (DRA) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. El modelo DRA es una adaptación a alta velocidad del modelo lineal secuencial en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el DRA permite al equipo de desarrollo implementar un Sistema completamente funcional, dentro de periódos cortos tiempo (Ej. 60 a 90 días). Las etapas son: El modelado de Gestión se modela respondiendo a: Qué información conduce el modelo de gestión?, Qué información se genera?, Quién la genera?, A dónde va la información?, Quién la procesa?. El modelado de Datos refina la información determinada en el paso anterior con la definición de un conjunto de objetos de datos con metodologías propias para tal fin. El modelado del proceso define funciones de gestión (insertar, borrar, modificar, recuperar) que utilizan el modelo de datos definido para procesar la información. La generación de la aplicación debe realizarse con herramientas de cuarta generación con herramientas que automatizan la creación de componentes y su reutilización. Finalmente la etapa de pruebas y entrega se supone es corta por la reutilización de software ya existente y correcto. Cuándo utilizar el DRA? Si una aplicación de gestión puede modularse de forma que permita completarse cada una de las funciones principales en menos de tres meses. 5

Modelo Incremental Desventajas El sistema debe permitir establecer adecuadamente los incrementos a desarrollar. Ventajas * Desarrollo completo de una aplicación con entregas funcionales que satisfacen al usuario. MODELOS EVOLUTIVOS MODELO INCREMENTAL El software al igual que todos los sistemas complejos, evoluciona con el tiempo. Los requisitos de gestión y de productos a menudo cambian conforme a que el desarrollo proceda haciendo que el camino que lleva al producto final no sea real; las estrictas fechas tope del mercado hacen que no sea posible finalizar un producto completo, por lo que se debe introducir una versión limitada para cumplir la presión competitiva y de gestión; se comprende perfectamente el conjunto de requisitos de productos centrales o del sistema, pero todavía se tienen que definir los detalles de extensiones del producto o sistema. En estas y en otras situaciones similares, los ingenieros del software necesitan un modelo de proceso que se haya diseñado explícitamente para acomodarse a un producto que evolucione con el tiempo. Modelo Incremental Combina elementos del modelo lineal secuencial con la filosofía interactiva de construcción de prototipos. Aplica secuencias lineales de forma escalonada mientras progresa el tiempo. Cada secuencia lineal produce un incremento el cual es funcional y utilizable. La diferencia de este modelo al de prototipos es que se centra en la entrega de un producto operacional con cada incremento. Cuándo utilizar el desarrollo Incremental? Cuando la dotación de personal no está disponible para una implementación completa en una fecha límite que se halla establecido para el proyecto. Los primeros incrementos generalmente tienen menos personas. 6

Modelo Espiral Regiones de Tareas Ventajas Ideal para proyectos Grandes. Adaptable a las necesidades. Desventajas Credibilidad del Cliente en cuanto su control. Habilidades de Evaluación del Riesgo. Poco usado Fuente: Boehm (1988) MODELOS EVOLUTIVOS MODELO EXPIRAL Es un modelo que acompaña la naturaleza interactiva de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software. En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones, la versión incremental podría ser un modelo en papel o un prototipo. Durante las ultimas iteraciones, se producen versiones cada vez más completas de la ingeniería del sistema El modelo se divide en cuatro cuadrantes que representan las actividades principales para el ciclo de vida de desarrollo de software, resumidos por Pressman (1995) en: Planeamiento. Análisis de riegos. Ingeniería. Evaluación del cliente. De acuerdo con Boehm (1988, p. 65) el ciclo de vida propuesto por el modelo se basa en cuatro preguntas fundamentales: Cómo empieza la espiral? Cómo uno rompe los ciclos de la espiral cuando es apropiado terminar un proyecto apenas iniciado? Por qué la espiral se acaba bruscamente? Qué pasa con la mejora (o el mantenimiento) del software? Debido a la reducción de riesgos determinada por el método evolutivo del modelo, éste representa un enfoque más apropiado para el desarrollo de grandes, complejos y ambiciosos sistemas de información. Además, el modelo espiral posee un nivel alto de capacidades de entorno de soporte de software y es Àexible, lo que permite acomodar diversas alternativas técnicas y objetivos de usuario. 7

Ejemplo Modelo Espiral WINWIN EL MODELO ESPIRAL WINWIN (Boehm 1998) Las mejores negociaciones se esfuerzan en obtener victotia / victoria. Esto es cliente gana obteniendo el producto o sistema que satisface la mayor parte de sus necesidades y el desaroolador gana para conseguir presupuestos y lograr una fecha de entrega realista. El modelo WINWIN define un conjunto de actividades de negociación al principio de cada 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 claves de los directivos. Determinación de las condiciones de victoria de los directivos. Negociación de las condiciones de victoria de los directivos para reunirla en un conjunto de condiciones victoria victoria para todos los afectados (incluyendo el equipo de desarrollo). Conseguido el paso anterior se logra una inicio con victoria victoria, elemento clave para desarrollar el resto de actividades de los demás sectores. Además este modelo incluye tres hitos llamados puntos de fijación que ayudan a establecer la completitud de un ciclo alrededor de la espiral y proporcionan hitos de decisión antes de continuar con el proyecto de software. Estos puntos son: OCV Objetivos de Ciclo de Vida: Conjunto de Objetivos para cada actividad principal. ACV Arquitectura del Ciclo de Vida.: Arquitectura que se deb implementar COI Capacidad Operativa Inicial: Preparación del software para la instalación / distribución 8

Otros Modelos de desarrollo de software Modelo de desarrollo concurrente. Desarrollo Basado en Componentes. El modelo de Métodos Formales. Técnicas de Cuarta Generación T4G. OTROS MODELOS DE DAROLLO DE SOFTWARE El modelo de desarrollo concurrente es un intento por tener control total del desarrollo del proyecto, definiendo estados y actividades que dependen de esos estados, disparando eventos específicos de acuerdo las decisiones tomadas. El desarrollo basado en componentes se propiciaron con el desarrollo de las tecnologías orientadas a objetos. Este modelo incorpora muchas de las características del modelo espiral. Es evolutivo por naturaleza y exige un enfoque iterativo para la creación de software, las principales etapas son: Identificar componentes candidatos, Buscar componentes en las bibliotecas, Extraer componentes si están disponibles, Construir componentes si no existen, Colocarlos en la biblioteca y construir la iteración del sistema. Según estudios de reutilización, QSM Associates, INC. Informa que el ensamblaje de componentes lleva a una reducción del 70 por 100 de tiempo del ciclo de desarrollo, un 84 por 100 del coste del proyecto y un índice de productividad del 26.2. El Proceso unificado de desarrollo de software UP, representa un número de modelos desarrollados basados en componentes que han sido propuestos en la industria. Utilizando el Lenguaje de Modelado Unificado UML, definirá los componentes utilizados para construir el sistema y las interfases que conectarán los componentes. Utilizando una combinación del desarrollo incremental e iterativo. El modelo de métodos formales comprende un conjunto de actividades que conducen a la especificación matemática del software de computadora. Permiten que un ingeniero de software especifique, desarrolle y verifique un sistema basado en computadora aplicando una notación rigurosa y matemática. (Ingeniería del Software de Sala limpia). 9

Preguntas y Ejercicios de Repaso Qué paradigma de ingeniería del software de los presentados en este capitulo piensa es más eficaz? Proporcione cinco ejemplos de proyectos de desarrollo en los cuales sea adecuado el desarrollo por prototipos. Investigue las herramientas CASE existentes que soportan DRA. Qué es más importante, el producto o el proceso? Bibliografía Pressman, Roger. Ingeniería del Software un enfoque Práctico. Quinta Edición. Mc Graw Hill. 2000. Senn, James A. Diseño de Sistemas de. Segunda Edición. Mc Graw Hill. 1998. Capitulo 5. Material De profundización Lectura Producto y Proceso. Ensayo Margaret Davis. 10