Aplicativos sin histórico de documentación

En base al "Proyecto de Transformación" se acuerda documentar los proyectos asistenciales que carecen o disponen de poca información dentro del modelado de información del proyecto en EA.

Teniendo en cuenta que estos proyectos se iniciaron hace bastante tiempo y que algunos de ellos tienen tendencia a desaparear y ser sustituidos o embebidos por otros se diferencian dos bloques que agrupan distintos proyectos siguiendo los criterios definidos anteriormente y en cada bloque se define y detalla la información que se ha de documentar en EA.

En un primer bloque, Bloque I, se agrupan los proyectos: MACO, ESTRUCTURA y GADU, y en un segundo bloque, Bloque II, se incluye inicialmente el proyecto HSAP.

Tras varias reuniones mantenidas por la STIC con el Proveedor de estas aplicaciones, se acuerda la documentación mínima a entregar (referente al modelado del sistema) para las aplicaciones agrupadas dentro del Bloque I, quedando pendiente de definir la documentación a entregar para el Bloque II.

ESTE ACUERDO FINALIZA EN EL MOMENTO QUE SEA NECESARIO REALIZAR UNA EVOLUCIÓN DE LA APLICACIÓN, EN ESTE MOMENTO LOS CAMBIOS QUE SE REALICEN SE DEBEN HACER CUMPLIENDO LA NORMATIVA y PLANTILLA VIGENTE.

Documentación Aplicaciones Bloque I

En este apartado se indica la documentación mínima a entregar para las aplicaciones agrupadas dentro del Bloque I:

• La plantilla EA de los entregables será la v01r09
• La normativa a aplicar será la v01r09 teniendo en cuenta lo indicado en este apartado
• Glosario de términos
  • Se incluirán cumpliendo normativa
• Entregas: se realizarán entregas parciales sobre cada fase: DR, AS, DS de forma que la OCA realizará una revisión informal por cada una de las entregas revisando sólo los elementos incluidos en la carpeta correspondiente a cada entrega. Ejemplo: entrega DR solo se revisan los objetos incluidos en la carpeta "Definición de requisitos".
  • Tras la entrega final DS se procederá a la revisión formal. En esta revisión se reportarán todos los defectos encontrado en el eap completo.
  • La nomenclatura de entrega se realizará conforme a normativa

A continuación se especifica la documentación que debe contener cada apartado del entregable EA:

Información Aplicativo

• Participantes:
  • NO es necesario incluir información en este apartado

Definición de requisitos

• Objetivos del sistema:
  • Se incluirán cumpliendo normativa
  • NO es necesario realizar el diagrama "Objetivos del sistema"
• Catálogo de Requisitos
  • NO es necesario realizar el diagrama "Catalogo de Requisitos"
  • Requisitos Funcionales
    • Se incluirán cumpliendo normativa
    • Diagrama "Requisitos Funcionales" contendrá la trazabilidad entre los requisitos y los objetivos
  • Requisitos de Integración
    • Se incluirán cumpliendo normativa
    • Diagrama "Requisitos de integración" contendrá la trazabilidad entre los requisitos y los objetivos
    • No es obligatorio relacionarlos con requisitos de información para especificar los campos o parámetros que requiere dicha integración
  • Requisitos No Funcionales
    • Se incluirán cumpliendo normativa
    • Diagrama "Requisitos No funcionales" contendrá la trazabilidad entre los requisitos y los objetivos
  • Requisitos de Información
    • Se incluirán cumpliendo normativa
    • No es necesario que los requisitos de información estén relacionados con las tablas
    • Diagrama "Requisitos información" contendrá la trazabilidad entre:
      • Requisitos
      • Requisitos y los objetivos

Analisis del sistema

• Modelo de Subsistemas
  • Se incluirán cumpliendo normativa
  • Diagrama "Modelo de Subsistemas" contendrá las relaciones entre los subsistemas. Si no hay relaciones también se tendrá que entregar el diagrama.
• Catálogo de Actores
  • Se incluirán cumpliendo normativa los actores (actores y sistemas)
  • NO es necesario realizar el diagrama "Catálogo de Actores"
  • Diagrama "Actores" contendrá las relaciones entre los actores del tipo Actor. Si no hay relaciones también se tendrá que entregar el diagrama.
  • Diagrama "Sistemas" contendrá las relaciones entre los actores del tipo Sistemas. Si no hay relaciones también se tendrá que entregar el diagrama.
• Casos de uso
  • NO es necesario realizar el diagrama "Casos de uso"
  • Los CUs que ya estén documentados NO serán necesarios adaptarlos a normativa. Esta forma de proceder se concretará por aplicación y previa validación de los CUs existentes por parte de la OCA. Se etiquetarán con el estado "N/A - Previo normativa" y versión la que corresponda.

En estos casos de uso se permitirá que no estén relacionados con casos de pruebas ya que no se van a pedir que se incluyan todos los casos de prueba.

• Los CUs no documentados se incluirán cumpliendo normativa.
  • Diagrama de "Casos de uso SUBXXX" contendrá la trazabilidad entre los actores con los casos de uso y casos de uso con los requisitos

• Modelo de Proceso de Negocio
  • NO es necesario realizar el diagrama "Modelo de proceso de Negocio SUBXXX"
  • Diagrama "Modelo de proceso de Negocio Interoperabilidad", se añadirá en el diagrama un objeto del tipo Note donde se hará referencia al documento de relaciones (Excel y doc) indicando su ubicación en Sharepoint.
• Interfaces de Usuario y Navegación
  • Diagrama de "Diagrama de Navegabilidad" contendrá la navegación entre las pantallas y los informes.
  • Pantallas
    • Se incluirán cumpliendo normativa las pantallas más importantes y/o relevantes
    • Diagrama de "Pantallas" contendrá la trazabilidad entre:
      • Pantallas
      • Pantallas y casos de uso
  • Informes
    • Se incluirán cumpliendo normativa los informes más importantes y/o relevantes
    • Diagrama de "Informes" contendrá la trazabilidad entre informes y casos de uso
• Interfaz a través de Servicios
  • NO es necesario incluir información en este apartado
• Modelo de Clases Lógico
  • NO es necesario aportarlo
• Modelo de Datos Lógico
  • NO es necesario aportarlo
• Casos de Prueba
  • NO es necesario realizar el diagrama "Casos de Prueba"
  • Casos de Prueba Software
    • Es necesario documentar solo los casos de pruebas de regresión, estos casos de prueba se incluirán cumpliendo con normativa
    • Todos los casos de pruebas estarán relacionados con casos de uso según normativa
    • No es necesario realizar el diagrama "Casos de Prueba Software"
    • Diagrama de "Casos de Prueba SUBXXX" contendrá la trazabilidad entre:
      • Actor y caso de uso
      • Caso de prueba y caso de uso
  • Casos de Prueba Interoperabilidad
    • NO es necesario aportarlo

Diseño del sistema

• Arquitectura del Sistema
  • Se incluirá la información asociada a la arquitectura del sistema representada mediante diagramas del tipo "Deployment Diagram"
• Interfaz a través de Servicios DS
  • NO es necesario realizar el diagrama "Interfaz a través de Servicios DS"
  • Provisión de Servicios DS
    • Se incluirán cumpliendo normativa las interfaces pero solo se requerirá una descripción clara de la interfaz y de los servicios (No se describen los atributos).
    • Se hará referencia a la documentación SOA existente de los servicios bien a nivel de carpeta "Provisión de servicios DS" o bien a nivel de interfaces.
    • Diagrama "Provisión de Servicios DS" contendrá la trazabilidad entre las interfaces y los casos de uso.
  • Consumo de Servicios DS
    • Se incluirán cumpliendo normativa las interfaces pero solo se requerirá una descripción clara de la interfaz y de los servicios (No se describen los atributos).
    • Se hará referencia a la documentación SOA existente de los servicios bien a nivel de carpeta "Consumo de servicios DS" o bien a nivel de interfaces.
    • Diagrama "Consumo de Servicios DS" contendrá la trazabilidad entre las interfaces y los casos de uso.
• Modelo de Clases Físico
  • NO es necesario realizar el diagrama  "Modelo de Clases Físico"
  • Las clases se incorporarán mediante ingeniería inversa (solo las más importantes y/o relevantes).
  • Solo es necesario documentar el nombre y descripción de las clases (no es necesario documentar atributos ni métodos, con el nombre es suficiente)
  • NO es necesario relacionar las clases con:
    • Casos de uso
    • Interfaces
  • Diagrama de "Clases SUBXXX (Físico)" contendrá las relaciones entre clases
• Modelo de Datos Físico
  • Las tablas y vistas se incorporarán mediante ingeniería inversa (solo las más importantes y/o relevantes).
  • Solo es necesario documentar los siguientes campos de las tablas o vistas:
    • Nombre y descripción de la tabla
    • Nombre y descripción de las columnas
    • Nombre y descripción de las constraints
  • NO es necesario relacionar las tablas o vistas con:
    • Requisitos de información
  • Diagrama de "Modelo de Datos Físico" contendrá las relaciones entre tablas y vistas

Matriz de trazabilidad

A continuación se muestra la matriz de trazabilidad con las relaciones entre elementos: