Introduction au Génie Logiciel : 4 crédits (60 heures); CM, TD, TPE

Table des matières

Introduction au Génie Logiciel : 4 crédits (60 heures); CM, TD, TPE ............................................................. 1
Objectif du module : .................................................................................................................................. 3
Chapitre 1. Notion de génie logiciel..................................................................................................... 4
Définitions ..................................................................................................................................... 4
Environnement du logiciel............................................................................................................. 4
Crise du logiciel .......................................................................................................................... 5
Raisons de la faible qualité des logiciels.................................................................................... 7
Importance de la qualité des logiciels ........................................................................................... 8
Qualité du logiciel ...................................................................................................................... 9
Principes utilisés dans le Génie Logiciel .................................................................................. 10
Chapitre 2. Processus de développement logiciel .............................................................................. 11
Activités du développement logiciel ou Cycle de vie .................................................................. 11
Documentation............................................................................................................................ 19
Modélisation des processus logiciels ...................................................................................... 21
Chapitre 3. Gestion de projets ............................................................................................................ 24
I. Pratiques du chef de projet ......................................................................................................... 24
II. Planification des projets .............................................................................................................. 28
III. Analyse et gestion des risques ................................................................................................ 41
IV. Test logiciel .............................................................................................................................. 43
Chapitre 4. L’ergonomie du logiciel .................................................................................................. 52
Problématique de l’ergonomie : ................................................................................................. 52
La place des technologies cognitives dans l’ergonomie.............................................................. 53
La prise en compte de l’ergonomie dans le développement d’IHM et plus spécifiquement
dans le développement d’applications Web ....................................................................................... 55
Chapitre 5. Production du code source............................................................................................... 61
Introduction ................................................................................................................................. 61
Convention de nommage ............................................................................................................ 61

1
Ing. NTOH MOUALAM Annick
 Langue utilisée ......................................................................................................................... 62
Formatage du code.................................................................................................................. 62
Commentaires ............................................................................................................................. 63
Chapitre 6. Systèmes de gestion de versions..................................................................................... 65
Notion de gestion de versions ..................................................................................................... 65
Application concrète : une infrastructure ................................................................................... 65
La gestion des versions d'un logiciel, en utilisant comme exemple l'outil Git. ....................... 66
Les logiciels de gestion des versions ....................................................................................... 67
Chapitre 7. Travail collaboratif ........................................................................................................... 71
Les enjeux du travail collaboratif ................................................................................................ 71
Présentation de GitHub ............................................................................................................... 71
Chapitre 8. Documentation ................................................................................................................ 75
Introduction ................................................................................................................................. 75
Documentation technique .......................................................................................................... 75
La documentation utilisateur .................................................................................................. 80
Conseils de rédaction .............................................................................................................. 82
Chapitre 9. Architecture logicielle...................................................................................................... 83
Définition ..................................................................................................................................... 83
Importance .................................................................................................................................. 83
Objectifs................................................................................................................................... 83
Architecture ou conception ? .................................................................................................. 84
L'activité d'architecture ............................................................................................................... 84
L'architecture d'un logiciel ...................................................................................................... 85
Chapitre 10. Principes de conception .................................................................................................. 86

2
Ing. NTOH MOUALAM Annick
 Objectif du module :
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

Ce cours permet de répondre à :

 Comment faire des logiciels de qualité ?

 Qu’attend-on d’un logiciel ? Quels sont les critères de qualité pour un logiciel ?

A la fin de ce cours l’étudiant doit être capable de :

 Analyser les besoins du client.

 Définir l'architecture du logiciel.
 Faire un Choix de conception.
 Définir des règles et méthodes de production du code source.
 Gérer des versions.
 Faire des Test du logiciel.
 Produire une Documentation.
 Organiser l'équipe et interagir avec le client.

3
Ing. NTOH MOUALAM Annick
 Chapitre 1. Notion de génie logiciel
Définitions

Génie logiciel

Idée : appliquer les méthodes classiques d'ingénierie au domaine du logiciel

Ingénierie (ou génie) : Ensemble des fonctions allant de la conception et des études à la responsabilité de la
construction et au contrôle des équipements d'une installation technique ou industrielle

Exple : Génie civil, naval, aéronautique, mécanique, chimique...

Logiciel :

Ensemble d'entités nécessaires au fonctionnement d'un processus de traitement automatique de l'information

Exple : Programmes, données, documentation...

Ensemble de programmes qui permet à un système informatique d’assurer une tâche ou une fonction en
particulier

Logiciel = programme + utilisation

Génie logiciel : Ensemble des méthodes, des techniques et des outils dédiés à la conception, au
développement et à la maintenance des systèmes informatiques.

Environnement du logiciel

4
Ing. NTOH MOUALAM Annick
● utilisateurs : grand public (traitement de texte), spécialistes (calcul météorologique), développeurs
(compilateur)

● autres logiciels : librairie, composant

● matériel : capteurs (système d'alarme), réseau physique (protocole), machine ou composant matériel
contrôlé.

Spécification : ce que doit faire le logiciel, ensemble de critères que doivent satisfaire son fonctionnement
interne et ses interactions avec son environnement.

Crise du logiciel
Constat du développement logiciel fin années 60 :

● délais de livraison non respectés

● budgets non respectés

● ne répond pas aux besoins de l'utilisateur ou du client

● difficile à utiliser, maintenir, et faire évoluer

5
Ing. NTOH MOUALAM Annick
 6
Ing. NTOH MOUALAM Annick
« La satisfaction du client et la valeur du produit sont plus grandes lorsque les fonctionnalités livrées sont
bien moins nombreuses que demandé et ne remplissent que les besoins évidents. »

Raisons de la faible qualité des logiciels

1) Tâche complexe :
● Taille et complexité des logiciels

● Taille des équipes de conception/développement

2) Manque de méthodes et de rigueur :

● Manque de méthodes de conception

● Négligence et manque de méthodes et d'outils des phases de validation/vérification

3) Mauvaise compréhension des besoins :

● Négligence de la phase d'analyse des besoins du client

● Manque d'implication du client dans le processus

7
Ing. NTOH MOUALAM Annick
 4) Difficultés spécifiques du logiciel :
● Produit invisible et immatériel

● Difficile de mesurer la qualité

● Conséquences critiques causées par modifications infimes

● Mises à jour et maintenance dues à l'évolution rapide de la technologie

● Défaillances logicielles principalement humaines

Importance de la qualité des logiciels

 Fiabilité, sûreté et sécurité des logiciels est importante dans les domaines suivants :

● Transports automobile, ferroviaire, aéronautique

● Contrôle de processus industriels, nucléaire, armement

● Médical : imagerie, appareillage, télé-surveillance

● e-commerce, carte bancaire sans contact, passeport électronique

 Raisons économiques : coût d'un bug

● Coût de la correction, du rappel des appareils défectueux

● Coût de l'impact sur l'image, de l'arrivée tardive sur le marché

8
Ing. NTOH MOUALAM Annick
● Coût en vies, coût de l'impact écologique

Qualité du logiciel
Critères de qualité :

● Validité : réponse aux besoins des utilisateurs

● Facilité d'utilisation : prise en main et robustesse

● Performance : temps de réponse, débit, fluidité...

● Fiabilité : tolérance aux pannes

● Sécurité : intégrité des données et protection des accès

● Maintenabilité : facilité à corriger ou transformer le logiciel

● Portabilité : changement d'environnement matériel ou logiciel

9
Ing. NTOH MOUALAM Annick
 Principes utilisés dans le Génie Logiciel

 Généralisation : regroupement d’un ensemble de fonctionnalités semblables en une fonctionnalité´

paramétrable (généricité, héritage)
 Structuration : façon de décomposer un logiciel (utilisation d’une méthode bottom-up ou top-down)
 Abstraction : mécanisme qui permet de présenter un contexte en exprimant les éléments pertinents
et en omettant ceux qui ne le sont pas.
 Modularité : décomposition d’un logiciel en composants discrets
 Documentation : gestion des documents incluant leur identification, acquisition, production,
stockage et distribution.
 Vérification : détermination du respect des specifications établies sur la base des besoins identifiés
dans la phase précédente du cycle de vie

10
Ing. NTOH MOUALAM Annick
 Chapitre 2. Processus de développement logiciel

Le cycle de vie désigne l’ensemble d'activités successives, organisées en vue de la production d'un logiciel

Les modèles décrivent les liens, les relations entre les différentes étapes du cycle de vie du logiciel.

Les méthodes permettent de mettre en œuvre un développement logiciel selon un modèle en organisant les
différentes étapes du cycle de vie du logiciel.

En pratique :

● Pas de processus idéal

● Choix du processus en fonction des contraintes (taille des équipes, temps, qualité...)

● Adaptation de « processus types » aux besoins réels

Activités du développement logiciel ou Cycle de vie

● Analyse des besoins

● Spécification

● Conception

● Programmation

● Validation et vérification

● Livraison

● Maintenance

Pour chaque activité : Utilisation et production de documents

1) Analyse des besoins : Comprendre les besoins du client

● Objectifs généraux, environnement du futur système, ressources disponibles, contraintes de
performance…

● Fournie par le client (expert du domaine d'application, futur utilisateur…)

2) Spécification :
● Établir une description claire de ce que doit faire le logiciel (fonctionnalités détaillées, exigences de
qualité, interface…)

● Clarifier le cahier des charges (ambiguïtés, contradictions) en listant les exigences fonctionnelles et non
fonctionnelles

11
Ing. NTOH MOUALAM Annick
 3) Conception : Élaborer une solution concrète réalisant la spécification
● 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é…)

4) Programmation : Implantation de la solution conçue

● Choix de l'environnement de développement, du/des langage(s) de programmation, de normes de
développement...

5) Validation et vérification
Objectifs :

● Validation : assurer que les besoins du client sont satisfaits (au niveau de la spécification, du produit
fini...)

● Vérification : assurer que le logiciel satisfait sa spécification

6) Maintenance
Types de maintenance :

● Correction : identifier et corriger des erreurs trouvées après la livraison

● Adaptation : adapter le logiciel aux changements dans l'environnement (format des données,
environnement d'exécution...)

12
Ing. NTOH MOUALAM Annick
● Perfection : améliorer la performance, ajouter des fonctionnalités, améliorer la maintenabilité du logiciel

13
Ing. NTOH MOUALAM Annick
 7) Processus en cascade
Chaque étape doit être terminée avant que ne commence la suivante

À chaque étape, production d'un document base de l'étape suivante

14
Ing. NTOH MOUALAM Annick
Caractéristiques :

● Hérité des méthodes classiques d'ingénierie

● 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 modification d'une erreur important, donc choix en amont cruciaux (typique d'une production
industrielle)

Pas toujours adapté à une production logicielle, en particulier si besoins du client changeants ou difficiles à
spécifier

8) Processus en V
Caractéristiques :

● Variante du modèle en cascade

● Mise en évidence de la complémentarité des phases menant à la réalisation et des phases de test permettant
de les valider

15
Ing. NTOH MOUALAM Annick
 a) Niveaux de test
 Test unitaire : test de chaque unité de programme (méthode, classe, composant), indépendamment
du reste du système
 Test d'intégration : test des interactions entre composants (interfaces et composants compatibles)
 Test système : test du système complet par rapport à son cahier des charges
 Test d'acceptation (recette) : fait par le client, validation par rapport aux besoins initiaux

9) Développement par prototypage

Prototype : version d’essai du logiciel

 Pour tester les différents concepts et exigences

 Pour montrer aux clients les fonctions que l’on veut mettre en œuvre

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

16
Ing. NTOH MOUALAM Annick
Avantage : Validation concrète des besoins, moins de risques d'erreur de spécification. Les efforts consacrés
au développement d’un prototype sont le plus souvent compensés par ceux gagnés à ne pas développer de
fonctions inutiles

10) Développement incrémental

Principe :

 Concevoir et livrer au client un sous-ensemble minimal et fonctionnel du système

 Procéder par ajouts d’incréments minimaux jusqu’à la fin du processus de développement
 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, meilleure intégration du client dans la boucle,
produit conforme à ses attentes

Difficulté : Intégration fonctionnalités secondaires non pensées en amont

11) Le modèle en Spirale de Boehm

Un modèle mixte

17
Ing. NTOH MOUALAM Annick
A chaque cycle, recommencer :

 Consultation du client
 Analyse des risques
 Conception
 Implémentation
 Tests
 Planification du prochain cycle

Avantages : meilleure maitrise des risques, mais nécessite une (très) grande expérience

12) Méthodes agiles et Extreme Programming

Principes :

● 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

Avantages : développement rapide en adéquation avec les besoins

Inconvénients : pas de spécification, documentation = tests, maintenance ?

18
Ing. NTOH MOUALAM Annick
Fonctionne pour petites équipes de développement (< 20) car communication cruciale

Documentation
Objectif : Traçabilité du projet

 Pour l'équipe :

● Regrouper et structurer les décisions prises

● Faire référence pour les décisions futures

● Garantir la cohérence entre les modèles et le produit

 Pour le client :

● Donner une vision claire de l'état d'avancement du projet

 Base commune de référence :

● Personne quittant le projet : pas de perte d'informations

● Personne rejoignant le projet : intégration rapide

1) Documents de spécification et conception

b) Rédaction : le plus souvent en langage naturel (français)

 Problèmes :

● Ambiguïtés : plusieurs sens d'un même mot selon les personnes ou les contextes

● Contradictions, oublis, redondances difficiles à détecter

● Difficultés à trouver une information

● Mélange entre les niveaux d'abstraction (spécification vs. conception)

c) Alternatives au langage naturel

 Langages informels :

● Langage naturel structuré : modèles de document et règles de rédaction précis et documentés

● Pseudo-code : description algorithmique de l'exécution d'une tâche, donnant une vision opérationnelle du
système

 Langages semi-formels :

● Notation graphique : diagrammes accompagnés de texte structuré, donnant une vue statique ou dynamique
du système

19
Ing. NTOH MOUALAM Annick
  Langages formels :

● Formalisme mathématique : propriétés logiques ou modèle du comportement du système dans un langage

mathématique

 Langages informels ou semi-formels :

✔Avantages : intuitifs, fondés sur l'expérience, facile à apprendre et à utiliser, répandus

✗ Inconvénients : ambigus, pas d'analyse systématique

 Langages formels :

✔Avantages : précis, analysables automatiquement, utilisables pour automatiser la vérification et le test

du logiciel

✗ Inconvénients : apprentissage et maîtrise difficiles

En pratique : utilisation de langages formels principalement pour logiciels critiques, ou restreinte aux parties
critiques du système.

2) Documents courants
 Cahier des charges : Description initiale des fonctionnalités désirées, généralement écrite par
l’utilisateur
 Spécifications : Décrit précisément les conditions que doit remplir le logiciel
 Modèle objet : indique les classes et les documents principaux
 Scénarios des cas d’utilisation : indique les differents enchaînements possibles du point de vue de
l’utilisateur
 Calendrier du projet : Ordre des differentes tâches ; Details et ressources qu’elles demandent

 Plan de test du logiciel : Décrit les procédures de tests appliquées au logiciel pour contrôler son bon
fonctionnement
 Tests de validation : tests choisis par le client pour déterminer s’il peut accepter le logiciel

 Plan d’assurance qualité : Décrit les activités mises en œuvre pour garantir la qualité du

Logiciel

 Manuel utilisateur : Mode d’emploi pour le logiciel dans sa version finale

 Code source : Code complet du produit fini
 Rapport des tests : Décrit les tests effectués et les réactions du système
 Rapport des défauts : Décrit les comportements du système qui n’ont pas satisfait le client

Il s’agit le plus souvent de défaillances du logiciel ou d’erreurs

20
Ing. NTOH MOUALAM Annick
 Documents produits dans le cycle de vie

Modélisation des processus logiciels

 Les modèles en V, spirale... sont des archétypes de modèles
o On peut les adapter à des projets particuliers
 On peut vouloir représenter le processus de développement (et ses parties) de manière plus fine
o Une modélisation précise limite les risques d’ambigüité
 Il est nécessaire de se doter d’un formalisme pour représenter le processus de développement
o Pour ordonner les tâches
o Pour déterminer les échanges d’information entre les differentes tâches
o Pour permettre aux jeunes recrues de mieux travailler

21
Ing. NTOH MOUALAM Annick
 1) Modèle de processus logiciels
 Un modèle de processus logiciels décrit
o Les tâches
o Les artefacts (fichiers, documents, données...)
o Les auteurs
o Les décisions (facultatif)
 Règles à observer
o Deux tâches doivent être séparées par un artefact
o Une tâche ne peut être exécutée tant que ses artefacts d’entrée n’existent pas
o Il doit y avoir au moins une tâche de début et une de fin
o Il doit y avoir un trajet depuis chaque tâche jusqu’à la tâche de fin

d) Exemples de processus logiciels

2) Diagrammes de flots de données

 Indique la circulation des données à travers un ensemble de composants qui peuvent être
o Des tâches
o Des composants logiciels...
 Règles à observer
o Les processus sont représentés par des cases qui contiennent des phrases verbales
o Les flèches représentent des données et doivent être accompagnées de phrases nominales
o Un processus peut être une activité´ ponctuelle ou continue

22
Ing. NTOH MOUALAM Annick
 o Deux flèches sortant d’une case peuvent indiquer
• Soit deux sorties simultanées
• Soit deux sorties exclusives

e) Exemples de diagramme de flots de données

pour représenter (x + y) × (w + z)

23
Ing. NTOH MOUALAM Annick
 Chapitre 3. Gestion de projets

 Problèmes souvent humains

o Planifier la progression
o Motiver et coordonner un groupe de professionnels
 Techniques souvent communes à la gestion de projet en général
 Problème particulier de la visibilité´
o Un projet logiciel apparaitra souvent à ses développeurs comme presque achevé alors qu’il
ne l’est qu’à 90%

I. Pratiques du chef de projet

 Opter pour une gestion des risques continue

o Prévoir des étapes reparties sur l’ensemble du cycle de vie consacrées a` l’identification et
a l’évaluation des risques, ainsi que des tâches pour y remédier
 Estimer les coûts et planifier le projet à partir de données empiriques
o prévoir une étape au début du cycle de vie pour évaluer le coût du projet et une série d’étapes
ultérieures pour raffiner cette estimation. Au cours de chaque étape, les données devront
être archivées pour les évaluations ultérieures
 Utiliser des métriques pour la gestion du projet
o Choisir des métriques et prévoir des étapes pour enregistrer les valeurs de celles-ci, et
d’autres pour analyser les progrès en fonction de ces résultats
 Suivre l’évolution de la valeur acquise
 Rechercher les défauts en fonction des objectifs de qualité
o Déterminer des objectifs pour le nombre de rapports d’erreurs et prévoir des étapes pour
communiquer ces résultats
 Considérer les employés comme la ressource la plus importante
o Contrôler l’ensemble du processus logiciel pour estimer son impact sur le programmeur
 Utiliser un outil de gestion de configuration
o Assurer que les modifications du logiciel sont effectuées de manière à minimiser les coûts
globaux
o Garder la trace des differences entre les versions pour contrôler les nouvelles versions.
 Gérer et suivre l’évolution des besoins
o Prévoir des étapes pour recueillir les besoins des utilisateurs
 Orienter la conception en fonction du système visé
 Definir et contrôler les interfaces
 Concevoir plusieurs fois pour ne coder qu’une seule
o Prévoir des étapes pour contrôler la conception
 Identifier les éléments potentiellement réutilisables
 Contrôler les specifications
 Organiser les tests comme un processus continu
o Prévoir des étapes de tests dans toutes les phases

24
Ing. NTOH MOUALAM Annick
 1) Analyse de la valeur acquise
f) Mesures de base

 CBT : cout budgété du travail

Quantité de travail estimée pour une tâche donnée

 CBTP : coût budgété du travail prévu

Somme des quantités de travail estimées pour l’ensemble des tâches devant être achevées à une date
donnée

 CBA : coût budgété a` l’achèvement

Total des CBTP et donc l’estimation de la quantité de travail pour le projet entier

 VP : valeur prévue

Proportion de la quantité de travail totale estimée attribuée à une tâche donnée

VP = CBT/CBA(cout estimé/achevé)
 CBTE : coût budgété´ du travail éffectué
Somme des quantités de travail estimées pour les tâches achevées à une date donnée

 CRTE : coût réel du travail éffectué

Somme des quantités de travail réelles pour l’ensemble des tâches du projet.

g) Indicateurs d’avancement

 VA : Valeur acquise

VA = CBTE/CBA

= somme des VP pour les tâches achevées

= PA (pourcentage achevé)

 IPT : indicateur de performance temporel

IPT = CBTE/CBTP

 VE : variance par rapport à` l’échéancier

VE = CBTE −CBTP

 IC : indicateur d’écart sur les coûts

25
Ing. NTOH MOUALAM Annick
IC = CBTE/CRTE

 VC : variance par rapport aux coûts

VC = CBTE −CRTE

Exemple 1

Problème : calculer les indicateurs d’avancement au 01/04

CBA : somme des estimations des quantités de travail (somme du trav estimé)

CBA = 330jh

 Au 01/04, les tâches 1,2 et 4 sont achevées

Le CBTE est la somme des CBT pour ces tâches(som trav estimé tach 1,2 et 4)

CBTE = 70jh

VA = 70/330 = 21.2%(pourcentage achevé ;somme des valeur prevue pour les taches achevé)

Les tâches 1 et 2 devraient être achevées pour le 01/04, et pas 1,2 et 4

CBTP = 30( somm trav estimé 1 et 2)

IPT = 70/30 = 233% (indicateur de performance temporel)

 SV = 70 − 30 = +40jh ( variance par rapport à` l’échéancier)

La CRTE est la somme des quantités de travail réelles pour les tâches 1,2 et 4

CRTE = 80jh

IC = 70/80 = 87.5%

VC = 70 − 80 = −10jh

26
Ing. NTOH MOUALAM Annick
Exemple 2
Problème : que deviennent ces indicateurs, à supposer que la tâche 3 a également été achevée avec 140jh de
travail et que nous sommes le 01/07 ?

CBTE = 190jh

CBTP = 250jh

CRTE = 220jh

VA = 190/330 = 57.5%

IPT = 190/250 = 76%

VE = 190 − 250 = −60jh

Seules les tâches 1–4 sont réalisées, au lieu de 1–5

IC = 190/220 = 86.6%

VC = 190 − 220 = −30jh

2) Suivi des erreurs

Le suivi des erreurs permet de :
 Conserver une trace des
o Erreurs qui se sont produites
o Durées entre deux erreurs successives
 Mieux déterminer une date de livraison
 Motiver les testeurs et les développeurs

h) Taux d’erreur

 TE : Inverse du temps qui sépare deux erreurs successives

Ex : si une erreur se produit tous les deux jours, TE = 0.5 erreurs par jour

27
Ing. NTOH MOUALAM Annick
  Taux d’erreur instantané : estimation du taux d’erreur courant
 Taux d’erreur cumulé : bonne estimation des taux d’erreur à venir

Somme de toutes les erreurs divise´ par le temps total

 Une représentation graphique permet d’estimer les tendances des taux d’erreur par régression
linéaire

y : taux d’erreurs

x : deux possibilités :

Nombre d’erreurs : donne une estimation du nombre d’erreurs restantes

Temps écoulé : donne une estimation du temps avant livraison

Exemple
Les durées entre une série d’erreurs sont les suivantes : 4, 3, 5,

6, 4, 6, 7

Si on prolonge cette courbe, on voit qu’elle coupe l’axe des abscisses pour une valeur de 11 erreurs environ

Le taux d’erreur devrait donc être nul après la 11ème erreur

Comme 7 erreurs ont été´ trouvées, il ne devrait plus en rester que 4

II. Planification des projets

Elément indispensable de la conduite de projets.

Permet de :

 Déterminer les tâches à accomplir

28
Ing. NTOH MOUALAM Annick
  Déterminer l’ordre des tâches
 Décider des ressources allouées à chaque tâche

1) Organigramme technique
i) Work Breakdown Structure (WBS)
Objectif : Diviser les tâches principales en tâches plus petites.

Nécessité de :

 Pouvoir identifier leurs differentes parties

 Trouver des livrables et des jalons qui permettront de mesurer l’avancement du projet

WBS Work Breakdown Structure : organigramme technique

 Structure arborescente
 Le premier niveau de décomposition correspond souvent au modèle de cycle de vie adopté

j) Règles d’obtention d’un organigramme technique (WBS)

 Structure arborescente
o Pas de boucle
o Les actions itératives apparaissent dans le modèle de processus ou dans le modèle de cycle
de vie.
 Les descriptions des tâches et des livrables doivent être claires et sans ambigüité
o Chaque livrable doit être associe à une tâche, sans quoi il ne sera pas produit
 Chaque tâche doit avoir un critère d’achèvement
o Le plus souvent un livrable
 L’achèvement de toutes les sous-tâches doit entrainer l’achèvement de la tâche

Exemple
Modèle de cycle de vie pour la consommation de tartines

29
Ing. NTOH MOUALAM Annick
Modèle de processus pour cuisiner du pain

Choisir la recette

Réunir les ingrédients → Ingrédients réunis

Cuisiner

Manger

Nettoyer

Choisir la recette

Choisir les ingrédients → Liste des ingrédients

Verifier leur disponibilité´ → Liste de courses

Réunir les ingrédients → Ingrédients réunis

Cuisiner

Manger

Nettoyer

30
Ing. NTOH MOUALAM Annick
Choisir la recette

Réunir les ingrédients → Ingrédients réunis

Cuisiner

Mélanger

Cuire → Pain cuit

Manger

Nettoyer

Choisir la recette

Réunir les ingrédients → Ingrédients réunis

Cuisiner

Mélanger

Ajouter l’eau → Saladier d’eau

Ajouter la levure et la farine → Mélange

Faire la pâte → Pâte

Laisser lever 1 → Pâte levée

Ajouter le reste de farine et pétrir → Pâte pétrie

Laisser lever 2 → Pâte pétrie et levée

Former des miches → Miches

Laisser lever 3 → Miches levées

Cuire → Pain cuit

Manger

Nettoyer

Choisir la recette

Réunir les ingrédients → Ingrédients réunis

Cuisiner

Manger

31
Ing. NTOH MOUALAM Annick
Découper en tranches → Tranches de pain

Beurrer → Tartines beurrées

Manger → Goût satisfaisant

Nettoyer

Nettoyer ustensiles → Ustensiles propres

Nettoyer cuisine → Cuisine propre

2) La méthode PERT
Program Evaluation and Review Technique

1. Identifier les tâches et estimer leur durée

2. Ordonner les tâches
3. Construire le réseau et l’exploiter

32
Ing. NTOH MOUALAM Annick
 k) Identification des tâches et de leur durée

l) Ordonnancement des tâches

33
Ing. NTOH MOUALAM Annick
 m) Construction du réseau

Les tâches A, D et E peuvent se faire en parallèle

Il faut qu’elles soient toutes deux finies pour pouvoir débuter

F, d’ou` les tâches fictives de durée nulle de 3 a` 4 et de 2 a` 4.

La crêpe doit être cuite (I) et le mélange doit être flambé (H) pour pouvoir commencer à verser du mélange
sur la crêpe (J)

n) Exploitation d’un réseau PERT

 Calcul des dates au plus tôt de chaque étape

Quand se terminera le projet ? Quel est le délai nécessaire pour atteindre une étape déterminée ?

Elles se calculent de gauche à droite en partant de 0 et rajoutant la durée de la tâche à la date précédente. En
cas de convergence, on prend la valeur la plus élevée.

 Calcul des dates au plus tard de chaque étape

Quand doit démarrer le projet pour être achevé à temps ? A quelle date chaque étape doit-elle être atteinte
pour que le projet ne prenne pas de retard ?

Elles se calculent de droite a` gauche en partant de la date de fin au plus tard et en retranchant la durée de la
tâche à la date précédente. En cas de convergence comme au 7 niveau on prend la valeur la plus faible

 Calcul des marges et du chemin critique

34
Ing. NTOH MOUALAM Annick
 o Chemin critique

On peut dès maintenant répondre à certaines questions

La crêpe sera mangée à la date 773 (soit à peu près 13 mn après le début de la fabrication)

Il faut avoir fini la sauce au plus tard à la date 643 (étape 10)

On pourra mélanger le rhum et les bananes au plus tôt à la date 300 (étape 4)

On remarque aussi que certaines étapes ont une marge nulle et que pour d’autres on est plus libre

Le chemin critique relie les étapes qui n’ont aucune marge

Un retard dans une tâche sur le chemin critique entrainera un retard dans le projet entier

L’analyse des temps de battements peut motiver une réaffectation des ressources associées à chaque tâche

3) Autres modèles

o) Diagrammes de Gantt
Utilise les dates au plus tôt et des dates au plus tard

Permet d’d’établir un planning en fonction des ressources

35
Ing. NTOH MOUALAM Annick
Devoirs :télécharger l’application Gantt Project

4) Estimation des coûts

36
Ing. NTOH MOUALAM Annick
 a) Le modèle COCOMO de base
COnstructive COst Model

Développé à la firme TRW (organisme du DoD, USA) par B.W. Boehm et son équipe

Fondé sur une base de données de plus de 60 projets differents

Modèle d’estimation du coût de développement d’un logiciel en nombre de mois-hommes (E : effort) du

temps de développement en mois (TDEV) en fonction du nombre de lignes de codes en milliers (KLOC)

b) Trois types de projets

 Mode organique

Petites équipes

Applications maitrisées et problèmes bien compris

Pas de besoins non fonctionnels difficiles

 Mode semi-détaché

Expérience variée des membres de l’équipe de projet

Possibilité l’avoir des contraintes non fonctionnelles importantes

Type l’application non maitrisée par l’organisation

 Mode embarqué

Contraintes serrées

L’équipe de projet a, en général, peu d’expérience de l’application

Problèmes complexes

c) Calcul de l’effort

Formule générale

a et b estimés en fonctions de données empiriques

Organique

Semi-détaché´

37
Ing. NTOH MOUALAM Annick
Embarque

d) Calcul du temps de développement

e) Modèle COCOMO intermédiaire

Estimation modifiant l’estimation brute fournie par le modèle COCOMO de base en se servant des attributs

 Logiciel
 Matériel
 Projet
 Personnel

f) Les attributs du logiciel

g) Besoin en fiabilité
h) Taille de la Base de Données
i) Complexité´ du produit

j) Les attributs du matériel

 Contraintes sur le temps l’exécution
 Contraintes sur la mémoire
 Contraintes sur le stockage
 Contraintes du temps de passage entre deux processus (synchronisation)

...

38
Ing. NTOH MOUALAM Annick
 k) Les attributs du projet

 Techniques de programmation moderne

 Programmation Orientée Objet
 Programmation Evènementielle
 Utilisation l’Ateliers de Génie Logiciel (CASE)
 Contraintes de développement
 Délais
 Budget

l) Les attributs du personnel

 Compétence de l’analyste
 Compétence du programmeur
 Expérience dans l’utilisation du langage de programmation
 Expérience dans le domaine de l’application
 Expérience dans l’utilisation du matériel

m) Calcul de l’éffort

n) Modèle COCOMO expert

Inclue toutes les caractéristiques du modèle intermédiaire

 Ajouts :
o L’impact de la conduite des coûts sur chaque étape du cycle de développement
o Le projet est analysé comme une hiérarchie : module, sous-système et système
 COCOMO expert permet une véritable gestion de projet
o Utile pour de grands projets

39
Ing. NTOH MOUALAM Annick
 o Ajustement des paramètres possibles en fonction de données locales portant sur les
habitudes de développement
o Problème : nécessite une estimation de la taille du projet en KLOC

o) Analyse en points de fonction

Plutôt que d’estimer le nombre de lignes de code, il peut être plus judicieux d’estimer des points de fonction.
Les éléments les plus courants à prendre en compte sont les :
 Interrogations : paires requête-réponse
 Entrées : les champs individuels ne sont généralement pas comptés séparément (nom, prénom...
comptent pour 1)
 Sorties (comme les entrées)
 Fichiers internes : fichiers tels que le client les comprend
 Interfaces externes : données partagées avec d’autres programmes

p) Comptage des points de fonction

 Des coefficients sont attribués aux éléments, selon leur complexité

 Les coefficients pondèrent une somme du nombre d’éléments récencés pour obtenir les points de
fonction du logiciel
o Manque de standard pour compter les PF
o Estimation des coefficients à faire en interne
o Relation entre points de fonction et coût a` estimer en interne

40
Ing. NTOH MOUALAM Annick
 III. Analyse et gestion des risques
1) Le risque
Définition
 Risque : probabilité qu’un évènement indésirable ait lieu. Le risque implique des idées de
o Incertitude : les événements ne se produiront pas de manière certaine
o Perte : plus l’évènement est indésirable, plus le risque est grand

 Une gestion proactive des risques peut aider à minimiser les effets négatifs d’événements
susceptibles de se produire

2) Types de risques :
o Les risques de projet concernent le déroulement du projet
o Les risques techniques portent sur la qualité du produit
o Les risques commerciaux peuvent affecter sa viabilité

a) Exemples de types de risques

b) Calcul des risques

 Utilisation de probabilités élémentaires
1. Estimer la probabilité du risque
2. Estimer l’impact, le coût des conséquences
3. Calculer le risque en multipliant ces deux valeurs

41
Ing. NTOH MOUALAM Annick
Exemple : jeu à deux dés à six faces
L’obtention d’un 7 fait perdre 60 euros, quel est le risque ?

 Utilisation de probabilités élémentaires

1. Estimer la probabilité du risque
2. Estimer l’impact, le coût des conséquences
3. Calculer le risque en multipliant ces deux valeurs

 Exemple : jeu à deux dés à six faces

1. L’obtention d’un 7 fait perdre 60 euros, quel est le risque ?
Il y a 6 façons d’obtenir un 7, soit une probabilité de
6/36 = 1/6
2. L’impact est de 60 euros
3. Le risque vaut donc 1/6 × 60 = 10 euros

3) Atténuation des risques

 Stratégie proactive pour tenter de diminuer

o L’impact d’un risque
o La probabilité´ d’un risque
 Pas de solution miracle !
o Identifier très tôt les risques les plus importants
o Utiliser un cycle de vie incrémental et fonde´ sur les risques
o Prototyper autant que possible
 Exemples de Stratégies d’atténuation des risques

42
Ing. NTOH MOUALAM Annick
 IV. Test logiciel
 Tester un logiciel : Exécuter le logiciel avec un ensemble de données réelles
« Un programme sans specifications est toujours correct »
 Il faut confronter résultats de l’exécution et résultats attendus
 Impossibilité de faire des tests exhaustifs
Ex : 2 entiers sur 32 bits en entrée : 264 possibilités. Si 1ms par test, plus de 108 années nécessaires pour
tout tester
 Choix des cas de tests :
Il faut couvrir au mieux l’espace d’entrées avec un nombre réduit d’exemples
Les zones sujettes à erreurs nécessitent une attention particulière

1) Tests fonctionnels
 Identification, à partir des specifications, des sous-domaines à tester
o Produire des cas de test pour chaque type de sortie du programme
o Produire des cas de test déclenchant les differents messages d’erreur
 Objectif : Disposer d’un ensemble de cas de tests pour tester le programme complètement lors de
son implémentation
 Test « boîte noire » parce qu’on ne préjuge pas de l’implémentation
o Identification possible des cas de test pertinents avant l’implémentation
o Utile pour guider l’implémentation

Exemple :
Problème : Créer un ensemble de cas de test pour un programme qui
1. Prend trois nombres a, b et c
2. Les interprète comme les longueurs des côtés d’un triangle
3. Retourne le type de triangle
Exemple :

43
Ing. NTOH MOUALAM Annick
 44
Ing. NTOH MOUALAM Annick
 45
Ing. NTOH MOUALAM Annick
 2) Matrices de test
Les matrices de test permettent de :
 Formaliser l’identification des sous-domaines a` partir des conditions des spécifications
 Indiquer systématiquement si les combinaisons de conditions sont vraies ou fausses
 Toutes les combinaisons possibles de V et de F seront examinées

46
Ing. NTOH MOUALAM Annick
Exemple :
A partir des specifications, on identifie des conditions d’exécution du programme qui permettront de
produire les sorties voulues :

NB : Il est impossible d’avoir (3) =V et (4) =F, ou encore (2)=V et (1)=F

3) Tests structurels
 Tests « boîte blanche » : détermination des cas de test en fonction du code
 Critère de couverture : Règle pour sélectionner les tests et déterminer quand les arrêter
o Au pire, on peut sélectionner des cas de test au hasard jusqu’à ce que le critère choisi soit
satisfait
 Oracle : Permet de déterminer la sortie attendue associée aux cas sélectionnés
o Difficile à mettre en place si on veut automatiser complètement le processus de test

a) Couverture de chaque instruction (C0)

Selon ce critère, chaque instruction doit être exécutée avec des données de test
Sélectionner des cas de test jusqu’à ce qu’un outil de couverture indique que toutes les instructions du code
ont été exécutées.
Exemple :

47
Ing. NTOH MOUALAM Annick
Après le quatrième test, toutes les instructions sont exécutées Il est rare que le jeu minimal soit bon d’un
point de vue fonctionnel.

b) Test de toutes le branches (C1)

Plus complet que C0
Selon ce critère, il faut emprunter les deux directions possibles au niveau de chaque décision
Nécessite la création d’un graphe de contrôle et de couvrir chaque arc du graphe
Exemple :

48
Ing. NTOH MOUALAM Annick
 c) Test de tous les chemins

 Encore plus complet

 Selon ce critère, il faut emprunter tous les chemins possibles dans le graphe
 Chemin : suite unique de nœuds du programme exécutés par un jeu spécifique de données de test
 Peu adapté au code contenant des boucles, le nombre de chemins possible étant souvent infini
Exemple :

d) Couverture des conditions multiples

 Un critère de test de conditions multiples impose que :
Chaque condition primitive doit être évaluée à la fois comme vraie et comme fausse
Toutes les combinaisons V/F entre primitives d’une condition multiple doivent être testées
 Très complet, ne pose pas de problème en cas d’itérations
Exemple :

49
Ing. NTOH MOUALAM Annick
 4) Test de flot de données
 Test structurel
 S’appuie sur la circulation des données à l’intérieur du programme
o Elles circulent depuis l’endroit où elles sont definies jusqu’à celui où elles sont utilisées
 def : definition d’une donnée, correspond à l’attribution d’une valeur à une variable
 c-use : utilisation pour calcul, la variable apparait à droite d’un opérateur
d’affectation
 p-use : utilisation comme prédicat dans une condition
o A noter :
 L’utilisation p-use est attribuée aux deux branches conditionnelles
 Un chemin sans definition, noteé def-free, va de la definition d’une variable à une
utilisation sans passer par d’autres definitions

e) Critères de tests de flots de données

 dcu : chaque definition doit être reliée a` un c-use en aval par un chemin sans definition
 dpu : chaque p-use doit être reliée à une definition en amont par un chemin sans definition
 du : combinaison des deux précédents
 all-du-paths : le plus exigeant, qui veut que tous les chemins possibles entre une definition et une
utilisation doivent être sans definition
Exemple :

 dcu : le seul c-use porte sur type et se trouve au nœud K

o Depuis ABC jusqu’à K : chemin ABCEGIK
o Depuis D jusqu’à K : chemin DEGIK
o Depuis F jusqu’à K : chemin FGIK
o Depuis H jusqu’à K : chemin HIK

50
Ing. NTOH MOUALAM Annick
 o Depuis J jusqu’à K : chemin JK

 dpu : les p-use portent sur les variables a,b et c qui ne sont définies que dans le nœud ABC
o Depuis ABC jusqu’a` l’arc ABC-D
o Depuis ABC jusqu’a` l’arc ABC-E
o Depuis ABC jusqu’a` l’arc E-F
o Depuis ABC jusqu’a` l’arc E-G
o Depuis ABC jusqu’a` l’arc G-H
o Depuis ABC jusqu’a` l’arc G-I
o Depuis ABC jusqu’a` l’arc I-J

 du : tous les tests de dcu et de dpu combinés

 all-du-paths : mêmes tests que pour du

5) Specificité des tests orientés objet

 Habituellement :
o Couverture des instructions
o Couverture des branches
o Couverture du flot de données
 Ces techniques s’appuient sur un diagramme de contrôle
 Ces diagrammes sont mal adaptés pour représenter la structure d’un logiciel objet
o Les complexités de ces logiciels objet résident plutôt dans les interactions entre les
méthodes
 Il faut couvrir les appels de méthodes

a) Couverture pour les tests objet

 Tests MM (méthode, message)
o Tester tous les appels de méthode
o Si une méthode en appelle une autre plusieurs fois, chaque appel est testé séparément
 Couverture des paires de fonctions
o Tester tous les enchaînements de deux méthodes possibles
o Utilisation d’expressions régulières pour identifier les paires à couvrir

51
Ing. NTOH MOUALAM Annick
 Chapitre 4. L’ergonomie du logiciel
Comment évaluer l’ergonomie d’un logiciel ou un progiciel préexistant ?
L’ergonomie peut être définie comme l’ensemble des connaissances scientifiques relatives à l’homme et
nécessaires pour concevoir des outils, des techniques et des dispositifs qui puissent être utilisés avec
le maximum de confort, de sécurité et d’efficacité.

Les principales caractéristiques de l’ergonomie sont :

• la nécessité de connaissances interdisciplinaires (physiologie, psychologie, sociologie, ingénierie,

médecine...);

• l’effort de prise en compte de la globalité d’une situation de travail (contenu des tâches,
environnement, organisation, formation...);

• l’analyse du travail réel effectué par les opérateurs.

Plus précisément, l’ergonomie du logiciel a pour objectif de permettre une meilleure adéquation des
applications informatiques aux besoins des utilisateurs.

Problématique de l’ergonomie :

1) Pourquoi aborder ce sujet maintenant ?

Après avoir appréhendé les aspects techniques d’un déploiement multicouches, nous allons voir quelle
forme et quelle organisation vous allez mettre en place. Après avoir appris comment aller chercher
l’information demandée, nous allons maintenant voir comment la mettre à disposition de l’utilisateur.

2) Pourquoi accorder de l’importance à l’ergonomie de son site et plus

généralement de ses applications ?
Quelque soit le domaine dans lequel vous intervenez, les vecteurs de communication que vous utiliserez
seront aussi importants, si ce n’est plus important que le fond même de votre intervention.

Petite notion de PNL (Programmation Neuro-Linguistique)

52
Ing. NTOH MOUALAM Annick
Fig. Illustration du principe d’une communication ergonomique

En regardant la figure ci-dessus, dans toute communication, ce qui importe, ce n’est pas l’étape 1 mais bien
finalement l’étape 5 ! Les outils que l’on vous a donné lors des précédentes interventions permettent de
passer de l’étape 2 à l’étape 3. Nous allons maintenant approfondir le passage de l’étape 3 à 4.

Dans certaines entreprises multinationales les taches sont séparées mais c’est loin d’être le cas de toutes les
structures.

Vous aurez donc à faire l’étape 2 et 3 en prenant en compte les étapes 4 et 5.

3) Présentation de l’intervention
L’objectif que nous nous sommes fixé ici, est de vous sensibiliser à l’importance de l’ergonomie et de
vous donner quelques points de repère vous permettant d’être rapidement opérationnel, lors de vos
prochaines expériences professionnelles.

Certaines personnes passent plus de 4 ans à étudier l’ergonomie, nous n’avons évidemment pas la
prétention d’être exhaustif, c’est la raison pour laquelle nous avons choisi de vous présenter des résultats
sous forme de « règles », que l’on pourrait classer sous la rubrique « trucs et astuces » dans un
magasine informatique, mais qui résulte d’études sérieuses.

Pour vous permettre d’appréhender cela, nous allons d’abord nous intéresser à l’Ergonomie en rentrant un
peu dans les « détails conceptuels ». Nous établirons ensuite une grille de critères à observer et nous
terminerons par l’étude de site Internet pour voir concrètement la mise en application de ces principes.

La place des technologies cognitives dans l’ergonomie

Dans notre schéma, il s’agit du passage de l’étape 4 à l’étape 5, à savoir : comment se passe la
conceptualisation du message reçu.

1) Comment définir les sciences cognitives ?

Les sciences cognitives sont un ensemble de disciplines qui étudient les activités liées aux fonctions
cognitives, c'est-à-dire la perception, les représentations, la mémoire, le langage, le raisonnement, la
motricité ou l'apprentissage.

53
Ing. NTOH MOUALAM Annick
Cette étude se fait autant sous l'aspect humain de ces fonctions que sous ceux de la modélisation et de la
simulation artificielle, en tenant compte de la validité biologique de tels modèles. Classiquement,
les champs disciplinaires intéressés par les sciences cognitives sont :

- les Sciences Humaines : Psychologie cognitive & Linguistique pour l'étude de l'humain et du langage ;

- les Neurosciences : la Neurobiologie (de la Neuroanatomie à la Neurochimie) pour l'étude des

composantes biologiques ;

- les Sciences de l'Artificiel : mathématiques, intelligence artificielle (apprentissage, connexionnisme, etc.)

pour la modélisation.

- D'autres sciences peuvent encore s'ajouter à cette liste, telles la philosophie, l'épistémologie ou

l'anthropologie (parmi les sciences humaines), ainsi que la physique (pour son apport aux Sciences
de l'artificiel).

La création des champs d'étude comme la psycholinguistique (psychologie et linguistique), la

neuropsychologie (neurologie, psychologie et neurosciences) ou l'intelligence artificielle (informatique,
logique et linguistique) marquait déjà cette nécessité bienheureuse d'une vision plus globale en
franchissant les frontières classiques entres les disciplines.

Les sciences cognitives forment ainsi un domaine de recherche qui se nourrit de la confrontation des points
de vue des divers secteurs liés à l'étude de la cognition, pariant sur les possibilités d'interfécondation
des visions et sur le développement des études transcendant les diverses disciplines

2) Quelles inter-connexions avec l’ergonomie ?

Les sciences cognitives sont un préalable à la pratique d’une ergonomie efficace. Comment imaginer
pouvoir travailler sur l’étape 3 si l’on ne maîtrise pas l’étape 4 et 5 ?

Il est intéressant de constater que les formations d’ergonome (que ce soit en Europe ou aux Etats-Unis), ne
sont que des spécialisations auxquelles on ne peut postuler qu’après plusieurs années d’étude (en général
4).

Gardez donc en mémoire les préalables à l’ergonomie et n’oubliez pas que la question de fond
reste « comment l’utilisateur va-t-il appréhender/comprendre l’outil ? » et non comment faire quelque chose
de beau !

3) Les différents domaines d’application de l’ergonomie

Ils sont tout ce qu’il y a de plus divers et varié. On peut dire que les premiers ergonomes étaient Ford et
Taylor. Ce sont les premiers à avoir complètement redéfini les conditions de travail pour améliorer la
productivité. En décomposant le processus de production ils ont rendu la fabrication des voitures accessible
à tout le monde. Comme le dis le conseil de la SELF, l'ergonomie peut être comprise comme " l'adaptation
du travail à l'homme ".

54
Ing. NTOH MOUALAM Annick
Par la suite, on retrouve les ergonomes dans les domaines où il a fallu optimiser les conditions de travail.
C’est à dire dans tous les milieux soumis à de forte contrainte de vitesse, de précision, de stress… On peut
citer les aéroports, les hôpitaux, les centre de service d’urgence, l’informatique (hardware et software),
l’automobile et parfois –mais plus rarement– dans le domaine du mobilier.

Pour approfondir la question, vous pourrez consulter plus tard les sites d’ergonomes que nous avons mis sur
le réseau.

La prise en compte de l’ergonomie dans le développement d’IHM et plus

spécifiquement dans le développement d’applications Web
1) L’« ergonomie de fond », un préalable à la mise à disposition de l’information
a) Importance et réalisation de l’organisation générale de l’application

Le challenge d’une application Web est de rendre accessible via un petit écran de 800 x 600 pixel, des
informations ou des produits qui étaient parfois disposés dans des entrepôts de plusieurs centaines de mètres
carrés. Il faut donc pouvoir retranscrire l’appréhension visuelle qu’avait l’utilisateur en arrivant dans son
entrepôt ou sa pièce. Pour cela, il est important de rendre lisible la structure de votre site. Comment:

- avec un plan du site si la structure n’est pas suffisamment lisible, ou si le site est trop grand pour que
l’utilisateur ne puisse sans effort avoir une vue d’ensemble,

- avec une signalétique cohérente tout au long de l’application

Remarques :

- Notez que la structure « visuelle » que vous donnez à votre utilisateur n’est pas forcément calquée
sur l’architecture technique que vous avez déterminée au préalable.

- Dans le cas d’un site commercial ou vous cherchez à vendre quelque chose, des études ont montré que

vous avez le droit à 3 cliques et moins d’une minute pour « ferrer » le client !

b) Les spécificités du Web

Mode de fonctionnement des moteurs de recherche, importance du titre des pages et des mots clefs,
présentation du « profiling ».

- Se faire référencer :

Sans rentrer dans les détails, il est important de savoir comment rendre accessible son site sur le Web.

Il existe des moteurs de recherche (type « google » ou « alta vista ») et des annuaires (type « Yahoo »). Dans
le premier cas, il n’y a aucune démarche à faire pour se faire référencer, ce sont des petits « moteurs » qui

55
Ing. NTOH MOUALAM Annick
parcourent le Web et référence les sites en fonction des mots clefs indiqués dans au début du code HTML
et des mots figurants dans le site.

Dans le deuxième cas, il faut inscrire le site sur une liste, et son site est ensuite visité manuellement ou
toujours à l’aide de « robot » pour vérifier certains critères.

Quand on veut rendre un site accessible sur le Web, il est bien sur capital d’être bien référencé si on veut
être visité.

Les termes que l’on choisit dans la définition de ses mots clefs sont déterminant.

2) L’ergonomie des applications Web

a) La densité de l’affichage
 Pour chaque application, il faut trouver un compromis entre la densité d’informations affichées
dans chaque fenêtre et le nombre de fenêtres :

- une forte densité d’affichage entraîne davantage d’erreurs de la part de l’utilisateur et augmente le temps

nécessaire pour repérer une information ;

- une trop grande dilution de l’information dans un trop grand nombre de fenêtres gêne l’utilisateur dans sa
perception globale de l’application.

56
Ing. NTOH MOUALAM Annick
 b) La disposition des éléments dans les fenêtres
 Pour regrouper les données (regroupement au sein de rubriques) et définir leur enchaînement
(chronologie de présentation des données affichées ou à saisir), tenir compte des habitudes de travail
de l’utilisateur :

- fréquence d’utilisation,

- séquence d’utilisation dans la tâche en cours,

- importance dans le contexte (saisies obligatoires, optionnelles).

Présenter les groupes de données les plus importants selon le critère privilégié (par exemple, fréquence
d’utilisation) vers le haut de la fenêtre.

Remarque : si le travail de l’utilisateur s’appuie sur un formulaire papier, et si ce formulaire est bien
construit, faire en sorte que la disposition des champs dans la fenêtre soit proche de la structure du
formulaire.

 Aligner verticalement les champs de saisie et/ou d’affichage avec leurs libellés ; la justification peut
se faire de trois manières :

- 1 : si les « libellés » sont de dimension sensiblement identique, justifier les champs et les libellés à gauche
;

- 2 : si les libellés sont de dimensions très variables, justifier ces libellés à droite et les champs à gauche ;

- 3 : il est également possible de disposer les libellés au-dessus des « champs de saisie » ; il faut alors les
justifier à gauche.

57
Ing. NTOH MOUALAM Annick
  Attribuer un libellé à chaque donnée et à chaque groupe de données.
 Séparer les différentes catégories d’informations par des espaces et éventuellement par des boîtes
de groupe (= encadrements).

c) Les éléments textuels

 Utiliser le vocabulaire appartenant au domaine d’activité des utilisateurs.
 Utiliser des termes explicites et non ambigus. Faire des phrases (ou expressions) simples, c’est-
à-dire facilement compréhensibles par l’opérateur ; préférer les formes affirmatives.
 Indiquer les unités de mesure utilisées (en abrégé si elles sont connues de l’utilisateur).
 Eviter d’utiliser des abréviations, sinon, fournir chaque fois que c’est possible des abréviations bien
choisies :

- utiliser uniquement celles qui sont le plus largement adoptées par les utilisateurs car ces derniers pourront
avoir rencontré certaines abréviations qui signifient autre chose ;

- préférer la contraction (omission des lettres internes) pour les mots courts ;

- préférer la troncature pour les mots longs (omission des lettres finales).

- Par souci d’homogénéité, ne pas utiliser de synonymes : désigner toujours un même objet ou une même
action par le même libellé.

58
Ing. NTOH MOUALAM Annick
  Lors de la création de listes d’éléments, on peut être confronté à des éléments de texte trop longs
pour contenir dans l’espace d’une ligne de la liste. Dans ce cas, supprimer des parties de texte dans
le milieu du libellé et y insérer des points de suspension, conservant ainsi le début et la fin du libellé
de l’élément. Attention toutefois :

dans certains cas, il sera plus judicieux de conserver le début du libellé et de faire suivre ce dernier par des
points de suspension.

 Repérer chaque champ, liste, tableau, colonne ou groupe de données par un libellé. On distingue
trois grands types de libellés :

- le libellé de champ, à utiliser pour identifier une donnée affichée ou à saisir ;

- l’en-tête de colonne, à utiliser pour identifier la colonne d’un tableau ou d’une liste ;

- l’en-tête de groupe, à utiliser pour identifier un ensemble de données rassemblées sous la forme
d’un groupe.

d) La typographie
 Concernant la taille des caractères :

taille minimum : 8 points ; des caractères de plus petite taille sont quasiment illisibles ;

taille maximum : 16 points ; l’utilisation de caractères de plus grande taille gêne la lisibilité.

 Choisir la police de caractères en fonction de critères de lisibilité (éviter l’italique).

 Eviter d’utiliser plus de trois polices de caractères différentes dans une même fenêtre ou sur
plusieurs fenêtres affichées simultanément.
 De manière générale, utiliser une seule police de caractères dans un champ. Toutefois, il est possible
d’utiliser des codages particuliers (police différente, couleur, italique, gras, souligné...) pour
différencier certains textes tels que des mots clés, des liens, des libellés de champs de saisie
obligatoire, etc.
 Pour tous les libellés (champs de saisie et champs d’affichage, option de menu, boutons d’option,
titre, etc.) utiliser une majuscule à l’initiale. Ne mettre donc en majuscule que la première lettre du
premier mot du libellé et aucun autre mot de ce libellé.

e) La couleur
La couleur peut être employée pour coder visuellement l’information : différenciation et identification des
informations affichées.

 La couleur ne doit pas être le seul moyen utilisé pour communiquer de l’information et ne devrait
pas être le seul élément qui distingue deux objets ; il doit y avoir d’autres indicateurs (libellés,
forme, disposition) ;appliquez ce principe surtout pour tenir compte des utilisateurs daltoniens ou
achromates mais aussi pour les écrans monochromes (même si ces derniers sont « rares » !)

59
Ing. NTOH MOUALAM Annick
  Choisir les couleurs en gardant à l’esprit que l’objectif est de faciliter la lisibilité des informations
affichées. C’est pourquoi certaines associations de couleurs doivent être évitées. Ainsi, essayer de
ne jamais utiliser ensemble :

- le rouge avec le bleu,

- le jaune avec le violet,

- le jaune avec le vert.

Pour le fond des fenêtres, éviter les teintes de rouge, de jaune et de ses dérivés (vert, orange, …). Privilégier
plutôt le gris pâle, sinon du bleu foncé.

Pour de l’information que l’utilisateur doit lire, éviter le bleu pâle (et les couleurs pâles en général).

 Homogénéité : au sein d’une même application et entre différentes applications destinées à un même
groupe d’utilisateurs, toujours choisir les mêmes “ codages couleur ”.
 Respecter les règles d’association conventionnelles entre la couleur et sa signification :

- vert : signifie que tout se passe correctement,

- jaune ou orange : attention, vigilance,

- rouge : alerte, danger, interruption.

 Eviter d’utiliser plus de 5 ou 6 couleurs différentes dans une même fenêtre (mais également
au sein d’une même application). Au-delà de 5 ou 6, cela entraîne une surcharge visuelle
et l’utilisateur éprouve des difficultés à saisir le rôle joué par la couleur au sein de l’application.
 Concernant les états sur les imprimantes noir et blanc : s’assurer que chaque couleur reste
visible sur les impressions (il doit y avoir correspondance entre les couleurs qui apparaissent à
l’écran et les niveaux de gris des sorties papier ; si le nombre de niveaux de gris disponible est
insuffisant, prévoir des hachures).

Comme nous avons pu le constater ensemble, la bonne ergonomie de ses applications Web ne tient pas à
grand-chose, il suffit de faire attention à un certain nombre de critères.

Notez tout de même que, la prise en compte de ces recommandations ne se substitue pas à la
connaissance des utilisateurs ni à la connaissance de leur travail ; elle ne remplace pas une analyse
du travail, elle est simplement complémentaire à un travail d’analyse de la cible. Ces recommandations
sont particulièrement applicables pour les sites Internet qui ne ciblent pas de public particulier.

Quand on élabore un Intranet ou une application spécifique, l’analyse du fonctionnement et du

comportement des utilisateurs peut amener à ne pas prendre en compte certaine recommandation, voir à
faire le contraire !

60
Ing. NTOH MOUALAM Annick
 Chapitre 5. Production du code source
L'objectif de ce chapitre est de présenter les enjeux et les solutions liés à la production du code source d'un
logiciel.

Introduction
Le code source est le cœur d'un projet logiciel. Il est essentiel que tous les membres de l'équipe de
développement se coordonnent pour adopter des règles communes dans la production de ce code.
L'objectif de ces règles est l'uniformisation de la base de code source du projet. Les avantages liés sont
les suivants :
 La consultation du code est facilitée.
 Les risques de duplication ou d'erreurs liées à des pratiques disparates sont éliminés.
 Chaque membre de l'équipe peut comprendre et intervenir sur d'autres parties que celles qu'il a
lui-même réalisées.
 Les nouveaux venus sur le projet mettront moins longtemps à être opérationnels.
Il est important de garder à l'esprit qu'un développeur passe en moyenne beaucoup plus de temps à lire
qu'à écrire du code.

Convention de nommage
Une première série de règle concerne le nommage des différents éléments qui composent le code.
Il n'existe pas de standard universel à ce sujet.
La convention la plus fréquemment adoptée se nomme camelCase (ou parfois lowerCamelCase).
Elle repose sur deux grands principes :
 Les noms des classes (et des méthodes en C#, pour être en harmonie avec le framework .NET)
commencent par une lettre majuscule.
 Les noms de tous les autres éléments (variables, attributs,
paramètres, etc) commencent par une lettre minuscule.
 Si le nom d'un élément se compose de plusieurs mots, la première lettre de chaque mot suivant le
premier s'écrit en majuscule.
Voici un exemple de classe conforme à cette convention.

61
Ing. NTOH MOUALAM Annick
On peut ajouter à cette convention une règle qui impose d'utiliser le pluriel pour nommer les éléments
contenant plusieurs valeurs, comme les tableaux et les listes. Cela rend le parcours de ces éléments
plus lisible.

Langue utilisée

La langue utilisée dans la production du code doit bien entendu être unique sur tout le projet.
Le français ( idClientSuivant) et l'anglais ( nextClientId ) ont chacun leurs avantages et leurs
inconvénients. On choisira de préférence l'anglais pour les projets de taille importante ou destinés
à être publiés en ligne.

Formatage du code
La grande majorité des IDE et des éditeurs de code offrent des fonctionnalités de formatage
automatique du code. A condition d'utiliser un paramétrage commun, cela permet à chaque
membre de l'équipe de formater rapidement et uniformément le code sur lequel il travaille.
Les paramètres de formatage les plus courants sont :
 Taille des tabulations (2 ou 4 espaces).
 Remplacement automatique destabulations par des espaces.
 Passage ou non à la ligne après chaque accolade ouvrante ou fermante.
 Ajout ou non d'un espace avant une liste de paramètres.
 ...
Sous Visual Studio, la commande de formatage automatique du code est Edition->Avancé-
>Mettre le document en forme.

62
Ing. NTOH MOUALAM Annick
Voici quelques exemples de paramétrages possibles du formatage (menu Outils->Options).

Commentaires

L'ajout de commentaires permet de faciliter la lecture et la compréhension d'une portion de code source.
L'ensemble des commentaires constitue une forme efficace de documentation d'un projet logiciel.
Il n'y a pas de règle absolue, ni de consensus, en matière de taux de commentaires dans le code source.
Certaines méthodologies de développement agile (eXtreme Programming) vont jusqu'à affirmer qu'un
code bien écrit se suffit à lui-même et ne nécessite aucun ajout de commentaires.
Dans un premier temps, il vaut mieux se montrer raisonnable et commenter les portions de code
complexes ou essentielles : en-têtes de classes, algorithmes importants, portions atypiques,etc. Il faut
éviter de paraphraser le code source en le commentant, ce qui alourdit sa lecture et n'est d'aucun intérêt.

63
Ing. NTOH MOUALAM Annick
Voici quelques exemples de commentaires inutiles : autant lire directement les instructions décrites.

Voici comment le code précédent pourrait être mieux commenté.

64
Ing. NTOH MOUALAM Annick
 Chapitre 6. Systèmes de gestion de versions
Notion de gestion de versions
Pour éviter de se tromper sur le bon fichier ou d’écraser un fichier plus récent, et bien d’autres situations,
on peut faire appel au système de gestion de versions ; qui facilitera la gestion de plusieurs versions d’un
même fichier. Ainsi de façon globale, chaque membre de l'équipe pourra récupérer la dernière version des
fichiers du projet, modifier le fichier de son choix et le livrer une fois le travail terminé.

Cette technique émane des systèmes UNIX et de CVS.

Pour obtenir des résultats de qualité et une meilleure organisation de votre projet, il est donc recommandé
d’utiliser un outil logiciel de gestion de versions. Ils aident en plus à simplifier et mieux organiser
l’arborescence du projet. Il ne nous encombre pas avec des versions physiques nombreuses du même fichier.
Bien sûr, même si on dispose d'un unique fichier, on peut à tout moment récupérer l'historique des
modifications effectuées ainsi que n'importe quelle version antérieure. On pourra même parfois effectuer
la fusion de modifications entre plusieurs version d'un même fichier.

Un exemple d’outil de gestion de version est « SVN » (gratuit, successeur de CVS), très performant, et
compatible avec n'importe quel type de fichier.

Par ailleurs, on peut bloquer les modifications sur un fichier pendant que l'on travaille dessus. De cette
manière, vous pouvez empêcher un autre membre de l'équipe d'y accéder et de créer une version concurrente
à la vôtre.

Il faut signaler ici que s’il arrive que si deux membres de l'équipe travaillent sur le même fichier, le chef de
projet n'a pas fait correctement son travail d'affectation des tâches.

Le système SVN peut fonctionner à distance. Les données de l'équipe qui sont centralisées sur le
serveur distant peuvent être récupérées via le net suivant différents protocoles, dont plusieurs sécurisés.

Application concrète : une infrastructure

Voici un exemple d’infrastructure technique à mettre en place pour votre projet :

- Un serveur distant pour :

o Stocker votre projet sous la forme d'un répertoire géré par SVN
o Effectuer les sauvegardes quotidiennes du projet vers une autre destination (CobianBackup)
- Des postes de travail clients équipés :
o d'un répertoire local de travail où sera placé la dernière version du projet par SVN
o des logiciels de travail : 3dsMAx, Virtools, photoshop....

N’oubliez pas que lorsque l'équipe devient importante (>3), une petite amélioration peut consister à héberger
sur votre serveur le site internet de l'équipe. Réalisé sous la forme d'un site de news, il vous permettra
d'assurer la communication du projet, en interne et en externe.

65
Ing. NTOH MOUALAM Annick
 La gestion des versions d'un logiciel, en utilisant comme exemple l'outil Git.

Nous avons déjà mentionné qu'un projet logiciel d'entreprise a une durée de vie de plusieurs années et subit
de nombreuses évolutions au cours de cette période. On rencontre souvent le besoin de livrer de
nouvelles versions qui corrigent des bogues ou apportent de nouvelles fonctionnalités. Le code source
du logiciel "vit" donc plusieurs années. Afin de pouvoir corriger des problèmes signalés par un
utilisateur du logiciel, on doit savoir précisément quels fichier source font partie de quelle(s) version(s).
En entreprise, seuls une petite minorité de logiciels sont conçus par un seul développeur. La
grande majorité des projets sont réalisés et/ou maintenus par une équipe de
plusieurs personnes travaillant sur la même base de code source. Ce
travail en parallèle est source de complexité :
 Comment récupérer le travail d'un autre membre de l'équipe ?
 Comment publier ses propres modifications ?
 Comment faire en cas de modifications conflictuelles (travail sur le même fichier source qu'un
ou plusieurs collègues) ?
 Comment accéder à une version précédente d'un fichier ou du logiciel entier ?

Pour les raisons précédentes, tout projet logiciel d'entreprise (même mono-développeur) doit faire l'objet
d'une gestion des versions (Revision Control System ou versioning). La gestion des versions vise les
objectifs suivants :
 Assurer la pérennité du code source d'un logiciel.
 Permettre le travail collaboratif.
 Fournir une gestion de l'historique du logiciel.

La gestion des versions la plus basique consiste à déposer le code source sur un répertoire partagé
par l'équipe de développement. Si elle permet à tous de récupérer le code, elle n'offre aucune solution aux
autres complexités du développement en équipe et n'autorise pas la gestion des versions.

66
Ing. NTOH MOUALAM Annick
Afin de libérer l'équipe de développement des complexités du travail collaboratif, il existe une
catégorie de logiciels spécialisés dans la gestion des versions.

Les logiciels de gestion des versions

1) Principales fonctionnalités

Un logiciel de gestion des versions est avant tout un dépôt de code qui héberge le code source du projet.
Chaque développeur peut accéder au dépôt afin de récupérer le code source, puis de publier ses
modifications. Les autres développeurs peuvent alors récupérer le travail publié.
Le logiciel garde la trace des modifications successives d'un fichier. Il permet d'en visualiser l'historique
et de revenir à une version antérieure.
Un logiciel de gestion des versions permet de travailler en parallèle sur plusieurs problématiques (par
exemple, la correction des bogues de la version publiée et l'avancement sur la future version) en créant des
branches. Les modifications réalisées sur une branche peuvent ensuite être intégrées (merging) à une autre.
En cas d'apparition d'un conflit (modifications simultanées du même fichier par plusieurs développeurs),
le logiciel de gestion des versions permet de comparer les versions du fichier et de choisir les
modifications à conserver ou à rejeter pour créer le fichier fusionné final.
Le logiciel de gestion des versions permet de regrouper logiquement des fichiers par le biais du
tagging : il ajoute aux fichiers source des tags correspondant aux différentes versions du logiciel.

2) Gestion centralisée Vs gestion décentralisée

On peut classer les logiciels de gestion des versions en deux catégories.
La première catégorie offre une gestion centralisée du code source. Dans ce cas de figure, il n'existe qu'un
seul dépôt qui fait référence. Les développeurs se connectent au logiciel de gestion des versions suivant
le principe du client/serveur. Cette solution offre les avantages de la centralisation (administration facilitée)

67
Ing. NTOH MOUALAM Annick
mais handicape le travail en mode déconnecté : une connexion au logiciel de SCM est indispensable.

Une seconde catégorie est apparue il y a peu. Elle consiste à voir le logiciel de gestion des versions
comme un outil individuel permettant de travailler de manière décentralisé (hors ligne). Dans ce cas de
figure, il existe autant de dépôts de code que de développeurs sur le projet. Le logiciel de gestion des
versions fournit heureusement un service de synchronisation entre toutes ces bases de code. Cette solution
fonctionne suivant le principe du pair-à-pair. Cependant, il peut exister un dépôt de référence

68
Ing. NTOH MOUALAM Annick
contenant les versions livrées.

3) Principaux logiciels de gestion des versions

Il existe de très nombreux logiciels de gestion des versions. Nous n'allons citer que les principaux.
Assez ancien mais toujours utilisé, CVS (Concurrent Versioning System) fonctionne sur un principe
centralisé, de même que son successeur SVN (Subversion). Tous deux sont souvent employés dans le
monde du logiciel libre (ce sont eux-mêmes des logiciels libres).

Les logiciels de SCM décentralisés sont apparus plus récemment. On peut citer Mercurial et surtout
Git, que nous utiliserons dans la suite de ce chapitre. Ce sont également des logiciels libres. Microsoft
fournit un logiciel de SCM développé sur mesure pour son environnement. Il se nomme TFS (Team
Foundation Server) et fonctionne de manière centralisée. TFS est une solution payante. Il est
tout à fait possible de gérer le code source d'un projet .NET avec un autre outil de gestion des versions que
TFS.

a) Présentation de Git
Git est un logiciel libre de gestion des versions. C'est un outil qui permet d'archiver et de maintenir les
différentes versions d'un ensemble de fichiers textuels constituant souvent le code source d'un projet
logiciel. Créé à l'origine pour gérer le code du noyau Linux, il est multi-langages et multi-plateformes Git
est devenu à l'heure actuelle un quasi-standard.

69
Ing. NTOH MOUALAM Annick
  Fonctionnement
Git rassemble dans un dépôt (repository ou repo) l'ensemble des données associées au projet.
Il fonctionne de manière décentralisée : tout dépôt Git contient l’intégralité des données (code source,
historique, versions, etc). Chaque participant au projet travaille à son rythme sur son dépôt
local. Il existe donc autant de dépôts que de participants. Git offre des
mécanismes permettant de synchroniser les modifications entre tous les dépôts.

Un dépôt Git correspond physiquement à un ensemble de fichiers rassemblés dans un répertoire .git.
Sauf cas particulier, il n'est pas nécessaire d'intervenir manuellement dans ce répertoire.
Lorsqu'on travaille avec Git, il est essentiel de faire la distinction entre trois zones :
 Le répertoire de travail (working directory) correspond aux fichiers actuellement sauvegardés
localement.
 L'index ou staging area est un espace de transit.
 HEAD correspond aux derniers fichiers ajoutés au dépôt.

70
Ing. NTOH MOUALAM Annick
 Chapitre 7. Travail collaboratif
L'objectif de ce chapitre est de présenter les enjeux du travail collaboratif dans le cadre de la réalisation d'un
logiciel.

Les enjeux du travail collaboratif

La très grande majorité des projets logiciels sont menés par des équipes de plusieurs développeurs. Il est de
plus en plus fréquent que ces développeurs travaillent à distance ou en mobilité.

Le travail en équipe sur un projet logiciel nécessite de pouvoir :

• partager le code source entre membres de l'équipe ;

• gérer les droits d'accès au code ;

• intégrer les modifications réalisées par chaque développeur ;

• signaler des problèmes ou proposer des améliorations qui peuvent ensuite être discutés collectivement ;

Pour répondre à ces besoins, des plates-formes de publication et de partage de code en ligne sont apparues.
On les appelle parfois des forges logicielles. La plus importante à l'heure actuelle est la plate-forme GitHub.

Présentation de GitHub
GitHub est une plate-forme web d'hébergement et de partage de code. Comme son nom l'indique, elle se
base sur le logiciel Git.

Le principal service proposé par GitHub est la fourniture de dépôts Git accessibles en ligne. Elle offre aussi
une gestion des équipes de travail (organizations et teams), des espaces d'échange autour du code (issues et
pull requests), des statistiques, etc.
GitHub est utilisée par pratiquement toutes les grandes sociétés du monde du logiciel, y compris
Microsoft, Facebook et Apple. Pour un développeur, GitHub peut constituer une vitrine en ligne de son
travail et un atout efficace pour son employabilité.

1) Modèle économique
Le business model de GitHub est le suivant :

71
Ing. NTOH MOUALAM Annick
• la création d'un compte et de dépôts publics est gratuite ;

• la création de dépôts privés est payante.

Ce modèle économique est à l'origine de l'énorme popularité de GitHub pour la publication de projets open
source.

GitHub peut offrir des dépôts privés gratuits aux étudiants et aux établissements scolaires.

D'autres plates-formes alternatives se basent sur un modèle différent :

• BitBucket autorise les dépôts privés gratuits, mais limite la taille de l'équipe à cinq personnes ;

• GitLab est une solution open core pour installer sur ses propres serveurs une plate-forme similaire à
GitHub.

2) Fonctionnement
Sur GitHub, un dépôt est associé à un utilisateur individuel ou à une organisation. Il est ensuite accessible
via une URL de la forme https://github.com/.../nomDuDepot.git.

L'organisation du travail en équipe autour de GitHub peut se faire suivant deux modèles distincts.

a) Modèle « dépôt partagé »

Ce modèle de travail est bien adapté aux petites équipes et aux projets peu complexes.

Un dépôt GitHub fait office de dépôt central pour l'équipe. Après avoir obtenu les droits nécessaires,
chaque développeur clone ce dépôt (git clone) sur sa machine de travail. Ensuite, chacun peut envoyer ses
modifications locales vers le dépôt commun (git push) et récupérer celles des autres membres de l'équipe

72
Ing. NTOH MOUALAM Annick
(git pull).

b) Modèle « fork and pull »

Ce modèle plus complexe est utilisé sur des projets de taille importante.

Un dépôt GitHub principal est forké (dévié, détourné ?) par chaque développeur pour en obtenir une copie
exacte sur son compte GitHub, puis cloné sur sa machine locale. Les modifications sont pushées (envoyées
?) sur GitHub, puis le développeur émet une demande d'intégration (pull request) pour signaler au
responsable du dépôt commun qu'il a effectué des améliorations de son côté. Ce responsable étudie le code
ajouté et décide de l'intégrer ou non dans le dépôt principal.

3) Issues
Parmi les autres services proposés par GitHub, les issues (« sujets de discussion ») permettent de
communiquer autour du projet. Elles sont souvent utilisées pour signaler des problèmes ou proposer des
idées.

73
Ing. NTOH MOUALAM Annick
 74
Ing. NTOH MOUALAM Annick
 Chapitre 8. Documentation
L'objectif de ce chapitre est de découvrir les différents aspects associés à la documentation d'un logiciel.

Introduction
Nous avons déjà mentionné à plusieurs reprises qu'un logiciel a une durée de vie de plusieurs années et subit

de nombreuses évolutions au cours de cette période. En entreprise, seule une petite minorité de
logiciels sont conçus par un seul développeur. La grande majorité des projets sont réalisés et/ou maintenus
par une équipe de plusieurs personnes travaillant sur la même base de code source. Il est fréquent que les
effectifs changent et que des développeurs soient amenés à travailler sur un logiciel sans avoir participé à
sa création. L'intégration de ces nouveaux développeurs doit être aussi rapide et efficace que possible.

Cependant, il est malaisé, voire parfois très difficile, de se familiariser avec un logiciel par la seule lecture
de son code source. En complément, un ou plusieurs documents doivent accompagner le logiciel. On peut
classer cette documentation en deux catégories :

• la documentation technique ;

• la documentation utilisateur.

Documentation technique
1) Rôle
Le mot-clé de la documentation technique est « comment ». Il ne s'agit pas ici de dire pourquoi le logiciel
existe ni de décrire ses fonctionnalités attendues. Ces informations figurent dans d'autres documents comme
le cahier des charges. Il ne s'agit pas non plus d'expliquer à un utilisateur du logiciel ce qu'il doit faire pour
effectuer telle ou telle tâche : c'est le rôle de la documentation utilisateur.

La documentation technique doit expliquer comment fonctionne le logiciel.

2) Public visé
La documentation technique est écrite par des informaticiens, pour des informaticiens. Elle nécessite
des compétences techniques pour être comprise. Le public visé est celui des personnes qui interviennent sur
le logiciel du point de vue technique : développeurs, intégrateurs, responsables techniques, éventuellement
chefs de projet.

Dans le cadre d'une relation maîtrise d'ouvrage / maîtrise d'œuvre pour réaliser un logiciel, la responsabilité
de la documentation technique est à la charge de la maîtrise d'œuvre. Bien sûr, le ou les document(s)
associé(s) sont fournis à la MOA en fin de projet.

3) Contenu
Le contenu de la documentation technique varie fortement en fonction de la structure et de la complexité du
logiciel associé. Néanmoins, nous allons décrire les aspects que l'on y retrouve le plus souvent.

Les paragraphes ci-dessous ne constituent pas un plan-type de documentation technique.

75
Ing. NTOH MOUALAM Annick
 a) Modélisation
La documentation technique inclut les informations liées au domaine du logiciel. Elle précise comment les
éléments métier ont été modélisés informatiquement au sein du logiciel.

Si le logiciel a fait l'objet d'une modélisation de type entité-association, la documentation technique présente
le modèle conceptuel résultat.

Si le logiciel a fait l'objet d'une modélisation orientée objet, la documentation technique inclut une
représentation des principales classes (souvent les classes métier) sous la forme d'un diagramme de classes
respectant la norme UML.

76
Ing. NTOH MOUALAM Annick
Si le logiciel utilise une base de données, la documentation technique doit présenter le modèle d'organisation
des données retenu, le plus souvent sous la forme d'un modèle logique sous forme graphique.

b) Architecture
La phase d'architecture d'un logiciel permet, en partant des besoins exprimés dans le cahier des charges, de
réaliser les grands choix qui structureront le développement : technologies, langages, patrons utilisés,
découpage en sous-parties, outils, etc.

La documentation technique doit décrire tous ces choix de conception. L'ajout de schémas est conseillé, par
exemple pour illustrer une organisation logique multicouche.

77
Ing. NTOH MOUALAM Annick
L’implantation physique des différents composants (appelés parfois tiers) sur une ou plusieurs machines
doit également être documentée.

c) Production du code source

Afin d'augmenter la qualité du code source produit, de nombreux logiciels adoptent des normes ou des
standards de production du code source : conventions de nommage, formatage du code, etc. Certains peuvent
être internes et spécifiques au logiciel, d'autres sont des reprises de normes existantes (exemples : normes
PSR-x pour PHP).

Afin que les nouveaux développeurs les connaissent et les respectent, ces normes et standards doivent
être présentés dans la documentation technique.

d) Génération
Le processus de génération (« build ») permet de passer des fichiers sources du logiciel aux éléments
exécutables.

Il inclut souvent une phase de compilation du code source.

Sa complexité est liée à celle du logiciel. Dans les cas simples, toute la génération est effectuée
de manière transparente par l'IDE utilisé. Dans d'autres, elle se fait en plusieurs étapes et doit donc être
documentée.

e) Déploiement
La documentation technique doit indiquer comment s'effectue le déploiement du logiciel, c'est-à-dire
l'installation de ses différents composants sur la ou les machines nécessaire(s). Là encore, cette étape peut
être plus ou moins complexe et nécessiter plus ou moins de documentation.

78
Ing. NTOH MOUALAM Annick
 f) Documentation du code source
Il est également possible de documenter un logiciel directement depuis son code source en y
ajoutant des commentaires (voir plus haut). Certains langages disposent d'un format spécial de commentaire
permettant de créer une documentation autogénérée

Le langage Java a le premier introduit une technique de documentation du code source basée sur
l'ajout de commentaires utilisant un format spécial. En exécutant un outil du JDK appelé javadoc, on obtient
une documentation du code source au format HTML.

Voici un exemple de méthode Java documentée au format javadoc.

L'avantage de cette approche est qu'elle facilite la documentation du code par les développeurs, au fur et à
mesure de son écriture. Depuis, de nombreux langages ont repris l'idée.

Voici un exemple de documentation d'une classe C#, qui utilise une syntaxe légèrement différente.

79
Ing. NTOH MOUALAM Annick
 La documentation utilisateur
1) Rôle
Contrairement à la documentation technique, la documentation d'utilisation ne vise pas à faire comprendre
comment le logiciel est conçu. Son objectif est d'apprendre à l'utilisateur à se servir du logiciel.

La documentation d'utilisation doit être :

• utile : une information exacte, mais inutile, ne fait que renforcer le sentiment d'inutilité et gêne la recherche
de l'information pertinente ;

• agréable : sa forme doit favoriser la clarté et mettre en avant les préoccupations de l'utilisateur et non pas
les caractéristiques techniques du produit.

2) Public visé
Le public visé est l'ensemble des utilisateurs du logiciel. Selon le contexte d'utilisation, les utilisateurs du
logiciel à documenter peuvent avoir des connaissances en informatique (exemples : cas d'un IDE ou d'un
outil de SCM).

Cependant, on supposera le plus souvent que le public visé n'est pas un public d'informaticiens.

Conséquence essentielle : toute information trop technique est à bannir de la documentation d'utilisation.
Pas question d'aborder l'architecture MVC ou les design patterns employés : ces éléments ont leur place
dans la documentation technique.

D'une manière générale, s'adapter aux connaissances du public visé constitue la principale difficulté de la
rédaction de la documentation d'utilisation.

3) Formes possibles
a) Manuel utilisateur
La forme la plus classique de la documentation d'utilisation consiste à rédiger un manuel utilisateur, le plus
souvent sous la forme d'un document bureautique. Ce document est structuré et permet aux utilisateurs de
retrouver les informations qu'ils recherchent. Il intègre très souvent des captures d'écran afin d'illustrer le
propos.

Un manuel utilisateur peut être organisé de deux façons :

• guide d'utilisation : ce mode d'organisation décompose la documentation en grandes fonctionnalités

décrites pas à pas et dans l'ordre de leur utilisation. Exemple pour un logiciel de finances personnelles :

création d'un compte, ajout d'écritures, pointage… Cette organisation plaît souvent aux utilisateurs, car elle
leur permet d'accéder facilement aux informations essentielles. En revanche, s'informer sur une
fonctionnalité avancée ou un détail complexe peut s'avérer difficile ;

• manuel de référence : dans ce mode d'organisation, on décrit une par une chaque fonctionnalité du logiciel,
sans se préoccuper de leur ordre ou de leur fréquence d'utilisation. Par exemple, on décrit l'un après l'autre
chacun des boutons d'une barre de boutons, alors que certains sont plus « importants » que d'autres. Cette

80
Ing. NTOH MOUALAM Annick
organisation suit la logique du créateur du logiciel plutôt que celle de son utilisateur. Elle est en général
moins appréciée de ces derniers.

b) Tutoriel
De plus en plus souvent, la documentation d'utilisation inclut un ou plusieurs tutoriel(s), destiné(s) à faciliter
la prise en main initiale du logiciel. Un tutoriel est un guide pédagogique constitué d'instructions détaillées
pas à pas en vue d'objectifs simples.

Le tutoriel a l'avantage de « prendre l'utilisateur par la main » afin de l'aider à réaliser ses premiers pas avec
le logiciel qu'il découvre, sans l'obliger à parcourir un manuel utilisateur plus ou moins volumineux. Il peut
prendre la forme d'un document texte, ou bien d'une vidéo ou d'un exercice interactif. Cependant, il est
illusoire de vouloir documenter l'intégralité d'un logiciel en accumulant les tutoriels.

c) FAQ
Une Foire Aux Questions (en anglais Frequently Asked questions) est une liste de questions/réponses sur
un sujet.

Elle peut faire partie de la documentation d'utilisation d'un logiciel.

La création d'une FAQ permet d'éviter que les mêmes questions soient régulièrement posées.

d) Aide en ligne
L'aide en ligne est une forme de documentation d'utilisation accessible depuis un ordinateur. Il peut s'agir
d'une partie de la documentation publiée sur Internet sous un format hypertexte.

Quand une section de l'aide en ligne est accessible facilement depuis la fonctionnalité d'un logiciel qu'elle
concerne, elle est appelée aide contextuelle ou aide en ligne contextuelle. Les principaux formats d'aide en
ligne sont le HTML et le PDF. Microsoft a publié plusieurs formats pour l'aide en ligne des logiciels tournant
sous Windows : HLP, CHM ou encore MAML.

81
Ing. NTOH MOUALAM Annick
Un moyen simple et efficace de fournir une aide en ligne consiste à définir des infobulles (tooltips). Elles
permettent de décrire succinctement une fonctionnalité par survol du curseur.

Conseils de rédaction
1) Structure
Qu'elle soit technique ou d'utilisation, toute documentation doit absolument être écrite de manière structurée,
afin de faciliter l'accès à une information précise.

Structurer un document bureautique signifie :

• le décomposer en paragraphes suivant une organisation hiérarchique ;

• utiliser des styles de titres, une table des matières, des références…

2) Niveau de langage
Comme dit plus haut, le public visé n'a pas forcément d'expérience informatique : il faut bannir les
explications trop techniques et penser à définir les principaux termes et le « jargon » utilisé.

Une documentation doit être rédigée dans une langue simple, pour être comprise de tous, y compris de
personnes étrangères apprenant la langue.

82
Ing. NTOH MOUALAM Annick
 Chapitre 9. Architecture logicielle
L'objectif de ce chapitre est de présenter ce qu'est l'architecture logicielle.

Définition
Le Petit Robert définit l'architecture comme étant « l'art de construire les édifices ». Ce mot est avant tout
lié au domaine du génie civil : on pense à l'architecture d'un monument ou encore d'un pont.

Par analogie, l'architecture logicielle peut être définie comme étant « l'art de construire les logiciels ».

Selon le contexte, l'architecture logicielle peut désigner :

• l'activité d'architecture, c'est-à-dire une phase au cours de laquelle on effectue les grands choix qui vont
structurer une application : langages et technologies utilisés, découpage en sous-parties, méthodologies
mises en œuvre…

• le résultat de cette activité, c'est-à-dire la structure d'une l'application, son squelette.

Importance
Dans le domaine du génie civil, on n'imagine pas se lancer dans la construction d'un bâtiment sans avoir
prévu son apparence, étudié ses fondations et son équilibre, choisi les matériaux utilisés, etc. Dans le cas
contraire, on va au-devant de graves désillusions…

Cette problématique se retrouve dans le domaine informatique. Comme un bâtiment, un logiciel est fait pour
durer dans le temps. Il est presque systématique que des projets informatiques aient une durée de vie de
plusieurs années.

Plus encore qu'un bâtiment, un logiciel va, tout au long de son cycle de vie, connaître de nombreuses
modifications qui aboutiront à la livraison de nouvelles versions, majeures ou mineures. Les évolutions par
rapport au produit initialement créé sont souvent nombreuses et très difficiles à prévoir au début du projet.
Exemple : le logiciel VLC n'était à l'origine qu'un projet étudiant destiné à diffuser des vidéos sur le campus
de l'École Centrale de Paris. Sa première version remonte à l'année 2001.

Objectifs
Dans le domaine du génie civil, les objectifs de l'architecture sont que le bâtiment construit réponde aux
besoins qu'il remplit, soit robuste dans le temps et (notion plus subjective) agréable à l'œil.

L’architecture logicielle poursuit les mêmes objectifs. Le logiciel créé doit répondre aux besoins et résister
aux nombreuses modifications qu'il subira au cours de son cycle de vie. Contrairement à un bâtiment, un
logiciel mal pensé ne risque pas de s'effondrer. En revanche, une mauvaise architecture peut faire exploser
le temps nécessaire pour réaliser les modifications, et donc leur coût.

Les deux objectifs principaux de toute architecture logicielle sont la réduction des coûts (création et
maintenance) et l'augmentation de la qualité du logiciel.

La qualité du code source d'un logiciel peut être évaluée par un certain nombre de mesures appelées
métriques de code : indice de maintenabilité, complexité cyclomatique, etc.

83
Ing. NTOH MOUALAM Annick
 Architecture ou conception ?
Il n'existe pas de vrai consensus concernant le sens des mots « architecture » et « conception » dans le
domaine du développement logiciel. Ces deux termes sont souvent employés de manière interchangeable.
Il arrive aussi que l'architecture soit appelée « conception préliminaire » et la conception proprement dite «
conception détaillée ».

Certaines méthodologies de développement incluent la définition de l'architecture dans une phase plus
globale appelée « conception ».

Cela dit, la distinction suivante est généralement admise et sera utilisée dans la suite de ce livre :

• l'architecture logicielle (software architecture) considère le logiciel de manière globale. Il s'agit d'une vue
de haut niveau qui définit le logiciel dans ses grandes lignes :

- que fait-il ?

- quelles sont les sous-parties qui le composent ?

- interagissent-elles ?

- sous quelle forme sont stockées ses données ?

- etc.

• la conception logicielle (software design) intervient à un niveau de granularité plus fin et permet de préciser
comment fonctionne chaque sous-partie de l'application :

- quel logiciel est utilisé pour stocker les données ?

- comment est organisé le code ?

- comment une sous-partie expose-t-elle ses fonctionnalités au reste du système ?

- etc.

La perspective change selon la taille du logiciel et le niveau auquel on s'intéresse à lui :

• sur un projet de taille modeste, architecture et conception peuvent se confondre ;

• à l'inverse, certaines sous-parties d'un projet de taille conséquente peuvent nécessiter en elles-mêmes un
travail d'architecture qui, du point de vue de l'application globale, relève plutôt de la conception…

L'activité d'architecture
1) Définition
Tout logiciel, au-delà d'un niveau minimal de complexité, est un édifice qui mérite une phase de réflexion
initiale pour l'imaginer dans ses grandes lignes. Cette phase correspond à l'activité d'architecture. Au cours
de cette phase, on effectue les grands choix structurant le futur logiciel : langages, technologies, outils…
Elle consiste notamment à identifier les différents éléments qui vont composer le logiciel et à organiser les
interactions entre ces éléments.

84
Ing. NTOH MOUALAM Annick
Selon le niveau de complexité du logiciel, l'activité d'architecture peut être une simple formalité ou bien un
travail de longue haleine.

L’activité d’architecture peut donner lieu à la production de diagrammes représentant les éléments et leurs
interactions selon différents formalismes, par exemple UML.

2) Place dans le processus de création

L'activité d'architecture intervient traditionnellement vers le début d'un projet logiciel, dès le moment où les
besoins auxquels le logiciel doit répondre sont suffisamment identifiés. Elle est presque toujours suivie par
une phase de conception.

Les évolutions d'un projet logiciel peuvent nécessiter de nouvelles phases d'architecture tout au long de sa
vie. C'est notamment le cas avec certaines méthodologies de développement itératif ou agile, où des phases
d'architecture souvent brèves alternent avec des phases de production, de test et de livraison.

3) Répartition des problématiques

De manière très générale, un logiciel sert à automatiser des traitements sur des données. Toute
application informatique est donc confrontée à trois problématiques :

• gérer les interactions avec l'extérieur, en particulier l'utilisateur : saisie et contrôle de données, affichage.

C'est la problématique de présentation ;

• effectuer sur les données des opérations (calculs) en rapport avec les règles métier (« business logic »).
C'est la problématique des traitements ;

• accéder aux informations qu'il manipule et les stocker, notamment entre deux utilisations. C'est la
problématique des données.

Dans certains cas de figure, l'une ou l'autre problématique sera très réduite (logiciel sans utilisateur, pas de
stockage des données, etc.).

La phase d'architecture d'une application consiste aussi à choisir comment sont gérées ces trois
problématiques, autrement dit à les répartir dans l'application créée.

L'architecture d'un logiciel

Résultat de l'activité du même nom, l'architecture d'un logiciel décrit sa structure globale, son squelette. Elle
décrit les principaux éléments qui composent le logiciel, ainsi que les flux d'échanges entre ces éléments.
Elle permet à l'équipe de développement d'avoir une vue d'ensemble de l'organisation du logiciel, et
constitue donc en elle-même une forme de documentation.

On peut décrire l'architecture d'un logiciel selon différents points de vue. Entre autres, une vue logique
mettra l'accent sur le rôle et les responsabilités de chaque partie du logiciel. Une vue physique présentera
les processus, les machines et les liens réseaux nécessaires.

85
Ing. NTOH MOUALAM Annick