Objet
|
Définir le personnel nécessaire pour le projet : nombre, type (compétences, domaine), expérience et
niveau
|
En fonction des efforts estimés pour le projet, du planning souhaité, de la structure organisationnelle choisie et de
la correspondance des rôles, le responsable de projet détermine le profil du personnel (nombre et compétences requises)
pour le projet. Bien évidemment, l'estimation des efforts n'est pas indépendante de la taille de l'équipe, de son
expérience, de ses compétences et de son niveau : dans la plupart des cas, le responsable de projet a déjà une idée des
capacités de l'équipe avant d'estimer les efforts nécessaires. Dans le Modèle d'estimation COCOMO (voir Tâche : Planifier les phases et les itérations), les capacités et
l'expérience du personnel sont des éléments clés. Par conséquent, le choix d'un effort total acceptable (grâce à
l'ajustement des paramètres d'effort COCOMO) et d'un planning réalisable seront déterminants pour la définition du
profil du personnel.
Parfois, le responsable de projet sait à l'avance de combien de personnes et de quelles compétences il pourra
disposer. Dans ce cas, si le nombre de personnes et les compétences sont fixes, seul le planning est variable (en
supposant que la portée du projet ne change pas).
Le responsable de projet doit également être conscient des perturbations qui peuvent être occasionnées par une
augmentation trop rapide du nombre d'employés, ainsi que des effets catastrophiques que peut produire une réduction
importante des délais associée à une multiplication du personnel.
Lors de la phase de création, il s'agit de définir et de délimiter la portée et de développer une étude de rentabilité
pour le projet. Par conséquent, l'équipe est relativement réduite : un responsable de projet, un architecte logiciel et
éventuellement un ou deux développeurs, surtout si un prototype du concept est nécessaire pour clarifier les exigences
ou mettre en place un support pour le produit.
Lors de l'élaboration, l'équipe se concentre sur l'architecture et sur le prototype d'architecture. Par conséquent, les
tâches de conception au début de l'élaboration sont principalement liées aux aspects architecturaux : les classes et
leurs attributs sont identifiés mais ne sont pas détaillés car ils présentent peu d'importance sur le plan
architectural. Lors de ces itérations, les principaux acteurs sont votre équipe architecturale et une équipe de
prototypage que vous aurez désignée. Cette dernière est généralement composée de programmeurs expérimentés. A ce stade,
vous disposez d'une équipe de conception très restreinte, qui se concentre sur les technologies et les mécanismes
génériques. Le groupe de test se charge de la création de l'environnement de test et du test des premiers cas
d'utilisation.
Il convient de choisir soigneusement les membres de l'équipe d'architecture : ils doivent présenter de bonnes
compétences d'analyse et de conception, mais également faire preuve de capacités de leadership. Pour communiquer
l'architecture choisie à une équipe plus vaste lors de la phase de construction, il peut être judicieux de répartir les
membres de l'équipe d'architecture entre les différentes équipes de construction. Les membres de l'équipe
d'architecture doivent également justifier d'une solide expérience en ingénierie logicielle : la conception et
l'implémentation de logiciels, l'ajustement des performances, la gestion de bases de données, la gestion de réseaux et
la gestion de la configuration sont des compétences essentielles qui doivent être représentées au sein de l'équipe
d'architecture.
La phase de construction a pour vocation de garantir l'intégrité architecturale du système, tout en lui ajoutant de
nouvelles fonctionnalités. Elle nécessite un affinage de l'architecture (c'est pour cette raison que suite à la phase
d'élaboration, on crée une référence plutôt que de "geler" l'architecture) et un suivi des activités des concepteurs de
la part de l'équipe d'architecture.
Généralement, l'équipe d'architecture est répartie entre les différentes équipes de développement, chacun de ses
membres jouant le rôle de responsable technique et coordonnant les problèmes entre les groupes avec les autres
responsables techniques. Les équipes de construction doivent être inter-fonctionnelles et réunir à la fois des
compétences de conception et de développement, car elles sont chargées de la conception et de l'implémentation des
fonctionnalités dont elles ont la responsabilité. Généralement, une équipe de construction est responsable d'un ou
plusieurs sous-systèmes avec des interfaces bien définies : toute modification apportée à l'interface ou tout ajout
d'un nouveau sous-système entraîne des changements architecturaux et doit donc faire l'objet d'une attention
particulière. Au sein du sous-système, l'équipe est relativement libre de concevoir et d'implémenter comme elle
l'entend, mais une bonne communication entre les équipes est nécessaire pour s'assurer qu'un même mécanisme
d'implémentation n'est pas mis en place en parallèle.
Les équipes de construction sont généralement organisées de manière horizontale, selon les couches. Par exemple, une
équipe peut être responsable des interfaces avec la base de données ou de l'infrastructure de communication, alors que
d'autres équipes se concentrent sur les fonctionnalités de l'application. Par conséquent, les équipes chargées de la
couche "supérieure" doivent avoir davantage d'expérience dans le domaine, mais aussi en termes de conception
d'interface utilisateur et d'interface avec les systèmes extérieurs. Les équipes chargées de la couche "inférieure"
sont davantage tournées vers les technologies d'implémentation. La composition des équipes doit tenir compte de ces
compétences requises.
Il convient dans un premier temps de déterminer la quantité de tests formels à exécuter. Vous devez ensuite évaluer le
nombre de tests à effectuer pour remplir vos objectifs de qualité tout en restant dans des limites raisonnables du
point de vue du coût et du planning. Il est rare qu'un projet dispose du budget nécessaire pour effectuer tous les
types de tests prévus. Vous devez donc déterminer le niveau de test envisageable. N'oubliez pas que chaque
spécification de test doit être contrôlée et gérée. Il n'est pas bon pour le moral de l'équipe de prévoir le
développement d'un grand nombre de spécifications de test, puis de ne pas pouvoir les implémenter par manque de temps.
Créez une équipe de test spécifique. Au moins une personne de l'équipe de test doit venir de l'équipe de définition des
exigences. L'équipe de test est responsable des :
-
Tests fonctionnels. Il s'agit de tester les cas d'utilisation en dehors du système, en utilisant le flux
d'événements du cas (voir Produit :
Cas d'utilisation).
-
Tests structurels. Il s'agit de tester l'envoi de messages dans le cas d'utilisation, en utilisant les vues
de séquence des scénarios.
-
Tests système. Il s'agit d'accroître la charge du système pour révéler sa véritable nature.
N'oubliez pas qu'il ne s'agit pas simplement d'exécuter les tests : vous devez également préparer l'environnement de
test et contrôler les spécifications de test.
Il est souhaitable qu'un groupe indépendant teste les cas d'utilisation et l'ensemble du système. Ce groupe devra
également exécuter les tests et rédiger les rapports de test. Il convient d'organiser le test des cas d'utilisation, de
telle sorte qu'une personne soit responsable de chaque cas d'utilisation.
Pour les petits projets, il n'est pas toujours réalisable de faire tester les cas d'utilisation par un groupe
indépendant. Dans ce cas, vous devez au moins vous assurer que le cas d'utilisation n'est pas testé par une personne
qui a participé à sa conception.
Pour les projets de moyenne ou de grande envergure, il est préférable d'avoir recours à des tests de régression
automatisés. Dans ce cas, l'équipe de test aura besoin de l'assistance de quelques programmeurs. Cela est
particulièrement important pour le développement itératif, pour éviter de réexécuter les mêmes suites de tests.
Au stade de la phase de transition, le travail de développement est terminé. Le test de la version bêta est effectué et
une version finale est préparée. Si la phase de construction s'est déroulée dans de bonnes conditions, l'équipe projet
peut alors commencer à se restreindre et notamment le nombre de développeurs et de testeurs peut diminuer. L'équipe
sera désormais constituée en majorité de formateurs et d'experts en logistique d'infrastructure, responsables du
déploiement du produit au sein de la communauté d'utilisateurs.
L'architecte du logiciel, ou l'équipe d'architecture, travaille en "mode suivi", pour aider à résoudre les rapports de
problème, hiérarchiser les propositions de changement et s'assurer que les problèmes ne sont pas résolus dans l'urgence
au détriment de l'architecture. Les tâches de conception deviennent plus rares lors de la phase de transition et se
limitent à la correction des problèmes ou à l'ajout d'améliorations de dernière minute.
|