Aide à la sélection d’un projet Open Source

Méthodologie QualOSS

Aide à la sélection d’un projet Open Source

Méthodologie QualOSS

Le projet européen QualOSS a permis d’élaborer une méthodologie d’évaluation de la robustesse et de la capacité d’évolution de projets Open Source, sur base d’une analyse de ses éléments (code source, documentation, matériel de test) mais aussi sur base du comportement de la communauté développant le projet ainsi que de sa méthode de travail. Cette méthode se caractérise par sa facilité d’adaptation à différents scénarios d’acquisition du logiciel mais aussi par le nombre important d’aspects pris en considération. Elle a été appliquée à plusieurs reprises avec succès dans un cadre industriel.

Contexte du projet

Dans notre newsletter de mars 2009, nous avons présenté QualOSS, un projet de recherche européen mené par le CETIC, dont le but est de développer une approche d’évaluation systématique des risques liés à l’acquisition de projets Open Source.

L’acquisition d’un logiciel Open Source se décide non seulement sur base du logiciel lui-même mais aussi sur base de la confiance attribuée à l’initiative de développement libre qui produit ce logiciel. Ainsi la méthodologie QualOSS s’intéresse non seulement au composant logiciel produit par l’initiative, mais aussi à la communauté de contributeurs impliqués dans cette initiative, aux processus de développement et de support utilisés par ces contributeurs, ainsi qu’aux éventuelles dépendances à d’autres initiatives de développement libre.

L’importance à accorder aux différents éléments dépend du scénario d’acquisition du logiciel :

  • Exploitation simple : une entreprise veut déployer un logiciel libre sur l’ordinateur de ses employés et leur payer des formations pour bien maîtriser le logiciel ; l’évaluation de la documentation disponible et du support fourni par la communauté est alors particulièrement importante.
  • Fourche : une entreprise veut intégrer un logiciel dans un de ses produits mais ne collaborera pas avec l’initiative qui l’a développé ; elle choisit de créer une initiative de développement interne sur base du code du projet Open Source (fourche). Dans ce cas, la priorité principale est à l’évaluation du logiciel lui-même, notamment du code.
  • Reprise d’une initiative : une entreprise veut prendre le contrôle d’une initiative de développement libre existante afin de diriger l’évolution du logiciel libre et de s’assurer qu’il est et restera rapidement intégrable à ses produits ; dans ce cas, le produit logiciel mais aussi ses éventuelles dépendances fonctionnelles vis à vis d’autres projets Open Source sont particulièrement importantes.
  • Collaboration complète : une entreprise veut intégrer un logiciel dans un de ses produits tout en gardant la ligne de collaboration ouverte avec l’initiative de développement libre. Tous les aspects (produits, communauté, processus et dépendances) doivent alors être pris en considération.

L’évaluation de ces éléments se fait sur base de questions concrètes que se posent les membres de l’entreprise désirant acquérir le logiciel, avec des points de vue qui peuvent différer suivant leur rôle (chef de projet, développeur...). Un ensemble de mesures précises permet de donner une réponse à chacune de ces questions sous forme d’un indicateur de risque qui peut prendre une valeur de 0 à 4 et auquel on associe une couleur pour faciliter la visualisation des résultats :

Ces indicateurs peuvent alors être combinés (moyenne pondérée) de façon à donner une vue d’ensemble.

Plus de détails sur la méthodologie d’évaluation QualOSS peuvent être trouvés dans le rapport final du projet.

Cette méthodologie a été expérimentée plusieurs fois avec succès dans un cadre industriel grâce aux études de cas décrites ci-après. La première étude de cas illustre la méthodologie de façon plus détaillée.

Evaluation du projet Asterisk pour la société Freecode

La première étude de cas concerne l’évaluation du projet Asterisk (logiciel de téléphonie) pour la société Freecode, une société norvégienne d’intégration de produit Open Source. Actuellement, Freecode utilise la méthode OpenBRR pour évaluer les projets Open Source mais la société n’est pas entièrement satisfaite et envisage de passer à une nouvelle méthode d’évaluation qui permettra d’obtenir une information plus complète.

Voici un extrait des résultats obtenus en utilisant la méthode d’évaluation standard QualOSS (la version intégrale des résultats d’évaluation sont disponibles en ligne - sélectionner la version 1.1 puis le projet Asterisk).

Tout d’abord, un résumé du contexte et du but de l’évaluation est présenté comme le montre l’exemple suivant où l’on voit apparaître notamment le nom et la version du projet (point 3.1), le scénario envisagé d’acquisition (point 3.2), les différents rôles intéressés par l’acquisition (point 4) ainsi que les éléments du projet qui feront l’objet d’une évaluation (point 5).

Ensuite, un résumé de l’évaluation est donné par un tableau mentionnant le niveau de risque global pour le projet ainsi que le risque associé à différents indicateurs de qualité (il est possible d’inclure ou d’exclure certains attributs de qualité dans l’évaluation globale) :

Enfin, en cliquant sur un attribut de qualité particulier, le modèle donne une information détaillée, à savoir le risque associé à chacune des questions relatives à cet attribut de qualité :

Les résultats de cette évaluation ont impressionné les responsables de la société Freecode par le grand nombre de mesures et l’abondance de l’information fournie. Après avoir passé en revue les questions et les indicateurs de risque, ils ont considéré que la plupart leur étaient utiles et que l’analyse QualOSS fournissaient une information plus complète que celle apportée par la méthode OpenBRR.

Evaluation de GCC-backend pour la société AdaCore

AdaCore utilise le composant back-end de GCC (GNU Compiler Collection) dans le cadre de son produit phare, le compilateur GNAT pour Ada pour lequel la robustesse et la fiabilité sont d’une importance primordiale. Une mise à niveau régulière vers les nouvelles versions de GCC est nécessaire et le processus de sélection de cette nouvelle version est essentiel.

La méthodologie QualOSS a été appliquée à 2 versions du GCC-backend (4.2 et 4.3) afin de permettre la comparaison de ces 2 versions.

AdaCore avait la connaissance préalable du fait que la version 4.2 a introduit de nouvelles fonctionnalités importantes qui ont affaibli le niveau de fiabilité de GCC-backend. Les responsables d’Adacore voulaient vérifier que les indicateurs de résultats de l’évaluation QualOSS permettaient également d’identifier ce fait.

AdaCore a constaté que les résultats d’évaluation de code ont été très utiles pour confirmer leurs attentes. Cette étude a également révélé qu’aucun rapport de couverture de test n’est disponible. AdaCore prévoit maintenant d’utiliser certains indicateurs QualOSS pour vérifier la pertinence d’intégrer une nouvelle version de GCC-backend dans le compilateur GNAT.

Evaluation d’outils logiciels de couverture de tests pour la société AdaCore

AdaCore, en collaboration avec la société Open Wide, l’Ecole Nationale Supérieure des Télécommunications (ENST) et le Laboratoire d’Informatique de Paris 6 (LIP6), développe le projet "Couverture", un ensemble d’outils logiciels libres qui analysent la couverture de tests. En plus des outils, le projet vise à générer des artefacts qui permettent d’utiliser ces outils dans le cadre de logiciels critiques soumis à un audit de vérification (DO-178B).

Le projet suivant la philosophie Open Source, AdaCore a utilisé la méthodologie QualOSS pour analyser et comprendre ce qui pourrait contribuer à rendre le projet Couverture robuste et évolutif tout en l’intégrant dans une forge ouverte au public.

Dans le cadre de cette évaluation, les commentaires concernant l’évaluation des tests et des processus ont été très positifs. Sur la base de ces résultats, AdaCore a identifié des actions prioritaires pour améliorer leurs indicateurs de risque pour ces deux parties de l’évaluation.

Evaluation du client d’impression yanolc pour la société Océ Software Laboratories

Une dernière étude de cas a consisté à évaluer le composant client de l’initiative Open Source yanolc afin d’aider Océ Software Laboratories (OSL) à déterminer s’il était plus intéressant de délivrer un nouveau client lpr (destiné à communiquer avec un dispositif d’impression) soit sur base de composants déjà développés chez OSL, soit sur base du code de yanolc.

OSL a considéré que l’évaluation QualOSS répondait aux questions pertinentes dans le cadre de cette décision - notamment en ce qui concerne l’évaluation de la maintenabilité et de la documentation. OSL a noté que de nombreuses questions posées par la méthodologie QualOSS n’ont pu recevoir de réponse car aucune donnée n’était disponible sur les incidents (absence de bugtracker) et a considéré ce manque d’information comme un risque important. En fin de compte, OSL a décidé de mettre en œuvre le client lpr en utilisant ses composants internes.

Conclusion

Les différentes études de cas réalisées durant le projet QualOSS ont confirmé le bénéfice de la méthodologie QualOSS pour guider le choix d’un projet Open Source dans le cadre de différents scénarios d’acquisition, et ce dans un environnement industriel.

Quelques informations sur le projet

- QualOSS, Quality in Open Source Software
- Durée : 2006-2009
- Partenaires : AdaCore, Facultés Universitaires Notre-Dame de la Paix de Namur (FUNDP), Fraunhofer IESE, Maastricht Economic and Social Research and Training, Centre on Innovation and Technology (MERIT), PEPITe, Universidad Rey Juan Carlos, ZEA Partners
- Site web : http://www.qualoss.org/