Réflexion sur les Approche de Développement des Systèmes Logiciels

Origine des Approches Traditionnelles et du Génie Logiciel

L’industrie logicielle a intégré la société moderne depuis plus de 50 ans. À la fin des années 50, l’informatique est devenue de plus en plus populaire et s’est étendue à d’autres disciplines. Cet élargissement à un public non scientifique, a engendré la création du métier de programmeur. L’utilisateur exprimait ses besoins et le programmeur réalisait la solution informatique. Ce fût le premier écart qui sépara les professionnels de l’informatique et les utilisateurs. À la fin des années 60, les grands systèmes commerciaux ont démontré qu’il était difficile d’adapter à grande échelle, les principes jusque là convenables. Les grands projets dépassaient les budgets et les échéanciers, ce fût alors la crise du génie logiciel [Tre 07]. Le développement logiciel n’était alors que le résultat d’activités désordonnées dites « code and fix » sans planification, ni conception détaillée en amont [Ben 12].

Réflexion sur les Approche de Développement des Systèmes Logiciels 

Depuis des décennies, les projets sont gérés avec une approche classique, le plus fréquemment « en cascade » ou son adaptation « en V », basée sur des activités séquentielles : on recueille les besoins, on définit le produit, on le développe puis on le teste avant de le livrer au client. Ces méthodologies se caractérisent par un attachement considérable à essayer de tout planifier, « tout doit être prévisible », au tout début du projet. C’est pourquoi on les qualifie d’approches « prédictives ». Un plan de management du projet décrit comment et quand le travail sera réalisé, les modalités de planification, d’exécution, de suivi et de clôture du projet. Cette volonté persistante de vouloir piloter le projet par les plans (plan‐driven development) [Ben 12, Mes 08], a conduit les acteurs des projets à redouter, voire à s’opposer systématiquement à tout changement : changement dans le contenu ou le périmètre du projet, dans le processus de développement, au sein de l’équipe, bref à toute modification des plans initiaux, auxquels on doit rester conforme. Les méthodes axées‐plan sont considérées comme étant le moyen traditionnel pour le développement logiciel. Fondées sur des concepts tirés des principaux domaines de l’ingénierie, ces méthodes perçoivent le développement selon un paradigme de besoins/conception/développement couplé de processus standards et bien définis que l’organisation améliore constamment.   

Limites des approches traditionnelles

Nous décrivons ci‐après les limites des approches traditionnelles ou ce qui fait leurs points faibles.   La rigidité de l’approche. On déplore que la nouveauté, la marge de manœuvre laissée au client pour préciser ou faire évoluer ses attentes, la non‐prévisibilité de tous les événements soient difficilement compatibles avec une approche prédictive comme celle du cycle en cascade. L’approche « en cascade » est par conséquent trop rigide pour permettre des retours en arrière; elle suppose que l’on fasse bien du premier coup. Une décision ou une anomalie détectée dans une phase aval de la cascade peuvent remettre en cause partiellement ou totalement des travaux validés précédemment et considérés comme définitifs. L’effet tunnel. L’effet tunnel est une autre des caractéristiques de l’approche «en cascade» : Si un projet dure un an et la phase de recueil des besoins dure deux mois ; le client ne voit le résultat que neuf mois plus tard (Figure 2.8) Figure 2.8 La « boîte noire » 30 D’une part, la non‐transparence des équipes de développement suscite des problèmes quant à leur capacité à coopérer, d’autre part, la longueur des phases techniques auxquelles le client n’est pas associé rend celui‐ci dubitatif sur le résultat à venir. Ce qui ne favorise pas la collaboration efficace entre informaticiens et utilisateurs. D’autant plus si le résultat livré n’est pas conforme à ce qui est attendu. Une mauvaise communication. L’absence de jalons intermédiaires prohibe la validation de ce que sera la version finale du produit. Il faut attendre que la phase de développement soit bien avancée pour découvrir les premiers écrans. Les mauvaises surprises en fin de cycle de vie et le refus du changement par les équipes de développement pénalisent la qualité et les relations avec les utilisateurs. Elles en deviennent parfois même conflictuelles ; les uns s’attachent fermement à leurs plans initiaux pour livrer ce qui était convenu à l’échéance prévue, même si le résultat ne correspond plus ou pas totalement à ce qui est réellement attendu; les autres ressentent cette rigidité comme un désintérêt pour la valeur ajoutée du produit final. La succession d’intervenants, au travers des différents corps de métier, nuit également à la fluidité de l’information, crée même une déperdition d’information et d’énergie ainsi que de nombreuses ruptures de charge [Mes 08]. La levée tardive des facteurs à risques. Dans un cycle de vie « en cascade », les facteurs à risques sont levés tardivement, puisque les tests de performance ou d’intégration, par exemple, sont reportés après les développements, tout comme l’appréciation des interfaces homme‐machines qui sont souvent sujettes à des débats subjectifs et longs. L’impact des risques augmente avec l’avancement du projet, puisque plus une anomalie est détectée tardivement, plus le retour arrière est complexe, plus sa correction coûtera cher et plus les effets de bords seront importants. Une documentation disparate. Afin de se prémunir contre ces risques, l’approche « en cascade » s’attache fortement à la production d’une documentation importante. La documentation permet de repousser le moment où il va falloir aborder la phase de codage, phase irréversible. Elle rassure et apporte la preuve que la réalisation progresse; elle matérialise l’avancement et engage les parties prenantes. En effet, il est plus aisé de s’opposer au changement en brandissant un document contractuel validé précédemment. Malheureusement, cette documentation, souvent trop exagérée, ne reflète pas la réalité des développements : on a beau valider un document d’architecture, celle‐ci reste théorique et conceptuelle tant qu’elle n’est pas implémentée et testée dans des conditions réelles; on a beau présenter des maquettes papier au client, celui‐ci est plus sensible à ce qu’il voit concrètement sur un écran.