Ces instructions décrivent comment implémenter un processus et ses outils dans un projet de développement
logiciel en exécutant les activités décrites dans la discipline d'environnement. Elles traitent aussi de la
discipline de gestion de projet, qui porte sur la planification du projet, l'identification des risques ainsi que sur
la gestion, le contrôle et l'évaluation du projet.
Il est primordial de comprendre qu'il existe plusieurs façons d'implémenter le processus et les outils, comme décrit
dans la section "Approches du processus d'implémentation et des
outils". Le choix de l'approche dépend de l'état en cours du projet et de ses organisations environnantes. Il faut
donc procéder à une évaluation du projet et de ses organisations environnantes (voir aussi Produit : Evaluation de l'organisation du développement).
Ces instructions décrivent plusieurs approches possibles pour implémenter un processus dans un projet. De plus,
le Concept : Pratiques de l'environnement décrit quelques pratiques fondamentales
utiles pour l'implémentation de l'environnement d'un projet logiciel. Pour obtenir plus d'informations sur la
personnalisation du processus, voir aussi Personnalisation de
RUP.
Ces instructions générales s'appliquent dans la quasi totalité des projets :
-
Avant le début du projet : avant le début du projet, les personnes remplissant les fonctions de responsables
de processus, de spécialistes outils et de responsables de projet doivent recevoir un entraînement concernant le
Rational Unified Process (RUP). Cela est primordial pour le succès du projet. En effet, si les membres du projet ne
savent pas quoi faire, ils ne pourront pas réussir.
-
Phase de création : lors de cette phase, concentrez-vous sur la façon d'améliorer la gestion des exigences
(discipline de recueil des exigences) et sur la gestion du projet (discipline de gestion de projet).
-
Phase d'élaboration: à la fin de la phase d'élaboration, tous les processus et les outils sont en place. La
partie critique de cette phase concerne souvent l'exécution de la configuration et de la gestion des changements
car, dans la phase de construction, le travail est accompli par des équipes de développement travaillant en
parallèle.
-
Phase de construction : il n'y a pas d'introduction de nouveaux processus ou de nouveaux outils dans cette
phase. Le but ici est de produire le produit, l'environnement de développement doit donc être stable. Lors de la
phase de construction, le but est d'intégrer rapidement de nouvelles personnes au projet.
-
Phase de transition : il n'y pas d'introduction de nouveaux processus ou de nouveaux outils. Lors de la
phase de transition, l'objectif n'est plus l'amélioration de processus liés au projet, mais la rétrospective du
projet qui consiste à rassembler les expériences concernant le projet en cours, à les résumer et à les regrouper
sous une forme que les futurs projets pourront utiliser. Le regroupement de ces expériences sert d'entrée pour
améliorer les processus et les outils qui serviront à développer la prochaine évaluation du produit.
L'organisation du processus varie énormément selon les entreprises de développement. Certaines sont très mûres dans ce
domaine et ont des groupes de processus chargés de veiller sur la définition et l'amélioration du processus dans
l'organisation. D'autres n'utilisent que des personnalisations adaptées au projet.
La méthode choisie pour adapter le processus au projet dépend en grande partie du formalisme du processus
d'organisation, ainsi que de plusieurs autres facteurs. Comme, par exemple :
Pour plus d'informations sur les facteurs affectant l'implémentation du processus, voir Instructions : Discriminants du processus.
Voici les différentes méthodes pour implémenter les processus et les outils dans un projet de développement logiciel
:
-
"Tout changer". Cela signifie que le projet adopte l'intégralité du RUP et un
ensemble complet de nouveaux instruments.
-
"Améliorer les processus et les outils". Cela signifie que le
projet décide d'améliorer certaines parties du processus et certains outils en adoptant une partie du processus RUP
et des outils de support.
La quantité de processus RUP à adopter et le nombre d'outils à implémenter pour un projet spécifique dépendent d'un
certains nombres de facteurs. Ces facteurs sont décrits dans Instructions : Discriminants de processus. Ces facteurs sont généralement
découverts lors d'une évaluation du projet et de son organisation environnante. Ces informations sont enregistrées dans
Produit : Evaluation de l'organisation du développement.
Un projet peut décider d'adopter l'intégralité du RUP et de commencer à utiliser un nouvel ensemble d'outils pour une
des raisons suivantes :
-
Il n'y a pas d'outil ou de processus en place et le projet a donc besoin de tout, à savoir d'un processus complet
et de tous les outils.
-
Toutes les personnes, ou presque, sont de nouveaux employés et n'ont donc pas encore une manière spécifique de
travailler.
-
Le projet va avoir recours à une nouvelle technologie pour son organisation, ce qui signifie que le processus et
les outils existants deviendront obsolètes.
Si vous décidez d'introduire l'intégralité du RUP et des outils dans votre projet, il est primordial de les implémenter
de manière incrémentielle. En implémentant le processus et les outils étape par étape, les risques sont plus faciles à
gérer et les modifications sont moins contraignantes pour les personnes travaillant sur le projet. Le diagramme suivant
illustre les moments auxquels différents produits de l'environnement seront développés durant le cycle de vie d'un
projet.
Evolution des produits Environnement dans un projet où "tout est nouveau".
Commentaires sur le planning :
-
Introduction : la discipline de modélisation métier est ignorée.
-
Création : il s'agit d'introduire les disciplines de recueil des exigences et de gestion de projet. Pour
réduire le nombre de nouveaux facteurs, les exigences de l'interface utilisateur ne sont pas introduites. Le
responsable de projet choisit les parties de la discipline de gestion de projet à utiliser.
-
Itération d'élaboration E-1: l'analyse & la conception, ainsi que l'architecture, sont très importantes
pour la phase d'élaboration. Les tests automatisés et la gestion de la configuration & des changements ne sont
pas aussi importants à ce stade du projet parce que le nombre de membres du projet est relativement peu élevé. Ces
éléments peuvent être ajoutés au produit plus tard.
-
Itération d'élaboration E-2 : les processus et les outils de test sont introduits au test automatisé.
Rational RequisitePro est introduit pour gérer les exigences changeantes.
-
Itération d'élaboration E-3 : dans la phase de construction, le travail sera effectué par des équipes de
développement travaillant en parallèle. Il est donc crucial de placer la discipline de gestion de la configuration
& des changements à la fin de la phase d'élaboration. Le responsable de déploiement choisit la façon d'exécuter
la discipline dans la discipline de déploiement.
-
Construction : aucun nouvel élément n'est introduit. Depuis une perspective d'environnement, le but lors de
la phase de construction est de faire participer tous les nouveaux arrivants rapidement au projet.
-
Transition : aucun nouvel élément n'est introduit. Le processus et les outils sont détaillés si nécessaire.
Les membres du projet d'une organisation où les processus et les outils sont en place ont la possibilité de développer
un système. Ces personnes ont la même façon de travailler et c'est un processus plus ou moins bien
documenté.
L'objectif à long terme est d'adopter l'intégralité du RUP et tous les nouveaux outils. Toutefois, l'objectif à court
terme est d'améliorer un ou plusieurs domaines de la prise en charge du processus et des outils. Cela doit concerner
des domaines ayant un fort potentiel d'amélioration.
Le diagramme ci-dessous montre un exemple de projet ayant décidé d'adopter la discipline de recueil des exigences ainsi
que des outils comme RequisitePro et Rational Rose pour améliorer la gestion des exigences. Le projet a aussi décidé
d'introduire la discipline d'analyse & de conception.
Evolution des produits environnement lors de l'amélioration des exigences, de l'analyse & de la conception.
Le diagramme ci-dessus n'est qu'un exemple. Les parties du processus que vous déciderez d'améliorer changeront en
fonction des projets, des problèmes et des besoins spécifiques à un projet. Vous devez évaluer le projet et ses
organisations environnantes pour déterminer les parties du processus que vous souhaitez améliorer ou les outils que
vous souhaitez ajouter.
Ce qui suit est un exemple d'itération dans la phase de création à laquelle on ajoute la discipline de recueil des
exigences. Chaque entrée du diagramme de Gantt est décrite en détails après le diagramme.
Exemple d'itération dans la phase de création
L'enchaînement d'activités décrit pour la création classique du RUP s'applique avec ces variations et ces extensions.
Gestion de projet
Cette activité fait évoluer un projet, de l'idée de départ à un stade où une décision raisonnée peut être prise
quant à la poursuite ou à l'abandon du projet. Les principaux résultats sont des ébauches de Produit : Etude de rentabilité, Produit : Plan de développement logiciel, et de Produit : Liste de risques.
Cette activité a pour but d'identifier les risques du projet, dont les risques associés à l'implémentation du
nouveau processus et des outils. Ce qui en résulte est Produit : liste de risques.
Cette activité a pour but de planifier les phases. Son résultat principal est la section intitulée planning de
projet dans le Plan de développement logiciel. Cela inclut le planning de la
phase où vous trouverez les jalons principaux et leurs critères de performance, dont le critère pour la discipline
d'environnement.
Remarque : le processus de développement personnalisé a une très grande
influence sur plan de développement logiciel et inversement. Par conséquent, le
développement du planning de projet et la personnalisation du processus doivent être effectués de manière
coordonnée.
Cette activité a pour but de planifier l'itération en détails, en incluant notamment la discipline d'environnement
et les autres disciplines. Ce qui en résulte est un Produit : Plan d'itération, comprenant tous les détails
d'activité et toutes les tâches de la discipline d'environnement, ainsi que les autres disciplines de processus.
L'utilisation des processus et des outils fait partie de l'évaluation de l'itération. Les résultats sont :
Le responsable de projet contrôle le travail quotidien, notamment le processus et les outils.
A la fin de l'itération, les risques sont réévalués, notamment les risques associés aux processus et aux outils.
Certains risques disparaissent pendant l'itération et de nouveaux risques sont identifiés. On obtient alors Produit : liste de risques.
Recueil des exigences
Pas de changements particuliers.
Test
Certains aspects logistiques du Produit : Stratégie de test sont définis et fourniront la base de
la réflexion concernant l'effort de test.
Le concepteur du test et une petite équipe de testeurs vérifient que les éléments clés de l'approche de test
fonctionneront par rapport au Produit : Bien fondé de la conception architecturale et les
sélections de composants sont vérifiés comme étant testables.
Environnement
Cette activité a pour but d'évaluer l'état actuel de l'organisation et de décider les parties du processus et les
outils sur lesquels vous souhaitez que les premières itérations portent. Une fois le projet décidé d'après les
évaluations, l'implémentation des processus et des outils peut commencer.
Remarque : le plan de développement logiciel a une très grande influence
sur le processus de développement et inversement. Par conséquent,
le développement du planning de projet et la personnalisation du processus doivent être effectués de manière
coordonnée.
Les résultats sont :
Cette activité a pour but de préparer les processus et les outils pour la discipline de recueil des exigences,
ainsi que les outils de support, de façon à ce que les gens participant au projet puissent commencer à les
utiliser. (Bien sûr, d'autres disciplines peuvent aussi être préparées.) Voir aussi Tâche : Personnaliser le processus pour le projet.
Assurez-vous que les personnes participant au projet savent comment utiliser le processus de développement, les
instructions de modélisation de cas d'utilisation et les outils. En plus des formations habituelles, nous vous
conseillons d'organiser un atelier d'une journée grâce auquel les membres du projet acquerront une expérience
pratique. Voir aussi Tâche : Lancer
le processus de développement.
Les résultats de cette activité sont les suivants :
-
Le Processus de développement dans laquelle la discipline de
recueil des exigences est décrite de manière détaillée.
-
-
Les
outils des exigences sont mis au point et prêts à être
utilisés par les personnes participant au projet.
L'administrateur système prend en charge le développeur de logiciel pendant l'itération.
Apprentissage
-
Tous les membres du projet doivent participer à un cours présentant le RUP de manière
générale, de façon à avoir une vue d'ensemble du cycle de vie du projet.
-
Les personnes travaillant sur la discipline RUP en train d'être mise au point doivent
participer à un cours qui leur apprenant les détails de la discipline.
Mentor
Le mentor est la clé d'un processus d'implémentation réussi. En général, les mentors suivants sont nécessaires :
-
Un mentor de processus à 50%. Il s'agit de quelqu'un agissant comme un
responsable de processus pour prendre en charge le responsable de projet et les autres personnes participant au
projet en utilisant et configurant le processus.
-
Un mentor<pour la discipline> à 50%. Il s'agit de quelqu'un
facilitant le travail relatif à la discipline en menant des ateliers, en révisant les résultats et en répondant à
certaines questions.
Pour plus d'informations sur les mentors, voir aussi Concept : Mentorat. |