Un exposé sur la construction, la structuration et l'organisation d'une équipe de développement ainsi que les rôles et responsabilités attendus de ses membres

1. REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE
MINISTERE D’ENSEIGNEMENT SUPERIEUR
ET DE LA RECHERCHE SCIENTIFIQUE
Faculté Des Sciences Et De L’ingénierie
Institue De Génie Informatique
Module Génie Logiciel II
4 éme
Année Informatique
Année Universitaire
2006-2007
Réalisé par :
HASSANI Mustapha
BENYAMMI Bachir
Encadré par :
M. D. R. BENAHACENE

2. Sommaire Équipe de développement
2
Sommaire
 Sommaire 02
 Introduction. 03
 I - Construction de l’équipe 05
 Quelques problèmes relatifs à la constitution d’une équipe 05
 Organisation de l’équipe 06
 II - Rôles et responsabilités 07
 Rôles 07
1. Interne 08
a. L’architecte 08
b. L’abstractionniste 09
c. L’ingénieur d’application 10
2. Suppléant 11
a. Chef du projet 11
b. Analyste 12
c. Intégration 12
d. Assurance qualité 11
e. Responsable d'outils 12
f. Administrateur système 12
3. Périphérique 11
a. Directeur 11
b. Responsable du produit 12
c. Utilisateurs finaux 13
d. Support technique 13
 Structuration de l’équipe 13
 Allocation des ressources 13
Conclusion 14
Bibliographie 15

3. Introduction Équipe de développement
3
Introduction
On appelle Génie Logiciel: "L'ensemble des activités de conception et de mise en
œuvre des produits et des procédures tendant à rationaliser la production du logiciel et
son suivi". [1]
Une définition plus pratique pourrait être la suivante : "Procédures, méthodes, langages,
ateliers, imposés ou préconisés par les normes adaptées à l'environnement d'utilisation
afin de favoriser la production et la maintenance de composants logiciels de qualité". [2]
L'appellation génie logiciel concerne l'ingénierie appliquée au logiciel informatique.
Cette branche de l'informatique s'intéresse plus particulièrement à la manière dont le
code source d'un logiciel est spécifié puis produit. Le génie logiciel touche au cycle de
vie des logiciels. Toutes les phases de la création d'un logiciel informatique y sont
enseignées : l'analyse du besoin, l'élaboration des spécifications, la conceptualisation du
mécanisme interne au logiciel ainsi que des techniques de programmation, le
développement, la phase de test et finalement à la maintenance. Les projets relatifs à
l'ingénierie logicielle sont de l'ordre du "Programming in the large", c’est-à-dire que les
projets sont généralement de grande envergure et dépassent souvent les 10000 lignes de
code. Ces projets nécessitent une équipe de développement bien structurée. La gestion
de projet vient en complément naturel du génie logiciel. [3]
La gestion de projet ou conduite de projet est une démarche visant à structurer,
assurer et optimiser le bon déroulement d'un projet suffisamment complexe pour devoir:

4. Introduction Équipe de développement
4
 être planifiée dans le temps : c'est l'objet de la planification;
 être budgétée (étude préalable des coûts et avantages ou revenus attendus en
contrepartie, des sources de financement, étude des risques opérationnels et
financiers et des impacts divers...) ;
 faire intervenir de nombreuses parties prenantes : c'est l'objet des organisations
qui identifient maîtrise d'œuvre et maîtrise d'ouvrage ;
 responsabiliser le chef de projet, mettre en place un comité de pilotage ;
 suivre des enjeux opérationnels et financiers importants.
L'objectif doit être précisé de façon claire, chiffrée et datée. Le résultat doit être
conforme à des normes de qualité et de performances prédéfinies, pour le moindre coût
et dans le meilleur délai possible. [4]
L’équipe de développement doit regrouper toute personne - de près ou de loin -
qui a un impact sur le succès ou l’échec d’un projet, commençant par l'architecte qui
est le responsable de la structure générale du système, jusqu'aux testeurs du produit.
Un projet doit respecter le rôle de chaque un de ces membres, par exemple un codeur
n'est pas une personne moins important qu'un architecte. Le succès de tout projet
dépend des efforts de chaque membre de l'équipe et peu importe si leur contribution
est plus ou moins humble.
Les personnes sont plus importantes que n'importe quel processus ou matériel, de
bonnes personnes avec un bon processus seront toujours plus performantes que de
bonnes personnes avec un mauvais processus. Les processus qui réussissent ne sont
jamais exécutés par des groupes d’agités irresponsables, En conclure qu'un projet
réussi nécessite à la fois un bon processus et une équipe soudée. [5]
Dans ce rapport en essaye de donner une idée sur la construction des équipes de
développement avec les problèmes liés à la construction de ces équipes, ainsi que la
manière d'organiser l'équipe en affectant des différents rôles aux membres de l'équipe.
Avec la définition des activités et des résultats attendus pour chaque rôle.

5. Construction de l’équipe Équipe de développement
5
Construction de l'équipe
L'un des tâches les plus importantes dans la gestion d'un projet est la construction
de l'équipe, cette tâche est faite par le chef d'équipe.
Un projet orienté objets peut être exécuté par une simple équipe de 1 ou 2
personnes, un projet légèrement plus grand nécessite cinq personnes, un projet de taille
modeste nécessite une équipe de développement d'une vingtaine de personnes, une
équipe développent un projet modérément complexe atteindra un personnel d'à peu près
50 personnes. Les projets qui ont un but géopolitique demandent les efforts de centaines
de personnes, …
En autre terme; La taille de l’équipe est souvent appuyée sur les deux facteurs qui
sont la nature et la taille du problème à résoudre.
Quelques problèmes relatives à la constitution d’une équipe
Embaucher des hommes et des femmes intelligents n’est pas suffisant pour la
réussite d’un projet, quelques problèmes peuvent être rencontrés, le facteur le plus
important est le manque des développeurs comme profession dans le milieu industriel.
En plus de ça; seulement 1 à 2 % des développeurs sont hyper productifs (motivés),
plus encore, en pratique; la majorité des projets ne peuvent pas se payer ce genre de
développeurs hyper productifs. Malgré ça; une petite équipe intelligente ne conduit pas
toujours à résoudre certains problèmes complexes.

6. Construction de l’équipe Équipe de développement
6
Un autre facteur figure dans le monde réel de l'industrie est qu'un programme bien
conçu n’est pas nécessairement un programme répond exactement aux besoins.
Normalement; Un projet orienté objet ayant moins de personnel et des compétences
par rapport à un projet non orienté objet, et lorsque la complexité d'un problème
accroît, la taille de l’équipe accroît aussi. Mais en pratique ; plus le personnel est
nombreux, plus il est vraisemblable que le projet échoue, et assez de personnel sur un
projet complexe ne signifiera pas la terminaison dans les délais prévus, …
Organisation de l'équipe
Dans cette partie, en doit monter l'effet de l'organisation sur une équipe quel
que soit sa nature et son rôle dans la réalisation d'un projet quelconque.
En suppose d'une équipe de développement est constitué de 7 personnes (par exemple
un architecte, deux abstractionnistes et 4 ingénieurs d'application – voir le chapitre).
L'échange de messages dans l'équipe si elle n'est pas organiser (Fig. 01) est égale à 21
interactions pour les 7 personnes. Par contre; si l'équipe est organisée d'une façon
hiérarchique (par exemple) (Fig. 02); seulement 6 interactions pouvant être fondus.
I = n (n - 1) / 2
21 interactions pour 7 personnes
I = n * log n
6 interactions pour 7 personnes
Fig. 01 : Equipe non organisée Fig. 02 : Equipe bien organisée

7. Rôles et responsabilités Équipe de développement
7
Rôles et responsabilités
Les développeurs hyper productifs sont, en moyenne, 4 à 10 fois plus productifs
que les développeurs moyens. On a constaté dans le précédent chapitre que la création
d'une petite équipe de développeurs hyper productifs ce n'est pas un choix désirable.
Alors la solution est de construire une équipe hyper productive en utilisant des
développeurs de talents moyens.
Les personnes différentes ont des compétences différentes. Tout projet logiciel
complexe demande un mélange de toutes ces compétences. La notion de rôle est fondée
pour affecté aux diffèrent membres de l'équipe des tâche selon leurs capacités et leurs
savoir-faire.
Dans un petit projet; les mêmes personnes jouent des rôles déférents, mais dans les
grands projets; chaque rôle peut être réalisé par une personne ou plusieurs personnes
différentes.
Dans une équipe; chaque groupe prend en charge les tâches d'études, de développement,
de documentation et de gestion du projet. Toute équipe qui réussit est constituée de trois
ensembles généraux de rôles :
 Interne : responsable de la production du logiciel ;
 Suppléant : supporte les activités des développeurs qui travaillent sur l’interne du
système ;
 Périphérique : à frontière du projet et son contexte.

8. Rôles et responsabilités Équipe de développement
8
1. L'équipe interne
Dans les projets orientés objets, l'équipe (de base) est responsable de la
production du logiciel, elle est généralement constituée d'individualités qui ont trois
rôles différents:
 L’architecte qui est responsable de la structuration entière du système ;
 L’abstractionniste qui gère le microarchitecture des sous-systèmes ;
 L’ingénieur d’application qui développe des classes et des sous-systèmes.
Approximativement 10% de l'équipe de développement devrait faire partie à plein
temps de l'équipe d'architecture. A peu près 30% de l'équipe sont des abstractionnistes.
Les ingénieurs d'application représentent 50 % de l'équipe entière. Les 10% restant ont
des rôles de support.
a. L'architecte
Un architecte est responsable de l’évolution et de la maintenance de l’architecture
du système, les activités principales de l'architecte sont constituées :
 Définir l’architecture du logiciel;
 Maintenir l’intégrité architecturale du logiciel;
 Évaluer les risques techniques lors de la conception du logiciel;
 Proposer l’ordre et le contenu des itérations successives;
 Aider lors des phases variées de conception, d’implémentation, d’intégration et
d’assurance de la qualité;
 Assister les commerciaux pour la définition des futurs produits.
L'architecte est généralement responsable de la production de certains livrables :
 Document d’architecture;
 Documents de conception de bas niveau;
 Document d’aide de conception et de programmation;
 Des éléments des plans de version;
 Les résultas des réunions et des revues;
 Les audits de conception du système livré.

9. Rôles et responsabilités Équipe de développement
9
L'architecte est le visionnaire du projet, il doit y avoir des compétences tel que:
 L’expérience : l’expertise du domaine et la conception de logiciel sont autant
essentielles l’une que l’autre;
 La direction : l’architecte doit avoir l’intérêt, la confiance, le charisme et
l’autorité nécessaire à la conduite de l’effort technique;
 Proactif et orientée sur les buts : l’architecte ni un chercheur assistant, ni un
technologiste; il doit pouvoir conduire à la construction d’un produit concret et
complet afin d’affronter la création de système conçue pour le monde réel.
b. L’abstractionniste
Un l’abstractionniste est une personne qui est responsable de la conception des
classes et des catégories de classes. En autre terme ; celui qui transforme la vision de
l’architecte en réalité. Leurs principales fonctionnalités sont:
 Identifier les classes, les groupes de classes et les mécanismes relevant du
domaine et de l’implémentation;
 Concevoir, défendre et négocier l’interface et les services des catégories de
classes individuelles et diriger leur implémentation;
 Tester les catégories de classes;
 Conseiller l’architecte sur l’ordre et le contenu des itérations successives;
 Épauler et diriger les ingénieurs d’application qui sont sous le contrôle des
abstractionnistes;
 Remplacer l’architecte pendant son absence.
Les résultats attendus par l’abstractionniste sont:
 Éléments du document d’architecture:
 Documents de conception;
 Interfaces et l’implémentation des catégories de classes et des classes;
 Révision et vérification de certaines classes.

10. Rôles et responsabilités Équipe de développement
01
c. L’ingénieur d’application
L’ingénieur d’application est responsable de l’implémentation des classes et des
mécanismes invités par l’architecte et les abstractionnistes. En résumé, il transforme la
vision de l'abstractionniste en réalité, les fonctionnalités de base de l'ingénieur sont:
 Implémenter, sous la responsabilité d’un abstractionniste, la conception des
classes et des mécanismes dans le contexte d’une catégorie de classes;
 Écrire des petits programmes qui fonctionnent dans le langage des classes et
des mécanismes dans le contexte d’une catégorie de classe;
 Exécuter la conception tactique de classes;
 Exécuter le test des classes;
 Conseiller l’abstractionniste au regard des risques tactiques;
 Participer à la rédaction des revue;
 Remplacer l’abstractionniste pendant son absence.
L'ingénieur d’application est grandement responsable de la production de code,
il apporte souvent leur contribution à l’élaboration des documents de conception et de
la documentation utilisateur. C'est lui qui transforme les abstractions en réalité.
Dans le domaine du système d’information, on peut trouver des spécialités tel que :
 Conception d’interface graphique;
 Programmation des bases de données;
 Programmation réseaux;
 Programmation des transactions;
 Sécurité et administration;
 …
En ingénierie; on peut trouver des spécialités tel que:
 Gestion de périphériques;
 Gestion de processus;
 Algorithmique;
 …

11. Rôles et responsabilités Équipe de développement
00
2. L'équipe suppléante
L'équipe suppléante supporte les activités des développeurs de l'équipe interne et
comprend généralement des personnes qui ont des rôles différents tel que:
 Chef du projet;
 Analyste;
 Responsable d'intégration;
 Responsable de l'assurance qualité;
 Responsable de la documentation;
 Responsable d'outils;
 Administrateur système;
 …
Tous les projets n'ont pas besoin de tous ces rôles et dans les projets plus petits,
beaucoup de ces rôles sont assignés aux mêmes individus.
a. Chef du projet
Le chef du projet est responsable de l'équipe, calendrier et du processus, il
conduit le rythme du projet. Les principales activités d'un chef de projet sont:
 Négocier, établir, coordonner et surveiller les produits livrables du projet;
 Établir et conduire le calendrier du projet;
 Affecter le personnel au projet;
 Assigner le travail à faire à l’équipe;
 Gérer le budget du projet;
 Faire communiquer les directeurs du projet et la communauté utilisateur.
Le chef du projet des généralement responsable de la production d'un membre de
produits livrables, dont les calendriers, la planification des ressources, les budgets, les
comptes rendus de réunion et les rapports de projet.
Le chef de projet doit tout d'abord posséder les quatre mêmes compétences que
l'architecte. Les autres rôles suppléants ne sont pas aussi importants pour le succès d'un
projet que celui de chef de projet.

12. Rôles et responsabilités Équipe de développement
01
b. L'analyste est responsable de l'évolution et l'interprétation des besoins utilisateur.
c. Intégration des sous-systèmes et d'assemblage des versions.
d. Assurance qualité Responsabilité de la mesure de tous les produits issus du
processus de développement, ainsi que la conduite du test, le prototypage, …
e. Responsable d'outils
Adaptation des outils logiciels qui doivent faciliter la production, tel que la
génération de code, outils de tests et de suivi.
f. Administrateur système
Responsable de la gestion des ressources informatiques physiques utilisées par le
projet, tel que le matériel et la maintenance des équipements, …
3. l'équipe périphérique
Cette équipe n'est pas directement associée au développement du logiciel, mais à
un impact effectif sur le succès ou l'échec d'un projet. Ces rôles comprennent:
 Le directeur;
 Le responsable de produit;
 L'utilisateur final;
 Le support technique.
Ces rôles représentent des personnes qui sont à la fin des consommateurs du système.
1. Directeur est quelqu'un qui contrôle les principales sources de revenus.
2. Responsable du produit
Assure la coordination commerciale, les formations sur le produit livré et les
activités de support, …
3. Utilisateurs finaux sont les clients, les acheteurs du produit, les futurs utilisateurs.
4. Support technique
Ce groupe est indépendant de l'équipe interne, ce rôle étant de gérer les activités
après livraison, couvrir tous faiblesse et défaut trouvés dans le produit, …

13. Rôles et responsabilités Équipe de développement
03
Structuration de l'équipe
Après avoir cité quelques rôles associés aux membres de l'équipe de
développement, le schéma suivant montre la structure hiérarchique de l'équipe.
Fig. 03 : La structure de l'équipe de développement.
Allocation des ressources
La durée de développement, le budget associé, la taille de l'équipe, les outils
utilisés, …peuvent être considérés comme des ressources d'un projet informatique.
Le schéma suivant montre la présence des différents rôles de l'équipe interne dans
durant les différents phases du cycle de vie d'un produit.
Fig. 04 : Allocation des ressources.
Architecte Abstractionniste Ingénieur
d’application
Équipe de
développement
Équipe
interne
Suppléant Périphérique
Directeur Responsable
de produit
Utilisateur
final
Support
technique
Chef de
projet
Analyste Intégration Assurance
qualité
Administrateur
système
...Responsable
d’outils
Ingénieur d’application
Abstractionniste
Architecte
Conception MaintenanceEvolusion
Ressources
Analyse
Cycle de vie

14. Conclusion Équipe de développement
14
Conclusion
Les individualités sont importantes mais dans le monde industriel du
développement de logiciel les équipes sont encore plus importantes.
La réussite d'un projet est étroitement liée à une équipe de développement bien
organisé et bien structuré.

15. Bibliographie Équipe de développement
15
Bibliographie
1. Journal officiel français du 19 février 1984.
2. Patrick Jaulent, Génie Logiciel, les méthodes, Armand Colin, Paris, 1992.
3. Wikipédia, l'encyclopédie libre, Article sur le Génie Logiciel.
http://fr.wikipedia.org/wiki/Génie_logiciel
4. Wikipédia, l'encyclopédie libre, Article sur la Gestion du Projet.
http://fr.wikipedia.org/wiki/Gestion_de_projet
5. Grady booch, Des solutions objets, Gérer les projets orienté objets,
Traduction de Jean Michel Redriguez, International Thomson Publishing,
France, Paris 1997, Chapitre 03 : L'équipe de développement.
6. Bruno MERMET, Génie logiciel, Concepts fondamentaux, Université du
Havre