Diagrama

1. Etapas o fases en el análisis y diseño del proyecto

1.1. Análisis orientado a la planificación del proyecto 

El Responsable Técnico junto con los Miembros del Equipo de desarrollo del proyecto realizan un análisis inicial del proyecto de baja granularidad guardando los esquemas, diagramas, comentarios y/o prototipos en la sección Análisis y diseño del proyecto en confluence, dentro de los apartados correspondientes. Este esfuerzo inicial deberá registrarse en la etapa de Elaborar Plan del Proyecto dentro del apartado 3. Planificación del Proyecto.

Esta etapa debe generar un análisis que sirva de base a la planificación del proyecto. En etapas posteriores se irá enriqueciendo hasta alcanzar un diseño de mayor granularidad que represente el sistema que se va a realizar o se está realizando.

Este análisis hay que hacerlo cada vez que se aborde un proyecto nuevo, o una ampliación de un proyecto existente.

A la hora de registrar este análisis inicial, se tendrá que dar de alta un Jira dentro del apartado Planificación del Proyecto:

De igual manera en cada Release se deberá definir el mismo Jira de análisis de release con el formato anterior.

1.2. Diseño del proyecto 

Una vez realizada la arquitectura base los Miembros del Equipo coordinados por el Responsable Técnico deberán detallar la arquitectura del proyecto a implementar profundizando en los detalles. Este detalle se puede registrar en la tarea de Análisis y diseño de cada Release o bien como una tarea global independiente en primera instancia, y actualizada en cada tarea de Análisis y diseño de cada una de las Releases del proyecto.

Para realizar el análisis del proyecto hay definidos una serie de artefactos y herramientas por defecto, pero puede ser ampliada conforme el Responsable Técnico estime oportuno, teniendo en cuenta que los artefactos marcados como obligatorios deben generarse.

2. Artefactos utilizados durante el análisis y el diseño del proyecto

2.1. Diseño de arquitectura (obligatorio) 

Este artefacto se encuentra en el apartado Análisis y diseño > Diseño de arquitectura. Consta de una página en el espacio del proyecto donde se detallará:

• La pila tecnológica del proyecto, si es un proyecto FundeWeb o desarrollo en arquitectura cloud (FundeWebJS) se tendría que enlazar las páginas de confluence xxxxx o xxxxJS según proceda; en caso de no ser un proyecto FundeWeb, crear una página en confluence con la descripción de la misma y enlazar.
• Los módulos principales del proyecto y las dependencias entre ellos, así como las dependencias con módulos externos.
  • Para cada módulo detallar su funcionalidad y tipo ( PL/SQL, Web )
• Factores de diseño, de alto nivel, relevantes a tener en cuenta.

Para registrar el trabajo realizado deberemos crear una subtarea a partir de la tarea de análisis creada para el análisis inicial o el análisis de la release.

Para realizar este diagrama se propone la herramienta Astah UML, pudiéndose crear diagramas de componentes y/o clases.

2.2. Diseño de base de datos (obligatorio) 

Este artefacto se encuentra en el apartado Análisis y diseño > Diseño de la base de datos, en él se debe reflejar el diseño de base de datos a alto nivel, reflejando las tablas y relaciones existentes entre ellas. También se deben describir los paquetes PL/SQL diseñados y la finalidad de cada uno. Para realizar esta tara deberemos seguir la Normativa de Desarrollo de BD de ATICA

Este diagrama se creará de manera iterativa, partiendo de una versión inicial e incrementándose (si fuese necesrio) en cada release del proyecto. Por lo tanto este esquema se debe ir enriqueciendo en las diferentes iteraciones de desarrollo con los cambios aplicados en cada Sprint/Release para que el diagrama se mantenga actualizado. 

Para registrar el trabajo realizado deberemos crear una subtarea a partir de la tarea de análisis creada para el análisis inicial o el análisis de la release.

Éste diagrama se puede diseñar mediante un diagrama de clases con Astah UML o bien a partir de un modelo obtenido mediante Data Modeler

Opcionalmente podemos asociar el script de creación del esquema de base de datos o bien el enlace al repositorio en el que esté almacenado dicho script.

2.3. Diseño de la interacción entre componentes (obligatorio) 

Este artefacto se encuentra en el apartado Análisis y diseño > Diseño de flujos de interacción, en él debemos definir los diagramas de actividad y secuencia de los distintos módulos de nuestro sistema.

La parte obligatoria es la definición de los flujos de interacciones entre módulos y/o componentes relevantes de nuestro proyecto (si los tuviera). Si una determinada acción o tarea en nuestro proyecto requiere interacción entre diferentes módulos o funcionalidades, debe quedar registrado mediante un diagrama de actividad.

Para registrar el trabajo realizado deberemos crear una subtarea a partir de la tarea de análisis creada para el análisis inicial o el análisis de la release.

Opcionalmente se pueden añadir todos los diagramas necesarios para aclarar los flujos de interacción de nuestra aplicación:

• Interacción de alto nivel (sin muchos detalles) mediante un diagrama de actividad, donde se detalla el proceso de interacciones entre módulos o acciones secuenciales que se realizan para realizar una acción o serie de acciones. Similar a los casos de uso, pero modelando el comportamiento del sistema en vez la interacción usuario-sistema.
• Interacción de bajo nivel (detallada) mediante un diagrama de secuencia donde se especifican las diferentes llamadas a cada módulo, su orden y los parámetros que se intercambian.

Para realizar estos diagrama se propone la herramienta Astah UML

2.4. Casos de uso 

Este artefacto se encuentra en el apartado Análisis y diseño > Casos de uso, en él debemos definir los casos de uso que contempla nuestro proyecto. En este apartado detallaremos las interacciones usuario-sistema para poder analizar las interacciones posibles y las respuestas que se esperan.

Si bien esta parte es opcional, se recomienda modelar los principales casos de uso, para ser conscientes de manera clara de la funcionalidad que oferta nuestra aplicación.

Existe disponible una plantilla de Casos de Uso, que puede ser creada a través de la creación de páginas con plantilla.

Las páginas creadas deben respetar la estructura en el nombre:

• "CUS-NMZ: NombreCasoUso", donde NMZ es un número consecutivo de caso de uso, y NombreCasoUso es el Nombre del caso de uso.

Otra opción más sencilla, es pulsar sobre el botón Nuevo Caso de Uso que se puede encontrar en la página Casos de Uso.

Para registrar el trabajo realizado deberemos crear una subtarea a partir de la tarea de análisis creada para el análisis inicial o el análisis de la release.

2.5. Prototipado de pantallas 

Este artefacto se encuentra en el apartado Análisis y diseño > Prototipado de pantallas, en él deberemos reflejar los prototipos de la interfaz gráfica de nuestra aplicación. Junto con estos prototipos podemos indicar información sobre el estado del mismo para recabar información sobre si el prototipo se aceptó o descartó, las fechas en las que se hizo, tal y como se indica en la plantilla.

Para registrar el trabajo realizado deberemos crear una subtarea a partir de la tarea de análisis creada para el análisis inicial o el análisis de la release.

Para realizar los prototipos se propone la herramienta Pencil

2.6. Documentación adicional 

Este artefacto se encuentra en el apartado Análisis y diseño > Documentación adicional, en este apartado registraremos toda la documentación de análisis adicional que no tiene lugar en los apartados anteriores.

3. Herramientas para las fases de análisis y diseño 

En esta sección detallamos las herramientas recomendadas a utilizar para generar los diferentes artefactos en la fase de análisis, no obstante no hay obligación de usar exclusivamente las propuestas. El objetivo es generar los artefactos de la manera más cómoda posible:

• Modelado bases de datos: Oracle Data Modeler
• Modelado de diagramas: Astah UML 
• Prototipado de pantallas: Pencil