norma tecnica peruana ntp-iso/iec 9126-2 2004 calidad del producto - metricas externas

5/17/2018 Norma Tecnica Peruana NTP-ISO/IEC 9126-2 2004 Calidad del producto - Metricas Exte...

http:///reader/full/norma-tecnica-peruana-ntp-isoiec-9126-2-2004-calidad-del-producto-

. . . . ,----------------------

-------------------i. ----- "'~

NORMA TECNICAPERUANA NTP -ISO IIEC TR 9126-22004Comision de Reglamentos Tecnicos y Comereiales-INDECOPICalle de La Prosa l38, San Borja (Lima 41) Apartado 145 Lima, Peru

INGENIERlA DE SOFTWARE. Calidad del producto.Pa rte 2 : Metricas extemasSOFTWARE ENGINEERING - PRODUCT QUALITY. Part 2 External memes(EQV. ISOIlEC TR 9126-2:2003 SOFTWARE ENGINEERING - Product quality. Part 2: External metrics)

2004-1l~18laEdici6n

R.0123-2004IINDECOPI-CRT.Publieada eI2004-12-02 Precio basado en 128 paginasLC.S.: 35.080Deseriptores: Calidad, metricas de calidad, software

ESTA NORMA ES RECOMENDABLE

/



INDICE

piginaiNDICE IPREFACIO IVPROLOGO viINTRODUCCION Vlll

1. ALCANCE 12 . CONFORMIDAD 23. REFERENCIAS NORMATIV AS 24 . TERMINOS Y DEFINlCIONES 45 . ABREVIATURA DE TERMINUS 46. USO DE LAS METRICAS CUALITATIVAS DE SOFTWARE 57 . FORMA DE LEER Y USAR LAS TABLAS METRICAS 78 . TABLAS DE METRICAS 89 . ANTECEDENTE 9 0

ANEXOSANEXOA 9 1ANEXOB 1 0 1ANEXOC 1 1 0ANEXOD 1 2 4

/

~ . , . . _f ~!~Ii.....I!; . . . . . .1~I:lI......~

.~

~.~~~" ' " '.~" ' " '~

: " ' " '" ' ".~



NORMA TECNICAPERUANA

NTP-ISOIIEC TR 9126-21 de 128

lNGENIERiA DE SOFTWARE. Calidad del producto. Parte2: Metricas extemas

1. ALCANCE

La presente NTP define las metricas extemas para la medici6n cuantitativa de calidadextema del software en terminos de caracteristicas y sub caracteristicas definidas en iaNTP-ISOIIEC 9126-1 y se pretende que sea utilizado junto con la NTP-ISOIIEC 9126-1.

Esta NTP contiene:

11 Un conjunto basico de metricas para carla sub caracteristica,

1 . Una explicacion de la forma de aplicaci6n de las metricas de calidad delsoftware.

III. Un ejemplo de la forma en que se aplican las metricas durante el ciclo devida del producto software.

Esta NTP no asigna un rango de valores de estas metricas a niveles determinados 0 agrados de conformidad dado que estos valores se definen para cada producto software 0para una parte del producto software, debido a su naturaleza, dependiendo en factores talescomo la categoria del software, el nivel de integraci6n y las necesidades del usuario.Algunos atributos pueden poseer un adecuado rango de valores, los mismos que nodependen de las necesidades especfficas del usuario sino de factores genericos, porejemplo, factores humanos cognoscitivos.

Entre los usuarios a los que em destinado esta NTP se incluyen:

Esta NTP puede aplicarse a todo tipo de software para cualquier aplicaci6n. Los usuariosde esta NTP pueden elegir 0 modificar y aplicar las metricas y medici6n de esta NTP 0quiza definir la aplicacion de metricas especificas para su dominio de aplicacionindividual. Por ejemplo, la medici6n especifica de caracteristicas de calidad tales como laseguridad e integridad' pueden encontrarse en las Normas Intemacionales 0 reportestecnicos proporcionados por el lEC 65 y ISOIIEC JTC lISC 27.

'I=:I termino Safety ha sido traducido al espafiol como Integridad. As! mismo Security como seguridad .

. . .



--.--- NORMA TECNICA___PERUANA NTP-ISOIIEC TR 9126-256 de 128---8.4 Metriea de eficiencia-- Una rnetrica extema de eficiencia deberia ser capaz de medir atributos como, el consumode tiempo y el comportamiento en la utilizaci6n de recursos de un sistema de computaci6n,incluyendo el software durante las pruebas 0 las operaciones.-- --- Se recomienda que el tiempo maximo y su distribuci6n sean investigados para muchoscasos de pruebas u operaciones, porque la medida del proceso es afectada y fluctuadependiendo de las condiciones de usc, tales como la carga de datos del proceso,frecuencia de uso, numero de sitios de conexi6n y asi sucesivamente. Sin embargo, lasmetricas de eficiencia pueden incluir el ratio del valor actual medido con fluctuaciones deerror para el valor disenado dentro del rango permitido de fluctuaciones de error requeridopor la especificaci6n.

-- --- -- -- --- Se recomienda listar e investigar el rol desempefiado por los factores tales como uso delprocesador y memoria usada por otro software, trafico de la red y procesos que se ejecutanen segundo plano. Las posibles fluctuaciones y los rangos validos para valores medidosdeben ser establecidos y comparados con las especificaciones de requerimientos.----- Se recomienda que una tarea sea identificada y definida para que se adecue a la aplicacionsoftware; por ejemplo, una transacci6n como una tarea para la aplicaci6n de negocio, elenvio 0 conrnutacion de paquetes de datos como tarea para la aplicaci6n de comunicaci6n;un control de eventos como tarea para la aplicaci6n de control; y la salida de datos

producida por la Hamada de una funci6nde usuario para una aplicaci6n de usuario comun.---- NOT AI: Tiernpo de respuesta: Tiempo necesario para recibir el resultado de presionar una tecJa detransmisi6n. Esto significa que el tiempo de respuesta inc\uye el tiempo de procesamiento y el tiernpode transmisi6n. EI tiempo de respuesta solo es aplicable para un sistema interactive. No hay ningunadiferencia significativa cuando es un sistema independiente (standalone system). Sin embargo, en el

caso de un sistema de internet u otro sistema en tiempo real, a veces el tiempo de transmisi6n esmucho mayor.

--- -- -- - NOTA 2: Tiempo de procesarniento: EI tiempo transcurrido en una computadora entre recibir unmensaje y enviar el resultado. A veces incluye tiempo de sobrecarga de operacion, otras veces, s610significa el tiempo usado por un programa de aplicacion.--- NOTA 3: Tiempo de retorno: Tiempo necesario para recibir el resultado de una solicitud. En muchoscasas el tiempo de retorno incluye muchas respuestas. Por ejemplo, en el caso de un dispensador dedinero, el tiempo de retorno es el tiernpo desde que se presiona la tecla hasta que se obtiene el dinero,es decir, se selecciona una transacci6n y se espera un mensaje, se ingresa la clave y se espera elsiguiente mensaje, etc.

--_-- ---



. - . . .-----------.--. . . . .-. - . . .-.. - . . .---- . . .---. - . . .--.---.

-. - . . .--. - . . .--------- ~.--

NORMA TECNICAPER-DANA


8.5 Merrlcas de facilidad de mantenimiento

Dna metrica extema de facilidad de mantenimiento deberia ser capaz de medir atributostales como el desernpefio del responsable de mantenimiento, usuario, 0 sistema incluyendoel software, cuando el software es mantenido 0 modificado durante las pruebas 0 elmantenimiento.

8.5.1 Metricas de analizabilidad

Una metrica externa de analizabilidad deberfa ser capaz de medir atributos tales como elesfuerzo del responsable de mantenimiento 0 del usuario 0 el uso de recursos cuando estatratando de diagnosticar deficiencias 0 causas de fallas, 0 para identificar partes a sermodificadas.

8.5.2 Metricas de cambiabilidad

Una metrica extema de cambiabilidad deberfa ser capaz de medir atributos tales como elesfuerzo del responsable de mantenimiento 0 del usuario para la medici6n del desempefiodel responsable de mantenimiento, usuario 0 sistema, incluyendo el software cuando estatratando de implementar una modificaci6n especifica .

8.5.3 MHricas de estabilidad

Una metrica extema de estabilidad deberfa ser capaz de medir atributos relacionados a uncomportamiento no esperado del sistema inc1uyendo el software cuando este es probado uoperado despues de l~ modificaci6n .

8.5.4 Metricas de testeabilidad

Una metrica externa de testeabilidad deberia ser capaz de medir atributos tales como elesfuerzo del responsable de mantenimiento 0 del usuario para medir el desempefio delresponsable de mantenimiento, usuario 0 sistema incluyendo el software cuando estatratando de probar el software modificado 0no.



~I~!~i~

1 " " ' " \

.~

, -,-.

, -, -



~.-. --------------------------------------------- "'.--


NTP-ISOfIEC TR 9126-292 de 128

ANEXOA(INFORMA TIVO)

CONSIDERACIONES CUANDO SE UTILIZANMETRlCAS

A.l Interpretacion de lamedici6n

A.l.1 Diferencias potenciales entre contextos de uso de prueba y operacional

Cuando planifique el uso de metricas 0 interprete mediciones es importante tener una claracomprensi6n del contexto de uso del software y cualquier potencial diferencia entre laspruebas y los contextos de usc operacionales. Por ejemplo, la medida del "tiemporequerido para aprender una operacion" es frecuentemente diferente entre los operadoreshabiles y operadores no habiles en sistemas software similares, Ejemplos de diferenciaspotenciales son proporcionadas mas abajo.

a) Diferencias entre entomos de prueba y entomos operacionales

GHay diferencias significativas entre los entornos de pruebas y la ejecuci6n operacional enentornos de usuario?

Los siguientes son ejemplos de estas diferencias:

Pruebas con alto / comparable / bajo desempefio de CPU de la computadoraoperacional.

Pruebas con alto / comparable / bajo desempefio de redes y comunicacionesoperacionales.

Pruebas con alto / comparable / bajo desempefio del sistema operativooperacional.


http:///reader/full/norma-tecnica-peruana-ntp-isoiec-9126-2-2004-calidad-del-producto

~---------------------------------------------- ,--:-~--



ANEXOB(INFOR...\1ATIVO)

usa DE CALIDAD EN'USO, METRICAS EXTERNAS EINTERNAS (EJEMPLO MARCO)B . I Introducci6n

Este ejemplo modelo es una descripcion a alto nivel de como el modele de calidad de IaISOlIEe 9126 y sus metricas relacionadas pueden ser usadas durante el desarrollo eimplementacion de software para lograr un producto de calidad que satisfaga 10requerimientos especificados por el usuario. Los conceptos mostrados en este ejemplo puedenser implementados en varias formas de adaptacion para adecuarse a Ia persona, organizacion 0proyecto; el ejemplo usa los procesos clave del ciclo de vida de la ISOIIEC 12207 como unareferencia al tradicionalciclode vida de software y los pasos del proceso de evaluaci6n decalidad de la ISOlIEe 14598-3 como Una referencia al proceso tradicional de evaluacion decalidad del producto software. Los conceptos pueden ser referenciados a otros modelos delciclo de vida del software si el usuario asi 10 desea en tanto los conceptos expuestos sonentendidos.

B.2 Vista general de los procesos de desarrollo y calidad

Tabla Bl muestra un modelo ejemplo que relaciona las actividades del proceso del ciclo devida de software (actividad 1 a actividad 8) a sus entregables clave y los modelos dereferencia relevantes para medir la calidad de los entregables (ejemplo: calidad en uso, calidadexterna, 0ca1idad intema).

La fila 1 describe las actividades del proceso del ciclo de vida de desarrollo de software (estapuede ser adaptada para adecuarse a necesidades individuales), La fila 2 describe si unamedida actual 0 pronosticada es posible para la categoria de Ia medida (ejemplo: calidad enuso, calidad extema, 0calidad interna). La fila 3 describe los entregables clave que pueden sermedidos por calidad, y la fila 4 describe las metricas que pueden ser aplicadas en cadaentregable de cada actividad del proceso.



NORMA rECNICAPERUANA NTP-ISOIIEC TR 9126-2111 de 128

ANEXOC(INFORMATIVO)

EXPLICACION DETALLADA DE LOS TIPOS DEESCALAS DE METRICAS Y LOS TIPOS DEMEDICIONES

C.l Tipos de escala de metricaUno de los siguientes tipos de escala de metrica de medicion deberiaser identificado paracada medida, cuando un usuario de metricas tiene el resultado de una medicion y usa lamedida para calculo 0 comparacion. Los valores de promedio, ratio 0 diferencia pueden notener significado para algunas medidas.

-os tipos de escala de metrica son: escala Nominal, escala Ordinal, escala de Intervalos,escala de Ratios y escala Absoluta, Una escala debe ser siempre definida como M =F(M),donde F es la funcion admisible. Tambien la descripcion de cada tipo de escala demedicion contiene una descripcion de la funcion admisible (si M es una metrica entoncesM' =F(M) es tambien una metrica),

a) Escala nominal

M' =F(M) donde F es de cualquiera a, . . una referencia.

Esto incluye clasificacion, por ejemplo, tipos de falla de software (datos, control, otro). Unpromedio tiene significado solo, si este es calculado con la frecuencia del mismo tipo. Unratio tiene significado solo cuando este es calculado con la frecuencia de cada tiporeferenciado. Asi, el ratio y el promedio pueden ser usados para representar una diferenciaen la frecuencia de s610 el mismo tipo entre casos iniciales y posteriores 0 dos casossimilares. En caso contrario, elIos pueden ser usados para comparar mutuamente lafrecuencia de cada otro tipo respectivamente.

Ejemplos: Numero de identificacion de la linea de transporte urbano. Numero dei1entificaci6n de mensaje de error de compilacion, ,-.

norma tecnica peruana ntp-iso/iec 9126-2 2004 calidad del producto - metricas externas

Documents