Modèles de cycles de vie logiciels et choix stratégiques pour UNIVERSITE DE LA MANOUBA

Exercice 1 - Cycle de vie du logiciel

Question 1 - Adoption d'un modèle linéaire vs itératif

a) Modèle linéaire (ex. Cascade) : L'adoption d'un modèle linéaire est favorable lorsque les besoins et les spécifications du système sont parfaitement connus, stables et clairement définis dès le début du projet. Ce modèle convient bien aux projets de petite ou moyenne envergure, ou aux projets présentant des contraintes réglementaires fortes nécessitant une documentation exhaustive à chaque étape avant de passer à la suivante.

b) Modèle itératif : Un modèle itératif est favorable lorsque les besoins initiaux sont flous, complexes ou susceptibles de changer en cours de route. Il permet de livrer rapidement des versions partielles (mais fonctionnelles) du logiciel, ce qui favorise l'implication continue du client. C'est idéal pour réduire les risques technologiques et s'adapter aux évolutions du marché.

Question 2 - Avantages des différents modèles

• Modèle en cascade : Sa simplicité et sa structure rigoureuse. Les livrables, les jalons et les rôles sont clairement définis pour chaque phase, ce qui facilite grandement la gestion de projet et la planification financière.
• Modèle en V : Il intègre les activités de test et de validation dès les phases de conception. L'avantage principal est la garantie d'une haute qualité et d'une meilleure anticipation des défauts, car chaque phase de développement possède une phase de test correspondante.
• Modèle incrémental : Il permet d'obtenir un retour sur investissement rapide en livrant rapidement les fonctionnalités les plus importantes (les incréments). Le client peut commencer à utiliser le cœur du système sans attendre la fin complète du projet.
• Modèle en spiral : Son avantage majeur est l'intégration systématique de l'analyse et de la gestion des risques à chaque cycle. C'est le modèle le plus sûr pour les projets critiques, complexes et très coûteux.
• Modèle de programmation exploratoire : Il offre une flexibilité maximale. L'avantage est la capacité à explorer des solutions pour des problèmes dont on ne connait ni les spécifications ni la faisabilité technique au départ (souvent utilisé en recherche et développement ou pour l'intelligence artificielle).

Question 3 - Comparaison des types de prototypage

Voici le tableau complété en utilisant les termes demandés (élevé, moyen, nul).

Critère	Prototypage jetable	Prototypage évolutif
Exhaustivité par rapport au système final	nul	élevé
Effort de programmation demandé	moyen	élevé
Apport pour l’analyse des besoins détaillés	élevé	moyen
Apport pour l’analyse des besoins généraux	moyen	élevé
Rapidité et coût de réalisation (dépense/temps investi)	moyen	élevé
Niveau de réutilisation pour le développement	nul	élevé

Note sur la correction : Le prototypage jetable a pour vocation d'être construit rapidement avec un effort modéré (moyen) pour valider des besoins spécifiques (interface, ergonomie), puis il est abandonné (réutilisation nulle). Le prototypage évolutif devient le système final, ce qui exige un effort, un coût et une exhaustivité élevés.

Question 4 - Exemples de projets selon le modèle

a) Le prototypage est bénéfique : Développement d'une nouvelle application mobile grand public innovante ou d'un jeu vidéo, où l'interface utilisateur (UI) et l'expérience utilisateur (UX) sont primordiales et doivent être testées avec les utilisateurs avant le développement final. b) L’adoption du modèle en cascade est bénéfique : Développement d'un logiciel de calcul d'impôts ou d'un système de paie. Les règles de gestion (lois, formules mathématiques) sont strictes, connues à l'avance, et ne changeront pas pendant la durée du développement. c) L’adoption du modèle en spiral est bénéfique : Un système de contrôle aérien ou un logiciel pour l'aérospatiale. Ce sont des systèmes critiques où la moindre erreur a des conséquences graves ; l'analyse systématique des risques à chaque boucle est donc indispensable.

Exercice 2 - Choix de modèles et justifications

Question 1 - Choix du développement en Cascade

Bonne réponse : a) Projet 1 Justification : Le développement d'un compilateur pour un langage déjà connu (comme le C ou Pascal) repose sur des spécifications fixes et standardisées. Les besoins ne vont pas évoluer en cours de projet. Le modèle en cascade est parfaitement adapté à ce type de développement prédictif. Le Projet 2 (cabinet médical) implique des utilisateurs humains et des processus administratifs qui peuvent nécessiter des ajustements, ce qui rend la cascade trop rigide.

Question 2 - Choix du modèle pour un système complexe sous contraintes

Bonne réponse : d) incrémental Justification : Le modèle incrémental permet de prioriser et de développer d'abord la partie vue comme "essentielle" par le client. Cela permet de livrer rapidement un premier incrément fonctionnel pour respecter les fortes contraintes temporelles. Comme l'équipe est réduite, elle ne peut pas utiliser la méthode RAD (qui nécessite de multiples équipes travaillant en parallèle), mais elle peut se concentrer sur la livraison d'un incrément à la fois.

Question 3 - Livrable des modèles itératifs

Bonne réponse : b) Faux Justification : Bien que les modèles itératifs (et surtout agiles) privilégient le logiciel fonctionnel, l'exécutable n'est pas le seul livrable. Chaque itération peut et doit également inclure des tests automatisés, du code source commenté, des mises à jour des modèles architecturaux et la documentation minimale nécessaire à la maintenance.

Exercice 3 - Stratégie d'acquisition et de développement (Make or Buy)

Discussion des deux alternatives

Alternative 1 : Acheter un SGBD et développer son propre système en interne (Make)

• Avantages : Le système sera sur-mesure et s'adaptera parfaitement aux processus spécifiques de la banque. La banque reste propriétaire du code et indépendante vis-à-vis d'un éditeur de logiciel externe.
• Inconvénients : Temps de développement long, coûts initiaux élevés, et risques liés au projet (dépassement de budget, bugs). L'équipe interne doit assurer toute la maintenance.

Alternative 2 : Acheter un système comparable à une autre banque et le modifier (Buy & Customize)

• Avantages : Gain de temps considérable (le cœur du système existe déjà) et réduction des risques de conception puisque le système a déjà fait ses preuves dans une autre banque.
• Inconvénients : Le système de l'autre banque peut imposer ses propres processus métier, obligeant la banque acheteuse à modifier son organisation. De plus, modifier le code d'un système tiers complexe (surtout s'il est mal documenté) peut s'avérer extrêmement coûteux.

Technique de décision

Pour décider quelle approche retenir, la technique la plus appropriée est une Analyse Coûts-Bénéfices (Cost-Benefit Analysis) couplée à une Matrice de décision "Faire ou Acheter" (Make-or-Buy decision). Il s'agit d'estimer, pour chaque alternative, le Coût Total de Possession (TCO - Total Cost of Ownership) sur plusieurs années, en incluant les coûts d'acquisition, de développement, de déploiement, de maintenance et d'adaptation au changement, tout en évaluant les risques associés.

Exercice 4 - Étude quantitative des alternatives de la société COMPTA

Données du problème

• Budget alloué : 70 000 UM
• Durée maximale : 120 jours
• Exigence clé : Fiabilité et maintenabilité élevées.

Analyse de l'Alternative 1 : Logiciel commercial + Ingénieur

• Coût d'acquisition du CRM : 50 000 UM
• Effort de déploiement/personnalisation par un ingénieur : 35 J/H
• Coût de l'ingénieur : 35 jours × 600 UM = 21 000 UM
• Coût total : 50 000 + 21 000 = 71 000 UM
• Durée estimée : 35 jours.
• Bilan : Cette option doit être rejetée. Bien que la durée soit respectée (35 jours ≤ 120 jours), le coût total de 71 000 UM dépasse le budget strict de 70 000 UM.

Analyse de l'Alternative 2 : Logiciel commercial + Consultant externe

• Coût d'acquisition du CRM : 50 000 UM
• Effort de déploiement/personnalisation par un consultant : 20 J/H
• Coût du consultant : 20 jours × 1000 UM = 20 000 UM
• Coût total : 50 000 + 20 000 = 70 000 UM
• Durée estimée : 20 jours.
• Bilan : Cette option est valide. Le coût correspond exactement au budget maximum (70 000 UM). La durée de 20 jours est excellente (largement inférieure à 120 jours). De plus, l'utilisation d'un logiciel commercial éprouvé déployé par un expert garantit le niveau de fiabilité et de maintenabilité "élevé" exigé par COMPTA.

Analyse de l'Alternative 3 : Développement interne autour d'un SGBD

• Effort de développement (V1) : 60 J/H
• Effort de déploiement et interfaçage (par ingénieur) : 35 J/H
• Effort total : 60 + 35 = 95 J/H
• Coût total : 95 jours × 600 UM = 57 000 UM
• Durée estimée : 95 jours (en supposant un seul ingénieur affecté séquentiellement ; moins si l'équipe est plus grande).
• Bilan : Cette option est valide. Le coût (57 000 UM) est très avantageux et bien inférieur au budget. La durée (95 jours) respecte le délai de 120 jours.

Conclusion et choix stratégique

Bien que l'Alternative 3 soit la moins chère (57 000 UM), développer un CRM "from scratch" introduit des risques techniques importants et produit une V1 dont la fiabilité est incertaine au moment du déploiement. L'Alternative 2 (Achat + Consultant) est le choix le plus stratégique. Elle respecte parfaitement le budget et offre le délai de mise en production le plus court (20 jours). L'acquisition d'un progiciel mature installé par un consultant expérimenté est la meilleure garantie pour répondre à l'exigence stricte d'une fiabilité et maintenabilité élevées.

Méthode

Pour réussir ce type d'épreuve (Génie Logiciel orienté gestion de projet) :

1. Apprenez les caractéristiques fondamentales des cycles de vie : Ne mémorisez pas seulement les schémas, mais comprenez les critères de sélection (risques, taille de l'équipe, clarté des besoins, délais). Chaque modèle répond à une faiblesse du précédent (la cascade est rigide, on crée le modèle en V pour la qualité, on crée l'itératif pour la flexibilité, le spiral pour le risque).
2. Justifiez systématiquement : Dans les QCM comme l'Exercice 2, la note provient de la justification. Liez toujours votre argument à un mot-clé de l'énoncé (ex: "équipe réduite" élimine le RAD ; "besoins connus" valide la cascade).
3. Structurer les problèmes d'estimation (Exercice 4) : Séparez l'analyse temporelle et l'analyse budgétaire. Posez chaque calcul clairement (Acquisition + (Taux journalier × Effort en jours) = Coût total). N'oubliez pas d'évaluer les résultats par rapport aux trois contraintes classiques de la gestion de projet : Coût, Délai, Qualité/Périmètre.
4. Attention à la lecture des énoncés chiffrés : Dans l'exercice 4, la donnée "20 J/H pour un consultant et 35 J/H pour un ingénieur" ne veut pas dire qu'il faut additionner les deux pour un déploiement, mais qu'il s'agit de deux rythmes de travail exclusifs selon la ressource choisie. Lisez prudemment les hypothèses.