Ingeniera de Software Universidad del Aconcagua El Proceso

Ingeniería de Software Universidad del Aconcagua El Proceso Unificado de Desarrollo

Antecedentes Proceso estructurado l l l Mediados –fines de los 80 Basados en conceptos de programación estructurada – descomposición funcional Ciclo de vida en cascada a veces prototipos Código estructurado (fc, procedimientos)

Métodos orientados a objetos El gran objetivo inicial (referido al proceso) era usar modelos similares para las distintas etapas Análisis: clases Diseño: clases Implementación: clases En la práctica, sigue existiendo el problema de llevar los requerimientos iniciales, normalmente expresados funcionalmente (casos de uso, escenarios) a objetos que colaboran

El UML l Hacia principios de los 90, coexistían distintas notaciones y enfoques para modelado de objetos l Tres de los autores principales (Booch, Jacobson, Rumaugh) decidieron intentar estandarizar las notaciones l Así surgió el UML, un estándar de modelado que combina modelos nuevos y existentes, e intenta cubrir todas las necesidades de especificación de un sistema de software l UML no es una metodología ni un proceso, es una notación estándar de modelado para capturar el conocimiento semántico de un problema y su solución

UML: no es un proceso l l l Proceso: descripción de actividades que deben realizarse en un determinado orden (en este caso para crear o modificar un sistema de software). Describen qué hacer, cómo hacerlo, cuándo hacerlo, qué roles deben hacer lo y el motivo por el que se hace. Debe ser: reproducible, definido, medible y mejorable UP no es exactamente un proceso, es un marco adaptable (“process framework”)

Antecedentes

Características de UP l Es un proceso “marco” (process framework) l l Está dirigido por casos de uso l l Prioritaria de principio al fin. Se facilita su refinamiento progresivo. Es iterativo e incremental l l Presentes en todas las fases Se centra en la arquitectura l l Se puede adaptar a las características de un proyecto Los riesgos guían la construcción Casos de uso: Funciones. Arquitectura: estructura.

Mejores prácticas de UP l Desarrollar iterativamente l Administrar los requerimientos l Usar arquitecturas de componentes l Modelar visualmente (UML) l Verificar la calidad l Controlar los cambios

UP: Iterativo incremental l El resultado de cada iteración es un sistema funcionando l Hay aprendizaje entre iteraciones l Time boxing (2 -12 semanas). Si no se llega, se recorta funcionalidad l Se busca el feedback del usuario l Los riesgos guían la elección de funcionalidad

Fases del UP l Inicio del proyecto (“inception”) l l Construcción l Definir contexto, factibilidad y objetivos Elaboración l l Funcionalidad (alcance) y arquitectura básica l Desarrollar el producto iterativamente Transición l Liberar el producto para uso rea ETAPAS: INGENIERIA CONSTRUCCION

Hitos del UP l Puntos de control para revisar el avance l l Sincronizar expectativas Identificar riesgos l Tienen entregables asociados para la evaluación l Dos tipos de hitos l l Principales al finalizar una fase (visión, arquitectura básica, capacidad inicial, producto final) Secundarios al finalizar una iteración

Disciplinas y artefactos l Disciplinas: organizan las actividades del proyecto l l De desarrollo: requerimientos, análisis, arquitectura, diseño, implementación, pruebas, deployment. De gestión: administración de riesgos, planificación y seguimiento, SCM (software configuration management), etc. l Cada disciplina de desarrollo genera modelos de UML (casos de uso, análisis, diseño, deployment, etc. ). Los modelos incluyen diagramas. l Artefactos: Cualquier tipo de información generada por el equipo de desarrollo

Especificación del proceso l El proceso está especificado en términos de Workers, Activities, Artifacts. Ejemplo de workflow:

Visión del proceso

El “caso de desarrollo” l l l El número de distintos artefactos a generar es muy grande Es preciso definir cuáles se harán en un desarrollo concreto Uno de los artefactos iniciales es el “Caso del desarrollo” l l l Qué artefacto es necesario en cada disciplina En qué fase se crea En qué fases se actualiza

La fase Inicial l Propósito l l l Establecer el “caso de negocio” para un sistema nuevo o mejoras a uno existente Especificar el alcance del proyecto Salidas l l Visión de los requerimientos (10 -20%) Caso de negocio l l Criterios de éxito Evaluación inicial de riesgos Estimación de recursos requeridos Hito: “Lifecycle objectives”

Principales artefactos de la fase Inicial l l Visión: ¿Para qué queremos este sistema? Modelo de casos de Uso Atributos de calidad Glosario Modelo del dominio Modelo de análisis Modelo de diseño Prototipos Plan de desarrollo / plan de riesgos “Development case”

La fase de Elaboración l Propósito l l l Analizar el dominio del problema Establecer una base sólida de arquitectura Atacar principales riesgos Desarrollar un plan “completo” Salidas l l Modelo de dominio y casos de uso (80% completo) Arquitectura probada y documentada Caso de negocio revisado Plan de desarrollo

Criterios de evaluación de la fase de Elaboración l ¿Se identificaron los requerimientos? ¿Están suficientemente detallados? l ¿La arquitectura satisface los requerimientos? ¿Es robusta? l ¿Se eliminaron los riesgos críticos? l ¿Se puede fijar un precio y una fecha de entrega?

Principales artefactos de la fase de Elaboración l Modelo de casos de Uso (la mayoría) l Modelo del dominio l Modelo de análisis l Modelo de diseño –Arquitectura del sistema l Modelo de pruebas l Modelo de implementación l Prototipos de interfaz de usuario

Fases de Construcción y Transición l En construcción se especifica, desarrolla y prueba el producto de manera incremental l En transición se llevan a cabo todas las tareas necesarias para una salida a producción: instalación, configuración, entrenamiento, soporte, mantenimiento, etc. No se deben confundir las iteraciones de Transición con los ciclos de pruebas

Sobre el uso de UP l Las iteraciones no son estrictamente secuenciales. Las disciplinas se superponen l Algunos templates de RUP no son muy prácticos, hay que adaptarlos l Cuando usar UP