GL 2

Introduction au génie logiciel # 2
Génie logiciel 1
plan
Introduction estimation Test
Le développement Méthode et
planification
vu du client Méthodologie
Cycles de vie Qualité
© A. Beugnard ENST Bretagne
Génie logiciel 2
Cycles de vie
• Modèles de cycle de vie
• Principes généraux
• Les phases
A. Beugnard 1 1998
Génie logiciel 3
Cycles de vie
• Les cycles de vie servent à modéliser le

déroulement dans le temps d'un processus
complexe.
• Permettent de définir le vocabulaire employé
• Permettent de planifier des activités
• Quelques exemples :
– Waterfall
–V
– Spirale
Génie logiciel 4
Cycle de vie standard
requirements
analysis
Requirements
spécification
Software
development
plan
Revue des besoins
A. Beugnard 2 1998
Génie logiciel 5

requirements
analysis
preliminary
design
Design
specification
Software test plan
Revue préliminaire
Génie logiciel 6
requirements
analysis
preliminary
design
detailed
design
Design
specification
Software test plan
Revue "critique" de conception
A. Beugnard 3 1998
Génie logiciel 7

requirements
analysis
preliminary
design
detailed
design
code and
unit test
Source code
Test
description
Génie logiciel 8
requirements
analysis
preliminary
design
detailed
design
code and
unit test subsystem
test and
integration
Test procedures
User documentation
Revue des tests

à effectuer
A. Beugnard 4 1998
Génie logiciel 9

requirements
analysis
preliminary
design
detailed
Requirements design
spécification code and
Software unit test subsystem
development test and
plan integration Test and
Design Source code integration
specification
Test
Software test plan description
Test procedures Test report
User documentation
Revue préliminaire
Revue "critique" de conception Revue des tests

Revue des besoins
à effectuer
Génie logiciel 10
Le cycle en V
besoins accept.
validation
concept. évaluation
decomp. Integration
vérification
concept. Tests
detail
code &
debug
A. Beugnard 5 1998
Génie logiciel 11
Cycle spirale
vérification analyse
validation
Succession de
prototypes. réalisation
Approche objet. conception
Génie logiciel 12
Cycle objet (exemple)

System Partial
Test integration
specification
Software Class design Class

requirements requirements implementation
analysis specification System
Class/Object Class Testing
Interactions Testing
User
requirements Identify
specification Class/Objects
Analyse
Aggregation
Generalization
Hierarchy
analyse conception réalisation
A. Beugnard 6 1998
Génie logiciel 13
Cycles de vie
• Les phases
Génie logiciel 14
Limite des cycles de vie
• La réalité suit rarement le modèle…retours arrière
• Il peut y avoir plusieurs flux en parallèle
• trop rigide
Mais offre des guides...
A. Beugnard 7 1998
Génie logiciel 15
Documents
Phase
Qui ? Etapes Décisions
1 : lancement...
n : conclusion
Objectif
Documents
Génie logiciel 16
Rôles
La même personne peut jouer plusieurs rôles
• Chef de projet • Assurance Qualité

• Chef de produits • Experts
• Architecte • Supports Outils
• Designer • Bêta Administration
• Documentation • Sites Bêta
• Programmeur • Responsable des ventes
• Intégrateur • Comptable
• Rédacteur des tests
• Testeur
• Ingénieur Système Certains rôles peuvent être extérieurs
• Administrateur Système à l ’organisation, mais des liens de
communication sont indispensables
A. Beugnard 8 1998
Génie logiciel 17
Changement de phase
Instabilité forte
Communication forte...
Génie logiciel 18
Communication
subsystem Test and

requirements preliminary detailed code and
test and integration
analysis design design unit test
integration
A. Beugnard 9 1998
Génie logiciel 19
Cycles de vie
• Les phases
Génie logiciel 20
Demande utilisateurs Information externe
Faisabilité
Consultant 1 lancement
requirements
analysis Consultant 2 Etude
Utilisateur (enjeux, risques)
Consultant
Direction 3 Conclusion continuer ?
Décider si
le projet mérite des
investissements
significatifs
Rapport faisabilité
A. Beugnard 10 1998
Génie logiciel 21
Rapport faisabilité Modèle de l'existant
Etude préalable
Chef de projet 1 lancement
Chef de projet
requirements Validation
Admin. Données 2 Bilan de
analysis du bilan
Consultant l’existant
Resp. Qualité
Experts Choix de
3 Scénarios
Utilisateurs scénarios
(variantes)
Etude de 2 ou 3 Chef de projet 4 Conclusion

variantes et de leurs
impacts organisationnel
Bilan existant Premiers éléments
fonctionnel, financier,... (modèles) de la
Dossier de choix
Rapport étude préalable solution choisie
Génie logiciel 22
Comprendre le domaine
• Etudier le contexte dans lequel va s'insérer le
système
• Qu'est-ce qui compose l'environnement du
système ?
– acteurs
– objets
– flux (d'information, de messages, de matériel, etc)
• Mickael Jackson : "le modèle du monde réel est

plus stable que le modèle su système !"
• Quels besoins fonctionnels...

• Quelle qualité...
A. Beugnard 11 1998
Génie logiciel 23
Bilan existant Premiers éléments

Dossier de choix (modèles) de la
Rapport étude préalable solution choisie
Etude détaillée
Chef de projet 1 Lancement
Chef de projet 2 Stabilisation Validation
preliminary Admin. Données 3 Plans générauxdoc.
design Techniciens 4 Etude des Validation
Consultants sous projets doc.
Experts 5 Homologation Homolog.
Utilisateurs de l'architecture
Resp. Qualité 6 Revue des ED
Finalisation de l'étude Chef de projet 7 Conclusion Suite...
fonctionnelle, et début de
l'étude technique
Cahier des charges Dict. de données
Etude détaillée Modèles
Plan Qualité Maquette IHM
Génie logiciel 24
Délimiter le système
• Le contexte étant bien compris, on se concentre

sur la réalisation du système
• On étudie les différentes solutions techniques

(architecture des logiciels - décomposition)
• On évalue par rapport à la qualité et aux besoins

requis
A. Beugnard 12 1998
Génie logiciel 25
Découpage
Application
Lot 1 Lot 2 Lot 3
Module 1 Module 3 Module 5 Module 4 Module 6
Module 2 Module 7 Module 8
Génie logiciel 26
Découpage
Contrôle
Application Communication
Accès BD
IHM
Calcul
Lot 1 Lot 2 Impression
Lot 3
Sécurité
Périphérique
Module 1 Module 3 Module 5 Module 4 Module 6
Module 2 Module 7 Module 8
A. Beugnard 13 1998
Génie logiciel 27
Cahier des charges Dict. de données
Etude détaillée Modèles
Plan Qualité Maquette IHM
Etude technique
1 Lancement
Chef de projet
Chef de projet Contrôle
Admin. Données2 Base de donnéeQualité
Analystes 3 Programmes
detailed
design Experts 4 Spécif des testsContrôle
Programmeurs Qualité
Chef de projet 5 Plan de Contrôle
Consultants développement Qualité
Experts
Chef de projet
6 Conclusion
Finalisation de la
description technique
(DB, communication,…) Cahier des charges Tech. Base de données
Etude technique Structure des programmes
Plan de développement Définition des tests
Génie logiciel 28
Détail de la solution retenue
• Une solution technique a été retenue
• Elle est détaillée ; on décrit précisément le

contenu de chaque module/lot
• On devrait rester indépendant du langage et du

système, mais certaines contraintes ou
caractéristiques peuvent influer sur la conception
(objet ou non, base de donnée ou non, etc.)
A. Beugnard 14 1998
Génie logiciel 29
Cahier des charges Tech. Base de données
Etude technique Structure des programmes
Plan de développement Définition des tests
Réalisation
1 Lancement
code and Chef de projet
unit test 2 Impl. BD
3 Programmation
subsystem Admin. Données Vérification
4 Tests
test and Analystes Acceptation
integration Programmeurs 5 Gestion des
modifications
6 Gestion envir. et
Chef de projet configuration
Utilisateurs 7 Stabilisation Validation
Chef de projet 8 Conclusion
Production du code et de
la documentation
associée Plans de recette Programmes
de mise en œuvre utilisateur Rapports de tests
de migration Documentation et versions
Génie logiciel 30
Stratégie au plus tard

Etude Technique Réalisation
Lot 1
Lot 2
Lot 3
plus de cohérence et de prudence, mais moins d'anticipation des aléas et plus d'inactivité
A. Beugnard 15 1998
Génie logiciel 31
Stratégie au plus tôt

Lot 1
Lot 2
Lot 3
moins de cohérence, mais moins d'inactivité et détection plus précoce d'éventuels aléas
Génie logiciel 32
Stratégie du projet Pilote

Lot 1
Lot 2
Lot 3
un compromis classique ...
A. Beugnard 16 1998
Génie logiciel 33
Plans de recette Programmes
de mise en œuvre utilisateur Rapports de tests
de migration Documentation et versions
Mise en œuvre
1 Lancement
Chef de projet
2 Intégration
Test and Chef de projet
integration Homolo
Analystes 3 Site pilote,
Utilisateurs gation
homologation
Logistique
4 Généralisation

Homologation et mise en
place du système,
généralisation de Bilan du projet Rapport des tests d'intégration
l'utilisation Rapport de formation
Homologation
Génie logiciel 34
Documentation
Demande d'amélioration,
du
de correction, d'évolution
Projet
Maintenance
1 Lancement
Chef de projet
2 Gest. des
Maintenance Chef de projet modifications Arbitrage
Analystes
et
Utilisateurs 3 Réalisation planifi-
des modifications cation

Corriger et faire
Evoluer...
Rapport de suivi de Mise à jour des programmes
maintenance et de leur documentation
A. Beugnard 17 1998
Génie logiciel 35
Bibliographie
• Cyrille Chartier-Kastler, Précis de conduite de projet informatique, Les

éditions d'organisation, 1995
• John J. Marciniak, Acquisition Management, in Encyclopædia of
Software Engineering, Vol 1, pp 4--24, John Wiley & Sons, 1994
• John J. Marciniak and D.J Reifer, Software Acquisition Management,
John Wiley &Sons, Inc, New York, 1990
• George Wilkie, Object-Oriented Software Engineering, Addison-
Wesley, 1993.
Génie logiciel 36
plan
Introduction estimation Test
Le développement Méthode et
planification
vu du client Méthodologie
Cycles de vie Qualité
A. Beugnard 18 1998
Génie logiciel 37
Estimation
• Quelques techniques
• La méthode Cocomo
• Les points de fonction
Génie logiciel 38
Estimation
Il est difficile de prévoir...surtout l'avenir
B.Shaw
Nécessité de précision pour :
• Identifier, justifier l'usage des ressources

(personnes, temps, capital) et leur priorité
• Négocier les budgets et les plannings
• Optimiser les coûts et la productivité
• Mesurer les risques et prendre les bonnes
décisions Analyse de risque
• Gérer l'impact des modifications

• Gérer les aléas
A. Beugnard 19 1998
Génie logiciel 39
Qu’estime-t-on ?
• La durée d'un projet
• Le nombre de personnes impliquées
• Le coût
• La taille du système
Génie logiciel 40
Niveau
d’information
volume nécessaire niveau de précision %
Ordre de grandeur
30 30
Avant projet
20 20
Préliminaire
10 10
Courants
5 5
Détaillé
- +
A. Beugnard 20 1998
Génie logiciel 41
Pourquoi de mauvaises estimations ?
• Les besoins sont vagues, et la qualité des résultats difficile à

évaluer
• Les "managers" sont trop optimistes et pensent que tout ira
bien ; Ils espèrent le succès parce qu'ils veulent le travail.
• On ne tire pas assez expérience du passé, on utilise trop le

« pif »; Il faut de l'expérience pour bien estimer
• Imprécision des notions d'homme-mois, de ligne de code

source
Alors, comment faire ...
Génie logiciel 42
Mythe de l’homme-mois
t
Faibles intéractions
#
t
Fortes interactions
Cueillette
A. Beugnard 21 1998
Génie logiciel 43
Pièges à éviter
• Faire trop précis

– travailler avec des marges d'erreur importantes
• Sous-estimer
– être exhaustif dans la liste des choses à estimer
• Sur-estimer
– ne pas intégrer systématiquement tous les coûts des aléas
possibles
• Confondre objectif et estimation
– résister à "Il ne faut pas que ça coûte plus de… »
• Vouloir tout estimer
– savoir avouer son ignorance
Génie logiciel 44
Qualités de l'estimation
• Rendue dans les délais

• Homogène en précision
• Honnête
• Complète
• Afficher les hypothèses
• Réaliste
• Proche du coût réel
Best Estimate
A. Beugnard 22 1998
Génie logiciel 45
Qualités de l'estimateur
• Utile au client
• Organisé
• Objectif
• Compétent
• Créatif
• Réaliste
• Manier l'analogie
Peut faire faux, pas idiot
Génie logiciel 46
Processus d’estimation
• Définir le vocabulaire
• Identifier les composants (WBS) et leurs versions
• Estimer la taille des composants
• Estimer la précision, la porté et la difficulté
• Estimer les ressources nécessaires
• Valider les estimations - Evaluer les risques
(What-if)
• Allouer les ressources
• Suivre et affiner les estimations
A. Beugnard 23 1998
Génie logiciel 47
Estimation
Génie logiciel 48
Méthodes d'estimations
• Par analogie
• Modèle paramétrique
• Oracle
• PERT
• Bottom-Up
A. Beugnard 24 1998
Génie logiciel 49
Par analogie
• Exploitation des expériences passées

• Catalogue des projets et estimations passés
• Ce qui est analysé :

– Taille
– Durée
– Effort
– Complexité
– Coût
• On rapproche ce qui se ressemble...

Génie logiciel 50
Modèles paramétriques
• Les estimations sont basées sur des modèles

mathématiques reposant sur divers paramètres.
• Elles sont largement répandus

– COCOMO
– SLIM
– PRICE-S
– SoftCost
• Elles disposent d'outils
A. Beugnard 25 1998
Génie logiciel 51
Oracle
• Equipe d'experts
• Atteinte d'un consensus par négociation
Génie logiciel 52
PERT
• Estimations reposant sur l'hypothèse d'une

répartition normale des estimations.
• On réalise plusieurs* estimations avec une
méthode "par analogie" ou "oracle" :
– la pire (l)
– la moyenne (m)
– la meilleure (h)
• Effort = (l+4m+h)/6
* pour être valide, les estimations (l, m, h) doivent être non corrélées (sources différentes)
A. Beugnard 26 1998
Génie logiciel 53
Bottom-Up
• Les estimations par analogie, PERT,

paramétrique, oracle, sont faites par
– activité ou
– composant élémentaire
• Puis consolidés (en suivant le WBS, par

exemple) jusqu'au sommet du projet.
Génie logiciel 54
Comparaison
Méthode Forces Faiblesses

Analogie basé sur l'expérience les expériences passées
peuvent être inappropriées
Paramétrique objective et répétable calibration difficile
beaucoup de facteurs subjectivité des facteurs
Oracle analyse croisée dépend de la qualité des
experts
PERT borne le risque difficile d'avoir de bonnes
entrées
Bottom-Up très détaillée long et beaucoup d'efforts
A. Beugnard 27 1998
Génie logiciel 55
Principe des modèles paramétriques
• Effort = a (Size)p
Avec :
– Effort en Personnes-Mois
– a impact des paramètres sur l'effort calibré
– Size quantité de travail (SLOC ou FP) estimé
– p exposant (proche de 1) calibré
Taille Estimation
facteurs
Génie logiciel 56
Principe des modèles paramétriques
• Effort = a (Size)p
Avec :
– Effort en Personnes-Mois
– a impact des paramètres sur l'effort calibré
– Size quantité de travail (SLOC ou FP) estimé
– p exposant (proche de 1) calibré
Taille Estimation Effort
facteurs
Taille
A. Beugnard 28 1998
Génie logiciel 57
Estimation
Génie logiciel 58
COCOMO
• Modèle paramétrique
• Facteurs dans le domaine public
• 3 modes de bases
– organique petite équipe, environnement stable

– semi-détaché équipe de taille moyenne
– détaché grande équipe, répartie, nouvel
environnement
A. Beugnard 29 1998
Génie logiciel 59
COCOMO simple
• mode organique : HM = 2,4 (KLSL) 1.05

• semi-détaché : HM = 3.0 (KLSL) 1.12 Effort
• détaché : HM = 3,6 (KLSL) 1.20
• mode organique : TDEV = 2.5 (HM) 0.38

• semi-détaché: TDEV = 2.5 (HM) 0.35 Durée
• détaché : TDEV = 2.5 (HM) 0.32
N = HM / TDEV
HM : Hommes-Mois (152heures)
KLSL : Kilo de Ligne de Source Livrées
Génie logiciel 60
COCOMO intermédiaire
• Quinze facteur correctifs sont introduits, valués
de VeryLow à XtraHigh
• Pour le projet :
– fiabilité requise du logiciel
– taille de la base de donnée
– complexité du produit
• Pour les contraintes de l'environnement :

– contraintes de temps d'exécution
– contraintes de place mémoire
– stabilité de la machine virtuelle
– système de développement interactif ou non
A. Beugnard 30 1998
Génie logiciel 61
COCOMO intermédiaire
• Pour le personnel :
– aptitude à l'analyse
– expérience du domaine
– expérience de la machine virtuelle
– aptitude à la programmation
– expérience du langage
• Pour les méthodes :

– méthode de programmation moderne
– outils logiciels
– durée du développement
Génie logiciel 62
COCOMO détaillé
• Les facteurs correctifs dépendent de la taille

(KLSL)
• Une répartition de l'effort sur les phases de

développement est réalisée
A. Beugnard 31 1998
Génie logiciel 63
Estimation de la taille
• Les "Function points" (Albrecht, 1979, 1984)
– Composant identifiable et unique (fonction)

– 5 types de fonction :
» Input
» Output
» Inquiry
» Internal Logical File
» External Interface File
Génie logiciel 64
Estimation
A. Beugnard 32 1998
Génie logiciel 65
Function Point
• Compter le nombre de fonctions (FC)
• Ajuster selon leur complexité (ci)

14 facteurs notés de 0 (pas d'influence) à 5
(fondamental)
– communication par message
– distribution de données ou de fonctions
– haut taux de transaction
FP = FC * PCA
– calcul complexe
– conception multi sites PCA = 0.65 + 0.01 Σ ci
– conception facilement maintenable
KLSL = -5 + 0.2 FP
Génie logiciel 66
Comparaison de SLOC et de FP
Case A Case B Difference
ASM ADA
(100K) (30K)
requirements 20 20 0
analysis and design 30 30 0
coding 100 30 -70
testing 50 30 -20
documentation 20 20 0
management 30 20 -10
total effort 250 150 -100 pro High

total cost $1,250,000 $750,000 -$500,000 Level lang.
cost per line $12.50 $25 +$12.5 Apparently
lines per month 400 200 -200 pro asm !
A. Beugnard 33 1998
Génie logiciel 67
Count Element Weight Totals
8 input X 4= 32
17 output X 5= 85
12 inquiry X 4= 48
5 internal X 10 = 50
5 external X 7= 35
total 250
complexity adjusts 1.2
FP 300
Génie logiciel 68
Case A Case B Difference
ASM ADA
(100K) (30K)
requirements 20 20 0
analysis and design 30 30 0
coding 100 30 -70
testing 50 30 -20
documentation 20 20 0
management 30 20 -10
total effort 250 150 -100

total cost $1,250,000 $750,000 -$500,000 pro High
cost per FP $4167 $2500 +$1667 Level lang.
FP per month 1.2 2 +0.8
A. Beugnard 34 1998
Génie logiciel 69
Conseils
• Définir et normaliser son propre processus

d'estimation
• Utiliser plusieurs techniques pour les recouper
• Calibrer le modèle avec ses propres expériences
• Evaluer les risques et les différentes options
• Stocker le données passées
• Etre réaliste
Génie logiciel 70
Quelques trucs...
• Pour les petits projets

– utiliser l'analogie
– paramétrique au moins 3-5 personnes et 5KSLOC
(sensibilité au personnes affectées)
• Pour augmenter la précision des modèles
paramétriques, utilisez vos propres données
• Pour gérer le risque
– estimer sans en tenir compte
– introduisez les facteurs de risque un par un
A. Beugnard 35 1998
Génie logiciel 71
Bibliographie
• D.J. Reifer, Cost estimation, Encyclopædia of Software Engineering,
pp209-220, J.J. Marciniak ed, John Wiley & Sons, Inc, New York,
1994
• B.W Boehm, Software Engineering Economics, Prentice Hall, Inc,
Englewood Cliffs, NJ, 1981
• D.V. Ferens, COCOMO, Encyclopædia of Software Engineering,
1994
• J.B Dreger, Function Point Analysis, Prentice Hall, Inc, Englewood
Cliffs, NJ, 1989
• C.S. Fugate, Estimating the cost of Object-Oriented Programming,
Journal of Parametrics, XI(1), Aug 1991
• C. Jones, Productivity, Encyclopædia of Software Engineering,
1994
A. Beugnard 36 1998

GL 2

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

GL 2

Titre original :

Transféré par

Droits d'auteur :

Introduction au génie logiciel # 2

Introduction estimation Test

Cycles de vie Qualité

© A. Beugnard ENST Bretagne

• Modèles de cycle de vie

© A. Beugnard ENST Bretagne

• Les cycles de vie servent à modéliser le

© A. Beugnard ENST Bretagne

Cycle de vie standard

Revue des besoins

© A. Beugnard ENST Bretagne

Cycle de vie standard

© A. Beugnard ENST Bretagne

Cycle de vie standard

Revue "critique" de conception

© A. Beugnard ENST Bretagne

Cycle de vie standard

© A. Beugnard ENST Bretagne

Cycle de vie standard

Revue des tests

© A. Beugnard ENST Bretagne

Cycle de vie standard

Revue "critique" de conception Revue des tests

© A. Beugnard ENST Bretagne

© A. Beugnard ENST Bretagne

© A. Beugnard ENST Bretagne

Cycle objet (exemple)

Software Class design Class

analyse conception réalisation

© A. Beugnard ENST Bretagne

• Modèles de cycle de vie

© A. Beugnard ENST Bretagne

Limite des cycles de vie

• La réalité suit rarement le modèle…retours arrière

• Il peut y avoir plusieurs flux en parallèle

Mais offre des guides...

© A. Beugnard ENST Bretagne

© A. Beugnard ENST Bretagne

• Chef de projet • Assurance Qualité

© A. Beugnard ENST Bretagne

subsystem Test and

• Modèles de cycle de vie

© A. Beugnard ENST Bretagne

Demande utilisateurs Information externe

© A. Beugnard ENST Bretagne

Rapport faisabilité Modèle de l'existant

Etude de 2 ou 3 Chef de projet 4 Conclusion

© A. Beugnard ENST Bretagne

• Mickael Jackson : "le modèle du monde réel est

• Quels besoins fonctionnels...

Bilan existant Premiers éléments

© A. Beugnard ENST Bretagne

• Le contexte étant bien compris, on se concentre

• On étudie les différentes solutions techniques

• On évalue par rapport à la qualité et aux besoins

© A. Beugnard ENST Bretagne

Lot 1 Lot 2 Lot 3

Module 1 Module 3 Module 5 Module 4 Module 6

Module 2 Module 7 Module 8

© A. Beugnard ENST Bretagne

Module 1 Module 3 Module 5 Module 4 Module 6

Module 2 Module 7 Module 8

© A. Beugnard ENST Bretagne

© A. Beugnard ENST Bretagne

Détail de la solution retenue