Correction TD2 GL

Exercice 1 - Choix du cycle de vie

Dans cet exercice, il s'agit d'associer un type de logiciel au cycle de vie le plus adapté pour son développement. Le document source présente ces éléments sous forme de deux listes. Voici la correspondance logique, accompagnée d'explications pour vous aider à réviser.

Note du correcteur : Le mot "Spilare" dans le document source est une erreur de frappe pour "Spirale". Je l'ai corrigé dans le tableau ci-dessous.

Type de Logiciel	Cycle de vie proposé (selon la source)	Commentaire pédagogique
Logiciel de contrôle anti-blocage des roues d’une voiture	Spirale / DSDM / Processus unifié	Attention : Bien que ce soit la correspondance issue de la lecture de la source, dans la pratique industrielle, un système critique (comme le freinage) utilise presque toujours un Cycle en V pour garantir une validation et une traçabilité rigoureuses. La spirale peut être justifiée ici si l'on met l'accent sur la forte gestion des risques.
Borne interactive de renseignement sur les horaires	Prototypage évolutif	Les interfaces utilisateurs (IHM) nécessitent des retours rapides des utilisateurs. Le prototypage est idéal.
Jeu vidéo	Prototypage incrémental	Un jeu nécessite des itérations pour ajuster la jouabilité (gameplay) brique par brique.
Logiciel de gestion des plannings	Cascade	Le besoin est généralement très bien défini à l'avance et mathématique. Une approche séquentielle fonctionne bien.
Logiciel de location des cassettes vidéo	Cascade	Il s'agit d'un domaine d'application classique, très bien maîtrisé et sans grande surprise.
Logiciel de gestion commerciale (points de vente)	Cascade / Spirale / en V	La source précise : "Spirale si on ajoute la gestion des risques relatifs à son installation [...] / en V si les besoins ne sont pas assez clairs". Le déploiement multi-sites introduit un risque majeur.
Site Web pour l’inscription universitaire en ligne	Prototypage évolutif	Comme pour la borne, le web nécessite une adaptation continue aux besoins des utilisateurs finaux.

Exercice 2 - Démarches évolutives et modèle en spirale

Cette section justifie les avantages et les inconvénients de certaines approches de développement.

Question 1 - Avantages et limites des démarches évolutives

Les démarches évolutives (comme le prototypage) ont un avantage majeur : elles intègrent le client très tôt dans le processus. Cela favorise l'assurance qualité car le produit correspondra réellement aux attentes de l'utilisateur.

Cependant, la source soulève un point critique pour vos révisions : la complexité de la maintenance. En évoluant en permanence, le code devient plus complexe. Chaque modification nécessite des tests de non-régression pour s'assurer qu'une nouvelle fonctionnalité n'a pas cassé le système existant.

Question 2 - Le modèle en spirale comme méta-modèle

Pourquoi dit-on que le cycle en spirale est un "méta-modèle" ? Parce qu'il ne s'enferme pas dans une seule méthode. À chaque boucle de la spirale, l'équipe évalue les risques :

• Si le risque principal est lié à l'intégration technique, la boucle de la spirale adoptera une approche en cascade.
• Si le risque principal est lié à l'interface utilisateur, la boucle adoptera une approche évolutive (prototypage).

Exercice 3 - Caractéristiques des modèles

Cet exercice valide votre compréhension des "moteurs" (ce qui dirige le passage à l'étape suivante) pour chaque grand modèle de cycle de vie.

• Le modèle en cascade est dirigé par les documents : L'attention est focalisée sur les livrables (les spécifications, les dossiers d'architecture, etc.). On ne passe à l'étape suivante que si le document de l'étape en cours est officiellement validé.
• Le prototypage est dirigé par le code : Les documents passent au second plan. À chaque étape, c'est un logiciel exécutable (le prototype) qui est soumis au client. L'évaluation se fait sur la base du code réel.
• Le modèle en spirale est dirigé par les risques : Avant de planifier ou de réaliser quoi que ce soit, on identifie les objectifs, les alternatives, et surtout les risques. Ces risques doivent être résolus avant d'avancer.

Exercice 4 - Analyse d'un projet spécifique

Bien que l'énoncé de cet exercice n'apparaisse pas explicitement, les éléments de correction indiquent qu'il s'agit d'une étude de cas sur un logiciel de sécurité et de surveillance innovant.

Question 1 - Nature du développement

Le correctif indique que, bien que le projet comprenne de l'innovation (ce qui implique des risques), son cœur de développement reste "classique". Il faut donc appliquer des méthodes traditionnelles, mais en y greffant une couche stricte de gestion des risques à cause des nouvelles techniques utilisées.

Question 2 - Choix du cycle de vie final

La décision dépend de la maturité technologique de l'entreprise :

• Cascade : À choisir uniquement si la société maîtrise déjà parfaitement toutes les technologies requises (le risque est donc nul).
• Spirale : C'est le choix recommandé ici. On intègre des phases de cascade à l'intérieur de la spirale, ce qui permet de sécuriser l'innovation tout en gardant la rigueur d'un développement classique.

Exercice 5 - Éthique et stratégie commerciale

Cet exercice aborde un aspect contractuel du génie logiciel : une société de services (ESN) qui propose un prix artificiellement bas pour remporter un appel d'offres (casser les prix).

La correction stipule que ce comportement est malhonnête, mais contractuellement valide si la société respecte le cahier des clauses techniques (le cahier des charges). Le piège (et la stratégie de la société) réside dans la maintenance et les évolutions : une fois le client dépendant de ce logiciel, chaque modification ou ajout non prévu initialement sera facturé au prix fort. C'est un point classique à comprendre dans la relation Client / Fournisseur en informatique.

Méthode

Pour réussir ce type d'examen de Génie Logiciel :

1. Justifiez toujours vos choix : En conception logicielle, il y a rarement une seule bonne réponse (comme on le voit dans l'Exercice 1). Ce qui rapporte des points, c'est la justification basée sur les caractéristiques du projet (risques, type d'IHM, criticité).
2. Apprenez les définitions exactes : Vous devez savoir ce qui "dirige" chaque modèle (les documents pour la cascade, les risques pour la spirale, le code pour l'agile/prototypage). C'est la clé de voûte de la gestion de projet.
3. Ne négligez pas l'aspect humain et contractuel : Le génie logiciel n'est pas que du code. Les relations clients, la facturation des avenants (Exercice 5) et l'acceptation par les utilisateurs (Exercice 2) font partie intégrante de la réussite ou de l'échec d'un produit.