Seguidamente detallaremos las políticas de Calidad de Asepeyo. Los quality gates o puntos que deben cumplir los proyectos en cada uno de los hitos, antes de un despliegue a los distintos entornos. Se tiene el enlace donde se encuentran las plantillas de la documentación que debe ser utilizada como estándar en cada punto del proyecto y partir de un requerimiento bien definido, justificado y aceptado.

Descripción de los documentos requeridos

• Modelo de Valoración : Documento donde se valora el coste que va tener el desarrollo del proyecto, en término de horas
• Acuerdos de Calidad : Documento donde se valora el coste que va tener el desarrollo del proyecto, en término de horas
• Diseño Funcional: Documento que detalla las especificaciones del requerimiento, detalla las capacidades, la apariencia y las interacciones previstas con los usuarios.
• Diseño de Arquitectura: Documento que describe las especificaciones no funcionales
• Calendario de Versiones: Registra el historial de las versiones, el control de los cambios.
• Diseño Técnico: Si el Diseño Funcional describe el qué, el Diseño Técnico describe el cómo. Tiene que ver con los aspectos técnicos y la implementación del diseño conceptual y cómo se coordinan los módulos, la interfaz y la base de datos.
• Juego de Pruebas Funcionales: Documento que registra los casos de prueba que verifican que el sistema satisface los requisitos especificados
• Resultado de las Pruebas en Integración Documento que recoge las evidencias de las pruebas realizadas
• Manual de Usuario, Administración y Operación: Documentos de guía para el usuario final sobre el funcionamiento de los aplicativos y solución de problemas comunes
  

Quality Gate

Se define como puntos de control de que el trabajo apropiado requerido para hacer avanzar los productos a las actividades subsiguientes del proyecto ha sido completado y revisado

Las Quality Gates son la mejor forma para cumplir las políticas de calidad. Para facilitar el cumplimiento de estas políticas únicamente se deberá responder a una pregunta: ¿puedo entregar mi proyecto en producción? Para responder esta pregunta hemos definido un conjunto de condiciones booleanas.

GitLab

GitLab es un repositorio de gestión de proyectos y, como se puede deducir desde el nombre, está construido sobre Git. Es decir, proporciona el código para generar un servidor y gestionar los clientes, sus operaciones y los servicios que ofrece.

A través de GitLab puedes administrar grupos, personas y los permisos que quieras que tengan los usuarios dentro de los grupos o proyectos a los que pertenezcan.

También, te permite llevar a cabo un seguimiento del estado actual y del histórico de los proyectos, logrando ver todos los cambios y modificaciones producidas en el tiempo de desarrollo.

Modelo de Valoración

El Modelo de valoración es un documento que nos permite tener un aproximado del coste en horas del desarrollo por cada detalle y tener un total horas del desarrollo.

El proveedor realizará un Estudio Previo que dará como resultado una valoración de acuerdo al estándar de Asepeyo

Fase Inicial

Partimos de una necesidad, se realiza la solicitud del requerimiento rellenando el formulario, una vez aprobada la solicitud, antes de empezar el desarrollo se debe tener la siguiente documentación que debemos tener antes de iniciar el desarrollo:

• modelo de valoración
• acuerdos de calidad

Fase Ejecución

Es la fase del desarrollo del proyecto, normalmente se cuenta con distintos proyectos. Normalmente se tienen los entornos de Integración, Preproducción, UAT y Producción. Pueda darse el caso que no se tenga el entorno de Preproducción, entonces las condiciones de quality gate que se debe cumplir antes de subir a Preproducción debe ser asumida por las condiciones de quality gate que se debe cumplir antes de subir a UAT

Nueva solución o evolutivo

Antes de cada subida a los entornos, Integración, Preproducción, UAT y Producción. Antes de promocionar el código a cada entorno debe cumplir con cada punto de control o quality gate. Si no se tiene el entorno de UAT, las condiciones de la quality gate 3, son asumidas por la quality gate 4. A continuación mostramos un cuadro que muestra los puntos a cumplir antes de subir el código a cada entorno

Correctivo

Antes de cada subida a los entornos de un correctivo, cada entorno debe cumplir con cada punto de control o quality gate.

Roles y Responsabilidades

El cuadro presenta los roles del Project Manager (PM), el Funcional, el arquitecto, el release manager el qa por parte de Asepeyo y del proveedor. La parte pintada de celeste son los roles por parte de Asepeyo

• • Project Manager es la persona responsable del inicio, la planificación, el diseño, el seguimiento, el control y el cierre exitosos de un proyecto. Por parte del proveedor es el responsable del plan de calidad, los resultados de las pruebas funcionales y no funcionales y la subida a los distintos entornos
  • Funcional : es la persona encargada de definir los requerimientos. Por parte del proveedor es el responsable del desarrollo del diseño funcional, el juego de pruebas y el manual de usuario.
  • Arquitecto : es la persona encargada de la arquitectura, las directrices, principios y desarrollo de los aspectos técnicos de un proyecto de software. Por parte del proveedor es el responsable del diseño de arquitectura, el juego de pruebas no funcionales y el manual de instalación.
  • Release Manager : es el responsable del ciclo de vida de la administración de versiones, centrándose en coordinar varios aspectos de la producción y los proyectos en una solución integrada. Por parte del proveedor es el encargado que el código se encuentre en el GIT y su revisión, que cumpla los estándares Asepeyo
  • QA : Es la persona responsable de asegurar la calidad. Por parte del proveedor es el responsable del plan de calidad, el juego de pruebas funcionales y no funcionales. Trabaja en conjunto con el project manager, el funcional y el arquitecto
  • Usuario: Es la persona que utilizará la aplicación, es el responsable de las pruebas en producción.