Introducció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, GADU, Estación de Gestión (EG) y Estación clínica (ECH),  y en un segundo bloque, Bloque II, se incluye inicialmente el proyecto HSAP y CAE URG-CExternas.

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 de los distintos bloques.

Para las aplicaciones incluidas en el Bloque I, se debe tener en cuenta lo siguiente:

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

Análisis 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:

Documentación Aplicaciones Bloque II

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

• 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:
  • Sólo para nuevas funcionalidades o si cambia alguna de ellas. Se incluirán cumpliendo normativa.
  • Se debe realizar el diagrama "Objetivos del sistema", con los objetivos que se hayan incluido en dicho apartado.
• Catálogo de Requisitos
  • Se debe realizar el diagrama "Catalogo de Requisitos", con los requisitos que se hayan incluido en dicho apartado.
  • Requisitos Funcionales
    • Sólo para nuevas funcionalidades o si cambia alguna de ellas. Se incluirán cumpliendo normativa.
    • Diagrama "Requisitos Funcionales" contendrá la trazabilidad entre los requisitos y los objetivos.
  • Requisitos de Integración
    • Sólo para nuevas funcionalidades o si cambia alguna de ellas. Se incluirán cumpliendo normativa.
    • Diagrama "Requisitos de integración" contendrá la trazabilidad entre los requisitos y los objetivos.
  • Requisitos No Funcionales
    • Sólo para nuevas funcionalidades o si cambia alguna de ellas. Se incluirán cumpliendo normativa.
    • Diagrama "Requisitos No funcionales" contendrá la trazabilidad entre los requisitos y los objetivos.
  • Requisitos de Información
    • Sólo para nuevas funcionalidades o si cambia alguna de ellas. Se incluirán cumpliendo normativa.
    • No es necesario que los requisitos de información estén relacionados con las tablas (puesto que no es obligatorio incluirlas).
    • Diagrama "Requisitos información" contendrá la trazabilidad entre requisitos.

Análisis del sistema

• Modelo de Subsistemas
  • Es opcional incluirlo. En caso de incluirlo deberá contener aquellos subsistemas en los que aparecen nuevas funcionalidades o cambia alguna de ellas. Se incluirán cumpliendo normativa.
  • El diagrama "Modelo de Subsistemas" es opcional. En caso de incluir algún subsitema deberá incluirse el diagrama, que contendrá las relaciones entre los subsistemas, si las hay.
• 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
    • Los casos de uso con los requisitos

• Modelo de Proceso de Negocio
  • NO es necesario incluir información en este apartado.
• Interfaces de Usuario y Navegación
  • NO es necesario incluir información en este apartado
• 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
    • Sólo para nuevas funcionalidades o si cambia alguna de ellas. Se incluirán cumpliendo 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"
    • Se debe incluir el diagrama de "Casos de Prueba SUBXXX", con los casos de prueba incluidos en el apartado. Este diagrama 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
  • NO es necesario aportarlo
• 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 aportarlo
• Modelo de Datos Físico
  • NO es necesario aportarlo

Matriz de trazabilidad

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