Desarrollo del Software UNIDAD I
Disciplinas Fundamentales del UP:
Profesor: Cesar Valenzuela Valverde
Objetivos • Identificación de los roles, artefactos y actividades de cada disciplina de UP. • Aplicación de los flujo de actividad de cada disciplina de UP • Integración de las disciplinas fundamentales del proceso unificado en una iteración
Modelado del Negocio • Los principales motivos para ejecutar esta disciplina: Asegurarse de que el producto será algo útil; conseguir que se ajuste de la mejor forma posible en la organización; y tener un marco común para el equipo de proyecto, los clientes y los usuarios finales • Los objetivos específicos del modelado de negocio son: • 1 Asegurar que clientes, usuarios finales y Programadores tengan un entendimiento común de la organización objetivo. • 2. Derivar los requerimientos del sistema necesarios para apoyar a la organización objetivo en su mejora. • 3. Entender el problema actual en la organización objetivo e identificar potenciales mejoras.4. Entender la estructura y la dinámica de la organización para la cual el sistema va a ser desarrollado (organización objetivo)
Modelado del Negocio • Para lograr estos objetivos, el modelado de negocio describe como desarrollar una visión de la nueva organización, basado en esta visión se definen procesos, roles y responsabilidades de la organización por medio de un Modelo de Casos de Uso del Negocio. Los artefactos del modelo de negocio sirven como entrada y referencia para la definición de los requerimientos del sistema. La importancia de esta disciplina radica en que sin el panorama completo del alcance del negocio y sin el entendimiento de sus procesos no podrán identificarse las necesidades inmediatas de mejora y continuidad relativa a las actividades relacionadas con los sistemas informáticos, que son el producto final del desarrollo.
FLUJO DE TRABAJO •
•
Un flujo de trabajo muestra la secuencia de actividades que se desarrollan dentro de uno o varios Casos de Uso, como una pieza de funcionalidad concreta que satisface los requerimientos de un Actor. Organiza y controla tareas, recursos y reglas necesarias para completar el proceso de negocio. BPMS (Business Process Management Systems / Sistemas de Gestión de Procesos de Negocio) tienen el objetivo de acercar personas, procesos y máquinas, ahorrando tiempo y acelerando la realización del trabajo. Facilitan también la automatización de los flujos de trabajo entre procesos, pudiendo integrar estos en la empresa de acuerdo a unas estrategias concretas
Análisis de Arquitectura
Diseño de Arquitectura
Describir Describir Concurrencia Distribución
Arquitecto Análisis de Casos de Uso
Diseño de Casos de Uso
Diseñador de Casos de Uso Análisis de Objetos
Diseño de Objetos
Diseñador
Revisor de Diseño
Revisar el Análisis
Revisar el Diseño
Revisar la Arquitectura
ACTIVIDADES • Es una unidad de trabajo que una persona que desempeñe un rol puede ser solicitado a que realice. Esta Incluye un conjunto de tareas realizadas en un área determinada y tiene como objetivo generar o actualizar algún artefacto. Definir el negocio: Esta actividad trata sobre definir cual va a ser el negocio. Desarrollar el Modelo de Dominio: Esta actividad se basa en desarrollar un subconjunto del modelo de análisis del negocio, es decir, el modelo de dominio. Describir el Negocio Actual: Esta actividad tiene como objetivo comprender y describir el negocio actual. Evaluar el Estatus del Negocio: Esta actividad busca evaluar la del negocio y fijar los objetivos de modelado del negocio Explorar la Automatización del Proceso: Esta actividad trata sobre analizar las oportunidades de automatización para los procesos del negocio en estudio
Roles • Un rol define las responsabilidades de un individuo, o de un grupo de individuos trabajando juntos como un equipo. . Este se encarga de la realización de tareas, las cuales generan artefactos. Existen artefactos que necesitan de más de un solo rol para poder ser elaborados. • Metodología más que proponer una serie de roles estáticos para un proyecto establece que se pueden utilizar los roles que se consideren necesario para realizar el proyecto según las características y el tiempo requerido por este. Cada uno de los roles poseen métodos específicos para la ingeniería del software en su área en particular
Roles • • • • • • • •
Roles básicos que deben tomarse en cuenta para la elaboración de software: Analista de Calidad: Se encarga de revisar todos los documentos de avance del proyecto Analista de Producto: Se encarga de dirigir el proceso de captura de requerimientos. Arquitecto de Software: Se encarga de la definición de la arquitectura que guiará el SW Desarrollador: : Tiene a su cargo la codificación de los componentes en código fuente . Involucrado: : Cualquier persona que se vea afectada por el resultado del proyecto . Líder del Proyecto:: Este rol se encarga de establecer las condiciones de trabajo.. Mentor : Es el rol que está íntimamente ligado con el proceso de desarrollo de software, Probador: : La función es realizar las pruebas identificadas y definidas previamente.
Artefactos •
•
•
Documento de Arquitectura del Negocio (DAN): El DAN ayuda a conocer la realidad del negocio, ya que proporciona una visión general de los objetivos, estructura y Documento de Arquitectura del Negocio. Este describe el qué, por qué y cómo del negocio. Contiene varias vistas: Vista del Mercado, Vista del Proceso de Negocio, Vista de la Organización, Vista Geográfica, Vista del Recurso Humano, Vista del Dominio y Vista de Comunicación. Cada una de estas vistas nos da una diferente perspectiva del negocio.
Entidad del Negocio: Este artefacto representa una pieza de información significativa que es manipulada por los actores y trabajadores del negocio. Las entidades del negocio de una aplicación representa entidades reales y además suelen ser sustantivos, como por ejemplo: Cliente, Nómina, Factura, Depósito, etc. Asimismo, las entidades de negocio son la base para compartir documentos entre los trabajadores del negocio y estas pueden ser utilizadas en diversas Realizaciones de los Casos de Uso del Negocio.
Artefactos •
Evaluación de la Organización Objetivo (EOO): Este artefacto describe la situación actual en que se encuentra la organización objetivo, es decir, la organización en la que el sistema será implantado. La descripción está en términos de procesos actuales, herramientas, competencias entre personas, actitudes de las personas, clientes, competidores, tendencias técnicas, problemas y áreas de mejora.
•
Modelo de Análisis del Negocio: Este modelo es interno al negocio, describe la realización de los casos de uso del negocio, para lo cual detalla cómo cada caso de uso de negocio es llevado a cabo por un grupo de trabajadores u sistemas que emplean entidades del negocio y unidades de trabajo recíprocamente.
•
Modelo de Casos de Uso del Negocio: Este modelo permite visualizar el alcance de la organización, representando lo que abarca y cuáles son sus límites. Así mismo, modela las actividades y procesos qué ejecuta una organización, señala gráficamente las funciones y metas que persigue el negocio, y también permite identificar cuáles son los entregables y roles dentro de la organización.
Artefactos •
Modelo de Diseño del Negocio: Este artefacto es un refinamiento del Modelo de Análisis del Negocio, por lo que describe en mayor detalle el cómo el negocio trabaja internamente para llevar a cabo las funciones que ejecuta.
•
Modelo de Implantación del Negocio: El objetivo de este artefacto es relacionar los elementos lógicos que se han detallado en los modelos de Casos de Uso, Análisis y Diseño del Negocio con los elementos físicos que tienen asociados, lo cual podría ser representado mediante localizaciones geográficas y sus características, canales de comunicación empleados y sus propiedades, entre otros recursos físicos.
•
Prueba de Concepto Arquitectónico del Negocio: Este artefacto es una solución que simplemente puede ser conceptual a los requerimientos arquitectónicamente significativos del negocio. El propósito de la Prueba de Concepto Arquitectónico del Negocio es determinar si existe, o es probable que exista, una solución (o un sistema de soluciones) que satisfaga los requerimientos arquitectónicamente significativos.
Artefactos โ ข
Realizaciones de los Casos de Uso del Negocio: Este artefacto expresa la colaboraciรณn de los sistemas del negocio, los trabajadores del negocio, las entidades del negocio, y los eventos del negocio para realizar un caso de uso del negocio particular. Mientras que un caso de uso del negocio, una realizaciรณn de casos de uso del negocio describe la manera en que estos pasos se realizan dentro de la organizaciรณn. Ademรกs, las Realizaciones de los Casos de uso del Negocio son utilizadas por los involucrados para verificar que el equipo del proyecto y demรกs involucrados entienden la estructura y el funcionamiento del negocio.
โ ข
Reglas del Negocio: Este artefacto expresa la colaboraciรณn de los sistemas del negocio, los trabajadores del negocio, las entidades del negocio, y los eventos del negocio para realizar un caso de uso del negocio particular. Mientras que un caso de uso del negocio describe los pasos que se deben realizar para aportar valor a un actor del negocio, una realizaciรณn de casos de uso del negocio describe la manera en que estos pasos se realizan dentro de la organizaciรณn. Ademรกs, las Realizaciones de los Casos de uso del Negocio son utilizadas por los involucrados para verificar que el equipo del proyecto y demรกs involucrados entienden la estructura y el funcionamiento del negocio.
Artefactos •
Trabajador del Negocio: Un Trabajador del Negocio representa a un ser humano, software o hardware que desempeña un rol dentro de las Realizaciones del Caso de Uso del Negocio. Este trabajador interactúa con entidades y otros trabajadores para que el negocio funcione. Los trabajadores de negocio son roles y no posiciones organizacionales, ya que una persona puede desempeñar varios roles pero sólo tiene una posición en la organización.
•
Visión del Negocio: Este artefacto describe los objetivos principales del proyecto, funcionalidades y restricciones en forma concisa; es un resumen del proyecto apto para la toma de decisiones, ofrece una descripción del sistema a ser desarrollado desde la perspectiva de los requerimientos más importantes. Este documento captura las expectativas de los que soportan el desarrollo del proyecto.
Captura de requisitos como casos de uso •
Los requisitos funcionales se estructuran de forma natural mediante casos de uso que constituyen el Modelo de Casos de Uso. Los requisitos no funcionales restantes, se modelan en el documento de requisitos adicionales.
Actividades • Encontrar actores y casos de uso. • Esta actividad consta de cuatro pasos:
Encontrar los actores Encontrar los casos de uso Describir brevemente cada caso de uso Describir el modelo de casos de uso completo (este paso también incluye la preparación de un glosario de términos).
• Priorizar casos de uso • El propósito de esta actividad es priorizar cuales son los casos de uso más importantes para abordar en las primeras iteraciones. Los resultados se recogen en la vista de la arquitectura del modelo de casos de uso. • Esta vista revisada con el jefe de proyecto se utiliza como entrada al hacer la planificación de lo que debe desarrollarse dentro de una iteración.
Actividades • Detallar casos de uso: El objetivo principal de detallar cada caso de uso es describir su flujo de sucesos en detalle, incluyendo como comienza, termina, e interactúan con los actores. Para detallar los casos de uso se usan: Descripciones textuales Diagramas de transición de estados para describir los estados de los casos de uso y las transiciones entre esos estados Diagramas de actividad para describir transiciones entre estados con más detalle como secuencias de acciones. Los diagramas de actividad pueden describirse como la generalización de los diagramas de transición de estados. Diagramas de interacción para describir cómo interactúa una instancia de caso de uso con la instancia de un actor. Los diagramas de interacción muestran el caso de uso y el actor o actores participantes.
Actividades • Para cada caso de uso debe detallarse:
Estado inicial como precondición Cómo y cuando comienza el caso de uso (primera acción a ejecutar) Orden en que deben ejecutarse las acciones Cómo y cuando terminan los casos de uso Posibles estados finales como postcondiciones Caminos de ejecución que no están permitidos Camino básico y Caminos alternativos
• Prototipar interfaz de usuario: Comenzamos con los casos de uso e intentamos discernir que se necesita de las interfaces de usuario para habilitar los casos de uso para cada actor. Hacemos un diseño lógico de la interfaz de usuario, luego creamos un modelo físico, y desarrollamos prototipos para ilustrar como pueden utilizar el sistema los usuarios para ejecutar los casos de uso. • Estructurar el modelo de casos de uso: Los casos de uso identificado son estructurados utilizando las relaciones de uso (secuencias comunes), extensiones (casos excepcionales), y generalizaciones.
Roles • Analista de sistemas : Responsable del modelo de casos de uso, actores y Glosario • Especificador de casos de uso: Asisten al analista de sistema en la descripción detallada de cada caso de uso y es el responsable de este. • Diseñador de interfaz de usuario: Es el responsable del prototipo de interfaz de usuario • Arquitecto: Responsable dela descripción de la arquitectura (vista del modelo de casos de uso)
Artefactos • Los artefactos utilizados en la captura de requisitos por casos de uso son: Modelo de casos de uso Actor Caso de uso Descripción de la arquitectura – vista del modelo de casos de uso. Glosario Prototipo de interfaz de usuario
Análisis • Durante el análisis, analizamos los requisitos que se describieron en la captura de requisitos, refinándolos y estructurándolos. El objetivo de hacerlo es conseguir una comprensión más precisa de los requisitos y una descripción de los mismos que sea fácil de mantener y que nos ayude a estructurar el sistema entero, incluyendo su arquitectura.
Artefactos • Modelo del análisis Compuesto por un sistema de análisis que es el paquete de más alto nivel, el cual se compone a su vez de otros paquetes y clases de análisis y realizaciones de casos de uso. • clase del análisis : Una clase de análisis representa una abstracción de una o varias clases y/o subsistemas del diseño. • realización caso de uso análisis: Una realización de caso de uso – análisis es una colaboración dentro del modelo de análisis que describe cómo se lleva a cabo y se ejecuta un caso de uso determinado en términos de las clases del análisis y sus objetos del análisis en interacción
Artefactos • Paquete del análisis • Los paquetes del análisis proporcionan un medio para organizar los artefactos del modelo de análisis en piezas manejables. Un paquete de análisis puede constar de clases de análisis, de realizaciones de casos de uso, y de otros paquetes del análisis recursivamente • Artefacto: descripción de la arquitectura (vista del modelo de análisis) • Los siguientes artefactos del modelo de análisis se consideran significativos para la arquitectura: Descomposición del modelo de análisis en paquetes de análisis y sus dependencias. Esta descomposición suele tener su efecto en los subsistemas de las capas superiores durante el diseño e implementación. Las clases fundamentales del análisis. Realizaciones de casos de uso que describen funcionalidades importantes y críticas, probablemente las correspondientes a los casos de uso que aparecen en la vista de la arquitectura del modelo de casos de uso.
Roles
• Arquitecto • Es responsable de la integridad del modelo de análisis, garantizando que sea correcto, consistente, y legible como un todo. • El arquitecto es responsable de: La descripción de la arquitectura Modelo del análisis
• Ingeniero de casos de uso • Es responsable de la integridad de una o más realizaciones de caso de uso, garantizando que cumplen los requisitos que recaen sobre ellos. El ing. de casos de uso es responsable de: Realización de casos de uso – análisis.
• Ingeniero de componentes • Define y mantiene las responsabilidades, atributos, relaciones, y requisitos especiales de una o varias clases del análisis asegurándose de que cada clase del análisis cumple los requisitos que se esperan de ella de acuerdo a las realizaciones de caso de uso en que participan. • El ingeniero de componentes es responsable de: clase del análisis paquete del análisis
Actividades • •
Análisis de la arquitectura El propósito de análisis de la arquitectura es esbozar el modelo de análisis y la arquitectura mediante la identificación de paquetes del análisis, clases del análisis evidentes, y requisitos especiales comunes. Identificación de paquetes de análisis: Los paquetes proporcionan un medio para organizar el modelo de análisis en piezas más pequeñas y manejables. Identificación de paquetes de servicio: Se suele hacer cuando el trabajo de análisis está avanzado, cuando se comprenden bien los requisitos funcionales, y existen la mayoría de las clases del análisis. Definición de dependencias entre paquetes del análisis: Deben definirse dependencias entre los paquetes del análisis si sus contenidos están relacionados. La dirección de la dependencia debería ser la misma (navegabilidad) dirección de la relación. Identificación de clases de entidad obvias: Pueden identificarse una lista de clases entidad candidatas basado en las clases del dominio o las entidades del negocio. Identificación de requisitos especiales: Un requisito especial es un requisito que aparece durante el análisis y que es importante anotar de forma que pueda ser tratado adecuadamente en las subsiguientes actividades de diseño e implementación.
Actividades • Analizar un caso de uso: Identificación de clases del análisis: Buscamos clases de entidad, control, e interfaz y esbozamos sus nombres, responsabilidades, atributos, y relaciones. Descripción de las interacciones entre objetos del análisis: Se utiliza un diagrama de colaboración para describir como interactúan los objetos encontrados para realizar el caso de uso. Captura de requisitos especiales: Recogemos todos los requisitos adicionales inherentes al caso de uso que se está tratando.
• Analizar una clase : Identificar y mantener las responsabilidades de la clase, basadas en su papel en las realizaciones de casos de uso. Identificar atributos y relaciones de la clase Capturar requisitos especiales sobre la realización de la clase.
• Analizar un paquete Garantizar que el paquete es tan independiente de otros como sea posible. Garantizar que el paquete del análisis cumple su objetivo de realizar algunas clases del dominio o casos de uso. Describir las dependencias de forma que pueda estimarse el efecto de los cambios futuros.
Diseño • Durante el diseño modelamos el sistema y su arquitectura para que soporte los requisitos funcionales y no funcionales. Una entrada esencial al diseño es el modelo de análisis. • El diseño es el centro de atención al final de la fase de elaboración y comienzo de las iteraciones de construcción.
Artefactos • Modelo del Diseño • El modelo de diseño es un modelo de objetos que describe la realización física de los casos de uso centrándose en los requisitos funcionales como en los no funcionales. Las abstracciones del modelo de diseño tienen una correspondencia directa con los elementos físicos del ambiente de implementación.
Artefactos • Clase del Diseño • Una clase de diseño es una abstracción sin costuras con una clase o construcción similar en la implementación del sistema. • Realización de caso de uso-diseño • Es una colaboración en término de clases de diseño que describe como se realiza un caso de uso específico. Una realización de caso de uso diseño, tiene una traza directa a la correspondiente realización del caso de uso análisis • Subsistema de diseño • Los subsistemas de diseño son una forma de organizar los artefactos del modelo de diseño en piezas más manejables • Interfaz • Las interfaces se utilizan para especificar las operaciones que proporcionan las clases y los subsistemas del diseño • modelo de despliegue • El modelo de despliegue es un modelo de objetos que describe la distribución física del sistema en términos de cómo se distribuye la funcionalidad entre los nodos de cómputo.
Artefactos • descripción de la arquitectura (vista del modelo de diseño) • Se consideran significativos para la arquitectura los siguientes artefactos del modelo de diseño: La descomposición del modelo de diseño en subsistemas, sus interfaces, y las dependencias entre ellos. Clases de diseño fundamentales como clases activas y clases centrales. Realizaciones de caso de uso-diseño que describan alguna funcionalidad importante y crítica.
• descripción de la arquitectura (vista del modelo de despliegue) • La descripción de la arquitectura contiene una vista de la arquitectura del modelo de despliegue que muestra sus artefactos relevantes para la arquitectura.
Roles • Arquitecto • Responsable del modelo de diseño, modelo de despliegue, y descripción de la arquitectura. • Ingeniero de casos de uso • Responsable del realización de caso de uso – diseño. • Ingeniero de componentes • Responsable de Clases de diseño, subsistema de diseño, interfaz
Actividades • diseño de la arquitectura • El objetivo del diseño de la arquitectura es esbozar los modelos de diseño y despliegue identificando: Nodos y configuraciones de red. Subsistemas e interfaces Clases de diseño significativas para la arquitectura como las clases activas (procesos). Mecanismos de diseño genéricos que tratan requisitos comunes.
• diseño de un caso de uso • Los objetivos del diseño de un caso de uso son: - Identificar clases y/o subsistemas necesarios para llevar a cabo el caso de uso. Distribuir el comportamiento del caso de uso entre los objetos del diseño que interactúan y/o entre los subsistemas participantes. Definir los requisitos sobre las operaciones de las clases del diseño y/o sobre los subsistemas y sus interfaces. Capturar los requisitos de implementación del caso de uso.
Actividades • diseño de una clase • Para una clase implica definir:
sus operaciones sus atributos sus relaciones sus métodos (que realizan sus operaciones) su ciclo de vida (máquina de estados) sus dependencias con cualquier mecanismo de diseño genérico. los requisitos relevantes a su implementación la correcta realización de cualquier interfaz requerida
• diseño de un subsistema • Los objetivos del diseño de un subsistema son: Garantizar que el subsistema es lo más independiente de los otros subsistemas. Garantizar que el susbsistema proporciona las interfaces correctas. Garantizar que el subsistema cumple su propósito de ofrecer una realización correcta de las operaciones que se definen en las interfaces.