Méthodologies de développement de logiciels de gestion

Dimension: px
Commencer à balayer dès la page:

Download "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 2013

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

Méthodologies de développement de logiciels de gestion

Méthodologies de développement de logiciels de gestion Méthodologies de développement de logiciels de gestion Chapitre 5 Traits caractéristiques des deux approches de méthodologie Présentation réalisée par P.-A. Sunier Professeur à la HE-Arc de Neuchâtel http://lgl.isnetne.ch

Plus en détail

Cours Gestion de projet

Cours Gestion de projet Cours Gestion de projet Méthodes de conduite de projet Version Date Auteur V1.8 Septembre 2007 Pascal HEYER 1 Méthodes de conduite de projet Ce document est publié sous la licence libre Creative Commons-BY-NC-SA

Plus en détail

Analyse et conception de systèmes d information

Analyse et conception de systèmes d information Analyse et conception de systèmes d information Présentation réalisée par P.-A. Sunier Professeur à la HE-Arc de Neuchâtel http://lgl.isnetne.ch Juin 2005 [SJB-02] Chapitre 3 1 Références Ce document a

Plus en détail

GESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET

GESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET GESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET 1 Tianxiao LIU Licence Professionnelle Réseaux & Sécurité Université de Cergy-Pontoise http://depinfo.u-cergy.fr/~tliu/lpg.php PLAN Objectif et

Plus en détail

Le génie logiciel. maintenance de logiciels.

Le génie logiciel. maintenance de logiciels. Le génie logiciel Définition de l IEEE (IEEE 1990): L application d une approche systématique, disciplinée et quantifiable pour le développement, l opération et la maintenance de logiciels. Introduction

Plus en détail

Projet en entreprise Cadrage du Projet de Fin d Etudes «Un projet informatique.»

Projet en entreprise Cadrage du Projet de Fin d Etudes «Un projet informatique.» Projet en entreprise Cadrage du Projet de Fin d Etudes «Un projet informatique.» Projet de fin d études 2 Sommaire OBJET DU DOCUMENT... 3 LES ETAPES DU PROJET... 4 ETUDE PREALABLE...5 1 L étude d opportunité...

Plus en détail

140. Modélisation des données Historisation

140. Modélisation des données Historisation Modélisation de logiciels de gestion 140. Modélisation des données Historisation 1 Préambule Dans les chapitres précédents, nous avons appris à concevoir des modèles de données relativement élaborés en

Plus en détail

Annexe sur la maîtrise de la qualité

Annexe sur la maîtrise de la qualité Version du 09/07/08 Annexe sur la maîtrise de la qualité La présente annexe précise les modalités d'application, en matière de maîtrise de la qualité, de la circulaire du 7 janvier 2008 fixant les modalités

Plus en détail

Gestion de Projet Informatique

Gestion de Projet Informatique Gestion de Projet Informatique Partie 3 : Cycles de vie de projet Licence d'informatique 3 ième Année Tianxiao Liu Université de Cergy-Pontoise 1 GPI T. LIU The earliest moment is when you think it is

Plus en détail

Chapitre 1 : Introduction aux bases de données

Chapitre 1 : Introduction aux bases de données Chapitre 1 : Introduction aux bases de données Les Bases de Données occupent aujourd'hui une place de plus en plus importante dans les systèmes informatiques. Les Systèmes de Gestion de Bases de Données

Plus en détail

Méthodes Agiles et gestion de projets

Méthodes Agiles et gestion de projets Méthodes Agiles et gestion de projets Eric LELEU Consultant Solutions Collaboratives Contact ericleleu@nordnet.fr Site Personnel http://home.nordnet.fr/~ericleleu Blog http://ericleleu.spaces.live.fr La

Plus en détail

1. Considérations sur le développement rapide d'application et les méthodes agiles

1. Considérations sur le développement rapide d'application et les méthodes agiles Chapitre 1 Introduction 1. Considérations sur le développement rapide d'application et les méthodes agiles 1.1 Rappel Longtemps les méthodes en cascade ou en V ont été opposées aux démarches empiriques

Plus en détail

Analyse,, Conception des Systèmes Informatiques

Analyse,, Conception des Systèmes Informatiques Analyse,, Conception des Systèmes Informatiques Méthode Analyse Conception Introduction à UML Génie logiciel Définition «Ensemble de méthodes, techniques et outils pour la production et la maintenance

Plus en détail

Concevoir des applications Web avec UML

Concevoir des applications Web avec UML Concevoir des applications Web avec UML Jim Conallen Éditions Eyrolles ISBN : 2-212-09172-9 2000 1 Introduction Objectifs du livre Le sujet de ce livre est le développement des applications web. Ce n est

Plus en détail

Le Processus RUP. H. Kadima. Tester. Analyst. Performance Engineer. Database Administrator. Release Engineer. Project Leader. Designer / Developer

Le Processus RUP. H. Kadima. Tester. Analyst. Performance Engineer. Database Administrator. Release Engineer. Project Leader. Designer / Developer Le Processus RUP Database Administrator Project Leader H. Kadima Performance Engineer Release Engineer Analyst Designer / Developer Tester Table des matières 1. De l artisanat à l industrialisation de

Plus en détail

Développement itératif, évolutif et agile

Développement itératif, évolutif et agile Document Développement itératif, évolutif et agile Auteur Nicoleta SERGI Version 1.0 Date de sortie 23/11/2007 1. Processus Unifié Développement itératif, évolutif et agile Contrairement au cycle de vie

Plus en détail

Services informatiques aux organisations

Services informatiques aux organisations I. APPELLATION DU DIPLÔME II. CHAMP D'ACTIVITÉ Services informatiques aux organisations Spécialité «Solutions logicielles et applications métiers» Spécialité «Solutions d infrastructure, systèmes et réseaux»

Plus en détail

Techniques de Développement

Techniques de Développement Techniques de Développement Quelques définitions relatives au développement de logiciel Sébastien Faucou Université de Nantes (IUT de Nantes, département Informatique) Licence Professionnelle Systèmes

Plus en détail

Business Project Management : Cycle de vie des documents et workflow

Business Project Management : Cycle de vie des documents et workflow Business Project Management : Cycle de vie des documents et workflow Iut de Tours Département Information-Communication Option Gestion de l Information et du Document dans les Organisations Page 1 sur

Plus en détail

Le Workflow comme moteur des projets de conformité

Le Workflow comme moteur des projets de conformité White Paper Le Workflow comme moteur des projets de conformité Présentation Les entreprises sont aujourd'hui soumises aux nouvelles régulations, lois et standards de gouvernance les obligeant à mettre

Plus en détail

Processus d Informatisation

Processus d Informatisation Processus d Informatisation Cheminement de la naissance d un projet jusqu à son terme, deux grandes étapes : Recherche ou étude de faisabilité (en amont) L utilisateur a une idée (plus ou moins) floue

Plus en détail

Génie logiciel (Un aperçu)

Génie logiciel (Un aperçu) (Un aperçu) (sommerville 2010) Laurent Pérochon INRA URH 63122 St Genès Champanelle Laurent.perochon@clermont.inra.fr Ensemble d activités conduisant à la production d un logiciel Sur un échantillon de

Plus en détail

Chapitre 9 : Informatique décisionnelle

Chapitre 9 : Informatique décisionnelle Chapitre 9 : Informatique décisionnelle Sommaire Introduction... 3 Définition... 3 Les domaines d application de l informatique décisionnelle... 4 Architecture d un système décisionnel... 5 L outil Oracle

Plus en détail

Licence en Informatique à Horraire Décalé. Cours Gestion de projet informatique Première partie

Licence en Informatique à Horraire Décalé. Cours Gestion de projet informatique Première partie Licence en Informatique à Horraire Décalé Cours Gestion de projet informatique Première partie 1 PLAN Introduction 1. Les concepts de base en management de projet : 3-33 2 Les processus du management de

Plus en détail

LA QUALITE, L ASSURANCE DE LA QUALITE ET LA CERTIFICATION ISO 9001

LA QUALITE, L ASSURANCE DE LA QUALITE ET LA CERTIFICATION ISO 9001 LA QUALITE, L ASSURANCE DE LA QUALITE ET LA CERTIFICATION ISO 9001 I/ HISTORIQUE DE LA QUALITE La qualité est un souci permanent de l homme depuis longtemps. Jusqu au XIX ème siècle, c est l ère artisanale

Plus en détail

Chapitre I : le langage UML et le processus unifié

Chapitre I : le langage UML et le processus unifié I. Introduction Les méthodes d analyse orientées objet sont initialement issues des milieux industriels. La préoccupation dominante de leurs auteurs est le génie logiciel, c est-àdire les principes et

Plus en détail

Introduction au génie logiciel

Introduction au génie logiciel Introduction au génie logiciel Guillaume Laurent ENSMM 2007 G. Laurent (ENSMM) Introduction au génie logiciel 2007 1 / 36 Plan du cours 1 Problématique du génie logiciel 2 Méthodes de développement logiciel

Plus en détail

Cette première partie pose les enjeux de la BI 2.0 et son intégration dans le SI de l entreprise. De manière progressive, notre approche situera le

Cette première partie pose les enjeux de la BI 2.0 et son intégration dans le SI de l entreprise. De manière progressive, notre approche situera le Partie I BI 2.0 Cette première partie pose les enjeux de la BI 2.0 et son intégration dans le SI de l entreprise. De manière progressive, notre approche situera le SI classique avec l intégration de la

Plus en détail

En face du commanditaire, on met un chef de projet qui connait le domaine (banque, administration, etc.)

En face du commanditaire, on met un chef de projet qui connait le domaine (banque, administration, etc.) Atelier «Science du projet» séance 4 8 novembre 2008 Compte rendu 1. Sébastien Larribe : la méthode AGILE, méthode de gestion de projet Sébastien Larribe part de l hypothèse que des méthodes de conception,

Plus en détail

Structure défendue par H. Fayol, qui met en avant l'unité de commandement : chaque individu n'a qu'un seul supérieur.

Structure défendue par H. Fayol, qui met en avant l'unité de commandement : chaque individu n'a qu'un seul supérieur. Structure défendue par H. Fayol, qui met en avant l'unité de commandement : chaque individu n'a qu'un seul supérieur. Découpage des activités (et donc des responsabilités) par fonctions, par unités de

Plus en détail

Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION

Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION Classe de terminale de la série Sciences et Technologie du Management et de la Gestion Préambule Présentation Les technologies de l information

Plus en détail

Conception, architecture et urbanisation des systèmes d information

Conception, architecture et urbanisation des systèmes d information Conception, architecture et urbanisation des systèmes d information S. Servigne Maître de Conférences, LIRIS, INSA-Lyon, F-69621 Villeurbanne Cedex e-mail: sylvie.servigne@insa-lyon.fr 1. Introduction

Plus en détail

O RMATION. Ingénierie Système Management de Projet Évaluation de la Maturité

O RMATION. Ingénierie Système Management de Projet Évaluation de la Maturité PLANS F de O RMATION Ingénierie Système Management de Projet Évaluation de la Maturité O R G A N I S A T I O N ACTEURS CONCERNÉS Les concepteurs de systèmes doivent détecter, analyser les besoins des utilisateurs,

Plus en détail

Direction Générale des Études Technologiques. Institut Supérieur des Etudes Technologiques de Djerba Département Technologies de l informatique

Direction Générale des Études Technologiques. Institut Supérieur des Etudes Technologiques de Djerba Département Technologies de l informatique Direction Générale des Études Technologiques Institut Supérieur des Etudes Technologiques de Djerba Département Technologies de l informatique Génie Logiciel Mejdi BLAGHGI m.blaghgi@gmail.com Chapitre

Plus en détail

La démarche qualité dans sa dimension humaine

La démarche qualité dans sa dimension humaine La démarche qualité dans sa dimension humaine Agadir-Maroc 15 décembre 2007 Thierry LONGEAU www.alcantis.fr Thierry LONGEAU Dirigeant du cabinet Alcantis Experts en systèmes d informations et de gestion

Plus en détail

Novembre 2013. Regard sur service desk

Novembre 2013. Regard sur service desk Novembre 2013 Regard sur service desk édito «reprenez le contrôle grâce à votre service desk!» Les attentes autour du service desk ont bien évolué. Fort de la riche expérience acquise dans l accompagnement

Plus en détail

INDUSTRIALISATION ET RATIONALISATION

INDUSTRIALISATION ET RATIONALISATION INDUSTRIALISATION ET RATIONALISATION A. LA PROBLEMATIQUE La mission de toute production informatique est de délivrer le service attendu par les utilisateurs. Ce service se compose de résultats de traitements

Plus en détail

25/12/2012 www.toubkalit.ma

25/12/2012 www.toubkalit.ma 25/12/2012 www.toubkalit.ma 1 Définition Exemple des méthodes agiles Valeurs Principes Le cycle itératif et incrémental (Itération/Sprint) Schéma de travail Méthode Scrum. Méthode XP (Extreme programming).

Plus en détail

Entrepôt de données 1. Introduction

Entrepôt de données 1. Introduction Entrepôt de données 1 (data warehouse) Introduction 1 Présentation Le concept d entrepôt de données a été formalisé pour la première fois en 1990 par Bill Inmon. Il s agissait de constituer une base de

Plus en détail

16 Fondements du pilotage

16 Fondements du pilotage $YDQWSURSRV Le pilotage des systèmes de production est un sujet qui revêt une importance grandissante, au fur et à mesure que l automatisation de ceux-ci d une part, la multiplication des contraintes de

Plus en détail

Informatiques. Module : Outils RAD

Informatiques. Module : Outils RAD Management de Projets Informatiques Module : Outils RAD Niveau : S4 du L2/ISIL Génie Logiciel Le terme génie logiciel (en anglais software engineering) désigne l'ensemble des méthodes, des techniques et

Plus en détail

Management de l Innovation

Management de l Innovation Management de l Innovation Mention du Master Sciences et Technologies de l Université Pierre et Marie Curie Directeur du Département de Formation : Patrick Brézillon Contact secrétariat : 01 44 39 08 69

Plus en détail

Gestion Projet. Cours 3. Le cycle de vie

Gestion Projet. Cours 3. Le cycle de vie Gestion Projet Cours 3 Le cycle de vie Sommaire Généralités 3 Séquentiel 7 Itératif/Incrémental 17 Extreme Programming 22 Que choisir? 29 Etats Transverse 33 Cours 3 2006-2007 2 Généralités Cours 3 2006-2007

Plus en détail

Projet Informatique. Philippe Collet. Licence 3 Informatique S5 2014-2015. http://deptinfo.unice.fr/twiki/bin/view/linfo/projetinfo201415

Projet Informatique. Philippe Collet. Licence 3 Informatique S5 2014-2015. http://deptinfo.unice.fr/twiki/bin/view/linfo/projetinfo201415 Projet Informatique Philippe Collet Licence 3 Informatique S5 2014-2015 http://deptinfo.unice.fr/twiki/bin/view/linfo/projetinfo201415 Réalisation d'un développement de taille conséquente? r Firefox? Ph.

Plus en détail

Modélisation Principe Autre principe

Modélisation Principe Autre principe Modélisation Principe : un modèle est une abstraction permettant de mieux comprendre un objet complexe (bâtiment, économie, atmosphère, cellule, logiciel, ). Autre principe : un petit dessin vaut mieux

Plus en détail

Généralités sur les bases de données

Généralités sur les bases de données Généralités sur les bases de données Qu est-ce donc qu une base de données? Que peut-on attendre d un système de gestion de bases de données? Que peut-on faire avec une base de données? 1 Des données?

Plus en détail

Enquête 2014 de rémunération globale sur les emplois en TIC

Enquête 2014 de rémunération globale sur les emplois en TIC Enquête 2014 de rémunération globale sur les emplois en TIC Enquête 2014 de rémunération globale sur les emplois en TIC Les emplois repères de cette enquête sont disponibles selon les trois blocs suivants

Plus en détail

La Certification de la Sécurité des Automatismes de METEOR

La Certification de la Sécurité des Automatismes de METEOR 1 La Certification de la Sécurité des Automatismes de METEOR 2 un mot sur METEOR 3 Le projet METEOR, c'est... un système automatique complexe fortement intégré matériel roulant, équipements électriques,

Plus en détail

Agile 360 Product Owner Scrum Master

Agile 360 Product Owner Scrum Master Agile 360 Product Owner Scrum Master Lead Technique Equipe Agile Conception Agile Leadership Agile Software Craftmanship Test Driven Development Catalogue 2013 Liste des formations Formation Agile 360

Plus en détail

M E S. Organiser et suivre la performance de ses ateliers

M E S. Organiser et suivre la performance de ses ateliers M E S. Organiser et suivre la performance de ses ateliers Lorraine La nécessité de «piloter au plus juste» les équipements et les ateliers est à l origine de la naissance des logiciel de Manufacturing

Plus en détail

Architecture d'entreprise : Guide Pratique de l'architecture Logique

Architecture d'entreprise : Guide Pratique de l'architecture Logique Guides Pratiques Objecteering Architecture d'entreprise : Guide Pratique de l'architecture Logique Auteur : Version : 1.0 Copyright : Softeam Equipe Conseil Softeam Supervisée par Philippe Desfray Softeam

Plus en détail

Extrait du site de l'oseo (ex.anvar) http://www.anvar.fr/projlanc.htm. Reste à déterminer les points incontournables

Extrait du site de l'oseo (ex.anvar) http://www.anvar.fr/projlanc.htm. Reste à déterminer les points incontournables Extrait du site de l'oseo (ex.anvar) http://www.anvar.fr/projlanc.htm Notez que vous trouverez les fiches citées à chaque étape sur le site (Normalement, les liens ont été conservés et fonctionnent) Reste

Plus en détail

Topologie du web - Valentin Bourgoin - http://www.valentinbourgoin.net. Méthodes agiles & SCRUM

Topologie du web - Valentin Bourgoin - http://www.valentinbourgoin.net. Méthodes agiles & SCRUM Méthodes agiles & SCRUM 1/ Pourquoi les méthodes agiles? Définition d une méthode agile. Fondamentaux. Quand les utiliser? 2/ SCRUM En quoi est-ce une méthode agile? Sprints et releases. Le Product Owner.

Plus en détail

Séance 1 Méthodologies du génie logiciel

Séance 1 Méthodologies du génie logiciel Séance 1 Méthodologies du génie logiciel Objectifs : Histoire du développement du logiciel. La crise du logiciel. Explorer les différentes méthodologies de développement. Comprendre l importance d adopter

Plus en détail

MANAGEMENT PAR LA QUALITE ET TIC

MANAGEMENT PAR LA QUALITE ET TIC Garantir une organisation performante pour satisfaire ses clients et ses partenaires, telle est la finalité d une certification «qualité». On dénombre de nombreux référentiels dont le plus connu et le

Plus en détail

Les méthodes itératives. Hugues MEUNIER

Les méthodes itératives. Hugues MEUNIER Les méthodes itératives Hugues MEUNIER INTRODUCTION. Toute les méthodes ont le même but : la maîtrise du budget, du planning et de la qualité des projets de développement informatique Plusieurs approches

Plus en détail

MANAGEMENT PAR LA QUALITE ET TIC

MANAGEMENT PAR LA QUALITE ET TIC MANAGEMENT PAR LA QUALITE ET TIC Lorraine Garantir une organisation performante pour satisfaire ses clients et ses partenaires, telle est la finalité d une certification «qualité». On dénombre de nombreux

Plus en détail

BACHELOR OF SCIENCE INFORMATICIEN-NE DE GESTION

BACHELOR OF SCIENCE INFORMATICIEN-NE DE GESTION Informatique de gestion BACHELOR OF SCIENCE HES-SO BACHELOR OF SCIENCE INFORMATICIEN-NE DE GESTION Plans d études et descriptifs des modules Filière à plein temps et à temps partiel Table des matières

Plus en détail

La démarche qualité dans sa dimension humaine

La démarche qualité dans sa dimension humaine La démarche qualité dans sa dimension humaine Fédérer, responsabiliser votre personnel autour d un projet commun. Un outil intelligent de management. Séminaire démarche qualité en hôtellerie, 23/01/07

Plus en détail

IFT2255 : Génie logiciel

IFT2255 : Génie logiciel IFT2255 : Génie logiciel Chapitre 6 - Analyse orientée objets Section 1. Introduction à UML Julie Vachon et Houari Sahraoui 6.1. Introduction à UML 1. Vers une approche orientée objet 2. Introduction ti

Plus en détail

Contrôle interne et organisation comptable de l'entreprise

Contrôle interne et organisation comptable de l'entreprise Source : "Comptable 2000 : Les textes de base du droit comptable", Les Éditions Raouf Yaïch. Contrôle interne et organisation comptable de l'entreprise Le nouveau système comptable consacre d'importants

Plus en détail

URBANISME DES SYSTÈMES D INFORMATION

URBANISME DES SYSTÈMES D INFORMATION FAYCAL AYECH GL2. INSAT 2010/2011 INTRODUCTION AUX SYSTÈMES D INFORMATIONS URBANISME DES SYSTÈMES D INFORMATION De l Urbanisme à L Urbanisation des SI Urbanisme : Mise en œuvre des politiques urbaines

Plus en détail

Quelle organisation pour développer? Les principes et les valeurs de l extreme programming

Quelle organisation pour développer? Les principes et les valeurs de l extreme programming Les principes et les valeurs de l extreme programming XP sont bons 1 Principes Revue de code Production systématique de cas tests Refactoring Solutions simples Métaphores Intégration quotidienne cycles

Plus en détail

Plan d études du CAS SMSI Volée 2014

Plan d études du CAS SMSI Volée 2014 Plan d études du CAS SMSI Volée 2014 SIE Système d information d entreprise Crédits ECTS : 2 Périodes : 32 «Le module SIE a pour objectif de faire connaître les fondements théoriques du système d information

Plus en détail

Méthodes de développement

Méthodes de développement 1 / 9 Méthodes de développement Méthodes agiles 1 - Introduction... 2 2 -Le manifeste agile et les méthodes agiles... 2 2.1 Le manifeste agile... 2 2.2 Les méthodes agiles... 3 3 - Caractéristiques communes

Plus en détail

Regard sur hybridation et infogérance de production

Regard sur hybridation et infogérance de production Regard sur hybridation et infogérance de production Février 2014 édito «comment transformer l hybridation des infrastructures en levier de performances?» Les solutions d infrastructure connaissent depuis

Plus en détail

Projet : Plan Assurance Qualité

Projet : Plan Assurance Qualité Projet : Document : Plan Assurance Qualité 2UP_SPEC_DEV1 VERSION 1.00 Objet Ce document a pour objectif de définir la démarche d analyse et de conception objet ainsi les activités liées. Auteur Eric PAPET

Plus en détail

Qu'est-ce que le BPM?

Qu'est-ce que le BPM? Qu'est-ce que le BPM? Le BPM (Business Process Management) n'est pas seulement une technologie mais, dans les grandes lignes, une discipline de gestion d'entreprise qui s'occupe des procédures contribuant

Plus en détail

Le géomarketing - Page 1 sur 7

Le géomarketing - Page 1 sur 7 Le géomarketing - Page 1 sur 7 LES DOSSIERS MADWATCH.net méthodes Le Géomarketing Novembre 2003 Nb de pages : 7 Le géomarketing - Page 2 sur 7 Créé dans les années 80, la plupart des applications du géomarketing

Plus en détail

Ingénierie des méthodes Agiles : Que cache l opposition entre déploiement et livraison en continu? Faut-il adopter DevOps 1?

Ingénierie des méthodes Agiles : Que cache l opposition entre déploiement et livraison en continu? Faut-il adopter DevOps 1? DEVOPS et le déploiement d application Les Livres Blancs de MARTE Ingénierie des méthodes Agiles : Que cache l opposition entre déploiement et livraison en continu? Faut-il adopter DevOps 1? L alignement

Plus en détail

FILIÈRE METHODOLOGIE & PROJET

FILIÈRE METHODOLOGIE & PROJET FILIÈRE METHODOLOGIE & PROJET 109 Gestion de projet METHODOLOGIE ET PROJET Durée 3 jours Conduite de projet COND-PRO s Intégrer les conditions de réussite d une démarche de management par projet. Impliquer

Plus en détail

CONDUITE D UN PROJET INFORMATIQUE. C.Crochepeyre Conduite d un projet Cnam-Diapason 1

CONDUITE D UN PROJET INFORMATIQUE. C.Crochepeyre Conduite d un projet Cnam-Diapason 1 CONDUITE D UN PROJET INFORMATIQUE C.Crochepeyre Conduite d un projet Cnam-Diapason 1 1. ORGANISATION Etude préalable Gestion de quatre paramètres: les ressources humaines les ressources matérielles les

Plus en détail

COBIT (v4.1) INTRODUCTION COBIT

COBIT (v4.1) INTRODUCTION COBIT COBIT (v4.1) Un référentiel de «bonnes pratiques» pour l informatique par René FELL, ABISSA Informatique INTRODUCTION Le Service Informatique (SI) est un maillon important de la création de valeur dans

Plus en détail

Développement spécifique d'un système d information

Développement spécifique d'un système d information Centre national de la recherche scientifique Direction des systèmes d'information REFERENTIEL QUALITE Procédure Qualité Développement spécifique d'un système d information Référence : CNRS/DSI/conduite-proj/developpement/proc-developpement-si

Plus en détail

Méthode Agile de 3 ème génération. 2008 J-P Vickoff

Méthode Agile de 3 ème génération. 2008 J-P Vickoff PUMA Essentiel Méthode Agile de 3 ème génération 1 Structure de la présentation PUMA Essentiel méthode Agile de 3 ème génération Quelques principes Agiles Principales pratique Agile de pilotage Structure

Plus en détail

Gestion de projet Agile. STS IRIS Module 4.2 - «Gérer et organiser un projet informatique»

Gestion de projet Agile. STS IRIS Module 4.2 - «Gérer et organiser un projet informatique» Gestion de projet Agile Module 4.2 - «Gérer et organiser un projet informatique» Sommaire Introduction Principes et méthodes Agiles Scrum 2 Introduction Gestion de projet : démarche structurante assurant

Plus en détail

Nos Solutions PME VIPDev sont les Atouts Business de votre entreprise.

Nos Solutions PME VIPDev sont les Atouts Business de votre entreprise. Solutions PME VIPDev Nos Solutions PME VIPDev sont les Atouts Business de votre entreprise. Cette offre est basée sur la mise à disposition de l ensemble de nos compétences techniques et créatives au service

Plus en détail

Les problèmes de mise en œuvre d un SIH

Les problèmes de mise en œuvre d un SIH Les problèmes de mise en œuvre d un SIH N.Qarmiche 1*, K.Amzian 2, M.Berraho 1, Z.Srhier 1, K.El Rhazi 1, S.El Fakir 1, N.Tachfouti 1, C.Nejjari 1 1 Laboratoire d Epidémiologie et Santé Publique, Faculté

Plus en détail

ITIL V3. Transition des services : Principes et politiques

ITIL V3. Transition des services : Principes et politiques ITIL V3 Transition des services : Principes et politiques Création : janvier 2008 Mise à jour : août 2009 A propos A propos du document Ce document de référence sur le référentiel ITIL V3 a été réalisé

Plus en détail

Introduction au développement du logiciel

Introduction au développement du logiciel Introduction au développement du logiciel Vers le génie logiciel Université de Nantes Master Miage M1 Plan 1 Introduction 2 Génie logiciel 3 Projet informatique 4 Méthode de développement 5 Qualité Bibliographie

Plus en détail

Le management des risques de l entreprise Cadre de Référence. Synthèse

Le management des risques de l entreprise Cadre de Référence. Synthèse Le management des risques de l entreprise Cadre de Référence Synthèse SYNTHESE L incertitude est une donnée intrinsèque à la vie de toute organisation. Aussi l un des principaux défis pour la direction

Plus en détail

Conduite de projets SI. Les méthodes «Agiles» N QUAL/1995/3660e ORESYS

Conduite de projets SI. Les méthodes «Agiles» N QUAL/1995/3660e ORESYS Conduite de projets SI Les méthodes «Agiles» N QUAL/1995/3660e ORESYS Agilité : de quoi parle-t-on? Agilité de l entreprise Urbanisme Architectures SOA Agilité du SI ERP Plateformes applicatives agiles

Plus en détail

LA GESTION DE PROJET INFORMATIQUE

LA GESTION DE PROJET INFORMATIQUE Structurer, assurer et optimiser le bon déroulement d un projet implique la maîtrise des besoins, des objectifs, des ressources, des coûts et des délais. Dans le cadre de la gestion d un projet informatique

Plus en détail

FORMATION. Connaître les exigences réglementaires appliquées aux Systèmes d Information. 1 JOUR soit 7 heures. Réf.AQ-Q1

FORMATION. Connaître les exigences réglementaires appliquées aux Systèmes d Information. 1 JOUR soit 7 heures. Réf.AQ-Q1 Réf.AQ-Q1 Les Systèmes d'information des entreprises réglementées font l'objet d'exigences spécifiques. Celles-ci sont souvent difficiles à appréhender pour les spécialistes métier de l'assurance Qualité,

Plus en détail

Nom-Projet MODELE PLAN DE MANAGEMENT DE PROJET

Nom-Projet MODELE PLAN DE MANAGEMENT DE PROJET Nom-Projet MODELE PLAN DE MANAGEMENT DE PROJET Glossaire La terminologie propre au projet, ainsi que les abréviations et sigles utilisés sont définis dans le Glossaire. Approbation Décision formelle, donnée

Plus en détail

1 L adéquation des systèmes d information actuels

1 L adéquation des systèmes d information actuels 1 L adéquation des systèmes d information actuels 1.1 Le contexte de la question 1.1.1 La tendance à l omniprésence informatique LG : Les «objets communicants» vont générer énormément d informations de

Plus en détail

Conduite de projets et architecture logicielle

Conduite de projets et architecture logicielle s et architecture logicielle ABCHIR Mohammed-Amine Université Paris 8 15 février 2011 1/36 ABCHIR Mohammed-Amine (Université Paris 8) Conduite de projets et architecture logicielle 15 février 2011 1 /

Plus en détail

Les ressources numériques

Les ressources numériques Les ressources numériques Les ressources numériques sont diverses et regroupent entre autres, les applications, les bases de données et les infrastructures informatiques. C est un ensemble de ressources

Plus en détail

Université de Lausanne

Université de Lausanne Université de Lausanne Records management et archivage électronique : cadre normatif Page 2 Ce qui se conçoit bien s énonce clairement Nicolas Boileau Page 3 Table des matières Qu est- ce que le «records

Plus en détail

Communiqué de Lancement

Communiqué de Lancement Direction du Marketing Produits Sage - Division Mid Market Communiqué de Lancement Rapprochement Bancaire 1000 Produit : Rapprochement Bancaire 1000 Bases de Données : Oracle - MS/SQL Server Microsoft

Plus en détail

Gé nié Logiciél Livré Blanc

Gé nié Logiciél Livré Blanc Gé nié Logiciél Livré Blanc Version 0.2 26 Octobre 2011 Xavier Blanc Xavier.Blanc@labri.fr Partie I : Les Bases Sans donner des définitions trop rigoureuses, il faut bien commencer ce livre par énoncer

Plus en détail

CobiT. Implémentation ISO 270. Pour une meilleure gouvernance des systèmes d'information. 2 e édition D O M I N I Q U E M O I S A N D

CobiT. Implémentation ISO 270. Pour une meilleure gouvernance des systèmes d'information. 2 e édition D O M I N I Q U E M O I S A N D D O M I N I Q U E M O I S A N D F A B R I C E G A R N I E R D E L A B A R E Y R E Préface de Bruno Ménard, président du Cigref CobiT Implémentation ISO 270 2 e édition Pour une meilleure gouvernance des

Plus en détail

ERP5. Gestion des Services Techniques des Collectivités Locales

ERP5. Gestion des Services Techniques des Collectivités Locales Gestion des Services Techniques des Collectivités Locales Cte 1 2 P 3 s tio T 4 m ilg h trc c n p.o 5 re u fe ro a le tio c M S tw u aa c e O 2 Relation Citoyen Interventions Patrimoine Core Ressources

Plus en détail

Nouvelles fiches métier en BAP F : Analyse et traitement des données scientifiques

Nouvelles fiches métier en BAP F : Analyse et traitement des données scientifiques 23 23 Nouvelles fiches métier en BAP F : Analyse et traitement des données scientifiques Assistant Ingénieur en traitement de données scientifiques Ingénieur d'études en traitement de données scientifiques

Plus en détail

ITIL V3. Objectifs et principes-clés de la conception des services

ITIL V3. Objectifs et principes-clés de la conception des services ITIL V3 Objectifs et principes-clés de la conception des services Création : janvier 2008 Mise à jour : juillet 2011 A propos A propos du document Ce document de référence sur le référentiel ITIL V3 a

Plus en détail

Conduite de projets informatiques Développement, analyse et pilotage (2ième édition)

Conduite de projets informatiques Développement, analyse et pilotage (2ième édition) Avant-propos 1. Objectifs du livre 13 2. Structure du livre 14 Un projet informatique 1. Les enjeux 17 1.1 Les buts d'un projet 17 1.2 Les protagonistes d'un projet 18 1.3 Exemples de projets 19 2. Les

Plus en détail

Soyez agile. Dans l industrie du logiciel, la. De plus chaque projet informatique

Soyez agile. Dans l industrie du logiciel, la. De plus chaque projet informatique Soyez agile Dans l industrie du logiciel, la gestion de projet est confrontée à de nombreux défis. Le principal est de pouvoir assurer l adéquation d un produit et de ses fonctionnalités avec les besoins

Plus en détail

Jean-Pierre Vickoff. 2008 J-P Vickoff

Jean-Pierre Vickoff. 2008 J-P Vickoff Agilité étendue Jean-Pierre Vickoff 1 Structure de la présentation PUMA Essentiel méthode Agile de 3 ème génération Le mouvement Itératif-Incrémental (Agile) Agilité étendue au SI et PUMA Essentiel Entreprise

Plus en détail

Génie logiciel. Concepts fondamentaux. Bruno MERMET, Université du Havre 1

Génie logiciel. Concepts fondamentaux. Bruno MERMET, Université du Havre 1 Génie logiciel Concepts fondamentaux Bruno MERMET, Université du Havre 1 Nécessité du Génie Logiciel Bruno MERMET, Université du Havre 2 Développement d un logiciel Caractéristiques souhaitées : Adéquation

Plus en détail