ADR-Calidad-4-Garantia - Alberto Medina

Vista previa del material en texto

Administración de Recursos - Garantía de 
Calidad del Software
AUS Fabiana María Riva 1
CALIDADCALIDAD
y y 
MEJORES PRÁCTICASMEJORES PRÁCTICAS
en laen la
INGENIERÍA SOFTWAREINGENIERÍA SOFTWARE
AUS Fabiana María Riva
Agosto 2006
CALIDAD y MEJORES PRÁCTICAS en laCALIDAD y MEJORES PRÁCTICAS en la
INGENIERÍA DE SOFTWAREINGENIERÍA DE SOFTWARE
AUS Fabiana María Riva
Agosto 2006
4ta. Parte4ta. Parte
Aseguramiento de la Aseguramiento de la 
Calidad del SoftwareCalidad del Software
Garantía de Calidad del Software (SQA)Garantía de Calidad del Software (SQA)
Es una disciplina de la Ingeniería de Software que 
se especializa en la aplicación de procesos de 
calidad a lo largo del proyecto de software.
ResponsabilidadesResponsabilidades
gestión de los procesos de ingeniería de software 
iniciativas de mejoramiento de procesos a lo largo de la organización 
integración de los procesos de calidad de ingenierí a y servicios al 
cliente 
Garantía de Calidad del Software (SQA)Garantía de Calidad del Software (SQA)
3 Cuestiones a tener en cuenta3 Cuestiones a tener en cuenta
1. La calidad no se puede probar, se construye
2. El aseguramiento de la calidad del software no es 
una tarea que se realiza en una fase particular del 
ciclo de vida de desarrollo
3. Las actividades asociadas con el aseguramiento de 
la calidad del software deben ser realizadas por 
personas que no estén directamente involucradas en 
el esfuerzo de desarrollo
Tres acercamientos al aseguramiento Tres acercamientos al aseguramiento 
de la calidadde la calidad
Certificación del Producto: Un tercero conduce un limitado 
ejercicio de verificación, validación y/o testeo de los 
componentes del software
Auditoría del Proceso: Un grupo independiente conduce un 
assessment del proceso de desarrollo utilizado para diseñar, 
construir e implementar un componente de software
Satisfacción del Usuario: Análisis del comportamiento real 
del software en uso
Actividades de Actividades de 
Garantía de Calidad del Software....Garantía de Calidad del Software....
Se usa la metodología de desarrollo apropiada 
Las actividades de desarrollo han sido debidamente planeadas 
Se han definido estándares y procedimientos para el proyecto 
El personal ha sido debidamente entrenado en los pr ocesos de calidad 
aplicables 
Se llevan a cabo regularmente revisiones y auditorí as independientes 
Administración de Recursos - Garantía de 
Calidad del Software
AUS Fabiana María Riva 2
Actividades de Actividades de 
Garantía de Calidad del Software....Garantía de Calidad del Software....
El desarrollo es documentado adecuadamente para fac ilitar el 
mantenimiento y la reutilización 
La documentación se produce oportunamente y no desp ués que el 
desarrollo ha sido completado 
Los cambios introducidos han sido debidamente contr olados
Las pruebas efectuadas son eficaces para detectar d efectos, 
especialmente en aquellas áreas de mayor riesgo
Las actividades se llevan a cabo de acuerdo a los p lazos y en los 
términos planeados 
Actividades de Actividades de 
Garantía de Calidad del Software....Garantía de Calidad del Software....
Las desviaciones a los estándares se identifican rá pidamente 
El proyecto está en condiciones para ser sometido a auditorías externas, 
si corresponde 
La calidad es verificada con respecto a criterios p reestablecidos
La gerencia es oportunamente informada de problemas y riesgos 
relativos a la calidad 
Los problemas de calidad se analizan y las causas s e comunican al jefe 
del proyecto para tomar medidas preventivas que evi ten su repetición
Metodologías de DesarrolloMetodologías de Desarrollo
Conceptos GeneralesConceptos Generales
MetodologíaMetodología
Conjunto de procedimientos, técnicas, herramientas y un soporte 
documental que ayuda a los desarrolladores a realiz ar software.
Indica cómo hay que obtener los distintos productos parciales y finales.
TécnicasTécnicas
Indica cómo debe realizarse una actividad detallada en la metodología. 
Combina el empleo de modelos gráficos conjuntamente con 
procedimientos detallados.
Metodologías Ágiles vs.Metodologías Ágiles vs.
Metodologías TradicionalesMetodologías Tradicionales
http://www.agilemanifesto.org/
Factores en los ProyectosFactores en los Proyectos
Factor Metodologías ágiles Metodologías formales
Tamaño
Dependencia y escalabilidad limitada por el 
porcentaje alto de conocimiento tácito.
Apropiado para equipos y productos 
pequeños.
Escalabilidad y conocimiento explícito.
Apropiado para productos y equipos grandes. 
Duro de mantener en pequeños proyectos.
Criticidad
La simplicidad en la documentación y el 
diseño dificulta los planes de pruebas.
No aconsejado para sistemas con niveles de 
criticidad altos (IEEE 1012)
Rigor de requisitos y diseño adecuados para 
procesos de pruebas, verificación y 
validación.
Duros de gestionar en proyectos de escasa 
criticidad
Dinamismo
“Re-factorizar” desde un diseño básico hasta 
el producto final es un método ideal para 
entornos dinámicos e in-novadores, pero 
muy caro por el “re-trabajo” para entornos 
estables o conocidos
En sistemas estables y conocidos, partir de 
requisitos completos y diseños detallados 
permite trazar y seguir un plan completo y 
“hacerlo bien a la primera”.
Personal
Los métodos de trabajo ágiles requieren una 
masa crítica de técnicos con niveles de 
experiencia medios-altos, capaces de 
comprender y adaptar los métodos y las 
técnicas empleadas.
Aunque es aconsejable contar con personas 
expertas en las fases de definición del 
proyecto, luego pueden ejecutarse con 
menor masa crítica de expertos.
Cultura
Más apropiado para culturas de 
“empowerment” responsabilidad y horquilla 
de decisión y libertad personal.
Más apropiado en culturas en las que las 
personas se sienten seguras con un marco 
de tareas y responsabilidades bien definido.
El ProcesoEl Proceso
El problema fundamental al querer conseguirEl problema fundamental al querer conseguir
productividad productividad yy calidadcalidad es la inhabilidad de es la inhabilidad de 
administrar el Proceso de Software. administrar el Proceso de Software. 
Síntomas de estoSíntomas de esto ::
Pérdida de ObjetivosPérdida de Objetivos
Visibilidad inadecuada de la administraciónVisibilidad inadecuada de la administración
Problemas de calidadProblemas de calidad
Baja en la moral del equipoBaja en la moral del equipo
Administración de Recursos - Garantía de 
Calidad del Software
AUS Fabiana María Riva 3
¿Por qué focalizarse en “El Proceso”?¿Por qué focalizarse en “El Proceso”?
Complementa la focalización en la tecnologíaComplementa la focalización en la tecnología
Por sí sola la tecnología no es efectiva, debe estar 
inmersa en un plan
Complementa la focalización en las personasComplementa la focalización en las personas
Generalmente falta capacitación en la fuerza de trabajo Generalmente falta capacitación en la fuerza de trabajo 
de las empresas que no se arregla con más trabajo. de las empresas que no se arregla con más trabajo. 
Esta concepción cambia el “culpable de las fallas” de Esta concepción cambia el “culpable de las fallas” de 
las personas al proceso.las personas al proceso.
Mitos Mitos 
No necesito procesos porque tengo:No necesito procesos porque tengo:
� Muy buena gente
� Tecnología avanzada
� Un experimentado administrador
Y los procesos:Y los procesos:
�� Interfieren con la creatividadInterfieren con la creatividad
�� Introducen burocraciaIntroducen burocracia
�� No son necesarios cuando se construyen prototiposNo son necesarios cuando se construyen prototipos
�� Sólo son útiles en grandes proyectosSólo son útiles en grandes proyectos
�� Cuestan muchoCuestan mucho
Procesos maduros vs. Procesos maduros vs. 
Procesos InmadurosProcesos Inmaduros
Un Un Proceso InmaduroProceso Inmaduro es fundamentalmente personal, no está documentado, es difícil es fundamentalmente personal, no está documentado, es difícil 
compartirlo con otros miembros del equipo, no es fácil reproducicompartirlocon otros miembros del equipo, no es fácil reproducirlo en nuevos rlo en nuevos 
proyectos, no proyectos, no hayhay entrenamiento, no todo el mundo lo conoce, no se mide, se aplicentrenamiento, no todo el mundo lo conoce, no se mide, se aplica a a a 
veces solamente, es percibido como poco eficiente, es interpretaveces solamente, es percibido como poco eficiente, es interpretado de manera distinta, do de manera distinta, 
etc.etc.
Un Un Proceso Maduro:Proceso Maduro:
Está DefinidoEstá Definido
Está DocumentadoEstá Documentado
El Personal ha sido entrenado en el ProcesoEl Personal ha sido entrenado en el Proceso
Es practicadoEs practicado
Es respaldado por la GerenciaEs respaldado por la Gerencia
Es mantenidoEs mantenido
Está controladoEstá controlado
Se verifica su aplicación a todos los proyectosSe verifica su aplicación a todos los proyectos
Se valida contra los estándaresSe valida contra los estándares
Se mideSe mide
Puede mejorarsePuede mejorarse
Aseguramiento de CalidadAseguramiento de Calidad
Modelos de Aseguramiento de CalidadModelos de Aseguramiento de Calidad
Series ISO 9000Series ISO 9000
CMMiCMMi
Series ISO 9000 (1994)Series ISO 9000 (1994)
Son cinco (5) normas
ISO-9000: definiciones y guías para la utilización de las normas.
ISO-9001, 9002 y 9003: enfoque de la calidad en situaciones contractuales (cliente-proveedor)
ISO 9001: Modelo para garantía de calidad en: 
� Diseño 
� Desarrollo 
� Producción 
� Instalación 
� Servicio postventa
ISO 9002: Modelo para garantía de calidad en: 
� Producción 
� Instalación 
ISO 9003: Modelo para garantía de calidad en: 
� Inspección Final 
� Pruebas 
ISO-9004: enfoque operacional para poner en marcha un sistema de calidad
Administración de Recursos - Garantía de 
Calidad del Software
AUS Fabiana María Riva 4
Series ISO 9000Series ISO 9000
La guía proporciona criterios para asegurar la conformidad de los siguientes 
aspectos del proceso de desarrollo: 
Política de calidad 
Gestión de la Calidad 
Manual de Calidad 
Procesos documentados y procedimientos 
Plan de desarrollo de proyectos 
Plan de Configuración 
Plan de Pruebas 
Plan de Servicio 
Archivos de Calidad 
Archivos de entrenamiento 
Sistema de auditorías de calidad interna 
Sistema de control de bibliotecas de software
Series ISO. Certificación.Series ISO. Certificación.
La certificación es un reconocimiento por un ente o ficial La certificación es un reconocimiento por un ente o ficial 
que la empresa satisface las exigencias de calidad que la empresa satisface las exigencias de calidad 
establecidas en la norma ISOestablecidas en la norma ISO --9001.9001.
Cuál es el interés de obtener la certificación?Cuál es el interés de obtener la certificación?
Externos:Externos:
�� Los clientes exigen la certificaciónLos clientes exigen la certificación
�� La certificación es un criterio de selecciónLa certificación es un criterio de selección
Internos:Internos:
�� La calidad del producto final depende de la calidad de los proceLa calidad del producto final depende de la calidad de los procesossos
�� Eficiencia, eficaciaEficiencia, eficacia
CapabilityCapability MaturityMaturity ModelModel IntegrationIntegration
Modelo de Madurez de CapacidadesModelo de Madurez de Capacidades
SEI (Software SEI (Software EngineeringEngineering InstituteInstitute ))
Universidad de Universidad de CarnegieCarnegie MellonMellon
http://www.sei.cmu.edu
El Origen del El Origen del CMMiCMMi
Múltiples modelos de capacidades se fueron 
creando a partir de la aparición del SW-CMM 
pero: 
• Todos con distintos formatos, terminologías y 
formas de medir la madurez 
• Confusos sobre todo cuando más de uno era 
utilizado a la vez
• Difíciles de integrar en un programa combinado 
de mejora
• Difíciles de utilizar en la selección de 
proveedores o subcontrataciones
El SWEl SW--CMMCMM
La estructura de SW-CMM por niveles está basada en principios de calidad del 
producto de Walter Shewart , W.Edwards Deming y Joseph Juran. 
Estos principios fueron adaptados por el SEI mediante un modelo que establece 
las bases de administración e ingeniería para el control de calidad del proceso 
de software y que es la base del proceso de mejoramiento continuo.
El modelo en el cual estos principios de calidad fueron adaptados está inspirado 
en el libro Quality is Free de Philip Crosby. 
La grilla de calidad de Crosby propone 5 niveles de evolución para adoptar 
prácticas de calidad. Este modelo fue adaptado por Watts Humphrey en IBM. 
Humphrey llevó este modelo al SEI en 1986, agregó el concepto de niveles de 
maduración y desarrolló las bases para su uso a través de la industria del 
software. 
Se desarrollaron 2 métodos en 1987: software process assessment y software 
capability evaluation. Desde 1990 el SEI ha expandido y refinado el modelo 
basado en años de experiencia en su aplicación en el mejoramiento de 
procesos de software.
Los productos del Los productos del CMMiCMMi