Le principe de développement des LL, grâce aux libertés offertes par les licences, est que le client peut modifier le logiciel. Bien sûr, les clients/utilisateurs n'ont pas forcément les compétences pour développer, mais ils peuvent influencer le développement : par exemple en demandant des développements plus rapides (cycle release->test_utilisateur->anomalie->release) ou un processus de développement plus sûr (avec des tests de non-regression, des circuits de relecture, des métriques à chaque version, etc.).
Bref, le client est forcément satisfait puisqu'il décide/influence directement. D'après ta definition de la qualité, je serais donc d'avis de conlure que les LL sont un très bon moyen de garantir la qualité d'un logiciel.
Par contre, il est évident que le principe de fonctionnement est différent de celui du monde industriel.
Je pense que tu as tort quand tu pose la question Comment allez-vous assurer à vos "clients" que vous tenez votre rang ? C'est au client de definir la réponse à cette question et de donner les moyens (en participant) d'y parvenir.
Professionnellement, je suis ingénieur dans une SSII (pour le spatial). Nos clients nous bassinent avec la QUALITE mais ils sont bien incapables de mettre une définition derriere ce terme, et ils sont rarement prets à mettre les moyens pour l'obtenir. Du coup, la QUALITE se traduit par d'interminables TRACES (grand terme de la QUALITE) que personne n'exploite et qui incite à TORCHER le code car y'a des rapports à produire et temps nous est compté.
Avec ma petite expérience, la qualité du logiciel est finalement obtenue grâce aux compétences des développeurs plus que grâce aux règles qui sont imposées par des gens qui n'ont plus les compétences de développer (Lois de Peter).
[^] # Re: Moi aussi j'ai une question !
Posté par Bonnefille Guilhem . En réponse à la dépêche Article de LinuxFrench sur GNU/Hurd. Évalué à 1.
Le principe de développement des LL, grâce aux libertés offertes par les licences, est que le client peut modifier le logiciel. Bien sûr, les clients/utilisateurs n'ont pas forcément les compétences pour développer, mais ils peuvent influencer le développement : par exemple en demandant des développements plus rapides (cycle release->test_utilisateur->anomalie->release) ou un processus de développement plus sûr (avec des tests de non-regression, des circuits de relecture, des métriques à chaque version, etc.).
Bref, le client est forcément satisfait puisqu'il décide/influence directement. D'après ta definition de la qualité, je serais donc d'avis de conlure que les LL sont un très bon moyen de garantir la qualité d'un logiciel.
Par contre, il est évident que le principe de fonctionnement est différent de celui du monde industriel.
Je pense que tu as tort quand tu pose la question Comment allez-vous assurer à vos "clients" que vous tenez votre rang ? C'est au client de definir la réponse à cette question et de donner les moyens (en participant) d'y parvenir.
Professionnellement, je suis ingénieur dans une SSII (pour le spatial). Nos clients nous bassinent avec la QUALITE mais ils sont bien incapables de mettre une définition derriere ce terme, et ils sont rarement prets à mettre les moyens pour l'obtenir. Du coup, la QUALITE se traduit par d'interminables TRACES (grand terme de la QUALITE) que personne n'exploite et qui incite à TORCHER le code car y'a des rapports à produire et temps nous est compté.
Avec ma petite expérience, la qualité du logiciel est finalement obtenue grâce aux compétences des développeurs plus que grâce aux règles qui sont imposées par des gens qui n'ont plus les compétences de développer (Lois de Peter).