Exercice 1 :
1) Les qualités manquantes dans ce logiciel sont :
- Complétude des Fonctionnalités : Le logiciel ne propose pas toutes les fonctionnalités attendues, ce qui signifie qu'il ne répond pas entièrement aux besoins des utilisateurs.
- Facilité d'Utilisation : L'apprentissage de l'utilisation du logiciel est fastidieux, indiquant qu'il manque une interface conviviale et intuitive.
- Fiabilité : Les résultats du logiciel sont parfois incorrects, ce qui montre un manque de fiabilité et de précision.
- Efficacité : Le logiciel consomme trop de CPU pour des tâches simples, ce qui suggère un manque d'optimisation des performances.
2) Le développement incrémental est efficace pour les systèmes logiciels de commerce car il permet d'ajouter de nouvelles fonctionnalités rapidement en réaction aux besoins changeants du marché. Cependant, il peut être moins approprié pour les systèmes de temps réel en raison de la nécessité de respecter des délais stricts et d'assurer une stabilité constante.
Mieux comprendre :
Le développement incrémental est une approche efficace pour le développement de systèmes logiciels de commerce, tandis qu'il peut être moins approprié pour l'ingénierie des systèmes de temps réel, pour les raisons suivantes :
Pourquoi le développement incrémental est efficace pour les systèmes de commerce :
- Évolution des besoins : Dans le commerce en ligne, les besoins des clients et les tendances du marché évoluent rapidement. Le développement incrémental permet d'ajouter de nouvelles fonctionnalités en réaction aux besoins changeants.
- Livraisons rapides : Les cycles courts de développement permettent de livrer rapidement des fonctionnalités essentielles, améliorant la satisfaction des clients et la compétitivité.
- Tests continus : L'approche incrémentale favorise les tests continus, assurant la qualité du logiciel tout au long du processus.
Pourquoi le développement incrémental peut être moins approprié pour les systèmes de temps réel :
- Exigences strictes en temps réel : Les systèmes de temps réel ont souvent des contraintes strictes en matière de délais et de réactivité. Le développement incrémental peut introduire de l'incertitude quant aux performances en temps réel.
- Stabilité nécessaire : Les systèmes de temps réel doivent fonctionner de manière stable et prévisible. Les itérations fréquentes du développement incrémental peuvent augmenter le risque de bugs et d'instabilité.
3) Ceci est un système où les besoins vont changer et il y aura des composants d'interface utilisateur (UI or GUI) étendus. Le développement incrémental avec, peut-être, certain prototypage de l'interface utilisateur (UI) est le modèle le plus approprié. Un processus agile peut être utilisé. autre proposition : Pour un système de réalité virtuelle de maintenance des logiciels, un modèle de cycle de vie itératif et incrémental est recommandé. Il permet d'ajouter progressivement de nouvelles fonctionnalités, d'obtenir des retours d'utilisateurs à chaque itération et de s'adapter aux évolutions technologiques.
Exercice 2 :
1. Principe de Responsabilité Unique : Le principe de responsabilité unique, également connu sous le nom de Single Responsibility Principle (SRP), est l'un des principes fondamentaux de la conception logicielle SOLID. Il stipule qu'une classe (ou module) ne devrait avoir qu'une seule raison de changer, c'est-à-dire qu'elle ne devrait avoir qu'une seule responsabilité.
En d'autres termes, une classe doit être conçue de manière à n'avoir qu'une seule tâche ou fonction principale. Cela rend le code plus modulaire, plus facile à comprendre, à maintenir et à étendre. L'application de ce principe favorise une meilleure organisation du code et réduit les risques d'effets de bord indésirables lorsque des modifications sont apportées.
2. Rôles d'un Client et d'un Fournisseur dans un Projet de Développement Logiciel :
- Client : Le client est la partie qui définit les besoins et les exigences du projet. Son rôle principal est de spécifier ce qu'il souhaite que le logiciel accomplisse. Cela implique la création d'un cahier des charges détaillé, la communication des fonctionnalités attendues, des contraintes et des objectifs du projet. Le client est responsable de valider que le logiciel final répond à ses attentes et de fournir des retours tout au long du développement.
- Fournisseur : Le fournisseur, généralement l'équipe de développement ou l'entreprise de développement logiciel, est responsable de la conception, du développement et de la livraison du logiciel en fonction des spécifications du client. Son rôle est de traduire les besoins du client en un produit logiciel fonctionnel, de gérer le projet de manière à respecter les délais et les budgets, et de garantir la qualité du logiciel livré. Le fournisseur doit également collaborer étroitement avec le client pour comprendre et adapter les besoins en cours de projet.
3. Rappel : Règle du CQFD : Coût Qualité Fonctionnalités Délai , Le GL se préoccupe des procédés de fabrication des logiciels de façon à s’assurer que les 4 critères suivants soient satisfaits
=> Le système qui est fabriqué répond aux besoins des utilisateurs (correction fonctionnelle).
=> La qualité correspond au contrat de service initial. La qualité du logiciel est une notion multiforme qui recouvre :
– la validité : aptitude d'un logiciel à réaliser exactement les tâches définies par sa spécification,
– la fiabilité : aptitude d'un logiciel à assurer de manière continue le service attendu,
– la robustesse : aptitude d'un logiciel à fonctionner même dans des conditions anormales,
– l’extensibilité : facilité d'adaptation d'un logiciel aux changements de spécification,
– la réutilisabilité : aptitude d'un logiciel à être réutilisé en tout ou partie,
– la compatibilité : aptitude des logiciels à pouvoir être combinés les uns aux autres,
– l’efficacité : aptitude d'un logiciel à bien utiliser les ressources matérielles telles la mémoire, la puissance de l’U.C., etc.
– la portabilité : facilité à être porté sur de nouveaux environnements matériels et/ou logiciels,
– la traçabilité : capacité à identifier et/ou suivre un élément du cahier des charges lié à un composant d'un logiciel,
– la vérifiabilité : facilité de préparation des procédures de recette et de certification,
– l’intégrité : aptitude d'un logiciel à protéger ses différents composants conte des accès ou des modifications non autorisés,
– la facilité d'utilisation, d’entretien, etc.
=> Les coûts restent dans les limites prévues au départ.
=> Les délais restent dans les limites prévues au départ.
A partir de ce rappel de cours nous pouvons aisemnet repondre a la question :
Qualités Fonctionnelles :
- Validité : aptitude d'un logiciel à réaliser exactement les tâches définies par sa spécification.
- Fiabilité : aptitude d'un logiciel à assurer de manière continue le service attendu.
- Robustesse : aptitude d'un logiciel à fonctionner même dans des conditions anormales.
- Extensibilité : facilité d'adaptation d'un logiciel aux changements de spécification.
- Réutilisabilité : aptitude d'un logiciel à être réutilisé en tout ou partie.
- Compatibilité : aptitude des logiciels à pouvoir être combinés les uns aux autres.
- Efficacité : aptitude d'un logiciel à bien utiliser les ressources matérielles telles que la mémoire, la puissance de l’U.C., etc.
Qualités Structurelles :
- Portabilité : facilité à être porté sur de nouveaux environnements matériels et/ou logiciels.
- Traçabilité : capacité à identifier et/ou suivre un élément du cahier des charges lié à un composant d'un logiciel.
Qualités de Mise en Œuvre :
- Vérifiabilité : facilité de préparation des procédures de recette et de certification.
- Intégrité : aptitude d'un logiciel à protéger ses différents composants contre des accès ou des modifications non autorisés.
- Facilité d'utilisation : convivialité et facilité d'entretien.
4.Cette partie liste sept principes fondamentaux (proposés par Carlo Ghezzi):
- rigueur,
- séparation des problèmes (« separation of concerns »),
- modularité,
- abstraction,
- anticipation du changement,
- généricité,
- construction incrémentale.
