Modelos de Calidad de Software

MODELOS DE CALIDAD DE SOFTWARE
1. (6)
2. Modelos De Calidad De Software…………………………………………………………………. (6)
2.1. Ventajas De Los Modelos De Calidad De Software …………………………………………. (7)
2.2. Pasos Para El Uso De Un Modelo De Calidad Del Software …………………………….. (7)
2.2.1. Principio Del Proyecto ………………………………………………………………………. (7)
2.2.2. Durante El Proyecto …………………………………………………………………….….. (9)
2.2.3. Final Del Proyecto ……………………………………………………………………........ (10)
3. Estructura De Los Modelos De Calidad De Software …………………………………….. (10)
3.1. Factores De Calidad ……………………………………………………………………………….... (10)
3.2. Criterios De Calidad ………………………………………………………………………………….. (10)
3.3. Métricas …………………………………………………………………………………………………. (11)
4. Tipos De Modelos De Calidad De Software………………………………………………….. (11)
4.1. Tipos De Modelos De Calidad De Producto………………………………………………….. (11)
4.1.1. Modelos Fijos………………………………………………………………………………….. (11)
4.1.2. Modelos De Calidad A Medida……………………………………………………………. (12)
4.1.3. Modelos Mixtos……………………………………………………………………………….. (12)
5. Modelos De Calidad De Software………………………………………………………………….. (13)
5.1. Modelo De Mccall…………………………………………………………………………………………… (14)
5.1.1. Perspectivas Para Definir E Identificar La Calidad De Un Producto Software (14)
5.1.2. Factores De Calidad………………………………………………………………………….. (14)
I. Factores De Revisión………………………………………………………………….. (14)
II. Factores De Transición……………………………………………………………….. (14)
III. Factores De Operación ……………………………………………………………….. (15)
5.1.3. Criterios De Calidad ………………………………………………………………………….. (15)
5.1.4. Métricas De Calidad ………………………………………………………………………….. (20)
5.2. Modelo De Boehm…………………………………………………………………………………………… (20)
5.2.1. Características De Alto Nivel …………………………………………………………….. (21)
5.2.2. Características De Nivel Intermedio …………………………………………………… (21)
5.2.3. Características Primitivas …………………………………………………………………. (21)
5.2.4. Comparación De Modelos Mccall – Boehm …………………………………………. (23)
5.2.5. Evaluación De Modelos Mccall – Boehm …………………………………………….. (23)
5.3. Modelo Arthur ………………………………………………………………………………………….. (24)
5.4. Modelo FURPS …………………………………………………………………………………………... (24)
5.5. Modelo Gilb ……………………………………………………………………………………………. (25)
5.6. Modelo Deutsch ………………………………………………………………………………………. (26)
5.6.1. Factores ……………………………………………………………………………………….. (27)
5.6.2. Criterios ……………………………………………………………………………………….. (27)
5.7. Modelo De Dromey ………………………………………………………………………………….. (27)
1
5.8. Modelo De Reboot ……………………………………………………………………………………. (28)

5.9. Modelo ISO ……………………………………………………………………………………………… (29)
5.9.1. Iso 9000 ……………………………………………………………………………………….. (29)
5.9.2. Iso 9126 ……………………………………………………………………………………….. (29)
5.9.2.1. Antecedentes …………………………………………………………………... (29)
5.9.2.2. Iso 9126-1 Modelo De Calidad (Iso/Iec, 2001) ……………………………. (30)
5.9.2.2.1. Metricas De Calidad Del Producto …………………. (36)
5.9.2.2.2. La Calidad En El Uso …………………………………. (38)
5.9.2.2.3. Utilidad De Las Normas Iso / Iec 9126 ………….... (39)
5.10. Modelo Parasuraman …………………………………………………………………………… (40)
5.11. Modelo Cai (2000) ………………………………………………………………………………… (40)
5.12. Modelo Fernandez And Rossi (2000) …………………………………………………….. (40)
5.13. Modelo Propuesto Bertoa y Vallecillo (2002)………………………………………… (42)
5.14. Modelo De Calidad Quint2 (Niessink, 2002) ………………………………………….. (41)
5.15. Modelo En Zo And Ramamurhty (2002) ………………………………………………… (41)
5.16. Modelo En Web And Web (2002) ………………………………………………………….. (41)
5.17. Modelo De Simao Y Belchior (2003) ………………………………………………………. (41)
5.18. Modelo De Calidad Propuesto Por Franch And Carvallo (2003) ………………. (41)
5.19. Modelo Botella (2003) …………………………………………………………………………… (41)
5.20. Modelo Wqm ………………………………………………………………………………………... (41)
5.21. Modelo Gqm (Goal Question Metric) ………………………………………………………. (41)
5.22. Modelo CMMI ……………………………………………………………………………………… .. (42)
5.22.1. Niveles De CMMI ………………………………………………………………………. (42)
1. MODELO
Un modelo es una representación de un objeto, sistema o idea, de forma diferente al de la

entidad misma. El propósito de los modelos es ayudarnos a explicar, entender o mejorar un
2
sistema. Un modelo de un objeto puede ser una réplica exacta de éste o una abstracción de
las propiedades dominantes del objeto.
2. MODELOS DE CALIDAD
Los Modelos de Calidad son herramientas que guían a las Organizaciones a la Mejora
Continua y la Competitividad dándoles especificaciones de qué tipo de requisitos debe de
implementar para poder brindar productos y servicios de alto nivel.
Conjunto de criterios agrupados en áreas o capítulos que sirven como referencia para
estructurar un plan de calidad total en una empresa u organización, o de una de sus partes.
Los modelos de calidad permiten:
a. Definición estructurada de criterios de evaluación

b. Especificación de requisitos con relación a ellos
c. Descripción de componentes en un marco común
d. Definición de métricas y prioridades
3. MODELOS DE CALIDAD DE SOFTWARE
La obtención de un software con calidad implica la utilización de modelos o procedimientos

estándares para el análisis, diseño, desarrollo y prueba del software que permitan
uniformar la filosofía de trabajo, para lograr una mayor confiabilidad, mantenibilidad y
facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo
como para el control de la calidad del software.
Un modelo de calidad del software es un conjunto de buenas prácticas para el ciclo de vida
del software, enfocado en los procesos de gestión y desarrollo de proyectos.
Construir un modelo de calidad es bastante complejo y es usual que estos modelos

descompongan la calidad del producto software jerárquicamente en una serie de
características y sub-características que pueden usarse como una lista de comprobación de
aspectos relacionados con la calidad.
3.1. VENTAJAS DE LOS MODELOS DE CALIDAD DEL SOFTWARE
Las ventajas de implantar Modelos de Calidad del Software son:
3
a) Tener una oportunidad para corregir los procesos de software que se hayan
desajustado con el tiempo.
b) Reducir los costos en todos los procesos.
c) Cambiar la actitud del personal de la empresa.
d) Realizar una mejora continua en la calidad de los procesos de software utilizados,

servicios y productos de software.
e) Lograr que la empresa de software sea más competitiva.
f) Aumentar la productividad, efectividad y utilidad de la empresa.
g) Asegurar la satisfacción de los clientes internos y externos.
h) Tener productos de software y servicios con valor agregado.
i) Tener permanentemente mejores procesos, productos de software y Servicios
3.2. PASOS PARA EL USO DE UN MODELO DE CALIDAD DEL SOFTWARE
3.2.1 AL PRINCIPIO DEL PROYECTO:
Al especificar la calidad requerida de un producto software hay que:
A. Seleccionar cuáles de los factores de calidad van a ser requisitos de calidad

del sistema. Para ello hay que tener varias cosas en consideración:
1. La relación que tienen los factores con las características peculiares del
producto o proyecto. Así, por ejemplo, si se espera que el ciclo de vida
del sistema sea largo, la ‘facilidad de mantenimiento’ y la ‘flexibilidad’
se convierten en un requisito; si el sistema es experimental y se espera
que las especificaciones del sistema cambien frecuentemente, la
‘flexibilidad’ será importante y sin embargo la ‘eficiencia’ apenas
tendrá importancia; si el sistema se desarrolla para un entorno en el
que el hardware evoluciona rápidamente, la ‘portabilidad’ es esencial;
si se espera que ciertas funciones del sistema se utilicen por un largo
4
período de tiempo, aunque el resto del sistema cambie, la ‘facilidad de

reutilización’ será fundamental, etc.
2. El coste del factor de calidad frente al beneficio que proporciona. La

siguiente tabla indica, para cada factor, el ahorro que se puede esperar
cuando se consigue frente al coste necesario para conseguir dicho
factor.
3. El coste del factor de calidad frente al beneficio que proporciona. La

siguiente tabla indica, para cada factor, el ahorro que se puede esperar
cuando se consigue frente al coste necesario para conseguir dicho
factor.
BENEFICIOS FRENTE A COSTE

ALTO MEDIO BAJO
Corrección 
Fiabilidad 
Eficiencia 
Integridad 
Facilidad de Uso 
FACTOR
Facilidad de Mantenimiento 
Facilidad de Prueba 
Flexibilidad 
Portabilidad 
Reusabilidad 
Interoperabilidad 
Tabla N°1. Beneficios Frente A Coste De Los Factores De Calidad
4. Las implicaciones de los factores de calidad sobre el ciclo de vida, es

decir, en qué etapas es necesario evaluar cada uno de los factores de
calidad, y en qué etapas se dejan sentir los efectos de una calidad pobre
con respecto a cada uno de estos factores.
5. Las interrelaciones entre factores. Algunos factores pueden ser

conflictivos entre sí. La eficiencia, por ejemplo, está en conflicto con
prácticamente todos los demás factores de calidad. La siguiente tabla
indica la dependencia entre los factores de McCall.
5
B. Una vez seleccionados los factores de calidad que son requisitos para el
producto, es necesario organizarlos en orden de importancia.
C. Una vez establecidos los factores de calidad, el modelo de calidad

proporciona automáticamente el conjunto de atributos o criterios
relacionados con dichos factores.
D. Para cada uno de los criterios de calidad se definen o eligen entonces un

conjunto de métricas.
E. Se debe entonces establecer valores deseables para los criterios en función

de datos históricos, el promedio en la industria, etc. Se pueden establecer
valores finales, es decir, los que se desea obtener una vez finalizado el
desarrollo, y también valores intermedios o predictivos en cada período de
medición durante el desarrollo.
F. Por último, se deberán establecer los valores mínimos aceptables. La

explicación para cualquier selección o decisión deberá ser adecuadamente
documentada.
3.2.2 DURANTE EL DESARROLLO:
Todo lo anterior se realizará al principio del proyecto. Ahora bien, durante el

desarrollo será necesario:
a) Implementar las métricas, es decir, tomar las medidas necesarias

b) Analizar los resultados de las métricas
c) Tomar medidas correctivas si es necesario, es decir, si los valores
obtenidos están por debajo de los valores mínimos aceptables. Estas
medidas correctivas pueden afectar tanto al proceso de desarrollo como
al proceso de gestión.
3.2.3 AL FINAL DEL PROYECTO:
6
Una vez finalizado el proyecto, será necesario validar las medidas predictivas
utilizadas, y comprobar si en efecto se pueden tomar como indicadores de los
valores finales
4. ESTRUCTURA DE LOS MODELOS DE CALIDAD DE SOFTWARE
Los modelos de calidad en software comparten una estructura en forma de árbol,

compuesta por un conjunto de atributos de calidad de alto nivel que identifican y miden
atributos de bajo nivel a los cuales están conectados.
Los modelos de calidad son creados para proveer las bases para la evaluación de software;
por lo tanto a los atributos de calidad se les tiene que asignar métricas que permitan su
medición.
Generalmente tienen una estructura en tres niveles:
Factores de Calidad
Criterios de Calidad
Métricas
Figura N°1. Estructura De Modelos De Calidad Software
4.1. FACTORES DE CALIDAD:
Se encuentran en el nivel más alto de la jerarquía, representan la calidad desde el

punto de vista del usuario, son las características que componen la calidad. También
conocidos como Atributos de Calidad Externos.
4.2. CRITERIOS DE CALIDAD:
Cada factor se descompone en un conjunto de Criterios De Calidad. Son atributos que,

contribuyen al aspecto de la calidad que el factor asociado representa. Se trata de una
visión de la calidad desde el punto de vista del producto software. También conocidos
como Atributos de Calidad Internos.
7
4.3. METRICAS:
Para cada uno de los criterios de calidad se definen un conjunto de Métricas, que son
medidas cuantitativas de ciertas características del producto que, cuando están
presentes, dan una indicación del grado en que dicho producto posee un determinado
atributo de calidad.
5. TIPOS DE MODELOS DE CALIDAD DE SOFTWARE
PROCESOS
PROYECTO ORGANIZACIO
DE SW N
PRODUCTO
DE SW
Figura N°2. Tipos de Modelos de Calidad Software
5.1. TIPOS DE MODELO DE CALIDAD DE PRODUCTO
5.1.1. MODELOS FIJOS
Existe un catálogo de factores de calidad de partida que se usa como base para
la evaluación de la calidad. Este enfoque supone que el modelo de calidad
contiene todos los factores de calidad posibles, y que se usará un subconjunto
de dichos factores para cada proyecto concreto. En general, la propuesta típica
de un modelo de calidad fijo consiste en una estructuración de los factores en
una jerarquía multinivel, con un conjunto de factores de más alto nivel, unos
criterios que descomponen dichos factores, y eventualmente métricas para la
medida de cada criterio.
La ventaja de estos modelos fijos es que proporcionan una vista común y
comparable que se reutiliza en cada proyecto, ya que el conjunto de factores de
calidad siempre es el mismo. Ahora bien, tiene como inconveniente su poca
8
flexibilidad debido a que asumen que siempre bastará con un subconjunto de

sus factores para evaluar la calidad en cualquier proyecto.
Ejemplos:
Los modelos de McCall et al. (1997), Boehm et al. (1978) y el modelo con un
enfoque más industrial FURPS (Grady y Caswell, 1987)
5.1.2. MODELOS DE CALIDAD A MEDIDA
No existe ningún catálogo de factores de partida, y dichos factores deben ser

identificados para cada proyecto. La idea que guía la construcción de estos
modelos es que se debe partir de la identificación de los objetivos a alcanzar.
Dichos objetivos serían los factores más abstractos que deben descomponerse
en factores más concretos hasta llegar a hacer operativos los objetivos, de
forma que pueda ser medida su consecución. Así, los modelos son creados
desde cero para todo nuevo proyecto. Existen diversas propuestas de métodos
para crear los modelos de calidad a medida.
La ventaja de estos modelos es su total adaptabilidad.
Tienen como inconveniente que el coste de su construcción es muy alto
comparado con el de los modelos fijos, y la reutilización de modelos de un
proyecto a otro es difícil, dado que los factores identificados para un proyecto
no tienen por qué ser adecuados para otro.
Ejemplos:
GQM (Goal-Question-Metric)
5.1.3. MODELOS MIXTOS
Se intenta combinar las ventajas de los dos tipos anteriores de modelos. La idea
es que exista un conjunto de factores de calidad más abstractos que sean
reutilizados en virtualmente todos los proyectos posibles, y que puedan ser
refinados y operacionalizados para un proyecto particular.
Ejemplos:
El modelo de Gilb (1988) y el modelo propuesto en el estándar ISO/IEC 9126-1
(2001)
9
ASPECTO MODELOS DE CALIDAD

PROYECTO CMMI
(Ciclo de Vida del SPICE
Software) ISO 12207
ISO 9001 – 2008
ORGANIZACIÓN
ISO 9003
(Gobierno de TI)
COBIT
PROCESO PMI – PMBOOK
(Procesos de la ITIL
Empresa) PRINCE2
PRODUCTO McCALL
(Producto de
Software) ISO 14598
Tabla N°2. Ejemplos de Tipo de Modelos de Calidad Software
6. MODELOS DE CALIDAD DE SOTFWARE
1976 -
1977 - Modelo de McCall
1978 - Modelo de Boehm
1979 -
1980 -
1981 -
1982 -
1983 -
1984 -
1985 - Modelo de Arthur
1986 - Figura N°3. Línea de Tiempo de
1987 - Modelo de FURFPS los Modelos de
1988 - Modelo de Gilb / Modelo de Desutsch
Calidad de Software
1989 -
1990 -
1991 -
1992 - Modelo de Gillies / Modelo de REBOOT
1993 -
1994 -
1995 - Modelo de Dromey
1996 -
1997 -
1998 -
1999 -
2000 -
2001 - ISO
10
6.1. MODELO DE MCCALL (1977)
El modelo de Jim McCall, desarrollado inicialmente para la Fuerza Aérea de los

EE.UU en 1977 que tenía la misión de proporcionar las normas y orientación de
técnicas para la adquisición del software, es uno de los más renombrados
actualmente. Este modelo busca reducir la brecha entre usuarios y desarrolladores
enfocándose en un número de factores de calidad que reflejen las prioridades de
ambos. El modelo establece una jerarquía de Perspectivas (3), Factores (11),
Criterios de Calidad (23) y Métricas (41).
Antes de utilizar este modelo hay que seguir las siguientes pautas:
1. Se aceptan los factores, criterios y métricas que propone los modelos.
2. Se aceptan las relaciones entre factores y criterios, y entre criterios y métricas.
3. Se selecciona un subconjunto de factores de calidad sobre los que aplica los
requisitos de calidad establecidos para el proyecto.
6.1.1. PERSPECTIVAS PARA DEFINIR E IDENTIFICAR LA CALIDAD DE UN

PRODUCTO SOFTWARE:
I.Revisión Del Producto habilidad para ser cambiado.

II.Transición Del Producto adaptabilidad al nuevo ambiente.
III.Operación Del Producto características de operación.
6.1.2. FACTORES DE CALIDAD
I. FACTORES DE REVISIÓN
La revisión del producto incluye los siguientes factores de calidad:
a) Mantenibilidad esfuerzo requerido para localizar y corregir fallas.

b) Flexibilidad facilidad de realizar cambios.
c) Testeabilidad facilidad para realizar el testing, para asegurarse que el
producto no tiene errores y cumple con la especificación.
II. FACTORES DE TRANSICIÓN.
La transición del producto incluye los siguientes factores de calidad:
a) Portabilidad esfuerzo requerido para transferir entre distintos

ambientes de operación.
b) Reusabilidad facilidad de reusar el software en diferentes contextos.
c) Interoperabilidad esfuerzo requerido para acoplar el producto con
otros sistemas.
11
III. FACTORES DE OPERACIÓN.
La operación del producto incluye los siguientes factores de calidad:
a) Correctitud grado en el que el producto cumple con su especificación.

b) Confiabilidad la habilidad del producto de responder ante situaciones
no esperadas.
c) Eficiencia el uso de los recursos tales como tiempo de ejecución y
memoria de ejecución.
d) Integridad protección del programa y sus datos de accesos no
autorizados.
e) Usabilidad facilidad de operación del producto por parte de los
usuarios
6.1.3. CRITERIOS DE CALIDAD:
A. CRITERIOS DEL FACTOR MANTENIBILIDAD
 Consistencia.
 Simplicidad.
 Consistencia.
 Auto-descripción.
 Modularidad.
Pero la mantenibilidad ha cambiado bastante desde 1977, encontrar
y corregir errores es sólo un aspecto más.
Mantenibilidad está muy influenciado por el uso de buenas prácticas a

lo largo de todo el ciclo de desarrollo algunas de estas buenas prácticas
son:
 Seguir una metodología bien definida.
 Usar buenas técnicas de diseño, tanto de procedimientos
como de datos, para aumentar cohesión y reducir
acoplamiento.
 Observar la documentación interna.
 Usar buenas prácticas de programación: nombres
significativos, código legible, etc.
B. CRITERIOS DEL FACTOR FLEXIBILIDAD
12
 Expandibilidad.
 Generalidad.
 Modularidad.
Con el correr de los años este criterio se ha fusionado con
mantenibilidad de hecho, en la definición original, dos de los criterios
de flexibilidad estaban compartidos con mantenibilidad.
C. CRITERIOS DEL FACTOR TESTEABILIDAD

 Simplicidad.
 Instrumentación.
Dado su ubicación en tradicionales modelos de ciclo de vida de
software, la facilidad de testing se define claramente como un criterio
de calidad.
El testeo interactúa con otros criterios de calidad, por ejemplo
correctitud y eficiencia debe ser llevado a cabo siguiendo planes pre-
definidos, con datos conocidos y cuyos resultados sean
predeterminados la testeabilidad puede ser maximizada usando
herramientas automáticas, buenas estrategias de cohesión y de diseño,
y buenas prácticas de programación McCall definió originalmente
métricas para testeabilidad consistentes en una matriz de complejidad
que involucra número y tamaño de módulos, tamaño de
procedimientos, profundidad de anidamiento, número de errores por
unidad de tiempo, etc.
D. CRITERIOS DEL FACTOR PORTABILIDAD

 Modularidad.
 Independencia de la máquina.
 Independencia del sistema operativo.
Algunos autores (Sommerville) lo consideran parte de la reusabilidad
se favorece mediante el seguimiento de estándares, tanto de
procedimientos (X Windows) como de datos (XML) la existencia de
compiladores cruzados favorece la portabilidad.
E. CRITERIOS DEL FACTOR REUSABILIDAD

 Generalidad.
 Modularidad.
13
 Independencia de la máquina.
 Independencia del sistema operativo.
Se puede favorecer la reusabilidad usando librerías de software, y
técnicas de programación orientada a objetos hay que tener en cuenta
que el desarrollo de código reusable cuesta más tiempo y dinero existe
un factor económico difícil de medir: el costo de código reusable y la
ganancia por reusar código ya desarrollado.
F. CRITERIOS DEL FACTOR INTEROPERABILIDAD

 Modularidad.
 Interoperabilidad en comunicación.
 Interoperabilidad en datos.
La interoperabilidad está relacionada con la reusabilidad en la
actualidad su importancia ha crecido debido al creciente interés de
conectarse con sistemas legacy se favorece mediante la adopción de
estándares.
G. CRITERIOS DEL FACTOR CORRECTITUD

 Trazabilidad.
 Completitud.
 Consistencia.
Correctitud es un factor muy difícil de identificar debido a la falta de
terminología estándar se lo pueden confundir con otros factores, tales
como confiabilidad e integridad para medirlo es necesario tener
disponible una especificación formal de los requerimientos, cosa muy
rara salvo en proyecto de alto presupuesto y sistemas críticos las
técnicas para verificarlo pueden ser: inspecciones de código,
verificación matemática y analizadores estáticos de programas.
H. CRITERIOS DEL FACTOR CONFIABILIDAD

 Tolerancia a errores.
 Consistencia.
 Simplicidad.
 Exactitud.
Combina la tolerancia tanto a errores de hardware como de software
técnica de programación tales como tolerancia a las fallas, manejo de
14
excepciones y programación defensiva ayudan puede ser medido con

medidas como:
 Tiempo medio entre fallas.
 Tiempo medio antes de mantenimiento.
 Tiempo medio antes de recuperación.
 Probabilidad de falla.
I. CRITERIOS DEL FACTOR EFICIENCIA

 Eficiencia en tiempo.
 Eficiencia en espacio.
Muchas técnicas favorecen este factor: el lenguaje de programación, el
sistema operativo, optimización de algoritmos, normalización de
datos.
J. CRITERIOS DEL FACTOR INTEGRIDAD

 Control de acceso.
 Auditoría de acceso.
Involucra tanto evitar el acceso malintencionado, así como los daños
causados por errores involuntarios de usuarios autorizados.
K. CRITERIOS DEL FACTOR USABILIDAD
 Operabilidad.
 Entrenamiento.
 Comunicación.
 Volumen de E/S.
 Tasa de E/S.
La usabilidad ha cambiado mucho desde la época de McCall incluye

aspectos tales como adaptabilidad, aprendizaje, adecuación al
contexto algunos autores consideran por ejemplo que facilidad de
aprendizaje es un factor de calidad independiente se puede subdividir
en:
 Ergonomía general el equipo es adecuado para el uso previsto.
 Ergonomía de software estilos de diálogos, metáforas, diseño
de pantallas, etc.
15
16
Tabla N°3. Modelo de McCall
EJES
PRODUCTO
PRODUCTO
REVISIÓN DE
ASPECTOS O
TRANSCISIÓN
DE PRODUCTO
OPERACIÓN DE
Eficiencia
Fiabilidad
Flexibilidad
Reusabilidad
FACTORES
Facilidad de Uso
Interoperabilidad
Transportabilidad
Facilidad de Prueba
Corrección(Exactitud)
Integridad(Seguridad)
Facilidad de Mantenimiento
Facilidad de Operación

Facilidad de Comunicación

Facilidad de Aprendizaje

Formación

Control de Accesos

Facilidad de Auditorías

Seguridad

Completitud

Trazabilidad

Precisión

Tolerancia a Fallos

Modularidad
      
Simplicidad
  
Exactitud

Eficiencia en Ejecución

CRITERIOS
Concisión

Auto Descripción
    
Instrumentación

Capacidad de Expansión

 
Generalidad
Independencia entre Sistemas y Hardware
 
Independencia del Hardware
 
Compatibilidad de Comunicaciones

Compatibilidad de Datos

Consistencia
  
Eficiencia en Almacenamiento

Estandarización de Datos

6.1.4. MÉTRICAS DE CALIDAD
La medición de cualquiera de estos factores está definida en este modelo

en base a 41métricas para cada criterio existe una lista de condiciones que
se deben cumplir en distintas etapas: requerimientos (R), diseño (D),
implementación (I) se cuentan las condiciones que se satisfacen en cada
una de las etapas, sobre el total posible eso da una medida del criterio, que
se pondera en partes iguales para medir el factor con los otros criterios
asociados al factor.
Para medir el criterio completitud del factor correctitud McCall sugiere las
siguientes condiciones:
 Referencias no ambiguas [R,D,I]

 Referencias a datos bien definidas, o externas [R,D,I]
 Todas las funciones definidas son usadas [R,D,I]
 Todas las condiciones y procesamientos están definidos para
cada punto de decisión [R,D,I]
 Todos los parámetros formales y actuales coinciden [D,I]
 Todos los reportes de problemas han sido resueltos [R,D,I]
 El diseño concuerda con los requerimientos [D]
 El código concuerda con el diseño [I]
Entonces se cuentan la cantidad de sí en cada etapa, resultando en la

métrica de completitud:
𝑆𝐼 𝐸𝑁 𝑅 𝑆𝐼 𝐸𝑁 𝐷 𝑆𝐼 𝐸𝑁 𝐼
( + + )/3
6 8 8
Luego la correctitud se mide como la media entre las medidas de sus

criterios
(COMPLETITUD +TRAZABILIDAD +CONSISTENCIA)
3
6.2. MODELO DE BOEHM
El segundo modelo de calidad más conocido es el presentado por Barry Boehm

en1978 este modelo introduce características de alto nivel, características de nivel
intermedio y características primitivas, cada una de las cuales contribuye al nivel
general de calidad.
17
6.2.1. CARACTERÍSTICAS DE ALTO NIVEL
Las características de alto nivel representan requerimientos generales de

uso pueden ser:
 Utilidad per-se cuan (usable, confiable, eficiente) es el producto en sí
mismo.
 Mantenibilidad cuán fácil es modificarlo, entenderlos y retestearlo.
 Utilidad general si puede seguir usándose si se cambia el ambiente.
6.2.2. CARACTERÍSTICAS DE NIVEL INTERMEDIO
Las características de nivel intermedio representan los factores de calidad

de Boehm:
 Portabilidad (utilidad general).
 Confiabilidad (utilidad per-se).
 Eficiencia (utilidad per-se).
 Usabilidad (utilidad per-se).
 Testeabilidad (mantenibilidad).
 Facilidad de entendimiento (mantenibilidad).
 Modificabilidad o flexibilidad (mantenibilidad).
6.2.3. CARACTERÍSTICAS PRIMITIVAS
El nivel más bajo corresponde a características directamente asociadas a

una o dos métricas de calidad:
A. DE PORTABILIDAD:
 Independencia de dispositivos.
 Auto-contención. De confiabilidad
 Auto-contención.
 Exactitud.
 Completitud.
 Consistencia.
 Robustez/integridad.
B. DE EFICIENCIA:
 Accesibilidad.
 Eficiencia de uso de dispositivos.
18
C. DE USABILIDAD:
 Robustez/integridad.
 Accesibilidad.
 Comunicación.
D. DE TESTEABILIDAD:
 Comunicación.
 Auto descripción.
 Estructuración.
E. DE ENTENDIBILIDAD:
 Consistencia.
 Concisidad.
 Legibilidad.
F. DE MODIFICABILIDAD:
 Aumentabilidad.
INDEPENDENCIA DE DISPOSITIVO
AUTO - CONTENCIÓN
PRECISIÓN
Portabilidad COMPLETITUD
Fiabilidad ROBUSTEZ - INTEGRIDAD
CONSISTENCIA
Eficiencia
UTILIDAD POR LA CONTABILIDAD
UTILIDAD
Ingeniería
GENERAL
Humana EFICIENCIA DE DISPOSITIVO
Prueba ACCESIBILIDAD
Mantenibilidad Entendibilida COMUNICABILIDAD

d
AUTO - DESCRIPTIVO
Modificabilidad
ESTRUCTURACIÓN
CONCISIÓN
LEGIBILIDAD
AUMENTABILIDAD
Figura N°4. Modelo de Boehm
19
6.2.4. COMPARACIÓN DE MODELOS MCCALL-BOEHM
Aunque parezcan similares, la diferencia está en que McCall focaliza en

medidas precisas de alto nivel, mientras que Boehm presenta un rango más
amplio de características primarias la mantenibilidad está más desarrollada
en Boehm.
CRITERIO McCALL BOEHM

Correctitud + +
Integridad + +
Eficiencia + +
Testeabilidad +
Flexibilidad + +
Portabilidad + +
Modificabilidad +
Entendibilidad +
Confiabilidad + +
Usabilidad + +
Mantenible + +
Interoperabilidad +
Reusabilidad + +
Claridad +
Documentación +
Validez +
Tabla N°4 Comparación de Modelos McCall - Boehm
6.2.5. EVALUACIÓN DE LOS MODELOS DE MCCALL Y BOEHM
Estos modelos tienen sus límites:

Es difícil que las características y sub-características sean siempre
perfectamente independientes falta una asociación explícita entre los
modelos y el proceso de software, cómo realizar software de calidad las
características son en general propiedades abstractas medible mediante
métricas. No siempre existe una relación perfectamente lineal entre los
valores de las métricas y las características que deben estimar.
20
6.3. MODELO ARTHUR
Modelo de calidad creado por Arthur Andersen en 1985. Arthur presenta una
variante del modelo de calidad propuesto por McCall., consta de dos acciones:
 Añadir tres nuevos criterios de valoración: Complejidad, Seguridad,

Auditabilidad
 Variar las relaciones de los factores y los criterios
6.4. MODELO FURPS
Desarrollado por Hewlett-Packard (1987). En este modelo se desarrollan un

conjunto de factores de calidad de software, bajo el acrónimo de FURPS:
funcionalidad (Functionality), usabilidad (Usability), confiabilidad (Reliability),
desempeño (Performance) y capacidad de soporte (Supportability).
A continuación se presenta la clasificación de los atributos de calidad que se
incluyen en el modelo, junto con las características asociadas a cada uno.
FACTOR DE CALIDAD ATRIBUTOS

Características y Capacidad del Programa
FUNCIONALIDAD Generalidad de las Funciones
Seguridad del Sistema
Factores Humanos
Factores Estéticos
FACILIDAD DE USO
Consistencia de la Interfaz
Documentación
Frecuencia y Severidad de las Fallas
Exactitud de las Salidas
CONFIABILIDAD Tiempo Medio de Fallos
Capacidad de Recuperación ante Fallas
Capacidad de Predicción
Velocidad del Procesamiento
Tiempo de Respuesta
RENDIMIENTO Consumo de Recursos
Rendimiento Efectivo Total
Eficacia
Extensibilidad
Adaptabilidad
Capacidad de Pruebas
CAPACIDAD DE SOPORTE
Capacidad de Configuración
Compatibilidad
Requisitos de Instalación
Tabla N°5. Modelo de FURPS
21
6.5. MODELO GILB
Modelo de calidad creado por Gilb en 1988. Este modelo presenta como aspecto
fundamental la definición de los atributos de calidad que realmente interesan al
usuario y el nivel de calidad que debe tener cada uno de ellos para satisfacerlo ya
que no tiene sentido exigir calidad en un producto, si no se cuenta con esta base.
Cada atributo tiene subatributos que ayudan a la medición de este. Estos atributos
son:
a. Capacidad de trabajo: Evalúa la capacidad natural del sistema para realizar su

trabajo. Subatributos: capacidad del proceso, capacidad de respuesta,
capacidad de almacenamiento.
b. Disponibilidad: Refleja la medida de la disponibilidad del sistema para realizar

de forma útil el trabajo para el que fue diseñado. Subatributos: fiabilidad,
Mantenibilidad e integridad.
c. Adaptabilidad: Es la medida de la capacidad de un sistema para ser modificado

de manera adecuada. Subatributos: improbabilidad, extensibilidad y
transportabilidad.
d. Utilizabilidad: Es la medida de la facilidad con que la gente será capaz y estará

motivada para utilizar el sistema en la práctica.
Sub-atributos: requisitos de entrada, requisitos de aprendizaje y habilidad de
manejo.
Gilb propone características como la corrección, la integridad, la facilidad de

mantenimiento y la facilidad de uso, como base para proporcionar indicadores
útiles para los equipos de trabajo y sugiere las definiciones, puntos de vista y
medida para cada uno de las siguientes características:
a. Corrección: Grado en el que el software lleva a cabo su función requerida. Si

un programa no opera correctamente, no dará valor agregado a sus usuarios
b. Facilidad de mantenimiento: Posibilidad de corregir un programa si se

encuentra un error, adaptarlo si cambia su entorno, mejorarlo si el cliente
desea un cambio
22
c. Integridad: Habilidad de un sistema para resistir ataques, tanto accidentales

como intencionados, contra su seguridad, a nivel de cualquiera de los tres
principales componentes del software: programas, datos y documentos. Para
medir la integridad, Gilb sugiere la utilización de otros dos atributos como
base:
 Amenaza. es la probabilidad (que se puede estimar o deducir de la
evidencia empírica) de que un ataque de cualquier tipo ocurra en un
tiempo determinado
 Seguridad. es la probabilidad de que se pueda repeler un determinado
ataque
d. Facilidad de uso: Es un intento por cuantificar “lo amigable que puede ser el
producto con el usuario”.
Las características se pueden medir mediante varias sub-características o métricas
detalladas. Para cada una de ellas se debe especificar los siguientes conceptos:
 Nombre y definición de la característica.

 Escala o unidades de medición.
 Recolección de datos o prueba.
 El valor previsto.
 El valor óptimo.
 El valor en el sistema actual.
6.6. MODELO DEUTSCH
Es otra variante al modelo de McCall, añadiéndole nuevos factores y criterios y

estableciendo nuevas relaciones. Para su establecimiento, Deutsch parte de las
necesidades del usuario estimando que éstas pueden clasificarse en dos
categorías:
a) Necesidades Operacionales. Están relacionadas con la capacidad del software

para realizar las tareas que se supone debe llevar a cabo
 Funcional
 Realización
b) Necesidades de Mantenimiento. Se relacionan con la capacidad de modificar

el software para ayudar al usuario
 Cambio
23
 Gestión
Para evaluar cada necesidad, Deutsch necesita 15 factores de calidad, y para

evaluar estos se dispone de 27 criterios de calidad.
6.6.1. FACTORES:
NECESIDADES DEL
FACTORES DE CALIDAD
USUARIO
Funcional Integridad – Fiabilidad – Supervivencia – Utilizabilidad
Eficiencia – Corrección – Seguridad –
Realización
Interoperabilidad
Mantenibilidad – Expansibilidad – Flexibilidad –
Cambio
Transportabilidad – Reutilizabilidad
Gestión Verificable - Gestionable
6.6.2. C
Tabla N°6. Factores del Modelo de Calidad de Deutsch
6.6.2. CRITERIOS:
CRITERIOS
Accesibilidad al sistema Consistencia Independencia
Alcance Funcional Distributivo Modularidad
Aumentabilidad Eficiencia de Almacenamiento Operatividad
Autonomía Eficiencia de Comunicaciones Precisión
Auto – Descriptivo Eficiencia de Proceso Simplicidad
Calidad de Documentación Entrenamiento Soporte
Compatibilidad del Sistema Gestión de Anomalías Seguimiento
Completitud Gestión Segura Virtualidad
Común Generalidad Visibilidad
24
Tabla N°7. Criterios del Modelo de Deutsch
6.7. MODELO DE CALIDAD DE DROMEY
Un modelo presentado por el Sr. R. Geoff Dromey basados en que reconoce que
evaluación de la calidad es diferente para cada producto y que una idea más
dinámica para modelar el proceso es necesario lo suficientemente amplia como
para solicitar los distintos sistemas. Dromey se centra en la relación entre los
atributos de calidad y los sub-atributos, así como intentar conectar propiedades de
productos de software con la calidad del software atributos.
Este modelo describe la idea de relacionar atributos del producto con atributos de
calidad para su evaluación
El modelo se estructura en torno a un proceso de 5 pasos:
1. Elije un conjunto de alto nivel de calidad atributos necesarios para la

evaluación.
2. Lista de componentes y módulos en su sistema.
3. Identificar las propiedades de transporte de calidad
4. Determinar la forma en cada uno de los efectos patrimoniales los atributos de
calidad.
5. Evaluar el modelo e identificar.
6.8. MODELO DE REBOOT
Incorpora dos factores nuevos:
 Mantenibilidad. Refleja la facilidad con que se hace el mantenimiento.

 Pruebas. Consiste en la capacidad del software para facilitar el
establecimiento de criterios, así como la evaluación de dicho software con
relación a esos criterios.
25
FIABILIDAD OBSERVADA
CONSISTENCIA
FIABILIDAD
AUTO - DESCRIPTIVO
MODELO DE SIMPLICIDAD
MANTENIBILIDAD
CALIDAD
MODULARIDAD
SEGUIMIENTO
PRUEBAS
COMPLEJIDAD DE
COMPONENTES
COMPLEJIDAD DEL
CODIGO
Figura N°5. Modelo de REBOOT
6.9. MODELO ISO
6.9.1. ISO 9000
Las siglas ISO significa “Organización Internacional para las

Standardization”. El ISO es la organización responsable de toda una serie
de normas de las cuales la norma ISO 9000 Probablemente es el más
conocido, difundir y utilizar.
a) ISO 19011:2000 "Directrices para la auditoría Gestión de la Calidad

Sistemas.
b) ISO 9004:2000"Directrices para la Calidad Gestión de las
Organizaciones "
c) ISO 9000:2000"Conceptos y Terminología "
d) ISO 9001:2000 "Requisitos para Aseguramiento de la Calidad "
e) ISO 9001 es un estándar de calidad internacional de gestión de
sistemas aplicables a las organizaciones en todo tipo de las
empresas. ISO 9001 internos centra en los procesos de una
organización y métodos y externamente en la gestión
6.9.2. ISO 9126
6.9.2.1. ANTECEDENTES
26
ISO 9126 se publicó en 1991, con el objeto de “promover un entorno

que permita la evaluación de la calidad de software”. En 1994 se
entendió que era necesario modificar y adaptar la norma. En esta
versión se introducen por primera vez los conceptos de calidad interna
y calidad externa. Además se creó una nueva norma (ISO 14598) que
asumía el modelo del proceso de evaluación antes incluido en la norma
ISO 9126.
En 2005 se crea una nueva versión de esa norma, la ISO/IEC 25000, que
entrega una guía para el uso de los nuevos estándares internacionales
llamados Requisitos y Evaluación de Calidad de Procesos de
Software (SQuaRE). La ISO/IEC 25000 establece criterios para la
especificación de requisitos de calidad del software, medidas y
evaluación, además entrega un modelo de calidad que unifica las
definiciones de calidad de los clientes con los atributos durante el
desarrollo.
El estándar 9126 propone un modelo de calidad que se divide en tres

vistas: interior, exterior y de uso. Estas están compuestas por
características, las que se dividen en sub características, y estas a su vez
se componen de atributos.
El estándar está dividido en cuatro partes las cuales dirigen,

respectivamente, lo siguiente:
a) ISO 9126-1 Modelo de calidad (ISO/IEC, 2001)

b) ISO 9126-2 Métricas externas (Mide el software en sí mismo)
c) ISO 9126-3 Métricas de internas (mide el comportamiento del sistema)
d) ISO 9126-4 Calidad en el uso de métricas (mide el efecto de usar el
software en un contexto específico)
CALIDAD DEL
PROCESO
CALIDAD
INTERNA 9126 – 3
9
1
2 CALIDAD
6 EXTERNA 9126 – 2
-
1
CALIDAD
EXTERNA 9126 – 4
27
Figura N°6 Estándar 9126
6.9.2.2. ISO 9126-1 MODELO DE CALIDAD (ISO/IEC, 2001)
La cual se divide en 2:
A. MODELO DE CALIDAD PARA CALIDAD INTERNA Y EXTERNA :
La norma ISO/IEC 9126 define la calidad interna como:
“La totalidad de las características del producto software desde

una perspectiva interna. La calidad interna es medida y evaluada
en base a los requerimientos de calidad interna. Los detalles de la
calidad del producto software pueden ser mejorados durante la
implementación, revisión y prueba del código software, pero la
naturaleza fundamental de la calidad del producto software
representada por la calidad interna permanece sin cambio a
menos que sea re diseñado”.
La norma ISO/IEC 9126 define la calidad externa como:
“La calidad de un producto software debería ser evaluado usando

un modelo de calidad. ISO 9126-1 propone un modelo de calidad
categorizando la calidad de los atributos software en seis
características, los cuales son subdivididos en subcategorías. Las
subcategorías pueden ser medidas con métricas internas o
externas.”
La calidad externa e interna establecen que cualquier

componente de calidad del software puede ser descrito en
términos de una o más de seis características básicas, las cuales
son: funcionalidad, confiabilidad, usabilidad, eficiencia,
mantenibilidad y portabilidad; cada una de las cuales se detalla a
través de un conjunto de sub características que permiten
profundizar en la evaluación de la calidad de productos de
software y la calidad de las necesidades del usuario o calidad de
uso que posee cuatro características que ayuden al usuario a
cumplir sus objetivos, ellas son: eficacia, productividad, seguridad
y satisfacción.
28
Figura N°7. Características Modelo de Calidad para Calidad Interna y Externa

1.1. Funcionalidad:
¿Las funciones y propiedades satisfacen las necesidades explícitas

e implícitas; esto es, el qué...? - En este grupo se conjunta una serie
de atributos que permiten calificar si un producto de software
maneja en forma adecuada el conjunto de funciones que
satisfagan las necesidades para las cuales fue diseñado. Para este
propósito se establecen los siguientes atributos:
 Adecuación: Capacidad del producto software para

proporcionar un conjunto apropiado de funciones para tareas
y objetivos de usuario especificados.
 Exactitud: Capacidad del producto software para
proporcionar los resultados o efectos correctos o acordados,
con el grado necesario de precisión.
 Interoperabilidad: Capacidad del producto software para
interactuar con uno o más sistemas especificados.
 Seguridad de acceso: Capacidad del producto software para
proteger información y datos de manera que las personas o
sistemas no autorizados no puedan leerlos o modificarlos, al
tiempo que no se deniega el acceso a las personas o sistemas
autorizados
29
 Cumplimiento funcional: Capacidad del producto software

para adherirse a normas, convenciones o regulaciones en
leyes y prescripciones similares relacionadas con
funcionalidad.
1.2. Fiabilidad / Confiabilidad:
¿Puede mantener el nivel de rendimiento, bajo ciertas condiciones

y por cierto tiempo? - Aquí se agrupan un conjunto de atributos
que se refieren a la capacidad del software de mantener su nivel
de ejecución bajo condiciones normales en un periodo de tiempo
establecido.
Las sub características que el estándar sugiere son:
 Madurez: Capacidad del producto software para evitar fallar

como resultado de fallos en el software.
 Tolerancia a fallos: Capacidad del software para mantener un
nivel especificado de prestaciones en caso de fallos software
o de infringir sus interfaces especificados.
 Capacidad de recuperación: Capacidad del producto software
para restablecer un nivel de prestaciones especificado y de
recuperar los datos directamente afectados en caso de fallo.
 Cumplimiento de la fiabilidad: Capacidad del producto
software para adherirse a normas, convenciones o
regulaciones relacionadas con la fiabilidad.
1.3. Usabilidad:
¿El software es fácil de usar y de aprender? - Consiste de un

conjunto de atributos que permiten evaluar el esfuerzo necesario
que deberá invertir el usuario para utilizar el sistema.
 Capacidad para ser entendido: Capacidad del producto

software que permite al usuario entender si el software es
adecuado y cómo puede ser usado para unas tareas o
condiciones de uso particulares.
 Capacidad para ser aprendido: Capacidad del producto
software que permite al usuario aprender sobre su aplicación.
30
 Capacidad para ser operado: Capacidad del producto

software que permite al usuario operarlo y controlarlo.
 Capacidad de atracción: Capacidad del producto software
para ser atractivo al usuario.
 Cumplimiento de la usabilidad: Capacidad del producto
software para adherirse a normas, convenciones, guías de
estilo o regulaciones relacionadas con la usabilidad.
1.4. Mantenibilidad:
¿Es fácil de modificar y verificar? Se refiere a los atributos que

permiten medir el esfuerzo necesario para realizar modificaciones
al software, ya sea por la corrección de errores o por el incremento
de necesidades.
 Capacidad para ser analizado: Es la capacidad del producto

software para serle diagnosticadas deficiencias o causas de los
fallos en el software, o para identificar las partes que han de
ser modificadas.
 Capacidad para ser cambiado: Capacidad del producto
software que permite que una determinada modificación sea
implementada.
 Estabilidad: Capacidad del producto software para evitar
efectos inesperados debidos a modificaciones del software.
 Capacidad para ser probado: Capacidad del producto
software que permite que el software modificado sea
validado.
 Cumplimiento de la mantenibilidad: Capacidad del producto
software para adherirse a normas o convenciones
relacionadas con la mantenibilidad.
1.5. Portabilidad:
¿Es fácil de transferir de un ambiente a otro? - En este caso, se

refiere a la habilidad del software de ser transferido de un
ambiente a otro, y considera los siguientes aspectos:
31
 Adaptabilidad: Evalúa la oportunidad para adaptar el

software a diferentes ambientes sin necesidad de aplicarle
modificaciones.
 Facilidad de Instalación: Es el esfuerzo necesario para instalar
el software en un ambiente determinado.
 Conformidad: Permite evaluar si el software se adhiere a
estándares o convenciones relativas a portabilidad.
 Capacidad de reemplazo: Se refiere a la oportunidad y el
esfuerzo usado en sustituir el software por otro producto con
funciones similares.
 Capacidad de portabilidad: capacidad del producto de
software de permitir que usuarios alcancen objetivos
específicos con eficacia, productividad, seguridad y
satisfacción en contextos de uso específicos.
1.6. Eficiencia:
Capacidad que permite que los usuarios alcancen objetivos con

exactitud e integridad, en un contexto especifico.
 Comportamiento temporal: Capacidad del producto software

para proporcionar tiempos de respuesta, tiempos de proceso
y potencia apropiados, bajo condiciones determinadas.
 Utilización de recursos: Capacidad del producto software para
usar las cantidades y tipos de recursos adecuados cuando el
software lleva a cabo su función bajo condiciones
determinadas.
 Cumplimiento de la eficiencia: Capacidad del producto
software para adherirse a normas o convenciones
relacionadas con la eficiencia.
B. CALIDAD EN USO
La norma ISO/IEC 9126-1 define la calidad en uso como:
“La perspectiva del usuario de la calidad del producto software

cuando éste es usado en un ambiente específico y un contexto de
uso específico. Ésta mide la extensión para la cual los usuarios
pueden conseguir sus metas en un ambiente particular, en vez de
medir las propiedades del software en sí mismo”.
32
Para la vista en uso se contemplan 4 características
VISTA EN USO
Efectividad Productividad Seguridad Satisfacción
Figura N°8. Características de Vista en Uso
2.1. Efectividad: capacidad del software de facilitar al usuario

alcanzar Objetivos con precisión y completitud.
2.2. Productividad: Capacidad del software de permitir a los

usuarios gastar la cantidad apropiada de recursos en
relación a la efectividad obtenida.
2.3. Seguridad: Capacidad del software para cumplir con los
niveles de riesgo emitidos tanto para posibles daños físicos
como para posibles riesgos de datos.´
2.4. Satisfacción: Capacidad del software de cumplir con las
expectativas de los usuarios en un contexto determinado.
6.9.2.2.1. MÉTRICAS DE CALIDAD DE PRODUCTO
Las métricas de calidad de producto se aplican a los diversos atributos

del producto y que permiten determinar posteriormente los niveles
de calidad del producto. Las métricas que se pueden aplicar de
acuerdo a los atributos están definidas en las normas ISO/IEC 9126-2
para el caso de la calidad externa, las ISO/IEC 9126-3 para el caso de
la calidad interna y la ISO/IEC 9126-4 para el caso de la calidad en uso.
En todos los casos las normas señalan que las métricas presentadas
no pretenden ser exhaustivas, ni limita la posibilidad de usar otras
métricas de acuerdo a las necesidades del usuario.
El anexo A de la norma ISO/IEC 9126-1 señala lo siguiente:
33
“Se han encontrado que los niveles de ciertos atributos internos

influyen los niveles de algunos atributos externos, de modo que haya
un aspecto externo y un aspecto interno a la mayoría de las
características. Por ejemplo, la confiabilidad puede ser medida
externamente observando el número de fallas en un período de
tiempo de ejecución dedo durante un ensayo del software e
internamente examinando las especificaciones detalladas y el código
fuente para determinar el nivel de la tolerancia a fallas. Los atributos
internos serían los indicadores de los atributos externos. Un atributo
interno puede influenciar a una o más características, y una
característica puede ser influenciada por más de un atributo. En este
modelo la totalidad de atributos de la calidad del producto software
son clasificados en una estructura arborescente jerárquica de
características y sub características. El nivel más alto de esta
estructura consiste en características de calidad y el nivel más bajo
consiste en atributos de calidad de software.
La jerarquía no es perfecta, porque algunos atributos pueden
contribuir a más de una sub característica”1.
A. Métricas externas: son aquellas que miden el comportamiento

de todo el software o parte de él, a través de testeos,
operaciones y observaciones del software ejecutable en el
sistema. Proporcionando a todos los involucrados el beneficio de
conocer la calidad del producto software durante las pruebas u
operación y sabemos si cumple con la calidad esperada.
La norma ISO/IEC 9126-1 señala que:
“Antes de adquirir o usar un producto software este debería ser

evaluado usando la métrica basada en los objetivos del negocio
relacionados al uso, explotación y administración del producto en
una organización y un ambiente técnico específico”2.
B. Métricas internas: Las métricas internas pueden ser aplicadas

durante el diseño y la codificación del producto software no
ejecutable (por ejemplo código fuente) y proporciona a todos los
involucrados el beneficio de conocer la calidad del producto
durante su construcción y tomar decisiones sobre esa base para
conseguir el producto con la calidad esperada.
1
http://inform.pucp.edu.pe/~edavila/publicaciones/calidadproductosoftware_ok.pdf
2
Libro Calidad Del Producto Y Proceso Software, CALERO, C, pág. 38
34
La norma ISO/IEC 9126-1 señala que:
“Las métricas internas miden atributos internos o indican los

atributos externos a través del análisis de las propiedades
estáticas de productos intermedio o entregables del producto
software. Las medidas de las métricas internas usan números o
frecuencias de elementos de composición de software los cuales
aparecen por ejemplo en las sentencias de código fuente, gráficos
de control, flujo de datos y representaciones de estado de
transición”.
6.9.2.2.2. LA CALIDAD EN EL USO:
Si bien el modelo indica que estas sub características a su vez se

subdividen en atributos, no se especifica cuáles son esos atributos, ya
que se entiende que estos son entidades dependientes del producto
software y variarán según varíe la naturaleza del software analizado:
lenguaje, paradigma de programación, complejidad tecnológica, etc.
a. Métricas de uso: Mide como un producto cumple con las
necesidades de los usuarios para alcancen sus objetivos. La
evaluación de la calidad en el uso valida la calidad del producto
software en escenarios específicos de uso. Este estándar
proviene desde el modelo establecido en 1977 por McCall y sus
colegas, los cuales propusieron un modelo para especificar la
calidad del software. El modelo de calidad McCall está
organizado sobre tres tipos de Características de Calidad:
 Factores (especificar): Ellos describen la visión externa del
software, como es visto por los usuarios.
 Criterios (construir): Ellos describen la visión interna del
software, con es visto por el desarrollador.
 Métricas (controlar): Ellas son definidas y usadas para
proveer una escala y método para la medida. ISO 9126
distingue entre fallos y no conformidad, siendo un fallo el no
cumplimiento de los requisitos previos, mientras que la no
conformidad afecta a los requisitos especificados. Una
35
Contextos de Uso
distinción similar es hecha entre la validación y la

verificación.
Figura N°9. Proceso del Modelos de Calidad ISO/IEC9126
6.9.2.2.3. UTILIDAD DE LAS NORMAS ISO / IEC 9126
Este estándar está pensado para los desarrolladores, adquirentes,

personal que asegure la calidad y evaluadores independientes,
responsables de especificar y evaluar la calidad del producto
software. Por tanto, puede servir para validar la completitud de una
definición de requisitos, identificar requisitos de calidad de software,
objetivos de diseño y prueba, criterios de aseguramiento de la
calidad, etc.
La calidad de cualquier proceso del ciclo de vida del software

(estándar ISO 12.207) influye en la calidad del producto software que,
a su vez, contribuye a mejorar la calidad en el uso del producto. La
calidad del software puede evaluarse midiendo los atributos internos
(medidas estáticas o productos intermedios) o atributos externos
(comportamiento del código cuando se ejecuta).
El mundo globalizado exige cada vez más la aplicación de estándares

internacionales que garanticen la calidad de los productos. Por esta
razón, es necesario que todo aquel que se dedica al desarrollo de
software incluya en sus procesos, estándares de calidad que permitan
certificarse en alguno de los modelos.
Aquí se ha presentado un estándar, el ISO-9126, el cual establece una

guía para la evaluación de la calidad del software, sin embargo es
necesario que cada empresa dedicada a producir software trabaje en
36
establecer su modelo de calidad que le permita valorar el nivel de

excelencia de sus productos, en el que deberán incluirse
instrumentos de medición que permitan calificar cuantitativamente
cada una de las características aquí presentadas. Es importante
mencionar, que dependiendo de los distintos tipos de aplicaciones
las métricas podrán variar, ya que aunque las características
expuestas son comunes a la totalidad de los productos, cada software
particular requiere una evaluación específica
El estándar ISO 9126, ahora englobado en el proyecto SQuaRE para el

desarrollo de la norma ISO 25000, establece un modelo de calidad en
el que se recogen las investigaciones de multitud de modelos de
calidad propuestos por los investigadores durante los últimos 30 años
para la caracterización de la calidad del producto software.
a) ISO / IEC 15504 (SPICE6)

La norma ISO / IEC 15504: Tecnologías de la Información -
Software Proceso de Evaluación es un estándar internacional a
gran marco para la evaluación de proceso que tiene la intención
de abordar todos los procesos que intervienen en:
• Software de adquisición
• Desarrollo
• Operación
• Suministro
• Mantenimiento
• Apoyo
ISO / IEC 15504 se compone de 9 componentes que cubren los

conceptos, modelo de referencia y mejora de procesos guía,
modelo de evaluación y guías, las calificaciones de los
evaluadores, y la guía para determinar el proceso de proveedor
capacidad:
Dada la estructura y el contenido de la norma ISO / IEC 15504 es
la documentación más estrechamente relacionados con la norma
ISO 9000
6.10. MODELO PARASURAMAN
37
Se describe el modelo SERVQUAL el cual contiene cinco dimensiones y 22 items

para medir los diferentes elementos de la calidad de un servicio en general. La
idea de este modelo es que puede ser adaptado a diferentes entornos en función
de los servicios ofrecidos por cada uno de ellos, adaptando las dimensiones
descritas en el modelo original.
6.11. MODELO CAI (2000)
Proponen un modelo de calidad para componentes y sistemas basados en

componentes.
6.12. MODELO FERNANDEZ AND ROSSI (2000)
Define un modelo de calidad para software distribuido.
6.13. MODELO PROPUESTO BERTOA Y VALLECILLO (2002).
Para componentes software en el que los autores adaptan la norma ISO/IEC 9126
a los componentes COTS (Comercial Off – The - Shelf).
6.14. MODELO DE CALIDAD QUINT2 (NIESSINK, 2002).
Presenta una ampliación de la norma ISO/IEC 9126, pensada para valorar la

calidad de arquitecturas software.
6.15. MODELO EN ZO AND RAMAMURHTY (2002).
Los autores presentan un modelo para valorar y seleccionar los sitios web de
comercio electrónico en un entorno B2C (Business To Consumer).
6.16. MODELO EN WEB AND WEB (2002).
Presentan los factores de calidad del sitio web que son importantes para los
consumidores.
6.17. MODELO DE SIMAO Y BELCHIOR (2003).
En el que los autores han ampliado las sub-características y atributos propuestos

por la norma ISO/IEC 9126, llegando a identificar 124 atributos de calidad para
los componentes software.
38
6.18. MODELO DE CALIDAD PROPUESTO POR FRANCH AND CARVALLO (2003).
Presenta una adaptación de la ISO/IEC 9126para servidores de correo electrónico
6.19. MODELO BOTELLA (2003).
Proponen un modelo para la selección de ERP y también escogen como marco de

trabajo el estándar de calidad ISO/IEC 9126-1.
6.20. MODELO WQM.
Pretende ser un modelo global de calidad de la web. Está caracterizado por 3

elementos:
I. La característica de calidad (basada en QUINT2 y en la ISO/IEC 9126)
II. El proceso del ciclo de vida (basado en la ISO/IEC 12207)
III. Características (contenido, presentación y navegación)
6.21. MODELO GQM (GOAL QUESTION METRIC).
Enfoque de medición para evaluar la calidad del software basado en la

identificación de objetivos a lograr. A continuación se presenta la estructura del
modelo
I. Nivel conceptual (goal - meta)

II. Se define un objetivo (meta) para un objeto (ente), con respecto a
determinado “modelo de calidad”, ara un punto de vista, relativo a un
contexto en particular.
III. Nivel operativo (question - pregunta)
IV. Se refina un conjunto de preguntas a partir de una meta, identificando el
objeto de medición con respecto a características de calidad seleccionadas
para un punto de vista.
V. Nivel cuantitativo (metric - metrica)
Se asocia un conjunto de métricas para cada pregunta, de modo de responder a

cada una de ellas de un modo cuantitativo3.
6.22. MODELO CMMI
3
OLSINA, Luis. “Ingeniería Web; Marco de medición y evaluación de calidad”. Departamento de informática.
Universidad Nacional de San Luis - La Rioja – Catamarca. Año 2007
39
Es un modelo de calidad del software que clasifica las empresas en niveles de

madurez. Estos niveles sirven para conocer la madurez de los procesos que se
realizan para producir software.
6.22.1. Niveles CMMI:
 Nivel 1. Inicial: Proceso impredecible, poco controlado y reactivo
Este es el nivel en donde están todas las empresas que no tienen procesos.
Los presupuestos se disparan, no es posible entregar el proyecto en fechas,
te tienes que quedar durante noches y fines de semana para terminar un
proyecto. No hay control sobre el estado del proyecto, el desarrollo del
proyecto es completamente opaco, no sabes lo que pasa en él.
 Nivel 2. Gestionado: Proceso caracterizado por proyectos y frecuentemente

reactivo
En este nivel el éxito de los resultados obtenidos se pueden repetir. La
principal diferencia entre este nivel y el anterior es que el proyecto es
gestionado y controlado durante el desarrollo del mismo. El desarrollo no es
opaco y se puede saber el estado del proyecto en todo momento.
Los procesos que hay que implantar para alcanzar este nivel son: Gestión de
requisitos Planificación de proyectos Seguimiento y control de proyectos
Gestión de proveedores Aseguramiento de la calidad Gestión de la
configuración.
 Nivel 3. Definido: Proceso caracterizado por la organización y proactivo.
Alcanzar este nivel significa que la forma de desarrollar proyectos (gestión e

ingeniería) está definida, por definida quiere decir que está establecida,
documentada y que existen métricas (obtención de datos objetivos) para la
consecución de objetivos concretos.
Los procesos que hay que implantar para alcanzar este nivel son:
 Desarrollo de requisitos
 Solución Técnica
 Integración del producto
 Verificación
 Validación
40
 Desarrollo y mejora de los procesos de la organización

 Definición de los procesos de la organización
 Planificación de la formación
 Gestión de riesgos
 Análisis y resolución de toma de decisiones
 Nivel 4. Gestionado Cuantitativamente: El proceso es controlado

cuantitativamente.
Los proyectos usan objetivos medibles para alcanzar las necesidades de los
clientes y la organización. Se usan métricas para gestionar la organización.
Los procesos que hay que implantar para alcanzar este nivel son: Gestión
cuantitativa de proyectos Mejora de los procesos de la organización
 Nivel 5. En Optimización: Enfoque en la mejora del proceso
Los procesos de los proyectos y de la organización están orientados a la

mejora de las actividades. Mejoras incrementales e innovadoras de los
procesos que mediante métricas son identificadas, evaluadas y puestas en
práctica.
Los procesos que hay que implantar para alcanzar este nivel son: Innovación
organizacional Análisis y resolución de las causas.
41
Figura N°10. Niveles del Modelo CMMI
Conclusiones
Para obtener el éxito en la producción de software debemos hacerlo con calidad y

demostrando el grado de ésta, calificando como buena. Esto sólo es posible con la
implantación de un Sistema para el Aseguramiento de la Calidad del Software directamente
relacionado con la política establecida para su elaboración y que esté en correspondencia
con las definiciones internacionales de calidad, ampliamente aceptada, y por los estándares
que se manejan hoy en día.
Recomendaciones
Finalmente como recomendación se sugiere la aplicación de las normativas establecidas a

nivel internacional, mediante la aplicación de métodos de calidad al software a desarrollar.
Con ello se logra garantizar la calidad del mismo y que logre cumplir el objetivo esperado.
42
BIBLIOGRAFIA
 http://modelosdegestiondelacalidad.blogspot.com/
 http://repositorio.utp.edu.co/dspace/bitstream/11059/1977/1/0053R173e.pdf
 http://www.slideshare.net/elsuse/calidad-del-software
 http://modelosdegestiondelacalidad.blogspot.com/
 http://es.scribd.com/doc/56605621/8/Estructura-de-los-modelos-de-calidad
 http://upcommons.upc.edu/pfc/bitstream/2099.1/11310/1/Tesina_Antonio_Perez
_Jimenez.pdf
 http://gpherrera1990.blogspot.com/2010/07/unidad-1.html
 https://export.writer.zoho.com/public/gerardogomez/modelos-de-calidad-de-
software/fullpage
 http://clases3gingsof.wetpaint.com/page/FURPS
 http://bdigital.eafit.edu.co/PROYECTO/P005.14CDP613/marcoTeorico.pdf
 http://repositorio.utp.edu.co/dspace/bitstream/11059/1977/1/0053R173e.pdf
43
 http://cdn.bitbucket.org/cuatrorios/calidad-de-
software/downloads/3.%20Introduccion%20a%20los%20modelos%20de%20calida
d.pdf
 http://www.slideshare.net/guest768516/modelo-de-calidad-de-desarrollo-de-
software-cmmi
44

Modelos de Calidad de Software

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Modelos de Calidad de Software

Cargado por

Copyright:

Formatos disponibles

MODELOS DE CALIDAD DE SOFTWARE

5.8. Modelo De Reboot ……………………………………………………………………………………. (28)

Un modelo es una representación de un objeto, sistema o idea, de forma diferente al de la

Los modelos de calidad permiten:

a. Definición estructurada de criterios de evaluación

3. MODELOS DE CALIDAD DE SOFTWARE

La obtención de un software con calidad implica la utilización de modelos o procedimientos

Construir un modelo de calidad es bastante complejo y es usual que estos modelos

3.1. VENTAJAS DE LOS MODELOS DE CALIDAD DEL SOFTWARE

Las ventajas de implantar Modelos de Calidad del Software son:

b) Reducir los costos en todos los procesos.

c) Cambiar la actitud del personal de la empresa.

d) Realizar una mejora continua en la calidad de los procesos de software utilizados,

e) Lograr que la empresa de software sea más competitiva.

f) Aumentar la productividad, efectividad y utilidad de la empresa.

g) Asegurar la satisfacción de los clientes internos y externos.

h) Tener productos de software y servicios con valor agregado.

i) Tener permanentemente mejores procesos, productos de software y Servicios

3.2. PASOS PARA EL USO DE UN MODELO DE CALIDAD DEL SOFTWARE

3.2.1 AL PRINCIPIO DEL PROYECTO:

Al especificar la calidad requerida de un producto software hay que:

A. Seleccionar cuáles de los factores de calidad van a ser requisitos de calidad

período de tiempo, aunque el resto del sistema cambie, la ‘facilidad de

2. El coste del factor de calidad frente al beneficio que proporciona. La

3. El coste del factor de calidad frente al beneficio que proporciona. La

BENEFICIOS FRENTE A COSTE

Tabla N°1. Beneficios Frente A Coste De Los Factores De Calidad

4. Las implicaciones de los factores de calidad sobre el ciclo de vida, es

5. Las interrelaciones entre factores. Algunos factores pueden ser

C. Una vez establecidos los factores de calidad, el modelo de calidad

D. Para cada uno de los criterios de calidad se definen o eligen entonces un

E. Se debe entonces establecer valores deseables para los criterios en función

F. Por último, se deberán establecer los valores mínimos aceptables. La

3.2.2 DURANTE EL DESARROLLO:

Todo lo anterior se realizará al principio del proyecto. Ahora bien, durante el

a) Implementar las métricas, es decir, tomar las medidas necesarias

3.2.3 AL FINAL DEL PROYECTO:

4. ESTRUCTURA DE LOS MODELOS DE CALIDAD DE SOFTWARE

Los modelos de calidad en software comparten una estructura en forma de árbol,

Figura N°1. Estructura De Modelos De Calidad Software

4.1. FACTORES DE CALIDAD:

Se encuentran en el nivel más alto de la jerarquía, representan la calidad desde el

4.2. CRITERIOS DE CALIDAD:

Cada factor se descompone en un conjunto de Criterios De Calidad. Son atributos que,

5. TIPOS DE MODELOS DE CALIDAD DE SOFTWARE

Figura N°2. Tipos de Modelos de Calidad Software

5.1. TIPOS DE MODELO DE CALIDAD DE PRODUCTO

5.1.1. MODELOS FIJOS

flexibilidad debido a que asumen que siempre bastará con un subconjunto de

5.1.2. MODELOS DE CALIDAD A MEDIDA

No existe ningún catálogo de factores de partida, y dichos factores deben ser

5.1.3. MODELOS MIXTOS

ASPECTO MODELOS DE CALIDAD

Tabla N°2. Ejemplos de Tipo de Modelos de Calidad Software

6. MODELOS DE CALIDAD DE SOTFWARE

6.1. MODELO DE MCCALL (1977)

El modelo de Jim McCall, desarrollado inicialmente para la Fuerza Aérea de los

6.1.1. PERSPECTIVAS PARA DEFINIR E IDENTIFICAR LA CALIDAD DE UN

I.Revisión Del Producto habilidad para ser cambiado.

6.1.2. FACTORES DE CALIDAD

La revisión del producto incluye los siguientes factores de calidad:

a) Mantenibilidad esfuerzo requerido para localizar y corregir fallas.

II. FACTORES DE TRANSICIÓN.

La transición del producto incluye los siguientes factores de calidad: