Ingeniería de Software II

Transcripción

1 Ingeniería de Software II Primer Cuatrimestre de 2009 Clase 18 SQA y Revisiones por Pares Buenos Aires, 4 de Junio de 2009

2 Algunas definiciones de calidad en Software La calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario. IEEE, Std Concordancia del software producido con los requerimientos explícitamente establecidos, con los estándares de desarrollo prefijados y con los requerimientos implícitos no establecidos formalmente, que desea el usuario. Pressman, 1998 Achieving excellent levels of fitness for use. Watts Humphrey the degree to which a set of inherent characteristics fulfills requirements. ISO

3 Entonces... calidad en Software involucra Aptitud para el uso Ausencia de defectos Satisfacción de los requerimientos Nivel hasta el que un producto tiene una combinación deseada de atributos Triste conclusión: En general, los sistemas de software no cumplen con ninguna definición de calidad! 3

4 Qué es y por qué SQA? What is not tracked is not done. Watts Humphrey La calidad del Software depende que una gran cantidad de cosas se hagan y bien, el Project Manager no puede dar seguimiento a todo Definimos SQA como el conjunto de tareas realizadas en el marco de un proyecto de desarrollo o de mantenimiento de software, por un grupo objetivo, para : Evaluar objetivamente la ejecución de procesos y los entregables en comparación con las descripciones de procesos, estándares y procedimientos vigentes. Identificar y documentar desviaciones en el cumplimiento de estándares y procedimientos aplicables. Proveer feedback al equipo de proyecto y los responsables de administrarlo sobre el resultado de las tareas de aseguramiento de la calidad. Asegurar que las desviaciones sean adecuadamente tratadas 4

5 Mitos de QA La gente de QA se ocupa de la calidad La existencia de QA garantiza que se van a seguir de los estándares y procedimientos QA se ocupa de las cosas, y no necesita soporte periódico de la gerencia QA debe escalar todo problema que encuentre 5

6 Objetivos de Quality Assurance Dar visibilidad a la gerencia sobre la ejecución del proceso de desarrollo. Asegurar el cumplimiento del proceso definido. A través de las revisiones, ayudar a poner la calidad en los productos Asegurar que los desvíos son visibles para el management 6

7 Funciones de QA Definición de prácticas de calidad Evaluación de planes Evaluación de requerimientos y diseño Evaluación de prácticas de programación Evaluación del proceso de prueba Evaluación del proceso de gestión Adaptación de los controles 7

8 Implementaciones de SQA En todo proyecto grande, se crea un plan de SQA donde se describen las actividades de calidad Roles y responsabilidades Actividades de SQA Mecanismos de seguimiento Herramientas a usar La implementación del rol de SQA suele hacerse con checklists que se adaptan a las necesidades de cada proyecto En organizaciones más maduras, las revisiones sobre productos se canalizan a través de Peer Reviews, dejando que SQA se concentre en el proceso 8

9 Ejemplo de un Checklist de SQA 9

10 Proceso de armado y uso de un checklist Puntos de checklists (del proceso de SQA) Otros puntos que el Responsable de SQA considere oportuno revisar Reporte vacío de SQA (usando template) Revisión Reporte de SQA Completo 10

11 SQA según CMMI Process and Product Quality Assurance SG 1 Objectively Evaluate Processes and Work Products SP 1.1 Objectively Evaluate Processes SP 1.2 Objectively Evaluate Work Products and Services SG 2 Provide Objective Insight SP 2.1 Communicate and Ensure Resolution of Noncompliance Issues SP 2.2 Establish Records La palabra clave objectively 11

12 Revisiones Peer Reviews Un concepto antiguo, muy efectivo, con muchas variantes. Entre ellas están las revisiones por pares (con formalidad, efectividad y esfuerzo creciente). Walkthroughs. Revisiones (menos formalidad) Inspecciones de código (más formales en cuanto a la rigurosidad con la que se deben aplicar sus reglas) 12

13 Walkthroughs Objetivos Detectar posibles defectos Identificar oportunidades de mejora Examinar alternativas Aprender Usadas para revisar especificaciones de requerimientos o diseños El concepto de walkthough significa recorrer el sistema (qué pasa al recibir un estímulo) 14

14 Walkthroughs: la reunión El presentador conoce a fondo el producto Los asistentes son especialistas del negocio, la tecnología usada o conocedores de los sistemas donde hay impacto no preparan esta actividad Se pueden discutir brevemente los temas planteados (problemas, sugerencias de mejora) Si funcionan bien: buenos resultados y buena relación calidad / esfuerzo Ser cuidadoso con el tiempo y el foco de la reunión! 15

15 Inspecciones de código Inspeccionar es revisar código buscando defectos. No son excluyentes con el testing: cada uno puede encontrar distintos tipos de defectos Nunca tengo dinero ni tiempo para inspeccionar todo. Se suele poner el foco en los módulos más críticos La técnica fue perdiendo utilidad con los nuevos paradigmas de programación y los nuevos entornos Pair Programming aparece como una alternativa interesante para obtener algunos de los beneficios de las revisiones de código 16

16 Inspecciones Objetivos primarios Detectar defectos Elegir el camino de resolución Verificar la resolución (los defectos deben ser resueltos) Objetivos secundarios Asegurar consenso sobre el trabajo / la calidad Potenciar el trabajo en equipo Obtener datos para las métricas 17

17 Entrada / salida de la reunión Entrada Inspección Salida Código Especificación (diseño) Procedimientos y estándares Lista de verificación (guía para revisores) Informe de resultados 18

18 Roles Revisores Buscan defectos, toman decisiones Autor Explica Lector Lee el programa, línea por línea Reunión de inspección Moderador Responsable de la inspección Registrador Anota... 19

19 Proceso PLANIFICACION PREPARACION REUNION DE REVISION CORRECCION SEGUIMIENTO 20

20 Reglas para la reunión El moderador Asegura que todos estén preparados Aclara los roles y las reglas Hace cumplir los reglas en la reunión El lector lee el código línea por línea Los revisores describen los defectos que encuentran El autor aclara las dudas El moderador mantiene las cosas funcionando El registrador registra los errores A las dos horas debe finalizar la reunión La minuta debe enviarse lo antes posible 21

21 Resultado Encabezado: Quién? Cuándo? Qué?... Para los defectos hallados Ubicación Descripción Severidad: Crítica / Media / Cosmética Clase: Interface / Datos / Lógica /... Evitar caza de brujas 22

22 Beneficios Directos Mayor calidad, que lleva a aumentos de productividad Mayor efectividad de test Indirectos Capacitación (para aprender a escribir hay que leer) Mayor visibilidad del proceso Trabajo en equipo y mejor comunicación Mejora en la calidad de estándares y métodos Es un método de seguimiento 23

23 Efectividad Entre 7 y 20 defectos mayores identificados por cada 1000 líneas de código (resultados reportados) Alrededor de 1 hora hombre por defecto (contando el proceso completo) 24

24 Cuándo hago la inspección? Si se hace una inspección de código testeado extensamente La inspección no va a ser eficiente Si hago una inspección de código que nunca fue compilado No voy a poder revisar ni 30 líneas Entonces Es recomendable hacerla luego de una prueba muy básica 25

25 Inspecciones de otros artefactos Cualquier artefacto que pueda ser leído en una reunión puede ser sujeto a una Inspección Casos de Uso, User Stories u otras especificaciones Casos de Prueba Manuales de Usuario Es importante tener en cuenta el costo de la actividad y el beneficio esperado 26

26 Lo importante Las revisiones por pares son actividades para el control de calidad efectivas Pueden aplicarse al análisis, diseño y codificación. Es bueno asociarlas a hitos dentro del proyecto Son actividades de mucho cerebro agregado Hay factores técnicos, de procedimiento y humanos Son importantes los factores humanos El uso de procedimientos (formales y documentados)y los moderadores sirve para manejar estos factores 27