Subdirección de las Tecnologías de la Información y Comunicaciones

Área de Gobernanza y Calidad


Contenido


  • Versión: v01r09
  • Fecha publicación:  20 de septiembre de 2017
  • Entrada en vigor desde: 20 de octubre de 2017

Las normas expuestas son de obligado cumplimiento. La STIC podrá estudiar los casos excepcionales los cuales serán gestionados a través de los responsables del proyecto correspondiente y autorizados por el Área de Gobernanza de la STIC. Asimismo cualquier aspecto no recogido en estas normas deberá regirse en primera instancia por las guías técnicas correspondientes al esquema nacional de seguridad y esquema nacional de interoperabilidad según correspondencia y en su defecto a los marcos normativos y de desarrollo software establecidos por la Junta de Andalucía, debiendo ser puesto de manifiesto ante la STIC.

La STIC se reserva el derecho a la modificación de la norma sin previo aviso, tras lo cual, notificará del cambio a los actores implicados para su adopción inmediata según la planificación de cada proyecto.

En el caso de que algún actor considere conveniente y/o necesario el incumplimiento de alguna de las normas y/o recomendaciones, deberá aportar previamente la correspondiente justificación fehaciente documentada de la solución alternativa propuesta, así como toda aquella documentación que le sea requerida por la STIC para proceder a su validación técnica.

Contacto Dpto: Oficina de Calidad

Versiónv01r09Fecha publicación20 de septiembre de 2017Fecha entrada en vigor20 de octubre de 2017
Alcance

- Se añade una recomendación acerca de cómo nombrar a las carpetas creadas por el proveedor para evitar confusiones entre dichas carpetas y los subsistemas.

- En la carpeta Aplicativo Software se usará también el nombre corto del aplicativo para homogeneizar.

- Se especifica la obligatoriedad de que los diferentes elementos incluidos en la plantilla aparezcan en algún diagrama.

- Se incluyen recomendaciones a la hora del uso de la ingeniería inversa para incluir los modelos de clases y de datos.

- Se especifica la obligatoriedad de una nueva entrega asociada a la fase de construcción con el resultado de la ejecución de los casos de prueba por parte del proveedor.

- Se aclara como entregar las evidencias asociadas a los casos de prueba de integración.

- A la hora de trabajar con el estado N/A se especifica ahora el motivo por el que no aplica.

Versiónv01r08Fecha publicación5 de mayo de 2017Fecha entrada en vigor05 de junio de 2017
Alcance

Versión BETA distribuida por la OCA de manera específica para los proyectos DBS (Módulo de Datos Básicos de Salud) y HSAP

- Se sube la versión para evitar confusiones con versiones previas a la definitiva de la v01r07 distribuidas antes de su finalización.

- Se aclara que puede haber requisitos de información sin tablas asociadas.

Versiónv01r07Fecha publicación
Fecha entrada en vigor
Alcance

Versión no liberada por la OCA  (1 de noviembre de 2016)

- Se incluyen las constantes para la generación de documentación.

- Se especifica que todos los diagramas deben llevar su descripción.

- Se modifica el nombre de los apartados relacionados con los modelos de clases y de datos y se aclaran las clases y tablas a incluir.

- Se cambia el tipo de diagrama usado para los modelos de proceso de negocio.

- Se incluye el catálogo de excepciones.

- Se establece una nueva entrega asociada a la construcción.

- Se incluyen aclaraciones en la nomenclatura de los diferentes elementos.

- Se incluyen aclaraciones en la información relacionada con las relaciones entre los diferentes elementos.

- Se simplifica la gestión de estados reduciendo el nº de ellos.

- Se indica como especificar los puntos de entrada de las diferentes secuencias y excepciones de los escenarios de los casos de uso y de prueba.

- Se amplía la información acerca de cómo incorporar la información acerca de los include y extend en los casos de uso.

- Se define la información adicional a incorporar en los casos de uso relacionados con interfaces a través de servicios.

- Se indica cómo trabajar con clases de los tipos interface y enumeration.

- Se modifica la información relacionada con los casos de prueba de integración predefinidos y se añaden los relacionados con los servicios REST.

- Los casos de prueba funcionales pasan a llamarse casos de prueba funcionales de interoperabilidad.

- Se incluyen aclaraciones en las instrucciones para el versionado y la entrega.

- Se incluye un último apartado con instrucciones para pasar la información existente de la anterior versión de la plantilla a la actual.

Versiónv01r06Fecha publicación5 de mayo de 2016Fecha entrada en vigor05 de mayo de 2016
Alcance
Primera versión distribuida por la OCA y el área de desarrollo y proyectos y utilizada por la mayoría de proyectos

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:

  • Sin etiquetas