Atributos de Calidad del Software

Módulo 1: Atributos de Calidad del Software

• El principal objetivo para las empresas es lograr calidad, adaptándose a las necesidades del cliente
• Calidad en Ingeniería de Software es una característica o atributo que se puede medir
• Para la IEEE, un software de calidad cumple las expectativas del cliente y combina bien los atributos
• Para los usuarios, cero defectos es alta calidad por el impacto en su trabajo
• Para los gerentes, cero defectos es alta calidad por la posibilidad de recibir críticas
• Para los usuarios, mucha funcionalidad es alta calidad si se benefician de opciones implementadas
• Para los vendedores, mucha funcionalidad es alta calidad por el argumento de venta
• Para los usuarios, alto rendimiento es alta calidad si su trabajo está ligado al tiempo de respuesta
• Para los vendedores, alto rendimiento es alta calidad si las ventas asocian el tiempo de respuesta
• El bajo costo de desarrollo es alta calidad para los clientes que compran el software
• Para los PMs, el bajo coste de desarrollo es alta calidad para la construcción con presupuestos limitados
• La rapidez de la construccion es una alta calidad para los usuarios cuando esperan un nuevo producto
• La rapidez de la construccion es una alta calidad para los vendedores cuando quieren capturar el mercado primero
• Para los usuarios, la facilidad de uso es alta calidad cuando están aprendiendo cómo usar el producto

¿Qué es un Producto de Software con Calidad?

• Cero defectos es alta calidad
• Mucha funcionalidad es alta calidad
• Alto rendimiento es alta calidad
• Bajo coste de desarrollo es alta calidad
• Rapidez en la construcción es alta calidad
• Facilidad de uso es alta calidad

Problemas Asociados a la Calidad del Software

• La especificación de calidad se enfoca en las características del producto que el consumidor desea
• Hay dificultad para especificar características de calidad de forma no ambigua
• No es posible especificar un software de manera concreta; a pesar de que un producto cumpla con la especificación, los usuarios pueden no considerarlo de alta calidad si no cumple sus expectativas
• La solución es diseñar procesos de calidad que no dependan de una especificación perfecta
• La gestión de la calidad es lo más importante en la práctica

Actividades Principales en la Administración de Calidad de un Proyecto

• Garantía de la calidad: establecer un marco de procedimientos y estándares para un software de alta calidad
• Planificación de la calidad: adaptar el marco a un proyecto de software específico
• Control de calidad: definir y fomentar procesos para garantizar que se sigan los procedimientos y estándares
• Coste de calidad: considerar todos los costos en la búsqueda de la calidad
• Cuanto más cerca se está de finalizar el desarrollo del software, más costosa es su solución

Principios de Calidad del Software

• Se debe describir cuál es la calidad esperada y qué combinación de atributos se desean del software
• Los desarrolladores deben gestionar la calidad, comprometiéndose a desarrollos de calidad y revisando el funcionamiento y desarrollo de los productos
• Los desarrolladores deben medir la calidad para cuantificar errores y crear registros
• La calidad del producto se determina por el proceso usado para desarrollarlo, con alta probabilidad de calidad si el proceso y la materia prima son de alta calidad
• Las pruebas solo solucionan una fracción de los defectos, requiriéndose pruebas funcionales y no funcionales gestionadas de forma planificada y organizada

Calidad del Producto y del Proceso

• La calidad del proceso de desarrollo del software afecta directamente/tiene una influencia significativa en la calidad de los productos derivados
• La gestión y mejora de la calidad del proceso debe minimizar los defectos en el software entregado

Gestión de Calidad del Proceso

• Definir estándares que el proceso debe seguir
• Supervisar el proceso de desarrollo para asegurar que se sigan los estándares
• Elaborar informes del proceso para el gestor del proyecto y el comprador del software
• Los gestores de calidad deben utilizar estándares de proceso dependiendo del tipo de software para asegurar que el proceso de calidad ayude al desarrollo del producto

Factores / Atributos de Calidad del Software

• Factores/Atributos que afectan a la calidad del producto de software
• Correctitud/Funcionalmente Correcto: el producto se comporta según la especificación
• Confiabilidad/Confiable: el usuario puede depender de que el software opere como se espera en un tiempo especificado
• Robustez: Se comporta razonablemente, aun en circunstancias imprevistas
• Performance/Rendimiento: Usa los recursos económicamente y eficientemente
• Amigabilidad/Amigable: El usuario considera fácil de usar
• Verificabilidad/Verificable: Sus propiedades se pueden verificar fácilmente
• Mantenibilidad: modificaciones hechas después de la entrega inicial para corregir errores o mejorar el producto
• Mantenibilidad Reparabilidad: un software es reparable si permite corregir defectos con poco trabajo
• Mantenibilidad evolutiva/Evolutividad: productos de software modificados para nuevas funciones o cambios
• Portabilidad: Es portable si corre en distintos ambientes
• Interoperabilidad: Habilidad de un sistema para coexistir con otros, estandarización de interfaces
• Integridad: Controla accesos no autorizados a datos o software

Atributos de Calidad del Proceso

• Productividad: Mide la eficiencia, con una entrega rápida por la cantidad de recursos y código necesarios
• La reusabilidad del software influye en la productividad
• Oportunidad: Es la habilidad para entregar a tiempo, con metas definidas y buena estimación
• Visibilidad: Un proceso visible debe tener todos sus pasos y el estado actual documentados y accesibles

Pruebas de Caja Negra y Caja Blanca

• Dos maneras de probar un producto construido
• Caja negra: Prueba funciones específicas demostrando que operan plenamente; se aplica a la interfaz y examina aspectos funcionales sin revisar la estructura interna
• Caja blanca/cristal: Asegura que todas las piezas encajen probando rutas lógicas y colaboración entre componentes; en forma de prueba de ruta básica y es más costosa

Reglas de Calidad

• Tener una relación mutuamente beneficiosa con el proveedor
• Tomar decisiones basadas en hechos
• Que el crecimiento no rompa la calidad
• Participación del personal con compromiso y difusión de las mejores prácticas
• Ser proactivo y un rol modelo a seguir al cometer errores
• Enfoque a los procesos
• Nunca dar la calidad por hecho, tiene que ser lo primero
• Organizaciones se basan en los clientes, comprendiendo la necesidasd y trabajando para superarla

Unidad 2. Calidad del Software

• Ser proactivo y modelo a seguir al cometer errores
• Enfoque a los procesos
• Nunca dar la calidad por hecho, tiene que ser lo primero

Aseguramiento de la Calidad != Control de Calidad

• Aseguramiento de la calidad : Actividades planificadas y sistemáticas para asegurar que un producto cumple con los requisitos de calidad
• Control de la calidad: Verificar que un producto sea útil, seguro y cumpla sus funciones correctamente
• QC busca detectar problemas en los productos de trabajo y revisarlos, la meta es producir software usable
• QA busca asegurar la adherencia a los procesos y estándares y por eso guía y monitorea los procesos utilizados y monitorea las revisiones

Proceso de Software

• Conjunto de herramientas, métodos y prácticas usados para producir un producto de software

Testing

• Operar un sistema/componente bajo ciertas condiciones, observar y registrar resultados para después evaluarlos

Activos/Elementos del Proceso de Software

• Proceso (el qué): actividades para un propósito
• Procedimientos (el cómo): pasos específicos y criterios para cumplir las actividades
• Estándares: sabiduría de la comunidad de ingeniería
• Plantillas: bosquejo del producto de trabajo
• Producto de trabajo: resultados tangibles de un proceso
• Política: Compromiso adoptado por la organización
• Actividad: acciones tomadas para crear/producir
• Rol: persona, grupo o sistema que ejecuta actividades
• Calidad del producto del software

Quiénes Quedan Satisfechos

• Clientes, patrocinadores, usuarios, desarrolladores

Problemas Asociados a la Calidad

• Falta de comprensión del rol de la calidad
• Falta de confianza en el valor de la calidad
• Creer que Aseguramiento de Calidad (QA) es testing
• Falta de respeto hacia QA
• Existencia de estándares inútiles
• Soporte inadecuado desde la gerencia

Calidad del Producto desde la Visión de QA

• Objetivos de QA:
• Mejorar la calidad monitoreando productos de software y el proceso de desarrollo
• Asegurar el apego a los estándares y procesos

Las Funciones de QA

• Elevar a la gerencia cualquier desviación para que se tomen medidas
• Asistir a los equipos de proyectos en la elaboración de planes/procedimientos
• Dar seguimiento a las no conformidades elevadas

Responsabilidades de QA

• Las responsabilidades de aseguramiento de la calidad (QA) se cumplen durante todas las fases del ciclo de vida
• Asegurar la correctitud de los planes del proyecto y su seguimiento
• Asistir al equipo en la elaboración de productos de calidad
• Asegurar que los procesos sean usados y útiles

Planificación de QA (Plan de QA)

• La planificación de la calidad define la calidad de un software deseado y define lo que es software de "alta calidad"
• El plan de QA es un mapa para institucionalizar la garantía de calidad
• Checklists: ayudan a asegurar que se cubran las características de calidad
• Concisos y precisos, no más de una página
• Completo, identifica todos los puntos esenciales
• Genérico, se puede aplicar a diferentes productos
• Consistente, puntos expresados de la misma forma

Lista de verificación Estandarizada

• Al evaluar elementos de una checklist, se debe considerar la severidad, el efecto en otros productos, su clase (omisión, excedente, incorrecto) y la prioridad
• La severidad debe ser mayor menor
• El efecto sobre otros productos (si vertical - no horizontal)
• La clase puede ser omisión, excedente o incorrecto
• La prioridad es alta, media o baja

Evaluación de la Calidad del Software

• La calidad del producto: se evalúa la calidad del software para garantizar que cumpla con la calidad adecuada; se usan métricas validadas y aceptadas para verificar los atributos

Evaluaciones para asegurar la calidad

• Interna y externa: Un producto se ve desde adentro (si cumple con lo planificado) o desde afuera (si cumple con las expectativas del cliente)
• Calidad en uso: Perspectiva del usuario en un contexto específico
• Calidad a nivel de proceso: Programar calidad durante el ciclo de desarrollo
• Calidad a nivel de producto: Especificar y evaluar cumplimiento

Importancia de evaluar el producto para las organizaciones:

• Diferenciarse de la competencia asegurando tiempos de entrega
• Establecer acuerdos definiendo ciertos parámetros de calidad antes de la entrega
• Detectar defectos y eliminarlos antes del lanzamiento
• Evaluar y controlar el rendimiento
• Asegurar la seguridad

Beneficios de Evaluar la Calidad del Producto para los Organismos de Desarrollo

• Controlar la calidad del producto
• Mejorar las características del producto
• Asegurar a los clientes el nivel de calidad
• Comparar con productos de la competencia
• Posicionar el producto en el mercado
• Aumentar las ventas del producto

Beneficios de Evaluar la Calidad del Producto para los Organismos que Adquieren Software

• Conocer la calidad del producto que compran
• Comparar alternativas
• Establecer acuerdos de nivel de servicio
• Conseguir independencia del proveedor
• Minimizar fallos en producción
• Reducir costos finales de comparar

Métricas y Normas de Calidad

• Un modelo de calidad del software es un documento que recolecta buenas prácticas para evaluar la calidad
• La organización debe definir un proceso para mantener y evaluar la calidad

Problemas que Acarrean Desafíos al Desarrollar Modelos de Calidad Estándar

• Ausencia de asociación entre modelos de calidad y proceso
• Modelos de calidad no evolutivos ni mantenibles
• Modelos de calidad generales
• Negligencia del control de riesgo
• Falta de participación de interesados
• Subjetividad en la evaluación
• La ausencia de directrices o documentos necesarios

Métricas de Calidad del Software

• Son un conjunto de medidas para estimar la calidad de un proyecto a desarrollar
• Los atributos se conectan con las métricas ya que quieren evaluar su adherencia en el proyecto

Unidad 3. Proceso de Certificación

• La certificación del modelo de madurez es una herramienta para mejorar la calidad en el desarrollo
• Está basado en las normas ISO/IEC 12207 e ISO/IEC 33000
• El modelo además se alinea e integra fácilmente a ISO 27001 e ISO 25000

Modelos de Certificación ISO

• ISO 12207: Guía del ciclo de vida del desarrollo de software
• ISO 25000: Calidad del producto de software: Permite conocer la calidad y poder comprar y/o desarrollar

Resultados al Superar el Proceso de Auditoría

• Certificado del modelo de madurez de la ingeniería del software
• La licencia de uso de la marca madurez del software

Beneficios al certificar Software:

• Diferenciarse de los competidores (asegura tiempos y reduce fallos)
• Establecer acuerdos (Define ciertos parámetros de calidad antes de la entrega)
• Detectar defectos y eliminarlos antes de la entrega
• Evaluar y controlar el rendimiento
• Garantizar niveles de seguridad necesarios

Modelos de Calidad Personalizados basados en la norma ISO

• Los modelos evalúan procesos de desarrollo y establecen una evaluación que asegure repetibilidad y consistencia
• Evaluación del Proceso -> Conocer la capacidad de los procesos organizacionales y determinar la info que los caracteriza

ISO 14598: Evaluación del Proceso del Software

• 9126-1 Modelo de calidad
• 9126-2 Métricas externas
• 9126-3 Métricas internas
• 9123-4 Métricas de calidad en uso
• 14598-1 Visión General
• 14598-2 Planeamiento y gestión
• 14598-3 Proceso para desarrolladores
• 14598-4 Proceso para compradores
• 14598-5 Proceso para evaluadores
• 14598-6 Documentación de los módulos de evaluación
• Estándar ISO/IEC 15504 -> proceso de evaluación
• Planificar, hacer, verificar y actuar
• Auditoría interna (19011) -> Busca verificar el sistema de calidad, su eficacia en la implementación y el mantenimiento

Criterios a seguir en auditorías

• Criterios de Auditoría: Conjunto de políticas, procedimientos o requisitos usados como referencia.
• Evidencia de Auditoría: Registros, declaraciones o información pertinente que sea verificable
• Hallazgos: Resultados de la evaluación de la evidencia
• Programa de Auditoría: Conjunto de auditorías planificadas por un tiempo determinado
• Plan: de auditoría Descripción de las actividades en el sitio y los preparativos previos

Herramientas Para la Gestión de Calidad (Identificar el problema, encontrar las causas principales, elegir la mejor solución e implementar y medir resultados)

• Brainstorming: Ideas
• Diagrama causa y efecto/Ishikawa: Encontrar las causas principales del problema, se aplica la técnica de los 5 "porqués"
• Pareto: Identifica la causa principal de un problema y reduce las causas raiz, concentrandose en el 20% que produce el 80% de los problemas
• 5W2H: Planifica acciones futuras con el objetivo responder 7 preguntas: (Why, Who, Where, What, When, How, How much)
• Plan-Do-Check-Act (PDCA): resolucion sistematica para la mejora continua

Técnicas y Metodología sobre la Madurez del Proceso

• Modelo CMMI (Integración de Modelos de Madurez de Capacidades): Integra las disciplinas de software y sistema para mejora de procesos y tiene dos tipos de representación (continuos y staged)
• SCAMPI (Standard CMMI APPRAISAL Method for Process Improvement) : Busca la mejora interna, selección del suministrador y la monitorización de este

Costos de la calidad: Certificación ISO 25000

• Normas ISO/IEC 25000 proporciona una guía para usar los requerimientos y evaluación de calidad del producto (SQuaRE)

Módulo 4: Administración de Configuración

• Disciplina que controla la evolución del producto de software, identifica componentes y reporta/verifica cambios
• La administración de la configuración provee estabilidad al producto, definiendo los procedimientos
• Las herramientas de administración sirven para almacenar las versiones de los componentes
• Los gestores de configuración llevan el registro diferencias entre las distintas versiones
• El equipo de administración construye el sistema y gestiona las pruebas donde los fallos son devueltos al equipo de desarrollo.

Proceso de Administración de Configuración

• Disciplina de 5 partes que se genera un plan para describir qué, quién, cómo, dónde y cuándo se realizarán las tareas, alineadas al proyecto específico
• Plan de Administración: (Definición de ítems de configuración gestionados y su esquema formal
• Roles y responsabilidades de la Administración
• Políticas de la administración
• Descripción de las herramientas y el proceso a seguir
• Definición de las bases para registrar la información

Control de Configuración

• Se realiza una convención para identificar la línea base (Versión) en los niveles de revisión
• Se trabaja aproando mejoras necesarias, todo puesto bajo la custodia del equipo de administración
• El Consejo de Control de Cambios (CCB) aprueba o rechaza las peticiones con la opción de remitir informes de error
• En los procedimientos de administracion, se analizan costos, aprueban cambios y se registran los componentes a cambiar
• Las peticiones de cambio pueden ser via web enviando un informe de error desde alli, un equipo verificará el error y transformará la peticion

Estado de la Configuración

• Se registran y siguen los problemas y solicitudes de cambios
• Se crea una base de datos que registra todas la configuración

Tipos de Auditorías

• Auditorías de configuración funcional (FCA: Verifica que el elemento de configuración ha sido completado cumpliendo los atributos de calidad y su documentación operativa es satisfactoria
• Auditorías de configuración física (PCA: certifica que el elemento fue constituido conforme a la documentación que lo describe)
• Auditorías de gestión de la configuración: Confirma que los registros y elementos son completos, consistentes y precisos

Elementos de Configuración (Documentos Formales)

• Planes del proyecto
• Especificaciones
• Diseños
• Programas
• Conjuntos de datos (Los nombres de los documentos deben ser únicos)

Sistema de Administración de las Versiones (Utilizado para almacenar y gestionar los documentos formales)

• Cuando se crea una nueva versión del sistema se usa un proceso de administración del cambio que puede ser sencillo o complejo
• Los cambios individuales no necesitan ser evaluados
• Los cambios que afectan los módulos del sistema sí lo hacen

Gestión de Versiones

• Es el proceso de identificar y mantener registros de versiones de software
• Se diseñan para que puedan ser recuperados y distribuidos al cliente

Entrega del Software

• incluye además del código ejecutable, el archivo de config, los datos necesarios, los programas de instalación, documentación y el embalaje publicitario)

  Las Entregas Deben Estar Documentadas

• se debe registrar las versiones específicas de los componentes de código fuente usados

• La Revisión del Componente debe guardar registro de sus modificaciones

• El Nivel de Promoción define el estado del componente en un momento dado

• Siempre existen más versiones que entregas ya que algunas son para interno o pruebas

Administración de Versiones

• Gestiona cantidad de información asegurando que los cambios sean registrados y controlados
• Las herramientas de administración controlan un repositorio donde sus contenidos son inmutables

Módulo 5. Fundamentos del Testing

• El testing es proceso de operar un componente/sistema bajo determinadas condiciones
• Verifica si cumple ("¿Construyendo correctamente el producto?")
• Valida el programa ("¿Estoy construyendo el producto correcto?")

Fundamentos de las Pruebas de Software

• La prueba de software intenta identificar las fallas antes de ser liberada
  • Defectos en el código
  • Diferencia potencial entre lo que el código debe hacer y lo que realmente hace

El Testing NO ASEGURA que el Software no tenga Fallos, pero Sí Minimiza el Riesgo

• Para realizarlo hay que seleccionar a las personas adecuadas y comunicar sus resultados a los desarrolladores
  • Para ello, tener en cuenta las formas de comunicar de los probadores

Axiomas del Testing

1. El software siempre se testea.
2. Un buen caso de testeo es el que muestra que el programa no anda
3. Detener el testeo es difícil
4. Uno no puede autotestearse
5. Parte ineludible del test: Determinar el resultado esperado
6. Debe ser reproducible
7. Casos para condiciones válidas e inválidas
8. Inspeccionar todos los resultados
9. Crece la probabilidad de hallar pocos errores al avanzar el testeo
10. Programador-> Testeo de caja blanca
11. Usuario -> Testeo de caja negra
12. El testeo es parte del desarrollo
13. Nunca modificar un programa antes de testearlo

Los Errores se Hacen Evidente Como Defectos/Fallas

• ocurren al ejecutar los casos de prueba y se identifica el defecto que lo causa

Los Objetivos de V&V (Verificación y Validación) son:

1. Descubrir defectos (para corregirlos)

• Provocar fallas (una forma de detectar defectos).
• Revisar los productos (otra forma de detectar defectos)

2. Evaluar la calidad, dando idea de esta

Para Identificar y Corregir Defectos:

• Identificación de defectos proceso de determinar qué defecto causó la falla
• Corrección: Proceso de cambiar el sistema para remover los defectos

Para Identificar Defectos:

1. Comparar los resultados esperados contra los obtenidos
2. Revisar el código ya sea solo o en grupo

Proceso de Prueba

• Las pruebas deben realizarse buscando un resultado esperado y sus resultados deben revisarse al detalle
• El error es una acción humana, el defecto una manifestación de ese error en el código y la falla la manifestación del defecto al usar el sistema

Módulo 6. Diseño de casos de test

• El ensayo consume tiempo y dinero -> Encontrar la mayor cantidad de defectos en la menor duración posible

Definiciones

• Diseño de la prueba: Hacer el mejor ensayo posible consumiendo el mínimo tiempo y dinero
• Condiciones: Las situaciones que el sistema debe responder, que quieren probarse
• Casos: Lotes de datos necesarios para que se dé una condición de prueba
• Programa correcto: Combinación de datos de entrada válida y su salida es correcta Nota: La prueba exhaustiva es imposible

Estrategia de Pruebas

• Criterios de selección: Una condición para seleccionar un conjunto de casos de prueba
• Técnicas de prueba estática: Estáticas (analítica). Se analiza el producto para confirmar su correcta operación
• Análisis de código fuente, análisis automatizado de código fuente, análisis formal

Tipos de pruebas a realizar

1. Análisis de Código Fuente

• Es una actividad en grupo para revisar el código y buscar problemas y las estrategias son:
• Revisión de escritorio
• Recorrida/Inspección: Unifica el estilo de programación
• Es una reunión de no más de dos horas, los roles son:
  • Autor: Presenta, explica y se encarga de la ejecucion
  • Modera: Organiza la discusion
  • Secretario: Escribe el reporte

2. Análisis Automatizado

• Es una herramienta que recorre el código fuente y detecta posibles anomalías
• Es un análisis sintáctico de instrucciones y flujos

3. Análisis Formal

• Especifica y prueba si el programa cumple con los requisitos, sin embargo
• requiere demasiado matemática y puede ser incorrecto
• exige un componente a verificar

Técnicas de Prueba Dinámicas

• Sirven para experimentar sobre el comportamiento previsible de un producto y puede ser de caja blanca o negra

Caja Blanca

• Abarcar requerimientos/especificaciones y sus componentes usando una prueba estructural que prueba lo que el software hace desde la estructura interna (se precisa del código fuente)

Caja Negra

• Abarcar requerimientos/especificaciones
• Se entra a una caja negra y se ve la salida que genera (No se precisa del código fuente)

Clase de Equivalencia ("Pruebas por Partición de Equivalencia", "Pruebas basadas en Subdominios")

• Definición: Subconjunto de valores representativos de cada clase. Cada clase tiene la misma validez

Dos pasos para realizar la partición de equivalencia

1. Identificar las clases de equivalencia: Dividir cada clase en válida o inválida
2. Definir los casos de prueba

Análisis de Condiciones de Borde

• Los resultados que exploran los bordes dan mejores resultados que los que no lo hacen, seleccionando elementos donde se miren las condiciones de entrada y salida
• Se debe hacer para rangos, máximos/mínimos/valores cercanos, sets de datos/vacios/primeros registros/últimos

Guía Para Análisis de Frontera

• Se deben establecer casos de prueba válidos para límites/conjuntos

Conjetura de Errores, Prueba Basada en Sospecha

• Sospechar de errores por lo que se listan errores posibles o situaciones similares anteriores y se crean casos de prueba basados en esos
• El programador puede dar información relevante
• Esta técnica puede surgir de partes complejas del programa o circunstancias del desarrollo

Error Guessing

• Se basa en la intuición o experiencia de errores comunes, con la información histórica de defectos como ayuda

Pairwise

• Busca "clases de equivalencia" al establecer combinaciones equivalentes que luego testea

Comparación de las técnicas estática y dinámica

• Técnicas estáticas (análisis):
• Efectivas para encontrar defectos en etapas tempranas
• Conclusiones de validez general
• Sujeto a razonamiento, espeficicaciones etc
• No consideran el hardware o el software de base Dinámicas (pruebas)
• Sirven para verificar y validar
• Consideran el entorno, funcionalidad
• Atadas al contexto de la ejecución
• Detectan un error por prueba

Complejidad Ciclomática

• Métrica del Software que da cuantificación de la complejidad lógica. Se usa en: Cantidad de caminos independientes Camino independiente: agrega sentencias o condiciones