Cet article propose de remettre au goût du jour, via un outil simple d’utilisation, les modèles d’estimation de charges proposés par Barry Boehm (Constructive Cost Model ou COCOMO) en 1981 et Alan Albrecht (Points de fonction) en 1979.
Je sais que cela ne nous rajeunit pas, mais ces modèles mathématiques gardent tout leur intérêt dans l’estimation de projets logiciels, Agiles ou non.
Ayant eu l’opportunité de travailler sur un outil commandé par Computer Associates au MIT en 1991, qui mettait en oeuvre ces deux techniques, je me suis intéressé de près à ces modèles, ainsi qu’au lien que l’on pouvait faire entre les points de fonction et CoCoMo.
L’outil de Computer Associates proposait déjà des critères quantitatifs de plus haut niveau que ceux utilisés par les points de fonction et CoCoMo, critères que l’on retrouve dans le diagramme de contexte des projets / produits, en fin de cadrage.
Après une première version sur Multiplan, j’ai rapidement adapté mon premier outil à Excel, et l’ai fait évolué au grès des nouveaux outils et méthodes de développement, tout en le testant sur de nombreux projets de taille respectable.
L’outil Excel, dont vous trouverez le lien ci-dessous, propose cette évaluation de fin de cadrage (Agile ou pas), et peut être fort utile comme base ou complément de vos outils d’estimation habituels :
Les points forts des formules de Barry Boehm : Elles prennent en compte les effets d’échelle, et permettent de calculer la taille des équipes en fonction des contraintes de délai qui vous sont imposées (entre les deux bornes qui vous sont indiquées dans l’outil) : Plus on rajoute de monde plus il faut de coordination.
Remarque : Cet outil est efficace pour les projets au dessus de 300 jours hommes
Passons maintenant aux concepts utilisés, et à la granularité des éléments quantitatifs à saisir.
Le Diagramme de Contexte d’un projet / d’une application
Le diagramme de contexte est une représentation graphique de la relation entre le domaine applicatif analysé et le monde extérieur.
C’est un diagramme de niveau 0, employé pour déterminer les interfaces à niveau élevé. La phase d’analyse détaillée utilisera le diagramme de contexte comme base pour décomposer les fonctionnalités et les flux.
Le diagramme de contexte est co-construit avec le métier et est une représentation valide du projet vu de l’utilisateur.
Les acteurs y sont précisés de façon exhaustive. Un acteur ne fait pas partie du projet en ce sens que l’on ne modélise pas ses tâches, mais il échange des informations avec les applications et produits modifiés par le projet / release. On indiquera (dans le descriptif de l’acteur) quelles sont les responsabilités de ce persona par rapport aux différents processus / tâches mis en œuvre.
Remarque : Le diagramme de contexte d’une application reflète exactement sa cartographie applicative, au sens Archimate (à contrario de sa cartographie fonctionnelle et de sa cartographie technique).
Estimation par le diagramme de contexte : Principes de fonctionnement
Saisie des éléments quantitatifs et des facteurs correctifs
Quantification du diagramme de contexte
Nombre de flux entrants créés ou modifiés par le Projet / la Release :
- Combien de groupes d’informations en entrée, uniques et logiques, le système aura-t-il à traiter ?
- Il s’agit de compter le nombre de types d’information principaux venant de l’extérieur qui rentreront dans le système.
- Les informations venant des bases de données internes sont donc exclues de ce total.
- Il faut penser en termes de transactions principales, de communications nécessaires à l’activité du domaine étudié.
- Une unité d’information en entrée est considérée comme unique quand elle nécessite une logique de traitement différente de celle des autres unités d’information.
- La complexité d’un flux dépend de la taille du sous-modèle de données qu’il transporte et des règles liées au traitement de ce flux.
Exemple :
Nombre de flux sortants créés ou modifiés par le Projet / la Release :
- Combien de documents (documents papier, fichiers, tables, emails pour l’extérieur) le système devra-t-il générer en sortie ?
- Ne prendre en compte que les flux majeurs et non les flux mineurs qui en sont dérivés.
- Une unité d’information en sortie est considérée comme unique quand elle nécessite une logique de traitement différente de celle des autres unités d’information.
- La complexité d’un flux dépend de la taille du sous-modèle de données qu’il transporte et des règles liées au traitement de ce flux.
Macro Entités créées ou modifiées par le Projet / la Release:
- On regroupe les entités suivant leurs buts de gestion.
- On obtiendra par exemple : commande = en-tête commande + ligne commande.
- Par exemple, si une macro entité regroupe moins de 3 «tables» la macro entité est simple, de 3 à 5 sa complexité est moyenne, au delà sa complexité est forte
Exemple :
Autres Services IT, Produits et Apps créés ou modifiés par le Projet / la Release :
- Web App, ou Mobile app
- Serveur application (ESB, APIs)
- Application monolithique
- ERP
- Editique
- Autre service IT référencé au sein de votre CMDB
- …
Cas d’usage reposant sur une expérience utilisateur, créés ou modifiés par le Projet / la Release
- Parcours utilisateur au sein d’une App, Web App, client lourd, mainframe, …
- Enchainement d’écrans pour réaliser une transaction métier
- …
Répartition des éléments quantitatifs par complexité
Simple
Moyen
Le modèle de données induit / porté par l’élément, comporte 3 à 5 entités ayant chacune environ 15 attributs et 3 relations vers d’autres entités. Les règles de gestion appliquées à ces entités sont moins triviales, et peuvent poser des problèmes de temps de réponse par exemple.
Complexe
Le modèle de données induit / porté par l’élément, comporte de nombreuses entités dont certaines ont un grand nombre d’attributs. On y trouve quelques relations multiples et les règles qui régissent le modèle sont complexes.
Appliquer une contrainte de délai
Voici enfin comment appliquer une contrainte de délai sur votre projet / release et voir l’impact de cette contrainte sur le staffing nécessaire :
Points de fonction et KPIs
Le nombre de points de fonction, peut également servir à mesurer des indicateurs de suivi de la qualité et de la vélocité.
En effet le nombre de points de fonction est un nombre sans dimension représentant le ‘poids’ du projet indépendamment de la manière dont celui-ci va être réalisé :
Pour aller plus loin : Voir ce qu’il y a sous le capot : Théorie et formules