100
2, APRIL 2006
Determinacin de los Requerimientos de
Calidad del Producto Software Basados en
Normas Internacionales
Abraham Dvila (edavila@pucp.edu.pe), Karin Melendez (melendez.ka@pucp.edu.pe) y Luis Flores
(flores.la@pucp.edu.pe), Seccin Ingeniera Informtica, Pontificia Universidad Catlica del Per,
Lima, Per
 En el ao 1994 se inicia la revisin de la norma internacional
Resumen-- La calidad del producto software es una
preocupacin cada vez mayor en el mbito informtico y cuyos
resultados inmediatos se aprecian en todas las actividades en
donde se utilicen computadoras. La serie de normas ISO/IEC
9126 establece un modelo de calidad de producto y a manera de
ejemplo, en el anexo, muestra la identificacin de los
requerimientos de calidad como un paso necesario para la
calidad de producto. Sin embargo, no establece el modo en que
se ha de determinar los requerimientos de calidad (interna,
externa, o en uso) relevantes para el producto a construirse y
tampoco establece como determinar los niveles esperados en las
mtricas a usarse. Determinar los requerimientos de calidad y los
niveles de mtricas, aparentan ser actividades sencillas, pero
podran resultar ser engorrosas y propensas a errores si no se
tiene establecido un esquema sistemtico para su determinacin.
Este artculo presenta una propuesta para la determinacin de
los requerimientos de calidad del producto basado en el estndar
ISO/IEC 9126.
Palabras ClavesCalidad de Software, Requerimientos de
Calidad de Producto Software, ISO/IEC 9126.
I. INTRODUCCIN
L a calidad es un tema complejo como lo seala
Kitchenham y Pfleeger [17] y existen diversas formas de
abordarlo. Un enfoque interesante y muy influyente,
presentado por Garvn, es la visin de la calidad desde cinco
perspectivas: (i) la visin trascendental que puede ser
reconocida pero no definida, (ii) la visin del usuario como la
adecuacin al propsito del usuario, (iii) la visin del
productor como conformidad con la especificacin, (iv) la
visin del producto, basada en las caractersticas observables
del producto, y (v) la visin basada en el valor que el cliente
est dispuesto a pagar [8].
La calidad del producto se ha venido tratando desde hace
varios aos, siendo los primeros modelos desarrollados por
McCall [18] y Boehm [4]. Lamentablemente, para cada
proyecto se adoptaba modelos de calidad diferentes, haciendo
difcil la comparacin. Con la publicacin de la primera
edicin de la estndar internacional ISO/IEC 9126 en 1991 se
puede aspirar a tener un modelo base que puede ser utilizado
como referencia para todos los trabajos que se realicen [12].
IEEE LATIN AMERICA TRANSACTIONS, VOL. 4, NO.
y se publican entre 1998 y el 2004 la serie de normas ISO/IEC
9126 (4 partes) referida al modelo de calidad de producto que
incluye las mtricas y la serie de normas ISO/IEC 14598 (6
partes) referida a la evaluacin de la calidad del producto [13]
[16].
El modelo ISO/IEC 9126 presenta el concepto de calidad
del producto descompuesto en la calidad interna, externa y en
uso [13]. En la figura 1 se puede apreciar que las necesidades
de calidad del usuario sobre el producto software, contribuyen
a especificar (definir) los requerimientos de calidad externa y
estos a su vez los requerimientos de calidad interna. El
cumplimiento de los requerimientos de calidad interna,
externa y en uso se deben de comprobar en un proceso que
permita evaluar la calidad a travs de las mtricas. Este
enfoque de tres niveles cubre las perspectivas del usuario,
desarrollador y el producto mismo.
Fig. 1. Calidad en el ciclo de vida del software. Tomado de ISO/IEC 9126
Necesidades de
calidad del Calidad en uso
usuario
uso y
contribuye a
especificar
Requerimientos
retroalimentacin
indica
de calidad Calidad externa
externa
validacin
contribuye a indica
especificar
Requerimientos
de calidad Calidad interna
interna
verificacin
[13]
La traduccin de los requisitos de calidad a nivel del
usuario hacia la calidad externa e interna representan un
problema que el desarrollador debe resolver en cada proyecto.
Lamentablemente la especificacin de requisitos de calidad
externa e interna puede contener diversos errores si no se
cuenta con herramientas adecuadas para dicha actividad. Se
sabe que la educcin de requisitos de software es una
actividad complicada y describir la calidad tambin es
DVILA et al.: ESTABLISHING SOFTWARE PRODUCT 101

complicada, entonces se puede inferir que definir los deseables depende directamente de cada atributo del producto.
requisitos de calidad interna y externa considerando el punto El diseo de la evaluacin (paso 3) comprende la preparacin
de vista del usuario, ser una actividad de la misma de un plan de medicin conteniendo los entregables sobre los
naturaleza. cuales se har el proceso de medicin y las mtricas que se
La traduccin de la necesidad de calidad del usuario a aplicarn.
requerimientos de calidad (externa e interna) podra derivarse
estableciendo algunas reglas o modelos como se presenta en TABLE I
RECLAMO [6], utilizando un criterio de comparacin relativa Funcionalidad Aplicabilidad A
cada dos caractersticas [5], siguiendo los pasos descritos en el
Precisin A
estndar de IEEE [10] u obtenerse directamente de los
Interoperatibilidad B
involucrados utilizando cuestionarios adecuados como se hace
en QAW (Quality Attribute Workshop) [2] o usando los
Seguridad B
principios de GQM (Goal/Question/Metrics) [22]. La tcnica Conformidad de funcionalidad M
desarrollada se basa en la filosofa de los trabajos de QAW y
CALIDAD DEFINIDA PARA LAS SUB-CARACTERSTICAS: FUNCIONALIDAD [13]
GQM, adaptndolos para la determinacin de requisitos de
calidad considerando el punto de vista del usuario. III. VISIN GENERAL
En las prximas secciones se presentar los pasos para la
calidad del producto segn la norma internacional, la DReC se propone como una tcnica para la determinacin
descripcin de la tcnica propuesta, los pasos para su de los requerimientos de calidad de un producto software
aplicacin, documentos de trabajo que utiliza, una aplicacin basada principalmente en el punto de vista de usuarios y el
de la tcnica y las conclusiones y trabajos futuros en esta punto de vista de desarrolladores de una manera
lnea. complementaria. La definicin implica que: (i) la
determinacin de requerimientos de calidad es un proceso de
II. PASOS PARA LA CALIDAD DE PRODUCTO SEGN LA NORMA fijacin de valores (niveles de calidad y estimacin de
ISO/IEC 9126 mtricas) que sern tomados inicialmente para la planificacin
de la calidad y posteriormente como referencia para la
La norma ISO/IEC 9126-1:2001 presenta -en el anexo- los
evaluacin del producto software; (ii) el usuario es un actor
pasos del enfoque de calidad de producto como un ejemplo
importante en la determinacin de los requerimientos de
orientado a la evaluacin de la calidad [13]. Los pasos
calidad y su punto de vista debe ser sistemticamente
descritos son: (i) identificacin de requerimientos de calidad;
obtenido; (iii) el desarrollador es un actor que contrapesar la
(ii) especificacin de la evaluacin, (iii) diseo de la
opinin del usuario, pero debe subordinar finalmente- su
evaluacin, (iv) ejecucin de la evaluacin, y (v)
opinin a la del usuario si no existe un consenso sobre los
retroalimentacin a la organizacin. El primer paso debe
valores; (iv) DReC se orienta principalmente a usuarios
realizarse durante el Anlisis de los Requerimientos y el resto
finales, por lo que la manera de relacionarse a l, ser en
de pasos durante cada actividad del proceso de desarrollo. Los
trminos lo menos tcnico posible pero con la claridad
tres primeros pasos son descritos con detalle en la norma, el
necesaria para determinar adecuadamente los valores; y (v)
cuarto hace una referencia a la serie de normas ISO/IEC
DReC se basa en la serie de normas ISO/IEC 9126, ISO/IEC
14598 y el quinto presenta una comentario sencillo y directo
14598 y recomendaciones del Cuerpo de Conocimiento de la
sobre como realizar la evaluacin.
Administracin de Proyectos (PMBOK) [20] del Project
La identificacin de requerimientos de calidad (paso 1)
Management Institute [21].
permite determinar los pesos a ser utilizados en el modelo de
La herramienta debe ajustarse al contexto de la
calidad y que debe reflejar las necesidades de calidad del
organizacin que utilizar el producto y al de la organizacin
usuario para cada una de las caractersticas y sub
desarrolladora. Con la organizacin usuaria, por que pueden
caractersticas. Los pesos representan la valoracin
tener datos sobre los niveles de calidad de los productos que
comparada entre las distintas caractersticas y sub
utilizan y pueden ser tomadas como referencia para los nuevos
caractersticas y para ello se puede utilizar una calificacin
productos que requieran. Con la organizacin desarrolladora,
relativa de alto / medio / bajo o una calificacin basada en
por que pueden tener datos sobre los niveles de calidad
valores que puede ir entre 1 y 9. En la tabla 1 se presenta, a
obtenidos en proyectos anteriores, que pueden respaldar el
manera de ejemplo, un extracto de la definicin de la calidad
nivel esperado de calidad en el nuevo proyecto. Sin embargo
externa e interna del producto a nivel de sub-caracterstica
la tcnica puede aplicarse tambin en las organizaciones
para la caracterstica de la funcionalidad, segn la norma
usuarias y desarrolladoras que no cuentan con estos datos
ISO/IEC 9126.
histricos; ya que no es una prctica extendida.
La especificacin de la evaluacin (paso 2) permite
DReC se utiliza en las primeras etapas de un proyecto de
identificar los valores deseables de las mtricas a utilizar
desarrollo de software (Anlisis de los Requerimientos
posteriormente en el desarrollo y en la evaluacin del
Participan en su determinacin los usuarios y los
producto. Estos valores deben orientarse principalmente a
desarrolladores (responsables del proyecto).
cubrir las necesidades del usuario. La definicin de valores
102 IEEE LATIN AMERICA TRANSACTIONS, VOL. 4, NO. 2, APRIL 2006

PASO 2 PASO 3
PASO 1
Completar la hoja inicial Completar la hoja
Descomponer el producto (Drec00) (Drec0x)
de
s oftware en com ponentes Subcaractersticas Atributos de Calidad

Consolidar Consolidar
Seleccionar componentes Informacin Informacin
Relevantes

Revisar Resultados Revisar Resultados

Repetir
para
1<=x<=3

Fig. 2. Diagrama de actividades de DReC

DReC tiene como objetivo determinar: (i) las
caractersticas de calidad interna y externa que son relevantes
en la desarrollo de software; (ii) los niveles de calidad de cada
caracterstica y sub-caracterstica; y (iii) los niveles de calidad
de los atributos (valores deseables de las mtricas) del
producto a desarrollar. Estos objetivos primarios de DReC
coinciden con los tres primeros pasos establecidos por la
ISO/IEC 9126 descrito en la seccin anterior.
Para la primera aproximacin de DReC se ha considerado
las mtricas de los atributos establecidos para las sub-
caractersticas internas y externas del modelo de calidad del
producto software, de la serie ISO/IEC 9126. Los
cuestionarios de DReC se han elaborado a partir de las
definiciones propias de la norma de caractersticas, sub-
caractersticas y mtricas.
IV. DESCRIPCIN DE DREC
La tcnica se compone de 3 pasos tal como se puede
apreciar en la figura 2 y que se describe a continuacin.
Paso 1: Seleccionar componentes; el objetivo de este paso
es seleccionar un conjunto de componentes a los cuales se les
aplicar el resto de la tcnica. La razn es que un producto
software tiene diversos componentes cuyas necesidades de
calidad son diferentes, dependiendo de la funcin que realizan
dentro del producto final. Un claro ejemplo se da en los
sistemas de informacin en donde existen componentes de
explotacin de informacin (como reportes) cuyo nivel de
calidad requerido es diferente a los de registro y
procesamiento de datos.
La seleccin de un sub conjunto de componentes sobre el
que se aplique una tcnica es una prctica que tambin se ha
usado en otras propuestas, un ejemplo concreto es Squid [3].
El resultado del paso es una lista de componentes
seleccionados, donde cada componente puede ser distinguible
por usuarios y desarrolladores; este paso puede ser omitido si
la organizacin desarrolladora tiene la lista de componentes
por alguna actividad previa a la aplicacin de DReC. Los sub-
pasos que componen este paso son:
Paso 1a. Descomponer el producto software en
componentes, se puede utilizar una estructura de
descomposicin del trabajo orientada al producto tambin
conocido como WBS (del ingls Work Breakdown Structure)
que es una prctica recomendada por PMI [19].
Opcionalmente se puede utilizar otra tcnica para
identificacin de componentes.
Paso 1b. Seleccionar los componentes relevantes, es decir,
aquellos que son considerados los ms importantes y/o crticos
para la solucin (sistema software) que se va a desarrollar.
Puede utilizar cualquier tcnica para seleccin basada en
grupo de personas; como por ejemplo la Tcnica de Grupo
Nominal [1].
Paso 2: Definir los pesos del modelo de calidad
(caractersticas y sub-caracteristicas), el objetivo de este paso
es la determinacin de los valores a ser usados en el modelo
obtenidos sistemticamente mediante un cuestionario que se
aplicar a cada componente seleccionado en el paso 1. La
razn es que el modelo de calidad es una representacin
abstracta de un conjunto de caractersticas y sub
caractersticas del producto software; sin embargo, el nivel de
importancia de las caractersticas y sub caractersticas varan
entre uno u otro proyecto y su contexto. Un software para
nios tiene caractersticas de calidad muy dismiles con un
software para una sala de urgencias, que uno para un sistema
de informacin empresarial. Cada participante contestar el
cuestionario de modo que plasme su percepcin sobre la
importancia comparada- de las caractersticas y sub
caractersticas. Los participantes son usuarios y
desarrolladores; y el cuestionario est redactado de manera
que sea fcil de comprender (principalmente para los
usuarios); pero cuyas respuestas permitan internamente ayudar
en la determinacin de los pesos a emplearse en el modelo de
calidad. La hoja de cuestionario se ha elaborado a partir de
las definiciones proporcionadas en la norma ISO/IEC 9126-
1:2001 [13] y se compone de 33 preguntas. El resultado de
DVILA et al.: ESTABLISHING SOFTWARE PRODUCT
este paso es un modelo de calidad con los pesos definidos a
nivel de caractersticas y sub-caractersticas. Los sub pasos
que componen este paso son:
Paso 2a. Completar la hoja inicial (DReC00) marcando con
una "x" de acuerdo a cada lnea que describe una caracterstica
o sub caracterstica. La hoja es completada por todas las
personas convocadas: usuarios y desarrolladores.
Paso 2b. Consolidar la informacin de todos los
participantes, de preferencia de manera automtica usando
hojas de clculo o un producto software ad-hoc para esta
actividad de modo que sea rpido y con resultados confiables.
Paso 2c. Revisar los resultados obtenidos y discutir sobre
las respuestas cuya variacin sea significativa hasta encontrar
un consenso entre todos los participantes de la sesin, la
participacin ser mediante un director de debate. Se podr
utilizar adicionalmente las hojas DReC11 y DReC12
siempre que se cuente con datos histricos.
Paso 3: Definir los niveles de calidad esperado en los
atributos del producto, el objetivo de este paso es la
determinacin de los valores a ser usados como nivel de
referencia para las mtricas en la evaluacin, obtenidos
sistemticamente mediante la aplicacin de un conjunto de
cuestionarios que se aplicarn a cada componente
seleccionado en el paso 1. La razn es que la calidad de un
producto es finalmente evaluada por el usuario cada vez que
utiliza el software (calidad en uso), esta calidad -en uso-
depende de la calidad externa y sta a su vez de la calidad
interna del componente [13]. Por ello, definir los niveles de
calidad deseada para las caractersticas internas y externas, es
una necesidad del equipo de desarrollo para que puedan
definir las actividades de control de calidad para el proyecto.
La determinacin debe ser el resultado de una negociacin
(consenso / acuerdo) entre los usuarios y los desarrolladores,
que apoyados en DReC pueden reducir la discusin sobre
aquellos aspectos en que hay una diferencia de opinin sobre
el nivel de calidad requerido. Igual que en el paso anterior,
los participantes son usuarios y desarrolladores, y los
cuestionarios estn orientado a los usuarios. El cuestionario
se ha elaborado a partir de las definiciones proporcionadas en
las normas ISO/IEC 9126-2:2003 [14] e ISO/IEC 9126-
2:2003 [15] y se compone de 6 cuestionarios con 25 preguntas
en promedio cada uno. El resultado de este paso es un hoja
con los niveles de calidad en cada atributo del producto. Los
sub pasos que componen este paso son:
Paso 3a. Completar la hoja DReC01 y DReC02
marcando con una "x" de acuerdo a cada lnea que describe un
atributo. La hoja es completada por todas las personas
convocadas: usuarios y desarrolladores
Paso 3b. Consolidar la informacin de todos los
participantes, de preferencia de manera automtica usando
hojas de clculo o un producto software ad-hoc para esta
actividad de modo que sea rpido y con resultados confiables.
Paso 3c. Revisar los resultados obtenidos y discutir sobre
las respuestas cuya variacin sea significativa hasta encontrar
un consenso entre todos los participantes de la sesin, la
participacin ser mediante un director de debate. Se
103
utilizarn adicionalmente las hojas DReC21 y DReC22.
Paso 3d. Repetir los sub-pasos anteriores para los pares de
hojas DReC03- DReC04 y DReC05- DReC06.
V. DOCUMENTOS DE TRABAJO DE LA TCNICA
La tcnica descrita en la seccin anterior, se basa en un
conjunto de documentos: cuestionarios, los cuales se han
derivado principalmente de la serie de normas ISO/IEC 9126;
y plantillas de resultados anteriores, los cuales se han diseado
para almacenar los requerimientos de calidad de un proyecto
determinado (planificado), tanto para la organizacin usuario
como desarrolladora, y para almacenar los niveles de calidad
logrados (reales) en dicho proyecto. Los documentos
(cuestionarios) utilizados en DReC se encuentran enumerados
a continuacin:
DReC00, para la determinacin de pesos de las
caractersticas y sub caractersticas, derivado de la
ISO/IEC 9126-1:2001[13].
DReC01..06, para la determinacin de niveles de calidad
interna y externa en cada atributo de la caracterstica de
funcionalidad, fiabilidad, eficiencia, usabilidad, facilidad
de mantenimiento y portabilidad.
DReC11, tabla de valores de pesos de calidad
planificados por proyecto y organizacin.
DReC12, tabla de valores de pesos de calidad reales por
proyecto y organizacin.
DReC21, tabla de valores de mtricas de atributos del
producto planificados por proyecto y organizacin.
DReC22, tabla de valores de mtricas de atributos del
producto reales por proyecto y organizacin.
VI. APLICACIN DE LA TCNICA
DReC se debe aplicar en dos etapas principales: una que
cubra el paso 1 y otra que cubra los pasos 2 y 3 en conjunto.
Para el paso 1, el equipo de desarrollo es el encargado de
hacer la descomposicin y la seleccin de componentes
tomando en cuenta las necesidades del usuario, el producto
mismo y los objetivos de la organizacin usuaria; esta etapa se
puede realizar en una sola sesin.
Para el paso 2 y 3 se convoca a un conjunto de personas
entre usuarios y desarrolladores de modo que realicen las
actividades indicadas para cada componente. Se debe tener en
cuenta que para cada componente podra definirse un equipo
diferente de personas quienes completen las actividades; ello
depender del componente en si mismo.
Si el nmero de componentes es muy alto, quizs sea
conveniente establecer un conjunto de sesiones para cubrir
todos los componentes, se sugiere que la evaluacin de un
componente se realice totalmente dentro de una sola sesin;
dividir la evaluacin de un componente en dos sesiones
diferentes podra introducir ruido debido a las conversaciones
fuera de sesin de los participantes.
104 IEEE LATIN AMERICA TRANSACTIONS, VOL. 4, NO. 2, APRIL 2006

TABLE II
CALIDAD MODELO DE CALIDAD DEFINIDO PARA VICU-DB

Calidad Externa e
Interna
Caracterstica Peso % Subcaracterstica Peso %
Funcionalidad 21 Aplicabilidad 39
Precisin 36
Interoperatibilidad 7
Seguridad 8
Conformidad de funcionalidad 10
Fiabilidad 22 M adurez (hardware/software/datos) 40
Tolerancia a fallos 36
Recuperabilidad (datos, proceso, tecnologa) 14
Conformidad de fiabilidad 10
Usabilidad 15 Entendibilidad 29
Facilidad de aprendizaje 23
Operabilidad 27
Atractividad 11
Conformidad de usabilidad 10
Eficiencia 18 Comportamiento en el tiempo 41
Utilizacin de recursos 35
Conformidad de eficiencia 24
Facilidad de 16 Analizabilidad 21
Mantenimiento
Cambiabilidad 23
Estabilidad 21
Testeabilidad 27
Conformidad de facilidad de mantenimiento 8
Portabilidad 8 Adaptabilidad 25
Instabilidad 25
Co existencia 25
Reemplazabilidad 13
Conformidad de portabilidad 13

atributos de calidad (paso 3) se desarroll en una sola sesin

VII. CASO DE APLICACIN
DReC se aplic a un proyecto denominado Vicu-DB que cuyo
desarrollo est en su fase IV como parte de un proyecto de fin
de carrera de estudiantes de Ingeniera Informtica. Vicu-DB
es un software desarrollado para la navegacin y visualizacin
de objetos de bases de datos de mltiples sistemas
administradores de bases de datos relacionales (SABDR),
tanto comerciales como Oracle y MSSql, y libres como
MySQL y PostgreSQL. El software ha sido desarrollado
inicialmente en Delphi y posteriormente se ha desarrollado
una versin en Java. La fase IV del proyecto comprende el
desarrollo de un componente para la migracin de los
programas desarrollados inicialmente entre Oracle y MSSql,
usando TransacSQL para el caso de MSSql y PLSQL para el
caso de Oracle.
La descomposicin del proyecto (paso 1) se realiz a partir
de la documentacin existente y con el equipo de desarrollo
encargado de ese proyecto. Se decidi evaluar solamente el
componente central de la fase IV que se inici hace un par de
semanas y que se refiere principalmente al motor de
conversin entre SQL de un SABDR.
La determinacin de los pesos del modelo (paso 2) y de los
de una maana. Las personas que participaron fueron: dos
estudiantes de ltimo ao de ingeniera informtica que son
los desarrolladores, el desarrollador de la fase I que acta
como usuario para esta nueva fase, una profesora de la seccin
de ingeniera informtica y un asistente del laboratorio que
actuaron como usuarios del producto.
Los pesos del modelo obtenido en la sesin (paso 2)
present gran similitud de calificacin en cuanto a la
fiabilidad y funcionalidad, y gran diferencia en cuanto a la
caracterstica de portabilidad. La obtencin del consenso se
obtuvo rpidamente. La discusin se centr sobre lo
concerniente a portabilidad, dada la gran diferencia. En las
otras caractersticas fue ms sencilla la discusin y se dio en
funcin directa del grado de diferencia de las respuestas. La
tabla 2 muestra los resultados obtenidos en valores
porcentuales para las caractersticas y sub-caractersticas. Los
niveles de calidad de cada atributo (paso 3) se realiz de
manera anloga al paso anterior.
La evaluacin final de la sesin, sobre el uso de la tcnica
al proyecto fue apreciado por alguno de los participantes,
quienes tomaron conciencia de la necesidad de clarificar los
requerimientos de calidad desde el principio.
DVILA et al.: ESTABLISHING SOFTWARE PRODUCT
VIII. CONCLUSIONES Y TRABAJO FUTURO
La determinacin de los requisitos de calidad interna y
externa para el proyecto Vicu-DB ha sido obtenida utilizando
la tcnica DReC, siendo la aplicacin de la tcnica muy
sencilla. El trabajo ms complejo en la preparacin de la
tcnica fue la elaboracin de los cuestionarios, que deban
tener relacin directa con las mtricas de donde se derivan y
ser expresado en trminos de usuario final.
Uno de los factores que puede haber influido en una fcil
aplicacin de la tcnica DReC a Vicu-DB, es que el proyecto
es desarrollado por un equipo donde tanto usuarios como
desarrolladores son profesionales de informtica. Se tiene
previsto la aplicacin de DReC a otros proyectos informticos
y a proyectos donde los usuarios sean menos tcnicos como el
caso de los proyectos relacionados a la construccin de
software para sistemas de informacin en empresas.
La tcnica cumple con incorporar la visin del usuario final
como visin primaria y la del desarrollador como visin
complementaria en la definicin de los pesos del modelo de
calidad de las caractersticas y sub caractersticas y en la
definicin de los valores deseables de los atributos de calidad.
La tcnica se ha desarrollado inicialmente para la calidad
del producto software a nivel de calidad interna y externa,
estando pendiente la extensin, a travs de cuestionarios, para
la calidad en uso. Adems, considerando las indicaciones de la
propia serie de normas ISO/IEC 9126, se puede introducir o
suprimir atributos para la elaboracin del cuestionario de esta
tcnica.
La tcnica puede aplicarse a grandes proyectos, pues se
basa en una descomposicin del producto en componentes
adecuados tal como lo hacen otras tcnicas como Squid [3] y
SQA [2].
El trabajo en esta lnea se puede extender hacia la
determinacin de modelos de calidad de producto para
determinados tipos de sistemas software, de modo que quienes
tengan que tomar la decisin sobre los requisitos de calidad
puedan partir de un modelo de referencia, tal como se hace
para la seleccin de paquetes [7][9].
IX. AGRADECIMIENTOS
Los autores agradecemos a Carla Basurto y a Ana Maria
Moreno por la revisin del documento y sus comentarios.
X. REFERENCIAS
[1] Aiteco Consultora, Tcnicas de Grupo Nominal,
http://www.aiteco.com/tgn.htm [last visited on 2005-03-10].
[2] Barbacci M. et al, Quality Attribute Workshop Participants Handbook,
Special Report CMU/SEI-2000-SR-01, January 2000.
[3] Boegh Jorgen et al, A Method for Software Quality Planning, Control
and Evaluation. IEEE Software, 69(9), March/April 1999.
[4] Boehm Barry et al, Characteristics of Software Quality, Elsevier North-
Holland,1978.
[5] Brosseau Jim, Quantity Quality Attributes,
http://www.spc.ca/essentials/may0802.htm#3 [last visited on 2005-03-
15].
[6] Chirinos Ledis et al, Identifiying Quality-Based Requirements,
Information System Management, 15(11), Winter 2004.
[7] Franch Xavier, Carvallo Juan, Using Quality Models in Software
Package Selection, IEEE software 20(l), pag 34-41, Jan-Feb 2003.
105
[8] Garvin David, What Does 'Product Quality' Really Mean, Sloan
Management Review 25(18), Fall 1984.
[9] Grau Gemma, Carvallo Juan, Franch Xavier, Quer Carme, DesCOTS:
A Software System for Selecting COTS Components, Proceedings of
the 30th EUROMICRO Conference, pp 118-126, Francia, 2004.
[10] IEEE, IEEE Std 1061-1998 IEEE Standard for a Software Quality
Metrics Methodology, IEEE-SA Standard Board, New York,1998.
[11] ISO/IEC, ISO/IEC 12207-1:2001 Software Engineering Product
quality. Part 1: Quality Model, Secretara General de ISO, Ginebra,
2001.
[12] ISO/IEC, ISO/IEC 9126:1991 Information Technology Software
Product Evaluation Quality Characteristics and Guidelines for their
use, Secretara General de ISO, Ginebra, 1991.
[13] ISO/IEC, ISO/IEC 9126-1:2001 Software Engineering Product quality.
Part 1: Quality Model, Secretara General de ISO, Ginebra, 2001.
[14] ISO/IEC, ISO/IEC 9126-2:2003 Software Engineering Product quality.
Part 2: External Metrics, Secretara General de ISO, Ginebra, 2003.
[15] ISO/IEC, ISO/IEC 9126-3:2003 Software Engineering Product quality.
Part 3: Internal Metrics, Secretara General de ISO, Ginebra, 2003.
[16] ISO, ISO/IEC 14598-1:1999 Information Technology Software
Product Evaluation. Part 1: General Overview, Secretara General de
ISO, Ginebra, 1999.
[17] Kitchenham Barbara, Pfleeger Sary, Software Quality: The Elusive
Target, IEEE Software 12 (9), January, 1996.
[18] McCall James et al, Factor in Software Quality. Vol. I , II, III: Final
Technical Report, RADC-TR-77-369, Rome Air Development Center,
Air Force System Command, Griffith Air Force Base, NY 1977.
[19] PMI, Practice Standard for Work Breakdown Structures, Project
Management Institute Inc, Pennsylvania, 2001.
[20] PMI, A Guide to the Project Management Body of Knowledge, Project
Management Institute Inc., Pennsylvania, 3th Edition, 2004.
[21] Project Management Institute Inc., http://www.pmi.org/ [last visited on
2005-01-10]
[22] Soligen Rini van, Berghout Egon, The Goal/Question/Metric Method: a
practical guide for quality improvement of software development,
McGraw-Hill Publishing Companies, London, 1st Edition, 1999.
XI. BIOGRAFIAS
Abraham Dvila es Profesor Asociado de la
Pontificia Universidad Catlica del Per (PUCP), es
doctorando de la Universidad Politcnica de Madrid
(UPM) en Ingeniera de Software, Magster en
Informtica e Ingeniero Mecnico en la PUCP.
Actualmente es coordinador de la especialidad de
Ingeniera Informtica de la PUCP, director del
Grupo de Investigacin y Desarrollo en Ingeniera
de Software (GIDIS) de la PUCP. Es Secretario
Tcnico del Comit de Normalizacin en Ingeniera
de Software y Sistemas de Informacin ante el Instituto Nacional de Defensa
al Consumidor (INDECOPI). Es autor de artculos publicados en eventos
nacionales e internacionales. Su rea de inters es la calidad en software tanto
a nivel de producto como proceso.
Karin Ana Melendez Llave es Profesora de la
Pontificia Universidad Catlica del Per (PUCP),
Bachiller en Ciencias e Ingeniera y Titulada en
Ingeniera Informtica en la PUCP en el ao 2003.
Actualmente es miembro del Comit Tcnico de
Normalizacin en Ingeniera de Software y Sistemas
de Informacin ante el Instituto Nacional de Defensa
al Consumidor (INDECOPI), Asistente del rea
acadmica de Ingeniera de Software en la
especialidad de Ingeniera Informtica, miembro del
Grupo de Investigacin y Desarrollo en Ingeniera de
Software (GIDIS) de la PUCP
106 IEEE LATIN AMERICA TRANSACTIONS, VOL. 4, NO. 2, APRIL 2006

Luis Alberto Flores Garcia es Profesor de la

Pontificia Universidad Catlica del Per
(PUCP), Bachiller en Ciencias e Ingeniera y
Titulada en Ingeniera Informtica en la PUCP
en el ao 2003. Actualmente es miembro del
Software Process Improvement Network
(SPIN-Per). Es miembro del Grupo de
Investigacin y Desarrollo en Ingeniera de
Software (GIDIS) de la PUCP