Tribune Libre
par Gilles Knoery, Directeur Général de Digora
A négliger l’infrastructure logicielle, on hérite d’applications peu performantes
Neuf fois sur dix, lorsque la performance et les temps de réponse d’une application se dégradent, les équipes techniques adoptent le même reflexe : elles rajoutent de la puissance. Dans un contexte où les ressources serveurs n’ont jamais été aussi facilement accessibles et bon marché, on les comprend. Le Cloud et la virtualisation se banalisent, le prix des mémoires et des CPU est en chute libre, les « appliances » (solution matérielle et logicielle prête à l’emploi) de big data fleurissent ici et là…
Le problème ? Les entreprises abusent de ces ressources faciles. Non seulement la course à l’armement n’enraye pas à long terme la chute des performances, mais surtout elle fait grimper dangereusement la facture. Et pour cause, la plupart du temps, ces dysfonctionnements ne sont pas imputables, comme on le croit à tort, à une faiblesse des serveurs, de la base de données ou du réseau. Ils résultent d’un mauvais ajustement entre les couches d’infrastructures et les logiciels.
La majorité des développeurs n’a pas conscience des architectures techniques qui font tourner leurs applications. Conséquence : ils ne maitrisent pas l’impact des plans d’exécution de leurs requêtes. En raison d’une requête mal paramétrée, un simple bouton utilisateur (« récupérer une facture » ou « ouvrir une fiche client ») mettra ainsi à genou la performance globale d’un système. Soit parce qu’il génère jusqu’à 3 000 lignes de code SQL, soit parce qu’il entraîne le balayement systématique et continu d’une base de 100 Tera octets.
La problématique de la performance des applications est donc d’abord celle d’un code ignorant les infrastructures en présence. Ce constat s’inscrit malheureusement dans la tendance actuelle de banalisation, voire de négligence des couches basses. Et ce au profit des seules applications, jugées plus critiques. L’absence de formations autour de SQL illustre cette désaffection pour le « middleware » (couches logicielles intermédiaires).
Une situation paradoxale
Car la prise en considération de ces éléments d’infrastructure n’aura jamais été aussi nécessaire. Surtout depuis les dernières versions, particulièrement enrichies, des bases de données. Celles-ci offrent par exemple nativement des modes « multi-tenant » : une seule et même base sait faire tourner plusieurs instances totalement isolées les unes des autres (un environnement pour la production, un autre pour les tests, un troisième pour la formation…) De la même façon, les bases de données parviennent aujourd’hui à remonter le temps, et à rejouer l’ensemble des transactions. On leur demande également de tourner 24 heures sur 24 sans jamais s’arrêter…
Ces enrichissements du « middleware » ne sont pas sans conséquence. Ils complexifient de plus belle l’alignement des applications sur les infrastructures. Peu permissives, ces nouvelles fonctions exigent, coté applications, des normes de développement et une qualité de code bien plus importantes que par le passé. De quoi contredire l’idée selon laquelle les couches basses se banalisent.
De quoi également tordre le cou à une autre contre-vérité, liée cette fois aux DBA (Administrateurs de Bases de Données). Avec les nouveaux environnements « plug and play » (prêt à l’emploi) des bases de données, certains voyaient leur métier menacé. Il n’en est rien : la prolifération des fonctions avancées de ces mêmes bases rend au contraire les DBA indispensables pour garantir un paramétrage optimal. Le niveau d’acquisition de leur connaissance devient d’ailleurs de plus en plus élevé.
Le Cloud et la virtualisation permettent bien aux entreprises de s’abstraire des couches d’infrastructure. Mais en partie seulement. Des compétences seront toujours nécessaires pour ajuster les applications et leur niveau de service attendu, aux architectures techniques. Sans quoi ces applications ne répondront jamais totalement à leurs promesses.
La Gestion des Anomalies pour les DSI
L’implémentation de processus de gestion des anomalies n’est pas un élément sur lequel les DSI perdent trop de sommeil. Peut-être à tort. Cet article définira cinq aspects clé qui devraient être suivis par les DSI et responsables de développements logiciels, qu’ils externalisent ou non les développements et les tests.
Pourquoi une Gestion d’Anomalies ?
Bien entendu pour gérer, mais pas uniquement. Une anomalie est souvent le reflet d’une défaillance dans les processus de conception. Les mêmes causes ayant les mêmes effets, tant que cette défaillance n’est pas corrigée, des anomalies similaires apparaitront. La correction d’anomalies impacte les délais – et les coûts – des livraisons de logiciels aux utilisateurs et clients. DSI ou Responsables de Développements doivent limiter ces impacts, et optimiser les processus, en mesurer l’efficacité et en améliorer la rentabilité. Une gestion d’anomalie est donc une source d’économies potentielles.
1. Mesurer et Informer Une gestion d’anomalies complète doit :
– identifier les processus les plus coûteux (ceux qui génèrent le plus d’anomalies),
– mesurer l’efficacité des processus de détection (revues ou tests), et
– permettre d’anticiper les livraisons.
Parmi les informations à fournir par la gestion d’anomalies, nous avons :
– Le nombre de défauts trouvés, corrigés, et à corriger (voir Figure 1)
– Les composants ou fonctionnalités avec le plus de défauts (voir Figure 2)
– Les durées moyennes de correction des défauts (voir Figure 3)
– Le coût des anomalies et les économies potentielles
– Les causes d’anomalies, et les processus défaillants (voir Figure 4).
Pour prendre des décisions en temps utile, vous devez mesurer périodiquement l’écart par rapport à des objectifs initiaux. Ceci implique des données correctement introduites et un reporting identifiant les tendances.
2. Tirer des Leçons des Anomalies
Une anomalie – corrigée ou non – a un coût, et indique un dysfonctionnement dans les processus de conception. Tant que ces processus ne sont pas corrigés, des anomalies de même type se reproduiront. Une analyse des causes racines des anomalies est connu, souvent coûteuse et non généralisable pour chaque anomalie. D’autres techniques existent et ont fait leurs preuves. Elles nécessitent souvent une expertise spécifique pour être mise en place efficacement, sans cela les bénéfices seront absents, et les livraisons en retard.
3. Ne pas travailler en silos
Souvent les équipes de conception, de réalisation et de support utilisent des outils de gestion de défauts différents et ne communiquent pas entre eux. Chaque équipe a ses propres outils – ou n’en a pas – et n’échange pas automatiquement avec les autres équipes. Les exigences font l’objet de revues, mais les anomalies identifiées en revues ne sont pas introduites dans le même outil de gestion d’anomalies. Donc on n’identifiera pas les documents de mauvaise qualité, ni le besoin d’amélioration d’exigences.
Les anomalies identifiées par les développeurs (lors des tests unitaires) sont-elles enregistrées dans l’outil de gestion des anomalies ? Souvent, elles sont corrigées sans être remontées. Les causes racines de ces anomalies ne seront ni identifiées ni corrigées. Si les équipes de test et de développement ne partagent pas le même outil, des informations se perdront, et donc de la valeur (et des possibilités d’améliorations).
Nous pouvons réfléchir aux équipes de support client, sollicitées pour les défauts trouvés en production. Les informer des défauts non corrigés réduira la durée des appels clients (un gain de temps mesurable). Obtenir, de la part des équipes de support client, les anomalies trouvées en production, identifiera des domaines omis par les testeurs. Remonter aux analystes métier les demandes des clients à l’équipe support, identifiera de futurs axes de développements.
Il est important de ne pas travailler en silos séparés, et l’outil de gestion d’anomalies permet de partager des informations utiles aux divers acteurs, pour autant que les données brutes soient introduites par les divers acteurs.
4. Adapter l’outil aux besoins
Il existe de nombreux outils de gestion d’anomalies, gratuits ou payants, en shareware, en Open Source ou commerciaux. Leur installation initiale est souvent simple, cependant les éléments de reporting fournis en standard sont limités. Beaucoup des données de classification, nécessaires à l’élaboration des rapports mentionnés dans cet article, sont absentes. Pour obtenir la pleine rentabilité de votre outil de gestion d’anomalies, vous devrez (selon la méthode GQM) : définir vos objectifs de gestion, identifier les questions à poser et déterminer les métriques à mesurer.
Pour mesurer le nombre de défauts trouvés, corrigés, et à corriger, puis le remonter de façon cohérente (cf. Figure 1), vous devrez concevoir un graphique comprenant 5 axes, qui n’est généralement pas fourni en standard dans les outils de gestion d’anomalies. Il faudra passer par des échanges de données et des graphiques générés par des tableurs.
Pour identifier la durée moyenne de correction des défauts (cf. Figure 3), vous aurez besoin de données de dates dont la fourniture peut être automatisée, mais non standard. Ainsi vos équipes devront adapter l’outil, rajouter des champs et veiller à ce qu’ils soient remplis.
En fusionnant les informations d’anomalies provenant des divers sources identifiées plus haut (cf. §3) et les coûts (de développement, de test, de correction, et de support), vous saurez déterminer le taux d’efficacité de vos activités de développement et de recette, et les améliorer. Ces informations sont essentielles pour les DSI et Responsables de Développement.
5. S’améliorer continuellement
Pour les causes d’anomalies, et les processus qui les génèrent (cf. Figure 4), seuls huit champs sont nécessaires (activité, impact, déclencheur, composant cible, type d’erreur, type de correction, source et âge). Ces champs doivent être introduits par les testeurs, et par les développeurs. Ces champs ne sont pas présents par défaut dans les outils de gestion d’anomalies.
L’analyse des informations liées à ces données, (p.ex. via des rapports tel celui Figure 4) associe les processus de conception et le nombre d’anomalies qu’ils génèrent. Responsable de Développement, ou au DSI, identifieront les processus de conception à améliorer, et optimiseront les développement futurs.
6. Synthèse
Au vu de l’impact des défauts (à la fois en termes de délais et de coûts), il est impératif d’améliorer la rentabilité et l’efficacité des processus de conception et de test. Une gestion d’anomalies optimisée est nécessaire. Des techniques simples comme GQM (GQM : Goal Question Metric, Méthode proposée par Victor Basili, hors du scope de cet article) et ODC (ODC : Orthogonal Defect Classificatoin, méthode proposée par IBM dans les années 1980) peuvent limiter le nombre et l’impact des anomalies (p.ex. retards des livraisons). Cela nécessite :
– d’adapter les outils disponibles, – de définir des exports de données,
– d’obtenir les graphes et rapports adaptés à vos besoins.
Ceci n’est pas trivial et dépasse le cadre simpliste de suivi d’anomalies proposé en standard. DSI et responsables de développements doivent définir leurs besoins et ne pas ignorer cette source d’informations souvent méprisée.
B. Homès
Bernard Homès
Président TESSCO sas
Fondateur et ex-président du Comité Français des Tests Logiciels
( bhomes@tesscogroup.com )
Bernard Homès (55 ans) bénéficie d’une expérience de plus de 33 ans dans le domaine de la Qualité et des Tests de logiciels. Il a occupé différents postes clefs à dimension internationale, en Amérique du Nord et en Asie. Depuis 2000, il exerce en qualité de Consultant Senior pour le compte d’entreprises renommées dans l’aéronautique, le spatial et les télécommunications. Bernard possède plusieurs certifications en test (CMAP, ISTQB CTFL, CTAL-TM, CTAL-TA, CTAL-TTA) et en gestion des exigences (IREB et REQB), et se focalise sur le transfert de connaissances, la formation et l’amélioration de la rentabilité des projets de test.
Bernard est également intervenu en dernière année du Mastère au sein de l’École des Mines de Paris et de HEC, dispense de nombreuses conférences chaque année et s’implique au sein de nombreuses organisations professionnelles (jury de l’Académie d’experts de France Télécom R&D, groupe de travail et auteur du Syllabus Avancé de l’ITQSB, bureau exécutif de l’IEEE France, membre fondateur de l’Association for Software Testing aux USA, du GASQ et du CFTL.
