UPi – A Software Development Process Aiming at Usability, Productivity and Integration Kenia Sousa, Elizabeth Furtado, Hildeberto Mendonça University of Fortaleza (UNIFOR) Av. Washington Soares, 1321 – 60.811-905 – Fortaleza – CE – Brazil +55 (85) 3477-3079 {kenia, elizabet}@unifor.br, [email protected]

ABSTRACT

This paper presents the definition of a software development process (SDP) that integrates practices from Software Engineering (SE) and Human-Computer Interaction (HCI) with three main goals. First, we intend to help professionals from both areas in developing interactive systems with usability through the application of an agile process. Second, we want to make HCI an essential part of SE processes by facilitating the communication between professionals from these two areas, thus, bringing productivity to a new working environment. Third, we aim at describing the basis for generating User Interfaces (UI) through the integration of HCI concepts in the process, rather than on depending only on UI designers’ experience. Keywords

Software Development Process, usability, productivity, integration, return on investment INTRODUCTION

When we started performing usability consulting services in software development companies, we noticed that many software organizations were unsatisfied with the quality of their delivered final products. That is the reason most of them are hiring consulting services related to quality. When doing so, most of them mention CMM, RUP and usability. We also noticed that software organizations were willing to make changes in their current SDP with two main conditions: if these changes result in improvements in the quality (including usability) of the final product and if they maintain the productivity of their professionals. With this scenario in mind, we decided to define a SDP, called UPi, which is a unified process to develop interactive systems aiming at usability, productivity, and integration. It includes activities from requirements, analysis and design, implementation, and test. This process aims at providing productivity for professionals through the application of an agile process that allows them to work in an integrated manner in order to develop usable UIs. That is, SE professionals can specify artifacts that are complemented or used by HCI professionals, or vice-versa. This way, they learn how to share artifacts and also that an artifact from

one area can help in the production of an artifact from another area, thus, bringing agility to the process. In order to provide agility with their integration, we must improve their communication by making artifacts and activities from these areas more dependent so that professionals work more as one team. Usability is a main concern for final users and also for software organizations that intend to satisfy their customers. Usable systems are easy to learn, easy to remember how to use it, efficient to use, and reliable, thus, leading to users’ overall satisfaction [Nielsen, 1993]. In this process, we focus on eliciting users’ needs, constant validation of UIs, reuse of usability patterns, among other usability recommendations. Productivity is directly related to the time spent by UI designers, developers, and other professionals throughout the SDP in order to produce artifacts that are necessary to develop usable UIs. Our intention is to help HCI as well as SE professionals to work together with constant communication to share and validate their artifacts. Integration of SE and HCI activities and professionals is a difficult task in the industry. Unlike in the academia, where researchers are willing to learn new things and make changes, professionals in the industry work with strict deadlines and cost restrictions, as a result they have to be very efficient in each activity they perform. Therefore, we aim at making this integration as smooth and as clear as possible by providing a process that allows them to share their experiences and knowledge. We are also defining and modeling a tool called IKnowU, which means designing UIs with Interaction based on the Knowledge of the User. This paper is organized as follows. In the second section, we describe the state of the art. In the third section, we define the process. In the fourth section, we present the proposal for the process automation. In the fifth section, we present an experiment of applying the process. In the sixth section, we discuss our lessons learned. In the seventh

section, we present future works. In the eighth section, we point out the main contributions of this work. STATE OF THE ART

In this section, we present artifacts and activities that are being performed by professionals from both areas and that can be integrated in one process. The following subsections are use case model and task model, usability requirements, system architecture, UI definition plan, and UI prototyping, which influence the activities and the guidelines followed by UPi. Use Case and Task Model

We have learned that HCI professionals work with task models and SE professionals work with use cases. Our intention is to demonstrate that use cases and task models can be used jointly. Use case models represent a wellestablished manner to define the system functionality, while task models can be used to detail use cases by breaking them down in tasks. We have decided to apply use case models because they are a stable notation and widespread in the entire Computer Science community. On the other hand, there are many ways to detail them. Therefore, we decided to compare different forms to detail use cases (e.g. flow of events, task models) in order to choose the format most suitable for UI generation. According to [Cockburn, 2001], use cases can be textually described in a detailed flow of events organized in a main success scenario with possible extensions. The flow of events represents the interaction of the user with the system to accomplish a goal. Two of the main purposes of a use case are: to describe a business process and to represent functional requirements of a system. It is intended to be read by end users and business executives, who can provide valuable feedback on its validity. Use case storyboards [Krutchen, Ahlqvist & Bylund, 2001] is composed of flow of events; class diagrams that describe the boundary classes that participate in the realization of the use case; sequence diagrams to describe how the use case is realized in terms of objects and actors; usability requirements; and references to use cases and UI prototypes. Concerning the steps it proposes to detail a use case, it follows the same idea as the one proposed by Cockburn, but it is augmented with usability aspects. The task description proposed by [Laussen, 2003] is similar to a flow of events specification, but it does not indicate if the actor of the task is the user or the system. The task description intends to present business goals and users’ tasks in a simple and sequential manner. It does not intend to describe functional requirements that separate the tasks between users and the system in order not to lead to early design decisions. An essential use case [Constantine & Lockwood, 1999] is a simplified, technology-free narrative organized in users’ intentions and system responsibilities. It does not describe concrete steps performed by users or the system, that is,

user actions and system responses. Its tasks are simpler than concrete use cases in order to leave open more design possibilities for the UI. All of these formats do not focus on early design decisions and they are easily read by anyone involved in requirements elicitation. Like most use case descriptions, the task model also does not focus on early design decisions and it uses small sentences to specify the tasks. On the other hand, the task model presents more advantages for the UI generation, such as the hierarchical structure, as in the CTT [Paternó, Mancini & Meniconi, 1997]; the possibility to include usability tasks; and the clear expression of temporal relationships among tasks. The hierarchical structure it is an intuitive form to decompose problems in smaller parts and maintain the relationship among all the parts, and it provides the possibility to reuse task structures [Mori, Paternò & Santoro, 2002]. Concerning usability tasks, we can exemplify with the ‘show error message’ task performed by the system in order to represent ‘feedback’ and ‘error treatment’ usability requirements. Concerning the relationship among tasks, its definition on the model enables UI designers to understand the hierarchical organization as groups of tasks that can be organized in sections of the system. The consideration of tasks relationships and the hierarchical organization can help UI designers to better define the system navigation. One problem that must be addressed is that most software engineers argue that the task model hierarchical structure is not familiar to most end users, business executives, and SE professionals as it is to HCI professionals. We argue that the ease of understanding provided by textual representations is less important than the task model positive characteristics for UI generation. In order to facilitate the application of the task model, system analysts and UI designers must be trained in this new model and a stable tool must be available for task modeling. In cases when business executives are reluctant to see the task model and prefer textual specifications, it is important to have a tool that generates a textual specification from the detailed description of each task, thus, avoiding re-work. The CTTE [Mori, Paternò & Santoro, 2002] is a very efficient and stable tool, besides being free, but it would be interesting if it could generate a textual specification of the task model as an alternative. Even though, we advice system analyst to review requirements with users by using paper sketch prototypes. As a result of this study, we have decided to apply in our process use case models and task models as a detailed specification of a set of related use cases, instead of using use case flow of events. The use of use case models and task models helps UI designers and system analyst to work together during the definition of requirements, making the validation of functional and usability requirements more

agile. It also improves the communication among SE and HCI professionals, starting earlier in the process, before the prototypes start being designed. Usability Requirements

Three different levels of usability are inter-related in order to allow the consideration of usability since the beginning of the product lifecycle and the actual inclusion of usability in the final system [Juristo et al., 2003]. Usability requirements represent users’ preferences or constraints that could or should, respectively, be part of a usable interactive system. For example, provide feedback to the use; provide guidance to the user, etc. Usability requirements are usually elicited from users in the beginning of the project. Usability patterns represent mechanisms to be applied in prototypes in order to address usability requirements; and they are associated to one or more usability requirements. For instance, the usability requirement ‘provide feedback’, which is a user request, is mapped to the usability pattern ‘progress indicator’. Interaction patterns represent design solutions for known usability problems; they are incorporated into the system architecture; and they are associated to one usability pattern.

listen-for- module (e.g. listen-forcancellation module), module (e.g. cancellation module), and collaborating modules. For the cancellation architectural pattern example, active modules represent modules that are performing the activities that are to be cancelled. The listen-for-cancellation module represents the module that listens for the user’s request to cancel the active modules. The cancellation module actually terminates the execution of the active modules and possible collaborating modules, returning the system to the state prior to the execution of the active modules. The collaborating modules represent modules that collaborate with the execution of the active modules. These modules are directly mapped to components that have specific responsibilities in order to carry out the usability pattern execution. Our approach for designing the system architecture has the same goal as the one proposed by [Bass, John & Kates, 2001], which is to include usability patterns in the system architecture. We have designed an example of a usability design pattern for the Web (Figure 1). We selected the Search interaction pattern to demonstrate the classes necessary for each layer of the architecture following the Struts framework [Struts, 2005].

The usability pattern ‘progress indicator’ is mapped to the interaction pattern ‘feedbacker.class’ and it is implemented in the final system in order to provide feedback to users after the execution of a task. There is a vast literature on usability patterns and there is a good list of usability patterns available in [Welie, 2005] that can used as a basis for usability engineers to define what they can offer to users. System Architecture

System architecture is composed of smaller components that are tested individually and integrated gradually to compose a complete system. A system that supports users’ usability requests must have an architecture designed so that it allows usability requirements to be implemented. In this section, we present how usability requests are expressed through components in the system architecture. In this context, a component can be, for instance, classes that implement interaction patterns; classes that represent pages (e.g. JSP), etc. There are system development organizations that consider usability only after the system is implemented. This scenario leads to architecture and source-code changes and re-work in order to include usability into the system. Therefore, [Bass, John & Kates, 2001] defined how to design system architecture to achieve usability by including usability patterns in it. They propose an extension of the Model-View-Controller (MVC) design pattern [MVC, 2000] by defining four modules to specify usability architectural patterns. These modules are: active modules,

Figure 1. MVC Example with Usability Search Pattern The model represents the business rules of the system. The view renders the contents through the UI. The controller translates user interactions into actions to be performed by the model. When the user interacts with the system (e.g. clicks on a button, selects an item on a menu), the “Search” page sends data to the controller. The “SearchAction” class is responsible for listening for user interactions in order to call the “SearchOnLineHelp”, which activates the business process of searching for information on the On-Line Help and sends the outcome data back to the controller. The “SearchAction” now selects the appropriate view (Search.jsp) that shows the search results on the UI. Associating our approach to the one defined in [Bass, John & Kates, 2001], the active and collaborating modules are represented by classes from the Model layer (e.g. Course class as the active module and Student class as the

collaborating module for a university enrollment system) and View layer (e.g. ListOfTakenCourses.jsp); the listenfor- module is represented by the class from the Controller layer (e.g. SearchAction class for a Search Usability Pattern); and the module is represented by the class from the Model layer (e.g. SearchOnLineHelp class for a Search Usability Pattern). UI Definition Plan

The UI Definition Plan is a new artifact included in the process as our contribution for the generation of usable UIs. Its main goal is to define which visual objects and usability patterns should be part of the UI. Its generation follows three main steps. The first step to produce this artifact is to group system analysts, software architects, and programmers from a software organization in order to define values (in a scale from one to five) for each visual object (e.g. combo box) and usability pattern (e.g. online help). For instance, the possible performance levels that visual objects and usability patterns can have are: extremely low, low, medium, high, and extremely high. The visual objects and usability patterns are organized in categories, for instance, search, navigation, page elements, etc. That is, for the search category, we can have simple search, advanced search, site index, FAQ, etc. We only include categories related to the usability requirements informed by users. If the user requested feedback, we include the alert category; for guidance, we include the navigation category; for searching facility, we include the search category; etc. The second step is to group users and business executives that represent the final user’s interests in order to attribute a weight (in a scale from one to five) for each non-functional requirement specified by the user as important. For instance, the level of performance that the client is expecting from the system can be: extremely low, low, medium, high, and extremely high. After this attribution of values, an algorithm decides which one is the best visual object or usability pattern in a certain category (e.g. search) to be placed on the UI. We are researching for the best algorithm to implement this solution. When the user requests search facility, the UI designer has to choose one option among many design alternatives. But, we have to notice that users also require the system to have, for instance, high level of performance, high level of reliability, medium level of security, and high level of usability, with low costs. Considering the characteristics of all search alternatives and users’ requests, the UI Definition Plan decides that the best option is to include the simple search. This artifact is very useful in making decisions based on users’ preferences, according to the elicited non-functional requirements. An interesting aspect is that all requirements

are considered for evaluation, each one with its importance level as specified by users’ representatives. It can also consider the software organization and the client’s reality concerning costs by analyzing how much each pattern would cost to be developed. In general, it provides a more solid decision making process instead of letting UI designers decide which objects and patterns to allocate on the UI solely based on their knowledge, or letting users’ representatives give design opinions with no prior knowledge. Rosson and Carroll proposed an approach to decide which features to include in the UI based on positive and negative characteristics of each feature [Rosson & Carroll, 2001]. The difference from our approach is that this one does not use any calculus to decide which feature to include in the UI, it is based on the analysis of a professional, and it only focuses on usability implications. UI Prototyping

Prototypes can be generated in the following levels of platform-dependent categories [Coyette et al., 2004]: 1.

Paper sketches focus on the interaction, UI components, and on the overall system structure, keeping the style guide secondary, without being too abstract. Examples: storyboards using paper and pencil.

2.

Drawing prototypes produce an accurate image of the system. Examples: prototypes using Microsoft Visio, Adobe Photoshop, etc.

3.

Executable prototypes produce the code in a certain programming language, focusing on the navigation, not on the implementation of business rules. Examples: prototypes using Macromedia Dream Weaver for web systems.

Each category serves for a specific purpose: Paper sketches are useful to demonstrate to users which activities the system attends and the possibilities of navigation in the system, even users can help build them. Drawing prototypes are useful to demonstrate standards and style guides. Executable prototypes are useful to demonstrate navigation and usage. Prototyping can follow these categories in order to be evaluated by users in different times during the life cycle, thus, allowing detailed discussion concerning the UI design with SE and HCI professionals. We use prototypes to follow a specific UPi characteristic that is based on two main hypotheses: Architecture-Centric Development Process and Return on Investment (ROI). •

In order to follow the Architecture-Centric characteristic, it is necessary to define the development platform (including programming language, operational system, and interaction device) from the beginning of the lifecycle, when we start to elicit users’ needs. The platform

decision directly affects the UI content, navigation, and the look & feel, that is, the number of objects in an interactive space and the kind of navigation among spaces are changed depending on the size of objects and spaces of the selected device. •

In recent bibliography concerning ROI [Wilson & Rosenbaum, 2005], there are many useful techniques that can be efficiently applied with prototypes, such as, explanation, simulation, participatory design, etc. Besides, project managers intend to achieve a better ROI and usability level with the application of prototypes.

Use case storyboards [Krutchen, Ahlqvist & Bylund, 2001] are also based on designing UI prototypes, but we did not use this idea entirely as a basis for our work because it adds many steps before the user can actually see a prototype. Examples of these steps are class diagrams to show classes that represent screens on the system and interaction diagrams to demonstrate the system navigation. Since these diagrams are not well understood by end users and business executives, we prefer to directly show prototypes. Our approach allows UI designers to start user evaluation with a set of paper sketches alternatives since they provide agility. With paper and pencil, UI designers can show the system navigation to be validated with the users. If they want changes, they are done fast and they can be revalidated in the same meeting. This level of prototype does not need to focus on visual objects and usability patterns, which will be a result of the UI Definition Plan. UPi DESCRIPTION

UPi is a lightweight development process for interactive systems that can be combined with other processes, like the RUP. In general, RUP satisfies organizational demands by bringing a structured and proven process framework into practice and UPi can add benefits to UI generation. UPi can serve as a guide, providing useful steps and artifacts that can be tailored and customized when organizations intend to develop usable interactive systems. One of the best advantages of UPi is the idea to focus on activities, artifacts and guidelines that add value to the UI generation. With this approach, it can be integrated with any other process and inherit activities that are vital to the entire process, but that are better defined and solidified in other processes. For instance, project management, configuration and change management, implementation, and deployment activities are very well detailed in the RUP. Besides the RUP, UPi can also be applied in conjunction with ISO 13407 [ISO 13407, 1999], which already has other activities defined and validated, such as project planning, testing, etc. Even though there are activities in UPi that exist in other processes, such as requirements specifications, they are specified in UPi in an integrated manner. That is, UPi integrates HCI and SE activities, artifacts and professionals.

While the other processes usually are concerned with only one area, either SE or HCI. For instance, the RUP arises from SE and ISO 13407 arises from HCI. In [John, Bass & Adams, 2003], they analyze the similarities and differences between the RUP and ISO 13407, and the communication problems between HCI and SE communities. Since communication problems occur even when there is no multi-disciplinary team; this problem becomes even more critical when working with a multi-disciplinary team. With this issue in mind, we decided to define a process to guide professionals in performing their work and sharing artifacts in a way to avoid communication issues. UPi is composed of activities that aim at designing UIs (Figure 2). These activities are based on RUP activities, but they follow different guidelines that take into consideration usability aspects. The purpose of the Elicit Stakeholder Needs activity is to understand users, their personal characteristics and information on the environment where they are located that have a direct influence on the system definition, and to collect special non-functional requirements that the system must fulfill, such as performance, cost, and device requests. The purpose of the Find Actors and Use Cases activity is to define the actors (users or other systems) that will interact with the system and the functionality of the system that directly attend users’ needs and support the execution of their work productively. The purpose of the Structure the Use Case Model activity is to refine the use case model with final details, such as relationships between actors and use cases. The purpose of the Detail a Use Case activity is to describe the use case’s tasks using the task model, to describe any usability requirements related to the use case, and to define the system navigation based on the task model hierarchical structure, using paper sketches. The purpose of the Review Requirements activity is to verify with users if the requirements are in conformance with their needs by showing them the elaborated paper sketches. The purpose of the Define the Architecture activity is to design the classes following the MVC design pattern, including business classes that fulfill the required functionality; and boundary classes based on the paper sketches. The purpose of the Define UI Plan activity is to define which visual objects and which usability patterns can be part of the UI according to the non-functional requirements defined in the Elicit Stakeholder Needs activity. The purpose of the UI Prototyping activity is to design a UI prototype either in paper sketches, in drawings or in executable prototypes following the description specified in the task models, in the UI definition plan and in the system architecture.

Concerning the five usability rules, access, efficacy, and context consider both novice and experienced users and the environment where they are located. Table 1. Process Theoretical Foundation UPi Activity

Usability Rule

Elicit Stakeholder Needs

-Access -Efficacy -Context

Find Actors and Use Cases

-Support

Structure the Use Case Model

The purpose of the Refine the Architecture activity is to design the classes (usability patterns) that attend the usability requirements elicited by users and refining boundary classes with the objects resultant from the UI Definition Plan. The purpose of the Evaluate Prototype activity is to verify if the UI prototypes are in accordance to usability principles and to verify with users (by using the system in the development site) if the UI prototypes are in conformance with their view of the system and needs. The purpose of the Implement Components activity is to develop the classes previously designed and the UI prototyped. The purpose of the Evaluate the System activity is to verify with users (by using the system in the installation site) if the interactive system is serving the purpose of supporting their work in a usable and efficient manner. These activities are based on five Usage Centered Design Rules [Constantine & Lockwood, 1999] and six RUP best practices [Krutchen, 2000] (See Table 1).

-Visually Software

Model

-Visually Software

Model Model

Detail a Use Case

-Progression -Support

-Visually Software

Review Requirements

-Support

-Manage Requirements -Continuously Verify Software Quality -Control Changes to Software

Define the Architecture

-Progression

-Use ComponentBased Architectures -Visually Model Software

Define Plan Figure 2. UPi Activities

Best Practice

the

UI

-Use ComponentBased Architectures

UI Prototyping

-Access -Efficacy -Context

-Develop Software Iteratively

Evaluate Prototype

-Support

-Manage Requirements -Continuously Verify Software Quality -Control Changes to Software

Implement Components

-Progression

-Use ComponentBased Architectures

-Support

-Manage Requirements -Continuously Verify Software Quality -Control Changes to Software

Evaluate System

the

They can be achieved by understanding users themselves and their usability needs and considering such

characteristics when designing the UI in the UPi Activity: Elicit Stakeholder Needs and UI Prototyping. Progression concerns adaptation and it can be achieved by eliciting users’ usability requests considering different users’ learning levels, and defining and implementing the system architecture considering such usability requests in the UPi Activities: Detail a Use Case, Define the Architecture and Implement Components. The ability to support users in performing their work better can be achieved by defining the tasks performed by users while working and analyzing if they are satisfied with what is being designed in the UPi Activities: Find Actors and Use Cases, Detail a Use Case, Review Requirements, Evaluate Prototype and Evaluate the System. Concerning the six best practices, we explain each one and associate them to the UPi activities as follows. 1. Develop Software Iteratively means developing the products in iterations and presenting each result to users in order to correct possible misunderstanding and inconsistencies in a timely and efficient manner, what raises the quality of the final product. This practice is achieved by the Incremental and Iterative Nature of the process and UI Prototyping, that is, prototypes with a set of functionalities are evaluated and smaller versions of the system are delivered in iterations. 2. Manage Requirements means controlling changes to requirements as they appear throughout the lifecycle in order to satisfy users’ changing needs. This practice is achieved by the Incremental and Iterative Nature of the process, that is, in each iteration, new or changing requirements are accepted for evaluation. Whenever a change in requirements affects the UI, the Control Changes to Software practice is invoked in order to notify UI designers that they have to change the prototype and evaluate the impact of such changes with users. It is most common to have new requirements after evaluations, such as in the UPi Activities: Review Requirements, Evaluate Prototype and Evaluate the System. 3. Use Component-Based Architectures means designing a system focusing on its architecture. This practice is achieved by defining the system architecture, which considers usability patterns, which are selected based on users’ non-functional requirements, and implementing the UI based on the architecture in the UPi Activities: Define the Architecture, Define the UI Plan and Implement Components. 4. Visually Model Software means defining the system structure and behavior with visual models. This practice is achieved by modeling use cases, users’ tasks, and architecture in the UPi Activities:

Find Actors and Use Cases, Detail a Use Case, Structure the Use Case Model and Define the Architecture. 5. Continuously Verify Software Quality means the analysis of the final product and its elements throughout the lifecycle. This practice is achieved by reviewing the requirements, evaluating the prototypes and the developed UIs in the UPi Activities: Review Requirements, Evaluate Prototype and Evaluate the System. 6. Control Changes to Software means controlling the evolution of requirements through the maintenance of the product and its elements. This practice is achieved by the Incremental and Iterative Nature of the process, that is, when changing requirements are accepted, the models related to the requirements need to be maintained. It is most common to have change requests after evaluations, such as in the UPi Activities: Review Requirements, Evaluate Prototype and Evaluate the System It is important to notice that the activities are associated to guidelines that should be followed in order to develop a usable system. The guidelines for UPi are the following: 1.

Specify task models considering usability aspects; therefore, there will be usability tasks in the model, such as, cancel, search, navigate forward, navigate backward, etc.

2.

Elicit usability requirements organized by use cases. This way, they can be easily traced back to use cases. According to [John, Bass & Adams, 2003], use cases are the most likely vehicle for injecting HCI information into the system design process and maintaining its influence.

3.

Another option is to elicit them organized in a separate document (such as the RUP Supplementary Requirements or the Vision Document) in order to be applied in the entire system, not only in specific use cases.

4.

Design the architecture considering usability patterns and following the MVC design pattern in two main steps: define boundary classes based on sketches; then refine it with usability patterns.

5.

Specify with users, in the UI definition plan, the importance level of certain non-functional requirements (e.g. security, privacy) by interviewing them using a spreadsheet-like template in order to view a list of visual objects and usability patterns that can be part of the UI.

6.

Evaluate prototypes against design standards and against users’ needs in order to ensure that the system meets the stated usability requirements and usefulness, respectively.

7.

Clearly demonstrate in the prototype evaluation that the prototype was designed according to the UI definition plan results.

8.

Document the UI style guide and deliver it to the client along with the UI definition plan and prototypes for acceptance before implementation begins.

We intend to evaluate the UPi by applying it in more projects both in the industry and in the academic environment in order to be able to answer the following questions: 1.

Is the integrated SDP increasing the overall usability of the final product?

2.

Are SE or HCI professionals willing to learn and apply new artifacts?

IKNOWU DESCRIPTION

We are currently working on specifying and modeling a tool called IKnowU with the goal of supporting SE and HCI professionals in developing usable interactive systems. We have noticed from various researches that we needed one integrated tool, where we could define both SE and HCI artifacts and could associate them to facilitate maintenance.

Figure 3. IKnowU Core Use Cases and usability patterns in order to define which of them can be part of the UI.

The core functionalities (Figure 3) in this tool are: 1.

Define use cases: the definition of use cases is done by specifying some basic information, such as name, primary actor, pre-condition(s), postcondition(s), etc.

2.

Define task models: each use case is detailed with a task model, composed of a set of hierarchical tasks necessary to achieve the use case main goal. When a task model is created, it is associated to a set of related use cases.

3.

Select usability requirements: each use case is also detailed with usability requirements requested by users. Some usability requirements are requested independent of use cases. These requirements are useful for the entire system.

4.

Create class diagram: based on the tasks, the class diagram is defined to specify the data and the operations on such data necessary to fulfill the tasks.

5.

Associate tasks to classes: the tasks are mapped to attributes or methods in the class diagram.

6.

Evaluate non-functional requirements: nonfunctional requirements (e.g. performance) are given an importance level according to users’ expectations of the system.

7.

Define and View UI Definition Plan: the values for the non-functional requirements are evaluated according to the values allocated to visual objects

8.

View prototype: the visual objects and usability patterns resultant from the UI definition plan are allocated on the UI according to the classes’ attributes and methods mapped to a certain task model. The result is an image that can be used as a starting point for implementers to develop them in any given programming language.

The core functionalities of the tool are supported by other functionalities that are performed independent of the interactive system to be developed. In other words, there are supporting functionalities that the usability engineer and the UI designer need to perform prior to the beginning of the requirements elicitation or during it (functionality 4) in order to enable the performance of the core functionalities. The supporting functionalities (Figure 4) in this tool are: 1.

Include usability requirements: a list of usability requirements is included in the system to allow the performance of the functionality “Select Usability Requirements”.

2.

Include usability patterns: a list of usability patterns is included in the system illustrated with images to allow the performance of the functionalities “View UI Definition Plan” and “View Prototype”.

3.

Associate usability requirements to usability patterns: usability requirements are mapped to usability patterns in order only to include usability

patterns in the UI Definition Plan that users requested. 4.

5.

6.

Attribute values to visual objects and usability patterns: visual objects and usability patterns are given values that represent how the software organization evaluates them according to the nonfunctional requirements users select (e.g. performance, usability, etc.) to allow the performance of the functionalities “View UI Definition Plan”. Include visual objects: a list of visual objects is included in the system to allow the performance of the functionalities “View UI Definition Plan” and “View Prototype”. Associate attribute types to visual objects: attribute types (e.g. Integer, String, Float, Boolean) from the class diagrams are mapped to visual objects in order only to include usability patterns in the UI Definition Plan that users requested. For instance, an attribute of a String type can be associated to Text Area and Text Field objects.

models, and class diagrams. The reason for this decision is due to the necessity to evaluate the results of the tool as soon as the main functionalities are ready. The tool will be evaluated according to the following aspects: 1.

Ease to trace tasks and classes back to use cases;

2.

Ease to trace usability requirements back to use cases;

3.

Ease to elicit usability requirements with users;

4.

Ease to adapt the UI definition plan to the specific needs of the organization or of the project;

5.

Ease to reuse usability patterns;

6.

Ease to map prototypes with tasks and classes;

7.

Coherence of the presented prototypes to users’ tasks; and

8.

Usability of the presented prototypes according to users’ usability requests.

In order to decrease the impact of not having visual aids for defining the models, we intend to provide the transformation of the defined models into XML Metadata Interchange (XMI.) XMI is a specification based on the Extensible Markup Language (XML) created in order to allow easy interchange of information between modeling tools that support the Unified Modeling Language (UML). With the XMI specification of a model, it is possible to view the visual diagram in any UML modeling tool that supports this specification. Examples of these tools are: IBM Rational Rose [IBM, 2005], Poseidon [Poseidon, 2005], etc. In the case of the task model, not supported by these UML modeling tools, we intend to provide the transformation of the defined task models into a XML format supported by a stable task modeling tool, which is CTTE [Mori, Paternò & Santoro, 2002]. CASE STUDY

In this experiment, our intention was to prove that the proposed process is capable of facilitating the communication among SE and HCI professionals, thus bringing agility to their work by making them share their artifacts and knowledge; and improving the actual usability of UIs by performing a set of activities that make users an active part of the process.

Figure 4. IKnowU Supporting Use Cases We are following UPi to develop this tool and we are currently detailing its use cases. Our intention is to have the final system ready as a first version by the end of this semester. The first version will have the characteristic of not providing visual aids for defining use case models, task

We have applied UPi in Mentores Consulting, a software development organization, during the development of a system, called PlanexStrategy, which aims at planning and executing the strategies of organizations. In more details, it is a system in which organizations of any kind of business define their strategic goals, monitor their organizational processes, and manage their projects. The client was a governmental organization that usually has a good amount of software development organizations

providing services for them throughout the year for all sorts of systems, such as: finances, education, tourism, etc. All of the systems they request are used for their work in a daily basis and they must provide very reliable data. They also need systems that are web-based because most of the organization leaders need to access information remotely very often. Initially, we presented the process, detailing the activities, artifacts, and tools to be applied for the project managers and the entire development team. During this explanation, we pointed out which activities of their work would be changed (according to their current process) and in which activities the SE and HCI team members would have to work in an integrated manner. We are calling system analysts, software architects and programmers as SE team members and the UI designer and usability engineer as HCI team members. During the application of the process, the system analyst generated ten use cases using Rational Rose and task models for related use cases using CTTE. Paper sketch prototypes were generated based on the task models, by the UI designer to facilitate the review of requirements with users. Then, the SE and HCI team members got together to define the architecture. Using the Rational Rose, they reused previously defined usability and architectural patterns. They considered the paper sketch prototypes to define ten boundary classes, six business classes, and select five usability patterns, according to the UI Definition Plan, generated using a spreadsheet; then the architecture was refined based on the results of the HCI team work. Then, the teams separated so the UI designer could generate executable prototypes and validate them with users’ representatives, so that programmers could start implementing the system. At the end, both teams interacted to validate the system. Following, we present the perception of the organization leaders, development team members, and users’ representatives concerning the application of the process, resulting from meetings we had after the experiment. Users’ representatives defined usability requirements by selecting them from a list of options. They related that no other software organization had elicited such requirements with them before.

used to analyzing use cases and defining classes considering architectural patterns related to extensibility, for instance. But after a few examples, he was ready to work on his own. They found it very good to evaluate the requirements early in the process by analyzing paper sketches. They valued the evaluation of prototypes in an iterative manner because they evaluated one section of the system at a time. When we reached the evaluation of the system in the installation site, there were few errors that were pointed out by the users and also few evolution requests for future versions of the system. This is a very different scenario from the one with the previous version of the system, in which there were constant calls for fixing errors and requests to improve the system. This experience demonstrated that the clients were very satisfied with the quality of the final product, which the organization leaders pointed out as remarkable aspect for them. Users’ representatives commented how much the lack of consideration of usability requirements in the system made a difference at the end. When they actually saw, for instance, visual and sound alerts to prevent errors from occurring and the translation of the system in different languages to support internationalization in the final product, they noticed that the 2-hour meeting we had to elicit usability requirements was worth the time. This experience is one among others that made us define a more agile process because that is what most professionals in software organizations are looking for. They need, in a little amount of time, to perform activities for a software development project that will certainly result in a usable interactive system. By certainly, we mean that they can not run the risk of performing activities that will not add value to their final positive result. By positive result, we mean that they need to deliver a product that is usable and efficient so users feel satisfied when applying them in their daily work. As a result, we can answer the questions described previously concerning the process: 1.

Yes, the integrated SDP is increasing the overall usability of the final product because the artifacts are complementary, dependent, and shared between the SE and HCI teams. They are known by all the professionals, but they do not need to have the same level of expertise as the professional who is producing the artifact. The execution of activities to produce the artifacts resulted in a better level of usability in the final system because they represent steps toward the actual application of usability. Instead of leaving usability to the desire or knowledge of UI designers or programmers.

2.

It depends, not all SE or HCI professionals are willing to learn and apply new artifacts. First, the

In order to start doing the task models, the system analysts were trained in how to use the CTTE tool. The trainings were a little bit time consuming for the project, which influenced on its agility. But, on the other hand, the hierarchical structure of task models was a good communication tool between the system analyst and the UI designer, who could intuitively design prototypes. One obstacle that was easy to overcome was the one of teaching and monitoring our software architect to design the architecture considering paper sketches and usability patterns. At first, he found it a little difficult because he was

organization leaders must support such changes by providing training for them. That is one good reason for them to be willing to learn new things. Second, the leaders need to monitor if they are applying in their work what they have learned. That is another good reason for them to apply new things. When the necessary support does not come from the leaders in the software organization, the minimum set of activities accepted by the process to guarantee usability in the final system are: a) the elicitation of usability requirements with users; b) the application of these requirements into the system architecture; c) at least one level of UI prototyping (such as paper sketches) based on the UI definition plan; and d) the implementation of usability patterns in the final system.

manner makes the user an active part of the process and results in a higher level of system usability and user satisfaction, since we are continually working according to their needs. 2.

Facilitate integration and communication – It is easier to work with a multi-disciplinary group (SE and HCI) when each professional knows their responsibilities in the process and acknowledge the advantages of artifacts from other areas of study through the application of an integrated process.

3.

Productivity – The definition of a lightweight process focusing on activities that add value to the usability of the product is crucial for professionals who seek rapid and efficient results.

4.

Reuse – The inclusion of users’ usability requests in the final system through the architecture facilitates the reuse of classes (usability patterns) in different projects, independent of the business domain.

5.

Reduced Development Cost – The use of prototypes helps users detect problems with the UI itself and the architecture before programming starts.

DISCUSSION

It is important to point out that this is not the first version of our process; we have been working on its definition for two years. As a result, we have learned many lessons through its applications in real projects, presentations, and also with reviews of articles submitted to conferences. First, we have learned that a process that integrates HCI and SE does not necessarily have to include everything that is good from both areas. We have to make choices on what is most important for our goals. Second, if we want an integrated process to work in real projects, from small to big organizations, we must keep it simple. The more roles, artifacts, and activities we include in it, the more people are reluctant to read it, understand it, or even apply it. Third, we do not have to re-invent the wheel. We can reuse the best practices from existing process and integrate them in order to reach our goals. Our process has a great influence from the RUP [Krutchen, 2000] and Constantine’s work [Constantine & Lockwood, 1999] since the beginning, and we had not shown (until now) how their practices and rules are followed in our approach. Following, there is a list of all the advantages we have noticed with the application of UPi in the organization mentioned previously. These advantages represent what new studies have defined as perceived internal and external ROI [Wilson & Rosenbaum, 2005]. Perceived internal ROI means perceived efficiencies that occur during the development of a product or service that can be attributed to the usability staff (e.g. elimination of re-work, generation of clear requirements, etc.). External ROI means that the usability staff developed products or services more profitable for the customer company and better for customers themselves (e.g. improvement of profits in sales, increase of customer satisfaction, etc.). 1.

Usability and User Satisfaction – The reviews with users of their requirements, use of prototypes, and the design of the final product in an iterative

FUTURE WORK

We plan to continue working on defining and improving UPi; specifying, modeling, and implementing IKnowU; and continue evaluating both the process and the tool according to the aspects presented in the previous sections. After that, we intend to have defined a process and developed a tool that can be applied in any software organization that is concerned with the usability of the final system; that is willing to make adaptations in its existing process; and that is capable of allocating its professionals in trainings of the process and tool. We intend to quantitatively measure the actual internal and external ROI in future experiments in order to achieve four main goals: 1.

Identify the process activities that most contribute to the internal ROI;

2.

Identify the process activities that most contribute to the external ROI;

3.

Identify the usability contributions for the internal ROI;

4.

Identify the usability contributions for the external ROI.

One aspect that we are still analyzing is the customization of UPi in order to demonstrate improvement to the organization process at no cost. This means that the application of UPi should result in gains for the organization, such as, fewer bugs in the final system at no additional cost (e.g. costs with trainings) for the software organization that intends to apply it.

We also intend to study methods to apply in the UI definition plan. We are searching in other areas of study, such as multi-criteria decision making in order to apply a stable algorithm. CONCLUSION

With this research work, we intend to make two main contributions. The first one is to contribute with software organizations and academic institutions with a process that aims to bring usability, productivity, and integration to interactive systems development in order to help practitioners, researchers, and professors in teaching how to generate or in generating interactive systems with quality and usability. Quality can be achieved by providing to users the functionality they have required without errors, or at least, with a minimum number of errors. Usability is acquired by designing UI that focus on facilitating the use of the system. The second contribution is the definition of a tool that aims to help with the integration of professionals from SE and HCI in order to design usable UIs, and to facilitate their communication. REFERENCES

1. Bass, L. J, John, B. E. & Kates, J. Achieving usability through software architecture. Carnegie Mellon University/Software Engineering Institute Technical Report No. CMU/SEI-2001-TR-005. 2001.

2. Cockburn, A. Writing Effective Use Cases. AddisonWesley, Reading, 2001. 3. Constantine, L., Lockwood, L. Software for Use: A Practical Guide to Models and Methods of UsageCentered Design. Addison-Wesley, Reading, 1999. 4. Coyette, A., Faulkner, S., Kolp, M., Limbourg, Q., Vanderdonckt, J., SketchiXML: Towards a Multi-Agent Design Tool for Sketching User Interfaces Based on UsiXML, Proc. of 3rd Int. Workshop on Task Models and Diagrams for user interface design TAMODIA’2004 (Prague, November 15-16, 2004), Ph. Palanque, P. Slavik, M. Winckler (eds.), ACM Press, New York, 2004, pp. 75-82. 5. IBM Rational Rose. 2005. Available at: http://www306.ibm.com/software/rational. Accessed in April, 12th, 2005. 6. ISO 13407. Human-centred design processes for interactive system teams. 1999. 7. John, B. E., Bass, L. J., & Adams, R. J. Communication across the HCI/SE divide: ISO 13407 and the Rational

Unified Process®. In proceedings of HCI International, Crete, June, 2003. 8. Juristo, N.; Lopez, M.; Moreno, A.; Sánchez, M. Improving Software Usability through Architectural Patterns. In: Workshop Bridging the Gaps between SE and HCI - International Conference on Software Engineering (ICSE), 2003, USA. 2003, pp. 12-19. 9. Kruchten, Philippe. The Rational Unified Process - An Introduction. 2 ed. New Jersey: Addison-Wesley, 2000. 10. Krutchen, P., Ahlqvist, S., Bylund, S. User Interface Design in the Rational Unified Process. Object Modeling and User Interface Design. Mark Van Harmelen Eds. Addison-Wesley, 2001. 11. Lauesen, S. Task Descriptions as Functional Requirements. IEEE Computer Society, 2003. 12. Mori G., Paternò F., Santoro C. CTTE: Support for Developing and Analyzing Task Models for Interactive System Design. IEEE Transactions on Software Engineering. August, 2002, pp.797-813. 13. MVC. 2000. Available http://java.sun.com/blueprints/patterns/MVC.html. Accessed in: April, 30th, 2005.

at:

14. Nielsen, J. Usability Engineering. Boston: Academic Press, 1993. 15. Paternó, F., Mancini, C., Meniconi, S. ConcurTaskTrees: A Diagrammatic Notation for Specifying Task Models, Proceedings Interact’97, pp.362-369, July’97, Sydney, Chapman&Hall, 1997. 16. Poseidon. 2005. Available at: http://www.gentleware.com. Accessed in: April, 30th, 2005. 17. Rosson, M. B., Carroll, J. M. Scenarios, Objects, and Points of View in User Interface Design. Object Modeling and User Interface Design. Mark Van Harmelen Eds. Addison-Wesley, 2001. 18. Struts. 2005. Available at: http://struts.apache.org. Accessed in: April, 30th, 2005. 19. Welie. 2005. Available at: http://www.welie.com. Accessed in: April, 30th, 2005. 20. Wilson, C., Rosenbaum, S. Categories of Return on Investment and Their Practical Implications. Cost Justifying Usability. An Update for the Internet Age. Randolph Bias & Deborah Mayhew Eds. Elsevier, USA, 2005.