Une nouvelle perspective pour gérer le soutien de l'utilisabilité dans l'architecture logicielle

Les ingénieurs logiciels font aujourd'hui face à d'énormes pressions pour développer et déployer des systèmes informatiques complexes. Ces pressions ont eu pour effet la concentration de leurs efforts dans le développement des besoins fonctionnels du client. On se rend compte aujourd'hui que ceci a eu pour conséquence l'oubli de certains attributs importants de qualité, surtout l'utilisabilité, entraînant alors la livraison de systèmes informatiques de mauvaise qualité. Jakob Nielsen, un gourou de l'utilisabilité, affirme qu'un logiciel qui fournit à l'utilisateur une panoplie de fonctionnalité mais qui est difficile à utiliser ne pourrait se vendre. Ceci va à l'encontre d'un des objectifs majeurs du génie logiciel : la conception de systèmes que les utilisateurs trouveront utilisables et qui leur permettront d'accomplir d'une manière efficace leurs travaux. Il est donc indispensable de prendre en compte l'utilisateur et son contexte de travail dans la conception de systèmes informatiques. Le succès d'un logiciel ne dépend donc plus uniquement de sa fonctionnalité ou de son prix, mais surtout de sa capacité à être utilisé facilement par une large population de connaissances variables. L'utilisabilité n'est généralement pas considérée pendant la conception de l'architecture, principalement à cause de la croyance qu'elle fasse seulement partie de l'Interface Utilisateur (IU). Mais la modification de certains aspects esthétiques de l'IU peut avoir un impact sur l'architecture du système. Plus précisément, ils ne peuvent être rectifiés sans encourir des changements majeurs à l'architecture de l'application. Seulement deux groupes de recherche ont proposé des méthodologies pour élucider le lien qui existe entre l'utilisabilité et l'architecture. Ils ont identifié des exigences d'utilisabilité qui nécessitent une considération lors de l'élaboration de l'architecture. Il s'avère très difficile d'incorporer ces exigences dans un système existant si leur absence n'a été découverte qu'à la livraison du système au client. Ceci nous mène à conclure que plus d'attention devrait être consacrée aux méthodes d'analyse des architectures qui seront orientées utilisabilité. De ce fait, nous présentons une étude de cas qui consiste à adapter une méthode existante d'analyse de l'architecture (SAAM) afin d'identifier l'impact de mettre en application ces changements d'utilisabilité sur l'architecture. Nous analysons une application Web, développée par des étudiants de 4en' année en Génie Logiciel à l'École Polytechnique de Montréal, afin de déterminer comment l'utilisabilité peut être incorporée. Une analyse détaillée nous permet d'affirmer que l'inclusion de certaines des exigences d'utilisabilité n'a été possible sans encourir des changements architecturaux majeurs. Corriger les problèmes d'utilisabilité sur un système existant peut s'avérer coûteux si les changements exigent les modifications qui atteignent au-delà de la couche de présentation, plus précisément ceux qui ne peuvent pas être facilement accommodés par l'architecture de logiciel. En tenant compte des exigences d'utilisabilité plus tôt dans le cycle de développement de logiciel, plus spécifiquement avant la phase de conception, le coût de ces modifications peut être considérablement réduit. Cependant, il y a une pénurie de méthodes et de directives qui ont pour but de guider les intervenants dans l'obtention des requis d'utilisabilité qui peuvent avoir un sérieux impact sur l'architecture de logiciel. Nous proposons donc une méthode qui va aider les organisations qui développent des logiciels, à découvrir et documenter les requis d'utilisabilité. Une expérience empirique, entreprise pour évaluer l'utilité de cette méthode, indique que la méthode permet de discerner les aspects de rentabilité qui n'auraient pas été nécessairement définis si cette technique n'avait pas été utilisée. Ensuite, nous modéliserons cette méthode comme activité au sein d'un processus centré architecture et nous définirons les rôles ainsi que les artefacts qui seront associés à cette activité.