Conduite et gestion de projets informatiques : une introduction

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

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

Introduction
! 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?

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, ).

Gnie logiciel
! 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.
5

Motivations
! 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
! 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.

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

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

Qualit du logiciel : facteurs internes

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

Etat des lieux

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

10

Mythes du logiciel
! Mythes du client ou usager ! Mythes du dveloppeur ! Mythes des gestionnaires

Les mythes du logiciel Mythes de lusager

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 cots dun changement pour corriger une erreur augmentent dramatiquement dans les dernires phases de la vie dun logiciel

! Les besoins du projet changent continuellement, mais ces changements peuvent tre facilement incorpors parce que le logiciel est flexible

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 ! Tant quun programme ne fonctionne pas, il ny a aucun moyen den mesurer la qualit ! Pour le succs dun projet, le bien livrable le plus important est un programme fonctionnel Ralit ! 50%-70% de leffort consacr un programme se produit aprs sa livraison lusager ! Les revues de logiciel peuvent tre plus efficaces pour dtecter les erreurs que les jeux dessais pour certaines classes derreurs ! ....

Les mythes du logiciel Mythes du gestionnaire

Mythe ! Lentreprise possde des normes, le logiciel dvelopp devrait tre satisfaisant 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 ! ....

! Les ordinateurs et les outils logiciels que lentreprise possde sont suffisants ! Si le projet prend du retard, on ajoutera des programmeurs
13

14

Matriser 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

Conduire le dveloppement
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
! 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 qualit Espace projet cots dlais
17

Acteurs dun projet (1)

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

18

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

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. Besoins Solutions Projet Satisfaction des Besoins

Matrise douvrage

Matrise duvre Conduite de Projet

19 20

Conduite de projet (2)

Conduite de projet Analyse et reporting Gestion des hommes Organisation Communication Animation Synthse et dcisions

Conduite et gestion de projet

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

!! Pour rduire ces risques :

Gestion technique Objectif Mthode Qualit

Gestion des Moyens Planification Contrle Cots Dlais

21

! Dfinir des principes de base, communs lensemble des projets afin de clarifier la terminologie ! Coordonner les intervenants ! Veiller la cohrence des diffrentes activits

22

Conduite et gestion de projet

! La conduite de projet se situe 2 niveaux
! 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

Conduite et gestion de projet Modles

1)! bass sur les livrables : modles linaires
! 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

! La fabrication dun logiciel de qualit respectant les contraintes de budget et de dlais ncessite :
! 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
A R C H I T E C T U R E

Conduite et gestion de projet Rfrentiels

E V A L U A T I O N

Cycles de vie

Mthodes de dveloppement

! 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
25

Outils

Communication

26

Cycle de dveloppement Phases

temps Vision
! ! ! ! Prelim Iteration ...

Cycle de dveloppement Itrations (1)

Arch Iteration ... Cons Cons Iteration Iteration ... Trans Iteration ...

Architecture

Premires fonctionnalits

Livraison Produit
Release Release Release Release Release Release Release Release

! !

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
27

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

28

Cycle de dveloppement Itrations (2)

Enchanement des Activits dIngnierie
Modlisation Mtier Recueil des besoins Analyse & Conception Implmentation Test Dploiement Configuration Mgmt Management Environment

Phases
Pr-tude Elaboration Construction

Une itration dans la phase d'laboration

Transition

Cycle de dveloppement Intervenants

Gestionnaire du Projet
Montage du projet

Gestion du projet

Clture du projet

temps Vision Architecture Premires fonctionnalits Livraison Produit

Enchanement des activits Support

Preliminary Iteration(s)

Iter. #1

Iter. #2

Iter. #n

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

Iter. #m

Iter. #m+1

Iterations
29

Spcialistes techniques
30

Gestion de projet Mise en uvre

ORGANISER PLANIFIER
QUOI ? COMMENT ? QUI ? QUAND? COMBIEN?

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
! 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

Replanifier si ncessaire

MESURER

Ecarts
CONTROLER
Prendre des actions correctrices
31

EXECUTER

Rfrentiel Ralisations

! Humains
! + 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
! ! ! ! ! ! Introduction Modles et activits de dveloppement Avant-Projet Suivi du projet Clture du projet Activits transverses

Modles de dveloppement
! 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
! 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:
! 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).

Modle en cascade
Expression des besoins

Analyse Conception Implmentation Tests Maintenance

35

36

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 Analyse et spcification

Modle en V
Validation des besoins Validation fonctionnelle Tests du systme Tests des composants

Conception du systme Conception des composants

Implmentation
37 38

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.

Modle en spirale

Analyse Conception Spcifications

Implmentation Tests
39

Validation

40

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.

Processus unifi

! 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
! 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 :
! ! ! ! ! ! ! ! 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
43

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

! Activits :
! simulation de diffrents scnarios de dveloppement

! Rsultats :
! 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.)

44

Spcification des besoins

! Objectifs :
! dfinition de ce que doit faire le logiciel

Analyse
! Objectifs :
! Analyse dtailles de toutes les fonctions et autres caractristiques que le logiciel devra raliser pour lusager, telles que vues par lusager.

! 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

! Activits :
! 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

! 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)
45

! Rsultats : Dossier danalyse et plan de validation

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

Conception
! Objectifs :
! Dfinition de larchitecture gnrale du logiciel. Spcification de la manire dont chacun des composants du logiciel sera ralis et comment ils interagiront.

Implmentation
! Objectifs :
! Ralisation des programmes dans un (des) langage(s) de programmation ! Tests selon les plans dfinis lors de la conception

! Activits :
! Rpondre au Comment raliser le systme ! Dcomposition modulaire, dfinition de chaque constituant du logiciel : informations traites, traitements effectus, rsultats fournis, contraintes respecter

! Activits :
! traduction dans un langage de programmation, ! Mise au point (dboguage)

! 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

! Rsultats : dossiers de programmation et codes sources.

! Collection de modules implments, non tests ! Documentation de programmation qui explique le code

48

Tests unitaires
! Objectifs :
! test spar de chacun des composants du logiciel en vue de leur intgration

Intgration et test du systme

! Objectifs :
! Intgration des modules et test de tout le systme

! Activits :
! 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

! 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

! 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

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

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

! Activits :
! Tests Bta : distribution du produit sur un groupe de clients avant la version officielle, ! Livraison tous les clients, ! Maintenance : corrective, adaptative, perfective.

! Rsultats : la version finale du manuel utilisateur, les traces dvolution du systme, les rapport dexploitation
! Produit et sa documentation ! Trace dexploitation et dvolution

! Suivi du projet ! Clture du projet ! Activits transverses

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
! Rle :
! 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

Planification structurelle Etapes

! Planification structurelle sommaire
! 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
! 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

55

56

Planification structurelle Product Breakdown Structure

Fait partie de

Planification structurelle Work Breakdown Structure

Dfinition S-systme 2 Dfinition systme Ralisation S-systme 1 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

Systme Sous-systme 1 Sous-systme 2

Est-compos de

Sous-systme 3

Projet

Ralisation S-systme 2 Ralisation S-systme 3 Intgration systme

Ensemble 1

Ensemble 2

Ensemble 3

Dcoupage du systme en units physiques hirarchises

57

Description structure de toutes les tches du projet, Rapportes au dcoupage du produit

58

Planification oprationnelle
! Toute tche est assigne une personne ! Tout participant est inform de :
! ses rles et responsabilits ! son degr dautonomie et dautorit ! des rles et responsabilits des autres ! Rle

Planification oprationnelle
! 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

! 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
Df. Syst. Ral. S-syst. 1 Df. S-syst. 2

Planification oprationnelle
! Organisation dans le temps des activits
! Activits/Dpendances :
! Contraintes temporelles entre activits, ! Structure logique des activits

Ensemble 21

Ensemble 22 Ensemble 23 Intgration s-syst 2 Ral. S-syst. 3

Ral. S-syst. 2

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

Intgration syst.

t
61

! La planification est un processus dynamique tenant compte de la situation relle, des nouvelles informations acquises
62

Planification oprationnelle
! 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

GanttProject

! 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
63

http://ganttproject.biz/
64

Estimations (1)
! Pourquoi ?
! Connatre le cot dune vue de lesprit qui deviendra ralit au bout dun temps fini

Estimations (2)
! Qualit de lestimation
! 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
! ! ! ! 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)
65

! Limites
! 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
66

Estimation Dmarche et conseils

! Dmarche
! Entres : objectifs techniques, objectifs de dlais, environnement, priode, historique, rfrences ! Sorties : estimation ! Itrations : augmenter linformation et comparer avec le rsultat
! Par analogie ! Modle paramtrique

Estimation Mthodes
! Exploration des expriences passes, catalogue des projets et estimations passes. Ce qui est analys concerne : taille, dure, effort, complexit, cot ! Les estimations sont bases sur des modles mathmatiques reposant sur divers paramtres : COCOMO, SLIM, PRICE-S, SoftCost,

! Conseils
! ! ! ! ! ! ! ! ! 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
67

! !

Oracle
! Equipe dexperts, atteinte dun consensus par ngociation

PERT
! 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. 68

Estimation Taille du logiciel

! Point fonction mesure du montant de fonctionnalit en sappuyant sur :
! 5 type de fonctionnalits :
! Input, Output, Inquiry, Internal Logical File, External Interface File

Estimation Types de fonctionnalits

! Input (entre utilisateur)
! Entre de donne ou de contrle qui requiert un traitement ! crans, transactions, fichier de donnes, etc.

! Output (sortie utilisateur)

! 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)
! Communication par message, distribution de donnes ou de fonctions, haut taux de transaction, calcul complexe, conception multi-sites, conception facilement maintenable,

! Internal files (fichiers internes)

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

! External interface files (fichiers externes)

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

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

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

! Inquiry (requtes)
! Entre ou sortie d'une requte demandant une rponse immdiate du systme ! Interruptions, appels, etc.

69

70

Estimation Facteurs dinfluence

! Interconnections ! Distribution des fonctions ! Performance ! Utilisation oprationnelle lourde ! Taux de transaction ! Entre de donnes en ligne ! Facilit dutilisation ! ! ! ! ! ! ! Mise jour en ligne Traitements complexes Rutilisation du code Facilit d'installation Facilit d'opration Sites multiples Flexibilit

Effort ? Dure ? Taille ?

! Effort ou charge : quantit de travail ncessaire, indpendamment du nombre de personnes qui vont raliser ce travail
! 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 ?

! ! ! ! ! ! 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
! ! ! !

Effort ? Dure ? Taille ?

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

Effort ? Dure ? Taille ?

! 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

Estimation COCOMO
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

! 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 .
75

! 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
76

Estimation COCOMO (simple)

! HM : Homme-mois = 152 h
HM
1200 1000 800 600 400 200 0 organique dtach

Estimation COCOMO (intermdiaire)

! Point de dpart : HM et TDEV du modle simplifi ! Introduction de quinze facteurs correctifs, valus de VeryLow XtraHigh
! Pour le projet :
! Fiabilit requise du logiciel ! Taille de la base de donnes ! Complexit du produit
semi-dtach

! 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
0 10 20 30 40 50 60 70 80 9 100 110 120 0
KLSL

! Pour le personnel
! ! ! ! ! Aptitude lanalyse Exprience du domaine Exprience de la machine virtuelle Aptitude la programmation Exprience du langage

! Pour les contraintes de lenvironnement

! 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

! Effectif crot jusqu limplmentation, dcrot ensuite

mois

TDEV 30 25 20 15 10 5 0
0

! Pour les mthodes

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

! TDEV : temps de dveloppement

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

organique semi-dtach dtach

KLSL

100

60

20

40

80

77

78

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

Suivi de projet

79

80

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 :
! des informations communiques ! des problmes rencontrs ! des dcisions prises ! des responsables dsigns pour mener bien les actions ! la date de ralisation de l'action
81

Suivi de projet
! 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 :
! 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

82

Matrise des ressources

! La matrise des ressources implique :
! 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)

Contrle
! Activit dacquisition des informations sur la progression du projet
! Ce qui est complt ! Les ressources effectivement utilises ! La date de dbut et de fin

! Cette capacit demande davoir des points de repre

! Cest la planification du projet

! Ce qui en en cours : % d avancement

! La date de dbut, ressources utilises : matriaux, quipement, main duvre

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

Suivi de lavancement Analyse

! But : vrifier si la situation actuelle est telle que prvue ! Compilation des informations recueillies
! Calcul des cots effectivement engags et dbourss ! Validation de l estim du % d avancement ! Nature exacte des problmes rencontrs (recherche des causes

Suivi de lavancement Causes dcart (1)

! Performance technique
! 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

! Analyse prvisionnelle - valeur acquise

! Comparaison avec la situation prvue

! Slection de mesures correctives

! Proposition et analyse de l effet de mesures correctives ! Recommandations

! Cots
! 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
85 86

Suivi de lavancement Causes dcart (2)

! chanciers
! 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)

Suivi de lavancement Conseils lmentaires

! 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

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

87

88

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

Clture de projet (1)

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

90

Clture de projet (2)

! 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

Evaluation (1)

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

94

Gestion des versions et des volutions (1)

! 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

Gestion des versions et des volutions (2)

! 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
! Documentation de gestion du projet
! ! ! ! ! Plannings, plans, estimations Rapports Dfinitions de standards Documents de travail Courriers (mls)

Documentations Structure dun document

! Un document comporte ncessaire une page den tte :
! 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 !
97 98

! 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

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.

Documentations de gestion de projet

! ! ! ! ! ! !

99

100

Documentations techniques

Documentations qualit

101

102

Document danalyse
1.! 2.! 3.! 4.! 5.! 6.! 7.! 8.! 9.! Vision gnrale Spcification prliminaire Dfinition des cas dutilisation Spcification dtaille Cas dutilisation Exemples Collaborations Diagrammes dtat Graphes dactivit

Document danalyse Vision gnrale

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

2.1 Dictionary
! This provides the list of terms used in the document, accompanied by their definition.

Document danalyse : Dfinition des cas dutilisation

User packages The "Definition of the use cases" chapter contains:
! 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 106

Document danalyse Spcification dtaille

4.1 Non-user packages 4.2 Classes 4.3 Interfaces 4.4 Referenced packages 4.5 Referenced classes 4.6 Referenced interfaces

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
107 108

Les outils
! Outils ddis des tches spcifiques ! Ateliers de gnie logiciel (AGL) :
! ! ! ! ! Analyse et conception Programmation, prototypage ou dveloppement rapide (RAD) Construction dinterface homme-machine Vrification Documentation, version, collaboratif

Les Hommes (1)

! Dveloppement logiciel est une tche humaine et crative ! Travail en groupe : Travail collaboratif, Productivit personnelle, Disponibilit doutils de travail collaboratif ! Structure homogne (petits projets) :
! 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

! Environnement intgrs pour un support tout le dveloppement

! Structure spcialise (grands projets) :

109

! Structuration selon les spcialits

110

Les Hommes (2)

! Rle du chef de projet
! Comptences techniques
! ! ! ! Spcification Architecture Outils de dveloppement Tests

Les Hommes (3)

! Programmation impersonnelle
! 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 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

! Programmers (system engineers)
! Technical lead, architect, programmer, Sr. programmer

Rles au sein dun projet

! Dcider lesquels sont ncessaires pour votre projet ! En fonction de ce que vous tes en train de dvelopper :
! ! ! ! ! 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?

! 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

! En fonction de votre budget

113

114

Modles dquipe
! Two early philosophies
! Decentralized/democratic ! Centralized/autocratic ! ! ! ! !

Modles dquipe
! Business Team
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

! Variation
! Controlled Decentralized

115

116

Modles dquipe
! Chief-Programmer Team
! From IBM in 70s
! See Brooks and Mythical Man-Month

Modles dquipe
! Skunkworks Team
! Put a bunch of talented, creative developers away from the mother ship
! Off-site literally or figuratively

! a.k.a. surgical team ! Puts a superstar at the top

! Others then specialize around him/her ! Backup Programmer ! Co-pilot or alter-ego ! Administrator ! Toolsmith ! Language lawyer

! Pro: Creates high ownership & buy-in ! Con: Little visibility into team progress ! Applicable: exploratory projects needing creativity
! 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
! SWAT Team
! ! ! ! Highly skilled team Skills tightly match goal Members often work together Ex: security swat team, Oracle performance team

Modles dquipe
! Large teams
! 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
! What is the optimal team size?
! 4-6 developers
! Tech lead + developers
! ! ! ! ! ! !

Rfrences
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
! ! http://www.retisoft.com/SCEPFeatures.html http://www.construx.com/estimate http://ourworld.compuserve.com/homepages/softcomp/fpfaq.htm http://www.4pm.com/articles/selpmsw.html http://www.infogoal.com/pmc/pmcswr.htm 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

! Small projects inspire stronger identification ! Increases cohesiveness ! QA, ops, and design on top of this

! !

FAQ on Function Points

! ! !

Choosing a project management tool

Project management tools

! ! ! ! ! ! !

121

122