Souscrire via RSSLa qualité dans un projet logiciel : mythe ou réalité ?
Les développements de projets Open Source sont connus et reconnus pour leur qualité : l’argument établis est que du fait de la publication du code, la qualité étant visible de tous, les développeurs auront tendance à prêter attention à la qualité du code. D’autres arguments existent : un projet communautaire (dont les développeurs ont chacun une vision et un objectif propre) se doit d’être irréprochable en matière de développement. Comment peut-on montrer ou démontrer la qualité d’un code ou d’un projet ? La question se pose aussi pour les données, mais j’y reviendrai plus tard dans un autre billet.
Différents paramètres sont parfois pris en compte comme le nombre de développeurs, d’utilisateur, le dynamisme des commits. Des services sont alors apparus comme ohloh, voir la page sur MapServer par exemple, se basant justement sur ce genre de paramètres. Ces méthodes ont des limites, je doute qu’il y ait seulement 103 utilisateurs de MapServer dans le monde, mais donnent un aperçu intéressant des projets (open source). Les listes de diffusion donnent également un aperçu : répond on à des questions (de difficulté diverse) ? Y a t’il des services commerciaux de formation et de support derrière ces projets ?
On le voit, la qualité d’un projet est difficile à juger et à industrialiser, et une première réponse serait : on ne peut pas juger la qualité d’un projet industriellement, une analyse finale, humaine, sera toujours obligatoire. Différents projets indépendants ont vue le jour autour de la qualité des projets : Qualipso, FLOSSmétric pour des projets orienté méthodologie, Sonar pour des projets d’application. Sans le vouloir je viens déjà de découper la notion de qualité d’un projet en deux catégories ! En effet, la qualité d’un projet ne porte pas forcément sur la qualité du code comme mon introduction le laisser supposer, la qualité d’un projet porte aussi sur tout ce qui tourne autour : formation, documentation, support, gestion du projet, etc.
D’un point de vue méthodologique les deux projets cités sont des projets eux-mêmes peu dynamique… Ont il tiré les leçons de leur analyse ? Blague à part revenons à notre sujet.
Qualipso est une entité constituée de plusieurs grosses sociétés de l’IT dont Bull, Mandriva, ATOS Origine (parmi 18 autres, provenant de Chine, du Brésil et d’Europe) dont l’objectif est de rendre les projets plus sûr (dans le sens de ‘peut on s’appuyer dessus ?‘) : d’un point de vue technique (qualité, maturité), juridique (licence, brevet), etc.. Ce projet est financé en partie par l’Union Européenne. De mon point de vue cela ressemble à une tentative de certification (donc un peu marketing) dont l’objectif est de montrer à ceux qui doutent encore de la pertinence de l’open source (c’est à dire les gros décideurs). Mais il y a un autre intérêt : leur objectif était de définir une check-liste de tâches qui prises dans leur ensemble permettrait de juger de la qualité d’un projet. Cette checklist me parait pertinente à deux points de vue : d’abord elle permet de définir pour un gestionnaire de projet les tâches à accomplir pour améliorer son projet, mais elle permet également à des utilisateurs de juger de la qualité d’un projet.
FLOSSmétric avait pour ambition de réunir des informations sur des projets Open Source en utilisant des outils et des process déjà définie. Parmi les projets suivi on trouvera GDAL-OGR, QGIS, uDIG, PostgreSQL, MySQL. À l’heure actuelle je n’ai pas réussit à trouver plus d’informations sur les données mesurées.
Les outils de mesure de la qualité du code me semble plus mature car cela fait déjà un moment qu’ils ont été définie afin d’améliorer la qualité du code : tests unitaires et fonctionnels, process de développement et de publication des versions, gestion des projets.
Sonar que j’ai eut l’occasion de découvrir via un article de Linux Magazine France (n°134) m’a plus particulièrement intéressé : utile à la fois aux développeurs à qui ils permet d’obtenir un suivie du projet mais aussi aux utilisateurs qui auront ainsi une visualisation de la qualité du projet (et son évolution) en fonction des objectifs que ce sont données les développeurs (commentaires dans le code, suivie des règles de développements, etc.), en effet ce sont les développeurs qui fixeront les objectifs et par conséquent les règles d’analyse de Sonar.
L’OSGeo a mis en place une procédure d’incubation afin de s’assurer de la qualité du projet. Le terme de qualité porte plus sur le projet que sur le code en lui même dans la mesure ou cette phase d’incubation met l’accent sur la présence de procédure formaliser pour la publication du code, la gestion du projet (qui fait quoi par exemple) et sur les aspects légaux (auteurs du code bien définie, par de problème de brevet, etc.)
On le voit ici, le terme de qualité porte sur des paramètres tellement différents qu’il est encore difficile de s’y retrouver mais une chose est sur il ne s’agit plus seulement de faire de la qualité mais de le montrer aussi !
6 Commentaires
21 Fév 2011 - 12:02:23Pour l’évaluation de l’environnement du projet, j’avais aussi en tête la grille d’évaluation du projet Cascadoss http://www.cascadoss.eu/en/index.php?option=com_content&task=view&id=68 qui rejoint ton point de vue.
Même si le code est important pour la maintenabilité du projet, il y a tant d’autres critères.
« Les développements de projets Open Source sont connus et reconnus pour leur qualité » : On peut se jeter des fleurs, ça ne mange pas de pain. Parlons plutôt de la loi de Linus qui stipule qu’à partir qu’au delà d’un nombre critique de contributeurs la qualité d’un projet libre est présente. C’est dit à demi-mot par la suite, mais ce sont plutôt les projets open source dynamiques dont la qualité est le plus souvent reconnus, encore que ce terme de dynamisme est propre à interprétation, une publication (release) mensuelle n’est pas forcément révélateur d’un projet de qualité, même s’il s’agit d’une méthode reconnue pour découvrir les bugs !
Le processus d’incubation est déjà une forme de certification OSGEO.
Depuis que je suis de plus ou moins près l’actualité de gdal, je retiens deux retraits importants de version de cette bibliothèque / suite d’utilitaires : un concernant un problème d’encodage de la grille de conversion IGN GR3DF97A rendant inadéquate l’utilisation de cette grille dans les reprojection, et un autre concernant la version 1.7.0 et une incompatibilité des formats Erdas avec le logiciel Erdas et tous les autres logiciels non basé sur gdal !
Je ne reproche pas l’existence de ces bugs, qui ont été très rapidement corrigés, une version de développement ou qui vient juste d’être publiée n’est pas utilisée en production (quoique, quand on voit que la popularité de FWTools (délivrant une version « dev »), même dans la certification RGF93 de l’IGN, on se pose des questions). Une certification qualité n’empêche pas l’apparition de tels problèmes.
Par contre je confirme, la qualité d’un projet industriel (/informatique) n’est pas axée uniquement sur la qualité du code source. Des indicateurs quantitatifs de qualité du code doivent exister, que des audits qualitatifs permettent de valider. Voir les CMMI pour la certification qualité, et on remarque que ce que réclament ces gros décideurs (qui ont peur de l’open source ?) ce n’est pas forcément un engagement d’expertise informatique absolue.
La qualité dans un projet est presque à comprendre comme une discipline à part entière, et non pas comme un simple adjectif. La qualité dans un projet et un projet de qualité, c’est malheureusement assez différent, même si au final il y a des forts rapprochements.
Salut,
Je connais un autre mythe: la qualité des logiciels propriétaires 😉
Bruno
Tiens, cela me fait penser à une question :
Existe-t-il dans ce domaine de la géomatique des entreprises ayant une certification quelconque, que ce soit ISO 9001, CMMI ou autre liée à la qualité de manière générale ou plus spécifiquement à l’informatique ?
Le dernier appel d’offre d’un gros décideur (une multi-nationale à plusieurs dizaines de milliers de salariés)que j’ai lu commençait par cette phrase « Toute solution a base d’Open Source sera rejetée ».
Ce n’est pas pour des questions de qualité que l’Open Source était écarté , mais pour des questions de RESPONSABILITE. La multinationale en question gére des équipements à risque et souhaite pouvoir toujours se retourner contre qqun en cas de pépin grave.
Que se passe t-il si un gazoduc explose en pleine ville à cause d’une erreur de transformation de coordonnées provenant de proj4 par exemple ?
JY
Le logiciel open source est fourni tel quel par la communauté.
Il n’empêche aucune entreprise de réaliser des tests permettant d’assurer la qualité dudit logiciel dans le cadre de son utilisation.
ESRI ne se cache pas d’utiliser GDAL. Windows utilise pour sa partie réseau du code BSD. Le titulaire d’un appel d’offre doit être capable de juger la qualité du produit qu’il fournit au donneur d’ordre, non ? Qu’il soit Open Source ou issu d’un code entièrement codé dans l’entreprise, y aurait-il une différence ?
Désolé, les commentaires pour cet articles sont clos pour le moment.