Un atelier de genie logiciel dedié a l'estimation du cout logiciel

CHAPITRE III

La Méthode Des Point Fonction

Et La Méthode Cocomo'81

1. INTRODUCTION 

Dans ce chapitre nous décrirons en particulier les méthodes cocomo'81 et point de fonction qui sont des méthodes algorithmiques pour l'estimation de coût d'un projet informatique. Nous donnerons aussi des définitions des différents composants utilisés par la méthode des points de fonctions et les étapes de comptage des points de fonction pour prévoir le coût logiciel.

2. LA METHODE DES POINTS DE FONCTION (ALBRECHT 79) 

2.1. Historique 

La méthode des points de fonction a été créée par Allan Albrecht en 1979.

Elle a été publiée pour la première fois lors d'une conférence IBM. C'était en effet la première fois que l'on proposait une mesure de production de logicielle basée sur les fonctions utilisateurs. Elle doit aider à prévoir la taille d'un projet, son effort de développement et la productivité du développement informatique.

En 1986, a été fondé par l'IFPUG (International Function Points Use Group) pour assurer la plus grande diffusion de cette méthode tout en garantissant son adéquation aux besoins des utilisateurs et sa normalisation.

De même en France, la FFUP (French Function Point User's Group) créée en 1992 a la même vocation.

La méthode des points de fonction est maintenant normalisée par L'AFNOR, sous la référence normative expérimentale XP Z 67-160.

2.2. Définition du contexte 

2.2.1. Frontières de l'application 

Utiliser la cartographie applicative pour identifier les limites de l'application à mesurer.

Ces limites définissent :

· Un ensemble de fonctions du métier identifiable et comprises par l'utilisateur.

· Des frontières stables, correspondant à la façon dont l'application est maintenue.

· Elles mettent en évidence les échanges de données entre l'intérieur et l'extérieur de l'application.

· Elles définissent la base des autres mesures (efforts, coûts, défauts ...).

2.2.2. Identification de l'utilisateur 

Les points de fonction mesurent ce que l'utilisateur a demandé et reçu. Il faut identifier l'utilisateur

L'identification de l'utilisateur est dépendante des objectifs de la mesure et modifie le périmètre de la mesures, par exemple :

· Pour la mesure d'un progiciel, seules les fonctionnalités utilisées par l'utilisateur doivent être considérées.

· Lors de la mesure d'un développement, toutes les fonctionnalités livrées dans le cadre du projet sont prises en compte

Les règles de l'IFPUG font référence à la notion de vue utilisateur, ou parle aussi de utilisateur expérimenté.

2.2.3. Règles et procédures des frontières du comptage  

La frontière est déterminée sur la base du point de vue utilisateur. L'important est de se concentrer sur ce que l'utilisateur peut comprendre et décrire.

La frontière entre des applications qui sont liées ne doit pas être basée sur des considérations technologiques mais sur la séparation des fonctions de gestion telles qu'elles sont vues par l'utilisateur

2.3. Définition des différents composants utilisés par la méthode des points de fonction 

2.3.1. Groupe logique de données internes(GDI) 

Groupe de données liées logiquement, ou de paramètres de contrôle identifiables par l'utilisateur, mis à jour et utilisés à l'intérieur de la frontière de l'application.

Si un fichier réel contient 1000 entrées de données personnelles, il sera compté comme un seul fichier.

Pour le comptage on peut partir d'un modèle de données (considérer les entités, relations porteuses de données), d'une liste de fichiers physiques, d'une liste de segments tables utilisateur et ne par présumer qu'un fichier physique égale un fichier logique.

Exemple : fichier logiques dans le système.

2.3.2. Groupe de données externes (GDE) 

Groupe de données liées logiquement, ou de paramètre de contrôle, identifiables par l'utilisateur, utilisés par l'application, mis à jour par une autre application.

Exemple : interfaces pour d'autres systèmes.

2.3.3. les entrées(ENT) 

Données ou paramétras de contrôle qui :

· Entrent dans l'application

· Maintiennent un ou plusieurs GDI

· Initialisent ou contrôlent un traitement

· Font l'objet d'un traitement unique (si on peut lancer le même traitement par plusieurs moyens par exemple l'entrée du nom, prénom et l'adresse d'un employé sera considérée comme une seule entrée

Exemple : fichiers, menus, etc. fournis par l'utilisateur. 

2.3.4. Les sorties (SOR) 

Données ou paramètres de contrôle qui :

· Sortent de l'application

· Sont le résultat d'un traitement unique autre qu'un simple traitement d'extraction de données (si on peut lancer un traitement par plusieurs moyens par exemple commande « E » ou « Editer », touche de fonction, il s'agit toujours d'une même sortie).

Exemple : les rapports, messages, fournis à l'utilisateur.

2.3.5. Les interrogations (INT) 

Combinaison Entrée-sortie qui :

· Ne fait par de mise à jour de GDI

· Ne résulte pas d'un traitement autre que des extractions de données

· Ne contient pas de données dérivées (calculées en sortie)

Exemple : entrées interactives nécessitant une réponse.

On associe à ces cinq entités Trois paramètres supplémentaires, qui vont permettre de ces paramètres sont les suivants :

Ø Données Elémentaires(DE) 

Chaque GDI ou GDE est composé de données élémentaires .une DE équivaut à un champ de données. On compte un seul DE par champ répétitif dans les entrées, les sorties, et les interrogations.

Ø Sous-ensemble logique de données (SLD) 

Relatif aux GDE et aux GDI.

D'un point de vue fonctionnel, ce sont les groupements logiques de GDI ou de GDE qui sont traitées simultanément dans l'application.

Ø Groupe de données référencées (GDR) 

Relatif aux ENT, SOR ou INT.

D'un point de vue fonctionnel, ce sont les groupements logiques de GDI ou de GDE qui sont mis à jour, ou consultés simultanément par les différents ENT, SOR ou INT.

2.4. Les niveaux de complexité

Pour chaque composant (données ou traitements), on détermine le niveau de complexité :

Ø Faible

Ø Moyen

Ø Elevé

Par exemple, pour les groupes de données internes on peut s'appuyer sur le modèle conceptuel ses données .dans un modèle entité relation on détermine les entités primaires. Ce sont typiquement les objets des bases de données -tables primaires-on évalue ensuite le nombre de relations entre les tables .Au sein des tables on compte le nombre d'éléments. Ces éléments permettent d'attribuer un niveau de complexité.

Prenons, par exemple, un modèle de données simple ou une table 1 est associée a deux autres par une relation 1 a plusieurs. Supposons que la table 1 comporte 15 champs contre 6 champs pour la table 2 et 4 pour la table 3.

Nous aurions 3 entités (les tables de paramètres ne sont pas prises en compte).L'entité table 1 a deux relations et moins de 20 éléments. Sa note de complexité donc faible. C'est également le cas pour les deux autres entités (1 seule relation et moins de 20 éléments).Dans cet exemple, nous avons donc 3 groupes de données internes de complexité faible. La même chose vaut pour l'autre fonction en tenant compte de leurs caractéristiques.

Pour chaque composant, le niveau de complexité se détermine de la même façon, on utilise une matrice dont les entrées lui sont propres mais qui reposent sur un comptage simple. La complexité (faible, moyenne, élevée) est déterminée par les tableaux (tab2, tab3 et tab4).

2.4.1. Complexité des groupes logiques de données (GDI et GDE) 

Le niveau de complexité est déterminé par le nombre se Sous-ensemble Logique de Données(SLD) et de Données Elémentaire du groupe logique de données (DE).

Les SLD sont des sous groupements de GDI(GDE) fondés sur la vue logique de l'utilisateur des données. Les DE sont des zones non récurrentes que l'utilisateur peut reconnaître et qui figurent dans le GDI(GDE).

Une DE est un attribut au sens de MERISE.les zones qui apprissent plusieurs fois dans un même GDI pour des raisons techniques, ne sont comptées qu'une seule fois.

Elément de données
		1 à 19 DE	20 à 50DE	51 DE ou plus
1 SLD		faible	faible	moyenne
2 à 5 SLD		faible	moyenne	élevée
6 SLD ou plus		Moyenne	élevée	élevée

Tableau 2: Matrice niveau de complexité GDE/GDI

2.4.2. Complexité d'une entrée ou partie entrée d'une interrogation 

Le niveau de complexité d'une entrée est déterminé par le nombre de groupe de données référencées (GDR) et DE de l'entrée ou de la partie entrée de l'interrogation.

Seules les DE mis a jour par l'Entrée sont comptabilisées.

Elément de données
	1 à 5 DE		6 à19 DE	20 DE ou plus
0 ou 1 GDR	faible		faible	moyenne
2 à3GDR	faible		moyenne	élevée
4GDR ou plus	moyenne		élevée	élevée

Tableau 3 : matrice niveau de complexité d'une Entrée ou partie d'une Interrogation

2.4.3. Complexité d'une sortie ou partie sortie d'une interrogation 

Le niveau de complexité d'une sortie est déterminé par le nombre de groupe de données référencées (GDR) et de DE de la sortie ou de la partie sortie de l'interrogation.

Le nombre de DE est celui de DE utilisées par la sorties.

Élément de données
		5 à 15 DE	16 DE ou plus
0 ou1GDR faible		faible	moyenne
2 GDR faible		moyenne	élevée
3GSR ou plus moyenne		élevée	élevée

Tableau 4: Matrices niveau de complexités sortie ou partie Sortie d'une Interrogation

2.5. Les étapes du comptage des points de fonction

Les étapes de comptages de cette méthode sont les suivantes :

Ø Il faut identifier un ensemble de fonctions identifiables par leurs spécificités.

Ø On classe chaque point de fonction comme simple, moyen ou complexe. Un nombre de transactions définit le seuil de chaque classification (simple, moyen ou complexe).

Ø On calcule ensuite le total non ajusté des poids des points de fonction .Pour cela, on calcule pour chaque type de points de fonction (simple, moyen...)le produit du poids par le nombre de cas. La somme de ces trois produits est égale au nombre brut de points de fonction du logiciel (non ajustés).

Ø Il faut déterminer le facteur de complexité technique(Facteur d'ajustement FA).C'est un facteur directement lié a la complexité du point de fonction( ex : portabilité du programme) et a l'expérience des personnes affectées au projet .On associe a chaque fonctionnalité du projet (probabilité, système multi_utilisateur....) un poids de 0 a 5 en fonction de l'importance de l tâche. En additionnant ces résultats, on obtient le facteur égale à ?F_{i .}On calcule le facteur de complexité suivant cette équation :

FA=0.6*(0.01*?F_i)

2.6. Calcul des Points de Fonction bruts (non ajustés)

Une fois toutes les entités isolés (ENT, SOR, INT, GDI, GDE) et leurs paramètres respectifs calculés (DE, SLD ou GDR), on pourra donc, pour chacun des composants, déterminer son niveau de complexité.

Une fois le niveau de complexité de chaque composant déterminé, il suffit de sommer le nombre de chacun des composants, pondérés par une valeur déterminée de sa complexité.

Points de fonction Grille de complexité
K (i, j)	Faible		Moyen	Elevé
GDI	7		10	15
GDE	5		7	10
ENT	3		4	6
SOR	4		5	7
INT	3		4	6

Tableau 5: Affectation de point de fonction aux complexités

PFB=? (C_{I, J}*K_{I, J})

Ø C_{I, J} correspond au nombre de composants calculés.

Ø K_{I, J} correspond au coefficient à attribuer à chacun des composants suivant son type et sa complexité (tableau 5)

Ø PFB correspond au nombre de points de Fonctions bruts calculés pour l'application

On peut, pour le calcule, utiliser également et directement le tableau du tableau 6.

Type de composant	complexité	Nombre	Totale par complexité			Totaux par types de composant
GDI	F	...........x	7			=...........
	M	...........x	10			=...........
	E	...........x	15			=...........
GDE	F	...........x	5			=...........
	M	...........x	7			=...........
	E	...........x	10			=...........
ENT	F	...........x	3			=...........
	M	...........x	4			=...........
	E	...........x	6			=...........
SOR	F	...........x	4			=...........
	M	...........x	5			=...........
	E	...........x	7			=...........
INT	F	..........x	3			=...........
	M	..........x	4			=...........
	E	..........x	6			=............
Nombre de points fonction bruts				=............

Tableau 6: Affectation de point de fonction aux composants.

2.7. Résumé du comptage en nombre brut de points de fonction

On peut résumer les différentes étapes d'un comptage par le schéma ci-dessous (figure III.1)

Détermination du périmètre de l'application

Identification de chaque composant

Evaluation de la complexité de chaque composant

Calcul du poids en points de fonction de chaque composant

Calcule du nombre brut de points de fonction

Fig III.1: Etape de comptage en points de fonction.

2.8. Conversion de points de fonction aux lignes de code

Les points de fonction non ajustés doivent être convertis en lignes de source de code dans la langue d'exécution (c++, java, prolog, langue fourth generation ,etc...)afin d'évaluer la taille du projet.

Langage	SLOC Par point de fonction
C	128
C++	52
JAVA 2	46
Cobol	107
ADA	41
prolog	64
Lisp	64
Assembleur	320
Basic	107
APL	32
2GL	107
4GL	20
Visuel basic 6	24
Delphi	18
HTML 4	14
SQL	13

2.9. Comptage du nombre de lignes de codes

2.9.1. Avantages

Ø Le nombre de lignes de code représente mieux l'effort à fournir ou la quantité de travail effectuée

Ø les mesures de productivité fondée sur le nombre de lignes de code ne varient pas en fonctions du langage utilisé.

Ø les taux d'erreur étant généralement proportionnel au nombre de lignes de code, sa connaissance améliore la planification de la phase de test

Ø pour les langages de troisième génération et orientées objet, le comptage du nombre de ligne de code est très facile et peut se voir automatisé.

2.9.2. Inconvenient

Ø Le nombre de ligne de code ne permet pas d'évaluer le coût prévisionnel d'un projet car il est difficile de les compter avant qu'elles ne soient écrites.

Ø le nombre de lignes de code peut être gonflé par le développeur suivant l'interprétation qui en sera faite

Elles sont pratiquement impossibles à compter dans de nouveaux environnements de développement de systèmes.

2.10. calcul de points de fonction Ajustés

L'étape suivante (facultative) consiste à ajuster ces points de fonction. Le principe est le suivant : on corrige le PDF grâce à un ensemble de 14 DI (degrés d'influence).

Chaque DI aura une valeur entre 0 et 5 en fonction de l'importance du degré d'influence sur l'application.

Le degré d'influence est classé de 0 à 5

0 : ne pas exister, ou pas influence

1 : influence incidente

2 : influence restreinte

3 : moyenne influence

4 : influence significative

5 : influence forte

Facteur d'ajustement des points de fonction 

Le questionnaire qui sert à ajuster les points comporte 14 facteurs qui font l'objet de réponses à choix multiples .Suivant la repense choisie on attribue une valeur qui varie de 0 à5.

Ces facteurs sont les suivants :

1. Transmission des données 

Application traitée par lot-batch-, entrée des données à distance, télétraitement interactif

2. Distribution 

On évalue ici la contribution de l'application au transfert des données (préparation des données sur un autre système, traitement dynamique des données sur un élément du système, etc,).

3. Performance 

On évalue ici, le fait de savoir si des objectifs de performance ont été dictés ou non par l'utilisateur.

4. configuration 

On mesure ici l'existence éventuelle de restrictions concernant l'exploitation de l'application

5. Taux de transaction 

Plus le taux de transactions est élevé plus il à d'influence sur la conception, la mise en oeuvre et le support de l'application.

6. Entrées des données en temps réel

Ce point du formulaire évalue l'importance des fonctions de commande et d'entrées de données interactives.

0. toutes les transactions sont traitées en différé.

1. de 1% à7% des transactions sont entrées en mode interactif.

2. de 8% à 15%des transactions sont entrées en mode interactif.

3. de 16%à 23%des transactions sont entrées en mode interactif.

4. de 24% à30% des transactions sont entrées en mode interactif.

5. Plus de 30% des transactions sont entrées en mode interactif.

7. convivialité (Efficacité d'interface) 

Ce point permet dévaluer les contrainte éventuelles posées par l'utilisateur concernant la convivialité et l'efficacité de l'application pour ce dernier, exemple (utilisation des menus, fonctions d'aide, mouvements automatiques du curseur, sélection de données de l'écran à l'aide du curseur l'impression à distance, une forte utilisation des options d'inversion vidéo, de clignotement, de soulignement, de couleur...).

Le calcule des points se fait de la façon suivante

0. Aucune catégorie ne s'applique

1. Une à Trois catégories s'applique

2. Quatre à cinq catégories s'appliquent

3. Six catégories ou plus s'appliquent, mais il n'y a aucun besoin relié spécifiquement à l'efficacité

4. Six catégories ou plus s'appliquent, et les besoins d'efficacité sont suffisamment importants pour exiger un effort.

5. Six catégories ou plus s'appliquent et les besoin d'efficacité é sont suffisamment important pour exiger l'utilisation d'outils et de processus spéciaux pour démontrer que les objectifs ont été atteints.

8. Mise à jour en temps réel :

On évalue ici si les entités internes de l'application sont mises à jour en ligne .On tient compte aussi de la protection contre la perte des données et du coût de la reprise.

1. Sans objet

2. Mise à jour en direct de 1 à 13 fichiers de contrôle.

3. Mise à jour en direct de plus de 3 fichiers de contrôle.

4. Mise à jour en direct des principaux dépôts internes.

5. En plus des mises à jour en direct, la protection contre les pertes de transactions.

6. Le programme offre des procédures de récupération automatisée.

9. Complexité du traitement :

On prend en compte la complexité du traitement défini de diverses manières : importance de la sécurité et du contrôle, importance du traitement logique et mathématique, importance des exceptions dans le traitement, importance des transactions avant d'être retraitées ; etc. On compte un point pour chaque catégorie.

10. Réutilisation :

On mesure ici l'effort accompli pour faciliter la réutilisation des programmes dans d'autres applications et de maîtrise.

11. Facilité d'implantation :

On évalue ici la facilité d'installation et notamment l'importance des conversions et leur degré de planification et de maîtrise

12. Simplicité d'utilisation :

Cette rubrique évalue la facilité d'exploitation de l'application. Procédures de démarrage, de sauvegarde, de relance, en cas de panne.

13. Installations multiples :

On évalue ici le fait de savoir si l'application a été conçue pour être mise en place dans des installations multiples.

14. Facilité des modifications, maintenance :

On mesure ici, le fait de savoir si l'application à été conçu pour faciliter les modifications (fonctions d'interrogations souples, etc.)

Le tableau suivant représente le questionnaire qui sert à ajuster les points de fonction :

Caractéristique générales du système	Description
Transmission des données	Combien de facilités de communication pour aider au transfert ou à l'échange d'information avec l'application ou le système?
Distribution du traitement et des données	Comment les données et les traitements distribués sont ils gérés ?
Critères de performance	L'utilisateur a t il des exigences en matière de temps de réponse?
Configuration matérielle	Quel est l'état de charge actuel de la plate-forme matérielle sur laquelle le système sera mis en exploitation?
Taux des transactions	Quelle est la fréquence d'exécution des transactions (quotidien, hebdomadaire, mensuel...) ?
Entrées des données	Quel est le pourcentage de données saisies en temps réel?
Efficacité des interfaces utilisateur (Convivialité)	Les interfaces ont elles été dessinées pour atteindre à l'efficacité maximale de l'utilisateur
Complexité du traitement	L'application fait elle appel à des traitements logiques ou mathématiques complexes?
Réutilisabilité	L'application est elle développée pour satisfaire un ou plusieurs besoins clients?
Facilité d'installation	Quelle est la difficulté de conversion et d'installation?
Simplicité d'utilisation	Quelle est l'efficacité et /ou l'automatisation des procédures de démarrage, backup, et récupération en cas de panne ?
Installation multiples	L'application est elle spécifiquement conçue, développée maintenue pour être installée sur de multiples sites pour de multiples organisations?
Facilité des modifications, maintenance	L'application est elle spécifiquement conçue, développée maintenue pour faciliter le changement?
Tableau 7: caractéristiques générales du système. [ANN 01] Ces 14 facteurs vont nous permettre de déterminer un coefficient de complexité du projet. On fait la somme des réponses (valeur comprise entre 0 et 5 pour chaque repense) fournies à l'ensemble des facteurs recensés dans le questionnaire. La somme des 14 facteurs, nous l'avons vu est comprise entre 0 et 70
FA=0.65 +0.01*
	Avec 0.65<FA<1.35

Puis on en déduit le nombre ajusté de points de fonction

PFA=PFA*FA

2.11. Calcul de la charge avec les points de fonctions

Le calcul de la charge (le point qui nous intéresse en particulier) est une fonction linéaire de PFB. (Ou de PFA si on l'a calculé).

Cette évaluation se fait grâce à un facteur multiplicatif.

Ce facteur multiplicatif est d'environ 3 Jours*Homme par Pont de Fonction en moyenne (2J*H si le projet est petit, 4 s'il s'agit d'un grand projet).

Charge de travail pour le développement

(En jour x homme=Point de fonction ajustés*nombre de jour x homme par points de fonction)

Charge=PFA * K

K : est le nombre de jour x homme par point de fonction (K est d'environ 3 Jours*Homme par Point de Fonction en moyenne ,2 J*H si le projet est petit ,4 s'il s'agit d'un grand projet).

2.12. Avantage et Inconvénients des points de fonction

2.12.1. Avantages

Ø La méthode des points de fonction est normalisée.

Ø Elle est utilisée dans de nombreuse entreprise pour mesurer la complexité ou la taille d'une application.

Ø Cette méthode est indépendante du langage et de la technologie utilisée.

2.12.2. Inconvénients :

Ø Problème d'assignation subjective: la complexité des fonctions élémentaires et de quatorze facteurs techniques est évaluée subjectivement sur l'échelle : simple, moyen et complexe ou de zéro à cinq. Le poids pour chaque catégorie et aussi déterminé subjectivement par <<débat et essai>> [DET 03]

Ø L'utilisation de cette méthode demande encore un travail important, la présence d'un spécialiste de cette méthode et ne peut pas encore être automatisée.

Ø Le comptage d'une personne à une autre peut varier de 10 %contrairement à ce que la méthode présente théoriquement.

3. LA METHODE COCOMO'81 (BOEHM)

L'estimation de l'effort (en homme mois) fait suite à l'estimation de la taille (en lignes de code source) et permettra de définir un calendrier pour le projet.

La méthode COCOMO'81 fournit un algorithme permettant de dériver une évaluation, de l'effort et du planning à partir de l'estimation de la taille du logiciel. Nous donnons en référence la méthode de (Putman and Myers 1992) qui conduit également à une évaluation de l'effort

3.1. Historique 

La méthode COCOMO, pour COnstructive COst Model a été développée par Dr. Barry Boehm pour estimer l'effort et le temps de développement d'un produit logiciel. A l'origine elle a été construite à partir d'une analyse des données par régression pratiquée sur 63 projets logiciels (gestion et informatique industrielle) comprenant de 2000 à 100.000 lignes de code dans l'entreprise TRW (USA). COCOMO à l'avantage d'être un modèle

Ouvert. Les données de calibrage, les formules et tous les détails des définitions sont disponibles. La participation à son développement est encouragée.

Aujourd'hui, COCOMO II est un nouveau produit beaucoup plus adapté à l'aspect réutilisation des composants (modules existants). La version 1998 a été calibrée sur 161 points de données, en utilisant l'approche statistique Bayesienne pour combiner les données empiriques avec les avis d'experts. De plus elle peut être ré-calibrée sur les données de l'entreprise. Un nouveau modèle appelé COCOTS, est en cours de développement par l'équipe de COCOMO. Ce modèle permet d'estimer les coûts et planifier des projets logiciels utilisant des composants existants. C'est encore un projet de recherche. Pour les projets basés sur une technologie traditionnelle, le modèle original de 1981 est encore valable, d'autant plus qu'il est maintenant rodé et bien documenté.

3.2. COCOMO 81 

Le modèle COCOMO 81 s'appuie sur une estimation de l'effort en homme*mois (HM) calculée par la formule :

Effort = C*M*taille**s

C : facteur de complexité

M : facteur multiplicateur

Taille : en milliers de lignes de code source livrées (KDSI)

S : proche de 1

Hypothèses :

KDSI livré :

Ø Exclut en général les environnements de tests, les supports de développement.

Ø Exclut les commentaires.

Ø Inclut le Shell.

Le modèle COCOMO 81 est en fait constitué de trois modèles :

Ø Le modèle de base.

Ø le modèle intermédiaire.

Ø le modèle détaillé ou expert.

3.2.1. Le modèle de base 

Le modèle de base estime l'effort (le nombre d'homme mois) en fonction du nombre de milliers d'instructions source livrées(KDSI), de la productivité (le nombre de lignes de code par personne par mois) et d'un facteur d'échelle qui dépend du type de projet. Les 3 types de projet identifiés sont :

· organique

Il est défini par une innovation minimale, une organisation simple en petites équipes

Expérimentées. (Ex: petite gestion, système de notes dans une école, petits systèmes D'exploitation, traducteurs).

· médian (semi-detached)

Il est défini par un degré d'innovation raisonnable, (exemples: Compilateurs, Contrôle de Processus simple, système bancaire interactif)

· imbriqué :

Dans ces projets le niveau d'innovation est important, l'organisation complexe, couplage fort avec beaucoup d'interactions, (exemples: Gros système d'exploitation, Systèmes Transactionnels complexes, système de contrôle aérospatial.)

Type de projet	Effort en homme mis(HM)	Temps de développement
Organique	2.4(KDSI)^1.05	2.5(HM)^0.38
Médian	3.0(KDSI)^1.12	2.5(HM)^0.35
Imbriquer	3.6(KDSI)^1.20	2.5(HM)^0.32

Tableau 8: Formules d'estimation COCOMO pour le modèle de base.

EXEMPLES 

Effort(HM)	2KDSI	8KDSI	32KDSI	128KDSI	512KDSI
Organique	5	21.3	91	392
Médian	6.5	31	146	687	3250
Imbriqué	8.3	44	230	1216	6420

Tableau 9: Effort en HOMMES MOIS (HM) en fonction de la taille et du type de projet

TDEV (mois)	2KDSI	8KDSI	32KDSI	128KDSI	512KDSI
organique	4.6	8	14	24
Médian	4.8	8.3	14	24	42
Imbriqué	4.9	8.4	14	24	41

Tableau 10: Temps de développement (en mois) en fonction de la taille et du type de projet

Le temps de développement commence après les spécifications fonctionnelles et s'arrête après l'intégration De ces chiffres on peut déduire la productivité (KDSI/HM) et le nombre moyen de personnes sur le projet (FSP=HM/TDEV).

Exemple :

Soit un projet estimé à 32 KDSI en mode organique,

HM = 2.4 * (32)1.05 = 91 HM

TDEV = 2.5 * (91)0.38 = 14 Mois

PRODUCTIVITE = 32000 DSI/91 HM = 352 DSI/HM

FSP = 91 HM / 14 MOIS = 6.5 FSP

3.2.2. Le modèle intermédiaire 

Le modèle de base ne prend en compte que le nombre de lignes source et induit des discontinuités un peu brutales au niveau du personnel entre chaque phase du cycle de vie; ce qui peut perturber l'organisation du projet.

Le modèle intermédiaire introduit 15 facteurs de productivité (appelés 'cost drivers'), représentants un avis subjectif du produit, du matériel, du personnel, et des attributs du projet. Chaque facteur prend une valeur nominative de 1, et peut varier selon son importance dans le projet. Les 15 facteurs sont multipliés entre eux pour donner un facteur d'ajustement qui vient modifier l'estimation donnée par la formule de base.

· Facteurs de productivité 

F Logiciel :

RELY: Fiabilité requise.

DATA: Volume des données manipulées.

CPLX: Complexité du produit.

F Matériel :

TIME: Contraintes de temps d'exécution.

STOR: Contraintes de taille mémoire.

VIRT: Instabilité de la mémoire.

TURN : Contraintes de système de développement

F Personnel :

ECAP: Aptitude de l'équipe.

AEXP: Expérience du domaine.

VEXP: Expérience de la machine virtuelle.

LEXP: Maîtrise du langage.

F Projet :

MODP: Pratique de développements évolués.

TOOL: Utilisation d'outils logiciels.

SCED: Contraintes de délais.

Multiplicateur		Très bas	Bas	Normal	Elevé	Très élevé	Extrêmement élevé
RELY		0.75	0.88	1	1.15	1.4
DATA			0,94	1	1.08	1.16
CPLX		0.7	0.85	1	1.15	1.3	1.65
TIME				1	1.11	1.3	1.66
STOR				1	1.06	1.21	1.56
VIRT			0.87	1	1.15	1.3
ECAP		1.44	1.18	1	0.86	0.7
AEXP		1.29	1.13	1	0.91	0.82
VEXP		1.21	1.1	1	0.9
LEXP		1.14	1.07	1	0.95
MODP		1.24	1.1	1	0.91	0.82
TOOL		1.24	1.1	1	0.91	0.83
SCED		1.23	1.08	1	1.04	1.1

Tableau 11: coefficients multiplicateurs pour chacun des facteurs de productivité

Type de projet	Effort en homme mois(HM)	Temps de développement
Organique	3.2(KDSI)^1.05	2.5(HM)^0.38
Médian	3.0(KDSI)^1.12	2.5(HM)^0.35
Imbriqué	2.8(KDSI)^1.20	2.5(HM)^0.32

Tableau 12: coefficients pour le calcul d'effort et de temps dans le

Modèle intermédiaire

3.2.2.1. Calcul de l'effort (HM) dans le modèle intermédiaire 

Identifier le mode de développement - organique, médian, imbriqué). Ceci donne 4 coefficients au modèle :

p (productivité nominative),

e (échelle appliquée à la taille du logiciel),

c (constante du modèle)

d (échelle appliquée au temps de développement) conformément au tableau 12.

Estimer le nombre de lignes du code source (en KDSI), puis calculer le nombre d'homme*mois par la formule appropriée du tableau 12. On obtient HM base.

Estimer les 15 facteurs de productivité et calculer le facteur d'ajustement (a) en multipliant les facteurs ensemble conformément au tableau 11

Multiplier l'effort 'nominal' par le facteur d'ajustement :

HM = HM base * a

Calculer le temps de développement en utilisant le tableau 12:

TDEV = c(HH) ^d

(On notera que les coefficients restent inchangés par rapport au modèle de base) Dans le modèle intermédiaire, les coefficients multiplicateurs s'appliquent uniformément sur l'ensemble des phases.

3.2.3. Modèle expert 

Le modèle expert inclut toutes les caractéristiques du modèle intermédiaire avec une estimation de l'impact de la conduite des coûts sur chaque étape du cycle de développement : définition initiale du produit, définition détaillée, codage, intégration. De plus, le projet est analysé en termes d'une hiérarchie : module, sous système et système. Il permet une véritable gestion de projet, utile pour de grands projets. Le modèle expert n'est pas décrit ici.

· Démarche 

Ø Estimation de la taille (nbr d'instruction source).

Ø Calcule de charge « brute ».

Ø Sélection des facteurs correcteurs.

Ø Application des facteurs correcteurs à la charge brute pour obtenir la charge « nette ».

Ø Evaluation de délai normal.

4. CONCLUSION :

La gestion de projet est une des meilleures garanties de l'assurance qualité, elle permet la maîtrise du processus de développement.

Les méthodes COCOMO'81 et points fonction peuvent être programmées très simplement sur des tableurs.

Enfin pour la documentation technique des outils comme Interleaf ou Framemaker seront préférés à Word pour leur facilité d'interfaçage avec les outils d'analyse et conception.