Evaluación de producto de

software

IRAM ISO / IEC 14598 con

modelo 9126

Ing. Mariana Gómez Lic. Raúl Martínez

La solicitud de IRAM

• Evaluar la calidad de un Producto de Software siguiendo el estándar ISO 14598 e ISO 9126

• Los desafíos que plantea

– Qué atributos de calidad considerar

– Bajo qué contexto se determina la calidad de dicho producto

• Evaluar conformidad es un problema conocido para otras industrias reguladas y estandarizadas. No así todavía para la industria del software.

Características Ext./ Int.

Funcionalidad Confiabilidad Usabilidad Eficiencia Mantenibilidad Portabilidad

El Modelo ISO 9126

Desafíos para la evaluación

Calidad en uso

Efectividad Productividad Seguridad Satisfacción

Proceso ISO 14598

Laboratorio de Ensayos de

Software

Proyecto: INFONOR

Producto: Nokia Gol

Versión 1.00

Breve descripción del Ensayo

• Objetivo del Proyecto

• El Resultado

• Equipo de Trabajo

• El Proceso de Evaluación

• Calendario

• Conclusiones y Lecciones Aprendidas

Objetivo del Proyecto

• Llevar a cabo los ensayos solicitados por IRAM para las características de calidad seleccionadas en el producto Nokia Gol Versión 1.00, éstos eran:

• Funcionalidad

• Confiabilidad

• Usabilidad

• Eficiencia

• Portabilidad

– Con el fin de aplicar los resultados de la evaluación para

futuras mejoras del producto

El Resultado – Entregables exigidos por la Norma

Característica Sub característica Métrica Descripción

de la

evaluación

(métricas)

Resultado Fórmula Valor de

Referencia

Resultado

Funcionalidad Adecuación Functional Adecuacy (Adecuación Funcional): Objetivo: Evaluación de la funcionalidad del aplicativo (ver funciones detalladas en el documento “Funciones MGOL.xls”). Se evalúa qué tan adecuadas son las funciones del aplicativo comparándolas contra las siguientes especificaciones de referencia: 1. Nokiagol_latam_guia_rapida.pdf 2. Requisitos de Evaluación - INFONOR -

NokiaGol LA 3. Flowchart (NokiaGol LA) spanish.jpg Cálculo: Se computa la cantidad de funciones con problemas detectados durante la evaluación dividido la cantidad total de funciones evaluadas. Se toma como problema detectado: cuando cada función probada no funciona como se especificó.

66 3 veces X=1-A/B A=2 B=16

0<=X<=1, lo más cercano a 1 es lo más adecuado

Característica Sub-característica Métrica Resultado

Funcionalidad Adecuación Functional Adequacy (Adecuación Funcional)

Funcionalidad Adecuación Functional Implementation Coverage (Cobertura de la Implementación

Funcional )

Confiabilidad Madurez Failure Density against test cases (Densidad de falla contra casos de

prueba)

Confiabilidad Madurez Mean time between failure (Tiempo Medio entre fallas)

Confiabilidad Madurez Test Coverage (Cobertura del Ensayo)

Confiabilidad Tolerancia a Fallas Break Down Avoidance (Prevención de caídas)

Confiabilidad Recuperabilidad Availability (Disponibilidad)

Confiabilidad Recuperabilidad Restartability (Capacidad de reanudación)

Confiabilidad Recuperabilidad Restorability (capacidad de recuperación)

Usabilidad Entendible Completeness of Description (Completitud de la descripción)

Usabilidad Aprendizaje Easy of function Learning (Facilidad de aprendizaje de Funciones)

El Resultado (Extracción Reporte de Evaluación)

Ejemplo

Característica de Usabilidad

Sponsor

Usuarios

Responsable Aplicación

Responsable Laboratorio

Testers

Responsable Instalación

RMyA

INFONOR

IRAM

RMyA

Referente Ente

Certificador

Consultor Calidad

Equipo de Trabajo

IRAM

RMyA

RMyA

IRAM

INFONOR

RMyA

RMyA

Equipo en pleno trabajo

Proceso de Evaluación

Administración

Cartera de

Servicios

Administración

DELIVERY – Proyecto de Laboratorio de Ensayos de Software

Calendario

15-21/05 08-14/05 02-07/05

Instalación

Kick Off

Instalación Verificada

Resul-tados

Confiabilidad Confiabilidad evaluada

Usabilidad

Documentación entregada por Cliente

Resultados generados

por Lab entregados

Portabilidad Portabilidad

evaluada

Eficiencia Eficiencia evaluada

22-29/05 23-30/05

Funcionalidad

Celulares entregados por Cliente

Funcionalidad evaluada

28/05 Ensayo Grupo 1 con Usuarios realizado

Celulares disponibles para ensayos

30-06/06

29/05 Ensayo Grupo 2 con Usuarios

realizado

Conclusiones

y Lecciones Aprendidas

Lecciones aprendidas

• Definir previamente el perfil del producto considerando:

– El negocio en que será aplicado

– El usuario al cual está destinado

– Las características específicas del producto

• Esto permite determinar las características a evaluar y el grado de rigurosidad de la prueba.

Lecciones aprendidas (2)

• La arquitectura del software debe explicitar los atributos de calidad del sistema y los valores esperados para los mismos. – Esto permitirá una prueba correcta de conformidad con

requerimientos.

• La funcionalidad es muy importante pero puede implementarse de maneras diversas. – La arquitectura es crítica para lograr la calidad en un

sistema.

• La calidad del sistema debe diseñarse en la arquitectura y puede ser evaluada a través de los atributos presentes en ella.

[Corroborando a Clements, Bachmann y Klein].

La calidad del software es el grado

en el cual el producto exhibe una

combinación deseada de

características

[Extraído de IEEE-1061]

FIN