Casos de uso, arquitectura y fases de desarrollo de software

Casos de uso

*Casos de uso: Funcionalidad ofrecida por el sistema a sus usuarios (actores). Despliegue: Arquitectura física del sistema. Clases: Clases, interfaces y relaciones para generar el modelo de dominio con los conceptos del problema a abordar y sus relaciones. Secuencia: Intercambio de mensajes entre objetos para documentar los escenarios de un caso de uso mediante un diagrama de secuencia de nivel de sistema (SSD). Actividad: Flujo de control entre actividades en una máquina de estado para modelar el flujo de trabajo con solicitudes. Estados: Máquina de estados y las transiciones entre ellos para modelar la navegación del sitio web. Paquetes: Organización lógica de distintos elementos para modelar la arquitectura lógica del sistema. *PB: Lista priorizada de características del sistema (historias de usuario, requisitos no funcionales, solicitudes de cambio o mejora) que el equipo de desarrollo tiene pendiente de implementar. PO: Responsable del PB en representación de todos los stakeholders, incluyendo el propio equipo de desarrollo. Grooming: Actividad en la que el PO es responsable de definir, refinar, estimar y priorizar de forma dinámica el PB. SB: Lista de características del PB a desarrollar por el equipo en un Sprint, descompuesta en las tareas técnicas necesarias para llevar a cabo la implementación y una estimación de esfuerzo. Burndown chart: Cuadro, diagrama para trazar el esfuerzo SB. Actualización diaria por el SM. Sandbox: Extensión del PB donde stakeholders pueden proponer historias de usuario para su aprobación por el PO o realizar comentarios. Dashboard: Cuadro de mandos del proyecto con información general, actividades realizadas e indicadores de progreso. *Boceto (Wireframe): Contenido de la interfaz, baja calidad. Maqueta (Mockup): Contenido de la interfaz, alta calidad. Diagrama de contenido: Estructura de la aplicación/sitio web. Diagrama de estados: Flujo de navegación. Wireflow: Flujo de navegación. Prototipo: Contenido y estructura de la interfaz, así como elementos de flujo de navegación. *Modelo de Ciclo de Vida: Fases que se encadenan en secuencia y representan un hito del proyecto. El documento es revisado y una vez aprobado, se utiliza como información de entrada para la fase siguiente. Una fase no comienza hasta que no ha terminado la anterior, no es posible la vuelta atrás a menos que se haya detectado algún problema. Muy extendido, intuitivo y fácilmente controlable para problemas con requisitos estables. No adecuado para sistemas innovadores o requisitos cambiantes. Fases: Análisis de requisitos: Captura de requisitos de usuario y especificación de requisitos funcionales y no funcionales y reglas de dominio. Diseño: Propuesta de partición y organización del sistema. Implementación: Traducción del diseño a código fuente y prueba unitaria. Integración: Combinación de componentes del sistema y pruebas de integración y de sistema. Operación y mantenimiento: Explotación y operación del sistema. Evolución del sistema. Entregables principales: Especificación del sistema software, Diseño de arquitectura y componentes, Componentes implementados, Sistema integrado. *Modelo de Proceso Unificado: Para el desarrollo de sistemas software basado en una sucesión de iteraciones que completan incrementalmente el sistema hasta su versión final de producción. El carácter iterativo permite la validación y retroalimentación cíclica y la adaptación a cambios en los requisitos. Cada iteración puede verse como un recorrido por las secuencia de actividades de un ciclo de vida en cascada. En este modelo las actividades se denominan disciplinas. En este tipo de ciclo de vida, las fases son un conjunto de iteraciones que llevan al proyecto a un determinado hito del plan de proyecto. El número de iteraciones y fases depende del proyecto concreto, aunque el UP propone cuatro fases: Inicio, Elaboración, Construcción, Transición. Objetivos: Inicio: Visión general del proyecto. Aceptación del compromiso de abordar el desarrollo. Elaboración: Captura de requisitos de mayor valoración de negocio o riesgo. Implementación iterativa de la arquitectura del sistema. Construcción: Implementación del resto del sistema. Versión (alfa) ejecutable del sistema. Transición: Versión (beta) ejecutable del sistema. Despliegue y puesta en operación. *Repositorio de proyecto: Almacén gestionado de artefactos de desarrollo de software con procedimientos de registro de entrada y salida de dichos artefactos. Baseline: Conjunto de componentes de configuración estables, revisados y acordados que sirve como base para llevar a cabo la siguiente fase en el proceso de desarrollo (por ejemplo, entrega de un Scrum sprint). Una baseline solo puede cambiarse siguiendo el proceso de gestión de cambios formalmente definido para el proyecto. Entrega (Release): Versión de un sistema (baseline) que se distribuye a usuarios fuera del ámbito del equipo de desarrollo (normalmente clientes). *Modelo de Dominio: Es un diagrama que se utiliza para modelar los conceptos (clases) relevantes al analizar un problema. Diagrama de Secuencia: Es un diagrama que se utiliza para modelar la interfaz pública de un sistema software para un escenario de un caso de uso. Modelo de Dominio: Se crea a partir de la descripción textual del escenario de un caso de uso. Diagrama de Secuencia: Se crea a partir de la descripción de uno de los escenarios descritos en un caso de uso. Modelo de Dominio: Se representa como un diagrama de clases. Diagrama de Secuencia: Se representa como un diagrama de secuencia. *Actividades TPV: Identificación de actores, Definición de historias de usuario y asociación con actores, Definición de hechos, Definición de pruebas de aceptación, Planificación de sprint: priorización, estimación de esfuerzo, release plan, sprint plan, Generación de diferentes documentos técnicos en formato PDF. *Dependencia: Se utiliza para indicar que un elemento utiliza a otro (relación de uso). Por ejemplo, se utiliza para indicar que una clase MiApplet utiliza a otra clase Graphics como argumento en una operación paint. - - -> Asociación: Se utiliza para indicar que existe una interconexión o enlace entre los objetos representados por las abstracciones relacionadas. Por ejemplo, se utiliza para indicar que un objeto de la clase Biblioteca almacena objetos de la clase Libro. ____ Generalización: Se utiliza para indicar que existe una relación entre una abstracción general (superclase) y una abstracción más concreta del mismo tipo (subclase). Por ejemplo, se utiliza para indicar que una clase Elipse es una subclase de la clase Figura. _____|> Realización: Se utiliza para indicar que un elemento implementa el comportamiento que otro elemento especifica. Por ejemplo, se utiliza para indicar que una clase ArrayList cumplirá el contrato especificado por la interfaz List. - - -|>