6 Iram Iso Iec

ESQUEMA 1
DE NORMA IRAM-ISO/IEC
14598-6
2009
Tecnología de la información
Ingeniería de software
Evaluación del producto de software

Parte 6 - Documentación de los módulos de evaluación
Software engineering
Product evaluation
Part 6 - Documentation of evaluation modules
LAS OBSERVACIONES DEBEN
ENVIARSE CON EL FORMULARIO DE LA
ETAPA DE DISCUSIÓN PÚBLICA
DOCUMENTO EN ESTUDIO Noviembre de 2009

Error: Reference source not found IRAM 77013-3
2
Esq ue ma 1 I RA M- IS O/ I E C 14 59 8 -6 : E rro r: Re f e ren ce so u rce n ot f ou nd
Prefacio
El Instituto Argentino de Normalización y Certificación (IRAM) es
una asociación civil sin fines de lucro cuyas finalidades específicas,
en su carácter de Organismo Argentino de Normalización, son
establecer normas técnicas, sin limitaciones en los ámbitos que
abarquen, además de propender al conocimiento y la aplicación de
la normalización como base de la calidad, promoviendo las
actividades de certificación de productos y de sistemas de la
calidad en las empresas para brindar seguridad al consumidor.
IRAM es el representante de la Argentina en la International

Organization for Standardization (ISO), en la Comisión
Panamericana de Normas Técnicas (COPANT) y en la Asociación
MERCOSUR de Normalización (AMN).
Esta norma IRAM es el fruto del consenso técnico entre los

diversos sectores involucrados, los que a través de sus
representantes han intervenido en los Organismos de Estudio de
Normas correspondientes.
Se pretende que la IRAM-ISO/IEC 14598-6 sea utilizada en

conjunto con la IRAM-NM-ISO/IEC 9126-1:2009.
La norma IRAM-ISO/IEC 14598 consta de las siguientes partes

bajo el título general: Tecnología de la Información. Ingeniería de
Software. Evaluación del producto de software:
 Parte 1 - Descripción general.
 Parte 2 - Planificación y gestión.
 Parte 3 - Proceso para desarrolladores.
 Parte 4 - Proceso para compradores.
 Parte 5 - Proceso para evaluadores.
 Parte 6 - Documentación de los módulos de evaluación.
Los anexos A, B, C, D y E de esta parte de la ISO/IEC 14598

son únicamente informativos.
La presente norma IRAM es idéntica a la norma ISO/IEC 14598-6:

2001. Sólo se han agregado los anexos IRAM F Bibliografía
IRAM e IRAM G Lista de participantes, ambos informativos y una
nota IRAM en el Prefacio de la norma ISO, una nota IRAM en
el capítulo 3, una nota IRAM en el capítulo 4, y se modifico el
título para hacerlo compatible con la serie que estudia el
organismo de estudio.
4
E squ e ma 1 I RA M- I SO / IE C :
Prefacio de la norma ISO
ISO (Organización Internacional de Normalización) e IEC

(Comisión Electrotécnica Internacional) forman el sistema
especializado para la normalización a nivel mundial. Los
organismos nacionales que son miembros de la ISO o del IEC
participan en el desarrollo de normas internacionales a través de
comités técnicos establecidos por la organización respectiva
para ocuparse de los campos particulares de la actividad técnica.
Otras organizaciones internacionales, gubernamentales y no
gubernamentales, en coordinación con ISO e IEC, también
participan en el trabajo. Las normas internacionales se redactan
de acuerdo con las reglas establecidas en la Parte 3 de las
Directivas ISO/IEC.
En el campo de la tecnología de la información, ISO e IEC han

establecido un comité técnico común, ISO/IEC JTC 1. Los
proyectos de normas internacionales adoptados por el comité
técnico común se envían a los organismos nacionales para su
votación. La publicación como norma internacional requiere la
aprobación de por lo menos el 75% de los organismos
nacionales que votan.
Se recomienda prestar atención a la posibilidad de que algunos

elementos de esta parte de la ISO/IEC 14598-6 puedan estar
sujetos a derechos de patente. ISO e IEC no deben ser
consideradas responsables de la identificación de alguno o de
todos los derechos de patentes.
La norma internacional ISO/IEC 14598-6 fue elaborada por el

Comité Técnico Conjunto ISO/IEC JTC 1 Tecnología de la
información y el Subcomité SC 7 Ingeniería de software.
NOTA IRAM. A la fecha de publicación de este documento el subcomité

ISO/IEC JTC1/SC7 se denomina Ingeniería de software y sistemas.
Se pretende que la ISO/IEC 14598-6 sea utilizada en conjunto

con la ISO/IEC 9126-1:2001 la cual ha reemplazado a la
ISO/IEC 9126:1991.
La ISO/IEC 14598 consta de las siguientes partes bajo el título

general: Software engineering – Product evaluation:
 Part 1 - General overview.
 Part 2 - Planning and management.
 Part 3 - Process for developers.
5
Esq ue ma 1 I RA M- IS O/ I E C :
 Part 4 - Process for acquirers.
 Part 5 - Process for evaluators.
 Part 6 - Documentation of evaluation modules.
Los anexos A, B, C, y D de esta parte de la ISO/IEC 14598 son

únicamente informativos.
6
Esq ue ma 1 I RA M- IS O/ I E C 14 59 8 -6 : Error: Re fe re nc e source not found
Índice
Página
0 INTRODUCCIÓN..............................................................................................7
1 OBJETO Y CAMPO DE APLICACIÓN..............................................................8
2 CONFORMIDAD...............................................................................................8
3 NORMAS PARA LA CONSULTA.......................................................................8
4 TÉRMINOS Y DEFINICIONES..........................................................................8
5 EL CONCEPTO DE MÓDULO DE EVALUACIÓN............................................9
6 FORMATO PARA LA DOCUMENTACIÓN DE UN MÓDULO DE EVALUACIÓN

............................................................................................................................ 10
Anexo A (Informativo) Desarrollo de los módulos de evaluación.........................13
Anexo B (Informativo) Ejemplo de un módulo de evaluación – Densidad de fallas

............................................................................................................................ 14
Anexo C (Informativo) Ejemplo de un modulo de evaluación - Funcionalidad.....19
Anexo D (Informativo) Ejemplo de un módulo de evaluación - Facilidad de uso y

calidad en uso.....................................................................................................33
Anexo E (Informativo) Bibliografía.......................................................................40
Anexo F – IRAM (Informativo) Bibliografía..........................................................41
Anexo G – IRAM (Informativo) Integrantes de los organismos de estudio..........42
7
Tecnología de la información
Ingeniería de software
Evaluación del producto de software
Parte 6 - Documentación de los módulos de evaluación
0 INTRODUCCIÓN Identifica un conjunto mínimo de requisitos para

documentar y desarrollar los módulos de
evaluación.
La evaluación del producto de software
depende de un conjunto de técnicas y métricas Proporciona una herramienta necesaria para
de evaluación que proporcionan información recolectar y catalogar la gran cantidad de
sobre las características de calidad del módulos de evaluación previstos.
software. Para la evaluación de productos de
software específicos se pueden emplear Los módulos de evaluación proporcionan un
muchas métricas y métodos asociados para enfoque flexible y estructurado que permite que
utilizar los resultados de la medición. Las las métricas se puedan aplicar para evaluar
normas ISO/IEC 9126-2 e ISO/IEC 9126-3 productos intermedios y productos terminados.
proporcionan métricas de ejemplo que El uso de módulos de evaluación, elaborados
corresponden a una subcaracterística. Es difícil de acuerdo con esta parte de la
utilizar estas métricas con regularidad en una ISO/IEC 14598, ayuda a asegurar que las
organización. Puede ser necesario desarrollar evaluaciones de productos de software puedan
nuevas métricas para un uso específico. Por ser repetibles, reproducibles y objetivas.
ello, es necesario que una función de apoyo
(ver IRAM-ISO/IEC 14598-2) en la organización El formato para documentar un módulo de
especifique cada métrica para un uso correcto evaluación tiene en cuenta lo siguiente:
y regular dentro de la organización. Conviene
normalizar el formato para documentar una
 se aplica en el contexto de la evaluación de
métrica y los métodos asociados, así como las
productos de software,
guías para su uso. El concepto de módulo de
evaluación proporciona una solución para esta
 respalda la necesidad de desarrollar nuevas
necesidad.
métricas con respecto al estado del arte,
Un módulo de evaluación define los métodos
de evaluación aplicables para evaluar una  proporciona una definición precisa de las
característica de calidad e identifica la métricas y su aplicación, y
evidencia que necesita. También define el
procedimiento básico de evaluación y el  proporciona la información que necesitan
formato para informar las mediciones quienes la usarán para una evaluación.
resultantes de la aplicación de las técnicas.
El anexo A brinda una guía para el proceso de
Un modo sistemático de documentar módulos desarrollo de nuevos módulos de evaluación.
de evaluación tiene una cantidad de ventajas:
Los anexos B, C y D son ejemplos de módulos
Proporciona una referencia común para de evaluación.
describir la base teórica de los módulos de
evaluación.
8
1 OBJETO Y CAMPO DE APLICACIÓN ISO/IEC 12207 - Information technology –

Software life cycle processes.
NOTA IRAM. A la fecha de publicación de este documento
Esta norma define la estructura y el contenido está en estudio la IRAM-ISO/IEC 12207 Tecnología de la
de la documentación a utilizar para describir un información – Ingeniería de software - Procesos del ciclo
Módulo de Evaluación. Los módulos de de vida del software.
evaluación están pensados para ser empleados
IRAM-ISO/IEC 14598-1 - Tecnología de la
en el contexto de las normas ISO/IEC 9126 e
información. Ingeniería de software -
ISO/IEC 14598 de partes múltiples.
Evaluación del producto de software. Parte 1
-Descripción general.
Esta parte de la ISO/IEC 14598 tiene por
finalidad ser utilizada por expertos en
tecnología de evaluación, tales como los
información. Ingeniería de software. Evaluación
laboratorios de prueba, los institutos de
del producto de software. Parte 2 - Planificación
investigación y otros, cuando producen nuevos
y gestión.
módulos de evaluación.
2 CONFORMIDAD del producto de software. Parte 3 - Proceso
para desarrolladores.
La documentación de un módulo de evaluación
es conforme a esta norma si satisface los
requisitos del capítulo 6 (formato para la
del producto de software. Parte 4 - Proceso
documentación de un módulo de evaluación).
para compradores.
IRAM-ISO/IEC 14598-5, Tecnología de la

3 NORMAS PARA LA CONSULTA información. Ingeniería de software. Evaluación
del producto de software. Parte 5 - Proceso
para evaluadores.
Los siguientes documentos normativos
contienen disposiciones las que, por medio de
la referencia en este texto, constituyen
disposiciones de esta parte de la ISO/IEC 4 TÉRMINOS Y DEFINICIONES
14598. Para las referencias fechadas, no son
aplicables las enmiendas subsiguientes ni las
A los fines de esta norma, se aplican los
revisiones de ninguna de estas publicaciones.
términos y definiciones siguientes:
Sin embargo, se alienta a las partes que
establecen acuerdos basados en esta parte de
4.1
la ISO/IEC 14598 a investigar la posibilidad de
módulo de evaluación
aplicar las ediciones más recientes de los
paquete de tecnología de evaluación que se
documentos normativos indicados a
utiliza para medir las características,
continuación. Para las referencias sin fecha, es
subcaracterísticas o atributos de calidad del
aplicable la última edición del documento
software.
normativo citado. Los miembros de ISO e IEC
mantienen registros de las Normas NOTA. El paquete incluye:
Internacionales actualmente vigentes.
 métodos y técnicas de evaluación,
IRAM-NM-ISO/IEC 9126-1 - Tecnología de la
información - Ingeniería de software - Calidad  entradas para la evaluación,
del producto - Parte 1 - Modelo de calidad.  datos a medir y recolectar,
 procedimientos y herramientas de apoyo.
9
 favorecer el uso de módulos de evaluación

ya que la información estará disponible en
forma homogénea;
4.2
tecnología de evaluación (tecnología  favorecer la reutilización de módulos de
utilizada para la evaluación) evaluación ya que facilita el establecimiento
técnicas, herramientas, métricas, medidas y y mantenimiento de las bibliotecas de
cualquier otra información técnica usada para módulos de evaluación;
evaluar.
 favorecer la normalización de módulos de
[IRAM-ISO/IEC 14598-2] evaluación ya que el formato cumple con los
NOTA IRAM. Se han definido otros términos en las partes
requisitos de las normas.
restantes de la IRAM-ISO/IEC 14598, especialmente en la
parte 4, que incluye las definiciones de las partes Un módulo de evaluación reúne toda la
anteriores. información necesaria para realizar la
evaluación de un aspecto específico de una
característica de calidad, aplicando una técnica
5 EL CONCEPTO DE MÓDULO DE específica de evaluación. Aclara qué aspecto
EVALUACIÓN específico de una característica de calidad del
software se está midiendo. Se define el
procedimiento para hacer la medición así como
La evaluación de productos de software puede las condiciones previas y la exactitud de la
ser una tarea abarcativa. Diferentes aspectos misma.
de las características y subcaracterísticas de la
calidad pueden requerir la aplicación de Los módulos de evaluación proveen el vínculo
diferentes técnicas de evaluación y la entre las técnicas de evaluación, las métricas y
recolección de diferentes datos. Con el fin de las medidas. Cuando las partes 3, 4 y 5 de la
administrar esta complejidad, es conveniente ISO/IEC 14598 recomiendan la aplicación de
organizar una evaluación en unidades una técnica de evaluación, se puede
manejables. Cada una de estas unidades seleccionar un módulo de evaluación apropiado
puede cubrir uno o varios aspectos de la de una biblioteca de módulos de evaluación
calidad. Sin embargo, conviene que cada (ver ISO/IEC 14598-2).
unidad se centre en la evaluación de un
aspecto específico de la calidad, aplicando una La documentación de un módulo de evaluación
técnica específica de evaluación. Se tiene seis partes, EM0 - EM5 (EM por su sigla
recomienda reunir y empaquetar la información en inglés de “Evaluation Module”), para
necesaria para realizar una de dichas diferentes propósitos, y un anexo A opcional
evaluaciones, para su uso futuro. Un paquete EMA.
como éste se denomina módulo de evaluación.
EM0 proporciona información formal acerca del
Los beneficios de usar un formato normalizado módulo de evaluación y presenta una
de un módulo de evaluación son: introducción a la técnica de evaluación descrita
en el módulo de evaluación.
 favorecer el desarrollo de módulos de
evaluación ya que proporciona una tabla de EM1 define el alcance de la aplicabilidad del
contenidos lo que permite visualizar qué módulo de evaluación.
información es necesaria para una
evaluación y cómo se maneja esta EM2 proporciona las referencias más
información (principios, métricas, significativas.
herramientas);
EM3 incluye las definiciones necesarias para el
módulo de evaluación.
10
EM4 especifica los productos de entrada Este apartado debe identificar las
necesarios para la evaluación y define los características, subcaracterísticas o atributos
datos por recolectar y las medidas a calcular. que el módulo de evaluación puede evaluar.
EM5 contiene información sobre cómo NOTA. El módulo de evaluación puede contribuir a una o
interpretar los resultados de las mediciones. varias características o subcaracterísticas.
Se debe identificar el modelo de calidad que

El anexo opcional EMA incluye el
describe las características, subcaracterísticas
procedimiento detallado para aplicar el módulo
o atributos. Conviene emplear el modelo de
de evaluación. Si bien EMA es optativo se
calidad de la ISO/IEC 9126-1, salvo que exista
sugiere incluirlo.
una razón particular para utilizar otro modelo.
NOTA. El formato para la documentación de un módulo de
evaluación cumple con los requerimientos formales de 6.2.2 Nivel de evaluación
una norma tal como se describe en la Parte 3 de las
Directivas ISO. Ello facilita la normalización de los Este apartado debe describir el nivel de la
módulos de evaluación. evaluación definido por el módulo de
evaluación. Los niveles de evaluación están
relacionados con la importancia de la
6 FORMATO PARA LA característica, subcaracterísticas o atributo
DOCUMENTACIÓN DE UN MÓDULO DE evaluados. Es conveniente que el nivel se
EVALUACIÓN describa teniendo en cuenta el uso previsto del
software y el ambiente del producto de software
(por ejemplo, las condiciones de la seguridad
La documentación de un módulo de evaluación física, las restricciones a la seguridad de
debe estructurarse de acuerdo a los apartados acceso, los riesgos económicos y las
6.1, 6.2, 6.3, 6.4, 6.5, 6.6 y 6.7. restricciones para la aplicación).
6.1 EM0: Prefacio e introducción El nivel define la profundidad o la minuciosidad
de la evaluación en términos de las técnicas de
6.1.1 Prefacio evaluación por aplicar y los resultados de
evaluación por lograr. Diferentes niveles de
Este apartado debe proporcionar información evaluación generan niveles diferentes de
relativa a: confianza en la calidad del producto de
software.
 la preparación, aprobación, contribuciones y
cambios, NOTA. Los niveles se pueden formular como A, B, C o D
como se describe en la ISO/IEC 14598-5. Los niveles de
 la relación con otras normas u otros integridad del software se describen en la ISO/IEC 15026.
documentos.
6.2.3 Técnicas
6.1.2 Introducción
Este apartado debe describir las técnicas de
evaluación aplicadas por el módulo de
Es conveniente que este capítulo introduzca
evaluación. Se deben incluir o referenciar
principios, antecedentes y razones técnicas en
adecuadamente la teoría correspondiente, los
los que se basa el módulo de evaluación.
modelos o la heurística subyacentes a la
NOTA. En 6.2.3 se provee una descripción formal del
evaluación.
método de evaluación.
NOTA. Son ejemplos de técnicas de evaluación los
6.2 EM1: Alcance modelos de crecimiento de la fiabilidad, las pruebas
comparativas, el análisis estático del código.
6.2.1 Características 6.2.4 Aplicabilidad
11
plan de administración de la configuración, el plan de

Este apartado debe identificar el alcance de la pruebas del programa, y la descripción del lenguaje de
programación y del compilador. La información de apoyo
aplicación del módulo de evaluación. no se evalúa, sólo se utiliza como información de respaldo
necesaria para conducir la evaluación.
NOTA 1. Por ejemplo, el módulo de evaluación puede
aplicarse a un lenguaje particular de programación, o a la NOTE 4. La información clasificada como información del
clase de todos los lenguajes importantes. producto en uso incluye: el informe de pruebas y el
informe de operación que describe el comportamiento del
Se debe describir en qué punto del ciclo de sistema. El sistema incluye todo el hardware, el software y
vida del software puede utilizarse el módulo de los usuarios involucrados.
evaluación. Si se pretende emplearlo en un
6.5.2 Elementos de datos
proceso específico del ciclo de vida del
software, conviene identificar este propósito.
Este apartado debe especificar qué elementos
NOTA 2. Los procesos del ciclo de vida del software se de datos deben obtenerse a partir de las
describen en la ISO/IEC 12207. entradas.
6.3 EM2: Referencias NOTA 1. Ejemplos de elementos de datos son: la cantidad

de líneas del código que tienen observaciones; la
distribución de frecuencias de la longitud de la oración en
Este apartado debe proporcionar las el manual del usuario; la cantidad de palabras en cada
referencias a documentos normativos y mensaje de ayuda; la cantidad de fallas observadas por
técnicos. Si el módulo de evaluación depende hora de operación; la cantidad de componentes léxicos de
del resultado de otros módulos de evaluación, tipos especificados hallados en cada módulo por un
entonces éstos deben mencionarse aquí. escaneo léxico especificado.
NOTA 2. En general, los elementos de datos son el

6.4 EM3: Términos y definiciones material a partir del cual se realizan las mediciones. Pero
en algunos casos, los datos crudos pueden por sí sólos
Este apartado debe definir los términos constituir las métricas.
técnicos utilizados en el módulo de evaluación.
6.5.3 Métricas y medidas
Alternativamente, se deben citar las fuentes en
las que se pueden hallar las definiciones.
Este apartado debe describir cómo se calculan
las medidas a partir de los elementos de datos
6.5 EM4: Entradas y métricas
utilizando las métricas.
6.5.1 Entradas para la evaluación
Si las métricas se han de combinar para
obtener métricas de ”orden superior”, se debe
Este apartado debe identificar las entradas
explicitar la dependencia.
requeridas para la evaluación. Estas entradas
se deben clasificar como componente del
Se deben establecer todas las suposiciones y
producto, información del producto, información
las precondiciones a satisfacer antes de
de apoyo e información del producto en uso.
efectuar las mediciones.
NOTA 1. La información clasificada como componente del
producto incluye: la especificación de los requerimientos 6.6 EM5: Interpretación de los resultados
del software, la descripción del diseño del software, la
descripción del programa, el código fuente, el código 6.6.1 Mapa de las mediciones
ejecutable y la documentación del usuario.
NOTA 2. La información clasificada como información del Este apartado debe establecer el significado de
producto incluye: el informe de revisión de los las medidas, es decir, la interpretación de los
requerimientos del software, el informe de revisión del resultados de la medición. Esto incluye la escala
diseño del software, el informe de revisión del programa, de medición con la que se han de corresponder
el informe de pruebas unitarias, y el informe de revisión de
la documentación del usuario. los valores obtenidos por la métrica. Si la
correspondencia no es simple, se deben definir
NOTA 3. La información clasificada como información de los detalles de los algoritmos (funciones)
apoyo incluye: el plan de aseguramiento de la calidad, el
12
necesarios para hacer el mapa o se debe hacer propietarias); hardware/software necesarios;

referencia a sus fuentes. Si se obtienen varias entornos automatizados de prueba (“test-
medidas para una sola característica, harness”) u otros equipos; aptitudes y
subcaracterística o atributo, entonces el capítulo calificaciones (conviene identificar toda aptitud
debe describir cómo se las puede combinar en y calificación especial requerida por el
una escala para la característica, evaluador o la organización evaluadora, (por
subcaracterística o atributo. ejemplo, certificación)); esfuerzo de aplicación
Se debe especificar la exactitud de la medida. (conviene estimar el esfuerzo requerido para
una aplicación típica del módulo de evaluación
6.6.2 Informe y si este esfuerzo depende de atributos del
producto (por ejemplo, la cantidad de líneas de
Este apartado debe describir el contenido del código), conviene proporcionar un algoritmo
informe resultante de aplicar el módulo de estimativo); y todo otro recurso requerido.
evaluación. En algunos casos, la visualización
de los valores obtenidos es importante y 6.7.3 Instrucciones para la evaluación
conviene promover esta buena práctica.
Este apartado debe describir detalles
6.7 EMA: Procedimiento de aplicación completos del procedimiento a seguir. Es
conveniente que incluya la selección de
NOTA. La inclusión de EMA es optativa pero, si se evidencias (por ejemplo, muestreo de código),
incluye, debe tener el siguiente contenido: la generación y registro de datos sin procesar,
reglas de conteo, algoritmos para las métricas
6.7.1 Definición de los términos técnicos
de computación a partir de estos datos, el
utilizados
registro de los resultados, y los requisitos para
la retención de la documentación de trabajo y la
Este apartado debe definir los términos
final. En particular, conviene destacar los pasos
técnicos no definidos en 6.4, pero que se
a seguir para asegurar la trazabilidad y
utilizan en la parte EMA del módulo de
repetibilidad de los resultados. Es
evaluación, o las fuentes a las que hace
recomendable que el procedimiento descripto
referencia.
se realice en conformidad con la IRAM 301-
ISO/IEC 17025.
6.7.2 Recursos requeridos
6.7.4 Documentación
Este apartado debe especificar los recursos
requeridos cuando se aplica el módulo de
Este apartado debe destacar la documentación
evaluación. Se recomienda que incluya: las
interna que resulte del uso del módulo de
herramientas de software requeridas (es
evaluación. Se recomienda que el informe
conveniente identificar toda herramienta de
resumido sea realizado en conformidad con la
software requerida y citar tanto los tipos de
IRAM 301-ISO/IEC 17025.
herramientas genéricas como de herramientas
13
Anexo A
(Informativo)
Desarrollo de los módulos de evaluación
Este anexo informativo proporciona una orientación para el proceso de desarrollo de nuevos módulos
de evaluación. La ISO/IEC 9126 partes 2, 3 y 4 pueden servir como entrada para este proceso. Es
conveniente que el proceso de desarrollo de módulos de evaluación incluya cinco pasos:
A.1 Identificación de los requisitos del módulo de evaluación
Cuando se identifica la necesidad de un nuevo módulo de evaluación y se toma la decisión de

desarrollarlo, es conveniente que el primer paso consista en identificar los requerimientos para el
nuevo módulo de evaluación. Esto incluye identificar un modelo de calidad y las características o
subcaracterísticas de calidad. También es recomendable que se decida cuál será la rigurosidad de la
evaluación.
A.2 Especificación del módulo de evaluación
Basado en los requerimientos identificados para el módulo de evaluación, el próximo paso consiste
en especificar las técnicas de evaluación y las entradas para la evaluación (por ejemplo, el código
fuente) así como el conjunto de métricas y el conjunto fundamental de elementos de los datos. En
este caso pueden ser útiles las partes 2, 3 y 4 de la ISO/IEC 9126.
A.3 Desarrollo del procedimiento de evaluación
Este paso toma la especificación formal del paso anterior y agrega algunos aspectos de
procedimiento. Se recomienda que la interpretación de las métricas y de los elementos de los datos
se expliquen en el contexto de la evaluación. Es conveniente estimar los recursos requeridos y
elaborar procedimientos detallados de evaluación. Puede ser necesaria la aplicación de pruebas del
procedimiento de evaluación.
A.4 Descripción del procedimiento de evaluación
En este paso es recomendable que el procedimiento de evaluación desarrollado en el paso anterior

se describa de acuerdo con el formato de módulo de evaluación, es decir, es conveniente que la
descripción esté conforme con esta parte de la ISO/IEC 14598.
A.5 Verificación y validación del módulo de evaluación
Se recomienda que el módulo de evaluación se revise (verifique) con respecto a su especificación.

Es conveniente que esto lo realicen los expertos en la técnica de evaluación descrita. Es
recomendable que la validación asegure que el módulo de evaluación represente el estado del arte
de la tecnología y la tecnología existente, aunque no sea conocida por la organización.
Conviene que diferentes grupos de personas en diferentes ambientes ensayen (validen) el módulo de
evaluación. Se recomienda transmitir la experiencia adquirida al equipo de desarrollo del módulo de
evaluación como entrada para una actualización.
14
Anexo B
(Informativo)
Ejemplo de un módulo de evaluación – Densidad de fallas
Tecnología de la información – Evaluación del producto de software – Módulo de Evaluación:

Densidad de fallas
B.0 Introducción
Este módulo de evaluación se utiliza para determinar la densidad de fallas de un programa. Detectar
una cantidad elevada de fallas durante el diseño y la fase de prueba reduce posibles fallas en el
software que provocarán errores en la fase de operación. Un número elevado de fallas al comienzo
de las fases de operación provoca errores frecuentes y disminuye la fiabilidad del producto. Por ello,
es conveniente asegurar que la densidad de fallas esté por debajo de un valor de umbral
especificado antes que el programa se ponga en funcionamiento.
En general, es imposible contar la cantidad de fallas que permanecen en un producto de software.

Pero utilizando el modelo y los datos históricos de detección de fallas, se puede estimar la cantidad.
La densidad de fallas se calcula utilizando este valor. El procedimiento general de estimación se
describe a continuación:
1) Se elige un Modelo de Crecimiento de la Fiabilidad (RGM por sus siglas en inglés (Reliability
Growing Model) adecuado, por ejemplo, un RGM exponencial o un S-shaped RGM.
2) Se registra el número acumulado de fallas detectadas con el tiempo en un punto particular del
período de prueba.
3) Se decide acerca del número de parámetros de la ecuación RGM que se requiere para ajustar la
curva al conjunto de datos registrados.
4) Cuando el tiempo (t) de la ecuación RGM tiende a infinito, se puede calcular el número estimado
de posibles fallas.
B.1 Alcance
B.1.1 Características
Fiabilidad - Madurez – Densidad de fallas
B.1.2 Nivel de evaluación
Nivel B tal como se define en IRAM-ISO/IEC 14598-5.
B.1.3 Técnica
Se utiliza una técnica de modelado del crecimiento de la fiabilidad. El número de fallas en el producto
de software final se predice utilizando el modelo de crecimiento de la fiabilidad.
B.1.4 Aplicabilidad
1) Se utiliza generalmente durante la prueba del sistema y se aplica a todos los tipos de lenguajes
de programación.
2) Cuando es necesario comparar el valor de densidad de fallas con otro valor para un programa
escrito en un lenguaje de programación diferente, conviene normalizar los valores del tamaño.
B.2 Referencias
B.3 Términos y definiciones
Se aplican las siguientes definiciones al módulo de evaluación:
Falla
defecto en el software.
Error
cualquier ocurrencia de un evento (o no ocurrencia de algunos eventos) normalmente a partir de un
conjunto de eventos definidos.
LOC (en inglés Lines of Code) Líneas de código

número de líneas del código.
ELOC (en inglés Erroneous Lines Of Code) Líneas erróneas del código
número de líneas del código, en las que se detecta una falla y se la modifica.
EELOC (en inglés Estimated Erroneous Lines Of Code) Líneas erróneas del código estimadas
número estimado de líneas erróneas del código (ELOC).
NCLOC (en inglés Non-Commented Lines Of Code) Líneas del código sin comentarios
número de líneas del código sin comentarios.
FDV (en inglés Fault Density Value) Valor de densidad de fallas

valor que indica el número de fallas por unidad de volumen del producto.
B.4 Entradas y métricas
B.4.1 Entrada para la evaluación
Las siguientes fuentes se utilizan como entrada para la evaluación:
1) Componente del producto: Código fuente.
2) Información del producto: Informe de prueba del programa, Informe de revisión del programa,
Informe de verificación del programa.
B.4.2 Elementos de los datos
Para aplicar la técnica de evaluación se deben recolectar los elementos de los datos siguientes:
1) El número de fallas detectadas (ELOC).
16
2) Tiempo detectado de cada falla. El tiempo debe medirse de manera congruente, por ejemplo,
tiempo de unidad central de procesamiento (CPU) o tiempo calendario.
3) Número de líneas del código (NCLOC).
B.4.3 Métricas y medidas
El valor de la densidad de fallas se calcula a partir de:
FDV = (EELOC - ELOC) / NCLOC
B.5 Interpretación de los resultados
B.5.1 Mapeo de medidas
FDV (No se realiza mapeo de las métricas en este caso).
Fuente experimental de escala dentro de la compañía:
FDV<=10E-4 Excelente
10E-4<FDV<=10E-3 Bueno
10E-3<FDV<=10E-2 Regular
FDV>10E-2 Pobre
AVISO: Los valores del umbral deben adaptarse de acuerdo con la fase o el dominio del software
aplicado.
B.5.2 Informe
Se suministra la siguiente información como resultado de aplicar el módulo de evaluación:
1) Identificación del código fuente
2) Valor de densidad de fallas: FDV
3) La puntuación correspondiente {Excelente, Buena, Regular, Pobre}
B.6 Procedimiento de aplicación
B.6.1 Definición de los términos técnicos utilizados
RGM (Reliability Growing Model)

modelo de crecimiento de la fiabilidad. El modelo de crecimiento de la fiabilidad utilizado para estimar
el número de líneas erróneas del código.
B.6.2 Recursos requeridos
Los siguientes recursos deben estar disponibles cuando se aplica el módulo de evaluación:
Herramientas del software requeridas:

1) Herramienta de conteo de LOC
2) Herramienta de conteo de líneas modificadas
3) Herramienta de recolección de datos de fiabilidad y herramienta de análisis (optativa)
Plataforma del hardware/software
No hay requerimientos especiales.
Entornos automatizados de prueba u otros equipos
No hay requerimientos especiales, pero se recomienda el uso de una herramienta para la re-
colección de datos de fiabilidad y para su análisis.
Aptitudes y calificación
Se requiere conocimiento en la aplicación de RGM.
Esfuerzo de mano de obra de la aplicación
La mayor parte del esfuerzo está relacionado con probar y registrar las fallas. Si se aplica una
herramienta de fiabilidad y recolección de datos, la aplicación del RGM y el cálculo de FDV sólo
requiere un esfuerzo limitado.
Otros recursos especiales
No hay requerimientos especiales.
B.6.3 Instrucciones para la evaluación
1) Selección de la muestra
Se selecciona una muestra del código fuente. Es conveniente que la proporción del muestreo sea
mayor que la mitad.
2) Generación de datos crudos
Los datos del error se extraen de los informes de prueba. Si no se dispone de informes de prueba, se
realiza la prueba. Para aplicar el modelo de crecimiento de la fiabilidad RGM se requiere un mínimo
de XXX tiempo de prueba.
Para cada falla, se registra la ubicación y el tiempo de ocurrencia.
Se cuenta el ELOC modificado con el tiempo de modificación y el NCLOC total de cada muestra.
3) Algoritmo
Se estima el número de posibles LOC erróneos utilizando el modelo de crecimiento de la fiabilidad

RGM. Se encuentra el número estimado de líneas erróneas del código aplicando el modelo RGM.
EELOC = RGM-({(Falla, Tiempo)})
18
Se calcula el valor de la densidad de fallas:
FDV = (EELOC - ELOC) / NCLOC
AVISO: En este punto se debe explicar con todo detalle cómo utilizar el modelo o herramienta RGM o
bien se deben proveer referencias correspondientes a una herramienta y manual de software para
realizar el cálculo.
4) Requerimientos para la retención del documento de trabajo y del documento final
Se mide una vez por semana, y se analiza la tendencia durante la fase de prueba.
Acción: Si el valor calculado de la densidad de fallas es superior a algún valor especificado

(puntuación = pobre), se revisa, se reensaya y se eliminan las fallas del código fuente y se vuelve a
calcular la densidad de fallas.
B.6.4 Documentación (Interna)
Se registra la información siguiente para constituir la documentación interna:
1) Identificación y versión de la muestra del código fuente
2) Identificación y versión de la documentación de prueba
3) El conjunto de fallas utilizado para estimar el EELOC
4) La fecha de aplicación y la persona responsable

Anexo C
(Informativo)
Ejemplo de un modulo de evaluación - Funcionalidad
Tecnología de la información – Evaluación del producto de software – Módulo de Evaluación:

Funcionalidad
C.0 Introducción
Este módulo de evaluación se utiliza para determinar la funcionalidad de un sistema/componente de

software, entendiéndose por funcionalidad hasta qué punto el componente de software proporciona
funciones que cumplen las necesidades expresadas o implícitas bajo condiciones especificadas.
Una correcta evaluación es posible si existe una definición bien documentada de los requerimientos
del software/sistema y si las necesidades expresadas están bien descritas. En todos los casos, la
evaluación considerará cómo se documenta.
La IRAM-NM-ISO/IEC 9126 define la funcionalidad en términos de subcaracterísticas, tal como se

describe en los párrafos siguientes. Cada subcaracterística es mensurable a través de la medida de
más sub ítems.
Los ítems elementales descritos en este documento para cada subcaracterística compondrán un
nivel aproximado para definir el valor de la subcaracterística. No existe actualmente una fórmula para
esta evaluación y la adopción de una norma emergente dará confianza en que el trabajo tendrá una
aceptación general en el contexto de su aplicación.
El modelo de calidad pertinente a este módulo de evaluación considera más de una métrica para
cada ítem elemental correspondiente a cada subcaracterística. Las métricas para cada ítem
elemental por medir se describen en las “listas de control” con (s/n/d) respuesta posible para cada
pregunta: s significa sí, n significa no y d significa descartar por no ser aplicable.
La respuesta s/n a una pregunta está relacionada con la comparación entre el valor de la métrica y
un valor esperado: si el valor medido es igual o mejor que el valor esperado entonces la respuesta es
sí, en caso contrario la respuesta es no.
La característica funcionalidad se ha de evaluar aplicando las reglas siguientes:
Vc = Ʃ Vsci / nsc
|Vscj| = Ʃ mi / (n-nd)
Vc es el valor medido de la característica;
Vsci es el valor medido de la subcaracterística i;
nsc es el número de subcaracterísticas;
mi es 1 si la respuesta-i es positiva, en caso contrario es 0;
n es el número total de medidas;
20
nd es el número de preguntas descartadas.
C.1 Alcance
C.1.1 Características
Las métricas de funcionalidad indican si el componente de software satisface los requerimientos

definidos. El componente de software también debe satisfacer las necesidades implícitas del usuario,
es decir, los requerimientos implícitos para la tipología del componente de software bajo evaluación.
Las métricas de funcionalidad incluyen indicadores para 5 subcaracterísticas:
 adecuación;
 exactitud;
 interoperabilidad;
 conformidad;
 seguridad de acceso;
Las métricas de adecuación miden la relación entre las funciones satisfechas durante la realización
de las pruebas y operaciones del usuario, y las funciones requeridas; es decir, las funciones que
realizan tareas que no se ajustan a los requerimientos documentados.
Las métricas de exactitud miden la precisión:
 el margen del error de cálculo;
 la diferencia entre los resultados reales y los esperados de la tarea realizada;
 discrepancia entre el procedimiento de operación real y el procedimiento documentado (por

ejemplo, en los manuales).
Las métricas de interoperabilidad miden el nivel de comunicación del componente de software con
otros sistemas y/o productos de software y/o equipos:
 capacidad de transferencia de datos;
 capacidad de intercambio de comandos.
Las métricas de conformidad miden el nivel de normalización del componente de software con
respecto a la reglamentación o las reglas del ambiente.
Las métricas de seguridad miden el nivel de desempeño de la defensa contra el acceso ilegal y/o las
operaciones ilegales.
C.1.2 Nivel de evaluación

El anexo B (informativo) de la ISO/IEC 14598-5 describe los criterios para la selección del nivel de
evaluación.
La criticidad de la característica medida en este módulo con respecto a diferentes aspectos

(seguridad, economía) influye en la definición de la exactitud de la evaluación, la definición de la
cantidad de medidas por realizar y las técnicas por utilizar. La pregunta que determina el nivel de
evaluación es: si la “funcionalidad” no cumple los requerimientos, ¿qué clase de problema existe?
La siguiente tabla indica los niveles y las condiciones para cada nivel, considerando:
 aspectos de seguridad física;
 aspectos de economía;
 aspectos de seguridad;
 aspectos ambientales.
La elección del nivel se debe hacer adoptando, como mínimo, el nivel más alto que resulte del aná-
lisis de cada aspecto.
Aspectos de Aspectos de Aspectos

Niveles Aspectos de economía
seguridad física seguridad ambientales
desastre financiero (la compañía no protección de datos y daño irrecuperable al

A muere mucha gente
sobrevive) servicios estratégicos medio ambiente
amenaza para vidas gran pérdida económica (compañía protección de datos y daño recuperable al medio
B
humanas comprometida) servicios críticos ambiente
daño a la propiedad, poca pérdida económica protección contra riesgo de

C contaminación local
gente herida significativa(compañía afectada) error
C.1.3 Técnica
La siguiente tabla indica las técnicas de evaluación adoptadas para evaluar la FUNCIONALIDAD,
comenzando por la fila correspondiente al nivel elegido e incluyendo las técnicas de los niveles
inferiores; es decir, si el nivel de evaluación adoptado es el B, se aplican todas las técnicas desde el
nivel elegido hasta el nivel D.
Técnicas de evaluación para la FUNCIONALIDAD

Nivel A Comprobaciones formales (no existen actualmente técnicas adecuadas para la
evaluación de la FUNCIONALIDAD en el nivel A)
Nivel B pruebas de componente (prueba de caja blanca)
Nivel C revisiones, inspecciones de código
Nivel D pruebas funcionales (prueba de caja negra)
La siguiente es una descripción introductoria de las posibles técnicas indicadas en la tabla.
Comprobaciones formales
22
El método más común de probar programas es el método de aseveraciones inductivas. La meta es el
desarrollo de un conjunto de teoremas sobre el componente de software bajo evaluación. El método
comienza escribiendo afirmaciones sobre las condiciones de entrada del componente de software y
los resultados correctos. Se requiere una prueba por separado para comprobar que el programa
siempre terminará. Otras técnicas de prueba son los métodos de transformador de predicados,
inducción de la sub meta, inducción del cálculo, inducción estructural y aseveraciones intermitentes.
En el futuro, este módulo de evaluación será ampliado para cubrir este nivel de evaluación, pero
actualmente este nivel para la FUNCIONALIDAD no es mensurable.
Pruebas de componente
Cada componente del software se prueba con respecto a los requerimientos. También se prueba en
relación con los componentes de software completamente integrados.
Prueba de caja blanca
Esta técnica permite examinar la estructura interna del componente de software: la persona que
realiza la prueba establece los datos de prueba a partir del examen de la lógica del programa.
La prueba de caja blanca se relaciona con el grado con el que los casos de prueba ejercen o cubren
la lógica (código fuente) del programa. Un criterio de cobertura útil es la cobertura de sentencias, es
decir, requerir que cada sentencia en el programa se ejecute al menos una vez. Los criterios de
cobertura de la lógica más estrictos son: cobertura de caminos, cobertura de decisiones, cobertura
de condiciones, cobertura de decisión/condición y cobertura de condiciones múltiples.
Revisiones
Proceso que consiste en la inspección/análisis visual de los componentes del software y toda la
documentación pertinente.
Inspecciones del código
Las inspecciones del código consisten en la lectura o inspección visual de un componente de

software. El objetivo es hallar errores, pero no encontrar soluciones a los errores. Sin embargo, esta
técnica no permite encontrar errores de alto nivel, tal como errores en el diseño. La inspección del
código debe considerarse complementaria a la inspección basada en la computadora, tal como el
análisis estático del código.
Listas de control
La actividad de revisión se basa en una lista de control definida que permite repetir la actividad con
pocos criterios subjetivos. Las preguntas en la lista de control deben ser lo más simples posibles; el
objetivo de la pregunta debe ser información elemental. Las listas de control están sujetas a revisión,
integración y eliminación en función de la experiencia de la aplicación.
Análisis estático del código
Es posible deducir la existencia de errores (potenciales) en el software, analizando su código fuente.

Un tipo de análisis estático es el flujo de control en el cual el código fuente se subdivide en
segmentos y se examina la relación entre los segmentos para verificar, por ejemplo, que no haya
segmentos que no puedan ejecutarse o que no haya caminos que no alcancen una sentencia de
STOP.
Otro tipo de análisis se relaciona con el gráfico de llamada o estructura del sistema de software que
describe la anidación de todas las unidades de software.
Pruebas funcionales
Este es un proceso que trata de encontrar las discrepancias entre el producto de software y su
especificación externa. Se analiza la especificación para derivar un conjunto de casos de prueba.
Esto es importante para la correcta definición de los casos de prueba y para aplicar técnicas y
métodos específicos (particiones o clases de equivalencia, análisis de valores límites, diagrama de
causa-efecto, métodos de conjetura de errores).
Prueba de caja negra
El software es visualizado como una caja negra, es decir, no interesa el comportamiento interno ni la
estructura del programa. La persona que realiza la prueba sólo está interesada en encontrar
situaciones en las que el programa no se comporte de acuerdo con sus especificaciones. Si no se
llevan a cabo pruebas adecuadas y exhaustivas, será necesario definir casos de prueba adecuados.
C.1.4 Aplicabilidad
El alcance de este módulo de evaluación es determinar la medida de funcionalidad para el producto

de software bajo evaluación. Este módulo de evaluación se aplica cuando están presentes dos tipos
de condiciones:
 condición concerniente al requerimiento para el proceso de evaluación:
Aplicable cuando se satisfacen los requisitos específicos para el proceso de evaluación de la

característica bajo evaluación (requerimientos del software para la funcionalidad).
 condición concerniente a la documentación de entrada para la evaluación:
Aplicable a la disponibilidad de la documentación de entrada para el proceso de evaluación.
Requerimiento para el proceso de evaluación:
Requerimientos del software para la funcionalidad
ADECUACION
 Se deben documentar todos los requerimientos funcionales.
 Se debe describir en la documentación la arquitectura del hardware del producto.
 Se debe describir en la documentación la arquitectura del software del producto.
 Se deben definir todas las entradas, procesamientos y salidas.
 Se deben identificar claramente los componentes del software entregados al laboratorio para su
evaluación como componentes del software bajo evaluación.
 Se deben identificar todos los requerimientos para probar el hardware/software.
24
 Se deben documentar los resultados de las pruebas realizadas.
 Se deben establecer completamente las especificaciones de las pruebas.
 Todos los componentes del diseño deben ser trazables con respecto a los requerimientos
funcionales.
 Se debe describir el ambiente hardware/software.para cada prueba.
EXACTITUD
 Los programas y datos deben estar libres de contradicciones entre sí y con respecto a la
documentación.
 Se deben poder ejecutar de manera completa y correcta todas las funciones mencionadas en la
documentación del software.
SEGURIDAD DE ACCESO
 Se deben definir los requerimientos de la seguridad de acceso.
 Se deben identificar todas las amenazas, objetivos y funciones que fuerzan la seguridad de
acceso.
 Las funciones que refuerzan la seguridad de acceso deben cumplir los objetivos de seguridad.
NOTA. La lista de requerimientos necesita integrarse con requerimientos específicos para el producto de software bajo
evaluación.
Documentación de ENTRADA para la evaluación:
Aplicable a la disponibilidad de la documentación de entrada para el proceso de evaluación
La tabla que está a continuación describe los documentos/componentes necesarios para el proceso
de evaluación para cada nivel de evaluación. También, la tabla indica cuándo, en un ciclo de vida
genérico del software, se puede utilizar el módulo de evaluación.
En la tabla, todo lo definido para un nivel es válido para los niveles inferiores.
Fase aplicable del

Componentes de software, Requerimientos
documentación requerida ciclo de vida del para la evaluación
software
Nivel A Informe de la revisión de Durante todas las No aplicable
requerimientos del software, informe fases del ciclo de vida
de la verificación de los del software
requerimientos del software, informe
de la medición de los requerimientos,
informe de la revisión del diseño del
software, informe de la verificación del
diseño del software, informe de la
medición del diseño, informe de la
revisión de la documentación del
usuario, descripción de los métodos y
herramientas de la especificación del
software, descripción de los métodos
y herramientas del diseño, descripción
del lenguaje de programación y de los
compiladores.
Nivel B Informe de revisión del programa, Durante todas las Cooperación con el
informe de verificación del programa, fases del ciclo de vida “desarrollador”
informe de medición del programa, del software durante las
plan de pruebas del programa, actividades de prueba
informe de pruebas del programa, (7), disponibilidad del
plan de prueba unitaria, informe de “ambiente objetivo” en
prueba unitaria, análisis de el que se ejecuta el
requerimientos del sistema, código instrumentado,
especificación y diseño del sistema, disponibilidad de
plan de prueba del sistema, plan de intercambio de
gestión de la configuración, informe información entre el
de gestión de la configuración, plan “ambiente de
de aseguramiento de la calidad, evaluación” y el
informe de aseguramiento de la “ambiente objetivo”.
calidad
Nivel C Código fuente, descripción del Luego de la fase de Código fuente escrito
lenguaje de programación y de los desarrollo del software en lenguaje C (6),
compiladores, especificación de cooperación con el
requerimientos del software (5), “desarrollador”
descripción del diseño del software, durante el proceso de
informe de revisión del sistema, revisión
informe de verificación del sistema,
plan de pruebas del sistema, informe
de pruebas del sistema.
Nivel D Producto ejecutable (1), descripción Antes de la entrega
del producto (2), manual del usuario del producto
(3), manuales del sistema, casos de
prueba (4)
(1) Esto significa ejecutar el producto en el ambiente de evaluación o bien tener acceso al ambiente objetivo con la
posibilidad de ejecutar el producto en dicho ambiente.
26
(2) La descripción del producto es una recopilación de información sobre qué espera el usuario del producto. Puede tener
la forma de carátula del producto o requerimientos del usuario u otra información.
(3) El manual del usuario es una recopilación de información sobre cómo utilizar el producto de software. Puede también
tener la forma de información interactiva, con o sin soporte en papel.
(4) Los casos de prueba incluyen los datos y los resultados de las pruebas. El proceso de evaluación utilizará dicha
información pero no se limita sólo a ella.
(5) La especificación de requerimientos del software es una colección de los requerimientos esenciales: requerimientos
funcionales, restricciones de eficiencia (“performance”) para diseño del software y sus interfaces externas.
(6) La restricción del lenguaje del código fuente se debe a la disponibilidad para el laboratorio del parseador (o pre compilador,
o intérprete) para el lenguaje especificado. Es una restricción temporal, ampliada a otros lenguajes cuando el laboratorio no
puede disponer del parseador correspondiente.
(7) desarrollador en este contexto es la organización que desarrolló el producto de software.
Para una descripción detallada sobre la documentación indicada en la tabla, consultar la IRAM-
ISO/IEC 14598-5.
C.2 Referencias
C.3 Términos y definiciones
C.4 Entradas y métricas
C.4.1 Entrada para la evaluación
La siguiente es la mínima documentación de entrada para cada nivel de evaluación. Para información
más detallada sobre el contenido de los documentos ver la IRAM-ISO/IEC 14598-5.
Los títulos de los documentos son indicativos; pueden cambiar dependiendo de la documentación
interna/ estándar en el ambiente de desarrollo. Se recomienda que el contenido requerido, tal como
se describe en la parte 5 de la IRAM-ISO/IEC 14598, se integre/describa en documentos similares.
Es conveniente contar con una referencia cruzada que indique dónde se necesita la información para
la evaluación.
Entrada para el nivel A de evaluación
Informe de la revisión de los requerimientos del software, informe de la verificación de los

requerimientos del software, informe de la medición de los requerimientos, informe de la revisión del
diseño del software, informe de la verificación del diseño del software, informe de la medición del
diseño, informe de la revisión de la documentación del usuario, descripción de los métodos y
herramientas de la especificación del software, descripción de los métodos y herramientas del
diseño, descripción del lenguaje de programación y de los compiladores.
Informe de revisión del programa, informe de verificación del programa, informe de medición del
programa, plan de pruebas del programa, informe de pruebas del programa, plan de pruebas
unitarias, informe de pruebas unitarias, análisis de requerimientos del sistema, especificación y
diseño del sistema, plan de pruebas del sistema, plan de gestión de la configuración, informe de
gestión de la configuración, plan de aseguramiento de la calidad, informe de aseguramiento de la
calidad.
Código fuente, descripción del lenguaje de programación y de los compiladores, especificación de
requerimientos del software, descripción del diseño del software, informe de revisión del sistema,
informe de verificación del sistema, plan de pruebas del sistema, informe de pruebas del sistema.
Producto ejecutable, descripción del producto, manual del usuario, manuales del sistema, casos de
prueba.
Entrada para el nivel B de evaluación
Informe de revisión del programa, informe de verificación del programa, informe de medición del
programa, plan de pruebas del programa, informe de pruebas del programa, plan de pruebas
unitarias, informe de pruebas unitarias, análisis de requerimientos del sistema, especificación y
diseño del sistema, plan de pruebas del sistema, plan de gestión de la configuración, informe de
gestión de la configuración, plan de aseguramiento de la calidad, informe de aseguramiento de la
calidad.

prueba.
Entrada para el nivel C de evaluación

prueba.
Entrada para el nivel D de evaluación
prueba.
C.4.2 Elementos de datos
La información a extraer de los documentos de entrada es de dos tipos:
 información para el proceso de evaluación, por ejemplo, lista de requerimientos;
 información útil para entender el sistema.
El primer tipo de información son los datos para el proceso de evaluación; este tipo de datos se
describe a continuación de cada métrica que se utiliza.
El segundo tipo de información no está sujeto a evaluación; puede constar de varios documentos
informales que el desarrollador proporciona al evaluador; es parte de la documentación de
evaluación (por ejemplo, fax, mails, etc.). Es conveniente que los evaluadores conserven estos
28
documentos junto con el resto de la documentación (a saber, informes de trabajo correspondientes a
actividades de medición).
En este módulo de evaluación, el apartado 4.2 Elementos de datos, está definido a nivel general.
Para módulos de evaluación en niveles inferiores, es decir, un módulo de evaluación para una
métrica (densidad de fallas), es conveniente que este apartado sea más descriptivo y preciso.
C.4.3 Métricas y mediciones
Lo que sigue es la descomposición de la característica FUNCIONALIDAD en subcaracterísticas y

para cada subcaracterística se indica la métrica a utilizar para la evaluación.
Métricas para la CONFORMIDAD
Ratio de conformidad con los estándares del (proyecto de) desarrollo de software
La razón entre el número de reglas relacionadas con los estándares de desarrollo del proyecto
correctamente aplicadas, y el número total de reglas estándares de desarrollo de software.
Ratio de conformidad con los estándares de documentación (del proyecto)
La razón entre las reglas, correctamente aplicadas, relacionadas con estándares de documentación
del proyecto y el número total de reglas de estándares de documentación del proyecto.
Ratio de estandarización del formato de datos.
La razón entre los formatos de datos estandarizados y los formatos de datos a estandarizar.
Ratio de caracteres estandarizados.
La razón entre los caracteres gráficos y de control estandarizados y aquellos por estandarizar.
Métricas para la ADECUACIÓN
Ratio de funciones disponibles
La razón entre las funciones que efectivamente se encuentran a disposición del usuario y el número
total de funciones especificadas.
Ratio de cambios de la especificación funcional
La razón entre la cantidad de funciones que deben cambiarse (cambio incluye agregado,
modificación y eliminación) luego de entrar en operación (prueba en la operación) y el número total
de funciones especificadas.
NOTA. Función especificada es la función que está definida en las especificaciones de requerimientos o que es provista por
un software en operación o está descripta en el manual del usuario como funciones disponibles.
Ratio de precisión en la definición de la Entrada-Salida
La razón entre los datos de entrada-salida claros y correctamente definidos, y el número total de
entradas-salidas.
Ratio de documentación del proyecto

La razón entre los documentos del proyecto disponibles con el producto y el número total de
documentos del proyecto requeridos.
Ratio de documentación del producto
La razón entre los documentos del producto disponibles con este respecto del número total de
documentos del producto requeridos.
Métricas para la EXACTITUD
Ratio de dígitos significativos
La razón entre los dígitos significativos implementados y los dígitos significativos requeridos para los
ítems de datos que requieren una exactitud específica.
Ratio de Tamaño de código
La razón entre el tamaño real del código y el tamaño requerido del código.
Ratio de Corrección
La proporción de datos obtenidos con el grado de precisión necesario respecto de los datos
esperados.
Métricas para la INTEROPERATIVIDAD
Ratio de comunicaciones
La proporción de comunicaciones de red que cumplen las normas de comunicación de red.
La razón entre el vocabulario técnico habitual del sistema y todos los sistemas inter operativos.
Ratio de formatos de datos apareados
La proporción de formatos de datos que concuerdan con los de los otros sistemas inter operativos
involucrados.
Ratio de caracteres apareados
La razón entre los caracteres gráficos y caracteres de control que concuerdan y los de los otros
sistemas que inter operan.
Métricas para la SEGURIDAD DE ACCESO
Ratio del control de acceso al software
La proporción de los accesos al software no autorizados y el número de intentos de acceso.
Ratio del control de acceso a los datos
30
La proporción de accesos/cambios de datos no autorizados y el número de intentos.
Ratio de datos cifrados
La razón entre los datos cifrados y los datos por ser cifrados.
Ratio de historia de acceso
La razón entre los registros de información confidencial, que tienen historias de accesos, y todos los
registros de información confidencial. Las historias de acceso contienen información sobre quién,
cuándo y a cuál de los registros de información confidencial se accedió.
Corrupción de datos
Frecuencia de la alteración de datos durante la operación.
Ratio de operación anormal detectada
La razón entre los intentos de operaciones ilegales detectadas y el total de operaciones ilegales de
ingreso al sistema efectivizadas.
C.5 Interpretación de resultados
C.5.1 Mapeo de medidas
La escala de evaluación para cada subcaracterística de FUNCIONALIDAD está relacionada con el

porcentaje de respuestas positivas a las preguntas presentadas previamente (ver la Introducción). A
continuación se indican los valores esperados para cada subcaracterística y el correspondiente valor
obtenido. El valor obtenido para cada subcaracterística es la entrada a la “fórmula” para la evaluación
de la característica FUNCIONALIDAD.
Conformidad Adecuación Exactitud Inter-operabilidad Seguridad de

acceso
Valores esperados Más del 25% de Más del 70% de Más del 70% de Más del 70% de Más del 70% de
respuestas positivas respuestas positivas respuestas positivas respuestas positivas respuestas positivas
Valores obtenidos Valores evaluados Valores evaluados Valores evaluados Valores evaluados Valores evaluados
para Conformidad para Adecuación para Exactitud para Inter- para Seguridad de
operabilidad acceso
1 (pobre) [ 0 .. 0,25] [ 0 .. 0,70] [ 0 .. .0,70] [ 0 .. 0,70] [ 0 .. 0,70]

2 (regular) [ 0,26 .. 0,50] [ 0,71 .. 0,80] [ 0,71 .. 0,80] [ 0,71 .. 0,80]
[ 0,71 .. 0,80]
3 (bueno) [ 0,51 .. 0,75] [ 0,81 .. 0,90] [ 0,81 .. 0,90] [ 0,81 .. 0,90]
[ 0,81 .. 0,90]
4 (excelente) [ 0,76 .. 1] [ 0,91 .. 1] [ 0,91 .. 1] [ 0,91 .. 1]
[ 0,91 .. 1]
Comenzando por el valor estimado de la subcaracterística, la siguiente es la fórmula para la

FUNCIONALIDAD.
Valor para la FUNCIONALIDAD:
Vc = Ʃ Vsci / nsc
0
donde: nsc es 5.
C.5.2 Informe
Se deben documentar los resultados de la evaluación en un Informe de Evaluación cuya estructura y

contenido cumpla con la IRAM-ISO/IEC 14598-5 (anexo A).
A continuación se resumen las secciones y contenidos de la plantilla requerida para el Informe de

Evaluación.
• Sección 1 - Identificaciones
Esta sección del informe de evaluación contiene información de identificación relativa a la evaluación
realizada.
• Identificación del evaluador
 nombre de la organización del evaluador,
 dirección de la organización del evaluador,
 lugar o lugares donde se realizó la evaluación (si fuera diferente del indicado anteriormente),
 nombre de la persona responsable de la evaluación.
• Identificación del informe de evaluación
 identificación única del informe (por ejemplo, número de serie),
 el número de páginas del informe.
• Identificación del solicitante
 el nombre de la organización del solicitante,
 la dirección de la organización del solicitante,
 el nombre del proveedor del producto de software (si fuera diferente del nombre indicado
anteriormente),
 la dirección del proveedor del producto de software (si fuera diferente de la dirección indicada
anteriormente).
• Sección 2 – Requisitos de la evaluación
Esta sección del informe de evaluación debe contener los requisitos de la evaluación:
 una descripción del dominio de aplicación del producto,
32
 una descripción general del propósito del producto,
 la lista de los requerimientos de la calidad e información del producto evaluado, incluyendo

posiblemente una referencia a las características de calidad y niveles de evaluación.
• Sección 3 – Especificación de la evaluación
Esta sección del informe de evaluación debe contener la especificación de la evaluación:
 el alcance de la evaluación, haciendo referencia a la descripción del producto,
 la referencia cruzada entre la información pedida en los requerimientos de la evaluación y los

componentes del producto,
 la especificación de las mediciones y verificaciones,
 el mapeo entre la especificación de las mediciones y verificaciones y los requisitos de la

evaluación.
• Sección 4 – Métodos de evaluación
Esta sección debe contener la documentación de los métodos de evaluación utilizados para realizar
la evaluación. Para cada método de evaluación incluido en este punto, se debe proporcionar la
identificación de los componentes del producto a los que se ha aplicado el método.
• Sección 5 – Resultados de la evaluación
Esta sección del informe de evaluación debe contener los resultados de la evaluación:
 resultados de la evaluación,
 resultados intermedios o una decisión de interpretación, cuando sea necesario,
 referencia a las herramientas utilizadas durante la evaluación.
Un Informe de Evaluación puede incluir los resultados de más de un Módulo de Evaluación; en ese
caso la estructura de las secciones es:
• Sección 1 - Identificaciones
• Sección 2 – Requisitos de la evaluación
• Sección 3 – Especificación de la evaluación
• Sección 4 A – Métodos de evaluación para el módulo de evaluación “XXXXX”
• Sección 5 A – Resultados de la evaluación para el módulo de evaluación “XXXXX”
• Sección 4 B - Métodos de evaluación para el Módulo de evaluación “YYYYYY”
• Sección 5 B - Resultados de la evaluación para el módulo de evaluación “YYYYY

Anexo D
(Informativo)
Ejemplo de un módulo de evaluación - Facilidad de uso y calidad en uso
Tecnología de la información – Evaluación del producto de software – Módulo de evaluación:

Facilidad de uso y calidad en uso
D.0 Prefacio e introducción
Prefacio
Este módulo de evaluación sirve para medir la Calidad en uso tal como se especifica en la IRAM-NM-
ISO/IEC 9126-1 y utilizar los principios de la ISO 9241-11. Se basa en la metodología MUSiC [2].
Introducción
Este módulo de evaluación proporciona los principios para evaluar la calidad en uso evaluando los
resultados de utilizar el producto con una muestra representativa de usuarios que llevan a cabo
tareas representativas en un ambiente simulado.
D.1 Alcance
D.1.1 Características
Este módulo de evaluación especifica cómo evaluar las siguientes tres características de la calidad
en uso definidas en la IRAM-NM-ISO/IEC 9126-1:
Eficacia: capacidad del producto de software de permitir que los usuarios alcancen las metas
especificadas con precisión y completitud en un contexto de uso especificado.
Productividad: capacidad del producto de software de permitir que los usuarios inviertan la cantidad
adecuada de recursos en relación con la eficacia lograda en un contexto de uso especificado.
Satisfacción: capacidad del producto de software de satisfacer a los usuarios en un contexto de uso
especificado.
NOTA. La IRAM-NM-ISO/IEC 9126- 1 también define a la seguridad física como una característica, pero la seguridad física
está fuera del alcance de este módulo de evaluación.
D.1.2 Nivel de evaluación
Este procedimiento de evaluación puede proporcionar estimaciones precisas de tres características

de la calidad en uso. El grado de precisión depende de cuán aproximadamente el contexto de
evaluación imita al contexto de uso, y de la cantidad de usuarios en cada grupo de usuarios que se
evalúa. Se recomienda que se evalúen al menos ocho usuarios en un contexto real de uso para
obtener resultados confiables.
D.1.3 Técnica
34
Una muestra de usuarios representativa intenta lograr metas de tareas representativas utilizando el
producto en un ambiente simulado sin otra ayuda que la disponible en el ambiente de trabajo real.
Los usuarios también completan un cuestionario de satisfacción.
D.1.4 Aplicabilidad
El modulo de evaluación es adecuado para cualquier producto que forme parte de un sistema con el
cual los usuarios interactúan para lograr los objetivos de las tareas.
Se puede aplicar durante el desarrollo, la adquisición o la operación, para el aseguramiento de la

calidad o la validación. Durante el desarrollo, se puede utilizar el módulo de evaluación para evaluar
prototipos tempranos utilizando sólo 3 ó 4 usuarios, para obtener una indicación de si es posible
lograr los objetivos de la calidad en uso. Durante la adquisición el módulo de evaluación puede
proporcionar aseguramiento de que el producto es adecuado para el ambiente de trabajo previsto.
Durante la operación, el módulo de evaluación puede establecer valores de referencia con los que se
compararán futuros productos, y puede indicar cuáles atributos del producto puede ser necesario
mejorar.
D.2 Referencias
[1] ISO 9241-11:1998, Ergonomic requirements for office work with visual display terminals (VDTs) -
Part 11: Guidance on usability.
[2] Macleod M, Bowden R, Bevan N and Curson I (1997) The MUSiC Performance Measurement
method, Behaviour and Information Technology, 16.
[3] Brooke J (1996). SUS: A "quick and dirty" usability scale. In Usability Evaluation in industry. Taylor
and Francis. See http://www.redhatch.co.uk/sus.html
[4] Lewis, J.R. (1995). IBM Computer Usability Satisfaction Questionnaires: Psychometric
Evaluation and Instructions for Use. International Journal of Human-Computer Interaction, 7, 57-78.
[5] Kirakowski, J. (1996). The software usability measurement inventory: background and usage. In:
P. Jordan, B Thomas, & B Weerdmeester, Usability Evaluation in Industry. Taylor & Frances, UK.
See also http://www.ucc.ie/hfrg/questionnaires/sumi/index.html
[6] Shneiderman, B. (1998). Designing the User Interface. Reading, MA, Addison-Wesley Publishing
Co. See also: http://www.cs.umd.edu/projects/hcil/Research/1994/quis.html
D.3 Términos y definiciones
Contexto de uso: usuarios, tareas, equipos (hardware, software y materiales) y ambientes físicos y
sociales en los que se usa el producto. [ISO 9241-11]
Usuario: persona que interactúa con el producto.
[ISO 9241-11] Meta: resultado deseado. [ISO 9241-11]
Tarea: actividades requeridas para alcanzar una meta. [ISO 9241-11]
D.4 Entradas y métricas

D.4.1 Entrada para la evaluación
D.4.1.1 Componente del producto: prototipo de trabajo
Se evalúa un prototipo de trabajo (incluyendo el código ejecutable y la documentación del usuario).
D.4.1.2 Información del producto: contexto de uso
Se requiere una definición de los contextos de uso previstos para el producto, incluyendo las
características esenciales y las capacidades de los grupos de usuarios seleccionados, sus metas y
tareas y el ambiente técnico y de apoyo proyectado.
D.4.1.3 Información de apoyo: contexto de evaluación
El contexto de evaluación es una especificación de las condiciones bajo las cuales las tareas se han
de realizar. Conviene que se base en el contexto de uso previsto. Se recomienda proporcionar la
siguiente información:
 los escenarios y las metas de las tareas, utilizados en la evaluación;
 la configuración utilizada para la evaluación, incluyendo la configuración del hardware, el sistema

operativo, y, si el producto se basa en un buscador, el buscador empleado;
 los dispositivos de visualización si el producto tiene una interfaz visual basada en una pantalla,
incluyendo el tamaño de la pantalla y la resolución del monitor y el tamaño y la fuente empleados;
 el tamaño del papel de impresión y la resolución de impresión, si el producto tiene una interfaz
basada en la impresión;
 los bits de audio y ajuste de volumen, si el producto tiene una interfaz de audio;
 el dispositivo de entrada manual (teclado, “mouse”, “joystick”, etc.), si el producto tiene una
interfaz manual;
 el ambiente, escenario o tipo de espacio en el que se llevó a cabo la evaluación. Por ejemplo,
laboratorio para facilidad de uso, configurado para simular un despacho de oficina, una sala de
reunión, un escritorio, un cuarto de estar, una planta de fabricación;
 información sobre los participantes en la evaluación: población, incluyendo edad, género y

necesidades especiales, si las hubiera, cómo fueron seleccionados los participantes y si poseen
las mismas características y capacidades esenciales de los usuarios previstos.
Se recomienda consignar en el informe de evaluación toda diferencia conocida entre el contexto de la

evaluación y el contexto de uso planificado
D.4.2 Elementos de los datos
D.4.2.1 Tiempo de la tarea

Tiempo total que le lleva a cada usuario completar la tarea (excluyendo las interrupciones).
D.4.2.2 Resultado de la tarea
36
Una representación concreta de los resultados de la tarea producidos por cada usuario (por ejemplo,
datos, un registro en papel o la respuesta del usuario a un cuestionario).
D.4.2.3 Resultados de la satisfacción

Un cuestionario de satisfacción cumplimentado.
NOTA. Utilizar una medida normalizada proporciona datos que son más fáciles de interpretar. Los siguientes son ejemplos
de cuestionarios estandarizados: SUS [3], PSSUQ [4], SUMI [5] y QUIS [6]).
D.4.2.4 Dificultades encontradas
Habitualmente es adecuado proporcionar datos cualitativos adicionales que identifiquen los

problemas, detectados por los usuarios, que causaron dificultades con la calidad en uso. También se
pueden incluir sugerencias de cambios al producto que mejorarían la calidad en uso.
D.4.3 Métricas y medidas
D.4.3.1 Eficacia
La eficacia es una medida de si los usuarios pueden alcanzar sus metas con precisión y completitud.
No tiene en cuenta cómo se alcanzaron los objetivos, sólo si se alcanzaron.
Se recomienda medir la eficacia por el grado en que se alcanzaron las metas de la tarea. Una
métrica posible es el porcentaje de usuarios que en conjunto alcanzaron sus metas. Si las metas se
pueden alcanzar parcialmente (por ejemplo, debido a resultados incompletos o por debajo del
óptimo) entonces una métrica más adecuada sería el logro promedio de la meta, medida en una
escala de 0 al 100 basada en criterios especificados. En algunos casos puede ser importante el
porcentaje de usuarios que producen errores críticos, no corregidos.
D.4.3.2 Productividad
La productividad es la razón del nivel de eficacia alcanzado a la cantidad de recursos utilizados. La

eficacia se evalúa generalmente por el tiempo medio insumido en lograr la tarea. La eficacia puede
también relacionarse con otros recursos (por ejemplo, el costo total de uso), o puede ser
relativamente poco importante (por ejemplo, para ciertas aplicaciones de consumidores).
El tiempo que insume una tarea es la medida general de la eficacia. Ello supone que cuánto menos
tiempo invierte un usuario en completar una tarea, tanto menos recursos demandará dicha tarea y
tanto mejor será el producto. Medir la eficiencia como el cociente entre la eficacia y el tiempo
proporciona una medida del ritmo de trabajo, y sirve cuando se comparan diferentes productos para
el mismo grupo de usuarios y tarea.
D.4.3.3 Satisfacción
La satisfacción es una evaluación de la reacción de los usuarios al utilizar el producto y es

recomendable que se mida utilizando un cuestionario normalizado.
D.5 Interpretación de resultados
D.5.1 Mapeo de medidas
D.5.1.1 Eficacia
La eficacia se mide como un porcentaje. Los criterios para la eficacia dependerán del nivel de
evaluación y de la naturaleza de los objetivos del negocio.
D.5.1.2 Productividad
La productividad se puede medir por tiempo de tarea o por el cociente eficacia/tiempo de tarea. Los
criterios para la eficacia dependerán del nivel de evaluación y de la naturaleza de los objetivos del
negocio.
D.5.1.3 Satisfacción
Los criterios para la satisfacción pueden fijarse por comparación con resultados anteriores para
productos relacionados, o por comparación con una base de datos suministrada de reglas
industriales estándar para el cuestionario.
D.5.1.4 Interpretación de las medidas
D.5.1.5 Exactitud
Es conveniente que todas las métricas informadas suministren los valores medios y el error estándar
de la media. Cualquier afirmación de diferencias entre los valores debe plantear la probabilidad de
que la diferencia no ocurrió por casualidad.
D.5.1.6 Interpretación
Se recomienda interpretar cada medida en relación con los requerimientos para la calidad en uso en
un contexto de uso específico. En general no es significativo combinar los resultados de la eficiencia
con los de la satisfacción.
D.5.2 Informe
Es conveniente que el informe contenga lo siguiente:
 El propósito del producto: para qué sirve el producto, qué se prevé que haga para sus usuarios.
 Los objetivos de la evaluación, y todo valor específico deseado para las medidas por tomar.
 Las características y capacidades esenciales que se esperan de los grupos de usuarios que se
están evaluando.
 Contexto de la evaluación: las condiciones bajo las que se realizaron las tareas, y toda diferencia
conocida entre el contexto evaluado y el contexto de uso esperado.
 Diseño de la evaluación: los grupos de usuarios, las tareas asignadas, toda otra variable
independiente, y las medidas tomadas.
38
 Procedimiento: secuencia de eventos.
 Instrucciones para las tareas.
 Resultados (los que deberían incluir su representación gráfica).
 Dificultades halladas por los usuarios y sugerencias para cambios al producto (optativo).
 Interpretación.
D.6 Procedimiento de aplicación
D.6.1 Recursos requeridos
 Un evaluador con aptitudes o idoneidad en la evaluación de factores humanos.
 El esfuerzo mínimo para los evaluadores es aproximadamente: 3 días/persona para la

planificación, 2 días/persona para la evaluación y 2 días/persona para el análisis e informe.
 El uso de un laboratorio de usabilidad, o medios para monitorear la interacción en forma remota

por video son deseables (aunque no esenciales).
D.6.2 Instrucciones para la evaluación
El propósito de la evaluación es ayudar a los lectores del informe a decidir si el producto tendrá
calidad en uso para sus usuarios particulares, tareas y ambiente de trabajo. Es conveniente que el
diseño de la evaluación se base en una simulación del ambiente de uso pretendido.
Se recomienda informar la evaluación y los resultados con suficiente detalle para permitir a los
lectores juzgar la relación de los resultados con las necesidades de sus propios usuarios, tareas y
ambientes de trabajo.
Las siguientes directrices ayudarán a asegurar que el procedimiento de evaluación se aproxime tanto
al uso en el ambiente de operación como sea posible:
 es necesario que el informe de evaluación aclare para qué usuarios, tareas y ambientes de trabajo
está previsto el producto, y en qué medida se simularon realmente estas características en la
evaluación,
 es conveniente que las instrucciones para las tareas instruyan a los usuarios sobre qué deben
alcanzar sin dar pistas sobre qué características del producto tienen que utilizar,
 para que la situación de evaluación sea representativa del uso en el mundo real debe ser tan
natural como sea posible. Ello puede significar tener que simular distractores y otras condiciones
de trabajo. Es conveniente que los evaluadores sean lo más discretos posibles (preferentemente
observando de lejos desde otra habitación),
 durante la evaluación no es conveniente pedir a los participantes que piensen en voz alta,
 no es conveniente dar a los participantes ninguna pista o ayuda, distinta de los mecanismos
disponibles para los usuarios reales (tales como documentación o una línea telefónica de ayuda
técnica),
 es conveniente obtener los datos de suficientes usuarios en cada categoría para que la muestra
de usuarios sea representativa del grupo previsto de usuarios. Dada la típica variabilidad de los
participantes en una evaluación, se ha demostrado que para obtener resultados coherentes es
mejor evaluar al menos 8 participantes de cada grupo de usuarios,
 para utilizar las medidas tomadas, se recomienda que sea posible establecer criterios de
aceptación o hacer comparaciones entre los productos. Ello significa que es recomendable que
las medidas sean ítems cuantificables de valor conocido.
40
Anexo E
(Informativo)
Bibliografía
[1] ISO/IEC Guide 2, Standardization and related activities – General vocabulary.
[2] ISO/IEC Guide 25, General requirements for the competence of calibration and testing
laboratories.
[3] ISO/IEC TR 9126-2, Software engineering — Product quality – Part 2: External metrics.
[4] ISO/IEC TR 9126-3, Software engineering — Product quality – Part 3: Internal metrics.
Anexo F – IRAM
(Informativo)
Bibliografía
En el estudio de este Esquema se ha tenido en cuenta el antecedente siguiente:
ISO - INTERNATIONAL ORGANIZATION FOR STANDARIZATION

IEC - INTERNATIONAL ELECTROTECHNICAL COMMISSION
ISO/IEC 14598-6:2006 – Software engineering –Product
evaluation - Part 6: Documentation of evaluation modules.
42
Anexo G – IRAM
(Informativo)
Integrantes de los organismos de estudio
El estudio de esta norma ha estado a cargo del organismo respectivo, integrado en la forma siguiente:
Subcomité de Calidad en Tecnología de la Información
Integrante Representa a:
Lic. Daniel ALONSO ALONSO CARRA S.A.

Lic. Gonzalo BALLESTER BALLESTER SASTRE CONSULTORES
Sr. Ricardo BALSIMELLI INVITADO ESPECIAL
Lic. Gladys A. BARCA AFIP – ADMINISTRACIÓN FEDERAL DE
INGRESOS PÚBLICOS
Lic. Julio César BELLENE IT QUALITY / GRUPO TEKNE
Ing. Alejandra BRITO INVITADA ESPECIAL
Act. Carolina C. CASTRO X-PROJECT S. A.
Sr. Eduardo DE MARÍA UNIVERSIDAD NACIONAL DE LA MATANZA
Ing. Susana N. EPPENS SIEMENS IT SOLUTIONS & SERVICES
Ing. Norberto ESARTE GATECH S.A.
Ing. Marcelo ESTAYNO FUNDESCO
Lic. Graciela FRIGERI INVITADA ESPECIAL / CAJA DE VALORES S.A.
Lic. Paula GEOSITS BANCO ITAÚ ARGENTINA S.A.
Sr. Luis Alberto GROSSO INTI – INSTITUTO NACIONAL DE TECNOLOGÍA
INDUSTRIAL – ÁREA INFORMÁTICA -
MENDOZA
Sr. Guillermo KROJZL INTERSISTEMAS
Lic. Roberto LANGDON CPCI – CONSEJO PROFESIONAL DE CIENCIAS
INFORMÁTICAS
Sra. Romina Laura LOMBARDI PROYECTOS DE IT
Tec. Gustavo A. LUCERO INTI – INSTITUTO NACIONAL DE TECNOLOGÍA
INDUSTRIAL – ÁREA INFORMÁTICA -
MENDOZA
Sra. Delia Cristina LUISIO TELECOM ARGENTINA S.A. WHOLESALE
NACIONAL – ÁREA VENTAS OPERADORES
Lic. Raúl MARTÍNEZ RMyA S.R.L. / POLO IT BUENOS AIRES
Lic. Marcelo MENAL DIVERSIS
Ing. Liliana R. MIRA SAYQA S.R.L.
Lic. Alicia MON UNIVERSIDAD NACIONAL DE LA MATANZA -
POSGRADO
Sra. Alfonsina MORGAVI INVITADA ESPECIAL
Ing. Osvaldo PÉREZ IEEE – INSTITUTO DE INGENIEROS EN
ELECTRICIDAD Y ELECTRÓNICA SECCIÓN
ARGENTINA
Lic. Beraldo Leo PESTCHANKER UNIVERSIDAD DE BELGRANO
Sra. Nora Cristina PONCE ADACSI – ASOCIACIÓN DE AUDITORÍA Y

Integrante Representa a:
CONTROL DE SISTEMAS DE INFORMACIÓN /

AFIP – ADMINISTRACIÓN FEDERAL DE
INGRESOS PÚBLICOS
Dra. Sandra PRIETO INVITADA ESPECIAL
Ing. Fernando RADICCHI BANCO DE LA NACIÓN ARGENTINA
Sr. Leonardo RAMOS INVITADO ESPECIAL
Sra. Graciela ROMANELLI Universidad Nacional de La Matanza- Sede de
Posgrado
Sr. Damián ROMERO INVITADO ESPECIAL
Ing. Claudia RUATA COLEGIO DE INGENIEROS ESPECIALISTAS DE
CÓRDOBA
Ing. Gerardo Carlos SAID INFOTRON S.A./ UNIVERSIDAD NACIONAL
NOROESTE DE BUENOS AIRES/ DRUDICS
Lic. Alberto Antonio SÁNCHEZ GPF SOLUCIONES
Lic. Fernanda SCALONE INVITADA ESPECIAL
Sr. Roberto SCHATZ MICROSOFT DE ARGENTINA S.A. /
INGEMATICA S.A.
Sr. Roberto SILVA PETROBRAS ENERGÍA S.A.- GESTIÓN DE
SISTEMAS - GECSMS
Lic. Marta R. de BARBIERI IRAM
Ing. Jorge L. CEBALLOS IRAM
Mg. Domingo F. DONADELLO IRAM
Mg. Paula María ANGELERI IRAM
TRÁMITE
El estudio de este Esquema se realizó en las reuniones del 2008-03-11 (Acta 1-2008), 2008-10-21
(Acta 8-2008), 2008-11-04 (Acta 9-2008), 2008-12-10 (Acta 10-2008), 2009-01-07 (Acta 1-2009),
2009-03-04 (Acta 2-2009), 2009-03-25 (Acta 3-2009), 2003-04-15 (Acta 4-2009), 2009-05-13 (Acta
5-2009), 2009-06-03 (Acta 6-2009), 2009-08-05 (Acta 7-2009), 2009-09-02 (Acta 8-2009), 2009-12-
22 (Acta 11-2009), en la última de las cuales se lo re aprobó como Esquema 1 y se dispuso su envío
a Discusión Pública por el término de 30 días.
Asimismo, en el estudio de este Esquema se han considerado los aspectos siguientes:
¿SE HAN INCORPORADO?

Aspectos Comentarios
Sí / No / No corresponde
Ambientales No corresponde
Salud No corresponde
Seguridad No corresponde
******************************
44
APROBADO SU ENVÍO A DISCUSIÓN PÚBLICA POR EL SUBCOMITÉ DE CALIDAD EN
TECNOLOGÍA DE LA INFORMACIÓN, EN SU SESIÓN DEL 22 DE DICIEMBRE DE 2009 (Acta 11-
2009).
FIRMADO FIRMADO
Mg. Paula María Angeleri Lic. Graciela Frigeri
Coordinador del Subcomité Secretario del Subcomité
FIRMADO
Lic. Marta R. de Barbieri
Vº Bº Gerente de Tecnología Química

6 Iram Iso Iec

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

6 Iram Iso Iec

Încărcat de

Drepturi de autor:

Formate disponibile

ESQUEMA 1

Evaluación del producto de software

LAS OBSERVACIONES DEBEN

ENVIARSE CON EL FORMULARIO DE LA

ETAPA DE DISCUSIÓN PÚBLICA

DOCUMENTO EN ESTUDIO Noviembre de 2009

IRAM es el representante de la Argentina en la International

Esta norma IRAM es el fruto del consenso técnico entre los

Se pretende que la IRAM-ISO/IEC 14598-6 sea utilizada en

La norma IRAM-ISO/IEC 14598 consta de las siguientes partes

 Parte 1 - Descripción general.

 Parte 2 - Planificación y gestión.

 Parte 3 - Proceso para desarrolladores.

 Parte 4 - Proceso para compradores.

 Parte 5 - Proceso para evaluadores.

 Parte 6 - Documentación de los módulos de evaluación.

Los anexos A, B, C, D y E de esta parte de la ISO/IEC 14598

La presente norma IRAM es idéntica a la norma ISO/IEC 14598-6:

Prefacio de la norma ISO

ISO (Organización Internacional de Normalización) e IEC

En el campo de la tecnología de la información, ISO e IEC han

Se recomienda prestar atención a la posibilidad de que algunos

La norma internacional ISO/IEC 14598-6 fue elaborada por el

NOTA IRAM. A la fecha de publicación de este documento el subcomité

Se pretende que la ISO/IEC 14598-6 sea utilizada en conjunto

La ISO/IEC 14598 consta de las siguientes partes bajo el título

 Part 1 - General overview.

 Part 2 - Planning and management.

 Part 3 - Process for developers.

 Part 4 - Process for acquirers.

 Part 5 - Process for evaluators.

 Part 6 - Documentation of evaluation modules.

Los anexos A, B, C, y D de esta parte de la ISO/IEC 14598 son

1 OBJETO Y CAMPO DE APLICACIÓN..............................................................8

3 NORMAS PARA LA CONSULTA.......................................................................8

5 EL CONCEPTO DE MÓDULO DE EVALUACIÓN............................................9

6 FORMATO PARA LA DOCUMENTACIÓN DE UN MÓDULO DE EVALUACIÓN

Anexo A (Informativo) Desarrollo de los módulos de evaluación.........................13

Anexo B (Informativo) Ejemplo de un módulo de evaluación – Densidad de fallas

Anexo C (Informativo) Ejemplo de un modulo de evaluación - Funcionalidad.....19

Anexo D (Informativo) Ejemplo de un módulo de evaluación - Facilidad de uso y

Anexo E (Informativo) Bibliografía.......................................................................40

Anexo F – IRAM (Informativo) Bibliografía..........................................................41

Anexo G – IRAM (Informativo) Integrantes de los organismos de estudio..........42

0 INTRODUCCIÓN Identifica un conjunto mínimo de requisitos para

1 OBJETO Y CAMPO DE APLICACIÓN ISO/IEC 12207 - Information technology –

IRAM-ISO/IEC 14598-5, Tecnología de la

 procedimientos y herramientas de apoyo.

 favorecer el uso de módulos de evaluación

Se debe identificar el modelo de calidad que

6.2.1 Características 6.2.4 Aplicabilidad

plan de administración de la configuración, el plan de

6.3 EM2: Referencias NOTA 1. Ejemplos de elementos de datos son: la cantidad

NOTA 2. En general, los elementos de datos son el

necesarios para hacer el mapa o se debe hacer propietarias); hardware/software necesarios;

Desarrollo de los módulos de evaluación

A.1 Identificación de los requisitos del módulo de evaluación

Cuando se identifica la necesidad de un nuevo módulo de evaluación y se toma la decisión de

A.2 Especificación del módulo de evaluación

A.3 Desarrollo del procedimiento de evaluación

A.4 Descripción del procedimiento de evaluación

En este paso es recomendable que el procedimiento de evaluación desarrollado en el paso anterior

A.5 Verificación y validación del módulo de evaluación