Download
1 / 23
E N D
El proceso es el conocimiento incorporado, y puesto que el conocimiento esta inicialmente disperso, el desarrollo de software implícito, latente e incompleto en gran medida es un proceso social de aprendizaje. El proceso es un dialogo en el que se reúne el conocimiento y se incluye en el software para convertirse en software. El proceso proporciona una iteración entre los usuarios y los diseñadores, entre los usuarios y las herramientas de desarrollo, y entre los diseñadores y las herramientas de desarrollo (tecnología). Es un proceso interactivo donde la herramienta de desarrollo se usa como medio de comunicación, con cada iteración del dialogo se obtiene mayor conocimiento. Howard Baetjer
Desde un punto de vista técnico se puede decir que el proceso de software es un marco de trabajo de las tareas que se requieren para construir software de alta calidad
Modelo de Cascada (Bennington 1956, Modificado por Royce en 1970, Pressman lo presenta como ciclo de vida clásico). Se denomina modelo en cascada porque su característica principal es que no se comienza con un paso hasta que no se ha terminado el anterior.
Es el más antiguo de todos los modelos de Ingeniería del Software. El modelo lineal presenta una estructura secuencial (de ahí el nombre de Modelo en cascada) formada por seis fases o etapas: - Análisis del Sistema - Análisis de Requisitos de Software - Diseño - Codificación - Prueba - Mantenimiento
Desventajas • Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay iteraciones y se crean problemas en la aplicación del paradigma. • Normalmente, es difícil para el cliente establecer explícitamente al principio todos los requisitos. El ciclo de vida clásico lo requiere y tiene dificultades en acomodar posibles incertidumbres que pueden existir al comienzo de muchos productos. • El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estará disponible una versión operativa del programa. Un error importante no detectado hasta que el programa este funcionando puede ser desastroso.
El modelo espiral propuesto originalmente por Boehm en 1988, es un modelo de proceso de software evolutivo ha sido desarrollado para cubrir las mejores características tanto del ciclo de vida clásico, como de la creación de prototipos, añadiendo al mismo tiempo un nuevo elemento: el análisis de riesgo
Este modelo, también no secuencial, es algo más complejo que los anteriores, aunque incluye un elemento muy útil e importante en el desarrollo del software: análisis de riesgos. El modelo en espiral concreta cuatro fases: - Planificación - Análisis de Riesgos - Ingeniería (Construcción del prototipo) - Evaluación por el cliente
Con cada iteración alrededor de la espiral (comenzando en el centro y siguiendo hacia el exterior), se construyen sucesivas versiones del software, cada vez más completas y, al final, el propio sistema operacional
El modelo incremental aplica secuencias lineales de forma escalonada mientras avanza el tiempo. Corrige la necesidad de una secuencia no lineal de pasos de desarrollo.
El funcionamiento es sencillo. Comienza con el análisis de los requisitos, tras el cual se prepara un primer diseño. La novedad de este modelo respecto del anterior, es la introducción de iteraciones para “bifurcar” diseños. Es decir, este modelo ofrece la posibilidad de comenzar un diseño, arquitectura, estructura, etc del software, que de no convencer al cliente (o al propio programador) es rechazado y se comienza con una segunda iteración (o un segundo diseño), sin necesidad de realizar un nuevo análisis de requisitos. Pueden realizarse tantas iteraciones (también llamadas incrementos) como sean necesarias.
Es un modelo complejo con mucha terminología propia, pensado principalmente para el desarrollo de grandes proyectos. Es un proceso que puede adaptarse y extenderse en función de las necesidades de cada empresa.Es el resultado de esfuerzo de las tres últimas décadas en desarrollo de software y de la experiencia de sus creadores Ivar Jacobson, Grady Booch y James Rumbaugh.
Características del Proceso Unificado de Desarrollo 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 Unificado está basado en componentes, lo cual quiere decir que el sistema software en construcción está formado por componentes de software interconectados a través de interfaces bien definidas. Además, el Proceso Unificado utiliza el UML para expresar gráficamente todos los esquemas de un sistema de software. Pero, realmente, las características que definen este Proceso Unificado son tres: Iterativo e Incremental, Dirigido por casos de uso y Centrado en la Arquitectura.
Inicio Elaboración Construcción Transición Tiempo Visión Arquitectura Capacidad inicial Edición del producto Figura 4.3 Fases del Ciclo de Vida Ivar Jacobson, “Applying UML in The Unified Process” [En linea], [Consulta:Enero de 2006], <http://www.jeckle.de/files/uniproc.pdf> Fases Cada ciclo consta de cuatro fases: inicio, elaboración, construcción, y transición: • Inicio: Definición del proyecto. • Elaboración: Planificación del proyecto, especificación de características y elaborar arquitectura base. • Construcción: Construcción del sistema. • Transición: Transición a usuarios
Inicio Elaboración Construcción Transición Tiempo Iteración Preliminar … Iteración Arquitectura … Iteración Desarrollo Iteración Desarrollo … Iteración Transición … Visión Arquitectura Capacidad inicial Edición del producto Figura 4.4 Iteraciones y fases Ivar Jacobson, “Applying UML in The Unified Process” [En linea], [Consulta:Enero de 2006], <http://www.jeckle.de/files/uniproc.pdf> Iteraciones dentro del ciclo de vida. Cada fase se subdivide en iteraciones. En cada iteración se desarrolla en secuencia un conjunto de disciplinas o flujos de trabajos.
