M2204 – Gestion de projets informatiques Estimation des charges – La méthode des cas d’utilisation

Sommaire Introduction La méthode des cas d’utilisation

Introduction

L’estimation des charges Management de projets SI L’estimation des charges

L’estimation des charges Management de projets SI L’estimation des charges Étapes Activités Charge (en jour/homme) Prédécesseur ou antériorité Début 0 J Analyse A1 A2 Fin analyse 5 J 3 J Conception C1 C2 6 J A1, A2 Installation I1 Fin 2 J C1, C2 Comment estimer ces valeurs ?

Les besoins en estimation Au niveau du projet global (en mois/homme) Au niveau de l’étape Ordre de grandeur : semaine/homme ou jour/homme (petits projets) Ajuster le découpage Sous-traiter Prévoir des délais pour planifier l’ordonnancement des étapes

Techniques d’estimation des charges Jugement d’expert L’estimation par analogie La loi de Parkinson Le prix gagnant L’estimation descendante L’estimation ascendante La modèle paramétrique/la modélisation algorithmique

L’estimation dans le cadre du processus unifié Une macro-estimation est réalisée dès la création, affinée dans la suite du projet

La méthode des cas d’utilisation

= Technique mise au point par Objectory AB en 1993 Méthode des cas d’utilisation = Technique mise au point par Objectory AB en 1993 Il est recommandé d’utiliser plusieurs techniques de macro-estimations conjointement afin d’effectuer une vérification. Source : The Challeng IT Projects 09/2003. British Computer Society 10 10

4 étapes Pondération des acteurs Pondération des cas d’utilisation Pondération des facteurs techniques Pondération des facteurs environnementaux Pré-requis : les Cas d’utilisation nominaux ont été identifiés

Etape 1 : pondération des acteurs Type d’acteur Description Pondération Simple Système logiciel externe ayant une interface bien définie 1 Moyen Système logiciel externe ayant une interface brute basée sur tcp/ip OU Acteur humain doté d’une interface texte 2 Complexe Acteur humain doté d’une IHM graphique 3

Etape 1 : pondération des acteurs Remarques : Faites preuve de discernement. Un cas d’utilisation d’IHM graphique concernant une IHM avec un seul bouton n’est pas complexe Calculez la somme pondérée : Si un acteur est lié à plusieurs cas, on le prend une fois avec la pondération maximale Pour l’ensemble des acteurs, ont fait la somme des pondérations

Exemple de pondération des acteurs : cas librairie en ligne Exemple avec le sujet librairie en ligne : les acteurs internes

Exemple de pondération des acteurs : cas librairie en ligne Description Pondération Gestion des stocks Système logiciel externe ayant comme interface une mise à jour par Update Simple : 1 Webmaster Acteur humain doté d’une IHM graphique que l’on peut estimer assez complexe Complexe : 3 Libraire Acteur humain doté d’une IHM graphique : - Maintenir le catalogue : Une IHM simple qui décrit chaque fiche d’ouvrage - Maintenir les informations éditoriales : Une IHM simple pour saisir des informations contextuelles Moyen : 2 Ici, on applique la règle « Si un acteur est lié à plusieurs cas, on le prend une fois avec la pondération maximale » => 2

Exemple de pondération des acteurs : cas librairie en ligne Acteurs externes :

Exemple de pondération des acteurs : cas librairie en ligne Description Pondération Paiement sécurisé Système logiciel externe ayant comme interface une requête/réponse simple Simple : 1 Service client Acteur humain doté d’une IHM graphique simple : il visualise des commandes et leur état d’avancement Moyen : 2 Visiteur Acteur humain doté d’une IHM graphique. Il est inutile d’analyser tous les UC ne rechercher que le plus complexe : Gérer son panier : affecter des livres après la recherche Client UC « Effectuer une commande » : Il y a plusieurs onglets : panier – authentification – livraison – mode expédition – règlement => IHM graphique complexe. Complexe : 3 Ne pas tenir compte des sur-types

Etape 2 : pondération des cas d’utilisation Type d’UC Description Pondération Simple 3 transactions (1 transaction = 1 lien « use », « include » ou « extend ») maximum, moins de 5 classes participantes 5 Moyen 4 à 7 transactions de 5 à 10 classes participantes 10 Complexe 7 transactions ou plus de 10 classes participantes 15

Etape 2 : pondération des cas d’utilisation Remarques : Faites preuve de discernement. Ignorez les cas d’utilisation vraiment mineurs Calculez la somme pondérée Nombre de transactions = Nombre de liens « use », « extend », « include » liés à l’UC

Exemple de pondération des UC : cas librairie en ligne Maintenir le catalogue 5 Maintenir les informations Maintenir le site

Exemple de pondération des UC : cas librairie en ligne Créer compte 5 Chercher ouvrages Effectuer recherche simple Effectuer recherche détaillée Découvrir ouvrage Gérer panier Effectuer commande 10 * Consulter commande Déposer commentaire Gérer compte client S’authentifier * Dans ce cas, il y a 3 liens « use », 1 « extend » et 1 « include », donc 5 transactions

Description heuristique Etape 3 : Facteurs de complexité technique Type technique Description heuristique Valeur poids T1 Distribué 2 T2 Objectifs de performances de réponse ou de débit 1 T3 Efficacité élevée d’utilisation en ligne pour l’utilisateur T4 Traitement interne complexe (simulation) T5 Le nouveau code doit être réutilisable T6 Très simple à installer 0.5 T7 Très simple à utiliser T8 Portable T9 Très simple à modifier T10 Application multi-thread concurrente T11 Propriétés spécifiques de sécurité T12 Accès direct offert à d’autres système API t13 Nécessite d’un système d’aide pour la formation utilisateur 0 sans intérêt 5 essentiel

Exemple de facteurs de complexité technique : cas librairie en ligne Type technique Description heuristique Valeur poids T1 Distribué 2 T2 Objectifs de performances de réponse ou de débit 3 1 T3 Efficacité élevée d’utilisation en ligne pour l’utilisateur T4 Traitement interne complexe (simulation) T5 Le nouveau code doit être réutilisable T6 Très simple à installer 0.5 T7 Très simple à utiliser T8 Portable T9 Très simple à modifier T10 Application multi-thread concurrente T11 Propriétés spécifiques de sécurité 5 T12 Accès direct offert à d’autres système API 4 t13 Nécessite d’un système d’aide pour la formation utilisateur

Description heuristique Etape 4 : Facteurs environnementaux Type d’environnement Description heuristique Valeur poids E1 Très familier du processus unifié 1.5 E2 Expérience du domaine applicatif 0.5 E3 Expérience des technologies objets 1 E4 Forte expérience de l’analyste/architecte principal E5 Motivation des équipes E6 Exigences stables 2 E7 Membres de l’équipe à temps partiel -1 E8 Langage de programmation complexe

Etape 4 : Facteurs environnementaux Estimation de chacun des paramètres, à multiplier ensuite par le poids indiqué dans le tableau E1 à E4 0 : pas d’expérience sur le sujet 5 : expert E5 0 : pas de motivation dans l’équipe 5 : équipe très motivée E6 0 : exigences très instables 5 : aucun changement prévu E7 0 : aucun membre de l’équipe à temps partiel sur le projet 5 : toute l’équipe est à temps partiel E8 0 : langage de programmation facile à utiliser 5 : langage complexe

Description heuristique Exemple de facteurs environnementaux : cas librairie en ligne Type d’environnement Description heuristique Valeur poids E1 Très familier du processus unifié 1 1.5 E2 Expérience du domaine applicatif 4 0.5 E3 Expérience des technologies objets E4 Forte expérience de l’analyste/architecte principal E5 Motivation des équipes E6 Exigences stables 2 E7 Membres de l’équipe à temps partiel -1 E8 Langage de programmation complexe 3

Points Use Case Calculs : Points Use Case non ajustés (UUCP) UUCP = TotalActeursPondérés + TotalUseCasePondérés 14 + 60 = 74 Facteur technique de complexité (TCF) TCF = 0.6 + (0.01 * TotalFacteursTechniquesPondérés)= 0,6 + (0,01*30,5) = 0,905 Facteurs environnementaux (EF) EF = 1.4 + (-0.03 * TotalFacteursEnvironnementauxPondérés) 1,4 + (-0,03*17,5)= 0,875 Points Use Case (UCP) Points Use Case = UUCP * TCF * EF 74*0,905*0,875 = 58,60

Effort de développement (en heures) Facteur de Complexité (PF) = (Nombre de E1-E6 au-dessous de 3) + (nombre de E7-E8 au-dessus de 3) Coordination Groupe = pour la communication et la synchronisation Effort * = Facteur horaire * UCP * Coordination Groupe PF Facteur Horaire PF < 2 20 heures 3 <= PF <= 4 28 heures PF > 4 Projet risqué Taille groupe informaticiens Coordination groupe 1 2 à 5 1,1 6 à 10 1,2 * L’effort inclut l’ensemble du travail nécessaire : de la modélisation métier au déploiement.

Exemple de calcul d’effort de développement : cas librairie en ligne PF : 1 seule E1 < 3 => PF =1, soit Facteur horaire = 20 heures Coordination : Equipe de 5 informaticiens => Coordination = 1,1 Effort de développement: Effort = 20 * 58,6 * 1,1 = 1289h En homme jour : 184 jours si 7 heures par jour En homme mois : 9,21 mois si 140 heures par mois L’effort de développement est la durée que mettrait une personne seule à faire l’ensemble du projet, ici elle est supérieure à 9 mois.

Estimation de la durée nominale du projet (Effort développement P1) * 2,5 L’effort de développement est exprimée en homme mois La durée nominale est exprimée en mois. Il s’agit de la durée conseillée pour réaliser le projet (avec ressources illimitées). P1 est un facteur variant de 0,38 à 0,32 selon le type de système à développer. Dans la pratique, on retient P1 = 1/3 Exemple : = (PUISSANCE(9,21;1/3)*2,5)= 5,24 mois, soit 105 jours Cette durée ne peut pas être réduite de plus de 25 % d’après la méthode => 3,96 mois au minimum

Estimation de la durée nominale du projet Phase Durée par défaut Effort par défaut Création 10 % 5 % Elaboration 30 % 20 % Construction 50 % 65 % Transition

Estimation de la durée nominale du projet : cas librairie en ligne Phase Durée par défaut sur 105 jours Effort par défaut sur 184 jours Création 10 9 Elaboration 31 37 Construction 52 120 Transition 18

Estimation de l’effort total du projet Activités Effort par défaut Management 10 % Gestion des configurations et des changements Exigences Analyse et conception 15 % Implémentation 25 % Test Déploiement 5 %

Estimation de l’effort total du projet : cas librairie en ligne Activités Effort sur 184 jours Management 18 Gestion des configurations et des changements Exigences Analyse et conception 28 Implémentation 46 Test Déploiement 9 A partir de ce tableau, on peut calculer le coût de chaque activité et ainsi le coût total du projet. Par exemple, si le coût horaire d’un développeur est de 25 €, l’implémentation coûtera 8050 € (main d’œuvre uniquement).

Estimation pour votre projet Projet avec 3 UC : Répartition de l’effort L’effort du projet (charge) a été estimé à 1100 heures, ce qui reste proche des 1200h requis (300h de projet * 4 étudiants). La pondération des cas d’utilisation a été estimée ainsi par le groupe de projet : Cas d’utilisation Pondération Effort par UC : Pondération UC / Pondération totale * Effort Cas 1 5 =5/30*1100 =>183h Cas 2 10 =10/30 *1100 => 357H Cas 3 15 = 15/130*1100=>550H 2 lots sont prévus : • Lot 1 : Cas 1 et 2 • Lot 2 : Cas 3

Estimation pour votre projet 1ère solution : réalisation incrémentale et itérative. Dans ce cas, chaque lot suit le processus suivant : analyse, conception, développement, test, déploiement. Lot 1 (Cas 1 + Cas 2) : 550h Activités Effort par défaut Effort en heures Management 10% 55 Gestion des configurations et des changements Exigences Analyse et conception 15% 82 Implémentation 25% 138 Test Déploiement 5% 27 Idem Lot 2.

Estimation pour votre projet 2ème solution : Analyse et conception de l’ensemble, développement incrémental (PREFERABLE, mais à définir avec l’enseignant tuteur). Activités Effort par défaut Effort en heures Lot 1 Lot 2 Management 10% 110h Gestion des configurations et des changements Exigences Analyse et conception 15% 165h Implémentation 25% 138h Test Déploiement 5% 27h

GANTT pour votre projet En moyenne, chaque étudiant fait 10h de travail par semaine => 40h par semaine de projet pour le groupe entier, soit 160h par mois, ce qui représente un effort de 6,88 homme mois (ou plutôt groupe mois, ici). GANTT Vous réaliserez le GANTT par rapport à l’effort calculé. Dans notre cas, il y a 40h à répartir par semaine entre 4 étudiants (la ressource gérée est principalement de niveau étudiant et plus rarement de niveau binôme ou groupe). Un étudiant pourra faire moins une semaine et plus la semaine suivante, si vous le souhaitez. Rappels : Livraison partielle : 11 décembre (soutenance le 18) Livraison finale : 5 mars (soutenance le 12) Maintenance : 3 dernières semaines de mars.

GANTT pour votre projet Le GANTT pourra être représenté de 2 façons, au choix : 1ère possibilité : - Lot 1 : Cas 1 : Sous-type 1 : étudiant 1, étudiant 2 Sous-type 2 : étudiant 3 Sous-type 3 : étudiant 4 Cas 2 : Sous-type 1 : étudiant 3, étudiant 4 Base de données * Tests * *(si vous souhaitez faire ressortir des points techniques) Lot 2 : etc.

GANTT pour votre projet 2ème possibilité (avec par exemple, ici, le choix d’une réalisation partiellement incrémentale) : Management : Dossier de GP : Tous les étudiants Réunions tuteurs : Tous les étudiants Visites entreprises: Tous les étudiants Suivi GP : étudiant 1 Soutenances : Tous les étudiants - Gestion des configurations et des changements : Formation interne : … Formation externe (utilisateurs) : … Exigences : CdC Analyse et conception : Diagrammes de séquence : étudiant 1, étudiant 2 MCD : étudiant 3 Diagramme de classes : étudiant 4 Création de la base : étudiant 3, étudiant 4

GANTT pour votre projet Lot 1 : Développement : Cas 1 : Sous-type 1 : étudiant 1 … Cas 2 : Tests : Sous-type 1 : étudiant 2 Sous-type 2 : étudiant 1 Sous-type 1 : étudiant 4 Sous-type 2 : étudiant 3 Déploiement : Déploiement lot 1 : tous les étudiants Etc. Vous penserez à décomposer au maximum si possible, notamment les tâches liées au développement et au test. Il est préférable de faire la version 2 car plus précise.