3.4. Coût du logiciel
Pour déterminer le coût du logiciel, il existe
beaucoup des méthodes que les concepteurs ou les informaticiens se
servent. Nous avons jugés bon d'utiliser la méthode
COCOMO (acronyme de l'anglais COnstructive COst
MOdel) qui est un modèle permettant de définir une
estimation de l'effort à fournir dans un développement logiciel
et la durée que ce dernier prendra en fonction des ressources
allouées. Le résultat de ce modèle n'est qu'une
estimation, il n'est en rien infaillible et parfaitement exact.
Ce modèle, Conçu en 1981 par Barry Boehm, COCOMO
est une méthode basée sur les résultats de 63 projets de
développements informatiques (allant de 2 000 à 100 000 lignes de
code). Elle se base donc sur des statistiques. Aujourd'hui, il existe
également le modèle COCOMO II, plus adapté à
l'aspect réutilisation des composants. [WIK 2016]
COCOMO est divisé en trois modèles, qui affinent
l'estimation en prenant en compte de plus en plus de paramètres :
3.4.1. Principe du modèle
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.
Page | 53
· le modèle de base effectue un simple
calcul de l'effort et de la durée en fonction du nombre d'instructions
que l'application doit contenir et la complexité de cette
dernière. Une ventilation est également possible, permettant de
déterminer le temps de développement et l'effort
nécessaire pour chaque partie du cycle de développement.
· le modèle intermédiaire reprend
l'effort et la durée du modèle de base, en appliquant cette
fois-ci des coefficients prenant en compte des facteurs de coût
(compétence de l'équipe, complexité de l'environnement
technique, etc.).
· le modèle détaillé
reprend les données du modèle intermédiaire en
affinant notamment les facteurs de coût en fonction de chaque phase du
cycle de développement. Ce modèle n'est véritablement
nécessaire que pour de très gros projets.
3.4.2. Complexité du modèle
Les complexités des applications à
développer peuvent être de trois types :
· S (en anglais organic) : Ce sont des
applications simples, n'ayant que peu de cas particuliers et de contraintes.
Elles sont parfaitement déterministes.
· P (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 (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 les plus compliquées à
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.
Page | 54
Formules
Complexité Effort (en mois homme) Temps de
développement (en mois)
S
P
E
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. [WIK 2016]
| 
