Maestro Technologies - Logiciel intelligent de gestion pour l’industrie de la construction.

Analyser le présent pour développer le futur

L’analyse d’un besoin de développement client peut sembler triviale au départ. Pourtant, la tâche s’avère fréquemment ardue e n raison des divers facteurs à prendre en compte. L’objectif principal est de satisfaire les besoins du client, tout en limitant autant que possible les développements et les modifications apportées à l’application. Il est aussi important de généraliser le développement pour permettre à d’autres utilisateurs soit d’en profiter, soit de ne pas être importunés par celui-ci.

Besoins primaires
Au départ, il est important de bien comprendre la demande de l’utilisateur. Souvent, les gens ont tendance à suggérer une solution au lieu d’exprimer un besoin. Cela peut orienter l’analyste dans une mauvaise direction et l’amener à proposer une solution qui pourra satisfaire le client tout en incommodant d’autres utilisateurs. Il est donc essentiel de poser les bonnes questions, afin de définir convenablement le besoin. Pour se faire, il faut souvent élargir le contexte du besoin à combler en considérant la place qu’il occupe dans un processus global. Supposons, par exemple, qu’un utilisateur demande un nouveau rapport. Il est important de savoir ce qui doit être imprimé et de s’assurer que l’ensemble de cette information est disponible dans l’application. Il faut également déterminer l’ordre dans lequel l’information doit être imprimée, la fréquence, le temps disponible, etc. Les réponses à ces points pourraient amener l’analyste à revoir certains formats de table, voire à créer de nouvelles tables ou à modifier des entrées de données, pour être en mesure de rassembler les informations nécessaires.

Découvrir les intervenants
Il faut identifier la ou les personnes qui seront impliquées dans l’utilisation de l’application. Le seront-elles en série ou en parallèle ? Par exemple, si un processus est continu et que l’information doit circuler d’une personne à l’autre, il sera nécessaire que la « transaction » puisse passer d’un utilisateur à l’autre suivant un processus prédéfini. L’application devrait donc permettre que plus d’une personne modifient la même information, avec la possibilité d’intégrer certaines sécurités. D’autre part, est-ce que plusieurs personnes seront amenées à utiliser en même temps la même application ? Cela pourrait devoir dire une gestion sécurisée d’accès, pour éviter que deux personnes modifient en même temps la même transaction, ou pour permettre à un utilisateur de réserver un numéro de transaction sans nuire aux traitements effectués par un d’autres utilisateurs. Il peut aussi être important de connaître les responsabilités de chacun. Dans le cas de traitements multiples, il est possible que chaque intervenant ait un droit d’accès à une partie des actions seulement. Il faudra donc tenir compte de ce fait important lors de l’établissement des règles de sécurité.

Connaître la source de l’information
Si des données doivent être entrées dans l’application, d’où proviennent-elles ? Sont-elles générées par une application externe ? Si oui, est-ce possible d’importer ces données ? Si l’information est incomplète, est-il possible de la compléter en effectuant des liens avec d’autres configurations dans maestro* ou si l’utilisateur devra faire une importation ? Autant de questions qui permettront à l’analyste de s’assurer de la façon de réunir l’information. Une entrée manuelle diffère d’une importation. Dans certain cas, même si une importation est requise, une entrée manuelle sera quand même nécessaire pour gérer, modifier, voire entrer manuellement certaines données.

Valider les exceptions
Une fois la solution établie, il est important de la valider en tenant compte des exceptions. Dans tout processus, il y a toujours un ou des cas non standards. Pour une application informatique, la gestion de ces cas s’avère souvent l’étape la plus ardue. L’avantage d’un logiciel est de reproduire rapidement et facilement un processus ou un traitement établi des centaines, voir des milliers de fois. Toutefois, lorsqu’une exception se produit, il faut prévoir une façon pour l’application de reconnaître que le processus standard doit prendre un chemin différent. Il est donc important pour l’analyste de connaître ces exceptions, et idéalement, de les connaître toutes. En effet, lors de son analyse de base, un bon analyste va prendre en compte les exceptions pour élaborer une solution permettant de faire face à tous les cas. Le fait d’apprendre à posteriori l’existence d’une exception peut remettre en cause le travail déjà fait. Il est donc important que l’utilisateur fournisse ces informations.

Volume d’information
La solution peut varier de façon importante dépendant si quelques données, voir quelques dizaines versus des milliers ou des millions de données doivent être gérées. Il est donc important d’établir d’avance le volume d’information qu’on pense devoir gérer. En plus d’avoir un impact sur la façon d’entrer les données, le volume affectera de façon importante le traitement subséquent, le format des tables de données, ainsi que la génération de rapports d’analyse.

Futur
Il arrive fréquemment qu’un développement constitue seulement une première phase dans le cadre d’un besoin plus général. Dans certain cas, la situation est claire alors que dans d’autres cas, elle demande plus de réflexion. Quoi qu’il en soit, il est important de faire cet exercice. S’il connaît les développements futurs, l’analyste peut prévoir dès la phase initiale des dispositifs souples facilitant les développements à venir.

Tests sur la modification ou l’ajout de fonctionnalités
Une fois les modifications complétées, il est nécessaire non seulement de modifier ces dernières mais aussi l’ensemble des fonctionnalités affectées par le changement. Par exemple, un changement au système de paie peut nécessiter plusieurs tests de validation, pour s’assurer que le changement n’a pas affecté d’autres calculs. Une application est composée d’un ensemble d’objets assemblés pour donner le résultat désiré. Si un objet est modifié, il faut, en théorie, revalider toutes les applications se servant de cet objet. Ainsi, un changement à notre objet « Grille d’entrée » nécessiterait en théorie une revalidation de toutes les options utilisant cette grille. En pratique, l’équipe du contrôle de la qualité vérifie quelques cas types et présume que le résultat peut s’appliquer à l’ensemble de l’application. Cela dit, le volume de tests va aussi affecter l’analyse. En l’occurrence, une solution nécessitant peu ou pas de tests sera privilégiée à une autre, dans la mesure du possible. Souvent, ce dernier point va aussi affecter le choix de la version dans laquelle le changement sera effectué.

Autres facteurs
Durant son examen, l’analyste devra aussi tenir compte du fonctionnement actuel de l’application, ainsi que de son utilisation par les utilisateurs. Par exemple, s’il sait qu’une fonctionnalité est peu utilisée, il sera plus enclin à modifier le comportement de l’application que dans le cas d’une forte utilisation.

Il doit aussi tenir compte des informations existantes et principalement de leur volume. Un changement à une table ou l’ajout d’information peut nécessiter une progression, pour ajuster les tables des clients en fonction du nouveau développement. Cela peut représenter plusieurs minutes, voire des heures dans certains cas.

Pour terminer, il est toujours très important de s’assurer qu’un nouveau développement n’importunera pas les utilisateurs courants. Cela peut se faire par une nouvelle configuration permettant d’activer ou de ne pas activer la nouvelle fonctionnalité. Dans certains cas, on peut aussi attribuer des valeurs par défaut, limitant ainsi l’entrée d’une information, par exemple.

Il est évident que certaines fonctionnalités peuvent être ajoutées sans modifier la situation. Par exemple, l’ajout d’un rapport modifie simplement le menu. Par contre, l’introduction d’une nouvelle étape dans un traitement affecterait en théorie l’ensemble des utilisateurs.

Conclusion
Souvent, on nous demande des changements qui peuvent paraître simples aux yeux de l’utilisateur. Toutefois, l’analyste doit prendre en compte un ensemble de facteurs et fournir une solution qui sera simple, pratique, peu coûteuse, sans danger et évolutive. Une tâche qui n’est pas toujours facile...