Onglet 1 – La métrique " applicative "
La première et la plus conséquente partie du travail réside dans le recensement et l'estimation (nombre, niveaux de complexité) des éléments qui composent l'application. Pour remplir l'onglet Métrique, il faut en effet avoir une vision minimale de la taille de l'application et de sa complexité. Voici les étapes de cette recherche :
Commencez par chercher le nombre d'éléments distincts qui composent le discours utilisateur. Vous découvrirez des " objets " (des données et des traitements associés). Cette étape permettra une première estimation des Tables et des relations. En observant les documents supports de ces informations vous obtiendrez une appréciation relative de leur importance (simple, moyenne, complexe). Ne négligez pas les relations dont les cardinalités sont de type N, elles génèrent de la complexité et doivent être considérées comme des tables simples.
Toujours à partir du discours utilisateur, déterminez les règles de gestion ou d'organisation, ainsi que les traitements à effectuer (si possible, sous la forme d'une hiérarchie de fonctions). Comptez alors un Écran (Windows ou HTML) par élément ainsi recensé et un Traitement (Business Process) pour chaque élément dont la complexité applicative (fonctionnelle ou technique) est évidente.
Le nombre de Rapports et d'Interfaces est ensuite généralement plus facile à circonvenir, généralement en étudiant le modèle de flux.
Pour les applications décisionnelles ou la maintenance d’applications, ne comptez pas les composants existants mais seulement ceux qui seront à ajouter ou à modifier. Dans ce cas, évaluez seulement la complexité de la modification.
Au-delà de l'oubli d'un élément connu, le risque principal se situe dans l'éventuelle explosion des
exigences en cours de Cadrage ou de Design. Le rôle d'un animateur RAD expérimenté est d'obtenir une première estimation fiable et stable lors de l'immersion dans le domaine fonctionnel ; puis à la fin de chaque phase, d’affiner la planification..Tables et Relations (couche données)
Une entité (table) simple (définie ou modifiée) comprend au maximum une douzaine d'attributs. Ajoutez ici les tables issues des cardinalités de type N.
Une entité (table) de complexité moyenne comprend plus d'une dizaine d'attributs, des clés étrangères et la gestion de l'intégrité référentielle.
Une entité (table) complexe comprend plus d'une dizaine d'attributs, de nombreuses clés étrangères et implique des triggers et des procédures cataloguées.
Ecrans type Windows (couche présentation)
Un écran Windows simple comprend :
de 5 à 6 objets (en plus des contrôles standards),
des procédures simples (la cinématique d'écran standard, les actions de recherche, de lecture, de création, de mise à jour) et les accès aux données sont inclus dans la notion d'écran.
Pour prendre en compte une complexité ergonomique exceptionnelle avec peu d'objets, utilisez le type d'écran " moyen ou complexe ".
Un écran Windows de complexité moyenne comprend moins d'une douzaine d'objets + des contrôles standards + des procédures classiques.
Toute forme de réelle complexité applicative doit être recensée dans la couche " Traitements / Règles de métier ".
Un écran Windows complexe comprend plus de 12 objets, des " customs controls " et des procédures complexes.
Ecrans type NET (D)HTML (couche présentation)
Un écran (D)HTML simple comprend du code HTML sans accès aux données. Le contenu textuel et ergonomique est figé.
Un écran (D)HTML moyen comprend une visualisation dynamique de données ou des objets simples ou un contenu instable.
Un écran (D)HTML complexe comprend du code HTML qui encapsule divers types d'objets et des accès à des données de diverses sources.
Traitements / règles de métier (couche application)
Un processus ou traitement simple comprend la programmation d'une règle de gestion ou des calculs semblant simples (ce qui correspond à moins d’une demi-journée de codage-test et se matérialise en général par moins d’une page de code, soit environ 50 lignes en incluant les commentaires).
Un processus ou traitement moyen comprend la programmation d'une règle de gestion ou des calculs de complexité moyenne (ce qui correspond à moins d’une journée de codage-test et se matérialise en général par 2 ou 3 pages de code).
Un processus ou traitement complexe comprend la programmation d'une règle de gestion ou des calculs paraissant complexes (ce qui correspond à plus d'une journée de codage-test et se matérialise en général par plus de 3 pages de codes). Décomposez en plusieurs éléments si nécessaire.
Rapports conventionnels et divers extrants
Un rapport simple est du style " liste " avec des restrictions simples, un tri et un ou deux champs cumulés.
Un rapport de complexité moyenne comprend plusieurs niveaux de rupture et nécessite des jointures entre les diverses tables impliquées.
Un rapport complexe comprend de multiples ruptures, jointures, restrictions et calculs.
Interfaces (autres applicatifs, annuaires, tiers payeurs, etc.)
Un interface (interne ou externe) de complexité simple est du style rapatriement de table de références (accès simple). Traitez comme des interfaces les tâches de reprise de données et les conversions.
Un interface de complexité moyenne comprend plusieurs champs (accès de complexité moyenne). Traitez ici la gestion d'annuaire et accès tiers (certificateurs, payeurs, etc.) standards ou de complexité moyenne.
Un interface (interne ou externe) complexe comprend de nombreux champs et la nécessité de procéder à des vérifications d'intégrité référentielle. Traitez ici les gestions complexes d'annuaires et les accès difficiles à des tiers (certificateurs, payeurs, etc.).
Aide à la maîtrise d'ouvrage sur petit projet NET (ou partie de projet)
Indiquez le nombre de pages HTML structurellement différentes (99 maxi) à l'élaboration desquelles vous participerez (en ce qui concerne le contenu : texte, graphique, ergonomie). Utilisez cette option pour estimer un petit projet NET de type simple présentation de site WEB. Indiquez les pages STRUCTURELLEMENT différentes et manuellement programmées.
