WQM Calero

1

Modelos de calidad softwareCalidad y Medición de Sistemas de Información

Dra. Coral CaleroGrupo ALARCOS

E.S. Informática - Ciudad RealUniversidad de Castilla-La Mancha

[email protected]

2

PLANIFICACIÓNSemana 1 (7/11): Introducción a la calidad, modelos de calidad, ISO 9126. Ejemplos de modelos de calidad: PQM, WQM (Coral)Semana 2 (14/11): Formalización de métricas, ontología de la medición (Coral)Semana 3 (21/11): Método de definición de medidas (Manuel). Ejemplo de uso del método: etapas de definición y validación formal (Manuel)Semana 4 (28/11): Ejemplo de uso del método: etapa de validaciónempírica y ampliación del método (Manuel)Semana 5 (12/12): Calidad de datos (Ismael)Semana 6 (19/12): Ejemplos (Ismael)Semana 7 (9/1): Entrega de trabajosSemana 8 (16/1): Sesión de exposiciones 1Semana 9 (23/1): Sesión de exposiciones 2

Las clases serán de 4:30 a 7:30 de la tarde excepto las sesiones de exposiciones que serán de 4:30 a 8:30

2

3

Modelos de calidad software

1. Introducción2. La ISO91263. Modelos de calidad

3.1. WQM3.2. PQM3.3. PDQM3.4. Calidad de portlets

4. Conclusiones

4

¿Cómo saber cual es mayor?

8,05 cm

INTRODUCCIÓN

3

5

Las medidas son un buen medio para entender, monitorizar, controlar, predecir y probar el desarrollo software y los proyectos de mantenimiento (Briandet al., 1996)En general, la medición persigue tres objetivosfundamentales (Fenton y Pfleeger, 1997):

entender qué ocurre durante el desarrollo y el mantenimientocontrolar qué es lo que ocurre en nuestros proyectosmejorar nuestros procesos y nuestros productos

INTRODUCCIÓN

6

Las medidas pueden ser utilizadas para que los profesionales e investigadores puedan tomar las mejores decisiones (Pfleeger, 1997).

INTRODUCCIÓN

MEDIDAS COMO MEDIOS PARAASEGURAR LA CALIDAD

EN LOS PRODUCTOS SOFTWARE

4

7

La médición del software es un término que se asigna a un amplio rango de actividades diversas, por ejemplo:

medidas y modelos de estimación de coste y esfuerzomodelos y medidas de productividadaseguramiento y control de calidad.recogida de datosmedidas y modelos de calidadmodelos de fiabilidadmodelos y evaluación de ejecucióncomplejidad computacional o algorítmica.medidas estructurales o de complejidad

INTRODUCCIINTRODUCCIÓÓNN

8

En software hay tres clases de entidades cuyos atributos podemos querer medir: Procesos: Son actividades software que normalmente conllevan el factor tiempo. Productos: son entregables, artefactos o documentos generados en el ciclo de vida del software. Recursos: son todos aquellos elementos que hacen de entrada a la producción software.


5

9

Atributos a medir: Procesos

el tiempo (duración del proceso), el esfuerzo (asociado al proceso) el número de incidentes de un tipo específico que se dan durante el proceso (por ejemplo el número de errores de requisitos encontrados durante la construcción de la especificación).


10

Atributos a medir: Productos:

la fiabilidad del código, la entendibilidad de un documento de especificación, la mantenibilidad del código fuente la longitud, funcionalidad, modularidad o corrección sintáctica de los documentos de especificación.


6

11

Atributos a medir: Recursos:

el personal, los materiales, las herramientas y los métodos,el coste,la productividad.


12

Últimamente ha aparecido un gran número de medidas para capturar atributos del software de una forma cuantitativa (también para la web). Sin embargo, muy pocas medidas han sobrevivido a la fase de definición y se usan en la industria.


7

13

Esto se debe a múltiples problemas, entre ellos:Las medidas no se definen siempre en el contexto del objetivo de interés industrial que se pretende alcanzarIncluso si el objetivo es explícito, las hipótesis experimentales a menudo no se hacen explícitasLas definiciones de medidas no siempre tienen en cuenta el entorno o contexto en el que serán aplicadasNo siempre es posible realizar una validación teóricaadecuada de la medida porque el atributo que queremos medir no siempre está bien definidoUn gran número de medidas nunca se ha validado empíricamente


14

Esta situación ha conducido frecuentemente a cierto grado de ambigüedad en las definiciones, propiedades y asunciones de las medidas, haciendo que el uso de las mismas sea difícil, la interpretación peligrosa y los resultados contradictorios.Para evitarlo es necesario contar con un método de definición de medidas


8

15




4. Conclusiones

16

Un modelo de calidad tiene en cuenta criterios para satisfacer las necesidades de los desarrolladores, mantenedores, adquisidores y usuarios finales (ISO, 2001). Pueden ser utilizados para construir mejores productos y asegurar su calidad. Se han desarrollado varios modelos de calidad para diferentes productos y procesos software. En general, descomponen la calidad jerárquicamente en una serie de características y subcaracterísticasque pueden usarse como una lista de comprobación de aspectos relacionados con la calidad y usan como base la ISO9126

MODELOS DE CALIDAD

9

17

CALIDAD

Usabilidad

Eficiencia

Fiabilidad

Mantenibilidad

Funcionalidad Transportabilidad

MODELOS DE CALIDADISO 9126

18

Funcionalidad: capacidad del producto software para proporcionar funciones que satisfagan las necesidades especificadas e implícitas.Fiabilidad: capacidad del producto software para mantener un nivel especificado de rendimiento.Usabilidad: la capacidad del producto software de ser entendido, aprendido, utilizado y atractivo al usuario.Eficiencia: la capacidad del producto software para proporcionar el rendimiento apropiado, relativo a la cantidad de recursos utilizados.Mantenibilidad: la capacidad del producto software para ser modificado. Las modificaciones pueden incluir correcciones, mejoras o adaptación del software a cambios en el entorno, en los requisitos o en las especificaciones funcionales.Portabilidad: la capacidad del producto software de ser transferido de un entorno a otro.


10

19

La funcionalidad se subdivide en cinco subcaracterísticas:Adecuación: la capacidad del producto software para proporcionar un conjunto apropiado de funciones para tareas específicas y objetivos de los usuarios.Exactitud: la capacidad del producto software para proporcionar los resultados o efectos correctos y con el grado de precisión acordado.Interoperabilidad: la capacidad del producto software para interactuar con uno o más sistemas especificados.Seguridad: referido a la capacidad del producto software para proteger la información y los datos.Conformidad: la capacidad del producto software para adaptarse a los estándares, convenciones o regulaciones en leyes y prescripciones relativos a la funcionalidad.


20

La fiabilidad se subdivide en cuatro subcaracterísticas:Madurez: la capacidad del producto software para evitar fallos provocados por errores en el software.Tolerancia a fallos: la capacidad del producto software para mantener un nivel de rendimiento determinado en caso de defectos en el software o incumplimiento de su interfaz.Recuperabilidad: la capacidad del producto software para restablecer un determinado nivel de rendimiento y recuperar los datos afectados directamente en caso de ocurrir un fallo.Conformidad: la capacidad del producto software para adaptarse a estándares, convenciones y regulaciones referidas a la fiabilidad.


11

21

La usabilidad se subdivide en cinco subcaracterísticas:Comprensibilidad: la capacidad del producto software para permitir al usuario que entienda si el software es adecuado, y como debe utilizarse para determinadas tareas y bajo ciertas condiciones de uso.Facilidad de aprendizaje: la capacidad del producto software para permitir al usuario aprender su aplicación.Operabilidad: la capacidad del producto software para permitir que el usuario lo opere y lo controle.Atracción: la capacidad del producto software para atraer al usuario.Conformidad: la capacidad del producto software para adaptarse a estándares, convenciones, guías de estilo y regulaciones relacionadas con la usabilidad.


22

La eficiencia se subdivide en tres subcaracterísticas:Comportamiento temporal: la capacidad del producto software para proporcionar tiempos de respuesta y de procesamiento apropiados cuando realiza sus funciones bajo condiciones determinadas.Utilización de recursos: la capacidad del producto software para utilizar cantidades y tipos de recursos apropiados cuando el software realiza su función bajo determinadas condiciones.Conformidad: la capacidad del producto software para adaptarse a estándares o convenciones relacionadas con la eficiencia.


12

23

La mantenibilidad se subdivide en cinco subcaracterísticas:Analizabilidad: Capacidad del producto software de diagnosticar sus deficiencias o causas de fallos, o de identificar las partes que deben ser modificadas.Cambiabilidad: Capacidad del producto software de permitir implementar una modificación especificada. La implementación incluye los cambios en el diseño, el código y la documentación. Estabilidad: Capacidad del producto software de evitar los efectos inesperados de las modificaciones.Facilidad de prueba: Capacidad del producto software de permitir validar las partes modificadas.Conformidad: Capacidad del producto software de cumplir los estándares o convenciones relativas a la mantenibilidad.


24

La portabilidad se subdivide en cinco subcaracterísticas:Adaptabilidad: la capacidad del producto software para ser adaptado para ambientes determinados sin realizar acciones o aplicar medios, más que los proporcionados para este propósito para el software considerado.Facilidad de instalación: la capacidad del producto software para ser instalado en un ambiente determinado.Coexistencia: la capacidad del producto software para coexistir con otro software independiente en un ambiente común compartiendo recursos.Reemplazabilidad: la capacidad del producto software para ser utilizado en lugar de otro producto de software para el mismo propósito en el mismo ambiente.Conformidad: la capacidad del producto software para adaptarse a estándares relacionados con la portabilidad.


13

25

Entre los modelos que usan la ISO9126:Bertoa y Vallecillo (2002). Adaptan la norma ISO9126 a los componentes COTS. Simão y Belchior (2003). Amplian las subcaracterísticas y atributos propuestos por la norma llegando a identificar 124 atributos de calidad para los componentes software.El modelo de calidad QUINT2 (Niessink, 2002) para valorar la calidad de arquitecturas software.Franch and Carvallo (2003). Adaptación de la ISO9126 para servidores de correo electrónico.Botella et al. (2003). Modelo para la selección de ERP.

MODELOS DE CALIDAD

26

Otras propuestas de modelos de calidad que no usanla ISO9126:

Cai et al. (2000). Modelo de calidad para componentes y sistemas basados en componentes. Fernández and Rossi (2000). Modelo de calidad parasoftware distribuido. Zo and Ramamurhty (2002). Modelo para valorar y seleccionar los sitios Web de comercio electrónico en un entorno B2C (Business-to-consumer).Webb and Webb (2002). Factores de calidad del sitio Web que son importantes para los consumidores.Parasuraman et al (1998). Modelo SERVQUAL con cinco dimensiones y 22 ítems para medir los diferentes elementos de la calidad de un servicio en general. La idea es adaptarlo a diferentes entornos adaptando las dimensiones descritas en el modelo original.

MODELOS DE CALIDAD

14

27




4. Conclusiones

28

La gran presencia de tecnología Web y la gran información asociada a esta tecnología hace imprescindible que los diseños se realicen bajo unos mínimos criterios de calidad, hasta ahora prácticamente inexistentes Las aplicaciones web desarrolladas sin criterios de calidad tendrán un pobre rendimiento y causarán fallos, por lo que es necesario que los sistemas web sean gestionados y dirigidos de forma rigurosa y cualitativa

EL MODELO WQM

15

29

En el ámbito de la web existen diferentes propuestas:MetodologíasMarcos de calidadModelos de estimaciónGuías de estilos y criteriosMétricas específicas

tanto del desarrollo, como de los productos, yde la calidad en uso de las aplicaciones web.

Sin embargo, no existen ni estándares ni puesta en común de todas estas iniciativas.

EL MODELO WQM

30

El objetivo de nuestro trabajo es paliar esta situación proponiendo un modelo tridimensional de calidad de los sitios web que puede utilizarse para clasificar tanto las medidas web, como los trabajos de investigación realizados sobre la web.El modelo no es excluyente de otros modelos de calidad existentes, sino que pretende ser aglutinador de los mismos, tratando de ser por tanto un modelo global de calidad de la web.

EL MODELO WQM

16

31

El modelo WQM está caracterizado por treselementos:

La característica de calidad (basada en Quint2 y en la ISO 9126)El proceso del ciclo de vida (basado en la ISO12207) Características (contenido, presentación y navegación)

EL MODELO WQM

32

EL MODELO WQM

Lifecycle Processes

Web Features

Quality Characteristics

Content

Navigation

Presentation

DevelopmentOperation

MaintenanceEffort

Reuse

17

33

Utilizamos tres de los factores más utilizados en la literatura para caracterizar un sitio web:

ContenidoPresentaciónNavegación

EL MODELO WQMCaracterísticas Web

34

Como base utilizamos el modelo Quint2 que se basaen la ISO 9126Quint2 amplia el estándar con nuevas características, apropiadas para productos web:

FuncionalidadFiabilidadUsabilidadEficienciaPortabilidadMantenibilidad

EL MODELO WQMCaracterísticas de calidad

18

35

Para esta dimensión utilizamos el estándar ISO 12207Trabajamos con los siguientes procesos:

El proceso de desarrolloEl proceso de explotaciónEl proceso de mantenimientoEl proceso de gestión de proyectosEl proceso de gestión de reutilización de programas

Las tres primeras pertenecen a la parte procesos primarios y las dos segundas a los procesos organizacionales (para incluir las medidas de estimación)

EL MODELO WQMProcesos del ciclo de vida

36

Otros datos:subjetiva/objetivadirecta/indirecta …

Validación formalValidación empíricaAutomatización…

EL MODELO WQMOtras características

19

37

Número de páginas (page count) (Emilia Mendes, Nile Mosley, Steve Counsell)

Descripción: Número de ficheros HTML o SHTML.

Validación Empírica: Sí

Clasificación WQM: Característica de Calidad: Usabilidad y Mantenibilidad

Ciclo de Vida: Diseño de la Arquitectura del Sistema, Implementación y Mantenimiento.

Características Web: Contenido y Presentación

EL MODELO WQMClasificación de medidas

38

Número de programas (program count) (Emilia Mendes, Nile Mosley, Steve Counsell)

Descripción: Número de scripts CGI, ficheros JavaScript, applets de Java de una aplicación web.

Validación Empírica: Sí

Clasificación WQM: Característica de Calidad: Funcionalidad, Fiabilidad, Usabilidad, Portabilidad y Mantenibilidad.

Ciclo de Vida: todas las etapas del ciclo de vida.

Características Web: Contenido, Presentación

EL MODELO WQMClasificación de medidas

20

39

Sobre el 44% de las medidass son de presentación. Este valor confirma la tendencia en la web de otorgara la presentación la máxima importancia haciendo quelos sitios sean lo más atractivos posible para el usuario.

UTILIZACIÓN DE WQM PARA LA CLASIFICACIÓN DE MEDIDAS

Website Features

Content35,8%

Presentation43,9%

Navigation20,3%

40

Los procesos de mantenimiento y explotación son los quecuentan con más medidas


Lifecycle ProcessesEffort7,7% Development

17,2%

Operation43,2%

Maintenance30,0%

Reuse1,9%

21

41

•Que los procesos de mantenimiento y explotación sean losque cuentan con más medidas, resulta lógico teniendo en cuenta la naturaleza evolucionaria de la web.

•Que no haya muchas para el proceso de desarrollo puede ser explicado porque las empresas de desarrollo tienden a losdesarrollos rápidos (Reifer, 2000).

•Finalmente, sólo hay un 10% de medidas para los procesosorganizacionales (8% para esfuerzo y 2% para reuso) lo cualcreemos que es debido a la falta de esfuerzo de investigaciónen este área.


42

Casi el 48% son medidas de usabilidad.



Effic iency8,2%

Portability7,5%

Maintainability18,4%

Reliability5,0%

Functionality10%

Usability47,8%

22

43

El alto número de medidas de usabilidad confirma la tendencia a satisfacer al usuario haciendo diseños usablesque atraigan a los usuarios.

Sólo el 4% de las medidas son de fiabilidad lo cual llama la atención ya que esta es fundamental para que el clienteacepte el sitio web.

Finalmente, pensamos que la aparición de nuevosdispositivos (como PDA, móviles, …) harán que se definanmedidas para portabilidad.C


44

Sobre 385 medidas la terna presentación, usabilidad, explotación


Lifecycle ProcessesEffort7,7% Development

17,2%

Operation43,2%

Maintenance30,0%

Reuse1,9%

Website Features

Content35,8%

Presentation43,9%

Navigation20,3%


Maintainability18,4%

Eff iciency8,2%

Functionality13,1%

Reliability5,0%

Usability47,8%

Portability7,5%

23

45




4. Conclusiones

46

Nuestro objetivo es definir un modelo que nos permita mejorar la calidad de un portalPara ello creamos PQM (Portal Quality Model) basado en el modelo SERVQUALDimensiones de PQM:

TangiblesFiabilidadCapacidad de respuestaAseguramientoEmpatíaCalidad de Datos

PQM

24

47

Tangibles: “El portal contiene todas las infraestructuras software y hardware que necesita de acuerdo a su funcionalidad”Fiabilidad: “Capacidad del portal para llevar a cabo su funcionalidad de forma precisa”. Esta dimensión además se verá afectada por:

Disponibilidad: El portal debe estar siempre operativo, para que los usuarios puedan acceder a él.

Calidad en las búsquedas: Los resultados que nos proporciona el portal al realizar una búsqueda deben ser adecuados a la petición realizada por el usuario.

PQM

48

Capacidad de respuesta: “Disposición del portal para ayudar y proveer su funcionalidad de forma inmediata a los usuarios”. Distinguimos:

Escalabilidad: Hace referencia a la capacidad del portal para adaptarse sin contratiempos al incremento de carga de trabajo.

Velocidad: Tiempo que debe esperar un usuario para obtener una respuesta a una petición.

Aseguramiento: “Capacidad del portal para transmitir veracidad y confianza”. Se distingue:

Confidencialidad: Capacidad para mantener la privacidad de los usuarios.

PQM

25

49

Empatía: “Capacidad del portal para proporcionar atención individualizada y ayuda”. En esta dimensión distinguimos:

Navegación: El portal debe proveer una navegación simple e intuitiva de utilizar.

Presentación: El portal debe tener una interfaz clara y uniforme.

Integración: Todos los componentes del portal deben ser integrados de forma coherente para no dificultar su uso.

Personalización: El portal debe ser capaz de adaptarse dependiendo del usuario.

PQM

50

Calidad de los datos (DQ): “Calidad de los datos contenidos en el portal”. Se pueden distinguir (Dedekey Kahn, 2002) :

DQ intrínseca: ¿Qué grado de cuidado se tomó en la creación y preparación de la información?Representación DQ: ¿Qué grado de cuidado se tomóen la presentación y organización de la información a los usuarios?Accesibilidad DQ: ¿Qué grado de libertad tienen los usuarios para usar datos, definir y/o refinar la forma en la que la información es introducida, procesada o presentada a ellos?DQ contextual: ¿En qué grado la información proporcionada satisface las necesidades de los usuarios?

PQM

26

51

El portal de Castilla-La Mancha (www.castillalamancha.es) es un portal corporativo, cuyo objetivo primordial es:

ser el motor generador de proyectos Internet en la región, vertebrados técnica y metodológicamente para asegurar el éxito de las diferentes iniciativas.

PQM

52

Para aplicar PQM y mejorar la calidad del portal creamos una encuestaEl objetivo de dicha encuesta es obtener el nivel de calidad del portal desde el punto de vista de los desarrolladores del mismo, paracada dimensión de calidad que hemosdefinido.La encuesta consta de cuarenta y dos cuestiones.Fiabilidad de nuestra encuesta: 0.9

PQM

27

53

Podemos clasificar cada pregunta en una dimensión (lo que es equivalente a indicar a que dimensión corresponde cada una de las cuestiones del cuestionario):

En la dimensión de Tangibles clasificamos las preguntas: P4, P38, P39.En la dimensión de Fiabilidad tenemos los ítems: P15, P16, P20, P31.En la dimensión de Capacidad de respuesta tenemos: P1, P2, P10, P11, P12, P13, P14, P17, P18, P26, P27.En la dimensión de Seguridad clasificamos las preguntas: P19, P21, P22, P23.En la dimensión Empatía tenemos: P3, P6, P24, P25, P28.En la dimensión Calidad de la Información clasificamos a: P7, P8, P9, P30.En la dimensión de Calidad del Servicio tenemos: P29, P32, P33, P34, P35, P36, P37, P40, P41, P42.

PQM

54

Resultados de la encuesta:

Resultados de la encuesta

1

2

3

4

5

1 4 7 10 13 16 19 22 25 28 31 34 37 40

Preguntas

Posi

bles

val

ores

Número de preguntas

Posibles valores para cada pregunta

Preguntas cuyo resultado está

por encima de 3 obtienen un

buen resultado

El resto no

PQM

28

55

Resultados para cada una de las dimensiones

4.11Calidad de los datos

3.44Empatía

2.71Aseguramiento

3.97Capacidad de respuesta

3.03Fiabilidad

3.5Tangible

VALOR MEDIO

DIMENSION Dimensión con valor más bajo (mejorarla haciendo las tareas

anteriores)

Mejor valor la información

devuelta por el portal es oportuna, lo que concuerda con el objetivo principal del

mismo.

Casi todas las dimensiones

están alrededor de la media

podemos hacer las mejoras indicadas y

después hacer el test de nuevo para verificar si la calidad del

portal ha mejorado.

PQM

56




4. Conclusiones

29

57

“Si las tecnologías de información son los motores de la Era de la Información, entonces los datos y la información son el combustible”. (Redman, 2001)

¿Datos o Información?

PDQM

58

PDQM

Las organizaciones modernas y sus datosLas organizaciones generan nuevo conocimiento a partir de la información que poseen y su experiencia. Enfrentan el fenómeno de contar con abundancia de información.Poseen muchos ordenadores con el fin de recoger, procesar y emplear los datos que llegan de varias fuentes de información.Los avances tecnológicos ayudan a que esto se incremente.

30

59

PDQMLas organizaciones modernas y sus datos

Expansión de las organizaciones por la Globalización.Necesidad de integrar diversos sistemas de información tanto dentro como más allá de los límites de la organización.

60

PDQM

Repercusiones de los datos sin calidad:Sociales

En entornos financieros (créditos)Laborales (confusión de identidades)Salud (diagnósticos)

EmpresarialesAtención al Cliente (Satisfacción del cliente)Apoyo a la Gestión (Toma de decisiones)Resultados (Aumento de ganancias/Disminución de pérdidas)

31

61

PDQM

Calidad de Datos/Calidad de Información

``Apropiada para el uso", entendiendo por esto, la capacidad de una colección de datos para reunir los requerimientos de los usuarios.

(Cappiello,2004; Wang, 1994).

62

Problemas típicos de una página Web Desarrollo de

Comercio Electrónico

Integrar datos estructurados y

no estructurados

Integrar datos de fuentes diversas

DQ desde la Perspectiva del

Usuario

Entender los datos y su

calidad

Demanda de servicios en tiempo real

Semántica de las AW

Calidad de Datos Dinámica

Fidelidad de los usuarios

PDQM

Aspectos relacionados con la Calidad de Datos web:

32

63

Los portales son unas importantes fuentes de informaciónNo hay propuestas espeíficas de calidad de datospara portalesLa perspectiva del consumidores de los datos no se considera en la mayoría de los trabajos y, sin embargo, son ellos los que necesitan evaluar la calidad de los datos que les ofrece un portalUn usuario satisfecho es la única garantía de quevuelva al portal

PDQM

64

Los tres aspectos claves del Modelo de Calidad de Datos de portales (PDQM-Portal Data Quality Model)

Data Consumerperspective

Web portal Functionalities

Web Data Quality

PDQM

PDQM

33

65

La perspectiva del consumidor de datosNo tienen control sobre la calidad de los datosofrecidos y disponibles.Su objetivo es encontrar datos que satisfagansus necesidades personales más que proveerdatos que satisfagan las necesidades de otros.

(Redman, 2001):

Privacy ContentQuality

ofValues

Presen-tation

Improve-ment

Commit-ment

Data Quality Expectations of Data Consumer on the Internet

PDQMData

Consumer

PDQM

66

Funcionalidades de un portal Web PortalData

Consumer

PDQM

Portal Funtionalities

(Collins, 2001)

PDQM

34

67

Marcos de Calidad de Datos en el contexto Web Data Consumer

PDQM

Portal Funtionalities

Web Data Quality

PDQM

68

1.- Identification of web data quality

attributes

2.- Definition of a Classification

Matrix

3.- Classification of data quality attributes into

the Matrix

PDQM

4.- Validation

PDQM

35

69

Identificación de atributos de calidad de datos Web

PDQM

70

Definición de la matriz de clasificación

PDQM

36

71

Clasificación de los atributos de DQ en la matriz.

They provide the ability to access in-formation from a wide range of inter-nal and external information sources and display the resulting information at the single point-of-access desktop.

Data consumers need a description of portal areas covered, use of published data, etc.),

Accessibility Currency

Amount of data Understandability

Relevancy Concise Representation

PDQM

72

Clasificación de los atributos de calidad de datos en la matriz

PDQM

37

73

Validación mediante encuestas a losconsumidores de datos de un portal Web

PDQM

74

La definición de un modelo no significa que éste sea operativo, es decir, que pueda ser utilizado para evaluar la DQ en portales Web.

Los 34 atributos de DQ de PDQM deben ser especificados de una manera operativa. Para esto debemos definir una estructura que nos permita organizar los atributos y asociarles medidas y criterios para su evaluación.

Nuestra propuesta:

Usar un enfoque probabilístico, usando redes Bayesianas, para estructurar, refinar y representar los atributos de DQ de PDQM.

PDQM

38

75

En nuestro contexto las redes bayesianas (BN) nos ofrecen un interesante framework con el cual es posible:

Representar las relaciones entre los atributos de DQ de una manera explícita e intuitiva. Facilitar la comprensión del modelo, su validación, evolución y explotación.

Evitar los problemas de incertidumbre de la subjetividad.

Usar la red obtenida para predecir/estimar la DQ de un portal.

Aislar factores responsables, en el caso de un bajo nivel de DQ.

Construcción de un BN para un modelo de calidad:

Construcción de la estructura gráfica

Definición de las tablas de probabilidades

PDQM

76

Generación de la estructura global de PDQM

PDQM

39

77

Desarrollo de una de las subredes de PDQM

PDQM

78




4. Conclusiones

40

79

Calidad de portlets

ISO/IEC 9126 NO ESTIMADAS ESTIMADAS

Mantenibilidad Portabilidad

Funcionalidad Fiabilidad Eficiencia

Franch y Carvallo, 2003

NO ESTIMADAS

Funcionalidad Fiabilidad Usabilidad Eficiencia Mantenibilidad Portabilidad

Bertoa y Vallecillo, 2002 NO ESTIMADAS ESTIMADAS

Funcionalidad Fiabilidad Eficiencia Mantenibilidad

Usabilidad

Simão y Belchior, 2003 NO ESTIMADAS


Botella et al., 2003 NO ESTIMADAS


Calero et al., 2004 NO ESTIMADAS ESTIMADAS

Funcionalidad Fiabilidad Usabilidad Eficiencia Portabilidad Mantenibilidad

Reusabilidad (subcaracteristica de mantenibilidad)

Cho et al., 2001 NO ESTIMADAS

Complejidad Customización Reusabilidad

Boxall y Araban, 2004 NO ESTIMADAS Reusabilidad

Offutt, 2002 NO ESTIMADAS

Fiabilidad Usabilidad Seguridad Disponibilidad Escalabilidad Mantenibilidad Tiempo para estar en el mercado

Washizaki et al., 2004 ESTIMADAS

Reusabilidad

PtQM

80

Calidad de portletsCaracterística Subcaracterística ¿Adoptada? Motivo

Adecuación No aplicable Exactitud Aplicable

Interoperabilidad Aplicable

Seguridad Adoptada del contexto

de aplicaciones web

Funcionalidad

Conformidad Aplicable Madurez Aplicable

Tolerancia a fallos Aplicable

Recuperabilidad Adoptada del contexto

de componentes Fiabilidad

Conformidad Aplicable Comprensibilidad Aplicable

Facilidad de aprendizaje Aplicable Operabilidad Reemplazada por otra

Atracción Reemplazada por otra Usabilidad

Conformidad Aplicable Comportamiento temporal Aplicable

Utilización de recursos Aplicable Eficiencia Conformidad Aplicable

Capacidad para ser analizado No aplicable

Cambiabilidad No aplicable Estabilidad No aplicable

Facilidad de prueba No aplicable

Mantenibilidad

Conformidad No aplicable

Adaptabilidad A tener en cuenta para

definir atributos

Facilidad de instalación A tener en cuenta para

definir atributos

Coexistencia A tener en cuenta para

definir atributos Capacidad para ser

reemplazado A tener en cuenta para

definir atributos

Portabilidad

Conformidad A tener en cuenta para

definir atributos

ISO 9126

41

81

Calidad de portlets

Franch y Carvallo (2003)Característica Subcaracterística ¿Adoptada? Motivo

Adecuación del servidor de correo No aplicable

Adecuación adicional No aplicable Exactitud Igual que ISO/IEC 9126

Interoperabilidad Igual que ISO/IEC 9126 Conformidad Igual que ISO/IEC 9126

Funcionalidad

Seguridad Igual que ISO/IEC 9126 Madurez Igual que ISO/IEC 9126

Tolerancia a fallos Igual que ISO/IEC 9126 Fiabilidad Recuperabilidad Igual que ISO/IEC 9126

Comprensibilidad Igual que ISO/IEC 9126 Facilidad de aprendizaje Igual que ISO/IEC 9126 Usabilidad

Operabilidad Igual que ISO/IEC 9126 Comportamiento temporal Igual que ISO/IEC 9126 Eficiencia Utilización de recursos Igual que ISO/IEC 9126

Capacidad para ser analizado Igual que ISO/IEC 9126 Cambiabilidad Igual que ISO/IEC 9126 Mantenibilidad

Facilidad de prueba Igual que ISO/IEC 9126 Adaptabilidad Igual que ISO/IEC 9126

Facilidad de instalación Igual que ISO/IEC 9126 Conformidad Igual que ISO/IEC 9126 Portabilidad

Capacidad para ser reemplazado Igual que ISO/IEC 9126

82

Calidad de portlets

Bertoa y Vallecillo (2002)

Característica Subcaracterística ¿Adoptada? Motivo Adecuación Igual que ISO/IEC 9126 Exactitud Igual que ISO/IEC 9126

Interoperabilidad Igual que ISO/IEC 9126 Seguridad Igual que ISO/IEC 9126

Conformidad Igual que ISO/IEC 9126

Funcionalidad

Compatibilidad No aplicable Madurez Igual que ISO/IEC 9126 Fiabilidad

Recuperabilidad Aplicable Comprensibilidad Igual que ISO/IEC 9126

Facilidad de aprendizaje Igual que ISO/IEC 9126 Operabilidad Igual que ISO/IEC 9126

Usabilidad

Complejidad No aplicable Comportamiento temporal Igual que ISO/IEC 9126 Eficiencia

Utilización de recursos Igual que ISO/IEC 9126 Cambiabilidad Igual que ISO/IEC 9126 Mantenibilidad

Facilidad de prueba Igual que ISO/IEC 9126

42

83

Calidad de portlets

Botella et al (2003)

Característica Subcaracterística ¿Adoptada? Motivo Adecuación del servidor de

correo No aplicable

Adecuación adicional No aplicable Exactitud Igual que ISO/IEC 9126

Interoperabilidad Igual que ISO/IEC 9126 Conformidad Igual que ISO/IEC 9126

Funcionalidad

Seguridad Igual que ISO/IEC 9126 Madurez Igual que ISO/IEC 9126

Tolerancia a fallos Igual que ISO/IEC 9126 Fiabilidad Recuperabilidad Igual que ISO/IEC 9126

Comprensibilidad Igual que ISO/IEC 9126 Facilidad de aprendizaje Igual que ISO/IEC 9126 Usabilidad

Operabilidad Igual que ISO/IEC 9126 Comportamiento temporal Igual que ISO/IEC 9126 Eficiencia Utilización de recursos Igual que ISO/IEC 9126

Capacidad para ser analizado Igual que ISO/IEC 9126 Cambiabilidad Igual que ISO/IEC 9126 Mantenibilidad

Facilidad de prueba Igual que ISO/IEC 9126 Adaptabilidad Igual que ISO/IEC 9126

Facilidad de instalación Igual que ISO/IEC 9126 Conformidad Igual que ISO/IEC 9126 Portabilidad

Capacidad para ser reemplazado Igual que ISO/IEC 9126

84

Calidad de portlets

Washizaki et al (2004)

Característica Subcaracterística ¿Considerada? Motivo Comprensibilidad Aplicable

Adaptabilidad No aplicable Reusabilidad Portabilidad Aplicable

43

85

Calidad de portlets

Simao and Belchior (2003)Característica Subcaracterística ¿Adoptada? Motivo

Adecuación Igual que ISO/IEC 9126 Exactitud Igual que ISO/IEC 9126

Autosuficiente Aplicable Cohesión funcional Aplicable Interoperabilidad Igual que ISO/IEC 9126

Seguridad Igual que ISO/IEC 9126

Funcionalidad

Conformidad Igual que ISO/IEC 9126 Madurez Igual que ISO/IEC 9126

Tolerancia a fallos Igual que ISO/IEC 9126 Recuperabilidad Igual que ISO/IEC 9126 Evaluabilidad Aplicable

Fiabilidad

Conformidad Igual que ISO/IEC 9126 Accesibilidad No aplicable Legibilidad No aplicable

Comprensibilidad Igual que ISO/IEC 9126 Amigabilidad al usuario No aplicable Facilidad de aprendizaje Igual que ISO/IEC 9126

Operabilidad Igual que ISO/IEC 9126 Atracción Igual que ISO/IEC 9126

Usabilidad

Conformidad Igual que ISO/IEC 9126 Comportamiento temporal Igual que ISO/IEC 9126

Utilización de recursos Igual que ISO/IEC 9126 Información del estado No aplicable

Escalabilidad No aplicable Nivel de granularidad apropiado No aplicable

Eficiencia

Conformidad Igual que ISO/IEC 9126 Capacidad para ser analizado Igual que ISO/IEC 9126

Viabilidad de la implementación No aplicable Cambiabilidad Igual que ISO/IEC 9126

Estabilidad Igual que ISO/IEC 9126 Facilidad de prueba Igual que ISO/IEC 9126

Mantenibilidad

Conformidad Igual que ISO/IEC 9126 Adaptabilidad Igual que ISO/IEC 9126

Facilidad de instalación Igual que ISO/IEC 9126 Coexistencia Igual que ISO/IEC 9126

Capacidad para ser reemplazado Igual que ISO/IEC 9126 Portabilidad

Conformidad Igual que ISO/IEC 9126

86

Calidad de portlets

Calero et al (2004)Característica Subcaracterística ¿Adoptada? Motivo

Adecuación Igual que ISO/IEC 9126 Exactitud Igual que ISO/IEC 9126

Interoperabilidad Igual que ISO/IEC 9126 Seguridad Aplicable

Funcionalidad

Trazabilidad No aplicable Madurez Igual que ISO/IEC 9126

Tolerancia a fallos Igual que ISO/IEC 9126 Recuperabilidad Igual que ISO/IEC 9126

Disponibilidad Considerada a partir de otro

trabajo

Fiabilidad

Degradabilidad Aplicable Comprensibilidad Igual que ISO/IEC 9126

Facilidad de aprendizaje Igual que ISO/IEC 9126 Operabilidad Igual que ISO/IEC 9126

Explícito No aplicable

Atractividad Tenida en cuenta para determinar

atributos Customizabilidad Aplicable

Claridad Tenida en cuenta para determinar

atributos

Ayudabilidad Tenida en cuenta para determinar

atributos

Usabilidad

Amigabilidad al usuario Tenida en cuenta para determinar

atributos Comportamiento temporal Igual que ISO/IEC 9126 Eficiencia Utilización de recursos Igual que ISO/IEC 9126

Adaptabilidad Igual que ISO/IEC 9126 Facilidad de instalación Igual que ISO/IEC 9126

Capacidad para ser reemplazado Igual que ISO/IEC 9126 Portabilidad

Coexistencia Igual que ISO/IEC 9126 Capacidad para ser analizado Igual que ISO/IEC 9126

Cambiabilidad Igual que ISO/IEC 9126 Estabilidad Igual que ISO/IEC 9126

Facilidad de prueba Igual que ISO/IEC 9126 Manejabilidad No aplicable

Mantenibilidad

Reusabilidad Considerada como característica

de calidad

44

87

Calidad de portlets

Característica Definición

Funcionalidad Capacidad del portlet para proporcionar funciones que

satisfagan las necesidades explícitas e implícitas cuando el portlet es utilizado en las condiciones especificadas.

Fiabilidad Capacidad del portlet para mantener un nivel especificado de

rendimiento cuando se utiliza en las condiciones especificadas.

Usabilidad Capacidad del portlet para ser utilizado por los desarrolladores del portal cuando construyen el portal con él.

Eficiencia Capacidad del portlet para proporcionar un rendimiento

adecuado, relativo a la cantidad de recursos utilizados, bajo condiciones indicadas.

Reusabilidad Capacidad del portlet para ser reusado en diferentes portales por diferentes desarrolladores.

88

Calidad de portlets

PtQM

Funcionalidad

Fiabilidad

Usabilidad

Eficiencia Reusabilidad

45

89

Calidad de portlets

90




4. Conclusiones

46

91

Es fundamental incorporar la calidad a losSistemas de Información Web: sitios, portales, datos, …Nosotros promovemos la definición de modelosde calidad y de medidas que nos ayuden en estatarea

CONCLUSIONES

92

Medidas para la calidad web

1. Introducción2. Método de definición de medidas3. Ontología de la medición4. Modelos de calidad

4.1. WQM4.2. PQM4.3. PDQM

5. Medición de aplicaciones de comercio electrónico6. Accesibilidad web7. Conclusiones8. Referencias

47

93

Basili, V.R. y Weiss, D. (1984). A methodology for Collecting Valid Software Engineering Data. IEEE Transactions on Software Engineering. SE-10. No. 6. pp.728-738.Basili, V.R., Shull, F. y Lanubille, F. (1999). Building Knowledge through families of experiments. IEEE Transactions on Software Engineering. July/August. No. 4. pp. 456-473Bertoa, M.F. and Vallecillo, A. “Quality Attributes for COTS Components”. In Proc. of the 6th ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering (QAOOSE 2002). Málaga, Spain, June 2002. Botella P., Burgués X., Carvallo J.P., Franch X., Pastor J.A. and Quer C. (2003) Towards a Quality Model for the Selection of ERP Systems in Component-Based Software Quality. Cechich et al (eds). LNCS 2693. pp. 225-245

REFERENCIAS

94

Briand, L.C., Morasca, S. y Basili, V. (1996). Property-based software engineering measurement. IEEE Transactions on Software Engineering. 22(1). pp.68-85.Cai, X., Lyu, M.R., Wong, K-F. and Ko, R. (2000). Component-Based Software Engineering: Technologies, Development Frameworks, and Quality Assurance Schemes. Proc. of the Seventh Asia-Pacific Software Engineering Conference (APSEC’00), IEEE Computer Society, 372-379.Dromey, R.G. (1996). Cornering the Chimera. IEEE Software 20 (1), 33-43.Fenton, N. y Pfleeger, S. L. (1997). Software Metrics: A Rigorous Approach 2nd. edition. London. Chapman & Hall. Franch, X. and Carvallo, J.P. (2003). Using Quality Models in Software Package Selection. IEEE Software 20 (1), 34 - 41.García, F., M.F. Bertoa, C. Calero, A. Vallecillo, F. Ruíz, and M. Genero, Towards a consistent terminology for software measurement. Information and Software Technology, 2005 To be published.

REFERENCIAS

48

95

Gruber, T. (1995). Towards Principles for the Design of Ontologies used for Knowledge Sharing. International Journal of Human-Computer Studies, 43(5/6), pp. 907-928.Henderson-Sellers, B. (1996). Object-oriented Metrics - Measures of complexity. Prentice-Hall. Upper Saddle River. New JerseyIFPUG (2002) IT technologies. Addison-WesleyISO 9126 (2001). Software Product Evaluation-Quality Characteristics and Guidelines for their Use. ISO/IEC Standard 9126. Geneva.Kish, L. (1959). Some statisticals problems in research design. American Sociological Review. 24. pp.328-338.Kitchenham, B. and Pfleeger, S.L. (1996). Software Quality: The Elusive Target. IEEE Software 20 (1), 12-21.Kitchenham, B.A. y Stell, J.G. (1997) “The danger of using axioms in software metrics”. IEE Proc.-Soft. Eng.. Vol. 144. No. 5-6. pp 279-285.

REFERENCIAS

96

Li, H.F. y Cheng, W.K. (1987). An empirical study of software metrics. IEEE Trans. on Software Engineering. 13 (6) pp. 679-708.Morasca, S. y Briand, L.C. (1997). Towards a Theoretical Framework for measuring software attributes. Proceeding of the Fourth International Software Metrics Symposium. pp. 119-126.Niessink, F. (2002) Software Requirements: Functional & Non-functional Software Requirements. www.cs.uu.nl/docs/vakken/swa/ Slides/SA-2-Requirements.pdfPfleeger S.L. (1995). Experimental design and analysis in software engineering. Annals of Software Engineering. JC BaltzerAG. Science Publishers. pp. 219-253.Pfleeger, S. L. (1997). “Assessing Software Measurement”. IEEE Software. March/April. pp. 25-26.

REFERENCIAS

49

97

Simão, R.P. y Belchior A. (2003). Software Component Quality. In: Quality in Component Based Systems. Cechich, A. et al. (eds.). Springer-Verlag.Van Den Berg y Van Den Broek (1996). Axiomatic Validation in the Software Metric Development Process (Chapter 10). Software Measurement. A. Melton (ed.). (Thomson Computer Press.Weyuker, E.J. (1988). Evaluating software complexity measures. IEEE Transactions on Software Engineering. 14(9). pp.1357-1365.Whitmire, S.A. (1997). Object Oriented Design Measurement. Ed. Wiley.Zuse, H. (1998). A Framework of Software Measurement. Berlin. Walter de Gruyter.

REFERENCIAS

WQM Calero

Documents

Transcript of WQM Calero