CQFD des Systèmes Informatisés

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

CQFD des Systèmes Informatisés

Les Modèles d’estimationPrincipes et méthodes

C E N T R E D E

M A I T R I S E D E S

S Y S T E M E S E T

D U L O G I C I E L


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 comptageForme des équations


Généralités

Métrologie des projets informatiques


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 produit Aspect processus

Aspect cohérence globale du projet

Aspect qualité(ISO 9126)

Aspect coût Aspect délai

Axes principaux

Maximiser Minimiser

CaractéristiquesFURPSE


Les fonctions et le processus de la gestion de projet

STRUCTURATIONSTRUCTURATION

ORDONNANCEMENTORDONNANCEMENT

ESTIMATIONESTIMATION

ORGANISATIONORGANISATION

PLANIFICATIONPLANIFICATION

SUIVISUIVI

É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


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ÉALISATIONRÉ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


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


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 hommean ou en hommemois (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 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

Processus de développementProcessus de

développementF, 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)

Perturbations

Ressources C sur une durée D

{savoir-faire, expérience de l’équipe, management et organisation}

« Usine » logicielle


C/ effortQ/ mesuréeF/ livréesD/ réactivité

Les paramètres de l’estimation

Modèle d’estimation

Modèle d’estimation

Cycle de vie système/logiciel

Arc

hit

ectu

re

prod

uit/

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

CCG, DCGCCD, DCD

CPTU, DPTU

CVVT, DVVT

AQ globale centralisée

CQFD global du projet

CQFD global du projet

CAQ = CAQ/GC + CAQ/CG + CAQ/CD + CAQ/PTU + CAQ/VVTCAQ = CAQ/GC + CAQ/CG + CAQ/CD + CAQ/PTU + CAQ/VVT

CD

P/TU

VVT

CG

CAQ/CG

CAQ/CD

CAQ/PTU

CAQ/VVT

DéléguerContrôler

AgirEffort

Nombre de RA/AC

Courbe de maturité


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

Effort

Indicateur d’avancement du processus par rapport à un paramètre de production(+ critère de terminaison)

Phase 1 Phase 2 Phase 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é


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)

)1(0

0

kt

kt

eNk

ekNN

tN

ktNN

00 1

1

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é)

EffortNNkN

Expression différentielle


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


La vision temporelle : le cycle de vie (1/2)

Faisabilité Définition Développement et MCO Retrait

Réalisation de maquettes

Version N°1

Version N°2 Exploitation

Version N°n Exploitation

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)

PrototypeExpérimentation

Réalisation de prototypes


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


2. Architecture


La vision architecturale : l’arbre produit

Sources d’information

Puits d’information

Applicationet/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)


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 lecture Canal d’écriture

Ressources


La vision architecturale : les messages

dp2

Fonction F1

ME MS

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

Applicationet/ou

système logiciel

Interactions

Fonctions d’accès à la mémoire permanente et aux

ressources


La vision architecturale : les caractéristiques FURPSE

me1

me2

me3

mep

p t

ypes

de m

ess

ages

en e

ntr

ée

• • •

q types de messages en sortie

• • •ms1

ms2

ms3

msq

FU

RP

SE

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


La vision architecturale : organisation des fonctions en couche

Modules fonctionnels de la couche

C1

Couche C1


C2

Couche C2

Services système communs à toute les couches + mémoire globale

Couche Cp

Services C1

Entrées Sorties

Système S organisé en couches et en services

Services C2

Services Cp

• • •Interface


CpInterface

Application et/ou système logiciel


Vision architecturale MOA/MOE (1/2)

Nouveau SI ou Adaptation d’un SI existant

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 « métier »Fonctions de service

(Réutilisation autres SI)

IHMet

contexte

API de portabilité

API « métier »

Architecture logicielle=

Traitements+

Données+

Contrôles

Architecture système et Urbanisme

Niveau 1Finalité du SI Enjeux stratégiques

Niveau 2Disponibilité SI et contrat de service usagers

Niveau 3 Disponibilité

informatique

Niveau 4Réutilisation et constitution d’un patrimoine

Caractéristiques NON fonctionnelles

Caractéristiques fonctionnelles

Règles de gestion paramétrables Patrimoine réutilisable


Vision architecturale MOA/MOE (2/2)

DonnéesDonnées TraitementsTraitements ContrôlesContrô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


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


Vision intégration hiérarchie des entités

Système informatiséSystème informatisé

Processus / TâcheProcessus / Tâche

Programme / TransactionProgramme / Transaction

ApplicationApplication

Fonction / ProcédureFonction / Procédure

Bloc / ActionBloc / Action

Instruction « source »Instruction « source »

Instruction « machine »Instruction « machine »

Ensemble / Regroupement Ensemble / Regroupement

Base de données (permanente)Base de données (permanente)

Fichier (permanent)Fichier (permanent)

Donnée « langage »Donnée « langage »

Enregistrement / AgrégatEnregistrement / Agrégat

Donnée « machine »Donnée « machine »

Structure de données (volatile)Structure de données (volatile)

Schéma / Vues / Méta-donnéesSchéma / Vues / Méta-données

Hiérarchie fonctionnelle Hiérarchie des données Hiérarchie des contrôles

Ordonnanceur systèmeOrdonnanceur système

Workflow / EAI / BusWorkflow / EAI / Bus

OLTP / Tâche (conversationnel)OLTP / Tâche (conversationnel)

Ordonnanceur (Bloc / Action)Ordonnanceur (Bloc / Action)

Ordonnanceur (Instruction)Ordonnanceur (Instruction)

Ordonnanceur (Surveillance)Ordonnanceur (Surveillance)

Objet (Type abstrait de données)

Ordonnanceur (E/S, message)Ordonnanceur (E/S, message)

Type(s) du

contrôle!!!


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 !!!


La vision qualité : le référentiel de test

RecetteInstallation

RecetteInstallation

Intégration VV&T

Intégration VV&T

P/TUP/TU

CG/CDCG/CD

EB/ECEB/EC

Plan de tests• Système• Recette

Plan de tests• Modules• IntégrationConception des tests• Modules/Transactions• Intégration• Système• Recette

Scénarios de tests• Modules• Intégration• SystèmeCas à 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és

ult

ats

des

ph

ases

co

nce

rnan

t l’

acti

vité

V&

V

des

ph

ases

su

ivan

tes

TESTS ET VÉRIFICATIONS POUR LA NON RÉGRESSION

Préparation Stratégie-Rentabilité de l’effort de tests

Architecture testable


La vision qualité : répartition de l’effort

Objectifs de test

Programmeur individuelTests unitaires

Programmeur individuelTests unitaires

Équipe projetIntégration projet

Équipe projetIntégration projet

Équipe systèmeIntégration système

Équipe systèmeIntégration système

Axe

de

prog

ress

ion

de l’

inté

grat

ion

en m

inim

isan

t le

s re

tour

s ar

rière

1

3

2

i est un coefficient d’amplification

Équilibrage de l’effort

Test boîte noire

Test boîte blanche

Zone grise


La vision qualité : impact de la non régression

Axe

de

prog

ress

ion

du p

assa

ge d

es

scén

ario

s de

tes

t

ScénarioN°1

ScénarioN°2

ScénarioN°i

ScénarioN°n

• • •

• • •

Nombre d’exécution pour N scénarios :

2

)1( NN

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

NN

25.12


VVT


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


Installation


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

Insp

ect

ions


Statistique de répartition des défauts

Source : B.Beizer, Software testing techniques (1990)

Statistique portant sur 6.877 millions de LS (avec des commentaires)Nombre d’erreurs : 16 209Taux d’erreurs : 2.36 Err/KLS

Catégorie et/ou phase % erreursdécouvertes

Description et commentaires

Expression de besoin 8.12Spécification fonctionnelle 16.19Conception détaillée 25.18 Dont :

- 12.82 flot de contrôle, enchaînement- 12.36 algorithmes de traitement

Données 22.44 Dont :- 11.14 valeurs initiales, duplication, etc.- 12.36 typage, accès.

Programmation proprementdite ; codage

9.88

Intégration 8.98 Interfaces entre les modulesAppels système 1.74Tests erronés 2.76Divers 4.71

Total 100


Une statistique de coût de correction des défauts

% Effort moyen pardéfaut (en heures)

Effort cumulé(en heures)

25% 2h 50h50% 5h 250h20% 10h 200h

4% 20h 80h1% 50h 50h

100 erreurs 6.3h/err 630h

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 :

EffortDurée (Phénomène de temps de cuisson)

Mesure de l’efficacité(Taux de retouches)

Palier de maturité

Extrapolation linéaire

Erreur d’extrapolation


Perturbations et aléas : les acteurs

Objectifs - Lettre de mission/cadrage

CQFD (langage client) / Analyse de la valeur

ObjectifsQOS

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 générale +domaines métiersSolutions

validées

Intégrats à valider

RA/AC et modifications

Chef de ProjetChef de Projet

Risques et données des évaluations

Équipe(s) projet(s)Développeur(s)

Client/UsagerOrganisation cible

Client/UsagerOrganisation cible

Spécialiste(s) métier(s)

Architecte systèmeUrbaniste Responsable de

processus

Responsable de la mutualisation (réutilisation)

Responsable assurance qualité

Responsable de l’intégration (IVV)


InitialInitial

ReproduireReproduire

DéfinirDéfinir

PiloterPiloter

OptimiserOptimiser

« 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 !!!


Organiser et planifier les

actions

Organiser et planifier les

actions

Collecter les données de

mesures

Collecter les données de

mesures

Analyser et comprendre les

différences

Analyser et comprendre les

différences

Mettre en œuvre les

améliorations

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


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

PerformanceQue consomme réellement la technologie (Capacity planning) ?

Ouverture, évolutivité, politique de versionsConformité 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

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 projetSystè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


Analyse de la productivité

1. Qq. Lois d’échelle du développement

2. 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 / HommeAn (350 LS/ HommeMois)

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 / HommeAn (200 LS/ HommeMois)

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 ]


Connaissance de la Conception Générale et Détaillée

Connaissance de la Conception Générale et Détaillée

Connaissance de la Machine et de

l'environnement d'exécution

Connaissance de la Machine et de

l'environnement d'exécution

Connaissance du langage et de

l'environnement de programmation

Connaissance du langage et de

l'environnement de programmation

Connaissance de l'environnement

système cible

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

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 PIPDonnées psycho-cognitives (1/3)

Influence de l’environnement et des interactions entre les acteurs


Acte de programmationActe 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

PermanenteMé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étenceCompétence

PerformancePerformance

Structure psycho-cognitive du programmeur



Structure d’un échange / interaction


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


Modèle PIP - RésultatsVitesse limite absolue de codage (physiologique)

6500 LS/hmois

Vitesse limite relative (inclut le temps de réflexion) 2200 LS/ hmois

Vitesse de programmation artisanale (inclut partiellement la conception + brouillon)

1300 LS/ hmois

Vitesse de programmation industrielle Débutant : 220-350 LS/ hmois ; Expert 308-352 LS/ hmois

COCOMO 350 LS/ hmois 70 LS/ hmois


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 !!!


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


Résultat d’une bonne architecture (1/2)

1 instance de M, 5 appels au module M

Gain en taille : 4L

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


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

LNKV 1

)(2 LNKLNKV

LNL

111

Programme P de taille V


É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èmeMythical 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.


Impact d’un changement d’architectureCentralisée Distribuées

20% des KLS sont impactées par le changement

Phase Architecture centralisée

Architecture distribuées

EB/EC - Plans 6 7

CG 15 16 – 17

CD 22 22

P-TU 34 27 - 22

IVVT 23 28 - 32

Coût (à KLS constant) 100 HA 120 – 130 HA


Compression des délais (1/2)

Délai optimum :

L’effectif augmente comme l’inverse de la compression !

Les communications augmentent comme N2 ou 2N !!!

Conclusion : le rendement s’effondre

D/3 2D/3D

D

Délai

Effectif

N

N/3 ) (5,0 HAenEffortDan

Compression

p1

p2


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 ??!!

Impact de la compression

1/ 1 /2

0.9 1.11 1.23

0.8 1.25 1.56

0.75 1.33 1.78

0.5 2 4

3/D

Np1

22

11

3/ p1

D

Np2


2. Productivité pour la maintenance


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


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


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 codeCf. Notation « hongroise » de Microsoft.


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 !!!


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 modificationType 3 : Ajout avec modification et suppressionType 4 : Ajout avec modifications diffusesType 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 !!!


Caractéristiques quantitatives (1/3)

Coefficient de modification source CMSLe code supprimé n’est

pas compté (bruit de fond)

Coefficient d’ajustage source CAS

Modèle COCOMO II

Totales

ModifiéesAjoutées

KLS

KLSKLSCMS

EMLFMLCAS 1

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

CASCMSKLSKLS TotaleseMaintenanc



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 X Composant Y

Code ajouté/modifié

Code à vérifier• Dépendances fonctionnelles, appelants/appelés, variables de contrôles

Com

posa

nts

appela

nts

Com

posa

nts

appelé

s

Autres facteurs de coût Identification des tests

pour la non régression des composants

Positionnement dans les couches architecturales



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é


Méthodes de comptage


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)

Classe du langage

Langage Equivalent assembleur

Machine Assembleur 1

C 2,5

FORTRAN 3

LHN

COBOL 3

LHN Fortement typé Ada 83 4,5

C++ 5 LHN Orienté Objet

Ada 95 6

Visual BASIC 10

Smalltalk 15

LODP

SQL 25


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


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


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 ou1 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 ?


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ÉESSORTIE

N1 variables en lecturee1, e2, …

N2 variables en écritures1, s2, …

• • •

N3 variables de travail en lecture/écriture qui peuvent être effacées en fin de travail

(brouillon)

RÉ

SU

LT

AT

Mapping SR réflexe

Mapping SR réfléchi (avec de la mémoire)

w1, w2, …

xf

xxx seee ,,, 321 ],,[;],,[;,,, 2121321 yyxf

xxxxx wwswweee


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 machinesInstructions de contrôleRéférences mémoireCalculs

On connaît la nature du Mapping SR 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


Forme des équations


Équation de l’effort (1/2)

T y p o l o g i e d e s p r o g r a m m e s

S i m p l e d e t y p e c o n v e r s i o n

( O r g a n i c )

A l g o r i t h m i q u e

( S e m i - d e t a c h e d )

R é a c t i f

( E m b e d d e d )

05.14.2 KLSEffort HM

40.05.3 KLSD mois


39.08.3 KLSD mois


38.08.3 KLSD mois

38..0)(54.0 HAannée ED 35..0)(50.0 HAannée ED 32..0)(46.0 HAannée ED

L ’ a p p r o x i m a t i o n 35.0 HAannée EffortD e s t l é g i t i m e

Modèle COCOMO


Équation de l’effort (2/2)

1 KLSkEffort

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ût Facteurs d’échelle

Peut-on justifier la forme de l’équation ?


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

nCUIEffnnEff xx 1

Coût Unitaire des Interaction 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 modulesComplexité résultant de l’architecture choisie


Impact du coefficient d’intégration

1

1,2

1,4

1,6

1,8

2

2 4 6 8 10 12 14 16 18 20

Facteur d'intégration

Am

plif

icat

ion

des

co

ûts

0,05

0,12

0,2

nxEFFn

xnEFF

)(

)(

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


Équation de la durée (1/2)

1/3T 2/3T TTemps

Effectif

Pic

Germe

: vitesse de recrutement

tE

Profil de charge

T1Temps

Effectif

Pic

Germe

T2

2ttE Profil de charge

2

9

2

332

1

33332

1T

TTTTTTEffort

23

0

2

9 2 Tdt)tt (Effort

T

EffortT 2

5.1

3223

32

81

2

9

2

9322 TTTttEffort

T

O


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


Interprétation des équations avec CQFD

1 KLSkEffort

3,0HAen )04,05,0( ED

C

Q

F

DRendement de l’effort VVT exprimé en termes de :

• Taux de défauts résiduels

• Disponibilité de l’application ou du système


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 !!!

SE Transf

!N

! !

!

N2N1

N2N1


LANGAGES 1.8 3.9 4CONTRÔLE 1.6 1.8 2.4TÉLÉCOM 1 1.6 2Taille <10 10-50 >50

LANGAGES 3 6 6.6CONTRÔLE 1.5 2.3 2.3TÉLÉCOM 1.4 1.8 1.9% instructions(nouvelles/modifiées)

<20 20-40 >40

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

Documents

CQFD des Systèmes Informatisés