Eléments essentiels du processusRubriques
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 communique les réponses aux questions fondamentales "quoi et pourquoi" concernant le projet et constitue le critère par rapport auquel toutes les décisions futures devraient être validées. Le contenu de Vision- ainsi que de tous les artefacts d'exigences associés- doit répondre aux questions suivantes, qui peuvent être séparées en artefacts indépendants et plus détaillées si nécessaire :
Le développement d'une Vision claire et d'une série d'exigences compréhensibles est l'essence de la 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 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 les domaines suivants : organisation du projet, planning, budget et ressources. Il peut aussi comporter des plans pour la gestion des exigences, la gestion de la configuration, la résolution des problèmes, l'assurance qualité, l'évaluation et le test, et la recette 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. Peu importe l'aspect des plans - ou les outils utilisés pour les créer. 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ésIl 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 des risques a pour but de consigner les risques perçus comme affectant la réussite 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 être brève, de telle sorte 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. Chaque vue architecturale traite de plusieurs séries spécifiques de préoccupations, spécifiques aux parties prenantes dans le processus de développement : utilisateurs finaux, concepteurs, responsables, ingénieurs de processus, 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 fonctionnement, et concevoir des composants du système est l'"essence" de la discipline d'analyse et de conception , et de Meilleure pratique : Utiliser les architectures de composants. 6. Prototype-Créer 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. Créer et tester les composants du système de façon incrémentielle est l'"essence" des disciples d'implémentation
et de 7. Evaluation-Evaluer régulièrement les résultatsDans 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 analyses de statut 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 suivies et mises à jour selon les besoins. 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 et 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 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écouvrent le premier prototype (et parfois même avant cela), ils demandent des changements. (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. La gestion et le contrôle de la portée du projet, au fur et à mesure que des changements ont lieu dans le cycle de vie du projet, tout en conservant l'objectif de considérer et de répondre à tous les besoins des parties prenantes, dans la mesure du possible - est l'"essence" de la discipline de gestion de la configuration et des changements, et de la Meilleure pratique : Contrôler les changements. 9. Support à 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, des supports de formation peuvent s'avérer nécessaires, ainsi qu'une nomenclature inclue dans tout emballage de produit. 10. Processus-Adopter un processus correspondant à 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 Pour plus d'information sur l'adaptation du RUP à votre projet et à votre organisation, voir : 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 :
Ces " éléments essentiels "fournissent aussi une introduction à chaque discipline du RUP, et à un bon nombre de ses meilleures pratiques. |
RUP (Rational Unified Process)
|