©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 1 CQFD des Systèmes Informatisés Les Modèles d’estimation.

Présentation au sujet: "©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 1 CQFD des Systèmes Informatisés Les Modèles d’estimation."— Transcription de la présentation:

1 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 1 CQFD des Systèmes Informatisés Les Modèles d’estimation Principes et méthodes

2 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 2 Plan  Généralités  Métrologie des projets informatiques  Analyse du référentiel de l’estimation  1.Cycle de vie – 2.Architecture – 3.Stratégie de test – 4.Maturité – 5.Construction progressive de l’estimation  Analyse de la productivité  1.Qq. Lois d’échelle du développement – 2.La Maintenance  Méthodes de comptage  Forme des équations

3 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 3 Généralités Métrologie des projets informatiques

4 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 4 Les différents aspects d’un projet Il faut assurer la cohérence globale des différents aspects des projets qui contribuent à l’acquisition d’un système informatique Aspect acteurs & organisation Sont au cœur de l’interaction : processus  produit Aspect produitAspect processus Aspect cohérence globale du projet Aspect qualité (ISO 9126) Aspect coûtAspect délai Axes principaux Maximiser Minimiser Caractéristiques FURPSE

5 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 5 Les fonctions et le processus de la gestion de projet STRUCTURATION ORDONNANCEMENT ESTIMATION ORGANISATION PLANIFICATION 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 MO ET DU MOI; 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

6 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 6 Les étapes de l'estimation EXPRESSION DE BESOIN 1ÈRE ESTIMATION (GROSSIÈRE) 1ÈRE ESTIMATION (GROSSIÈRE) DEVIS INITIAL ÉTUDE FONCTIONNELLE PRÉ-ÉTUDE TECHNIQUE ÉTUDE TECHNIQUE COMPLÈTE ESTIMATION FINALE (PRÉCISE) ESTIMATION FINALE (PRÉCISE) RÉALISATION RÉ-ESTIMATION (MOINS GROSSIÈRE) RÉ-ESTIMATION (MOINS GROSSIÈRE) Délai généralement très court (qq. semaines) entre la remise du cahier des charges et le devis initial, même pour de très gros projets. SUIVI DE LA RÉALISATION 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/ou de prototypes

7 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 7 Pourquoi estimer les projets ?  Comparer en permanence les prévisions à la réalité ; Estimer les dérives Tableau de bord Observations Situation du projet à l’instant t Interprétation Action (consistant, fidèle) Réaction (complet) Visualisation de l’état du projet

8 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 8 Les grandeurs fondamentales CQFD Coût 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 (1hm=152 heures ouvrées « brutes », soit  132 heures utiles ; 1 mois=22 jours).  Le paramètre coût peut être imposé par le MOA Qualité 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. Check-up FURPSE).  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 plate-forme (i.e. les instructions écrites+celles générées). Délai 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 ». Fonctionnalités 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.

9 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 9 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 12207 : le processus de développement logiciel ISO 9126 : les caractéristiques qualité produit ISO 15504 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

10 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 10 À partir de quoi fait-on une estimation : les 4 grandeurs caractéristiques C Q F D Processus de développement F, QF', Q' F : fonctionnalités en tant que besoin Q : qualité de service (QOS) en tant qu’exigences 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) Perturbations Ressources C sur une durée D {savoir-faire, expérience de l’équipe, management et organisation} « Usine » logicielle

11 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 11 C/ effort Q/ mesurée F/ livrées D/ réactivité Les paramètres de l’estimation Modèle d’estimation Cycle de vie système/logiciel Architecture produit/système 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 Connaissance des scénarios d’emploi, flux d’information

12 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 12 Distribution CQFD sur les processus C CG, D CG C CD, D CD C PTU, D PTU C VVT, D VVT AQ globale centralisée CQFD global du projet C AQ = C AQ/GC + C AQ/CG + C AQ/CD + C AQ/PTU + C AQ/VVT CD P/TU VVT CG C AQ/CG C AQ/CD C AQ/PTU C AQ/VVT Déléguer Contrôler Agir Effort Nombre de RA/AC Courbe de maturité

13 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 13 Les étapes de la transformation {F,Q}  {F,Q} Initial : à T EB/EC-Début, T EB/EC-Fin  le logiciel en tant que besoin et exigence comportementale  {F,Q} CG : à T CG-Début, T CG-Fin  Expression fonctionnelle et conception générale  {F,Q} CD : à T CD-Début, T CD-Fin  Conception détaillée (Algorithmes, règles de traitement, diagrammes d’activité, etc.)  {F,Q} P : à T P-Début, T P-Fin  L’ensemble du code source (y compris les scripts de commandes) et la documentation associée  {F,Q} VVT/Final : à T VVT-Début, T VVT-Fin  L’ensemble des tests est écrit et correctement exécuté

14 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 14 Dynamique des processus (1/2) Modèle intuitif à 3 phases Effort Indicateur d’avancement du processus par rapport à un paramètre de production (+ critère de terminaison) Phase 1Phase 2Phase 3 Phase 1 : Initialisation du processus, collecte et vérification des informations nécessaires à son déroulement, construction d’un cadre permettant le démarrage de la phase 2 et la VVT et/ou optimisation en phase 3  Dépend fondamentalement de la qualité et du professionnalisme des personnes qui initialisent le processus Phase 2 : Production des livrables du processus selon les modalités propres au processus (organisation de l’équipe ; outils de production ; etc.)  Son efficacité dépend très fortement de la qualité du travail effectué en phase 1 et du talent du chef de projet Phase 3 : Validation, Vérification et Test des livrables du processus ; Optimisation si nécessaire  Satisfaction des critères FURPSE ; son efficacité dépend très fortement de la qualité du travail effectué en phase 1 et 2, en particulier en terme de complexité

15 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 15 Dynamique des processus (2/2) Modèle mathématique Volume de code (Couverture C1 95%) Effort 1ère estimation 2ème estimation Pentes quasi identiques Retard final Retard de programmation Défauts résiduels  Attention à l’ amplification due à la forme de la courbe en S Indicateur d’avancement du processus (+ critère de terminaison) Forme mathématique d’une courbe en S Approximation linéaire L’effort de VVT n’est pas proportionnel au volume de programmation (cf. complexité) Expression différentielle

16 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 16 Analyse du référentiel de l’estimation 1. Cycle de vie - 2. Architecture 3. Stratégie de test - 4. Maturité

17 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 17 1. Cycle de vie

18 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 18 La vision temporelle : le cycle de vie (1/2) Faisabilité Définition Développement et MCORetrait Réalisation de maquettes Version N°1 Version N°2Exploitation Version N°nExploitation Cycles de développement (par itération successives)  Durée d’un cycle : > 15-20 ans, mais > 30 pour les grands systèmes technologiques A l’issue de ces deux phases, l’architecture/urbanisation du système d’information doit être stabilisée Le modèle de croissance est explicite  Niveau de risque sous contrôle Exploitation Nombre de RA/AC Durée Mesure de la qualité de service (QOS) Prototype Expérimentation Réalisation de prototypes

19 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 19 La vision temporelle : le cycle de vie (2/2) Expression de besoin et exigences Exploitation et support Processus de conception Processus de développement Assurance qualité et activités transverses AQ EB/EC (Spécification fonctionnelles) CG CD P/TU VVT Mesure de la qualité de service Mesure de la maturité de l’EB/EC Défauts détectés Défauts propagés Défauts ajoutés Conception générale Conception détaillée Programmation et tests unitaires Intégration (VV&T) Implémentation Mesure du taux d’erreurs résiduelles Nombre de RA/AC Mesure de la maturité (i.e. contrat de service) en exploitation Durée Processus de spécification QOS

20 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 20 2. Architecture

21 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 21 La vision architecturale : l’arbre produit Sources d’information Puits d’information Application et/ou système logiciel Flux de messages sortant (types + occurrences) + règles d’enchaînement et de gestion des messages (i.e. des protocoles) + exigences système et environnement + ressources système nécessaires à l’exécution Flux de messages entrant (types + occurrences)

22 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 22 La vision architecturale : les fonctions Moniteur d’enchaînement Fonction F1 Fonction F2 Fonction F3 Fonction Fn Mémoire de stockage des messages entrants Mémoire de stockage des messages sortants Mémoire de stockage des règles de gestion et de la programmation des enchaînements Base de données en mémoire persistante Canal de lectureCanal d’écriture Ressources

23 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 23 La vision architecturale : les messages dp2 Fonction F1 MEMS DP Fonction F2 Fonction F3 Fonction Fn me1 me2 me3 mep p types de messages en entrée ms1 ms2 ms3 msq q types de messages en sortie dp1 dpr Ressources Application et/ou système logiciel Interactions Fonctions d’accès à la mémoire permanente et aux ressources

24 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 24 La vision architecturale : les caractéristiques FURPSE me1 me2 me3 mep p types de messages en entrée q types de messages en sortie ms1 ms2 ms3 msq F U R P S E Influence de l’ environnement système (sécurité, sûreté, interopérabilité, innocuité) Caractéristiques non fonctionnelles Caractéristiques fonctionnelles Une fonction quelconque doit pouvoir être analysée selon les différents plans FURPSE

25 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 25 La vision architecturale : organisation des fonctions en couche Modules fonctionnels de la couche C1 Couche C1 Modules fonctionnels de la couche C2 Couche C2 Services système communs à toute les couches + mémoire globale Couche Cp Services C1 EntréesSorties Système S organisé en couches et en services Services C2 Services Cp Interface Modules fonctionnels de la couche Cp Interface Application et/ou système logiciel

26 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 26 Vision architecturale MOA/MOE (1/2) Nouveau SI ou Adaptation d’un SI existant Fonctions à effectuer par l’informatique Fonctions à effectuer par des opérateurs humains Fonctions logicielles à développer par le MOE Fonctions logicielles à acquérir par le MOE  COTS + plate-forme Fonctions « métier » Fonctions de service (Réutilisation autres SI) IHM et contexte API de portabilité API « métier » Architecture logicielle = Traitements + Données + Contrôles Architecture système et Urbanisme  Niveau 1 Finalité du SI Enjeux stratégiques  Niveau 2 Disponibilité SI et contrat de service usagers  Niveau 3 Disponibilité informatique  Niveau 4 Réutilisation et constitution d’un patrimoine Caractéristiques NON fonctionnelles Caractéristiques fonctionnelles Règles de gestion paramétrables Patrimoine réutilisable

27 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 27 Vision architecturale MOA/MOE (2/2) Données Traitements Contrôles Ingénierie de l’architecture Ingénierie des Besoins/Exigences Modèles intuitifs « papier » Modèles métiers (BPR) Maquettes et simulation Logique de la construction progressive (configuration système) Urbanisme et Architecture testable (Cf. RAS) Transactions longues/courtes (OLTP, Workflow) Bus logiciel (EAI, IAI) Automates de surveillance globale Cinématique des IHM Modèles intuitifs (ERA à la MERISE) Analyse sémantique et types (MIND™) Modèles d’échanges (XML, …) Algorithmique « dure » si nécessaire (Data Mining) Prise en compte des contraintes SECURITÉ (confidentialité, intégrité) INTEROPÉRABILITÉ Ingénierie de l’acquisition du SI Domaine de préoccupation du MOA Modèles intuitifs globaux et enchaînements (Cf. catalogue UML) Prototypes instrumentés et performance globale

28 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 28 3. La stratégie d’intégration et la VV&T

29 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 29 Vision intégration  hiérarchie des entités Système informatisé Processus / Tâche Programme / Transaction Application Fonction / Procédure Bloc / Action Instruction « source » Instruction « machine » Ensemble / Regroupement Base de données (permanente) Fichier (permanent) Donnée « langage » Enregistrement / Agrégat Donnée « machine » Structure de données (volatile) Schéma / Vues / Méta-données Hiérarchie fonctionnelleHiérarchie des donnéesHiérarchie des contrôles Ordonnanceur système Workflow / EAI / Bus OLTP / Tâche (conversationnel) Ordonnanceur (Bloc / Action) Ordonnanceur (Instruction) Ordonnanceur (Surveillance) Objet (Type abstrait de données) Ordonnanceur (E/S, message) Type(s) du contrôle!! !

30 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 30 Intégration : ordonnancement de la construction Système informatiséProcessus / Tâche Programme / Transaction Application Fonction / Procédure Bloc / Action Instruction « source » Instruction « machine » Processus / Tâche n n n n n n n  Il faut évidemment tenir compte des données et des contrôles !!!

31 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 31 La vision qualité : le référentiel de test Recette Installation Recette Installation Intégration VV&T P/TU CG/CD EB/EC Plan de tests Système Recette Plan de tests Modules Intégration Conception des tests Modules/Transactions Intégration Système Recette Scénarios de tests Modules Intégration Système Cas à tester Modules/Transactions Intégration Système Recette Scénario de tests Recette Évaluation Productivité-Rendement de l’effort de tests  Construction de la courbe de maturité  Pour toutes les phases : collecte des Rapports d’Anomalies (RA) et des Actions Correctrices (AC) ; traçabilité Résultats des phases concernant l’activité V&V des phases suivantes TESTS ET VÉRIFICATIONS POUR LA NON RÉGRESSION Préparation Stratégie-Rentabilité de l’effort de tests  Architecture testable

32 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 32 La vision qualité : répartition de l’effort Objectifs de test Programmeur individuel Tests unitaires Programmeur individuel Tests unitaires Équipe projet Intégration projet Équipe projet Intégration projet Équipe système Intégration système Équipe système Intégration système Axe de progression de l’intégration en minimisant les retours arrière  1  3  2  i est un coefficient d’amplification Équilibrage de l’effort Test boîte noire Test boîte blanche Zone grise

33 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 33 La vision qualité : impact de la non régression Axe de progression du passage des scénarios de test Scénario N°1 Scénario N°2 Scénario N°i Scénario N°n Nombre d’exécution pour N scénarios : Critère d’arrêt :  Tous les scénarios ont été exécutés avec toutes les modifications  Attention aux doublons : plusieurs scénarios détectent le même défaut 

34 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 34 VVT Conception détaillée Programmation Tests de couverture et de contrôle Tests fonctionnel à partir des données Tests de performance Tests de robustesse Tests de pré-intégration Modèle de données, en particulier interfaces entre les modules, Modèle d’enchaînement/contrôle des fonctions INTÉGRATION Code source fabriqué par les programmeurs, compilé sans erreur Réduction du nombre de défauts au minimum acceptable selon le contrat de service 80 à 100 défauts par KLS 5 à 10 défauts par KLS Installation 1 à 2 défauts par KLS Découverte des défauts  Si la stratégie VVT est correctement conduite (niveau de maturité élevé : CMM 4/5 + architecture testable + PSP) le nombre de défauts résiduels peut tomber à [0.5-0.3] par KLS (Source SEI 2001) Revues Inspections

35 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 35 Statistique de répartition des défauts  Source : B.Beizer, Software testing techniques (1990) 

36 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 36 Une statistique de coût de correction des défauts 1er Quartile : 8% 2ème-3ème Quartile : 40% 4ème Quartile : 52% Source : Hewlett-Packard

37 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 37 4. Maturité

38 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 38 Perturbations et aléas : maturité et apprentissage  Définition  Capacité des individus et/ou des organisations à résoudre une classe de problèmes pour laquelle ils ont été formés (c’est une compétence) en commettant le moins d’erreur possible (c’est une performance pour une compétence donnée)  Forme générale de ces courbes dite en S : Effort Durée (Phénomène de temps de cuisson) Mesure de l’efficacité (Taux de retouches) Palier de maturité Extrapolation linéaire Erreur d’extrapolation

39 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 39 Perturbations et aléas : les acteurs Objectifs - Lettre de mission/cadrage CQFD (langage client) / Analyse de la valeur Objectifs QOS CQFD (informatique) Données sur les processus Risques et données des évaluations Tests et scénarios pour la certifications des composants réutilisés Exigences système (administration, surveillance, etc.) Besoins initiaux Proposition de solution Besoins validés par domaine métier Schéma d’urbanisation Architecture Conception détaillée Conception générale + domaines métiers Solutions validées Intégrats à valider RA/AC et modifications Chef de Projet Risques et données des évaluations Équipe(s) projet(s) Développeur(s) Client/Usager Organisation cible Client/Usager Organisation cible Spécialiste(s) métier(s) Architecte système Urbaniste Responsable de processus Responsable de la mutualisation (réutilisation) Responsable assurance qualité Responsable de l’intégration (IVV)

40 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 40 Initial Reproduire Définir Piloter Optimiser « laissez faire » Gestion du besoin et des exigences Assurance qualité Gestion de projet ; contrats de sous-traitance Gestion des configurations Définition des processus Vision systémique « gagnant-gagnant » des acteurs (  formation) Satisfaction du client final Revues de projet, évaluation des risques Pratique systématique de la mesure pour évaluer la performance : Processus de développement Produit logiciel réalisé Régulation du processus sur les objectifs stratégiques de l’entreprise : Prévention des défauts Intégration des NTI (  architecture ouverte et testable) Optimisation CQFD 1 2 3 4 5 Améliorer la maturité avec le CMM Durée pour passer de 1  5 : 5 à 6 ans minimum !!!

41 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 41 Organiser et planifier les actions Collecter les données de mesures Analyser et comprendre les différences Mettre en œuvre les améliorations Caractériser l’effort de maturité Réunir l’équipe Choisir ce qu’il faut améliorer Identifier des partenaires potentiels Choisir les partenaires Positionner les sondes de mesures (dans les projets) Collecter les données Analyser les résultats Bilan des coûts qualité et de non qualité (COQ/CONQ) Déterminer les écarts à résorber Etablir les niveaux de performance atteignables Communiquer les découvertes Plans d’actions Mise en œuvre et pilotage Réajuster si nécessaire Amélioration continue Rôle positif des inspections / revues et des formations Dynamique de la maturité : benchmarking

42 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 42 Maturité des plates-formes  Il faut être très prudent et lucide avec les nouvelles technologies qui n’ont pas encore atteint leur palier de maturité (ou en accepter explicitement le risque !)  En particulier, bien s’assurer des caractéristiques non fonctionnelles :  Comportement de l’outil en cas de dysfonctionnement : Messages d’erreurs, Auto-test et surveillance en ligne  Performance Que consomme réellement la technologie (Capacity planning) ?  Ouverture, évolutivité, politique de versions Conformité aux standards et normes de la profession  Disponibilité de personnel qualifié maîtrisant bien la technologie  La non maturité est toujours une source de retard

43 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 43 5. Construction progressive de l’estimation

44 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 44 Les étapes de l’estimation  Étape N°1 :  Définir le périmètre fonctionnel de l’application ou du système  Étape N°2 :  Définir les caractéristiques non fonctionnelles induites par le contrat de service ( analyse de la valeur )  Étape N°3 :  Identifier les incertitudes dues au caractère innovateur de l’application  Étape N°4 :  Identifier les incertitudes /aléas de l’environnement organisationnel/humain et de la maturité des technologies utilisées (outils et méthodes de développement – maturité des plates-formes)

45 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 45 + Complexité, complication, incertitude Noyau CQFD incompressible compte tenu des objectifs du projet (QOS) Surcoût CQD du au caractère innovateur (ou au manque d’expérience des acteurs) Surcoût CQD du aux incertitudes/aléas organisationnels et humains – Plates-formes Complications et incertitudes à prendre en compte dans le suivi de projet  Système qualité – Gestion des risques – Indicateurs Noyau Non Fonctionnel de l’application  Résulte d’une analyse de la valeur en fonction du contrat de service (analyse fine de l’impact des caractéristiques FURPSE )  Définition du projet Noyau Fonctionnel de l’application  Ce qui se stabilise le plus en amont du cycle de développement  Faisabilité du projet Complexité intrinsèque de l’application  Compétence de l’architecte CQFD RÉSULTANT Limite de l’ingénierie de projet

46 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 46 Analyse de la productivité 1.Qq. Lois d’échelle du développement 2.La Maintenance

47 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 47 1. Quelques lois d’échelle simples applicables au développement

48 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 48 Productivité des programmeurs  Évaluation en KLS documentées et testées  Application simple, avec une structure de données simple (Tables relationnelles), et un contrôle simple :  4 à 5 KLS / Homme  An (350 LS/ Homme  Mois)  Application moyennement complexe (quelques algorithmes, données en réseau pour la navigation [typique IHM], contrôle de type réseau sans protocole à réaliser [OLTP, EAI]) :  2 à 3 KLS / Homme  An (200 LS/ Homme  Mois)  Confusion fréquente :  Ce que le programmeur doit valider est ce que la machine exécute et non pas simplement ce que le programmeur a écrit  What you prove is what you execute

49 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 49 Relations quantitatives entre les activités  Sur la base des activités du cycle de développement (cf. COCOMO et/ou ISO12207) :  EB Expression de besoin, CG Conception générale, DEV Développement projet (Conception détaillée + Programmation Tests unitaires + VVT), Logistique projet (Management de projet, Gestion de configuration, Assurance Qualité, Documentation livrée)  On a les relations :  Effort Total  20  [ Effort EB ] Peut aller jusqu’à 25 pour les projets complexes  Effort projet  7 à 8  [ Effort CG ]  Effort DEV  5  [Effort CG ]

50 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 50 Connaissance de la Conception Générale et Détaillée Connaissance de la Machine et de l'environnement d'exécution Connaissance du langage et de l'environnement de programmation Connaissance de l'environnement système cible Instruction 1 Instruction 2 Instruction n Compétence et capacité du programmeur définissent la vitesse de fabrication et de vérification des instructions produites Connaissance de ce qui a déjà été programmé par lui- même ou par d’autres Test N° 1 Test N° 2 Test N° k Documentation Modèle PIP Données psycho-cognitives (1/3) Influence de l’environnement et des interactions entre les acteurs

51 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 51 Acte de programmation Interruptions / Perturbations extérieures Flux d'information entrant Flux d'instructions sortant vérifiées / validées Apport énergétique (effort en ha) Mémoire Permanente Mémoire de Travail Performance intrinsèque de la personne «Viscosité» de l'environnement organisationnel (en particulier prises de décisions collectives) Tâches ancillaires (secrétariat, etc.) Temps consacré à communiquer Temps d'attente irrécupérable (perte sèche) dû aux interruptions / perturbations extérieures Compétence intrinsèque de la personne : Connaissance de base Connaissance informatique Connaissance métier Compétence Performance Structure psycho-cognitive du programmeur Modèle PIP Données psycho-cognitives (2/3)

52 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 52 Structure d’un échange / interaction Modèle PIP Données psycho-cognitives (3/3) Temps Début Fin Début de saisie de la séquence Le programmeur collecte les données permettant d’écrire la séquence d’instructions Le programmeur réfléchit et raisonne  brouillon Fin de saisie de la séquence Fin de vérification de la séquence Le programmeur mémorise et archive ce qu’il a fait Partie matérielle de la saisie Le programmeur vérifie et valide soigneusement ce qu ’il a écrit Début Latence / Repos Fin de la collecte

53 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 53 Modèle PIP - Résultats  Vitesse limite absolue de codage (physiologique)  6500 LS/h  mois  Vitesse limite relative (inclut le temps de réflexion)  2200 LS/ h  mois  Vitesse de programmation artisanale (inclut partiellement la conception + brouillon)  1300 LS/ h  mois  Vitesse de programmation industrielle  Débutant : 220-350 LS/ h  mois ; Expert 308-352 LS/ h  mois COCOMO  350 LS/ h  mois  70 LS/ h  mois

54 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 54 Le programmeur expert  Le débutant à la tentation de programmer au cas par cas et/ou par essai-erreur  Le programme résultat est un ensemble de cas particuliers que seul l’auteur peut comprendre  L’expert traite le cas général (une abstraction du réel) d’abord, puis rajoute les cas particuliers qu’il documente soigneusement  Le programme est un algorithme + qq. cas particuliers  Pour une même fonction la taille peut varier de 1 à 4, voire 1 à 10 pour des enchaînements/contrôles  Ce n’est pas le langage qui fait l’expert !!!

55 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 55 Facteurs humains  Pour l’équipe : capacité d’abstraction, rigueur, aptitude à communiquer et à coopérer  Facteur compétence (architecte [ACAP] et programmeur [PCAP] )  Amplitude : 2 ; 15% inf : 1.42 ; 10% sup : 0.71  Amplitude : 1.76 ;15% inf : 1.34 ; 10% sup : 0.76  Facteur performance (développement de la maturité [APEX,PLEX,LTEX] )  En 1 an : 1.59  1 (62% de gain)  En 5 ans : 1  0.62

56 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 56 Résultat d’une bonne architecture (1/2)  1 instance de M, 5 appels au module M  Gain en taille :  4  L M M M M M N « portion » de code semblables de taille L = 1 abstraction architecturale Programme P de taille V1 mal factorisé M Programme P de taille V2 correctement factorisé Module de code factorisé Séquences d’appel à M

57 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 57 Résultat d’une bonne architecture (2/2)  Variation de la taille :  La qualité du travail architectural est le meilleur investissement durable M M M M M N modules semblables de taille L = 1 abstraction Programme P de taille V

58 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 58 Équilibrage des coûts entre tâches  F.Brooks :  33% Planning (inclut les spécifications), 17% Codage, 25% Test unitaire et pré-intégration, 25% Intégration système Mythical man-month  Hewlett-Packard :  18% Expression de besoin - Spécification, 19% Design, 34% Codage, 29% VV&T (R.B.Grady in Practical software metrics for project management and process improvement, Prentice Hall  Vade-mecum du chef de projet  40% Conception, 20% Codage, 40% Intégration  Les différences proviennent des règles de démarcation.

59 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 59 Impact d’un changement d’architecture Centralisée  Distribuées   20% des KLS sont impactées par le changement

60 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 60 Compression des délais (1/2)  Délai optimum :  L’effectif augmente comme l’inverse de la compression  !  Les communications augmentent comme N 2 ou 2 N !!!  Conclusion : le rendement s’effondre D/32D/3 D  D Délai Effectif N N/  Compression  p1 p2

61 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 61 Compression des délais (2/2)  Variation de la pente de la courbe de montée en charge :  Capacité à assurer la montée en charge ??!!  Communications ??!!

62 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 62 2. Productivité pour la maintenance

63 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 63 Caractéristiques générales  Domaines de validité :  Maintenance corrective – Maintenance évolutive  Facteurs de coût  Expérience du mainteneur par rapport au programme/système à maintenir  Maintenabilité du produit  Organisation  Possibilité de faire appel ou non à l’équipe de développement Cas d’une TMA ; séparation géographique/linguistique ; etc.  Ratio Mainteneur/Développeur  Quel est la quantité de code raisonnable pour un mainteneur ? Le mainteneur a nécessairement une productivité moindre que le développeur

64 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 64 Caractéristique qualité ( ISO 9126 ) de MAINTENABILITÉ  4 sous-caractéristiques principales Facilité d’analyse (analysability)  Aides aux diagnostic, traces  auto-contrôles, invariants, gestion de configuration et références croisées, traçabilité Facilité de modification (changeability)  Effort nécessaire pour modifier  degré de formalisation de la documentation, structuration du code et des données, API Stabilité  Effets inattendus des modifications  effets de bord, confinement, fuites de mémoire, canaux cachés, etc. Facilité de test (testability)  Effort nécessaire pour valider le logiciel modifié  hiérarchisation des tests, non régression, moniteur de tests

65 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 65 Caractéristiques qualité ( ISO 9126 ) complémentaires utiles Facilité d’adaptation  Possibilité d’adaptation à différents environnements  encapsulation des interfaces, paramétrisation, méta-données et dictionnaires de données en ligne Facilité à l’installation  Effort nécessaire à l’installation dans un environnement donné  environnement de test et de simulation, facilités système pour installer les corrections (édition de liens, « patches » démontables, etc.) Conformité aux règles de portabilité  Existence de normes de codage ou de conventions d’écriture facilitant la portabilité et la relecture (i.e. compréhension) du code Cf. Notation « hongroise » de Microsoft.

66 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 66 Contraintes logistiques  Exemple pour un programme industriel de 10 KLS :  Code source avec commentaire : 15 KLS  Texte de 300 pages (+X-ref, cartes des données, listages, etc.)  Volume des scénarios de tests de toute nature et des résultats de tests : équivalent à  10 KLS  Texte de 200 pages  Spécification au sens large ; diagrammes ; etc.  Texte de 50 pages  Tout manquement dans le référentiel doit être reconstruit par le mainteneur !!!  Un code mal maintenu se dégrade très vite !!!

67 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 67 Analyse d’impact des modifications  Type 1 : Ajout sans modification de l’existant  Productivité optimale : 5 à 15 PF/hm L’architecture a été faite en vue d’évolution (NB : cas rare !!!)  Type 2 : Ajout avec modification  Type 3 : Ajout avec modification et suppression  Type 4 : Ajout avec modifications diffuses  Type 5 : Ajout avec modifications, suppressions et réparations conflictuelles  Productivité : 0.5 à 3 PF/hm Situation fréquente suite à l’introduction d’actions correctrices qui s’avèrent incomplète voire fausse !!!

68 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 68 Caractéristiques quantitatives (1/3)  Coefficient de modification source CMS Le code supprimé n’est pas compté ( bruit de fond )  Coefficient d’ajustage source CAS  Modèle COCOMO II Facteur de Maintenabilité du Logiciel : Varie entre 0,1 et 0,5 Expérience du Mainteneur du Logiciel (degré de familiarité) : Varie entre 0 et 1

69 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 69 Caractéristiques quantitatives (2/3)  Coût moyen des corrections sur l’ensemble du cycle (Source HP)  25%  2H, 50%  5H, 20%  10H, 4%  20H, 1%  50H  Moyenne : 6,3H ; 1er Quartile : 8% ; 4ème Quartile : 52% Composant XComposant Y Code ajouté/modifié Code à vérifier Dépendances fonctionnelles, appelants/appelés, variables de contrôles Composants appelants Composants appelés  Autres facteurs de coût  Identification des tests pour la non régression des composants  Positionnement dans les couches architecturales

70 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 70 Caractéristiques quantitatives (3/3)  Ce qui est significatif pour un mainteneur est le nombre de rapports d’anomalies (RA) traités par hm  En moyenne 8 à 10 RA par mois ouvré Soit 15 à 20 heures ouvrées par RA (à comparer avec la statistique HP)  Volume de code / périmètre fonctionnel moyen gérées par mainteneur  sur la base du vade-mecum : 20-25 KLS à 40-50 KLS selon la capacité et l’expérience des mainteneurs Très dépendant du flux des modifications et des rapports d’anomalies, ainsi que des caractéristiques de maintenabilité

71 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 71 Méthodes de comptage

72 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 72 Ligne de code source - Langage de programmation  LHN Langage de haut niveau  3ème génération  Orienté Objet  LODP Langage orienté domaine de problème  Notion de « puissance expressive » d’un langage en équivalent assembleur  1 PF  320 LS (Assembleur)

73 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 73 Le piège du niveau de langage (1/2)  Question :  Comment expliquer la différence des coefficients de puissance entre Ada 83 et Ada 95, ou entre C et C++ / Java ???  Réponse :  Certainement pas par une vertu « magique » du langage !!!  Clé :  Les langages objets facilitent le codage des abstractions une fois qu’elles ont été découvertes, mais la découverte des abstractions fait partie de la conception (générale et détaillée) qui ne dépend que de la compétence des acteurs impliqués (architecte et programmeur) !!!  Fondement dans la théorie algorithmique de l’information et de la relation entre la compacité du code et la structure de la machine associée au langage Cf. le concept de machine abstraite, et de machine universelle versus machine spécialisée

74 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 74 Le piège du niveau de langage (2/2)  Le coefficient de puissance fait l’hypothèse que la maîtrise du langage s’accompagne d’une maîtrise équivalente de l’architecture d’une application, mais :  pas de relation de causalité entre les deux !!!  Cf. les facteurs de coût PLEX et ACAP-PCAP-AEXP de COCOMO  A titre d’exemple : Les manipulations de données sont vues comme des types abstraits, ce qui conduit à une identification rigoureuse des objets + cohérence renforcée par le typage fort Les classes sont correctement partitionnées et hiérarchisées La fiabilité est intégrée à l’architecture (architecture testable) grâce aux couches/serveurs + assertions (programmation par contrat explicite) Les mécanismes architecturaux (et les APIs correspondants) sont parfaitement maîtrisés

75 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 75 Point de fonction - Relation Données Instructions (1/2)  Question :  Quel est le sens de l’équivalence 1 PF =320 LS Assembleur ou 1 PF =107 LS Cobol/Fortran ou 1 PF = 53 LS C++… ????  Réponse :  Aucun, sauf si il y a une relation entre les données connues d’un programme et la taille de ce programme  Clé :  Quel est le programme étalon moyen correspondant à 320 LS assembleur ou 53 LS C++ ? Peut-on définir un tel étalon ?

76 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 76 Point de fonction - Relation Données Instructions (2/2) Programme à tester P Graphe de contrôle de P :  P Nombre cyclomatique de P : (  P ) (complexité statique) Nombre d’instructions impératives : I1 ENTRÉES SORTIE N1 variables en lecture e1, e2, … N2 variables en écriture s1, s2, … N3 variables de travail en lecture/écriture qui peuvent être effacées en fin de travail (brouillon) RÉSULTAT  Mapping S  R réflexe  Mapping S  R réfléchi (avec de la mémoire) w1, w2, …

77 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 77 Forme de l’étalon de comptage  Contraintes :  On sait définir une « instruction moyenne »  À partir des MIX d’instructions utilisées en moyenne par les machines Instructions de contrôle Références mémoire Calculs  On connaît la nature du Mapping S  R  Beaucoup de programmes réalisent des mappings linéaires entre les variables en entrée et les résultats en sortie (manipulations d’aggrégats de données)  Tout programme non conforme à ces hypothèses rend le décompte non fidèle

78 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 78 Forme des équations

79 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 79 Équation de l’effort (1/2)  Modèle COCOMO

80 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 80 Équation de l’effort (2/2) Dépend de la puissance expressive et du « grain » sémantique du langage + Expérience des acteurs Dépend de la complexité de l’application et de la maturité du processus de développement   est le facteur d’intégration Facteurs de coûtFacteurs d’échelle  Peut-on justifier la forme de l’équation ?

81 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 81 Coût de l’intégration de n modules Module Mx de x KLS Module My de x KLS += Modules intégrés Mx + My de 2  x KLS C oût U nitaire des I nteraction entre les n modules  CUI a 2 origines :  Interactions entre les acteurs Complexité résultant de l’organisation et des méthodes de travail  Interactions entre les modules Complexité résultant de l’architecture choisie

82 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 82 Impact du coefficient d’intégration   Tout ajout de code génère un coût d’intégration qui dépend du terme complexité Courbes établies à partir des équations COCOMO

83 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 83 Équation de la durée (1/2) 1/3T 2/3TT Temps Effectif Pic  Germe  : vitesse de recrutement Profil de charge T1 Temps Effectif Pic  Germe T2 Profil de charge

84 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 84 Effort utile - Productivité t1 Temps Effectif Pic  Germe Profil de charge théorique Profil de charge utile  En cas de compression trop forte des délais, la surface de productivité utile peut décroître  Loi de Brooks Surface de productivité utile Pic de productivité Surface de l’ effort perdu

85 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 85 Interprétation des équations avec CQFD C Q F D Rendement de l’effort VVT exprimé en termes de : Taux de défauts résiduels Disponibilité de l’application ou du système

86 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 86 Facteur de complexité du code (1/2)  Typologie des programmes :  Programmes transformationnels  T linéaire simple (mise en correspondance 1cas  1programme) La conception est une description  T est un algorithme qu’il faut « démontrer » La conception est l’invention d’un algorithme qui doit « marcher » dans tous les cas, y compris quand E est faux.  Programmes réactifs : gestion « temps réel » de signaux arrivant dans un ordre quelconque dans un environnement non sûr (cas des télécommunications)  Ordre d’arrivée des évènements   Entrelacement de plusieurs flots d’exécution   Grande combinatoire !!!

87 ©2002 / J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0Page 87 Facteur de complexité du code (2/2)  Productivité par classe de produits et taille :  Productivité par taux de modifications :  Source : IBM System Journal, Vol 24, N°2, 1985, Programming process productivity measurement system for System/370 ; les tailles sont en KLS.  NB : le ratio de productivité COCOMO Langage/Contrôle est  1.6 pour 30 KLS et  1.7 pour 60 KLS à comparer à 2.2 et 1.7 du tableau