Mémoire M2 MIAGE SIC 2012 - Simon Joliet

UNIVERSITÉ PARIS 1 PANTHÉON – SORBONNE

MÉMOIRE DE MASTER M2

MANAGEMENT SYSTÈMES D’INFORMATION ET

DE CONNAISSANCE

&

INFORMATIQUE DES ORGANISATIONS

MIAGE

EN APPRENTISSAGE

PROMOTION 2012

« DEFINITION DE MOYENS ET DE METHODES POUR LA CONDUITE DU CHANTIER DE L’EXPLOITABILITE »

-APPLICATION DU MODELE INTENTIONNEL AU SEIN DES METHODES AGILES.

REDIGE ET SOUTENU PAR : SIMON JOLIET

DIRECTEUR DE MEMOIRE : SAMIRA SI-SAID CHERFI

MAITRE D’APPRENTISSAGE : ALAIN GOY

RAPPORTEUR ENTERPRISE : UGO JUYOU

DATE DE SOUTENANCE : 18 SEPTEMBRE 2012

Définition de moyens et de méthodes pour la conduite du chantier de l’exploitabilité

2

Simon Joliet

3

A ma famille.


4

Simon Joliet

5

1. PRÉAMBULE

1.1. Résumé

Dans l’industrie, il est régulièrement cas de systèmes d’une valeur fonctionnelle certaine, où la valeur d’usage est cependant faible due à la difficulté d’appréhension des utilisateurs. La cause est souvent imputable aux stratégies d’exploitation inadaptées, voir obsolètes. Ce mémoire se propose de définir moyens et méthodes permettant de piloter un chantier visant l’augmentation de la valeur d’usage d’un système. La matérialisation de cette plus-value s’effectue en impactant le volet de l’exploitabilité d’un système, grâce aux exigences formulées par ses utilisateurs. La méthodologie propose une solution élégante et innovante –inspirée du modèle intentionnel, intégrée dans une approche Agile. Ce processus a pu être validé de manière empirique par une mise en situation au sein de l’entreprise France Télécom. Le projet pilote a été le chantier de renouvellement des interfaces hommes-machine d’un produit de médiation pour les applications de facturation.

1.2. Mots clés

Backlog ; EKD-CMM ; Exploitabilité ; Gisement ; Macro Design ; Map ; Maquette ; MDE ; Méta-Modèle ; Méthodes Agile ; Partie Prenante ; Requirement Engineering ; Scenario Based Approach ; SCRUM ; ScrumMaster ; Spécifique ; Sprint ; UML � AJAX ; Client léger ; Framework ; IHM ; Java, J2EE, JSP ; Off The Shelf ; PHP ; RIA ; SCADA ; SNMP ; Supervision


6

Simon Joliet

7

1.3. Remerciements

Je tiens à remercier très sincèrement toutes les personnes qui, de près ou de loin, m’ont appuyé et soutenu au cours de la réalisation de ce projet ainsi que tout au long de la rédaction de ce mémoire. Mes remerciements s’adressent tout d’abord à Madame Samira Si-Said Cherfi, en qualité de Directrice de Mémoire, pour s’être montrée disponible et pour m’avoir suivi, aiguillé et conseillé tout au long de la rédaction de ce mémoire. Je souhaite de plus adresser mes remerciements à Ugo Juyou, en qualité de Chef de Projet et maître d’apprentissage de novembre 2011 à juin 2012 au sein du Skill Center Médiation Platine. Je le remercie chaleureusement pour son implication, ses conseils et la confiance qu’il m’a accordé tout au long de mon apprentissage à la Direction des Systèmes d’Information de France Télécom / Orange. J’adresse également mes remerciements à Alain Goy, en qualité de Directeur de Projet du Skill Center Médiation Platine et maître d’apprentissage de juin à septembre 2012. Je le remercie pour le support et le soutien sans faille qu’il m’a accordé lors de toutes les réunions que j’ai eu l’occasion d’organiser. Je lui sais gré de ne jamais avoir tari de nouvelles idées créatrices, contribuant ainsi majoritairement à la richesse et à la densité de ce projet. Je n’oublie pas Dominique Dejammes, en qualité d’expert technique et surtout collègue, pour m’avoir accordé beaucoup de son temps. Je tiens à le remercier pour s’être montré disponible pour m’aiguiller et pour me conseiller sur les plans conceptuels et techniques. Je le remercie de plus très chaleureusement d’avoir eu la gentillesse de relire l’intégralité de mon mémoire, me permettant d’améliorer ce dernier tant sur le fond que sur la forme. Je remercie au même titre toute l’équipe du Skill Center Médiation Platine et plus personnellement Martine Roman, Fabrice Blanchard, Serge Bergère et Geoffroy Veger. J’exprime ma gratitude à Rahima Benhamada en qualité de représentante des utilisateurs de l’équipe DECI au sein du projet. Je remercie en passant toute l’équipe de DECI pour le temps et l’implication qu’ils ont su consacrer à ce projet, ainsi que pour m’avoir accueilli si chaleureusement une journée sur leur site de l’Isle d’Abeau en Isère. Je tiens enfin à remercier tout spécialement ma sœur Marguerite, qui a eu la patience et la bienveillance de relire et de corriger ce travail dans son intégralité. Je la remercie d’avoir su mettre en lumière les rectifications s’imposant sur la forme et parfois sur le fond, me permettant de satisfaire pleinement les exigences de qualités que je m’étais fixé sur l’ensemble de ce travail. Merci à toutes et à tous.


8

Simon Joliet

9

TABLE DES MATIERES

1. PRÉAMBULE 5

1.1. RESUME ........................................................................................................................................................................ 5

1.2. MOTS CLES .................................................................................................................................................................. 5

1.3. REMERCIEMENTS ....................................................................................................................................................... 7

2. INTRODUCTION 11

2.1. AVANT-PROPOS ........................................................................................................................................................ 11

2.2. CONTEXTE DE PROJET ............................................................................................................................................ 13

2.2.1. Introduction au projet .......................................................................................................................... 13

2.2.2. Problématique ...................................................................................................................................... 13

2.3. PLAN DU MEMOIRE .................................................................................................................................................. 14

2.4. LIGNE DIRECTRICE .................................................................................................................................................. 15

3. ÉTAT DE L’ART 16

3.1. INTRODUCTION A L’ETAT DE L’ART ................................................................................................................... 16

3.1.1. Théories de la supervision ..................................................................................................................... 17

3.2. SOLUTIONS OFF THE SHELF ................................................................................................................................. 23

3.2.1. Supervision réseau ................................................................................................................................ 23

3.2.2. Supervision industrielle ........................................................................................................................ 33

3.2.3. Bilan d’exploitabilité des solutions Off The Shelf ................................................................................. 38

3.3. DEVELOPPEMENT SPECIFIQUE .............................................................................................................................. 40

3.3.1. Avant-Propos ....................................................................................................................................... 40

3.3.2. Application binaire .............................................................................................................................. 46

3.3.3. Application web .................................................................................................................................... 48

3.3.4. Bilan d’exploitabilité des solutions spécifiques ...................................................................................... 60

3.4. SYNTHESE GENERALE .............................................................................................................................................. 62

3.4.1. Comparatif des solutions Off The Shelf et Spécifique ........................................................................... 62

3.5. ARBRE DES SOLUTIONS DE L’ETAT DE L’ART ..................................................................................................... 64

3.6. CONCLUSION DE L’ETAT DE L’ART ...................................................................................................................... 65

4. MÉTHODOLOGIE 66

4.1. APPROCHE ................................................................................................................................................................. 66

4.1.1. Constitution d’une méthodologie ......................................................................................................... 67

4.1.2. Modèle de processus .............................................................................................................................. 69

4.1.3. Approche Top-Down ............................................................................................................................ 71

4.1.4. Approche Bottom-Up............................................................................................................................ 72

4.1.5. Déterminer la meilleure approche de collecte ........................................................................................ 73

4.1.6. Aspect itératif de l’opérationnalisation ................................................................................................. 74

4.1.7. Extension de SCRUM à la méthodologie ............................................................................................. 74

4.1.8. Implication des parties prenantes ......................................................................................................... 76

4.2. EXIGENCES ................................................................................................................................................................ 77

4.2.1. Modèle des exigences ............................................................................................................................. 77

4.2.2. Exigences Stratégiques (propres à l’industrie) ...................................................................................... 79

4.2.3. Exigences Fonctionnelles (propres aux métiers) .................................................................................... 80

4.2.4. Exigences Opérationnelles (propres au système) ................................................................................... 81


10

4.2.5. Recueil des exigences ............................................................................................................................. 81

4.3. SCENARIO .................................................................................................................................................................. 84

4.3.1. Théorie sur les scénarios ........................................................................................................................ 84

4.3.2. Modèles de scénarios ............................................................................................................................. 85

4.3.3. Processus de rédaction du scénario ........................................................................................................ 86

4.3.4. Macro-design ........................................................................................................................................ 87

4.3.5. Maquette .............................................................................................................................................. 87

4.3.6. Macro-validation du scénario par les parties prenantes ....................................................................... 87

4.4. MACRO DEVELOPPEMENT .................................................................................................................................... 88

4.4.1. Modèle du Macro Développement ........................................................................................................ 88

4.4.2. Processus de Macro-Développement ..................................................................................................... 89

4.4.3. Macro-validation de la brique applicative ........................................................................................... 89

4.5. PROTOTYPAGE ......................................................................................................................................................... 90

4.6. INDUSTRIALISATION ............................................................................................................................................... 91

4.6.1. Modèles de l’industrialisation .............................................................................................................. 91

4.7. NOUVELLES EXIGENCES OPERATIONNELLES .................................................................................................... 92

5. ÉVALUATION ET CONCLUSION 93

5.1. ÉVALUATION EMPIRIQUE ...................................................................................................................................... 93

5.2. ÉVALUATION PAR LES PARTIES PRENANTES ...................................................................................................... 95

5.3. BILAN ET PERSPECTIVES ....................................................................................................................................... 100

5.4. CONCLUSION ......................................................................................................................................................... 102

6. ANNEXES 104

6.1. REFLEXIONS SUR LA COUCHE TRANSACTIONNELLE .................................................................................... 104

6.1.1. Redéfinition de la couche transactionnelle ......................................................................................... 106

6.1.2. Conservation en l’état de la couche transactionnelle .......................................................................... 107

6.1.3. Conclusion des réflexions sur la couche transactionnelle .................................................................... 107

6.2. REFLEXIONS SUR LA MISE EN PLACE DE MAQUETTES .................................................................................... 108

6.2.1. Interface actuelle ................................................................................................................................. 108

6.2.2. Interface projetée ................................................................................................................................. 109

6.3. REFLEXIONS SUR LE MODELE DE DONNEES ..................................................................................................... 113

6.4. META MODELE GLOBAL DES ENTITES ET DES METHODES DE PROJET ....................................................... 115

6.5. CARTE MENTALE GLOBALE DU PROJET ........................................................................................................... 116

6.6. EXTRAIT DU GISEMENT D’EXIGENCES .............................................................................................................. 117

6.7. IHM HISTORIQUE DE L’APPLICATION PLATINE ............................................................................................ 119

6.8. EXEMPLE DE MAQUETTE FIL DE FER .................................................................................................................. 120

6.9. EXEMPLE DE MAQUETTE ERGONOMIQUE ....................................................................................................... 121

6.10. EXEMPLE D’INTERFACE HOMME MACHINE PROTOTYPEE ......................................................................... 122

6.11. REGLES DES REUNIONS AGILES ........................................................................................................................... 123

6.12. REUNION AGILE TYPE ........................................................................................................................................... 123

6.13. QUESTIONNAIRE D’EVALUATION PARTIES PRENANTES ............................................................................. 126

7. RÉFÉRENCES 129

7.1. INDEX DES FIGURES ............................................................................................................................................... 129

7.2. INDEX DES TABLEAUX ........................................................................................................................................... 130

7.3. BIBLIOGRAPHIE ...................................................................................................................................................... 131

7.4. WEBOGRAPHIE ....................................................................................................................................................... 133

7.5. GLOSSAIRE ............................................................................................................................................................... 134

Simon Joliet

11

2. INTRODUCTION

2.1. Avant-propos

Le monde des systèmes d’information est en constante évolution. Cela est dû au fait que

ceux-ci, utilisés comme supports aux activités métiers, doivent sans cesse se réadapter à de

nouvelles données business, tout en étant vecteurs d’innovation. Ce principe est aujourd’hui

largement présent au sein des directions des systèmes d’information sous le terme

d’alignement.

Plusieurs méthodes sont alors apparues pour apporter de nouveaux cycles de

développements, voulus plus rapides, plus proches des utilisateurs et de leurs

préoccupations, mettant en avant le principe de création de valeur. C’est une des bases

fondamentales des méthodes Agiles ou encore l’ingénierie des exigences. Ces deux

approches phares ont en commun l’implication des parties prenantes au sein des projets.

Il existe un grand nombre de méthodes intervenant à différents niveaux de l’ingénierie de

projet et exploitant des concepts souvent transverses, parfois propres à l’approche. Bien

évidemment, la mise en place d’un chantier, de son démarrage jusqu'à sa concrétisation,

utilisera plusieurs approches offrant des visions différentes d’un problème similaire mais

évoluant à mesure de l’avancement d’un projet. Ces visions différentes utilisent presque

toujours des considérations et des facettes similaires. Dans un projet majeur, il est

extrêmement important de prendre en compte un maximum d’informations utiles, propre

aux projets, à l’environnement et aux métiers, sans pour autant surcharger inutilement le

processus du projet lui-même.

Deux approches offrent des éléments de réponses. La première est la construction d’une

méthode spécifique à base de composants (Ralyté J., Rolland C., 2001). La seconde et

l’ingénierie dirigée par les modèles nommée MDE1 (Model Driven Engineering). Cette

démarche consiste à utiliser des outils permettant la méta-modélisation d’un aspect de la

réalité afin d’atteindre un objectif. Les outils de la MDE permettent d’articuler des modèles

au sein de procédures, afin de réaliser un méta-programme. Il est proposé de marier ces deux

concepts afin de créer une méta-méthodologie, répondant aux besoins spécifiques d’un

chantier particulier.


12

Les avantages de l’approche MDE sont multiples. La réutilisation est assurée par la

dimension haut-niveau de l’approche. Il a été convenu de la mettre en place pour un projet

de conduite du changement, au sein d’un chantier d’amélioration de l’exploitabilité d’un SI

de médiation pour la facturation, au sein de l’entreprise France Télécom/Orange.

La justification d’une telle approche, spécifiquement pour un aspect d’un chantier, a plusieurs motivations. Tout d’abord, les exigences très nombreuses des parties prenantes aux profils variés. Ensuite, la nécessité impérative d’introduire les parties prenantes dans des cycles de développement itératifs. Enfin, la nécessité de livrer un prototype, soit une opérationnalisation préalable à l’industrialisation.

Simon Joliet

13

2.2. Contexte de projet

2.2.1. Introduction au projet

Le projet pour lequel cette méthodologie sera mise en place porte sur la redéfinition de la

supervision d’un produit de médiation pour la facturation, dans le domaine des télécoms. Le

produit réalise la traduction des informations du monde de l’utilisateur, vers le reste du SI

de facturation mais aussi les bases de données d’archivage légales ou encore les

DataWarehouses marketing et analytiques.

Le chantier ne se limite pas à la couche de présentation. Il s’agit aussi de trouver de nouvelles

stratégies de supervision en partant d’un système existant. La supervision de ce produit est

complexe, il serait nécessaire de simplifier cette dernière en trouvant de nouvelles façons de

superviser l’existant, tout en conservant la supervision actuelle.

La méthode ainsi réalisée permettrait de conduire tout chantier portant sur la conduite d’un

projet d’exploitabilité d’un système, nécessitant d’impliquer au maximum les parties

prenantes et débouchant sur des livraisons régulières de prototypes, puis la mise en place du

système cible.

2.2.2. Problématique

La problématique retenue est donc « La définition de moyens et de méthodes pour la

conduite du chantier de l’exploitabilité ». Ce type de chantier consiste à partir d’un système

possédant déjà une valeur fonctionnelle, mais où la valeur globale est affaiblie par la valeur

d’usage. Cela peut-être dû à un défaut d’alignement de la couche d’exploitation du système,

résultant par exemple de l’utilisation d’une technologie obsolète, ou simplement de la

pauvreté des interactions proposées aux utilisateurs. Le cœur métier du système sur lequel la

méthode s’appliquerait est supposé être conservé en l’état, ce qui ne serait pas le cas des

couches de transport et de présentation.

Cela signifie donc qu’il est nécessaire de déterminer les technologies permettant de

supporter le chantier et l’architecture à mettre en place par rapport à la technologie retenue.

Les méthodes formelles permettent de diriger et d’orienter efficacement un projet et sur ce

point, l’implication des parties prenantes est absolument déterminante. Ce mémoire

propose donc d’identifier et d’expliciter les moyens et les méthodes nécessaires à la

résolution de cette problématique d’entreprise.


14

2.3. Plan du mémoire

Ce mémoire sera divisé donc en deux parties ; « Moyens » et « Méthode ». La première

partie permet d’identifier les meilleures solutions applicables à la couche technique et

l’architecture associée. Ces solutions seront proposées à la suite d’une étude de l’état de l’art.

La seconde partie, constituant le cœur du travail présenté, proposera une méthode

permettant de diriger le projet indépendamment des solutions techniques et structurelles

retenues.

Simon Joliet

15

2.4. Ligne directrice

Il est proposé ici d’analyser le contenu du mémoire dans sa capacité à répondre à la problématique initialement formulée. Cette analyse est une introspection a posteriori, basée sur l’ensemble du travail effectué tant sur le volet théorique que dans sa mise en œuvre pratique. Ainsi et dans une optique de réutilisabilité, les différentes étapes du projet seront ici traitées et les renvois aux pages s’y référant seront mentionnées.

• Constitution du gisement des exigences La première étape du chantier consiste à récolter les exigences des parties prenantes (p77). Deux approches existent pour la constitution du premier gisement d’exigences, une approche Top-Down (p71) ou une approche Bottom-Up (p72). Ces exigences s’agencent selon trois niveaux : Stratégique (p79), Fonctionnel (p80) et Opérationnel (p81).

• Identification d’une technologie Lorsque suffisamment d’exigences ont étés récoltés, il devient possible d’argumenter en faveur d’une technologie, en se basant pour cela sur l’état de l’art (pp16-65). Deux grandes familles d’ingénierie de produit sont documentées dans cette partie : l’utilisation d’un progiciel (pp23-38), ou la mise en place d’un développement spécifique (pp40-60).

• Démarche organisationnelle Une fois la technologie identifiée, la mise en œuvre du projet peut être déclenchée (pp84-92). Ce volet est opérationnalisé en mode Agiles (p74). La mise en œuvre est ainsi motivée par la concrétisation des exigences telle que spécifiée par les parties prenantes, en priorisant systématiquement la création de valeur.

• Réalisation de maquettes Afin de justifier les développements créant cette valeur ajoutée, les exigences doivent être conceptualisées en vue d’être validées par les parties prenantes (p87). Cette validation se concrétise par la présentation de maquettes (exemple p120) ou de scénarios fonctionnels, embarquant une à plusieurs exigences.

• Développement d’un prototype Les maquettes validées par les parties prenantes sont autant de développements potentiels. La somme des développements permet de construire un prototype de manière itérative (p90), (exemple p122).

• Industrialisation La dernière étape du chantier consiste à tirer les conclusions du ou des prototypes. En prenant pour base les développements réalisés puis validés par les parties prenantes, il devient possible de réaliser le système cible créant le plus de valeur à moindre coût (p91).


16

3. ÉTAT DE L’ART

3.1. Introduction à l’état de l’art

Le rôle de cet état de l’art est de déterminer les moyens techniques sur lequel le processus de

projet pourra s’appuyer. S’agissant d’un projet d’exploitabilité, il semble déjà intéressant

dans un premier temps d’observer s’il existe des progiciels permettant d’effectuer la

supervision et l’exploitation d’un système. Dans un second temps, il sera proposé de

comparer ces approches avec celle d’un développement spécifique.

Actuellement, ces deux approches techniques prédominent pour ce type de chantier :

• L’utilisation de solutions sur étagère (off the shelf2), soit des progiciels de supervision

et d’exploitation, basés sur des protocoles réseau, techniques ou industriels.

• La mise en place d’un développement spécifique pour une application basée sur des

technologies et des Framework3 de développement.

C’est un constat tiré par Sadovykh (Sadovykh A., 2005), qui propose un cadre de

classification aux solutions de supervision et d’exploitation. Selon lui, quelle que soit la

technologie utilisée, ces solutions doivent respecter les six points suivants :

• L’interopérabilité, le fait que plusieurs systèmes, qu'ils soient identiques ou

radicalement différents, puissent communiquer sans ambiguïté,

• La portabilité, ou la capacité d'être utilisées sous différents systèmes et plateformes,

• La flexibilité de l’application dans son intégration et dans son fonctionnement,

• Le support d’agents intelligents pour des solutions élaborées,

• La facilité de développement et d’intégration des composants de supervision,

• La facilité d’utilisation de l’outil à tous les niveaux pour les parties prenantes.

Nous utiliserons ces six éléments comme métriques de notre cadre de classification de la

pertinence des solutions de supervision étudiées, qu’elles soient sur étagère ou développées

spécifiquement pour le besoin.

Simon Joliet

17

3.1.1. Théories de la supervision

Pour le chantier, comme le cœur fonctionnel du système n’est pas impacté, la priorité est clairement mise sur la remontée d’informations, donc de la supervision du système, puis de son exploitation. Avant de mettre en comparaison des solutions dédiées à la supervision, il semble pertinent de prendre du recul sur ce qu’est la supervision. La supervision n’est pas vue par Hernández (Hernández H. R., 2006) comme un simple

outil de surveillance. Elle doit aussi permettre le diagnostic, et faciliter l’aide à la décision.

Son rôle consiste à permettre la gestion et la surveillance de l’exécution d’une opération ou

d’un travail accompli par l’homme, par une machine ou par un processus technique, puis à

proposer des actions correctives si besoin est.

Pour Sadovykh (ibid.), la supervision est une fonction de surveillance et de gestion de tous

les aspects opérationnels d’un système complexe. Elle inclut la disponibilité des applications,

les systèmes d’exploitation, les équipements réseaux, les flux de données, le stockage de

données, les activités des utilisateurs, les droits d’accès, etc.

Figure 3-1 : Synoptique des trois sous ensemble inhérents à la supervision

• La surveillance :

C’est une opération de recueil en continu des signaux et commandes d’un processus

afin de reconstituer l’état du fonctionnement réel. Ainsi, la surveillance utilise les

données provenant du système pour représenter l’état de fonctionnement, puis en

détecter les évolutions. Les informations retransmises par la surveillance viennent

alimenter le module de diagnostic.

• Le diagnostic :

Cette étape permet d’identifier la cause des évolutions. Elle alimente le module

d’aide à la décision.

• L’aide à la décision :

Elle doit permettre à un décideur d’analyser un défaut, ou une situation et à lui

proposer des solutions associées. Elle peut s’appuyer sur une base de connaissances


18

hiérarchisées, générée par des critères logiques ou découvertes après une phase

d’apprentissage. Ce dernier peut alors proposer des actions correctives.

3.1.1.1. Les alarmes

Pour Hernández (ibid.), les alarmes sont les symptômes d’un comportement anormal du

système afin de faciliter sa supervision. Une alarme est d’une manière générale observée

lorsqu’une variable prend au cours du fonctionnement du système, une valeur considérée

comme étant « anormale ».

L’auteur distingue trois déclencheurs distincts d’alarmes par rapport à l’observation d’un

variable :

• Une variable prend une valeur non prévue dans un fonctionnement « normal » ;

elle est supérieure ou inférieure à un seuil prédéfini,

• Une variable reste dans les tolérances, mais varie brusquement. Ce n’est pas la

variable mais la dérivée de celle-ci qui dépasse la tolérance,

• Une variable reste dans les tolérances, mais ne respecte pas une corrélation avec une

autre, ou ne respecte pas un pattern prédéfini.

Dans le cas de l’étude de Hernández (ibid.), le contexte fait que les défaillances doivent être

anticipées (prédiction de la non-potabilité de l’eau). Cela permet de détecter les besoins de

maintenance et offre un support d’aide à la décision. Il est pour cela primordial de disposer

d’un grand nombre d’informations sur le système que l’on étudie.

Concernant les méthodes de diagnostic, il existe deux grandes familles : les méthodes à base

de modèles et celles à base de données historiées.

Simon Joliet

19

Figure 3-2 : Arbre des méthodes de diagnostic

3.1.1.2. La maintenance

Hernández (ibid.) estime qu’une supervision a toujours un but sous-jacent de maintenance.

Le simple fait de superviser un système implique par extension que celui-ci peut être en

situation de défaillance. On peut en conclure que la supervision ne permet pas de s’assurer

que le système fonctionne, mais plutôt que celui-ci n’est pas en défaut.

Figure 3-3 : Diagramme de flux, problématique de la maintenance


20

• La maintenance corrective

La maintenance corrective est l’action de maintenance la plus visible. Cette étape

implique qu’un élément est défectueux, donc qu’il faut le réparer. Ainsi rien n’est prévu

lorsque l’élément fonctionne correctement. La supervision doit pouvoir être capable de

transmettre un diagnostic pertinent afin de pouvoir déterminer l’action à entreprendre :

• La maintenance palliative

Intervention à caractère provisoire, ou risque accepté.

• La maintenance curative

Réalisation de toutes les étapes nécessaires afin de rendre d’une part, le système de

nouveau opérationnel et d’autre part, d’éviter les prochaines occurrences de cette

panne (à moins encore une fois que le risque soit accepté).

• La maintenance préventive

La maintenance préventive est l’ensemble des opérations dont le but est d’augmenter la

fiabilité d’un système et de ses processus. Pour cela, un contrôle fréquent des données

d’exploitation est nécessaire afin de s’assurer du bon fonctionnement du système, et

d’anticiper les problèmes potentiels. On distingue trois types de maintenance

préventive :

• La maintenance systémique

Les interventions sont placées à des échéances fixes en prenant en compte les

phénomènes d’usure.

• La maintenance conditionnelle

Identique à la maintenance systémique, c'est-à-dire basée sur un échéancier, mais

l’étape de maintenance n’est lancée que si une dégradation est constatée.

• La maintenance prédictive

Dans ce dernier cas, le suivi du système est continu. L’analyse des situations passées

permet de prévoir les défaillances futures. Cette maintenance est la plus à même

d’offrir un haut niveau de disponibilité. Plusieurs stratégies de maintenance

prédictive sont envisageables (modèles prédéfinis, apprentissage…).

Toujours selon Hernández (ibid.), la maintenance doit être continue sur le système. Ce

n’est pas parce que le système n’est pas en situation de défaillance qu’il ne nécessite pas de

maintenance, bien au contraire. La maintenance préventive doit être une composante de la

supervision ; c’est le but d’une maintenance prédictive que l’auteur a mis en place par un

système d’apprentissage à base de réseaux neuronaux, couplée à une ACP4 (Analyse en

Simon Joliet

21

Composante Principale). Cela permet selon lui de passer d’une maintenance curative à une

maintenance prédictive.

En réalité, la meilleure façon d’assurer la haute disponibilité du système passe par :

Point à améliorer Moyen

Maintenance corrective Mise en place d’un outil de diagnostic pertinent et efficace

Maintenance prédictive Analyse continu de la production, analyse des résultats passés

Tableau 3-1 : Axe d’amélioration, maintenance corrective et prédictive

Pour notre besoin, il est difficile de mettre en place une maintenance prédictive. Un système

informatique ne possède pas de notion d’usure, il est rarement possible d’anticiper les

pannes qui ne sont pas clairement récurrentes. Mais cela pourrait être le cas de certaines

briques techniques et à ce titre, une telle réflexion semblerait être pertinente.

3.1.1.3. La représentation de l’information

La représentation de l’information est un point très important pour notre chantier ;

Hernández (ibid.) en parle assez succinctement. Dans son cas, les seuls modes de

représentation sont des histogrammes simples. L’étude de Hurter (Hurter C., 2011) va

quant à elle beaucoup plus loin puisque la représentation de l’information représente

l’essence même de sa thèse. L’auteur y dresse d’ailleurs un état de l’art très complet.

Ses travaux consistent à trouver les manières les plus pertinentes de représenter une

information dans un domaine (le contrôle aérien) où une mauvaise interprétation de

l’information peut avoir des conséquences dramatiques.

Il existe historiquement trois grands domaines de représentation des données :

• La cartographie, premier champ d’application par le biais notable des SIG (SI

Géographiques),

• Les visualisations scientifiques (SciVis),

• La représentation de l’information (InfoVis).

Le domaine de l’InfoVis a une dizaine d’années d’existence. Son but est la représentation de

données de façon abstraite sans référentiel dans notre environnement naturel, mais en

utilisant notre système perceptif comme vecteur d’amplification de la cognition.


22

3.1.1.4. Théorie des formes, ergonomie et affordance

Le fondement de l’étude de Hurter (ibid.) est la recherche d’une représentation

correctement interprétable en un minimum d’efforts. Il se base pour cela sur les travaux de

Tufte, Bertin, Kofka, Tukey, Cleveland, Treisman et McGill en matière de représentation

de l’information.

Mais c’est la théorie de Kofta qui est la plus citée par la suite, notamment par le biais de la

théorie des formes, plus connue sous le nom de « loi de Gestalt ». Cette loi regroupe entre-

autre les règles de base de l’ergonomie des systèmes tels que la loi de la bonne forme, de la

continuité, de la proximité, de la similitude, du destin commun, de la clôture, etc.

Ajoutée à cela l’affordance5, qui est une théorie constituant une très bonne base pour le

développement d’interfaces homme-machine. L’affordance est la capacité d’un objet à

suggérer sa propre utilisation. Ce concept est très employé –notamment, dans le design et

les interfaces homme-machine actuelles.

Simon Joliet

23

3.2. Solutions Off The Shelf

Dans un premier temps, il convient de recenser les solutions sur étagère permettant

d’effectuer de la supervision. Il existe deux grandes familles de supervision :

• La supervision réseau, basée entre autre sur les protocoles SNMP6 et ICMP7,

• La supervision industrielle, basée sur une multitude de protocoles techniques

(SCADA8).

3.2.1. Supervision réseau

Le paysage actuel est constitué d’un très grand nombre de solutions adaptées au monitoring

de systèmes d’informations complexes, par le biais notamment de la technologie SNMP

(Simple Network Monitoring Protocol). Utiliser ce protocole pour transmettre des

informations de contrôle d’exploitation est un enjeu à terme pour le chantier. Mais

l’utilisation de cette technologie pourrait aussi bien être un atout pour faire transiter tous

types d’informations, puis d’observer ces dernières via un logiciel de monitoring réseau clé

en main. C’est l’une des hypothèses de cet état de l’art.

3.2.1.1. Les progiciels de supervision réseau

Deux grands standards permettent actuellement d’effectuer une supervision des réseaux :

ICMP et SNMP. ICMP est orienté technique alors que SNMP est plutôt orienté

fonctionnel ; ce standard est donc plus adapté aux problématiques du chantier de

l’exploitabilité.

De nombreux produits exploitent cette technologie. Il est à noter qu’une grande partie de

ces outils sont open-source (GNU9 GPL10, …).

Exemple : RRDTool, Cacti (Oudot C., 2005), OPenNMS, MRTG, Vigilo, Nagios

(Imanache D. et al, 2004), Icinga, Shinken, Centreon, Zabbix (Temple C., 2004),

Eyesofnetwork, Unicenter, TNG, HP Openview NMMi (Vilemaitis M., 2011), Pandora

FMS, IBM Tivoli, NetCrunch, SUNNetManager…

<www.monitoring-fr.org>


24

Voici la description de cinq outils de supervision correspondant le plus à notre besoin, en

termes de communauté d’utilisateurs, de modularité, d’ergonomie et de représentation de

l’information :

3.2.1.2. Nagios

Nagios permet de superviser les machines et les services d’un réseau en utilisant des plugins

indépendants. Ces plugins sont majoritairement des scripts exécutables. Le comportement

de Nagios est renseigné dans des fichiers de configuration plats. Nagios est l'utilitaire gratuit

le plus utilisé dans le monde de la supervision.

Les informations sont remontées grâce au plugin Snmptrapd. Ce dernier est chargé de

récupérer les traps SNMP sur un réseau. Il se configure via le fichier snmptrapd.conf. Nagios

fonctionne en deux modes :

• le mode polling (il interroge les équipements),

• le mode passif (il attend les requêtes clients).

Le mode polling surcharge plus le réseau, mais offre une meilleure vision QoS11 que le mode

passif.

Nagios peut alerter les administrateurs par mail ou par SMS12. Toute la configuration passe

par des fichiers textes. Celle-ci est, selon Imanache (Imanache D. et al, 2004), l’auteur d’un

guide assez exhaustif sur la solution, relativement longue si l’on souhaite gérer plusieurs

centaines de machines. Il existe un très grand nombre de fichiers, ce qui peut être

rapidement problématique. C’est un point que Centreon se propose par exemple de corriger

(voir le chapitre consacré à Centreon en page 25). Il est somme toute nécessaire d’affiner

cette configuration pour ne conserver que les informations indispensables à superviser.

D’après Imanache (ibid.), il est possible de superviser quasiment tous les systèmes avec

Nagios, ce qui nécessite recherche, développement et surtout temps. Nagios est la base de

nombreux autres logiciels de supervision réseau, qui bénéficient très souvent de plugins,

ceux-ci étant souvent compatibles avec Nagios.

Avantages Inconvénients

La solution la plus utilisée (Amazon, BMW, Google, T-Mobile, Siemens) Richesse des plugins Permet de développer ses propres plugins Très orientée alarme

Interface complexe et pas très intuitive Configuration fastidieuse, nombre important de fichiers de configuration Configuration de bout en bout Un seul développeur sur toute la solution

Simon Joliet

25

Tableau 3-2 : Avantages et inconvénients de la solution Nagios

<http://www.nagios.org/>

3.2.1.3. Zabbix

Zabbix est un logiciel permettant de superviser les éléments physiques (mémoire, CPU13,

disques, ...), les services réseaux (SMTP, HTTP14, ...) ou les applications sur serveurs et

postes clients. Globalement, son comportement général est très proche de Nagios bien que

son fonctionnement technique soit assez différent. Tout comme Nagios, Zabbix ne se limite

pas au SNMP et peut récupérer des informations via des scripts locaux ou distants.

Il peut donc superviser de trois manières :

• soit par un processus lancé sur chaque machines qui collecte les données en local,

• soit par une vérification externe (seuls les services réseaux peuvent dans ce cas être

testés),

• soit par SNMP (il peut aussi superviser un équipement tel qu'un commutateur ou

un routeur qui supportant SNMP).

Contrairement à Nagios, Zabbix est un tout-en-un et ne dispose pas de plugins.

(Temple C., 2004)


Supporté par tout une entreprise et non un seul développeur Facilité de prise en main des tableaux de bord Richesse des sondes et tests possibles Supervision de ressources hétérogènes Génération de rapports

Modularité limité faute de plugins tiers Documentation un peu inférieure à Nagios Produit auto-suffisant (tout-en-un) et donc relativement peu flexible

Tableau 3-3 : Avantages et inconvénients de la solution Zabbix

<http://www.zabbix.com/>

3.2.1.4. Centreon

Centreon est un utilitaire qui vient se placer en front end15 à Nagios. C'est un logiciel libre

sous licence GPL. Centreon est un programme modulaire qui se compose de trois parties :

• Le moteur de l'application qui vient ordonnancer les tâches de supervision,


26

• L'interface web, qui permet d'avoir une vue d'ensemble du système d'information et

des différentes anomalies,

• Les plugins, soit une centaine de mini programmes que l'on peut compléter en

fonction des besoins de chacun pour superviser chaque service ou ressource disponible

sur l'ensemble des ordinateurs et autres éléments réseaux du SI.

Centreon est un moteur de services. Un service est une association plugin-machine. Ces

plugins peuvent être par exemple des scripts allant tester une fonction, ou devant récupérer

une donnée via SNMP. Il peut encore une fois s’agir de scripts distants. Ces services peuvent

avoir des valeurs de seuils, déclenchant par exemple une alarme dès que la valeur retournée

par un module dépasse une valeur prédéfinie. De là il est possible de planifier des opérations

spécifiques. La première alerte envoie un email, la seconde alerte un SMS, etc ...

La solution proposée par Centreon offre donc les mêmes fonctionnalités que Nagios, le tout

via une interface plus conviviale, avec une installation simplifiée et une meilleure ergonomie

générale. La prise en main et la configuration est grandement facilitée par rapport à Nagios.

Pour mémoire, la configuration de Nagios se fait par fichiers plats et n’est pas

particulièrement aisée d’un premier abord.

Centreon encapsule aussi le progiciel Cacti. Cacti est une solution de supervision réseau

basée sur l’outil RRDTool. Globalement, c’est une application permettant de générer

facilement des graphiques à partir de données SNMP.


Basé sur Nagios (héritage des plugins) Très modulaire Très intuitif Bonne ergonomie générale

Modules parfois propriétaires Produit tout-en-un Fonctionnement plus complexe

Tableau 3-4 : Avantages et inconvénients de la solution Centreon

<http://www.centreon.com/>

3.2.1.5. OpenNMS

OpenNMS est un outil de supervision réseau développé en Java, s’appuyant sur le serveur

applicatif Jetty et sur une base de données PostgreSQL. OpenNMS est une application

offrant des fonctionnalités très standards en termes de supervision. Son principal avantage

est en fait son cœur applicatif Java, lui conférant de fait une modularité bien supérieure aux

autres solutions.

Simon Joliet

27


Très performant

Basé sur Java et supporte PostgreSQL

Simple et intuitif

Documentation peu structurée

Cœur d’application complexe

Nécessite des compétences Java très

pointues pour le paramétrage (modification

directe du code source)

Tableau 3-5 : Avantages et inconvénients de la solution OpenNMS

<http://www.opennms.org>

3.2.1.6. HP Openview NMMi

HP Openview NMMi est une solution de monitoring réseau propriétaire permettant

d’effectuer une supervision autonome, pouvant être fortement intégrée à l’infrastructure

technique telle que les serveurs, les applications, mais aussi les utilisateurs.

Hewlett Packard démarque son produit des autres solutions en le présentant avant tout

comme un outil de gestion au niveau entreprise et non comme un simple élément de

monitoring. De la vision d’Openview, le réseau n’est qu’une partie de la chaîne supervisée

entre l’infrastructure technique et l’utilisateur en bout de chaîne.

L’utilisation du produit dépend ainsi du contexte ; il peut être utilisé comme un outil de

monitoring réseau standard, ou comme un outil décisionnel par le biais de tableaux de

bords. Cette spécificité et le coût de licence non négligeable de cette solution la réserve à des

systèmes d’une taille conséquente.

Comme les autres produits, HP Openview NMMi permet d’effectuer une découverte en

temps réel du réseau.

(Vilemaitis M., 2011)


Solution globale et éprouvée

Périmètres techniques et fonctionnels très

étendus.

Supports techniques, SLA16…

Coût d’acquisition et de support

Développement additionnel restreint et

coûteux

Plutôt adapté aux très gros réseaux

Tableau 3-6 : Avantages et inconvénients de la solution Openview NMMi

<http://www8.hp.com/us/en/software/software-product.html?compURI=tcm:245-936950>


28

3.2.1.7. Synthèse des solutions de supervision réseau

Voici une liste des points d’appréciation des différentes solutions disponibles actuellement.

a) Licence Il ressort deux types de solutions, les libres sous licence GNU/GPL et les solutions

propriétaires. Historiquement dans le domaine de la supervision, les solutions propriétaires

étaient les plus suivies et les plus flexibles. Ce n’est plus vraiment le cas aujourd’hui où les

solutions libres sont majoritairement employées et supportées.

b) Taille de la communauté La taille de la communauté est définie selon plusieurs facteurs. La communauté open-source

est par expérience plus active que la communauté d’utilisateurs de solutions propriétaires.

Le critère est ensuite évalué en se basant sur les forums, la facilité de la recherche

d’information, les sites utilisateurs dédiés à des solutions et la réactivité de la communauté.

c) Prise en main La prise en main se base en partie sur les retours des utilisateurs sur les sites spécialisés, et de

nombreux comparatifs accessibles sur Internet, voir des tests de solutions en ligne lorsque

des démonstrations sont proposées par les éditeurs.

d) Fréquence des mises à jour La mesure se base sur la date de sortie de la dernière version majeure, l’écartement calendaire

des versions majeures et sur la fréquence des mises à jours correctives.

e) Notoriété Ce critère constitue une appréciation des retours positifs des solutions, des ressentis

utilisateurs sur les forums, ou des conseils donnés par les utilisateurs pour des questions

relatives aux solutions.

f) Documentation La notation de l’aspect documentaire se base sur la facilité à trouver des informations sur

internet pour les solutions étudiées et sur l’existence de livres papier ou d’ebooks. Pour les

produits propriétaires, la notation est différente puisqu’il est relativement difficile de

trouver des informations techniques. Ce point se base alors sur la disponibilité

d’informations techniques sur les sites officiels des solutions.

Simon Joliet

29

Voici une liste synthétisant les principales solutions gratuites et payantes actuellement

disponibles sur le marché. Cette étude se base sur de nombreux tests, comparatifs, retours

utilisateurs, forums et tutoriels disponibles sur Internet.

Solution

Développeur / Éditeur

Version actuelle

Licence

Taille de la

communauté

Prise en main

Fréquence des mises à jour

Notoriété

Docum

entation

Cacti The Cacti Group

0.8.7i GNU GPL

Moyenne Moyenne Moyenne Moyenne Moyenne

Centreon Centreon 2.3.1 GNU GPL v2

Moyenne Facile Élevée Plutôt

importante Plutôt

importante

Eyes of network

EON 3.0 GNU GPL v2

Faible Facile Moyenne Plutôt

importante Moyenne

Icinga Icinga 1.6.1 GNU GPL v2

Moyenne Facile Élevée Bonne Moyenne

MRTG Tobi

Oetiker 2.17.2

GNU GPL

Faible Difficile Moyenne Faible Moyenne

Nagios Nagios 3.3.1 GNU GPL

Importante

Facile Élevée Importante Importante

NetCrunch AdRem Software

6.5 Propriétair

e Faible Difficile Élevée Assez faible Faible

OPenNMS The

OPenNMS Group

1.8.16 GNU GPL

Moyenne Facile Élevée Plutôt

importante Plutôt

importante

Openview NMMi

HP 9.10 Propriétair

e Moyenne Facile Élevée Importante Faible

Pandora FMS

Ártica ST 4.0 GNU GPL + EULA

Très faible Facile Élevée Assez faible Faible

RRDTool Tobi

Oetiker 1.4.5

GNU GPL

Faible Difficile Faible Moyenne Faible

Shinken Shinken 1.6 GNU AGPL17

Moyenne Facile Élevée Moyenne-faible

Moyenne

SUNNet Manager

Oracle 2.2 Propriétair

e Moyenne Difficile Élevée Importante Faible

Tivoli IBM 6.2 Propriétair

e Moyenne Difficile Élevée

Très importante

Moyenne

Unicenter TNG

Computer Associates

2.4 Propriétair

e Faible Difficile Terminée Importante Moyenne

Vigilo CS 2.0.0 GNU GPL v2

Faible Facile Faible Faible Faible

Zabbix Zabbix SIA 1.8.9 GNU GPL

Importante

Facile Élevée Importante Importante

Tableau 3-7 : Benchmark des solutions de monitoring réseau


30

3.2.1.8. Proposition d’architecture pour la supervision réseau

Ces solutions pourraient être des atouts déterminants au chantier. En effet, un effort

minimum serait dès lors porté à la présentation des données, qui serait gérée nativement par

les outils. Le volet transactionnel serait alors réalisé par un serveur SNMP associé à une

MIB18. Un effort non négligeable devra être porté au développement de ce modèle de

données car le serveur SNMP sera le point d’entrée/sortie unique de toutes les informations

et commandes du cœur de métier.

Figure 3-4 : Proposition d’architecture associée à un monitoring réseau

Les solutions tierces se composent globalement d’un serveur Web, d’un client SNMP et

d’une base de données. Le client SNMP va émettre des Traps SNMP19 afin de récupérer les

informations sur le système supervisé, puis va remplir une base de données locale. Les clients

(utilisateurs effectuant la supervision) se connectent à la solution via un navigateur web. Les

données affichées sont celles présentes en base locale. Les commandes d’exploitation sont

quant à elles envoyées directement au client SNMP et ne passent logiquement pas par la

base de données.

Dans le cas du chantier de l’exploitabilité, l’intérêt d’avoir une base de données côté solution

est très discutable car celle-ci serait potentiellement redondante, verbeuse et peu pertinente.

Or de par la conception des outils de monitoring réseau, cette base de données est

primordiale. En effet dans une supervision réseau classique, les informations supervisées ne

sont pas présentes en base, il est donc intéressant d’en conserver une copie pour observer par

exemple l’évolution d’une QoS au cours du temps. Copier les informations côté solution n’a

aucun sens dans notre chantier.

Le modèle de données ensuite doit être complètement maîtrisé afin de pouvoir exploiter la

fonction de découverte automatique dont les outils de monitoring réseau disposent bien

souvent. L’exploitabilité d’une telle fonction n’est pas garantie dans le cas d’un système

Simon Joliet

31

n’étant pas un réseau au sens physique du terme. Le modèle de données devrait dès lors

émuler une sorte de réseau virtuel afin d’exploiter proprement les outils. Ces derniers

servent en effet à superviser avant tout des réseaux informatiques (postes, serveurs, routeurs,

applications, etc.). Dans un cas d’utilisation sortant de ce périmètre, il est important de se

poser les bonnes questions quant à la pertinence de ces solutions.


32

3.2.1.9. Bilan d’exploitabilité des technologies de supervision

réseau

Voici d’une manière générale, les avantages et les inconvénients de la supervision réseau

pour le besoin du chantier :


Souvent de grandes communautés Outils paramétrables et intelligents Certains produits disposent de plugins Restitution des informations aisée

Effort de paramétrage Pertinence des outils de supervision réseau pour le besoin Nécessite presque toujours une base de données supplémentaire

Tableau 3-8 : Avantages et inconvénients des technologies de supervision réseau

Les technologies de supervision réseau possèdent des atouts importants pour notre chantier.

Il est par contre clair qu’aucune de ces solutions ne correspond exactement à notre besoin ;

celles-ci sont avant tout développées et utilisées pour superviser des réseaux physiques et des

applications techniques (plus rarement métier). Elles sont donc à destination

d’administrateurs réseaux par exemple, qui n’ont pas du tout les mêmes besoins que les

exploitants du SI.

Ces outils se concentrent majoritairement sur la disponibilité et la qualité de service offerte

par des équipements réseaux, ce au cours du temps. Cela ne représente qu’une facette des

métiers de l’exploitation du SI. Par ailleurs, l’effort de portage sous une de ces solutions de

monitoring réseau serait important et pas forcément optimal. Tout paramétrage réalisé sous

ces conditions serait spécifique à une application et donc difficilement réutilisable et

capitalisable.

Simon Joliet

33

3.2.2. Supervision industrielle

En matière de supervision industrielle, il existe une famille d’outils se retrouvant sous la

terminologie SCADA (acronyme pour Supervisory Control And Data Acquisition). Les outils

SCADA sont utilisés pour surveiller, contrôler et exploiter une infrastructure industrielle et

plus précisément des processus techniques.

Ces systèmes sont apparus dès lors qu’il a été possible de commander et de contrôler des

systèmes industriels via l’outil informatique. Ces solutions se sont développées

parallèlement à l’augmentation de la puissance de calculs des outils. La complexité et la

richesse grandissante des systèmes supervisés ont imposé la nécessité de centraliser et de

synthétiser les informations techniques et les commandes d’exploitation sur un minimum

de postes de contrôle.

Ces outils se rejoignent par la représentation très graphique des systèmes qu’ils supervisent.

Les interfaces de ces outils se doivent d’être extrêmement claires, au point que les éléments

supervisés sont parfois représentés graphiquement tels qu’ils sont dans la réalité (cuves,

vannes, tapis roulants…). Ceci est un point très positif pour le développement d’IHM à

moindre coût.

(Wiberg K., 2006) ; (Etinkaya E. K., 2001)

<www.linuxscada.com> ; <www.scadaworld.org>

Il existe un certain nombre de solutions type SCADA actuellement. Cette étude porte sur

trois d’entre eux, considérés comme étant les plus graphiques et flexibles disponibles

actuellement.

3.2.2.1. Ignition

Ignition répond aux problématiques de collecte, de centralisation, d’interopérabilité et de

visualisation de l’information. La solution est installée sur un serveur ; le déploiement est

donc quasi-instantané pour les clients. L’application est à base de Java Web Start, qui se

déploie donc par le biais d’un page Web (à l’instar du déploiement actuel de Platine). Le

client comme le serveur sont multi OS20.


34

Ignition s’appuie sur une base de données. Toutes les informations acquises sont en effet

enregistrées en base par le serveur applicatif. Les clients se connectent ensuite à cette base

pour récupérer les données collectées. Ce fonctionnement, qui se retrouve dans presque

toutes les solutions SCADA n’est pas sans poser problème en termes d’architecture. Ignition

possède une solution pour construire facilement ses IHM21 (type IDE22).

Le prix de la licence d’Ignition est par serveur. Le nombre de clients est donc illimité, pour

un coût en version standard de 9925$.

3.2.2.2. Aggregate

Aggregate est un système de visualisation et d’exploitation de processus industriels, de flux

de production, de machines et d’installations techniques. Il s'agit d'une solution multi-

utilisateurs distribuée qui fournit un contrôle de supervision centralisé.

A l’instar d’Ignition, Aggregate est un produit permettant d’effectuer l’acquisition et le

traitement de données d’équipements industriels. Le système crée ensuite des interfaces

homme-machines associées afin d’afficher en temps réel, d’alerter ou de piloter un processus.

Aggregate supporte un grand nombre de protocoles industriels : OLE23 for Process Control

(OPC), Modbus (TCP24, UDP25, série RTU/ASCII26/BIN27), BACnet IP28, et plus

intéressant encore, SNMP. Le spectre d’un produit comme Aggregate est donc bien plus

large qu’une solution de monitoring réseau classique.

La solution possède aussi son constructeur d’IHM simplifiées, tout comme Ignition. Les

objets graphiques sont moins nombreux mais les interfaces générées sont plus soignées.

Aggregate est plus orienté pour les besoins M2M29 que ne l’est Ignition.

Le prix de la licence d’Aggregate est fonction des équipements supervisés. Pour 100

éléments, le coût est de 2400$.

3.2.2.3. Mango M2M

Mango M2M est actuellement l’outil open-source de contrôle industriel SCADA le plus

populaire. Il est comme son nom l’indique, très orienté pour des projets M2M. Mango

utilise le navigateur Web et est déployé en mode client léger (application web J2EE30) et

non en mode semi léger via des technologies Java Web Start comme c’est le cas pour

Ignition ou Aggregate. Mango M2M requiert un serveur applicatif Java Apache Tomcat

pour fonctionner.

Simon Joliet

35

Comme les autres solutions SCADA, Mango M2M va collecter les données et les afficher au

sein d’IHM à destination des opérateurs, qui peuvent à leur tour envoyer des commandes

aux éléments du processus supervisé. Mango M2M fournit une interface simple pour

superviser des données hétérogènes, simplifier la création et la configuration de flux

multiples tout en offrant la gestion en amont de l'accès des utilisateurs, des alertes, de

l'enregistrement des données et de l'automatisation des processus. Le produit est open

source.

(Juhász B., 2009)

Mango est une solution relativement exotique dans la mesure où celle-ci, contrairement à

une majorité de solutions SCADA, est libre et basée sur un serveur applicatif Java. Du reste,

même si la solution est moins riche que les deux précédentes, c’est aussi la plus flexible.


36

3.2.2.4. Synthèse des solutions de monitoring industriel

Solution

Développeur/É

diteur

Licence

Cout de licence

Technologie employés

Operation System

s

Langue

IHM Web

Archivage

Alarm

es

Tendances

Contrôle

Base de

données

Aggregate

Tibbo technology

Propriétaire

2400$ (100) Java

Linux/Unix, Win Multi Oui Oui Oui Oui Oui

Oracle,PostgreSQL

Argos SCADA

CINTAL GPL C++ Mono Oui Oui Oui Oui Oui -

EnergoSCADA

Oleg Ivanov

Propriétaire ?

C++/PHP Linux

Mono (ru) Oui Oui Oui Oui Oui -

ICSCADA

O.Automation

Propriétaire ? PHP

Linux, Win Multi Oui Oui Oui Oui Non -

Ignition

I.Automation

Propriétaire 9925$ Java

Linux, Win, Mac, Multi Oui Oui Oui Oui Oui -

IGSS IGSS Propriétaire 730 € C++ Multi Non Oui Oui Oui Oui -

Lintouch SWAC GNU

C++/Java

Linux, Win

Mono (en) Non Non Non Oui Oui -

Mango

Serotonin Software

Open-source Libre

J2EE, JS, AJAX Mono Oui Non Oui Oui Oui SQL

openSCADA

R. Savochenko GPL C Linux Multi Oui Oui Oui Oui Oui

mySQL,SQLLite

Proview

Mandator / SSAB O.

Open-source C Linux Multi Oui Oui Oui Oui Oui -

RTAP

Industrial Defender

Propriétaire ?

C/Java JS,VBA,

Linux, Unix, Win

Mono (en) Oui Oui Oui Oui Oui Oracle

Stantor Stantor GPL Libre C/PHP/JS Linux Multi Oui Oui Oui Oui Oui -

Storozh Storozh GPL C

LinuxWin Multi Non Non Non Non Oui -

SZARP D. TERM GPL

C++,SVG

Linux, Win Multi Oui Oui Oui Oui Oui -

Tableau 3-9 : Benchmark des solutions de monitoring industriel

3.2.2.5. Bilan d’exploitabilité des technologies SCADA

Simon Joliet

37

Voici d’une manière générale, les avantages et les inconvénients de la supervision SCADA

pour notre besoin :


Représentation graphique aisée Conception des IMH efficace

Coût des solutions Lourdeur des technologies employées Manque de pertinence pour le besoin Produits très riches, mais trop de fonctionnalités par rapport au besoin Architecture permissive Sécurité des données

Tableau 3-10 : Avantages et inconvénients des technologies de monitoring industriel

Les solutions de supervision industrielles sont moins nombreuses que les solutions de

monitoring réseau. Elles paraissent cependant plus adaptées au besoin d’exploitation et de

supervision que les solutions de supervision réseau. Cependant, peu d’entre elles sont

gratuites et celles qui le sont disposent généralement d’un faible suivi. La problématique de

ces solutions est encore une fois les faibles perspectives de réutilisation du code. En effet, si le

choix réalisé venait à ne plus convenir, les développements ne pourraient pas ou très peu

servir au paramétrage d’une autre solution ; en réalité il s’agit d’un problème récurrent aux

solutions sur étagère.

3.2.2.6. Proposition d’architecture pour une supervision industrielle

Les différentes solutions de monitoring industriel étudiées possèdent globalement la même

philosophie. Celles-ci diffèrent quelque peu des solutions réseau. L’argument clé de SCADA

est en effet d’offrir une réponse aux problématiques d’interopérabilité. De fait et

contrairement aux solutions de monitoring réseau qui cherchent à apporter une couche

d’abstraction entre l’architecture technique et fonctionnelle, SCADA se place au plus près

des infrastructures techniques. Et ce à tous les sens de terme : les solutions gèrent

nativement un grand nombre de protocoles industriels afin de pouvoir collecter

l’information, de l’enregistrer en base, puis de l’afficher par le biais d’interfaces graphiques.

Elles se contentent uniquement d’informations techniques (plus rarement fonctionnelles),

le tout représenté de manière très graphique.


38

Figure 3-5 : Proposition d’architecture associée à une supervision industrielle

Dans notre cas, le volet d’interopérabilité n’aurait aucun intérêt puisque cette contrainte a

déjà été résolue en amont ; d’autre part, toutes les informations sont déjà présentes en base.

Comme ces outils permettent d’extraire les informations via de multiples protocoles et au

plus près des équipements réseaux, il paraît évident que la solution la plus logique

consisterait à aller interroger directement la base de données.

Dans le cadre du chantier de l’exploitation, cette solution serait souvent impossible à

implanter au vu des contraintes d’architecture qu’elle implique. L’intérêt d’un tel choix

devient dès lors très limité, de surcroît la plupart de ces solutions sont assez coûteuses. Le

volet d’interopérabilité constitue l’argument phare de ces solutions, mais il ne serait dans

notre cas jamais exploité. Les cas d’utilisations standards de ces outils sont très éloignés de

notre besoin.

3.2.3. Bilan d’exploitabilité des solutions Off The Shelf

Les solutions sur étagère disposent de nombreux atouts. L’effort de paramétrage est du reste

une donnée très importante à prendre en compte. Les contraintes sur les besoins sont

ensuite très nombreuses et l’outil parfait n’existe pas. Le choix d’une solution off the shelf

demanderait à priori des modifications importantes du produit pour satisfaire le besoin,

modifications sur lesquelles la capitalisation serait très délicate.

Cependant le principal problème des solutions sur étagère étudiées est que celles-ci sont très

souvent déployées dans un environnement ne possédant pas d’historique d’exploitation et

de supervision mutualisée. Le fait de vouloir reproduire par l’utilisation d’un progiciel, les

comportements d’une solution historique possédant un très grand nombre de spécificités est

très complexe et très difficile à mesurer. Il existe des méthodes permettant d’analyser les

écarts des solutions sur étagère (COTS), qui pourraient avoir du sens dans le cadre d’une

analyse plus poussée de la variabilité des solutions étudiées ici (Rolland C., 1999). Quoi qu’il

en soit dans le cas d’un prototypage réalisé avec une technologie se révélant être mauvaise, le

Simon Joliet

39

développement et le paramétrage spécifique à une solution ne pourra pas ou peu être

réutilisé dans un autre contexte.


Développement minimalisé (idéalement) Librairies graphiques existantes Intégration facilitée Support fournisseur

Effort de paramétrage Réutilisation la plupart du temps limité Solutions parfois payantes Manque de pertinence des solutions pour le besoin

Tableau 3-11 : Avantages et inconvénients des solutions sur étagère


40

3.3. Développement spécifique

3.3.1. Avant-Propos

Ce deuxième choix de solution s’oppose aux produits sur étagère. Il s’agirait d’exploiter la

couche métier par une application développée spécifiquement pour le besoin. Il semble

cohérent de mesurer si un développement spécifique ne pourrait pas potentiellement

apporter une meilleure solution par rapport aux progiciels sur étagère. Il est clair qu’un tel

développement serait plus long. Mais le spécifique permet de s’approcher de la solution la

plus pertinente, tout en permettant une plus grande capitalisation sur le développement

réalisé.

Nous noterons deux grandes technologies candidates pour un développement spécifique :

l’application binaire classique (compilée ou précompilée), avec un schéma type « client

lourd31 » et l’autre, l’application web pour un schéma type « client léger32».

Contrairement aux solutions off the shelf, le fait de développer une application en interne

impose une réflexion poussée sur l’architecture applicative cible. Les choix d’architectures

doivent en réalité se poser de la même manière pour les solutions sur étagère, mais cette

étape est bien plus importante pour un développement spécifique. Dans le paysage actuel,

un découpage de type MVC33 semble être la solution la plus appropriée.

3.3.1.1. Introduction au modèle MVC

MVC est l'acronyme pour le Modèle Vue Contrôleur. C’est un modèle d’architecture utilisé

en génie logiciel, permettant de simplifier la mise en œuvre d’applications ayant besoin

d’afficher des données tout en prenant en compte les interactions des utilisateurs.

Le Modèle est la structuration des données au sein du logiciel, afin de faciliter leurs

traitements et leurs manipulations. La Vue prend en charge la représentation des données

pour l’utilisateur final. Enfin, le Contrôleur est la couche transactionnelle responsable du

traitement de l’information, en fonction des demandes de l’utilisateur. Le contrôleur extrait

les données du modèle pour les mettre à la forme spécifiée par la vue.

(Machacek et al., 2008)

Cette philosophie apparaît comme très pertinente pour notre choix d’architecture.

Simon Joliet

41

3.3.1.2. Développement d’une couche middleware

Dans le développement de notre application et d’après l’architecture définie précédemment,

nous allons avoir besoin de définir une couche d’interface entre le cœur métier et les IHM.

En fonction de l’architecture préexistante, il peut être primordial de redéfinir la couche

Middleware34. Si cette dernière n’est pas satisfaisante dans le produit. Il semble intéressant

de voir comment ce point pourrait être consolidé à terme via le chantier.

Selon Sadovykh (Sadovykh A., 2005), un Middleware de supervision est un progiciel

permettant de faire le lien entre des sources ou des moyens de supervision et des applications

utilisatrices des fonctions d’administration. Le rôle du Middleware est de cacher la

complexité de la distribution de la communication. Il fournit la base de la conception

d’agents d’exploitation et de supervision et simplifie de fait l’intégration avec des outils de

visualisation.

Sadovykh énonce 6 familles de normes permettant selon lui, de réaliser un Middleware :

Normes Technologies

Appel de procédure à distance RPC35 JRES Middleware Orienté Objet RMI, DCOM36, Corba37 Middleware de Composants CCM, EJB38 Plateforme Multi-Agents (SMA) FIPA, ICM Middleware de Messages JMS39, Message Query Webservices40 SOAP, REST41, .NET42

Tableau 3-12 : Technologies Middleware

D’après les travaux de Sadovykh, les deux technologies se prêtant le mieux à cet exercice sont

CORBA et les Webservices. Sadovyky met par la suite en opposition ces deux méthodes.

Globalement suite à sa réflexion, il avance que les Webservices sont plus intéressants dans le

cadre de composants autonomes tel que des agents de supervision. La suite de son travail a

donc consisté à développer un Middleware de supervision à base de ces Webservices (en

technologie SOAP43).

D’une manière générale et dans le cadre de notre projet, voici ce que nous pouvons conclure

sur l’utilisation d’un Middleware de supervision :


Architecture SOA44 Flexibilité optimale

Coût de développement de la couche interface et présentation Charge serveur plus importante (selon les


42

Division de la supervision en couches Nombreuses technologies envisageables Très adapté pour l’exploitation dynamique (JSON,45 AJAX46…) Possibilité de connexion à l’existant (en SOAP)

solutions)

Tableau 3-13 : Avantages et inconvénients des technologies Middleware

3.3.1.3. Choix d’une technologie de Webservices

Pour les besoins du chantier, la solution la plus pertinente en matière de Middleware est

effectivement une approche à base de Webservices. Il existe actuellement 23 familles de

Webservices : les technologies SOAP, REST et .NET. Dans le cadre d’une optimisation de

l’application, il serait cohérent d’offrir un certain nombre de services métiers, interrogeables

par le biais des IHM.

Si le choix se portait sur une application Web, une technologie semblerait particulièrement

adaptée ; il s’agirait des Webservices REST. Par rapport à la technologie SOAP, ceux-ci

offrent un grand nombre d’avantages qu’il conviendrait de prendre en considération.

L’architecture .NET est exclue d’office du comparatif de par son caractère propriétaire et

surtout, non interopérable.

a) Introduction aux Webservices

Les Webservices consistent à faire communiquer entre-eux de manière standardisée des

environnements hétérogènes et des systèmes potentiellement distants. Ils permettent un

accès à des ressources de manière identique pour n’importe quelle application ou utilisateur.

Les informations échangées sont structurées et normalisées, elles transitent au sein d’un

intranet ou sur internet par le biais du standard HTTP.

Il existe actuellement deux interprétations majeures de la notion de Webservice que sont :

SOAP et REST. D’une manière générale, ces deux méthodes utilisent le protocole HTTP, à

ceci près que SOAP encapsule des trames propriétaires au sein de l’interface POST. Le

protocole REST pour sa part exploite directement des interfaces (verbs) spécifiées par

HTTP. Nous nous concentrerons ici sur l’implantation et le fonctionnement des

Webservices REST, ses avantages et ses inconvénients.

Simon Joliet

43

b) Les Webservices REST

L’architecture REST (REpresentational State Service) est un modèle d’implantation des

Webservices interrogeable par le biais des interfaces propres au protocole HTTP. L’accès et la

modification d’une ressource se fait au moyen de l’URI47 (Uniform Ressource Identifier),

couplé à quatre méthodes classiques de l’HTTP: GET, POST, PUT et DELETE. La

structure des ressources repose souvent sur une structuration descriptive de type XML mais

d’autres formats sont possibles (texte, HTML, JSON…).

L’architecture REST est une interprétation des Webservices orientée ressource. Cela signifie

qu’au lieu d’avoir un point unique de collecte des requêtes clients redistribuant les résultats,

l’implantation REST fournie pour chaque donnée une interface interrogeable par son URI

respectif. L’élément URI est facilement compréhensible de par sa formulation simple et

retourne la ressource explicitement demandée par sa syntaxe. L’agencement des ressources

fournie ainsi une stratégie d’accès permettant à plusieurs acteurs d’accéder à plusieurs

ressources en même temps, sans goulot d’étranglement.


44

Les ressources fournies en retour d’une requête client peuvent prendre plusieurs formes :

• Une entité HTML : cela dans le but de présenter facilement des ressources et de

les hiérarchiser de manière transparente. Le référencement web est alors largement

facilité,

• Un document XML : la récupération d’un tel objet permet par exemple un

traitement ultérieur par l’application consommatrice de données (après parsing),

• Un élément JSON : cela permet d’obtenir les données d’une entité tout en

respectant la structure de l’objet relatif, directement interprétable. Très utilisé en

usage web,

• Un élément texte : directement intégrable ou transformable dans l’application

consommatrice de données.

Il apparaît que le protocole HTTP se prête parfaitement à la notion même de Webservices

telle que définie par l’implémentation REST. La structure même du World Wide Web peut

être en effet vue comme une architecture REST. HTTP comme REST embarquent tous

deux les notions suivantes :

• Ressource : entité accessible par son adresse.

• État : un état est le statut particulier d’une ressource.

• Représentation : la manière de présenter l’état d’une ressource (texte, HTML, XML,

JSON…).

• Transfert : la transition entre les états.

En fait, une requête REST n’a pas d’état : elle est dite « auto-suffisante ». Toutes les

informations nécessaires au bon déroulement de la requête sont déjà contenues dans cette

dernière. Cela a pour effet de réduire les échanges client-serveur, de limiter la bande passante

nécessaire à ce niveau et enfin de ne pas surcharger le serveur par l’ouverture et la fermeture

de sessions clientes.

Dans le cas d’un équilibrage de charge sur plusieurs machines, la requête pourra être

exécutée sur n’importe quel serveur.

Simon Joliet

45

c) Avantages et inconvénients des Webservices RESTFull


L’implantation permet un meilleur nommage des ressources accessible via l’URI,

L’utilisation des URI permet de générer des requêtes à la syntaxe humainement compréhensible,

Le protocole exploite un standard robuste, éprouvé et générique : HTTP. Cela facilite clairement l’interopérabilité,

Seulement 4 interfaces sont nécessaires pour accéder à toutes les ressources : GET, PUT, POST et DELETE,

L’implantation des Webservices REST est légère et facilement reproductible (peu de code nécessaire ; moins que SOAP),

La structure générée par l’implantation est facilement accessible et référençable,

Les ressources étant accessibles indépendamment et parallèlement, il est possible de prioriser certains traitements par rapport à d’autres, ou d’équilibrer une charge,

Le fait qu’une ressource pointe vers une URI unique permet de mettre en cache l’information côté serveur, et d’augmenter la réactivité générale,

La sécurité n’est pas la principale préoccupation de cette architecture,

L’implantation orientée donnée demande un effort supplémentaire pour une utilisation d’un point de vue métier,

Le passage d’éléments sécurisés par le biais d’une URI n’est pas idéal.

Avoir une URI par entité n’est pas toujours la meilleure approche selon l’application,

La formalisation des applications REST n’est pas encore totalement stabilisée,

L’implantation de REST n’est pas une solution à l’interopérabilité en soit, mais elle la facilite grandement,

Les quatre interfaces HTTP sont bien adaptées pour manipuler des ressources, moins lorsqu’il s’agit de concepts métiers haut-niveau,

La gestion succès/erreur est celle du protocole HTTP. Cela n’est pas toujours explicite pour une application ou un utilisateur (erreurs 4xx et 5xx par exemple),

La méthode DELETE est très peu utilisée sur le protocole HTTP en temps normal et n’est pas toujours bien implanté ou interprété par les navigateurs et autres applications,

Les données nécessaires à l’envoi d’une requête doivent être conservées pendant le déroulement de cette dernière côté client.

Tableau 3-14 : Avantages et inconvénients des Webservices Restfull


46

d) Conclusion des Webservices REST

En faisant le choix de s’implanter sur le protocole HTTP, une norme déjà solide et

cohérente, l’architecture des Webservices REST bénéficie d’atouts considérables. L’accès à

des Webservices peut en effet être réalisé très efficacement au moyen de seulement quatre

opérateurs déjà définis. Cela permet à REST d’être un protocole léger, performant et

surtout très facilement intégrable.

Cette implantation n’est cependant pas sans inconvénients. Même si l’exploitation de la

norme HTTP permet de répondre très justement à la problématique de mise à disposition

d’informations dans le but de faciliter l’interopérabilité, il n’en demeure pas moins que

l’implantation reste très orientée ressource.

3.3.2. Application binaire

Technologies candidates : Java, C/C++, …

Pour le chantier, si la mise en place d’un IHM Web est actée, REST apparaît comme étant la

solution la plus pertinente. Les applications d’exploitation historiques sont bien souvent

basées sur des technologies compilées au déploiement problématique. Ces technologies sont

actuellement dépréciées, dans la mesure où elles sont perçues comme un frein au

déploiement et à l’évolutivité du business.

Dans le projet de l’exploitabilité ces solutions offrent de nombreux désavantages. Proposer

une application compilée ne permet pas tout d’abord d’assurer une maintenabilité aisée des

solutions. Sur la problématique du déploiement, ce type d’application est bien plus

complexe à appréhender qu’une solution Web. Un cas particulier concerne les Applets Java,

dont le déploiement n’est pas réellement un problème mais où l’obsolescence est effective.

Ces solutions présentent par contre certains avantages majeurs, comme l’intégration

souvent très poussée des outils de développement via les IDE. Mais cet avantage est à

tempérer par rapport aux solutions Web qui possèdent elles-aussi des solutions de design

rapide d’IHM.

Simon Joliet

47

3.3.2.1. Proposition d’architecture associée à une application

binaire

En appliquant la philosophie MVC à un système existant et associée à une solution

spécifique binaire éventuelle, l’architecture proposée serait la suivante :

Figure 3-6 : Proposition d’architecture associée à une solution spécifique binaire

Par rapport aux solutions sur étagère, le développement spécifique offre une plus grande

liberté en termes d’architecture. Le modèle proposé n’est plus soumis aux contraintes de

solutions tierces potentiellement en conflit avec les contraintes métiers, internes ou

stratégiques. Ce gain en souplesse se perd mécaniquement en coûts d’études et de

développement.

Dans cette solution, les problèmes de redondance de l’information sont éliminés et par

rapport à l’existant, la couche contrôleur propose n Webservices, associés à toutes les entités

du cœur de métier supervisées. L’intelligence serait déportée dans les couches modèle et

contrôleur qui réaliseraient les traitements métiers entre le cœur métier et les interfaces

homme-machines (vue).

L’inconvénient de ce modèle est propre à la technologie employée ici, à savoir l’application

binaire, qui présente un certain nombre de limitations en termes de sécurité, d’architecture

et de déploiement.

3.3.2.2. Bilan d’exploitabilité des applications binaires

En résumé, une solution de supervision basée sur une application binaire spécifique n’est pas

un choix très judicieux par rapport au besoin.


48


Performance des solutions Richesse des outils de conception (IDE)

Déploiement difficile Maintenance du code complexe Développement souvent fastidieux

Tableau 3-15 : Avantage et inconvénients des applications binaires

3.3.3. Application web

Technologies candidates : PHP48, JSP49, .NET, …

La problématique de ces solutions est de développer un modèle de données permettant une

intégration performante des éléments actuels. Il est cependant nécessaire de se tourner vers

des technologies matures, proposant des Framework améliorant significativement la rapidité

de production de code ainsi que sa réutilisation. Les technologies open sources libres seront

privilégiées ce qui exclura de fait .Net de ce benchmark.

Deux technologies sont actuellement les plus en vue du Web dynamique d’entreprise, PHP

et JSP. Ces deux technologies sont d’une part extrêmement matures, mais d’autre part

disposent de Framework réputés et très performants qui feront gagner un temps certain lors

du processus de développement ?

3.3.3.1. Utilisation d’un Framework

Un Framework est un ensemble d’outils de haut niveau, permettant d’élaborer rapidement

une application en utilisant une méthode de programmation dite « orienté composant ».

Ces techniques pallient aux limitations des technologies sur lesquelles elles s’articulent, en

facilitant notamment les interactions entre l’application, les utilisateurs et les autres

systèmes (base de données, applications tierces, etc.)

3.3.3.2. Les Framework PHP

La liste des Framework PHP est longue. Généralement ces derniers proposent les mêmes

approches, à savoir une interprétation de la philosophie MVC plus ou moins poussée. Nous

ne retiendrons que deux de ces Framework, Zend et Symfony. Ces deux Framework sont les

plus riches et les plus utilisés dans l’industrie (respectivement 22% et 34% de part de marché

des Framework applicatifs Web utilisés en entreprise).

a) Zend

Simon Joliet

49

Zend Framework est développé par la société Zend, qui est l’initiateur du langage PHP. Un

grand nombre d’entreprises utilise ce Framework : Google, IBM, Microsoft, Adobe…

L’utilisation de Zend impose de comprendre la philosophie MVC. Le développement d’une

application doit suivre des étapes précises (proposition, modélisation et implémentation), ce

qui est un avantage comme un inconvénient. L’avantage est une bonne modélisation

garantissant un haut niveau de réutilisation du code et un découpage applicatif cohérent.

Zend n’est pas exempt de défauts. Le Framework est moins riche que d’autres. Certains

éléments génériques doivent parfois être réécrits. Ensuite, ce Framework ne dispose pas

d’outil de génération automatique de code.


Très documenté Orientation professionnelle Support de l’application facilitée Open-Source

Difficile à appréhender Non adapté pour les petits projets et les prototypes Performances limitées

Tableau 3-16 : Avantages et inconvénients du Framework Zend

<http://www.zend.com/fr/>

b) Symfony

Le Framework Symfony est supporté par l’agence Web française Sensio depuis 2003, et est

proposé en open source depuis 2005. L’avantage principal de la solution est la génération de

code qui lui permet de prototyper rapidement une application. Cette génération est

présente à tous les niveaux d’une application Web : vue, contrôleur, modèle, formulaire, test,

configuration…

L’idée de base de Symfony est de ne pas avoir à réécrire des briques ayant déjà été

développées par d’autres. En effet le Framework consiste à assembler divers projets, avec

leurs spécificités propres, en les liant dans une même structure de développement tout-en-

un.

C’est un Framework de choix pour industrialiser les développements et simplifier la

maintenance des projets.


50


Très documenté Orienté développement rapide Simple à installer et à configurer Apprentissage rapide Orientation Corporate Évolutif sans modifications structurelles Très nombreuses briques de base Open-Source

Installation et utilisation complexe Forte dépendance au Framework Lourdeur du Framework Performances limitées

Tableau 3-17 : Avantages et inconvénients du Framework Symfony

<http://www.symfony-project.org/>

c) Comparatif Zend/Symfony Zend Symfony

Prise en main Très bonne Bonne Installation Très facile Plutôt difficile Routing Très bon Très bon Mapping relationnel-objet Très bon Plutôt bon Mise en place de modules Très facile Facile Formulaires Très bon Très bon Frontend et backend Très bon Bon Sessions Moyen Moyen Organisation du code Très bon Très bon Interactions avec la BDD Très bon Très bon

Documentation sur les APIs Bon Bon

Outils de développement Très bon Moyen Feuilles de style CSS Très bon Très bon

Composants élaborés Très bon Très bon Tableau 3-18 : Benchmark des Framework Zend et Symfony

(Moro A., 2010)

d) Conclusion Framework PHP

Globalement, on notera une maturité plus importante du cadre proposé par Symfony. Dans

une optique de génération automatique de code et de simplicité du modèle, Symfony semble

être la meilleure approche.

3.3.3.3. Les Framework Java

Simon Joliet

51

Il existe une grande variété de Framework Java. Nous n’en retiendrons que deux, qui sont

actuellement les plus suivis, documentés et riches. Il s’agit des Framework MVC Struts et

Spring MVC. Ces deux produits sont les Framework Java les plus utilisés en entreprise.

a) Struts

Struts est un Framework J2EE libre créé par Craig McClanahan, soutenu par la fondation

Apache depuis 2000. Il utilise l’API50 Servlet Java afin d’imposer la philosophie MVC. Ce

Framework permet le développement d’applications Web en équipe, optimisant ainsi le

découpage applicatif d’une solution.

En approche Struts, une application est un ensemble d’événements et d’actions déclenchés

par les utilisateurs du système. Ces éléments sont décrits dans des fichiers XML, dans

lesquels sont renseignés les différents cheminements possibles des actions.

Struts est à privilégier pour obtenir un gain de temps sur les grosses applications de type

MVC.


Quasiment un standard de fait Intégration poussée dans les IDE Nombreuses sources d'informations

Utilisation abusive du XML Peu d'évolutions Avenir incertain Beaucoup de classes et de code à produire Architecture vieillissante (Servlets)

Tableau 3-19 : Avantages et inconvénients du Framework Struts

<http://struts.apache.org/>

b) Spring MVC

Spring MVC est un Framework open source, créée par Rod Johnson. Il a été créé pour faire

face à la complexité du développement d'applications d'entreprise. C’est un Framework à

injection de dépendances, orienté aspect. Le Framework est constitué d’un certain nombre

de modules d’intégration tels qu’ORM51, JMX52, JDBC53 ou encore DAO54.

(Ladd D., 2006)

Spring MVC est un conteneur dit « léger », car son infrastructure est similaire à celle d’un

serveur applicatif JSP. A l’instar de Struts, il prend en charge la création d’objets ainsi que la

mise en relation de ces derniers par l’intermédiaire d’un fichier de configuration.


52

Le Framework Spring MVC offre une couche d’abstraction permettant d’intégrer d’autres

Framework, notamment Struts. De fait il ne concurrence pas réellement Struts puisqu’il est

tout à fait possible d’utiliser Spring pour le découpage MVC, et Struts pour la couche de

présentation (et donc pas forcément Spring MVC).

Pour l’étude, seule l’implantation Spring MVC peut-être mise en comparaison avec Struts.

L’avantage majeur de l’utilisation de Spring MVC est surtout son intégration sans coutures

dans Spring, ainsi que son excellent support des Webservices REST.


Intégration complète dans Spring Grande maturité Niveau d’abstraction poussée Modularité très importante

Complexe à utiliser d’un premier abord

Tableau 3-20 : Avantages et inconvénients du Framework Spring MVC

<http://www.springsource.org/>

c) Comparatif Struts/Spring MVC Struts Spring MVC

Prise en main Bonne Bonne Installation Facile Moyenne Routing Très bon Très bon Mapping relationnel-objet Très bon Très bon Mise en place de modules Bon Bon Formulaires Bon Bon Frontend et backend Bon Bon Sessions Bon Très bon Organisation du code Bon Très bon Interactions avec la BDD Très bon Très bon Documentation sur les APIs Bon Bon Outils de développement Très bon Très bon Feuilles de style CSS Très bon Très bon Composants élaborés Moyen Moyen

Tableau 3-21 : Benchmark des Framework Struts et Spring MVC

d) Conclusion Framework Java

Les Framework Java offrent de très nombreux avantages, notamment en termes de richesse

d’API. Les solutions Struts et de Spring MVC se révèlent toutes deux excellentes pour

Simon Joliet

53

réaliser des applications métiers. C’est d’ailleurs à ce titre que ces dernières sont les plus

utilisés en entreprise pour ce type de besoins. Pour conclure, l’industrie tend de plus en plus

vers Spring et Spring MVC, qui se révèlent être des choix plus durables.


54

3.3.3.4. Synthèse sur les Framework

Pour conclure, voici globalement les avantages et les inconvénients de l’utilisation des

Framework :

a) Avantages des Framework

Un Framework possède de nombreux intérêts. S’il permet effectivement de simplifier les

interactions de base comme les appels à la base de données ou à des Webservices, le cœur de

l’application doit quant à lui être codé autour des outils proposés par le Framework. Le

développement d’un projet est globalement plus rapide grâce à l’utilisation d’un Framework,

c’est un fait.

Il est par contre nécessaire de respecter un certain formalisme, une architecture et des

contraintes de développement propres aux Framework. Cela peut être problématique mais

c’est pourtant la principale force de ces solutions. Il est en fait plus facile dès lors de se

concentrer sur le cœur fonctionnel d’un projet, plutôt que de résoudre des problèmes

techniques déjà résolus pour d’autres besoins. Enfin ces outils possèdent pour la plupart de

grandes communautés de développeurs et mécaniquement, les correctifs et évolutions sur

ces outils sont relativement fréquentes et efficaces

b) Inconvénients des Framework

Ces solutions ne sont cependant pas exemptes de défauts. Si un Framework oriente

l’architecture technique, il est à noter que les développements ne sont pas interopérables

entre les différents Framework. Ainsi plus un Framework dispose de fonctions avancées et de

haut niveau, plus il sera délicat de modifier le comportement technique d’une application.

Ensuite, le poids d’un Framework peut ne pas être négligeable. N’étant certes composé que

de fichiers, un Framework chargera significativement le serveur applicatif. Enfin, les mises à

jour peuvent parfois être délicates à mettre en œuvre sur un système en production, mais ce

problème est assez récurrent dans l’industrie.

Simon Joliet

55

c) Synthèse Framework


Gain de temps Maintenance facilitée Communautés réactives Solutions gratuites

Structure imposée Poids du Framework important Normes de travail à respecter Apprentissage parfois délicat Mises à jour non évidentes Sécurité des Framework

Tableau 3-22 : Avantages et inconvénients des Framework de développement Web

3.3.3.5. Comparatif des Framework PHP/J2EE

Globalement, les quatre Framework sont de très bons outils permettant tous sans exception

de réaliser une application web de manière efficace et performante. Le seul point d’écart

significatif entre ces quatre solutions est bien sûr la différence entre le langage utilisé, PHP

ou Java (JSP).

Ces deux langages sont relativement différents. Le PHP sera toujours préféré pour les

développements rapides et les sites Web dynamiques de moyenne envergure. La technologie

JSP est quant à elle privilégiée par l’industrie pour les applications métiers, les sites

marchands, les prototypes et les gros intranets sur architecture n-tiers. Voici donc un

comparatif entre ces deux technologies sur l’aspect fonctionnel :

JSP PHP

Exécution Lourde (pré-compilation) Légère (interprété) Paradigme Totalement objet Procédural et notions objet Débugger Lourd et complexe Aucun Connexion à une BDD55 Tous types (JDBC) Tous types (ODBC56)

Processus Un processus multithread Un processus par script Performance Assez performant Très performant Complexité Plutôt complexe Plutôt simple Verbosité Très verbeux Peu verbeux Portabilité Complètement portable Problèmes potentiels Scalabilité Très scalable Peu scalable Robustesse Très robuste Peu robuste Orientation Corporate Web Cout de développement Plutôt important Bon marché Communauté En deçà de PHP Nombreuse et active

Intégration technique Difficile Facile Intégration fonctionnelle Facile Difficile

Tableau 3-23 : Benchmark des technologies JSP et PHP


56

Et d’une manière plus synthétique, ce qu’il faut retenir de ces deux solutions :


PHP

Performance Simplicité Communauté Aspect technique

Orienté web « simple » Peu robuste Procédural Peu maintenable

JSP

Modèle robuste Scalabilité (extensibilité) Orienté application d’entreprise Aspect fonctionnel

Débugger lourd Rigidité Verbosité Complexité

Tableau 3-24 : Synthèse comparative des technologies JSP et PHP

3.3.3.6. Les Framework Javascript

Cette solution n’est pas à comparer avec les deux précédentes ; il s’agirait d’une brique

complémentaire permettant de gagner du temps lors du développement de l’application,

côté client. De fait, les Framework PHP ou JSP constitueraient l’application sur le serveur.

Ceux-ci réaliseraient les opérations métiers au sein des couches contrôleur et modèle. Le

Framework côté client n’effectuerait que des opérations de présentation de l’information

(graphiques, tri, optimisation d’affichage…).

De plus et dans le cadre du développement de toute application Web (PHP, JSP ou autre

technologie), il sera nécessaire de développer en Javascript ne serait-ce que pour effectuer des

contrôles de base côté client. Utiliser un Framework Javascript est, au vu de la technologie

Javascript actuelle, un argument fondamental en termes de rationalisation et d’optimisation

des coûts de développement d’une application Web.

Les Framework permettant d’effectuer des opérations complexes côtés client web sont

appelés « Rich Internet Application57 Framework ». Il en existe actuellement environ 40. Les

solutions payantes et celles utilisant des produits tiers et non interopérables sont éliminés

(Flash58, Silverligh59t, WPF60…). Le Javascript reste la seule technologie légère et complète

permettant d’effectuer des opérations avancées coté client.

Le Javascript n’est pas exempt de défaut et développer toute une application dans cette

technologie peut se révéler long, fastidieux, inefficace et non interopérable. Voici une liste

des solutions existantes, adaptées à notre besoin :

Simon Joliet

57

Nom License Format

Ample SDK MIT61, GPL Javascript AppFlower MIT License ou commercial Javascript Cappuccino LGPL Javascript, .sj Dojo Toolkit BSD62 Javascript ExtJS GPLv3 ou commercial Javascript Google Web Toolkit Apache 2 Javascript Lively Kernel MIT Javascript Qooxdoo LGPL, EPL Javascript Quick PHP Open source Javascript > PHP > Javascript Sproutcore MIT Javascript Vaadin Apache 2 Javascript

Tableau 3-25 : Liste des Framework Javascript

De ces solutions, deux sortent du lot : il s’agit de Dojo Toolkit et de Google Web Toolkit.

D’une part, ces solutions sont les plus matures, les plus utilisées et les plus suivies de tous ces

Framework. Elles disposent de nombreux outils facilitant le développement d’application et

la construction d’interfaces homme-machine.

a) Google Web Toolkit

Dernièrement, les technologies Web s’efforcent de simplifier les interactions homme

machine, notamment par le biais des applications internet riches (RIA). L'utilisation accrue

des technologies Ajax pour développer ces applications est une chose, mais il est nécessaire

de garantir la réutilisation et la maintenance de ces applications.

La réalisation de ces objectifs avec les technologies Ajax et Javascript est plutôt difficile. La

compatibilité du code sur toutes les plateformes n’est jamais vraiment garantie. Ensuite, le

développement et le débogage dans cette technologie est loin d’être une sinécure, ce qui peut

apparaître comme une perte de temps et un des derniers gros problèmes en développement

web avancé.

Le Framework GWT, lancé en mai 2006 par Google, a été développé pour répondre à ces

points. Il s'agit d'un ensemble d'outils de développement, de services ouverts et libres de

programmation et de widgets pour le développement basés sur les technologies Ajax. GWT

propose de développer les applications riches dans un environnement Java, infiniment plus

efficace que le Javascript en termes de développement, de réutilisabilité et de maîtrise du

code.


58

La compilation ne génère pas de bytecode63 Java, mais un programme Javascript optimisé,

interopérable entre les différents navigateurs Web, le tout sans couture. Le débogage n’est

pas celui du navigateur, mais celui intégré à l’environnement de développement utilisé.

L’effort a été porté par Google pour intégrer pleinement ce Framework dans l’IDE Eclipse (à

partir de la version 3.2). Le développement des interfaces homme-machine se fait via la boîte

à outil fournie par l’IDE, ce qui constitue un gain non négligeable.

(Faiz B. M., 2009)


Aucune connaissance Javascript requise

Possibilité de récupérer le code Java

Communauté très active

Code Javascript extrêmement optimisé

Perte de compétence sur le code par

compilation Java vers Javascript

Compilation très lente

Code difficile à tester

Tableau 3-26 : Avantages et inconvénients du Framework Google Web Toolkit

<https://developers.google.com/web-toolkit/>

Simon Joliet

59

b) Dojo Toolkit

Dojo Toolkit est un Framework open source modulaire basé sur une bibliothèque Javascript,

conçu pour développer rapidement des Applications Internet Riches (RIA), indépendantes

de la plateforme, sur base HTML64/CSS65, Javascript et Ajax. Il a été lancé en 2004 par Alex

Russell, Dylan Schiemann et David Schontzler entre autres. Le produit est sous licence

BSD.

En utilisant la classe graphique Dijit, Dojo propose un très grand nombre d’éléments pour

construire rapidement une interface (compteurs, histogrammes, cartes…). La création des

IHM peut se faire en code, soit avec l’outil libre Maqetta. Enfin, ce Framework s’intègre

nativement dans les Framework PHP Zend et Symfony, ainsi que le JSP Spring MVC.


Richesse, flexibilité, maturité et légèreté du

Framework

Pas d’intégration native dans un IDE

Obligation de coder un minimum en

Javascript

Tableau 3-27 : Avantages et inconvénients du Framework Dojo Toolkit

<http://dojotoolkit.org/>

3.3.3.7. Proposition d’architecture associée à une application web

En appliquant la philosophie MVC à l’existant, voici une proposition d’architecture

applicative web :

Figure 3-7 : Proposition d’architecture associée à une solution spécifique binaire


60

Le développement spécifique web est la meilleure interprétation du modèle n-tiers, et

sûrement la meilleure approche en termes d’architecture MVC que l’on peut actuellement

trouver. C’est notamment le cas grâce aux nombreux Framework qui intègrent et imposent

cette philosophie, permettant dès le développement de partir sur de bonnes bases.

Dans cette solution, le client utilise son navigateur pour accéder aux IHM Web.

L’application est présente sur un serveur applicatif Web dynamique (PHP, JSP, …), il n’y a

donc pas de contraintes de déploiement de la solution. La maintenance de l’application se

fait en modifiant les sources du serveur Web, structurées de manière efficace par le

Framework applicatif et le modèle de données présent dans les traitements métiers.

L’intégrateur récupère les objets spécifiés dans le modèle d’objet, et les place dans des

conteneurs. L’agencement est ensuite réalisé côté client.

Une fois l’application internet riche chargée sur le poste du client, celle-ci va utiliser un

Framework Javascript pour récupérer les informations métier sur la couche contrôleur.

Concrètement, l’utilisateur télécharge un canevas vide, et chaque élément (arborescence,

compteur, …) va se connecter au bon Webservice de manière asynchrone (AJAX), afin de

récupérer les informations spécifiques à la vue utilisateur souhaitée.

3.3.3.8. Bilan d’exploitabilité des applications web


Pas de problématique de déploiement

Clients légers

Gratuité des Framework

Effort de développement

Problématique de sécurité à mesurer

Tableau 3-28 : Avantages et inconvénients des applications Web

3.3.4. Bilan d’exploitabilité des solutions spécifiques

En règle générale, voici ce que l’on peut retenir des solutions spécifiques. Dans un premier

temps, toutes se baseraient sur des technologies libres. En couplant ces technologies à des

Framework de développement libres (notamment sur la partie Web), il serait possible de

construire une application de manière rapide et efficace, pour peu que le modèle de données

soit maîtrisé.

La flexibilité et l’intégration des exigences du chantier seraient optimales de par la spécificité

du développement. Bien entendu, cela signifie un effort supplémentaire en modélisation,

mais cet effort serait plus structurant à long terme. Bien sûr, une solution spécifique n’est

pas clé en main ; il faudra donc très certainement développer des briques génériques existant

Simon Joliet

61

déjà dans des produits sur étagère. Le support n’est enfin pas garanti sur la solution (mais il

l’est sur la technologie et sur le Framework).


Solutions libres

Réutilisation possible

Flexibilité optimale

Intégrations optimale des exigences

Effort de développement

Pas de solutions clé en main

Modèle de données à maîtriser parfaitement

Pas de support

Tableau 3-29 : Avantages et inconvénients du développement spécifique


62

3.4. Synthèse générale

3.4.1. Comparatif des solutions Off The Shelf et Spécifique

D’après ce que nous avons pu voir des analyses précédentes, nous dressons le tableau

comparatif suivant, en nous basant sur les six points proposés par Sadovykh :

• Interopérabilité : C’est le point fort d’une solution spécifique. Les solutions sur

étagère intègrent quant à elles plutôt bien cette donnée au niveau réseau même si ce

n’est pas le but premier et c’est encore plus le cas avec les solutions de type SCADA

dont une des motivations premières est de faire communiquer des appareils

industriels de technologie différente.

• Portabilité : Elle est plus facile côté développement spécifique. Côté solutions sur

étagère, elle est souvent dépendante des systèmes hôtes sur les parties serveur et

client, mais ce point est rarement problématique. La mise en place d’un système sur

étagère au sein d’un système complexe et à l’historique chargé peut-être

problématique, notamment en terme d’intégration avec l’existant et sur des

questions d’architecture.

• Flexibilité : Le développement spécifique offre une grande flexibilité, surtout avec

les Webservices, les différents Framework et le modèle MVC. Les solutions sur

étagère sont en règle générale plus rigides. La scalabilité n’est pas toujours assurée.

• Support d’agent : Les solutions sur étagère disposent très souvent de moyens de

prédiction d’évènement, de découverte des systèmes, etc. Ce point qui est un

avantage significatif, peut ne pas être très utile lorsqu’un système sur lequel

s’applique une solution est très particulier. Côté développement spécifique, le

support d’agent intelligent n’existe pas. C’est une notion à mettre en place si le

besoin est effectif.

• Facilité de développement : Ce point est assez particulier puisque idéalement, une

solution sur étagère ne devrait pas imposer de développement. En réalité, un

paramétrage (à mesurer) peut-être une opération très lourde et dans le cas de

systèmes très particuliers, l’utilisation de produits off the shelf ne se justifie pas

toujours. Côté développement spécifique, par essence tout devra être développé

donc la facilité de mise en œuvre n’est pas garantie.

• Facilité d’utilisation : En développement spécifique, les outils tels que les Framework

simplifient la génération et la réutilisation du code, mais ces solutions ne sont tout

de même pas évidentes à prendre en main. En spécifique, l’ergonomie doit être mise

Simon Joliet

63

en place. Les solutions sur étagère intègrent nativement les notions d’ergonomie et

poussent au maximum la facilité d’utilisation.

En voici la synthèse :

Off the shelf Spécifique

Interopérabilité Moyenne Très bonne Portabilité Moyenne Bonne Flexibilité Moyenne Bonne Support d'agents Bon Faible Facilité de développement Moyen Assez faible Facilité d’utilisation Bon Assez faible

Tableau 3-30 : Comparatif qualitatif des solutions sur étagère et du développement spécifique

Ce que nous synthétisons de la manière suivante :

Figure 3-8 : Synoptique de synthèse, solutions off the shelf contre développement spécifique

Interopérabilité

Portabilité

Flexibilité

Support d'agents

Facilité de développement

Facilité d’utilisation

Off the shelf

Spécifique


64

3.5. Arbre des solutions de l’état de l’art

La constitution de cet état de l’art nous permet donc d’exposer objectivement l’outillage

technique nécessaire à la mise en œuvre du produit. Ce dernier est présenté ci-dessous sous

la forme d’un outil décisionnel facilitant le choix d’une solution par rapport aux besoins sur

une problématique identique du chantier de l’exploitabilité.

Figure 3-9 : Arbre de solutions de l’état de l’art

: Choix d’architecture : Branche principale

: Choix de solution : Branche complémentaire

: Choix d’architecture et de solution

Simon Joliet

65

3.6. Conclusion de l’état de l’art

Il existe de nombreuses possibilités pour superviser et exploiter un système. Les besoins industriels ont contribués au développement de deux grandes familles de supervision : la supervision réseau et la supervision industrielle. La liste n’est pas exhaustive et pourra au besoin être étendue à d’autres familles de progiciels. Pourtant si ces deux solutions semblent brasser un éventail très large de besoins, il n’est pourtant pas évident de choisir une solution par rapport à une autre, tant celles-ci peuvent différer dans l’usage. La réutilisation d’outils existants n’est cependant pas la seule approche bien qu’elle présente un avantage incontestable. En effet, un développement spécifique pourrait, face à des besoins non couverts par une solution du marché, être une démarche nécessaire. Cependant, un développement spécifique ne signifie pas nécessairement une mise en œuvre from scratch. Il existe de nombreux Framework génériques permettant de développer rapidement et efficacement une solution sur mesure. Encore une fois, d’autres paradigmes que ceux présentés existent en génie logiciel et pourrait aussi bien supporter ce chantier. Le choix d’une solution est en somme un exercice difficile. Pour être certain de faire le bon choix, la meilleure solution reste de cerner précisément le besoin et d’argumenter sur ce denier en fonction des spécificités des approches. Chacune des technologies présentées serait à même de pouvoir conduire le chantier. Reste à savoir laquelle pourrait le faire d’une manière indiscutablement plus efficace.


66

4. MÉTHODOLOGIE

4.1. Approche

La méthodologie constitue la définition du processus d’ingénierie du projet. Cette formalisation permet de guider le cycle de développement, afin de transformer un système existant en une nouvelle solution. Cette dernière doit à la fois tenir compte de la stratégie de l’entreprise et des exigences des parties prenantes. Ces exigences sont générées sur la base de l’exploitation du système actuel et plus globalement, de l’environnement des parties prenantes. Dans le cas présent, le rôle de la formalisation est d’aider la constitution du dispositif organisationnel permettant de redéfinir l’exploitabilité d’un système existant. L’exécution de cette démarche permettrait ainsi d’obtenir un projet fonctionnel, conduisant efficacement l’ingénierie de produit.

Figure 4-1 : Workflow de plus haut niveau, définissant la position de la méthodologie

Dans le projet de l’exploitabilité, nous observons la présence d’un certain nombre d’acteurs que nous englobons ici dans l’entité « Parties prenantes ». Le système actuel est utilisé et maintenu par des parties prenantes. L’utilisation faite du système actuel génère des besoins qui viennent alimenter un processus de développement. Afin d’éviter que le projet ne soit pas établi sur un mauvais périmètre, il est nécessaire avant cette étape que l’organisation structure les pré-études avant même le recueil des besoins des parties prenantes. Il s’agit en effet de définir qui sont ces parties prenantes, comment formaliser leurs besoins, quelle méthode de projet va être mise en place, quelle cible est fixée, quel budget est alloué, etc. Le tout pour diriger un projet sur une cible, le système projeté, qui n’est ni clairement définie, ni même connue. L’exercice est donc loin d’être trivial.

Simon Joliet

67

Globalement pour répondre au besoin qui vient d’être soulevé, deux grandes familles d’ingénierie de projet sont potentiellement à même de piloter ce chantier :

• L’ingénierie classique (Modèle en cascade66, cycle en V67, …) • L’ingénierie incrémentale (Méthodes Agiles68, RUP69, …)

Par rapport au chantier, un modèle classique ne paraît pas être la meilleure approche. En effet, cette méthode impose que tous les besoins, parties prenantes et système cible soient connus au démarrage du projet. Or ce n’est presque jamais le cas sur un chantier aussi structurant que celui de l’exploitabilité des systèmes. De plus en impliquant directement les parties prenantes, il ne semblerait pas pertinent de réaliser l’expression de besoins au seul moment du démarrage du projet. La meilleure réponse en termes de méthodologie, afin de prendre en compte des besoins susceptibles d’évoluer au cours du temps, sont clairement les méthodes Agiles (Aubry, 2011). La notion de communication sur les livrables est en effet fondamentale pour un tel chantier. Plutôt que de se concentrer sur des étapes de projet, il apparaît plus logique d’observer une démarche orientée par les livrables. Ces livrables permettraient à la fois de communiquer sur le projet et de faire participer les parties prenantes à la mise en place du système projeté. Il convient ensuite de valider régulièrement les développements afin de pouvoir réagir rapidement en cas de mauvaise interprétation des besoins. Chaque cycle est enfin la possibilité pour les parties prenantes de découvrir de nouvelles exigences. L’idée directrice de la méthodologie mise en œuvre dans le cadre de ce projet, est que le chantier serait dirigé exclusivement par les exigences de ses parties prenantes. Ces exigences constitueront la matière première du projet ; elles seront récoltées, classifiées et triées, puis conceptualisées, compilées itérativement au sein d’un prototype et enfin mutualisées au sein du système cible. Il convient à présent de définir comment passer de l’abstrait au concret, en mettant en place cette méthodologie innovante.

4.1.1. Constitution d’une méthodologie

4.1.1.1. Transformation des artefacts de projet

Comme énoncé précédemment, il est nécessaire de développer une méthode performante afin de piloter un tel chantier. Une première étape consiste à définir clairement comment transformer des exigences en une série de livrables intermédiaires permettant par la suite de construire un prototype, puis le système cible. Cette représentation est inspirée des transformations de modèles UML (Menet L., 2008).

Figure 4-2 : Modèle de transition du système existant au système cible en utilisant les exigences

Voici l’articulation de ces transformations successives :


68

• L’organisation émet des exigences stratégiques au système cible (exemple : obtenir

de nouveaux marchés ou augmenter le nombre d’utilisateurs satisfaits). Les parties

prenantes émettent à leur tour leurs exigences opérationnelles et fonctionnelles

sur l’existant.

• Ces exigences sont alors organisées, groupées et reliées les unes aux autres afin de

constituer des clusters d’exigences corrélés et hiérarchisées.

• Ces clusters d’exigences sont extraits du gisement, et sont contextualisées par le

biais de macro-design, regroupés ensuite au sein de maquettes. Ces macro-designs

qui représentent une à plusieurs exigences sont alors soumis à la validation des

parties prenantes.

• Les macro-designs sont transformés en briques applicatives grâce à la technologie

retenue par l’application de l’état de l’art par rapport au contexte.

• Les briques applicatives embarquant les clusters d’exigences sont alors soumis à la

validation des parties prenantes, générant potentiellement de nouvelles exigences

opérationnelles ou fonctionnelles à ajouter au gisement.

• Les briques applicatives validées sont compilées au sein du prototype. Une fois un

trigger atteint (nombre d’exigences satisfaites atteint, ressources épuisées, deadline

atteinte), le prototype est soumis à la validation des parties prenantes.

• La validation du prototype par les parties prenantes génère de nouvelles exigences

à ajouter au gisement. Le prototype fournit alors la base de l’industrialisation du

produit final.

4.1.1.2. Méthodes utilisées

Plutôt que de développer une méthode sur mesure, il est souvent préférable d’utiliser des méthodes éprouvées pour les connecter (Ralyté et al, 2001). En utilisant l’ingénierie des méthodes à base de composants, il est possible de développer une méthode pour les besoins spécifiques d’un projet, en modélisant les concepts utilisés au sein des différentes méthodes. Voir Annexe « Méta modèle global des entités et des méthodes de projet » en page 115. Pour formaliser l’ensemble projet, l’approche retenue est l’ingénierie dirigée par les modèles

(MDE). En effet, la complexité mais aussi la richesse et la durée du projet implique une

réflexion importante sur sa formalisation. Cela permet ainsi d’articuler un certain nombre

de méthodes utilisant des artefacts pour créer d’autres d’artefacts. Les différentes méthodes

peuvent en théorie être connectées par ces artefacts, pour peu que ceux-ci soient définis

d’une manière les rendant compatibles avec les méthodes les exploitant.

Simon Joliet

69

L’ingénierie dirigée par les modèles simplifierait le découpage du projet en un ensemble de

processus clairs et séquencés. De plus, comme cette méthodologie utilise plusieurs approches

distinctes, la formalisation des processus et des artefacts du projet permet de la représenter

de façon homogène. Globalement toute la méthodologie est basée sur trois concepts : des

concepts de parties prenantes, d’artefacts et de transformation d’artefacts, comme expliqué

dans la partie précédente.

Les artefacts sont les objets du projet, comme les exigences ou les macro-designs, exprimés

par les parties prenantes, quand les transformations sont des processus de projet, pilotés par

certaines parties prenantes. Ces processus explicités par la suite utiliseront la représentation

MAP70 (Ben Achour et al., 1999), et les entités seront modélisées par des diagrammes de

classe de type UML (Morley C., 2008). Exemple : on passe d’un artefact « exigence » à un

artefact « prototype » par un processus de rédaction d’un scénario (voir partie 4.3.3

Processus de rédaction du scénario en page 86). Schématiquement, ce processus consommer

une exigence, pour la transformer en scénario.

Les méthodologies et concepts utilisés pour piloter le chantier de l’exploitabilité sont :

• l’ingénierie des exigences pour la collecte des besoins (Rolland et al, 1999),

• les verbes d’EKD-CMM71 pour formaliser les exigences d’impact (Nurcan S., 2003),

• l’approche dirigée par les scénarios pour réaliser macro-designs, (Rolland et al, 1996),

• les méthodes agiles pour l’opérationnalisation des solutions (Aubry C., 2011).

L’idée sous-jacente à l’emploi d’une composition de ces différentes méthodes est l’implication forte des parties prenantes lors de la mise en œuvre du système cible. L’approche est donc de chaîner de manière homogène les trois premières méthodes au sein de cycles de développement Agiles (en utilisant une approche SCRUM72).

Figure 4-3 : Modèle de transition et chaînage des méthodologies utilisées

4.1.2. Modèle de processus

Tel que définie précédemment, la base et la matière première du projet sont donc un gisement d’exigences structurées, hiérarchisées et mises à jour de manière incrémentale. La définition itérative des exigences est donc le point central de toute la méthodologie, ce qui impose presque mathématiquement l’utilisation d’une approche de type Agile, afin de pouvoir réagir à la mise à jour permanente du référentiel d’exigences.


70

Start

i1 Définir les exigences

i2 Prototyper

S2 Par approche

Bottom-Up

S1 Par approche

Top-Down

S3 Par cluster

S11 Par

validation

d’étude

S4 Par

similitude

S8 Par

invalidation

de concept

S7 Par validation

de concept

S10 Par

itération

S5 Par composition

i3 Industrialiser

Stop

S15 Par validation

d’industrialisation

S13 Par invalidation

d’industrialisation

S6 Par rédaction

De scénario

S12 Par

composition

S14 Par itération

S9 Par macro

développement

Figure 4-4 Modélisation du processus de projet macro avec MAP

Nom Processus de projet de haut niveau But Augmenter la valeur d’usage d’un système Entrée Le Business Model de l’organisation

Les besoins des parties prenantes du système AS IS Sortie Le système TO BE conforme aux exigences validées des parties prenantes Intentions

i1 : Définir les exigences i2 : Prototyper i3 : Industrialiser

Stratégies S1 : Par approche Top Down S2 : Par approche Bottom Up S3 : Par cluster S4 : Par similitude S5 : Par composition S6 : Par rédaction de scénario S7 : Par validation de concept S8 : Par invalidation de concept S9 : Par macro développement S10 : Par itération S11 : Par validation d’étude S12 : Par composition S13 : Par invalidation d’industrialisation S14 : Par itération

Simon Joliet

71

S15 : Par validation d’industrialisation Tableau 4-1 : Description de la stratégie : Processus du projet de l’exploitabilité de haut niveau

La méthodologie se compose donc de trois étapes majeures : La première « i1 Définir les exigences », est l’intention centrale, elle est en fait la constitution du gisement d’exigence, qui sera exploité tout au long du cycle de vie du projet. La seconde intention « i2 Prototyper » consiste à conceptualiser une à plusieurs exigences au sein d’un prototype. Un prototype peut être de plusieurs niveaux ; il peut s’agir d’un scénario fonctionnel, d’une maquette, d’une brique applicative, etc. Ce point sera définit dans le chapitre associé. Enfin la troisième intention, « i3 Industrialiser » consiste en la compilation des multiples prototypes validés dans un produit complet et fonctionnel répondant aux exigences sélectionnées et validées dans leurs interprétations par les parties prenantes. La MAP utilisée ici sera raffinée section par section dans les parties associées à la suite de ce document.

4.1.3. Approche Top-Down

L’approche Top-Down part du principe que l’applicatif, les exigences des parties prenantes et l’expertise sur le système sont suffisant pour définir les exigences du niveau stratégique au niveau opérationnel. Il s’agit du raffinement de la section S1 de la MAP globale.

Figure 4-4 : S1, Modélisation de découverte des exigences par processus Top-Down

Nom Découverte des exigences par processus Top-Down But Constituer un gisement d’exigences Entrée Le Business Model de l’organisation Sortie Un gisement d’exigences de niveau stratégique, fonctionnel et opérationnel Intentions i1.1 : Collecter des exigences stratégiques


72

i1.2 : Collecter des exigences fonctionnelles i1.3 : Collecter des exigences opérationnelles

Stratégies S1.1 : Par analyse du business model S1.2 : Par composition S1.3 : Par raffinement S1.4 : Par composition S1.5 : Par raffinement S1.6 : Par cluster S1.7 : Par similitude S1.8 : Par validation

Tableau 4-2 : Description de la stratégie S1 : Découverte des exigences par processus Top-Down

4.1.4. Approche Bottom-Up

Comme il a été dit, il n’est pas toujours possible de mettre en place une approche Top-Down. Dans les autres cas, c’est l’approche Bottom-Up qui sera préférée. Contrairement à l’approche Top-Down, l’approche Bottom-Up doit être mise en place en deux temps. D’abord on capture les exigences opérationnelles, puis on les organise afin de découvrir nos exigences fonctionnelles, que l’on rapproche aux exigences stratégiques de l’organisation. Une fois cette première passe effectuée, on applique l’approche Top-Down sur le gisement organisé afin d’éliminer les exigences fonctionnelles et opérationnelles hors scope. Il s’agit du raffinement de la section S2 de la MAP globale.

Figure 4-5 : S2, Modélisation de découverte des exigences par processus Bottom-Up

Nom Découverte des exigences par processus Bottom-Up But Constituer un gisement d’exigences Entrée Les besoins des parties prenantes du système AS IS Sortie Un gisement d’exigences de niveau stratégique, fonctionnel et opérationnel

Simon Joliet

73

Intentions

i2.1 : Collecter des exigences opérationnelles i2.2 : Collecter des exigences fonctionnelles i2.3 : Collecter des exigences stratégiques

Stratégies S2.1 : Par analyse du système S2.2 : Par cluster S2.3 : Par similitude S2.4 : Par validation S2.5 : Par cluster S2.6 : Par raffinement S2.7 : Par généralisation S2.8 : Par cluster S2.9 : Par raffinement S2.10 : Par généralisation S2.11 : Par rapprochement avec le business model S2.12 : Par élimination S2.13 : Par élimination

Tableau 4-3 : Description de la stratégie S2 : Découverte des exigences par processus Bottom-Up

L’approche Bottom-Up est à privilégier lorsque le niveau d’expertise n’est pas jugée suffisant

sur le système.

� : Dans le cas du projet Platine, c’est cette approche qui aura été retenue face à la complexité de l’application et au vu des diversités potentielles des parties prenantes et des besoins.

4.1.5. Déterminer la meilleure approche de collecte

Comme cela a été présenté, il existe deux approches distinctes de collecte initiale des exigences : l’approche Top-Down et l’approche Bottom-Up (aussi connues sous le nom d’approche montantes et descendantes). Comme il n’est pas toujours évident de trouver la meilleure stratégie, il peut paraître intéressant de dresser une synthèse pouvant servir d’outil décisionnel lorsque la meilleure approche doit être déterminée. En effet la première constitution des exigences est primordiale pour lancer efficacement le chantier.

Top-Down Bottom-Up

Paradigme Heuristique Empirique Approche Analytique Synthétique

Fonctionnement Par déduction Par initiative Démarche mise en place Dirigiste Participative Taille de l’organisation Petite à moyenne Moyenne à grande

Tableau 4-4 : Comparatif des approches Top-Down et Bottom Up

Comme ce comparatif le montre, ces deux approches ne partent pas des mêmes postulats. L’approche Top-Down est donc à privilégier lorsque l’organisation, les objectifs et la cible sont connus au démarrage du chantier, ce qui sera dans les faits rarement le cas. Ainsi et de


74

par son aspect collaboratif, l’approche Bottom-Up sera très souvent préférée pour les chantiers d’exploitabilité.

4.1.6. Aspect itératif de l’opérationnalisation

Concernant l’opérationnalisation, celle-ci est à l’instar de l’ensemble de la méthodologie, basée sur des modèles itératifs. L’objectif premier est d’offrir un prototype cohérent par rapport à un certain nombre d’exigences (un maximum en l’occurrence). Si toutes ne peuvent pas bien sûr, être opérationnalisées au sein d’un prototype, il est nécessaire de déceler les exigences fondamentales à opérationnaliser en priorité. Pour cela il est primordial que les parties prenantes soient inclues au plus proche du chantier. La meilleure solution semble passer par des développements unitaires, des validations nombreuses de la part des parties prenantes afin de pourvoir efficacement piloter une opérationnalisation. L’utilisation des méthodes Agiles semble tomber sous le sens par rapport à ces contraintes. La méthodologie présentée est compatible SCRUM (Aubry C., 2011).

� : Pour Platine, les entités SCRUM au projet ont été identifiées au sein des parties prenantes :

● Le Directeur de Projet et responsable du service « Skill Center Médiation », Alain Goy, en tant que Product Owner en qualité d’éditeur de solution,

● Le chargé de projet, Simon Joliet, en tant que ScrumMaster, ● L’équipe de projet, Geoffroy Veger et Dominique Dejammes, en tant que team, ● Et enfin les utilisateurs du système, en l’occurrence l’instance d’exploitation

DECI, en tant que System’s Users.

4.1.7. Extension de SCRUM à la méthodologie

L’objectif n’est pas ici de présenter une méthodologie déjà éprouvée, mais plutôt d’observer comment celle-ci pourrait être mise en situation dans le cadre de ce chantier de l’exploitabilité. La formalisation des exigences proposée et l’approche dirigée par les scénarii structurent certains livrables, dont la définition diffère même si l’ensemble de la philosophie reste inchangée. A titre d’illustration, le cycle de vie d’un processus SCRUM :

Figure 4-6 : La vision des sprints SCRUM selon Mike Cohn

Simon Joliet

75

Dans ce schéma, il apparaît que la base du développement, l’équivalent des spécifications en ingénierie classique, est ici un référentiel appelé backlog. Cet élément est simplement une liste d’éléments rangés par priorité. SCRUM ne définit pas ce que doivent être ces éléments, qui sont nommés de manière courante des stories. Le backlog de produit est l’ensemble de ces stories, quand le backlog de sprint est l’ensemble des stories extraites dans le cadre d’un sprint. A la fin du sprint, les stories sont compilées dans le livrable. L’approche utilisée diffère quelque peu, mais comme les objets consommés par les processus SCRUM ne sont pas clairement définis par la méthode elle-même, il est possible de structurer le processus d’ingénierie incrémentale en se basant sur d’autres entités. Pour la méthodologie mise en place dans le cadre de cette étude, c’est l’approche ci-dessous qui a été observée.

Gisement

D’exigences

Maquette LivrableSprint

2 semaines

24 heures

Figure 4-7 : Extension du schéma de Mike Cohn par une approche dirigée par les exigences

Dans le cas présent, le gisement d’exigence est organisé par priorité, mais aussi par niveau fonctionnel et par opérateur, ce qui est un enrichissement considérable par rapport aux backlog classiques (voir chapitre suivant, 4.2 Exigences en page 77). L’extraction des exigences se fait par priorisation motivée par les parties prenantes ; les extractions réalisées sont ensuite conceptualisées au sein de maquettes, embarquant des clusters d’exigences corrélés, équivalents aux stories SCRUM. Une des grandes différences de l’approche est de pouvoir l’utiliser pendant une démarche conceptuelle, c'est-à-dire que le livrable pourra être une autre maquette. Ainsi la démarche ne sert pas seulement de support à l’ingénierie logicielle dans le cadre des développements, mais aussi de guide à l’ingénierie des exigences de par sa capacité à formaliser des exigences fonctionnelles au travers de maquettes.


76

4.1.8. Implication des parties prenantes

L’utilisation des méthodes Agiles au sein de ce projet va donc nous permettre de rapprocher les parties prenantes de notre réflexion de projet. Pour les impliquer de façon efficace et productive, il est indispensable de fixer des réunions d’avancement et de validation à fréquence fixes. Ces réunions permettraient de :

• Présenter l’avancement des travaux, • Valider les développements effectués, • Exprimer la liste des lots suivants à opérationnaliser en priorité, • Valider une liste d’exigences à opérationnaliser, • Fixer les objectifs de prochaine itération (sprint73).

Voir annexe : 6.12 Réunion Agile type en page 123. Dans le cadre de ce projet et conformément à la philosophie SCRUM, il est nécessaire d’organiser un ensemble de réunions. Les réunions sont à intervalles réguliers et chacune possède un ordre du jour bien spécifique. Le rôle du ScrumMaster74 est de veiller à ce que chaque réunion atteigne son objectif prévu. � : Dans le cas du premier sprint du projet Platine, 21 exigences opérationnelles ont étés extraites du gisement. Ces exigences ont été conceptualisées dans plusieurs macro-designs (principalement des maquettes) qui ont été présentés, argumentés puis validés de manière itérative au cours de diverses réunions Agiles. Ces réunions sont aussi l’occasion de découvrir de nouvelles exigences opérationnelles et fonctionnelles qui sont alors ajoutées au gisement.

Simon Joliet

77

4.2. Exigences

Les exigences sont la base de ce projet. Chaque maquette, scénario ou développement doit impérativement être supporté par une à n exigences du gisement. Un macro design ne concrétisant pas d’exigence doit être abandonné et ne peut pas servir de base à un développement. En philosophie SCRUM, l’approche est quasiment identique avec le backlog de produit (Aubry C., 2011). L’intérêt des exigences au sein de ce type de chantier est de pouvoir consigner un très grand nombre et une très grande variété de besoins exprimés par les parties prenantes. Mais pour que l’exploitation de ce gisement soit efficace, il doit impérativement être organisé de manière pertinente. Avant d’aller plus loin concernant les stratégies applicables aux exigences, tâchons de définir ce qu’est cet élément atomique au chantier : l’exigence.

4.2.1. Modèle des exigences

Comme indiqué précédemment, il existe trois niveaux d’exigences : Stratégiques, Fonctionnelles et Opérationnelles. Afin d’organiser le plus efficacement possible ces exigences, il est primordial de les classer selon ces trois niveaux. Nous décrierons plus loin les caractéristiques associées à cette taxonomie.

Niveau d’exigence Impacts

Exigences stratégiques Propres à l’industrie Exigences fonctionnelles Propres aux métiers ; qualitatives Exigences opérationnelles Propres à l’application ; quantitatives

Tableau 4-5 : Description des niveaux d’exigences

En voici une le méta modèle conforme à la représentation UML75 :


78

Exigence Partie prenante10..*

Propose1..*1

ConcernePriorité*1

Possède

0..*

1..*

Composée

par

Corps

*

1

Décrite par

Stratégique Applicative Opérationnelle

OR

Identifiant

Niveau

0..*

1..*Raffiné

par

1

*

Caractérisé par

1

*

Repérée par

Figure 4-8 : Méta-modélisation des exigences

Attribut Rôle Contenu

Exigence Nomme Le nom (titre <verbe> <cible> <manière>) de l’exigence

Identifiant Identifie L’identifiant unique de l’exigence Niveau Caractérise Le niveau de l’exigence (Stratégique, Applicatif ou

Opérationnel) Auteur Proposé par La partie prenante émettrice de l’exigence Partie(s) prenante(s) Concerne Les/les parties prenantes concernées par l’exigence Exigence(s) parente(s)

Compose une

La ou les exigences d’un niveau supérieur (sauf si niveau d’exigence stratégique)

Exigence(s) descendante(s)

Raffinée par La ou les exigences descendantes d’un même niveau

Corps Décrit par Le contenu descriptif (prose) de l’exigence Tableau 4-6 : Descriptif du méta modèle des exigences

Les exigences sont toujours spécifiées et rédigées par une partie prenante. Elle doit posséder un identifiant unique, ou un texte formaté explicitant son action et un texte en prose commentant cette dernière. De plus, chaque exigence peut posséder 0 à n exigences parentes, et 0 à n exigences enfantes.

� : 4 parties prenantes ont été identifiées dans le cadre du projet Platine et ont donc été invitées à abonder le gisement d’exigences associé au chantier :

● La maîtrise d’œuvre du produit (Skill Center Médiation Platine) ● Les ergonomes ● Les intégrateurs ● Et bien sûr les utilisateurs du produit, qui sont divisés en deux métiers :

Simon Joliet

79

● Les experts métiers ● Les exploitants

Concernant les utilisateurs, deux instances d’exploitation du produit ont étés sondés. L’exploitant DECI supervise la production de toutes les instances France du produit (quatre instances techniques, fixe et mobile et temps réel), ainsi que l’exploitant Sonatel qui supervise les instances du groupe au Sénégal, pour le compte des clients du groupe en Afrique de l’ouest (Sénégal, Guinée Bissau, Guinée Conakry et Côte d’Ivoire). Voir en annexe 6.6 Extrait du gisement d’exigences en page 117.

Le méta-modèle UML des exigences propose de lier chaque exigence à une autre de niveau inférieur ou supérieur, de la manière suivante :

Figure 4-9 : Exemple de taxonomie des exigences

Dans cet exemple, on voit que les exigences stratégiques E1 et E2 sont supportées par au moins une exigence fonctionnelle, elles-mêmes supportée par une à plusieurs exigences opérationnelles. A titre d’illustration : l’exigence stratégique E2 est « Introduire un nouvel argument commercial au système X », qui se traduit par l’exigence fonctionnelle E5 « Améliorer la connectivité avec le système Y », encore une fois traduit par une exigence opérationnelle « Introduire un connecteur applicatif type Z ». Si l’objectif du chantier change et l’exigence E2 n’est plus à l’ordre du jour, les exigences E5 et E8 seront de fait éliminées du chantier.

4.2.2. Exigences Stratégiques (propres à l’industrie)

Ces exigences sont conditionnées par le modèle de l’organisation. Elles fixent un spectre très large au projet. Dans le cas de l’exploitabilité d’un système, il peut s’agir par exemple d’obtenir de nouveaux marchés, de satisfaire les utilisateurs, d’optimiser l’activité d’un métier. Dans ces exemples, de telles exigences ne peuvent être satisfaites que si certaines exigences qualitatives (fonctionnelles) sont elles-mêmes satisfaites. Encore une fois ces exigences fonctionnelles se basent sur la mise en œuvre d’exigences opérationnelles.


80

Le Business Model d’une organisation consiste en une mission stratégique, une vision et les valeurs de cette dernière (Hearn D., 2009). Cette définition permet de définir et de structurer des sous-stratégies, assemblables en processus métiers, donc de niveau fonctionnel. Dans les SI, et par effet de bord dans les projets SI, les produits et les processus sont et doivent être perçus comme étant le support du business model et des exigences stratégiques. Cela nécessite une modélisation de la stratégie d’entreprise, orientée et appliquée au projet d’exploitabilité pour un système donné. Les exigences stratégiques doivent être en phase avec la stratégie d’entreprise. Le rôle du projet d’exploitabilité consiste donc à traduire ces exigences stratégiques en fonctions, puis à les rendre opérationnelles. Ce mécanisme est appliqué aux exigences afin d’aligner le produit sur la stratégie de l’organisation. � : Dans le projet Platine, le service d’accueil est aussi éditeur de solution et propose ainsi ses exigences stratégiques.

4.2.2.1. Détermination des exigences stratégiques à partir d’un

business model

Cette stratégie consiste à connecter directement le projet au Business Model de l’organisation. Elle implique une connaissance forte du système sur lequel le projet porte, mais aussi sur l’organisation elle-même.

� : Exemple dans le cadre du projet Platine, au sein de l’entreprise France Télécom/Orange : La stratégie actuelle du groupe consiste en quatre grands axes, visant à mettre en valeur :

● Les femmes et les hommes d’Orange, ● Les réseaux, ● Les clients, ● Le développement international.

Pour le projet Platine, la réflexion dirigeant le renouveau de l’exploitabilité est avant tout motivée par l’acquisition de nouveaux marchés internationaux, la découverte de nouvelles applications au système type M2M et la satisfaction des utilisateurs actuels du système. Le projet est donc directement connecté aux stratégies d’entreprise mettant en valeur le développement international, ainsi que les utilisateurs de la solution au sein du groupe France Télécom /Orange. Dans ce projet, le choix de partir des exigences stratégiques pour déterminer les exigences fonctionnelles et opérationnelles (approche Top-Down), n’a cependant pas été retenu. La richesse de l’organisation en effet, mais aussi des métiers exploitant le produit est trop complexe pour rendre cette approche rapidement efficace.

4.2.3. Exigences Fonctionnelles (propres aux métiers)

Simon Joliet

81

Les exigences fonctionnelles portent globalement sur les aspects qualitatifs des systèmes, ou en tout cas tous les points ne pouvant être directement opérationnalisés mais n’étant pas de niveau stratégique. Ces aspects qualitatifs peuvent servir à l’élaboration d’indicateurs de performance clé (KPI76). Il est possible de déterminer les exigences stratégiques à partir des exigences fonctionnelles. Au lieu d’analyser les perspectives d’amélioration en alignant les ingénieries de projet et de produit au business model (approche Top-Down), une autre approche consiste à déterminer les exigences stratégiques au travers des exigences fonctionnelles (approche Bottom-Up). Dans cette optique, la stratégie d’entreprise n’impacte le produit que par le biais des exigences fonctionnelles exprimées par le métier et les autres parties prenantes. Ce sont les qualités et les comportements voulus par ces parties prenantes pour ce système qui fixent les directives du projet et ces mêmes qualités doivent ensuite trouver justification auprès de la stratégie d’entreprise. Cette stratégie Bottom-Up consiste à déterminer les corrélations des exigences opérationnelles par un processus de clustérisations. Une telle stratégie est à privilégier sur les projets très impactants et les organisations complexes.

� : Dans le cadre du projet Platine, c’est cette stratégie qui aura été mise en place.

4.2.4. Exigences Opérationnelles (propres au système)

Les exigences opérationnelles sont le niveau le plus bas –atomique des exigences. Une exigence opérationnelle pourrait être directement implantable sur le système courant, mais dans la méthodologie proposée, ces exigences de bas niveau doivent impérativement être connectées à des exigences fonctionnelles elles-mêmes connectées à des exigences stratégiques, afin que chaque opérationnalisation permette de participer à la concrétisation des objectifs stratégiques du chantier. Comme expliqué précédemment, une exigence orpheline n’a pas lieu d’être prise en considération dans les cycles incrémentaux si elle ne participe pas à des exigences de plus haut niveau. Elle doit donc être éliminée à moins que de nouvelles exigences fonctionnelles soient découvertes. Les exigences opérationnelles peuvent facilement être conceptualisées dans des macro-designs, elles sont donc de fait la base du chantier.

4.2.5. Recueil des exigences

Le méta-modèle ci-après nous permet d’obtenir un canevas formalisant les exigences que

nous définirons au cours de notre étude. Mais si ce-méta-modèle convient à la structuration

de l’information, ce n’est pas forcément le cas pour la captation de cette dernière. Or dans

l’approche Bottom-Up, il est nécessaire de recueillir les exigences des parties prenantes,

structurées par un canevas (ou d’un backlog SCRUM). Il est nécessaire d’exécuter le méta-

modèle afin d’obtenir un formulaire de recueil d’exigences.


82

La méthode EKD-CMM (Nurcan et al, 2003) permet de lancer le chantier du changement.

Elle se base pour cela sur des modèles de buts de transitions, opérationnalisés par les 5 verbes

d’actions suivants : maintenir, cesser, améliorer, introduire, et étendre.

Développer des scénarios de transition est un enjeu important pour la méthode qui est

toujours basée sur un système en l’état (AS-IS). Ces 5 verbes d’action pourraient être utiles

dans le recueil des exigences opérationnelles auprès des parties prenantes. Il convient

d’étendre le modèle des exigences opérationnelles afin d’intégrer ces 5 opérateurs :

Exigence

AND/OR

Opérationnelle Opérateur1 1..*

Maintenir Cesser IntroduireAméliorer Etendre

0..*

1..*

0..* 0..* 0..* 0..*

Figure 4-10 : Méta-modélisation des exigences opérationnelles et des 5 opérateurs du changement


Exigence Nomme Le nom (titre <verbe> <cible> <manière>) de l’exigence Opérationnelle Détermine Niveau d’exigence pouvant être mise en œuvre sans

exigence enfant Opérateur Caractérise Verbe du changement formalisant l’action à effectuer par

rapport à une entité Maintenir Conditionne Entité du système en l’état à conserver Cesser Conditionne Entité du système en l’état à retirer Améliorer Conditionne Entité du système en l’état à améliorer Introduire Conditionne Entité du système en l’état à ajouter Étendre Conditionne Entité du système en l’état dont le champ d’action doit

être augmenté Tableau 4-7 : Descriptif du méta-modèle des exigences opérationnelles

Dès lors, nous concluons que dans le cadre de la récolte des exigences opérationnelles, il sera

fondamental dans un premier temps de comprendre ce que les parties prenantes veulent

maintenir, cesser, améliorer, introduire, et enfin étendre.

Simon Joliet

83

Encore une fois, le méta-modèle est un cadre à la structuration de nos données, mais il ne

permet en aucun cas la collecte. En effet dans le processus Bottom-Up, il est nécessaire de

définir un canevas permettant le recueil et le stockage du gisement d’exigences. La

constitution et l’utilisation d’un canevas de recueil d’exigences n’a de raison d’être

logiquement que dans l’optique d’une approche Bottom-Up (Stratégie S2). Dans l’approche

Top-Down, la première itération du modèle n’implique pas la collecte des exigences auprès

des parties prenantes ; l’utilisation d’un outil n’est donc nécessaire que pour stocker et

organiser les exigences dans ce cas.

Un des objectifs de la méthode est de faire l’abstraction de toute technique

d’implémentation. Il en va de même pour l’outil formalisant la collecte et le stockage du

gisement d’exigences. L’outil ici nommé « canevas » peut prendre de nombreuses formes.

Une base de données de type Microsoft Access peut être un outil performant et rapidement

opérationnalisable pour le développement du canevas. Une fois le canevas développé, celui-

ci peut être diffusé afin de servir efficacement de support à la capture des exigences

opérationnelles et fonctionnelles auprès des parties prenantes.

� : Dans le cas du projet Platine, le canevas a pris la forme d’une feuille Excel formatée à champs fixes. Il a été soumis à la validation du service d’accueil, qui a ensuite été la première partie prenante contributrice. Ce canevas a ensuite été présenté aux utilisateurs finaux, puis à des ergonomes de profession. Nous avons pu constituer grâce à la première itération de cette méthode, un gisement de 124 exigences constituées de : ● 7 exigences stratégiques ● 30 exigences fonctionnelles ● 88 exigences opérationnelles Par rapport aux verbes de transition, ces exigences se composent de : ● 10 Maintenir ● 68 Introduire ● 34 Améliorer ● 4 Étendre ● 8 Cesser Le canevas, doit être considéré comme un contenant. Le contenu est l’ensemble ∈ des exigences recueillies par l’outil jusqu’au déclenchement du trigger τ (nombre d’exigences suffisantes pour le déclenchement du premier incrément, deadline atteinte, ressources de projet épuisées…). Dans SCRUM, le recueil est réalisé au sein du backlog, qui n’est qu’une liste d’exigences, faiblement organisée et sans véritable structure –à moins d’utiliser des outils avancés tels que


84

iceScrum (Aubry C., 2011). Preuve étant que les stories, éléments de base de ce recueil, sont consignées bien souvent à l’aide de fiches bristol ou encore de Post-It®. D’après Aubry, le fait de ne pas utiliser l’outil informatique devient très vite un problème. Dans la méthodologie proposée, le stockage et la gestion du gisement d’exigences sera systématiquement informatisé.

4.3. Scénario

4.3.1. Théorie sur les scénarios

La conceptualisation des exigences opérationnelles est effectuée à l’aide de maquettes

embarquant un à n macro-designs. Une maquette est une forme particulière de scénario

améliorant significativement la description, la portée et l’exploration des interactions

homme-machine pour un système donné. Les projets d’envergure intègrent aujourd’hui

presque systématiquement cette démarche dans leurs développements. Elle permet en effet

une exhaustivité difficilement atteignable par d’autres moyens. La méthode est de plus très

efficace dans la découverte de certaines attentes ou de comportements tacites d’un système

par ses parties prenantes.

Il apparait évident pour les besoins du chantier de comprendre comment ces maquettes

doivent être construites, tout en mettant en évidence leur pertinence. La suite du chantier

s’articule en effet autour de l’approche dirigée par les scénarios (Rolland et al., 1999). Le

projet CREWS77 a mis en place un cadre de classification de différentes approches dirigées

par les scénarios. En effet le volet d’exploitabilité concentre l’intégralité des interactions

homme-machine. Ceci fait de l’approche par scénario une étape clé de l’ingénierie des

exigences pour un tel chantier. Il est donc important de pouvoir déterminer de quelle

manière et sur quels aspects ces approches pourront interagir avec le développement.

Le CREWS propose une méthode permettant de classifier des scénarios selon 4 dimensions,

déterminées comme étant les plus pertinentes. Elle propose ainsi d’offrir une structure

commune aux formalismes d’une majorité des types d’approches dirigées par les scénarios

existants. Les auteurs notent ainsi les concepts de forme, de contenu, de but et de durée de vie.

• La forme est la manière dont est exprimé un scénario. Elle peut être décrite de

manière formelle ou informelle et prendre différentes aspects : texte, image, dessin,

vidéo, animation…

• Le contenu est l’expression du scénario en soi. Il contient l’expression de la

connaissance dudit scénario. Cette expression peut être concrète ou abstraite.

Simon Joliet

85

• Le but représente la fin du scénario face à un problème rencontré ou une fonction

d’un système. Il peut exprimer des alternatives ou montrer des défauts.

• La durée de vie stipule l’évolution du scénario au cours du temps. Un scénario est vu

comme un artefact pouvant être créé, affiné ou supprimé. Cette vue oppose

notamment les caractères persistants et transitoires.

Toutes ces caractéristiques ne seront pas forcément pertinentes pour l’ensemble des

chantiers d’exploitabilité, la prise en considération de certains éléments au profit d’autres

devra être néanmoins argumentée.

4.3.2. Modèles de scénarios

En se basant sur notre contexte où les scénarios sont une représentation d’une exigence

opérationnelle et sur l’analyse des différentes approches dirigées par les scénarios du

CREWS, nous pouvons représenter le méta modèle des scénarios tels qu’utilisé au sein de

notre méthode.

Le modèle défini par le CREWS a cependant été étendu afin d’intégrer la notion d’exigence. Un scénario possède en effet un but, mais aussi une à n exigences opérationnelles. Ces exigences définissent un scénario. Sont ajoutées ensuite les macro-designs qui sont l’entité atomique d’une maquette, conceptualisant une ou plusieurs exigences opérationnelles.

Figure 4-11 : Méta-modélisation du scénario


86


Scénario Modélise Aspect fonctionnel du scénario

Contenu Décrit par Le corps du scénario

Durée de vie Valide pendant La durée de validité du scénario

Forme Défini par La forme, support physique du scénario

Macro Design Conceptualise Scénario unitaire embarquant une à n exigence

Maquette Compile Compilation de macro-designs sur un même support

But Possède Le rôle d’un scénario, la fonctionnalité représentée

Partie prenante Propose/Valide Entité validant le scénario (via la présentation d’une maquette)

Développeur Rédige Entité mettant en place les scénarii

Tableau 4-8 : Descriptif du méta modèle des scénarios

4.3.3. Processus de rédaction du scénario

L’entité scénario aillant été définie, il faut à présent expliciter le processus permettant de passer d’un cluster d’exigences opérationnelles à un macro-design (un scénario), conceptualisant des principes fonctionnels exprimés par les parties prenantes.

Figure 4-12 : Processus de rédaction du scénario

Simon Joliet

87

Nom Processus d’écriture du scénario But Écrire un scénario permettant de conceptualiser une à plusieurs exigences

fonctionnelles du gisement Entrée Exigences opérationnelles validées Sortie Scénario opérationnel Intentions

i6.1 : Agréger les exigences i6.2 : Écrire un scénario

Stratégies S6.1 : Par extraction d’exigences S6.2 : Par similitude S6.3 : Par raffinement S6.4 : Par réécriture S6.5 : Par composition S6.6 : Par cluster S6.7 : Par validation

Tableau 4-9 : Description de la stratégie S6 : Par rédaction du scénario

4.3.4. Macro-design

4.3.5. Maquette

Une maquette est un regroupement de macro design au sein d’une IHM complète, pouvant servir de support à la communication lors des réunions SCRUM où sont réalisée la présentation et la validation de ces maquettes. Les maquettes sont l’équivalent des stories SCRUM ; elles sont les axes de travaux d’un sprint embarquant un certain nombre de points du backlog (Aubry C., 2011).

� : Pour le projet Platine, les maquettes sont réalisées en deux temps. Une première itération permet de valider les principes fonctionnels en utilisant une maquette type « Wireframe » (voir 6.8 Exemple de maquette fil de fer en page 120). Si validation de ces principes, les maquettes étaient réinterprétés par les ergonomes du chantier, ou les interactions et les scénarios étaient mis en lumière (voir 6.9 Exemple de maquette ergonomique en page 121).

4.3.6. Macro-validation du scénario par les parties prenantes

Les macro-validations des scénarios se font lors des réunions Agiles. Dans ce cadre, des maquettes embarquant une à plusieurs exigences opérationnelles sont présentées aux parties prenantes. Le rôle du ScrumMaster doit être de présenter les concepts liés aux différents macro-designs composant ces maquettes, qui seront validés ou non par les parties prenantes. Un scénario non validé peut conduire à une réécriture de ce dernier, puis un nouveau passage en validation au sein d’un nouveau sprint SCRUM. Un scénario validé signifie que l’interprétation fonctionnelle d’une ou plusieurs exigences est cohérente pour une majorité des parties prenantes. Elle peut dès lors être opérationnalisée. Pour ce faire, le scénario doit être transformé en macro-cahier des charges.


88

4.4. Macro Développement

Un macro-développement (ou brique applicative) correspond à la mise en œuvre technique d’un macro-design, embarquant donc une à n exigences. Une brique applicative est développée à l’aide d’un socle technologique déterminé par l’état de l’art.

4.4.1. Modèle du Macro Développement

Tout ou partie d’une maquette validée par les parties prenantes sert dès lors de base au processus de macro développement (ou d’opérationnalisation). En l’occurrence, chaque Macro design packagé au sein d’une maquette défini un macro développement. Ces macro-développements utilisent une technologie spécifiée par l’état de l’art.

Figure 4-13 : Méta-modélisation du macro-développement


Macro-design Défini Entité qui, validée, motive un macro-développement

Macro-développement Fonctionnalise L’aspect fonctionnel du macro-développement

Corps Opérationnalise L’aspect technique du macro-développement

Technologie Utilise La technologie servant de base au macro-développement

Partie Prenante Valide Entité validant le scénario (via la présentation d’une maquette)

Développeur Développe Entité mettant en place les scénarii

Simon Joliet

89

Tableau 4-10 : Descriptif du méta modèle des macro-développements

4.4.2. Processus de Macro-Développement

Le processus de macro développement doit se reposer sur la validation d’un scénario (ou d’une maquette). Lorsque la validation est effective, le prochain sprint sera l’occasion de développer une brique logicielle répondant à l’exigence embarquée dans le scénario validé. Cette brique sera ensuite testée et en cas de validation fonctionnelle, présentée lors de la prochaine réunion.

Figure 4-14 Processus de macro développement

Nom Processus de Macro Développement Rôle Développer une brique fonctionnelle permettant de prototyper un scénario

préalablement validé par les parties prenantes Entrée Macro Design validé Sortie Brique fonctionnelle validée Intentions

i9.1 : Développer i9.2 : Tester

Stratégies S9.1 : Par validation du scénario S9.2 : Par réutilisation S9.3 : Par fin de développement S9.4 : Par nouveau testeur S9.5 : Par validation fonctionnelle S9.6 : Par invalidation du développement

Tableau 4-11 : Description de la stratégie S9 : Par macro développement

4.4.3. Macro-validation de la brique applicative

Le dernier jour d’un sprint, les travaux réalisés sont présentés à un maximum de parties prenantes et potentiellement à des invités. Les tâches accomplies sont unitairement approuvées ou désapprouvées par les parties prenantes, de sorte que le tir puisse systématiquement être corrigé dès le sprint suivant. La macro-validation se fait donc de manière collégiale (Aubry C., 2011).


90

4.5. Prototypage

Le prototypage est incrémental. Il se construit donc brique par brique à mesure que les cycles incrémentaux se suivent. Il n’existe donc pas de phase de prototypage en soit, puisque ce dernier n’est finalement que la compilation de tous les macros-développements effectués, puis validés par les parties prenantes. � : Dans le cas du projet Platine c’est la dernière intention de la méthode proposée qui a pu être mise en œuvre.

Simon Joliet

91

4.6. Industrialisation

Lorsque le prototype est jugé assez mature, par exemple si ce dernier satisfait suffisamment d’exigences, ou si le délai voir si les ressources imposent le passage en industrialisation, le prototype doit être validé. Un prototype validé, c’est une base capitalisée de fonctionnalités validées, opérationnelles sur un périmètre restreint. � : Dans le cas du projet Platine, l’étape d’industrialisation est prévue pour début 2013, soit suite à la livraison finale du prototype. La suite de cette approche est abordée de manière théorique dans la mesure où aucune validation empirique n’a pu être mise en place.

4.6.1. Modèles de l’industrialisation

Comme nous l’avions défini, le prototype est composé de 1 à n macro développements validés par les parties prenantes. Lorsque le prototype est jugé suffisamment mature, celui-ci est validé ou invalidé dans son ensemble (voir MAP globale), afin de servir de base supportant le système cible (TO-BE). Nous modéliserons donc cela de la manière suivante :

Figure 4-15 : Méta modélisation de l’industrialisation


Macro Développement Est composé de Motive le prototype Prototype Conceptualise Base du système cible Système TOBE Finalise Le système cible du chantier Partie Prenante Valide Valide le ou les prototypes

ainsi que le système cible Développeur Développe Développe le ou les

prototypes ainsi que le système cible

Tableau 4-12 : Descriptif du méta modèle de l’industrialisation


92

4.7. Nouvelles exigences opérationnelles

La validation du prototype, comme la validation d’une maquette ou d’une manière générale, lors de tout point formel et informel, est l’occasion d’ajouter de nouvelles exigences au gisement. Le rôle du prototype est en effet de concrétiser les exigences fonctionnelles en conceptualisant un certain nombre d’exigences opérationnelles. Le système cible pourra ainsi bénéficier de la base capitalisée que constituent les incréments du prototype, tout en apportant de nouvelles exigences sur un périmètre plus large cette fois.

Simon Joliet

93

5. ÉVALUATION ET CONCLUSION

5.1. Évaluation empirique

Tous les processus de la méthode ayant été explicités en détail, l’heure est au bilan pour cette dernière partie. La mise en œuvre in situ de la méthode aura permis de revoir certains points qui se seraient montrés perfectibles. Par exemple le canevas de recueil des exigences qui a été deux fois réévalué lorsque des champs manquaient, ce qui a conduit à l’évolution du méta-modèle. Un autre heurt vient du fait que certaines parties prenantes ont été intégrées après le démarrage des cycles de projet, ce qui peut potentiellement remettre en cause les travaux préliminaires. Dans le cadre du projet Platine, la méthodologie aura prouvé sa robustesse puisqu’elle a pu efficacement intégrer deux parties prenantes majeures alors même que le projet était enclenché depuis plusieurs mois (il s’agit en l’occurrence des ergonomes et de l’instance d’exploitation du Sénégal). Il est en effet assez difficile de formaliser l’ensemble d’une ingénierie de projet avant le démarrage du projet lui-même. C’est d’autant plus vrai lorsque la cible et les parties prenantes ne sont pas encore totalement identifiées à l’initialisation du projet. Il est de plus très délicat de diriger tout un projet sans visibilité globale ni objectifs initiaux définis. Pourtant le fait de travailler avec ces éléments atomiques que sont les exigences, permet à chaque instant de juger de la maturité du projet et si la piste actuelle est bonne ou mauvaise, tout en pouvant rapidement réagir à l’ajout ou à la suppression d’entités au projet. Enfin, il ne faut pas perdre de vue que proposer une méthode générique n’est pas toujours la meilleure solution puisque chaque projet est unique et qu’une méthode doit s’adapter aux spécificités d’un projet et non l’inverse. D’un point de vue purement pragmatique, le bienfondé de la méthodologie proposée ici pour ce projet particulier apparaît comme évident. Gageons que cette dernière reste réutilisable et adaptable à d’autres domaines de la supervision et de l’exploitabilité des systèmes, ce qui n’a pas pu être mis en place. Le formalisme imposé par une telle approche peut être perçu comme problématique. Dans les faits, quand il s’agit de projets aussi impactant que ceux de l’exploitabilité des systèmes, ce formalisme est loin d’être un luxe. De plus l’inertie de la méthode imposée par ces processus permet de soigner les pré-études et d’être rapidement performant et pertinent auprès des parties prenantes au projet. Pour visualiser clairement ce qui aura pu être mis en place au sein du chantier, il est proposé de projeter les activités réalisées sur la Map globale du projet.


94

Figure 5-1 : Évaluation empirique ; Map réelle

Comme le montre la Map ci-dessus, seules 9 stratégies sur les 15 proposées par cette méthode ont pu être mises en place au sein du projet. Concernant les intentions, 3 ont été réalisées sur les 5 de la méthode. Cela limite bien entendu la validation de cette dernière à un certain périmètre. Pourtant, la durée totale du projet étant estimée à 36 mois pour l’industrialisation de l’instance France, de tels résultats en 6 mois –le recueil des exigences effectué par le déclenchement de la stratégie S2 a en effet débuté fin février 2012 apparaissent comme clairement encourageants pour la poursuite du chantier. Passons maintenant à une évaluation objective basée sur les retours des parties prenantes au projet sur la méthodologie mise en œuvre.

Simon Joliet

95

5.2. Évaluation par les parties prenantes

Afin de qualifier la pertinence de la méthode pour guider le chantier de l’exploitabilité, mais d’un point de vue objectif cette fois, il est proposé d’évaluer les retours des parties prenantes au projet à fin de parcours. Cette évaluation a été réalisée à l’aide d’un questionnaire envoyé à 22 des parties prenantes au projet, parmi lesquelles 9 ont répondu. Le questionnaire comporte 12 questions et est joint en annexe (voir 6.13 Questionnaire d’évaluation Parties Prenantes en page 126). La structure utilisée présente une caractéristique intéressante, elle est en fait basée sur le même formalisme que celui utilisé pour le recueil des exigences (et donc est supportée par les 5 opérateurs clés, Améliorer, Introduire, Cesser, Étendre et Maintenir) Voici une synthèse sur les retours.

Q1 : Pensez-vous que cette méthode est plus à même de guider un chantier IHM qu’une expression de besoin initiale, suivi du cycle de développement classique (ingénierie de projet) ?

Réponse Décompte Pourcentage

Pas du tout 1 11,11%

Un peu 0 0,00%

Moyennement 4 44,44%

Beaucoup 4 44,44%

Selon les parties prenantes, la méthode s’est montrée très pertinente dans le chantier des IHM pour 44% (4) des sondés, assez pertinente pour 44% (4) et pas du tout pour 11% (1). C’est un résultat globalement satisfaisant bien qu’il semble que la méthode puisse être améliorée.

Q2 : Selon vous, a-t-il été pertinent de communiquer régulièrement sur l’avancement du projet ?


Oui 9 100,00%

Parfois 0 0,00%

Non 0 0,00%

Sans réponse 0 0,00%

11%0%

45%

44%

Pas du tout Un peu Moyennement Beaucoup

100%

0% 0%0%

Oui Parfois Non Sans réponse


96

Il a été décidé pour ce projet de communiquer le plus possible et avec un maximum d’acteurs, ce de manière régulière. Pour 100% (9) des parties prenantes, ceci est une bonne approche. � : Le concept d’impliquer régulièrement et un maximum de parties prenantes doit donc être retenu dans la méthode.

Q3 : Pensez-vous que dans l’ensemble, le fait de se baser sur les exigences pour piloter le projet a apporté une plus-value ?


Oui 5 55,55%

Parfois 4 44,44%

Non 0 0,00%


A la question de la pertinence d’utiliser les exigences comme pilote du projet, les résultats sont partagés puisque 55% (5) des parties prenantes estiment que cela a toujours été pertinent, quand 44% (4) estiment que cela a parfois été pertinent. Note : aucune partie prenante n’estime que cela n’a jamais été pertinent.

Q4 : Est-ce que la structure utilisée pour la tenue des réunions (présentation des travaux effectués, présentation des travaux à venir, ordre du jour, suivi des exigences) a été pertinente ?


Très pertinent 4 44,44%

Plutôt pertinent 5 55,55%

Pas pertinent 0 0,00%


Les réunions effectuées dans le cadre du projet suivaient un canevas précis. Les avis sont partagés entre les sondés puisque 55% (5) indiquent que ce canevas est très pertinent quand quasiment la même proportion (4) indique que celui-ci est plutôt pertinent. Un commentaire indique de plus qu’il est parfois difficile de voir en cela la réalisation concrète

56%

44%

0% 0%


44%

56%

0% 0%

Très pertinent Plutôt pertinentPas pertinent Sans réponse

Simon Joliet

97

du projet. Il est de plus remarqué que les changements étaient plus facilement acceptés par les utilisateurs dans la mesure où ces derniers étaient impliqués aux décisions. � : Pour la suite de la méthodologie, il semble primordial de conserver et d’améliorer ce formalisme. Ensuite, l’accent doit être mis sur les démonstrations afin de montrer des réalisations concrètes autant que faire se peut.

Q5 : Selon vous, la durée des réunions fixée à 1 heure 30 est-elle suffisante, trop importante ou pas assez importante ? Si trop ou pas assez, pourquoi ?


Pas assez longue 0 0,00%

Bonne durée 9 100%

Trop longue 0 0,00%

Sans réponse 0 0,00% La durée des réunions a été fixée à 1h30. Pour 100% (9) des parties prenantes, cette durée a été jugée comme suffisante. Un commentaire indique que cette durée est bien adaptée au nombre des participants (soit entre 10 et 20). Cette durée serait certainement revue à la hausse ou à la baisse en fonction d’une évolution du nombre de participants.

� : Pour la suite de la méthodologie, il faut privilégier une conservation de cette durée.

Q6 : Selon vous, la fréquence des réunions fixée à 2 semaines est-elle suffisante, trop importante ou pas assez importante ? Si trop ou pas assez, pourquoi ?


Trop importante 0 0,00%

Satisfaisante 9 100% Pas assez importante 0 0,00%

Sans réponse 0 0,00% La fréquence des réunions était fixée à deux semaines. Pour 100% (8) des parties prenantes, cette fréquence a été jugée satisfaisante.

� : Pour la suite de la méthodologie, il est donc décidé de conserver cette fréquence.

0%

100%

0%0%

Pas assez longue Bonne duréeTrop longue Sans réponse

0%

100%

0%0%

Trop importante SatisfaisantePas assez importante Sans réponse


98

Q7 : A votre avis, cette méthode pourrait être pertinente dans d’autres chantiers que celui des IHM ?


Oui 6 66,67%

Parfois 2 22,22%

Non 1 11,11%

Sans réponse 0 0,00% Un point clé de la méthode proposée est de pouvoir piloter les chantiers de l’exploitabilité, c'est-à-dire pas seulement la conduite d’un chantier de renouveau d’IHM, mais aussi pour tout projet attenant aux stratégies de supervision et d’exploitation d’un système. Il a ainsi été demandé aux parties prenantes d’évaluer la généricité de cette méthode. Pour 66% (6) des sondés, cette méthode aurait d’une part un intérêt à être utilisée dans un autre contexte. Pour 22% (2) des sondés, la méthode pourrait parfois avoir un intérêt dans d’autres contextes. Enfin, pour 11% (1) des sondés, cette méthode n’apporterait pas de plus-value dans d’autres cas que ce chantier.

Q8 : Selon vous, que faut-il absolument maintenir dans la méthode ? Selon les sondés, un certain nombre de points doivent être conservés dans la méthode mise en œuvre. Majoritairement, c’est le dialogue régulier entre concepteur et utilisateur qui est plébiscité. Le fait de se baser sur les exigences et de produire un prototype de manière itérative sont tous deux vus comme des concepts phares à la méthode, à conserver.

Q9 : Selon vous, que faut-il absolument améliorer dans la méthode ? Pour les sondés, un certain nombre de points doivent être améliorées. Tout d’abord, la priorisation des exigences n’a pas été perçue par tous. Ensuite, une demande d’avoir systématiquement une maquette par choix conceptuel a été formulée. Enfin, certains sondés souhaiteraient arriver plus rapidement à un prototype quand d’autres désireraient que les utilisateurs soient associées au projet encore plus tôt.

Q10 : Selon vous, que faut-il absolument introduire dans la méthode ? Selon certaines parties prenantes, il semblerait utile de mettre en corrélation les propositions fonctionnelles formulées lors de la mise en œuvre conceptuelle, avec de véritables données de production.

67%

22%

11%

0%


Simon Joliet

99

Q11 : Selon vous, que faut-il absolument cesser (supprimer) dans la méthode ? Pour certaines parties prenantes, il faudrait cesser de présenter des concepts (maquettes ou développements) tant qu’ils ne sont pas mûrs. Un autre point consisterait à ne pas expliquer la méthode utilisée aux parties prenantes si celle-ci est complexe, comme cela aura parfois été perçu.

Q12 : Selon vous, avec quelles autres méthodes celle-ci devrait être étendue ? Il est proposé par les parties prenantes de coupler la méthode par une analyse des impacts et des écarts sur l’existant. D’autres parties prenantes souhaiteraient que l’analyse des exigences soit couplée à une analyse des besoins. L’évaluation de la méthode par les utilisateurs sondés retourne globalement un bon niveau d’adhérence de leurs parts. Il existe bien sûr quelques heurts rendant la méthode perfectible aux yeux des intervenants, mais les avantages qu’elle aura procuré pour ce projet lui sont en grande partie reconnus. Du reste de tels retours sont très positifs ; gageons de surcroît qu’il est difficile d’évaluer une méthode utilisée à partie.


100

5.3. Bilan et perspectives

Si la méthodologie proposée a pu guider efficacement le projet, il serait très intéressant d’un point de vue pragmatique de suivre cette dernière de bout en bout pour l’ensemble du projet et pas seulement pour une partie. La démarche dirigée par les exigences et le fait de produire un grand nombre de livrables intermédiaires est un atout considérable apporté par la méthode. Dans le cadre des chantiers importants où le processus de capitalisation de connaissances n’est pas négligeable, le fait de posséder un gisement d’exigences unique et de consigner l’ensemble des maquettes et des scénarios facilite le commissionnement et le décommissionnement de ressources, le tout à moindre coût. De plus, la réunion de fin de sprint permet rapidement à des parties prenantes non initiées au projet de comprendre très rapidement les enjeux de l’ensemble du chantier, le tout en peu de temps. Toujours par rapport à cette méthodologie, le fait de la rendre compatible avec SCRUM offre de nombreux avantages, dont le plus important est en toute franchise, l’utilisation d’une méthode populaire et reconnue dans l’industrie. Il est pourtant primordial de ne pas céder aux sirènes de la SCRUMmania ; SCRUM est d’abord tout sauf une panacée. Ensuite, les méthodes Agiles ne sont pas synonymes de développements bâclés, de documentation inexistante et de rentabilité maximum. C’est un outil proche du lean management certes, où la notion de qualité est fondamentale. Il est quoi qu’il en soit délicat d’appliquer SCRUM dans une organisation ayant recours uniquement aux méthodes classiques, dans ce cas la mise en place d’un chantier pilote s’avère souvent être une bonne approche. Un problème inhérent aux méthodes Agiles, est qu’il n’est pas toujours évident de communiquer sur un produit en cours de réalisation. Les méthodes classiques n’imposent des points de synchronisation sur l’avancement qu’à certains moments clés comme les passages de jalons, ou encore à la livraison finale du produit. S’il est communément admis que le fait de présenter un produit uniquement avant sa livraison est une mauvaise pratique, il n’est pas non plus évident d’utiliser un produit en cours de réalisation comme support de présentation. Il peut exister une incompréhension de la part des parties prenantes, c’est pourquoi il est primordial de toujours rappeler lors des réunions de sprint que les travaux présentés sont partiels et que les autres aspects fonctionnels seront opérationnalisés ultérieurement. Un des avantages majeurs de SCRUM –qui contribue d’ailleurs très certainement à sa grande popularité, est justement le fait de n’imposer finalement que très peu de formalisme. Il s’agit en fait d’un simple framework qui impose un pattern de processus à respecter, mais qui en soi n’impose aucune contrainte sur le processus en lui-même, ni sur les objets manipulés par ce processus (comme les backlog ou les stories). De fait, il est tout à fait possible que deux projets appliquant SCRUM à la lettre en aient une approche finalement très différente, ce qui est plutôt positif quant à la flexibilité potentielle par rapport aux projets. Il serait tout de même intéressant d’ouvrir le processus de conduite du chantier à

Simon Joliet

101

d’autres méthodes Agiles telles que XP ou encore RUP, et de faire finalement l’abstraction de la méthode retenue, à l’instar de la technologie. Ensuite, la méthode ayant été mise en pratique pour conduire un chantier de renouveau d’IHM, il serait intéressant d’observer dans quelle mesure cette dernière serait pertinente dans d’autres contextes d’exploitation, encore une fois dans le cadre d’une démarche empirique.


102

5.4. Conclusion

Les solutions proposées, tant sur le volet moyens –via l’état de l’art– que sur la partie méthode, se sont donc révélés performantes pour piloter le chantier de renouveau d’IHM sur un périmètre circonscrit. Concernant la partie moyens, celle-ci bien qu’exhaustive, pourrait être étendue à d’autres types de progiciels d’une part, et à d’autres paradigmes du génie logiciel. Bien entendu cette méthode –comme toute méthode reste perfectible. Une seule mise en pratique de cette dernière ne semble cependant pas suffisante pour tirer de conclusion générale, d’autant que l’ensemble des stratégies de cette dernière n’ont pas pu être mises en place. D’une manière générale, il est important de noter que l’utilisation des méthodes Agiles n’apporte pas toujours les meilleures réponses organisationnelles aux structures. En effet à l’instar de certaines méthodes Agiles, ce qui est proposé ici n’est qu’un cadre qui devra être adapté dans une optique de réutilisation aux spécificités d’un autre projet. En suivant cette considération, la méthode ne doit pas être vue comme un processus formalisé, mais plutôt comme un framework méthodologique permettant de piloter le chantier spécifique de l’exploitation. Les concepts méthodologiques n’étant connectés entre eux que par le biais d’artefacts de projets formalisées, les différentes approches sont complètement indépendantes les unes des autres. Elles peuvent ainsi être remplacées à souhait par d’autres, potentiellement plus pertinentes dans un autre contexte. Ainsi et en guise de conclusion, ce mémoire aura permis de démontrer qu’il est possible de composer une méthode de conduite de projet sur mesure, à base d’ingénierie des exigences et d’approches dirigées par les scénarios, le tout au sein de cycles Agiles. Les méthodes communiquent entre elles par le biais des livrables qu’elles produisent et qu’elles consomment, en abstraction complète des autres approches satellites. Le fait de coupler différentes méthodes permet en cas de réussite, de tirer parti efficacement des avantages de chacune. En décorellant moyens et méthodes, la solution propose enfin d’apporter une couche d’abstraction garantissant la généricité des solutions mises en œuvre dans le cadre de cette étude, autorisant de fait sa réutilisation.

Simon Joliet

103


104

6. ANNEXES

Il est proposé au sein des annexes de suivre certains raisonnements développés au sein du projet « IHM Platine » à titre d’illustration de points particuliers, soulevés par la mise en pratique de l’état de l’art et de la méthodologie formalisée précédemment.

6.1. Réflexions sur la couche transactionnelle

Mesurer les contraintes liées au dialogue (entre le cœur de produit, la passerelle SOAP et les IHM actuelles) ; voir si cet élément serait impacté ou non par le chantier.

Couche

d’interface

Couche

présentation

Couche

métier Figure 6-1 : Architecture actuelle simplifiée

L’architecture actuelle autorise une communication efficace entre le cœur de métier et les IHM. Cependant, le périmètre du chantier impactant la présentation des données, il peut être intéressant d’observer si et dans quelle mesure, la couche d’interface actuelle pourrait être améliorée. L’implantation actuelle possède certains désavantages notamment sur ces derniers points :

• Les données sont récupérées à la volée, directement au sein de la classe d’affichage des IHM. Il n’y a pas –dans les IHM de séparation entre la gestion du protocole et celle de l’affichage des données.

• La sémantique nécessaire pour envoyer des requêtes au sein des IHM et pour comprendre les réponses de la couche métier est dupliquée entre les deux parties.

• Les requêtes envoyées et reçues sont sérialisées par cette sémantique sous un format binaire via un mécanisme de sérialisation propriétaire, ce qui est vraisemblablement un héritage de l’architecture historique Corba.

• Les services transactionnels sont limités entre le métier et la présentation (une dizaine seulement). Ces derniers sont de niveau technique et non métier ou fonctionnel. Les stratégies d’extraction de l’information ne sont valables que pour les IHM actuelles, les données étant remontées panneau par panneau.

• Les échanges sont soit synchrones (exploitation), soit asynchrones (supervision) et les informations sont remontées à la couche transactionnelle soit en mode pull

Simon Joliet

105

(pour les compteurs), soit en push (pour les notifications d’état de la couche métier, comme le démarrage ou l’arrêt du serveur de supervision).

La redéfinition de cette couche d’interface impliquerait soit une urbanisation, soit une séparation de la partie transactionnelle et de la partie présentation des données. Globalement, voici ce qu’il faut en retenir : l’utilisateur, par le biais des IHM, affiche un panneau. Le code de ce panneau implique la réception d’informations de la couche métier. La requête est sérialisée côté IHM et celle-ci est envoyée à la passerelle SOAP. Un identifiant de requête est alors généré, la requête sérialisée est ensuite envoyée au métier et l’identifiant de requête est retournée aux IHM. Ceci est valable en mode asynchrone seulement. Côté métier, la requête est désérialisée, exécutée, puis le résultat est de nouveau sérialisé et envoyé à la passerelle. Celle-ci réceptionne la réponse et l’associe à la session de l’IHM ainsi qu’à l’identifiant de la requête initiale. La réponse est stockée dans une pile en attendant l’appel de la couche de présentation. La couche de présentation envoie des requêtes à la passerelle jusqu'à ce qu’une réponse associée à l’identifiant de requête retourne un résultat. La passerelle renvoie alors la réponse métier sérialisée, qui est dès lors désérialisée par les IHM, puis intégrée aux éléments graphiques côté applet Java. L’échange est modélisé par le diagramme de séquence suivant.

Session

Couche de présentation:Applet Java

Couche transactionnelle:Passerelle SOAP

Couche Métier:Base de données

Émettre requête passerelle

Recevoir identifiant réponse

Emettre requête métier

Recevoir réponse métierÉmettre requête passerelleavec identifiant réponse

Exécution requête métier

Afficher panneau

Sérialiser requête panneau

Désérialiser requête métier

Recevoir réponse

Désérialiser réponse

Afficher réponse

Panneau affiché

Sérialiser réponse

Figure 6-2 : Diagramme de séquence du dialogue « IHM/Métier » actuel (dialogue asynchrone)

La communication est plutôt lourde, mais ce n’est pas vraiment un problème au niveau de la performance de l’ensemble. Par contre, l’asynchronisme et la nécessité de conserver les


106

identifiants de requête est potentiellement un mécanisme à revoir en cas de modification de la couche transactionnelle. Cette stratégie de dialogue n’est pas sans posséder quelques avantages en cas de transaction longue (ce qui est souvent le cas), elle est de plus très bien adaptée au multi-thread et surtout, elle ne bloque pas les appels client. Cependant le point le plus problématique sur cette partie protocolaire est les sérialisations et les désérialisations successives, nécessaires à l’envoi et la réception des requêtes. Ce formalisme est logiquement dupliqué côté présentation (en Java) et côté Métier (C++). Le problème est que l’ajout –par exemple, d’un nouveau panneau de supervision ou d’une nouvelle fonction métier implique systématiquement ces deux modifications. Les stratégies de dialogue entre les couches est extrêmement pauvre. Si la robustesse de l’échange est certaine, la plus-value apportée par la solution et l’évolutivité qu’elle autorise est trop faible pour servir de base à tout projet très impactant. Ce point sera clairement un problème pour toutes les évolutions ciblant le métier et les IHM.

6.1.1. Redéfinition de la couche transactionnelle

Proposition d’architecture selon les bonnes pratiques de l’urbanisation des systèmes (Longépé C., 2009)

Figure 6-3 : Architecture cible urbanisée

La meilleure solution en termes d’architecture consisterait ainsi à redéfinir non seulement la couche de présentation, mais aussi la couche d’interface (transactionnelle) associée. La redéfinition de la couche d’interface permettrait de faciliter le développement de la couche de présentation. En effet actuellement, les transactions passent par un nombre limité de services et la sémantique est codée en dur dans la couche métier comme dans la couche présentation (par le biais du fichier synoptique.dat). Il en résulte une architecture certes efficace, mais peu maintenable. Une bonne solution consisterait à définir une couche d’interface exposant un certain nombre de services, tantôt spécialisés, tantôt génériques. Cette nouvelle architecture impacterait fortement l’existant, notamment sur la partie métier. Si la refonte de la couche d’interface est une solution à long terme, il n’en demeure pas moins que le coût de développement de celle-ci ne sera pas négligeable.

Avantages Inconvénients Meilleure solution en termes d’architecture Développement ultérieur facilité

Coût de développement non négligeable Impacte potentiellement la couche métier

Simon Joliet

107

Tableau 6-1 : Avantages et inconvénients d’une nouvelle architecture fonctionnelle

6.1.2. Conservation en l’état de la couche transactionnelle

Voici une solution hybride, finalement retenue dans le cadre de la première opérationnalisation.

Figure 6-4 : Solution intermédiaire

Une solution intermédiaire consisterait à laisser la couche d’interface en l’état et de développer une couche transactionnelle intermédiaire entre la couche d’interface et la couche de présentation. L’objectif serait de pouvoir intégrer le modèle de données à moindre effort au sein de la couche de présentation. Le remplacement ultérieur de la couche d’interface constituerait une étape cruciale pour la pérennité et la maintenance du produit. Le remplacement de cette couche transactionnelle temporaire se ferait de fait à moindre effort.

Avantages Inconvénients Rapidement opérationnalisable Remplacement couche transactionnelle

Capitalisation faible sur développement Pauvreté des informations disponibles

Tableau 6-2 : Avantages et inconvénients d’une architecture fonctionnelle hybride

6.1.3. Conclusion des réflexions sur la couche transactionnelle

La manière et la sémantique de remontée de l’information est certes efficace, mais relativement pauvre et assez contraignante. La conservation de cette couche en l’état ne serait pas sans poser problème dans la mesure où celle-ci ne présente que peu de services et en tout cas, aucun d’intérêt fonctionnel. Cela conviendrait dans un premier temps ; à terme il n’est pas certain que toutes les informations nécessaires au chantier soient présentes en base. Dans ce cas une modification de la partie métier serait potentiellement nécessaire pour afficher toute information non présente actuellement dans les IHM. Le problème est que les modifications côté métier sont d’une part à éviter pour le prototype et d’une autre que d’éventuelles modifications perdraient en portée lors de la mise en œuvre, de par la pauvreté de l’échange métier/interface. Garder en l’état cette couche de communication n’est pas une solution valable à long terme. Mais sur les IHM, il est par contre primordial de séparer les requêtes métier de leurs affichages dans les applets Java.


108

6.2. Réflexions sur la mise en place de maquettes

Définir des maquettes permettant de représenter l’information (Look) en se basant sur les exigences de DECI, les solutions de supervision et d’exploitation existantes et les bonnes pratiques de l’ergonomie.

En intégrant les retours déterminés par les grands principes fonctionnels, l’enjeu consiste maintenant à intégrer ces derniers principes afin de déterminer de nouvelles stratégies de supervision sur l’existant.

6.2.1. Interface actuelle

Avant toute chose, voici un aperçu de l’organisation des éléments sur l’interface de supervision :

Figure 6-5 : Wireframe de l’interface actuelle

� : Nom de la plateforme – volet – Heure courante (Figé) : affiche les informations

courantes de la plateforme actuelle. � : Alarmes (Figé) : Contient trois options concernant les alarmes :

• « Alarmes » : affiche toutes les alarmes du système dans un nouvelle fenêtre.

• « Voir fenêtres d’alarmes » : affiche la fenêtre d’alarme.

Simon Joliet

109

• « Fermer fenêtre alarmes » : ferme la fenêtre d’alarme. � : Commande et options (Figé) : Contient 5 commandes :

• « Couleur » qui permet de changer la couleur de fond des IHM (afin de repérer par exemple des supervisions d’instances différentes sur une même machine…).

• « ECC Arbo… » qui permet de modifier la stratégie d’organisation des arborescences.

• « Versions… » qui permet d’afficher les versions des modules de l’applicatif. • « Exploitation » qui permet de passer de l’IHM de supervision à l’IHM

d’exploitation (fonctionne uniquement si l’IHM d’exploitation est déjà lancée).

• « Quitter » qui termine la session de supervision en cours. � : Navigation (Figé) : représente actuellement le découpage de plus haut niveau du système

(Platine, Médiation active, Collecte…). Les alarmes sont affichées en rouge sur l’élément en défaut et en orange s’il s’agit d’une information.

� : Arborescence (Facultative) : représente la sous-arborescence si celle-ci existe, de l’élément parent sélectionné dans �.

� : Vue : affiche les compteurs ou la vue courante spécifiée par les éléments � et �. � : Éléments en anomalie (Dynamique) : recense les éléments en anomalie héritant de

l’élément courant (� et �). Actuellement, la navigation s’effectue à l’aide des éléments � et �. Le contenu de l’arborescence � dépend en effet de l’entité Navigation � sélectionné. Par contre, l’arborescence n’est pas toujours présente. Pour certains éléments en effet, l’élément � n’est pas présent et est remplacé par une plus grande vue �. Du reste, l’interface n’est pas homogène en fonction de l’élément sélectionné dans la navigation �, ce qui doit cesser. [#3 #4] En règle générale, le zonage fonctionnel n’est pas satisfaisant sur l’existant, par exemple via certains éléments regroupant des actions de niveau fonctionnels inégaux. C’est notamment le cas de l’élément � avec la commande « Couleur », ou encore l’élément � avec le panneau « Connexions ». Ces deux éléments ne sont pas par exemple dans une zone cohérente au vu de leurs niveaux fonctionnels.

6.2.2. Interface projetée

L’exercice proposé est donc de prendre en compte les problématiques des interfaces actuelles, tout en réorganisant les éléments en fonctions de leurs rôles, niveaux fonctionnels et stratégies d’interaction. Les lois de Gestalt et le principe de l’affordance permettraient une réorganisation efficace de l’interface actuelle d’un point de vue fonctionnel. Les représentations ne tiennent pas compte de la mise en œuvre ; celle-ci peut se faire bien évidemment indépendamment de la technologie retenue. Voici à titre illustratif, un zonage fonctionnel répondant potentiellement à ces derniers critères :


110

Navigationet

Arborescence

Vue

Alarmes

Informations et commandes générales

Onglets

Chemin

Figure 6-6 : Interface projetée

� : Informations et commandes générales Cet élément reprendrait les informations générales présentées dans les interfaces actuelles [#9]. Il devrait idéalement présenter les informations de connexion de l’utilisateur, les paramètres généraux des interfaces ainsi que les stratégies d’accès à d’autres ressources (autres IHM, aide contextuelle [#34]…), etc. � : Navigation et arborescence Il est nécessaire de conserver l’arborescence en l’état, ce qui est imposé par les exigences [#6 #103]. Cependant, il peut paraître intéressant de fusionner les notions de navigation et d’arborescence, qui sont actuellement fortement imbriquées. La notion d’alarme doit être apportée à ce nouvel élément [#72] comme sur l’existant. � : Onglets

Les onglets permettraient, en fonction du module sélectionné dans l’élément �, d’offrir un point de vue différent (facette) en fonction de la supervision souhaitée [#27 #119]. Le type d’onglet disponible est dépendant du rôle de l’utilisateur et de l’implantation faite par l’intégrateur pour l’instance [#44]. Les différentes facettes potentielles seront décrites dans le modèle de données (chapitre 5). � : Chemin

Cet élément fournirait une nouvelle stratégie d’accès aux entités. En effet et contrairement à l’existant, il serait souhaitable que la navigation se fasse de différentes manières, donc pas seulement à l’aide de l’élément � [#3 #24].

Simon Joliet

111

� : Vue Dans cette proposition, le vue serait fonction de la sélection de l’élément � et de l’élément � (les onglets). Celle-ci est de plus liée au chemin spécifié par �. Par rapport à l’existant, cet élément offrirait de plus grands niveaux d’interaction, comme par exemple [#36]. Autre ajout, la possibilité d’avoir des vues paramétrables par utilisateurs et par élément [#38]. � : Alarmes Au lieu de présenter les éléments en anomalies, cette interface projetée présenterait des alarmes, contextuelles ou non, ce qui resterait à définir. Les libellés d’alarmes et les opérations à entreprendre doivent être plus clairs que sur l’existant, ce qui pourrait nécessiter une redéfinition de ces dernières [#61].

6.2.2.1. Instanciation du zonage fonctionnel

A titre d’illustration, voici comment le zonage fonctionnel pourrait être instancié en intégrant un ensemble d’exigences corrélées.

Figure 6-7 : Exemple d’intégrations des exigences fonctionnelles dans l’interface

[1 Les feuilles constituent les fonctionnalités atomiques qui peuvent être des

applications ou des flux. La remontée est effective dans les arborescences par le biais d’une coloration de l’élément.

[2 Les regroupements de feuilles (dossiers) constituent les îlots et les blocs fonctionnels. Ces regroupements sont bien entendu autant d’éléments supervisables.


112

[3 Le niveau supérieur de l’arborescence est constitué des quartiers fonctionnels.

[4 Le second niveau correspond aux cinq zones fonctionnelles de Platine. [5 Le niveau racine constitue l’instance métier et mène de fait au synoptique

global de l’instance. [6 Première partie de l’entête, (voir � : informations générales) [#9]. [7 Permet d’accéder à l’élément parent ; dans ce cas par exemple, il s’agirait

de passer de Q_Traitement à Z_Core [#23]. [8 Affichage de la date et de l’heure comme sur l’existant [#9]. [9 Indique le login de l’utilisateur authentifié sur l’IHM (informations

récupérés sur le cœur de métier) [#9]. [10 Déconnection ou passage sur un autre volet. [11 Accès aux options de second plan (couleurs, connexions…). [12 Barre d’onglets, supervision en fonction d’une facette [#27]. [13 La barre d’adresse permettant d’accéder rapidement à un élément [#24]. [14 La fenêtre centrale offre des stratégies d’accès aux éléments présentés. Ici,

la supervision présentée est dite par flux, elle est donc fonctionnelle et non technique.

[15 Info bulle ; cet élément permettrait d’afficher les informations de base d’un élément : articles en entrée, articles en sortie, articles en cours, divers et alarmes [#39 #62]. Zoom, notion à définir [#3]. Alarmes à intervention immédiate. Alarmes à intervention différée.

Simon Joliet

113

6.3. Réflexions sur le modèle de données

Définir un modèle de données sur le périmètre du prototype, mais en prévenant l’évolution de ce modèle à tout le produit à moyen/long terme.

La clé du projet est de développer un modèle de généricité entre les différents éléments supervisés. L’effort apporté à cette généricité apporterait une plus-value conséquente aux développements futurs. Historiquement, le développement de chaque panneau de la supervision de Platine aura été le fruit des besoins directs du métier. Le problème de ce développement est que sa mise en place n’aura pas été l’occasion de définir une homogénéité de la supervision. En revanche, cet effort a été porté sur la médiation active. De fait, les retours sur ce volet semblent très pertinents pour notre chantier. Dans notre cas, il s’agirait d’offrir une vision fonctionnelle –et non plus technique du système supervisé. Pour la médiation active, les panneaux génériques proposent les informations suivantes : articles en entrée, articles en sortie, articles en cours, divers. Ce mode de supervision présente un avantage significatif pour représenter l’ensemble du système sous forme de flux. Voir la proposition du modèle de données page suivante.


114

Figure 6-8 : Première proposition d’un modèle de données pour le chantier Platine

Annexes Simon Joliet

115

6.4. Méta modèle global des entités et des méthodes de projet

SystèmeTOBE

1..*

1..*

Développe

1

1

Supporte

Prototype

1

1..*

Est

composé de

Macro Développement

1..*

1..*Développe

0..*

1

Composée

par

Corps1..*1

Défini par

Technologie

1..*

1

Valide

0..*

1Nécessite

0..*

1Réutilise

1..*

1..*

Utilise

1..*

1

Défini

Scénario

10..*Propose

1..*1Rédige

0..*

1

Composée

par

Contenu1..*1

Décrite par

Scénario fonctionnel

Macro-design

OR

Partie prenante

Développeur

Forme

1..*

1

Possède

1..*

1

Valide1

1..*

Définit

Durée de vie

1..*

1

Possède

But

1..*

1

Possède

AND/OR

Opérateur11..*

Formalisée par

Maintenir Cesser IntroduireAméliorer Etendre

0..*

1..*

0..* 0..* 0..* 0..*

Exigence

1

0..*

Propose

1..*

1

Concerne

Priorité* 1

Possède

0..*

1..*

Composée

par

Corps

*

1

Décrite par

Stratégique Applicative

Opérationnelle

OR

Identifiant

Niveau

0..*

1..*Raffiné

par

1 *Caractérisé par

1

* Repérée par

SystèmeASIS

1

1..*

Génère

Approches dirigées par les

scénarios

Entités communesEKD-CMM

Ingénierie des exigences SCRUM

Légende

Figure 6-9 : Méta modélisation globale des entités du projet


116

6.5. Carte Mentale globale du projet

Figure 6-10 : Carte mentales globale des concepts utilisés dans le projet


117

6.6. Extrait du gisement d’exigences

Id Auteur Niveau Val. *Opérateur *Cible Paramètres *Commentaire

4 Exploitant Opérationnel OK Introduire des commandes sur les éléments du synoptique

Avoir sur le synoptique des « boutons » (élément, groupe, serveur, instance...) ou "lien" entre ces éléments (file, liaison..) ; un clic droit avec un certain nombre de possibilités propres a l'objet (info alarme, info compteur, commandes spécifiques A/R ou autre --> écrans à définir ultérieurement).

11 Exploitant Fonctionnel OK Introduire dans l'interface principale

un cadre regroupant l'ensemble des commandes et des scripts

A droite par ex : se laisser un cadre « Outil » avec accès à l'ensemble des commandes ou scripts.

18 Exploitant Opérationnel OK Maintenir le bouton d'alarme

sur toutes les fenêtres, en fonction du niveau

Sur toutes les fenêtres, alarmes se rapportant au niveau où l’utilisateur se trouve.

19 Exploitant Fonctionnel OK Améliorer la représentation

du synoptique à ce qui est supervisé

En adéquation avec ce qui est supervisé (BIE, PRIMS, GOUROU, Platine,...) ; gestion dynamique; ne faire apparaître que l'existant voir feuille « DétailExploit » pour les propositions et/ou les propositions synoptiques (fichiers joints).

45 Exploitant Fonctionnel OK Améliorer les temps de réponses

de la visualisation Optimiser les temps de réponse (ex supervision pop-up déconnection).

49 Exploitant Opérationnel OK Cesser l'affichage du module de retraitement

En effet le module de retraitement n’est actuellement plus utilisé.

51 Exploitant Fonctionnel OK Améliorer les délais d'acquittement

des alarmes L'acquittement des alarmes est trop long (de 10 à 20 secondes).


118

52 Exploitant Fonctionnel OK Améliorer la fiabilité des IHM Les timeout sur les IHM sont trop fréquents et obligent à arrêter et relancer les IHM.

58 Exploitant Opérationnel OK Introduire une notion de tri

insensible à la casse Quel que soit la liste, pouvoir trier par ordre alphabétique sans respecter la casse.

59 Exploitant Opérationnel OK Introduire la personnalisation

du synoptique Pouvoir développer un synoptique à la demande pour un besoin ponctuel. Exemple : suivre le changement de palier sur 1 GSN.

65 Exploitant Fonctionnel OK Introduire la personnalisation

des arborescences Pouvoir modifier les arborescences de manière dynamique.

66 Exploitant Opérationnel OK Introduire l'affichage du décalage horaire

pour les EEC hors métropole

Pouvoir afficher le décalage horaire pour les EEC hors métropole.

81 Exploitant Opérationnel OK Introduire une vue regroupant l’information des lots en anomalie de retard

Besoin d’une vue qui regroupant l’information des lots en anomalie de retard/Niveau IECC. En effet, si les lots ne sont pas envoyés, alors il y a un problème.

90 Exploitant Opérationnel OK Améliorer l'aide des commandes Apporter une aide contextuelle sur les commandes.

108 Skill Center

Stratégique OK Introduire une IHM light pour les besoins AMEA

Offrir la possibilité de superviser le produit de manière synthétique, de la même manière qu'un tableau de bord, pour satisfaire les besoin AMEA. Voir en quoi cela peut être une plus-value pour les instances historiques.

Tableau 6-3 : Extrait de 14 exigences du gisement mis en place pour le projet Platine


119

6.7. IHM historique de l’application Platine

Figure 6-11 : IHM du module de collecte des IHM historique de Platine (v4)


120

6.8. Exemple de maquette fil de fer

Figure 6-12 : Maquette présentant le nouveau principe fonctionnel « Supervision par synoptique »


121

6.9. Exemple de maquette ergonomique

Figure 6-13 : Maquette ergonomique présentant le principe fonctionnel « Supervision par synoptique »


122

6.10. Exemple d’Interface Homme Machine prototypée

Figure 6-14 : Une itération du prototype des nouvelles IHM Web de Platine


123

6.11. Règles des réunions Agiles

Afin d’atteindre ses objectifs, la tenue des réunions Agiles doivent être garantie. Pour cela, le formalisme suivant tendra à être respecté dans la mesure du possible.

• L'ordre du jour de la réunion doit être clair. • Si les membres de l'équipe démarrent une discussion sans rapport avec l'objectif de la

réunion, les membres devront reprendre cette discussion plus tard dans un autre contexte. Le ScrumMaster doit identifier et indiquer le moment où les membres de l'équipe doivent poursuivre une discussion dans un autre contexte.

• Toutes les réunions doivent suivre la structure de base décrite pour cette réunion. • Les réunions doivent démarrer à l'heure, même si certains membres de l'équipe sont

en retard. • Les membres de l'équipe doivent être à l'heure sauf dans les rares cas inévitables. Si

votre planification vous empêche d'être à l'heure régulièrement, le conflit doit être résolu dès que possible. Si nécessaire, le ScrumMaster doit adapter l'heure de la réunion pour résoudre le conflit si le changement ne dérange pas indûment un autre membre de l'équipe.

• Chaque membre de l'équipe doit venir à la réunion préparé. • Les réunions doivent finir à l'heure. Dans la plupart des cas, la longueur de la réunion

est déterminée par la durée du sprint. Par exemple pour le projet Platine, une heure et demie apparaît comme suffisante pour un sprint de deux semaines.

• La méthode SCRUM applique cette structure de réunion à un niveau qui peut ne pas convenir à certaines personnes. Cette réaction est causée par l'exigence de ponctualité, la responsabilité vis à vis de ses pairs liée au fait de prendre et de tenir des engagements, et la transparence requise pour une participation active.

(Aubry C., 2011)

6.12. Réunion Agile type

Pour conceptualiser la tenue d’une réunion agile type pour ce type de chantier, voici un exemple de structure d’une réunion type. Il s’agit dans les faits de la troisième réunion Agile du cycle de développement, en date du 29 juin 2012. Au cours de cette réunion, huit nouvelles exigences ont été apportés au chantier.

1. Travaux effectués et à venir 2. Les retours du Workshop Sénégal 3. Nouvelles exigences AMEA78 4. Nouvel élément : «Diagnostic» 5. Nouvel élément : «Journal de Bord»


124

6. Présentation des maquettes 7. Suivi des exigences

En voici une version plus détaillé pour information : 1. Travaux effectués et à venir

• Invariant : à chaque réunion est présenté la liste des tâches effectuées depuis le dernier point, et les tâches à lancer pour la suite. Exemple dans le cas de la réunion n°2 :

Tâches effectuées Tâches à démarrer

• Présentation et intégration de Sonatel au sein du chantier

• Synchronisation interne suite au workshop Sénégal

• Développement de nouvelles maquettes

• Développement de deux nouveaux éléments : « Diagnostic » et « Journal de Bord »

• Poursuite et validation du développement des maquettes [SKC & Ergonomes]

• Poursuite des développements de l’application web

Tableau 6-4 : Diapositive type « Tâche effectuées / Tâches à démarrer »

2. Retours du Workshop Sénégal

• Le chantier a été présenté à de nouvelles parties prenantes, il s’agit de l’instance

Sonatel au Sénégal. Le ScrumMaster présente ainsi les retours.

3. Nouvelles exigences AMEA

• 8 nouvelles exigences sont ajoutées au gisement suite au retour du workshop, et sont donc présentées aux participants de la réunion. Ces exigences sont repérées par leur identifiant unique (#xxx), et suivent le formalisme imposé par le canevas mis en œuvre.

#141 Introduire des IHM légères #142 Introduire des IHM exploitables avec peu de ressources #143 Améliorer la vérification de l'étanchéité #144 Introduire un outil de traçabilité #145 Introduire une supervision multi-instance #146 Introduire une visualisation des éléments en anomalies quelle que soit l'instance #147 Introduire un traçage des éléments via un journal de bord #148 Introduire des tableaux de statistiques #149 Introduire un élément de diagnostic

4. Nouvel élément « Diagnostique »


125

• L’élément « Diagnostic » est un macro-design conceptualisant l’exigence #149 5. Nouvel élément : «Journal de Bord»

• L’élément « Journal de Bord » est un macro-design conceptualisant l’exigence #147

6. Présentation des maquettes • Présentation en temps réel d’une maquette réalisée par les ergonomes du

chantier, montant les IHM sur la base des exigences précédemment validées. 7. Suivi des exigences

• Ici, le ScrumMaster expose toutes les exigences sur lesquelles les efforts ont été portés au cours du dernier sprint Agile. En l’occurrence pour le point n°2 :

#9 : Introduire des informations générales dans l'entête #26 : Améliorer l'affichage du synoptique de manière dynamique #34 : Introduire la notion d'aide #31 : Améliorer la gestion de l'espace dans les écrans #33 : Améliorer la pertinence et nommage des compteurs #36 : Améliorer les tableaux de compteurs

• Il est ensuite demandé aux intervenants de valider les travaux présentés portant sur ces exigences. Si celles-ci sont validées, elles seront développées. Sinon, elles seront conceptualisées dans de nouvelles maquettes, puis repasseront une étape de validation lors d’un sprint suivant.


126

6.13. Questionnaire d’évaluation Parties Prenantes

Il est proposé ici de rédiger un canevas permettant de capturer les retours des parties prenantes quant à l’implantation de la méthode utilisé dans le cadre du chantier Chantier IHM Platine. Ce questionnaire a été mis à disposition des parties prenantes pendant environ un mois, via le service www.mon-enquete-en-ligne.fr.

Questionnaire d’évaluation Parties Prenantes Dans le cadre de mon mémoire, j’ai documenté une partie de la méthodologie que j’ai mise en place afin de guider le processus de projet. Je souhaiterais évaluer la compréhension et l’efficacité de la méthode pour le chantier des IHM. Aussi j’aimerais qu’un maximum de personnes ayant participé de près ou de loin au chantier et qui ont assisté au moins à une réunion, puissent répondre à ces 12 questions. Le projet a été mené jusque-là via un processus de projet hybride, utilisant les méthodes Agiles (SCRUM) couplé à une méthode de l'ingénierie des besoins (Requirement Engineering), ainsi qu’une approche dirigée par les scénarios (Maquettes et Macro-Designs).

--Simon Il y a 12 questions dans ce questionnaire. Ce questionnaire est anonyme.

Principal Q1: *Pensez-vous que cette méthode est plus à même de guider un chantier IHM qu’une expression de besoin initiale, suivi du cycle de développement classique (ingénierie de projet) ?

Veuillez sélectionner seulement une réponse ci-dessous :

Pas du tout Un peu Moyennement Beaucoup

Q2: *Selon vous, a-t-il été pertinent de communiquer régulièrement sur l’avancement du projet ?


Oui Parfois


127

Non Autre (Précisez)

Q3: *Pensez-vous que dans l’ensemble, le fait de se baser sur les exigences pour piloter le projet a apporté une plus-value ?


Oui Parfois Non Autre (Précisez)

Q4: *Est-ce que la structure utilisée pour la tenue des réunions (présentation des travaux effectués, présentation des travaux à venir, ordre du jour, suivi des exigences) a été pertinente ?

Veuillez sélectionner une réponse ci-dessous:

Très pertinent Plutôt pertinent Pas pertinent

Veuillez saisir votre commentaire ici :

Q5: *Selon vous, la durée des réunions fixée à 1 heure 30 est-elle suffisante, trop importante ou pas assez importante ? Si trop ou pas assez, pourquoi ?

Veuillez sélectionner une réponse ci-dessous:

Pas assez longue Bonne durée Trop longue

Veuillez saisir votre commentaire ici : Q6: *Selon vous, la fréquence des réunions fixée à 2 semaines est-elle suffisante, trop importante ou pas assez importante ? Si trop ou pas assez, pourquoi ?

Veuillez sélectionner seulement une réponse ci-dessous

Trop importante Satisfaisante Pas assez importante Autre (Précisez)

Q7: *A votre avis, cette méthode pourrait être pertinente dans d’autres chantiers que celui des IHM ?

Veuillez sélectionner seulement une réponse ci-dessous


128

Oui Parfois Non

Q8: Selon vous, que faut-il absolument maintenir dans la méthode ? Q9: Selon vous, que faut-il absolument améliorer dans la méthode ? Q10: Selon vous, que faut-il absolument introduire dans la méthode ? Q11: Selon vous, que faut-il absolument cesser (supprimer) dans la méthode ? Q12: Selon vous, avec quelles autres méthodes celle-ci devrait être étendue ?

Envoyer votre questionnaire. Merci d'avoir complété ce questionnaire.

RÉfÉrences Simon Joliet

129

7. RÉFÉRENCES

7.1. Index des figures

Figure 3-1 : Synoptique des trois sous ensemble inhérents à la supervision ....................................................................... 17

Figure 3-2 : Arbre des méthodes de diagnostic ......................................................................................................................... 19

Figure 3-3 : Diagramme de flux, problématique de la maintenance ..................................................................................... 19

Figure 3-4 : Proposition d’architecture associée à un monitoring réseau ............................................................................ 30

Figure 3-5 : Proposition d’architecture associée à une supervision industrielle ................................................................ 38

Figure 3-6 : Proposition d’architecture associée à une solution spécifique binaire ........................................................... 47

Figure 3-7 : Proposition d’architecture associée à une solution spécifique binaire ........................................................... 59

Figure 3-8 : Synoptique de synthèse, solutions off the shelf contre développement spécifique ..................................... 63

Figure 3-9 : Arbre de solutions de l’état de l’art ........................................................................................................................ 64

Figure 4-1 : Workflow de plus haut niveau, définissant la position de la méthodologie ................................................. 66

Figure 4-2 : Modèle de transition du système existant au système cible en utilisant les exigences ................................ 67

Figure 4-3 : Modèle de transition et chaînage des méthodologies utilisées ........................................................................ 69

Figure 4-4 : S1, Modélisation de découverte des exigences par processus Top-Down ..................................................... 71

Figure 4-5 : S2, Modélisation de découverte des exigences par processus Bottom-Up .................................................... 72

Figure 4-6 : La vision des sprints SCRUM selon Mike Cohn................................................................................................ 74

Figure 4-7 : Extension du schéma de Mike Cohn par une approche dirigée par les exigences ....................................... 75

Figure 4-8 : Méta-modélisation des exigences ........................................................................................................................... 78

Figure 4-9 : Exemple de taxonomie des exigences .................................................................................................................... 79

Figure 4-10 : Méta-modélisation des exigences opérationnelles et des 5 opérateurs du changement........................... 82

Figure 4-11 : Méta-modélisation du scénario ............................................................................................................................ 85

Figure 4-12 : Processus de rédaction du scénario ..................................................................................................................... 86

Figure 4-13 : Méta-modélisation du macro-développement ................................................................................................. 88

Figure 4-14 Processus de macro développement ...................................................................................................................... 89

Figure 4-15 : Méta modélisation de l’industrialisation ........................................................................................................... 91

Figure 5-1 : Évaluation empirique ; Map réelle ......................................................................................................................... 94

Figure 6-1 : Architecture actuelle simplifiée ............................................................................................................................ 104

Figure 6-2 : Diagramme de séquence du dialogue « IHM/Métier » actuel (dialogue asynchrone) .......................... 105

Figure 6-3 : Architecture cible urbanisée .................................................................................................................................. 106

Figure 6-4 : Solution intermédiaire ........................................................................................................................................... 107

Figure 6-5 : Wireframe de l’interface actuelle ......................................................................................................................... 108

Figure 6-6 : Interface projetée ..................................................................................................................................................... 110

Figure 6-7 : Exemple d’intégrations des exigences fonctionnelles dans l’interface ......................................................... 111

Figure 6-8 : Première proposition d’un modèle de données pour le chantier Platine .................................................... 114

Figure 6-9 : Méta modélisation globale des entités du projet .............................................................................................. 115

Figure 6-10 : Carte mentales globale des concepts utilisés dans le projet.......................................................................... 116

Figure 6-11 : IHM du module de collecte des IHM historique de Platine (v4) ............................................................. 119

Figure 6-12 : Maquette présentant le nouveau principe fonctionnel « Supervision par synoptique » .................... 120

Figure 6-13 : Maquette ergonomique présentant le principe fonctionnel « Supervision par synoptique »............ 121

Figure 6-14 : Une itération du prototype des nouvelles IHM Web de Platine .............................................................. 122


130

7.2. Index des tableaux

Tableau 3-1 : Axe d’amélioration, maintenance corrective et prédictive ............................................................................ 21

Tableau 3-2 : Avantages et inconvénients de la solution Nagios .......................................................................................... 25

Tableau 3-3 : Avantages et inconvénients de la solution Zabbix .......................................................................................... 25

Tableau 3-4 : Avantages et inconvénients de la solution Centreon ..................................................................................... 26

Tableau 3-5 : Avantages et inconvénients de la solution OpenNMS .................................................................................. 27

Tableau 3-6 : Avantages et inconvénients de la solution Openview NMMi ..................................................................... 27

Tableau 3-7 : Benchmark des solutions de monitoring réseau .............................................................................................. 29

Tableau 3-8 : Avantages et inconvénients des technologies de supervision réseau ........................................................... 32

Tableau 3-9 : Benchmark des solutions de monitoring industriel ........................................................................................ 36

Tableau 3-10 : Avantages et inconvénients des technologies de monitoring industriel .................................................. 37

Tableau 3-11 : Avantages et inconvénients des solutions sur étagère .................................................................................. 39

Tableau 3-12 : Technologies Middleware .................................................................................................................................. 41

Tableau 3-13 : Avantages et inconvénients des technologies Middleware ......................................................................... 42

Tableau 3-14 : Avantages et inconvénients des Webservices Restfull ................................................................................. 45

Tableau 3-15 : Avantage et inconvénients des applications binaires ................................................................................... 48

Tableau 3-16 : Avantages et inconvénients du Framework Zend ........................................................................................ 49

Tableau 3-17 : Avantages et inconvénients du Framework Symfony .................................................................................. 50

Tableau 3-18 : Benchmark des Framework Zend et Symfony .............................................................................................. 50

Tableau 3-19 : Avantages et inconvénients du Framework Struts ....................................................................................... 51

Tableau 3-20 : Avantages et inconvénients du Framework Spring MVC .......................................................................... 52

Tableau 3-21 : Benchmark des Framework Struts et Spring MVC ..................................................................................... 52

Tableau 3-22 : Avantages et inconvénients des Framework de développement Web ..................................................... 55

Tableau 3-23 : Benchmark des technologies JSP et PHP ....................................................................................................... 55

Tableau 3-24 : Synthèse comparative des technologies JSP et PHP .................................................................................... 56

Tableau 3-25 : Liste des Framework Javascript ......................................................................................................................... 57

Tableau 3-26 : Avantages et inconvénients du Framework Google Web Toolkit ........................................................... 58

Tableau 3-27 : Avantages et inconvénients du Framework Dojo Toolkit ......................................................................... 59

Tableau 3-28 : Avantages et inconvénients des applications Web ........................................................................................ 60

Tableau 3-29 : Avantages et inconvénients du développement spécifique ......................................................................... 61

Tableau 3-30 : Comparatif qualitatif des solutions sur étagère et du développement spécifique ................................. 63

Tableau 4-1 : Description de la stratégie : Processus du projet de l’exploitabilité de haut niveau................................. 71

Tableau 4-2 : Description de la stratégie S1 : Découverte des exigences par processus Top-Down ............................. 72

Tableau 4-3 : Description de la stratégie S2 : Découverte des exigences par processus Bottom-Up ............................ 73

Tableau 4-4 : Comparatif des approches Top-Down et Bottom Up .................................................................................. 73

Tableau 4-5 : Description des niveaux d’exigences .................................................................................................................. 77

Tableau 4-6 : Descriptif du méta modèle des exigences .......................................................................................................... 78

Tableau 4-7 : Descriptif du méta-modèle des exigences opérationnelles ............................................................................ 82

Tableau 4-8 : Descriptif du méta modèle des scénarios .......................................................................................................... 86

Tableau 4-9 : Description de la stratégie S6 : Par rédaction du scénario ............................................................................ 87

Tableau 4-10 : Descriptif du méta modèle des macro-développements .............................................................................. 89

Tableau 4-11 : Description de la stratégie S9 : Par macro développement ......................................................................... 89

Tableau 4-12 : Descriptif du méta modèle de l’industrialisation .......................................................................................... 91

Tableau 6-1 : Avantages et inconvénients d’une nouvelle architecture fonctionnelle ................................................... 107

Tableau 6-2 : Avantages et inconvénients d’une architecture fonctionnelle hybride .................................................... 107

Tableau 6-3 : Extrait de 14 exigences du gisement mis en place pour le projet Platine ................................................. 118

Tableau 6-4 : Diapositive type « Tâche effectuées / Tâches à démarrer » ...................................................................... 124


131

7.3. Bibliographie

Aubry C., 2011 : Scrum : Le guide pratique de la méthode agile la plus populaire - 2ème edition, Dunod, 304p

Ben Achour C. et al., 1999 : Guiding Requirement Engineering with a Process Map, Fourth IEEE International Symposium on Requirements Engineering, University of Limerick, 15p

Etinkaya E. K., 2001 : Reliability Analysis Of SCADA Systems Used In The Offshore Oil And Gas Industry, Faculty of the Graduate School of the University Of Missouri-Rolla, 75p

Faiz Bashir M., 2009 : Google Web Toolkit (GWT) and Java EE, Center for Advanced Software Engineering (CASE) Faculty of Computer Science and Information System Universiti Teknologi Malaysia, 88p

Hearn D., 2009 : Enterprise architecture Evolving to succeed, Deloitte, Deloitte & Touch House, Earlsfort Terrace, Dublin 2, 12p

Hennion N., 2011 : Introduction à Nagios – Nicolargo, 65p

Hernández De León, H. R., 2006 : On-Line

Monitoring And Diagnosis Of

Potable Water Production Processes,

Laboratoire d'Analyse et

d'Architecture des Systèmes du CNRS,

Université de Toulouse, 163p

Hurter C., 2010 : Characterization of

Visualizations and Interactive

Exploration of Large Quantity of

Multidimensional Data, Institut

Supérieur de l’Aéronautique et de

l’Espac, Université de Toulouse, 190p

Imanache D. et al, 2004 : Nouvelles Technologies Réseau – Nagios, Ingénieurs 2000, Université de Marne la Vallée, 26p

Juhász B., 2009 : Developing M2M Applications With Mango – JAMK University of Applied Sciences, 42p

Longépé C., 2009 : Le projet d'urbanisation du système d'information – Démarche pratique avec cas concret, Dunod, 290p

Machacek, J. et al, 2008. Pro Spring 2.5, Apress, 920p

Menet, L. 2008 : Enrichissement sémantique de méta modèles XML et UML pour une transformation bidirectionnelle de modèles – Laboratoire d’Informatique et Communication), Université Paris 8, 16p

Morley C., 2008 : UML 2 pour l'analyse d'un système d'information - Le cahier des charges du maître d'ouvrage, Dunod, 232p

Moro A., 2010, Les Framework au cœur des applications Web - Haute Ecole de Gestion de Genève (HEG), 128p

Nurcan S. et al, 2003 : A Multi-Method for Defining the Organizational Change, Centre de Recherches en Informatique – Université Paris I Panthéon-Sorbonne, 35p

Oudot C., 2005 : Introduction à Cacti – Linagora Paris, 40p

Ralyté J., Rolland C., 2001 : An assembly process model for method engineering, Centre de Recherches en


132

Informatique – Université Paris I Panthéon-Sorbonne, 24p

Rolland C, et al, 1999 : A Multi-Model View of Process Modelling, Centre de Recherches en Informatique – Université Paris I Panthéon-Sorbonne, p. 169-187

Rolland C., 1999 : A goal driven approach to modelling COTS acquisition impacts – Centre de Recherches en Informatique – Université Paris I Panthéon-Sorbonne, p. 8

Rolland C et al., 1996 : A Proposal For A Scenario Classification Framework, Centre de Recherches en Informatique – Université Paris I Panthéon-Sorbonne, 44p

Sadovykh A., 2005 : Innovative Middleware

Concept for Supervision of Complex

Systems, EADS SPACE

Transportation, Université Paris VI,

107p

Temple C., 2004 : Monitoring de serveurs avec Zabbix - Université des Sciences et Technologies de Lille, 29p

Vilemaitis M., 2011 : HP Network Node Manager 9: Getting Started - Chapter No.1 "Before we Manage with NNMi", 39p

Wiberg K., 2006 : Identifying Supervisory Control And Data Acquisition (SCADA) Systems On A Network Via Remote Reconnaissance, Naval Postgraduate School, Monterey, California, 147p


133

7.4. Webographie

Bartol N., 2012 : Serveur Web d'applications PHP - Outils de développement PHP - Formations PHP - Zend.com <http://www.zend.com/fr/>

Bhaskar J., 2012 : Google Web Toolkit – Google Developers <https://developers.google.com/web-toolkit/>

Chong, L., 2012 : Meetings (Agiles) <http://msdn.microsoft.com/fr-fr/library/dd997582.aspx>

Galstad E., 2011 : Nagios - The Industry Standard In IT Infrastructure Monitoring And Alerting <http://www.nagios.org/>

Germusk J., 2012 : Welcome <http://struts.apache.org/>

Gutmans A., 2011 : Home Centreon <http://www.centreon.com/>

Ivanova E., 2011 : Linux SCADA :: SCADA/HMI for Linux platform reviews, <http://linuxscada.info>

Ivanova E., 2011 : SCADA World - all world SCADA systems / HMI Interface, [compare price, choose, links, download information], <http://scadaworld.org>

Jan O., 2012 : Supervision, monitoring, métrologie, capacity planning à la sauce Open Source | Communauté Francophone de la Supervision Libre <http://www.monitoring-fr.org>

Johnson R., 2012 : SpringSource.org | <http://www.springsource.org/>

Potencier F., 2012 : Symfony | Web PHP Framework <http://www.symfony-project.org/>

Russell A., 2012 : Unbeatable JavaScript Tools - The Dojo Toolkit <http://dojotoolkit.org/>

Ryals A., 2011 : HP Network Node Manager i software | HP Software <http://www8.hp.com/us/en/software/software-product.html?compURI=tcm:245-936950>


134

7.5. Glossaire

1 MDE : Model Driven Engineering ;

Ingénierie dirigée par les modèles 2 Off The Shelf : Solutions sur étagère 3 Framework : Kit de composants logiciels

structurels servant à créer tout ou partie d'un logiciel

4 ACP : Analyse en Composante Principale ; méthode d’analyse statistique de données

5 Affordance : capacité d’un objet à suggérer sa propre utilisation

6 SNMP : Simple Network Management Protocol ; protocole de communication permettant de gérer et de superviser des équipements réseau

7 ICMP : Internet Control Message Protocol. Utilisé pour véhiculer des messages de contrôle et d'erreur

8 SCADA : Supervisory Control And Data Acquisition ; télésurveillance et acquisition de données

9 GNU : système d’exploitation libre lancé en 1984

10 GPL : Licence publique générale de distribution des logiciels libres

11 QoS : Quality of Service ; Qualité de service

12 SMS : Short Message Service ; Service de messagerie

13 CPU : Central Process Unit ; Le processeur physique

14 HTTP : HyperText Transfer Protocol ; protocole de communication client-serveur développé pour le World Wide Web

15 Front end : Point d'entrée uniformisé pour des services différents

16 SLA : Service Level Agreement ; document

qui définit la qualité de service requise entre un prestataire et un client

17 AGPL : Affero General Public License ; licence libre dérivée de la Licence publique générale GNU avec une partie supplémentaire couvrant les logiciels utilisés sur le réseau

18 MIB : Management Information Base, base d'information pour la gestion du réseau utilisé dans SNMP

19 Traps SNMP : type de PDU utilisé pour signaler un événement asynchrone comme une alerte ou autre autour d'un sous-système de gestion

20 OS : Operating System ; Système d’exploitation

21 IHM : Interface Homme-Machine ; outils de contrôle et de communication entre un système et son utilisateur

22 IDE : Integrated Development Environment ; Environnement de développement logiciel intégré

23 OLE : Object Linking and Embedding ; protocole et système d'objets distribués, distribué par Microsoft

24 TCP : Transmission Control Protocol ; protocole de transport fiable en mode connecté

25 UDP : User Datagram Protocol ; protocole de transport en mode non connecté

26 ASCII : American Standard Code for Information Interchange ; norme de codage de caractères en informatique la plus ancienne

27 BIN : fichier exécutable binaire compilé 28 IP : Internet Protocol ; protocole de

communication fondamental de la suite des protocoles internet,

29 M2M : Machine to Machine, systèmes de communications entre machines sans intervention humaine.


135

30 J2EE : Java Enterprise Edition,

spécification Java particulièrement destinée aux applications d’entreprise

31 Client lourd : Logiciel qui propose des fonctionnalités complexes avec un traitement autonome

32 Client léger : Machine dédiée à l’architecture client-serveur, n’aillant presque aucune logique applicative

33 MVC : Modèle-Vue-Contrôleur ; paradigme d’organisation d’une application en couches

34 Middleware : Logiciel tiers créant un réseau d'échange d'informations entre différentes applications informatiques

35 RPC : Remote procedure call ; protocole d'appel de procédures à distance

36 DCOM : Distributed Component Object Model ; technique de Microsoft permettant la communication entre des composants logiciels distribués

37 CORBA : Common Object Request Broker Architecture ; architecture logicielle pour le développement de composants et d’ORB

38 EJB : Enterprise JavaBeans ; Architecture de composants logiciels côté serveur pour la plateforme de développement JEE.

39 JMS : Java Message Service ; interface de programmation Java

40 Webservices : Programme informatique permettant la communication et l'échange de données entre applications et systèmes hétérogènes

41 REST : REpresentational State Transfer ; manière de construire une application pour les systèmes distribués (à l’instar de SOAP)

42 .NET : Ensemble de produits informatiques de Microsoft pour rendre des applications facilement portables sur Internet

43 SOAP : Simple Object Access Protocol ;

protocole RPC orienté objet bâti sur XML permettant la transmission de messages entre objets distants

44 SOA : Service Oriented Architecture ; forme d'architecture de médiation qui met en œuvre des services

45 JSON : JavaScript Object Notation ; Format de données textuel héritant de la notation JavaScript

46 AJAX : Asynchronous Javascript and XML ; Manière de faire communiquer des applications Web de manière dynamique

47 URI : Uniform Resource Identifier ; Courte chaîne de caractères identifiant une ressource sur un réseau

48 PHP : Hypertext Preprocessor ; Langage de scripts libre utilisé pour produire des pages dynamiques via serveur HTTP

49 JSP : JavaServer Pages ; technique basée sur Java qui permettant aux développeurs de créer des pages web dynamiques

50 API : Application Programming Interface ; interface fournie par un programme informatique

51 ORM : Object-Role Modeling ; démarche et formalisme de modélisation conceptuelle de bases de données

52 JMX : Java Management Extensions ; API Java permettant de gérer le fonctionnement d'une application en cours d'exécution

53 JDBC : Java DataBase Connectivity ; API de connexion à une base de données pour les programmes Java

54 DAO : Data Access Object ; objet permettant l'accès aux données d’une base

55 BDD : Base de Données 56 ODBC : Open Database Connectivity ;

logiciel middleware qui permet à une application informatique de se connecter à une base de données


136

57 Rich Internet Application : Application

Internet riche ; Application Web qui offre des caractéristiques similaires aux logiciels traditionnels

58 Flash : Logiciel multimédia utilisé pour créer des graphiques vectoriels et des bitmap animés

59 Silverlight : Framework d’application internet riche de Microsoft (équivalent de Adobe Flash)

60 WPF : Windows Presentation Foundation est la spécification graphique de Microsoft .NET 3.0

61 MIT (licence) : Licence de logiciel utilisée notamment pour la diffusion du gestionnaire de fenêtre X11

62 BSD (licence) : Licence libre utilisée pour la distribution de logiciels

63 Bytecode : Code intermédiaire plus proche des instructions machines que le code source, exécutable par machine virtuelle

64 HTML : Hypertext Markup Language, Langage de balisage utilisé pour représenter les pages web

65 CSS : Cascading Style Sheets ; langage informatique pour la présentation des documents HTML

66 Modèle en cascade : Cycle de développement traditionnel où tout le processus du chantier est formalisé au préalable et les tâches sont exécutés dans un ordre bien établi

67 Cycle en V : Amélioration du modèle en cascade permettant en cas d'anomalie, de limiter un retour aux étapes précédentes

68 Méthodes Agiles : Groupe de méthodes itératives ou incrémentales, permettant de réagir au changement des besoins et impliquant plus efficacement les utilisateurs dans les développements

69 RUP : Rational Unified Process ; Méthode de développement pour les logiciels orientés objets (itérative)

70 Map : Modélisation permettant la

représentation de plusieurs façons de conduire un processus d'ingénierie

71 EKD-CMM : Enterprise Knowledge Development - Change Management Method ; Démarche méthodologique permettant de guider une activité de modélisation du changement organisationnel

72 SCRUM : Méthode Agile incrémentale permettant de prendre en charge une production planifiée. Scrum autorise l'affinement itératif des exigences lors des cycles de développement

73 Sprint : Incrément de projet durant généralement deux semaines, terminé par une démonstration des travaux réalisés

74 ScrumMaster : animateur d'une équipe qui applique Scrum

75 UML : Unified Modeling Language, ; langage graphique de modélisation des données et des traitements d’un système

76 KPI : Key Performance Indicator ; indicateurs de performance clés, indicateurs mesurables permettant l’ide décisionnelle.

77 CREWS : Projet du centre de recherche de Paris I dont l’objectif est de mettre en place et d’évaluer des outils de l’ingénierie des besoins

Documents

Mémoire M2 MIAGE SIC 2012 - Simon Joliet