• Aucun résultat trouvé

Unité Lectures et Autres ressources

Dans le document Assurance de la qualité logicielle (Page 66-70)

Les lectures de cette unité doivent être trouvés au niveau de cours Lectures et autres ressources.

Évaluation du cours

L’évaluation finale du cours est laissée à la discrétion de l’institution qui offre le cours.

Évaluation Finale 1 (Evaluation sommative)

Directives

Les examens finaux sont gérés à la discrétion de l’établissement qui offre le cours. Cette évaluation porte sur tout le module et il est recommandé que vous le fassiez individuellement.

Ce type d’examen comptera généralement pour 50% des évaluations de ce module.

Système de notation

Cette évaluation est notée sur 20 points. Chaque question est notée sur 1 point.

Unité 4. Gestion de la qualité

Évaluation

I- Répondre par Vrai ou Faux et justifiez si c’est faux.

1. La phase de contrôle de qualité doit intervenir à la fin du développement.

2. la non-validation des exigences par le client avant le développement conduit à un échec du logiciel.

3. La qualité est garantie si le logiciel fonctionne correctement en fonction de ce que vous avez compris des exigences.

4. Le client, les utilisateurs et les intervenants disparaissent du processus du développement dès que l’analyse des besoins est terminée. Il ne revienne qu’après l’implémentation.

5. Toutes les propositions de qualité des différents acteurs conduisent la qualité.

6. Un système de détection de métaux à l’aéroport peut avoir une assurance qualité moyenne.

7. Les tests de conformité sont menés uniquement par un organisme accrédité.

8. Le prototypage ne participe pas à l’assurance de la qualité du logiciel.

II- Répondre aux questions suivantes

9. Quelles sont les caractéristiques d’un logiciel ?

10. Expliquez la différence entre la vérification et la validation ?

11. Qu’entendez-vous par maintenance de logiciels ? Donnez les catégories de maintenance des systèmes ?

12. Quelles différences voyez-vous entre une norme et un standard ? 13. Pensez-vous qu’un standard peut devenir une norme ?

14. Définissez la qualité ?

15. Si vous devez négocier à la fin de ce cours un projet de développement logiciel, pensez-vous que le coût serait le même que ce que vous auriez négocié avant de suivre ce cours ? Pourquoi ?

16. Donnez trois (3) caractéristiques du modèle de qualité ISO 9126.

17. La fiabilité est-il un facteur critique de qualité ? Discutez.

18. Citez les quatre objectifs de l’équipe d’assurance de la qualité logicielle.

19. Décrivez les techniques/méthodes/outils qui pourraient être utilisés par les ingénieurs logiciels afin d’aider à répondre aux questions d’assurance qualité suivantes :

20. a. Le logiciel répond-t-il de manière adéquate à ses facteurs de qualité ? b. Le développement du logiciel a-t-il été mené selon les normes préétablies ? 21. Donner trois exemples de mesure qu’on peut généralement faire avec les

outils de test de logiciels ?

Réponses :

I-

1. Faux, car les spécifications de qualité doivent être vérifiées au fur et à mesure. L’omission d’une exigence de qualité constatée à la fin du développement peut avoir un impact négatif sur la livraison et rallonger les délais.

2. Vrai, car il faut valider avec tous les acteurs les exigences avant d’évoluer.

3. Non, car si la compréhension que vous avez, n’a pas été validée par le client lors de l’établissement du dossier d’analyse, votre développement sera vain. Beaucoup de choses seront remis en cause. Il serait plus prudent de tout faire valider avec tous les acteurs impliqués avant de continuer avec la conception. Chaque inquiétude au niveau d’un processus doit être clarifiée par tous les acteurs avant d’évoluer vers une autre phase.

4. Faux, il faudrait chaque fois faire un point de l’évolution avec quelques acteurs clés pour réduire le risque d’échec du développement. Il faut rester en contact permanent avec le client et certains acteurs clés.

5. Faux, car toutes les propositions peuvent ne pas être réalisables à cause d’un choix technologique dépassé ou très récent dont l’équipe de développement n’a pas la maîtrise.

6. Faux, l’assurance qualité doit être élevée car un tel système doit être très sensible à tout soupçon de métal dans un bagage ou sur une personne.

7. Faux, les tests de conformité peuvent être menés par des sociétés privées qui se spécialisent dans la vérification des normes, mais l’entreprise peut également disposer d’un service interne pour effectuer des tests de conformité.

8. Faux, car cela pourrait déjà permettre de s’entendre au mieux sur ce que sera l’application et d’être plus précis sur ce qui pourrait être choisies comme normes à suivre pour atteindre la qualité.

Unité 4. Gestion de la qualité

II-

9. Fonctionnalité, fiabilité, ergonomie, efficacité, maintenabilité, portabilité 10. Ceux sont deux aspects de la notion de qualité.

La vérification fait la correction d’une phase du processus de développement ou de l’ensemble par rapport aux éventuelles erreurs sur les définitions ou spécifications définies lors des phases antérieures de développement.

La validation voit la conformité par rapport à la définition en contrôlant les défauts par rapport aux besoins que le produit doit satisfaire.

11. Quatre types de maintenance

• Maintenance corrective : modification d’un progiciel effectuée après livraison afin de corriger les défauts rencontrés.

• Maintenance adaptative : modification d’un progiciel effectuée après livraison pour qu’il reste utilisable dans un environnement qui change ou a changé.

• Maintenance perfective : modification d’un progiciel effectuée après livraison pour en améliorer l’efficacité ou la maintenabilité.

• Maintenance préventive : modification d’un progiciel effectuée après livraison pour en déceler et corriger les défauts latents avant qu’ils ne se manifestent.

12. La norme est mise en place par un organisme de normalisation national ou international tandis que le standard est publié par une entité privée.

13. Un standard peut évoluer pour devenir une norme si les restrictions d’accès sont levées.

14. La qualité est le fait qu’un produit répond aux spécifications initialement retenues lors de l’analyse des exigences. Elle peut se mesurer par la vérification de certains attributs clés.

15. Non, parce qu’il faudra y intégrer les coûts liés à la prise en compte de la qualité.

16. La norme ISO/CEI 9126 définit un langage commun pour modéliser les qualités d’un logiciel.

17. Caractéristiques : fiabilité, facilité d’utilisation, efficacité, maintenabilité, portabilité

18. La fiabilité est un facteur critique de qualité car elle permet d’identifier les dangers potentiels qui peuvent causer la défaillance d’un logiciel. Elle permet d’avoir un produit qui répond aux exigences de qualité définies.

19. Les objectifs concernent la vérification des exigences de qualité, la qualité de la conception, la qualité du code et l’efficacité du contrôle de qualité.

Cela peut être aussi la vérification de l’intégrité, la complexité, le taux

la documentation.

20.

• La mesure des indicateurs de performance (fiabilité, robustesse, temps de réponse, …) par des tests, l’utilisation des logiciels d’évaluation de performance tel que LoadUI, la qualité du code, le respect des normes telles que définies par l’équipe d’assurance qualité (ISO 9126)

• La vérification de la conformité par rapport aux normes choisies par des tests, des mesures de métriques de qualité.

21. Temps de réponse, disponibilité, la robustesse

Dans le document Assurance de la qualité logicielle (Page 66-70)

Documents relatifs