05_SQuaRE_PAngeleri_Argentina_20150813.pdf

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