Determinación de los Requerimientos de Calidad del Producto Software Basados en Normas Internacionales

Transcripción

1 100 IEEE LATIN AMERICA TRANSACTIONS, VOL. 4, NO. 2, APRIL 2006 Determinación de los Requerimientos de Calidad del Producto Software Basados en Normas Internacionales Abraham Dávila Karin Melendez y Luis Flores Sección Ingeniería Informática, Pontificia Universidad Católica del Perú, Lima, Perú 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 Palabras Claves Calidad de Software, Requerimientos de Calidad de Producto Software, ISO/IEC I. INTRODUCCIÓN a calidad es un tema complejo como lo señala LKitchenham 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]. En el año 1994 se inicia la revisión 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 métricas y la serie de normas ISO/IEC (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 [13] Necesidades de calidad del usuario contribuye a especificar Requerimientos de calidad externa contribuye a especificar Requerimientos de calidad interna uso y retroalimentación validación verificación Calidad en uso indica Calidad externa indica Calidad interna 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

2 DÁVILA 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 traducción de la necesidad de calidad del usuario a requerimientos de calidad (externa e interna) podría derivarse estableciendo algunas reglas o modelos como se presenta en RECLAMO [6], utilizando un criterio de comparación relativa cada dos características [5], siguiendo los pasos descritos en el estándar 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 técnica desarrollada se basa en la filosofía de los trabajos de QAW y GQM, adaptándolos para la determinación de requisitos de calidad considerando el punto de vista del usuario. En las próximas secciones se presentará los pasos para la calidad del producto según la norma internacional, la descripción de la técnica propuesta, los pasos para su aplicación, documentos de trabajo que utiliza, una aplicación de la técnica y las conclusiones y trabajos futuros en esta línea. II. PASOS PARA LA CALIDAD DE PRODUCTO SEGÚN LA NORMA ISO/IEC 9126 La norma ISO/IEC :2001 presenta -en el anexo- los pasos del enfoque de calidad de producto como un ejemplo orientado a la evaluación de la calidad [13]. Los pasos descritos son: (i) identificación de requerimientos de calidad; (ii) especificación de la evaluación, (iii) diseño de la evaluación, (iv) ejecución de la evaluación, y (v) retroalimentación a la organización. El primer paso debe realizarse durante el Análisis 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 y el quinto presenta una comentario sencillo y directo sobre como realizar la evaluación. La identificación 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 características y sub características. Los pesos representan la valoración comparada entre las distintas características y sub características y para ello se puede utilizar una calificación relativa de alto / medio / bajo o una calificación basada en valores que puede ir entre 1 y 9. En la tabla 1 se presenta, a manera de ejemplo, un extracto de la definición de la calidad externa e interna del producto a nivel de sub-característica para la característica de la funcionalidad, según la norma ISO/IEC La especificación de la evaluación (paso 2) permite identificar los valores deseables de las métricas a utilizar posteriormente en el desarrollo y en la evaluación del producto. Estos valores deben orientarse principalmente a cubrir las necesidades del usuario. La definición de valores deseables depende directamente de cada atributo del producto. El diseño de la evaluación (paso 3) comprende la preparación de un plan de medición conteniendo los entregables sobre los cuales se hará el proceso de medición y las métricas que se aplicarán. TABLE I Funcionalidad Aplicabilidad A Precisión A Interoperatibilidad B Seguridad B Conformidad de funcionalidad M CALIDAD DEFINIDA PARA LAS SUB-CARACTERÍSTICAS:FUNCIONALIDAD [13] III. VISIÓN GENERAL DReC se propone como una técnica para la determinación 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 definición implica que: (i) la determinación de requerimientos de calidad es un proceso de fijación de valores (niveles de calidad y estimación de métricas) que serán tomados inicialmente para la planificación de la calidad y posteriormente como referencia para la evaluación del producto software; (ii) el usuario es un actor importante en la determinación de los requerimientos de calidad y su punto de vista debe ser sistemáticamente obtenido; (iii) el desarrollador es un actor que contrapesará la opinión del usuario, pero debe subordinar finalmente- su opinión 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 términos lo menos técnico 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 y recomendaciones del Cuerpo de Conocimiento de la Administración de Proyectos (PMBOK) [20] del Project Management Institute [21]. La herramienta debe ajustarse al contexto de la organización que utilizará el producto y al de la organización desarrolladora. Con la organización 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 organización 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 técnica puede aplicarse también en las organizaciones usuarias y desarrolladoras que no cuentan con estos datos históricos; ya que no es una práctica extendida. DReC se utiliza en las primeras etapas de un proyecto de desarrollo de software (Análisis de los Requerimientos Participan en su determinación los usuarios y los desarrolladores (responsables del proyecto).

3 102 IEEE LATIN AMERICA TRANSACTIONS, VOL. 4, NO. 2, APRIL 2006 PASO 1 Descomponer el producto desoftware en componentes PASO 2 Completar la hoja inicial (Drec00) Subcaracterísticas PASO 3 Completar la hoja (Drec0x) Atributos de Calidad Seleccionar componentes Relevantes Consolidar Información Consolidar Información Revisar Resultados Repetir para 1<=x<=3 Revisar Resultados 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 subcaracterísticas internas y externas del modelo de calidad del producto software, de la serie ISO/IEC Los cuestionarios de DReC se han elaborado a partir de las definiciones propias de la norma de características, subcaracterí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 subpasos 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 :2001 [13] y se compone de 33 preguntas. El resultado de

4 DÁVILA et al.: ESTABLISHING SOFTWARE PRODUCT 103 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 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 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 :2003 [14] e ISO/IEC :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 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 :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.

5 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 Madurez (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 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 atributos de calidad (paso 3) se desarrolló en una sola sesión 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.

6 DÁVILA et al.: ESTABLISHING SOFTWARE PRODUCT 105 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, [last visited on ]. [2] Barbacci M. et al, Quality Attribute Workshop Participants Handbook, Special Report CMU/SEI-2000-SR-01, January [3] Boegh Jorgen et al, A Method for Software Quality Planning, Control and Evaluation. IEEE Software, 69(9), March/April [4] Boehm Barry et al, Characteristics of Software Quality, Elsevier North- Holland,1978. [5] Brosseau Jim, Quantity Quality Attributes, [last visited on ]. [6] Chirinos Ledis et al, Identifiying Quality-Based Requirements, Information System Management, 15(11), Winter [7] Franch Xavier, Carvallo Juan, Using Quality Models in Software Package Selection, IEEE software 20(l), pag 34-41, Jan-Feb [8] Garvin David, What Does 'Product Quality' Really Mean, Sloan Management Review 25(18), Fall [9] Grau Gemma, Carvallo Juan, Franch Xavier, Quer Carme, DesCOTS: A Software System for Selecting COTS Components, Proceedings of the 30th EUROMICRO Conference, pp , Francia, [10] IEEE, IEEE Std IEEE Standard for a Software Quality Metrics Methodology, IEEE-SA Standard Board, New York,1998. [11] ISO/IEC, ISO/IEC :2001 Software Engineering Product quality. Part 1: Quality Model, Secretaría General de ISO, Ginebra, [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, [13] ISO/IEC, ISO/IEC :2001 Software Engineering Product quality. Part 1: Quality Model, Secretaría General de ISO, Ginebra, [14] ISO/IEC, ISO/IEC :2003 Software Engineering Product quality. Part 2: External Metrics, Secretaría General de ISO, Ginebra, [15] ISO/IEC, ISO/IEC :2003 Software Engineering Product quality. Part 3: Internal Metrics, Secretaría General de ISO, Ginebra, [16] ISO, ISO/IEC :1999 Information Technology Software Product Evaluation. Part 1: General Overview, Secretaría General de ISO, Ginebra, [17] Kitchenham Barbara, Pfleeger Sary, Software Quality: The Elusive Target, IEEE Software 12 (9), January, [18] McCall James et al, Factor in Software Quality. Vol. I, II, III: Final Technical Report, RADC-TR , Rome Air Development Center, Air Force System Command, Griffith Air Force Base, NY [19] PMI, Practice Standard for Work Breakdown Structures, Project Management Institute Inc, Pennsylvania, [20] PMI, A Guide to the Project Management Body of Knowledge, Project Management Institute Inc., Pennsylvania, 3th Edition, [21] Project Management Institute Inc., [last visited on ] [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, 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 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

7 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 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