les modèles « sqale » pour l’évaluation de code source
TRANSCRIPT
Les modèles « SQALE » pourl’évaluation de code source logiciel
DNV IT Global Services
Pouvoir évaluer de manière objective la qualité du code source d’une application logicielle est un avantage considérable. La méthode “SQALE” (Software Quality Assessment based on Lifecycle Expectations) d’évaluationde code source logiciel développée par DNV ITGS offre :
- une excellente visibilité et une synthèse homogène sur la qualité de l’applicatif,- un diagnostic quantitatif objectif applicable de manière générique,- un hiérarchisation des constats permettant l’optimisation du plan de correction,- une mise en œuvre simple et rapide par son automatisation,- une complémentarité naturelle avec les méthodes d’évaluation de processus.
La méthode “SQALE” présentée ici comporte l’application de deux modèles originaux - un modèle qualitéhomogène et hiérarchique et un modèle d’analyse basé sur le concept de remédiation.
Modèle Qualité et Modèle d’analyse
Le besoin de connaître, d’évaluer la qua-lité du code logiciel dont on a demandéou payé le développement n’est pas nou-veau. Lorsqu’on recette une application,en complément de tests fonctionnels et deperformances, on aimerait bien pouvoirqualifier facilement et de façon précised’autres attributs de la livraison. On aime-rait, par exemple, savoir si le code suppor-tera facilement les demandes d’évolutionqui ne manqueront pas d’apparaitre, ous’il sera facile de faire assurer sa mainte-nance par une équipe tierce.
Bien que certains grands donneurs d’or-dre aient développé leurs méthodes, voireleurs propres outils pour satisfaire cebesoin d’évaluation, ces pratiques n’ontpas été généralisées faute de méthodestandard permettant la systématisation dece type d’évaluation dans des délais et descoûts réduits.Cette absence de méthode pour évaluerdes logiciels est ressenti aussi par les res-ponsables de développement de logiciel. Illeur manque des moyens standards et sim-ples pour évaluer la qualité du code logi-ciel et piloter leurs projets selon les troisaxes majeurs qui sont la qualité, les coûtset les délais.
Plus généralement, si l’on prend une orga-nisation qui développe des logiciels, onpeut positionner ses capacités et la matu-rité de ses processus sur une échelle éta-lonnée comme celle du modèle standardCMMI. En ce qui concerne le code logicielqu’elle développe, il n’existe pas de sys-tème complet et calibré pour positionner,coter la qualité des codes sources qu’elleproduit.
Pourtant, les modèles de bonnes pratiquesde développement tels que le CMMI pourl’Acquisition1 ou CMMI pour le Dévelop-pement2 2 requièrent de contrôler et de sui-vre la qualité des produits pendant toute la
Le modèle qualité SQALE
Ce modèle possède quatre caractéristiquesparticulières :
� Il est construit par une approche générique prenant en compte le cycle de vie du code source.
� Il est organisé en niveaux successifs.
� C’est un modèle d’exigences, et nonune liste de bonnes pratiques à prendre en considération.
� Il prend en compte les points de vue du réalisateur et celui de l’utilisateur du logiciel.
Pour déterminer les caractéristiques qua-lité de base de notre modèle, nous avonsutilisé une démarche qui s’appuie sur lecycle de vie typique d’un fichier de codesource logiciel. Nous avons retenu cettegranularité parce que c’est celle usuelle-ment prise pour attribuer un « proprié-taire » dans les projets de développement.C’est aussi la granularité supportée par lesoutils de gestion de configuration de codeet souvent celle utilisée pour la compila-tion. Quel que soit le cycle de vie général(cycle en V, cycle en spirale…) d’uneapplication, un fichier va typiquement sui-vre une chronologie, un cycle de vie, illus-tré dans la figure 1.
Même s’il y a, au niveau macroscopique,des allers et retours entre différentesphases (par exemple entre le codage et letest), ce diagramme illustre une chronolo-
DNV IT Global Services - Enhancing Trust and Confidence in IT
Figure 1 : Le cycle de vie « fichier » retenu pour créernotre modèle Qualité. Les dépendances entre activitéset caractéristiques qualité
� Orientation du modèle sur des points de vue différents de celui d’un évaluateur en charge de statuer sur la qualité d’uncode source.
� Non orthogonalité des caractéristiques.
Mais, ce qui représente la principale fai-blesse de tous ces modèles, c’est qu’ils nesont pas accompagnés d’une méthodedétaillée et concrète permettant de noterune application selon les critères qu’ils établissent.
On se retrouve à devoir créer sa propreméthode d’évaluation. Par exemple onpeut, pour chacune des sous-caractéris-tiques, demander à un panel d’expertsayant parcouru le code de donner unenotre entre 1 et 5. En faisant la moyennedes notes, on identifiera les sous-caractéris-tiques avec des bonnes moyennes et cellesavec des moyennes faibles. On aura ainsiidentifié les points forts et les points faiblesdu logiciel. On voit tout de suite que cetteméthode est coûteuse, longue et peu re-productible.
Nous avons développé la méthode SQALEet ses 2 modèles pour satisfaire nos clientsayant besoin d’évaluer le code source d’ap-plications stratégiques.
Afin de contribuer au travail collectif indis-pensable vers l’obtention d’un standardd’évaluation, nous décrivons ici les mo-dèles SQALE que nous utilisons avec suc-cès depuis plusieurs années.
durée du projet de développement.
C'est le cas, par exemple, de la pratique SP1.2 du PA (Process Area)PPQA (Product andProcess QualityAssurance): « Objectively Evaluate WorkProducts and Services » et dela pratique SP 2.3 du PASAM (Supplier AgreementManagement):« Evaluate Selected SupplierWork Products ».
Ces pratiques seraient plusfaciles à mettre en œuvre,s’il y avait une méthodestandard et simple pourpratiquer ces évaluationsde code source.
Les deux constituantsprincipaux d’une
méthode d’évaluation sont d’une part unmodèle qualité et d’autre part un modèled’analyse.
� Le modèle qualité définit les caractéris- tiques qualités (appelés parfois aussi fac-teurs) attendues dans le contexte de l'éva-luation et les décompose en sous caracté-ristiques (ou sous facteurs) plus détaillées. Cette décomposition permet d'en déduire les contrôles précis à effectuer lors de l'évaluation du produit.
� Le modèle d’analyse précise les règlespermettant de caractériser ou de noter lesproduits (ou leurs constituants) en fonc-tion des mesures effectuées sur les points de contrôle identifiés dans le modèle qua-lité. C'est ce qui est nommé « model » ou « analysis model » dans la norme ISO/IEC 159393.
En ce qui concerne les modèles qualité, lesplus connus sont ceux de Boehm4, deMcCall5, de l'ISO 9126.6 Ils sont générauxet n'ont pas été spécialement développéspour l'évaluation du code source d'uneapplication logicielle.
Lorsqu’on essaye de les utiliser pour effec-tuer des analyses de code source, on seheurte à un certain nombre de problèmesdont les principaux sont les suivants :
� Mélange de caractéristiques fonctionnelles et externes avec des caractéristiquesprincipalement intrinsèques.
Le CMMI
permet
d’évaluer les
processus mis
en œuvre
par une
organisation.
Pour évaluer
le code
développé,
il manque un
standard qui
soit
concrètement
applicable.
2
RéutiliserRéutilisabilité
Maintenabilité
Efficacité
Évolutivité
Fiabilité
Testabilité
Équi
pe P
roje
t
Autre
s éq
uipe
s
Maintenir
Livrer
Modifier
Tester
Coder
gie générale et des règles de bon sens :
� On ne va pas livrer un code qui n’a pas été testé.
� Il y aura toujours des évolutions à pren-dre en compte ou des corrections à faire avant de livrer.
� On ne va pas réutiliser un code qui n’est pas maintenable.
Nous nous sommes demandés quels étaientles pré requis majeurs en termes de qualitépour chacune des étapes du cycle. Nousavons utilisé les caractéristiques et souscaractéristiques des 3 modèles précités, cequi nous a permis d’établir les dépen-dances illustrées dans la figure 1.
Notons que nous avons rajouté la caracté-ristique «réutilisabilité» qui est absente dumodèle ISO 9126.
C’est ainsi que cette démarche positionnechronologiquement les attentes relatives àla qualité d’un code source logiciel. La pre-mière caractéristique étant la testabilité etla dernière étant la réutilisabilité. On obtient au final un modèle en couchesreprésenté en figure 2. Ce modèle de basepeut être adapté en fonction du cycle devie prévu pour le code. Notre démarcheétant générique, elle permet par exemple,et si nécessaire, de rajouter des couchescorrespondant à d’autres attentes tellesque la portabilité ou à la sécurité du code.
Partant de ces caractéristiques qualité (oufacteurs) de premier niveau, nous avonscomplété notre modèle par deux niveauxde détails complémentaires. Un niveau desous-caractéristiques et un niveau corres-pondant à des points de contrôle sur lecode. Pour ce faire nous avons utilisé l’ap-proche classique Goal/Question/Metricsde Basili.8 Les points de contrôle précisdépendent des situations, en particulierdes langages et des environnements d'exé-cution du code.
Afin d'identifier les points de contrôle,nous nous sommes référés à la littératureexistante sur le sujet et notamment à lataxonomie très complète établie parDiomodis Spinellis10. Les figures 3 et 4 présentent quelques éléments du modèle qualité complet. Il faut noter que, lorsquenécessaire, nous avons utilisé des souscaractéristiques correspondant à des sousactivités bien précises du cycle de vie du
logiciel. Ainsi la testabilité est décomposéeen testabilité unitaire et testabilité d'inté-gration correspondant aux activités de testunitaire et de test d'intégration. De mêmela maintenabilité est décomposée en lisibi-lité et compréhensibilité car les activités delecture/navigation et de compréhensionsont considérées comme les activités prin-cipales d'un mainteneur amené à travaillersur un code développé par un tiers.
Dans cette construction, une sous-caracté-ristique ou un point de contrôle retenudans le modèle n‘est pas dupliqué dansune couche supérieure. Cette absence deduplication est un point essentiel dumodèle qualité SQALE.
Ceci a pour conséquence, par exemple,qu’aucun critère lié à la testabilité n’appa-raît dans la couche maintenabilité. Il nereste plus que les sous-caractéristiques « lisibilité » et « compréhensibilité » asso-ciées à cette caractéristique. Les sous-carac-téristiques telles que la testabilité ou l’évo-lutivité qui sont traditionnellement asso-ciées à la maintenabilité dans les modèles
qualité cités précédemment, constituentdes couches plus basses du modèleSQALE. C’est la conséquence du fait queces caractéristiques sont nécessaires plusen amont dans le cycle de vie d’un fichierde code source logiciel.
Le modèle qualité SQALE possède égale-ment la propriété importante d’être unmodèle d’exigences. Chaque contrôle pré-sent dans le modèle est une exigence qua-lité à satisfaire. Ceci est en conformité aupremier « Concept absolu » défini par Ph.Crosby7 «Quality must be defined asconformance to requirements.Consequently, the non conformance detec-ted is the absence of quality ». Pour ce faire, les points de contrôles rete-nus dans notre modèle qualité sont des « must » caractérisant sans controverse lescodes sources de qualité. Les exigences debase, ou point de contrôle sont, soit desmétriques avec un seuil précis en deçàduquel le code n’est pas conforme, soit desrègles de codage universellement recon-nues pour leur bien fondé et n’acceptantpas d’exception.
Figure 2 : Les niveaux du modèle qualité “SQALE”
Figure 3 : Un exemple de décomposition en sous-caractéristiques du modèle qualité SQALE
DNV IT Global Services - Enhancing Trust and Confidence in IT3
Réutilisabilité
Maintenabilité
Efficacité
Évolutivité
Fiabilité
Testabilité
Modularité
Transportabilité
Compréhensibilité
Lisibilité
Utilisation de la mémoire
Utilisation du processeur
Évolutivité relative à l’architecture
Évolutivité relative à la logique
Évolutivité relative aux données
Tolérance aux erreurs
Traitement des exceptions
Fiabilité relative à l’architecture
Fiabilité relative à la logique
Fiabilité realative aux instructions
Fiabilité relative aux données
Testabilité au niveau intégration
Testabilité au niveau unitaire
Réutilisabilité
Maintenabilité
Efficacité
Évolutivité
Fiabilité
Testabilité
Réutilisabilité
Maintenabilité
Évolutivité
Efficacité
Fiabilité
Testabilité
Egalement, les exigences proposées se doi-vent d’être non contradictoires entre elles.En effet, il doit être possible, en pratique,de livrer un code sans défaut, en regarddes exigences retenues.
La dernière particularité du modèle qua-lité SQALE que nous avons cité est sa capa-cité à supporter deux points de vue, enl’occurrence, celui du « développeur » etcelui du « propriétaire » comme illustrépar la figure 5.
En lisant le modèle horizontalement, onpeut analyser les non-conformités en fonc-tion de la couche (caractéristique) ou de lasous-couche (sous-caractéristique) àlaquelle ellescorrespondent et visualiserleur impact direct sur une activité de déve-loppement (test, prise en compte des de-mandes d’évolution….).
Pour ce faire, imaginons qu’un chef deprojet souhaite caractériser la maintenabi-lité de son application par une note glo-bale.
Pour établir cette note, il faut agréger desnotes de base. L’agrégation doit se faireselon deux dimensions :
� Selon la hiérarchie des éléments de l’application. La note globale de maintena-bilité de l’application résultant forcément de la maintenabilité de chacun de ses élé-ments et sous éléments (par exemple de chacune des classes, elles mêmes consti-tuées de méthodes).
� Selon le modèle qualité qui a définit les sous caractéristiques qui contribuent à la maintenabilité d’une application (en l’oc-currence la lisibilité et la compréhensibi-lité).
En lisant le modèle verticalement, on peutanalyser les conséquences directes et indi-rectes des non-conformités aux exigencesde bas niveau sur les caractéristiques tellesque la maintenabilité ou la réutilisabilité.
Le modèle d’analyse SQALE
Tout d’abord, illustrons par un exemple lefait que le modèle d’analyse est le point leplus délicat d’une démarche d’évaluationproduit.
Figure 4 : Extrait d’une décomposition du modèle qualité SQALE en points de contrôle
Figure 5 : Les deux points de vue du modèle qualité SQALE
De nombreuses évaluations sont restituéesen se contentant à chaque étape d’agréga-tion de construire les notes en effectuantune moyenne de notes élémentaires. Notessouvent pondérées par des poids cher-chant à prendre en compte, par exemple,l’importance relative des sous-caractéris-tiques ou la taille des fichiers analysés.
Cette approche courante, soutenue par denombreux outils d’analyse de code, n’estpas satisfaisante car elle produit des diag-
nostics erronés et par conséquent amène àde mauvaises décisions.
En continuant sur l’exemple pris, on peutconsidérer que pour s’assurer de la mainte-nabilité de l’application, on va vérifier(sans que cela soit suffisant) que le codesoit bien commenté. En supposant quedans le contexte, le seuil de commentaireait été fixé à 25% par fichier. Si la moitiéde l’application a un taux de commentairede 15% et l’autre moitié un taux de 40%,un système d’agrégation basé sur lamoyenne va donner un taux de commen-taire de 32,5% et par conséquent une noteacceptable pour la maintenabilité globalede l’application.
Malheureusement, et en pratique, ce n’estpas le surcroit de commentaire dans unepartie du code qui aidera à maintenir lapartie où les commentaires font défaut.Chaque partie, pour être maintenable, doitdisposer de commentaires en quantiténécessaire et suffisante.
Le modèle d’analyse SQALE évite ce typede travers.
Comme nous l’avons précisé auparavant,notre modèle qualité est un modèle « d’exigences ». De par la manière dont ila été construit, la qualité visée correspondà une absence totale de non conformités etcomme le précise Ph. Crosby, évaluer uncode source peut se ramener à évaluer ladistance qui le sépare de sa cible qualité.
Pour évaluer cette distance, nous avonsdéfini et implémenté le concept d’indexde remédiation. Cet index associé àchaque constituant du code (par exempleun fichier ou un composant) représentel’effort de remédiation qui serait néces-saire pour corriger les non conformitésconstatées par rapport aux exigences dumodèle.
Comme le concept d’index de remédiation représente une charge de travail, la conso-lidation se fait par simple addition d’infor-mations homogènes, ce qui constitue unavantage important. Un index de compo-sant se calcule par addition des index deses constituants. Un index de caractéris-tique se calcule par addition des index deses sous-caractéristiques. Eux-mêmes sont calculés par addition desindex associés à chaque point de contrôleconcerné.
DNV IT Global Services - Enhancing Trust and Confidence in IT4
Maintenabilité Compréhensibilité Les méthodes ont une complexité essentielle ev(G) <=5
Maintenabilité Compréhensibilité Il n’y a pas d’instruction ‘continue’
Maintenabilité Compréhensibilité Il n’y a pas d’instruction ‘break’ en dehors d’un block ‘switch’
Maintenabilité Compréhensibilité Le taux de commentaire de chaque fichier est > 25%
Maintenabilité Lisibilité Les accolades fermentes ‘�’ sont seules sur une ligne
Maintenabilité Lisibilité Il n’y a pas d’instruction mise en commentaire
Une vue analytique fournie par des
caractéristiques orthogonales
Représentation de l’impact de chaque
non-conformité et amélioration sur les
caractéristiques qualité et sur le cycle
de vie
Une vue externe représentant la qualité
perçue évaluée par la consolidation de
la hiérarchie des caractéristiques
des points de contrôles à base demétriques orientées objet pour évaluer parexemple la testabilité, l’évolutivité, et laréutilisabilité.
Il comprend aussi le contrôle de l’absenced’“anti patterns” tels par exemple ceuxidentifiés par Brown10.
Les index sont calculés en fonction descoûts moyens de remédiation estimés parl’équipe de développement. Les seuils d’in-dex permettant de faire une cotation en 5niveaux (de mauvais à excellent) sont pro-posés par les responsables en charge del’application.
Pour restituer efficacement les forces et lesfaiblesses du code évalué nous utilisons des
graphes permettant de bien visualiser :� Dans quelle partie du code il y a le plus de risques.
� Quels critères qualités sont les plus concernés.
� Quel est l’impact direct des non conformités constatées.
Nous présentons ici (Figures 6 et 7)quelques uns des indicateurs que nous uti-lisons dans nos restitutions et qui selonnotre expérience donnent une bonne visi-bilité et un bon pouvoir de décision à nosinterlocuteurs chefs de projet.
Dans le cas de l’application présentée enexemple, l’index de testabilité est élevé.
Figure 6 : Graphe de synthèse des index de l’application entièreLes index de base sont attribués selon desrègles qui respectent lesprincipes suivants :
� Ils prennent en compte le coût unitaire de remédiation dechaque non-confor-mité. Coût qui dépendprincipalement de satypologie.
Corriger un problème de présentation (mau-vaise indentation, sup-pression de code mort) n’a pas le même coût unitaire qu’une correc-tion qui implique la création et l’exécution de nouveaux tests uni-taires, voir des tests d’in-tégration et des tests de non régression.
� Ils prennent en compte le nombre d’occurences des non-conformités. Par exemple un fichier qui a trois méthodes nécessitant d’être décou-pées car trop complexes aura un index tri-ple qu’un fichier contenant une seuleméthode trop complexe, toutes choses étant égales par ailleurs.
Finalement, les index de remédiation per-mettent de mesurer et de comparer à tra-vers une mesure commune (de type coût)des non conformités d’origine et de typetrès différents. Des non conformités de typeviolation de règle de codage, de type dépas-sement de seuil pour une métrique ou pré-sence d’un “anti pattern” pourront êtrecomparées à travers leurs impacts relatifssur la valeur de l’index.
Utilisation concrète
Nous avons utilisé les modèles qualité etd’analyse SQALE pour effectuer de nom-breuses évaluations de code source detoutes tailles et dans de nombreux domai-nes.
Que ce soit des applications Cobol, Java oudes applications embarquées en Ada ouC++, nous avons utilisé le même modèlequalité en couche. Dans le cas des applications en Java, Ada etC++, le modèle qualité comprend, bien sûr,
Beaucoup
d’évaluations
de code
reposent sur un
système
d’aggrégation
par moyenne.
Cette approche
n’est pas
satisfaisante,
elle produit des
diagnostics
erronés et par
conséquent
amène à de
mauvaises
décisions. Figure 7 : Répartition des fichiers en fonction de leur index pour chaque caractéristique qualité
DNV IT Global Services - Enhancing Trust and Confidence in IT5
131
559
118
772
151
6 535
8 266
131
118
772
151
6 535
8 135
118
118
772
151
6 535
7 458
151
6 535
6 686
6 535
6 535
Testabilité Fiabilité Évolutivité Efficacité Maintenabilité Réutilisabilité
Réutilisabilité
Maintenabilité
Efficacité
Évolutivité
Fiabilité
Testabilité
Réutilisabilité
Maintenabilité
Efficacité
Évolutivité
Fiabilité
Testabilité
0% 20% 40% 60% 80% 100%
De ce fait, les autres caractéristiquesexternes ne peuvent être satisfaites (ouapprochées). Ceci malgré la relative bonneconformité aux points de contrôle relatifsaux caractéristiques de plus haut niveau. Legraphe présente un constat qui peut sem-bler paradoxal.
En effet, pour améliorer notablement lamaintenabilité perçue par le « proprié-taire » de l’application, il est préférable etplus efficace d’améliorer la testabilité quede rajouter des commentaires.
Les indicateurs d’analyse mentionnés ontpermis de localiser précisément les modifi-cations prioritaires à apporter pour aug-menter la testabilité et par conséquent laqualité générale de l’application. L’analysede la densité d’index (telle que présentéepar exemple en figure 8) a aussi permis decomparer la distribution des non-conformi-tés ente les fichiers de code réutilisés (R),modifiés (M) et créés (C).
Conclusion
Plus qu’un modèle qualité, nous proposonsune démarche générique pour développerdes modèles qualité déduit du cycle de viedu logiciel et par conséquent permettantde bien spécifier les attentes relative à laqualité du code. Les modèles ainsi obtenuslèvent un certain nombre de faiblesses asso-ciées aux modèles faisant actuellementréférence.
Les modèles qualité développés selon laméthode SQALE ont la particularité deprésenter deux ressemblances avec lemodèle CMMI. D’une part, comme celui-ci,ils organisent les exigences en niveaux cor-respondant à une logique de priorité.
D’autre part, comme le modèle CMMI quel’on peut utiliser pour évaluer la maturitéou la capacité, on peut utiliser les modèlesqualité SQALE pour évaluer le code sourcede façon analytique ou selon le point devue externe d’un utilisateur ou du proprié-taire du code.
Ces similitudes des modèles et des métho-des d’évaluation permettent de mener rapi-dement et efficacement des évaluationsconjointes processus/produit apportantune forte valeur ajoutée.
DNV IT Global Services - Enhancing Trust and Confidence in IT6
Références
1. SEI, CMMI for Acquisition Version 1.2, CMU/SEI 2007-TR-017, Carnegie Mellon University, Pittsburg,2007
2. SEI, CMMI for Development Version 1.2, CMU/SEI-2006-TR-008, Carnegie Mellon University, Pittsburgh,2006
3. ISO/IEC, International Standard, «ISO/IEC 15939: 2007 (E), Systems and software engineering –Measurement process, 2007
4. Boehm, B. W., Brown, J. R., Kaspar, H., Lipow, M., McLeod, G., and Merrit, M., Characteristics of SoftwareQuality, North Holland, 1978
5. McCall, J. A., Richards, P. K., and Walters, G.F., Factors in Software Quality, The National TechnicalInformation Service, No. Vol 1, 2 and 3, 1977
6. ISO, International Organization for Standardization, «9126-1:2001, Software engineering – Product qua-lity, Part 1: Quality model», 2001
7. Crosby, P. B., Quality is free: the art of making quality certain, New York: McGraw-Hill, 19798. Victor Basili, Software Modeling and Measurement: The Goal/Question/ Metric Paradigm. Technical
report. University of Maryland at College Park, 19929. Diomidis Spinellis, Code Quality The Open Source Perspective, ISBN: 0-321-16607-8, Addison-Wesley,
200610. Brown et al, Anti Patterns: Refactoring Software, Architectures and Projects in Crisis, ISBN:978-0-471-
19713, John Wiley, 1998
TESTABILITÉ R M C
Testabilité au niveau unitaire 4 130 970 495
Testabilité au niveau intégration 835 105 -
TOTAL 4 965 1 074 495
Figure 8 : Graphe de distribution des index et de leur densité
M
16%
R
76%
0,350
0,300
0,250
0,200
0,150
0,100
0,050
-R M C
0,173
0,330
0,195
C
8%
Index Distribution Index Density by v(G)
Le kit de découverte SQALE
Découvrez les principes fondamentaux et les bénéfices de la méthode SQALEavec notre “kit de découverte SQALE”. Ce kit contient :
- Une formation d’un jour à la méthode SQALE - L’identification (à travers quelques entretiens) des principaux “cas d’utilisation” de l’analyse
de code dans le contexte de votre organisation- Le développement (à l’aide d’ateliers dédiés) de vos propres modèles qualité et d’analyse.
Ces modèles seront adaptés à votre environnement et serviront de références pour définir et évaluer la qualité de votre code source (pour l’un des langages suivants : Java, C, C++, C#, Cobol)
- L’évaluation concrète d’une de vos applications avec la méthode SQALE et vos propres modèles qualité et d’analyse (vous recevrez un rapport d’évaluation détaillé)
- Un atelier sur l’interprétation et l’utilisation des résultats.
Les livrables de la prestation sont :- Votre modèle qualité et votre modèle d’analyse pour un langage de développement- Un rapport d’évaluation- Une liste d’actions directrices.
Durée totale : environ 20 jours
Auteurs : Jean-Louis Letouzey et Thierry Coq
À propos de DNV IT Global Services
DNV IT Global Services aide les entreprises et organismes des secteurs des services financiers, des télécommuni-cations, des services publics, de la défense, de l’aérospatiale et de l’automobile à mieux gérer les risques informa-tiques en améliorant l’efficacité et la prévisibilité de leurs processus et logiciels, ainsi que la gestion de l'informa-tion. Basé à Paris, DNV IT Global Services s’appuie sur une équipe de 300 consultants, ingénieurs et spécialistesde la formation répartis dans les principaux pays européens.
Contact :
Alain [email protected]
Le Visium22 avenue Aristide Briand CS 9000194742 Arcueil Cedex FranceTél : +33 (0)1 49 08 58 00
www.dnv.com/itgsVersion 3