Votre employeur a décidé de mettre en place un système de gestion des alarmes (SGA) pour améliorer la sécurité sur le campus.
Comme ils ont plusieurs besoins informatiques en même temps et tous semblent utiliser les mêmes données, ils ont d’abord pensé qu’il serait une bonne idée d’intégrer tout cela à un ERP de réputation internationale.
Mais comme ils ont des besoins d’affaires un peu spécifiques (la sécurité) et que le système doit être relié à plusieurs systèmes existants, ils allaient alors devoir “légèrement” personnaliser l’ERP.
Mais… vu certains événements récents parus dans les médias, il leur a été plutôt recommandé de découper le projet en plus petits morceaux et de livrer de la valeur et des fonctionnalités utilisables en continu. Ils ont donc fait appel à vous afin de s’adjoindre les services d’ingénieurs/informaticiens logiciels pour le développement du système.
Comme, à terme, il s’agit quand même d’un grand produit, en tant que professionnel du développement vous avez rapidement identifié la maintenabilité et la préservation de la capacité à modifier le code, le design et l’architecture en continu comme étant une caractéristique qualité essentielle pour ce projet.
Et il va sans dire vu la nature du projet ainsi que la méthode de travail, qu’il serait assez inacceptable de voir ce que nous appelons communément des “bogues” de production.
En tout temps, il doit être possible d’adapter le système, modifier le code, le faire évoluer, le connecter à d’autres systèmes, etc.
Vous savez aussi que le projet étant complexe, il sera nécessaire d’y aller incrémentalement et itérativement. Découper le projet en jalon pour le livrer d’un coup après 2 ans (ou même 8) n’est pas une option. Il faudra livrer de la valeur toutes les deux semaines et être capable de s’adapter aux changements de priorités, aux imprévus, aux nouvelles exigences, etc.
Vous devrez également monter vos suites de tests en conséquence afin de maximiser, non seulement la détection des “bogues”, mais aussi de manière à mettre à l’épreuve la capacité à modifier le code en continu.
NOTE: Au cas où vous n’auriez pas compris par vous-même, sachez que l’énoncé se veut humoristique et que le contexte ainsi que les fonctionnalités sont fictifs et destinés à un projet de session pédagogique. Évidemment, utiliser les règles d’affaires inventées de ce projet pour un vrai système ne serait pas une bonne idée!