Le modèle du cycle de vie d’un Système d’Information identifie invariablement la séquence des tâches suivantes :
– l’analyse et la spécification, – le développement,
– l’exploitation et la maintenance de l’application.
Il nous semble original de décliner ces trois temps par rapport à deux points de vue ; celui du client et celui de l’éditeur. Un client cherche à acquérir une solution informatique pour faciliter la gestion de son entreprise. Il doit délimiter le périmètre d’action du logiciel et expliquer ses méthodes de gestion à l’intérieur de ce périmètre afin de mettre le logiciel en adéquation avec ses besoins. Toutefois, l’expérience montre que cette recherche d’adéquation est un exercice délicat : les méthodes de gestion de l’entreprise (§ 2.1.1) ne sont pas forcément facilement explicables, ou encore l’examen des méthodes standard codées dans le logiciel peuvent être considérées comme une meilleure façon de procéder pour l’industriel. Dans ce dernier cas, c’est alors l’entreprise qui doit s’adapter à de nouvelles méthodes et se mettre en adéquation avec le logiciel. Une autre source de difficulté peut provenir d’un manque de couverture du logiciel vis-à-vis des besoins de l’entreprise, ce que l’on désigne sous le terme de « trou fonctionnel ». Ce type de situation, qui est connu, conduit l’éditeur à proposer le développement d’un code spécifique intégrable à la solution standard pour être en adéquation avec le besoin.
La complexité des problèmes rend délicate l’écriture du cahier des charges. La part d’incerti- tude doit être minimisée dans la spécification détaillée du développement pour le client avant le prototypage. Les projets de ce type sont réputés non linéaires dans le sens ou plusieurs itérations entre la phase d’analyse et de spécification, et celle de développement, peuvent être nécessaires pour atteindre un bon niveau de qualité.
Un éditeur de logiciel doit maîtriser le développement de son produit. Le cycle de vie du produit se renouvelle suivant les trois phases évoquées (début du § 9.1) pour chaque version du logiciel.
Il faut distinguer, d’une part, le cycle de vie de l’application cliente, et d’autre part, le cycle de développement de l’application par l’éditeur (§ 6.2.1). Ce dernier correspond à un ensemble d’étapes (analyse, développement, documentation, contrôle/test et validation) permettant de développer une application « globale » répondant à un ensemble de besoins des clients installés
136 CHAPITRE 9. CADRE DE RÉFÉRENCE
(étant dans un contexte de maintenance évolutive) ou à installer (étant dans un contexte de déploiement d’une nouvelle version du produit). Pour l’éditeur, le caractère générique du logiciel est primordial. Chaque application client doit être déduite de l’application générique avec un minimum de développements spécifiques. C’est ce que l’on appelle le paramétrage qui doit constituer l’essentiel de la charge des services techniques.
Chaque nouvelle version doit assurer une non régression pour les applications installées. Elle doit aussi offrir des services nouveaux pour couvrir des attentes de clients sur des besoins non satisfaits auparavant. Ces nouveaux services sont perçus de plusieurs façons :
– factorisation des développements spécifiques, – effets de mode en gestion,
– adaptation de méthodes existantes.
Spécification Développement Exploitation
Cahier des charges ME ME ME
Outil MR MR MR
Tab. 9.1 – Correspondance Modèle d’Entreprise - Modèle de Référence
Sur le tableau 9.1, nous émettons l’hypothèse que les deux protagonistes sont en phase sur une période correspondant à la gestion d’une version stabilisée pour un client donné. Chaque client peut avoir une valeur de période différente. Nos travaux étudient les apports d’une coexistence entre un modèle de l’entreprise côté client et un modèle de l’application côté éditeur. Cette correspondance de modèles est utile sur les trois étapes du déroulement du projet et de la relation client/éditeur. Pour chaque étape, nous allons mettre en évidence la spécificité des apports d’une telle démarche, sur la base de l’expérience acquise auprès de notre partenaire industriel.
9.1.1 Analyse et spécification
L’étape d’analyse et de spécification est une phase de collecte d’informations. Ces informations sont nécessaires pour proposer une solution adaptée aux besoins du client.
9.1.1.1 Côté client
Actuellement, la démarche d’analyse de l’éditeur auprès du client est la suivante : – description du mode de fonctionnement de la structure client,
– expression des besoins,
– étude de l’adéquation des besoins avec la solution logicielle, – récupération des données existantes.
Nous souhaitons standardiser cette démarche et soutenir les chefs de projet à l’aide de do- cuments normalisés. Le modèle d’entreprise propre au client sera développé au moyen d’un formalisme complet et adapté. Par capitalisation et retour d’expérience, il sera possible d’ex- traire des classes de modèles représentant des profils types de clients.
9.1.1.2 Côté éditeur
Nous considérons que le modèle de l’application existe chez l’éditeur. Si, de plus, ce modèle est basé sur un formalisme compatible avec le modèle d’entreprise, la pré-configuration de l’application se trouve facilitée. Cela signifie que :
– les descriptions des produits, des coûts et des procédés sont possibles par le logiciel, – certains processus de gestion peuvent être repérés comme des fonctions programmées du
logiciel.
Il y a donc naturellement possibilité d’imaginer des procédures de transition du modèle de référence de la solution logicielle vers le modèle d’entreprise pour assister la pré-configuration. De manière symétrique, des procédures de transition du modèle d’entreprise vers le modèle d’application mettront en évidence les Trous Fonctionnels Potentiels (TFP) et poseront les bases du développement d’applications spécifiques.
À la suite de cette analyse détaillée, il faut bâtir le paramétrage de l’application et coder les développements spécifiques. Cette pré-configuration de l’application cliente va permettre d’alimenter la grille de paramétrage et de faire le développement.
9.1.2 Développement
La généricité de l’application côté éditeur se concrétise par une facilité de paramétrage (obte- nue par une base de données des paramètres). En d’autres termes, un certain nombre d’options permettant de caractériser les méthodes programmées, et donc les fonctionnalités disponibles, sont accessibles pour les techniciens chez l’éditeur. La partie du développement relative au paramétrage consiste à renseigner les valeurs de ces paramètres pour compléter la définition du modèle de l’entreprise cliente.
Puisque le développement est aussi une phase de travail sur les spécifiques, le modèle de référence permet de faciliter le travail d’intégration du nouveau code dans le code existant. À l’issue de cette activité de développement, nous allons pouvoir alimenter la grille de valida- tion. Cette grille de validation permet de tester la solution logicielle, incluant les développe- ments spécifiques, avec les jeux de test du client.
9.1.2.1 Côté client
Un client possède son propre mode de fonctionnement, son univers de discours. La collecte d’informations pour le paramétrage doit être menée avec une dépense minimale d’énergie. Le modèle d’entreprise, lorsqu’il est mis en regard du modèle de référence, permet de faire la correspondance entre les données et les méthodes de gestion, et les paramètres de la solution logicielle.
L’utilisation de certaines fonctionnalités du logiciel peut amener le client à modifier son or- ganisation et ses habitudes de gestion. La transition du modèle de référence vers le modèle d’entreprise permettra d’exprimer ces contraintes, et de faciliter la prise de décision du client sur la base d’un dialogue entre le client et l’éditeur.
Outre les valeurs des paramètres, l’existence du modèle d’entreprise permet de faciliter la mise au point de scénarios de tests qui serviront de validation pour la recette de l’application chez le client.
138 CHAPITRE 9. CADRE DE RÉFÉRENCE
9.1.2.2 Côté éditeur
Le modèle de référence du futur système généré à partir du modèle d’entreprise facilite la compréhension du projet par le développeur. L’équipe projet de l’éditeur a donc un moyen de médiation à travers le modèle de référence. La distribution des tâches se trouve normalement facilitée.
Si, au cours du développement, une difficulté surgit, le modèle d’entreprise peut être utilisé pour chercher à modifier le modèle de référence de manière transparente pour le client et en minimisant la casse.
9.1.3 Exploitation et maintenance
La phase d’exploitation et de maintenance concerne plus particulièrement les services per- sonnalisés qui peuvent être fournis au client par l’éditeur (maintenance hotline, maintenance préventive, maintenance évolutive).
9.1.3.1 Côté client
À l’aide de la grille de test et validation, nous avons une vision du modèle de la solution logicielle qui a été installée. Il est donc possible d’utiliser ces connaissances pour la formation des utilisateurs sur les modules installés, incluant les spécifiques du client.
Nous pouvons aussi, à l’aide de ces informations, fournir et maintenir une documentation personnalisée pour chaque client.
9.1.3.2 Côté éditeur
La grille de test et validation est une base de connaissance faisant office de référence dans le cas d’une assistance au client, ou pour une gestion de l’évolution de version plus aisée.
9.1.4 Synthèse
Nous synthétisons sur la figure 9.1 la coexistence des modèles d’entreprise et de référence de la solution, des deux côtés de la relation client/éditeur, fondement du projet.
Cette coexistence des deux modèles permet :
– de structurer le travail du projet en exploitant les possibilités de transition entre le modèle d’entreprise et le modèle de référence,
– d’obtenir un meilleur dialogue entre les experts métiers et les experts SI (Système d’In- formation),
– d’améliorer la qualité (délais, coûts et performance) globale de la relation entre les deux parties.
Fig. 9.1 – Mise en relation du modèle d’entreprise (côté client) et modèle de référence (côté éditeur)