Initiation Au GL

2018 / 2019
Initiation au Génie Logiciel
M. Marc TEJIOGNI
Email : mtejiogni@yahoo.fr
Tél : 693 90 91 21 / 670 10 23 98
Initiation au Génie Logiciel 2018 / 2019
PLAN DU COURS
OBJECTIF GENERAL........................................................................................................................ 6
CHAPITRE I : PRESENTATION DU GENIE LOGICIEL................................................................ 7
I. Objectifs ................................................................................................................................... 7
II. Définition et principes d’ingénierie pour le logiciel ................................................................ 7
III. Processus de développement logiciel .................................................................................... 8
III.1. Analyse des besoins ............................................................................................................ 8
III.2. Spécification........................................................................................................................ 8
III.3. Conception .......................................................................................................................... 9
III.4. Programmation (Implémentation)....................................................................................... 9
III.5. Validation et vérification .................................................................................................. 10
III.6. Intégration et tests (Déploiement)..................................................................................... 10
III.7. Maintenance ...................................................................................................................... 11
IV. Tests de connaissances ........................................................................................................ 12
CHAPITRE II : CYCLE DE VIE DU LOGICIEL ............................................................................ 13
I. Objectifs ................................................................................................................................. 13
II. Différents cycles de vie.......................................................................................................... 14
II.1. Cycle en cascade ................................................................................................................ 14
II.2. Cycle en V .......................................................................................................................... 15
II.3. Cycle en spirale .................................................................................................................. 17
II.4. Développement par prototypage ........................................................................................ 18
II.5. Développement incrémental............................................................................................... 19
II.6. Méthodes agiles .................................................................................................................. 20
III. Tests de connaissances ........................................................................................................ 20
CHAPITRE III : ANALYSE DES BESOINS ET SPECIFICATIONS FONCTIONNELLES ........ 21
I. Objectifs ................................................................................................................................. 21
II. Intérêt de l’analyse des besoins.............................................................................................. 21
III. Concepts de base ................................................................................................................. 21
III.1. Qu’est-ce qu’un client ? .................................................................................................... 21
III.2. Qu’est-ce qu’un besoin, une fonction, un produit ou un service ? ................................... 22
III.3. Qu’est ce qu’une fonction d’usage et une fonction d’estime ? ......................................... 24
III.4. Quels sont les acteurs de l’analyse du besoin ? ................................................................ 25
IV. Analyse fonctionnelle (Spécification) ................................................................................. 26
IV.1. Définition .......................................................................................................................... 26
IV.2. Analyse fonctionnelle interne ........................................................................................... 26
2 M. Marc TEJIOGN I | mtejiogni@yahoo.fr | Tél : 693 90 91 21 – 670 10 23 98
IV.2.1. La méthode FAST (Function Analysis System Technic) .......................................... 26

IV.3. Analyse fonctionnelle externe .......................................................................................... 28
IV.3.1. La Bête à cornes......................................................................................................... 28
IV.3.2. Diagramme pieuvre.................................................................................................... 29
V. Tests de connaissances........................................................................................................... 31
CHAPITRE IV : ERGONOMIE DE CONCEPTION D’INTERFACES INFORMATIQUES ........ 32
I. Objectifs ................................................................................................................................. 32
II. Notion d’interface Homme – Machine (IHM) ....................................................................... 32
II.1. Définition............................................................................................................................ 32
II.2. Importance de l’interface Homme-Machine (IHM) ........................................................... 32
II.3. Qualité d’une bonne IHM................................................................................................... 33
II.4. Finalités d’un IHM ............................................................................................................. 33
III. Les principales étapes de la conception d’une IHM ........................................................... 34
IV. Les utilisateurs de l’interface .............................................................................................. 34
IV.1. Les caractéristiques des utilisateurs .................................................................................. 34
IV.2. Le contexte d’utilisation ................................................................................................... 35
IV.3. Le matériel ........................................................................................................................ 35
IV.4. La tâche (ou buts à atteindre)............................................................................................ 35
V. Tests de connaissances........................................................................................................... 35
CHAPITRE V : GESTION DE PROJET .......................................................................................... 36
I. Objectifs ................................................................................................................................. 36
II. Définition ............................................................................................................................... 36
III. Les contraintes de la gestion projet ..................................................................................... 36
III.1. Contraintes de délai........................................................................................................... 37
III.2. Contraintes de coût............................................................................................................ 37
III.3. Contraintes de qualité........................................................................................................ 37
IV. Les phases de la gestion de projet ....................................................................................... 37
V. Les intervenants dans un projet.............................................................................................. 39
VI. Planification de projet ......................................................................................................... 39
VI.1. Définition .......................................................................................................................... 39
VI.2. Réseau ou méthode PERT ................................................................................................ 40
VI.2.1. Définition ................................................................................................................... 40
VI.2.2. Principe de fonctionnement ....................................................................................... 41
VI.2.3. Construction d’un réseau PERT ................................................................................ 42
VI.2.4. Exploitation du réseau PERT..................................................................................... 43
VI.3. Diagramme de Gantt ......................................................................................................... 48
VII. Estimation des charges ........................................................................................................ 52

VII.1. Vocabulaire...................................................................................................................... 52
VII.2. Différentes méthodes d'estimation des charges ............................................................... 53
VII.2.1. La non méthode ........................................................................................................ 53
VII.2.2. La Méthode Delphi................................................................................................... 53
VII.2.3. Méthode de répartitions proportionnelle .................................................................. 54
VII.2.4. Méthode COCOMO (COnstructive COst Model).................................................... 54
VIII. Tests de connaissances .................................................................................................... 55
CHAPITRE VI : TEST D’UN LOGICIEL........................................................................................ 56
I. Objectifs ................................................................................................................................. 56
II. Fondement du test (pourquoi réaliser un test ?) ..................................................................... 56
III. Cycle de développement du test .......................................................................................... 57
III.1. Mise au point inductive..................................................................................................... 58
III.2. Mise au point déductive .................................................................................................... 58
IV. Les différents techniques de test ......................................................................................... 59
IV.1. Test statique ...................................................................................................................... 59
IV.2. Test dynamique................................................................................................................. 60
IV.3. Test « Boîte blanche » ...................................................................................................... 60
IV.3.1. Structures de la représentation de la boîte blanche.................................................... 61
IV.3.2. Mesure de complexité de Mac Cabr .......................................................................... 61
IV.4. Test « Boîte noire »........................................................................................................... 62
CHAPITRE VII : FIABILITE DU LOGICIEL ................................................................................. 64
I. Objectifs ................................................................................................................................. 64
II. Défaut et faute ........................................................................................................................ 64
III. Amélioration de la fiabilité ................................................................................................. 65
IV. Métrique de la fiabilité ........................................................................................................ 65
IV.1. Probabilité d’une panne .................................................................................................... 65
IV.2. Taux de panne ................................................................................................................... 65
IV.3. Temps moyen entre deux pannes...................................................................................... 65
IV.4. Disponibilité...................................................................................................................... 66
V. Classification de défaut .......................................................................................................... 66
VI. Exercice d’application ......................................................................................................... 66
CHAPITRE VIII : MAINTENANCE DU LOGICIEL ..................................................................... 68
I. Objectifs ................................................................................................................................. 68
II. Les types de maintenance.......................................................................................................... 68
II.1. La maintenance perfective ou évolutive............................................................................. 68
II.2. La maintenance adaptative ................................................................................................. 69
II.3. La maintenance corrective.................................................................................................. 69

II.4. Distribution de l'effort ........................................................................................................ 69

III. Processus de la maintenance .................................................................................................... 70
III.1. Informations nécessaires pour la maintenance.................................................................. 70
III.2. Cycles de développement d’une correction ...................................................................... 71
IV. Estimation du coût de la maintenance ..................................................................................... 71
IV.1. Formules ........................................................................................................................... 71
IV.2. Exercice d’application ...................................................................................................... 72
V. Les effets de la maintenance ..................................................................................................... 72
V.1. Effet de bord du codage ..................................................................................................... 72
V.2. Effet de bord de données.................................................................................................... 73
V.3. Effet de bord de la documentation ..................................................................................... 73
VI. Maintenance du code étranger ................................................................................................. 73
VII. Ré- ingénierie .......................................................................................................................... 74
VIII. Maintenance perfective ou évolutive .................................................................................... 74
IX. Tests de connaissances............................................................................................................. 75
CHAPITRE IX : GESTION DE LA QUALITE................................................................................ 76
I. Objectifs...................................................................................................................................... 76
II. Normalisation ............................................................................................................................ 76
III. Manuel qualité.......................................................................................................................... 77
IV. Tests de connaissances............................................................................................................. 77

OBJECTIF GENERAL
Le (Génie Logiciel) GL se préoccupe des procédés de fabrication des logiciels de façon à s’assurer
que les quatre critères suivants soient satisfaits :
• Le système qui est fabriqué répond aux besoins (exigences) des utilisateurs (correction
fonctionnelle) ;
• La qualité correspond au contrat de service initial. La qualité du logiciel est une notion multiforme
qui recouvre notamment :
o La validité : aptitude d’un logiciel à réaliser exactement les tâches définies par sa
spécification,
o La fiabilité : aptitude d’un logiciel à assurer de manière continue le service attendu,
o La robustesse : aptitude d’un logiciel à fonctionner même dans des conditions anormales,
o L’extensibilité : facilité d’adaptation d’un logiciel aux changements de spécification,
o La réutilisabilité : aptitude d’un logiciel à être réutilisé en tout ou partie,
o La compatibilité : aptitude des logiciels à pouvoir être combinés les uns aux autres,
o L’efficacité : aptitude d’un logiciel à bien utiliser les ressources matérielles (mémoire,
CPU...),
o La portabilité : facilité à être porté sur de nouveaux environnements matériels et/ou
logiciels,
o La traçabilité : capacité à identifier et/ou suivre un élément du cahier des charges lié à un
composant d’un logiciel,
o La vérifiabilité : facilité de préparation des procédures de recette et de certification,
o L’intégrité : aptitude d’un logiciel à protéger ses différents composants contre des accès ou
des modifications non autorisés,
o La facilité d’utilisation, d’entretien, etc.
• Les coûts restent dans les limites prévues au départ.
• Les délais restent dans les limites prévues au départ.
Ces qualités sont parfois contradictoires. Il faut les pondérer selon les types d’utilisation. Il faut
aussi distinguer les systèmes sur mesure et les produits logiciels de grande diffusion.

CHAPITRE I : PRESENTATION DU GENIE LOGICIEL

I. Objectifs
Présenter de façon générale les concepts du génie logiciel qui s’appuie sur les bonnes pratiques à
mettre en œuvre pour développer les logiciels répondant aux critères ou aux besoins exprimés par
les utilisateurs. Il sera dont question de mettre en œuvre tous les éléments du génie logiciel qui
concourt à un logiciel respectant les normes de l’ingénierie logiciel.
Avoir des procédures systématiques pour des logiciels de grande taille afin que :
• La spécification corresponde aux besoins réels du client
• Le logiciel respecte sa spécification
• Les délais et les coûts alloués à la réalisation soient respectés
II. Définition et principes d’ingénierie pour le

logiciel
Le Génie Logiciel est un ensemble des méthodes, des techniques et des outils dédiés à la
conception, au développement et à la maintenance des systèmes informatiques.
Nous avons sept principes fondamentaux pour l’ingénierie logicielle à savoir :

• Rigueur : principale source d'erreurs humaine, s'assurer par tous les moyens que ce qu'on
écrit est bien ce qu'on veut dire et que ça correspond à ce qu'on a promis (outils, revue de
code...)
• Abstraction : extraire des concepts généraux sur lesquels raisonner, puis instancier les
solutions sur les cas particuliers
• Décomposition en sous-problèmes : traiter chaque aspect séparément, chaque sous-
problème plus simple que problème global
• Modularité : partition du logiciel en modules interagissant, remplissant une fonction et
ayant une interface cachant l'implantation aux autres modules
• Construction incré mentale : construction pas à pas, intégration progressive
• Généricité : proposer des solutions plus générales que le problème pour pouvoir les
réutiliser et les adapter à d'autres cas
• Anticipation des évolutions : liée à la généricité et à la modularité, prévoir les ajouts et les
modifications possibles de fonctionnalités
• Documentation : essentielle pour le suivi de projet et la communication au sein de l'équipe
de projet
• Standardisation/normalisation : aide à la communication pour le développement, la
maintenance et la réutilisation

III. Processus de développement logiciel

Les activités du développement logiciel sont :
• Analyse des besoins
• Spécification
• Conception
• Programmation (Implémentation)
• Validation et vérification
• Intégration et tests (Déploiement)
• Maintenance
III.1. Analyse des besoins

Il s’agit ici de comprendre les besoins du client : Comprendre l’environnement du futur système, les
ressources disponibles, les contraintes de performance...
Besoins du
client Analyse des besoins Cahier des charges
III.2. Spécification
Permet d’établir une description claire de ce que doit faire le logiciel (fonctionnalités détaillées,
exigences de qualité, interface...) et clarifier le cahier des charges (ambiguïtés, contradictions).
Spécification Cahier des charges

Cahier des
Fonctionnel
charges

III.3. Conception
Permet d’élaborer une solution concrète réalisant la spécification. C’est le moment idéal de :
• Description architecturale en composants (avec interface et fonctionnalités)
• Réalisation des fonctionnalités par les composants (algorithmes, organisation des données)
• Réalisation des exigences non- fonctionnelles (performance, sécurité...)
Conception Dossier de
Cahier des charges conception
fonctionnel
III.4. Programmation (Implémentation)

Permet l’implantation de la solution conçue, choix de l'environnement de développement, du/des
langage(s) de programmation, de normes de développement...
Ici c’est la programmation qui nécessite la connaissance d’un certain nombre de langage pour le
mener à bien, il faut savoir bien programmer et connaitre les outils à utiliser. Il existe des outils qui
peuvent aider de manière à réduire le nombre d’erreur à ce niveau.
Programmation Code documenté

Dossier de + Manuel
conception d'utilisation

III.5. Validation et vérification

La validation qui consiste à assurer que les besoins du client sont satisfaits (au niveau de la
spécification, du produit fini...) ce qui permet de concevoir le bon logiciel. Nous avons également la
vérification dont le rôle ici est d’assurer que le logiciel satisfait sa spécification. Ceci permet de
concevoir le logiciel correctement.
Validation
Besoins du
client Cahier des Logiciel
charges
fonctionnel
Vérification
Méthodes de validation
• Revue de spécification, de code
• Prototypage rapide
• Développement de tests exécutables (extrême programming)
Méthodes de vérification
• Test (à partir de la spécification)
• Preuve de programmes
• Model-checking (vérification de modèles)
III.6. Intégration et tests (Déploiement)

Celui qui conçoit et qui teste doivent être différent ; cependant, il existe des jeux de tests que
lorsqu’on traverse, il y a de forte chance qu’il n’ait plus d’erreur. Il faut accorder un temps
privilégié à cette phase car on peut lancer une exception qui ne sera pas intercepté et arrêter ainsi
par le programme.

III.7. Maintenance
La maintenance du logiciel désigne, en génie logiciel, les modifications apportées à un logiciel,
après sa mise en œuvre, pour en corriger les fautes, en améliorer l'efficacité ou autres
caractéristiques, ou encore adapter celui-ci à un environnement modifié.
Types de maintenance
E.B. Swanson (informaticien américain et remarquable professeur de systèmes d’information à la

UCLA Anderson School of Management.) a identifié, au départ, trois catégories de maintenance : la
corrective, l'adaptative et la perfective. Ces catégories ont été mises à jour par l'équipe de
ISO/IEC 14764 (Norme internationale portant sur l’Ingénierie du logiciel -- Processus du cycle de
vie du logiciel -- Maintenance), avec l'ajout d'une quatrième catégorie :
• Maintenance corrective : modification du logiciel effectuée après livraison afin de corriger
les défauts rencontrés.
• Maintenance adaptative : modification du logiciel effectuée après livraison pour qu'il reste
utilisable dans un environnement qui change ou a changé.
• Maintenance perfective : modification du logiciel effectuée après livraison pour en
améliorer l'efficacité ou la maintenabilité.
• Maintenance préventive : modification du logiciel effectué après livraison pour en déceler
et corriger les défauts latents avant qu'ils ne se manifestent.
La maintenance corrective et la maintenance perfective visent à corriger des erreurs alors que la
maintenance adaptative et la maintenance préventive répondent à une amélioration du logiciel
Répartition des efforts
Repartition des efforts

7%
6%
8%
Spécification
Conception
60% 19%
Programmation
Integration et test
Maintenance

Rapport effort /e rreur/coût
160
140
120
100
Integration/test
80
Programmation
60 Conception
40 Spécialisation
20
0
Effort Origine des Coût maince
erreurs
IV. Tests de connaissances

1. Apres avoir définir spécification, expression des besoins, cahier des charges fonctionnels,
faites un lien étroite entre les trois éléments
2. Quelles différences faites-vous entre vérification et validation
3. Quelle est la place de la maintenance dans l’ingénierie logicielle

CHAPITRE II : CYCLE DE VIE DU LOGICIEL

I. Objectifs
Selon la phase du cycle de vie des systèmes, des installations ou des ouvrages sous étude, des
objectifs spécifiques d’analyse de risques peuvent être recherchés. Quelques exemples sont
énumérés ci-dessous.
• Phases d’identification de concept, définition/conception et développement
o Identifier les principaux éléments qui contribuent au risque ainsi que les facteurs
significatifs associés.
o Fixer un ou des critères de conception et estimer l’adéquation de la conception
globale.
o Identifier et évaluer les mesures de sécurité possibles au niveau de la conception.
o Fixer un ou des critères pour l’estimation du caractère acceptable des installations,
activités ou systèmes potentiellement dangereux.
o Rassembler des informations permettant d’aider le développement de procédures
pour les conditions normales et d’urgence.
o Évaluer le risque en termes de prescriptions réglementaires et autres.
o Évaluer d’autres alternatives de conception.
• Phases de construction, d’installation, d’exploitation et d’entretien :

o Surveiller et évaluer l’expérience acquise afin de comparer le niveau de performance
réel aux prescriptions pertinentes.
o Fixer un ou des critères pour optimiser les procédures de fonctionnement normal,
d’entretien et d’urgence.
o Mettre à jour les principaux éléments qui contribuent au risque ainsi que les facteurs
d’influence.
o Documenter le niveau du risque pour une prise de décision opérationnelle.
o Évaluer les effets des modifications de structure, d’organisation, d’usage, de
procédures opérationnelles et de composantes du système.
o Cibler les efforts de formation.
• Phase de mise au rebut ou de mise hors service :

o Évaluer le risque relatif aux activités de mise au rebut du système et s’assurer que les
exigences correspondantes peuvent être remplies.
o Fournir des données d’entrée aux procédures de mise au rebut.
Définir clairement la portée de l’étude des risques permettant de guider le travail d’analyse et réduit
ainsi les possibilités que les résultats soient facilement remis en question. Pour ce faire, il est
souhaitable de définir et de formuler le domaine d’application de l’analyse du risque afin de

produire un plan d’analyse du risque dès le début du projet. Il est souhaitable d’inclure, dans la
définition du domaine d’application du risque, les éléments suivants :
• La description des raisons ou problèmes qui ont donné lieu à l’analyse du risque.
• La formulation des objectifs de l’analyse de risque, sur la base des principales
préoccupations identifiées
• La définition du système à analyser.
• L’identification des sources d’information.
• La définition des conditions de fonctionnement couvertes par l’analyse de risque ainsi que
d’éventuelles limites applicables;
• L’identification des sources permettant d’obtenir des détails des aspects techniques,
environnementaux, légaux, organisationnels et humains concernant l’activité et le problème
à analyser. Il y a lieu, en particulier, de décrire également tout aspect sécuritaire.
• L’analyse des accidents passés.
• La détermination des hypothèses et contraintes régissant l’analyse.
• L’identification des décisions à prendre, des décideurs et du résultat requis de l’étude.
II. Différents cycles de vie

II.1. Cycle en cascade
Principe
Chaque étape doit être terminée avant que ne commence la suivante, à chaque étape, il y a
production d'un document base de l'étape suivante.
Ce modèle créé par Winston W.Royce en 1970 est basé sur 2 éléments fondamentaux :
1. On ne peut passer à l’étape suivante tant la précédente n’est pas terminée.

2. La modification d’une étape a un impact important sur les étapes à venir.
Lors du processus, chaque phase doit être définie précisément, c’est-à-dire, qu’il correspond au
cahier des charges écrit ultérieurement, et possède une date d’échéance fixe. Lorsque l’étape est
validée le processus continu, sinon l’étape est refaite. Si une erreur critique est rencontrée, il est
possible de revenir à la première étape.
Avantages
• Produit des livrables définis au préalable ;

• Se termine à une date précise ;
• Ne se terminer que lorsque les livrables sont jugés satisfaisants lors d'une étape de
validation-vérification
Inconvénients
• Découverte d'une erreur entraîne retour à la phase à l'origine de l'erreur et nouvelle cascade,
avec de nouveaux documents...
• Coût de médication (traitement) d'une erreur important, donc choix en amont cruciaux
(typique d'une production industrielle)
Il n’est pas toujours adapté à une production logicielle, en particulier si les besoins du client sont
changeants ou difficiles à spécifier.
II.2. Cycle en V
Principe
Le cycle en V va être constitué de 9 étapes :
• Analyse des besoins : le client va exprimer sa demande, une analyse est faite par la suite par
l’équipe, pour pouvoir présenter une solution intéressante au client.
• Les spécifications fonctionnelles : Elles permettant de décrire de manière complète ou
précises le produit et ses différentes fonctionnalités.
• Conception architecturale ou préliminaire : Ici vont être présenté l’interface graphique ou
maquette, l’arborescence à travers le module de la solution et leur interaction, …

• Conception détaillé : tout simplement, ça sera les spécifications fonctionnelles avec les
diagrammes (UML) pour être plus explicite pour que les développements commencent.
• Codage (ou développement) : l’équipe commence les développements des fonctionnalités
du produit tout en respectant les spécifications détaillées (Spécifications fonctionnelles +
Maquettes), afin de respecter le contrat avec le client et réaliser la demande du client.
• Tests unitaires : Après les développements des fonctionnalités du produit, l’équipe réalise
les tests unitaires, techniquement parlant, les tests de chaque méthode qui fait un traitement
spécifique.
• Tests d’intégration : Des tests de chaque fonctionnalité sont par la suite fait, ce sont des
tests qui se font sur tout une fonctionnalité, ils peuvent passer par plusieurs méthodes pour
assurer le bon résultat.
• Tests de validation : permet de vérifier si toutes les exigences client décrites dans le
document de spécification d'un logiciel, écrit à partir de la spécification des besoins, sont
respectées. Les tests de validation se décomposent généralement en plusieurs phases:
o Validation fonctionnelle : Les tests fonctionnels vérifient que les différents modules
ou composants implémentent correctement les exigences client.
o Validation solution : Les tests solutions vérifient les exigences client d'un point de
vue cas d'utilisation (use cases). Généralement ces tests sont des tests en volume.
Chaque grand cas d'utilisation est validé isolément; puis tous les cas d'utilisation sont
validés ensemble. L'intérêt est de valider la stabilité d'une solution par rapport aux
différents modules qui la composent, en soumettant cette solution à un ensemble
d'actions représentatif de ce qui sera fait en production.
o Validation performance, robustesse : Les tests de performance vont vérifier la
conformité de la solution par rapport à ses exigences de performance, alors que les
tests de robustesse vont essayer de mettre en évidence des éventuels problèmes de
stabilité et de fiabilité dans le temps (fuite mémoire par exemple, résistance au pic de
charge, augmentation de la volumétrie des données,...).
• Recette et maintenance : Le cahier de recette (réalisé en parallèle avec les spécifications
fonctionnelles), contient les descriptions des fonctionnalités des spécifications
fonctionnelles, l’équipe utilise ce cahier pour tester ces fonctionnalités sur le produit pour
pouvoir détecter les bugs, pour les corriger, afin d’assurer formellement que le produit est
conforme aux spécifications
Avantages
• Simple et intuitive à utiliser : Cette méthodologie est encore enseignée dans la plupart des
écoles d’ingénieurs et constitue un process naturel où il faut concevoir avant de réaliser.
• Attitude proactive : Le travail effectué lors des phases de conception permet de limiter les
risques et dérives pendant les phases de tests. Il s’agit de mettre en face de chaque phase de
spécification un moyen de vérification.

Inconvénients : les mêmes que le cycle en cascade
• Processus lourd, difficile de revenir en arrière

• Nécessite des spécifications précises et stables
• Beaucoup de documentation
II.3. Cycle en spirale

Principe
Le cycle en spirale reprend les étapes du cycle en V, et prévoit la livraison de versions successives,
ce qui permet de mettre l’accent sur la gestion des risques. Ce cycle prévoit la livraison de
prototypes, c’est à dire de versions incomplètes du produit. Il peut s’agir par exemple d’une simple
maquette sans aucune fonctionnalité.
Un modèle mixte recommencé à chaque cycle :

1. Consultation du client
2. Analyse des risques
3. Conception
4. Implémentation
5. Tests
6. Planification du prochain cycle
C’est un modèle itératif ou répétitif et incrémental.

Avantages
Meilleure maîtrise des risques (mais nécessite une très grande expérience).
Inconvénients
Il n’est adapté qu’aux grands projets et peut engendrer plus des surcoûts d'analyse par rapport à la
réalisation du logiciel. Enfin, le cycle entre les étapes prévues en théorie et celles mises en pratique
il y a parfois une grande différence.
II.4. Développement par prototypage

Principe
• Développement rapide d'un prototype avec le client pour valider ses besoins ;
• Écriture de la spécification à partir du prototype, puis processus de développement linéaire.
Avantages
Validation concrète des besoins, moins de risques d'erreur de spécification

Inconvénients
• Il échoue le plus souvent dans la réplication du produit ou du système réel.

• Il pourrait arriver que certaines mesures importantes de développement pourrait être
supprimé pour obtenir un modèle rapide et bon marché
• De nombreux problèmes sont négligés résultant de rectifications et les révisions sans fin.
Besoin du
client Prototypage Cahier des
charges Logiciel
Fonctionnel
II.5. Développement incrémental

Principe
• Hiérarchiser les besoins du client ;
• Concevoir et livrer au client un produit implantant un sous-ensemble de fonctionnalités par
ordre de priorité
Avantage
Minimiser le risque d'inadéquation aux besoins
Inconvénients
Intégration fonctionnalités secondaires non pensées en amont

II.6. Méthodes agiles

Principe
• Implication constante du client
• Programmation en binôme (revue de code permanente)
• Développement dirigé par les tests
• Cycles de développement rapides pour réagir aux changements
Avantage
Développement rapide en adéquation avec les besoins
Inconvénients
• Pas de spécification, documentation = tests, maintenance
• Fonctionne pour petites équipes de développement (< 20) car communication cruciale
III. Tests de connaissances

Faites un tableau comparatif entre les différents cycles de vie en ingénierie logiciel

CHAPITRE III : ANALYSE DES BESOINS ET

SPECIFICATIONS FONCTIONNELLES
I. Objectifs
Ce chapitre va permettre aux apprenants d’appréhender le vocabulaire de base. Ce vocabulaire
leur permettra de mieux comprendre les chapitres suivants et de mettre en œuvre au mieux la
processus de développement logiciel.
Ainsi, ce chapitre met en exergue les définitions et les concepts touchant aux thèmes suivants :
• La notion de client interne et la notion de client externe.
• La notion de besoin.
• La notion de produit ou de service pour couvrir le besoin.
• La notion de fonction.
• Les acteurs qui participent à l’analyse du besoin.
II. Intérêt de l’analyse des besoins

L’analyse du besoin n’est pas complexe à comprendre, elle fait appel au bon sens, toutefois
sa mise en œuvre repose sur un enchaînement qu’il faut respecter si on veut aboutir à un résultat
satisfaisant et compréhensible par tous.
Analyser un besoin c’est devenir un « traducteur », cette traduction doit être la plus fidèle
possible afin que celui qui va « couvrir » le besoin y réponde précisément.
Le besoin est ensuite décrit dans un document qui est appelé « cahier des charges ».
Si le besoin est mal compris, il sera mal couvert !
III. Concepts de base

III.1. Qu’est-ce qu’un client ?
C’est celui qui va faire usage du produit ou du service. On parle d’utilisateur final.
Le client est la personne la mieux placée pour exprimer son besoin, toutefois elle aura tendance à
raisonner solution plutôt que besoin. Ainsi elle dira « je veux une voiture » plutôt que « je
souhaite me déplacer d’un point A à un point B dans telle condition de confort ».
Notion de client interne et client externe
Un client interne est un client qui appartient à l’entreprise productrice du bien ou service considéré.
Le terme de client interne désigne généralement un département, service ou salarié qui reçoit un
produit ou service produit par un autre département de l’entreprise.
Exemple : Au sein d’une même entreprise, l’atelier de montage est ainsi le client interne des
départements produisant les pièces nécessaires au montage.
Le client externe est un individu externe à l’entreprise qui achète et / ou consomme les produits ou
services de cette entreprise.
III.2. Qu’est-ce qu’un besoin, une fonction, un produit ou un

service ?
Selon la norme NF X50-150,
• Un besoin est une nécessité ou désir éprouvé par un utilisateur.
• Une fonction est l’action d'un produit ou de l'un de ses constituants exprimées
exclusivement en terme de finalité.
• Un produit représente ce qui est fourni à un utilisateur pour répondre à un besoin
Un besoin peut être :

• Exprimer ou implicite
• Avouer ou non
• Latent (caché ou non manifesté)
Exemple :
Le besoin peut être exprimé de la manière suivante : « je voudrais trouver un moyen facile et rapide
pour aller de mon domicile à mon travail » c’est le besoin exprimé, mais de manière implicite
l’utilisateur pense « avec toutes les conditions de sécurité... »
Ce besoin peut se traduire en fonctions à remplir pour l’utilisateur :

• Être transporté rapidement
• Être protégé des autres usagers
• A voir du confort...
Les fonctions doivent être normalement qualifiées afin qu’il n’y ait pas d’ambiguïté, en effet
la notion de « rapidement » peut être très différente d’un utilisateur à l’autre. On va donc dire
que la fonction « être transporté » sera qualifiée à 50 km/h de moyenne sur tout le trajet.
Les fonctions sont remplies par des produits ou des services offerts au client- utilisateur.
Ainsi si l’analyse du besoin est bien réalisée elle laisse un grand champ de possibles pour couvrir le
besoin.
Nous pouvons par exemple proposer plusieurs produits qui remplissent la fonction « se
déplacer à une moyenne de 50 km/h », la voiture, le tramway, le scooter, le bus, etc.
Si le besoin a bien été analysé, l’ensemble des fonctions sera listé, et les produits proposés
couvriront le besoin.
Principe pour faire une bonne analyse des besoins
Pour faire un bon produit, il faut d’abord avoir identifié le vrai besoin. L’approche méthodique est
comme suit :
Besoin > Fonctions > Produits
1 2 3
1. Quel est le problème à résoudre

2. Quelles sont les fonctions assurées
3. Quelle est la réponse concrète

Les fonctions doivent satisfaire aux besoins comme illustre le schéma ci-dessous :
Besoin
Fonction
Inutilité
Insatisfaction
III.3. Qu’est ce qu’une fonction d’usage et une fonction

d’estime ?
La fonction d'usage précise ce à quoi est destiné l'objet technique (objet voulu et fabriqué par
l'homme) en question.
La fonction d’estime est liée au goût de l'utilisateur et peut être ressentie différemment d'un
utilisateur à un autre. La fonction d'estime est en rapport étroit avec le style de l'objet (forme,
matières, modes, couleurs ...)
L’ensemble des fonctions d’un produit comporte des fonctions d’usage et des fonctions
d’estime. Ainsi le coût total d’un produit est la somme des coûts nécessaires pour remplir
les fonctions d’usage et pour remplir les fonctions d’estime.
La répartition de ces coûts est très différente suivant les produits. Les produits d’utilisation et de
consommation courante privilégient la fonction d’usage, ainsi dans un paquet de lessive c’est
généralement l’usage (laver le linge) qui prime. Cependant l’estime n’est jamais totalement ignorée,
ainsi on mettra dans la lessive des petites paillettes bleues pour indiquer qu’il y a des agents actifs,
la couleur, une grosse partie de la présentation et du packaging remplissent des fonctions d’estime.
Prenons le cas d’une montre, sa fonction d’usage principale est de donner l’heure, pour remplir
cette fonction vous pouvez acheter une Swatch (encore qu’il existe une certaine « estime » à
porter une Swatch !) ou acheter une Rolex qui elle aussi donnera l’heure aussi bien que la Swatch.

III.4. Quels sont les acteurs de l’analyse du besoin ?

Les acteurs possibles sont les suivants :
• Les utilisateurs ou clients du produit ou service : Ceux qui vont faire usage du résultat de
l’étude après fabrication (produit ou service). Ils peuvent participer à l’étude s’ils sont
directement interrogés sur leurs besoins.
• Les représentants des clients ou utilisateurs : Généralement nommé par ses pairs, il va se
charger de transmettre le besoin des utilisateurs finaux. On veillera à ce qu’il soit lui-
même utilisateur du résultat afin de limiter les interprétations sur les réels besoins.
• L’analyste : Personne chargée de mettre en œuvre le recueil du besoin à travers différentes
techniques (enquêtes, interviews, entretiens, observations...).
• L’animateur : Il va organiser les groupes de travail et les animer. Ainsi on peut lui
demander d’animer une séance de créativité. Ce rôle peut être rempli par l’analyste.
• L’expert fonctionnel : C’est celui qui va, à partir du besoin, le traduire en fonctions à
remplir. Ce rôle peut aussi être rempli par l’analyste.
• L’expert technique : Il est l’expert des solutions techniques, de la construction du produit
ou du service. Il intervient peu dans l’analyse du besoin dans la mesure où un besoin
devrait être exprimé en dehors de toutes contraintes techniques. Cependant dans certains
projets il peut intervenir (dans la phase d’étude préalable par exemple) afin de «
canaliser » les besoins afin que certaines fonctions qui ne peuvent pas être remplies puissent
être rapidement écartées de l’analyse.
• Le rédacteur : C’est celui qui va rédiger le cahier des charges d’analyse du besoin et le
faire valider aux utilisateurs ou aux représentants des utilisateurs. Ce rôle peut être tenu
par l’analyste.
• Le décideur : Dans certaines phases de l’analyse du besoin et notamment au moment
des propositions de solutions, le décideur va effectuer des arbitrages et décider des
solutions à retenir. Ses choix s’appuient généralement sur des critères budgétaires et
temporels.
La multiplication des acteurs dans l’analyse du besoin donne plus de recul à chacun et permet de
meilleurs arbitrages. Cependant les erreurs d’interprétation sont généralement plus nombreuses.
L’équipe peut être réduite aux utilisateurs, l’analyste et le décideur, il est alors plus facile
de communiquer mais l’étude sera moins ouverte, moins complète et sûrement plus orientée.

IV. Analyse fonctionnelle (Spécification)

IV.1. Définition
L'analyse fonctionnelle consiste à rechercher et à caractériser les fonctions offertes par un produit
placé dans un système pour satisfaire les besoins de son utilisateur.
Un système est un ensemble d’éléments formant un tout structuré satisfaisant plusieurs besoins
cohérents.
Il existe deux (02) types d’analyse fonctionnelle à savoir :
IV.2. Analyse fonctionnelle interne

Cette analyse porte sur le produit lui- même, pour :
• Améliorer son comportement,
• Diminuer son coût,
• Améliorer sa fiabilité,
• etc.
Le produit est considéré comme un assemblage de constituants dont chacun remplit certaines
fonctions (fonctions de services) vis-à-vis des autres. Elle exprime le point de vue du concepteur
réalisateur du produit. Elle met en évidence les fonctions techniques qui sont internes au produit, et
qui sont choisies par le constructeur pour assurer une fonction de service.
Il existe plusieurs méthodes ou outils mettant en exergue l’analyse fonctionnelle interne donc nous
en citerons un (01) en particulier à savoir :
IV.2.1. La méthode FAST (Function Analysis System Technic)

Elle permet de traduire chacune des fonctions de service en fonction(s) technique(s), puis
matériellement en solution(s) constructive(s).
Principe de fonctionnement
Il se construit de gauche à droite, dans une logique du pourquoi au comment.
Dès lors que les fonctions de services sont identifiées, cette méthode les ordonne et les décompose
logiquement pour aboutir aux solutions techniques de réalisation.

Le diagramme FAST constitue alors un ensemble de données essentielles permettant d’avoir une
bonne connaissance d’un produit complexe et ainsi de pouvoir améliorer la solution proposée.
Exemple :
Analyse fonctionnelle interne d’un aspirateur

IV.3. Analyse fonctionnelle externe

Cette analyse fonctionnelle concerne l'usage d'un produit, c'est à dire les fonctions qu'il doit assurer
pour satisfaire le besoin du client.
Elle exprime le point de vue du client et met en évidence les fonctions d’usage ou d'estime.
Il existe plusieurs méthodes ou outils mettant en exergue l’analyse fonctionnelle externe donc nous
en citerons deux (02) en particulier à savoir :
IV.3.1. La Bête à cornes

Pour formaliser l’énoncé du besoin, l’utilisation de l’outil bête à cornes est le mieux adapté. Pour
cela, il est fondamental de poser les trois questions suivantes:
• À qui rend-il service?
• Sur quoi agit-il ?
• Dans quel but le produit existe-il ?
A qui rend-t- Sur quoi

1 2
il service ? agit-t- il ?
Produit
Dans quel but ? 3

Exemple :
A qui rend-t- Jardinier Sur quoi

Gazon, Herbe
il service ? agit-t- il ?
Tondeuse
Dans quel but ? Mettre la propreté
IV.3.2. Diagramme pieuvre

Il permet de relier le produit ou service à son environnement extérieur. Il met en évidence les
relations entre les différents Elé ments du Milieu Extérieur (EME) et le produit ou service au
travers de fonctions : Fonctions Principales (FP) et Fonctions de Contraintes (FC).
Vocabulaire
• Fonctions principales (FP) : C’est la raison d’être du produit

• Fonctions de contraintes (FC) : Ce sont des limitations à l’imagination du concepteur
• Milieu extérieur : Représente tous les éléments ayant une interaction avec le produit ou
service
Principe de fonctionnement
Pour créer un diagramme pieuvre nous devons tout d’abord placé l’objet à étudier dans une bulle
centrale puis, rechercher les Elé ments du Milieu Extérieur (EME) en relation avec le produit ou
service et les placer autour de la première bulle. Identifier les fonctions principales FP (= relier
deux bulles extérieurs en passant par l’objet à étudier) et enfin identifier les fonctions de
contraintes FC en reliant par une ligne les bulles restantes de l’extérieur à l’objet à étudier.

Fonctions Principales (FP) Fonctions de Contraintes (FC)

FP1 = description…. FC1 = description….
…..
FC5 = description….
ATTENTION : La description des FP et FC doit toujours débuter par un verbe d’action à

l’infinitif.
Exemple :
Diagramme pieuvre d’une souris d’ordinateur sans fil

Fonctions Principales (FP) Fonctions de Contraintes (FC)

FP1 = Sélectionner un élément FC1 = Eviter tout choc excessif
FC2 = Organiser le poste de travail de manière ergonomique
FC3 = S’assurer de la présence de piles 2 x AAA (1.5V)
FC4 = Ne diriger jamais le capteur optique vers les yeux afin
d’éviter une blessure éventuelle.
FC5 = Connecter le nano-récepteur USB
V. Tests de connaissances
Faire l’analyse des besoins et l’analyse fonctionnelle d'un téléphone portable.

CHAPITRE IV : ERGONOMIE DE CONCEPTION

D’INTERFACES INFORMATIQUES
I. Objectifs
Pour la conception ou la correction en profondeur de votre interface, nous vous proposons un
niveau de prestation plus élevé que la simple évaluation des éléments statiques de votre système.
Nos analyses et les propositions de solutions qui en découlent vont bien au-delà de la simple
correction technique de l’interface : nous prenons en compte l’ensemble du contexte d’utilisation
dans le cadre de la norme ISO 9241-11.
Dans le cadre de ce cours, l’apprenant est orienté vers les compétences suivantes :
• Permettre la réalisation des tâches prévues,
• Minimiser l'investissement nécessaire pour pouvoir utiliser l'interface
• Garantir des interactions fiables
• Favoriser la standardisation ;
II. Notion d’interface Homme – Machine (IHM)

II.1. Définition
Ergonomie (du grec ergos qui signifie le travail et de Nomos qui signifie la loi) : discipline qui vise
l’adaptation d’un système à son utilisateur, afin que ce dernier puisse mener ses activités avec un
maximum d’efficacité, de satisfaction et de bien-être, avec une phase d’adaptation réduite.
L’interface Homme-Machine est une discipline qui s’intéresse à la conception, le développement,

l’évaluation de systèmes interactifs Homme-Machine et les phénomènes autour d’eux.
II.2. Importance de l’interface Homme-Machine (IHM)

Une mauvaise interface peut provoquer le rejet de la part des utilisateurs, leur frustration, face au
système qu'ils ont à utiliser. Inversement, une bonne IHM amplifie les sensations positives de
succès et de contrôle.

II.3. Qualité d’une bonne IHM

D'une façon générale, une bonne IHM est une interface que l'utilisateur ne remarque plus.
II.4. Finalités d’un IHM

La finalité de l’IHM peut être vue sur plusieurs plans à savoir :
• Permettre la réalisation des tâches prévues :
o La richesse fonctionnelle doit être adaptée
o Trop peu de fonctions entrainent un système inutilisable
o Richesse fonctionnelle trop importante implique système difficile à maîtriser.
o Une analyse fonctionnelle doit être réalisée pour recenser l'ensemble des tâches et
sous-tâches véritablement nécessaires, ainsi que leur fréquence d'utilisation.
o Analyse fonctionnelle dynamique Règle du MRU (Most Recently Used) (exemple
Win2k, pour les programmes les plus utilisés)
• Minimiser l'investissement de l'utilisateur :

Minimiser la durée d'apprentissage et le niveau de compétences requis, ce qui peut s'obtenir,
entre autre, par un mimétisme plus ou moins marqué avec d'autres IHM auxquelles
l'utilisateur à déjà été confronté.
• Garantir des interactions fiables :

o Garantir un bon degré de fiabilité lors des interactions.
o La confiance que place l'utilisateur dans le système est souvent fragile! Les
interactions offertes par une bonne IHM doivent donc contribuer à augmenter la
confiance de l'utilisateur : fonctionnement sans erreurs, organisation fonctionnelle
claire et cohérente, stabilité dans le temps, ...
• Favoriser la standardisation :
La standardisation permet de réduire les temps d'apprentissage, augmente la confiance et les
performances des utilisateurs (moins d'erreurs) et améliore la portabilité des systèmes.
• Règles :
o Séparer la conception de l’application de la conception de l’interface
o Prendre en compte les utilisateurs
o Concevoir de manière itérative, avec phases d’affinement progressif par une équipe
pluridisciplinaire.

III. Les principales étapes de la conception d’une

IHM
Les principales étapes de la conception d'une IHM sont :
1. Déterminer l'ensemble des tâches que l'IHM devra permettre de réaliser : une bonne
IHM est une IHM dont les objectifs fonctionnels sont clairement identifiés ;
2. Déterminer les caractéristiques principales des utilisateurs qui seront ame nés à utiliser
l'IHM (leur profil) : La qualité d'une IHM est directement dépendante de son adéquation
avec la population d'utilisateurs pour laquelle elle est prévue ;
3. Proposer plusieurs prototypes d'interface qui seront discutés et évalués par les
concepteurs et les utilisateurs potentiels : Une bonne IHM naît le plus souvent de la
diversité... et plusieurs pistes doivent donc être explorées ;
4. Produire une spécification explicite de l'IHM, décrivant à la fois les contraintes

fonctionnelles et les contraintes de layout (disposition des éléments); un manuel d'utilisation
et une référence technique pourront également être produits durant cette phase;
5. Réaliser l'IHM proprement dite (phase d'implé mentation effective) ;
6. Evaluer l'IHM produite sur la base d'indicateurs reconnus.
IV. Les utilisateurs de l’interface

IV.1. Les caractéristiques des utilisateurs
Les utilisateurs visés peuvent avoir des profils variés ou non, cependant nous pouvons anticiper les
problèmes d’utilisation selon leurs profils. Par exemple, certains utilisateurs ont une grande maîtrise
des outils techniques (expertise système), d’autres ne sont pas à l’aise avec l’informatique mais
présentent un savoir- faire réel sur la tâche retranscrite par l’interface (expertise métier). L’action
d’ergonomie vous aide à définir le niveau d’expertise de vos utilisateurs, améliorant la flexibilité de
votre système.

IV.2. Le contexte d’utilisation

Il s’agit d’une variable importante pour le succès de votre interface. Les utilisateurs interagissent
avec votre système dans un environnement défini par plusieurs caractéristiques. L’organisation du
travail, le facteur temporel, les ambiances physiques telles que le bruit et la luminosité ou encore
l’aménagement de l’espace de travail sont autant de paramètres qui influeront directement sur
l’utilisation. L’action d’ergonomie identifie ces facteurs et les prend en compte dans la conception
d’interface.
IV.3. Le matériel
Le matériel qui supporte l’interface comporte des caractéristiques qui lui sont propres. Il définit
parfois un type d’interaction avec l’utilisateur, par exemple avec le choix d’un périphérique de
saisie plutôt qu’un autre (clavier physique, souris, tactile…). Plus généralement, il est nécessaire de
relever également les propriétés des éléments qui servent à l’utilisateur, en complément de
l’interface (bloc-notes, documents textuels, manuels…).
IV.4. La tâche (ou buts à atteindre)

Les utilisateurs utilisent les interfaces pour atteindre un but précis. Pour y parvenir, ils ont
généralement plusieurs actions à accomplir, de façon séquentielle ou non. Action Ergo analyse
l’ensemble des processus induit par le système et les exigences cognitives qui en découlent. Ainsi,
nous pouvons déterminer quelles fonctionnalités doivent être assurées par la machine (fonctions
répétitives, mémorisation de nombreux paramètres…) et quelles sont celles qui seront plus adaptées
pour l’humain (gestion des aléas, interprétation des situations…). L’utilisation de votre interface
implique souvent l’accomplissement de plusieurs tâches, qui font appel à des traitements cognitifs
différents : tâche de contrôle, tâche de conception, tâche d’évaluation.
V. Tests de connaissances
Apres avoir présenté de manière sommaire la notion d’ergonomie, faites un lien étroite avec la
notion de qualité logiciel et les utilisateurs.

CHAPITRE V : GESTION DE PROJET

I. Objectifs
• Comprendre la fonction projet dans la stratégie d’entreprise
• Connaître la méthodologie de conduite d’un projet informatique
• Analyser les contraintes liées à un projet informatique
• Apprendre à travers des cas d’étude à planifier un projet
• Pouvoir comprendre le rôle et les responsabilités des acteurs liés à un projet informatique
II. Définition
Selon AFITEP (Association Française des Ingénieurs et Techniciens d'Estimation et de
Planification), Dictionnaire de manage ment de projet [1996],
« Un projet est un processus unique, qui consiste en un ensemble d'activités coordonnées et

maîtrisées comportant des dates de début et de fin, entreprises dans le but d'atteindre un objectif
conforme à des exigences spécifiques telles que des contraintes de délais, de coûts et de
ressources. »
III. Les contraintes de la gestion projet

La gestion du projet logiciel a pour but de mener à son terme un projet, en tenant compte de
contraintes qui lient chacun des aspects du triangle du projet : Délai, Coût et Qualité.

III.1. Contraintes de délai

Il s’agit d’une fenêtre temporelle à l’intérieur de laquelle le projet doit être réalisé.
Savoir combien de temps doit durer la réalisation d’un projet n’est pas aisé, même si cela fait partie
du travail d’un ingénieur. Certains projets ne sont pas urgents, ni même importants, mais ils
comportent forcément une deadline à partir de laquelle ils deviennent caducs.
III.2. Contraintes de coût

Il s’agit du budget pour réaliser le projet.
Un client est prêt à dépenser une certaine somme pour un projet donné. La valeur du projet peut
éventuellement s’adapter à un certain nombre de critères, mais il y a forcément un seuil au-delà
duquel il est impossible de le rentabiliser. La notion de coût englobe aussi bien les frais d’étude (en
fonction du temps passé aux spécifications fonctionnelles et techniques) et de réalisation (suivant le
nombre de développeurs nécessaires, le matériel mis à leur disposition, la présence d’une équipe de
test et de validation, …), que les frais d’exploitation (matériel nécessaire pour faire tourner le projet
en production, salaire de l’opérateur de maintenance, …)
III.3. Contraintes de qualité

Il s’agit du soin qui est apporté à la réalisation fonctionnelle et technique du projet.
Un projet de médiocre qualité remplira les besoins immédiats du client, en s’autorisant un certain
nombre de raccourcis. Un projet de bonne qualité aura été spécifié pour couvrir certains besoins
futurs identifiables, et offrira une ergonomie adaptée, des performances homogènes, une évolutivité
étudiée, une documentation complète.
IV. Les phases de la gestion de projet

La gestion de projet logiciel s'intéresse aux activités qui assurent que le projet commandé sera livré
dans les temps en accord avec les contraintes des organismes commanditaires et réalisateurs. Il se
dégage donc quatre activités principales: la conception, la planification, la réalisation, et la
terminaison.

• Phase de conception :
o Déterminer le but du projet
o Estimer les ressources matérielles, logicielles et humaines
o Définir le type d'organisation
o Choisir le MOA (Maîtrise d’ouvrage), le MOE (Maîtrise d’œuvre) et le chef de
projet
o Estimation des risques liés à la réalisation du projet
o Définir les moyens ou méthodes de gestion ou de pilotage de projet à utiliser
• Phase de planification
o Organigramme des tâches
o Détail des coûts et délais
o Engagement des hommes-clés
o Définition des responsabilités
• Phase de réalisation :
o Mise en place de l’organisation
o Exécution du travail
o Pilotage délais-coûts-spécifications
o Résolution des problèmes
• Phase de terminaison :
o Analyse des écarts entre planifié et réalisé
o Evaluation du projet
o Archivage
o Réaffectation du personnel

V. Les intervenants dans un projet
Maîtrise d'Ouvrage (MOA) : L’entité génératrice du projet. La MOA lance le projet, définit les
limites et les frontières ainsi que la nature du projet. C’est elle qui établit le cahier des charges.
Maîtrise d'Œuvre (MOE) : L’entité responsable de la conception et coordination de la mise en

place d'un projet avec les différents acteurs.
VI. Planification de projet

VI.1. Définition
À partir des résultats de la conception, la planification consiste à :
• Identifier les différentes tâches et leur durée,
• Déterminer les relations de dépendance entre les tâches,
• Déterminer les étapes critiques,
• Ordonnancer les tâches dans le temps,
• De tenir compte d'éventuelles intolérances.

Pour cela, le MOE a deux principales techniques (complémentaires) à sa disposition :

• Le réseau PERT (Program Evaluation and Review Technique ou Technique
d’Évaluation et d’Exame n de Programme)
• Le diagramme de Gantt.
VI.2. Réseau ou méthode PERT

VI.2.1. Définition
Réseau ou méthode PERT
Le réseau PERT (Program Evaluation and Review Technique ou Technique d’Évaluation et

d’Examen de Programme) : C’est une méthode conventionnelle utilisable en gestion de projet,
ordonnancement et planification développée aux États-Unis par la marine américaine dans les
années 1950.
La méthode PERT permet de représenter la planification de la réalisation d’un projet suivant un

graphe de dépendances.
1 A 2 B 3
3 1
Tâche
Une tâche est le déroulement dans le temps d’une action.
Elle permet au projet d’avancer vers son état final. On attribue une lettre à chaque tâche afin
d’alléger le schéma. La tâche a des propriétés d’ordre temporel qui qualifient le temps de réalisation
: la durée, exprimée en minutes ou bien heures, jours, semaines, mois, etc.
Exprimée via la méthode PERT, une tâche est représentée par une flèche, précisée par son nom et sa
durée.
Lettre référençant la tâche

B
3
Durée de la tâche
Une tâche ne peut être représentée qu’une seule fois ; inversement, une flèche ne peut représenter
qu’une seule tâche. La longueur, la courbure et la forme des flèches sont sans signification
particulière.

Étape
Une étape indique le début et/ou la fin d’une tâche. On numérote les étapes afin de clarifier le
schéma.
L’étape a des propriétés d’ordre temporel : dates au plus tôt et au plus tard, exprimées en
minutes, heures, etc.
Exprimée via la méthode PERT, une étape est représentée par un rond, découpé en 3 zones, précisé
par son numé ro, ainsi que ses dates au plus tôt et au plus tard.
Numéro de l’étape
2
3 5
Date au plus tôt Date au plus tard
La date au plus tôt est le délai minimum, depuis le début du projet, nécessaire pour atteindre
l’étape considérée.
La date au plus tard est la date maximum, depuis le début du projet, à laquelle doit être atteinte
l’étape considérée pour que le délai de l’ensemble du projet ne soit pas modifié.
Réseau
Un réseau est l’ensemble des tâches et des étapes formant l’intégralité de la planification du projet
(on parle aussi de diagramme PERT).
Deux tâches qui se succèdent immédiatement dans le temps sont représentées par deux flèches qui
se suivent, séparées par une étape.
1 A 2 B 3
5 3
NB : Les différentes propriétés temporelles (durée, date, etc.) doivent impérativement être
exprimées suivant la même unité, et la même échelle.
VI.2.2. Principe de fonctionnement

Son principe est de découper un projet en un ensemble d’actions appelées tâches et de les
représenter sous forme graphique selon un graphe de dépendances.
Grâce à la chronologie et l’interdépendance de chacune des tâches, on structure ainsi l’ensemble du

projet et on peut alors planifier la réalisation de chacune des tâches les unes par rapport aux autres,
afin de minimiser les délais, ainsi que réduire l’impact des retards lors de l’exécution des différentes
tâches.
Exemple :
Soit le projet suivant : « changer une roue crevée ».

A. Installer le cric et monter la voiture : 5 minutes ;
B. Dévisser les écrous de la roue crevée : 3 minutes ;
C. Ôter la roue crevée et installer la roue de secours : 1 minute ;
D. Revisser les écrous de la nouvelle roue : 4 minutes ;
E. Baisser la voiture et enlever le cric : 3 minutes.
Exprimée grâce au réseau PERT, ce projet prendra la forme suivante :
1 A 2 B 3 C 4 D 5 E 6
5 3 1 4 3
Afin de finaliser la mise en œuvre de la méthode PERT, un certain nombre d’activités doivent être
menées à bien :
• Définir de manière précise le projet ;
• Définir un responsable de projet auquel on rendra compte et qui prendra les décisions
importantes ;
• Analyser le projet par grands groupes de tâches, puis détailler certaines tâches si besoin est ;
• Définir très précisément les tâches et déterminer leur durée ;
• Rechercher les coûts correspondants, ce qui peut éventuellement remettre en cause certaines
tâches ;
• Mettre en œuvre les tâches selon la chronologie décidée ;
• Effectuer des contrôles périodiques pour vérifier que le système ne dérive pas ; si c’est le
cas, prendre les dispositions nécessaires – quitte à revoir la planification selon la méthode
PERT – afin de minimiser les conséquences.
VI.2.3. Construction d’un réseau PERT

La construction d’un réseau PERT, et son exploitation, supposent d’effectuer les opérations
suivantes :
1. Etablir une liste précise des tâches ;
2. Déterminer les tâches antérieures (ainsi que les tâches postérieures éventuellement) ;
3. Construire les graphes partiels ;

4. Regrouper les graphes partiels ;
5. Construire le réseau.
Exemple :
Tâches Tâche(s) Tâche(s) Durée

antérieure(s) postérieure(s)
A _ C 3
B _ C, D 12
C A, B E, F 1
D B F 6
E C _ 7
F D G 3
G F _ 3
1
C 2 E 3
1 7
A
0
3 Fin
Début C F
3
1
B
12 4 5 6 0
D F G 7
6 3 3
VI.2.4. Exploitation du réseau PERT

Par « exploitation » on entend les informations temporelles obtenues grâce à la méthode PERT,
comme notamment la détermination de la durée totale du projet à réaliser.
Calcul des dates « au plus tôt »
On commence tout d’abord par calculer les dates au plus tôt. Pour une étape donnée, cette
information détermine à quelle date minimum depuis le début du projet sera atteinte, au plus tôt,
l’étape considérée.
Pour ce faire, on se base sur l’estimation de la durée des tâches. On part de l’étape de début, pour
laquelle la date au plus tôt est initialisée à 0, et on parcourt le réseau en suivant l’agencement des
tâches déterminé auparavant.

Deux méthodes de calcul existent alors selon que l’étape considérée est atteinte par une ou par
plusieurs tâches :
• Une (01) tâche : il n’y a qu’un seul chemin possible pour atteindre l’étape ;
La date au plus tôt vaut la date au plus tôt anté rieure à laquelle on rajoute la durée de la
tâche liant les 2 étapes :
to0 = to1 + durée1
to1 to0
durée1
• Plusieurs tâches : il y a plusieurs che mins possibles pour atteindre l’étape.

On applique le procédé décrit ci-dessus (pour 1 tâche) pour chacune des tâches antérieures ;
la date au plus tôt vaut alors le maximum parmi ces résultats :
to0 = Max [(to1 + durée1), (to2 + durée2), … ]
to1
durée1
to0
durée2
to2
La date au plus tôt de l’étape de fin indique alors le temps minimum nécessaire à l’achèvement du
projet.
Calcul des dates « au plus tard »
On poursuit avec le calcul des dates au plus tard. Pour une étape donnée, cette information
détermine à quelle date maximum, depuis le début du projet, doit être atteinte, au plus tard, l’étape
considérée, afin que le délai de l’ensemble du projet ne soit pas modifié.
Pour ce faire, on se base sur l’estimation de la durée des tâches. On part de l’étape de fin, pour
laquelle la date au plus tard est initialisée à la même valeur que la date au plus tôt déterminée
précédemment, et on parcourt le réseau en suivant l’agencement inverse des tâches.
Là encore, il existe deux méthodes de calcul selon qu’une ou plusieurs tâches partent de l’étape
considérée :
• Une (01) tâche : il n’y a qu’un seul chemin possible pour partir de l’étape ;
La date au plus tard vaut la date au plus tard « précédente » (la postérieure dans
l’agencement des tâches) à laquelle on retranche la durée de la tâche liant les 2 étapes :
ta0 = ta1 – durée1
ta0 ta1
durée1

• Plusieurs tâches : il y a plusieurs chemins possibles qui partent de l’étape.

On applique le procédé décrit ci-dessus (pour une (01) tâche) pour chacune des tâches «
précédentes » ; la date au plus tard vaut alors le minimum parmi ces résultats :
ta0 = Min [(ta1 – durée1), (ta2 – durée2), … ]
ta1
durée1
ta0
durée2
ta2
Une fois cette étape terminée, on regroupe les informations de dates au plus tôt et au plus tard en un
seul schéma. Ainsi, si on reprend l’exemple précédent on aura :
1 3
C 2 E
3 16 1 13 17 7 20 24
A
0
3 Fin
Début C F
3 24 24
0 0 1
B
12 4 5 6 7
0
D F G
12 12 6 18 18 3 21 21 3 24 24
Calcul des marges
Certaines tâches bénéficient d’une latence variable dans leur aboutissement sans pour autant
remettre en cause la date d’achèvement du projet. Cette période de latence est appelée marge.
L’évaluation quantitative de ces marges (appelées aussi battements) permet d’optimiser la gestion
du projet. En effet, l’analyse de ces marges permet d’aménager le déroulement de certaines tâches
selon des critères autres que temporels : coûts, plan de charge de l’entreprise, goulets
d’étranglements 3, …
On appelle "marge" d'une tâche le retard qu'il est possible de tolérer dans la réalisation de celle-ci,
sans que la durée optimale prévue du projet global en soit affectée. Il est possible de calculer trois
types de marges : la marge totale, la marge certaine et la marge libre.

Marge totale
La marge totale d'une tâche indique le retard maximal que l'on peut admettre dans sa réalisation
(sous réserve qu'elle ait commencé à sa date au plus tôt) sans allonger la durée optimale du projet.
Elle se calcule en retirant la durée de la tâche en question à l'écart qu'il peut y avoir entre sa date au
plus tôt de début et sa date au plus tard de fin :
marge totale = (ta2 – to1) – durée
to1 ta1 durée to2 ta2
Sauf cas particulier, un retard correspondant à la marge totale d'une tâche se traduit par une
modification des dates au plus tôt des tâches qui lui succèdent et entraîne, généralement, l'apparition
d'un second chemin critique.
Il n'est donc pas possible de cumuler des retards correspondant à leur marge totale sur plusieurs
tâches successives, sans remettre en cause la durée optimale prévue pour le projet.
Marge libre
La marge libre d'une tâche indique le retard que l'on peut admettre dans sa réalisation (sous réserve
qu'elle ait commencé à sa date au plus tôt) sans modifier les dates au plus tôt des tâches suivantes et
sans allonger la durée optimale du projet.
Elle se calcule en retirant la durée de la tâche en question à l'écart qu'il peut y avoir entre ses dates
au plus tôt de début et de fin :
marge libre = (to2 – to1) – durée
Un retard correspondant à la marge libre d'une tâche reste sans conséquence sur les marges des
tâches qui lui succèdent. Il est donc possible de cumuler des retards, s'inscrivant dans leur marge
libre, pour plusieurs tâches successives, sans remettre en cause la durée optimale prévue pour le
projet.

Marge certaine
La marge certaine d'une tâche indique le retard que l'on peut admettre dans sa réalisation (quelle
que soit sa date de début) sans allonger la durée optimale du projet.
Elle se calcule en retirant la durée de la tâche en question à l'écart qu'il peut y avoir entre sa date au
plus tard de début et sa date au plus tôt de fin :
marge centaine = Max [0, (to2 – ta1) – durée]
D'après cette formule, la marge certaine est considérée comme nulle lorsque son calcul donne un
nombre négatif.
Un retard correspondant à la marge certaine d'une tâche reste sans conséquence sur les marges des
tâches qui lui succèdent, même si elle commence à sa date au plus tard. Il est donc possible de
cumuler des retards, s'inscrivant dans leur marge certaine, pour plusieurs tâches successives, même
si elles commencent à leur date au plus tard, sans remettre en cause la durée optimale prévue pour le
projet.
Dans le cadre de notre exemple, on a regroupé les marges calculées dans le tableau suivant :
1
C 2
E 3
3 16 1 13 17 7 20 24
A
0
3 Fin
Début C F
3 24 24
0 0
1
B
12 4 5 6 7 0
D F G
12 12 6 18 18 3 21 21 3 24 24
Tâches Marge total Marge libre Marge centaine

A (16 – 0) – 3 = 13 (3 – 0) – 3 = 0 Max[0, (3 – 0) – 3] = 0
B (12 – 0) – 12 = 0 (12 – 0) – 12 = 0 Max[0, (12 – 0) – 12] = 0
C (17 – 12) – 1 = 4 (13 – 12) – 1 = 0 Max[0, (13 – 12) – 1] = 0
D (18 – 12) – 6 = 0 (18 – 12) – 6 = 0 Max[0, (18 – 12) – 6] = 0
E (24 – 13) – 7 = 4 (20 – 13) – 7 = 0 Max[0, (20 – 17) – 7] = 0
F (21 – 18) – 3 = 0 (21 – 18) – 3 = 0 Max[0, (21 – 18) – 3] = 0
G (24 – 21) – 3 = 0 (24 – 21) – 3 = 0 Max[0, (24 – 21) – 3] = 0

Les tâches ayant une marge nulle ne bénéficient donc d’aucune latence dans leur exécution leur
permettant de ne pas retarder le projet. L’ensemble de ces tâches permet de déterminer le chemin
critique.
Détermination du che min critique
Le chemin critique indique quelles sont les tâches à successivement observer au cours de la mise en
œuvre du projet afin de surveiller les éventuels retards. Le but est de détecter les dérives et d’agir
alors rapidement en conséquence afin de minimiser leur impact sur la durée de l’ensemble du projet.
On parle de « che min » car il part de l’étape initiale et mène à l’étape finale via une suite de
différentes tâches.
Il est dit « critique » car tout retard pris sur l’une des tâches constituant ce chemin aura une
incidence directe sur la date d’achèvement du projet ; celui-ci sera retardé d’autant que la tâche est
elle- même retardée.
Pour savoir quel est le chemin critique et donc aussi quelles tâches observer, il suffit de répertorier
toutes les tâches ayant une marge nulle. La mise en avant de ces tâches détermine d’elle-même le
chemin critique.
Si on reprend notre exemple on a : B, D, F, G
1
C 2 E 3
3 16 1 13 17 7 20 24
A
0
3 Fin
Début C F
1 3 24 24
0 0
B
12 4
D 5 F 6 7
0
G
12 12 6 18 18 3 21 21 3 24 24
VI.3. Diagramme de Gantt

Le diagramme de Gantt est un outil utilisé (souvent en complément d'un réseau PERT) en
ordonnancement et en gestion de projet et permettant de visualiser dans le temps les diverses tâches
composant un projet.
À partir de résultats obtenus du réseau PERT, plus les hypothèses sur la ressource disponible, on
construit un planning (calendrier) sous forme de diagramme dont l’axe des abscisses représente le
temps et l’axe des ordonnées représente les tâches.

Il se construit simplement en suivant les différents niveaux du tableau d’avancement des tâches ; on
procède niveau par niveau, en traitant chacune des tâches prenant fin au niveau considéré.
Comment repartir les tâches en niveau 0, 1, 2, …, n ?
Soit n appartenant à l’ensemble des entiers naturels, le nombre de niveau.
1. Les tâches n’ayant pas de tâches antérieures sont des tâches de niveau 0 (n = 0). Ces tâches
constituent l’ensemble des tâches que l’on peut démarrer de suite.
2. Les tâches n’ayant pas de tâches antérieures après suppression des tâches qui se trouvent
déjà dans un niveau (tâches supérieures) sont les tâches de niveau n+1.
Si on reprend notre exemple précédent on aura :
Niveau 0
Tâches Tâche(s) antérieure(s) Niveau

A _ Niveau 0
B _ Niveau 0
C A, B
D B
E C
F D
G F
Niveau 1

A _ Niveau 0
B _ Niveau 0
C A, B Niveau 1
D B Niveau 1
E C
F D
G F

Niveau 2

A _ Niveau 0
B _ Niveau 0
C A, B Niveau 1
D B Niveau 1
E C Niveau 2
F D Niveau 2
G F
Niveau 3

A _ Niveau 0
B _ Niveau 0
C A, B Niveau 1
D B Niveau 1
E C Niveau 2
F D Niveau 2
G F Niveau 3

A _ Niveau 0
B _ Niveau 0
C A, B Niveau 1
D B Niveau 1
E C Niveau 2
F D Niveau 2
G F Niveau 3

Diagramme de Gantt
Tâche(s) Tâche(s)
Tâches Durée Niveau
antérieure(s) postérieure(s)
A _ C 3 Niveau 0
B _ C, D 12 Niveau 0
C A, B E, F 1 Niveau 1
D B F 6 Niveau 1
E C _ 7 Niveau 2
F D G 3 Niveau 2
G F _ 3 Niveau 3
1 2
C E 3
3 16 1 13 17 7 20 24
A
0
3 Fin
Début C F
3 24 24
0 0 1
B
12 4 5 6 7 0
D F G
12 12 6 18 18 3 21 21 3 24 24
Selon que l’on utilise les dates au plus tôt ou au plus tard on peut avoir le diagramme de Gantt au
plus tôt et le diagramme de Gantt au plus tard.
Diagramme de Gantt au plus tôt
Date de début du projet : 03/12/2018

Date de fin du projet : 04/01/2019
Durée du projet : 35 jours

Diagramme de Gantt au plus tard
Date de début du projet : 03/12/2018

Date de fin du projet : 04/01/2019
Durée du projet : 35 jours
On remarque que le choix des dates au plus tôt ou au plus tard n’influence pas la durée du projet sur
le diagramme de Gantt mais néanmoins permet de mettre en exergue les marges (totale et libre)
dans la réalisation de la tâche liée au projet.
VII. Estimation des charges

VII.1. Vocabulaire
Charge
C'est la quantité de travail qu'une personne peut réaliser.
Unité utilisée
Jour / homme, mois / homme, année / homme.
Remarques
Mois / homme (charge sur un mois) = en général 20 jours.
Taille du projet
La taille du projet se mesure à sa charge.

Ordre de grandeur
Selon les normes ISO on a :
Charge < 6 M/h Très petit projet

6 M/h ≤ charge ≤ 12 M/h Petit projet
12 M/h ≤ charge ≤ 30 M/h Projet moyen
30 M/h ≤ charge ≤ 100 M/h Grand projet
100 M/h ≤ charge Très grand projet
Durée
Elle dépend de la charge et du nombre de personnes infectées.
Exemple
60 M/h peut être :

• 1 personne pendant 5 ans ou
• 10 personnes pendant 6 mois ou
• 60 personnes pendant 1 mois.
VII.2. Différentes méthodes d'estimation des charges

VII.2.1. La non méthode
Il s’agit ici du principe de répondre à une offre avec un prix bas pour être sur de l'avoir, mais sans
être sûr d'y gagner quelque chose en définitive au point de vue financier.
VII.2.2. La Méthode Delphi

C’est méthode est basée sur l'expérience des experts du domaine.
Principe
1. Chaque expert propose une estimation basée sur son expérience.

2. On publie le résultat (anonyme).
3. Les experts sont invités à modifier ou à maintenir leurs estimations.
4. On publie les résultats nominaux.
5. Les experts refont la troisième étape.
6. On analyse les disparités, on calcule la moyenne.

VII.2.3. Méthode de répartitions proportionnelle

Elle s'appuie sur le découpage du projet en différentes phases. On commence par faire l'estimation
de la charge globale. Ensuite, on détermine la charge pour chaque phase du cycle de vie.
Etape ratio
Etude préalable 10 % de la charge totale
Etude détaillée 20 à 30 % de la charge totale
Etude technique 5 à 15 % de la charge "réalisation"
Réalisation 2 fois la charge "étude détaillé"
Mise en œuvre 30 à 40 % de la charge "réalisation"
VII.2.4. Méthode COCOMO (COnstructive COst Model)

Le modèle d’estimation COCOMO (COnstructive COst MOdel : modèle constructif de coûts)
a été introduit en 1981 par Barry Boehm. Ce modèle d’estimation des charges projet est
constructif car il permet de mieux prendre en compte la complexité logicielle et mieux appréhender
l’estimation.
Ce modèle cherche à limiter les erreurs de budget et les retards de livraison, qui sont monnaie
courante dans l’industrie de développement logiciel.
COCOMO à l'avantage d'être ouvert. Les données de calibrage, les formules et tous les détails des
définitions sont disponibles. La participation à son développement est encouragée.
Ainsi :
• Il est facile à un informaticien d'estimé le nombre de lignes source.
• La complexité d'écriture d'un programme est la même quelque soit le langage de
programmation.
• Il propose une méthode basée sur la corrélation entre la taille d'un projet et sa charge.

Formule
Charge = a.(Kisl)b
Délai = c.(Charge)d
Taille moyenne d'équipe = Charge / Délai
Avec
• Kisl = kilo instruction source livrée (lignes de
programme source testées)
• Les paramètres a, b, c et d qui dépendent de la catégorie
du projet.
Classification
Type de projet Charge en M/h Délai en M

Simple < 50 000 lignes a = 3.2 c = 2.5
b = 1.05 d = 0.38
Moyen 50 000 ≤ lignes ≤ 300 000 a=3 c = 2.5
b = 1.12 d = 0.35
Complexe > 300 000 lignes a = 2.8 c = 2.5
b = 1.2 d = 0.32
VIII. Tests de connaissances

1. Qu’est ce que projet ?
2. Quelles sont les contraintes liées à un projet ?
3. Quelles sont les outils utilisés dans la planification de projet ? Donner leur rôle et principe
de fonctionnement
4. Faire un tableau comparatif mettant en exergue les différentes méthodes d’estimation des
charges liées à un projet : Définition, principe de fonctionnement, avantages et
inconvénients

CHAPITRE VI : TEST D’UN LOGICIEL

I. Objectifs
Le test est une activité importante dont le but est d’arriver à un produit « zéro défaut ». C'est la
limite idéaliste vers laquelle on tend pour la qualité du logiciel. Généralement 40% du budget
global est consacrée à l’effort de test.
Dans l’absolu, l’effort de test (validation, intégration et unitaire) d’un logiciel peut être aussi
important que l’on veut. La combinatoire des données d’entrée, des modes d’utilisation, des modes
de fonctionnement, des paramètres d’exploitation, la variété des aspects vérifiables (conformités
aux spécifications, aux manuels d’utilisation et d’exploitation, aux exigences de robustesse, de
performance, d’ergonomie, comportement nominal, en cas de défaillance, etc.) sont telles qu’une
infinité de tests peut être menée sans qu’on soit certain de la conformité totale aux exigences.
II. Fondement du test (pourquoi réaliser un test ?)

Le test est une recherche d'anomalie dans le comportement du logiciel. C’est une activité
paradoxale : il vaut mieux que ce ne soit pas la même personne qui développe et qui teste le
logiciel. D’où le fait qu’un bon test est celui qui met à jour une erreur (non encore rencontrée).
Difficulté rencontrée : il faut arriver à gérer une suite de test la plus complète possible à un coup
minimal. Un test ne peut pas dire « il n'y a pas d'erreur » car il teste le logiciel de façon poussive (à
l’extrême) plus que dans l'utilisation réelle.

III. Cycle de développement du test
Spécification Spécification du
programme test
Scénario de test
Résultat attendu
Chargement du prog.
et de son
Exécution du
environnement test
Comparaison de
résultats
Correct incorrect on émet une hypothèse

qui expliquerait l’anomalie
Induction
Archivage du test Analyse de
+ résultats résultats
Déduction
On élimine les cas jusqu’à

Bibliothèque Modification « tomber » sur la problématique
Induite
Dans le test Dans le programme
Gestion de
configuration

III.1. Mise au point inductive

On met une hypothèse sur l’ensemble.
Localiser toutes les données

pertinentes
Organiser les données (classes

d’équivalence)
Données Insuffisantes
Etudier les relations et dépendances
fonctionnelles
Formuler (é mettre) une hypothèse
Inconsistance
Prouver l’hypothèse (Est-elle
pertinente ?)
Corriger l’erre ur
III.2. Mise au point déductive

On traite chaque cause séparément.
Enumé rer toutes les causes

possibles
Elimination progressive de toutes Rassembler plus de

les causes sauf une données
Emettre, améliore r, raffiner

l’hypothèse
Inconsistance
Prouver l’hypothèse (Est-elle
pertinente ?)
Corriger l’erre ur

IV. Les différents techniques de test

Plusieurs techniques dépendent de l’objectif du test. Mais aucune technique ne sera jamais
complète. Le problème est de savoir quelle technique nous assure la complétude, car en fait, aucune
ne peut le garantir.
Espace de cas possibles
Cela revient à échantillonner de façon représentative

Espace
générateur
Vocabulaire :
• Espace générateur : Il s’agit de l’ensemble des tests générés pour assurer la complétude du
logiciel
• Espace de cas possibles : Il s’agit de l’ensemble des erreurs possibles pouvant être
rencontrées sur le logiciel
Propriétés recherchées :
Si l’espace générateur est couvert alors la probabilité d'une défaillance dans l'espace de cas
possibles est très faible (inférieure à une limite fixée à l'avance). La difficulté est de faire que
l'espace générateur soit consistant et complet.
IV.1. Test statique

Test réalisé par l’humain par revue ou relecture du code.

IV.2. Test dynamique

Ici on exécute chaque module ou composante du logiciel avec des valeurs en entrée et on observe le
comportement.
PVIS DS Domaine de résultat
Instrument de Composante
visualisation
Données Code
DE Trace Suivi du chemin

d’exécution
Eléments d’entrés
IV.3. Test « Boîte blanche »

Ce test consiste à analyser la structure interne du programme en déterminant les chemins minimaux.
Afin d'assurer que:
• Toutes les conditions d'arrêt de boucle ont été vérifiées.
• Toutes les branches d'une instruction conditionnelle ont été testées.
• Les structures de données interne ont été testées (pour assurer la validité).

IV.3.1. Structures de la représentation de la boîte blanche

La structure de contrôle se présente sous la forme d'un graphe dit graphe de flot. On représente les
instructions comme cela :
• Suite linéaire : • Case :
• If : • Until :
• While (for) : • Else :
Remarque: If A & B & C ⇔ If A then if B then if C then…
IV.3.2. Mesure de complexité de Mac Cabr

Cette mesure donne le nombre de chemins minimaux. Elle est donnée par la formule suivante qui
correspond au nombre de régions du graphe de flot :
Nombre cyclomatique = Nb. Arcs – Nb. Nœuds + 2
Exemple : Supposons un programme représenté par l'organigramme suivant:
début
1
2
4
6
5
8 7
9
10
11

De ce programme, on en déduit le graphe de flot suivant :
2
R1
R4
3
6 4
R3
8 7 R2 5
9
11
10
Donc le nombre cyclomatique est : Nb.Arcs – Nb.Nœuds + 2 = 13 – 11 + 2 = 4
Pour vérifier, on regarde les chemins minimaux (un test par chemin pour tester toutes les
possibilités du programme) :
1. 1.11
2. 1.2.3.4.5.10.1.11
3. 1.2.3.6.7.9.10.1.11
4. 1.2.3.6.8.9.10.1.11
IV.4. Test « Boîte noire »

On ignore la structure de codage du logiciel
Principe :
1. On considère le programme dans son aspect fonctionnel et non plus structurel.

2. On partitionne le domaine DE ou éléments d’entrés en classes.
3. On génère des cas de test aux limites de classe.

Exemple :
Soit P un programme. Supposons que les données de P soient des nombre de cinq chiffres. Alors les
classes de nombre à cinq chiffres s'obtiennent de la manière suivante:
1. X < 10 000 2. 10000 ≤ X ≤ 99 999 3. X ≥ 100 000
Les cas de test aux limites de classes sont donc 00 000 et 09 999 pour la première classe, 10 000 et
99 999 pour la deuxième classe et 100 000 pour la troisième.
On a donc à tester les nombres suivants :
00 000 09 999 10 000 99 999 100 000

CHAPITRE VII : FIABILITE DU LOGICIEL

I. Objectifs
C’est la probabilité de faire une opération sans panne sur une durée fixée et pour un contexte donné.
La fiabilité est subjective : elle dépend de l’utilisateur et du contexte d’utilisation. Elle donne une
mesure du degré de confiance et elle mesure les conséquences d’une faute.
II. Défaut et faute

Un défaut est dû à la présence d’une faute. Il a une caractéristique essentiellement dynamique. Une
faute est une caractéristique statique du logiciel qui provoque un défaut à l’exécution.
Exemple
Pour un logiciel de saisie, une faute serait de ne pas vérifier la mauvaise saisie. Un défaut serait que
le logiciel plante suite à la mauvaise saisie.
Entrées possibles
Ie
Il est clair que toute faute ne
provoque pas nécessairement un
défaut, c’est possible si et seulement
PROGRAMME
si la donnée est prise dans la partie
fautive.
Oe
Sorties possibles

III. Amélioration de la fiabilité

Est-ce que la fiabilité est fonction de la correction de faute logicielle ? Non !!! Mais il faut quand
même corriger les fautes, surtout les fautes graves. Paradoxe : « Plus on augmente la fiabilité, plus
on réduit l’efficacité ». Pour assurer la fiabilité, on fait des tests, on rajoute du code (redondance,
vérification…). Ceci entraîne le fait que le logiciel sera plus lourd, plus lent donc moins efficace.
En général, on privilégie la fiabilité car l’efficacité devient de moins en moins nécessaire vu les prix
des machines actuelles. Cela est plus facile à améliorer.
IV. Métrique de la fiabilité

IV.1. Probabilité d’une panne
C’est la probabilité que le système se comporte de manière non prévue (non souhaitée) lorsqu’une
requête est effectuée.
Exemple
Système non stop, la probabilité de panne = 0.001 c'est-à-dire sur 1000 requêtes, on a une
probabilité d’un (01) défaut.
IV.2. Taux de panne

C’est la fréquence d’apparition d’un défaut.
Exemple
Système d’exploitation ou transactionnel, le taux de panne = 0.02 c'est-à-dire sur 100 unités de
temps, on a 2 défauts.
IV.3. Temps moyen entre deux pannes

C’est la mesure de temps entre deux apparitions de défauts.
Exemple
Réseau (essentiellement échange de gros fichiers), le temps moyen entre deux pannes =500 c'est-à-
dire le temps moyen entre deux défauts est de 500 unité de temps.

IV.4. Disponibilité
C’est la probabilité que le système soit opérationnel. Elle prend en compte le temps de réparation
éventuel.
Exemple
Centrale nucléaire, commande de refroidissement du noyau. Deux métriques principales :

disponibilité et probabilité. On peut avoir aussi les transmissions par un réseau concernant le temps
moyen de panne, systèmes de communication…
Disponibilité = 0,998 c'est-à-dire sur 1000 unités de temps, le système est disponible et utilisable
pendant 998 unités de temps.
Unité de temps
Elle dépend du système utilisé. Ainsi on a :

• Horloge interne pour le système « non-stop »
• Temps calendaire pour le système activité régulière
• Nombre de transaction pour le système fonctionnant à la demande.
V. Classification de défaut
CLASSE DE PANNE DESCRIPTION
Transitoire Ne se produit qu’avec certaines entrées.
Permanente Se produit avec toutes les entrées.
Réparable Ne nécessite pas d’intervention humaine.
Irréparable Nécessite une intervention de l’opérateur.
Non corruptrice Ne détruit, ni corrompt les données.
Corruptrice Corrompt les données. (INACCEPTABLE !!!)
VI. Exercice d’application

Distributeurs automatique de billets
Chaque distributeur est utilisé 300 fois par jour,

Une banque possède 1000 distributeurs,
La vie d’une version de distributeur est de deux ans,
Chaque distributeur traite environ 10 000 transactions par jour.
Question : Classer les pannes et proposer les métriques qui vont avec.
Solution
Classe de panne Exemple Métrique

Permanente et non Le système n’est plus opérationnel quelque Disponibilité : 1 par 1000
corruptrice soit la carte jours
Transitoire et non Les données sur la bande magnétique ne Taux de panne
corruptrice peuvent être lue sur certaines cartes (non
endommagées)
Transitoire et Le montant n’est pas correctement reporté Inqualifiable (ne devrait
corruptrice sur le compte. jamais arriver).

CHAPITRE VIII : MAINTENANCE DU LOGICIEL

I. Objectifs
• Gérer un processus de modification pour éviter que des corrections partielles soient faites en
dehors du processus d’itérations
• Fidéliser le client
Ainsi l’apprenant sera capable de :

• Comprendre la problématique de la réalisation et de la maintenance de logiciels.
• Situer les activités de réalisation et de maintenance dans le cycle de vie du logiciel.
• Connaître les approches contemporaines de réalisation et de maintenance. Savoir utiliser des
outils de contrôle du code source.
• Comprendre l'importance des activités d'assemblage et de déploiement des logiciels.
Connaître les principaux outils et techniques de test et pouvoir les utiliser (tests unitaires et
tests d'acceptation).
• Connaître et utiliser des outils d'analyse de code pour en évaluer la qualité et la
maintenabilité.
• Comprendre la notion de "dette technique" et le rôle du «refactoring»
• Se familiariser avec de nouvelles approches dans le domaine et de nouveaux langages de
programmation.
II. Les types de maintenance

II.1. La maintenance perfective ou évolutive
Elle consiste à maintenir les fonctionnalités antérieures tout en ajoutant des nouvelles
fonctionnalités qui modifient profondément l'architecture.
Exemple
• Changement d’OS
• Changement de SGBD…

II.2. La maintenance adaptative

Ajout de petites fonctionnalités qui ne modifie pas l'architecture.
Exemple
• Mise à l’euro
• Passage de données par fichiers…
II.3. La maintenance corrective

Critère important de la qualité qui corrige les anomalies ou erreurs mises à jour par le client et non
pas lors des tests de vérification et de validation.
II.4. Distribution de l'effort

III. Processus de la maintenance
Changement Analyse Planification Implémentation Edition

demandé d’impact de de changements d’une
modification nouvelle
version
Perfective Adaptative Corrective
III.1. Informations nécessaires pour la maintenance

Au niveau de l’équipe de développe ment
• Savoir si la maintenance est encore en place,

• Analyse : spécifications fonctionnelles,
• Listing de sources,
• Dossier de test,
• Algorithmes et les références,
• Options de compilations, standard utilisés…
Au niveau de l’utilisateur
• Anomalie ou erreur (description précise), ou nouvelle fonctionnalité,

• Contexte de l’erreur ou fonction,
• Données du client,
• Environnement technique…

III.2. Cycles de développement d’une correction
Reconstruction Simplification Analyse Intégration de

Début du contexte de du contexte déductive / la solution
l’erreur Inductive
Validation de
la correction
non régressive
Distribution
correction
fin
IV. Estimation du coût de la maintenance

IV.1. Formules
Dr Barry W. BOEHM à mesuré que les coûts annuels de maintenance sont trois à quatre fois ceux
du développement d'applications nouvelles. Ainsi, il proposa une formule d’estimation du coût de la
maintenance.
Charge brute annuelle de maintenance = Taux Annuel de Modification (TAM) x Charge

brute annuelle de développement
Charge brute annuelle de maintenance
Elle est exprimée en Mois/Homme (M/H). Elle correspond à l’effort annuel de maintenance
(EAM).

Taux Annuel de Modification (TAM)
Il est basé sur le pourcentage de ligne de code source du logiciel à corriger dans une année.
Nombre d’instructions modifiées

Nombre total d’instructions
Charge brute annuelle de développe ment
Elle est exprimée en Mois/Homme (M/H). Elle est obtenue à l’aide la méthode COCOMO lors de
l’estimation des charges liées au projet.
Le bénéfice sur le coût total de maintenance d’un système est proportionnel au pourcentage
d’investissement sur le développement.
IV.2. Exercice d’application

Enoncé
On a un logiciel qui a coûté 236 M/H et on estime le TAM = 15%.

Estimer l’effort de maintenance annuel (EAM) liée au projet.
Solution
EAM = 15% x 236 = 0.15 x 236 = 35.6

EAM = 35.6
V. Les effets de la maintenance

On distingue trois catégories d’effets :
V.1. Effet de bord du codage

• Modification ou suppression d’un sous programme
• Modification ou suppression d’un identifiant
• Opérations logiques
• Test de condition de sortie de boucle…

V.2. Effet de bord de données

Il est induit généralement par une modification d’une structure de données ou d’un champ, et peut
concerner :
• Réduction ou augmentation de la taille d’un tableau ou structure complexe
• Redéfinition de format de fichier
• Redéfinition de constante locale ou globale
• Réinitialisation d’un pointeur…
V.3. Effet de bord de la documentation

Concerne essentiellement l'adéquation entre le code source et les autres documents.
Remarque
Toute modification du code doit être reflétée dans les documents de maintenance, le manuel de
l’utilisateur et le document de conception.
VI. Maintenance du code étranger

Un code étranger est un programme (qui date de plus de 15 ans généralement) auquel aucun
membre de l’équipe de maintenance n’a participé à son développement. Aucune méthodologie du
génie logiciel n’a été appliqué (pas structuré, documentation pauvre et incomplète et pas de
sauvegarde de modification…). Que faire dans ce cas là ?
• Etudier le programme avant d'apporter une modification.
• Se familiariser avec le programme en essayant de tracer un graphe de flot.
• Evaluer l'adéquation de la documentation.
• Insérer vos propres commentaires si vous jugez cela utile à la compréhension.
• Ne jamais éliminer du code avant de s'assurer qu'il n’est pas utilisé ailleurs sinon avec
beaucoup de précautions.
• Indiquer absolument toute instruction que vous avez changée sur le listing.
• Eviter de partager les variables (locales), déclarer les votre pour éviter des collisions.

VII. Ré-ingénierie
Dans le domaine du génie logiciel, cela signifie processus qui ne consiste pas seulement à
redécouvrir la conception des logiciels existants mais aussi à utiliser cette information pour
reconstruire le système existant dans le but d'améliorer toutes ses qualités.
Quand décider la poursuite ou non de la maintenance ?
Cela dépend du coût d’un nouveau produit (analyse) par rapport à celui de la maintenance. Si ce
dernier est trop élevé, il est alors temps d'arrêter sa maintenance.
Est-il raisonnable qu’une entreprise envisage la ré-ingénierie de tous ses logiciels ?
Non, il y a des logiciels qui n’auront pas à évoluer, les besoins n’évoluant pas. D’autres au contraire
auront besoin d'évoluer rapidement.
VIII. Maintenance perfective ou évolutive

Considérons un programme « spaghettis » (programme non structuré). Que faire pour le maintenir ?
:
• On peut le refaire complètement en utilisant l'atelier de génie logiciel et les principes du
génie du logiciel.
• On peut travailler dessus jusqu'à l’arriver, modification après modification, au changement
nécessaire (en introduisant les principales de génie logiciel).
• On peut attendre de comprendre le fonctionnement et la structure interne avant toute
modification.
• On peut refaire une conception, implémenter et tester les parties du logiciel qui exigent une
modification.
Dans ce cas, quelle est la meilleure solution ?
Cela dépend de ce que l'on veut réaliser en fonction de l'importance du logiciel pour l'entreprise.
Quoi qu’il en soit, a priori la deuxième solution est la moins bonne (modification après
modification).

IX. Tests de connaissances

1. Citer et décrire les différents types de maintenance
2. Décrire le processus de maintenance
3. Quels sont les effets de maintenance ?
4. Comment réaliser la maintenance d’un code étranger ?
5. A quoi sert le processus de Ré- ingénierie ?
6. Quels sont les facteurs qui influent sur le coût de la maintenance ?

CHAPITRE IX : GESTION DE LA QUALITE

I. Objectifs
La gestion de la qualité est l'activité qui a pour but de donner confiance au client pour certifier que
le produit livré a une certaine qualité fixée par l’entreprise. La notion de qualité est relative et vise à
promouvoir le produit et l'entreprise. La gestion de la qualité implique la définition de procédés, le
choix de standards et procédures, et surtout le contrôle de l’équipe de développement qui doit suivre
les dispositifs mis en place pour les objectives qualités.
La gestion de la qualité s’articule autour de trois activités suivantes :

• Assurance qualité : concerne la définition de la manière dont l’entreprise compte atteindre
la qualité ;
• Planification qualité : sélection de procédures et standards appropriées pour un projet bien
déterminé ;
• Contrôle qualité : implique l'observation du processus de développement pour assurer que
les procédures d'assurance qualité ont été suivies.
II. Normalisation
La normalisation répond au souci d’interchangeabilité (ou interopérabilité). Dans le domaine du
logiciel, on distingue trois niveaux :
• 1er niveau : caractéristiques,
• 2ième niveau : modèle (Merise),
• 3ième niveau : la qualité (ISO 9001).
Classe ISO
• 9001 : concerne toute la vie du logiciel ;

• 9002 : ne concerne pas la conception ;
• 9003 : ne concerne que la mise en service et la maintenance ;
• 9004 : concerne le contrôle qualité (audit).
En fait, la normalisation définit les principes de base pour mettre en œuvre le contrôle qualité.

III. Manuel qualité

Le manuel qualité est le document qui contient le système mis en œuvre pour assurer la qualité.
On distingue deux types d’informations :

• Informations techniques : standards, procédures...
• Informations méthodologiques : méthodes de spécification, conception, développement.
La certification et valable trois ans en France (délivré par l’AFNOR). Cet organisme définit la
qualité ainsi : « c’est l'ensemble des propriétés et caractéristiques d'un produit ou d'un service qui
lui confère l'aptitude à satisfaire des besoins exprimés ou implicite ».
IV. Tests de connaissances

1. Définir qualité en génie logiciel
2. Donnez les différentes normes existant en ingénierie logiciel en spécifiant leur rôle.

Initiation Au GL

Transféré par

Informations du document

Description :

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Description :

Droits d'auteur :

Formats disponibles

Initiation Au GL

Transféré par

Description :

Droits d'auteur :

Formats disponibles

2018 / 2019

Initiation au Génie Logiciel

IV.2.1. La méthode FAST (Function Analysis System Technic) .......................................... 26

3 M. Marc TEJIOGN I | mtejiogni@yahoo.fr | Tél : 693 90 91 21 – 670 10 23 98

4 M. Marc TEJIOGN I | mtejiogni@yahoo.fr | Tél : 693 90 91 21 – 670 10 23 98

II.4. Distribution de l'effort ........................................................................................................ 69

5 M. Marc TEJIOGN I | mtejiogni@yahoo.fr | Tél : 693 90 91 21 – 670 10 23 98

6 M. Marc TEJIOGN I | mtejiogni@yahoo.fr | Tél : 693 90 91 21 – 670 10 23 98

CHAPITRE I : PRESENTATION DU GENIE LOGICIEL

II. Définition et principes d’ingénierie pour le

Nous avons sept principes fondamentaux pour l’ingénierie logicielle à savoir :

7 M. Marc TEJIOGN I | mtejiogni@yahoo.fr | Tél : 693 90 91 21 – 670 10 23 98

III. Processus de développement logiciel

III.1. Analyse des besoins

Spécification Cahier des charges

8 M. Marc TEJIOGN I | mtejiogni@yahoo.fr | Tél : 693 90 91 21 – 670 10 23 98

III.4. Programmation (Implémentation)

Programmation Code documenté

9 M. Marc TEJIOGN I | mtejiogni@yahoo.fr | Tél : 693 90 91 21 – 670 10 23 98

III.5. Validation et vérification

III.6. Intégration et tests (Déploiement)

10 M. Marc TEJIOGN I | mtejiogni@yahoo.fr | Tél : 693 90 91 21 – 670 10 23 98

E.B. Swanson (informaticien américain et remarquable professeur de systèmes d’information à la

Répartition des eﬀorts

Repartition des efforts

11 M. Marc TEJIOGN I | mtejiogni@yahoo.fr | Tél : 693 90 91 21 – 670 10 23 98

Rapport eﬀort /e rreur/coût

IV. Tests de connaissances

12 M. Marc TEJIOGN I | mtejiogni@yahoo.fr | Tél : 693 90 91 21 – 670 10 23 98

CHAPITRE II : CYCLE DE VIE DU LOGICIEL

• Phases de construction, d’installation, d’exploitation et d’entretien :

• Phase de mise au rebut ou de mise hors service :

13 M. Marc TEJIOGN I | mtejiogni@yahoo.fr | Tél : 693 90 91 21 – 670 10 23 98

II. Différents cycles de vie

1. On ne peut passer à l’étape suivante tant la précédente n’est pas terminée.

• Produit des livrables définis au préalable ;

Le cycle en V va être constitué de 9 étapes :

15 M. Marc TEJIOGN I | mtejiogni@yahoo.fr | Tél : 693 90 91 21 – 670 10 23 98

16 M. Marc TEJIOGN I | mtejiogni@yahoo.fr | Tél : 693 90 91 21 – 670 10 23 98

Inconvénients : les mêmes que le cycle en cascade

• Processus lourd, difficile de revenir en arrière

II.3. Cycle en spirale

Un modèle mixte recommencé à chaque cycle :

C’est un modèle itératif ou répétitif et incrémental.

17 M. Marc TEJIOGN I | mtejiogni@yahoo.fr | Tél : 693 90 91 21 – 670 10 23 98

II.4. Développement par prototypage

Validation concrète des besoins, moins de risques d'erreur de spéciﬁcation

18 M. Marc TEJIOGN I | mtejiogni@yahoo.fr | Tél : 693 90 91 21 – 670 10 23 98

• Il échoue le plus souvent dans la réplication du produit ou du système réel.

II.5. Développement incrémental

19 M. Marc TEJIOGN I | mtejiogni@yahoo.fr | Tél : 693 90 91 21 – 670 10 23 98

II.6. Méthodes agiles

III. Tests de connaissances

20 M. Marc TEJIOGN I | mtejiogni@yahoo.fr | Tél : 693 90 91 21 – 670 10 23 98

CHAPITRE III : ANALYSE DES BESOINS ET

II. Intérêt de l’analyse des besoins

Si le besoin est mal compris, il sera mal couvert !

III. Concepts de base

Notion de client interne et client externe

III.2. Qu’est-ce qu’un besoin, une fonction, un produit ou un

Un besoin peut être :