Activité :
|
Objet
|
|
Rôle : Implémenteur | |
Fréquence : Cette activité est généralement réalisée plusieurs fois pendant la création ou la modification d'un élément d'implémentation. | |
Etapes
|
|
Artefacts d'entrée : | Artefacts de sortie : |
Plus d'informations : | |
Guides d'utilisation de l'outil : |
Détails sur l'enchaînement d'activités : |
Objet : | Identifier le chemin d'exécution qui stimulera le comportement d'exécution souhaité |
Si l'observation et l'analyse du comportement d'exécution doit fournir une bonne description du comportement du logiciel, vous devez tenir compte des chemins d'exécution importants à explorer dans l'application et de ceux qui offriront la meilleure opportunité de compréhension du comportement d'exécution du logiciel.
Les scénarios les plus utiles à explorer tendent à refléter tout ou partie de ceux dont se sert généralement l'utilisateur final. Il est donc utile, dans la mesure du possible, d'identifier les scénarios en consultant un expert du domaine (comme par exemple un représentant des utilisateurs finaux du logiciel en cours de développement).
Les cas d'utilisation offrent un ensemble précieux d'artefacts à partir desquels des scénarios très utiles peuvent être identifiés et explorés. En tant que développeur, vous pouvez commencer par les réalisations de cas d'utilisation, car ce sont les éléments qui vous seront les plus familiers. En l'absence de réalisations de cas d'utilisation, identifiez les scénarios de cas d'utilisation disponibles offrant une explication textuelle du chemin que l'utilisateur final utilisera pour naviguer dans les différents flots d'événements de la spécification de cas d'utilisation. Enfin, vous pouvez consulter les flots d'événements des cas d'utilisation pour recueillir des informations utilisées pour l'identification de scénarios potentiels. Le succès de cette dernière opération est optimisé lorsque vous consultez un représentant des acteurs de cas d'utilisation ou un autre expert du domaine.
Les testeurs représentent une autre ressource utile à consulter lorsque vous tentez d'identifier les scénarios utiles pour l'analyse d'exécution. Les testeurs ont généralement une bonne connaissance et une longue expérience du domaine grâce à leurs efforts de tests qui les positionnent pratiquement en experts. Il est fréquent que les stimulations d'observation du comportement d'exécution du logiciel proviennent des résultats de l'effort de test lui-même.
Si cette activité est menée suite au signalement d'une anomalie, la tâche principale consiste à la reproduire au sein d'un environnement contrôlé. Sur la base des informations consignées au moment où l'incident s'est produit, vous devez identifier un certain nombre de cas de test représentant autant de possibilités d'exécution fiable de l'anomalie. Vous devrez peut-être modifier certains tests ou en écrire de nouveaux, mais souvenez-vous que la reproduction de l'anomalie constitue une étape essentielle, et que pour les cas les plus difficiles, il sera plus long de stabiliser l'anomalie que de la corriger.
Objet : | S'assurer que le composant est prêt et porte l'état permettant son exécution |
Pour que l'exécution du composant permette d'obtenir des résultats précis, vous devez veiller à préparer correctement le composant afin qu'aucun résultat anormal ne se produise suite à une erreur d'implémentation, de compilation ou de liaison.
Il est souvent nécessaire d'utiliser desdes composants afin que l'observation de l'exécution puisse s'effectuer en temps voulu ou qu'elle puisse avoir lieu dans des situations dans lesquelles le composant s'appuie sur d'autres composants non encore implémentés.
Vous devrez également préparer le cadre ou les outils requis pour l'exécution du composant. Dans certains cas, cela peut impliquer la création d'un code pour l'exécution du composant ; dans d'autres cas, cela peut justifier d'instrumenter le composant de telle sorte que les outils externes puissent observer et éventuellement contrôler le comportement des composants.
Objet : | Vérifier que la configuration des prérequis de l'environnement cible a été effectuée correctement. |
Il est important de tenir compte de toutes les exigences et contraintes à respecter pour l'environnement cible dans lequel aura lieu l'analyse d'exécution. Dans certains cas, il sera nécessaire de simuler un ou plusieurs environnements de déploiement dans lesquels le composant devra être exécuté. Dans d'autres cas, il suffira d'effectuer l'observation du comportement d'exécution sur la machine des développeurs.
Dans tous les cas, il est important de configurer l'environnement cible pour que l'observation de l'exécution soit satisfaisante : cela évite l'introduction d'"éléments polluants" susceptibles d'invalider l'analyse.
Vous devez également tenir compte de l'utilisation d'outils qui génèrent des contraintes environnementales ou des conditions d'exception qui sont en temps normal difficiles à reproduire. Ces outils sont précieux pour l'isolation d'anomalies survenant dans le comportement d'exécution dans ces conditions.
Objet : | Observer et enregistrer le comportement d'exécution du composant. |
Une fois que vous avez préparé le composant et l'environnement d'observation, vous pouvez commencer à exécuter le composant via le scénario de votre choix. En fonction des techniques et des outils utilisés, cette étape peut en grande partie être effectuée de façon autonome ou peut au contraire demander une attention constante au fur et à mesure de la progression du scénario.
Objet : | Identifier les anomalies du comportement d'exécution des composants |
Pendant les différentes étapes ou à la fin du scénario en cours d'observation, recherchez les anomalies présentes dans le comportement attendu. Notez toutes vos observations ou impressions qui vous semblent liées au comportement anormal.
Objet : | Comprendre la racine des anomalies |
Examinez vos observations et recherchez les motifs sous-jacents des incidents survenus.
Objet : | Suggérer d'autres actions correctives ou d'investigation |
Une fois que vous avez revu toutes vos observations, vous disposez d'une liste d'impressions qui vous sera utile pour vos investigations ultérieures et pour les actions correctives que vous proposerez, le cas échéant. Si vous n'exécutez vous-même aucune action immédiate sur ces éléments, enregistrez vos propositions au format approprié et communiquez-les aux membres de votre équipe autorisés à approuver ou à mettre en oeuvre vos propositions.
Objet : | Vérifier que l'activité a été correctement réalisée et que les artefacts qui en résultent sont acceptables. |
Maintenant que vous avez achevé le travail, il serait utile de vérifier que ce travail a suffisamment de valeur. Vous devez évaluer si votre travail est d'une qualité correcte et qu'il est suffisamment achevé pour les membres de l'équipe qui en feront un usage ultérieur comme entrée pour leur propre travail. A chaque fois que cela est possible, utilisez les listes de contrôle fournies dans RUP pour vérifier que la qualité et l'achèvement sont "suffisamment bons".
Demandez aux personnes qui utiliseront votre travail au cours de leurs activités de participer à la revue intermédiaire. Effectuez cette revue pendant que vous avez encore du temps disponible pour prendre les mesures qui répondent à leurs préoccupations. Vous devez également évaluer votre travail par rapport aux artefacts d'entrée clés pour vous assurer que vous les avez précisément et suffisamment représentés. Il peut être utile que l'auteur de l'artefact d'entrée revoie votre travail sur cette base.
Essayez de vous rappeler que le RUP est un processus itératif et que dans plusieurs cas, les artefacts évoluent à travers le temps. Il est donc généralement inutile (et souvent contre-productif) d'élaborer un artefact qui ne sera utilisé que partiellement ou pas du tout lors des opérations en aval. Cela s'explique par la haute probabilité d'évolution de la situation entourant l'artefact, et sur les hypothèses formulées au moment où l'artefact a été déclaré incorrect avant l'utilisation, ce qui a occasionné une refonte du travail et par conséquent un gaspillage de l'effort.
Evitez également le piège consistant à utiliser trop de cycles pour la présentation au détriment de la valeur du contenu lui-même. Dans les environnements qui accordent une grande importance à la présentation et où elle a valeur d'élément livrable, vous pouvez utiliser une ressource administrative ou junior pour travailler sur un artefact dans le but d'améliorer sa présentation.
RUP (Rational Unified Process)
|