Sonar ABAP – Les cas d’utilisation

Nous continuons le post précédent sur les questions à poser afin de préparer la mise en place d’un processus d’analyse de code ABAP, dont nous avons vu que celui-ci reposait en grande partie sur les cas d’utilisation.

J’ai donc invité Walter, Directeur Qualité de Drago Solutions, qui nous accompagne depuis le début de cette série d’articles, à répondre à quelques questions sur ce sujet.

Walter, quels sont les cas d’utilisation que tu rencontres le plus souvent ?

Les cas d’utilisation auxquels je pense sont : Quality Gate, amélioration continue, audit d’un portefeuille d’aplications, benchmark de provider, KPI pour le management (évolution de la qualité du code), assessments spécifiques (par exemple pour un migration, un problème de performance, etc.)

Les plus fréquents dans mon expérience sont les suivants : d’abord, l’évaluation ponctuelle d’un projet, deuxièmement l’intégration continue de l’analyse de code dans le cycle de vie du logiciel, troisièmement, une analyse avant et après un projet en cours de maintenance, quatrièmement, l’audit de la performance.

Mais il ne faut pas oublier les sous-produits de ces cas d’utilisation, à savoir la l’implémentation de best practices de programmation, le suivi des accords de niveau de service (SLA ou Service Level Agreement), la génération de documentations techniques lorsque celles-ci sont obsolescentes ou absentes, l’évaluation des exigences CMMI ou ISO, ou enfin le respect des normes et des règles spécifiques en environnements à haut risque (défense, aviation civile, nucléaire, secteur pharmaceutique, etc.).

Et récemment, nous avons ouvert un nouveau champ d’investigation, sur l’évaluation et la réduction des risques de défaillances des processus business, causées par les systèmes d’information qui les soutiennent, à travers l’analyse de code de ces systèmes.

Y a-t-il des cas d’utilisation qui te semble présenter plus de valeur et que tu recommanderais à un client ou à des utilisateurs / stakeholders en interne ?

Tout d’abord, l’intégration continue de l’analyse de code dans le cycle de vie de projet a démontré une très grande valeur pour les organisations dans lesquelles nous l’avons mis en œuvre.

Je recommande également la réalisation d’audit de code sous l’angle des risques pour les processus critiques d’une organisation, et particulièrement les processus d’affaires.

Est-ce que cette valeur peut être différente en fonction de la taille du portefeuille SAP, ou le nombre de fournisseurs, ou tout autre élément?

Dans ce dernier exemple d’analyse de risque pour les processus business, plus le portefeuille d’applications SAP sera important, plus l’on pourra identifier et mesurer ces risques au travers de l’analyse de code.

Pour ce qui est du nombre de fournisseurs, plus il est important, plus il sera profitable d’effectuer des cas d’utilisation tels que le benchmarking interne et le suivi des SLA ou des best practices par les prestataires.

Qu’est ce que tu appelles benchmarking “interne” ou “externe”?

Je parle de benchmarking “interne” s’il est nécessaire d’évaluer de manière comparative le niveau de connaissance des bonnes pratiques de programmation et la qualité du code produit par différentes équipes, normalement de différents providers.

A l’inverse, un benchmarking “externe” porte sur les résultats d’analyse de code de différentes entreprises d’un même secteur et pour une même technologie, par exemple, les implémentations SAP du module IS-U dans le secteur de l’énergie ou la personnalisation d’un système CRM dans le secteur des télécommunications.

Qu’en est-il des défauts antérieurs , qui proviennent d’un autre provider ou de l’équipe de projet précédente ?

Comme tu l’as souligné dans ton dernier article, les providers ou équipes de projet actuels ne sont pas responsables des carences existantes dans le code. Néanmoins, lorsqu’elles sont révélées par l’analyse de code, nous ne devons pas les ignorer, en fonction de leur gravité et de leur impact ou de leur fréquence. Nous pouvons sélectionner les points critiques et recommander un plan d’actions. L’effort de résolution, après détection, sera toujours inférieur à son impact pour les utilisateurs. Je compare toujours de tels défauts à une bombe à retardement. Les gens que je rencontre comprennent immédiatement ce que je veux dire.

Que le client ou l’équipe de projet dispose ou non de ses propres normes de qualité, quels sont les bénéfices de l’analyse de code ?

Qu’il existe ou non des standards et des normes de programmation, l’analyse de code permet un premier niveau de connaissance des applications et ensuite de surveiller le respect par l’équipe de projet de ces normes, internes ou externes. En second lieu, il devient possible de définir des objectifs et de vérifier si les développeurs parviennent à les atteindre, dans l’intérêt des utilisateurs et des stakeholders.

L’objectif peut être : « La performance des bases de données doit être optimale », et donc de diffuser, mettre en œuvre et contrôler le respect des bonnes pratiques correspondantes, sur la base de données objectives et mesurables : ne pas utiliser de Selects imbriqués, éviter l’instruction l’instruction SELECT … ENDSELECT, etc.

Merci Walter, pour partager ton expérience dans l’implémentation de ces cas d’utilisation SAP. Les prochains posts seront plus techniques, centrés sur l’analyse de code ABAP avec Sonar.

A bientôt.

Ce article est également disponible en Leer este articulo en castellano et Read that post in english.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *