Génie logiciel & Atelier GL – Résumés, fiches de révision et QCM

Chapitre 1 : Principes et importance du génie logiciel

Le génie logiciel regroupe l’ensemble des activités et méthodes structurées visant à concevoir et
produire des logiciels de haute qualité. Il couvre tout le cycle de vie du logiciel : ingénierie des exigences,
conception (architecture et modules), codage, tests et maintenance. L’objectif est de rationaliser le
développement et la maintenance de logiciels robustes. La qualité logicielle est primordiale : elle se
mesure par des attributs tels que la fiabilité, l’efficacité, l’ergonomie, la maintenabilité et le respect de
normes. Une approche rigoureuse, avec planification précise et gestion des ressources, est nécessaire
pour éviter défauts et retards. Les méthodologies agiles (Scrum, Kanban) et les pratiques DevOps
émergentes offrent plus de flexibilité et de réactivité aux changements.

Chapitre 2 : Spécification des exigences logicielles

L’ingénierie des exigences vise à élaborer un cahier des charges précisant ce que doit faire le logiciel
(fonctionnalités, contraintes, exigences non-fonctionnelles). Le document de spécifications (SRS) est
essentiel pour clarifier les besoins du client, guider l’équipe de développement et établir la base des
tests. Une exigence bien formulée doit être claire, concise et exempte d’ambiguïté Ainsi, chaque besoin
est vérifiable et réalisable. La gestion rigoureuse des exigences (documentation, suivi des changements)
permet de détecter tôt les erreurs et d’éviter la dérive de périmètre, les dépassements de coûts et
l’inadéquation aux besoins clients.

Chapitre 3.1 : Modèle en cascade

Le modèle en cascade est un cycle de vie séquentiel classique : les phases (spécifications, conception,
implémentation, tests, déploiement) s’enchaînent de manière linéaire, chaque phase dépendant des
livrables de la précédente. Ainsi, on conçoit d’abord l’ensemble du logiciel avant de coder. Ce modèle
permet une planification claire, mais rend difficiles les changements tardifs et retarde la détection des
erreurs jusqu’aux phases de test. Il est issu des méthodes industrielles traditionnelles (construction,
aéronautique) où toute modification devient coûteuse.

Chapitre 3.2 : Modèle en V

Le cycle en V est inspiré du modèle en cascade avec la particularité d’associer chaque phase de
conception à une phase de test correspondante. La phase descendante couvre spécifications et
conception, la phase ascendante réalise les tests (unitaires, intégration, validation) en miroir. En V, les
tests sont planifiés parallèlement à chaque niveau de conception, ce qui améliore la vérification
continue. Ce modèle est adapté aux projets critiques (industrie, avionique) car il insiste sur la validation à
chaque étape, mais reste séquentiel et rigide.

Chapitre 3.3 : Modèle incrémental

Le développement incrémental découpe le projet en petits incréments fonctionnels livrables. Chaque

incrément apporte de nouvelles fonctionnalités et est intégré au système existant, permettant un
feedback fréquent et des tests continus. Contrairement au modèle global, on livre une première version
partielle rapidement, puis on complète progressivement. Les avantages incluent une livraison plus rapide
des fonctionnalités critiques et la capacité d’ajuster le produit en cours de développement selon les
retours clients. Cette approche facilite l’adaptation aux changements et la maîtrise des risques par
itérations, au prix d’une architecture qui doit rester souple.

Chapitre 3.4 : Méthodologie lourde vs Scrum

Les méthodes traditionnelles (dites « lourdes ») comme le Processus Unifié (RUP) reposent sur une
planification complète et des phases séquentielles (étude, conception, construction, tests). Elles
conviennent à de grands projets stables mais manquent de souplesse. En revanche, Scrum est une
méthode agile itérative qui définit trois rôles clés : le Product Owner (représentant du client, gardien du
backlog), le Scrum Master (facilitateur du processus), et les Développeurs. Les travaux sont organisés en
sprints (itérations de durée fixe). Scrum prévoit des réunions codifiées : la planification de sprint (choix
des éléments du Product Backlog à réaliser), la revue de sprint (démonstration des fonctionnalités
terminées) et la rétrospective (amélioration du processus), ainsi que la mêlée quotidienne (stand-up)
pour synchroniser l’équipe. Les artefacts Scrum comprennent le Product Backlog (liste ordonnée des
exigences) et le Sprint Backlog. Ce cadre favorise l’adaptation rapide aux changements et le feedback
fréquent.

Chapitre 4.1 : Architecture et conception logicielle

L’architecture logicielle décrit la structure globale du système : composants principaux, connexions et

interactions, au lieu des détails internes. Elle répond au « comment faire » alors que l’analyse
fonctionnelle décrit « quoi faire ». La conception logicielle (design) détaille l’architecture en définissant
les modules, interfaces et algorithmes. Des principes directeurs assurent la qualité du design : masquage
de l’information (cacher l’implémentation interne), faible couplage (minimiser les dépendances entre
modules) et forte cohésion (un module réalise une seule responsabilité). Ces principes améliorent la
maintenabilité et la robustesse du logiciel. La phase de conception peut représenter jusqu’à 40 % de
l’effort total de développement, soulignant son importance pour la qualité finale.

Chapitre 4.2 : Qualité logicielle et patrons de conception

Les principes de qualité logicielle concernent les attributs attendus du logiciel (fiabilité, maintenabilité,
efficacité, sécurité, etc.). Par exemple, un logiciel de qualité doit être fiable (peu de défauts), efficace
(bonnes performances) et maintenable (facile à faire évoluer). Les patrons de conception (design
patterns) sont des solutions réutilisables à des problèmes de conception récurrents. Chaque patron
décrit un arrangement générique de classes et d’objets pour résoudre un cas typique (ex. singleton,
observateur, fabrique, stratégie). Ce vocabulaire commun capitalise l’expérience des concepteurs. Un
patron de conception est la « meilleure solution connue » à un problème donné. En utilisant des
patrons, on améliore la modularité et la qualité du code, tout en facilitant la communication entre
concepteurs et développeurs.

Chapitre 5 : Gestion de configuration logicielle

La gestion de configuration logicielle englobe les processus et outils pour maîtriser les versions et
évolutions d’un logiciel. Elle consiste à gérer la description technique du système et à tracer toutes les
modifications tout au long du cycle de vie. Concrètement, on utilise des systèmes de gestion de versions
(Git, Subversion, etc.) pour stocker et suivre les différentes versions et révisions du code source, de la
documentation et des livrables. Cela permet de revenir à un état antérieur, de collaborer en parallèle et
de constituer des livrables reproductibles. La gestion des variantes (software product lines) fait
également partie du domaine : il s’agit de contrôler les différentes déclinaisons d’un même produit
(options, modules). Par exemple, en électronique embarquée, on définit des variantes pour adapter le
logiciel à chaque version matérielle sans recréer tout le projet. La gestion de configuration garantit ainsi
la cohérence du logiciel et la traçabilité de son évolution.

Chapitre 6 : Tests et validation du logiciel

Les tests logiciels visent à garantir la qualité et la fiabilité du produit en exécutant une série de
vérifications. Le test est une quête constante de qualité : il comprend la vérification (le logiciel répond-il
aux spécifications ?) et la validation (répond-il aux besoins réels de l’utilisateur ?). Selon B. W. Boehm,
« la vérification consiste à construire le produit correctement, la validation à construire le bon produit ».
À chaque phase du développement, différents tests sont pratiqués pour détecter le plus tôt possible les
défauts (unitaires, d’intégration, système, acceptation, performance, etc.). Le processus de test
comprend plusieurs activités clés :

• Planification des tests : définir objectifs, stratégie, périmètre, niveaux de tests, critères
d’entrée/sortie, ressources et planning.

• Analyse et conception des tests : identifier et documenter les cas de test (scénarios, données).

• Implémentation et exécution des tests : développer les scripts ou préparer l’environnement,

puis exécuter les tests et consigner les résultats (anomalies).

• Clôture des tests : évaluer la campagne de test, vérifier que les objectifs sont atteints et produire
un bilan.

Les tests unitaires (écrits par les développeurs) isolent chaque composant pour en démontrer la
conformité aux exigences. Les tests d’intégration vérifient l’interaction entre modules, et les tests
système valident le logiciel complet dans son environnement final. Des tests statiques (revues de code,
analyse statique) peuvent détecter des défauts sans exécution. Chaque niveau de test correspond à un
objectif spécifique de qualité (fonctionnalité, performance, sécurité, etc.). En somme, une stratégie de
test planifiée et rigoureuse est essentielle pour valider le logiciel et réduire les risques de défaut en
production.

Fiche de révision – Points essentiels

Chapitre 1 – Génie logiciel :

• Activités clés : ingénierie des exigences, conception logicielle, codage, tests, maintenance.
 • Qualité logicielle : attributs principaux : fiabilité, efficacité, ergonomie, maintenabilité, respect
des normes.

• Approche rigoureuse (processus structurés) pour assurer la qualité et gérer les ressources.

• Évolution vers l’agile (Scrum, Kanban) et DevOps pour plus de flexibilité.

Chapitre 2 – Spécifications d’exigences :

• Spécification fonctionnelle (SRS) : document décrivant en détail ce que doit faire le logiciel
(exigences fonctionnelles et non-fonctionnelles).

• Objectifs : clarifier les besoins du client, guider l’équipe, servir de base aux tests.

• Exigences correctes : claires, concises, sans ambiguïté.

• Importance de la gestion des exigences : suivre et valider les changements pour éviter dérives,
retards et mauvaise qualité.

Chapitre 3.1 – Modèle cascade :

• Phases linéaires et séquentielles, chaque étape attend l’achèvement de la précédente.

• Orienté documentation, convenant aux projets stables.

• Inconvénient : réactivité réduite aux changements tardifs, tests reportés en fin de cycle.

Chapitre 3.2 – Modèle en V :

• Comme cascade mais avec phase descendante (analyse, design) puis phase ascendante (tests).

• Chaque phase de conception a un test associé (test unitaire pour conception détaillée, test
d’intégration pour modules, etc.).

• Validation précoce des exigences grâce au parallèle entre développement et tests.

Chapitre 3.3 – Modèle incrémental :

• Développement par petits incréments successifs.

• Livraison rapide d’une première version minimale, puis enrichissement progressif.

• Avantages : feedback fréquent, adaptation aux changements, priorisation des fonctionnalités

critiques.

• Permet tests continus et vérification précoce à chaque incrément.

Chapitre 3.4 – Méthodologies lourdes vs Scrum :

 • Méthode lourde (ex. RUP) : phases planifiées, documentation complète, moins de changement
possible.

• Scrum (agile) : itératif en sprints courts, avec 3 rôles (PO, SM, dev), 4 réunions clés (planification,
mêlée quotidienne, revue, rétrospective) et artefacts (Product Backlog, Sprint Backlog,
incrément).

• Scrum privilégie la collaboration, l’adaptation rapide et les livraisons fréquentes.

Chapitre 4.1 – Architecture & conception :

• Architecture logicielle : structure globale du système (composants et leurs interactions).

• Différence analyse vs architecture : l’analyse décrit quoi faire, l’architecture comment faire.

• Principes de conception : masquage de l’information, faible couplage, forte cohésion.

• Conception = choix d’algorithmes, structures de données et patterns pour réaliser l’architecture.

Chapitre 4.2 – Qualité & design patterns :

• Qualité attendue : fiabilité, performance, maintenabilité, sécurité, ergonomie…

• Patrons de conception : solutions réutilisables à des problèmes récurrents de design.

• Vocabulaire commun (singleton, observateur, etc.) permettant de capitaliser l’expérience et

d’améliorer la modularité.

• Un patron = « meilleure solution connue » à un problème de conception.

Chapitre 5 – Gestion de configuration :

• Gestion des versions : tracer toutes les versions/révisions du code, documents, environnements.

• Utilisation d’outils de versioning (Git, SVN…) pour collaborer et revenir aux configurations
antérieures.

• Suivi des changements (commits, branches, tags) pour garantir la traçabilité et la

reproductibilité.

• Gestion des variantes : contrôler les différentes déclinaisons d’un même logiciel (options, plates-
formes).

Chapitre 6 – Tests et validation :

• Objectif : garantir qualité et fiabilité en vérifiant (faire bien) et validant (faire ce qu’il faut) le
logiciel.

• Processus de test : planification, analyses/conception, implémentation, exécution, bilan.

 • Tests statiques (revues, analyse de code) et dynamiques (unitaires, intégration, système,
acceptation).

• Exemples de tests : tests unitaires isolant chaque module; tests d’intégration vérifiant
l’interfaçage entre composants; tests fonctionnels et de performance selon les exigences.

• Importance de définir des critères d’entrée/sortie et un plan de tests pour mesurer

l’avancement et la fin de chaque étape.

QCM et questions à développement

Chapitre 1 – Principes du génie logiciel

QCM 1: Le génie logiciel vise principalement à :

A. Produire du code le plus rapidement possible sans documentation.
B. Appliquer des méthodes rigoureuses pour développer et maintenir des logiciels de qualité. (Correct)
C. Remplacer tous les tests par de la relecture de code.
D. Développer uniquement des logiciels embarqués.

QCM 2: Lequel des attributs suivants n’est pas un critère de qualité logicielle courant ?
A. Fiabilité
B. Efficacité
C. Maintenabilité
D. Couleur de l’interface utilisateur (sans rapport avec la qualité interne du code)

Question à développement : Expliquez comment le génie logiciel contribue à la qualité d’un logiciel.
Donnez au moins deux exemples d’activités ou de bonnes pratiques associées.

Chapitre 2 – Spécification des exigences

QCM 1: Une spécification fonctionnelle (SRS) décrit principalement :

A. Les algorithmes et le code source.
B. Les fonctionnalités et contraintes du système du point de vue utilisateur. (Correct)
C. Les détails de déploiement matériel du logiciel.
D. Le budget financier du projet.

QCM 2: Quel est un avantage clé de rédiger des spécifications fonctionnelles claires ?
A. Accélérer le codage sans réévaluation.
B. Clarifier les exigences et fournir une base pour les tests. (Correct)
C. Éliminer la nécessité de réunions d’équipe.
D. Assurer automatiquement la sécurité du logiciel.

Question à développement : Pourquoi la gestion des exigences est-elle cruciale dans un projet logiciel ?
Donnez des exemples de risques associés à une mauvaise définition des exigences.

Chapitre 3.1 – Modèle en cascade

QCM 1: Dans le modèle en cascade, les phases de développement sont organisées de manière :
A. Linéaire et séquentielle, chaque phase dépendant de la précédente. (Correct)
B. Itérative, avec retours fréquents sur chaque étape.
C. Concurrente, avec plusieurs phases en parallèle.
D. Aléatoire, sans ordre préétabli.

QCM 2: Un inconvénient majeur du modèle en cascade est que :

A. Il ne nécessite pas de phase de tests.
B. Les modifications tardives peuvent être très coûteuses. (Correct)
C. Il encourage la livraison fréquente de fonctionnalités.
D. Il supprime le besoin de documentation.

Question à développement : Quels types de projets et de contraintes rendent le modèle en cascade

approprié ou inadapté ? Expliquez en comparant avec un contexte agile.

Chapitre 3.2 – Modèle en V

QCM 1: Le cycle en V se caractérise par :

A. Des phases descendante et ascendante, correspondant respectivement au développement et aux
tests. (Correct)
B. Aucun test prévu avant la fin du projet.
C. Un même processus que la cascade (aucune différence).
D. Des itérations rapides sans phases définies.

QCM 2: Contrairement au cycle en cascade, le cycle en V met l’accent sur :

A. La suppression de toute documentation.
B. La planification conjointe des activités de développement et de test pour chaque niveau. (Correct)
C. Le prototypage continu à chaque étape.
D. L’intégration automatique du code en continu.

Question à développement : Expliquez en quoi le modèle en V améliore la gestion de la qualité par

rapport au modèle en cascade. Donnez un exemple de test pour chaque étape de conception.

Chapitre 3.3 – Modèle incrémental

QCM 1: Quel avantage principal offre le développement incrémental ?

A. Livraison précoce des fonctionnalités critiques et feedback continu. (Correct)
B. Suppression totale des phases de test.
C. Conception figée sans évolution possible.
D. Aucun besoin d’architecture logicielle.

QCM 2: Le développement incrémental se définit par :

A. Livrer le système complet d’un seul coup uniquement à la fin.
B. Découper le projet en éléments plus petits et livrer ces incréments séquentiellement. (Correct)
C. Développer uniquement des prototypes (pas de livrable final).
D. Concentation sur un seul développeur travaillant sur tout.

Question à développement : Décrivez comment une équipe pourrait planifier un projet en utilisant la
méthode incrémentale. Quels critères permet-elle d’optimiser (priorisation, tests, etc.) ?

Chapitre 3.4 – Méthodologies lourdes vs Scrum

QCM 1: Parmi les rôles suivants de Scrum, lequel représente la vision du client et priorise les exigences ?
A. Scrum Master
B. Product Owner (Correct)
C. Développeur (équipe)
D. Chef de projet traditionnel

QCM 2: En Scrum, la mêlée quotidienne (daily stand-up) est :

A. Une réunion de planification de sprint.
B. Une réunion technique de conception.
C. Une réunion quotidienne de synchronisation de l’équipe. (Correct)
D. Un atelier de gestion des risques.

Question à développement : Donnez deux différences majeures entre une approche traditionnelle (cycle
en cascade) et une approche Scrum/agile (en termes d’organisation du travail et de gestion des
changements).

Chapitre 4.1 – Architecture & conception

QCM 1: Quelle affirmation décrit correctement l’architecture logicielle ?

A. Elle spécifie quoi le logiciel doit faire (fonctionnalités).
B. Elle décrit comment structurer le système pour réaliser les spécifications. (Correct)
C. Elle remplace l’analyse fonctionnelle en détaillant les tests.
D. Elle n’inclut pas les interactions entre les composants.

QCM 2: Le principe de faible couplage en conception signifie :

A. Les modules sont fortement interdépendants.
B. Les modules ont peu d’interactions entre eux. (Correct)
C. Un module doit remplir plusieurs responsabilités.
D. Le code doit être optimisé en priorité.

Question à développement : Pourquoi une architecture logicielle bien définie facilite-t-elle la

maintenance et l’évolutivité d’un logiciel ? Donnez un exemple de principe de conception qui illustre
cela.

Chapitre 4.2 – Qualité & patrons de conception

QCM 1: Un patron de conception (design pattern) est :
A. Une meilleure solution connue à un problème de conception récurrent. (Correct)
B. Un algorithme de tri spécifique.
C. Un type de base de données.
D. Une méthode de test logiciel.

QCM 2: Parmi ces attributs, lequel n’est pas un critère de qualité logicielle ?
A. Fiabilité du logiciel
B. Maintenabilité du code
C. Ergonomie (convivialité)
D. Couleur de la documentation (sans impact sur la qualité du produit)

Question à développement : Donnez un exemple concret de patron de conception (par exemple

Singleton ou Observateur) et expliquez en quoi il améliore la conception logicielle.

Chapitre 5 – Gestion de configuration

QCM 1: La gestion de configuration logicielle vise principalement à :

A. Planifier le projet sans gérer de code.
B. Gérer les modifications et versions d’un logiciel tout au long de son cycle de vie. (Correct)
C. Remplacer entièrement la phase de tests.
D. Améliorer les performances d’exécution.

QCM 2: La gestion des variantes d’un produit logiciel concerne :

A. Les différentes versions du code source dans le temps.
B. Les configurations matérielles sur lesquelles on exécute le logiciel.
C. Les différentes déclinaisons/options du même produit (configurations logicielles). (Correct)
D. Les fichiers de log générés par l’application.

Question à développement : Pourquoi un outil de contrôle de version (ex. Git) est-il indispensable dans
la gestion de configuration logicielle ? Illustrez par un exemple de branchement ou de fusion.

Chapitre 6 – Tests et validation

QCM 1: Selon B. W. Boehm, la vérification consiste à construire le produit correctement, tandis que la
validation consiste à construire le bon produit. Donc, la vérification répond à la question :
A. Le logiciel correspond-il aux spécifications ? (Correct)
B. Le logiciel répond-il aux besoins réels des utilisateurs ?
C. Le logiciel est-il rapide à coder ?
D. Le logiciel est-il gratuit à déployer ?

QCM 2: L’objectif principal des tests unitaires est :

A. Isoler chaque composant pour vérifier qu’il fonctionne selon les exigences. (Correct)
B. Tester les performances du système dans son ensemble.
C. Vérifier la conformité du logiciel auprès de l’utilisateur final.
D. Évaluer le modèle d’affaire du projet.