LA METHODE COCOMO
(COnstructive COst MOdel, Barry Boehm 1981)
La méthode COCOMO couvre les développements informatiques, de la conception à la recette finale.
Hypothèse de départ :
- Le projet est bien géré par les informaticiens.
- Le projet est bien géré par les utilisateurs.
Variable de départ = KISL = Kilo Instructions Sources Livrées.
1 KISL = 1000 instructions sources à écrire effectivement (on ne comptera pas par exemple les lignes de code des squelettes de programme, mais celles que l’on rajoute aux squelettes pour obtenir le programme final). On comptera donc :
- – Instructions sources
- – Instructions de JCL
- – Déclarations de champs
- – Lignes d’états
(En COBOL on utilise 2,5 fois moins de lignes qu’en assembleur . . . .
=> Le KISL tient compte du type de langage utilisé).
* Le KISL est une variable assez bien estimée par les informaticiens
(erreur de + – 20% par rapport à + – 300% sur la charge de réalisation).
ETAPE 1 : Estimer le nombre de KISL résultant du projet
EXEMPLE : Pour le développement d’un projet à l’aide d’un L4G classique, de squelettes de programmes, d’héritage d’objets, on peut estimer le nombre de lignes de code à rajouter pour un type de programme donné, suivant sa complexité.
Il suffira ensuite d’estimer le nombre de programmes par type, nécessaires au développement du projet considéré :
ETAPE 2 : Détermination du mode de développement
Suivant le contexte général du projet, on choisit un des 3 modes de développement suivant :
MODE ORGANIQUE
- Petites équipes de développement (2 à 8 personnes)
- Bonne connaissance du domaine métier
- Projets petits ou moyens (10 à 50 KISL)
- Spécifications stables
- Projets développés à l’intérieur de l’entreprise
MODE MEDIAN (intermédiaire, semi – détaché)
- Projets moyens et grands (< 300 KISL)
- Personnels ayant des expériences et connaissances variées
- Aspects de sous-traitance, forfaits
MODE IMBRIQUE
- Très grands projets
- Contraintes sévères avec forte imbrication hard / soft
- Interfaces complexes
- Domaines nouveaux, avec des algorithmes peu ou mal connus
- Tout changement de spécifications entraîne des coûts élevés
=> Equipes nombreuses et déséconomies d’échelle
ETAPE 3 : Calcul de la charge estimée brute
En fonction du mode de développement, on applique une des formules suivantes, donnant l’effort à fournir pour développer le projet, indépendamment de l’environnement qualitatif du projet :
* Note : Le résultat est exprime en Mois * Homme
ETAPE 4 : Répartition de la charge brute par phase
En fonction du mode de développement du projet ainsi que de sa taille on sélectionne le jeu de pourcentages approprié dans le tableau suivant. On obtient donc un pourcentage d’effort nécessaire à la réalisation de chaque phase de développement. On réparti donc la charge précédemment calculée sur les différentes phases. La somme des pourcentages pour les phases du cycle de vie d’un projet est supérieur à 100%. En effet on considère que la phase de spécifications générales / cadrage est déjà effectuée, et que la charge totale brute correspond au développement du projet, de la phase de conception (analyse) à la phase d’intégration / tests.
ETAPE 5 : Détermination des facteurs correctifs
Pour chaque facteur correctif, on détermine son influence sur le projet, et donc l’ensemble des 4 coefficients de l’intersection correspondante. Comme on le verra plus loin, chaque coefficient s’appliquera ensuite à une phase de développement en diminuant ou augmentant sa charge (nombre de mois * hommes nécessaires à sa réalisation). Le premier coefficient est identique pour les deux phases de spécifications et de conception.
ETAPE 6 : Calcul des charges nettes
Pour chaque phase du cycle de vie du projet on réalise les deux opérations suivantes :
- Calculer le produit des facteurs correctifs qui concernent la phase
- Multiplier la charge estimée brute de la phase, par le résultat du calcul précédent
ETAPE 7 : Calcul du délai total optimal
En fonction du mode de développement du projet, on applique une des formules de calcul suivantes, indiquant le délai total nécessaire à la réalisation complète du projet. On utilisera MH = Charge nette totale du projet : C’est la somme des charges nettes des phases du cycle de vie. Ces charges ont été calculées précédemment par l’application des facteurs correctifs aux charges estimées brutes des phases. Le délai est exprimé en mois :
ETAPE 8 : Répartition du délai total par phase
En fonction du mode de développement du projet ainsi que de sa taille, on sélectionne le jeu de pourcentages approprié dans le tableau suivant. On obtient donc un pourcentage de délai nécessaire à la réalisation de chaque phase de développement. On réparti donc le délai précédemment calculé sur les différentes phases. La somme des pourcentages pour les phases du cycle de vie d’un projet est supérieur à 100%. En effet on considère que la phase de spécifications générales / cadrage est déjà effectuée, et que la délai total correspond au développement du projet, de la phase de conception (analyse) à la phase d’intégration / tests.
ETAPE 9 : Détermination d’une contrainte de délai
Si le délai ou le niveau de personnel sont trop importants, il est possible de modifier le délai initial dans les limites suivantes :
Délai initial * 75% <= Nouveau délai <= Délai initial * 160 %
On détermine alors le facteur “Contrainte de délai”, en fonction du paramètre :
CONTRAINTE = (Nouveau délai / Délai initial) * 100 :
On recalcule ensuite les charges nettes pour chaque phase (Etape 6), en tenant compte du facteur “Contrainte de délai”. On réparti enfin le “Nouveau délai” sur les phases (Etape 8).
LA METHODE DES POINTS DE FONCTION
(ALLAN ALBRECHT 1979)
Son principe repose sur l’identification de cinq aspects externes à l’application donnant un “nombre de points de fonction” qui, une fois ajusté à l’aide de quatorze facteurs qui sont eux aussi propres à l’application, est lié à ce que demande l’utilisateur et indépendant de la façon dont le développement sera effectué. Typiquement, on comptabilisera ici les éléments issus de la phase de conception / cadrage.
Les cinq aspects externes
La description de ces éléments quantitatifs est ici basée sur un modèle utilisé par les méthodes anglo-saxonnes : le diagramme de flux de données. Ce modèle correspond au modèle conceptuel des traitements développé avec la méthode Merise.
On a alors la correspondance suivante :
LES ENTREES :
On compte les flux de données distincts, qui entrent dans le sous-système de l’entreprise représenté par le projet à estimer. Ces flux venant de l’extérieur du projet vont ajouter ou modifier des données dans les fichiers logiques internes au projet. On ne prendra ici en compte que les feuilles du diagramme de flux de données.
Dans l’exemple suivant on compte 4 Entrées (flèches en gras) :
LES SORTIES :
On compte les flux de données distincts, qui sortent du sous-système de l’entreprise représenté par le projet à estimer.
Dans l’exemple suivant on compte 2 Sorties :
Les Macro Entités :
On compte les Entités du modèle conceptuel des données, ou les Dépôts élémentaires du diagramme de flux de données, dont les occurrences sont créées ou mises à jour par les processus du système étudié.
Dans l’exemple suivant on compte 4 Fichiers Logiques :
LES FICHIERS INTERFACE EXTERNES :
On compte les fichiers logiques partagés avec d’autres applications, et non mis à jour par l’application.
Dans l’exemple suivant on compte 1 Fichier Interface :
LES INTERROGATIONS :
On compte les couples Entrées / Sorties sans mise à jour. Une entrée génère alors une réponse immédiate représentée par une sortie. On inclus les interrogations générées par un utilisateur ou par une autre application. Dans ce dernier cas deux processus de deux projets différents sont alors synchrones.
Dans l’exemple suivant on compte 1 Interrogation :
Chacun des éléments comptabilisé est ensuite ventilé suivant un critère de difficulté :
SIMPLE :
Le modèle de données externe induit par l’élément comporte une seule entité avec peu d’attributs, et peu de contraintes d’intégrité référentielles vers d’autres entités.
MOYEN :
Le modèle de données externe induit par l’élément, comporte 2 entités ayant chacune environ 10 attributs et 2 contraintes d’intégrité référentielles vers d’autres entités. Ce modèle peut également comporter une relation multiple ou porteuse d’attributs. Les règles de gestion appliquées à ces entités sont moins triviales, et peuvent poser des problèmes de temps de réponse.
COMPLEXE :
Le modèle de données externe induit par l’élément, comporte de nombreuses entités dont certaines ont un grand nombre d’attributs. On y trouve quelques relations multiples, les règles de gestion qui concernent le modèle sont complexes. Le modèle devra être optimisé, notamment en y introduisant de la redondance d’information, afin de satisfaire aux contraintes de temps de réponse. Le volume de ces données est important et l’on doit se poser le problème de leur récupération en cas d’incident.
(Pour les éléments fichiers logiques internes et interfaces, le nombre d’entités induit par le modèle externe des données, n’est bien sur pas pris en compte).
ETAPE 1 : Calcul des points de fonction bruts
On quantifie les cinq aspects externes, que l’on ventile suivant le critère de complexité. En appliquant les coefficients de pondération du tableau ci – dessous, on obtient le nombre de points de fonction brut : PFB
ETAPE 2 : Détermination des facteurs d’ajustement
On ajuste ensuite le nombre de points de fonction bruts en appréciant l’influence (notée de 0 à 5) de quatorze facteurs :
0 => Le facteur n’a pas d’influence
5 => Le facteur a une influence essentielle
FACTEURS D’AJUSTEMENT :
* LE TELETRAITEMENT
Ecrans, réseaux etc. à mettre en place.
. 0 : Base de données et programmes sur la même machine, écrans VTxxx
. 1 : Pc en émulation, avec présentation plus ergonomique
. 2 : Application X-Window
. 3 : Logique d’application distribuée, appels de procédures stockées
. 4 : Gestion déportée des données, tables locales.
. 5 : Distribution des données
* LA DISTRIBUTION DES DONNEES / TRAITEMENTS
. 0 : Aucun transfert de données.
. 1 : Données préparées pour transfert aux utilisateurs ou à une autre composante du système.
. 2 : Données préparées, transférées et traitées par une autre composante du système.
. 3 : Utilisation de Replication Server dans un seul sens.
. 4 : Utilisation complexe de Replication Server.
. 5 : Utilisation de Navigation server.
* LES PERFORMANCES
Quelle influence ont les objectifs de performances donnés par les utilisateurs sur l’analyse, la construction, l’installation et le support de l’application ?
. 0 : Aucune.
. 1 : Revue du design logique de l’application.
. 2 : Les temps de réponse sont critiques aux heures de pointe.
. 3 : Les temps de réponse sont critiques à toutes heures.
. 4 : Nécessité d’un environnement de tests de performances pendant la réalisation.
. 5 : Optimisation nécessaire pendant toutes les phases du cycle de vie.
* LA CHARGE SUR LA CONFIGURATION
Une configuration fortement chargée demande un design spécifique.
. 0 : Aucune restriction.
. 1 : Planification des batch en fin de journée.
. 2 : + Sauvegardes volumineuses.
. 3 : + Gestion lourde de la sécurité, timing des transactions.
. 4 : + Configuration dédiée à une partie de l’application (base décisionnelle ….)
. 5 : + Optimisation du modèle de données due aux volumes importants.
* LE TAUX DE TRANSACTIONS PAR SECONDE
Quelle influence a le taux de transactions par seconde et les ‘peak period’ sur l’analyse, la construction, l’installation et le support de l’application ?
. 0 : Pas de pointe d’activité.
. 1 : Pointe d’activité mensuelle.
. 2 : Pointe d’activité hebdomadaire.
. 3 : Pointe d’activité journalière.
. 4 : Haut débit de transaction, présentation spéciale de l’application.
. 5 : Haut débit de transaction, présentation et outils spéciaux.
* LA PRESENCE D’UNE SAISIE INTERACTIVE
. 0 : application totalement Batch.
. 1 : application 30% on-line, 70% Batch.
. 2 : application 50% on-line 50% Batch.
. 3 : application on-line à 70% et plus.
. 4 : aspects de temps réel.
. 5 : application temps réel.
* L’EFFICACITE DES UTILISATEURS : ERGONOMIE
Nombre de fonctions ou d’aménagements destines à faciliter l’utilisation finale de l’application :
. Aide pour la navigation dans l’application (touches de fonction, menus dynamiques, mode expert ….).
. Aide on-line.
. Déplacement automatique du curseur.
. Scrolling.
. Impressions en remote sur les transactions on-line.
. Soumissions de batch à partir des transactions on-line.
. Utilisation lourde des attributs vidéo.
. Minimiser le nombre d’écrans.
. Pré-chargement de données sur le poste client.
. Application multi-lingue.
. 0 : Aucune de ces fonctions.
. 1 : De 1 à 3.
. 2 : De 4 à 5.
. 3 : Plus de 5.
. 4 : Plus de 5 – Présentations spécifiques demandées (hors normes).
. 5 : Plus de 5 – Présentations et outils spécifiques (hors normes).
* LA MISE A JOUR DES DONNEES EN TEMPS REEL
Quelle influence sur le design de l’application, à la mise à jour des données on-line ? (contrôle des données avant mise à jour)
. 0 : Nulle.
. 1 : De 1 à 3 fichiers de contrôle, avec un faible volume.
. 2 : Plus de 3 fichiers de contrôle, avec un faible volume
. 3 : Nombreuses tables de références.
. 4 : Nombreuses tables de références avec protection contre les pertes de données.
. 5 : Nombreuses tables de références volumineuses avec protection et pré-chargement.
* LA DIFFICULTE GLOBALE DES ALGORITHMES
. 0 : Très simple.
. 1 : Simple.
. 2 : Moyen.
. 3 : Complexe.
. 4 : Très complexe
. 5 : Personne n’a jamais fait aussi complexe.
* LA REUTILISATION DU LOGICIEL (PACKAGE)
Est ce que le code de l’application doit être spécifiquement structuré, développé et supporté afin d’être utilisé dans d’autres applications ? (aspects de progiciels).
. 0 : Non.
. 1 : Une partie du code réutilisable.
. 2 : Moins de 10% des modules réutilisables.
. 3 : Plus de 10% des modules réutilisables.
. 4 : Packaging et documentation (incluant le code).
. 5 : Packaging et documentation (incluant de nombreuses tables de paramètres).
* LA FACILITE D’INSTALLATION
Quelle est l’importance des manipulations de conversions et d’installation concernant la mise en place de l’application ? Existe-t-il des plans ou des outils de conversion et devront-ils être testés durant la phase de test de l’ensemble du système ?
. 0 : Aucune manipulation.
. 1 : Aucune manipulation, mais un set-up spécial est nécessaire.
. 2 : Quelques manipulations, mais avec un impact réduit. (point Neutre).
. 3 : Nombreuses manipulations, avec des conversions de données importantes.
. 4 : Nombreuses manipulations, procédures de conversion automatiques.
. 5 : Nombreuses manipulations, conversion et installation automatique.
* LA FACILITE D’EXPLOITATION
Quelle est la facilite de mise en place et d’exploitation de l’application pour l’équipe de production ? Les procédures de démarrage, sauvegarde et récupération de données sont elles fournies, et devront elles être testées durant les phases de test ? L’application minimise-t-elle les taches de production comme le montage des bandes, la manipulation de papier ou toute sorte d’intervention manuelle ?
. 0 : Aucune procédure à fournir mis à part le backup et le recovery normal.
. 3 : Analyser et construire quelques procédures d’exploitation.
. 5 : Analyser et construire de nombreuses et complexes procédures d’exploitation, avant la
mise en production.
* LE NOMBRE DE SITES DESTINATAIRES
Jusqu’à quel degré l’application est elle analysée, développée et supportée pour être installée sur plusieurs sites, dans de multiples organisations :
. 0 : Site et environnement unique
. 1 : Même environnement machine et logiciel, mais plusieurs sites
. 2 : Même environnement machine ou même environnement logiciel
. 3 : Environnements machines et logiciels différents
. 4 : implémentation d’un plan de support sur des environnements similaires
. 5 : implémentation d’un plan de support sur des environnements différents
* L’EVOLUTIVITE PREVUE
L’application doit elle être spécifiquement analysée, développée et supportée pour être par la suite facilement modifiable afin de tenir compte des nécessités d’évolution.
. 0 : Aucune contrainte particulière.
. 3 : Design spécifique des données et des traitements risquant d’évoluer.
. 5 : Utilisation lourde de tables de paramètres.
ETAPE 3 : Calcul du nombre de points de fonction nets
TFA = SOMME DES QUATORZE FACTEURS
FTA = FACTEUR TOTAL D’AJUSTEMENT
0,65 + (TFA / 100)
PFA = NOMBRE DE POINTS DE FONCTION AJUSTE
= NOMBRE DE POINTS DE FONCTION NETS
= PFB * FTA
REMARQUE : L’expérience de l’analyste peut permettre de pondérer l’influence des quatorze facteurs en les affectant d’un poids personnalisé.
ETAPE 4 : Calcul de la charge et du délai de développement
KISL = (PFA * 20) / 1000
COCOMO