Moins de 50% des logiciels tiers seraient testés par leurs utilisateurs

[Hinault Romaric]

Moins de 50% des logiciels tiers seraient testés par leurs utilisateurs
Mettant les développeurs dans une situation contradictoire, selon Forrester

Une étude du cabinet d'analyse Forester révèle que moins de la moitié des codes logiciels tiers sont testés au niveau de leur qualité et de leur sécurité.

L'étude, dénommée Software Integrity Risk Repor, a été menée auprès de 336 professionnels du développement applicatif en Amérique du Nord et en Europe sur le thème de l'intégrité logicielle, avec pour objectif d'analyser les pratiques actuelles et les tendances du marché en matière de qualité et de sécurité des logiciels.

Le rapport montre que la majorité des entreprises utilisent des codes logiciels tiers fournis par de nombreux partenaires (plus de 90 % des responsables interrogées confirment avoir recours à des codes tiers fournis par des éditeurs, des équipes sous-traitantes ou des fournisseurs d'open source).

La qualité de ces logiciels tiers a un impact significatif sur le rendement de l'entreprise. Selon le rapport, plus de 40% des responsables interrogés ont souligné le fait que les défauts des codes logiciels tiers provoquent des retards de mise sur le marché, des rappels de produits, des failles de sécurité, des allongements dans les délais de développement et des baisses de revenus.

Pourtant, il existerait un fossé entre les tests effectués sur les codes développés en interne et ceux effectués sur les codes provenant de partenaires tiers. Seules 44% des entreprises interrogées procèdent, pendant les phases de développement, à des tests de code automatisés sur les codes fournis par des partenaires. Contre 69% pour les codes développés en interne.

Pire, seules 35% des entreprises interrogées effectuent des évaluations de risques, de sécurité et de vulnérabilité pour les codes logiciels tiers qu'elles utilisent dans leurs développements (contre 70% pour logiciels développés en interne).

Les écarts d'assurance qualité sont également mis en exergue par Forrester. 51% des entreprises interrogées déclarant effectuer des tests fonctionnels, de charge et d'unité automatisés pour les logiciels fournis par des partenaires tiers. Tandis que 75% appliquent ces mêmes méthodes aux logiciels développés en interne

L'étude montre également que 74% des entreprises considèrent que les développeurs doivent rendre plus de comptes en matière d'objectifs de qualité et de sécurité qu'il ne le faisait un an auparavant. Autre fait marquant, la moitié (51%) évalue leurs développeurs en fonction de la satisfaction du client et en fonction des bugs dans le code publié.

« Les données fournies par l'étude donnent de très bons éclairages sur les changements qui s'opèrent en matière de gestion de la qualité logicielle », commente Dave Peterson, Chief Marketing Officer chez Coverity. « Les équipes de développement sont aujourd'hui au cœur de ces démarches en termes de responsabilité. Les développeurs sont responsables à 100% de la réussite de leurs logiciels, alors qu'ils ne contrôlent que peu les logiciels fournis par leurs partenaires. Cette situation génère une forte demande de la part des entreprises souhaitant pouvoir contrôler et gouverner l'ensemble de la chaîne de développement ».

En vain ?

Source : Coverity


Et vous ?

Que pensez-vous de la responsabilité du développeurs dans la qualité du logiciel ?
Controlez-vous la qualité et la sécurité des codes tiers que vous utilisez ?

[ddrmax]

Que pensez-vous de la responsabilité du développeurs dans la qualité du logiciel ?

le dévellopeur c'est comme un mécano, il est responsable de ce qu'il fait,
si un mécano pour etre plus productif laisserait tomber la verification du serrage des pieces qu'il installe et si ce qu'il a installer et bien fonctionnel, on finirait par avoir une floppée d'accident
et si mon mecano ne fait pas le remplacement du liquide de frein normalement, je me poinerais direct avec ma caisse a outils pour reparrer le tout.
Bah pour le développeur c'est pareil, quand il code sur un logiciel, il suit tout une procedure.
pour moi on doit normalement avoir cette méthode:

Sachant que chaque descente est soumise a validation et que dans le cas contraire remonte en passant par la case débogage.
Le contrôle qualité primaire doit être fait par les developpeurs et ceci concerne aussi les codes et composants tiers.
Pour ma part, j'utilise des codes et logiciels tiers (par exemple les codes disponibles sur developpez ou autres sites avec des codes sous licences non restricitive quand a la mise en disposition dans un logiciel commercial)
j'utilise dans un de mes logiciels le composant GeoMap de SDL, il a passé tout une batterie de tests (ou j'ai pu me rendre compte que mes cartographies etaient trop grandes donc j'ai fait mon propre systeme d'affichage avec l'utilisation du composant pour le calcul de cordonnées GPS vers le XY en pixels pour ma carte)

Par contre c'est pas aux developpeurs de tout se tapper niveau contrôle qualité, car normalement une equipe qualité se charge de faire la seconde partie, car c'est cette equipe qui est plus proche de la vision utilisateur.

Pour info dans nôtre entreprise l'equipe qualité est constituée d'un ou plusieurs techniciens de l'entreprise, un techinicien de l'entreprise pour lequel on sous traite et le client en lui même (du moins en partie)

tout ça permet de regler certains soucis dont les plus anodins (du genre des fautes d'orthographe)

Controlez-vous la qualité et la sécurité des codes tiers que vous utilisez ?

Oui, une partie répondue au dessus.
Par contre le plus embetant et de contrôler l'effet de certains codes ou composants tiers sur la machine finale (OS ou materiels differents) car on a aucun pouvoir de contrôle comme pour les composants COM et ActiveX qui peuvent causer des soucis que l'on ne peut reproduire (Le cas le plus flagrand c'est nous est un activeX d'un de nos partenaire qui sert de client OPC vers leur système qui a un comportement parfois aleatoire (Active X VB en utilisation sur C++ builder) et Mappoint (fonctionne nickel chez nous mais sur un win server 2003 ça passe pas et chez certains client (sur Win XP/Vista/7) il arrive que mappoint bug totalement et devienne inutilisable)