Processus Du Développement Logiciel - Paradigmes & Perspectives

ROYAUME DU MAROC
MINISTERE DE LECONOMIE ET DES FINANCES
MEMOIRE
Pour lAccs au Grade dIngnieur En Chef
Processus du dveloppement logiciel Paradigmes & Perspectives
Thme
Cas de la Direction du Budget
Prpar par : M. Badr TALAGHZI
Ingnieur dEtat Grade Principal la Direction du Budget
Janvier 2011
ROYAUME DU MAROC
MEMOIRE
Pour L'Accs Au Grade D'Ingnieur En Chef
Processus du dveloppement logiciel Paradigmes & Perspectives

Cas de la Direction du Budget
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.
Division of Information System
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
Contexte & problmatique

1. Prsentation de la Direction du Budget Missions et attributions de la Direction du Budget 1.1. Organigramme de la Direction du Budget 1.2. Organisation de la Division du Systme d'Information Service de dveloppement des systmes mtiers 2.1. Service de l'architecture du systme d'information 2.2. Service de la communication et du dcisionnel 2.3. Service de lexploitation et du support 2.4. Le systme d'information de la Direction Budget Gense du systme d'information de la DB 3.1. Architecture du Systme d'Information de la DB 3.2. 3.2.1. Les mtiers 3.2.2. Le dcisionnel 3.2.3. La collaboration et la communication Problmatique du dveloppement logiciel la DB Le Schma directeur du systme d'information (2009-2012) Objectifs du schma directeur du SI de la DB 5.1. Thmes de progrs 5.2. Conclusion 6 6 7 9 10 11 12 12 13 13 14 16 20 21 21 22 22 23 23
2.
CHAPITRE I CHAPITRE II
3.
4. 5.
6.
Processus de dveloppement Logiciel de la DB

1. Management des projets informatiques Dmarche et organisation 1.1. 1.1.1. Comit de direction 1.1.2. Commission de Liaison Informatique (CLI) 1.1.3. Structure Informatique (DSI) Outils de management des projets informatiques 1.2 1.2.1. Schma directeur informatique 1.2.2. Plan de charges annuel 1.2.3. Planification du projet 1.2.4. Bilan annuel des ralisations Dveloppement de l'applicatif informatique Analyse et spcification des besoins 2.1. Spcification de l'architecture du systme d'information 2.2. Analyse fonctionnelle 2.3. Programmation 2.4. Les Tests 2.5. Documentation 2.6. 26 26 27 28 28 29 29 30 31 31 32 34 34 35 36 36 37
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
Mthodes traditionnelles ou mthodes agiles

1. Les approches traditionnelles Origine du gnie logiciel 1.1. Les processus de production dans une approche traditionnelle 1.2. 1.2.1. L'organisation du travail 1.2.2. Les modles du cycle de vie logiciel 1.2.3. Les mthodologies de dveloppement logiciel 1.2.4. Les acteurs dans une approche classique Limitations des approches traditionnelles 1.3. Les mthodes agiles Les bases de l'agilit 2.1. 2.1.1. Dfinition 2.1.2. Origine 2.1.3. Le manifeste agile 2.1.4. Les principes agiles 2.1.5. Les concepts de l'interdpendance L'apport de l'approche agile 2.2. 2.2.1. L'apport agile pour les dveloppeurs 2.2.2. L'apport agile pour le produit 2.2.3. L'apport agile pour le client 2.2.4. L'apport agile pour le projet Limitations des approches agiles 2.3. Description de quelques mthodes de dveloppement agiles Extreme Programming (XP) 3.1. 3.1.1. Les Valeurs d'Extreme Programming 3.1.2. Les pratiques d'Extreme Programming 3.1.3. Le processus d'Extreme Programming SCRUM 3.2. 3.2.1. Les trois phases de SCRUM 3.2.2. Processus de SCRUM Crystal Clear 3.3. Rapid Application Developpement (RAD) 3.4. Rational Unified Process (RUP) 3.5. Autres mthodes 3.6. Synthse des diffrences fondamentales entre l'approche traditionnelle et agile 54 54 55 55 57 58 58 59 59 59 59 60 60 60 62 62 62 62 63 63 63 64 64 64 65 66 69 70 70 72 72 73 73 75
2.
CHAPITRE III
3. 4.
XII
Dmarche qualit dans les systmes d'information

1. 2. Les Origines de la qualit Dfinitions Qualit 2.1. Qualit logicielle 2.2. Systme qualit 2.3. Management de la qualit 2.4. Assurance qualit 2.5. Manuel d'assurance qualit 2.6. Dmarche qualit 2.7. Management de la qualit totale (TQM) 2.8. Principes de management de la qualit Dmarches qualit Les normes de standardisation ISO 9000 4.1. 4.1.1. La norme ISO 9000:2005 4.1.2. La norme ISO 9001:2008 4.1.3. La norme ISO 9004:2009 4.1.4. La gestion documentaire du systme d'assurance qualit 4.1.5. La certification La dmarche CMMi 4.2. 4.2.1. Historique CMMi 4.2.2. Les niveaux de maturit CMMi 4.2.3. Architecture du modle CMMi 4.2.4. Les audits de certifications La dmarche SPiCE / ISO 15504 4.3. 4.3.1. Origines de la dmarche SPiCE 4.3.2. Les niveaux d'amlioration de la dmarche SPiCE/ISO15504 4.3.3. Architecture de la dmarche SPiCE La dmarche ITIL 4.4. Limitations d'une dmarche qualit Gestion de projet: le guide PMBOK Origine PMBOK 6.1. Cycles de vie d'un projet dans le PMBOK 6.2. Avantages et inconvnients du PMBOK 6.3. Conformit de l'approche agile aux dmarches qualit 78 79 79 79 81 81 81 81 81 82 82 85 85 85 86 87 87 88 89 89 90 91 92 93 93 93 94 95 97 97 98 98 100 101
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
121 122 123 124 126
Rfrentiel des bonnes pratiques de dveloppement logiciel de la DB

1. 2. 3. 4. Mthode et outils de travail Justifications du choix Objectif du guide mthodologique du dveloppement logiciel Contenu du guide Organisation et acteurs du dveloppement logiciel 4.1. 4.1.1 Pilotage global du systme d'information de la DB 4.1.2 Pilotage par domaine fonctionnel 4.1.3 Organisation de la structure des systmes d'information Charte projet 4.2. Planification et suivi de lavancement du projet 4.3. Gestion des risques 4.4. Rdaction du cahier des charges fonctionnel 4.5. Etude dtaille 4.6. Programmation & codage 4.7. Les tests 4.8. Gestion des changements 4.9. 4.10. Formalisme documentaire Dploiement 4.11 Conclusion 128 129 130 131 131 132 132 133 135 135 137 139 140 140 141 143 144 146 148
CHAPITRE VI
5. 1. 2. 3.
Conduite du changement dans la mise en uvre du nouveau rfrentiel

Contexte de la mise en uvre Plan prvisionnel de la mise en uvre Les ressources requises Les ressources logicielles 3.1 Les ressources humaines 3.2 Le budget estimatif du projet 3.3 L'organisation du projet de changement Le planning prvisionnel Mesure de la performance du changement Conclusion 150 152 154 154 154 155 156 157 160 161 163
CHAPITRE VII
4. 5. 6. 7.
Conclusion gnrale ANNEXES Rfrences

CONVENTIONS
Les rfrences sont cites dans le corps du texte entre deux crochets [] en petite taille et en GRAS. La rfrence se compose de deux parties, le premier mot renseigne l'auteur du livre, article ou site web. Pour certains sites web, le nom de l'auteur n'est pas renseign, on note alors un acronyme du site. La seconde partie renseigne l'anne de la publication du livre, article ou site web. Dans le cas o cette information n'est pas disponible pour certains sites web, on note alors l'anne de consultation.
XIV
LISTE DES FIGURES

Figure 1-1 Figure 1-2 Figure 2-1 Figure 2-2 Figure 2-3 Figure 2-4 Figure 2-5 Figure 2-6 Figure 2-7 Figure 2-8 Figure 2-9 Figure 2-10 Figure 2-11 Figure 2-12 Figure 2-13 Figure 2-14 Figure 2-15 Figure 2-16 Figure 2-17 Figure 2-18 Figure 2-19 Figure 2-20 Figure 2-21 Figure 2-22 Figure 2-23 Figure 2-24 Figure 2-25 Figure 2-26 Figure 2-27 Figure 2-28 Figure 2-29 Figure 3-1 Figure 3-2 Figure 3-3 Figure 3-4 Figure 3-5 Figure 3-6 Figure 3-7 Figure 4-1 Figure 4-2
Organigramme de la Direction du Budget Cartographie des principaux groupes applicatifs de la DB Organes mis en place pour le pilotage des projets informatiques Diagramme de squence illustrant le processus du pilotage des projets informatiques au sein de la DB Diagramme d'activits illustrant le processus de dveloppement logiciel la DB Architecture de dveloppement du systme d'information la DB Rpartition des rpondants par structure Rpartition des mtiers de la DSI au sein de la DB Rpartition des profils des cadres de la DSI au sein de la DB Anciennet des cadres de la DSI au sein de la DB Nombre de participation des cadres de la DSI dans les projets informatiques Dure moyenne des projets informatiques de la DB Taille des quipes informatiques de la DB Taux des participations dans les phases des projets informatiques de la DB Taux des participations dans l'laboration des documents informatiques de la DB Frquence des mises jour des documents dans les projets informatiques de la DB Organisation des projets informatiques de la DB Mthodologie de gestion de projet informatique de la DB Mthodes de dveloppement informatiques de la DB Normes et standards de gestion de projets informatiques de la DB Taux dutilisation des mthodes formelles dans la phase danalyse dans les projets informatiques de la DB Techniques de planification utilises lors des projets informatiques de la DB Analyses Post-projet informatique de la DB Taux des checs des projets informatiques de la DB Raisons dchecs de certains projets informatiques de la DB Difficults rencontres au processus de dveloppement logiciel de la DB Domaines damlioration prfrs des cadres informaticiens de la DB Dmarches de changement prfres par les cadres informaticiens de la DB Domaines de formation prfrs par les cadres informaticiens de la DB Prfrence de formation des cadres informaticiens de la DB en normes de certification Prfrence de formation des cadres informaticiens de la DB en mthodes agiles Rpartition des efforts du dveloppement logiciel Processus XP au niveau du projet Processus XP au niveau de l'itration Processus XP au niveau du dveloppement Processus XP sur la proprit du code commun Le cycle de vie SCRUM Les Phases de RUP Caractristiques de la qualit logicielle Roue de DEMING
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
LISTE DES TABLEAUX
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
38 56 61 75 91 95 96 99 109 145 146 153 155
XVII
LISTE DES ACRONYMES

AECID AFAQ AFNOR ANSI AQAP ASD ASP BLL BTP CCTA CDCF CDMT CEI CEN CLI CMMi CRC CST DAL DB DSDM DSI EPA ETSI FDD GID IEEE ISO ITIL J2EE LSD MEF OTAN PLF PMBOK PMI PNUD RAD RUP SADT SCAMPI SCE SEGMA SEI SI SIG SNIMA SPA SPiCE TGR TQM TSAVA UI UIT UML WBS XP Agence Espagnole de Coopration Internationale de Dveloppement Association Franaise pour l'Assurance de la Qualit Association Franaise de Normalisation American National Standards Institute Allied Quality Assurance Publications Adaptive System Development Active Server Pages Business Logic Layer Btiment et des Travaux Publics Central Computer and Telecommunications Agency Cahier Des Charges Fonctionnel Cadre de Dpense Moyen Terme Commission Electrotechnique Internationale Comit Europen de Normalisation Commission de Liaison Informatique Capability Maturity Models Integrated Classe, Responsabilit et Collaboration Comptes Spciaux du Trsor Data Access Layer Direction du Budget Dynamic Software Development Method Direction ou Division des Systmes d'Information Etablissement Public caractre Administratif European Telecommunications Standards Institue Feature Driven Development Gestion Intgre de la Dpense Institute of Electrical and Electronics Engineers International Organization for Standardization Information Technology Infrastructure Library Java Enterprise Edition Lean Software Development Ministre de l'Economie et des Finances Organisation du Trait de lAtlantique Nord Projet de Loi des Finances Project Management Body of Knowledge Project Management Institute Programme des Nations Unies pour le Dveloppement Rapid Application Development Rational Unified Process Structured Analysis and Design Technic Standard CMMI Appraisal Method for Process Improvement Software Capability Evaluation Service de l'Etat Gr de Manire Autonome Software Engineering Institute Systme d'Information Systme d'Information Gographique Service de Normalisation Industrielle Marocaine Software Process Assessment Software Process Improvement and Capability dEtermination Trsorerie Gnrale du Royaume Total Quality Management Taxe Spciale Annuelle sur les Vhicules Automobiles User Interface Union Internationale des Tlcommunications Unified Modeling Language Work Breakdown Structure Extreme Programming
XVIII
INTRODUCTION GENERALE
BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF
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].
Le dveloppement logiciel est un support
d'accompagnement de la DB dans sa gestion budgtaire, par consquent, le Schma Directeur
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
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
CHAPITRE I : CONTEXTE & PROBLEMATIQUE
Chapitre 1 Contexte & Problmatique

Tout en s'inscrivant dans la dynamique de modernisation enclenche par le Ministre de lEconomie et des Finances (MEF), le systme d'information de la Direction du Budget (DB) entend rpondre de manire concrte aux besoins de gestion de cette direction avec la proccupation d'amlioration des performances. C'est dans cet esprit que la Direction du Budget a adopt ds 1988, pour l'laboration de son systme d'information, une dmarche qui traite l'ensemble des aspects intervenant dans le processus d'informatisation. Ce chapitre propose de relater la gense de cette exprience et de dcouvrir les diffrentes composantes du systme d'information actuel de la Direction du Budget ainsi que la problmatique du dveloppement logiciel au sein de la DB.
1. Prsentation de la Direction du Budget

1.1. Missions et attributions de la Direction du Budget
La Direction du Budget se trouve au centre dun rseau de partenaires constitu essentiellement dadministrations, de collectivits locales, dtablissements publics, dadministrations publiques trangres et dorganisations internationales. Le rle de la Direction du Budget sarticule principalement autour de quatre axes principaux : La prparation de la loi de Finances, sa mise en uvre et le suivi de son excution, y compris la part relevant des tablissements publics ; Le traitement des problmes lis lenvironnement conomique, juridique, technique et financier du budget ; La mise en uvre et le suivi de financement extrieur des projets publics et de la coopration technique ; La gestion du personnel de lEtat, des collectivits locales et des tablissements publics. Dans ce contexte, la DB est charge : De prparer les projets de lois de finances et de veiller lexcution de ces lois ; De prparer les projets de lois de rglements en matire budgtaire et de veiller lexcution de la lgislation et de la rglementation dans ce domaine ; Dtudier en liaison avec les services intresss tous les projets de textes lgislatifs et rglementaires relatifs aux produits et revenus autres que fiscaux et domaniaux et de veiller lexcution de la lgislation et de la rglementation en la matire ; 6

De participer llaboration et lapplication de la rglementation en matire de rmunration et de pensions servies au personnel de lEtat, des collectivits locales et des tablissements publics ; De donner son avis sur les projets de budget des tablissements publics pralablement leur approbation ; De participer la dfinition des modalits du financement de projets publics et den coordonner la mise en uvre ; De suivre, en relation avec les services intresss, les mouvements des comptes spciaux du Trsor retraant des oprations caractre dfinitif.
1.2.
Organigramme de la Direction du Budget
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
DB 3 Sous Direction Charge Coordination Structurelles Sectorielles et Synthse
Division Financement Bilatral et Union Europenne
Division Personnel de l'Etat, des Collectivits Locales et des Etablissements Publics
Division Secteurs Administratifs
Division Financement Multilatral et des Fonds Arabes
Division Pensions
Division Secteurs de l'Infrastructure
Service des Suivi et de la Synthse
Division Finances Locales
Division Secteurs Sociaux
Division Normalisation des Dpenses Publiques
Division Secteurs Productifs et conomiques
DIVISION DU SYSTEME D'INFORMATION
Division Secteur Agricole et de la Compensation
Service Affaires Gnrales
Division Synthse et de la Coordination
Division de la Rforme Budgtaire, du Suivi de l'excution du Budget et de la Loi de Rglement
Figure 1-1: Organigramme de la Direction du Budget
2. Organisation de la Division du Systme d'Information

La DSI1 est le matre duvre de la mise en place et le pilotage oprationnel de lensemble des oprations entrant dans le cadre de linformatisation du systme dinformation de la Direction du Budget. Ses attributions sont bases autour de trois domaines: Le dveloppement informatique Gnraliser lautomatisation du systme dinformation pour rpondre, dans les meilleures conditions, aux besoins dtudes, de prparation, de suivi et de prvision budgtaires ; Concevoir des systmes intgrs avec les partenaires de la Direction du Budget afin damliorer les dispositifs de suivi et dassurer une fluidit de communication des informations ; Faire voluer lapplicatif en fonction des besoins des utilisateurs, assurer linstallation des nouvelles versions de lapplicatif et veiller ladministration des rseaux, des serveurs, des postes de travail et des imprimantes ; Elaborer et mettre en uvre un plan de scurit informatique permettant la direction de protger son patrimoine informationnel et de continuer lexploitation de ses systmes informatiques en cas de problme de fonctionnement dun ou de plusieurs composantes de son systme global ; Coordonner et synchroniser les diffrentes composantes du processus dinformatisation. La communication Mettre en place une bureautique intgre offrant un outil daide la dcision et de communication entre les diffrents services ; Assurer la reprsentation de la Direction du Budget dans les commissions inter-directions et les chantiers de rforme et de modernisation ayant trait linformatique, la communication et les systmes dinformation ; Grer le fonds documentaire du patrimoine informatique de la direction.
Division du Systme d'Information 1

La formation et support Elaborer et mettre en uvre des actions planifies de formation, dassistance, de perfectionnement et de recyclage du personnel de la Direction du Budget en matire de traitement de linformation ; Garantir lentretien et le renouvellement des moyens matriels et logiciels ; Assurer lassistance de lutilisateur et tre linterlocuteur du prestataire de service en ce qui concerne la maintenance corrective et volutive des logiciels de base ; Assurer la fonction de veille technologique pour garantir une actualisation continue du patrimoine informatique et mettre en place progressivement de nouveaux outils en vue de permettre lutilisateur de profiter des innovations de la technologie de traitement de linformation. La DSI est compose de quatre services qui sarticulent autour des orientations majeures de la fonction informatique, elle dispose d'un service de dveloppement des systmes mtiers, d'un service de l'architecture du systme d'information, d'un service de la communication et du dcisionnel et d'un service de lexploitation et du support.
2.1. Service de dveloppement des systmes mtiers

Il est charg du dveloppement et de la maintenance des systmes applicatifs conformment aux exigences de la direction du point de vue mtier, qualit, performance, cot et dlai. Le champ daction du service couvre tout le primtre fonctionnel de la DB. En effet, ses fonctions constituent un support dtudes, dlaboration et de suivi recouvrant tous les mtiers de la Direction du Budget : llaboration des projets des lois de finances, la gestion des mouvements de suivi de lexcution du budget, llaboration de la loi de rglement, ldition des documents et statistiques budgtaires et la gestion de lexcution financire des accords de financements accords par les bailleurs de fonds. Ce service se charge de couvrir toutes les tapes du cycle de vie dun projet informatique depuis son identification jusqu la fin de son excution. Ces tches sarticulent autour des applicatifs ci-aprs :
Gestion des crdits du budget de l'Etat (Budget gnral, Comptes spciaux du trsor et SEGMA) E-Budget Morasse2; Gestion des mouvements des crdits budgtaires E-Budget Mouvement; Gestion du Budget de l'Etat volet effectif E-Budget Tableau des effectifs;
Systme d'laboration dlocalise de la morasse budgtaire 2
10

Aide la prparation de la loi de finances E-Budget PLF; Administration des applications E-Budget Administration; Gestion du budget des tablissements publics caractre administratifs E-Budget EPA; Gestion des Financements des projets publics via un systme d'information gographique SIG; Gestion du parc Automobile de lEtat assujetti la Taxe Spciale Annuelle sur les
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.
2.2. Service de l'architecture du systme d'information

Ce service est une structure stratgique au sein de la DSI, il est responsable de la conception des diffrentes briques du systme d'information, il assure la mise en uvre des infrastructures matrielle et logicielle, il est aussi responsable de la qualit et des procdures de production du systme d'information. Son objectif d'urbanisation du systme d'information se traduit par: La participation la dfinition, llaboration et au suivi de la mise en uvre du schma directeur informatique de la Direction du Budget; La participation la dfinition et la mise en place dune stratgie de scurit pour le SI et son environnement; La veille technologique et la gestion dimpact de lintroduction de nouvelles technologies dans le systme dinformation de la DB. Le service assure aussi la fonction de communication via: La veille au suivi et lalimentation des sites intranet et internet du MEF (Volet DB) ; La mise en place du portail intranet de la Direction du Budget travers lintgration des diffrents systmes dinformation, et lintroduction des outils collaboratifs ; La veille la mise en place et au renforcement des outils dautoformation (eLearning) sur les outils informatique, bureautique et de travail de groupe ; Laccompagnement des utilisateurs de la DB dans lexploitation des systmes dinformation. Ce service dispose d'une quipe de quatre ingnieurs, deux informatistes et un technicien. 11
CHAPITRE I : CONTEXTE & PROBLEMATIQUE 2.3. Service de la communication et du dcisionnel

Ce service est charg de construire un espace de travail dcisionnel organis autour dune banque de donnes informationnelle dont les composants sont intelligibles pour le non informaticien, lhabilitant oprer aisment toutes sortes de manipulations de donnes pour les transformer en informations. Par consquent, le service assure la mise en uvre des protocoles dchanges et leur actualisation en fonction des changements qui interviennent dans lenvironnement interne et externe. Ses tches s'articulent principalement autour : La dfinition des spcifications technico fonctionnelles des instruments d'analyse; La mise en place des instruments d'analyse et prototypage des modules ; La mise en uvre du modle de simulation ; Ldition des travaux de reporting ; Les actions d'accompagnement : support auprs des utilisateurs du systme dcisionnel ; La dfinition, et mise en uvre des protocoles dchange avec les partenaires ; La mise en place dun tableau de bord de suivi des changes. Ce service dispose d'une quipe de trois ingnieurs et un informatiste.
2.4. Service de lexploitation et du support

Ce service est charg de lexploitation du patrimoine matriel et logiciel de la direction, de ladministration des systmes et du rseau, de la surveillance du systme (charge, performance, scurit, disponibilit), de la gestion des incidents (reprise), des sauvegardes, de la maintenance des quipements; et ventuellement de la gestion de la scurit. Ses tches sont dtailles ci-dessous:
Administrer le parc informatique, les systmes dexploitation, les systmes de bases de

donnes, les applications et les rseaux informatiques ;
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 ;
Concevoir et mettre en uvre un rseau informatique scuris de la direction et assurer

son interconnexion avec les diffrents systmes dinformation des partenaires ;
12
CHAPITRE I : CONTEXTE & PROBLEMATIQUE Mettre en place linfrastructure physique et logicielle ncessaire pour le dveloppement
et l'exploitation du patrimoine informationnel ;
Concevoir et mettre en uvre la politique de maintenance des applicatifs et des

infrastructures techniques et de tlcommunication et des systmes dinformation ;
Elaborer le plan d'action du service en harmonie avec les orientations de la direction et

veiller au suivi de son excution ;
Assurer lentretien et le renouvellement des moyens matriels et logiciels, lassistance

des utilisateurs et tre linterlocuteur des prestataires de service ;
Mettre en place un systme dassistance aux utilisateurs dans les domaines de la

bureautique, des applicatifs et des tlcommunications. Ce service dispose d'une quipe de trois ingnieurs et trois techniciens.
3. Le systme d'information de la Direction du Budget

3.1. Gense du systme d'information de la DB
Dans un souci de satisfaction des exigences continuellement changeantes des mtiers de la DB, le processus dinformatisation de la direction du budget a volu, conformment aux volutions technologies afin de faire profiter la DB du maximum des nouvelles technologies de linformation. Le 1er plan directeur (1988-1992) avait comme objectif principal lautomatisation des domaines prioritaires au vu des missions de la DB. Ce plan a aboutit la conception, la ralisation et la mise en uvre des sous systmes de gestion des crdits budgtaires (MASSIRA), de gestion des postes budgtaires (OTOR) et de gestion des projets financs (TAMWIL). Llaboration du 2me plan directeur (1994-1998) a concid avec le dbut de gnralisation des technologies de linformation indpendantes des constructeurs traditionnels et l'apparition d'un concept du poste de travail intelligent matrialis par un microordinateur standard (le PC) dot du systme d'exploitation WINDOWS qui est devenu un standard de fait. Ce plan est venu donc consolider les acquis du 1er plan travers la gnralisation de lautomatisation et lintroduction massive de la bureautique.
13

Le troisime plan (2000-2005) a mis laccent sur les actions lies la communication, la valorisation du patrimoine informationnel budgtaire et la gnralisation des outils de communication et de travail de groupe. La priode (2005-2008) s'est caractrise par l'intgration du systme d'information EBudget des diffrents mtiers de la DB, l'ouverture de ce systme sur les diffrents partenaires de la DB, la mise en place d'un portail dcisionnel de la DB et le renforcement des outils de travail de groupe (Mise niveau du site intranet). Afin daccompagner les diffrents chantiers de Rforme dans lesquels sest inscrite la Direction du Budget, et en vue de mettre en place un cadre dvolution stratgique du SI devant assurer lalignement sur la stratgie mtier, une tude a t ralise avec le concours dun bureau dtudes international (Deloitte Conseil) pour llaboration du schma directeur du SI. Cette tude a abouti la dfinition dune feuille de route pour la priode 2009-2012, fixant les axes dvolution du systme dinformation ainsi que la cible atteindre, les chantiers mener pour construire cette cible (stratgiques, applicatifs et techniques) et leffort dinvestissement en termes de moyens matriels et humains.
3.2.
Architecture du Systme d'Information de la DB
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
TDB Finances Locales
Excel
E-Budget Consultation
Oprations
Financement SIG Elaboration budgtaire E-Budget GID "TGR" Prparation LF E-Budget PLF
Echange
Support
Gestion du courrier
Site internet et intranet du Ministre Messagerie lectronique
Gestion Incidents E-Budget Administration Intranet de la Direction du Budget
- 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"
MANAR "Echanges DEPF" Systme Intgr de Gestion des Ressources Humaines
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

Les budgets des SEGMA portant sur 190 budgets, ainsi que les arrts de relvement du plafond des charges y affrentes ; Une soixantaine de Comptes Spciaux du Trsor (CST) et arrts portant relvement de plafonds des charges les concernant ; Les financements extrieurs des projets publics (prts ou dons) de type multilatral ou bilatral. Au regard de son architecture fonctionnelle, le SI actuel sarticule autour de trois axes : laxe mtier ; laxe dcisionnel et laxe collaboratif & communication.
3.2.1. Les mtiers

Laxe Mtier est bti autour de la solution e-Budget qui constitue le socle de ce systme. Cette solution a t conue selon une vision dintgration de lensemble des mtiers de la Direction du Budget. Sa mise en uvre est faite selon une dmarche progressive privilgiant les besoins prioritaires.
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

Le calcul des diffrentes composantes de la dpense du personnel de l'Etat; La prise en charge des projets de texte et loi inscrire dans le projet de loi de finances ; La prise en charge des propositions relatives aux crations des postes budgtaires ; Les ditions en arabe et en franais dlocalises des diffrents Tableaux du PLF. Ce module a t mis en uvre en 2010. Elaboration des documents budgtaires de lEtat
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

Gestion de la nomenclature budgtaire (Rfrentiel Budgtaire) Ce module permet la prise en charge de la nomenclature budgtaire, il est dcompos en sept grandes fonctionnalits : La nomenclature administrative. La construction des chapitres administratifs. La nomenclature fonctionnelle des dpenses. La nomenclature conomique des dpenses. La nomenclature conomique des recettes. Le lexique des paragraphes. Le lexique des lignes. Ce module a t mis en uvre en 2006. Gestion des mouvements des crdits budgtaires Ce module permet la prise en charge des mouvements des crdits budgtaires dans un souci de l'tablissement de la loi de rglement. Ce systme a t remplac par le systme GID3 offert par la TGR4 aux gestionnaires de la Direction du Budget. Cette opration entre dans un cadre d'intgration des systmes d'information du Ministre de l'Economie et des Finances. Le module a t mis en uvre en 2007. Consultation du patrimoine informationnel (Consultation Budgtaire) Ce module permet aux partenaires de la direction du budget dexploiter son patrimoine informationnel budgtaire suivant plusieurs axes danalyse et ce, pour les besoins dtude, de prvisions et de comparaison. Ce systme a t remplac par le portail dcisionnel de la Direction du Budget lors du dploiement de ce dernier en 2008. Elaboration des budgets des tablissements publics (EPA)
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

Llaboration de la Loi cadre ; Lchange informatis des donnes avec les diffrents partenaires; Lanalyse multicritre laide des tableaux de bord et des outils dcisionnels ; La communication avec les systmes dinformation des entreprises et tablissements publics travers des fonctionnalits dchange, dintgration et de compatibilit ; La prise en charge de la base juridique concernant les tablissements publics. Ce module a t mis en uvre en Fvrier 2011. Gestion parc automobile de l'Etat Ce module qui a t mis en uvre en Mars 2011, permettra la gestion du parc automobile de l'Etat, ainsi il prend en charge : La gestion des programmes d'achat ou location des vhicules au profit des organismes public; Le suivi des paiements des Taxe Spciale Annuelle sur les Vhicules Automobiles. Administration du systme Ce module transverse toutes les applications du systme E-Budget, permet de grer la stratgie daccs au patrimoine applicatif de la Direction du Budget en termes de donnes et de fonctionnalits. Ladministration du systme E-Budget et de lensemble de ses composantes est centralise au niveau de ce module. Il a t mis en uvre en 2006.
Systme dInformation Gographique (SIG)

Outre le systme E-Budget, la Direction du Budget s'est engag pour la mise en place dune Carte de projets de dveloppement via un Systme dInformation Gographique (SIG) permettant une gestion harmonise des donnes et informations relatives aux projets de dveloppement. Ce systme est le fruit d'un partenariat avec le PNUD5, et la collaboration de l'AECID6. Il a une forte valeur ajoute en terme dorganisation, de communication, de mise jour et de facilitation de laccs linformation sur les projets de dveloppement. Il permet notamment de disposer de: Un outil danalyse et daide la dcision, favorisant : Un meilleur appui aux priorits nationales de rfrence ;
Programme des Nations Unies pour le Dveloppement 5 Agence Espagnole de Coopration Internationale de Dveloppement 6
19

Une rduction des inadquations, duplications ou autres carences au niveau de la planification de laide; Un outil de communication et de publication de linformation, permettant ltablissement ponctuel de rapports et autres bilans ; Un outil de travail en quipe et de coordination, permettant: Une consolidation de la coordination entre les partenaires du dveloppement ; Une matrise accrue des cots des transactions et, terme, rduction de ces cots. Ce systme est mis en service en Octobre 2010.
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

3.2.3. La collaboration et la communication
Laxe Collaboratif et communication : Le dveloppement de ce dernier axe trouve son essence dans le renforcement des outils de communication et du travail du groupe (groupware) et la valorisation du patrimoine informationnel. Cet axe est davantage renforc par la mise en place du rseau Intranet qui constitue un instrument de travail incontournable dans laccomplissement des tches via des fonctionnalits lies laccs, lchange, le partage et la recherche des documents, en plus de la disponibilit de services en ligne et laccs aux applicatifs web (Extranet budgtaire, dcisionnel). Compte tenu de la ncessit doffrir un point focal daccs lensemble des ressources de la Direction du Budget, en fonction des habilitations et moyennant une authentification unique, loption de mise en place dun Portail fdrateur et collaboratif a t retenue. Cette mise en place a t entame par la ralisation des modules prioritaires, notamment celui relatif la prparation de la Loi de Finances.
4. Problmatique du dveloppement logiciel la DB

La Direction du Budget a fait le choix stratgique du dveloppement de son systme d'information avec ses ressources internes, cependant la DSI confronte certains obstacles qui ralentissent son processus de dveloppement logiciel et rduisent l'efficacit de ses quipes. Ces obstacles concernent principalement l'organisation de la DSI, la mthodologie de gestion de ses projets informatiques et ses relations avec le matre d'ouvrage [DELOITTE 2008] : Lorganisation actuelle de la Division du Systme dInformation ne permet pas de rpondre pleinement la stratgie de la Direction du Budget. En effet, le mode dorganisation actuel correspond une gestion oriente plus quipe que projet . La mthodologie de gestion des projets informatiques nest pas formalise. Les rles des diffrents acteurs et notamment des utilisateurs dans le processus de dveloppement logiciel ne sont pas clairement dfinis, ce qui limite leur niveau dappropriation du SI et leurs responsabilits quant la qualit du SI quils utilisent. Les projets ne sont pas systmatiquement conduits en partenariat avec les divisions mtiers sur toutes les phases de leur cycle de vie. En effet, les divisions mtiers ne sont consultes qu'en amont du projet et lors de la formation sur le produit, elles ne sont pas impliques dans le pilotage des projets, donc les projets sont raliss sans vritable matrise 21

douvrage agissant en interface entre les divisions mtiers et les quipes informatiques. Certains projets ne disposent pas dune expression de besoins formalise et les phases de validation des spcifications fonctionnelles et de recette fonctionnelle ne sont pas ralises dans un cadre formalis avec les divisions mtiers. De ce fait, Labsence de la fonction dassistance la matrise d'ouvrage ainsi que la faible implication des utilisateurs dans le processus de dveloppement dapplication et de recette pourrait conduire au dveloppement dapplications partiellement adaptes aux besoins des utilisateurs. Le processus de gestion des changements nest pas formalis et il nexiste pas de processus formalis de gestion des versions. En fait, les modifications apportes aux applications par les quipes de dveloppement, bien que nombreuses, ne sont pas journalises. Les demandes de changement provenant des utilisateurs ne sont pas formalises. Il en va de mme pour les changements qui sont raliss. Il est donc impossible de suivre la satisfaction des demandes des utilisateurs. D'une manire gnrale, les projets ne sont pas suffisamment documents. La gestion des risques dans le management des projets de dveloppement logiciel est inexistante.
5. Le Schma directeur du systme d'information (2009-2012)

5.1. Objectifs du schma directeur du SI de la DB
A travers la ralisation du schma directeur 2009-2012 de son systme dinformation, la Direction du Budget souhaite atteindre les objectifs suivants : Disposer dun systme dinformation permettant la matrise de l'exercice des mtiers et favorisant la performance ; Faire du systme d'information un instrument de prvision budgtaire permettant d'anticiper les changements et les mutations futures de l'environnement ; Amliorer lchange dinformations avec les partenaires de la Direction du Budget par linstauration de protocoles de communication permettant un change rgulier de linformation et lintgration ventuelle avec les systmes structurants du ministre ; Mettre en place un systme d'information permettant de mesurer et d'valuer les performances de l'administration dans la mise en uvre des diffrentes rformes structurelles et sectorielles entreprises par le Gouvernement ;
22

Accompagner efficacement la politique mene par la Direction du Budget en matire dutilisation des technologies de linformation et de communication par la mise en place dun systme de gouvernance favorisant lanticipation et la vision prospective ; Mettre en place une architecture technologique prenne, volutive et scurise, garantissant une qualit de service optimale, et permettant la matrise des cots de possession (investissements et fonctionnement) du systme dinformation.
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

de la DB tel que le dveloppement logiciel qui prsente un support d'accompagnement de la DB dans sa gestion budgtaire. En consquence, il doit y avoir un rfrentiel des procdures mtiers relatif au dveloppement logiciel au sein de la Direction du Budget, ce rfrentiel de bonnes pratiques permettra la mise en place d'un plan d'assurance qualit par le rapprochement de la structure et moyens de la DSI aux normes et standards internationaux. Ainsi lobjectif de ce travail est de proposer la DB un rfrentiel des bonnes pratiques de dveloppement logiciel. La dmarche de llaboration de ce rfrentiel sest tale sur plusieurs tapes : Nous avons men une enqute auprs des cadres et responsables de la DSI afin de confirmer le diagnostic de ltude de lexistant ralise dans le cadre de llaboration du SDI de la DB. Nous avons utilis pour cette tape un questionnaire qui nous a permis de recenser lorganisation et les mthodes du travail au sein de la DSI, les diffrentes activits de lquipe informatique de la DB, les difficults rencontres et les perspectives damlioration ; Nous avons men des entretiens avec les responsables de la DSI de la DB, principalement avec le chef de la DSI, le chef du Service de dveloppement des systmes mtiers et le chef du Service de larchitecture du systme dinformation. Ces entretiens ont t trs avantageux, leur intrt sinscrit dans lencadrement, la direction du travail et la validation des solutions proposes ; Nous avons programm des sances de travail avec les cadres de la DSI afin de recueillir leurs propositions et leurs recommandations au sujet de llaboration du futur guide mthodologique de dveloppement logiciel ; Nous avons effectu une tude documentaire de diffrentes mthodes, normes et standards de dveloppement logiciel, cette tude nous a permis de parcourir et d'tudier les recherches scientifiques et acadmiques qui ont t ralises dans ce domaine ; Nous avons ralis une enqute sur les activits de dveloppement au sein des structures informatiques marocaines, pour cela nous avons labor un questionnaire pour recenser les bonnes pratiques et les expriences russies en matire de dveloppement logiciel, que a soit au niveau du secteur public ou priv. Ltude des diffrentes pratiques mises en uvre par les chefs de projet dans leurs processus de dveloppement logiciel nous a permis de dcouvrir certaines bonnes pratiques susceptibles dtre adaptes la DB ;
24
CHAPITRE II : PROCESSUS DE DEVELOPPEMENT LOGICIEL DE LA DIRECTION DU BUDGET
Chapitre 2 Processus de dveloppement logiciel de la Direction du Budget
25

Le systme d'information de la Direction du Budget dessert l'ensemble des services de cette direction. Son processus de dveloppement logiciel volue constamment avec ses besoins. Par consquent, le dveloppement interne des applications informatiques s'impose vu les spcificits du mtier de la Direction du Budget qui ne cessent d'voluer avec toutes les rformes budgtaires qui amliorent la performance et le contrle du budget marocain. La confidentialit des informations budgtaires exige davantage la production interne du systme d'information de la Direction du Budget. Le prsent chapitre dvoilera dans un premier temps la dmarche du management des projets informatiques de la Direction du Budget, les procdures de dveloppement logiciel et les modes d'exploitation pour une utilisation aise du systme d'information. Par la suite, ce chapitre entamera une tude du processus de dveloppement logiciel au sein de la DB. La mise en surbrillance des bonnes pratiques et l'identification de celles amliorer ou ajouter aux mthodes de dveloppement logiciel de la DB feront l'objet de la conclusion de ce chapitre.
1. Management des projets informatiques

1.1. Dmarche et organisation
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

Ainsi, trois instances, chacune dans son domaine de comptence, ont t constitues pour le pilotage, le suivi de la gestion, le dveloppement et la mise en uvre du projet d'informatisation de la Direction du Budget.
Figure 2-1: Organes mis en place pour le pilotage des projets informatiques
1.1.1. Comit de direction

Le comit de direction reprsente linstance de pilotage, de coordination et dorientation de lensemble des actions dinformatisation. Il est prsid par le directeur et se compose de: Un comit restreint constitu des directeurs adjoints et du responsable informatique ; Un comit largi l'ensemble des chefs de division. Aussi, ce comit de direction peut inviter toute personne, en relation avec l'ordre du jour, pour participer ces runions (des consultants externes, le directeur des affaires administratives et gnrales, le reprsentant du Secrtaire Gnral, ). Dautre part, son rle consiste essentiellement : 27 La dfinition des choix stratgiques ; La dfinition des orientations de gestion ; Lordonnancement des priorits de ralisation ; Lactualisation des plans de dveloppement informatique ; La dfinition des axes de projets ; La validation des travaux des commissions de liaison informatique; Larbitrage.

1.1.2. Commission de Liaison Informatique (CLI)
Cette commission intervient au niveau de chaque projet et sintresse toutes les oprations relatives la mise en place et au suivi de son exploitation durant tout son cycle de vie. Elle est constitue dun noyau dur dinformaticiens et dutilisateurs et peut, tout moment, faire appel dautres comptences internes ou externes pour mener et raliser ses tches. Les principales attributions de cet organe consistent en : La dfinition des orientations de gestion, dorganisation et techniques pour chaque projet ; La planification et l'ordonnancement des travaux ; L'laboration des documents ncessaires la ralisation de lapplicatif : Analyse de lexistant ; Conception du nouveau systme ; Elaboration du cahier des charges ; La validation du nouveau systme informatique ; Le recours aux utilisateurs.
1.1.3. Structure Informatique (DSI)

Cet organe constitue le matre duvre de la mise en place et du pilotage oprationnel de lensemble des oprations lies au dveloppement logiciel de la Direction du Budget. Il assure les ralisations techniques des systmes d'information conformment au cahier des charges labor par la commission de liaison informatique. Il est responsable de la volatilit, de la prennit et de la scurit de son systme d'information, il doit l'entretenir et
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.
Outils de management des projets informatiques
1.2.1. Schma directeur informatique

La diversit des domaines dintervention, lurgence de disposer de moyens modernes de traitement de linformation , la rflexion en commun sur les systmes dinformation potentiels futurs, la rationalisation de lallocation des ressources, loptimisation des procdures et les rgles de gestion, le renforcement des capacits de rflexion, danalyse et de prvision ainsi que lamlioration de la qualit du travail, constituent tant darguments qui ont amen les responsables de la Direction du Budget opter pour le schma directeur informatique (SDI) comme moyen de planification pour la gestion du processus dinformatisation de cette direction.
29

Cette planification a permis dassurer notamment : Ladaptation dune stratgie dinformatisation matrialise par un schma directeur informatique rvisable priodiquement ; La cohrence du dveloppement des diffrentes composantes du systme dinformation avec la stratgie de la direction; La compatibilit entre une conception globale et une ralisation progressive; La hirarchisation des projets informatiques en fonction des impratifs stratgiques et des contraintes organisationnelles et financires; La programmation des moyens mettre en uvre sur les plans matriel, logiciel, organisationnel et humain en fonction dun programme dtaill. La dmarche retenue pour llaboration du schma directeur informatique a t axe sur cinq lments essentiels : La stratgie de la direction en matire dinformatisation ; Loffre de la technologie de traitement de linformation ; Ltat de lenvironnement interne et de lorganisation de la direction ; Ltat de lenvironnement externe (situation des systmes dinformation des partenaires de la direction) ; La participation des comptences internes et externes.
1.2.2. Plan de charges annuel

Le schma directeur informatique constitue le cadre gnral dorientation du processus dinformatisation de la direction moyen terme. Quant au plan prvisionnel annuel, il retrace lensemble des oprations inscrites au schma directeur dont la ralisation est prvue pour lanne considre. Le plan de charges annuel est un instrument de pilotage puisquil permet la programmation, la mobilisation des ressources et le suivi de ltat davancement des diffrentes oprations. Son contenu sarticule autour des axes suivants : 30 La prsentation gnrale des objectifs atteindre ; Le calendrier des oprations programmes ;

Les ressources humaines mobiliser ; Les quipements acqurir ; Les actions de formation assurer ; Les types d'oprations raliser au niveau de chaque projet.
1.2.3. Planification du projet

Chaque projet possde son propre plan daction qui constitue le document essentiel pour la planification de la ralisation du systme informatique correspondant. En effet, partir du schma directeur informatique qui dfinit le cadre dorientation globale du processus dinformatisation, et partir du plan prvisionnel annuel, le plan daction du projet reprend les donnes relatives chaque projet et les dtaille de faon fine pour permettre une meilleure programmation de ses diffrentes composantes et une utilisation rationnelle des ressources mobilises, ceci en vue dassurer un suivi permanent et un contrle rgulier de ltat davancement des ralisations au niveau de chaque projet.
1.2.4. Bilan annuel des ralisations

Pour permettre au comit directeur de suivre lvolution des ralisations inscrites au programme prvisionnel, un document relatif au bilan des ralisations est labor annuellement par la structure charge du systme dinformation. Ce document retrace lvolution de la mise en uvre des diffrentes actions du processus dinformatisation de la Direction du Budget pendant les douze derniers mois. Il a pour objet de faire la synthse du droulement des ralisations et danalyser les carts et les incidents rencontrs. Les informations inscrites dans ce bilan sont des tats agrgs dont les donnes de base proviennent des intervenants oprationnels : les commissions de liaison informatique et les instances de dveloppement, de formation et dexploitation. Le contenu du bilan annuel des ralisations informatiques est ax sur les domaines suivants : Rappel des actions programmes ; Evaluation gnrale des ralisations ; Analyse et comparaison des ralisations par rapport aux prvisions ; Bilan des ralisations relatif chaque projet ;
31

Bilan des actions daccompagnement (formation, assistance, maintenance) ; Synthse et analyse des incidents rencontrs ; Recommandations ; Plan d'actions de l'anne suivante. En plus de sa mission primordiale dans lactualisation du schma directeur informatique, le bilan annuel des ralisations joue un rle important dans le pilotage du processus dinformatisation, puisquil permet aux dcideurs de connatre ltat rel davancement des ralisations par rapport aux prvisions et dagir en consquence.
2. Dveloppement de l'applicatif informatique

La Direction du Budget a opt pour le dveloppement de son systme d'information avec les ressources internes de la DB, et ce pour garantir sa prennit, rduire ses cots de dveloppement et d'exploitation et permettre, notamment, son dploiement auprs des partenaires sans investissement supplmentaire. Le dveloppement logiciel la Direction du Budget inspire ses mthodes d'une approche traditionnelle base sur le modle par prototypage. La phase de dveloppement
prend en charge la ralisation du logiciel. Elle prcise les besoins, ralise le produit et valide son fonctionnement.
La figure 2-3 prsente le diagramme d'activits illustrant le processus de dveloppement logiciel au sein de la Direction du Budget.
32
Figure 2-3: Diagramme d'activits illustrant le processus de dveloppement logiciel la DB
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.
Spcification de l'architecture du systme d'information
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
Figure 2-4 : Architecture de dveloppement du systme d'information la DB
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
CHAPITRE II : PROCESSUS DE DEVELOPPEMENT LOGICIEL DE LA DIRECTION DU BUDGET 2.4. Dveloppement
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
Java Enterprise Edition
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

Les tests fonctionnels sont raliss par des utilisateurs nomms "utilisateurs pilotes", cette tiquette drive de l'action pilote de mise en exploitation du nouveau systme au profit d'un chantillon d'utilisateurs choisis pour leur expertise du mtier informatis. Ces derniers utilisent le nouveau systme et gardent leurs anciens outils afin de tester la conformit des rsultats obtenus par les deux outils. Cette mthode offre aux utilisateurs "pilote" l'avantage de se familiariser avec le nouveau systme et leur permet de valider les fonctionnalits de ce systme et de spcifier, le cas chant, les fonctionnalits manquantes.
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. Analyse du processus de dveloppement logiciel de la DB

Llaboration dun rfrentiel des bonnes pratiques de dveloppement logiciel la DB doit tre prcde par ltude dtaille des besoins de lquipe du dveloppement logiciel. Ainsi, et en vue de clarifier davantage lesdits besoins, nous avons men une enqute afin dtudier lorganisation et les mthodes du travail au sein de la DSI, les diffrentes activits de lquipe informatique de la DB, et les perspectives damlioration. Lobjectif de cette enqute est de confirmer le diagnostic tabli dans le cadre de llaboration du SDI de la DB. En fait, elle permettra didentifier les causes majeures des diffrentes difficults rencontres lors du dveloppement logiciel la DB et de justifier la ncessit de la mise en place dun rfrentiel des bonnes pratiques de dveloppement logiciel. Cette enqute sadresse lquipe informatique de la DB, des entretiens ont t tenus avec les responsables de la DSI et un questionnaire a t distribu lensemble des cadres et responsables de la DSI, ce questionnaire porte sur six parties (cf. annexe I). La premire partie recueille des informations sur les profils des cadres de la DSI, la seconde partie comporte des questions relatives lenvironnement du travail de lquipe informatique, la troisime partie sinterroge sur les activits des dveloppeurs logiciel, la quatrime partie examine lorganisation de la DSI et ses mthodes de travail, la cinquime partie recense certaines difficults rencontres par lquipe de dveloppement logiciel lors de lexcution de ses activits. Enfin, la dernire partie dtermine la motivation de lquipe informatique llaboration dun nouveau rfrentiel des bonnes pratiques de dveloppement logiciel et recueille leurs perspectives du changement et damlioration.
3.1.
Prsentation et analyse des rsultats de lenqute
3.1.1. Environnement de lenqute

La distribution et la collecte du questionnaire ont t manuelles. Le personnel de la DSI a contribu volontairement la rponse au questionnaire. Le taux de rponse a atteint 80% pour lensemble des cadres de la DSI (cf. tableau 2-1 & figure 2-5).
Nombre des rponses 11 7 1 4 1 24 Effectif des cadres 11 7 7 4 1 30 % rponse 100,00% 100,00% 14,29% 100,00% 100,00% 80,00% Figure 2-5: Rpartition des rpondants par structure
Structure SDSM SASI SES SDC DSI TOTAL
Tableau 2-1: Rpartition des rpondants par structure
38

3.1.2. Profils des rpondants
Le graphique ci-dessous dmontre que 54% des cadres pratiquent lactivit du dveloppement logiciel contre 9% qui font le mtier de la conception (cf. figure 2-6). Le mtier du dveloppement occupe une place importante parmi les autres mtiers de production logicielle au sein de la DSI.
Figure 2-6: Rpartition des mtiers de la DSI au sein de la DB
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-7: Rpartition des profils des cadres de la DSI au sein de la DB
Figure 2-8: Anciennet des cadres de la DSI au sein de la DB
3.1.3. Environnement de travail

Les interrogations de cette section du questionnaire nous informent sur lenvironnement du travail de lquipe de dveloppement logiciel. La figure 2-9 fait ressortir 39

que 62% des cadres de la DSI participent de deux quatre projets en parallle. 13% des rpondants travaillent sur plusieurs projets (plus de 4), ils reprsentent les responsables de la DSI.
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).
Figure 2-10: Dure moyenne des projets informatiques de la DB
Figure 2-11: Taille des quipes informatiques de la DB
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.
3.1.4. Activits des rpondants

Cette section du questionnaire est trs importante puisquelle dfinit les diffrentes interventions des cadres de la DSI dans le processus de production du systme dinformation. Sagissant des phases relatives aux dveloppements des SI, les cadres participent, gnralement, la phase du dveloppement et des tests (80% des rpondants), ltude de lexistant (58%), lanalyse et conception (58%), ainsi quau dploiement (54%) (cf. figure
40

2-12). Nous concluons que les cadres de la DSI participent toutes les tapes du cycle de vie de la production logiciel.
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
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.
3.1.5. Mthodes et organisation

Dans cette section, nous prsentons les rsultats de la quatrime partie du questionnaire portant sur la mthodologie de gestion de projet informatique de la DB et les mthodes de travail et de planification. Prs de 70% des cadres ayant rpondu ce questionnaire considrent que de la DSI sorganise en mode projet (cf. figure 2-15) et 88% des rponses confirment que la DSI a sa propre mthodologie de gestion de projet (cf. figure 2-16).
Figure 2-15 : Organisation des projets informatiques de la DB
Figure 2-16 : Mthodologie de gestion de projet informatique de la DB
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

Concernant la question sur les normes et standards utiliss dans le processus dinformatisation de la DB, plus de 54% des rponses estiment que la DSI nutilise aucune norme standard ou rfrentiel dans le management de ses activits, 42% jugent que la DSI utilise son propre rfrentiel. Aucun des cadres rpondants na cit lutilisation des normes ISO, CMMi ou SPiCE (cf. figure 2-18).
Figure 2-17 : Mthodes de dveloppement informatiques de la DB
Figure 2-18 : Normes et standards de gestion de projets informatiques de la DB
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

Parmi les rponses collectes, la majorit (79%) nutilise aucune technique de planification de projet informatique (cf. figure 2-20). 50% des rpondants nont jamais effectu des analyses post-projet, 29% des cadres de la DSI font des analyses post-projet afin damliorer la qualit de leur activit et 21% le font pour capitaliser sur leurs expriences (cf. figure 2-21).
Figure 2-20: Techniques de planification utilises lors des projets informatiques de la DB
Figure 2-21: Analyses Post-projet informatique de la DB
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.
3.1.6. Difficults rencontres

Pour recenser les difficults rencontres lors du processus de dveloppement logiciel la DB, cette section porte des interrogations sur la russite des projets informatiques, les raisons dchec, et les domaines les plus difficiles matriser par lquipe informatique de la DB. Pour la population ayant rpondu cette section, 47% affirment que les projets dont ils participent connaissent un peu dchec, contre 28% qui affirment que leurs projets ne connaissent pas beaucoup dchecs, 10% des rponses affirment la russite de leurs projets de dveloppement logiciel et 10% tmoignent lchec de leurs projets (cf. figure 2-22).
44
Figure 2-22: Taux des checs des projets informatiques de la DB
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).
Figure 2-23 : Raisons dchecs de certains projets informatiques de la DB
Figure 2-24 : Difficults rencontres au processus de dveloppement logiciel de la DB
45

Si certains projets informatiques de la DB connaissent quelques difficults, cela est d principalement au changement continu des spcifications fonctionnelles des utilisateurs. La communication interrompue avec le matre douvrage impacte la conformit des cahiers des charges labors aux besoins fonctionnels rels, ce qui conduit la production des applications non adquates aux besoins des utilisateurs.
3.1.7. Perspectives damlioration

Cette partie du questionnaire revt une grande importance quant aux besoins rels des cadres de la DSI, que ce soit la formation continue, la motivation de lquipe informatique pour llaboration dun nouveau rfrentiel des bonnes pratiques de dveloppement logiciel ou les perspectives du changement et damlioration. A la question Si vous pouviez amliorer une seule chose, Que voudriez-vous
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)
Figure 2-25 : Domaines damlioration prfrs par les cadres informaticiens de la DB
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
Figure 2-26 : Dmarches de changement prfres par les cadres informaticiens de la DB
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).
Figure 2-27 : Domaines de formation prfrs par les cadres informaticiens de la DB
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
Figure 2-28: Prfrence de formation des cadres informaticiens de la DB en normes de certification
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).
Figure 2-29 : Prfrence de formation des cadres informaticiens de la DB en mthodes agiles
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
CHAPITRE II : PROCESSUS DE DEVELOPPEMENT LOGICIEL DE LA DIRECTION DU BUDGET 3.2. Synthse de ltude
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.
3.2.1. Points forts du processus de dveloppement logiciel

Les informations collectes de lenqute expriment les avis des rpondeurs, cependant lanalyse de ces informations savre trs importante. En effet, on essaiera de les projeter sur le processus de dveloppement logiciel dcrit prcdemment pour dcortiquer les points forts dans les pratiques du dveloppement logiciel de la DB. Comme nous l'avons cit au dbut de ce chapitre, la Direction du Budget a fait son choix stratgique de produire son systme dinformation en interne, ce qui explique le nombre lev des dveloppeurs au sein de la DSI. Les dveloppeurs de la DSI, sont gnralement des laurats des grandes coles d'ingnieurs ou ayant des diplmes universitaires suprieurs, leur anciennet au sein de la DB leur a permis de bien connatre les diffrents processus mtiers de la direction. Par consquent, mme si la communication avec le matre d'ouvrage demeure insuffisante, l'expertise de l'quipe informatique de la Direction du Budget leur permet de bien dfinir les objectifs des projets informatiques. La taille des projets informatiques initis au sein de la DB est moyenne, ces projets sont matrisables, en plus, la taille de l'quipe des dveloppeurs est aussi moyenne, cette quipe est socialement bien soude, et professionnellement a l'expertise et la comptence technique utiles l'exercice de ses fonctions. Comme nous l'avons dj dcrit dans la premire section de ce chapitre, la DB dispose de ses propres moyens pour grer ses projets informatiques. L'organisation de management des projets informatiques permet aux dcideurs de la direction d'avoir une vision claire sur le droulement de ces projets.
49

Les documents techniques accompagnant la production du logiciel de la DB ont un formalisme standard. Les dveloppeurs assurent l'laboration du manuel de formation et la formation des utilisateurs finaux sur leur nouveau produit logiciel. Ces sessions de formation permettent aux dveloppeurs de recueillir les remarques sur le nouveau logiciel et de s'assurer de la conformit du produit aux besoins fonctionnels.
3.2.2. Points d'amlioration au processus du dveloppement logiciel

L'examen du processus de dveloppement logiciel de la DB et la synthse de l'enqute nous ont permis d'identifier certains axes o la DSI est appele apporter des amliorations. La majorit des rpondants au questionnaire a affirm qu'elle n'utilise ni une technique de planification de projet, ni des analyses post-projet, ceci soutient l'hypothse que les cadres ne participent ni la planification de leurs projets informatiques, ni aux analyses post-projet qui se font au niveau management. Nous recommandons ainsi leur participation ces deux phases de dveloppement logiciel, ce qui les engagerait au respect des dlais de livraison et de la qualit des logiciels produits. Les dveloppeurs de la DB participent plusieurs projets en parallle, ils assurent aussi la formation du nouveau logiciel produit, l'assistance des utilisateurs dans leurs activits informatises occupe un temps colossal des dveloppeurs. La charge des cadres de la DSI est normment leve notamment en priode de prparation du projet de la loi de finances. La prise en considration des ressources dployes dans l'assistance des utilisateurs permettrait de bien estimer les dlais de ralisation du nouveau logiciel produit. Rappelons que la mthodologie de gestion de projet informatique la DB nest pas aligne avec les meilleures pratiques [DELOITTE 2008]. Les projets ne sont pas systmatiquement conduits en partenariat avec les divisions mtiers sur toutes les phases de leur cycle de vie, certains projets ne disposent pas dune expression de besoins formalise et les divisions mtiers ne sont consultes quen amont du projet et lors de la formation au produit, elles ne sont pas impliques dans le pilotage des projets. Les tests au sein de la DB ne suivent aucun formalisme, le dveloppeur teste son propre code, le test technique intgral est effectu par le chef de projet. Les tests fonctionnels n'existent pas ou ils sont remplacs par l'action "pilote" de dploiement, comme on l'a dcrit
50

prcdemment dans ce chapitre, les utilisateurs "pilote" effectuent eux mme les tests fonctionnels lors de leur premire dcouverte du nouveau SI. Il est recommand d'avoir une quipe de test indpendante de l'quipe de dveloppement, l'externalisation des tests vers un organisme tiers peut tre une bonne solution, mais ceci reste une opration coteuse, on suggre alors que les tests soient effectus par un autre dveloppeur. L'industrialisation des tests est une tape primordiale dans le cycle de vie des applications informatiques, plusieurs outils de test sont prsents sur le march informatique, il faut noter aussi que les mthodes agiles et les rfrentiels d'amlioration des processus tel que CMMi ou SPiCE, mettent les tests au cur du processus de dveloppement. Le processus de gestion des changements nest pas formalis. Les cadres de la DSI ont affirm lors du questionnaire que le cycle du dveloppement logiciel souffre souvent du changement continu des besoins fonctionnels. Les nouvelles fonctionnalits sont directement intgres dans le code informatique sans aucun suivi des changements. La planification initiale du projet n'est pas respecte puisque les dlais de ralisation des nouvelles spcifications n'ont pas t pris en compte. Il est rappeler que le quatrime manifeste agile opte pour l'acceptation du changement plutt que la conformit aux plans. Les projets sont raliss sans vritable matrise douvrage agissant en interface entre les divisions mtiers et la DSI. La communication avec le matre d'ouvrage est parmi les difficults recenses lors du notre enqute, le temps consacr par les divisions mtiers de la DB aux runions de la commission de liaison informatique reste insuffisant, ces runions sont courtes cause de l'engagement des divisions mtiers lexercice de leurs fonctions. Il est noter que le troisime manifeste agile opte pour la collaboration avec le client plutt que
la contractualisation des relations. La formalisation de la gestion des risques dans le processus de dveloppement logiciel au sein de la DB est inexistante, lexpertise et le bon sens des cadres de la DSI leur permettent dviter certains risques rcurrents. Toutefois, le niveau III du Rfrentiel CMMi comprend le domaine de processus gestion des risques .
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
CHAPITRE III : METHODES TRADITIONNELLES Vs METHODES AGILES
Chapitre 3 Mthodes traditionnelles Vs mthodes agiles
53

Le gnie logiciel couvre un grand nombre de sujets, dont certains traitent spcifiquement la gestion et le processus de dveloppement. Le gnie logiciel peut se dfinir comme lapplication dune approche systmatique, discipline et quantifiable pour le dveloppement, l'exploitation et la maintenance du logiciel. Il sagit de lapplication du gnie au domaine logiciel. Plus spcifiquement, le cycle de vie du logiciel est lensemble des tapes rencontres par le logiciel au cours de sa cration et de son existence, il couvre son origine, sa cration, son exploitation, et son retrait dans lobjectif dappliquer de meilleures pratiques, tant individuelles
quorganisationnelles
[SWEBOK 2004].
Cest principalement sur la cration du produit que porte
notre attention, afin de mettre en vidence les diffrences entre les approches traditionnelles et celles agiles.
1. Les approches traditionnelles

1.1. Origine du gnie logiciel
la fin des annes 50, linformatique est devenue de plus en plus populaire et sest tendue dautres disciplines. Cet largissement un public non scientifique, a engendr la cration du mtier de programmeur. Lutilisateur exprimait ses besoins et le programmeur ralisait la solution informatique. Ce ft le premier cart qui spara les professionnels de linformatique et les utilisateurs. la fin des annes 60, les grands systmes commerciaux ont dmontr quil tait difficile dadapter grande chelle, les principes jusque l adquats. Les grands projets dpassaient les budgets et les chanciers, ce ft alors the software crisis la crise du logiciel
[GHEZZI 1991].
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].
Une tude sur la rpartition des efforts dmontra quau
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
discipline nomme : gnie logiciel.
54
Figure 3-1 : Rpartition des efforts du dveloppement logiciel [Tir de NATO 1968]
1.2. Les processus de production dans une approche traditionnelle

Un processus est un ensemble d'activits corrles ou interactives qui transforment les lments d'entre en lments de sortie (norme ISO 9001:2000). La dfinition dun processus sert dterminer lordre des tapes et connatre les critres de transition pour passer dune tape lautre. Cette dfinition permet ainsi d'amliorer la qualit du produit et facilite son exploitation.
1.2.1. L'organisation du travail

Dans une approche traditionnelle, le cycle de vie de logiciel passe par quatre grandes phases : linitiation, le dveloppement, le dploiement et lexploitation. Linitiation vise connatre la mission du systme et raliser les travaux exploratoires qui vrifieront la pertinence du projet. Le dveloppement est la phase qui prend en charge la ralisation du logiciel. Elle prcise les besoins, ralise le produit et valide son fonctionnement. Le dploiement rend le produit accessible ses utilisateurs, par la mise en service du logiciel dans son environnement de production. Lexploitation est la priode de vie utile du produit au cours de laquelle des amliorations peuvent tre apportes au produit. Un ensemble dlments est ncessaire un projet conduit par une approche traditionnelle. Le Tableau 3-1 rsume les phases et les principales tches quelles regroupent. 55

Etapes Initiation
Etude de faisabilit Planification du projet
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
Programmation et tests unitaires Intgrations et tests systmes Documentation
Dploiement
Plan de dploiement
Formation
Conversion de donnes
Tests d'acceptation
Vrification posthume
Exploitation
Suivi Oprationnel et support
Maintenance Dcisions rcurrentes: Continuer Refaire Terminer
Tableau 3-1 : Description des tapes du cycle de vie logiciel
56

1.2.2. Les modles du cycle de vie logiciel
Il existe diffrents types de modles de production logiciel appels aussi Cycle de vie logiciel ou cycle de dveloppement . Ils mettent en relief les phases du processus et leur ordonnancement. On cite ci-aprs divers modles proposs:
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].
Le Software Engineering Institut de Carnegie Mellon University
[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].
Il prsente une srie dtapes subsquentes ralises lune aprs
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].
Il met en vidence la ncessit danticiper et de prparer ltape
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

rsultats plus tt dans le processus et d'obtenir de prcieux commentaires des utilisateurs, chaque itration est en fait un processus de mini cascade et chaque phase fournit des informations vitales pour la conception de la prochaine phase [CTG1998].
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.
1.2.3. Les mthodologies de dveloppement logiciel

Une mthode est lapplication concrte dun modle, elle dtaille la dmarche suivre. Au cours des annes 1980, les mthodologies Merise et SADT furent fortement rpandues. Ces approches sparaient les traitements et les donnes, ce qui convenait aux technologies en vigueur au cours de cette priode. Au cours des annes 1990, les langages orients objets, modliss par les diagrammes UML, gagnrent en popularit : Le gabarit de mthode RUP (cf. Chapitre III : section
3.5)
propose un modle itratif bas sur de courtes livraisons [IBM 2010].
1.2.4. Les acteurs dans une approche classique

Les approches traditionnelles spcialisent les tches. Ces tches sont ralises par des individus ayant un rle prcis. Il existe plusieurs titres tels que : chef de projet, architecte, analyste, programmeur, etc. Le programmeur est le principal acteur des projets de dveloppement dans une approche classique. D'autres acteurs s'ajoutent l'quipe de production 58

logiciel, et sont principalement le directeur qui gre les budgets, le pilote du projet qui dtient l'expertise du domaine et l'utilisateur qui exploite le produit. Ce dernier peut tre tiquet par un terme gnrique "Client".
1.3. Limitations des approches traditionnelles

Bien que les approches traditionnelles comportent divers avantages, elles prsentent certaines limites notamment dans les environnements volutifs. En effet, les environnements changeants demandent des adaptations constantes. Avec une planification rigoureuse, il est difficile dapporter des changements cause de leurs impacts, et plus une modification est faite tardivement, plus elle est coteuse. Cette situation de retard requiert de modifier la chane des tapes pralables et seules les modifications les plus importantes seront effectues. Certains projets peuvent requrir moins deffort de gestion. Les suivis et les rapports alourdissent la charge administrative. Les communications crites sont coteuses et longues produire. Il faut tenir compte de lampleur et de la complexit du projet. Si le produit est livr dans un dlai important, il est possible que la situation du client ait volu et que lon soit appel modifier le systme. Lexprience de lquipe peut faire diminuer les risques et contribuer minimiser les exigences de suivi. Les approbations et le manque dautonomie des quipes peuvent ralentir le projet. Une organisation peu hirarchise, ayant une culture collgiale, intgrera difficilement une structure traditionnelle.
2. Les mthodes agiles

2.1. Les bases de l'agilit
2.1.1. Dfinition
Selon B.BOEHM et R.TURNER dans
[BOEHM 2003],
l'agilit peut tre l'quivalent de la
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

Une mthode agile est une approche itrative et incrmentale, qui est mene dans un esprit collaboratif, avec juste ce quil faut de formalisme. Elle gnre un produit de haute qualit tout en prenant en compte lvolution des besoins des clients [ROTA 2008].
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.
Les principes agiles
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

Principe
Notre priorit est de satisfaire le client en lui livrant trs tt et rgulirement des versions oprationnelles de lapplication, source de valeur. Accepter le changement dans les exigences, mme tard dans le cycle de vie, pour garantir la comptitivit du client. Livrer le plus souvent possible des versions oprationnelles de lapplication, une frquence allant de deux semaines deux mois Client et dveloppeurs doivent cooprer quotidiennement tout au long du projet Construire des projets autour dindividus motivs. Leur donner lenvironnement et le support dont ils ont besoin et leur faire confiance pour remplir leur mission. La mthode la plus efficace de communiquer des informations une quipe et au sein de celle-ci reste la conversation en face face. Le fonctionnement de lapplication est le premier indicateur davancement du projet. Les mthodes agiles recommandent que le projet avance un rythme soutenable. Sponsors, dveloppeurs et utilisateurs devraient pouvoir maintenir un rythme constant indfiniment.
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
Porter une attention continue lexcellence technique et la conception, amliore lagilit.
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.
Tableau 3-2: Les principes du manifeste agile [Tir de ROTA 2008] 61


2.1.5. Les concepts de l'interdpendance
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. L'apport de l'approche agile

2.2.1. L'apport agile pour les dveloppeurs
Le premier concept du Manifeste touche directement les individus et les interactions. Au del des outils, il y a les gens. Les dveloppeurs impliqus dans un projet agile doivent tre prts vivre une exprience de groupe. La cohsion de lquipe est au centre du potentiel de russite du projet. Le partage des connaissances techniques des experts et la comprhension gnrale du systme amliorent continuellement les connaissances de l'individu, ce qui est une source de motivation. Litration donne une occasion dapprendre, donc de capitaliser et dadapter les pratiques pour la suite du projet [ROTA 2008].
2.2.2.
L'apport agile pour le produit
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

dvelopp et les besoins mtiers sont rduits au maximum [PORRET 2010]. La qualit du produit est value continuellement.
2.2.3.
L'apport agile pour le client
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.
L'apport agile pour le projet
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.
2.3. Limitations des approches agiles

Dans cette section, on va dcrire quelques situations pour lesquelles l'approche agile ne peut pas tre applique [DAN 2006]: Limitations pour les environnements de dveloppement distribu : Les environnements
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

partie fixe et une partie variable qui dfinit les exigences et les rsultats qui peuvent varier dans les limites dfinies dans la partie fixe. Limitations pour le dveloppement impliquant de grandes quipes: Le nombre des
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. Description de quelques mthodes de dveloppement agiles

3.1. EXtreme Programming (XP)
Extreme Programming (XP) est une mthode agile qui priorise lexcellence technique. Elle comporte un ensemble de pratiques interdpendantes qui demandent beaucoup de rigueur, afin de puiser le maximum defficacit des quipes de dveloppement. Extreme Programming (XP) a t dvelopp par Kent Beck, Ward Cunningham et Ron Jefferies au cours des annes 90. Beck est le principal instigateur de XP [BECK 2010]. Cette mthode a t cre pour rpondre aux changements mergeants de lapprentissage des clients en cours de projet. Elle sadresse principalement aux petites quipes composes de 2 12 personnes, travaillant dans un espace commun. Elle demande une grande implication du client et exige de pouvoir automatiser les tests. Elle augmente la productivit et offre de meilleurs rsultats [BECK 1999]. Elle se distingue avec ses pratiques particulires et ses valeurs.
3.1.1.
Les Valeurs d'Extreme Programming:
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

Le retour d'information (feedback) : Les itrations sont bases sur les retours d'informations du client, permettant une adquation totale entre l'application finale et sa demande. La simplicit : Avec XP, la faon la plus simple d'arriver un rsultat est la meilleure. La meilleure manire de rendre une application extensible est de la garder simple (et donc simple comprendre) et bien conue autant que possible.
3.1.2.
Les pratiques d'Extreme Programming:
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

Livraisons frquentes: pour une bonne gestion des risques il faut faire des livraisons frquentes. Un release permet de rassurer le client et de lui fournir une vision de lvolution du projet. Jeu du planning : le planning game est un processus informel qui planifie une itration. Pendant une premire phase dexploration, le client exprime ses besoins en termes de fonctionnalits sous forme de user stories. Les dveloppeurs estiment le temps de dveloppement de ces user stories (1, 2 ou 3 semaines homme travail), affectent un risque (low, medium, high) chaque user story et dcoupent les longues user stories en scnarios. Dans la deuxime phase dite dengagement, les user stories sont tries par ordre de priorit en (i) Il faut absolument l'avoir, (ii) J'en ai besoin, mais je peux peine en passer, et (iii) Si vous me tordrez le bras, je n'ai pas vraiment besoin. Les user stories sont classes des plus ncessaires avec haut risque aux moins ncessaires avec moins de risque. En fonction de la vlocit de lquipe, le client et les dveloppeurs dcident le nombre de user stories qui seront dveloppes dans la prochaine itration.
Client sur site: Une personne ct client est disponible tout le temps pour aider la comprhension du mtier. Son travail consiste transcrire les besoins en user stories, les classer par ordre de priorit et tablir les tests de recette. Rythme durable: Partant du fait quune quipe surmene ou surcharge est non productive, il est recommand que lquipe ne doive pas faire dheures supplmentaires deux semaines de suite et que chaque dveloppeur ne dpasse pas 40h hebdomadaire.
3.1.3.
Le processus d'Extreme Programming
Les diffrentes tapes du cycle XP sont illustres ci-dessous:
Figure 3-2 : Processus XP au niveau du projet [Tir de XP 2010] 66


Au niveau du projet, les scnarios utilisateurs (user stories) sont les principaux lments qui mnent le projet. Ils sont composs par le client qui exprime ses besoins. Ils fournissent la liste des caractristiques raliser et serviront de rfrence lors des tests dacceptation. Les transitions architecturales (architectural spike) forment les grandes parties du systme qui construiront les mtaphores du projet. Lutilisation de mtaphores aide la communication et permet de regrouper les scnarios ensemble. La planification de la livraison liste les scnarios qui seront raliss au cours des itrations. Cette planification se construit en fonction des priorits du client, des estimations et de la vlocit de lquipe qui prvoit tre en mesure de produire ces scnarii pour cette itration. Lorsque la liste des scnarios raliser est complte, les cycles des itrations pour cette livraison commencent. La dure des itrations doit tre constante. Une dure de deux quatre semaines est conseille. Les tests dacceptation suivent les itrations. Ces tests dordre fonctionnel, comparent les fonctionnalits ralises aux scnarios dcrits pralablement pour en vrifier la conformit. Les problmes soulevs sont alors complts dans une version suivante. Ces conformits sont vrifies par le client.
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

Lorsque la liste est complte, lquipe entre dans la phase de dveloppement. Mme au cours de cette activit, lquipe peut dbusquer de nouveaux scnarios. Cette phase est riche en interaction avec le client. Le cycle dapprentissage sopre naturellement. Chaque correction ou fonctionnalit complte, est intgre tous les jours la dernire version. De cette manire, le produit progresse vers son objectif. Le client peut constater concrtement les efforts de lquipe et voir son systme oprer.
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

SCRUM : Rencontre journalire de lquipe o lavancement et les empchements sont rviss. Il sagit du plus frquent et plus bas niveau de contrle. Rglement des rencontres SCRUM : Protocole des runions quotidiennes pour tre efficaces. Afin de minimiser la logistique, une srie de rgles uniformise la dynamique des rencontres. quipe SCRUM : quipe multidisciplinaire qui travaille sur les lments du sprint. Toutes les personnes (vente, service clientle, etc.) impliques dans le projet sont invites se joindre lquipe.
3.2.1.
Les trois phases de SCRUM
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
Figure 3- 6 : Le cycle de vie SCRUM [Tir de MSG 2010]
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
CHAPITRE III : METHODES TRADITIONNELLES Vs METHODES AGILES 3.3. Crystal Clear
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].
Les proprits de Crystal Clear [COCKBURN 2004]

Des livraisons frquentes. Amlioration de la rflexion. Une communication osmotique. Confiance, libert dexpression et scurit personnelle. Focus sur lobjectif et la disponibilit. Un contact permanent avec les utilisateurs experts. Un environnement de travail appropri pour lautomatisation des tests, la gestion de configuration et les intgrations frquentes.
3.4.
Rapid Application Dveloppement (RAD)
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:
Figure 3-7 : Les Phases de RUP [Tir de VVT 2002]
Initiation : la phase dinitiation a pour objectif dobtenir un consensus de lensemble des
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

Dynamic Software Development Method (DSDM): c'est le fruit du travail dun consortium de socits dsirant utiliser RAD, de faon structure et indpendante, en GrandeBretagne. DSDM adhre aux valeurs et principes du Manifeste, puisque lun de ses reprsentants, Arie Van Bennekum, est lun de ses signataires [ROTA 2008]. Feature Driven Development (FDD): est une mthode de gnie logiciel, conu par Jeff de Luca et influenc par l'approche de Peter Coad de modlisation objet [DZONE 2010]. Cette mthode priorise la gestion des risques, en sappuyant sur de courtes itrations pour donner des fonctionnalits tangibles lutilisateur. Celui-ci est rapidement inform de lavancement, ce qui diminue les risques. Cette mthode ne prescrit pas de pratique de programmation prcise, mais certains rles sont dfinis. FDD est plus un guide quun processus prescrit. Adaptive System Development (ASD): est une mthode agile de dveloppement logiciel cre par Jim Highsmith. Elle est une adaptation du RAD. ASD incarne le principe que ladaptation continue du processus au travail courant est la faon normale de faire. Elle remplace le traditionnel cycle en cascade, avec des sries rptes de cycles de spculation,
collaboration, et apprentissage. Ce cycle dynamique propose un apprentissage continu et une adaptation a l'tat mergent du projet.
74
4. Synthse des diffrences fondamentales entre l'approche traditionnelle et agile

Les approches agiles et traditionnelles convergent et divergent sur diffrents aspects. On prsentera dans le tableau 3-3 les diffrences majeures par thme entre les deux approches [ROTA
2008]:
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
Suivi de lavancement Gestion des risques
Mesure du succs
Respect des engagements initiaux en termes de cots, de budget et de niveau de qualit.
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.
Tableau 3-3 : Diffrences entre approche traditionnelle et approche agile
75
CHAPITRE IV: DEMARCHE QUALITE DANS LES SYSTEMES D'IINFORMATION
Chapitre 4 Dmarche qualit dans les systmes d'information
77

De nos jours, dans un monde de plus en plus concurrentiel, la multiplication des normes est un phnomne qui se gnralise, rpondant un besoin de standardisation de plus en plus important. Les systmes d'information n'chappent pas cette tendance dans la mesure o les normes, les standards, les dmarches et les guides de bonnes pratiques fleurissent. Selon une exprience mene par l'OTAN
[AQAP-2210 2006],
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.
1. Les Origines de la qualit

La qualit, cette notion minemment subjective, peut tre associe aux premires proccupations de l'homme ds son origine, puisqu'elle traduit fondamentalement la recherche de l'adaptation de chaque chose son usage prvu. Au cours des sicles, et sous l'influence des exigences de la concurrence dans des marchs de plus en plus largement ouverts, cette proccupation s'est dveloppe sans cesse. A la fin du XVII sicle, Winslow Taylor a propos une organisation scientifique du travail permettant le rendement maximum. Cette organisation repose sur l'analyse des techniques de production (gestes, rythmes, cadences) et la dfinition des tches. Taylor rencontra une grande efficacit dans la sidrurgie et il formalisa sa mthode dans un livre intitul The Principles of Scientific Management [CHKHI 2004]. Cette mthode est nomme TAYLORISME. Les premires impulsions de la rvolution de la qualit furent donnes en 1931 par le livre fondamental de Walter A SHEWHART sur le contrle statistique de la qualit, sous le titre Economic Control of Quality of Manufactured Product
[MORICE 1953].
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

Plus tard, en 1950 Tokyo, le Dr Edwards DEMING propose une rforme globale du systme organisationnel de production qui recommande une gestion participative de lensemble du personnel de lentreprise (le management qualitatif). En 1959, le dpartement amricain de la dfense publia la premire norme d'assurance qualit (MIL-Q-9858) destination de ses fournisseurs, puis en 1965 lOTAN cra le groupe des Allied Quality Assurance Publications (AQAP). En 1970, une loi fdrale amricaine exige des critres dassurance qualit dans le domaine du nuclaire, lAgence Internationale de lEnergie Atomique dicte un code de bonnes pratiques sur lassurance qualit [DUMORTIER 2010].
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.
2.2. Qualit logicielle

La qualit logicielle est une apprciation globale d'un logiciel, base sur de nombreux indicateurs. La norme [ISO/CEI 9126-1] dfinit 6 groupes d'indicateurs de qualit des logiciels : La capacit fonctionnelle: c'est la capacit qu'ont les fonctionnalits d'un logiciel rpondre aux besoins explicites ou implicites des usagers. La prcision, l'interoprabilit, la conformit aux normes et la scurit en font partie. La facilit d'utilisation: Qui porte sur l'effort ncessaire pour apprendre manipuler le logiciel. En font partie la facilit de comprhension, d'apprentissage et d'exploitation et la robustesse. Une utilisation incorrecte n'entrane pas de dysfonctionnement. La fiabilit: c'est la capacit d'un logiciel de rendre des rsultats corrects quels que soient les conditions d'exploitation. En fait partie la tolrance de pannes, la capacit d'un logiciel de fonctionner mme en tant handicap par la panne d'un composant (logiciel ou matriel).
79

La performance: c'est le rapport entre la quantit de ressources utilises (moyens matriels, temps, personnel), et la quantit de rsultats dlivrs. En font partie le temps de rponse, le dbit et l'extensibilit - capacit maintenir la performance mme en cas d'utilisation intensive. La maintenabilit: Qui porte sur l'effort ncessaire en vue de corriger ou de transformer le logiciel. En fait partie l'extensibilit, c'est--dire le peu d'effort ncessaire pour y ajouter de nouvelles fonctions. La portabilit: c'est l'aptitude d'un logiciel de fonctionner dans un environnement matriel ou logiciel diffrent de son environnement initial, y compris la facilit d'installation et de configuration pour le nouvel environnement. Chaque caractristique contient des sous caractristiques. Il y a 21 sous caractristiques (cf. figure 4-1). Selon
[KAN 2002]
Les diffrents indicateurs sont parfois conflictuels, ou au contraire
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.
Figure 4-1: Caractristiques de la qualit logicielle [Tir de U-ANGERS 2010] 80

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".
2.4. Management de la qualit

La mise en uvre d'un systme de management qualit est indispensable pour diriger avec succs un organisme. La norme [ISO 9000] dfinit un systme de management qualit comme un "Systme de management permettant dorienter et de contrler un organisme en matire de qualit".
2.5. Assurance qualit

Selon la norme [ISO 8402] l'assurance qualit est un "Ensemble des activits prtablies et systmatiques mises en oeuvre dans le cadre du systme qualit, et dmontres en tant que besoin, pour donner la confiance approprie en ce qu'une entit satisfera aux exigences pour la qualit".
2.6. Manuel d'assurance qualit

Daprs la norme [ISO 8402], cest un document nonant la politique qualit et dcrivant le systme qualit de lentreprise. Selon la norme [ISO 9000], le manuel doit : Exister ; Dcrire les procdures du systme qualit (ou y faire rfrence) ;
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
3. Principes de management de la qualit

Le management de la qualit est fond sur huit principes qui sont la base des normes relatives au systme de management des sries [ISO 9000:2000] et [ISO 9000:2008]. Ces 82

principes peuvent tre utiliss par la direction pour servir de cadre l'amlioration des performances de l'organisme. Les huit principes de management de la qualit sont dfinis dans [ISO 9000:2005], Systmes de management de la qualit Principes essentiels et vocabulaire et dans [ISO 9004:2000] Systmes de management de la qualit Lignes directrices pour l'amlioration des performances [ORG-ISO 2010] [CARLIER 2006]: Principe 1: Orientation client La satisfaction des clients est la base mme de tout systme de management de la qualit. L'coute et la comprhension de leurs besoins, prsents et futurs est indispensable pour satisfaire leurs exigences et d'aller au-devant de leurs attentes. L'orientation client se traduit par la mise en place d'un vritable processus de communication avec eux, une analyse prospective de leur besoin, une valuation rgulire de leur niveau de satisfaction et le traitement de leurs rclamations. Principe 2: Leadership Dans tout systme de management de la qualit, la direction doit dterminer clairement ses orientations stratgiques et crer les conditions pour que le personnel puisse pleinement s'impliquer. Pour cela elle doit montrer l'exemple et son rel engagement, dfinir des objectifs motivants et crer des valeurs partages. Principe 3: Implication du personnel Le personnel est le cur mme d'une entreprise et donc l'un des maillons principal pour tout systme de management de la qualit. Son implication est indispensable pour qu'une entreprise puisse progresser. Il est important de faire comprendre chacun son rle et son importance, de les responsabiliser. Principe 4: Approche processus Tout systme de management de la qualit ncessite une approche processus. Celle-ci consiste, entre autre, dterminer les processus de l'entreprise, leurs interactions et des critres de surveillance. Sur cette base, il sera possible de piloter chaque processus, d'analyser leurs performances, de faire des propositions d'amlioration et de les mettre en oeuvre afin de contribuer aux objectifs stratgiques de l'entreprise. Principe 5: Management par approche systme Comprendre et grer l'entreprise comme un systme de processus interdpendants en vue d'un objectif donn permet d'amliorer son efficacit et son efficience. Ce principe permet de
83

clarifier le fonctionnement de l'entreprise, de mettre jour et de supprimer les activits "doublons" et les zones d'ombres qui sont souvent source de dysfonctionnements. Principe 6: Amlioration continue L'amlioration continue d'un systme de management de la qualit consiste augmenter la performance interne et la satisfaction des clients. Cela comprend, entre autre : analyse des rsultats pour identifier les pistes d'amlioration, tablissement des objectifs, recherche et mise en oeuvre des actions d'amlioration, valuation des rsultats, formalisation des changements.
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
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.
4.1. Les normes de standardisation ISO 9000

Une normalisation est une activit propre tablir, face des problmes rels ou potentiels, des dispositions destines un usage commun et rpt, visant l'obtention du degr optimal d'ordre dans un contexte donn, Ces dispositions sont consignes dans des documents de rfrence appels NORMES. La normalisation s'appuie sur les organismes europens et internationaux, on peut citer: ISO CEI UIT CEN ETSI AFNOR : International Organization for Standardization. : Commission Electrotechnique Internationale. : Union Internationale des tlcommunications. : Comit Europen de Normalisation. : European Telecommunications Standards Institute. : Association Franaise de Normalisation.
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;
ISO 19011:2002 Audits des systmes de management de la qualit et de
4.1.1.
La norme ISO 9000:2005
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

4.1.2. La norme ISO 9001:2008
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

4.1.3. La norme ISO 9004:2009
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 gestion documentaire du systme d'assurance qualit
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

4.1.5. La certification
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
Figure 4-3: Historique des CMM [Tir de SEI 2008_1]
4.2.2.
Les niveaux de maturit CMMi
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

Niveau 2: Reproductible. Ce niveau de capacit de dveloppement implique notamment le suivi des cots, des dlais et des fonctionnalits du projet. Il est donc possible de reproduire un scnario antrieur satisfaisant. Niveau 3: Dfini. A ce niveau, le projet dispose d'un processus clairement dfini, document et standardis. L'ensemble du dveloppement consiste appliquer des processus standard. Niveau 4: Matris. Ce niveau correspond la gestion quantitative du processus et des produits. Niveau 5: Optimis. A ce niveau, les informations quantitatives servent grer le processus logiciel et amliorer constamment.
4.2.3.
Architecture du modle CMMi
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
Analyse causale et rsolution (CAR)
Gestion de projet quantitative (QPM)
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)
Tableau 4-1: Les domaines du processus du CMMi
91

Chacun des domaines de processus est dcrit par des pratiques cls qui contribuent satisfaire les objectifs de ce domaine de processus. Les pratiques cls sont rparties en cinq caractristiques communes: Engagement de ralisation : on y retrouve les pratiques qui confirment la volont ferme et explicite de lorganisation de mettre en oeuvre ce qui est requis pour atteindre les objectifs du secteur cl; Capacit de ralisation : y sont dcrites les pratiques qui illustrent que lorganisation prend effectivement les moyens pour pouvoir respecter ses engagements (budget, affectation des ressources, formation...); Activit ralise : cette catgorie contient les pratiques spcifiques la mise en oeuvre en Mesures et analyse : les pratiques qui dcrivent comment on peut constater la progression rapport avec le secteur cl; des activits inhrentes au secteur cl ou quantifier des caractristiques importantes des produits de ces activits; Vrification de mise en oeuvre : cette dernire catgorie regroupe les pratiques qui dcrivent comment lorganisation sassure que les choses se font conformment aux engagements et aux directives.
4.2.4.
l'entreprise:
Les audits de certifications
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].
Une structure internationale a t cre pour assurer la coordination
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.
Origines de la dmarche SPiCE
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.
Figure 4-4: Relations entre diffrents rfrentiels [Tir de CARLIER 2006]
4.3.2.
les niveaux d'amlioration de la dmarche SPiCE/ISO15504

[CARLIER
La dmarche SPiCE fournit un cadre d'amlioration de processus de six niveaux

2006]:
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

Niveau 1 - Ralis: Les objectifs du processus sont atteints, les pratiques de base sont employes, les produits en fournissent la preuve. Le processus est gr au niveau de l'individu. Pertinence par rapport aux objectifs de l'entreprise. Niveau 2 Gr: Les produits sont vrifis et conformes aux standards. La planification s'effectue au niveau projet et est respecte, aussi bien au niveau du processus lui-mme que des produits issus du processus. Niveau 3 Etabli: Les activits s'effectuent suivant un processus standard dfini au niveau de l'organisation. Le processus est bas sur des pratiques documentes standard adaptes aux besoins de chacun. Niveau 4 Prvisible: Le droulement du processus et de la qualit des produits sont quantifis et les performances sont prvisibles. Obtention dun niveau de qualit prdfini, Niveau 5 En Optimisation: L'organisation est capable d'amliorer de faon continue ses processus pour les adapter suivant les objectifs. Soutien de lamlioration de la productivit.
4.3.3.
Architecture de la dmarche SPiCE
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

Catgorie Zone de processus ClientCUS
fournisseur Ingnierie
Nombre Nombre processus pratiques

8 39
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.
4.4. La dmarche ITIL

La dmarche ITIL (Information Technology Infrastructure Library), littralement bibliothque dinfrastructure des technologies de linformation ou encore bibliothque dinfrastructure IT, est un rfrentiel des bonnes pratiques de gestion des services informatiques. Ainsi elle permet [CARLIER 2006]: Aligner les objectifs des systmes d'information avec les besoins des mtiers et des clients. Optimiser les ressources informatiques. Amliorer la qualit des services rendus, formaliser les objectifs et les rgles de gestion dans un rfrentiel. Matriser l'ensemble des cots. Conu dans les annes 1980 par lagence centrale des tlcommunications de GrandeBretagne (CCTA), afin damliorer la qualit des services informatiques des administrations britanniques et de professionnaliser les relations entre celles-ci et leurs prestataires, ITIL sinscrit dans une dmarche de qualit et de gouvernance SI. Pour les entreprises, entreprendre une telle dmarche, cest manifester une volont de transformer la DSI (Direction des systmes d'information) en centre de services afin damliorer leur relation avec les clients internes. 95

Structure du processus ITIL
ITIL se dcompose en neuf domaines, correspondant neuf livres, permettant de couvrir l'ensemble des problmatiques couvertes par les DSI:

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.
Service Support Service Delivery
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
Tableau 4-3: Les Processus des deux principaux domaines d'ITIL
5. Limitations d'une dmarche qualit
96

La mise en place d'une dmarche qualit nest pas une tape facile. Elle ne doit pas tre perue comme un but en soi, mais elle doit sintgrer dans une logique de rentabilit et dvolution des mthodes de management. Une dmarche qualit peut prsenter les limites suivantes : Le cot lev de la mise en place. La certification entrane un cot important (conseil extrieur, dveloppement de la fonction qualit, instrumentation, certification proprement dite) et la rentabilit de lopration nest pas toujours vidente. La certification de la qualit augmente les barrires lentre pour les petites structures qui ne peuvent en supporter le cot. Ainsi, la dualisation des marchs, entre les diffrents soustraitants, hirarchise les relations entre les entreprises et rigidifie les structures concurrentielles. Un ventuel retour vers le taylorisme La formalisation lextrme pourrait nuire la prise dinitiative du personnel de lentreprise et engendrer un retour aux tches parcellaires. La profusion de documents et procdures risquerait d'entraner une organisation fige selon un mode bureaucratique.
6. Gestion de projet: le guide PMBOK

PMBOK (Project Management Body of Knowledge) est un standard de fait internationalement reconnu (IEEE, norme ANSI) qui traite de l'application des connaissances, des qualifications, des outils, et des techniques pour rpondre aux exigences des projets. Le guide du PMBOK dfinit un cycle de vie du management de projet, 5 groupes de processus et 9 domaines de Connaissance de la profession du management de projet [PMBOK 2000]. Une quipe de projet intervient dans 9 domaines de connaissances travers un certain nombre de processus de base comme rcapitul ci-dessous : Intgration: Dvelopper la charte du projet, la formulation du primtre et du Plan. Diriger, Grer, Suivre, Contrler et Piloter les changements du projet. Contenu: Planification, Dfinition, Structure de Dcomposition du Travail (WBS)1, Cration, Vrification et Contrle. Dlais: Dfinition, Ordonnancement, Estimation de la Dure des tches et des Ressources, Dveloppement et Contrle de la planification. Cot: Planification des Ressources, Estimation des Cots, Budgtisation et Contrle.
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

Qualit: Planification de la Qualit, Assurance Qualit et Contrle Qualit. Ressources Humaines: Planification des RH, Recrutement, Dveloppement et Gestion de l'quipe projet. Communications: Plan de Communications, Diffusion de l'information, Rapport d'activit et de Performance, Gestion des partenaires. Risques: Prvision et identification des Risques, Analyse des Risques (mthodes qualitative et quantitative), Prvision des Actions Correctrices et Surveillance et Contrle des Risques. Approvisionnement: Plan d'Acquisition et de Contractualisation, Rponses et Choix des Soumissionnaires, Administration et clture des contrats.
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.
Cycles de vie d'un projet dans le PMBOK
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

Autoriser le projet Engager l'organisation dans un projet ou une phase Ajuster l'orientation globale Dfinir les objectifs majeurs du projet Arrter les approbations et les ressources ncessaires Valider l'alignement avec des objectifs globaux Affecter le chef de projet Grer l'intgration Dfinissez le primtre de projet Raffinez les objectifs de projet Dfinir tous les livrables requis Crer un rfrentiel pour la planification du projet Fournir un forum pour le partage des informations avec les membres de l'quipe et les partenaires Dfinissez toutes les activits requises Ordonnancez toutes les activits Identifiez les qualifications et les ressources requises Estimez l'effort de travail Analyser les Risques et les actions de contournement Dfinissez et estimez tous les cots requis Obtenir l'approbation du financement du projet Planifier la communication Coordonner les ressources, le dveloppement de l'quipe Garantir la Qualit Choisir et approcher les sous-traitants Diffuser l'information Elaborer le plan du projet
Ralisation Contrler et Piloter Clture
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

Le chef de projet est responsable des objectifs du projet pour livrer le produit final pralablement dfini, dans les contraintes du primtre, de temps, de cot et de qualit requise du projet.
Figure 4-5: Les cinq processus du Management du Projet dans PMBOK [Tir de PMBOK 2000]
6.3.

Avantages et inconvnients du PMBOK

Avantages PMBOK:
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
7. Conformit de l'approche agile aux dmarches qualit

Les dmarches qualit se caractrisent par la prvisibilit ou la rptitivit, ce qui diffre des approches agiles, mais elles ne sont pas ncessairement incompatibles. L'adaptation d'une mthode agile, pour une dmarche qualit, demande souvent de compromettre un peu son agilit
[COCKBURN 2004].
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].
Nous retrouvons parmi les approches agiles les mmes
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].
Le cycle de vie itratif, ou les mthodes de travail
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
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
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.
2. Dfinition des mesures du Benchmarking

Le dveloppement logiciel est plus rtif la mesure et la comparaison par rapport dautres activits dans le domaine des technologies de linformation
[CIGREF 1999].
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
4. Collection des donnes de la cible du Benchmarking

4.1. Prsentation de l'enqute
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.
Dmarche et enjeux de l'enqute
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
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
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
Tableau 5-1 : Liste des dpartements participants l'enqute 108

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).
Figure 5-3 : Fonctions des rpondants
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%
De 10 personnes 20 Plus que 20 personnes
Figure 5-4 : Rpartition des tailles des DSI 109

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%
Figure 5-5 : Nombre d'utilisateurs du systme d'information
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
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
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.
Dmarrage du projet informatique
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).
Figure 5-10 : Clart des objectifs des projets informatiques
112
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).
Figure 5-12 : Dlai de ralisation des projets informatiques 113

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.
Figure 5-13 : Planification des projets informatiques
5.5.
Management du projet informatique
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
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
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).
Figure 5-17 : Mthodologie de gestion de projet informatique
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
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
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
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
Figure 5-24 : Mode des livraisons des projets informatiques
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
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).
Figure 5-27 : Utilisation des dmarches structures dans les tests
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
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).
Figure 5-29 : Niveaux de la documentation des projets informatiques
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
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).
Figure 5-31 : Degr de satisfaction du matre d'ouvrage de la qualit du produit logiciel
5.8.
Conclusion des rpondants
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
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.
Figure 5-33 : Niveaux de la russite du projet informatique
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
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].
Valtech est une socit mondiale de conseil et de services informatiques 1
125
CHAPITRE V : BENCHMARKING APEC

APEC est une socit de recrutement en France. Au dbut de l'an 2009, APEC a choisi les mthodes agiles pour le dveloppement de ses logiciels. La DSI d'APEC n'a pas choisi une mthode en particulier, elle a puis les avantages de plusieurs mthodes (Scrum, XP, Lean, etc.). En revanche, elle a conserv la mthode traditionnelle en cascade pour la gouvernance du projet et sa rception. Les rsultats satisfaisants ont amen APEC gnraliser les mthodes agiles en interne et pratiquer l'agilit de faon assidue. A ce titre, APEC a fait appel l'expertise de Valtech pour auditer ses outils et ses mthodes [LMI 2010].
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
CHAPITRE VI : REFERENTIEL DES BONNES PRATIQUES DE DEVELOPPEMENT LOGICIEL DE LA DB
Chapitre 6 Rfrentiel des bonnes pratiques de dveloppement logiciel de la Direction du Budget
127

Conduire un projet revient prendre les mesures ncessaires pour atteindre les objectifs escompts, savoir dvelopper et livrer un produit de qualit, en matrisant les ressources et les dlais. L'approche privilgier est l'anticipation plutt que le contrle posteriori (en particulier pour pouvoir s'adapter aux invitables modifications de l'environnement du projet). La conduite de projet est un processus difficile matriser car plusieurs facteurs de risques interviennent tels que les cots et les dlais respecter, les technologies matriser, les ressources humaines grer. Par ailleurs, le dveloppement d'un systme d'information est soumis aux exigences accrues des utilisateurs, des contraintes de prennit et l'volution des technologies informatiques. Pour rduire ces risques, il est ncessaire de dfinir les principes de base, communs l'ensemble des projets afin de clarifier la terminologie, de coordonner les intervenants et de veiller la cohrence des diffrentes activits. Une approche mthodologique permet de mettre en place une concertation base sur des principes de fonctionnement clairement tablis et des points de vrification prdfinis. Lobjectif de ce chapitre est de prsenter la mthodologie de l'laboration du guide des bonnes pratiques de dveloppement logiciel, ses objectifs et son contenu.
1. Mthode et outils de travail

Llaboration de la premire version du rfrentiel des bonnes pratiques de dveloppement logiciel de la DB a t le fruit de cette tude, plusieurs outils ont t utiliss dans notre dmarche de llaboration de ce guide. En effet, aprs les entretiens avec les responsables de la DSI la DB, un questionnaire a t labor dans le but de confirmer les besoins de la DB en matire de dveloppement logiciel. Une tude documentaire de diffrentes mthodes, normes et standards de dveloppement logiciel a t ralise afin de parcourir et d'tudier les recherches scientifiques et acadmiques qui ont t effectues dans ce domaine. Le Benchmarking des diffrentes pratiques de dveloppement logiciel dans les structures informatiques marocaines nous a permis de dcouvrir certaines bonnes pratiques
susceptibles dtre adaptes la Direction du Budget. Enfin, une recherche des modles de
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

mensuels de rencontres avec ses clients et elle gre les risques avec des suivis quotidiens. Au niveau de la ralisation technique, cette mthode reste ouverte et peut se greffer XP. Une des pratiques de SCRUM que nous ne pourrions suivre, est les rencontres journalires. Lquipe ntant pas entirement ddie au dveloppement, nous comptons peu de progression quotidienne. Quotidiennement, elles seraient trop frquentes et savreraient inutiles, par contre nous pouvons retenir de cette mthode, les critres de slection des fonctionnalits produire et les questions poser au cours dune rencontre de suivi journalier. Choisir entre un rfrentiel "maison" et l'intgration d'un rfrentiel standard du march ncessite de connatre les limites inhrentes aux derniers. En effet, la lourdeur du rfrentiel (trop de documentation), le cot de la mise en uvre lev et la dmarche de certification trop engageante nous mne choisir le rfrentiel "maison" qui sera par nature mieux adapt la DB, plus lger en documentation et ne ncessite pas de dmarche de certification. Les responsables de la DB ne prfrent pas intgrer une norme standard, il n'existe aucune motivation concrte d'une certification du systme qualit, cependant certaines rgles des normes standards de dveloppement logiciel peuvent tre intgres dans le nouveau rfrentiel qui sera adopt par la Direction du Budget.
3. Objectif du guide mthodologique du dveloppement logiciel

Le guide dfinit les processus de dveloppement logiciel en les catgorisant en trois processus majeurs: Processus gestion de projet : il comprend des activits d'organisation, de management et de planification. Processus technique : il regroupe les activits techniques de la cration d'un systme d'information. Ce document expose en particulier la dfinition des besoins fonctionnels, la conception du nouveau SI, sa ralisation et sa mise en uvre. Processus qualit : Il prsente la gestion du risque et la gestion documentaire. A cet effet, ce guide a pour but d'apporter une aide mthodologique autour des thmes suivants : - L'organisation et la dfinition des rles et des acteurs intervenant durant le cycle de vie du systme d'information; - La dfinition de la charte de projet informatique ; 130

- La conception et la ralisation d'un planning de projet informatique; - Le suivi des risques dans un projet de dveloppement logiciel; - L'laboration d'un cahier des charges fonctionnel; - L'laboration d'un dossier d'tude dtaille; - L'organisation du plan des tests de validation; - La gestion documentaire produite par lquipe de dveloppement logiciel; - La gestion des modifications intervenant aprs la constitution du cahier des charges. Ce document est destin toute personne participante au projet informatique dont les fonctions sont dcrites dans de ce guide.
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.
4.1.1. Pilotage global du systme d'information de la DB

L'organisation des structures participantes au projet de dveloppement logiciel se dcline en trois niveaux (cf. figure 6-1). Le comit de direction est responsable de la dfinition du schma directeur informatique de la DB, il est prsid par le directeur et est constitu des directeurs adjoints, des responsables de la Division des Systmes dInformation (DSI) et de l'ensemble des chefs de division. Le comit de direction ou directeur lance le dbut du projet, dsigne les membres de la commission de liaison informatique (CLI : dcrite dans le paragraphe suivant) et valide le produit final livr par la structure des systmes d'information (DSI).
131
Figure 6-1 : Gestion des projets informatiques de la DB
4.1.2. Pilotage par domaine fonctionnel

Les commissions de liaison informatique sont instaures par le comit directeur selon les domaines fonctionnels, chaque commission fixe les orientations en garantissant la cohrence pour le domaine fonctionnel, et suit les instances dcisionnelles de chaque systme d'information. Cette instance est charge de llaboration du cahier des charges fonctionnel, la validation fonctionnelle de chaque livraison partielle du produit et la mise jour; le cas chant; du cahier des charges fonctionnel, elle participe aussi la dfinition de la charte du projet. Cette commission est prside par un expert fonctionnel, elle est compose des utilisateurs et des cadres de la DSI, ceci permet aux dveloppeurs de bien comprendre les mtiers de la Direction du Budget, afin qu'ils deviennent une force de proposition de solution fonctionnelle, et non seulement des chargs de l'automatisation des processus mtier de la Direction du Budget.
4.1.3. Organisation de la structure des systmes d'information

La structure informatique de la Direction du Budget (DSI) est responsable de la ralisation technique du systme dinformation, elle assure le bon droulement de cette opration et garantit la qualit du produit livr. Cette structure est gouverne par une quipe nomm comit de pilotage oprationnel . Il sagit dune entit compose des responsables de la DSI et du chef de projet informatique, ce comit se charge de la planification et le suivi 132

du projet informatique, la gestion des changements qui mergent en cours ou aprs la production du logiciel, le suivi des risques, le suivi des mises jour des documents accompagnant le produit et llaboration des plans de formation. Lquipe oprationnelle assure la ralisation technique des fonctionnalits dfinies dans le cahier des charges, elle doit respecter les dlais prciss par le comit de pilotage oprationnel, ses principales activits sont : La conception des modles des donnes du systme dinformation futur ; Llaboration du dossier technique qui est matrialis par une tude permettant de dfinir les mthodes de faisabilit techniques et dfinit larchitecture du systme dinformation futur ; Le dveloppement des spcifications dfinies dans le cahier des charges fonctionnel ; Les tests de validation des modules et les tests dintgration du systme dinformation global ; Lassistance de l'quipe de formation pour llaboration du manuel de formation utilisateur du systme dinformation livr. Lquipe charge de la formation et dassistance assure la formation des utilisateurs au nouveau systme dinformation et continue doffrir le service dassistance tout au long de la vie du SI. Le diagramme de squence (cf. figure 6-2) dcrit lordre des activits de la production du systme dinformation et les interactions entre les diffrents acteurs intervenants dans le dveloppement logiciel.
133
Figure 6-2 : Diagramme de squence de dveloppement du systme d'information

Lgende (Figure 6-2) :
(i) : Retour l'tape (5) (ii) : Retour l'tape (11)
134

Il est important de signaler que la dure de l'itration de dveloppement doit tre comprise entre deux quatre semaines, les membres de la commission de liaison informatique doivent tre prsents la runion pour la validation du module produit pendant l'itration prcdente et l'expression des nouveaux besoins.
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.
Planification et suivi de lavancement du projet
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 ;

Matriser les moyens ; Diminuer les risques ; Suivre les actions en cours ; Rendre compte de l'tat d'avancement du projet. La planification est un outil de prise de dcision pour le chef de projet mais aussi de communication entre les diffrents acteurs d'un projet. Elle permet alors de matriser les interfaces du projet. Elle optimise ainsi les chances de russite d'un projet en amliorant la productivit grce une meilleure matrise de la qualit. La planification du projet est initialise au dbut du projet, le mme projet peut avoir plusieurs planifications, le comit de pilotage oprationnel est le responsable de ldition et la mise jour de la planification globale du projet Macro-planning , chaque itration de dveloppement informatique ncessite llaboration dun planning spcifique aux tches prvues lors de cette itration. La ralisation d'un planning ncessite la mise en uvre dune technique de planification. Il est conseill dutiliser la technique de GANTT1. A cet effet, il faut procder comme suit : Dterminer et structurer la liste des tches raliser pour mener bien le projet ; Estimer les dures et les ressources; Analyser la corrlation entre l'ensemble des tches. Le suivi de projet doit permettre d'effectuer un comparatif entre le prvu et le rel. La russite d'un bon suivi de projet tient en la disponibilit d'informations fiables, au niveau du chef de projet, sur : Les charges consommes, les reports d'chance; L'estimation du reste faire en charge et les travaux complmentaires prvoir ; Les difficults rencontres. Le suivi des projets doit tre rgulier, le chef de projet organise des runions rgulires de l'quipe de dveloppement. Les points que l'quipe souhaite inscrire l'ordre du jour sont communiqus au chef de projet au plus tard la veille de la runion. Un Journal
Le diagramme de GANTT est un outil utilis en ordonnancement et gestion de projet et permettant de 1 visualiser dans le temps les diverses tches lies composant un projet
136

de bord doit tre mis jour, il permet de garder une trace des informations communiques, des problmes rencontrs, des dcisions prises, des responsables dsigns pour mener bien les actions et la date de ralisation de l'action. L'ordre du jour de la runion est le suivant : Passage en revue des points non encore clos du journal de bord ; Prsentation de l'avancement des activits de l'quipe ; Examen des diffrents problmes et reports dans le journal de bord. Aprs laboration du journal de bord par le chef de projet, il doit tre valid par lensemble de lquipe participante la runion. Lutilisation de loutil MS-EXCEL peut garantir le suivi des projets informatiques. En effet, il permet la DSI de bien faire le suivi de lavancement du projet et ltablissement dun journal de bord. Lannexe IV contient un plan type de planning et de suivi de lavancement des projets. La Planification, la gestion et le contrle du projet font parties des domaines de
processus du Rfrentiel CMMi du niveau II.
4.4.
Gestion des risques
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

procder un brainstorming avec les membres de l'quipe oprationnelle. Une fois la liste initiale des facteurs identifie, les interactions possibles ou les combinaisons ventuelles entre les risques doivent tre examines afin de dceler des risques qui pourraient en dcouler. Ensuite, les risques doivent tre analyss (classification selon une typologie et estimation de leur probabilit d'apparition) et leurs consquences doivent tre values (en terme d'impacts certains qui apparatront une phase du projet ou une date prcise). Un poids est affect au risque, il est calcul comme le produit de la probabilit d'apparition du risque et de son niveau d'impact. Rduction des risques :
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

La gestion des risques est un des domaines de processus du Rfrentiel CMMi class au
niveau III. Pour une bonne gestion des risques il faut prvoir des livraisons frquentes.
4.5.
Rdaction du cahier des charges fonctionnel
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.
Programmation & codage
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

et en vitant les constructions qui rendent le code difficile lire. Nous proposons cidessous une convention de nommage concernant le codage en informatique : - Ecrire la premire lettre de chaque mot en majuscule. Exemple : NomClasse ; - Eviter d'crire des noms avec des espaces, ou autre caractre (-, _, /, *, +) ; - Donner des noms simples et descriptifs ; - Eviter dutiliser des raccourcissements (par exemple, cd=code), ni mme des mots lors de la composition des noms didentifiants. Par exemple, prfrer lutilisation de GetWindow GetWin ; - Eviter dutiliser les acronymes qui ne sont pas trs usits dans le mtier ; - Utiliser des acronymes seulement en cas dabsolue ncessit, et seulement lorsquil sagit dacronymes bien connus et rpandus. Par exemple, utiliser UI pour User Interface et OLAP pour On-line Analytical Processing. Les commentaires doivent tre en littrature franaise simple, ils doivent contenir des descriptions des classes, fonctions ou blocs de code. Les en-ttes de page du code doivent contenir une description de l'utilit de ce code, la date de cration, la date de mise jour et ventuellement les auteurs de cette page. Lindentation est laction qui permet dajouter des caractres de tabulations ou despaces dans le code source, elle le rend plus clair et plus lisible, l'indentation propose par l'diteur de Microsoft Visual Studio Dot Net utilis la DB, est bien structure, il faut veiller la respecter.
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

qui a fait le dveloppement. On propose que les dveloppeurs changent entre eux leurs modules cods afin qu'ils soient tests. Le chef du projet doit assurer les tests de non rgression, il doit vrifier chaque nouvelle itration que les lments conservs de l'ancienne itration du produit logiciel fonctionnent sans dgradation par rapport l'itration prcdente. Le service charg de lexploitation et du support doit assurer le test d'intgration afin de vrifier le bon fonctionnement de la structure du produit et des technologies utilises (units centrales, rseaux, architectures, etc.). Ce service est responsable aussi des tests en monte de charge afin de vrifier la robustesse du nouveau produit face au nombre dutilisateurs croissant. Les tests fonctionnels nomms aussi tests de recette mtier, consistent vrifier l'adquation du logiciel par rapport aux besoins fonctionnels des utilisateurs. L'engagement des utilisateurs professionnels dans cette tape est ncessaire, ils doivent vrifier la conformit du produit par rapport aux spcifications selon la dmarche suivante : - Effectuer des tests de saisie des erreurs ; - Effectuer des tests du flux du mtier, ces tests regroupent l'enchanement des diffrents crans de l'application pour vrifier la conformit du processus mtier automatis aux exigences exprimes; - Vrifier les tats de sorties du composant du produit livr. Il est recommand de faire des tests fonctionnels unitaires chaque livraison d'un composant du produit logiciel, le bilan de cette tape est la validation de ce composant ou l'expression des nouvelles spcifications fonctionnelles correctives ou adaptatives qui seront inscrites dans le cahier des charges fonctionnel pour l'itration suivante. Enfin, les tests de validation finale permettent la vrification de la conformit du produit logiciel livr par rapport aux spcifications. Cette opration est assure par l'utilisateur final lors d'une premire utilisation du SI, il vrifie l'exactitude des rsultats fournis par le produit aux rsultats obtenus par les anciennes mthodes de gestion que a soit manuel ou un ancien systme d'information. Le test fait partie des domaines de processus du Rfrentiel CMMi class au niveau III (Domaine de processus : Vrification).
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).
Processus de gestion des adaptations et des volutions

Envoi de la demande de modification : Les modifications surgissant en cours de dveloppement doivent tre lobjet dune mise jour du cahier des charges fonctionnel labor par la commission de liaison informatique. En revanche les modifications exprimes par les utilisateurs doivent tre formules sur une fiche de demande de modification (cf. annexe VII), la fiche est ensuite envoye la DSI ; Etude et avis sur l'opportunit et les priorits : Le chef de projet examine les demandes de modification reues, il les classe selon leurs importances et leurs priorits. Les demandes reues en cours de dveloppement peuvent mettre en cause les dlais de ralisation du module produit, elles doivent tre planifies en itration suivante. Toute demande de modification prsentant un caractre bloquant (sans solution de contournement existante) pour le systme d'information ou toute demande prsentant un caractre impratif en terme de dlai, sera considre comme demande urgente; Mise jour du portefeuille de la gestion des changements : Llaboration dun document de suivi des changements permet la DSI dassurer une bonne gestion de la planification en mettant en corrlation les tches prvues au dbut du projet et celles imprvues. Chaque projet doit avoir un portefeuille de gestion des modifications (cf. annexe VIII), il contient des informations sur le type de la modification (adaptative ou corrective), lobjet de la modification, la date de la demande, lidentification du demandeur, le responsable de la modification, la priorit de la ralisation et ltat de suivi de la demande ( prciser, analyser, accepte, ralise ou annule) ;
143

Raliser les modifications demandes : Les demandes de modification acceptes font ainsi lobjet dune planification pour une ventuelle ralisation.
Processus de gestion des anomalies logiciel (modifications de type correctif)

Envoi de la fiche d'anomalie : En cas danomalie, les utilisateurs seraient invits remplir une fiche danomalie (cf. annexe IX). Mise jour du portefeuille de la gestion des changements : Le portefeuille de gestion des modifications doit tre mis jour. Il faut noter que les anomalies sont prioritaires. Ralisation de la correction : le chef de projet planifie laction de la ralisation et dsigne les ressources correspondantes.
4.10. Formalisme documentaire

La documentation dun projet a une importance primordiale : cest loutil de communication et de dialogue entre les membres de lquipe projet. Elle assure aussi la prennit des informations au sein du projet. Afin dorganiser la gestion de la documentation produite par projet, il convient au pralable didentifier tous les types de documents relatifs aux diverses tapes dun projet, de les rfrencer de manire homogne pour ensuite dfinir un formalisme commun tous les documents. Le tableau 6-1 nonce les diffrents documents produire par la Direction du Budget lors dun projet de dveloppement informatique. Il est compos des colonnes suivantes : nom : titre du document (que l'on retrouvera en page de garde du document) ; auteur : la personne charge de produire le document, de le transmettre aux destinataires et de le mettre jour suite aux retours ventuels des destinataires ; priodicit : frquence de production du document et tape du projet concerne ; destinataires : liste des personnes auxquelles le document est destin pour action ; missions : exploitation du document faire par les destinataires : Vrification : action de contrle de la forme et du contenu pour commentaires ou enrichissements ventuels ; Validation : action de donner un avis par rapport au contenu (fond) du document, permet d'tablir le document comme une rfrence au sein du projet et de passer l'tape suivante ; 144

Information : diffusion pour consultation, sans retour attendu de la part du destinataire ; Action : diffusion pour application des recommandations/dcisions donnes dans le document.
Nom du document
Charte projet
Auteur
Priodicit
Destinataires
Missions
Documents de gestion de projet

DSI Au dbut du projet Comit directeur Commission de liaison informatique Macro-Planning DSI (Comit de pilotage oprationnel) DSI (Comit de pilotage oprationnel) DSI (Comit de pilotage oprationnel) DSI (Comit de pilotage oprationnel) DSI (Comit de pilotage oprationnel) Au dbut du projet Comit directeur DSI (Equipe oprationnelle) DSI (Equipe oprationnelle) DSI (Comit de pilotage oprationnel & Equipe oprationnel) DSI (Comit de pilotage oprationnel & Equipe oprationnel) DSI (Comit de pilotage oprationnel & Equipe oprationnel) Validation Information Action Validation Information Information
Planning de litration Journal de bord
Au dbut dune itration du projet de dveloppement Runions de l'quipe Identification dun risque Expression de nouveaux besoins
Information
Suivi des risques
Information Action Information Action
Suivi des changements
Documents dtude et dveloppement

Cahier des charges fonctionnel Commission de liaison informatique
- Etape d'tude
pralable
- Changements
des besoins fonctionnels Etape dtude dtaille
DSI (Comit de pilotage oprationnel & Equipe oprationnel)
Vrification Information Action
Document d'tude dtaille
DSI (Equipe oprationnelle)
DSI (Comit de pilotage oprationnel) CLI
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
Dbut de ltape de mise en uvre
Support de formation (Prsentation, atelier, etc.)
DSI (Equipe de formation)
Dbut de ltape de mise en uvre
Tableau 6-1 : Liste des documents labors par la DB lors du projet de dveloppement
145

Les documents labors par la DB doivent suivre un formalisme de prsentation et de contenu, Dans les sections prcdentes on a dj prsent des propositions du contenu type des documents livrer. Le tableau 6-2 prsente le formalisme de prsentation des documents accompagnants les projets informatiques : Champ Page de garde Observation / 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 (cf. annexe X). Tableau de gestion des mises jour (cf. annexe XI). Nom du document En Gras ; Times New Roman police 16 En Gras ; Times New Roman police 14 Times New Roman police 12 En bas de lobjet. Gras soulign ; Times New Roman police 12
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

- La dsinstallation : Cette activit consiste effacer physiquement lapplication et tous les dossiers qui contiennent des fichiers concernant cette application. Avant l'installation du nouveau produit, il faut penser identifier tous les aspects de la configuration matrielle, logicielle et organisationnelle : - Matrielle : Type et vitesse du processeur; Quantit de mmoire physique et virtuelle; Quantit de lespace disponible en disque dur du serveur; Taille estime des bases de donnes.
- 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

Il faut penser informer les utilisateurs par avance des dernires mises jour, certaines personnes n'aiment pas les surprises. L'intranet de la DB peut tre un moyen de communication.
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
CHAPITRE VII : CONDUITE DU CHANGEMENT DANS LA MISE EN UVRE DU NOUVEAU REFERENTIEL
Chapitre 7 CONDUITE DU CHANGEMENT DANS LA MISE EN UVRE DU NOUVEAU REFERENTIEL
149

Lobjectif fondamental de la mise en uvre du rfrentiel propos est de renforcer la productivit en fonction des ressources disponibles. Ce chapitre prsente les conditions de la dmarche de limplantation de la mthodologie propose au niveau de la Direction du Budget.
1. Contexte de la mise en uvre

La mise en uvre du rfrentiel des bonnes pratiques au sein de la Direction du Budget est un projet de changement. L'adoption d'une intgration graduelle et soutenue du guide est prfrable une implantation rationnelle et risque. John KOTTER dans son article [KOTTER 1995] prsente une stratgie constitue de huit tapes pour grer le changement en entreprise : - Prsenter l'urgence d'intervenir : Rappelons que dans la phase de l'tude de l'existant de l'laboration du schma directeur informatique de la DB, le cabinet DELOITTE a indiqu que la mthodologie de gestion de projets informatiques nest pas aligne avec les meilleures pratiques et le processus de gestion des changements nest pas formalis, le processus de gestion des versions et les demandes de changement provenant des utilisateurs ne sont pas formalises, il en va de mme pour les changements qui sont raliss. Il nest donc pas possible de suivre la satisfaction des demandes utilisateurs [DELOITTE 2008] (cf. figure 7-1).
Figure 7-1 : Analyse de la performance oprationnelle de la DB [Tir de DELOITTE 2008]
150

La forte sollicitation des utilisateurs aux divers projets de la DB affaiblit leur implication dans le processus de dveloppement dapplication et de recette, en outre labsence de la fonction dassistance de la matrise d'uvre pourrait conduire au dveloppement dapplications partiellement adaptes aux besoins des utilisateurs. La documentation insuffisante des changements et du dveloppement et linsuffisance des tests de recette pourraient conduire une perturbation non dtecte des fonctionnalits des applications et des incidents dexploitation lors des mises en production de nouvelles versions. En conclusion, le redressement est ncessaire. Les efforts pour intervenir sont justifis et urgents. - Composer une coalition pour mener le changement : L'appui des responsables de la DSI est acquis, puisque tout le groupe de travail est conscient de l'intrt du changement. C'est un projet peu coteux mais qui amne des bnfices importants. - Crer une vision pour guider les efforts : Le rfrentiel des bonnes pratiques, objet de cette mise en uvre, a t labor conformment au contexte de dveloppement logiciel la Direction du Budget, les projets de dveloppement entre dans les limites du rfrentiel. - Communiquer la vision : La prsentation du rfrentiel des bonnes pratiques expos dans le chapitre prcdent est planifie au profit de l'ensemble des cadres intervenant dans la production du systme d'information de la DB, des sances de travail sont prvues avec les dveloppeurs pour leur expliquer les nouveauts de ce rfrentiel. - Impliquer les gens et les inciter intervenir : La dmarche doit dbuter avec des gens conciliants et motivs. Ceci permet de mettre lpreuve le changement et liminer certains obstacles. Selon le questionnaire interne tabli pour l'analyse, la plus part des cadres de la DSI (92% : cf. figure 2-26) sont trs motivs pour un changement. Une formation sur les approches agiles pourrait motiver davantage les quipes de dveloppement.
151

- Planifier pour crer des petites victoires : Nous devons fixer des objectifs qui sont faciles raliser, le modle de dveloppement itratif adopt par le guide favorise cette dmarche. On recommande d'intgrer les pratiques du guide selon des tapes successives, les acteurs doivent s'habituer et matriser une pratique avant de passer la suivante. Lapplication graduelle des outils et des pratiques permettrait lquipe dintgrer les changements un la fois, constituant ainsi une srie de petites victoires. Nous proposons par la suite un planning de la mise en uvre du changement. - Consolider les amliorations et engendrer d'autres changements : Nous suggrons de conduire de faon cyclique des ateliers de rflexion pour valuer ce qui peut tre amlior et ce qui sera ajout. Ce moment de rflexion permet de consolider les changements et de planifier les prochaines transformations. Chaque nouvelle pratique sera value en runion. - Institutionnaliser la nouvelle approche : Lorsqu'une nouvelle pratique est intgre, le guide des bonnes pratiques peut tre mis jour, on peut appliquer ces pratiques dautres projets. Toutefois, le processus nest pas fig ternellement. Les ateliers de rflexion sont toujours pertinents pour assurer la viabilit du processus et apporter les rvisions.
2. Plan prvisionnel de la mise en uvre

La gestion du projet de changement des processus de dveloppement au sein de la DB englobera les cinq tapes principales conformment aux normes PMI : - Dmarrage du projet : Les conditions du dmarrage du projet sont convenables, Les objectifs majeurs du projet ont t dfinis dans ce travail, ils sont aligns avec le schma directeur informatique de la Direction du Budget. Les limites du projet on t identifies par l'intgration des nouveaux pratiques au projet de dveloppement pilote CDMT1. - Planification du projet : Elle consiste estimer les ressources humaines et matrielles requises pour la ralisation du projet dans le dlai prvu. Il faut ainsi dfinir l'organisation du travail, les structures oprationnelles et celles de pilotage. Un plan de communication auprs
Cadre de Dpenses Moyen Terme : c'est un cadre budgtaire pluriannuel glissant 1
152

des dveloppeurs et de la matrise d'ouvrage doit tre mis en place. Le tableau 7-1 prsente le plan de communication propos pour le projet du changement :
Communication Charte projet Guide des bonnes pratiques Comptes rendus des runions Source Comit de suivi du changement Comit de suivi du changement Comit de suivi du changement Moyen
Courrier Runion Prsentation Courrier Courrier Prsentation
Evaluation de la russite Comit de suivi du du projet changement
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
3. Les ressources requises

Un changement russi doit tre trs rapide, et peu onreux. Les ressources ncessaires la mise en uvre du projet sarticulent autour des ressources logicielles, humaines, budgtaires et celles lies la planification :
3.1.
Les ressources logicielles
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.
Les ressources humaines
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

Le fait d'externaliser la conduite du changement auprs d'une socit de conseil permet de solliciter des consultants spcialiss, dont la conduite du changement est leur mtier, cette expertise externe ajoutera ventuellement une assurance la russite du projet du changement. En revanche, un travail consquent est prvoir en amont pour permettre au consultant de connatre la DB, son organisation, son processus de dveloppement et ses cadres.
3.3.
Le budget estimatif du projet
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)
Formation Comprendre lagilit et mettre en uvre une dmarche Agile

Frais de dplacement et de sjour des formateurs pour la dure de la formation (Dmarche Agile) 10*2 sessions = 20 personnes
23 500,00 11 500,00 8 000,00 8 000,00 -
3J 4J 20 J -
141 000,00 11 500,00 32 000,00 160 000,00 344 500,00
10 -
Team Foundation Server Assistance en conduite de changement TOTAL
Tableau 7-2 : Budget estimatif du projet 155


Ce budget est titre estimatif, la validation d'une prestation de formation ou d'assistance externe doit tre conforme la lgislation marocaine des marchs publics.
4. L'organisation du projet de changement

La gestion du projet de changement du processus de dveloppement logiciel au sein de la DB requiert linstauration dune organisation qui veille la bonne conduite du changement (cf. figure 7-2). Le projet est pilot sous les directives du comit directeur. Un comit de suivi du changement a pour mission principale : La communication des objectifs ; Llaboration dun plan de communication ; Le suivi des indicateurs de performance ; Lamlioration du rfrentiel. La commission de liaison informatique sengage au processus du changement par sa disponibilit tout au long du processus itratif du dveloppement logiciel, la validation des modules livrs en fin de chaque itration, la restriction de la formulation des modifications aux modles formaliss proposs dans le rfrentiel, et le respect du formalisme documentaire. Lquipe oprationnelle est charge de lintgration des bonnes pratiques du guide que ce soit au niveau de la gestion du projet ou des tapes de la production du logiciel.
156
Figure 7-2 : Organisation du projet de changement du processus de dveloppement logiciel
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

Des runions hebdomadaires sont programmer pour valuer les nouvelles pratiques et les rsultats obtenus. Ces runions sont prsides par les responsables de la DSI, le chef du comit du suivi de changement et le chef du projet de dveloppement. L'tape la plus importante dans la dmarche de la mise en uvre du changement est l'implantation du modle itratif dans la gestion du projet. Cette tape dbutera au lancement du projet pilote CDMT : La prsentation du guide au profit des membres de la commission de liaison informatique ; Lintgration du formalisme documentaire loccasion de la rdaction de la charte de projet CDMT et du cahier des charges fonctionnel ; La mise en uvre des procdures de planification du projet et du suivi de son avancement ; Nous gardons toujours le mme rythme des runions d'valuation des pratiques intgres en ajoutant progressivement d'autres pratiques. Ces runions consistent dfinir les priorits suivre dans l'intgration des nouvelles pratiques et recueillir les recommandations pour russir l'opration de transition, nous suggrons de mettre jour le rfrentiel des bonnes pratiques si nous le jugeons ncessaire. En jugeant la matrise et l'adaptabilit des nouvelles pratiques l'organisation du projet, nous pouvons augmenter la priodicit des runions deux ou trois semaines. La mise en place du nouveau rfrentiel de la direction stale sur une priode de dix mois ( compter du rsultat de la prsente tude) selon le planning prvisionnel ci-aprs (cf. figure 7-3) :
158
Figure 7-3 : Planning prvisionnel de ralisation

159
6. Mesure de la performance du changement

Il faut penser mesurer l'impact des nouvelles pratiques intgres au processus de dveloppement logiciel de la DB. cet effet, un ensemble d'indicateurs doivent tre mis en place. Ces indicateurs adhrent la dmarche d'amlioration continue. L'indicateur le plus simple mettre en place est le portefeuille du suivi des anomalies, le nombre des fiches d'anomalie reues par la DSI dterminera l'efficacit des pratiques dployes. La matrise d'ouvrage peut aussi donner son niveau de satisfaction sur une chelle de un trois (Satisfait, Partiellement Satisfait, Non Satisfait). On peut aussi mesurer l'application des nouvelles pratiques sur une chelle de un quatre: 1- Action non ralise : Les acteurs n'ont pas pu mettre en uvre la pratique mesure; 2- Action ralise : Les acteurs ont parvenu la ralisation de la pratique; 3- Action matrise : Les acteurs matrisent la pratique; 4- Action amliore : La pratique est matrise et des amliorations ont t ajout; La mesure d'impact des nouvelles pratiques intgres au processus de dveloppement logiciel de la DB, permettra au comit de suivi du changement d'intgrer les niveaux d'obligations au rfrentiel propos prcdemment. Il faut aussi penser communiquer les bnfices constats lors de l'valuation du rfrentiel, cette action permettra de gagner la confiance de la matrise d'ouvrage et de motiver d'avantage les acteurs du dveloppement logiciel la DB, aussi bien que pour les quipes oprationnelles du projet ou les experts mtiers qui collaborent dans le cadre des commissions de liaison informatique.
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

Favorisation de la communication verticale aussi bien que horizontale ; Mobilisation des quipes de travail : Le chef du projet peut agir sur la mobilisation de son quipe grce aux moyens suivants : Donner une cible et des objectifs communs ; Mettre laccent sur le travail dquipe, la prise de dcision collective, lautonomie des quipes et la coopration ; Donner de la marge de manuvre, des dfis et des responsabilits ; tablir une relation de confiance avec les cadres de la DB ; Partager linformation ; Donner de la rtroaction rgulirement et manifester de la reconnaissance.
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]
I.1. Vous travaillez pour le service ?

SASI SDSM SDC SES
I.2. Quelle est votre fonction exacte ?

Chef de projet Administrateur de systme Concepteur Dveloppeur Technicien Autres (prcisez) :
I.3. Depuis quand exercez-vous votre fonction actuelle ?

Moins de 2 ans Depuis 2 5 ans Depuis plus de 5 ans
I.4. Quelle est votre formation initiale ?

Bac +2 Diplme universitaire de 2e ou 3e cycle (bac + 4 ou 5) Diplme dingnieurs Autres (prcisez) :
ii
ANNEXES
I.5. Avez-vous suivi une formation complmentaire ?
Oui Non
Si, oui la (les) quelle (s) ? Formation / Diplme
Institution / Etablissement
- II- ENVIRONNEMENT DE TRAVAIL

II.1. Participez-vous dans plusieurs projets informatiques en parallle ?
Oui Non
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
II.3. Quel est en moyenne le nombre des personnes de lquipe du projet ?

Moins 3 personnes De 3 10 personnes Plus de 10 personnes
- III - ACTIVITES REALISEES ET COLLABORATION

II1.1. Dans quel (s) phase (s) du projet intervenez-vous ?
Etude de lexistant Analyse et conception Dveloppement informatique Test Dploiement Autres
III.2. Elaborez vous des livrables dans le cadre de votre intervention ?

Oui Non
Si oui, lesquels ?
Cahier des charges Document de conception Recueil de l'existant Manuel d'utilisation informatique Cahier de maintenance Autres
III.3. Mettez-vous jour les livrable ?

Oui Non
Si oui, Selon quelle priodicit ?

Mensuelle Semestrielle Plus dun an En cas de modification apporte la phase de projet relative au livrable (conjoncturelle)
iii
ANNEXES
- IV - ORGANISATION ET METHODES DE TRAVAIL

IV.1. Travaillez-vous en mode projet ?
Oui Non Ne sait pas
IV.2. Disposez-vous dune mthodologie en gestion de projet ?

Oui Non
Si oui, laquelle ?
PMI Propre la DSI Autres (prcisez) :
IV.3. Utilisez-vous une des mthodes de dveloppement logiciel ?

Oui Non
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) :
IV.5. Utilisez-vous des mthodes danalyse ?

Oui Non
Si oui, laquelle ?
MERISE UML Autres, laquelle ?
IV.6. Utilisez-vous des outils de planification ?

Oui Non
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
Si oui, quelle fin ?

Capitaliser sur votre exprience Rduire les cots Amliorer la qualit Autres.
- 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) :
V.3 Dans quel domaine prouvez-vous le plus de difficult ?

La gestion des hommes La matrise des technologies Le changement des spcifications La communication avec le matre douvrage 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?
VI.3 Selon vous, quel est la bonne dmarche du changement?

Certification aux normes standards de dveloppement logiciel Sadapter une mthodologie standard de dveloppement (sans certification) Autres, Prcisez Ne rien faire.
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.5 Connaissez-vous quelques standards de certification ?

Non Oui, citez-les
VI.6 Quel est le standard sur lequel vous vouliez tre form ?
CMMi SPiCE ISO 9001 Autres standards, citez Pas besoin de formation
VI.7 Connaissez-vous une des mthodes agiles ?

Non Oui, citez-les
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.9 Dans une quipe, vous prfriez travailler dans :

Une quipe trs nombreuse Une quipe moyenne Une petite quipe Tout (e) seul (e)
VI.10 Accepteriez-vous dcrire le programme (code) informatique en binme?

Oui Non
VI.11 Avez-vous une remarque ou suggestion lamlioration du processus du dveloppement logiciel? .
Nous vous remercions davoir pris le temps de remplir ce questionnaire.
vi
ANNEXES ANNEXE II SPiCE - Pratiques par catgories de proccupations

CUS.1 CUS.1.1 CUS.1.2 CUS.1.3 CUS.1.4 CUS.1.5 CUS.2 CUS.2.1 CUS.2.2 CUS.2.3 CUS.2.4 CUS.3 CUS.3.1 CUS.3.2 CUS.3.3 CUS.4 CUS.4.1 CUS.4.2 CUS.4.3 CUS.4.4 CUS.4.5 CUS.4.6 CUS.5 CUS.5.1 CUS.5.2 CUS.5.3 CUS.5.4 CUS.5.5 CUS.5.6 CUS.5.7 CUS.6 CUS.6.1 CUS.6.2 CUS.6.3 CUS.6.4 CUS.6.5 CUS.6.6 CUS.6.7 CUS.7 CUS.7.1 CUS.7.2 CUS.7.3 CUS.7.4 CUS.8 CUS.8.1 CUS.8.2 CUS.8.3 Acquire software product and/or service Identify the need Define the requirements Prepare acquisition strategy Prepare request for proposal Select software product supplier Establish contract Review before contract finalization Negotiate contract Determine interfaces to independent agents Determine interfaces to subcontractors Identify customer needs Obtain customer requirements and requests Understand customer expectations Keep customers informed Perform joint audits and reviews Establish joint audits and reviews Prepare for customer audits and reviews Conduct joint management reviews Conduct joint technical reviews Support customer acceptance review Perform joint process assessment Package, deliver, and install the software Identify installation requirements Prepare site for installation Pack software Deliver software Verify correct receipt Install software Provide handling and storage procedures Support operation of software Identify operational risks Perform operational testing Operate the software Resolve operational problems Handle user requests Document temporary work-arounds Monitor system capacity and service Provide customer service Train customer Establish product support Monitor performance Install product upgrades Assess customer satisfaction Determine customer satisfaction level Compare with competitors Communicate customer satisfaction
ENG Engineering process category

ENG.1 ENG.1.1 ENG.1.2 ENG.1.3 ENG.1.4 ENG.2 ENG.2.1 Develop system requirements and design Specify system requirements Describe system architecture Allocate requirements Determine release strategy Develop software requirements Determine software requirements
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
PRO Project process category

PRO.1 PRO.1.1 PRO.1.2 PRO.1.3 PRO.1.4 PRO.1.5 PRO.2 PRO.2.1 PRO.2.2 PRO.2.3 PRO.2.4 PRO.2.5 PRO.2.6 PRO.2.7 PRO.2.8 PRO.2.9 PRO.2.10 PRO.3 PRO.3.1 PRO.3.2 PRO.3.3 PRO.3.4 PRO.4 PRO.4.1 PRO.4.2 PRO.4.3 PRO.4.4 PRO.4.5 PRO.5
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
Support process category
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
ORG Organization process category

ORG.1 ORG.1.1 ORG.1.2 ORG.1.3 ORG.1.4 ORG.1.5 ORG.1.6 ORG.2 ORG.2.1 ORG.2.2 ORG.2.3 ORG.2.4 ORG.2.5 ORG.2.6 ORG.2.7 ORG.2.8 ORG.2.9 ORG.2.10 ORG.2.11 ORG.2.12 ORG.2.13 ORG.3 ORG.3.1 ORG.3.2 ORG.3.3 ORG.3.4 ORG.3.5 ORG.3.6 ORG.3.7 ORG.3.8 ORG.3.9 ORG.4 ORG.4.1 ORG.4.2 ORG.4.3 ORG.4.4 ORG.5 ORG.5.1 ORG.5.2 ORG.5.3 ORG.5.4 ORG.5.5 ORG.5.6 ORG.5.7 ORG.6 ORG.6.1 ORG.6.2 ORG.6.3 ORG.6.4 ORG.7 ORG.7.1 ORG.7.2 ORG.7.3 ORG.7.4 ORG.7.5 Engineer the business Establish strategic vision Deploy vision Establish quality culture Build integrated teams Provide incentives Define career plans Define the process Define goals Identify current activities, roles and responsibilities Identify inputs and outputs Define entry and exit criteria Define control points Identify external interfaces Identify internal interfaces Define quality records Define process measures Document the standard process Establish policy Establish performance expectations Deploy the process Improve the process Identify improvement opportunities Define scope of improvement activities Understand the process Identify improvements Prioritize improvements Define measures of impact Change the process Confirm the improvement Deploy improvement Perform training Identify training needs Develop or acquire training Train personnel Maintain training records Enable reuse Determine organizational reuse strategy Identify reusable components Develop reusable components Establish a reuse library Certify reusable components Integrate reuse into life cycle Propagate change carefully Provide software engineering environment Identify software engineering environment requirements Provide a software engineering environment Provide support for developers Maintain software engineering environment Provide work facilities Provide productive workspace Ensure data integrity Provide data backups Provide building facilities Provide remote access facility
ANNEXES ANNEXE III
- 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]
[Cochez Votre Rponse]

I.1. Quel est le secteur d'activit de votre organisme ?
Administration Industrie Socit de Service Informatique (SSI) Autres, prcisez Banques
I.2. Quel est votre fonction2 dans lorganisme ?

Chef de projet informatique Testeur Analyste concepteur Autres, prcisez Dveloppeur
I.3. Quel est la taille de votre DSI3 en personnes ?

I.4. Quel est le nombre dutilisateurs de votre systme dinformation?

II.
II.1.
LE PROJET INFORMATIQUE
E-Learning Progiciel de gestion intgr (ERP) Dcisionnel Autres, prcisez
Quel sont les types de projet initi par votre organisme?

Production logiciel Knowledge Management
(KM)
II.2.
Qui sont les initiateurs du projet ?

Direction DSI Responsable mtier Autres, prcisez
II.3.
Qui pilote le projet ?

Direction DSI Responsable mtier Autres, prcisez
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?
(Veuillez prcisez en Jour/Homme)

Petite J/H Moyenne J/H Grosse J/H
III. LE DEMARRAGE DU PROJET INFORMATIQUE

III.1.
Les objectifs du projet avant le dmarrage sont ils clairs ?
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.
Quel est le degr de prcision de lexpression du besoin client avant dveloppement ?
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.
Le dlai de ralisation, est il fixe ?

Le dlai a t impos par le client ; il est indiscutable et immuable. Le dlai a t estim approximativement ; il est donn titre indicatif. On na aucune ide du dlai de ralisation ; on ne saurait sengager et engager lquipe.
III.4.
Quel est la planification du projet que vous avez adoptez ?
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. LE MANAGEMENT DU PROJET

IV.1. Comment vous faites le choix technique des outils de dveloppement?
Les outils dont dispose lorganisme Choix impos par la hirarchie Par une dmarche structure. Laquelle?
IV.2.
Comment vous faites pour choisir lquipe de travail ?

Les personnes qui travaillent dans lorganisme Une quipe choisie par la hirarchie Par une dmarche structure. Laquelle?
xiii
ANNEXES
IV.3. Comment vous vous organisez ?
Organisation existante dans lorganisme Organisation impose par la hirarchie Par une dmarche structure. Laquelle?
IV.4.
Est-ce que vous utilisez une mthodologie de gestion de projet ?

Oui Non
IV.5.
Si oui, votre mthodologie de gestion de projet, elle est :

Une mthodologie traditionnelle laquelle on a intgr des pratiques modernes. Une mthodologie standard, prouve, bien documente, tendue toute lorganisation. Quelle est cette mthodologie ?
V.
V.1.
LE PROCESSUS DU DEVELOPPEMENT
Intgration Autres, prcisez Maintenance
Quel est le type de production d'application informatique ?

Dveloppement interne Dveloppement externe (Achat)
V.2.
Quel sont les principales technologies informatiques utilises?

Dot Net Open Source J2EE Autres, prcisez
V.3.
Quelles sont les relations avec la matrise douvrage ?

On a un interlocuteur unique qui est un expert mtier ; il sait ce que veulent les utilisateurs.
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.
Avez-vous un contrle qualit ?

On na pas de contrle qualit ; on travaille dans lurgence. On mne priodiquement un certain nombre de contrles qualit et on organise quelques revues.
On a un plan qualit quon respecte trs rigoureusement en fournissant toute la documentation requise.
V.5.
Si vous avez un plan qualit, quelle dmarche qualit utilisez-vous?

CMMi ITIL V3 ISO 9001 SPiCE ISO 27001 Autres, Prcisez
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.
Quel est votre rythme des livraisons ?

Quelle que soit la dure des projets, on livre systmatiquement en retard. On livre en fin de projet, gnralement lchance prvue. On a adopt un dveloppement itratif et incrmental, avec des livraisons priodiques.
Si votre projet est de type dveloppement interne :

V.8. Quelle mthode de dveloppement avez-vous suivi?
Une mthodologie traditionnelle, Quel modle ? Modle ad-hoc Modle par prototypage Une mthodologie agile, Laquelle ? Extreme Programming Autres, prcisez Pas de modle formel Je ne sais pas. SCRUM Crystal Clear Modle en cascade Modle en spirale Modle en V Modle itratif
V.9.
Quel modle (s) danalyse (s) utilisez-vous dans votre projet ?

UML Pas de modle formel MERISE Autres, prcisez
V.10.
Non
Les tests fonctionnels ont-ils suivi une dmarche structure ?
Oui, Prcisez laquelle ?
V.11.
Non
Les tests techniques ont-ils suivi une dmarche structure ?
Oui, Prcisez laquelle ?
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
Selon vous quel est le niveau de votre documentation ?

Faible VI.3. Documentation utilisateur VI.4. Documentation technique Moyen Fort Trs Fort
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.
VII.3. Quel est le degr de satisfaction du matre douvrage

Trs satisfaits de la qualit de nos applications Assez satisfaits du produit fini, mais dplorent des livraisons tardives et pas toujours conformes aux besoins exprims Ne sont pas satisfaits, cest que le cahier des charges a t mal rdig
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
Et, Selon vous:

Faible VIII.5. le chef de projet a (ou a eu) une matrise sur le droulement du projet VIII.6. les chances ou le niveau de russite succs du projet sont VIII.7. le niveau de couverture des
re
Moyen
Fort
Trs Fort
besoins de la 1 version mise en oeuvre est ou sera
VIII.8. Avez-vous une remarque ou suggestion propos de ce questionnaire ou cette tude ?
MERCI POUR VOTRE COLLABORATION

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 Finances Direction Budget Bd. Med V. Quartier Administratif - RABAT- Chellah MAROC
xvii
ANNEXES ANNEXE IV Document de suivi davancement des projets
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
ANNEXES ANNEXE V Tableau de suivi des risques des projets informatiques
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.
2. Description des principes dorganisation et de gestion

2.1 Acteurs concerns Identifier ici l'ensemble des acteurs impliqus. Un acteur est une entit organisationnelle identifiable par les missions quil remplit au sein du champ dtude (acteur interne) ou lextrieur de celui-ci (acteur externe). Les acteurs sont organiss en postes de travail. 2.2 Principes dorganisation et de gestion Dcrire les principes d'organisation et de gestion mis en place. 2.3 Description des procdures Une procdure est une suite de tches excutes par un ensemble dacteurs et concourant au mme but. Une tche est un ensemble logique de travaux excuts par un poste de travail. Une tche peut tre de type temps diffr (TD), temps rel (TR) ou manuel (MA). Chaque tche est dcrite par les conditions de son dclenchement, lacteur, les travaux raliss, les rsultats produits, et le temps (dure, frquence).
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
4. Description des donnes

Rfrencer ici le Modle Relationnel de Donnes (modle MRD) de l'application. L'outil de modlisation MERISE ou UML doit tre utilis pour raliser le modle MRD de l'application.
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
ANNEXES ANNEXE VII Fiche de demande de modification
Ministre de l'Economie et des Finances
Demande de modification
Date : jj/mm/aaaa Auteur:
Direction Budget #Nom de projet# Application / Sous domaine : Description de la Demande Titre de la demande Description dtaille de la demande :
Date de livraison au plus tard Type de la modification
jj/mm/aaaa Adaptative Corrective
Signature du service demandeur
Rserv la DSI Priorit Action prvue - - -
Responsable de suivi
xxiv
ANNEXES ANNEXE VIII Portefeuille de gestion des modifications
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
ANNEXES ANNEXE IX Fiche d'anomalie
Ministre de l'Economie et des Finances
Fiche d'anomalie
Date : jj/mm/aaaa Auteur:
Direction Budget #Nom de projet# Application / Sous domaine : Description de l'anomalie
Degr de gravit
Bloquant Non bloquant
Signature du service demandeur
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
En-tte de page Corps Pied de page
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
ANNEXES ANNEXE XII
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
Comprendre les nouveaux dfis

Ledfioprationnel Ledfimarketing Ledfiorganisationnel Ledfignrationnel Ledfitechnologique
Dcouvrir les mthodes Agile

LentrepriseAgile:lecasGoogle L'agilitrpondinitialementaubesoin"d'treplusrapide" Desapprochesdiffrencies(Lean,XP,UP,Scrum) Comparaisondesmthodesagilesaveclesmthodestraditionnelles LemanifesteAgile:uneformalisationconsensuelle
Les objectifs dun projet Agile

Crationdevaleur Incrmentationauplusjuste Proximitetconfiancedansl'quipe Proximitclient
xxix
ANNEXES
Prsentation de Scrum
Monterl'quipeScrum L'espacedetravail Quelssontlesgrandsrendezvous
Jour1aprsmidi
Jeu Agile (avec des lgos)

DfinirleBacklog Planifierunsprint Ledroulementdel'itration Raliserladmo Raliserlartrospective
Jour2matin
Usine de dveloppement agile

Importancedestests L'intgrationcontinue QuiddelamodlisationUML Assurerlatraabilitentrelesoutilsdelusinededveloppement
Prsentation doutil Agile pour le dveloppement

UtiliserAtlassianGreenHopper UtiliserFitnessepourlesTDD(TestDrivenDevelopment)
Jour2aprsmidi
Appliquer scrum dans lentreprise

Visualiser&diffuserl'opportunitagiledansl'entreprise Crerdesprocessusagilesadaptslentreprise valuerlamiseenplacedel'agilit(projetspilotes) Passerduprojetagilel'entrepriseAgile
Industrialisation des projets pour une DSI & une entreprise plus agile.
VersuneapprocheglobaledelagilitpourrendrelaDSIplus"agile" Assurerlatransitiondesprojetsagiles&innovantsversl'industrialisation Capterl'adhsionduclientfinalfaceauxnouveauxusages.
Faire ou Faire faire ?

Sefaireaccompagner RflexionssurlesContratsauforfait. Comprendrelesdifficultsdansl'externalisationdeprojetAgile Parcourirlesretoursd'expriences Externaliseravecuncontratenminiforfait Externaliseravecuncontratparengagementdemoyens
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
ANNEXES ANNEXE XIII
Visual Studio Team System et Team Foundation Server 2010

Dure: Objectifs: Public et pr-requis:
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
(Consult en Avril 2010)
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
COMPUTE 2010 CTG 1998
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
(consult en Aout 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
http://pmdoi.org/ Declaration of Interdependence Jim Highsmith, 17 Fvrier 2005.
(Consult en Juin 2010)
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
IT-CMMI 2010 JEFF 2008
JNET 2011 KAN 2002
KNOWLLEN CE 2010 KOTTER 1995
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
MARTIN 2009 MORICE 1953
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
(Consult en Mars 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
(Consult en Aout 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.

Processus Du Développement Logiciel - Paradigmes & Perspectives

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Processus Du Développement Logiciel - Paradigmes & Perspectives

Uploaded by

Copyright:

Available Formats

ROYAUME DU MAROC

MINISTERE DE LECONOMIE ET DES FINANCES

Processus du dveloppement logiciel Paradigmes & Perspectives

Cas de la Direction du Budget

Prpar par : M. Badr TALAGHZI

Ingnieur dEtat Grade Principal la Direction du Budget

MINISTERE DE LECONOMIE ET DES FINANCES

Processus du dveloppement logiciel Paradigmes & Perspectives

Division of Information System

Contexte & problmatique

Processus de dveloppement Logiciel de la DB

Mthodes traditionnelles ou mthodes agiles

Dmarche qualit dans les systmes d'information

121 122 123 124 126

Rfrentiel des bonnes pratiques de dveloppement logiciel de la DB

Conduite du changement dans la mise en uvre du nouveau rfrentiel

Conclusion gnrale ANNEXES Rfrences

LISTE DES FIGURES

LISTE DES TABLEAUX

38 56 61 75 91 95 96 99 109 145 146 153 155

LISTE DES ACRONYMES

BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF

Le dveloppement logiciel est un support

d'accompagnement de la DB dans sa gestion budgtaire, par consquent, le Schma Directeur

BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF

CHAPITRE I : CONTEXTE & PROBLEMATIQUE

Chapitre 1 Contexte & Problmatique

BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF

CHAPITRE I : CONTEXTE & PROBLEMATIQUE

1. Prsentation de la Direction du Budget

CHAPITRE I : CONTEXTE & PROBLEMATIQUE

Organigramme de la Direction du Budget

BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF

CHAPITRE I : CONTEXTE & PROBLEMATIQUE

DB 3 Sous Direction Charge Coordination Structurelles Sectorielles et Synthse

Division Financement Bilatral et Union Europenne

Division Personnel de l'Etat, des Collectivits Locales et des Etablissements Publics

Division Secteurs Administratifs

Division Financement Multilatral et des Fonds Arabes

Division Secteurs de l'Infrastructure

Service des Suivi et de la Synthse

Division Finances Locales

Division Secteurs Sociaux

Division Normalisation des Dpenses Publiques

Division Secteurs Productifs et conomiques

DIVISION DU SYSTEME D'INFORMATION

Division Secteur Agricole et de la Compensation

Service Affaires Gnrales

Division Synthse et de la Coordination

Division de la Rforme Budgtaire, du Suivi de l'excution du Budget et de la Loi de Rglement

Figure 1-1: Organigramme de la Direction du Budget

BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF

CHAPITRE I : CONTEXTE & PROBLEMATIQUE

2. Organisation de la Division du Systme d'Information

Division du Systme d'Information 1

BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF

CHAPITRE I : CONTEXTE & PROBLEMATIQUE

2.1. Service de dveloppement des systmes mtiers

BADR TALAGHZI MEMOIRE POUR L'ACCES AU GRADE D'INGENIEUR EN CHEF

CHAPITRE I : CONTEXTE & PROBLEMATIQUE

2.2. Service de l'architecture du systme d'information

CHAPITRE I : CONTEXTE & PROBLEMATIQUE 2.3. Service de la communication et du dcisionnel

2.4. Service de lexploitation et du support