Plan

Conduite et gestion
de projets informatiques :
une introduction

!
!
!
!
!
!

G. Picard
SMA/G2I/ENS Mines Saint-Etienne
gauthier.picard@emse.fr
Septembre 2009

Introduction
Modles et activits de dveloppement
Avant-Projet
Suivi du projet
Clture du projet
Activits transverses

Introduction

Logiciel
! Objet immatriel pendant son dveloppement, trs facile modifier,
! Ses caractristiques attendues sont difficiles figer au dpart et souvent
remises en cause en cours de dveloppement,
! Les dfaillances et erreurs ne proviennent ni de dfauts dans les
matriaux ni de phnomnes dusure dont on connat les lois mais
derreurs humaines, inhrentes lactivit de dveloppement,
! Le logiciel ne suse pas, il devient obsolte (par rapport aux concurrents,
par rapport au contexte technique, par rapport aux autres logiciels, ...),
! Le dveloppement par assemblage de composants, des services,
dapplications nest pas encore gnralis dans le domaine logiciel
(beans, EJB, composants, ... Web services, EAI, ).

! A physician, a civil engineer and a computer scientist were

arguing about what was the oldest profession in the world.
! The physician remarked, Well, in the Bible, it says God created
Eve from a rib taken out from Adam. This clearly required surgery,
and so I can rightly claim that mine is the oldest profession in the
world.
! The civil engineer interrupted, and said, But even earlier in the
book of Genesis, it states that God created the order of the heavens
and the earth from out chaos. This was the first and certainly the
most spectacular application of civil engineering. Therefore, fair
doctor, you are wrong: Mine is the oldest profession in the world.
! The computer scientist leaned back in her chair, and then said
confidently, Ah, but who do you think created the chaos?

Gnie logiciel

Motivations

! Ingnierie du logiciel ! Software Engineering

! Ensemble de thories, de mthodes, de techniques et
doutils pour la production et la maintenance de systmes
logiciels de qualit
! Domaine des sciences de lingnieur dont la finalit est la
conception, la fabrication et la maintenance de systmes
logiciels complexes, srs et de qualit (Software
Engineering)
! Art de la fabrication collective dun systme complexe,
concrtise par un ensemble de documents de conception,
de programmes et de jeux de tests avec souvent de
multiples versions.

! Rpondre la crise du logiciel apparue dans les annes 70

(prise de conscience que le cot du logiciel dpassait le
cot du matriel)
! Rpondre la croissance de la taille et de la complexit des
systmes
! besoins et fonctionnalits augmentent, voluent
! technologies en perptuelle volution
! diversification des architectures

! Faire face aux dlais de plus en plus courts,

! Grer des quipes de plus en plus grosses, avec des
comptences multiples

Proccupations

Qualit du logiciel : facteurs externes

! Correction (validit) : aptitude rpondre aux besoins et remplir les
fonctions dfinies dans le cahier des charges
! Robustesse (fiabilit) : aptitude fonctionner dans des conditions non
prvues au cahier des charges, ventuellement anormales
! Extensibilit : facilit avec laquelle de nouvelles fonctionnalits peuvent
tre ajoutes un logiciel
! Compatibilit : facilit avec laquelle un logiciel peut tre combin avec
d autres
! Efficacit : utilisation optimale des ressources matrielles (processeur,
mmoires, rseau, )
! Convivialit : facilit d apprentissage et d utilisation, facilit de
prparation des donnes, facilit de correction des erreurs d utilisation,
facilit d interprtation des rsultats
! Intgrit (scurit) : aptitude d un logiciel protger son code contre
des accs non autoriss.

! Lindustrialisation de la production du logiciel :

! organisation des procds de production (cycle de vie, mthodes,
notations, outils), organisation des quipes de dveloppement,
tablissement de plan qualit rigoureux, etc.

! Des principes :
! Rigueur et formalisation, Sparation des problmes, Modularit,
Abstraction, Anticipation des changements, Gnricit, Construction
incrmentale
! Rgle du CQFD (Cot Qualit Fonctionnalits Dlai)
! Le systme qui est fabriqu rpond aux besoins des utilisateurs
(correction fonctionnelle).
! La qualit correspond au contrat de service initial.
! Les cots restent dans les limites prvues au dpart.
! Les dlais restent dans les limites prvues au dpart.
7

Qualit du logiciel : facteurs internes

Etat des lieux

! R-utilisabilit : Aptitude d un logiciel tre rutilis, en tout

ou en partie, pour d autres applications
! Vrifiabilit : aptitude d un logiciel tre test (optimisation
de la prparation et de la vrification des jeux d essai)
! Portabilit : aptitude d un logiciel tre transfr dans des
environnements logiciels et matriels diffrents
! Lisibilit,
! Modularit.

http://www.standishgroup.com/sample_research/chaos_1994_1.php

10

Les mythes du logiciel

Mythes de lusager

Mythes du logiciel
! Mythes du client ou usager

Mythe
! Un nonc gnral des objectifs
est suffisant pour commencer.
On verra les dtails plus tard.

Ralit
! Une dfinition insuffisante des
besoins des utilisateurs est la
cause majeure dun logiciel de
mauvaise qualit et en retard

! Les besoins du projet changent

continuellement, mais ces
changements peuvent tre
facilement incorpors parce que
le logiciel est flexible

! Les cots dun changement pour

corriger une erreur augmentent
dramatiquement dans les
dernires phases de la vie dun
logiciel

! Mythes du dveloppeur
! Mythes des gestionnaires

11

12

Les mythes du logiciel

Mythes du dveloppeur
Mythe
! Une fois que le programme est
crit, et marche, le travail du
dveloppeur est termin

Ralit
! 50%-70% de leffort consacr
un programme se produit aprs
sa livraison lusager

! Tant quun programme ne

fonctionne pas, il ny a aucun
moyen den mesurer la qualit

! Les revues de logiciel peuvent

tre plus efficaces pour dtecter
les erreurs que les jeux dessais
pour certaines classes derreurs
! ....

! Pour le succs dun projet, le

bien livrable le plus important est
un programme fonctionnel

Les mythes du logiciel

Mythes du gestionnaire
Mythe
! Lentreprise possde des
normes, le logiciel dvelopp
devrait tre satisfaisant

! Les ordinateurs et les outils

logiciels que lentreprise possde
sont suffisants

Ralit
! Une configuration de logiciel
inclue de la documentation, des
fichiers de rgnration, des
donnes dentre pour des tests,
et les rsultats des tests sur ces
donnes
! ....

! Si le projet prend du retard, on

ajoutera des programmeurs
13

14

Matriser le dveloppement

Conduire le dveloppement

! Utiliser des techniques dindustrialisation

(cf. calculettes, micros)
! Concevoir chaque logiciel comme une brique dun projet (=
travailler en mode projet)
! Les aspects dvaluation des cots et mtrologie sont
fondamentaux (CMM, ISO, SPICE,...)

!
!
!
!
!
!
!
!
!
!
15

Simposer des processus formels de dveloppement

processus dassurance qualit
des points de contrle (milestones)
mthode structure, phase
des produits finis en fin de phase: inspection et validation
aprs chaque phase du dveloppement
automatis
adaptable
processus formel et exhaustif de tests
technologie jour (objets, Java, AGL,...)

16

Projet informatique

Acteurs dun projet (1)

! Ensemble dactions mises en uvre, afin de produire les

rsultats et fournitures dfinies en rponse aux objectifs
clairement dfinis
! dans des dlais fixs (date dbut et date de fin)
! mobilisant des ressources humaines et matrielles
! possdant un cot prvisionnel et des gains esprs

! Matrise douvrage : personne physique ou morale

propritaire de louvrage. Il dtermine les objectifs, le budget
et les dlais de ralisation.
! Matrise duvre : personne physique ou morale qui reoit
mission de la matrise douvrage pour assurer la conception
et la ralisation de louvrage.

qualit
Espace
projet
cots

dlais
17

Acteurs dun projet (2)

! Le Commanditaire
! Le Client
! Le comit directeur
(moyen et gros projet)
!
!
!
!
!
!
!
!
!

Le chef de projet
Lquipe projet
Les experts
Le planificateur
Lorganisateur
Le contrleur
Linnovateur
Linvestigateur
Les utilisateurs

18

Conduite de projet (1)

Organisation mthodologique mise en uvre pour faire en
sorte que louvrage ralis par le matre duvre rponde
aux attentes du matre douvrage dans les contraintes de
dlai, cot et qualit.

Matrise douvrage

Besoins

Solutions
Projet

Satisfaction des
Besoins

Matrise duvre
Conduite
de
Projet
19

20

Conduite de projet (2)

Conduite et gestion de projet

! Processus difficile matriser

Conduite de
projet
Analyse et reporting

!! Facteurs de risque :
! cots et les dlais respecter
! technologies matriser
! ressources humaines grer

Synthse et dcisions

!! Pour rduire ces risques :

Gestion des
hommes

Gestion
technique

Gestion des
Moyens

Organisation
Communication
Animation

Objectif
Mthode
Qualit

Planification
Contrle
Cots Dlais

! Dfinir des principes de base, communs lensemble des projets afin de

clarifier la terminologie
! Coordonner les intervenants
! Veiller la cohrence des diffrentes activits

21

22

Conduite et gestion de projet

Modles

Conduite et gestion de projet

! La conduite de projet se situe 2 niveaux

1)! bass sur les livrables : modles linaires

! lors de la conception : fixer les objectifs, la stratgie, les moyens,

lorganisation et le programme daction
! lors de la ralisation : sassurer du bon droulement du projet, de la
qualit, du respect des dlais et des budgets, faciliter les travaux de
mise en uvre et de maintenance

! Le processus de dveloppement est divis en tapes

indpendantes, conscutives ou non
! Chaque tape donne lieu une revue et produit un document

2)! bass sur le risque : modle en spirale

! Le modle en spirale de Boehm met en uvre une valuation
rgulire des risques lis au projet permettant la mise en uvre de
solutions techniques pour annihiler ou contrer ces risques. Cette
valuation englobe les autres approches :
!! Un cycle de spirale utilise :
! un modle de dveloppement en cascade (quand un risque
dintgration est identifi)
! le prototypage quand le risque est li lacceptation de linterface
utilisateur par le client, par exemple

23

24

Conduite et Gestion de Projet

Rfrentiels

Conduite et gestion de projet

Rfrentiels

! La fabrication dun logiciel de qualit respectant les

contraintes de budget et de dlais ncessite :
A
R
C
H
I
T
E
C
T
U
R
E

! le choix dune architecture

! la mise en uvre de mthodes, de techniques, de
standards, des normes et des outils en vigueur au sein
de lorganisation

! Ces mthodes, techniques, standards, normes,

outils concernent aussi bien :
! la production de composants logiciels (dfinition des
besoins, conception, ralisation, tests,...)
! le contrle (planification, valuation,...) du processus de
production

E
V
A
L
U
A
T
I
O
N

Cycles de vie

Mthodes de dveloppement

Outils

Communication

25

26

Cycle de dveloppement
Phases

Cycle de dveloppement
Itrations (1)

temps

Prelim
Iteration

Vision
!
!
!
!

!
!

Architecture

Premires
fonctionnalits

...

Arch
Iteration

...

Cons
Cons
Iteration Iteration

...

Trans
Iteration

...

Livraison
Produit

Pr-tude : Dfinition de la porte du projet et dveloppement des cas

Vision : Glossaire, Dtermination des parties prenantes et des utilisateurs, Dtermination
de leurs besoins, Besoins fonctionnels et non fonctionnels, Contraintes de conception
Elaboration : Planification du projet, spcification des caractristiques, des fondements de
larchitecture
Architecture : Document darchitecture Logicielle, Diffrentes vues selon la partie
prenante, Une architecture candidate, Comportement et conception des composants du
systme
Construction : Construction du produit
Transition : Prparation du produit pour les utilisateurs

Release

Release Release Release Release Release

Release

Release

Une itration est une squence dactivits selon un plan prtabli et des critres dvaluation, rsultant en un produit
excutable

27

28

Cycle de dveloppement
Itrations (2)
Enchanement des
Activits dIngnierie

Une itration
dans la phase
d'laboration

Phases
Pr-tude Elaboration

Cycle de dveloppement
Intervenants
Gestionnaire du Projet

Construction

Transition

Modlisation Mtier

Montage
du projet

Recueil des besoins

Clture
du projet

Gestion du projet

Analyse & Conception

Implmentation
Test

temps

Dploiement

Vision
Configuration Mgmt
Management
Environment

Enchanement des

Preliminary
Iteration(s)

Iter.
#1

Iter.
#2

Iter.
#n

Iter. Iter.
#n+1 #n+2

Iter.
#m

Premires
fonctionnalits

Livraison
Produit

Iter.
#m+1

Spcialistes techniques

Iterations

activits Support

Architecture

29

Gestion de projet
Mise en uvre
ORGANISER

Conduite et gestion de projet

Causes de difficults
! Qualit du produit, Estimation des risques,
Mesures, Estimation du cot, chancier,
! Relation avec le client, Encadrement,
! Autres ressources, Contrle du projet,
! Communication

Replanifier si ncessaire

PLANIFIER
QUOI ?
COMMENT ?

MESURER

QUI ?

! Fred Brooks remarque dans son livre The mythical

man-month que sil y a n employs sur un projet: on a
n(n-1)/2 besoins de communication

QUAND?
COMBIEN?

Rfrentiel
Ralisations

EXECUTER

30

Ecarts

! Humains

CONTROLER
Prendre des
actions
correctrices
31

! + un projet est vaste et complexe , + la conduite de projet

sloigne du domaine de la technique pour se rapprocher
de celui des relations humaines
32

Plan
!
!
!
!
!
!

Modles de dveloppement

Introduction
Modles et activits de dveloppement
Avant-Projet
Suivi du projet
Clture du projet
Activits transverses

! Organiser les diffrentes phases du cycle de vie pour

l'obtention d'un logiciel fiable, adaptable et efficace
! Guider le dveloppeur dans ses activits techniques
! Fournir des moyens pour grer le dveloppement et la
maintenance (ressources, dlais, avancement, etc.)
! Plusieurs modles sont proposs :
!
!
!
!
!
!

Modle code-and-fix
Modle (linaire) en cascade
Modle en V
Modle en spirale
...
Processus unifi

33

34

Modle en cascade

Modle en cascade
Expression
des besoins

! Atteinte de lobjectif par atteinte ordonne de sous

objectifs. Les activits sont reprsentes dans des
processus spars.
! Processus squentiel: Chaque tape doit tre termine
avant que la suivante commence.
! Livrables:

Analyse
Conception

! la fin de chaque tape, le livrable est vrifi et valid.

! Vrification: le livrable est-il correct ?
! Validation: est-ce le bon produit ? (Compar lnonc de ltape).

Implmentation
Tests
Maintenance

35

36

Modle en V

Modle en V

! Amlioration du modle en cascade

! Met en vidence la symtrie et la relation quil y a entre les
phases du dbut du cycle de vie et celles de fin.
! Les phases du dbut doivent tre accompagnes dune
planification des phases de fin
! Lors de la planification, on dveloppe et documente les
plans de test.

Expression
des besoins

Validation
des besoins

Analyse et
spcification

Validation
fonctionnelle

Conception
du systme

Tests du
systme

Conception
des composants

Tests des
composants

Implmentation
37

38

Modle en spirale

Modle en spirale

! Mise de laccent sur lvaluation des risques.

! A chaque tape, aprs avoir dfini les objectifs et les
alternatives, celles-ci sont values par diffrentes
techniques (prototypage, simulation, ...), ltape est ralise
et la suite est planifie.
! Le nombre de cycles est variable selon que le
dveloppement est classique ou incrmental.

Analyse
Conception

Spcifications

Implmentation

Validation
Tests

39

40

Processus unifi

Processus unifi

! Regroupement des activits mener pour le dveloppement dun

systme logiciel, bas sur la notion dobjets.
! Pilot par les cas dutilisation (bien comprendre les dsirs et les besoins
de ses futurs utilisateurs)
! Un cas d'utilisation est une fonctionnalit du systme produisant un rsultat
satisfaisant pour l'utilisateur. Les cas d'utilisation saisissent les besoins
fonctionnels et leur ensemble forme le modle des cas d'utilisation qui dcrit
les fonctionnalits compltes du systme.

! Centr sur larchitecture (les diffrentes vues du systme qui doit tre
construit)
! Itratif et incrmental
! Itratif : croissance et laffinement successifs dun systme par le biais
ditrations multiples, retours en arrire et adaptation cycliques
! Incrmental : dcoupage du travail en plusieurs parties qui sont autant de
mini-projets. Chaque mini-projet reprsente une itration ou tape de courte
dure (1 mois) qui donne lieu un incrment. Le rsultat de chaque itration
est un systme test, intgr et excutable.
41

42

Activits de dveloppement

Planification

! Elles sont dcrites de faon indpendante en indiquant leur

rle, utilisent et produisent des artefacts
! Selon le modle, une activit peut jouer un rle plus ou
moins important et parfois ne pas exister du tout.
! Elles concernent :
!
!
!
!
!
!
!
!

! Objectifs :
! identification de plusieurs solutions et valuation des cots et
bnfices de chacune d'elles

! Activits :
! simulation de diffrents scnarios de dveloppement

! Rsultats :

Planification (tude de la faisabilit)

Spcification des besoins (Requirement analysis)
Analyse (Spcification formelle)
Conception (Spcification technique)
Implmentation (Codage) et tests unitaires
Intgration et tests densemble
Livraison
Maintenance

! Rapport danalyse prliminaire et un schma directeur contenant :

! la dfinition du problme et les diffrentes solutions tudies, avec, pour
chacune delles, les bnfices attendus, les ressources requises (dlais,
livraison, etc.)

43

44

Spcification des besoins

Analyse

! Objectifs :

! Objectifs :

! dfinition de ce que doit faire le logiciel

! Analyse dtailles de toutes les fonctions et autres caractristiques

que le logiciel devra raliser pour lusager, telles que vues par lusager.

! Activits :

! Activits :

! Description du problme traiter afin didentifier les besoins de

l'utilisateur, de spcifier ce que doit faire le logiciel : informations
manipules, services rendus, interfaces, contraintes
! Mise en uvre des principes : abstraction, sparation des
problmes, sparation des besoins fonctionnels

! Rpondre au Que fait le systme ? , Modlisation du domaine

dapplication
! Analyse de l existant et des contraintes de ralisation
! Abstraction et sparation des problmes, sparation en units
cohrentes

! Rsultats : cahier des charges et plan qualit

! Rsultats : Dossier danalyse et plan de validation

! un dossier d'analyse comprenant les spcifications fonctionnelles et non

fonctionnelles du produit
! une bauche du manuel utilisateur pour les non informaticiens
! une premire version du glossaire contenant les termes propres au
projet.
! un plan de test du futur systme (cahier de validation)

!
!
!
!

Modle du domaine
Modle de lexistant (ventuellement)
Dfinition du modle conceptuel.
Plan de validation, dossier de tests d intgration

45

46

Implmentation

Conception
! Objectifs :

! Objectifs :

! Dfinition de larchitecture gnrale du logiciel. Spcification de la manire

dont chacun des composants du logiciel sera ralis et comment ils
interagiront.

! Ralisation des programmes dans un (des) langage(s) de

programmation
! Tests selon les plans dfinis lors de la conception

! Activits :

! Activits :

! Rpondre au Comment raliser le systme

! Dcomposition modulaire, dfinition de chaque constituant du logiciel :
informations traites, traitements effectus, rsultats fournis, contraintes
respecter

! traduction dans un langage de programmation,

! Mise au point (dboguage)

! Rsultats : dossiers de programmation et codes sources.

! Rsultats : dossier de conception + plan de test global et par module

! proposition de solution au problme spcifi dans lanalyse
! organisation de lapplication en modules et interface des modules (architecture
du logiciel),
! description dtaille des modules avec les algorithmes essentiels (modle
logique)
! structuration des donnes.
47

! Collection de modules implments, non tests

! Documentation de programmation qui explique le code

48

Tests unitaires

Intgration et test du systme

! Objectifs :

! Objectifs :

! test spar de chacun des composants du logiciel en vue de leur

intgration

! Intgration des modules et test de tout le systme

! Activits :

! Activits :

!
!
!
!

Assemblage de composants tests sparment

Dmarche dintgration (ascendante, descendante ou les deux)
Conception des donnes de tests
Tests Alpha : l'application est mise dans des conditions relles
d'utilisation, au sein de l'quipe de dveloppement (simulation de
l'utilisateur final)
! Documentation des lments logiciels

! ralisation des tests prvus pour chaque module

! les tests sont faire par un membre de l'quipe n'ayant pas particip
la fabrication du module

! Rsultats :
! rsultats des tests avec les jeux dessais par module selon le plan de
test.

! Rsultats :
! Rapports de test
! Manuel dutilisation
49

50

Livraison, maintenance, volution

Plan
! Introduction
! Modles et activits de dveloppement
! Avant-Projet

! Objectifs :
! Livraison du produit final l'utilisateur,
! Suivi, modifications, amliorations aprs livraison.

! Activits :

! Estimation
! Planification

! Tests Bta : distribution du produit sur un groupe de clients avant la

version officielle,
! Livraison tous les clients,
! Maintenance : corrective, adaptative, perfective.

! Suivi du projet
! Clture du projet
! Activits transverses

! Rsultats : la version finale du manuel utilisateur, les traces

dvolution du systme, les rapport dexploitation
! Produit et sa documentation
! Trace dexploitation et dvolution

51

52

Planification

Planification
! Outil incontournable pour la gestion du projet
! Il permet de :
!
!
!
!
!
!
!

dfinir les travaux raliser

fixer des objectifs
coordonner les actions
matriser les moyens
diminuer les risques
suivre les actions en cours
rendre compte de l'tat d'avancement du projet

53

54

Planification structurelle
Etapes

Planification structurelle
! Rle :

! Planification structurelle sommaire

! Identifier les travaux complter

! Traduire la dfinition du projet en une liste de tches accomplir
! prparer une liste exhaustive, documente et structure des travaux
dont laccomplissement est ncessaire la production des biens
livrables du projet

! Subdiviser le projet en lots de travail

! Un lot = un bien livrable du projet
! Toujours prvoir les lots de support pour tches ponctuelles

! Planification structurelle dtaille

! Subdiviser les lots de travail principaux
! Jusqu lidentification de tches lmentaires
! Reprsentation laide dun organigramme de tche (Work
Breakdown Structure)

!! Constitution dune base de donnes des travaux

! Sert de base aux autres tapes de planification
! Principal instrument de communication entre les intervenants

! Identification et description des lots de travail principaux

! Identification et description des tches lmentaires

! Conformit et compltude

55

! On doit avoir suffisamment confiance dans le caractre exhaustif de

la liste des tches pour tre assur que, une fois complte de faon
suffisante chacune des tches lmentaires y apparaissant, le
produit vis est effectivement ralis et conforme aux exigences
initiales

56

Planification structurelle
Product Breakdown Structure
Fait partie
de

Planification structurelle
Work Breakdown Structure
Dfinition
S-systme 2

Est-compos
de

Systme

Dfinition
systme
Ralisation
S-systme 1

Sous-systme 1

Sous-systme 2

Sous-systme 3

Ralisation
S-systme 2

Projet

Ralisation
S-systme 3
Intgration
systme

Ensemble 1

Ensemble 2

Ensemble 3

Dcoupage du systme en units physiques hirarchises

Ralisation
Ensemble 21
Ralisation
Ensemble 22
Ralisation
Ensemble 23
Intgration
S-systme 2

Dfinition
Ensemble 21
Ralisation
Ensemble 21
Intgration
Ensemble 21
Dfinition
Ensemble 22
Ralisation
Ensemble 22
Intgration
Ensemble 22
Dfinition
Ensemble 23
Ralisation
Ensemble 23
Intgration
Ensemble 23

Description structure de toutes les tches du projet,

Rapportes au dcoupage du produit
57

58

Planification oprationnelle

Planification oprationnelle
! Rle

! Toute tche est assigne une personne

! Tout participant est inform de :

! Crer un rseau ordonnanc dactivits partir des tches de

lorganigramme technique
! Estimer de la dure dune activit et des ressources requises pour la
complter
! Identifier le chemin critique dans un rseau ordonnanc et calculer les
marges totales, libres et dindpendance
! Utiliser les diffrents modes de prsentation des rsultats

! ses rles et responsabilits

! son degr dautonomie et dautorit
! des rles et responsabilits des autres

! Donnes de dpart :
! Organigramme technique
! Processus de dveloppement

! Caractristiques
! Forme la base pour la planification et la prdiction dun projet
! Facilite le choix des ressources pour complter un projet lintrieur des
chanciers et du budget
! Fournit les renseignements ncessaires pour prendre des dcisions.
! Identifie les dpendances entres les activits
! Identifie le chemin le plus long : le chemin critique
! Permet deffectuer lanalyse des risques dchancier
59

60

Planification oprationnelle

Planification oprationnelle

Df. Syst.

! Organisation dans le temps des activits

Ral. S-syst. 1

! Activits/Dpendances :

Df. S-syst. 2

! Contraintes temporelles entre activits,

! Structure logique des activits
Ensemble 21

Ensemble 22

! Ressources associes aux activits

! Dure dune activit : dure dans le meilleur des cas,
ajout dun dlai de garantie, pondration pour tenir
compte de limprvu

Ral. S-syst. 2

Ensemble 23

! La planification est un processus dynamique tenant

compte de la situation relle, des nouvelles
informations acquises

Intgration s-syst 2
Ral. S-syst. 3
Intgration syst.

t
61

Planification oprationnelle

62

GanttProject

! Diagramme Pert
! Graphe ordonn dcrivant les contraintes de prcdence
logique des activits
!
!
!
!

Lister les tches

Indiquer la charge de chacune
Prciser les liens de dpendance entre tches
Classer les tches selon leur rang

! Diagramme de Gantt
! calendrier sur lequel chaque activit est reprsente par
une barre grise dbutant la date de dbut au plus tt
et terminant la date de fin au plus tard, sur laquelle
glisse une barre blanche correspondant aux dates relles
de dbut et de fin

http://ganttproject.biz/
63

64

Estimations (1)

Estimations (2)

! Pourquoi ?

! Qualit de lestimation

! Connatre le cot dune vue de lesprit qui deviendra ralit au bout dun
temps fini

! Rendue dans les dlais, homogne en prcision,

honnte, complte, hypothses explicites, raliste,
proche du cot rel

! Quoi ?
! Leffort de dveloppement (cot), la dure du projet (temps), autre
(quipement, voyage, formation), ajouter (la logique des calculs, les
hypothses)

! Qualits de lestimateur
! Utile au client, organis, objectif, comptent, cratif,
raliste, manie lanalogie

! Quand ?
! Tout au long du cycle de vie du projet

! Piges viter

! Limites

!
!
!
!

Faire trop prcis (" travailler avec des marges derreur importantes)
Sous-estimer (" tre exhaustif dans la liste des choses estimer)
Sur-estimer (" ne pas intgrer systmatiquement tous les cots possibles)
Confondre objectif et estimation (" rsister il ne faut pas que a cote
plus de )
! Vouloir tout estimer (" savoir avouer son ignorance)

! manque de donnes historiques pour faire l'estimation,

nouvelles technologies, manque d'exprience en
estimation, oublis, productivit n'est pas 40 heures/
semaine , optimisme non fond
65

66

Estimation
Dmarche et conseils

Estimation
Mthodes
!

! Dmarche

! Exploration des expriences passes, catalogue des projets et estimations passes. Ce qui est
analys concerne : taille, dure, effort, complexit, cot

! Entres : objectifs techniques, objectifs de dlais, environnement, priode,

historique, rfrences
! Sorties : estimation
! Itrations : augmenter linformation et comparer avec le rsultat

Modle paramtrique
! Les estimations sont bases sur des modles mathmatiques reposant sur divers paramtres :
COCOMO, SLIM, PRICE-S, SoftCost,

! Conseils
!
!
!
!
!
!
!
!
!

Par analogie

Oracle

PERT

! Equipe dexperts, atteinte dun consensus par ngociation

Toute information est bonne prendre et classer

Les projets dj raliss sont la meilleure source (" tableau de bord)
Exploiter les offres de ses fournisseurs
Adhrer aux associations professionnelles
Lire les revues spcialises de sa profession
tre organis, tre cratif, affter ses outils
Constituer une check-list
Vrifier ses estimations
Remettre jour ses donnes

! Estimations reposant sur lhypothse dune rpartition normale des estimations

! Raliser plusieurs estimations avec une mthode par analogie ou oracle " la pire (l), la
moyenne (m), la meilleure (h)
! Effort = (l+4m+h)/6

Bottom-up
! Les estimations par analogie, PERT, paramtrique, oracle sont faites par activit ou composant
lmentaire
! Puis consolides jusquau sommet du projet

Aucune technique nest meilleure ou pire que les autres.

! Utiliser plusieurs techniques en parallle et comparer les rsultats : si trop de diffrence,
augmenter la quantit dinformations prises en compte.

67

68

Estimation
Taille du logiciel

Estimation
Types de fonctionnalits
! Input (entre utilisateur)

! Point fonction mesure du montant de fonctionnalit en

sappuyant sur :

! Entre de donne ou de contrle qui requiert un traitement

! crans, transactions, fichier de donnes, etc.

! 5 type de fonctionnalits :

! Output (sortie utilisateur)

! Input, Output, Inquiry, Internal Logical File, External Interface File

! Sortie de donne ou de contrle aprs un traitement du systme

! crans, transactions, fichier de donnes, etc.

! FC = nombre de fonctions
! Ajuster selon leur complexit ci partir de 14 facteurs nots
de 0 (pas dinfluence) 5 (fondamental)

! Internal files (fichiers internes)

! Regroupement logique de donnes ou de contrle interne au systme
! Bases de donnes, rpertoires, etc.

! Communication par message, distribution de donnes ou de

fonctions, haut taux de transaction, calcul complexe, conception
multi-sites, conception facilement maintenable,

! FP = FC * PCA
! KLSL = -5 + 0,2 FP

! External interface files (fichiers externes)

! Fichier ou excutable qui sortent des limites du systme
! Bibliothques, bases de donnes externes, paquetages gnriques, etc.

PCA = 0,65+0,01 Somme(ci)

! Inquiry (requtes)

69

Estimation
Facteurs dinfluence
! Interconnections
! Distribution des
fonctions
! Performance
! Utilisation
oprationnelle lourde
! Taux de transaction
! Entre de donnes en
ligne
! Facilit dutilisation

!
!
!
!
!
!
!

! Entre ou sortie d'une requte demandant une rponse immdiate du

systme
! Interruptions, appels, etc.

70

Effort ? Dure ? Taille ?

! Effort ou charge : quantit de travail ncessaire,
indpendamment du nombre de personnes qui vont raliser
ce travail

Mise jour en ligne

Traitements complexes
Rutilisation du code
Facilit d'installation
Facilit d'opration
Sites multiples
Flexibilit

! Permet dobtenir un cot prvisionnel

! Sexprime en homme/jour, homme/mois ou homme/anne
! Un homme/mois (HM) reprsente lquivalent du travail dune
personne pendant un mois, gnralement 20 jours
! Un homme/mois (HM)=152 heures de travail par mois

! Exemple: Un projet de 60 mois/homme reprsente

lquivalent du travail dune personne pendant 60 mois. Si
on value le cot du mois/homme 50 K! en moyenne, le
projet sera estim 3 M!

71

72

Effort ? Dure ? Taille ?

!
!
!
!
!
!

Effort ? Dure ? Taille ?

On mesure la taille des projets leur charge

Si Charge < 6 HM : trs petit projet
Si 6 HM< Charge <12 HM : petit projet
Si 12 HM< Charge <30 HM : projet moyen
Si 30 HM < Charge < 100 HM : grand projet
Si Charge > 100 HM : trs grand projet

La dure dpend du nombre de personnes

! 60 HM peut correspondre
!
!
!
!

1 personne pendant 5 ans

5 personnes pendant un an
10 personnes pendant 6 mois
60 personnes pendant 1 mois

73

74

Estimation
COCOMO

Effort ? Dure ? Taille ?

http://sunset.usc.edu/research/cocomosuite/index.html
! Modle paramtrique
! Hypothse : les besoins du logiciel sont relativement
stables, le projet est gr la fois par le client et par le
fournisseur
! Formule destimation : Effort = A (KLSL)b

! Homme-mois = unit de mesure de leffort

! Un homme pendant un mois
! Deux hommes-mois = 2 hommes pendant 1 mois, ou 1
homme pendant deux mois

! Selon Brooks : Lhomme-mois comme unit pour

mesurer la taille dun travail est un mythe
dangereux et trompeur. Il implique que les hommes
et les mois sont interchangeables. Les hommes et
les mois sont des biens interchangeables
seulement lorsquune tche peut tre partitionne
entre plusieurs employs sans quil faille une
communication entre eux .

! KLSL : Kilo Lignes Sources Livres : ligne source quelque soit le

nombre dinstructions par ligne, sans tenir compte des commentaires
ni du logiciel support
! A et b estimes partir de lanalyse des historiques
! A et b dpendent des trois classes de projet
! Organique : petites quipes (faible communication, distribution efficace
du travail, ), environnement stable, applications bien comprises
! Semi-dtach : quipe de taille moyenne (personnes exprimentes
dbutants), problmes ne sont pas tous matriss
! Dtach : grande quipe, rpartie, nouvel environnement
75

76

Estimation
COCOMO (simple)

Estimation
COCOMO (intermdiaire)
! Point de dpart : HM et TDEV du modle simplifi
! Introduction de quinze facteurs correctifs, valus de VeryLow XtraHigh

1200

! HM : Homme-mois = 152 h

1000
800

organique

HM

! Organique : HM = 2,4 (KLSL)1,05

! Semi-dtach : HM = 3,0 (KLSL)1,12
! Dtach : HM = 3,6 (KLSL)1,20
! Attention : nombre de personnes employes sur un projet
nest pas uniforme pendant le temps de dveloppement
600

semi-dtach

400

dtach

! Pour le projet :

200

0
10
20
30
40
50
60
70
80
9
100
110
120
0
KLSL

! Effectif crot jusqu limplmentation,

dcrot ensuite

TDEV

25
20

organique

15

semi-dtach
dtach

10
5

! Contraintes de temps dexcution

! Contraintes de place mmoire
! Stabilit de la machine virtuelle
(matriel + logiciel) sur lequel le
logiciel est dvelopp
! Systme de dveloppement
interactif ou non

!
!
!
!
!

Aptitude lanalyse
Exprience du domaine
Exprience de la machine virtuelle
Aptitude la programmation
Exprience du langage

! Pour les mthodes

! Mthode de programmation
moderne
! Outils logiciels
! Dure de dveloppement

60

80

100

40

0
20

! Organique : TDEV = 2,5 (HM)0,38

! Semi-dtach : TDEV = 2,5 (HM)0,35
! Dtach : TDEV = 2,5 (HM)0,32

! Pour les contraintes de

lenvironnement

30

mois

! TDEV : temps de dveloppement

! Pour le personnel

! Fiabilit requise du logiciel

! Taille de la base de donnes
! Complexit du produit

KLSL

77

Plan
!
!
!
!
!
!

78

Suivi de projet

Introduction
Modles et activits de dveloppement
Avant-Projet
Suivi du projet
Clture du projet
Activits transverses

79

80

Suivi de projet

Suivi de projet

! Mettre en place un processus de suivi et de revues

rgulires entre le chef de projet et les membres de
l'quipe
! Un "journal de bord" est tenu jour. Il permet de
garder une trace :

! Cette fonction consiste valuer la situation relle du projet,

la comparer la situation prvue au plan dexcution et
prendre les dcisions ncessaires pour corriger la situation,
si des carts sont observs ou prvus
! La matrise des ressources et la gestion de la qualit du
produit :

! des informations communiques

! des problmes rencontrs
! des dcisions prises
! des responsables dsigns pour mener bien les
actions
! la date de ralisation de l'action

! sont des fonctions en cours de ralisation du projet quelle que soit la

phase atteinte dans la progression du projet
! impliquent une base de comparaison que constitue le plan de
ralisation, produit de la planification du projet et de lutilisation des
ressources

81

Matrise des ressources

82

Contrle

! La matrise des ressources implique :

! Activit dacquisition des informations sur la

progression du projet

! capacit dexpliquer les difficults rencontres au plan technique

! capacit dexpliquer les retards et les dpassements de cot
! capacit de proposer des mesures correctives, den valuer les
rpercussions et de les mettre rapidement en uvre
! capacit rpondre des conditions changeantes du milieu (le
projet, son environnement)

! Ce qui est complt

! Les ressources effectivement utilises
! La date de dbut et de fin

! Ce qui en en cours : % d avancement

! Cette capacit demande davoir des points de repre

! La date de dbut, ressources utilises : matriaux,

quipement, main duvre

! Cest la planification du projet

! Questions rsoudre:
! Quoi documenter ? quelle frquence ?
! Avec quelle rsolution ? Problmes rencontrs ?
83

84

Suivi de lavancement
Analyse

Suivi de lavancement
Causes dcart (1)
! Performance technique

! But : vrifier si la situation actuelle est telle que prvue

! Compilation des informations recueillies

! Occurrence d un problme technique imprvu

! Difficults techniques majeures dont la mise en relation de diverses
composantes
! Problme de fiabilit dans les matriaux, les quipements achets
! Changement impos par le client
! Apparition d un nouveau produit sur le march
! Rvision des spcifications techniques

! Calcul des cots effectivement engags et dbourss

! Validation de l estim du % d avancement
! Nature exacte des problmes rencontrs (recherche des causes

! Analyse prvisionnelle - valeur acquise

! Comparaison avec la situation prvue

! Cots

! Slection de mesures correctives

! Difficult de financement
! Difficults techniques imposant l utilisation de plus de ressources humaines
ou d quipement
! Majoration des cots des matriaux, de la main-duvre, de lnergie, etc.
! Monitoring erron
! Dlai dans la mise en uvre des mesures correctives
! Estimation initiale incorrecte

! Proposition et analyse de l effet de mesures correctives

! Recommandations

85

Suivi de lavancement
Causes dcart (2)

86

Suivi de lavancement
Conseils lmentaires

! chanciers

! Toujours donner lheure juste

! Sassurer que le cot du contrle, de lanalyse et de la mise
en uvre demeure infrieur aux bnfices esprs du suive
et du contrle des ressources
! Ne prendre que les informations pertinentes la matrise
des ressources et de la qualit du produit
! Vrifier que le contrle et lanalyse se font rapidement pour
que les mesures correctives demeurent dactualit
! Organiser le contrle autour des biens livrables

! Dure plus longue que prvue pour complter une activit, pour rsoudre un
problme technique
! Dure requise pour rsoudre un problme nouveau
! Mauvaise estimation de la dure des activits raliser
! Pnurie de ressources humaines, matrielles et dquipement
! Rpercussions des retards de ralisation des activits qui prcdent sur la
dure des activits venir, sur leur programmation, etc. (Boucle de
rtroaction positive)

! Mise en uvre
! Approbation des mesures retenues
! Communication aux personnes concernes
! Mise en application

87

88

Plan
!
!
!
!
!
!

Clture de projet (1)

Introduction
Modles et activits de dveloppement
Avant-Projet
Suivi du projet
Clture du projet
Activits transverses

Invitablement, les projets se terminent ; il est dans la dfinition mme dun

projet quil ne dure quun temps prcis dans la vie dune organisation. Les
faons dont les projets se terminent peuvent toutefois varier.
Fin normale dun projet
! La plupart des projets se terminent favorablement avec la livraison du produit ou du
systme au client; ce client peut tre linterne de lorganisation, projet dimplantation
dquipement dans une usine, ou lexterne, projet de construction, projet de soustraitance industrielle.

Fin normale dun projet et intgration lorganisation

! Dans certains cas de projets, surtout lorsque le client est interne, il arrive trs
frquemment quon invite les membres de lquipe devenir ou redevenir membres
part entire lorganisation. On parle donc dintgration des rsultats et des
ressources du projet.

Fin dun projet avort

! Il peut arriver quon doive arrter un projet pour des questions techniques,
budgtaires ou lgales. Des procdures doivent alors tre prises pour compenser, sil
y a lieu, la ou les parties lses.

89

Clture de projet (2)

90

Evaluation (1)

! En situation normale, clturer un projet dsigne une srie dactivits

que doit raliser les responsables du projet. Lutilisation de listes de
vrification est frquente lors de la fermeture de dossiers.
! Sassurer de la fin de lensemble des travaux, incluant les tches en
sous-traitance
! Validation du client comme quoi il a reu le produit/systme et les autres
livrables
! Sassurer que la documentation est jour et que les rapports de clture
ont t raliss (si requis)
! Rgler les dernires transactions financires (facturation)
! Relocalisation du personnel, des quipements, des matriaux
! Consolider la documentation conserver

91

92

Evaluation (2)

Plan
!
!
!
!
!
!

Introduction
Modles et activits de dveloppement
Avant-Projet
Suivi du projet
Clture du projet
Activits transverses
! Gestion de configurations
! Documentations
! Les outils
! Les Hommes

93

Gestion des versions

et des volutions (1)

94

Gestion des versions

et des volutions (2)

! Numrotation trois chiffres :

! 1er chiffre : Numro de versions majeures du produit, dont la sortie
saccompagne de progrs importants au niveau des fonctionnalits,
et/ou changement notable denvironnement dutilisation ou de
portabilit
! 2me chiffre : numro des version mineures. Lincrment est ralis
chaque fois que lquipe de dveloppement libre une version du
produit qui corrige des bugs attendus par les clients (mais non
bloquants), et apporte des modifications lgres
! 3me chiffre : numro des corrections, versions rsultant de la
maintenance

! Version Alpha : version termine en cours de test et de

revue de qualit
! Version Bta : version alpha valide en test auprs dun
panel de clients privilgis
95

96

Documentations
Structure dun document

Documentations
! Documentation de gestion du projet
!
!
!
!
!

! Un document comporte ncessaire une page den tte :

Plannings, plans, estimations

Rapports
Dfinitions de standards
Documents de travail
Courriers (mls)

! Qui le situe dans le projet (rfrence de projet, auteurs, catgorie du

document)
! Qui dcrive sommairement son contenu (titre parlant, rsum)
! Qui le date et donne sa version
! Qui en permette larchivage (mot clef, type de document)
! Qui dcrive les standards auquel le document est suppos se
conformer
! Qui en dcrive le copyright
! Qui en dcrive la circulation souhaite (nominatif et/ou classement
de confidentialit)
! Qui donne un contact pour questions ou remarques
! Qui dise sil sagit dune version prliminaire (de travail) ou dfinitive
!

! Documentation Technique
! Utilisateur : Manuel dinstallation, manuel dadministration, manuel
dutilisation, manuel de rfrence
! Systme : cahier des charges, analyse et conception du systme,
architecture du systme, archivage des programmes et des listings,
documents de validation, documents de tests, guide de maintenance

97

Documentations
Style rdactionnel
!

!
!
!
!
!

Sparer clairement les paragraphes qui peuvent tre perus comme des rponses aux
questions quoi ?, par qui ?, o ?
Identifier des niveaux de texte correspondant des lectures plus ou moins dtailles.
Trois niveaux : titre, corps principal de texte, texte
Mentionner en notes de bas de page les considrations caractre anecdotique qui
mme si elles clairent le sujet perturbent la comprhension dune phrase
Mettre en vidence la premire apparition dun terme dans le texte, et surtout une mention
qui le dfinit, par exemple, en utilisant des caractres gras. Une dfinition ne doit pas
pouvoir chapper lattention, mme lors dune lecture rapide
crire des phrases et des paragraphes courts
Ne pas utiliser de double ngation
Utiliser des formes verbales actives, impratives et le prsent
Avoir une bonne orthographe et une bonne grammaire
Dfinir les termes utiliss : un glossaire doit imprativement accompagner tout document

!
!

Se rpter si ncessaire
Donner des rfrences explicites.

!
!
!

98

Documentations
de gestion de projet

99

100

Documentations techniques

Documentations qualit

101

Document danalyse
Vision gnrale

Document danalyse
1.!
2.!
3.!
4.!
5.!
6.!
7.!
8.!
9.!

102

Vision gnrale
Spcification prliminaire
Dfinition des cas dutilisation
Spcification dtaille
Cas dutilisation
Exemples
Collaborations
Diagrammes dtat
Graphes dactivit

1.1 Positionnement
! This chapter describes the situation of the analysis
document (positioning with regard to other analysis
documents, requirements specifications, indication of
associated software parts)

1.2 Objectifs
! This chapter describes the aim of this specification,
fundamental needs met and the overall specification plan

1.3 Documents de rfrence

! This chapter provides the list of documents on which the
current document is based, and to what extent
103

104

Document danalyse :
Spcification prliminaire

Document danalyse :
Dfinition des cas dutilisation

2.1 Dictionary

User packages
The "Definition of the use cases" chapter contains:

! This provides the list of terms used in the document, accompanied

by their definition.

! packages annotated {usecase}.

2.2 Overview of the application

! This chapter contains:
! summary and description notes of the document package
! class diagrams (with their description notes)

2.3 Summary
! This chapter contains the list of:
!
!
!
!
!

packages annotated {usecase} (with their summary notes)

packages not annotated {usecase} (with their summary notes)
classes (with their summary notes)
interfaces (with their summary notes)
referenced elements (with their summary notes)
105

Document danalyse
Spcification dtaille

106

Structure du document
1 Overview
1.1 Situation of this specification
1.2 Objectives of this specification
1.3 Reference documents
2 Preliminary specification
2.1 Dictionary
2.2 Overview of the application
2.3 Summary
3 Definition of the use cases
User packages
4 Detailed specification
4.1 Non-user packages
4.2 Classes
4.3 Interfaces
4.4 Referenced packages
4.5 Referenced classes
4.6 Referenced interfaces
5 Use cases
6 Examples
7 Collaborations
8...State machines
9...Activity graphs

4.1 Non-user packages

4.2 Classes
4.3 Interfaces
4.4 Referenced packages
4.5 Referenced classes
4.6 Referenced interfaces

107

108

Les outils

Les Hommes (1)

! Outils ddis des tches spcifiques

! Ateliers de gnie logiciel (AGL) :
!
!
!
!
!

! Dveloppement logiciel est une tche humaine et

crative
! Travail en groupe : Travail collaboratif, Productivit
personnelle, Disponibilit doutils de travail
collaboratif
! Structure homogne (petits projets) :

Analyse et conception
Programmation, prototypage ou dveloppement rapide (RAD)
Construction dinterface homme-machine
Vrification
Documentation, version, collaboratif

! Environnement intgrs pour un support tout le

dveloppement

! structure de lquipe reflte la structure du produit,

chaque membre ralise une partie du projet
! Bonne communication entre les membres, continuit du
projet est facile assurer

! Structure spcialise (grands projets) :

109

Les Hommes (2)

110

Les Hommes (3)

! Programmation impersonnelle

! Rle du chef de projet

! Pas de proprit personnelle (pas de lien affectif entre le module et

la personne)
! Proprit collective (prsentation standardise : mise en page,
commentaires, )
! Tout programme contient des erreurs
! En dcouvrant une erreur, on ne blme pas une personne
particulire, mais on rend un service lquipe
! Plus tt on dcouvre les erreurs, moins coteuse est la correction

! Comptences techniques
!
!
!
!

! Structuration selon les spcialits

Spcification
Architecture
Outils de dveloppement
Tests

! Comptences administratives et organisationnelles

! Gestion administrative
! Allocation de ressources
! Animation des quipes

! Trop pour une seule personne

! Deux responsables (technique et administratif)
111

112

Rles au sein dun projet

Rles au sein dun projet

! Programmers (system engineers)

! Dcider lesquels sont ncessaires pour votre projet

! En fonction de ce que vous tes en train de dvelopper :

! Technical lead, architect, programmer, Sr. programmer

! Quality Assurance (QA) engineers (testers)

!
!
!
!
!

! QA Manager, QA Lead, QA staff

! DBAs
! DB Administrator, DB Programmer, DB Modeler

!
!
!
!
!
!
!
!

CM engineers (build engineers)

Network engineers, System Administrators
Analysts (business analysts)
UI Designers
Information Architects
Documentation writers (editors, documentation specialist)
Project manager
Other
! Security specialist, consultants, trainer

How big is it?

Is it UI intensive? Data intensive?
Are you installing/managing hardware?
Do you need to run an operations center?
Is it in-house, contract, COTS, etc?

! En fonction de votre budget

113

114

Modles dquipe

Modles dquipe

! Two early philosophies

! Business Team

! Decentralized/democratic
! Centralized/autocratic

!
!
!
!
!

! Variation
! Controlled Decentralized

Most common model

Technical lead + team (rest team at equal status)
Hierarchical with one principal contact
Adaptable and general
Variation: Democratic Team
! All decisions made by whole team
! See Weinbergs egoless programming model

115

116

Modles dquipe

Modles dquipe

! Chief-Programmer Team

! Skunkworks Team

! From IBM in 70s

! Put a bunch of talented, creative developers away from the mother

ship

! See Brooks and Mythical Man-Month

! a.k.a. surgical team

! Puts a superstar at the top

! Off-site literally or figuratively

! Pro: Creates high ownership & buy-in

! Con: Little visibility into team progress
! Applicable: exploratory projects needing creativity

! Others then specialize around him/her

! Backup Programmer
! Co-pilot or alter-ego
! Administrator
! Toolsmith
! Language lawyer

! Not on well-defined or narrow problem

! Issues
! Difficult to achieve
! Ego issues: superstar and/or team

! Can be appropriate for creative projects or tactical execution

117

118

Modles dquipe

Modles dquipe

! SWAT Team
!
!
!
!

! Large teams

Highly skilled team

Skills tightly match goal
Members often work together
Ex: security swat team, Oracle performance team

! Communication increases multiplicatively

! Square of the number of people
! 50 programmers = 1200 possible paths
! Communication must be formalized

! Always use a hierarchy

! Reduce units to optimal team sizes
! Always less than 10

119

120

Taille dquipe

Rfrences
!
!
!
!
!
!
!

! What is the optimal team size?

! 4-6 developers
! Tech lead + developers

! Small projects inspire stronger identification

! Increases cohesiveness
! QA, ops, and design on top of this

CNRS, DSI (http://www.dsi.cnrs.fr/conduite-projet/Default.htm)

Association Francophone de la gestion de projet (http://www.afitep.fr/Default.htm)
Project Management Institute (PMI) (http://www.pmi.org/)
Software Engineering Institute (SEI) (http://www.sei.cmu.edu/)
IEEE Software Engineering Group (http://standards.ieee.org/software/)
Guide to the Software Engineering Body of Knowledge (http://www.swebok.org/)
Cost estimation tools
!
!

FAQ on Function Points

Choosing a project management tool

!
!
!

http://ourworld.compuserve.com/homepages/softcomp/fpfaq.htm
http://www.4pm.com/articles/selpmsw.html
http://www.infogoal.com/pmc/pmcswr.htm

Project management tools

!
!
!
!
!
!
!

121

http://www.retisoft.com/SCEPFeatures.html
http://www.construx.com/estimate

http://www.startwright.com/project1.htm
http://www.kidasa.com
http://www.criticaltools.com/pertmain.htm
http://www.guysoftware.com/planbee.htm
http://www.minuteman-systems.com
http://www.microsoft.com/office/project/prodinfo/default.mspx
http://www.eclipse-plugins.info/eclipse/plugins.jsp?category=Project+management

122