2 - Plan de Calidad
0. Historial de Cambios
|
Versión Documento |
Fecha |
Autor |
Descripción |
|
1.0 |
21/11/2022 |
Encargado de Calidad |
Primera Versión |
|
|
|
|
|
|
|
|
|
|
1. Gestión
A continuación se detalla todo en cuanto a la composición, organización y roles del equipo de trabajo asignado al proyecto actual.
1.1. Organización
El equipo estará organizado como se muestra en la siguiente tabla que muestra las asignaciones de tiempo para cada integrante.
|
Tareas |
Rol |
Dedicación |
|
Comunicador, responsable, planificador, motivador, moderador |
Gerente del proyecto |
Part time |
|
Controlador; conocimiento del estado actual de la configuración del software, sus actualizaciones y problemas. |
Encargado de calidad y SCM |
Part time |
|
Planificador y organización del equipo de testing |
Encargado de testing |
Part time |
|
Diseñador de la arquitectura, define los patrones de diseño |
Arquitecto de software |
Part time |
|
Interpretador y desarrollador del sistema |
Desarrollador |
Full time |
|
Probador |
Tester |
Full time |
El Gerente del Proyecto es quien cuenta con la mayor prioridad en sus decisiones respecto al resto de los integrantes, quienes deberán acatar sus lineamientos.
El encargado de calidad también deberá hacer cumplir sus decisiones y así como también revisar el trabajo por el resto del equipo; en caso de encontrar inconsistencias en la implementación de metodologías como desviaciones a los requerimientos, deberá solicitar tanto a desarrolladores como al encargado de testing su resolución.
El encargado de testing tendrá un equipo de testers con el cuál planificará y organizará, velando porque se cumplan sus indicaciones.
El arquitecto de software tendrá mayor interacción con los desarrolladores aunque sin responsables directos.
Los desarrolladores tampoco tendrán personas a su cargo, sin embargo, puede darse cierta jerarquía en la cual un programador dado su expertise dirija o haga de referente del resto.
1.2. Roles y responsabilidades
Detalle estructural y los respectivos roles:
|
Rol |
Responsabilidad |
|
Gerente de Proyecto |
Encargado de gerenciar el proyecto, negociaciones con el cliente, así como la confección de cronogramas y documentación pertinente. Así como también deberá dirigir el equipo de proyecto para su mejor funcionamiento.
|
|
Encargado de calidad y SCM |
Identificar, controlar, auditar e informar de las modificaciones al software que pudieran surgur a lo largo de todo el proceso. Contribuyendo a optimizar el trabajo en equipo del grupo de desarrolladores para lograr un mejor resultado para todos. Además, al ser encargado de calidad, deberá dedicarse a controlar tanto la calidad del proceso de desarrollo como la del producto resultante. Controlando la correcta aplicación de las metodologías y estándares acordados.
|
|
Encargado de testing |
Planificar y organizar al equipo de testers haciendo posible cumplir todos los planes de pruebas.
|
|
Arquitecto de software |
Diseñar el modelo arquitectónico del sistema y encargarse de sus modificaciones en caso de que surgieran. Así como también documentar dicho diseño arquitectónico.
|
|
Desarrollador |
Pasar a código fuente los requerimientos. Adecuándose al estilo y notación establecidos como estándares del proyecto. También estará encargado de la documentación técnica que facilite a los otros desarrolladores la comprensión del funcionamiento del sistema.
|
|
Tester |
Cumplir con los planes de pruebas confeccionados, así como también confeccionar la documentación del proceso de testing.
|
1.3. Tareas
El Investigador Principal y Gestor del proyecto es responsable de las tareas de aseguramiento de la calidad generales del proyecto, que se describen con más detalle en las siguientes subsecciones.
Una semana antes de cada liberación se realizará una presentación de los requerimientos y/o módulos que serán liberados para contar de forma temprana con un feedback del cliente.
Cada 15 días aproximadamente tendrán lugar reuniones con el cliente para conocer su opinión o grado de conformidad con respecto al avance del proyecto, así como también tratar de establecer prioridades para el resto del proceso.
Las etapas del proyecto que se tomarán en cuenta son las relacionadas a los requerimientos, análisis, diseño, implementación y verificación. En las dos primeras se trabajará en la especificación de los requerimientos, alcance, casos de uso y especificaciones de interfaces gráficas.
En cuanto al diseño, se revisará la descripción de la arquitectura establecida, así como también el diagrama de diseño confeccionado.
Por último, en la sección de implementación y validación, se revisará el Plan de Verificación y Validación creado. También se utilizarán métricas que ofrezcan una perspectiva de tamaño al sistema creado.
De igual modo cuenta por relevante importancia la revisión del Plan de Configuración de SCM así como también los avances logrados en cada una de las iteraciones.
Las actividades para realizar son las siguientes:
- Revisar cada producto
- Revisiones Técnicas Formales (RTF)
- Aseguramiento de documentación de las desviaciones en cuanto a metodologías y especificaciones.
En las actividades mencionadas se incluirán los siguientes puntos:
- Evaluaciones
- Estándares a aplicar
- Detalle de productos para revisión
- Especificación de procedimientos para la elaboración de los productos
- Especificación de procedimientos para informar defectos encontrados y su correspondiente mecanismo de corrección.
Revisar cada producto
Actividad relacionada al encargado del SQA la cual se realiza en las fases de elaboración y construcción. En ella, se revisarán los productos especificados como importantes en el Plan de SQA verificando que no haya quedado ninguna corrección sin resolver de las documentadas anteriormente. También se controla la correctitud del producto ante los estándares especificados así como también las desviaciones mencionadas anteriormente. Como resultado se confecciona un Informe de revisión el cual contiene las puntualizaciones realizadas, que luego será distribuido a los responsables del producto.
Revisiones Técnicas Formales (RFT)
Se realizan con el objetivo de encontrar errores/desviaciones de forma temprana a la implementación del producto. También se verificará el cumplimiento de los estándares, los requerimientos, y se puntualizarán las desviaciones que salgan a la luz.
Sus participantes son el responsable del SQA e integrantes del equipo de desarrollo (no todos). Se convoca a la reunión a los involucrados, se informa del material que deben preparar, junto a una lista de preguntas y dudas que surgen del estudio del producto a ser revisado. La duración de la reunión no debe ser mayor una hora u hora y media.
Como salida se obtiene el Informe de RTF.
Asegurar que las desviaciones son documentadas
Las desviaciones encontradas en las actividades y en los productos deben ser documentadas y ser manejadas de acuerdo a un procedimiento establecido.
Los responsables de cada plan, son los encargados de mantener actualizados, dichos informes conforme a las desviaciones encontradas.
|
Actividad |
Semana en que se realiza |
|
Elaboración del Plan de SQA |
1, 2 y 3 |
|
Verificación y ajuste del Plan de SQA |
4 y 5 |
|
Revisar productos (en cada iteración) |
6, 7, 14, 15, 19, 20 |
|
RTFs |
2, 6, 10, 14, 16, 20 |
|
Realizar informe final de calidad |
24 |
1.4. Recursos estimados
Para las actividades de QA será necesario un encargado de calidad y SCM junto a un encargado de testing. Por su parte los desarrolladores y testers colaborarán con dicho plan, estando en contacto permanente con los encargados del plan de calidad, brindando la información necesaria para cumplir con lo que se disponga por éstos últimos.
2. Documentación
2.1. Propósito
Identificar la documentación mínima establecida para todo el ciclo de vida del proyecto, acatando lo establecido por las normas utilizadas.
2.2. Especificación de Requerimientos del Software (SRS)
En este documento se presenta una descripción completa del sistema que se va a desarrollar. Se deberán especificar de forma clara todas las funcionalidades que deberá tener el producto así como también sus cualidades. Es escrito en lenguaje informal dado que debe ser entendible tanto por el equipo de desarrollo como por el cliente, teniendo que ser validado por ambas partes luego de un ida y vuelta de correcciones. Se trata de un documento de suma importancia dado que es el comprobante de cuál es el alcance que tendrá el proyecto y sirve como contrato para ambas partes.
Dentro de las características que debe tener se encuentran las siguientes:
- Consistente, no debe tener contradicciones en distintas partes del documento
- No ambiguo, no debe dar lugar a diferentes interpretaciones de los requerimientos
- Funcional, debe indicar que es lo que se necesita que el sistema haga sin tener en cuenta como re implementará.
- Verificable, se debe comprobar que los requerimientos cumplen con las necesidades del cliente
- Fácilmente modificable, que no afecte la redacción del resto de los requerimientos en caso de ser modificado uno de ellos.
Se incluirán en él también las cualidades deseadas del software,
tales como usabilidad, eficiencia, interoperabilidad, etc.
2.3. Descripción del Diseño del Software (SDD)
Se trata de un documento en donde se describe como el sistema podrá satisfacer los requisitos de la SRD. Debe contener, partiendo del diseño arquitectónico, los componentes y subcomponentes del diseño, incluyendo bases de datos internas y externas. Contendrá de los mismos, detalles algorítmicos, la representación de datos, y el empaquetamiento del producto en la programación. A medida que se van realizando distintas etapas de análisis, dicho documento se va modificando hasta lograr un diseño detallado.
El principal objetivo de describir en detalle el diseño de software y dejarlo plasmado en un documento se reduce a intentar prevenir los defectos antes de que ocurran.
2.4. Plan de Verificación y Validación (SVVP)
Se trata de un documento que sirve para determinar que los requisitos del cliente han sido implementados correctamente. En él, se describirán los procedimientos a utilizar para la verificación y validación del software.
La verificación involucra por ejemplo, la satisfacción de los requisitos funcionales y no funcionales; que el software este de acuerdo con su especificación, garantizando la consistencia entre ambas cosas; etc.
Por otro lado la validación corresponde, por ejemplo, a si los requisitos y pruebas durante la etapa de desarrollo satisfacen las expectativas del cliente; se garantiza que el software final satisfaga los requisitos del sistema; etc.
En concreto debería contener los siguientes puntos: Especificación del diseño de pruebas, especificación del caso de prueba, especificación de los procedimientos de prueba, plan de pruebas, documento de anomalías y documento final de pruebas.
2.5. Informe de Verificación y Validación (SVVR)
En este documento se describirán tanto los resultados de las actividades de la verificación del software (de acuerdo al plan de verificación), así como también los resultados de la prueba del software (de acuerdo al plan de validación).
2.6. Documentación del usuario
Este documento contendrá una descripción de los controles de entradas de datos existentes, tipos de datos, secuencias de entrada, opciones, limitaciones, y toda otra información referida al programa y que le sea de interés al usuario final.
Es un documento que le es entregado al cliente al finalizar el producto.
2.7. Plan de Gestión de Configuración del Software (SCMP)
Se deberá especificar en este documento las tareas y formas en que se llevarán a cabo, responsables de las mismas, calendario de eventos y que recursos se utilizan.
3. Estándares,
Prácticas y Convenciones
3.1. Propósito
Se busca identificar y detallar los estándares, prácticas y convenciones que nos comprometemos a aplicar y respetar en cada fase del proyecto.
3.2. Contenido
Se ha definido que todos los documentos del proyecto cuenten con el siguiente formato:
Encabezado de página con el nombre de la empresa desarrolladora y del proyecto en Calibri 11.
Pie de página con nombre del documento y número de página en Calibri 11.
Carátulas con el título del documento en letra Negrita Calibri tamaño 48.
Habrá un apartado Historial de Cambios detallando Versión, Fecha, Autor y Descripción.
Los títulos se deberán escribir en Calibri, en negrita, tamaño 16.
Los subtítulos se deberán escribir en Calibri, en negrita, tamaño 14.
Los párrafos se deberán escribir en Calibri, tamaño 11.
En lo que respecta a los diagramas Análisis y Diseño, se seguirá la especificación UML.
Se utilizarán los siguientes patrones de Diseño:
Facade: para establecer la separación entre las capas que compondrán el sistema.
Value Objects: para resolver la transferencia de información entre la capa gráfica y la capa lógica.
MVC: para desacoplar la presentación de la información del procesamiento y la transferencia de los datos.
Puesto que la implementación se realizará mediante páginas JSP y Servlets, se seguirán los estándares de programación y codificación de Java: http://javafoundations.blogspot.com/2010/07/java-estandares-de-programacion.html
Para el Testing se seguirán los lineamientos del estándar IEEE/ISO/IEC 29119-2-2021
dedicado a brindar guías, documentos y buenas prácticas de convención mundial para el testing a lo largo del ciclo de vida del software.
Puede ser referenciado a través de:
https://standards.ieee.org/ieee/29119-2/7498/
Métrica de Tamaño del software: LDC
Métrica de calidad del software: Índice de Errores por Face e Índice de Errores (global)
GCO (Grado de cohesión de objectos)
Métrica de McCabe
Métrica del Proceso: se realizará seguimiento del avance del proyecto evaluando el porcentaje de requerimentos cumplidos sobre el total de requerimentos a realizar (100%).
3.3. Monitoreo de Cumplimiento
Se harán inspecciones de la documentación generada para asegurar el cumplimiento de los estándares establecidos en este punto del Plan de Calidad. Así mismo, se prevén inspecciones, auditorías y revisiones en todas las fases del ciclo de vida del software para todos los productos del proyecto: diagramas, módulos, etc. De esta forma, se evaluará continuamente el cumplimiento de los estándares; y como resultado y registro, se tendrán los productos de dichas actividades.
Informe RTF (para revisiones técnicas formales)
Documentos de resultado de Auditorías
Documentos de resultado de Inspecciones
4. Revisiones y Auditorías
Las revisiones y auditorías serán realizadas tomando como referencia el standard 730-2002. A continuación, las revisiones y auditorías a ser llevadas a cabo.
4.1. Revisiones
Esta revisión tiene como objetivo confirmar que el software desarrollado, concuerda con lo establecido en el documento de definición de requerimientos. Esta revisión deberá llevarse a cabo al final del desarrollo de cada funcionalidad establecida como requerimiento.
El objetivo de esta revisión, es muy similar a la especificada anteriormente, pero con fines meramente técnicos. Sirve para comprobar que la arquitectura definida en la especificación, se respetó en lo que se implementó. Esta revisión sería llevada a cabo en las mismas instancias que la Revisión de Especificación de Software.
Esta revisión apunta a confirmar la adecuación del plan de testing establecido para el software que desea desarrollarse. Contempla aspectos como:
· La correcta definición de los casos de uso a considerarse.
· La correcta definición de las pruebas que desean realizarse.
· Que la información necesaria para las pruebas, se encuentre disponible.
Son una serie de revisiones que apuntan a los aspectos no tan técnicos como en los casos anteriores. Sino a establecer la efectividad de aquellos que se encuentran a cargo de la parte gerencial que forma parte del proyecto de desarrollo. Estas instancias sirven entre otras cosas, para verificar el apego que se dio a las estimaciones definidas en primera instancia.
Esta revisión se encarga de comprobar que todo aquello necesario para el proceso de desarrollo, en materia de adecuación de los equipos y servidores a utilizarse, información para pruebas, etc. haya estado disponible en el momento que se estableció en el plan. Se realiza previo al comienzo de cada iteración y permite en caso de falta de información o cualquier otro inconveniente vinculado a la infraestructura necesaria, tomar las medidas necesarias para que la etapa pueda desarrollarse con normalidad.
Esta revisión, tal como su nombre lo indica se realiza luego de entregado el proyecto y lo que hace es tomar lo que se desarrolló en relación a lo esperado y definir a grandes rasgos si se alcanzó lo planeado.
4.2. Auditorías
Estos tres tipos de auditorías, serán seguidos tal como se especifica en el estándar mencionado al principio del documento.
Para las auditorías “In-Process”:
· Código contra documentación del diseño.
· Especificaciones de interfase (hardware y software).
· Implementación del diseño contra requerimientos funcionales.
· Requerimientos funcionales contra descripciones de los tests.
Las auditorías funcionales y físicas, serán realizadas al final de cada iteración.
5.Herramientas, Técnicas y Metodologías
En esta sección identificaremos las herramientas especiales de software, técnicas y metodologías de soporte con el fin de lograr un software confiable, mantenible, fácil de probar y al mismo tiempo mejorar la productividad de desarrollo y control de la calidad.
5.1.Herramientas
- Bugzilla (http://www.bugzilla.org/) que es una herramienta para el seguimiento y organización de errores para múltiples productos y diferente versionado de los mismos. Permite categorizar dichos errores de acuerdo a su prioridad y severidad, así como asignarles versiones para su solución, anexar comentarios, asignar responsables para solucionarlos, enviar correos electrónicos a los interesados del mismo, etc.
-
GitLab (https://about.gitlab.com/ ) que es un
sistema de control de versiones multiplataforma para desarrollo de gran
rendimiento y escalabilidad, posee buenas capacidades de integración, etc.
Resulta ideal para el modelo de proceso elegido, ya que se pueden ir entregando
diferentes incrementos sin necesidad de compartir todo lo que se está
desarrollando, tiene buen control sobre el histórico de las tareas realizadas y
es bueno para el control de cambios. También puede utilizarse como repositorio
de la documentación.
- Eclipse Metrics Plugin que calcula varias métricas del código durante los ciclos de compilación, advirtiendo mediante una vista el rango de “violación” para cada una de dichas métricas. Esto permite tener un estado continuamente actualizado del estado del código. También permite exportarlas para futuros análisis.
- Open Workbench que es una aplicación gratuita de gestión y planificación de proyectos. Es un equivalente libre de Microsoft Project que permite definir el ciclo de vida del proyecto, realizar una división de las actividades con tareas e hitos y también realizar un diagrama de Gantt del proyecto.
5.2.Técnicas
Se sugieren las siguientes técnicas a utilizar para el aseguramiento de calidad:
Revisiones de código: Se practica con el objetivo de mejorar la calidad del código que se genera en el proceso de desarrollo del software, mediante la detección temprana de errores en el código de los programas. También se utiliza como técnica para mejorar las cualidades de los desarrolladores involucrados en la práctica, mediante la discusión abierta de posibles mejoras en el programa.
Repositorios compartidos: se contará
con un repositorio único de código y documentación.
Un repositorio centralizado debe tener, al menos, funcionalidades
para poder actualizar código fuente de más de un origen y dar marcha atrás en
caso de necesitarlo, hacia cualquier versión anterior. Estas funcionalidades se
encuentran en
la herramienta GitLab mencionada en la sección de Herramientas a utilizar.
Refactorización: con de la
refactorización se busca mejorar el diseño de parte de un sistema que ya está
funcionando.
Las mismas son riesgosas, debido a que se está cambiando código que sabemos que
funciona por otro que, aunque presumimos será de mejor calidad, no sabemos si
funcionará correctamente.
Esto se suele hacer por las siguientes razones:
- Mejorar código, haciéndolo más comprensible y legible.
- Eliminar duplicaciones de código o de comportamiento, para que cada cambio afecte una sola porción de código.
- Mantener alta la calidad del diseño.
Integración continua: Consiste en hacer integraciones automáticas de un proyecto lo más a menudo posible para así poder detectar fallos cuanto antes.
Optimización: Es el proceso de modificación de un software para hacer que algún aspecto del mismo funcione de manera más eficiente y/o utilizar menos recursos.
5.3. Metodologías
Al
utilizarse un modelo de proceso iterativo e incremental entenderemos a las
iteraciones como mini proyectos ya que en cada una de estas se repetirá un
proceso de trabajo similar (de ahí el nombre iterativo). De esta forma se proporcionará un resultado completo
sobre el producto final donde el cliente podrá obtener los beneficios del
proyecto de forma incremental.
Para ello, cada requerimiento se debe completar en una única iteración donde el
equipo realizará todas las tareas necesarias para completarla lo cual incluye
el análisis, diseño, implementación y pruebas de cada uno de estos. De
esta manera no se deja para el final del proyecto actividades que puedan
resultar arriesgadas.
6. Gestión de configuración (plan de SCM) y control de código
6.1. Introducción
Se describirán las actividades de gestión
de configuración de software llevadas a cabo durante el proceso de desarrollo
del proyecto.
Aquí se definirán los productos bajo control de configuración como los
procedimientos que deben seguirse por los integrantes del equipo de trabajo.
El tiempo de duración del proyecto es de 6 meses y lo ideal sería poder tener una rápida respuesta a los cambios dentro de lo posible para evitar correr riesgos.
El modelo de proceso elegido es iterativo e incremental y para el mismo lo ideal es tener un buen control sobre cada iteración y los productos que se generan en base a esta, en conjunto con los posibles cambios que puedan surgir.
Para la buena gestión de configuración se deben incluir la mayor cantidad de iteraciones posibles, teniendo en cuenta la duración del proyecto y la capacidad organizativa del equipo.
Se debe identificar todas las líneas de trabajo que participen o sean responsables de actividades de SCM.
6.2. Responsable
Las actividades que deberá realizar el encargado de SCM son las siguientes:
- Identificar los elementos de configuración, estableciendo la línea base para el proyecto.
- Brindar el entorno de configuración junto con la infraestructura para el proyecto.
- Debe encargarse de que todos los integrantes del equipo entiendan y puedan llevar a cabo las actividades de SCM, controlar versionado y cambios.
- Fijar una nomenclatura para identificar y ubicar los elementos de configuración.
- Llevar a cabo el control de la configuración, establecer estándares y metodologías a seguir respecto a cambios para poder tener un control sobre los mismos.
- Brindar reportes sobre el estado de configuración mediante el seguimiento del histórico de revisiones y liberaciones.
-
Realizar
auditorías para verificar que el software en desarrollo sea consistente.
6.3. Elementos de la gestión y configuración de software
Los elementos de configuración coincidirán con los entregables definidos en el modelo de proceso elegido. De todos modos, no todos los entregables pueden llegar a ser elementos de configuración siendo esto decisión del encargado de SCM.
6.4. Control de versiones
Con el tiempo, se van obteniendo
diferentes versiones del software que se está desarrollando y resulta necesario
que haya una forma organizada de gestionar dichas versiones a través de los
cambios que ocurran en este.
Un componente es etiquetado e identificado para diferenciarlo de los demás
componentes en las versiones del software.
Cuando es modificado, las versiones anteriores y las nuevas se pueden
identificar individualmente y de esta forma tener un historial de sus
diferentes componentes así como un respaldo que permita regresar a versiones
anteriores. Todas estas funcionalidades las ofrece la herramienta GitHub mencionada
en la sección de Herramientas a utilizar.
6.5. Gestión de cambios
En esta sección se detallan las
actividades de solicitud, evaluación, aprobación e implementación de cambios
que apuntarán tanto a la mejora como corrección del software.
A continuación se detalla el proceso que se utilizará cada vez que se precise
introducir un cambio en el sistema:
- Cambios en los requerimientos.
- Cambios en el diseño.
- Cambios de arquitectura.
- Cambios en las herramientas de desarrollo.
- Cambios en la documentación del proyecto, ya sea agregar documentos o modificar los existentes.
Comentarios
Publicar un comentario