La planification GEF493 2001 Renvoi: HvV ch' 2

1
La planificationGEF493 2001 Renvoi HvV ch. 2
Royal Military College of Canada Electrical and
Computer Engineering

• Major Greg Phillips
• greg.phillips_at_rmc.ca
• 1-613-541-6000 ext. 6190

Major Ron Smith smith-r_at_rmc.ca 1-613-541-6000
ext. 6030
2
La planification

• Un plan nest plus quune position doù on peut
  sadapter. Mais ce nest pas à dire quon na pas
  besoin dun plan. Sans un plan, on na rien.
• Neil MacLaine, 1 PPCLI
• No plan survives contact with the enemy. (fr?)
• Auteur anonyme

3
Pourquoi est-ce quon fait des plans?

• cest vrai que les projects du logiciel ny
  arrive pas a cause des facteurs technique, mais
  la plupart des échecs viennent des facteurs de
  gestion
• causes typique pour léchec dun projet
• estimation de temps trop basse
• productivité des programmeurs plus bas que prévue
• une manque de connaissance de lavancement
  actuel, peut-être a cause des comptes inexacts
• une manque de connassance des besoins réels
• on a pas prévoit assez de temps pour concevoir le
  projet
• conception et entretien dun plan est
  indispensable

4
Un plan de projet définit (1)

• ce quon va construire
• un contexte et sommaire du système, et le but
  éssentiel (de point de vue de lentreprise)
• le processus
• il faut quon choisisse un modèle du cycle de vie
  cohérent aux objectifs du projet
• des méthodes ou techniques spéciales et les
  outils necessaires
• le structure
• les rôles et résponsabilités des members
  déquipe, et les relations entre léquipe et
  autres organisations externes (y compris le
  client)

5
Un plan de projet définit (2)

• les normes, directives et procédures
• très important pout les projets fait par une
  contracteur externe
• il faut identifier les questions de documentation
  de façon assez précise
• les activités dadministration
• les rôles et responsabilités déquipe de gestion
• y compris les reports davancement et le gestion
  des risques
• les risques
• lidentification et classification des risques au
  projet et les strategies dattenuation
• la qualité
• comment sassurer des besoins de la qualité

6
a Project Plan defines (3)

• les ressources
• le matériel, les outils, et lappareillage
  d'essai
• les types et nombres de personnel requise
• les lots de travaux
• la division du travail en morceaux maniable
• le budget et le programme
• une allocation des fondes et du temps aux lots de
  travaux
• les techniques destimation et de traquage
• le gestion des changements
• les procédures claires pour soccuper des
  changements

7
Principles de base

• crée de façon itérative et entretenu
• on commence par trouvant une piste des besions
  vagues aux besoins précises
• on crée un plan conceptuel du produit
• chaque fois que les besoins devient plus
  précises, on raffine les estimations et le
  programme
• quand les besoins devient claire, on élabore une
  conception détaillé et une strategie dexécution
  et les incorporent dans le plan
• le plan fournit un structure avec laquelle on
  peut négocier pour les ressources et le temps
  neécessaires

8
Il faut se souvenir que

• les premiers estimations des ressource et du
  programme sont presque toujours inacceptables
• il faut ou reduire lampleur ou augmenter le
  temps ou les ressources
• on a toujours besoin des entités avant que cest
  possible de les avoir
• alors le plan devient dun processus de
  négociation entre les désires et les ressources
  du client
• il faut conclure la négociation aussitôt que
  possible

9
Les besions ont de la suprématie

• le plan vient toujours des besions du client, y
  compris
• attributs critiques
• ce que le système doit faire
• configuration du système
• (platforme de fonctionnement), normes,
  compatibilité
• lidentification du client
• pour qui est-ce quon élabore ce système, comment
  est-ce quon les implique
• mesures du succès
• coût, programme, performance, qualité, grandeur
• validation et réception
• les tests de réception, critère dacceptation,
  garanties
• soutien
• les besoins de support après achèvement

10
Les variables de contôle du projet
lampleur
ressources ?
temps
la qualité
La qualité nest pas une bonne variable de
contrôle. Pourquoi pas?
11
Les paradoxes du contrôle

• si on ajoute des programmeurs au projet, la
  productivité va presque certainnement diminuer
• More fire requires more gasoline, and thus
  begins a regenerative cycle which ends in
  disaster
• Fred Brooks
• dhabitude, linsistance de haute qualité aide à
  réduire le temps necessaire pour achever
• si on a plus de temps pour le projet, des fois on
  crée un système moins utile
• parce quon a besion des réactions du client

12
Renvoi supplémentaires

• Kent Beck. eXtreme Programming eXlained -
  Embrace Change, Chapter 4. Addison Wesley, 2000.
  ISBN 201-61641-6
• Frederick P. Brooks. The Mythical Man-Month
  Essays on Software Engineering. 20th Anniversary
  Edition. Addison Wesley, 1995. ISBN
  0-201-83595-9.

13
Next ClassLes modèles du process et le modèle
Chute deau (Waterfall)