Introduction au

Gnie Logiciel

Yannick Loiseau

Introduction au gnie logiciel e

(WORK IN PROGRESS)

Yannick Loiseau
Matre de confrences ` luniversit Blaise Pascal e a e

Introduction au gnie logiciel: (WORK IN PROGRESS) e Yannick Loiseau Copyrights 20072011 Yannick Loiseau Cette cration est mise ` disposition selon le Contrat Paternit-Pas dUtilisation Commercialee a e Partage des Conditions Initiales ` lIdentique 2.0 France disponible en ligne http:// a creativecommons.org/licenses/by-nc-sa/2.0/fr/ ou par courrier postal ` Creative a Commons, 171 Second Street, Suite 300, San Francisco, California 94105, USA.

Table des mati`res e

Table des mati`res e Prface e 1 Introduction 1.1 Quest-ce que le gnie logiciel ? . . . . . . . . . . . . . . . . . . . . . . . . e i iii 1 1

Gestion de projet

3
5 5 5 5 7 7 7 8 11 13 13 14 14 16 16 16 19 19 20 21 21 22 22 23 24

2 Mthodes de gestion de projets et de dveloppement e e 2.1 Cycle de vie du logiciel . . . . . . . . . . . . . . . . . . . 2.2 Unied Process . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Phases et activits . . . . . . . . . . . . . . . . . e 2.3 Mthodes agiles . . . . . . . . . . . . . . . . . . . . . . . e 2.3.1 Valeurs . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Principes . . . . . . . . . . . . . . . . . . . . . . 2.3.3 Pratiques et techniques . . . . . . . . . . . . . . 3 Introduction 4 Estimation de la charge dun projet 4.1 Charge et cot dun projet . . . . . u 4.2 Dure et nombre dintervenants . . . e 4.3 Mthode COCOMO . . . . . . . . . e 4.3.1 Mod`les et type de logiciels . e 4.3.2 COCOMO simple . . . . . . 4.3.3 COCOMO intermdiaire . . . e 5 Planication 5.1 Ordonnancement de tches . . . . . a 5.1.1 Potentiel tche : PERT . . . a 5.1.2 Diagramme de Gantt . . . . . 5.1.3 Tches successives . . . . . . a 5.2 Mthode de suivi global . . . . . . . e 5.2.1 Principe . . . . . . . . . . . . 5.2.2 Mthodologie . . . . . . . . . e 5.2.3 Calcul du taux de ralisation e i

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

6 Documents - Cahier des charges 6.1 Elaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Qualit du syst`me . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e e 6.3 Type de cahiers des charges . . . . . . . . . . . . . . . . . . . . . . . . . . Bibliographie Table des gures Liste des tableaux Liste des dnitions e Liste des exemples Glossaire Index

25 25 26 27 29 31 33 35 37 39 41

ii

Prface e
Audience et prrequis e
Il a pour but de servir de support aux cours de gnie logiciels en 3me anne de licence et e e re anne de master en informatique. Certains chapitres sont plus orients conception ou 1 e e dveloppement dapplication et concernent plus des tudiants de niveau licence ; dautres e e traitent de la gestion de projet ou de mthodes dorganisation ou dvaluation, et sont e e plutt destins ` des tudiants de niveau master. o e a e Certaines parties (notamment la gestion de projet) sont cependant assez gnrales pour e e tre utiles ` dautres type de formations sans forcment ncessiter de prrequis. Dautres e a e e e sont beaucoup plus appliques, et requi`rent de bonnes connaissances en programmation, e e notamment dans les concepts orients objets. e

Conventions utilises e
Voici les direntes conventions utilises dans la suite. e e

Icnes o
 reprsente un paragraphe contenant des notes diverses. e  reprsente un paragraphe contenant des conseils. e ! reprsente un paragraphe contenant un avertissement. e

Niveau
Selon les chapitres ou les sections, des connaissances diverses peuvent tre requises. e Le niveau dune partie est indiqu par les symboles suivant : e

#$$ ##$ ###

dbutant e intermdiaire e conrm e

Contacts
Vous pouvez contacter lauteur ` mailto:yannick.loiseau@univ-bpclermont.fr a

iii

iv

1
Introduction
1.1 Quest-ce que le gnie logiciel ? e

1. INTRODUCTION

Refactoring

Dploiement

TDD

Pair Programming Unified Process (UP) Merise Cycle de vie du logiciel

Suivi davancement

Diagramme Pert

Documents Intgration continue Mthodes Agiles

Ordonnancement des tches

Diagramme de Gantt

Planification Mthodes de dveloppement

UML Gestion de projet

Design Patterns Modlisation Gnie Logiciel

Estimation de la charge

Architecture

Dette Technique

DSL Automatisation de tches Outils de dveloppement Qualit Revue de code

Gestion du code

Commentaires

Analyse du code

Optimisation

Gestion de version AGL Tests Formatage du code Mtriques Analyse statique Bonnes pratiques

Litterate Programming

Gestion derreurs

Tests Unitaires

Tests Fonctionnels Couverture des tests

Figure 1.1 Quelques concepts du gnie logiciel e

I
Gestion de projet

2
Mthodes de gestion de e projets et de dveloppement e
2.1 Cycle de vie du logiciel
Analyse des besoins Conception

Ralisation e Vrication e Dploiement e

Maintenance Figure 2.1 Cycle de dveloppement en cascade e

2.2
2.2.1

Unied Process
Phases et activits e

Le processus de dveloppement prconis dans UP se dcompose en phases et en e e e e activits, correspondant plus ou moins aux tapes de Merise, ` la nuance pr`s que le e e a e processus tant par nature itratif, les direntes tapes se rpartissent potentiellement e e e e e sur plusieurs phases, tout au long des itrations du cycle de vie. e 5

6
Rle

2. METHODES DE GESTION DE PROJETS ET DE DEVELOPPEMENT

Niveau Acceptation Recette Validation

Matre douvrage

Besoins

Systme

Matre doeuvre

Conception

valuation

Fonctionnel

Architecte

Dcomposition Dfinition et dcomposition Vrification Conception dtaille Tests unitaires

Intgration Tests et intgration

Technique/mtier

Dveloppeur

Composant

Implmentation

Figure 2.2 Cycle de dveloppement en V e Phases : Inception (lancement) tude dopportunit et de faisabilit e e e valuation des risques e Elaboration dnition des besoins cas dutilisation e dtails de larchitecture composants, dploiement e e Construction premi`re version e conception implmentation e tests Transition dploiement e livraison, exploitation Activits : e Expression des besoins, tude de lexistant diagramme des cas dutilisation e Analyse, formalisation diagrammes de classe, squence, tat, collaboration e e Conception : considration des aspects techniques e Implmentation e Tests : unitaires, intgration, rception, performances. e e Dmarche La dmarche de dveloppement est donc la suivante : e e e 1. Etude du contexte du syst`me laboration du diagramme de contexte. On tudie e e e ici lenvironnement du syst`me, ses interactions avec lextrieur, les dirents acteurs e e e impliqus. A ce niveau, le syst`me est considr comme une boite noire . Les e ` e ee acteurs reprsentent toutes les entits extrieures qui interagiront avec le syst`me e e e e (personnes, autres syst`mes,. . .). e 2. Etude des cas dutilisation laboration du diagramme des cas dutilisation. On e consid`re ici les dirents services ou fonctionnalits fournies par le syst`me, quel e e e e est lutilisation que lon va en faire, dans le cadre de son fonctionnement normal, et pour chaque acteur impliqu. Par exemple, ladministrateur du syst`me naura pas e e acc`s aux mmes fonctionnalits quun utilisateur normal. On distingue galement e e e e

 2.3. METHODES AGILES

` ce niveau les acteurs principaux du syst`me, qui agiront sur lui, et les acteurs a e secondaires, que le syst`me utilisera. e 3. Etude dtaille de chaque cas dutilisation. Le scnario de chaque cas dutilisation e e e est dtaill pour dcrire le droulement normal de la fonctionnalit correspondante e e e e e laboration des diagrammes de squence. Etude du comportement complet du e e syst`me, avec prise en compte des dirents cas de gures et des probl`mes ventuels e e e e diagramme dactivit. e 4. Etude de larchitecture du syst`me diagrammes de classes et dobjets (instances), e diagramme de composants. 5. Dtail du comportement des objets et des composants pour les dirents activits e e e prcdentes diagramme dtat e e e 6. Vrication de la conformit du mod`le ` lventuel syst`me existant et ` la dese e e a e e a cription des besoins et des spcications du client. Itration en dtaillant. e e e Les tapes suivant llaboration des cas dutilisations sont eectues plus ou moins e e e en parall`le, tant fortement corrle. On it`re ensuite sur ces tches, en augmentant le e e ee e a niveau de dtail de ltude et la granularit des descriptions, pour passer de lanalyse, e e e qui ne consid`re que le syst`me dans son ensemble, ` la conception dtaille, qui spcie e e a e e e prcisment les dirents aspects du syst`me et servira de base ` limplmentation. Lautre e e e e a e cycle ditration, plus global, se situe dans le cycle spirale et concerne donc lextension du e syst`me par prototypage. e

2.3

Mthodes agiles e

Les mthodes agiles sont le rsultat dune raction face aux mthodes dites traditione e e e nelles, bases sur un cycle en cascade, juges trop lourdes ` grer et en contradiction avec e e a e les mthodes de travail des programmeurs. Le terme est n en 2001, lors dune runion e e e de dirent membre de la communaut qui a donn naissance au manifeste (Agile Mae e e nifesto 1 ) prcisant les grands principes de ces mthodes. Les plus connues restent RAD e e (Rapid Application Development) ne dans les annes 80, et XP (Extreme programming), e e formalise ` la n des annes 90. e a e Plus facile de dire ce qui ne va pas dans un syst`me existant que de dnir ` priori e e a ses spcicits. e e overengineering in advance of requirements. If youre not developing the feature now, its best not to make a bunch of other design decisions based on what you think the feature will need.

2.3.1

Valeurs

Les valeurs dfendues dans le manifeste sont : e Personnes et interactions plutt que processus et outils o Programmes fonctionnels plutt que documentation (technique) compl`te o e Collaboration avec le client plutt que ngociation de contrat o e Ragir et sadapeter aux changements plutt que suivre un plan e o

2.3.2

Principes

Les principes agiles illustrent ces valeurs : Notre premi`re priorit est de satisfaire le client en livrant tt et rguli`rement des e e o e e logiciels utiles.
1. http://www.agilemanifesto.org/

2. METHODES DE GESTION DE PROJETS ET DE DEVELOPPEMENT

Le changement de spcications est bienvenu, mme tardivement dans le dveloppement. e e e Les processus agiles utilisent le changement comme avantage comptitif pour le e client. Livrer frquemment une application fonctionnelle, toutes les deux semaines ` deux e a mois, avec une prfrence pour la priode la plus courte. ee e Les commerciaux (clients) et les dveloppeurs doivent collaborer quotidiennement e au projet. Construire le projet autour de personnes motives. Leur fournir lenvironnement et e le soutien dont elles ont besoin, et avoir conance en leur capacit ` faire le travail. ea La mthode la plus ecace de transmettre linformation dans une quipe est une e e conversation directe. Un logiciel fonctionnel est la meilleure mesure de la progression du projet. Les processus agiles promeuvent un rythme de dveloppement soutenable. Commane ditaires, dveloppeurs et utilisateurs devraient pouvoir maintenir le rythme indniment. e e Une attention continue ` lexcellence technique et ` la qualit de la conception a a e amliore lagilit. e e La simplicit lart de maximiser la quantit de travail ` ne pas faire est e e a essentielle. Les meilleures architectures, spcications et conceptions sont issues dquipes qui e e sauto-organisent. ` A intervalle rgulier, lquipe rchit aux moyens de devenir plus ecace, puis e e e e accorde et ajuste son comportement dans ce sens. On voit ainsi que tout est centr sur lhumain et bas sur la communication : entre les e e programmeurs, avec les clients, etc. Cet aspect sert souvent dargument contre lutilisation des mthodes agiles dans le cadre de gros projets, avec de nombreux acteurs. En eet, e comme on la vu, plus le nombre de personne impliqu est grand, plus la communication e peut tre un frein au droulement du projet. e e Une consquence de cette approche est illustre par dlivrer tt, dlivrer souvent, e e e o e impliquant donc un dveloppement itratif (cycle spirale), avec des cycles tr`s court. e e e Ainsi, le client peut valuer en continue lavancement du projet, le tester, et fournir des e commentaires permettant dorienter le dveloppement, lajout de fonctionnalits, etc. Ceci e e garantie une raction au changement facile et prcoce. e e

2.3.3

Pratiques et techniques

Intgration continue (Fowler, 2006) Le terme vient de lXP, et dcrit un environnee e ment de travail o` tous les dveloppeurs int`grent frquemment leur travail, gnralement u e e e e e sur une base journali`re, dans un dpt de code, conduisant ` plusieurs intgrations e e o a e par jours. Ces intgrations sont vries par une compilation et des tests (unitaires, e e e intgration) automatiques, permettant de ne valider que les intgration correctes. On e e observe ainsi une baisse signicative des probl`mes lors de lintgration nale de lapplie e cation. Bien que cela ne soit pas ncessaire, il est utile dutiliser pour cela un serveur dintgration. e e (CruiseControl) Processus : 1. rcupration des sources (` partir du syst`me de gestion de version) ; e e a e 2. modication du code et des tests (unitaires, fonctionnels, intgration) ; e 3. compilation et tests en local de mani`re automatique (make, scripts, etc.) ; e 4. quand tous les tests passent, synchronisation des sources (rcupration des ventuelles e e e modications faites pendant ce temps) ;

 2.3. METHODES AGILES

5. nouveau cycle compilation/tests. Si des conits apparaissent, modication du code pour les rsoudre, synchronisation, etc. jusqu` ce que le code soit synchronis et e a e passe tous les tests ; 6. envoie des modications dans le gestionnaire de version (commit) La derni`re tape est un cycle compilation/tests sur une machine dintgration, base sur e e e e la derni`re version du dpt, en situation relle . De cette mani`re, les conits entre e e o e e les dirents dveloppeurs, entre les composants du syst`me par exemple, sont dtect e e e e e tr`s rapidement. Si cette derni`re tape choue, la priorit est de rtablir lenvironnement e e e e e e dans un tat stable et fonctionnel. Ainsi, chaque modication ultrieure se fait ` partir e e a dun syst`me fonctionnel. La modication du code par cycle court garanti que le nouveau e code sera proche de cette version stable, et donc facile ` intgrer. Une version fonctiona e nelle du syst`me est donc disponible en permanence, ce qui permet de faire des tests de e performances, de qualit, etc. et de dlivrer une version du syst`me frquemment. e e e e Toute cette infrastructure repose donc sur dautres outils et pratiques classiques des mthodes agiles, tels que lautomatisation, les tests et le contrle de version. En eet, e o on doit pouvoir mettre en place et tester le syst`me facilement et frquemment, ce qui e e implique crer les bases de donnes, compiler, initialiser et congurer les environnements, e e etc. Le dpt de documents doit donc tre complet, et lautomatisation des tches pousse e o e a e a ` son maximum. Lautre avantage de lautomatisation est de permettre deectuer ces tches de mani`re consistantes tout au long du processus de dveloppement, en vitant a e e e ainsi les erreurs humaines.

10

2. METHODES DE GESTION DE PROJETS ET DE DEVELOPPEMENT

3
Introduction
Etude des besoins Evaluation Planication Cycle dtalonnage e Suivi Cycle dactualisation

Bilan Figure 3.1 Phases de la planication Qualit e

2 3

Cot u

Temps

Figure 3.2 Dilemme de la gestion de projet

11

12

3. INTRODUCTION

4
Estimation de la charge dun projet
If we wish to count lines of code, we should not regard them as lines produced but as lines spent Edsger Dijkstra

#$$
ien estimer la charge dun projet est important, car de cette estimation va dpendre e la planication et la rpartition des direntes tches et tapes du projet, et donc e e a e le bon droulement de celui-ci. e Il est frquent de sous estimer un projet, pour diverses raisons allant de linexprience e e a ` loptimisme, en passant par loublie dtapes de dveloppement ou labsence de e e mthode Ce chapitre prsente quelques mthodes destimation de la charge dun projet e e e informatique. Ces mthodes, ou mod`les deort, se basent sur une tude des spcicits du projet e e e e e (technologies, contraintes, besoins, etc.) pour estimer sa charge. Elles se basent gnralement e e sur des tudes empiriques, et il convient donc dadapter les dirents param`tres pris e e e en compte en comparant les rsultats fournis par les formules du mod`le et les valeurs e e rellement observes lors de projets prcdents (cycle dtalonnage). e e e e e

4.1

Charge et co t dun projet u

An de planier le projet (ou une de ses tches), on estime sa charge C, exprim en a e homme-jour (ou homme-mois). La table 4.1 prsente une classication de la taille des e projets par la mthode Merise. e Dnition 4.1 (Charge dun projet) La charge dun projet reprsente le cot de celuie e u ci en terme de ressources. Elle est mesure en homme-moi ou homme-jour, qui reprsente e e le temps ncessaire ` une personne pour raliser la tche, ou (thoriquement), le nombre e a e a e de personnes ncessaire pour eectuer la tche en un mois (ou un jour) e a Dnition 4.2 (kilo instructions source livre kisl) Cette unit mesure la taille e e e dun projet informatique par le nombre dinstructions prsentent dans le code source e nal (en milliers). Ce nombre est gnralement approxim par le nombre de lignes utiles e e e 13

14

4. ESTIMATION DE LA CHARGE DUN PROJET Tr`s gros projet e Gros projet Projet moyen Petit projet Tr`s petit projet e 200 100 ` 200 a 50 ` 100 a 20 ` 50 a < 20 hm hm hm hm hm 512 128 32 8 2 kisl kisl kisl kisl kisl

Table 4.1 Classication de la taille des projets dans Merise (sans les commentaires, etc.). Pour une mme fonctionnalit, cette mesure va videmment e e e dpendre du langage de programmation utilis. Cependant, elle est utilise pour reprsenter e e e e la charge, et donc le temps pass par lutilisateur pour mettre en uvre la fonctionnalit, e e ce qui sera aussi dpendant du langage. . . e A titre dexemple, dans sa version 2.6.31, le noyau linux toute architecture confondues fait environs 6000 kisl, et apache 2.2.13 pr`s de 200 kisl (modules compris). e

4.2

Dure et nombre dintervenants e

C En premi`re approximation, la dure D de la tche est N si N personnes se rpartissent e e a e le travail. Cependant, cette approximation nest pas valable dans la ralit. Comme le dit e e Brooks (1975),

Lhomme-mois comme unit pour mesurer la taille dun travail est un e mythe dangereux et trompeur. Il implique que les hommes et les mois sont interchangeables. Contrairement au cot, lavancement ne varie pas comme le produit du nombre de peru sonne et du nombre de mois. En eet, plus le nombre de personne impliqu augmente, e plus on perd de temps dans les interactions entre personnes, dans les runions, les exe plications, la communication, etc. Si N est tr`s grand, les interactions peuvent reprsenter e e un temps plus important que le travail eectif ! On estime gnralement la part de line e teraction entre 10% et 20% de la charge de la tche par personne supplmentaire. Ce a e coecient est estim plus prcisment en se basant sur lexprience. En eet, certaines e e e e personnes vont communiquer plus facilement que dautres, certains outils de gestion de projets peuvent faciliter la communication, etc. (dimension humaine du projet). Autrement dit, si CN est la charge relle pour N personnes, on a CN +1 = CN (1 + i) e N 1 avec i la part de linteraction (0.1 ` 0.2), soit pour la dure DN = C(1+i) a e . N Ceci permet de montrer quau del` dun certain nombre de personne, le temps pass a e se remet a augmenter. Il y a donc un temps minimum, correspondant au nombre optimal de personne pour la tche (voir Fig. 4.1). a De plus, pour chaque nouvelle personne aecte au projet ou ` la tche, une priode e a a e de formation devra tre prise en compte, pour lintgrer ` lquipe. Cet eort nest pas e e a e partitionnable, et varie donc linairement avec le nombre de personne. e

4.3

Mthode COCOMO e

La mthode COCOMO (Constructive Cost Model (Evaluation)) permet lestimation e de la charge dun projet et de son dlai normal de ralisation en fonction du nombre e e prsum de lignes de programmes ` crire. Elle se base sur les deux principes fondamene e ae taux suivants : 1. Un informaticien dveloppeur sait plus facilement donner une valuation de la taille e e du logiciel ` dvelopper que faire une estimation du travail ncessaire. a e e

 4.3. METHODE COCOMO Dure e 10

15

i = 0.2

i = 0.1 1 1 5 i=0 10 Personnes

Figure 4.1 Exemple de variation de la dure en fonction du nombre de personnes e On peut trouver le nombre de personne optimal pour une tche en annulant la a drive de la dure par rapport au nombre de personne e e e dD dn = = = = d C(1+i) N dN N 1 d (1+i) N dN N (1 + i)N 1 ln(1 + i) (1 + i)N 1 N2 N 1 (N ln(1 + i) 1) (1 + i) N2
N 1

1 c on veut donc que N ln(1 + i) 1 = 0, soit N = ln(1+i) . On saperoit donc que le nombre optimal ne dpend pas de la charge, mais uniquement de la part de e linteraction !

2. Il faut toujours le mme eort pour crire un nombre donne de lignes de programme, e e e quelque soit le langage de la mme gnration utilise. e e e e Le premier mod`le COCOMO a t dvelopp en 1981 par Dr. Barry Boehm pour e ee e e estimer le cot, en nombre de mois-homme, et le temps de dveloppement dun produit u e logiciel. A lorigine il a t construit sur une tude de 63 projets logiciels de 2000 ` 100 ee e a 000 lignes de code dans lentreprise TRW Inc. La mthode COCOMO est ouverte : les donnes de calibrage, les formules et tous les e e dtails des dnitions sont disponibles. La participation ` son dveloppement est encoue e a e rage. e Aujourdhui, COCOMO II est un nouveau produit beaucoup plus adapt ` laspect ea rutilisation des composants (modules existants). La version 1998 a t calibre sur 161 e ee e points de donnes, en utilisant lapproche statistique Bayesian pour combiner les donnes e e empiriques avec les avis experts. De plus elle peut tre re-calibre sur les donnes de e e e lentreprise.

16

4. ESTIMATION DE LA CHARGE DUN PROJET

Un nouveau mod`le appel COCOTS (Constructive Commercial o-the-shelf), est en e e cours de dveloppement par lquipe de COCOMO. Ce mod`le permet destimer les cots e e e u et planier des projets logiciels utilisant des composants existants. Leort global C (en h-m) est calcul comme une fonction de la taille du projet T (en e kisl) par : C = ai T bi m(X) (4.1) o` ai et bi sont des param`tres dpendant du mod`le COCOMO utilis et du type de u e e e e logiciel, et m(X) est le facteur dajustement de leort.

4.3.1

Mod`les et type de logiciels e

COCOMO est en fait compos de trois mod`les de plus en plus dtaills : e e e e simple ou de base, qui ne ncssite pas de param`tre, est utilis au dbut du projet ; e e e e e intermdiaire , qui ajoute des facteurs de cots fonctions des produits, machines, pere u sonnels, etc., est utilis apr`s les analyses prliminaires, une fois le syst`me dcoup ; e e e e e e dtaill fournis une estimation spare pour chaque sous-syst`me et utilise des facteurs e e e e e de cots dirents selon la phase du projet ; il est donc utilis apr`s la dnition des u e e e e dirents modules. e Le type de logiciel considr, retant sa complexit, inuence aussi les param`tres ee e e e dajustement. COCOMO dni trois type de logiciel : e organique : petites quipes connaissant bien le domaine et le syst`me utilis ; peu de e e e communications. semi-dtach : quipes plus htrog`nes ; exprience limit du domaine et du syst`me. e e e ee e e e e intgr : syst`me complexe avec des contraintes fortes (scurit, temps rel) ; cots de e e e e e e u validation levs. e e

4.3.2

COCOMO simple

Pour le mod`le simple, la charge se calcule avec les coecients suivants : e logiciel organique : C = 2.4 T 1.05 logiciel semi-dtach : C = 3 T 1.12 e e logiciel intgr : C = 3.6 T 1.2 e e et le temps de dveloppement en mois par : e logiciel organique : D = 2.5 C 0.38 logiciel semi-dtach : D = 2.5 C 0.35 e e logiciel intgr : D = 2.5 C 0.32 e e Le nombre de personnes ` mettre sur le projet est obtenu par a
C D

4.3.3

COCOMO intermdiaire e

Les coecients pour le calcul de la charge sont : logiciel organique : C = 3.2 T 1.05 logiciel semi-dtach : C = 3 T 1.12 e e logiciel intgr : C = 2.8 T 1.2 e e

 4.3. METHODE COCOMO

17

En plus des coecients dirents, le mod`le intermdiaire prend en compte les 15 e e e param`tres du tableau 4.2 comme facteur dajustement de leort (EAF pour eort ade justment factor ). Dans lquation 4.1, on a alors m(X) = 15 m(xi ) ; la valeur m(xi ) e i=1 pour le param`tre xi , entre 0.70 et 1.66, est donne par le tableau. Ces valeurs peuvent e e tre ajuste en fonction de lexprience. e e e La dure et leectif du projet sont calculs comme pour COCOMO simple. e e
Tr`s bas e Produit Fiabilit requise du logiciel e Taille BD Complexit e Matriel e Contrainte de temps dexcussion e Contrainte de taille mmoire e Instabilit de la MV e Temps de restitution des travaux Personnel Comptences des analystes e Exprience du domaine e Comptence des programmeurs e Connaissance de la MV Ma trise du langage de progr. Projet Utilisation des mthodes modernes e Utilisation doutils de dev. Contraintes sur le dlai du projet e 0.75 0.70 1.46 1.29 1.42 1.21 1.14 1.24 1.24 1.23 Bas 0.88 0.94 0.85 0.87 0.87 1.19 1.13 1.17 1.10 1.07 1.10 1.10 1.08 Normal 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 Haut 1.15 1.08 1.15 1.11 1.06 1.15 1.07 0.86 0.91 0.86 0.90 0.95 0.91 0.91 1.04 Tr`s haut e 1.40 1.16 1.30 1.30 1.21 1.30 1.15 0.71 0.82 0.70 0.82 0.83 1.10 Ext. haut 1.65 1.66 1.56 -

Table 4.2 Facteurs de lajustement du coup de COCOMO

18

4. ESTIMATION DE LA CHARGE DUN PROJET

5
Planication
Planning is bringing the future into the present so that you can do something about it now Alan Lakein

##$ 5.1 Ordonnancement de tches a

Quand le projet a t dcompos en direntes tches et sous-tches, et une fois que ee e e e a a lon conna leur dure et les intervenants, il faut tablir dans quel ordre ces tches seront t e e a eectues. Ceci permet de dterminer ` quelle date au plus tt le projet pourra sachever, e e a o et comment vont se rpartir les dirents travaux en fonction des intervenants. On obtient e e ainsi le planning du projet ; il doit tre visible par lensemble de lquipe. e e Pour eectuer cet ordonnancement des tches, il faut dnir les contraintes dantriorit, a e e e cest ` dire de la ralisation de quelles autres tches dpendent chaque tche, en se basant a e a e a sur la nature des tches, en ignorant les moyens ncessaires. On estime alors lordre de a e ralisation et les dates au plus tt des direntes tapes, puis la solution est dgrade e o e e e e pour prendre en compte les limites de moyens. On a plusieurs types de contraintes dantriorit : e e n dbut : la tche suivante commence d`s que la prcdente est termine (ou e a e e e e avec un dlai). Cest la plus courante ; e n n : les deux tches doivent nir en mme temps (on a donc la marge ventuelle a e e au dbut) ; e dbut dbut : les deux tches doivent commencer en mme temps ; e e a e Il est souvent utile dajouter les tches ctives permettant de valider lavancement du a projet ` certaines dates. Ces tches sont des jalons (mile stones), qui balisent lavancement a a du projet. Les jalons correspondent classiquement au moins aux direntes phases du e cycle de vie du logiciel, mais il est possible den ajouter dautres pour valider des tapes e importantes. Ces jalons sont particuli`rement important pour la suivie du lavancement e du projet (section 5.2). Larrive ` un jalon est donc gnralement accompagne dun e a e e e dlivrable (cahier des charges, documentation, prototype, etc.). e 19

20

5. PLANIFICATION

5.1.1

Potentiel tche : PERT a

On peut reprsenter les tches et leurs dpendances sous forme dun graphe. Plusieurs e a e approches sont possible : potentiel tche, o` les nuds reprsentent les tches, et les arcs a u e a les dpendances entre elles, ou potentiel tape, o` les tches sont places sur les arcs, nes e e u a e nuds tant les tapes de droulement du projet. e e e La mthode PERT (Program Evaluation and Review Technique) est plutt oriente e o e tche, les sommets du graphe comportent donc les dates de dbut et de n de la tche a e a associe (voif g.5.1). Une version plus avance de PERT prend en compte une estimation e e optimiste et pessimiste des dates. On peut ajouter des tches ctives pour reprsenter le dbut et/ou la n du projet. a e e On dtermine ensuite les dates de dbut et de n au plus tt de chaque tche : la date e e o a de dbut au plus tt est le maximum des dates de n au plus tt des tches prcdentes e o o a e e (la premi`re tche commenant ` 0), la date de n au plus tt tant dnie par la dure e a c a o e e e de la tche. Une fois la date de n de projet tablie, les dates de n au plus tard sont a e dnies par le minimum des dates de dbut au plus tt des tches suivantes. Lcart entre e e o a e le dbut au plus tt et le dbut au plus tard dnie la marge associe ` la tche. Ainsi : e o e e e a a Deb+tot F in+tot F in+tard Deb+tard M arge = = = = = = maxpred (F in+tot ) Deb+tot + Duree minsucc (Deb+tard ) F in+tard Duree Deb+tard Deb+tot F in+tard F in+tot

Nom: dure (marge) au plus tt + marge

au plus tard

dbut + dure

fin

Figure 5.1 Reprsentation des tches dans un PERT e a Le chemin critique appara ainsi. Il est constitu des tches pour lesquels il ny a pas de t e a marge, cest-`-dire celles o` lon na pas le droit de prendre du retard. Par consquent, a u e pour diminuer la dure du projet, il faut diminuer la dure des tches du chemin critique e e a (en aectant plus de personnes par exemple) ; diminuer la dure des autres tches naura e a a priori pas dimpact sur la dure totale du projet. La table 5.1 prsente un exemple de e e tches pour un projet, ainsi que les tches antrieures et leur dure. La gure 5.2 illustre a a e e le graphe obtenu. On voit que lon dispose de marges pour les tches B et C, le chemin critique tant A, a e F, E. Ainsi, A, F, et E ne peuvent tre ni avances ni recules, alors que D peut dmarrer e e e e au plus tard ` t = 15, et C peut dmarrer au plus tard ` t = 29. La gestion des marges a e a implique donc de grer la planication au plus tt ou au plus tard des direntes tches, e o e a selon la disponibilit des resources et la scurit que lon veut garder dans les retards. e e e

 5.1. ORDONNANCEMENT DE TACHES Tche antrieure a e D B,F A D,B,F A Tche a A B C D E F Charge 12 2 3 8 7 13 Intervenants 1 2 1 2 1 1

21

Table 5.1 Exemple de tches dun projet a

D: 4 (8) 12 A: 12 (0) 0 0 12 12 F: 13 (0) 12 12 25 25 C: 3 (4) 25 29 28 32 20 16 24 B: 1 (8) 16 24 17 25 E: 7 (0) 25 25 32 32 End 32

Figure 5.2 Exemple de graphe dordonnancement

5.1.2

Diagramme de Gantt

Pour reprsenter cet ordonnancement de mani`re plus parlante, on utilise gnralement e e e e un diagramme de Gantt. La gure ?? montre le diagramme de Gantt pour les tches de a lexemple prcdent. Il est aussi possible daecter les tches au moyen de production. e e a Dans ce cas, on a les moyens en ordonnes au lieu des tches. Cette vue est particuli`rement e a e parlante, car elle permet de bien reprsenter les aectations des dirents participants au e e projet. Les marges sont mieux visibles sur cette reprsentation. En rpartissant les tches e e a sur direntes resources (ou moyen, ici les programmeurs par exemple), il est possible de e rduire les marges, et ainsi de raccourcir dautant la dure du projet (comme la tche A e e a dans lexemple). Il faut cependant tre prudent : comme on la vue, multiplier le nombre e de personnes sur une tche peut ralonger celle-ci (probl`mes de communication). De plus, a e les marges sont une scurit en cas de retard sur une tche. Il ne faut donc pas toutes e e a les supprimer ! Par exemple, dans la gure ??(b), on pourrait encore raccourcir le projet en aectant le dbut de F ` P1 et P2 , pendant 1.5, mais dans ce cas, toutes les tches e a a deviennet critiques. enralement e 10% de  On conseille gchangement de garder auetmoinsimprvus.marges libres, an de pouvoir sadapter aux de planing aux e

5.1.3

Tches successives a

Ce principe permet dordonnancer des tches indpendantes mais devant tre efa e e fectues sur deux postes successifs, pour minimiser le temps dinactivit de chaque poste. e e 1. On cherche le temps minimal (tous postes confondus). Les galits ne sont pas e e importantes. 2. Si cest une opration du premier poste, on commence par la tche correspondante e a Si cest une opration du deuxi`me poste, on termine par la tche correspondante e e a 3. On supprime la ligne prise en compte, et on rit`re avec les valeurs restantes e e

22 Tche a T1 T2 T3 T4 T5 Dure sur poste 1 e 2 3 5 4 5

5. PLANIFICATION Dure sur poste 2 e 4 1 2 7 5

Table 5.2 Exemple de tches successives a Sur lexemple de la table 5.2, en excutant les tches dans lordre normal , on e a obtient le planning de la gure 5.3.
T1 T2 T3 T4 T5

T1

T2

T3

T4

T5

10

12

14

19

21

26

Figure 5.3 Tches successives non ordonnes a e Lutilisation de lalgorithme permet dobtenir le planning de la gure 5.4.

T1

T4

T5

T3

T2

T1

T4

T5

T3

T2

11

13

16

18

19

20

21

Figure 5.4 Tches successives ordonnes a e Il est possible dtendre cette mthode sur 3 postes (P1 , P2 , P3 ), si min(P1 ) max(P2 ) e e ou min(P3 ) max(P1 ). Dans ce cas, on applique la mthode prcdente sur P1 + P2 et e e e P2 + P3 .

5.2
5.2.1

Mthode de suivi global e

Principe

La mthode de suivi global est un moyen de mesurer lavancement du projet par e rapport aux tches qui ont t dnies. Les objectifs sont : a ee e 1. Quantier chaque point priodiquement e pour donner une mesure de ltat davancement du projet ; e cette estimation doit tre frquente (au moins une fois par semaine) : la mise en e e uvre doit donc tre facile et rapide ; e la quantication de lavancement clarie les relations du chef de projet avec son quipe, son suprieur et le client. e e 2. Estimer la charge restante : si le projet diverge (prend du retard), cela permet de sen rendre compte susamment tt pour pouvoir envisager les solutions possibles o et les mettre en place (rorganisation, embauche, etc.) e 3. Motiver lquipe en lui fournissant une mesure quantitative du travail eectu. Cela e e

 5.2. METHODE DE SUIVI GLOBAL fournit un objectif commun ; vite les tensions dues ` un suivi individuel ; e a fournit une mesure priodique connue et indiscutable. e

23

Le suivi tche par tche nest pas toujours ecace. En eet, la charge totale consomme a a e rellement pour une tche na souvent que peu de rapport avec la charge initialement e a prvue ; do` un suivi global sur le projet. e u

5.2.2

Mthodologie e

A chaque point priodique, le chef de projet value le taux de consommation de la e e charge du projet et le taux de ralisation eectu. Lensemble de ces deux taux est un e e bon indicateur de suivi. Dnition 5.1 (Taux de consomation) Cest le rapport de la charge consomme dee e puis le dbut du projet sur la charge initialement prvue. e e Dnition 5.2 (Taux de ralisation) Il reprsente lavancement rel du projet. Il est e e e e dtermin en ne tenant compte que des travaux gnrateurs de rsultat. On ne tient pas e e e e e compte des autres tches (formation, runions de suivi, etc.) a e Lvolution de ces deux taux est visualise en temps rel sur un graphique, comme e e e sur lexemple de la gure 5.5. CRn est la charge (taux) restante ` linstant de mesure n. a La gure 5.5 montre trois exemple de courbes : une courbe idale, qui dbute plus e e lentement que le taux de consommation, mais ni dans les temps ; une courbe intressante e qui se termine avant la date prvue (projet sur-dimensionn) ; une courbe dalerte, o` le e e u projet ne nira pas dans les temps (sous-dimensionn). e 100% Sur-estimation

Taux de ralisation e

Sous-estimation CRn Taux de consomation 100% Figure 5.5 Exemple de courbes de suivi 130%

24

5. PLANIFICATION Si arriv au tiers de la charge consomme la courbe du taux de ralisation na pas e e e situation, en ajoutant des personnes sur la tche par exemple. a

 commenc ` sinchir vers le haut, il faut prendre des mesures pour corriger la e a e
5.2.3 Calcul du taux de ralisation e

Le projet est dcompos en grand ensemble de tches ou tapes, elles mmes dcomposes e e a e e e e en tches, sous-tches, etc. Plus la dcomposition est ne, plus lvaluation, que ce soit a a e e de la charge initiale ou de ltat davancement, va tre prcise. On estime ensuite limpore e e tance relative des direntes tches, sous-tches,. . . (en terme de charge, pas de priorit). e a a e Cette estimation est base en grande partie sur lexprience. On peut aussi utiliser les e e estimations de charge faites lors de la planication (et les passer en relatif). Il nest pas ncessaire davoir une grande prcision sur les importances relatives (max. 5%), le but e e tant uniquement dvaluer la tendance du projet. Il est ` noter que lordre dexcution e e a e des tches nest pas forcment donn par leur hirarchie dans cette dcomposition, mais a e e e e par le travail dordonnancement. Le taux davancement dune tche est donne par la a e somme pondre des taux davancement de ses sous-tches. ee a Le projet est considr comme achev lorsque tous les grands ensembles de tches ee e a sont termins ; un ensemble de tche tant considr achev lorsque toutes ses tches sont e a e ee e a acheves, et ainsi de suite. Une tche lmentaire est soit termine, soit considr comme e a ee e ee non commence. Il est en eet dicile destimer lavancement dune tche lmentaire. e a ee Par exemple, lorsquun programme est crit, compil et test, lorsque une analyse est e e e valide, etc. e Exemple : Soit la dcomposition suivante : e
E1 2 E3

20% 40% 40%

P rojet

T1 T2 T4 T5 T3 T6

40% 60% 50% 50% 20% 80%

Si ` au moment dune estimation, les tches T5 et T3 sont nies et que les tches T1 a a a et T 4 sont en cours, le taux de ralisation du projet Rn est donc : e Rn = 0.2 E1 + 0.4 E2 + 0.4 E3 = 0.2(0.4 T1 + 0.6 T2 ) + 0.4(0.5 T4 + 0.5 T5 ) + 0.4(0.2 T3 + 0.8 T6 ) = 0.2(0.4 0 + 0.6 0) + 0.4(0.5 0 + 0.5 1) + 0.4(0.2 1 + 0.8 0) = 0.2 0 + 0.4 0.5 + 0.4 0.2 = 28%

6
Documents - Cahier des charges

e but dun cahier des charges dans un appel dore est de dcrire prcisment les e e e besoins du client en engageant ainsi la responsabilit du fournisseur. Ainsi, un e dialogue entre client et fournisseur doit tre constant an de garantir la bonne e comprhension par les deux parties et lever les ambigu es des spcications. e t e Schmatiquement, un cahier des charges doit prciser : e e le cadre gnral de la demande ainsi que les limites du projet (ce qui entre ou pas e e dans celui-ci) ; les objectifs ` satisfaire ; a les fonctionnalits et rsultats attendus ; e e les contraintes de ralisation et de mise en uvre ; e les exigences du client pour les moyens, les dlais, le suivi de qualit ; e e les mthodes danalyse et de reprsentation, les mthodes de ralisation, les contraintes e e e e techniques (langages, plate-forme).

6.1

Elaboration

Llaboration dun cahier des charges passe par direntes phases : e e Dtermination du type de cahier des charges, de la phase du projet ` laquelle il e a sapplique et ainsi ses objectif. Identication les acteurs du projet, les intervenants, les organes de dcision et de e validation. Synth`se de lanalyse des besoins : cela implique davoir une bonne connaissance e des besoins de lutilisateur et du domaine dapplication. Cet aspect passe aussi par lanalyse dtaille de lventuel syst`me existant, an den dterminer les probl`mes, e e e e e e amlioration, manques, etc. et denvisager ainsi larchitecture du nouveau syst`me e e mieux adapt ` ces besoins. ea Identication et planication des direntes tches du projet, estimation des dlais e a e et des cots. u Le cahier des charges doit tre fait de mani`re ` pouvoir voluer avec le projet, an de e e a e prendre en compte les direntes dcisions de modication ou dadaptation qui peuvent e e tre prises au cours de la ralisation, les versions de maintenance amlioratives, et senrie e e chir des remarques utilisateurs pour prparer les futures volutions. e e 25

26

6. DOCUMENTS - CAHIER DES CHARGES Il est important de dnir des crit`res dach`vement dans le cahier des charges, pere e e mettant de valider le rsultat nal. Ces crit`res doivent tre objectifs et mesurables. e e e On peut prendre en compte par exemple des crit`res de performance (vitesse de e rponse, taille des donnes, monte en charge), de dlais sans dysfonctionnement e e e e majeur, la validation de tests de rgression et fonctionnels. Cet aspect est li au e e processus de qualit, et le plan dassurance-qualit doit au mme titre tre inclue e e e e dans le cahier des charges.

6.2

Qualit du syst`me e e

Dirent crit`res de qualit peuvent tre garantis par le fournisseur ou demand par le e e e e e client. Ces dirents crit`res impliques des stratgies adaptes, tant au niveau produit (les e e e e technologies ` mettre en uvre, quau niveau processus (les mthodologies ` appliquer). a e a Voici quelques exemples de telles garanties, avec les stratgies correspondantes. e Assurance Le syst`me doit garantir un fonctionnement sans panes et sans perte de e donnes, ainsi quune scurit en terme de protection e e e Tolrance aux pannes, sauvegarde et restauration des donnes, contrle interne et e e o reprise sur panes, intgrit des donnes, redondance. Protection contre les intrusions, e e e gestion des droits dacc`s. . . e Analyse des eets dun dysfonctionnement, tests de non rgression. . . e Interoprabilit Le syst`me doit pouvoir interagir de faon transparente avec dautres e e e c syst`mes du mme type, et tre facilement remplaable e e e c Syst`me distribu, spcication des interfaces, encapsulation, utilisation de protoe e e coles et de formats standards. . . Tests dintgration, validation et tests des interfaces. . . e Facilit dutilisation Le syst`me doit tre facile ` utiliser et ` prendre en main pour e e e a a un utilisateur non spcialiste e Contrle des erreurs de saisie, aide et autoformation, paramtrage et personnalisao e tion, permettre lannulation, messages derreurs explicites, respect des conventions (raccourcis claviers, menus, etc.), utilisation de wizzard . . . Implication des utilisateurs, prototypes, respect des conventions (graphiques, vocabulaire, etc.) de lentreprise. . . Performances Le syst`me doit rpondre rapidement e e Traitement parall`les, optimisation du code, architecture quilibrs ou distribue, e e e e choix du matriel et des architectures. . . e Tests de performance, benchmarks, simulation. . . Evolutivit/Portabilit Il doit tre facile dajouter des fonctionnalits ou dadapter e e e e le syst`me ` dautres environnements e a Gnricit des dveloppements, encapsulation, paramtrage de lapplication, intere e e e e nationalisation de lapplication, lisibilit du code, syst`me distribu. . . e e e Spcications vers la portabilit, prototypage, rutilisabilit, mod`les gnriques, e e e e e e e dveloppement incrmental. . . e e

6.3. TYPE DE CAHIERS DES CHARGES

27

Co t et planning Le projet doit respecter des limites de cot et/ou de temps de u u ralisation e Modularit, rutilisabilit, dnition des fonctionnalits par domaine. . . e e e e e Utilisation de langages volus, rutilisabilit, implication des utilisateurs. . . e e e e Rutilisabilit Les composants spciques du syst`mes doivent pouvoir servir dans e e e e dautres applications fournissant les mmes fonctionnalits, ou dans dautres domaines de e e lentreprise Portabilit des fonctions, encapsulation, dnition de larchitecture par domaine, e e sparation des responsabilits. . . e e On voit bien que certaines de ces contraintes sont exclusives, et que dautres impliques des stratgies similaires. Il faut donc conseiller le client et le guider dans les garanties e quil peux exiger, et laider ` dnir ses priorits en fonction des contraintes techniques a e e et mthodologiques. e

6.3

Type de cahiers des charges

La forme du cahier des charges sera dirente en fonction du type de projet : ralisation e e spcique, choix de progiciels, acquisition et mise en place dun syst`me existant, etc. e e On peut galement dnir des cahiers des charges pour dirents domaines connexes e e e au projet : cahier des charges des interfaces, de migration, de formation des utilisateurs. . . De plus, la notion de cahier des charges peut intervenir dans toutes les phases de llaboration dune application, chaque phase prparant la suivante. e e Etude dtaille (rapport dtude prliminaire) : dnie lorientation gnrale, prsente e e e e e e e e lanalyse de lexistant (syst`me en place, autres syst`mes utilisables, etc.), les dirents e e e axes damliorations possibles, le planning prvisionnel. e e Ralisation (rapport dtude dtaille) : souvent tr`s proche de la documentation e e e e e nale (partie dveloppement). Donne les spcications gnrales et dtailles, dtaille e e e e e e e et justie les choix technologiques. Dnie galement les crit`res de validit et e e e e dach`vement, les valuations et les jeux dessais utiliss. Prsente les interfaces e e e e et la charte graphique le cas chant. e e Mise en uvre (rapport de ralisation) : prcise les scnarios de mise en place e e e (dploiement), les dirents param`tres du syst`me, les tests unitaires et dintgration. e e e e e Prcise les valuations ` mener dans lenvironnement de production. Spcie la doe e a e cumentation ` fournir, la formation des utilisateurs, etc. a

28

6. DOCUMENTS - CAHIER DES CHARGES

Bibliographie
F. P. Brooks : The mythical man-month : Essays on Software Engineering. AddisonWesley, 1975. ISBN 0-201-00650-2. M. Fowler : Continuous integration. continuousIntegration.html, 2006. http://martinfowler.com/articles/

29

30

BIBLIOGRAPHIE

Table des gures

1.1 2.1 2.2 3.1 3.2 4.1 5.1 5.2 5.3 5.4 5.5 Quelques concepts du gnie logiciel . . . . . . . . . . . . . . . . . . . . . . e Cycle de dveloppement en cascade . . . . . . . . . . . . . . . . . . . . . . e Cycle de dveloppement en V . . . . . . . . . . . . . . . . . . . . . . . . . e Phases de la planication . . . . . . . . . . . . . . . . . . . . . . . . . . . Dilemme de la gestion de projet . . . . . . . . . . . . . . . . . . . . . . . . Exemple de variation de la dure en fonction du nombre de personnes . . e Reprsentation des tches dans un PERT e a Exemple de graphe dordonnancement . . Tches successives non ordonnes . . . . . a e Tches successives ordonnes . . . . . . . a e Exemple de courbes de suivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 5 6 11 11 15 20 21 22 22 23

31

32

TABLE DES FIGURES

Liste des tableaux

4.1 4.2 5.1 5.2 Classication de la taille des projets dans Merise . . . . . . . . . . . . . . Facteurs de lajustement du coup de COCOMO . . . . . . . . . . . . . . . Exemple de tches dun projet . . . . . . . . . . . . . . . . . . . . . . . . a Exemple de tches successives . . . . . . . . . . . . . . . . . . . . . . . . . a 14 17 21 22

33

34

LISTE DES TABLEAUX

Liste des dnitions e

4.1 4.2 5.1 5.2 Charge dun projet . . . . . . . . . kilo instructions source livre kisl e Taux de consomation . . . . . . . . Taux de ralisation . . . . . . . . . e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 13 23 23

35

36

LISTE DES DEFINITIONS

Liste des exemples

37

38

LISTE DES EXEMPLES

Glossaire
C
Constructive Commercial o-the-shelf (COCOTS) Mod`le destimation bas sur COe e COMO orient vers la rutilisation de composants. e e Constructive Cost Model (Evaluation) (COCOMO) Mthode destimation de la charge e dun projet en fonction du nombre prsum de ligne de code ` crire (kisl). e e ae

P
Program Evaluation and Review Technique (PERT) Outil de gestion de projet permettant danalyser et ordonnancer les direntes tches dun projet. e a

39

40

GLOSSAIRE

Index
acteur, 6 agiles (mthodes), 7 e COCOMO, 14

41

Ce cours est encore en cours de rdaction. e 6 octobre 2011

Introduction au gnie logiciel e

(WORK IN PROGRESS)
Ce cours prsente dirents aspect du gnie logiciel, de la gestion et plannie e e cation de projets a la modlisation de syst`mes dinformation, en passant par les ` e e techniques de dveloppement logiciels. e
` A propos de lauteur: Yannick Loiseau est ma de confrences en informatre e tique ` luniversit Blaise Pascal, et travaille dans lquipe syst`mes dinformation et de a e e e communication du Limos.