ESPS

Conduite des projets

LES MÉTHODES AGILES

ESPS
ESPS
ESPS

Processus de développement

Ensemble d'étapes partiellement ordonnées, qui concourent à

l'obtention d'un système logiciel ou à l'évolution d'un système
existant.

Objectif : produire des logiciels

- De qualité (qui répondent aux besoins de leurs utilisateurs)
- Dans des temps et des coûts prévisibles
A chaque étape, on produit :
- Des modèles
- De la documentation
- Du code
ESPS

Méthode = Démarche + Langage

UML n'est qu'un langage

Spécifie comment décrire des cas d'utilisation, des classes, des
interactions...
Ne préjuge pas de la démarche employée

Méthodes s'appuyant sur UML?

ESPS

LES METHODES AGILES

EXEMPLE : SCRUM
ESPS
 ESPS

Cette démarche respecte une succession d’étapes immuables (fixes),

une approche somme toute logique car les informaticiens se sont rendus
compte, au fil des ans, qu’il valait mieux procéder par étapes, du début à la fin.
Ainsi, comme pour la construction d’une maison, on pose les fondations en
premier, on monte les murs ensuite, puis le toit et on termine par
l’aménagement intérieur.
 ESPS

La première étape est celle des spécifications. Il s'agit d'écrire noir sur blanc
les objectifs du logiciel et les fonctionnalités qu’on en attend. Une fois que
les clients et les informaticiens sont bien d’accord sur ce point, on peut passer
à l'étape suivante, l’analyse. Celle-ci consiste à expliquer par quels procédés
on va atteindre les objectifs spécifiés. Ce travail est réalisé en partie sur papier
et en partie en créant des prototypes qui valident les idées. Le codage
consiste ensuite à concrétiser les procédés issus de l’analyse, en écrivant du
code ou en rassemblant des logiciels préexistants. À ce stade, la moitié du
travail est faite.
 ESPS

Il reste à vérifier que ce qui a été spécifié, analysé et codé est bien conforme
aux attentes des clients. C’est ce que l’on appelle les tests et la validation.
Pour finir, le déploiement des logiciels testés et validés consiste à mettre à
disposition ces logiciels sur les systèmes cibles
ESPS

Toutefois, cette méthodologie en V a été bousculée au cours de la dernière

décennie, en raison de l’extraordinaire développement du web et des
terminaux fixes et mobiles, qui envahissent désormais notre environnement
familier.
Elle présente en effet un inconvénient notoire : elle fonctionne
comme un rouleau compresseur. Une fois la méthode lancée, on doit aller
jusqu’au bout sans modifier les spécifications initiales, c'est-à-dire les objectifs
et les fonctionnalités attendues du logiciel.
ESPS

Si le projet dure deux ans et concerne un logiciel de gestion de barrage

hydroélectrique, ce n’est pas gênant. Mais s’il s’agit d’un jeu vidéo sur
smartphone ou d’un site d’e-commerce, cette inertie peut vite devenir
insupportable pour les utilisateurs et préjudiciable pour le client qui
achète ce logiciel.
ESPS

C’est donc pour éviter l’effet « rouleau compresseur » que les informaticiens
ont mis en place les méthodes agiles, qui permettent, dans les cas favorables,
de modifier graduellement les objectifs et les spécifications des logiciels.
Idéalement, les méthodes agiles livrent des logiciels qui fonctionnent
immédiatement avec un jeu restreint de fonctionnalités, là où les méthodes
classiques imposent que le logiciel ne soit livré qu'à la fin des développements
complets.
Ce jeu de fonctionnalités est ensuite enrichi régulièrement,
en fonction des nouvelles demandes des utilisateurs ou de la pression
concurrentielle.
Plusieurs méthodes se revendiquent du courant agile. Voici les principales,
classées par ordre chronologique d’apparition :
ESPS

RAD pour Rapid Application Development (1991)

Scrum (1996)
XP pour eXtreme Programming (1999)
Crystal Clear (2004)
L’agilité est une valeur montante dans le secteur de la production de logiciel.
De nombreuses entreprises d’ingénierie et de service ainsi que de nombreux
éditeurs de logiciels ont lancé des projets en mode agile, lorsque le contexte
technique ou contractuel y était favorable.
ESPS

On ne peut pas résumer l’agilité à un simple changement de planning.

L’objectif ultime est la satisfaction des utilisateurs en termes de valeur
perçue, de facilité d’utilisation et de respect des délais.
Dans ce but, les premiers promoteurs des méthodes agiles ont également
impulsé des valeurs nouvelles pour penser le travail. Ces valeurs tiennent
en peu de mots, elles ont été écrites sous la forme d’un « Manifeste Agile » au
début de la décennie 2000, qui met en avant quatre valeurs fondamentales.
ESPS

Le manifeste Agile

Personnes et interactions Plutôt que Processus et outils

Documentation
Un produit opérationnel Plutôt que
exhaustive

Collaboration Plutôt que Négociation d'un contrat

avec le client

Adaptation au Plutôt que 1616

Suivi d'un plan
changement 16
ESPS

• Libérer le génie humain

pour l’auto-organisation dans un contexte qu’il
peut maîtriser :
• La taille de l’équipe est limitée
• le domaine du problème est limité

Petites équipes autogérées

Portée fonctionnelle restreinte à un moment donné
Garder un rythme de travail soutenable
Avancement par itération

17
ESPS

• .
Expression des besoins

Conception

Développement

Tests, recette & debugage

18
ESPS

Les solutions Agiles

• .
Expression de besoins

Conception

Développement

Tests, recette & debuggage

i1 i2 i3 in

19
ESPS

Extrait du Manifeste pour le développement Agile de logiciels.

1. Notre plus haute priorité est de satisfaire le client en livrant rapidement

et régulièrement des fonctionnalités à grande valeur ajoutée.
2. Accueillons positivement les changements de besoins, même tard dans le
projet. Les processus agiles exploitent le changement pour donner un
avantage compétitif au client.
3. Livrons fréquemment un logiciel opérationnel avec des cycles de quelques
semaines à quelques mois et une préférence pour les plus courts.
4. Les utilisateurs ou leurs représentants et les développeurs doivent travailler
ensemble quotidiennement tout au long du projet.
ESPS

5. Réalisons les projets avec des personnes motivées. Fournissons-leur

l’environnement et le soutien dont ils ont besoin et faisons-leur confiance
pour atteindre les objectifs fixés.

6. La méthode la plus simple et la plus efficace pour transmettre de

l’information à l'équipe de développement et à l’intérieur de celle-ci est
le dialogue en face à face.

7. Un logiciel opérationnel est la principale mesure d’avancement.

8. Les processus agiles encouragent un rythme de développement soutenable.

Ensemble, les commanditaires, les développeurs et les utilisateurs doivent
être capables de maintenir indéfiniment un rythme constant.
ESPS

9. Une attention continue à l'excellence technique et à une bonne conception

renforce l’agilité.
10. La simplicité (c’est-à-dire l’art de minimiser la quantité de travail inutile)
est essentielle.
11. Les meilleures architectures, spécifications et conceptions émergent
d'équipes auto-organisées.
12. À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus
efficace, puis règle et modifie son comportement en conséquence.

En résumé, cette méthodologie est mise en œuvre par des équipes

d'ingénieurs qui travaillent selon des méthodes flexibles mais rigoureuses, afin
d’apporter graduellement de la souplesse dans la production de logiciels tout
en garantissant, in fine, un excellent niveau de qualité aux utilisateurs.
ESPS

Les solutions Agiles

• Toujours focalisées sur le produit final
Une vision commune pour l’équipe
 la satisfaction du client
Découper le projet autrement
 par fonctionnalité
Organiser en cycles de développement réduits
 itérations

23
ESPS

Les solutions Agiles

• Collaboration avec le client
Pourquoi on veut des contrats ?

- Instaurer la confiance autrement

- Eviter les effets pervers d’un contrat

24
ESPS

Les solutions Agiles

• Adaptables
Réactives aux nouveaux besoins
Réceptives aux nouvelles solutions

- Prendre les décisions définitives le plus tard possible

- De courtes itérations permettent de changer de direction sans
laisser des éléments à moitié fait

25
ESPS

Agile : Planification
• L’estimation de charge est difficile, mais les
courtes itérations nous aident
– On est plus précis sur les petites tâches
– Feedback très rapide
– Plus facile à s’adapter face aux dérives, surprises

2626
26
ESPS

Exemple de méthode Agile

SCRUM

27
27
ESPS

Scrum : Caractéristiques
• Produire le maximum de valeur pour le
minimum de coût
• Besoins capturés dans un backlog de produit
priorisé par une personne
• Cycles de développement de 2 à 4 semaines
(Sprints) ; équipes autogérées
• Mêlée quotidienne
2828
28
ESPS

Scrum : Les Acteurs

• Product Owner
– Porteur de la vision globale du produit
– Gère le Backlog du Produit
– Défini des priorités
– Accepte ou Rejette les livrables

2929
29
ESPS

Scrum : Les Acteurs

• Scrum Master
– Veille au bon fonctionnement de l’équipe
• Enlève les obstacles
– Gardien des pratiques de Scrum
– Serviteur de l’équipe - Facilitateur
– N’est pas un chef de projet !

3030
30
ESPS

Scrum : Les Acteurs

• L’équipe
– 5 à 9 personnes
– Autogérée ; les décisions sont prises
collectivement
– Contient toutes les compétences nécessaires pour
terminer le sprint
– Ne change pas pendant un Sprint
3131
31
 ESPS

Le processus Scrum

Estimation Mêlée
Mêlée quotidienne
Créer un Backlog
Planification
Visualisation dududu
de l'état produit
Sprint
quotidienne
projet sous la forme
•15 minutes, tous les jours
Revue
d'unanalogie
•Par tableau
•Trois
dedu sprint
préférence
questions
•Les tâches à faire pour chacun
24 heures
Rétrospective
•L'intuition
•Géré par
•Réunion estde acceptable
le Product
l’équipe : duOwner
! sprint
décisions collectives
•Les tâches •Qu’avez-vous fait hier
en cours
•Planning
•Liste
•Définir
•les Poker
tâchesde tout
unterminéesce pour
objectif qui va entrainer du travail
le sprint
•Eviter
•Choisir
•Qu’allez-vous
•Présentation
l'influence des des
leaders faire
nouveautés aujourd’hui
d'opinion
pour•Uniquement
l’équipe
des
•Tout•Quels
éléments
le monde
du
l’équipe
estvos
Backlog
invité
de produit pour
•Collégialité
mettre dans le sont
backlog du problèmes
sprint
•Appréciation
•Constat
•Toute de ce
l’équipe de
qui a la
bien
participe valeur
oupas
– apportée
moins
justebien
le Scrum
•Recherche
•Chaque du consensus,
élément est2 – 4 semaines
et de en
découpé la propriété
taches qui sont
marché
par dans
l’élément
Master !estimationsl’organisation
•Mettre
collective
estiméesdes en
à heures
jour le (max
Backlog2 jours)
du Sprint
•Chiffré
•Informel
•La conception de façon
de haut imprécise
•Le reste à faire totalniveau
pourest le abordée
Sprint
•Les •User
tâches Stories
ne sont pas nominatives 3232
Backlog du Backlog du
Produit 32
produit sprint
 ESPS

Mêlée
quotidienne

24 heures

2 – 4 semaines

Backlog du Backlog du
Produit
produit sprint
3333
33
ESPS

LES TESTS

Écrire des scénarios de tests automatisés (qu'il s'agisse de tests unitaires

ou de tests d'intégration) constitue une étape incontournable du cycle de
développement logiciel dans un cadre professionnel.

Bien que cette tâche puisse parfois sembler rébarbative, elle reste
indispensable pour produire des développements de bonne qualité,
notamment parce que cela permet entre autres :
de s'assurer que l'on maîtrise les aspects fonctionnels de l'application (les
besoins métier à satisfaire) ;
de détecter au plus tôt les anomalies éventuelles avant la livraison d'un
projet aux utilisateurs .

3434
ESPS

LES TESTS

De détecter d'éventuelles régressions, suite à l'implémentation de

nouvelles fonctionnalités, en automatisant l'exécution de l'ensemble des
scénarios de tests implémentés sous forme de tests unitaires ou tests
d'intégration, de façon à ce qu'ils soient exécutés régulièrement (à minima
une fois par jour par exemple).

Plus l'ensemble du code de chaque module applicatif sera couvert par les
tests, plus nous serons à même de détecter les régressions, de maîtriser
l'ensemble des fonctionnalités de nos applications et ainsi de les rendre
plus maintenables.

3535
ESPS

Les tests unitaires

Il s'agit de tests permettant de vérifier le bon fonctionnement d'une

fonction précise en essayant de couvrir au maximum la combinatoire
des cas fonctionnels possibles sur cette fonction.

Le test unitaire bouchonne également l'ensemble des dépendances

auxquelles la fonction peut faire appel : base de données,
webservices, fichiers, autres fonctions…

Chaque évolution doit donner lieu à des tests unitaires sur les
fonctions ayant été créées ou à la mise à jour de ces tests s'ils existent
déjà.

3636
36
ESPS

Test d’intégration

Il s'agit ici de tests permettant de tester la bonne intégration de la

fonction dans l'ensemble du logiciel et de ses dépendances. Dans le cas
d'un test d'intégration, on ne bouchonne plus les dépendances pouvant
être appelées par la fonction, on observe au contraire si la fonction
exploite bien les résultats fournis par les dépendances ou au contraire si
elle injecte bien des données dans une ou plusieurs dépendances comme
dans le cas d'une base de données par exemple.

Parmi les tests d'intégration, on peut avoir également des scénarios

complets du logiciel correspondant à des enchaînements d'appels de
fonctions ou de webservices. Cette catégorie de tests d'intégration est
également appelée “tests bout en bout”.

3737
37
ESPS

Test de qualité

Il s'agit ici de vérifier la qualité du code à l'aide d'un certain nombre

de métriques :
fonctions inutilisées ;
constantes inutilisées ;
taux de commentaires dans le code ;
redondance dans les fonctions ;
constantes définies plusieurs fois ;

3838
38
ESPS

Livraison

Une fois les user-stories d'une itérations réalisées puis livrées, l'ensemble
du sprint fait l'objet d'une livraison au client. Celui-ci, au bout d'une ou
plusieurs livraisons d'itération(s) rentre dans un cycle de validation qui
passe par une phase de recette, une phase de préproduction, une phase de
mise en production.

3939
39
ESPS

Ainsi, les méthodes agiles sont itératives, parce que les développements sont
organisés selon des cycles courts, plutôt 15 jours ou un mois au lieu d'un ou
deux ans dans les projets classiques. Elles sont aussi incrémentales, parce que
les nouveaux développements s’ajoutent aux précédents par strates
successives.
Cette approche itérative et incrémentale est particulièrement adaptée aux
logiciels qui mettent en œuvre une interaction homme–machine, à l’instar
des applications pour smartphones, des sites web, des jeux vidéo, etc.
En effet, modifier un écran, un son, ou un dispositif haptique est
immédiatement perceptible par les utilisateurs. Les utilisateurs peuvent
donner rapidement un feedbackqui entre ainsi aisément dans la boucle
vertueuse de rétroaction propre aux méthodes agiles.
ESPS

En revanche, cette approche n'est pas pertinente pour les grands logiciels
industriels comme les protocoles de réseau, les progiciels de gestion
d’entreprise, les logiciels de contrôle-commande de machine, les logiciels
embarqués (automobile, aérospatiale, etc.).
ESPS

Conduite des projets

CHAPITRE 4
L’ORDONNANCEMENT
ESPS

Objectif
Etudier les deux méthodes d’ordonnancement GANTT
et PERT.
Éléments de contenu
Le diagramme de GANTT.
La méthode PERT.
ESPS

L’ordonnancement permet de déterminer le

planning de réalisation d’un projet à partir de la
liste des tâches élémentaires à exécuter,
connaissant leur durée et leur enchaînement.
ESPS

LE DIAGRAMME DE GANTT

Se présente sous forme d’un tableau à deux

dimensions :
- En abscisses : l’écoulement du temps depuis le
début du projet.
- En ordonnées : les tâches
Exemple :
ESPS

LA METHODE PERT(Program Evaluation and Review

Technology)

On utilise un graphe de dépendances. Pour chaque tâche, on

indique une date de début et de fin au plus tôt et au plus tard.
Le diagramme permet de déterminer le chemin critique qui
conditionne la durée minimale du projet.
ESPS

EXEMPLE :
ESPS
ESPS
ESPS
ESPS
ESPS
ESPS
ESPS

RECHERCHE DU CHEMIN CRITIQUE :

Elle se compose en quatre étapes :

1. construction du réseau
2. calcul des dates au plus tôt : on appelle date au plutôt qu’on notera DTO la date
minimale à laquelle peut être lancée une tâche donnée.
On appelle date de fin au plutôt qu’on notera FTO d’une tâche la date minimale
à laquelle peut être achevée la tâche considérée.
FTO = DTO + durée
Par convention on débute le projet à la date = 0 donc c’est la DTO de toutes les
tâches début du projet, le calcul des dates au plutôt des différentes tâches
s’effectue en partant du début du projet vers sa fin en parcourant tous les
chemins en additionnant les durées des différentes tâches et en prenant la plus
grande valeur aux intersections comme DTO du successeur.
DTO(i) = Max (FTO (antecedent(i))
La durée totale du projet est égale à la date de fin au plutôt maximale de toutes
les tâches du projet.
Durée du projet = Max (FTO)
ESPS

3. Calcul des dates au plus tard :

La date du fin au plus tard d’une tâche qu’on note FTA est la date maximale à
la quelle peut se terminer une tâche sans modifier la durée totale du projet.
La date de début au plus tard d’une tâche qu’on note DTA est la date maximale
à la quelle peut débuter sans toutefois augmenter la durée totale du projet :
DTA (i) = FTA(i) – durée (i)
FTA(i) = MIN (DTA (succ (i) )
Le calcul des dates au plus tard s’effectue en partant de la fin du projet et en
parcourant tous les chemins du projet jusqu’au début du projet.
ESPS

4. Calcul des marges :

La marge totale d’une tâche qui est notée MT est définie comme le retard
maximum pouvant être pris dans la réalisation de la tâche sans augmenter la
durée totale du projet.
MT = FTA – FTO
La marge libre d’une tâche ML est définie comme le retard maximum qui peut
être pris par une tâche sans modifier les DTO de ses successeurs et on définit
donc la marge libre d’une tâche comme étant le minimum des DTO.
ML(i) = Min [DTO (succ (i) ] – FTO (i)
Pour les tâches qui n’ont pas de successeurs: ML = durée du projet - FTO
ESPS

5. Un chemin est dit critique si et seulement si sa durée est égale à la durée

totale du projet.
On appelle tâche critique, une tâche dont la marge totale est égale à la marge
libre et est égale à zéro.
Les tâches critiques sont les tâches pour lesquelles un retard ou un
allongement de la durée de réalisation entraînerait une augmentation
équivalente de la durée totale du projet.
ESPS
ESPS
ESPS

Tâche Ant SUCC Durée Date au plus tôt Date au plus tard MT ML
DTO FTO DTA FTA
A _ 12

B D 2

C B,F 3

D A 8

E B,F 8

F A 13
ESPS
ESPS

EXERCICE : Pratique du PERT

On désire planifier un projet comprenant 13 tâches repérées de A à M.
ESPS
ESPS

Conduite des projets

CHAPITRE 5
CAHIER DES CHARGES
ESPS

Qu'est-ce qu'un cahier des charges

Définition générale:

Le cahier des charges d'un produit est un outil écrit après

l'analyse des besoins qui décrit avec précision :
Le projet relatif au produit,
Le contexte dans lequel il va être utilisé,
Les objectifs auquel il répond,
Les conditions nécessaire à la réussite du projet,
Le scénario qui va le mettre en scène,
D’une manière générales, les différents aspects suivants :
Contextuelle, économique, organisationnel, technologique
et juridique.
65
ESPS

A quoi sert un cahier des charges

Le cahier des charges est à la fois :

Un outil de communication,
De structuration,
De description du produit.

Le cahier des charges est un outil référence à différents

moments du projet :
En amont :
Il est présenté aux responsables financiers pour la demande de
budget nécessaire à l'élaboration du produit.
Pendant le développement :
Il est une pièce de référence pour le développeur .
Une fois le produit terminé, il est un élément de référence pour
le contrôle de validité du produit fourni. 66
ESPS

Contenu du cahier des charges

1. Rappel de la contribution attendue du produit, contexte et enjeux.

2. Publics visés.
3. Bénéfices attendus pour l’utilisateur.
4. Contraintes à prendre en compte.
5. Conditions de réussite d'une action de formation avec ce produit.
6. Descriptif du produit.
7. Thème développé (didacticiel, simulation, jeu de rôle, etc.).
8. Cadre pédagogique.
9. Ressources disponibles en interne pour le développement du
produit.
10. Matériel et logiciel à prévoir pour l'action de formation avec le
produit.
11. Méthodologie d'évaluation du produit.
12. Coûts.
67
13. Délais de réalisation.
14. Maintenance du produit.
ESPS

Conduite des projets

CHAPITRE 6
LE CONTRAT
ESPS

Définition :

Un contrat est un accord passé entre deux personnes ou plus

(morale ou physique) afin de réaliser quelque chose ensemble
(matériel ou immatériel).

Il peut s'agir d'un contrat financier ou d'un contrat de partenariat.

Les termes du contrat - qui, quoi, où, quand et comment - décrivent

avec précision les promesses faites par chaque partie.

Le "quelque chose" pourrait être par exemple, un package de

logiciels - ou un produit pédagogique multimédia interactif.

69
69
ESPS

Différent type de contrat

Type de contrat selon les intervenants :
Contrat classique (société de production / client) :
Déterminer les tarifs de développement et de maintenance.
Déterminer les pénalités de retard de livraison ou de règlement.
Garantir au client la propriété exclusive des droits d'auteur.
Déterminer si la société de production aura le droit de réutiliser, les
graphiques ou le schéma d'interface dans un autre produit.

Contrat en partenariat :
Déterminer un calendrier précis est fixé.
Souligner les droits d’auteur de chaque partie vis à vis du produit
fini.

Contrat interne (on vise un marché plutôt qu’un client) :

Pas nécessaire de rédiger un contrat forme. La société de
production possède les droits d'auteur de tout ce qui est produit. 70

70
ESPS

Différent type de contrat

Type de contrat selon le mode de paiement :
Régie :
Dépenses contrôlées :
 Le client achète uniquement des heures de travail et des
matériels clairement définis .
 Le fournisseur n’a pas de responsabilité quand a
l’organisation des travaux.

Coût + honoraires :
 Le fournisseur organise ses travaux, choisit ces sous-
traitants et assure le contrôle.

Forfait :
Le fournisseur s’engage est à réaliser le travail défini à un prix
forfaitaire.
71

71
ESPS

Clause incitative pour limiter le coût du projet :

Honoraires incitatifs (coût+honoraires) :

 Exemple :

 Développement forfaitaire .

PMG = Prix Maximum Garanti :

 Une variante du forfait.

 Après détermination des coût réels, l’écart par rapport au

montant forfaitaire du contrat (perte ou gain) est partagé entre le
client et le fournisseur suivant des modalités définis dans le contrat.

72

72
ESPS

Clause incitative d’u contrat

Clause incitative pour tenir les délais :

 Pénalité de retard :
 Le client se réserve la possibilité de diminuer le montant d’un
lot lorsque celui-ci a été honoré avec un retard par rapport à une
date limite définie contractuellement.

P = (V*R) * (10%) P = Montant à déduire

V = Valeur du lot
R = nombre de jours de retard

 Intéressement :
 On peut envisager le même type de formule au bénéfice du
fournisseur en cas de livraison en avance. 73

73
ESPS

Contenu d’un contrat

Cadre du contrat
 Objet du contrat et le contexte dans lequel il se situe.

Présentation et délai
 Liste des fournitures et des délais associées.

Montant du contrat
 Montant globale avec date de références des prix,
 Tranche ferme et conditionnelle.

Condition de paiement
 Faits générateurs de facturations.
 Formule de révision des prix, pénalité et intéressement.

Condition générale (Brevet,maintenance, droit d’auteur).

74
74