Complément au chapitre 11: Object-Oriented Software Engineering Practical Software Development using UML and Java Complément au chapitre 11: Estimation de coûts

Effort de développement Le coût d’un logiciel est fonction de l’effort de développement: Le coût inclut: spécifications, analyse, conception,programmtion, tests, maintenance Prérequis: les trois P, Problème-Processus-Personnes Pour diminuer le coût: Améliorer l’un des trois P Ne pas écrire de code Réutiliser L’effort se mesure souvent en Personne-Mois (PM) Planification de projets © Lethbridge/Laganière 2001

Estimer l’effort de développement Une bonne estimation dépend de: Complexité du projet Taille du projet Degré de solidification des exigences Facilité de décomposition du problème Expérience passée Moment où on fait l’estimation Planification de projets © Lethbridge/Laganière 2001

À ne pas faire pour estimer le coût L’effort correspond au temps disponible pour faire le projet Le coût est juste un peu moins que celui de son concurrent Le coût correspond au prix maximum que le client est prêt à payer L’effort correspond aux ressources disponibles Planification de projets © Lethbridge/Laganière 2001

Effort versus Taille du logiciel L’effort est fonction de l’ampleur du logiciel à développer Effort = A + B * ( Taille ) C C < 1 : économie d’échelle C > 1 : coût additionnel de production Chez IBM, 1970s, 60 projets : E = 5.25 Taille ^ 0.91 A la NASA, 1980s, 18 projets : 5.5 + 0.73 Taille ^ 1.16 Planification de projets © Lethbridge/Laganière 2001

Comment estimer la taille ? FFP Fichiers , Flux de données , Processus Valide pour des projets de traitement de données de taille moyenne ( de 25 à 100 PM ) F : Nombre de fichiers (espace de stockage) permanents F : Flux de données entre l’application et l’environnement (écrans, rapports) P : Processus représentant une fonctionnalité logique ou arithmétique Taille = D * ( F + F + P ) D : constante de productivité Planification de projets © Lethbridge/Laganière 2001

Exemple: Logiciel de correction Extraction des mots, des phrases Statistiques Document Vérification de l’orthographe Identification des fautes Dictionnaire personnel Vérification grammaticale Proposition de corrections Taille = D * ( 3 + 3 + 3 ) Dictionnaire Planification de projets © Lethbridge/Laganière 2001

Comment estimer la taille ? LOC Nombre de lignes de code ( LOC ) Très représentatif de la taille du logiciel Très difficile à évaluer avant que le programme soit écrit Les LOCs ne sont pas toutes de la même complexité La complexité d’une LOC dépend du langage utilisé LOC = N1 + N2 N1 : nombre d’occurrence d’opérateurs N2 : nombre d’occurrence d’opérandes LOC = n1 log n1 + n2 log n2 n1 : nombre d’opérateurs dans le langage n2 : nombre d’opérandes distinctes Planification de projets © Lethbridge/Laganière 2001

Comment estimer la taille ? Nombre de classes Nombre total de classes = 40% * Nombre total de classes appartenant au domaine de l’application Nombre typique d’attributs par classes (3 à 5) Nombre typique de méthodes (12 à 16) Nombre de lignes par méthodes (6) Ou encore, 1 classe = 20 personne-jour Planification de projets © Lethbridge/Laganière 2001

Comment estimer la taille ? Analyse par points de fonction (FP) Les points de fonction avant ajustement se calculent en comptant: I : nombre d’entrées O : nombre de sorties E : nombre de requêtes F : nombre de fichiers T : nombre d’interfaces à d’autres systèmes Planification de projets © Lethbridge/Laganière 2001

Points de fonction non-ajustés Niveau de complexité Simple Moyenne Complexe C I 3 4 6 C O 5 7 C E C F 10 15 C T UFP = C I I + C O O + C E E + C F F + C T T ou UFP = 0.44 I + 1.67 E + 0.38 O Planification de projets © Lethbridge/Laganière 2001

Facteurs d’ajustement (degré d’influence DI) Principe: attribué entre 0 et 5 points à chacun des facteurs suivants: Le système doit-il permettre des copies de sauvegarde, du recouvrement de données? Y-a-t-il de la communication de données? Y-a-t-il des fils d’exécution concurrents? Les contraintes de performances sont-elles importantes? Le système sera-t-il utilisé dans un environnement difficile? Le système requiert-il de la cueillette de données à chaque exécution Les mises à jour des fichiers et BDs sont-elles fréquentes? Les calculs sont-ils complexes? Le code sera-t-il concu pour être réutilisables? L’installation du logiciel est-elle complexe? Les opérations de maintenances seront-elles fréqeuentes? Y-a-t-il des interfaces à d’autres systèmes? Les problèmes de sécurités sont-ils importants? La documentation requise est-elle importante? Y-aura-t-il un grand besoin de formation? Utilisera-t-on un matériel spécial? Planification de projets © Lethbridge/Laganière 2001

Facteur de complexité technique (TCF) TCF = 0.65 + E * DI où DI est la somme des points attribués aux facteurs précédents E est une constante entre 0.005 et 0.01 Planification de projets © Lethbridge/Laganière 2001

Points de fonctions ajustés (FP) FP = UFP * TCF LOC = G * FP La valeur de G dépend du langage utilisé (devrait aussi être pondérée par l’expertise de l’équipe de développement) Langage G Assembleur 320 C 128 Cobol 105 Fortran Ada 70 Java 30 Planification de projets © Lethbridge/Laganière 2001

Exemple: Logiciel de correction Extraction des mots, des phrases Statistiques Document Vérification de l’orthographe Identification des fautes Dictionnaire personnel Vérification grammaticale Proposition de corrections UFP = 2*4 + 3*5 + 1*4 + 1*10 + 2*7 = 51 Dictionnaire Planification de projets © Lethbridge/Laganière 2001

Planification de projets Matrice de coût Faire une estimation de taille séparée pour chacun des modules du système. Chaque module représente soit un problème connu (O) ou un problème nouveau (N) La réalisation de chaque module est jugée soit facile (E), moyenne (M), difficile (H) La matrice donne une cote (C) pour chaque module E = D * Σ Cmodule * LOCmodule D : constante de productivité Planification de projets © Lethbridge/Laganière 2001

Matrice de coût Wolverton (1974) OE OM OH NE NM NH Contrôle 21 27 30 33 40 49 Entrée/Sortie 17 24 28 35 43 Pré et post-traitements 16 23 26 34 42 Algorithme 15 20 22 25 Gestion des données 31 37 46 57 Contrainte temps-réel 75 Planification de projets © Lethbridge/Laganière 2001

Modèle algorithmique de Nelson (1966) Instablité dans les spécifications (0-2) Instabilité dans la conception (0-3) % d’opérations mathématiques % d’entrée et sortie Nombre de modules Utilisation d’un langage de haut niveau (oui=0 non=1) Application de type business (oui=0 non=1) Application indépendante (oui=0 non=1) 1er programme sur cette architecture (oui=1 non=0) Développement de matériel (oui=1 non=0) Utilisation d’un support de données (oui=1 non=0) Développement multi-plateforme (oui=1 non=0) Développement militaire (oui=0 non=1) E= -33.63 + 9.15x1 + 10.73x2+0.51x3+0.46x4+0.4x5+7.28x6 -21.45x7+13.5x8+12.35x9+58.82x10+30.61x11+29.55x12-25.2x13 Planification de projets © Lethbridge/Laganière 2001

Quelques principes d’estimation Décomposer le problème, estimer les coûts des sous-problèmes et les sommer pour obtenir l'estimation globale. Effectuer plusieurs estimations avec différentes méthodes. Plus grande est la similitude entre les estimés et plus grande est la confiance en ces estimés. Considérer le plus d'éventualités possibles. Réévaluer constamment les estimés au fur et à mesure de l'état d'avancement du projet. Planification de projets © Lethbridge/Laganière 2001

Estimation basée sur différentes expertises Optimiste – Réaliste – Pessimiste (OLP) Consiste à faire 3 estimés: Le cas optimiste (O): en suposant que tout ira bien. Le cas réaliste (L): le coût probable. Le cas pessimiste (P): le pire scénario. E = ( O + 4L + P ) / 6 Planification de projets © Lethbridge/Laganière 2001

COCOMO (Constructive Cost Model) 1981 Effort = B * ( kLOC ) C COCOMO élémentaire Projet organique B=2.4, C=1.05 Petite équipe Environnement connu Expérience avec ce type d’application Projet embarqué B=3.6, C=1.2 Projet complexe Contrainte sévère imposé par l’environnement Projet semi-détaché B=3.0, C=1.12 Expérience moyenne Projet de grande taille Planification de projets © Lethbridge/Laganière 2001

Planification de projets COCOMO intermédiaire Correction de l’effort par un facteur d’effort nominal multiplicatif Produit: Fiabilité requise (rely) Dimension de la base de données (data) Complexité (cplx) Environnement informatique Contrainte de temps (time) Contrainte de mémoire (stor) Volatilité de la plateforme de développement (virt) Fréquence des exigences de maintenance (turn) Personnel Expertise des analystes (acap) Expérience avec l’application (aexp) Expérience des programmeurs (pcap) Expérience avec l’environement (vexp) Expérience avec le langage (lexp) Projet Utilisation de langages évolués (modp) Utilisation d’outils avancés (tool) Horaire stricte (sch) Planification de projets © Lethbridge/Laganière 2001

Facteurs d’effort nominal TB B N E TE XE rely 0.75 0.88 1.00 1.15 1.40 1.40 data 0.94 0.94 1.00 1.08 1.16 1.16 cplx 0.70 0.85 1.00 1.15 1.30 1.65 time 1.00 1.00 1.00 1.11 1.30 1.66 stor 1.00 1.00 1.00 1.06 1.21 1.56 virt 0.87 0.87 1.00 1.15 1.30 1.30 turn 0.87 0.87 1.00 1.07 1.15 1.15 acap 1.46 1.19 1.00 0.86 0.71 0.71 aexp 1.29 1.13 1.00 0.91 0.82 0.82 pcap 1.42 1.17 1.00 0.86 0.70 0.70 vexp 1.21 1.10 1.00 0.90 0.90 0.90 lexp 1.14 1.07 1.00 0.95 0.95 0.95 modp 1.24 1.10 1.00 0.91 0.82 0.82 tool 1.24 1.10 1.00 0.91 0.83 0.83 sced 1.23 1.08 1.00 1.04 1.04 1.10 Planification de projets © Lethbridge/Laganière 2001

Effort versus nombre de personnes La productivité (LOC / PM) diminue lorsque le nombre de personne impliqué augmente. L = 777 P –0.5 (Conte 86) Le temps de développement devrait être, selon COCOMO: T = 2.5 E 0.38 Le nombre de personnes requis pour travailler sur le projet n’est pas constant dans le temps Planification de projets © Lethbridge/Laganière 2001

Modèle Putnam-Norden (1970) Planification de projets © Lethbridge/Laganière 2001

Planification du projet Le plan de travail se définit est subdivisant le projet en tâches à accomplir: Plus précisément, le projet est subdivisé en phases Les phases se décomposent an activités Chaque activité exige la réalisation de tâches Titre Date de début Date de fin Durée (idéalement de 2 à 10 semaines) Coût Ressources allouées Dépendance avec les tâches précédentes et suivantes Tous ces éléments devant être périodiquement remis à jour Planification de projets © Lethbridge/Laganière 2001

Planification de projets Les livrables La fin de chacune des tâches correspond généralement à une étape (milestone) Un document devrait être produit à chacune de ces étapes (delivrables) Concevoir un plan de travail consiste à établir la liste et la séquence des tâches à accomplir à définir les rapport d’étapes à remettre à attribuer ces tâches aux équipes disponibles et à déterminer les dates à lesquelles elles doivent débuter et se terminer. Planification de projets © Lethbridge/Laganière 2001

Planification de projets L’échéancier L’échéancier peut être représenté à l’aide de: Un diagramme de Gantt Associant une ligne temporelle pour chacune des tâches à accomplir Un diagramme de PERT où chaque tâche est un nœud dans un graphe Planification de projets © Lethbridge/Laganière 2001

Diagramme de PERT (Program Evaluation and Review Technique) Chacune des tâches est un noeud dans un graphe Le graphe montre explicitement la dépendance entre tâche Le chemin critique indique la durée minimale requise pour complèter le projet. le plus long chemin dans le graphe Les tâches ne faisant pas partie de ce chemin critique peuvent être déplacées (à l’intérieur d’une certaine fenêtre de temps) sans affecter l’échéancier Planification de projets © Lethbridge/Laganière 2001

Planification de projets Diagramme de PERT Planification de projets © Lethbridge/Laganière 2001

Planification de projets Exemple Tâche Durée Dépendances T1 8 T2 15 T3 T4 10 T5 T2, T4 T6 5 T1, T2 T7 20 T8 25 T9 T3, T6 T10 T5, T7 T11 7 T12 Planification de projets © Lethbridge/Laganière 2001

Planification de projets Diagrammes de Gantt Le diagramme montre explicitement les dates de début et de fin pour chacune des tâche L’axe horizontal montre le temps, l’axe vertical montre les activités. Les barres noires représentent les activités. Les barres blanches représentent les tâches. Les symboles en diamants représentent les dates où un document est dû. Planification de projets © Lethbridge/Laganière 2001

Planification de projets Diagramme de Gantt Planification de projets © Lethbridge/Laganière 2001

Gain de projet (earned value) Un gain de projet correspond à la quantité de travail complété telle que mesuré à l’aide l’effort budgeté. It is also called the budgeted cost of work performed. As each task is completed, the number of person-months originally planned for that task is added to the earned value of the project. Planification de projets © Lethbridge/Laganière 2001

Diagramme de gain en coût budgété (earned value chart) Un gain de projet correspond à la quantité de travail complété telle que mesuré à l’aide l’effort budgeté. Un diagramme de gain en coût budgété (PM vs temps) comporte 3 courbes: Le coût budgété du projet en fonction de l’échéancier. Le coût réel courant du projet Le coût budgété de la portion réalisée du projet Planification de projets © Lethbridge/Laganière 2001

Diagramme de gain (earned value chart) Budgeted Actual Earned Planned Actual cost of cost of value elapsed elapsed 40 work work scheduled performed time time Actual effort 35 Budgeted effort 30 25 Le projet a 6 semaines de retard à la semaine 23 Effort (person- months) 20 15 Le projet est 2 PM en surcoût à la semaine 23 10 5 4 8 12 16 20 24 28 32 36 40 Elapsed time (weeks) Planification de projets © Lethbridge/Laganière 2001