Modèles d’évaluation de la maturité pour les logiciels FLOSS

La structure spécifique des organisations développant des logiciels FLOSS ne permet pas de s’appuyer sur CMMI pour évaluer la maturité des offres FLOSS. Les modèles Open Source Maturity Model de Cap Gemini, ou de Navica, QSOS d’Atos, OpenBRR et QualiPSo présentés dans les paragraphes suivants prennent en compte les spécificités des logiciels FLOSS.

Open Source Maturity Model (OSMM) de la société Cap Gemini a été développé en 2003. Ce modèle repose sur douze critères, notés de un à cinq, répartis en quatre catégories 28[28].

L’évaluation du produit se base sur l’âge du produit, le type de licence, le degré de hiérarchie au sein des développeurs, les points forts de l’outil et la communauté de développeurs. L’intégration de la solution est jugée sur sa modularité et sa capacité à s’interfacer avec d’autres produits. Ensuite, la facilité d’utilisation est estimée à partir des standards utilisés et des offres de support. Enfin, la facilité d’adoption de la solution est examinée d’après la facilité de déploiement, la communauté des utilisateurs ainsi que la pénétration du marché. Cette méthode d’évaluation étant soumise à une licence payante, elle ne sera pas étudiée plus amplement.

En 2004, B. Golden 29[29] dirigeant de la société Navica a publié un OSMM concurrent.

L’évaluation d’une solution libre repose sur les six éléments clés suivants : la solution logicielle, l’offre de support, la documentation, l’offre de formation, la capacité d’intégration du produit et l’offre de services. La note de chacun de ces sujets est construite en quatre étapes. La première phase consiste à déterminer les besoins. Puis, il faut déterminer les ressources disponibles sur le produit, en contactant les développeurs, les organismes partenaires, etc. Ensuite, il faut évaluer la maturité de l’élément étudié. Chacun des chapitres dispose de ses propres critères de maturité. Ainsi, le modèle propose de considérer par exemple la pérennité, la qualité de la solution logicielle, les différents types de support, la présence de tutoriaux ou encore les différents moyens de formation disponibles. La dernière étape est d’attribuer une note sur une échelle de un à dix. Les différentes catégories clés ont des pondérations par défaut qu’il est possible d’ajuster en fonction des besoins et de la marge de risque acceptable. Suite à ces différentes étapes, une note est calculée pour chaque élément clé permettant d’estimer la maturité de tout l’environnement de la solution libre étudiée. Ce modèle reposant uniquement sur la publication réalisée par une seule personne et la société Navica n’existant plus, il a été abandonné. De ce fait, il ne peut pas être utilisé pour la présente étude.

[28] F.-W. Duijnhouwer, C. Duijnhouwer. Open Source. Maturity Model, Capgemini Expert Letter, 2003 [29] B. Golden. Succeeding with Open Source. Addison-Wesley Professional, 272 pages, 2004

En 2004, la société Atos a développé la méthode de qualification et de sélection de logiciels Open Source (QSOS) 30[30]. Elle repose sur un processus itératif composé de quatre étapes.

La première phase « Définir » a pour objectif de définir la typologie de la solution logicielle au niveau de la licence et de la communauté. La seconde phase « Evaluer » est la constitution des fiches d’identité des outils ainsi que des fiches d’évaluation. La notation est réalisée sur des critères répartis selon les axes de couverture fonctionnelle, de risque utilisateur et éventuellement du risque du point de vue du prestataire de service si l’étude est réalisée par une société de services. Le processus étant itératif, le niveau de granularité des critères d’évaluation peut être affiné en trois itérations. Ainsi l’évaluation est faite au niveau des cinq catégories principales pour la première, au niveau des sous-catégories pour la seconde et au niveau des critères le plus fins pour la dernière. La troisième phase du processus « Qualifier » permet d’ajuster les critères au contexte. Ainsi, pour la couverture fonctionnelle l’objectif est d’affecter un niveau d’exigence à chaque fonctionnalité (requise, optionnelle ou non requise) et pour les risques utilisateurs de définir le degré de pertinence des critères. La quatrième phase « Sélectionner » permet de faire le choix d’un outil en se basant sur les critères définis précédemment.

Atos Origin fournit un outil qui permet d’assister l’utilisateur dans l’exécution des différentes étapes et de générer des graphiques facilitant la comparaison des solutions Open Source. Par ailleurs, la méthode étant sous licence GNU Free Documentation, les documents générés avec QSOS et ses outils sont également soumis à ce type de licence.

[30] R. Semeteys, O. Pilot, L. Baudrillard, G. Le Bouder. Méthode de Qualification et de Sélection de logiciels Open



)LJXUH3URFHVVXVLWpUDWLIGHTXDOLILFDWLRQHWGHVpOHFWLRQGHORJLFLHOV2SHQ6RXUFH4626 VRXUFHKWWSZZZTVRVRUJ

(QO¶XQLYHUVLWpGH&DUQHJLH0HOORQ6LOLFRQ9DOOH\OHVVRFLpWpV6SLNH6RXUFH25HLOO\ HW ,QWHO RQW GpEXWp OD UpGDFWLRQ GH OD PpWKRGH %XVLQHVV 5HDGLQHVV 5DWLQJ IRU 2SHQ 6RXUFH

2SHQ%55>@$O¶LQVWDUGH46262SHQ%55HVWXQHPpWKRGHHQTXDWUHpWDSHVIDFLOHjPHWWUHHQ

°XYUH /D SUHPLqUH SKDVH ©(YDOXDWLRQ UDSLGHª SHUPHW GH ILOWUHU OHV VROXWLRQV FDQGLGDWHV HQ IRQFWLRQGHFULWqUHVGHOLFHQFHHWGHYLDELOLWpIRXUQLVSDUODPpWKRGH/DVHFRQGHSKDVH©(YDOXDWLRQ GHO¶XWLOLVDWLRQFLEOHª DSRXUREMHFWLIGHOLVWHUHWSRQGpUHUO¶HQVHPEOHGHVFULWqUHVjpYDOXHU3RXU FHODODPpWKRGHIRXUQLWGRX]HFDWpJRULHVTX¶LOIDXWFODVVHUSDURUGUHG¶LPSRUWDQFH(QVXLWHLOIDXW DIIHFWHU XQ SRLGV DX[ VHSW SUHPLqUHV OHV VXLYDQWHV Q¶pWDQW SDV XWLOLVpHV (QVXLWH SRXU FKDTXH FDWpJRULHLOIDXWSURFpGHUFRPPHSUpFpGHPPHQWGRQFFODVVHUOHVFULWqUHVSDURUGUHG¶LPSRUWDQFH YLVjYLVGHVEHVRLQVPpWLHUVHWOHXUDIIHFWHUXQSRLGV/DWURLVLqPHSKDVH©&ROOHFWHGHVGRQQpHVHW WUDLWHPHQWª YLVH j UpXQLU OHV LQIRUPDWLRQV VXU OHV RXWLOV SRXU FKDTXH FULWqUH VpOHFWLRQQp j O¶pWDSH SUpFpGHQWH SXLV j FDOFXOHU XQH QRWH HQ DSSOLTXDQW OD SRQGpUDWLRQ /D GHUQLqUH SKDVH ©7UDGXFWLRQ GHVGRQQpHVªUHTXLHUWG¶XWLOLVHUOHVQRWHVREWHQXHVSDUFKDTXHFULWqUHSRXUFDOFXOHUXQHQRWHJOREDOH SRXU FKDFXQH GHV FDWpJRULHV VpOHFWLRQQpHV j OD VHFRQGH pWDSH &H VFRUH SHUPHW G¶pWDEOLU OH WDX[ G¶DGpTXDWLRQDXPpWLHU%55©%XVLQHVVUHDGLQHVVUDWLQJªHQDQJODLV&HSHQGDQWODPpWKRGHHVW HQFRUH j O¶pWDW GH ©5HTXHVW )RU &RPPHQWª HW DXFXQH SXEOLFDWLRQ SOXV UpFHQWH TXH OD SUHPLqUH YHUVLRQQ¶HVWGLVSRQLEOH'HFHIDLWOHVFULWqUHVGHPDWXULWpWHOVTX¶pYRTXpVSDUFHWWHPrPHPpWKRGH WHQGHQWjDYHUWLUG¶XQULVTXHIRUWTXDQWjVDYLDELOLWp'HFHIDLWLOHVWSUpIpUDEOHGHQHSDVO¶XWLOLVHU



>@$:DVVHUPDQ03DO&&KDQ%XVLQHVV5HDGLQHVV5DWLQJIRU2SHQ6RXUFH%55:KLWHSDSHU5HTXHVW)RU

Le consortium « Quality Platform for Open Source Software » (QualiPSo) fut fondé en 2006 par la Commission Européenne au travers de son sixième programme cadre des technologies de l’information (FP6 IST) « Information Society Technologies: thematic priority under the specific program "Integrating and strengthening the European research area" (2002-2006) » auxquels se sont joints des entreprises telles qu’Atos Origin et des organismes gouvernementaux européens, brésilien et chinois, dont la gendarmerie nationale française et l’Institut National de Recherche en Informatique et Automatique (INRIA). QualiPSo, qui compte actuellement dix-huit participants, a pour objectifs de développer des méthodologies, des processus et des outils pour les projets Open Source et ainsi se rapprocher des exigences de qualité des solutions propriétaires pour donner confiance dans ces solutions aux clients potentiels. Dans ce cadre, QualiPSo a conçu une certification de qualité et de maturité OpenSource Maturity Model (OMM) dérivée de CMMI et adaptée aux organisations virtuelles qui ne dépendent pas d’infrastructures et/ou d’outillages formels. OMM ne se focalise donc pas sur les processus de l’organisation mais sur douze éléments qui peuvent donner confiance (en anglais : (TWE : « Trustworthy elements » en anglais) dont certains sont extraits ou inspirés de CMMI 32[32] :

1. Documentation du produit (PDOC) correspondant au paragraphe SP 3.2 « Développer la documentation de soutien au produit » du domaine de processus « Solution technique » du niveau 3 de maturité CMMI [25],

2. Popularité du produit (REP),

3. Standards établis et répandus (STD) correspondant au domaine de processus CMMI « Assurance qualité processus et produit » du niveau 2 de maturité CMMI [25],

4. Feuille de route du produit (RDMP : « roadmap » en anglais) évoqué dans CMMI aux paragraphes SP 2.1 « Établir les exigences produit et composants de produit » du domaine de processus « Développement des exigences » et SP 1.1 « Établir une stratégie d’intégration » du domaine de processus « Intégration de produit » du niveau 3 de maturité CMMI [25],

5. Plan de tests de la qualité (QTP) correspondant au paragraphe SP 1.3 « Établir les procédures et les critères de vérification » du domaine de processus « Vérification » du niveau 3 de maturité CMMI [25],

6. Relations entre les parties prenantes (STK : « stakeholder » en anglais) correspondant aux paragraphes SP 2.6 « Prévoir l’implication des parties prenantes » du domaine de processus « Planification de projet » du niveau 2 de maturité CMMI [25] et SP 2.1 « Gérer l’implication

[32] M. Wittmann, R. Nambakam, G. Ruffati, S. Oltolina, E. Petrinja, F. Ortega, V. Malheiros, D. Tosi. Working

des parties prenantes » du domaine de processus « Gestion de projet intégrée » du niveau 3 de maturité CMMI [25],

7. Licences (LCS),

8. Environnement technique (ENV) correspondant aux paragraphes SP 2.4 « Prévoir les ressources du projet » du domaine de processus « Planification de projet » du niveau 2 de maturité CMMI [25] et SP 2.1« Gérer l’implication des parties prenantes » du domaine de processus « Gestion de projet intégrée » du niveau 3 de maturité CMMI [25],

9. Nombre de validations et de bugs rapportés (DFCT),

10. Maintenabilité et stabilité (MST) correspondant aux paragraphes SP 1.2 « Transformer les besoins des parties prenantes en exigences client » du domaine de processus « Développement des exigences » et SP 2.1 « Concevoir le produit ou le composant de produit » du domaine de processus « Solution technique » du niveau 3 de maturité CMMI [25],

11. Contribution de sociétés de logiciels commerciaux dans le développement de logiciels libres (CONT),

12. Résultats d’évaluation du produit par une société tierce (RASM).

Figure 80 - Echelle de maturité à trois niveaux de QualiPSo

Comme le montrent ces éléments d’évaluation, le modèle de maturité de QualiPSo est destiné aux organisations qui produisent des outils Open Source ou qui les auditent dans un objectif d’amélioration des activités connexes au développement. Si l’organisation qui gère le projet libre applique ce modèle, alors le résultat peut être utilisé pour évaluer le produit et son environnement. Dans le cas contraire, il n’est pas opportun d’envisager ce moyen pour sélectionner des produits.

Comme aucune solution candidate pour le projet IAM n’a été examinée via le modèle de maturité de QualiPSo, il ne peut donc pas être utilisé pour les comparer. Aussi, parmi les cinq modèles d’évaluation seul QSOS est finalement utilisable.

V.4.4 Evaluation par la méthode QSOS