Upload
kha-heru
View
33
Download
0
Embed Size (px)
DESCRIPTION
USING FUNCTION POINTS FOR PROJECT COST ESTIMATION
Citation preview
CNAM Ile de France
COURS D’INTRODUCTION A LA METHODE DES POINTS
DE FONCTIONDE FONCTION
Session 2011/2012
1
PROGRAMME • Introduction générale aux Points de Fonction
Objectifs de la méthode Historique Spécifications et mesure fonctionnelle Vue utilisateur
• Mesure des différents types de composants : « Fonctions » : Entrées, Sorties, Interrogations ; « Données » : GDI et GDE ; Mesure des applications transactionnelles (IHM) et des traitements Batch Mesure des applications transactionnelles (IHM) et des traitements Batch
• Les types de cotation pratiquées : Mesure de performance (Bilan), Estimation de la charge des projets Mesure de patrimoines applicatifs Utilisation des PF pour la gouvernance du SI
• Méthodes de mesure pratiquées : IFPUG 4.3 (« méthode complète ») Méthodes simplifiées, Extensions Méthodes rapides Cas particuliers (progiciels…)
• Mise en œuvre de la méthode sur un cas réel 2
DEFINITION DU POINT DE FONCTION
• Le point de fonction est l’unité de mesurede la taille fonctionnelle d’un « produit » logiciel
• Mesure objective, du point de vue de l’utilisateur « vision métier »
• Grand standard international (IFPUG) et norme ISO
3
Intérêt des points de fonction• Comment mesurer les activités de Développement informatique ?
Gestionnaires (Managers ou Commerciaux)
Utilisateurs (métier) ou client
Informaticiensou client
X lignes de C++Y lignes de JavaZ scripts
4
Intérêt des points de fonction• Comment mesurer la Production d’une Direction
Informatique ou d’un prestataire de services ?– Production Informatique = nombre de JH budgétés délivrés (vue
gestion)– Production de logiciel : X lignes de C++, Y lignes de Java et Z
scripts (vue développeur) – Client ou Utilisateur : coût de n M€, gains calculés pour justifier le
lancement du projet (fiabilité?)• La méthode des Points de Fonction permet de rendre
compte de la Production d’une équipe informatique par une mesure objective
• Les PF permettent de rétablir le dialogue entre informaticiens et utilisateurs, entre MOE et MOA.
5
Objectiver le dialogue MOA/MOE ou Client / Fournisseur
• Comment estimer la charge d’un projet à partir d’éléments objectifs ?– Coût, qualité, fonctionnalités et délais +/- inconnus– Spécifications générales du projet => modélisation des données
et recensement des fonctions. Calcul des PF réalisé dès les phases amonts, aide à la définition de l’enveloppe du projet.
– En cas de dérive : évolution de la taille du projet ou difficulté – En cas de dérive : évolution de la taille du projet ou difficulté technique imprévue ?
• Changement de taille permet de répercuter la dérive sur le MOA (mesure précise des impacts des demandes complémentaires en cours de projet)
• La MOE est donc responsable des seuls problèmes techniques – Ratios majeurs : Coût/PF, Qualité/PF, Délais/PF permettent de
rapporter la production de l’informatique aux fonctionnalités délivrés aux utilisateurs.
6
PF et objectifs externes aux études• Vis-à-vis du management de l’entreprise
– Assurer la transparence de l'activité « développement »
• Vis-à-vis des « clients » maîtres d’ouvrage– Expliciter le lien entre les coûts de développement
et les services rendus par l’application• Vis-à-vis des sous-traitants
– Utiliser le PF comme unité d’œuvre, et de facturation– Evaluer les sous-traitants
Nombre de PF développés, modifiés ou maintenus, par jour• Vis-à-vis de l’exploitation
– Rapporter les mesures de qualité des applications en exploitation à un indicateur de dimension fonctionnelle
7
PF et objectifs internes aux études : SAVOIR
• Connaître la taille du portefeuille applicatif et son évolution
• Se « Bench marquer»– D’un projet à l’autre– D’un processus à l’autre
• Mesurer l’impact des exigences non fonctionnellessur la productivité des processus de développement
8
Les PF et les objectifs DSI internes aux études : AGIR
• Améliorer le processus de budgétisation de la maintenance
• Développer une politique d'amélioration de la productivité– Mesurer, analyser et comparer la productivité (PF/JH)
des différents processus de développement mis en œuvredes différents processus de développement mis en œuvre– En tirer des préconisations relativement à la politique
d’acquisition d’outils de développement et de progiciels du marché
– En tirer des préconisations relativement aux politiques de recrutement et de formation
9
Les PF et les objectifs PROJETS• Mesure la richesse fonctionnelle du système d’information projeté
en termes de quantité de services rendus aux utilisateurs finaux• Fiabiliser et faciliter l’estimation des charges
– De développement ou d’évolution– De maîtrise d’œuvre, de maîtrise d’ouvrage, de sous-traitance
Le PF est l’unité d’œuvre par excellenceLe PF est l’unité d’œuvre par excellence• Gérer le projet en transparence avec les utilisateurs
– Manager le périmètre du projet, estimer la stabilité du périmètreLe PF est l’unité de mesure du périmètre
– Optimiser le budget : Rationaliser les arbitrages entre fonctionnalités de « valeur » différentesLe PF est l’unité de troc entre fonctionnalités
• Connaître la productivité du développement pour les projets terminés
10
Les méthodes point de fonction• La méthode la plus répandue dans le domaine des SI de gestion est
celle de l ’« IFPUG » (International Fonction Point User Group)– Basée sur une méthode initiale de A.Albrecht (1979)– IFPUG créé en 1986 (US)– Normalisée ISO20926 en 2003– Version actuelle = IFPUG 4.3– Basée sur une modélisation en objets « métiers » : données et processus – Basée sur une modélisation en objets « métiers » : données et processus
élémentaires• Des méthodes alternatives
o Méthode COSMIC-FFP– Utilisée notamment pour les SI industriels (temps réel)– UK, Canada …– Basée sur une modélisation des flux élémentaires de données
o Nesma FP, Story points (Agile), Use Case Points, Backfiring fromLOC, AFP …
11
Equivalence lignes de code/PF
Langage SLOC/UFP Langage SLOC/UFP
• Ratios d ’équivalence– Des ratios statistiques ont été publiés pour estimer le nombre de lignes de code
équivalent à la programmation d ’un PF, en moyenne, dans un langage donné. – L ’inverse (cad convertir des lignes de code en PF) est faux en général.
• En effet, le code contient en général des modules non fonctionnels qui ne se traduisent pas en PF.
Table SLOC-PF :
Access 38 Java 53 Ada 95 49 Lisp 64 Assembleur 320 Pascal 91 Basic ANSI 64 PERL 27 C 128 PowerBuilder 16 C++ 55 Query 13 COBOL 85 91 Simulation 46 Fortran 95 71 Tableur 6 HTML 3.0 15 Scrip Unix 107 L3G 80 Visual Basic 5.0 29 L4G 20 Visual C++ 34 L5G 4
12
MESURE DE LA TAILLE FONCTIONNELLE REGLES DE COMPTAGE IFPUG 4.3REGLES DE COMPTAGE IFPUG 4.3
13
Spécification fonctionnelle et PF (1)• Nécessité d ’une spécification fonctionnelle
– La spécification fonctionnelle est le document d ’entrée pour la mesure des PF.
– En terme de mesure, l ’aspect le plus important est la complétude de cette spécification.
• Le formalisme spécifique : description littérale ou « use case UML », schémas relationnels ou description objet est sans impact sur la précision de cette mesure, dans la mesure où le cotateur comprend le formalisme utilisé.
– Complétude de la spécification fonctionnelle• Dans la plupart des projets « modernes », on observe une non-stabilité
et/ou une inflation fonctionnelle durant la durée d ’un projet.– On constate souvent un taux d ’inflation de l’ordre de 30% sur certains
grands projets (dérive moyenne : env. 2% / mois)
14
Spécification fonctionnelle et PF (2)• Position dans le cycle de vie
– Suivant la complétude de la spécification fonctionnelle, le comptage des PF est une quasi-mesure ou une approximation.
– En terme de cycle de vie séquentiel, on a les cas suivants :Phase du cycle de vie Comptage Phase du cycle de vie Comptage
Proposition Etude de faisabilité
Approximation
Fin de conception Comptage « fin de conception »
Fin de réalisation Comptage final (mesure) Une inflation fonctionnelle est souvent observée durant le développement
15
La mesure fonctionnelle • Les Points de Fonction IFPUG
SYSTEMEsorties
données internes
interrogations
SYSTEME
entrées données externes
Entrées, Sorties, Interrogations sont des transactions (IFPUG 4.x)L ’aspect fonctionnel (vue utilisateur) est la base de la modélisation
16
Définitions• Application
– un ensemble cohérent de procédures automatisées et de données correspondant à un objectif de gestion de l'entreprise
» Dans la terminologie moderne, les procédures sont regroupées en « processus métiers»
• Projet– activité organisée de création ou de modification d'une application– activité organisée de création ou de modification d'une application
» C ’est dans le cadre du projet que l ’on fait l’estimation de la charge de développement.
• Taille en PF – PF projet (créés, modifiés, supprimés, migrés)– PF de l’application (socle)
17
Les étapes
• les étapes Définition du contexte
Identification des composants
Niveaux de complexitéNiveaux de complexité
Calcul des PF bruts
Facteurs d'ajustement
Calcul des PF nets
Valeur non ajustée
18
Contexte• Objectif du comptage
– Bilan de projet, Estimation de charge, mesure d’un Patrimoine applicatif ?
• Périmètre de la mesure– Fixer les frontières de l’application mesurée : les PF mesurent les
fonctions qui franchissent la frontière. • Utilisateurs• Utilisateurs
– Le périmètre fonctionnel correspond à l ’ensemble des utilisateurs d ’une application. En particulier toutes les vues utilisateurs doivent être prises en compte.
» Utilisateurs finaux, administrateurs, interfaces avec d’autres applications…
19
Identification des données: GDI (1)
• groupes logiques de données internes (GDI)– (ILF - Internal Logical File)– Groupe de données liées logiquement
ou de paramètres de contrôle– identifiables par l'utilisateur– mis à jour par l'application– utilisés à l'intérieur des frontières de l'application
20
Identification des données : GDE (1)
• groupes logiques de données externes (GDE)– (EIF - External Interface File)– Groupe de données liées logiquement
ou de paramètres de contrôle– identifiables par l'utilisateur– mis à jour par une autre application– utilisés à l'intérieur des frontières de l'application
21
Identification des données: GDI (2)
• GDI (exemples)– Exemples : données « métier » (client, fournisseur,
employé…). Historiques mis-à-jour dans l'application, paramètres permanents de l'application. Données de référence gérées...
– contre-exemples: fichiers techniques et temporaires, – contre-exemples: fichiers techniques et temporaires, fichiers log, tables utilisées mais non maintenues par l'application.
• Dans le cas de données partagées, un GDx peut être GDI pour plusieurs applications
• Dans le cas de données échangées, un cas typique est celui ou le GDx est GDI pour une application et GDE pour d ’autres applications.
22
Identification des données: GDE (2)
• GDE (exemples)– Exemples : données utilisées pour enrichir des
restitutions d'information, tables de référence de l'entreprise (gérées par une application tierce), données d'habilitation d'un système de sécurité centralisé…
– contre-exemples : ensembles de données partagées et – contre-exemples : ensembles de données partagées et mises à jour par l'application.
23
Définitions complémentaires - Données
• DE et SLD Une DE (Donnée Elémentaire) est un champ unique, non
répété, identifiable par l’utilisateur, consulté ou maintenu dans un GDI ou GDE lors de l’exécution d’un processus élémentaire.
Un SLD (Sous-ensemble Logique de Données) est un sous-groupe optionnel ou obligatoire d’un GDI ou GDE, identifiable par l’utilisateur. Un GDI ou GDE a au minimum un SLD. par l’utilisateur. Un GDI ou GDE a au minimum un SLD.
NB : termes anglais IFPUG : o DE = DET (Data Element Type), o SLD = RET (Record Element Type).
24
Niveaux de complexité des données
• complexité des GDI et GDE– nombre de Données Elémentaires (DE)
» (DET - Data Element Type)– nombre de Sous-Ensembles Logiques de données (SLD)
» (RET - Record Element Type)(RET - Record Element Type)
GDI et GDE nombre de DESLD de 1 à 19 de 20 à 50 > 50
1 Faible Faible Moyende 2 à 5 Faible Moyen Elevé
> 5 Moyen Elevé Elevé
25
Conseils complémentaires pour le comptage des Données
– Une application peut utiliser des GDI ou des GDE dans plusieurs processus, mais le GDI ou le GDE est compté une seule fois dans le périmètre de l’application.
– Un Groupe de Données ne peut pas être compté à la fois comme un GDI et un GDE pour une même application. Si le Groupe de Données satisfait les deux règles, il est compté comme un GDI.
– Ne pas considérer qu’un fichier physique, une table ou une classe objet égale un Groupe de Données lorsque l’on analyse les données par une approche un Groupe de Données lorsque l’on analyse les données par une approche logique du point de vue de l’utilisateur.
– Ne pas considérer que tous les fichiers physiques ou tables doivent être comptés ou inclus comme une partie d’un GDI ou d’un GDE.
– Un ensemble de constantes ne peut pas être compté comme un Groupe de Données.
– Entité Dépendance et Entité Indépendance : si deux entités sont fonctionnellement liées, on compte un seul Groupe de Données.
26
Compléments - 3 types de Données
• « Business Data » : données métier– Informations stockées et consultées nécessaires au domaine fonctionnel de
l’application, très dynamiques. – Par exemple : données du client. – Généralement comptées comme GDI.
• « Référence Data » : données de référence– Supportent les règles métier nécessaires à la maintenance des données métier,
peu dynamiques.
27
peu dynamiques. – Par exemple , types et termes d’une politique de gestion. – Souvent comptées, comme GDI ou GDE
• « Code Data » : données de codification- Liste de valeurs possibles d’un attribut- Données stockées permettant de standardiser et faciliter activités métier et les
transactions- En général, une clé et un ou deux attributs- Tables du type : « Code / Libellé »- Exemple : Code type de paiement
Identification des transactions: ENT (1)
• entrée (ENT)– (EI - External Input)– Processus élémentaire qui manipule des données liées
logiquement ou des paramètres de contrôle qui:» entrent dans l'application
maintiennent un ou plusieurs GDI» maintiennent un ou plusieurs GDI» initialisent/contrôlent un traitement» font l'objet d'un traitement spécifique
• Par opposition à un traitement générique (ex. un tri standard)
28
Identification des transactions: ENT (2)
• ENT (suite)– Exemples: données de mise à jour d'un GDI, saisie de
paramètres d'impression… – Contre-exemples: processus de navigation, saisie d’un
paramètre à des fins de consultation d’un objetTypiquement : fonctions de création, modification, – Typiquement : fonctions de création, modification, suppression, duplication … d’un objet
– Ex. : Créer un employé, Modifier un client…
29
Identification des transactions: SOR (1)
• sortie (SOR)– (EO - External Output)– Processus élémentaire qui manipule des données liées
logiquement ou des paramètres de contrôle qui:» sortent de l'application» sont le résultat d'un traitement spécifique autre qu'un » sont le résultat d'un traitement spécifique autre qu'un
simple traitement d'extraction de données
30
Identification des transactions: SOR (2)
• SOR (suite)– Exemples: impressions, rapports d'anomalie, restitution
d'informations, reports, exportation de données, informations destinées à une autre application…
– Contre-exemples: affichage de menus, boîtes de dialogue, messages d'aide, récapitulatifs dans un état, dialogue, messages d'aide, récapitulatifs dans un état, impression assistée par un langage de requête (ex: SQL)
Les SOR comportent des calculs (simples ou complexes), ou modifient le fonctionnement de l’application.
31
Identification des transactions:INT (1)
• interrogation (INT)– (EQ - External Query)– Combinaison entrée/sortie qui:
» ne fait pas de mise-à-jour de GDI» résulte d'un simple traitement d ’extraction de données,
sans traitement supplémentairesans traitement supplémentaire» ne contient pas de donnée calculée en sortie (ex: totaux)
32
Identification des transactions:INT (2)
• INT (suite)– Exemples : visualisation de données (détails) d’un GDI
(fichier ou table), listes sans traitement, aide en ligne, « log-in » sécurisé
– Contre-exemples : menus de navigation, affichages avec données calculées, états sur critères de tri différents ou données calculées, états sur critères de tri différents ou copies sur support divers
33
Définitions complémentaires
• Un Processus élémentaire (PE) est la plus petite unité d’activité identifiable par l’utilisateur. Il est autonome, constitue une transaction complète et laisse l’application dans un état cohérent.
• GDR = Groupes de Données Référencés (nombre de Groupes de Données lus et/ou mis à jour par le PE)
• Une DE (Donnée Elémentaire) est un champ unique, non répété, • Une DE (Donnée Elémentaire) est un champ unique, non répété, identifiable par l’utilisateur, consulté ou maintenu dans un GDI ou GDE lors de l’exécution d’un processus élémentaire.
» Compter une (seule) DE supplémentaire pour l’affichage des messages d’erreur
» Compter une (seule) DE supplémentaire pour les bontonsd’action et les touches de contrôle (Fn).
• En anglais : PE = EP (Elementary Process) ; GDR = FTR (File Type Referenced).
34
Transactions - synthèse des fonctions
• Tableau des fonctions– Pour clarifier les rôles des ENT, SOR et INT, le tableau suivant
introduit les fonctions « principales » et « autorisées »• N veut dire fonction interdite pour le type de transaction• P veut dire fonction principale dans le type de transaction• F veut dire fonction autorisée dans le type de transaction
Fonction Transaction ENT Transaction SOR Transaction INT
Modifier le fonctionnement de l’application
P F N
Modifier un ou plusieurs GDI
P F N
Présenter de l’information à un utilisateur
F P P
35
Processing logic used by EIs, EOs, EQs (1)
• Forms of processing logic– Legend:
• m : mandatory that the function type perform the form of processing logic
• m* : mandatory that the function type perform at least one of these (m*) forms of processing logic
• c : can perform the form of processing logic but is not mandatory
• n : cannot perform the form of processing logic
36
Processing logic used by EIs, EOs, EQs (2)Form of Processing logic EI EO EQ
Validations are performed c c c
Mathematical formulae or calculations areperformed
c m* n
Equivalent values are converted c c c
Data is filtered and selected using specifiedcriteria to compare multiple sets of data
c c c
Conditions are analysed to determinewhich are applicable
c c c
At least one ILF is updated m* m* nAt least one ILF is updated m* m* n
At least one ILF or EIF is referenced c c m
Data or control information is retrieved c c m
Derived data is created c m* n
Behavior of the system is altered m* m* n
Prepare and present information outsidethe boubdary
c m m
Capability to accept data or controlinformation that enters the applicationboundary
m c c
Resorting or rearranging a set of data c c c
37
Niveaux de complexité des transactions
– nombre de Groupes de Données Référencées (GDR) et de DE de l'entrée.» GDR = GDI ou GDE
ENT nombre de DEGDR de 1 à 4 de 5 à 15 > 15
0 ou 1 Faible Faible Moyen22 Faible Moyen Elevé
> 2 Moyen Elevé Elevé
SOR et INT nombre de DEGDR de 1 à 5 de 6 à 19 > 19
0 ou 1 Faible Faible Moyen2 ou 3 Faible Moyen Elevé
> 3 Moyen Elevé Elevé
38
Poids des objets• Les poids (non ajustés) des données et
transactions sont les suivants :Complexité Poids
GDI Poids GDE
Poids Sortie Poids Entrées/ Interrogations
Faible 7 5 4 3
Moyen 10 7 5 4
Elevé 15 10 7 6
39
Calcul des PF bruts
• exemple de méthode de calcul– Sommer, dans chaque type de composant, les
composants ayant même niveau de complexité;– Multiplier chaque nombre par le poids correspondant;– Faire les sous-totaux et le total général des points de
fonction bruts.fonction bruts.
• outillage mis en œuvre : tableur (Excel)
40
EXEMPLE 1Application “Consultation des dossiers d’acheteurs”
8 données différentes affichées, 1 ensemble de données utilisé pour l’affichage
3 Points de Fonction41
EXEMPLE 2
• 1 fonction TP : Créer un Utilisateur• Combien de Données élémentaires (DE) ?=> 1 Entrée Simple, soit 3 PF.
– NB : les 3 PF incluent les contrôles (login sur 8 caractères alphanumériques …), le dessin d’écran, la requête, mais aussi les spécset les tests.
• Mais cet écran « cache » aussi un Groupe de Données « Utilisateur »
42
Facteurs d’ajustement
Les caractéristiques générales du système consistent en un ensemble de 14 questions évaluant la complexité générale de l'application dans les domaines suivants :
Capacité transactionnelleTraitement de données répartiesPerformanceConfiguration à utilisation intensiveConfiguration à utilisation intensiveTaux de transactionSaisie interactiveConvivialitéMise à jour en temps réelComplexité des traitementsRéutilisationFacilité d'installationFacilité d'exploitationPortabilité de l’applicationFacilité d'adaptation
43
Facteurs d’ajustement 2Chaque caractéristique générale du système (CGS) doit être évaluée en fonction de son degré d'influence sur une échelle de zéro à cinq :0 Inexistante, ou sans influence1 Influence occasionnelle2 Influence restreinte3 Influence moyenne4 Influence significative5 Influence intensive partoutIl existe des critères pour déterminer le degré d'influence de chacune des caractéristiques Il existe des critères pour déterminer le degré d'influence de chacune des caractéristiques générales du système. Exemple : Performance 0 : Aucune exigence d'exécution particulière n'a été établie par l'utilisateur.1 : Les exigences relatives à la performance et à la conception ont été établies et revues, mais aucune action particulière n’a été exigée.2 : Le temps de réponse ou le débit sont critiques durant les heures de pointe. Aucune conception particulière concernant l'utilisation de la CPU n’a été exigée. Le délai de traitement est le jour ouvrable suivant.3 : Le temps de réponse ou le débit sont critiques durant toutes les heures ouvrables. Aucune conception particulière concernant l'utilisation de la CPU n’a été exigée. Les exigences de délai des traitements en interface avec l’extérieur sont contraignantes.4 : En outre, les exigences de performance spécifiées par l’utilisateur sont assez fortes pour exiger des tâches d'analyse de performance pendant la phase de conception.5 : En outre, des outils d’analyse de performance ont été utilisés au cours des phases de conception, de développement et/ou de mise en exploitation afin de s’assurer du respect des exigences de performance établies par l’utilisateur.
Les facteurs d’ajustement ne sont pas utilisés en France (non recommandés par l’ASSEMI), facultatifs dans les dernières versions IFPUG et hors périmètre de la norme ISO. Ils sont à remplacer par des « facteurs d’influence » qui affectent le coefficient de productivité permettant le passage des PF à la charge en JH.
44
APERCU DES METHODES DE MESURES RAPIDESMESURES RAPIDES
45
Principe des mesures rapides
• Simplification du modèle– En simplifiant le modèle quant aux objets à
modéliser ou aux poids à utiliser, on obtient un comptage plus rapide mais moins précis.
– Ces méthodes simplifiées donnent en général un – Ces méthodes simplifiées donnent en général un premier niveau d ’approximation … pour peu qu’on reste dans des contextes connus.
46
Calcul simplifié sur les poids
• prendre les valeurs moyennes des poids:– GDI: 10– GDE: 7– ENT: 4– SOR: 5– SOR: 5– INT: 4⇒écart moyen de 5 à 10 %
• Notion de CRUD : Create, Read, Update, Delete
47
Modélisation des données• Modèle de données
– On ne compte que les PF de données– On fait une approximation
• Total PF = K x PF données• Le facteur K est souvent compris entre 3 et 4 pour les SI
nouveauxnouveaux• Pour les SI d ’évolution, on observe que les traitements
évoluent en général plus vite que les données, et le facteur K a tendance à augmenter.
48
Exercices
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
PROJETS ET APPLICATIONSPROJETS ET APPLICATIONS
67
Projets et applications (1)
• projet d'évolution– formule pour comptage brut:– PFP = AJOUT + CHGAp + SUPP
ajoutémodifiémodifiésupprimé
version 1projet d'évolution v2
68
Projets et applications (2)
• application version 2:– PFA(v2)= PFA (v1) + AJOUT + CHGAp - CHGAv - SUPP
» CHGAp-CHGAv = solde de l ’opération de modification
ajoutémodifiésupprimé
version 1projet d'évolution v2
69
ESTIMATION DES CHARGES PROJETS
70
Principes de l’estimation de charge projet
• La charge (et/ou le coût) d’un projet est bien sûr l’élément fondamental suivi par le chef de projet.
• Pour passer de la taille fonctionnelle en PF à une charge en JH, on utilise des ratios de productivité (PF/JH)
• Ces ratios donnent des résultats fiables lorsque les deux principes suivants sont respectés.principes suivants sont respectés.– Un ratio est fiable dans un domaine (complexité, domaine applicatif,
environnement, équipes …) où l’on dispose de données de référence.
– Les activités prises en charge sont celles du cycle de développement MOE standard (de la conception générale à la « qualification usine »)
• Les activités supplémentaires telles que pré-étude, déploiement, formation … seraient à compter en plus.
71
Ratios de productivité • Ratios de productivité pour points de fonctions
– Les ratios de productivité utilisées dans les estimations en points de fonctions sont souvent exprimées en PF/h.j
– Dans la pratique on va de 0,2 PF/h.j (grands projets – Dans la pratique on va de 0,2 PF/h.j (grands projets complexes) à 5 PF/h.j (petits projets RAD sur PC).
• Facteurs d ’environnement– Sont intégrés directement dans le ratio de productivité.
• L ’idéal est de disposer d ’un référentiel projet suffisamment détaillé au niveau de l ’entreprise
72
Modèles d’estimation• Des modèles d’Estimation élaborés basés sur les Points de Fonction
et des bases de Benchmark sont disponibles sur le marché– Modèles à base d’Excel de sociétés internationales spécialisées – Outils packagés
• Ces modèles prennent en compte la taille en PF, et un certains nombres de facteurs non fonctionnels qui complètent ou remplacent les 14 facteurs IFPUG les 14 facteurs IFPUG
• Prise en compte de la complexité technique (exigences de performance, algorithmes complexes, outils de développement utilisés …)
• Prise en compte des facteurs organisationnels (relations avec MOA, outillage et expérience de la conception, du développement et des tests …)
• Ces modèles fournissent des estimations basés sur les moyennes du marché. L’étude et la capitalisation de projets terminées au sein de l’organisation étudiée est nécessaire pour adapter les modèles et obtenir des résultats fiables.
73
Charges additionnelles• Dans l ’estimation, on doit comptabiliser toutes les
activités, mais ne les compter qu’une seule fois.• En particulier, le ratio de productivité inclut une valeur
moyenne pour l ’activité de management projet MOE. Cependant dans certains cas, on considèrera des charge complémentaires, non incluses dans la productivité complémentaires, non incluses dans la productivité moyenne. Par exemple :– Activités liées à l ’amélioration de la qualité (CMM, ..)– Activités d ’assistance à la MOA (support aux pilotes, support au
déploiement)• Les charges MOA elles mêmes sont toujours comptées
séparément. Elles ne sont pas négligeables (couramment supérieures à 20%).
74
Estimation et suivi des délais de développement
• Formule très pratique bien qu’indépendante des points de fonction
• Estimation du délai nominal– On calcule souvent une valeur du délai de développement dite
« nominale », qui est plutôt interprétée comme le « minimum raisonnable ». Une formule couramment utilisée est :raisonnable ». Une formule couramment utilisée est :
Délai nominal = 2,5 (Effort)0,38
• Effort en h.mois• Délai en mois
• Délai planifié– Pour déterminer le délai planifié (et le calendrier), on tient compte
des contraintes du projet. Par exemples certaines activités doivent être sérialisées, ou ont une date butée.
75
Extensions de la méthode Extensions de la méthode IFPUG
76
Besoin d ’extensions à l ’IFPUG• La méthode créée par A.Albrecht en 1980 a été conçue
pour les SI de gestion de l ’époque. Elle a été reprise par l ’IFPUG et mise à jour pour les SI actuels.
• Néanmoins, certaines architectures (fonctionnelles) actuelles sont plutôt traitées comme des extensions aux règles IFPUG dans la mesure où un consensus ne s ’est règles IFPUG dans la mesure où un consensus ne s ’est pas dégagé sur de nouvelles règles de comptage.– C ’est le cas en particulier des types de SI suivants :
• Progiciels de gestion intégrés (PGI)• Architectures d ’échanges de données (EAI) • Applications WEB• DataWareHouses
77
Comptage des PGI• Principe
– Il existe principalement deux types de progiciels :• Les progiciels métiers : SAP, PeopleSoft ..• Les progiciels boite à outil : Documentum ..
– Les progiciels métiers ont une définition fonctionnelle qu ’on peut mesurer avec des points de fonction.mesurer avec des points de fonction.
• L ’idée de base est de partir du cahier des charges des fonctions réellement utilisées dans le PGI et de ne mesurer que ces fonctions.
– En terme de coût de développement, la réalisation des fonctions donnera lieu à 3 types d ’activités :
» Fonctions standard du PGI - à intégrer et tester» Fonctions obtenues par paramétrage» Fonctions spécifiques à développer
– Les progiciels boites à outils sont des cas spécifiques où il faut documenter une certaine « enveloppe fonctionnelle » pour obtenir une mesure PF
78
Le PF comme métrique généralisée (1)• Idée générale
– A l ’origine, l ’objectif des PF était surtout de servir de métrique pour l ’estimation des charges projet de développement de SI.
• Dans une telle opération, on passe de la taille en PF à la charge projet par application d ’un ratio de productivité en homme.jourprojet par application d ’un ratio de productivité en homme.jourpar PF.
– En généralisant l ’approche, on peut faire des mesures d ’autres activités liées au SI.
• Il reste cependant à vérifier la fiabilité des ratios si on veut les utiliser pour faire de la prévision.
79
Le PF comme métrique généralisée (2)• Métriques PF potentielles
– Coûts de maintenance par PF• Maintenance corrective• Maintenance adaptative (par exemple réglementaire)• Maintenance évolutive• Support utilisateur
– Coûts de déploiement par PF• Déploiement peut nécessiter adaptation à environnement
local– Taux de bugs résiduels par PF– Autres KPI
80
Aspects organisationnels (1)• Organisation type
– Dans les entreprises qui ont déployé l ’utilisation des PF, on a typiquement l ’organisation suivante :
• La DSI utilise l ’outil de façon intégrée à son référentiel méthode– Les chefs de projet MOE et les MOAD font de l ’estimation PF sur base de cahier des
charges.– Certains projets font aussi un comptage au niveau SFG (par exemple pour analyser les
écarts)écarts)– Le support a la méthode est confié à une cellule transverse (méthodes, architecture …)
» Suivant son organisation (et sa taille), la cellule transverse peut faire simplement du support/contrôle, ou se charger de tous les comptages.
» Cette cellule est responsable de capitaliser et gérer le référentiel d’estimation• Les MOA connaissent les principes de la méthode, mais en général ne font pas de
comptage.– Une opération de mesure de patrimoine peut s ’avérer lourde, mais utile car
permet aussi de retro-cartographier le SI.
81
Aspects organisationnels (2)• Les grands comptes en France ayant déployé les PF
– Renault• Sûrement les plus en pointe (cellule spécifique de 8 personnes)
– Michelin• En cours de déploiement
– France Telecom– France Telecom• En cours de déploiement
– Bouygues Telecom• En cours de déploiement
– Bouygues Construction• En cours de déploiement
– Autres entreprises faisant une utilisation partielle• PSA, SNCF, RATP, Banques ...
82
ETUDE DE CASETUDE DE CAS
83
Groupes de données
• On commence par recenser les données métiers de l’application (si modèle logique de données disponible). A défaut, un modèle physique peut aider (si l’application s’appuie sur une base de données relationnelle).
• Entités utilisées :• Objets métiers gérés• Objets métiers consultés
84
Fonctionnalités
• Recenser les fonctionnalités de l’application, à partir des spécifications.
• IHM : menus, puis fonctions de chaque écran• Puis étude des traitements Batch• Puis éventuellement les traitements de migration• Puis éventuellement les traitements de migration
• Fonctionnalités ou groupes de fonctions :• Fonctions élémentaires de chaque groupe
(ENT, SOR, INT)• Liens avec les groupes de données pour
déterminer la complexité
85
Exemple de Cotation (tableur)
86