Estimation et planification logicielles

L'estimation et la planification logicielles prévoient l'effort, le coût, le calendrier et les ressources qu'un projet logiciel nécessitera, et organisent le travail pour le livrer dans le respect de ces contraintes.

Definition

L'estimation logicielle est la prédiction de l'effort, de la durée et du coût nécessaires au développement ou à la maintenance d'un logiciel, et la planification est l'organisation des activités, des jalons et des ressources pour atteindre les objectifs du projet dans le cadre de ces estimations.

Scope

Ce sujet aborde les mesures de taille telles que les lignes de code et les points de fonction ; les modèles de coût algorithmiques comme COCOMO ; l'estimation par jugement d'experts, par analogie et par planning poker ; les techniques de décomposition du travail et de planification incluant le chemin critique et le burndown ; la planification agile avec la vélocité et les points d'histoire (story points) ; et le traitement de l'incertitude d'estimation par des fourchettes et le cône d'incertitude.

Core questions

• Comment la taille d'un logiciel est-elle mesurée pour étayer les estimations ?
• Comment se comparent les méthodes algorithmiques, par analogie et par jugement d'experts ?
• Comment l'incertitude est-elle représentée et réduite à mesure qu'un projet progresse ?
• En quoi la planification agile avec la vélocité diffère-t-elle de la planification initiale (up-front scheduling) ?

Key theories

Modèles de coût algorithmiques

Des modèles tels que COCOMO expriment l'effort et le calendrier comme des fonctions calibrées de la taille estimée et des facteurs de coût du projet, fournissant des estimations reproductibles qui peuvent être ajustées avec des données historiques.

Dimensionnement par points de fonction

L'analyse des points de fonction dimensionne un logiciel en comptant et en pondérant ses composants fonctionnels indépendamment du langage d'implémentation, fournissant ainsi une entrée de taille neutre vis-à-vis de la technologie pour l'estimation.

Clinical relevance

Une estimation et une planification réalistes sont à la base des engagements envers les parties prenantes et des décisions concernant les ressources ; la sous-estimation chronique entraîne les dépassements de calendrier et de budget qui affligent les projets logiciels, de sorte que des méthodes disciplinées et une gestion explicite de l'incertitude sont essentielles.

Evidence & guidelines

La recherche empirique sur la précision de l'estimation et les modèles tels que COCOMO II fournissent des orientations fondées sur des preuves, et le comptage des points de fonction est régi par les normes de mesure de la taille fonctionnelle IFPUG et ISO/IEC.

History

Les points de fonction ont été introduits par Albrecht à la fin des années 1970 et COCOMO par Boehm en 1981, conférant à l'estimation une base quantitative ; les travaux ultérieurs ont affiné les modèles (COCOMO II), étudié les biais d'estimation et introduit des méthodes légères de dimensionnement relatif pour la planification agile.

Debates

L'estimation versus le mouvement « no-estimates »

Certains praticiens agiles soutiennent qu'une estimation détaillée gaspille des efforts et qu'une livraison petite et constante rend les prévisions plus fiables que les estimations, tandis que d'autres maintiennent que les estimations restent nécessaires pour la planification et les engagements ; le débat dépend du contexte et des besoins des parties prenantes.

Key figures

• Barry Boehm
• Allan Albrecht
• Steve McConnell

Seminal works

• boehm1981
• albrecht1983
• mcconnell2006

Frequently asked questions

Pourquoi les estimations logicielles sont-elles si souvent erronées ?

Les estimations sont réalisées lorsque l'on dispose du moins d'informations, les exigences évoluent, et le biais humain tend vers l'optimisme ; le cône d'incertitude illustre l'ampleur inévitable des premières estimations, c'est pourquoi les fourchettes et la ré-estimation sont préférées aux chiffres fixes uniques.

Les points d'histoire (story points) sont-ils simplement des heures déguisées ?

Non. Les points d'histoire expriment la taille et la complexité relatives plutôt que le temps absolu ; combinés à la vélocité observée d'une équipe, ils permettent d'établir des prévisions, mais assimiler un point à un nombre fixe d'heures compromet leur objectif de saisir l'effort relatif.