Académique Documents
Professionnel Documents
Culture Documents
MEMOIRE
Pour lAccs au Grade dIngnieur En Chef
Thme
Janvier 2011
ROYAUME DU MAROC
MEMOIRE
Pour L'Accs Au Grade D'Ingnieur En Chef
Janvier 2011
Prpar par : M. Badr TALAGHZI Ingnieur d'Etat Grade Principal la Direction du Budget
A
Mes chers parents Ma chre femme Mes chers frres et surs Mes amis Et tous ceux que jaime et que je respecte
Je ddie ce travail
II
REMERCIEMENTS
Je remercie le Directeur du Budget pour m'avoir permis de raliser ce mmoire. Je remercie Mr M. LAMJOUN chef de la Division Systme d'Information la DB, Mme M. ZAHIR chef du Service Dveloppement Systme Mtiers la DB, Mme M. OUCIBLE chef du Service Banque Mondiale la DB, Mr A. FATHI chef du Service de l'Architecture du Systme d'Information la DB et Mr M. CHIKHI chef du service informatique la DEPP pour leurs conseils constructifs et l'intrt quils ont accord ce travail. Je remercie l'ensemble des personnes qui ont bien voulu rpondre mon questionnaire et celles qui ont eu l'amabilit de m'accorder des entrevues. Je remercie mes amis et collgues de la division du systme d'information pour leurs commentaires constructifs et remarques intressantes. Je remercie toutes les personnes qui ont contribu de prs ou de loin la ralisation de ce travail. Je remercie les membres du jury pour avoir accept de juger ce travail.
III
IV
RESUME
La gestion du processus de dveloppement logiciel de la Direction du Budget (DB) repose sur une coute attentive et permanente de lensemble des services. Cette approche permet de cerner lvolution des besoins de la direction, dapprcier lapport de linformatique et de dceler les projets aptes rpondre aux attentes des utilisateurs en matire de traitement dune information riche et diversifie et de renforcement de la capacit dexpertise de la direction. Par ailleurs, le processus de dveloppement d'un systme d'information est soumis aux exigences accrues des utilisateurs, des contraintes de prennit et l'volution des technologies informatiques. Le travail prsent dans ce mmoire s'inscrit dans le cadre de l'tude du processus de dveloppement logiciel au sein de la DB. Cette tude sarticule autour de trois axes principaux : Le premier axe dcrit la cartographie du systme dinformation de la DB et le processus du dveloppement de ce systme. ce stade, nous avons men une enqute sur les mthodologies du dveloppement logiciel auprs des cadres et des responsables de la DSI de la DB afin d'enrichir l'analyse du processus de dveloppement logiciel. Le deuxime axe expose le fruit de la recherche bibliographique des principaux rfrentiels standards et mthodologies du dveloppement logiciel. Enfin, le troisime axe synthtise l'enqute mene auprs des structures informatiques marocaines afin d'examiner les pratiques de dveloppement logiciel mises en uvre par les chefs de projet. Nous proposons par la suite un rfrentiel des bonnes pratiques de dveloppement logiciel et une dmarche de sa mise en uvre.
VI
ABSTRACT
The management of software development process of Direction of Budget (DB) is based on careful and permanent listening to all services. This approach allows us to identify the changing needs of the direction, evaluate the contribution of IT and identify suitable projects to meet user expectations on information processing rich and diverse and on building the ability of the direction expertise. Moreover, the process of software development is subjected to increasing demands of users, and the constraints of continuity and the evolution of computer technology. The work presented in this report is a part of the study of the process of software development in DB. This study is about three main axes: The first axis describes the mapping of the Information System of the DB and it presents the process of developing this system. We did a survey of methodologies of software development with executives and officials from the DIS1 of the DB in order to enrich the analysis of the software development process of the DB. The second axis describes the result of a literature search of the main methods and standards of software development. Finally, the third axis summarizes the survey of Moroccan IT structures to discuss the software development practices implemented by their project leaderships. Then; we provide a repository of good practices of software development and the approach of its implementation.
VII
VIII
. . . . : . . .
IX
SOMMAIRE
LISTE DES FIGURES LISTE DES TABLEAUX LISTE DES ACRONYMES XV XVII XVIII
Introduction gnrale
1. 2. 3. 4. Contexte du projet Objectif du projet Mthodologie du travail Contenu du mmoire 2 3 3 4
2.
CHAPITRE I CHAPITRE II
3.
4. 5.
6.
2.
XI
3.
4.
Analyse du processus de dveloppement logiciel de la DB Prsentation et analyse des rsultats de lenqute 3.1. 3.1.1. Environnement de lenqute 3.1.2. Profils des rpondants 3.1.3. Environnement de travail 3.1.4. Activits des rpondants 3.1.5. Mthodes et organisation 3.1.6. Difficults rencontres 3.1.7. Perspectives damlioration Synthse de l'tude 3.2. 3.2.1. Points forts du processus de dveloppement logiciel 3.2.2. Points d'amlioration au processus du dveloppement logiciel Conclusion
38 38 38 39 39 40 42 44 46 49 49 50 52
2.
CHAPITRE III
3. 4.
XII
3. 4.
CHAPITRE IV
5. 6. 7. 1. 2. 3. 4.
Benchmarking
Objectif du Benchmarking Dfinition des mesures du Benchmarking Identification du Benchmark Collection des donnes de la cible du Benchmarking Prsentation de l'enqute 4.1. Dmarche et enjeux de l'enqute 4.2. Synthse du Benchmarking Environnement de l'enqute 5.1. Environnement de l'organisme 5.2. Projet informatique 5.3. Dmarrage du projet informatique 5.4. Management du projet informatique 5.5. Processus de dveloppement 5.6. 5.6.1. Le dveloppement 105 105 105 106 106 106 107 107 107 110 112 114 116 116
CHAPITRE V
5.
XIII
6. 7.
5.6.2. La documentation Utilisation du produit 5.7. Conclusion des rpondants 5.8. Tmoignages Conclusion
CHAPITRE VI
5. 1. 2. 3.
CHAPITRE VII
4. 5. 6. 7.
XIV
8 15 27 29 33 35 38 39 39 39 40 40 40 41 41 42 42 42 43 43 43 44 44 45 45 45 46 47 47 48 48 55 66 67 68 69 71 73 80 84
XV
Figure 4-3 Figure 4-4 Figure 4-5 Figure 5-1 Figure 5-2 Figure 5-3 Figure 5-4 Figure 5-5 Figure 5-6 Figure 5-7 Figure 5-8 Figure 5-9 Figure 5-10 Figure 5-11 Figure 5-12 Figure 5-13 Figure 5-14 Figure 5-15 Figure 5-16 Figure 5-17 Figure 5-18 Figure 5-19 Figure 5-20 Figure 5-21 Figure 5-22 Figure 5-23 Figure 5-24 Figure 5-25 Figure 5-26 Figure 5-27 Figure 5-28 Figure 5-29 Figure 5-30 Figure 5-31 Figure 5-32 Figure 5-33 Figure 6-1 Figure 6-2 Figure 7-1 Figure 7-2 Figure 7-3
Historique des CMM Relations entre diffrents rfrentiels Les cinq processus du Management du Projet dans PMBOK Mode de rponse au questionnaire Rpartition des organismes par secteur d'activit Fonctions des rpondants Rpartition des tailles des DSI Nombre d'utilisateurs du systme d'information Projet informatique initi au sein des organismes enquts Initiateurs des projets informatiques dans les organismes enquts Pilotes des projets informatiques dans les organismes enquts La taille des projets informatiques Clart des objectifs des projets informatiques Degr de prcision de l'expression des besoins fonctionnels Dlai de ralisation des projets informatiques Planification des projets informatiques Le choix technique des outils de dveloppement Le choix de l'quipe de travail Le choix de l'organisation du travail Mthodologie de gestion de projet informatique Type de production d'application informatique Les technologies informatiques utilises Relations avec la matrise d'ouvrage Le contrle qualit Les dmarches qualit Gestion des changements des besoins fonctionnels Mode des livraisons des projets informatiques Les mthodes de dveloppement Les mthodes d'analyse Utilisation des dmarches structures dans les tests Documents labors dans le cadre des projets informatiques Niveaux de la documentation des projets informatiques Niveaux deffort fourni lors de lutilisation du produit logiciel Degr de satisfaction du matre d'ouvrage de la qualit du produit logiciel Rpartition globale de leffort dans la production logiciel Niveaux de la russite du projet informatique Gestion des projets informatiques de la DB Diagramme de squence de dveloppement du systme d'information Analyse de la performance oprationnelle de la DB Organisation du projet de changement du processus de dveloppement logiciel Planning prvisionnel de ralisation
90 93 100 107 108 109 109 110 110 111 111 112 112 113 113 114 115 115 116 116 117 117 118 118 119 119 120 120 121 121 122 122 123 123 124 124 132 134 150 157 159
XVI
Tableau 2-1 Tableau 3-1 Tableau 3-2 Tableau 3-3 Tableau 4-1 Tableau 4-2 Tableau 4-3 Tableau 4-4 Tableau 5-1 Tableau 6-1 Tableau 6-2 Tableau 7-1 Tableau 7-2
Rpartition des rpondants par structure Description des tapes du cycle de vie logiciel Les principes du manifeste agile Diffrences entre approche traditionnelle et approche agile Les domaines du processus du CMMi Les cinq catgories d'activits SPiCE Les Processus des deux principaux domaines d'ITIL Les processus du Management du Projet dans PMBOK Liste des dpartements participants l'enqute Liste des documents labors par la DB lors dun projet de dveloppement Formalisme de prsentation des documents Plan de communication du projet de changement Budget estimatif du projet
XVII
XVIII
INTRODUCTION GENERALE
INTRODUCTION GENERALE
INTRODUCTION GENERALE
1. Contexte du projet
Le dveloppement logiciel dsigne le processus consistant btir des applications informatiques, qu'elles soient labores par l'entreprise pour son propre compte ou par un diteur qui les commercialise [JNET 2011]. En perptuelle maturation depuis l'mergence de l'informatique dans les annes 1950, ce processus s'appuie sur diffrentes mthodes qui ont connu une nette volution damlioration. Cependant, de nombreux diteurs de logiciels se sont toujours exprims sur le sujet, proposant des mthodes trs riches et systmiques, mais souvent inutilisables vu la complexit de leur mise en uvre, elles sont utilises en dbut de projet, au prix defforts extrmes, mais rapidement abandonnes. Le dveloppement logiciel spcifique consiste produire un systme rpondant aux besoins mtiers et contribuer la performance des individus et de lentreprise. Nanmoins, selon le Standish Group [STANDISH 2010], quatre raisons majeures sont la source des checs des projets de dveloppement logiciel : Les spcifications fonctionnelles sont incompltes et la gestion des besoins est mal mene; Le manque de communication entre le matre duvre et le matre douvrage ; Le manque de ractivit face au changement continu des spcifications fonctionnelles ; Linexistence de la gestion des risques dans les projets de dveloppement logiciel. Dans son schma directeur informatique, la Direction du Budget (DB) a fait le choix stratgique du dveloppement spcifique de son Systme dInformation (SI), elle investit beaucoup de temps et de ressources dployer ses systmes informatiques car elle gre des volumes importants de donnes sensibles et complexes. Lvolution des mtiers de la DB en liaison avec la mise en place de diffrentes rformes des processus budgtaires, les besoins en termes douverture de son SI avec les partenaires internes et externes du Ministre de lEconomie et des Finances et le positionnement de la Direction du Budget en tant que maillon principal dans la gestion des finances publiques exigent le dploiement d'un systme dinformation performant, efficient et agile. La gouvernance du systme d'information et la dfinition des rfrentiels des procdures mtiers de la DB sinscrivent parmi les directives du Schma Directeur Informatique (SDI) (2009-2012) de la DB
[DELOITTE 2009].
INTRODUCTION GENERALE
Informatique de la DB a prsent la ncessit davoir un rfrentiel des procdures mtiers relatives au dveloppement logiciel au sein de la direction. En consquence, il est impratif davoir une grande matrise de la chane de production des SI et principalement le processus du dveloppement qui prsente une tape trs importante. Dans ce contexte, la mise en place dun cadre normalis de dveloppement savre ncessaire pour assurer une production de logiciel respectant les dlais et la qualit exige, et facile maintenir pour garantir une bonne ractivit notamment en priode de prparation du Projet de la Loi de Finances (PLF).
2. Objectif du projet
Conformment aux directives du SDI da la DB, le prsent mmoire a pour objectif de proposer la Direction du Budget un rfrentiel des mthodes, outils et modles devant amliorer le dveloppement logiciel, dans la perspective dhabiliter la Division du Systme dInformation (DSI) assurer ladquation du logiciel produit par rapport aux attentes des utilisateurs, accrotre sa qualit et respecter les dlais de sa production. Ceci se traduit par les axes suivants: La proposition dun modle de dveloppement de logiciel qui met en adquation les besoins lis au dveloppement avec les attentes de la DB ; La proposition dune organisation des acteurs de dveloppement logiciel ; La mise en place des outils de pilotage au profit du chef de projet, ces outils lui permettent de crer des plans ralistes et les mettre en place, de mesurer l'avancement du logiciel et de faire le lien entre lavancement du projet et latteinte des objectifs ; La gestion des risques et la gestion des changements dans les projets de dveloppement logiciel ; La proposition des modles de forme et de contenu des documents accompagnant le cycle de vie de dveloppement logiciel.
3. Mthodologie du travail
Ce travail a dbut par une description du systme dinformation de la DB, tout en mettant l'accent sur la problmatique du dveloppement logiciel au sein de la DB. Par la suite, une tude du processus de dveloppement logiciel a t labore. Cette tude a t enrichie par une enqute sur lorganisation et les mthodes du travail au sein de la DSI, les diffrentes activits de lquipe informatique de la DB, et les perspectives damlioration du processus de dveloppement logiciel la DB. Une recherche bibliographique sur les diffrentes 3
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
INTRODUCTION GENERALE
mthodologies de dveloppement de logiciel et les dmarches qualit dans les systmes dinformation a t ralise afin d'tablir une maquette des principaux rfrentiels standards et mthodologies de dveloppement logiciel existants. Le travail a t complt par une enqute auprs des structures responsables des systmes dinformation des organisations externes la DB, ce qui nous a permis de raliser un Benchmarking des diffrentes pratiques mises en uvre par les chefs de projet dans leurs processus de dveloppement logiciel. Le fruit de ce travail a conduit llaboration dun guide de bonnes pratiques de dveloppement logiciel dont la mise en uvre sera planifie pour les projets de dveloppement futurs prvus par la DSI.
4. Contenu du mmoire
Ce travail a abouti la rdaction du prsent mmoire, il est compos de sept chapitres : 1. Le premier chapitre est consacr au rappel des principales missions de la Direction du Budget, lorganisation de la Division des Systmes dInformation et la description de la cartographie du systme dinformation de la DB. Il expose galement la problmatique du dveloppement logiciel au sein de cette direction ; 2. Le second chapitre examine les principales composantes et organes de pilotage dans le management des projets de dveloppement logiciel la DB, il expose les rsultats de l'enqute mene sur la mthode de dveloppement au sein de la DSI et analyse le processus de dveloppement logiciel au sein de la DB ; 3. Le troisime chapitre est ddi la prsentation des concepts fondamentaux des mthodologies de dveloppement traditionnelles et celles agiles, afin de mettre en vidence les diffrences entre les deux mthodes ; 4. Le quatrime chapitre prsente les dmarches qualit dans les systmes dinformation et particulirement celles du dveloppement logiciel, il sera ensuite procd une tude de la conformit des mthodes de dveloppement ces dmarches qualit ; 5. Le cinquime chapitre est consacr au Benchmarking des pratiques de dveloppement de logiciel dans des structures responsables des systmes dinformation dans les organismes externes la DB. Il nonce la synthse de lenqute mene auprs de ces derniers ; 6. 7. Le sixime chapitre dcrit la mthodologie de l'laboration du guide des bonnes pratiques de dveloppement logiciel spcifique la DB et expose le contenu du guide propos ; Et enfin, le septime chapitre aborde les conditions de la mise en uvre du nouveau rfrentiel et les modalits de la conduite du changement. 4
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
1.2.
La Direction du Budget est structure autour de trois sous directions couvrant les axes majeurs de ses attributions: DB1 : Sous Direction charge de la coordination des structures du financement des projets publics regroupant deux divisions et un service. DB2 : Sous direction charge de la coordination des structures du personnel, des pensions, des finances locales, de la normalisation, des ressources humaines, de la formation et des affaires gnrales ; avec cinq divisions (dont la Division du Systme dInformation) et un service. DB3 : Sous direction charge de la coordination des structures sectorielles et de synthse ; avec sept divisions. Le dtail de ces structures est fourni dans la figure 1-1:
Direction du Budget
DB 1 Sous Direction Charge de la Coordination des Structures de Financement des Projets Publics
DB 2 Sous Direction Charge de la Coordination des Structures du Personnel, des Pensions, des Finances Locales, de la Normalisation, du Systme d'Information, des Ressources Humaines, de la Formation et des Affaires Gnrales
Division Pensions
10
Vhicules Automobiles (TSAVA) E-Budget Parc Auto. A posteriori, le service assure l'laboration du support utilisateur et la formation des utilisateurs. Le service dispose d'une quipe de neuf ingnieurs et deux techniciens.
Dployer et mettre en exploitation les solutions informatiques dveloppes ou acquises; Mettre en uvre la politique de scurit prconise des infrastructures informatiques et
des systmes dinformation et leur intgrit ;
12
CHAPITRE I : CONTEXTE & PROBLEMATIQUE Mettre en place linfrastructure physique et logicielle ncessaire pour le dveloppement
et l'exploitation du patrimoine informationnel ;
13
3.2.
Le systme dinformation de la Direction du Budget constitue une architecture intgre qui brasse lensemble des activits, circuits et procdures de cette direction. Son informatisation sinscrit par consquent dans la dure compte tenu des moyens humains et matriels mobilisables pour y parvenir. Le processus dinformatisation de la Direction du Budget a donn naissance une panoplie dapplications couvrant lensemble des domaines de gestion de cette direction. La figure 1-2 prsente une cartographie des principaux groupes applicatifs de la Direction du Budget.
14
Pilotage
Excel
E-Budget Consultation
Oprations
Financement SIG Elaboration budgtaire E-Budget GID "TGR" Prparation LF E-Budget PLF
Echange
Support
Gestion du courrier
- Morasse - Indicateurs de
performances - Tableaux de concordance - Mesures budgtaires - Tableaux des effectifs Suivi de l'excution budgtaire E-Budget - Mouvement des crdits budgtaires - Mouvements des postes budgtaires - Gestion du parc
Dcisionnel
- Historique
budgtaire - Masse salariale E-Budget EPA Gestion des pensions
"Echanges TGR"
Rfrentiels
Nomenclatures budgtaires Nomenclatures "Bailleurs de fonds"
- Pensions
exceptionnelles
- Pensions de
rforme
Lgende
Application utilise Application Externe Application en cours de dveloppement
Figure 1-2: Cartographie des principaux groupes applicatifs de la DB En outre, la varit des activits de la Direction du Budget ainsi que son rle dintgrateur, exigent la disponibilit dun systme dinformation fiable, mme doffrir une vision la fois globale et sectorielle. Ainsi, la mise en place dun systme ouvert permet de vulgariser, renforcer et amliorer les moyens dexploitation de linformation. Le patrimoine applicatif de la DB couvre la quasi-totalit des mtiers se rapportant au budget de l'Etat. Il permet, notamment dapprhender : Les budgets de lensemble des dpartements couvrant 35 ministres et institutions, rpartis sur une centaine de Chapitres du Budget Gnral, les modifications apportes aux budgets initiaux sous forme darrts de fonds de concours, de dcrets portant prlvement sur le chapitre des dpenses imprvues, les virements de crdits ainsi que les dcisions de transfert aux tablissements et entreprises publics et autres organismes ; Lvolution des budgets annexes jusqu leur suppression en 2006 ;
15
Systme E-Budget
Le Systme E-Budget a t mis en ligne ; pour lensemble des dpartements ministriels, des SEGMA et des CST ; loccasion de la prparation du Projet de Loi de Finances pour lanne 2006. Il a permis de couvrir les processus dlaboration des morasses budgtaires. Compte tenu de louverture du "systme E-Budget" sur les partenaires du Ministre de lEconomie et des Finances, la scurit revt une grande importance. Elle a t prise en compte depuis la conception du systme et concerne essentiellement : Laccs rglement aux systmes oprationnels via des habilitations et des droits daccs; Lchange informationnel scuris par des techniques de cryptage de donnes ; Les procdures de sauvegarde et de restauration. Actuellement, le systme E-Budget compte plusieurs modules offrant un large ventail de fonctionnalits couvrant lensemble des domaines dactivits de la Direction du Budget: Prparation du Projet de la Loi de Finances Ce module sattache tous les aspects lis la prparation du Projet de Loi de Finances, notamment : La prise en charge des propositions budgtaires (dpenses et recettes) ; L'dition des lettres de cadrage du PLF aux dpartements ministrielles ; 16
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
Le module dlaboration des documents budgtaires de lEtat regroupe les fonctionnalits relatives : Llaboration des morasses de dpenses budgtaires : Fonctionnement et
Investissement ; Les ditions en arabe et en franais dlocalises des diffrents documents budgtaires. La dernire rforme de la nomenclature budgtaire qui sest porte sur lharmonisation de la codification administrative au niveau du chapitre budgtaire a permis lextension de ce module pour prendre en charges les budgets des SEGMA et des CST. Ce module a t mis en uvre en 2006. Elaboration des tableaux de concordance Ce module permet d'tablir les tableaux de concordance entre la codification des crdits reports de la loi de finance de l'anne antrieure avec celle de la loi de finance suivante. Il a t mis en uvre en 2007. Elaboration des tableaux des indicateurs Ce module permet d'diter les tableaux des indicateurs d'objectifs avec lesquels la Direction du Budget mesure la performance de ses objectifs savoir l'efficacit socioconomique, la qualit de service ou l'efficacit de gestion. Ce module a t produit pour accompagner la DB dans sa rforme de la gestion budgtaire axe sur les rsultats. Il a t mis en uvre en 2007. Elaboration des tableaux des effectifs du personnel de lEtat Ce module permet la prise en charge des diffrents mouvements (cration, transfert, transformation, suppression) ncessaire pour llaboration des tableaux annuels des effectifs des diffrents dpartements ministriels. Il a t mis en uvre en 2008. 17
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
Ce module vise lintgration des donnes sur les tablissements et entreprises publics caractres administratifs dans le systme E-Budget. Il permettra ainsi: La gestion des rfrentiels ; Llaboration du Budget des EPA ; La gestion des crdits Budgtaires ;
Systme de Gestion Intgr de la Dpense 3 Trsorerie Gnrale du Royaume 4
18
19
3.2.2. Le dcisionnel
Laxe Dcisionnel vise se rapprocher davantage des proccupations de ses utilisateurs (les structures de la direction) en leur offrant des outils plus adapts daide la prise de dcision. Linitiation du projet dcisionnel a t matrialise par la mise en oeuvre de deux chantiers prioritaires relatifs lhistorique budgtaire et la masse salariale. Ceci a t fait dans le cadre dune approche itrative par focalisation successive sur un ensemble de domaines. Actuellement, ces deux chantiers sont achevs et permettront de doter le MEF, travers la Direction du Budget, doutils mettant la disposition des utilisateurs mtiers : Lhistorique budgtaire intgrant les informations de lensemble des crdits ouverts des diffrentes Lois de Finances depuis 1990 jusquen 2010. Les donnes sont structures autour dun ensemble daxes danalyse permettant une lecture multidimensionnelle de linformation budgtaire (conomique, fonctionnelle, rgionale et administrative) ; Des donnes pour avoir une vision multidimensionnelle des dpenses de personnel, des effectifs budgtaires et des postes pourvus et analyser les carts entre la prvision et la ralisation des donnes y affrentes ; La gestion de la masse salariale du personnel de lEtat. Le portail du systme dcisionnel recense un effectif budgtaire qui dpasse les 700 000 fonctionnaires ventils selon le dtail le plus fin concomitamment aux effectifs rels lesquels sont coupls la rmunration. Cet inventaire est destin se doter des outils applicatifs ncessaires la prvision budgtaire ainsi que pour assurer une meilleure matrise de la masse salariale. Les tableaux des effectifs comportent galement les crations de postes budgtaires, les suppressions ainsi que les transformations/ transferts. 20
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
22
5.2.
Thmes de progrs
Les axes dvolution prvus dans lactuel schma directeur pour le systme dinformation de la DB ont t dfini comme suit [DELOITTE 2009] : Stratgie informatique : Dfinition des instances de gouvernance des systmes d'information, de formation et les indicateurs de suivi associs ; Dfinition des instances de pilotage de projet. Support au pilotage : Fourniture des fonctionnalits de pilotage ; Fourniture des outils d'aide la dcision oprationnelle aux structures mtiers. Systme d'information intgr support l'exercice mtier : Accompagnement des volutions du cadre budgtaire ; Support de la prparation des lois de finances ; Informatisation de la gestion budgtaire des tablissements publics ; Prise en charge de la gestion des financements extrieurs. Ouverture sur les partenaires : Mise en place des fonctionnalits d'change et d'intgration interne et externe. Rfrentiel, qualit et scurit : Dfinition des rfrentiels communs pour la nomenclature budgtaire, les procdures mtiers ; Dfinition de l'assurance qualit du service fourni par le systme d'information.
6. Conclusion
Dans le cadre de l'laboration du Schma Directeur Informatique, l'analyse de l'existant a dmontr l'existence des lacunes dans le processus de dveloppement logiciel la DB. Le Schma Directeur Informatique (2009-2012) de la DB a dsign, parmi ses directives, la gouvernance du systme d'information et la dfinition des rfrentiels des procdures mtiers 23
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
24
25
La mise en place de tout systme informatique ncessite la mise en uvre dune organisation adquate capable de lui assurer les facteurs de russite. Ds le dmarrage de cette opration, la Direction du Budget a opt pour une dmarche participative qui visait ladhsion du personnel au processus dinformatisation, do : Linstauration dun comit de direction, qui reprsente l'acteur cl dans le processus dinformatisation puisquil veille la planification, lordonnancement des priorits, larbitrage et finalement la conformit entre prvisions et ralisations ; La mise en place des commissions de liaison informatique regroupant les informaticiens et les utilisateurs afin dinitier, piloter et accompagner les projets informatiques tout au long de leur cycle de vie ; Linstitution dune entit informatique qui constitue le matre duvre de la mise en place et du pilotage oprationnel de lensemble des oprations lies linformatisation du systme dinformation de la Direction du Budget.
26
Figure 2-1: Organes mis en place pour le pilotage des projets informatiques
accompagner les utilisateurs dans son exploitation par les actions de formation et d'assistance. En conclusion, la figure 2-2 prsente un diagramme de squence illustrant le processus de pilotage des projets informatiques au sein de la Direction du Budget:
28
Figure 2-2: Diagramme de squence illustrant le processus du pilotage des projets informatiques au sein de la DB
1.2.
29
31
La figure 2-3 prsente le diagramme d'activits illustrant le processus de dveloppement logiciel au sein de la Direction du Budget.
32
33
CHAPITRE II : PROCESSUS DE DEVELOPPEMENT LOGICIEL DE LA DIRECTION DU BUDGET 2.1. Analyse et spcification des besoins
La phase de l'analyse et de spcification des besoins est dfinie sur le plan directeur labor par le comit directeur. Ces besoins s'alignent avec les besoins stratgiques de la Direction du Budget en matire d'informatisation et qui sont dclins sur le schma directeur informatique. Les exigences de la Direction du Budget en informatisation sont en gnral soit une intgration d'un nouveau module au systme E-Budget, soit un accompagnement de la direction sur une nouvelle rforme budgtaire telle que la budgtisation CDMT (Cadre de Dpense Moyen Terme).
2.2.
La Direction du Budget a opt, pour le dveloppement de son systme d'information, une architecture plusieurs couches. Cette architecture prsente dans la figure 2-4 comporte : La couche UI (User Interface) : couche de prsentation ; La couche Mtier (BLL : Business Logic Layer) : couche de service et dobjets mtiers ; La couche daccs aux donnes (DAL : Data Access Layer). Les composants UI dans le cadre de ce projet sont des formulaires Web et des contrles utilisateur affichant les donnes utilisateur et permettant leur saisie. Le module des composants mtier (BLL) inclut les classes implmentant la logique mtier ainsi que les rgles de gestion. Le module relatif aux entits mtier inclut la liste des entits mtier utilises pour le transport des informations entre les diffrentes couches. Le composant de la logique daccs aux donnes est une interface gnrique efficace entre la couche mtier et la base de donnes. Chaque couche offre ses services travers une interface de service prenant en charge les contrats de communication (communications axes sur des messages, des formats, des protocoles, la scurit, des exceptions, etc.). Lappel de ces services utilise des patterns de fabrication (Factory pattern) afin de garantir labstraction des entits et leur indpendance.
34
2.3.
Analyse fonctionnelle
Les spcifications fonctionnelles gnrales dcrivent les diffrents cas d'utilisation d'un processus mtier, elles sont labores par la commission de liaison informatique. Aprs leur validation, la Division des Systmes d'Information (DSI) prvoit le modle conceptuel, le modle logique, et le modle physique des donnes associes. La DSI utilise la mthode MERISE1 pour dresser les modles conceptuels, les modles logiques, et physiques des donnes. Il utilise aussi la modlisation UML2 pour laborer certains diagrammes UML, ces derniers constituent le squelette de l'analyse fonctionnelle.
1 2
Mthode franaise d'analyse, de conception et de ralisation de systmes d'information Unified Modeling Language (c'est un langage de modlisation graphique base de pictogrammes) BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
35
Le choix de la Direction du Budget pour le dveloppement s'est port sur la technologie Microsoft. Une exprimentation au sein de la DB entre la plateforme Microsoft Dot Net et J2EE1 a montr un succs de la premire notamment en termes de facilit dutilisation, rapidit de dveloppement et prsence dexpertise sur le march. Les dveloppeurs utilisent l'outil de dveloppement Microsoft Visual Studio Dot Net, la programmation est crite avec le langage de programmation C# puisqu'il est le mieux adapt pour le dveloppement des applications Web, ces dernires sont conues avec le langage ASP2 Dot Net. La gnration des entits de la couche d'accs aux donnes se fait automatiquement laide dune application Web nomme (GenereDAL). Cette dernire permet dattaquer la base de donnes et de gnrer pour chaque table la classe correspondante avec les mthodes de base CRUD3. Les requtes et les oprations de donnes sont implmentes sous forme de procdures stockes, afin d'amliorer les performances et la maintenance. Le dveloppement des modules de la couche mtier et de la couche de prsentation est partag entre les dveloppeurs de l'quipe du projet. Le chef de projet est responsable de l'intgration des diffrents modules livrs par son quipe, il assure la cohrence du produit final et gre les versions des diffrentes livraisons. Le code source des systmes est partag par toute lquipe. Une discipline manuelle permet le contrle des codes sources. En procdant ainsi, il est possible doublier ou dcraser des codes sources. Il serait bon dutiliser un outil spcialis dans le contrle des codes sources, afin de journaliser les modifications apportes au produit.
2.5.
Les tests
Les tests techniques sont raliss par le dveloppeur lui-mme. Le chef de projet assure le test technique de l'ensemble des modules intgrs au produit final.
1 2
Active Server Pages. Cest un standard mis au point par Microsoft permettant de dvelopper des applications Web dynamique.
3
CRUD: Les quatre lettres signifient Create, Read, Update et Delete: crer, lire, mettre jour et supprimer. BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
36
2.6.
Documentation
La documentation constitue le livrable de chaque tape en gestion de projet informatique, sa validation conduit la fin de cette tape. La Direction du Budget sest engage produire un certain nombre de document accompagnant la production du logiciel. Les diffrents livrables documentaires sont dcrits ainsi : Etude de lexistant : Cest un document qui analyse et prcise les qualits internes requises pour juger de la conformit du logiciel demand. Cahier des charges : Cest un document qui permet la matrise d'ouvrage d'exprimer son besoin de manire fonctionnelle indpendamment de toute solution technique. Il retrace les diffrentes maquettes du systme dinformation futur, ainsi que les rgles de gestion et les procdures du mtier informatiser. Manuel dutilisation informatique : Cest un document qui explique comment exploiter lapplication. Il est destin aux utilisateurs, et il est utilis lors des sessions de formation. La documentation technique de la DSI est formalise selon une structure qui contient les informations suivantes : Le titre du projet informatique ; Ltiquette du document produit ; La version du document ; Un historique des dates dlaboration de toutes les versions du document ; Les observations de ces versions.
37
3.1.
38
La DSI de la DB compte parmi ses cadres 62% diplms dcoles dingnieurs contre 25% ayant un diplme universitaire (cf. figure 2-7). 75% des cadres rpondants au questionnaire exercent leurs mtiers au sein de la DB depuis plus de 5 ans (cf. figure 2-8). Ce qui laisse conclure que le taux dencadrement de la DSI est trs lev, et que lexpertise et la comptence de lquipe informatique de la DB sont robustes.
Figure 2-9 : Nombre de participation des cadres de la DSI dans les projets informatiques
La majorit des projets informatiques (54% des rponses) au sein de la DSI dure en moyenne six mois un an (cf. figure 2-10). Les quipes informatiques de la DB sont des petites ou moyennes quipes (cf. figure 2-11).
On peut conclure que les projets informatiques de la DB sont de taille moyenne, cependant les cadres de la structure informatique de la DB travaillent sur plusieurs projets en parallle, ce qui accrot incontestablement leur charge du travail.
40
Figure 2-12 : Taux des participations dans les phases des projets informatiques de la DB
Concernant llaboration des documents techniques accompagnant les diffrentes phases des projets informatiques de la DB, 58% des cadres rpondants ce questionnaire interviennent dans ldition du cahier des charges et du manuel dutilisation informatique, 29% participent la production des documents de conception et du recueil de lexistant (cf. Figure 2-13).
Figure 2-13 : Taux des participations dans l'laboration des documents dans les projets informatiques de la DB
Pour la question concernant la mise jour de la documentation des projets informatiques, 70% des rdacteurs des documents techniques des projets informatiques de la DB affirment la mise jour de leurs documents chaque fois quune modification est apporte ces projets, 25% de cette population ne mettent jamais jour leurs documents (cf. figure 214). 41
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
Figure 2-14 : Frquence des mises jour des documents des projets informatiques de la DB
Gnralement, les cadres de la DSI participent massivement au dveloppement informatique et aux tests, ils laborent de manire conjoncturelle le cahier des charges fonctionnel et les documents dutilisation du produit.
Pour la question sur les mthodes de dveloppement informatique, 50% des rpondants indiquent quils utilisent leur propre mthode de dveloppement, contre 21% confirment lutilisation dune mthode de dveloppement traditionnelle et 25% disent quil ny a aucune mthode formelle de dveloppement informatique au sein de la DB (cf. figure 2-17). 42
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
Parmi les rponses sur lutilisation des mthodes danalyse et de conception, 54% confirment lutilisation dune mthode formelle danalyse et de conception savoir la mthodologie MERISE et / ou UML. 29% des cadres n'utilisent aucune mthode d'analyse (cf. figure 2-19). Ceci dmontre que la majorit des cadres participe la phase danalyse et de conception.
Figure 2-19 : Taux dutilisation des mthodes formelles dans la phase danalyse dans les projets informatiques de la DB
43
En conclusion, la Direction du Budget gre ses projets informatiques selon sa propre mthodologie, elle utilise une mthode de dveloppement traditionnelle laquelle, elle a ajout certaines pratiques propres la maison. Aucune norme nest instaure pour cadrer les activits de dveloppement informatiques de la DB. Les dveloppeurs participent la phase danalyse et de conception, cependant ils neffectuent que rarement la planification formelle des projets ou des analyses la fin de ces projets.
44
31% des cadres ayant rpondu cette section du questionnaire ont indiqu que le changement continu des spcifications fonctionnelles constitue llment majeur des checs de certains projets informatiques. 23% des rponses dclarent que le cahier des charges incomplet est la raison des checs. 14% ont reproch lchec la mauvaise attribution des responsabilits au sein de lquipe du projet et 7% des rponses ont tmoign que la raison des checs est la mauvaise estimation des cots et des dlais des projets (cf. figure 2-23). Pour la question portant sur les difficults rencontres lors de la production du logiciel la DB, 76% des rponses confirment que le changement des spcifications et la communication avec le matre douvrage prsentent les principales difficults du dveloppement informatique la DB, une minorit des cadres (12% des rponses) rencontrent des difficults dans la matrise des technologies et des outils informatiques danalyse et de dveloppement (cf. figure 2-24).
45
amliorer en premier ? 30% des rpondants ont choisi lamlioration de la mthode de travail en premier, 27% ont opt pour le changement de lorganisation, lamlioration de la communication vient aussi au second rang avec 27% des rponses, et seulement 12% des rpondants ont choisi damliorer la planification (cf. figure 2-25)
Les cadres de la DSI ont t invits nous indiquer la bonne dmarche du changement pour lamlioration du processus de dveloppement informatique, 59% des rponses prfrent adapter la mthodologie de dveloppement logiciel de la DB une mthodologie standard de dveloppement, contre 33% seulement prfrent certifier la DSI aux normes standards de dveloppement informatique (cf. figure 2-26).
46
Pour les besoins en formation continue, 71% des rponses expriment leur souhait de suivre une formation approfondie sur les normes et les mthodes de dveloppement, 63 % des rponses prfrent bnificier dune formation dans la communication, mme taux (63%) des rponses ont opt de se former sur la veille technologique et 42% des cadres souhaitent bnficier d'une formation sur les produits et les logiciels (cf. figure 2-27).
A la question Connaissez-vous quelques standards de certification? 67% des rpondants affirment connatre au moins une norme standard de certification. Ainsi, 54% des rpondants souhaitent suivre une formation en CMMi contre 42% veulent se former en ISO 9001 et 29% prfrent bnificier dune formation sur le standard SPiCE (cf. figure 2-28).
47
A la question Connaissez-vous une des mthodes agiles? Seulement 43% des rpondants affirment connatre une des mthodes de dveloppement informatique agiles. Cependant, 74% des rpondants indiquent leur volont de suivre une formation sur une ou plusieurs mthodes de dveloppement informatique agiles selon lordre suivant (1-Extrme Programming, 2- SCRUM, 3-Crystal Clear) (cf. figure 2-29).
Pour le travail en quipe, 50% des cadres ayant rpondu au questionnaire prfrent travailler dans une petite quipe (moins de trois personnes), les autres prfrent une quipe moyenne (entre trois et dix personnes), et 62% des dveloppeurs qui ont rpondu ce questionnaire acceptent dcrire le code informatique en binme. Les rponses collectes de cette section permettent de conclure que les cadres de la DSI sont trs motivs pour une amlioration de leur organisation et leurs mthodes de travail, la majorit prfre instaurer une dmarche standard de dveloppement logiciel, ainsi elle souhaite suivre des formations sur les normes et les mthodologies.
48
La DSI a brillamment accompagn la DB dans l'informatisation de ses processus mtiers depuis plus de 22 ans, elle a pu accumuler des russites incontestables en matire de production logiciel, elle a aussi trouv les cls de la russite. Cependant, certaines difficults s'imposent son mtier, la DSI est alors appele amliorer certaines procdures afin de parfaire l'excution de sa fonction.
49
50
51
4. Conclusion
La Direction du Budget accorde une importance particulire au dveloppement du systme dinformation ddi aux mtiers du budget, et ce pour tre en phase avec leur volution et de moderniser les mthodes et outils de travail des structures en charge de ces mtiers. Les axes damliorations relevs auprs des dveloppeurs dvoilent la ncessit de limplmentation dune dmarche standard de dveloppement. La Direction du Budget ne dispose pas dune certification une norme standard pour son processus de dveloppement de logiciel, notre objectif diverge de celles des certifications, on ne doit pas se passer de la russite des projets informatiques en mettant plus deffort respecter les normes. La DB pourrait oprer le choix des mthodes agiles comme solution pour le dveloppement de son SI, certaines pratiques des mthodes agiles ou des rfrentiels d'amlioration des processus tel que CMMi ou SPiCE pourraient apporter la DB des solutions adquates aux difficults rencontres lors du processus de dveloppement de son SI. La suite de ce mmoire, sera consacre ltude des diffrentes mthodologies et normes standards du dveloppement logiciel existantes. Puis elle sachvera par llaboration dun guide mthodologique de la DB aux bonnes pratiques de dveloppement logiciel, ce guide inspirera ses directives de certaines mthodes agiles ou quelques rfrentiels standards damlioration des processus.
52
53
quorganisationnelles
[SWEBOK 2004].
notre attention, afin de mettre en vidence les diffrences entre les approches traditionnelles et celles agiles.
On explora laspect de la gestion de projets, la composition des quipes, des outils et les standards de code. On en conclut que le logiciel est un produit trs complexe. La rduction du cot des machines et laugmentation des cots des logiciels ont permis de mettre lemphase sur cet aspect conomique
[COMPUTE 2010].
cours dun dveloppement logiciel, prs de 50% des efforts sont investis dans la gestion et le support, 15% pour le design, 20% pour la ralisation et 15% pour les tests (cf. figure 3-1) [NATO
1968].
La constatation du manque de structure pour ces projets a ouvert la porte une nouvelle
54
Figure 3-1 : Rpartition des efforts du dveloppement logiciel [Tir de NATO 1968]
Description
L'ETUDE DE FAISABILITE produit un document qui analyse les besoins et dfinit le mandat et les limites du systme. LE PLAN DE PROJET prsente travers le temps les diffrentes phases du projet, il prcise ses ressources, son dlai et son cot LES SPECIFICATIONS REQUISES analysent et prcisent les qualits internes requises pour juger de la conformit du produit. LES SPECIFICATIONS DU DESIGN, correspondent la dcomposition en modules et les relations quils ont entre eux. LANALYSE FONCTIONNELLE dtaille les units de programmation leur plus bas niveau, avant dtre cod. Lensemble des lments doit prcisment y tre spcifi. On y retrouve les maquettes dcran, les donnes exploites et le dtail des algorithmes. La programmation ralise Le Code Source, qui est le livrable de cette tape. UN PLAN DE TESTS UNITAIRES doit aussi tre produit pour valider le code. Lintgration consiste valider linteraction des units de programmation ensemble. UN PLAN DES TESTS SYSTEMES prvoit la vrification des changes entre les units et les modules du systme. Les interfaces modulaires sont testes ce niveau. La documentation explique comment exploiter lapplication. La DOCUMENTATION TECHNIQUE est destine ladministration du systme et la DOCUMENTATION DIDACTIQUE est destine aux utilisateurs, elle est utilise lors des sessions de formation. Limplantation est ltape de livraison du produit au client. Le logiciel doit tre install sur les machines de production relle. LE PLAN DIMPLANTATION guide les tapes suivre pour procder cette mise en opration Les utilisateurs doivent tre forms sur le nouveau systme, afin quils connaissent les fonctionnalits disponibles dans leur nouveau systme. LE PLAN DE FORMATION dtaille la stratgie et les moyens utiliss. Cette tape sert alimenter le nouveau systme partir de donnes existantes. Cellesci doivent tre converties dans un nouveau format. UN PLAN DE CONVERSION doit tre produit afin de spcifier les interfaces dimportation et lexportation des donnes existantes. Les tests dacceptation sont raliss par les pilotes ou les utilisateurs, afin de dapprouver le systme. UNE LISTE DES DEMANDES DE CORRECTIONS est rdige dans le but de corriger les lments non conformes aux attentes du client. Lors de la fermeture du projet de dveloppement, une vrification posthume rvise le droulement des diffrentes tapes. LE RAPPORT DE FIN DE PROJET explique les difficults rencontres et les bonnes pratiques retenir. Le suivi oprationnel assure le fonctionnement du systme. Des lments de surveillance permettent de contrler le fonctionnement. Le support consiste rpondre aux questions et complter la formation auprs de lquipe en charge de lexploitation ou des utilisateurs. La maintenance du systme permet de corriger les erreurs de conception et de complter ou dajouter des fonctionnalits. Le systme doit tre valu de manire rcurrente pour confirmer sa pertinence. travers le temps, de nouvelles opportunits peuvent comporter suffisamment davantages pour abandonner un systme dsuet.
Dveloppement
Analyse et spcifications des besoins Spcification du design (Architecture) Analyse fonctionnelle
Dploiement
Plan de dploiement
Formation
Conversion de donnes
Tests d'acceptation
Vrification posthume
Exploitation
Suivi Oprationnel et support
56
Le modle ad-hoc: Ce ft le premier moyen utilis au dbut de laire informatique, il est fond uniquement sur les comptences et l'exprience des membres du personnel effectuant les travaux
[CTG 1998].
[SEI 2010]
souligne qu'avec le modle Ad-hoc, les performances dpendent de la capacit des individus et varie en fonction de leurs comptences innes, leurs connaissances et leurs motivations. Il y a peu de processus logiciels stables en preuve, et le rendement peut tre prdit par individu plutt que la capacit organisationnelle.
Le modle en cascade: Ce modle a t mis au point ds 1966, puis formalis aux alentours de 1970
[CLV 2010].
lautre, il est hrit de l'industrie du BTP [Royce 1970]. La documentation est intgre chaque tape et des vrifications sont faites sur tous les livrables. Bien qu'il ait t attaqu ces dernires annes du fait de sa rigidit et son manque de son ralisme quand il s'agit des besoins urgents des clients, le modle en cascade est encore largement utilis. Il est considr comme base thorique pour d'autres modles de processus, parce qu'il ressemble plus un "gnrique" qu'un modle de dveloppement logiciel [CTG 1998].
Le modle en V: Il est une premire amlioration du modle en cascade. Il a t cr pour palier au manque de ractivit du modle en cascade. Il part du principe que les procdures de vrification de la conformit du logiciel aux spcifications doivent tre labores ds les phases de conception
[CVL 2010].
suivante. Les lments ncessaires la validation sont prpars lors des spcifications. Ce modle est devenu un standard depuis les annes 1980.
Le modle itratif : Les problmes du modle en cascade ont donn naissance au besoin d'une nouvelle mthode de dveloppement des systmes qui pourrait fournir des rsultats plus rapides, avec peu de renseignements, et d'offrir une plus grande flexibilit. Le modle itratif divise le projet en petites briques. Cela permet l'quipe de dveloppement de dmontrer des
57
Le modle par prototypage : Il ft cr du fait quil est difficile dobtenir les spcifications au dbut dun projet. Ce modle consiste construire une version rduite ou thorique du systme, afin dobtenir les approbations. Les commentaires permettent de raffiner les spcifications [CTG 1998]. Ce modle peut se greffer un modle en cascade ou itratif. Le modle en spirale: Le modle en spirale a t conu pour inclure les meilleures caractristiques des modles en cascade et par prototypage, il met cependant plus l'accent sur la gestion des risques. Le terme spirale est utilis pour dcrire la forme que prend le modle : une version initiale du systme est dveloppe, puis rpte et modifie en fonction des commentaires reus et des valuations des utilisateurs. Contrairement au prototypage, le modle est soigneusement conu pour chaque version produite en suivant les tapes du modle en cascade. Progressivement, en partant du centre de la spirale, une version plus complte est produite [CTG 1998]. Il faut tenir compte des diffrentes variables pour choisir un modle convenable et obtenir les bnfices attendus. Lenvironnement organisationnel et la nature de lapplication sont des facteurs importants pour choisir un modle.
discipline. Lorsque la discipline s'implante et se renforce, l'agilit apparat et invente. Il permet aux athltes de faire le jeu inattendu, aux musiciens d'improviser et d'orner, aux artisans de faire voluer leur style, et aux ingnieurs de s'adapter l'volution des technologies et des besoins. L'agilit applique la mmoire et l'histoire pour s'adapter aux nouveaux environnements. Elle ragit, s'adapte, prend l'avantage sur les possibilits imprvues, et elle met jour la base de l'exprience pour l'avenir.
59
2.1.2.
Origine
Devant lobservation faite du taux important dchec des projets, notamment dans les annes 1990, dix-sept experts en dveloppement logiciel, qui avaient chacun dj mis au point et expriment de nouvelles mthodes, se sont runis afin dchanger et de trouver un socle commun de valeurs et de bonnes pratiques. Ces premiers "Agilistes" se sont rencontrs au Centre de ski Snowbird en Utha, le 13 novembre 2001. Le rsultat de cette rflexion a abouti au Manifeste pour le dveloppement logiciel agile et la cration de lAgile Alliance, charge de promouvoir lagilit dans les organisations et dapporter du soutien aux quipes qui veulent dmarrer un projet agile [ROTA 2008; AGM 2001]. Par la suite, ils ont regroup une liste de principes pour enrichir le manifeste [Fowler 2006]. En 2005, la "Dclaration dinterdpendance" a t publie
[HIGHSMITH 2005],
et parmi ses
signataires, on retrouve les acteurs majeurs de lAgile Alliance. Cette communaut a formalis les valeurs mises en pratique qui les amenaient rencontrer tant de succs et de bons rsultats dans leurs projets.
2.1.3.
Le Manifeste agile
Le Manifeste dcline quatre valeurs dans toute dmarche agile. Chaque mthode adopte ensuite sa propre terminologie et prconise un certain nombre de pratiques. Les quatre valeurs du Manifeste sont [AGM 2001; LARMAN 2003; ROTA 2008; SEI 2008]: Les individus et leurs interactions avant les processus et les outils. Des fonctionnalits oprationnelles avant la documentation. Collaboration avec le client plutt que contractualisation des relations. Acceptation du changement plutt que conformit aux plans. Il faut noter que les valeurs mises en avant gauche n'excluent pas les valeurs droite.
2.1.4.
Aprs la rdaction du manifeste, une srie de principes prcisant leur vision a t dcrite, ces principes sont brivement prsents dans le tableau 3-2: 60
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
Description
Grce au dveloppement itratif, chaque livraison intermdiaire donne lieu une validation par le client ; son feedback est essentiel pour garantir la conformit de la livraison avec ses attentes, pour prendre en compte ses remarques et (re)prioriser. Cet tat desprit caractrise une quipe agile qui dmontre ainsi sa capacit comprendre et apprendre comment satisfaire encore mieux la demande. Une version intermdiaire du produit final, visible et testable, satisfait davantage le client quune documentation valider. Il a, de ce fait, la preuve tangible que le projet avance et peut exprimer son point de vue sur le rsultat prsent. Les relations conflictuelles ne font pas partie de lesprit agile ; on prfrera des relations collaboratives et de partenariat bases sur la confiance et le consensus. Le client (ou son reprsentant) est accessible et disponible, totalement impliqu dans toutes les phases du projet. Le facteur cl du succs dun projet est lquipe. Tout obstacle son bon fonctionnement devra tre lev ; un changement, sil savre ncessaire, sera apport aux processus, aux outils, lenvironnement, la composition de lquipe Par dfaut, on privilgie lchange oral lcrit, pour lever toute ambigut et favoriser la rapidit de la comprhension. Tout ne peut tre formalis par crit, notamment la "connaissance tacite", cest-dire linformation "informelle", la culture du projet, dtenues par chacun au sein dune quipe. Il nexiste pas dautre indicateur plus pertinent que le pourcentage ou le nombre dexigences satisfaites ; on ne mesure pas un projet la quantit de documents produits ou au nombre de lignes de code, non significatifs pour le client. La qualit du travail fourni dpend du rythme de travail qui doit tre adapt en fonction des spcificits du projet. Le rythme doit tre soutenu et soutenable sur la dure du projet. Ce rythme de travail est dterminer par lensemble des membres de lquipe et par le client, en fonction de la productivit de lquipe et des priorits du client. Mais travailler en heures supplmentaires, surtout pour corriger des bogues ou des rgressions, napporte aucune valeur ajoute. Maintenir un code propre, volutif et performant est un objectif permanent de lquipe ; il ne sagit pas de produire rapidement du code non exploitable par les autres. De plus, cela vite surtout denliser les dveloppements ultrieurs, avec des modifications cassant un dveloppement fragile, ncessitant des interventions des endroits varis du code. La simplicit garantit lvolutivit du systme. La complexit, au contraire, cote davantage et rend plus difficiles les volutions inhrentes au dveloppement incrmental. La conception ne doit comporter que des lments utiles. Le chef de projet agile nest plus celui qui attribue des tches. Lquipe, elle mme, se responsabilise et dfinit ses travaux raliser, le partage des tches seffectuant sur la base du volontariat Lenvironnement dun projet nest pas constant ; lquipe agile, qui en a conscience, sinterroge en permanence sur la faon damliorer son fonctionnement afin de sadapter aux nouvelles conditions. Cest aussi lacceptation du changement
La simplicit art de maximiser la quantit de travail fait inutilement est essentielle. Les meilleures architectures, spcifications et conceptions sont le fruit dquipes qui sauto organisent intervalles rguliers, lensemble de lquipe sinterroge sur la manire de devenir encore plus efficace, puis ajuste son comportement en consquence.
La "Dclaration d'Interdpendance" annonce que les membres de l'quipe de projet font partie d'un groupe interdpendant complet et non pas dun groupe d'individus non connects. Cela signifie que les quipes de projet, leurs clients et leurs parties prenantes sont aussi interdpendants. Les six concepts de l'interdpendance sont [HIGHSMITH 2005]:
Nous augmentons le retour sur investissement en faisant des flux continus de la valeur de nos proccupations. Nous fournissons des rsultats fiables en engageant les clients dans les interactions frquentes et en partageant nos ressources. Nous attendons l'incertitude et nous la grons par le biais d'itrations, l'anticipation et l'adaptation. Nous librons la crativit et l'innovation en reconnaissant que les individus sont la source ultime de la valeur, et en crant un environnement o ils peuvent faire une diffrence. Nous soutenons la performance en valuant les rsultats du groupe et en partageant la responsabilit pour l'efficacit des quipes. Nous amliorons l'efficacit et la fiabilit par les situations spcifiques des stratgies, des processus et des pratiques.
2.2.2.
Le second concept du Manifeste insiste sur un logiciel fonctionnel. Les fonctionnalits couvertes par le dveloppement du produit voluent et sadaptent aux changements. C'est principalement ce qui dmarque les produits issus des approches agiles. Les itrations permettent la dtection des anomalies et de les corriger au fur et mesure. Les carts entre le produit
62
2.2.3.
Le troisime concept du Manifeste souligne la collaboration avec le client. Dans le cas des projets agiles, la collaboration avec le client est essentielle. Le client est impliqu dans le projet et dtermine les priorits. La planification du projet volue et sadapte aux changements quil propose. Le client amne son retour d'exprience avec le produit, Il est plus sensible aux contraintes techniques. Cette collaboration permet doptimiser les solutions proposes.
2.2.4.
Le dernier concept du Manifeste met en avant l'adaptabilit. L'approche agile est inspire du modle itratif [ROTA 2008]. Toutes les parties du systme peuvent tre amliores au cours des itrations. Autrement dit, le modle itratif peut devenir une srie de cascades. Les planifications rcurrentes sur de courtes chances, permettent un meilleur suivi et diminuent les risques. Les lments doivent tre complts lintrieur dun cycle, ce qui vite ltirement des tches. Lintgration des tapes de ralisation (conception, codage et tests) contribue clore les fonctionnalits prvues. Les changements sont introduits lors de ces renouvellements. Au terme du projet, la somme des efforts de planification peut tre quivalente celle d'un projet traditionnel, mais rparti diffremment travers le temps.
de dveloppement dans lequel les membres de l'quipe et les clients sont gographiquement disperss peuvent dfavoriser la communication en face--face prconise par les processus agiles. Par consquent, l'utilisation des technologies comme la vido-confrence peuvent tre utiles, mais ces technologies peuvent tre moins efficaces et gnrent des investissements supplmentaires. La documentation devient la principale forme de communication. Limitations de la sous-traitance : L'externalisation des tches du dveloppement logiciel
est souvent base sur des cahiers de charges bien dfinis, le sous-traitant labore un plan qui prvoit le processus et les livrables pour faire une estimation du cot soumissionn dans son offre financire, ce qui dsavantage le changement adopt par le Manifeste agile. Pour y remdier, le cahier de charges du dveloppement agile devrait tre compos de deux parties : une 63
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
canaux de communication dans une grande quipe de dveloppement rduit l'efficacit des pratiques informelles telles que les communications face--face et des runions d'examen. Il peut y avoir des occasions pour utiliser des pratiques agiles, mais le degr de souplesse peut tre infrieur celle trouve dans les petites quipes. Limitations pour le dveloppement de logiciels complexes et critiques pour la scurit :
Les mcanismes de contrle de qualit soutenus par le processus agile (par exemple, les commentaires informels, la paire de programmation) ne sont pas suffisants pour garantir aux utilisateurs que le produit est scuris.
3.1.1.
Extreme Programming repose sur 4 valeurs fondamentales qui sont: La communication: la conversation directe face face est privilgie bien que le support crit reste un moyen de mmorisation. Le courage : Il est ncessaire tous les niveaux et de la part de tous les intervenants, notamment chez les dveloppeurs (lorsque des changements surviennent un stade avanc du projet ou quand des dfauts mergent) et chez le client (qui doit pouvoir prioriser ses demandes).
64
3.1.2.
Ces valeurs se dclinent en 12 pratiques [MOUSSA 2010]: Conception simple: Il faut dvelopper la solution la plus simple dont on a besoin. Refactoring: (remaniement du code) consiste nettoyer, purer le code en continu sans changer la fonctionnalit. Le refactoring est une pratique quotidienne de qualit et non une activit pisodique de rcriture. Tests unitaires & Tests de recette: Les tests unitaires sont crits avant le code par les dveloppeurs pour vrifier le bon fonctionnement du code. Les tests de recette (ou tests fonctionnels) sont conus par le client pour lui permettre de vrifier le bon fonctionnement du systme, daffiner lexpression de ses besoins et de contrler lavancement dans le projet. Pair programming: lcriture du code se fait deux sur la mme machine. Et ce pour amliorer la qualit du code, surmonter vite les difficults, diminuer la distraction. La rotation au quotidien des binmes implique une connaissance du code par toute lquipe. Ainsi, en cas de besoin toute personne peut oprer des changements. Responsabilit collective: toute lquipe est auteur du code et responsable de la qualit du code. Rgles de codage: des rgles de codage (normes de nommage, commentaires) sont dfinies et doivent tre suivies par tous les dveloppeurs. Cela facilite le travail en binmes et la responsabilit collective. Mtaphore: la mtaphore du projet est une description informelle du systme, permettant toute lquipe davoir une vision globale du systme. Intgration continue: aprs chaque fin de tache, le code nouvellement crit est intgr lexistant en sassurant que tous les tests de non rgression de lapplication passent 100%.
65
3.1.3.
Figure 3-3 : Processus XP au niveau de l'itration [Tir de XP 2010] Litration est un mini projet en soit. Les intrants de cette phase sont la liste des scnarios utilisateurs raliser lors de cette itration et les bugs rencontrs aux itrations prcdentes. En fonction de sa vlocit, lquipe estime ce quelle pourra livrer. Ces diffrents lments sont consolids, afin de composer le plan ditration. Les scnarios non-inclus seront raliss ultrieurement dans les prochaines itrations de la version. 67
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
Figure 3-4: Processus XP au niveau du dveloppement [Tir de XP 2010] Lactivit principale dXP reste le dveloppement. Le quotidien des dveloppeurs commence par la rencontre matinale (Stand Up Meeting) qui passe en revue les tches raliser suivant le plan ditration, ainsi que les tches prcdentes incompltes. Cest aussi lors de cette rencontre que les demandes trop exigeantes sont mises de ct dans la liste des choses complter. La proprit commune du code fait appel toutes les comptences de lquipe. Cest la pierre angulaire dXP, elle est explique plus en dtail dans le paragraphe suivant. Chaque dveloppeur apporte ses connaissances au projet, afin de partager les lments qui peuvent aider la ralisation des fonctionnalits. Cette tape du cycle XP peut livrer de nouvelles fonctionnalits qui russissent entirement leur suite de tests unitaires. La correction des erreurs est aussi valide au cours de cette pratique.
68
Figure 3-5 : Processus XP sur la proprit commune du code [Tir de XP 2010] La pratique de la proprit commune du code, est en fait la ralisation informatique des scnarios utilisateurs dcrits sur les cartes CRC (Classe, Responsabilit et Collaboration). Le design et la ralisation sont faits conjointement. Les dveloppeurs prennent connaissance de la tche raliser. Cette tche peut tre nouvelle ou provenir dune prcdente ayant chou lors du test dacceptation et que le client ne jugeait pas adquat. Les dveloppeurs commencent par prparer les tests unitaires qui leur permettront de vrifier le rsultat de la fonction quils produiront
3.2.
SCRUM
SCRUM est un processus de dveloppement logiciel agile. Il sinspire de sources diversifies. Il est une amlioration du processus itratif et de lapproche incrmentale pour le logiciel orient objet. SCRUM utilise un vocabulaire spcifique, nous le dfinissons ainsi : Backlog produit : Liste des lments techniques et fonctionnels produire dans un avenir prvisible pour le produit complet. Il inclue ce qui est dfini et ce qui reste prciser. Sprint backlog : Liste des lments techniques et fonctionnels produire au cours dun sprint. Cest un sous-ensemble du backlog produit. Elle comporte des lments suffisamment dfinis pour quils soient raliss au cours de la priode du sprint. Sprint : Une priode de 30 jours o un ensemble de travaux sont effectus pour crer un livrable.
69
3.2.1.
Ce processus se dcline principalement en trois phases: La Phase initiale est consacre prparer le travail faire avec une dmarche linaire. Cette phase doit construire la liste des lments que comportera la version du produit. Elle comporte les tapes suivantes : L'laboration du planning et de l'architecture du systme cible La mise en place dun backlog produit La dfinition de lquipe L'analyse des risques Budget
Les phases de sprints sont les phases itratives qui ralisent concrtement les lments qui composent le produit. Ce travail tant plus chaotique, il est aussi qualifi de bote noire . Elles se traduisent par les caractristiques suivantes : Un sprint backlog est slectionn, cette liste sera suivie et ralise. Priode denviron 30 jours, au cours de laquelle lquipe est isole des influences extrieures. Cest--dire que la liste des lments reste inchange. Runion quotidienne SCRUM. Et enfin, une runion post-sprint de prsentation des rsultats.
La Phase de clture, elle aussi est linaire et connue. Elle prpare la documentation, finalise les tests et rend la version fonctionnelle et prsentable.
3.2.2.
Processus de SCRUM
Le cycle de vie Scrum (figure 3-6) est rythm par des itrations de quatre semaines, les sprints ; la liste des exigences initiales, dresse et hirarchise avec le client constitue le rfrentiel, le product backlog.
70
Avant chaque sprint, au cours dune runion de planification, le sprint planning meeting, on slectionne, dans le product backlog, les exigences les plus prioritaires pour le client qui seront dveloppes, testes et livres au client ; elles constituent le sprint backlog, un sousensemble du product backlog. Au cours du sprint, chaque jour, une runion davancement le Scrum ou mle est organise avec tous les membres de lquipe pour sassurer que les objectifs du sprint seront tenus. la fin du sprint, une dmonstration des derniers dveloppements est faite au client (Sprint Review Meeting), puis une revue de fin ditration, une rtrospective, donne lieu un bilan qualitatif sur le fonctionnement de lquipe. SCRUM dfinit galement un certain nombre de rles au sein de lquipe, tendue au client: Le ScrumMaster : cest le manager du projet, charg dassister lquipe pour appliquer la philosophie et les pratiques de Scrum ; il est celui qui facilite la rsolution des problmes. Le Product owner : il est le propritaire du product backlog, en tant que reprsentant des utilisateurs et, par consquent, du retrait ou de lajout des exigences, de leur priorisation en fonction de la valeur ajoute quelles apportent aux utilisateurs et lorganisation. Il est fortement impliqu dans les runions de planification et davancement. Lquipe : elle est compose de tous les corps de mtier ncessaires limplmentation dune fonctionnalit. Elle est responsable de ses dcisions et sautogre.
71
Crystal Clear, ou plus exactement la famille de mthodologies Crystal, a t mise au point par Alistair Cockburn (signataire du Manifeste). Crystal Clear est une mthode ouverte qui permet dintgrer des pratiques provenant dautres mthodes. Le noyau de cette mthode est constitu des proprits appliques travers diffrentes stratgies et techniques [COCKBURN 2004].
3.4.
Le dveloppement rapide dapplications (RAD) est un gabarit de mthode. Il s'appuie principalement sur la ralisation de prototypes pour communiquer les concepts. La mthode RAD structure le cycle de vie du projet en 5 phases [VICKOFF 2010]: LInitialisation dfinit lorganisation, le primtre et le plan de communication. Le Cadrage dfinit un espace dobjectifs, de solutions et de moyens. Le Design modlise la solution et valide sa cohrence systmique. La Construction ralise en prototypage actif (validation permanente). La Finalisation est un contrle final de qualit en site pilote. En analysant les tapes de ralisation, le RAD ne se qualifie pas comme une mthode agile cause de son manque dadaptation aux changements
[RATO 2008; VTT 2002].
La planification
itrative ne vise pas livrer un produit fonctionnel incrmental. Il s'apparente plutt une srie de cascades. Il diverge aussi sur le retour d'exprience du client car, elle ne prvoit pas l'intgration de nouvelles demandes.
72
CHAPITRE III : METHODES TRADITIONNELLES Vs METHODES AGILES 3.5. Rational Unified Process (RUP)
Le RUP est le Rational Unified Process, la version "progicialise" du Processus unifi, dite et commercialise par Rational en 1998 pour complter sa suite logicielle. On connat, par la suite, lavenir de Rational, socit rachete par IBM, qui maintient rgulirement une version du RUP [RATO 2008]. Le RUP se dcompose en quatre phases:
parties prenantes sur la vision ou la porte du projet, le primtre et lestimation globale. laboration : la phase dlaboration a pour objectifs dtablir et de valider larchitecture
de rfrence, de lever les principaux risques ainsi que de spcifier en dtail les exigences; cest une phase exploratoire. Construction : la phase de construction a pour objectif de livrer une premire version
oprationnelle du systme, accompagne de sa documentation. Transition : la phase de transition a pour objectif de dployer et mettre en production la
version finale de lapplication, teste par les utilisateurs. Cette mthode est intimement lie son outil de conception et au formalisme UML, ce qui diverge des valeurs agiles. Dautres adaptations du RUP sont disponibles (AgileUP, EssUP, Essential UP, OpenUP).
3.6.
Autres mthodes
L'volution des mthodes de dveloppement donne naissance d'autres mthodes de dveloppement logiciel tel que : Lean Software Development (LSD): est une mthodologie de dveloppement agile, inspire de "Lean Manufacturing", elle a t adapte par Tom et Mary POPPENDIECK du systme de dveloppement de produits de Toyota [DZONE 2010].
73
collaboration, et apprentissage. Ce cycle dynamique propose un apprentissage continu et une adaptation a l'tat mergent du projet.
74
Thme
Cycle de vie Planification
Approche traditionnelle
En cascade ou en V, sans rtroaction possible, phases squentielles. Prdictive, caractrise par des plans plus ou moins dtaills sur la base dun primtre et dexigences dfinies et stables au dbut du projet. Produite en quantit importante comme support de communication, de validation et de contractualisation. Une quipe avec des ressources spcialises, diriges par un chef de projet. Contrle qualit la fin du cycle de dveloppement. Le client dcouvre le produit fini. Rsistance voire opposition au changement. Processus lourds de gestion des changements accepts. Mesure de la conformit aux plans initiaux. Analyse des carts. Processus distinct, rigoureux, de gestion des risques.
Approche agile
Itratif et incrmental. Adaptative avec plusieurs niveaux de planification (macro- et micro- planification) avec ajustements si ncessaires au fil de leau en fonction des changements survenus. Rduite au strict ncessaire au profit dincrments fonctionnels oprationnels pour obtenir le feedback du client. Une quipe responsabilise o linitiative et la communication sont privilgies, soutenue par le chef de projet Un contrle qualit prcoce et permanent, au niveau du produit et du processus. Le client visualise les rsultats tt et frquemment. Accueil favorable au changement inluctable, intgr dans le processus.
Documentation
quipe
Qualit
Changement
Mesure du succs
Un seul indicateur davancement : le nombre de fonctionnalits implmentes et le travail restant faire. Gestion des risques intgre dans le processus global, avec responsabilisation de chacun dans lidentification et la rsolution des risques. Pilotage par les risques. Satisfaction client par la livraison de valeur ajoute.
75
77
le management de la qualit de
l'ensemble du processus de dveloppement logiciel est le facteur cl pour l'obtention de la qualit logiciel dans les systmes informatiques complexes et d'importance critique pour les missions, tels que les systmes d'armes, systmes de communication et systmes de commandement et de contrle. Pour garantir la qualit du processus de dveloppement du logiciel, ces processus doivent tre planifis, matriss et amliors, avec l'objectif de rduire, d'liminer et, plus important encore, de prvenir les insuffisances de qualit du logiciel. On essayera dans ce chapitre de passer en revue les diffrents rfrentiels qui concernent les systmes d'information en se focalisant sur ceux qui s'intressent au processus de dveloppement logiciel, puis on tudiera la conformit des mthodes agiles aux normes certifies.
Un vnement important
va alors intervenir dans les annes 40, favorisant l'extension des principes de Schewart dans toute l'industrie amricaine : la deuxime guerre mondiale. La demande trs forte de production auprs de l'industrie amricaine partir de 1941, va en effet engendrer une diffusion et une gnralisation des techniques de contrles statistiques. 78
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
2. Dfinitions
2.1. Qualit
La norme [ISO-9000] nonce la qualit comme tant laptitude dun ensemble de caractristiques intrinsques dun produit, dun systme ou dun processus satisfaire les exigences des clients et autres parties intresses. On distingue entre qualit interne et externe. La seconde est fonction de la satisfaction du client et de lutilisateur final; la qualit interne pour un organisme se traduit par sa capacit raliser les oprations/activits conformment aux exigences et ceci du premier coup. La non qualit interne loblige reprendre les oprations nayant pas aboutit la qualit vise.
79
complmentaires: une augmentation de la capacit fonctionnelle a un impact ngatif sur la performance, la maintenabilit et la fiabilit. Tandis qu'une augmentation de la fiabilit, la maintenabilit ou de la disponibilit a un impact positif sur l'utilisabilit. En outre, une augmentation de la maintenabilit a un impact ngatif sur la performance.
CHAPITRE IV: DEMARCHE QUALITE DANS LES SYSTEMES D'IINFORMATION 2.3. Systme qualit
Il s'agit d'un ensemble structur et ouvert, d'lments en interaction, anim par une finalit (un but) et qui volue dans le temps tout en gardant son identit. Le systme qualit selon la norme [ISO 8402] se dfinit comme "l'ensemble de l'organisation, des procdures, des processus et des moyens ncessaires pour mettre en oeuvre le management de la qualit".
Exposer la structure documentaire utilise dans le cadre du systme qualit. 2.7. Dmarche qualit
Une dmarche qualit est un outil de changement crant une dynamique de progrs continu dans le fonctionnement de l'entreprise (qualit interne) et la satisfaction de ses clients (qualit externe). Cela favorise la prennit et le dveloppement de l'entreprise. Une dmarche qualit est avant tout un vritable projet d'entreprise participatif qui doit tre port par la direction et impliquer tout le personnel.
81
CHAPITRE IV: DEMARCHE QUALITE DANS LES SYSTEMES D'IINFORMATION 2.8. Management de la qualit totale (TQM)
Le management de la qualit totale ou tout simplement Qualit Totale est une approche globale du management relatif la qualit qui se concentre sur la rponse aux besoins client et sur les objectifs organisationnels. Son ide de base est que lentreprise entire: culture, organisation, processus et attitude quotidienne du personnel, soit continuellement implique dans l'amlioration de la qualit des produits et services rendus. La qualit totale ou TQM (Total Quality Management) reprsente la matrise, lamlioration et lanticipation: du management de lentreprise; de la satisfaction des besoins des clients; des produits ou services; des oprations; de la participation du personnel; des rsultats pour le client, lentreprise, le personnel et la communaut. La TQM impose de puissants bouleversements dans l'organisme, c'est donc le dirigeant qui doit initier cette dmarche. Il doit s'engager personnellement et dployer les moyens ncessaires sa russite. La TQM se base sur six principes fondamentaux: Le leadership ou l'engagement de la direction, Une vision partage, comme culture forte et mobilisatrice, La mthode du dploiement : dcliner en orientation d'actions les orientations stratgiques au niveau des directions, services, branches et individus, L'coute du client de faon quantitative mais surtout qualitative, pour aller la rencontre des nouveaux besoins, Le management par processus pour des organisations orientes clients, La crativit et le dveloppement du personnel o chacun peut laisser libre cours son imagination
83
Cette dynamique de recherche d'amlioration est continue. Les retours d'information des clients, les audits et la revue du systme de management de la qualit sont galement utiliss pour identifier des opportunits d'amlioration. L'amlioration continue doit tre un objectif permanent de l'entreprise. Le principe de l'amlioration continue est souvent reprsent par un cycle d'actions, appel "roue de Deming" ou cycle PDCA : Plan (Planifier, prvoir), Do (faire), Check (Vrifier), Act (Agir).
Figure 4-2: Roue de DEMING Principe 7: Approche factuelle pour la prise de dcision
Dcider c'est prendre un risque. Pour pouvoir prendre les bonnes dcisions, il faut pouvoir s'appuyer sur des informations fiables. Ces informations doivent donc tre disponibles et sous une forme permettant leur analyse et leur comprhension. Dans de nombreux cas, la mise en place d'indicateurs et tableaux de bord pertinents permet de rpondre ce besoin et facilite la prise de dcision. Principe 8: Relations mutuellement bnfiques avec les fournisseurs Une entreprise et ses fournisseurs sont interdpendants et des relations mutuellement bnfiques permettront d'augmenter leurs capacits crer de la valeur. Pour cela, il est ncessaire de comprendre les intrts des partenaires, de dfinir clairement leurs obligations et d'valuer rgulirement leurs performances. 84
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
4. Dmarches qualit
Dans cette section, on essaie de dcrire certaines dmarches qualit relatives aux systmes d'information, notamment celles qui s'intressent au processus de dveloppement logiciel. A cet effet, nous prsentons les normes de standardisation ISO 9000, les modles CMMi et SPiCE et la bibliothque ITIL.
L'ISO a labor plus de 18 000 Normes internationales sur des sujets trs varis et quelque 1100 nouvelles normes ISO sont publies chaque anne [ORG-ISO 2010]. Les normes [ISO 9000] sont une srie de normes internationales sur les systmes de management de la qualit. La famille ISO 9000 implique 4 normes principales: ISO 9000:2005 ISO 9001:2008 ISO 9004:2009 l'environnement. Les Normes sont des outils au service de la dmarche qualit qui est applique un domaine d'activit. Les huit principes de management de la qualit cit ci-dessus sont la fondation des normes [ISO 9000]. Principes essentiels et vocabulaire; Exigences des systmes de management de la qualit; Lignes directrices pour l'amlioration de la performance;
4.1.1.
L'ISO 9000:2005 dcrit les principes essentiels des systmes de management de la qualit, objet de la famille des normes ISO 9000, et en dfinit les termes associs. 85
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
L'ISO 9001:2008 est une norme internationale sur le systme de management de la qualit. Elle a d'abord t publie par l'Organisation internationale de normalisation (ISO) en 1987 puis rviss en 1994 et 2000. En 2008 une autre version a vu le jour pour prendre en compte des nouvelles exigences [LATTIF 2010]. La norme [ISO 9001:2008] fournit le cadre et les exigences daudit pour le systme de management de la qualit. Avec une approche systmique des processus, la norme donne une libert aux organisations pour dvelopper, grer et amliorer leurs propres objectifs, processus et procdures pour dmontrer l'implantation efficace de systme de management de la qualit, obtenir la certification et l'atteinte les rsultats cibls. L'universalit et la versatilit de la norme ISO 9001 :2008 sont bien fondes sur lapproche processus et sur une structure de 5 lments: Systme de management de la qualit Responsabilit de la direction Management des ressources Ralisation du produit Mesure, analyse et amlioration Le systme [ISO 9001:2008] est fond sur cette structure de cinq lments avec 23 exigences. Les intrants sont les exigences des clients, les exigences du produit et les objectifs qualit. Les rsultats cibls sont la satisfaction des clients et la qualit des produits et services livrs. La nouvelle norme ISO 9001:2008 a apport des changements dans les 23 exigences existantes afin damliorer la comprhension, lutilisation et lapplication de la norme dans un nouvel environnement daffaires des organisations. Les changements majeurs dISO 9001:2008 sont : Focus sur les rsultats livrs Matrise des processus sous-traits Systme dinformation Comptence Satisfaction des clients: mthodes et sources Activits aprs-livraison valuation des actions prises
86
L'ISO 9004:2009 fournit les recommandations pour que le systme qualit soit efficace et s'appuie sur la satisfaction des utilisateurs pour procurer des avantages aux parties intresses (personnels, fournisseurs, actionnaires). Elle prsente des conseils et des recommandations. Elle n'est pas destine tre utilise dans un cadre rglementaire, contractuel ou de certification, mais pour pratiquer l'autovaluation des fonctions internes.
4.1.4.
La norme indique les raisons d'avoir une documentation et insiste sur le fait que celle-ci doit ajouter de la valeur. La documentation, partie la plus visible, peut tre utile pour: Obtenir la conformit aux exigences client, Amliorer la qualit, Assurer la rptabilit des processus, Assurer la formation; Fournir des preuves, Evaluer l'efficacit du systme.
Les normes au travers du systme de management de la qualit fournissent des modles types de documentation: Manuel qualit, Plan qualit, Spcification, Procdures, Enregistrements et Lignes directrices. Les documents doivent contenir les informations suivantes : Auteur ; Approbateur ; Distribution ; Version ; Date ; Dure de vie ; Classement / archivage ; Identification des modifications.
Les versions primes doivent tre retires de la classification et chacune des pages doit pouvoir tre relie au document-source travers un codage.
87
La certification est la procdure par laquelle une tierce partie donne une assurance crite quun produit, un processus ou un service est conforme des exigences spcifies. Les motivations de la certification de systme qualit peuvent tre classes en six catgories parfois contradictoires : Protectionnisme Argument commercial Outil interne de gestion Exigence clientle ou rglementaire Dveloppement du commerce Source d'conomie Plusieurs types de certification coexistent : - La certification de personne qui atteste de la comptence dune personne pour accomplir des tches dtermines ; - La certification de service qui certifie quun service possde certaines caractristiques ayant fait lobjet dun contrle ; - La certification de produit qui se traduit par lapposition dune marque ; - La certification dentreprise qui vise attester de la conformit des systmes dassurance qualit des entreprises aux normes internationales de la srie ISO 9000. La certification requiert obligatoirement un organisme tiers et indpendant, diffrent du fournisseur et du client. Il a pour vocation dattester de la conformit des systmes dassurance qualit des entreprises aux exigences des normes ISO 9000. Contrairement aux organismes de normalisation, les organismes certificateurs ne sont pas lorigine de la constitution des normes, ils fournissent uniquement le certificat de conformit. LISO elle-mme neffectue pas dvaluation pour vrifier si ses normes sont appliques avec conformit. L'audit de certification se fait uniquement par un organisme accrdit: AFAQ (www.afaq.fr) AFNOR (www.afnor.fr) AFAQ-ASCERT INTERNATIONAL (www.afaq.fr/web/pays/homeaai.nsf/vol/acc000) LLOYDS REGISTER QUALITY ASSURANCE (www.lrqa.com) SNIMA (www.mcinet.gov.ma/snima)
88
CHAPITRE IV: DEMARCHE QUALITE DANS LES SYSTEMES D'IINFORMATION 4.2. La dmarche CMMi
La dmarche CMMi propose de matriser le processus de dveloppement des applications et l'ensemble des dmarches du gnie logiciel. Le modle CMMi (Capability Maturity Models Integrated) ou modle d'volution des capacits logicielles a t conu par le SEI (Software Engineering Institue) pour valuer le processus de dveloppement logiciel dmarche CMMi permet de: Optimiser le processus de dveloppement logiciel applicatifs; Mettre en place une politique d'assurance qualit et de certification; Evaluer le niveau de maturit global sur une chelle de 1 5; Grer les exigences des niveaux de maturit.
[SEI 2010].
Ainsi la
4.2.1.
Historique CMMi
En 1980, le DoD (Department of Defense) amricain a demand l'laboration d'un rfrentiel de critres lui permettant d'valuer ses fournisseurs de logiciel. Le SEI a t cr cette fin en 1984 et luniversit Carnegie Mellon a t choisie pour lhberger. Le SEI a publi en 1988 la mthode SCE (Software Capability Evaluation), en 1990 la mthode SPA (Software Process Assessment), en 1991 la version 1.0 du SW-CMM (CMM for SoftWare). Ce premier modle a permis de crer de nouveaux modles comme : SE-CMM (pour System Engineering); SA-CMM (pour Software Acquisition) ; IPD-CMM (pour Integrated Product Development).
Aprs 10 ans de maturation et de recherche (cf. Figure 4-3), SEI propose en 2001 une nouvelle version de son modle, le CMMi qui englobe les bonnes pratiques des autres modles. En 2006, le SEI publie CMMi pour le dveloppement, Version 1.2. La nouvelle version couvre un domaine plus vaste que ce dernier. Au dveloppement logiciel s'adjoignent d'autres secteurs notamment l'ingnierie systmes et l'acquisition de logiciels.
89
4.2.2.
CMMi propose deux modles de reprsentation [SEI 2008_1]: Le modle continu : Il permet lorganisation de choisir un domaine de processus et damliorer les processus qui lui sont lis. Cette reprsentation utilise des niveaux daptitude pour caractriser une amlioration relative un domaine de processus. Le modle tag : Il utilise des ensembles de domaines de processus prdfinis pour dterminer la voie damlioration dorganisation. Cette voie est caractrise par des niveaux de maturit. Chaque niveau de maturit fournit un ensemble de domaines de processus qui caractrisent diffrents comportements organisationnels. A noter que les deux reprsentations ne sont que 2 mthodes pour reprsenter les rsultats et restent compatibles. En modle tag, CMMi permet d'valuer la maturit de l'entreprise sur cinq niveaux partir de l'observation de ses pratiques, de ses processus et de son organisation. Un niveau de maturit est un palier d'volution dfini dans la pratique du processus de dveloppement mature. Une entreprise se classe sur l'un des niveaux suivants: Niveau 1: Initial ou immature. Il s'agit du niveau le plus bas qui correspond gnralement un dsordre relatif.
90
4.2.3.
CMMi propose des domaines de processus ou Process Area (PA) spcifiques des thmatiques. Chaque thmatique est dcompose en domaines de processus [IT-CMMI 2010] :
Niveaux Support Gestion des configurations (CM) Assurance Qualit des produits et processus (PPQA) Mesure et analyse (MA) Analyse et prise de dcision (DAR) Gestion de projet Planification de projet (PP) Surveillance et contrle du projet (PMC) Gestion des contrats fournisseur (SAM) Gestion de projet intgre + IPPD (IPM) Gestion des risques (RSKM) Ingnierie Gestion des exigences (REQM) Gestion des processus -
Niveau 1 Niveau 2
Niveau 3
Dveloppement des exigences (RD) Solutions techniques (TS) Intgration de produit (PI) Vrification (VER) Validation (VAL)
Niveau 4 Niveau 5
Focalisation du processus Organisationnel (OPF) Dfinition du processus Organisationnel + IPPD (OPD) Formation de l'organisation (OT) Performance du processus organisationnel (OPP) Innovation et dploiement Organisationnel (OID)
91
4.2.4.
l'entreprise:
Il n'existe pas de certification CMMi, mais un niveau de maturit laquelle on peut valuer Le niveau 1 est le niveau de dpart. Les organisations bien rodes se satisferont des niveaux 2 et 3. ce dernier atteste que les processus valus sont suffisamment optimiss et scuriss; Les niveaux 4 et 5 sont la caractristique des structures trs ractives, capables de surveiller et d'amliorer en permanence leur activit. Le SEI a cr une mthode facultative pour valuer le niveau de maturit: SCAMPI (Standard CMMI Appraisal Method for Process Improvement). Il existe des certifications dcernes par le SEI, mais il s'agit de certifier l'aptitude des tiers former aux mthodes CMMi et SCAMPI, ainsi qu' fournir des services d'valuation.
92
CHAPITRE IV: DEMARCHE QUALITE DANS LES SYSTEMES D'IINFORMATION 4.3. la dmarche SPiCE / ISO 15504
Le projet SPiCE (Software Process Improvement and Capability dEtermination) est un projet international dvelopp pour dfinir des recommandations en matire de dveloppement d'application
[SQI-SPICE 2010].
avec l'universit Griffith de Brisbane en Australie. Les objectifs de la dmarche SPiCE sont: Optimiser le processus de dveloppement des logiciels; Garantir la prdictibilit des livrables et des dlais; Assurer la rversibilit lors des dveloppements; Dterminer le niveau de maturit et d'amlioration des pratiques du dveloppement.
4.3.1.
En janvier 1993, un programme de travail fut approuv par le comit ISO/CEI JTC1, il devait aboutir aux spcifications dun standard en matire de pratique de dveloppement dapplications: SPiCE. Un rapport technique est prsent lISO sous le titre gnrique de Software Process Assessment en 1995. Depuis SPiCE est devenu un mta norme sous la rfrence ISO 15504.
4.3.2.
Niveau 0 - Incomplet: Le processus n'est pas ralis, ou bien il n'atteint son objectif que partiellement ou bien le rsultat nest pas facilement identifiable. Rptabilit des processus.
93
4.3.3.
La dmarche SPiCE se matrialise par deux principes: les processus et le classement en catgorie. Chaque processus du dveloppement est identifi par une catgorie, on lui attribut pour chacun des neuf attributs de capacit un niveau de capacit sur une chelle de quatre niveaux (non ralis, partiellement ralis, largement ralis et pleinement ralis). Les neufs attributs sont: 1. Ralisation des processus 3. Produits du travail 5. Ressources de processus 7. Matrise processus 9. Amlioration continue SPiCE Dtermine cinq principales catgories qui prsentent les proccupations majeures du dveloppement logiciel, chaque catgorie est compose d'un nombre de processus qui contient un nombre de pratiques (cf. Tableau 4-2): 2. Gestion des ralisations 4. Dfinition de processus 6. Mesure du processus 8. Changement du processus
94
Observation
Soutient le dveloppement et le transfert du fournisseur vers le client et assure une exploitation et une utilisation correcte: prparation de l'acquisition, slection des fournisseurs, suivi des fournisseurs, acceptation clients. Processus qui spcifient, ralisent, mettent en uvre et maintiennent un logiciel et sa documentation utilisateur: conception & analyse, dveloppement, intgration & test, maintenance systme et logiciel. Processus composs de pratiques gnriques qui peuvent tre employes par le chef de projet l'intrieur du cycle de vie: management projet, management qualit, management des risques. Processus qui peuvent tre utiliss par tout autre processus des stades divers du cycle de vie:documentation, gestion de la configuration, vrification, audit, rsolution problme. Processus qui tablissent les buts stratgiques de l'organisation, grent et identifient les produits et les ressources qui serviront les atteindre: tablissement du processus, valuation et amlioration du processus, gestion des ressources humaines, infrastructures, mesurage.
ENG
32
PRO
Projet
30
SUP
Support
32
ORG
Organisation
48
Tableau 4-2: Les cinq catgories d'activits SPiCE [Tir de CARLIER 2006] La liste des Pratiques par catgories de proccupations SPiCE est annexe en annexe II.
Service Support Service Delivery Infrastructure Management Applications Management Service Management Business Perspective Business Requirements Technology Les deux premiers Service Support et Service Delivery sont considrs comme le coeur de
la mthode ITIL [JEFF 2008]. Le tableau 4-3 dtaille les processus de ces derniers:
Processus Gestion des configurations Objectif Grer l'infrastructure technologique en faisant un tat des lieux de l'existant afin de mieux le grer et le faire voluer. Mieux dtecter les incidents, amliorer le dlai de rsolution des incidents selon leur criticit sur le fonctionnement de l'entreprise. Mieux grer les problmes rcurrents et mettre en oeuvre des solutions de prvention afin de rduire leur occurence, voire les supprimer. Mettre en oeuvre des dmarches de conduite du changement afin d'anticiper les effets de bord. S'assurer de l'adquation du service avec les besoins mtiers. Assurer un niveau de disponibilit suffisant un cot raisonnable. Maintenir un certain niveau de qualit de service grce des contrats de service rengocis priodiquement. Vrifier l'adquation des capacits et performances avec les exigences actuelles et venir. Dfinir et mettre en oeuvre des dlais contractuels pour la reprise aprs incident. Grer la rentabilit des moyens mis en oeuvre pour fournir le service.
Gestion des incidents Gestion des problmes Gestion des changements Gestion des mises en oeuvre Gestion de la disponibilit Gestion des niveaux de service Gestion des capacits Gestion de la continuit des services IT Gestion financire des services IT
96
1 Work Breakdown Structure (WBS) (en anglais; en franais : Structure de dcoupage du projet SDP; le sigle anglais tant le plus souvent utilis) est une dcomposition hirarchique, axe sur les tches et activits, du travail que lquipe de projet doit excuter pour atteindre les objectifs du projet et produire les livrables voulus.
97
6.1.
Origine PMBOK
Le Project Management Institute (PMI) a t fond en 1969, au commencement pour identifier les procdures de gestion commune dans les projets travers les industries.
La premire dition du PMBOK a t publie en 1987. C'tait le rsultat des travaux lancs par le PMI au dbut des annes 80. En parallle un code d'thique a t dvelopp. Et des directives pour l'accrditation des centres de formation et la certification des personnes.
Plus tard, une deuxime version du PMBOK a t publie (1996 et 2000), base sur les commentaires reus des membres. Le PMBOK a t reconnu comme norme par l'American National Standards Institute (norme ANSI) en 1998, et plus tard par l'institut des ingnieurs en lectricit et lectronique (IEEE).
La troisime version du guide PMBOK a t publie en 2004, avec des amliorations majeures dans la structure du document, des complments concernant les processus, des termes et les domaines de programme et de portefeuille de projets.
6.2.
Un projet est ralis au travers de l'intgration des processus de management de projet. Le PMBOK utilise une variation du Cycle de Deming pour l'amlioration continue avec 5 tapes de cycle de vie (cf. Figure 4-5):
98
Prvision
Dmarrage
Grer l'quipe, les partenaires, les sous-traitants Performance de mesure de progrs et de contrler (ensemble, primtre, programme, cots, qualit) Dfinir et enclencher les actions correctives si ncessaire et o elles le sont. Rsolution de problme et escalade Grer les demandes de Changement Grer les Risques (technique, qualit, performance, management de projet, organisationnel, externe) Rdiger les rapports de performance. Mener les activits bonne fin Clture administrative du projet (rassembler, distribuer, archiver l'information pour formaliser l'aboutissement du projet, son acceptation/rception, valuation, valuations des membres, leons apprises) Clture des Contrats (finalisation du contrat du projet comprenant la leve des rserves en suspens et la rception dfinitive) Tableau 4-4: Les processus du Management du Projet dans PMBOK
99
Figure 4-5: Les cinq processus du Management du Projet dans PMBOK [Tir de PMBOK 2000]
6.3.
Le guide PMBOK est un rfrentiel de connaissances et une norme de fait. Il est orient-processus. Il tablit les connaissances requises pour grer le cycle de vie de n'importe quel Projet, Programme et Portefeuille de projets par leurs processus. Il dfinit pour chaque processus les produits en entre, les outils, techniques et les produits en sortie (livrable). Il dfinit un corps des connaissances sur lequel n'importe quelle industrie peut tablir de bonnes pratiques spcifiques son domaine d'application.
Limitations PMBOK:
Complexe pour de petits projets. Doit tre adapt l'industrie du domaine d'application, la taille et le contenu du projet, le dlai et le budget et les contraintes de qualit.
100
C'est l'organisation de dterminer ses priorits. Que l'on vise une simple
amlioration des processus en s'inspirant d'une norme ou que l'on doive obtenir une certification, les approches agiles ajoutent un ensemble de pratiques intressantes. Pour la mise en place d'une dmarche qualit ISO 9001, il est possible de rapprocher les objectifs avec les valeurs agiles. Mais, on craint toujours que les organisations dfinissent des processus lourds, qui limitent lintgration de lagilit. Pour le modle CMMi, chaque niveau de ce modle fait progresser les processus en place, pour tre capable de les optimiser. Plusieurs mthodes agiles allguent quivaloir au niveau standardis (niveau 3)
[COCKBURN 2004].
principes qui cherchent amliorer le rendement et la productivit. La communaut CMMi, dune faon gnrale, adhre lide que le CMMi et les mthodes agiles sont compatibles
[SEI 2008_2].
que prconisent XP, SCRUM et autres sont applicables dans un environnement CMMi. Quelle que soit son adaptation, un problme frquent lorsquun processus est dfini, est dimaginer quil est fig puisquil est rdig [COCKBURN 2004]. Les gens se contraignent suivre la procdure, sans songer ladapter. Parfois, ils prfrent croire que le processus est fig. La conciliation est possible, mais nous pouvons attribuer cette mconnaissance la perception plutt qu une contrainte relle.
101
CHAPITRE V : BENCHMARKING
Chapitre 5 BENCHMARKING
103
CHAPITRE V : BENCHMARKING
Le Benchmarking est un processus qui permet d'identifier ce qui se fait de mieux dans un secteur particulier, et de rencontrer les entreprises afin d'atteindre les rsultats issus des meilleures pratiques, dans ce secteur
[KNOWLLENCE 2010].
Le Benchmarking de dveloppement
logiciel consiste la mise en place dun systme de mesure de lactivit de dveloppement. Il permet damliorer le pilotage de cette activit du point de vue du dlai de livraison, du cot des projets de dveloppement et de la qualit des applications. Un bon Benchmarking doit tre ralis selon une dmarche en cinq tapes : 1- Identifier l'objet du Benchmarking : Il faut dfinir le processus amliorer ainsi que les limites du Benchmarking. 2- Dfinir des mesures de Benchmarking : Cette tape consiste la mise en uvre des indicateurs pertinents pour mesurer les bons lments en rapport avec les objectifs fixs. 3- Identifier le Benchmark : Le benchmark est la rfrence pour ce qui concerne la mesure. Il faut cerner le primtre de l'entit qu'on veut comparer. 4- Collecter les donnes de la cible du Benchmarking : Cette tape consiste rassembler les donnes sur le site du Benchmark afin de mesurer ses indicateurs. Plusieurs outils apportent une aide importante cette tape, tels que llaboration dun questionnaire et lorganisation dentretiens avec les personnes relevant de lentit choisie comme base de Benchmarking. 5- Analyser et comparer les donnes et dterminer l'cart : L'objectif de cette tape est la comparaison des donnes collectes et l'analyse des rsultats de synthse, il va falloir les transcrire sous forme de graphiques. Dans le cadre de notre tude, le Benchmarking de dveloppement logiciel propos ajoutera ce travail un recensement des diffrentes pratiques mises en uvre par les chefs de projet dans leurs processus de dveloppement logiciel, il nous permettra par la suite de comparer leurs pratiques de dveloppement logiciel celles adoptes la DB. Ce chapitre retrace les diffrentes tapes du Benchmarking de dveloppement logiciel ralises au cours de cette tude, nous examinons par la suite certaines expriences russies en matire d'intgration de nouvelles mthodologies de dveloppement logiciel dans les mthodes de travail de la DSI.
104
CHAPITRE V : BENCHMARKING
1. Objectif du Benchmarking
Conformment l'objectif de cette tude, le primtre de ce Benchmarking se limite aux pratiques de dveloppement logiciel aussi bien qu' la gestion du projet de dveloppement qu' son excution. Il ne s'tend pas aux activits de formation ni de maintenance ni celles du centre de production.
Le
benchmarking ne mesure pas la productivit du dveloppeur mais la productivit du dveloppement, ceci est trs fortement li aux modles de processus de dveloppement pratiqus et aux procds et techniques utiliss pour la production du logiciel. A cet effet, les mesures du Benchmarking sont proposes selon quatre axes : - L'axe "Dmarrage" regroupe lensemble des activits permettant dentamer la fabrication du systme dinformation et le management du projet. Ces activits sont directement lies limage que le chef de projet se fait de la future utilisation du systme dinformation - L'axe "Management" de projet vise assurer la matrise des objectifs : la qualit, le dlai et le cot. Il englobe les activits dorganisation, de dcision, de coordination des diffrents acteurs et de pilotage du projet. - L'axe "Processus de dveloppement" regroupe les activits de conception et de cration du futur SI. La fabrication ncessite la matrise de techniques informatiques, de mthodes ou modles danalyse et de conception et dune dmarche complte de dveloppement. - L'axe "Utilisation" part de la mise en exploitation du SI et dborde en aval du cadre du projet : cest la vie en exploitation du SI. Lutilisation est laboutissement du projet.
3. Identification du Benchmark
Dans le cadre de notre tude, ce Benchmarking sintresse aux structures charges du dveloppement logiciel dans les organismes marocains. Il a cibl les administrations publiques (dpartements ministriels et tablissements publics) et le secteur priv tel que les banques et les socits dingnierie informatique.
105
CHAPITRE V : BENCHMARKING
Pour mener bien cette enqute, nous avons propos la cible du benchmarking un questionnaire simple qui permet deffectuer des comparaisons entre projets (cf. annexe III). Ce questionnaire dcline les mesures du Benchmarking de dveloppement logiciel en huit sections : Identification de l'environnement de l'organisme; Identification des projets informatiques initis au sein de cet organisme; Inspection des activits de la prparation des projets informatiques; Interrogation sur les activits dorganisation, de dcision, de coordination des diffrents acteurs et de pilotage du projet. Collection des donnes sur les procdures de la production du logiciel; Mesure de la qualit de la documentation labore au cours du projet de dveloppement logiciel; Mesure de l'effort dploy pour l'utilisation du logiciel produit afin de satisfaire l'utilisateur final; Et la dernire section recueille l'avis global du rpondant sur le projet.
4.2.
Aprs la rdaction du questionnaire, nous avons procd un test interne la Direction du Budget afin de nous permettre de mesurer la clart des questions et des rponses proposes. L'administration du questionnaire au site du Benchmark a t alatoire, elle a t base sur l'envoi du questionnaire par email aux groupes des ingnieurs et informaticiens via des mailings listes. En parallle le questionnaire a t mis en ligne sur le site web [QUEST 2010]. Aprs un premier essai infructueux, il a fallu renoncer l'envoi du questionnaire aux groupes des mailings listes, pour plusieurs raisons dont la principale est la mfiance des rpondants de la publication de leur avis sur une enqute non officielle par leur organisme. Lchantillon est donc li mon rseau de relation et celui de mes collgues, d'autres envois ont t destins aux responsables des DSI des diffrentes directions du Ministre de l'Economie et des Finances. J'ai pu, par la suite, m'entretenir avec quelques responsables informatiques des dpartements ministriels ou des Socits de Services Informatiques lors d'un rendez vous ou l'occasion du sminaire Agile Maroc Organis le 24/11/2010 l'Ecole Mohammedia des Ingnieurs Rabat. 106
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
CHAPITRE V : BENCHMARKING
5. Synthse du Benchmarking
5.1. Environnement de l'enqute
Pendant deux mois denqute, on a pu recueillir 48 rponses. 57% des rponses ont t remis par mail, 5% des rpondants ont choisi de rpondre au questionnaire manuellement et uniquement 3% ont rpondu au questionnaire en ligne. 35% des rponses ont t recueilli suite aux entretiens directs (cf. figure 5-1).
Figure 5-1 : Mode de rponse au questionnaire Les rpondants ont rpondu la majorit des sections du questionnaire hauteur de 98,18% de la totalit des questions.
5.2.
Environnement de l'organisme
59% des rponses recueillies concernent les administrations, 25% reprsentent les socits dingnierie informatique et des tlcoms et 4% du secteur bancaire (cf. figure 5-2). Pour les besoins de notre tude, nous rpartissons le secteur dactivit des organismes participants cette enqute en secteur priv et secteur public, ce dernier est rparti en directions du Ministre de lEconomie et des Finances (MEF) et autres organismes publics. Ainsi 27% des rponses reprsentent les directions du MEF, 40% concernent le secteur public et 33% du secteur priv (cf. figure 5-2).
107
CHAPITRE V : BENCHMARKING
Figure 5-2 : Rpartition des organismes par secteur d'activit Le tableau suivant liste les diffrents dpartements participants cette enqute :
Organisme
AgileaSoft S.A.R.L. Atos Origin Cercle RH CNESTEN Ministre de l'Education Nationale - Dpartement de l'enseignement scolaire DSI Conseil Ecole Mohamedia des Ingnieurs Dpartement de l'Enseignement Suprieur Fondation Med 6 Education IAM MEF / DAAG MEF / DAPS MEF / DEPF MEF / DB MEF / DOMAINES MEF / DOUANE MEF / TGR MEF/ DEPP Ministre de l'agriculture Ministre de l'industrie et du commerce Ministre de l'intrieur Dpartement des Nouvelles Technologies NUN Computing OFPPT/ISTA ONE SAZ CDG Sofrecom Wana corporate Secteur Priv Priv Priv Public Public Priv Public Public Public Priv MEF MEF MEF MEF MEF MEF MEF MEF Public Public Public Public Priv Public Public Public Priv Priv
CHAPITRE V : BENCHMARKING
Les autres dpartements ont prfr de garder l'anonymat de leur rponse. Le graphique ci-dessous dmontre que 50% des rpondants sont des chefs de projet informatique, 35% sont des dveloppeurs et 8% exercent le mtier de lanalyste concepteur. 17% des rpondants exercent autres mtiers qui varient entre formateur, ingnieur support ou responsable rseau (cf. figure 5-3).
La majorit des structures informatiques (DSI) qui ont particip cette enqute sont des structures de grande taille, 53% des rponses affirment que leffectif de leur DSI est suprieur 20 personnes (cf. figure 5-4).
21%
Moins de 5 personnes De 5 personnes 10
53% 13%
13%
CHAPITRE V : BENCHMARKING
Les DSI contactes lors de cette enqute offrent des systmes dinformation au profit de nombreux utilisateurs. 36% des rponses affirment que le nombre des utilisateurs de leur systme dinformation dpasse mille personnes et 38% des rponses indiquent que ce nombre est entre cent et mille personnes (cf. figure 5-5).
9%
36%
17%
Moins de 10 personnes De 10 personnes 100 De 100 personnes 1000 Plus que 1000 personnes
38%
5.3.
Projet informatique
Le graphique ci-dessous fait ressortir que 84% des organismes participants cette enqute produisent des logiciels, ceci saligne avec les objectifs de notre tude. Nanmoins, nous constatons que les organismes marocains commencent sintresser aux projets dcisionnels (48% des rponses) (cf. figure 5-6).
Figure 5-6 : Projet informatique initi au sein des organismes enquts 110
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
CHAPITRE V : BENCHMARKING
Le graphique ci-dessous dmontre que les projets informatiques de 66% des organismes enquts sont initis par la direction. Les responsables mtier et les DSI initient les projets informatiques de 51% des organismes rpondants. Certaines rponses (6%) indiquent que le service commercial est linitiateur des projets informatiques, cest le cas des organismes du secteur priv (cf. figure 5-7).
Figure 5-7 : Initiateurs des projets informatiques dans les organismes enquts Pour 70% des organismes enquts, la DSI est responsable de la conduite de ses projets informatiques. 44% des organismes engagent les responsables mtier au pilotage de leurs projets informatiques, contre seulement 19% des organismes dont les projets informatiques sont pilots par leurs managers (cf. figure 5-8).
Figure 5-8 : Pilotes des projets informatiques dans les organismes enquts Sagissant des tailles des projets informatiques initis au sein des organismes enquts, 56% des rponses indiquent que la taille de leurs projets est moyenne, 31% affirment que la taille de leurs projets est grosse et 13% sont petite (cf. figure 5-9). 111
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
CHAPITRE V : BENCHMARKING
Figure 5-9 : La taille des projets informatiques Dans la suite de cette synthse, nous comparons toutes les rponses entre trois secteurs : le MEF qui regroupe les directions du Ministre de lEconomie et des Finances, le secteur public qui regroupe tous les organismes publics hors ceux des directions du MEF et le secteur priv.
5.4.
Les interrogations de cette section du questionnaire nous clairent sur les activits de management au dbut des projets informatiques. Avant le dmarrage du projet informatique, 44% des projets ont des objectifs clairement dfinis. Tous les projets informatiques des directions du MEF ont des objectifs dfinis, mais plus de 60% de ces projets manquent de prcision. Uniquement 4% des projets informatiques initis au secteur Public et Priv ont des objectifs mal dfinis (cf. figure 5-10).
112
CHAPITRE V : BENCHMARKING
Lexpression des besoins fonctionnels est moins formalise au secteur public et priv par rapport aux directions du MEF. En effet, plus 23% des projets du MEF ont une bonne expression des besoins, 69% des projets des directions du MEF ont des besoins qui sont formaliss mais changent frquemment. Le secteur Priv trouve une difficult formaliser les besoins fonctionnels dans 29% des cas, contre 21% du secteur Public et 8% des directions du MEF (cf. figure 5-11). Ceci sexplique par la matrise des dveloppeurs des directions du MEF et du secteur Public du mtier de leurs organismes, par contre le secteur Priv ; qui est constitu dans cette enqute en majorit par des SII ; narrive pas obtenir facilement un document bien formalis de lexpression des besoins fonctionnels.
Figure 5-11 : Degr de prcision de l'expression des besoins fonctionnels Le digramme ci-dessous fait ressortir que 50% des projets informatiques du secteur Priv ont un dlai de livraison fixe, contre 38% des projets qui ont un dlai de livraison estimatif et 12% des projets qui nont aucun engagement du dlai. Par contre, au secteur Public tout comme aux directions du MEF, plus que 75% des projets ont des dlais de ralisation
estimatifs, et moins de 25% des projets ont des dlais fixes imposs par la hirarchie (cf. figure 5-12).
CHAPITRE V : BENCHMARKING
Prs de 84% des projets informatiques initis au MEF, ont eu une planification sommaire, 8% des projets ont eu une planification dtaille et 8% des projets ont t raliss sans aucune planification pralable. 74% des projets informatiques du secteur Public ont eu une planification sommaire, 21% ont eu une planification dtaille et 5% nont aucune planification pralable. 44% des projets informatiques du secteur Priv ont eu une planification sommaire, 37% ont eu une planification dtaille et 19% nont aucune planification pralable. (cf. figure 5-13). On remarque que la planification sommaire est la plus pratique dans la majorit des projets informatiques, par contre la planification dtaille est plus utilise au secteur priv.
5.5.
Parmi les rponses recueillies lors de cette enqute, 55% du secteur Public, 54% des directions du MEF et 44% du secteur Priv affirment que les chefs de projet utilisent les outils dont disposent leurs organismes. L'utilisation des outils imposs par la hirarchie ou le client vient en second rang par 43% du secteur Priv, 38% des directions du MEF et 26% du secteur Public. Les chefs de projet disposent rarement d'une dmarche structure pour choisir leurs outils de dveloppement (21% au secteur Public, 13% au secteur Priv et 8% aux directions du MEF) (cf. figure 5-14).
114
CHAPITRE V : BENCHMARKING
Figure 5-14 : Le choix technique des outils de dveloppement 54% des directions du MEF, disposent des quipes informatiques composes par des personnes travaillant dans le ministre, 38% deux ont une quipe impose par la hirarchie. 42% des organismes du secteur Public choisissent leurs quipes informatiques parmi les personnes de leurs organismes et 52% deux ont une quipe impose par la hirarchie. 65% des structures du secteur Priv choisissent leurs quipes parmi les personnes internes l'organisme, et 30% d'eux composent leurs quipes de travail selon des dmarches structures (cf. figure 5-15).
Figure 5-15 : Le choix de l'quipe de travail La figure 5-16 montre que 59% des chefs de projet (dans les trois secteurs) travaillent selon une organisation existante dans leurs organismes et 26% s'organisent selon des dmarches structures. L'organisation du projet impose par la hirarchie ou le client est classe en troisime rang avec 6% au secteur Priv, 15% aux directions du MEF et 21% au secteur Public.
115
CHAPITRE V : BENCHMARKING
Figure 5-16 : Le choix de l'organisation du travail Pour la question portant sur l'utilisation d'une mthodologie de gestion de projet, 69% des rponses du secteur Priv indiquent le recours des mthodologies traditionnelles et 31% utilisent des mthodologies standards. Quant aux directions du MEF, 38% des rpondants ont affirm l'utilisation d'une mthodologie traditionnelle, 38% des rponses tmoignent labsence d'une mthodologie de gestion de projet et seulement 24% utilisent des mthodologies standards. Le secteur Public utilise moins que les autres les mthodologies standards (10%), 68% du secteur Public utilise des mthodologies traditionnelles et 22% nont aucune mthodologie de gestion de projet (cf. figure 5-17).
5.6.
Processus de dveloppement
5.6.1. Le dveloppement
Pour la question portant sur les types de production d'application informatique, 83% des rponses ont affirm que leurs organismes font du dveloppement interne, 50% externalisent
116
CHAPITRE V : BENCHMARKING
leurs dveloppements logiciels, 60% intgrent des progiciels et 41% exercent la maintenance des systmes d'information. (cf. figure 5-18).
Figure 5-18 : Type de production d'application informatique La majorit des DSI participantes cette enqute a confirm l'utilisation de la technologie J2EE (70%), contre 41% des DSI utilisent la technologie Dot Net, 50% utilisent des logiciels libres et 25% utilisent autres technologies telles que Oracle et PHP . (cf. figure 5-19).
Figure 5-19 : Les technologies informatiques utilises Pour les relations avec le matre d'ouvrage, 71% des rponses du secteur Priv affirment avoir une relation avec un interlocuteur unique, 29% deux ont une relation assez formalise avec plusieurs utilisateurs qui sont souvent occups. 56% des rponses des directions du MEF affirment que leurs relations avec le matre d'ouvrage sont formalises avec un seul interlocuteur, 46% deux affirment avoir une relation assez formalise avec plusieurs utilisateurs. Quant au secteur Public, 37% des rponses expriment la formalisation des relations avec un utilisateur unique, 63% deux affirment que leurs relations avec les utilisateurs sont assez formelles (cf. figure 5-20).
117
CHAPITRE V : BENCHMARKING
Figure 5-20 : Relations avec la matrise d'ouvrage Parmi les DSI qui ont rpondu ce questionnaire, 42% des directions du MEF et 53% du secteur Public n'ont aucun contrle qualit dans leurs projets informatiques. 69% du secteur Priv, 50% des directions du MEF et 37% du secteur Public utilisent quelques contrles qualit dans leur processus de dveloppement logiciel. Le secteur priv reste le plus rigoureux dans l'laboration d'un plan qualit; 31% du secteur Priv contre 10% et 8% respectivement du secteur Public et des directions du MEF (cf. figure 5-21).
Figure 5-21 : Le contrle qualit La dmarche qualit CMMi est utilise par 33% des structures du secteur Priv et 13% des structures du secteur Public. La dmarche ITIL V3 est pratique par 17% du secteur Priv et 13% du secteur Public. L'ISO est adopte par 28% des organismes du secteur Priv et 17% des structures du secteur Public. 58% des directions du MEF adoptent une autre dmarche qualit qu'ils ont tiquete "dmarche maison"(cf. figure 5-22).
118
CHAPITRE V : BENCHMARKING
Figure 5-22 : Les dmarches qualit Pour la question portant sur la gestion des changements des besoins au cours du dveloppement, les directions du MEF ont rpondu que les demandes du changement sont toutes acceptes, 56% de ces directions trouvent des difficults bien grer ces demandes de changement. Par contre, 10% des rponses du secteur Public confirment le rejet des demandes du changement et 37% grent bien les demandes du changement des besoins fonctionnels. Quant au secteur Priv, la contractualisation avec le client augmente le taux du rejet des demandes du changement 31%, 56% des structures du secteur Priv expriment l'acceptation et la bonne gestion des demandes du changement (cf. figure 5-23).
Figure 5-23 : Gestion des changements des besoins fonctionnels Pour la question portant sur le mode de livraison des logiciels produits, 71% des rpondants des directions du MEF ont tmoign que les livraisons sont priodiques, contre 66% des rpondants du secteur Priv et 53% du secteur Public. (cf. figure 5-24).
119
CHAPITRE V : BENCHMARKING
La figure 5-25 dmontre que les directions du MEF utilisent principalement le modle itratif, le modle par prototypage et le modle en cascade, l'adoption de la mthode agile SCRUM a t instaure dans certaines directions du MEF. Le secteur public utilise le modle par prototypage et le modle en V. Par contre le secteur Priv utilise le modle itratif et les mthodes agiles SCRUM et XP.
Figure 5-25 : Les mthodes de dveloppement La figure 5-26 dmontre que 42% des directions du MEF ont choisi la mthode merise pour analyser et concevoir leurs systmes dinformation, contre 41% des organismes du secteur Public et 25% des structures du secteur Priv.
120
CHAPITRE V : BENCHMARKING
63% des organismes du secteur priv adoptent la modlisation UML, contre 54% des rponses du secteur Public et 52% des directions du MEF.
Figure 5-26 : Les mthodes d'analyse Le digramme ci-dessous fait ressortir que le secteur Priv est le plus organis dans la phase des tests par rapport au secteur Public et aux directions du MEF. Il est noter quil y a une nette volution de la structuration des tests dans les directions du MEF par rapport au secteur Public (cf. figure5-27).
5.6.2. La documentation
Dans le cadre des projets informatiques, la figure 5-28 montre que les directions du MEF et les organismes du secteur public laborent essentiellement le cahier des charges, le manuel dutilisation informatique et le document de conception. Le secteur Priv adjoint ces documents le cahier de maintenance, le plan de management et le plan de qualit.
121
CHAPITRE V : BENCHMARKING
Figure 5-28 : Documents labors dans le cadre des projets informatiques Les rponses des DSI participantes cette enqute affirment que les documents labors au profit des utilisateurs lors dun projet informatique sont dune qualit qui dpasse lgrement la moyenne, par contre les documents techniques sont estims dune bonne qualit dans le secteur Priv. Le secteur Public et les directions du MEF ont encore un effort fournir pour amliorer leurs documentations (cf. figure 5-29).
5.7.
Utilisation du produit
Les DSI rpondantes ce questionnaire ont indiqu que les efforts fournis lors du dploiement du systme dinformation produit sont considrables. Le secteur public se distingue
122
CHAPITRE V : BENCHMARKING
des directions du MEF et du secteur Priv par la difficult rencontres lors de la conduite des changements aprs le dploiement (cf. figure 5-30).
Figure 5-30 : Niveaux deffort fourni lors de lutilisation du produit logiciel Pour la question portant sur la satisfaction de la matrise d'ouvrage, 56% des rpondants du secteur Priv ont exprim la satisfaction de leurs clients, contre 32% des rpondants du secteur Public et 25% des directions du MEF. 68% des rpondants du secteur Public affirment que leurs matrises d'ouvrage sont assez satisfaites, mais dplorent le respect des dlais des livraisons, contre 66% des rpondants des directions du MEF et 44% du secteur Priv. Seulement 9% des DSI des directions du MEF ont tmoign linsatisfaction de leurs clients (cf. figure 5-31).
5.8.
Le graphique ci-dessous fait ressortir que les directions du MEF fournissent plus d'effort au dveloppement. La prparation du post-projet et le management du projet demandent moins d'effort que l'exploitation du logiciel. Les organismes du secteur Public fournissent plus d'effort la prparation post-projet par rapport aux directions du MEF. Quant au secteur Priv, la prparation post-projet et le dveloppement ont une charge de travail assez forte, la charge du travail du management du projet et de l'exploitation du logiciel, reste modre (cf. figure 5-32). 123
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
CHAPITRE V : BENCHMARKING
Figure 5-32 : Rpartition globale de leffort dans la production logiciel La figure 5-33 dmontre que les chefs du projet du secteur Public ont plus de matrise sur leurs projets informatiques. Le secteur Priv est le mieux class dans russir de ses projets et il est le premier couvrir le maximum des besoins fonctionnels exprims au dbut du projet. Notons que cette synthse ne rcapitule que les avis des rpondants cette question.
6. Tmoignages
Une tude de Forrester Research [Eweek 2010] montre que les entreprises adoptent de plus en plus les mthodes agiles de dveloppement. Prs de 45 % des entreprises sondes faisaient appel ces procdures censes tre plus pragmatiques que les mthodes traditionnelles en cascade. Selon ltude, SCRUM est lune des mthodes Agiles les plus populaires en raison de sa simplicit, son pragmatisme et sa popularit. Elle couvre la gestion des projets et elle est complmente par dautres mthodes, lXP tant aussi trs prise, car elle se concentre sur les 124
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
CHAPITRE V : BENCHMARKING
principes simples de dveloppement pousss lextrme. On prsente dans cette section quelques tmoignages des entreprises qui ont adopt une mthode agile.
Vidal
VIDAL est une filiale d'UBM Medica (Groupe United Business Media), il est le leader dans le domaine de linformation sur les produits de sant. Le dpartement informatique de VIDAL utilisait une approche classique en cascade avant de penser l'introduction de l'agilit. Mais un des premiers obstacles tait le choix de la mthode : SCRUM, XP ou FDD, SCRUM fut privilgi. Lexprience agile chez Vidal a dmarr avec la mise en uvre dun projet pilote. Ce qui a donn une satisfaction sur les dlais. Actuellement, Vidal continue de piloter lensemble de ses projets par lagilit [de Morlhon 2009].
Le Club Med
Club Mditerrane est une entreprise franaise de services qui commercialise des produits de voyage et de loisirs sous le nom de Club Med. Le Club Med hberge ses applications de rservation de voyage sur un mainframe IBM qui traite, pour tous les canaux de distribution, lensemble des demandes de disponibilit et de tarifs. Ces oprations qui sont effectues via le web augmentent de plus en plus. Pour rduire la charge mais aussi les cots dexploitation induits, la DSI a choisi de migrer cette application web sur des technologies moins onreuses : Java et MySQL sous Linux. Devant la ncessit de rcrire compltement ses programmes, avec un primtre fonctionnel identique et dans des dlais courts, la DSI a opt pour un modle agile qui avait dj t expriment sur un projet prcdent men avec Valtech1. Base sur SCRUM, la mthode applique par la SII se dcline sur lensemble des tches, depuis les estimations et spcifications de dveloppements jusqu la recette finale et le transfert de comptences. La particularit de ce projet, surtout lorsque les utilisateurs sont trs sollicits et impliqus, est que la DSI est ellemme lutilisateur final. Ces nouvelles faons de travailler sont un peu dstabilisantes pour les collaborateurs habitus travailler seuls. Mais, les runions journalires de l'quipe ont encadr ds le dbut du projet les participants. Toutefois, le projet avanant, les bnfices sont apparus et trs rapidement les quipes ont adhr la dmarche. Le gain de temps et defficacit et la meilleure visibilit sur les dveloppements sont des points trs motivants. Lagilit de Scrum et la comptence des quipes de Valtech sont rapidement venues bout des rsistances et ils ont pu rcrire en seulement quelques mois une application code et optimise en 10 ou 15 ans [MARTIN
2009].
125
7. Conclusion
Les mthodes agiles ont pu mettre leur empreinte positive sur le droulement des projets informatiques au niveau international. Au Maroc, notre enqute synthtise dans ce chapitre a dmontr que le taux de satisfaction de la matrise d'ouvrage est plus lev pour les DSI adoptantes une des mthodes agiles. Les mthodes agiles commencent investir le secteur Priv et principalement les SII. La TGR est le premier organisme du secteur public qui a intgr une mthode agile dans ses pratiques de dveloppement logiciel, cette dernire a pu introduire le modle de SCURM grce au transfert d'exprience de leur collaboration avec des socits d'ingnierie informatique. Les projets informatiques de la DB, tout comme ceux des autres directions du MEF, ont des objectifs qui sont bien clairs au dbut du projet, mais les besoins fonctionnels voluent souvent au cours du dveloppement du SI, les demandes de changement des besoins fonctionnels sont toujours acceptes, mais la gestion de ces demandes demeure insuffisante. Les dlais sont flexibles et la planification peut tre ajuste au cours du cycle de vie du projet ce qui engendre des retards dans les dlais de livraison. Les DSI du MEF disposent des quipes comptentes, ayant cumul une riche exprience sur l'utilisation de leurs outils de dveloppement et leurs mthodes de gestion de projet. Leurs relations avec la matrise d'ouvrage sont collaboratives. L'organisation du travail au sein de la DB favorise l'agilit, Il est recommand d'introduire les bonnes pratiques des mthodes agiles dans le rfrentiel de dveloppement logiciel de la DB.
126
127
rfrentiels des bonnes pratiques de dveloppement logiciel existants au sein dautres organismes a t effectue, celle-ci nous a permis de construire un plan type du nouveau rfrentiel proposer.
128
2. Justifications du choix
L'quipe de dveloppement logiciel de la DB est compose de huit ingnieurs, ces ressources exercent plusieurs fonctions de la spcification des besoins la formation des utilisateurs, ils participent plusieurs projets en parallle. Les quipes de dveloppement varient entre une et quatre personnes par projet de dveloppement. La Direction du Budget dispose de certains cadres expriments qui collaborent bien avec l'quipe de dveloppement, les dveloppeurs eux mme ont une expertise en mtier budgtaire. Les caractristiques de l'quipe favorisent l'agilit, en fonction du contexte et des objectifs d'amlioration, il faut dterminer quelle mthode est prfrable pour la mise en uvre la DB. Ce travail de recherche nous a permis de vrifier plusieurs mthodes en se focalisant sur les plus populaires savoir Extrme Programming et SCRUM aussi bien quau niveau mondial que du Maroc (cf. figure5-25). Les deux approches agiles se recoupent sur des notions similaires, elles sadressent des quipes de petite taille, travaillant dans un espace commun. Elles demandent limplication des clients pour prendre des dcisions. La communication est au centre de chacune des mthodes. Comme son nom lindique, Extrme Programming (XP) est une mthode extrmiste. Cette mthode prcise une douzaine de pratiques implanter. Cest la mthode qui se proccupe le plus de lexcellence technique. Elle comporte beaucoup dimpact sur lorganisation du travail. Cest une mthode difficilement applicable dans un milieu qui suit une structure traditionnelle en ce qui concerne les dfinitions de tches. Cependant, il est possible de classer les pratiques en trois groupes : les pratiques individuelles, dquipes et de gestion. Les pratiques individuelles, comme lautomatisation des tests, sont applicables. Les pratiques dquipes, tels que le code commun et la programmation en duo, sont partiellement applicables. Les pratiques de gestion, comme le calcul de la vlocit, sont difficilement applicables, mais peuvent sadapter. Nous ne pouvons appliquer intgralement cette mthode, mais plusieurs pratiques peuvent en tre extraites. SCRUM sintresse principalement la gestion de projet. Elle propose une excellente approche de la gestion des fonctionnalits pour composer le produit, elle suit des cycles
129
4. Contenu du guide
4.1. Organisation et acteurs du dveloppement logiciel
Le cycle de vie du systme dinformation de la DB suit un modle itratif et incrmental. Les caractristiques et les spcificits des phases de ce modle imposent une organisation adapte des instances et structures qui auront prendre en charge chacune d'entre elles.
131
133
134
4.2.
Charte projet
La charte de projet est un document contractuel entre le comit de pilotage oprationnel dune part et les instances dcisionnelles du projet dautre part (comit directeur et commission de liaison informatique). Il a pour objectif didentifier les dispositions spcifiques dorganisation de la phase de dveloppement. La charte de projet est initie en phase de dfinition dun nouveau systme dinformation. Sa dure de vie est celle de la phase de dveloppement du systme dinformation. Le contenu de ce document est principalement articul autour de quatre sections : La prsentation du projet : Cette section permet de dfinir le positionnement du projet par rapport au schma directeur, elle claire la nature des fonctionnalits demandes et leurs spcificits, la qualit du service attendu et les limites du futur systme dinformation ; Les acteurs et utilisateurs : Cette section identifie les noms et les responsabilits de toutes les personnes ou structures qui participent au projet informatique. Elle identifie aussi le nombre total des utilisateurs du futur SI en indiquant leurs domaines dactivit ; Le champ du projet : Cette section dfinit le cadre stratgique du projet, prsente de manire synthtique les objectifs et orientations de gestion du nouveau systme ; Le plan daction : Cette section prsente les diffrentes tapes importantes du projet en se basant sur le cycle de dveloppement du systme d'information et dfinit les principales dates du calendrier prvisionnel.
4.3.
La planification d'un projet est un outil incontournable pour le management de projet. Elle permet de : 135 Dfinir les travaux raliser ; Fixer les objectifs ; Coordonner les actions ;
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
136
4.4.
Exercer les activits de matrise des risques dans le projet de dveloppement logiciel se traduit par l'laboration d'un document intitul Tableau de suivi des risques . Le tableau de suivi des risques est initialis au dbut d'un projet et mis jour pendant toute la dure de vie du projet. En effet, plus un risque est dtect tardivement, plus ses consquences peuvent tre graves et difficilement rversibles. Il est prfrable que le document soit initialis et mis jour par le chef de projet et qu'il soit diffus lors des diffrentes runions de suivi du projet. Le comit de pilotage oprationnel est le responsable de llaboration du Tableau de suivi des risques avec limplication de tous les acteurs participants au projet. A la fin du projet, le document doit tre capitalis au sein de l'organisme afin de contribuer l'enrichissement de l'exprience pour les projets futurs. La dmarche d'laboration du document est la suivante : Analyse des risques :
Il s'agit tout d'abord d'identifier de manire la plus exhaustive possible tous les vnements gnrateurs de risques pour le projet, pouvant conduire au non respect des objectifs. L'identification initiale des risques s'effectue en fonction des objectifs, des exigences et du contexte du projet. Pour effectuer ce recensement, le chef de projet peut 137
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
Cette activit consiste ensuite mettre en uvre des dispositions appropries visant rendre les risques acceptables pour le projet. Ces dispositions peuvent tre de diffrents types: Suppression des causes ; Partage des responsabilits ; Limitation des consquences ; Acceptation du risque tout en le surveillant. Le choix des actions prventives engager est effectu en comparant les cots de leur mise en uvre avec les cots des consquences du risque, en tenant compte de leur probabilit d'apparition. Suivi de l'volution des risques :
Cette activit rgulire permet de suivre l'volution de la probabilit d'apparition des risques (stable, la hausse ou la baisse), de contrler la pertinence des actions prventives engages et ventuellement de corriger les dispositions prvues. De nouveaux facteurs de risques peuvent galement apparatre, au quel cas; il faut les ajouter la liste initiale. Enfin, il s'agit de surveiller le dclenchement des vnements redouts et leurs consquences relles. Le suivi des risques s'effectue au cours des runions de projet dans lesquelles les diffrents intervenants concerns sont convis. L'ordre du jour et le tableau de suivi des risques doit tre communiqu suffisamment tt afin de pouvoir proposer des actions. Un compte-rendu de runion est fait par le comit de pilotage oprationnel, auquel est joint le tableau de suivi des risques mis jour. Lannexe V contient un plan type du tableau de suivi des risques.
138
4.5.
L'laboration d'un cahier des charges fonctionnel dbute lorsque la phase de lancement du projet est termine (la charte de projet est valide). Les objectifs d'un cahier des charges fonctionnel sont : Prciser les orientations et le champ du domaine tudi ; Analyser l'existant au niveau organisation, documents utiliss, traitements effectus, donnes manipules ; Proposer des solutions d'organisation, fonctionnelles et techniques rpondant aux exigences et besoins exprims ; Obtenir une description globale du systme (organisationnelle, fonctionnelle, technique, contraintes majeures de scurit, de performance, interfaces avec d'autres systmes) ; Vrifier la faisabilit organisationnelle et technique ; Aboutir un choix argument d'une solution type de dveloppement. Ce document doit contenir les lments suivants : Authentification : Une page de garde doit contenir en plus du formalisme documentaire de la DB, la date et la signature du chef de projet et du chef de la commission de liaison informatique. Contexte : Dcrire l'environnement dans lequel s'inscrit le projet (stratgie, enjeux, domaine). Les objectifs : Dfinir les rsultats que le projet doit atteindre. Produit du projet: Proposer une description gnrale de ce produit. Les fonctions du produit : Etablir une liste des principales fonctionnalits du produit. Contraintes : Spcifier les Contraintes de cots, de dlais et les ventuelles autres contraintes prendre en compte dans le cadre du projet (normes techniques, clauses juridiques). Planification : Reprsenter l'articulation des grandes phases du projet et des principaux jalons. Ressources : Lister les ressources humaines et matrielles mise la disposition du projet.
139
CHAPITRE VI : REFERENTIEL DES BONNES PRATIQUES DE DEVELOPPEMENT LOGICIEL DE LA DB 4.6. Etude dtaille
L'tude dtaille vise l'exhaustivit de la description de la solution. Les spcifications dtailles sont la traduction prcise des besoins fonctionnels, techniques et organisationnels exprims par la matrise d'ouvrage ou les utilisateurs, en termes de : Traitements proposer aux utilisateurs de l'application ; Donnes grer par l'application ; Interface utilisateurs : crans, tats, enchanement d'crans ; Contraintes de scurit et techniques.
Le document d'tude dtaille se compose dune description gnrale du projet, une tude dtaille des acteurs et de lorganisation des procdures mtiers, une description des modules implmenter dans le nouveau SI, un schma du modle relationnel des donnes, et des maquettes des crans et des tats de sortie de lapplication. Lannexe VI contient une proposition dun plan type dun document dtude dtaille. Une fois le document d'tude dtaille valid par la commission de liaison informatique, il constitue le cahier des charges technique pour la production du nouveau systme dinformation.
4.7.
La production du code correspondant aux spcificits fonctionnelles et techniques issue des documents des spcifications fonctionnelles et de l'tude dtaille, doit respecter certaines rgles de dveloppement : Toute l'quipe de dveloppement est auteur du code et responsable de la qualit du code. Lcriture du code peut se faire deux sur la mme machine afin damliorer la qualit du code et surmonter vite les difficults. La rotation au quotidien des binmes implique une connaissance du code par toute lquipe. Ainsi, en cas de besoin, toute personne peut oprer des changements. Le nettoyage et l'puration du code doivent tre effectus priodiquement afin de garder une bonne lisibilit de ce dernier. Les rgles d'criture du code (convention de nommage, indentation, commentaires) sont dfinies et doivent tre suivies par tous les dveloppeurs. Les rgles de codage permettent d'assurer une meilleure lisibilit du code en utilisant le mme style de codage
140
4.8.
Les tests
Les tests doivent tre mens de manire organise et tre bien grs. Dans une application, il nest pas possible de tout tester, les facteurs humains ne peuvent tre pris en compte par linformatique. Cependant il faut bien sassurer que les tests rpondent une couverture technique et fonctionnelle afin que les risques pris au SI soient minimes. Il existe diffrents types de test que la DB doit effectuer afin de maximiser la qualit du produit final : Les tests techniques unitaires doivent tre effectus avant la livraison de chaque composant du produit logiciel, ils doivent tre faits par une personne indpendante de celle
141
142
CHAPITRE VI : REFERENTIEL DES BONNES PRATIQUES DE DEVELOPPEMENT LOGICIEL DE LA DB 4.9. Gestion des changements
La gestion des changements des besoins fonctionnels permet la DSI le contrle par des moyens humains et techniques de la qualit du systme dinformation produit tout au long de son cycle de vie. Les demandes de modifications interviennent en cours ou aprs llaboration du cahier des charges, ils doivent faire l'objet de procdures de gestion spcifiques. Les activits de gestion des changements sont mises en uvre lors du dveloppement initial d'un systme d'information, chaque itration de dveloppement ou en phase de maintenance. Les modifications peuvent tre de natures diffrentes :
Adaptative ou volutive du primtre fonctionnel, technologique ou organisationnel. Corrective suite une non-conformit (anomalie dans le logiciel).
143
Auteur
Priodicit
Destinataires
Missions
Au dbut dune itration du projet de dveloppement Runions de l'quipe Identification dun risque Expression de nouveaux besoins
Information
- Etape d'tude
pralable
- Changements
des besoins fonctionnels Etape dtude dtaille
Vrification Validation
Documents de formation
Manuel d'utilisation DSI (Equipe oprationnelle) DSI (Comit de pilotage oprationnel) Dbut de ltape de mise en uvre DSI (Comit de pilotage oprationnel) DSI (Equipe de formation) Comit directeur DSI (Equipe de formation) Utilisateurs DSI (Comit de pilotage oprationnel) Vrification Validation Information Action Validation Information Action Information Vrification Validation
Plan de formation
Tableau 6-1 : Liste des documents labors par la DB lors du projet de dveloppement
145
Deuxime page En-tte de page Titre Sous titre Corps du texte Titre des images et des tableaux Pied de page
A droite : [Numro de page] A gauche : MINSTERE DE L'ECONOMIE ET DES FINANCES - DIRECTION DU BUDGET Tableau 6-2 : Formalisme de prsentation des documents
4.11. Dploiement
Dployer une application informatique ne consiste pas seulement installer cette application mais aussi la grer. Le dploiement regroupe toutes les activits du cycle de vie du logiciel qui prend dbut depuis la fin du dveloppement. Dans le cas de la Direction du Budget, l'architecture 3-tiers des systmes d'information nous conduit au dploiement sur un seul serveur. Il y a cinq activits du cycle de vie mises en uvre : la formation, linstallation, la mise jour, la vrification de cohrence et la dsinstallation. - La formation : Un plan de formation et des supports de formation doivent tre mis au service des utilisateurs avant la mise en exploitation du nouveau systme d'information ; - Linstallation : Cette activit consiste la mise en exploitation du produit valid pour une ventuelle exploitation ; - La mise jour : la mise jour intervient suite une demande de modification reue et valide par la DSI ou une dtection d'une anomalie. Lorsquune nouvelle version est disponible, le service charg de l'exploitation assurera la mise jour des fichiers concerns sur le serveur d'exploitation ; - La cohrence : Vrifier la cohrence du logiciel, cest dire vrifier que tous les fichiers et rpertoires sont bien prsents ;
146
- Logicielle : Systme dexploitation : niveau de service pack ; Configuration du rseau (protocoles, noms et adresses) ; Configuration de la scurit (membre du domaine, domaine log on, utilisateurs locaux, droits daccs et politiques de restriction) ; Type de profiles et localisation des donnes de lutilisateur.
- Organisationnelle : Localisation physique du systme (btiment, tage et bureau ou salle) ; Propritaire du systme et la personne responsable ; Organisation des utilisateurs (groups, profiles).
La mise jour du logiciel en question doit tre accomplie en dehors du serveur de dploiement, il faut penser aussi tester les nouvelles fonctionnalits du produit avant de mettre jour la version mise en exploitation. En mode exploitation, chaque application doit avoir une fiche de gestion des versions qui contient les lments suivants : - Nom : le nom du module ou de l'application; - Version : la version mise jour ; - Objet de la mise jour ; - Etat : Quand les tests de la version sont valids, l'tat de la version est approuv, sinon il est en attente ; - OS support : le systme d'exploitation ou l'application est dploye; - Localisation : le chemin physique des fichiers du module dploy. Ces informations doivent tre l'objet d'un document de dploiement. 147
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
5. Conclusion
Le guide propos dans ce chapitre a t crit afin de favoriser le dveloppement dun logiciel de qualit. Il a trait lensemble des approches qui visent contrler le processus de la production logiciel. Nous avons essay desquisser quelques rgles de bonne pratique bases sur les directives de certaines mthodes standards et des expriences russies en matire de dveloppement logiciel. Ce guide ne prtend pas donner de solution dfinitive pour atteindre lexcellence dans la production logiciel, sa premire version ne prsente pas la liste exhaustive des directives du dveloppement. Nous pensons cependant que ce rfrentiel alimentera le dbat sur sa qualit et participera structurer les changes de bonnes pratiques, il sera ainsi lobjet des mises jour et des amliorations lors de sa mise en place. La participation des cadres de la DSI son laboration renforce les chances de russite de son intgration. La mise en uvre du nouveau rfrentiel requiert une bonne conduite du changement. Le chapitre suivant dcrit les conditions de la russite de la mise en uvre du prsent guide.
148
149
150
151
152
Destination Comit directeur CLI DSI CLI DSI CLI DSI Comit directeur CLI DSI
Tableau 7-1 : Plan de communication du projet de changement - Ralisation du projet : Cette tape consiste former les quipes sur les principes des mthodes agiles et certains outils de gestion du cycle de vie des projets de dveloppement logiciel. Lobjectif majeur de cette tape est l'intgration graduelle de nouvelles pratiques de dveloppement, de gestion et d'laboration des documents accompagnant toutes les phases des projets de dveloppement logiciel. - Matrise du projet : La phase du contrle et de pilotage consiste mettre en place des indicateurs pour assurer le suivi de l'avancement du projet de changement et mesurer la performance de la russite de ce projet. Ainsi cette phase peut conclure une amlioration et adaptation du rfrentiel. L'objectif est la validation du nouveau rfrentiel par les dcideurs de la Direction de Budget. Le rfrentiel des bonnes pratiques reste toujours sujet des amliorations requises lors des valuations futures. - Clture du projet : L'obtention des rsultats satisfaisants en termes de gestion du projet de dveloppement, de qualit du logiciel produit et du respect des dlais prvus nous mne la clture du projet du changement. C'est un engagement de toutes les parties prenantes du projet de dveloppement logiciel respecter les directives du nouveau rfrentiel. Par ailleurs, la mise en uvre de ce plan est tributaire dun ensemble de pr requis notamment en termes de moyens, de responsabilits et de matrise des dlais travers un planning prcis ; savoir : - Les ressources requises. - Lorganisation du projet. - Le planning prvisionnel. 153
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
3.1.
La mise en place d'un nouveau processus de dveloppement logiciel n'exige aucun logiciel, nanmoins, il est prfrable que la Direction du Budget utilise des outils de planification et gestion de projet de dveloppement informatique : - Team Foundation Server : C'est un outil de travail collaboratif dvelopp par Microsoft. Il accompagne la suite Visual Studio Team System. Il permet la gestion des sources (contrle de version, contrle de qualit du code), la gestion des builds, le suivi des lments de travail, la planification, la gouvernance de projet et l'analyse des performances. Il a pour but d'augmenter la productivit des dveloppeurs. - Microsoft Project : C'est un logiciel de gestion de projet dit par Microsoft. MS Project permet de planifier les projets et les ressources, et dassurer le suivi des projets pendant leur ralisation. Notons que la Direction du Budget dispose des outils Team Foundation Server et Microsoft Project.
3.2.
Le projet de changement engage toutes les ressources humaines agissant dans le projet de dveloppement pilote. Bien que la gestion du projet et la conduite du changement soient indissociables et doivent tre gres par la mme quipe, dans la mesure o l'quipe projet est celle qui connat le mieux le projet, une quipe interne spcifique constituera le comit de suivi du changement du processus, elle sera compose du chef du projet et deux autres membres qui assureront la bonne conduite du changement. Cette quipe permet d'assurer un suivi permanent des actions de conduite du changement, elle garantit d'une certaine manire la prennit de la dmarche. La mission de cette quipe n'est pas exclusivement ddie au suivi du changement, ses membres font partis des quipes oprationnelles, du comit de pilotage (et / ou) de la commission de liaison informatique. 154
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
3.3.
Les principaux postes de charges pour le budget de la mise en place du nouveau processus de dveloppement logiciel sont les sessions de formations et l'assistance dans la conduite du changement. Un plan de formation intitul "Comprendre lagilit et mettre en uvre une dmarche Agile pour vos Projets" a t propos la DB (cf. annexe XII), cette session est tale sur trois jours. Le devis a t estim 152 500,00 Dhs pour la formation d'une quipe de vingt personnes. Une autre session de formation l'outil de gestion de projet de dveloppement informatique "Visual Studio Team System et Visual Foundation Server" a t propose la DB (cf. annexe XII), cette session est tale sur une priode de 4 jours, le devis a t estim 32 000,00 Dhs pour une quipe de dix personnes. L'assistance d'un expert de conduite de changement est estime 8 000,00 Dhs/jour. Le besoin de la Direction du Budget en prestation dassistance est estim par une semaine (cinq jours) au dmarrage du projet, puis une prestation tout les deux semaines pour une priode de sept mois, soit une moyenne de vingt jours de prestation. Le tableau 7-2 rcapitule les diffrentes charges affrentes ce projet :
Volet Nombre de personne Prix unitaire
(DH / HT par jour)
Quantit
Prix moyen
(en DH/ HT)
3J 4J 20 J -
10 -
156
5. Le planning prvisionnel
La chronologie des vnements de la transition des pratiques de dveloppement logiciel au sein de la DSI peut tre progressive et programme sur plusieurs tapes : La prsentation du guide au profit des dveloppeurs de la Direction du Budget, ce guide leur a t distribu et nous avons pu recueillir leurs observations et leurs recommandations sur la premire version. La formation des cadres sur les approches de dveloppement agiles ; La formation sur loutil de gestion des projets de dveloppement informatique "Visual Studio Team System" ; Dans un souci de lintgration graduelle, lapplication des bonnes pratiques au code source la programmation des applications en cours de ralisation savoir SIG et E-Budget EPA et ladoption des pratiques de test technique, fonctionnel et test de non rgression, viennent en premier temps afin de familiariser les dveloppeurs avec les nouvelles rgles du codage. 157
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
158
159
160
7. Conclusion
La conduite du changement est une tape cl dans le dploiement du rfrentiel, elle dpend de la nature du changement (transformation, volution, correction), ainsi que du niveau de maturit du rfrentiel dans son cycle de vie. C'est une action complexe, la communication pourrait dsamorcer des craintes latentes de la matrise d'ouvrage. Cependant le rfrentiel expos dans ce travail offre aux membres du projet une mthodologie simple appliquer tout au long du cycle du dveloppement logiciel. Il propose une fluidit de communication entre les diffrents acteurs de lquipe, un formalisme de suivi des diffrentes actions de gestion de projet et du dveloppement logiciel. Les directives du guide des bonnes pratiques n'ont pas un caractre obligatoire, la russite du projet de dveloppement est prioritaire au projet du changement. Pourtant, l'amlioration du rfrentiel des bonnes pratiques est souhaitable au fur et mesure de son application, il est recommand d'ajouter au rfrentiel des niveaux d'obligations : - Les directives : elles ont un caractre obligatoire ; - Les recommandations : elles sont traduites par "obligatoire sauf si", la non application de ces recommandations est tolr ; - Et les bonnes pratiques : elles sont des pratiques optionnelles. La russite dun tel projet repose sur une bonne gestion de lquipe du projet, Il est essentiel d'encadrer le personnel de lquipe afin assurer le bon droulement du changement. La supervision est une autre cl majeur du contrle du bon rendement de l'quipe. La supervision et l'encadrement sont bass sur les lments suivants : Gestion du temps et des priorits : La gestion du temps et des priorits est au cur du fonctionnement de l'organisation du travail, il est recommand de : Prendre du temps en dbut de journe pour planifier son travail ; Respecter la rgle 60-20-20 en se concentrant sur l'essentiel (60 % pour les tches planifies, 20% pour les activits non planifies et 20 % pour les priodes tampons et les imprvus) ; laborer des listes de tches accomplir de faon les numrer et s'en rappeler ; Garder en tte les priorits pour faire le choix des tches dlguer et liminer. 161
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
162
CONCLUSION GENERALE
CONCLUSION GENERALE
163
CONCLUSION GENERALE
Le plan Maroc Numrique 2013 et le programme e-gouvernement adopts par le gouvernement marocain, mettent le secteur de l'information et tlcommunications au cur des proccupations de l'administration marocaine. En effet, la hausse des budgets d'informatisation le confirme, le dveloppement des systmes d'information reprsente des investissements consquents qu'il faut bien grer. La Direction du Budget qui s'est engage dans la dynamique egouvernement travers son portail extranet fdrateur E-Budget, gagnerait ; sans doute ; par la normalisation de ses pratiques de dveloppement, une augmentation de son retour sur investissement. La mise en uvre du cadre mthodologique des bonnes pratiques habiliterait la Direction du Budget assurer ladquation du logiciel produit par rapport aux attentes de la matrise d'ouvrage, accrotre la qualit de ce logiciel et respecter les dlais et le cot de sa production. Au terme de ce travail, nous avons pu exposer une description des diffrentes composantes du systme d'information de la DB, et nous avons labor une tude du processus de la production de ces systmes. Le schma directeur informatique de la DB a exprim la ncessit de la mise en place dun rfrentiel de dveloppement logiciel, lenqute ralise nous a permis de confirmer cette ncessit, ainsi nous avons pu dceler certaines difficults rencontres lors du dveloppement logiciel et recenser les perspectives d'amliorations exprimes par lquipe informatique de la direction. L'examen des pratiques mises en uvre dans le dveloppement logiciel et la capitalisation sur les expriences russies, ont t les principaux objectifs du Benchmarking du dveloppement logiciel ralis auprs des structures informatiques marocaines. Le nouveau rfrentiel des bonnes pratiques a t labor dans un cadre collaboratif. Le dsir damlioration continue et la volont de crer un milieu de travail quitable, sain et valorisant, doivent alimenter les dmarches pour mettre en uvre les bonnes pratiques du nouveau rfrentiel, ce qui ncessite un grand effort et une forte volont. En effet, la conduite du changement n'est pas un exercice linaire, il ne suffit pas de planifier adquatement pour que toutes les tapes se droulent harmonieusement, l'adaptation et l'amlioration du rfrentiel devraient tre parmi les principaux objectifs dans la conduite du changement. Il est souligner que l'implication de toute lquipe informatique de la Direction du Budget dans la mise en uvre du nouveau rfrentiel est l'une des cls de russite, cela ne serait possible qu' travers une compagne de communication qui permettra de faire adhrer et de motiver l'ensemble des acteurs du dveloppement logiciel au processus du changement.
164
CONCLUSION GENERALE
Le recours lexternalisation du dveloppement logiciel auprs dune socit soustraitante pourrait tre une alternative du dveloppement logiciel la Direction du Budget. En effet, elle permettrait un gain dans les dlais et la qualit, grce au potentiel du sous-traitant de mobiliser des ressources techniques conformes aux besoins des projets de la direction. Les ressources internes seraient ainsi libres et ralloues aux tches qui font le cur du mtier de la direction. Le rfrentiel prcdemment propos dans ce mmoire pourrait tre un des principaux piliers du cahier des charges labor par la DB, le sous-traitant devrait alors se conformer aux mthodologies de gestion des projets de dveloppement logiciel mise en place par la DB. Le rfrentiel expos dans ce mmoire, propose des pratiques standards qui peuvent tre introduites dans les autres directions du Ministre de lEconomie et des Finances. Pour les grands projets de dveloppement informatique, il est recommand de diviser le projet de dveloppement logiciel en petits modules qui seraient confis des petites quipes, cette structuration permettra dassurer la cohrence de ces quipes, de faciliter le partage des connaissances techniques et de simplifier les canaux de communication. La situation gographique des utilisateurs finaux dans les directions rseau doit tre prise en compte dans la dtermination de la dure de chaque itration, la priodicit du recueil des besoins fonctionnels et de la validation du produit de chaque itration sera plus grande. Toutefois, le prsent guide pourrait faire l'objet d'adaptation selon les critres d'organisation de chaque direction. Il est noter que le MEF pourrait capitaliser sur l'exprience de la TGR ayant des structures ddies la gestion des projets des systmes dinformation ; et un actif en termes de comptences et d'intgration des mthodes agiles. La qualit est une des priorits majeures du changement, la mise en place dun plan d'assurance qualit est en lui-mme un projet denvergure, le recours une dmarche qualit serait une tape importante dans le processus de la gouvernance du systme d'information de la Direction du Budget. Au del de la matrise des pratiques de dveloppement logiciel prsentes dans ce travail, il est recommand d'laborer des guides mthodologiques spcifiques chaque mtier de la DSI. L'intgration du systme dcisionnel de la DB devrait tre cadre par un rfrentiel des bonnes pratiques, il est souligner que la scurit des systmes d'information et la gestion des bases de donnes sont aussi des mtiers que la DSI devrait intgrer dans sa dmarche damlioration.
165
ANNEXES
ANNEXES
ANNEXES
ANNEXE I ANNEXE II ANNEXE III ANNEXE IV ANNEXE V ANNEXE VI ANNEXE VII ANNEXE VIII ANNEXE IX ANNEXE X ANNEXE XI ANNEXE XII ANNEXE XIII
Questionnaire I SPiCE - Pratiques par catgories de proccupations Questionnaire II Document de suivi davancement des projets Tableau de suivi des risques des projets informatiques Plan type dun document dtude dtaille Fiche de demande de modification Portefeuille de gestion des modifications Fiche d'anomalie Format et contenu de la page de garde des documents accompagnant les projets informatiques Format et contenu de la 2ime page des documents accompagnant les projets informatiques Plan de formation Comprendre lagilit et mettre en oeuvre une dmarche Agile pour vos Projets Plan de formation Visual Studio Team System et Team Foundation Server 2010
i vii xi xviii xix xxi xxiv xxv xxvi xxvii xxviii xxix xxxi
ANNEXES
ANNEXES ANNEXE I
QUESTIONNAIRE
Elabor par : Mr. Badr TALAGHZI Ingnieur dEtat grade principal
Le prsent questionnaire est tabli dans le cadre du projet de mmoire "Processus du dveloppement logiciel Paradigmes & Perspectives Cas de la Direction Budget". Lobjectif du projet est l'tablissement d'un rfrentiel des procdures de bonnes pratiques au niveau du dveloppement des systmes dinformation de la DB. Ce questionnaire nous permettra d'examiner lorganisation et les mthodes du travail au sein de la DSI, les diffrentes activits de lquipe informatique de la DB, et les perspectives damlioration.
[Cochez la bonne rponse]
- I - IDENTIFICATION
Votre Nom Voter adresse mail Votre fonction [Facultatif] [Facultatif]
ii
ANNEXES
I.5. Avez-vous suivi une formation complmentaire ?
Oui Non
Institution / Etablissement
Si oui, combien ?
De deux quatre Plus de quatre
II.2. Quelle est la dure moyenne des projets dont vous avez la charge ?
De quelques semaines 6 mois De 6 mois un an Plus dun an
Si oui, lesquels ?
Cahier des charges Document de conception Recueil de l'existant Manuel d'utilisation informatique Cahier de maintenance Autres
iii
ANNEXES
Si oui, laquelle ?
PMI Propre la DSI Autres (prcisez) :
Si oui, laquelle ?
Mthode traditionnelle Mthode agile Propre la DSI (maison) Autres (prcisez) : ...
IV.4. Utilisez-vous des normes, standards, best practices ou autre rfrentiel dans le cadre de vos activits ?
Oui Non
Si oui, laquelle ?
ISO, Laquelle ? CMMI SPiCE Propre la DSI (maison) Autres (prcisez) :
Si oui, laquelle ?
MERISE UML Autres, laquelle ?
Si oui, laquelle ?
Ms Project Pert Gantt Estimation des cots et des dlais Autres (prcisez) :
iv
ANNEXES
IV.6. Effectuez-vous des analyses post-projet ?
Oui Non
- V - DIFFICULTES RENCONTREES
V.1. Avez-vous connu des checs sur certains projets ?
Oui, beaucoup Oui, un peu Non, pas vraiment Non, pas du tout Ne sait pas
V.2 Selon vous, pour quelles raisons certains de vos projets ont-ils chou ?
Mauvaise attribution des responsabilits au sein de lquipe projet Cahier des charges incomplet Mauvaise estimation des cots et/ou des dlais du projet Changement continu des besoins des utilisateurs Mauvaises relations avec les utilisateurs Dfaillance des prestataires Autres (prcisez) :
- VI - PERSPECTIVES
VI.1. Si vous pouviez amliorer une seule chose, Que voudriez-vous amliorer en premier ( part le salaire !) ? Vous pouvez cocher plusieurs choix et classez les selon un ordre prioritaire.
Mthode de travail Organisation Communication Planification Autres
VI.2 Etes vous pour llaboration dun nouveau guide de bonnes pratiques de dveloppement logiciel spcifique la DB
Oui Non, Pourquoi?
ANNEXES
VI.4. En relation avec vos activits, quels sont les domaines dans les quels vous souhaitez faire une formation approfondie ?
Produits et logiciels Normes et mthodes Veille technologique Communication Autres, prcisez
VI.6 Quel est le standard sur lequel vous vouliez tre form ?
CMMi SPiCE ISO 9001 Autres standards, citez Pas besoin de formation
VI.8 Quel est la mthode agile sur laquelle vous vouliez tre form ?
SCRUM Extreme Programming Crystal Clear Autres mthodes, citez Pas besoin de formation
vi
vii
ANNEXES
ENG.2.2 ENG.2.3 ENG.2.4 ENG.2.5 ENG.3 ENG.3.1 ENG.3.2 ENG.3.3 ENG.3.4 ENG.4 ENG.4.1 ENG.4.2 ENG.4.3 ENG.5 ENG.5.1 ENG.5.2 ENG.5.3 ENG.5.4 ENG.5.5 ENG.5.6 ENG.6 ENG.6.1 ENG.6.2 ENG.6.3 ENG.6.4 ENG.6.5 ENG.7 ENG.7.1 ENG.7.2 ENG.7.3 ENG.7.4 ENG.7.5 Analyze software requirements Determine operating environment impact Evaluate requirements with customer Update requirements for next iteration Develop software design Develop software architectural design Design interfaces at top level Develop detailed design Establish traceability Implement software design Develop software units Develop unit verification procedures Verify the software units Integrate and test software Determine regression test strategy Build aggregates of software units Develop tests for aggregates Test software aggregates Develop tests for software Test integrated software Integrate and test system Build aggregates of system elements Develop tests for aggregates Test system aggregates Develop tests for system Test integrated system Maintain system and software Determine maintenance requirements Analyze user problem and enhancements Determine modifications for next upgrade Implement and test modifications Upgrade user system
Plan project life cycle Evaluate options for product development Select software life cycle model Describe activities and tasks Establish task sequences Document activities Establish project plan Develop work breakdown structure Identify project standards Identify specialized facilities Determine reuse strategy Develop project estimates Identify initial project risks Identify project measures Establish project schedule Establish project commitments Document project plans Build project teams Define project teams Empower project teams Maintain project team interactions Manage inter-team issues Manage requirements Agree on requirements Establish customer requirements baseline Manage customer requirements changes Use customer requirements Maintain traceability Manage quality
viii
ANNEXES
PRO.5.1 Establish quality goals PRO.5.2 Define quality metrics PRO.5.3 Identify quality activities PRO.5.4 Perform quality activities PRO.5.5 Assess quality PRO.5.6 Take corrective action PRO.6 Manage risks PRO.6.1 Establish risk management scope PRO.6.2 Identify risks PRO.6.3 Analyze and prioritize risks PRO.6.4 Develop mitigation strategies PRO.6.5 Define risk metrics PRO.6.6 Implement mitigation strategies PRO.6.7 Assess results of mitigation strategies PRO.6.8 Take corrective action PRO.7 Manage resources and schedule PRO.7.1 Acquire resources PRO.7.2 Track progress PRO.7.3 Conduct management reviews PRO.7.4 Conduct technical reviews PRO.7.5 Manage commitments PRO.8 Manage subcontractors PRO.8.1 Establish statement of work PRO.8.2 Qualify potential subcontractors PRO.8.3 Select subcontractor PRO.8.4 Establish and manage commitments PRO.8.5 Maintain communications PRO.8.6 Assess compliance PRO.8.7 Assess subcontractor quality
SUP
SUP.1 SUP.1.1 SUP.1.2 SUP.1.3 SUP.1.4 SUP.1.5 SUP.2 SUP.2.1 SUP.2.2 SUP.2.3 SUP.2.4 SUP.2.5 SUP.2.6 SUP.2.7 SUP.2.8 SUP.3 SUP.3.1 SUP.3.2 SUP.3.3 SUP.3.4 SUP.3.5 SUP.4 SUP.4.1 SUP.4.2 SUP.4.3 SUP.4.4 SUP.4.5 SUP.4.6 SUP.5 SUP.5.1 SUP.5.2 SUP.5.3
Develop documentation Determine documentation requirements Develop document Check document Distribute document Maintain document Perform configuration management Establish configuration management library system Identify configuration items Maintain configuration item descriptions Manage change requests Control changes Build product releases Maintain configuration item history Report configuration status Perform quality assurance Select project standards Review software engineering activities Audit work products Report results Handle deviations Perform problem resolution Prepare problem report Track problem report Prioritize problems Determine resolution Correct the defect Distribute the correction Perform peer reviews Select work products Identify review standards Establish completion criteria
ix
ANNEXES
SUP.5.4 SUP.5.5 SUP.5.6 SUP.5.7 SUP.5.8 Establish re-review criteria Distribute review materials Conduct peer review Document action items Track action items
- QUESTIONNAIRE Elabor par : Mr. Badr TALAGHZI Ingnieur dEtat grade principal Ministre de l'Economie et des Finances
Dans le cadre du projet de mmoire: "Processus du dveloppement logiciel Paradigmes & Perspectives Cas de la Direction Budget", le questionnaire1 cijoint a t labor pour recenser les bonnes pratiques et expriences en matire de dveloppement informatique, que a soit au niveau des secteurs public et priv. Ainsi, nous vous serons trs reconnaissants de bien vouloir remplir ce questionnaire afin de nous permettre de faire une tude des diffrents pratiques mises en uvre par les chefs de projets dans les processus de dveloppement logiciel et les comparer avec celui pratiqu au sein de la Direction du Budget.
Veuillez rendre ce formulaire par E-mail : talaghzi@db.finances.gov.ma Ou par courrier au nom de Mr Badr TALAGHZI - Chef de projet dveloppement Ministre de l'Economie et des Finance - Direction Budget Bd. Med V. Quartier Administratif - RABAT- Chellah MAROC
Les informations recueillies lors de cette enqute ne seront utilises aucune fin commerciale. Seuls les rsultats du questionnaire feront l'objet d'une publication dans le corps du mmoire.
xi
ANNEXES
I.
L'ORGANISATION
Votre Nom [Facultatif] Voter adresse mail [Facultatif] Le nom de votre organisme [Facultatif] Site web de votre organisme [Facultatif]
II.
II.1.
LE PROJET INFORMATIQUE
E-Learning Progiciel de gestion intgr (ERP) Dcisionnel Autres, prcisez
(KM)
II.2.
II.3.
2 3
Selon la nomenclature des mtiers de la DSI du CIGREF (Octobre 2009) Structure charge du systme dinformation dans votre organisme
xii
ANNEXES
II.4. Selon vous, quel est la taille du projet dans lequel vous participez?
Lobjectif de mon projet est clairement dfini ; il y a mme un consensus entre toutes les parties prenantes sur les livrables attendus, leurs critres dvaluation et les moyens mis en uvre pour les raliser Lobjectif de mon projet est dfini, mais les spcifications ne sont toutes pas prcisment identifies. Lobjectif de mon projet est mal dfini, il ny a aucune formalisation des besoins ; des informations contradictoires marrivent chaque jour. III.2.
Les besoins sont clairement exprims et formaliss par les utilisateurs. Le primtre fonctionnel est stable. Les besoins sont formaliss dans un cahier des charges, mais sont susceptibles dvoluer frquemment durant le projet. Les utilisateurs modifient leurs besoins frquemment, nous narrivons pas obtenir un premier niveau de fonctionnalits attendues. III.3.
III.4.
On a tabli, sans difficult, un plan de management du projet qui dcrit toutes les phases, les jalons, les activits et les livrables jusqu la fin du projet. Le plan du projet comporte un plan de dveloppement logiciel sommaire et un macro-planning prvisionnel donns titre indicatif, car susceptibles dtre ajusts On ne peut jamais rien planifier, puisque tout change systmatiquement compte tenu de lopacit des besoins et des contraintes.
IV.2.
xiii
ANNEXES
IV.3. Comment vous vous organisez ?
Organisation existante dans lorganisme Organisation impose par la hirarchie Par une dmarche structure. Laquelle?
IV.4.
IV.5.
V.
V.1.
LE PROCESSUS DU DEVELOPPEMENT
Intgration Autres, prcisez Maintenance
V.2.
V.3.
Elles sont relativement formalises avec certains utilisateurs mais on a du mal les impliquer tout au long du projet. On na aucun contact avec les utilisateurs.
V.4.
On a un plan qualit quon respecte trs rigoureusement en fournissant toute la documentation requise.
V.5.
xiv
ANNEXES
V.6. Au cours du dveloppement, comment grez-vous les changements des besoins fonctionnels ?
Nous sommes dsorients lorsque nous acceptons une demande de modification ou une nouvelle fonctionnalit. Aucune demande de changement nest accepte, une fois le cahier des charges valid. Nous sommes trs bien organiss : nous avons un processus de gestion des demandes de changement, un rle ddi leur suivi et un comit de contrle des changements.
V.7.
V.9.
V.10.
Non
V.11.
Non
xv
ANNEXES
VI. LA DOCUMENTATION
VI.1. laborez-vous une documentation dans le cadre de votre intervention ?
OUI NON
VI.2.
Si oui, lesquels ?
Cahier des charges Recueil de l'existant Cahier de maintenance Document de conception Manuel d'utilisation informatique Autres, Prcisez
VII. L'UTILISATION
Faible VII.1. Niveau d'effort dans la mise en exploitation (ou dploiement) du systme Niveau d'effort dans la conduite d'un changement ultrieur Moyen Fort Trs Fort
VII.2.
xvi
ANNEXES
VIII. VOTRE
AVIS
GLOBAL
SUR
LE
PROJET
DE
DEVELOPPEMENT
Selon vous, quelle est la rpartition globale de leffort sur les 4 ples :
Faible VIII.1. VIII.2. VIII.3. VIII.4. Dmarrage du projet Management du projet dveloppement Utilisation Moyen Fort Trs Fort
Moyen
Fort
Trs Fort
xvii
Le fichier du suivi de lavancement des projets contient les colonnes suivantes : 1. Tches : Cette colonne contient la description textuelle de la tche. 2. Ressources : Une personne doit tre affecte pour chaque tche. Inscrire dans cette colonne le nom de la ou des personnes charges de la tche. 3. Tches prvues : elle est fractionne en trois colonnes, la date de dbut prvue pour la tche, la date de fin prvue pour la tche et la charge de travail prvue pour la tche. 4. La charge de travail relle : cette colonne contient la charge de travail relle dj consomme pour la tche. 5. Achev (%) : On saisie dans cette colonne le pourcentage rel d'avancement de la tche. 6. Actualisation de la charge prvue : Cette colonne calcule automatiquement, en fonction du pourcentage d'avancement rel indique dans la colonne prcdente, la nouvelle charge estime pour la ralisation de la tche. Elle effectue l'opration suivante : charge de travail relle / pourcentage achev. 7. Variation de la prvision : Cette colonne est aussi calcul, elle effectue l'opration suivante : Actualisation de la charge prvue charge de travail prvu. Elle indique lerreur d'estimation dans les prvisions.
xviii
Le tableau suivi des risques se prsente sous forme d'un document Excel, compos de 10 colonnes. 1. Rf. Cette colonne contient un numro chronologique servant rfrencer rapidement une ligne du tableau. Le numro ne change pas pendant toute la dure de vie du document. 2. Date Cette colonne contient la date laquelle le facteur de risque a t identifi. La date ne change pas pendant toute la dure de vie du document. 3. Description du risque Cette colonne contient la description textuelle du facteur de risque ainsi que son contexte d'apparition. Si de nouveaux lments apparaissent venant complter le contexte d'apparition du risque, ils sont ajouts au fur et mesure dans cette colonne, prcds par la date de mise jour. 4. Impacts Cette colonne identifie et quantifie si possible les consquences si le risque se transforme en vnement certain, ainsi que les dates ou priodes d'apparition des consquences. 5. Type de risque Cette colonne permet la classification des risques des fins de regroupement pour traitement par les acteurs concerns.
6. Probabilit Cette colonne contient la probabilit d'apparition des consquences du risque (de 1 4).
xix
ANNEXES
7. Niveau d'impact Cette colonne permet de quantifier l'importance de l'impact si le risque se concrtise (de 1 4). 8. Poids du risque Cette colonne est obtenue en multipliant la probabilit par le niveau d'impact. On obtient un poids variant de 1 16. Les risques d'un poids suprieur doivent tre traits en comit de suivi du projet, ce sont des risques surveiller avec attention. Les risques d'un poids infrieur peuvent gnralement tre traits par l'quipe projet. 9. Actions prventives engages Il s'agit de lister ici les actions engages ou engager dans le but de rduire le risque. Les actions engages doivent tre ralistes, rvisables et mesurables en termes d'estimation de cots et de rsultats. Une date de ralisation de l'action doit tre ajoute afin de prciser le calendrier, ainsi que la personne ou l'quipe responsable de mener l'action. 10. Evolution du risque Cette colonne permet d'effectuer le suivi de l'volution du risque au cours du projet. Gnralement, on saisit la date du suivi et la tendance de l'volution, savoir si le risque se concrtise ou pas. Exemples :
jj/mm/aa : = (stable) jj/mm/aa : + ou ++ (augmente lgrement ou fortement) jj/mm/aa : - ou -- (diminue lgrement ou fortement) jj/mm/aa : 0 (risque clos)
xx
ANNEXES ANNEXE VI Plan type dun document dtude dtaille 1. Description gnrale
1.1 Prsentation gnrale de l'application Ce paragraphe a pour but de prsenter de manire gnrale l'ensemble de l'application. 1.2 Description des principales fonctions Ce paragraphe dcrit les principales fonctionnalits de l'application.
3. Description du module
Un module regroupe un ensemble d'oprations implmentes dans le logiciel. 3.1 Description du Module 3.1.1 Historique du module Mentionner les diffrentes versions du module et dcrire pour chacune d'elles les modifications par rapport l'ancienne version.
xxi
ANNEXES
3.1.2 Prsentation gnrale du module Faire une prsentation rapide du module. 3.1.3 Habilitations Dfinir ici les rgles d'habilitations pour le module (droits d'accs, confidentialit). 3.1.4 Liste des oprations Donner dans ce paragraphe la liste des oprations du module en compltant le tableau ci-dessous. Une opration est un ensemble de traitements automatiss (temps diffr ou temps rel) : cration, mise jour, annulation, consultation, dition, calcul... ou manuels. Rf de l'opration Nom de l'opration Type Opration nouvelle ou modifie CREATION ou MODIFICATION
3.1.5 Rfrences Entres/sorties Cette partie a pour but de dcrire la liste des enchanements d'crans, la liste des crans ainsi que la liste des tats. 3.1.5.1 Liste des enchanements d'crans Utiliser le tableau ci-dessous pour donner la liste des enchanements d'cran. Rf de l'enchanement d'cran Nom de l'enchanement d'cran
3.1.5.2 Liste des crans Utiliser le tableau ci-dessous pour donner la liste des crans. Rf de l'cran Nom de l'cran
3.1.5.3 Liste des Etats Utiliser le tableau ci-dessous pour donner la liste des tats. 3.1.6 Orientations techniques et contraintes. Dcrire dans ce paragraphe les orientations techniques et les contraintes du module considr en termes de performance, scurit 3.2 Description de l'opration 3.2.1 Prsentation gnrale Faire un texte introductif prsentant d'une manire gnrale l'opration.
xxii
ANNEXES
3.2.2 Rfrences donnes Tables consultes Tables Mises jour
3.2.3 Description des tches Dcrire l'ensemble des tches effectues par l'opration considre l'aide du tableau ci-dessous. Rf Type Description Table-attribut Type tche erreur Affichage rgles de gestion et de calcul Contrle Edition Avertissement Mise jour Traitement Saisie 3.2.4 Conditions d'excution Ce paragraphe permet de dcrire les conditions d'excution de l'opration (vnements dclencheurs, tats de donnes...). 3.2.5 Restriction dhabilitation Dcrire ici les restrictions par rapport aux acteurs indiqus dans le module. Erreur bloquante
5. Entres - sorties
5.1 Ecrans Les crans seront prsents sous la forme dune maquette cran. 5.2 Etats Les tats seront prsents sous la forme dune maquette tat. Dcrire aussi dans ce paragraphe les liens entre les champs de la maquette et les donnes. Champ de la maquette Donne Table Attribut ou nom de donne nom table ou indication calcule " calcul "
xxiii
Demande de modification
Direction Budget #Nom de projet# Application / Sous domaine : Description de la Demande Titre de la demande Description dtaille de la demande :
Responsable de suivi
xxiv
Numro de rfrence : c'est un numro incrmental qui identifie la demande de modification Type de la modification : Dsignez dans cette colonne l'origine de l'intervention (Modification adaptative, Modification corrective ou Anomalie) Titre de la modification : c'est le libell descriptif de la modification / anomalie. Date de la demande : (jj/mm/aaaa) Service demandeur : Structure de l'auteur de la demande Priorit : Cette colonne dfinit la priorit de l'intervention mener pour satisfaire la modification (les anomalies sont prioritaire). Gravit : pour les modifications de type anomalie, dsigner dans cette colonne la gravit de l'anomalie (Bloquante, non bloquante) Responsable de la modification : personne dsign par le chef de projet pour assurer le suivi de la demande. Action mener : Liste des actions mener pour la ralisation de la modification. Date limite de livraison de la modification : Renseignez dans cette colonne la date demande de la modification Etat : Etat de la demande ( prciser, analyser, accepte, ralise ou annule).
xxv
Fiche d'anomalie
Degr de gravit
Action prvue
Rserv la DSI - - -
Responsable de la correction
xxvi
ANNEXES ANNEXE X Format et contenu de la page de garde des documents accompagnant les projets informatiques
Contenu : Le logo en entte, le nom du document et le nom du projet au centre de la page. Un tableau en bas contenant les informations sur la date de cration du document, lauteur et la version.
xxvii
ANNEXES ANNEXE XI Format et contenu de la 2ime page des documents accompagnant les projets informatiques
Nom du document Tableau des mises jour du document A droite : Numro de page A gauche : MINSTERE DE L'ECONOMIE ET DES FINANCES - DIRECTION DU BUDGET
xxviii
Plan de formation Comprendre lagilit et mettre en oeuvre une dmarche Agile pour vos Projets
Lagilit permet de produire des applications mieux adaptes pour les clients de la DSI. Scrum offre un socle concret pour mettre en oeuvre des projets agiles quelque soit leur taille. Cette formation offre une vision claire des avantages de lagilit avec scrum et permet de comprendre pourquoi a marche et dans quelles conditions. Dans la pratique les participants collaboreront ensemble un jeu Agile (avec des legos), et il pourront comprendre lintrt dutiliser un outil agile (greenhopper).
Formateur
Laurent Meurisse a ralis lagilisation du S.I. dun grand groupe de commerces et a conseill de nombreuses entreprises outiller et industrialiser en agilit leurs projets. Au-del de laspect thorique scrum, Il connat bien la problmatique de la conduite du changement au sein des entreprises ainsi que laspect contractualisation des sous traitants. Sa devise agile est keep it simple !. Il crit actuellement un ouvrage sur lagilit et scrum aux ditions ENI (sortie juin 2011).
Contenu
Jour1matin
xxix
ANNEXES
Prsentation de Scrum
Monterl'quipeScrum L'espacedetravail Quelssontlesgrandsrendezvous
Jour1aprsmidi
Jour2matin
Jour2aprsmidi
Industrialisation des projets pour une DSI & une entreprise plus agile.
VersuneapprocheglobaledelagilitpourrendrelaDSIplus"agile" Assurerlatransitiondesprojetsagiles&innovantsversl'industrialisation Capterl'adhsionduclientfinalfaceauxnouveauxusages.
Jour3
Suite votre demande le formateur va rajouter unejourne deformation pour vous former autour de L'Extreme programming dont le contenu sera arrt d'un commun accordavecvousetleformateurlorsd'unconfcall.
xxx
Rfrence:
4 jours DMRTFS2010 La gestion du cycle de dveloppement logiciel est un exercice complexe et comporte de nombreuses facettes: choix d'une mthodologie, intgration des outils, suivi des versions, des bugs, ... La gamme de produits Visual Studio 2010 couple Team Foundation Server offre une solution cl en main permettant d'aborder cette problmatique. Ce cours anim par un instructeur aborde la fois les fonctionnalits des diffrentes ditions de Visual Studio 2010 et du serveur Team Foundation Server 2010 (TFS). Ce cours est destin aux dveloppeurs, chefs de projet et architectes souhaitant s'appuyer sur les outils de dveloppement Microsoft pour la collaboration de l'quipe de dveloppement et de la gestion du processus de dveloppement d'applications.
Module 1: Introduction Team System La problmatique sans Team System Le besoin d'une mthodologie est MSF (Microsoft Solution Framework) Personnalisation des mthodologies de Team System Visual Studio for Software Architects Visual Studio for Software Developers Visual Studio for Software Testers Visual Studio for Databases Developers Les rles dans Team System Principales fonctionnalits apportes par la version 2010 Module 2: Team Foundation Server Les composants de Team Foundation Server Architecture de Team Foundation Server Les Work items Le contrle de version Gestion des builds et des releases Module 3: Applications Clientes de Team System Le Team Explorer Utilisation de Microsoft Project Utilisation de Microsoft Excel Les outils DSI (Dynamic System Iniative) pour les architectes Les outils SDM pour les architectes Les outils DSL dans Team System Explorateur de contrle de code sources pour les dveloppeurs Le concepteur de classes La gestion des Check-in Les outils pour les testeurs
xxxi
ANNEXES
Module 4: Team system pour les chefs de projets Organisation de l'quipe Dmarrage d'un nouveau projet Slection d'une mthodologie (Msf, Msf agile et Scrum) Configuration du portail de Projet Configuration du contrle de version Configuration de la scurit Cration des itrations Paramtrage des stratgies de Check-in Ajout de documents Cration et gestion des Work items Module 5: Team System pour les architectes Le rle d'architecte Architecte d'infrastructure Architecte d'applications Les concepteurs de systmes distribus Le concepteur d'application Le concepteur de dploiement Les concepteurs UML L'explorateur d'architecture Diagrammes de squence Module 6: Team system pour les dveloppeurs Affichage des Work items Implmentation des applications Web et des services Web Utilisation du concepteur de classes Association des check-ins avec les works items Stratgies du contrle de versions Le dveloppement orient Test Les tests unitaires La couverture de code L'analyse statique Les build de Team Foundation Utilisation des rapports Utilisation du profiler Module 7: Team System pour les dveloppeurs de bases de donnes Projets de bases de donnes Comparaison de schma Dploiement de bases de donnes en production Comparaison de donnes Analyse d'impacts Module 8: Team System pour les Testeurs Cration de tests Tests manuels Tests gnriques Tests pour les applications Web Tests de monte en charge Test unitaires pour les bases de donnes Gestion des pools de machines et Labs Analyse des rapports de tests
D.M.R Immeuble SYNERGITECH, Z.I. de lAgavon, 18 Av. Lamartine, 13170 Les Pennes Mirabeau
xxxii
REFERENCES
REFERENCES
xxxiii
REFERENCES
12MANAGE 2010 AGM 2001 http://www.12manage.com/methods_pmi_pmbok_fr.html Site web des managers (consult en septembre 2010) http://agilemanifesto.org Manifesto for Agile Software Development - 2001
AQAP-2210 2006
http://www.nato.int/docu/stanag/aqap2210/aqap2210f.pdf
Exigences OTAN supplmentaires en matire dassurance de la qualit des logiciels pour lutilisation de lAQAP-2210
Edition 1 - Novembre 2006 (Consult en Aout 2010) Extreme Programming Explained Addison-Wesley - First Edition September 29, 1999 - ISBN: 0201616416 Kent Beck http://c2.com/ppr/about/author/kent.html Kent Beck (biographie). Sur le site de Cunningham & Cunningham, Inc. (Consult en Juillet 2010)
BECK 1999
BECK 2010
BOEHM 2003 Balancing Agility and Discipline: A Guide for the Perplexed Addison Wesley - August 15, 2003 - ISBN 0-321-18612-5 Barry Boehm, Richard Turner CARLIER 2006 Management de la qualit pour la matrise du SI LAVOISIER - 2006 - ISBN: 2-7462-1211-0 Alphonse Carlier Management de la qualit dans les systmes dinformation, cas de la direction du budget MEMOIRE POUR LACCES AU GRADE DINGENIEUR EN CHEF M. CHIKHI Mustapha Dcembre 2004
CHKHI 2004
CIGREF 1999 BENCHMARKING INFORMATIQUE Club informatique des grandes entreprises franaises CIGREF - Mai 1999 COCKBURN 2004 Crystal Clear A Human-Powered Methodology for Small Teams Addison Wesley Professional - 19 October 2004 - ISBN : 0-201-69947-8 Alistair Cockburn http://www.compute-rs.com/fr/conseil-402532.htm Pourquoi avons-nous besoin de gnie logiciel (Consult en Juin 2010) http://www.ctg.albany.edu/publications/reports/survey_of_sysdev/survey_of_sysdev.pdf A Survey of System Development Process Models Site web du Center for Technology in Government - University at Albany / SUNY - 1998 (consult en Mars 2010) http://www.commentcamarche.net/contents/genie-logiciel/cycle-de-vie.php3 Cycle de vie d'un logiciel (Consult en Juin 2010) http://www.agilealliance.org/system/article/file/1096/file.pdf Site de l'alliance agile (consult en juin 2010) Limitations of Agile Software Processes (pp: 43-46) Dan Turk, Robert France et Bernhard Rumpe - 7 September 2006 SOLUTIONS & LOGICIELS N 8 Juin Septembre 2009 Article "Quand Vidal devient Agile" P. 37 Jean Laurent Fabre de Morlhon
CVL 2010
DAN 2006
de Morlhon 2009
xxxiv
REFERENCES
DELOITTE 2008 Etude pour llaboration dun Schma Directeur du Systme dinformation de la Direction du Budget Phase 1 Analyse de l'existant V 1,10 22/07/2008 DELOITTE Conseil Etude pour llaboration dun Schma Directeur du Systme dinformation de la Direction du Budget Phase 4 Elaboration du schma directeur oprationnel V 0,25 16/06/2009 DELOITTE Conseil http://www.cdumortier.fr/ Management de la qualit / ISO 9000
Christian DUMORTIER
DELOITTE 2009
DUMORTIER 2010
Dzone 2010
http://agile.dzone.com software developement methodologies (Consult en Aout 2010) http://www.eweek.com/c/a/Application-Development/Report-Agile-Development-Hitting-theMainstream-539452/?kc=rss&utm_source=feedburner&utm_medium=feed&utm_campaign= Feed:+RSS/eweekdeveloper+(eWEEK+Developer) Agile Development Hitting the Mainstream, Report Says (consult en Dcembre 2010)
Par Darryl K. Taft (22-01-2010)
Eweek 2010
FLOWER 2006
http://martinfowler.com/articles/agileStory.html Writing The Agile Manifesto (Consult en Avril 2010) Martin Flower - 2006
GHEZZI 1991 http://www.prenhall.com/ghezzi/ Website to accompany Fundamentals of Software Engineering, Second Edition 1991
Par Carlo Ghezzi, Mehdi Jazayeri, and Dino Mandrioli (Consult en Juin 2010)
HIGHSMITH 2005
IBM 2010
http://www-01.ibm.com/software/awdtools/rup/ IBM- Rational Unifed Process (RUP) (Consult en Avril 2010) http://itil.fr/Table/CMMI/ Portail des Meilleurs pratiques IT (Consult en Aout 2010) http://www.commentcamarche.net/contents/qualite/itil.php3 Dernire modification le mardi 14 octobre 2008 17:40:32 par Jeff (consult en Aout2010) http://www.journaldunet.com Le journal du net (Consult en Janvier 2011) Metrics and Models in Software Quality Engineering Addison Wesley - 20 Septembre 2002 - ISBN: 0-201-72915-6
par Stephen H. Kan
http://www.knowllence.com/fr/publications/benchmarking_genevieve_krebs.php Knowllence - Le Benchmarking (Consult en Juin 2010) Leading change: Why transformation efforts fail Harvard business review, march-april 1995
Par J. Kotter (consult en Novembre 2010 sur le site http://hbr.org)
xxxv
REFERENCES
LARMAN 2003 Agile and Iterative Development: A Manager's Guide Addison Wesley - 11 August 2003 - ISBN : 0-13-111155-8 Craig Larman http://iso9001implementationdocuments.info ISO 9001:2008 Quality Management System (Consult en Aout 2010) Ismail Mohammad Latiff http://www.lemondeinformatique.fr/dossiers/lire-methodes-agiles-le-renouveau-des-relationsclient-fournisseurs-en-ingenierie-94-page-4.html Mthodes agiles : Le renouveau des relations client/fournisseurs en ingnierie Tmoignage utilisateur : Thierry Roche, DSI de l'Apec (consult en dcembre 2010) SOLUTIONS & LOGICIELS N 8 Juin Septembre 2009 Article "Le Club Med passe aux mthodes agiles pour ses migrations" PP: 38-39 Pierre Martin http://archive.numdam.org/ARCHIVE/RSA/RSA_1953__1_2/RSA_1953__1_2_5_0/RSA_1953__1 _2_5_0.pdf Revue de Statistiques Apliques, Tome1, N 2, (1953) P. 5-13 L'application des mthodes statistiques dans l'industrie
Par E. Morice (consult en Aout 2010)
LATTIF 2010
LMI 2010
MOUSSA 2010
rim.moussa.googlepages.com/MSE_XP.pdf eXtreme Programming - Cours Mthodologies de Dveloppement Logiciel - Master ISIL ESTI, U. 7 Nov Carthage R. Moussa (Consult en Aout 2010) http://www.mountaingoatsoftware.com/topics/scrum
Introduction to Scrum - An agile process (consult en juin 2010)
MSG 2010
NATO 1968
NATO Science commitee. Software Engineering. proceeding of NATO Software Engineering Conference, Garmish, Germany, 7th to 11th Oct 1968 http://www.iso.org Site Officiel de l'Organisation Internationale de Normalisation (Consult en Juillet 2010)
ORG-ISO 2010
PMBOK 2000 Guide de Rfrentiel des connaissances en gestion de projet Project Management Institue (PMI) 2000 PORRET 2010 http://www.itrmanager.com/articles/99276/forces-limites-methodes-agiles-conduire-projetinformatique- br-william-porret-fondateur-directeur-associe-enora-consulting.html Le magazine en ligne des professionnels de l'informatique (consult en Juin 2010) William Porret, fondateur et directeur associ dEnora Consulting - vendredi 8 janvier 2010
QUEST 2010
http://spreadsheets.google.com/viewform?formkey=dDNFdE9PZmp0bkZOSWdjeGs4 OWlDZmc6MQ
Page web du questionnaire : Processus de dveloppement logiciel GESTION DE PROJET - Vers les mthodes agiles Eyrolles - 2008 - ISBN 978-2-212-12165-0 Vronique MESSAGER ROTA http://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_r oyce.pdf Royce, W.W. Managing the developement of large software systems. Proceeding of IEEE WESON August 1970, page 1-9 (Consult en Mars 2010)
ROTA 2008
ROYCE 1970
xxxvi
REFERENCES
SEI 2008_1 http://www.sei.cmu.edu/library/assets/cmmi-dev-v12-fr.pdf CMMI pour le developpement, Version 1.2 Lamlioration des processus pour des meilleurs produits Lequipe produit CMMI - 2008 (Consult en Aout 2010) http://www.sei.cmu.edu/reports/08tn003.pdf CMMI or Agile : Why Not Embrace Both - November 2008 Site web : Software Engineering institue (Consult en Juin 2010) http://www.sei.cmu.edu Software Engineering Institue
SEI 2008_2
SEI 2010
SQI-SPICE 2010 STANDISH 2010 SWEBOK 2004 U-ANGERS 2010 VICKOFF 2010
http://www.sqi.gu.edu.au/spice/ Site web de Software Quality Institute (consult en Septembre 2010) http://www.standishgroup.com/ Site officiel du Standish group (consult en Septembre 2010) Guide to the Software Engineering Body of Knowledge - IEEE - 2004 Version A project of the IEEE Computer Society http://www.univ-angers.fr/docs/etudquassi/PI06_07.pdf Site de l'universit de Angers (consult en Juillet 2010) www.rad.fr Site historique de la mthode RAD (consult en juin 2010) Jean-Pierre Vickoff http://www.vtt.fi/inf/pdf/publications/2002/P478.pdf Agile software development methods (consult en Mai 2010) Abrahamsson, P. O. Salo, J. Ronkainen and J. Warsta http://www.extremeprogramming.org Extreme Programming - A gentle introduction
VTT 2002
XP 2010
xxxvii
La gestion du processus de dveloppement logiciel de la Direction du Budget (DB) repose sur une coute attentive et permanente de lensemble des services. Cette approche permet de cerner lvolution des besoins de la direction, dapprcier lapport de linformatique et de dceler les projets aptes rpondre aux attentes des utilisateurs en matire de traitement dune information riche et diversifie et de renforcement de la capacit dexpertise de la direction. Par ailleurs, le processus de dveloppement d'un systme d'information est soumis aux exigences accrues des utilisateurs, des contraintes de prennit et l'volution des technologies informatiques. Le travail prsent dans ce mmoire s'inscrit dans le cadre de l'tude du processus de dveloppement logiciel au sein de la DB. Cette tude sarticule autour de trois axes principaux : Le premier axe dcrit la cartographie du systme dinformation de la DB et le processus du dveloppement de ce systme. ce stade, nous avons men une enqute sur les mthodologies du dveloppement logiciel auprs des cadres et des responsables de la DSI de la DB afin d'enrichir l'analyse du processus de dveloppement logiciel. Le deuxime axe expose le fruit de la recherche bibliographique des principaux rfrentiels standards et mthodologies du dveloppement logiciel. Enfin, le troisime axe synthtise l'enqute mene auprs des structures informatiques marocaines afin d'examiner les pratiques de dveloppement logiciel mis en uvre par les chefs de projet. Nous proposons par la suite un rfrentiel des bonnes pratiques de dveloppement logiciel et une dmarche de sa mise en uvre.