Comprobación Automática de Requisitos de Calidad en Sistemas Multiorganizacionales

ComprobaciónAutomáticadeRequisitosde CalidadenSistemasMultiorganizacionales* Antonio Ruiz, Amador Durán, Rafael Corchuelo, Beatriz Bernárdez y Miguel Toro UniversidaddeSevilla,Dpto.deLenguajesySistemasInformáticos aruiz,amador,corchu,beat,[email protected] Resumen El uso de servicios WEB y de servidores de aplicaciones durante el desarrollo y explotación de sistemas multiorganizacionales basados en la WEB (MOWS), ha puesto de relieve algunas limitaciones de los actuales lenguajes de especificación de requisitos de calidad para soportar el tratamiento automático que, sobre este tipo de requisitos, precisan el desarrollo y la explotación de MOWS. En este artículo se presenta un lenguaje formal de especificación de requisitos que facilita la comprobación automática de la conformidad ylaeconomía, dos propiedades de gran interés para los MOWS. Keywords: ingeniería de requisitos, requisitos de calidad, aplicaciones WEB 1.Introducción El aumento de la demanda y complejidad de aplicaciones WEB, la presión por reducir los costes de desarrollo y explotación, y las nuevas posibilidades que ofrecen los llamados servicios WEB [1, 2], son, a grandes rasgos, las principales razones que han motivado la propuesta de un nuevo paradigma de programación conocido como WOP (Web–Oriented Programming) [3]. Este paradigma intenta dar respuesta a los principales problemas del desarrollo de sistemas multiorganizacionales basados en la WEB,o más abreviadamente MOWS (Multi–Organisational Web–based Systems), que han sido definidos como sistemas cuya funcionalidad es obtenida mayoritariamente subcontratando aplicaciones y servicios WEB proporcionados por múltiples organizaciones [3]. Como cabría esperar, la WOP debe dar una respuesta efectiva a problemas críticos en el desarrollo de un MOWS como son el de la optimalidad yeldelaconformidad [3, 4]. La optimalidad se define como la capacidad de seleccionar entre un conjunto de candidatosel servicio WEB o aplicación que satisface de manera óptima un conjunto de requisitos de calidad, que incluyen desde la cuota que es preciso pagar por utilizarlos hasta su tiempo de respuesta. Por su parte, la conformidad se define como la capacidad de garantizar que dichos requisitos de calidad se cumplen. Conviene matizar que en este contexto la palabra garantizar no debe entenderse como sinónimo de asegurar la *Este trabajo está parcialmente financiado por el proyecto CICYT “GEOZOCO”, TIC 20001106-C02-01, y por el proyecto CYTED “WEST” satisfacción ininterrumpidade los requisitos, sino de como ofrecer a las organizaciones que intervienen en un MOWS un documentode garantía que permita identificar en caso de problemas cuál es el elemento del sistema que no ha cumplido con sus especificaciones de calidad y depurar responsabilidades. Hasta la fecha, las limitaciones de los lenguajes de especificación de requisitos de calidad han hecho imposible obtener soluciones automáticas realmente eficaces que resuelvan este problema. En este artículo presentamos las principales características de un nuevo lenguaje de especificación de requisitos diseñado para ofrecer una respuesta adecuada y eficaz a los problemas relacionados con la comprobación de la conformidad. En adelante haremos referencia a este lenguaje como QRL (Quality Requirements Language). Las principales aportaciones de QRL respecto a otras propuestas son: i) el uso de un modelo ontológico para definir atributos de calidad que hace posible la comprobación automática de propiedades y facilita la comprobación entre documentos de requisitos que utilizan diferentes catálogos de atributos ii) la interpretación de la comprobación de la conformidad como un problema de satisfacción de restricciones [5] lo que aumenta considerablemente su capacidad expresiva iii) la posibilidad de especificar períodos de validez tanto para el documento de requisitos en su conjunto como de cada requisito individualmente y iv) la capacidad de especificar reglas de negociación bilaterales de modo que los clientes puedan expresar todas las condiciones que están dispuestos a aceptar y los proveedores todas las ofertas que desean ofrecer. El resto del artículo está organizadode la siguiente forma: en la Sección 2 se describe el problema de la conformidad en los MOWS. En la Sección 3 se presenta de manera intuitiva el modelo ontológicode los catálogos de atributos y en la Sección 4 de presenta las posibilidades que ofrece QRL para describir requisitos de calidad. En la Sección 5 se presentan las reglas de negociación y en la Sección 6 las reglas que permiten establecer los criterios de optimalidad. Seguidamente en la Sección 7, se describen algunos de los trabajos relacionados con la presente contribución. Por último, en la Sección 8, se describen las conclusiones y los trabajos futuros. 2. La Conformidad en los MOWS Para ilustrar de manera intuitiva el problema de la conformidad en los MOWS, imaginemos que se desea construir un portal que ofrece la misma funcionalidad que un reproductor de vídeo doméstico con una videoteca potencialmente infinita y con la garantía de que el nivel de calidad se satisfará mientras dure su explotación. Durante el diseño se ha optado por utilizar tres tipos de servicios WEB: uno para la autentificación de usuarios (p.e. Microsoft Passport, http://www.passport.com), otro de almacén de películas y otro de almacén de tráilers. De este modo, el propietario del portal sólo se encargaría de la publicidad y de la coordinación entre las diferentes servicios y aplicaciones subcontratados. Con objeto de obtener la máxima rentabilidad económica, los MOWS son diseñados como sistemas abiertos y con capacidad de razonamiento automático, de modo que, en general, los proveedores de servicios y aplicaciones que pueden formar parte del Conditions • Medium time between fails greater than 90 minutes • Medium time to repair smaller than 60 seconds • Maximum cost 0.1 Euro per connection • Streaming is required • Negotiation: •if cost is smaller than 0.03 then streaming is not needed •Criteria •Minimise the cost per connection ITrailersBank playTrailer.html Offer: • Medium time between fails: 120 minutes • Medium time to repair: 50 seconds • 0.02 Euro per connection on workdays •0.05 Euro per connection at weekends • Streaming is not supported • And so on .... $UTXLWHFWXUH ,QWHUQHW http://zipi.lsi.us.es/Trailers http://velazquez.fie.us.es/Trailers Offer: •Medium time between fails: 360 min •Medium time to repair: 50 seconds •Streaming is supported •Media: BroadBand •Cost: 0.4 euros (Broadband) •Negotiation •If Media is T1 or ISDN then Cost is 0.3 euros •If Media is Modem-56K then Cost is 0.2 euros •And so on .... Figura1. Fragmento de la arquitectura de un portal que permite la reproducción de películas y tráilers. sistema no son conocidos de antemano, sino que en cada conexión se elige el proveedor que resulte más beneficioso. La Figura 1 muestra un fragmento de la vista de implementación (de acuerdo con UML [6]) de la arquitectura software del portal de video. Como puede observarse, para reproducir un tráiler (página playTrailer.htm) se necesita un servicio WEB que implementela interfaz ITrailersBank.Por su parte, la línea discontinuadel contorno del servicio WEB (componente estereotipado con una bola del mundo) significa que el servicio de almacenamiento de tráilers puede ser proporcionado por cualquier proveedor de dicho servicio que ofrezca un nivel de calidad que satisfaga las condiciones establecidas por el sistema. De ahoraen adelantellamaremoscondicionesal documento que especifica los requisitos de calidad exigidos por el sistema y oferta al documento que especifica los requisitos que el proveedor se compromete a garantizar. Una de las actividades necesarias para poder garantizar la conformidad, es la comprobación de que las condiciones que debe satisfacer el proveedor del servicio pueden cumplirse con la oferta de calidad que éste proporciona. En la figura 1 se muestran dos proveedoresdeserviciosdealmacenamientodetráilers.Esfácilcomprobarquelaoferta del primer proveedor(http://zipi.lsi.us.es/Trailers) no satisface las condiciones exigidas por el sistema pues no soporta streaming. De igual modo, es fácil comprobar que la oferta del segundo proveedor si satisface las condiciones del sistema. Se podría pensar que comprobar la conformidad es un problema muy simple y que puede ser llevada a cabo manualmente por el administrador del portal, pero como veremos a continuación, existen varias razones que aconsejan que dicha actividad se automatice a fin de poder ser realizadapor algún componentede la plataforma de ejecución: Cuando el número de requisitos es elevado, esta comprobación consume mucho tiempo lo que puede resultar inaceptable cuando el cliente que espera la conexión es un persona y no una aplicación. Además, existe una mayor probabilidad de que comprobacionesincorrectasdenporválidas ofertasquenosatisfacen los requisitos. El nivel de calidad de las condiciones y las ofertas pueden cambiar con mucha frecuencia, por lo que en el caso más desfavorable puede ser necesario comprobar la conformidad en cada conexión, aumentando considerablemente el número de comprobaciones necesarias. Si se incluyenreglas denegociaciónen las condicionesy/o enlas ofertas,el proceso de comprobación se complica, y aumenta el tiempo necesario para realizarla. 3. Catálogos de Atributos de Calidad Un atributo de calidad puede definirse como una propiedad cuyo grado de satisfacción por parte de un sistema software puede ser valorado por sus usuarios (atributos externos) y/o por sus diseñadores (atributos internos) [7, pág.3], en otras palabras, un atributo de calidad puede ser cualquier característica que pueda verificarse, es decir, medirse de manera objetiva o subjetiva. De este modo, dependiendo del dominio del sistema al que nos refiramos, la etapa del desarrollo en la que nos encontremos,o la experiencia de los desarrolladores, entre otros factores, para un mismo sistema podrándefinirse diferentes conjuntos de atributos de calidad que lo caractericen (en [8, pág.160] se ofrece una lista con 161 atributos de calidad diferentes). La definición de conjuntos de atributos en QRL se realiza mediante catálogos. El modelo ontológico de un catálogo de atributos consta únicamente de dos conceptos: atributo de calidad yrequisito abstracto. Las propiedades de un atributo de calidad son cinco: un nombre o identificador, una descripción en lenguaje natural, una descripción formal, una definición de su dominio y su unidad de medida. Las restricciones que se establecen sobre estas propiedades son las siguientes: El nombre debe ser de tipo cadena y su valor seráúnico dentro del catálogo. Su indicación es obligatoria. La descripción debe ser de tipo cadena. Su indicación es opcional. La descripción formal debe constar de al menos un patrón lingüístico [9] que describa su significado y de una restricción matemática equivalente. Su indicaciónes obligatoria. El dominio podráser de tipo entero, real, enumerado o de tipo conjunto. Su indicación es obligatoria. La unidad seráde tipo cadena. Su indicación es obligatoria siempre que el atributo no sea adimensional. Por su parte, las propiedades de un requisito abstracto son tres: su identificador, una restricción de calidad y un período de vigencia. Estas propiedades se estudiaránen detalle en la Sección4. La Figura2 muestra la definiciónparcialdedoscatálogosdeatributosdecalidad,un catálogohorizontalparalos MOWS y otro verticalpara el dominiode las aplicaciones de multimedia. El catálogo se identifica por un URI (Universal Resource Identificator)de forma similar a la utilizada en XML para los espacios de nombres [10]. A continuación describimosconmayor detallecomose definen los dominiosy los patroneslingüísticos. catalogue com.acme.stdMOWS { attributes { TTF { description :“Tiempo entre fallos”; domain : integer min; pattern :“El tiempo medio entre fallos seráde al menos <tiempo>” = “TTF.mean  <tiempo>”; pattern :“El tiempo entre fallos seguiráuna distribución de valor medio <valor>y una desviacióntípica máxima de <valor>” = “TTF.mean  <valor> and TTF.variance  <valor>”;} TTR { description :“Tiempo de recuperación ante un error”; domain : integer sec; pattern :“El tiempo {medio, máximo} de recuperación ante un fallo será inferior a <valor>” = “TTF.{mean,max}  <valor>”;} BCODE { description :“Portabilidad a nivel de código binario”; domain : set {Win3.X, Win95, Win98, WinNT4, Win2000, Linux, Solaris}; pattern :“Todos los componentes de la aplicación podrán ser ejecutados sin necesidad de recompilar el código fuente en las siguientes plataformas: <valor>” = “BCODE >= <valor>”;} SCODE { domain : set {Win95, Win2000, Linux, Solaris}; ::: } AVAIL { domain : real [0..100]%; ::: } FMASK { domain : set {early, late, state, value, omission}; ::: } SFAIL { domain : enum {halt, initialState, rollBack}; ::: } OPSEM { domain : enum {atLeastOnce, atMostOnce, once}; ::: } REBIND { domain : b o olean ; ::: } DELAY { domain : integer [0, 60*60] sec; ::: } THR { domain : integer [0, 1000] unit/sec; ::: } } stereotyp es { safety.low: TTF.mean > 60 and TTR  120; safety.med: TTF.mean > 90 and TTR  90; robustness.high: REBIND = true and OPSEM = once and SFAIL  initialState; } catalogue com.acme.multimedia { attributes { STREAMING { domain : b o olean ; ::: } COST { domain : real euro; ::: } MEDIA { domain : set {BroadBand, T1, ISDN, Modem}; ::: } LANG { domain : set {english, french, german, spanish}; ::: } SUBT { domain : set {english, french, german, spanish}; ::: } } } Figura2. Especificación de catálogos de atributos en QRL 3.1. Dominios de Atributos de Calidad En QRL los atributos pueden tomar valores en cinco dominios diferentes: Enteros: Sus elementos son números enteros. Por ejemplo, la latencia (DELAY), definida como el tiempo que se tarda en responder a una determinada operacióny el tiempo entre fallos (TTF). Reales:Suselementosson númerosreales.Porejemplo,ladisponibilidad(AVAIL), definida comola probabilidad (expresada en%) de que el sistema se encuentre fuera de servicio. Lógicos: Sus elementos sólo pueden tomar dos valores true o false . Por ejemplo, el soporte de streaming por parte de un servidor. Enumerados. Sus elementos son literales alfanuméricos.Por ejemplo, para describir las posibles maneras que tiene un sistema de comportarse tras un fallo (SFAIL, Server Failure), no se requiere un dominio tan amplio como los numéricos, basta con algunos valores que puedan ser referenciados por literales, por ejemplo: halt, si se queda inactivo indefinidamente, initialState si vuelve a un estado inicial conocido y rollBack si vuelve a un punto de sincronización y deshace todos los cambios realizados antes del fallo. Conjuntos. En ocasiones, necesitamos varios literales para establecer el valor de un atributo. Por ejemplo, el atributo FMASK especifica los tipos de fallos de los que se debe preocupar el cliente de un servicio WEB, los cuales, siguiendo la clasificación expuestaen [11],puedenser: i) fallos de omisión(omission),indicanque el servidor puede no responder a las peticiones realizadas, ii) fallos en las respuestas, indica que el servidor puede devolver valores incorrectos (value) o realizar transiciones de estado incorrectas (state) y iii) los errores de tiempo, que indican que el servicio puede responderdemasiadopronto(early) o demasiado tarde (late). Es evidente que un servicio puede presentar más de un tipo de fallo de manera simultánea (p.e. fallos de omisión y devolver valores incorrectos), siendo necesario para describir tales situaciones, utilizar conjuntos de valores enumerados ({ omission, value}). 3.2. Descripción Formal de Atributos La base formal de QRL son las restricciones matemáticas y su principio básico es considerar que todo requisito de calidad puede ser expresado mediante una restricción sobre un atributo de calidad. Por ejemplo el requisito “El tiempo medio entre dos fallos consecutivos seráde al menos 6 minutos”, puede interpretarse como la restricciónTTF  6 min.Deestemodo,losproblemasenunciadosenlaSección2demaneraintuitiva se pueden enunciar formalmente como problemas de satisfacción de restricciones o CSP (Constraint Satisfaction Problem) [5] y resolverse con técnicas habituales en la programación con restricciones [12]. Parafacilitar la traducciónde un requisitoexpresadoen lenguaje naturala su restricción equivalentea la vez que se minimizan los problemas inherentes al uso del lenguaje natural, QRL utiliza patrones lingüísticos en el mismo sentido y con la misma forma que se utilizan en [9] (ver Figura 2). Un patrón lingüístico, o abreviadamentepatrón–L, es una frase estándar que representa a todos aquellos requisitos que se pueden expresar respetando la forma y el fondo de la frase. En la notación usada para describir los patrones–L, las palabras o frases entre <y> deben ser convenientementereemplazadas, mientras quepalabrasofrases quese encuentrenentre {y} yseparadasporcomasrepresentan opcionesde las quese deberáescogeruna.Lanotaciónparaescribirrestricciones es muy similar a la empleada para la formación de patrones–L. El principio de definición dual de un requisito “frase en lenguaje natural / restricción”pese a su simplicidad tiene una gran eficacia, pues hasta la fecha no hemos encontrado ningún requisito de calidad que no haya podido ser expresado mediante una restricción. Además, resulta de gran ayuda para definir los esquemas de transformación necesarios para resolver los problemas de definiciones incompatibles que pueden aparecer cuando se utilizan diferentes catálogos de atributos de calidad. Por ejemplo, supongamos que el “tiempo medio entre fallos”(TTF)sedefine en un primer modelo como el número de días que transcurre entre dos fallos consecutivos (TTF 1 ), y como el número de fallos al año en un segundo modelo (TTF 2 ). Es evidente que si tenemos que comparar TTF 1 con TTF 2 es necesario definir una relación que ligue ambas definiciones a fin de hacer posible la automatización. Supongamos que en nuestro esquema de transformacióndefinimos la ecuaciónTTF 1  TTF 2 = 365,de este modo un problema como es el de comparar si TTF 1 > 31 dias satisface la restricciónTTF 2 > 12 errores/año se convierte en el problema de comparar si TTF 1 > 31 dias satisface la restricciónTTF 1 > 30.42 dias. 4. Especificación de Requisitos Con QRL se pueden especificar dos tipos de documentos: las condiciones y las ofertas. Las condiciones expresanel nivel de calidad quedebeproporcionarun determinado servicio WEB para que el cliente acepte utilizarlo. Por su parte, las ofertas expresan el nivel de calidad que ofrece un determinado servicio WEB. La Figura 3 muestra las condiciones que debe satisfacer los servicios WEB que implementen la interfaz IVideoServer y la interfaz ITrailersBank. Como puede observarse, al principio del documento se indican los catálogos de atributos que se utilizarán para especificar requisitos y la definición de las interfaces sobre las que estos se definirán (cláusula pro ducts ). Desde el punto de vista de QRL, el lenguaje base utilizado para definir la interfaz que debe implementar un servicio WEB es completamente irrelevante. Esta decisión de diseño aumenta la aplicabilidad de QRL ya que puede ser utilizado para definir requisitos sobre cualquier “producto”sobre el que sea posible una caracterización con atributos de calidad (ver Sección 8). QRL permitedefinirrequisitosabstractosoestereotipos.Un requisito abstracto debe ser considerado como una facilidad sintáctica que permite disponer de definiciones de requisitos que todavía no se han asociado a ningún producto concreto. Pueden ser definidos tanto en un catálogo de atributos como en un documento de requisitos. Además, es posible definir nuevos requisitos refinando estereotipos previamente definidos. Finalmente, la cláusula conditions permite definir los requisitos concretos de cada interfaz IVideoServer,y en general de cualquier productodefinido en la Sección pro ducts . Dichos requisitos pueden definirse tanto para todas las operaciones de la interfaz (en general de los subelementos que definen un producto) como a operaciones concretas. La secciones de una oferta son las mismas que para las condiciones salvo que la palabra clave conditions se sustituye por oer . En las siguientes secciones comentamos con mayor detalle las posibilidad que QRL ofrece para definir requisitos de calidad. interface IVideoServer { b o olean find ( in Film ); void select ( in Film) raises (FilmNotExists); void play () raises (OutOfOrder); void stop (); void rewind ( in Time); raises (OutOfFilm); }; using com.acme.stdMOWS, com.acme.multimedia; pro ducts { IVideoServer = find, select, play, stop, rewind; ITrailersBank; } valid during 01/JAN/2001..31/DEC/2001 except AUG, 25/DEC/2001 stereotyp es { stdHome: safety.med and robustness.high from 16..24 ; } conditions for IVideoServer { for _ ALL {stdHome}; for play { ro: TTF.min > 120 and TTR.mean + TTR.variance < 90; } for stop { r1: DELAY.percentile90 < 250 msec; } }; conditions for ITrailersBank { global { fiabilidad: TTF > 90 min recuperacion: TTR < 60 seg precio: COST  0.1 euro streaming: STREAMING= true } Descripción sintáctica Condiciones de calidad Figura3. Documento de condiciones para las interfaces IVideoServer e ITrailersBank 4.1. Restricciones Unidimensionales Elformatobásicodelasrestriccionesquese puedeexpresaren QRL es “atributo  valor”. Donde  2f <;  ; = ; 6 = ;  ;>; 2 ;  ;  ;  ; g ,yvalor un valor válido del dominio del atributo. Siguiendo este formato y tomando como referencia los atributos indicadosen los catálogosde la Figura 2, las siguientes restriccionesserían validas:c 1 : TTR  10, c 2 : SFAIL = halt, c 3 : FMASK  {late, value}. Como puede observarse se trata de restricciones en las que sólo interviene un atributo de calidad. 4.2. Caracterización Estadística A veces, puede resultar imposible para el proveedor especificar con una medida absoluta el nivel de calidad que ofrece su servicio. Por ejemplo, el tiempo exacto que tardaráun servicio WEB en responder a una petición es algo imposible de determinar, pues depende de muchas variables. No obstante, siempre es posible someter el servicio a un banco de pruebas tras el cual se disponga de la información necesaria para caracterizar estadísticamente el tiempo de respuesta: valor medio, desviacióntípica, etcétera. Para especificar un atributo de manera estadística, QRL propone un conjunto de palabras reservadas que representan las medidas de localizaciónmás habituales en distribuciones estadísticas. En concreto son: el valor medio (mean), la desviacióntípica (variance), percentiles (desde percentile 1 hasta percentile 99), el valor máximo (max) y el valor mínimo (min). Por último, también es posible especificar valores relativos a la frecuencia relativa (frecuency). A continuación indicamos algunos ejemplos del uso de la caracterización estadística: TTF.min > 10, indica que en el peor de los casos, transcurriránmásde10segundos entre dos fallos consecutivos. TTR.frecuency [5,10] > 35%, indica que el tiempo de recuperación tras un error estáentre 5 y 10 segundos en el 35% de los casos. TTF.percentile 80 > 5, indica que el tiempo entre fallos serámayor que 5 en al menos el 20% (100  80) de los casos. 4.3. Restricciones Multidimensionales Existen situaciones en las que resulta especialmente útil poder expresar restricciones sobre varios atributos de calidad simultáneamente. Imaginemos un sistema que ha de decidir automáticamente entre dos servicios WEB que implementan la misma interfaz. El primero oferta un tiempo medio de respuesta inferior a 50 segundos con una desviacióntípica de10segundos,es decir,quesatisface las restriccionesDELAY.mean < 50 yDELAY.variance < 10, y el segundo oferta un DELAY.mean < 52 y DELAY.variance < 2. Es evidente, que aunque el sistema seleccionaría el primer servicio, pues el segundo servicio no satisface las condiciones del cliente (su tiempo medio supera en dos segundos al máximo admitido), en la mayoría de las ocasiones el segundoservicio resultaría mucho más interesante, pues la variabilidadde su tiempo de respuesta sería significativamente menor. Una forma de evitar situaciones como la anterior, en la que podemos dejar pasar ofertas interesantes,pasa porpermitirrestriccionesque puedanutilizar expresionesaritméticas sobre los atributos. Si en el ejemplo anterior, el cliente hubiese expresado sus preferencias con la restricción(TTR.mean + TTR.variance) < 55, hubiésemos elegido el segundo servicio en lugar del primero. En este tipo de restricciones, resulta especialmente útil poder utilizar intervalos numéricos, pues reduce el tamaño de las especificaciones. Por ejemplo, (TTR.mean + TTR.variance) < 52 and (TTR.mean  TTR.variance) > 48 se puede reescribir como (TTR.mean + TTR.variance) 2 (48, 52). 4.4. Restricciones No Lineales Sin duda alguna, uno de los valores añadidos de cualquier tipo de servicio es su política de precios. En el mundo de la telefoníamóvil, la tarificación por segundos supuso una gran ventaja para los usuarios y la captación de un gran número de éstos para los primeros operadores de telefonía que adoptaron esta política de precios. En el caso de los servicios WEB, la adopción de este tipo de políticas puede conducir a la caracterización mediante funciones no lineales. Pensemosenaquellos servicios WEB que tienenunconsumoderecursos quedepende del tamaño de la entrada. Por ejemplo, para un servicio de conversióndeimágenes, estáclaro que convertir una imagen de 1 MB consume muchos más recursos que convertir una imagen de 1 KB, por tanto, parece lógico que el coste en el primer caso sea mayor que en el segundo. Pero, ¿cómo podemos reflejar esta realidad en el nivel de calidad proporcionadopor el servicio? Con QRL existen varias posibilidades: