El Rol del Análisis en el Desarrollo de Software: Un Enfoque Iterativo
¿Por qué el Análisis no es Diseño ni Implementación?
El diseño y la implementación se enfocan en dar forma al sistema para que cumpla con los requisitos funcionales y no funcionales. Antes de iniciar estas etapas, es crucial tener una comprensión precisa y detallada de los requisitos. El análisis juega un papel fundamental en este proceso.
Opciones para Incluir el Workflow de Análisis en el Ciclo de Vida Iterativo e Incremental del PUD:
- Hacer y mantener: Se utiliza el modelo de análisis para describir los resultados del análisis y se mantiene su consistencia a lo largo del ciclo de vida del software.
- Hacer y no mantener: Se utiliza el modelo de análisis como herramienta transitoria e intermedia, dejando de actualizarlo cuando el diseño y la implementación están en marcha durante la fase de construcción.
- No hacer: No se utiliza el modelo de análisis, y se analizan los requisitos como parte integrada en la captura de requisitos o en el diseño.
La segunda opción suele ser la más utilizada, ya que el análisis se centra en la fase de elaboración.
Artefactos del Análisis
Modelo de Análisis
Es el sistema de análisis que representa el paquete de más alto nivel del modelo. Es el artefacto principal del análisis y se utiliza para describir los requisitos funcionales y no funcionales del sistema.
Clases de Análisis
Son las clases fundamentales del análisis, que representan una abstracción de las clases y se utilizan para describir los objetos del sistema.
- Clases de entidad: Modelan información persistente con una vida larga.
- Clases de interfaz: Modelan la interacción entre el sistema y sus actores, representando abstracciones de ventanas, formularios, interfaces de comunicación, etc.
- Clases de control: Modelan funcionalidad que opera sobre varios objetos de entidad, realizando cálculos y retornando el resultado al objeto de boundary.
Realización de Casos de Uso de Análisis
Es el artefacto principal del modelo de análisis, donde se describen los casos de uso mediante clases de análisis y sus objetos.
Paquete de Análisis
Se utiliza para organizar los elementos de modelado. Permite descomponer el modelo de análisis en paquetes de análisis y sus dependencias (subsistemas).
Descripción de la Arquitectura
Se utiliza para representar la arquitectura del sistema y se encuentra en la vista de la arquitectura del modelo de casos de uso. Se toman todas las relaciones de casos de uso de análisis relevantes para la arquitectura.
Roles en el Análisis
Arquitecto
Responsable de la integridad del modelo de análisis (artefacto: arquitectura).
Ingeniero de Casos de Uso
Responsable de la integridad de una o más realizaciones de caso de uso, garantizando que cumplen los requisitos.
Ingeniero de Componentes
Responsable de las clases de análisis.
Arquitectura
La arquitectura de un sistema comprende las decisiones significativas que se toman para cumplir con los requisitos funcionales y no funcionales. Define cómo se satisfacen los requisitos y abarca la estructura, el comportamiento, el uso, la funcionalidad, el rendimiento, la adaptabilidad, las restricciones económicas y tecnológicas, entre otros aspectos. Se puede describir mejor a través de cinco vistas interrelacionadas.
Vistas
Cada vista es una proyección de la organización y estructura del sistema, centrada en un aspecto particular del mismo.
Workflow de Análisis
El Análisis
El lenguaje utilizado en el análisis se basa en un modelo de objetos conceptual llamado modelo de análisis. Este modelo ayuda a refinar los requisitos, razonar sobre los aspectos internos del sistema, estructurar los requisitos y proporciona una estructura centrada en el mantenimiento, la flexibilidad ante los cambios y la reutilización. El modelo de análisis se considera una primera aproximación al modelo de diseño, aunque es un modelo independiente.
El Papel del Workflow de Análisis en el PUD
El workflow de análisis en el PUD contribuye a la planificación de los incrementos en la fase de inicio y en la fase de elaboración y construcción, ayuda a obtener una estructura robusta y estable y facilita una comprensión más profunda de los requerimientos. Según el PUD, el workflow de análisis tiene su pico de actuación en las iteraciones de la fase de elaboración, donde se busca una estructura robusta y sostenible y una arquitectura estable para el producto. El foco de análisis está centrado en las primeras iteraciones de las fases de elaboración.
Opciones para la Inclusión del Workflow de Análisis en el Ciclo de Vida Iterativo e Incremental del PUD:
- Hacer y mantener: Se utiliza el modelo de análisis para describir los resultados del análisis y se mantiene su consistencia a lo largo del ciclo de vida del software.
- Hacer y no mantener: Se utiliza el modelo de análisis como herramienta transitoria e intermedia, dejando de actualizarlo cuando el diseño y la implementación están en marcha durante la fase de construcción.
- No hacer: No se utiliza el modelo de análisis, y se analizan los requisitos como parte integrada en la captura de requisitos o en el diseño.
La segunda opción suele ser la más utilizada, ya que el análisis se centra en la fase de elaboración.
Patrones GRASP
Los patrones GRASP son un conjunto de patrones de diseño que ayudan a decidir en qué clase de un modelo es más conveniente asignar una determinada responsabilidad.
Experto en Información
Sugiere que una clase debe ser responsable de una tarea si tiene la información necesaria para llevarla a cabo.
Creador
Sugiere que una clase debe ser responsable de crear instancias de otra clase si tiene la información necesaria para hacerlo.
Alta Cohesión
Sugiere que una clase debe tener una única responsabilidad bien definida y que todas sus operaciones deben estar relacionadas con esa responsabilidad.
Bajo Acoplamiento
Sugiere que las clases deben tener una relación débil entre sí, es decir, que los cambios en una clase no deben afectar a otras clases.