 |
|
|
| |
|
|
|
| La résolution de bugs : une question de méthode avant tout |
| La phase de débogage occupe une place critique dans le cycle de vie du développement applicatif. Méthodes itératives et chasse à la régression sont de mise pour la mener à bien.
(17/03/2006) |
|
S'il existe un sujet qui mette au diapason un client final avec son prestataire en charge des développements applicatifs, il s'agit bien de la chasse (perpétuelle) aux bugs et autres dysfonctionnements.
Revêtant essentiellement deux formes, ces derniers proviennent en effet soit d'une non conformité technique du code ou d'une non conformité fonctionnelle de l'application elle-même.
Ainsi, dans le cas d'un bug technique, l'application se trouve être irrémédiablement "plantée", alors qu'un bug fonctionnel - s'il n'implique pas un blocage du système - empêche l'exploitation de l'application telle qu'originellement définie par le cahier des charges.
Confronté à un bug technique, le développeur fera appel à un outil de débogage fournissant des indicateurs servant à identifier les instructions de codes qui sont à l'origine de son déclenchement. La démarche sera bien entendu différente avec la découverte d'un bug fonctionnel.
"Dans le cas d'un bug fonctionnel où le système ne plante pas, l'utilisateur a la possibilité de décrire le problème rencontré dans un système de bug track qui permet de référencer les bugs et de générer des alertes automatiques à destination du développeur de l'application", indique Didier Girard, directeur technique au sein d'Improve, société de conseil objet, Internet et nouvelles technologies.
"Une méthode de développement itérative doit être privilégiée"
(Gilles Lapère - Arès) |
"La non-conformité technique consiste en un bug de développement, qui n'est pas le problème le plus complexe à résoudre par rapport à un bug fonctionnel, beaucoup plus impactant et pouvant même aboutir à une phase de rejet entre le développeur et son client final", prévient Gilles Lapère, responsable études et développement au sein de la SSII Arès.
Pour éviter de se retrouver dans cette situation de point de rupture, le choix d'une méthode de développement itérative, basée sur de constants allers - retours entre le client et son prestataire pour la validation des spécifications fonctionnelles, semble à privilégier.
"Avec une méthode de développement itérative, les corrections à apporter à l'application sont moins complexes et fastidieuses qu'une méthode distinguant l'étape de spécification de celle du développement, au cours de laquelle le client réalise des jeux d'essai. Sans compter qu'apporter des modifications fonctionnelles à une application développée depuis plusieurs mois génère un haut risque de rejet", ajoute Gilles Lapère.
En outre, la phase de débogage intervient le plus souvent à plusieurs reprises dans le cycle de vie d'un projet applicatif. Tout d'abord dans la phase de développements initiale, lors de son intégration dans l'environnement de fonctionnement et, également - mais de façon moins formelle - une fois la livraison de l'application effectuée (on évoque alors une phase dite de maintenance corrective).
"La résolution de la non-conformité d'une application est confiée au développeur de l'application, tandis que le gestionnaire de projet intervient dans la phase amont de résolution en écrivant les plans de tests et leur niveau de détail. Le chef de projet valide la phase de tests en s'assurant que l'application est prête à être livrée", précise Gilles Lapère.
"S'assurer que les bugs ne réapparaissent pas est essentiel "
(Didier Girard - Improve) |
Cependant, l'identification du dysfonctionnement ne suffit pas, encore faut-il s'assurer qu'il ne sera pas redondant.
"La présence de bugs dans les applications n'est pas le problème le plus important, car ce qui compte avant tout, c'est de faire en sorte qu'ils ne réapparaissent jamais dans le cycle de vie du programme. La mise en place d'un système de tests unitaires de non régression doit alors être envisagée afin d'assurer la meilleure couverture possible du code", signale Didier Girard.
"Il est toujours difficile de livrer une application dont le code possède 100 % de couverture, ce taux étant trop dépendant d'autres paramètres externes comme les délais de livraison décidés par le client, les moyens et ressources mobilisées pour le développement ainsi que le niveau de qualité attendu. Sans compter le cas où le client n'a pas mené à bout les phases de test nécessaires, ce qui aboutit le plus souvent à une situation de conflit", poursuit Didier Girard.
Les risques proviennent essentiellement de la sous-estimation par le client de l'importance de la phase de tests. "Avec une méthode itérative de développement, le risque de dérive est relativement maîtrisé et le client n'a pas d'autre alternative que de tester lui-même l'application en interne, en manipulant les morceaux de développement à des intervalles fixes et rapprochés", remarque de son côté Gilles Lapère.
Et le responsable études et développements de conclure :
"on accepte plus facilement d'être mis en cause en cas de non conformité fonctionnelle de l'application lorsqu'elle a été développée selon une méthode itérative".
|
|
|
|
|
|
|
Dossier 
