Une norme pour les projets logiciels ?

par Daniel Mahé, ASK Conseil

Daniel Mahé a une longue expérience de la conduite et de l’audit de projets informatiques. Il a en particulier eu l’opportunité de travailler sur les normes en cours de gestation au DOD au début des années 9, domaine qu’il suit depuis lors. Il mène régulièrement des audits de projet informatique.

La notion de projet renvoie à l’unicité, au spécifique, au différent. Mais les travaux entrepris dan le cadre de projets logiciels possèdent de nombreux traits commun dans leur nature ou leur type, d’où la question légitime :Peut-il exister un cadre générique aux projets de développement de logiciels ? Ce cadre est-il offert par les normes proposées aujourd’hui ?

Cette question peut paraître inopportune au vu de l’opinion commune sur les normes : Si elles sont en effet aujourd’hui considérées comme un point de passage obligatoire, elles sont aussi souvent perçues comme n’apportant pas toujours un plus et ont la fâcheuse réputation d’être parfois génératrices d’activités administratives. Il faut toutefois nuancer ce jugement car les normes ne sont pas vraiment connues de la plupart de leurs utilisateurs potentiels. A ce titre, qu’en est-il de la norme majeure des développements logiciels, la norme ISO/CEI 12207 « Processus du cycle de vie du logiciel »

Cette norme décrit l’ensemble des processus mis en œuvre sur l’intégralité du cycle de vie d’un logiciel, de l’idée ou de l’expression du besoin initial jusqu’à son retrait final. Elle ne présuppose ni ne définit un cycle de développement particulier (en V ou en cascade, prototypage, spirale, incrémental ou autre). Tous les types de projet sont pris en compte : Développement complet, réutilisation, achat, intégration de progiciels, maintenance, logiciel embarqué ou logiciel d’aide au développement.

Comment répondre à cette diversité ? Par la description détaillée de 17 processus et de leurs interrelations (et non pas de phases, de jalons ou d’un Cycle de vie) et une décomposition des processus en activités et tâches élémentaires.

La décomposition d’un processus en activités suit plus ou moins le bien connu « PDCA » (Plan, Do, Check, Act). Se voulant donc sans description de séquences d’enchaînements temporels, la norme n’implique pas non plus un type particulier d’organisation. Elle est écrite pour pouvoir être mise en œuvre sur un projet par le donneur d’ordre ou par le réalisateur, mais elle peut aussi être appliquée par une entreprise comme cadre de référence de ses développements. La norme décrit seulement des rôles (acheteur, fournisseur, développeur, mainteneur,...) pour le choix des processus à mettre en œuvre et chaque activité peut être « ajustée » (tailored) au contexte spécifique. D’ailleurs un des seuls chapitres normatifs (obligatoires) de la norme correspond au processus d’ajustement, il est complété par un guide détaillé expliquant aussi exhaustivement que possible les points à prendre en compte et la façon d’ajuster ensuite les items de la norme, selon les caractéristiques locales :

1. la position de l‘utilisateur de la norme : acheteur, fournisseur, développeur, ... 2. la place du projet dans le cycle de vie du produit, 3. Les caractéristiques du logiciel : développement standard, réemploi, logiciel embarqué, adaptation de progiciel,... 4. Les règles propres à l’entreprise : les langages, les plates-formes, les procédures particulières 5. La stratégie d’acquisition retenue : Achat, contrat type de sous-traitance, contrat avec clause d’engagement du fournisseur,... 6. La stratégie de développement : modèle en V, en spirale, incrémental,....

L’approche 12207 est le résultat d’un travail entamé dés juin 1989 impliquant 17 pays au sein de l’ISO (International Standardisation Organisation) et qui a abouti à une première version en août 1995, augmentée de 3 compléments, le premier publié en 1998 puis les « Life Cycle Data » et « Implementation Considerations ». Cet ensemble a subi un premier amendement en juin 2002 après les premeires retours d’expérience significatifs. La norme initiale fut bâtie sur l’acquis des entreprises dans l’emploi des normes précédentes qu’elle soient de source militaire (et particulièrement la DOD std 2167A) ou Entreprise tels que les standards IEEE de génie logiciel. Dés l’origine la compatibilité, voire la convergence avec la série des ISO 9000 ; les travaux entamés autour du CMM (Capacity Maturity model) du SIE ont été aussi pris en compte. L’ISO/CEI 12207 est donc aujourd’hui un standard expérimenté et reconnu à travers le monde.

Les premières mises en œuvre sur le territoire français ont naturellement été le fait des industriels de l’armement (DoD oblige) au sein de Thalés et de Matra par exemple, cette sphère entraînant naturellement ses équipementiers et sous-traitants. Mais, d’autres organisations ont vite compris le parti qu’il pouvait tirer de cette approche.

Une première réponse, provocante, mais à ce titre interpellante : personne n’a réellement besoin de cette norme, si l’on considère que les normes n’apportent pas de savoir-faire concrets ou de compétences particulières ou innovantes ni sur le plan technique, ni sur le plan des procédures de travail. Tout ce qui est décrit dans cette norme existe déjà par ailleurs et peut être acquis probablement ( ?) pour un coût de mise en œuvre moindre, les normes de source militaire US étant connues pour leur formalisme fort et l’abondance des documents générés. Si cette approche peut être entendue, elle masque cependant une facette importante des normes. Elles sont l’expression d’un savoir-faire commun et approuvé, l’élaboration d’une telle réflexion nécessite toujours un travail collectif important et répond en finale parfaitement à des besoins multiples d’harmonisation et d’échanges, A ce titre, la norme 12217 peut être employée pour mettre en place une approche des projets basée sur une vision complète et consensuelle et dont on peut être certain, a priori, qu’elle répond à une haute exigence de qualité. Cette réponse ne masquer pas la réalité du travail de mise en place, outre qu’il faut accepter ce qui’ n’a pas été inventé localement (éviter le syndrome NIH), un effort réel d’adaptation est nécessaire, effort qui demande un personnel formé à la norme.

En fait, en dehors des secteurs qui, tels que l’armement, ont définitivement adopté la 12207 comme cadre de référence, les premiers utilisateurs de cette norme sont les entreprises ou les organisations qui ont besoin de collaborer ou d’être ouvertes dans les développements des logiciels que ce soit dans le développement en partenariat ou la passation et la réponse à des appels d’offres, et l’on peut s’attendre dans ce domaine à voir progressivement s’imposer le 12207 comme seule référence.

Mais des utilisateurs potentiels existent, en dehors du cadre contractuel pour faire face aux challenges de la collaboration dans des structures complexes ou larges. La norme offre dans ce cas un langage commun pour établir des recommandations entre développeurs et utilisateurs à l’intérieur d’une même entreprise. Elle peut aussi être employée comme check-list d’évaluation des aspects Organisation interne dans le cadre d’une acquisition d’un ERP par exemple. La norme apporte alors un cadre de référence qui offre, par sa conception, deux caractéristiques fondamentales, être un apport externe reconnu et être adapté (tailored) aux spécificités de l’entreprise.