• Aucun résultat trouvé

Analyse, évaluation et amélioration de la performance du processus de développement libre : une approche par la norme ISO/IEC 29110

N/A
N/A
Protected

Academic year: 2021

Partager "Analyse, évaluation et amélioration de la performance du processus de développement libre : une approche par la norme ISO/IEC 29110"

Copied!
278
0
0

Texte intégral

(1)

UNIVERSITÉ DU QUÉBEC À MONTRÉAL

ANALYSE, ÉVALUATION ET AMÉLIORATION DE LA PERFORMANCE DU

PROCESSUS DE DÉVELOPPEMENT LIBRE : UNE APPROCHE PAR LA

NORME ISO/IEC 29110

MÉMOIRE PRÉSENTÉ

COMME EXIGENCE PARTIELLE

DE LA MAÎTRISE EN INFORMA TIQUE

PAR

ADÈLE LARISSA NSOA

(2)

Avertissement

La

diffusion de ce mémoire se fait dans le' respect des droits de son auteur, qui a signé .le formulaire Autorisation de reproduire. et de diffüser un travail de recherche de cycles supérieurs (SDU-522- Rév.01-2006). Cette autorisation stipule que «conformément à l'article 11 du Règlement no 8 des études de cycles supérieurs, [l'auteur} concède à l'Université du Québec

à

Montréal une licence non exclusive d'utilisation et de . publication oe la totalité ou d'une partie importante de [son} travail d~ recherche pour 'des fins pédagogiques et non commerciales. Plus précisément, [l'auteur} autorise l'Université du Québec à Montréal à reproduire, diffuser, prêter, distribuer ou vendre des .· copies de. [son} travail de recherche à des fins non commerciales sur quelque support que ce soit,

y

compris l'Internet. Cette licence et cette autorisation n'entraînent pas une renonciation de [la] part [de l'auteur] à [ses] droits moraux ni à [ses} droits de propriété intellectuelle. Sauf entente contraire, [l'auteur] conserve la liberté de diffuser et de commercialiser ou non ce travail dont [il} possède un exemplaire.»

(3)

REMERCIEMENTS

Je remercie premièrement le professeur Normand Séguin de m'avoir invité à poursuivre mon projet de maîtrise sous sa direction. 11 a été vraiment disponible pour moi tout au long du déroulement de ce projet de recherche et m'a procuré de précieux conseils et sa vision globale du projet a guidé et soutenu ma démarche.

Je tiens à remercier les professeurs qui accepteront d'évaluer le rapport de mon travail de recherche.

Je tiens à remercier particulièrement mon ami Edouard Fonh-Gbei pour avoir cru en moi et pour m'avoir soutenu tout au long de mon année académique.

Je remercie également ma famille toute entière: ma mère, mon père, ma sœur et mes frères, pour m'avoir apporté un soutien moral inestimable et d'avoir cru en mes capacités et en ma volonté de terminer ce projet de recherche.

(4)

REMERCIEMENTS ... iii

LISTE DES FIGURES ... ix

LISTE DES TABLEAUX ... xi

LISTE DES SIGLES, ABRÉVATIONS ET ACRONYMES ... xiii RÉSUMÉ ... xv

CHAPITRE! INTRODUCTION ... 1

1.1 CONTEXTE DES LOGICIELS LIBRES ... l 1.2 CONTEXTE DE L'ÉTUDE ... 3 1.3 CONTRIBUTIONS ... 4 1.4 STRUCTURE DU DOCUMENT ... .4 CHAPITRE II PROBLÉMATIQUE ET OBJECTIFS ... 7 2.1 INTRODUCTION ... 7 2.2 PROBLÉMATIQUE ... 11 2.3 OBJECTIFS ... 13 CHAPITRE III ÉTAT DE L'ART SUR L'ASSURANCE QUALITÉ EN LOGICIELS LIBRES ... 1 S 3.1 LITTÉRATURES SUR LES F/OSS ... ] S 3.1.1 Définition de F/OSS ... 16

3.1.2 Considérations dans les F/OSS ... 18

3.1.2.1 Valeurs dans les F/OSS ... 18

3.1.3 Principes derrière le libre : cas de quelques projets ... 20

(5)

3.1 .3.2 Mozilla ... 21

3.1.3.3 Apache ... 23

3.1.4 Style de développement ... 24

3.1.4.1 Type de développement ... 24

3.2 LITTÉRATURES SUR LA QUALITÉ DANS LES F/OSS ... 30

3.2.1 Définition de la qualité ... 30

3.2.2 Comparaison de F/OSS et logiciels commerciaux ... 32

3.2.3 Développement et pratiques de qualité ... 34

3.2.3.1 Pratiques de qualité ... 34

3.2.3.2 Quelques éléments de base du développement des F/OSS ... 37 3.2.3.2.1 Adhésion, initiation et planification de projet ... 37

3.2.3.2.2 Implémentation de logiciel ... 38

3.2.3.2.3 Gestion de configurations, de documents et de versions ... .41 3.2.3.2.4 Méthodes de vérification et validation ... .43

3.2.4 Problèmes de qualité ... 51

3.3 CONCLUSION ... 53

CHAPITRE IV MÉTHODOLOGIE ... 55

4.1 INTRODUCTION ... 55

4.2 RAPPEL SUJET DE RECHERCHE ... 56

4.3 ANALYSE, OUTILS ET ÉLÉMENTS DE L'ÉTUDE ... 56

4.3.1 Aspect global de l'étude ... 56

4.3.2 Recadrage : outils et éléments utilisés ... 57

4.4 PRÉSENT A TION DE L'APPROCHE UTILISÉE ... 60

4.4.1 Méthodologie d'analyse du processus de développement libre ... 65

4.4.2 Compatibilité de la norme avec les logiciels libres ... 67

4.5 CONCLUSION ... 69

CHAPITRE V ANALYSE DU PROCESSUS DE DÉVELOPPEMENT LIBRE SELON L'OBSERVATION DES F/OSS ... 71

5.1 INTRODUCTION ... 71

(6)

5.2.1 Présentation du processus de développement actuel ... 72 CHAPITRE VI 5.2.1.1 5.2.1.2 5.2.1.3 5.2.1.4 5.2.1.5 5.2.1.6 Initiation d'implémentation du logiciel ... 72

Analyse des exigences ... 7 S Architecture et conception ... 79

Construction du logiciel ... 83

Intégration et tests ... 89

Livraison du produit ... 93

NORME ISO/IEC 29110 ET COMPARAISON DES PROCESSUS ... 97

6.1 PRÉSENTATION DE LA NORME ISO/IEC 29110 ... 97

6.1.1 Définition ... 97

6.1.2 Guide d'ingénierie et gestion du profil basique d'une YSE ... 98

6.1.2.1 6.1.2.2 Processus de gestion de projet.. ... 99

Processus d'implémentation de logiciel ... 1 02 6.2 COMPARAISON DES PROCESSUS ... 1 06 6.2.1 Différences entre le processus de développement de logiciels libres et le développement classique de logiciels ... 106 6.2.1.1 Évaluation du processus de développement de logiciels libres .. 1 07 6.2.2 Étude de compatibilité entre les processus de la norme et les processus libres ... 115 6.2.2.1 Identification des critères de compatibilité ... ll5 6.3 PRÉSENT A TION DES RÉSULTATS ... 129 6.3.1 Écarts observés entre les processus libres et processus classiques de développement ... 129 6.3.2 Résultats de l'étude de compatibilité ... 138

6.4 RÉSUMÉ DU CHAPITRE ... 140 CHAPITRE VII ANALYSE ET RÉFLEXIONS SUR LES RÉSULTATS ... 141 7.1 INTRODUCTION ... 141 7 .1.1 Rappel des résultats obtenus : synthèse des résultats ... 142

7 .1.1.1 Différences entre le développement de logiciels libres et le développement classique de logiciels ... 142 7 .1.1.2 Compatibilité de ISO/IEC 29110 avec les logiciels libres ... 147

(7)

7.2 ANALYSE DES RÉSULTATS ... 147 7 .2.1 Architecture et conception ... 150 7 .2.2 Construction de logiciel ... 151 7 .2.3 Intégration et tests ... 151 7 .2.4 Livraison de produit ... 152 7.3 RÉFLEXION SUR LES RÉSULTATS ... 153 7.3.1 Approche d'application de la norme aux logiciels libres ... 155 7.4 CONCLUSION ... 167 CHAPITRE VIII

CONCLUSION ... 169

ANNEXE A

PRINCIPES DE LOGICIELS OPEN SOURCE ... 179

ANNEXEE

DIFFÉRENTS PROCESSUS DES PHASES DE REVUE DANS LE PROJET ECLIPSE .183

ANNEXEC

ÉTAT DE L'ART DES MÉTHODOLOGIES DE DÉVELOPPEMENT ... 187

ANNEXED

ISO/IEC TR 29110- 1 ... 197

ANNEXEE

ISO/IEC TR 2911 0 - 3 ... 235

(8)

Figure Figure 2.1 Figure3.1 Figure 3.2 Figure 4.1 Figure 4.2 Figure 4.3 Figure 6.1 Figure 6.2 Figure 6.3 Figure C.1 Figure C.2 Figure C.3 Figure C.4 Page

Culture en génie logiciel ... 9

Structure de l'équipe de développement des F/OSS ... 28

Fonctionnement des communautés de logiciels libres ... 37

Gabarit du tableau d'analyse ... 58

Analyse générale du processus de développement de logiciel libre ... 65

Analyse de compatibilité de la norme avec les logiciels libres ... 69

Processus du guide du profil de base ... 98

Diagramme du processus de gestion de projet ... 100

Diagramme d'implémentation de processus ... 103

Modèle en cascade···.··· 190

Modèle en V ... 191

Modèle par incréments ... 193

(9)

Tableau Page

Tableau 3.1 Quelques licences de F/OSS ... 18

Tableau 3.2 Comparaison des pratiques de gestion de la qualité ... 34

Tableau 3.3 Récapitulatif des outils de gestion de documents et de configurations dans certains rojets de F/OSS ... 43

Tableau 6.1 Évaluation de l'activité d'initiation d'implémentation de logiciel. 108 Tableau 6.2 Évaluation de l'activité d'analyse des exigences ... 109

Tableau 6.3 Évaluation de l'activité d'architecture et de conception ... 110

Tableau 6.4 Évaluation de l'activité de construction logicielle ... 111

Tableau 6.5 Évaluation de l'activité d'intégration et tests ... 113

Tableau 6.6 Évaluation de l'activité de livraison de produit ... 114

Tableau 6.7 Résumé des pratiques de quelques sous-projets libres ... 122

Tableau 6.8 Analyse générale de l'applicabilité de la norme ISO/IEC 29110 avec le mode de développement de logiciels libres ... 125

Tableau 6.9 Matrice de comparaison des activités de ISO/IEC 29110 conformément aux critères de compatibilité avec les logiciels libres ··· 129

Tableau 6.10 Écarts observés du développement de logiciels libres par rapport au développement classique de logiciels ... 135

Tableau 6.11 Forces, faiblesses et pratiques de qualité entre le développement libre et le développement en ingénierie ... 137

(10)

Tableau 6.12 Résultats de l'étude de compatibilité de la norme ISO/IEC 29110 conformément aux logiciels libres ... 139 Tableau 7.1 Synthèse des différences entre les logiciels libres vs développement

d'ingénierie ... 146 Tableau 7.2 Synthèse de résultats de compatibilité de la norme ISO/IEC 29110

aux logiciels libres ... 147 Tableau B.1 Différentes phases de revue dans le projet Eclipse ... 186

(11)

AGPL Affero General Public License. Généralement connue sous le nom de

GNU AGPL

AN Analyste

BSD Berkeley Software Distribution License

CCB System control board

CUS Client

CYS Concurrent Versions System

DES Designer

EMO Eclipe Management Organization

EMO(ED) Sous-ensemble de l'EMO: En fait c'est un directeur exécutif(il/elle) qui peut déléguer une autorité spécifique à une autre personne.

Ezmlm Progiciel pour la gestion des listes de diffusion électroniques

FDL Free Documentation License. Généralement connue sous le nom de

GNUFDL

F/OSS Free 1 Open Source Software

FSF Free Software Foundation

GNATS GNU GNATS est un ensemble d'outils pour le suivi des bogues rapportés par les utilisateurs vers un site central.

(12)

GNU Système d'exploitation libre, initié en 1983 par Richard Stallman dans le projet GNU [ 101]. Il est généralement aussi connu sous le nom de GNU/Linux.

GPL General Public License. Généralement connue sous le nom de GNU GPL

IEEE lnstitute of Electrical and Electronics Engineers

IRC Internet Relay Chat

ISO International Organization of Standardization

LGPL Lesser General Public License. Généralement connue sous le nom de GNU LGPL

LXR Linux Cross Referencer. Utilisé pour 1 'indexation de code source, particulièrement dans de gros projets tel que le noyau linux

Mozmill Outil de test d'interface utilisateur pour les applications basées sur Mozilla. Il est utilisé par la Mozilla Corporation et Mozilla Messaging pour exécuter des tests fonctionnels par rapport à Firefox et

Thunderbird.

OSI Open Source Initiative

PM Projet Manager

PMC Projet Managment Committee

PR Programmeur

SVN Apache Subversion. C'est un logiciel de gestion de versions.

TinderBox Outil supportant les tests de logiciel

TL Technicallead ou chef technique en français

ViewCVS Outil permettant de visualiser les dépôts CYS ou SVN via un navigateur web

(13)

Les F/OSS 1 font face à de nombreux problèmes de qualité [67, J 08, J 15] et cette problématique de qualité est d'actualité. Malgré un nombre important de publications sur les F/OSS, nous déplorons la rareté des recherches qui se sont penchées sur l'application des normes de base de développement du génie logiciel au processus de développement libre. Cependant, certains projets libre ont pu développer du logiciel de qualité et ont maintenu ce niveau de qualité dans les logiciels développés ou maintenus au sein de leurs communautés. Cette recherche a donc pour but d'analyser si une norme de développement du génie logiciel telle que la jeune nom1e ISO/IEC 29110 peut soutenir ou améliorer le processus de développement libre compte tenu de la culture du libre.

La méthodologie de recherche utilisée est divisée en deux phases. La première phase est une étude exploratoire des F/OSS au travers de l'étude des projets: Linux, Apache, Mozilla et GNOME. Elle a permis de se familiariser aux F/OSS, d'identifier les problèmes de qualité rencontrés, d'extraire et d'évaluer le processus de développement actuel des F/OSS par rapport à la norme ISO/IEC 2911 O. Les résultats de cette évaluation rejoignent à littérature en ce sens que le développement libre souffre d'un manque de documentation. La deuxième phase consiste en une analyse de compatibilité des activités du processus d'implémentation de la norme ISO/IEC 29110 avec les F/OSS, afin d'identifier les activités de la norme qui sont compatibles aux F/OSS. Cette évaluation a permit 1 'identification de 4 activités de la norme ISO/IEC 29110 qui sont compatibles aux F/OSS, et qui ont été la base d'une stratégie d'amélioration de la performance du processus de développement libre.

Mots clés : Assurance qualité, qualité, processus de développement, valeurs, logiciels libre, valeurs, culture, principes, activités, artefacts, norme de développement du génie logiciel, logiciels open source, génie logiciel.

1

F/OSS: Free 1 Open Source Software. Le sigle F/OSS englobe à la fois les logiciels libres et les logiciels open source. Il désigne les logiciels développés ou maintenus sous une licence libre ou open source.

(14)

INTRODUCTION

1.1 CONTEXTE DES LOGICIELS LIBRES

Les communautés ou projets de logiciels libres, sont habituellement des organisations hybrides qui combinent le but non lucratif et des stratégies de marché. Elles sont constituées d'une multitude de participants, généralement des bénévoles, distribués géographiquement à travers le monde [92]. Leur principal moyen de communication est entièrement basé sur l'Internet, par le biais d'une infrastructure solide soutenue par de multiples outils qui sont majoritairement des logiciels libres (voir chapitre 3 -section 3.2.4.2.3 pour les détails).

Les logiciels développés ou maintenus dans les communautés de logiciels libres sont de types:

Les systèmes d'exploitation : par exemple, GNU/Linux, Free/Net/OpenBSD [8], Solaris;

Les applications web et applications réseau : par exemple, Mozilla, Apache, Samba;

Les interfaces utilisateurs et graphiques : par exemple, le projet GNOME, Gimp;

(15)

Compilateurs, éditeurs de programmes et langages de programmations : GCC, Php, Java, Notepad++, Emacs, Gummi.

Ces exemples confirment simplement les identifications d'Eric Raymond [102] et de Brian Behlendorf [34]. Ces pionniers dans les logiciels libres, ont identifié en 1999 que la majorité des applications de F/OSS sont dans le domaine Internet ou dans les applications systèmes. D'amples exemples de projets de F/OSS2 sont vus dans certains travaux [12, 70, 77].

Les F/OSS sont divisés en différents sous-projets. Chacun de ces sous-projets possède une communauté de membres qui lui est propre, un portail web, une liste de diffusion des développeurs, un groupe de mainteneurs du projet et dans certains cas un groupe d'assurance qualité. 11 n'existe pas réellement une durée maximale de réalisation pour ces projets. Cependant, chaque projet évolue itérativement, version après version [102].

Le mode de développement des F/OSS, bien qu'intriguant et très peu orthodoxe comparativement au développement commercial qui est soutenu par des normes de l'industrie, suscite un intérêt grandissant tant pour de simples utilisateurs que pour des entreprises commerciales. li offre d'énormes avantages économiques et permet d'aboutir dans certains cas à des logiciels de qualité élevée et très sécuritaires. Certains F/OSS se sont démarqués des autres, c'est le cas des communautés Linux, Mozilla, GNOME, Apache et même Eclipse.

2

F/OSS: Free 1 Open Source Sofiware. Le sigle F/OSS englobe à la fois les logiciels libres et les logiciels open source. Nous 1 'utiliserons tout au long de notre étude. Généralement dans cette étude, lorsque nous utiliserons «logiciels libres» ou «logiciels open source», nous penserons au sigle F/OSS. La différence entre logiciels libres et logiciels open source sera présentée au chapitre 3.

(16)

1.2 CONTEXTE DE L'ÉTUDE

L'utilisation de logiciels libres, depuis leur création jusqu'à présent, est de plus en

plus grandissante [13, 100, 103]. Les F/OSS sont une alternative viable face aux

logiciels commerciaux [60], de par leurs performances. Dans certains cas, ils sont

d'une qualité et fiabilité élevées [26]. Ce contexte très intéressant a suscité ma

curiosité face aux logiciels libres. Et donc, il m'a mené à la question spécifique de

voir si une norme de base sur les processus de développement comme la ISO/IEC 29110 pouvait s'appliquer au F/OSS ou en partie aider à améliorer le développement de logiciels libres (voir chapitre 2 -section 2.3 pour les détails).

Le sujet de mon mémoire me permettra non seulement de démystifier Je concept de

logiciel libre, mais également de mieux comprendre leur processus de

développement.

Ce sujet de recherche présente :

Un aspect théorique : consistant en une présentation détaillée des valeurs, des

pratiques et des problèmes de qualité, ainsi que du mode de développement de

logiciel libre;

Un aspect pratique : qUJ consiste principalement en deux évaluations. La

première consiste à 1 'évaluation des processus de développement des logiciels

libres par rapport à la norme ISO/IEC 29110 pour relever les différences entre

les logiciels libres et Je développement classique de logiciels. La seconde

consiste quant à elle à 1 'évaluation de la nonne ISO/IEC 29110 par rapport

aux logiciels libres, question de déterminer les activités de la norme ISO/IEC

29110 qui sont compatibles et ceux non compatibles au. contexte particulier du logiciel libre. Cet aspect de compatibilité de la norme ISO/IEC 29110 aux

(17)

particulier des F/OSS. Les activités de la norme ISO/IEC 29110 qui seront

compatibles au contexte des F/OSS, constitueront la base de notre proposition

d'amélioration des performances du processus de développement des F/OSS via notre application de la norme ISO/IEC 29110 aux F/OSS.

1.3 CONTRIBUTIONS

Les contributions essentielles du présent rapport sont :

L'identification des pratiques et problèmes de qualité des F/OSS;

L'identification des différences entre le processus de développement de

logiciels libres et le processus de développement de logiciels en génie logiciel;

L'identification des processus ou activités de la norme ISO/lEC 29110 qui

sont compatibles aux logiciels libres, et donc qui peuvent s'appliquer aux

processus libres;

La proposition d'une application de la norme ISO/IEC 29110 au contexte des F/OSS.

1.4 STRUCTURE DU DOCUMENT

Le présent document est constitué de six chapitres, sans compter les chapitres pour l'introduction et la conclusion. Au chapitre 2, nous présenterons notre problématique de recherche ainsi que les objectifs que nous devons atteindre à la fin de cette étude.

Par ailleurs, le chapitre 2 contient également des définitions des termes clés, utilisés

fréquemment dans ce document et qui sont nécessaires à la compréhension de la suite

de cette étude. Au chapitre 3, nous présentons une revue de littérature sur les logiciels

libres et sur l'assurance qualité en logiciel libre. À la suite de cette revue de

(18)

5

recherche. Nous procèderons au chapitre 5 à une première analyse du procèssus de développement de logiciel en nous basant sur 1 'observation faite, tirée de la revue de littérature du chapitre 3. À la suite de ce chapitre, principalement au chapitre 6, nous introduirons la norme ISO/IEC 29110 par une brève description de son contenu et présenterons pour finir deux évaluations de processus : 1 'évaluation du processus de développement des logiciels libres par rapport au développement classique de logiciels et l'évaluation de la nom1e ISO/IEC 29110 par rapport aux logiciels libres. Pour finir, nous présenterons une analyse et les réflexions faites sur les résultats obtenus au chapitre 6. Dans la conclusion, nous répondrons à la question principale de notre sujet de recherche, évaluerons si les objectifs de cette recherche (voir

chapitre 2 - section 2.3) sont atteints et présenterons les limites de cette études ainsi

(19)
(20)

PROBLÉMATIQUE ET OBJECTIFS

2.1 INTRODUCTION

Dans ce chapitre, nous présentons la problématique de notre recherche ainsi que les objectifs que nous comptons atteindre.

Avant d'aller plus loin, nous définissons certains termes clés que nous JUgeons importants pour la suite de notre étude : « principes », « philosophie », « culture », « valeurs ». Ces derniers ont de légères différences d'une communauté à une autre. Nous définissons également les expressions suivantes: « génie logiciel », «assurance

qualité » et «ISO /IEC 29110 » .

../ Philosophie :

Provenant du mot grec philosophia, le terme en son sens le plus large consiste en

l'exercice systématique de la pensée et de la réflexion. Selon Larousse [17], l'une des définitions de la philosophie consiste en: « un système d'idées qui se propose de dégager les principes fondamentaux d'une discipline

»

.

Une autre définition proposée

par Larousse [17] est : « la manière de voir, de comprendre, d'interpréter le monde,

les choses de la vie, qui guide le comportement

».

Donc, si nous associons ces deux définitions au développement, le terme pourrait s'appréhender à la façon ou le

(21)

comment se fait le développement et permet de ce fait de dégager les pnnc1pes fondamentaux de ce développement. En ce sens, nous pouvons donc voir le terme philosophie comme un modèle de développement de logiciel. Cette façon de la voir s'appréhende bien à la philosophie dans les logiciels libres .

./ Culture:

Les projets de logiciel libre et open source sont organisés sous forme d'une organisation virtuelle, permettant de gérer et de maintenir le projet. Magaret Elliot [ 48] définit la culture dans les projets de F/OSS de la façon suivante :

« Culture is treated as a metaphor for organization, not as a discrete variable within an organization. The virtual community is the organizational culture » [ 48].

Nous notons une autre définition de la culture, ici au sens du génie logiciel. La culture est définie par Karl Weigers [121] de la manière suivante:

«

Culture includes a set of shared values, goals, and princip/es that guide the behaviors, activities, priorities, and decisions of a group of people working toward a common objective. » [121].

La culture en génie logiciel (figure 2.1) vise à améliorer la qualité de produit logiciel, tant au niveau de la gestion (par le biais de la mise en place d'un environnement de développement qui facilite le développement de logiciel de qualité) qu'au niveau du processus de développement proprement dit.

(22)

Figure 2.1 Culture en génie logiciel [121]

Le développement d'une culture se base sur l'application des meilleures pratiques de l'industrie, et exige l'application d'une discipline personnelle et professionnelle chez les différents participants aux projets logiciels. Cependant, elle n'élimine pas la créativité chez les développeurs. Dans ce contexte, la culture telle que vu par Weigers pourrait s'adapter au développement du logiciel libre .

./ Principe :

Ce terme est utilisé dans bon nombre de domaines. Il est très souvent vu comme : un fondement, une cause première, une proposition admise comme base d'un raisonnement, une règle générale théorique guidant la conduite [ 43, 76].

(23)

Normand Séguin [ 1 09] définit un principe comme suit : « Proposition fondamentale de la discipline formulée sous forme prescriptive (règle), à la source des actions, pouvant être vérifiée dans ses conséquences et par l'expérience ». C'est cette définition que nous considérons pour notre étude .

./ Valeurs :

Les valeurs sont des règles qui régissent le comportement d'un ensemble de personnes. De manière plus détaillée, « les valeurs représentent des principes auxquels doivent se conformer les manières d'être et d'agir. Ces principes sont ceux qu'une personne ou qu'une collectivité reconnaissent comme idéales [sic] et qui rendent désirables et estimables les êtres ou les conduites auxquelles elles [sic] sont attribuées » [24]. Elles sont implicites dans la culture de chaque société. En appliquant la définition des valeurs précédemment énoncées aux logiciels libres, nous dirons que les valeurs sont des règles implicites à la culture de chaque projet, et qui soutiennent le comportement des membres de ces projets .

./ Génie logiciel :

Selon IEEE Computer Society [27], le génie logiciel est: « The application of a

systematic, disciplined, quantifiable approach ta the development, operation, and

maintenance of software; that is, the application of engineering ta software » .

./ Assurance qualité:

L'assurance qualité est définie par 1'1SO/IEC/IEEE 24765 [72] comme étant: «1) un ensemble d'activités planifiées et systématiques de toutes les actions nécessaires pour fournir l'assurance suffisante qu'un élément produit est conforme aux exigences techniques établies ; 2) un ensemble d'activités destinées à évaluer le processus par

lequel les produits sont développés ou fabriqués ; 3) les activités planifiées et systématiques mises en œuvre, dans le système qualité, et démontrées au besoin pour

(24)

vraiment important de la garder à l'esprit car c'est cette définition qui est utilisée tout

au long de cette étude .

./ ISO/IEC 29110:

C'est une norme développée par l'organisme ISO spécifiquement pour les très petits

organismes (TPO) qui développent du logiciel. Les TPO sont des entreprises, des

organismes, des départements ou des projets comportant 25 personnes ou moins. La

norme ISO/IEC 29110 décrit les phases minimales de développement à la fois du

processus de gestion de projet et dq processus de mise en œuvre de logiciel, en tenant

compte des informations suffisantes pour qu'un TPO puisse décrire sont propre

processus de développement [73, 81, 111]. Pour plus de détails, consulter le chapitre

6 et les parties gratuites de la norme ISO/IEC 29110 en ANNEXE 0 et ANNEXEE .

2.2 PROBLÉMATIQUE

Depuis la création du concept de logiciel libre, face à leur croissance fulgurante [13,

82, 100, 103], un débat est porté sur la question de savoir si les processus de F/OSS

peuvent s'appliquer dans d'autres domaines [91]. Sachant que les F/OSS ont réussi

où plusieurs entreprises auparavant ont échoué, notamment, le développement de

façon distribué via l'Internet [89]. La question soulevée est: quand, où, et de quelle

manière le processus de développement de F/OSS se différencie des autres processus

[91 ]? Dans ce contexte, différentes opinions sont nées. Elles opposent les personnes

qui critiquent les pratiques utilisées dans les logiciels libres [90] au groupe constitué

de praticiens de F/OSS et de chercheurs supportant le mouvement de F/OSS [26, 36,

102, 1 05]. Ces chercheurs ont noté certaines spécificités dans 1 'organisation et les

(25)

À

cet effet, Mockus, Fielding et Herbsleb [94] ont eu à identifier des différences entre

le développement de F/OSS par rapport au développement traditionnel :

Les F/OSS sont construits par un nombre souvent élevé de bénévoles;

Le travail n'est pas assigné aux participants, les personnes entreprennent les travaux qu'elles désirent faire;

Il n'y a aucune conception explicite au niveau du système, ou même une conception détaillée du système;

Il n'y a aucun plan de projet, de calendrier, ou liste des livrables.

Les points mentionnés par Mockus, Fielding et Herbsleb [94), traduisent tout

simplement la nature non organisée et non-structurée des projets de logiciels libres qui opèrent de façon ad-hoc [1 04), et donc, au sens classique de développement, sont sujets à 1 'échec du projet. Cela conduirait à des délais non respectés et à des débordements de coûts (coûts de développement et coûts de main d'œuvre) de projet,

car les participants aux F/OSS, qui sont des bénévoles et des experts en leur domaine, ne sont pas payés. Cependant, les considérations en F/OSS, notamment les notions de

coûts de développement et des délais, diffèrent de celles du développement traditionnel de logiciel qui nécessitent que les processus soient soigneusement

planifiés et organisés. Un autre aspect tout aussi important est que, de plus en plus,

certains projets de F/OSS, particulièrement les grands projets, ont recours à une

planification dans leur développement. Il s'agit de la planification des « releases »

[47, 60), qui est un processus permettant d'aboutir à une version rapide et stable du

système logiciel libre. L'usage de la planification des releases dans certains projets libres est en opposition avec 1 'un des points identifiés par Mockus, Fielding et Herbsleb [94] stipulant que dans le développement libre, « il n'y a aucun plan projet, ou calendrier

»

.

(26)

Bien que la méthodologie de développement de logiciels libres ait permis d'aboutir à

des systèmes importants (cas de Linux), dans certains cas de qualité élevée,

comparable voire supérieure aux logiciels de développement fermé [26, 67, 1 08]; les

F/OSS souffrent cependant d'un réel problème de qualité dans leur développement.

Ce problème de qualité, compte tenu de notre observation des F/OSS, serait dû à la

fois à un développement distribué géographiquement et au fait que les participants de

F/OSS soient des bénévoles. Les recherches de Mockus et ses collaborateurs [94],

ainsi que d'autres menées sur le développement de F/OSS [31, 93, 108, 115],

conduisent de manière générale à ce problème de qualité dans le développement de

F/OSS. Le débat sur la qualité dans les processus de F/OSS est toujours ouvert de nos JOurs.

Face au problème de qualité dont souffrent les F/OSS, la question est donc de savoir

si les processus d'ingénierie peuvent s'appliquer au développement de logiciel libre pour pallier aux lacunes de qualité (voir chapitre 3 pour les détails) que font face bon

nombre de projets de type logiciels libres. C'est donc dans ce contexte que porte notre

étude, particulièrement sur la question spécifique : est-ce que la norme ISO/IEC

29110 [73] pourrait soutenir le développement de logiciels libres, compte tenu de la culture et des valeurs sous jacentes au monde du libre?

2.3 OBJECTIFS

Notre travail est une étude analytique dont le but principal est d'évaluer si la norme

ISO/IEC 29110 peut s'appliquer au développement libre.

À

cet effet, nous

présenterons donc : la culture, la philosophie, les valeurs dans le monde du libre, ainsi

(27)

Ainsi, afin de mener à bien cette étude, nous nous sommes donc fixés les quatre objectifs suivants :

./ Identifier les problèmes de qualité que rencontrent certains projets de F/OSS; ./ Analyser le processus de développement de logiciels libres :

o Déterminer en quoi le développement des logiciels libres se distingue du développement classique, ici, celui en génie logiciel (respect des normes de 1 'industrie);

o D'identifier lesquelles des activités de la norme ISO/IEC 29110 sont

incompatibles avec la philosophie de F/OSS et les considérations autour des F/OSS, et lesquelles pourraient améliorer le processus de développement de F/OSS;

./ Présenter la synthèse des résultats obtenus;

./ Présenter les conclusions tirées de cette étude.

Afin de réaliser ces objectifs, nous smvrons notre méthodologie de recherche, laquelle est présentée en détail dans le chapitre 4.

(28)

ÉTAT DE L'ART SUR L'ASSURANCE QUALITÉ EN LOGICIELS LIBRES

3.1 LITTÉRATURES SUR LES F/OSS

Depuis des années, les entreprises propriétaires utilisent un mode de développement

basé sur des standards de l'industrie, afin d'obtenir des produits d'une certaine

qualité, sous des licences protégeant la propriété intellectuelle. Face à toute cette

rigueur procédurale et à 1 'impossibilité des utilisateurs de pouvoir accéder librement

au code source, Richard Stallman lance en 1983, le mouvement du «Logiciel libre »

et le formalise à travers le projet GNU [ 101]. Deux années plus tard, Stallman fonde

la FSF [54] afin de soutenir et promouvoir le logiciel libre, de même que de défendre

les droits ou libertés des utilisateurs. Depuis sa création, le concept de logiciel libre a

révolutionné le développement de logiciels et est considéré de nos jours comme un

atout important tant pour de simples utilisateurs que pour des entreprises

commerciales. Les logiciels libres présentent d'énormes avantages économiques par

rapport aux logiciels propriétaires.

Dans la suite de ce chapitre, nous examinerons comment se fait l'assurance qualité

dans les projets de F/OSS, ainsi que les méthodes et outils permettant d'aboutir à une

(29)

d'entrer dans le cœur des pratiques des communautés de F/OSS, nous exposerons les

valeurs véhiculées dans le développement de F/OSS.

3.1.1 DéfinitiondeF/OSS

Tel que définie par le projet GNU [ 101 ], un logiciel est dit libre si tous les utilisateurs

ont les libertés d'exécuter, de copier, de distribuer, d'étudier, de modifier et

d'améliorer le logiciel. Cela est plus connu sous 1 'appellation des quatre libertés

[101) :

Liberté 0: Liberté d'exécuter le programme pour tous les usages;

Liberté 1: Liberté pour les utilisateurs d'étudier le programme et de l'adapter à

leurs besoins. Cette liberté nécessite l'accès au code source;

Liberté 2: Liberté de redistribuer les copies du programme;

Liberté 3: Liberté d'améliorer le programme et de publier vos améliorations

pour en faire profiter toute la communauté. Cette liberté requiert également

l'accès au code source.

Ces libertés exposent clairement le focus du concept de logiciel libre, qui est : « La

liberté et non le prix » comme l'a dit Stallman [101). Cependant, ce concept

de

«

logiciel libre » ne signifie pas être gratuit, car la production et la distribution

peuvent être rémunérées mais leur utilisation doit rester libre. Afin que les logiciels

dérivés restent libres, en d'autres termes, que les droits d'auteurs restent conservés,

les communautés de logiciels libres utilisent des « licences Copylefe

».

Cependant,

quelque fois dans les communautés de logiciels libres, les logiciels peuvent être «

non-copyleftés

».

Cela permet ainsi à un utilisateur qui utilise ou qui modifie un

3

Le copylefi est une catégorie de licence au sein de la communauté du logiciel libre permettant à un logiciel libre de conserver le statut de logiciel libre à travers ses versions ultérieures. Voir le projet GNU [62, 84, 1 01] pour plus de détails.

(30)

logiciel de type «logiciel libre », de le vendre et de s'en accaparer sous une licence

propriétaire (voir tableau 3.1 pour quelques licences en logiciels libres).

Le concept de «logiciel libre » est toute fois confondu avec celui de logiciel Open source (confer - ANNEXE A pour les détails de la définition d'un logiciel Open Source tel que défini par OSI [23]). Le concept de logiciel open source émane de

celui de «logiciel libre ». Cependant, il se différencie du concept de logiciel libre par

sa philosophie. La philosophie liée à la définition du logiciel libre selon Stallman est

focalisée sur la liberté tandis que celle des logiciels Open Source est un peu plus

concrète. L'accent est mis sur les fonctionnalités du logiciel telles que la qualité dans

les logiciels Open source [91]. La désignation Open source s'applique aux logiciels

dont la licence respecte les critères établis par l'Open Source initiative (OSI) [23],

alors la désignation logiciel libre s'applique aux logiciels dont la licence respecte les

critères ayant été formalisés dans le projet GNU [ 1 01] et soutenu par la Free Software

Foundation (FSF) [54]. Tous deux ont en commun les quatre libertés du libre [101]

car le concept de logiciel libre tel que vu par Stallman a été à la base de celui de

logiciel Open source. Néanmoins, du fait que le concept de logiciel Open source est

régit par une philosophie émanant et partageant celle de logiciel libre [23], les deux

mouvements ont donc pratiquement les mêmes : licences, logiciels et le plus

important étant des processus de développement grandement semblables [91]. Ainsi,

nous engloberons ces concepts dans la suite de notre étude sous forme de F/OSS

(Free 1 Open Source Software). Par ailleurs, ces deux concepts (logiciel libre et

logiciel open source) n'empêchent pas un individu, ou une entreprise, ou un groupe

de personnes, de vendre ou bien de distribuer un logiciel de type libre4 comme une

composante d'un système logiciel qui contient différentes sources. L'appellation

4

Nous considérons qu'un logiciel de type libre est un logiciel développé ou maintenu dans l'une des communautés « logiciel libre »ou « Open source ».

(31)

F/OSS nous permettra ainsi de mieux faire ressortir les meilleures pratiques de qualité du monde du libre.

Modèles Catégories

Compatible

de licences Non- Open Projets

Copyleftée Libre avec GPL

de F/OSS copyleftée source

GPL OUI OUI OUI OUI OUI Projet GNU.

Exemgle: CYS

LGPL Partiel- OUI OUI OUI OUI Projet GNU.

lement Exemgle: La

librairie C de GNU

AGPL OUI OUI OUI OUI OUI Projet GNU

FOL OUI OUI OUI OUI OUI Projet GNU

BSD non OUI OUI OUI non Apache,

Sendmail

MPL/NPL non OUI OUI OUI non Mozilla

EPL non OUI OUI OUI non Eclipse

Tableau 3.1 Quelques licences de F/OSS

3.1.2 Considérations dans les F/OSS

3.1.2.1 Valeurs dans les F/OSS

Les enquêtes menées en 2005 par Michlmayr et ses collaborateurs [92] permettent d'identifier deux caractéristiques ou valeurs essentielles des F/OSS, à savoir :

(32)

Les projets de logiciels libres sont pour la plupart du temps, distribués à travers Je monde ;

Les participants des projets de logiciels libres sont généralement des volontaires non payés.

Les F/OSS sont connus pour leur non conformisme par rapport à la ngueur procédurale imposée dans le développement fermé5 de logiciels. Ainsi, les programmeurs dans ces communautés sont libres de choisir les composants sur lesquels ils travailleront en relation à leur expertise. De par le développement ouvert des F/OSS et le non respect des normes de l'industrie dans les projets libres, les considérations de coûts et délais de développement en logiciels libres diffèrent grandement de celles du développement de logiciels propriétaires. En plus du mode de développement libre qui favorise un développement itératif et en parallèle [91] ainsi que la participation6 de n'importe quel membre de la communauté libre à n'importe quelle phase du processus de développement libre [102], la passion qu'ont les développeurs dans les communautés de logiciels libres leur permet de s'investir et de rendre le code aussi efficace et fiable que possible. Les deux, ensemble (mode de développement libre et passion rencontrée chez les développeurs), permettent de rapidement détecter et corriger les défauts de logiciel. Cela conduit ainsi à une efficacité et une fiabilité accrues du code, mais est également la base de certains problèmes de qualités rencontrés dans les projets. La section 3.2.4 de ce chapitre présente quelques problèmes de qualité rencontrés identifiés dans les F/OSS.

5

Utilisé pour référencer le développement de logiciels propriétaires. Les entreprises commerciales suivent habituellement des normes de génie logiciel afin d'assurer et de maintenir la qualité de leur processus, ainsi que celle de leurs produits logiciels.

6

Dans les communautés de F/OSS, tant des individus volontaires participent aux projets, mais également des entreprises et leurs employées [Il 0].

(33)

3.1.3 Principes derrière le libre: cas de quelques projets

Chaque participant d'un projet de F/OSS respecte les pnnc1pes soutenant le

développement dans sa communauté. Bien que ces principes diffèrent d'un projet à

un autre, nous avons cependant noté des similitudes entre les communautés grâce aux

nombreuses littératures faites dans les F/OSS. Ces similitudes consistent notamment:

aux quatre libertés du libre, traiter les utilisateurs comme des co-développeurs, à

rapidement distribuer le code, à livrer rapidement le logiciel et à utiliser des outils

libres ou open source afin de soutenir le développement.

Afin de regrouper ou généraliser les F/OSS, nous avions pensé identifier les principes

globaux des logiciels libres. Cependant, I)OUS n'avons retrouvé que très peu d'informations à ce sujet. Très peu d'auteurs et de F/OSS ont identifié les principes soutenant le développement libre. Ainsi dans cette section, nous présentons uniquement les principes de quelques projets populaires de F/OSS.

3.1.3.1 Linux

Son nom initial est GNU/Linux faisant référence au projet GNU [101]. GNU/Linux est un système d'exploitation libre lancé en 1983 par Stallam et maintenu dans le projet GNU [101], et plus connu sous le terme Linux. Ce système utilise le noyau libre de système d'exploitation crée par Linus Dorvals en 1991.

Les principes soutenant Linux tel qu'identifiés par Raymond [102], bien qu'abstraits, sont les suivants :

1. Tout bon logiciel commence par gratter un développeur là où ça le démange.

2. Les bons programmeurs savent quoi écrire. Les grands programmeurs savent quoi réécrire (et réutiliser).

(34)

3. Si vous avez la bonne attitude, les problèmes intéressants viendront à vous.

4. Quand un programme ne vous intéresse plus, votre dernier devoir à son égard

est de le confier à un successeur compétent.

5. Traiter vos utilisateurs en tant que co-développeurs est le chemin le moins

semé d'embûches vers une amélioration rapide du code et un débogage efficace.

6.

Distribuez tôt. Mettez à jour souvent. Et soyez à l'écoute de vos clients.

7. Étant donné un ensemble de bêta-testeurs et de co-développeurs suffisamment

grand, chaque problème sera rapidement isolé, et sa solution semblera

évidente à quelqu'un.

8. il vaut mieux avoir des structures de données intelligentes et un code stupide que le contraire.

9. Si vous traitez vos bêta-testeurs comme ce que vous avez de plus cher au

monde, ils réagiront en devenant effectivement ce que vous avez de plus cher

au monde.

1 O. Il est presque aussi important de savoir reconnaître les bonnes idées de vos utilisateurs que d'avoir de bonnes idées vous-même. C'est même préférable, pmiois.

11. Bien souvent, les solutions les plus innovantes, les plus frappantes,

apparaissent lorsque vous réalisez que votre approche du problème était

mauvaise.

3.1.3.2 Mozilla

Fondé en 1998, Mozilla est un projet open source qui se concentre à la promotion de l'ouverture, de l'innovation et des possibilités que le web peut offrir [2]. Mozilla est une organisation hybride qui combine à la fois le but non lucratif et les stratégies de marché pour assurer que l'lntemet demeure une ressource publique et partagée [14]. En voici un exemple d'application Mozilla : le navigateur Firefox. Firefox est conçu

(35)

pour différentes plateformes : les ordinateurs (les portables et les ordinateurs de

bureau) et le mobile (particulièrement le système Android) [95).

Les principes derrière Mozilla, énoncés dans le Manifeste de Mozilla [22] sont les

suivants :

1. Internet fait partie intégrante de la vie moderne - il s'agit d'un composant clé dans l'éducation, la communication, la collaboration, les affaires, le divertissement et la société en général.

2. Internet est une ressource publique mondiale qui doit demeurer ouverte et accessible.

3. Internet doit enrichir la vie de tout le monde.

4. La sécurité des personnes sur Internet est fondamentale et ne peut pas être considérée comme optionnelle.

5. Chacun doit avoir la possibilité defaçonner son utilisation d'Internet.

6. La réalité d'Internet en tant que ressource publique dépend de l'interopérabilité (des protocoles, des formats de données, du contenu), de l'innovation et d'une participation décentralisée mondiale.

7. Les logiciels libres et open source favorisent le développement d'Internet comme ressource publique.

8. Des processus transparents et communautaires favorisent la participation, la responsabilité et la corifiance.

9. L'investissement commercial dans le développement d'Internet apporte de nombreux bénéfices un équilibre entre les object!fs commerciaux et l'intérêt public est crucial.

1 O. L'amplification des aspects d'intérêt public d'Internet est un but important, digne du temps, de l'attention et de l'investissement que l'on y consacre.

(36)

3.1.3.3 Apache

Le projet Apache est un projet ayant vu le jour en 1995, et est constitué d'une

fondation (ASF : Apache Software Foundation) [9]. ASF est gérée par deux

principales entités :

Le conseil d'administration : Il dirige la fondation Apache et est composé

couramment de neuf individus élus chaque année parmi les membres de

l' ASF [9]. Le conseil est responsable de la gestion et de la supervision des activités et des affaires de la société conformément aux statuts de la fondation

Apache. Plus en détails, le conseil assure la gestion des actifs (fonds, la

propriété intellectuelle, des marques de commerce et l'équipement de soutien) et l'allocation des ressources de l'entreprise à des projets.

Les comités de gestion de projets (PMC) : Ils dirigent le projet et sont

constitués des committer/. Chaque PMC pour un projet donné dans Apache,

constitue l'autorité de prise de décision technique concernant le contenu et la direction de ce projet dans Apache. Plus en détails, le rôle du PMC se divise en deux volets, le premier étant de : s'assurer que toutes les questions juridiques sont abordées, s'assurer que la procédure soit suivie et que chaque

version du logiciel soit le produit de la communauté dans son ensemble. Le deuxième volet consiste à : promouvoir le développement à long terme et la santé de la communauté dans son ensemble, de faire en sorte que la revue par les pairs soit équilibrée et à large échelle, et que la collaboration entre les

pairs se produise.

7

Représente un développeur ayant le droit d'accéder et d'écrire au dépôt de code, et ayant signé un Contrat de Licence de Contributeur (en anglais Contributor License Agreement (CLA)) [9]. Le CLA est une licence dans Apache protégeant la propriété intellectuelle ayant été contribuée à la ASF [6].

(37)

Les 6 principes cités comme croyances fondamentales de la philosophie derrière la fondation Apache (ASF) [9] sont :

1. Développement de logiciels de collaboration 2. Licence standard librement commerciale 3. Logiciels constamment de haute qualité

4. Interaction basée sur la technique, l'honnêteté, le respect 5. Mise en œuvre fidèle des normes

6. Fonctionnalité obligatoire telle que la sécurité

Comme exemple de projets Apache, nous citons les suivants : Apache http server, Ofbiz, Anika [30].

3.1.4 Style de développement

3.1.4.1 Type de développement

Le mode de développement utilisé dans les F/OSS tend à rejoindre le développement de logiciel agile [38]. Les communautés de F/OSS utilisent un modèle hybride de développement qui est un développement évolutif, asynchrone et ouvert [92], à la différence du développement commercial qui est fermé. Cette idée est soutenue par

J0rgensen qui qualifie le développement de logiciel libre de développement incrémentai [96] .

../ Ouvert: il peut s'expliquer par le fait que, le code est disponible pour tous les participants au projet. De même, l'ouverture fait référence au fait que tous les processus de développement, processus de changements, les fonctionnalités et les

(38)

25

./ Asynchrone : Otto dans le dictionnaire informatique [99], définie ce terme de la

façon suivante :

«Asynchrone, désigne un type d'échange de données entre deux machines où les données échangées sont émises et analysées selon une référence de temps différente et un rythme variable. Désigne également le même modèle de communication que

précédemment mais cette.fois appliqué à des processus. »

L'aspect important à retenir dans cette définition pour le contexte de logiciel libre est qu'il est appliqué aux différents processus de développement. Le fait que les programmeurs en F/OSS, étant principalement des bénévoles, soient géographiquement distribués à travers le monde et qu'ils communiquent par l'Internet, conduit à des rythmes de travail variables. Par exemple, prenons le cas d'une revue de code par les pairs dans les F/OSS. Habituellement, chaque revue se fait sur une période de temps définie. Tout participant à cette revue travaille indépendamment sur sa copie local du code, et à son rythme. Les corrections de code sont faites parallèlement.

./ Évolutif: L'évolution d'un point de vue programmeurs ou utilisateurs de logiciels libres, peut se voir comme

«

itératif

+

incrémentai ». L'idée dans « itératif» est de fournir le plus tôt possible et de manière fréquente une version du système qui marche, avec des fonctionnalités basiques et très souvent une partie des fonctionnalités ayant été soigneusement intégrées et testées. Chaque itération contient les phases suivantes : étude de la faisabilité, 1 'élaboration,

l'implémentation ou fabrication du logiciel et pour finir la livraison. À chaque nouvelle itération, de nouveaux besoins sont examinés. L'idée dans

« incrémentai

» en logiciel libre, consiste à rajouter des fonctionnalités et informations supplémentaires à la version précédente du système, développée lors du cycle de

(39)

développement précédent. L'évolutivité met donc en œuvre l'aspect cyclique du processus de développement de F/OSS.

En 1999, les enquêtes faites par Raymond dans son livre intitulé « The Cathedral and the Bazaar

» [102], nous montrent que le modèle de développement des logiciels

libres, ressemble plus à un «bazar », ceci à

1

'opposé du modèle « cathédrale »qui est celui des logiciels propriétaires. Le style bazar des F/OSS selon Raymond est caractérisé par la nature non-organisée et très ouverte dans laquelle tout le monde peut participer. Raymond résume ainsi le développement de logiciel libre par

la

phrase « distribuez tôt, distribuez souvent » [1 02]. Également, Raymond mentionne que cette approche de développement encourage activement les utilisateurs à

participer aux projets et à contribuer de diverses manières à savoir : soumission des

rapports de bogues, procéder aux revues de code ou suggérer de nouvelles fonctionnalités. De plus, ce mode de développement compte sur un prototypage rapide dont le développement est fait de manière itérative. Ce mode de développement a été initié par Linus Dorval dont la règle d'or est de: « distribuez vite et souvent, déléguez tout ce que vous pouvez déléguer, soyez ouvert jusqu'à la promiscuité ». Dans cette façon de développer, le travail est fait en parallèle. Par exemple au même moment que se fait le développement, particulièrement, l'élimination des défauts est également faite [91]. Ce processus de développement en parallèle procure ainsi un niveau élevé de qualité des produits logiciels développés [91]. Raymond dans le même ouvrage, a eu à identifier quelques facteurs contribuant au niveau élevé de qualité dans les projets de F/OSS, notamment :

Les revues par les pairs : tant les développeurs que les utilisateurs peuvent réviser et modifier le code source, car les projets libres sont par définition ouverts et transparents;

La motivation des participants : les participants dans les F/OSS étant principalement bénévoles, ils sont motivés par une passion pour le travail

(40)

qu'ils réalisent [80]. Ainsi, particulièrement pour des programmeurs, cette

passion mène à de la créativité et à beaucoup d'innovation. Du côté des utilisateurs, le cycle de développement rapide des F/OSS permet d'obtenir des

feedbacks rapides des utilisateurs, lesquels favorisent grandement la qualité;

Très peu de contraintes : le manque de contraintes liées à la rigueur procédurale, comme tel est le cas pour un développement en entreprise, contribue également à la qualité des F/OSS car, cela permet de trouver de meilleures solutions.

Des meilleures personnes : les F/OSS attirent des personnes très qualifiées qui sont des experts en leurs domaines.

Des années plus tard, précisément en 2007, Kevin Crowston et ses collaborateurs [38]

présentent un nouveau modèle de développement qui se concentre particulièrement

sur la structure sociale des F/OSS. Ce modèle porte le nom du modèle en oignon [26, 38]. Il fait participer les utilisateurs de logiciels aux projets de F/OSS [31] pour que le logiciel respecte le plus possible leurs exigences. Kevin Crowston et ses collaborateurs [38], notent que les F/OSS utilisent un modèle de développement se

rapprochant du modèle agile, qui vise à impliquer le plus possible les clients ou les

utilisateurs et qui permet aux développeurs de réagir rapidement à leurs demandes.

Selon ce modèle, une communauté durable de F/OSS est constituée d'un petit groupe de membres de base, d'un nombre croissant de développeurs contribuant au projet et

un nombre élevé d'utilisateurs actifs signalant des défauts [26].

La figure 3.1 représente la structure de 1 'équipe de développement dans les projets de

F/OSS, basée sur le modèle en oignon [38]. De manière hypothétique comme le

mentionnent Kevin Crowston et ses collaborateurs [38], parmi les développeurs appartenant au groupe noyau, ici, des développeurs de confiance ayant certains

(41)

privilèges tel que 1' accès au référentiel de contrôle de version, il y a 1' initiateur du projet, le coordonnateur de versions.

Initia te ur de projet

Coordonateur de versions

(Release œ9.1.~inat9i)

Figure 3.1 Structure de l'équipe de développement des F/OSS

Dans le modèle en oignon, les participants actifs au projet peuvent monter en grade au niveau de la prochaine couche fermée la plus interne, en gagnant le respect de la

communauté à travers un processus de méritocratie8 [26, 38]. Tout comme l'a

8 C'est une philosophie fonctionnant comme suit: plus des partiCipants aux projets de F/OSS fournissent des contributions signifiantes, plus ils gagnent des responsabilités au sein de la

(42)

mentionné Raymond [ 1 02), les utilisateurs peuvent participer aux projets en envoyant

des rapports de bogues, des suggestions ou par d'autres feedbacks. C'est ainsi qu'ils

deviennent des membres actifs de la communauté. À ce stade, chaque participant peut

devenir un développeur, contributeur au projet s'il a soumis bon nombre de

contributions importantes. Quant à la couche la plus interne, ici, groupe noyau, elle

est réservée aux membres actifs et ayant Je plus d'expérience au sein de la

communauté. Ces membres ont certains privilèges, comme 1 'accès au référentiel de

documents. Chaque rôle dans le modèle est associé à un nombre de tâches et à des

responsabilités spécifiques :

Reporteur de bogues ou testeurs : L'un des points forts des F/OSS est qu'un

très grand nombre de participants au projet, particulièrement des utilisateurs,

fournissent des feedbacks usuels [ 1 02). Ces feedbacks, peuvent être sous

forme de rapports de bogues, de suggestions de nouvelles fonctionnalités et

d'exigences [19, 91, 102). La majorité des défauts majeurs du logiciel sont

détectés par les utilisateurs.

Contributeurs : Ce sont des développeurs appartenant à un groupe fermé,

contribuant par de nouvelles fonctionnalités pour 1 'intérêt du projet [91].

Équipe de base ou groupe noyau : Ce sont des contributeurs ayant fournis

bon nombre de contributions importantes, se voyant ainsi gagner le respect

des autres membres de la communauté de F/OSS. Ils ont pour rôles selon

Lerner et Triole [83]: de fournir la vision du projet, de diviser le projet en

plusieurs parties dans lesquelles les individus peuvent s'attaquer aux tâches

indépendantes, d'attirer les développeurs au projet et de garder le projet

ensemble et de prévenir la bifurcation.

communauté. Pour de nouveaux adhérant au projet, ils gagnent un accès direct au dépôt de code. Et s'ils sont très actifs, ils peuvent grimper en échelon.

(43)

3.2 LITTÉRATURES SUR LA QUALITÉ DANS LES F/OSS

3 .2.1 Définition de la qualité

Le concept de qualité de logiciel est un concept très intéressant. Cependant, quand vient le moment de définir la qualité de manière précise, ce concept devient un peu plus ambigu, car il nécessite une bonne compréhension du processus de prise de décision menant à la qualité. Bon nombre de personnes sont à même de reconnaître la qualité d'un logiciel quant elles la voient, cependant, elles sont incapables de la définir de façon précise, encore moins de décrire le processus menant à cette qualité. Face à tout ce désordre et au besoin d'avoir une définition et une compréhension universelle de la qualité, le sous-groupe CEJ (Commission Électronique Internationale), de 1 'organisme ISO a proposé la norme ISO/CEl 9126 [71].

La qualité au sens de la norme ISO/CEl 9126 [71] est un modèle de qualité constitué d'un ensemble d'attributs de qualité (qualité interne, qualité externe et qualité fonctionnelle de produit logiciel) que doit respecter un produit logiciel. Cette approche de qualité est une perspective orientée utilisateur. Les attributs de qualité identifiés dans ISO/CEl 9126 sont regroupés dans les six caractéristiques suivantes:

La fonctionabilité: c'est la capacité du produit logiciel à fournir des fonctions qui répondent à des besoins exprimés et implicites lorsque le logiciel est utilisé dans des conditions spécifiées;

La fiabilité : c'est la capacité du produit logiciel à maintenir un niveau de service spécifié lorsqu'il est utilisé dans des conditions précises;

L 'utilisabilité : capacité du produit logiciel à être compris, connu, utilisé et à

(44)

L'efficacité : capacité du produit logiciel à fournir des performances appropriées en fonction de la quantité de ressources utilisées, dans des conditions données;

La maintenabilité : capacité du produit logiciel à être modifié;

La portabilité : capacité du produit logiciel à être transféré d'un

environnement à un autre.

Cette approche permet non seulement de déterminer si un produit logiciel est apte à l'emploi conformément aux exigences définies, mais également de déterminer ses performances (fiabilité, efficacité, portabilité, utilisabilité et maintenabilité), afin de déterminer son niveau de qualité.

Quant à l'application de cette approche de qualité dans les F/OSS, de nombreuses questions sont soulevées, notamment les différents facteurs à considérer pour atteindre un certain niveau de qualité du logiciel. Les F/OSS sont connus pour abriter essentiellement des membres bénévoles. Ce contexte est donc conflictuel avec l'approche de la norme ISO/CEl 9126, car les développeurs des F/OSS comme cela est le cas dans les entreprises commerciales, peuvent décider de ne mettre 1 'emphase que sur certains attributs de qualité prescrit par ISO/CEI9126.

La VISIOn de qualité diffère du point de vue des programmeurs par rapport aux utilisateurs. Le plus souvent, la différence entre les programmeurs et les utilisateurs se résume au fait que les utilisateurs se concentrent particulièrement sur les attributs de qualité suivants : utilisabilité, fiabilité et fonctionalibité; tandis que les programmeurs se concentrent sur la portabilité, la maintenabilité et l'efficacité, soutenus par l'attribut de qualité fonctionabilité. Les utilisateurs exigent des mesures et des outils pour mesurer la qualité d'un logiciel [115]. En logiciel libre, tel qu'identifiés par Tawileh et Rana [115], les développeurs croient fermement que les

(45)

idées derrière le modèle de développement de F/OSS, en l'occurrence, les idées de

communication intensive entre les développeurs, la large dépendance dans les revues

par les pairs et une livraison fréquente du code source [ 1 02], sont suffisantes pour

atteindre un niveau de qualité et de fiabilité élevées dans les produits logiciels

développés. Cela étant, ces idées permettent: d'accélérer la détection et correction

des bogues, de fixer la date de livraison et d'améliorer la qualité des produits

logiciels. Certains projets F/OSS ont opté pour des outils de type F/OSS leur permettant d'évaluer la qualité du code de leur produits logiciels en examinant

certains aspects. Par exemple, SourceForge héberge PMD [ 112] qui est un analyseur

de code Java, permettant de retrouver certains bogues, tel que les blocks de catch

vides, la création d'objets inutile; de retrouver des variables non utilisées, de

retrouver du code dupliqué. Il en existe plein d'autres outils de ce genre qui soient de

type F/OSS. Spinellis et ses collaborateurs [114], ont fait une observation de la qualité de logiciels libre : SQO- OSS (Software Quality Observator pour des produits logiciels OSS) qui se différencie des analyses de la qualité faites par des outils libres d'évaluation de la qualité des F/OSS, car elle permet de calculer et d'intégrer les mesures de divers produits et procédés industriels. Le logiciel produit par la recherche

de Spinellis et ses collaborateurs est appelé Alitheia [114]. Il ne se limite pas à un

seul langage de programmation comme il est souvent le cas de la plupart d'outils

libres d'analyse de code en F/OSS [114].

3.2.2 Comparaison de F/OSS et logiciels commerciaux

Certains logiciels libres sont d'une qualité comparable, voir supérieure aux logiciels

propriétaires [67, 108]. L'une des raisons conduisant à cette qualité élevée dans les

logiciels libres est que, contrairement au développement traditionnel de logiciels, les

développeurs dans les F/OSS sont eux-mêmes les utilisateurs du logiciel développé

ou maintenu, et ils sont donc plus pointilleux dans leur développement, rendant ainsi

(46)

non-organisée du processus de développement des logiciels libres ainsi que son manque

apparent de mécanismes d'assurance qualité [ 115], contrairement au développement

dans les industries, posent un réel problème à ces dernières car elles s'avèrent

dépendre de plus en plus des produits développés dans les communautés de F/OSS

[91]. Afin de pallier à ce problème qualité des logiciels libres, des modèles de

maturité et d'évaluation, particulièrement, l'Open Source Maturity Mode! (OSMM)

[63] et le Business Readiness Rating (BBR) [1], ont été développés pour évaluer la

durabilité d'un projet de F/OSS.

Mockus et ses collaborateurs [94] ont eu à identifier quatre différences entre le

développement de F/OSS et celui de logiciels commerciaux. Ces différences sont les

suivantes : «

Les FIOSS sont construits par un nombre potentiellement élevé de bénévoles; Le travail n'est pas assigné aux participants, les personnes entreprennent les travaux qu'elles désirent faire;

Il n

y

a aucune conception explicite au nzveau du système, ou même une conception détaillée du système;

Il n y a aucun plan de projet, de calendrier, ou liste des livrables. »

Aberdour [26] quant à lui, a eu à prolonger le travail de Mockus et ses collaborateurs

[94 ], en identifiant des différences en termes de pratiques de gestion de la qualité

entre le développement de F/OSS et le développement en entreprise (voir tableau

Figure

Figure 2.1  Culture e n gé nie  logiciel  [121]
Tableau 3.1  Quelques li cences de F/OSS
Figure 3.1  Structure de  l'équipe de développement des F/OSS
Tableau  3.2 Comparaison des pratiques  de gestion de  la  qualité [26)
+7

Références

Documents relatifs

A travers cette recherche, nous allons essayer de montrer : Comment la démarche qualité peut être installée au sein du processus gestion des ressources

Méthodes de développement pour .: construire des systèmes opérationnels .: organiser le travail dans le projet .: gérer le cycle de vie complet .: gérer les coûts .: gérer les

réparation, il peut choisir de ne pas faire le remplacement et de repartir avec le véhicule en l’état en ayant réglé les frais de main d’œuvre.. Ecrivez un cas

Le dispositif Point permet d’avoir plusieurs applications ou objets qui s’écoutent et ce pattern permet aux objets de communiquer entre eux pour maintenir une cohérence globale et

Avant-propos Génie logiciel Méthodes Activités Outils. Documentation

Cette situation est beaucoup plus proche de la position dominante que du monopole de fait. Cela signifie que sur le marché en cause, on ne voit pas de concurrent qui a

A la lecture de ces exigences, chacun est libre de les apprécier à sa manière. Une chose est certaine, aujourd’hui le monde économique est partagé entre les pro et les anti-ISO

– Ensemble d'attributs portant sur l'aptitude du logiciel à maintenir son niveau de service dans des conditions précises et pendant une période déterminée.