El documento presenta el temario de un taller de gestión de software. Incluye secciones sobre el plan de aseguramiento de la calidad, contenido del plan de aseguramiento de la calidad, secciones no aplicables del estándar IEEE, modo de utilización del plan, guía para el rol de aseguramiento de la calidad, buenas prácticas, y recomendaciones para las distintas fases de un proyecto de software. También presenta ejemplos de métricas para medir diferentes atributos de calidad.
2. Taller de Gestión de Software
Temario
Plan de SQA
Contenido
Utilización
Guía para el SQA
Propósito de la guía
Propósito del rol SQA
Actividades fundamentales
Buenas prácticas
Fase Inicial
Fase Elaboración
Fase Construcción
Fase Transición
4. Taller de Gestión de Software
Contenido del SQAP
Propósito
Acrónimos y abreviaturas - agregado
Referencias
Gestión
Documentación
Estándares y métricas - Estándares,
prácticas, convenciones y métricas
5. Taller de Gestión de Software
Contenido del SQAP
Revisiones – Revisiones y auditorias
Test
Reporte de problemas y acciones
correctivas
Gestión de configuración (Control de
código, Control de medios)
Gestión de riesgos
6. Taller de Gestión de Software
Secciones que no aplican de
IEEE
12 Control de proveedores
13 Recopilación de registros,
mantenimiento y retención
14 Entrenamiento
7. Taller de Gestión de Software
Modo de utilización
Contrastar el SQAP realizado con el
SQAP propuesto.
Adoptar las modificaciones del SQAP
que resulten útiles.
9. Taller de Gestión de Software
Propósito de la guía
Soporte al rol de SQA en PIS.
Dicho soporte apunta a que las tareas realizadas en
el rol del SQA no se conviertan en meras revisiones
sintácticas de los distintos entregables, sino que sea
esencial en el éxito del proyecto.
10. Taller de Gestión de Software
Rol del SQA
Según Humphrey, el SQA debe:
monitorear métodos, prácticas y estándares aplicados por el resto del
equipo para verificar que fueron propiamente aplicados.
En PIS, se traduce a:
preparar y efectuar las distintas revisiones a los entregables de modo de
asegurar la calidad de los mismos.
seguimiento de las tareas (Humphrey: “What is not tracked is not done”)
SQA es una disciplina de soporte
Lograr un balance de forma que el SQA pueda
aportar a la calidad sin obstaculizar el proyecto
11. Taller de Gestión de Software
Buenas practicas
Riesgos (detección y seguimiento)
Asegurar que:
Sean evaluados permanentemente
Sean prevenidos, mitigados, y contenidos
Mediciones y estimaciónes
Las mediciones deben reflejar la realidad
Las estimaciones deben basarse en las
mediciones
Gestión de configuración
Asegurar que el SCM cumpla su rol:
Mantener líneas bases
12. Taller de Gestión de Software
Recomendaciones
Las actividades a revisar deben ser monitoreadas
desde su comienzo.
Comunicar al responsable del artefacto
cuando debe comenzar
que cosas se van a evaluar
Si se detectan desviaciones que impactan en el
proyecto el informe acerca de las revisiones
realizadas debe dirigirse al Administrador y Arquitecto
para que ese impacto se analice y tenga en cuenta
en los planes del proyecto
Evitar que se ignore
13. Taller de Gestión de Software
Fase Inicial
Requerimientos funcionales
Detallar (y revisar) solamente los críticos
Requerimientos no funcionales y atributos de calidad
Identificar propiedades de calidad del producto
Alineado con IS-1 y IS-2
Modelo de calidad
IS-2
Factibilidad
Alcance
Visión de Arquitectura
Planes de verificación
Prototipo
Realizar demo del mismo
Debe demostrar que mitiga los riesgos
14. Taller de Gestión de Software
Fase Inicial -
Criterios de evaluación
Acuerdo entre los involucrados sobre el
alcance y estimaciones originales
Acuerdo en que el conjunto correcto de
requerimientos ha sido capturado y hay un
entendimiento común sobre los mismos
Acuerdo en que las estimaciones,
prioridades, y riesgos son apropiados
Los riesgos han sido identificados y hay
estrategias para mitigarlos?
15. Taller de Gestión de Software
Fase Inicial –
Recomendaciones
No se deben intentar detallar todos los
requerimientos en la fase inicial.
Las estimaciones y planes realizados en la
fase inicial no se pueden considerar reales.
No se puede asumir que la arquitectura va
a ser definida en la fase inicial y tomarla
como estable en ese entonces.
Se deben elegir los casos de uso que van a
guiar la fase de elaboración
16. Taller de Gestión de Software
Fase de Elaboración
Requerimientos estables
80 % de los casos de uso detallados
Revisión de alcance
Arquitectura estable
Implementación de los casos de uso críticos
Apego al proceso
Obtener un producto funcional
Gestión del proyecto
Asegurar que el Administrador cumpla un rol activo en
la gestión.
17. Taller de Gestión de Software
Fase de Elaboración –
Criterios de evaluación
La visión y requerimientos del producto están
estables?
La arquitectura es estable?
La evaluación de los prototipos ha demostrado que los
principales elementos de riesgo han sido abordados y
resueltos?
Los planes para la fase de construcción se apoyan en
estimaciones creíbles?
Los involucrados están de acuerdo en que la visión del
producto puede ser lograda con la arquitectura y plan
actuales?
18. Taller de Gestión de Software
Fase de Elaboración–
Recomendaciones
Se deben tener productos funcionales
luego de cada iteración.
Se deben implementar los casos de uso
críticos para la arquitectura.
No se debe detallar el diseño de todo el
sistema.
Se deben modificar todos los planes según
las mediciones de esta fase.
19. Taller de Gestión de Software
Fase de Construcción
Revisión del producto
Nueva versión del producto al final de cada iteración
Funcionalidades no realizadas serán incluidas en siguiente
iteración
Presentarlo al cliente
Revisión de informes de validación
Asegurar que se realicen los informes sobre los
resultados de las validaciones con el cliente por medio
de demos.
Documentación de usuario
Completa al final de la fase.
Asegurar que se realice
20. Taller de Gestión de Software
Fase de Construcción
Revisión por pares
Asegurar que se realicen de forma efectiva para lo cual se pueden
contrastar contra los reportes de verificación
Gestión de configuración
Asegurarse que se controla la línea base.
Reportes de verificación
Asegurar que se cumplan con los planes de verificación
Que los resultados sean informados de manera inmediata
Contrastar las tasas de defectos encontrados en la distintas
fases
21. Taller de Gestión de Software
Fase de Construcción –
Criterios de evaluación
El producto es lo suficientemente estable y
maduro para ser aceptado por el usuario?
La relación del esfuerzo incurrido sobre el
planificado es aceptable?
22. Taller de Gestión de Software
Fase de Transición
Aceptación
Se debe asegurar que se realice la encuesta de satisfacción del
cliente
Plan de gestión de proyecto
Informe de situación, gastos incurridos sobre planificados
Evaluación final
Realizar la evaluación a lo largo del proyecto
Evalur lo planificado contra lo realizado
Apego al proceso en todo el transcurso del proyecto
Cumplimiento de las propiedades de calidad
Es por esto que se recomienda realizar la evaluación final de SQA a
medida que el proyecto avanza.
23. Taller de Gestión de Software
Fase de Transición –
Criterios de evaluación
Esta satisfecho el usuario?
La relación de lo ejecutado sobre lo
planificado es aceptable ?
24. Taller de Gestión de Software
Métricas
Se sugiere que para las propiedades de
calidad que se identifiquen en el proyecto
se definan métricas para evaluarlas. En las
secciones siguientes se muestran ejemplos
de métricas y como se definen para
determinadas propiedades de calidad.
Estas métricas se basan en el borrador de
estándar ISO/IEC 9126 [3].
25. Taller de Gestión de Software
Métricas - Internas
Característica: Funcionalidad
Subcaracterística: Conveniencia
Métricas
Nombre Propósito de la métrica Medición o fórmula de cálculo
Completitud de la
implementación
funcional.
¿Cuán completa es la
implementación funcional?
X = 1 – A / B
A = Número de casos de uso (o funciones) no
implementadas
B = Número de casos de uso (o funciones) descriptas
en el Alcance del sistema final (último compromiso de
alcance, fin de fase de elaboración)
Y = 1 – A / C
A = Número de casos de uso (o funciones) no
implementadas
C = Número de casos de uso (o funciones) descriptas
en el Alcance del sistema al final de la fase inicial
Z = 1 – A / D
A = Número de casos de uso (o funciones) no
implementadas
D = Número de casos de uso (o funciones) descriptas
en la Especificación de Requerimientos
26. Taller de Gestión de Software
Metricas - Internas
Característica: Fiabilidad
Subcaracterística: Madurez
Métricas
Nombre Propósito de la métrica Medición o fórmula de cálculo
Levantamiento de
defectos (atributo
para medir la
calidad del
proceso)
¿Cuántos defectos han sido
corregidos?
¿Cuál es la proporción de defectos
corregidos?
X = A
A = Número de defectos corregidos en diseño /
codificación.
Y = A / B
A = Número de defectos corregidos en diseño /
codificación.
B = Número de defectos detectados en las revisiones.
Densidad de
defectos
¿Cuál es la proporción de defectos
respecto al tamaño del producto?
X = 1 – A / B
A = Número de defectos que no fueron corregidos.
B = Tamaño del producto.
NOTA: El tamaño del producto se mide en líneas
de código.
27. Taller de Gestión de Software
Métricas - Internas
Característica: Usabilidad
Subcaracterística: Capacidad de ser entendido (Understandability)
Métricas
Nombre Propósito de la métrica Medición o fórmula de cálculo
Completitud de la
descripción
¿Qué proporción de las funciones
(casos de uso) o tipos de
funciones se describen en la
descripción del producto
(documentación de usuario,
ayuda, etc)?
X = A / B
A = Número de funciones (casos de uso) o tipos de
funciones descriptas en la descripción del producto.
B = Número total de funciones (casos de uso) o tipos
de funciones.
NOTA: Esta medida indica si los usuarios
potenciales entenderán la capacidad del producto
luego de leer la descripción del producto.
Subcaracterístic
a
Operabilidad
Métricas
Nombre Propósito de la métrica Medición o fórmula de cálculo
Consistencia
operacional
¿Qué proporción de las
operaciones se comportan de
manera similar a operaciones
similares en otras partes del
sistema?
X = 1 - A / B
A = Número de instancias de operaciones con
comportamiento inconsistente.
B = Número total de operaciones.
28. Taller de Gestión de Software
Métricas - Externas
Característica: Funcionalidad
Subcaracterística: Conveniencia
Métricas
Nombre Propósito de la métrica Medición o fórmula de cálculo
Adecuación
funcional
¿Cuán adecuadas son las
funciones evaluadas?
X = 1 - A / B
A = Número de funciones (casos de uso) en las
cuales se detectaron problemas en la evaluación.
B = Número de funciones (casos de uso) evaluadas.
Característica: Fiabilidad
Subcaracterística: Madurez
Métricas
Nombre Propósito de la métrica Medición o fórmula de cálculo
Densidad de
defectos
¿Cuántos defectos fueron
detectados durante el período
de prueba?
X = A / B
A = Número de defectos detectados.
B = Tamaño del producto.
NOTA: El tamaño del producto se mide en líneas de
código.
29. Taller de Gestión de Software
Métricas - Externas
Característica: Usabilidad
Subcaracterística: Operabilidad
Métricas
Nombre Propósito de la métrica Medición o fórmula de cálculo
Consistencia
operacional en el uso
¿Cuán consistentes son los componentes
de la interfase de usuario?
X = 1 - A / B
A = Número de funciones que el usuario encontró
inaceptablemente inconsistentes según sus expectativas.
B = Número de funciones usadas por el usuario durante el
período de prueba.
Y = A / UOT
A = Número de funciones que el usuario encontró
inaceptablemente inconsistentes según sus expectativas.
UOT = Tiempo de operación del usuario (durante el período de
observación).
Característica: Portabilidad
Subcaracterística: Facilidad de instalación
Métricas
Nombre Propósito de la métrica Medición o fórmula de cálculo
Facilidad de
instalación
¿Puede el usuario o quien mantiene el
software fácilmente instalar el software
en un ambiente operacional?
X = A / B
A = Número de casos en que el usuario es exitoso en la
operación de instalación.
B = Número total de casos en que el usuario intenta ejecutar la
operación de instalación.
30. Taller de Gestión de Software
Métricas – Calidad en el uso
Característica: Efectividad
Métricas
Nombre Propósito de la métrica Medición o fórmula de cálculo
Tareas
completadas
¿Qué proporción de las tareas son
completadas?
X = A / B
A = Número de tareas completadas
B = Número total de tareas que se intentaron realizar
Frecuencia de
errores
¿Cuál es la frecuencia de errores? X = A / T
A = Número de errores del usuario
T = Tiempo de la prueba o número de tareas
Característica: Satisfacción
Métricas
Nombre Propósito de la métrica Medición o fórmula de cálculo
Escala de
satisfacción
¿Cuán satisfecho está el usuario? X = A / B
A = Valor producida por el cuestionario
B = Mayor valor de la escala que puede producir el
cuestionario
31. Taller de Gestión de Software
Otros elementos
Checklists
Sugerencias para las propiedades o modelo
de calidad
ANEXO REVISIONES
Revisión de Requerimientos
Revisión del diseño de alto nivel
Revisión del Plan de Verificación y Validación
Revisión del Plan de SCM
Revisión del Plan del Proyecto
Diseño vs. Código, Diseño vs. Requerimientos y
Testeo vs. Requerimientos
32. Taller de Gestión de Software
Conclusiones
Comunicación fluida
Soporte, apoyo
Monitoreo de actividades
Fuerte conocimiento del proceso
Riesgos
Buena suerte!