L'hyperespace du danger et son application aux risques logiciels.
L'hyperespace du danger et son application aux risques logiciels.
Bernard Homès M. Sc., membre (Belge) de l'IEC est consultant, conférencier international et spécialiste reconnu en tests de logiciels. Il est aussi membre du bureau Français de l'IEEE (Assistant VP), et du Comité Aviseur de conférences sur la qualité logicielle, et participe au groupe de travail de mise à jour de la norme IEEE Std 1074-1997 (Standard for Developing Software Life Cycle Processes).
Il fournit en synthèse un tableau récapitulatifs des Déficits Systèmiques Cindyniques que vous trouverez dans la version PDF de la lettre.
NDLR
L'Hyper-Espace du danger a démontré son utilité dans l'analyse et la recherche des dysfonctionnements et catastrophes, industrielles ou non. Son application aux risques logiciels permet de démontrer que de tels risques peuvent être traités de la même manière systémique.
Résumé
Après avoir proposé des exemples d'application des DSC dans le monde des SSII (sociétés de services et d'ingénierie informatique), nous verrons comment ces DSC peuvent s'adapter à l'hyperespace du danger. Ensuite nous verrons comment la réduction des risques et l'amélioration de la qualité des logiciels peut bénéficier de méthodes, normes et techniques utilisées dans les tests de logiciels. En conclusion nous proposons diverses méthodes pour implémenter ces techniques sur le marché, en prenant en compte les impératifs économiques des sociétés.
Introduction
L'informatique est souvent considérée par les profanes comme le fut l'alchimie il y a plusieurs siècles : une science opaque pratiquée dans des endroits reculés de l'entreprise par des (pseudo) savants utilisant des termes totalement inconnus des non-initiés (sgbd, java, bluetooth, interface, …). Promettant beaucoup les réalisations n'étaient généralement pas à la hauteur des investissements consentis. La recherche de la pierre philosophale n'est pas différente de la frénésie s'étant emparé de beaucoup de nos concitoyens lors de la période de la bulle Internet.
A une époque où la rentabilité des investissements d'une entreprise devient primordiale, l'atteinte des objectifs fixés dans le respect des coûts et des délais est une priorité. Tout ce qui peut avoir un impact sur ces aspects devient un risque qui ne peut plus être considéré comme mineur.
Les méthodes cindyniques ont montré leur applicabilité dans divers domaines de détection des risques industriels, leur application est aussi possible dans le domaine des risques logiciels.
Définition des risques informatiques
Un projet informatique est un ensemble de tâches administratives et techniques dont la finalité est l'atteinte d'un objectif défini par la hiérarchie. Pour être considéré comme un projet informatique, les tâches techniques doivent &endash; partiellement ou totalement &endash; s'appuyer sur les techniques informatiques telles programmation et/ou développement de logiciels. Un risque sur le projet est toute action qui a un impact sur la réalisation du projet, que ce soit en augmentant la durée et/ou le coût de réalisation de ce projet. Donc tout retard ou toute augmentation du coût du projet est considéré comme un risque, même s'il ne s'applique pas directement à des tâches techniques.
De la même façon nous pouvons étendre le panorama d'application pour inclure l'utilisation des produits logiciels développés. Il est en effet évident qu'un produit logiciel a une fonction de production tout comme un tour ou un moteur. Le mauvais fonctionnement du logiciel est à évaluer au même titre que le mauvais fonctionnement d'un moteur est aussi à évaluer.
Nous nous trouvons donc avec un paradigme où l'utilisation de l'outil informatique de même que sa conception définissent le périmètre des risques logiciels : Un projet qui prend plus de temps ou de ressources que prévu pour être terminé est un projet qui a subi un risque ; si ce projet est un projet de réalisation d'un logiciel ou met en œuvre des outils logiciels il sera donc considéré comme un projet informatique et à ce titre le risque est un risque informatique.
Séparation des risques
Dans le paradigme il est nécessaire de séparer les deux aspects du problème :
Le premier cas n'est pas foncièrement différent de l'utilisation d'un outil pour exécuter une tâche : il faut que l'outil soit adapté à la tâche. La difficulté vient de ce que les tâches à exécuter sont plus complexe et que la spécification d'un outil pour les réaliser est de ce fait plus ardue. L'absence de normes de conception et de définition de spécifications ne rend pas la tâche plus facile. L'outil logiciel est généralement conçu de manière à ce que tous les utilisateurs de cet outil, quelle que soit leur tâche, soient connectés au même outil, un peu comme si tous les outils d'un garage étaient regroupés en un seul, utilisable simultanément par tous les mécaniciens. Il est évident qu'en cas de mauvais fonctionnement, tous sont affectés, ce qui n'est pas le cas si différentes tailles (et/ou marques) de tournevis (par exemple) sont utilisés : en cas de défaillance (bris, perte, …) d'un tournevis, un autre peut être utilisé en remplacement.
Le second cas est similaire à la conception d'un ouvrage d'art (bâtiment, port, échangeur autoroutier, …) faisant intervenir plusieurs corps de métier. Il ne viendrait à l'idée de personne de construire une maison sans en faire les plans, les architectes et les ingénieurs de constructions connaissent les standards minimaux pour l'inclinaison des canalisations, des normes existent concernant le nombre et la taille des issues de secours pour les établissements recevant du public. Actuellement, la conception de logiciels est traitée comme un art1 plutôt que comme une science2. Les standards, normes et méthodes sont appliqués de manière non systématique et leur interprétation varie selon les praticiens. Les risques informatique dans ce cas sont donc des risques de fonctionnement incorrect ou non satisfaisant générant une application insatisfaisante, et des risques de dépassement des délais et budgets pour atteindre un fonctionnement correct.
Illustration par des exemples
Afin de mieux appréhender l'utilisation des dix Déficits Structurels Cindynogènes (DSC) et les mettre en rapport avec des cas concrets de risques informatiques, prenons quelques exemples, associés à chacun des DSC. Les exemples proposés sont tirés, pour la plupart, d'expériences vécues au sein de SSII françaises :
DSC1 : Culture d'infaillibilité :
Pour convaincre un prospect, le commercial ou le directeur de projet annonce que leur SSII est tout à fait capable de résoudre le problème du client, qu'ils ont déjà fait cela pour d'autres clients (montrent une liste de clients grand comptes pour convaincre le prospect). Bien sûr « nous avons les spécialistes et les experts adéquats ». De retour dans leur SSII, il est décidé de former sur le tas un ou plusieurs ingénieurs pour les faire paraître « expert » ou « spécialiste » aux yeux du client. Comme s'il était possible de former un spécialiste en quelques jours…
DSC2 : Culture du simplisme :
Explication souvent entendue dans la bouche de divers responsables : « c'est simple, on fait un prototype puis on l'adapte ». En fait cela revient à simuler un traitement mono-utilisateur et mono-poste puis à augmenter la taille des bases de données et le nombre des utilisateurs. C'est à ce moment que l'on se rend compte des problèmes d'accès concurrent au même enregistrement (faut-il prévenir qu'un autre utilisateur utilise l'enregistrement ?; qui a priorité en cas de sauvegarde ?), des problèmes de backups (on ne peut pas effectuer le backup s'il reste un utilisateur connecté, mais ils sont répartis dans tout le pays), de problèmes de sécurité etc qui n'ont pas été prévus initialement.
DSC3 : Culture de la non-communication :
Dans le cadre d'un projet impliquant de multiples systèmes et donc de multiples équipes de conception (internes et sous-traitants), il est arrivé de nombreuses fois que les équipes ne communiquent pas entre elles, résultant en un échange de données dans des formats incompatibles (ASCII3 vs EBCDIC4).
DSC4 : Culture du nombrilisme :
Dans un projet de la NASA (sonde d'exploration de Mars), les programmes de guidance étaient développés d'une part en Europe (avec une mesure en Km/sec.) et d'autre part aux USA (avec une mesure en Milles/sec.). Ni l'une ni l'autre des deux équipes ne se sont préoccupé de la possibilité de différence d'unité de mesure, chacune prenant l'unité de mesure qui leur était habituelle.
DSC5 : Subordination des risques à la production :
Beaucoup de SSII fournissent ou mettent sur le marché, sciemment et en connaissance de cause, des applications dont la qualité est médiocre. Ceci uniquement pour satisfaire des dates de livraison associées à des pénalités de retard. Comme le niveau de qualité n'est pas spécifié, ils fournissent ensuite des patches5 et autres corrections jusqu'à atteindre le niveau de qualité souhaité ou le montant total des investissements que le client peut se permettre.
DSC6 : Dilution des responsabilités :
La multiplicité des intervenants et la différence de compétences techniques entre les intervenants mène souvent à une dilution des responsabilités : les techniciens rejetant la faute à d'autres techniciens, ou à de mauvaises spécifications, voire à des sous-traitants (ou co-traitants), quand ce n'est pas à des produits qu'ils auraient eux-même proposé (cf projet Socrate à la SNCF).
DSC7 : Absence de retour d'expérience :
Dans la conception d'applications logicielles, il est rare qu'une SSII conçoive plusieurs fois le même logiciel. Le retour d'expérience est donc restreint. De plus le taux de renouvellement des équipes (de l'ordre de 30%) implique que les effectifs sont quasi totalement renouvelés après 3 ans, ce qui ne facilite pas le retour d'expérience. L'analyse des expériences des autres acteurs de la profession est rendu malaisé par un manque de communications et de statistiques.
DSC8 : Absence de méthode cindynique :
Dans la majorité des SSII, l'absence de préconisations écrites de la direction et/ou de l'encadrement laisse libre court à la créativité (ou l'absence de créativité) de chacun des intervenants. En ce qui concerne la sécurité des données informatiques, cet aspect est généralement traité une fois que l'aspect fonctionnel de l'application a été traité correctement. Les risques d'effets de bords entre deux applications ne sont généralement pas traités et n'apparaissent que lors des retours (plaintes) de la part des utilisateurs.Dans une banque, le mauvais fonctionnement d'un programme de reprise de données de nuit détruit les informations sur les supports de sauvegarde. Les opérateurs, suivant la procédure en cas de non fonctionnement, reprennent les supports de la journée précédente (même souci) puis des journées antérieures (même souci). Quand ils demandent l'accès au coffre pour prendre la dernière des sauvegardes disponibles, le responsable de l'accès au coffre demande l'autorisation au responsable informatique qui, au vu des informations disponibles, interdit la mise à disposition et sauvegarde ainsi les données comptables concernant plusieurs centaines de milliers de clients.
DSC9 : Absence de formations aux risques :
La formation aux risques des ingénieurs et techniciens informatiques est totalement absente des cursus de formation, ou n'est mentionné qu'à titre connexe dans certains cas. Ceci est du partiellement à l'absence de statistiques fiables et détaillées sur les causes des dysfonctionnements des applications.
DSC10 : Absence de planification des situations de crise :
Lors d'une anomalie majeure remettant en question le projet, seuls quelques décideurs (commerciaux et directeurs) se réunissent afin de déterminer la meilleure stratégie. La crise n'est traitée que sous son aspect économique et en fonction de l'impact que cela peut avoir sur la comptabilité de l'entreprise ou la poursuite de ses relations commerciales avec son client.
Une nouvelle approche ?
L'analyse des causes des retards ou des dépassements de budget des projets informatiques a fait l'objet de nombreuses études, tant en Europe qu'en Amérique du nord. Les arguments avancés par leurs auteurs varient, mais peuvent se regrouper en trois axes :
Le niveau de pénétration de ces solutions est variable selon les cultures, important dans les cultures germaniques et anglo-saxonnes, faible dans les pays de culture latine. Il suffit pour se convaincre de ce fait de comparer le nombre de livres publiés sur les tests de logiciels en anglais et en français.
Dans un monde où les échanges et les techniques sont à la base de la réussite économique des structures (états, sociétés, individus), la réduction des risques sur les projets est une priorité. L'approche par les DSC et l'hyperespace du danger fourni une approche nouvelle et prometteuse.
Adaptation des DSC à l'Hyperespace du danger
L'hyperespace du danger (voir page ) permet de regrouper de façon graphique les différentes causes de risques. Nous fournissons ci-dessous une proposition d'adaptation des DSC aux diverses dimensions de l'hyperespace,
Axe Statistique : Dimension des faits de mémoire de l'histoire et des statistiques, DSC : 7
Axe Epistémique : Dimension des représentations et modèles élaborés à partir des faits DSC : 1, 3, 8
Axe des Finalités : Dimension des objectifs et finalités (traduction sociale de l'entreprise) DSC : 2, 3, 4, 5
Axe Déontologique : Dimension des lois, normes, règles et standards, obligatoires ou libres DSC : 3, 6, 8
Axe Axiologique : Dimension des systèmes de valeur des référents DSC 5, 6, 9, 10
Figure : Hyperespace du Danger
Réduction des risques et amélioration de la qualité des logiciels
Plusieurs méthodes et techniques sont utilisées dans le but d'améliorer la qualité des logiciels :
Ces méthodes ont pour but de détecter des anomalies qui auraient été introduites dans les logiciels. Ce sont donc des méthodes qui se situent en aval du codage et potentiellement sur le chemin critique de la livraison (mise sur le marché).
Ces méthodes et techniques ont pour but de prévenir des anomalies futures, soit en se basant sur les anomalies existantes (FMEA, gestion de configuration et d'anomalies), soit en recherchant les incohérences dans les spécifications ou dans le code, préalablement à leur utilisation (V&V, Revues de code et de documents)
Diverses normes ont pour but de formaliser les développements logiciels et de fournir une documentation servant de référence pour le codage. Ces normes, méthodes et standards peuvent être utilisées dans le cadre de développements logiciels de manière à réduire les risques logiciels. S'il est certain que l'utilisation de ces normes et standards auront dans un premier temps un effet de ralentissement de la production informatique, dans un second temps &endash; généralement assez rapidement &endash; des résultats positifs se font sentir.
Pour l'exemple voici différentes normes pouvant s'appliquer à certains aspects de la qualité des logiciels :
Toute politique d'amélioration de la qualité des logiciels produits doit être implémentée en prenant en compte les DSC.
Dimension statistique :
Diverses études, majoritairement nord américaines, démontrent l'impact de la non qualité au cours de l'évolution d'un logiciel. En général le coût d'une correction est 200 fois plus élevé si elle intervient au moment de la livraison du système qu'au moment de la conception de ce système10. 75% des projets ne se terminent pas dans les délais ni dans les coûts initialement estimés11.
L'absence de statistiques en France ne doit pas servir de prétexte pour penser que les concepteurs de logiciels nationaux sont meilleurs ; aucune raison ne laisse penser cela, surtout si l'on se rapporte à l'absence de percée sur le marché mondial des logiciels français.
Dimension épistémique :
Certains modèles existent permettant de déterminer un taux d'anomalies par milliers de ligne de code ; d'autres modèles mathématiques sont disponibles pour déterminer la charge de développement (et de tests) nécessaire pour réaliser un logiciel12. L'utilisation de ces modèles est généralement repoussée au profit de l'estimation empirique de tel ou tel ingénieur, réduite par le commercial pour tenir dans les budgets du client.
Dimension des finalités :
Le nombre important d'acteurs impliqués dans la définition des finalités en rend la définition risquée. D'une part nous avons les utilisateurs d'un produit informatique, d'autre part les aspects économiques dans le cadre de la conception d'applications informatiques par les SSII. La finalité pour les utilisateurs d'une application informatique est que l'application facilite leurs tâches. La finalité pour les SSII est que le client paye les prestations qui lui sont fournies. Les objectifs sont donc totalement différents, quasiment opposés. Pour l'aspect économique la finalité est de produire l'application au moindre coût et dans les délais les plus courts. Pour l'aspect utilisation, le bon fonctionnement de l'application est
Dimension déontologique :
Nous avons vu qu'un nombre important de règles et de normes ont été produites par des organismes de normalisation reconnus (IEEE, ISO, ANSI), cependant leur utilisation très réduite. Leur enseignement est plus que confidentiel et leur percée dans la profession est extrêmement faible. Il est donc compréhensible que leur utilisation reste confidentielle.
Outre les normes mentionnées ci-avant, il existe un certain nombre de règles, écrites ou non, déterminant le mode de fonctionnement des composants logiciels visibles par l'utilisateur : un bouton a par défaut telle forme et tel mode de fonctionnement (variant selon le système PC ou Mac), ceci est aussi applicable pour les autres composants d'un écran ou d'une page web.
Dimension axiologique :
Le système de valeur dans le cadre des applications logicielles est difficile à déterminer. Il peut être déterminé par la valeur ajoutée fournie à l'exécution des tâches des utilisateurs (réduction du temps, augmentation de la productivité), il peut être déterminé par le coût du logiciel, ou par la valeur que met l'utilisateur à des données fiables. Pour un même coût de logiciel, la valeur peut être différente s'il s'agit d'un logiciel de suivi des patients dans une salle de soins intensifs, d'un logiciel d'achat/vente d'actions dans une salle de marchés, ou un logiciel de jeu vidéo.
Implémentation de la réduction des risques
L'implémentation peut venir de deux sources majeures :
Si la profession de testeur de logiciels a connu un essor important outre-Atlantique, c'est peut-être suite aux poursuites en dommages et intérêt engagées par de nombreux clients à l'encontre de sociétés développant des logiciels et suite à le mise en place de normes strictes par l'organisme de régulation (FDA15 et DoD16 par exemple). Un autre aspect non négligeable outre-Atlantique est la position dominante et militante de certaines associations d'ingénieurs (cf IEEE) dans la diffusion et l'utilisation de normes et de méthodes d'amélioration de la qualité.
Sans une volonté forte de la part des gouvernants, des dirigeants économiques et des clients, y compris des consommateurs, une augmentation nette de la qualité des applications logicielles ne verra pas le jour.
Les méthodes d'amélioration existent, elles doivent devenir d'un usage courant dans la profession.
Propositions
L'approche de la réduction des risques doit se faire par plusieurs canaux :
La sensibilisation des dirigeants et des responsables, tant au niveau des SSII que des clients
La formation des futurs cadres et techniciens, et la remise à niveau des ingénieurs
La mise en place par le législateur d'un niveau de certification rendant obligatoire la mise en place de pratiques cindyniques pour certaines applications telles celles relevant de la santé, des échanges bancaires et/ou des informations à caractère personnel.
La sensibilisation des managers et responsables informatiques est un mode de diffusion de l'information, mais ne doit pas être le seul, surtout que ces interlocuteurs sont confrontés à des impératifs économiques et des sollicitations de toutes parts.
La formation des futurs techniciens et ingénieurs informaticiens, (et des futurs managers) devrait affecter une partie non négligeable du cursus aux aspects de sécurité et de gestion des risques, en mettant l'accent sur les problèmes de responsabilité personnelle des intervenants. Ceci permettra d'obtenir des résultats dans les années à venir. La remise à niveau des informaticiens (par le biais du 1% patronal par exemple) n'est pas une mesure qui donnera des résultats à court terme.
La mise en place par le législateur, (initialement dans des domaines spécifiques tel la santé, la finance, les assurances et/ou pour tout traitement utilisant des données personnelles) d'un niveau minimal de certification, de façon à rendre obligatoire une démarche cindynique permettrait de vérifier l'impact de ces méthodes sur un secteur de l'économie. Cela pourra servir de base de référence pour une extension de ces normes aux autres domaines de l'économie.
Le Canada a déjà déterminé des obligations de certifications pour les logiciels utilisant le Réseau des Télécommunications Socio-Sanitaires (RTSS) ; les Etats Unis, par le biais de la FDA et du DoD ont défini des normes et des méthodes d'amélioration de la qualité des logiciels ; d'autres pays ont, ou vont commencer, ce type de démarches. L'IEC17, en tant qu'organisme indépendant et impartial, pourrait (devrait ?) se trouver à la pointe de ces efforts, d'une part en proposant des réunions de sensibilisation pour les managers et les dirigeants, d'autre part en étant force de proposition auprès des législateurs, et auprès des organismes d'éducation pour former les informaticiens du 21ème siècle.
Bernard Homès
Consultant,
bhomes@tesscogroup.com
