CUADRO COMPARATIVO NORMAS Y MODELOS PARA EVALUAR LA

CALIDAD EN LOS PROCESOS DE DESARROLLO Y PRODUCTO FINAL

DEL SOFWARE

NURIS CELENA MONTERO SANTIAGO

TUTOR:
PAOLA ANDREA BACCA PACHON

UNIVERSIDAD DE SANTANDER
MAESTRIA GESTION DE LA TECNOLOGIA EDUCATIVA
2015

INTRODUCCION

El software como producto debe poseer atributos o cualidades que midan y lo categoricen con alto
grado de calidad.

Como tal es

necesario que en el desarrollo o ciclo de vida del software se

implementen estrategias o metodologas estndares que permitan detectar problemas desde su diseo,
desarrollo, proceso y uso.

Para obtener un Software de calidad se debe

tomar en cuenta las Normas y Modelos que los

Organismos Nacionales, Regionales E internacionales han formulado para este fin.

En el presente trabajo se elaboraran unos cuadro comparativo donde se pretende mostrar un cuadro
las principales caractersticas, la estructura de cada modelo, sus ventajas y desventajas.

CUADRO COMPARATIVO NORMAS Y MODELOS PARA EVALUAR LA CALIDAD EN LOS PROCESOS DE

Modelo
McCall
Fue
desarrollado
en 1977 por
Jim MacCall

ESTRUCTURA JERARQUICA
Nivel 1
Nivel 2

CARACTERSTICAS

McCall est organizado sobre

tres tipos de caractersticas de
calidad:
Factores (especificar)
Criterios (construir)
Mtricas (controlar)
Este modelo organiza 11 factores
en tres ejes o puntos de vista :
Operacin, Transicin y Revisin.
A travs de ellos el usuario puede
contemplar la calidad de un
producto. Cada factor tiene
asociado sus respectivos criterios
o mtricas.
El modelo refleja perspectivas del
desarrollador y del usuario,
adems presenta una estructura
jerrquica para organizar los
factores.

EJE DE OPERACION

ASPECTO

FACTORES

Facilidad de
uso
Integridad

Correccin

Fiabilidad

Eficiencia

CRITERIOS
Facilidad de
aprendizaje.
Control de accesos.
Facilidad de
auditora.
Seguridad.
Completitud.
Consistencia.
Trazabilidad o
rastreabilidad.
Precisin.
Consistencia
Tolerancia a fallos.
Modularidad.
Eficiencia en
ejecucin.
Eficiencia en
almacenamiento.

Nivel
3

VENTAJAS

DESVENTAJAS

METRICAS

DESARROLLO Y PRODUCTO FINAL DEL SOFWARE

Est orientado al
producto final
pero se puede
aplicar al
proceso.

Los criterios se
calculan
a
travs
de
preguntas
dicotmicas del
tipo SI-NO,
las cuales son
contestadas por
una o varias
personas,
lo
cual
podra
implicar
subjetividad
dado que cada
una
puede
evaluar
la
calidad de forma
diferente.

Este Modelo crea

un puente entre
el desarrollador y
el usuario.
Por su estructura
jerrquica, se
puede observar
que es prctico,
fcil de entender
y fcil de aplicar.

Se focaliza en el producto final,

identificando atributos claves
desde el punto de vista del
usuario

Facilidad de
Mantenimiento

Consistencia
Concisin.

Facilidad de
prueba
Flexibilidad

Cada
Criterio
tiene
varias
mtricas o atributos que en si son
los que permiten
medir la
calidad.

Modularidad
Simplicidad
Auto descripcin
Instrumentacin.
Auto descripcin
Capacidad de

ESTRUCTURA JERARQUICA
Nivel 1
Nivel 2

EJE

para

Su aplicacin
resulta viable
por sus bajos
costos.

Se podra utilizar
no para uno sino
para varios
proyectos.

DESVENTAJAS

En este Modelo
se
evalan
muchos factores
lo que implicara
un
trabajo
adicional
al
proceso
de
desarrollo que
denota tiempo y
costo.

expansin.
Generalidad.
Modularidad

CARACTERSTICAS

Presenta un nivel ms

Simplicidad

VENTAJAS

Auto descripcin.

Utiliza criterios de calidad en los

relaciona atributos internos y
externos.

ASPECTO

CRITERIOS
Modularidad

METRICAS

Satisface las necesidades tanto

de los desarrolladores como las
del usuario.

FACTORES

Nivel
3

FACTORES
Facilidad de

CRITERIOS
Auto descripcin

Nivel
3

METR

Modelo
McCall
Fue
desarrollado
en 1977 por
Jim MacCall

ESTRUCTURA JERARQUICA
Nivel 1
Nivel 2

CARACTERSTICAS

EJE DE REVISION

ASPECTO

VENTAJAS

DESVENTAJAS

Es difcil que las

descomponer y mapear cada

criterio de calidad en un conjunto
de mtricas de calidad que son
atributos

(tanto

del

producto

reutilizacin

Modularidad

la medicin de cualquiera de

Hardware.
Modularidad
Compatibilidad de

Interoperabilidad

datos.

mtricas para cada criterio existe

Estandarizacin en

deben

cumplir

etapas:

en

distintas

requerimientos

Portabilidad

(R),

implementacin (I).

Modelo

los datos.
Auto descripcin
Modularidad
Independencia entre
Sistema y Software
Independencia del

diseo (D),

ASPECTO

Implicara
un
trabajo tedioso
por la cantidad
de mtricas que
se utilizaran.

comunicaciones.
Compatibilidad de

este modelo en base a 41

DESVENTAJAS

caractersticas y
subcaractersticas
sean
siempre
perfectamente
independientes

Sistema y Software.
Independencia del

estos factores est definida en

una lista de condiciones que se

VENTAJAS

Independencia entre

como del proceso) de muy bajo

nivel, medibles directamente.

Generalidad

Nivel
3

ICAS

Modelo
McCall
Fue
desarrollado
en 1977 por
Jim MacCall

ESTRUCTURA JERARQUICA
Nivel 1
Nivel 2

CARACTERSTICAS

DE REVISION

ASPECTO

Hardware.

ESTRUCTURA DEL MODELO

CARACTERSTICAS

ALTO NIVEL
O USOS PRIMARIOS

Se
conoce
como
modelo espiral. Presenta
una
jerarqua
de

Utilidad Per-se

NIVEL O
CONSTRUCTORE
S INTERMEDIO

Confiabilidad

NIVEL BAJO O
CONSTRUCT.
PRIMITIVOS

Autocontencin
Exactitud
Completitud
Consistencia

VENTAJAS

DESVENTAJAS

Considera
explcitamente
los riesgos.

Requiere de una
considerable
habilidad
y
experiencia para

creado por
Barry Boehm
en 1978.

CARACTERSTICAS

caractersticas
que
sirven para medir la
calidad del producto
software:
Caractersticas de alto
nivel:
representan
requisitos generales de
uso o usos primarios.
Caractersticas de nivel
intermedio: representan
los factores de calidad
de
Bohem.
Caractersticas
primitivas: nivel ms bajo
que
corresponde
a
caractersticas Directamente asociadas a uno o
ms mtricas de calidad.

Cun usable,
confiable y
eficiente es el
producto en si
mismo.

Tiene similitudes con el

modelo McCall, porque
muchos de sus factores
de calidad son los
mismos.

ASPECTO

CARACTERSTICAS

NIVEL O
CONSTRUCTORE
S INTERMEDIO

Eficiencia

Usabilidad

NIVEL BAJO O
CONSTRUCT.
PRIMITIVOS

Integridad
Accesibilidad
Eficiencia de uso
de dispositivos
Integridad
Accesibilidad
Comunicacin
Comunicacin

Mantenibilidad
Cuan fcil es
modificarlo,
entenderlo y
retestearlo.

Testeabilidad
Flexibilidad
Portabilidad

Utilidad general
Si puede seguirse
usando si se
cambia de
ambiente

Facilidad de
entendimiento

Autodescripcin
Estructuracin
Estructuracin
Aumentabilidad
Independencia de
los dispositivos
Autocontencin

VENTAJAS
CRITERIOS O METRICAS
CRITERIOS O METRICAS

Boehm

ESTRUCTURA DEL MODELO

ALTO NIVEL
O USOS PRIMARIOS

Consistencia
Estructuracin
Concisidad
Legibilidad

ESTRUCTURA DEL MODELO

TIPOS DE REQUERIMIENTOS

ATRIBUTOS O
REQUISITOS

Al gestionar los
riesgos, se
reducen los
problemas en el
proyecto y el
costo del mismo.
Permite
especificar
alternativas para
lograr los
objetivos.
Es adaptable a
desarrollo de
todo tipo.
Permite una
mezcla con las
metodologas de
prototipos,
cascada e
incremental.

VENTAJAS
CRI

ASPECTO

DESVENTAJAS

la evaluacin de
riesgos.

Si
no
se
detectan
los
riesgos a tiempo
surgirn
dificultades.
Debido a su
complejidad no
es aconsejable
su
uso
en
sistemas
pequeos.
Limita
la
reusabilidad.

DESVENTAJAS

Funcionalidad

Seguridad

Usabilidad

Confiabilidad

Factores
humanos
Estticos
Consistencia de
la Interfaz
Ayuda en lnea
Asistentes
Documentacin
del usuario
Frecuencia y
severidad de
fallas.
Recuperacin a
fallos
Exactitud de las
salidas

TERIOS O METRICAS

Incluye
cinco
(5)
categoras
principales
las cuales se derivan de
su nombres en ingls:
-Funcionalidad
(Functionality),
-Usabilidad
(Usability),
-Confiabilidad
(Reliability),
-Desempeo
(Performance)
-Soportabilidad
(Supportability).

FUNCIONALES

Este Modelo desarroll

una serie de factores de
calidad que reciben el
acrnimo de FURPS.

NO FUNCIONALES

Modelo
FURPS
creado por
HewlettPackard,
1987.

Se puede utilizar
en varios
proyectos.

Caractersticas y
capacidades del
Programa
Generalidades de
las funciones

Tiene en cuenta
las fallas en el
producto y en el
proceso, este
control permite
correcciones.

Se requieren de
Muchas
mtricas para la
evaluacin del
producto.

No tiene
cuenta
portabilidad
los productos
Software.

en
la
de
de

Tiempo entre fallos.

Capacidad de
Prediccin.
Velocidad
Eficacia
P

Desempeo

Consumo de
recurso
Tiempo de
respuesta

Rendimiento
efectivo total.

CARACTERSTICAS

ESTRUCTURA DEL MODELO

TIPOS DE REQUERIMIENTOS

ATRIBUTOS O
REQUISITOS

VENTAJAS
CRITE

ASPECTO

DESVENTAJAS

enfoque

Desempeo

Requisito de Instalacin

Soporte

Implementacin

-Requerimientos Funcionales (F)

-Requerimientos No
Funcionales (URPS).

Interfaz
+

Operaciones
Empaquetamiento
Legales

Requisito de
Compatibilidad.
Limitacion de recurso
Lenguajes
Herramientas, Hardware.
Restricciones para
interaccin con sistemas
externos.

Se utiliza para
establecer
mtricas de la
calidad para
todas las
actividades del
proceso de
desarrollo de un
software,
inclusive de un
sistema de
informacin.

Se establecen
restricciones en
el diseo y los
requerimientos
de
implementacin,
fsicos y de
interfaz

Gestin del Sistema

Pautas administrativas
Puesta en Marcha
Forma de distribucin
Licencias
Derecho de autor

ESTRUCTURA DEL MODELO

CARACTERSTICAS

FACTORES

CRITERIOS

Correccin

Completitud

METRIC

ASPECTO

Requisito de
Configuracin.
Requisito de
Adaptabilidad

Plantea dos categoras

de requerimientos:

A cada uno de ellos

Utilizacin de Recursos

RIOS O METRICAS

Tiene
un
industrial.

NO FUNCIONALES

Modelo
FURPS
Creado por
HewlettPackard,
1987.

El
modelo
FURPS
incluye, adems de los
factores de calidad y los
atributos, restricciones
de
diseo
y
requerimientos
de
implementacin, fsicos
y de interfaz. .

VENTAJAS

DESVENTAJAS

Modelo
ARTHUR
Creado por
Arthur
Andersen,
1985.

Consistencia
Seguimiento

Fiabilidad
Arthur,
para
diferenciarlo del McCall,
aade
tres nuevos
criterios de valoracin:
Complejidad, Seguridad,
Auditabilidad

AS

Este Modelo de calidad

creado
por
Arthur
Andersen, presenta una
variante del modelo de
calidad propuesto por
McCall.

Complejidad
Consistencia
Modularidad
Preciso
simplicidad
Tolerante a errores
Concisin

Eficiencia

Posee un Valor
agregado ya
que incorpora
un factor de
calidad que
muchos
modelos no
presentan:
Correccin.

Eficiencia de Ejecucin
Operatividad

Integridad
Utilizable

Mantenible

Flexible

Auditabilidad
Instrumentacin
Seguridad
Entretenimiento
Operatividad
Auto-documentado
Concisin
Consistencia
Instrumentacin
Modularidad
Simplicidad
Auto-documentado
Complejidad
Concisin
Consistencia
ESTRUCTURA DEL MODELO

CARACTERSTICAS

FACTORES

CRITERIOS

Verificable

Auditabilidad
Auto-documentado

METRICAS

ASPECTO

Presenta
demasiados
criterios por lo
cual se deber
utilizar una gran
cantidad
de
mtricas
para
verificar
la
calidad
del
producto
o
proceso
de
Software.

VENTAJAS

DESVENTAJAS

Modelo
ARTHUR
Creado por
Arthur
Andersen,
1985.

Este Modelo introduce

una variacin entre
las relaciones de los
factores y los criterios.

El Criterio de
Auditabilidad,
genera un alto
grado
de
confiabilidad
ante
posibles
riesgos.

Complejidad
Instrumentacin
Modularidad

Presenta como factor

de calidad la Correccin
y criterios que denotan
un seguimiento que
conlleva a procesos de
calidad.

Simplicidad

Debido al uso
de
muchas
mtricas
para
medir la calidad,
se requiere de
mucho esfuerzo
y un alto costo
econmico.

Auto-documentado
Generalidad
Independencia de la mquina
Portable

Independencia del sistema

software
Modularidad

Inter-operable

ASPECTO

ESTRUCTURA DEL MODELO

CARACTERISTICAS
CARACTERSTICAS

INTERNAS Y
EXTERNAS

Es un estndar internacional para

CRITERIOS

Adecuacin.

METRICAS

Reutilizable

Auto-documentado
Generalidad
Independencia del hardware
Independencia del sistema
software
Modularidad
Comunicaciones comunes
Datos comunes
Generalidad
Modularidad

VENTAJAS

DESVENTAJAS

Primer versin
1992
Es reemplazado
en el 2001 por
ISO 9126:1.
Es Actualizada
en el 2005 con
una nueva
versin
ISO/IEC 25000

la evaluacin del Software, est

supervisado por el proyecto
SQuaRE, ISO 25000:2005, el
cual sigue los mismos conceptos.
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 atributo.

Confiabilidad

Facilidad de uso.

Se divide en:

Eficiencia.

ISO 9126-2 Mtricas externas

(Mide el software en s mismo)

Facilidad de
mantenimiento.

ISO 9126-4 Calidad en el uso de

mtricas (mide el efecto de
usar el software en un contexto
especfico).
CARACTERSTICAS

Portabilidad

Es un Modelo
que puede ser
usado en
cualquier parte
porque es de
mbito
internacional.

Tolerante a defectos.
Facilidad de
recuperacin.
Fcil de comprender.
Fcil de aprender.
Fcil de operar.
Atractividad.

Al ser norma
de aplicacin
internacional
siempre est
actualizada.

Comportamiento en el
tiempo.
Comportamiento de
recursos.

ISO 9126-1 Modelo de calidad

(ISO/IEC, 2001).

ISO 9126-3 Mtricas de internas

(mide
el comportamiento
del
sistema)

ASPECTO

Exactitud.
Interoperabilidad.
Seguridad.
Cumplimiento de
normas.
Madurez.

Funcionalidad.

Es aplicada al
producto y al
proceso.

Fcil de comprender.
Fcil de aprender.
Fcil de operar.
Atractividad. .
Facilidad de
instalacin.
Facilidad de
reemplazo.

Presenta una
superposicin
de conceptos, al
definir
usabilidad
(Facilidad de
uso) como una
caracterstica de
calidad interna
externa, y llamar
calidad en uso a
otras
caractersticas
tambin
vinculadas a la
usabilidad.

Adaptabilidad

ESTRUCTURA DEL MODELO

CARACTERISTICAS CALIDAD DE USO
FACTORES

DESCRIPCION

VENTAJAS
MET

Estndar
ISO 9126

DESVENTAJAS

Primer versin
1992
Es reemplazado
en el 2001 por
ISO 9126:1.
Es Actualizada
en el 2005 con
una nueva
versin
ISO/IEC 25000.

Eficiencia

Productividad

Seguridad

Satisfaccin

Capacidad de ayudar al
usuario a cumplir sus
objetivos con exactitud y
completitud en un contexto
de uso dado.
Capacidad de ayudar al
usuario a emplear una
cantidad apropiada de
recursos para obtener sus
resultados
Capacidad de alcanzar
niveles aceptables de
riesgo para las personas, el
ambiente de trabajo y la
actividad, en un contexto de
uso dado
Capacidad de satisfacer a
un usuario en un contexto
de uso dado

RICAS

Estndar
ISO 9126

La mantenibilidad es una de las

caractersticas ms importantes
de la calidad de un producto
software, quiz sea la parte ms
famosa de la norma ISO 9126 /
ISO
25000.
Atributo
intrnsecamente asociado con el
proceso de mantenimiento, y que
representa la mayor parte de los
costes en el Ciclo de Vida
Software.

Este Estndar
implementa la
calidad en el
uso, por lo cual
se obtiene
informacin de
parte del
usuario que
facilita generar
procesos de
mejoramientos
en la calidad
del software.

Posee muchas
mtricas por lo
cual,
requiere
tiempo, trabajo y
costos.

CONCLUSIONES

Toda organizacin automatiza tareas a travs de la implementacin de Sistemas de Informacin, por esta
razn adquirir un software es un requisito fundamental para el desarrollo organizacional. Teniendo en
cuenta este fundamento administrativo se debe preveer obtener un producto de software que cumpla con
las condiciones de calidad.

Para poder evaluar la calidad del software debe tener en cuenta que existen una variedad de Modelos y
Estndares que permiten medir la calidad a travs de atributos que son evidenciados a travs no solo de
su uso sino a travs de los resultados que se obtienen a travs del procesamiento de la informacin. Por
eso debe determinar qu Modelo o Estndar utilizar segn los objetivos que se pretendan alcanzar.

Lo ms recomendable analizar y comparar cada uno de los modelos y estndares, para poder efectuar
una correcta eleccin del Modelo y/o Estndar de Calidad del Software

a aplicar, determinar que

beneficios ofrece a nivel proceso, a nivel de resultado. Slo as se puede desarrollar una evaluacin
eficiente que permita

de la futura implantacin

humanos, materiales, tiempos y costos.

teniendo en cuenta un contexto integral: recursos

BIBLIOGRAFIA

Calidad del Software: camino hacia una verdadera industria del software. Revista de la Escuela
Administracin de Negocios, 38, 38-57. Rojas, S., & Borja, J. (1999). Recuperado el 10 de Febrero
de

2015,

de:

http://aulavirtual.eaie.cvudes.edu.co/publico/lems/L.000.008.MG/Documentos/Anexos/Cap1/1.pdf

El Modelo de Capacidad de Madurez y su Aplicacin en Empresas Mexicana de Software. Puebla: Universidad de las
Amricas Puebla. p (10-18, 68-75). Garca Romero, C. (2001). Recuperado el 12 de Febrero de 2015 de;

http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/garcia_r_ci/capitulo_2.html.

Introduccin a la Calidad del Software. Scientia et Technica(39), 326-331.ISSN 0122-1701. Lpez, A.,
Cabrera, C., & Valencia, L. (2008). Recuperado el 15 de febrero de 2012, de
http://aulavirtual.eaie.cvudes.edu.co/publico/lems/L.000.008.MG/Documentos/Anexos/Cap1/2.pdf

Medinatic. (14 de 02 de 2013). http://medinatic.scoom.com. Recuperado el 11 de Febrero de 2015, de

http://medinatic.scoom.com/2013/02/14/cuadro-comparativo-sobre-normas-y-estandares-decalidad/

Piedrahita Mesa, Sebastin. Construccin de una herramienta para evaluar la calidad de un producto
software. Recuperado el 18 de febrero de 2.015 de:
https://repository.eafit.edu.co/handle/10784/2431.