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é.

Abstract

In the last decades, it has become clear that the most challenging task for a software engineer is not just to design for the required functionality, but also focus on architecting for specific quality attributes such as performance and security, which contribute to the quality of the software. Software that provides much functionality but is awkward to use will not sell. Over the years it is noticed that besides an increasing focus on quality attributes, increasing attention is being paid to the architecture of a software system. And within the software engineering community, it is commonly accepted that the quality attributes of a system such as performance or security are to a large extent, constrained by its architecture. Is this constraint also true for usability? Usability is not usually considered during the design of the software architecture due to the widespread assumption amongst software engineers that usability has to do only with the visible part of the system, the user interface. However, this fallacious dichotomy does not address all the usability concerns. Separation of the UI from the core functionality of the system seemed sufficient to support usability. Unfortunately, the modification of certain aesthetic aspects of the UI might require the rework of the software architecture. More specifically, certain usability driven modifications might incur modifications that cannot be easily accommodated by the architecture of the system. Only two research groups have investigated the support for those aspects of usability that are connected to the design of the architecture. They suggested an approach to improve the usability of software systems by means of software architectural decisions by identifying specific connections between usability requirements and software architecture. These requirements are difficult to retrofit into a system if their absence has been discovered when the system is delivered to the customer. This leads us to conclude that more attention should be devoted to usability driven architectural analysis methods. We present a case study that consists in adapting an existing software architecture analysis method (SAAM) for the purpose of deriving the interdependencies between architectural characteristics and usability requirements. More specifically, we investigate the impact of implementing usability requirement changes on the architecture. Potential design solutions that accommodate the corresponding usability mechanisms into the web software architecture are presented, along with their rational and the process by which they are obtained. After a detailed analysis of two distinct architectures of a web system implemented by software engineering students at École Polytechnique de Montreal, our study shows that two of the six chosen scenarios cannot be implemented into an existing system without incurring major architectural changes. These impacts could have been avoided if the usability requirements were defined and considered in the architectural description phase. Both teams constructed their architectures without paying sufficient attention to usability requirements and whether it can easily accommodate late modifications. Fixing usability problems on an already implemented system can prove costly if the changes require modifications that reach beyond the presentation layer, namely those that cannot be easily accommodated by the software architecture. Taking into account some usability requirements earlier in the software development cycle, more specifically before architectural design, can reduce the cost of these modifications. However, there is scarcity of methods and guidelines with the scope of directing users in eliciting the usability requirements that can impact a software architecture. We propose a usability driven adaptation of the quality attribute workshop (QAW) to assist software development organizations in discovering and documenting those usability requirements. An empirical experiment, conducted to assess the utility of this method, reveals that participants were successful in identifying the architecturally relevant usability requirements. It also helped discern the usability aspects that would not have been necessarily defined if this technique had not been employed. We show how this method could be integrated within an existing architecture-centric software development process.------------CONTENU L'utilisabilité, un important attribut de qualité logicielle -- Une vue multidimensionnelle de la qualité logicielle -- La qualité du produit : un point de vue fonctionnel -- La qualité du produit : un point de vue utilisation -- La qualité du processus : un point de vue fabrication -- L'aspect graphique de l'utilisabilité -- L'utilisabilité et le génie logiciel -- Intégration de l'utilisabilité dans les processus de génie logiciel -- L'utilisabilité : vers une nouvelle perspective -- Les architectures des application interactives -- Le soutien architectural de l'utilisabilité -- Évaluation de l'architecture dans la perspective de l'utilisabilité -- Organisation et motivation de recherche -- Investigating the impact of usability on software architecture through scenarios : a cas study on web systems -- SAAM : software architecture analysis method -- Scenario evaluation -- Overall evaluation -- A method to elicit architecturally sensitive usability requirements : its integration into a software development process -- Linking usability to software architecture -- Quality attribute workshop : QAW -- Usability drivent adaptation of QAW : UQAW -- Validation of UQAW.

Mots clés

Architecture logicielle; Génie logiciel; Logiciels -- Développement