CQFD des Systèmes Informatisés

CQFD des Systèmes Informatisés Les Modèles d’estimationPrincipes et méthodes

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

Généralités Métrologie des projets informatiques

Les différents aspects d’un projet Axes principaux Aspect produit Aspect acteurs&organisation Aspect processus Sont au cœur de l’interaction : processus  produit Aspect cohérence globale du projet Caractéristiques FURPSE 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

Les fonctions et le processus de la gestion de projet ÉNUMÉRER TOUS LES TRAVAUX À FAIRE AUSSI PRÉCISEMMENT QUE POSSIBLE STRUCTURATION DÉTERMINER À L'AVANCE LES QUANTITÉS / QUALITÉS DE RESSOURCES NÉCESSAIRES AUX DIFFÉRENTES TÂCHES ESTIMATION AFFECTER LES RESSOURCES RÉELLES, DÉFINIR LES RESPONSABILITÉS, RÉPERTORIER LES CONTRAINTES D'EXÉCUTION LIÉES À L'ENVIRONNEMENT ORGANISATION PLANIFICATION 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 ORDONNANCEMENT MESURER ET CONTRÔLER RÉGULIÈREMENT L'AVANCEMENT RÉEL PAR RAPPORT AUX PRÉVISIONS; RENDRE COMPTE SUIVI

Les étapes de l'estimation EXPRESSION DE BESOIN 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. 1ÈRE ESTIMATION (GROSSIÈRE) DEVIS INITIAL ÉTUDE FONCTIONNELLE RÉ-ESTIMATION (MOINS 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/ou de prototypes PRÉ-ÉTUDE TECHNIQUE ÉTUDE TECHNIQUE COMPLÈTE ESTIMATION FINALE (PRÉCISE) RÉALISATION SUIVI DE LA RÉALISATION

Pourquoi estimer les projets ? • Comparer en permanence les prévisions à la réalité ; Estimerles dérives Visualisation de l’état du projet Tableau de bord Réaction (complet) Interprétation Observations Situation du projet à l’instant t Action (consistant, fidèle)

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. Les grandeurs fondamentales CQFD

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

À partir de quoi fait-on une estimation : les 4 grandeurs caractéristiques C Q F D Perturbations « Usine » logicielle Processus de développement F, Q F', 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) Ressources C sur une durée D {savoir-faire, expérience de l’équipe, management et organisation}

Les paramètres de l’estimation Cycle de vie système/logiciel Modèle d’estimation C/ effort Q/ mesurée F/ livrées D/ réactivité 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

Distribution CQFD sur les processus CCD, DCD CCG, DCG CQFD global du projet CG CPTU, DPTU CAQ/CG CD CVVT, DVVT Nombre de RA/AC CAQ/CD P/TU Courbe de maturité CAQ/PTU Déléguer Contrôler Agir VVT CAQ/VVT Effort AQ globale centralisée CAQ = CAQ/GC + CAQ/CG + CAQ/CD + CAQ/PTU + CAQ/VVT

Les étapes de la transformation {F,Q} • {F,Q}Initial : à TEB/EC-Début , TEB/EC-Fin • le logiciel en tant que besoin et exigence comportementale • {F,Q}CG : à TCG-Début , TCG-Fin • Expression fonctionnelle et conception générale • {F,Q}CD : à TCD-Début , TCD-Fin • Conception détaillée (Algorithmes, règles de traitement, diagrammes d’activité, etc.) • {F,Q}P : à TP-Début , TP-Fin • L’ensemble du code source (y compris les scripts de commandes) et la documentation associée • {F,Q}VVT/Final : à TVVT-Début , TVVT-Fin • L’ensemble des tests est écrit et correctement exécuté

Dynamique des processus (1/2)Modèle intuitif à 3 phases • 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 Indicateur d’avancement du processus par rapport à un paramètre de production (+ critère de terminaison) • 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 Effort • 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é Phase 1 Phase 2 Phase 3

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

Analyse du référentiel de l’estimation 1. Cycle de vie - 2. Architecture 3. Stratégie de test - 4. Maturité

1. Cycle de vie

Nombre de RA/AC Mesure de la qualité de service (QOS) Durée Exploitation La vision temporelle : le cycle de vie (1/2) Développement et MCO Retrait Faisabilité Définition Prototype Expérimentation Réalisation de maquettes Réalisation de prototypes Version N°1 Version N°2 Exploitation 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 Cycles de développement (par itération successives) Version N°n Exploitation Durée d’un cycle : > 15-20 ans, mais > 30 pour les grands systèmes technologiques

La vision temporelle : le cycle de vie (2/2) Processus de développement Processus de spécification Expression de besoin et exigences Mesure de la maturité de l’EB/EC EB/EC (Spécification fonctionnelles) • Défauts détectés • Défauts propagés • Défauts ajoutés Conception générale CG Conception détaillée Implémentation CD Programmation et tests unitaires • Mesure du taux d’erreurs résiduelles Processus de conception P/TU Intégration (VV&T) Mesure de la maturité (i.e. contrat de service) en exploitation Assurance qualité et activités transverses AQ Nombre de RA/AC VVT Exploitation et support QOS Mesure de la qualité de service Durée

2. Architecture

La vision architecturale : l’arbre produit Flux de messages entrant (types + occurrences) Flux de messages sortant (types + occurrences) Application et/ou système logiciel Sources d’information Puits d’information + 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

La vision architecturale : les fonctions Mémoire de stockage des règles de gestion et de la programmation des enchaînements Moniteur d’enchaînement • • • Fonction F1 Fonction F2 Fonction F3 Canal de lecture Canal d’écriture Mémoire de stockage des messages entrants Mémoire de stockage des messages sortants Fonction Fn Base de données en mémoire persistante Ressources

La vision architecturale : les messages Application et/ou système logiciel • • • ms1 me1 Fonction F1 ms2 me2 Fonction F2 ms3 me3 ••• ••• Fonction F3 p types de messages en entrée q types de messages en sortie ME MS Fonction Fn msq mep Interactions dp1 ••• dp2 Fonctions d’accès à la mémoire permanente et aux ressources dpr DP Ressources

E S P R U F La vision architecturale : les caractéristiques FURPSE Caractéristiques non fonctionnelles Caractéristiques fonctionnelles Influence de l’environnement système (sécurité, sûreté, interopérabilité, innocuité) me1 me2 me3 p types de messages en entrée • • • mep Une fonction quelconque doit pouvoir être analysée selon les différents plans FURPSE • • • ms1 ms2 msq ms3 q types de messages en sortie

La vision architecturale : organisation des fonctions en couche Application et/ou système logiciel Système S organisé en couches et en services Modules fonctionnels de la couche C1 Modules fonctionnels de la couche C2 Modules fonctionnels de la couche Cp Couche Cp Couche C1 Couche C2 • • • Entrées Sorties Interface Interface Services C1 Services C2 Services Cp Services système communs à toute les couches + mémoire globale

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

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

3. La stratégie d’intégration et la VV&T

Vision intégration  hiérarchie des entités Hiérarchie fonctionnelle Hiérarchie des données Hiérarchie des contrôles Système informatisé Schéma / Vues / Méta-données Ordonnanceur système Workflow / EAI / Bus Application Base de données (permanente) OLTP / Tâche (conversationnel) Processus / Tâche Fichier (permanent) Structure de données (volatile) Programme / Transaction Ordonnanceur (E/S, message) Ensemble / Regroupement Fonction / Procédure Ordonnanceur (Bloc / Action) Enregistrement / Agrégat Bloc / Action Ordonnanceur (Surveillance) Donnée « langage » Instruction « source » Ordonnanceur (Instruction) Instruction « machine » Donnée « machine » Type(s) du contrôle!!! Objet (Type abstrait de données)

Il faut évidemment tenir compte des données et des contrôles !!! Intégration : ordonnancement de la construction Système informatisé Processus / Tâche n n Programme / Transaction Application n Fonction / Procédure n n Processus / Tâche Bloc / Action n Instruction « source » n Instruction « machine »

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

La vision qualité : répartition de l’effort Objectifs de test Équilibrage de l’effort Programmeur individuel Tests unitaires Test boîte blanche 1 Axe de progression de l’intégration en minimisant les retours arrière Équipe projet Intégration projet 3 Zone grise 2 Équipe système Intégration système Test boîte noire i est un coefficient d’amplification

La vision qualité : impact de la non régression Nombre d’exécution pour N scénarios : Scénario N°1 • Attention aux doublons : plusieurs scénarios détectent le même défaut Scénario N°2 • • • Axe de progression du passage des scénarios de test Scénario N°i • Critère d’arrêt : • Tous les scénarios ont été exécutés avec toutes les modifications • • • Scénario N°n

Découverte des défauts • Modèle de données, en particulier interfaces entre les modules, • Modèle d’enchaînement/contrôle des fonctions Conception détaillée Revues Inspections • Code source fabriqué par les programmeurs, compilé sans erreur Programmation • Réduction du nombre de défauts au minimum acceptable selon le contrat de service VVT Tests de couverture et de contrôle • 80 à 100 défauts par KLS Tests fonctionnel à partir des données Tests de performance Tests de robustesse • 5 à 10 défauts par KLS Tests de pré-intégration • 1 à 2 défauts par KLS INTÉGRATION  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) Installation

Statistique de répartition des défauts • Source : B.Beizer, Software testing techniques (1990) 

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

4. Maturité

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 : Mesure de l’efficacité (Taux de retouches) Extrapolation linéaire Palier de maturité Erreur d’extrapolation Effort Durée (Phénomène de temps de cuisson)

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

Améliorer la maturité avec le CMM Durée pour passer de 1  5 : 5 à 6 ans minimum !!! Optimiser • 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 5 Piloter • Pratique systématique de la mesure pour évaluer la performance : • Processus de développement • Produit logiciel réalisé 4 Définir • Définition des processus • Vision systémique « gagnant-gagnant » des acteurs ( formation) • Satisfaction du client final • Revues de projet, évaluation des risques 3 Reproduire 2 • Gestion du besoin et des exigences • Assurance qualité • Gestion de projet ; contrats de sous-traitance • Gestion des configurations Initial 1 « laissez faire »

Dynamique de la maturité : benchmarking Amélioration continue 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 Rôle positif des inspections / revues et des formations

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

5. Construction progressive de l’estimation

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)

Complexité, complication, incertitude CQFD RÉSULTANT 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 Surcoût CQD du au caractère innovateur (ou au manque d’expérience des acteurs) • 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 • 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 CQFD incompressible compte tenu des objectifs du projet (QOS) Limite de l’ingénierie de projet

Analyse de la productivité Qq. Lois d’échelle du développement La Maintenance

1. Quelques lois d’échelle simples applicables au développement

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

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 ]

Instruction 1 Test N° 1 Test N° 2 Instruction 2 • • • • • • Test N° k Instruction n Modèle PIPDonnées psycho-cognitives (1/3) Influence de l’environnement et des interactions entre les acteurs Connaissance de ce qui a déjà été programmé par lui-même ou par d’autres Connaissance de la Conception Générale et Détaillée Connaissance de la Machine et de l'environnement d'exécution Connaissance de l'environnement système cible Connaissance du langage et de l'environnement de programmation Compétence et capacité du programmeur définissent la vitesse de fabrication et de vérification des instructions produites Documentation

CQFD des Systèmes Informatisés