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

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

También 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.2. 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 las interacciones entre los flujos de funcionalidad 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 sistema-usuario.
• 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