- Documentation -

La documentation de la conception détaillée d'un prototype permet d'une part de compléter le Dossier de Réalisation Prototype (DRP) qui avait été à la phase précédente, d'autre part de rédiger le Plan d'Essais Prototype (PEP).

Le Dossier de réalisation prototype (DRP)

Il rajoute au dossier déjà constitué, les éléments d'information obtenus au cours de la conception détaillée :

• diagramme des classes faisant apparaître les composants du prototype précédent et le paquetage IHM,
• description des méthodes complexes (algorithmes),
• SEF ou SEP,
• dessins des boîtes de dialogue ou des pages Web complexes,
• dessins des états imprimés complexes,
• diagrammes d'enchaînement pour les chaînes batch,
• diagrammes d'interactions et d'états-transitions pour les classes ayant une dynamique complexe
• diagrammes d'implémentation

A toutes ces informations on rajoute une estimation des charges ainsi qu'un planning de réalisation pour les phases de codage, d'intégration et des tests utilisateurs.

Le Plan d'Essais Prototype (PEP)

Objectif

Destiné à l'équipe de développement, le PEP décrit les tests d'intégration à réaliser avant la livraison du prototype aux utilisateurs pour les bêta-tests.

Ces tests sont indispensables afin de pouvoir livrer aux utilisateurs-valideurs un prototype utilisable c'est-à-dire qui ne plante pas dès les premiers clics souris ou à l'ouverture de chaque fenêtre. Si l'on veut que les utilisateurs fassent un travail efficace, il faut éviter de les mettre d'entrée de jeu de mauvaise humeur en leur livrant un logiciel impraticable.

L'objectif des tests d'intégration est de s'assurer que le prototype livré est conforme d'une part au cahier des charges utilisateur, d'autre part au dossier de réalisation. La description des tests à réaliser doit être faite avant la phase de codage pour éviter qu'ils soient influencés par les techniques de programmation employées et surtout par la structure qui sera donnée aux programmes.

Les types de validation

La validation d'un prototype comporte généralement deux étapes :

• la validation informatique
• la validation fonctionnelle

La validation informatique permet de vérifier la conformité des programmes sources aux méthodes du génie logiciel et aux normes de codage décrites dans le Plan Qualité Logiciel (PQL) intégré au plan de développement lors de la conception globale. Elle permet également de vérifier la conformité de l'IHM avec les règles ergonomiques propres au type d'IHM (GUI, Web) ainsi qu'avec la charte graphique en vigueur dans l'entreprise. Ce type de validation sera réalisée directement par l'équipe de développement sous la responsabilité du maître d'œuvre pendant la phase de codage.

La validation fonctionnelle apporte la preuve du bon fonctionnement du logiciel conformément aux spécifications fonctionnelles et techniques. Elle concerne les tests qui simuleront les processus fonctionnels correspondant aux besoins des utilisateurs. Le PEP concernera uniquement ce type de validation.

La validation fonctionnelle doit être réalisée suivant plusieurs axes tels que le comportement de l'IHM, le déroulement des chaînes batch, l'exactitude des résultats obtenus, la consistance des données persistantes, le fonctionnement des communications, les performances et temps de réponse…

Le comportement de l'IHM

Il s'agit ici de vérifier essentiellement le bon enchaînement des menus et des fenêtres, le contenu des boîtes de dialogue, la présentation correcte des résultats et le contrôle des données saisies. Il faudra notamment s'assurer que d'une part tous les messages de débogage ont été enlevés, d'autre part que les messages utilisateurs sont explicites et ne comportent plus aucun terme technique.

Le déroulement des chaînes batch

Des jeux d'essais complets devront être définis pour chaque fichier mis en oeuvre et tous les états imprimés devront être minutieusement vérifiés pour s'assurer de l'exactitude des résultats produits et de leur présentation.

L'exactitude des résultats

Comme pour les chaînes batch, les résultats affichés dans les boîtes de dialogue de présentation ou les pages Web devront être vérifiés, surtout s'il s'agit de données obtenues à la suite de calculs qu'il faudra refaire manuellement sur certains cas précis (contrôle par sondage).

La consistance des données persistantes

Le contenu des fichiers ou de la base de données devra être soigneusement analysé en utilisant d'une part le diagramme des classes persistantes, d'autre part des jeux d'essais à réaliser. Tous les cas de création, mise à jour ou suppression d'objets devront être testés. Les cas extrêmes tels qu'un fichier ou une table vide devront faire l'objet de vérification de même que la bonne fin des transactions (Commit). Les contraintes d'intégrité devront être forcées pour s'assurer de leur prise en compte.

Le fonctionnement des communications

Dans le cadre du développement d'applications client-serveur il y a lieu de vérifier le bon fonctionnement des communications entre les composants situés sur différentes machines : appel des procédures distantes RMI pour les applications Java, stockage, enregistrement et évolution correcte de l'espace des noms. Cette phase peut nécessiter la mise en place d'une plate forme de tests composée de plusieurs machines en réseau.

Les performances

A ce niveau il faudra simplement s'assurer que les performances ne soient pas prohibitives en termes de temps de réponse, d'occupation mémoire, d'encombrement des lignes… Une étude plus fine des performances sera réalisée lors de l'étape de finalisation.

Le respect des droits d'accès aux fonctions

Il faudra vérifier d'une part que si on possède le bon droit d'accès on peut accéder à la fonction et si on ne le possède pas l'accès est refusé ou impossible. Il faudra vérifier tous les chemins possibles permettant d'arriver sur la fonction.

Intérêt du PEP

Afin d'éviter les a priori sur les tests à réaliser, il est préférable que la validation fonctionnelle du prototype ne soit pas réalisée entièrement par les membres de l'équipe de développement. Il faut donc prévoir l'intervention d'un collaborateur externe au projet qui s'appuiera sur le PEP pour effectuer toutes les opérations de validation du prototype. A cet effet, nous voyons l'importance prise par ce document qui devra être parfaitement explicite sur toutes les actions à mener.

Les unités de validation

Une unité de validation (UV) correspond à un groupe de fonctions ayant une certaine cohérence entre elles et qui feront l'objet d'une validation commune. Dans certains cas les unités de validation correspondront aux cas d'utilisation déjà définis.

Pour les chaînes batch les validations se feront de façon indépendante en utilisant éventuellement un générateur de jeux d'essais.

On établira un tableau d'ordonnancement qui indiquera dans quel ordre les UV devront être prises en compte. En effet, très souvent la validation d'un cas n'a de sens que si un autre cas a été précédemment testé. Dans les cas complexes, on pourra s'aider d'un graphe des précédences qui indiquera que telle unité doit être validée avant telle autre et qui permettra de construire le tableau d'ordonnancement.

Pour chaque unité de validation il faudra définir les informations suivantes :

• Objectif général de la validation : résultat final à obtenir
• Tests à appliquer à toutes les fonctions de l'UV
• Droits d'accès concernant toutes les fonctions de l'UV
• Liste des fonctions à valider : code, désignation et ordre de validation

Pour chaque fonction indiquer les types de validation à réaliser :

• IHM,
• calculs et résultats,
• données persistantes,
• communications,
• performances,
• droits d'accès particuliers

Pour chaque type de validation indiquer les opérations à effectuer :

• événements utilisateurs : clic-gauche, clic-droit, double-clic, touche ENTREE, touche ECHAP, touche TAB, touche F1… (pour chaque événement il faudra bien sûr indiquer quels sont les objets visuels qui sont concernés),
• données à saisir (jeu d'essais),
• résultats à obtenir.

Exemple avec le cas Assurance-Auto

Nous allons prendre le cas du deuxième prototype.

Les unités de validation pourraient être les suivantes :

UV1 : Saisie d'un dossier accident (toutes les fonctions de l'UC03)

UV2 : Recherche d'un dossier accident (GesDoss-01)

UV3 : Suivi d'un dossier (GesDoss-02, GesDoss-03, GesDoss-04, GesDoss-05, GesDoss-06, GesDoss-08)

UV4 : Paiement expert (GesDoss-07)

UV5 : Consultations (Consult-06 et Consult-07)

UV6 : Statistiques (Stats-01, Stats-02)

Remarques :

Si les UV 5 et 6 ne sont pas codées dans le prototype 2 (elles sont notées optionnelles dans le Tableau de Développement et Traçabilité (TDT) leur validation devra bien sûr être reprise dans le prototype 3.

L'ordre donné ici convient bien pour effectuer les validation : il est par exemple logique de tester la saisie d'un dossier avant de vérifier sa consultation ou son suivi.

A titre d'exemple nous allons développer l'UV1 (saisie d'un dossier accident).

UV1 : Saisie d'un dossier accident

Objectif : S'assurer que la saisie porte sur toutes les données d'un dossier et que toutes les données saisies sont bien enregistrées dans la base de données (Table Dossier).

Droits d'accès : Les chargés de dossiers et le responsable

Eléments à valider :

SDoss-05 - Saisir dossier

Fenêtre : BD-SaisieDossier

Chemin d'accès : Option "Dossiers" dans le menu général – bouton poussoir "Nouveau Dossier" dans la boîte de dialogue "Dossiers Accidents"

IHM : Présence de tous les champs de saisie, affichage du bon numéro de dossier, fonctionnement du bouton Aide, contrôle de la saisie (vérifier la validité des dates)

Résultats : Enregistrement dans la base de données.

SDoss-01 - Recherche véhicule

Fenêtre : BD-SaisieDossier

Chemin d'accès : liste déroulante dans le cadre "Véhicule impliqué"

IHM : La combobox doit permettre d'identifier rapidement un véhicule à partir de son numéro minéralogique.

Résultats : La marque, le genre, le modèle et l'immatriculation du véhicule doivent être affichés correctement.

SDoss-02 - Lien tiers client

Fenêtre : BD-RechTiers

Chemin d'accès : bouton poussoir "Recherche tiers…" dans le cadre "Accident"

IHM : Affichage du bon numéro de dossier, recherche à partir du numéro d'immatriculation, insertion dans la liste déroulante "Internes", fonctionnement du bouton "Aide"

Résultats : En appuyant sur le bouton "Fin" tous les tiers internes doivent avoir été rajoutés dans la liste déroulante développable "Tiers internes"

SDoss-03 - Lien compagnie

Fenêtre : BD-SaisieTiersExt (cette boîte de dialogue n'a pas été présentée dans cet ouvrage.

Chemin d'accès : idem à SDoss-02 + Appui sur le bouton "Suite saisie" permettant d'ouvrir la boîte de dialogue "BD-SaisieTiersExt"

IHM : idem au fonctionnement de la boîte de dialogue "BD-SaisieTiersExt"

Résultats : En appuyant sur le bouton "Valider" tous les tiers externes doivent avoir été rajoutés dans la liste déroulante "Externes" de la boîte "BD-RechTiers" puis dans la liste déroulante développable de la fenêtre BD-SaisieDossier".