Étudiant : Joffrey COULON Responsable pédagogique : Alain APRIL Diplôme : Maîtrise en génie logiciel Session : Été 2016 Rapport MTR891 TITRE Identifier et définir les exigences de qualité logicielles selon la norme ISO/IEC 25030 des particularités d’un système « Cloud » RÉSUMÉ Ce rapport est un rapport de recherche dans le cadre du cours MTR891 sans lien avec une entreprise. Le sujet est : « Identifier et définir les exigences de qualité selon la norme ISO/IEC 25030 des particularités d’un système Cloud ». J’ai choisi ce sujet dans ce domaine après quelques recherches faites dans un cours la session dernière et j’ai trouvé intéressant d’approfondir dans ce domaine. Comme une démarche de recherche, je commencerais par la description du sujet suivi des objectifs puis des résultats attendus pour cette recherche. Par ces sections-là, on passera notamment par une revue des systèmes Cloud dans notre monde d’aujourd’hui afin de mieux comprendre et de se concentrer sur ce qu’on doit étudier en rapport avec la norme ISO 25030 et enfin, quels seront les éventuels apports que cette recherche va permettre dans ce domaine. En deuxième partie, je me concentrerai sur l’état de l’art dans la littérature des exigences de qualité de ce qui différencie les systèmes cloud des systèmes informatiques plus classiques. J’aborderais, par la suite, l’analyse des risques liés à cette recherche. En troisième partie, je vous présenterai mon plan d’exécution et ma méthodologie de recherche associée. Je vous exposerai mes résultats puis les traiterai en les commentant dans la section « Discussion des résultats ». En dernière partie, je parlerai des suites possibles à ce rapport pour contribuer à la recherche dans ce domaine des exigences de qualité des systèmes cloud. Je finirais par une conclusion de ce rapport et les références qui m’ont aidé dans la rédaction de ce dernier. Mots clés 1- ISO/IEC 25030 2- Système « Cloud », SaaS 3- Caractéristiques clés, particularités du cloud 4- Scénarios de qualité
Transcript
Étudiant : Joffrey COULON
Responsable pédagogique : Alain APRIL
Diplôme : Maîtrise en génie logiciel
Session : Été 2016
Rapport MTR891
TITRE
Identifier et définir les exigences de qualité logicielles selon la norme ISO/IEC 25030 des particularités d’un
système « Cloud »
RÉSUMÉ
Ce rapport est un rapport de recherche dans le cadre du cours MTR891 sans lien avec une entreprise. Le sujet est : « Identifier et définir les exigences de qualité selon la norme ISO/IEC 25030 des particularités d’un
système Cloud ». J’ai choisi ce sujet dans ce domaine après quelques recherches faites dans un cours la session
dernière et j’ai trouvé intéressant d’approfondir dans ce domaine. Comme une démarche de recherche, je commencerais par la description du sujet suivi des objectifs puis des résultats attendus pour cette recherche. Par ces sections-là, on passera notamment par une revue des systèmes Cloud dans notre monde d’aujourd’hui afin de
mieux comprendre et de se concentrer sur ce qu’on doit étudier en rapport avec la norme ISO 25030 et enfin, quels seront les éventuels apports que cette recherche va permettre dans ce domaine. En deuxième partie, je me concentrerai sur l’état de l’art dans la littérature des exigences de qualité de ce qui différencie les systèmes cloud des systèmes informatiques plus classiques. J’aborderais, par la suite, l’analyse des risques liés à cette recherche. En troisième partie, je vous présenterai mon plan d’exécution et ma méthodologie de recherche associée. Je vous exposerai mes résultats puis les traiterai en les commentant dans la section « Discussion des résultats ». En dernière partie, je parlerai des suites possibles à ce rapport pour contribuer à la recherche dans ce domaine des exigences de qualité des systèmes cloud. Je finirais par une conclusion de ce rapport et les références qui m’ont
aidé dans la rédaction de ce dernier.
Mots clés
1- ISO/IEC 25030 2- Système « Cloud », SaaS 3- Caractéristiques clés, particularités du cloud 4- Scénarios de qualité
COULON Joffrey Rapport MTR891
Été 2016
2
Tables des matières 1. LISTE DES ABREVIATIONS .................................................................................................................. 3
2. TABLE DES FIGURES ............................................................................................................................. 4
NFRs, « Non-Functional Requirements », exigences non fonctionnelles.
NIST, « National Institute of Standards and Technology ».
PaaS, « Platform as a Service ».
SaaS, « Software as a Service ».
SAiP, « Software Architecture in Practice » [5].
SLA, « Service Level Agreement », Accord de niveau de service.
SQuaRE, « Software product Quality Requirements and Evaluation ».
VM, « Virtual machine », machine virtuelle.
Il peut arriver que quelques traductions portent à confusion, c’est pourquoi j’ai choisi de
mettre l’équivalent en anglais.
COULON Joffrey Rapport MTR891
Été 2016
4
2. Table des figures
FIGURE 1 - DEGRE DE CONTROLE ENTRE FOURNISSEUR ET CONSOMMATEUR [3] .................................... 5
FIGURE 2 - MODELE CONCEPTUEL DE REFERENCE [3] ........................................................................... 6
FIGURE 3 - LES CONCEPTS DE LA NORME ISO 17789 [4] ....................................................................... 7
FIGURE 4 - MODELE POUR CONSTRUIRE UN SCENARIO DE QUALITE [5] ................................................ 11
FIGURE 5 - RELATION ENTRE METRIQUES ET MESURES, EXTRAIT D'ISO/IEC 25010 [7] ...................... 13
FIGURE 6 - COUVERTURE D'UN MODELE DE QUALITE SUR LE PRODUIT LOGICIEL ................................. 15
FIGURE 7 - LES 3 TYPES DE COLOCATION EXCLUSIVE [21] .................................................................. 21
FIGURE 8 - MODELE DE LA QUALITE EN UTILISATION SELON ISO/IEC 25010 [7] ................................ 27
FIGURE 9 - MODELE DE QUALITE DU PRODUIT LOGICIEL SELON ISO/IEC 25010 [7] ........................... 27
COULON Joffrey Rapport MTR891
Été 2016
5
3. Introduction
Les systèmes cloud en tout genre ont subi une énorme avancée au cours des 10 dernières années. Il en existe 3 sortes : définition inspirée d’ISO 17788 [1]
- SaaS, « Software as a Service » : Application fournie avec les capacités qu’offre un système cloud à un client par un fournisseur de service cloud.
- IaaS, « Infrastructure as a Service » : Ensemble de ressources réseau, de stockage et/ou de calcul qu’un client peut utiliser et avoir à disposition par les capacités qu’offre un système cloud de la part d’un fournisseur de service cloud.
- PaaS, « Platform as a Service » : Environnement offert avec les capacités qu’offre un système cloud par un fournisseur de service cloud pour permettre au client de créer, déployer et faire rouler une application du client (qu’il a créée ou acquise) tout en utilisant un ou plusieurs langages de programmation suivant ce que le fournisseur peut supporter.
Il existe beaucoup de variantes à ces 3 sortes de systèmes cloud, et surtout pour le PaaS étant donnée l’ambiguïté de ce qu’on entend par « Environnement » ou « Plateforme ». On peut retrouver nombreuses de ces variantes avec définition et produits disponibles dans la « Cloud Taxonomy » [2].
Malgré ces 3 sortes de systèmes cloud, il existe des points communs entre tous les systèmes Cloud. Le NIST (« National Institute of Standards and Technology ») a sorti en septembre 2011 une architecture de référence pour les systèmes cloud [3] d’un fournisseur qui inclue les 3 sortes de niveaux de services (SaaS, PaaS et IaaS).
Figure 1 - degré de contrôle entre fournisseur et consommateur [3]
COULON Joffrey Rapport MTR891
Été 2016
6
La figure ci-dessus nous décrit bien le degré de contrôle et de responsabilités que le fournisseur et le client ont pour chaque niveau de service cloud. Ce degré est notamment défini de manière la plus exhaustive possible dans l’accord de niveaux de service (SLA). Le NIST introduit également d’autres acteurs qui peuvent intervenir sur les systèmes cloud :
- « Cloud Broker » : Entité entre le client et le fournisseur qui gère l’utilisation, la performance et la bonne délivrance des services cloud ainsi que les négociations entre clients et fournisseurs.
- « Cloud Carrier » : Intermédiaire qui fournit une bonne connexion et un bon transport des services cloud d’un fournisseur à un client.
- « Cloud Auditor » : Partie qui conduit des évaluations indépendantes des services cloud en ce qui concerne leur implémentation.
Chaque acteur (personne ou organisation) participe ou exécute des activités dans l’exploitation du système cloud comme on peut le voir dans la figure 2 ci-dessous.
Figure 2 - Modèle conceptuel de référence [3]
COULON Joffrey Rapport MTR891
Été 2016
7
Peu de temps après en 2014, le groupe ISO/IEC publie 2 normes concernant l’informatique en nuage en s’inspirant d’autres normes du groupe et de publications du NIST. ISO/IEC 17788 [1] nous donne une vue d’ensemble et le vocabulaire concernant l’informatique en nuage tandis qu'ISO 17789 [4] nous donne une architecture de référence selon le groupe ISO. La CCRA (« cloud computing reference architecture ») proposée inclut des rôles, des activités et des composants fonctionnels avec leurs relations entre eux. Elle a entre autres pour but de décrire les caractéristiques fondamentales des systèmes cloud. Elle se concentre notamment sur les exigences « quoi » du système cloud et non pas sur le « comment » plus tourné vers la conception et l’implémentation. C’est pourquoi la CCRA fournit un point de référence technologiquement indifférent et vise à une uniformisation de tous les systèmes cloud qu’importe leur niveau de service et leur domaine d’affaires.
La CCRA peut être décrite en utilisant différentes vues : utilisateur, fonctionnel, implémentation et déploiement. La norme ISO 17789 aborde uniquement les 2 premières vues étant donné qu’on reste neutre technologiquement parlant. La vue utilisateur parle principalement de parties prenantes avec des rôles et sous-rôles qui effectuent seul ou à plusieurs des activités. La vue fonctionnelle découle de cette dernière vue. On y retrouve des couches composées de composants fonctionnels avec des fonctions multicouches qui sont transversales aux couches et aident les composants fonctionnels des couches à accomplir leurs activités. La figure 3 ci-dessous résume de manière conceptuelle le paragraphe ci-dessus expliquant la norme ISO 17789.
Figure 3 - Les concepts de la norme ISO 17789 [4]
COULON Joffrey Rapport MTR891
Été 2016
8
4. Description du sujet
Dans le même contexte et en accord avec la figure 3, le groupe ISO/IEC isole des caractéristiques clés qui définissent un système cloud d’un système non-cloud. Ces caractéristiques sont :
· Un accès large au réseau cloud : le principe est qu’une multitude de clients matériels différents comme les cellulaires, les tablettes, les ordinateurs portables et de bureau aient accès aux services cloud sur le réseau.
· Service mesurable : le principe est que l’usage des services cloud soit surveillé avec des métriques, contrôlé, enregistré et facturé en conséquence au client les utilisant.
· Colocation exclusive : le principe est qu’un ou plusieurs utilisateurs, leurs données et leurs traitements soient isolés les uns des autres sur un même ensemble de ressources physiques et virtuelles qu’ils partagent.
· Libre-service à la demande : le principe est de minimiser au maximum le temps, le coût et les interactions nécessaires pour fournir au client les ressources supplémentaires qu’il demande.
· Élasticité et évolutivité rapide : le principe est de s’adapter à la demande du client en termes de ressources ou de capacités de calcul de telle manière à maintenir un niveau de service aussi performant que convenu avec le fournisseur dans l’entente de niveau de service.
· Mise en commun des ressources : le principe est de supporter la colocation exclusive tout en abstrayant la complexité technique au client.
Les auteurs de « Software Architecture in Practice : 3rd edition » [5] rajoutent une nuance au dernier point en y ajoutant la caractéristique « Indépendance de localisation ». Cela apporte une bonne chose pour le client qui n’a pas à se préoccuper de l’endroit d’où sont ses données et qu’il peut y avoir accès de n’importe quelle machine connectée au réseau. Cependant, plusieurs inconvénients ont été soulevés comme la latence des traitements ou encore le côté juridique et sécuritaire de garder ses données dans son propre pays.
La question est maintenant de définir la portée de la recherche par rapport aux différentes catégories de systèmes cloud qui existent (SaaS, PaaS, IaaS). Dans notre cas, nous travaillons avec la norme ISO/IEC 25030 qui explicite bien dans son titre « Exigences de qualité du produit logiciel ». C’est pourquoi cette recherche s’oriente uniquement sur les SaaS. Si on regarde le niveau plus bas qui est PaaS, il est très difficile de savoir à quoi on fait référence de manière exhaustive et à quel point le client a le contrôle sur l’architecture cloud du fournisseur. Tout dépendamment du SLA, le PaaS proposera un ou plusieurs services, mais les artéfacts concernés ne seront pas considérés comme des logiciels, mais des « plates-formes » tels que des environnements de développement, des bases de données, des serveurs, etc. On parle de PaaS et non plus de SaaS
COULON Joffrey Rapport MTR891
Été 2016
9
quand l’utilisateur ou le client commence à avoir la possibilité de modifier le logiciel par lui-même en termes de fonctionnalités du produit et de sa manière d’utilisation.
5. Objectifs de cette recherche
Toutes les caractéristiques citées ci-dessus spécifiques à un système cloud peuvent s’exprimer comme des exigences fonctionnelles et de qualité. Une des exigences fonctionnelles est le fait d’avoir un hyperviseur qui va gérer les différentes machines virtuelles tout en s’accordant avec les différentes ressources physiques. On peut aussi citer l’ordonnanceur ou encore le « Page Mapper ».
Dans notre cas, nous allons nous concentrer sur les exigences de qualité qu’un SaaS doit prendre en considération pour se différencier d’un logiciel non-cloud. Selon la norme ISO 25030 [6], les exigences de qualité sont définies comme des exigences qui font le lien entre les exigences fonctionnelles et les exigences de qualité du système. Il se peut également que des exigences de qualité résultent en des exigences fonctionnelles à part entière étant donnée l’ampleur de l’exigence de qualité sur le logiciel.
Une exigence de qualité nécessite une fonction/programme capable d’interpréter une propriété de qualité logicielle sous forme d’une valeur. L’un des premiers travaux sera de rechercher ces valeurs pour les particularités d’un SaaS, idéalement quantitative pour ainsi mesurer la particularité selon une échelle internationale compréhensible de tous. Ensuite, les particularités doivent atteindre une certaine valeur dans leur échelle. En effet, une valeur cible de la mesure de qualité logiciel représente une exigence de qualité logiciel [6]. ISO/IEC 25030 s’inspire de la norme « ISO/IEC 15288:2002 – Software engineering – system life cycle processes », mais d’un point de vue logiciel, la majorité des activités prescrites dans cette norme vieille de 14 ans ne sont pas très pertinentes pour notre recherche. L’un des points dans le processus d’analyse des exigences qui va dans notre sens est le fait de définir des mesures techniques et de qualité en utilisation qui permet l’accomplissement des objectifs techniques.
Outre les exigences des parties prenantes d’ISO/IEC 25030, la norme nous dit quoi faire pour avoir des exigences de qualité logicielle. On assume premièrement que toutes les décisions architecturales à haut niveau ont été prises. Ensuite, il nous faut un modèle de qualité avec des mesures pour associer des caractéristiques à de la qualité. Étant dans la série des normes SQuaRE, les normes de référence d’ISO 25030 sont ISO/IEC 25010 [7] pour les modèles de qualité (voir annexe 14.1 et 14.2) et « ISO/IEC 25020:2007 - Software engineering -- Software product Quality Requirements and Evaluation (SQuaRE) -- Measurement reference model and guide » pour les mesures. Le modèle de qualité du produit logiciel nous sert à couvrir les exigences de qualité logicielle interne et externe tandis que le modèle de qualité en utilisation pour le système entier
COULON Joffrey Rapport MTR891
Été 2016
10
qu’on peut voir comme une boîte noire. Enfin, la norme ISO 25030 nous dit quoi prendre en compte et documenter le plus possible afin que l’implémentation du système final soit de la meilleure qualité possible. Les exigences de qualité logicielle (et aussi des parties prenantes) qui sortent de cette norme servent pour la phase d’explication des exigences du projet et comme intrants pour le processus d’évaluation du logiciel.
Dans ce registre et en termes de comment y arriver, je propose la méthode des scénarios de qualité des auteurs du livre SAiP « Software Architecture in Practice » [5]. Le principe est d’associer un scénario de qualité à un attribut de qualité. Dans notre cas avec nos modèles de qualité d’ISO 25010, on parlera plutôt de caractéristiques. La différence littéraire se pose entre « le degré avec lequel »(ISO) et « à quel point »(SAiP). Dans chaque scénario de qualité, on a 4 à 6 éléments à prendre en compte suivant l’avancée des décisions architecturales du projet qui sont :
· Le stimulus : évènement envoyé au système qui peut se manifester comme une opération utilisateur, une requête ou encore même une attaque.
· La source du stimulus : Le stimulus arrive forcément d’une entité quelconque. Il est possible qu’on souhaite un traitement différent pour le même stimulus venant de 2 sources différentes.
· L’artéfact (optionnel) : Partie de l’architecture logicielle concernée. On peut mettre le logiciel en entier ou seulement certains modules, etc.
· L’environnement (optionnel) : l’environnement sert à définir des circonstances à l’artéfact qui le reçoit et qualifie donc le stimulus qui arrive. On peut définir en production, en période intense d’activités, en test ou encore pendant la phase de conception tout dépendamment de la caractéristique associée.
· La réponse : On parle ici de ce qu’on veut faire ressortir en termes de métrique après le processus du traitement de ce stimulus venant de cette source par cet artéfact dans cet environnement. Les métriques peuvent être diverses et variées, mais la ou les métriques pour un scénario doivent être en lien avec la caractéristique de qualité associée à ce scénario. Par exemple, on associera un temps de réponse en seconde à un scénario de performance ou un pourcentage de couverture de code par les tests à un scénario de testabilité. Tout dépend du ou des modèles de qualité ainsi que des métriques.
· La mesure de la réponse : Elle définit un objectif à atteindre pour que le scénario de qualité soit déclaré comme un succès. L’objectif peut être une mesure à atteindre, dépasser ou ne pas dépasser inclus dans la réponse. Par exemple, en dessous 15 secondes de traitement sans faute, plus 95% de couverture de code ou 2 tables de la base de données créées.
L’artéfact et l’environnement sont déclarés optionnels, car tôt dans le projet logiciel ou par manque d’informations précises, il peut parfois être difficile de les spécifier. Cependant, cela peut aussi vouloir dire « pour tout environnement et sur l’ensemble du logiciel ».
COULON Joffrey Rapport MTR891
Été 2016
11
La figure 4 ci-dessus expose le modèle pour construire ces scénarios de qualité. Le processus est donc :
1. Construire un scénario de qualité avec le maximum d’informations et de composantes pour une meilleure compréhension sans oublier les 4 essentielles et non optionnelles.
2. Et d’y associer une caractéristique de qualité afin de fournir des intrants à un processus d’évaluation du logiciel pour cette caractéristique de qualité.
L’association entre les métriques et les caractéristiques est logiquement déjà faite dans notre contexte des modèles de qualité.
6. Résultats attendus
La première étape sera de fournir des propositions de liens entre une ou plusieurs caractéristiques clés d’un SaaS avec une ou plusieurs caractéristiques de qualité, de préférence inscrites dans un modèle de qualité et de préférence ceux d’ISO/IEC 25010 ou en accord avec. La deuxième étape sera de fournir un à plusieurs scénarios de qualité en commençant par déterminer les métriques utilisées pour signifier comment on va exprimer la qualité d’un SaaS pour cette caractéristique clé. On complétera par la suite le reste du scénario de qualité avec le plus d’informations possible qu’on pourra trouver dans la littérature. En résumé, on aura une caractéristique clé du cloud avec des caractéristiques (ou sous-caractéristiques) de qualité. Ces caractéristiques de qualité peuvent être utilisées dans d’autres caractéristiques clés du cloud. Puis,
Figure 4 - modèle pour construire un scénario de qualité [5]
COULON Joffrey Rapport MTR891
Été 2016
12
on a des métriques qui seront cruciales à identifier. Elles nous servent d’intrants pour un scénario de qualité qu’on complètera le plus possible par la suite.
Le but est aussi de rester le plus technologiquement neutre possible afin de pouvoir convenir au maximum de SaaS se trouvant dans l’industrie. Étant donné ce fait, les scénarios de qualité seront certes insuffisants selon ISO 25030, en particulier pour le côté documentation, mais ils donneront une bonne vue d’ensemble des exigences, une bonne lisibilité pour l’explication de ces dernières et peuvent servir comme intrants au processus d’évaluation du logiciel.
7. État de l’art
Dans beaucoup d’articles, on distingue 2 types de qualité exprimés :
1. La qualité en tant que telle du produit hébergé dans le nuage. On peut faire le rapprochement dans notre cas aux qualités internes et externes.
2. La qualité que le produit dégage via cette plateforme. On peut faire le rapprochement dans notre cas aux qualités du produit en utilisation.
L’article « Quality Model for Evaluating SaaS Service » [15] part dans cette voie et nous donne un modèle de qualité pour un SaaS. En ce qui nous concerne pour le logiciel en tant que tel, les auteurs nous proposent 2 parties qui sont la qualité du logiciel et la qualité de « l’application », sous-entendu servi par le cloud. Pour la première partie, les auteurs ont tout simplement cité la norme ISO/IEC 25010. En revanche, pour la 2ème partie, ils ont fourni un nombre de mesures associées qui sont :
· Colocation exclusive qu’ils mesurent avec 3 facteurs : o Capacité de permettre aux colocataires de partager des bases de données o Capacité de permettre aux colocataires de partager des instances o Capacité de fournir du support pour les données, les processus de travail, etc.
· Degré de configuration du SaaS
· Degré d’isolation des données
· Réponse aux demandes de changement
· Interopérabilité en termes d’accueil lors d’un déménagement d’un système cloud à un autre.
· Tolérance aux fautes du logiciel
Le « Cloud Services Measurement Initiative Consortium » (CSMIC) [16] en propose une liste beaucoup plus exhaustive. Dans l’article en [17], les chercheurs s’inspirent de ces mesures pour aider les utilisateurs à évaluer la qualité d’un système cloud. Ils ont rassemblé un total de 6 groupes de 30 mesures. D’autres auteurs [18] se sont penchés sur la visualisation de la qualité du système cloud de manière visuelle et ont par ce fait, proposé leur modèle de qualité avec des
COULON Joffrey Rapport MTR891
Été 2016
13
mesures qu’ils expliquent par la suite. Ils nous rappellent un point cité dans la norme ISO 9000 qui est « La qualité est définie par le degré auquel un ensemble de caractéristiques intrinsèques satisfait les besoins et les attentes de l'utilisateur » [19]. Le principal concerné est donc l’utilisateur et ceux qu’il ressent, c’est pourquoi on parle beaucoup de qualité de service, sous-entendu à l’utilisateur.
Malheureusement d’un point de vue technique logiciel, toutes ces mesures mentionnées ci-dessus n’ont pas de métriques associées bien définies, c’est-à-dire une fonction qui va nous permettre de donner une valeur quantitative à ces mesures.
Le point à aborder, en toute logique, est maintenant le SLA qui régit entre l’utilisateur/client et le fournisseur. Cet accord de niveaux de service comprend en grande partie les fonctionnalités que le client a accès sur le système cloud du fournisseur, mais il peut aussi contenir également les ententes de qualité, souvent en termes de performance. Selon l’article [20], les NFRs (« Non-Functional Requirements ») ou exigences non fonctionnelles sont en dehors des SLAs de chaque client. Les auteurs conseillent d’inscrire ces NFRs dans un modèle de qualité du logiciel et un modèle de qualité en utilisation que le fournisseur aura lui-même choisi de suivre. Les auteurs poussent à la conformité avec ISO 25010 de la série de normes SQuaRE dans la définition des caractéristiques, sous-caractéristiques, attributs et métriques. Cet ensemble SLA+NFRs forme pour eux un modèle unique qu’ils appellent le modèle de surveillance des exigences qui va s’appuyer sur le modèle de qualité du SaaS et sur le modèle de qualité en utilisation pour les NFRs.
Figure 5 - Relation entre métriques et mesures, extrait d'ISO/IEC 25010 [7]
COULON Joffrey Rapport MTR891
Été 2016
14
8. Analyse des risques
L’un des risques à soulever pour la recherche qui va suivre est l’applicabilité de SQuaRE pour les systèmes cloud. En effet, même si quelques articles peuvent faire la liaison avec la norme ISO/IEC 25010 pour exprimer la qualité du SaaS, les caractéristiques clés d’un système cloud peuvent créer un écart d’analyse et doivent être prises en compte dans le modèle de qualité pour éviter cet écart. De plus, certains autres articles peuvent proposer leurs propres modèles de qualité pour les SaaS. Ces modèles de qualité peuvent très bien ne pas être assez détaillés et donc ne pas pour être fiables. En effet, la construction du modèle peut ne pas être la même que dans la norme ISO 25010 (section 3.1, figure 2 et figure C.1). Elle dit que cette décomposition hiérarchique en caractéristiques, sous-caractéristiques, propriétés et mesures est la meilleure manière d’exprimer la qualité d’un logiciel.
Un autre risque est de savoir si les caractéristiques de qualité qu’on va nous proposer pour les particularités du cloud (incluant SaaS) s’inscrivent ou non dans un modèle de qualité avec cette décomposition citée ci-dessus. Si ce n’est pas le cas, l’applicabilité à la série de norme SQuaRE est à mettre en doute. Toutefois, si le ou les auteurs nous proposent des métriques associées, on se rapproche néanmoins de la construction d’un modèle de qualité.
Tous les modèles de qualité présents dans la littérature n’ont pas forcément tous la même valeur et ne respecte pas forcément les mêmes lois que celles dites dans ISO/IEC 25010 de la famille SQuaRE. Les auteurs de l’article [8] proposent une suite de règles pour bien construire et évaluer un modèle de qualité. Le principal problème soulevé est l’ambiguïté entre les différentes relations d’un modèle de qualité. La plupart du temps, il n’y a pas de définitions claires, règles ou procédures qui nous permettent de dériver d’une caractéristique à une sous-caractéristique ou qui nous permettent de lier une caractéristique à une métrique. Comme dit précédemment, on préférera le modèle de qualité du produit logiciel d’ISO/IEC 25010, mais il n’est peut-être pas représentatif de ce qu’un SaaS est en réalité en termes de qualité. Les recherches dans ce domaine datent des 2-3 dernières années et très peu d’articles sont donc disponibles pour aider à la contribution de ce rapport. ISO/IEC 25010 a sorti sa dernière version en 2011 et les 2 architectures de référence présentées ci-haut datent de fin 2014. L’un des problèmes soulevés dans l’article [8] et qui peut s’appliquer dans ce cas-là pour cet écart de date est la couverture du modèle de qualité ISO 2010 pour le produit logiciel.
COULON Joffrey Rapport MTR891
Été 2016
15
Comme le montre la figure 5 ci-dessus, il y a 3 cas de figure :
1. La caractéristique proposée ne couvre pas le produit logiciel et est donc une « extra » caractéristique.
2. La caractéristique proposée couvre bien le produit logiciel et contribue donc à la couverture du produit logiciel par le modèle auquel elle appartient. C’est le cas de figure que tous les modèles de qualité recherchent pour chacune de leurs caractéristiques.
3. La caractéristique n’est pas proposée par le modèle, mais couvre une partie de la qualité du logiciel.
Ce dernier cas de figure est peut-être la réalité en ce qui concerne l’applicabilité des SaaS cloud sur le modèle de qualité du produit logiciel ISO 25010.
Figure 6 - Couverture d'un modèle de qualité sur le produit logiciel
COULON Joffrey Rapport MTR891
Été 2016
16
9. Plan d’exécution
Voici mon plan d’exécution que j’ai tenu tout au long de cette recherche :
Revue littéraire spécialisée pour chaque caractéristique clé du
cloud
· Une caractéristique clé du cloud
· Banques de données d’articles
· Résumé de l’existant · Liens possibles en
termes de qualité · Scénario de qualité
complété au mieux
Suggestion de suite de cette recherche
· Ensemble des articles trouvés sur les caractéristiques clés du cloud
· Suite de la recherche
Rédaction de la conclusion et formalité de remise
· L’ensemble des parties déjà écrites du rapport
· Rapport final
COULON Joffrey Rapport MTR891
Été 2016
17
10. Méthodologie de recherche
Compte tenu de ce plan d’exécution, je vais maintenant exprimer ma méthodologie qui m’a permis d’effectuer cette recherche. J’ai choisi de faire une recherche littéraire sur le sujet tout en m’imposant un cadre de travail que je vous présenterais afin de filtrer les recherches et pouvoir générer au mieux les résultats attendus.
Étant étudiant à l’ETS, j’ai décidé de prendre, comme ensemble de documents de recherche, le catalogue de la bibliothèque ETS [9] ainsi que les 5 bases de données spécialisé dans le domaine logiciel et TI qui sont :
· ACM Digital Library [10]
· Applied Science & Technology Source [11]
· Computer Database [12]
· IEEE Xplore [13]
· INSPEC [14]
Le but est de trouver des articles qui concernent notre recherche et si possible le plus récent possible. Les architectures de référence datent de 2014 donc plus récents que 2013 au possible.
Après la retranscription de l’existant de manière globale dans la littérature dans l’état de l’art, je me suis plus focalisé sur l’intégration des logiciels du point de vue de la qualité dans les systèmes cloud pour chacune de ses caractéristiques clés ou particularités citées plus haut dans la section « Description du sujet ». Je vais recueillir un maximum de caractéristiques de qualité pour une particularité, fournir l’inscription de ces caractéristiques trouvées dans un quelconque modèle de qualité ainsi que les éventuelles métriques associées. J’expliquerais mes croisements entre une ou plusieurs métriques qui se trouvent parmi un ou plusieurs articles. Le but est de couvrir au mieux la particularité du cloud avec des exigences dites non fonctionnelles (NFRs) pour l’application du logiciel dans un système Cloud (pour ainsi devenir un SaaS).
Un ou plusieurs scénarios de qualité seront ensuite présentés puis expliqués en détail avec au mieux les références à un ou plusieurs articles de la recherche. La mesure de la réponse à atteindre pour chaque scénario de qualité sera optionnelle dans notre cas, car cette valeur varie suivant la particularité du cloud qu’on est en train de traiter. Elle peut dépendre du SLA, des attentes du client pour ce qui est des NFRs ou des capacités de service que le fournisseur peut apporter à ses clients.
COULON Joffrey Rapport MTR891
Été 2016
18
11. Discussion des résultats
11.1 Accès large au réseau cloud
Pour cette particularité en ce qui concerne les logiciels hébergés sur le cloud (SaaS), le logiciel n’a pas de grand impact ou d’exigences de qualité particulière. Cependant, la chose à retenir avec mon expérience et ma revue littéraire est que cette particularité est à prendre en considération dans le déploiement d’un SaaS et qu’elle ne doit pas affecter les autres exigences de qualité du logiciel lui-même.
On parle ici d’un accès large au réseau avec différents clients hétérogènes comme un ordinateur, un téléphone intelligent ou une tablette. Partout où le fournisseur du SaaS propose son service en termes de type de client matériel, les exigences de qualités du logiciel de base (en lui-même) doivent être respectées. Par exemple, si je demande une information sur un mobile ou sur un ordinateur, le temps de réponse ne doit pas dépasser une certaine limite (exigence de qualité pour la performance du logiciel de base). Le point le plus sensible là-dessus est en ce qui concerne l’utilisabilité du logiciel où on peut voir apparaître bien souvent des exigences de qualité pour chaque plateforme tout dépendamment de la complexité du logiciel. Les auteurs de SAiP [5] proposent des mesures telles que le temps moyen d’une tâche fait par un panel de personnes, nombre moyen d’erreurs ou encore des formulaires de satisfaction.
En résumé, notre scénario de qualité pour cette particularité serait :
· Le stimulus : Pour chaque fonctionnalité/personnages, scénarios indépendants du client matériel
· La source du stimulus : Pour chaque client matériel supporté
· L’artéfact : le logiciel SaaS
· L’environnement : sur le réseau supporté
· La réponse : il faut que les mesures pour chaque exigence de qualité
· La mesure de la réponse : satisfassent ces dernières
11.2 Service mesurable
Pour cette particularité, on parle surtout des métriques et mesures qu’on va établir pour le logiciel pour la fourniture des services cloud. CLOUDQUAL [26] est un modèle de qualité proposé pour évaluer le logiciel au sein d’un système cloud. On y compte 6 caractéristiques qui sont orientées du point de vue de l’utilisateur final :
· Utilisabilité : c’est la seule des caractéristiques qui est subjective et non objective du modèle. Comme déjà discutées au-dessus, les interfaces utilisateurs peuvent changer d’un client matériel à un autre. Les auteurs [26] recommandent d’utiliser les
COULON Joffrey Rapport MTR891
Été 2016
19
interfaces utilisateur web vu qu’elles sont très bien standardisées et requièrent uniquement un navigateur internet très familier pour les clients. Le but de cette caractéristique est bien sûr le plus intuitif pour le client et le plus interactif avec lui.
· Disponibilité : on l’a défini comme le rapport entre le temps d’activité sans interruption et le temps total d’une période d’opération pour le logiciel. L’interruption doit venir du logiciel pendant une période d’opération. La VM dans ce cas demandera au logiciel de redémarrer. Le but est de ne jamais que les VM est à redémarrer le logiciel pour être de nouveau opérationnel. On atteint dans ce cas la disponibilité absolue et qui est voulue par beaucoup.
· Fiabilité : On l’exprime par le nombre d’opérations échouées sur le nombre d’opérations total qu’on va soustraire à 1 pour ainsi fixer comme but d’atteindre 1. En effet, plus le nombre d’opérations échouées est bas, plus notre service est fiable. 2 autres mesures de la fiabilité sont le « mean time between failures (MTBF) » et le « mean time to failure » (MTTF) qui sont soulevé dans CLOUDQUAL et SAiP.
· Réactivité : On l’exprime entre autres avec la mesure de performance la plus utilisée qui est le temps de réponse entre l’envoi de la requête et la réception de la réponse. La valeur de référence dans la même unité de temps est définie selon le fournisseur et représente le temps maximum acceptable. Elle va servir de dénominateur commun pour les précédents temps de réponse. Pour le CLOUDQUAL, tous les temps de réponse disponibles sont mis dans un échantillon où on va y extraire la moyenne et la médiane pour la comparer au temps de référence acceptable maximum. Cette donnée est bien souvent non mentionnée dans le SLA.
· Sécurité : On parle ici de la résistance du logiciel aux attaques. La mesure est le temps avant que la première attaque répertoriée arrive par rapport aux temps d’utilisation. Le but est d’avoir le temps au numérateur égal au temps d’utilisation en tout temps, ce qui veut dire que le ratio est égal à 1 et l’application est sécuritaire.
· Élasticité : On l’exprime par requête avec le nombre de ressources allouées par rapport au nombre de ressources requises pour cette même requête. Plus ce ratio est proche de 1, plus le service est adapté en ce qui concerne l’élasticité. S’il est trop petit que 1, le service sera ralentit. S’il est plus grand que 1, le service sera surconsommateur. Je reviendrais là-dessus dans la partie de l’élasticité et surtout concernant l’interaction avec les centres de données.
On remarque que beaucoup de ces métriques n’apparaissent pas dans le SLA et pourtant, c’est une information que tous les clients aimeraient avoir avant de prendre un fournisseur de service cloud. L’article « Service Response Time Measurement Model of Service Level Agreements in Cloud Environment » [27] nous présente une solution pour rassurer le client dans son choix où les auteurs vont tout simplement proposer un cadre de simulation d’un système cloud client au moment de l’établissement du SLA. En résumé, on va déployer l’application client à
COULON Joffrey Rapport MTR891
Été 2016
20
travers toutes les machines physiques/virtuelles du fournisseur et simuler des cas d’opérations normales et extrêmes pour chaque type d’opérations et systèmes clients. Par ce fait, si on présente ce rapport au client, il peut avoir un benchmark de ce que le client peut avoir, mais c’est à la liberté du fournisseur de divulguer les informations qu’il veut. Les données extraites de ce cadre de simulation sont des temps de réponse et des erreurs d’une ou plusieurs requêtes. Les caractéristiques de CLOUDQUAL seulement visées sont donc la réactivité et la fiabilité qui sont les 2 caractéristiques qui ressortent dans la littérature en termes de métriques et mesures.
En résumé, notre scénario de qualité pour cette particularité serait :
· Le stimulus : demande ou utilise le service cloud avec de nombreuses requêtes
· La source du stimulus : chaque utilisateur de mon client
· L’artéfact : Logiciel propriétaire du client ou du fournisseur
· L’environnement : le cloud du fournisseur
· La réponse : les requêtes complétées avec leur temps de réponse
· La mesure de la réponse : 1. L’échantillon et les statistiques autour des temps de réponse (moyenne,
extrême, etc.) sont convenables 2. Le nombre de requêtes échouées est convenable
Due à la complexité de mettre une cadre de simulation comme dans [27], beaucoup d’articles parlent de la prédiction du temps de réponse de manière analytique en considérant toutes les couches du cloud que la requête doit traverser [28] ou encore de manière statistique avec une prédiction Bayesian [29]. Ce temps de réponse varie bien évidemment par rapport au modèle de déploiement du cloud. Plus le système cloud vise une population petite et finie (non variant), plus il est facile de prédire ce temps de réponse et de l’optimiser. Les auteurs en [30] s’attaquent à cette optimisation du temps de réponse pour une population finie d’utilisateur sur un système cloud. L’article [30] parle également de l’optimisation de l’utilisation des ressources qui a plus à voir avec l’élasticité dans notre cas qui sera abordé dans une prochaine section.
11.3 Colocation exclusive
Pour cette particularité, j’ai choisi de traduire « multi-tenancy » par « colocation exclusive », car ce sont des personnes qui partagent un même espace comme des colocataires, mais avec aucun croisement des traitements ou données entre ces personnes. Les traitements et données doivent isoler les unes des autres par client de manière générale. Cette règle varie en fonction du mode de déploiement du système cloud. L’article en [21] nous rappelle la construction de la colocation qui se met en place jusqu’au logiciel (voir figure 7).
COULON Joffrey Rapport MTR891
Été 2016
21
Les utilisateurs au sein d’une même application ne doivent même pas savoir qu’ils la « co-utilisent ». Ils ne doivent pas avoir accès aux données ou traitements des autres « co-utilisateurs » ni même les voir ! La « multi-tenancy » concerne donc l’aspect sécuritaire des traitements et données du client. En faisant un parallèle avec la sécurité de CLOUDQUAL, on aurait un scénario comme celui-ci :
· Le stimulus : effectuer des traitements avec des données
· La source du stimulus : un utilisateur
· La réponse : temps avant la première visibilité ou le premier accès à des traitements ou données par un co-utilisateur ou une entité non autorisée.
· La mesure de la réponse : 1. Ce temps n’existe pas selon les fournisseurs de services cloud 2. On peut comparer ce temps par rapport à un temps d’utilisation totale au cas
où il existe.
Certes de nos jours, tous les fournisseurs de service cloud prétendent que cet aspect sécurité de la colocation exclusive est respecté 100% du temps.
Un autre aspect qui est exprimé dans la littérature est l’efficacité. Dans les articles [31] et [32], les auteurs nous parle du défi de la colocation exclusive sur l’efficacité du système cloud. Cette efficacité n’est pas inscrite dans un modèle de qualité, mais fait partie de la qualité de service promise dans le SLA. Les métriques abordées sont des temps de réponse et des débits de téléchargement pour des applications avec beaucoup de « co-utilisateurs ». Les articles proposent chacun leur méthode d’évaluation d’applications étant soumises à la « multi-tenancy » en faisant justement jouer ce facteur dans leur méthode ce qui n’est pas le cas de certaines méthodes.
Le dernier aspect pour cette particularité cloud se passe au niveau de l’application et concerne les mises à jour logicielles ou montées de version. En effet, les clients ne sont pas toujours conscients des mises à jour, des montées de version. Ils peuvent ne pas vouloir cette mise à jour, car il effectue déjà des traitements par exemple. Cependant, un autre client peut vouloir cette mise à
Figure 7 - Les 3 types de colocation exclusive [21]
COULON Joffrey Rapport MTR891
Été 2016
22
jour. L’article en [33] soulève les différents problèmes actuels d’évolution continue d’un SaaS avec des co-utilisateurs. Les auteurs proposent ensuite une méthode pour offrir cette opportunité au fournisseur pour ces clients. La méthode soulève 4 exigences :
1. Donner du contrôle au client dans la gestion des versions et mises à jour voulues 2. Isoler les mises à jour et montées de version voulues par client 3. Supporter la complexité de toute cette nouvelle gestion pour assurer la continuité du
service o Déplacer un co-utilisateur sur une autre application, car il veut la nouvelle
mise à jour o Montée de version une application, car les co-utilisateurs de cette dernière la
veulent tous o Etc.
4. Automatiser cette nouvelle gestion
Le point 1 et le point 4 rentrent en conflit, car le fait d’automatiser donne moins d’opérations manuelles à faire et aussi moins de contrôle. Par conséquent, le client et le fournisseur doivent communiquer et se mettre d’accord sur le contrôle du client sur cette gestion des mises à jour et montées de version. Par exemple, un client peut choisir d’avoir le contrôle sur les versions (v1 ou v2, etc.), mais d’automatiser les mises à jour (v1.1, v1.2, v1.3 installé au fur et à mesure sur l’application que le client utilise et lui est assigné de manière automatique).
11.4 Libre-service à la demande
Pour cette particularité du point de vue du client, on parle surtout qu’il peut faire tout ce qu’il veut sur le service cloud par rapport aux fonctionnalités qu’il a accès et indépendamment de la puissance de traitement. C’est le cas pour la plus grande des fournisseurs cloud dans l’industrie. La réponse du service cloud ne doit pas laisser apparaître la puissance de traitement supplémentaire allouée pour cette tâche pour cet utilisateur. Cependant, dans certains cas, on peut voir des dépassements de la puissance de traitement maximum par rapport au SLA établi entre le client et le fournisseur qui reste le plus souvent invisible pour le client au moment de la réception de la réponse.
En résumé, notre scénario de qualité pour cette particularité serait :
· Le stimulus : demande et/ou réception d’un service sur le cloud
· La source du stimulus : utilisateur identifié avec un client associé
· La réponse : la demande et/ou réponse est correctement faite il faut que les mesures pour chaque exigence de qualité
· La mesure de la réponse : satisfassent ces dernières
Ces dépassements ne vont pas être bloqués dans la plupart des cas, car ce qu’on veut, c’est donner au client ce qu’il veut au client sur l’instant, mais on va lui facturer le dépassement dans la
COULON Joffrey Rapport MTR891
Été 2016
23
plupart des cas tout dépendamment du SLA établi à cette clause. Aucun client et fournisseur n’aime les violations de SLA. Pour le client, il va soit être bloqué ou facturé à la fin. Pour le fournisseur, il va souffrir de la non-satisfaction du client ou d’une mauvaise image de ces services cloud qu’il offre. La partie suivante sur l’élasticité et l’évolutivité rapide du cloud supporte en réalité cette particularité où je vous présenterais les progrès à ce sujet.
Toutefois, on peut parler du « Palladio Bench » [24] qui est un EDI spécialisé dans la construction de diagramme de caractéristiques de qualité. Ces diagrammes sont censés être représentatifs du comportement du système cloud. « Palladio Bench » est donné au client pour l’aider pendant la phase de conception du système. Il intègre des modèles comme le processus de Markov à temps discret qui est ensuite considéré comme les conditions SLA à respecter [25].
En allant plus loin, on soulignera les chercheurs de l’article en [23] qui nous présente une manière de synchroniser les conditions définies dans le SLA de chaque client avec les serveurs en utilisation. Nous avons un module de décision globale entre les VMs et les applications et il accueille toutes les métriques monitorées par ces 2 dernières. Ce module global est synchronisé avec les conditions du SLA pour chaque client et prend action sur les VMs et ressources physiques si nécessaire par rapport aux algorithmes configurés. Nous avons aussi un module de décision local à chaque application qui fonctionne. Il reçoit du module global le droit de déménager, s’installer ou de se relancer sur une VM en particulier qui a plus de ressources qu’une autre par exemple.
11.5 Élasticité et évolutivité rapide
Pour cette particularité cloud, la partie concernée est surtout au niveau des machines virtuelles et de l’infrastructure. Le but est d’apporter la qualité de service promis dans le SLA à un client tout en s’adaptant à son activité au cours du temps. Chaque fournisseur a sa propre implémentation et ses techniques de comment gérer ces ressources matérielles et ses VMs. La métrique qui ressort dans la littérature est le temps de réponse qui doit toujours être le plus petit et optimale possible. Cette optimisation et rapidité ne peut se faire avec des opérations manuelles d’allocations des ressources pour satisfaire les exigences du SLA. Beaucoup d’algorithmes différents sont présents dans l’industrie et beaucoup sont proposés dans la littérature. Les auteurs [21] se reposent sur la « Queueing Theory » [22] qui propose le modèle « M/G/s/s+r » qui prend en compte le nombre de CPU utilisé parmi tant d’autres paramètres. Si le temps de réponse n’est pas suffisant selon l’algorithme « temps de réponse/nombre de CPU/contexte » (en résumé large), on va allouer plus de ressources et refaire la requête.
Il peut arriver que plusieurs algorithmes soient présents pour un seul système cloud sur différents composants. Dans ce cas, l’important est que cette concurrence des algorithmes ne rentre pas en conflit les uns avec les autres et affecte la performance ou même la délivrance du service. Les auteurs de « À framework for the coordination of multiple autonomic managers in cloud environments » [34] nous font part de leur méthode de coordination de multiples gestionnaires
COULON Joffrey Rapport MTR891
Été 2016
24
automatiques des ressources où leur modèle se divise en un côté application et un côté infrastructure.
L’article en [35] nous rappelle le fait que la recherche de la meilleure performance d’un point de vue compétitif pour un fournisseur peut parfois minimiser d’autres qualités comme les préoccupations de sécurité mentionnées dans la colocation exclusive ou dans CLOUDQUAL ; les données peuvent être visibles ou accessibles ou encore la réplication du logiciel donne en théorie plus de failles potentielles à exploiter. Les auteurs de [35] proposent leur algorithme d’élasticité en prenant en compte l’optimisation de la performance et les préoccupations de sécurité du client.
Le dernier point à aborder avant de clore cette section est la consommation énergétique que tous ces algorithmes entrainent pour un centre de données. En effet, le client n’a aucune idée de la charge de travail et de la consommation énergétique qui sont investies pour satisfaire sa qualité de service voulue. Le fournisseur dans son cas ne fait pas attention à ce critère, car l’économie d’énergie n’est bien souvent pas synonyme de performance et le fournisseur veut toutefois rester compétitif. Les chercheurs de [36] propose une solution pour réduire au plus la consommation d’énergie des centres de données. Ils identifient précisément les gains à faire sur le logiciel, « middleware » et matériel en ce qui concerne le gaspillage d’énergie sans impacter considérablement les mesures de qualité.
11.6 Mise en commun des ressources
Pour cette particularité, elle relate surtout de l’abstraction de la complexité de la colocation exclusive. Le point qui fait débat à ce sujet est sur la localisation de tous les traitements et données que les utilisateurs effectuent ou stockent.
COULON Joffrey Rapport MTR891
Été 2016
25
12. Suite de la recherche
Beaucoup d’articles parlent du sujet sans jamais rentrer dans les détails et ils s’arrêtent souvent à référencer la norme ISO/IEC 25010 pour ce qui est des caractéristiques des modèles qu’ils appliquent à leur logiciel dans le cloud. Pourtant, il y a bien un écart d’analyse avec l’émergence des logiciels dans le cloud. Énormément de considérations sont dues à la plate-forme qui change certes, mais le logiciel doit s’adapter aussi. L’idéal serait donc de proposer un modèle de qualité du produit logiciel d’ISO/IEC 25010 sur mesure pour le cloud qui prendrait en considération les 6 ou 7 particularités cloud. Ce serait certainement un modèle à part du modèle déjà existant de qualité du produit logiciel d’ISO/IEC 25010 à classer dans une autre série de normes spécialisée dans le cloud.
Avec ce nouveau modèle, il faudrait l’évaluer avec l’article en [8] qui nous fournit une suite de règles quant à l’évaluation de ce modèle. Le plus gros du travail pour satisfaire aux exigences d’un bon modèle sera de fournir des métriques, fonctions et mesures associés pour les éventuelles nouvelles caractéristiques ou sous-caractéristiques et de plus, adaptées au cloud. Le travail comprend en partie l’analyse des mesures existantes du modèle pour les adapter si nécessaire au cloud.
Vers la fin de cette recherche au mois de Juin 2016, 2 nouvelles normes sont sorties et il serait très intéressant de les prendre en considération pour le nouveau modèle de qualité adapté au cloud :
· ISO/IEC 25022:2016 « Systems and software engineering -- Systems and software quality requirements and evaluation (SQuaRE) -- Measurement of quality in use »
· ISO/IEC 25023:2016 « Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- Measurement of system and software product quality »
En restant sur ISO, on peut souligner que la norme « ISO/IEC 19086 - Information technology -- Cloud computing -- Service level agreement (SLA) framework and technology » est en cours de développement et aidera beaucoup dans l’identification et la définition des métriques au sein d’un système cloud.
Pour aller plus loin dans le sujet, on pourrait étendre la recherche au PaaS. Étant donnée la complexité quant à la définition du SLA afin de savoir comment se définit le PaaS pour chaque client, on introduit des facteurs supplémentaires. On verra donc sûrement apparaitre de nouvelles caractéristiques de qualité. De plus, les caractéristiques de qualité citées dans la norme ISO 25010 sont certes aussi pour des « systèmes », mais les définitions fournies ne sont peut-être pas adaptées pour les plates-formes dans le cloud (donc à adapter). Certaines caractéristiques peuvent aussi disparaître pour le modèle de qualité du PaaS. En ce qui concerne les exigences de qualité pour les
COULON Joffrey Rapport MTR891
Été 2016
26
PaaS, le domaine est extrêmement large étant donné toutes les formes que le PaaS peut prendre. On peut trouver un échantillon de types de PaaS sur la « Cloud Taxonomy » [2].
13. Conclusion
En résumé, il a été dur de trouver beaucoup d’articles pertinents pour m’aider dans cette recherche des exigences de qualité définies selon ISO/IEC 25030. Les risques se sont avérés être des obstacles surtout dans le fait qu’on parle de systèmes cloud qui ont émergé il y a juste quelques années.
Néanmoins, CLOUDQUAL est un modèle de qualité avec ses propres mesures qui sont pertinentes pour un système cloud d’un point de vue client. Cependant, on ne couvre pas l’entièreté de la qualité d’un système cloud. Cette barrière est due à la non-maturité que nous avons encore sur la définition exacte des mesures prises en compte dans un SLA. Beaucoup de fournisseurs formulent ça sous forme de clauses qu’ils s’engagent à tenir pour rester compétitifs, en particulier sur la sécurité. Beaucoup d’articles parlent de méthode d’évaluation pour donner une bonne perception au client du système cloud mais peu de mesures sont fournies et non inscrites dans un modèle de qualité. La mesure qui revient le plus souvent dans la littérature est le temps de réponse en secondes, ou millisecondes, etc. Ce temps de réponse est grandement lié aux matériels et aux « middlewares » qui supportent ce logiciel. On essaye le plus possible d’améliorer cette mesure pour une requête donnée avec des algorithmes toujours plus performants. On notera qu’on ne prend pas tout le temps compte des autres mesures de qualité comme l’optimisation des ressources utilisées par rapport aux ressources minimums nécessaires pour satisfaire les exigences de qualité. Le client veut en permanence savoir ce qu’il contrôle, ce qu’il a et où sont ses données, mais avec l’élasticité et la colocation exclusive du cloud, ceci reste assez subjectif. Le fait de faire cohabiter plusieurs utilisateurs sur une même application qui veulent des performances maximums, une fiabilité hors-norme et la meilleure des sécurités est sans doute la chose la plus difficile à accomplir pour un fournisseur.
Au final, les scénarios de qualité proposés n’ont que très peu de métriques. Ils sont assez subjectifs et le nombre de métriques est faible. Le client n’a que très peu de contrôle même si des efforts ont été faits de ce côté-là pour la gestion de l’évolution du logiciel ou de l’allocation des ressources. Les clauses de 25030 sont en partie respectées, car des métriques sont cachées au client. Pour faire le lien avec ISO 25010, nous avons la fiabilité et la sécurité qui sont exprimées le plus souvent comme des clauses de contrat SLA que le système est 100% sécuritaire et fiable. Pour la performance, on a un temps de réponse qui dépendamment des cas peut être évalué, déterminé selon une moyenne ou encore être prédit par des approches statistiques plus poussées.
COULON Joffrey Rapport MTR891
Été 2016
27
14. Annexes
14.1 Modèle de la qualité en utilisation selon ISO/IEC 25010 [7]
14.2 Modèle de qualité du produit logiciel selon ISO/IEC 25010 [7]
Figure 8 - Modèle de la qualité en utilisation selon ISO/IEC 25010 [7]
Figure 9 - Modèle de qualité du produit logiciel selon ISO/IEC 25010 [7]
[3] National Institute of Standards and Technology. NIST Cloud Computing Reference Architecture. Gaithersburg, MD: National Institute of Standards and Technology, 2011. Vols. Special Publication 500-292
[7] ISO/IEC 25010:2011 - Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models
[8] A Suite of Rules for Developing and Evaluating Software Quality Models. AL-Badareen, Anas Bassam , Desharnais, Jean Marc and Abran, Alain . Kraków, Poland : Springer, 2015. Software Measurement - 25th International Workshop on Software Measurement and 10th International Conference on Software Process and Product Measurement, IWSM-Mensura 2015. Vol. 230, pp. 1–13
[15] Quality Model for Evaluating SaaS Service, Pang Xiong Wen, Li Dong, 978-0-7695-5044-2/13, 2013, IEEE
[16] http://csmic.org
[17] Evaluation Criteria for Cloud Services, Pedro Costa, João Paulo Santos, Miguel Mira da Silva, 978-0-7695-5028-2/13, 2013 IEEE Computer Society.
COULON Joffrey Rapport MTR891
Été 2016
29
[18] User-friendly Visualization of Cloud Quality, Yvonne Thoss, Christoph Pohl, Madlain Hoffmann, Josef Spillner, Alexander Schill, 978-1-4799-5063-8/14, 2014 IEEE Computer Society.
[19] ISO 9000:2005, “Quality management systems – Fundamentals and vocabulary,” International Organization for Standardization, 2005.
[20] Towards a Monitoring Middleware for Cloud Services, Priscila Cedillo, Javier Jimenez-Gomez, Silvia Abrahao, Emilio Insfran, 2015
[21] A QoS-aware Load Balancing Policy in Multi-tenancy Environment, Hailong Sun, Tao Zhao, Yu Tang, Xudong Liu, Beihang University, Beijing, China, 2014
[22] Probability Statistics And Queuing Theory, V. Sundarapandian, PHI Learning, 2009
[23] SLA-aware Virtual Resource Management for Cloud Infrastructures, Hien Nguyen Van, Fr´ed´eric Dang Tran, Jean-Marc Menaud, supported by “Agence Nationale de la Recherche” with the ANR-08-SEGI-017, 2009.
[24] S. Becker, H. Koziolek, and R. Reussner, “The palladio component model for model-driven performance prediction,” in J. Syst. Softw., vol. 82, no. 1. New York, NY, USA: Elsevier Science Inc., Jan. 2009, pp. 3–22
[25] Model Based Control for Multi-cloud Applications, Marco Miglierina, Giovanni P. Gibilisco, Danilo Ardagna, Elisabetta Di Nitto, Politecnico di Milano, Italy, 2013.
[26] CLOUDQUAL: A Quality Model for Cloud Services, Xianrong Zheng, Student Member, IEEE, Patrick Martin, Kathryn Brohman, and Li Da Xu, Senior Member, IEEE, 2014
[27] Service Response Time Measurement Model of Service Level Agreements in Cloud Environment, Clayton Maciel Costa, Cicília Raquel Maia Leite, António Luís Sousa, 2015 IEE
[28] End-to-End Performance Prediction for Selecting Cloud Services Solutions, Raed Karim, Chen Ding, Ali Miri, Department of Computer Science, Ryerson University, 2015
[29] A QoS Guarantee Framework for Cloud Services based on Bayesian Prediction, Wei Chen, Jiming Chen, Jine Tang, Liangmin Wang, 2015
[30] Performance Analysis and Optimal Resource Usage in Finite Population Cloud Environment, V. Goswami, S. S. Patra, G. B. Mund, 2012
[31] QoS-Aware Service Recommendation for Multi-Tenant SaaS on the Cloud, Yanchun Wang1, Qiang He1 and Yun Yang, 2015.
[32] QoS-Driven Service Selection for Multi-Tenant SaaS, Qiang He, Jun Han, Yun Yang and John Grundy, Hai Jin, 2012.
COULON Joffrey Rapport MTR891
Été 2016
30
[33] Continuous Evolution of Multi-tenant SaaS Applications: A Customizable Dynamic Adaptation Approach, Fatih Gey, Dimitri Van Landuyt, and Wouter Joosen, Viviane Jonckers, 2015.
[34] A framework for the coordination of multiple autonomic managers in cloud environments, Frederico Alvares de Oliveira Jr., Rémi Sharrock, 2013.
[35] Optimizing Multi-Objective Evolutionary Algorithms to Enable Quality-Aware Software Provisioning, Donia El Kateb, François Fouquet, Johann Bourcier, Yves Le Traon, 2014.
[36] Survey of Techniques and Architectures for Designing Energy-Efficient Data Centers, Junaid Shuja, Kashif Bilal, Sajjad A. Madani, Mazliza Othman, Rajiv Ranjan, Pavan Balaji, and Samee U. Khan, 2014, IEEE.
