Choix du scénario d'exécution nécessaire
Objet :
|
Identifier le chemin d'exécution qui déclenchera le comportement d'exécution voulu
|
Si l'observation et l'analyse du comportement de l'exécution ont pour but de fournir les informations voulues sur le
comportement du logiciel, vous devrez prêter attention aux chemins d'exécution de l'application importants à explorer
et à ceux qui offriront la meilleure façon de comprendre le comportement d'exécution du logiciel.
En général, les scénarios les plus utiles à explorer reflètent souvent ce que l'utilisateur utilisera habituellement.
Il est donc utile, quand cela est possible, d'identifier les scénarios en questionnant ou en consultant un expert du
domaine, comme un utilisateur représentatif du logiciel en cours de développement.
Les cas d'utilisation offrent un bon ensemble d'artefacts à partir desquels identifier et explorer les scénarios
utiles. En tant que développeur de logiciel, le plus familier d'entre eux sera sûrement les réalisations de cas
d'utilisations. Vous devriez commencer avec ces dernières si elles sont disponibles. S'il n'y a pas de réalisations de
cas d'utilisation, identifiez les scénarios de cas d'utilisation offrant une explication textuelle du chemin que
l'utilisateur prendra pour les différents flux d'événements du cas d'utilisation. Le flux d'événements du cas
d'utilisation peut aussi être consulté pour fournir des informations permettant d'identifier les scénarios candidats
possibles. Le succès de cette dernière approche est augmenté par la consultation d'un représentant des acteurs des cas
d'utilisation ou d'un expert du domaine.
Les testeurs sont aussi une source utile de renseignements lors de la définition des scénarios utiles pour l'analyse
d'exécution. Les testeurs ont souvent une bonne connaissance et de l'expérience dans le domaine qu'ils testent, faisant
d'eux des experts d'un pseudo-domaine. Dans la plupart des cas, le stimulus de l'observation du comportement
d'exécution du logiciel viendra des résultats des tests.
Si cette tâche est exécutée par un incident connu, le but principal sera de la reproduire dans un environnement
contrôlé. A partir des informations consignées lorsque le problème a eu lieu, un certain nombre de jeux d'essai doivent
être identifiés comme des candidats potentiels pour que l'incident ait lieu de manière sûre. Vous aurez peut être à
peaufiner certains des tests ou à en réécrire d'autres, mais rappelez-vous que la reproduction de l'incident est une
étape essentielle et que pour les cas les plus complexes il faudra plus de temps pour stabiliser l'incident que pour le
corriger.
|
Préparation du composant d'implémentation pour l'observation de l'exécution
Objet :
|
S'assurer que le composant soit prêt et dans un état approprié pour activer l'exécution.
|
Pour que l'exécution du composant donne des résultats précis, il faut veiller à ce que la préparation du composant soit
faite de manière satisfaisante afin qu'il n'y ait pas de résultats anormaux, comme des dérivé d'erreurs, dans
l'implémentation, la compilation ou la liaison.
Il faut souvent utiliser des composants découpés pour que l'observation de l'exécution soit faite rapidement
ou qu'elle puisse être réalisée dans le situations où le composant dépend d'autres composants n'ayant pas encore été
implémentés.
Vous devrez aussi préparer l'infrastructure ou les outils de support nécessaires à l'exécution du composant. Dans
certains cas, cela peut impliquer la création d'un pilote ou d'un code de sécurité pour la prise en charge l'exécution
du composant ; dans d'autres cas, cela peut entraîner l'utilisation du composant comme un instrument, de façon à ce que
les outils de support externes puissent observer et contrôler le comportement des composants.
|
Préparation de l'environnement pour l'exécution
Objet :
|
S'assurer que le profil prérequis de l'environnement cible ait été réalisé de manière satisfaisante.
|
Il faut prêter attention aux exigences et aux contraintes devant être prises en compte dans l'environnement cible dans
lequel l'analyse de l'exécution aura lieu. Dans certains cas, il faudra simuler un ou plusieurs des environnements de
déploiement prévus dans lesquels le composant devra finalement être exécuté. En général, il suffira d'exécuter le
comportement d'observation de l'exécution sur la machine du développeur.
Dans tous les cas, il est important de configurer l'environnement cible de l'observation de l'exécution de manière
adéquate afin que l'exercice ne soit pas gâché par l'inclusion de "contaminants" susceptibles de faire échouer
l'analyse.
Une autre chose à prendre en compte est l'utilisation d'outils qui génère des contraintes environnementales ou des
conditions d'exception qui sont autrement difficiles à reproduire. Ces outils sont inutiles pour isoler les échecs ou
les anomalies qui ont lieu pendant le comportement d'exécution sous ces conditions.
|
Exécution des observations sur le comportement du composant et de l'enregistrement
Objet :
|
Observer et enregistrer le comportement de l'exécution du composant.
|
Après avoir préparé le composant et l'environnement dans lequel il sera observé, vous pouvez commencer à exécuter le
comportement dans le scénario choisi. Selon les techniques et les outils utilisés, cette étape peut être réalisée sans
surveillance ou au contraire requérir une attention permanente lors de la progression du scénario.
|
Revue des observations du comportement et isolation des constatations initiales
Objet :
|
Identifier les échecs et les anomalies dans le comportement de l'exécution des composants
|
Pendant chaque étape ou lors de la conclusion du scénario que vous observez, cherchez les échecs ou les anomalies du
comportement prévu. Ecrivez toutes les observations que vous faites qui, d'après vous, peuvent être liées à un
comportement anormal.
|
Analyse des constatations pour comprendre les causes racine
Objet :
|
Comprendre la cause racine des échecs et des anomalies
|
A partir de vos constatations, commencez à rechercher l'erreur sous-jacente ou la cause racine de chaque incident.
|
Identification et communication des actions suivies
Objet :
|
Suggérer des recherches et des interventions supplémentaires
|
Après avoir revu vos constatations, vous obtiendrez une liste contenant vos remarques ou vos pressentiments demandant
plus d'amples recherches, ainsi que des propositions d'interventions. Si vous ne prenez pas cela en charge vous-même,
enregistrer vos suggestions sous un format approprié et communiquez-les aux membres de votre équipe qui pourront les
approuver ou les prendre en charge.
|
Evaluation de vos résultats
Objet :
|
Vérifier que la tâche a été correctement réalisée et que les produits 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 bien 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 de participer aux réunions de revue intermédiaires. 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 produits 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 du produit d'entrée revoie votre
travail sur cette base.
Essayez de vous rappeler que le RUP est un processus itératif de livraison et que, dans la plupart des cas, les
produits évoluent avec le temps. A ce titre, il n'est habituellement pas nécessaire, et c'est même souvent
contre-productif, de former complètement un produit qui ne sera que partiellement ou pas du tout utilisé dans
l'immédiat. Cela vient du fait qu'il y a une grande probabilité pour que la situation qui entoure le produit change et
que les hypothèses émises lors de la création du produit s'avèrent incorrectes, avant même l'utilisation du produit,
occasionnant un nouveau travail et une perte d'efforts.
Evitez également le piège consistant à utiliser trop de cycles pour la présentation au détriment de la valeur du
contenu. Dans les environnements de projet où la présentation a une importance et une valeur économique comme livrable,
vous pouvez envisager d'utiliser une ressource d'administration ou junior pour réaliser les tâches d'amélioration de la
présentation.
|
|