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"
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.
|