Projet

• Ensemble d’actions à entreprendre afin de

Gestion de Projets répondre à un besoin défini dans des délais
fixés, mobilisant des ressources humaines et
Informatiques matérielles, possédant un coût.

qualité

Une partie du matériau de ce cours est adaptée du cours de Michel Desmarais Ecole Polytechnique Montréal

O. Boissier, SMA/G2I/ENS Mines Saint-Etienne, [Link]@[Link], Septembre 2004 coûts délais

2

Acteurs d’un projet Conduite de projet

• Maître d’ouvrage personne physique ou Organisation méthodologique mise en œuvre pour faire en
morale propriétaire de l’ouvrage. Il détermine sorte que l’ouvrage réalisé par le maître d’œuvre réponde
aux attentes du maître d’ouvrage dans les contraintes de
les objectifs, le budget et les délais de délai, coût et qualité.
réalisation.
Solutions
• Maître d’œuvre personne physique ou Besoins Satisfaction des
Projet Besoins
morale qui reçoit mission du maître
d’ouvrage pour assurer la conception et la
réalisation de l’ouvrage.
Conduite
de
3 Projet 4
 Conduite de projet Cycle de développement
Direction de
projet Pré-étude
Synthèse et décisions
Analyse et reporting Elaboration

Gestion des Gestion Gestion des Statut-quo

hommes technique Moyens
Construction
Organisation Objectif Planification
Communication Méthode Contrôle Transition
Animation Qualité Coûts Délais

5 6

Phases du cycle de Itérations

développement
Pré-étude Elaboration Construction Transition
Pré-étude Elaboration Construction Transition

temps Prelim ... Arch ... Cons Cons ... Trans ...
Iteration Iteration Iteration Iteration Iteration

Vision Architecture Premières Livraison

fonctionnalités Produit

• Pré-étude : Définition de la portée du projet et développement des cas Release Release Release Release Release Release Release Release
• Vision : Glossaire, Détermination des parties prenantes et des utilisateurs, Détermination de leurs
besoins, Besoins fonctionnels et non fonctionnels, Contraintes de conception
• Elaboration : Planification du projet, spécification des caractéristiques, des Une itération est une séquence d’activités selon un plan pré-établi et
fondements de l’architecture des critères d’évaluation, résultant en un produit exécutable.
• Architecture : Document d’architecture Logicielle, Différentes vues selon la partie prenante, Une
architecture candidate, Comportement et conception des composants du système
• Construction : Construction du produit
• Transition : Préparation du produit pour les utilisateurs
7 8
Itérations (2) Une itération
Phases du cycle de
dans la phase

Enchaînement des Phases

d'élaboration
développement
Activités d’Ingénierie Pré-étude Elaboration Construction Transition Gestionnaire du Projet
Modélisation Métier
Recueil des besoins Montage Clôture
Gestion du projet
Analyse & Conception du projet du projet

Implémentation Pré-étude Elaboration Construction Transition

Test
Déploiement temps

Configuration Mgmt Vision Architecture Premières Livraison

Management fonctionnalités Produit
Environment
Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Enchaînement des Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1

activités Support Iterations

Spécialistes techniques
9 10

Cycle de vie Plan

• Avant-Projet
• Estimation
• Planification
• Gestion du projet
• Fin de projet
• Activités transverses
• Gestion de configurations
• Documentations
8/10 22/10 3/12 • Les outils
• Les Hommes

11 12
 Estimations Estimations :
• Pourquoi ?
• Connaître le coût d’une “vue de l’esprit” qui deviendra réalité … au bout d’un temps fini.
démarche et conseils
• Quoi ?
• L’effort de développement (coût), la durée du projet (temps), autre (équipement, voyage, • Démarche
formation), ajouter (la logique des calculs, les hypothèses=
• Entrées : objectifs techniques, objectifs de délais, environneme nt, période,
• Quand ? historique, références
• Tout au long du cycle de vie du projet • Sorties : estimation
• Pièges à éviter • Itérations : augmenter l’information et comparer avec le résultat
• Faire trop précis (Æ travailler avec des marges d’erreur importantes)
• Sous-estimer (Æ être exhaustif dans la liste des choses à estimer)
• Conseils :
• Sur-estimer (Æ ne pas intégrer systématiquement tous les coûts possibles) • Toute information est bonne à prendre et à classer
• Confondre objectif et estimation (Æ résister à “il ne faut pas que ça coûte plus de …”) • Les projets déjà réalisés sont la meilleure source (Æ tableau de bord)
• Vouloir tout estimer (Æ savoir avouer son ignorance) • Exploiter les offres de ses fournisseurs
• Qualité de l’estimation • Adhérer aux associations professionnelles
• Rendue dans les délais, homogène en précision, honnête, complète, hypothèses • Lire les revues spécialisées de sa profession
explicites, réaliste, proche du coût réel • Être organisé, être créatif, affûter ses outils
• Qualités de l’estimateur • Constituer une check-list
• Utile au client, organisé, objectif, compétent, créatif, réaliste, manie l’analogie
• Vérifier ses estimations
• Limites :
• Remettre à jour ses données
• manque de données historiques pour faire l'estimation, nouvelles technologies, manque
d'expérience en estimation, oublis, productivité n'est pas « 40 heures/semaine », 13 14
optimisme non fondé.

Estimation : Estimation :
méthodes Taille du logiciel
• Par analogie
• Exploration des expériences passées, catalogue des projets et estimations passées. • Points de fonction :
Ce qui est analysé concerne : taille, durée, effort, complexité, coût
• Modèle paramétrique
• Composant identifiable et unique (fonction)
• Les estimations sont basées sur des modèles mathématiques reposant sur divers • 5 types de fonctions :
paramètres : COCOMO, SLIM, PRICE-S, SoftCost, … • Input, Output, Inquiry, Internal Logical File, External Interfac e File
• Oracle
• Equipe d’experts, atteinte d’un consensus par négociation • Compter le nombre de fonctions (FC)
• PERT • Ajuster selon leur complexité (ci) à partir de 14 facteurs
• Estimations reposant sur l’hypothèse d’une répartition normale des estimations
• Réaliser plusieurs estimations avec une méthode “par analogie” ou “oracle” Æ la pire
notés de 0 (pas d’influence) à 5 (fondamental)
(l), la moyenne (m), la meilleure (h) • Communication par message, distribution de données ou de
• Effort = (l+4m+h)/6 fonctions, haut taux de transaction, calcul complexe, conception
• Bottom-up multi-sites, conception facilement maintenable, ..
• Les estimations par analogie, PERT, paramétrique, oracle sont faites par activité ou
composant élémentaire • FP = FC * PCA PCA = 0,65+0,01 Somme(ci)
• Puis consolidées jusqu’au sommet du projet
• Aucune technique n’est meilleure ou pire que les autres. • KLSL = -5 + 0,2 FP
• Utiliser plusieurs techniques en parallèle et comparer les résultats : si trop de
différence, augmenter la quantité d’informations prises en compte. 15 16
 Estimation : Estimation :
Types de fonction Facteurs d’influence
• Entrée utilisateur: • Interconnections • Mise à jour en ligne
• Entrée de donnée ou de contrôle qui requiert un traitement.
• Écrans, transactions, fichier de données, etc. • Distribution des • Traitements complexes
• Sortie utilisateur: fonctions
• Sortie de donnée ou de contrôle après un traitement du système. • Réutilisation du code
• Écrans, transactions, fichier de données, etc.
• Performance
• Facilité d'installation
• Fichier interne: • Utilisation
• Regroupement logique de données ou de contrôle interne au système. opérationnelle lourde • Facilité d'opération
• Bases de données, répertoires, etc.
• Interface externe: • Taux de transaction • Sites multiples
• Fichier ou exécutable qui sortent des limites du système. • Entrée de données en • Flexibilité
• Bibliothèques , bases de données externes, paquetages génériques, etc.
ligne
• Requête externe:
• Entrée ou sortie d'une requête demandant une réponse immédiate du • Facilité d’utilisation
système.
• Interruptions, appels, etc.
17 18

Estimations : Estimation :
COCOMO [Link] COCOMO (simple) 1200

1000

• Modèle paramétrique • HM : Homme/mois = 152 h 800

organique

HM
600 semi-détaché
détaché

• Hypothèse : les besoins du logiciel sont relativement • Organique : HM = 2,4 (KLSL) 1,05 400

200

stables, le projet est géré à la fois par le client et par le • Semi-détaché : HM = 3,0 (KLSL) 1,12 0

0
10

40

70

0
110
120
20
30
50
60
80
100
9
fournisseur • Détaché : HM = 3,6 (KLSL) 1,20 KLSL

• Formule d’estimation : Effort = A (KLSL) b • Attention : nombre de personnes employées sur un

• KISL : Kilo Lignes Sources Livrées : ligne source quelque soit le projet n’est pas uniforme pendant le temps de
nombre d’instructions par ligne, sans tenir compte des développement TDEV
commentaires ni du logiciel support
• Effectif croît jusqu’à l’implémentation, 30
• A et b estimées à partir de l’analyse des historiques décroît ensuite 25

• A et b dépendent des trois classes de projet : 20

• TDEV : temps de développement organique

mois
• Organique : petites équipes (faible communication, distribution efficace 15 semi-détaché
détaché
du travail, …), environnement stable, applications bien comprises • Organique : TDEV = 2,5 (HM) 0,38 10

5
• Semi-détaché : équipe de taille moyenne (personnes expérimentées,
débutants), problèmes ne sont pas tous maîtrisés • Semi-détaché : TDEV = 2,5 (HM) 0,35 0

0
20

40

60
80

100
• Détaché : grande équipe, répartie, nouvel environnement
19
• Détaché : TDEV = 2,5 (HM) 0,32 KLSL
20
 Estimation :
Planification
COCOMO (intermédiaire
(intermédiaire))
• Point de départ : HM et TDEV du modèle simplifié
• Introduction de quinze facteurs correctifs, valués de VeryLow à XtraHigh
• Pour le projet :
• Fiabilité requise du logiciel
• Taille de la base de données
• Complexité du produit
• Pour les contraintes de l’environnement
• Contraintes de temps d’exécution
• Contraintes de place mémoire
• Stabilité de la machine virtuelle (matériel + logiciel) sur lequel le logiciel est développé
• Système de développement interactif ou non
• Pour le personnel
• Aptitude à l’analyse
• Expérience du domaine
• Expérience de la machine virtuelle
• Aptitude à la programmation
• Expérience du langage
• Pour les méthodes
• Méthode de programmation moderne
• Outils logiciels
21 22
• Durée de développement

Planification Planification structurelle

• Rôle :
• Outil incontournable pour la gestion du projet. • Identifier les travaux à compléter
• permet de : • Traduire la définition du projet en une liste de tâches à accomplir
• définir les travaux à réaliser, • préparer une liste exhaustive, documentée et structurée des travaux
dont l’accomplissement est nécessaire à la production des biens
• fixer des objectifs, livrables du projet.
• coordonner les actions, Æ Constitution d’une base de données des travaux
• maîtriser les moyens, • Sert de base aux autres étapes de planification
• diminuer les risques, • Principal instrument de communication entre les intervenants

• suivre les actions en cours, • Identification et description des lots de travail principaux
• rendre compte de l'état d'avancement du projet. • Identification et description des tâches élémentaires

23 24
 Planification structurelle Planification structurelle :
Etapes Product Breakdown Structure
• Planification structurelle sommaire
• Subdiviser le projet en lots de travail
• Un lot = un bien livrable du projet Fait partie Est-composé
de … Système de …
• Toujours prévoir les lots de support pour tâches ponctuelles
• Planification structurelle détaillée
• Subdiviser les lots de travail principaux Sous-système 1 Sous-système 2 Sous-système 3
• Jusqu’à l’identification de tâches élémentaires
• Représentation à l’aide d’un organigramme de tâche (Work
Breakdown Structure)
• Conformité et complétude Ensemble 1 Ensemble 2 Ensemble 3
• On doit avoir suffisamment confiance dans le caractère exhaustif de
la liste des tâches pour être assuré que, une fois complétée de
façon suffisante chacune des tâches élémentaires y apparaissant, le
produit visé est effectivement réalisé et conforme aux exigences
initiales. Découpage du système en unités physiques hiérarchisées
25 26

Planification structurelle :
Planification opérationnelle
Work Breakdown Structure Définition
Ensemble 21
Définition
S-système 2 Réalisation • Toute tâche est assignée à une personne
Ensemble 21
Définition
système Intégration • Tout participant est informé de:
Réalisation Ensemble 21
Réalisation
S-système 1
Ensemble 21 • ses rôles et responsabilités
Définition

Réalisation Réalisation
Ensemble 22 • son degré d’autonomie et d’autorité
Projet
S-système 2 Ensemble 22 Réalisation
Ensemble 22 • des rôles et responsabilités des autres
Réalisation
Intégration
S-système 3 Réalisation
Ensemble 23 Ensemble 22 • Données de départ:
Intégration
système Définition • Organigramme technique
Intégration Ensemble 23
S-système 2
Réalisation
• Processus de développement
Ensemble 23
Description structurée de toutes les tâches du projet,
Rapportées au découpage du produit. Intégration
Ensemble 23 27 28
 Planification opérationnelle Planification opérationnelle
Déf. Syst.
Réal. S-syst. 1
• Rôle :
• Créer un réseau ordonnancé d’activités à partir des tâches de
l’organigramme technique Déf. S-syst. 2
• Estimer de la durée d’une activité et des ressources requises pour la
compléter
Ensemble 21
• Identifier le chemin critique dans un réseau ordonnancé et calculer
les marges totales, libres et d’indépendance
• Utiliser les différents modes de présentation des résultats Ensemble 22 Réal. S-syst. 2

• Caractéristiques :
Ensemble 23
• Forme la base pour la planification et la prédiction d’un projet.
Facilite le choix des ressources pour compléter un projet à l’intérieur
des échéanciers et du budget. Intégration s-syst 2

• Fournit les renseignements nécessaires pour prendre des décisions. Réal. S-syst. 3

• Identifie les dépendances entres les activités Intégration syst.

• Identifie le chemin le plus long: le chemin critique t
• Permet d’effectuer l’analyse des risques d’échéancier. 29 30

Planification opérationnelle Planification opérationnelle

• organisation dans le temps des activités • Diagramme Pert :
• Activités/Dépendances : • graphe ordonné décrivant les contraintes de précédence
• Contraintes temporelles entre activités, logique des activités.
• Structure logique des activités • Lister les tâches.
• Ressources associées aux activités • Indiquer la charge de chacune.
• Durée d’une activité : durée dans le meilleur des cas, • Préciser les liens de dépendance entre tâches.
ajout d’un délai de garantie, pondération pour tenir
compte de l’imprévu • Classer les tâches selon leur rang
• La planification est un processus dynamique tenant • Diagramme de Gantt :
compte de la situation réelle, des nouvelles • calendrier sur lequel chaque activité est représentée par
une barre grisée débutant à la date de début au plus tôt
informations acquises.
et terminant à la date de fin au plus tard, sur laquelle
glisse une barre blanche correspondant aux dates
réelles de début et de fin.
31 32
 Plan Suivi de l’avancement
• Avant-Projet
• Estimation
• Planification
• Gestion du projet
• Fin de projet
• Activités transverses
• Gestion de configurations
• Documentations
• Les outils
• Les Hommes

33 34

Suivi de l’avancement Suivi de l’avancement

• Mettre en place un processus de suivi et de revues • Cette fonction consiste à évaluer la situation réelle
régulières entre le chef de projet et les membres du projet, à la comparer à la situation prévue au
de l'équipe. plan d’exécution et à prendre les décisions
• Un "journal de bord" est tenu à jour. Il permet de nécessaires pour corriger la situation, si des écarts
garder une trace : sont observés ou prévus.
• des informations communiquées, • La maîtrise des ressources et la gestion de la
• des problèmes rencontrés, qualité du produit :
• des décisions prises, • sont des fonctions en cours de réalisation du projet
• des responsables désignés pour mener à bien les quelle que soit la phase atteinte dans la progression du
actions projet;
• la date de réalisation de l'action. • impliquent une base de comparaison que constitue le
plan de réalisation, produit de la planification du projet et
de l’utilisation des ressources.
35 36
 Suivi de l’avancement : Suivi de l’avancement :
Maîtrise des ressources Contrôle
• La maîtrise des ressources implique: • Activité d’acquisition des informations sur la
• capacité d’expliquer les difficultés rencontrées au plan progression du projet
technique • Ce qui est complété
• capacité d’expliquer les retards et les dépassements de • Les ressources effectivement utilisées
coût • La date de début et de fin
• capacité de proposer des mesures correctives, d’en
évaluer les répercussions et de les mettre rapidement en • Ce qui en en cours: % d ’avancement
œuvre • La date de début, ressources utilisées : matériaux,
• capacité à répondre à des conditions changeantes du équipement, main d ’œuvre
milieu (le projet, son environnement) • Questions à résoudre:
• Cette capacité demande d’avoir des points de • Quoi documenter? À quelle fréquence?
repère • Avec quelle résolution? Problèmes rencontrés?
• C’est la planification du projet
37 38

Suivi de l’avancement : Suivi de l’avancement :

Analyse causes d’écart
• Performance technique
• But : vérifier si la situation actuelle est telle que •
•
Occurrence d ’un problème technique imprévu
Difficultés techniques majeures dont la mise en relation de diverses composantes
prévue •
•
Problème de fiabilité dans les matériaux, les équipements achetés
Changement imposé par le client

• Compilation des informations recueillies •

•
Apparition d ’un nouveau produit sur le marché
Révision des spécifications techniques
• Coûts
• Calcul des coûts effectivement engagés et déboursés • Difficulté de financement
• Difficultés techniques imposant l ’utilisation de plus de ressources humaines ou d ’équipement
• Validation de l ’estimé du % d ’avancement • Majoration des coûts des matériaux, de la main-d’œuvre, de l’énergie, etc.

• Nature exacte des problèmes rencontrés (recherche des •

•
Monitoring erroné
Délai dans la mise en œuvre des mesures correctives
causes • Estimation initiale incorrecte
• Échéanciers
• Analyse prévisionnelle - valeur acquise •
•
Durée plus longue que prévue pour compléter une activité, pour résoudre un problème technique
Durée requise pour résoudre un problème nouveau
• Comparaison avec la situation prévue •
•
Mauvaise estimation de la durée des activités à réaliser
Pénurie de ressources humaines, matérielles et d’équipement

• Sélection de mesures correctives • Répercussions des retards de réalisation des activités qui précèdent sur la durée des activités à venir, sur leur
programmation, etc. (Boucle de rétroaction positive)
• Mise en œuvre
• Proposition et analyse de l ’effet de mesures correctives • Approbation des mesures retenues
• Communication aux personnes concernées
• Recommandations 39 • Mise en application 40
 Suivi de l’avancement
Plan
Conseils élémentaires
• Toujours donner l’heure juste • Avant-Projet
• S’assurer que le coût du contrôle, de l’analyse et • Estimation
de la mise en œuvre demeure inférieur aux • Planification
bénéfices espérés du suive et du contrôle des
ressources • Gestion du projet
• Ne prendre que les informations pertinentes à la • Fin de projet
maîtrise des ressources et de la qualité du produit • Activités transverses
• Vérifier que le contrôle et l’analyse se font • Gestion de configurations
rapidement pour que les mesures correctives
• Documentations
demeurent d’actualité
• Organiser le contrôle autour des biens livrables • Gestion des hommes
41 42

Clôture de projet (1) Clôture de projet (2)

• Inévitablement, les projets se terminent; il est dans la définition même • En situation normale, « clôturer » un projet désigne une
d’un projet qu’il ne dure qu’un temps précis dans la vie d’une série d’activités que doit réaliser les responsables du projet.
organisation. Les façons dont les projets se terminent peuvent toutefois
varier. L’utilisation de listes de vérification est fréquente lors de la
• Fin « normale » d’un projet
fermeture de dossiers.
• La plupart des projets se terminent favorablement avec la livraison du • S’assurer de la fin de l’ensemble des travaux, incluant les
produit ou du système au client; ce client peut être à l’interne de tâches en sous-traitance
l’organisation, projet d’implantation d’équipement dans une usine , ou à
l’externe, projet de construction, projet de sous-traitance industrielle. • Validation du client comme quoi il a reçu le produit/système
• Fin « normale » d’un projet et intégration à l’organisation et les autres livrables
• Dans certains cas de projets, surtout lorsque le client est interne, il arrive • S’assurer que la documentation est à jour et que les
très fréquemment qu’on invite les membres de l’équipe à devenir ou
redevenir membres à part entière à l’organisation. On parle donc
rapports de clôture ont été réalisés (si requis)
d’intégration des résultats et des ressources du projet. • Régler les dernières transactions financières (facturation)
• Fin d’un projet avorté • Relocalisation du personnel, des équipements, des
• Il peut arriver qu’on doive arrêter un projet pour des questions techniques,
budgétaires ou légales. Des procédures doivent alors être prises pour
matériaux
compenser, s’il y a lieu, la ou les parties lésées. 43 • Consolider la documentation à conserver 44
 Evaluation (1) Evaluation (2)

45 46

Gestion des versions et des

Plan
évolutions (1)
• Avant-Projet • Numérotation à trois chiffres :
• Estimation • 1er chiffre : Numéro de versions majeures du produit, don’t la sortie
s’accompagne de progrès importants au niveau des fonctionnalités,
• Planification et/ou changement notable d’environnement d’utilisation ou de
portabilité
• Gestion du projet
• 2ème chiffre : numéro des version mineures. L’incrément est réalisé
• Fin de projet à chaque fois que l’équipe de développement libère une version du
produit qui corrige des bugs attendus par les clients (mais non
• Activités transverses bloquants), et apporte des modifications légères.
• Gestion de configurations • 3ème chiffre : numéro des corrections, versions résultant de la
maintenance.
• Documentations
• Les outils • Version Alpha : version terminée en cours de test et de
revue de qualité
• Les Hommes
• Version Béta : version alpha validée en test auprès d’un
panel de clients privilégiés
47 48
 Gestion des versions et des
Documentations
évolutions (2)
• Documentation de gestion du projet
• Plannings, plans, estimations
• Rapports
• Définitions de standards
• Documents de travail
• Courriers (mels)
• Documentation Technique
• Utilisateur : Manuel d’installation, manuel d’administration, manuel
d’utilisation, manuel de référence
• Système : cahier des charges, analyse et conception du système,
architecture du système , archivage des programmes et des listings,
documents de validation, documents de tests, guide de
maintenance.

49 50

Documentations : structure Documentations : style

d’un document rédactionnel
• Un document comporte nécessaire une page d’en tête : • Séparer clairement les paragraphes qui peuvent être perçus comme des réponses aux
• Qui le situe dans le projet (référenc de projet, auteurs, catégorie du questions quoi ?, par qui ?, où ?
document) • Identifier des niveaux de texte correspondant à des lectures plus ou moins détaillées.
• Qui décrive sommairement son contenu (titre parlant, résumé) Trois niveaux : titre, corps principal de texte, texte
• Qui le date et donne sa version • Mentionner en notes de bas de page les considérations à caractère anecdotique qui
même si elles éclairent le sujet perturbent la compréhension d’une phrase
• Qui en permette l’archivage (mot clef, type de document) • Mettre en évidence la première apparition d’un terme dans le texte, et surtout une
• Qui décrive les standards auquel le document est supposé se mention qui le définit, par exemple, en utilisant des caractères gras. Une définition ne doit
conformer pas pouvoir échapper à l’attention, même lors d’une lecture rapide
• Qui en décrive le copyright • Écrire des phrases et des paragraphes courts
• Qui en décrive la circulation souhaitée (nominatif et/ou classement • Ne pas utiliser de double négation
de confidentialité) • Utiliser des formes verbales actives, impératives et le présent
• Avoir une bonne orthographe et une bonne grammaire
• Qui donne un contact pour questions ou remarques
• Définir les termes utilisés : un glossaire doit impérativement accompagner tout document
• Qui dise s’il s’agit d’une version préliminaire (de travail) ou définitive
• Se répéter si nécessaire
• … • Donner des références explicites.

51 52
Documentations Gestion
Documentations Techniques
Projet

53 54

Documentations Qualité Les outils

• Outils dédiés à des tâches spécifiques
• Ateliers de génie logiciel (AGL) :
• Analyse et conception
• Programmation, prototypage ou développement rapide
(RAD)
• Construction d’interface homme-machine
• Vérification
• Documentation, version, collaboratif
• Environnement intégrés pour un support à tout le
développement
55 56
 Les Hommes (1) Les Hommes (2)
• Développement logiciel est une tâche humaine et • Rôle du chef de projet
créative • Compétences techniques
• Travail en groupe : Travail collaboratif, Productivité • Spécification
personnelle, Disponibilité d’outils de travail • Architecture
collaboratif • Outils de développement
• Tests
• Structure homogène (petits projets) : • Compétences administratives et organisationnelles
• structure de l’équipe reflète la structure du produit, • Gestion administrative
chaque membre réalise une partie du projet • Allocation de ressources
• Bonne communication entre les membres, continuité du • Animation des équipes
projet est facile à assurer • Trop pour une seule personne
• Structure spécialisée (grands projets) : • Deux responsables (technique et administratif)
• Structuration selon les spécialités
57 58

Les Hommes (3)

• Programmation impersonnelle
• Pas de propriété personnelle (pas de lien affectif entre le
module et la personne)
• Propriété collective (présentation standardisée : mise en
page, commentaires, …)
• Tout programme contient des erreurs
• En découvrant une erreur, on ne blâme pas une
personne particulière, mais on rend un service à l’équipe
• Plus tôt on découvre les erreurs, moins coûteuse est la
correction

59