Upload
dima
View
73
Download
31
Embed Size (px)
DESCRIPTION
CQFD des Systèmes Informatisés. Les Modèles d’estimation Principes 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 - PowerPoint PPT Presentation
Citation preview
©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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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 comptageForme des équations
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 3
Généralités
Métrologie des projets informatiques
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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 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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 5
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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É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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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 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.
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 10
À 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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 11
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 12
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é
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 13
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é
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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 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é
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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)
)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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 16
Analyse du référentiel de l’estimation
1. Cycle de vie - 2. Architecture
3. Stratégie de test - 4. Maturité
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 17
1. Cycle de vie
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 18
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 20
2. Architecture
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 21
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)
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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 lecture Canal d’écriture
Ressources
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 23
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 24
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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ées Sorties
Système S organisé en couches et en services
Services C2
Services Cp
• • •Interface
Modules fonctionnels de la couche
CpInterface
Application et/ou système logiciel
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 26
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 27
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 28
3. La stratégie d’intégration et la VV&T
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 29
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!!!
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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 !!!
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 31
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 32
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 33
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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
Insp
ect
ions
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 35
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 36
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 37
4. Maturité
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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 :
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 39
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 détaillée
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)
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 40
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 !!!
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 41
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 43
5. Construction progressive de l’estimation
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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)
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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 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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 46
Analyse de la productivité
1. Qq. Lois d’échelle du développement
2. La Maintenance
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 47
1. Quelques lois d’échelle simples applicables au développement
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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 / 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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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 ]
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 50
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 51
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
Modèle PIPDonnées psycho-cognitives (2/3)
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 52
Structure d’un échange / interaction
Modèle PIPDonné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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 53
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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 !!!
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 56
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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
LNKV 1
)(2 LNKLNKV
LNL
111
Programme P de taille V
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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è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.
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 59
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 60
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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 ??!!
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 62
2. Productivité pour la maintenance
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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 codeCf. Notation « hongroise » de Microsoft.
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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 !!!
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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 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 !!!
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 68
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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 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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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é
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 71
Méthodes de comptage
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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)
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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 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 ?
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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É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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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 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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 78
Forme des équations
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 79
É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
12.10.3 KLSEffort HM
39.08.3 KLSD mois
20.16.3 KLSEffort HM
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 80
É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 ?
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 82
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 83
É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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 85
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
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 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 !!!
SE Transf
!N
! !
!
N2N1
N2N1
©2002 /J.Printz / CNAM-CMSL / CQFD des systèmes informatisés – Modèles d’estimation / Vers. 3.0 Page 87
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