urbanisation-si

urbanisation-si

Estimation


Estimation – Méthode des points de cas d’utilisation

urbanisation-si-estimation-UC-2i.jpg
 
Les diagrammes de Cas d’Utilisation sont sans conteste les plus faciles à utiliser.
Les CU ainsi que les autres diagrammes UML semblent représenter une base d’évaluation plus précise et plus fiable que les Points de fonction.
En terme de précision, la méthode des points de CU est comparable avec celle de l’expertise basée sur l’expérience concrète des développeurs.
Paramètre de complexité des Acteurs :
  • Caractériser les acteurs par « poids de complexité » appliqué à leur action (1 = simple, 2 = moyen, 3 = complexe)
Le poids non ajusté ( des facteurs techniques et environnementaux ) des Acteurs ( UAW Unadjusted Actor Weight ) s’obtient en comptant le nombre d’acteurs dans chaque catégorie et en le multipliant par le paramètre de complexité. Additionner les 3 chiffres des 3 catégories.
Paramètre de complexité des CU : caractériser les CU par un paramètre de complexité :
 
urbanisation-si-estimation-points-de-use-case-1.png
 
Le poids non ajusté ( des facteurs techniques et environnementaux ) des CU ( UUCW Unadjusted Use Case Weight ) se calcule en comptant le nombre de CU dans chaque catégorie. Multiplier chaque catégorie de Cas d’Utilisation par son poids, puis additionner les produits obtenus.
Valeur non ajustée des Points de CU :
  • UUCP = UAW + UUCW 
Le compte des Points de CU est ensuite ajusté en fonction de facteurs techniques ( TCF Technical Complexity Factor ) et environnementaux ( EF Environmental ). A chacun de ces paramètres est assigné une valeur variant de 0 à 5 en fonction de son influence (I) dans le projet.
 
urbanisation-si-estimation-points-de-use-case-2.png
 
urbanisation-si-estimation-points-de-use-case-3.png
 
TCF ( Technical Complexity factor ) :
  • TCF = 0,6 + ( 0,01 * (somme(I * PTx))) 
 
 
urbanisation-si-estimation-points-de-use-case-4.png
 
EF ( Environmental Factor ) :
  • EF = 1,4 + ( -0,03 * (somme(I * EPx)))
Valeur ajustée des Points de CU (UCP Use Case Point) :
  • UCP = UUCP * TCF * EF
Si tous les facteurs = 0 =>
  • UCP = UUCP * 0,6 * 1,4 = UUCP * 0,84
Si tous les facteurs = 5 =>
  • UCP = UUCP * (0,6 + (0,01 * 5 * 14)) * (1,4 + (-0,03 * 5 * 3,5))
    UCP = UUCP * 1,3 * 0,875 = UUCP * 1,137
Remarque l’ajustement varie de -16% à ~1%
UCP est multiplié par un nombre correspondant à la productivité classique ou historique des équipes impliqués dans le projet (par exemple : 10 heures par UCP).
Le résultat du calcul est un nombre d’heures de travail requis pour réaliser le projet
Pré - requis :
  • Exhaustivité des diagrammes en termes de couverture fonctionnelle et en termes de précision dans la description des acteurs et des rôles.
  • Niveau de détail qui doit offrir une vision complète tout en évitant le  piège de « l’expansion infinie ».
  • Pas de standard actuellement pour définir formellement le niveau de détail approprié.
La manière de décrire les CU a donc une influence notable sur l’estimation :
  • Généraliser un acteur va amener à le compter 1 seule fois.
  • Relations d’inclusion, extension et généralisation entre les CU. Dans certaines estimations ces types sont comptés dans d’autres, ils sont omis. A évaluer au cas par cas.
Il est facile pour chaque organisation de définir son propre standard de granularité en analysant ses CU et en les classifiant « simple », « moyen » ou « complexe ».
L’intérêt est significatif car les CU permettent de définir le périmètre d’un projet avec beaucoup plus de précision que les Points de fonctions.
De plus les CU expriment utilement les exigences pour le développement.
Avec UML, au-delà des CU, il est possible de considérer d’autres éléments de métrique :
  • Modèle objet du domaine
  • Modèle objet d’analyse
  • Modèle objet de conception
  • Modèle objet d’implémentation
  • Modèle objet de test
Évolution et affinement possibles :
Contenu des diagrammes UML
Diagramme de classe, le nombre de :
  • Classes
  • Attributs
  • Opérations
  • Associations
Diagramme d’état, le nombre de :
  • États
  • Transitions
 
"Il vaut mieux exceller en une chose que d'être médiocre en plusieurs."
Pline le Jeune
 

05/11/2014
0 Poster un commentaire

La réutilisabilité un atout à ne pas oublier pour faire baisser les chiffrages !

urbanisation-si-pieges.jpg

Une MOA doit se faire aider d'experts en architecture technique et en méthodologie de gestion de projet informatique pour analyser les réponses aux appels d'offres. Pour différentes raisons, l'entreprise peut avoir décidé à l'avance quelle prestataire elle allait prendre. Souvent des consultants sont déjà en place ou bien les décideurs connaissent les soumissionnaires. L'exemple type à ne pas suivre, c'est ce projet de refonte d'une application dans le domaine des assurances. Des développeurs et un chef de projet étaient dans la place pour concevoir un socle technique dans le but de concevoir toutes les briques de base d'une sur couche d'abstraction dans le but de la réutilisabilité et de l'évolutivité. Malheureusement leurs livrables ne furent pas expertisés comme il se doit. Les documents furent livrés et c'est tout, personne coté MOA pour contrôler leur travail. Quand il a fallu lancer les appels d'offres,  bien qu'ils n'avaient pas le droit de communiquer avec leurs hiérarchies, ils ne s'en privèrent pas, donnant un très net avantage à leur société. Au niveau de la méthode de chiffrages, on trouvait les fameux abaques permettant d'estimer les charges. Un ensemble de critères comme le nombre de boutons, de règles, d'entités métiers, de composants graphiques, ..., déterminaient le type de complexité d'un écran (simple, moyen, complexe, très complexe, hors norme) avec le nombre de jours correspondant (1, 3, 5, 8). Un expert en gestion de projet informatique avec l'aide de techniciens auraient détecté qu'à aucun moment il n'était fait mention de la réutilisabilité permettant de mutualiser et faire baisser les charges. Sans contre expertise coté MOA, le contrat fut signé. Aussi on se retrouva vite dans l'impasse car la MOE appliqua à juste titre systématiquement ses abaques telles que spécifiés dans le contrat signé et obtint des charges exorbitantes. Un écran qui aurait été qualifié de simple par tout le monde se transforma en complexe du fait notamment de l'absence de la mutualisation et de la prise en compte du socle technique déjà conçu auparavant et qui n'avait jamais été validé par les commanditaires. 

Une bonne pratique de gestion de projet, pour diminuer les risques dans un domaine qu'on ne connaît pas, qu'on ne maîtrise pas ou qu'on ne comprend pas, consiste à s'entourer d'experts dans les domaines concernés (par exemple architecture technique, méthode de gestion de projet informatique, estimations, aide à la dépouille et à l'analyse des réponses aux appels d'offres, …), le surcoût sera bien vite rentabilisé car on aura évité de tomber dans les pièges. 

 

 "Grand est celui qui n'a pas perdu son coeur d'enfant."

 

Voir aussi :  //urbanisation-si.over-blog.com/

//urbanisation-des-si.blogspot.fr/

//urbanisation-si.eklablog.com/

//bonnes-pratiques-si.eklablog.com/

//rhonamaxwel.over-blog.com/


11/10/2014
0 Poster un commentaire