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

2. 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)

3. Overview of my presentation 1.Introduction 2.Relationship between usability & SA 3.SALUTA: steps 4.Case studies 5.Research questions & Future work

4. Introduction  Usability  Software Quality  Tradeoffs (Cost, Quality, Time)  Practice  “Ensuring Usability is expensive”  Result  systems with less than optimal usability  need: cost effectively engineer usable software

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

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

7. Usability  SA The retrofit problem Architectural assessment SA Get rid of the “hard to change” undo

8. SA  Usability Usability depends on:  Information architecture  Interaction architecture  System quality attributes SA design

9. Investigating the relationship between Usability and SA Need to know the solutions that are hard to retrofit.  Investigate rel. SA & usability  Result: SAU SA-Usability-Framework Elements: Usability attributes Usability properties Architecture sensitive usability patterns

10. Usability attributes  Learnability  Efficiency of use  Reliability in use  Satisfaction Attributes “tell” you how to measure usability!

11. 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!

12. Architecture sensitive usability patterns Consider 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)

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

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

15. Relationships in the SAU framework

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

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

18. 1.Create usage profile 2/3 ISO 9241: usability depends on: users, tasks, contexts of use. usertaskContext of use Account managerInsert new customer training Efficiency reliability satisfaction learnability Req. 1.learnability 2.satisfaction 3.reliability, 4.efficiency,

19. 1. Create usage profile 3/3 1.Identify the users 2.Identify the tasks 3.Identify contexts of use 4.Determine attribute values 5.Scenario Selection & weighing

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

21. 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 framework Software architecture

22. 4.Interpret results Interpretation Goal of the analysis –Selection –Design/ use results of the assessment. Requirements

23. Case studies AspectWebplatformCompressoreSuite Type of systemCMSE-commerceERP No of users> 20.000> 100> 1000 GoalAnalyze 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 332 Usage contextsMobile / desktop/ Helpdesk Mobile/Desktop/Stan dalone Mobile/Desktop System release status Fully deployed

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

25. Inputs to the analysis Usage profile creation  functional requirements specification Architecture analysis  software architecture description Interviews with usability engineer & software architect Web-platform analysis

26. Selected users & tasks

27. Create APT table 1/2 UsersTasksSatisfactionLearnabilityEfficiencyReliability End-userNavigate 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 UsersTasksSatisfactionLearnabilityEfficiencyReliability End-userNavigate1423

28. Create APT table 2/2 Web-platform analysis

29. Architecture description Web-platform analysis Multi channeling History logging User profiles

30. Architecture description 1/2 Web-platform analysis

31. Architecture description 2/2 Web-platform analysis

32. Visual consistency Scenario evaluation Web-platform analysis UsersTasksSatisfactionLearnabilityEfficiencyReliability End-userNavigate1423 System feedback Multiple views Context sensitive help Visual consistency + + + + +

33. Interpretation Scenario nr. # patterns# propertiessupport 145+ 236+ 393- 493- 545++ 636+ 7103++ 8103+ 9 3+ 45+ 1136++ SA provides sufficient support

34. 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)

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

36. SALUTA experiences 3. Scenario evaluation Evaluation is guided by tacit knowledge 4. Interpretation Initially Lacked a frame of reference

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

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

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

40. The last slide! Questions??? More on: www.designforquality.com