Akelaï

La maîtrise des projets de développement IT

Projets IT


Visitez notre site Web dédié à l'ingéniérie logicielle et aux projets IT : software.akelai.fr

logo Akelaï Visitez notre site WEB : www.akelai.fr

Le Travail Bien Fait

En Génie Civil, un architecte est responsable de l'édifice qu'il livre.
En cas de défaut, il pourra avoir a en répondre, le cas échéant, devant des tribunaux.
Qu'en est-il pour le développement du logiciel ?

Le trépied de la qualité

Un point d'appui dans toute réflexion qui touche à la Qualité, l'Organisation, ou les Processus, est de considérer le mélange des trois ingrédients:

Selon le contexte, on s'appuiera plus sur l'un ou sur l'autre, mais seul ce trépied est complet et peut fournir sa stabilité au système qualité.

Un outil pourra contribuer directement à la qualité. C'est par exemple le mètre qui permet de positionner plus exactement le tableau au milieu du mur.
Toutefois, il ne garantira pas toujours la qualité: selon le soin du bricoleur, le tableau sera toujours plus ou moins bien placé.
Certains outils ont une efficacité redoutable. Ainsi un guide permettra de placer exactement une pièce; une butée permettra de contrôler la profondeur d'un perçage.
L'outil pourra aussi impacter favorablement coûts et délais. Utiliser une butée économise le temps de mesurer le bon emplacement d'une pièce, et son temps de fabrication est négligeable dès qu'on travaille en série.

On peut voir la procédure comme le partage d'un savoir-faire, mais elle résulte aussi plus simplement d'une découpe du travail. C'est le bureau des méthodes qui définit et organise le travail dans l'atelier.
Autant l'outil est bien accepté, autant la procédure peut être ressentie comme contraignante.
L'outil est un démultiplicateur du travail de l'homme, il ne vient pas à l'encontre de son initiative.
La procédure au contraire est un substitut à cette initiative: la reflexion a été faite "ailleurs", il ne reste plus qu'a "appliquer".
Or autant les machines "aiment" les procédures (elle ne savent qu'appliquer sans cesse des directives), autant l'homme est peu doué pour cela et -- presque inévitablement -- commettra des erreurs. Pire : si on lui demande de mettre son intelligence et son initiative au vestiaire, le jour ou la procédure sera en défaut, il prendra un malin plaisir à l'appliquer aveuglément pour un résultat catastrophique en se retranchant derrière "j'ai fait ce qu'on m'a dit".

On peut aussi reprocher aux procédures une tendance à figer le sytème qualité : on fait un gros effort pour les rédiger; si gros, que la seule perspective de devoir les changer décourage toute velléité.
Dans un monde changeant, le Système Qualité peut devenir alors un obstacle à l'adaptation de l'entreprise !

Il y a souvent un large écart entre une procédure écrite et une procédure appliquée. Pour être appliquée, une procédure devra être accompagnée de formation, y compris sur les bonnes raisons de la procédure, et de (nombreux) rappels, avec toute la patience voulue.
L'usage de procédures doit donc être fait avec discernement.
Les cimetières sont plein de Système Qualité fossilisés sur une pléthore de procédures non-appliquées au mieux et démotivantes au pire.

Parfois on a un choix facile entre outil et procédure.
On peut citer les outils de workflow: un outil de workflow organise une succession de tâches cohérentes à travers des états de tâches, des transitions entre ces états successifs, des assignations à des personnes, un suivi, des outils de recherche et de statistiques.
Les outils de gestion documentaire sont un autre exemple de substition très avantageuse de procédures par des outils.
Dans ces deux cas, la formalisation d'une procédure en est d'autant allégée, et le respect des règles fortement soutenu par l'outil.

L'usine à logiciel

Le bon équilibre entre hommes, outils et procédures dépendra:

Dans les industries manufacturières de grande série, on s'appuie sur du personnel peu qualifié; la place des outils et procédures est prépondérante. Les hommes sont interchangeables à très court délai. Les outils incluent les robots les plus pefectionnés.

Les évolutions et les succès de ces modes de production (y compris le "flux tendu" et ses moutures LEAN) peuvent être une source d'inspiration.
On a imaginé ainsi l'appellation "d'usine à logiciel" pour ce qui reste encore une vue idéale (?) où la production de logiciel serait enfin maîtrisée, en s'appuyant sur des composants logiciels réutilisables qu'il s'agirait d'assembler. Voir la littérature des débuts de l'approche objet.

La réalité est bien différente, et il n'est pas certain qu'on n'arrive jamais à ce monde "idéal". Ce serait en effet ignorer les natures fondamentalement différentes des activités de production (répétitives) et de conception (inventer un nouveau système).

En revenant au trépied de la qualité, les activités de conception doivent s'appuyer essentiellement sur l'homme -- et ses outils --.
Malheureusement, parce qu'elles font appel à la créativité et à l'initiative, elles sont difficilement prédictibles. Parce que l'homme est faillible, elles rencontrent beaucoup d'aléas: mettre l'homme au coeur d'un système qualité n'est-ce pas aussi y introduire une faille "fatale" ?

Le modèle COCOMO [1] (Constructive Cost Model) reste une référence pour l'estimation des coûts d'un projet de développement de système informatique.
Il a été élaboré par le Dr Barry Boehm de l'Université de Californie du Sud. C'est un modèle de coûts établis d'après des études statistiques. Il date de 1981 et a été repris en 1995.
Il classifie les facteurs de coûts en 4 catégories: "personnel", "produit", "plateforme", "projet". Les facteurs de coûts de la catégorie "personnel" sont : Maturité des Architectes, Maturité des Programmeurs, Turn Over, Expérience du domaine Applicatif, Expérience de la Plateforme, Expérience du Language. Le modèle COCOMO montre que si le coût moyen d'un projet est 1, alors les facteurs de coût liés au personnel peuvent le faire varier entre 0,2 (projet 5 fois moins coûteux) et 5 (projet 5 fois plus coûteux), soit un écart de 1 à 25 entre les deux extrêmes.

Il faudra donc que le système qualité trouve une juste place à l'homme, pour permettre son initiative et sa créativité tout en limitant les conséquences de ses erreurs; on rêve encore de pouvoir "prouver" le logiciel, mais le Zune de Microsoft n'a pas pu passer les 12 coups de minuit du 31 décembre 2008 (Les Echos 2 février 2009).

Le travail bien fait

Reconnaître (sans que ce soit une surprise) le rôle prépondérant de l'homme dans le développement de système n'est pas suffisant. Il faut encore en tirer les conséquences sur le côté obscure de la force :

Curieusement, le premier point semble faire l'objet d'un tabou. J'ai connu un projet où une des fonctions majeures (les rapports fournissant une vision globale du système -- dont les données nécessaires à la comptabilité) a constitué un double échec:

Pour traiter la défaillance du fournisseur sous-traitant, il a fallu faire développer par ailleurs cette fonction.

Eviter des erreurs en s'appuyant sur les personnes les plus compétentes possible est le meilleur choix.
Réussir un projet n'est jamais une fatalité. A contrario, on a déjà écrit, pour expliquer la réussite de certains projets en danger : "et puis les bonnes personnes sont arrivées...".
Le Système Qualité devra donc porter une attention toute particulière à l'adéquation des personnes, sous la responsibilité explicite du management.
La difficulté n'est pas d'en prendre conscience, mais d'organiser cette prise en compte de manière objective et responsable (le modèle COCOMO fournit une approche possible et des critères d'évaluation).

Le travail bien fait est du domaine de la responsabilité individuelle. Cela s'applique autant au manager qu'au technicien. Il faut éviter les doubles échecs.

Références

[1] Boehm, B.W., Software Engineering Economics, Prentice-Hall: Englewood Cliffs, NJ, 1981


© Akelaï Conseil 2006-2018. Akelaï Conseil encourage l'usage de navigateurs internet respectueux des normes : Google Chrome, Firefox, Opera, Safari.

Valid CSS Valid XHTML 1.0