Cuáles Son Las Características Del Modelo Virtual CV

MODELOS DE CALIDAD DE SOFTWARE
Ao de la Integracin Nacional y el Reconocimiento de Nuestra Diversidad
UNIVERSIDAD NACIONAL SAN LUIS GONZAGA DE ICA
TEMA :
CURSO : CONTROL DE CALIDAD DE SOFTWARE
INTEGRANTES : Bautista Quispe Leydi

Chaico Lebanoandrea
Gavilan Pecho Luisa
Guillen Martinez Margoth
Mandujano Bendez Alexander
Marca Juarez Mayda
CICLO : VIII
DOCENTE : Antonio Alonso Morales Loaiza
ICA PERU
2012
1
NDICE
ndice De Tablas Y Figuras (4)
Introduccin .. (5)
1. Modelo (6)
2. Modelos De Calidad... (6)
3. Modelos De Calidad De Software. (6)
3.1. Ventajas De Los Modelos De Calidad De Software . (7)
3.2. Pasos Para El Uso De Un Modelo De Calidad Del Software .. (7)
3.2.1. Principio Del Proyecto . (7)
3.2.2. Durante El Proyecto ... (9)
3.2.3. Final Del Proyecto ........ (10)
4. Estructura De Los Modelos De Calidad De Software .. (10)
4.1. Factores De Calidad .... (10)
4.2. Criterios De Calidad .. (10)
4.3. Mtricas . (11)
5. Tipos De Modelos De Calidad De Software.. (11)
5.1. Tipos De Modelos De Calidad De Producto.. (11)
5.1.1. Modelos Fijos.. (11)
5.1.2. Modelos De Calidad A Medida. (12)
5.1.3. Modelos Mixtos.. (12)
6. Modelos De Calidad De Software.. (13)
6.1. Modelo De Mccall (14)
6.1.1. Perspectivas Para Definir E Identificar La Calidad De Un Producto Software (14)
6.1.2. Factores De Calidad.. (14)
I. Factores De Revisin.. (14)
II. Factores De Transicin.. (14)
III. Factores De Operacin .. (15)
6.1.3. Criterios De Calidad .. (15)
6.1.4. Mtricas De Calidad .. (20)
6.2. Modelo De Boehm (20)
6.2.1. Caractersticas De Alto Nivel .. (21)
6.2.2. Caractersticas De Nivel Intermedio (21)
6.2.3. Caractersticas Primitivas . (21)
6.2.4. Comparacin De Modelos Mccall Boehm . (23)
6.2.5. Evaluacin De Modelos Mccall Boehm .. (23)
6.3. Modelo Arthur .. (24)
6.4. Modelo FURPS ... (24)
2
6.5. Modelo Gilb . (25)

6.6. Modelo Deutsch . (26)
6.6.1. Factores .. (27)
6.6.2. Criterios .. (27)
6.7. Modelo De Dromey .. (27)
6.8. Modelo De Reboot . (28)
6.9. Modelo ISO (29)
6.9.1. Iso 9000 .. (29)
6.9.2. Iso 9126 .. (29)
6.9.2.1. Antecedentes ... (29)
6.9.2.2. Iso 9126-1 Modelo De Calidad (Iso/Iec, 2001) . (30)
6.9.2.2.1. Metricas De Calidad Del Producto . (36)
6.9.2.2.2. La Calidad En El Uso . (38)
6.9.2.2.3. Utilidad De Las Normas Iso / Iec 9126 .... (39)
6.10. Modelo Parasuraman (40)
6.11. Modelo Cai (2000) (40)
6.12. Modelo Fernandez And Rossi (2000) .. (40)
6.13. Modelo Propuesto Bertoa y Vallecillo (2002) (42)
6.14. Modelo De Calidad Quint2 (Niessink, 2002) .. (41)
6.15. Modelo En Zo And Ramamurhty (2002) (41)
6.16. Modelo En Web And Web (2002) .. (41)
6.17. Modelo De Simao Y Belchior (2003) . (41)
6.18. Modelo De Calidad Propuesto Por Franch And Carvallo (2003) . (41)
6.19. Modelo Botella (2003) (41)
6.20. Modelo Wqm ... (41)
6.21. Modelo Gqm (Goal Question Metric) . (41)
6.22. Modelo CMMI .. (42)
6.22.1. Niveles De CMMI . (42)
Conclusiones (45)
Recomendaciones .. (45)
Bibliografa . (46)
3
NDICE DE TABLAS Y FIGURAS
1. INDICE DE FIGURAS
Figura N1. Estructura De Modelos De Calidad Software 10

Figura N2. Tipos de Modelos de Calidad Software 11
Figura N3. Lnea de Tiempo de los Modelos de Calidad de Software 13
Figura N4. Modelo de Boehm 22
Figura N5. Modelo de REBOOT 28
Figura N6. Estndar 9126 30
Figura N7. Caractersticas Modelo de Calidad para Calidad Interna y Externa 31
Figura N8. Caractersticas de Vista en Uso 35
Figura N9. Proceso del Modelos de Calidad ISO/IEC9126 38
Figura N10. Niveles del Modelo CMMI 44
2. INDICE DE TABLAS
Tabla N1. Beneficios Frente A Coste De Los Factores De Calidad 8

Tabla N2. Ejemplos de Tipo de Modelos de Calidad Software 13
Tabla N3. Modelo de McCall 19
Tabla N4. Comparacin de Modelos McCall Boehm 23
Tabla N5. Modelo de FURPS 24
Tabla N6. Factores del Modelo de Calidad de Deutsch 27
Tabla N7. Criterios del Modelo de Deutsch 27
4
INTRODUCCIN
Hoy en da nos encontramos en un mundo cada vez ms globalizado, donde cada da la

calidad aparece como una necesidad, la cual permite competir con mayores posibilidades
de xito. La calidad en productos de software ha tenido un auge importante en la sociedad
informatizada de hoy.
Los modelos de calidad son una parte fundamental en los procesos de desarrollo y
evaluacin de la calidad del software
Se debe entender que un modelo de calidad no es una metodologa que nos resuelva la vida
de forma sencilla y clara, los modelos de calidad nos dicen QUE hacer, no COMO hacerlo.
Debido a la necesidad de obtener un software de calidad que debe satisfacer los

requerimientos dados por el usuario, han surgido modelos de calidad que resultan la
prediccin de confiabilidad y la gerencia de calidad durante el proceso de desarrollo y
medicin de la complejidad de un sistema de software.
En este presente documento muestra una breve descripcin y estructura de los modelos de
calidad de software de McCall, Boehm, ISO/IEC 9126 entre otros.
El modelo de McCall fue el primero en ser presentado en 1977, busca reducir la brecha
entre usuarios y desarrolladores enfocndose a factores de calidad.
Modelo Boehm introduce caractersticas de alto nivel, caractersticas de nivel intermedio y

caractersticas primitivas, cada una de las cuales contribuye al nivel general de calidad
ISO/IEC 9126 ISO 9126-1 propone un modelo de calidad categorizando la calidad de los
atributos software en seis caractersticas (funcionalidad, fiabilidad, usabilidad, eficiencia,
mantenibilidad y portabilidad
1. MODELO
5
Un modelo es una representacin de un objeto, sistema o idea, de forma diferente al de la

entidad misma. El propsito de los modelos es ayudarnos a explicar, entender o mejorar un
sistema. Un modelo de un objeto puede ser una rplica exacta de ste o una abstraccin de
las propiedades dominantes del objeto.
2. MODELOS DE CALIDAD
Los Modelos de Calidad son herramientas que guan a las Organizaciones a la Mejora
Continua y la Competitividad dndoles 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 captulos que sirven como referencia para
estructurar un plan de calidad total en una empresa u organizacin, o de una de sus partes.
Los modelos de calidad permiten:
a. Definicin estructurada de criterios de evaluacin

b. Especificacin de requisitos con relacin a ellos
c. Descripcin de componentes en un marco comn
d. Definicin de mtricas y prioridades
3. MODELOS DE CALIDAD DE SOFTWARE
La obtencin de un software con calidad implica la utilizacin de modelos o procedimientos

estndares para el anlisis, diseo, desarrollo y prueba del software que permitan
uniformar la filosofa 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 prcticas para el ciclo de vida
del software, enfocado en los procesos de gestin y desarrollo de proyectos.
Construir un modelo de calidad es bastante complejo y es usual que estos modelos

descompongan la calidad del producto software jerrquicamente en una serie de
caractersticas y sub-caractersticas que pueden usarse como una lista de comprobacin 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:
6
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 ms competitiva.
f) Aumentar la productividad, efectividad y utilidad de la empresa.
g) Asegurar la satisfaccin 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 cules de los factores de calidad van a ser requisitos de calidad

del sistema. Para ello hay que tener varias cosas en consideracin:
1. La relacin que tienen los factores con las caractersticas 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 rpidamente, la portabilidad es esencial;
si se espera que ciertas funciones del sistema se utilicen por un largo
7
perodo de tiempo, aunque el resto del sistema cambie, la facilidad de

reutilizacin 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
Correccin
Fiabilidad
Eficiencia
Integridad
Facilidad de Uso
FACTOR
Facilidad de Mantenimiento
Facilidad de Prueba
Flexibilidad
Portabilidad
Reusabilidad
Interoperabilidad
Tabla N1. 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
prcticamente todos los dems factores de calidad. La siguiente tabla
indica la dependencia entre los factores de McCall.
8
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 automticamente 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 mtricas.
E. Se debe entonces establecer valores deseables para los criterios en funcin

de datos histricos, el promedio en la industria, etc. Se pueden establecer
valores finales, es decir, los que se desea obtener una vez finalizado el
desarrollo, y tambin valores intermedios o predictivos en cada perodo de
medicin durante el desarrollo.
F. Por ltimo, se debern establecer los valores mnimos aceptables. La

explicacin para cualquier seleccin o decisin 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 mtricas, es decir, tomar las medidas necesarias

b) Analizar los resultados de las mtricas
c) Tomar medidas correctivas si es necesario, es decir, si los valores
obtenidos estn por debajo de los valores mnimos aceptables. Estas
medidas correctivas pueden afectar tanto al proceso de desarrollo como
al proceso de gestin.
3.2.3 AL FINAL DEL PROYECTO:
9
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 estn conectados.
Los modelos de calidad son creados para proveer las bases para la evaluacin de software;
por lo tanto a los atributos de calidad se les tiene que asignar mtricas que permitan su
medicin.
Generalmente tienen una estructura en tres niveles:
Factores de Calidad
Criterios de Calidad
Mtricas
Figura N1. Estructura De Modelos De Calidad Software
4.1. FACTORES DE CALIDAD:
Se encuentran en el nivel ms alto de la jerarqua, representan la calidad desde el

punto de vista del usuario, son las caractersticas que componen la calidad. Tambin
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
visin de la calidad desde el punto de vista del producto software. Tambin conocidos
como Atributos de Calidad Internos.
10
4.3. METRICAS:
Para cada uno de los criterios de calidad se definen un conjunto de Mtricas, que son
medidas cuantitativas de ciertas caractersticas del producto que, cuando estn
presentes, dan una indicacin 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 N2. Tipos de Modelos de Calidad Software
5.1. TIPOS DE MODELO DE CALIDAD DE PRODUCTO
5.1.1. MODELOS FIJOS
Existe un catlogo de factores de calidad de partida que se usa como base para
la evaluacin 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 tpica
de un modelo de calidad fijo consiste en una estructuracin de los factores en
una jerarqua multinivel, con un conjunto de factores de ms alto nivel, unos
criterios que descomponen dichos factores, y eventualmente mtricas para la
medida de cada criterio.
La ventaja de estos modelos fijos es que proporcionan una vista comn 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
11
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 ms industrial FURPS (Grady y Caswell, 1987)
5.1.2. MODELOS DE CALIDAD A MEDIDA
No existe ningn catlogo de factores de partida, y dichos factores deben ser

identificados para cada proyecto. La idea que gua la construccin de estos
modelos es que se debe partir de la identificacin de los objetivos a alcanzar.
Dichos objetivos seran los factores ms abstractos que deben descomponerse
en factores ms concretos hasta llegar a hacer operativos los objetivos, de
forma que pueda ser medida su consecucin. As, los modelos son creados
desde cero para todo nuevo proyecto. Existen diversas propuestas de mtodos
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 construccin es muy alto
comparado con el de los modelos fijos, y la reutilizacin de modelos de un
proyecto a otro es difcil, 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 ms 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 estndar ISO/IEC 9126-1
(2001)
12
ASPECTO MODELOS DE CALIDAD

PROYECTO CMMI
(Ciclo de Vida del SPICE
Software) ISO 12207
ISO 9001 2008
ORGANIZACIN
ISO 9003
(Gobierno de TI)
COBIT
PROCESO PMI PMBOOK
(Procesos de la ITIL
Empresa) PRINCE2
PRODUCTO McCALL
(Producto de
Software) ISO 14598
Tabla N2. 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 N3. Lnea 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
13
6.1. MODELO DE MCCALL (1977)
El modelo de Jim McCall, desarrollado inicialmente para la Fuerza Area de los

EE.UU en 1977 que tena la misin de proporcionar las normas y orientacin de
tcnicas para la adquisicin del software, es uno de los ms renombrados
actualmente. Este modelo busca reducir la brecha entre usuarios y desarrolladores
enfocndose en un nmero de factores de calidad que reflejen las prioridades de
ambos. El modelo establece una jerarqua de Perspectivas (3), Factores (11),
Criterios de Calidad (23) y Mtricas (41).
Antes de utilizar este modelo hay que seguir las siguientes pautas:
1. Se aceptan los factores, criterios y mtricas que propone los modelos.
2. Se aceptan las relaciones entre factores y criterios, y entre criterios y mtricas.
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.Revisin Del Producto habilidad para ser cambiado.

II.Transicin Del Producto adaptabilidad al nuevo ambiente.
III.Operacin Del Producto caractersticas de operacin.
6.1.2. FACTORES DE CALIDAD
I. FACTORES DE REVISIN
La revisin 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 especificacin.
II. FACTORES DE TRANSICIN.
La transicin del producto incluye los siguientes factores de calidad:
a) Portabilidad esfuerzo requerido para transferir entre distintos

ambientes de operacin.
b) Reusabilidad facilidad de reusar el software en diferentes contextos.
c) Interoperabilidad esfuerzo requerido para acoplar el producto con
otros sistemas.
14
III. FACTORES DE OPERACIN.
La operacin del producto incluye los siguientes factores de calidad:
a) Correctitud grado en el que el producto cumple con su especificacin.

b) Confiabilidad la habilidad del producto de responder ante situaciones
no esperadas.
c) Eficiencia el uso de los recursos tales como tiempo de ejecucin y
memoria de ejecucin.
d) Integridad proteccin del programa y sus datos de accesos no
autorizados.
e) Usabilidad facilidad de operacin del producto por parte de los
usuarios
6.1.3. CRITERIOS DE CALIDAD:
A. CRITERIOS DEL FACTOR MANTENIBILIDAD
Consistencia.
Simplicidad.
Consistencia.
Auto-descripcin.
Modularidad.
Pero la mantenibilidad ha cambiado bastante desde 1977, encontrar
y corregir errores es slo un aspecto ms.
Mantenibilidad est muy influenciado por el uso de buenas prcticas a

lo largo de todo el ciclo de desarrollo algunas de estas buenas prcticas
son:
Seguir una metodologa bien definida.
Usar buenas tcnicas de diseo, tanto de procedimientos
como de datos, para aumentar cohesin y reducir
acoplamiento.
Observar la documentacin interna.
Usar buenas prcticas de programacin: nombres
significativos, cdigo legible, etc.
B. CRITERIOS DEL FACTOR FLEXIBILIDAD
15
Expandibilidad.
Generalidad.
Auto-descripcin.
Modularidad.
Con el correr de los aos este criterio se ha fusionado con
mantenibilidad de hecho, en la definicin original, dos de los criterios
de flexibilidad estaban compartidos con mantenibilidad.
C. CRITERIOS DEL FACTOR TESTEABILIDAD

Simplicidad.
Instrumentacin.
Dado su ubicacin en tradicionales modelos de ciclo de vida de
software, la facilidad de testing se define claramente como un criterio
de calidad.
El testeo interacta 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 automticas, buenas estrategias de cohesin y de diseo,
y buenas prcticas de programacin McCall defini originalmente
mtricas para testeabilidad consistentes en una matriz de complejidad
que involucra nmero y tamao de mdulos, tamao de
procedimientos, profundidad de anidamiento, nmero de errores por
unidad de tiempo, etc.
D. CRITERIOS DEL FACTOR PORTABILIDAD

Auto-descripcin.
Modularidad.
Independencia de la mquina.
Independencia del sistema operativo.
Algunos autores (Sommerville) lo consideran parte de la reusabilidad
se favorece mediante el seguimiento de estndares, tanto de
procedimientos (X Windows) como de datos (XML) la existencia de
compiladores cruzados favorece la portabilidad.
E. CRITERIOS DEL FACTOR REUSABILIDAD

Generalidad.
Modularidad.
16
Auto-descripcin.
Independencia de la mquina.
Independencia del sistema operativo.
Se puede favorecer la reusabilidad usando libreras de software, y
tcnicas de programacin orientada a objetos hay que tener en cuenta
que el desarrollo de cdigo reusable cuesta ms tiempo y dinero existe
un factor econmico difcil de medir: el costo de cdigo reusable y la
ganancia por reusar cdigo ya desarrollado.
F. CRITERIOS DEL FACTOR INTEROPERABILIDAD

Modularidad.
Interoperabilidad en comunicacin.
Interoperabilidad en datos.
La interoperabilidad est relacionada con la reusabilidad en la
actualidad su importancia ha crecido debido al creciente inters de
conectarse con sistemas legacy se favorece mediante la adopcin de
estndares.
G. CRITERIOS DEL FACTOR CORRECTITUD

Trazabilidad.
Completitud.
Consistencia.
Correctitud es un factor muy difcil de identificar debido a la falta de
terminologa estndar se lo pueden confundir con otros factores, tales
como confiabilidad e integridad para medirlo es necesario tener
disponible una especificacin formal de los requerimientos, cosa muy
rara salvo en proyecto de alto presupuesto y sistemas crticos las
tcnicas para verificarlo pueden ser: inspecciones de cdigo,
verificacin matemtica y analizadores estticos de programas.
H. CRITERIOS DEL FACTOR CONFIABILIDAD

Tolerancia a errores.
Consistencia.
Simplicidad.
Exactitud.
Combina la tolerancia tanto a errores de hardware como de software
tcnica de programacin tales como tolerancia a las fallas, manejo de
17
excepciones y programacin defensiva ayudan puede ser medido con

medidas como:
Tiempo medio entre fallas.
Tiempo medio antes de mantenimiento.
Tiempo medio antes de recuperacin.
Probabilidad de falla.
I. CRITERIOS DEL FACTOR EFICIENCIA

Eficiencia en tiempo.
Eficiencia en espacio.
Muchas tcnicas favorecen este factor: el lenguaje de programacin, el
sistema operativo, optimizacin de algoritmos, normalizacin de
datos.
J. CRITERIOS DEL FACTOR INTEGRIDAD

Control de acceso.
Auditora de acceso.
Involucra tanto evitar el acceso malintencionado, as como los daos
causados por errores involuntarios de usuarios autorizados.
K. CRITERIOS DEL FACTOR USABILIDAD
Operabilidad.
Entrenamiento.
Comunicacin.
Volumen de E/S.
Tasa de E/S.
La usabilidad ha cambiado mucho desde la poca de McCall incluye

aspectos tales como adaptabilidad, aprendizaje, adecuacin al
contexto algunos autores consideran por ejemplo que facilidad de
aprendizaje es un factor de calidad independiente se puede subdividir
en:
Ergonoma general el equipo es adecuado para el uso previsto.
Ergonoma de software estilos de dilogos, metforas, diseo
de pantallas, etc.
18
19
Tabla N3. Modelo de McCall
EJES
PRODUCTO
PRODUCTO
REVISIN DE
ASPECTOS O
TRANSCISIN
DE PRODUCTO
OPERACIN DE
Eficiencia
Fiabilidad
Flexibilidad
Reusabilidad
FACTORES
Facilidad de Uso
Interoperabilidad
Transportabilidad
Facilidad de Prueba
Correccin(Exactitud)
Integridad(Seguridad)
Facilidad de Mantenimiento
Facilidad de Operacin

Facilidad de Comunicacin

Facilidad de Aprendizaje

Formacin

Control de Accesos

Facilidad de Auditoras

Seguridad

Completitud

Trazabilidad

Precisin

Tolerancia a Fallos

Modularidad

Simplicidad

Exactitud

Eficiencia en Ejecucin

CRITERIOS
Concisin

Auto Descripcin

Instrumentacin

Capacidad de Expansin

Generalidad
Independencia entre Sistemas y Hardware

Independencia del Hardware

Compatibilidad de Comunicaciones

Compatibilidad de Datos

Consistencia

Eficiencia en Almacenamiento

Estandarizacin de Datos

6.1.4. MTRICAS DE CALIDAD
La medicin de cualquiera de estos factores est definida en este modelo

en base a 41mtricas para cada criterio existe una lista de condiciones que
se deben cumplir en distintas etapas: requerimientos (R), diseo (D),
implementacin (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 denidas, o externas [R,D,I]
Todas las funciones denidas son usadas [R,D,I]
Todas las condiciones y procesamientos estn denidos para
cada punto de decisin [R,D,I]
Todos los parmetros formales y actuales coinciden [D,I]
Todos los reportes de problemas han sido resueltos [R,D,I]
El diseo concuerda con los requerimientos [D]
El cdigo concuerda con el diseo [I]
Entonces se cuentan la cantidad de s en cada etapa, resultando en la

mtrica 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 ms conocido es el presentado por Barry Boehm

en1978 este modelo introduce caractersticas de alto nivel, caractersticas de nivel
intermedio y caractersticas primitivas, cada una de las cuales contribuye al nivel
general de calidad.
20
6.2.1. CARACTERSTICAS DE ALTO NIVEL
Las caractersticas de alto nivel representan requerimientos generales de

uso pueden ser:
Utilidad per-se cuan (usable, confiable, eficiente) es el producto en s
mismo.
Mantenibilidad cun fcil es modificarlo, entenderlos y retestearlo.
Utilidad general si puede seguir usndose si se cambia el ambiente.
6.2.2. CARACTERSTICAS DE NIVEL INTERMEDIO
Las caractersticas 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. CARACTERSTICAS PRIMITIVAS
El nivel ms bajo corresponde a caractersticas directamente asociadas a

una o dos mtricas de calidad:
A. DE PORTABILIDAD:
Independencia de dispositivos.
Auto-contencin. De confiabilidad
Auto-contencin.
Exactitud.
Completitud.
Consistencia.
Robustez/integridad.
B. DE EFICIENCIA:
Accesibilidad.
Eficiencia de uso de dispositivos.
21
C. DE USABILIDAD:
Robustez/integridad.
Accesibilidad.
Comunicacin.
D. DE TESTEABILIDAD:
Comunicacin.
Auto descripcin.
Estructuracin.
E. DE ENTENDIBILIDAD:
Consistencia.
Estructuracin.
Concisidad.
Legibilidad.
F. DE MODIFICABILIDAD:
Estructuracin.
Aumentabilidad.
INDEPENDENCIA DE DISPOSITIVO
AUTO - CONTENCIN
PRECISIN
Portabilidad COMPLETITUD
Fiabilidad ROBUSTEZ - INTEGRIDAD
CONSISTENCIA
Eficiencia
UTILIDAD POR LA CONTABILIDAD
UTILIDAD
Ingeniera
GENERAL
Humana EFICIENCIA DE DISPOSITIVO
Prueba ACCESIBILIDAD
Mantenibilidad Entendibilida COMUNICABILIDAD

d
AUTO - DESCRIPTIVO
Modificabilidad
ESTRUCTURACIN
CONCISIN
LEGIBILIDAD
AUMENTABILIDAD
Figura N4. Modelo de Boehm
22
6.2.4. COMPARACIN 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 ms
amplio de caractersticas primarias la mantenibilidad est ms desarrollada
en Boehm.
CRITERIO McCALL BOEHM

Correctitud + +
Integridad + +
Eficiencia + +
Testeabilidad +
Flexibilidad + +
Portabilidad + +
Modificabilidad +
Entendibilidad +
Confiabilidad + +
Usabilidad + +
Mantenible + +
Interoperabilidad +
Reusabilidad + +
Claridad +
Documentacin +
Validez +
Tabla N4 Comparacin de Modelos McCall - Boehm
6.2.5. EVALUACIN DE LOS MODELOS DE MCCALL Y BOEHM
Estos modelos tienen sus lmites:

Es difcil que las caractersticas y sub-caractersticas sean siempre
perfectamente independientes falta una asociacin explcita entre los
modelos y el proceso de software, cmo realizar software de calidad las
caractersticas son en general propiedades abstractas medible mediante
mtricas. No siempre existe una relacin perfectamente lineal entre los
valores de las mtricas y las caractersticas que deben estimar.
23
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:
Aadir tres nuevos criterios de valoracin: 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 acrnimo de FURPS:
funcionalidad (Functionality), usabilidad (Usability), confiabilidad (Reliability),
desempeo (Performance) y capacidad de soporte (Supportability).
A continuacin se presenta la clasificacin de los atributos de calidad que se
incluyen en el modelo, junto con las caractersticas asociadas a cada uno.
FACTOR DE CALIDAD ATRIBUTOS

Caractersticas y Capacidad del Programa
FUNCIONALIDAD Generalidad de las Funciones
Seguridad del Sistema
Factores Humanos
Factores Estticos
FACILIDAD DE USO
Consistencia de la Interfaz
Documentacin
Frecuencia y Severidad de las Fallas
Exactitud de las Salidas
CONFIABILIDAD Tiempo Medio de Fallos
Capacidad de Recuperacin ante Fallas
Capacidad de Prediccin
Velocidad del Procesamiento
Tiempo de Respuesta
RENDIMIENTO Consumo de Recursos
Rendimiento Efectivo Total
Eficacia
Extensibilidad
Adaptabilidad
Capacidad de Pruebas
CAPACIDAD DE SOPORTE
Capacidad de Configuracin
Compatibilidad
Requisitos de Instalacin
Tabla N5. Modelo de FURPS
24
6.5. MODELO GILB
Modelo de calidad creado por Gilb en 1988. Este modelo presenta como aspecto
fundamental la definicin 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 medicin de este. Estos atributos
son:
a. Capacidad de trabajo: Evala 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 diseado. 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 prctica.
Sub-atributos: requisitos de entrada, requisitos de aprendizaje y habilidad de
manejo.
Gilb propone caractersticas como la correccin, 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 caractersticas:
a. Correccin: Grado en el que el software lleva a cabo su funcin 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
25
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 utilizacin de otros dos atributos como
base:
Amenaza. es la probabilidad (que se puede estimar o deducir de la
evidencia emprica) 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 caractersticas se pueden medir mediante varias sub-caractersticas o mtricas
detalladas. Para cada una de ellas se debe especificar los siguientes conceptos:
Nombre y definicin de la caracterstica.

Escala o unidades de medicin.
Recoleccin 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, aadindole 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
categoras:
a) Necesidades Operacionales. Estn relacionadas con la capacidad del software

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

el software para ayudar al usuario
Cambio
26
Gestin
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 Correccin Seguridad
Realizacin
Interoperabilidad
Mantenibilidad Expansibilidad Flexibilidad
Cambio
Transportabilidad Reutilizabilidad
Gestin Verificable - Gestionable
6.6.2. C
Tabla N6. 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
Autonoma Eficiencia de Comunicaciones Precisin
Auto Descriptivo Eficiencia de Proceso Simplicidad
Calidad de Documentacin Entrenamiento Soporte
Compatibilidad del Sistema Gestin de Anomalas Seguimiento
Completitud Gestin Segura Virtualidad
Comn Generalidad Visibilidad
27
Tabla N7. 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
evaluacin de la calidad es diferente para cada producto y que una idea ms
dinmica para modelar el proceso es necesario lo suficientemente amplia como
para solicitar los distintos sistemas. Dromey se centra en la relacin 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 evaluacin
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

evaluacin.
2. Lista de componentes y mdulos 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 evaluacin de dicho software con
relacin a esos criterios.
28
FIABILIDAD OBSERVADA
CONSISTENCIA
FIABILIDAD
AUTO - DESCRIPTIVO
MODELO DE SIMPLICIDAD
MANTENIBILIDAD
CALIDAD
MODULARIDAD
SEGUIMIENTO
PRUEBAS
COMPLEJIDAD DE
COMPONENTES
COMPLEJIDAD DEL
CODIGO
Figura N5. Modelo de REBOOT
6.9. MODELO ISO
6.9.1. ISO 9000
Las siglas ISO significa Organizacin Internacional para las

Standardization. El ISO es la organizacin responsable de toda una serie
de normas de las cuales la norma ISO 9000 Probablemente es el ms
conocido, difundir y utilizar.
a) ISO 19011:2000 "Directrices para la auditora Gestin de la Calidad

Sistemas.
b) ISO 9004:2000"Directrices para la Calidad Gestin de las
Organizaciones "
c) ISO 9000:2000"Conceptos y Terminologa "
d) ISO 9001:2000 "Requisitos para Aseguramiento de la Calidad "
e) ISO 9001 es un estndar de calidad internacional de gestin de
sistemas aplicables a las organizaciones en todo tipo de las
empresas. ISO 9001 internos centra en los procesos de una
organizacin y mtodos y externamente en la gestin
6.9.2. ISO 9126
6.9.2.1. ANTECEDENTES
29
ISO 9126 se public en 1991, con el objeto de promover un entorno

que permita la evaluacin de la calidad de software. En 1994 se
entendi que era necesario modificar y adaptar la norma. En esta
versin se introducen por primera vez los conceptos de calidad interna
y calidad externa. Adems se cre una nueva norma (ISO 14598) que
asuma el modelo del proceso de evaluacin antes incluido en la norma
ISO 9126.
En 2005 se crea una nueva versin de esa norma, la ISO/IEC 25000, que
entrega una gua para el uso de los nuevos estndares internacionales
llamados Requisitos y Evaluacin de Calidad de Procesos de
Software (SQuaRE). La ISO/IEC 25000 establece criterios para la
especificacin de requisitos de calidad del software, medidas y
evaluacin, adems entrega un modelo de calidad que unifica las
definiciones de calidad de los clientes con los atributos durante el
desarrollo.
El estndar 9126 propone un modelo de calidad que se divide en tres

vistas: interior, exterior y de uso. Estas estn compuestas por
caractersticas, las que se dividen en sub caractersticas, y estas a su vez
se componen de atributos.
El estndar 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 Mtricas externas (Mide el software en s mismo)
c) ISO 9126-3 Mtricas de internas (mide el comportamiento del sistema)
d) ISO 9126-4 Calidad en el uso de mtricas (mide el efecto de usar el
software en un contexto especfico)
CALIDAD DEL
PROCESO
CALIDAD
INTERNA 9126 3
9
1
2 CALIDAD
6 EXTERNA 9126 2
-
1
CALIDAD
EXTERNA 9126 4
30
Figura N6 Estndar 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 caractersticas 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
implementacin, revisin y prueba del cdigo software, pero la
naturaleza fundamental de la calidad del producto software
representada por la calidad interna permanece sin cambio a
menos que sea re diseado.
La norma ISO/IEC 9126 define la calidad externa como:
La calidad de un producto software debera ser evaluado usando

un modelo de calidad. ISO 9126-1 propone un modelo de calidad
categorizando la calidad de los atributos software en seis
caractersticas, los cuales son subdivididos en subcategoras. Las
subcategoras pueden ser medidas con mtricas internas o
externas.
La calidad externa e interna establecen que cualquier

componente de calidad del software puede ser descrito en
trminos de una o ms de seis caractersticas bsicas, las cuales
son: funcionalidad, confiabilidad, usabilidad, eficiencia,
mantenibilidad y portabilidad; cada una de las cuales se detalla a
travs de un conjunto de sub caractersticas que permiten
profundizar en la evaluacin de la calidad de productos de
software y la calidad de las necesidades del usuario o calidad de
uso que posee cuatro caractersticas que ayuden al usuario a
cumplir sus objetivos, ellas son: eficacia, productividad, seguridad
y satisfaccin.
31
Figura N7. Caractersticas Modelo de Calidad para Calidad Interna y Externa

1.1. Funcionalidad:
Las funciones y propiedades satisfacen las necesidades explcitas

e implcitas; 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 diseado. Para este
propsito se establecen los siguientes atributos:
Adecuacin: 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 precisin.
Interoperabilidad: Capacidad del producto software para
interactuar con uno o ms sistemas especificados.
Seguridad de acceso: Capacidad del producto software para
proteger informacin 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
32
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 ejecucin bajo condiciones normales en un periodo de tiempo
establecido.
Las sub caractersticas que el estndar 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 recuperacin: 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 fcil 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 cmo 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 aplicacin.
33
Capacidad para ser operado: Capacidad del producto

software que permite al usuario operarlo y controlarlo.
Capacidad de atraccin: Capacidad del producto software
para ser atractivo al usuario.
Cumplimiento de la usabilidad: Capacidad del producto
software para adherirse a normas, convenciones, guas de
estilo o regulaciones relacionadas con la usabilidad.
1.4. Mantenibilidad:
Es fcil de modificar y verificar? Se refiere a los atributos que

permiten medir el esfuerzo necesario para realizar modificaciones
al software, ya sea por la correccin 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 modificacin 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 fcil 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:
34
Adaptabilidad: Evala la oportunidad para adaptar el

software a diferentes ambientes sin necesidad de aplicarle
modificaciones.
Facilidad de Instalacin: Es el esfuerzo necesario para instalar
el software en un ambiente determinado.
Conformidad: Permite evaluar si el software se adhiere a
estndares 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
especficos con eficacia, productividad, seguridad y
satisfaccin en contextos de uso especficos.
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.
Utilizacin de recursos: Capacidad del producto software para
usar las cantidades y tipos de recursos adecuados cuando el
software lleva a cabo su funcin 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 especfico y un contexto de
uso especfico. sta mide la extensin para la cual los usuarios
pueden conseguir sus metas en un ambiente particular, en vez de
medir las propiedades del software en s mismo.
35
Para la vista en uso se contemplan 4 caractersticas
VISTA EN USO
Efectividad Productividad Seguridad Satisfaccin
Figura N8. Caractersticas de Vista en Uso
2.1. Efectividad: capacidad del software de facilitar al usuario

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

usuarios gastar la cantidad apropiada de recursos en
relacin a la efectividad obtenida.
2.3. Seguridad: Capacidad del software para cumplir con los
niveles de riesgo emitidos tanto para posibles daos fsicos
como para posibles riesgos de datos.
2.4. Satisfaccin: Capacidad del software de cumplir con las
expectativas de los usuarios en un contexto determinado.
6.9.2.2.1. MTRICAS DE CALIDAD DE PRODUCTO
Las mtricas de calidad de producto se aplican a los diversos atributos

del producto y que permiten determinar posteriormente los niveles
de calidad del producto. Las mtricas que se pueden aplicar de
acuerdo a los atributos estn 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 sealan que las mtricas presentadas
no pretenden ser exhaustivas, ni limita la posibilidad de usar otras
mtricas de acuerdo a las necesidades del usuario.
El anexo A de la norma ISO/IEC 9126-1 seala lo siguiente:
36
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 mayora de las
caractersticas. Por ejemplo, la confiabilidad puede ser medida
externamente observando el nmero de fallas en un perodo de
tiempo de ejecucin dedo durante un ensayo del software e
internamente examinando las especificaciones detalladas y el cdigo
fuente para determinar el nivel de la tolerancia a fallas. Los atributos
internos seran los indicadores de los atributos externos. Un atributo
interno puede influenciar a una o ms caractersticas, y una
caracterstica puede ser influenciada por ms de un atributo. En este
modelo la totalidad de atributos de la calidad del producto software
son clasificados en una estructura arborescente jerrquica de
caractersticas y sub caractersticas. El nivel ms alto de esta
estructura consiste en caractersticas de calidad y el nivel ms bajo
consiste en atributos de calidad de software.
La jerarqua no es perfecta, porque algunos atributos pueden
contribuir a ms de una sub caracterstica1.
A. Mtricas externas: son aquellas que miden el comportamiento

de todo el software o parte de l, a travs 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
operacin y sabemos si cumple con la calidad esperada.
La norma ISO/IEC 9126-1 seala que:
Antes de adquirir o usar un producto software este debera ser

evaluado usando la mtrica basada en los objetivos del negocio
relacionados al uso, explotacin y administracin del producto en
una organizacin y un ambiente tcnico especfico2.
B. Mtricas internas: Las mtricas internas pueden ser aplicadas

durante el diseo y la codificacin del producto software no
ejecutable (por ejemplo cdigo fuente) y proporciona a todos los
involucrados el beneficio de conocer la calidad del producto
durante su construccin 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, pg. 38
37
La norma ISO/IEC 9126-1 seala que:
Las mtricas internas miden atributos internos o indican los

atributos externos a travs del anlisis de las propiedades
estticas de productos intermedio o entregables del producto
software. Las medidas de las mtricas internas usan nmeros o
frecuencias de elementos de composicin de software los cuales
aparecen por ejemplo en las sentencias de cdigo fuente, grficos
de control, flujo de datos y representaciones de estado de
transicin.
6.9.2.2.2. LA CALIDAD EN EL USO:
Si bien el modelo indica que estas sub caractersticas a su vez se

subdividen en atributos, no se especifica cules son esos atributos, ya
que se entiende que estos son entidades dependientes del producto
software y variarn segn vare la naturaleza del software analizado:
lenguaje, paradigma de programacin, complejidad tecnolgica, etc.
a. Mtricas de uso: Mide como un producto cumple con las
necesidades de los usuarios para alcancen sus objetivos. La
evaluacin de la calidad en el uso valida la calidad del producto
software en escenarios especficos de uso. Este estndar
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 Caractersticas de Calidad:
Factores (especificar): Ellos describen la visin externa del
software, como es visto por los usuarios.
Criterios (construir): Ellos describen la visin interna del
software, con es visto por el desarrollador.
Mtricas (controlar): Ellas son definidas y usadas para
proveer una escala y mtodo 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
38
Contextos de Uso
distincin similar es hecha entre la validacin y la

verificacin.
Figura N9. Proceso del Modelos de Calidad ISO/IEC9126
6.9.2.2.3. UTILIDAD DE LAS NORMAS ISO / IEC 9126
Este estndar 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
definicin de requisitos, identificar requisitos de calidad de software,
objetivos de diseo y prueba, criterios de aseguramiento de la
calidad, etc.
La calidad de cualquier proceso del ciclo de vida del software

(estndar 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 estticas o productos intermedios) o atributos externos
(comportamiento del cdigo cuando se ejecuta).
El mundo globalizado exige cada vez ms la aplicacin de estndares

internacionales que garanticen la calidad de los productos. Por esta
razn, es necesario que todo aquel que se dedica al desarrollo de
software incluya en sus procesos, estndares de calidad que permitan
certificarse en alguno de los modelos.
Aqu se ha presentado un estndar, el ISO-9126, el cual establece una

gua para la evaluacin de la calidad del software, sin embargo es
necesario que cada empresa dedicada a producir software trabaje en
39
establecer su modelo de calidad que le permita valorar el nivel de

excelencia de sus productos, en el que debern incluirse
instrumentos de medicin que permitan calificar cuantitativamente
cada una de las caractersticas aqu presentadas. Es importante
mencionar, que dependiendo de los distintos tipos de aplicaciones
las mtricas podrn variar, ya que aunque las caractersticas
expuestas son comunes a la totalidad de los productos, cada software
particular requiere una evaluacin especfica
El estndar 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 aos
para la caracterizacin de la calidad del producto software.
a) ISO / IEC 15504 (SPICE6)

La norma ISO / IEC 15504: Tecnologas de la Informacin -
Software Proceso de Evaluacin es un estndar internacional a
gran marco para la evaluacin de proceso que tiene la intencin
de abordar todos los procesos que intervienen en:
Software de adquisicin
Desarrollo
Operacin
Suministro
Mantenimiento
Apoyo
ISO / IEC 15504 se compone de 9 componentes que cubren los

conceptos, modelo de referencia y mejora de procesos gua,
modelo de evaluacin y guas, las calificaciones de los
evaluadores, y la gua para determinar el proceso de proveedor
capacidad:
Dada la estructura y el contenido de la norma ISO / IEC 15504 es
la documentacin ms estrechamente relacionados con la norma
ISO 9000
6.10. MODELO PARASURAMAN
40
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 funcin
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 ampliacin 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 electrnico 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-caractersticas y atributos propuestos

por la norma ISO/IEC 9126, llegando a identificar 124 atributos de calidad para
los componentes software.
41
6.18. MODELO DE CALIDAD PROPUESTO POR FRANCH AND CARVALLO (2003).
Presenta una adaptacin de la ISO/IEC 9126para servidores de correo electrnico
6.19. MODELO BOTELLA (2003).
Proponen un modelo para la seleccin de ERP y tambin escogen como marco de

trabajo el estndar 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 caracterstica 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. Caractersticas (contenido, presentacin y navegacin)
6.21. MODELO GQM (GOAL QUESTION METRIC).
Enfoque de medicin para evaluar la calidad del software basado en la

identificacin de objetivos a lograr. A continuacin 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 medicin con respecto a caractersticas de calidad seleccionadas
para un punto de vista.
V. Nivel cuantitativo (metric - metrica)
Se asocia un conjunto de mtricas para cada pregunta, de modo de responder a

cada una de ellas de un modo cuantitativo3.
6.22. MODELO CMMI
3
OLSINA, Luis. Ingeniera Web; Marco de medicin y evaluacin de calidad. Departamento de informtica.
Universidad Nacional de San Luis - La Rioja Catamarca. Ao 2007
42
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 estn 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: Gestin de
requisitos Planificacin de proyectos Seguimiento y control de proyectos
Gestin de proveedores Aseguramiento de la calidad Gestin de la
configuracin.
Nivel 3. Definido: Proceso caracterizado por la organizacin y proactivo.
Alcanzar este nivel significa que la forma de desarrollar proyectos (gestin e

ingeniera) est definida, por definida quiere decir que est establecida,
documentada y que existen mtricas (obtencin de datos objetivos) para la
consecucin de objetivos concretos.
Los procesos que hay que implantar para alcanzar este nivel son:
Desarrollo de requisitos
Solucin Tcnica
Integracin del producto
Verificacin
Validacin
43
Desarrollo y mejora de los procesos de la organizacin

Definicin de los procesos de la organizacin
Planificacin de la formacin
Gestin de riesgos
Anlisis y resolucin 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 organizacin. Se usan mtricas para gestionar la organizacin.
Los procesos que hay que implantar para alcanzar este nivel son: Gestin
cuantitativa de proyectos Mejora de los procesos de la organizacin
Nivel 5. En Optimizacin: Enfoque en la mejora del proceso
Los procesos de los proyectos y de la organizacin estn orientados a la

mejora de las actividades. Mejoras incrementales e innovadoras de los
procesos que mediante mtricas son identificadas, evaluadas y puestas en
prctica.
Los procesos que hay que implantar para alcanzar este nivel son: Innovacin
organizacional Anlisis y resolucin de las causas.
44
Figura N10. Niveles del Modelo CMMI
Conclusiones
Para obtener el xito en la produccin de software debemos hacerlo con calidad y

demostrando el grado de sta, calificando como buena. Esto slo es posible con la
implantacin de un Sistema para el Aseguramiento de la Calidad del Software directamente
relacionado con la poltica establecida para su elaboracin y que est en correspondencia
con las definiciones internacionales de calidad, ampliamente aceptada, y por los estndares
que se manejan hoy en da.
Recomendaciones
Finalmente como recomendacin se sugiere la aplicacin de las normativas establecidas a

nivel internacional, mediante la aplicacin de mtodos de calidad al software a desarrollar.
Con ello se logra garantizar la calidad del mismo y que logre cumplir el objetivo esperado.
45
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
46
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
47

Cuáles Son Las Características Del Modelo Virtual CV

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Cuáles Son Las Características Del Modelo Virtual CV

Загружено:

Авторское право:

Доступные форматы

MODELOS DE CALIDAD DE SOFTWARE

Ao de la Integracin Nacional y el Reconocimiento de Nuestra Diversidad

UNIVERSIDAD NACIONAL SAN LUIS GONZAGA DE ICA

CURSO : CONTROL DE CALIDAD DE SOFTWARE

INTEGRANTES : Bautista Quispe Leydi

DOCENTE : Antonio Alonso Morales Loaiza

6.5. Modelo Gilb . (25)

NDICE DE TABLAS Y FIGURAS

Figura N1. Estructura De Modelos De Calidad Software 10

Tabla N1. Beneficios Frente A Coste De Los Factores De Calidad 8

Hoy en da nos encontramos en un mundo cada vez ms globalizado, donde cada da la

Debido a la necesidad de obtener un software de calidad que debe satisfacer los

Modelo Boehm introduce caractersticas de alto nivel, caractersticas de nivel intermedio y

Un modelo es una representacin de un objeto, sistema o idea, de forma diferente al de la

Los modelos de calidad permiten:

a. Definicin estructurada de criterios de evaluacin

3. MODELOS DE CALIDAD DE SOFTWARE

La obtencin de un software con calidad implica la utilizacin 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 ms competitiva.

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

g) Asegurar la satisfaccin 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 cules de los factores de calidad van a ser requisitos de calidad

perodo 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 N1. 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 funcin

F. Por ltimo, se debern establecer los valores mnimos aceptables. La

3.2.2 DURANTE EL DESARROLLO:

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

a) Implementar las mtricas, 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 N1. Estructura De Modelos De Calidad Software

4.1. FACTORES DE CALIDAD:

Se encuentran en el nivel ms alto de la jerarqua, 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 N2. 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 ningn catlogo de factores de partida, y dichos factores deben ser

5.1.3. MODELOS MIXTOS