Objectif

Analyse des besoins

Appréhender et appliquer les concepts de
& Gestion de projets „

l'analyse des besoins et de la gestion des

projets informatiques à grande échelle.
Philippe Collet
Licence 3 Info / MIAGE „ Pré-requis :
2011-2012 „ Aucun

http://deptinfo.unice.fr/twiki/bin/view/Linfo/ABGP

P. Collet 1 P. Collet 2

Evaluation Programme
„ Projet réalisé lors des TD : Cahier des charges et plan de „ Principes et méthodes pour l'analyse des besoins, la conduite
tests d'un très grand projet, par équipe de 4 à 5 d'un projet de développement logiciel de grande taille
„ Evaluation intermédiaire : 20 % „ Principes d'assurance qualité, de validation et de vérification
„ Evaluation finale sur le rendu du projet : 40 % associés
„ Réalisation d’une analyse complète des besoins pour un grand
système informatique
„ étude de faisabilité
„ Interrogation de 2h (40 %) à la fin du cours / support de „ analyse des besoins clients
cours autorisé „ définition des fonctionnalités
„ définition des contraintes non fonctionnelles
„ organisation du projet
Présence obligatoire et primordiale au premier „ Planification
TD pour la formation des équipes „ plan des tests

P. Collet 3 P. Collet 4

1
 Plan du cours
„ Introduction : mythes et réalités
„ Analyse des besoins, cahier des charges Introduction
„ Cycle de vie du logiciel
„ Gestion de projets „ Pourquoi ?
„ Assurance Qualité : modèles et normes „ Génie logiciel : définition(s)
„ Pourquoi c’est difficile ?
„ Validation et Vérification
P. Collet 5
P. Collet 6

Pourquoi le Génie logiciel ? Génie logiciel : historique

„ pour passer du développement

„ Histoire drôle : la facture à 0 euro
logiciel ad hoc et imprévisible
„ Réponse à la crise du logiciel, il y a 40 ans
à
„ Conférence OTAN 1968
„ un développement logiciel
systématique et réfléchi
P. Collet 7 P. Collet 8

2
 Pourquoi ne construit-on pas les logiciels
La crise du logiciel comme on construit des ponts ?
„ Grosses erreurs : Les projets logiciels Génie logiciel
„
„ Génie civil „
„ Les sondes perdues (Vénus ne livrent pas le
„
„ Échecs moins nombreux „ Échecs très nombreux
dans les années 60, Mars produit dans les temps
„ L ’écroulement est grave et „ Crash système pas considéré
en 99) „ coûtent beaucoup plus met en danger l ’utilisateur comme inhabituel
La fausse attaque de chers que prévu.
„
„ On ne répare pas un pont „ Cause du bug pas directement
missiles (1979) „ délivrent un produit de « buggé », on reconstruit un identifiable
Les missiles Patriotes qualité très faible pont qui s’écroule.
„ „ Dommages mineurs
(1991) „ échouent dans la On inspecte tous les ponts
„ A part dans les systèmes
majorité des cas !!!
„

„ 1er vol d’Ariane 5 (1996) construits sur le même modèle critiques, on considère que le
„ Étude américaine de Les ponts résistent à toutes les logiciel ne peut anticiper
„ L’aéroport de Denver 1995 : 81 milliard $ /
„

conditions (à 99 %...) TOUTES les situations

(1994-96) an en échec
„ L’an 2000... ) Différence d ’approche face à l ’échec, face aux pannes
P. Collet 9 P. Collet 10

Pourquoi ne construit-on pas les logiciels

comme on construit des ponts ? Génie logiciel : définition (ou presque)

„ Génie civil „ Génie logiciel „ Discipline (= méthodes, techniques et outils)

„ Plusieurs milliers d ’années „ Les systèmes informatiques se „ basée sur le savoir (théorique)
d ’expérience dans la complexifient trop vite
construction des ponts „ Les logiciels passent par des „ le savoir-faire (pragmatique)
„ Les ponts sont des systèmes états discrets, dont certains ne „ et le faire savoir (communication)
continus et analogiques sont pas prévus
„ On repeint un pont, on change „ Ajouts, changements de „ pour produire (développement)
l ’enrobée de la route… fonctionnalités, de plate-
„ de façon industrielle (taille, diffusion)
formes...
„ On ne reconstruit pas la moitié
d ’un pont „ des logiciels (= les produits)
„ de qualité au meilleur prix...
) Différence dans la complexité et dans la maintenance
P. Collet 11 P. Collet 12

3
 Les mythes de gestion de projet Les mythes du client
„ Les outils actuels sont la solution „ Une idée générale des objectifs est suffisante
„ un nul avec un outil est toujours un nul pour commencer le codage – on ajoutera les
„ Si on est en retard, on ajoutera du personnel détails plus tard
„ Une forte communication entre clients et développeurs
est toujours nécessaire
„ Les changements peuvent être facilement
répercutés parce que le logiciel est flexible
„ Les changements ne peuvent être évités, c’est la vie...
„ Les changements tardifs coûtent très chers

P. Collet 13 P. Collet 14

L’impact des changements Les mythes des développeurs

„ Une fois que le programme est écrit et qu’il
Coût du changement

tourne, le travail est terminé

60 - 100 x
„ 50-70% de l’effort est réalisé après la livraison
„ Jusqu’à ce que le programme tourne, il n’y a
aucun moyen d’évaluer sa qualité
1.5 - 6 x „ Inspections & revues
1x
„ La seule chose à livrer pour un projet réussi est
Définition Développement Après livraison un programme qui marche
„ Documentation (utilisateur, maintenance)

P. Collet 15 P. Collet 16

4
 Pourquoi c’est difficile ? Pourquoi c’est difficile ? (suite)

„ Invisibilité du logiciel „ La spécification :

„ Facilité apparente d’écriture et de modification „ Le logiciel modifie son environnement

„ Le produit fini est différent du programme : „ La maintenance (67 % du coût total)

„ produit logiciel : généralisation, tests, documentation, „ corrective (50 %) : 60 % des défauts proviennent
maintenance * 3 d ’erreurs de spécification ou de conception.

„ programme intégré dans un système (interfaces) * 3 „ évolutive : se méfier de l’effet 2ème version...
„ L’optimisme !
) produit logiciel intégré dans un système : *9
„ Ajouter du personnel à un projet en retard ne fait que
) The mythical man-month de Frédéric Brooks (1975)
le retarder plus Loi de Brooks

P. Collet 17 P. Collet 18

Les réponses à la crise 40 ans de Génie logiciel

„ Recherche du concept de qualité Architectures
Orientées
„ Maîtrise du processus de développement Services :
Approche
„ Méthodes et outils structurés (CASE) composants Business
Approche objets Java beans processes
„ Programmes de recherche Active X Web Services
outils GL:
Politique qualité,
„ Approche solo méthodes structurées
langages C++, J2EE, .NET
Java serveurs Réseaux,
„ Prolog, Lisp, Smalltalk, etc. outils GL : ORB (CORBA) d’applications Internet
Systèmes
„ Approche par objets Modèles de
cycles de devt
environnements CASE
langages (ADA…)
Réseaux,
Internet
ubiquitaires
Réseaux, Cloud
) Réutilisation théorique la crise: Micro informatique client/serveur n tiers Virtualisation
coûts Bases de données hétérogénéité e-business
„ Approche par composants délais Temps réel, systèmes Aide à la décision Réutilisation
qualité embarqués datawarehouse
) Réutilisation quasi-effective
1970 1980 1990 2000 2010
P. Collet 19 P. Collet 20

5
 Le logiciel, fin 2011 Liste (non-exhaustive) des problèmes
„ Fiabilité meilleure mais… „ Productivité
Coûts et délais
„ partout, sous toutes les formes „

„ Simplicité
„ gros, très très gros, cher, très très cher ! „ Uniformité, orthogonalité, unicité, normalisation
„ Types : „ Communication H/M
„ Sur mesure (à partir de composants, de services) „ Ergonomie, interactivité, multimédia, simplicité,
„ Générique (les progiciels) rapidité, documentation (contextuelle)

„ Interconnectés, en constante évolution…

„ Fonctionnels
„ Étendue et pertinence des services, fiabilité (correction,
„ Acteurs : constructeurs, SSII, utilisateurs robustesse)

P. Collet 21 P. Collet 22

Liste des problèmes (suite) Il faut donc…

„ Matériau „ Développer des „ A partir
Logiciel, structure, langage, modularité…
d’un cahier des
„
„
Organisation „ nouveaux produits
„
charges
„ Gestion de projet visibilité, protections, contrôles
„ Réalisme „ nouvelles fonctions „ d’applications
Adéquation aux besoins, évolutivité
existantes
„
„ nouveaux portages de composants
„ Économique „

„ Réutilisabilité, transportabilité existants

„ Diversité ) avec des objectifs „ En
„ BD, IA, Calcul, Parallélisme, Réseau, Internet, intranet de qualité et „ interne
„ Divers de productivité „ sous-traitance
„ Juridique, psychologique
P. Collet 23 P. Collet 24

6
 Génie logiciel : les besoins Qualités du logiciel
„ Langages pour décrire „ Il faut bien distinguer
„ Outils pour manipuler
„ Les qualités utiles à l’utilisateur, donc a priori
„ Méthodes pour décider souhaitées par le client
„ Phases d’exploitation
„ Théories pour démontrer
„ Professionnels pour réaliser „ Les qualités utiles au développeur
„ Phases de construction et de maintenance
„ Logistique pour supporter

P. Collet 25 P. Collet 26

Qualités pour l’utilisateur Qualités pour l’utilisateur (suite)

„ Fiabilité = Validité + Robustesse „ Robustesse: faire tout ce qu’il est utile et possible de
faire en cas de défaillance: pannes matérielles, erreurs
„ Validité (Efficacité) ≡ correction, exactitude humaines ou logicielles, malveillances…
„ Efficacité : qualité d’une chose ou d’une personne „ Performance (parfois appelée efficacité)
qui donne le résultat escompté „ Utiliser de manière optimale les ressources matérielles :
)Assurer exactement les fonctions attendues, définies temps d’utilisation des processeurs, place en mémoire,
dans le cahier des charges et la spécification, en précision…
supposant son environnement fiable „ Convivialité
)Adéquation aux besoins „ Réaliser tout ce qui est utile à l’utilisateur, de manière
simple, ergonomique, agréable (documentation,
aide contextuelle…
P. Collet 27 P. Collet 28

7
 Qualités pour le développeur Qualités pour le développeur (suite)

„ Documentation „ Interchangeabilité
„ Tout ce qu’il faut, rien que ce qu’il faut, là où il „ Pouvoir substituer une variante d’implémentation sans
conséquence fonctionnelle (et souvent non-
faut, quand il faut, correcte et adaptée au fonctionnelle) sur les autres parties
lecteur : crucial !
„ Évolutivité
„ Modularité = Fonctionnalité + Interchangeabilité „ Facilité avec laquelle un logiciel peut être adapté à un
+ Évolutivité + Réutilisabilité changement ou une extension de sa spécification

„ Fonctionnalité „ Réutilisabilité
„ Aptitude à être réutilisé, en tout ou en partie, tel que ou
„ Localiser un phénomène unique, facile à comprendre
par adaptation, dans un autre contexte : autre
et à spécifier application, machine, système…
P. Collet 29 P. Collet 30

Qualités pour l’entité de

développement Génie logiciel : le défi
„ Contradictions apparentes
„ Client satisfait (est-ce possible ?) „ Qualités vs coût du logiciel
„ Qualités pour l’utilisateur vs qualités pour le
„ Coût minimum de développement développeur
„ Nombre de développeurs „ Contrôler vs produire
„ Formation des développeurs „ Conséquences
„ Nombre de jours de réalisation ) Chercher sans cesse le meilleur compromis
„ Environnement ) Amortir les coûts
„ Réutilisation maximale „ Premier exemplaire de composant coûteux à

produire ou à acheter, puis amortissement…

P. Collet 31 P. Collet 32

8
 Objectifs de qualité Les 3 P ˆ
ˆ
formation
compétences
ˆ communication
Réduire le nombre „ Adéquation aux besoins
Personnes
„

d'erreurs résiduelles „ Efficacité temps/espace

ˆ cahier des
Maîtriser coût et planification
„ „ Fiabilité ˆ charges
ˆ coordination conception
durée du „ Testabilité, Traçabilité gestion
ˆ
ˆ ˆ code source
développement mesures
„ Adaptabilité ˆ ˆ exécutable
„ sans nuire à la ˆ analyse ˆ documentation
„ Maintenabilité conception utilisateur
créativité et à ˆ

„ Convivialité (interface et ˆ implémentation ˆ cas de test

l’innovation résultats des
documentation) Processus Produitsˆ tests
demande de
) doivent rejoindre les objectifs de productivité ˆ
changement
P. Collet 33 P. Collet 34

Système informatique
Analyse des besoins „ “Un ensemble d’éléments qui sont organisés pour
accomplir un but prédéfini par un traitement de
et cahier des charges l’information”
„ utilise des :
„ Logiciels
Matériels (informatiques)
Terminologie
„
„
„ Personnes
„ La faisabilité „ Bases de données (ensemble organisée de données)
Documentation
L ’analyse des besoins
„
„
„ Procédures (étapes qui définissent comment utiliser
„ Le cahier des charges les éléments du système)
P. Collet 35 P. Collet 36

9
 Développement d’un système Différence dans les maîtrises
„ La maîtrise d’ouvrage
„ Entité responsable de l’expression du besoin
„ Souvent non informaticien
„ Besoin réel / budget
) Possibilité de maîtrise d’ouvrage déléguée
„ La maîtrise d’œuvre
„ Entité responsable de la concrétisation de l’idée en outil
informatique
„ Pas de connaissance fonctionnelle
„ Bons choix techniques, adéquation avec les besoins,
performances…

P. Collet 37 P. Collet 38

Étude de faisabilité Étude de faisabilité (suite)

„ Tous les projets sont faisables ! „ Faisabilité économique
„ étant donnés des ressources et un temps „ Faisabilité technique au plus tôt
infinis
„ Risques de développement
„ Disponibilité des ressources
„ Mais les ressources sont limitées...
„ Technologie nécessaire
„ Faisabilité légale
„ Alternatives

P. Collet 39 P. Collet 40

10
 Étude de faisabilité :
aspects économiques Analyse des besoins
„ Analyse du rapport Coût/Bénéfice : „ Définition des besoins à différents niveaux d’abstraction :
Besoins de l’utilisateur
„ Coût du système „

„ Besoins des composants

„ Bénéfices mesurables (en € )
„ Définition du système à réaliser avec le point de vue de
„ Bénéfices non mesurables
l’utilisateur et/ou du client
„ meilleure conception
) Les utilisateurs doivent être capables de comprendre ce document
„ meilleures décisions marketing
„ satisfaction accrue du client
) Analyse des besoins : LE QUOI
)L’analyse Coût/Bénéfice est souvent le moyen
) Conception : LE COMMENT
d’obtenir le feu vert de la direction

P. Collet 41 P. Collet 42

Le processus d’analyse Bases de la communication

„ Processus de découverte, de raffinement, de „ Écouter le client
modélisation et de spécification „ Écoute ≠ Compréhension
„ Les utilisateurs/clients et les développeurs ont des „ Préparer les réunions
rôles actifs „ Connaissance du client et des contacts
„ Les utilisateurs ne sont pas satisfaits par un „ Lecture des documents disponibles
système bien conçu et bien implémenté „ Penser aux objectifs de la réunion
Les utilisateurs veulent des systèmes „ Penser aux problèmes
Être à l’heure…
qui satisfont leurs besoins „

P. Collet 43 P. Collet 44

11
 Initier la communication Une bonne analyse
„ La première réunion peut être bizarre „ Objectif premier : Maximiser la satisfaction des
„ Pas de connaissance des intervenants
„ Attentes différentes utilisateurs et des clients
„ Mais : chacun veut que cela réussisse

„ Compréhension minimale du problème : „ En tenant compte de 3 types de besoin

„ Qui est derrière la demande de cette réalisation ?
„ Qui va utiliser la solution proposée ? Avec quels bénéfices ? „ Normaux : besoins explicitement établis
„ Quelle serait une “bonne” solution ?
„ Quel sera l’environnement de la solution ? „ Attendus : implicites, pas exprimés mais nécessaires
„ Y-a-t-il des contraintes ? Des problèmes de performance ? „ Excitants : allant au delà des espérances des clients
„ Qui sont les bons interlocuteurs ? => réponses “officielles”
„ Ai-je oublié des questions ?
„ A qui d’autre dois-je m’adresser ?
P. Collet 45 P. Collet 46

Indications à suivre... Le cahier des charges

„ Comprendre le problème avant de commencer à créer la „ Première étape de l’expression du besoin
spécification des besoins
„ Description globale des fonctions d’un nouveau
Ne pas résoudre le mauvais problème
„
produit ou des extensions à un produit existant
„ Développer des prototypes des interfaces utilisateurs (IHM) „ Énoncé du problème à résoudre
„ Les interfaces utilisateurs déterminent souvent la qualité… „ Liste des fonctions de base
Caractéristiques techniques
Noter et tracer l’origine et les raisons d’un besoin
„
„
„ Priorités de réalisation
„ Utiliser des vues multiples sur les besoins „ Facteurs de qualité
„ Réduit les risques de rater quelque chose „ Il doit être validé par le client et/ou l’utilisateur
„ Classer les besoins par priorité „ Il est la base du contrat entre clients et
„ Travailler pour éliminer les ambiguïtés développeurs
P. Collet 47 P. Collet 48

12
 Contrer les problèmes du
Difficultés à établir le cahier langage naturel
„ Expression de la faisabilité „ Imprécisions et ambiguïtés qui devront être
„ utiliser une maquette pour simuler levées lors de la phase d’analyse
)Scinder le texte en paragraphes pour une meilleure
„ Précision et non ambiguïté traçabilité
„ utiliser un formalisme différent du langage naturel ? )Ne pas inclure plusieurs concepts dans un même
paragraphe
„ Le cahier des charges est un document technique,
)Ne pas mélanger :
sans considération économique
„ Besoins : ce qui doit être fourni
„ sauf si on lui adjoint un plan de projet „ Buts : souhait, vœu pieu, mais impossible à tester
„ Recherche de précision, cohérence, complétude, „ Contraintes : qui doivent être décrites séparément
testabilité, traçabilité, maintenabilité, flexibilité...
P. Collet 49 P. Collet 50

Les besoins non-fonctionnels Cahier des charges épuré

„ Restrictions ou contraintes sur un service fourni „ Couverture
par le système :
„ Introduction
„ plate-forme matérielle
„ temps de réponse „ Spécification des besoins fonctionnels
„ MTBF : Mean Time Between Failures „ Spécification des besoins non fonctionnels
„ Raisons : „ Standards à atteindre, plate-forme, taille mémoire
„ besoins des utilisateurs
„ Glossaire
„ contraintes de budget, …

)Ces besoins doivent être quantifiables !

P. Collet 51 P. Collet 52

13
 Un plan type
Couverture : norme AFNOR X50-151
1. Présentation générale du problème
„ Nom du projet / du produit 1.1 Projet
1.1.1 Finalités
1.1.2 Espérance de retour sur investissement
„ Date 1.2 Contexte
1.2.1 Situation du projet par rapport aux autres projets d e l’entreprise
„ Numéro de version 1.2.2 Etudes déjà effectuées
1.2.3 Etudes menées sur des sujets voisins

„ Auteur(s) 1.2.4 Suites prévues

1.2.5 Nature des prestations demandées
1.2.6 Parties concernées par le déroulement du projet et ses résultats (demandeurs,
„ Responsabilités de chaque auteur utilisateurs)
1.2.7 Caractère confidentiel si il y a lieu
„ Changements clés depuis la précédente version 1.3 Enoncé du besoin (finalités du produit pour le futur utilisateur tel que prévu par le
demandeur)
1.4 Environnement du produit recherché
1.4.1 Listes exhaustives des éléments (personnes, équipements, matières…) et
contraintes (environnement)
1.4.2 Caractéristiques pour chaque élément de l ’environnement

P. Collet 53 P. Collet 54

Norme AFNOR X50-151 (suite) Norme AFNOR X50-151 (suite)

2. Expression fonctionnelle du besoin 3. Cadre de réponse
2.1 Fonctions de service et de contrainte 3.1 Pour chaque fonction
2.1.1 Fonctions de service principales (qui sont la raison d ’être du produit) 3.1.1 Solution proposée

2.1.2 Fonctions de service complémentaires (qui améliorent, facilitent ou 3.1.2 Niveau atteint pour chaque critère d ’appréciation de cette fonction et
modalités de contrôle
complètent le service rendu)
3.1.3 Part du prix attribué à chaque fonction
2.1.3 Contraintes (limitations à la liberté du concepteur-réalisateur)
3.2 Pour l ’ensemble du produit
2.2 Critères d ’appréciation (en soulignant ceux qui sont déterminants pour l ’évaluation
3.2.1 Prix de la réalisation de la version de base
des réponses)
3.2.2 Options et variantes proposées non retenues au cahier des charges
2.3 Niveaux des critères d ’appréciation et ce qui les caractérise
3.2.3 Mesures prises pour respecter les contraintes et leurs conséquences
2.3.1 Niveaux dont l ’obtention est imposée économiques
2.3.2 Niveaux souhaités mais révisables 3.2.4 Outils d ’installation, de maintenance … à prévoir
3.2.5 Décomposition en modules, sous-ensembles
3.2.6 Prévisions de fiabilité
3.2.7 Perspectives d’évolution technologique

P. Collet 55 P. Collet 56

14
 Cahier des charges / Plan projet : Cahier des charges / Plan projet :
Détails d’une réponse Détails...
Limites et interfaces
1. Introduction
„
„ „ Tout ce que le système pourrait faire implicitement, mais qu’il ne fera
„ Résumé (ou Objectifs) pas
„ une demi page pour aller à l ’essentiel avec vue d ’ensemble „ Toutes les interactions avec du matériel ou du logiciel extérieur, déjà
présent ou apporté par un autre fournisseur
„ Fournitures
„ liste de ce qui est livré au client (logiciel, matériel…) „ 3. Gestion
„ Définitions et acronymes „ Objectifs et priorités
„ explication de tous les termes spécifiques au projet ou „ Objectifs ? La qualité au meilleur prix et dans les délais !!!
techniques au sens informatique „ Priorités : Si on est en retard ou que cela doit coûter plus cher,
„ 2. Organisation du projet explication des propositions
„ Processus „ Hypothèses, dépendances, contraintes
„ Hypothèses : Tous les décisions prises arbitrairement par rapport à
„ décomposition du projet dans le temps, justification du modèle
l ’appel d ’offres
de développement utilisé
„ Dépendances : Identification des liens avec d ’autres systèmes
„ Organisation structurelle informatiques (Cf. limites et interfaces) ou des actions à entreprendre
„ les rôles de chaque acteur du développement „ Contraintes : Identification de certaines contraintes posées par
l ’existant ou par les besoins utilisateurs
P. Collet 57 P. Collet 58

Cahier des charges / Plan Cahier des charges / Plan projet :

projet : Détails... Détails...
Gestion du risque
„
„ 5. Calendrier, Budget
„ Solutions pour gérer les risques posés par les hypothèses, les
contraintes et les dépendances
„ Découpage en lots
„ Livraison intermédiaire et paiement intermédiaire
„ Moyens de contrôle
„ Dépendances
„ Description des moyens mis en œuvre lors du développement
„ Identification des dépendances qui peuvent influer sur le
pour assurer la qualité, la satisfaction du client, etc. calendrier (par exemple : attente d ’un élément spécifique par un
fournisseur ou le client lui-même)
„ 4. Technique
„ Ressources
„ Méthodes et outils employés „ Moyens mis en œuvre pour la réalisation (autres que les
„ Notation, outils de conception, développement, de gestion du ressources humaines)
projet, de gestion des sources, des configurations... „ Budget
„ Documentation „ Chiffrage complet et… l ’addition SVP !
„ Manière de gérer (et générer) la documentation tout au long du „ Échéancier
projet „ Calendrier déplié à partir d’une date précise de début

P. Collet 59 P. Collet 60

15
 Cahier des charges / Plan projet :
Détails... Revue de spécification : questions
„ 6. Fonctions du produit „ Interfaces importantes décrites ?
„ Une grande fonctionnalité
„ sous fonctionnalité „ Diagrammes clairs ? Texte supplémentaire nécessaire ?
„ opération…

„ description en quelques lignes de ce que réalise cette

„ Grandes fonctionnalités assurées ?
opération, pour l ’utilisateur, et éventuellement en interne si
cela est pertinent
„ Contraintes de conception réalistes ?
„ ... „ Risques technologiques considérés ?
Une autre grande fonctionnalité
„
„ Critères clairs de validation établis ?
„ ...
„ 7. Contraintes non fonctionnelles „ Y-a-t-il des incohérences, des omissions, des
„ plate-forme matérielle redondances ?
„ temps de réponse „ Le contact avec l’utilisateur est-il terminé / complet ?
„ annexes techniques : schémas matériels, architecture logicielle
pressentie...
P. Collet 61 P. Collet 62

Notion de cycle de vie

„ Description d’un processus pour :
Cycle de vie du logiciel „ la création d ’un produit
„ sa distribution sur un marché
„ son retrait
„ Les phases du cycle de vie „ Cycle de vie et assurance qualité
„ Les modèles de développement „ Validation : le bon produit ?
„ Vérification : le produit correct ?

P. Collet 63 P. Collet 64

16
 Les phases du cycle de vie Objectifs
Retrait ou „ Fixés par les donneurs d’ordre
Objectifs
remplacement
„ le management
Définition
des besoins Maintenance „ ou une (bonne) idée...

Analyse Mise en
des besoins exploitation „ Quelques définitions
„ Clients : ceux qui veulent le produit
Qualification
Planification
„ Utilisateurs : ceux qui vont l ’utiliser
Validation et
Conception Implémentation „ Développeurs : ceux qui vont le fabriquer
Intégration
et tests unitaires
P. Collet 65 P. Collet 66

Définition des besoins Analyse des besoins

„ Un cahier des charges est normalement établi par „ C’est la définition du produit
le client en interaction avec utilisateurs et „ Spécification précise du produit
encadrement : „ Contraintes de réalisation

„ description des fonctionnalités attendues „ A l ’issue de cette phase :

„ contraintes non fonctionnelles (temps de réponse, „ Client et fournisseur sont d ’accord sur le produit à
place mémoire,...) réaliser (IHM comprise)
)Dossier d’analyse (spécifications fonctionnelles
„ possibilités d’utilisation de Use Cases
et non fonctionnelles)
)Ébauche de manuel utilisateur
) A l ’issue de cette phase : cahier des charges
)Première version du glossaire du projet
P. Collet 67 P. Collet 68

17
 Planification Conception
„ Découpage du projet en tâches avec enchaînement „ Définition de l’architecture du logiciel
„ Affectation à chacune d’une durée et d’un effort „ Interfaces entre les différents modules
„ Définition des normes qualité à appliquer „ Rendre les composants du produits indépendants
„ Choix de la méthode de conception, de test... pour faciliter le développement
„ Dépendances extérieures (matériels, experts…)
) Dossier de conception
) Plan qualité + Plan projet (pour les développeurs) ) Plan d ’intégration
) Estimation des coûts réels ) Plans de test
) Devis destiné au client (prix, délais, fournitures) ) Mise à jour du planning
P. Collet 69 P. Collet 70

Implémentation et tests unitaires Validation et Intégration

„ Chaque module est intégré avec les autres en
„ Codage et test indépendant de chaque module
suivant le plan d ’intégration
„ Produits intermédiaires :
„ L’ensemble est testé conformément au plan de
)Modules codés et testés tests
)Documentation de chaque module )Logiciel testé
)Résultats des tests unitaires )Tests de non-régression
)Planning mis à jour )Manuel d’installation
)Version finale du manuel utilisateur

P. Collet 71 P. Collet 72

18
 Qualification Mise en exploitation
„ Tests en vraie grandeur, dans des conditions „ Livraison finale du produit (packaging)
normales d’utilisation „ Installation chez le client
„ Tests non-fonctionnels : „ Est-ce la fin des problèmes ?
„ Tests de charge
„ Tests de tolérance aux pannes
„ Parfois Bêta-test )AU CONTRAIRE
)Rapports d’anomalie )Ce n’est rien en comparaison de la...
„ Déterminant dans la relation client-fournisseur

P. Collet 73 P. Collet 74

Maintenance Exemples de durée de cycle

„ Rapport d’incident (ou anomalie) „ SGBD relationnel „ Langage ADA (1983)
1er proto : 5 à 7 ans „ Définition et analyse
Demande de modification corrective
„
„
Investissement > 100H An
des besoins : 3 ans
„ Demande d’évolution (avenant au contrat) „ Compilateur industriel :
„ 1er système
Code et documentation modifiés... 3ans
„ commercial : 3 à 4 ans
Investissement > 50H An
„ Nouvelle série de tests : Investissement > 150H An
„ Maintenance : > 15
„ unitaires „ Maintenance : > 10 ans
ans 5 à 10 H par an
„ d ’intégration
10 à 15 H par an livraison tous les 1 ou 2 ans
„ de non-régression
nouvelle livraison tous les 6 ) Nouvelle version :
mois à 1 an Ada95
P. Collet 75 P. Collet 76

19
 Modèle en cascade (1970)
Les approches de développement
Analyse des besoins
„ Approche cartésienne, déterministe vérification
Specif. fonctionnelles vérification Changement
vérification dans l’expression
„ structurée descendante : cascade ou V Planification des besoins
vérification
„ Approche heuristique, par prototypage Conception
vérification
„ ascendante : incrémental ou prototypage Implémentation
tests unitaires
Intégration
„ Approche objets : tests
Qualification
„ aucune organisation spécifique n’est vraiment tests

mise en avant Exploitation

Retrait
P. Collet 77 P. Collet 78

Problèmes du modèle en cascade Modèle en V

Définition des tests
„ Les vrais projets suivent rarement un Spécifications fonctionnelles
& planification
Qualification

développement séquentiel Définition du plan

Conception d ’intégration
Intégration
„ Établir tous les besoins au début d’un projet globale

est difficile
Conception Tests
détaillée unitaires
„ Le produit apparaît tard
„ Seulement applicable pour les projets qui sont Programmation

bien compris et maîtrisés

) Gestion des configurations, de projet, plan assurance
qualité
P. Collet 79 P. Collet 80

20
 Comparaison Prototypage
„ Le cycle en V construire /
Écoute du améliorer
„ permet une meilleure anticipation client la maquette
„ évite les retours en arrière
„ Mais
„ le cadre de développement est rigide Le client
essaie
„ la durée est souvent trop longue la maquette
„ le produit apparaît très tard
P. Collet 81 P. Collet 82

Prototypage, RAD Prototypage, RAD (suite)

RAD : Rapid Application Development „ Mais :
„ Discuter et interagir avec l’utilisateur „ Les objectifs sont uniquement généraux
Prototyper n’est pas spécifier
Vérifier l ’efficacité réelle d ’un algorithme
„
„
„ Les décisions rapides sont rarement de bonnes
„ Vérifier des choix spécifiques d ’IHM décisions
„ Souvent utilisé pour identifier les besoins „ Le prototype évolutif donne-t-il le produit demandé ?
„ Prototype jetable (moins de risque ?) „ Les générateurs de code produisent-ils du code assez
efficace ?
„ Souvent implémenté par des générateurs de code
„ Prototype évolutif ) Projets petits ou à courte durée de vie
P. Collet 83 P. Collet 84

21
 Modèle incrémental Le développement incrémental
Analyse des besoins „ combine des éléments des modèles linéaires et du
vérification prototypage
Spécif. & Planification
vérification „ produit des incréments livrables
Concept. globale
vérification
„ se concentre sur un produit opérationnel (pas de
prototype jetable)
Incrément N
„ peut être utilisé quand il n’y a pas assez de
conception détaillée, ressources disponibles pour une livraison à temps
codage, tests uni.,
intégration, livraison
)Le premier incrément est souvent le noyau
Exploitation
)Les incréments aident à gérer les risques
Retrait techniques (matériel non disponible)
P. Collet 85 P. Collet 86

Modèle en spirale (Boehm, 1988) Modèle en spirale (suite)

„ Spécification : communiquer avec le client
„ Analyse de risque : évaluation des risques
techniques et des risques de gestion
„ Implémentation et vérification : construire,
tester, installer et fournir un support utilisateur
„ Validation: obtenir des retours
„ Planification : définir les ressources, la répartition
dans le temps

P. Collet 87 P. Collet 88

22
 RUP : Rational Unified Process
Modèle en spirale (suite) Phases
Analyse
Élaboration Construction Transition

Couplage de la nature itérative du prototypage avec

des besoins
„ Processus projet
Processus organisationnels
les aspects systématiques et contrôlés du modèle en Spécifications

cascade
Analyse & Conception
Implémentation
Tests
„ Les premières itérations peuvent être des modèles Déploiement

sur papier ou des prototypes Support du projet

Configuration

Utilisation possible tout au long de la vie du produit

Gestion du projet
„ Environnement
Itération Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Préliminaire #1 #2 #n #n+1 #n+2 #m #m+1

)Réduit les risques si bien appliqué ƒ Promu par Rational

Itérations

)Les augmentent considérablement si le contrôle ƒ Le RUP est à la fois une méthodologie et un outil prêt à
l’emploi (documents types partagés dans un référentiel
faiblit Web)
ƒ plutôt pour des projets de plus de 10 personnes
P. Collet 89 P. Collet 90

2TUP : Two Track Unified Process eXtreme Programming (XP…)

ƒ Ensemble de « Bests Practices » de développement 4 Valeurs
(travail en équipes, transfert de compétences…) ƒ Communication
ƒ S’articule autour ƒ Simplicité
ƒ plutôt pour des projets de moins de 10 personnes
de l’architecture ƒ Feedback
ƒ Courage
ƒ Propose un cycle
de développement
en Y
ƒ Détaillé dans
« UML en action »
ƒ pour des projets
de toutes tailles

P. Collet 91 P. Collet 92

23
 XP => Développement Agile Manifeste Agile : 12 principes
„ Collaboration étroite entre équipe(s) de 1. Our highest priority is to satisfy the costumer through early and
continuous delivery of valuable software.
programmation et experts métier 2. Welcome changing requirements, even late in development. Agile
process harness change for the customer´s competitive advantage.
„ Communication orale, pas écrite 3. Deliver working software frequently, from a couple of weeks to a
„ Livraison fréquente de fonctionnalités couple of months, with a preference to the shorter timescale.
déployables et utilisables (= qui apportent une 4. Business people and developers must work together daily throughout
the project.
valeur ajoutée) 5. Build projects around motivated individuals. Give them the
„ Equipe auto-organisée et soudée environment and support they need, and trust them to get the job
done.
„ Test-Driven Development 6. The most efficient and effective method of conveying information to
and within a development team is face to face conversation.
„ Ecrire les tests avant le code…

P. Collet 93 94

Manifeste Agile : 12 principes Scrum : principes

7. Working software is the primary measure of progress „ Isolement de l'équipe de développement
8. Agile processes promote sustainable development. The sponsors, „ l'équipe est isolée de toute influence extérieure qui pourrait lui nuire. Seules
l'information et les tâches reliées au projet lui parviennent : pas d’évolution des
developers, and users should be able to maintain a constant pace besoins dans chaque sprint.
indefinitely „ Développement progressif
9. Continuous attention to technical excellence and good design „ afin de forcer l'équipe à progresser, elle doit livrer une solution tous les 30 jours.
Durant cette période de développement l'équipe se doit de livrer une série de
enhances agility
fonctionnalités qui devront être opérationnelles à la fin des 30 jours.
10. Simplicity – the art of maximizing the amount of work not done – is „ Pouvoir à l'équipe
essential „ l'équipe reçoit les pleins pouvoirs pour réaliser les fonctionnalités. C'est elle qui
11. The best architectures, requirements, and designs emerge from self- détient la responsabilité de décider comment atteindre ses objectifs. Sa seule
contrainte est de livrer une solution qui convienne au client dans un délai de 30
organizing teams jours.
12. At regular intervals, the team reflects on how to become more „ Contrôle du travail
effective, then tunes and adjusts its behavior accordingly „ le travail est contrôlé quotidiennement pour savoir si tout va bien pour les
membres de l'équipe et à la fin des 30 jours de développement pour savoir si la
solution répond au besoin du client.

95 96

24
 Comparaison des 3 processus dans le vent
Scrum : rôles et pratiques Points forts Points faibles
„ Itératif „ Coûteux à personnaliser
„ Scrum Master „ Product Backlog
„ Spécifie le dialogue entre les différents
„ expert de l’application de Scrum „ état courant des tâches à accomplir
intervenants du projet : les livrables, les „ Très axé processus, au détriment du
„ Product owner „ Effort Estimation RUP plannings, les prototypes… développement : peu de place pour le code et
„ responsable officiel du projet „ permanente, sur les entrées du backlog „ Propose des modèles de documents, la technologie
„ Scrum Team „ Sprint et des canevas pour des projets types
„ équipe projet. „ itération de 30 jours
„ Itératif „ Ne couvre pas les phases en amont et en
„ Customer „ Sprint Planning Meeting „ Simple à mettre en œuvre aval au développement : capture des besoins,
„ participe aux réunions liées aux „ réunion de décision des objectifs du support, maintenance, tests d'intégration…
„ Fait une large place aux aspects
fonctionnalités prochain sprint et de la manière de les
implémenter XP techniques : prototypes, règles de „ Élude la phase d'analyse, si bien qu'on peut
„ Management développement, tests… dépenser son énergie à faire et défaire
prend les décisions „ Sprint Backlog
„ Innovant: programmation en duo… „ Assez flou dans sa mise en œuvre: quels
„

Product Backlog limité au sprint en cours

„
intervenants, quels livrables ?
„ Daily Scrum meeting „ Itératif „ Plutôt superficiel sur les phases situées en
ce qui a été fait, ce qui reste à faire, les
Fait une large place à la technologie et amont et en aval du développement : capture
„
„
problèmes
2TUP à la gestion du risque des besoins, support, maintenance, gestion
„ Sprint Review Meeting du changement…
„ Définit les profils des intervenants, les
„ présentation des résultats du sprint „ Ne propose pas de documents types
livrables, les plannings, les prototypes
97 P. Collet 98

Les différents types de projet

Durée Personnes Budget Approche
Documentation a posteriori
<à1 < 100
1 Validation par le développeur

Conduite de Projet
an K€ Vie limitée
Plusieurs phases (dont conception)
Env. 1 < 300 à Planning, réunions d’avancement
1à5 Contrôle qualité interne et gestion de versions
an 500 K€
Prototypage „ Gestion d’un projet
Etudes préliminaires et cycle en spirale
1à2
6 à 15 < 5 M€
Documents de suivi et d’anomalie, inspections
Gestion de configurations
„ Ce qu’il ne faut pas faire
ans
Plans de validation et d’intégration
Procédures de communication
„ Planification : PERT et Gantt
2 ans
Recettes intermédiaires
Contrôle qualité permanent „ Estimation des coûts, métriques
16 et plus > 5 M€
Organisation du travail
et plus Gestion des sous-projets et de la sous-traitance
Tests de non-régression „
Effort de synthèse et base historique
P. Collet 99
P. Collet 100

25
 Les 3 P ˆ

ˆ
formation
compétences
Génie logiciel gestion de projet
communication
ˆ
„ Beaucoup de problèmes de développement
Personnes logiciel sont des problèmes de gestion
ˆ cahier des
ˆ planification charges (management)
ˆ coordination ˆ conception
gestion „ Estimation des coûts
ˆ ˆ code source
ˆ mesures ˆ exécutable „ Estimation des durées, des délais
ˆ analyse documentation
ˆ
„ Ordonnancement des tâches
ˆ conception utilisateur
ˆ implémentation ˆ cas de test „ Gestion des changements
résultats des
Processus Produitsˆ
tests
„ Contrôle des versions et gestion des configurations
ˆ demande de
changement
P. Collet 101 P. Collet 102

Objectifs et décomposition Les tâches de gestion

„ Gestion de projet = „ Modélisation des tâches
planification, organisation, gestion des tâches et Planification
„ Ordonnancement
des ressources pour accomplir un but défini
„ Quoi, qui, quand, combien „ Gestion des ressources
„ Comment ? „ Gestion du risque
„ Les différentes phases de la conduite d’un projet : „ Gestion des changements
„ Planification du projet
„ Évaluation et ordonnancement des tâches „ Gestion des configurations
„ Contrôle et analyse de l’avancement „ Gestion de la qualité
„ Communication des informations relatives au projet
P. Collet 103 P. Collet 104

26
 Planification des tâches Suivi de la planification
„ Définir les activités constituant le projet „ Réaliser des réunions d’avancement du projet de
„ Détecter les jalons (milestones) du projet façon périodique
„ événements significatifs dans le projet
„ Évaluer les résultats de toutes les revues
„ Évaluer les dépendances entre activités
„ Déterminer si les jalons du projet ont été atteints
„ Ordonnancer les activités en conséquence
„ Évaluer l’effort nécessaire pour chaque activité „ Comparer les dates de fin réelles et prévues
„ durée minimum et maximum „ Discuter avec les gens (!)
„ Affecter les ressources nécessaires aux tâches
„ S’assurer de la bonne répartition des ressources
P. Collet 105 P. Collet 106

Gestion des ressources Gestion du risque

„ Contrôler et analyser la quantité de travail „ Identification du risque
effectué par chaque personne, avec les „ Quantification du risque
implications matérielles
„ Résolution du risque
„ Participation à plusieurs projets en même temps
„ Réserver du temps pour surmonter les
„ Délégation et distribution des responsabilités
problèmes
„ Conserver une trace du coût des ressources
„ Définir les tâches de façon à réduire les risques
„ Effectuer un planning de la disponibilité des
ressources
„ Plans d’urgence

P. Collet 107 P. Collet 108

27
 Gestion de
Gestion des changements configurations
Demande de changement „ Projets, packages,
classes
Identifier l’objet du changement
„ Propriétaire,
Estimer le coût du changement
membres d’un
Déterminer si, et quand le changement doit être appliqué groupe
Mettre en place un plan d’implémentation du changement
„ Version &
Publication
Mettre en œuvre le plan (release)
P. Collet 109 P. Collet 110

Pourquoi les projets sont-ils

Gestion de la qualité toujours en retard ?
„ Paradigme d’amélioration de la qualité „ Dates limites irréalistes, imposées par des
éléments externes
„ Plan de gestion de la qualité „ Changements de besoin non répercutés dans la
„ Plans de test planification
„ Gestion des risques abordant les risques „ Sous-estimation de l’effort nécessaire
techniques du produit à livrer „ Risques mal ou non considérés
„ Manque de communication entre les membres de
„ Plans de revue
l’équipe
„ Plans de mesure „ Les gestionnaires ne se rendent pas compte que
le projet est en retard par rapport au planning
P. Collet 111 P. Collet 112

28
 Que peut-on faire contre les
limites irréalistes ? Les plus mauvaises approches
„ Vous ne pouvez pas les modifier „ Rassemblement de vantards
„ Vous ne pouvez pas refuser de faire le travail „ Décisions technologiques influencées par d’éminentes
)Réaliser des estimations détaillées personnes, des magazines, etc.
)Essayer d’utiliser des modèles incrémentaux „ Mort par planification intensive
)Définir les fonctionnalités critiques „ Une planification excessive entraîne des plannings
)Reporter les autres fonctionnalités à des phases complexes qui vont causer des problèmes en aval
ultérieures
„ “On ne peut pas commencer tant qu’on n’a pas un plan
)Expliquer au client pourquoi vous ne pouvez pas
d’implémentation complet”
respecter la date limite (en utilisant les estimations
basées sur les performances de projets passés)
P. Collet 113 P. Collet 114

Les plus mauvaises approches Les plus mauvaises approches

„ Paralysie analysatoire „ Conflits permanents
„ La recherche de la perfection et de la complétude dans
les phases d’analyse entraîne un ralentissement du „ Les gens difficiles ralentissent et font diverger
projet le processus de développement logiciel
„ “On doit refaire cette analyse pour la rendre plus „ “Pourquoi est-il si difficile de travailler avec
orientée objet, et utiliser beaucoup plus l’héritage pour Maurice ?”
obtenir beaucoup de réutilisation.”
„ Violence intellectuelle
„ Il n’existe pas de méthode évidente pour identifier le
niveau de détail exact nécessaire à la conception d’un „ Utilisation de la connaissance pour intimider
système informatique
d’autres personnes lors des réunions
P. Collet 115 P. Collet 116

29
 Les plus mauvaises approches Problèmes de gestion
„ Gestion irritante „ Mauvaise gestion
„ Indécision permanente „ Pas de direction à cause d’une minimisation ou
d’un oubli des activités clés et des risques
„ “Bon, et qu’est qu’on fait maintenant ?” „ “Que s’est-il passé ? Tout allait bien et puis
„ “Il faudrait régler ça avec les gens du tout d’un coup… BOOM !”
management avant de commencer.” „ Un petit peu de Freud
„ Power to salesmen ! „ Conflits de personnalité au sein de la direction,
entre les chefs de projet, etc.
„ L’équipe de direction s’engage sur des délais
„ Les e-mails sont dangereux
au delà des capacités de l’organisation
„ Ils ne remplacent jamais les réunions
P. Collet 117 P. Collet 118

Décomposition structurée des activités Exemple de WBS

„ WBS : Work Breakdown Structure
Activités de
Gestion Maintenance
„ Décomposition sous forme arborescente développement
1000 2000 3000
„ purement statique (pas d ’ordonnancement)
„ Décomposer jusqu’à obtenir des activités bien
Définition des Définition des Préparation
définies et faciles à gérer objectifs besoins
Développement
recette
2100 2200 2300 2400
„ entrées et résultats parfaitement identifiés
„ responsabilité confiée à des personnes précises ˆ Décomposition optimale lorsque :
„ Identification rapide des activités critiques ) la durée d’une activité est maîtrisée
) la connaissance des ressources requises est totale
„ Identification des besoins de sous-traitance
) le coût de l’activité est évaluable
P. Collet 119 P. Collet 120

30
 Caractéristiques de la WBS Graphe PERT
„ Elle permet au chef de projet d’établir le graphe „ PERT: Program Evaluation and Review Technique
PERT et de faire un suivi budgétaire
„ doit être complète, pour élaborer un graphe PERT correct „ Graphe de dépendances, pour l’ordonnancement
„ doit être non ambiguë, pour budgéter correctement le „ Pour chaque tâche, on indique une date de début et de
projet et contrôler les coûts par la suite fin, au plus tôt et au plus tard
„ les résultats des activités doivent être mesurables pour „ Le diagramme permet de déterminer le chemin critique
évaluer l’avancement général qui conditionne la durée minimale du projet

„ Certaines activités sont toujours présentes :

) Techniques fortement appliquées en BTP
„ élaboration des documents, inspections...
) Projets à plusieurs équipes => PERT à plusieurs niveaux
„ construction d’outils, apprentissage...
P. Collet 121 P. Collet 122

PERT : calcul des dates au plus

Graphe PERT-flèche : exemple tôt
(2,5) (9,15)
DTO FTO A1 A4 A1 A4
(0,0) 3 6 (0,0) 3 6
(15,15)
(5,9)
Début Début
A3 Fin A3 Fin

(0,0) 4 (0,0) 4
DTA FTA (0,2) (9,13)
A2 A5 A2 A5
2 4 2 4

ƒ Estimation de la durée des tâches : ni optimiste, ni pessimiste ƒ Partant du début, calcul « aller » de la gauche vers la droite :
) DTO : date de début au plus tôt ƒ pour une tâche, la durée de début au plus tôt est égale à la plus grande
) FTO : date de fin au plus tôt des dates de fin au plus tôt des tâches qui la précèdent
) DTA : date de début au plus tard ƒ FTO = DTO + durée
) FTA : date de fin au plus tard ) Délai de réalisation du projet
P. Collet 123 P. Collet 124

31
 PERT : calcul des dates au plus
tard PERT : marges et chemin critique
(2,5) (9,15) (2,5) (9,15)
A1 A4 A1 A4
(0,0) 3 6 (0,0) 3 6
(2,5) (9,15) (15,15) (15,15)
(5,9) (2,5) (5,9) (9,15)
Début Début
A3 Fin A3 Fin
(0,0) 4 (0,0) 4
(0,2) (9,13) (15,15) (0,2) (9,13)
(5,9) (5,9) (15,15)
A2 A5 A2 A5
2 4 2 4
(0,2) (11,15) (0,2) (11,15)

ƒ Partant de la fin début, calcul « retour » en sens inverse : ƒ Durée maximum d’une tâche = FTA -DTO
) pour une tâche, la durée de fin au plus tard est égale à la plus petite ƒ Marge totale d’une tâche = FTA - FTO
des dates de début au plus tard des tâches qui lui succèdent ) Une tâche est critique si sa durée est égale à sa durée maximum
) DTA = FTA - durée ) Le chemin critique est le plus long, où toutes les tâches sont critiques
P. Collet 125 P. Collet 126

Diagramme de Gantt Diagramme de Gantt (suite)

„ Son but est de faire apparaître „ Il faut d’abord estimer les durées et les ressources
„ la répartition des activités dans le temps, „ Pour harmoniser le diagramme de Gantt, il faut
„ l’affectation des individus. utiliser la même unité de temps
„ Il donne une description détaillée
„ Les ressources peuvent être humaines ou matérielles
„ des coûts (en hommes*mois),
„ des dates pour chaque tâche et pour chaque phase. „ Après avoir ordonnées les tâches à l’aide d’un PERT :
en abscisse, l’échelle des temps
„ A chaque tâche sont attribués „

„ un objectif pour repérer la terminaison de l’activité „ en ordonnée, la liste des tâches

„ une durée pour atteindre cet objectif „ des rectangles sont tracés proportionnellement à la durée
„ des ressources nécessaires à son accomplissement de la tâche, avec l ’affectation des ressources nécessaires

P. Collet 127 P. Collet 128

32
 Gantt : exemple Évaluation des coûts et durées
„ Analogie avec des projets déjà achevés
„ Expertises et retours sur expérience
„ Décomposition du projet pour estimation
)Modélisation du processus (Cf. CMM plus loin)

)Effectuer des mesures Métriques du logiciel

„ utilisées pour prédire les besoins du projet (personnel,
effort total, …)

P. Collet 129 P. Collet 130

Rôles des mesures Problèmes des LOC (Lines Of Code)

„ Estimation „ Le code n’est qu’une petite partie du développement
Déterminer les besoins vraisemblables en ressource
Que compte-t-on effectivement ?
„
„
„ Prédiction „ Commentaires, lignes vides, code non livré
„ Déterminer les valeurs vraisemblables des mesures
„ Dépendances fortes vis-à-vis des langages, des
„ Évaluation
„ Comparer les mesures aux valeurs prédéterminées applications, des développeurs...
„ Comparaison „ La complexité du code n’est pas exprimée
„ Prendre des décisions pour des compromis „ Cela encourage de gros volumes de code
„ Investigation
„ Cela ne prédit ni la qualité, ni l’avancement
„ Soutenir ou réfuter les hypothèses
„ Le comptage est forcément effectué a posteriori
P. Collet 131 P. Collet 132

33
 Métrique de taille des applications
Métrique de taille : Points de fonction orientées objets
„ IBM (1979) „ Table de correspondance Lorenz, Kidd: Object-oriented software metrics, Prentice Hall,
pour plus de 500 langages 1994
„ Valeurs connues tôt dans le
„ Nombre de cas d’utilisation
cycle de vie, indépendante
„ Nombre de classes
des langages
„ Nombre de classes clé
„ Paramètres + coefficients ) Marge d ’erreur : 200 % „ Un client considérerait-il cette classe comme importante ?
(nb d ’entrées, sorties…) (contre 800% pour LOC) „ Découvert tôt dans le projet
„ Ne pas prendre en compte : IHM, communication, exception
„ Facteur de complexité ) Projets orientés gestion „ Nombre de classes support
„ Degré d ’influence ) Feature points pour les „ Indicateur du volume de travail

„ version 3 en 1990, projets industriels „ Nombre moyen de classes support par classes clé
„ Intensif IHM : 2-3 x le nombre de classes clé
version 4 en fin d’évaluation
P. Collet 133 P. Collet 134

Estimation des coûts : COCOMO COCOMO 81

„ COnstructive COst MOdel (Boehm, 1981) „ COCOMO 81 : projets traditionnels
„ Coût en nombre d’hommes*mois (MM) „ réalisé à partir d ’une étude sur 63 projets de 2000 à
„ Temps de développement (TDEV) 100000 LOC, dans l ’entreprise TWR
„ Modèle de régression
„ basé sur un historique de projets logiciels „ COCOMO dispose de trois niveaux de modèles :
„ avec analyse des données par régression „ Modèle de base (ou simplifié)
„ et relation mathématiques entre les variables „ Modèle intermédiaire
„ Fonction de la prévision du nombre de milliers „ Modèle détaillé
d’instructions sources livrées (KDSI)
P. Collet 135 P. Collet 136

34
 COCOMO : modèle de base COCOMO : des formules
„ Estimation de l ’effort (MM) en fonction des LOC
et d ’un facteur d ’échelle qui dépend du projet Projet MM TDEV
„ 3 types de projet sont identifiés :
„ organique : innovation minimale, organisation simple et Organique 2.4(KDSI)1.05 2.5(MM)0.38
petites équipes expérimentées (ex : petite gestion…)
„ médian (semi-detached) : degré d ’innovation
raisonnable (ex: banque, compilateurs…) Médian 3.0(KDSI)1.12 2.5(MM)0.35
„ imbriqué (embedded) : innovation importante,
organisation complexe, couplage fort et nombreuses
Imbriqué 3.6(KDSI)1.20 2.5(MM)0.32
interactions (ex : gros systèmes, avioniques...)

P. Collet 137 P. Collet 138

Exemples d’application des formules Formules déduites

„ Projet organique de 2 KDSI : „ Productivité (KDSI/MM):
„ effort de 5 hommes*mois, sur 4.6 mois „ organique et 2 KDSI donne 400
imbriqué et 512 KDSI donne 80
Projet médian de 32 KDSI :
„
„

„ effort de 146 hommes*mois, sur 14 mois

„ Projet imbriqué de 512 KDSI : „ Nombre moyen de personnes
(MM/TDEV):
„ effort de 6420 hommes*mois, sur 41 mois
„ organique et 2 KDSI donne 1.1
„ imbriqué et 512 KDSI donne 157

P. Collet 139 P. Collet 140

35
 Les hypothèses La distribution par phases
„ Le KDSI «livré» exclut en général les environnements „ Prise en compte de la distribution de l’effort
de tests, les supports de développement... et du temps par phase (en %)
„ Une instruction source exclut les commentaires, mais „ RPD: Requirements and Preliminary Design
inclut le shell „ DD: Detailed Design
„ Hommes*mois (MM) correspond à 152 heures „ CUT: Code and Unit Test
(normes américaines !) et tient compte des
„ IT: Integration and Test
vacances, arrêts maladie...
„ En fait, c’est même trop avec les 35 heures, mais…
„ TDEV correspond au temps entre spécifications ) des tableaux, encore des tableaux...
fonctionnelles et intégration
P. Collet 141 P. Collet 142

Exemple de distribution Limites du modèle de base

„ Projet organique et 2 KDSI „ Fondé, à la base, sur les statistiques d’une seule
„ Effort: RPD : 16%, DD : 26 %, CUT : 42%, IT : 16% entreprise
„ Temps: RPD : 19%, DD et CUT : 63 % ,IT : 18% „ Ne prends en compte que le nombre de lignes
source
„ Projet imbriqué et 512 KDSI „ alors que plus les programmeurs sont experts, moins
„ Effort: RPD : 18%, DD : 24 %, CUT : 24%, IT : 34% ils écrivent de code…
„ Temps: RPD : 38%, DD et CUT : 32 % , IT : 30% „ induit des discontinuités brutales entre chaque
phase (nombre de personnes)

P. Collet 143 P. Collet 144

36
 COCOMO : modèle médian COCOMO 2
„ Introduit 13 facteurs de coût (cost drivers) sur le „ COCOMO 2 (1998)
logiciel, le matériel, le personnel et le projet : „ pour les projets basés sur la réutilisation de
composants
„ Fiabilité requise
„ possibilité de recalibrage sur les données de
„ Volumes des données
l’entreprise
...
3 modèles :
„
„
„ Contraintes de temps d ’exécution
„ modèle de composition d ’application (GUI builder)
„ … „ modèle avant projet pour obtenir une estimation à
„ Contraintes de délais base de facteurs de coûts et des LOC
„ modèle post-architecture, à utiliser après le
développement de l ’architecture générale
P. Collet 145 P. Collet 146

Organisation du travail Les ressources humaines

„ En fonction de la nature des tâches, le nombre de „ Client „ Diriger l’équipe
Utilisateur
personnes et leur communication influent „
„ évaluer coûts et délais en
„ Management
différemment sur la durée de réalisation fonction des personnes
„ Chef de projet
„ ordonnancer les tâches
„ Analyste
bonne partition non partitionable communication complexe „ Architecte système „ contrôler
Durée Durée Durée
„ Concepteur „ motiver
„ Développeur „ anticiper les créateurs et les
„ Testeur résistants
„ Installateur „ former
Personnel Personnel Personnel „ Support
P. Collet 147 P. Collet 148

37
 Nécessité de la structuration Comment s’organiser
„ Les équipes doivent être structurées pour „ Petit groupe de „ Structuration forte
diminuer le temps passé à communiquer travail sans par le chef
La communication un chef de projet dirige
autorité définie
„
„
de 2 à 5 ingénieurs
„ améliore la compréhension du sujet „ travail par consensus „ un adjoint peut le
„ permet une plus grande mobilité dans le projet „ le travail de chacun est remplacer
celui de tous un contrôleur gère
„ mais „
programmes,
„ fait perdre du temps „ Le travail enrichit toute configurations et
l ’équipe documentation
„ peut nuire à la documentation, car les besoins de
communication externe sont plus faibles
)Le consensus est-il )Structure lourde
facile à trouver ?
P. Collet 149 P. Collet 150

Comment s’organiser (suite) Attention aux facteurs humains

„ 1 chef de projet „ 1 comité de direction „ Motivations individuelles vs. motivation collective
pour plusieurs pour plusieurs projets „ Relations entre membres de l’équipe
équipes „ le comité est composé de „ Relations avec l’extérieur (client, sous-traitant)
„ Le chef, son adjoint et le chefs de projets qui gèrent „ Dynamique du chef de projet
contrôleur gèrent directement plusieurs
projets
„ Formation permanente de l’équipe
plusieurs projets
„ Les équipes travaillent „ Les chefs de projets „ Les problèmes éventuels :
en consensus interne travaillent par consensus „ sur-spécialisation
pour les tâches „ Ils peuvent se remplacer à „ dé-responsabilisation
quotidiennes tout moment „ trop ou pas assez de niveaux dans l’organisation
P. Collet 151 P. Collet 152

38
 Assurance Qualité : définition
„ Mise en œuvre d ’un ensemble approprié de
dispositions préétablies et systématiques destinées
Assurance Qualité à donner confiance en l’obtention de la qualité
requise
AFNOR
„ Définition „ Les moteurs de la qualité logicielle
„ Business : retour sur investissement, analyse
„ Les normes ISO-9xxx coûts/bénéfices, aspects politiques
Technologie + outils logiciels + mesures
„ Les modèles CMM et CMMI „

„ Organisation du processus
„ Ressources humaines

P. Collet 153 P. Collet 154

Qualité du logiciel et contrôles Qu’est-ce qu’une norme ?

„ Qualité = adéquation aux besoins/spécifications „ Accords documentés contenant des spécifications
„ Qualité ≠ “excellence” ou “luxe” techniques ou autres critères précis
„ Le responsable du contrôle qualité dans une usine Orangina „ destinés à être utilisés systématiquement en tant que
assure que chaque bouteille satisfait les spécifications Orangina
„

„ n’essaye pas de produire un Orangina supérieur

règles, lignes directrices ou définitions de caractéristiques
pour assurer que les produits et processus sont aptes à
)But : Produire du logiciel de bonne qualité „

l’emploi
„ Contrôle de la qualité = Ensemble de
„ inspections
„ Pourquoi une normalisation internationale ?
„

„
revues
tests
V&V „

„
Pour éviter les obstacles techniques au commerce
ISO : (International Standards Organisation) : fédération
internationale des organismes nationaux de normalisation
pour assurer la qualité
„ Exemples : ISO 9000, DOD 2167A, IEEE, AFNOR
P. Collet 155 P. Collet 156

39
 ISO 9000 (1987, 1994) Le référentiel ISO 9000
„ Ensemble de référentiels de bonnes pratiques de management en „ Responsabilité de la direction „ Maîtrise des équipements de
matière de qualité „ Système qualité contrôle, de mesure et d’essais
Revue de contrat „ État des contrôles et essais
„ La certification atteste que le système qualité de l’entreprise est „

Maîtrise de la conception „ Maîtrise du produit non

conforme au référentiel ISO 9000 „

„ Maîtrise des documents conforme

Procédure par laquelle une tierce partie donne une assurance écrite qu'un
„

Achats „ Actions correctives et

produit, un processus ou un service est conforme aux exigences spécifiées „
préventives
dans un référentiel. „ Maîtrise du produit fini par le
client „ Manutention, stockage
„ 9001 : Exigences „ Enregistrements relatifs à la
„ Identification et traçabilité
„ Ensemble de directives que l’entreprise doit suivre qualité
„ Maîtrise du processus
„ 9004 : Lignes directrices pour l’amélioration „ Audits qualité internes
„ Contrôle et essais
Le référentiel contient 20 chapitres qui couvrent les principaux secteurs „ Formation
„
„ Maîtrise des équipements de
d’activités d’une entreprise et les phases de fabrication d’un produit contrôle, de mesure et d’essais „ Prestations associées
„ État des contrôles et essais „ Techniques statistiques
P. Collet 157 P. Collet 158

ISO 9000 : Des recommandations ISO 9000 : Mise en œuvre

„ Pour gérer la relation client-fournisseur „ Diagnostic de l’organisation :
„ Spécifications „ Audit des fonctions principales
„ rigoureuses, figées et complètes „ Apparition des non conformités
„ avant que le produit ne soit conçu „ L’organisation manque sûrement de formalismes…
„ Visibilité „ Attention, formalisme ne doit pas être synonyme de
lourdeur
„ fournitures intermédiaires
„ suivi constant du bon avancement du projet
)Plan de travail pour des actions rapides :
„ Gestion documentaire
„ Traçabilité „ Revue de contrat
„ pendant le développement „ Gestion de produits non conformes
„ en phase de maintenance „ Traçabilité
P. Collet 159 P. Collet 160

40
 ISO 9000 : Mise en œuvre (suite) ISO 9000 : Intérêts pour l’entreprise
„ Déterminer tous les processus inhérents aux „ En interne :
métiers de l’entreprise
„ Amélioration de la compétitivité (rationalisation)
„ depuis la prise de commande
„ jusqu’à la livraison du produit et la maintenance „ Diminution des coûts (réduction des défauts)

„ Intérêts directs : „ Démarche fédératrice pour le personnel

„ Les fonctions sont mieux définies (qui fait quoi) „ Vis-à-vis de l’extérieur :
„ Le processus est plus clair (il doit boucler)
„ Réponse aux exigences des donneurs d’ordres
„ Les procédures sont établies (reste à formaliser)

„ La circulation des documents est précisée

„ Forte communication externe
)Les points critiques apparaissent „ Possibilité de se démarquer de la concurrence

P. Collet 161 P. Collet 162

ISO 9001:2000 (évolution) Le modèle CMM

„ Pourquoi une évolution ? „ CMM= Capability Maturity Model
„ Gérer « l’après-certification » en entretenant la motivation des
acteurs de l’entreprise „ créé par Watts S. Humphrey (Software Engineering
„ Réorienter la certification vers la satisfaction client Institute, Carnegie Mellon)
„ Donner la priorité à l’efficacité des processus et non à la
conformité des procédures „ Objectifs :
Répondre à l’explosion de la certification dans le domaine des
Processus prévisibles
„
„
services
„ ISO 9001:2000 porte essentiellement sur les processus et „ Produit de qualité supérieure
n’est plus centrée sur le produit „ Meilleure organisation
„ Pourquoi ?
„ Parce que la gestion du processus est la seule chose qui marche
„ Ajout, étape par étape, de techniques de génie
(cf. CMM/CMMI) logiciel
P. Collet 163 P. Collet 164

41
 Un CMM, des CMMs CMM : principes
„ Un CMM est un modèle de référence de „ Comprendre l’état actuel (courant) du processus
bonnes pratiques dans un domaine de développement :
spécifique, afin de permettre d’améliorer le  Développer la vision souhaitée du processus
fonctionnement des équipes de travail ž Établir une liste des actions nécessaires pour
„ Chaque CMM peut différer selon améliorer le processus
„ La discipline Ÿ Produire un plan pour accomplir les actions
„ La structure nécessaires
„ L’étape de maturité   Attribuer des ressources pour exécuter le plan
¡ GOTO Étape 1
P. Collet 165 P. Collet 166

CMM : les niveaux de maturité Processus initial (niveau 1)

„ Pas de procédures formalisées, d’estimation des
Process Maturity Levels coûts, de plans de projet
Contrôle du „ Outils pas appliqués uniformément
processus „ Contrôle du changement laxiste
Mesures sur le processus
„ Actions clé :
„ Contrôles minimum de la gestion du projet
Définition du processus „ planification, responsabilités, engagements
„ Assurance qualité
Contrôle basique de la gestion „ Contrôle des changements

P. Collet 167 P. Collet 168

42
 Processus reproductible (niveau 2) Processus reproductible : actions clé
„ Fournit des contrôles sur l’établissement des plans et „ Établir un processus de groupe
les engagements „ Objectif constant : améliorer le processus
„ Est en accord avec les estimations „ Missions à plein temps pour le personnel
„ Établir une architecture du processus de
„ Problème : basé sur des expériences passées dans la
réalisation du même travail développement
„ description des activités techniques et de gestion
pour une bonne exécution du processus
„ Risques :
„ décomposition des tâches
„ nouveaux outils et méthodes
„ nouvelles sortes de produit „ Introduire des méthodes et
„ nouvelles personnes des technologies de
génie logiciel
P. Collet 169 P. Collet 170

Processus établi (niveau 3) Processus maîtrisé (niveau 4)

„ Fondations nécessaires à la progression „ Problème : Coûts de récupérations des données et
„ En cas de crise : les équipes suivent quand même le des mesures
processus ! „ Nécessité d’une définition précise
„ Question : Quelle est l’efficacité du processus ? „ les lignes de code peuvent varier par un facteur 100

„ Aucune mesure quantitative „ Utilisation de métriques

„ Actions clé :
„ Mettre en place un ensemble minimum
„ Actions clé :
de mesures „ Mettre en place une récupération
„ Établir une base de données du automatique
processus et fournir des „ Analyser les données et
ressources pour la maintenir modifier le processus
P. Collet 171 P. Collet 172

43
 Optimisation du processus (niveau 5) De CMM à CMMI
„ De nouveau : analyser les données pour „ Le succès du CMM « logiciel » a entraîné la
déterminer les améliorations possibles création d’autres CMMs :
„ People, System Engr, System Security…
„ Leurs différences de structure et de niveaux de
„ Mais maintenant, les données sont maturité rendent complexes leur utilisation
disponibles pour justifier l’application de combinée
CMMI : CMM Integrated
technologies appropriées à diverses „

„ Ensemble de base de CMMs intégrés

tâches critiques „ Fondé sur les meilleurs CMMs existants
„ Ouvert à l’intégration de nouveaux CMMs

P. Collet 173 P. Collet 174

Principes du CMMI
„ Vue structurée de l’amélioration du processus à
l’intérieur d’une organisation
„ Quelques outils du CMMI Vérification et Validation
„ Des Modèles sur 4 disciplines (System Engineering,
Software Engineering, Integrated Product and Process „ Principes
Development, Supplier Sourcing)
„ Des méthodes d’évaluation
„ Approches statiques
„ Des méthodes de formation „ Approches dynamiques
„ Bénéfices ? „ Intégration
„ De l’amélioration de processus partout !

P. Collet 175
P. Collet 176

44
 Contrôler la qualité Principes de V&V
„ Contrôle de la qualité = Ensemble d’inspections, de revues „ Deux aspects de la notion de qualité :
et de tests pour trouver des erreurs, des défauts…
„ Conformité avec la définition : VALIDATION
„ Idées préconçues :
„ Réponse à la question : faisons-nous le bon produit ?
„ La qualité ne peut être évaluée que lorsque le code est disponible
„ Contrôle en cours de réalisation, le plus souvent avec le client
„ La qualité ne peut être uniquement améliorée par la suppression
d’erreurs dans le code „ Défauts par rapport aux besoins que le produit doit satisfaire

„ Mais les produits intermédiaires sont contrôlables „ Correction d’une phase ou de l’ensemble : VERIFICATION
„ Prototypes / maquettes „ Réponse à la question : faisons-nous le produit correctement ?
„ Documents de spécification, de conception „ Tests
„ Code
„ Erreurs par rapport aux définitions précises établies lors des
„ Jeux de tests
phases antérieures de développement
P. Collet 177 P. Collet 178

Qualité et cycle de vie Terminologies

„ Les spécifications fonctionnelles définissent les „ Norme IEEE (Software Engineering Terminology)
intentions „ Erreur : commise par le développeur, entraîne un défaut
„ Valider la conformité aux besoins „ Défaut : imperfection dans le logiciel, pouvant amener une
„ Définir le plan qualité panne
„ A chaque vérification, on vérifie la conformité aux „ Panne : comportement anormal d’un logiciel
spécifications fonctionnelles par rapport aux
„ Classification des faits techniques (qualification) :
intentions
„ Non conformité : Erreur par rapport au cahier des charges
„ Lors de la phase de qualification, on valide le produit „ Défaut : Erreur car le comportement du logiciel est
„ par rapport aux besoins différent d’un comportement normal dans son contexte
„ par rapport aux performances requises „ Évolution : Demande de changement sans prise de garantie
P. Collet 179 P. Collet 180

45
 Problèmes Amplification des défauts (1)
„ Plus de 50 % des erreurs sont découvertes en
phase d’exploitation
„Le coût de réparation croit exponentiellement avec Erreurs passées à travers
Pourcentage
l’avancée dans le cycle de vie d’efficacité
)Contrôles tout au long du cycle de vie + Qualification Erreurs amplifiées 1:x de la
Erreurs de détection Erreurs passées
l’étape précédente d’erreurs à l’étape suivante
„ Problèmes lors des contrôles : Nouvelles erreurs générées
„ prééminence du planning sur la qualité
„ sous-estimation des ressources
„ par les développeurs (activité inutile ?)
„ par les dirigeants (budgets séparés pour développement et
maintenance !)
P. Collet 181 P. Collet 182

Nouvelle approche /
Amplification des défauts (2) amplification des défauts
Hypothèse : amplification 1:0.5 Hypothèse : amplification 1:0.5
Conception préliminaire Conception préliminaire
0 Conception détaillée 0 Conception détaillée
0 0% 10 10 Codage 0 50 5 5 Codage
10 5 0% 40 10 % 3 50 16
40 16
25 85 25 % 25
20 0% 8 50
25 25 %

Tests unitaires Tests unitaires

85 85 Tests d’intégration 25 25 Tests d’intégration
42 12
0 50 42 0 50 6
0 % 21 0 % 6
0 50 0 50
0 % 0 %

P. Collet 183 P. Collet 184

46
 V & V : les moyens Examen critique de documents
„ Statiques : „ Minimisation des „ Validation
problèmes d’interprétation Mauvaises interprétations des
Examen critique des documents : Inspections, revues
„
„
documents de référence
„ Analyse statique du code „ Point de vue indépendant du „ Critères de qualité mal
rédacteur appliqués
„ Évaluation symbolique „ Hypothèses erronées
„ Preuve „ Vérification
„ Quelle méthode pour
„ Dynamiques : „ Forme : respect des normes, examiner les documents ?
„ Exécution du code : Tests précision, non ambiguïté „ Pouvoir de détection
Fond : cohérence et „ Coût
„ Comment les choisir ? „
5 à 10p/h Cahier des
complétude
„

„ Quand arrêter de tester ? charges

„ Testabilité et traçabilité „ 20 à 50 LOC/h Code

P. Collet 185 P. Collet 186

Échelle d’efficacité des méthodes Relectures et revues

Plus efficace „ Relecture individuelle qualité faible
Inspection „ Lecture croisée qualité assez faible
Revue en groupe structuré
Parcours systématique „

„ Groupe de 10 pers. Max.

Revue structurée „ Lecture puis discussion qualité moyenne
Aspects Revue en groupe structuré „ Revue structurée
formels Lecture croisée „ Liste séparée de défauts
Check list des défauts typiques bonne qualité
Relecture individuelle „

„ Revue en Round Robin

Conversation normale „ lecture préalable
„ attribution de rôles qualité variable
P. Collet 187 P. Collet 188

47
 Parcours et inspection Ça marche, les inspections ?
„ Parcours systématique „ [Fagan 1976] Inspections de la conception et du code
67%-82% de toutes les fautes sont trouvées par des inspections
„ le plus souvent du code „

25% de temps gagné sur les ressources / programmeur (malgré le

„ audit par des experts (extrêmement coûteux) „

temps passé dans les inspections)

„ Inspection „ [Fagan 1986] nouvelle étude de Fagan

93% de toutes les fautes sont trouvées par inspections
„ Préparation : recherche des défauts
„

 Cycle de réunions „ Réduction de coût pour la détection de fautes (en

comparaison avec les tests)
ž Suivi : vérification des corrections
„ [Ackerman, Buchwald, Lewski 1989]: 85%
) Modérateur + secrétaire meilleure qualité
„ [Fowler 1986]: 90%
„ [Bush 1990]: 25000 $ gagné PAR inspection
P. Collet 189 P. Collet 190

Analyse statique du code Méthodes dynamiques : les tests

„ Évaluation du code par des métriques
„ moins cher, mais résultat souvent approximatif “ Testing is the process of
„ qualité des métriques ? executing a program with the
intent of finding errors.”
„ Recherche d’anomalies dans le code
„ Références aux données (flots, initialisation, Glen Myers
utilisation…)
„ Contrôle (graphe de contrôle, code isolé, boucles…)
Tester, c’est exécuter un programme
„ Comparaisons avec l’intention de trouver des erreurs
„ Respect des conventions de style
P. Collet 191 P. Collet 192

48
 Tests : définition... Tests exhaustifs ?
„ Une expérience d’exécution, pour mettre en évidence un Il y a 520 chemins
défaut ou une erreur If then else
„ Diagnostic : quel est le problème
possibles
„ Besoin d’un oracle, qui indique si le résultat de l’expérience est En exécutant 1 test
conforme aux intentions
„ Localisation (si possible) : où est la cause du problème ?
par milliseconde,
) Les tests doivent mettre en évidence des erreurs ! cela prendrait
) On ne doit pas vouloir démontrer qu’un programme 3024 ans pour
marche à l’aide de tests ! tester ce
„ Souvent négligé car :
„ les chefs de projet n’investissent pas pour un résultat négatif
programme !
Boucle < 20x
„ les développeurs ne considèrent pas les tests comme un
processus destructeur

P. Collet 193 P. Collet 194

Constituants d’un test Test vs. Essai vs. Débogage

„ Nom, objectif, commentaires, auteur „ On converse les données de test
„ Données : jeu de test „ Le coût du test est amorti
„ Du code qui appelle des routines : cas de test „ Car un test doit être reproductible
„ Des oracles (vérifications de propriétés) „ Le test est différent d’un essai de mise au
„ Des traces, des résultats observables point
„ Un stockage de résultats : étalon
„ Un compte-rendu, une synthèse… „ Le débogage est une enquête
„ Difficilement reproductible
„ Coût moyen : autant que le programme „ Qui cherche à expliquer un problème

P. Collet 195 P. Collet 196

49
 Les stratégies de test Test unitaire
Testeur interface

Tests d’ordre driver structures de données locales

besoins supérieur conditions limites

chemins indépendants
Module Erreur de chemins
Tests d’intégration
conception
Tests
stub stub
code unitaires
Cas de test
RESULTATS
Simulateur…
P. Collet 197 P. Collet 198

Tests d’intégration Intégration descendante

Si tous les modules
Stratégie de A Les modules racines
marchent bien sont testés avec des
séparément, construction simulateurs (stubs)
pourquoi douter incrémentale
qu’ils ne
B F G
marcheraient pas Big Intégration ƒ Les simulateurs sont remplacés, un
ensemble ?
Bang partielle C par un, en profondeur d’abord
Réunir les modules : ƒ Lorsque de nouveaux modules sont
Interfacer intégrés, des sous-ensembles des tests
Test de sont ré-effectués
non-régression
D E ) Les modules complexes sont testés
tardivement
P. Collet 199 P. Collet 200

50
 Intégration ascendante Intégration en Sandwich
Les modules racines
Les modules A A sont testés avec des
feuilles sont
simulateurs (stubs)
regroupés et
intégrés
B F G B F G
package
package ƒ Les testeurs (drivers) sont
C remplacés, un par un, en C
profondeur d’abord
Les modules feuilles sont
) Pas de simulateur regroupés et intégrés
D E ) Mais l’interface apparaît tard D E

P. Collet 201 P. Collet 202

Tests de charge et de performance Tests de validation et qualification

„ Charge : „ Rédigés à partir des spécifications fonctionnelles
„ Tests de vérification des contraintes de performance en et des contraintes non fonctionnelles
pleine charge : avec les contraintes maximales „ Composition :
„ Mesure des temps d’exécution depuis l’extérieur
„ Vision de l’utilisateur face au système chargé „ Préconditions du test
„ Performance : „ Mode opératoire
„ Analyse des performances du logiciel en charge normale „ Résultat attendu
„ Profilage d’utilisation des ressources et du temps passé „ Structuration en Acceptation, refus et panne
par instruction, bloc d’instructions ou appel de fonction „ Résultat des passages
Instrumentation des programmes par des outils pour effectuer
„
„ Fiche(s) d’anomalie liée(s)
les comptages

P. Collet 203 P. Collet 204

51
 Organiser l’activité de tests Organiser l’activité de tests (suite)
„ Qui teste le logiciel ? „ Les jeux de test sont des produits :
„ Développeur : comprend bien le système mais, testera „ Spécification et développement des tests
« gentiment » et est motivé par la livraison „ Contraintes de reproduction des tests
„ Testeur indépendant : doit apprendre le système mais, „ Taille et coût minimum pour une probabilité de détection
essaiera de le casser et est motivé par la qualité
maximum
„ Mettre en place les différents types de tests : „ Les tâches associées aux tests
„ tests unitaires „ Planification
„ tests d’intégration
„ Spécification et réalisation des jeux de tests
„ tests de validation
„ tests de qualification „ Passage des tests et évaluation des résultats
„ tests de suivi d’exploitation )Commencer le plus tôt possible
P. Collet 205 P. Collet 206

Jeux de test ( =∑ cas de test ) Cas de test : exemples

„ Décrivent comment tester un système/module „ État du système avant „ État du système avant
exécution du test exécution du test
„ La description doit faire apparaître :
„ ResourcePool est non vide „ ResourcePool est non vide
„ L’état du système avant l’exécution du test
„ Fonction à tester „ Fonction à tester
„ La fonction à tester removeEngineer(anEngineer)
„ removeEngineer(anEngineer) „

„ La valeur des paramètres pour le test

„ Valeurs des paramètres „ Valeurs des paramètres
„ Les résultats et sorties attendus pour le test pour le test
pour le test
„ Objectif Découvrir des erreurs „ anEngineer est dans „ anEngineer N ’est PAS dans
ResourcePool
„ Critère de manière complète ResourcePool
Résultat attendu du test „ Résultat attendu du test
avec un minimum d’effort et
„
„ Contrainte EngineerNotFoundException
ResourcePool = ResourcePool „

dans un minimum de temps

„

\ anEngineer est levée

P. Collet 207 P. Collet 208

52
 Le jeu de test « adéquat »? Test en boîte noire
„ Teste l’interface des composants
„ Toutes les méthodes publiques besoins

„ Est-ce qu’un cas de test par méthode suffit ? sorties

„ Combien sont nécessaires ?
entrées

événements

P. Collet 209 P. Collet 210

Tests fonctionnels en boîte

noire Exemple : la recherche binaire
„ Principes Table_binaire <elem -> comparable>
…
„ S’appuient sur des spécifications externes lower() : integer
…
„ Partitionnent les données à tester par classes chercher(key : elem) : integer
d’équivalence // si l’élement de clé key est dans la table, rend son
indice, sinon rend lower-1
„ Une valeur attendue dans 1..10 donne [1..10], < 1 …
et > 10
„ Classes d’équivalence ?
„ Ajoutent des valeurs « pertinentes », liées à „ Données conformes aux prérequis (?)
l’expérience du testeur „ Données non-conformes aux prérequis
„ Tests aux bornes : sur les bornes pour „ Cas où l’élément recherché existe dans la table
l’acceptation, juste au delà des bornes pour des
„ Cas où l’élément recherché n’existe pas dans la table
refus
P. Collet 211 P. Collet 212

53
 Test : recherche binaire Test : recherche binaire
„ Deuxième regroupement plus pertinent „ Classes d’équivalence
„ Table ordonnée, avec élément recherché présent „ 1 seul élément, clé présente
„ Table ordonnée, avec élément recherché absent „ 1 seul élément, clé absente
„ Table non ordonnée, avec élément recherché présent „ Nb pair d’éléments, clé absente
„ Nb pair d’éléments, clé en première position
„ Table non ordonnée, avec élément recherché absent
„ …
„ Ajout de cas limites et intuitifs „ Tests en boîte noire résultants
„ Table à un seul élément „ Nb pair d’éléments, clé ni en première, ni en dernière
„ Table à un nombre impair d’éléments (boite grise) position
„ Nb impair d’éléments, clé absente
„ Table à un nombre pair d’éléments (boite grise)
„ Nb impair d’éléments, clé en première position
Table où l’élément recherché est le premier de la table
„
„ …
„ Table où l’élément recherché est le dernier de la table
P. Collet 213 P. Collet 214

Exemple pour le langage C :

Automatisation des tests Check
„ Les tests logiciels à la main prennent beaucoup „ Environnement de tests unitaires pour le langage C
de temps „ Inspiré de JUnit, pour Java, selon l’approche Extreme Programming
„ Check utilise
„ Les tests sur le logiciel doivent être ré-effectués „ fork pour créer un nouvel espace d’adressage pour chaque test
après chaque changement (tests de non- unitaire
des files de messages pour retourner des comptes-rendus à
régression)
„

l’environnement de tests

)Écriture ou utilisation de système de tests (driver) „ Pour piloter le lancement des tests, check
Peut être appelé directement, mais surtout
qui peuvent effectuer les tests automatiquement
„

„ Depuis un makefile, et encore mieux

et produire un rapport de tests „ Depuis autoconf/automake pour générer le tout…

P. Collet 215 P. Collet 216

54
 Pourquoi faire des tests
en boîte blanche ? Test en boîte blanche
Les données de test sont produites à partir d’une analyse
„ Tests en boîte noire: „

du code source
„ Les besoins sont satisfaits
„ Les interfaces sont appropriées et fonctionnent „ Critères de test
„ Tous les chemins
„ Pourquoi s’occuper de ce qui se passe à l’intérieur ? „ Toutes les branches
„ Les erreurs de logique et les suppositions incorrectes „ Toutes les instructions
sont inversement proportionnelles à la probabilité
d’exécution du chemin !
„ On croît souvent qu’un chemin ne va pas être exécuté ; Boucle < = 20x
en fait, la réalité va souvent à l’encontre des intuitions
) Analyse du graphe de flot de contrôle
„ Les erreurs de saisie sont aléatoires; il est vraisemblable
que certains chemins non testés en contiennent ) Analyse du flux de données
P. Collet 217 P. Collet 218

Conclusion
Ne jamais être trop ambitieux…

La date limite, c’est la date limite !

P. Collet 219

55