software architecture assessment of usability eelke folmer, jan bosch ipa lentedagen, made

40
Software Architecture Assessment of Usability Eelke Folmer, Jan Bosch IPA lentedagen, Made.

Post on 21-Dec-2015

219 views

Category:

Documents


4 download

TRANSCRIPT

Software Architecture Assessment of Usability

Eelke Folmer, Jan Bosch

IPA lentedagen, Made.

STATUS project

• European Research Project: STATUS (Software Architecture that supports Usability)

• Duration: 12/01-12/04 • Partners:

– Technical University of Madrid (Spain)– University of Groningen (Netherlands)– Imperial College (England)– IHG (Spain)– LogicDIS (Greece)

Overview of my presentation

1. Introduction2. Relationship between usability & SA3. SALUTA: steps4. Case studies5. Research questions & Future work

Introduction

Usability Software QualityTradeoffs (Cost, Quality, Time) Practice “Ensuring Usability is expensive”

Result systems with less than optimal usability

need: cost effectively engineer usable software

What Causes these high costs?

Majority of usability costs are spent during maintenance.

Some requirements are detected late Requirements are often weakly specified.

Requirements engineering techniques have only limited ability to capture all req.

requirements change during development.

Role of the SA

Hard and expensive to change a running system to Improve its usability

Causes:1. The impact of software architecture

on usability. 2. The impact of usability on software

architecture design.

Usability SA

The retrofit problem

Architectural assessment

SASA

Get rid of the “hard to change”

undo

SA Usability

Usability depends on:Information architecture Interaction architecture System quality attributes

SA design

Investigating the relationship between Usability and SA

Need to know the solutions that are hard to retrofit.

Investigate rel. SA & usabilityResult: SAU SA-Usability-FrameworkElements:• Usability attributes• Usability properties• Architecture sensitive usability patterns

Usability attributes

LearnabilityEfficiency of useReliability in useSatisfaction

Attributes “tell” you how to measure usability!

Usability Properties

• Based on heuristics/ design principles• Likely have architectural implications • Architecture sensitive usability Patterns can be used to fulfill these properties

Some examples:• Error management

– Error prevention– Error correction

• Consistency– Visual consistency– Functional consistency

Properties tell you how to design for usability!

Architecture sensitive usability

patternsConsider patterns:• that should be addressed during architectural design (architecture sensitive)

Patterns obtained from:• Existing (usability) pattern collections • Inductive process from different practical cases ( systems developed by industrial partners in STATUS project)

Undo (1/2)

Problem: Users do actions they later want reverse

Solution: Maintain a list of user actions and allow users to reverse selected actions.

Properties affected: + Error management: providing the ability to undo

an action helps the user to correct errors if the user makes a mistake. + Explicit user control: allowing the user to undo actions helps the user feel that they are in control of the interaction.

Undo (2/2)

Architectural Implications: record the sequence of actions carried out by the user and the system.

1. capture the entire state of the system after each user action.

2. capture only relative changes.

Implementation: Most implementations of multi-level

undo are based on the COMMAND pattern.

Relationships in the SAU framework

SALUTA steps

SALUTA Scenario based Architecture Level UsabiliTy Assessment

1. Describe required usability: create usage profile.

2. Describe provided usability: analyze the software architecture.

3. Evaluate scenarios: determine the support for the usage scenarios.

4. Interpret the results: draw conclusions from the analysis results.

1. Create usage profile 1/3

• Req. Rather weakly specified• Traditional specification techniques Rather metric/abstract

Solution: Use scenario profiles!- Scenarios express meaning of requirement

- More specific fine grained.

1.Create usage profile 2/3

ISO 9241: usability depends on: users, tasks, contexts of use.

user task Context of use

Account manager Insert new customer

training

Efficiency reliability satisfaction learnability

Req. 1. learnability2. satisfaction 3. reliability, 4. efficiency,

1. Create usage profile 3/3

1. Identify the users2. Identify the tasks3. Identify contexts of use 4. Determine attribute values5. Scenario Selection & weighing

2. Analyze architecture

Usability properties-Consistency-Provide feedback-Guidance-Error prevention

Usability properties-Consistency-Provide feedback-Guidance-Error prevention

Usability patterns-User Modes-Undo-Multiple views

Usability patterns-User Modes-Undo-Multiple views

Software architecture

framework

Design decisions

3. Evaluate scenarios

Users Tasks Context of use

Satisfaction Learnability Efficiency Reliability

Account manager

Insert new customer in database

training User should feel that he/she is in control

How easy this task is to understand

The time it takes to perform this task.

No errors should occur performing this task

USAGE PROFILE 1 4 2 3

Usability properties-Consistency-Provide feedback-Guidance-Error prevention

Usability patterns-User Modes-Undo-Multiple views

framework

Usability properties-Consistency-Provide feedback-Guidance-Error prevention

Usability patterns-User Modes-Undo-Multiple views

frameworkSoftware architecture

4.Interpret results

Interpretation• Goal of the analysis

– Selection– Design/ use results of the assessment.

• Requirements

Case studies

Aspect Webplatform Compressor eSuite

Type of system CMS E-commerce ERP

No of users > 20.000 > 100 > 1000

Goal Analyze architecture’s support for usability

Selection: Compare old versus new version of Compressor.

Selection: Compare old versus new version of eSuite.

Different types of users

3 3 2

Usage contexts Mobile / desktop/ Helpdesk

Mobile/Desktop/Standalone

Mobile/Desktop

System release status

Fully deployed Fully deployed Fully deployed

Case study

• CMS for managing WebPages within the university of Groningen.

• Allows creating, editing & managing and publish a variety of content (text, graphics, video etc).

• Consists of 200000 different web pages & 15.000 users

• Usability an explicit design goal

Web-platform analysis

Inputs to the analysis

• Usage profile creation functional requirements specification

• Architecture analysis software architecture description

• Interviews with usability engineer & software architect

Web-platform analysis

Selected users & tasks

# Users Tasks example 1 End-user Quick search Find course X

2 End-user Navigate Find employee X

3 Content Administrator Edit object Edit course description

4 Content Administrator Make object Create new course description

5 Content Administrator Quick search Find course X

6 Content Administrator Navigate Find phone number for person X

7 CMS Administrator Edit object Change layout of portal X

8 CMS Administrator Make object Create new portal medical sciences

9 CMS Administrator Delete object Delete teacher X

10 CMS Administrator Quick search Find all employees of section X

11 CMS Administrator Navigate Find section library

Create APT table 1/2

Users Tasks Satisfaction Learnability Efficiency Reliability

End-user Navigate

Web-platform analysis

Navigating should be intuitive and self explanatory

Always let the user know where he is

Students are not familiar with the system

Users Tasks Satisfaction Learnability Efficiency Reliability

End-user Navigate 1 4 2 3

Create APT table 2/2

Web-platform analysis

Architecture description

Web-platform analysis

Multichanneling

History logging

User profiles

Architecture description 1/2

Web-platform analysis

[pattern]- History Logging - There is a component that logs every user action. I t can be further augmented to also monitor system events (i.e. “the user failed to login 3 consecutive times”). History logging is especially helpful for speeding up the object manipulation process.

- Cookies are used to prevent users from having to login again when a connection is lost. Cookies also serve as a backup mechanism on the client site. (To retrieve lost data).

[property] - Accessibility

Disabilities

Multi channel

Multi channeling is provided by the web server which can provide a front end to I -Mode or other devices based on specified XLST templates.

Internationalization

- Support for Dutch / English language, each xml object has different language attribute fields.

- J ava support Unicode

Architecture description 2/2

Web-platform analysis

[pattern]- History Logging - There is a component that logs every user action. I t can be further augmented to also monitor system events (i.e. “the user failed to login 3 consecutive times”). History logging is especially helpful for speeding up the object manipulation process.

- Cookies are used to prevent users from having to login again when a connection is lost. Cookies also serve as a backup mechanism on the client site. (To retrieve lost data).

[property] - Accessibility

Disabilities

Multi channel

Multi channeling is provided by the web server which can provide a front end to I -Mode or other devices based on specified XLST templates.

Internationalization

- Support for Dutch / English language, each xml object has different language attribute fields.

- J ava support Unicode

Visual consistency

Scenario evaluation

Web-platform analysis

Users Tasks Satisfaction Learnability Efficiency Reliability

End-user Navigate 1 4 2 3

System feedback

Multipleviews

Contextsensitive help

Visual consistency

++

+ + +

Interpretation

Scenario nr. # patterns # properties support

1 4 5 +

2 3 6 +

3 9 3 -

4 9 3 -

5 4 5 ++

6 3 6 +

7 10 3 ++

8 10 3 +

9 10 3 +

10 4 5 +

11 3 6 ++

SA provides sufficient support

Validation / research questions

• Usage profile representative?Webplatform Usability tests:• No SA related usability issues were discovered (yet)

• usability tests show learnability for content admins is not supported very well (cannot be traced back to insufficient support of the SA)

SALUTA experiences

1. Usage profile creation• Difficult to transform requirements to scenarios• Specification of certain quality attributes is

difficult during initial design• Cost benefit tradeoffs• Representativeness of the usage profile

2. Architecture analysis• Non-explicit nature of architecture design• Validation of the SAU framework• Qualitative nature of SAU framework

SALUTA experiences

3. Scenario evaluation• Evaluation is guided by tacit knowledge

4. Interpretation• Initially Lacked a frame of reference

General experiences

• Lack of integration of SE and HCI processes

• “Technology” driven design • Impact of software architecture design on usability

• Accuracy of the analysis is unclear• Design rather than evaluate

Future work

• Tool support for Usage profile creation & scenario evaluation

• Reworking the set of patterns & provide specific implementation details

• Specialization of framework to particular domains & extension to other qualities (usability, security safety)

Future case studies• Expand our “frame of reference”• Measure decrease in usability related maintenance costs

Concluding

Main benefits of using SALUTA:- Be able to predict the SA support of usability (which could not be done before)

- Allow for more usability “tuning”- Save on maintenance costs.- Systems with higher usability.

The last slide!

Questions???

More on: www.designforquality.com