TD1 : Processus Logiciels

Exercice 1 - Comparaison de termes

Note : La question 3 est absente du document source. L'énoncé passe directement de la question 2 à la question 4. Les réponses suivent la numérotation disponible.

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

• Bien développer : Fait référence à la qualité technique du processus de construction (respect des normes de codage, architecture robuste, absence de bugs, maintenabilité). C'est la perspective de l'ingénieur qui cherche à construire le système de manière optimale.
• 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 marché. Un logiciel peut être parfaitement codé ("bien développé") mais inutile s'il ne répond pas au bon problème.

Question 2 - Vérification Versus validation

• Vérification : Répond à la question "Construisons-nous le produit correctement ?". Il s'agit de s'assurer que le logiciel est conforme à ses spécifications techniques et conceptuelles (ex: revues de code, tests unitaires).
• Validation : Répond à la question "Construisons-nous le bon produit ?". Il s'agit de s'assurer que le logiciel final satisfait les attentes et les besoins réels du client dans son environnement d'exploitation (ex: tests d'acceptation par l'utilisateur).

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

• Cycle itératif : Consiste à développer le système par approximations successives. On construit une version globale mais simplifiée, puis on l'affine et on l'améliore au fil des itérations jusqu'à obtenir la qualité souhaitée.
• Cycle incrémental : Consiste à développer le système par morceaux complets (incréments). Chaque incrément ajoute de nouvelles fonctionnalités finies et utilisables au produit. Les deux cycles sont souvent combinés (itératif et incrémental).

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

• Développement classique (prédictif) : Approche séquentielle ou guidée par les plans (ex: Cascade, Cycle en V). Tout est spécifié en amont, la documentation est très présente, et le processus est rigide face aux changements de besoins en cours de route.
• Développement agile (adaptatif) : Approche itérative et incrémentale (ex: Scrum, XP) qui valorise la collaboration avec le client, l'adaptation rapide aux changements et la livraison continue de logiciels fonctionnels plutôt que la documentation exhaustive.

Exercice 2 - Concepts fondamentaux

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. Le succès implique aussi le respect des délais, du budget, des normes de qualité (maintenabilité, sécurité), et surtout la satisfaction des besoins réels des utilisateurs (validation).

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 et d'évolution représente souvent la majeure partie du cycle de vie et du coût d'un logiciel. Il faudra corriger des bugs futurs, adapter le logiciel à de nouveaux environnements, et ajouter de nouvelles fonctionnalités.

c) Tant qu'un logiciel ne fonctionne pas, il n'y a pas moyen d'en mesurer la qualité.

• Faux. La qualité peut (et doit) être mesurée bien avant l'exécution du code à travers des revues de spécifications, l'inspection de modèles (comme UML), des audits d'architecture, et l'analyse statique du code.

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 non physique. Contrairement au matériel, il ne s'use pas avec le temps, mais il se détériore à cause des modifications. Son processus est davantage de l'ingénierie et de la conception continue que de la "fabrication" ou de la "production à la chaîne".

e) La plupart des projets de développement de logiciels sont initiés pour tenter de répondre à un besoin commercial.

• Vrai. Dans un contexte professionnel, les logiciels sont créés pour automatiser un processus métier, gagner des parts de marché, réduire des coûts ou offrir un nouveau service aux clients.

Question 2 - Exemples de projets de développement

a) La technique de prototypage est bénéfique :

• Exemple : Le développement d'une nouvelle application mobile grand public innovante, ou d'une interface homme-machine (IHM) complexe, où les utilisateurs ne savent pas exactement ce qu'ils veulent avant d'avoir vu un écran interactif.

b) L'adoption du modèle en cascade est bénéfique :

• Exemple : Le développement d'un logiciel pour un système critique (ex: contrôle de vol d'un avion, système de radiothérapie) où les spécifications sont parfaitement définies dès le départ et où le coût d'une erreur nécessitant un retour en arrière est inacceptable.

c) L'adoption du modèle incrémental est bénéfique :

• Exemple : Un système de gestion universitaire (ERP) où l'on a urgemment besoin d'un noyau fonctionnel (ex: l'inscription des étudiants pour la rentrée). Les autres fonctionnalités (gestion de la bibliothèque, notes) seront développées et ajoutées lors d'incréments ultérieurs.

Question 3 - Choix multiples 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) sont fondamentalement itératifs. De plus, il est très courant de créer des modèles hybrides (ex: un cycle en V au niveau macro du projet, et du Scrum au niveau micro pour les phases de réalisation).

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 s'occupe de la planification, de l'allocation des ressources, de l'estimation et du suivi (contrôle). Programmer (a) est le rôle du développeur, et écrire les spécifications (d) est généralement le rôle de l'analyste fonctionnel ou de l'ingénieur exigences.

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

• a) Une approche raisonnable lorsque les exigences sont bien définies.
• Justification : Le modèle en cascade suppose qu'il n'y a pas de retours en arrière possibles (ou qu'ils sont très coûteux). Il exige donc que la phase d'analyse des besoins produise des spécifications exhaustives et figées avant de commencer la conception.

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 : C'est le principe même de l'incrémental : livrer rapidement une première version opérationnelle contenant les fonctionnalités primordiales (le noyau), afin que le client puisse commencer à utiliser le système sans attendre la fin du projet.

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.
• Justification : Le prototype sert de support de communication. Face à un client qui a des besoins flous ou ambigus, lui montrer une maquette permet de faire émerger ses véritables besoins par ses réactions au prototype.

Exercice 3 - Direction des cycles de vie

• Quel(s) cycle(s) de vie est (sont) dirigé(s) par les documents ?
  • Réponse : Le modèle en cascade et le cycle en V.
  • Justification : Ces modèles prédictifs s'appuient sur la validation exhaustive de documents (cahier des charges, spécifications, architecture) pour valider le passage d'une phase à la suivante (jalons documentaires).
• Quel(s) cycle(s) de vie est (sont) dirigé(s) par les jeux de tests ?
  • Réponse : Le cycle en V et les approches agiles comme XP (Extreme Programming / TDD).
  • Justification : Dans le cycle en V, la phase descendante sert à préparer les plans de tests de la phase montante. Dans l'agilité (TDD), l'écriture du test précède et guide l'écriture du code.
• Quel(s) cycle(s) de vie est (sont) dirigé(s) par le code ?
  • Réponse : Les méthodes Agiles (Scrum, XP).
  • Justification : Le manifeste Agile privilégie "un logiciel opérationnel plutôt qu'une documentation exhaustive". La mesure principale d'avancement est le code testé et fonctionnel.
• Quel(s) cycle(s) de vie est (sont) dirigé(s) par les risques ?
  • Réponse : Le modèle en spirale (de Boehm).
  • Justification : Chaque itération (boucle) de la spirale inclut obligatoirement une étape formelle d'identification, d'évaluation et de résolution des risques avant de poursuivre le développement.

Exercice 4 - Comparaison des cycles de vie

Voici le tableau complété, suivi des justifications.

Cycle de vie	Linéaire	Itératif	Incrémental	Agile	Orienté Objet	Utilise le Prototypage
En V	X
Prototypage évolutif		X	X			X
Scrum		X	X	X
PU		X	X		X	X
Orienté réutilisation		X	X

• En V : C'est un modèle linéaire (avec une correspondance de vérification entre les phases de conception et de test). Il n'est pas nativement itératif ou incrémental.
• Prototypage évolutif : Repose fondamentalement sur le prototypage. Il est itératif (on affine le prototype) et incrémental (le prototype devient progressivement le système final).
• Scrum : Le fer de lance des méthodes agiles. Le développement se fait sur des itérations courtes (Sprints) qui produisent des incréments de produit fonctionnels.
• PU (Processus Unifié) : Il est guidé par les cas d'utilisation, centré sur l'architecture (souvent par des prototypes jetables au début), itératif et incrémental. Il est intimement lié à la modélisation Orientée Objet (avec UML).
• Orienté réutilisation (CBSE) : Basé sur l'intégration de composants (sur étagère). Il nécessite souvent de multiples itérations pour adapter les spécifications aux composants trouvés sur le marché et intégrer ces composants incrémentalement.

Exercice 5 - Choix de modèles selon le contexte

Note : Les listes de choix reproduisent fidèlement les lettres de la source, incluant les sauts de lettres (ex: passage direct de b à d).

1. Système avec fonctions essentielles, contraintes temporelles fortes :

• Choix : d) Incrémental
• Justification : L'approche incrémentale permet de se concentrer sur la livraison rapide d'un noyau contenant uniquement les fonctions "essentielles". Cela respecte les contraintes temporelles pour la première mise en service, le reste étant ajouté plus tard.

2. Fonctions partiellement claires, utilisation d'UML imposée :

• Choix : d) PU (Processus Unifié)
• Justification : L'ambiguïté partielle exclut les modèles strictement linéaires. PU gère très bien l'évolution des exigences par son aspect itératif. De plus, PU a été créé en conjonction avec UML, c'est donc le standard de facto pour un cycle de vie piloté par l'Orienté Objet.

3. Besoins ambigus, modifications acceptées à n'importe quel moment :

• Choix : d) SCRUM
• Justification : Accueillir le changement (même tardif) est l'un des principes fondamentaux de l'agilité. Scrum est le seul de la liste conçu spécifiquement pour gérer un scope très variable.

4. Cahier des charges précis, enseignement à distance, modélisation UML :

• Choix : d) PU (ou b) Cycle en V)
• Justification : Les deux réponses peuvent être soutenues. "Cahier des charges précis" oriente classiquement vers le Cycle en V (b). Cependant, l'imposition de la norme UML pointe très fortement vers le Processus Unifié (PU) (d) dans un contexte universitaire de génie logiciel, PU incluant des phases de spécification strictes au début. Si une seule option doit primer académiquement pour l'association systématique à UML, c'est PU.

5. Petit logiciel maîtrisé, aucun risque, cahier des charges précis :

• (Note: options proposées: a, c, d)
• Choix : a) Cycle en V
• Justification : Quand la technologie est connue, qu'il n'y a aucun risque technique, et que le périmètre est précis et petit, un cycle de développement linéaire et prédictif (comme le cycle en V ou Cascade) est le plus efficace et le moins coûteux en gestion.

6. Informatiser un traitement manuel existant, critères vagues basés sur l'expérience, conservation de l'historique :

• (Note: options proposées: a, b, d)
• Choix : b) Prototypage évolutif
• Justification : Puisque le processus actuel repose sur la mémoire humaine et que les critères "restent à spécifier", il est impossible de rédiger un cahier des charges immédiat. Créer un prototype permettra aux ingénieurs de tester l'outil, de formaliser leurs méthodes de travail et de clarifier les critères de recherche de manière empirique.

Exercice 6 - Étude de cas : Système de contrôle énergétique

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

Pour cette première version destinée à acquérir des clients (démonstrateur pour le marché), deux approches se démarquent :

• Le Prototypage (jetable ou évolutif) : Idéal pour construire rapidement une façade ou un système limité mais visuellement convaincant. L'objectif principal est la démonstration et le recueil de feedback.
• Les méthodes Agiles (ex: Scrum) : Permettent un "Time-to-Market" très court en livrant un Produit Minimum Viable (MVP) rapidement pour attaquer le marché, tout en s'assurant que ce qui est montré fonctionne réellement.

Question 2 - Cycles de vie pour les versions sur mesure

Pour produire des extensions sur mesure tout en profitant du travail déjà accompli, le chef de projet a intérêt à adopter :

• Le Prototypage évolutif : Si la version de démonstration a été conçue proprement, elle ne sera pas jetée mais servira de base technique (le noyau). Chaque demande client fera évoluer cette base par itérations successives pour devenir la solution sur mesure de ce client.
• Le développement orienté réutilisation (ou Ligne de Produits Logiciels) : Pour gérer efficacement les multiples clients, l'éditeur doit isoler les "parties communes" (le cœur du contrôle énergétique) sous forme de composants réutilisables. Les parties spécifiques seront développées en intégrant ce socle commun, limitant ainsi le temps et les coûts de développement pour chaque nouveau client.

Méthode

Face à un examen sur les processus logiciels, la clé est l'identification des mots-clés discriminants dans l'énoncé de chaque scénario :

1. Stabilité des exigences : Si l'énoncé parle de "cahier des charges précis", "bien défini", orientez-vous vers les modèles prédictifs (Cascade, Cycle en V). Si l'énoncé mentionne "ambigu", "besoins évolutifs" ou "flou", excluez les modèles linéaires et choisissez l'Agile, le Prototypage ou la Spirale.
2. Gestion du temps et livraison : Si le client exige de voir un résultat rapidement ou un "noyau fonctionnel", l'approche Incrémentale ou Agile (Scrum) est la solution.
3. Taille et Risques : Les très gros projets avec des risques vitaux ou financiers énormes appellent le modèle en Spirale ou le Cycle en V rigoureux. Les petits projets maîtrisés sans risque appellent la Cascade ou le Cycle en V.
4. Vocabulaire technique : La mention d'UML ou d'Orienté Objet pointe presque toujours vers le Processus Unifié (PU ou UP), ou vers une architecture itérative.
5. Ne forcez pas les définitions : Utilisez toujours les caractéristiques exactes du cours. Ne confondez pas incrémental (ajout par blocs fonctionnels finis) et itératif (raffinement global successif).