Aseguramiento de Calidad de Software+ Mario F Monsalve

Objetivos  Concepto  Procesos y actividades  Impacto  Rol de Estándares  Situación Actual  Resumen

Surgimiento  Cumplimiento total de especificaciones  Problemática de sistemas de Software Tensión en Requerimientos de calidad  Cliente (eficiencia, relaiabilidad, )  Desarrollador (mantenible, reusable) Especificaciones  Ambigüas  Incompletas  Inconsistentes  Clientes sorprendidos

Administración de Calidad  La gente cree que lo que hace está bién  Analogía Sexo vs Administración de Calidad Todo hace lo que sea por eso (bajo ciertas circunstancias) Todos sienten que lo entienden (aún se nieguen a explicarlo) Aplicarlo es seguir inclinaciones naturales Si hay problemas, recaen sobre las demás personas

Definición Calidad de Software  Asegurar que el nivel de calidad sea logrado en un producto de software, de acuerdo a características medibles conocidas  Involucra definición y uso de Estándares de calidad y de procesos  Control de variaciones Define métricas  Cultura de calidad Responsabilidad de todos

Calidad de software  Calidad de diseño Características que se especifican sobre algún ítem  Calidad de Conformismo Grado en que se siguen las especificaciones de diseño  “La gente no recuerda que tan rápido fue hecho, sino que tan bien fue hecho”H.N.

Aseguramiento de Calidad  Conjunto de reportes y auditorias  Asesora cumplimiento de actividades Efectividad Completamiento  Corregir errores Evitar defectos  Llegar a las metas

Historia  1950´s y 60´s. Recae responsabilidad sobre el programador  Contracto militar de software Se esparce rápidamente al software comercial Se define como un patrón de acciones planeadas y sistemáticas  Hoy Recae sobre todos los involucrados (ingenieros, administradores, clientes, vendedores, e individuos del grupo)

Costo de Calidad  Busca minimizar impacto ($)  Evaluar procesos  Costos de Prevención Planeación de calidad Entrenamiento  Costos de Evaluación Lo que sucede dentro de los procesos Mantenimiento Testing  Costos de Fallos Defectos (Errores no detectados) Bugs

Costos de Fallos  Ocurren después de entregado el producto  Fallo Interno Detectado por la organización, antes de entrega Reparación Se entra en modo de análisis  Fallo Externo Ocurre después de entregado al cliente Retorno del producto Resolución de Queja Garantía

Actividades  Grupo de software (Quienes ejecutan) Realizan actividades de calidad  Control  Métodos y medidas técnicas  Testing  Grupo de Aseguramiento de calidad de Software (Quienes planean y hacen tareas de control, análisis y reportes) Asiste al grupo de software Planean, analizan y dan reportes, Son un grupo independiente

Actividades  Realiza plan para el proyecto  Participa en desarrollo de la descripción del proceso de software Lo hace de acuerdo a políticas y a estándares definidos  Revisa actividades de ingeniería de software  Audita productos para prueba  Asegurar correcta documentación de las desviaciones del producto  Guarda y reporta incumplimientos hasta que se realicen de la manera adecuada  Se verifica cumplimiento de proceso de software  Se identifica y documenta desviaciones  Puede haber reportes

Análisis de Software / Impacto  “Err es humano”  Filtros para el proceso de software  Impacto de costo de Defectos de Software Psicológico 50% a 65 % de los errores y defectos se hacen en el diseño 75% de los errores se detectan con técnicas de análisis  Amplificación del defecto y eliminación “Algunos males son difíciles de reconocer al comienzo, pero fáciles de curar. Mientras que otros males con el tiempo son fáciles de reconocer pero difíciles de curar”

Análisis técnicos formales  Buscan descubrir errores de cualquier representación de software  Verifica que el software bajo análisis cumpla los requerimientos  Asegurarse que el software ha sido representado bajo algún Estándar  Desarrollo uniforme  Hacer los proyectos manejables

Guía de Análisis  Evaluar el producto, no el desarrollador Tono gentil en la evaluación No involucrar personas ni egos Dar sensación de cumplimiento  Mantener un agenda Bla bla blA  Limitar el debate Debatir impactos off-line  Enunciar áreas de problemas No se trata de solucionarlos inmediatamente  Tomar notas escritas Que el habla no se pierda  Limitar participantes Enfocarse en preparación  Checklist Enfocase en problemas importantes y mantener estructura  Calendarización  Entrenamiento de evaluadores  Evaluar anteriores análisis y evaluaciones

Análisis, reporte y registro  Informe Que se analizó Quien lo hizo Que se encontró Conclusiones  Distribución Líder del proyecto Partes interesadas

Aseguramiento de calidad de software estadístico  Refleja la tendencia en la industria, a sr mas cuantitativo en la calidad Información de los defectos deben ser categorizados Rastrear a que se debe exactamente el defecto  Violación de estándar  Diseño  No conformismo con la especificación  Comunicación con el cliente Principio de Pareto (80% causas rastrean al 20% de las causas) Corregir las causas vitales (20%)

Six Sigma  Estrategia de aseguramiento de calidad estadístico  Mas usado hoy en día  3 pasos Definir requerimientos, entregables, y metas del proyecto.  Comunicación con el cliente Medir procesos existentes y sus salidas  Determinar rendimiento de la calidad  Mejoras Eliminar raíz de las causas Controlar el proceso para evitar ampliación del problema Analizar métricas defecto y determinar causas vitales

Fiabilidad del software  “Probabilidad de que falle algún software en un ambiente específico, en un momento determinado”  Medidas de fiabilidad y disponibilidad Puede ser un fallo molesto o catastrófico  Tiempo de fallo = Tiempo en ocurrir + tiempo en ser arreglado Disponibilidad = Tiempo en ocurrir Tiempo en ocurrir + Tiempo de corrección

Fiabilidad de Softwae  Seguridad de Software Posibles riesgos que represente el software para el usuario Usualmente se aprovechan defectos o fallos de software No todo defecto o fallo termina en amenaza o riesgos Corrección  Debe ser tenido en cuenta en los análisis y evaluaciones del software

Situación Actual  Lo Ideal Avances en los últimos años Contribuir en las organizaciones a mejorar la gestión de los proyectos  Procesos de construcción de soluciones Consecución de un certificado  ISO 9001  Algún nivel de CMM Organizar la forma de trabajar  Ser mas eficiente  Productividad  Calidad de lo que se produce

Situación Actual  Fallas Manejo de versiones Estándares de desarrollo Documentación Integración de desarrollos multiplataforma Software propietario y libre  Varían de acuerdo a quién lo haga  Algunos en sus licencias no se responsabilizan Academia Industria

Bibliografía  Object-oriented software engineering : using UML, Patterns, and Javai, Bruegge, Bernd 2006  Ingeniería de Software, Ian Sommerville, 7ma Ediciión, 2006    sentations/index.html, sentations/index.html   html, html     pymes/calidad-sw-pymes.shtml, pymes/calidad-sw-pymes.shtml  