[PDF] 1. Le jugement dexperts (Méthode Delphi)

View - Download 1. Le jugement dexperts (Méthode Delphi)

Previous PDF

Next PDF

1. L (Méthode Delphi)

moments et à différents niveaux (pour un projet entier ou pour une activité). On une aide à la décision de poursuivre ou non le projet.

La méthode Delphi fut élaborée en 1948 par la Rand Corporation, pour améliorer les prévisions

incertain ; les avis des experts, bien que parfois divergents, apportent des éclairages précieux. Cette méthode propose une démarche pour mettre en commun des jugements Elle est utilisée

La démarche est la suivante :

Dans un premier temps, chaque expert propose une estimation en utilisant sa propre expérience. Dans un second temps, tous les jugements sont rendus publics, mais restent anonymes. Chaque expert peut alors modifier sa propre estimation ou la confirmer. Chacun doit bien sûr considérer que tous les autres sont également des experts, ce qui le conduit à se poser des questions si ses propres estimations sont très éloignées de celles des autres.

Dans un troisième temps, les nouvelles estimations sont dévoilées et chacun peut justifier son

propre jugement. Dans un dernier temps, chacun propose une révision de son estimation.

premier tour. Dans tous les cas, cela permet de construire en commun une première analyse du projet.

Cette méthode, utilisée notamment dans les sociétés de services, peut comporter différentes variantes,

selon le mode de communication entre experts (oral, cycles de prévision et la fortement strictement individuelle en organisant la confrontation collective des

évite que certains exercent une trop grande influence sur les autres, ce qui biaiserait le résultat.

2. estimation par analogie

2.1 La méthode des répartitions proportionnelles

- Basée sur des observations de projets antérieurs, - La charge de chaque phase devrait correspondre à un pourcentage de la charge globale avec un certain intervalle de confiance, 2.1.1 Cette méthode peut être utilisée de plusieurs façons : temps, charge des autres étapes, En cours du déroulement du projet, on observe le temps déjà consommé pour en estimer le temps des phases à venir. Exemple : Estimation des répartitions proportionnelles a- Cycle de vie classique

Figure 1. Répartition proportionnelle d

Remarque :

- étude détaillée avec " étude préalable » à cause de deux facteurs la couverture et la maille,

- La charge de la phase " étude technique » est estimée par rapport à la phase " réalisation »,

- La charge de est estimée à la moitié de la charge de " réalisation ». Figure 2. Répartition proportionnelle dans les étapes de la phase : Etude préalable b- Modèle RUP Figure 3. Répartition proportionnelle des charges et durées des phases dans un modèle RUP

2.2 La méthode des ratios

- Variante de la répartition proportionnelle, - Utilisée pour en relation avec une autre activité, g

Encadrement du projet,

Recette,

a- Encadrement du projet réalisation. En stade. La coordination assurée par le responsable augmente de façon significative. b- La recette

La charge de recette dépend de la taille du logiciel. En effet, la recette est la procédure par

constatent ensemble que le produit (logiciel) livré correspond aux spécifications.

Les utilisateurs sont souvent impliqués dans la procédure, ce qui prépare le démarrage du futur

système. Les tâches de recette comprennent : L doivent permettre de vérifier que le système fonctionne et réagit correctement ; on bâtit de préférence des cas simulant le traitement entier recette sont destinés à faire des tests de fonctionnalité et non de volume. volume important de données et de transactions simultanées ; ils ne sont pas toujours nécessaires ;

Lextraire des parties de bases de

L lots et

pointer les résultats ; les traitements transactionnels sont testés en présence des deux parties, client et fournisseur. Un procès-verbal est dressé. c- taille du logiciel. La plupart des logiciels développés ont des aides utilisateurs intégrées pour la partie transactionnelle. Il faut néanmoins généralement livrer d-

La charge de la phase de mise en

souvent proportionnel au nombre et à la complexité des programmes écrits, mais les

évolutions organisationnelles pour

évaluer la charge. Si le futur système est implanté sur plusieurs sites, il faut prévoir une charge

additionnelle variant avec le nombre de sites. On applique parfois un ratio de 40 % sur la charge de réalisation, ce qui indique une relation

de proportionnalité avec la taille du logiciel. Mais cette estimation est en général affinée en

fonction du nombre de sites et de leurs caractéristiques techniques, organisationnelles et humaines. -à dire de passage de varier en fonction de deux critères : la complexité et le scénario. La complexité du passage situation avant/situation après se mesure par le nombre informations conversi-à-dire reprendre le contenu des anciens fichiers et les convertir selon les nouvelles structures de données. Le scénario retenu peut être ou non progressify a moins situations intermédiaires. Le risque est plus grand et la charge plus faible. un sous-projet à part

Programmes spécifiques de reprise et de

bascule. De plus, le scénario de mise en 3. lorsque

des types de composants, classés par nature et souvent par degré de difficulté, spécifiques de

-personne) des types de composants peuvent varier en fonction de la

Le tableau de la figure 4

transactionnels et programmes par lots. Les poids indiqués, en jours-personne, correspondent à des temps moyens. composants à

réaliser en les ventilant par nature. La charge obtenue, appelée charge de réalisation, couvre la

obtenir la charge complète, on rajoute en général :

Figure 4. Evaluation analytique pour un modèle classique (programme comprenant des lots et des transactions)

Nous donnons à la figure 5

Figure 5. Evaluation analytique intranet Lotus/Note

N : Nombre P : Poids C : Charge

estimation paramétrique

entre un ou plusieurs paramètres, qui sont des variables caractéristiques du projet, et la charge

prévisible. exemple, en divisant un coût global

Les méthodes basées sur un modèle proposent donc de repérer certains éléments simples, à partir

effort nécessaire. dans un schéma général (figure 6) comportant les étapes suivantes :

Figure 6. Etapes

4.1 Le modèle COCOMO

Le modèle Cocomo (Constructive Cost Model, modèle de construction des coûts) a été proposé en

1981 par B.W. Boehm [Boehm, 1984]. Ce modèle repose sur deux hypothèses :

informaticien chevronné sait plus facilement donner une évaluation de la taille du logiciel à développer que faire une estimation du travail nécessaire ; programme, quel que soit le langage de troisième génération employé.

Ces deux hypothèses ont conduit B.W. Boehm à calculer des coefficients de corrélation entre la taille du

s déjà réalisés. Le paramètre utilisé par ce modèle est . Il faut donc disposer du nombre présumé de charge de la réalisation en mois-personne, ainsi que le délai " normal », recommandé si on ne veut pas prendre de risques supplémentaires. Les formules de calcul de la charge et du délai sont les suivantes :

Charge en mois-personne = a (kisl)b

Délai normal en mois = c (charge en mois-personne)d avec kisl -à-dire le nombre de milliers de lignes de programme source testées.

Les paramètres a, b, c et d prennent des valeurs différentes selon la catégorie de projet. En effet,

duit à distinguer trois types de projet : simple, moyen et complexe. Un projet est simple si le logiciel comporte moins de 50 000 instructions, si les spécifications sont stables et le développement effectué par une petite équipe. Un projet est moyen si le logiciel comporte entre 50 000 et 300 000 instructions. Un projet est complexe si le logiciel comporte plus de 300 000 instructions et Les valeurs des paramètres sont les suivantes (figure 7) :

Figure 7. Formules Modèle Cocomo

Soit par exemple un projet simple visant à développer un logiciel estimé à 40 000 instructions sources :

Charge = 2,4 * (40)1,05 = 116 mois-personne (arrondi) Délai normal = 2,5 * (116)0,38 = 12 mois (arrondi) La méthode Cocomo prend en compte des caractéristiques propres au projet pouvant modifier par un coefficient de pondération appelé : facteur correcteur. Les valeurs des coefficients données par B.W. Boehm et obtenues de façon

statistique sur un échantillon limité et biaisé (les projets de sa propre société TRW) sont de moindre

intérêt que la démarche de correction. Celle-ci répartit les facteurs selon quatre sources de risques

(figure 8) : les exigences attendues du logiciel, les car (matériel), les caractéristiques de -même. Figure 8. Facteurs correcteurs du modèle : cocomo

- La fiabilité est le degré de régularité exigé ; dans le cas de systèmes mettant en jeu la vie

humaine (contrôle du trafic aérien) ou pouvant causer des pertes financières importantes (système temps réel de réservation), ce facteur aura une influence forte. - Le facteur base de données est mesuré par le ratio : (volume de données gérées en octets) sur (taille du logiciel en lignes).

Ainsi, si on gère 100 kilo-octets pour 1 000 lignes de programme, le ratio sera 100. La méthode

ratio est inférieur à 10, moyenne entre 10 et

100, forte entre 100 et 1 000 et très forte si le ratio est supérieur à 1 000.

- La complexité est celle des algorithmes à développer. - mme le contrôle du trafic aérien ou le système de cotation des valeurs mobilières. - La contrainte de délai se mesure par rapport au délai " normal ».

Chaque facteur peut prendre ses valeurs dans un intervalle spécifique, dont les valeurs résultent

la charge brute de façon multiplicative : Charge nette = Produit (valeurs des facteurs correcteurs) * Charge brute La méthode Cocomo propose donc une démarche en cinq temps : -à-dire en langage de programmation ; calcul de la charge dite " brute » ; charge dite " nette » ; Les facteurs correcteurs sont à utiliser avec précaution pour deux raisons : part, les valeurs proposées résultent ropose que chaque

COCOMO II, rendues publiques à partir

de 1997. Elle propose un affinement des paramètres de contexte et inclut des projets au stade de la méthode des points de fonction. Ce point est développé plus loin au paragraphe

4.2 La méthode des points de fonctions

a été quelques difficultés Un guide de comptage, publié en 1984, a favorisé sa diffusion. Des associations Group) fédère des associations nationales, et diffuse des versions mises à jour du guide de comptage. En France la FFPUG (French Function Point Users Group) n 1992, regroupant principalement des grandes entreprises, des

constructeurs de matériel informatique et des sociétés de services. Elle a organisé pendant plusieurs

é une norme sur la mise en de la méthode.

Le principe de la méthode des points fonctionnels est de faire une estimation à

externe du futur système, de ses " fonctions » ou composants " fonctionnels ». On identifie cinq types

avec trois degrés de complexité. À chaque type et chaque degré est affecté un nombre de " points », ce

qui permet de calculer, pour un projet donné, son poids en points de fonction. Différentes règles

permettront de passer des points de fonction à une charge.

La méthode propose de faire un comptage des points au début du projet en faisant des hypothèses sur les

fonctions du futur système et de refaire un comptage en fin de projet basé sur les fonctionnalités livrées.

appelé " changement

Un GDI (Groupe de

logiquement liées. e GDI à une entité du modèle

conceptuel ou à une association porteuse de propriétés, qui correspond à un objet de gestion.

GDI pour les deux entités. Si par exemple, dans le domaine Crédit, une entité échéance à recouvrer se

décompose en plusieurs entités ǯ (capital, intérêts, assurance.), on considère gestion.

Un GDE ȋȌǯ

Il est créé et mis à jour par un autre domaine. Un GDE est donc obligatoirement un GDI dans un autre

domaine.

Une ENT ȋȌǡǯǡǯes

ǯǯon dans un état de cohérence fonctionnelle.

Par simplification, une entrée correspond à un écran de saisie ou à une réception de données provenant

entrée permettant sa mise à jour. Chaque entrée (ENT) permet de saisir un certain nombre de champs, qui

sont des données élémentaires (DE). On compte une seule DE pour un champ répétitif. Une SOR ȋȌǡǯr, qui envoie des données vers correspond à lǯǡǯǯ

données. Sur chaque sortie figurent un certain nombre de champs, qui sont des données élémentaires (DE).

On compte une seule DE pour un champ répétitif. Si deux sorties ont la même logique de traitement et les

à jour

élémentaires (DE). On compte une seule DE pour un champ répétitif. Si deux interrogations ont la même

logique de traitement et les mêmes DE (par exemple, résultat papier et résultat écran), on ne comptera

Figure 9. Évaluation de la complexité des composants. Figure 9. Évaluation de la complexité des composants.

4.2.1 La complexité et le nombre de points de fonction

Un GDI ou un GDE est composé de données élémentaires (DE), ǯ

entité conceptuelle ou logique. On compte une DE par champ, y compris pour les clés étrangères.

On peut parfois identifier plusieurs sous-ensembles logiques de données (SLD) ǯǯ

GDI/GDE.

Dans un modèle de classes UML, un SLD peut être assimilé à une entité spécialisée : on compte un SLD pour

ǯité spécialisée.

ǯGDI ǯGDE est fonction du nombre de DE et du nombre de SLD, selon la figure 9.

Une ENT utilise, en lecture ou mise à jour, différents groupes logiques de données, internes ou externes

ȋȌǡǯ de façon générale des GDR, groupes de données référencées. Une SOR ou

une INT utilise, en lecture uniquement, différents GDR. ǯENTǡǯSOR ǯINT est fonction du nombre de DE et du nombre de GDR impliqués, selon le tableau de la figure 9. Figure 9. Évaluation de la complexité des composants.

Le tableau de la figure 10 donne, selon son degré de complexité, le nombre de points de fonction

correspondant à chaque composant fonctionnel. Figure 10. Nombre de points de fonction des composants.

La première étape de la méthode des points fonctionnels est un dénombrement des différents

composants fonctionnels et de leur degré de complexité : la somme des points de fonction de chaque

composant est appelée nombre de points de fonction brut (PFB).

On corrige le nombre de points de fonction brut, en appréciant les spécificités du projet pouvant influer

La méthode en identifie quatorze, appelées CGS, caractéristiques générales du système.

DI. , le DIT, compris entre 0 et 70

DIT = Somme (DI i) avec i = 1 à 14.

Le 35% :

FA = 0,65 + (DIT/100)

pour obtenir le nombre de points de fonction ajusté (PFA) :

PFA = FA * PFB

Chaque caractéristique isolément ne peut faire varier le nombre de PFB que de 35/14 = 2,5 %. Ce point

systématiquement réalisée, surtout quand on

4.2.3 La transformation du nombre de points de fonction en charge

recommandé que chaque entreprise établisse sa base de projets pour déterminer ses propres coefficients.

Ils proposent une formule de transformation du nombre de points de fonction en transformation

En général, on calcule la charge en convertissant directement le nombre de points de fonction. Les

estimations généralement retenues sont les suivantes : général 160 jours-personne en environnement grand système et 80 en environnement client-serveur. babiliste -Carlo.

estimation à trois points peut être utilisée à tous les niveaux, projet, phase, activité ou tâche. Elle

-à- rencontrera aucun problème (disponibilité des ressources, productivité, relations avec l difficultés ou imprévus ;

une valeur considérée comme la plus probable (p), avec une part vraisemblable de difficulté.

On prend alors comme estimation la valeur calculée suivante : moyenne = (f + F + p)/3 probable, on prend une moyenne pondérée : moyenne = (f + F + 4p)/6 La méthode de Monte-Carlo peut être utilisée avec une méthode ascendante.

ǯǡǡde la répartition des

logique de fonctionnement est la suivante :

1. Pour chaque activité, on tire au hasard une valeur de charge possible, selon la loi de distribution qui lui

est attachée.

2. On fait ensuite la somme de toutes les valeurs obtenues, et on obtient une valeur totale du projet ou de la

phase.

3. On recommence n fois les pas 1 et 2.

4. On prend la moyenne des n valeurs obtenues.

Figure 11. Premier tirage dans la méthode de Monte-Carlo (évaluation analytique, points fonctionnels) ne peuvent pas pourra dénombrer et auxquels on pourra attacher une quantité de travail.

Pour cela, on effectue un découpage du projet en tâches, en distinguant les tâches uniques et les tâches

répétitives. a- Tâches répétitives - -à-dire un paramètre.

» La charge

de tr lisateurs sur chaque site, on pourra dénombrer le nombre de sessions à assurer.

- Ensuite, on va déterminer le poids des paramètres associés aux tâches répétitives.

On peut utiliser différents moyens, notamment le prototypage et

- Le prototypage revient à réaliser sommairement une des tâches répétitives, ce qui donne une

unités, ce qui permet de

formation des utilisateurs, le poids sera la durée de la session de formation : on la déterminera en

formant deux ou trois utilisateurs pilotes. b- Tâches uniques,

Différents moyens peuvent être utilisés.

- On peut rechercher un paramètre propre à la tâche. Par exemple, pour la tâche " Construire le

charge de travail nécessaire à pour laquelle il faut préparer une formation.

- On peut éventuellement classer les fonctions selon leur degré de complexité et déterminer une

charge de préparation de formation correspondante.

- Sinon, on peut rapprocher cette tâche de tâches analogues sur des projets antérieurs et se baser

sur les charges consommées. - On peut également utiliser la méthode Delphi, par exemple avec trois ou quatre personnes dequotesdbs_dbs41.pdfusesText_41

[PDF] estimation budgétaire projet

[PDF] exercices calcul mental 4ème primaire belgique

[PDF] la compensation math

[PDF] jeux de mathématique pour 3e année

[PDF] estimer des quantités petite section

[PDF] cartes beaucoup pas beaucoup

[PDF] beaucoup pas beaucoup petite section

[PDF] fiche beaucoup pas beaucoup maternelle

[PDF] comparer des collections petite section

[PDF] séquence correspondance terme ? terme petite section

[PDF] cours dexpertise immobilière pdf

[PDF] expertise immobilière guide pratique pdf

[PDF] guide méthodologique relatif ? l évaluation des actifs immobiliers

[PDF] comment developper lestime de soi pdf

[PDF] comment se developpe lestime de soi