Software Engineering: avril 2015

cocomo 2

COCOMO (acronyme de l'anglais COnstructive COst MOdel) 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.

Histoire[modifier | modifier le code]

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.

Principe[modifier | modifier le code]

COCOMO est divisé en trois modèles, qui affinent l'estimation en prenant en compte de plus en plus de paramètres :

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.

Complexité[modifier | modifier le code]

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 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.

Modèle de base[modifier | modifier le code]

**Formules**
Complexité	Effort (en mois homme)	Temps de développement (en mois)
S	${\textit {Effort}}=2,4\times KLS^{{1,05}}$	$TDev=2,5\times {\textit {Effort}}^{{0,38}}$
P	${\textit {Effort}}=3\times KLS^{{1,12}}$	$TDev=2,5\times {\textit {Effort}}^{{0,35}}$
E	${\textit {Effort}}=3,6\times KLS^{{1,2}}$	$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.

La ventilation[modifier | modifier le code]

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 et 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 a réaliser et le temps passé.

Coefficients de l'effort[modifier | modifier le code]

**Distribution par phase de l'effort**
Complexité	Phase	Taille de 2 KLS	Taille de 8 KLS	Taille de 32 KLS	Taille de 128 KLS	Taille de 512 KLS
S	Expression des besoins et planification	6	6	6	6
	Conception générale	16	16	16	16
	Programmation	68	65	62	59
	Conception détaillée	26	25	24	23
	Programmation et tests unitaires	42	40	38	36
	Tests et intégration	16	19	22	25
P	Expression des besoins et planification	7	7	7	7	7
	Conception générale	17	17	17	17	17
	Programmation	64	61	58	55	52
	Conception détaillée	27	26	25	24	23
	Programmation et tests unitaires	37	35	33	31	29
	Tests et intégration	19	22	25	28	31
E	Expression des besoins et planification	8	8	8	8	8
	Conception générale	18	18	18	18	18
	Programmation	60	57	54	51	48
	Conception détaillée	28	27	26	25	24
	Programmation et tests unitaires	32	30	28	26	24
	Tests et intégration	22	25	28	31	34

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.

Coefficients du temps de développement[modifier | modifier le code]

**Distribution par phase du temps de développement**
Complexité	Phase	Taille de 2 KLS	Taille de 8 KLS	Taille de 32 KLS	Taille de 128 KLS	Taille de 512 KLS
S	Expression des besoins et planification	10	11	12	13
	Conception générale	19	19	19	19
	Programmation	63	59	55	51
	Tests et intégration	18	22	26	30
P	Expression des besoins et planification	16	18	20	22	24
	Conception générale	24	25	26	27	28
	Programmation	56	52	48	44	40
	Tests et intégration	20	23	26	29	32
E	Expression des besoins et planification	24	28	32	36	40
	Conception générale	30	32	34	36	38
	Programmation	48	44	40	36	32
	Tests et intégration	22	24	26	28	30

Metrics

´est une mesure d'une propriété d'un morceau de logiciel ou de ses spécifications

´Une bibliothèque Java qui vous donne un aperçu sans précédent en ce que fait votre code dans la production.

´Fournit un outil puissant de façons de mesurer le comportement des composants critiques dans votre environnement de production.

´Avec des modules pour les bibliothèques communes comme Jetty , Logback , Log4j , Apache HttpClient , Ehcache , JDBI , Jersey et backends déclaré comme ganglions et Graphite , Metrics vous offre une visibilité complète

Plugin sous eclipse:

´ menu -> Install New Software (url): http://metrics2.sourceforge.net/update/

´Windows -> Show View -> Other and navigate to the Metrics View