Taller de Gestión de Software

Doris Correa
Luis Remuñán
Gabriel Claramunt
Dieter Spangenberg

tgsoft01@fing.edu.uy
 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

Taller de Gestión de Software

Plan de SQA

tgsoft01@fing.edu.uy
 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

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
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

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.

Taller de Gestión de Software

Guía del buen SQA

tgsoft01@fing.edu.uy
 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.

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

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

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

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

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?
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
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.
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?
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.
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
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

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?

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.
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 ?

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].
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 ¿Cuán completa es la X=1–A/B

implementación implementación funcional? A = Número de casos de uso (o funciones) no
funcional. 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

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 ¿Cuántos defectos han sido X=A

defectos (atributo corregidos? A = Número de defectos corregidos en diseño /
para medir la ¿Cuál es la proporción de defectos codificación.
calidad del corregidos? Y=A/B
proceso) A = Número de defectos corregidos en diseño /
codificación.
B = Número de defectos detectados en las revisiones.

Densidad de ¿Cuál es la proporción de defectos X=1–A/B

defectos respecto al tamaño del producto? 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.

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
Completitud de la ¿Qué proporción de las funciones
descripción (casos de uso) o tipos de funciones
se describen en la descripción del
producto (documentación de
usuario, ayuda, etc)?
Subcaracterístic Operabilidad
a
Métricas
Nombre Propósito de la métrica
Consistencia ¿Qué proporción de las
operacional operaciones se comportan de
manera similar a operaciones
similares en otras partes del
sistema?
Taller de Gestión de Software
Medición o fórmula de cálculo
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.
Medición o fórmula de cálculo
X=1-A/B
A = Número de instancias de operaciones con
comportamiento inconsistente.
B = Número total de operaciones.
 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 ¿Cuán adecuadas son las X=1-A/B

funcional funciones evaluadas? 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 ¿Cuántos defectos fueron X=A/B

defectos detectados durante el período A = Número de defectos detectados.
de prueba? B = Tamaño del producto.
NOTA: El tamaño del producto se mide en líneas de
código.

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 ¿Cuán consistentes son los componentes X=1-A/B
operacional en el uso de la interfase de usuario? 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 ¿Puede el usuario o quien mantiene el
instalación 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.

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 ¿Qué proporción de las tareas son X=A/B

completadas completadas? A = Número de tareas completadas
B = Número total de tareas que se intentaron realizar

Frecuencia de ¿Cuál es la frecuencia de errores? X=A/T

errores 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 ¿Cuán satisfecho está el usuario? X=A/B

satisfacción A = Valor producida por el cuestionario
B = Mayor valor de la escala que puede producir el
cuestionario

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
Taller de Gestión de Software
 Conclusiones
 Comunicación fluida
 Soporte, apoyo
 Monitoreo de actividades
 Fuerte conocimiento del proceso
 Riesgos
 Buena suerte!

Taller de Gestión de Software