Seminario FACUL FACULT TAD Internacional DE INGEN INGENIERÍA IERÍA Y TECNO TECNOLOGÍA LOGÍA LA NORMALIZACIÓN y INFORMÁTICA LAS TICs
¿Cómo evaluar evaluar Productos Productos de Software?
Introducción a SQuaRE y caso de Estudio MyFEPS Expositora: Mg. Paula M. Angeleri paula.angeleri@comunid paula.ange
[email protected] ad.ub.edu.ar
13 Agosto 13 Agosto 2015
© Evaluación de software : beneficios para la industria, Universidad de Belgrano, Buenos Aires, Argentina
1
Seminario FACUL FACULT TAD Internacional DE INGEN INGENIERÍA IERÍA Y TECNO TECNOLOGÍA LOGÍA 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?
© Evaluación de software : beneficios para la industria, Universidad de Belgrano, Buenos Aires, Argentina
2
Seminario FACUL FACULT TAD Internacional DE INGEN INGENIERÍA IERÍA Y TECNO TECNOLOGÍA LOGÍA 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?
© Evaluación de software : beneficios para la industria, Universidad de Belgrano, Buenos Aires, Argentina
2
FACULT FACUL TAD DE INGEN INGENIERÍA IERÍA Y TECNO TECNOLOGÍA LOGÍ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
FACULT FACUL TAD DE INGEN INGENIERÍA IERÍA Y TECNO TECNOLOGÍA LOGÍA 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 variedad y y tipificación de clientes. Globalización de: de: mercados, producción; distribución, competencia y la innovación. • Globalizació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
FACULTAD DE INGENIERÍA Y TECNOLOGÍA 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
Seminario Internacional FACULTAD DE INGENIERÍA Y TECNOLOGÍA 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 © Evaluación de software : beneficios para la industria, Universidad de Belgrano, Buenos Aires, Argentina
6
Seminario Internacional FACULTAD DE INGENIERÍA Y TECNOLOGÍA 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: 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 © Evaluación de software : beneficios para la industria, Universidad de Belgrano, Buenos Aires, Argentina
7
Seminario Internacional FACULTAD DE INGENIERÍA Y TECNOLOGÍA LA NORMALIZACIÓN y INFORMÁTICA LAS TICs
Autos que tienen buena calidad para Paula A.
© Evaluación de software : beneficios para la industria, Universidad de Belgrano, Buenos Aires, Argentina
8
Seminario Internacional FACULTAD DE INGENIERÍA Y TECNOLOGÍA 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: 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
© Evaluación de software : beneficios para la industria, Universidad de Belgrano, Buenos Aires, Argentina
9
Seminario Internacional FACULTAD DE INGENIERÍA Y TECNOLOGÍA LA NORMALIZACIÓN y INFORMÁTICA LAS TICs
Auto ideal para Marcelo:
© Evaluación de software : beneficios para la industria, Universidad de Belgrano, Buenos Aires, Argentina
10
Seminario Internacional FACULTAD FACULTAD DE INGENIERÍA Y TECNOLOGÍA TECNOLOGÍA LA NORMALIZACIÓN y INFORMÁTICA LAS TICs
Modelo de Calidad de producto software QSAT¹:
Comprensible:
No Ambiguo:
Tiene mayor precisión que modelos anteriores. Ej. Métricas y su ponderación
Adaptable:
Mayor claridad que los modelos ISO (detalle de métricas, etc)
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 © Evaluación de software : beneficios para la industria, Universidad de Belgrano, Buenos Aires, Argentina
11
Seminario Internacional FACULTAD FACULTAD DE INGENIERÍA Y TECNOLOGÍA TECNOLOGÍA LA NORMALIZACIÓN y INFORMÁTICA LAS TICs
Modelo de Calidad :
Comprensible:
No Ambiguo:
Precisión para no dejar a la libre interpretación
Adaptable:
Claridad para definir atributos
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
© Evaluación de software : beneficios para la industria, Universidad de Belgrano, Buenos Aires, Argentina
12
Seminario Internacional FACULTAD DE INGENIERÍA Y TECNOLOGÍA 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
A Í G O L O N C E T Y A C A Í I T R Á E I M N R E O G F N I N I E
A Í G O L O N C E T Y A C A Í I T R Á E I M N R E O G F N I N I E
FACULTAD DE INGENIERÍA Y TECNOLOGÍA 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
FACULTAD DE INGENIERÍA Y TECNOLOGÍA 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
Cliente
del cliente/ usuario
Con su necesidad satisfecha
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
FACULTAD DE INGENIERÍA Y TECNOLOGÍA INFORMÁTICA
Certification of Software in Argentina
• Research Proyecto MyFEPS for software evaluation Framework
Seminario Internacional FACULTAD DE INGENIERÍA Y TECNOLOGÍA 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
© Evaluación de software : beneficios para la industria, Universidad de Belgrano, Buenos Aires, Argentina
19
Seminario Internacional FACULTAD DE INGENIERÍA Y TECNOLOGÍA 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.
© Evaluación de software : beneficios para la industria, Universidad de Belgrano, Buenos Aires, Argentina
20
Seminario Internacional FACULTAD DE INGENIERÍA Y TECNOLOGÍA 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
© Evaluación de software : beneficios para la industria, Universidad de Belgrano, Buenos Aires, Argentina
21
FACULTAD DE INGENIERÍA Y TECNOLOGÍA 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).
FACULTAD DE INGENIERÍA Y TECNOLOGÍA INFORMÁTICA
Calidad de producto software Normas ISO/IEC 9126; ISO/IEC 14598; y nueva ISO/IEC 25000
FACULTAD DE INGENIERÍA Y TECNOLOGÍA 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?
FACULTAD DE INGENIERÍA Y TECNOLOGÍA AproximacionesINFORMÁTICA 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 FACULTAD DE INGENIERÍA Y TECNOLOGÍA 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/IEC 25010
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 25000
Nueva edición de la ISO/IEC 9126‐2 Parte 2: Métricas Externas y de la
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
ISO/IEC 9126‐3
SW Engineering – SW product Quality Requirements and Evaluation (SQuaRE) ‐‐ Guide to SQuaRE
Parte 3: Métricas Internas (Segunda ed.)
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
Systems and SW engineering ‐‐ Systems and SW Quality Requirements and Evaluation (SQuaRE) ‐‐ System and SW quality models
FACULTAD DE INGENIERÍA Y TECNOLOGÍA INFORMÁTICA
Antecedentes
Se emite ISO/IEC 25000:2014
Se reemplazan las ISO/IEC 14598‐1 14598‐2 14598‐3 14598‐4
Se reemplazan las ISO/IEC 25000 1ra Ed.
2011
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
FACULTAD DE INGENIERÍA Y TECNOLOGÍA INFORMÁTICA
SQuaRE – I SO/ I EC 25000 Modelo de calidad
Software engineeringSoftware product Qua lity Requirements and Evaluation
FACULTAD DE INGENIERÍA Y TECNOLOGÍA 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
División Gestión de Calidad
2500n
2503n
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
FACULTAD INGENIERÍA Y TECNOLOGÍA SQuaRE ‐ ISO/IEC 25000 vs DE modelo actual de calidad INFORMÁTICA
INGENIERÍA Y TECNOLOGÍA I FACULTAD SO/ I ECDE 25010 Modelo de Calidad INFORMÁTICA de producto
Ref. ISO 25010 Figure 4 – Product quality model
FACULTAD DE INGENIERÍA Y TECNOLOGÍA INFORMÁTICA
I SO/ I EC 250 10 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.
Seminario Internacional FACULTAD DE INGENIERÍA Y TECNOLOGÍA 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
© Evaluación de software : beneficios para la industria, Universidad de Belgrano, Buenos Aires, Argentina
33
Seminario Internacional FACULTAD DE INGENIERÍA Y TECNOLOGÍA ‐ 8.1 Métricas de funcionalidad LA NORMALIZACIÓN y(a) INFORMÁTICA 8.1.1 Métricas externas de Adecuación LAS TICs
ISO/IEC 9126 ‐2 tablas de métricas
• Nombre de la métrica
Adecua ción fu nciona l
• Propósito de la métrica ¿Cuán adecuadas son las fun ciones evaluadas? • Método de aplicación Númer o de fu nciones que son adecuadas para realizar las tareas específicas, comparadas con el nú m ero de funciones evaluadas
• Medición, fórmula y X = 1–A/ B cálculo de elem entos de A = Nro de funciones en que se detectaron pr oblemas en la evaluación B = Nro de funciones evaluadas datos • Int erpretación del valor medido • Tipo escala de métrica • Tipo { unidad} de medida • Entrada para la medición • Referencia I SO/ I EC 12207
0 < = X< = 1 Lo más cerca de 1,0 es lo mejor Absoluta X = Cantidad / Cantidad
A = Cantidad; B = Cantidad Especificación de r equerim ientos. Reporte de evaluación 6.5 Validación 6.3 Aseguramiento de calidad 5.3 Pruebas de calificación © Evaluación de software : beneficios la industria, Universidad de Belgrano, Desarrpara ollador ers; Responsables de ACSBuenos Aires, Argentina • Audiencia objetivo
34
34
Seminario Internacional FACULTAD DE INGENIERÍA Y TECNOLOGÍA ‐ 8.1 Métricas de funcionalidad LA NORMALIZACIÓN y(b) INFORMÁTICA 8.1.1 Métricas externas de Adecuación LAS TICs
ISO/IEC 9126‐2 tablas de métricas
Integridad de implementación funcional
•Nombre de la métrica
•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 X = 1 – A / B
•Medición, fórmula y cálculo
A = Número de funciones faltantes detectadas en la evaluación B = Número de funciones descritas en la especificación de requerimientos
de elementos de datos
0< =X< =1
•Interpretación del valor
Lo más cerca de 1,0 es lo mejor
medido •Tipo de escala de métrica
X = Cantidad / Cantidad
•Tipo {unidad} de medida •Entrada para la medición
Absoluta
(A = Cantidad; B = Cantidad)
Especificación de requerimientos. Reporte de evaluación
•Referencia ISO/IEC 12207
6.5 Validación; 6.3 Aseguramiento de calidad; 5.3 Pruebas de calificación
Desarrollador © Evaluación de software : beneficios para la industria, Universidad de Belgrano, Buenos Aires, Argentina Responsable de ACS
•Audiencia objetivo
35
35
Seminario Internacional FACULTAD DE INGENIERÍA Y TECNOLOGÍA LA NORMALIZACIÓN y INFORMÁTICA ‐ 8.1 Métricas de funcionalidad ISO/IEC 9126‐2 tablas de métricas 8.1.2 Métricas externasLAS deTICs Precisión (c)
Precisión
•Nombre de la métrica
•Propósito de la métrica •Método de aplicación
¿Cuán frecuente los usuarios finales encuentran resultados con exactitud inadecuada?
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 T = Tiempo de operación
de elementos de datos
0
