Version V1.8 Date Septembre 2007 Auteur Pascal HEYERpascal.heyer.free.fr/M02_2007_Cours_Methodes de conduite de projet... · Merise/cycle de vie ... Merise/Processus de conception

�

La Gestion de projetP. Heyer Sept 2007

1

Cours Gestion de projetCours Gestion de projet

MMééthodes de conduite de projetthodes de conduite de projet

Septembre 2007Date

Pascal HEYERAuteur

V1.8Version

�


2

MMééthodes de conduite de projetthodes de conduite de projet

Ce document est publié sous la licence libre Creative Commons-BY-NC-SAhttp://creativecommons.org/licenses/by-nc-sa/2.0/fr/

BY : Paternité. Vous devez citer le nom de l'auteur original.

NC : Pas d'Utilisation Commerciale. Vous n'avez pas le droit d'utiliser cette création à des fins lucratives et commerciales.

SA : Partage des Conditions Initiales à l'Identique. Si vous modifiez, transformez ou adaptez cette création, vous n'avez le droit de distribuer la création qui en résulte que sous un contrat identique à celui-ci. En outre, à chaque réutilisation ou distribution, vous devez faire apparaître clairement aux autres les conditions contractuelles de mise à disposition de cette création.

Chacune de ces conditions peut être levée si vous obtenez l'autorisation du titulaire des droits.

�


3

Méthodes de conduite de projet

• Sommaire– Rappel sur les activités de développement– Plan de conduite– Cycle de vie du logiciel– Les principales méthodes– Synthèse– Recommandations

�


4

Rappel sur les activités d’un projet informatique de développement

• Activités d’ingénierie logiciel :– Conception– Développement– Test

• Activités de gestion :– Gestion de projet– Gestion des tests

• Activités support :– Assurance de la Qualité– Gestion de configuration logiciel– Documentation, traduction,

formation– Système, réseaux, base de

données

TestRéalisationConception

Gestion

AQL

GCL

Documentation ….

Infrastructure (système, réseaux, SGBDR)

�


5

Le plan de conduite = scénario du projet

• Le scénario du projet dépend :– De la méthode de conduite de projet utilisée qui définit les

activités d’ingénierie logicielle :• Découpage Projet en Phases/étapes/tâches

– Pour chaque étape : entrée, activités (acteurs/responsabilité), sorties (produits), V&V

• Le cycle de vie

– De la Méthode de conception (modélisation)

�


6

Précisions sur le vocabulaire

• Les méthodes de conception (modélisation) permettent de décrire un système d’information et ses évolutions :– UML

• Les méthodes de conduite de projet décrivent un processus de développement qui s’appuie sur une méthode de modélisation :– UP– RAD

• Des adhérences entre conception et conduite de projet :– Merise/Merise, UML/(UP et ses déclinaisons)

�


7

Les objectifs du cours

• Il s’agit de :– Comprendre les grands concepts des principales

méthodologies de conduite de projet et leurs cas d’utilisation

• Il ne s’agit pas de :– De maîtriser ces méthodologies

�


8

Le processus de développement

• Phases, étapes, activités de spécification, de conception, réalisation et test avec des activités de V&V – Le cycle de vie ��

��

��

��

��

��

��

��

��

��

�

�

��

�

�

��

� ��

��

�


9

Le processus de développement

• Est constitué de Phases/étapes/activités de spécification, de conception, réalisation et test avec des activités de V&V Leur enchaînement = Le cycle de vie

Lancement

Cadrage Spécifications Conception Réalisation

Clôture

Version

Approche d'ensemble

Management de Projet et activités Support

Mise en productionTests

�


10

Cycles de vie (1/5)

• « Pré-historique ? »

• Cascade simple��

� ��

��

� ��

� ��

Analyse

Conception

Codage

Tests

Maintenance

Codage

Utilisation

�


11

Cycles de vie (2/5)

• Cascade « évoluée » : Processus en V

Implémentation

Expressiondes besoins

Testsd’acceptation

Tests du systèmeSpécificationdu système

Conceptiongénérale Tests intégrés

Tests unitairesConceptiondétaillée

FC

�


12

Risques et amélioration du cycle de vie en cascade (3/5)

• Risques élevés et non contrôlés– Identification tardive des problèmes– Preuve tardive de bon fonctionnement=> Effet « Tunnel »

• Améliorations :– Découplage entre phases et activités– Construction du système par incréments (phases)– Chaque itération a pour but de maîtriser une partie des risques

et apporte une preuve tangible de faisabilité ou d’adéquation– Enrichissement d’une série de prototypes– Les versions livrées correspondent à une étape de la chaîne des

prototypes

�


13

Amélioration du cycle de vie en cascade (4/5)

• Processus itératif et incrémental– Un processus itératif implique la gestion d'une succession des

activités de développement.– Un processus incrémental signifie que l'architecture du système

est constamment améliorée pour produire ces nouvelles versions qui apportent toutes des améliorations incrémentales par rapport à la précédente.

– Un processus à la fois itératif et incrémental doit être centré sur les risques, c'est-à-dire que chaque nouvelle version se concentre sur la prise en charge et la réduction des risques les plus importants qui pourraient menacer la réussite du projet.

�


14

Cycle de vie (5/5)

• En spirale

Conception

Analyse

Spécifications Besoins

Validation

Tests

Implémentation

Prototype

V1 V2

�


15

Cycle de vie et méthodes de conduite

Cascade (Merise, SDM/S) Semi-itératif (RAD) Itératif (UP, XP)

�


16

Merise/Historique

• Méthode d’Étude et de Réalisation Informatique pour les Systèmes d’Entreprise

• En 1977/1978, demande du Ministère de l'Industrie : choix de sociétés de conseil en informatique pour la constitution d'une méthode de conception des systèmes d'information– Équipe de J.-L. Lemoigne (Univ. d'Aix / Marseille)– CTI (Centre Technique d'Informatique)– CETE (Centre d'Études Techniques de l'Équipement)

�


17

Merise/Principes de base

• Principes de base de la méthode Merise– Vision globale : la mise en place d'un S.I. est liée à la refonte de

l'organisation– Vision systémique de l'entreprise : travaux de J.-L. Lemoigne, J.

Melese, J. de Rosnay

�


18

Merise/Approche

1. Approche par niveaux et par étapes– Niveaux :

• en contribuant à la stratégie de l'entreprise en mettant en œuvre les règles de gestion

• en tenant compte des aspects organisationnels • en tenant compte des aspect techniques=> formalise le système futur

– Etapes :• conception• développement• mise en œuvre• généralisation de l'emploi du S.I. futur• évolution du S.I. futur=> hiérarchise les décisions au cours de la vie du projet

2. Séparation des données et des traitements

�


19

Merise/Principes de base

1. Passage par différents étapes : "le cycle d'abstraction pour la conception des S.I.">système d'information manuel

>expression des besoins>modèle conceptuel (quoi)

>modèle logique (qui, quand, ou)>modèle physique (comment)

>système d'information automatisé

2. La séparation des données et des traitements– l'agencement des données est plutôt stable– les traitements sont fréquemment remaniés– la séparation des données et des traitements– assure une longévité au modèle

FC

�


20

Merise/Chronologie des étapes

�


21

Merise/cycle de vie• Le cycle de vie se décompose en phases :

– Spécifications des besoins,– Conception générale,– Conception détaillée,– Codage et tests unitaires,– Tests intégrés (intégration des modules),– Tests système (intégration du logiciel),– Recette.

Ces phases sont échelonnées dans le temps.

Une phase se termine par la remise de Livrables(s) validé(s).Une phase se termine lorsque la revue de cette phase est faite.

Une phase ne peut commencer que lorsque la précédente est terminée.

=>La décomposition en phases permet donc le suivi du projet.

�


22

Cycle de vie

• Processus de développement d'un logiciel classique :

�


23

Merise/Processus de conception• La courbe du soleil (cycle complet)

�


24

Merise/Modélisation

• Merise intègre sa propre méthode de modélisation– Niveau conceptuel

• Modèle Conceptuel de Données• Modèle Conceptuel des Traitements

– Niveau Organisationnel• Modèle Logique de Données• Modèle Organisationnel des Traitements

– Niveau Physique• Modèle Physique de Données• Modèle Opérationnel des Traitements

�


25

Les Méthodes Agiles (AM = Agile Modeling)� !��" �� #��$��%��&��$��&�� '��(��)

� *��+,,-(��$�� $��%��'��.//0001��1��/�$�)1�

� 2�� !�� $��%�� 3 �� 4��.

– priorité aux personnes et aux interactions sur les procédures et les outils, – priorité aux applications fonctionnelles sur une documentation pléthorique, – priorité à la collaboration avec le client sur la négociation de contrat, – priorité à l'acceptation du changement sur la planification.

� ��4��-+��&�#��$��1

�


26

Les Méthodes Agiles• Nombreuses• S’appliquent en fonction de la taille et la typologie des projets

�


27

UP (Unified Process)

• Historique :– 1997

• Principes :– Approche itérative et incrémentale– L’ordonnancement des itérations est basée sur les priorités entre

cas d’utilisation et sur l’étude du risque– Chaque prototype réduit une part du risque

• Un prototype est un programme exécutable qui peut s’évaluer quantitativement

• Un prototype donné est construit avec des buts précis et clairement exprimés

• Les priorités et l’ordonnancement de construction des prototypes peuvent changer avec le déroulement du plan

�


28

UP/Phases et itérations

• Des phases– Inception (étude d'opportunité)– Elaboration (architecture, planification)– Construction– Transition

• Des itérations– Chaque cycle donne une génération– Chaque cycle est décomposé en phases– Chaque phase comprend des itérations

• Des incréments– Le logiciel évolue par incrément– Une itération correspond à un incrément– Les itérations peuvent évoluer en parallèle

��

� ��

� ��

��

�


29

UP/Phases et itérations

� �� !�� "!��#��

�


30

UP/Modélisation

• UML– Diagrammes de contexte– Diagrammes de cas d’utilisation– Diagrammes d’objet– Diagrammes de classes– Diagrammes de composants– Diagrammes de déploiement– Diagrammes de collaboration– Diagrammes d’état-transition– Diagrammes d’activités– Diagrammes de séquences

�


31

UP->RUP (Rational Unified Process)

• Promu par IBM Rational• C’est un outil qui propose des gabarits partagés dans un

référentiel

�


32

XP (eXtreme Programming)

• Historique– Initiative de Kent BECK en 1996– Projet vitrine à la DRH Chrysler

• Principes :– Pousser à l’extrême les bonnes pratiques de génie logiciel– Respecte le manifeste des méthodes Agiles

• 4 valeurs de base -> 12 pratiques

�


33

eXtreme Programming

• Les 4 valeurs fondamentales :– Communication : tout doit être prétexte à communiquer.

Privilégier les échanges directs (face à face)– Simplicité : faire simple avant tout– Rétroaction (feedback) : utiliser les expériences du passé et les

remarques du client le plus possible– Courage : il faudra peut être jeter des semaines de travail pour

suivre les nouvelles exigences du client (accepter le re-work)

�


34

eXtreme Programming

• Les 12 pratiques :– Livraisons fréquentes– Planification itérative– Intégration continue– Tests permanents– Métaphore système– Conception simple– Remaniement– Programmation en binôme– Responsabilité collective du code– Rythme durable– Client sur le site– Standard d’écriture

�


35

eXtreme Programming

• Cycle de vie

�


36

Synthèse (1/4)• MERISE (conduite de projet) (ou SDM/S) : Approche «par la structure»

(systémique).– Inconvénients (liés à la validation en cascade) : rigidité, manque d'adaptation,

éloignement des besoins détaillés des utilisateurs, on valide que du papier, «effet tunnel».

• UP/RUP (ou RAD) : Approche « par la structure » avec validation en cascade (pour maintenir la cohérence global) lors du premier tiers du projet. Puis, approche « par les besoins » avec construction-validation de type itératif-incrémentiel (pour assurer la conformité de l'application aux besoins de l'utilisateur).– Inconvénients : pas d’inconvénient «structurel», mais implique d’adapter le

processus à la typologie du projet. Gestion des besoins « béton ».

• XP (ou FDD, Crystal) : Approche «par les besoins» se voulant totalement incrémentielle et itérative mais finalement débutant par une phase exploratoire (comme UP).– Inconvénients : risques d'incohérences, de redondances et de déstructuration

des programmes par de trop fréquentes modifications. Gestion des besoins « béton ».

�


37

Synthèse (2/4)

��

��

��

�� !��

��

��

��

��"#$

��"#%

��"#�

��"#�&$

��"#�&%

��"#�

��"#�&$

��

��

��

Merise

�


38

Synthèse (3/4)

• Coûteux àpersonnaliser :batterie de consultants

• Très axé processus,au détriment du développement : peude place pour le codeet la technologie

• Itératif• Spécifie le dialogue entre les différents intervenants duprojet : les livrables, les plannings, les prototypes…• Propose des modèles de documents et des canevas pour des projets types

• Promu par Rational.• A la fois une méthodologieet un outil prêt à l’emploi (documentstypes partagés dans un référentiel Web)• Cible des projets de plus de 10 personnes

RUPRationalUnifiedProcess

• Non itératif• Effet tunnel• Ne propose pas de modèles de Documents

• Distingue clairement les phases projet• Simple à mettre en œuvre• Partagé par la communautéinformatique

Propose de dérouler les phases projet de manière séquentielle

CascadeMerise

Points faiblesPoints fortsDescription

�


39

Synthèse (4/4)

• Ne couvre pas les phases en amont et en aval au développement :capture des besoins, support, maintenance, tests d’intégration…• Elude la phase d’analyse, si bien qu’on peut dépenser son énergie àfaire et défaire• Assez flou dans sa mise en œuvre: quels intervenants, quels livrables ?

• Itératif• Simple à mettre en œuvre• Fait une large place aux aspects techniques : prototypes, règles de développement, tests…• Innovant: programmation en duo, kick-off matinal debout …

• Ensemble de «BestsPractices» de développement (travail en équipes, transfert de compétences, etc.)• Cible des projets de moins de 10 personnes

XPeXtremeProgramming

Points faiblesPoints fortsDescription

�


40

Recommandations (Best Practices ?)� *��.5 ��'67,)

5 ��

5 8��2��#��

� *��.5 9� ��#��(��$��:��1

� ��:��;��<��.5 ��:=� '�$$��(��$��(� ��)�