- Recherche des prototypes -

La dernière phase de l'étape de conception globale consiste à rechercher quels sont les prototypes qui seront développés à l'étape suivante.

Le nombre de prototypes peut varier, de un seul pour un petit projet (moins de six mois de développement), à cinq ou six pour de plus gros projets. Il n'est pas recommandé de multiplier les prototypes car le temps consacré à leur gestion ne serait plus compensé par le gain de temps apporté par la simplification du développement de chacun. D'une façon générale, on s'attachera à ce que la durée moyenne de développement d'un prototype ne soit ni inférieure à six mois ni supérieure à un an (ces chiffres sont bien sûr un ordre de grandeur). Ainsi un gros projet pour lequel on a estimé trois ans de développement pourra-t-il être décomposé en six prototypes.

7.1 - Périmètre fonctionnel d'un prototype

On appelle périmètre fonctionnel d'un prototype l'ensemble des fonctions qu'il implémente. La définition du périmètre fonctionnel dépend des objectifs recherchés pour organiser les tests utilisateurs (b-tests) de validation de chaque prototype. Il sera donc nécessaire de faire participer les utilisateurs et le maître d'ouvrage à la définition des prototypes.

L'écueil à éviter est de se laisser influencer par les utilisateurs qui ont souvent tendance à gonfler le premier prototype afin de disposer rapidement d'un maximum de fonctions. En effet, si l'on n'y prend pas garde, le développement par prototypage peut être mal vécu par certains utilisateurs qui s'estiment lésés de devoir attendre les prototypes suivants pour obtenir satisfaction. Si le cas devait se produire il ne faudra pas hésiter à passer un peu de temps pour expliquer clairement l'importance de devoir conserver un équilibre entre les différents prototypes afin que le développement  progresse dans les meilleures conditions.

Il faut aussi souligner le rôle important joué par le premier prototype qui va essuyer les plâtres car il permettra de vérifier deux aspects qui ne concerneront plus les prototypes suivants : la navigation générale dans les menus telle qu'elle a été définie dans le SNI et les choix des outils de développement (système d'exploitation, langage de programmation, base de données, utilitaires divers…). Il ne faudra donc pas vouloir être trop ambitieux dans le nombre de fonctions qu'il implémentera. Cet aspect devra être bien expliqué aux utilisateurs et au maître d'ouvrage qui ne sont généralement pas conscients de ces problèmes.

Un autre critère peut parfois intervenir dans la définition du périmètre fonctionnel des prototypes. Il concerne la disponibilité des utilisateurs qui devront réaliser les tests en fonction du planning estimé pour le développement. Ce critère peut prendre de l'importance si les tests doivent faire intervenir des dirigeants qui ont un emploi du temps très chargé. Cet aspect montre bien l'importance du plan de développement que nous détaillerons au paragraphe suivant.

Méthodes de recherche du périmètre fonctionnel

La recherche des prototypes peut se faire suivant deux méthodes :

• en implémentant chaque cas d'utilisation de façon complète dans un même prototype (structuration verticale),
• en éclatant sur plusieurs prototypes les fonctions de certains cas d'utilisation (structuration transversale).

La première méthode est la plus simple à mettre en œuvre mais possède l'inconvénient de ne pas assurer de continuité entre les prototypes. Elle sera plutôt utilisée quand les cas d'utilisation concernent des profils d'acteurs différents et sont assez bien différenciés. Si, au contraire certains cas d'utilisation sont complexes avec beaucoup de fonctions et si l'ensemble possède une forte cohésion il sera préférable d'utiliser la méthode transversale. Dans ce cas, on commencera par placer dans les premiers prototypes les fonctions de base des cas d'utilisation les plus complexes et les autres fonctions seront réparties dans les prototypes suivants. Les cas d'utilisation les plus simples pourront être développés dans leur intégralité (de façon verticale).

Pour illustrer ces deux méthodes nous allons reprendre le cas "Assurance-Auto". Bien qu'il s'agisse d'un petit projet (cas d'école) qui ne nécessiterait pas plusieurs prototypes, nous allons cependant procéder à son découpage en trois prototypes suivant les deux méthodes.

a) Structuration verticale

Prototype 1
Le premier prototype comportera les cas d'utilisation suivants :

• UC02 : Saisie des paiements (SPrimes)
• UC05 : Consultations du responsable (Consult)

L'objectif principal de ce premier prototype est de valider la base de données indépendamment de la gestion des dossiers accidents. Il permettra également de se rendre compte si la navigation proposée organisée dans le SNI convient aux utilisateurs et notamment au responsable. Les utilisateurs concernés par les tests seront constitués uniquement du responsable et des personnels intérimaires ou de leurs représentants.

Prototype 2
Le deuxième prototype s'intéresse à tout ce qui concerne les dossiers accident :

• UC03 : Saisie des dossiers accidents (SDoss)
• UC04 : Gestion des dossiers (GesDoss)

Les utilisateurs concernés sont les chargés de dossiers, les employés chargés de la saisie des dossiers et le responsable.

Prototype 3
Il contiendra les cas d'utilisation restants :

• UC01 : Chaîne batch d'envoi des avis d'échéances (EnvEch)
• UC06 : Edition des statistiques (Stats)

La chaîne batch ne sera pas soumise aux tests utilisateurs mais ils seront néanmoins sollicités pour la construction de jeux d'essais utilisateurs qui permettront des tests se rapprochant d'une utilisation réelle.

b) Structuration transversale

Cette méthode est un peu plus complexe à mettre en œuvre car il faudra faire attention aux précédences de fonctions. Par exemple, il serait incohérent de programmer le calcul du montant de l'indemnité versée à l'assuré (GesDoss-05) dans le prototype 1 et l'enregistrement de la part de responsabilité de l'assuré (GesDoss-03) dans le deuxième puisque GesDoss‑03 est pré-conditionné par GesDoss‑05.

Prototype 1
Le périmètre fonctionnel du premier prototype pourrait concerner les fonctions de saisie (paiements et dossiers) ainsi que quelques fonctions de consultation.

• UC02 : Saisie des paiements. Ce cas d'utilisation est suffisamment simple pour être implémenté ici dans son intégralité.
• UC03 : Saisie d'un dossier accident
• GesDoss-01 : Recherche d'un dossier accident à partir de son numéro ou du nom de l'assuré
• Consult-01 : Affichage des données d'un contrat
• Consult-02 : Obtenir la liste des impayés
• Consult-03 : Consultation des tarifs à partir du type de contrat
• Consult-04 : Consultation des tarifs à partir de la catégorie de tarif

Prototype 2
Le deuxième prototype s'intéressera à la partie du cas d'utilisation de Gestion des dossiers qui traite uniquement des événements concernant l'assuré et que l'on souhaite tester de façon indépendante compte tenu des problèmes de chronologie et d'organisation soulevés.

• GesDoss-02 : Saisie du montant des dégâts estimés
• GesDoss-03 : Enregistrer la part de responsabilité
• GesDoss-04 : Actualisation du malus
• GesDoss-05 : Calcul du montant de l'indemnité à verser à l'assuré
• GesDoss-06 : Editer le chèque assuré
• GesDoss-08 : Clôturer le dossier

• UC01 : Chaîne batch d'envoi des avis d'échéance
• UC06 : Edition des statistiques
• Consult-05 : Liste des dossiers non clôturés
• Consult-06 : Liste des compagnies d'assurances
• Consult-07 : Véhicules assurés impliqués dans un accident en tant que tiers
• GesDoss-07 : Editer la lettre chèque pour l'expert après réception de sa facture

Les règles de Moscow

• Must have (doit avoir)
• Should have (devrait avoir)
• Could have (pourrait avoir)
• Won't have (n'aura pas)

Traçabilité des fonctions

Afin de suivre au plus près l'évolution du projet au travers de la réalisation de ses divers prototypes, il faut garder la trace écrite de toutes les décisions qui sont prises pour faire évoluer le projet. La plupart des décisions portent sur les fonctions et elles devront donc apparaître dans le tableau des fonctions sous la forme d'une colonne intitulée "décisions et commentaires". Par ailleurs, on gardera toujours la trace de l'origine de la fonction en indiquant dans quel dossier et à quel paragraphe du dossier elle a été définie. A ce niveau de l'étude les deux seuls dossiers connus sont le cahier des charges utilisateur (CCU) et le dossier des spécifications (DSP).

Le Tableau de Développement et de Traçabilité (TDT)

Ce tableau reprend le tableau des fonctions que nous avons vu lors de la définition de l'architecture fonctionnelle. Il y rajoute des informations concernant le niveau d'implantation dans les prototypes (I, S ou O), l'origine de la définition de la fonction et un commentaire indiquant les décisions prises avec leur origine.

Le commentaire sera surtout utilisé lors du développement pour indiquer les modifications que l'on est amené à apporter à la fonction à la suite d'une décision prise par une instance (commission informatique, maître d'ouvrage, utilisateur, maître d'œuvre, chef de projet, programmeur…). Au niveau de la conception globale, il sera éventuellement utilisé pour indiquer si une fonction non prévue à l'origine dans le CCU a été ajoutée lors de l'étape de conception globale. Ce sera particulièrement le cas des fonctions techniques.

Dand le TDT ci-dessous lesfonctions sont classées par cas d'utilisation. P1, P2 et P3 représentent les différents prototypes envisagés (ici trois). Le symbole de pourcentage placé sur les lignes des cas d'utilisation donnent une évaluation de l'avancement des cas d'utilisation avec les prototypes dans le cas d'une structuration transversale. I : Impératif, S : Souhaitable, O :Optionnel.

TDT du projet "Assurances-Auto

Cas d'une structuration verticale

Cas d'une structuration transversale

Pour les cas d'utilisation qui ne sont pas entièrement développés dans un même prototype on fait apparaître leur avancement par un pourcentage calculé à partir du nombre de fonctions prévues de niveau I ou S.