clase18 sqayrevisionesporpares revision insp imp
DESCRIPTION
.TRANSCRIPT
-
Ingeniera de Software II
Primer Cuatrimestre de 2009
Buenos Aires, 4 de Junio de 2009
Clase 18 SQA y Revisiones por Pares
Ctedra de Ingeniera de Software II FCEN UBA, 2009
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
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. 610-1990
Concordancia del software producido con los requerimientos explcitamente establecidos, con los estndares de desarrollo prefijados y con los requerimientos implcitos 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 9001-00
2
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
Entonces... calidad en Software involucra
Aptitud para el uso
Ausencia de defectos
Satisfaccin de los requerimientos
Nivel hasta el que un producto tieneuna combinacin deseada de atributos
Triste conclusin: En general, los sistemas de software no cumplen con
ninguna definicin de calidad!
3
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
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 ejecucin de procesos y los entregables en comparacin con las descripciones de procesos, estndares y procedimientos vigentes.
Identificar y documentar desviaciones en el cumplimiento de estndares 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 tratadas4
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
Mitos de QA
La gente de QA se ocupa de la calidad
La existencia de QA garantiza que se van a seguir de los estndares y procedimientos
QA se ocupa de las cosas, y no necesita soporte peridico de la gerencia
QA debe escalar todo problema que encuentre
5
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
Objetivos de Quality Assurance
Dar visibilidad a la gerencia sobre la ejecucin del proceso de desarrollo.
Asegurar el cumplimiento del proceso definido.
A travs de las revisiones, ayudar a poner la calidad en los productos
Asegurar que los desvos son visibles para el management
6
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
Funciones de QA
Definicin de prcticas de calidad
Evaluacin de planes
Evaluacin de requerimientos y diseo
Evaluacin de prcticas de programacin
Evaluacin del proceso de prueba
Evaluacin del proceso de gestin
Adaptacin de los controles
7
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
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 implementacin del rol de SQA suele hacerse con checklists que se adaptan a las necesidades de cada proyecto
En organizaciones ms maduras, las revisiones sobre productos se canalizan a travs de Peer Reviews, dejando que SQA se concentre en el proceso
8
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
Ejemplo de un Checklist de SQA
9
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
Proceso de armado y uso de un checklist
10
Puntos de checklists (del
proceso de SQA)
Otros puntos que el Responsable de
SQA considere oportuno revisar
Reporte vaco de SQA (usando
template)
Revisin
Reporte de SQA Completo
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
11
SQA segn 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
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
Revisiones Peer Reviews
Un concepto antiguo, muy efectivo, con muchas variantes.
Entre ellas estn las revisiones por pares (con formalidad, efectividad y esfuerzo creciente).
Walkthroughs.
Revisiones (menos formalidad)
Inspecciones de cdigo (ms formales en cuanto a la rigurosidad con la que se deben aplicar sus reglas)
12
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
Walkthroughs
Objetivos Detectar posibles defectos
Identificar oportunidades de mejora
Examinar alternativas
Aprender
Usadas para revisar especificaciones de requerimientos o diseos
El concepto de walkthough significa recorrer el sistema (qu pasa al recibir un estmulo)
14
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
Walkthroughs: la reunin
El presentador conoce a fondo el producto
Los asistentesson especialistas del negocio, la tecnologa 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 relacin calidad / esfuerzo
Ser cuidadoso con el tiempo y el foco de la reunin!
15
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
Inspeccionar es revisar cdigo 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 mdulos ms crticos
La tcnica fue perdiendo utilidad con los nuevos paradigmas de programacin y los nuevos entornos
Pair Programming aparece como una alternativa interesante para obtener algunos de los beneficios de las revisiones de cdigo
Inspecciones de cdigo
16
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
Inspecciones
Objetivos primarios
Detectar defectos
Elegir el camino de resolucin
Verificar la resolucin (los defectos deben ser resueltos)
Objetivos secundarios
Asegurar consenso sobre el trabajo / la calidad
Potenciar el trabajo en equipo
Obtener datos para las mtricas
17
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
Entrada / salida de la reunin
InspeccinEntrada
Cdigo
Especificacin (diseo)
Procedimientos y estndares
Lista de verificacin
(gua para revisores)
Salida
Informe de resultados
18
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
Roles
Reunin de
inspeccin
Moderador
Responsable
de la inspeccin
Revisores
Buscan defectos,
toman decisiones
Lector
Lee el programa,
lnea por lnea
Autor
Explica
Registrador
Anota...
19
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
Proceso
PLANIFICACION PREPARACIONREUNION DE
REVISIONCORRECCION SEGUIMIENTO
20
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
Reglas para la reunin
El moderadorAsegura que todos estn preparados
Aclara los roles y las reglas
Hace cumplir los reglas en la reunin
El lector lee el cdigo lnea por lneaLos revisores describen los defectos que encuentranEl autor aclara las dudasEl moderador mantiene las cosas funcionandoEl registrador registra los erroresA las dos horas debe finalizar la reuninLa minuta debe enviarse lo antes posible
21
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
Resultado
Encabezado: Quin? Cundo? Qu?...
Para los defectos halladosUbicacin
Descripcin
Severidad: Crtica / Media / Cosmtica
Clase: Interface / Datos / Lgica /...
Evitar caza de brujas
22
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
Beneficios
DirectosMayor calidad, que lleva a aumentos de
productividadMayor efectividad de test
IndirectosCapacitacin (para aprender a escribir hay que leer)Mayor visibilidad del procesoTrabajo en equipo y mejor comunicacinMejora en la calidad de estndares y mtodosEs un mtodo de seguimiento
23
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
Efectividad
Entre 7 y 20 defectos mayores identificados por cada 1000 lneas de cdigo (resultados reportados)
Alrededor de 1 hora hombre por defecto (contando el proceso completo)
24
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
Cundo hago la inspeccin?
Si se hace una inspeccin de cdigo testeado extensamente
La inspeccin no va a ser eficiente
Si hago una inspeccin de cdigo que nunca fue compilado
No voy a poder revisar ni 30 lneas
EntoncesEs recomendable hacerla luego de una prueba muy
bsica
25
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
Inspecciones de otros artefactos
Cualquier artefacto que pueda ser ledo en una reunin puede ser sujeto a una Inspeccin
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
-
Ctedra de Ingeniera de Software II FCEN UBA, 2009
Lo importante
Las revisiones por pares son actividades para el control de calidad efectivas
Pueden aplicarse al anlisis, diseo y codificacin. Es bueno asociarlas a hitos dentro del proyecto
Son actividades de mucho cerebro agregado
Hay factores tcnicos, 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