1
INGENIERÍA DEL SOFTWARE III
CALIDAD DEL SOFTWARE
Curso 2013/14
Departamento de Lenguajes y Sistemas Informáticos
Universidad de Sevilla
2
Contenidos
1. Introducción a la Calidad del Software.
2. Marco normativo relacionado con la calidad.
3. Factores y modelos de calidad.
4. Procedimientos de control de la calidad:
� Revisiones
� Pruebas
� Auditorías
� Evaluación de prototipos
5. Listas de control, guiones de recomendaciones y
elementos auxiliares.
6. Dossier del aseguramiento de la calidad.
7. Plan General de Aseguramiento de la Calidad.
3
Calidad� Conjunto de propiedades inherentes a una cosa, que
permiten apreciarla como igual, mejor o peor que las restantes de su especie (Diccionario de la Real Academia Española)
� Conjunto de características de un producto o servicio relativas a su capacidad para satisfacer unas necesidades dadas. (Norma UNE 66-001-92 traducción de ISO 8402) [AENOR, 1992]
Calidad del software� Proceso efectivo de software que se aplica de manera
que crea un producto útil, el cual proporciona un valor medible a quienes lo producen y a quienes lo utilizan (Pressman).
� Grado con el que un sistema, componente o proceso cumple:
� Los requisitos especificados� Las necesidades o expectativas del cliente o
usuario. (IEEE Std. 610-1990) [IEEE, 1993].
El concepto de calidad:� No es absoluto.� Está sujeto a restricciones.� Trata de compromisos aceptables.� Los criterios de calidad no son independientes.� Es multidimensional: funcionalidad, oportunidad, coste,
…
Introducción a la calidad del Software
4
Errores, defectos y fallos según Pressman:
� Error: problema de calidad encontrado antes de que el software sea distribuido a los usuarios finales
� Defecto o fallo: problema de calidad encontrado después de que el software haya sido distribuido a los usuarios finales
� Sin embargo, en general, la comunidad de ingeniería del software no suele hacer distinción entre los términos anteriores, considerándolos sinónimos
� Idealmente, los ingenieros del software deberían poder encontrar los problemas del mismo antes de que se distribuya a los usuarios
Introducción a la calidad del Software
5
Introducción a la calidad del Software
Gestión de Calidad
Aseguramiento de la calidadPlanificación de la calidad
Control de la calidad
Calidad de servicio
Calidad de la organización
Proceso de calidad
Calidad del producto
TQM
EFQM
CMMI
ITIL
ISO 9000:2005ISO/IEC 15504
ISO/IEC 12007 ISO 9126
Certificación
ItMark
SwTQM
TicKit
TPI/TMAP
MoProsoft
PSP/TSP
BOOTSTRAP
XP
RUP
SixSigma
MSF
Mejora de la calidad
Variedadde
conceptos
Variedadde
modelos
ISO/IEC 20000
ISO 9001:2008
ISO 9004:2000
ISO 90003:2004
Calidad total
Modelos de calidad
Sistema de gestión de la calidad
6
Introducción a la calidad del Software
Ciclo Shewhart (alias ciclo PDSA, alias ciclo Deming)
• En los años 20, Walter Shewhart de Laboratorios Bell (hoy parte de Alcatel) comenzó a aplicar la estadística a los procesos de manufactura, de manera que el trabajador pudiera estudiar y controlar la variación de dichos procesos.
• Una de sus aportaciones es el conocido “ciclo Shewhart”: un procedimiento iterativo para la mejora continua de un producto ode un proceso. El ciclo ya contenía las ideas (hoy en día muy populares) de realizar investigación del cliente para determinar sus necesidades reales, obtener realimentación de los clientes, y actuar basándose en dicha realimentación.
A P
S D
Plan: planificar un cambio o una prueba, encaminados hacia la mejora
Do: llevar a cabo el cambio o la prueba (preferiblemente a pequeña escala)
Study: estudiar los resultados. ¿Qué
hemos aprendido? ¿Qué ha ido mal?
Act: adoptar el cambio, o abandonarlo, o volver a
ejecutar el ciclo
7
Introducción a la calidad del Software
Ciclo Shewhart (alias ciclo PDSA, alias ciclo Deming)
• W. Edward Deming trabajó con Shewhart en los laboratorios Bell. Posteriormente se trasladó a Japón, donde popularizó el ciclo Shewhart durante los años cincuenta.
• Posteriormente, en los años 80, el ciclo Shewhart fue popularizado por Deming en EE.UU (véase su libro Out of the Crisis)
• El trabajo de Shewhart es considerado por Craig Larman y VictorBasili (2003) como la raíz del desarrollo iterativo e incremental en Ingeniería del Software.
• Varias ideas contenidas en el libro de Deming forman el germen de lo que hoy se deminina Total Management Quality:
• Es una filosofía de gestión empresarial basada en la mejora continua de la calidad de procesos y de productos, capitalizando la implicación de gestión, trabajadores, proveedores y clientes, de manera que se satisfagan o superen las expectativas de los clientes.
• TQM trasciende del ámbito de la producción al ámbito empresarial.
• Toma impulso a partir de los años ochenta.
8
Introducción a la calidad del Software
• Modelo de Excelencia EFQM (European Foundationfor Quality Management): trata de medir, mediante criterios e indicadores, el nivel de calidad de una organización.
http://www.efqm.org/sites/default/files/triptych.pdf
• Sistema de gestión de la calidad: permite a una organización alcanzar los criterios y satisfacer los indicadores de calidad.
9
Introducción a la calidad del Software
Gestión de la calidad: aspecto de la función general de lagestión que determina y aplica la política de calidad [AENOR].
Planificación de la calidad: parte de la gestión de la calidad enfocada alestablecimiento de los objetivos de la calidad y a la especificación de losprocesos operativos necesarios y de los recursos relacionados para cumplir los objetivos de calidad.
Aseguramiento de la calidad: conjunto de actividades planificadas ysistemáticas necesarias para aportar la confianza en que el producto satisfará los requisitos dados de calidad [AENOR, 1992].Conjunto de actividades para evaluar el proceso mediante el cual se desarrolla el producto. [IEEE].
Control de la calidad: técnicas y actividades de carácter operativo utilizadas para satisfacer los requisitos relativos a la calidad, centradas en dos objetivos fundamentales: mantener bajo control un proceso y eliminar las causas de defectos en las diferentes fases del ciclo de vida [AENOR].Proceso de verificar el propio trabajo o el de un compañero. [IEEE].
Mejora de la calidad: parte de la gestión de la calidad orientadaa aumentar la capacidad de cumplir con los requisitos de calidad.
10
Introducción a la calidad del Software
El coste de la calidad
� Boehm y Basili (2001): encontrar y reparar un problema software tras la entrega es a menudo 100 veces más caro que encontrarlo y repararlo durante las fases de requisitos y diseño. No obstante, en el caso de sistemas software pequeños y de naturaleza no crítica, el factor es más próximo a 5:1 que a 100:1. Sin embargo, el uso de buenas prácticas arquitectónicas puede reducir el factor de 100:1 incluso en sistemas grandes y críticos
Requisitos Diseño MantenimientoCodificación Pruebas
Coste (en dólares norteamericanos) de encontrar y corregir un defecto según la fase del desarrollo (estudio de Cigital (2007); véase Pressman)
$ 139$ 455
$ 977
$ 7136
$ 14102
Introducción a la calidad del Software
El coste de la calidad
� La calidad tiene un coste, pero la falta de calidad también
� Costes de prevención:
� Coste de actividades de gestión requeridas para planificar y coordinar las actividades de control de la calidad y de aseguramiento de la misma
� Coste de las actividades técnicas agregadas para desarrollar los modelos de requisitos y diseño completos
� Coste de planificar las pruebas.� Coste de la formación necesaria para realizar estas
actividades.
� Costes de evaluación:
� Coste de Revisiones Técnicas Formales para los elementos del desarrollo.
� Coste de recabar datos y medidas para la evaluación.� Coste de realizar las pruebas y depurar el código.
� Costes de fallos:
� Internos (antes del lanzamiento o de la entrega): revisión y reparación, coste adicional si una reparación genera nuevos defectos, coste de la recolección de métricas de calidad
� Externos (asociados con defectos encontrados después de que el producto haya sido entregado al cliente): resolución de quejas, devolución y sustitución del producto, ayuda en línea, coste de la mala reputación, etc.
12
Introducción a la calidad del Software
Principios básicos de la calidad del software
� Debe construirse durante todo el ciclo de vida del
proyecto.
� Sólo se alcanza con la contribución de todas las
personas involucradas.
� Se debe planificar y gestionar con eficacia.
� Se debe invertir recursos en la prevención de
defectos.
� Se deben reforzar los sistemas de detección y
eliminación de defectos durante las primeras fases
del proyecto.
� Es un parámetro importante del proyecto al igual que
los plazos de entrega, coste y productividad.
� Es esencial que se involucre la dirección.
13
Introducción a la calidad del Software
Actividades básicas que garantizan la calidad del software
� Establecimiento de un plan para el aseguramiento de la calidad del proyecto:
� Se desarrolla durante la planificación del proyecto
� Se revisa por todas las partes involucradas
� Aplicación de metodologías y herramientas en el desarrollo.
� Ajuste a los estándares y normas establecidos, ajustándose en todo momento a la política de empresa.
� Realización de revisiones técnicas formales.
� Controlar los cambios.
� Recopilación y análisis de métricas para evaluar tanto la calidad del producto como la calidad del proceso.
� Verificación y validación del software.
� Realización de pruebas
� Revisión de las actividades de IS:
� Seguimiento de las desviaciones
� Verificación de la realización de las correcciones
� Asegurar la documentación de las desviaciones
� Registrar lo que no se ajuste a los requisitos
� Elaboración de bases históricas e informes.
14
Introducción a la calidad del Software
Equipo de aseguramiento de la calidad� Es el encargado de realizar el aseguramiento de la calidad
del software.
� Sus miembros deben tener como características:� Titulación informática y experiencia en desarrollo de software.
� Conocimiento de la organización.
� Conocimiento de las metodologías de desarrollo y de los métodos y técnicas de control de calidad.
� Capacidad de comunicación oral y escrita.
� Capacidad de interrelación personal.
� Capacidad de hacer frente a problemas.
� Capacidad de diálogo.
� Sus funciones son:� Establecer el plan SQA del proyecto.
� Participar en la definición del proceso de software del proyecto.
� Revisar las actividades de ingeniería de software aplicadas en el proyecto.
� Auditar los productos software obtenidos.
� Garantizar la documentación de las desviaciones detectadas.
� Registrar las diferencias respecto a los requisitos.
� Decidir las acciones correctoras necesarias.
� Desarrollar herramientas de prueba.
� Coordinar el control y la gestión de cambios.
� Recopilar y analizar las métricas del software.
15
Introducción a la calidad del Software
Ámbitos del aseguramiento de la calidad� A nivel de empresa u organización consiste en la creación de
una estructura organizativa apropiada para fomentar el trabajo por la calidad de todas las personas y departamentos de la empresa.
� En cada proyecto de desarrollo se deben aplicar las directrices de calidad fijadas a nivel de la organización. Para ello es imprescindible la adaptación de las mismas a las condiciones de cada proyecto.
� Un producto o servicio de calidad es el que satisface las necesidades del cliente.
16
Contenidos
1. Introducción a la Calidad del Software.
2. Marco normativo relacionado con la calidad.
3. Factores y modelos de calidad.
4. Procedimientos de control de la calidad:
� Revisiones
� Pruebas
� Auditorías
� Evaluación de prototipos
5. Listas de control, guiones de recomendaciones y
elementos auxiliares.
6. Dossier del aseguramiento de la calidad.
7. Plan General de Aseguramiento de la Calidad.
17
Marco normativo relacionado con la calidad
� Norma: documento establecido por consenso y aprobado por un organismo reconocido, que proporciona para uso común y repetido, reglas directrices o características para ciertas actividades o sus resultados, con el fin de conseguir un grado óptimo en un contexto dado.
� Principales organismos de normalización:
InternationalElectrotechnicalCommission
European Committee forElectrotechnical Standardization
BritishStandardsInstitution
DEUTSCHESINSTITUTFÜR NORMUNG
18
Marco normativo relacionado con la calidad
Estándares ISO: etapas
Stage name Product name Acronym
Preliminarystage
Preliminary workitem (project)
PWI
Proposal stage New proposal for a work item
NP
Preparatorystage
Working draft(s) WD
Committeestage
Commitee draft(s) CD
Enquire stage Draft International Standard
DIS
ApprovalStage
Final draftInternational Standard
FDIS
Publicationstage
International Standard
IS
Ref: International Organization for Standardization
19
Marco normativo relacionado con la calidad
Estándares de calidad ISO 9000
� Los sistemas de aseguramiento de la calidadtienen como objetivo ayudar a las organizaciones a asegurarse de que sus productos y serviciossatisfacen las expectativas de sus clientes
� Dichos sistemas cubren un amplio abanico de actividades que abarcan el ciclo de vida completode un producto, incluyendo la planificación, el control, la medida, las pruebas y los informes, y mejorando los niveles de calidad a través del proceso de desarrollo y manufactura
� La organización ISO (International Organization forStandardization) ha producido un conjunto de estándares para la gestión y el aseguramiento de la calidad conocidos colectivamente como ISO 9000.
� ISO 9000 describe elementos de aseguramiento de la calidad en términos genéricos, que puedenaplicarse a cualquier negocio independientementede los productos o servicios que ofrezca
20
Marco normativo relacionado con la calidad
Grupo de normas ISO 9000
� ISO 9000:2005. Sistemas de gestión de calidad-Fundamentos y vocabulario: describe los fundamentos de los sistemas de gestión de la calidad y especifica la terminología para los sistemas de gestión de la calidad.
� ISO 9001:2008. Sistemas de gestión de la calidad-Requisitos: especifica los requisitos para un sistema de gestión de la calidad para organizaciones que:
� 1) Necesiten demostrar su capacidad para proporcionar (de manera consistente) productos que satisfagan los requisitos de sus clientes
� 2) Tengan como objetivo mejorar la satisfacción del cliente.
� ISO 9004:2000. Sistemas de gestión de la calidad-Directrices para la mejora del rendimiento. Tiene por objetivo y está orientada hacia la mejora del rendimiento de la organización
� ISO 90003:2004. Guías para la aplicación de ISO 9001:2000 al software: adquisición, suministro, desarrollo, operación, mantenimiento y soporte. (NOTA: ISO 9001:2000 ha sido posteriormente revisado por ISO 9001:2008)
21
Marco normativo relacionado con la calidad
ISO 9000� Aspectos positivos:
� Es un elemento competitivo para las empresas.� Proporciona confianza a los clientes.� Ahorra tiempo y dinero una vez que está implantado.� Implantado en más de 90 países y en todo tipo de
empresas industriales y de servicios.� Proporciona cierta seguridad de que las cosas se
hacen tal y como se han dicho que se han de hacer.
� Aspectos negativos:� Es costoso de implantar, especialmente en las
pequeñas empresas.� Muchas veces se hace por obligación. � Puede existir diferentes interpretaciones de los
apartados del estándar.� Existe publicidad engañosa.
La importancia de estos estándares radica en que permiten la certificación a las empresas.
22
Marco normativo relacionado con la calidad
Certificación
• Acción llevada a cabo por una entidad reconocida como confiable e independiente de las partes interesadas, mediante la que se manifiesta la conformidad de una empresa, producto, servicio o persona con los requisitos definidos en normas o especificaciones técnicas. [AENOR]
• No todos los modelos son certificables.
• ENAC (Entidad Nacional de Acreditación)• Organismo designado por la Administración española para establecer y mantener el sistema de acreditación a nivel nacional, de acuerdo a normas internacionales, siguiendo en todo momento las políticas y recomendaciones establecidas por la Unión Europea.• Su misión es evaluar la competencia técnica de los organismos de evaluación de la conformidad-Laboratorios, Entidades de Inspección, de Certificación, Verificadores- para generar así confianza en sus actividades a la Administración, al mercado y a la sociedad en general.
23
Marco normativo relacionado con la calidad
Certificación
• Otras entidades de certificación:• ISO• SEI (Software Engineering Institute). • ESI (European Software Institute).
Motivaciones para la certificación personal• Promoción interna e incrementar salario y seguridad laboral.• Validación profesional sin título académico específico.• Satisfacción personal.• Mayor movilidad profesional en el ámbito nacional e internacional.
Motivación para la certificación de la organización• Diferenciarse de la competencia.• Ofrecer mayor garantía a los clientes.• Mejorar los procesos organizativos y de producción.• Disminución de costes a largo plazo.• Mayor facilidad para abrir nuevos mercados.• Mayor garantía en la calidad de los productos o servicios.• Aumentar la motivación del personal.
• Principales modelos: CMMI, ISO/IEC 15504, ItMark, SwTQM, TickIT, etc.
24
Marco normativo relacionado con la calidad
Eleccióndel
modelo
Evaluación de lasituación de laorganización
Comparación de lasituación
actual con lasexigencias
modelo
Diseño de unproyecto de
mejora
Realización de laevaluación
que conlleva a lacertificación
Proceso de certificación
25
Contenidos
1. Introducción a la Calidad del Software.
2. Marco normativo relacionado con la calidad.
3. Factores y modelos de calidad.
4. Procedimientos de control de la calidad:
� Revisiones
� Pruebas
� Auditorías
� Evaluación de prototipos
5. Listas de control, guiones de recomendaciones y
elementos auxiliares.
6. Dossier del aseguramiento de la calidad.
7. Plan General de Aseguramiento de la Calidad.
26
Factores y Modelos de Calidad
Según McCall, la calidad del producto software se sustenta en una compleja mezcla de once factores, agrupados en tres categorías: revisión del producto, transición del producto, y operación del producto.
Transición del producto• Portabilidad.• Reusabilidad.• Interoperatividad.
Revisión del producto• Facilidad de mantenimiento.• Flexibilidad.• Facilidad de prueba.
Operacióndel producto• Corrección.• Fiabilidad.• Usabilidad.• Integridad.• Eficiencia.
Modelo de calidad de McCall: factores de calidad
Revis
ión
Transición
Operación
27
Factores y Modelos de Calidad
• Facilidad de auditoría (FA).• Exactitud (EX).• Normalización de comunicaciones (NO).• Completitud (COT).• Complejidad (COJ).• Concisión (COC).• Consistencia (COS).• Estructuración de datos (ES).• Tolerancia al error (TO).• Eficiencia en la ejecución (EF).• Facilidad de expansión (FAE).• Generalidad (GE).• Independencia del hardware (INH).• Instrumentación (INS).• Modularidad (MO).• Facilidad de operación (FAO).• Seguridad (SE).• Autodocumentación (AU).• Simplicidad (SI).• Independencia del entorno software (INS).• Trazabilidad (FAT).• Formación (FO).
Modelo de calidad de McCall: métricas de calidad
28
Factores y Modelos de Calidad
Modelo de calidad de McCall: relación entre las métricas de calidad y los factores de calidad
Modelo de McCallMétricas de la calidad del software
Factores de calidad
29
Factores y Modelos de Calidad
Modelo de McCall: cálculo
• Cada métrica se estima en la escala de 0 a 10.
• Para cada factor de calidad se calcula:n
Fc = Σ Ci � mii=1
siendo:
Fc : valor cuantitativo del factor de calidad.mi : valor asignado a la métrica (de 0 a 10).Ci : peso (tanto por uno) de la métrica en el factor de
calidad. Si la métrica no tuviera relevancia para elfactor, Ci=0
n: número de métricas
Σ Ci = 1
30
Statistical Software Quality Assurement(SQA Estadística)
Refleja la tendencia creciente en la industria de concebir la calidad desde un punto de vista más cuantitativo.
Pasos:
1. Se recoge y se clasifica la información sobre los
defectos del software durante un tiempo determinado.
2. Se intenta encontrar la causa subyacente de cada error
y de cada defecto (por ejemplo: no conformidad con
las especificaciones, error de diseño, violación de
estándares, comunicación pobre con el usuario).
3. De entre todas las causas posibles de errores y
defectos, aislar el 20% que origina la mayoría de los
defectos (las denominadas “causas vitales”). Según
el principio de Pareto, el 80% de los defectos puede
deberse al 20% de todas las causas posibles.
4. Una vez identificadas las causas vitales, se actúa para
corregir los problemas que han originado los defectos.
Tiene como objetivos:
• Detectar los errores que más se producen y analizar
sus causas.
• Medir la calidad de los proyectos.
Factores y Modelos de Calidad
31
SQA Estadística (continuación)
Las causas de error más comunes son:
1. Especificación incompleta o errónea (EIE).
2. Mala interpretación de la comunicación con el
cliente/usuario (MCC).
3. Desviación deliberada de la especificación (DDE).
4. Incumplimiento de los estándares de programación
(IEP).
5. Error en la representación de los datos (ERD).
6. Interfaz de módulo inconsistente (IMI).
7. Error en la lógica de diseño (ELD).
8. Prueba incompleta o errónea (PIE).
9. Documentación imprecisa o incompleta (DII).
10. Error en la traducción del diseño al lenguaje de
programación (TLP).
11. Interfaz hombre-máquina ambigua o inconsistente
(IHM).
12. Varios (VAR).
Factores y Modelos de Calidad
32
SQA Estadística (continuación)
Para aplicar este método se debe recopilar la información en
forma de tabla. Una vez determinadas las causas vitales, la
organización de desarrollo de software puede comenzar las
acciones correctivas.
Por ejemplo:
100435100379100128100942TOTAL
94151500556VAR
4841723328IHM
6265191215660TLP
31452022436DII
11489359121095PIE
4193121114545ELD
8361868202614130ERD
73151879658IMI
21041500325IEP
52362411548DDE
1776186891217156MCC
241031868273422205EIE
%Nº%Nº%Nº%NºError
LeveModeradoGraveTotal
Factores y Modelos de Calidad
33
SQA Estadística (continuación)
Además de la recopilación de información de los defectos,
los equipos de desarrollo pueden calcular un Índice de
Errores (IE) para cada proyecto.
• Para cada etapa del ciclo de vida se recopila:• Ei : nº total de defectos descubiertos en la etapa i.
• Si : nº de defectos graves.
• Mi : nº de defectos moderados.
• Ti : nº de defectos leves.
• Sean Ws, Wm, Wt los factores de peso de errores graves,
moderados y leves, respectivamente. Los valores
recomendados son Ws=10, Wm=3 y Wt=1. Sin embargo,
los valores de los factores para cada fase deberían
aumentarse a medida que el desarrollo progresa, de manera
que se beneficie el encontrar errores temprano.
• Se calcula el índice de fase (IFi):
IFi = Ws (Si/Ei) + Wm (Mi/Ei) + Wt (Ti/Ei)
• Para calcular el índice de errores:n
IE = Σ (i * IFi) / PS = (1*IF1 +. . . + n*IFn) / PS
i =1siendo PS el tamaño del producto (LDC, sentencias de diseño, páginas de documentación, etc).
Factores y Modelos de Calidad
34
Contenidos
1. Introducción a la Calidad del Software.
2. Marco normativo relacionado con la calidad.
3. Factores y modelos de calidad.
4. Procedimientos de control de la calidad:
� Revisiones
� Pruebas
� Auditorías
� Evaluación de prototipos
5. Listas de control, guiones de recomendaciones y
elementos auxiliares.
6. Dossier del aseguramiento de la calidad.
7. Plan General de Aseguramiento de la Calidad.
35
Procedimientos de control de la calidad: tipos
Procedimientos de control:
• Revisiones: aplicables a productos documentales en las
fases inicial e intermedias del proyecto.
• Pruebas: aplicables a productos software ejecutables.
• Auditorías: pretende garantizar la tarea del EDS y del
EGC.
• Evaluación de prototipos.
36
Procedimientos de control de la calidad: revisiones
Revisiones
• Pretenden detectar manualmente defectos, mediante la lectura, en productos documentales.
• Objetivos: encontrar defectos, conseguir mayor entendimiento, generar discusiones y tomar decisiones por consenso.
• Roles en el equipo de revisión:
• Moderador: dirige y coordina el proceso de revisión.• Autor: persona que ha elaborado el documento.• Documentador: toma notas en la reunión de revisión.• Revisor: persona que realiza la evaluación del documento.• Supervisor: además de involucrarse en la revisión, decide abordar la revisión, determinar si se han cumplido los objetivos y quien decide ejecutarla.
37
Procedimientos de control de la calidad: revisiones
Planificación: selección de participantes y definición de roles.
Lanzamiento (reunión de arranque): explicación del producto y delpropio proceso de revisión.
Preparación: los participantes trabajan de forma individual sobre eldocumento en revisión.
Seguimiento: el moderador velará porque se tomen las acciones queprocedan sobre los defectos registrados, sugerencias de mejora y solicitudesde cambio. Realizará mediciones sobre el proceso de revisión para analizarposteriormente.
Reunión de revisión:• Fase de registro: se enumeran y se clasifican (críticos,mayores y menores) los defectos encontrados en la preparación.• Fase de discusión: se discutirá sobre los aspectos encontradosen el documento.• Fase de decisión: se decidirá sobre la validación o no deldocumento.
Corrección: en función de los defectos detectados, el autor mejorará eldocumento bajo revisión
Revisiones: fases
38
Informal: de bajo coste, no formal; no precisa documentarse; centrada en aspectos muy generales.
Revisión técnica: se centra en conseguir consenso sobre el contenido técnico de un documento; busca en alguna medida la identificación de defectos; puede hacerse revisión por pares.
Inspección: revisión minuciosa; se centra en la identificación de defectos y en su eliminación.
Formalidad
baja
alta
Revisiones: tipos
Procedimientos de control de la calidad: revisiones
39
PruebaPrueba
Modelo de Modelo de FiabilidadFiabilidad
DepuraciDepuraci óónn
EvaluaciEvaluaci óónn
ConfiguraciConfiguraci óónndel Softwaredel Software
ConfiguraciConfiguraci óónnde lade la
PruebaPrueba
FallosFallos
CorrecionesCorreciones
PredicciPredicci óónnFiabilidadFiabilidad
Resultados Resultados esperadosesperados
Resultados de Resultados de la pruebala prueba
Datos de tasa Datos de tasa de errorde error
Pruebas
Contexto de la Prueba de Software
Procedimientos de control de la calidad: pruebas
40
Las pruebas no demuestran la ausencia de errores nidefectos: tan sólo muestran si los hay.
CARACTERÍSTICAS DE UNA BUENA PRUEBA� Una buena prueba ha de tener una alta probabilidad de
encontrar un fallo. � Una buena prueba no debe ser redundante. � Una buena prueba debería ser la “mejor de la cosecha”. � Una buena prueba no debería ser ni demasiado sencilla
ni demasiado compleja.
FASES DE LA PRUEBA� Diseño de las pruebas (¿técnicas?)� Generación de casos de prueba (¿datos de prueba?)� Definición del procedimiento de la prueba (¿cómo,
donde?� Ejecución de la prueba� Informe de la prueba (¿resultados?)
TÉCNICAS DE PRUEBA� Pruebas estructurales o de caja blanca.� Pruebas funcionales o de caja negra.
Procedimientos de control de la calidad: pruebas
41
Pruebas estructurales o de caja blanca
� Atienden al comportamiento interno y la estructura del programa, examinando la lógica interna.
� Diseñar casos de prueba para que se ejecuten:� Todas las sentencias al menos una vez� Todas las condiciones con valor verdadero y falso.
� Información de entrada: diseño y código.� Hay distintos criterios de cobertura, como la cobertura de
caminos
Cobertura de caminos� Camino: Secuencia de sentencias encadenadas desde la
entrada del programa hasta su salida.� Diseñar casos para caminos independientes:
� Todas las sentencias se ejecutan al menos una vez.� Las condiciones son probadas para valores verdadero y
falso.
� Estudiaremos una técnica de pruebas de caja blanca conocida como la técnica del camino básico.
Procedimientos de control de la calidad: pruebas
42
Pruebas de caja blanca: técnica del camino básico
� Se basa en la medida de complejidad ciclomática de McCabe.
� Consta de los pasos:� Representación del programa como grafo de flujo.� Cálculo de la complejidad ciclomática.� Determinación de un conjunto básico de caminos
linealmente independientes.� Derivación de los casos de prueba.
Procedimientos de control de la calidad: pruebas
43
Pruebas de caja blanca: técnica del camino básico
Representación del programa como grafo de flujo
Notación� Nodos. Representan cero, una o varias sentencias.� Aristas: Unen dos nodos.� Regiones: Áreas delimitadas por aristas y nodos. Para
contarlas, se incluirá la externa.� Nodos Predicado: Surgen al descomponer las
sentencias condicionales compuestas en simples.
Secuencia While
CASE
opción1
opción N
END CASEopción2
if
Repeat
Procedimientos de control de la calidad: pruebas
44
Aristas
Nodos
Región
1
2
3
5 6
7
4
8
9
IF a OR b
THEN
xELSE
y
ENDIF
a
y
b x
Nodos Predicado
False True
False
Pruebas de caja blanca: técnica del camino básico
Representación del programa como grafo de flujo
Procedimientos de control de la calidad: pruebas
45
Pruebas de caja blanca: técnica del camino básico
� Complejidad ciclomática� Métrica software para averiguar la complejidad lógica de
un programa.� Pone límite superior al número de caminos a recorrer.
� Representando como V(G) la complejidad ciclomática de un grafo G:
� V(G) = Número de regiones
� V(G) = Aristas - Nodos + 2
� V(G) = Número de nodos predicado + 1
Aristas
Nodos
Región
R1R1
R2R2
R3R3
R4R4
1
2
3
5 6
7
4
8
9
V(G) = Número de regiones = 4V(G) = Aristas – Nodos + 2 =
11-9 + 2 = 4V(G) = Nodos Predicado + 1 =
3 +1 = 4
Procedimientos de control de la calidad: pruebas
46
Pruebas de caja blanca: técnica del camino básico
• Camino independiente es cualquier camino del programa que introduce, al menos, un nuevo conjunto de sentencias de proceso o una nueva condición, respecto a los caminos existentes.• Elegir como primer camino un camino principal que atraviese el máximo número de decisiones en el grafo.• Definir los restantes caminos a partir del análisis de los diferentes nodos predicados• Para el ejemplo anterior, el conjunto básico de caminos independientes sería:
• Camino 1 : 1-2-3-6-7-8-1-9• Camino 2 : 1-2-3-5-7-8-1-9• Camino 3 : 1-2-4-8-1-9• Camino 4 : 1-9
� Cada caso de prueba se diseñará de tal modo que corresponda a cada uno de los caminos elegidos.
� PROBLEMA: El número ciclomático no da idea acerca de la complejidad de los datos.
Número de Camino Caso de Prueba Resultado Esperado
Procedimientos de control de la calidad: pruebas
47
Pruebas funcionales o de caja negra
� Se utiliza la especificación del componente� El componente se ve como una caja negra.� Se estudia el comportamiento a partir de entradas y salidas.� Técnicas:
� Particiones de Equivalencia
� Análisis de Valores Límite
Procedimientos de control de la calidad: pruebas
48
Pruebas de caja negra: técnica de las particiones de equivalencia
� Se basa en dos consideraciones:� Se debe dividir el dominio de entrada de un programa en
clases de datos (clases de equivalencia) a partir de las que se pueden derivar los casos de prueba.
� Idealmente, con esta técnica, un único caso de prueba descubrirá toda una clase de errores.
� Dos pasos:1. Identificar las clases de equivalencia.2. Elaborar los casos de prueba.
� Una relación de equivalencia es aquella simétrica, transitiva y reflexiva. Si un conjunto de elementos satisface una relación de equivalencia, dicho conjunto forma una clase de equivalencia. Cada miembro de la clase es equivalente (con respecto a la relación) a cualquier otro de la clase.
� En un programa, una clase de equivalencia representa un conjunto de estados válidos o no válidos para las condiciones de entrada del programa.
Procedimientos de control de la calidad: pruebas
49
Pruebas de caja negra: técnica de las particiones de equivalencia
� Heurísticas para identificar clases de equivalencia para una condición de entrada:
� Si la condición se trata de un rango de valores, definir una clase válida y dos inválidas.
� Si la condición especifica el número de valores, definir una clase válida y dos inválidas.
� Si la condición especifica un conjunto de valores de entrada, y hay alguna razón para creer que el programa los trata de manera diferente, definir una clase válida para cada uno y una inválida.
� Si la condición especifica una situación del tipo “debe ser”, identificar una clase válida y una inválida.
� Si hay alguna razón para creer que el programa no trata los elementos de una clase de equivalencia del mismo modo, dividir la clase en subclases más pequeñas.
Procedimientos de control de la calidad: pruebas
50
14: primer carácter no es letra
13: primer carácter es letra
Debe serEl primer carácter del identificador debe ser una letra.
12: otro tipo7: tipo= Autobús8: tipo= Camión9: tipo= Taxi10: tipo= Turismo11: tipo= Moto
Conjunto de valores
El tipo del vehículo puede ser Autobús, Camión, Taxi, Turismo, Moto
5: personas <= 06: personas > 6
4: 1<= personas <= 6Número de valores
De 1 a 6 personas pueden figurar como propietarias de un automóvil
Condición de entrada Tipo Clases de Equivalencia Válidas
Clases de Equivalencia No Válidas
El número de artículos puede ir de 1 a 999
Rango 1: 1<= artículos <= 999 2: artículos < 13: artículos > 999
Pruebas de caja negra: técnica de las particiones de equivalencia
Procedimientos de control de la calidad: pruebas
51
Pruebas de caja negra: técnica de las particiones de equivalencia
El siguiente paso es crear los casos de prueba:
1. Asignar un número único a cada clase de equivalencia.
2. Hasta que todas las clases de equivalencia válidas hayan sido cubiertas por algún caso de prueba, escribir un nuevo caso de prueba que cubra tantas clases válidas no cubiertas como sea posible.
3. Hasta que todas las clases de equivalencia inválidas hayan sido cubiertas, escribir un nuevo caso de prueba que cubra una, y sólo una, clase de equivalencia inválida no cubierta.
Procedimientos de control de la calidad: pruebas
52
Pruebas de caja negra: técnica de las particiones de equivalencia
Ejemplos para el primer problema:
Caso de prueba 1: artículos=5 (cubre clase 1)
Caso de prueba 2: artículos=0 (cubre clase 2)
Caso de prueba 3: artículos= 1500 (cubre clase 3)
Ejemplos para el segundo problema:
Caso de prueba 1: personas= 4 (cubre clase 4)
Caso de prueba 2: personas=-2 (cubre clase 5)
Caso de prueba 3: personas= 10 (cubre clase 6)
Procedimientos de control de la calidad: pruebas
53
Pruebas de caja negra: técnica del análisis de valores límite
� Consideremos un programa que lee tres valores enteros de un diálogo de entrada. Los tres valores representan las longitudes de los lados de un triángulo. El programa muestra un mensaje que indica si el triángulo es equilátero, isósceles o escaleno.
� Una primera condición es que los enteros deben ser mayores que 0 y la suma de dos cualesquiera debe ser mayor que el tercero (si no, ni siquiera es un triángulo).
Primeras clases de equivalencia:
� Clase 1 (válida): los tres enteros mayores que 0
� Clase 2 (inválida): algún entero menor que 0
� Clase 3 (válida): suma de dos cualesquiera mayor que el tercero
� Clase 4 (inválida): existen dos cuya suma es menor o igual que el tercero
Casos de prueba por técnica de particiones equivalentes:
� Test 1: 3, 4, 5 (cubre clases 1 y 3)
� Test 2: 3, 4, -1 (cubre clase 2)
� Test 3: 1, 2, 4 (cubre clase 4)
Procedimientos de control de la calidad: pruebas
54
Pruebas de caja negra: técnica del análisis de valores límite
� Problema: los casos de prueba obtenidos podrían haber pasado por alto un error muy frecuente en programación, que es codificar la condición como:
if (a+b >= c)
en vez de:
if (a+b > c)
� Con la primera condición el programa nos diría que 1, 2, 3 es un triángulo escaleno válido.
� De aquí la importancia de comprobar las elementos en los límites de las clases de equivalencia y alrededor de las mismas.
Procedimientos de control de la calidad: pruebas
55
Pruebas de caja negra: técnica del análisis de valores límite
� La experiencia nos muestra que los casos de prueba que exploran condiciones límite son más rentables a la hora de encontrar defectos que aquellos que exploran valores cualesquiera dentro de las clases de equivalencia.
� Condiciones límite: aquellas que se hayan en los límites de las clases de equivalencia, o bien encima, o bien debajo.
� Cada margen de una clase de equivalencia debe ser el sujeto de una prueba, seleccionando uno o más elementos del mismo.
� A diferencia de la técnica de las clases de equivalencia, en el análisis de valores límite no sólo se consideran las condiciones de entrada, sino también el espacio de los resultados (clases de equivalencia de salida).
Procedimientos de control de la calidad: pruebas
56
Pruebas de caja negra: técnica del análisis de valores límite
Heurísticas para la aplicación de la técnica:
� Si una condición de entrada especifica un rango de valores, escribir casos de prueba para los extremos del rango, y casos de prueba de entradas inválidas para situaciones que sobrepasen los extremos.
� Ejm: si el dominio válido de un valor de entrada va de -1.0 a 1.0, escribir casos de prueba para las situaciones -1.0, 1.0, -1.001, y 1.001.
� Si una condición de entrada especifica un número de valores, escribir casos de prueba para el mínimo, para el máximo, para el mínimo-1 y para el máximo+1.
� Por ejemplo, si un fichero de entrada puede contener de 1 a 255 registros, escribir casos de prueba para 0, 1, 255 y 256 registros.
Procedimientos de control de la calidad: pruebas
57
Pruebas de caja negra: técnica del análisis de valores límite
Heurísticas para la aplicación de la técnica (continuación):
� Usar las dos reglas anteriores también para cada condición de salida.
� Ejemplo 1: un programa de la Renta calcula la deducción por inversión en vivienda habitual, que es el 15% de las cantidades aportadas, hasta un máximo de 9015.81 euros. Por tanto, la deducción va de 0 a 1352.37 euros. Habría que escribir casos de prueba con valores de entrada que ocasionaran las deducciones de 0 y 1352.37. Además, ver si es posible escribir casos de prueba que causaran una deducción negativa o una deducción de más de 1352.37 euros.
� Ejemplo 2: un programa de recuperación de información muestra los resúmenes más relevantes sobre un tema basados en una cadena de búsqueda, pero nunca más de cuatro. Habría que escribir casos de prueba que causen que el programa mostrara cero, uno, y cuatro resúmenes, y escribir un caso de prueba que causara que el programa mostrara erróneamente cinco resúmenes.
Procedimientos de control de la calidad: pruebas
58
Pruebas de caja negra: técnica del análisis de valores límite
Heurísticas para la aplicación de la técnica (continuación):
� Si la entrada o la salida de un programa es un conjunto ordenado (un fichero secuencial, por ejemplo, o una lista o una tabla), centrar la atención en el primer y último elementos del conjunto.
� En general, la técnica del análisis de valores límite requiere creatividad y conocimiento del problema en cuestión, por lo que siempre es necesario utilizar el ingenio para buscar otras condiciones límite.
Procedimientos de control de la calidad: pruebas
59
Pruebas de caja negra: técnica del análisis de valores límite
� Si la entrada o la salida de un programa es un conjunto ordenado (un fichero secuencial, por ejemplo, o una lista o una tabla), centrar la atención en el primer y último elementos del conjunto.
� En general, la técnica del análisis de valores límite requiere creatividad y conocimiento del problema en cuestión, por lo que siempre es necesario utilizar el ingenio para buscar otras condiciones límite.
Procedimientos de control de la calidad: pruebas
60
Estrategias de pruebas
� Esperar a que el todo el sistema esté construidopara probarlo => esta estrategia no funciona en general.
� Realizar pruebas diariamente, cada vez que alguna parte del sistema se construya => puede ser una estrategia muy efectiva, aunque menos atractiva para muchos desarrolladores.
� Estrategia incremental:1. Pruebas unitarias2. Pruebas de integración y de regresión3. Pruebas de validación4. Pruebas de sistemas
� Test-driven development: construir las pruebas antes que el código; el código se construye para pasar las pruebas. Es la recomendada por la metodología Extreme Programming (XP). Es también una estrategia incremental ya que el código se desarrolla en incrementos muy pequeños (una subfunción de cada vez) pero nunca se escribe código antes de que exista una prueba para él. También se aplican pruebas de regresión.
Procedimientos de control de la calidad: pruebas
61
Estrategia incremental
� Pruebas Unitarias:� Una prueba unitaria se centra en verificar la unidad más
pequeña del diseño (llamémosla componente o módulo)� Cada módulo es probado por separado� Pueden emplearse técnicas de caja blanca y caja negra� Módulo: pieza de código que cumple:
� Bloque básico de programa� Implementa función independiente simple� Puede probarse por separado� Normalmente menor de 500 líneas de código.
� Pruebas de Integración:
� Aunque los módulos hayan sido probados con éxito de manera independiente, al conectarlos pueden dar problemas en las interfaces:
� Se pueden perder datos que cruzan una interfaz
� Un módulo puede tener un efecto adverso sobre otro
� Al combinar módulos, puede que el comportamiento emergente no sea el esperado.
� Una imprecisión que de manera individual pasaba por aceptable puede magnificarse a niveles inaceptables.
� Las estructuras de datos globales pueden presentar problemas.
Procedimientos de control de la calidad: pruebas
62
Estrategia incremental
Pruebas de Integración (continuación):
� Las pruebas de integración pueden considerarse una técnica para construir la arquitectura del software al tiempo que se realizan pruebas para detectar errores relacionados con las interfaces
� Se toman módulos que ya han sido probados unitariamente y se construye una estructura de programa que haya sido dictada por el diseño
� Aproximación big bang a la integración: es una tendencia de algunos desarrolladores de intentar una integración no incremental, es decir, combinar todos los componentes a la vez. Esto produce el caos: la corrección de errores es difícil porque se complica el aislar las causas debido a la gran extensión del programa completo. Una vez que se corrigen los errores, surgen otros nuevos en un bucle interminable.
� Aproximación incremental a la integración: lo contrario de la anterior. El programa se construye y se prueba en pequeños incrementos, donde los errores son más fáciles de aislar y corregir. Existen dos técnicas:
� Integración incremental top-down (ascendente)
� Integración incremental bottom-up (descendente)
Procedimientos de control de la calidad: pruebas
63
Integración incremental top-down (descendente)• Los módulos se integran moviéndonos hacia abajo
en la jerarquía de control, comenzando por el módulo principal de control (programa main). Los módulos subordinados al principal se incorporan a la estructura incrementalmente, bien en profundidad o bien en anchura.
• Se emplean stubs: falsos módulos (normalmente están huecos) que tienen la misma interfaz que los reales y simplemente sirven para que el programa compile. Incrementalmente, los stubs se irán sustituyendo por los módulos reales.
• Pasos:1. El módulo principal de control se emplea
como el conductor de la prueba. Se cambian sus stubs por los módulos reales subordinados al principal.
2. Los stubs subordinados a los módulos anteriores se sustituyen por los reales. Aquí se puede trabajar en anchura o en profundidad.
3. Se realizan las pruebas mientras que cada módulo se van integrando.
4. Una vez completado el conjunto de pruebas, el siguiente stub se sustituye por el módulo real. La selección se hace en anchura o en profundidad.
5. Se puede utilizar una prueba de regresión(véase más adelante) para asegurarnos de que no se han introducido nuevos errores.
6. Volver a 2 hasta completar todo el programa.
Procedimientos de control de la calidad: pruebas
64
Integración incremental top-down (descendente)
• Ejemplo de integración descendente en profundidad: primero se selecciona un camino de control fundamental (lo cual depende del tipo de programa que estemos probando). Por ejemplo, supongamos que este camino está formado por M1, M2 y M5. Dichos módulos se integrarían primero. Después se integraría M8 (o M6, si fuese necesario para el correcto funcionamiento de M2). A continuación nos iríamos a la ramas central, integrando M3 y luego M7, y acabando en M4.
• Ejemplo de integración descendente en anchura: primero se integrarían M2, M3 y M4. A continuación, el siguiente nivel: M5, M6 y M7. Por último, M8.
M2 M3 M4
M1
M5 M6
M8
M7
Procedimientos de control de la calidad: pruebas
65
Integración incremental bottom-up (ascendente)
• Esta estrategia comienza la construcción y las pruebas a partir de módulos atómicos(componentes en los niveles inferiores de la estructura del programa).
• No son necesarios stubs, ya que, dado un nivel de la estructura del programa, la funcionalidad de los módulos subordinados a dicho nivel ya estádisponible (han sido construidos y probados al ser ascendente).
• Pasos:1. Los componentes de nivel inferior se
combinan en grupos (a veces llamados builds) que implementan una determinada subfunción del software.
2. Se escribe un driver (un programa de control para pruebas) que coordine la entrada y la salida del caso de prueba.
3. Se prueba el grupo.4. Se eliminan los drivers y los grupos se
combinan moviéndonos hacia arriba en la estructura del programa.
Procedimientos de control de la calidad: pruebas
66
D1 D2 D3
Ma Mb
Mc
Grupo 2
Gru
po 1
Gru
po 3
Integración incremental bottom-up (ascendente)
• Ejemplo: primero se combinan los módulos para formar los grupos 1, 2 y 3. Cada uno de los grupos se prueba empleando un driver (mostrado como cajas con líneas discontinuas). Los módulos de los grupos 1 y 2 están subordinados a Ma. Una vez probados dichos grupos, se eliminan los drivers D1 y D2 y los grupos 1 u 2 se conectan directamente a las interfaces de Ma. Análogamente, el driver D3 para el grupo 3 se elimina antes de la integración con el módulo Mb. Tanto Macomo Mb serán integrados al final con el módulo Mc.
Procedimientos de control de la calidad: pruebas
67
Pruebas de regresión
• Cada vez que se añade un módulo como parte de las pruebas de integración, el software cambia: se establecen nuevos flujos de datos, pueden ocurrir nuevas E/S, y se invoca nueva lógica de control. Todo esto puede ocasionar problemas con funciones que previamente se comportaban bien.
• En el contexto de la estrategia de pruebas de integración, las pruebas de regresión consisten en la reejecución de un subconjunto de pruebas que ya se hayan realizado, con el objetivo de asegurarnos de que los cambios no han introducido efectos colaterales.
• Las pruebas de regresión se pueden realizar:• Manualmente: reejecutando un subconjunto de todos los
casos de prueba• Mediante herramientas software llamadas record/playback
o capture/playback: capturan los casos de prueba y sus resultados, y posteriormente los utilizan para su reejecución y comparación.
• La suite de pruebas de regresión contiene tres clases de pruebas:• Una muestra representativa de pruebas que van a ejercitar
todas las funciones del software.• Pruebas adicionales centradas en aquellas funciones del
software que probablemente se vean afectadas por el cambio.
• Pruebas centradas en los módulos software que han cambiado.
• Como el número de pruebas de integración puede llegar a ser muy alto, es necesario diseñar la suite de pruebas de manera que se centre en una o más clases de errores en cada una de las funciones importantes del programa. No resulta práctico reejecutar todas las pruebas para todas las funciones cada vez que se haga un cambio.
Procedimientos de control de la calidad: pruebas
68
Pruebas de validación
• Comienzan al culminar las pruebas de integración• Se centran en los requisitos del sistema: en las acciones visibles
por el usuario y en las salidas reconocibles por el usuario• La validación tiene éxito cuando el software funciona de la manera
que el cliente esperaba razonablemente• La Especificación de Requisitos debe contener una sección de
Criterios de Validación que forma la base de estas pruebas• Plan de pruebas: esboza las clases de pruebas a realizar• Procedimiento de pruebas: define los casos de prueba
específicos diseñados para asegurar que:• Todos los requisitos funcionales se satisfacen• Todas las características de comportamiento se han
conseguido• Todo el contenido es preciso y se ha presentado
adecuadamente• Todos los requisitos de rendimiento se han alcanzado• La documentación es correcta• Se han satisfecho los requisitos de usabilidad y el resto de
requisitos de calidad (p.e. seguridad, disponibilidad, etc).• Una vez que se ha realizado cada caso de prueba de validación, se
da una de dos condiciones:• El requisito funcional o de calidad es conforme a la
especificación y por tanto es aceptado• Se ha desvelado una desviación de la especificación y se
añade a una lista de deficiencias.• Las desviaciones o errores descubiertos en estas pruebas pueden
ser rara vez corregidos antes del plazo de entrega que se había acordado. A menudo será necesario renegociar con el cliente para establecer un método para resolver dichas deficiencias.
Procedimientos de control de la calidad: pruebas
69
Pruebas de validación (continuación)
• En general, resulta casi imposible para los desarrolladores prever cómo los clientes van a utilizar realmente el sistema:• Pueden malinterpretar el manual de usuario.• Pueden utilizar de manera reiterada combinaciones extrañas
de datos.• Una salida del programa que le parecía clara a un probador
puede resultarle ininteligible a un usuario.
• Cuando se construye software “a medida” para un único cliente, se prepara un conjunto de pruebas de aceptación que el cliente realiza y así valida todos los requisitos. El proceso puede durar semanas o incluso meses.
• Cuando se construye software en forma de producto para ser utilizado por múltiples clientes, no resulta práctico realizar pruebas de aceptación con cada cliente. En ese caso se realizan las llamadas pruebas alfa y beta para descubrir errores que sólo el usuario final parece ser capaz de encontrar.
• Las pruebas alfa son realizadas en el sitio del desarrollador por un grupo representativo de los usuarios finales. El desarrollador observa y anota errores y problemas de uso. Las pruebas alfa se realizan, pues, en un entorno controlado.
• Las pruebas beta son realizadas en uno o varios sitios de los usuarios finales. El desarrollador no suele estar presente. El software se ejecuta en un entorno “real”, no controlado. El cliente anota todos los problemas hallados (reales o imaginarios) y se los comunica al desarrollador periódicamente. Posteriormente, el equipo de desarrollo realiza modificaciones al sistema y lo prepara para su lanzamiento a la base completa de clientes.
Procedimientos de control de la calidad: pruebas
70
Pruebas de sistemas
• El software es sólo una parte más de una red de sistemas (hardware, personas, otros sistemas software). Por tanto, son necesarias pruebas adicionales de integración y validación del sistema software con los demás.
• Estas pruebas no sólo son llevadas a cabo por ingenieros del software. Una situación típica cuando ocurre un fallo es que los responsables de los distintos sistemas se acusan mutuamente
• Para paliar esto, ciertas decisiones tomadas durante el diseño del software y de sus pruebas pueden aumentar la probabilidad de éxito al integrar el sistema con los demás:• Diseñar rutas de gestión de errores que prueben toda la
información procedente de sistemas externos• Realizar pruebas que simulen datos erróneos u otros errores
potenciales en la interfaz del sistema software con otros• Registrar los resultados de las pruebas como evidencia• Participar en la planificación y el diseño de pruebas de
sistemas para asegurarse de que el software es probado adecuadamente
• Pruebas de sistema recomendadas para sistemas software:• Pruebas de recuperación: forzar a que el sistema falle y
verificar que se recupera adecuadamente• Pruebas de seguridad: verificar que los mecanismos de
protección internos al sistema lo protegerán de una penetración no permitida
• Pruebas de estrés: ejecutar el sistema de manera que éste demande recursos de manera anormalmente alta
• Pruebas de rendimiento: para probar el rendimiento en tiempo de ejecución del sistema en el contexto de un sistema integrado
• Pruebas de despliegue o de configuración: ejecutar el sistema en las distintas plataformas bajo las que se supone que debe poder funcionar
Procedimientos de control de la calidad: pruebas
71
Auditorías
• Carácter extraordinario.• Superior coste a revisiones e inspecciones.• Se suele aplicar en proyectos de gran entidad con
disponibilidad de recursos.• Supervisa la labor del equipo de desarrollo y del equipo de
garantía de calidad.• El equipo de auditoría debe ser independiente de los
equipos de desarrollo y de garantía de calidad.• La referencia para la auditoría es el dossier de garantía de
calidad.• El equipo de auditoría no dispone de autoridad formal
explícita sobre el equipo de desarrollo y sobre el equipo de garantía de calidad.
• El informe de auditoría contiene un diagnóstico y una serie de recomendaciones.
• Proporciona información al promotor (usuario) o a la dirección del proyecto para la toma de decisiones.
• Agentes: dirección del proyecto, equipo de auditoría, equipo de desarrollo, equipo de garantía de calidad, promotor del proyecto (usuario).
Evaluación de prototipos
• Se aplica en la fase inicial del proyecto.• Facilita la definición de las especificaciones del proyecto.• Agentes: dirección del proyecto, equipo de desarrollo,
equipo de garantía de calidad, promotor del proyecto (usuario).
Procedimientos de control de la calidad: auditorías y ev. de prototipos
72
Contenidos
1. Introducción a la Calidad del Software.
2. Marco normativo relacionado con la calidad.
3. Factores y modelos de calidad.
4. Procedimientos de control de la calidad:
� Revisiones
� Pruebas
� Auditorías
� Evaluación de prototipos
5. Listas de control, guiones de recomendaciones y
elementos auxiliares.
6. Dossier del aseguramiento de la calidad.
7. Plan General de Aseguramiento de la Calidad.
73
Listas de control
Listas de control: definen de forma explícita los puntos concretos que deben ser controlados, al aplicar el procedimiento de control de calidad, para la revisión de los componentes documentales del proyecto
Son instrumentos de ayuda que permitirán al equipo de garantía de calidad y en su caso al usuario o promotor del proyecto ejercer el control de calidad que corresponda sobre los aspectos formales y de contenido de cada documento.
Se ha de definir una lista de control para cada tipo de procedimiento y tipo de documento identificado en el proyecto.
Por ejemplo: lista de control para aplicar una revisión técnica formal al documento de especificaciones de diseño, lista de control para la revisión de usuario del documento de operación de la aplicación, etc.Aspectos a controlar:
•Aspectos de forma.• Suelen ser comunes a todas las listas de control.• Ej.: tipo de letra, estructura, identificación del
documento, etc.
•Aspectos de contenido.• Varían en función del procedimiento a aplicar y del
documento a revisar.• Ej: consistencia con otros documentos del proyecto,
aplicación correcta de las técnicas utilizadas en el documento, etc.
74
Guiones de recomendaciones
Guiones de recomendaciones: contienen criterios, ideas y recomendaciones aplicables al realizar las tareas correspondientes a los procedimientos de control de calidad.
Son instrumentos que aportan criterios generales, sugerencias y normas de buena práctica para la realización de determinadas tareas de garantía de calidad (por ejemplo, reuniones formales de revisión conjunta entre los equipos de garantía de calidad y desarrollo; realización de pruebas de diversos tipos y de auditorías del proyecto).
Por ejemplo:• La convocatoria de la reunión de revisión se realizarápreferentemente por escrito y se extenderá a todos los agentes involucrados. En ella se indicará la fecha, hora y lugar de la reunión, asó como las personas que asistirán a la misma.• La reunión de revisión será presidida o moderada por la persona del equipo de garantía de calidad que se designe o en su caso por el Director del Proyecto.
75
Elementos auxiliares
Elementos auxiliares: hacen referencia a formatos o plantillas que se pueden aplicar a los distintos documentos auxiliares que se han de ir generando al realizar las actividades de aseguramiento de la calidad. En ellos debe quedar constancia de las actuaciones practicadas en cada fase.
Son documentos producidos como consecuencia de la realización de las funciones de control en el marco del Plan Garantía de la Calidad específico del proyecto. En ellos debe quedar constancia de las actuaciones practicadas en cada fase.
Forman parte del dossier de garantía de calidad del proyecto.
Por ejemplo: la hoja de comentarios de usuario constará de los siguientes elementos:
• Cabecera: título del proyecto, identificación del promotor, identificación del responsable del desarrollo, identificación del responsable de la garantía de la calidad, identificación del documento (nombre, fecha de revisión, etc. ), etc.• Cuerpo: contendrá todos los comentarios y observaciones que el usuario quiera reflejar respecto al contenido de que se trate.• Firma del autor o responsable del contenido indicado en la hoja de comentario.
76
Contenidos
1. Introducción a la Calidad del Software.
2. Marco normativo relacionado con la calidad.
3. Factores y modelos de calidad.
4. Procedimientos de control de la calidad:
� Revisiones
� Pruebas
� Auditorías
� Evaluación de prototipos
5. Listas de control, guiones de recomendaciones y
elementos auxiliares.
6. Dossier del aseguramiento de la calidad.
7. Plan General de Aseguramiento de la Calidad.
77
Dossier del Aseguramiento de la Calidad
1. Documentos generados por el EDS:• DBP: documento base y de planificación.• DED: documento de especificaciones de diseño.• DDD: documento de descripción del diseño.• DDF: documento de diseño funcional.• DDT: documento de diseño técnico.• DTP: documentación técnica de programación.• DOP: documentación de operación.• DRU: documento de referencia para usuarios.
2. Documentos auxiliares generados por el EDS:• IAIR: informe de análisis e interpretación de resultados de las pruebas de aceptación.
3. Documentos generados por el USR:• HCU: hojas de comentarios de usuario.
4. Documentos generados por el EGC:• PGC: plan de garantía de calidad del proyecto.• HCR: hojas de comentarios de revisión.• LAC: listas de acciones correctivas.• HAP: hojas de aprobación provisional.• PPRB: plan de pruebas.• IPVM: informe de pruebas de validación de módulos.• IPI: informe de pruebas de integración.• IPAA: informe de monitorización de pruebas de aceptación de la aplicación.• IEP: informes de evaluación de prototipos.• IVVA: informe final de verificación y validación de la aplicación.
5. Documentos generados por AUD:• PAUD: plan de auditoría del proyecto.• IAUD: informes de auditoría del proyecto.
78
Contenidos
1. Introducción a la Calidad del Software.
2. Marco normativo relacionado con la calidad.
3. Factores y modelos de calidad.
4. Procedimientos de control de la calidad:
� Revisiones
� Pruebas
� Auditorías
� Evaluación de prototipos
5. Listas de control, guiones de recomendaciones y
elementos auxiliares.
6. Dossier del aseguramiento de la calidad.
7. Plan General de Aseguramiento de la Calidad.
79
Plan General de Aseguramiento de la Calidad: aspectos generales
� Marco homogéneo de referencia para diseñar y aplicar los planes específicos de calidad a los proyectos.
� Objetivos:� Ofrecer una metodología para elaborar los planes específicos. � Ofrecer una metodología para evaluar preliminarmente a los
proyectos.� Elaborar procedimientos e instrumentos de control.
� Se estructura en:� Guía metodológica para elaborar Planes Específicos de
Aseguramiento de la Calidad.� Esquema formal para la clasificación de proyectos.� Procedimientos de Control de Calidad.� Instrumentos de control y elementos auxiliares de
aseguramiento de la calidad.� Es independiente de las metodologías de desarrollo.� Se basa en estándares: ISO 8402, 9000, 9001, 9002,
9003, 10011-1, -2, -3, y diferentes normas ANSI/IEEE.
Plan calidad proyecto 1
Plan calidad proyecto 2
Plan calidad proyecto n
PGAC
80
Plan General de Aseguramiento de la Calidad: aspectos generales
Características de los planes específicos de calidad
� Adaptación al proyecto y a las circunstancias.� Respeto de los estándares de aseguramiento de calidad
reconocidos.
Agentes participantes en un proyecto
Relación de los agentes con el PGAC
USR
DIR
AUDEGCEDS
Plan específicode calidadPGAC
DIRAUDEGC
USR
EDS
81
Plan General de Aseguramiento de la Calidad: metodología para la elaboración de planes específicos de calidad
V. Redacción y aprobación del plan específico de calidad
I. Actuaciones preliminares• Designar al representante de los usuarios.• Designar al director del proyecto.•Elaborar las especificaciones de usuario paradesarrollo/contratación.
II. Caracterización del proyecto a efectos de calidad• Designar al responsable de calidad• Obtener el Diagrama Característico• Aplicar el esquema Formal de Clasificación
III. Selección y adaptación de procedimientos de control
IV. Selección y adaptación de instrumentos de control y elementos auxiliares
82
Plan General de Aseguramiento de la Calidad: contenido de un plan específico de calidad para un proyecto
1. Objetivos y alcance.2. Fases, productos y componentes del
proyecto.3. Procedimientos de control.4. Instrumentos de control y elementos
auxiliares.5. Organización y gestión del aseguramiento
de la calidad del proyecto.6. Registro de actuaciones: el Dossier de
Aseguramiento de la Calidad.7. Estándares y normas.8. Documentos de referencia.9. Revisión del Plan.
83
Plan General de Aseguramiento de la Calidad: esquema formal para la clasificación de proyectos
I. Estimación de factores críticos y obtención deldiagrama característico
II. Selección del modelo de referencia
III. Obtención del perfil de riesgos
IV. Determinación del foco de interés(de las funciones de aseguramiento de la calidad)
Etapas a seguir
84
Plan General de Aseguramiento de la Calidad: atributos significativos del proyecto
Atributos significativos del proyecto� Intrínsecos de la aplicación:
� Dimensión (DIM).� Complejidad (COMP).� Requisitos de fiabilidad (FIAB).� Requisitos de seguridad (SEC).� Requisitos de comportamiento externo (CEX).� Requisitos de comportamiento interno (CIN).� Grado de definición y estructura de las especificaciones
(DESP).� Relativos al entorno de implantación:
� Característica de la máquina virtual:� Tipología (TPMV).� Funcionalidad (FCMV).� Grado de distribución y heterogeneidad (DHMV).
� Carga de trabajo (CTR).� Nivel de interacción con otras aplicaciones o datos del
entorno (INT).� Diferencias entre los entornos de desarrollo y de implantación
(DIFE).� Relativos al proyecto o proceso de desarrollo.
� Coste estimado del proyecto (COST).� Plazo estimado de ejecución (PLZ).� Estabilidad del proyecto (EPRY).� Evaluación previa del contratista (ECON).� Disponibilidad de recursos para el aseguramiento de la calidad
(REC).
Estimación de factores críticos y obtención del diagrama característico
85
Atributos significativos del proyecto� El rango de todos ellos es 1..5.� La incertidumbre se refleja seleccionando más de un valor en el rango
� Dimensión (DIM). A título orientativo se establece la siguiente correspondencia entre dimensión y esfuerzo de desarrollo:
� 1 (pequeño) si esfuerzo es de 1 a 6 persona-mes� 2 (moderado) si esfuerzo es de 6 a 24 persona-mes� 3 (mediano) si esfuerzo es de 24 a 60 persona-mes� 4 (grande) si esfuerzo es de 60 a 120 persona-mes� 5 (muy grande) si esfuerzo es >= 120 persona-mes
� Complejidad (COMP). Los factores a considerar son:� Nº de módulos y nivel de interrelación.� Nº y tipo de interfaces con otros sistemas.� Distribución y heterogeneidad del entorno de implantación.� Grado de sofisticación (dificultad de uso) de las herramientas de
desarrollo.� Naturaleza de los algoritmos que hay que diseñar e implementar.� Otros factores.
� A cada factor se le asigna un valor de 1 a 5 y se promedia el valor final.
� Requisitos de fiabilidad (FIAB).� 1: el efecto de un fallo no causa perjuicio significativo para el usuario.� 2: el efecto de un defecto causa perjuicios que el usuario puede asumir.� 3: el efecto del defecto lo puede asumir el usuario a un elevado coste.� 4: el defecto causa grandes pérdidas económicas al usuario o perjuicios a un
número considerable de personas.� 5: el defecto puede poner en peligro vidas humanas o causar pérdidas
irrecuperables.
Estimación de factores críticos y obtención del diagrama característico
Plan General de Aseguramiento de la Calidad: atributos significativos del proyecto
86
Atributos significativos del proyecto� Requisitos de seguridad (SEC). A modo de referencia:
� 1 a 3: sistemas administrativos.� 4 a 5: sistemas críticos.
� Requisitos de comportamiento externo (CEX): funcionalidad y rendimiento del sistema tal como son percibidos por el usuario
� 1: inexistencia de requisitos de comportamiento externo en el documento de especificaciones
� . . .� 5: condicionantes muy severos de requisitos de comportamiento
externo.
� Requisitos de comportamiento interno (CIN): relativos a la utilización de recursos máquina por parte del sistema
� 1: inexistencia de requisitos de comportamiento interno en el documento de especificaciones.
� . . . � 5: condicionantes muy severos de este tipo de requisitos
� Grado de definición, estructura y modularidad de las especificaciones (DESP). (Se refiere a las especificaciones para la contratación del desarrollo)
� 1 a 4: en función de la claridad, facilidad de comprensión (reducción de ambigüedades), verificabilidad, trazabilidad, formalismo, cohesión. . .
� 5: las especificaciones, además de un buen nivel de detalle poseen un notable grado de modularidad.
Estimación de factores críticos y obtención del diagrama característico
Plan General de Aseguramiento de la Calidad: atributos significativos del proyecto
87
Atributos significativos del proyecto� Tipología de la máquina virtual (TPMV). (características
técnicas de la MV –plataformas hardware y software)� 1: nivel bajo de sofisticación (ej: 1 PC + SO sencillo).� 2: nivel moderado de sofisticación (ej: red local pequeña <= 16 PCs).� 3: nivel intermedio de sofisticación (ej: red intermedia <= 200 PCs).� 4: nivel alto de sofisticación (ej: red intermedia > 200 PCs+SO pesado).� 5: nivel muy alto de sofisticación (ej: unión de varios a nivel 4).
� Funcionalidad de la máquina virtual (FCMV) (nivel de los servicios prestados)
� 1 a 3: rica.� 4 a 5: pobre.
� Grado de distribución y heterogeneidad de la máquina virtual (DHMV).
� 1: sistema monolítico.� 2: varias plataformas hardware idénticas con el mismo sistema
operativo y el mismo software intermedio.� 3: varias plataformas hardware diferentes, con el mismo sistema
operativo y el mismo software intermedio.� 4: varias plataformas hardware diferentes, con diferentes sistemas
operativos y con el mismo software intermedio.� 5: varias plataformas hardware diferentes, con diferentes sistemas
operativos y con diferentes software intermedios.
� Carga de trabajo (CTR). Nº usuarios concurrentes, tps o tpm, nº de tareas paralelas, … Relacionado con CEX.
� 1: mínima severidad de las condiciones de carga de trabajo.� . . .� 5: máxima severidad de las condiciones de carga de trabajo.
Estimación de factores críticos y obtención del diagrama característico
Nótese el sentido inverso
Plan General de Aseguramiento de la Calidad: atributos significativos del proyecto
88
Atributos significativos del proyecto
� Nivel de interacción con otros sistemas o datos (INT).� 1: no existe interacción con otros sistemas o datos.� 2: el sistema usa datos o procedimientos compartidos.� 3: el sistema actúa como post-procesador de otros sistemas.� 4: el sistema actúa en modo cliente-servidor con otros sistemas.� 5: el sistema intercambia mensajes y datos con otros sistemas en un
entorno distribuido y heterogéneo.
� Diferencias entre los entornos de desarrollo y de implantación (DIFE).
� 1: total coincidencia.� 2: coincidencia en la máquina virtual pero existen diferencias
organizativas y de recursos humanos.� 3: diferencias moderadas en la máquina y en las organizaciones.� 4: diferencias significativas en la máquina y en las organizaciones.� 5: diferencias acusadas en la máquina y en las organizaciones.
� Coste total estimado del proyecto (COST). Es el coste presupuestado, tal como se ha estimado por el usuario o el promotor del proyecto.
� 1: pequeño (<= 18.000 euros).� 2: moderado (18000 <= coste <= 60000).� 3: medio (60000 <= coste <= 150000).� 4: grande (150000 <= coste <= 600000).� 5: muy grande (>= 600000).
Estimación de factores críticos y obtención del diagrama característico
Plan General de Aseguramiento de la Calidad: atributos significativos del proyecto
89
Atributos significativos del proyecto� Plazo estimado de desarrollo (PLZ). Es un requisito.
� 1: pequeño (<= 3 meses).� 2: moderado (3 meses <= plazo <= 6 meses).� 3: medio (6 meses <= plazo <= 1 año).� 4: grande (1 año <= plazo <= 2 años).� 5: muy grande (>= 2 años).
� Estabilidad del proyecto (EPRY).� Se puede contemplar:
� Definición, exhaustividad y precisión de las especificaciones.� Neutralidad del dominio del problema frente a disposiciones
normativas de probable aparición.� Independencia de las especificaciones respecto al entorno de
implantación.� Permanencia de los usuarios o promotores.� Número de interlocutores o centros de decisión afectados por el
proyecto.� Grado de homogeneidad y de comunidad de intereses entre los
distintos interlocutores.
� Evaluación previa del contratista (ECON). Contratista en caso de contratación externa, equipo de desarrollo en caso de desarrollos internos.
� 1: elevado grado de confianza.� 2: moderado grado de confianza.� 3: situación de incertidumbre y neutralidad.� 4: cierto grado de prevención, o varios contratistas.� 5: manifiesto recelo, o excesivo número de contratistas.
� Disponibilidad de recursos para el aseguramiento de la calidad (REC). Tiempo, presupuesto, personal.
� 1: serias dificultades.� 2: claras limitaciones.� 3: cierto nivel de disponibilidad, pero con limitaciones.� 4: situación favorable.� 5: no existen limitaciones.
Estimación de factores críticos y obtención del diagrama característico
Plan General de Aseguramiento de la Calidad: atributos significativos del proyecto
90
Estimación de factores críticos y obtención del diagrama característico
Plan General de Aseguramiento de la Calidad: diagrama característico del proyecto
91
Estimación de factores críticos y obtención del diagrama característico
Plan General de Aseguramiento de la Calidad: diagrama característico del proyecto
92
Selección del modelo de referencia
El PGAC contempla cinco modelos de referencia:� Secuencial básico.� Secuencial intermedio.� Secuencial detallado.� Desarrollo evolutivo por prototipo.� Desarrollo modular.
Plan General de Aseguramiento de la Calidad: selección del modelo de referencia
93
Selección del modelo de referencia
Secuencial básicoProductos a obtener:� Diseño: documento de especificaciones de
diseño (DED); documento de descripción del diseño (DDD).
� Programación: código fuente; documentación técnica de programación (DTP).
� Implantación y pruebas de aceptación: aplicación o software ejecutable (APL); documento de operación (DOP); documento de referencia para usuarios (DRU).
Plan General de Aseguramiento de la Calidad: selección del modelo de referencia
94
Selección del modelo de referencia
Secuencial intermedioProductos a obtener:� Elaboración especificaciones de diseño:
documento de especificaciones de diseño (DED).� Diseño funcional: documento de diseño funcional
(DDF).� Diseño técnico detallado: documento de diseño
técnico (DDT).� Programación: código fuente; documentación
técnica de programación (DTP).� Implantación y pruebas de aceptación: aplicación
software ejecutable (APL); documento de operación (DOP); documento de referencia para usuarios (DRU).
Plan General de Aseguramiento de la Calidad: selección del modelo de referencia
95
Selección del modelo de referencia
Secuencial intermedio
Plan General de Aseguramiento de la Calidad: selección del modelo de referencia
96
Selección del modelo de referencia
Secuencial detalladoProductos a obtener:� Planificación del desarrollo: Documento baso de
planificación del desarrollo (DBP)� Elaboración especificaciones de diseño: documento
de especificaciones de diseño (DED).� Diseño funcional: documento de diseño funcional
(DDF).� Diseño técnico detallado: documento de diseño
técnico (DDT).� Programación: código fuente; documentación
técnica de programación (DTP).� Integración: software ejecutable de partes
constituyentes de la aplicación (APL).� Implantación y pruebas de aceptación: aplicación
software ejecutable (APL); documento de operación (DOP); documento de referencia para usuarios (DRU).
Plan General de Aseguramiento de la Calidad: selección del modelo de referencia
97
Secuencial detallado
Selección del modelo de referencia
Plan General de Aseguramiento de la Calidad: selección del modelo de referencia
98
Selección del modelo de referencia
Desarrollo evolutivo por prototipoProductos a obtener:� Procesos de experimentación: por cada iteración se
realiza el Informe de Evolución del Prototipo (IEP).� Especificaciones finales y diseño:
� documento de especificaciones de diseño (DED) y documento de descripción del diseño (DDD), si se sigue el modelo secuencial básico.
� documento de diseño funcional (DDF) y documento de diseño técnico (DDT), si se sigue el modelo secuencial intermedio.
� Programación: código fuente; documentación técnica de programación (DTP).
� Implantación y pruebas de aceptación: aplicación software ejecutable (APL); documento de operación (DOP); documento de referencia para usuarios (DRU).
Plan General de Aseguramiento de la Calidad: selección del modelo de referencia
99
Selección del modelo de referencia
Evolución de prototipos
Plan General de Aseguramiento de la Calidad: selección del modelo de referencia
100
Selección del modelo de referencia
Desarrollo modularProductos a obtener:� Estudio preliminar y planificación del desarrollo:
Documento base de planificación del desarrollo (DBP).
� Desarrollo de módulos en paralelo: los correspondientes a cada fase del modelo secuencial que se siga y aplicados a cada uno de los módulos.
� Integración de módulos: software ejecutable e integrado de todos los módulos.
� Implantación y pruebas de aceptación: aplicación software ejecutable (APL); documento de operación (DOP); documento de referencia para usuarios (DRU).
Plan General de Aseguramiento de la Calidad: selección del modelo de referencia
101
Selección del modelo de referencia
Desarrollo modular
Plan General de Aseguramiento de la Calidad: selección del modelo de referencia
102
Selección del modelo de referencia
Pasos a seguir� Evaluar los factores de discriminación del proyecto
(FDPi) en relación con cada uno de los modelos de referencia. Para ello, para cada modelo:
� Se contrasta el diagrama característico del proyecto con la plantilla de comparación correspondiente.
� Para cada fila de la parrilla (atributo Aj) se obtiene
el valor del factor de discriminación parcial fj:fj = (Σ tjk * dk ) / n
tjk : valor de cada uno de los cuadros de la trama del diagrama característico del proyecto no cubierto por la trama de la plantilla de comparación que se está utilizando.
dk : distancia medida entre ese cuadro y el que resulte más próximo en la plantilla (valor absoluto de la diferencia entre los valores correspondientes).
n : número total de cuadros del diagrama característico no cubiertos por la plantilla del modelo, en la fila de que se trate.
� El valor del FDPi correspondiente es la media
aritmética simple de los valores fj:FDPi = Σ fj / 18
� Se seleccionará el modelo que presente el FDPimenor.
Plan General de Aseguramiento de la Calidad: selección del modelo de referencia
103
Selección del modelo de referencia(plantillas de comparación)
Secu
enci
al b
ásic
oSe
cuen
cial
inte
rmed
io
Plan General de Aseguramiento de la Calidad: selección del modelo de referencia
104
Secu
enci
al d
etal
lado
Evol
ució
n de
pro
totip
os
Selección del modelo de referencia(plantillas de comparación)
Plan General de Aseguramiento de la Calidad: selección del modelo de referencia
105
Des
arro
llo m
odul
ar
Selección del modelo de referencia(plantillas de comparación)
Plan General de Aseguramiento de la Calidad: selección del modelo de referencia
106
Selección del modelo de referencia(comparación con la plantilla)
Secu
enci
al b
ásic
oSe
cuen
cial
inte
rmed
io
Plan General de Aseguramiento de la Calidad: selección del modelo de referencia
107
Selección del modelo de referencia(comparación con la plantilla)
Secu
enci
al d
etal
lado
Evol
ució
n de
pro
totip
os
Plan General de Aseguramiento de la Calidad: selección del modelo de referencia
108
Selección del modelo de referencia(comparación con la plantilla)
Des
arro
llo m
odul
ar
Plan General de Aseguramiento de la Calidad: selección del modelo de referencia
109
� Aplicando la anterior fórmula al diagrama característico del ejemplo, obtenemos los siguientes valores (redondeados a dos decimales):
Secuencial Básico: 2.83Secuencial Intermedio: 1.22Secuencial Detallado: 0.75Evolución de Prototipos: 2.83Desarrollo Modular: 0.61
Por tanto, el modelo recomendado para el proyecto ejemplo es el de Desarrollo Modular.
Plan General de Aseguramiento de la Calidad: selección del modelo de referencia
110
� Dos umbrales de riesgos: ordinario y extraordinario.
� En general, puede decirse que los proyectos situados en el umbral de riesgos ordinarios podrán controlarse de forma efectiva a través de planes de calidad de intensidades nominal (1) o especial (2), según se determine en su foco de interés (véase más adelante). Los riesgos ordinarios son en principio tolerables, y el objetivo de un plan de calidad se dirige precisamente a su control.
� Sin embargo, la existencia de riesgos extraordinarios hace muy difícil o incluso imposible su control efectivo una vez iniciado el proceso de desarrollo. La situación en estos casos suele deberse a la existencia de elementos contradictorios o desequilibrios importantes en el proyecto, que se traducen en que éste sea extremadamente vulnerable y en la mayoría de los casos hacen impráctica la aplicación de cualquier plan de calidad, razón por la que conviene su detección temprana. En estas situaciones se recomienda el reestudio del proyecto y la redefinición de sus condiciones de desarrollo, con el fin de atenuar los riesgos extraordinarios identificados y reducirlos hasta límites tolerables.
Plan General de Aseguramiento de la Calidad: perfil de riesgos
111
� Lista genérica de riesgos potenciales a evaluar:
� R1: defectos graves y recurrentes en el comportamiento externo de la aplicación, bien sea por mala adecuación funcional o por problemas de rendimiento, falta de fiabilidad, problemas de seguridad, etc.
� R2: baja calidad en general de los distintos productos obtenidos en las fases del desarrollo, con graves implicaciones en cuanto a la mantenibilidad de la aplicación y la gestión de su configuración.
� R3: dificultades graves de implantación por mala adecuación de la aplicación a su entorno real de operación, debidas a un bajo nivel de funcionalidad de la máquina virtual, falta de homogeneidad entre los entornos de desarrollo e implantación, mal comportamiento interno de la aplicación, etc.
� R4: imposibilidad práctica de mantener los costes de desarrollo en consonancia con los límites establecidos en la contratación, bien por la necesidad de llevar a cabo ampliaciones o revisiones importantes del proyecto, bien por la aparición de costes ocultos significativos que le son directamente imputables.
� R5: incumplimiento grave de los plazos de ejecución.� R6: imposibilidad de gestionar y controlar adecuadamente el
desarrollo del proyecto, por razones de inmanejabilidadpráctica del mismo, lo que se traduce entre otros problemas en la inoperabilidad de los planes de garantía de calidad establecidos.
� R7: inconclusión del proyecto, que correspondería a una situación extrema en alguno de los problemas anteriores.
Plan General de Aseguramiento de la Calidad: perfil de riesgos
112
� Se ha de obtener el coeficiente de divergencia CDi para cada tipo de riesgo i:
CDi = (Σ aij )/n - (Σ bik )/m j=1..n k=1..m
siendo:- n: número de atributos del grupo A para el riesgo i-ésimo- m: número de atributos del grupo B para el riesgo i-ésimo- aij: valor medio de cada atributo del grupo A para el riesgo
i-ésimo (tal y como refleja el diagrama característico del proyecto)
- bij: valor medio de cada atributo del grupo B para el riesgo i-ésimo (tal y como refleja el diagrama característico del proyecto)
Plan General de Aseguramiento de la Calidad: perfil de riesgos
113
Grupos de atributos antagonistas (A y B) para cada riesgo:� Para R1.
� Grupo A: [FIAB], [SEC], [CEX],[CTR], [ECON]� Grupo B: [DESP], [PLZ], [REC]
� Para R2.� Grupo A: [DIM], [COMP], [FIAB], [SEC], [CEX], [ECON]� Grupo B: [DESP], [COST], [PLZ], [EPRY], [REC]
� Para R3.� Grupo A: [CIN], [FCMV], [DHMV], [INT], [DIFE], [ECON]� Grupo B: [COST], [PLZ], [REC]
� Para R4.� Grupo A: [DIM], [COMP], [FIAB], [FCMV], [ECON]� Grupo B: [DESP], [COST], [EPRY]
� Para R5.� Grupo A: [DIM], [COMP], [FIAB], [FCMV], [ECON]� Grupo B: [DESP], [PLZ], [EPRY]
� Para R6.� Grupo A: [DIM], [COMP]� Grupo B: [REC]
� Para R7.� Grupo A: [DIM], [COMP], [FIAB], [SEC], [CEX], [CIN],
[TPMV], [FCMV], [DHMV], [CTR], [INT], [DIFE], [ECON]� Grupo B: [DESP], [COST], [PLZ], [EPRY], [REC]
Plan General de Aseguramiento de la Calidad: perfil de riesgos
114
� Los coeficientes de divergencia (redondeados a dos decimales) para el proyecto ejemplo son los siguientes:
Riesgo: 1 Coeficiente de divergencia: -1.10
Riesgo: 2 Coeficiente de divergencia: -0.40
Riesgo: 3 Coeficiente de divergencia: -2.0
Riesgo: 4 Coeficiente de divergencia: -0.60
Riesgo: 5 Coeficiente de divergencia: -0.27
Riesgo: 6 Coeficiente de divergencia: 1.0
Riesgo: 7 Coeficiente de divergencia: -1.05
Plan General de Aseguramiento de la Calidad: perfil de riesgos
115
Obtención del perfil de riesgos
Una vez obtenidos los coeficientes, se representan gráficamente (perfil de riesgos). Para el ejemplo anterior:
Plan General de Aseguramiento de la Calidad: perfil de riesgos
116
Análisis del perfil de riesgos� Se analiza el diagrama comparándolo con los umbrales de
referencia que se definen abajo. � En los casos en que se identifiquen riesgos
extraordinarios, se recomienda encarecidamente a los promotores o responsables del proyecto que procedan a su reestudio o redefinición con el fin de mejorar su consistencia interna y reducir los desequilibrios que pueden existir entre los grupos de atributos antagonistas. De esta manera se conseguirá atenuar la vulnerabilidad del proyecto hasta límites tolerables que permitan la definición y la aplicación efectiva de un plan de garantía de calidad adecuado a su proceso de desarrollo. Especialmente se advierte que no debería iniciarse el desarrollo de ningún proyecto que se encuentre en situación de riesgos extraordinarios.
Plan General de Aseguramiento de la Calidad: perfil de riesgos
117
Análisis del perfil de riesgos (continuación)� La interpretación de los valores obtenidos para cada CDi es:
� 0 <= CDi < 3 : corresponde a un nivel ordinario de riesgos previos en relación con el factor considerado, que pueden ser en principio controlados mediante la aplicación de un plan de garantía de calidad adecuado.
� 3 <= CDi <= 5 : el nivel de riesgos es extraordinario y por lo tanto muy difícilmente controlable. En este caso deberáredefinirse el proyecto para reducir el desajuste entre los atributos de los grupos A y B hasta valores admisibles.
� -3 < CDi <= 0 : indica que el planteamiento del proyecto es suficientemente satisfactorio en relación con el tipo de riesgo considerado, y que la propia definición inicial no introduce riesgos preliminares. No obstante, el control de los riesgos ordinarios que se producirán una vez iniciado el desarrollo deberá llevarse a cabo siguiendo un plan adecuado de garantía de calidad.
� -5 <= CDi <= -3 : indica que el planteamiento inicial del proyecto resulta desajustado en relación con el tipo de riesgo considerado; si bien ello no resulta forzosamente negativo desde el punto de vista de garantía de calidad, conviene por razones de eficiencia en la asignación de recursos y equilibrio entre los grupos de atributos antagonistas que se proceda a la redefinición de los términos en los que se piensa llevar a cabo el proyecto mediante el reajuste de los atributos correspondientes.
Plan General de Aseguramiento de la Calidad: perfil de riesgos
118
Análisis del perfil de riesgos del ejemplo
� Puede observarse que en este caso el proyecto se sitúa en el umbral de riesgos ordinarios, en una posición que podría calificarse globalmente como moderada en cuanto a los riesgos preliminares.
� El proyecto se sitúa en la banda conservadora en relación con seis de los siete tipos de riesgos considerados.
� No parece por lo tanto necesaria su redefinición, y por lo tanto se puede esperar que la aplicación de un plan de garantía de calidad adecuado permita controlar el proceso de desarrollo hasta la conclusión satisfactoria del proyecto.
Plan General de Aseguramiento de la Calidad: perfil de riesgos
119
Plantilla para perfil de riesgos
Plan General de Aseguramiento de la Calidad: perfil de riesgos
120
� El diseño de un plan específico de garantía de calidad aplicable a proyectos cuyo perfil de riesgos se sitúa dentro del umbral de riesgos potenciales ordinarios se llevará a cabo una vez determinado el modelo de referencia más adecuado para su desarrollo, mediante la definición del foco de interéscorrespondiente.
� Para la obtención del foco de interés se aplica sobre el diagrama característico del proyecto una plantilla específica, que depende del modelo de referencia elegido para el proyecto
� El foco de interés se determinará asignando a cada una de las fases y productos del modelo de desarrollo elegido un nivel de intensidad que sirva para graduar el ejercicio de las funciones de garantía de calidad.
� Los dos niveles de intensidad considerados son: normal (1) y especial (2).
� Existe un nivel mínimo de intensidad (0) aplicable a las situaciones en las que no se disponga de recursos adecuados para abordar las tareas regulares de garantía de calidad de la forma apropiada. En tales casos se asignará la intensidad mínima (0) al control de todas las fases, productos y componentes incluidos en el modelo de referencia correspondiente.
Plan General de Aseguramiento de la Calidad: foco de interés
121
� Procedimiento a seguir para determinar el foco de interés:� Se contrasta el diagrama característico del proyecto con la
plantilla correspondiente al modelo de referencia que se haya elegido previamente
� Se elabora la matriz de intensidades
� Se deduce el grado de intensidad más adecuado para el control de las fases y productos a partir de la matriz de intensidades y de la criticidad de los atributos del proyecto.
� Control de calidad de la fase con intensidad normal: si el valor medio correspondiente a la fase en la matriz de intensidades es menor que 1.30
� Control de calidad de la fase con intensidad especial: si el valor medio correspondiente a la fase en la matriz de intensidades es mayor o igual que 1.30
� A partir del foco de interés se diseña el plan específico de garantía de calidad del proyecto.
Plan General de Aseguramiento de la Calidad: foco de interés
122
Determinación del foco de interés
Plan General de Aseguramiento de la Calidad: foco de interés
123
Determinación del foco de interés
Plan General de Aseguramiento de la Calidad: foco de interés
124
Determinación del foco de interés
Plan General de Aseguramiento de la Calidad: foco de interés
125
Determinación del foco de interés
Plan General de Aseguramiento de la Calidad: foco de interés
126
Determinación del foco de interés
Plan General de Aseguramiento de la Calidad: foco de interés
127
Determinación del foco de interés
Plan General de Aseguramiento de la Calidad: foco de interés
Como se puede observar, en este ejemplo existen algunos atributos que son irrelevantes desde el punto de vista de la determinación del foco de interés: [DIFE], [EPRY] y [REC].
128
Determinación del foco de interés
Matriz de intensidades y valores medios de la intensidad en cada fase (para el
ejemplo de desarrollo modular)
Plan General de Aseguramiento de la Calidad: foco de interés
No deben contarse los atributos considerados irrelevantes (en este caso [DIFE], [EPRY] y [REC]).
129
Determinación del foco de interés
Según la matriz anterior el foco de interés del proyectoejemplo sería, para cada fase:
� Fase 1 (Estudio preliminar y planificación del desarrollo): nivel 1
� Fase 2 (Desarrollo de módulos):� 2.1 (Especificación): nivel 2.� 2.2.1 (Diseño funcional): nivel 1.� 2.2.2. (Diseño técnico): nivel 1.� 2.3 (Programación): nivel 1.� 2.4 (Pruebas de validación): nivel 2.
� Fase 3 (Integración de módulos): nivel 2.� Fase 4 (Implantación y pruebas de aceptación): nivel 2.
Plan General de Aseguramiento de la Calidad: foco de interés
130
Plan General de Aseguramiento de la Calidad: determinación de los procedimientos de control
131
Plan General de Aseguramiento de la Calidad: determinación de los procedimientos de control
132
Plan General de Aseguramiento de la Calidad: determinación de los procedimientos de control
133
Plan General de Aseguramiento de la Calidad: determinación de los procedimientos de control
134
Plan General de Aseguramiento de la Calidad: determinación de los procedimientos de control
135
Plan General de Aseguramiento de la Calidad: determinación de los procedimientos de control
En el contexto del Plan General de Aseguramiento de la Calidad, las auditorías son procedimientos de control de carácter extraordinario a los que se pueden someter los proyectos de desarrollo de aplicaciones informáticas en determinadas circunstancias.
Este tipo de procedimientos suelen tener un coste superior a las revisiones e inspecciones, y en algunas ocasiones incluso a las pruebas de aceptación, por lo que su uso tendrá lugar generalmente en el marco de proyectos que cumplan estas dos condiciones:
• proyectos importantes con una buena disponibilidad de recursos asignables a las funciones de garantía de calidad • en los que una buena parte de las fases y componentes deba controlarse con un nivel de intensidad especial (nivel 2).
El objetivo fundamental de una auditoría consiste en garantizar que tanto los procesos de desarrollo que lleva a cabo el Equipo de Desarrollo de Software como muy especialmente las funciones de control que está realizando el Equipo de Garantía de la Calidad se ajustan estrictamente a las normas y procedimientos establecidos en el Plan de Garantía de Calidad del proyecto. Por esta razón, el equipo u organización encargada de llevar a cabo la auditoría debe ser independiente de los dos equipos anteriores.
136
Plan General de Aseguramiento de la Calidad: determinación de los procedimientos de control
Para el ejemplo anterior (basado en el modelo de desarrollo modular):
• Fase 1 (Estudio preliminar y planificación del desarrollo): nivel 1 => Revisión Técnica Formal• Fase 2 (Desarrollo de módulos):
•2.1 (Especificación): nivel 2 => Inspección Detallada•2.2.1 (Diseño funcional): nivel 1 => Revisión Técnica Formal•2.2.2 (Diseño técnico): nivel 1 => Revisión Técnica Formal•2.3 (Programación): nivel 1 => Revisión Técnica Formal•2.4 (Pruebas de validación): nivel 2 => Pruebas de validación de módulos
• Fase 3 (Integración de módulos): nivel 2 => Pruebas de integración• Fase 4 (Implantación y pruebas de aceptación): nivel 2 => Pruebas de aceptación de la aplicación
137
Plan General de Aseguramiento de la Calidad: determinación de los instrumentos de control y elementos auxiliares
La puesta en marcha del Plan de Garantía de Calidad específico de un determinado proyecto supondrá la utilización de una serie de procedimientos de control, cuya ejecución exigirá la utilización de instrumentos de control y elementos auxiliares.
Distinguimos tres tipos de instrumentos de control y elementos auxiliares:
• Listas de control: véase tabla TLC.
• Guiones de recomendaciones: véase la tabla TGR.
• Elementos auxiliares: véase la tabla TEA.
138
Plan General de Aseguramiento de la Calidad: determinación de los instrumentos de control y elementos auxiliares
139
Para el ejemplo anterior (basado en el modelo de desarrollo modular):
............
Lista de control para RTF del DDDM
EGCDocumento de Diseño (DDDM)
DiseñoFase 2.2
Lista de control para revisiones de usuario del DEDM
USRRevisiones de usuario del DEDM
Lista de control para inspección detallada del DEDM
EGCDocumento de especificaciones de diseño (DEDM)
EspecificacionesFase 2.1
Lista de control para revisiones de usuario del DBP
USR (grupo de representantes del organismo promotor)
Revisiones de usuario de DBP
Lista de control para RTF del DBP
EGC (equipo de garantía de calidad del proyecto)
Documento base y de planificación (DBP)
Estudio preliminar y planificación del desarrollo
Fase 1
Lista de controlAgente responsable
DocumentoDenominación de la faseFase
Plan General de Aseguramiento de la Calidad: determinación de los instrumentos de control y elementos auxiliares
140
Plan General de Aseguramiento de la Calidad: determinación de los instrumentos de control y elementos auxiliares
141
Plan General de Aseguramiento de la Calidad: determinación de los instrumentos de control y elementos auxiliares
142
Para el ejemplo anterior (basado en el modelo de desarrollo modular):
.........
Hoja de comentarios de Inspección Detallada del DEDMHoja de comentarios de usuarios para el DEDMLista de acciones correctivas para el DEDMHoja de aprobación provisional del DEDM...
DEDMGuión de recomendación para la realización de revisiones conjuntas del DEDM
Fase 2.1
Hoja de comentarios de RTF de DBPHoja de comentarios de usuarios para el DBPLista de acciones correctivas para el DBPHoja de aprobación provisional del DBP...
DBPGuión de recomendación para la realización de revisiones conjuntas del DBP
Fase 1
Elementos auxiliaresProductos y componentes sobre los que se aplica
Guiones de recomendación
Fase
Plan General de Aseguramiento de la Calidad: determinación de los instrumentos de control y elementos auxiliares
143
Bibliografía
Austenfeld, R.B. W.E. Deming, the story of a truly remarkable person, Papers of the Research Society of Commerce and Economics XXXXII (2001) 49–102.
Boehm, B.; Basili, V.R. Software defect reduction top 10 list. Revista IEEE Computer, Enero 2001, pp. 135-137.
Deming, W.E. Out of the Crisis. The MIT Press, 2000 (reimpresión de la edición de SPC Press de 1986)
Dolado, J.J.; Fernández, L. y otros. Medición para la gestión en la Ingeniería del Software. Ra-Ma, 2000
Jenner, M. L. Software Quality Management and ISO 9001. How to makethem work for you. JohnWiley & Sons, Inc., 1995.
Larman, C; Basili, V.R. Iterative and incremental development: a brief history. Revista IEEE Computer, vol. 36, no. 6., Junio 2003, pp. 47-56.
IEEE Standards Collection Software Engineering. IEEE, 1997.
Myers, G.J.; Badgett, T.; Sandler, C. The Art of Software Testing. Tercera edición. Wiley, 2011.
Plan General de Garantía de Calidad Aplicable al Desarrollo de Equipos Lógicos. Ministerio de Administraciones Públicas, 1991.
Pressman, R.S., Ingeniería del Software: un Enfoque Práctico, séptima edición, Mc Graw Hill, 2010.