modelos de calidad

1

Modelos de calidad softwareCalidad de Sistemas de Información

Dra. Coral CaleroGrupo ALARCOS

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

[email protected]

2

Modelos de calidad software

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

3.1. WQM3.2. PQM3.3. PDQM

4. Medición de aplicaciones de comercio electrónico5. Conclusiones

2

3

¿Cómo saber cual es mayor?

8,05 cm

INTRODUCCIÓN

4

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

3

5

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

6

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

4

7

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.


8

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).


5

9

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.


10

Atributos a medir: Recursos:

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


6

11

Ú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.


12

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


7

13

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


14





8

15

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

16

CALIDAD

Usabilidad

Eficiencia

Fiabilidad

Mantenibilidad

Funcionalidad Transportabilidad

MODELOS DE CALIDADISO 9126

9

17

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.


18

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.


10

19

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.


20

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.


11

21

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.


22

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.


12

23

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.


24

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

13

25

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

26





14

27

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

28

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

15

29

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

30

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

16

31

EL MODELO WQM

Lifecycle Processes

Web Features

Quality Characteristics

Content

Navigation

Presentation

DevelopmentOperation

MaintenanceEffort

Reuse

32

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

ContenidoPresentaciónNavegación

EL MODELO WQMCaracterísticas Web

17

33

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

34

Para esta dimensión utilizamos el estándar ISO 12207

Trabajamos con los siguientes procesos:El proceso de desarrollo

El proceso de explotación

El proceso de mantenimiento

El proceso de gestión de proyectos

El 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

18

35

Otros datos:subjetiva/objetiva

directa/indirecta …

Validación formal

Validación empírica

Automatización

…

EL MODELO WQMOtras características

36

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

19

37

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

38

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%

20

39

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%

40

•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.


21

41

Casi el 48% son medidas de usabilidad.



Effic iency8,2%

Portability7,5%

Maintainability18,4%

Reliability5,0%

Functionality10%

Usability47,8%

42

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


22

43

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%

44





23

45

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

46

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

24

47

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

48

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

25

49

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

50

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

26

51

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

52

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

27

53

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

54

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

28

55





56

“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

29

57

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.

58

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.

30

59

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)

60

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).

31

61

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:

62

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

32

63

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

64

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

33

65

Funcionalidades de un portal Web PortalData

Consumer

PDQM

Portal Funtionalities

(Collins, 2001)

PDQM

66

Marcos de Calidad de Datos en el contexto Web Data Consumer

PDQM

Portal Funtionalities

Web Data Quality

PDQM

34

67

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

68

Identificación de atributos de calidad de datos Web

PDQM

35

69

Definición de la matriz de clasificación

PDQM

70

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

PDQM

36

71

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

PDQM

72





37

73

MEDICIÓN DE APLICACIONES DE E-COMERCIO

Las compañías quieren evaluar la efectividad de las aplicaciones de comercio electrónico. La misma depende, estrictamente, de la satisfacción del usuario final.Todos los aspectos de la usabilidad de una aplicación son muy importantes para el desarrollo de negocios en Internet. De hecho, si un usuario tiene la oportunidad de escoger entre varias tiendas electrónicas, ciertamente elegirá aquella que esté soportada por la aplicación más usable.

74

Vamos a ver un modelo para la medición de la usabilidad de aplicaciones de comercio electrónico propuesto por Frallicciardi (2002) en IFPUG (2002).Los requisitos para definir una aplicación como usable son:

Debe ser amigableDebe ser fácil de entender y de aprenderDebe ayudar a los usuarios finales a alcanzar sus objetivosDebe mejorar la productividad de los usuarios finales


38

75

Teniendo en cuenta lo anterior, el modelo de medición de usabilidad tiene las cuatro siguientes sub-características:

Facilidad de usoEntendibilidadEfectividadEficiencia


76

Facilidad de usoEsta sub-característica es medida de acuerdo al número de funciones ofrecidas a los usuarios finales, entre ellas:Ayudanavegacional, Ayuda y documentos en línea, Teclas de función preasignadas, Utilizaciones de zonas destacadas, subrayados, coloreados, y otros indicadores que ayuden al usuario a localizar elementos, El menor número de pantallas posible para implementar la funcionalidad, Soporte bilingüe, Soporte multilingüe, …


39

77

Cuanto más se utilicen estas indicaciones más usable será la aplicación. En la tabla siguiente hay una relación de rangos respecto al número de indicaciones usadas. El valor aceptable para esta sub-característica es 4 o más.


78

6 o más junto con requisitos de usuario para eficiencia suficientemente fuertes para requerir el uso de herramientas especiales y procesos para demostrar que los objetivos son alcanzados

5

6 o más junto con requisitos de usuario para eficiencia suficientemente fuertes para requerir tareas de diseño

4

6 o más pero no hay requisitos de usuario relacionados con la eficiencia

3

De 4 a 52

De 1 a 31

Ninguna 0

Número de indicaciones incluidasRango


40

79

EntendibilidadLa entendibilidad de una aplicación refleja la capacidad de la aplicación para interactuar de manera sencilla con los usuarios finales.Las medidas para la entendibilidad de una aplicación son:

Cantidad de veces que el usuario final accede, durante unas sesión, a las funciones de ayuda en líneaNúmero de páginas web accedidas y rápidamente abandonadasNúmero de mensajes de error visualizados durante una sesiónTiempo que necesita el usuario para pasar de una página web a otra


80

Los tres primeros indicadores pueden ser calculados midiendo su número durante un conjunto de sesiones de trabajos observadas:

Número de veces durante una sesión que el usuario accede a las funciones de ayuda en líneaNúmero de páginas web accedidas y rápidamente abandonadasNúmero de mensajes de error visualizados durante una sesión

La medición del cuarto indicador, se hace otorgando valores de 0 a 3 de acuerdo a un rango de posibles valores


41

81

tiempo > 5 minutos3

3 minutos < tiempo <= 5 minutos2

1 minuto < tiempo <= 3 minutos1

tiempo <= 1 minuto0

TiempoRango


82

La medición final de la entendibilidad se hace calculando la media aritmética entre los valores obtenidos de la medición de los tres primeros indicadores y el rango asignado al cuarto.


42

83

EfectividadLa efectividad de una aplicación consiste en su capacidad de ayudar a los usuarios finales a alcanzar sus objetivos. En otras palabras, los usuarios finales pueden navegar correctamente a través de páginas web, sabiendo dónde están, dónde deben ir y no tienen que abandonar transacciones comenzadas o abortar sus sesiones de trabajo hasta alcanzar sus objetivos.


84

La efectividad de una aplicación se puede medir de acuerdo a:

Número de transacciones diarias abandonadas (no completadas) por usuarios finalesEl número de sesiones de trabajo diarias abandonadas sin ninguna transacción completada

La medición final de la efectividad se hace calculando la media aritmética entre los valores obtenidos de la medición de los indicadores aunque los valores aceptables para esta sub-característica debe estar entre 1 o 0.


43

85

EficienciaLa eficiencia de una aplicación es su capacidad de ayudar a los usuarios finales a alcanzar sus objetivos en menos tiempo que el requerido para alcanzar los mismos objetivos utilizando otros instrumentos


86

Algunos indicadores para medir la eficiencia son:

El tiempo necesario para completar exitosamente una transacción Número de transacciones completadas con éxito en un periodo de tiempo dado

tiempo > 10 minutos3



tiempo <= 3 minutos0

TiempoRango

TC <= 63

6 < TC <= 122

12< TC <= 201

TC> 200

Nro de transacciones completadas (TC)Rango


44

87

La medición final de la eficiencia se hace calculando la media aritmética entre los rangos asignados a cada indicador.


88

Evaluación de la usabilidadLa medición de las cuatro sub-dimensiones explicadas, proveen la medición de la usabilidad completa de una aplicación.El valor medido aceptable se define como un conjunto de cuatro valores medidos aceptables y que se identifican con cada una de las cuatro sub-características vistas.


45

89

Usabilidad no aceptableOtros

Usabilidad aceptable(5/4,1,1,1)

Usabilidad media(5/4,1,0,1) o (5/4,1,1,0) o (5/4,0,1,1)

Usabilidad alta(5/4,1,0,0) o (5/4,0,1,0) o (5/4,0,0,1)

Usabilidad excelente(5/4,0,0,0)

Evaluación de la usabilidadConjunto de valores


90





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


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

modelos de calidad

Documents