Soutenance mémoire
Le cycle de développement d’un logiciel est un processus long et complexe, avec beaucoup d’étapes. Les différentes phases du cycle de développement ont toutes leur importance et leur coût associé. La phase d’analyse produit les documents de spécification du système. La phase de conception permet de construire et schématiser le logiciel par rapport aux exigences recueillies dans la phase d’analyse. La phase de développement est celle où les fonctionnalités du système sont codées. Finalement, une série de vérifications et validations sont effectuées durant la phase de test. La capacité de faire des prévisions sur les dernières phases (développement et test) est un facteur des plus importants dans la gestion d’un projet de développement [17, 33].
Les phases d’analyse et de développement sont généralement considérées comme des phases coûteuses en termes de temps et de ressources. Avec la création de logiciels de grande envergure, il devient d’autant plus important de pouvoir estimer cet effort le plus rapidement possible pour pouvoir planifier correctement les activités et l’attribution des ressources d’un projet [6, 15, 41]. Les mêmes objectifs sont d’autant plus valables pour les tests. Il s’agit, dans ce projet, de mettre l’accent sur la prédiction des efforts relatifs aux phases de développement et de test. L’effort de la phase de développement peut se mesurer en termes de taille du code source qui doit être écrit pour compléter les exigences décrites durant la phase de conception. De façon similaire, pour la phase des tests, on considère la taille des suites de tests automatisés permettant de tester la totalité des fonctionnalités codées [14, 15].
Métriques des suites de test
Dans le développement d’un logiciel, un test peut être définit de plusieurs façons différentes: manuel ou automatique. Pour le test manuel, l’utilisateur pilote effectuera une série d’opérations pour en vérifier le résultat. Quant au test automatisé, la tâche sera effectuée par un ordinateur qui disposera d’une batterie de tests à exécuter. Les tests peuvent être de type unitaire ou d’intégration. Certains types de tests se prêtent mieux aux tests manuels (tests d’intégration), alors que d’autres peuvent être semiautomatisés à l’aide d’outils, tels que JUnit1 (tests unitaires).
Pour effectuer la prédiction des efforts de test, nous avons considéré une catégorie de tests qui représente, à notre point de vue, une bonne partie de l’effort global nécessaire pour tester un système. Il s’agit des tests unitaires automatisés. Les tests unitaires automatisés ont un concept de couverture de code, représentant le pourcentage du code testé (du moins couvert) par la suite de tests. On considère que l’effort nécessaire pour développer une suite de tests unitaires couvrant une grande majorité du code d’un logiciel est un bon indicateur de l’effort global de test. Pour mesurer cet effort, nous utilisons deux métriques [14, 15].
Métriques de cas d’utilisation (MCU)
Un cas d’utilisation se définit comme étant une série de transactions effectuées entre un acteur et le système, ayant une collection de scénarios possibles résultant en un succès ou en un échec du cas [24, 27]. Le modèle de cas d’utilisation est un outil important pour définir la portée d’un système et lister les fonctionnalités que ce dernier doit implémenter pour satisfaire aux exigences du client. Le schéma typique d’un cas d’utilisation est représenté par un acteur envoyant un message au système, qui délègue ce message à des sous-systèmes jusqu’à complétion de la tâche, suite à quoi un message de retour est renvoyé à l’acteur. Certains cas peuvent nécessiter plusieurs opérations de la part de l’acteur, alors que d’autres vont offrir plusieurs messages de retour possibles. Un cas peut aussi avoir une série de scénarios, représentant chacun un chemin du début du cas jusqu’à sa complétion. Dans certains cas, un seul scénario se termine en succès alors que tous les autres donnent des erreurs (cas exceptionnels).
Dans le but de prédire l’effort de test, nous devons extraire des métriques des cas d’utilisation. Voici la liste des métriques qui ont été considérées:
Nombre de classes impliquées (NCI) : Le nombre de classes (ou entités du côté système) impliquées dans la réalisation du cas d’utilisation (participant au cas). Cette information est disponible dans le diagramme de séquences d’un cas d’utilisation. À noter que seules les classes testables unitairement ont été considérées. Les classes ne contenant pas de logique de métier, comme les classes gérant l’interface graphique d’un logiciel, ne sont pas considérées « testables» pour les besoins de ce projet.
Nombre d’opérations externes (NOE): Cette métrique représente le nombre d’opérations disponibles à l’interface d’un cas d’utilisation. La complétion du cas nécessitera généralement l’appel de toutes les opérations externes de ce dernier. Pour faire un parallèle avec la phase de conception, les opérations externes pourraient être regroupées dans une classe Controlleur (ou Façade).
Nombre de méthodes impliquées (NMI) : Le nombre de message différents utilisés dans le diagramme de séquences. Un message représente l’appel d’une méthode dans la phase de conception. Les messages permettent de comprendre comment les objets interagissent entre eux. Cette métrique inclut la totalité des méthodes appelées dans la réalisation du cas, incluant tous ses scénarios.
Nombre de scénarios (NS): Un scénario est définit comme un chemin valide pour compléter un cas d’utilisation. Certains cas d’utilisations n’ont qu’un seul scénario, alors que d’autres vont en avoir une multitude. Dépendant du cas, un scénario peut résulter en une erreur retournée à l’acteur du scénario.
Nombre de transactions (NT): Cette métrique compte le nombre de transactions présentes dans un cas d’utilisation. Une transaction est définie comme étant un échange de messages entre l’acteur et le système, ou dans certains cas, entre deux sous-systèmes. En réalité, deux métriques ont été utilisées pour mesurer le nombre de transactions, l’une incluant toutes les transactions du système, y compris les transactions internes, et une autre n’incluant que les transactions où l’acteur participe (nommée Nombre de transactions de haut-niveau (NTHN)).
L’ensemble des métriques a évolué avec le projet, avec certaines métriques retirées et d’autres rajoutées après certaines étapes. La métrique NMI, constatée comme étant peu influente dans les analyses statistiques (corrélation faible), a été retirée du modèle finalement. Les métriques NT et NTHN ont été considérées plus tard dans le projet, avec l’inclusion de la méthode UCP, qui fait aussi usage de ces métriques [31].
|
Table des matières
CHAPITRE 1- INTRODUCTION
CHAPITRE 2 – REVUE DE LA UTIÉRATURE
CHAPITRE 3 – CADRE GLOBAL DE L’ÉTUDE
3.1 Métriques des suites de test
3.2 Métriques de cas d’utilisation (MCU)
3.3 Métriques de classes
3.4 Méthodes existantes
3.4.1 La méthode UCP (Use Case Points)
3.4.2 La méthode OCP (Objective Case Points)
3.4.3 Études de cas
CHAPITRE 4 – PRÉDICTION DES EFFORTS DE TEST
4.1 Étude empirique
4.1.1 Analyses de corrélations
4.1.2 Analyses de régression logistique
CHAPITRE 5 – PRÉDICTION DES EFFORTS DE DÉVELOPPEMENT
5.1 Métrique d’effort de développement
5.2 Étude empirique
5.2.1 Analyses de corrélations
5.2.2 Analyses de régression logistique
CHAPITRE 6 – DISCUSSION ET INTERPRÉTATION DES RÉSULTATS
6.1 Sommaire des résultats
6.2 Menaces à la validité
CHAPITRE 7 – CONCLUSION
Télécharger le rapport complet
