100
2, APRIL 2006
Determinación de los Requerimientos de
Calidad del Producto Software Basados en
Normas Internacionales
Abraham Dávila (edavila@pucp.edu.pe), Karin Melendez (melendez.ka@pucp.edu.pe) y Luis Flores
(flores.la@pucp.edu.pe), Sección Ingeniería Informática, Pontificia Universidad Católica del Perú,
Lima, Perú
 En el año 1994 se inicia la revisión de la norma internacional
Resumen-- La calidad del producto software es una
preocupación cada vez mayor en el ámbito informático 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 identificación 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
métricas a usarse. Determinar los requerimientos de calidad y los
niveles de métricas, aparentan ser actividades sencillas, pero
podrían resultar ser engorrosas y propensas a errores si no se
tiene establecido un esquema sistemático para su determinación.
Este artículo presenta una propuesta para la determinación de
los requerimientos de calidad del producto basado en el estándar
ISO/IEC 9126.
Palabras Claves—Calidad de Software, Requerimientos de
Calidad de Producto Software, ISO/IEC 9126.
I. INTRODUCCIÓN
L a calidad es un tema complejo como lo señala
Kitchenham y Pfleeger [17] y existen diversas formas de
abordarlo. Un enfoque interesante y muy influyente,
presentado por Garvín, es la visión de la calidad desde cinco
perspectivas: (i) la visión trascendental que puede ser
reconocida pero no definida, (ii) la visión del usuario como la
adecuación al propósito del usuario, (iii) la visión del
productor como conformidad con la especificación, (iv) la
visión del producto, basada en las características observables
del producto, y (v) la visión basada en el valor que el cliente
está dispuesto a pagar [8].
La calidad del producto se ha venido tratando desde hace
varios años, siendo los primeros modelos desarrollados por
McCall [18] y Boehm [4]. Lamentablemente, para cada
proyecto se adoptaba modelos de calidad diferentes, haciendo
difícil la comparación. Con la publicación de la primera
edición de la estándar 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 métricas y la serie de normas ISO/IEC 14598 (6
partes) referida a la evaluación 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 través de las métricas. 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
retroalimentación
indica
de calidad Calidad externa
externa
validación
contribuye a indica
especificar
Requerimientos
de calidad Calidad interna
interna
verificación
[13]
La traducción 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 especificación 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 educción de requisitos de software es una
actividad complicada y describir la calidad también es
DÁVILA 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 diseño de la evaluación (paso 3) comprende la preparación
de vista del usuario, será una actividad de la misma de un plan de medición conteniendo los entregables sobre los
naturaleza. cuales se hará el proceso de medición y las métricas que se
La traducción de la necesidad de calidad del usuario a aplicarán.
requerimientos de calidad (externa e interna) podría derivarse
estableciendo algunas reglas o modelos como se presenta en TABLE I
RECLAMO [6], utilizando un criterio de comparación relativa Funcionalidad Aplicabilidad A
cada dos características [5], siguiendo los pasos descritos en el
Precisión A
estándar 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 técnica Conformidad de funcionalidad M
desarrollada se basa en la filosofía de los trabajos de QAW y
CALIDAD DEFINIDA PARA LAS SUB-CARACTERÍSTICAS: FUNCIONALIDAD [13]
GQM, adaptándolos para la determinación de requisitos de
calidad considerando el punto de vista del usuario. III. VISIÓN GENERAL
En las próximas secciones se presentará los pasos para la
calidad del producto según la norma internacional, la DReC se propone como “una técnica para la determinación
descripción de la técnica propuesta, los pasos para su de los requerimientos de calidad de un producto software
aplicación, documentos de trabajo que utiliza, una aplicación basada principalmente en el punto de vista de usuarios y el
de la técnica y las conclusiones y trabajos futuros en esta punto de vista de desarrolladores de una manera
línea. complementaria”. La definición implica que: (i) la
determinación de requerimientos de calidad es un proceso de
II. PASOS PARA LA CALIDAD DE PRODUCTO SEGÚN LA NORMA fijación de valores (niveles de calidad y estimación de
ISO/IEC 9126 métricas) que serán tomados inicialmente para la planificación
de la calidad y posteriormente como referencia para la
La norma ISO/IEC 9126-1:2001 presenta -en el anexo- los
evaluación del producto software; (ii) el usuario es un actor
pasos del enfoque de calidad de producto como un ejemplo
importante en la determinación de los requerimientos de
orientado a la evaluación de la calidad [13]. Los pasos
calidad y su punto de vista debe ser sistemáticamente
descritos son: (i) identificación de requerimientos de calidad;
obtenido; (iii) el desarrollador es un actor que contrapesará la
(ii) especificación de la evaluación, (iii) diseño de la
opinión del usuario, pero debe subordinar –finalmente- su
evaluación, (iv) ejecución de la evaluación, y (v)
opinión a la del usuario si no existe un consenso sobre los
retroalimentación a la organización. El primer paso debe
valores; (iv) DReC se orienta principalmente a usuarios
realizarse durante el Análisis 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
términos lo menos técnico 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 evaluación.
Administración de Proyectos (PMBOK) [20] del Project
La identificación 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
organización que utilizará el producto y al de la organización
usuario para cada una de las características y sub
desarrolladora. Con la organización usuaria, por que pueden
características. Los pesos representan la valoración
tener datos sobre los niveles de calidad de los productos que
comparada entre las distintas características y sub
utilizan y pueden ser tomadas como referencia para los nuevos
características y para ello se puede utilizar una calificación
productos que requieran. Con la organización desarrolladora,
relativa de alto / medio / bajo o una calificación 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 definición de la calidad
nivel esperado de calidad en el nuevo proyecto. Sin embargo
externa e interna del producto a nivel de sub-característica
la técnica puede aplicarse también en las organizaciones
para la característica de la funcionalidad, según la norma
usuarias y desarrolladoras que no cuentan con estos datos
ISO/IEC 9126.
históricos; ya que no es una práctica extendida.
La especificación de la evaluación (paso 2) permite
DReC se utiliza en las primeras etapas de un proyecto de
identificar los valores deseables de las métricas a utilizar
desarrollo de software (Análisis de los Requerimientos
posteriormente en el desarrollo y en la evaluación del
Participan en su determinación los usuarios y los
producto. Estos valores deben orientarse principalmente a
desarrolladores (responsables del proyecto).
cubrir las necesidades del usuario. La definición 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 Subcaracterísticas Atributos de Calidad

Consolidar Consolidar
Seleccionar componentes Información Información
Relevantes

Revisar Resultados Revisar Resultados

Repetir
para
1<=x<=3

Fig. 2. Diagrama de actividades de DReC

DReC tiene como objetivo determinar: (i) las
características de calidad interna y externa que son relevantes
en la desarrollo de software; (ii) los niveles de calidad de cada
característica y sub-característica; y (iii) los niveles de calidad
de los atributos (valores deseables de las métricas) del
producto a desarrollar. Estos objetivos primarios de DReC
coinciden con los tres primeros pasos establecidos por la
ISO/IEC 9126 descrito en la sección anterior.
Para la primera aproximación de DReC se ha considerado
las métricas de los atributos establecidos para las sub-
características 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 características, sub-
características y métricas.
IV. DESCRIPCIÓN DE DREC
La técnica se compone de 3 pasos tal como se puede
apreciar en la figura 2 y que se describe a continuación.
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 técnica. La razón es que un producto
software tiene diversos componentes cuyas necesidades de
calidad son diferentes, dependiendo de la función que realizan
dentro del producto final. Un claro ejemplo se da en los
sistemas de información en donde existen componentes de
explotación de información (como reportes) cuyo nivel de
calidad requerido es diferente a los de registro y
procesamiento de datos.
La selección de un sub conjunto de componentes sobre el
que se aplique una técnica es una práctica que también 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 organización desarrolladora tiene la lista de componentes
por alguna actividad previa a la aplicación de DReC. Los sub-
pasos que componen este paso son:
Paso 1a. Descomponer el producto software en
componentes, se puede utilizar una estructura de
descomposición del trabajo orientada al producto también
conocido como WBS (del inglés Work Breakdown Structure)
que es una práctica recomendada por PMI [19].
Opcionalmente se puede utilizar otra técnica para
identificación de componentes.
Paso 1b. Seleccionar los componentes relevantes, es decir,
aquellos que son considerados los más importantes y/o críticos
para la solución (sistema software) que se va a desarrollar.
Puede utilizar cualquier técnica para selección basada en
grupo de personas; como por ejemplo la Técnica de Grupo
Nominal [1].
Paso 2: Definir los pesos del modelo de calidad
(características y sub-caracteristicas), el objetivo de este paso
es la determinación de los valores a ser usados en el modelo
obtenidos sistemáticamente mediante un cuestionario que se
aplicará a cada componente seleccionado en el paso 1. La
razón es que el modelo de calidad es una representación
abstracta de un conjunto de características y sub
características del producto software; sin embargo, el nivel de
importancia de las características y sub características varían
entre uno u otro proyecto y su contexto. Un software para
niños tiene características de calidad muy disímiles con un
software para una sala de urgencias, que uno para un sistema
de información empresarial. Cada participante contestará el
cuestionario de modo que plasme su percepción sobre la
importancia –comparada- de las características y sub
características. Los participantes son usuarios y
desarrolladores; y el cuestionario está redactado de manera
que sea fácil de comprender (principalmente para los
usuarios); pero cuyas respuestas permitan internamente ayudar
en la determinación 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
DÁVILA et al.: ESTABLISHING SOFTWARE PRODUCT
este paso es un modelo de calidad con los pesos definidos a
nivel de características y sub-características. Los sub pasos
que componen este paso son:
Paso 2a. Completar la hoja inicial (DReC00) marcando con
una "x" de acuerdo a cada línea que describe una característica
o sub característica. La hoja es completada por todas las
personas convocadas: usuarios y desarrolladores.
Paso 2b. Consolidar la información de todos los
participantes, de preferencia de manera automática usando
hojas de cálculo o un producto software ad-hoc para esta
actividad de modo que sea rápido y con resultados confiables.
Paso 2c. Revisar los resultados obtenidos y discutir sobre
las respuestas cuya variación sea significativa hasta encontrar
un consenso entre todos los participantes de la sesión, la
participación será mediante un director de debate. Se podrá
utilizar adicionalmente las hojas “DReC11” y “DReC12”
siempre que se cuente con datos históricos.
Paso 3: Definir los niveles de calidad esperado en los
atributos del producto, el objetivo de este paso es la
determinación de los valores a ser usados como nivel de
referencia para las métricas en la evaluación, obtenidos
sistemáticamente mediante la aplicación de un conjunto de
cuestionarios que se aplicarán a cada componente
seleccionado en el paso 1. La razón 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 características internas y externas, es
una necesidad del equipo de desarrollo para que puedan
definir las actividades de control de calidad para el proyecto.
La determinación debe ser el resultado de una negociación
(consenso / acuerdo) entre los usuarios y los desarrolladores,
que apoyados en DReC pueden reducir la discusión sobre
aquellos aspectos en que hay una diferencia de opinión sobre
el nivel de calidad requerido. Igual que en el paso anterior,
los participantes son usuarios y desarrolladores, y los
cuestionarios están 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 línea que describe un
atributo. La hoja es completada por todas las personas
convocadas: usuarios y desarrolladores
Paso 3b. Consolidar la información de todos los
participantes, de preferencia de manera automática usando
hojas de cálculo o un producto software ad-hoc para esta
actividad de modo que sea rápido y con resultados confiables.
Paso 3c. Revisar los resultados obtenidos y discutir sobre
las respuestas cuya variación sea significativa hasta encontrar
un consenso entre todos los participantes de la sesión, la
participación será mediante un director de debate. Se
103
utilizarán 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 TÉCNICA
La técnica descrita en la sección 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 diseñado
para almacenar los requerimientos de calidad de un proyecto
determinado (planificado), tanto para la organización 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 continuación:
ƒ DReC00, para la determinación de pesos de las
características y sub características, derivado de la
ISO/IEC 9126-1:2001[13].
ƒ DReC01..06, para la determinación de niveles de calidad
interna y externa en cada atributo de la característica de
funcionalidad, fiabilidad, eficiencia, usabilidad, facilidad
de mantenimiento y portabilidad.
ƒ DReC11, tabla de valores de pesos de calidad
planificados por proyecto y organización.
ƒ DReC12, tabla de valores de pesos de calidad reales por
proyecto y organización.
ƒ DReC21, tabla de valores de métricas de atributos del
producto planificados por proyecto y organización.
ƒ DReC22, tabla de valores de métricas de atributos del
producto reales por proyecto y organización.
VI. APLICACIÓN DE LA TÉCNICA
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 descomposición y la selección de componentes
tomando en cuenta las necesidades del usuario, el producto
mismo y los objetivos de la organización usuaria; esta etapa se
puede realizar en una sola sesión.
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 podría definirse un equipo
diferente de personas quienes completen las actividades; ello
dependerá del componente en si mismo.
Si el número de componentes es muy alto, quizás sea
conveniente establecer un conjunto de sesiones para cubrir
todos los componentes, se sugiere que la evaluación de un
componente se realice totalmente dentro de una sola sesión;
dividir la evaluación de un componente en dos sesiones
diferentes podría introducir ruido debido a las conversaciones
fuera de sesión 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
Característica Peso % Subcaracterística Peso %
Funcionalidad 21 Aplicabilidad 39
Precisión 36
Interoperatibilidad 7
Seguridad 8
Conformidad de funcionalidad 10
Fiabilidad 22 M adurez (hardware/software/datos) 40
Tolerancia a fallos 36
Recuperabilidad (datos, proceso, tecnología) 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
Utilización 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 sesión

VII. CASO DE APLICACIÓN
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 Ingeniería Informática. Vicu-DB
es un software desarrollado para la navegación y visualización
de objetos de bases de datos de múltiples 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 versión en Java. La fase IV del proyecto comprende el
desarrollo de un componente para la migración de los
programas desarrollados inicialmente entre Oracle y MSSql,
usando TransacSQL para el caso de MSSql y PLSQL para el
caso de Oracle.
La descomposición del proyecto (paso 1) se realizó a partir
de la documentación 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
conversión entre SQL de un SABDR.
La determinación de los pesos del modelo (paso 2) y de los
de una mañana. Las personas que participaron fueron: dos
estudiantes de último año de ingeniería informática que son
los desarrolladores, el desarrollador de la fase I que actúa
como usuario para esta nueva fase, una profesora de la sección
de ingeniería informática y un asistente del laboratorio que
actuaron como usuarios del producto.
Los pesos del modelo obtenido en la sesión (paso 2)
presentó gran similitud de calificación en cuanto a la
fiabilidad y funcionalidad, y gran diferencia en cuanto a la
característica de portabilidad. La obtención del consenso se
obtuvo rápidamente. La discusión se centró sobre lo
concerniente a portabilidad, dada la gran diferencia. En las
otras características fue más sencilla la discusión y se dio en
función directa del grado de diferencia de las respuestas. La
tabla 2 muestra los resultados obtenidos en valores
porcentuales para las características y sub-características. Los
niveles de calidad de cada atributo (paso 3) se realizó de
manera análoga al paso anterior.
La evaluación final de la sesión, sobre el uso de la técnica
al proyecto fue apreciado por alguno de los participantes,
quienes tomaron conciencia de la necesidad de clarificar los
requerimientos de calidad desde el principio.
DÁVILA et al.: ESTABLISHING SOFTWARE PRODUCT
VIII. CONCLUSIONES Y TRABAJO FUTURO
La determinación de los requisitos de calidad interna y
externa para el proyecto Vicu-DB ha sido obtenida utilizando
la técnica DReC, siendo la aplicación de la técnica muy
sencilla. El trabajo más complejo en la preparación de la
técnica fue la elaboración de los cuestionarios, que debían
tener relación directa con las métricas de donde se derivan y
ser expresado en términos de usuario final.
Uno de los factores que puede haber influido en una fácil
aplicación de la técnica DReC a Vicu-DB, es que el proyecto
es desarrollado por un equipo donde tanto usuarios como
desarrolladores son profesionales de informática. Se tiene
previsto la aplicación de DReC a otros proyectos informáticos
y a proyectos donde los usuarios sean menos técnicos como el
caso de los proyectos relacionados a la construcción de
software para sistemas de información en empresas.
La técnica cumple con incorporar la visión del usuario final
como visión primaria y la del desarrollador como visión
complementaria en la definición de los pesos del modelo de
calidad de las características y sub características y en la
definición de los valores deseables de los atributos de calidad.
La técnica se ha desarrollado inicialmente para la calidad
del producto software a nivel de calidad interna y externa,
estando pendiente la extensión, a través de cuestionarios, para
la calidad en uso. Además, considerando las indicaciones de la
propia serie de normas ISO/IEC 9126, se puede introducir o
suprimir atributos para la elaboración del cuestionario de esta
técnica.
La técnica puede aplicarse a grandes proyectos, pues se
basa en una descomposición del producto en componentes
adecuados tal como lo hacen otras técnicas como Squid [3] y
SQA [2].
El trabajo en esta línea se puede extender hacia la
determinación de modelos de calidad de producto para
determinados tipos de sistemas software, de modo que quienes
tengan que tomar la decisión sobre los requisitos de calidad
puedan partir de un modelo de referencia, tal como se hace
para la selección de paquetes [7][9].
IX. AGRADECIMIENTOS
Los autores agradecemos a Carla Basurto y a Ana Maria
Moreno por la revisión del documento y sus comentarios.
X. REFERENCIAS
[1] Aiteco Consultora, ”Técnicas 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, Secretaría General de ISO, Ginebra,
2001.
[12] ISO/IEC, ISO/IEC 9126:1991 Information Technology – Software
Product Evaluation – Quality Characteristics and Guidelines for their
use, Secretaría General de ISO, Ginebra, 1991.
[13] ISO/IEC, ISO/IEC 9126-1:2001 Software Engineering – Product quality.
Part 1: Quality Model, Secretaría General de ISO, Ginebra, 2001.
[14] ISO/IEC, ISO/IEC 9126-2:2003 Software Engineering – Product quality.
Part 2: External Metrics, Secretaría General de ISO, Ginebra, 2003.
[15] ISO/IEC, ISO/IEC 9126-3:2003 Software Engineering – Product quality.
Part 3: Internal Metrics, Secretaría General de ISO, Ginebra, 2003.
[16] ISO, ISO/IEC 14598-1:1999 Information Technology – Software
Product Evaluation. Part 1: General Overview, Secretaría 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 Dávila es Profesor Asociado de la
Pontificia Universidad Católica del Perú (PUCP), es
doctorando de la Universidad Politécnica de Madrid
(UPM) en Ingeniería de Software, Magíster en
Informática e Ingeniero Mecánico en la PUCP.
Actualmente es coordinador de la especialidad de
Ingeniería Informática de la PUCP, director del
Grupo de Investigación y Desarrollo en Ingeniería
de Software (GIDIS) de la PUCP. Es Secretario
Técnico del Comité de Normalización en Ingeniería
de Software y Sistemas de Información ante el Instituto Nacional de Defensa
al Consumidor (INDECOPI). Es autor de artículos publicados en eventos
nacionales e internacionales. Su área de interés es la calidad en software tanto
a nivel de producto como proceso.
Karin Ana Melendez Llave es Profesora de la
Pontificia Universidad Católica del Perú (PUCP),
Bachiller en Ciencias e Ingeniería y Titulada en
Ingeniería Informática en la PUCP en el año 2003.
Actualmente es miembro del Comité Técnico de
Normalización en Ingeniería de Software y Sistemas
de Información ante el Instituto Nacional de Defensa
al Consumidor (INDECOPI), Asistente del área
académica de Ingeniería de Software en la
especialidad de Ingeniería Informática, miembro del
Grupo de Investigación y Desarrollo en Ingeniería 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 Católica del Perú
(PUCP), Bachiller en Ciencias e Ingeniería y
Titulada en Ingeniería Informática en la PUCP
en el año 2003. Actualmente es miembro del
Software Process Improvement Network
(SPIN-Perú). Es miembro del Grupo de
Investigación y Desarrollo en Ingeniería de
Software (GIDIS) de la PUCP