Logiciel d�fectueux

ArticleCategory: [Choose a category, translators: do not translate this, see list below for available categories]

AuthorImage:[Here we need a little image from you]

TranslationInfo:[Author + translation history. mailto: or http://homepage]

original in de Ralf Wieland

de to en Guido Socher

en to fr Jean-Etienne Poirrier

AboutTheAuthor:[A small biography about the author]

Je d�veloppe un syst�me de simulation tri-dimensionnelle d'Eco et de simulation d'environnement : (SAMT). Il est bas� sur la logique floue, les r�seaux neuronaux et les automates cellulaires. Il tourne sous Linux, que j'utilise depuis la version 0.99pl12.

Abstract:[Here you write a little summary]

ArticleIllustration:[One image that will end up at the top of the article]

ArticleBody:[The main part of the article]

Les d�fauts dans les logiciels Source Ouvert contre les d�fauts dans les logiciels � Source Ferm�

La question de savoir qui, des logiciels Source Ouvert ou des Source Ferm�, sont les meilleurs, a �t� abondamment discut� dans les divers magazines informatique. Les r�sultats sont compl�tement diff�rents en fonction du c�t� qui commandite l'�tude. Les utilisateurs de logiciels et les lecteurs de magazines ne gagnent pas grand chose de ces discussions. Elles g�n�rent juste plus de confusion et de frustrations. L'int�r�t de cette question, potentiellement tr�s int�ressante, dispara�t rapidement.

La situation me rappelle les temps des tests du mat�riel et du cpu. Chaque nouveau � test � apporte de nouveaux ordinateurs qui vont battre de loin les anciens mod�les mais, lorsque vous achetez r�ellement un tel ordinateur, le r�sultat n'est pas le m�me.

Aujourd'hui, les m�mes discussions ont d�but� dans le champ de bataille des d�fauts de logiciels.

Je vais essayer d'�claircir un peu la situation en utilisant un mod�le simple et compr�hensible.

Un mod�le simple

Les logiciels Source Ouvert et Source Ferm� contiennent des d�fauts. Je suppose que les programmeurs des deux c�t�s sont aussi bons et produisent, en cons�quence, la m�me densit� moyenne de d�fauts. Les soci�t�s de d�veloppement de logiciels � Source Ferm� vont employer des testeurs pour �liminer les bogues. D'un point de vue �conomique, c'est tout b�n�fices pour eux, jusqu'� un certain point mais �galement parce que les clients peuvent les poursuivre en justice si les fonctions essentielles ne fonctionnent pas.
Dans le cas des logiciels Source Ouvert, la pression n'est pas aussi grande. La GPL exclut toutes garanties et responsabilit�s. En d�pit de cela, la qualit� et la s�curit� des logiciels Source Ouvert semble �tre tr�s grande.

Pour mon mod�le, je suppose que tant le logiciel � Source Ferm� que le logiciel � Source Ouvert impl�mentent la m�me fonctionnalit� et que tous les deux contiennent 100 d�fauts.

Pour la premi�re simulation, je fais les suppositions suivantes. La compagnie de logiciel trouve et corrige 20 d�fauts en utilisant des tests �tendus. Le d�veloppeur Source Ouvert distribue aussit�t que possible et n'effectue pas de tests �tendus. Pour compenser la phase de test manquante, le d�veloppeur Source Ouvert travaille en �troite collaboration avec les utilisateurs et corrige 80% des d�fauts (m�me avec le Source Ouvert, 100% n'est pas possible ; de temps en temps, de nouveaux d�fauts sont ajout�s lors de la correction de d�fauts existants). Gr�ce � la disponibilit� du code source, environ 10% des d�fauts sont corrig�s par mois.

La situation est tr�s diff�rente pour la partie � Source Ferm�. Il est plus difficile de trouver les d�fauts. Dans ce mod�le, 8% des fautes sont rapport�es (une valeur tr�s optimiste). Pour la compagnie � Source Ferm�, le processus de correction des d�fauts est habituellement tr�s co�teux. La compagnie va, d�s lors, essayer de ne corriger que les d�fauts importants. Ceci est, bien s�r un mod�le et je serai tr�s int�ress� d'utiliser des donn�es r�elles, un jour.

	Source Ouvert			Source Ferm�
Mois	erreurs	rapport�es	corrig�es	erreurs	rapport�es	corrig�es
1	100	10	8	80	6,4	3,2
2	92	9,2	7,4	76,8	6,1	3,1
3	84,6	8,5	6,8	73,7	5,9	2,9
4	77,9	7,8	6,2	70,8	5,7	2,8
5	71,6	7,2	5,7	67,9	5,4	2,7
6	65,9	6,6	5,3	65,2	5,2	2,6
7	60,6	6,1	4,9	62,6	5	2,5
8	55,8	5,6	4,5	60,1	4,8	2,4
9	51,3	5,1	4,1	57,7	4,6	2,3
10	47,2	4,7	3,8	55,4	4,4	2,2
11	43,4	4,3	3,5	53,2	4,3	2,1
12	40	4	3,2	51,1	4,1	2

Si vous regardez le nombre de d�fauts apr�s que les programmes aient �t� utilis�s pendant un an, la variante Source Ouvert a un l�ger avantage. Apr�s une demi-ann�e, le taux de d�fauts est �quivalent. En d'autres mots, les utilisateurs de logiciels Source Ouvert doivent s'attendre � beaucoup plus de patches et corrections au d�but. La quantit� de mises � jour va engendrer un co�t plus �lev�. Apr�s cette p�riode de stabilisation, la situation change. Maintenant, le logiciel Source Ouvert est de meilleure qualit� et engendre moins de co�ts d�s aux mises � jour.

Dans une seconde simulation, je suis parti de conditions �gales, tant pour le logiciel Source Ouvert que le logiciel � Source Ferm�. Tous les deux ont subi des tests �tendus avant leur diffusion officielle.

	Source Ouvert			Source Ferm�
Mois	erreurs	rapport�es	corrig�es	erreurs	rapport�es	corrig�es
1	80	8	6,4	80	6,4	3,2
2	73,6	7,4	5,9	76,8	6,1	3,1
3	67,7	6,8	5,4	73,7	5,9	2,9
4	62,3	6,2	5	70,8	5,7	2,8
5	57,3	5,7	4,6	67,9	5,4	2,7
6	52,7	5,3	4,2	65,2	5,2	2,6
7	48,5	4,9	3,9	62,6	5	2,5
8	44,6	4,5	3,6	60,1	4,8	2,4
9	41,1	4,1	3,3	57,7	4,6	2,3
10	37,8	3,8	3	55,4	4,4	2,2
11	34,8	3,5	2,8	53,2	4,3	2,1
12	32	3,2	2,6	51,1	4,1	2

Maintenant, la situation semble beaucoup mieux pour le Source Ouvert. Un test �tendu est important. C'est �galement dans ce contexte que vous devez voir ce rapport de ZD-Net : � Le co-mainteneur du noyau Linux, Andrew Morton, a averti qu'un d�faut d'engagement dans les tests de la part de la communaut� Linux pourrait, en d�finitive, menacer la stabilit� du syst�me d'exploitation �.
Il trouve que la phase de test n'est plus s�curis�e et que laisser le plus gros des tests �tre r�alis� par les utilisateurs finaux n'est que la seconde meilleure solution.

Comment quantifier ce mod�le

Ce mod�le est bas� sur des suppositions tr�s simples. Le taux auquel les d�fauts sont d�couverts est, par exemple, suppos� constant. En r�alit�, cela ne sera pas le cas. Un nouveau programme sera test� par des utilisateurs tr�s int�ress�s et, ici, un nombre important de d�fauts devrait �tre trouv�. Apr�s qu'un nombre plus important d'utilisateurs soit arriv� � utiliser le logiciel, la quantit� de d�faut trouv� en fonction du temps change. Il peut aussi bien augmenter que diminuer. Cela d�pend de la quantit� de fautes restantes, de l'activit� et de la connaissance des utilisateurs. Dans des phases plus avanc�es, le taux avec lequel les fautes sont trouv�es chute, non seulement parce que le nombre de d�fauts restant est moindre mais aussi parce que l'int�r�t des utilisateurs chute �galement.
La volont� des utilisateurs d'appliquer des patch ou de mettre � jour sera r�duite au cours du temps.

Fiabilit�

L'�quipement technique (par exemple, les machines) ont, statistiquement, des taux d'�chec diff�rents au cours de leur temps de vie. Au d�but, le taux d'�chec est �lev� et, apr�s une phase assez chaude, suit une p�riode avec un taux d'�chec tr�s bas. A la fin de la dur�e de vie pr�vue, le taux d'�chec augmente de nouveau.

A premi�re vue, il semble que cela doit �tre diff�rent pour les logiciels puisqu'il est am�lior� tout le temps. Ce n'est cependant pas le cas. Une des raisons principales de cela est que l'�quipe de d�veloppement change le logiciel apr�s un certain temps (tant en Source Ouvert qu'en Source Ferm�). Le d�veloppeur principal peut avoir quitt� le projet. Vous pouvez facilement avoir une courbe similaire � celles que nous avons avec le mat�riel.

Nombre d'erreurs

Le nombre absolu d'erreurs dans un projet logiciel n'est jamais connu. Il est seulement possible de l'estimer (par exemple : 1 erreur pour 1000 lignes de code). Cette estimation d�pend cependant du type de logiciel et de l'exp�rience du programmeur.
De nombreuses �tudes utilisent le nombre de fautes trouv�es en fonction du temps comme mesure. Ces �tudes pr�tendent que les logiciels � Source Ferm� sont de meilleure qualit�. C'est cependant faux. L'important est le nombre de fautes qui sont laiss�es. Il est important pour notre projet (www.samt-lsa.org) d'inclure les utilisateurs au processus de d�veloppement. L'utilisateur re�oit souvent des patches et des mises � jour. En �change, des id�es pour des d�veloppement futurs ainsi que des rapports d'erreurs reviennent. C'est une solution optimale pour un logiciel scientifique.

Conclusion