Génie Logiciel I Exam

Exercice 1 - Comparaison des termes

Note : La question 3 est absente du sujet original (la numérotation passe de 2 à 4). L'exercice est traité selon la numérotation fournie.

Question 1 - Bien développer versus développer le bon logiciel

• Bien développer fait référence à la manière dont le logiciel est construit d'un point de vue technique. Cela signifie respecter les bonnes pratiques de programmation, les normes de qualité, l'architecture et les spécifications.
• Développer le bon logiciel fait référence à l'adéquation du produit final avec les besoins réels de l'utilisateur ou du client. Un logiciel peut être techniquement parfait ("bien développé") mais inutile s'il ne résout pas le problème du client ("pas le bon logiciel").

Question 2 - Vérification versus validation

• Vérification : Elle répond à la question "Construisons-nous le produit correctement ?". C'est l'évaluation du logiciel par rapport à ses spécifications techniques (ex: un composant fait-il exactement ce que son document de conception décrit ?).
• Validation : Elle répond à la question "Construisons-nous le bon produit ?". C'est l'évaluation du logiciel par rapport aux attentes et besoins métier du client, souvent à la fin du cycle.

Question 4 - Cycle itératif versus Cycle incrémental

• Cycle itératif : Le développement se fait par approximations successives. On construit une version globale mais incomplète ou basique du système, puis on l'affine et on l'améliore au fil des itérations jusqu'à obtenir la qualité souhaitée.
• Cycle incrémental : Le système est découpé en modules ou sous-ensembles fonctionnels (incréments). Chaque incrément est développé complètement et livré. Le système grandit par ajouts successifs de nouvelles fonctionnalités.

Question 5 - Développement classique versus Développement agile

• Développement classique (prédictif) : Approche linéaire et rigide (comme le modèle en cascade ou en V). Très axée sur la planification initiale stricte, une documentation exhaustive et une définition figée des besoins avant de commencer à coder.
• Développement agile (adaptatif) : Approche souple, itérative et incrémentale. Elle privilégie l'adaptation rapide aux changements, la collaboration continue avec le client, et la livraison fréquente de logiciels fonctionnels plutôt qu'une documentation lourde.

Exercice 2 - Concepts et Modèles de Cycle de Vie

Question 1 - Vrai ou faux avec justification

a) Le succès d’un projet tient essentiellement à la livraison d’un programme fonctionnel. Faux. Un programme fonctionnel ne suffit pas si le projet a largement dépassé son budget, ses délais, ou s'il ne répond pas aux vrais besoins des utilisateurs finaux, ou s'il n'est pas maintenable.

b) Une fois le logiciel est implémenté et qu’il fonctionne, le travail de l’ingénieur est terminé. Faux. La phase de maintenance (corrections de bugs, mises à jour, évolutions) commence après la livraison et représente souvent la majeure partie du cycle de vie et du coût d'un logiciel.

c) Tant qu’un logiciel ne fonctionne pas, il n’y a pas moyen d’en mesurer la qualité. Faux. L'assurance qualité intervient bien avant l'exécution du code : revues des cahiers des charges, inspection des modèles de conception (UML), analyses statiques de code, et validation de l'architecture permettent de mesurer et d'assurer la qualité très tôt.

d) Le logiciel est un produit qui peut être fabriqué en utilisant les mêmes technologies utilisées pour d'autres objets. Faux. Le logiciel est un produit purement immatériel et intellectuel. Contrairement aux objets physiques, il ne s'use pas avec le temps (pas de dégradation physique) et sa reproduction ("fabrication" en série) a un coût marginal quasi nul.

e) La plupart des projets de développement de logiciels sont initiés pour tenter de répondre à un besoin commercial. Vrai. Dans le milieu professionnel, les logiciels sont généralement créés pour résoudre un problème métier, automatiser un processus coûteux, dégager un avantage concurrentiel ou être vendus (produits commerciaux).

Question 2 - Exemples de projets selon la technique

a) La technique de prototypage est bénéfique. Projets où l'interface homme-machine est complexe ou lorsque le client a une idée très vague de ce qu'il veut. Exemple : Une application mobile innovante grand public où l'expérience utilisateur doit être testée avant le développement complet.

b) L'adoption du modèle en cascade est bénéfique. Projets critiques ou très stables où les exigences sont parfaitement connues à l'avance et ne changeront pas, avec de fortes contraintes réglementaires. Exemple : Le développement d'un système de freinage ABS pour une voiture.

c) L'adoption du modèle incrémental est bénéfique. Projets volumineux où le client a besoin d'un retour sur investissement rapide avec un noyau dur. Exemple : Un logiciel de gestion d'entreprise (ERP) où l'on livre d'abord le module de comptabilité, puis le module de ressources humaines le mois suivant.

Question 3 - Attribution des modèles de cycle de vie

Note : Les attributions suivantes représentent les choix canoniques en génie logiciel selon les caractéristiques de chaque projet.

a) Développement d’un logiciel médical ; Modèle en V ou Cascade. Raison : Exigences de sécurité et de fiabilité critiques, nécessitant une documentation stricte, une traçabilité totale et des phases de tests rigoureuses.

b) Développement d’un site web pour l’organisation du croissant rouge ; Prototypage évolutif ou Agile. Raison : Les besoins peuvent évoluer rapidement en fonction des campagnes ou des urgences, et l'aspect visuel/communication est primordial.

c) Développement d’un logiciel à utilisation militaire ; Modèle en Spirale. Raison : Forte criticité et très hauts risques techniques et stratégiques justifiant une analyse des risques approfondie à chaque itération.

d) Développement d’un site web pour une agence de voyage (réservation en ligne) ; Modèle Incrémental. Raison : Possibilité de livrer le module de consultation de base d'abord, puis d'ajouter les réservations, puis les paiements en ligne par incréments.

e) Développement d’une application de gestion d’une bibliothèque universitaire ; Processus Unifié (PU) ou Incrémental. Raison : Système classique de gestion, orienté données et cas d'utilisation bien définis, pouvant être développé par sous-systèmes (emprunts, inventaire).

f) Développement d’un logiciel aéronautique pour la NASA ; Modèle en V ou Spirale. Raison : Tolérance aux pannes zéro. L'analyse des risques (Spirale) et la validation systématique de chaque spécification (En V) sont obligatoires.

g) Développement d’une application de gestion de stock importante ; Modèle Incrémental. Raison : Vaste système qui gagne à être déployé par parties (ex: entrepôt A, puis B, ou fonctionnalités de base puis avancées) pour ne pas perturber l'entreprise.

h) Développement d’un projet pour la gestion hôtelière ; Agile ou Incrémental. Raison : Besoin fonctionnel standardisé mais nécessitant des adaptations fréquentes selon les retours des réceptionnistes et gérants.

i) Développement d’un site web de vente de voitures en ligne. Agile (ex: Scrum). Raison : Marché très concurrentiel, nécessité de s'adapter rapidement aux concurrents et de sortir de nouvelles fonctionnalités web en continu (Time-to-market).

Question 4 - Choix de réponses et justifications

Un processus de développement :

• c) Peut-être itéré.
• d) Peut s’appuyer sur plusieurs modèles de processus.
• Justification : Les modèles rigoureux (a) ne sont pas systématiques, et aucun processus ne s'applique aveuglément à la lettre (b) (il faut l'adapter au contexte). Un processus hybride combinant plusieurs modèles est très courant, tout comme les itérations.

C’est le rôle d’un chef de projet :

• b) De vérifier le bon déroulement des tâches.
• c) D’organiser l’enchaînement des tâches.
• Justification : Le chef de projet gère la planification, les ressources, le suivi (b et c). Il ne programme généralement pas (a, rôle du développeur) et l'écriture de la spécification technique (d) est le rôle de l'analyste ou de l'architecte.

Le modèle en cascade de développement de logiciels est :

• a) Une approche raisonnable lorsque les exigences sont bien définies.
• Justification : En cascade, il est impossible de revenir facilement en arrière. Ce n'est donc viable que si les exigences sont figées, complètes et sans ambiguïté dès le départ. Ce n'est pas rapide (b), ce n'est pas exclusif aux grandes équipes (c), et ce n'est pas totalement démodé pour le monde de l'embarqué critique (d).

Le modèle incrémental de développement de logiciels est :

• b) Une bonne approche quand un noyau fonctionnel d'un produit est nécessaire rapidement.
• Justification : L'idée même## Exercice 1

Le texte source de cet exercice passe directement de la question 2 à la question 4. La question 3 est manquante dans le document original.

Comparaison 1 - Bien développer Versus développer le bon logiciel

• Bien développer (Vérification) : Cela signifie que le logiciel est construit selon les règles de l'art. Il respecte le cahier des charges, ne contient pas de bugs, et son architecture est robuste. L'objectif est de s'assurer que le produit est techniquement correct.
• Développer le bon logiciel (Validation) : Cela signifie que le logiciel répond véritablement aux besoins réels de l'utilisateur final et résout son problème métier. Un logiciel peut être "bien développé" (sans bugs) mais être le "mauvais logiciel" s'il ne sert à rien pour le client.

Comparaison 2 - Vérification Versus validation

• Vérification : Répond à la question "Sommes-nous en train de construire le produit correctement ?". C'est le processus qui évalue si un livrable d'une phase de développement satisfait aux conditions imposées au début de cette phase (ex: le code respecte la spécification).
• Validation : Répond à la question "Sommes-nous en train de construire le bon produit ?". C'est le processus d'évaluation du logiciel à la fin du développement pour s'assurer qu'il satisfait les attentes et les exigences du client.

Comparaison 4 - Cycle itératif Versus Cycle incrémental

• Cycle itératif : Le développement se fait par raffinements successifs. On développe le système entier ou une grande partie sous forme d'ébauche, puis on repasse dessus (itérations) pour améliorer la qualité, la précision ou les performances.
• Cycle incrémental : Le développement se fait par ajouts successifs de fonctionnalités complètes (incréments). On livre un premier module fonctionnel, puis un deuxième s'y ajoute, et ainsi de suite, jusqu'à ce que le logiciel soit complet.

Comparaison 5 - Développement classique Versus Développement agile

• Développement classique (ex: Cascade, Cycle en V) : Approche prédictive et séquentielle. Fortement dirigée par les documents, elle nécessite des spécifications complètes avant de commencer à coder. Le changement est difficile et coûteux une fois le projet lancé.
• Développement agile (ex: Scrum, XP) : Approche adaptative et itérative. Privilégie le code fonctionnel, la collaboration avec le client et l'adaptation rapide aux changements des besoins, même tardivement dans le développement.

Exercice 2

Question 1 - Vrai ou Faux

a) Le succès d’un projet tient essentiellement à la livraison d’un programme fonctionnel. Faux. Un programme fonctionnel ne suffit pas. Le projet doit également respecter les délais, le budget alloué, être maintenable, documenté, et surtout répondre aux besoins réels des utilisateurs.

b) Une fois le logiciel est implémenté et qu’il fonctionne, le travail de l’ingénieur est terminé. Faux. La phase de maintenance (correction de bugs, évolution, adaptation à de nouveaux environnements) représente souvent la majeure partie du cycle de vie et du coût d'un logiciel.

c) Tant qu’un logiciel ne fonctionne pas, il n’y a pas moyen d’en mesurer la qualité. Faux. La qualité peut être mesurée bien avant l'exécution du code : revues de spécifications, validation des modèles d'architecture, inspections de code, et vérification formelle.

d) Le logiciel est un produit qui peut être fabriqué en utilisant les mêmes technologies utilisées pour d'autres objets. Faux. Le logiciel est une entité logique et abstraite, non physique. Contrairement au matériel, il ne s'use pas avec le temps, et son développement relève de la conception intellectuelle plutôt que de la fabrication ou de l'assemblage en usine.

e) La plupart des projets de développement de logiciels sont initiés pour tenter de répondre à un besoin commercial. Vrai. Dans le milieu professionnel, les logiciels sont créés pour automatiser des tâches, gagner des parts de marché, réduire des coûts ou offrir un nouveau service, ce qui correspond à des objectifs commerciaux ou organisationnels.

Question 2 - Exemples de projets

a) La technique de prototypage est bénéfique : Lors de la création d'une nouvelle application mobile grand public innovante où l'ergonomie (Interface Utilisateur) est primordiale, mais où les attentes exactes des utilisateurs sont encore floues. Le prototype permet de valider le concept visuel avant le développement.

b) L’adoption du modèle en cascade est bénéfique : Pour le remplacement d'un logiciel de paie interne basé sur des lois fiscales strictes et immuables. Les règles métier sont parfaitement connues, documentées dès le départ, et ne changeront pas en cours de route.

c) L’adoption du modèle incrémental est bénéfique : Pour un portail universitaire en ligne. On peut livrer rapidement un premier incrément (le module d'inscription), puis un deuxième (la consultation des notes quelques mois plus tard), permettant à l'université d'utiliser le système partiellement pendant que le reste est développé.

Question 3 - Modèles de cycle de vie adéquats

Note : Pour certains projets, plusieurs réponses sont acceptables si elles sont bien argumentées. Voici les choix les plus classiques en génie logiciel.

• a) Développement d’un logiciel médical : Cycle en V (Criticité élevée, besoin d'une validation rigoureuse et de traçabilité).
• b) Développement d’un site web pour l’organisation du croissant rouge : Prototypage ou Agile (Besoin d'une mise en ligne rapide, exigences potentiellement changeantes, forte importance de l'interface).
• c) Développement d’un logiciel à utilisation militaire : Cycle en V ou Modèle en Spirale (Gestion des risques très critique, sécurité et vérification maximales).
• d) Développement d’un site web pour une agence de voyage : Modèle Incrémental (Lancement rapide d'un noyau fonctionnel pour la réservation de base, puis ajout de modules annexes comme les hôtels ou voitures).
• e) Développement d’une application de gestion d’une bibliothèque universitaire : Processus Unifié (PU) ou Cascade (Domaine très classique, cas d'utilisation bien définis, modélisation objet adaptée).
• f) Développement d’un logiciel aéronautique pour la NASA : Cycle en V (Système critique, tests exhaustifs requis à chaque niveau de conception).
• g) Développement d’une application de gestion de stock importante : Processus Unifié (PU) ou Incrémental (Projet volumineux nécessitant une forte modélisation UML et une intégration progressive).
• h) Développement d’un projet pour la gestion hôtelière : Cascade (Domaine métier très mature et standardisé, besoins facilement identifiables dès le début).
• i) Développement d’un site web de vente de voitures en ligne : Agile / Scrum (Marché très concurrentiel, nécessité de s'adapter rapidement aux offres et aux comportements des clients en ligne).

Question 4 - Choix de réponses avec justification

Un processus de développement :

• c) Peut-être itéré.
• d) Peut s’appuyer sur plusieurs modèles de processus.
• Justification : Les processus modernes (comme UP ou Agile) sont fondés sur l'itération. De plus, il est très courant d'hybrider les modèles pour un grand projet (ex: approche en cascade pour la définition de l'architecture matérielle, et Scrum pour le développement des modules logiciels). Les réponses a) et b) sont fausses car un processus peut s'adapter aux petits projets et ne doit jamais être appliqué aveuglément "à la lettre" au détriment du bon sens.

C’est le rôle d’un chef de projet :

• b) De vérifier le bon déroulement des tâches.
• c) D’organiser l’enchaînement des tâches.
• Justification : Le chef de projet gère les ressources, le planning et les risques. La programmation (a) relève de l'équipe de développement, et l'écriture des spécifications (d) est généralement le rôle de l'analyste fonctionnel ou de l'ingénieur des exigences.

Le modèle en cascade de développement de logiciels est :

• a) Une approche raisonnable lorsque les exigences sont bien définies.
• Justification : La cascade impose qu'une phase soit totalement terminée avant de passer à la suivante. Elle ne gère pas bien le changement. Elle est donc idéale si et seulement si les exigences sont figées et parfaitement comprises dès le début.

Le modèle incrémental de développement de logiciels est :

• b) Une bonne approche quand un noyau fonctionnel d'un produit est nécessaire rapidement.
• Justification : L'essence même du modèle incrémental est de livrer les fonctionnalités par lots ("incréments"). Livrer les fonctionnalités les plus importantes en premier (le noyau) permet au client de commencer à utiliser et rentabiliser le logiciel très tôt.

Le modèle de prototypage du développement logiciel est :

• h) Une approche utile quand un client ne peut pas définir des exigences clairement. (Note : Les options de la source sont e, f, g, h).
• Justification : Le prototype sert de support de communication. En montrant une maquette concrète au client, il réagit et précise ses besoins, ce qui lève l'ambiguïté des exigences initiales.

Exercice 3

• Quel(s) cycle(s) de vie est (sont) dirigé(s) par les documents ? Le Modèle en Cascade et le Cycle en V. Chaque phase se termine par la production d'un document validé (cahier des charges, spécifications, dossier d'architecture) qui sert de point d'entrée strict pour la phase suivante.
• Quel(s) cycle(s) de vie est (sont) dirigé(s) par les jeux de tests ? Le Cycle en V (car la partie gauche de conception prépare directement les plans de tests de la partie droite), l'eXtreme Programming (XP) et plus généralement les méthodes basées sur le TDD (Test-Driven Development), où l'on écrit le test avant même d'écrire le code.
• Quel(s) cycle(s) de vie est (sont) dirigé(s) par le code ? Les méthodes Agiles (notamment Scrum et XP) et le Prototypage évolutif. La mesure principale d'avancement est le logiciel fonctionnel, et non la documentation.
• Quel(s) cycle(s) de vie est (sont) dirigé(s) par les risques ? Le Modèle en Spirale (de Boehm). Chaque boucle de la spirale inclut une phase explicite d'analyse et de résolution des risques avant de s'engager dans le développement de l'itération.

Exercice 4

Question 1 - Tableau comparatif des cycles de vie

Modèle	Linéaire	Itératif	Incrémental	Agile	Orienté Objet	Utilise le Prototypage
En V	Oui	Non	Non	Non	Non	Non
Prototypage évolutif	Non	Oui	Oui	Non (mais flexible)	Non	Oui
Scrum	Non	Oui	Oui	Oui	Non	Oui (souvent)
PU (Processus Unifié)	Non	Oui	Oui	Non (classique)	Oui	Oui
Orienté réutilisation	Oui / Non	Non	Non	Non	Oui (souvent)	Non

Justifications :

• Cycle en V : Il est fondamentalement linéaire (descendant puis ascendant). Il ne boucle pas (non itératif), livre en une seule fois (non incrémental), est rigide (non agile). Il ne présume d'aucun paradigme de code (pas forcément Objet) et ne repose pas sur des prototypes.
• Prototypage évolutif : Repose sur des boucles (donc itératif) pour raffiner le prototype qui devient le produit final en ajoutant des fonctions (donc incrémental et utilise le prototypage).
• Scrum : Le standard des méthodes Agiles. Fonctionne par sprints courts (itératif) à la fin desquels on livre une nouvelle partie du produit (incrémental). Un MVP (Minimum Viable Product) joue souvent le rôle de prototype. Ne force pas l'usage de l'Orienté Objet.
• PU : Cadre lourd mais qui fonctionne par itérations et incréments (Itératif et Incrémental). Il est intimement lié à UML et à la modélisation Orientée Objet. Il utilise le prototypage lors des phases de création (Inception/Elaboration) pour lever les risques.
• Orienté réutilisation (Composants) : Basé sur l'assemblage de composants existants. Souvent lié aux composants Objets. Son flux dépend du projet, mais il est rarement itératif/incrémental au sens classique, car on intègre des blocs déjà finis.

Exercice 5

Note : La numérotation des options respecte strictement les choix (parfois discontinus) proposés dans le document source.

1. Contraintes temporelles fortes et fonctionnalités partiellement essentielles.

• Bonne réponse : d) Incrémental
• Justification : Le modèle incrémental permet de développer et de livrer immédiatement les fonctionnalités jugées "essentielles" pour respecter les contraintes de temps fortes du client. Les fonctions secondaires seront livrées lors d'incréments ultérieurs.

2. Besoins partiellement clairs et modélisation UML exigée.

• Bonne réponse : d) PU (Processus Unifié)
• Justification : PU est le processus de développement nativement conçu pour s'appuyer sur le langage UML (il est dirigé par les cas d'utilisation). Son caractère itératif permet de gérer l'aspect "partiellement clair" des besoins en les affinant au fil des itérations.

3. Ambigüité des besoins et modifications acceptées à n'importe quel moment.

• Bonne réponse : d) SCRUM
• Justification : L'un des principes fondateurs de l'agilité (et donc de Scrum) est d'accueillir positivement les changements de besoins, même tardifs. L'ambiguïté est gérée par des cycles courts (sprints) et une implication continue du client.

4. Enseignement à distance, cahier des charges précis, modélisation UML.

• Bonne réponse : d) PU (Processus Unifié)
• Justification : L'exigence stricte d'utiliser UML pointe directement vers le Processus Unifié. Bien qu'un cahier des charges soit "précis" (ce qui pourrait suggérer Cascade ou V), PU reste parfaitement applicable pour un projet bien cadré tout en fournissant le cadre architectural lié à UML.

5. Petit logiciel, équipe experte, pas de risque, cahier des charges précis, technologie objet.

• Bonne réponse : a) Cycle en V
• Justification : Quand les exigences sont parfaitement définies (cahier des charges précis), l'équipe formée et qu'il n'y a aucun risque technique, une approche prédictive et séquentielle comme le Cycle en V est la plus économique et directe. (Le modèle en cascade aurait également été correct, mais n'est pas proposé).

6. Informatisation d'une méthode de travail variable avec critères à spécifier.

• Bonne réponse : b) Prototypage évolutif
• Justification : Le texte mentionne que les "méthodes de travail varient d'une personne à l'autre" et que les "critères restent à spécifier". Il n'y a donc pas de consensus initial. Un prototype évolutif permettra de montrer une interface aux différents ingénieurs pour unifier leurs méthodes et découvrir ensemble les critères de recherche pertinents, avant de consolider le système final.

Exercice 6

Question 1 - Cycles de vie pour la première version (Démonstration)

Pour développer rapidement un système de contrôle énergétique afin d'acquérir des clients sur le marché, le but est de faire une "vitrine". Cycles candidats :

• Le Prototypage (jetable ou évolutif) : Idéal pour construire une version de démonstration centrée sur l'interface et les fonctionnalités clés afin d'attirer les clients. Le retour des clients permettra de cerner les besoins réels du marché.
• Scrum (Agile) : Permet de créer très rapidement un MVP (Minimum Viable Product - le cœur fonctionnel) pour aller vite sur le marché tout en s'adaptant aux retours des premiers prospects commerciaux.

Question 2 - Cycles de vie pour les versions sur mesure

Une fois le marché acquis, il s'agit de livrer des extensions spécifiques pour chaque client, tout en capitalisant sur un cœur commun (la démo). Cycles proposés :

1. Modèle Orienté Réutilisation (Développement à Base de Composants) : Le chef de projet a tout intérêt à transformer le code de la démonstration en composants logiciels standards (le cœur du système). Pour chaque nouveau client, l'équipe réutilise ces composants centraux et développe uniquement les composants spécifiques manquants.
2. Modèle Incrémental : La version de démonstration constitue le premier "incrément" (le noyau de base). Pour chaque demande client, l'équipe ajoute de nouveaux incréments (modules sur mesure) au-dessus de cette base sans avoir à redévelopper le noyau.

Méthode

Pour réussir ce type d'épreuve sur les processus logiciels, la clé est l'identification des mots-clés dans les énoncés de scénarios (Exercices 5 et 6). Les concepteurs de sujets utilisent un vocabulaire spécifique pour vous guider vers un modèle particulier :

• "Cahier des charges précis", "Exigences figées", "Pas de risques" pointent vers les approches prédictives (Cascade, Cycle en V).
• "Flou", "Ambigüité", "Interface", "Besoins mal définis" pointent vers le Prototypage.
• "Noyau fonctionnel rapide", "Budget limité au départ", "Fonctions essentielles d'abord" pointent vers le modèle Incrémental.
• "Modifications tardives", "Changement", "Client impliqué" pointent vers les méthodes Agiles (Scrum, XP).
• "Risques majeurs", "Critique" pointent vers le modèle Spirale ou le Cycle en V (si spécifications strictes).
• "UML" ou "Orienté Objet avec itérations" pointe très souvent vers le Processus Unifié (PU). Lisez attentivement chaque mot du contexte et assurez-vous de toujours justifier votre choix en croisant les caractéristiques du modèle avec les contraintes du client exprimées dans le texte.