1. Diseño de arquitectura

1.1. Arquitectura inicial orientada a la planificación del proyecto

El Responsable Técnico junto con los Miembros del Equipo de desarrollo del proyecto realizan un diseño inicial de la arquitectura del proyecto de baja granularidad guardando los esquemas, diagramas, comentarios y/o prototipos en la sección Análisis y diseño 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.

Este diseño inicial debe suponer una base de apoyo a la planificación del proyecto y se irá enriqueciendo en etapas posteriores hasta alcanzar un diseño de mayor granularidad que represente el sistema que se va a realizar.

1.2. Arquitectura  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 de análisis 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 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, indicar que esta página su pila tecnológica.
• 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.

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 pero sin necesidad de detallar las columnas de cada tabla (salvo las que sean especialmente relevantes). El objetivo es poder ver, de un vistazo rápido, la estructuración general de la base de datos necesaria en la aplicación.

Una vez hecho el diagrama inicial, 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. 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 flujos de interacción (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.

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.

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.

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 etc.

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 el análisis

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