MESURE & ESTIMATION DES PROJETS LOGICIELS

Transcription

1 C E N T R E D E MAITRISE DES SYSTEMES ET DU LOGICIEL MESURE & ESTIMATION DES PROJETS LOGICIELS INTRODUCTION N.Trèves / CNAM - CMSL / Mesure & estimation des projets logiciels / Vers. 1.0 Page 1

2 La réalité des projets informatiques Selon l étude du Standish group (2003) : «Chaos, charting the seas of information technology» 34% des projets sont conformes à leurs objectifs (16,2% en 1994) 51% connaissent des surcoûts (52,7% en 1994) < 20% dans 23% des cas Moyenne = 43% de la dépense (en %, fonctionnalités complètes à seulement 61% des projets) 15% sont abandonnés (31,1% en 1994)!!! Enquête menée aux US concernant environ 500 entreprises, projets Du progrès, mais ce n est pas encore cela N.Trèves / CNAM - CMSL / Mesure & estimation des projets logiciels / Vers. 1.0 Page 2

3 Pourquoi ce constat? Du point de vue de la MOA Incapacité à sélectionner le maître d œuvre qui saura réaliser le système souhaité, aux conditions économiques de coût, qualité, fonctionnalité et délai Du point de vue de la MOE Incapacité à faire un devis réaliste des travaux à réaliser selon les conditions fixées par la MOA Incapacité à diriger la réalisation selon les termes du contrat Difficultés de gestion de la productivité des équipes Incapacité à maîtriser la complexité Incapacité a dialoguer avec le MOA Pour expliquer que le système commandé est infaisable aux conditions fixées par le contrat Pour expliquer que l expression de besoin est trop instable ou économiquement mal fondée pour développer quoi que ce soit de solide N.Trèves / CNAM - CMSL / Mesure & estimation des projets logiciels / Vers. 1.0 Page 3

4 L explication : les dérives possibles Production (Selon le type de tâche) Trajectoire initiale estimée Trajectoire réelle observée 1er cas Dérive constante : T / T = K 0 Problème de productivité Écart en production 2ème cas Dérive croissante : T / T = K 1 + K 2 Problème de complexité non maîtrisée (Il s agit en fait d une courbe en S ; l accélération de la dérive fait que la production stagne sur l asymptote de la courbe, le projet ne progresse plus). T A T A T B Temps normalisé (analogue à un effort) Retard calendaire Accélération de la dérive N.Trèves / CNAM - CMSL / Mesure & estimation des projets logiciels / Vers. 1.0 Page 4

5 Définition d un projet informatique Suite d'actions, que l'on se propose d'accomplir, organisées selon un ordre partiel, ayant pour but la réalisation d'un logiciel PERTURBATIONS PROJET INFORMATIQUE Cahier des charges du futur utilisateur: Expression de besoin (EB) Exigences comportementales (EC) ENTRÉE RESSOURCES COUT DELAI Méthodes et savoir-faire du réalisateur Logiciel opérationnel Conforme à l EB/EC SORTIE PROCESSUS DE DEVELOPPEMENT N.Trèves / CNAM - CMSL / Mesure & estimation des projets logiciels / Vers. 1.0 Page 5

6 Les différents aspects d un projet Axes principaux Aspect produit Aspect acteurs & organisation Aspect processus Aspect cohérence globale du projet Sont au cœur de l interaction : processus produit Aspect qualité (ISO 9126) Aspect coût Aspect délai Maximiser Minimiser Il faut assurer la cohérence globale des différents aspects des projets qui contribuent à l acquisition d un système informatique N.Trèves / CNAM - CMSL / Mesure & estimation des projets logiciels / Vers. 1.0 Page 6

7 Les fonctions et le processus de la gestion de projet STRUCTURATION ESTIMATION ORGANISATION PLANIFICATION ORDONNANCEMENT SUIVI SUIVI ÉNUMÉRER TOUS LES TRAVAUX À FAIRE AUSSI PRÉCISEMMENT QUE POSSIBLE DÉTERMINER À L'AVANCE LES QUANTITÉS / QUALITÉS DE RESSOURCES NÉCESSAIRES AUX DIFFÉRENTES TÂCHES AFFECTER LES RESSOURCES RÉELLES, DÉFINIR LES RESPONSABILITÉS, RÉPERTORIER LES CONTRAINTES D'EXÉCUTION LIÉES À L'ENVIRONNEMENT DÉTERMINER LES DATES CLEFS VIS À VIS DU MOA ET DU MOE; ANALYSE ET IDENTIFICATION DES RISQUES DÉFINIR L'ENCHAÎNEMENT DANS LE TEMPS DE TOUTES LES TÂCHES, LA SYNCHRONISATION, L'AFFECTATION FINE DES RESSOURCES, LES PRIORITÉS MESURER ET CONTRÔLER RÉGULIÈREMENT L'AVANCEMENT RÉEL PAR RAPPORT AUX PRÉVISIONS; RENDRE COMPTE N.Trèves / CNAM - CMSL / Mesure & estimation des projets logiciels / Vers. 1.0 Page 7

8 Pourquoi estimer les projets? Comparer en permanence les prévisions à la réalité ; Estimer les dérives Visualisation de l état du projet Réaction (complet) Tableau de bord Interprétation Action (consistant, fidèle) Observations Situation du projet à l instant t N.Trèves / CNAM - CMSL / Mesure & estimation des projets logiciels / Vers. 1.0 Page 8

9 Les étapes de l'estimation EXPRESSION DE BESOIN 1ÈRE 1ÈRE ESTIMATION (GROSSIÈRE) (GROSSIÈRE) Délai généralement très court (quelques semaines) entre la remise du cahier des charges et le devis initial, même pour de très gros projets. DEVIS INITIAL ÉTUDE FONCTIONNELLE PRÉ-ÉTUDE TECHNIQUE TUDE TECHNIQUE COMPLÈTE ESTIMATION FINALE (TRÈS (TRÈS PRÉCISE) PRÉCISE) RÉ-ESTIMATION (MOINS (MOINS GROSSIÈRE) GROSSIÈRE) Délai et charge de travail pouvant représenter 5 à 10% de la réalisation pour de très gros projets. Réalisation de maquettes et de prototypes. RÉALISATION SUIVI DE LA RÉALISATION N.Trèves / CNAM - CMSL / Mesure & estimation des projets logiciels / Vers. 1.0 Page 9

10 Les conditions préalables de l estimation Le périmètre et les frontières du projet sont connus Nomenclature des processus qui font l objet de l estimation Le processus de développement est défini Emploi intelligent des normes internationales : IEEE 1220 : le processus système global ISO : le processus de développement logiciel ISO 9126 : les caractéristiques qualité produit ISO SPICE : la maturité des organisations Choisir quelques métriques incontestables Volume de programmation ; Comptage des points de fonctions Volume et nombre de tests ; nombre de défauts découverts Taux de retouches et maturité des référentiels N.Trèves / CNAM - CMSL / Mesure & estimation des projets logiciels / Vers. 1.0 Page 10

11 À partir de quoi fait-on une estimation : les 4 grandeurs caractéristiques C Q F D Perturbations «Usine» logicielle F, Q F : fonctionnalités en tant que besoin Q : qualité de service (QOS) en tant qu exigences Processus de de développement Ressources C sur une durée D F', Q' F' : fonctions livrées en langage informatique (+ documentation et tests) Q' : qualité de service (QOS) effectivement mesurée (Disponibilité, courbe de maturité, taux de défauts) {savoir-faire, expérience de l équipe, management et organisation} N.Trèves / CNAM - CMSL / Mesure & estimation des projets logiciels / Vers. 1.0 Page 11

12 Les grandeurs fondamentales CQFD Coût Qualité Délai Fonctionnalité Fixé par le client dès le début. Le coût détermine l effort jugé nécessaire pour réaliser le logiciel ; s exprime en homme an ou en homme mois. Le paramètre coût peut être imposé par le MOA Dépend des actions du chef de projet MOE, et en particulier de l'effort de vérification, validation et test (VVT); en théorie, elle est fixée dès que le plan qualité est approuvé, généralement en début de projet (Cf. norme ISO/CEI 9126). Il est particulièrement malvenu et maladroit de réviser la qualité à la baisse en cas de retard! La VVT est fonction de ce qui est réellement exécuté par la plateforme (i.e. les instructions écrites+celles générées). Fixé par le client qui en général synchronise le travail avec d'autres projets ; le délai peut varier en cours de projet. Pour tout projet il existe un délai optimum «temps de cuisson». Caractérise le service rendu (i.e. fonctions offertes) proposé par le maître d œuvre à son client ; les fonctionnalités peuvent souvent être négociées en contre partie du coût et du délai ; s expriment en nombre de points de fonctions (PF) ou en nombre de milliers de lignes source (KLS). On ne compte que ce qui est réellement écrit par les programmeurs. N.Trèves / CNAM - CMSL / Mesure & estimation des projets logiciels / Vers. 1.0 Page 12

13 Espace méthodologique de la gestion de projet logiciel 6 caractéristiques principales FURPSE + Caractéristiques éventuelles de l environnement système Axe arbre produit et caractéristiques qualité produit EB/EC (Cf. ISO/CEI 9126) Axe méthodes d estimation (acteurs et organisation) Axe méthodologies cycle système et cycle de développement (Cf. ISO/CEI 12207) Chaque phase a des besoins et des exigences qui lui sont propres en terme CQFD et risques Espace de possibilités de choix très grand donc risque d inconsistance et d incomplétude si la maturité du chef de projet est faible N.Trèves / CNAM - CMSL / Mesure & estimation des projets logiciels / Vers. 1.0 Page 13

14 Les paramètres de l estimation Cycle de vie système/logiciel Architecture produit/système Modèle d estimation C/ effort Q/ mesurée F/ livrées D/ réactivité Connaissance des scénarios d emploi, flux d information complexité Stratégie VV&T Contrat de service, Coût/efficacité de l intégration Maturité : Système cible besoins stabilisés, Environnement système maturité des technologies, Équipes de développement maturité des acteurs, courbes d expérience. Analyse des risques N.Trèves / CNAM - CMSL / Mesure & estimation des projets logiciels / Vers. 1.0 Page 14

15 Un exemple de paramétrage : facteurs de coût du modèle COCOMO Niveaux Facteurs de Coûts Très bas Bas Nominal Élevé Très élevé Extrêmement élevé Attributs du produit (Complexité de l application et/ou du produit à réaliser RELY Contraintes de fiabilité du logiciel DATA Taille de la base de donnée CPLX Complexité de l application Attributs du matériel (Qualité de service du centre de calcul et de l ordinateur cible) TIME Contraintes de la durée d exécution sur le temps machine STOR Contraintes d occupation mémoire VIRT Stabilité de la machine virtuelle TURN Durée d exécution Attributs du personnel (Expérience et/ou maturité des programmeurs, individuellement et collectivement) ACAP Maturité des architectes AEXP Expérience du domaine applicatif PCAP Maturité des programmeurs VEXP Expérience d utilisation de l environnement d exploitation LEXP Pratique des langages de programmation utilisés Attributs du projet (Processus et/ou méthodes de développement adoptés par le projet) MODP utilisation des pratiques modernes de programmation TOOL Utilisation d outils logiciels SCED Mise en place d un planning de réalisation N.Trèves / CNAM - CMSL / Mesure & estimation des projets logiciels / Vers. 1.0 Page 15

16 Difficultés et limites de l estimation Expliciter très clairement la métrologie Volume de programmation, fonctionnalités livrées Ex: COCOMO, nombre de lignes de code Lissage des paramètres concernant le style de programmation Ex: modèle des points de fonctions Expliciter les hypothèses concernant la valeur des paramètres (complexité, facteurs de risque, incertitudes) Séparer clairement le subjectif et le qualitatif, du quantitatif Faire très attention aux facteurs organisationnel (MOA, MOE, Sous-traitants, etc.) Révision des hypothèses dans un cadre de suivi de projet (gestion des risques) Arbre de dépendance classique avec les méthodes d analyse des données La pratique reproductible du paramétrage requiert une véritable expertise en management de projet logiciel N.Trèves / CNAM - CMSL / Mesure & estimation des projets logiciels / Vers. 1.0 Page 16

17 Estimation et maturité logicielle Sur la base du modèle de maturité CMM à 5 niveaux : Au niveau 2 (le processus de développement est défini) : on doit maîtriser les bases de la gestion de projet Modèle CQFD Au niveau 3 et au delà (le processus de développement est reproductible et instrumenté) : on doit maîtriser tous les aspects de l estimation Requiert, au minimum, 5 ans d expérience et la réalisation effective de plusieurs projets de complexité variée N.Trèves / CNAM - CMSL / Mesure & estimation des projets logiciels / Vers. 1.0 Page 17