Aseguramiento de calidad

Para asegurar una calidad aceptable del producto y los procesos llevados a cabo en el desarrollo se ha tomado como esquema el conjunto de normas ISO 9000. El sistema de gestión de la calidad está formado por procesos y es en si mismo un proceso en el que ingresan los requisitos del sitema y se obtiene un producto que cumple los requisitos y satisface al cliente.

A continuación se describen los procesos y actividades seguidas para asegurar la calidad.

• Se implementa un ciclo de vida evolutivo en el que se examina y documenta cada decisión tomada, al final de cada iteración se comprueba la calidad del producto obtenido.
• El equipo directivo se asegura de que los requisitos del cliente se determinan y cumplen. El objetivo de esto es aumentar la satisfación del mismo.
• El equipo directivo realiza una planificación en la que se capturen las acciones a seguir para alcanzar los objetivos perseguidos.
• Los roles y responsabilides del equipo quedan definido y atribuidos en cada iteración del ciclo.
• En cada iteración se examina las pruebas de calidad realizadas, la retroalimentación del cliente y la conformidad del producto.
• En cada iteración se contemplan las mejoras del producto en relación con los requisitos y necesidades del cliente.
• Todo el personal tiene los conocimientos y el entrenamiento adecuados para realizar la tarea que en la planificación se le ha sido asignada.
• Se utilizan entrevistas periódicas con el cliente para capturá los requisos necesarios en cada iteración. Además de validar la corrección del producto obtenido
• Para la toma de requisitos se ha utilizado técnicas de objetivos medibles, de forma que los requisitos impuesto por el cliente se ven como objetivos generales. Estos son analizados repetidamente para obtener los requisos críticos para el funcionamineto del sistema. En cada iteración se refinan los requisitos generales y se plantean nuevos, aplicándose la misma técnica para determiar los tomados en la iteración.
• Se presentan modelos de caso de uso que deben ser comprendidos y validados por el cliente.
• El diseño del producto obtenido en cada iteración queda documentado mediante modelos.
• Se realiza una revisión, verificación y validación de los diseños propuestos.
• La actividad de desarrollo del producto quedará bien documentada en el propio código.
• En cada iteración se definirán los casos de pruebas, estas serán llevadas a cabo para comprobar la corrección del producto.

A continuación los criterios para la aceptación o rechazo de los productos obtenidos en cada fase del desarrollo.

• Si se detecta algún requisito ambiguo o mal especificado este queda rechazado. En este caso se deberá concertar una entrevista con el cliente.
• Para la aceptación de los requisitos estos deben ser simples y sencillos, estar bien descritos y especificados de forma atómica.
• Si se detecta un caso de uso mal explicado o confuso este será rechazado.
• Los casos de uso para su aceptación deben estar completamente explicados, de una forma esquemática y fácil de entender por el cliente. Además debe quedar bien definidos los actores involucrados y las relaciones entre estos.
• Los modelos de datos serán aceptados si son claros, completos y se encuentran bien estructurados.
• Los diseños de soluciones serán aceptados si cumple los criterios de versatilidad, adaptación, optimización y claridad impuestos.
• Si en el diseño de la gramática se da alguna ambiguedad esta deberá ser redefinida.
• Si la elección de una palabra del léxico es confusa o demasiado compleja esta deberá ser redefinida.
• Si alguna clase no cumple el principio de única resposabilidad será rechaza.
• Si alguna clase no cumple el principio abierto/cerrado será rechaza.
• Si alguna clase no cumple el principio de sustitución de Liskov será rechaza.
• Si alguna clase no cumple el principio de segregación de la interfaz será rechaza.
• Si alguna clase no cumple el principio de inversión de dependencias será rechaza.
• Si algún módulo de código fuente desarrollado no cumple las reglas de estilo este será rechazado.
• Si algún módulo de código fuente no se encuentra debidamente docuemtado será rechazado.
• Si algún módulo de código fuente no sigue el principio de reutilización será rechazado.
• Si se detecta que no se han capturados todos los casos de prueba escenciales se produce un rechazo.
• Para la aceptación se deben completar satisfactoriamente todas las pruebas unitarias.