Articles : L'UE co-finance un observatoire de la qualité des logiciels open source.
Posté par R4f (page perso, ). Modéré le 25 octobre 2006.
Il s'agit d'un consortium de projets open source européens majeurs, de consultants et d'instituts de recherche grecs, britanniques, allemands et suédois qui développent une suite complète d'outils d'évaluation de la qualité des logiciels. Ces outils permettront l'analyse et le benchmarking de logiciels open source.
Buts du projet
SQO-OSS vise à assister les développeurs européens à améliorer la qualité de leur code, et à abaisser les barrières à l'entrée du logiciel open source en fournissant des preuves scientifiques de leurs qualités.
L'open source mène déjà la danse dans la renaissance du développement logiciel des PME ; des outils pointus d'évaluation de la qualité soutiendront son adoption par davantage d'entreprises et aideront les PME et projets européens dans leur concurrence vis à vis des sociétés globales.
(repris du site : http://www.sqo-oss.eu/index_html/about)
![[en]](../images/en.png)
> Lire la dépêche (19 commentaires, moyenne: 3,2).
Vous avez demandé le commentaire #768189.
Run by 
Cette page a été générée par Templeet en 0.0532s (dont 0.0044 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Preuves scientifiques?
Bonjour,
C'est certainement une bonne idée. Mais comment se concrétisera-t-elle?
Apporter des preuves scientifiques de la qualité des logiciels, qu"ils soient libres ou non, me semble plutôt vaniteux. Non?
Quels seront les "métriques" dont l'on parle? Quels sont les étalons comparatifs? Les logiciels propriétaires? Quels sont les critères retenus pour l'évaluation? Quels barèmes? Comment va-t-on scientifiquement prouver l'adéquation d'une interface avec la finalité d'un logiciel? Car la qualité c'est celà aussi.
Tant de critères entrent en ligne de compte que je ne vois pas comment l'on peut s'en sortir, toujours d'un point de vue scientifique. Quel est le plus qualitatif?: un logiciel à l'optimisation algorithmique hussarde et echevelée mais documentée, ou bien un logiciel respectant les canons de la programmation objet avec pour seul commentaire "// ce programme permet de faire ceci-celà"
Les outils servant à extraires ces "preuves scientifiques" sont-ils eux mêmes auto-audités? Si l'on s'arrête au défaut de codage dans la page web cité plus haut dans les commentaires, on est en droit de s'interroger sur la fiabilité des audits effectués.
Enfin, pour que ces résultats qualitatifs soient parlants, il faut aussi mesurer la qualité des logiciels propriétaires des sociétés globalistes, puisque telle est la finalité. Cette évaluation ne pourra porter sur le code alors. Donc tout critère lié à la maintenance et l'évolution d'un logiciel est à exclure.
Que d'interrogations, si quelqu'un peut m'aider à y répondre... simplement.
Bref qui sait, comment fera-t-on pour évaluer la qualité de GIMP par exemple et de Open Office Spreadsheet. Les deux ayant des finalités et fonctionnalités différentes sans parler de l'interface. Peut-être n'ai-je tout simplement pas compris de quoi nous parlions.
[^]Re: Preuves scientifiques?
Si on savait répondre à tes questions simplement, il n'y aurait pas besoin de ce projet ;).
Ils prévoient plus d'un an sur les deux de définition précise du projet, bibliographie et spécification ...
http://www.sqo-oss.eu/about/activities
Ce que je vois 'à priori' sur la qualité, c'est par exemple la qualité du code. Utiliser et concevoir des outils de preuves de programmes pour rechercher des propriétés comme "pas de segfault" dans le code.
Mais tu à raison, le projet semble bien plus vaste, ils vont sans doute mettre des équipes de recherche en labo et/ou en r&d dans les entreprises sur des domaines relativement larges (de l'ihm à la preuve formelle de programme, recherche de bugs, ...)
[^]Re: Preuves scientifiques?
Tu poses à mon avis de vrai questions.
Perso je ne crois pas du tout à ces modes de "calcul" sois disant scientifique de la qualité.
Le méthode en général : ils décomposent en plein de critères et sous critères (en veux tu en voilà), donne un poids à chacun, puis ils font une évaluation et par un "savant" calcul de moyenne tu obtiens une note ! Certains te feront un joli graphe multidimensionnel (c'est déjà un peu mieux).
Ce n'est pas que ces calculs soient en eux même mauvais, ils peuvent être un outil, mais c'est leur utilisation : à la fin on te balance le chiffre mais on oublie que selon ton contexte, ce qui importe n'est pas la même chose. D'ailleurs, quelle est la pertinence des critères choisis, le poids qu'on leur donne, c'est hyper discutable. Quel est le rôle aussi de chaque critère. Par exemple, le fait qu'il y ai beaucoup d'alertes de sécurité ne veux pas forcément dire que mesure pas la réactivité que l'on porte à les corriger.
Bref le risque, c'est de chercher à justifier par des chiffres une politique ou une idéologie (ou à avoir un beau parapluie). En fait on masque par des calcul le fait qu'à la base il n'y a rien de scientifique.
Pour ce qui est des chiffres, je préfèrerais un outil qui me permette de sortir les chiffres en fonctions de critères et poids que je donne. Bref une base de métrique des projets puis un outils de calcul. Mais ce ne serait qu'un critère de décision parmis d'autre !
Le partage d'expérience entre utilisateurs est sûrement bien plus profitable (il apporte ouverture et solutions nouvelles), mais moins en vogue car il te justifie moins et dans les grandes organisation c'est parfois seulement à garder sa place que l'on pense.
mes références : "la société malade la gestion" de Vincent de Gauléjac
[^]Re: Preuves scientifiques?
J'ai discute avec Sebastian Kugler, qui est un activiste de KDE (sur le plan de la communication notamment) et qui vient de rentrer au board de KDE. Il fait partie de ce projet, ainsi que Adriaan de Groot.
Adriaan maintient "the english breakfast network" ( http://www.englishbreakfastnetwork.org/ ) qui sous un nom assez obtus, est un site web faisant des analyses de code sur le code de KDE et reporte des problemes standards:
- methodes, classes ou parametres non documentees
- analyses sur la documentation utilsateur (problemes d'utilisation de docbook)
- analyses sur le code, pour chercher des constructions non optimisees, des petites erreurs, des problemes dans l'assignation des licences, etc.
J'avoue avoir initialement les memes reserves que vous sur ce projet mais en discutant avec lui, j'ai vu qu'il y avait une approche a la fois pratique et academique.
Note: l'analyseur de code est base sur le parser de C++ de kdevelop
Le projet part donc deja avec quelques outils.
Sebastian et Adriaan ont une tres bonne comprehension de l'open source et sont des gens tres pragmatiques. Je leur fais confiance pour ne pas nous sortir un machin completement inutilisable.
La metrique utilisee par EBN est super simpliste: documenter toutes ses fonctions et tous ses parametres, eviter des constructions dangereuses, non optimisees, obsoletes ou jettant un flou juridique (melange de licence, fichiers avec une mauvaise licence, etc). Elle ne permet pas de mesurer objectivement la qualite de KDE. Mais deja, elle a permis d'ameliorer la qualite du code de KDE.
Donc meme si on a aboutit pas a des outils mettant une note objective sur 20 a un projet, on aboutira pour sur a des outils permettant globalement d'ameliorer la qualite de nos chers projects Open Source, de la meme facon que les scan de coverity ont ameliorer la securite des projets open source.
Je suis quand meme convaincu que avec des gens intelligent comme Sebastian, le projet ira beaucoup plus loin que cela.
phil.freehackers.org
[^]Re: Preuves scientifiques?
Merci pour ta réponse.
Mon sceptiscime est en effet plutot sur le fait d'absolutiser des mesures quantitatives de qualité mais pas contre le fait d'en faire et de les utiliser.
Puisqu'en plus tu as confiance dans la personne c'est surement très positif !
j'espère juste qu'il ne veut pas se servir de ce projet pour nourir le troll KDE/Gnome ;-)
[^]Re: Preuves scientifiques?
Cette évaluation ne pourra porter sur le code alors.
Ben justement, ça peut. En montrant que l'absence de code fait baisser la confiance qu'on peut avoir dans un logiciel, on montre bien qu'un code fermé donne moins de garanties sur la qualité.
Par exemple, un logiciel libre fourni avec des tests unitaires permet d'évaluer la couverture du code par les tests, et de vérifier le fonctionnement de chaque brique constitutive du programme.
[^]Re: Preuves scientifiques?
Merci pour vos réponses et les quelques lumières qu'elles m'ont apporté.