Méthodologies de développement de logiciels de gestion

Transcription

1 Méthodologies de développement de logiciels de gestion P.-A. Sunier Juin 2012 / Février

2 Table des matières 1 Ingénierie des systèmes d information informatisés Evolution de l informatisation Les défis de l informatisation Pratique de l'ingénierie Cycle de vie Méthodes de développement de logiciels de gestion Pourquoi une ou des méthodes? Qu est-ce? Choisir une méthode Approches Recensement Positionnement Personnalisation Méthodes phares Portée des méthodes Approche classique ou fonctionnelle Préambule Vue globale du système d information Cycles de construction Dualité des données et des traitements Modélisation Approche orientée objets Préambule UP est piloté par les cas d utilisation UP est centré sur l architecture UP est itératif et incrémental Discussion Modélisation Cycle de vie Préambule Cycle de vie en cascade (Merise) Cycle de vie itératif Cycle de vie en spirale L informatisation de l entreprise 2/46 P-A. Sunier

3 3.5 Conclusion Liens Internet Bibliographie L informatisation de l entreprise 3/46 P-A. Sunier

4 1 Ingénierie des systèmes d information informatisés 1.1 Evolution de l informatisation L informatisation de l entreprise s est faite à partir des années 1960 pour les précurseurs (banques, assurances, agences gouvernementales ). A cette époque-là, il s agissait de réaliser des programmes informatiques susceptibles d automatiser des processus obéissant à des règles mécanistes (facturations, relevés, paie ). Au début de l informatisation, le retour sur investissement était facilement chiffrable; il s agissait «simplement» de mesurer l écart entre les coûts de l informatisation et l économie salariale réalisée en remplaçant des travailleurs par une solution informatique. Actuellement, la plupart des organismes ont réalisés ces automatismes 1, les bénéfices attendus sont donc beaucoup plus difficilement chiffrables; ce peuvent être des avantages concurrentiels, une réactivité accrue ou encore une meilleure connaissance (maîtrise) des processus de l organisation. Au début de l informatisation, le travail de programmation pouvait être très difficile et nécessiter un bagage intellectuel de haut niveau mais, la difficulté était dans la seule réalisation de l automate. Actuellement, la technologie a passablement gommé les difficultés liées aux activités de programmation; le problème des informaticiens s est déplacé au niveau de la compréhension et de la prise en compte 2 de la complexité des organismes et de leurs systèmes d information. Au début de l informatisation, le travail de programmation était essentiellement individuel. L informaticien n avait que peu de contact avec la maîtrise d ouvrage 3 ou avec les utilisateurs; la mode était encore au traitement par lot 4, les terminaux qui ont permis l interaction entre les utilisateurs et le logiciel ne sont apparus que plus tard. Actuellement, il n est plus envisageable de mener un projet d informatisation en solo; l informaticien doit savoir communiquer avec une multitude d intervenants, que ce soit la maîtrise d ouvrage, les utilisateurs ou ses collègues de la maitrise d œuvre, spécialistes de domaines spécifiques. [Pour plus de détails sur l évolution de l informatisation, voir le chapitre 7.2 du cours [1]] 1 Au gré de l évolution de la technologie, de nouveaux automatismes peuvent voir le jour avec leur cortège de licenciement et de difficultés sociales; à titre d exemple, nous pourrions citer : la lecture automatique du contenu d un caddy lorsque le client d un magasin présente sa carte de crédit et en conséquence, la suppression du travail de typage d articles des caissières. 2 La complexité, au sens des systèmes vivants sociaux, ne saurait être maîtrisée, elle ne peut être que constatée et intégrée dans les réflexions. [Pour plus de détails voir [2]] 3 maîtrise d ouvrage : donneur d ordre et en finalité c est la maîtrise d ouvrage qui va payer la maîtrise d œuvre pour la réalisation des objectifs du projet. 4 [DICMP-99] Traitement par lot ou batch Technique qui consiste à effectuer un traitement ou une série de traitement, en général très répétitif, sur une masse de données très importante. Ce type de traitement réclame généralement pas mal de temps et est programmé pour s effectuer en l absence de l utilisateur, au contraire du traitement temps réel, conversationnel, transactionnel ou interactif. L informatisation de l entreprise 4/46 P-A. Sunier

5 1.2 Les défis de l informatisation Pour relever les défis d un projet d informatisation, les acteurs du projet et surtout son pilote ou ses pilotes doivent disposer de larges compétences scientifiques, de culture générale, en gestion, en technologie et aussi et surtout en relations humaines. Ces nombreuses compétences doivent leur permettre de relever les défis de l informatisation de l entreprise, parmi lesquels, nous pouvons citer la nécessité de: connaître 5 les multiples métiers supportés par le système d'information et leurs interactions. Le comptable, le chef des ventes, les acheteurs, le chef d'atelier sont autant de clients d'un système d'information d'entreprise qui souhaitent être compris, disposer des fonctionnalités dont ils ont besoin et avoir accès, respectivement donner accès, à tout ou partie des processus et données utiles à d'autres services. maîtriser des technologies de plus en plus spécialisées. En effet, le temps de la seule compétence en programmation ne suffit largement plus; actuellement, et pour autant que le projet soit d'une portée tant soit peu stratégique, les professionnels ne pourront plus être des généralistes de l'informatique; ils devront former une équipe regroupant spécialistes de bases de données, de réseaux, de serveurs d'application, d'urbanisation, de stations de travail, etc. instaurer une communication efficiente entre les multiples personnes parties prenantes 6 du projet; au-delà de la seule communication, il s agit de s assurer que les personnes qui communiquent se comprennent et acceptent les différences d attentes, de perception ou encore de valeurs des uns et des autres au gré de leurs fonctions, parcours de vie, intérêts ou encore capacités. mettre en œuvre un projet dont les objectifs ne sont pas figés comme peut l être la construction d une maison lorsque les plans sont sanctionnés; mais, mettre en oeuvre un projet s inscrivant dans l incertitude du système d information de l entreprise qui est sujet à adaptation à chaque changement significatif au sein de l entreprise ou de son environnement. A chacun de ces changements, la maitrise d ouvrage ou les utilisateurs peuvent estimer inadéquat quelque chose qui était correct précédemment. La question alors n est pas de débattre sur les errements 7 de la maitrise d ouvrage ou des utilisateurs pour les uns ou de débattre de la rigidité 8 de la maitrise d œuvre pour les autres; la question est de savoir qu elles sont les incidences pour le projet et s il y a lieu de faire une adaptation qui en supporte les conséquences. s appuyer sur les expériences passées tout en ne perdant pas de vue la nature unique de chaque entreprise qui rend son système d information tout aussi unique, même si de multiples parties peuvent être identiques à celles d autres entreprises. Donc, chaque projet d informatisation est unique et comporte sa part d incertitude. Nous verrons comment l ingénierie du logiciel apporte une réponse issue des enseignements de l industrialisation dans un prochain chapitre; mais, dans l immédiat, nous présenterons les concepts d ingénierie. 5 Dans le sens de comprendre les tenants et aboutissants et non d en maîtriser les subtilités. 6 Qu elles aient un rôle de maîtrise d œuvre, d ouvrage ou d interlocuteur concerné par le projet. 7 Caricaturalement, l informaticien a tendance à dire ou penser : «Ces utilisateurs ne savent jamais ce qu ils veulent» 8 Caricaturalement, l utilisateur a tendance à dire ou penser : «Ces informaticiens ne font jamais ce dont on a besoin» L informatisation de l entreprise 5/46 P-A. Sunier

6 1.3 Pratique de l'ingénierie Tout comme pour l ingénierie et l ingénieur, nous trouvons dans la pratique et la littérature deux concepts très liés qui souvent se définissent l un l autre, d une part l ingénierie appliquée au domaine de l information et d autre part le génie logiciel 9. Quelques définitions de la littérature : [DICMP-99] Ingénierie de l information : Ensemble des méthodes et des techniques qui concernent l exploitation de l information dans l entreprise. [DICMP-99] Ingénierie informatique : Discipline qui englobe la construction des ordinateurs, la conception d applications et d architectures. [DICMP-99] Génie logiciel : Ensemble des techniques et des méthodes qui permettent la conception et le développement d applications informatiques. [I-13] Le génie logiciel (anglais software engineering) est une science de génie industriel qui étudie les méthodes de travail et les bonnes pratiques des ingénieurs qui développent des logiciels. Le génie logiciel s'intéresse en particulier aux procédures systématiques qui permettent d'arriver à ce que des logiciels de grande taille correspondent aux attentes du client, sont fiables, ont un coût d'entretien réduit et de bonnes performances tout en respectant les délais et les coûts de construction Est aussi appelée génie logiciel : l'ingénierie appliquée au logiciel informatique, l'activité par laquelle le code source d'un logiciel est spécifié puis produit. Le génie logiciel touche au cycle de vie des logiciels. Toutes les phases de la création d'un logiciel informatique y sont enseignées : l'analyse du besoin, l'élaboration des spécifications, la conceptualisation du mécanisme interne au logiciel ainsi que les techniques de programmation, le développement, la phase de test et finalement la maintenance. La notion de génie logiciel a été mentionnée pour la première fois à une conférence concernant la crise du logiciel en La crise du logiciel est une baisse significative de la qualité des logiciels dont la venue coïncide avec le début de l'utilisation des circuits intégrés dans les ordinateurs: l'augmentation de la puissance de calcul des ordinateurs a permis de réaliser des logiciels beaucoup plus complexes 10 qu'auparavant [BOU-95] pour devenir une réalité, le génie logiciel doit répondre à des critères définis par la science de l ingénieur, ou ingénierie, et permettre de pratiquer le professionnalisme de l ingénierie informatique selon les axes privilégiés suivants : o le respect des objectifs quantitatifs et qualitatifs de l objet à fabriquer et celui du niveau de service défini pour le système en ordre de marche, o la maitrise des coûts et des délais de production du logiciel tout en préparant sa maintenance et son évolution à des coûts prévisibles, 9 Le logiciel qu il soit de nature IS ou IT (systèmes d exploitation, réseaux, communications ) mais, sans la composante matériel. 10 Dans le sens mathématique du terme, c est-à-dire de difficulté de dénombrement [Voir [2]] L informatisation de l entreprise 6/46 P-A. Sunier

7 o l industrialisation 11 de tout ou partie des phases et des étapes des cycles de vie de pilotage et de vie du logiciel, avec prise en charge de ce qui est répétitif par des automatismes généralisés, o la garantie à l avance de la qualité du logiciel fabriqué au regard des critères définis dès le départ par les différents partenaires. [ IEEE-1] L'exercice du génie logiciel comprend des activités de planification, de conception, de création, d évaluation, de consultation, d établissement de rapports, de direction ou de surveillance, et de gestion de produits ou de procédés à fort contenu logiciel qui nécessitent l'application de principes d'ingénierie et mettent en cause la protection de la vie, de la santé, de la propriété, d intérêts économiques, du bien-être public ou de l environnement. En synthèse et en nous appuyant sur la définition que nous avons donnée de l ingénierie [0 - Ingénierie], nous proposons la définition suivante de l ingénierie des logiciels de gestion : L ingénierie des logiciels de gestion est l art de mener méthodiquement les actions pertinentes et nécessaires à transformer une idée souvent originale et/ou ambitieuse en un logiciel 12 ou, mieux, un service informatisé adéquat aux plans économique, social et environnemental. L aspect méthodique de l ingénierie des logiciels de gestion a fait et continue de faire l objet de nombreux travaux et propositions. Nous traiterons plus en détail (chapitre Erreur! Source du renvoi introuvable.) les principes méthodologiques et quelques méthodes significatives dans la suite du cours. 1.4 Cycle de vie La vision systémique du système d information informatisé et la mise en œuvre des principes d ingénierie amènent à considérer le logiciel 13 non pas seulement comme un objet existant mais, à l appréhender comme un objet «vivant», d où la notion de cycle de vie, en nous intéressant à lui depuis son inception à sa «mort» ou destruction en passant par sa gestation et son utilisation. 11 L auteur associe la pratique du génie logiciel à la mise en œuvre d ateliers de génie logiciel (AGL); les AGL sont des outils informatiques capables de générer du code à la place des programmeurs à partir de spécifications qui sont en général des modèles contenus dans un référentiel. 12 Produit immatériel. 13 Il en est de même pour les autres produits de l ingénierie mais, de par l immatérialité du logiciel, la notion de cycle de vie devient essentielle pour bien situer le projet menant à la réalisation du logiciel; sommes-nous en train de définir ce que sera le logiciel, de planifier comment réaliser le logiciel ou sommes-nous en train de résoudre des problèmes d exploitation du logiciel? L informatisation de l entreprise 7/46 P-A. Sunier

8 Dans cette notion de cycle de vie, il est naturellement aussi question de la maintenance évolutive et corrective; cette maintenance doit être «organisée» dès la conception à l image d un constructeur de voitures qui organise son réseau de distribution et d entretien et planifie, dès la conception, les travaux d entretien et de correction de l usure. Un système d'information informatisé ou un logiciel n'est pas un élément figé "tombant du ciel" mais un élément "vivant" découlant des besoins d'organisation de l'entreprise. Le concept de cycle de vie est important; il permet de ne pas perdre de vue l'aspect vivant et évolutif du système d'information informatisé ou logiciel, dont: L'existence et la forme dépendantes de choix et de contraintes. La réalisation ou l'acquisition peuvent faire l'objet de projets relativement conséquents. L'exploitation nécessite des ressources humaines, financières ou temporelles. Si ces ressources ne sont pas disponibles, le logiciel ne saurait offrir les services attendus. La maintenance doit corriger l'"usure" du temps. Il ne s'agit pas d'usure physique comme pour une voiture dont les essuie-glaces ou les plaquettes de freins doivent être remplacés; il s'agit d'une usure des services offerts du aux immanquables changements de l'environnement et/ou de l'organisation de l'entreprise. L'obsolescence viendra nécessairement un jour et il faut se préparer à cette échéance. L informatisation de l entreprise 8/46 P-A. Sunier

9 2 Méthodes de développement de logiciels de gestion 2.1 Pourquoi une ou des méthodes? Le début de l informatisation de processus de gestion, dans les années 1960, avait comme objectif essentiel de produire, par programmation, des automates susceptibles de remplacer certaines activités humaines. L intérêt de ces automates était d améliorer la qualité des processus en évitant les erreurs humaines et d obtenir des gains financiers en bénéficiant de la puissance de calcul des ordinateurs. A titre d exemple, nous pourrions citer, la facturation des relevés d électricité des collectivités publiques ; les erreurs humaines de reports d états de compteurs, de calculs de consommation ou d application de tarifs sont supprimées par le recours à l informatique et par ailleurs les traitements des factures ne nécessitent plus une multitude de collaborateurs, l essentiel du travail étant assumé par le système informatique. Ensuite, dans les années , les besoins des organisations dépassent largement l automatisation de processus unitaires telles que la facturation de l électricité ; il s agit d offrir des systèmes d information informatisés aptes à intégrer et faire communiquer de multiples processus. Par exemple, l établissement d une nouvelle facture d électricité doit engendrer une écriture en comptabilité ; l arrivée d un nouvel habitant doit provoquer la création d un nouveau débiteur à qui sera imputé de futures factures d électricité. Actuellement, les besoins des organisations ne se limitent plus à l automatisation de processus de gestion mais aussi, à la connaissance de leur environnement et de la concurrence. Cette connaissance est accessible par la mise en réseau (internet, intranet, extranet) d informations coordonnées provenant de bases de données internes et externes. Le passage de l automatisation de processus de gestion unitaires à la réalisation de systèmes d information informatisés (SII) en passant par l intégration de processus a drastiquement changé le travail des informaticiens. Il est passé de la seule programmation, à l aide de langages proches des ordinateurs, à une étape préalable de conception, puis à l analyse des systèmes d information en étroite collaboration avec les utilisateurs; le travail des informaticiens essentiellement artisanal, voire artistique des débuts, est devenu de plus en plus structuré au fil du temps pour être actuellement un domaine à part entière relevant de l ingénierie [3 Ingénierie des système d information informatisés]. Pour pouvoir appliquer les concepts d ingénierie à la réalisation de logiciels de gestion, il est indispensable que tous les acteurs, chacun dans son rôle propre, partagent un savoir et une démarche commune. Une méthode formalisée de développement de logiciels de gestion permettra de supporter, transmettre et pérenniser le savoir et la démarche commune ; ainsi la méthode garantit le passage des temps héroïques des «rats de laboratoire» férus de la programmation proche des langages de l ordinateur à celui du travail en équipes pluridisciplinaires seules aptes à relever les défis d intégration et de communication de la connaissance des systèmes d informations informatisés modernes. L informatisation de l entreprise 9/46 P-A. Sunier

10 2.2 Qu est-ce? Une méthode 14 ou méthodologie de développement de logiciels de gestion est la description d une démarche à suivre pour réaliser chacune des activités allant de l expression des besoins à la mise en place et l exploitation du futur logiciel. En plus de la démarche, une méthode inclut des modèles, des outils et des techniques ; un modèle peut être une représentation abstraite des données manipulées par un logiciel, un outil peut être un éditeur de diagrammes qui permet de représenter graphiquement un modèle ou un générateur qui produit du code depuis un modèle, une technique peut être la formalisation de la manière de réaliser Tiré de [SBJ-02] des modèles. Une méthode peut provenir de l extérieur, être développée à l interne ou résulter de la personnalisation d une méthode externe. L avantage de méthodes externes reconnues par une large communauté, telles que Merise 15 de l approche classique des années ou UP 16 de l approche orientée objet contemporaine, est que ces méthodes reconnues permettent le dialogue entre personnes sur la base d un référentiel commun. Le risque de ces méthodes externes est qu elles ne soient qu imparfaitement adaptées aux besoins spécifiques des organismes qui l utilisent et qu elles s avèrent être un carcan «réglementaire» plus qu une aide efficiente; à l inverse, une méthode interne peut s avérer lacunaire par manque d expérience, peu propice à favoriser la communication par son caractère «propriétaire» et coûteuse à maintenir. La sagesse recommande de s appuyer sur une méthode externe reconnue et de l adapter aux besoins spécifiques de l organisme ; ainsi, la méthode personnalisée servira de guide éprouvé pour un organisme ou pour un projet particulier. 14 Pour les concepts généraux, voir [0] 15 Merise [MERISE-1] Méthode de conception et de développement de système d information dont les fondements ont été élaborés durant les années 1978 & 1979 sur la base d une impulsion du gouvernement français. 16 UP [JBR-00 p16] Le Processus unifié (UP) est un processus de développement logiciel, c est-à-dire qu il regroupe les activités à mener pour transformer les besoins d un utilisateur en système logiciel. Mais, c est plus qu un processus. C est un fragment de framework de processus générique pouvant être adaptés à une large classe de systèmes logiciels, à différents domaines d application, à différents types d entreprises, à différents niveaux de compétences et à différentes tailles de projets. L informatisation de l entreprise 10/46 P-A. Sunier

11 2.3 Choisir une méthode Tout comme pour la cuisine, il n y a pas une méthode mais des méthodes! En cuisine il y a des méthodes liées aux us et coutumes locales, aux traditions, aux progrès technologiques, au mode de vie, à la finalité du repas En informatique, il en est de même, il y a des méthodes liées à des courants de pensée, à des besoins particuliers, à des technologies particulières, à des contraintes de «taille» des entreprises, à des enjeux financiers Le choix ou l adoption d une ou de méthodes par de nombreuses DSI nous semble être un perpétuel recommencement ; régulièrement, de nouvelles méthodes apparaissent et sont présentées comme incontournable à qui veut rester au sommet de son art 17. A partir de là, la difficulté des DSI et des informaticiens en général est de faire la part des choses entre la nécessité d évoluer et le besoin d assurer une stabilité minimale au sein des équipes, des projets et des logiciels. Très souvent, les utilisateurs et/ou la maitrise d ouvrage ne sont pas totalement satisfaits du SII ; face à cette situation, il nous semble que beaucoup de DSI et d informaticiens croient trouver leur salut dans la nouvelle méthode miracle, les cours et les certifications qui vont avec et qui sont souvent vendus au prix fort. Dans certains cas, l acquisition et la mise en œuvre d une ou de méthodes appropriées vont permettre à la DSI et aux informaticiens de conduire de nouveaux projets d informatisation avec succès. Dans bien d autres cas, ce n est certainement pas l adoption d une ou de nouvelles méthodes qui vont conduire au succès mais de comprendre les raisons de l insatisfaction des utilisateurs et/ou de la maitrise d ouvrage qui, très, très souvent, sont inhérents à la spécificité des logiciels de gestion : l immatérialité du logiciel 18 ; La problématique de l immatérialité du logiciel peut être relativement bien solutionnée par le recours à des phases de modélisation sous forme de modèles graphiques, maquettes, prototypes Le recours à une méthode guidant le travail de modélisation aide à solutionner ce problème. les perturbations incessantes que subit le SII de son environnement [1 Système d information informatisé et non automatisé Evolution du système d information]; La problématique des perturbations que subit le SII peut être solutionnée en mettant en place une méthode de travail axée sur la réactivité aux changements 19 plutôt que 17 [3] L ingénierie des logiciels de gestion est l art de mener méthodiquement les actions 18 L immatérialité du logiciel fait que beaucoup d utilisateurs ou de maître d ouvrage ne perçoivent pas que l excellence informatique a un prix que l entreprise ne peut pas forcément payer. Beaucoup d utilisateurs ou de maître d ouvrage estiment normal de disposer de mécanismes de recherche au sein de leurs logiciels aussi sophistiqué que ce qu offre Google par exemple ; ils ne perçoivent pas que derrière la simplicité du mécanisme utilisateur de la recherche de Google se cache une débauche de technologie et de ressources humaines, financières et temporelles. C est un peu comme si lors d un achat de voiture, tout en chacun estime devoir disposer de ce qui se fait de mieux indépendamment de ses moyens. 19 Demeurent réservés les incidences humaines, financières, temporelles, qualitatives ou encore en terme de risques de la prise en compte de chaque changement. L informatisation de l entreprise 11/46 P-A. Sunier

12 centrée sur la réalisation d un cahier des charges contractuel 20. les besoins qui sont souvent implicites [2 Qualité des logiciels]. La problématique des besoins implicites peut être atténuée en recourant à des maquettes et/ou prototypes dans la phase de développement des logiciels, tout comme pour résoudre le problème de l immatérialité du logiciel. Mais, en amont, le recours, méthodiquement, à un recueil exhaustif et précis des besoins en impliquant toutes les parties concernées est une démarche qui a fait ses preuves. 2.4 Approches Recensement De manière très sommaire, nous pouvons relever 3 grandes approches, courants de pensée ou écoles dans les méthodes de développement de logiciels de gestion : L approche classique ou fonctionnelle 21 qui s inspire très fortement des concepts systémiques sans intégrer à satisfaction les perpétuelles perturbations que subissent l entreprise et son système d information. L approche orientée objets (UP 22 ) qui propose une démarche s appuyant sur la technologie de programmation orientée objets et prônant : o l expression des besoins, o un développement itératif et incrémental, o une architecture (modèles) comme base de travail ; Les méthodes agiles qui se veulent plus pragmatiques que les 2 approches ci-dessus. L approche «agile» sous-tend un développement du logiciel par affinements successifs à partir de prototypes de plus en plus finalisés. Ces affinements successifs se font dans le cadre d une forte implication des utilisateurs dans le processus de développement Positionnement [I-2 Méthodes de développement de logiciels de gestion Approches usuelles] Les deux approches, classique ou fonctionnelle d une part et orientée objets d autre part, sont couramment utilisées ; pour de nombreuses organisations, les deux approches cohabitent par choix ou par contingence de l existant. 20 Naturellement, lorsqu un projet d informatisation est relativement mécaniste, un cahier des charges figé est le moyen contractuel le plus adapté pour fixer les modalités liant maitre d ouvrage et maitre d œuvre. 21 Les deux noms se retrouvent dans la littérature. 22 Nous nous limitions aux concepts généraux d UP, tout en sachant qu il existe d autres approches orientées objets mais, qui souvent, ne prennent pas en compte la spécificité des logiciels de gestion. L informatisation de l entreprise 12/46 P-A. Sunier

13 L approche classique est liée aux développements clients/serveurs des années 1980 à De son côté, l approche orientée objets est elle liée aux développements multi-tiers apparus à la fin des années 1990 et pour lesquels le langage Java était une pratique courante. En ce qui nous concerne, il nous semble que les méthodes agiles sont de bonnes pratiques pour le développement de logiciels de gestion «limités» à quelques fonctions du SII et ne sauraient remplacer les outils rigoureux que fournissent les approches classiques ou orientées objets ; nous pensons plus particulièrement à la modélisation (cycle de vie), au pilotage (cycle de décision) et au cycle de vie du logiciel. 2.5 Personnalisation En cuisine, nous serions tenté de qualifier de bonne cuisine un repas gastronomique et de pisaller un sandwich. A partir de là, peut-on dire que la cuisine ou le cuisinier qui délivre le repas gastronomique est meilleur que celui qui délivre le sandwich? Si je commande un sandwich pour mon repas, c est peut-être parce que je n ai pas beaucoup de temps, pas très faim, peu d argent ou encore parce que j aime cela. Si je commande un sandwich parce que je n ai pas beaucoup de temps, je serai content d être servi avec un minimum de temps d attente et fâché si je dois attendre très longtemps indépendamment du plaisir que je pourrais avoir à manger le sandwich. A l inverse, si je réserve une table dans un restaurant gastronomique, c est peut-être parce que je veux fêter quelque chose, passer un moment agréable ou encore déguster une cuisine raffinée. Dans cette situation, le temps et le prix n ont pas la même signification ; je suis prêt à passer du temps à table et m acquitter d un montant nettement plus élevé que pour un sandwich. En fait, sandwich ou repas gastronomique ne sauraient être confrontés et jugés l un par rapport à l autre ; chacun correspond à un besoin particulier et chacun mérite d être confectionné par rapport à ce qu attend le client. Ce petit exemple, nous renvoie à la notion de qualité [1 Qualité des logiciels]. La qualité est l'ensemble des propriétés d'un produit, processus ou service qui lui confèrent l'aptitude à satisfaire des besoins explicites ou implicites. La confection d un sandwich ne saurait obéir aux mêmes préceptes que la cuisine gastronomique ; néanmoins, ceci n empêche pas de confectionner des sandwichs au foie gras avec une préparation du foie gras relevant d une cuisine raffinée. Entre le sandwich vite fait, bien fait et le repas gastronomique, nous savons tous qu il y a un nombre incalculable de recettes ou méthodes pour confectionner des mets adaptés à chaque situation particulière. De plus, chacun va choisir d appliquer la recette ou méthode de cuisine «de référence» à la lettre ou tenir compte de ses compétences, des produits disponibles, des goûts et envies des convives pour adapter la recette. L informatisation de l entreprise 13/46 P-A. Sunier

14 Avec toute la prudence voulue lorsqu il s agit de vulgariser une notion, les méthodes en développement de logiciels de gestion ne sauraient être uniques tout comme les recettes de cuisine; en fonction des entreprises, des projets, des acteurs des projets ou d une multitude d autres critères, différentes méthodes peuvent être pertinentes et applicables. Tout comme en cuisine, le succès passe souvent par la conjonction de : la rigueur méthodique, c est-à-dire, privilégier la pérennité d une méthode 23 afin de garantir une constance dans la qualité des processus de développement de logiciels de gestion; l intelligente réaction aux impératifs de chaque projet, c est-à-dire, adapter ou personnaliser la méthode «de référence», autant que nécessaire, pour qu elle soit une aide et non un carcan. En conclusion, il nous semble qu il existe de nombreux apports à prendre dans chaque méthode et qu il est pertinent, par nature de projets, de choisir une méthode et de l adapter ou la personnaliser, si nécessaire, en intégrant des éléments venant d autres méthodes 24 ou en ajustant l un ou l autre élément à partir des expériences passées. 2.6 Méthodes phares Approche Méthode Classique / fonctionnelle Orientée objets Agile Merise X SADT X RAD X UP X XP X Scrum X Merise 1978/1979, H. Tardieu et consorts avec le soutien du gouvernement français. Méthode de référence dans le monde francophone durant les années 1980 à 2000 [Merise-1, Préface de J. Lesbourne] la méthode Merise conçoit le système d information (SI) comme un «objet artificiel» intermédiaire entre le système opérant (SO - l usine ), et le système de pilotage (SP - la 23 Naturellement, il peut y avoir plusieurs méthodes utilisées au sein d une entreprise si les projets sont de nature différente ou si pour des projets de même nature, l entreprise veut tester l une ou l autre nouvelle méthode. 24 ou approches L informatisation de l entreprise 14/46 P-A. Sunier

15 SADT direction ), et comme un objet qui doit contenir une représentation de la dynamique de ces deux derniers systèmes. 1976/1977 D.T. Ross SADT (en anglais Structured Analysis and Design Technique) - connue aussi sous le label IDEF0 (en anglais Integration Definition for Function modeling) - est une méthode d'origine américaine, développée pour Softech par Doug Ross en 1977 puis introduite en Europe à partir de 1982 par Michel Galiner. Elle se répandit vers la fin des années 1980 comme l'un des standards de description graphique d'un système complexe par analyse fonctionnelle descendante 1, c'est-à-dire que l'analyse chemine du général (dit "niveau A-0") vers le particulier et le détaillé (dits "niveaux A ijk "). SADT est une démarche systémique de modélisation d'un système complexe ou d'un processus opératoire RAD UP XP Fin des années 1980, James Martin [I-14] La méthode de développement rapide d'applications, dite méthode RAD (acronyme de l'anglais Rapid Application Development), est la première méthode de développement de logiciels où le cycle de développement est en rupture fondamentale par rapport à celui des méthodes antérieures dites «en cascade». Ce nouveau cycle qualifié d'itératif, d'incrémental et d'adaptatif, se retrouvera ensuite dans toutes les méthodes dites «agiles» publiées par la suite. 1999, I. Jacobson, G. Booch et J. Rumbaugh [JBR-00 p16] Le Processus unifié (UP) est un processus de développement logiciel, c est-à-dire qu il regroupe les activités à mener pour transformer les besoins d un utilisateur en système logiciel. Mais, c est plus qu un processus. C est un fragment de framework de processus générique pouvant être adaptés à une large classe de systèmes logiciels, à différents domaines d application, à différents types d entreprises, à différents niveaux de compétences et à différentes tailles de projets. 1999, Kent Benck [I-15] En informatique et plus particulièrement en génie logiciel, Extreme Programming (XP) est une méthode agile de gestion de projet informatique adaptée aux équipes réduites avec des besoins changeants. Elle pousse à l'extrême des principes simples puisque la revue de code est une bonne pratique, elle sera faite en permanence (par un binôme) ; puisque les tests sont utiles, ils seront faits systématiquement avant chaque implantation ; puisque la conception est importante, elle sera faite tout au long du projet (refactoring) ; puisque la simplicité permet d'avancer plus vite, nous choisirons L informatisation de l entreprise 15/46 P-A. Sunier

16 toujours la solution la plus simple ; puisque la compréhension est importante, nous définirons et ferons évoluer ensemble des métaphores 25 ; puisque l'intégration des modifications est cruciale, nous l'effectuerons plusieurs fois par jour ; puisque les besoins évoluent vite, nous ferons des cycles de développement très rapides pour nous adapter au changement. Scrum 1996 [I-16] En informatique et plus particulièrement en génie logiciel, Scrum est une méthode agile dédiée à la gestion de projets. Son objectif est d'améliorer la productivité des équipes auparavant ralenties par des méthodologies plus lourdes En revanche, la méthode Scrum ne couvre aucune technique d'ingénierie du logiciel. Aussi, son utilisation dans le contexte du développement d'une application informatique nécessite de lui adjoindre une méthode complémentaire Le principe de base de Scrum est de focaliser l'équipe sur une partie limitée et maîtrisable des fonctionnalités à réaliser. Ces incréments se réalisent successivement lors de périodes de durée fixe de une à quatre semaines, appelées sprints. Chaque sprint possède, préalablement à son exécution, un but à atteindre, défini par le directeur de produit, à partir duquel sont choisies les fonctionnalités à implémenter dans cet incrément. Un sprint aboutit toujours à la livraison d'un produit partiel fonctionnel. 2.7 Portée des méthodes Comme le montre la lecture de la petite synthèse des méthodes phares du chapitre précédent, pratiquement toute méthode a une portée particulière ce qui rend très certainement nécessaire le recours à une personnalisation et une complémentarité des méthodes. Dans une approche allant du plus stratégique au plus opérationnel, nous pouvons certainement dire que : Merise est une méthode de développement de logiciels de gestion qui couvre un très large spectre des activités surtout en amont du développement proprement dit; en effet le concept de Schéma directeur est certainement la pièce maitresse de toute démarche d informatisation de l entreprise [3 Conduite stratégique de l informatisation Schéma directeur]. Même si la méthode est aujourd hui passée de mode et d utilisation ; le concept de 25 [PR] Métaphore : procédé du langage qui consiste dans un transfert de sens (terme concret dans un contexte abstrait) par substitution analogique. Le couple réalité/modèle peut perçu comme une métaphore. L informatisation de l entreprise 16/46 P-A. Sunier

17 Schéma directeur 26 reste et demeure la pierre angulaire de toute informatisation de l entreprise. Par ailleurs, les notions de cycle de vie, cycle d abstraction (modélisation) et cycle de décision fortement prônées par Merise, deviennent des impératifs de tout projet d informatisation tant soit peu stratégique. Si ces cycles ne sont pas expressément pris en charge par l une ou l autre méthode, comme par exemple Scrum, il y a lieu de les intégrer d une manière ou d une autre ; pour rappel, ce peut être par une personnalisation de méthode ou une complémentarité de méthode. Merise, SADT et d autres méthodes des débuts du génie logiciel en informatique de gestion (années 1970) ont fortement contribué à la pratique de la modélisation des données (aspect statique du SI) et des traitements (aspect dynamique du SI). A ce jour, ces activités de modélisation sont toujours fortement inspirées de ces méthodes pionnières. UP et ses déclinaisons commerciales comme RUP par exemple, se concentrent essentiellement sur le logiciel de gestion et ne remontent pas au niveau du SII dans son ensemble ; par contre, les cycles de construction (cycles de vie, d abstraction et de décision) sont très bien pris en charge projet par projet ou logiciel par logiciel. Les méthodes agiles sont profilées pour tenter de donner des réponses appropriées aux défis actuels des entreprises qui se meuvent dans un univers toujours plus concurrentiel et globalisé, à savoir : répondre rapidement aux besoins toujours plus urgents et changeants de l automatisation des systèmes d information. En conclusion, une méthode comme Merise est toujours intéressante s agissant de définir la stratégie à moyen et long terme du SI de l entreprise [3 Conduite stratégique de l informatisation]. Une méthode inspirée des concepts d UP offre une démarche très intéressante pour la réalisation des divers projets d informatisation du SI et se traduisant par autant de logiciels constitutifs du SII. Une méthode dite «agile» peut compléter les méthodes plus formelles ci-dessus en focalisant les activités de conception et de programmation sur les besoins évolutifs des utilisateurs. Dans tous les cas et quelle que soit la méthode utilisée, nous recommandons de toujours réaliser le modèle de données sous-tendu par le logiciel de gestion à développer car la structure de données est l élément le plus stable du SII. Cette règle impose de coupler les méthodes agiles qui ne proposent pas de modélisation à des méthodes plus formelles qu elles soient de l approche classique, orientées objets ou autre. 26 Le terme Schéma directeur peut être renommé (par exemple : plan directeur ) par d autres méthodes ou auteurs mais, les bases conceptuelles demeurent. L informatisation de l entreprise 17/46 P-A. Sunier

18 2.8 Approche classique ou fonctionnelle Préambule Dans le paysage francophone, le courant de pensée méthodologique tel que nous le percevons actuellement dans le cadre de l approche classique a été très fortement influencé par la méthode Merise. Les fondements de la méthode Merise ont été élaborés entre 1978 et 1979 sur la base d une impulsion du ministère français de l Industrie et de la Recherche ; cette impulsion a été donnée sous forme du lancement d une étude sur l informatisation et la vie au travail. Merise s enracine dans une conception systémique de l organisation ; [Merise-1, Préface de J. Lesbourne] la méthode Merise conçoit le système d information (SI) comme un «objet artificiel» intermédiaire entre le système opérant (SO - l usine ), et le système de pilotage (SP - la direction ), et comme un objet qui doit contenir une représentation de la dynamique de ces deux derniers systèmes. Dans le monde anglo-saxon, la méthode SADT 27 a posé les fondements de l approche structurée de l analyse à la programmation; conjointement, la méthode SASS 28 a amené le concept de diagramme de flux de données (DFD) pour modéliser la dynamique des systèmes d information. Trois concepts se retrouvent dans les méthodes classiques inspirées du courant de pensée systémique [HS-94]: avoir une vue globale du système d'information, c'est-à-dire considérer les données et les traitements d'une entreprise comme constituant unique et intégré. Cette approche globale conduit souvent vers un schéma de données, un schéma de traitement et un schéma organisationnel; distinguer plusieurs niveaux d'abstraction lors du processus de modélisation; on commence par le niveau le plus général (le conceptuel, le quoi) pour terminer par le niveau le plus détaillé et le plus technique (le physique, le comment); mettre en évidence la dualité données/traitements: les données et les traitements doivent être modélisés séparément dans un premier temps, pour être ensuite confrontés mutuellement. Rappel : Sous le terme d approche classique, nous regroupons les méthodes des approches dites «structurées» des «technologies de l information» ou encore «fonctionnelles». 27 SADT - Structured Analys and Design Technique développée par D.T. Ross aux alentours de SASS Structured Analys and System Specification développée par T. De Marco au milieu des années 1970 L informatisation de l entreprise 18/46 P-A. Sunier

19 2.8.2 Vue globale du système d information Comme nous l avons vu précédemment, le système d information est un objet artificiel qui capte, traite, stocke et restitue de l information au bénéfice de l opérationnel ou du pilotage de l organisme ; il interagit aussi avec l environnement de l organisme. Pour automatiser tout ou partie de ces fonctions, il est indispensable de comprendre les buts, l organisation ou encore le fonctionnement de l organisme et son système d information. La compréhension de l organisme et de son système d information doit tenir compte de la spécificité des organismes sociaux qui, comme les organismes vivants, ne peuvent se décrire par des formules mathématiques ; d autres éléments comme la finalité de l organisme ou des individus qui le compose, l influence de l environnement ou l usure du temps doivent être pris en compte. La théorie des systèmes et la systémique nous offrent les bases d un raisonnement susceptible de nous aider à comprendre et appréhender la complexité des organismes et de leurs systèmes d information ; les organismes, tout comme leurs systèmes d information, doivent être considérés comme des systèmes ouverts. L informatisation de l entreprise 19/46 P-A. Sunier

20 Théorie des systèmes Un système ouvert est en relation permanente avec son environnement ; en fait, il y est immergé. Il subit des perturbations externes qui sont à priori, imprévisibles et inanalysables. Ces perturbations, qui surviennent dans son environnement, nécessitent des adaptations du système qui le ramènent à un état stationnaire. [Merise-1] Trois propriétés formelles s appliquent aux systèmes ouverts : - Totalité : un système ne se comporte pas comme un simple agrégat d éléments indépendants, il constitue un tout cohérent et indivisible. Une autre façon d exprimer cette propriété est de définir un système complexe. Les deux éléments qui caractérisent la complexité sont la variété des éléments et l interaction entre les éléments. - Rétroaction : le fonctionnement de base des systèmes repose sur le jeu combiné des interactions entre les composants du système. Dans tout système où s effectue des transformations, on peut identifier des entrées qui reflètent l action de l environnement et des sorties qui représentent l action du système sur l environnement. La rétroaction consiste à renvoyer à l entrée, des informations sur la sortie du système. - Equifinalité : dans un système circulaire, les conséquences ne sont pas uniquement déterminées par les conditions initiales mais aussi par la nature du processus qui se déroule. Le principe d équifinalité signifie que les mêmes conséquences peuvent avoir des origines différentes et donc que par opposition au système fermé qui est complètement déterminé par ses conditions initiales, un système ouvert a un comportement à la limite indépendant des conditions initiales La vision systémique du système d information En reprenant les postulats de la systémique, les méthodes de l approche classique et plus particulièrement Merise ont été élaborées à partir des trois hypothèses suivantes : 1. Téléologique : l objet à modéliser, c est-à-dire l organisme ou son système d information est supposé être doté d au moins un projet identifiable ; cette hypothèse est appelée «téléologique» 2. Structuraliste : l objet à modéliser doit être décrit dans sa totalité, fonctionnant et évoluant. 3. Ouverture sur l environnement [BOU-95 p29]... au vu de la nécessité de traiter à la fois l'instabilité, l'évolutivité et la complexité des systèmes... il devient alors évident de privilégier les approches plus ensemblistes où la prise en compte du "global" est préférable à la précision du détail, où la complexité du système ne peut s'approcher qu'à travers des modèles imbriqués ou tout au moins enchaînés. La pensée analytique, basée sur le fonctionnement, cède le pas à la puissance des visions plus synthétiques, plus itératives, fondées sur des modèles de comportement... L informatisation de l entreprise 20/46 P-A. Sunier

21 2.8.3 Cycles de construction De la théorie des systèmes, les auteurs des méthodes classiques de conception de système d information et plus particulièrement de Merise ont mis en évidence 3 cycles dans la construction du système d information informatisé (SII). La représentation de ces 3 cycles se fait classiquement sous forme d un espace à 3 dimensions que sont : la vie, les décisions et le niveau d abstraction du SII Le cycle de vie Le cycle de vie rend compte du passage de l expression des besoins d informatisation du système d information à la mise en œuvre et à l exploitation du système d information informatisé. Le cycle de vie permet de passer de l idée à sa concrétisation ; sur cet axe temporel nous trouverons sous des termes variables et avec un découpage plus ou moins fin : l inception, la conception, la réalisation, l exploitation et la maintenance. Lorsque les contraintes environnementales du SII évoluent trop fortement : obsolescence des techniques, changement profond des règles de gestion ou transformation importante de l organisation, un nouveau cycle de vie recommence Le cycle de vie est qualifié de «processus de production» ou encore de «démarche» du projet d informatisation par d autres auteurs. L informatisation de l entreprise 21/46 P-A. Sunier

22 Le cycle d abstraction Le cycle d abstraction est utile pour isoler les choix de gestion, niveau conceptuel, des choix organisationnels et opérationnels. Ces niveaux d abstraction correspondent aux échelles des cartes topographiques; selon l échelle, plus ou moins de détails sont pris en compte. La carte routière est utilisée pour se rendre d une ville à l autre et le plan de ville pour rechercher une rue ou un quartier. Le cycle d abstraction est qualifié de «représentation» ou encore de «raisonnement» du projet d informatisation par d autres auteurs Le cycle de décision Le cycle de décision rend compte de l ensemble des choix qui doivent être faits durant le cycle de vie. Il permet à l organisation de définir les buts et l environnement du système d information artificiel, de même que les modalités de son exploitation. Le cycle de décision est qualifié de «pilotage» ou encore de «maîtrise» du projet d informatisation par d autres auteurs. Lorsqu''il s'agit de mettre en place un logiciel de gestion, la portée des décisions varie au fil du temps. Au début, ce seront essentiellement des décisions stratégiques liées aux choix organisationnels de l'entreprise et impliquant fortement la maîtrise d'ouvrage; ensuite, les décisions relèveront toujours plus de l'opérationnel du traitement de l'information et impliqueront de plus en plus les utilisateurs. L informatisation de l entreprise 22/46 P-A. Sunier

23 2.8.4 Dualité des données et des traitements Le concept de dualité données/traitements est issu des premières démarches d'ingénierie et de méthodologie; le but de cette séparation consistait à séparer le traitement "technique" d'obtention des données du traitement "logique" de manipulation des données dans le but de fournir de l'information. Par traitement "technique", nous entendons les opérations de transformation de contenus de fichiers informatiques (une suite de bits, bytes, de caractères ou de mots) en données utilisables. Cette dualité a pris tout son sens lors de l'émergence des systèmes de gestion de base de données qui permettaient de s'intéresser aux données en faisant abstraction des mécanismes de mémorisation mis en œuvre. Les méthodes classiques ont alors proposé d'étudier d'une part la structure statique (les données) et d'autre part la structure dynamique (les traitements). Actuellement, les méthodes classiques 29 préconisent de privilégier l effort de modélisation des données car celles-ci constituent une ressource qui risque de bien peu changer avec le temps comparativement aux processus de l organisme. Par exemple, le système de gestion des commandes d une société de vente par correspondance comporte comme entités de données des clients, commandes et produits ; le processus informatique permet aux opérateurs de la société de saisir les commandes par poste ou par téléphone. La société décide de créer une galerie de vente sur son site internet ; naturellement, il faudra développer de nouveaux processus informatiques mais, les entités de données clients, commandes et produits peuvent probablement être réutilisées. [BOU-95 p78]... la modélisation interne du système s'effectue en deux parties distinctes, l'une dite "statique", qui correspond aux données et en représente la part la plus stable et la plus permanente, l'autre dite "dynamique", qui correspond aux traitements et en représente la part la plus instable et la plus évolutive. [SBJ-02 p83] Le type de données nécessaire pour diriger une entreprise change très peu avec le temps, à l opposé des processus de collecte des données qui eux changent souvent. En s'inspirant de cette emphase de la modélisation des données sur la modélisation des traitements, de nombreuses méthodes et ateliers de génie logiciels prônent une conception de logiciels de gestion "pilotée" par les données. Dans de nombreuses situations, la modélisation des données se fait en amont et la réalisation des aspects dynamiques se fait à partir de la structure de données modélisée. 29 Et aussi orientée objet par l intermédiaire des modèles du domaine, voire du métier. L informatisation de l entreprise 23/46 P-A. Sunier

24 2.8.5 Modélisation Le cycle d abstraction, de raisonnement ou encore de représentation consiste à modéliser l organisme ou le système d information. La complexité des organismes et de leurs systèmes d information rend leur compréhension, respectivement leur description excessivement difficile ; pour nous aider dans cette tâche, les méthodes classiques ou orientées objets, nous proposent d en réaliser des modèles. Les modèles sont des simplifications de la réalité qui se concentrent sur un ou des aspects particuliers ; ces modèles favorisent la communication au sein des équipes et des acteurs impliqués par tout projet d informatisation du SI. La nature des modèles, respectivement l activité de modélisation, sont probablement les éléments les plus distinctifs des différentes méthodes ; les modèles de l approche classique sont relativement différents de ceux de l approche orientée objets. Néanmoins, certaines analogies existent entre les modèles représentant l aspect statique (les données) des deux approches. S agissant de l approche classique, deux concepts se retrouvent dans les différentes déclinaisons de méthode : - Une modélisation de l aspect statique (les données) indépendamment de la modélisation de l aspect dynamique (les traitements de données) ; - Une modélisation par niveaux d abstraction d où le nom quelque peu malheureux de cycle d abstraction que nous devrions peut-être nommer cycle de modélisation Exemple L activité de modélisation étant essentielle à la pratique efficace des méthodes de développement de systèmes d information informatisés, nous produisons ci-après à titre d illustration deux diagrammes issus de modèles de niveau conceptuel que nous réaliserions en phase d analyse. Pour cet exemple, nous nous sommes inspirés du contexte de la société de vente par correspondance que nous avons mentionnée précédemment. Le premier diagramme est une vue du modèle entités/associations ; le modèle entités/associations représente l aspect statique du SII, c est-à-dire une structure de données sous formes d entités et d associations entre entités. Le deuxième diagramme est une vue du modèle de flux de données 31 ; le modèle de flux de données représente l aspect dynamique du SII, c est-à-dire les fonctions informatiques qui manipulent des entités de données. Ces deux modèles ont été réalisés avec l atelier de génie logiciel Designer du constructeur Oracle. 30 Malheureusement, le terme de cycle d abstraction est déjà entré dans le langage courant et le changer n apporterait probablement qu un peu plus de confusion. 31 Le modèle de flux de données illustré se nomme en fait DFD, pour diagramme de flux de données. Ce nom de diagramme a été donné en 1975 car un modèle était en fait un dessin ou un diagramme ; les termes de diagrammes ou de modèles étaient utilisés indifféremment. Depuis l avènement des outils informatiques de modélisation, le terme de modèle s applique à l ensemble des éléments modélisés et stockés dans une base de données ; le terme de diagramme s applique à une représentation graphique particulière d éléments modélisés. Plus scientifiquement, un diagramme est une vue externe du modèle pour un aspect et un usage particulier. L informatisation de l entreprise 24/46 P-A. Sunier

25 Diagramme entités/associations Nous voyons sur ce diagramme : les entités de données CLIENT, COMMANDE, LIGNECOMMANDE et PRODUIT ; les associations qui relient entre les entités entre elles; par exemple : une commande est passée par un client. L informatisation de l entreprise 25/46 P-A. Sunier

26 Diagramme de flux de données (DFD) Nous voyons sur ce diagramme : les fonctions Traiter commande, Préparer commande et Expédier commande; l entité externe CLIENT qui représente l environnement ; les entrepôts de données COMMANDES et BULLETIN LIVRAISON qui font le lien avec le modèle entités/associations ; par exemple : l entrepôt COMMANDES de ce diagramme contient les occurrences de l entité COMMANDE du digramme précédent ; les flux de données qui véhiculent les entrées ou sorties de fonctions. L informatisation de l entreprise 26/46 P-A. Sunier

27 2.9 Approche orientée objets Préambule L approche orientée objet de développement de système d information informatisé (SII) de gestion est actuellement influencée par UP ou Unified Processus ; en français, nous nommons cette méthode «Processus unifié». Le terme de processus choisi par les auteurs doit être compris comme «chemin raisonné» de notre définition initiale du concept de méthode. UP est le fruit du travail de UP de I. Jacobson, G. Booch et J. Rumbaugh. Les auteurs ont réalisé UP à partir de la réunion de leurs travaux antérieurs et de multiples sources telles que les autres méthodes et les retours d expériences pratiques ; le terme «unifié» qualifie ce travail de réunion ou d unification qui a sous-tendu UP. Les 3 auteurs ont publié leur méthode sous le titre : «The Unified Software Development Process» en 1999 ; cette publication a été traduite en français en 2000 sous le titre «Le Processus unifié de développement logiciel [JBR-00]. Dans un premier temps cette méthode, ou processus selon la terminologie des auteurs, s appelait Unified Method ; une première version de cette méthode a été présentée en 1995 ; mais, par la suite, les auteurs se sont concentrés sur la problématique de l unification des modèles qui sont à la base du processus ; pour ce faire, ils ont spécifié un langage «unifié» de modélisation de représentation du système d information et Unified Method Figure 1 - Genèse du Processus unifié est devenue UML ou Unified Modeling Language en Ensuite I. Jacobson, G. Booch et J. Rumbaugh ont repris les éléments du processus UM et du langage UML pour affiner le processus qui est devenu UP en 1999 comme indiqué précédemment. Parallèlement, aux travaux de Jacobson, Booch & Rumbaugh, la société Rational 32, met au point une méthode commerciale, RUP ou Rational Unified Process, basée sur les mêmes principes que ceux qui ont prévalus à l élaboration d UP ; ces travaux ont été menés par divers collaborateurs dont P. Kruchten qui a publié un ouvrage d introduction au processus sous le titre «The Rational Unified Process : An Introduction» en 1999 ; cette publication a été traduite en français sous le titre «Introduction au Rational Unified Process» [PK-00]. 32 Les auteurs de UP & UML I. Jacobson, G. Booch et J. Rumbaugh sont parties prenantes de la société Rational Depuis 2003, Rational est passé dans le giron d IBM et le processus s appelle RUP ou IBM Rational Unified Process L informatisation de l entreprise 27/46 P-A. Sunier

28 En fait, UP fournit librement, sous forme d un ouvrage de référence, les principes que chacun peut utiliser et adapter à ses besoins. De son côté, RUP est un produit commercial ; il fournit la méthode et toute une série de guides pour la mettre en œuvre efficacement. Naturellement, d autres méthodes existent, inspirées ou pas du Processus unifié, UP. Trois concepts centraux supportent le Processus unifié (UP) : Il est piloté par les cas d utilisation ; les cas d utilisation permettent de décrire les services attendus par chacun des futurs utilisateurs du système. Nous tenons à rappeler ici que, si couramment il est évoqué les besoins des utilisateurs, les cas d'utilisation vont à notre sens au-delà; les cas d'utilisation doivent représenter l'automatisation de processus de traitement de l'information utiles et nécessaires en tant que support de l'organisation de l'entreprise; l'utilisateur n'est, sans être péjoratif, qu'un acteur, important certes, des processus organisationnels. Il est centré sur l architecture ; l architecture est l ensemble des choix significatifs de construction réalisés pendant la modélisation. L'architecture d'un logiciel ne peut se visualiser physiquement comme c'est le cas avec une maison; l'architecture ne se "voit" qu'au travers de modèles. Dès lors, la représentation visuelle des modèles doit être privilégiée. Il est itératif et incrémental ; de par la complexité des organisations, des contraintes de temps ou encore de l'émergence de nouvelles technologies peu maîtrisées de nombreux risques peuvent mettre en péril un développement logiciel ; une démarche itérative permet de réduire, dès les premières itérations, les risques les plus élevés. L informatisation de l entreprise 28/46 P-A. Sunier

29 2.9.2 UP est piloté par les cas d utilisation Figure 2 - Extrait de modèle de cas d'utilisation [JBR-00 p17] L'objectif d'un système logiciel est de rendre service à ses utilisateurs. Pour réussir la mise au point d'un système, il importe, par conséquent, de bien comprendre les désirs et les besoins de ses futurs utilisateurs. Un cas d'utilisation est une fonctionnalité du système produisant un résultat satisfaisant pour l'utilisateur. Les cas d'utilisation saisissent les besoins fonctionnels et leur ensemble forme le modèle des cas d'utilisation qui décrit les fonctionnalités complètes du système. [JBR-00 p47] L'objectif du Processus unifié est de guider les développeurs vers l'implémentation et le déploiement efficaces de systèmes répondant aux besoins des clients. Cette efficacité se mesure en termes de coûts, de qualité et de délai de fabrication. Le passage de l'estimation des besoins du client à leur implémentation est loin d'être naturel. D'abord parce que les besoins des clients ne se laissent pas si facilement appréhender. Il faut disposer d'un moyen de les communiquer de façon claire à toute personne impliquée dans le projet. Il Figure 3 - Enchaînement d'activités et de modèles depuis l expression des besoins par les cas d'utilisation aux tests du logiciel en passant par l'analyse et la conception faut, ensuite, être en mesure de concevoir une implémentation opérationnelle répondant à ces besoins. Il faut, enfin, vérifier la pleine satisfaction de ces besoins en testant le système. L informatisation de l entreprise 29/46 P-A. Sunier

30 2.9.3 UP est centré sur l architecture [JBR-00 p18] Le rôle de l'architecture logicielle est comparable à celle que joue l'architecte dans la construction d'un bâtiment. Le bâtiment est envisagé de différents points de vue: structure, services, conduite de chauffage, plomberie, etc. Ce regard multiple dessine une image complète du bâtiment avant le début de la construction. De la même façon, l'architecture d'un système logiciel peut être décrite comme les différentes vues du système qui doit être construit. [JBR-00 p71] Les cas d'utilisation ne suffisent pas. Pour échafauder un système opérationnel, il faut quelque chose de plus. Ce "plus" c'est l'architecture. On peut se représenter l'architecture d'un système comme la vision commune sur laquelle doivent s'accorder tous les travailleurs (c'està-dire les développeurs et les autres intervenants), ou qu'ils doivent au moins accepter. L'architecture offre une perspective claire de tout le système, indispensable pour en maîtriser le développement. Figure 4 - Vue architecturale des classes d'analyse du cas d'utilisation "Retirer de l'argent" [JBR-00 p81] Les cas d'utilisation orientent le développement de l'architecture, tandis que l'architecture guide la réalisation des cas d'utilisation L informatisation de l entreprise 30/46 P-A. Sunier

31 2.9.4 UP est itératif et incrémental [JBR-00 p19] Le développement d'un produit logiciel destiné à la commercialisation est une vaste opération qui peut s'étendre sur plusieurs mois, voire sur une année ou plus. Il n'est pas inutile de découper le travail en plusieurs parties qui sont autant de mini-projets (Concept systémique de système et sous-systèmes). Chacun d'eux représente une itération qui donne lieu à un incrément. Les itérations désignent des étapes de l'enchaînement d'activités, tandis que les incréments correspondent à des stades de développement du produit. Figure 5 - Les itérations du RUP [JBR-00 p101] Parvenir à un juste équilibre entre cas d utilisation et architecture revient, grosso modo, à harmoniser forme et fond dans le développement d un produit Savoir ce qui vient en premier nous ramène au problème de l œuf et de la poule Ce sont d interminables itérations, survenues tout au cours du long processus d évolution qui ont donné naissance à la poule et à l œuf. De la même façon, au fil du processus de développement logiciel, les développeurs recherchent consciencieusement cet équilibre (entre cas d utilisation et architecture) à travers une série d itérations. L approche itérative et incrémentale du développement constitue bien, par conséquent, le troisième pivot du Processus unifié. L informatisation de l entreprise 31/46 P-A. Sunier

32 2.9.5 Discussion Piloté par les cas d'utilisation est un processus privilégiant les besoins des utilisateurs tout en sachant que le but final est d'offrir des fonctionnalités informatiques supportant le plus efficacement possible les choix organisationnels de l'entreprise. Piloté par les cas d'utilisation est aussi une manière d'organiser les différents artefacts produits tout au long du cycle de vie des différents logiciels composants le SII. La Figure ci-contre montre cette organisation des artefacts au sein du référentiel d'un outil de modélisation; nous voyons le System (SII) offrant des cas d'utilisation et la description détaillée du cas d'utilisation Attribuer livreur. Piloté par les cas d'utilisation ne veut pas dire que le modèle des cas d'utilisation doit être le premier modèle à réaliser; en de nombreuses situations, la stabilité des structures de données [Voir Chapitre 2.8.4] amène l'analyste à s'intéresser d'abord aux dites données et ensuite seulement aux cas d'utilisation (services) qui manipuleront d'une manière ou d'une autre ces données. L informatisation de l entreprise 32/46 P-A. Sunier

33 2.9.6 Modélisation Démarche Les modèles sont au cœur du processus ; comme nous l avons indiqué précédemment, les choix essentiels de modélisation définissent l architecture du futur logiciel et donc le résultat final fournit aux futurs utilisateurs. Figure 6 - Les enchaînements et dépendances de modèles du RUP Dans un premier temps, la modélisation du métier «Business Modeling» permet de représenter les activités de l organisme dans son ensemble sous forme de modèles des cas d utilisation métier, de modèles d objets métier et de modèles du domaine ; les concepts du modèle du domaine s apparentent à ceux du modèle entités-associations de l approche classique. Ensuite ces modèles servent de données d entrée pour la modélisation des exigences «Requirements» sous forme de modèle de cas d utilisation système ; il s agit cette fois de cas d utilisation du sous-système d information de l organisme. Le modèle de cas d utilisation système, le modèle d objets métier et le modèle du domaine sont utilisés comme données d entrée pour l analyse ; la modélisation en analyse fournira le modèle d analyse et ainsi de suite jusqu aux tests finaux. L informatisation de l entreprise 33/46 P-A. Sunier

34 Langage de modélisation unifié UML Un apport qui nous semble essentiel de la démarche d unification des auteurs du Processus unifié, c est d avoir spécifié UML, un langage de modélisation tout aussi unifié 33 ; comme nous pouvons le voir dans la figure1, la version 1.1 d UML a été standardisée par l OMG 34 en fin Après une version 1.5, qui a été largement utilisée ; fin 2004, l OMG a libéré les spécifications d une version 2.0 qui fait apparemment la part belle à la modélisation des activités de l entreprise et plus particulièrement au concept d entités de données. Grâce à une large utilisation d UML, à la limite quelle que soit la méthode sous-jacente, les erreurs dues à une interprétation erronée d un modèle ou d un diagramme par méconnaissance d un langage particulier se trouvent grandement réduite ; dans l approche classique, pratiquement chaque méthode ou école de pensée a défini son langage de représentation, ce qui rend le passage d une méthode ou d un outil à un autre relativement périlleux ou, en tout les cas, rébarbatif. De plus, l unification et la standardisation d UML permet l échange 35 de modèles entre outils logiciels différents ; en conséquence le changement d outils logiciel en est facilité. Le même langage s applique aux multiples modèles nécessaires à représenter les divers aspects des systèmes d information Exemple L activité de modélisation étant essentielle à la pratique efficace des méthodes de développement de systèmes d information informatisés, nous produisons ci-après, à titre d illustration, deux diagrammes issus du modèle d analyse pour le premier et du modèle de conception pour le deuxième. Les deux diagrammes, respectivement les deux modèles, affinent le cas d utilisation «Retirer de l argent» de la Figure 2. Ces deux modèles ont été réalisés avec l atelier de génie logiciel Rose du constructeur IBM 36 à partir d un cas pratique issu de [JBR-00]. 33 UML Unified Modeling Language 34 Site UML de l OMG-Object Management Group : 35 L échange de contenu de référentiel se fait grâce à XMI, un schéma XML définit par l OMG; 36 Anciennement Rational L informatisation de l entreprise 34/46 P-A. Sunier

35 Diagramme de collaboration en analyse Nous voyons sur le diagramme ci-dessus, les classes d analyse qui réalisent le cas d utilisation «Retirer de l argent». Nous pouvons observer l acteur «:Client de la banque» qui interagit avec les classes d interfaçage du système ; à leur tour ces classes interagissent avec les classes de contrôle et de données (entités) pour réaliser le service attendu. L informatisation de l entreprise 35/46 P-A. Sunier

36 Diagramme de classes de conception Nous voyons sur le diagramme ci-dessus, les classes de conception qui réalisent le cas d utilisation «Retirer de l argent». Comme précédemment, nous pouvons observer l acteur «:Client de la banque» qui interagit avec le système ; les classes de conception réalisent, en détail, les spécifications abstraites des classes d analyse comme illustré par le schéma de dépendance ci-dessous. 3 Cycle de vie 3.1 Préambule Le cycle de vie permet de passer de l idée d un logiciel à son utilisation régulière et ensuite à son obsolescence en parcourant des étapes ou phases de développement. Ces étapes ou phases peuvent être comparées à celle par lesquelles passe l être humain : la naissance, l enfance, l adolescence, l âge adulte, la vieillesse et la mort pour finir. Les méthodes n étant pas normalisées, le découpage du cycle de vie est souvent propre à chaque méthode et le nom de ces portions du cycle de vie sont multiples; nous trouvons couramment les termes d étapes ou de phases. Les méthodes classiques, telles que Merise, utilisent le terme d étape; les méthodes orientées objet, de part l unification d UP, ont adopté le terme de phase. Historiquement, chaque étape ou phase était parcourue une et une seule fois à l image de l humain qui passe à l enfance à l âge adulte en passant par l adolescence sans retour possible. L informatisation de l entreprise 36/46 P-A. Sunier

37 A chaque étape du développement du logiciel étaient associées une ou plusieurs activités qui n étaient plus jamais reconduites 37. Dans les étapes initiales étaient réalisées l analyse ou la conception et dans une étape postérieure, la programmation était réalisée sur la base d une conception qui se voulait définitive. Très vite, il est apparu que la linéarité d une telle démarche ne permettait pas le principe de rétroaction chère à la systémique; en l occurrence, ce n était qu à la programmation ou à livraison du produit final que des défauts d analyse ou de conception apparaissaient. Les incidences financières et autres de la découverte très tardive d erreurs d analyse ou de conception ont conduit à la perte de nombreux projets, services informatiques ou autres prestataires de service. 37 Une boucle de rétroaction chère à la systémique était possible depuis l étape subséquente. En fait chaque étape valide l étape qui la précède immédiatement. L informatisation de l entreprise 37/46 P-A. Sunier

38 Pour corriger les travers de la démarche linéaire sont apparus des modèles dits en spirales où les risques, quels qu ils soient, sont constamment traités au travers de bouclages successifs; chaque spire confirme et affine les spires précédentes en menant des activités de même nature successivement. L analyse ou la conception ne sont plus effectuées dans une seule phase ou étape mais sont conduites en tant qu activités qui se déroulent sur de multiples phases. Progressivement le cycle de développement ne s est plus décliné en étapes ou phases assimilées à des activités mais en phases de maturité du logiciel dans lesquelles, à la limite, chaque activité est conduite si nécessaire. Par exemple, dans les phases initiales il y aura une importante activité d analyse mais néanmoins un peu de programmation pour confirmer les choix architecturaux d analyse; et dans les phases finales, il y aura surtout de la programmation mais néanmoins aussi de l analyse pour les besoins qui n avaient pas été estimés prioritaires. Pour illustrer notre propos et en revenant à la métaphore de l humain du début, nous pouvons considérer que l apprentissage de la lecture se fait à l école primaire pendant l enfance; ainsi la phase «enfance» comporte l activité «apprentissage de la lecture» et cet apprentissage n est plus jamais reconduit. Dans la vision d une démarche de développement linéaire, l individu qui ne sait pas lire à l adolescence restera analphabète toute sa vie; dès lors, cet individu a peu de chance de pouvoir suivre une formation professionnelle et le risque est très grand de le voir se marginaliser. Dans une vision de développement itérative, la société prend conscience des risques induits par l analphabétisme; dès lors, et pour autant que cela soit nécessaire, l activité «apprentissage de la lecture» n est plus restreinte à la seule enfance mais à toutes les autres phases du développement de l individu y compris la vieillesse. Un vieillard qui ne sait ni lire, ni écrire risque de se refermer sur lui-même; l apprentissage de la lecture et de l écriture lui donnera des moyens supplémentaires de communiquer, particulièrement utiles, lorsque sa mobilité se trouve affectée par la vieillesse. Il en est de même pour la formation professionnelle, si elle est prioritairement le fait de l adolescence, elle doit pouvoir être reconduite à l âge adulte; c est tout l aspect très actuel du perfectionnement ou de la reconversion professionnelle. Le cycle de vie du développement de SII est aussi appelé cycle chronologique de développement de SII par certains auteurs comme [SJBB-00]. Pour notre part, nous utilisons le terme de cycle de vie en référence à la méthode Merise qui est une des premières à avoir proposé le découpage du développement en 3 cycles : cycle de vie, cycle d abstraction et cycle de décision. L informatisation de l entreprise 38/46 P-A. Sunier

39 3.2 Cycle de vie en cascade (Merise) Le cycle de vie dit de la «cascade» date de 1970, il est l œuvre de Royce. Il s agit d un modèle linéaire. Toute étape est supposée n avoir de rétroaction que sur l étape qui la précède. L activité d une étape se réalise avec les résultats fournis par l étape précédente; ainsi, chaque étape sert de contrôle du travail effectué lors de l étape précédente. L utilisateur attend le déroulement complet du cycle de vie du logiciel pour vérifier, lors de la dernière étape, l adéquation entre ses exigences et le produit livré. A titre d exemple, nous reproduisons ci-après, les étapes du cycle de vie 38 présentées dans l ouvrage «La méthode Merise Tome 3 Gamme opératoire» de A. Rochfeld et J. Moréjon publié en [MERISE-3]. la production qui concerne une application particulière. Il est à noter que les étapes de Merise traitent le système d information par affinements successifs; ainsi, le schéma directeur s applique au système d information de l organisme dans son ensemble, l étude préalable s applique à un domaine ou département et ainsi de suite jusqu à Merise symbolise cette gradation des étapes par une pyramide; au sommet de la pyramide se trouve le plus général, c est-à-dire l entreprise et le schéma directeur et à la base de la pyramide se trouve le plus spécialisé, en l occurrence, l exploitation d une application particulière. 38 Le cycle de vie tel que l ouvrage le décrit et le présente graphiquement était déjà défini lors de l élaboration de la méthode en 1978/1979. L informatisation de l entreprise 39/46 P-A. Sunier

40 En 1978, Merise introduisait déjà les prémisses de différentiation entre découpage temporel du cycle de vie et activités menées à chaque étape; cette différentiation a été illustrée par un schéma devenu célèbre : «la courbe du soleil». Sur l axe horizontal se trouve le cycle de vie sous forme d état du système d information et sur l axe vertical, le cycle d abstraction, se trouve la représentation du système. Dans cet espace à 2 dimensions sont représentés les différentes activités 39, respectivement modèles, à réaliser. Appliquée à mauvais escient, la rigidité du modèle en cascade de Merise, a mené de nombreux projets à l échec; et, cette «courbe du soleil» a été caricaturée par certains comme le lancement du projet au lever du jour et son aboutissement au crépuscule donc bien après que l on en eut l utilité. En effet, appliquée sans discernement, le principe de la courbe du soleil comporte le risque de passer trop de temps à décrire l état actuel au détriment de la réalisation du nouveau système; donc de fournir une solution désuète et en retard. 39 Uniquement par souci de rigueur mais néanmoins avec le souci de ne pas perturber le lecteur, nous nous devons de mentionner que Merise qualifiait ces activités de «phases»; dans la terminologie originale de Merise, nous avions donc le couple : - étapes pour le découpage temporel; - phases pour les activités menées dans les différentes étapes. L informatisation de l entreprise 40/46 P-A. Sunier

41 3.3 Cycle de vie itératif Le cycle de vie itératif consiste à mener la plupart des activités de production du logiciel successivement dans chacune des phases du cycle de vie; la ou les premières itérations se concentreront sur la compréhension du métier et des besoins mais, incluront néanmoins aussi de l analyse et de la conception et dans une moindre mesure une réalisation de quelques prototypes qui seront mis en œuvre pour s assurer de la justesse des choix architecturaux. Le choix des premiers éléments du logiciel à réaliser doit être dicté par les risques les plus critiques encourus par le projet; la réalisation de ces premiers éléments doit donner l assurance que les risques identifiés sont maîtrisés ou maîtrisables. Pour garantir la maîtrise des risques, le cycle de vie en cascade s accompagne de la réalisation d artefacts de validation des choix architecturaux; ainsi, en plus des différents modèles graphiques, sont réalisés des maquettes et prototypes soumis pour validation aux utilisateurs. De même, lorsque le cadre du projet le permet, la mise en exploitation du logiciel est effectuée progressivement, au fur et à mesure de l avancement des itérations; ainsi, les utilisateurs peuvent quittancer le travail réalisé avant la livraison finale. Les différentes itérations peuvent être nommées en tant que phases ou faire partie de phases englobantes. A titre d illustration, nous reproduisons deux diagrammes «Phases & activités», le premier issu de la méthode RUP 40 et le deuxième issu de la méthode CDM 41. Il est à noter que le Processus unifié et RUP utilisent le terme de discipline en lieu et place d activité; ils réservent le terme «activité» pour décrire le travail à réaliser à l intérieur de phases et disciplines. Phases et disciplines du RUP 40 RUP : Déclinaison commerciale d IBM du Processus unifié (UP). 41 CDM : Oracle Custom Development Method - Méthode de développement de logiciel du constructeur Oracle. L informatisation de l entreprise 41/46 P-A. Sunier

42 De son côté, CDM utilise le terme de «processus» en lieu et place d activité; un «processus» de CDM est un enchaînement de «tâches» réalisées sur plusieurs phases. Phases, processus et tâches de CDM-Classic Remarque : Formellement, UP, RUP et CDM préconisent une mise à disposition du logiciel opérationnel aux utilisateurs seulement lors de la phase terminale. Ainsi, pour de nombreuses méthodes, les itérations ne concernent que les phases précédant la mise en exploitation; les itérations servent essentiellement à maîtriser les risques inhérents à la construction du logiciel et non aux risques induits par d éventuels changements organisationnels liés à son utilisation. 3.4 Cycle de vie en spirale Le cycle de vie en spirale est une démarche hautement itérative. La construction du SII se réalise par spires de fonctionnalités successives. Les premières couches, comme les premières itérations du cycle itératif, servent à réduire les risques identifiés, et simultanément à fournir les prototypes et/ou solutions opérationnelles offrant aux utilisateurs les services minimaux attendus. Les couches suivantes doivent permettre d élargir les services offerts pour atteindre progressivement la couverture complète des besoins tout en assurant la transition avec les éléments réalisés antérieurement. L informatisation de l entreprise 42/46 P-A. Sunier