Tâche: Personnaliser le processus de développement pour le projet |
|
 |
Cette tâche explique comment personnaliser un processus de développement afin qu'il réponde aux besoins spécifiques du projet. |
|
Objet
Objectifs de cette tâche :
-
Ajuster le processus de développement logiciel aux besoins spécifiques du projet.
-
Mettre à la disposition des participants au projet suffisamment de conseils pertinents concernant le processus afin
qu'ils puissent fournir un travail efficace et de qualité acceptable.
-
Fournir une description pertinente et accessible du processus aux participants au projet.
|
Relations
Rôles | Principal:
| Complémentaire:
| Auxiliaire:
|
Entrées | Obligatoire:
| Facultatif:
| Externe:
|
Sorties |
|
Etapes
Analyse du projet
Objet :
|
Comprendre le problème posé, et les ressources disponibles pour le projet.
|
Pour assurer le succès du projet, le processus de livraison doit absolument être pertinent pour le projet en
question et adapté à ses exigences en terme de taille et de formalisme. Un processus trop marqué entrave souvent la
créativité et l'efficacité. Un processus pas assez marqué peut entraîner une situation chaotique, poussant
par exemple des membres individuels du projet à prendre des décisions locales pouvant avoir des résultats peu
efficaces, incohérents et imprévisibles.
|
Définition de la portée de l'effort de personnalisation
Objet :
|
Définir les domaines de processus à traiter lors du processus personnalisé selon le projet.
|
Les résultats de l'analyse des ressources du projet et de leur expérience dans des projets de développement
logiciel similaires aident à identifier l'ampleur du travail d'adaptation. Un processus personnalisé selon le
projet ne contient pas obligatoirement toutes les disciplines de RUP, et, à priori, il n'est pas non plus
nécessaire de traiter tous les rôles définis dans RUP. Il faut garder à l'esprit le fait que RUP est un cadre de
processus adapté à une large gamme de types de projets, et qu'il sera donc trop vaste pour un projet spécifique. La
sélection des domaines devant être traités dans le processus du projet dépend fortement des compétences réelles des
différents participants au projet et de la nature du projet en question. Vous trouverez ci-dessous certains des
éléments à prendre en compte lorsque vous définissez la portée du travail d'adaptation.
-
Domaines dans lesquels les membres du projet possèdent déjà une méthode de travail commune, où il n'est pas
nécessaire d'introduire un nouveau processus ou des outils. Par exemple, s'ils savent effectuer des tests, il
serait judicieux de ne pas présenter la discipline test de RUP afin de limiter le nombre de nouveaux éléments.
Vous pouvez vous concentrer sur certaines fonctions de RUP, afin de résoudre les problèmes de leur processus
existant. Pour plus d'informations, voir le Concept : Implémentation d'un processus dans un projet, section Amélioration du
processus et des outils.
-
Domaines (disciplines) dans lesquels le projet doit présenter un nouveau processus et de nouveaux outils, car
il n'existe aucune méthode de travail existante. Dans certains cas il n'y a pas de processus ni d'outils
existants sur lesquels se baser, et il est nécessaire de présenter l'essentiel du programme RUP, ainsi que ses
outils de support. Pour plus d'informations, voir le Concept : Implémentation d'un processus dans un projet, section Tout
changer.
-
Problèmes dans le processus existant. Se concentrer sur l'amélioration de domaines dans lesquels l'entreprise a
eu des problèmes.
-
Quels outils utiliser ? Si le projet requiert l'utilisation de certains outils, le processus de développement
devrait traiter les domaines correspondants de RUP.
-
La capacité de changement du projet. Lorsque l'on traite les problèmes de l'entreprise, on a tendance à essayer
de régler tous les problèmes à la fois, d'autant que beaucoup de ces problèmes ont lieu simultanément. Il
s'agit d'un piège souvent fatal. Comme les personnes, les entreprises peuvent s'adapter au changement mais
seulement dans une certaine mesure. Si la capacité de changement est faible, vous devrez aller plus lentement,
et peut-être vous contenter de présenter une ou deux disciplines de RUP lors du premier projet.
-
Domaines dans lesquels les membres du projet manquent de connaissance, ou sont faibles. Confier le traitement
de ces domaines au processus de développement. S'assurer qu'il est facile de trouver l'information souhaitée
dans RUP.
Pour plus d'informations sur la définition de la portée de l'effort de personnalisation, voir les Instructions : Personnalisation de RUP.
Pour obtenir une description des facteurs ayant une influence sur la personnalisation d'un processus pour un
projet, voir les Instructions : Discriminants de processus.
Les domaines d'amélioration identifiés ne doivent pas obligatoirement être présentés pour la première fois dans le
même projet. Réduire le nombre de facteurs inconnus et s'intéresser aux domaines dans lesquels l'entreprise de
développement a eu le plus de mal dans le passé. Il est conseillé d'implémenter RUP de manière itérative, comme
indiqué dans le Concept : Implémentation d'un processus dans un projet. Pour les petits projets,
des conseils sont également à disposition dans l'Exemple : Adoption de RUP par un petit projet.
Bien qu'il puisse exister des besoins d'amélioration dans plusieurs disciplines, considérer l'option de les
présenter de façon itérative lors de plusieurs projets, plutôt que de choisir une approche visant à tout changer en
même temps. Un exemple de ce type de compromis consiste à présenter les exigences avec les cas d'utilisation et à
retarder la présentation d'un nouveau processus de gestion de la configuration, si les projets préalables ont
rencontré des problèmes d'exigences obscures et/ou insuffisantes ou si si de nombreux utilisateurs se sont déclarés
peu satisfaits par le produit livré.
Les compromis effectués et la portée en résultant doivent être documentées en tant que partie du processus afin de
communiquer aux parties prenantes externes les décisions relatives à la portée.
|
Développement du contenu spécifique au projet
Objet :
|
Créer de nouvelles "compétences de processus" dans les domaines pour lesquels la couverture de
l'infrastructure RUP est jugée insuffisante pour le projet.
|
L'infrastructure de méthode RUP se manifeste dans un modèle de processus défini au moyen d'un métamodèle UML. Cette
infrastructure est fondée sur un métamodèle appelé "Unified Method Architecture" (UMA). Les notions de base de l'UMA
sont décrites dans le Concept : Principales fonctions de l'architecture UMA.
Vous pouvez étendre l'infrastructure RUP en ajoutant des rôles, des tâches et/ou des produits
ou bien encore en ajoutant des conseils spécifiques au projet à l'infrastructure RUP existante.
Dans le cadre de tout processus personnalisé selon le projet, une série de ressources disponibles adaptée doit
fournir une aide spécifique et un matériel de référence visant à faciliter la production des artefacts. Des
exemples de ces ressources sont :
-
Instructions communes pour la production de certains artefacts.
-
Modèles personnalisés pour être utilisés dans plusieurs projets. Ils seront partiellement instanciés avec les
informations du projet.
-
Exemples d'artefacts pertinents par rapport à l'ensemble de livrables et à la technologie choisis pour le projet.
-
Actifs réutilisables, tels que des patterns de conception et des bibliothèques de codes.
Au début du projet, le responsable de projet travaille généralement avec l'responsable de processus pour sélectionner la série de ressources
adaptée, et les rendre disponible aux membres du projet dans le cadre du processus personnalisé selon le projet. Le
besoin en ressources additionnelles est réévalué au début de chaque itération.
|
Configuration du processus
Objet :
|
Ajuster le processus afin qu'il réponde parfaitement aux besoins d'un projet.
|
La configuration d'un processus implique de sélectionner le contenu de méthode (produits, tâches, rôles, etc.) devant
être inclus dans le processus. Pour obtenir des recommandations spécifiques sur les éléments de méthode à inclure
pour chaque discipline, voir les instructions relatives aux "décisions clés dans <nom de la discipline>" fournies
pour chacune des disciplines de RUP. La sélection de l'ensemble de contenu de méthode approprié pour le
projet en question n'est pas une tâche négligeable. Pour être efficace, le processus doit être pertinent et adapté
selon plusieurs caractéristiques, comme l'ampleur du projet (ressources et durée), le formalisme, les plates-formes
technologiques, le domaine, etc.
Pour plus d'informations sur le système de classification permettant de déterminer l'importance de produits
spécifiques et de décider s'ils seront utilisés, voir les Instructions : Classification des produits.
|
Définition du modèle de cycle de vie du projet
Objet :
|
Définir le modèle de cycle de vie du projet.
|
Une étape importante de la personnalisation d'un processus pour un projet consiste à choisir un modèle de cycle de vie
pour le projet, y compris la répartition en phases et itérations. A ce stade, le responsable de processus doit
travailler en étroite collaboration avec le responsable de projet car le modèle de cycle de vie choisi pose les bases
du processus de planification du projet. Selon la nature du projet, il peut s'avérer nécessaire d'ajuster le cycle de
vie RUP pour mieux répondre aux besoins spécifiques. Par exemple, le développement d'un nouveau projet exige
généralement plus d'efforts en phase de création qu'un projet de maintenance. Ainsi, la description du cycle de vie
doit être ajustée selon la nature du projet. Voir Concepts :
Itérations pour une discussion sur les différents types de modèles de cycle de vie.
Une fois le modèle général de cycle de vie sélectionné, il est également important de décider de la façon
d'exécuter les enchaînements d'activités associés à chaque discipline incluse dans l'effort de personnalisation,
ainsi que de déterminer le moment du cycle de vie du projet où il sera judicieux de présenter les différentes
parties de l'enchaînement d'activités des disciplines. Choisir une méthode d'exécution de l'enchaînement
d'activités implique de déterminer les activités à exécuter et l'ordre d'exécution. Choisir le moment où les
différentes parties de l'enchaînement d'activités seront exécutées implique de déterminer quand, dans le cycle de vie,
(par exemple, à quelle phase) présenter les activités sélectionnées. Pour plus d'informations sur la personnalisation
de l'enchaînement d'activités pour chaque discipline RUP, voir les notes d'utilisation des enchaînements d'activités de
référence fournies pour chacune de ces disciplines.
A ce stade, vous pouvez également définir les exigences en termes de rythme et de formalisme des produits à différents
moments du cycle de vie. Par exemple, la phase au cours de laquelle un produit est créé et/ou mise à jour et le niveau
de formalisme requis pour le produit (par exemple, le client doit-il clôturer la session?).
|
Mise à disposition du processus pour les participants au projet
Objet :
|
Rendre le processus personnalisé disponible aux membres du projet.
|
Une fois la personnalisation initiale effectuée, le processus en résultant doit être mis à la disposition de
l'équipe projet sous un format exploitable.
Une solution consiste à rendre le processus accessible via un site Web qui peut résider sur un
serveur Web du réseau de l'organisation ou être installé sur l'ordinateur de chaque participant. Si les
participants au projet sont connectés au réseau pratiquement en permanence, il est recommandé d'effectuer un
déploiement sur un serveur Web afin d'éviter toute surcharge liée aux mises à jour du processus au cours du cycle
de vie du projet.
|
Maintenance du processus
Bien que l'essentiel du travail d'adaptation soit effectué au début du projet, il doit être fréquemment mis à jour, à
mesure que l'équipe du projet rencontre des obstacles et d'autres problèmes liés au processus. Tout au long du
déploiement du processus, des leçons peuvent être tirées, qui permettront ensuite au responsable de processus
d'améliorer le processus à partir de ces retours d'informations. Les évaluations réalisées pendant le projet sont
également des données importantes dans une optique d'amélioration du processus.
Les changements mineurs sont généralement gérés par l'équipe projet, et le processus personnalisé est mis à jour
régulièrement afin de préparer l'environnement de développement de la prochaine itération. Ces améliorations du
processus entraîneront souvent des mises à jour du processus spécifique au projet (par exemple, amélioration des
canevas et instructions liés au produit). Les problèmes plus complexes sont traités par le biais de demandes de
changement.
Un des avantages principaux du développement itératif est de permettre aux équipes d'améliorer progressivement leur
méthode de développement logiciel. Nous recommandons que tout projet comporte des micro-cycles d'ingénierie de
processus comportant les étapes suivantes :
|
|
Propriétés
Plusieurs occurrences |  |
Commandé par les événements |  |
En cours |  |
Facultatif |  |
Planifié |  |
Réitérable |  |
Illustrations
Considérations clés
Quel que soit le niveau de personnalisation , il convient d'enregistrer les résultats (et si possible la
logique) de l'effort de personnalisation. De plus, s'il est prévu de procéder ultérieurement à une nouvelle
personnalisation du processus en cours de personnalisation (par exemple, le processus est personnalisé pour une
organisation dans son ensemble et le processus organisationnel qui en résulte doit être de nouveau personnalisé
pour chaque projet), il est également essentiel d'établir des instructions expliquant comment procéder à la
personnalisation d'un processus de développement déjà personnalisé. Les décisions et recommandations relatives à la
personnalisation peuvent être enregistrées dans un document indépendant ou faire partie intégrante du processus de
développement. Pour plus d'informations sur les niveaux de personnalisation, voir le Concept : Personnalisation de RUP.
Le plan de développement logiciel et l'organisation influent
fortement sur le processus de développement, et inversement. La personnalisation du
processus et le développement du planning de projet doivent s'effectuer de manière coordonnée. Par exemple, si le
projet doit utiliser un ensemble de phases différent de celui défini dans RUP (Rational Unified Process), cela doit
être enregistré dans le processus de développement personnalisé. De plus, une fois la personnalisation du
processus de développement effectuée, il convient de procéder à son instanciation en planning de projet susceptible
d'être promulgué. Pour plus d'informations sur la planification de projet, voir la Tâche :
Planifier les phases et les itérations et la Tâche :
Développer un plan d'itération.
Il est conseillé de ne pas personnaliser immédiatement le processus dans son ensemble. Mettez plutôt l'accent sur
la prochaine discipline devant être appliquée dans le projet. Pour plus d'informations sur la méthode
itérative appliquée à l'implémentation de processus, voir le Concept : Implémentation d'un processus dans un projet.
|
Alternatives
Plus d'informations
Concepts |
|
Instructions |
|
Guides d'utilisation de l'outil |
|
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.
|
|