Constructive Cost Model

Les complexités des applications à développer peuvent être de trois types :

• S organique (en anglais organic) : Ce sont des applications simples, n'ayant que peu de cas particuliers et de contraintes. Elles sont parfaitement déterministes.
• P semi-detaché(en anglais semidetached) : Ce sont des applications intermédiaires, plus complexes que les applications de type S, elles restent tout de même déterministes, bien que le nombre de cas particuliers et de tests doivent être plus important que pour les applications de type S
• E embarqué(en anglais embedded) : Ce sont des applications très complexes, que ce soit au niveau de leurs contraintes (comme un système temps réel) ou au niveau des données saisies (comme certaines interfaces graphiques où l'on ne peut envisager toutes les possibilités de saisies qu'un utilisateur pourrait effectuer). Elles ne sont pas déterministes.

La catégorisation d'une application dans un type de complexité reste une des choses la plus compliqué à définir dans le modèle de base de COCOMO. En cas de doute et pour ne pas avoir de surprise (comme une sous-estimation de l'effort et donc du temps de développement), il vaut mieux surestimer la complexité d'une application, sans tomber dans l'excès...

En fonction de la complexité de l'application, on utilisera différents coefficients prenant en compte les différentes complexités et forcément les efforts différents à fournir.

Formules

Complexité	Effort (en mois Homme)	Temps de développement (en mois)
S	${\displaystyle {\textit {Effort}}=2,4\times KLS^{1,05}}$	${\displaystyle TDev=2,5\times {\textit {Effort}}^{0,38}}$
P	${\displaystyle {\textit {Effort}}=3\times KLS^{1,12}}$	${\displaystyle TDev=2,5\times {\textit {Effort}}^{0,35}}$
E	${\displaystyle {\textit {Effort}}=3,6\times KLS^{1,2}}$	${\displaystyle TDev=2,5\times {\textit {Effort}}^{0,32}}$

KLS (pour Kilo Ligne Source) représente le nombre de milliers d'instructions que contiendra l'application.

Le plus complexe est de déterminer le nombre de KLS. À première vue, on peut se dire que c'est une chose impossible ou avec une très grande marge d'erreur. Cependant, pour être valable le modèle COCOMO ne doit être utilisé que lorsque la phase de conception est déjà bien avancée, de manière à avoir une idée assez précise du travail à réaliser. De plus, l'expérience de la personne utilisant le modèle est déterminante, car il sera ainsi en mesure de s'approcher au plus près du bon nombre de KLS.

Comme nous l'avons vu plus haut, la ventilation, aussi appelé distribution par phase, permet de déterminer le temps de développement et l'effort nécessaire pour chaque phase du cycle de développement. COCOMO divise en 4 grandes phases le cycle de développement :

• Expression des besoins et planification (Plans and requirements) ;
• Conception générale (Product design) ;
• Programmation (Programming) ;
  • Conception détaillée (Detailed design) ;
  • Programmation et tests unitaires (Code and unit test) ;
• Tests et intégration (Integration and test).

Selon la complexité et la taille (en KLS) de l'application, l'effort et le temps de développement varie sur chacune des phases. Le modèle COCOMO exprime cela sous la forme d'un coefficient représentant le pourcentage d'effort à réaliser et le temps passé.

Ainsi, la somme de l'effort nécessaire aux phases de conception générale, de programmation et de tests et intégration fait 100, ce qui correspond à 100 % de l'effort du développement d'une application. On remarquera que l'effort de l'expression des besoins et planification est mis à part et doit être ajouté pour avoir l'effort total.

Le modèle intermédiaire introduit des facteurs de coût supplémentaires pour affiner les résultats, tels que :

• la fiabilité requise ;
• la taille de la base de données (s'il y en a une) ;
• la complexité du produit ;
• les contraintes concernant le temps d'exécution et la taille mémoire disponible ;
• l'instabilité du logiciel de base si c'est une évolution ;
• l'expérience du personnel concernant le domaine ;
• les qualifications des développeurs ;
• la familiarité de l'équipe de développement avec logiciel de base si c'est une évolution ;
• l'expérience de l'équipe de développement concernant le langage utilisé ;
• l'utilisation de technologies ou/et méthodes récentes, l'équipe de développement manque donc d'expérience et de recul ;
• l'utilisation d'outils d'aide à la programmation (comme les générateur de code) ;
• les contraintes de délai de livraison du projet.

L'inconvénient des modèles COCOMO simplifié ou intermédiaire est qu'ils considèrent que le produit logiciel est un tout auquel ils appliquent des multiplicateurs. En réalité, les grands systèmes sont très rarement homogènes (certains peuvent être organiques, d'autres intégrés). Le COCOMO complet tient compte de cette diversité. En effet, l'évaluation de l'effort se fait de la manière suivante :

• identification des différents sous-projets relatifs à une classe ;
• calcul de l'effort simplifié pour chaque sous-projet en tenant compte de la classe à laquelle il appartient ;
• appliquer les facteurs qui influent sur chaque sous-projet et déduire l'effort intermédiaire pour chacun d'eux ;
• l'effort global sera équivalent à la somme des efforts calculés.

Cette approche permet de réduire des erreurs de l'estimation finale de l'effort.