Date post: | 03-Jan-2016 |
Category: |
Documents |
Upload: | lucian-burnett |
View: | 22 times |
Download: | 0 times |
Taller de Gestión de Software
Doris CorreaLuis RemuñánGabriel ClaramuntDieter Spangenberg
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
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
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
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 - InternasCaracterí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 / BA = Número de casos de uso (o funciones) no implementadasB = 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 / CA = Número de casos de uso (o funciones) no implementadasC = Número de casos de uso (o funciones) descriptas en el Alcance del sistema al final de la fase inicialZ = 1 – A / DA = Número de casos de uso (o funciones) no implementadasD = Número de casos de uso (o funciones) descriptas en la Especificación de Requerimientos
Taller de Gestión de Software
Metricas - InternasCaracterí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 = AA = Número de defectos corregidos en diseño / codificación.Y = A / BA = 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 / BA = 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 - InternasCaracterí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 / BA = 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ística
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 / BA = Número de instancias de operaciones con comportamiento inconsistente.B = Número total de operaciones.
Taller de Gestión de Software
Métricas - ExternasCaracterí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 / BA = 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 / BA = Número de defectos detectados.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 - ExternasCaracterí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 / BA = 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 / UOTA = 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 / BA = 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 completadas
¿Qué proporción de las tareas son completadas?
X = A / BA = Número de tareas completadasB = Número total de tareas que se intentaron realizar
Frecuencia de errores
¿Cuál es la frecuencia de errores? X = A / TA = Número de errores del usuarioT = 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 / BA = Valor producida por el cuestionarioB = 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!