Ingénierie Logicielle

E-mail Print PDF

1. Introduction
Ce document décrit ma philosophie de la conception logicielle suivant l'approche de la gestion de qualité, et en me positionant comme gestionaire du projet.
De nombreuses méthodes existent pour réaliser les phases d'un projet IT, elles font partie de la famille "Software Devellopment Lifecycle Management".
Mon approche se base sur le modèle CMMi. Pour ce qui concerne cet article, la méthode de conception du code applicatif est basé sur les normes ISO-15504/SPiCE sup2/3,ISO-10007 et ISO-25000/SquaRE.
En ce qui concerne l'ITSM (le lifecycle management de l'infrastructure et le change management) ma référence est ITIL. Ces phases sont hors-scope du présent document.

2. Validité d'un  programme
L'une des étapes, sans doute la plus critique, de l'élaboration d'un programme est son analyse fonctionelle. Il n'est pas râre de devoir fixer des rendez-vous avec les demandeurs du programme plusieurs fois au cours de son élaboration, avant même que la première ligne de code ne soit écrite.
Car souvent, les désirs du client sont soit mal compris par les analystes -souvent plus cartésiens-, soit l'expression du besoin de la part du client se modifie au cours de l'élaboration du projet.
Il est donc nécessaire de coordonner efficacement ce point, au risque de produire un programme obsolète avant même sa mise en production par le client. Un profil d'analyste capable de se détacher totalement du code et même de l'approche architecture d'infrastructure est donc primordial à la réussite de cette tâche.
On formalisera les flux, besoins et plan projet suivant diverses méthodes, telle l'ancienne Method-One ou plus récemment UML selon la complexité du projet et la compéhension de ce modèle par chaque personne impliquée dans sa réaliseaion.

3. Robustesse
La robustesse d'un programme, à mon sens, se situe excusivement dans la tâche de l'analyste-programmeur, qui doit prévoir tous les scénarios possibles de l'utilisation de son programme.
Une donnée entrée de façon erronée doit être détectée par des routines du programme et également pouvoir être corrigée par l'utilisateur. Si la dernière possibilité de correction est irréalisable, le programmeur doit permettre au programme d'arrêter le processus en faute et restaurer le système à l'utilisateur dans son état initial. 
Il est possible d'affiner cet aspect de la programmation par une batterie de tests (dits de "boite noire" et de "boite blanche") tout au cours de l'évolution des modules du projet,. Seuls quelques bugs "mineurs" peuvent encore être tolérés au cours des test de "robots" ou au niveau des bétas-testeurs. Des erreurs plus amples nécéssitant une révision totale de l'analyse. 
Malheureusement, nous nous trouvons de plus en plus souvent confrontés à des programmes commerciaux, pour l'entreprise comme pour le privé, qui ne semblent pas avoir suivi cet examen aux "bugtracking" et qui posent énormémént de problèmes aux utilisateurs. Ces derniers se trouvent confrontés au dilème de l'attente des mise à jours fréquentes ou de la recherche d'un outil concurrent plus fiable, encore faut-il que se dernier existe... 
Ce dernier cas, au point de vue de la société d'édition, peut causer de grands dommages sur son image de marque, sa crédibilité ou même sur sa pénétration du marché.


4. Extensibilité
L'aspect extensibilité est également une tâche primaire de l'analyste, qui doit raffiner l'analyse de l'outil pour la rendre facile à comprendre pour les programmeurs initiaux du projet ainsi que pour ceux qui, dans le futur, en feront la maintenance.
Le programmeur, lui aussi, doit fournir un code "propre", c'est à dire suffisament fourni en commentaires et utilisant une syntaxe à la fois simple et performante (Les programmeurs en C comprendront aisément l'étendue et l'importance de cette remarque...).
On remarque également que dans de grandes entreprises de dévellopement de logiciels, la conception d'un programme majeur est exécuté par de multiples groupes de trois à quatre personnes. Chaque groupe travaillant exclusivement sur un module du projet, sans pour autant avoir la nécéssité d'en comprendre la totalité.
Cette façon modulaire et décentralisée permet une adaptation exclusive de chaque module sans avoir à modifier l'entièreté du code et ainsi permettre le travail à d'autres équipes.
Ceci fut la leçon tirée d'IBM lors de ses grands projets sur mainframe, où de grandes équipes travaillaient sur un unique projet monolythique et où la détection de problèmes et l'adaptation étaient des tâches fastidieuses, quasi-impossibles.


5. Réutilisabilité
Une bonne analyse, en vue de l'extensibilité, facilite également la réutilisabilité de programmes en vue d'autres projets. 
En effet, il est ridicule de réinventer la roue à chaque tour de celle-ci. 
En écrivant des programmes dont une partie des fonctions peuvent être recopiées telles-quelles, après certitude de leur efficacité et de leur justesse bien sûr, permet un gain de temps, de sécurité et d'argent dans la conçeption du projet. 
La conception de programmes orientés-objet permet, par exemple, de n'avoir qu'à modifier les méthodes agissant sur un objet, sans avoir à recréer le squelette de celui-ci. 
L'utilisation de langages de scripting évolués, tels Python ou Perl, qui permettent également de récupérer les résultats de programmes pré-existants sans avoir à les recréer en "byte-code". Ce dernier exemple m'amène au chapitre suivant.


6. Compatibilité
La compatibilité est la conséquence des deux aspects énumérés antérieurement. Il faut néanmoins considérer deux types de compatibilité:
La compatibilité horizontale est la capacité d'un programme à pouvoir communiquer avec d'autres programmes tournant dans le même environnement, comme par exemple les pipes et redirection dans l'environnement UNIX, les interfaces graphiques "window manager" utilisant la même couche de support hardware de l'affichage (tel X-window, Motif ou Cocoa) ainsi que les  protocoles tels TCP/IP, dont l'architecture, au même titre que le modèle OSI, permettent une interaction "simple" entre leurs différents éléments et également l'ajout de nouvelles couches compatibles communiquant de façons standardisées. On peut se référer à DDR pour X-Free 4.0, où cette couche supplémentaire de support 3D ne contraint aucunement le window manager tournant "au dessus" de lui. L'invention de protocoles tels SLP ou SSH ne nécessitent pas non plus de modification des couches inféreures (TCP/UDP,IP,...)..
La compatibilité ascendante, quant à elle, est l'aspect de pouvoir faire s'échanger des données produites par une version de programme plus ancienne avec une nouvelle version, et éventuellement dans les deux sens. Ceci est un aspect bien plus important pour l'utilisateur que pour le programmeur, car il est très désagréable et coûteux de perdre la capacité d'importer dans les nouveaux logiciels tout le travail fourni précédemment  avec l'ancienne version. Ce type de mauvaises expériences peut se produire avec des outils fournis par des firmes de dévellopement concurentes ou parfois même par la même entreprise.
Pour ces deux types de compatibilités, des solutions existent pour palier aux différents problèmes explicités plus haut, telle l'utilisation exclusive et stricte de standards acceptés, ou mieux encore, l'utilisation d'outils "OpenSource". qui permettent aux dévellopeurs de mieux comprendre les mécanismes et algorithmes internes au code et utilisés par d'autres entreprises afin de rendre leurs produits compatibles avec le reste de la même "niche logicielle". -On peut soulever ici le problème de la brevatibilité logicielle ou intellectuelle qui peut nuire à cet échange sain d'informations qui permettent une concurrence plus loyale.-


7. Qualités complémentaires
Beaucoup d'autres qualités sont nécessaires à l'élaboration d'un bon programme.
L'utilisation optimisée des ressources disponibles sur la majorité du parc informatique de technologie actuelle, de façon à éviter une "course à l'armement" en informatique, ou les processeurs ou la taille de la mémoire ne suffisent plus à faire tourner un nouveau programme ne comportant que peu de différences marquantes vis-à-vis de la version précédente qui se contentait à merveille de la machine présente.
La portabilité vers d'autres plates-formes (à la fois systèmes d'exploitation -GNU/Linux, MacOS/X, MS-Windows- qu'architectures -x86,POWER,SPARC,...-). 
L'utilisation de langages tels le C et Java, pour ne citer qu'eux, permettent ce genre de portabilité grâce à l'existance de compilateurs et d'interpréteurs adaptés. Pour le cas de Java, cela se paie au niveau de la performance puisqu'une JVM est nécessaire à l'exécution du code sur la plate-forme native.
Le langage le plus portable, par excellence depuis des années, est le C. Celui-ci peut être utilisé dans la programmation de bas-niveau tout en restant compatible entre les environements et les plates-formes hardware.
La vérificabilité des programmes conçus est également due au langage utilisé: il existe des débuggers et des "robots-tests" pour beaucoup de langages, comme gdb pour C. La vérificabilité passe également par le contrôle de versions du code créé, avec des outils tels que Subversion ou GIT. Ces outils permettent également un échange sain des sources entre les différents programmeurs du même module.
L'intégrité des données gérées par le programme. Cette part de responsabilité est à prendre en charge par le programmeur qui a conçu l'outil. C'est à lui de vérifier la sécurité et de tester son code contre les intrusions de tous types, que se soit grâce à des outils de cryptage intégrés ou plus simplement à l'aide d'une bonne définition de l'accès à ses objets. 
Les idées préconçues que les logiciels dont le code ouvert seraient plus sujet à l'intégration d'outils de piratage est fausse: les pirates -à ne pas confondre avec les hackers, dont le sens originel du terme ne  reflète pas le "coté obscur du code" mais bel et bien des personnes attachées à leur vision de l'informatique et des dévellopeurs anonymes acharnés- qui voudront être les premiers à infecter un code savent pertinamment bien qu'une énorme communauté n'attend que cette occasion pour créer une meilleure parade à leur attaque. Leur action négative serait anéantie rapidement et permetterait même une évolution. Par compte, attaquer des programmes propriétaires réduit le nombre de personnes succeptibles de répondre au virus et donc augmente la durée de vie du virus et, par excellence, ses dommages aux systèmes infectés. 
L'intégrité, à un autre aspect, existe aussi grâce à une bonne normalisation dans le cas des bases de données relationelles. Dans ce cas la responsabilité se situe chez le DBA [Data Base Administrator], en collaboration avec le programmeur qui écrira l'application exploitant ces données.Ainsi, on peut facilement éviter les classiques attaques par cross-site scripting (mauvaise utilisation de cookie au niveau client-server web) ou d'injection SQL.
La facilité d'utilisation doit être prise en compte assez tôt par l'analyste, parfois avec l'aide d'un designer, afin de créer un environnement de travail qui sera facile à utiliser et qui ne dégoûtera pas l'utilisateur ni par la complexité à saisir le "squelette du programme" (son but et son organisation) ni par l'aspect visuel ou l'ergonomie de l'outil. 
Ce dernier point prend une place de plus en plus importante dans les nouveaux projets liés au Web ou ayant une utilisation similaire (Intranet,Extranet,...) afin de toucher un plus large public, tout autant technique que profane. Les systèmes embarqués -GPS, GSM multi-fonctions, outils de mesure scientifique, mediacenters,...- doivent comporter des programmes qui seront utilisés naturellement par le client, sans que celui-ci ne sache nécessairement de quelle façon le matériel fonctionne, avec un minimum d'efforts d'apprentissage.


8. Conclusion
On peut donc remarquer qu'une grande partie de la réussite de la conception de software réside dans l'éfficacité de son analyse et qu'il est donc normal que cette phase prenne une grande partie temporelle de l'élaboration.Le gestionnaire du projet doit donc être attentif à maitriser cette phase, autant dans le contrôle de sa rigueur technique que dans l'utilisation de ressources humaines et financières qu'il allouera à ce poste.

Last Updated ( Thursday, 03 September 2009 00:10 )  
You are here: