Concept: Implémentation d'un processus dans un projet
Cette page de concept décrit comment implémenter un processus et ses outils de support dans un projet de développement logiciel.
Relations
Description principale

Introduction

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.

Instructions générales concernant le planning

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.

Approches pour les processus et les outils d'implémentation

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 :

  • La maturité du processus de l'entreprise de développement.
  • L'ampleur du projet en termes de durée et du nombre de ressources de développement.
  • L'expérience préalable des membres du projet avec des processus similaires.
  • Le formalisme requis par le projet.

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.

"Tout changer" (retour aux approches...)

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. 

 Diagramme décrit dans le texte d'accompagnement.

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.

"Améliorer les processus et les outils" (retour aux approches...)

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. 

Diagramme décrit dans le texte d'accompagnement.

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.

Exemple d'itération de création

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. 

Gestion de projet Planifier l'itération suivante Evaluer la portée et les risques du projet Planification du projet Gérer l'itération Surveillance et contrôle du projet Concevoir un nouveau projet Evaluer la portée et les risques du projet Recueil des exigences Test Environnement Support de l'environnement au cours d'une itération Préparer l'environnement pour un projet Préparer l'environnement d'une itération Mentor de processus à 50% Mentorat RMUC RUPF Formation Mentor d'exigences à 50% Cliquez sur une rubrique pour obtenir une description détaillée

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 :

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.