MIAGE MASTER 1 Cours de gestion de projet Session 3 : Méthodes de réalisation d’un Projet 1

MIAGE MASTER 1Cours de gestion de projet

Session 3 : Méthodes de réalisation d’un Projet

1

MIAGE 1: Cours de gestion de projetSession 3 : Méthodes de réalisation d’un Projet

Questions sur le cours précédent

• Régie? Assistance Technique?• Forfait?

• Projet de développement?• TMA?• TRA?

• Infogérance?


Sommaire

• Les disciplines standard d’un projet– …, Spécifications, Conception, Développement, Recette, …

• Les méthodes « classiques et obsolètes » (V, W)– Intérêts– Difficultés à postériori

• Les méthodes « itératives » (RUP, 2TUP)– Intérêts– Difficultés à postériori

• Les méthodes Agile– Fondements – Scrum, XP, Lean– Problématiques soulevées et difficultés rencontrées

• Exemples

3


Les disciplines d’un projet : vue d’ensemble

Rappel (session 1) :

Le cycle de vie du projet ne concerne que la réalisation du produit informatique (en rouge)

4

Maîtrise d’ouvrage

Projet domaine « Etudes »

Domaine Production

5


Les disciplines d’un projet : spécifications

• Spécifications = manière dont l’application va implémenter les besoins (étape précédente = expression de besoin)

• Définir le périmètre de l’application :– au niveau fonctionnel : activités métier à informatiser (souvent sous UML)

• Navigation dans l’application• Description détaillé des écrans : maquettes, règles de gestion écran• Organisation des traitements• Description détaillée des traitements « batch »• Gestion des habilitations• Paramétrage et contrôle des traitements

– au niveau technique : interfaces techniques du projet (normes, flux de données, interfaces matérielles (info indus, imprimantes, équipements mobiles, …)

• Livrables– Spécifications Fonctionnelles Générales (SFG) - option– Spécifications Fonctionnelles Générales (SFD) - obligatoire– Spécifications Techniques Générales (STG) - option– Spécifications Techniques Détaillées (STD) - option

6


Les disciplines d’un projet : Architecture Technique

• Peut être optionnel (si l’architecture est déjà en place et maîtrisée)• Nécessaire s’il faut industrialiser les développements sur de gros

projets• Tâches :

– Sélectionner avec soin les outils de développement– Récupérer un framework existant ou le créer– Mettre en place des fonctions standard pour les DAO– Identifier et contourner les contraintes techniques (ex : projets J2EE :

comportements différents selon les navigateurs)– Réaliser des modèles d’implémentation qui seront largement utilisés,

exemple : • Écran de saisie, navigation standard dans l’écran• Fenêtres standard d’erreurs et gestion standard des retours d’erreur

• Livrables– Dossier d’architecture logicielle

7


Les disciplines d’un projet : Conception Technique

• Conception Technique = Passerelle entre SFD et Code• Point d’entrée des développeurs• Tâches :

– Analyser les SFD et détecter d’éventuelles anomalies– Identifier les composants à développer (classes, écrans, services métier, …)– Formaliser la navigation entre les écrans– Formaliser sous forme de pseudo code les traitements

• Livrables– Dossier de Conception Technique

8


Les disciplines d’un projet : développement

• Tâches– Développement, dans le respect :

• Des spécifications• De la conception applicative

– Tests usine• Tests Unitaires • Tests d’intégration• Tests par mutation, tests par propriétés• Tests fonctionnels, Tests IHM• Tests de montée en charge, de robustesse, de sécurité, de scalabilité, ….

• Livrables– Code source– Exécutables, dans un package de livraison complet– Documentation du code (si intérêt)– Documentation utilisateur (dérive spécifications fonctionnelles)– Documentation des tests

9


Les disciplines d’un projet : recette

• But– Passage de ses tests avant mise en production

• Plusieurs niveaux : – VT : Validation technique (non contractuelle) : porte sur des sous ensembles

de l’application– VA : Vérification d’Aptitude (ou VABF : VA au Bon Fonctionnement) :

opération contractuelle : vérifier que l’application finale respecte scrupuleusement les spécifications. Cette validation déclenche la mise en production

– VSP : Vérification sur Site Pilote (optionnel) : correction de bugs éventuels en production sur une extraction des sites client

– VSR : Vérification pour Service Régulier (contractuel) : correction de bugs en production sur tous les sites clients. Déclenche le début de la garantie contractuelle

• Livrables– Bordereaux de livraison (chaque étape)– PV (procès verbal) de recette (chaque étape)

• « sans réserves »• « avec réserves » : bugs à corriger (mineurs)

10

11


Les méthodes « classiques et obsolètes » : Le Modèle en V

• Part d’une conception globale et décompose le système en sous-ensembles, qui sont développés et testés séparément. On fait ensuite l’intégration et les tests du système complet. Il ne prévoit pas de retour arrière.

12

Analyse des besoins

Conception du système

Conception du composant 'i'

Codage du composant 'i'

Test du composant 'i'

Tests d'acceptation

Tests du système


Les méthodes « classiques et obsolètes » : Le Modèle en W

• Il part du modèle en V, en y ajoutant des phases d’élaboration de maquettes permettant de valider la conception. Il ne prévoit pas de retour arrière.

13

Analyse des besoins

Conception du système

Conception du composant 'i'

Codage du composant 'i'

Test du composant 'i'

Tests d'acceptation

Tests du système

Définition des besoins bruts

Conception de haut niveau

Vérification des flux logiques

Maquettes


Les méthodes « classiques et obsolètes » : Synthèse

• Intérêts :– Permettent de connaître « dès le départ » l’ensemble des fonctionnalités d’une

application Rassurant– Fournies une documentation avancée du logiciel– Simple à appréhender Rassurant pour beaucoup de décideurs

• Difficultés à postériori :– Savez-vous aujourd’hui définir dans le détail et par avance la maison de vos rêves ??

Réponse oui en théorie, et NON dans la pratique : au mieux vous en aurez une idée plus ou moins précise (votre 3ème maison sera la bonne!)

• Il en va de même avec la conception d’une application.• Le besoin réel se construit au fur et à mesure de son utilisation.

– Cela implique la plus part du temps : • Une application mal pensée par rapport aux besoins réels des utilisateurs• Un dépassement des délais et des coûts établis au départ du projet

14

15


• L'idée est simple : pour modéliser (comprendre et représenter) un système complexe, il vaut mieux s'y prendre en plusieurs fois, en affinant son analyse par étapes.

Notion « itérative »

• Modèle souple, proche des réalités de terrain, non figé comme les modèles précédents évitant les cloisonnements stricts entre analyse et réalisation par exemple (dans les modèles précédents, on considère qu'il faut terminer 100% des spécifications avant de démarrer le développement => faux en pratique)

• Lié à une démarche de conception UML (scénario nominal, scénarii alternatifs, scénarii d’erreurs)

Les méthodes « itératives » : Principes


• Ce qu’il y a de nouveau avec les méthodes itératives :

IT 3

IT 2

IT 1

Domaine fonctionnel A

Domaine fonctionnel A.1

Domaine fonctionnel A.2

Domaine fonctionnel B

Domaine fonctionnel B.1

Légende : Fonctionnalité générale Fonctionnalité alternative Exceptions

Approche Itérative

Lot 1 Lot 2 Lot 3

Approche "traditionnelle"

Avant : approche en lots (qui sont des sous-ensembles fonctionnels), chaque lot étant implémenté complètement

Méthode itérative : chaque livraison a pour périmètre l’application globale, mais en incluant des raffinements successifs

Les méthodes « itératives » : Comparaison avec les méthodes « classiques »


• Les quatre phases : – phase d'initialisation (Inception) : mise en place et finalisaton du SDP

(Software Development Plan, ou Plan de Développement Logiciel) en définissant les itérations nécessaires. Début de la modélisation métier et de la réalisation de prototypes ;

– phase d'élaboration (Elaboration) : fixe le maximum de règles fonctionnelles (uses cases) et réaliser des prototypes permettant de lever les risques et les maquettes permettant de modéliser l'IHM générale de l'application ainsi que la cinématique d'accès,

– phase de construction (Construction) : développement et tests (unitaires, intégration, pré-qualification au gré de l'avancement des itérations de cette phase),

– phase de transition (Transition) : préparation du déploiement et conduite du changement.

Les méthodes « itératives » : Un cycle itératif


• RUP (Rational Unified Process) : les principes

Démarche itérative

Opérationsde modélisationet d’analyse

Opérationsde développement

Opérationsconnexes

Vue « pragmatique » : les tâches sont continues dans le temps (en pratique, les spécifications ne sont jamais totalement figées)

Les méthodes « itératives » : Implémentation RUP


• Illustration de la souplesse de la méthode : exemple type d’évolution de la couverture des spécifications sur le projet

Couv

ertu

re fo

nctio

nnel

lede

s ca

s d'

utili

satio

n

Phases Inception Elaboration Construction Transition

1 2 1 2 3 4 1 2 3Itérations

100%

90%

80%

30%

0%

Traitement des cas standards

Prise en compte des cas particuliers

Exceptions et interactions techniques

Réglages fonctionnels

On démarre les maquettes et prototypes avec uniquement 30% des spécifications

On démarre les développementsalors que les cas d’exception des

spécifications ne sont même

pas encore abordés.

Même en phase de pré-déploiement,

les modifications dedétail des spécifications

sont possibles

Les méthodes « itératives » : Evolution de la couverture applicative


• La répartition des charges selon les phases du RUP : Etape Initialisatio

nElaboration Constructio

nTransition

Charge de travail

~5 %

20 %

65 %

10%

Proportion de temps dans le projet

10 %

30 %

50 %

10%

Ressourceshumainesnécessaires

Initialisation Elaboration Construction TransitionEtapes

temps(linéaire)

Les méthodes « itératives » : RUP, Répartition de charges


• Chaque évolution majeure du logiciel est traitée comme un projet à part entière, et consiste donc à redémarrer un cycle.

• A un instant donné, les différentes évolutions du logiciel peuvent être dans des phases différentes

SDP Init. Elab. Construction Transition Evolution

Génération 1


Génération 2


Génération 3

Les méthodes « itératives » : Prise en compte d’évolutions dans RUP


Les méthodes « itératives » : Le cycle en « Y » ou 2 TUP : 2 Tracks Unified Process

Description des processus métierDescription des processus métier

Spécifications FonctionnellesSpécifications Fonctionnelles

Charte graphiqueCharte graphique

Spécifications TechniquesSpécifications Techniques

Architecture TechniqueArchitecture Technique

Architecture LogicielleArchitecture Logicielle

Conception itération 1Conception itération 1

Recette Technique itération 1Recette Technique itération 1

Recette Fonctionnelle itération 1Recette Fonctionnelle itération 1

Itération 2

Itération n

Recette Technique itération nRecette Technique itération n

Recette Fonctionnelle itération nRecette Fonctionnelle itération n

Mise en productionMise en production

DéploiementDéploiement

Tests Techniques itération 1Tests Techniques itération 1

Tests Fonctionnels itération 1Tests Fonctionnels itération 1

Réalisation itération 1Réalisation itération 1

Maquette / PrototypeMaquette / Prototype


Les méthodes « Itératives » : Comment contractualiser?

(en général)

– Le client envoi son cahier des charges plus ou mois flou

– Le prestataire effectuer une réponse chiffrée l’engageant sur le respect de besoin et de son estimation de charge

– Problème ! Cahier des charges flou => Nombreuses discussions contractuelles (= pertes de temps pour le projet) => Nombreux avenants => Non maîtrise du budget du projet

– Une fois le client satisfait de la qualité, il paie son prestataire

– De plus en plus les clients mettent des pénalités sur :• Les retards de livraison (1 jour de retard = 1 000 euros)• Sur la non qualité (1 anomalie bloquante = 2 000 euros)

24


Les méthodes « itératives » : Synthèse

• Intérêts :– Permettent de connaître rapidement les principales fonctionnalités d’une application

Rassurant– Autorise de revoir une partie du besoin en cours de route– Fournies une documentation avancée du logiciel– Simple à appréhender et à contractualiser Rassurant pour beaucoup de décideurs

• Difficultés à postériori :– Méthode encore trop orientée sur une définition figée du besoin utilisateur– Ne traite pas les problématiques de qualité de code, de non régression

• Ces méthodes s’approchent d’un processus de création incrémental

25

26


Les méthodes Agiles : Le manifeste

27

Extrait du manifeste Agile : http://agilemanifesto.org/

Nous découvrons comment mieux développer des logicielspar la pratique et en aidant les autres à le faire.

Ces expériences nous ont amenés à valoriser :

– Les individus et leurs interactions plus que les processus et les outils

– Des logiciels opérationnels plus qu’une documentation exhaustive

– La collaboration avec les clients plus que la négociation contractuelle

– L’adaptation au changement plus que le suivi d’un plan

Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

http://agilemanifesto.org/


Les méthodes Agiles : Le manifeste

28


Les méthodes Agiles : plusieurs solutions

29

• Scrum• eXtreme Programming• Lean• Devops• Kanban• Crystal clear• FDD• ASD, DSDM, …………


Agile : Focus sur SCRUM

La méthode Scrum est un processus itératif représenté par le diagramme suivant :



• Le « Backlog de produit » est constitué d’une liste de « User story », à savoir des cas d’utilisation simples et représentatifs. Il est modifié tout au long du projet par le directeur de produit. Chaque « User story » est orienté « fonctionnel » et est identifié de façon unique.





Les rôles dans Scrum sont :

• Le « Directeur du produit ou Product Owner» est le représentant des clients et utilisateurs. C’est lui qui défini le produit au travers du « Backlog » de produit.

• Le « ScrumMaster » est chargé de protéger l'équipe de tous les éléments perturbateurs extérieurs à l'équipe et de résoudre ses problèmes non technique.

• L’ « Equipe » ne comporte pas de rôle prédéfini et est autogérée. Elle s’adresse directement au directeur de produit.



• Le « Backlog de sprint » est réalisé à chaque début de sprint. Il contient l’ensemble des « User story » à réaliser pour celui ci. Le « Backlog de sprint » n’évolue jamais.

• La mêlée quotidienne (ou Daily Scrum) est effectuée chaque matin afin de vérifier qu’aucun élément ne perturbe le développement. Il s’agît d’un Stand-up Meeting (on reste debout pour que la réunion ne s’éternise pas…)– Point court de 10 à 15min– Exposer l’avancement de chacun et les problèmes rencontrés

MIAGE 1: Cours de gestion de projetSession 3 : Méthodes de réalisation d’un Projet 35

Agile : Focus sur XP

• Méthode résolument incrémentale et focalisée sur la programmation qui met en œuvre les pratiques suivantes :• TDD (Test Driven Developement)• Refactoring• Intégration Continue• Propriété collective• Normes de développement• Pair programming• Rythme soutenable

• Approche très complémentaire avec Scrum qui met en place l’organisation projet• Scrum et XP se sont mutuellement inspirées


Agile : Focus sur Lean

• http://blog.octo.com/qu-est-ce-que-le-lean• Ensemble de principes et de pratiques issus de Toyota :

• Respect des gens :• Le travail doit être motivant, épanouissant, inspirant• Le personnel doit être formé, encouragé et responsabilisé

• Eliminer le gaspillage :• Surproduction, • Délai (exemple : temps d’organisation d’une réunion), • Stock, • Transport, mouvement inutile, processus inutile et défauts

• Amélioration continue :• Innover : faire quelque chose de nouveau• Imiter : reprendre quelque chose qui a déjà marché ailleurs• Améliorer en continu pas à pas : partir de la situation actuelle et la

changer petit à petit en s’assurant que chaque changement est une amélioration

http://blog.octo.com/qu-est-ce-que-le-lean


Agile : Focus sur Lean

• Ensemble de principes et de pratiques issus de Toyota :

• Management visuel :• Consiste à rendre visible les écarts par rapport au standard. Comme cela

il n’est pas besoin d’être courageux pour parler de ces écarts, ils sont traités tout de suite soit en renforçant la formation aux bonnes pratiques, soit en ajustant le standard.

• Gemba : Avoir conscience du lieu où la valeur ajoutée est crée.

• Kanban : Méthode de planification de production d’un flux tendu

• Attention : Comme tout principe (méthode, dogme, religion, …), lorsque celui-ci est appliqué de manière excessive il devient néfaste!


Les méthodes « Agiles » : Comment contractualiser?

38

• Rappel sur un contrat forfait classique :

– Le client porte le risque du besoin, tant dis que le fournisseur porte le risque du produit.

– Du fait qu’en ingénierie logicielle, le besoin évolue très fréquemment, mais que le contrat lui ne bouge pas, le client tente souvent de faire porter le risque du besoin sur le prestataire, ce qui donne souvent lieu à de nombreuses négociations contractuelles.


Les méthodes « Agiles » : Comment contractualiser?

39

• Solution pour contractualiser en agile :– Engagement de moyen (régie) sur une équipe complète (Scrum Master

Architecte, Développeur)• Les itérations étant courtes, en cas de non satisfaction de la part du client, celui-ci

pourra remercier rapidement l’équipe constituée.

– Forfait basé sur une métrique de productivité • 1ères itérations facturées au temps passé pour mesurer la vélocité de l’équipe

– L’équipe est capable de produire tant de points (si l’on est en SCRUM)

• Ensuite l’engagement forfaitaire porte sur un nombre d’itérations devant respecter un certaine vélocité

– Le besoin fonctionnel peut évoluer en cours, à condition que la vélocité des itérations à produire reste la même.

– D’autres formes contractuelles existent :• Target Coast, Target Delay, Partage de profit

– Exemple de contrat Agile proposé par Xebia :• http://contrat-agile.org/


Les méthodes « Agiles » : Synthèse

• Intérêts :– Favorise clairement la productivité– Permet aux utilisateurs de mieux appréhender leurs besoins

• Difficultés à postériori :– Nécessite une forte implication du client – Conceptuellement plus complexe à appréhender (pour le client et pour les

prestataires)– Nécessite des collaborateurs très compétents, capables d’être performants

aussi bien sur le fonctionnel que sur le technique– Nécessité absolue de mettre en œuvre des outils de contrôle de qualité et de

non régression– Méthodes (très) difficiles à mettre en œuvre sur des gros projets (30, 40, …

ETP)– La contractualisation est rendue plus difficile

40


Cycle de vie des TMA

Prise en comptePrise en compte

Acq

uisi

tion

des

Acq

uisi

tion

des

conn

aiss

ance

sco

nnai

ssan

ces

Acq

uisi

tion

des

Acq

uisi

tion

des

conn

aiss

ance

sco

nnai

ssan

ces

OrganisationOrganisationOrganisationOrganisation

Mai

nten

ance

M

aint

enan

ce

en m

ode

assi

sté

en m

ode

assi

sté

Mai

nten

ance

M

aint

enan

ce

en m

ode

assi

sté

en m

ode

assi

sté

Lancement

Recette

Maintenance OpérationnelleMaintenance Opérationnelle

Maintenance en mode Maintenance en mode autonomeautonome

Réalisation des services de Réalisation des services de maintenancemaintenance

Maintenance en mode Maintenance en mode autonomeautonome

Réalisation des services de Réalisation des services de maintenancemaintenance

Projets d’évolutionProjets d’évolutionProjets d’évolutionProjets d’évolution

Fin de TMA

Management et suivi de la prestation Réversibilité

Recet

te

Recet

te

RéversibilitéRéversibilitéRéversibilitéRéversibilité

Montée Montée en en

charge charge équipe équipe ClientClient

Montée Montée en en

charge charge équipe équipe ClientClient

Transfert Transfert de l’activitéde l’activitéTransfert Transfert

de l’activitéde l’activité

OOrrggaanniissaatitioonn

OOrrggaanniissaatitioonn

• Le Cycle de vie peut être spécifique à chaque métier

– Tierce Maintenance Applicative (exemple => )

– Infogérance

– Etc.

TMATMA


Les TMA : Comment contractualiser?

(en général)

• La phase de prise en compte est forfaitaire• Il arrive qu’elle soit offerte au client en tant que geste commercial

• En phase opérationnelle :• Les activités de MCO, Support sont forfaitaires, mais basées sur un volume

d’activité déjà constaté ou estimé (nombre d’anomalies, nombre d’incidents, …)

• Les évolutions sont forfaitaires et utilisent des Unités d’Œuvre pour les valoriser

• La phase de réversibilité est forfaitaire

42

43


• Comment savoir quelle méthode appliquer ?

Type de projet

Technique

ERP/Décisionnel

Dév. Spécifique C/S

Dév. Spécifique J2EE

Risque

Normal Élevé Très élevé

Taille du projet

Petit (<500 j/h)

Moyen

Important (>5000 j/h)

« Votre »

méthode

Quelle méthode pour quel cas ?

Client

VolontairePeu impliqué ExpérimentéCQFD !


Prochaines sessions

• Session 4 : Découpage d’un projet• TP 1 : Outil de suivi d’un projet (L. Descamps)• Session 5 : Estimation des charges• Session 6 : Outils de planification• Session 7 : Gestion des ressources d’un projet• Session 8 : Suivi d’un projet• TP2 : Suivi pratique d’un projet (L. Descamps)• Session 9 : Coûts d’un projet / Gestion des risques• Session 10 : Assurance Qualité• Session 11 : Recette et AMOA• Session 12 : Conduite du changement• Session 13 : Bilan de projet• Examen, correction

45

Documents

MIAGE MASTER 1 Cours de gestion de projet Session 3 : Méthodes de réalisation d’un Projet 1