GEF492 - PPL09 Estimation de projets logiciels Automne 2013 L’estimation de projets du logiciel GEF492A 2014 Référence: [HvV §7.1.1 - .3, 7.2] Quelle est la grosseur du logiciel? Combien ça coûte? Combien ça vaut? Combien de temps ça prend? Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et génie informatique Vincent.roberge@rmc.ca roberge.segfaults.net PPL09-EstimationLogicielle.pdf Sylvain P. Leblanc

Méthodes d’estimation GEF492 - PPL09 Estimation de projets logiciels Automne 2013 Méthodes d’estimation La méthode de Parkinson* Estimez pour gagner le contrat (Price to Win)* Le jugement d’expert estimé venant d'expérience l’analogie la méthode "Wideband Delphi" Les modèles algorithmiques Techniques de haut en bas de bas en haut * pas recommandé Automne 2014 GEF492 Sylvain P. Leblanc

La méthode de Parkinson GEF492 - PPL09 Estimation de projets logiciels Automne 2013 La méthode de Parkinson La loi de Parkinson: «Le travail s’accroît pour remplir tout le temps disponible.» Exemple: Il faut qu’on finisse en 18 mois, et il y a 10 développeurs disponibles, la tâche prendra donc 180 mois-développeur. Faiblesses énormément inexacte fonctionne seulement s’il y a beaucoup de marge (temps et argent) pour ajouter de la fonctionnalité peu utile renforce les mauvaises pratiques d’élaboration logicielle Automne 2014 GEF492 Sylvain P. Leblanc

Estimation pour gagner le contrat (Price-to-Win) On estime le prix et le plan qui, selon notre opinion, gagneront le contrat Populaire parce que les gestionnaires ne comprennent pas, ou n'ont pas confiance, aux techniques d'estimation légitimes. Faiblesse motivé par les facteurs politiques mène habituellement au désastre complet Le plus bas soumissionnaire conforme! Automne 2014 GEF492

Le jugement d’expert On demande conseil à expert(s) Avantages l’expert est capable de considérer les différences entre projets l’expert peut considérer les situations exceptionnelles Faiblesses l'estimé ne peut être meilleur que l’expert l’expert à peut-être ses propres motivations demande de l’expérience qu’est-ce qu’on peut faire pour estimer le premier projet? Automne 2014 GEF492

L’estimation basée sur l’expérience une méthode empirique grandeur = meilleur estimation personnelle * 20 nombres d’années d’expérience sur les projets semblables = WAG («wild ass guess») Automne 2014 GEF492

L’estimation par analogie On raisonne par analogie avec des projets similaires qu’on a déjà complétés, en examinant leurs coûts et autres caractéristiques On essaie de quantifier les différences entre le projet à l'étude et les projets précédents. Avantages l’estimation est basée sur l’expérience réelle on peut faire analogies au niveau du système ou au niveau plus détaillé Faiblesse pas toujours clair si le projet à l'étude est vraiment similaire aux projets précédents limitations, techniques, effectifs, etc. Automne 2014 GEF492

Wideband Delphi (1/2) (une technique de consensus du group) Étape 1 – On débute avec les besoins de fonctionnalité et de qualité bien établis Étape 2 – On crée un design raisonnable où chaque composante est assez bien définie pour être comprise Étape 3 - Chaque participant produit une estimation de la grandeur pour chaque composante, et les donnes à un modérateur Étape 4 - Pour chaque composante, le modérateur crée un graphique comme celui-ci: 1000 2000 grandeur de composante 7, en ligne de code, série 1 Automne 2014 GEF492

grandeur de composant 7, en ligne de code, série 1 Wideband Delphi (2/2) Étape 5 - Sans discuter des valeurs de leurs propres estimations, chaque participant explique leur logique Étape 6 - On refait les étapes 3 à 5 jusqu’à les estimations convergent L’expérience dit que: les estimations convergent la valeur à laquelle les estimations convergent représente typiquement une meilleure estimation que la moyenne des estimations des premières séries, et elle est plus précise que les meilleures estimations des meilleurs participants 1000 2000 grandeur de composant 7, en ligne de code, série 1 Automne 2014 GEF492

Les modèles algorithmiques Les modèles algorithmiques nous donnent des algorithmes mathématiques qui produisent une estimation comme fonction des paramètres considérée comme inducteur du coût important (x1, x2,... xn) Inducteurs du coût possibles: lignes de code capacité des programmeurs contrainte de temps contrainte sur le montant de mémoire utilisé, etc. Automne 2014 GEF492

Les modèles algorithmiques Avantages objectif les motivations personnelles ne peuvent pas influencer les estimations on peut les répéter avec les mêmes résultats on peut conduire une analyse de sensibilité Faiblesses doit être calibré est-ce que le projet à l'étude est similaires aux données de l'algorithme difficile a tenir compte des circonstances exceptionnelles personnel, teamwork.... Après toutes ces années, il manque toujours de données quantitatives Automne 2014 GEF492

Techniques d'estimation Peut importe la méthode qu'on choisit, on doit décider si on veut commencer en considérant les caractéristiques du système en entier, ou celles des composantes de bas niveau. On considère deux techniques: L'estimation de haut en bas L'estimation de bas en haut Automne 2014 GEF492

L’estimation de haut en bas On crée une estimation en considérant les propriétés globales du système Avantages on pense au système en son entier basée sur l’expérience avec projets similaires on considère les coûts d’intégration, de documentation, de gestion de la configuration, etc. Faiblesses ne tient pas compte des problèmes importants de niveau bas On peut oublier des composantes la méthode ne donne pas une justification détaillée de l’estimation Automne 2014 GEF492

L’estimation de bas en haut Le coût de chaque composante logicielle est estimé par un individu; les coûts sont ensuite additionnés pour trouver le coût total Peut utiliser la structure de répartition du travail Système Sous-système Mod. Automne 2014 GEF492

L'estimation de bas en haut Avantages Arrive à une appréciation des problèmes techniques concrets plus rapidement Les estimations de composantes sont justifiées par l'engagement des individus responsables de l'achèvement du travail Justification détaillée des coûts (bien que d'autres techniques d'analyse sont toujours possibles) Désavantages Tendance à ne pas capturer les coûts de système Ceux-ci doivent être inclus dans la SRT pour être capturés Il est difficile d'estimer les coûts de haut niveau du système avant d'estimer le coût des composantes Il est difficile de modaliser les activités reliées au projet Lecture, révision, réunions, réparation, etc. Il est difficile de modaliser les activités de non-reliées au projet Entraînement, administration personnelle, communication hors projet, etc. Automne 2014 GEF492

Comment est-ce qu’on peut mesurer le code? Considérons les lignes de code (LDC) comme mesure Productivité: "Le nombre d’articles produit par unité de travail ou de dépense" Est-ce que l’utilisation d’un langage de programmation de niveau plus élevé augmente la productivité? Automne 2014 GEF492

Références supplémentaires Boehm, W.B., The Art of Software Estimation, Prentice-Hall, 1981 University of West Florida, Generic Delphi Estimation Process, http://www.cs.uwf.edu/~wilde/gump/delphi.htm Automne 2014 GEF492

Prochaine séance: L’estimation de la grandeur par l'analyse de points de fonction Automne 2014 GEF492