Eléments essentiels du processus
Cette page présente les éléments essentiels de RUP ainsi que certaines instructions permettant de personnaliser le processus afin qu'il réponde aux besoins de votre projet. Voici la clé permettant d'atteindre l'équilibre délicat entre livrer des logiciels de qualité et les livrer rapidement (le paradoxe logiciel !).
Description principale

Introduction

La clé permettant d'atteindre l'équilibre délicat entre livrer des logiciels de qualité et les livrer rapidement (le paradoxe logiciel !) consiste à comprendre les éléments essentiels du processus et à suivre certaines recommandations pour l'adaptation du processus afin de mieux répondre aux besoins spécifiques de votre projet. Cette tâche doit être effectuée tout en adoptant les meilleures pratiques ayant contribué à la réussite des projets de développement logiciel dans l'ensemble de l'industrie.  

Vous trouverez ci-après une description des principes essentiels d'un processus logiciel efficace.

1. Vision :  Développer une vision

Le développement d'une Vision claire est primordiale pour le développement d'un produit répondant aux "véritables besoins" de vos parties prenantes.

Dans le RUP, l'artefact Vision consigne des exigences et des contraintes de conception de très haut niveau afin de permettre au lecteur de comprendre le système à développer. Il sert d'entrée au processus d'approbation du projet et il est, par conséquent, étroitement associé à l'étude de rentabilité. Il répond aux questions fondamentales relatives projet et sert de jauge aux futures décisions à prendre.

Le contenu de la Vision - ainsi que tous les artefacts d'exigences associés - doivent répondre aux questions suivantes, qui peuvent être séparées en artefacts indépendants et plus détaillés :

  • Quels sont les termes clé ? (Glossaire)
  • Quels problèmes essayons-nous de résoudre ? (Définition du problème)
  • Qui sont les parties prenantes ? Qui sont les utilisateurs ? Quels sont leurs besoins ?
  • Quelles sont les fonctionnalités du produit ?
  • Quelles sont les exigences fonctionnelles ? (Cas d'utilisation)
  • Quelles sont les exigences non fonctionnelles ?
  • Quelles sont les contraintes de conception ?

Le développement d'une vision claire et d'un ensemble d'exigences compréhensible est l'essence même de la discipline de recueil des exigences et du principe d'équilibre de l' Evaluation des priorités des parties prenantes. Cette activité consiste à analyser le problème, comprendre les besoins des parties prenantes, définir le système et gérer les exigences au fur et à mesure de leurs changements.   

2. Plan :  Gérer le plan

"La qualité du produit dépend de la qualité du plan du produit" ( FIS96 ).

Concevoir un nouveau projet ; évaluer la portée et le risque ; surveiller et contrôler le projet ; prévoir et évaluer chaque itération et phase - c'est l'"essence" de la discipline de gestion de projet.

Un plan de développement logiciel recueille l'information nécessaire pour gérer le projet. Il est utilisé pour prévoir le planning du projet et ses besoins en ressources, et pour suivre la progression par rapport au planning. Il traite, entre autres, des domaines suivants :  organisation du projet, calendrier, budget et ressources. Il peut aussi comporter des plans pour la gestion des exigences et de la configuration, la résolution de problèmes, l'assurance qualité, l'évaluation, le test et l'acceptation du produit.

Dans un projet simple, un bon nombre de ces sujets peuvent être traités en une ou deux phrases. Par exemple, la gestion de la configuration peut être décrite ainsi : "A la fin de chaque journée, le contenu de la structure de répertoire du projet sera zippé, copié sur un disque zippé daté et étiqueté, annoté d'un numéro de version et placé dans l'armoire d'archivage".

Le format des artefacts de planification n'est pas aussi important que les activités de planification et l'attention qui leur est portée.  Leur apparence ou les outils utilisés pour leur construction importent peu. Comme l'a dit Dwight D. Eisenhower, "Le plan n'est rien ; le planning est tout."

3. Risques : Limiter les risques et contrôler les problèmes associés

Il est essentiel d'identifier, de s'attaquer aux éléments à plus haut risque tôt dans le projet et de les suivre, en même temps que les autres problèmes associés.  La Liste de risques a pour but d'enregistrer les risques potentiels pouvant nuire au succès du projet. Elle identifie, dans un ordre de priorité décroissant, les événements qui peuvent entraîner des conséquences négatives importantes.

A chaque risque doit être associé un plan pour le limiter. Ceci servira de point central pour planifier les activités de projet, et de base à partir de laquelle les itérations sont organisées.

4. Etude de rentabilité : Examiner l'étude de rentabilité

L'étude de rentabilité fournit les informations nécessaires, du point de vue commercial, pour déterminer si un projet justifie un investissement.

L'objectif principal de l'étude de rentabilité est le développement d'un plan économique pour la réalisation de la Vision du projet. Une fois développée, cette étude est utilisée pour une évaluation précise du retour sur investissement prévu du projet. Elle justifie le projet et établit ses contraintes économiques. Elle fournit des informations aux décideurs sur la valeur du projet, et elle est utilisée pour déterminer si le projet doit continuer.

Cette description ne doit pas entrer dans les détails du problème, mais expliquer de manière convaincante pourquoi ce produit est nécessaire. Elle doit cependant être brève afin que tous les membres de l'équipe puissent la comprendre et la mémoriser facilement. A des jalons critiques, l'étude de rentabilité est réexaminée afin de déterminer si les estimations de coût et de retour sur investissement envisagées sont toujours exactes et si le projet doit être continué.

5. Architecture : Concevoir une architecture de composants

Dans le Rational Unified Process (RUP), l'architecture d'un système logiciel (à un stade donné) est l'organisation ou la structure des composants significatifs du système interagissant par le biais d'interfaces avec des composants constitués successivement de plus petits composants et interfaces. Quelles sont les pièces principales ? Comment s'adaptent-ils les uns aux autres ?  Possédons-nous un cadre d'application auquel ajouter le reste des logiciels ?

Pour discuter et raisonner au sujet de l'architecture logicielle, vous devez d'abord définir une représentation architecturale, une manière de décrire les aspects importants d'une architecture. Cette description est consignée dans le document d'architecture logicielle, qui présente l'architecture selon plusieurs vues.

Chacune d'entre elles traite d'un ensemble précis de problèmes, spécifiques aux parties prenantes du processus de développement : utilisateurs, concepteurs, responsables, ingénieurs systèmes, personnes chargées de la maintenance, etc. Elle sert de moyen de communication entre l'architecte logiciel et les autres membres de l'équipe du projet au sujet des décisions architecturales significatives qui ont été prises concernant le projet.

Définir une architecture candidate, préciser l'architecture, analyser le comportement et concevoir des composants du système est l'essence même de la discipline d'analyse et de conception et du principe Augmenter le niveau d'abstraction.

6. Prototype : Construire et tester le produit de manière incrémentielle

Le RUP est une approche itérative de la création, du test et de l'évaluation de versions du produit afin de déterminer et résoudre les risques et les problèmes le plus tôt possible.

Construire de manière incrémentielle et tester les composants du système est la fonction première des disciplines d'Implémentation  et de Test et le principe même de  Démontrer la valeur de manière itérative.

7. Evaluation : Evaluer régulièrement les résultats

Dans tout projet, il est important de maintenir une communication ouverte continue entre les données objectives extraites directement des activités en cours et les configurations évolutives du produit.  Des évaluations d'état régulières procurent un mécanisme pour traiter, communiquer et résoudre les problèmes de gestion ou techniques et les risques du projet.  Les problèmes ne doivent pas seulement être identifiés, il est aussi nécessaire de leur attribuer une échéance ainsi qu'une personne responsable de leur résolution.  Ces informations doivent être contrôlées et mises à jour si nécessaire.

Ces instantanés du projet constituent le pouls pour l'attention des responsables. La période peut varier mais la fonction de forçage doit consigner l'historique du projet et tenter de supprimer tous goulots d'étranglement ou blocages entravant la progression.

L'évaluation des itérations consigne les résultats d'une itération, à quel point les critères d'évaluation ont été atteints, les enseignements et les changements de processus à implémenter.

L'évaluation d'itération est un artefact essentiel de l'approche itérative. Selon la portée, le risque du projet et la nature de l'itération, il peut aller du simple enregistrement de la présentation et des résultats à un enregistrement formel d'audit de test.

La clé consiste à se concentrer sur les problèmes de processus ainsi que sur les problèmes du produit : "Plus tôt vous prendrez du retard, plus vous aurez de temps pour le rattraper".

8. Demandes de changements : Gérer et contrôler les changements

Dès que les utilisateurs découvriront le premier prototype, et parfois même avant cela, des demandes de changements seront faites. (C'est l'une des certitudes de la vie !) Afin de contrôler ces changements et de gérer de façon efficace la portée du projet et les attentes des parties prenantes, il est important de soumettre tous les changements aux artefacts de développement aux demandes de changements et de les gérer à l'aide d'un processus cohérent.

Les demandes de changements sont utilisées pour documenter et suivre les anomalies, les demandes d'amélioration et tout autre type de demandes de changements effectuées sur le produit. L'avantage des demandes de changements est qu'elles fournissent un enregistrement des décisions, et du fait de leur processus d'évaluation, garantissent que les impacts du changement potentiel seront compris par tous les membres de l'équipe du projet. Les demandes de changements sont essentielles pour la gestion de la portée du projet, ainsi que pour l'évaluation de l'impact des changements proposés.

Gérer et contrôler la portée du projet, à mesure que des changements ont lieu dans le cycle de vie du projet, tout en conservant l'objectif qui consiste à connaître et à répondre aux besoins des parties prenantes, dans la mesure du possible, est l'essence même de la discipline de gestion de la configuration et des changements et du Matériel de prise en charge : Contrôler les changements.

9. Support de l'utilisateur : Déployer un produit utilisable

L'objectif d'un processus est de produire un produit utilisable.  Tous les aspects du processus doivent être adaptés en gardant à l'esprit cet objectif.  Généralement, le produit représente plus que le logiciel.  Au minimum, il doit y avoir un guide d'utilisation, éventuellement implémenté par le biais de l'aide en ligne.  Vous pouvez aussi inclure un guide d'installation et des notes de version.  Selon la complexité du produit, du matériel d'apprentissage peut aussi être nécessaire, ainsi qu'une nomenclature incluse dans tout emballage de produit. Les activités associées forment la discipline Déploiement

10. Processus : Adopter un processus adapté à votre projet

Il est essentiel de choisir un processus correspondant au type de produit que vous développez. Même après avoir choisi un processus, vous ne devez pas le suivre aveuglément - utilisez votre logique et votre expérience pour configurer le processus et les outils répondant aux besoins de l'organisation et du projet.

Adapter un processus pour un projet est un élément clé de la discipline Environnement.

Pour plus d'informations sur la façon d'adapter le RUP en fonction de votre projet et de votre organisation, voir aussi : Concept : personnalisation du RUP.

Conclusion

Les éléments essentiels mentionnés ci-dessus procurent un moyen d'évaluer rapidement un processus et d'identifier des domaines où les améliorations seraient les plus utiles.  Il est important d'examiner ce qui arrivera si l'un de ces éléments essentiels est ignoré.  Par exemple :

  • Pas de Vision ? Vous risquez de perdre votre cap de vue et de vous laisser entraîner dans des détours.
  • Pas de processus ? Sans processus commun, l'équipe peut faire face à des problèmes de communication et ne pas comprendre exactement qui doit faire quoi -et quand.
  • Pas de plan ? Vous ne pourrez pas suivre la progression.
  • Pas de liste des risques ? Vous vous concentrez peut-être sur les mauvais problèmes maintenant et risquez de sauter sur une mine dans 5 mois.
  • Pas d'étude de rentabilité ? Vous risquez de perdre du temps et de l'argent sur le projet. Il risque d'être annulé ou d'aller à la faillite.
  • Pas d'architecture ? Vous ne pourrez peut-être pas prendre en charge les problèmes éventuels de communication, de synchronisation et d'accès aux données ; vous aurez peut-être des problèmes de mise à l'échelle ou de performance.
  • Pas de produit (prototype) ? Dès que possible, mettez un produit face au client. Il ne vous suffit pas d'accumuler les papiers pour garantir à vous-même comme au client que le produit réussira - et cela accroît le risque de dépassements de budget et de délais et/ou d'échec pur et simple.
  • Pas d'évaluation ? Ne pratiquez pas la politique de l'autruche. Il est important de faire face à la réalité. Comment vous situez-vous exactement par rapport à vos délais ? A vos objectifs de qualité ou de budget ? Tous les problèmes sont-ils suivis de façon acceptable ?
  • Pas de demandes de changements ? Comment suivez-vous les demandes de vos parties prenantes ? Comment les hiérarchisez-vous ? Et comment vous assurez-vous que les changements non prioritaires ne passent pas à la trappe ?
  • Pas de surpport à l'utilisateur ? Que se passe-t-il si un utilisateur a une question ou ne comprend pas comment utiliser le produit ?  Est-il facile d'obtenir de l'aide ?

Ces éléments essentiels fournissent aussi une introduction à chaque regroupement de disciplines : Disciplines du RUP et prennent en charge ses Principes clés.