La mesure et l’amélioration continue des processus

Comme le suggère la définition du génie logiciel citée précédemment et proposée par Fenton et Pfleeger (Fenton & Pfleeger, 1996), une approche d’ingénierie suppose que chacune des activités d’un quelconque processus est comprise et contrôlée. Or, comme le suggère DeMarco (DeMarco, 1982) dans sa célèbre proposition «you can’t control what you can’t measure», la mesure est une activité inhérente et essentielle en génie logiciel. Fenton et Pfleeger (Fenton & Pfleeger, 1996) décrivent la mesure comme suit : «Measurement is the process by which numbers or symbols are assigned to attributes of entities in the real world in such a way as to describe them according to clearly defined rules.»

Ainsi, la mesure permet de décrire des entités du monde réel en attribuant une valeur numérique ou symbolique aux attributs qui les constituent rendant possible, toujours selon les mêmes auteurs, la réalisation de trois types d’activités fondamentales. D’abord, elle aide à «comprendre» en rendant plus visible ou perceptible les différents aspects du processus et du produit et permettant ainsi une

14

meilleure compréhension des différentes activités et des entités affectées. Ensuite, la mesure permet de «contrôler» ce qui survient lors d’un projet en se servant d’une meilleure compréhension des entités et de leurs relations et en prévoyant ce qui est susceptible de se produire afin d’appliquer les changements requis pour que les buts du projet soient atteints. Finalement, toujours suite à une meilleure compréhension que procure la mesure, cette dernière permet en plus d’«améliorer» les processus et produits afin que les défaillances détectées ne se perpétuent pas aux projets subséquents.

De ce fait et comme il a été en partie évoqué ci-haut, la mesure en génie logiciel s’applique essentiellement à trois ensembles d’entités, soit aux entités reliées au produit, celles rattachées au processus et enfin celles relatives aux ressources. En ce qui a trait particulièrement aux entités touchant le produit, l’extrait suivant tiré d’un article intitulé «Making software development visible» de Hsia (Hsia, 1996) illustre assez bien la difficulté majeure et inhérente à la nature des logiciels, c’est-à- dire leur invisibilité.

«Software, like wind, is invisible yet powerful. We can 'see' wind only by observing its effect, as it sways branches and swirls sand. And we can 'see' software only by observing its functionality. Invisibility is what makes software development so difficult to manage -- it is hard to monitor the construction of something you can't see.»

Bien que la mesure du produit logiciel soit fondamentale en génie logiciel, elle est toutefois moins pertinente à la recherche exposée dans le présent document. D’autre part, concernant les mesures relatives aux entités liées au processus,

15

celles-ci bénéficient d’une attention accrue dans la littérature contrairement à ce dont elles avaient droit il n’y a encore pas si longtemps. Tel que discuté précédemment, de plus en plus de processus et méthodologies voient le jour et l’approche «processus» est maintenant largement adoptée au sein d’un nombre croissant d’organisations qui produisent du logiciel pour usage interne ou pour fins commerciales. Toutefois, l’approche «processus» en soit n’est pas une panacée. D’abord, un processus est loin de garantir la production d’un logiciel de qualité, mais de plus, tout bon processus n’est pas nécessairement applicable à toutes situations et dans toutes organisations. Non seulement faut-il être capable d’appliquer un processus adéquat à une organisation donnée dans un premier temps, mais encore faut-il être capable d’en mesurer son efficience pour être en mesure de l’optimiser dans un deuxième temps.

Ainsi, un exercice de mesures sur le processus de développement utilisé s’avère donc nécessaire en suivant une approche dite «bottom-up». Cette approche de mesure et d’amélioration de processus est celle préconisée par nombre d’auteurs dans la littérature. Contrairement à l’approche dite «top-down» qui consiste simplement à implanter un processus générique ou commercial ou qui consiste à valider le processus évalué par rapport à un modèle de référence, l’approche «bottom-up» consiste quant à elle à mesurer et à analyser le processus en place, déterminer les causes des problèmes rencontrés, pour ensuite en apporter les correctifs nécessaires (Briand, El Eman, & Melo, 1995; Robillard et al., 2003). C’est d’ailleurs cette approche qui sous-tend l’un des paradigmes de mesures de processus très bien connu sous le nom de «Goal-Question-Metrics» (Fenton & Pfleeger, 1996; Robillard et al., 2003).

16

Pour justifier l’adoption de l’approche «bottom-up», Briand, El Emam et Melo expliquent que le problème majeur rencontré à l'égard des processus génériques ou commerciaux sur lesquels on se base pour adopter une approche descendante (top- down), est qu’ils sont basés sur de nombreuses présomptions sur ce qui constitue de soit disant bonnes pratiques, présomptions qui ne sont pas vérifiées empiriquement et qui ne sont également pas toujours applicables dans certains contextes. De plus, les auteurs renchérissent en ajoutant que de nombreux problèmes qui sont rencontrés en pratique ne sont pas tous abordés par ces types de processus. L’approche ascendante (bottom-up) de l’amélioration du processus consiste donc, selon ces auteurs, à implanter une équipe d’amélioration du processus, modéliser le processus existant dans l’organisation concernée, mener une analyse qualitative afin d’identifier des sources de problèmes, définir et documenter un plan d’action ainsi qu’un programme de mesures, mener un projet pilote pour finalement implanter de nouvelles pratiques à l’ensemble de l’organisation.

Par ailleurs, on retrouve maintenant dans la littérature et sur le marché, un certain nombre de méthodes d’évaluation de processus s’inspirant également d’une approche «bottom-up». On n’a d’abord qu’à penser aux très célèbres «Capability Maturity Model®» (CMM) et «Capability Maturity Model® Integration» (CMMI) du Software Engineering Institute (SEI) (Paulk & Carnegie Mellon University. Software Engineering Institute, 1994; Ahern, Clouse, & Turner, 2001). Le CMM, lancé par le SEI en août 1990, connu dès lors un succès fort appréciable auprès des organisations en raison, entre autres, de sa présentation hiérarchisée des différents

17

niveaux de qualité. Plus spécifiquement, le CMM se veut d’être un modèle d’évaluation des processus organisationnels qui permet de classifier le niveau de maturité du processus évalué en cinq niveaux. Ainsi, un processus classifié au niveau 1 indique un processus tout à fait ad hoc et chaotique où les chances de succès d’un projet sont tout à fait imprévisibles et dépendent grandement des individus impliqués. Le niveau 2, quant à lui, indique un début de gestion de projet, de spécifications, d’assurance qualité, etc., mais principalement pratiqués au niveau de chaque projet, alors que le niveau 3 indique des pratiques définies au niveau organisationnel. Le niveau 4 signifie la présence de mesures quantitatives de processus, alors que le niveau 5, le plus élevé du CMM, dénote finalement des activités d’optimisation de processus. De plus, les cinq niveaux de maturité définis par le CMM se subdivisent en 18 domaines clés, 52 buts et 316 pratiques clés donnant autant de points de repère spécifiques aux organisations désireuses de parfaire leur processus.

Une autre méthode d’évaluation de processus également populaire dans l’industrie est assurément celle de la norme ISO 9001 qui définit les standards d’assurance qualité relatifs à toutes les phases du cycle de développement du produit, soit de sa conception jusqu’à son installation et/ou sa mise en service (International Organization for Standardization (ISO), 2009). Cinq chapitres composent la norme, établissant les standards en terme de gestion de l’assurance qualité, des responsabilités de la haute direction, des ressources humaines, de l’ingénierie et construction des produits, ainsi que de la mesure, analyse et amélioration continue du processus. Un peu comme fonctionne le processus d’évaluation du CMM, le processus de certification ISO consiste en audits menés par des évaluateurs

18

externes qui recommanderont par la suite l’enregistrement de l’organisation évaluée ou non.

Ces deux types de méthodes d’évaluation de processus ne sont que quelques exemples bien connus parmi la manne de standards et de certifications qui existent sur le marché. Celles-ci comportent plusieurs avantages intéressants. Outre le fait qu’elles permettent l’adoption d’un processus susceptible de mieux épouser les formes procédurales organisationnelles, donc d’être mieux adapté au contexte spécifique dans lequel il est implanté, étant donné qu’elles consistent en l’établissement de standards sur ce qu’il doit être fait et en laissant les organisations libres d’en décider du comment, elles permettent également et justement de certifier de l’application d’un certain standard par l’organisation et de la mise en pratique de certaines règles de l’art bien établies dans le domaine. Aussi, non seulement de telles certifications permettent à l’organisation de dénicher de nouveaux contrats et d’attirer de nouveaux clients, elles sont, de plus, parfois une exigence stricte de plusieurs organisations qui pratiquent une gestion serrée de leurs fournisseurs et sous-traitants pour mener des affaires avec elles.

Toutefois, bien que cela puisse sans doute sembler surprenant et bien que ces types de certifications permettent d’attester que l’entreprise suit un processus standardisé à l’organisation, elles ne permettent pas toujours d’assurer que les produits, produits par l’entreprise, respectent un certain niveau de qualité. Autrement dit, une entreprise produisant des logiciels truffés d’anomalies, peut, par exemple, certainement obtenir une certification de type ISO 9001, en autant que son processus de production soit standardisé à l’organisation. Comme le soulignent

19

Fenton et Pfleeger dans leur livre intitulé Software Metrics : A Rigourous & Pratical

Approach, «quality, like beauty, is very much in the eyes of the beholder». Ainsi,

l’important est de définir les attributs du logiciel présentant un intérêt pour l’utilisateur et de mesurer le degré de présence de ces attributs dans le produit logiciel (Fenton & Pfleeger, 1996). Toutefois, plusieurs écarts de non-qualité peuvent s’introduire, et ce, à plusieurs instants au cours du processus logiciel. Il peut y avoir, par exemple, un écart de non-qualité entre ce que l’usager désire, et ce qu’il exprime, un écart de non-qualité entre ce que l’usager exprime et ce que l’analyste comprend, un autre entre ce que l’analyste comprend et ce qu’il exprime par écrit dans le document de spécifications des requis logiciels, un autre encore entre ce qui est spécifié dans le document de spécifications et ce qui est compris par les concepteurs, un autre entre ce qui est compris et ce qui est réalisé par ces mêmes concepteurs, un autre entre ce qui est réalisé et ce qui est testé et finalement un autre entre ce qui est testé et ce qui aurait dû être testé. Même si tout bon processus de développement de logiciels doit théoriquement inclure les activités nécessaires afin de minimiser toutes ces écarts de non-qualité, plus souvent qu’autrement, la pratique indique que ce n’est malheureusement pas toujours le cas.

En fait, au niveau des processus mêmes, ils existent également ce que l’on pourrait appeler des «marges de non-conformité». D’abord, il existe une marge de non- conformité entre ce qui devrait être prescrit et ce qu’il l’est vraiment. Ensuite, la plupart des chercheurs seront d’accord pour dire qu’il existe une autre marge de non-conformité entre ce qui est prescrit et ce qui est réellement pratiqué par les concepteurs. Enfin, lorsque vient le temps d’être audité, les plus honnêtes

20

avoueront qu’il existe également, dans certains cas, un écart de non-conformité entre le processus réellement suivi par les concepteurs de logiciels et ce qui est permis de constater aux auditeurs. Plusieurs raisons peuvent expliquer ces marges de non-conformité, mais l’une des plus évidentes et la plus fréquemment soulevée par les praticiens du domaine, est que l’institutionnalisation des processus tel que promus par le CMM et l’ISO et leur simplification pour être applicable à l’ensemble des projets menés par l’organisation, provoque un effet pervers d’encourager l’adoption d’un processus souterrain beaucoup plus riche et adapté aux besoins spécifiques du contexte. «Institutionalization guarantees nothing, and efforts to institutionalize often lead to a bifurcation between an oversimplified public process and a rich private process that must be practiced undercover.» (Bach, 1994)

Finalement, quant au troisième et dernier type de mesures, celles concernant les entités reliées aux ressources, ce sont certainement celles ayant le moins été traitées dans la littérature, sans doute en raison de la difficulté inhérente à la mesure des facteurs humains influant au cours d’un processus de génie logiciel. Même si la mesure des ressources inclut aussi bien le matériel requis au processus de développement que les ressources humaines chargées de réaliser le projet, il n’en demeure pas moins que ces dernières constituent assurément l’élément le plus important et ayant le plus d’impact sur le projet. Ce type de mesures est par ailleurs le plus pertinent dans le cadre de la recherche présentée dans ce document et ne sera conséquemment pas traité dans le présent chapitre, mais sera abordé plus particulièrement au cours des chapitres qui suivent.

21