Se encarga de la revisión de la documentación aportada en las fases ASI y DSI. Se verificará , casos de uso, actores, subsistemas, requisitos, precondiciones, casos de pruebas y la trazabilidad entre ellos.

Este servicio se presta bajo petición expresa, bien sea por parte de un usuario autorizado.

El JP deberá realizar la petición al menos un mes antes de la fecha prevista para el comienzo del servicio y deberá incluir el modelado del aplicativo en Enterprise Architect incluyendo los ficheros correspondientes, bien en la fase de análisis para una primera revisión y/o bien en la fase de diseño y construcción para una revisión final y completa:

• Modelado EA del sistema (Nombre_FF_EA_vXXrXX.xml).
• Constantes del proyecto (Nombre_FF_EAPC_vXXrXX.xml) 
• Glosario y control de cambios (Nombre_FF_EAERD_vXXrXX.xml).

• Archivo .EAP

• Informe sobre la evaluación del testing temprano.
• Alta de "No conformidades" y propuestas de mejoras detectadas durante la verificación.

A través de este servicio, el equipo de la Oficina de Calidad realiza una labor de acompañamiento y detección temprana de errores. El objetivo es agilizar la solución a los posibles problemas detectados en fase de desarrollo, y ofrecer una una visión del estado en que se encuentra el proyecto en cada etapa, para facilitar el aseguramiento de un producto de calidad que logre la satisfacción del usuario final.

El alcance de este servicio incluye:

• Verificación del repositorio de código.
• Verificación y validación de la calidad estática de código.
• Revisión de las pruebas (.feature).
• Organización del plan de pruebas para su ejecución en el entorno de pruebas.
• Verificación del cumplimiento del DoR.
• Verificación del cumplimiento del DoD.

• Taller concepción del producto (al inicio del proyecto en esta metodología)
• Entrevistas y acuerdos en la STIC (al inicio del proyecto en esta metodología)
• Manual usuario
• Historias de usuario
• Casos de prueba en archivos .feature
• Código en el repositorio correspondiente
• Entornos para las pruebas

• Informe de verificación en la herramienta de gestión de proyecto (JIRA).
• Alta en JIRA de los Bugs detectados durante la ejecución de las pruebas en el entorno de desarrollo. 

El objetivo es garantizar el cumplimiento de la normativa de entregas publicada por el Área de Gobernanza, así como la calidad del código del producto. 

El proceso incluye la revisión de los siguientes puntos:

• Compilación de fuentes.
• Ejecución de test unitarios.
• Empaquetado de binarios.
• Análisis estático de Calidad.

• SVE (Jira)
• Software (código fuente)
• Scripts de base de datos (si aplica)

• Informe sobre la revisión, aceptación o rechazo de la entrega.

El objetivo es garantizar la calidad de los scripts para el caso de una carga o correctivo de datos que no suponga modificación de la línea base del código.

El proceso incluye la revisión de los siguientes puntos:

• Script de base de datos.

• SVD (Jira)
• Scripts 

• Resultado de la revisión de la entrega en la misma SVD.
• Informe de evaluación CNO

El servicio de Testing Funcional de la OCA permite determinar si se ha construido el software deseado, que cumple con los requerimientos, y por lo tanto que es candidato a desplegarse en un entorno productivo. Esto ayudará al Servicio Andaluz de Salud a tomar decisiones relacionadas con la versión del producto entregado por el proveedor.

Parte de la ejecución de este Servicio incluye el lanzamiento de pruebas asociadas a versiones anteriores con el fin de garantizar que no se han producido regresiones en la entrega de código. Estas pruebas estarán agrupadas en un plan diseñado para tal fin.

El responsable del proyecto deberá realizar la petición al menos un mes antes de la fecha prevista para el comienzo de las pruebas y deberá incluir la siguiente información:

• Entorno 
• URLs de las aplicaciones afectadas o APK
• Alcance
• Plan de pruebas (EA o GIT) 
• Credenciales de acceso y juego de datos para la ejecución de las pruebas

• Alcance de la versión
• Identificación entorno a probar.
• Plan de pruebas en EA o Git.
• Usuarios de acceso y juego de datos para las pruebas

• Alta de "No conformidades" detectadas durante la verificación funcional en JIRA. En las NC estarán adjuntas las evidencias correspondientes.
• Informe de resultados de las ejecuciones y listado de las NC.

La accesibilidad tiene como objetivo lograr que las páginas web/aplicaciones móviles sean utilizables por el máximo número de personas, independientemente de sus conocimientos o capacidades personales e independientemente de las características técnicas del equipo utilizado para acceder a la Web o Aplicación. 

Todos los sitios webs y aplicaciones para dispositivos móviles desarrollados para la STIC deberán ser accesibles para sus personas usuarias y, en particular, para las personas mayores y personas con discapacidad, de modo que sus contenidos sean perceptibles, operables, comprensibles y robustos. La accesibilidad se tendrá presente de forma integral en el proceso de diseño, gestión, mantenimiento y actualización de contenidos de los sitios web y las aplicaciones para dispositivos móviles.

El responsable del producto deberá realizar la petición al menos un mes antes de la fecha prevista para el comienzo de las pruebas y deberá incluir la siguiente información:

• • Entorno 
  • Casos de uso
  • Credenciales de acceso para las pruebas
  • En el caso de aplicaciones móviles, APK de la misma.

Entorno de PRE:

• APK de la aplicación (SVA-Móvil)
• URL web (SVA-Web)
• Casos de uso
• Credenciales de acceso para las pruebas (Ej: usuario/contraseña, certificado digital, etc)

Entorno de PRO:

• Tener publicada la aplicación en el Play Store, Apple Store, etc. (SVA-Móvil)
• URL web (SVA-Web)
• Casos de uso
• Credenciales de acceso para las pruebas (Ej: usuario/contraseña, certificado digital, etc)

• Informe resultados Accesibilidad
• Alta de "No conformidades" detectadas durante la verificación de accesibilidad en JIRA. En las NC estarán adjuntas las evidencias correspondientes.

La usabilidad persigue que la experiencia del usuario sea lo más satisfactoria posible al interactuar con un producto o servicio, en nuestro caso una web o una aplicación.

La usabilidad es una cualidad abstracta que no puede ser medida directamente y es difícilmente cuantificable. Por ello, se descompone habitualmente en “atributos” que si pueden ser medidos utilizando las denominadas “pruebas de usabilidad”, las cuales se aplican sobre el producto software para determinar si es o no usable.

Por tanto, aunque en primera instancia pueda parecer que la experiencia de usuario, y por tanto la usabilidad, son conceptos meramente subjetivos, existen pruebas empíricas para su medición. En el caso de una web o aplicación digital, podemos medir los objetivos de usabilidad en términos de eficacia, eficiencia y satisfacción:

• Eficacia. El usuario logra lo que quiere. Se mide en función del número de errores que comete en el proceso.
• Eficiencia. Lo logra sin esfuerzo. Se mide en función del tiempo y clics empleados en el proceso.
• Satisfacción. La experiencia le reporta satisfacción. Se mide de forma subjetiva a través de preguntas al usuario y será relativa, ya que dependerá de los objetivos planteados y de su comparación con otras experiencias similares.

El responsable del producto deberá realizar la petición al menos un mes antes de la fecha prevista para el comienzo de las pruebas y deberá incluir la siguiente información:

• Entorno 
• Casos de uso
• Credenciales de acceso para las pruebas

• Identificación entorno a probar
• Casos de uso

• Informe resultados Usabilidad

Este servicio tiene como objetivo:

• Coordinación de los diferentes actores intervinientes durante el lanzamiento de las pruebas de carga de Sistemas.
• Revisión del plan de pruebas previa a la ejecución.
• Revisión de los resultados tras la ejecución de las pruebas, incorporando nuestras conclusiones al informe.

Este servicio se presta bajo petición expresa por parte de un usuario autorizado.

La petición se ha de realizar al menos un mes de antelación a la fecha prevista de inicio de las pruebas y a de incluir la siguiente información: 

• Planificación detallada por tipo de prueba a realizar (se puede hacer referencia al apartado planificación del PPS). Debe incluir las pruebas de alta disponibilidad (sostenidas con tolerancia a fallos).
• Horario en el que se realizarán las pruebas
• Nº de máquinas lanzadoras (controladora + agentes).
• Usuario DMSAS que realizará las pruebas.
• Software y versión necesario para realizar la pruebas.
• Aplicaciones afectadas, es necesario indicar las integraciones con aplicaciones que se realizan durante las pruebas. 
• PPS, adjuntar el plan de pruebas de carga de sistemas actualizado.

• Petición reserva de máquinas
• Plan de pruebas rendimiento (PPS)

• Gestión reserva de las máquinas
• Análisis de los resultados de las pruebas realizadas