La planification en génie logiciel

GEF492A Automne 2014[HvV ch. 2]

Capt Vincent RobergeCollège Militaire Royal du Canada

Génie électrique et génie informatiqueVincent.roberge@rmc.ca roberge.segfaults.net

PPL01-planification.pdf

2GEF492

Aperçu• Qu’est-ce que le génie• Maturité du génie logiciel• Planification de projet• Contrôle de projet

Automne 2014

3GEF492

Qu’est-ce que le génie?• Le génie est l’application d’art, science,

connaissances, mathématiques, technologie et d’expérience pratique à la conception d’objet, d’outils ou de processus utiles

Wikipedia• Plusieurs parle d’une progression

• Bricoleur• Artisan• Scientiste• Ingénieur

Automne 2014

4GEF492

La profession du génie• Le génie au Canada est une profession qui,

dans l'intérêt du public, est réglementée par des organismes autonomes qui délivrent les permis d'ingénieur.

• Ces organismes ont été créés par les 13 gouvernements provinciaux et territoriaux du Canada, par l'entremise de lois contrôlant la pratique du génie.

• Seuls les ingénieurs titulaires de la désignation ing./PEng. sont autorisés à exercer le génie au Canada.• Dispense pour ingénieurs fédéraux

www.peng.ca/francais/profession/index.html

Automne 2014

5GEF492

Les ingénieurs font parfois des erreurs

Automne 2014

Le pont des Tacoma Narrows

6GEF492

Le génie logiciel• Le génie logiciel est l’application d’une

approche disciplinée, systématique, et quantifiable au développement, à l’utilisation et à l’entretien de logiciel

IEEE

Il s’agit donc de l’application des principes d’ingénierie au logiciel

Automne 2014

7GEF492

Maturité du génie logiciel• Conférence de l’OTAN introduit le terme

« Software Engineering » en 1968/1969

• Motivation: Le développement de logiciel est plus qu’un art, ou qu’un « sac de trucs »

• On bâtit le logiciel comme on bâtis un pont!!• Ce qui signifie qu’on suit un processus de

génie; il existe toutefois des grandes différences entre le génie logiciel et les génies matériaux

Automne 2014

8GEF492

Distribution relative des coûtsmatériel/logiciel

Automne 2014

MatérielDéveloppement

Logiciel

Maintenance

1955 1970 1985Année

100

60

20

Po

urc

enta

ge

du

co

ût

tota

l

9GEF492

La planification

On doit commencer avec un plan, mais celui-ci n’est rien de plus qu’un point de départ duquel on peut/doit s’adapter

Aucun plan d’opérations ne demeure adéquat avec exactitude après avoir rencontré la force principale de l’ennemi.

- Helmut von Moltke the Elder

Aucun plan ne survit le contact avec l’ennemi.

— Dicton communAutomne 2014

10GEF492

Pourquoi est-ce qu’on fait des plans?• C’est vrai que les projets logiciels échouent

parfois de par des facteurs techniques, mais la plupart des échecs sont causés pare des facteurs de gestion

• Causes typiques pour l’échec d’un projet:• estimation de temps trop optimiste

• on ne prévoit pas assez de temps pour concevoir le projet

• productivité des programmeurs moins haute que prévue

• une manque de réalisation du progrès actuel, • peut-être a cause de mesures inexactes

• une manque de connaissance des besoins réels

• La conception et l’entretien d’un plan est indispensable – le succès n’est pas un hazardAutomne 2014

11GEF492

Un plan de projet définit (1)

• ce qu’on va construire• un contexte et sommaire du système, et le but

principale (de point de vue de l’entreprise)

• le processus qu’on suivra• il faut qu’on choisisse un modèle du cycle de

vie cohérent aux objectifs du projet• des méthodes ou techniques spéciales et les

outils nécessaires

• la structure organisationnelle• les rôles et responsabilités des membres de

l’équipe, ainsi que les relations entre l’équipe et les entités externes (y compris le client)

Automne 2014

12GEF492

Un plan de projet définit(2)• les normes, directives et procédures

• très important pout les projets exécutés par un entrepreneur externe

• il faut identifier les questions de documentation de façon assez précise

• les activités de gestion• les rôles et responsabilités de l’équipe de gestion

• y compris les reports de progrès et la gestion des risques

• les risques• l’identification et classification des risques au

projet et les stratégies d’atténuation de ceux ci• la qualité

• comment s’assurer de rencontrer les besoins de qualité

Automne 2014

13GEF492

Un plan de projet définit : (3)

• les ressources• le matériel, les outils, et l’appareillage d'essai• le nombre de personnel requis, ainsi que leurs

qualifications

• les lots de travaux• la division du travail en morceaux maniable

• le budget et le programme • une allocation des fonds et du temps aux lots

de travail• les techniques d’estimation et de pistage

• le gestion des changements• les procédures claires pour adresser les

changementsAutomne 2014

14GEF492

Principes de base• Le logiciel est crée de façon itérative* et

doit être entretenu• on commence par trouver un « sentier » des

besoins vagues aux besoins précis• on crée un plan conceptuel du produit• chaque fois que les besoins devient plus précis,

on raffine les estimations et le programme • quand les besoins deviennent clairs, on élabore

un design détaillé et une stratégie d’exécution et on les incorporent dans le plan

• le plan fournit l’échafaud duquel on peut négocier pour les ressources et le temps nécessaires

Automne 2014

15GEF492

Il faut se souvenir que• les premières estimations de ressource et

du programme sont presque toujours fautives• On doit réduire l’ampleur du projet ou

augmenter le temps disponible ou les ressources allouées

• on a toujours besoin d’entités avant que celles-ci ne soient disponibles• Donc: le plan devient le début d’un processus

de négociation entre les désires du clients et les ressources du développeur

• il faut conclure cette négociation aussitôt que possible

Automne 2014

16GEF492

Les besoins sont maîtres• le plan découle toujours des besoins du

client, y compris• attributs critiques

• ce que le système doit faire• configuration du système

• Plateforme, normes, compatibilité• l’identification par le client

• pour qui est-ce qu’on élabore ce système, comment est-ce qu’on les implique

• mesures du succès• coût, programme, performance, qualité, grandeur

• validation et réception• les tests de réception, critère d’acceptation,

garanties• soutien

• les besoins de soutient après achèvementAutomne 2014

17GEF492

Les variables de contrôle du projet

Automne 2014

l’ampleur

temps la qualité*

ressources?

* La qualité n’est pas une bonne variable de contrôle. Pourquoi pas?

18GEF492

Les paradoxes du contrôle • si on ajoute des programmeurs au projet,

la productivité va presque certainement diminuer“… More fire requires more gasoline, and thus

begins a regenerative cycle which ends in disaster”

Fred Brooks

• habituellement, l’insistance sur la haute qualité aide à réduire le temps requis pour compléter

• si on a plus de temps pour le projet, on crée parfois un système moins utile• parce qu’on a besoin des réactions du client

Automne 2014

19GEF492

Resources 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.

Automne 2014

20GEF492

LES MODÈLES DU PROCESSUS ET LE MODÈLE «WATERFALL»

Prochaine séance:

Automne 2014