A Unified Process for Interactive Systems Kenia Soares Sousa Mentores Consultoria Rua João Carvalho, 800 - S.511 (85) 224 7055 [email protected] ABSTRACT

This research work intends to present a new software development process (SDP) that, besides focusing on cost and schedule, also includes some Human-Computer Interaction (HCI) aspects along the software life cycle. Such HCI aspects include usability, accessibility, acceptability, guidelines application, and model-based User Interface (UI) generation. This study is based on the worldwide renowned Rational Unified Process (RUP), which is a basis for the definition of this new SDP, called the UPi (Unified Process for Interactive Systems). The purpose of this integration is to develop interactive systems that are easy to learn and use, therefore, helping users in performing their daily tasks in an efficient manner. Besides that, this integration intends to bring together researchers from the HCI and Software Engineering (SE) areas of study, which started to be a concern in the research community in the last years. Keywords

Human-Computer Interaction, Software Engineering, Interactive Systems, Software Development Process, RUP. INTRODUCTION

Most SDP focus on delivering software on the pre-defined cost and schedule, and that accommodates users' expectations related to functionalities. To achieve this goal, most activities performed during the software lifecycle are related to: scope and risk control; functionalities definition; components design, implementation, and integration; functionalities tests; change control; tools definition; and documentation development. On the other hand, there is the focus on the users’ characteristics, the tasks they perform, the work environment where they are located, and the devices they use to perform their tasks. This focus is more closely related to human factors [12], usability, acceptability, accessibility, guidelines, and UI modeling. These aspects, when applied in a SDP, may bring benefits such as decrease in time to learn how to use the software, increase in the speed in performing tasks using the software, and increase in the user satisfaction towards the software. By analyzing these differences, we chose an existing SDP and adapt it towards having HCI aspects. The chosen SDP is the RUP [3] because it is a well-defined, applied worldwide and flexible SDP. The RUP has successful experiences in many international org anizations, besides, it has workflows that are easily adaptable and applicable, and

Elizabeth Furtado Universidade de Fortaleza Av. Washington Soares, 1321 (85) 477 3079 [email protected] it follows the best practices necessary to produce software with quality in a predictable manner. The result of this adaptation is the creation of a new SDP, called the Unified Process for Interactive Systems (UPi). The case study used in this research work is the development of a project management system for software development organizations. This system has the purpose of controlling information of software development projects, its processes, phases, activities, documents, and workers’ roles. This work is a continuous research on the integration of HCI aspects in SE, more specifically in the SDP. Our intention is to associate both areas in order to increase user satisfaction from the use of software derived from a usercentered SDP. We exposed our first ideas related to the addition of HCI aspects in only four RUP workflows in [13], and detailed and exemplified this work in [14]. Now, we extend this work by applying HCI aspects in all of the RUP workflows. RELATED WORK

Kruchten [4] presents the concern on UI design in the RUP by including the worker UI Designer, responsible for performing the activities UI Modeling and UI Prototyping in the Requirements Workflow. In the activity UI Modeling, the UI Designer analyzes the use case model, and creates a use case storyboard. This artifact is composed of a textual description of the interaction between the user and the system, interaction diagrams, class diagrams, usability requirements, references to the UI prototype, and a trace dependency to the use case. In the activity UI Prototyping, the UI Designer designs and implements the UI prototype, then obtains feedback from other project members, external usability experts, and users. Even though there is a concern on the UI design, there is no concern on the specification of users’ tasks. Use cases differ from task descriptions in the sense that they do not provide details related to purpose, preconditions, frequency, and post conditions. Such specification is not a use case goal, but it is responsibility of task descriptions. We suggest use case and task modeling to be used in a complementary manner. Phillips [9] suggests the use of tabular representation of use cases in order to describe the flow of events, and the use of UI element clusters, which can be used as references to the UI prototype. Tabular use cases separate user and system actions. Soren Lauesen [5] argues that separating users' and

systems' actions as early as in requirements may be a barrier for future decisions in the project. Therefore, he suggests the use of task descriptions, which specify what the users and the system shall do, not dividing the work between them. On the other hand, Constantine [1] focuses on preparing task cases that address users' intentions rather than their actions and on system responsibilities rather than on responses. This approach offers a requirement modeling more technology-independent, providing designers the flexibility related to the actual interface components when designing the UI, but maintaining conformity to users' needs. There are other research works related to extending the RUP, such as [8] and [6], but they concern changes in the process regarding aspect-oriented principles. Piveta [8] suggests changes in the Analysis and Design Workflow in order to suit the modeling techniques necessary for the Aspect-Oriented Software Development. Massoni [6] suggests changes in the Implementation Workflow by creating the Progressive Implementation Method, which provides the progressive implementation of three different aspects: persistence, distribution, and concurrency. Therefore, none of their extensions affect the generation of usable UIs. UPi CHARACTERISTCS

The UPi is composed of nine workflows: Requirements, Analysis and Design, Implementation, Test, Project Management, Business Modeling, Configuration and Change Management, Environment, and Deployment. Each workflow is composed of workflow details, which have a set of activities to be performed by workers that produce valuable results, called artifacts. Figure 1 depicts the relationship among the UPi workflows and their specific artifacts and workers. The six best practices adopted by the UPi are: •Develop software iteratively – HCI aspects can be applied since early in the lifecycle until the product is ready for release, what raises the quality of the final product. Prototypes can be generated by applying the results of modeling techniques starting in the requirements workflow. •Manage requirements - Analysis of the users' tasks, the environment where they are performing their tasks, and the devices that they are using, guaranteeing that the software accommodates users' reality. •Use component-based architecture - Modular architecture definition, but, more specifically, it suggests the adoption of the n-tier architecture, along with the MVC design pattern. They provide the software to be divided in independent layers, what provides higher reusability and flexibility. •Visually model software – The use of user, task, context, and domain models. These models can be directly aided by graphical scenarios. •Continuously verify software quality - Quality assessment also starts early in the lifecycle and focuses on areas of highest risk. UPi focuses on usability, accessibility, and acceptability.

Figure 1 – Relationship among UPi workflows, workers, and artifacts • Control changes to software - UPi proposes maintainability efforts towards the models defined during requirements elicitation. THE REQUIREMENTS WORKFLOW

This workflow has the purpose of defining the system scope, focusing on users' needs. The system scope needs to be based on the detection of problems in the target organization and on understanding users' needs. Then, this scope needs to be managed in order to reflect users' changing requests. This workflow can be enhanced with the addition of the following three workflows details: • “System Modeling” is a workflow detail composed of the following two activities: •“User Modeling”, which specifies characteristics of users who will interact with the system. The user model defines the scope of the user population, including characteristics, such as intellectual and physical

abilities, previous experience with using interactive systems and performing the required task. Its greatest advantage is the impact of users’ classification on the UI suitability to their individuality; •“Task Modeling”, which defines the tasks performed by users. The task model is a hierarchical structure of tasks and sub-tasks graphically represented. In this work, we used the MAD formalism [7], in which a task is divided in two or more subtasks that are performed in order to fulfill a certain objective. The task model is generated based on the use case model, defined during this workflow, which defines system’s processes. Each process is represented by a use case that has a set of tasks associated to it. This model is useful to allow designers to envision what tasks users perform, predict difficulties, evaluate systems, measure system complexity, and predict performance, among other aspects. Such model can be generated by collecting information from talking to users about their working tasks, observing them working and analyzing operating manuals. Figure 2 depicts a task model that specifies the sub-tasks necessary to achieve the goal of defining an activity for a software project;

applied in the UI during the implementation workflow, and the system evaluation during the test workflow are based on these requirements. These requirements can be gathered by analyzing the user, the task, and the context of use models prepared during this workflow; and they are organized in use cases. THE ANALYSIS AND DESIGN WORKFLOW

This workflow has the purpose of transforming requirements into a design specification useful for the implementation workflow. In order to enhance it with HCI aspects, activities are included in two existing workflow details and one new workflow detail is added to this workflow, as follows: In the workflow detail “Analyze Behavior”, use case behavioral descriptions are analyzed and transformed into elements useful for design. This workflow can be enhanced with the activity “Refinement of the Task Model”, in which the task model, generated in the requirements workflow, is defined based on the use case descriptions. Here, it may be refined by considering characteristics of different kinds of users and different interaction styles. The workflow detail “Design Components” in which the class characteristics and relationships are completely specified, the class model can be enhanced by being specified in a n-tier architecture. In such a class model, the first layer represents the interface, the second one is the control layer, the third is the business logic layer, and the fourth one is the data layer. Besides these adaptations, the Analysis and Design workflow is further enhanced with the addition of a new workflow detail, which is the “UI Conceptual Design”, composed of two activities:

Figure 2 – Task Model • The “Definition of Guidelines” workflow detail is the definition of textual recommendations based on the users, their tasks, their working environment, and the system domain. Guidelines definitions are important to provide consistency in the UI, increasing user productivity, decrease number of errors, among other aspects related to usability. Guidelines defined during the requirements workflow are related to the system conceptual level, and are used as a basis for the definition of guidelines related to other workflows, prepared during the environment workflow. For example, the guideline “use metaphors to operations” is useful to define the guideline “use a printer image for the print operation”, necessary for the UI generation during the implementation workflow. Guidelines are defined based on the usability requirements. For instance, a use case “system maintenance” could have maintenance speed as one usability requirement, which would generate the following semantic guideline: use metaphors that group a set of actions familiar to the users. • The “Definition of Usability Requirements” workflow detail is the definition of requirements related to users' satisfaction and the performance of the system. Usability requirements directly influence aspects of the system quality of use (e.g. easy access to shortcuts, number of data users need to remember, etc.), because the guidelines

•“Preparation of the Interface Conceptual Model” (MIC) [2] that represents the interactive part of the system by graphically representing the navigational structure of the system. The MIC is generated based on the task model, on the context of use model, and on a set of guidelines applied to translate the task model into the MIC. For instance, there is one guideline that states that if a task in the task model shall only be performed when a user validates it, then two interaction objects have to be created in the MIC. There is another one that states that each interruptible task in the task model shall originate an interactive space in the MIC. The production of the MIC can generate design options because the designer is able to prepare this model for different kinds of users, e.g. experts and novices; •“Analysis of Design Options” that are generated using MIC. Figure 3 depicts the association of usability requirements to design options of a specific task in order to help the designer when trying to choose, along with the users, the best option.

In the workflow detail “Evaluate Project Scope and Risk”, the project manager is responsible for evaluating the project's characteristics, and associated risks. It can be enhanced with prototyping. The prototyping technique is useful to check the conformance of specified functionalities according to users' needs, therefore, reducing the risk of having to re-work.

Figure 3 – Usability requirements related to design options THE IMPLEMENTATION W ORKFLOW

This workflow focuses on the codification and integration of components. Focusing on the HCI perspective, this workflow can be altered by the addition of some activities in existing workflow details: The workflow detail “Implement Components” in which classes and objects are implemented, developed visual components can be enhanced with the activity “Guidelines Application”. Components layout can be improved by the application of guidelines in the lexical level, which may prevent users from making errors, such as guidelines for error messages, data display, color, and data entry. Some organizations adapt lexical guidelines to the reality of their cultural needs and characteristics, producing a document composed of a collection of guidelines, called style guide. Eventually, guidelines are not very easily applicable because of the lack of consistency among them. Therefore, there are some tools that intend to help in the application of guidelines during the generation of UIs, such as SEGUIA [16] and SIERRA [15]. SEGUIA processes guidelines in order to generate concrete interaction objects, and SIERRA organizes guidelines in a uniform structure. THE TEST WORKFLOW

This workflow focuses on the product quality by verifying the integration of components, correcting the implementation of requirements, and correcting detected anomalies. Such quality can be better achieved with the concern on usability aspects of the product. This workflow is further enhanced with the addition of a new workflow detail, which is the “Usability Evaluation”. Usability Evaluation [10] involves analysis of a system in the users' point of view. That is, this evaluation takes into consideration: users' characteristics, the tasks they perform, the environment in which they work, and the technology they use. This workflow detail produces test cases that describe what aspects to be tested in the system. Test cases are differentiated in this workflow detail because it contains a list of usability attributes defined according to usability requirements, instead of having functionality attributes. THE PROJECT MANAGEMENT WORKFLOW

The purpose of this workflow is to manage software projects in order to deliver a product that meets users' needs. Its main focus is to plan the project, manage risks, and monitor the project's progress. In addition to that, this workflow includes HCI techniques that intend to help in the delivery of a product that is usable by its users.

The workflow detail “Develop Software Development Plan”, in which the project manager is responsible for generating artifacts related to the software development, can be enhanced by the addition of a new activity, which is to “Develop a UI Acceptance Plan”. This activity results in the artifact UI acceptance plan that is based on the UI guidelines defined in the environment workflow. This plan can be used by designers in order to check the conformance of the UI according to established guidelines and to users' needs, accessed through the user model, prepared during the requirements workflow. In order for a UI to be accepted by its end users, the users’ needs to evaluate the UI according to its conformance to the guidelines established in this plan, and then, sign it when the UI is approved. THE BUSINESS MODELING WORKFLOW

This workflow focuses on establishing a common understanding of the target organization in order to derive the software requirements. The understanding of the organizational structure (e.g. processes, roles, etc.) has an impact on the delivered product, which should help workers in accomplishing their daily tasks. The focus on users’ characteristics and environment influences designers in better understanding the organizational structure. In the “Assess Business Status” workflow detail, in which the business-process analyst is responsible for understanding the target organization, include the activity “Prepare Context of Use Model”. This model represents the environment where users are located in order to perform their tasks. The context of use model can be generated by the analysis of the environment where the interactive system will operate (e.g. analysis of users’ surroundings, situation, and location). This model will be important to adapt the system’s physical UI based on environment’s constraints, especially for mobile devices that are used in a wide variety of locations. For instance, a palm will be necessary for a system while users work walking. The context of use model can have one or more associated graphical representations, which can be scenarios. A scenario represents a situation lived by a user while interacting with a system to perform a task. In the “Refine Roles and Responsibilities” workflow detail, in which the business designer is responsible for defining details of business workers and entities, the user model is useful for the activity “Detail Business Worker”. The user model represents users’ characteristics, focusing more on human factors than on work responsibilities. This addition brings a perspective related to users’ reality, different from a business point of view.

THE CONFIGURATION WORKFLOW

AND

CHANGE

MANAGEMENT

packaged, installed, and users are trained. The inclusion of human factors increases the probability of satisfying users.

This workflow has the purpose of maintaining the integrity of project artifacts as they evolve along the life cycle. Such integrity is achieved by controlling change requests, versions of artifacts, and the project status. The participation of users improves configuration and change control.

The workflow detail “Test Product at Installation Site”, in which acceptance tests are performed, can be enhanced with the assessment of users’ perception of the installed software. The human-factor aspects analyzed during this activity are: acceptability and accessibility of the software. The artifact User Acceptance Agreement is signed by users depending on their perception of the software.

The workflow detail “Manage Change Requests”, in which the change control manager is responsible for maintaining a uniform change control process, can be enhanced with the addition of the worker “User” for the activity “Review Change Request”. The purpose is to ensure that they participate in planning and deciding changes viability, not only being informed on the state of the product. This participation leads to decrease in errors related to lack of accordance to users´ requests. The artifacts controlled in this workflow are those that make up the deliverable product. This is specially noticed in the workflow detail “Manage Baselines & Releases” that has the activity “Create Deployment Unit”, which is composed of a build (an executable collection of components), documents (end-user support material and release notes) and installation artifacts [11]. In addition, in the workflow detail “Change and Deliver Configuration Items”, the activity “Make Changes” is performed according to a work order that refers to software functionalities. On the other hand, the artifacts focused on the UPi are those that directly have an impact on the UI generation, e.g., the user and the task models. Such models must be changed according to the requests made that, consequently, reflect changes in the UI. The evaluation of changes in these models facilitates the analysis of cost and schedule impacts before the actual change is performed in the product. THE ENVIRONMENT WORKFLOW

This workflow has the purpose of providing adequate support for the development organization in selecting, acquiring, and adapting tools, processes, and methods in conformance to the organizational culture. In addition to that, guidelines can be a concern in this workflow in order to achieve usability more effectively. The workflow detail “Prepare Guidelines for an Iteration”, in which specific workers are responsible for defining guidelines of their knowledge area (e.g. implementation guidelines), can be enhanced with the ergonomist defining guidelines to be applied during the transition between: i) the use case and the conceptual interface model and; ii) the task and the conceptual interface model. These guidelines applied during the transition of models are useful for accurately linking models with the goal of generating UI consistent with users’ requirements.

Another activity that can enhance this workflow detail is the “User Model Verification” according to its consistency to the reality of software users. While training users, the trainers are able to verify if the real users are the ones modeled during the requirements workflow. This assessment is important in order to guarantee that UI adaptations are appropriate to users. When inconsistencies are detected, the software needs to go through changes in order to reflect the reality of users. CONCLUSION This research work presents the nine RUP workflows adapted with HCI aspects, generating UPi workflows. The Requirements Workflow is enhanced by focusing on model-based UI generation, and on usability goals. The Analysis and Design Workflow is enhanced by focusing on different kinds of users and interaction styles, dialogue independence, and usability requirements. The Implementation Workflow is enhanced by focusing on the application of UI guidelines. The Test Workflow is enhanced by focusing on evaluating the product based on users´ point of view. The Project Management Workflow is enhanced by focusing on users' point of view and needs, and with the application of UI guidelines. The Business Modeling Workflow is enhanced by focusing on users´ characteristics and environment, and with the application of model guidelines. The Configuration and Change Management Workflow is enhanced by focusing on the active participation of users and on the control over artifacts related to the UI generation. The Environment Workflow is enhanced by focusing on defining guidelines to help generate UIs according to users´ requirements. The Deployment Workflow is enhanced by focusing on users´ characteristics and their perception of the installed software. The focus of HCI aspects in the UPi workflows brings benefits both to the development team and users. The first ones benefit from the decrease of re-work, related to the focus on users´ needs along the entire life cycle. The latter benefit from usability, acceptability, and accessibility aspects, leading into satisfaction, acquired from the association of HCI aspects in the Software Development Process. REFERENCES

1.

CONSTANTINE, Larry; Lockwood, Lucy. Software for Use: A Practical Guide to Models and Methods of usage-Centered Design. Massachusetts: AddisonWesley, 1999.

2.

FURTADO, Elizabeth; Sousa, Kênia; CÓLERA, César. An Environment to Support Developers in

THE DEPLOYMENT WORKFLOW

This workflow has the purpose of turning the finished software product over to its users in an efficient manner. This efficiency is achieved when the software is tested,

Elaborating a Participatory and Evolutionary Help on Style Guide. In: Seminário em Fatores Humanos para Sistemas de Computação, 2002, Fortaleza. Usabilidade: um direito. Fortaleza: Banco do Nordeste, 2002, p. 84 – 92. 3.

KRUCHTEN, Philippe. The Rational Unified Process - An Introduction. 2 ed. New Jersey: Addison-Wesley, 2000.

4.

KRUCHTEN, Philippe; Ahlqvist, S; Bylund S. User Interface Design in the Rational Unified Process, in Object Modeling and User Interface Design. Massachusetts: Addison-Wesley, 2001.

5.

LAUESEN, Soren. Task & Support - Task Descriptions as Functional Requirements. In: Proceedings of AWRE, 2001, p. 83-91.

6.

MASSONI, Tiago; SAMPAIO, Augusto; BORBA, Paulo. A RUP-Based Software Process Supporting Progressive Implementation. In: 2002 International Conference of the Information Resources Management Association (IRMA'2002), 2002, p. 480-483.

7.

PIERRET-GOLBREICH, Christine.; SCAPIN, Dominique. MAD: Méthode Analytique de Description des tâches. Colloque sun língénierie des interfaces homme-machine. Sophia-Antipolis. 1989.

8.

PIVETA, Eduardo Kessler; DEVEGILI, Augusto Jun. Aspects in the Rational Unified Process’ Analysis and Design Workflow. In: Proceedings of the Aspect Oriented Design (ADO), 2002.

9.

PHILLIPS, Chris; KEMP, Elizabeth. In Support of User Interface Design in the Rational Unified

Process. In: Proceedings of the Third Australasian User Interface Conference, 2002, p. 21-27. 10. PREECE, Jenny et al. Human-Computer Interaction. England: Addison-Wesley, 1994. 11. RUP. The Rational Unified Process. Available in: . Accessed in 23 apr. 2003. 12. SHNEIDERMAN, Ben. Designing the User Interface: Strategies for Effective Human-Computer Interaction. 3 ed. England: Addison-Wesley, 1998.

13. SOUSA, Kenia; Furtado, Elizabeth. Integration of Human-Computer Interaction in a Software Development Process. In: Human-Computer Interaction International, 2003. To be published. 14. SOUSA, Kenia; Furtado, Elizabeth. RUPi – A Unified Process that Integrates Human-Computer Interaction and Software Engineering. In: International Conference on Software Engineering, 2003, p. 41-48. 15. VANDERDONCKT, Jean. Accessing guidelines information with Sierra. In: Proceedings of Fifth International Conference on Human-Computer Interaction (HCI International 1995). London: Chapman & Hall, 1995, p. 311-316. 16. VANDERDONCKT, Jean. Assisting Designers in Developing Interactive Business Oriented Applications. In: Proceedings of the Eighth International Conference on Human-Computer Interaction (HCI International 1999). Mahwah: Lawrence Erlbaum Ass., 1999, p. 1043-1047.