Post on 12-Apr-2017
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