100

IEEE LATIN AMERICA TRANSACTIONS, VOL. 4, NO. 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

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.

En el ao 1994 se inicia la revisin de la norma internacional 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 usuario
contribuye a especificar

Calidad en uso

I. INTRODUCCIN 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].

uso y retroalimentacin

indica

Requerimientos de calidad externa

Calidad externa

validacin

contribuye a especificar
Requerimientos de calidad interna

indica

Calidad 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 requisitos de calidad interna y externa considerando el punto de vista del usuario, ser una actividad de la misma naturaleza. La traduccin de la necesidad de calidad del usuario a requerimientos de calidad (externa e interna) podra derivarse estableciendo algunas reglas o modelos como se presenta en RECLAMO [6], utilizando un criterio de comparacin relativa cada dos caractersticas [5], siguiendo los pasos descritos en el estndar de IEEE [10] u obtenerse directamente de los involucrados utilizando cuestionarios adecuados como se hace en QAW (Quality Attribute Workshop) [2] o usando los principios de GQM (Goal/Question/Metrics) [22]. La tcnica desarrollada se basa en la filosofa de los trabajos de QAW y GQM, adaptndolos para la determinacin de requisitos de calidad considerando el punto de vista del usuario. En las prximas secciones se presentar los pasos para la calidad del producto segn la norma internacional, la descripcin de la tcnica propuesta, los pasos para su aplicacin, documentos de trabajo que utiliza, una aplicacin de la tcnica y las conclusiones y trabajos futuros en esta lnea. II. PASOS PARA LA CALIDAD DE PRODUCTO SEGN LA NORMA ISO/IEC 9126 La norma ISO/IEC 9126-1:2001 presenta -en el anexo- los pasos del enfoque de calidad de producto como un ejemplo orientado a la evaluacin de la calidad [13]. Los pasos descritos son: (i) identificacin de requerimientos de calidad; (ii) especificacin de la evaluacin, (iii) diseo de la evaluacin, (iv) ejecucin de la evaluacin, y (v) retroalimentacin a la organizacin. El primer paso debe realizarse durante el Anlisis de los Requerimientos y el resto de pasos durante cada actividad del proceso de desarrollo. Los tres primeros pasos son descritos con detalle en la norma, el cuarto hace una referencia a la serie de normas ISO/IEC 14598 y el quinto presenta una comentario sencillo y directo sobre como realizar la evaluacin. La identificacin de requerimientos de calidad (paso 1) permite determinar los pesos a ser utilizados en el modelo de calidad y que debe reflejar las necesidades de calidad del usuario para cada una de las caractersticas y sub caractersticas. Los pesos representan la valoracin comparada entre las distintas caractersticas y sub caractersticas y para ello se puede utilizar una calificacin relativa de alto / medio / bajo o una calificacin basada en valores que puede ir entre 1 y 9. En la tabla 1 se presenta, a manera de ejemplo, un extracto de la definicin de la calidad externa e interna del producto a nivel de sub-caracterstica para la caracterstica de la funcionalidad, segn la norma ISO/IEC 9126. La especificacin de la evaluacin (paso 2) permite identificar los valores deseables de las mtricas a utilizar posteriormente en el desarrollo y en la evaluacin del producto. Estos valores deben orientarse principalmente a cubrir las necesidades del usuario. La definicin de valores

deseables depende directamente de cada atributo del producto. El diseo de la evaluacin (paso 3) comprende la preparacin de un plan de medicin conteniendo los entregables sobre los cuales se har el proceso de medicin y las mtricas que se aplicarn.
TABLE I

Funcionalidad

Aplicabilidad Precisin Interoperatibilidad Seguridad Conformidad de funcionalidad

A A B B M

CALIDAD DEFINIDA PARA LAS SUB-CARACTERSTICAS: FUNCIONALIDAD [13]

III. VISIN GENERAL DReC se propone como una tcnica para la determinacin de los requerimientos de calidad de un producto software basada principalmente en el punto de vista de usuarios y el punto de vista de desarrolladores de una manera complementaria. La definicin implica que: (i) la determinacin de requerimientos de calidad es un proceso de fijacin de valores (niveles de calidad y estimacin de mtricas) que sern tomados inicialmente para la planificacin de la calidad y posteriormente como referencia para la evaluacin del producto software; (ii) el usuario es un actor importante en la determinacin de los requerimientos de calidad y su punto de vista debe ser sistemticamente obtenido; (iii) el desarrollador es un actor que contrapesar la opinin del usuario, pero debe subordinar finalmente- su opinin a la del usuario si no existe un consenso sobre los valores; (iv) DReC se orienta principalmente a usuarios finales, por lo que la manera de relacionarse a l, ser en trminos lo menos tcnico posible pero con la claridad necesaria para determinar adecuadamente los valores; y (v) DReC se basa en la serie de normas ISO/IEC 9126, ISO/IEC 14598 y recomendaciones del Cuerpo de Conocimiento de la Administracin de Proyectos (PMBOK) [20] del Project Management Institute [21]. La herramienta debe ajustarse al contexto de la organizacin que utilizar el producto y al de la organizacin desarrolladora. Con la organizacin usuaria, por que pueden tener datos sobre los niveles de calidad de los productos que utilizan y pueden ser tomadas como referencia para los nuevos productos que requieran. Con la organizacin desarrolladora, por que pueden tener datos sobre los niveles de calidad obtenidos en proyectos anteriores, que pueden respaldar el nivel esperado de calidad en el nuevo proyecto. Sin embargo la tcnica puede aplicarse tambin en las organizaciones usuarias y desarrolladoras que no cuentan con estos datos histricos; ya que no es una prctica extendida. DReC se utiliza en las primeras etapas de un proyecto de desarrollo de software (Anlisis de los Requerimientos Participan en su determinacin los usuarios y los desarrolladores (responsables del proyecto).

102

IEEE LATIN AMERICA TRANSACTIONS, VOL. 4, NO. 2, APRIL 2006

PASO 2 PASO 1 Descomponer el producto deoftware en com ponentes s Completar la hoja inicial (Drec00) Subcaractersticas

PASO 3 Completar la hoja (Drec0x) Atributos de Calidad Consolidar Informacin Revisar Resultados Repetir para 1<=x<=3

Seleccionar componentes Relevantes

Consolidar Informacin

Revisar Resultados

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 subcaractersticas 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, subcaractersticas 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 91261:2001 [13] y se compone de 33 preguntas. El resultado de

DVILA et al.: ESTABLISHING SOFTWARE PRODUCT

103

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 usodepende 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 91262: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

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 Funcionalidad

Peso % 21

Fiabilidad

22

Usabilidad

15

Eficiencia

18

Facilidad de Mantenimiento

16

Subcaracterstica Aplicabilidad Precisin Interoperatibilidad Seguridad Conformidad de funcionalidad M adurez (hardware/software/datos) Tolerancia a fallos Recuperabilidad (datos, proceso, tecnologa) Conformidad de fiabilidad Entendibilidad Facilidad de aprendizaje Operabilidad Atractividad Conformidad de usabilidad Comportamiento en el tiempo Utilizacin de recursos Conformidad de eficiencia Analizabilidad Cambiabilidad Estabilidad Testeabilidad Conformidad de facilidad de mantenimiento Adaptabilidad Instabilidad Co existencia Reemplazabilidad Conformidad de portabilidad

Peso % 39 36 7 8 10 40 36 14 10 29 23 27 11 10 41 35 24 21 23 21 27 8 25 25 25 13 13

Portabilidad

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

atributos de calidad (paso 3) se desarroll en una sola sesin 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

105

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] [2] [3] [4] [5] Aiteco Consultora, Tcnicas de Grupo Nominal, http://www.aiteco.com/tgn.htm [last visited on 2005-03-10]. Barbacci M. et al, Quality Attribute Workshop Participants Handbook, Special Report CMU/SEI-2000-SR-01, January 2000. Boegh Jorgen et al, A Method for Software Quality Planning, Control and Evaluation. IEEE Software, 69(9), March/April 1999. Boehm Barry et al, Characteristics of Software Quality, Elsevier NorthHolland,1978. Brosseau Jim, Quantity Quality Attributes, http://www.spc.ca/essentials/may0802.htm#3 [last visited on 2005-0315]. Chirinos Ledis et al, Identifiying Quality-Based Requirements, Information System Management, 15(11), Winter 2004. Franch Xavier, Carvallo Juan, Using Quality Models in Software Package Selection, IEEE software 20(l), pag 34-41, Jan-Feb 2003.

[8] [9]

[10] [11]

[12]

[13] [14] [15] [16]

[17] [18]

[19] [20] [21] [22]

Garvin David, What Does 'Product Quality' Really Mean, Sloan Management Review 25(18), Fall 1984. 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. IEEE, IEEE Std 1061-1998 IEEE Standard for a Software Quality Metrics Methodology, IEEE-SA Standard Board, New York,1998. ISO/IEC, ISO/IEC 12207-1:2001 Software Engineering Product quality. Part 1: Quality Model, Secretara General de ISO, Ginebra, 2001. ISO/IEC, ISO/IEC 9126:1991 Information Technology Software Product Evaluation Quality Characteristics and Guidelines for their use, Secretara General de ISO, Ginebra, 1991. ISO/IEC, ISO/IEC 9126-1:2001 Software Engineering Product quality. Part 1: Quality Model, Secretara General de ISO, Ginebra, 2001. ISO/IEC, ISO/IEC 9126-2:2003 Software Engineering Product quality. Part 2: External Metrics, Secretara General de ISO, Ginebra, 2003. ISO/IEC, ISO/IEC 9126-3:2003 Software Engineering Product quality. Part 3: Internal Metrics, Secretara General de ISO, Ginebra, 2003. ISO, ISO/IEC 14598-1:1999 Information Technology Software Product Evaluation. Part 1: General Overview, Secretara General de ISO, Ginebra, 1999. Kitchenham Barbara, Pfleeger Sary, Software Quality: The Elusive Target, IEEE Software 12 (9), January, 1996. 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. PMI, Practice Standard for Work Breakdown Structures, Project Management Institute Inc, Pennsylvania, 2001. PMI, A Guide to the Project Management Body of Knowledge, Project Management Institute Inc., Pennsylvania, 3th Edition, 2004. Project Management Institute Inc., http://www.pmi.org/ [last visited on 2005-01-10] 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

[6] [7]

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