Chapitre 1: Introduction

Génie logiciel : Définition :

Ensemble de méthodes, techniques et outils nécessaires à la
production de logiciels de qualité
Facteurs de qualité du logiciel :
 Fiabilité: La conformité du logiciel vis-à-vis de ses spécifications.- Les résultats sont vérifiables et
sont ceux attendus
 Performance: L’ensemble des exigences non fonctionnelles concernant la qualité en matière
de temps de réponse, de dimensionnement et de comportement système du logiciel.
 Sécurité: La mise en place de la politique d’attribution de droit d’accès pour un ensemble de
ressources et de fonctionnalités du logiciel.
Eléments clés du génie logiciel:
Méthodologie de développement :
• Ensemble de principes régissant la conception, le développement et la livraison du
logiciel.
Méthode de développement :
• Une modélisation (concepts manipulés).
• Une implémentation d’une méthodologie de développement logiciel.
Processus de développement logiciel :
 C’est l’ensemble des activités du développement logiciel
Modèles de cycle de vie de développement logiciel : chaque modèle de cycle de vie présente un
procédé d’agencement des activités.
Outils de développement : N’importe quel outil utilisé lors du développement logiciel.
 • Exemples : Editeurs de texte, Outils de gestion de projet, Compilateurs, IDE, etc.
 • Ateliers de génie logiciel (AGL) : Ensemble d’outils permettant de couvrir le cycle
 de vie logiciel depuis .
 • Exemples : Rational Rose, Power AMC, etc
Chapitre 2 : Ingénierie des exigences
1) Processus d’ingénierie des exigences:
1-Recueil des données: cahier de charges client
Collecte des besoins à travers des questionnaires, interviews,
réunions, brainstorming, etc.
2-Analyse des besoins: Raffinement des besoins «bruts »en eliminant
les ambiguïtés, incohérences, redondances, incomplétudes et en
filtrant les besoins (par objectif, par contexte, etc.)
3-Spécification des exigences:cahier de spécification: :Rassembler
dans un document unique (le cahier de spécification ) l’ensemble des
exigences du système sous forme cohérente.
2) Catégories des exigences:
Fonctionnelles: définit les services du système en termes de relation
entre les entrées et les sorties.
Une exigence fonctionnelle donne des informations concrètes sur une
fonctionnalité, Exemple , La photo de profil sur Facebook doit être
visible lors de la connexion
Non Fonctionnelles: ce sont les contraintes et les propriétés remplies
par le système dans son intégralité
Une exigence fonctionnelle peut avoir de nombreux attributs
d'exigences non fonctionnelles. Exemple, temps de connexion
(performances), aspect et convivialité de la page de profil
(convivialité), nombre d'utilisateurs pouvant se connecter à la fois (capacité,
performances)
Liées au processus : ce sont des contraintes liées au
développement du produit (coût, délai, assurance qualité), ou liées à
l’exploitation future (prix de vente, marché de distribution, etc.)
 3) Types de documents de spécification:
Pour le point de vue interne : une description la plus précise possible
du système qui doit être réalisé : • Spécification du système ;• Ou Spécification
technique.
Pour le point de vue externe : une description de haut niveau
d’abstraction des services que doit rendre le système et les contraintes sous
lesquelles il opère : Spécification des besoins ;Ou Spécification générale.
Les outils de gestion de la configuration logicielle permettent à une équipe des développeurs de
gérer un projet informatique.
Travailler à plusieurs : Chaque développeur utilise les 2 fonctions principales d’un GCL : le
ckeckout qui permet de récupérer la dernière version d’un projet depuis un dépôt, et le commit
qui permet d’envoyer les modifications sur le dépôt et ainsi créer une nouvelle version du projet
que d’autres développeurs pourront récupérer.
Conserver l’ensemble des versions d’un ensemble de fichiers : Cela permet de revenir en arrière
en cas de problème sur la version actuelle.
Conserver les actions des développeurs : La journalisation.
Gérer les conflits : Lorsque plusieurs modifications ont lieu sur un même fichier : en effet si deux
personnes modifient le même fichier, des conflits peuvent apparaitre (édition de la même ligne,
etc.). La gestion de conflits permet d’éviter qu’un travail soit écrasé par un collègue.
2) Les architectures d’un GCL :
Basée sur le modèle Client- Serveur : le serveur possède
l’historique des versions du projet et se charge de les transmettre aux développeurs
• Exemple de GCL à architecture centralisée : CVS et Subversion.

 Simple dans la mise en place puisqu'il se base sur le modèle classique de client/serveur

 Travail à plusieurs sur une branche détachée de la branche principale

 Il nécessite un serveur de back-up pour assurer la fiabilité

La gestion décentralisée consiste à voir le logiciel de gestion de versions comme un outil

permettant à chacun de travailler à son rythme, de façon désynchronisée des autres, puis d'offrir
un moyen à ces personnes de s'échanger leur travaux respectifs. Par conséquent, il existe
plusieurs dépôts pour un même logiciel.
Dans la pratique, les logiciels distribués sont capables de fonctionner dans ce mode distribué
(plusieurs dépôts) mais on utilise très souvent un seul serveur qui sert de « point de rencontre »
entre les personnes.
• Exemple de GCL à architecture décentralisée : Git, GNU Arch et Mercurial

 Permet de travailler de manière indépendante des autres développeurs

 il est possible d'enregistrer ses modifications sur le dépôt sans être connecté à Internet
 il est possible de partager ses modifications avec les autres développeurs en les envoyant
sur un serveur de "rencontre

 Cloner un dépôt est long car il faut récupérer tout son historique
 La gestion de la concurrence en mode lock
3) Les principes de base :
La journalisation: • La journalisation permet de contrôler les modifications
apportées à chaque fichier ou composant d’un logiciel:
❖Historique d’accès :Qui? Quand? Nature(Création/modification/destruction).
❖Détail de la modification : Par des outils intelligents de comparaison des sources

 Gestion de conflit pessimiste: impose à chaque utilisateur de demander un verrou avant de

modifier une ressource ; ce verrou lui garantit qu'il sera le seul à modifier la ressource.
 Gestion de conflit optimiste: Les développeurs peuvent éditer en même temps le même
fichier : le logiciel de gestion de versions s’occupe de fusionner toutes les versions du même
fichier en un seul. En cas de conflit, les développeurs sont alertés et doivent intervenir
manuellement pour le résoudre.
Chapitre4
Conception logicielle - Définition
Processus d’analyse et de résolution des problèmes(Identifier la meilleure façon d’implémenter
les exigences fonctionnelles)
Objectifs de la conception
La réutilisabilité: Réutiliser le code (code source ou API) produit par d'autres afin De réduire le
temps et minimiser la complexité de l’ de application.
La maintenabilité: • Est la facilité avec laquelle un logiciel peut être maintenu.
Architecture logique– Approche de résolution
Approches de haut en bas (Top– Down):
Concevoir la structure générale. Etudier les éléments du plus bas niveau. Détailler tous les
éléments de la structure : format des données, algorithmes, etc.
Approche de basvers le haut (Bottom– Up) :
Identifier les éléments de bas niveau Prendre des décisions concernant la réutilisation Décider
de l’assemblage des éléments pour créer des structures de plus haut niveau.
Combinaisondes 2 approches :
o Une approche de haut en bas est nécessaire afin de garantir une bonne
structure au système.Une approche de bas en haut est utile afin de s’assurer que des
composantes réutilisables soient concevable et réalisables.
Découpage en couches – Modèle en 3 couches
Avantages :
 Découpage conforme à une démarche structurée par les cas d’utilisation.
 On peut s’occuper d’une couche sans savoir à connaitre le détail des autres couches.
 Minimise les dépendances entre couches
 La sécurité peut être renforcée
Inconvénients:
 Complexe.
 Plus d’exigence.
 Problèmes au niveau des performances
Découpage en couches – Modèle en 5 couches
La couche IHM (Présentation) : Gérer le dialogue Humain machine :
• Capter, sous forme d’évènements, les requêtes provenant de l’utilisateur (clavier, souris, voix,
etc.)
La couche Applicative : Implémenter les services (cas d’utilisation) demandés par l’utilisateur :
• Utilise les services métier (propres au domaine de l’application,couche inférieure).
• Utilise les services techniques (authentification, autorisation, etc.)
La couche Métier : Implémenter les services atomiques métiers propres au domaine et
réutilisables par les applications :
• Permet de capitaliser le savoir faire de la structure en matière de
règles métiers, de règles de gestion et de contrôle de cohérence.
• Sollicitée par la couche applicative.
• Potentiellement réutilisable
La couche d’accès aux données :
Elle gère le stockage des données, logiquement nommée couche de données.
La couche de gestion des données : Elle sert de communicateur avec la base
de données. Son avantage est le rôle de sas de sécurité entre l'application et la base
de données. Si la structure de données change, seule (en théorie) cette couche est à
modifier.La couche de gestion des données : Elle sert de communicateur avec la base
de données. Son avantage est le rôle de sas de sécurité entre l'application et la base
de données. Si la structure de données change, seule (en théorie) cette couche est à
modifier.
Avantages du MVC :
• Il peut y avoir plusieurs vues sur le même modèle.
• Plusieurs contrôleurs peuvent modifier le même modèle.
• Toutes les vues seront notifiées des modifications.
Application de critères de qualité :
• Faible couplage.(plusieurs agregation)
• Forte cohésion.
 S’assurer que le produit répond aux exigences. ❖Conformité au cahier des
charges.==> Validation
S’assurer que le produit est construit correctement==> Vérification.
❖Les tests peuvent prouver la présence de défauts, mais ne peuvent en prouver
l'absence.
 Les tests réduisent la probabilité que des défauts restent cachés dans le logiciel.
Le test logiciel pourra avoir pour but de qualifier un logiciel ou certifier un produit
les principaux métiers du test sont:
❑ Analyste de test:prend en charge la conception des cas de test et des jeux de
données
❑ Analyste technique de test: s'occupe des activités à forte technicité
❑ Gestionnaire d’environnement de test: s'occupe de la mise en place de
l’infrastructure et des outils
nécessaires au bon déroulement des activités de test
❑ Architecte de test: a pour rôle de définir et évaluer la stratégie globale des
activités de tests
❑ Chef de projet de test: gérer les activités de test en prenant en compte les coûts et
les délais à respecter.
❑ Testeur: testeur a pour mission d'exécuter les tests (manuels ou automatique) et
de vérifier que le résultat obtenu correspond au résultat attendu

Bug ❖Dysfonctionnement de l'ordinateur causé par un défaut de conception ou de

réalisation d'un programme informatique
Crash applicatif ou Deny of Service❖Déclenchement d’un mécanisme à la fois
matériel et logiciel qui met hors service le logiciel défaillant lors de la tentative de ce
dernier d’effectuer des opérations impossibles à réaliser (exceptions : division
par zéro, recherche d'informations inexistantes, etc.)
 Fuite de mémoire ❖Dysfonctionnement dans les opérations d'allocation de
mémoire. La quantité de mémoire utilisée par le logiciel défaillant va en augmentant
continuellement et gêne le déroulement des autres logiciels et les entraîne à des
dysfonctionnements.
Vulnérabilité ❖Faiblesse dans un système informatique permettant à un attaquant de
porter atteinte à l'intégrité de ce système, c'est-à-dire à son fonctionnement normal,
à la confidentialité et l'intégrité des données qu'il contient. On parle aussi de faille de
sécurité informatique.
Méthodes de tests:
Méthode boîte noire:
• Tests autour du fonctionnement externe du système.
• Les détails d'implémentation des composants ne sont pas connus.
Méthode boîte blanche (ou transparente):
• Tests autour du fonctionnement interne du système.
• Les détails d'implémentation des composants sont tous connus
Méthode boîte grise:
• Combinaison des deux approches précédentes :
• Tests autour du fonctionnement externe du système.
• Quelques détails d’implémentation des composants sont connus.
Types de tests:
Test nominal (de bon fonctionnement):❖Entrer des données volontairement
valides.Test to pass.
Test de robustesse (de défense) ❖Entrer des données volontairement invalides.
Test to fail.
Test unitaire ❑Tester les fonctions (ou les modules) de code par les programmeurs.
Test nécessitant une connaissance approfondie du code de l’application.
Test d’intégration ❑Valider le bon fonctionnement d’une ou de plusieurs parties
(modules de code, librairies, applications individuelles) développées
indépendamment avec le reste de l’application
Test de non régression (Tests liés au changement ) ❑Reprendre un ensemble de cas
de tests après avoir fixé les bogues ou les modifications du logiciel ou de
l’environnement.❖Les outils de test automatisé peuvent être extrêmement
utiles pour ce type de test.
Test d’administration ❑Se Focaliser sur les aspects d’administration (tests des
backups et restaurations; reprise après sinistre; gestion des utilisateurs; tâches de
maintenance; chargements de données et tâches de migration, etc.
Test de sécurité❑Détecter les intrusions et les failles de sécurité par le biais d’une
vérification périodique de vulnérabilité de sécurité
Test & Scrum
TDD : Test Driven Develpment
• Développement piloté par les tests.
• Ecrire des tests pour vérifier si le code écrit fonctionne
correctement : « Est-ce que mon code fonctionne? »
• Permet au développeur de comprendre ce que le
système doit faire
ATDD : Acceptance Test Driven Development
• S’intéresse à la qualité externe du logiciel
• «Est-ce que le système fait ce qui est demandé de
faire? »
• S’assurer que tous les membres du projet comprennent
précisément quels besoins doivent être réalisés et
implémentés.

Test d’acceptation : processus permettant d’accepter une story à la fin d’un sprint.
• Etapes d’un test d’acceptation :
• Décrire le comportement attendu d’une story avec les conditions de satisfaction.
• Transformer ces conditions en cas de tests appelés Story Test.
• Développer le code applicatif qui répond au comportement attendu de la story.
• Passer les Story test sur le code applicatif.
• En cas d’échec, corriger les tests ou le code.
Exemple :
• User story : En tant qu’abonné je veux réserver un livre afin de réaliser une
recherche
• Critères d’acceptation :
• Abonné autorisé (abonnement non expiré, abonnement ne
figurant pas dans la liste rouge, etc.).
• Livre disponible.
• Etc
Story tests :
• Cas1:réservation réussie.
• Etant donné l’abonné Mohamed ayant l’abonnement num 345 valide
et ne figurant pas dans la liste rouge et le nombre d’exemplaires du
livre intitulé « Testing » étant égale à 3
Quand l’abonné Mohamed réserve le livre intitulé « Testing »
Alors la réservation est réussie et le message « Réservation effectuée
avec succès » est affichée et le nombre d’exemplaires du livre intitulé
« Testing » est réduit à 2.
• Cas2:réservation échouée.
• Etant donné l’abonné Mohamed ayant l’abonnement num 345 valide
et ne figurant pas dans la liste rouge et aucun exemplaire du livre
intitulé « Testing » n’est disponible
Quand l’abonné Mohamed réserve le livre intitulé « Testing »Alors le message «
Livre non disponible » est affiché et l’abonné Mohamed est redirigé vers une
interface d’ajout à une liste d’attente.