El objetivo de este proceso es el proponer una solución arquitectonica que cubra los aspectos reflejados en el documento de visión y los requisitos funcionales y no funcionales descritos en los distintos documentos de requisitos. Para ello crearemos distintos documentos de análisis en los que describiremos dicha solución. Estos documentos servirán de guía al analista/diseñador del software en el proceso de diseño, y a los programadores en la disciplina de desarrollo.

Para la realización de este proceso, se deberá de estudiar el documento de visión del proyecto, en el cual es posible encontrar una primera visión arquitectónica del proyecto descrita en alto nivel de abstracción. También será necesario conocer los requisitos funcionales descritos en el documento de requisitos: Casos de Uso e Historias y los requisitos no funcionales. Además, para su elaboración es posible que sea necesario la elaboración de entrevistas con:

• El cliente final del proyecto
• El responsable del documento de requisitos
• El responsable del documento de visión
• Los responsables de los módulos externos con los que tiene que interactuar el sistema.

Para la realización de entrevistas, especialmente con el cliente final, convoca siempre reuniones con un orden del día preestablecido. Envíalo con suficiente antelación y atente a él durante la reunión.

Una vez realizada la reunión elabora un acta y envíala a los asistentes para su aprobación.

Los siguientes son los roles participantes en este proceso:

Cada participante en esta tarea DEBE crear un JIRA con los siguientes datos, y registrar las horas de trabajo en ella:

2.1. Iniciar la creación de un nuevo Documento de análisis.

2.2. Escribir la siguiente sección del Documento de análisis:

• “1. Introducción”, en la que se debe describir de manera resumida el alcance del documento de análisis.
  • Para su elaboración, puede consultarse el documento de Visión, los casos de uso e historias, que son los artefactos de salida de la disciplina de Requisitos.

3.1. Escribir la siguiente sección del Documento de Análisis:

• “2. Arquitectura Global”. En ella se mostrará la arquitectura lógica que tendrá nuestro proyecto. Para ello, iremos completando las siguientes subsecciones:
  • “2.1. Diagrama”. En este diagrama se representará visualmente el conjunto de módulos que compondrán nuestra solución, así como las relaciones entre los mismos. Distinguiremos entre módulos internos y externos, entendiendo como Módulo interno aquel que será desarrollado en el ámbito de este proyecto, y por Módulo externo aquel perteneciente a otra unidad, departamento, sección, … pero que será necesario para la ejecución de nuestro proyecto. Para su elaboración, seguid los siguientes principios:
    • Los diagramas serán realizados con OpenOffice Draw, e insertados en el documento como un objeto OLE desde el fichero de la imagen.
    • Para su realización, estudiar el documento de visión; depende del proyecto, es posible que en él se incluya un diagrama de la arquitectura de alto nivel que os puede servir de punto de partida.
    • No abusad de la creación de módulos; los proyecto más frecuentes suelen tener un único módulo interno con un conjunto de dependencias externas (módulos externos). Esta decisión nos la dará principalmente el estudio de los requisitos funcionales del proyecto.
    • En el caso de identificar más de un módulo, mostrar en el diagrama las interfaces y protocolos de comunicación entre ellos.

• “2.2. a 2.N. Módulo N”. En estos apartados, se debe hacer una pequeña descripción del módulo, su utilidad, papel en la arquitectura y relación con el resto de módulos. Esta descripción nos servirá de base para posteriormente completar la tarea “MDA-TR-1.0-ANA-Definir Arquitectura Lógica de cada Módulo”

4.1. Escribir la siguiente sección del Documento de Análisis:

• “3. Flujos de interacción entre módulos”. En este apartado se mostrarán aquellos flujos de interación más significativos entre los diferentes módulos. Tendrán un especial interés cuando nuestro proyecto está compuesto por más de un módulo, o cuando queramos reflejar la forma de interacción con módulos externos.

Para cada flujo que se desee mostrar, crear su propia subsección:

• “3.1. Flujo de Información N”. Se mostrará aquí el flujo realizado como diagramas de secuencia UML con la herramienta astahUML.

Será el primer diagrama UML creado por iniciaremos la creación de un nuevo documento del tipo:

Cada participante en esta tarea DEBE crear un JIRA con los siguientes datos, y registrar las horas de trabajo en ella:

2.1. Por cada módulo identificado en la Arquitectura Global del Documento de Análisis, iniciar la creación de un nuevo Documento de Análisis de Modulo, usando una de las siguientes dos plantillas, según sea un Modulo Web o un Modulo de Servicios (lo único que cambia en estas dos plantillas es el diagrama de arquitectura del módulo):

• Las plantillas hacen uso de los gráficos Diagrama de Arquitectura de Módulo Web y Diagrama de Arquitectura de Módulo de Servicios que también pueden ser descargados y modificados.

Por defecto estos apartados vendrán rellenos, si es un modulo web o de una capa de servicios, si se utilizan las plantillas anteriormente citadas. Sin embargo puede haber ocasiones que o bien no nos sirvan, o bien, sea necesario hacer modificaciones.

• 3.1. Escribir los siguientes apartados:
  • “4.1.1 Diagrama de Arquitectura”. Diagrama de arquitectura en el que aparecen la estructura interna del modulo a alto nivel. Aparecen las capas y componentes software más relevantes. Es para que quede reflejado a nivel global cómo va a estar estructurado el software.
  • “4.1.2 Breve descripción diagrama de arquitectura”. Breve descripción de cada una de esas capas y componentes software.

Cada participante en esta tarea DEBE crear un JIRA con los siguientes datos, y registrar las horas de trabajo en ella:

2.1. En el documento de Analisis del Módulo, escribir las siguientes secciones:

• “4.1.3. Diagrama de Clases Conceptual”. En este apartado se incluirán el diagrama ( o diagramas en el posible caso de que no quepa en uno) de conceptos del sistema. Servirá de base para los posteriores Entidad/Relacion y Diagrama de Clases de la etapa de diseño y en él aparecerán conceptos relevantes, sus atributos y relacion entre distintos conceptos.
  • El diagrama se realizará con la herramienta Astah. Para más información de cómo realizarlo seguir el siguiente manual, en el apartado Diagrama Conceptual
• “4.1.4. Explicación Modelado Conceptual”. Descripción textual de los conceptos básicos del sistema.

2.2. Modificad el Documento de Análisis para integrar TODOS los Documentos de Módulo que se hayan creado:

• Dentro de la sección “4. Arquitectura de los Módulos.”

Para ello sigue las instrucciones acerca de cómo manejar documentos_maestros

• NOTAS:
  • XXX: Código del proyecto.
  • 1.2.3: Número de version del documento.
  • [NombreMódulo]: Nombre del módulo que se describe en este documento.

Las métricas del proyecto se guardarán dentro de la carpeta del proyecto en Proyecto/Documentacion/1.Gestionproyecto/1.4.Metricas. Las métricas de este proceso en concreto se almacenan en la Hoja ANA.

1. Entra en Jira en el navegador de incidencias. Realiza una query simple y selecciona todas las tareas del proyecto.

• project = ClaveDelProyecto
• Disciplina-Proceso = ANA-Análisis del Proyecto

Pulsa el botón Search

Usa la Plantilla de Seguimiento tal y como se indica en el apartado Calcular tiempos con Jira.

1. Abre el fichero Documento de Análisis.
2. Cuenta el número de módulos definidos

1. Abre el fichero Diagramas UML.

- Cuenta el numero de clases que cuelgan de la carpeta Analisis.