¿Cómo evaluar Productos de Software?

Transcripción

Seminario Internacional
FACULTAD
DE INGENIERÍA Y TECNOLOGÍA
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
¿Cómo evaluar Productos de Software?
Introducción a SQuaRE y caso de Estudio MyFEPS
Expositora: Mg. Paula M. Angeleri
[email protected]
13 Agosto 2015
© Evaluación de software : beneficios para la industria, Universidad de Belgrano, Buenos Aires, Argentina
1
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Agenda
•
•
•
•
•
¿Para qué evaluar la calidad de un software? Beneficios para la Industria
Ejemplo de un proyecto de evaluación Conclusiones
¿Preguntas y comentarios?
2
FACULTAD DE INGENIERÍA Y TECNOLOGÍA
INFORMÁTICA
¿Para qué evaluar la calidad de un software?
• Software cada vez más complejo, debido a los avances tecnológicos
• Software se utilizan en sistemas críticos
• Aplicaciones cada vez más diversas requieren distintos tipos de evaluaciones
• Modelos de calidad desactualizados e incompletos
• Diversidad de objetivos de negocio para los cuales son desarrollados estos sistemas
• Diversidad de objetivos de evaluación, y de intereses de stakeholders
INFORMÁTICA
Edad Antigua
Edad Media
Edad Moderna
Edad Contemporánea
MERCADO
HOY
•
•
•
•
Clientes más sofisticados.
Menor fidelidad de los clientes. Nuevos usuarios y usos, mayor variedad y tipificación de clientes.
Globalización de: mercados, producción; distribución, competencia y la innovación.
PRODUCTOS •
•
•
•
•
Productos con ciclo de vida corto.
Gran variedad de líneas de productos.
Productos muy adaptados al cliente.
Demanda de calidad y fiabilidad
Productos de nueva tecnología.
Ref.: slide tomada de una presentación de Jorge Ceballos
INFORMÁTICA
Brecha entre lo requerido y lo percibido
¿Qué entendemos por Calidad del software?
Es necesario comprender las
necesidades reales de los usuarios
con tanto detalle como sea posible
(requisitos).
El objetivo no es necesariamente alcanzar una calidad perfecta, sino la necesaria y suficiente para cada contexto de uso a la hora de la entrega y de la utilización por parte de los usuarios. ¿Cuáles son las características inherentes de un producto?
Ref.: slide tomada de una presentación de Jorge Ceballos
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
¿Modelo de Calidad?
La calidad es subjetiva
Cada objeto tiene características que lo
identifican, que nos ayudan a medirla de una
manera más objetiva
Ejemplo: producto AUTO
1. Estética, estilo
2. Color
3. Tamaño
4. Potencia
6
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
•
•
Cada objeto tiene características que lo identifican, que
nos ayudan a medirla de una manera más objetiva
Ejemplo: AUTO
Criterio de prioridades Paula:
1.
Estética, estilo coupée
2.
Color, preferiblemente rojo, negro a azulino
3.
Que “ruja” el motor
4.
Buenas llantas
5.
Focos como “ojos de gato”
6.
Que tenga buen baúl
7
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Autos que tienen buena calidad para Paula A.
8
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
•
•
Cada objeto tiene características que lo identifican, que
nos ayudan a medirla de una manera más objetiva
Ejemplo: AUTO
Criterio de prioridades Marcelo:
1.
Precio
2.
Tamaño
3.
Economía de consumo
4.
Estética, estilo coupée o convertible
5.
Color, preferiblemente azul o negro
9
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Auto ideal para Marcelo:
10
FACULTAD
FACULTAD
TECNOLOGÍA
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Modelo de Calidad de producto software QSAT¹:
Comprensible:
Mayor claridad que los modelos ISO (detalle de métricas, etc)
No Ambiguo:
Tiene mayor precisión que modelos anteriores. Ej. Métricas y su
ponderación
Adaptable:
A la mayor cantidad de productos de software
En la mayor cantidad de contextos.
A las necesidades de las empresas, y objetivos de stakeholders
Compatible:
Con la mayoría de todos los modelos existentes. Ej.ISO/IEC
9126, 25010
Ref: ¹ QSAT por el nombre de sus creadores Quality model de Sorgen, Angeleri y Titiosky
11
FACULTAD
FACULTAD
TECNOLOGÍA
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Modelo de Calidad:
Comprensible:
Claridad para definir atributos
No Ambiguo:
Precisión para no dejar a la libre interpretación
Adaptable:
A la mayor cantidad de productos de software
En la mayor cantidad de contextos.
A las necesidades de las empresas, y objetivos de stakeholders
Completo:
Que defina todas las propiedades que se puedan querer
evaluar
12
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Para qué se evalúa un software?
• Para dar visibilidad a “alguien” sobre cierta calidad esperada
• Para encontrar debilidades, que permitan su mejora de la manera más eficiente
• Para dar confianza © Evaluación de software : beneficios para la industria, Universidad de Belgrano, Buenos Aires, Argentina
13
INFORMÁTICA
INFORMÁTICA
INFORMÁTICA
Beneficios para la industria
•
•
•
•
Conocer la calidad de su propio producto SW
Comparar su producto con uno similar
Marca de reconocimiento (certificación)
Conocer si su producto satisface las necesidades de los clientes
• Mejorar el proceso de Desarrollo, garantizando un mejor Mantenimiento
INFORMÁTICA
El proceso de certificación de producto y la cadena de valor:
Cliente
Necesidad
de un producto de software
Desarrollo del producto
Especificación
y datos de entrada para el
desarrollo del producto Atributos internos, externos y de uso
Interpretación de la especificación (DE, DS, atributos)
Instalación y uso por parte del cliente/ usuario
Producción
Verificación y validación del producto
Organización desarrolladora
Input para el diseño de la prueba
Ref.: slide tomada de una presentación de IRAM
Producto terminado
Certificación de calidad de producto
Cliente
Con su necesidad satisfecha
INFORMÁTICA
Certification of Software in Argentina
• Research Proyecto MyFEPS for software evaluation Framework Seminario Internacional
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Proyecto de Investigación
de la Facultad de Tecnología Informática:
MyFEPS: Metodologías y framework para la Evaluación de Productos de Software
Investigadores: Paula Angeleri y Amos Sorgen (co‐directores) –
Rolando Titioski y Jaquelina Wuille Bille (investigadores) –
Martín Santi, Agustín Ventura, Diego Ardizzone (tesistas)‐
Oriana Pozzo y Juan Nenna (becarios)‐
Estela Terano, Romina Méndez, Joaquín Freijóo y Gustavo Rodrígue (alumnos)
y colaboración de empresa TSOFT
Fecha de inicio: 15-06-2010

Fecha de finalización: 15-06-2014
19
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Área Temática del Proyecto de Investigación MyFEPS: Ciencias Aplicadas
Ingeniería de Software
Calidad
Problemática:
• El proceso de evaluación de un producto de software es complejo, y muy pocas organizaciones lo llevan a cabo con la calidad requerida, la mayoría se focaliza sólo en testing de software .
• Las normas y modelos existentes no habían sido actualizados, Tampoco existen guías de aplicación que faciliten su uso en la industria.
20
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Objetivo General del proyecto:
• Elaborar una meta‐metodología de evaluación de software • Diseñar un framework de evaluación que incluya recomendaciones de métodos y herramientas
Objetivos Específicos:
• Identificar factores que influencien en la evaluación, como ser los intereses de los stakeholders, riesgos, etc.
• Establecer criterios para la ponderación de atributos del producto
• Establecer un modelo de Calidad de SW más completo y actualizado
que el de ISO/IEC 9126‐1, etc.
• Apoyar el proceso nacional de certificación de software
21
INFORMÁTICA
Resultados hasta el momento
•
Se definió un modelo de calidad de productos de software que es completo, claro, comprensible y compatible con los modelos de calidad existentes (ISO, IBM, Mc Call, Boehm, etc)
•
Se identificó la necesidad de introducir grados de rigurosidad con los que se quiera evaluar las distintas características de un producto de software.
•
Se definió la Arquitectura del framework de evaluación
•
Se está desarrollando un modelo de evaluación confiable adaptable a diversos objetivos de evaluación, a las distintas normas internacionales y al grado de rigurosidad con que se quieran obtener los resultados de la evaluación.
•
Se está haciendo Transferencia de conocimiento (publicaciones, proy. laboratorio de Testing TSOFT, conferencias, academia).
INFORMÁTICA
Calidad de producto software
Normas ISO/IEC 9126; ISO/IEC 14598; y nueva ISO/IEC 25000
INFORMÁTICA
Antecedentes
• “Hay poca evidencia en que cumplir un modelo de procesos asegure la calidad del producto. La estandarización de los procesos garantiza la uniformidad en la salida de los mismos, lo que puede incluso institucionalizar la creación de malos productos”(Kitchenham y Pfleeger, 1996).
• Situación general del Mercado para la Industria Software
• ¿Qué efecto tiene esta situación en los productos?
• Cambia el enfoque tradicional de las organizaciones. Profundo cambio cultural, de valores y percepciones sobre el trabajo y su resultado.
Ejemplos de SW que no cumpliera con los requisitos implícitos y/o explícitos?
INFORMÁTICA
Aproximaciones a la calidad del SW:
…La calidad en el ciclo de vida
Producto
Proceso
influencian
depende de
Mediciones
del proceso
influencian
influencian
Atributos
externos
de
calidad
Atributos
internos de
calidad
Calidad del
proceso
Efecto producto
depende de
Medidas
internas
Atributos
de calidad
en uso
depende de
Medidas
externas
Ref. figura B.2 IRAM‐ISO/IEC 25000
Contextos
de uso
Medidas de
calidad en uso
Antecedentes
INFORMÁTICA
La familia ISO/IEC 25000 es el resultado de la evolución de otras normas:
• ISO/IEC 9126 (modelo de calidad del producto software)
• ISO/IEC 14598 (proceso de evaluación de productos software) ISO 9126 fue publicada por primera vez en el año 1991, y fue posteriormente reemplazada durante el 2001 por una familia de normas, (partes 1; 2; 3 y 4):
ISO/IEC 9126:1991 Evaluación del producto de software ‐
Carácterística
s de calidad y directrices para su uso
Se desdobla
ISO/IEC 9126 como modelo
de calidad e ISO/IEC 14598 como proceso
de evaluación
de conformidad
Nueva versión del modelo de calidad
ISO/IEC 9126
Nueva edición de la ISO/IEC 9126‐2 Parte 2: Métricas
Externas
y de la ISO/IEC 9126‐3
Parte 3: Métricas
Internas
(Segunda ed.)
ISO/IEC 25000
SW Engineering – SW product Quality Requirements and Evaluation (SQuaRE) ‐‐
Guide to SQuaRE
ISO/IEC 9126‐4
Parte 4: Métricas de Calidad en Uso
Nuevas partes ISO/IEC 14598‐2
Part 2: Planificación y Gestión
ISO/IEC 14598/3 Parte 3: Proceso
para desarrolladores
ISO/IEC 25010
Systems and SW engineering ‐‐
Systems and SW Quality Requirements and Evaluation (SQuaRE) ‐‐ System and SW quality models
INFORMÁTICA
Antecedentes
Se reemplazan las ISO/IEC 14598‐1
14598‐2
14598‐3
14598‐4
Se reemplazan las ISO/IEC 25000 1ra Ed.
2011
Se emite
ISO/IEC 25000:2014
Systems and software engineering ‐‐
Systems and software Quality Requirements and Evaluation (SQuaRE) ‐
‐ Guide to SQuaRE
ISO/IEC 9126‐3
Software engineering ‐Product quality Part 3: Internal Metrics (Segunda
ed.)
2014
2012
Se reemplaza la ISO/IEC 9126‐1
INFORMÁTICA
SQuaRE –
I SO/ I EC 25000
Modelo de calidad
Software engineeringSoftware product Qua lity
Requirements and Evaluation
Organización de la serie de estándares SQuaRE
INFORMÁTICA
Divisiones dentro del modelo SQuaRE División Modelo de Calidad 2501n
División Requisitos de Calidad
2503n
División Gestión de Calidad 2500n
División Evaluación de Calidad
2504n
División Medición de Calidad 2502n
Extensión División 25050 ‐ 25099
Ref.: IRAM‐ISO/IEC 25000 ‐ Figura 1
SQuaRE ‐ ISO/IEC 25000 vs modelo actual de calidad
INFORMÁTICA
INGENIERÍA Y TECNOLOGÍA
I FACULTAD
SO/ I ECDE
25010
Modelo de CalidadINFORMÁTICA
de producto
Ref. ISO 25010 Figure 4 – Product quality model
INFORMÁTICA
I SO/ I EC 25010 Calidad en USO
Ejemplos de mediciones de Calidad en el USO se pueden ver en ISO/IEC TR 9126‐4
(a ser reemplazada por ISO/IEC 25024).
Referencia: ISO/IEC Table A.1 – Comparison with the previous model in ISO/IEC 9126-1:2001.
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Fortalezas del modelo ISO
• Consensuado internacionalmente
• Bien estructurado • Medición de calidad interna, externa y en el uso
33
LA NORMALIZACIÓN
y
INFORMÁTICA
8.1.1 Métricas externas de Adecuación (a)
LAS TICs
FACULTAD
ISO/IEC 9126‐2 tablas de métricas ‐
8.1 Métricas de funcionalidad
• Nom bre de la m ét rica
Ade cu a ción fu n cion a l
• Propósit o de la m ét rica ¿Cuán adecuadas son las funciones evaluadas?
• Mét odo de aplicación
Núm ero de funciones que son adecuadas para realizar las t areas
específicas, com paradas con el núm ero de funciones evaluadas
• Medición, fórm ula y
X = 1 – A/ B
cálculo de elem ent os de A = Nro de funciones en que se det ect aron problem as en la evaluación
B = Nro de funciones evaluadas
dat os
• I nt erpret ación del valor 0 < = X < = 1
m edido
Lo m ás cerca de 1,0 es lo m ej or
• Tipo escala de m ét rica Absolut a
• Tipo { unidad} de
m edida
• Ent rada para la
m edición
• Referencia I SO/ I EC
12207
X
= Cant idad / Cant idad
A = Cant idad;
B = Cant idad
Especificación de requerim ient os.
Report e de evaluación
6.5 Validación
6.3 Aseguram ient o de calidad
5.3 Pruebas de calificación
© Evaluación
para la industria, Universidad
de Belgrano,
Desarrolladorers;
Responsables
de ACSBuenos Aires, Argentina
• Audiencia
objdeetsoftware
ivo : beneficios
34 34
Seminario
Internacional
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
8.1.1 Métricas externas de Adecuación (b)
LAS TICs
•Nombre de la métrica
Integridad de implementación funcional
•Propósito de la métrica
¿Cuán completa es la implementación de acuerdo a la especificación de requerimientos?
•Método de aplicación
Realizar pruebas funcionales (caja negra) del sistema según especificación de requerimientos. Contar el Nº de funciones faltantes detectadas en la evaluación y compararlas con el Nº de funciones descritas en la especificación de requerimientos
•Medición, fórmula y cálculo de elementos de datos
X = 1 – A / B
A = Número de funciones faltantes detectadas en la evaluación
B = Número de funciones descritas en la especificación de requerimientos
0 < = X < = 1
•Interpretación del valor medido
•Tipo de escala de métrica
Absoluta
•Tipo {unidad} de medida
X = Cantidad / Cantidad (A = Cantidad; B = Cantidad)
•Entrada para la medición
Especificación de requerimientos.
Lo más cerca de 1,0 es lo mejor
Reporte de evaluación
•Referencia ISO/IEC 12207
6.5 Validación; 6.3 Aseguramiento de calidad; 5.3 Pruebas de calificación Desarrollador •Audiencia objetivo
Responsable de ACS 35 35
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
8.1.2 Métricas externas de Precisión (c)
•Nombre de la métrica
Precisión
•Propósito de la métrica
¿Cuán frecuente los usuarios finales encuentran resultados con exactitud inadecuada?
•Método de aplicación
Registrar el número de resultados con exactitud inadecuada
•Medición, fórmula y cálculo X = A / T
A = Nro de resultados encontrados por usuarios c/nivel de exactitud dif. al requerido
de elementos de datos
•Interpretación del valor medido
•Tipo de escala de métrica
•Tipo {unidad} de medida
•Entrada para la medición
T = Tiempo de operación
0 < = X Lo más cerca de 0,0 es lo mejor
Ratiio
X = Cantidad / Tiempo
A = Cantidad
B = Tiempo
Especificación de requerimientos.
Reporte de pruebas
6.5 Validación
6.3 Aseguramiento de calidad
© Evaluación de software : beneficios
para la industria, Universidad de Belgrano, Buenos Aires, Argentina
Desarrollador // Usuarios
•Audiencia objetivo
•Referencia ISO/IEC 12207
36 36
Comparación entre características
y sub‐características
de Seminario Internacional
FACULTAD
DE
ISO/IEC 25010 respecto de ISO/IEC 9126‐1:2001.
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Tabla A.1 Comparación con el modelo previo en ISO/IEC 9126‐1:2001
Cláusula ISO/IEC 25010
ISO/IEC 9126‐1 Notas
4.1
Calidad en uso
Calidad en uso
4.1.1
Eficacia
Eficacia
4.1.2
Eficiencia
Productividad
4.1.3
4.1.3.1
4.1.3.2
4.1.3.3
4.1.3.4
4.1.4
4.1.4.1
4.1.4.2
Satisfacción
Satisfacción
Utilidad
Confianza
Placer
Comodidad
Libre de riesgo
Seguridad
Riesgo de daño económico
Riesgos de no causar daños a la salud de las personas
La calidad en uso es ahora un sistema de calidad
Nombre alineado con eficiencia en
ISO/IEC 25062 e ISO 9241‐11
No subcaracterizado previamente
”
”
”
No subcaracterizado previamente
”
37
Comparación entre características
y sub‐características
de Seminario Internacional
FACULTAD
DE
ISO/IEC 25010 respecto de ISO/IEC 9126‐1:2001.
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Cláusula ISO/IEC 25010
ISO/IEC 9126‐1
4.1.4.3 Riesgos de daño al medio ambiente
4.1.5
Contexto de cobertura
4.1.5.1 Contexto de integridad
Notas
”
4.2.1.1 Integridad funcional
Problema de calidad implícito hecho explícito Nueva sub‐característica (es importante que un producto sea utilizable en todos los contextos de uso requeridos)
Nueva sub‐característica (permite que un producto sea utilizado en nuevos contextos de uso)
Calidad interna y Calidad interna y externa combinada como calidad externa
de Producto
Funcionalidad
Nuevo nombre es más precisa, y evita la confusión con otros significados de "funcionalidad"
La cobertura de las necesidades establecidas
4.2.1.2 Corrección funcional
Precisión
4.1.5.2 Flexibilidad
4.2
Calidad de Producto
4.2.1
Idoneidad funcional
Más general que la precisión
4.2.1.3 Adecuación funcional Idoneidad
La cobertura de las necesidades implícitas
Interoperatividad Trasladado a la Compatibilidad
Seguridad
Ahora una característica
38
FACULTAD
Cláusula
4.2.6.2
4.2.6.3
4.2.6.4
4.2.6.5
4.2.7
4.2.7.1
4.2.7.2
4.2.7.3
4.2.7.4
4.2.7.5
4.2.8
4.2.8.1
LA NORMALIZACIÓN
y
Notas
INFORMÁTICA
ISO/IEC 25010
ISO/IEC 9126‐1
”
LAS TICs
Integridad
”
No rechazo
”
Responsabilidad
”
Autenticidad
Mantenibilidad
Mantenibilidad
Nueva Sub‐característica
Modularidad
Nueva Sub‐característica
Reusabilidad (capacidad de ser reutilizado)
Analisabilidad (capacidad de ser Analisabilidad (capacidad de analizado)
ser analizado)
Modificabilidad (capacidad de ser Modificabilidad (capacidad de Nombre más preciso combinando variabilidad y estabilidad
modificado)
ser modificado)
Capacidad de ser probado
Capacidad de ser probado
Portabilidad
Adaptabilidad (capacidad de ser adaptado)
Instalabilidad (capacidad de ser instalado)
Portabilidad
Adaptabilidad (capacidad de ser adaptado)
4.2.8.2
Instalabilidad (capacidad de ser instalado)
Trasladado a la Compatibilidad
Co‐existencia
4.2.8.3 Reemplazabilidad (capacidad de ser Reemplazabilidad (capacidad © Evaluación
de software : beneficios para la industria,
Universidad de Belgrano, Buenos Aires, Argentina
39
reemplazado)
de ser reemplazado)
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Proceso de evaluación de calidad de producto SW Norma IRAM‐ISO/IEC 14598‐1 (apartado 6)
Establecer los requisitos
de evaluación
Especificar la
evaluación
Realizar la
evaluación
Diseñar la
evaluación
40
Proceso de evaluación
deINGENIERÍA
calidad de
producto SW
FACULTAD
DE
Y TECNOLOGÍA
Norma
LA NORMALIZACIÓN
y
INFORMÁTICA
I RAM-I
LASSO/
TICsI EC 14598
Realizar la evaluación
Certificar
Evaluar los resultados
Comparar con los criterios
Hacer mediciones
Elaborar el Plan de Evaluación
Establecer requisitos de evaluación
Establecer el propósito de la evaluación
Identificar los tipos de producto a evaluar
Especificar el modelo de calidad
Seleccionar Métricas
ISO/IEC 9126‐1
Características de calidad
ISO/IEC 9126‐2 Métricas ext.
ISO/IEC 9126‐3 Métricas int.
ISO/IEC 14598‐6 Módulos de evaluación
Establecer niveles de puntuación p/métricas
Establecer los criterios de evaluación
Diseñar la evaluación
Especificar la evaluación
41
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
42
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Proyecto de evaluación de la Red
Social Académica
ConexionUB
43
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Modelo de Calidad QSAT: estructura
44
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Modelo de calidad QSAT
45
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Modelo de Calidad QSAT (1/3)
N Características Fundamentales
Sub - características
1 Adaptabilidad
a diferentes entornos
a diferentes idiomas
2 Calidad de los artefactos
Tipo X
Trazabilidad
Modularidad
Reusabilidad
Capacidad de ser analizado
3 Constancia
independiente del número de usuarios
independiente del número de actores
que no son los usuarios
independiente del la cantidad de
información acumulada
4 Correctitud
de Datos
de Procesos
de la Documentación
5 Cumplimiento legal
referente a la funcionalidad
referente a la facilidad de uso
referente a la tolerancia a fallas
referente a la recuperabilidad de fallas
referente al mantenimiento
referente a la eficiencia
referente a su portabilidad
6 Efectividad
Cobertura de las funcionalidades útilies
Ausencia de funcionalidades inutilies
Cumplimiento con las capacidades
esperadas
46
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Modelo de Calidad QSAT (2)
7 Eficiencia
en la Interfaz del Usuario
en los tiempos de respuesta
en la utilizacion de memoria interna
en la utilizacion de almacenaje externo
en la utilizacion de CPU
en la utilizacion de otro hardware
Disponibilidad
Productividad
8 Estandarizado
en su IU
como componente
9 Facilidad de Instalación
Primera instalacion
Upgrades
10 Manejo de fallas
Previniendolas
Recuperándose
11 Facilidad de Mantenimiento
Eficiencia para corregir errores
Eficiencia para ampliar y mejorar
Eficiencia para re-instalar versiones
Estabilidad después de un cambio
Capacidad de ser testeado
Portabilidad
12 Satisfaccion de los stakeholders que no son
usuarios
Considerado util
Considerado apropiado
Considerado confiable
13 Satifaccion subjetiva de los usuario
Confort físico
en la Entrada manual de información
Efectividad del Help
en el Acceso a las funciones
en la Comprensión de las salidas del
sistema
en la Estética
en el Conocimiento del sistema
Satisfaccion total
47
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Modelo de Calidad QSAT (3)
14 Usabilidad (objetiva)
en el Aprendizaje
Coherencia de la IU
Confort físico
Efectividad del Help
en el Acceso a las funciones
en la Comprensión de las salidas del
sistema
en la Estética
en el Conocimiento del sistema
Satisfaccion total
15 Seguridad de no causar daños
Físicos
Materiales
Económicos
Al medio ambiente
16 Seguridad Informática
de datos
de funciones
48
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Atributos QSAT
QSAT define “Atributo” de una Subcaracterísticas del
modelo, a una propiedad que posee el producto de
software, que es evaluada usando métricas bien definidas.
Por ejemplo: “El número de errores en los datos detectados
en uso en un período dado”, es un atributo
49
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Ej. Característica, Subcaracterística, Atributo, Métrica (1/2)
Característica Básica: Satisfacción de los usuarios
En qué medida el producto software hace sentir confortable al
usuario, en el contexto de su uso, de modo que los usuarios tienen
una subjetiva percepción de satisfacción por el uso del sistema.
Evaluable en términos de opiniones subjetivas de los usuarios.
Subcaracterísticas:
Confort físico
-
Satisfacción en la Estética
Satisfacción en el Acceso a las funciones
Satisfacción en la Entrada manual de información
Satisfacción en la Comprensión de las salidas del sistema
Satisfacción en el Aprendizaje
Satisfacción total
50
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Ej. Característica, Subcaracterística, Atributo, Métrica (1/2)
Sub-característica: Confort físico:
Se evalúa en que medida el sistema es percibido como confortable por el
operador, en el contexto de su uso diario y repetitivo.
Es evaluable en términos de opiniones subjetivas de los usuarios. Comparable
con100% de satisfacción
Atributo: Grado de Confort percibido en entorno de uso
Métrica:
Preguntar a N usuarios:
¿De o a 100 cuan confortable le resulta trabajar con el sistema? : El resultado se registra en
la variable GCFi, (Grado de Calidad Físico del Usuario i).
A continuación se registra el promedio en la variable M (media)
M = SUM(GCFi) / N
51
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
¿Cómo calcular el grado de calidad de una
Característica Básica?
El grado de calidad de una Característica Básica
resultará de la composición ponderada de sus Subcaracterísticas.
El grado de calidad de cada Sub-característica a su vez
resultará de la composición ponderada de sus Sub-subcaracterísticas.
Este proceso se continúa hasta llegar a los Atributos que
se evalúan a partir la composición de las mediciones de sus
Métricas.
52
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Fortalezas del modelo QSAT
• Bien estructurado
• Medición de calidad interna, externa y en el uso. Definición del contexto a nivel de atributos
• Establece criterio de ponderación de mediciones
• Métricas claras y actualizadas
• Acompañado por un framework que Facilita la evaluación
53
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Falencias del modelo QSAT, a la fecha
• No fue consensuado internacionalmente
• Los proyectos de evaluación realizados para su validación resultaron insuficientes, por la cantidad de características a evaluar y las necesidades de cada proyecto. © Evaluación de software : beneficios para la industria, Universidad de Belgrano, Buenos Aires, Argentina
54
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Proceso de Evaluación (basado en proceso ISO
55
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
El proyecto
56
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
El sistema
LAS TICs
• Herramienta de soporte accesible por Internet para: – estudiar, realizar trabajos individuales o en equipos, interactuar y comunicar.
• Abanico de recursos digitales disponibles.
–
–
–
–
Mecanismo de autorización
Accesibles por todos los participantes.
Todo lo elaborado disponible para los autorizados.
Material en el servidor o de la nube
• Organizado en espacios de trabajo accesibles por autorizados:
– Alumnos
– Docentes
– Invitados
• Autorizaciones
– Docente: establece la potestad de cada uno.
– Alumnos: establece quién puede ver y modificar sus documentos.
57
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Vistas evaluadas, principales stakeholders:
• Profesor Alumno
58
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
59
FACULTAD
El profesor
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
• Incorpora y comparte: – programa, cronograma, trabajos prácticos, la estructura de la materia y sus contenidos.
– materiales (digitales) de la cátedra.
– videos de sus clases.
• Transmite consignas.
• Accede a: – todos los trabajos de alumnos.
– evaluaciones (hoja de parcial virtual).
• Modera debates.
• Responde consultas.
• Hace encuestas y evalúa las respuestas.
60
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
61
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
62
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
63
FACULTAD
El alumno
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
• Se informa sobre: – planificación, contenidos y actividades de la materia
• Participa en – encuestas, debates y otras actividades.
• Accede a:
– materiales del curso (textos, videos, imágenes, etc.)
– consignas del docente.
• Incorpora material en su propio espacio – para uso propio o compartir
• Interactúa con: – docentes y compañeros
• Consulta:
– docente.
– agenda del curso.
64
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
Beneficio para Universidad
LAS TICs
Actualmente en uso en varias cátedras de la Facultad de Ingeniería y Tecnología Informática, permite:
• Acceso al conocimiento producido (Internet).
• Actualización de la biblioteca virtual.
• Puesta a disposición de los docentes de una plataforma de trabajo state of the art.
• Control sobre contenidos y transacciones, por tratarse de una red social cerrada. • Presencia institucional en la web.
• Formación a distancia
65
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Proceso de Evaluación (basado en proceso ISO
66
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Objetivo de la Evaluación: medir el grado de satisfacción de los
Stakeholders
Características bajo estudio:
1) Satisfacción de los stakeholders que no son usuarios
En qué medida se desempeña el Sistema en el contexto de su uso,
de modo que los stakeholders que no son usuarios tienen una subjetiva percepción de
satisfacción del uso del sistema. Evaluable en términos de opiniones subjetivas de los
stakeholders que no son usuarios. Comparable con 100% de satisfacción
Subcaracterísticas: Considerado Útil, Apropiado, Confiable
Por cada
Atributo de
Subcaracterística se
calcula su
métrica
Atributo
Métrica
Porcentaje de
Cobertura de
Funciones
Útiles
Con un CUESTIONARIO conciliar la siguiente información
1. Sea NS (número de stakeholders)
2. Para cada módulo X
2.1.
Para suma=0 e i=1 hasta NS, de 1 en 1, hacer
2.1.1.
Obtener CFRi (Cobertura de Funciones
Útiles para el Modulo X, según la opinión del
StakeHolders “i”. Se mide entre 0 y 1).
2.1.2.
suma+=CFRi
fin
3. Valoración del modulo X = Suma/NS.
67
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Subcaracterística: Considerado apropiado
Atributo
Porcentaje de
Funciones
inútiles
Métrica
1. Sea NS (numero de stakeholders)
2. Para cada modulo X
2.1.
Para suma=0 e i=1 hasta NS, de 1 en 1, hacer
2.1.1.
Obtener PFIi (Porcentaje de Funciones
inútiles para el Modulo X, según la opinión del
StakeHolders “i”. Se mide entre 0 y 1).
2.1.2.
suma+=PFIi
fin
3. Valoración del modulo X = Suma/NS.
Subcaracterística:
Considerado confiable
Atributo
Grado de
Confiabilidad
percibida en
Uso
Métrica
1. Para cada modulo X
1.1.
NS (numero de stakeholders)
1.2.
Para sumG=0 e i=1 hasta NS, de 1 en 1, hacer
1.2.1.
Obtener el GCIi(Grado de confiabilidad del
modulo i medida entre 0 y 1)
1.2.2.
SumG+=GCIi
fin
2. Valoración del modulo X = SumG/NS.
68
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Establecer criterio de ponderación de atributos, registrando el grado de importancia relativa para cada Stakeholder no usuario
Completar por cada Stakeholder no
usuario que participa de la
evaluación: Ejemplo Stakeholder 1
Muy
importante
12 Satisfacción de los stakeholders
que no son usuarios
12.1. Considerado Util
12.2 Considerado Apropiado
12.3 Considerado Confiable
Importante
Medianamente
importante
Algo
importante
Nada
importante
Puntuacion Stakeholder 1
Respuestas Stakeholder 1
x
1
x
0,75
x
0,5
69
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Establecer criterio de ponderación de atributos, promediando las respuestas de Stakeholders
Peso SubcaPuntuacion racterística
Stakeholder 3
SC
1
0,75
0,75
0,75
1
0,75
0,5
0,75
1
0,83
0,83
0,75
70
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Características bajo estudio:
1) Satisfacción subjetiva de los usuarios
En qué medida se desempeña el Sistema en el contexto de su uso,
de modo que los usuarios tienen una subjetiva percepción de satisfacción del
uso del sistema. Evaluable en términos de opiniones subjetivas de los
usuarios. Comparable con 100% de satisfacción
Subcaracterísticas:
• Confort Físico
• Satisfacción en el acceso a las funciones
• Satisfacción en cuanto a la estética
• Satisfacción Total
71
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Establecer criterio de ponderación de atributos, registrando el grado de importancia relativa para cada Usuario
Completar por cada Usuario que
participa de la evaluación: Ejemplo
Usuario 1
Muy
importante
Importante
Algo
importante
Nada
importante
Puntuacion Usuario 1
Respuestas Usuario 1
13. Satisfaccion de los Usuarios
13.1 Confort Fisico
13.2 En el Acceso a las funciones
13.4. En la Estética
13.6 Satisfacción total
Medianamente
importante
x
1
x
x
x
0,75
0,75
1
72
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Establecer criterio de ponderación de atributos, promediando las respuestas de los Usuarios
Peso SubcaPuntuacion Puntuacion Puntuacion racterística
Usuario 1 Usuario 2 Usuario 3
SC
1
0,75
0,75
0,75
1
1
0,75
0,75
0,75
1
0,75
1
0,83
0,92
0,75
0,92
73
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Calcular el Grado de Calidad de cada Característica, y luego del Producto software
Característic
Subcaracterística (SC)
a Básica (CB)
Grado de
Calidad
de la SC
Peso
de la
SC
Grado de
Grado de
CALIDAD
Calidad de Peso CB
Del
la CB
Producto
0,70 Producto Conexión UB
0,71
12 Satisfacción de los stakeholders que no son usuarios
12.1. Considerado Útil
12.2 Considerado Apropiado
12.3 Considerado Confiable
0,73
0,70
0,69
0,83 El grado de Calidad
0,83 de SC se obtuvo del
0,75 valor promedio del
puntaje dado por
stakeholders
0,70
13. Satisfaccion de los Usuarios
13.1 Confort Físico
13.2 En el Acceso a las funciones
13.4. En la Estética
13.6 Satisfacción total
0,74
0,64
0,70
0,72
0,83
0,92
0,75
0,92
0,83
El peso de SC se obtuvo
del valor promedio de los
pesos sugeridos por los
stakeholders (entre 0 y 1)
0,92
El grado de calidad de la CB se obtuvo multiplicando
el Grado de calidad de cada SC por su Peso,
sumando los resultados y dividíendolos por la
sumatoria de Pesos de SCs
74
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Resultado de la evaluación del software Prosys Ecommerce
75
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Situación en Argentina
• Software certificados (MGOL, Master of Faith, OCASA, y en proceso de certificación software Gobierno de Chile).
• Academia: Universidad de Belgrano, Univ. Morón, Univ. Nac. De La Plata, Univ. Nac. de la Matanza, Univ. de La Punta.
• Industria: 3 software durante MyFEPS, 3 posteriores, 2 empresas capacitadas.
76
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Tesistas que participaron del proyecto MyFEPS
• Agustín Ventura
“Evaluación del grado de calidad de una aplicación de Gestión de Clínicas usando el Framework MyFEPS”
• Martín Santi
“Evaluación del grado de calidad de una aplicación E‐Commerce usando el Framework MyFEPS”
• Diego Ardizone
“Desarrollo de una aplicación BI para mostrar los resultados de una Evaluación de calidad realizada con el Framework MyFEPS”
77
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Resultados de la Tesina
• Software tiene calidad aceptable para los usuarios
• Pero requiere mejoras, como ser que la Ayuda del Help sea consistente con las pantallas (Coherencia de Interfaz) y en poder corregir datos mal cargados, como ser Nro. Tarjeta de crédito (Ingreso Manual de Información)
78
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Conclusiones
1. Es importante poder medir la calidad de un software,
2. Lo importante es usar un modelo de calidad de
producto, tanto en el Desarrollo como en el
Mantenimiento
3. Dar visibilidad a la Alta Gerencia !!!
4. Certificar software Críticos (que impliquen alto riesgo)
79
FACULTAD
LA NORMALIZACIÓN
y
INFORMÁTICA
LAS TICs
Comentarios
80

¿Cómo evaluar Productos de Software?

Transcripción

Documentos relacionados

Seminario de High Impact Leadership - México

Seguridad en Internet - Manuel Fernandez Barcell