debe ser validada antes de su subida a Producción, tanto por parte del Responsable funcional como en muchos casos por parte de la Oficina de Calidad. Cualquier fallo o defecto detectado pasa a registrarse como una No Conformidad (ver proceso de Gestión de No Conformidades), que deberá ser solucionada por el Proveedor, y que, como hemos comentado antes, puede formar parte del alcance de una versión. De cara a la entrega de la NC en el repositorio, el flujo de Gitflow funciona igual que se ha indicado en las mejoras. Hay dos tipos de órdenes de trabajo: - Órdenes de trabajo con crédito disponible: el Responsable de Producto es quien determina el techo de coste o esfuerzo en HBS requerido para la orden. El Proveedor se limita a, teniendo ese techo de coste asignado, planificar las fechas en las que va a hacer el trabajo. Hay diferentes tipos de órdenes de trabajo con crédito disponible:
- OTEVS (Estudio de viabilidad del sistema). Son las únicas órdenes de trabajo que pueden crearse con la versión sin haber comenzado, incluso pueden crearse para más de una versión. Sus incurridos no se tienen en cuenta en el cómputo de las HBS de la versión.
- OTR (Requisitos)
- OTInmediata
- OTEquipo (para equipos dedicados que trabajan con esta metodología)
- PST (Petición soporte Transición): son peticiones de ayuda del área de Proyectos al Proveedor de sistemas
- Órdenes de trabajo con estimación: como su propio nombre indica, es necesario que el Proveedor estime el coste/esfuerzo de la orden y que planifique las fechas en las que podrá ser realizada. Esa estimación deberá ser aprobada por el Responsable de producto, y será realizada por el Proveedor tantas veces hasta que sea finalmente aprobada. Hay diferentes tipos de órdenes de trabajo con estimación:
- OTA (Análisis)
- OTD (Diseño)
- OTC (Construcción)
- OTAD (Análisis y diseño)
- OTADC (Análisis, diseño y construcción)
- OTImpl (Implantación)
El Responsable de producto puede además solicitar servicios a la Oficina de Calidad asociados a esa versión. Estos servicios son: - Servicios de Testing Temprano (STT):
Revisión de la documentación aportada en las fases ASI y DSI. Se verifican casos de uso, actores, subsistemas, requisitos, precondiciones, casos de pruebas y la trazabilidad entre ellos. Se valida que tanto en el análisis como en el diseño se cumpla la normativa específica de la organización, así como mantener una trazabilidad completa en el modelo propuesto.
La petición debe hacerse por parte del Responsable de producto al menos un mes antes de la fecha prevista para el comienzo de las pruebas 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 para una revisión final y completa: Entrada: Salidas: - Informe sobre la evaluación del testing temprano.
- Alta de "No conformidades" y propuestas de mejoras detectadas durante la revisión.
- Servicio de Verificación de entregas (SVE)
Una vez que se haya finalizado la construcción de las mejoras y llegue el momento de desplegar en un entorno, habrá que tener en cuenta si es la primera versión del producto que se va a desplegar. En este caso, habrá sido necesario construir la plataforma en la que se va a hacer el despliegue. (Ver Proceso de Gestión de plataformas ). Una vez que la plataforma o plataformas en las que hay que realizar el despliegue están construidas, es necesario hacer la petición de lanzamiento para el despliegue en esas plataformas y en los entornos en los que se quiera implantar la versión del producto. (Ver Proceso de Gestión de lanzamientos). Mediante este servicio, se garantiza el cumplimiento de la normativa de entregas publicada por el Área de Gobernanza, así como la calidad del código del producto. Este servicio es absolutamente necesario para poder gestionar el lanzamiento de una versión a menos de que se trate de un lanzamiento urgente (PLU), en cuyo caso el servicio de la OCA podrá hacerse con posterioridad al lanzamiento. 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.
Entradas: Salida: - Informe sobre la revisión, aceptación o rechazo de la entrega.
- Servicio de validación funcional (SVF)
Esta validación 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 de 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
- URLs de las aplicaciones afectadas
- Alcance
- Plan de pruebas (EA o GIT)
- Credenciales de acceso y juego de datos para la ejecución de las pruebas
Entradas: - 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
Salidas: - 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.
- Servicio de validación de la accesibilidad (SVA)
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 de 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.
Entradas: 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)
Salidas: - Informe resultados Accesibilidad
- Alta de "No conformidades" detectadas durante la verificación de accesibilidad. En ellas estarán adjuntas las evidencias correspondientes. En el caso de realizar el servicio en el entorno de PRO, sólo se dará el informe de resultados para que sea el Responsable de producto quien registre las incidencias o mejoras oportunas.
- Servicio de validación de la usabilidad (SVU)
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 de 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
Entradas: - Identificación entorno a probar
- Casos de uso
Salidas: - Informe resultados usabilidad
- Servicio de pruebas dinámicas de seguridad (SPSD)
Es una vía paralela para la detección de vulnerabilidades de seguridad que ya hace la USTIC mediante la evaluación de seguridad correspondiente.
En Servicios de la OCA se muestran videos de sesiones formativas para estos servicios.
Cuando se hayan hecho todas las posibles implantaciones para una versión, es el Responsable de producto quien considera que la versión está implantada, lo que supondrá la implantación de todas las mejoras, incidencias y no conformidades que constituían el alcance de la versión. Esto no implica que la versión se pueda finalizar, puesto que es posible que queden órdenes de trabajo sin acabar o incluso que fuera necesaria la creación de una orden de trabajo para que el proveedor impartiera formación. Una vez que todas las órdenes de trabajo están cerradas, la versión se puede finalizar. La implementación de este proceso se hace en JIRA. Accediendo al enlace podrás ver el manual en el que se detallan los tipos de entidades, los estados y las acciones por estado, así como los roles que pueden ejecutarlas. El proceso de Gestión de productos está ligado al de Gestión del conocimiento, ya que el Responsable de producto debe velar porque todo el conocimiento asociado a su producto sea: - Centralizado en un único sitio.
- Accesible para todo el que lo necesite con una fácil gestión de acceso.
- Usado como gestor documental para los entregables de las órdenes de trabajo que acomete el proveedor.
- Estructurado de modo similar en todos los productos.
- Integrado con la herramienta en la que se gestiona el producto.
La gestión del conocimiento se hace mediante espacios en CONFLUENCE, de modo que cualquier producto siempre va a tener asociado un espacio en el que se custodie toda la información que afecte a su producto y del que el Responsable de producto va a ser administrador. Todos los espacios tendrán una misma estructura y cada vez que se cree una versión del producto se creará una página dentro del espacio que se actualiza automáticamente con la información de JIRA, estructurada con la información de gestión (OTs de la versión y calendario), alcance y entregables. Cualquier otra información relacionada con la versión se podrá incluir en esa página. Además, el uso de esta herramienta de gestión de conocimiento permitirá: - Fomentar el trabajo en equipo en el espacio con posibilidad de edición en línea.
- Estandarizar la entrega de los entregables de las órdenes de trabajo.
- Tener un histórico de versiones de la documentación.
- En el futuro permitirá sustituir los “documentos” por páginas.
- Fomentar la comunicación en base a notificaciones “@usuario”.
Comunicación de los cambios (Changelog de aplicaciones): puedes ver una guía para saber cómo publicar las novedades de tu producto aquí. | 
