20061019_Calidad

Calidad

ItinerarioConceptos GeneralesQuality ControlQuality AssuranceMás Sobre Calidad...Ingeniería de Software II Calidad 2

¿Por qué hablamos de Calidad?Construir software es un proceso sujeto a errores.(Como toda actividad humana.)No importan los métodos y las técnicas usadas, no es posible garantizar que el producto final se comporte siempre como es requerido.Ingeniería de Software II Calidad 3

¿Por qué se justifica?50 % de los defectos se introducen durante la programación.Hoy, no más del 15% de los defectos iniciales son detectados antes del testing.Al comienzo del test de unidad la densidad es de 20 defectos x cada 1000 líneas de código (no comentadas).80% de los defectos de prog. se encuentran en el 20% de los módulos de programación. Muchos se ven durante la integración.El costo de reparación crece con el tiempo (1 unidad en test de unidad a > 12.5 durante operación).Ingeniería de Software II Calidad 4

¿Por qué pasa esto?Nohaysolucionesmágicas,o“BalasdePlata”. Dificultades esenciales y accidentales.La disciplina está inmadura.Hayunabismoentreel“EstadodelArte”yel “EstadodelaPráctica”.Hay problemas en la gestiónIngeniería de Software II Calidad 5

Definiciones de CalidadAptitud para el uso.Ausencia de defectos.Satisfacción de los requerimientos.Triste conclusión: ¡En general, los sistemas de software no cumplen con ninguna definición de calidad!Ingeniería de Software II Calidad 6

Construcción de Software como Ingeniería Actividades definidas. Actividades repetibles. Actividades estables. “ASoftwareProcesscanbedefinedasasetofactivities,methods, practices and transformations that people employto develop and maintain software and the associated products” 7

Calidad de Proceso vs ProductoConstruimos con procesos establesDependencias de la calidad del producto Calidad del método Calidad de las herramientas Habilidades de las personasLos defectos encontrados se traducen en mejoras para el proceso. 8

Costo de Corrección Req. Diseño Desarr Desp. OperaciónCost of rework X X XX XX XX X XX X Time over Lifecycle 9

Principios de Calidad de Demming Cesar la dependencia en inspección masiva para obtener calidad. Mejorar constantemente y para siempre, el sistema de producción. 10

El software“SuficientementeBueno”Nunca podremos cumplir con todos los requerimientos. los usuarios y nosotros lo sabemos.Preguntas: ¿Qué requerimientos son esenciales? ¿Qué requerimientos son importantes? ¿Qué requerimientos son opcionales?¿Cuál es el orden adecuado de implementación de requerimientos?Ingeniería de Software II Calidad 11

Calidad en softwareConfiabilidad UsabilidadCorrección Facilidad de MantenimientoRobustez ReusabilidadSeguridad (en datos, en acceso, Safety) Verificabilidad + ClaridadFuncionalidad InteroperabilidadIngeniería de Software II Calidad 12

Calidad en el proceso vs.calidad en el producto FORMA DE TRABAJO Mala Buena Malo Típico BurocraciaPRODUCTO Desarrollo sin Sentido Bueno Esfuerzo Disciplina Heroico de Software MaduraIngeniería de Software II Calidad 13

ItinerarioConceptos GeneralesQuality Control Métodos Consejos para QCQuality AssuranceMás Sobre Calidad...Ingeniería de Software II Calidad 14

Proceso“Esencial”deSoftware Real WorldCorrespondence Correctness Verification ValidationIngeniería de Software II System 15 Calidad

IV&VValidación. ¿Estamos haciendo el producto correcto? Basada en el uso de modelos.Verificación. ¿Estamos haciendo el producto correctamente? Necesariamente es en relación a un componente anterior, que describe nuestro producto.Ingeniería de Software II Calidad 16

V ModelIngeniería de Software II Calidad 17

¿Cuándo parar de testear?Problema: no puede estimarse en la práctica la intensidad del testing para alcanzar determinada densidad de defectos.Estrategias usuales (confiando en la convergencia): “NoFailure”:pasaexitosamentetodoslostestdiseñados. “GoodEnough”:esaceptableunaciertacantidaddefallasno críticas (i.e. Hay umbral de fallas no críticas por unidad de testing). MS. Cantidad de defectos detectados es similar a la cantidad de defectos estimados.Alcancé cierto umbral predeterminado de esfuerzo.Ingeniería de Software II Calidad 18

Definiciones en TestingError = equivocación.Defecto (defect o fault)Un error introduce uno o más defectos, que perduran en el producto de software.La presencia de defectos separa a los productos correctos de los incorrectos.Falla (failure)Un defecto en el producto se manifiesta en la dinámica a través de cero, una o más fallas.La presencia de fallas separa los resultados reales de los esperados.Ingeniería de Software II Calidad 19

Definiciones en TestingVerificación dinámica.Verificación estática.Debugging.Casos de test.Datos de test.Cobertura.Ingeniería de Software II Calidad 20

Tipos (o niveles) de testDe UnidadDe IntegraciónDe SistemaDe Aceptación del UsuarioDe Volumen y PerformanceDe EstrésDe RegresiónTipo Alfa y BetaIngeniería de Software II Calidad 21

Test de aceptación del usuario (UAT)Asegurar que el sistema implementa los requerimientos del usuario.Es una forma particular del testing del sistema.Los casos de test están basados en los requerimientos y los diseñan y ejecutan los usuarios.Involucrar a los usuarios es clave en el proceso de testing.Ingeniería de Software II Calidad 22

Test de volumen y performanceAsegurar que el sistema soporta los volúmenes máximos definidos de: Capacidad de almacenamiento. Capacidad de procesamiento. Test de estrésAsegurar que el sistema tiene comportamientoadecuado cuando se excede los límites decapacidad de procesamiento yalmacenamiento.Es un test de sistema.Ingeniería de Software II Calidad 23

Test de regresiónTiene como objetivo asegurar que luego de un cambio no se han introducido errores en funcionalidades que no debían cambiar.Tambiénllamado“denoimpacto”.Necesitocondicionesydatosdetest“reusables” (sus últimas palabras fueron) Por cambiar un par de líneas no va a pasar nada... Yo me juego y catalogo sin probarlo...Ingeniería de Software II Calidad 24

Test de versiones alfa y betaTienecomoobjetivolograrlaayudadelos“amigos” en un test de sistema.Consiste en entregar una versión preliminar a los “amigos”Técnica muy interesante, efectiva y sobre todo, eficiente.Alfa: usuario interno, muy amigo.Beta: usuario externo y real.Ingeniería de Software II Calidad 25

RevisionesUn concepto antiguo, muy efectivo, con muchas variantes.Entre ellas están las revisiones por pares (con formalidad, efectividad y esfuerzo creciente). “Walkthroughs”. Inspecciones de código.Ingeniería de Software II Calidad 26

WalkthroughsObjetivos Detectar posibles defectos Examinar alternativas AprenderNo se decide QUE HACER con los defectosUsadas para revisar especificaciones de requerimientos o diseñosIngeniería de Software II Calidad 28

Walkthroughs: la reuniónEl presentador conoce a fondo el productoLos asistentes son especialistas del negocio, de la tecnología usada o conocedores de los sistemas donde hay impacto no preparan esta actividadEl autor es el único que decide que hacer con lo que se encuentra. Los hallazgos son tratados de acuerdo a las implicancias del ciclo de vida del producto.Si funcionan bien: buenos resultados y buena relación calidad / esfuerzoSer cuidadoso con el tiempo de la reunión!Ingeniería de Software II Calidad 29

InspeccionesObjetivos primarios Detectar defectos Elegir el camino de resolución Verificar la resolución (los defectos deben ser resueltos)Ingeniería de Software II Calidad 30

Inspecciones de códigoInspeccionar es revisar un programa buscando defectos.Es un procedimiento estático.No son excluyentes con el testing: cada uno puede encontrar distintos tipos de defectosNunca tengo Total de Defectos hallados dinero ni tiempo defectos con Inspecciones para inspeccionar hallados Defectos hallados todo. con TestingIngeniería de Software II Calidad 31

InspeccionesObjetivos secundarios Asegurar consenso sobre el trabajo / la calidad Potenciar el trabajo en equipo Obtener datos para las métricasEntre alternativas prefijadas, equipo de inspección elige un camino para cada defectoIngeniería de Software II Calidad 32

Entrada / salida de la reuniónEntrada Inspección SalidaCódigo Informe de resultadosEspecificación del programaProcedimientos y estándaresLista de verificación (guía para revisores)Ingeniería de Software II Calidad 33

Roles Autor Revisores Buscan defectos, toman decisiones Lector Reunión de RegistradorLee el programa, inspección Anota... línea por línea Moderador 34 ResponsableIngeniería de Software II de la inspección Calidad

ProcesoIngeniería de Software II Calidad 35

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 posibleIngeniería de Software II Calidad 36

ResultadoEncabezado: Quién? Cuándo? Qué?...Para los defectos hallados Ubicación Descripción Gravedad: Mayor / Menor Clase: Función / Interface / Datos / Lógica /...Ingeniería de Software II Calidad 37

Buen y mal uso de los resultadosLos resultados de las inspecciones son para el uso y beneficio de los programadores [Fagan]Los resultados no deben, bajo ninguna circunstancia, ser usados para evaluar a los programadoresIngeniería de Software II Calidad 38

BeneficiosDirectos –Mayor calidad, que lleva a aumentos de productividad –Mayor efectividad de test –Mejor calidad del test por reducirse la base de errores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 seguimientoIngeniería de Software II Calidad 39

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) ¿Cuánto cuesta encontrar esos defectos en producción? En producción se detectan manifestaciones de defectos (fallas) y no defectosIngeniería de Software II Calidad 40

Cuando hago la inspección?Si se hace una inspección de un programa testeado extensamente La inspección no va a ser eficienteSi hago una inspección de un programa que nunca fue compilado Novoyapoderrevisarni30líneas…Entonces… Es recomendable hacerla luego de la primera compilación limpiaIngeniería de Software II Calidad 41

Reglas de WeinbergBusque asociarse con Sólo incluya revisores el autor del programa técnicamente competentesCuide el lenguaje Registre todos los temas en públicoUn comentario positivo y uno negativo Limítese a temas técnicosIdentifiquen defectos, No evalúe a los autores no los corrija Distribuya el reporte lo antesNo discuta el estilo posibleApéguese al estándar Permita al autor decidir cuándo está listoIngeniería de Software II Calidad 42

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La clave son los factores humanosEl uso de procedimientos (formales y documentados)y los moderadores sirve para manejar estos factoresIngeniería de Software II Calidad 43

ItinerarioConceptos GeneralesQuality Control Métodos Consejos para QCQuality AssuranceMás Sobre Calidad...Ingeniería de Software II Calidad 44

La visión modernaSe puede invertir mucho esfuerzo en testearTestear es el procesode establecer confianzaen que un programa hacelo que se supone 120que tiene que hacer 100 80 % Errores 60Testear es una Detectados 40 decisión 20económica 0 Unidad de TiempoIngeniería de Software II Calidad 45

La paradoja del pesticida(Beizer)El pesticida mata el 98% de los bichos, los que se salvan son los más fuertes.Al siguiente año, necesito un pesticida mejor.Nuestros bugs son verdaderos bichos!El buen uso del testing implica que los errores que no se encuentran son los más sutiles.Si todo anda bien, el tipo de errores encontrados tiene que cambiar!El orden en el cual aplico las técnicas de QC debe ser el económicamente adecuado!!Ingeniería de Software II Calidad 46

ConsejosDefinir estándares y templates para los documentos de test de ambiente, test de instalación y tipos de errores.Incluir los tipos de errores dentro de los estándares con el objetivo de poder comparar un proyecto contra otro.Nodebenser“writeonly”(seescribenysearchivan).No tienen que ser inmensos, muchas veces con 2 hojas es suficiente.En la estrategia Definir claramente qué es lo que voy probar, dónde y cómo.Ingeniería de Software II Calidad 47

Consejos (2): casos ycondicionesInvolucrar al desarrollador y al usuario para escribir el resultado esperado.Escribir en forma simple y concisa (recordar que luego habrá regresiones).Todos los involucrados deben estar de acuerdo sobre los casos de prueba.Definir cuándo parar de hacer testing.Ingeniería de Software II Calidad 48

Consejos (3): reporte de erroresIdentificar problemas crónicos y/o repetitivos.Definir métricas sobre los errores para aprender a evitarlos.La historia no termina al reportarlos, luego hay que seguirlos.Ingeniería de Software II Calidad 49

¿Por dónde empezar?Implantar inspecciones de código para componentes críticos.Empezar por testing del sistema completo, basado en sus requerimientos.Definir los casos antes de construir.Insistir en la participación de los usuarios.Seguir con caja negra de programas.Mejorar la definición de entornos.Luego buscar herramientas de administración.Ingeniería de Software II Calidad 50

ItinerarioConceptos GeneralesQuality ControlQuality AssuranceMás Sobre Calidad...Ingeniería de Software II Calidad 51