INGENIERÍA DEL SOFTWARE III CALIDAD DEL SOFTWARE Curso 2013…

INGENIERÍA DEL SOFTWARE III

CALIDAD DEL SOFTWARE

Curso 2013/14

Departamento de Lenguajes y Sistemas Informáticos

Universidad de Sevilla

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.

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

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

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

ISO 9000:2005ISO/IEC 15504

ISO/IEC 12007 ISO 9126

Certificación

ItMark

TicKit

TPI/TMAP

MoProsoft

PSP/TSP

BOOTSTRAP

SixSigma

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

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.

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

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.

• 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.

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.

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

$ 7136

$ 14102

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.

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.

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.

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.

Á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.

Contenidos

� Revisiones

� Pruebas

� Auditorías

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

Estándares ISO: etapas

Stage name Product name Acronym

Preliminarystage

Preliminary workitem (project)

Proposal stage New proposal for a work item

Preparatorystage

Working draft(s) WD

Committeestage

Commitee draft(s) CD

Enquire stage Draft International Standard

ApprovalStage

Final draftInternational Standard

Publicationstage

International Standard

Ref: International Organization for Standardization

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

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)

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.

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.

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.

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

Contenidos

� Revisiones

� Pruebas

� Auditorías

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

Transición

Operación

• 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

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

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

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.

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).

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

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).

Contenidos

� Revisiones

� Pruebas

� Auditorías

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

• Evaluación de prototipos.

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.

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

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

Revisiones: tipos

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

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.

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.

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.

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

opción1

opción N

END CASEopción2

Repeat

Aristas

Región

IF a OR b

Nodos Predicado

False True

Representación del programa como grafo de flujo

� 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

Región

V(G) = Número de regiones = 4V(G) = Aristas – Nodos + 2 =

11-9 + 2 = 4V(G) = Nodos Predicado + 1 =

3 +1 = 4

• 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

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

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.

� 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.

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

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.

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)

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)

� 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.

� 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).

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.

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.

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.

� 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.

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.

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.

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)

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.

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

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.

D1 D2 D3

Grupo 2

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.

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.

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.

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.

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

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

Contenidos

� Revisiones

� Pruebas

� Auditorías

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.

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.

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.

Contenidos

� Revisiones

� Pruebas

� Auditorías

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.

Contenidos

� Revisiones

� Pruebas

� Auditorías

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

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

AUDEGCEDS

Plan específicode calidadPGAC

DIRAUDEGC

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

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.

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

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

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.

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.

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.

Nótese el sentido inverso

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).

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.

Plan General de Aseguramiento de la Calidad: diagrama característico del proyecto

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

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).

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).

Secuencial intermedio

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).

Secuencial detallado

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).

Evolución de prototipos

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).

Desarrollo modular

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.

Selección del modelo de referencia(plantillas de comparación)

Selección del modelo de referencia(comparación con la plantilla)

� 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.

� 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

� 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.

� 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)

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]

� Los coeficientes de divergencia (redondeados a dos decimales) para el proyecto ejemplo son los siguientes:

Riesgo: 1 Coeficiente de divergencia: -1.10

Riesgo: 6 Coeficiente de divergencia: 1.0

Obtención del perfil de riesgos

Una vez obtenidos los coeficientes, se representan gráficamente (perfil de riesgos). Para el ejemplo anterior:

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.

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.

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.

Plantilla para perfil de riesgos

� 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

� 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.

Determinación del 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].

Matriz de intensidades y valores medios de la intensidad en cada fase (para el

ejemplo de desarrollo modular)

No deben contarse los atributos considerados irrelevantes (en este caso [DIFE], [EPRY] y [REC]).

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: 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.

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

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.

............

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

.........

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

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.

INGENIERÍA DEL SOFTWARE III CALIDAD DEL SOFTWARE Curso 2013…

Documents

Transcript of INGENIERÍA DEL SOFTWARE III CALIDAD DEL SOFTWARE Curso 2013…

U I B 3/10/2001 Gestión de riesgos Ingeniería del Software III Octubre - 1999.

III Jornadas de Ingeniería de Software ESPOL - UTPL 2006 Área de Ingeniería de Software, Proyecto VLIR Capítulo de Computación, Rama Estudiantil IEEE-ESPOL.

Ingeniería en Software

Ingeniería de Software

INGENIERÍA DEL SOFTWARE

Unidad iii paradigmas de la ingeniería de software

INGENIERÍA DE SOFTWARE LABORATORIO III

Ingeniería de software Ingeniería de Software I. Temas Definición de Ingeniería de Software Etapas del proceso de desarrollo de software Modelos de desarrollo.

Ingeniería del Software

U I B Ingeniería del Software III Calidad en Ingeniería del Software Ingeniería del Software III Enero - 2.002.

Software e ingeniería del software

Ingeniería de Software – Ingeniería de Sistemas1 Ingeniería de software.

Ingeniería de Software I Conceptos Básicos de la Ingeniería de Software.

¿Qué es la Ingeniería De Software? Ingeniería de Software.

Ingeniería de Software III CMMI Mejora de Procesos Fernando Mancía Cristhian Parra Hugo Meyer.

Ingeniería de Software I - Proyecto Final Parte III