Taller de Gestión de Software

1. Taller de Gestión de Software Doris Correa Luis Remuñán Gabriel Claramunt Dieter Spangenberg tgsoft01@fing.edu.uy

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

3. Plan de SQA tgsoft01@fing.edu.uy

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

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

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

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

8. Guía del buen SQA tgsoft01@fing.edu.uy

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

25. Métricas - Internas Taller de Gestión de Software

26. Metricas - Internas Taller de Gestión de Software

27. Métricas - Internas Taller de Gestión de Software

28. Métricas - Externas Taller de Gestión de Software

29. Métricas - Externas Taller de Gestión de Software

30. Métricas – Calidad en el uso Taller de Gestión de Software

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

32. Conclusiones • Comunicación fluida • Soporte, apoyo • Monitoreo de actividades • Fuerte conocimiento del proceso • Riesgos • Buena suerte! Taller de Gestión de Software