Documentación y Pruebas en Arquitectura de Software

Proceso Unificado de Desarrollo (UP)

• El UP es un proceso "marco" flexible y extensible, no un proceso universal.
• Permite diversas estrategias de desarrollo.
• Permite definir diferentes conjuntos de productos.
• Permite definir actividades y encargados de las mismas.

Componentes de un Método

• Elementos de modelado: Conjunto fundamental de conceptos de modelado para capturar el conocimiento semántico sobre un problema y su solución.
• Notación: Conjunto de vistas y notaciones para presentar la información de modelado subyacente, permitiendo a las personas examinarlos y modificarlos.
• Proceso: Formalización de las actividades relacionadas con la elaboración de sistemas software.
• Experiencia: Colección de reglas y heurísticas para llevar a cabo el desarrollo.

UML no es un Método

• UML es un lenguaje de modelado, no un método completo.
• Comprende: Lenguaje de modelado, proceso y personas/equipos/experiencia.
• UML es un estándar OMG.

¿Qué es un proceso?

• Describe un conjunto de actividades que deben realizarse en un orden específico para alcanzar un objetivo.
• Debe ser reproducible, definido, medible en cuanto a rendimiento y optimizable.
• Debe capturar las mejores prácticas para reducir el riesgo y hacer el proyecto predecible, logrando una visión y cultura comunes.

Dos elementos complementarios

• UML es un estándar OMG.
• El Proceso Unificado es un marco adaptable.
• El Proceso Unificado es un estándar en fase de propuesta.

Antecedentes del Proceso Unificado

• El proceso se basó en varios procesos unificados anteriores.
• El Rational Objectory Process fue un precursor, así como el Objeto Process.
• El Rational Unified Process 5.0 y luego el Unified Process de 1999.
• El estándar SPEM (2002) estuvo relacionado.

Características del Proceso Unificado

• Se guía por los casos de uso, desde la especificación hasta el mantenimiento.
• La arquitectura es fundamental desde el inicio hasta el final, facilitando el refinamiento progresivo de la misma.
• Es iterativo e incremental, dividiendo el trabajo en iteraciones pequeñas.
• Las iteraciones se enfocan en la importancia de los casos de uso y el análisis de riesgos.

Conducido por Casos de uso, Centrado en la Arquitectura

• Los casos de uso integran todas la actividades de software desde Requisitos a Pruebas.
• La arquitectura central describe los elementos fundamentales del sistema: subsistemas, dependencias, interfaces, colaboraciones y nodos.
• Incluye decisiones importantes: organización del sistema, comportamiento de los elementos estructurales, interfaces y subsistemas, así como el estilo de arquitectura que los guía.
• Se usan modelos 4+1 para visualizar y documentar la arquitectura.

Modelo de Arquitectura: 4+1 Vistas

• Los modelos son instrumentos para visualizar, especificar, construir y documentar la arquitectura del sistema.
• Cada vista es una parte de un modelo.
• Son las vistas lógica, de realización, de casos de uso, de procesos y de despliegue.

Arquitectura y Modelos

• La arquitectura incorpora una colección de vistas de los modelos.
• Presenta modelos de casos de uso, análisis, diseño, despliegue, implementación y pruebas.

Estructura y Función

• Los casos de uso especifican las funciones del sistema.
• La arquitectura especifica la estructura del sistema.
• Los casos de uso y la arquitectura deben estar equilibrados.

Proceso Iterativo e Incremental

• UP es un proceso iterativo, basado en la ampliación y refinamiento del sistema en mini-proyectos cortos (2 a 6 semanas).
• Cada iteración reproduce un ciclo de vida a menor escala, mejorando y haciendo crecer el sistema.
• El resultado de cada iteración es un sistema ejecutable.

Gestión del riesgo

• Evalúa el proyecto, la tecnología y los recursos para determinar y comprender el origen de los riesgos.
• Factores a considerar: comerciales, financieros y técnicos.
• Cada iteración se centra en los riesgos más importantes.

Las cuatro "P" (Personas, Proyecto, Producto, Proceso)

• Personas: Todos los interesados.
• Proyecto: Elemento organizacional para la gestión del desarrollo de software.
• Producto: Artefactos creados durante la vida del proyecto.
• Proceso: Conjunto completo de actividades para transformar requisitos en un producto.

Fases y Disciplinas

• Fases y puntos de control.
• Disciplinas (flujos de trabajo).
• Artefactos.

Elementos del Proceso Unificado

• Fases: división temporal del ciclo de vida, con puntos decontrol o hitos que marcan las etapas del proceso.
• Disciplinas: organizan las actividades fundamentales de gestión y desarrollo, pudiéndose solapar en tiempo.
• Artefactos: cualquier tipo de información producida por los desarrolladores (diagramas UML, código, ejecutables, casos de prueba).

Planificación Temporal del Proyecto

• UP propone ciclos de desarrollo con la separación clara entre las etapas de Ingeniería y Producción, divididos en fases e iteraciones.

Etapas y Fases del Ciclo de Vida

• Etapa de Ingeniería: equipos pequeños, actividades poco predecibles (análisis, viabilidad, planificación). Fases: Inicio y Elaboración.
• Etapa de Producción: equipos grandes, actividades predecibles, menos riesgos. Fases: construcción y transición.

Objetivos de las Fases

• Inicio (Inception): Definir el ámbito, objetivos, funcionalidades y arquitectura básica del proyecto y reducir los riesgos.
• Elaboracion: Estudiar en profundidad la funcionalidad y el dominio del problema, definir la arquitectura básica y planificar el proyecto con los recursos disponibles.
• Construcción: Desarrollar el producto con iteraciones incrementales.
• Transición: Liberar el producto, realizar tareas de instalación, configuración, entrenamiento y soporte.

Hitos

• Son puntos de control donde los participantes revisan el progres del proyecto.
• Se pretende sincronizar expectativas y realidad, identificar riesgos, y evaluar la situación global del proyecto.
• Se necesitan resultados y niveles de hitos principales al final de cada fase y hitos secundarios al final de cada iteración.

Disciplinas o Flujos de Trabajo

• Organizan las actividades de gestión y desarrollo del proyecto (requisitos, análisis, diseño, implementación, pruebas, gestión de proyecto, etc.).
• Las actividades no necesitan seguir un orden lineal.

Artefactos

• Cualquier tipo de información producida durante el desarrollo del proyecto (ej. Diagramas UML, código, ejecutables, casos de prueba).
• Se construyen de forma incremental.

Disciplinas y Modelos Principales

• Las disciplinas (Requisitos, Análisis, Diseño, Implementación, Pruebas) se asocian con modelos (casos de uso, análisis, despliegue, implementación y pruebas).

Modelo de Casos de Uso

• Diagramas de casos de uso, diagrama de clases, de componentes, de despliegue, de secuencia, de colaboración, de estados, de objetos, de actividades.

Modelos de Análisis y Diseño

• En detalle las relaciones entre modelos de análisis y diseño.

El "Caso de Desarrollo"

• El "Caso de desarrollo" es un artefacto inicial que especifica los artefactos necesarios en cada disciplina y fase.

La fase de Inicio (Inception)

• Responder preguntas sobre la visión del sistema, viabilidad, costos, fabricación y decisión de si continuar con el proyecto.
• Definir el alcance, objetivos, funcionalidad, arquitectura, riesgos y costo inicial.
• Establecer criterios de evaluación (planificación, ámbito del sistema, requisitos, arquitectura, riesgos, y análisis de negocio),

Objetivos de la fase de Inicio

• Desarrollar el análisis de negocio hasta el punto necesario para la puesta en marcha del proyecto.
• Delimitar el alcance y objetivos, definir funcionalidad y capacidades del producto.
• Tener una idea básica de la arquitectura.
• Reducir los riesgos, haciendo estimaciones de costes y agendamiento.

Criterios de Evaluación de la fase de Inicio

• Planificación provisional y criterios de evaluación para la fase de inicio.
• Fijar el ámbito, resolver incertidumbres en los requisitos, determinar arquitectura candidata, mitigar riesgos y evaluar el análisis de negocio.

Disciplinas en la fase de Inicio

• Enumerar requisitos iniciales, comprender el contexto, representar requisitos como casos de uso, recoger requisitos no funcionales.
• Análisis de la arquitectura y casos de uso.
• Esbozo de la arquitectura; prototipo desechable.

Artefactos de la fase de Inicio

• Descripción detallada de los artefactos importantes para la fase de Inicio: Visión, requisitos, modelo de casos de uso, glosario modelo inicial de dominio.etc

La fase de Elaboración

• Objetivos de la fase de Elaboración: Se centra en profundizar tanto en la funcionalidad como en el dominio del problema, definiendo una arquitectura básica y planificando el proyecto teniendo en cuenta los recursos disponibles.
• Criterios de Evaluación: se revisan los requisitos, la arquitectura e identifican posibles riesgos, se busca fijar precio y fecha de entrega.

Disciplinas en la fase de Elaboración

• Casos de uso, actores, prioridad de casos de uso, detalle de los casos de uso, estructura del modelo de casos de uso, prototipos de interfaces de usuario, Análisis de la arquitectura, Análisis de casos de uso, Diseño de arquitectura, Diseño de casos de uso, Implementación de arquitectura (parte del sistema), Integración(frameworks y servicios), Planificación y diseño de pruebas, pruebas de integración y de sistema.

Artefactos de la fase de Elaboración

• Modelos de casos de uso, modelo de dominio, modelo de análisis, modelo de diseño, arquitectura del sistema y modelo de pruebas, model de implementación; prototipos etc.

Las fases de Construcción y Transición

• La fase de Construcción es donde el producto se refina y construye.
• La fase de Transición es donde el producto se entrega al usuario.

Fase de Construcción

• Desarrollo a través de iteraciones involucrando análisis, diseño e implementación incremental de la arquitectura.
• Gran parte del trabajo se centra en programación y pruebas.
• Se documenta tanto el sistema como su manejo.
• Proporciona un producto construido junto con la documentación.

Disciplinas en la fase de Construcción

• Completar casos de uso y detalles, desarrollo de prototipos de interfaz de usuario, análisis de casos de uso añadidos, diseño de casos de uso añadidos, implementación de arquitectura, implementación de clase, subsistemas, realizar pruebas de unidad e integración.

Control en la fase de Construcción

• Labores de gestión adicional: control del análisis de negocio, evaluación de la fase de Construcción y planificación de la fase de Transición.

Artefactos de la fase de Construcción

• Modelos de casos de uso, modelos de análisis, diseño, pruebas, arquitectura del sistema, modelo de implementación. Descripción de los artefactos, como sistema ejecutable y manual de usuario.

Fase de Transición

• Liberación del producto para su uso real e integración.
• Tareas de instalación, configuración, entrenamiento y soporte al usuario.
• Incluye la evaluación del usuario tras la evaluación.
• Evaluación del proyecto y criterios a cumplir.

Disciplinas en la fase de Transición

• Para la transición se prepara una versión de pruebas de calidad, se instala la versión en los lugares deseados, se evalúan los resultados de las pruebas y se reaccionan a fallas o problemas. Importante es el análisis del negocio.

Este cuestionario explora la importancia de la documentación y las pruebas de integración en la arquitectura de sistemas y el desarrollo de software. Analiza el ciclo de vida del software, la gestión de proyectos en construcción y la transición de proyectos, proporcionando un enfoque sobre la calidad y migración de datos. Ideal para entender procesos iterativos e incrementales en la gestión de proyectos de software.