integrating usability into the software development · 2016-04-14 · integrating usability into...

Integrating usability into the softwaredevelopment

Analysis of a software development process

Diploma Thesis

Heike Wagner

- Corrected Version -

First supervisor: Prof. Dr. Horst Oberquelle

Second supervisor: Prof. Dr. Christiane Floyd

Dept. of Computer Science

University of Hamburg, Germany

October 8, 2004

Addresses

Diploma thesis at Dept. of Computer ScienceUniversity of HamburgVogt-Kolln-Straße 3022527 Hamburg

Author: Heike WagnerUniversity of Hamburg

First supervisor: Prof. Dr. Horst OberquelleUniversity of HamburgDept. of Computer Science, ASI

Second supervisor: Prof. Dr. Christiane FloydUniversity of HamburgDept. of Computer Science, SWT

Registered trademarks are used in this thesis. All rights reserved.

iii

Eidesstattliche Erklarung

Die vorliegende Diplomarbeit habe ich selbstandig durchgefuhrt. Dabei habe ich keineanderen als die angegebenen Quellen und Hilfsmittel verwendet.

Hamburg, 12. Mai 2004

Heike Wagner

v

Acknowledgements

Many people were involved in the writing of this thesis and have provided me with a lotof help. My heartful thanks go to the following people:

Prof. Dr. Horst Oberquelle, who at first introduced me to Computer–HumanInteraction and helped me with critical comments to reconsider some as-pects of this thesis

Prof. Dr. Christiane Floyd, who gave me helpful feedback in restructuringmy ideas

Dr. Stefan Thomas Gries, who provided me with useful tips on the Englishlanguage

Thoralf Rickert, who helped me solving technical problems, although he wasbusy with his own thesis

Dipl.-Ing. Gerhard Meier, who helped me to elaborate the subject in the in-dustrial environment

Dipl.-Inf. Peter Friese, who was an interesting and interested negotiating part-ner on usability issues

All my interview partners, who spent their (private) time to help me with theanalysis for this thesis

vii

Table of Contents

1 Introduction 1

1.1 Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Chapter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Usability 5

2.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Interdisciplinarity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Work Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 Legal Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5 Business Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Usability Engineering 13

3.1 The place of Users in the development process . . . . . . . . . . . . . . . . 15

3.1.1 Waterfall, V and Spiral Model . . . . . . . . . . . . . . . . . . . . . 15

3.1.2 STEPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.3 The Usability Engineering Lifecycle . . . . . . . . . . . . . . . . . . 16

3.1.4 EN ISO 13407 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.5 Rational Unified Process . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Understanding the Context of Use . . . . . . . . . . . . . . . . . . . . . . . 23

3.2.1 Requirements Engineering . . . . . . . . . . . . . . . . . . . . . . . 23

3.2.2 Contextual Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.3 Scenario-based Design . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3 The Role of Participation and Prototyping . . . . . . . . . . . . . . . . . . 29

3.3.1 Participation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3.2 Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.4 Quality Assurance for Usability . . . . . . . . . . . . . . . . . . . . . . . . 35

3.4.1 Usability Testing and Inspection Methods . . . . . . . . . . . . . . 35

3.4.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.5 Project Management for Usability . . . . . . . . . . . . . . . . . . . . . . . 39

3.5.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.6 Summary Usability Engineering . . . . . . . . . . . . . . . . . . . . . . . . 43

ix

Table of Contents

4 Examination of the software development process 454.1 Examination Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.1.1 Using Empirical Research . . . . . . . . . . . . . . . . . . . . . . . 454.1.2 Choosing an Interview Form . . . . . . . . . . . . . . . . . . . . . . 464.1.3 Conducting the Interviews . . . . . . . . . . . . . . . . . . . . . . . 464.1.4 Choosing Evaluation Methods . . . . . . . . . . . . . . . . . . . . . 504.1.5 Summary of the Examination Process . . . . . . . . . . . . . . . . . 50

4.2 Status Quo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.2.1 SofTec Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.2.2 User Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.2.3 Customer Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.2.4 Relevance of PFS for Usability Integration . . . . . . . . . . . . . . 634.2.5 SofTec’s intended development process . . . . . . . . . . . . . . . . 64

5 Process Improvement for SofTec 655.1 Usability Maturity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.2 Interview Evaluation and Proposals . . . . . . . . . . . . . . . . . . . . . . 685.3 Usability Integration in the SDP . . . . . . . . . . . . . . . . . . . . . . . . 73

6 Summary and remaining ideas 756.1 Result summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756.2 Evaluation of analysis process . . . . . . . . . . . . . . . . . . . . . . . . . 776.3 Outlook and further ideas . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Appendix 801 Interview Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802 Interview Extracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853 SDP Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Bibliography 101

x

List of Figures

1.1 Communication Problems in Software Development . . . . . . . . . . . . . 2

3.1 Usability Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 The STEPS Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3 The Usability Engineering Lifecycle . . . . . . . . . . . . . . . . . . . . . . 173.4 Relations among user–centred measures in ISO 13407 . . . . . . . . . . . . 193.5 The Rational Unified Process . . . . . . . . . . . . . . . . . . . . . . . . . 203.6 Cycle in Rational Unified Process . . . . . . . . . . . . . . . . . . . . . . . 213.7 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.8 User Profile Check List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.9 Contextual Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.10 Scenario-Based Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.11 Test-Finding-Relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.12 Relevant Factors for efficient project work . . . . . . . . . . . . . . . . . . 41

xi

List of Tables

2.1 Aspects of HCI and according disciplines . . . . . . . . . . . . . . . . . . . 72.2 Excerpt from Bildschirmarbeitsverordnung . . . . . . . . . . . . . . . . . . 10

3.1 The stakeholder involvement in the Rational Unified Process . . . . . . . . 223.2 Questionnaire for Cognitive Walkthrough . . . . . . . . . . . . . . . . . . . 38

5.1 UMM Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.2 Ratings in UMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.3 UMM Level B – Evaluation for SofTec . . . . . . . . . . . . . . . . . . . . 675.4 UMM Level C – Evaluation for SofTec . . . . . . . . . . . . . . . . . . . . 685.5 Result Documents for PSF . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.6 Usability Activities in SDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

A.1 Iterations in SDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91A.2 Roles in SDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92A.3 Activities in SDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94A.4 Artifacts in SDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

xiii

1 Introduction

At first sight, the notion ”usability” immediately triggers off an association. It is theease of use of a product. Everybody might have an experience at hand where a devicewas not usable. This shows an important aspect of usability: When usability is good, itis not recognized, but if it fails, it becomes an issue. This holds for simple devices likehair driers as well as for more complex devices like video recorders and especially for verycomplex devices like computers.

Ince explains, that a ”fitness for purpose” is an important property of products([Ince 1995, p. 3]). This is easy to determine for a hair drier. It has to dry hair,using warm air. Usability is the easiness with which this task can be accomplished. Butwhat about a computer? There is no implicit purpose. It can be used for a variety oftasks. Therefore, it is not easy to determine the purpose here. Hence, to define the pur-pose of software is crucial to the evaluation of usability. Ideally, a purpose is defined anda suitable software is built. In practise, this is impossible, because the tasks supported bysoftware are difficult and often they are changed intentionally by supporting them withsoftware.

Additionally, a common problem in defining the purpose and building the suitablesoftware is that customers and developers are people with different backgrounds. Thecommunication between them is sometimes difficult due to different associations, but it isimportant for the developing of software that those who will use the software and thosewho build it have a common understanding. If this is not the case, the software will notmeet the user’s requirements (see figure 1.1, [Unknown 2003]). This may seem funny,but it is daily practise for some organizations dealing with software development.

Usability is not only related to a product, but also to the according development pro-cess. A product of good usability can only be achieved, if its development process includedusability methods. One might argue that usability is general knowledge, but the practiseshows that this is not the case. Too many products fail to provide usability. Software en-gineering provides many process models and methods to be applied in this respect. Thesemodels describe which steps should be taken to manufacture software of good quality: Us-ability is nothing that can be put on top of a product at the end of its development. On thecontrary, usability has to be considered during the whole development cycle, right fromthe beginning of the planning to the delivery of the product and even further. Usabilityof a product without usability (methods) in the development process is impossible.

A company developing software has to make sure that its developing process meetsusability requirements. Customers do not only demand software, which provides theintended functionality. Usability is a requirement as well. This is important for developersof standard software, as customers can buy the product of a competitor. But this is alsoimportant for companies developing individual software. Customers would pay for a

1 Introduction

software with poor usability though, but they will not assign a further order. Whena development team is newly formed, the development is not always structured with adefined process. The development quality is based on individuals who have the requiredknowledge and do use appropriate methods without the structuring of a formal process.

Figure 1.1: Communication Problems in Software Development

2

1.1 Project Overview

1.1 Project Overview

SofTec1 is a company that provides consultancy in the area of transportation craft main-tenance. Additionally, it offers application development in this area. Hence, the softwaredeveloped by SofTec is individual software. As this company belongs to a corporation, itsmain customers are other companies or departments in this corporation. Furthermore,SofTec’s customers include companies apart from the corporation’s companies.

The company exists for a few years now and the development team was doing its worksuccessfully in general. But in some cases, the customers were not satisfied with the resultof the development work, because the software did not meet the customers’ requirements.A first step the company took towards an improvement of this situation was to assign amaster thesis to choose an appropriate development process.

The result of this thesis was an adapted Rational Unified Process, the SofTec Develop-ment process (SDP). When I had a look at the details of this process, I recognized thatusability was not considered. Its focus was on a more general level, to develop a processmodel to enable the application development team to develop software in a structuredmanner. In a discussion with the person in charge for quality assurance, we had the ideato integrate usability in the work of the development team by extending the developmentprocess before it is installed. The manager of this development team agreed on a studyto find out about the weakest points of the current development process and to extendthe new process model to avoid these points.

To approach this goal, I planned a project2. The first step in this project was a pre-liminary literature search on usability engineering starting with literature I knew frommy studies on usability and usability engineering. As software development is affectedby quality assurance and project management, I extended my literature search on thesefields.

At second, I conducted an analysis on the current development practise to find outabout the occurrence of usability in the development practise. This analysis consisted ofinterviews with representatives of all stakeholders in the development company, includingmanagers, project managers, developers and customers. I focused on their knowledgeabout usability and how this knowledge is used during software development projects.Parallel to this, I learned about the SDP by reading internal papers and talking with thepapers’ author to find out about possible extension points in this process model.

The study resulted in a set of proposals containing methods to be integrated into theSDP. These proposals were derived from the knowledge of usability engineering as providedin chapter 3 Usability Engineering and matched to the individual levels of knowledge. Thisincluded training measures like workshops to introduce the new methods.

1Names changed by author for anonymity reason.2I use the notion project according to the definition in [DIN 69901 1987] This might seem to be not

appropriate for my work as it is no project in a conventional sense, but my work shared importantproperties with a conventional project: It had a defined start and end date, a goal and milestoneswere defined and resources had to be organized.

3

1 Introduction

1.2 Chapter Overview

Chapter two explains the meaning of usability. As SofTec produces software to be usedin professional context, this chapter describes the particular conditions for this kind ofsoftware. Additionally, the legal framework for software applied in German companies isconsidered. At last, the business value is outlined. Readers who are familiar with thedifferent aspects of usability may skip this chapter.

Chapter three outlines usability engineering. The focus is set on the integrationof the user, i.e., when, where and how the user is involved in the development process.Additionally, quality assurance and project management are examined with respectto their support for usability. This chapter provides the basic knowledge used for theproposals. Readers who are familiar with the software development for usability mayskip this chapter.

In chapter four, the analysis I conducted is described in detail. I explain how Ichose appropriate methods from empirical research for my analysis process and how theanalysis was conducted. At the end of this chapter, a description of the status quo isgiven, which is the basis for the improvement proposals in the subsequent chapter. It isnot necessary to read this chapter in order to understand the proposals, but it may helpto understand how the proposals were derived.

Chapter five provides the results of the study. It comprises a set of proposalswhich are discussed with regard to their integration in the SDP and to the necessaryprerequisites.

Chapter six gives a summary of the analysis results and the proposed solutions.Furthermore, it contains ideas which could not yet be considered, because they are notdirectly related to this investigation but are worth further consideration. This is themain chapter for the quick reader.

The Appendix contains the interview guidelines, interview extracts and the details onthe intended development process of SofTec. Additionally, a glossary and the bibliographyare included.

4

2 Usability

The objective of this thesis is to improve the usability of the software developed bySofTec. This software is individual software in a professional working environment, i.e. thesoftware is developed for a specific customer, who supports a work task of convenient size.This chapter outlines the meaning of usability with a focus on the particular importanceof individual software in work context.

2.1 Definition

A comprehensive definition of usability is difficult since different people have differentdefinitions. For example, a user may find a software usable which can be used withoutreading a manual, and a maintenance programmer finds software usable, when developingnew functions is easy. Here, I will restrict my view of usability to the perspective ofcustomers.1 To explain the notion of usability in this sense, some definitions can help2:

• Balzert: Balzert provides one definition of usability in a more general meaningand one in a more concrete meaning. In general, usability means that the end userhas access to one ore more software application systems at the workplace, whichenable the user to accomplish the work tasks in an individual and human-orientedway. Balzert’s more concrete definition points out the role of design. Usabilityemerges when dialogue structures and inputs and outputs of a software system aredesigned following usability guidelines. Additionally, to design usability includesthe knowledge on the work tasks and the organizational environment. To gain thisknowledge, one must examine the organizational structure, the work groups, thetask environment and the application system ([Balzert 1994, p. 407]).3

• Chapanis: ”The usability of a computer is measured by how easily and how af-fectively the computer can be used by a specific set of users, given a particularkind of support, to carry out a fixed set of tasks, in a defined set of environment.”([Chapanis 1991, p. 362f.])

• Hartson and Hix: ”A discipline concerned with design, implementation,and evaluation of interactive computing systems for human use” [theiremphasis]([Hartson and Hix 2000, p. 2]).

1Where it does not make any difference, I use the notion ’customer’ to refer to both the purchaser andthe user. Otherwise, the appropriate stakeholder is used.

2This enumeration is ordered alphabetically.3The application system comprises all applications the user needs for working

2 Usability

• International Organization for Standardization (ISO): Usability as a mat-ter of software quality is defined in ISO norms. The collection of ISO 9241provides guidance on many ergonomic aspects concerning office work with com-puters. This includes hardware ergonomic issues like guidelines on keyboards([ISO 9241-4 1998]) and software ergonomic issues like guidance on dialogue design([ISO 9241-10 1998]). Part 11 of this collection is concerned with software usabilityin general ([ISO 9241-11 1998]). It defines the framework for usability. Usability ishere defined as the ”extent to which a product can be used by specified users toachieve specified goals with effectiveness, efficiency and satisfaction in a specifiedcontext of use”. ([ISO 9241-11 1998, p. 4])

• Mayhew: ”Usability is a measurable characteristic of a product user interface thatis present to a greater or lesser degree. One broad dimension of usability is how easyto learn the user interface is for novice and casual users. Another is how easy to use(efficient, flexible, powerful) the user interface is for frequent and proficient users,after they have mastered the initial learning of the interface.” ([Mayhew 1999, p.1])

• Nielsen: ”Usability is a quality attribute that assesses how easy user interfaces areto use. The word ’usability’ also refers to methods for improving ease-of-use duringthe design process.” ([Nielsen 2003b]) Chapter 3 deals in detail with the processof developing for usability.

• Preece et al.: ”Human-Computer Interaction [henceforth HCI] is about designing:computer systems that support people so that they can carry out their activitiesproductively and safely.”(p. 1) ”Usability, a key concept in HCI, is concerned withmaking systems easy to learn and easy to use.” ([Preece et al. 1994, p. 14])

To summarize, usability has these different aspects:

• software integrated in its environment at a work place

• supporting humans to work in a human-oriented way

• enabling the user to accomplish a task efficiently and effectively

• users have to be specified in a given context

• design has to follow some basic rules

• software has to meet ISO requirements

• learning has to be supported

• the process is considered as well

In this thesis, usability is considered with all these aspects, but with a strong focus onthe work context. This implies that the ISO definitions are most important as they arerelevant to companies employing software (see section 2.4). The condensed definition forthe purpose of this thesis is this:

6

2.2 Interdisciplinarity

Usability describes the ease with which a person being expert in a profes-sional setting can use a software for this specific task productively. UsabilityEngineering describes methods for a software development that produces asoftware that meets the definition above.

2.2 Interdisciplinarity

All these definitions imply that usability is highly interdisciplinary. Involved aspectsenumerated by Preece et al. are shown in table 2.1 ([Preece et al. 1994, p. 31]).

Aspect DetailsOrganizational Factors training, job designEnvironmental Factors noise, heating, lighting, ventilationHealth and Safety Factors stress, headache, musculo-skeletal disordersThe User motivation, enjoyment, satisfaction, personality, experi-

enceComfort Factors seating, equipment, layoutUser Interface input devices, output displays, dialogue structures, use

of colour, icons, commands, graphics, natural language,3-D, user support material, multi-media

Task Factors easy complex, novel, task allocation, repetitive, moni-toring, skills, components

Constraints costs, timescales, budgets, staff, equipment, buildingstructure

System Functionality hardware, software, applicationProductivity Factors increase output, increase quality, decrease costs, de-

crease errors, decrease labour requirements, decreaseproduction time, increase creative and innovative ideasleading to new products

Table 2.1: Aspects of HCI and according disciplines

From that, disciplines contributing to HCI can be derived, including computerscience, cognitive psychology, organizational psychology, ergonomics and human factors,linguistics, artificial intelligence, philosophy, sociology and anthropology, and engineeringand design. Lindgaard supports this idea as she states: ”Information & Screen DesignStandards are based on principles of human information processing, psychophysics, hu-man memory, social norms and other human capabilities and limitations.” Additionally,the knowledge of different disciplines such as psychology, social science, informationdesign, computer science, work design and more are needed.

Usability takes place on different levels. ([Lindgaard 2002, p. 14]) On a verybasic level, usability deals with the direct interaction between a user and a computer.

7

2 Usability

Here, psychological knowledge is required, e.g. knowledge about perception and memoryand control of attention can help in designing screens and the screen flow, e.g. somecolours do not go well together like red and blue, or elements can be arranged on thescreen in a way that indicates whether they belong together. Another aspect to beconsidered is the intended user group. The user group must be analyzed to know aboutspecial requirements. Additionally, the work place must be examined to find out aboutspecific conditions that might influence the usage of the software, like noise. The worktask might be the most obvious item to be analyzed as it is the goal of the softwareto support this task. And finally, the organizational environment has to be considered.This includes co–operation, i.e. how the work task is embedded in the overall process.

2.3 Work Context

The relation between software and work context is important in both directions. Thework context is the basis for software design. But at the same time, software influencesthe work as well, because it changes the the way a work task is done. Most often, thisis even an intended effect as the main task is to optimize a work process, and softwareis applied to support the new process. Hence, software restrictions can limit the optionsfor process changes. From this it follows that software design is work design. Klotz out-lines that software design has important implications on job design. A software developerdetermines the allocation of functions between a human and a computer and hence influ-ences the work4. Many fields are influenced by the usage of computers. There is a widerange of design options for job design, organization of work, co–operation and relationsof communication, structures of qualification and many more ([Klotz 1991, p. 450]).Therefore the new software has to be developed very carefully and a good analysis ofthe work situation is required. For this analysis, important work aspects according to[Balzert 2000, p. 493] comprise:

• User It is important to know, whether the users are beginners or advanced users5,experienced in the product, experienced in the work task and experienced in theorganization. It has to be analyzed, which qualifications and general knowledgethey have and what other psychological and physical conditions remain.

• Work task Fragmentation, frequency and durance of the work task have to beanalyzed. Additionally, the frequency of events, the experience in organization andthe latitude to act must be considered as well as the consequences of errors andsecurity issues.

• Work equipment The work equipment will be analyzed including description,name, functions, hardware and software and materials. Additionally, available ser-vices are considered.

4Although this is done together with the customer, the leading role of this task lies with the developer.5A user group for an application often comprises beginners and advanced users.

8

2.4 Legal Framework

• Environment The environment includes the physical environment with atmo-spheric and acoustic conditions, conditions of climate, size and equipment, workplace and the like and equally important the organizational environment with modelof working time, co–operation possibilities, interrupts, structure of management,structure of communication, requirements for computer usage, organizational ob-jectives and the like.

These complex environment requires good skills of those in charge for the analysis andfor those responsible for the design of a new system that meets the analyzed requirements.Preece et al. ([Preece et al. 1994, p. 15]) state that ”[i]n order to produce computersystems with good usability, HCI specialists strive to

• understand the factors (such as psychological, ergonomic, organizational and socialfactors) that determine how people operate and make use of computer technologyeffectively, and to translate that understanding into the

• development of tools and techniques to help designers ensure that computer sys-tems are suitable for the activities for which people will use them, in order to

• achieve efficient, effective and safe interaction both in terms of individual human-computer interaction and group interactions”

2.4 Legal Framework

In Germany, usability has yet become part of the industrial safety act in an act calledBildschirmarbeitsverordnung ([BildschArbVO 1996]). This act defines minimum re-quirements for work places with a monitor6. The responsibility for the adherence of thisact is at the employer. Often, the works committee monitors the employer’s measures inorder to support the employees rights. Apart from requirements for hardware like prop-erties of a monitor and medical issues like regular examinations by ophthalmologists, theBildschirmarbeitsverordnung was extended to prescribe properties of software applied inwork context.7 These items are listed in table 2.2 on the next page.8

The Bildschirmarbeitsverordnung sets the rights for employees to work with usablesoftware. Thus, an employer has to make sure that the software used by the employeesmeets these requirements.

2.5 Business Value

The business value of usability is an important factor when talking about software in pro-fessional settings. The main reason to build or buy software is to increase the productivityby improving work processes. The relevant question is whether usability can be justified

6With some exceptions concerning transportation, machines, typewriters and others.7This is described in the section on the Relation between Human and Tools.8Translated by me.

9

2 Usability

20. The principles of usability have to be applied especially for the informationprocessing by humans.

21. When developing, choosing, purchasing and changing software, and designingthe work task on a computer, the employer has to make sure that the followingprinciples are applied, especially with respect the usability.

21.1 The software must suit the work task.

21.2 The systems must provide information on the screen flows directly or whenrequested by the user.

21.3 The systems must provide the user with the possibility to influence the screenflow. Additionally, possible errors occurring during usage must be described,and the error recovering must be possible with limited effort.

21.4 The software must be adaptable to meet the users’ knowledge and experiencewith respect to the work task.

Table 2.2: Excerpt from Bildschirmarbeitsverordnung

providing a business value. The business value can be regarded from two points of view.On the one hand, one can tell the advantages usability has concerning work effectiveness.On the other hand, one can examine the disadvantages which arise, when a software lacksusability. Arguments from both views are difficult to quantify, because the calculationdepends on the individual context.

Effects of UsabilityAccording to [Karat 1997], the advantages include these positive effects:

• improved product design

• improved user satisfaction

• reduced development length and time

• reduced trainings and help desk costs

• improved user productivity

Lindgaard states that users work more productively with usable software. She reportsthat a good task analysis is a requirement to achieve a business value ([Lindgaard 2002])and describes an example of a call centre, where a redesign of a work process supportedby software saved more than three million dollars a year – presuming a user’s salary, thenumber of users and the time the process takes before and after the redesign. However,McCoy points out that it is crucial to evaluate the software in its context: ”With nobodykeeping an eye on the whole-of-life [...] cost of an application, the real expense of poorusability remains hidden, making companies reluctant to invest in usability expertise.”([McCoy 2002, p. 287])

10

2.6 Summary

Effects of missing UsabilityThe absence of usability can cause hidden costs. Cooper explains: ”Getting paid forusing software makes users far more tolerant of its shortcomings because they have nochoice, but it doesn’t make [the lack of usability] any less expensive.” ([Cooper 1999,p. 52]) He explains further that ”the costs [of bad usability] are not monetary ones [. . . ]but are exacted in fare more expensive currencies like time [. . . ] and customer loyalty.”([Cooper 1999, p. 52]) For example Brodbeck examined how long it took users to recoverfrom errors ([Brodbeck 1991]). He discovered that 10% of the daily work time was spenton solving computer problems. One can easily imagine the costs for hundreds of users asoftware can have. Additionally, the error recovering included asking a colleague for help.The user with the problem and the colleague have to interrupt their work task and needto resume the task. These costs have to be considered as well. To ask a colleague maybe favourable, because the colleague is an expert in the work task, unlike a members of asupport desk team.

Calculating the Value of UsabilityIt is important for the management point of view is to evaluate usability in terms of money.It is difficult to quantify both the business value of usability and the costs of a lack ofusability. ‘Often those costs are buried in generalized personell or development coststhat cannot be allocated to specific projects.’ ([Chapanis 1991, p. 41]) In calculationcosts, it is useful to know that the cost impact of removing software defects is higher, thelater the defect is detected. Pressman reports that assuming an error detection costs 1monetary unit, uncovering it before testing will cost 6.5 units, during testing 15 units andafter release 67 units ([Pressman 1992]). This indicates that usability errors should bedetected as soon as possible.

Nielsen emphasizes: ”Ease of use doesn’t come from wishful thinking. It comes fromconducting systematic usability engineering activities throughout the project lifecycle.This is real work and costs real money, though not as much as some people fear.” He addsthat ”current best practises call for devoting about 10% of a projects budget to usability.”[Nielsen 2003a] A literature overview on this subject providing many examples andguidelines to estimate the costs and benefits of usability measurements can be found in[Wagner 2000]. The following chapter shows, how usability of software can be achievedduring the devlopment.

2.6 Summary

Usability here means the ease of accomplishing a task in a work environment. It is highlyinterdisciplinary, contributing disciplines include psychology, sociology, engineering anddesign. The context of a software is determined by the user, described by experiences andprepositions, the work task with its organizational details, the work equipment includ-ing hardware and software, and the environment described by physical conditions andco-operation options. For German companies, the legal framework is also relevant. It

11

2 Usability

prescribes usability for software on work context. At last, a company has to evaluate thebusiness value of productivity or using software. The next chapter provides developmentmethods and process models to build usable software.

12

3 Usability Engineering

The last chapter explained the notion ”usability” and its importance for software inprofessional context. This chapter explains, how software usability can be achievedby usability engineering. Hartson and Dix explain that the ”[s]ignificant cause ofpoor usability in product is lack of understanding of proper development process”[Hartson and Hix 2000, p. 8]. Usability engineering is software engineering with afocus on usability. It comprises a wide range of proposals to develop an individual soft-ware process for usability. These proposals are discussed in how they let users participatein the development. At first, process models are presented with respect to the role of theuser in them. As user involvement and understanding the context of use are importantfactors to produce usable software, analysis methods for these are presented. At the end,the two supporting disciplines quality assurance and project management are illuminatedin what they can do to support usability.

Figure 3.1 shows the relations between these fields as it is seen in this thesis. Usabilitycan not be put on top of a software when it is ready. i.e, when all other developmenttasks are finished. It is integrated in software development, quality assurance and projectmanagement. Without integrating usability in all parts of the development yet in earlystages, the overall usability of the software will fail. Software development is team work.Whenever people work together, communication is the basis for team work. However, asmethods for communication are closely related to project management, communicationissues are discussed there.

Figure 3.1: Usability Integration

The main approach for usability engineering is the user–centred design (UCD). Preece etal. point out that the central aspect of user–centred design is an involvement of users. To


only let them comment on provided ideas is not enough. Additionally, they enumerate themain tasks in user-centred design as there are to involve the users so that they can influencethe design, to integrate knowledge from the disciplines that contribute to HCI, and to behighly iterative to check if the design meets the users requirements ([Preece et al. 1994]).

Norman puts it simple. Usability can be achieved by following some general designprinciples ([Norman 1990, p. 52f.]):

• Visibility By looking, the user can tell the state of the device and the alternativesfor actions.

• Provide good conceptual model The designer provides a good conceptual modelfor the user, with consistency in the presentation of operations and results and acoherent, consistent system image. This model enables users to predict systembehaviour.

• Good mapping It is possible to determine the relationships between actions andresult, between the controls and their effects, and between what is visible and thesystem state.

• Feedback The user receives full and continuous feedback about the results ofactions.

Although these principles seem to be reasonable, they are not general knowledge. Thereis a wide range of methods to turn the design principles into practical guidelines. Gillanand Breedin showed in a study on differences in mental models of HCI that human fac-tors experts and developers had a much more elaborated mental model than had users([Gillan and Breedin 1990]).

To let developers follow the rule above is not sufficient. Gentner and Grudin explain,why it is not easy for engineers to produce good interfaces: ”From the engineer’s per-spective, the ideal interface reflects the underlying mechanism and affords direct accessto the control points of the mechanism. [...] and has a strong bias to towards basing theinterface on the engineering model. [...] The user, however, is primarily concerned withthe task to be accomplished, and a problem arises if the user’s model of the task does notmap cleanly onto the systems mechanism.” ([Gentner and Grudin 1990, p. 277]) Theywarn although not to be stuck to elaborate the interface based only on the task model,because the task may be influenced by former tools. At the time of development, theremay be better technologies to support the task, so the ”interface designer must find theproper balance between forcing the user to accommodate to the machine and adaptingthe machine to the user’s pre–existing model of task.”([Gentner and Grudin 1990, p.280]).

Therefore, the design process should be accomplished in a co–operation of developersand users. Stewart enumerates the tasks of the design process, where users should be in-volved ([Stewart 1991, p. 99ff.]): requirements analysis, allocation of function, interfacedevelopment, workstation design, testing and feedback, and quality control.

14

3.1 The place of Users in the development process


Usability engineering focuses on the involvement of users in the development process.This is carried out during the whole process. The following sections describe, where theusers are involved in the particular process.

3.1.1 Waterfall, V and Spiral Model

The waterfall model defines determined phases in the development: system specification,software requirements, analysis, design, coding, testing and maintenance. Each phase isclosed with a specific documentation. This model has two major disadvantages. At first,the user involvement is restricted to the definition phase. They are not involved in designand testing. Errors emerging in this phase cannot be detected –and corrected– in laterphases. At second, there are few feedback cycles. Feedback is provided only from onephase to the previous one ([Balzert 1998, p. 99f.]). The waterfall model was extendedby Boehm with quality assurance ([Balzert 1998, p. 101ff.]). He developed the V modelindicating that not only the phases have to be traversed (This is the left hand side of theletter ’V’.), but also, these phases have to be quality checked. The result of each phaseis checked against its specification (This is the right hand side of the letter ’V’.). TheV model does not contain any further elements of participation as the waterfall model.In 1986, Boehm developed the spiral model ([Balzert 1998, p. 129ff.]). This modelproposes a cyclic development. Each cycle consists of the phases ’Plan next phases’,’determine objectives, alternatives and constraints’, ’Evaluate alternatives, identify risks’and ’Develop, verify next level product’. At the end of each cycle, a part of the productis finished. Users are involved in each cycle, as they participate in the requirementsdefinition, but each cycle only contains one iteration, i.g. the outcome cannot be reviewedby the user.

3.1.2 STEPS

The STEPS model, developed by Floyd, overcomes the lack of user feedback in the spiralmodel. It focuses explicitly on the users as participating in the development process andincludes their work environment, social processes, and communication needs. To developsoftware for work is a task of work design. Additionally, the computer may be a newmeans of work, so users have to develop skills in using it. A basic technique to involveusers in the development is prototyping (see section 3.3.2). STEPS has one major im-provements. Here, the development takes again place in iterations and each iteration isfinished with a most usable system version. But unlike the spiral model, this systemversion is used and evaluated in work context. So, users are not only involve in require-ments specification but also in system design and evaluation. User feedback enters thenext iteration to detail requirements or system design. STEPS focuses on communicationwith users as software development is understood as a design task involving developersand users ([Floyd et al. 1989]). Figure 3.2 on the next page provides an overview of

15


Figure 3.2: The STEPS Model

STEPS. It shows the cyclic development and shows to what extend users participate inwhich step.

3.1.3 The Usability Engineering Lifecycle

”Usability Engineering is a discipline that provides structured methods for achieving us-ability in user interface design during product development.” ([Mayhew 1999, p. 2])Mayhew provides a comprehensive process model for this: the usability engineering life-cycle.

16


Figure 3.3: The Usability Engineering Lifecycle

She defines three major phases during software development (see figure 3.3([Mayhew 1999, leading blurb]):

• requirements analysis The requirements analysis includes the analysis of theuser and of the task. Additionally, general constraints and design principles are

17


determined. The result of the requirements analysis is a list of usability goals,which is transformed into a style guide for the the transition to the next phase.

• design/test/development This second phase consists of three levels, each ofwhich can be iterated several times. When a satisfying result is achieved, the processmoves on the next level or phase.

– Level one tends to eliminate major flaws in the design. This is accomplishedwith the work reengineering, conceptual models, mock ups and evaluation

– Level two elaborates the screen design and evaluates, if usability goals aremet by using iterative prototypes and evaluation.

– Level three details the user interface. When usability goals are met, thefunctionality is checked.

• installation/user feedback In case of completeness, the software is installed.When user feedback does not reveal further issues, the development process is com-pleted.

To summarize, the user involvement in the usability engineering lifecycle is an ongoingprocess from the beginning, e.g. in the task analysis, to the very end, when the system isalready used in the intended environment and users provide feedback on the usage.

3.1.4 EN ISO 13407

ISO 13407 is a norm that defines human–centred design ([DIN prEN ISO 13407 1997]).It does not define a concrete process, but it explains, which tasks have to be accomplishedfor a usability process. The norm is divided into separate sections on basic principles ofhuman–oriented design, as there are the planning of a user–centred design process, anduser–centred design measures.

The basic principles comprise the active participation of users in the development pro-cess and a clear understanding of requirements, a suitable allocation of functions betweenthe user and the computer, iterative development and multidisciplinary design.

The principles for planning consist of using user–centred design measures, integratingthese measures into the overall development process, determine persons in charge forusability, installing effective processes to ensure communication and feedback, definingsuitable milestones for the user–centred measures and ensuring feedback for work designwith a suitable schedule.

The user–centred design measures comprise the understanding of the context of use,determining the requirements on user and organization, sketching design solutions, andevaluating the solutions. Figure 3.4 on the next page ([DIN prEN ISO 13407 1997, p.8]1) shows, how the single measures are related to one another. After the necessity ofuser–centred design was stated, these measures run in a cycle until the evaluation provesthat the system meets the requirements.

1Translated by me

18


Figure 3.4: Relations among user–centred measures in ISO 13407

19


Figure 3.5: The Rational Unified Process

3.1.5 Rational Unified Process

The Rational Unified Process (RUP) is the state–of–the–art process model. This processmodel is particularly important here as SofTec intends to employ a RUP based processmodel in the near future. My proposals for integrating usability into the developmentprocess will hence be oriented towards this model. Details on the intended process modelfor SofTec are described in the status quo in section 4.2.

The RUP is based on six best practises of software development, which are explainedby Booch in [Kruchten 2004, p. 3ff.]:

1. Develop software iteratively. The RUP is a cyclic model. Each cycle consists ofseveral steps. When a cycle proved to be successful, an executable version of thesoftware is released.

2. Manage requirements. Identifying requirements is an important factor to success-ful development. Hence, it is a continuous process during the whole developmentprocess.

3. Use component–based architectures. A component–based architecture allows there–use of software. This includes software developed by the organization itself butalso components that are commercially available.

4. Visually model software. Modelling the software allows stakeholders to communi-cate on the software based on visualized models and to develop a common under-standing.

20


5. Continuously verify software quality. Continuous quality control avoids finding aproblem late in the development, which would lead to much higher costs of fixingthe defect (see Pressman section in 2.5 Business Value).

6. Control changes to software. An organized process to control changes and releasesis important, as the development of software–intensive systems consists of a complexenvironment of developers in different teams and different places, releases, platformsand more.

The RUP is a process framework for defining software development processes. It pro-vides means to build a development process which meets an organization’s requirements.It does not prescribe concrete measures but important tasks (called disciplines) and pro-vides elements to build a concrete development process. Foote compares the RUP to arestaurant buffet ([Foote 2003]). For example, a buffet provides many different sorts offood, but not all the food must be chosen for a meal. The RUP provides a collection oftasks, but not all of them are appropriate in every situation. Or, a meal has differentphases. Although one does not need to follow these phases, there are good reasons to doso. In the same way, one is not forced to follow the phases of the RUP, but they providea reasonable sequence.

Figure 3.6: Cycle in Rational Unified Process

The basic components of the RUP are shown in figure 3.5 on the facing page. The fourphases show the progress of the overall development process, each of which focuses ona different aspect of development. A phase consists of several iterations. Each iteration

21


is a cycle of different disciplines (see figure 3.6 on the page before). The disciplines arecategorized into engineering disciplines (Business Modelling, Requirements, Analysis &Design, Implementation, Test and Deployment) and supporting disciplines (Configuration& Change Management, Project Management and Environment). At the end of eachphase or iteration, a milestone is defined. Only if its criteria are met, the next phaseor iteration can start. For example, at the end of the inception phase, an agreement onthe project scope and the acceptance criteria has to be established. For each iteration,the disciplines are substantiated as workflows with details in terms of roles, activitiesand artifacts depending on the current phase and iteration. The role describes the personperforming this workflow, the activity describes what the person has to do, and the artifactis the outcome of this workflow. For example, a workflow in the business modellingdiscipline in the inception phase may prescribe that the system analyst (role) has toproduce an organization model (artifact) by establishing a vision of the new business andcapturing business goals (activity). Or, in the elaboration phase, a requirements specifier(role) has to detail the software requirements (activity) producing use cases (artifact).

Important for this thesis is the role of the user in the RUP. The role of the users is notexplicitly defined in the RUP, but it is affected in different disciplines. The only role thatis explicitly related to the user is the role ’stakeholder’. This is a general term, which doesnot differentiate the different stakeholders like the purchaser or the end user. Nonetheless,stakeholders appear in different disciplines. An overview of the user involvement is shownin table 3.1.

Discipline Stakeholder InvolvementBusiness Modelling A goal of this discipline is to understand the organization

with its current problems and to define the requirements forthe organization.

Requirements This discipline aims to establish and maintain agreement withthe customer and to provide the developer with a better un-derstanding of the system.

Implementation Prototypes are used in this discipline to detail requirementsand to determine the usability.

Test Concrete demonstration is used to evaluate assumptions madein design and requirements specification. As a system versionis released with every milestone, tests are conducted againand again during the development.

Table 3.1: The stakeholder involvement in the Rational Unified Process

22

3.2 Understanding the Context of Use


After considering the place of the user in the development process, the focus is nowset to the context of use. At first, the requirements engineering is outlined in general.Afterwards, two best practises are described, which point out the requirements analysis.These are the contextual design and the scenario–based design.

3.2.1 Requirements Engineering

Requirements engineering is the process of learning about the user’s needs for the newsystem and writing them down in a requirements specification. It ”is a means of commu-nication between analysts, designers, users, customers, testers, management, and whoeverhas a stake in the system.[. . . ] It describes exactly what the software will do, but not theprocesses by which it will operate.” ([Lindgaard 1994, p.43]).

The requirements specification serves as a basis for the project contract. At the endof a project, the requirements specification is used by the customer to determine, if thesoftware will be accepted.

The task of specifying customer expectations is a very tricky business. ”People are notvery good at telling analysts what they want, and analysts are not always very good atlistening. Yet, requirements capture is probably the most important activity of systemdesign, because it guides the further system development.” (([Lindgaard 1994, p. 38]))Supporting this, Ince points out the importance of early specification:

”Errors in the requirements specification that remain undiscovered until latein a software project, say during system testing, have been a major cause ofproject overruns, and have even led to the cancellation of major projects”([Ince 1995, p. 28])

Anyhow, the requirements engineering takes place during the whole development pro-cess. It starts in the beginning with a task and user analysis to define the general frame-work for the development. But the requirements will change during the project. A singleanalysis in the beginning is not sufficient for several reasons:

• Users are not always familiar with the possibilities offered by technology. ”Currentusers are not dedicated to technology, their background is more tied to workflow”([Shneiderman 1998, p. 97]). On the other side, as long as the workflow is notwell understood by the developers, they cannot build a system that meets the users’wishes in an appropriate way. Hunt and Thomas point out that it ”is importantto discover the underlying reason why users do a particular thing. [...] Docu-menting the reasons behind requirements will give your team invaluable informa-tion when making daily implementation decisions.” ([Hunt and Thomas 2000, p.203]). They provide a tip to detect requirements: Become a user. This idea is a ba-sic idea in the contextual design by Beyer and Holtzblatt, described in section 3.2.2.This examination has to be executed very carefully, because ”‘what users tell [. . . ]may not be consistent with what they want, need and expect [Lindgaard 1994, p.42].

23


Figure 3.7: Use Case Diagram

• The requirements are written down in natural language. These descriptions aremost often ambiguous and therefore have to be partly revised as all stakeholdersget a more detailed understanding of the work processes as the project goes on.Hunt and Thomas ([Hunt and Thomas 2000]) propose use cases as a possibilityto define requirements. Although they are formal, they are easy to understand bycustomers not familiar with them. They should not become too complex, though.A simple example is shown in figure 3.7.

• Requirements change during the development due to changes in the context, inwhich the software will be used. This may arise, for example, due to changes intax law. Hunt and Thomas propose: ”Don’t gather requirements, dig for them.”([Hunt and Thomas 2000, p. 202]). This expresses the difficulties in specifyingthem. Hunt and Thomas point out that requirements will certainly change and thattherefore the specification should provide a certain level of abstraction, for example,it may not be sufficient to define that a definite user group has access to definitefunctions. Maybe the allowed users or functions will change later, so it may be betterto define an access control module, which can be modified later. Another reason forthe abstraction is that one should leave the programmers with some implementationfreedom, so that they can find different ways of coding, one of which may be easierthan the one intended. As the change of requirements is common during projects, a”[...] serious software developer will plan for this [...] because requirement analysisis such a difficult task, evolution is the only way to deal with the development ofthe requirements specification” ([Ince 1995, p. 73]).

• Detailed usability requirements normally do not come from users, and general state-ments have to be refined. An iterative development process can make sure thatusability issues are considered.

Lindgaard points out that the requirements specification is the basis for usability testsand must be quantifiable, for example ”At least 95% of test users must be able to workthrough the task in five minutes, committing one error at maximum. If an error iscommitted, [the user] must be able to recover in a single attempt.”([Lindgaard 2002,p. 14]). To avoid ambiguity, Ince proposes to avoid general statements like ’the system

24


Figure 3.8: User Profile Check List

must be user-friendly’. A better statement would be ’The system needs a user’s manual’.The question ’How can this be tested?’ can lead to more detailed requirement statements([Ince 1995]).

Lindgaard proposes to include a user profile to extend the requirements specification toclarify the characteristics of the users ([Lindgaard 1994]). This profile can be built up byusing a checklist. An example of such a list can be seen in figure 3.8 ([Lindgaard 1994]).A concrete situation may require other categories of questions. [Dunn 1993] supports theidea that a detailed specification serves as a means to determine requirements.

Furthermore, Lindgaard provides practical hints for the successful accomplishment ofthe task analysis ([Lindgaard 1994]):

• Establish the purpose of the task analysis.

• Identify range of tasks to be analyzed.

• Identify task performers.

• Identify rationale is a criteria for successful completion.

• Identify incomes and outcomes.

• Define, who needs the output.

• Identify person’s goals, subgoals and subtasks, ordering of subtasks.

25


• Identify all related objects and actions.

The remaining section provides guidance on how to find and define system require-ments. Well known methods focusing on requirements analysis are contextual design andscenario–based design.

3.2.2 Contextual Design

Contextual Design by [Beyer and Holtzblatt 1998] provides a process model for soft-ware development from a very user–centric point of view. This comprises an analysis ofthe work environment, a creation of work models, a system design, prototyping and sys-tem implementation. Contextual Design comprises all steps from requirements analysisto software deployment. The main tasks are listed in figure 3.9 ([Incent 2003]):

Figure 3.9: Contextual Design

• Talk to customers To analyze requirements, it is useful to watch the future userswhile they are working. The method used for this is the so–called contextual inter-view, i.e. the user is interviewed in the work context. Beyer and Holtzblatt proposeto approach the users in the model of master–and–apprentice. The interviewer willbehave like an apprentice and watch the ’master’ to understand the work task indetail. During this observation, first design ideas may be discussed to check howthey fit into the work process. However, a focus is set on those parts of the work,that will be supported by the future system.

26


• Interpret data The analysis of the interviews results in models that describe dif-ferent aspects of the work: a flow model to describe the communication flow, asequence model for sequences in the work task, an artifact model to indicate whichartifacts are involved in which tasks and which persons use them, a cultural modelto recognize the influence of culture on the work task and a physical model for thephysical environment. This analysis is conducted by a cross–functional team thatconsists of different stakeholders. These are usually not only users and developersbut also designers, members of the marketing team and psychologists. The ad-vantage of this mixed team lies in the different views of the different stakeholders.Group interpretations lead to a shared view to identify hidden structures and toreveal informal knowledge.

• Consolidate data The next step is a consolidation of the data found in that thework practise is described with agreed statements. This results in common workpatterns that abstract from individual work practises. The task is to ”[r]eveal thecustomers’ story by seeing behind the pattern.” [Beyer and Holtzblatt 1998, p.151].

• Invent solutions After the analysis process is finished, a new solution has to becreated. ”The real invention of a design team is a new way for people to work.” (p.215) Helpful in this task is the diversity of the design team members, each of whichholds an own perspective. This will ensure creativity throughout the design. Thework redesign comprises distinct steps from brainstorming and considering radicaldesign solutions to check the technical feasibility and the impact it has on the workprocess. The solution is worked out in storyboards, that ”show how a specific taskwill be accomplished in the new world.” ([Beyer and Holtzblatt 1998, p. 287])

• Structure the system Once, the solution is invented, it has to support the newwork practise. The transition from the vision to the system design follows. Themain task is to keep the system coherent, ”a coherent system keeps the user’s workorderly and natural.” (p. 295). The first task is to structure the system. Thisincludes the decision on what the system should do in what parts. The next step isto work out in detail the user interface. Beyer and Holzblatt compare this task tothe design of a house. At first, the floor plan is sketched. Afterwards, the decorationof the house can follow.

• Iteration with the customer Beyer and Holtzblatt propose a paper prototype,because it has two major advantages. It will give the users a real experience of thesystem. This is the better, if real data are used in the prototype. The fact thatthe prototype is made of paper invites the the users to propose changes, because”there’s a whole layer of detailed requirements that users simply can’t communicateexcept when they’re working with an actual design.” (p. 373) Prototypes are auseful means to build trust with customers. Users, who are involved in the designwill accept the system later.

27


• Design the object model The result of the prototyping is the basis for the im-plementation work. The software architecture is defined, and walkthroughs ensurethe support of the work structure.

The software development itself is not part of the contextual design method.

3.2.3 Scenario-based Design

While the contextual design focuses on an analysis using the approach of the master–apprentice–relation, the scenario–based design is based on scenarios. A scenario is asmall story that describes the interaction of a user with the system on a defined level ofabstraction. Like scenes for theatre plays, scenarios contain a set of scenario elements([Rosson and Carroll 2002, p. 18]):

• Setting The setting describes the current situation, in which a scenario starts ortakes place, e.g. an office within an accounting organization.

• Actors An actor is a person interacting with the system. This person is describedin terms of experience, e.g. ”accountant using a software for the first time”.

• Task goals A task goal is a reason for an actor to interact with the system, e.g.the accountant intending to compare sales data.

• Plans A plan describes the mental activity to convert a goal into behaviour on alow level, e.g. resizing a window to make room for another one.

• Evaluation An evaluation is the mental activity to interpret a situation, e.g. darkborders indicate that a window is active.

• Actions An action is an observable behaviour, e.g. a window is moved to the sideand reveals an underlying window.

• Events An event is an external action produced by the computer –maybe hidden ornot– that is important to the scenario, e.g. the saving of a file automatically everyfive minutes.

Figure 3.10 on the next page shows an overview of the scenario–based design([Rosson and Carroll 2002, p. 25]).

The requirements analysis starts with a field observation. As a result, a first scenario–the problem scenario– is created including propositions to support or improve the worktask with technology. The level of abstraction in a scenario changes during the develop-ment from very abstract to very detailed. A scenario in the beginning of the developmentexplains the general functionality of a system. In a late scenario, the interaction is de-scribed very detailed. Additionally, the single scenarios focus on different aspects: theproblem, the activity, the information, the interaction, and the usability issues. Scenariosare discussed with the users to be verified.

28

3.3 The Role of Participation and Prototyping

Figure 3.10: Scenario-Based Design

The scenario-based design provides two important advantages. At first, it provides thepossibility to examine design alternatives and to find out about their trade offs. Secondly,it provides rationales behind design decisions. Thus, design decisions in a later stage canbe based on earlier decisions providing the reasoning behind it. Stewart outlines that itis important to note design rationales ([Stewart 1991]). In later project stages or laterprojects no one will yet know, why a specific design decision was made. This implies thedanger that future decisions will be made by default without considering former reasoning.Scenarios should not be confounded with use cases. While use cases aim to describe thefunctionalities of a system with every alternative and error handling, scenarios are focusedon the interaction of the user with a system and the side–effects it can have on the overallwork task. Rosson and Carroll propose an integration of these two methods: Use casescan be used for a complete functional specification, whereas the scenarios can be used toconsider usability implications of intended implementations.


The role of the user and the meaning of analyzing the context of use have yet beenoutlined. This section describes the close relation between participation and prototyping.

29


3.3.1 Participation

One of the key principles in user–centred design is the participation of stakeholders inall phases of the software development. It comprises iterative techniques that allow thedevelopment team to receive ongoing qualified feedback from the prospective users. Taskanalysis, for example, is a form of participation that might be obviously necessary. Butto achieve a usable product, ongoing participation has to take place.

Spinas and Weber conducted a study to analyze the opinion of users, de-velopers and managers about user participation in the development process([Spinas and Waeber 1991]). The found that more than 70 per cent of the subjectsagreed on the thesis that users should participate in the development process. Addi-tionally, all stakeholders preferred a stepwise cyclic process model (users 73%, developers63%, managers 60%).

Ortlieb and Holz auf der Heide report from the project PROTOS([Ortlieb and Holz auf der Heide 1993]). To describe the different forms ofparticipation, they use these questions:

• Who participates?This may be the users themselves or representatives. A representative may be oneor more persons of the users or as well a superior, of which alternatives the lattermay cause problems in the grade of necessary knowledge or acceptance.

• How are they participated?There are three forms of examined participation as there are the passive partici-pation, active decision and active participation. Passive involvement includes aninterview with the users at the beginning of the software development. Activecollaboration gives the users the possibility to decide basic design questions in co–operation with the design team. Active participation lets the users take part in thedesign process during the whole process.

• When does it take place?The authors put out that the point of time of the participation is a critical factorfor the successful work. It depends on the development process.

• In what do the users participate?It has to be clarified, which decisions should be shared with the users and to whichextend. An extended participation would include not only the development of asoftware system but also a new design of organizational and work related questions.

Ortlieb and Holz auf der Heide report how users were involved in the software develop-ment process ([Ortlieb and Holz auf der Heide 1993]):

• Users are Stakeholders in System Design The authors used prototyping in PROTOS.At first, they tried out what they call active participation, which means that usersare encouraged to participate in an active way, i.e. to express their own ideas freely,not just to respond to ideas presented by the designers. The design team consisted ofone computer scientists, one psychologist and two users. The knowledge of the latter

30


served as a basis for decisions. The design process begins with the task analysis ofwhich parts of the work should be supported by the computer. Afterwards thesystem functions were specified according to results of the previous step. Thesefunctions were tested with a walk through in a third step. Step two and threewere repeated until a satisfying status was achieved2. The prototype was designed,implemented and afterwards evaluated by the users. If necessary, the prototype wasredesigned to the users satisfaction. When this process was finished, the system wasfully implemented. Later, the system was evaluated before it was to be deployed.

• Users are Stakeholders in Prototype Evaluation The test persons were potentialusers. The authors found users from other companies via advertisements in news-papers. These subjects had similar work tasks and had little computer skills. Thetask was to fulfil typical work tasks. The subjects were monitored by videos andlog files. They were asked to express their criticism of the system. To improve theprototype, the authors collected data on errors and time of completing the tasks toimprove the prototype. The results were categorized according to system functionsand rated as ”must”, ”should” or ”can” changes.

• Users are Stakeholders in System Evaluation The objective to evaluate the systemwas to check the usability for real users. Additionally to the evaluation of theprototype, the users were questioned with half structured interviews. The authorsreport that their interviews were successful in receiving information on systemacceptance.

The conclusion of Ortlieb and Holz auf der Heide was that to involve theusers in early phases of the development process is critical to successful systemdevelopment as they provide the developers with important knowledge of the workcontext. It is very important to decide which functions should be supported bythe software in these early phases, because late changes are only possible underhigh costs. Another argument for evaluating the system once again is that therequirements may have changed during development. This may lead to the needfor system changes. The test persons from other companies served to get a moreobjective view on the system, other than the users who were used to the softwareafter a certain time.

Another experience report of successful participation is provided by [Beck 1993]. Shegives an impression of the opinion of participation from the views of both developers andusers. She also provides advice to which prerequisites should exist to assure a successfulparticipation. After she collected data from nine projects from different companies, shefound two major difficulties in participation. One is the absence of support by the man-agement and the other is the uncertainty of developers to adequately involve users in theirproject. In detail, she identified six insufficiencies in the organization of participation:

• Form of participation The participation was passive in all projects.

2Unfortunately, the authors do not provide information on how the user’s satisfaction was measured.

31


• Project contract Neither of the projects made a contract to regulate the respon-sibilities of all stakeholders. All took the system specification for project contract.

• Regulation of time In neither project was defined when and to what extend userswere to be involved in the development. That caused several users to make a lot ofovertime.

• Competences and coordination Users seldom had the right to decide on changerequests and even if they had it, they were seldom given clear statements on theirrights and responsibilities.

• Co–operation and communication between the users Users seldom informtheir colleagues about project advances. As a result, those peers were no longerinterested in the project. This led to a worse acceptance of the application.

• Conflicts All stakeholders agreed that the main problem in the co–operation wasnot the development process itself but the social context, which consisted of conflicts,claims to power, differences in motivations and interests.

All stakeholders were familiar with the term prototyping, but they did not have the sameidea of it. Prototypes were often rated after their user interface. Often participants didnot regard the functions behind it, so that it is not always detected, whether functions metthe requirements. Often a prototype was build before the requirements were analyzed.After her analysis, Beck derives some requirements for co–operative system design:

• Requirements for the management and heads of departments A passive participationis not sufficient. Rather should users take a more active and responsible role in thedesign process. Therefore, the management should ensure that

– Users are motivated by providing them with incentives.

– Co-workers should have the right to decide on who should participate.

– The participants should be officially exempted for the time they participate.

– Users should be given qualifying measures in usability and industrial science.

– Duties and responsibilities should be fixed.

– The position of the users should be strengthened against their colleagues andthe developers.

– Organizational measures should be taken to ensure co–operation between theparticipants.

– The information policy on strategic goals, new hardware and software shouldbe widely known.

– The policy on decision should be co–operative and democratic.

• Requirements for software developers Software developers should enlarge their un-derstanding of the process of user participation. This includes an active informationpolicy on time lines and projects objectives. A project contract should be provided,which contains:

32


– Composition of the project team (stakeholders, integration of works committee,etc.)

– Allocation of tasks and responsibilities

– Use of methods, tools and process models

Possible qualifying measures for developers include:

– Prototyping as means of participation

– Knowledge on work domain

– Knowledge on usability and industrial science

– Knowledge on group processes

3.3.2 Prototyping

Participation consists of several elements one of which is prototyping. Prototyping is ameans to determine requirements ([Dunn 1993]). ”Prototyping is an effective process forcarrying out requirements analysis. Requirements specification are becoming so complexand large that both the customer and the developer have major difficulties understand-ing them.” ([Ince 1995, p. 35]) Engelbert and Seffah state that ”prototypes are ableto capture almost all of the usability issues that could be communicated in a fully de-veloped system” ([Engelberg and Seffah 2002, p. 207]). Formal methods to capturerequirements are not sufficient. People unfamiliar with this method do not understandthem in the way they were intended. A good solution to this is prototyping — and itis easy to learn by developers. A prototype serves to provide users with a concrete ideaof the software. [Hunt and Thomas 2000]) Prototyping is used throughout the wholedevelopment process.

A prototype is a model of the software. Like in industrial engineering, prototypes areused to evaluate a specific aspect. In this case, prototypes serve to evaluate usabilityissues. There are different kinds of prototypes. They can be distinguished being:

• explorative or evaluative An exploring prototype is used, when the problemfocus is not yet clear. The (most common) evaluative prototype is used to evaluatespecific aspects of the software.

• throw–away/rapid or evolutionary The former one is built only to show designideas. It will not be used as a technical basis for the development. Therefore, it isthrown away after usage. The latter one is used for further development. Preeceet al. explain that a rapid prototype is useful for small projects. In larger projects,an evolutionary prototype can be used to collect requirements. They additionallypoint out that the development of a prototype has to be planned in terms of timeand budget.

• horizontal or vertical The horizontal prototype provides a wide range of functionswithout the possibility to carry them out in detail. The vertical prototype takes

33


few functions and implements them in detail. Of course, to gain adequate feedback,both types can be used in a project.

• paper and pen based or electronic The prototype can be built either withpaper and pencil or with the help of a computer. To use paper and pencil is aninexpensive way of prototyping. There are reasons for a pen and paper based pro-totype to be more applicable than an electronic one. Lindgaard, proposes pen andpaper simulations, as they ”can save a great deal of time, effort, and money byenabling different ideas to be shown and user tested before a particular approachis settled upon” ([Lindgaard 1994, p.93]). An electronic prototype can be usedafterwards, but the pen and paper version should come first as it is ’very valuable atthis point’([Lindgaard 2002, p.16]), meaning before the electronic version. How-ever, she explains that te pen and paper kind of simulation can only be successfulunder certain conditions. It is crucial for the success to conduct the pen and papertest under the same conditions and with the same system functions as the systemwill have. A good example for situations that suit a pen and paper test is a testthat aims to determine the order of information input. The electronic prototypeis programmed in some way, this can be done with the programming language thelater system will have or using prototyping tools. It provides the possibility to gainan impression of the intended usage by enabling the user to test it on a computer. Itcan be implemented as horizontal or vertical prototype and uses most often simpletechniques like static HTML pages. There is no real functionality implemented, forexample, to simulate a database query, a form with the required fields is provided,and when it is sent, a result is shown. However, this result does not derive from areal database search but is just another simple HTML page with a result table.Thisis not to be confused with a tracer bullet, which is a real implementation that showsthat a certain architecture works. Nielsen examined a paper and a computer versionof mockups to find differences. ”Both can be used for heuristic evaluation [...].” Hesuggests to use a mixture of both types as they differ in respect to the focus. Com-puter mockups find major usability problems, paper mockups show inconsistenciesin design. ([Nielsen 1990, p. 320]). Most difficulties can be found with both sys-tems. The computer version is slightly better in finding major problems, the paperversion is better in finding inconsistencies, because of the possibility to look at somescreens at the same time.

• functional or non functional A functional prototype provides the option to tryout the system. However, for some purposes, a non functional prototype can besufficient, for example, if screen layouts or information visualizations have to beevaluated.

Of course, combinations of these categories are possible. e.g. a horizontal prototypecan be thrown away and a vertical one can be paper and pen based. The prototype isshown to one or more users. The users evaluate whether the prototype is suitable fortheir work task. Their feedback influences the further development of the software.

34

3.4 Quality Assurance for Usability


Up to now, I outlined methods to build usability. It is as important though to ensurethat the results of these methods reach a satisfying level of quality, as ”[f]ailure to meetusability criteria is just as big a bug as dividing by zero.” ([Hunt and Thomas 2000,p. 241]) Hence, quality assurance for usability is as important as for other softwarequality factors. Wong and Jeffrey showed that the importance of usability as a qualityfactor is accepted by both the developers and the users. They analyzed 403 users anddevelopers in 22 Australian companies to learn about the factors, which lead to theirunderstanding of software quality ([Wong and Jeffery 2002]). Although they showa difference in the importance of the factors, which are related to software quality, thefactor usability is valuated at almost the same rate both from the group of users (0,21)and the from group of the developers (0,22). In the following, the notion ’quality’ isoutlined according to different views. Afterwards, the relation to usability is determined.

Balzert shows different points of view of quality ([Balzert 1998]). Quality canbe related to the:

• Product Quality is a measurable and defined variable that describes a product. Itcan be used to compare different products, and it is independent from customers.

• User Quality is defined by the user. Different user have different ideas, so theproduct, which fits the user’s wishes best, is regarded as best quality. Users oftendo not have concrete ideas, so it is difficult for manufacturers to detect the usersneeds.

• Process Quality emerges, when the right process is used to develop a product.The development is specified and controlled to avoid costs for follow up treatmentand to adapt the user’s requirements.

• Cost-Benefit-Ratio Quality is a relation between costs and benefits. A productof good quality provides a specific benefit with an acceptable price.

The aspect ”process” is further discussed as this thesis aims to improve the process ofSofTec.

3.4.1 Usability Testing and Inspection Methods

Usability testing can be divided into two major groups, testing with users and testingwithout users. In this section, the focus is set to the usability testing without users.These methods are called inspection methods. They are not carried out by users butby experts with usability knowledge. An advantage of these methods is that the effortneeded to conduct them is less than for usability testing with users. Suggestions byNielsen and Mack include ([Nielsen and Mack 1994]):

35


Heuristic EvaluationA heuristic evaluation is conducted by a usability expert. The expert tests a user interfaceaccording to general psychological knowledge and user interface guidelines. Nielsen andMolich ([Nielsen and Molich 1990, p. 249]) propose a heuristic evaluation, whichthey define as ”an informal method of usability analysis where a number of evaluatorsare presented with an interface design and asked to comment on it.” They found in astudy that not more than five evaluators are needed to detect between 55 and 90 percentof the usability problems. More evaluators investigating an interface will not result inproportional more error detections, see results figure 3.11.

Figure 3.11: Test-Finding-Relation

This finding was later approved and resulted in a mathematical model([Nielsen and Landauer 1993]). Nielsen and Molich propose that evaluators should usethese principles as guideline to their work (Explanations provided by [Dix et al. 1998]:

• Simple and natural dialogue- no irrelevant information- natural order of tasks

• Speak the user’s language- use concepts from the user’s world, no system specific terms

• Minimize user memory load- leave information as long as it is needed

• Be consistent

• Provide feedback

• Provide clearly marked exits- i.e. if the user is in a part of the system he or she is not interested in, it shoud beeasy to find a way back

• Provide short cuts- to help experienced users to avoid dialogues

36


• Good error messages- show the cause of the problem and provide aid to solve the problem

• Prevent errors- whenever an error message occurs, could it be prevented?

Cognitive Walk-ThroughThe cognitive walkthrough is a means of heuristic evaluation. The user is simulated by theevaluator, who accomplishes the task as if being the user. The evaluator ”walks through”the interface. Lewis et al. describe how theory may be used to guide a design review using astructured cognitive walkthrough ([Lewis et al. 1990]). They built a list of questions withthe focus on the interaction of an interface. Possible answers estimate, how many userswill have problems with the software. Responses are rated on a scale from ’none’ to ’most’of the users will have usability problems. These questions are based on theory of problem-solving. The questionnaire is shown in table 3.2. To use this questionnaire, a series of taskshas to be specified at first. Then, a sequence of user actions for successful task completionmust be defined. Lewis et al. found in an experiment that the more familiar an evaluatorwas with this evaluation the more usability problems were found ([Lewis et al. 1990]).The results of this experiment were compared to empirical results according to the sameinterface. In terms of resources, they found that a walkthrough performed with one taskand one interface will elicit almost 50 percent of the usability errors. But they foundas well that those evaluators who where familiar with the underlying theory found moreproblems that those not familiar with it. So it seems necessary that evaluators needtraining in both theory and practise in conducting cognitive walkthroughs.

”The concept usability implies activity that has to be evaluated by actual behaviour.”([Chapanis 1991, p. 368], emphasis by Chapanis) Chapanis emphasizes that guidelinesare no substitute for evaluations. Although they are helpful, they are mostly too generalto be successful in any concrete design situation. He provides the example of a guidelineproposing to use the user’s language. In that case, one cannot be sure to have used theright notions unless an evaluation confirmed this.

There are many process improvement models like SPICE (Software Process Improve-ment and Capability Determination) or CMMI (Capability Maturity Model Integration).SPICE and CMMI are frameworks to evaluate on the one hand the quality of software de-velopment processes, and on the hand other to provide improvement proposals. However,they do not include usability improvement, and are therefore not considered here. Betterin this respect is the UMM (Usability Maturity Model). It focuses just on the integrationof usability. A more detailed view on this model is given in section 5.1 Usability Maturity.

3.4.2 Summary

Quality can be defined from different points of view: product, user, process and cost–benefit–ratio. The most important aspect here is the process. To improve the process withevaluation, inspection methods conducted by usability experts are proposed. Inspection

37


1. Description of user’s immediate goal:

2. (First/Next) atomic action a user should take:

a) Obvious that action is available? Why/why not?

b) Obvious that action is appropriate to goal? Why/why not?

3. How will the user access description of action?

• Problem accessing? Why/why not?

4. How will the user associate description with action?

• Problem associating? Why/why not?

5. All other available actions less appropriate? For each: Why/why not?

6. How will the user execute the action?

• Problems? Why/why not?

7. If timeouts, time for user to decide before timeout? Why/why not?

8. Execute the action. Describe system response:

• Obvious progress has been made towards a

9. User can access needed information in system response? Why/why not?

10. Describe appropriate modified goal, if any:

• Obvious that goal should change? Why/why not?

• If task completed, is it obvious? ? Why/why not?

Table 3.2: Questionnaire for Cognitive Walkthrough

methods include heuristic evaluation. Few experts are needed to produce valuable resultswith a small effort.

38

3.5 Project Management for Usability


The previous sections showed that the improvement of usability takes place in all phasesof the development and throughout the software’s life cycle. As any other quality factor,usability can not be achieved without effort. It requires the planning of resources in termsof time, staff and budget. Therefore, it is important to consider usability in the projectmanagement.

This section explains, where usability has to be integrated in project managementtasks. According to Field and Keller ([Field and Keller 1998]), a project is a uniqueundertaking with specific objectives that requires resources, has budgets and schedules,requires the effort of people, and quality measures. The project management consists ofmeasures to reach the specific project goal within the given resources. In the followinglist, the main tasks, according to [Field and Keller 1998, p. 3] are listed and shortlyoutlined. Each item is commented on how it is related to usability.

• project initiation In the initiation, the idea evolves. Sometimes, a feasibility studyis conducted to make sure that an idea can turn into a product. In some environ-ments, a public invitation to tender is used to receive offers from different potentialcontractors.3 It depends on the common process of the customer, if usability is yetconsidered here. If the customer has developed a detailed specification, usabilityissues should have been outlined therein. But if this phase consists of a feasibilitystudy, usability is not important at that time –unless the feasibility study has toanalyze a usability problem.

• risk, estimates and contract In this phase, the estimation takes place. Accordingto its result, the customer will sign a contract with the contractor, who made thebest offer. In this phase, usability is of great importance. Both the customer andthe contractor have to agree on usability issues. The project needs a usability plan,which defines the concrete measures for usability, such as prototyping. For this,time and budget have to be estimated. This agreement is crucial for the estimatingto make sure that neither of the contractors will be surprised later in the project byunexpected costs or schedules.

• planning The planning includes a scheduling and the assigning of tasks to people.The project plan is built due to available time and resources. Additionally, thecontract may be revised here due to changes in environment conditions. This is thetask, where the usability measures are concretely planned. It is defined, e.g., whowill manage the requirements and what resources will be at his or her disposal. Thecustomer contact is crucial for the usability measures. As outlined in the first partof this chapter, participation is the key concept of usability engineering. Therefore,the customer has to plan for the involvement of the users, too, e.g. users must bereleased to participate in the project. Prototyping as a measure of participation istime–consuming. Jozwicka-Braun points out that the development of a prototypeshould be treated as a ”project in the project” ([Jozwicka-Braun 2000, p. 89]).

3This is often the case for SofTec.

39


It has to follow the same rules, as there are a an order to develop, assigned staff, timeand budget, a concept, realization, evaluation and additionally, it has to be decided,whether it is to be thrown away or to be developed further. The stakeholders in thedevelopment are not only the developers, as important are the prospective users.The evaluation should include users, who were not involved in the development ofthe prototype.

• building and leading the team Most often, project managers do not have a choicefor their team members. If they have, they most probably choose people with technicalskills as well as communicative skills. Leading the team not only includes to assignwork tasks but also assures a good communication among the team members. This iseven more important, if the team is distributed over several locations. Usability hasto do very much with communication, not only between the developers themselvesbut also between developer and customer representative. Usability methods arestrongly based on communication. Therefore, communicative skills are of greatadvantage. Another aspect of the relation between team leading and usability is thefact that the team leader has to promote the usability measures, especially, if theteam members are not well educated in this respect. The aspect of communicationis further detailed below.

• managing and controlling progress and cost The project management providescontrol measurements. In this respect, usability is as important as any other taskin the project and has to be controlled equally.

• managing quality and change To manage quality and change, particular mea-sures have to be taken. The managing of usability quality includes ongoing reviewsby the customer to verify that the development outcome meets the customers needs.This measures include prototyping and usability tests.

• closing the project The closing of a project includes the handover of the projectresult. From the perspective of usability, the usability effort has happened. At last,together with the product, a user’s manual is handed over.

Two factors among the project tasks should be pointed out as they are highly important:change management and communication. Software is a complex product. As pointedout in section 3.2.1 Requirements Engineering, the requirements will change during theproject. A procedure must be installed to define, how these changes will be handled.If these are minor changes, the change may be done within the projects resources. If achange requires more effort, it has to be estimated, and the customer will have to payextra for it, at least, this is important for fixed price projects. When the payment is ona time and material basis, this is common practise anyhow. But in any case, a majorchange will increase either the development time or the staff involved in the project. Huntand Thomas point out that it is easy to get problems with changing requirements, theycall this phenomenon the ”just one more feature maelstrom”. They propose to documentcarefully each change request to ”get a clearer picture that ’just one more feature’ is reallythe fifteenth new feature this month.” ([Hunt and Thomas 2000, p. 210]). Kotonya and

40


Figure 3.12: Relevant Factors for efficient project work

Summerville propose to ensure that the changes ”make economic sense and contribute tothe business needs of the organization buying the system.” Change control consists offormal procedures to document the change request, the reason, the person in charge, thedecision upon the implementation and the release ([Kotonya and Summerville 1997,p. 11]).

Software development requires a certain amount of communication skills from the stake-holders. ”Communication skills are critical, for work is often conducted through teamsof people from different disciplines, with different knowledge bases, and with somewhatdifferent vocabularies.” ([Fetz and Day 1990, p. 84]) Brodbeck reports from the projectIPAS in which interviews were conducted with 200 collaborators from 19 organizationsin Germany and Switzerland ([Brodbeck 1993]). 21 software projects were examined toanalyze the relation between the degree of communication and the quality of the softwareproducts. The developers spent on average 30 per cent of their time on communicationwith other stakeholders. This communication was closely related to co-operation and con-sisted of different activities like project meetings or presentations. When questioned whatthe important factors to efficient project work are, the answers contained most factorswhich have to do with communication, cf. figure 3.12 (text in graphic translated by me).

Brodbeck found a positive correlation between the amount of communication and thequality of the product. To include user participation in the development process mayseem to be a handicap for the development on first sight. But good communicationpractises can eliminate this negative impact. He concludes that it is necessary to improvethe communication skills of stakeholders involved in software development to improvesoftware quality. Communication is last not least also important among development

41


team members, because the results of user contacts have to be communicated to thewhole team.

Also Beck confirms that communication is crucial to development projects. She pointsout that participants do not volunteer but are forced to work on the projects. The bigger aproject is, the worse is the communication situation, because the personal contact betweenthe team members gets lost. The most important motivation factor, the corporate feeling,does not evolve. In projects, where the interpersonal relations were improved, e.g. whenparties at milestones were included, motivation and communication was rated higher([Beck 1993]). Communication is a common problem between developers and users.One misunderstanding is that developers suppose that users expect solutions to be tooelaborated and results to come faster as possible. But the users refuse that. Regardingboth groups, Beck found that more than 80 per cent agree that communication is aproblem.

At last, team members are people. They need a degree of freedom to do their workwell. Constantine points this out to be of great importance: ”In the typical situation,all factors –budget, allocation of resources, staffing, methodology, and deadline– are fixwhen the project is given to software developers. Where can we get improved quality?”([Constantine 2001, p. 175])

3.5.1 Summary

Project management involves usability in nearly every task. As usability consists of time-consuming methods, these methods have to be planned in a project in terms of scheduleand budget. The most important tasks are the change management and the support ofcommunication among team members and between team members and users.

42

3.6 Summary Usability Engineering

3.6 Summary Usability Engineering

Usability Engineering is the discipline that provides methods and processes to produceusable software. The main principles are user participation and iterative development andevaluation. Modern process models provide a general framework to integrate usabilitymethods into the development individual process. Though the RUP is the state–of–the–art process model providing iterative development, participation tasks are missing. As theRUP is a process model, these tasks can be integrated into an individual RUP. To supportusability integration, quality assurance and project management have to be adapted tomeet the requirements of the process change. Most common usability methods include auser–centred task analysis as provided for example by contextual design or scenario–baseddesign, prototyping for requirements engineering and design evaluation, and heuristicevaluation to extend the user–based evaluation. These methods have to be integratedinto an iterative development process.

43


44

4 Examination of the softwaredevelopment process

The basis of my proposals is the analysis of the current situation of the software develop-ment process at SofTec. For my analysis and evaluation process, I adopted an empiricalapproach. The first section describes how I chose an appropriate evaluation process.Atthe end of this chapter, I will outline the result of my examination, a description of thestatus quo of the development environment of SofTec. This situation led to my proposalsexplained in the subsequent chapter.

4.1 Examination Process

In this section, I will outline methods proposed in the literature, each of which I willdiscuss and explain, whether it was appropriate for my purpose. A formatting was chosento distinguish the method description (bold and italic) from my discussion.

4.1.1 Using Empirical Research

I conducted empirical research to analyze the development process. To learn about appro-priate methods for my examination process, I chose two books recommended by universityteachers: [Flick 1998] and [Bortz and Doring 2002]. Especially the latter, a standardbook on empirical research, provided me with useful methods. Empirical research is di-vided into two major forms of research: quantitative research and qualitative research,which differ in their goals and their design.

According to Flick, quantitative research separates causes and consequences, and theinvestigation is conducted under stringent conditions. This includes in particular theindependence of the researcher. Quantitative research focuses on questions of how to op-erationalize and to quantify the collected data and offers scales for the answers. Therefore,a questioning will be carried out with a questionnaire, which provides answers that canbe put into range and order.

On the contrary, qualitative research does not usually aim at comparing data but atcollecting an at most broad range of answers ([Bortz and Doring 2002]). It producesdata that is not intended to be quantified and focuses on the interpretation of the col-lected material. The material consists most often of interviews, which do not offer scalesbut the possibility of free answers and of questions not intended in the beginning. There-fore, qualitative interviews are conducted with an interview guideline rather than with aquestionnaire.

4 Examination of the software development process

To summarize, quantitative research is characteristically used for hypothesis testingsince it is here where an independent researcher is most strongly called for. By contrast,qualitative research is characteristically used for explorative designs where no clear–cuthypothesis has been formulated initially. The field I wanted to examine consists of pro-cedures and problems of software development at SofTec. This is an explorative fieldwithout a hypothesis; thus, I adopted a qualitative approach.

4.1.2 Choosing an Interview Form

Qualitative research provides a useful means of accessing undefined problems: theinterview. Flick describes different forms of interviews which have different goals([Flick 1998]). My goal is best met with the expert interview. The expert interviewassumes that the subject is an expert in the object of investigation. The interview part-ner is not an individual case but a representative of a group. Therefore, the interviewguideline has the task to structure the interview to avoid unnecessary topics more thanin other interview forms.

All my subjects were asked about their daily work, or at least a part of it. So they wereexperts in the research object. Additionally, each interview partner was not regarded asan individual case but as a representative of a role. I met this point with using differentinterview guidelines for the different roles I identified in advance. With the interviews, Iwanted to gain knowledge on processes, not on individual differences.

Other interviews comprise the focus interview, which presumes a stimulus given beforethe interview, the half-structured interview, which aims to reconstruct the subject’s theoryon the object of investigation, the problem-focused interview, which collects biographicdata to examine problems of general interest that emerge in society, the ethnographicinterview, which is conducted during a participative observation, the narrative interview,which collects data on biographic developments, the episodic interview, which examinessituations in everyday life, and the group interview, which uses group processes to examineopinions of individuals.

4.1.3 Conducting the Interviews

In the following enumeration, I listed common problems wit interviews according to Flick.For each item, I will describe how I intended to avoid it.

• The interview partner refuses the interview, e.g. because he or she is no expert asintended. I chose the interview partners carefully to be sure that they are expertsin the requested domain. Especially, I checked, what role they are in to use theappropriate interview guideline1. Some interview partners appeared in two roles2.In that case, I merged the two appropriate guidelines.

1As I am a colleague of most interviewees, I knew about their role. Where I was not sure, I asked thepersons directly or I asked my manager.

2See paragraph on ’Preparation of Contents’ below for details on roles and guidelines.

46


• The expert involves the interviewer into current conflicts in the team. I was awareof this problem, but it did not appear. If it had appeared, I would have tried tofocus the interview partner on the questions again.

• He or she switches from the role of an expert to that of a private person, which leadsto too much data on the private life rather than on the expert knowledge. As I ampart of this development team, I have personal relations to its members. Therefore,it happened from time to time that the interview partner did no stick to the question,but that was rare, and it was no problem to focus the person again.

• It is difficult to choose subjects. This was not difficult as the identification of theroles implied the choice of the subjects. All subjects I asked agreed on an interview.

• It is difficult motivate the subjects. Most of the interview partners were my directcolleagues. They knew me before and were motivated not only because of thepersonal relation to me but also because they knew my intention. My managerarranged the contact to two customers, who agreed on an interview. In addition,one user participated as well when contacted by a colleague.

• The researcher needs communicative skills. I assume that I have communicativeskills as I have worked in many teams where communication was important forwork. I am experienced in giving talks and I attended a course at university whereI learned how to conduct qualitative interviews.

• The managers have to grant the permission to interview the stakeholders. This wasno problem. As I was allowed to write this thesis, I was also allowed to interviewthe stakeholders. Additionally, I affirmed to keep the interviews anonymous.

Conducting the interviews, I followed the steps to be taken in qualitative interviews asproposed by Bortz and Doring ([Bortz and Doring 2002]). In the following, I will listthese steps with a description of how I used them in my process.

1. Preparation of Contents The preparation of the contents includes the choice ofpersons, the definition of the contents and the preparation of guideline questions.

My research object was a process where many people in different roles were involved.I identified the roles involved in the software development in a first informal interviewwith an employee, who works both as a business consultant and a project manager.These roles are:

• Customer

• Manager

• Project Manager

• Software Developer

• User

47


Each of this role was represented by at least one member. To structure my inter-views, I used role–specific interview guidelines. Each interview guideline consisted ofdifferent blocks of questions and differed according to the role the interview partnerwas in. These blocks included these domains:

• Person

• Usability Knowledge

• Usability in the Work Process

• The Development Process

• Project Management

• Customer–Developer Contact

The interview guidelines for the different roles can be found in the appendix. Asthe examined company is German, the interviews and the guidelines are in German.The appendix contains both the original guidelines in German and the Englishtranslations.

2. Organizational Preparation Additionally, the interviews have to be organized,i.e., appointments must be made, material must be prepared, as the guideline, therecorder, substitute batteries, business cards and other information material. Allinterview partners were either contacted by me or my manager first. I informedthem about the exact purpose of the interview before the actual interview session.All but two cases were recorded3. Therefore, the interviews took place in a quietroom. I prepared the guideline and the recorder for each session.

3. Start of interview Before the interviews starts, small talk helps to create a con-venient atmosphere. This may reduce acceptance problems, that occur often due torecordings.

I introduced myself and described where I work and how this work is related to mythesis. A short description of my subject followed, including a list of the points Iwanted to talk about.

I explained that I wanted to record the interview for convenience. The interviewrecording gave me the freedom for a detailed analysis afterwards. All interviewpartners were asked if they agreed with the recording. This was no problem as Iassured the interviewees that the interviews would be treated anonymously and thatno real names would appear, so that neither the name of the interview partner northe name of any company would appear in this thesis.

At last, I explained that I will show them a summary of their interview to make sureI understood him or her. Additionally, I told that my thesis is in English and asked,if the interview partner would feel comfortable with an English summary. I offered to

3One interview was not recorded due to technical problems with the recorder, another interview wasnot prepared in advance as the opportunity arose unexpectedly. In both cases I made notes.

48


provide a German summary. All interviewees agreed on the English summary. Theinterview partners were asked to give a feedback on my summary. The interviewswith those persons who knew me in advance had a convenient atmosphere rightfrom the beginning. The remaining interview partners were very co–operative andsoon a convenient atmosphere was established during the introduction.

4. Conducting and Recording of Interview The main task of the interviewer isto control the interview progression, to find additional questions from the contextand to prevent the subject from digressing.

As mentioned above, all interviews but two were recorded. In order to guaranteean efficient interview situation, two interviews were conducted with volunteers as apre–test; as a result, the interview guidelines were optimized for the interviews withthe intended subjects.

5. End of interview The interview end is marked by the shutdown of the recorder.It is important to notice utterances more attentively, as subjects sometimes provideuseful information when the recorder is off.

I was prepared to note additional information after I stopped the recording, butthat did not provide additional information.

6. Saying Good Bye The good bye end offers the possibility to present a businesscard and to offer the results.

All interview partners received a muffin at the end as a thank-you-present as theinterviews had to take place in their spare time. As this thesis will be published onthe internet, I will send the link to the interview partners.

7. Interview notes Interview notes can be used after the interview to note additionaldata that did not emerge on the recording. As I explained above, I did not takenotes after the interviews.

49


4.1.4 Choosing Evaluation Methods

When I had recorded an interview, the next step was to evaluate it. For this part of myexamination, I consulted [Bortz and Doring 2002] again. According to them, qualita-tive research provides several methods to evaluate qualitative data. All of these evaluationprocesses have been developed for the use in sociology and human science. Therefore, theyare not all applicable for my purpose. My requirements were best met by the QualitativeContents Analysis according to Mayring. This analysis comprises three steps:

1. Summarizing Contents Analysis The original text is condensed to a concise textthat contains the important contents. Decorating statements or long winded descrip-tions are shortened. Concrete examples are generalized and redundant statementsare deleted.

This method proved to be useful for me. The interview protocol omitted both manyredundancies and decorating statements. Concrete examples were not interestingin general, although they sometimes served to clarify certain aspects, so they weremost often omitted as well.

2. Explicit Contents Analysis Unclear statements are clarified using additionalmaterial like other interview passages or knowledge about the subject.

I clarified unclear statements letting the interview partner read and comment onmy summaries, which partly contained additional questions. As I worked in theproblem context, it was easy for me to clarify remaining unclear statements.

3. Structuring Contents Analysis At last, the text is sorted due to the researchobject. This includes a scheme of categories, which is refined before it is applied. Thecategories can be classified into a structuring of contents, a structuring of frequent orinteresting representations and a structuring of scales, which estimates statementson a scale.

I did not build categories from the identified problems. The interviews did notreveal individual problems that could be categorized.

Other evaluation methods included the General Qualitative Analysis, which focuseson analyzing individual cases, the Global Analysis according to Legewie, which includesmany text interpretation steps that are not necessary in my case, the Grounded Theoryaccording to Glaser and Strauss, which aims to test a hypothesis, and Linguistic AnalysisMethods, which aim to analyze the construction of a text.

4.1.5 Summary of the Examination Process

The appropriate process for my examination derives from qualitative research. I conductedinterviews to find out about the development process, a field that was not clear at thebeginning, so interviews with guidelines were reasonable to explore the field. The expertinterviews matched my needs best as my interview partners were asked about their dailywork. The interviews were prepared with different interview guidelines for the different

50


roles of the interview partners, like software developer or customer. Each guideline hada structure of main topics to talk about with each having several concrete points. Mostinterviews were recorded. This made the interviewing easier as I did not have to writedown answers and find additional questions at the same time.

The evaluation started with a protocol of the interview, which was sent to the interviewpartner for feedback. This allowed me to clarify unclear statements and to pose additionalquestions where useful. The interviews were summarized to one status quo. An analysis ofthe status quo led to the identification of integrations points for usability. These problemswill be discussed in the subsequent chapter.

51


4.2 Status Quo

This section describes the current situation at SofTec from the point of view of sev-eral stakeholders. At first, a summary of the interviews with the members of SofTec isprovided, including software developers, project managers and managers. Afterwards,a summary of the user and customer interviews is provided. All evaluative statementsin these sections were provided by the interviewees. During the interviews, a documentimportant for the development was mentioned. As this document is the basis for commonprojects, I analyzed it with respect to usability engineering. The result of this analysisis outlined. At the end of this section, a brief overview of the adjustments made to theRUP to produce the software development process at SofTec is outlined.

4.2.1 SofTec Summary

EnvironmentThe corporation Transport Services Corporation resides in the business of publictransportation. It is divided into several business segments, one of which is the supportfor the maintenance of the transportation crafts. This segment resides in the corporatecompany SofTec. It is divided into three business units, one of which is ”Consultingand Development”. This business unit is divided into the SAP Consulting Group, theBusiness Consulting Group and the Application Development Team. This developmentteam consists of eleven Java developers. Application maintenance resides in anotherbusiness unit of this company.

Projects of the Application TeamThe software build by the application development team is mainly build for the maincustomer in the area of maintenance and production planning. Few projects are accom-plished for external customers. If so, these are commonly customers who reside in thetransportation industry as well and who have similar requirements, e.g. the managementof large amounts of data.

OffersMost of all orders, about 4/5, of the main customer accomplished by SofTec are placedby invitation to bid. The last fifth results from small direct orders without bidding.Sometimes, a consultant may propose a development project which is assigned to thedevelopmen team. However, the transition of the consulting job to a development jobis often a bit unstructured, because the IT specialists are involved late in this process.Developers would like to be involved earlier to provide knowledge on the feasibility asthe consultants are not always capable of estimating the effort needed for solutions withnew technologies.

When an invitation to bid was published, a team is reassembled to create an offer.This team includes a potential project manager and one or two potential developers. Theteam has to estimate the required efforts and to build up a possible project plan. Theestimation comprises efforts for the development itself, including tasks like implementing

52

4.2 Status Quo

and testing, and for supporting tasks like project management. The estimation team willpresent the project to the customer. Possible project members, i.e. persons with therequired skills, will mostly attend this presentation to be introduced to the customer.The project manager is a member of the business consulting team. In larger projects, atechnical project manager, who is a senior developer from the Java team, is appointed. Iffurther knowledge is required, team members are also recruited from other departments.The customer can influence what persons have to become members of the project team.The customer has often a concrete idea of who has to take over the project management.Even the team members are so well known with their skills that the customer requiresthe team members by name. This makes it difficult to introduce new employees.

As the bidding is a common process for the main customer, SofTec has to competeagainst other development companies. A differentiation against competing companies canbe achieved with the criteria skills, price or time. An invitation to bid is often answeredby companies with unreliable offers, most of which are identified by TechProduction.Among the remaining offers, there are often still some unreliable ones. In this cases, itis difficult for SofTec to argue, why their offer is adequate. This is also difficult, becauseTechProduction knows the employees of SofTec, their experience and their actual work.The manager of SofTec addresses this situation with a so–called ”open book policy”, i.e.,not only is the offer made, a detailed argumentation for the costs is provided as well.

If the price for the software is too high for the customer, some elements will be aban-doned. This is most often the documentation, the customer will maybe write it internally.One project manager stated that it is very important to include the abandoned require-ments in the contract, because the customer might claim later that its absence might betaken for a symptom for low quality. Often, the abandoned requirement will be regardedas important though and will result in a later change request.

The offer contains a detailed concept of the software. This concept contains a require-ments specification and responsibilities for the development team, e.g. to use specificguidelines, and the customer, e.g. to involve users in the development. The conceptdefines project team members, specifying their general tasks, and in which stages in thedevelopment they take part and to which extend. Additionally, the concept defines thelimits of the project, i.e. it states explicitly that specified tasks are not in the scope ofthe project.

To set up a project to collect requirements would be an appropriate way, but this isnot always possible because the customers do not want to pay for that. Customers expectan offer to contain the requirements as they are stated in the bidding paper. Hence, theoffer sometimes has to include the specification of yet unclear statements. This will leadto a passage in the contract that some requirements will be detailed during the project.

An invitation to bid often contains a screen design and a screen flow. This is sometimesvery detailed, e.g. with a specification of millimetres to determine the position of ascreen element. In that case, the development team implements this specification.If there is a gap in the specification or the design seems odd to the developers, thisproblem is discussed with the customer. Sometimes, such a screen design is taken forrequirements specification. This has to be detailed in further descriptions. Often, thedesign is provided by the customers marketing department, this is a fixed requirement

53


then. Another reason for a fixed design is that the customer obtains offers from differentcompanies. To compare these offers, it is necessary to leave the design unchanged.

Project ManagementThe project management is accomplished by a project manager for the whole project.Depending on the size of the project, a technical project manager is constituted. Thecomplexity of the projects varies. A small project comprises two or three developersand a development time of at most a few weeks. A complex project includes maybe 20persons and a development time of eight to twelve months. The project manager caninfluence the composition of the project team, but this is limited due to the availabilityof the persons.

An important task of a project manager is to communicate with the customer and thedevelopment team to enable the latter to do the work with a maximum of information anda minimum of disturbance, i.e. information not necessary for development but with thepotential to create an unpleasant atmosphere is not communicated. This does explicitlynot mean to keep back information.

Communication is an important success factor for projects. The project manager takescare of the developers to ensure that they seek help, if they need it, and that peopleshare their know–how with others. Additionally, team meetings are essential. Especiallyin projects where new technologies are used, one has to explain it to the other members.All members have to develop a common understanding of the work task.

Communication is most important, for a developer can only do good work, if the re-quirements are well understood. As the understanding of the work task improved duringthe proceeding project, it is an important task of the project manager to spread thisknowledge in the project team. The project manager has to take care that the teammembers receive required assistance for their work.

It is important to create a work situation that enables all team members to workefficiently. This includes to clarify the time resources of each team member, e.g. that theteam members will not be forced to work on too many different projects.

One project manager stated that an iterative approach is used, i.e., the work is splitinto work packages, so the software is not developed all at once but package after package.Each package is accepted by the customer separately.

Ideally, milestones are defined for the development phase which provide basic systemfunctions. This may be better called pilot application. This has to be defined togetherwith the customer. Customer like this process as they can provide their superiors withsomething to show.

The customer contact contains weekly status reports in a structured form, e.g. includingtraffic lights. Depending on the individual project, phone calls or meetings are held severaltimes a week. Frequent customer contact is especially important, if requirements are notproperly defined.

When the customer discovers that the system is not as required, the concept is usedas the basis for discussing this problem. This is no problem with a project on a timeand material basis. If it is a fixed price project, which is common for contracts betweenSofTec and TechProduction, the project manager has to explain that this was not part

54

4.2 Status Quo

of the concept and will propose a change request. is the task of the project managerto negotiate on change requests. If the two contractors cannot agree on a solution, aarbitrative board is consulted.

One developer stated to expect the project management to ensure that usability is metin a project, this task may be assigned to somebody or done by the project management.Ideally, in early phases of the project, a person who has experience with usability shouldreview the software to make usability propositions. There is a good understanding forthe differentiation of customer and user. This becomes obvious when conflicts arise,because the users want additional features and the customer does not want to pay forthem. Then it is the task of the project manager to negotiate with the customer toprioritize requirements and to determine change requests if applicable.

Definition of UsabilityThe definitions of usability varies a little among the stakeholders, but they have someaspects in common:

• work task Usability requires to know the work tasks and work processes. Theuser wants his or her work to be well supported. This requires a co–operative workbetween the developers and the users and a project manager who understands bothgroups. Usability is reached, when a user can accomplish the work task as quickly aspossible. In general, user groups and their work environment have to be identified.For example, in a critical work environment, a technician should not be confrontedwith the task of entering columns of numbers into a computer.

• design The screen design and screen flow is often perceived on an emotional level.The software has to be concise and style guides are used. One developer pointedout that 99 % of the software usability comprise the user interface, because thatis what the user sees. Software usability considers the usability of the softwareinterface and the reaction on user interactions. This comprises a thorough conceptand design. Standards should be followed, e.g. the placement of ’OK’ and ’Cancel’button. Additionally, users should be prevented from making errors.

• ease of use A software has to be easy to use, i.e. the user must be able to usethe software without requiring much training, intuitive handling is an importantrequirement. Additionally, software needs clear and concise structures. Help mustbe available immediately.

• communication Usability is closely related to creating a positive atmosphere dur-ing the project. At best, several users are integrated, who are representatives of thewhole user group. An intensive integration of the customer into the developmentprocess is very essential. If the contractor cares intensively for the customer andhe or she gets the impression that the work is done as desired, this will automat-ically influence the impression of usability. One interviewee stated that the mostimportant measure to ensure usability is to have a close communication with thecustomer to verify that the solution developed is what the customer expected.

55


• performance The software is perceived as unusable if the user has to wait too longfor a result, e.g., in one project, a response time of 20 minutes was not tolerated.If an element is clicked, the result must come quickly within limits, depending onthe operation. A good feedback is necessary, which shows the systems state. Forexample, a progress bar has to show a good progress, i.e., it is not acceptable thatit shows 90% of the time a progress of 10% and then jumps to 100%. A commonerror here is to use the wrong progress bar. If it is not known, how long the progresstakes, it is better to use a progress bar that does not show progress in % but showsthat the system is still working.

• skill level dependence Usability depends on the computer skill level of the user,e.g., a novice will better work with more screens, each of which provides a fewelements. An expert will prefer all needed information and interaction on one screenas he or she will be working faster with this.

The most important aspect for the customer is a cheap software. The second importantpoint is the functionality. Usability is less important. It is a quality factor of softwareand is often presumed implicitly. But customers will not spend money to ensure softwareusability, because it is regarded as a basic attribute of software. One interviewee pointedout that usability is very important though, because it is immediately perceived, whenthe customer uses the software for the first time. This will influence the acceptance.

The role of usability depends on the invitation of bid. A requirements specification nor-mally contains the required functions for the software. Depending on the customer, us-ability issues are defined more or less detailed. For example, there was a project to rebuilda software, that has been in use for more than 12 years with about 1200 people using it.In this project, a very strong requirement was put on the design and the interaction: Thesoftware had to have the same interface as the old one had, for the users should ideallyfail to notice that the underlying software had changed, for the training costs would betoo high educating this large number of persons. However, it is fatal to fail to check theusability not until the system is delivered, so a prototyping is crucial for the development.

The number of users participating in development differs from 0 to 3. This dependson the IT department of the customer. If this department is well involved, just oneuser is necessary, because the user has to decide just specific questions, The IT de-partment, which is close to the user group, will have done most of the analysis in advance.

BildschirmarbeitsverordnungThe Bildschirmarbeitsverordnung is concerned with hardware economics like displaysor chairs. In the corporation, every new employee has to attend a one–day course onergonomic and security issues. This course communicates the relevant knowledge. Everyfew years, the employees can undergo a medical examination, i.e. an eye examination.This is under the surveillance of the secretary’s office the employee belongs to. TheBildschirmarbeitsverordnung is known, but without the extension on software usability– except of one developer, who is aware of the impact on software. In the softwaredevelopment, the Bildschirmarbeitsverordnung is therefore not explicitly considered.The user groups are identified in terms of functional requirements, e.g. ’who gets which

56

4.2 Status Quo

report’. To meet the requirements of users concerning the introduction of new software,SofTec offers ’mental change’ trainings for users to explain the impact the changes.

Employee’s skillsNew employees mostly do not need specialized skills. Their attitude towards working ismore important. They should have fun working, have the intention to develop themselvesand to learn what they need for their work, and have an idea of their career goals.Additionally, a customer– and user–centred attitude is essential. Trainings may beoffered, if a certain skill is needed for a project. Important though is that the customeris willing to pay for the according work packages in the project. From one developer’spoint of view, to be permitted to attend a training course requires that the employee hasthe concrete course plan with the dates and offers to spend some free time. Trainingsare not offered by the managers, although this is often defined in annual employee talks.The disadvantage is that employees are treated differently because those, who demand atraining are more likely to get one. Developers are willing to improve their knowledgewith training courses. This is not supported by the management with costs as reasoning.Most of the developers improve their knowledge in that they learn new technologies offthe job. The monthly team meeting is used to present new technologies, but this cannotreplace trainings.

All developers did not learn much about usability during studying computer science,courses on usability were attended voluntarily. In these courses, usability was introducedas a quality factor and the notions defined in ISO 9241 were explained, e.g. ’conformitywith user expectations’. One developer stated that being a user of several applications,one develops an understanding of what is usable and what is not. Much of thisis determined by the use of Windows. The experience in using Windows leads toexpectations for other application. Although that is not necessarily usable, one expectscommon behaviour and therefore, this is regarded as usable. One developer voluntarilytook a hands–on–course on usability evaluation of web sites. This was not related to thedevelopment process, but it was restricted to user interfaces. ISO and DIN norms werementioned in that course. The development team has no usability specialist. There is akernel team that is very experiences in programming. This leads to the effect that thesemembers are often consulted to estimate projects for example. This is often a disturbanceas these tasks have to be done in a limited amount of time while the developers work inother projects. The most important improvement measure for the Java team is to reducethe inhomogeneity in the team, to get all members on a high level. A specialization isnot helpful in this respect, because the team is too small. A specialization would behelpful, if more than one person had become a specialist in a certain field. Otherwise, itwould be impossible to have two projects at the same time, which require this skill. Theexperience in Java differs among the developers. A few of them are very experienced.The remaining developers are intermediate. Another aspect pointed out by a developeris the confusion of tools used for development. For example, in the last few projects, fourdifferent UML tools were used (Rose, MagicDraw, Together, Poseidon). The developersare expected to learn these tools without spending time. But this is not the case. Eachnew tool requires learning time.

57


Quality AssuranceThere are no general quality assurance methods applied here. It is the task of a projectmanager to use appropriate methods of quality assurance. For the project management,checklists are used to establish a project management standard. The PSF (see section4.2.4) supports the collection of relevant documents, but does not support a process. Aworkshop was held to address the importance of standards for projects. This revealedthat project managers and developers have different visions of quality management andthat it is important to introduce an ongoing improvement process with the development ofquality standards. Software quality is a subject that has to undergo great improvements.The usability is more or less implicitly described in the specialized concept. In cases,where this concept seems odd to the development team, they will make propositions forimprovements. This is not driven by the knowledge of norms but by personal commonsense. The team’s evaluation of the design contains two aspects: one is a very subjectivematter. The design is a matter of taste. This evaluation is done before the software isused and is concerned with design details like buttons. The second aspect deals withthe usability and appears when the software is used. When the developers think thatthe software is difficult to use, this is in any case a point to discuss with the customer.One developer reported a case, where software was built to be used by employees ofthe customer to record data. In this case, the software was built for a special purposeand a limited period of time. The usability was explicitly not considered in this case.The only goal was to build a the software very quickly. Its design was proposed by thedevelopment team and determined by the customer, without user participation.

Software Development ProcessThe development team exists for about two years now. Up to now, there was no processmodel installed. As some conceptual problems in the company are known, one of whichis the missing process model, there will be a revision process as soon as possible. This isplanned to be carried out during the current year. A master thesis of a former studentyet made a proposal for a development process. Another idea was to specialize theJava developers in different parts of the development, such as back end and interfaceprogramming. A more important problem in this team is that there is an inhomogeneityof the group. There are developers, who are very advanced, and others, who fail to usethe development environment properly. This affects the performance of the team andleads to a development that focuses on the functionality in a project, where deadlineshave to be met. This holds not only for usability but for other software quality factors.Aspects like usability could only be considered, if this basic problems are already solved.

The customer prescribes the development process in that the project is already planned,and the waterfall model is prefered here. So the development team is not involved in therequirements phase. This is conducted by the customer. However, the requirements willbe elaborated together with SofTec. The co–operation with the users is often restrictedto an evaluation at the end of the development. During the project, its progress is mostlyshown to the customer.

58

4.2 Status Quo

Development FrameworkThe emerging importance of Java and the J2EE standard led to more and more complexsoftware applications. To support the needs of the development, a J2EE frameworkwas developed for easier development of J2EE applications. The development of thisframework did not take software usability into consideration as this framework is moreof a technical architecture. The two GUI modules of the framework simplify thedevelopment of graphical user interfaces for the internet and for JAVA applications. TheJ2EE framework does not support possible usability–related features, e.g. the use ofshort cuts to navigate in an HTML form. One reason for not using usability supportingfeature might be that those features are not specified in the requirements specification,and there are no general guidelines that prescribe certain standards for this. Formerly,the framework was further developed due to TechProduction’s requirements. Regularmeetings were held to foster the framework. This could not be further supported dueto time problems. Meanwhile, external development companies use this framework todevelop software for TechProduction. But as the framework is not sold as a product, theorganization of support is difficult. Requests by these third parties are often not paid, ifthe analysis of the problem revealed that the problem was not due to the framework butdue to reasons within the application development. The caller will not pay as there is nocontract between the development company and SofTec, the customer will not pay, asthis was no problem due to the framework.

PrototypingA prototype is a very useful means, because it can show aspects better than paintedscreens can. Additionally, it is important in the development phase to provide anidea of the system, apart from a tracer bullet, to be able to react at an early stage ofdevelopment, if the software does not meet the requirements.

The main customer offers a very detailed description of the software in terms of screendescriptions with screenshots and screen flows. When this is not the case, SofTec createsscreen designs and screen flows together with user representatives (may be a prospectiveuser or a team leader or a member of the customer’s IT team) most often using Excel orPowerpoint. This is the minimum required for a prototype.

One project manager stated that screens and concept are not sufficient. To enableusers to evaluate the software, a clickable prototype is necessary. It depends on thecustomer, which one is preferred and to which extend. Due to cost reasons, sometimesan evolutionary prototype is expected. This is often the case for applications with Swinginterfaces. An HTML-Prototypes consisting of static pages, will most often be thrownaway. Paper prototypes were never used to communicate with the customer.

It is useful to involve users in the prototyping process, because they can provide moredetailed requirements as their their team leaders, who do not always exactly know, howworkflows are organized. Sometimes, a workshop is held to capture requirements. Mostcritical for the user participation are the costs. During the workshop, the users cannotaccomplish their daily work, but this work is often organized after a tight schedule. There-fore, one person taking part in the participation is the limit. Developers of SofTec have

59


developed much knowledge on the workflows at TechProduction. Good communicationskills are required, if user representatives have to be convinced that they should discusssome requirements with the users.

One developer pointed out that the notion ’prototype’ has different meanings to dif-ferent people. Some think of a prototype to determine requirements, containing screens,and screen flow. Others think, a prototype is a tracer bullet. For example, one simplefunctionality is implemented to show that a certain solution works. This is further usedas a reference implementation.

4.2.2 User Summary

I interviewed users in two interviews, one was a planned interview with one intervieweeand one was a spontaneous interview with three users. This was very interesting as thetwo interviews provided one example for a very successful project, one example of anintermediately successful project and one example for a very disastrous project.

The first interviewee uses few different software products for work. The main ap-plication of this user was supporting the main work task. Additionally, this user usedadditional applications to prepare the main work task, and further office software. Themain focus of the interview was on the software for the main work task as this softwarewas reimplemented by SofTec a short time ago.

This software has two interesting aspects. At first, it is used by about 500 users.Changes in the environment of this software required a re–implementation on a new plat-form. At second, a study group exists for this software, consisting of twelve members,users and team leaders. This shows that the improvement of this software is an importantfactor to the management. The study group meets four times a year to discuss possibleimprovements for this software and to discuss questions on the enlargement of its function-ality and the improvement of its usability. In this ongoing improvement process, users areintegrated very closely in the development process of this application. They can influencethe development in proposing improvements on the functionality to better support theirwork task, and they evaluate the software in an ongoing cycle. The interviewee reportsfrom a second project, where a software was developed to support additional work tasks.This software was developed by an external4 development company. There was little userinvolvement, and the interviewee reported usability problems. It was not easy for the userto determine the state of the software (e.g. whether the software saved the document ornot), to determine its feedback (e.g. status messages could not be interpreted) and todetermine the possibilities to navigate (e.g. how to navigate back to the main page).

The second interview was spontaneous. I could interview three employees of a logisticdepartment of TechProduction. They reported from a project that was in its last phaseof development, shortly before going live. The software is used to support a maintenanceprocess for a vehicle in that it manages the purchasing, the planning and the consumptionof material. For such a process, several departments are involved and will therefore usethis software. The logistic department plans the process and orders material. Anotherdepartment has to ensure that the material is available at the defined point of time. The

4Outside of the corporation

60

4.2 Status Quo

idea for this project arose when a member of TechProduction discussed the workflow witha project manager from SofTec. The goal for this software was to avoid redundancy in theworkflow. One of the interviewees was deeply involved as a user’s representative in thewhole project, the remaining two were less involved. They reported major problems dur-ing the project. It started as a relatively small project with defined requirements. But asseveral departments were involved, they required additional features. No central planningwas considered. The project grew fast, but this was not addressed to by the project man-agement on either side, at SofTec and at TechProduction. Requirements changed rapidly,and the project soon overran costs and time. Additionally, the software was not well inte-grated in the existing system of applications. The Bildschirmarbeitsverordnung was notconsidered, and the works committee did not appear very co–operative. The creation ofthe requirements specification took two an a half years. Besides this catastrophic project,the interviewees reported from another project, which was developed by an external de-velopment company. A software should be replaced. But instead of developing a modulefor the basic software to integrate the new functions, small applications were developedindependently from the basic software. The interviewees feel annoyed to use this varietyof programs although most of them are internet–based.

4.2.3 Customer Summary

I interviewed two customers in different positions. The first customer is the leader ofa small IT group of a department within a company of the corporation. The secondcustomer is a member of the IT department in the corporation and supports the ITteams of departments in accomplishing IT projects. A common development project caninclude the involvement of both stakeholders. Software used by the department of thefirst customer comprises standard software like SAP and individual software, where thestandard software could not support the required processes.

When a new software is required, the decision is between (a) standard software, thathas to be adopted to the needs of the department, (b) the purchase of a new software or(c) the order to develop an individual solution. For a few years now, the development ofnew software is implemented in Java.

Major IT projects are carried out with reference to a guideline, the Project SupportFolder (PSF, see section 4.2.4). This guideline comprises all aspects of a project, e.g.,the conception, the budget estimation and result types. The order for a project is givenfrom a department in the sub company. An internal standard prescribes that the specialistdepartment has to develop the sketch of the application with the IT department in advancebefore a project is set up. This may include a feasibility study to be able to better estimatethe implementation costs. When the complexity is small, no study will be conducted inadvance, and the main project will start. The feasibility study can be conducted by acontractor. This depends on free capacities of manpower in the organization.

User tests are conducted with about 3 or 4 users. It depends on the different profiles,the users have. A profile corresponds to the work profile, at least one user per profiletakes part in the usability test.

When writing a specialized concept, the focus is on the functions of the application and

61


the embedding in the work processes. This does normally not include usability require-ments. Before a project starts, there is an idea of what should be improved and how. Thisis worked out in detail in the specification phase. In this phase, end users are involved.Prototypes are seldom used. Normally, users are involved during the whole project. Theyevaluate the ongoing developed software. As today’s projects are small (three months),the developer is asked to develop a screen flow according to an existing application, andthe software is evaluated with heuristic evaluation against the requirements.

When a tether in the requirements specification appears, the proceeding depends onthe individual case. If it happens to be a mistake of specification, the question may leadto a change request that will be newly estimated. When a specification is not detailedenough and therefore leaves room for design decisions, the first interviewee expects thedeveloper to have a look at possible consequences. If there are no further consequences,the developer can decide the question by himself. In cases, where serious consequencesfor the software can be expected, a dialogue with the customer is required. The costs forsuch discussions should be included in the project costs in fixed price projects.

The second interviewee agreed that if the specialized concept provides space for designdecisions, it depends on the possible consequences the decision has on factors like func-tionality, performance or usability of the system, how the developer has to react. The wellknown developers have a certain degree of freedom to make design decisions. Sometimesthey are given reference applications to guide their decision. A too detailed specificationis not applicable as the writer of a specialized concept cannot always achieve the goalthen. Sometimes, the possible technical solutions in some modules are not known fromthe beginning. Every user has access to the required software by a personal computer.New employees can attend courses in office software, which take one or two days. Theapplications are taught with regard to the work process. There are no official courses.Teachings are given as required. The training material is not an important attribute,when new software is ordered. A training is planned for new software, but it is no projectgoal to keep it as small as possible.

A software development project is most often based on a process redesign. For morecomplex projects, evolutionary prototypes are used. A discussion with the departmentleads to the development of screen flows. In this process, usability is not considered, andno optimizing of a screen flow takes place. The focus is on functionality. The Bildschirm-arbeitsverordnung is known, but not directly used. The contents of this act is handledin a general process instruction providing guidelines for the software development. Oninterviewee stated that usability means to adhere to a standard for all software applica-tions of one user group. However, in some cases, it was noticed that a detailed analysisin advanced would have helped, e.g. in a case where the screen had that much elementsto fit on the screen of a typical user. The layout of the new software has to follow thestyle guide of the corporation, especially, if the new software has to be integrated intothe intranet. Screen flows are designed in workshops. The about eight participants ina workshop stem from the team of IT and of the technical department. The process isdiscussed and screens are developed. Afterwards, developers and users are involved in thewriting of the specialized concept after the workshop.

One interviewee stated that usability is no criterion as it is hard to evaluate. The

62

4.2 Status Quo

experience was that users often refuse a system when it’s new with the reasoning thatthe software is not usable. Some years later, when the system should be replaced by anew software, the users stick to the old one. As theey got used to the software, it isdifficult to find out, whether the software is really unusable. So more important for thedevelopment are factors like the probability of change requests, maintenance costs andthe performance. In greater projects, the software is promoted in advance to get the usersused to the software before it is applied.

One interviewee pointed out that a users’ manual is important for users that do not usea software often. In general, a user, who is expert in his work task must be able to usethe software without a handbook. The other interviewee stated that a handbook is notas important as a training course. The training material will serve then as a handbook.When a new employee is hired, the effort to teach him the software is a problem, becausethe present software is very specific on work processes. A training for two persons is notefficient. This leads to the problem, that software is taught on–the–job by other employees.This implies the danger of transferring errors in the software usage. Therefore, there aretrainings from time to time for all employees, if this is required. These trainings do notonly show the software usage. It is also guided by a co–trainer, who is experienced in thework task, so that an explaintion of the work processes is included in the training as well.

The contractor is sometimes involved in writing the requirements specification andexpects the contractor to consider usability questions in this phase. The work of SofTec issufficient in this respect. The experience of one interviewee with the co–operation withSofTec was different in different projects. In some projects, the project management wasnot fulfilled very professionally. Therefore, the confidence between contractor and projectmanager could not evolve. Current projects are good in this respect. Additionally, thedelivered software did not always fulfil quality requirements, e.g. a documentation wasrare.

4.2.4 Relevance of PFS for Usability Integration

The Project Support Folder (PSF) is a guideline developed in co–operation of TechPro-duction and SofTec to accomplish common IT projects. It is based on a waterfall processmodel comprising the phases feasibility study, requirements specification, implementationand maintenance. It defines result documents for each phase, but no measures how toachieve them are described.

As yet explained in section 3.1.1, this process model does not include common measuresof usability engineering.

One of the basic concept of usability engineering, the iterative development is notconsidered at all. User participation is only included partly. Although the PSF statesthat a goal for this guideline is to develop a common understanding for all stakeholders,neither are the stakeholders defined nor are concrete measures proposed to achieve thisgoal. The PSF contains measures for the requirements specification, but no users areinvolved in this process.

The PSF contains a passage on user interface design. But the ’methodological pre-scriptions’ only define that the style guide has to be considered for web applications, and

63


screen and dialogue standards have to be considered for host applications. The style guideof course does only define the interface in terms of colours´and font sizes. Nothing is saidabout concrete measures to involve users in the design process.

After all, the PSF prescribes that user groups must be defined in advance, users mustbe involved in the evaluation of the system and training measures have to be documentedin terms of who and what has been trained, which kinds of problems occurred, possiblesolutions for these problems and feedback of the participants.

The PSF was established as a standard for common projects. This is a constraintfor a change of the development process at SofTec. As the projects have to follow asequential process, it is difficult to install an iterative process at first sight. A first ideathat could solve this problem is the SDP, an adapted RUP for SofTec. As described insection 3.1.5, the RUP has four major phases, each of which consist of iterative cycles. Agreat advantage in this respect is that PSF does not provide concrete measures. Thesemeasures can be defined individually for each project. Therefore. it should be possible touse PSF as a general framework and SDP as a general process model, that can be refinedwith usability measures.

4.2.5 SofTec’s intended development process

This section describes the future development process of SofTec. The introduction of thisprocess is planned for this year. It is based on the Rational Unified Process (see section3.1.5 Rational Unified Process). In this section, the adjustments for the developmentprocess of SofTec (SP) are described, according to [SofTec 2003]. This is no currentpractise yet, but as this is the intended new development process for the near future, itis the basis for my proposals.

The RUP is a process model, i.e., it does not define concrete measures. Instead, itprovides a framework with a general processing and the definition of activities, artifactsand roles. For the requirements of SofTec, adjustments have been made to the elementsin that the amount of possible elements has been reduced and required elements havebeen added. The result is the SofTec Development Process (SDP). The result consists ofpossible roles, activities and artifacts, which are listed in the appendix.

64

5 Process Improvement for SofTec

For the improvement of the development process at SofTec, an evaluation is necessary toprovide applicable improvement proposals. The evaluation consists of two parts. At first,I rate the user–centredness using the Usability Maturity Model to get a first impressionof the company’s status. After this, I provide a summarizing evaluation of the interviewsto discuss those points and propose an improvement measure. At last, I explain, howspecific measures fit into the SDP.

5.1 Usability Maturity

The Usability Maturity Model (UMM) is a measure to evaluate the extend of user–centredness in organizations. I will use it to get a first impression of the situation atSofTec. Earthy ([Earthy 1998]) describes the UMM:

The UMM defines different levels of maturity, which are assigned to attributes. Eachlevel includes also the previous level. An overview of the levels is given in 5.1.

X: Unrecognized (no indicators)A: Recognized problem recognition, performed

processesB: Considered quality in user awareness, user fo-

cusC: Implemented user involvement, human factors

technology, human factors skillsD: Integrated integration, improvement, itera-

tionE: Institutionalized human-centred leadership, orga-

nizational humancentredness

Table 5.1: UMM Levels

For each attribute, operationalizations are provided. These are used in an interview todetermine the extend of each attribute. At the end, a combination of the single ratings isdetermined for each level. Earthy proposes to set a ceiling, a maximum value, in advancefor simplifying the interview. However this is no obstacle, if the interview reveals thata higher level would be appropriate, the interview can be adapted spontaneously. Thismodel is based on an ordered scale comprising the rates shown in figure 5.2 on the nextpage. The results are collected in a recording form.


From the general overview of the status quo, I decided that SofTec has a minimum levelof B and a maximum of C. It is obvious that SofTec has overcome level A as this thesisis a first step towards the integration of usability into the development process. Insteadof conducting extra interviews for this purpose, I used the results of my interviews. Thestatus quo is the basis for my rating.

I will present here in detail the recording form for level B and C as these were relevantfor my analysis. The recording form is extended with the operationalizations to providedetails on the rating of the single items. The complete recording form and the accordingoperationalizations can be found in [Earthy 1998]. The original has three columns forinterviews and a fourth for the combined rating. For my purpose, one column for therating is sufficient.

The result of this analysis showed that the user–centredness of SofTec is between levelB and level C. The analysis of level B showed that the company reached ranking L, a”significant achievement of define practise”. The analysis of level C showed that thecompany reached ranking P, ”some achievement of defined practise”. Thus, the companyis aware of usability and has yet applied a few usability–related measures.

N for ”No evidence”P for ”Some achievement of defined practise”L for ”Significant achievement of defined practise”F for ”Full achievement of defined practise”

Table 5.2: Ratings in UMM

Level B: ConsideredLevel Title Operationalization Rating

B.1 Quality in useawareness at-tribute

The extent to which the staff carrying outa process are aware of quality in use as anattribute of the system.

B1.1 Quality in use training Staff are made aware that quality in use isa particular attribute of a system which canbe improved.

F

B1.2 Human–centred meth-ods training

Staff are made aware that quality in useis achieved through the use of a series ofhuman–centred processes during the devel-opment and support/use of a system.

P

B1.3 Human–system inter-action training

Staff are made aware that human–centredness covers the total system, notjust the user interface or the physicalergonomics.

L

Combined rating for attribute B1 LContinued overleaf.

66

5.1 Usability Maturity

Continued.Level Title Operationalization Rating

B.2 User focus at-tribute

The extent to which staff performing pro-cesses relating to the user–facing elementsof the system take account of the fact thata human being will need to use it.

B2.1 User considerationtraining

Staff are made aware that the needs of theend users of the system should be consid-ered when developing or supporting the sys-tem.

F

B2.2 Context of use train-ing

Staff are made aware that end users’ skills,background and motivation may differ fromdevelopers or system support staff.

P

Combined rating for attribute B2 L

Combined rating for this level L

Table 5.3: UMM Level B – Evaluation for SofTec

Level C: ImplementedLevel Title Operationalization Rating

C.1 User involvementattribute

The extent to which information is elicitedfrom representative users using appropriatetechniques throughout the lifecycle.

rating

C.1.1 Active involvement ofusers

The development process ensures under-standing of user needs through user involve-ment in all development phases.

L

C.1.2 Elicitation of user ex-perience

The design solution is shown to stakeholdersand they are allowed to perform tasks (orsimulated tasks).

L

C.1.3 End users definequality-in-use

Systems are tested using measures of qual-ity in use derived from end users.

L

C.1.4 Continuous evaluation Early and continual testing is an essentialelement of the development methodology.The process is based on the necessity forfeedback from users.

P

Combined rating for attribute C1 L

C.2 HF technology at-tribute

The extent to which human factors methodsand techniques are used in or by human–centred processes.

C.2.1 Provide appropri-ate human-centredmethods

Select and support methods for the elicita-tion of user input at all stages in the lifecy-cle.

P

Continued overleaf.

67


Continued.Level Title Operationalization Rating

C.2.2 Provide suitable facil-ities and tools

Suitable facilities and tools are provided forquality in use activities.

N

C.2.3 Maintain quality inuse techniques

Ensure that methods and techniques arereviewed for suitability and that state–of–the–art user interface technologies are usedas appropriate in developing new systems.

N

Combined rating for attribute C2 N

C.3 HF skills attribute The extent to which human factors skills areused in human–centred processes.

C.3.1 Decide on requiredskills

Identify required competencies and planhow to make these available in order to fa-cilitate multi–disciplinary design solutions.

N

C.3.2 Develop appropriateskills

Development of appropriate skills inhuman-centred staff either by training orby job experience.

N

C.3.3 Deploy appropriatestaff

Skilled staff are involved and effective in allstages of development as and when required.

P

Combined rating for attribute C3 N

Combination of ratings for this level P

Table 5.4: UMM Level C – Evaluation for SofTec

5.2 Interview Evaluation and Proposals

The overall situation concerning usability provides a good basis for improvements. Allstakeholders are aware that there is good reason to improve the current situation. How-ever, from the interviews, many improvement proposals can be derived. This sectionprovides advice on issues independent from the development process. An analysis on howthe SDP can be extended is provided in the subsequent section.

Most developers have learned about usability at university. But not only the devel-opers, nearly all stakeholders showed a positive attitude towards it and will not resistimprovement measures because they take them for important. A first step to improveusability issues as a part of quality improvement was taken with the assignment of thisthesis.

TrainingAlthough the developers have a basic knowledge of usability, there is a need for training.This training should comprise knowledge on usability and on usability engineering,i.e. what usability is and how it can be achieved. This must include the contentsand relevance of the Bildschirmarbeitsverordnung, the different types of prototypes

68


in comparison with tracer bullets, the general usability engineering methods and apresentation of usability integration in the SDP. It should involve all developers, teamleaders, project managers and managers to gain a common understanding of the issue.Such a training would last at least half a day. If this is not possible, an alternativeis to use the monthly team meeting. Usability issues can be presented here regularly.When software reviews were conducted, the results can be presented here as a trainingsmeasure as well. Also the intranet can be used to collect knowledge on usability issues.This should be structured by a usability expert.

Usability ExpertsAdditionally, there should be at least two usability experts in the development team.It is sufficient to assign this responsibility as part of the position, apart from thedevelopment. These persons will have two main tasks: one is to take part in therequirements specification to have a good understanding of the work task. I will resumethis regarding the customer relation. The second task is to give advice on usability issueswhen problems occur during a project. This includes concrete questions like the orderingof items on a screen or the usability evaluation. It is important to have two persons inthe role of a usability expert. Not only that they can act in place of each other, but alsothey can do a heuristic evaluation for each others projects. For heuristic evaluation, it isuseful to separate development from evaluation to produce a result free from bias.

CertificationWhen the process has been changed, SofTec can apply for a TUV certification. Thecurrent importance of software usability is supported by the German Technical InspectionAuthority (TUV). The TUV has yet developed certificates for usability checks. Thesecertificates comprise two different checks ([Dzida 2002]). The first one checks, if asoftware meets usability requirements. To operationalize usability, the more specificrequirements defined in [ISO 9241 1996] are used. The second check is concerned withthe development process. [DIN prEN ISO 13407 1997] describes general methods tobe employed in a software development process to achieve a product of good usability.This ISO norm is described in detail in section 3.1.4. Gieth et al. point out that thecertification of a process is more valuable than product certification, as the costs comeup only once for the process, but otherwise for every application.

Customer RelationThe relation to the main customer showed to be specific. Although SofTec and Tech-Production are separate companies, they are not independent. This becomes very clear,when it comes to concluding contracts. The contract is very strict in all items. It isbased on a common guideline, the PSF, which prescribes required result documents.The advantage of this guideline is that it simplifies the project contract. However, itdoes not contain usability–related documents. The PSF can be extended to prescribesuch documents. As this is closely related to the SDP, which not only describes resultdocuments, but also the according roles and activities, I will detail the result documentsto be integrated in the PSF in the subsequent section.

69


The customer most often conducts the analysis and the design without SofTec. Thismakes a thorough usability process is difficult, because it comprises the analysis. Theanalysis is important to gain a proper understanding of the work task, which is crucialfor the development. A possible solution is to involve one developer in the analysis ofa project. This is an appropriate task for a developer in the role of a usability expertsand can be sold as work package ’Bildschirmarbeitsverordnung’, which is described below.This results in a win–win situation. The customer can ensure that usability issues arewell considered and with that has taken a quality measure in any case, no matter whowill conduct the project. This is even more important when the analysis is conducted bya marketing team, as it was the case in an example of one employee. The usability expertworking in the task analysis could introduce methods of usability requirements analysis inthe customer company to foster usability. Another advantage for SofTec is that –whenit comes to a project– one of the team members already participated in the analysis andcan spread the understanding of the work task to the remaining team members. Thisis however difficult as TechProduction conducts the analysis, and in larger projects, aninvitation to bid is advertised, so one cannot be sure that the project is conducted bySofTec. Another obstacle is that the customer might not be willing to pay for this work.SofTec could offer a discount when the project is assigned to them as they can save effortduring the later in contrast with competing development companies.

An additional reason to assign the contract to SofTec can be the TUV certification.It is a valuable quality attribute of a company. When a usability process is accepted bythe customer, the customer should ensure that at least one user can be consulted whenusability questions arise. This user has to be exempted from his daily work for the duranceof the project.

SofTec could provide two standardized work packages, named ’basic usability’,and ’Bildschirmarbeitsverordnung’. The first one comprises a set of usability fea-tures that can be ordered. This package can contain general guidelines and featuresfor interface design. This will help developers to decide usability questions in thedevelopment and provide customers with a certainty that the software will have aspecific usability standard. As usability does not only contain interface specific issues,another work package is necessary. The work package ’Bildschirmarbeitsverordnung’can contain measures to ensure the adherence to this prescriptions. Of course, thisis only possible, when a developer is involved in the task analysis, e.g. as described above.

DevelopmentThe development is outlined with respect to the development process in the next section.Here, I outline two further aspects, the prototyping and the development framework.There is no general process for prototyping yet. Most orders have a requirements spec-ification when the project starts. This requirements specification contains a prototypeconsisting of screens and screenflow. However, this is not sufficient for successful usabilityengineering. SofTec should build a clickable prototype early in the development processto gain user feedback for evaluating the requirements, to discuss technical constraints,and to develop a clear understanding of the software. A compromise between extensiveprototyping and costs would be to build a horizontal prototype in the beginning to check

70


the overall impression and to extend it with a vertical prototype for complex modules.The development framework is used for most applications. However, it does only

provide means to simplify the development with regard to the software architecture. Itshould be analyzed with respect to possibilities to provide support for basic usability.This can be means like providing support for internationalization or providing meansto support HTML features not only for HTML based applications but also for Swingapplications, e.g. navigating in a form using alt–keys. All these features can be integratedin the package ’basic usability’.

Project ManagementThe project management relies on the PSF and the development process. Therefore, notmany improvements can be proposed directly for the project management.

If possible, a project manager should influence the team member choice in that at leastone usability expert should be at the projects disposal for advice. The project managersdo yet ensure a good communication, this is a good basis for usability improvements.

As I learned from the developer interviews, usability responsibilities are not clearlycommunicated in projects. Every project should have one person responsible for usabilityissues. To support common understanding, a project glossary containing all relevantnotions related to the software is useful.

In general, the project manager has to plan for ongoing evaluation and to make surethat all relevant aspects are defined in the contract.

General StrategyUsability integration does not come without work. It is a process that has to be managedby a responsible manager. Mayhew proposes a general strategy for usability introductionin companies comprising several tasks([Mayhew 1999, p. 403ff.]):

• promote the idea The idea has to be widely accepted, resistance has to berecognized and cleared out. Useful is a cost–benefit–analysis (for web projects,[Nielsen and Gilutz 2003] provides recent examples.). To contact the works com-mittee to work together on usability improvements may be a further step.

• implementation Benefits have to be clarified and communicated, staff has to betrained.

• institutionalization Usability methods have to be laid down in the developmentprocess

• sensitizing the customer The customer has to be convinced that usability engi-neering is advantageous. Helpful in this respect would be to provide a show case,e.g. a small project, where the new methods were successfully tested.

[Knoll et al. 1996] enumerate the success factors for the improvement of the develop-ment process as there are:

• Acceptance by management If the top management is not convinced that theimprovement is necessary, it will not provide budgets and human resources.

71


• Technical support If technical support is necessary, the technique to be introducedshould be supported by opinion leaders.

• Involvement of of all management levels If not all management levels do agreeon the planned changes, the improvement will go along very slowly.

• Aggressive strategy and realistic action plan The top management will employan aggressive strategy to reach the goals, the middle management level will claim arealistic plan.

• Situation estimation The plan has to be revised from time to time to meetchanged requirements.

• Process visualization The stakeholders of the process improvement should beable to realize the success of their work.

• Training concept A concept for adequate training of different stakeholder groupsshould be introduced.

• Review standards To ensure constant review quality, review standards should beintroduced.

• Relations and labour conditions Relations between different groups must notbe contradictory. Interfaces between groups have to be clearly defined, e.g. whichinformation should be exchanged.

• Additional requirements The equipment, such as computers and rooms must beplanned carefully.

As the introduction of organizational changes requires communication, some tips fromHunt and Thomas might be useful ([Hunt and Thomas 2000, p. 18ff.]):

• Know what you want to say (Communicate your idea clearly.)

• Know your audience (Know their interests.)

• Choose your moment (The listener has to pay attention.)

• Choose a style (Write a long or short description .)

• Make it look good (Use a word processor or layout system, and use a spell checker.)

• Involve your audience (Writing documents, let a draft be read.)

• Be a listener (If you want people to listen to you, listen to them.)

72

5.3 Usability Integration in the SDP

5.3 Usability Integration in the SDP

In this section I show, how usability engineering is related to the SDP. The usability–related artifacts in table 5.5 can be added to the PSF as result documents as explainedin the previous section. Therefore, I extract all activities related to usability engineeringfrom the lists in appendix 2 and provide the according usability engineering method intable A.3 on page 94.

The principle iteration is addressed in that each workflow is repeated during the wholeproject, although with a different focus, e.g. the usability tests may test different partsof the application. Users are involved in all activities provided here.

• Design Guidelines • Use–Case Model• Glossary • Use–Case Modelling Guidelines• Product Acceptance Plan • Use–Case Priority• Programmers Guidelines • User Manual• Test Cases • User–Experience Guidelines• Test Guidelines • User–Experience Model• Test Plan • User–Experience Prototype• Test Script

Table 5.5: Result Documents for PSF

Discipline Activity Usability Engineering

Requirements • Capture a common vocabulary is closely related to the con-• Find actors and use cases text of use. Common usabil-• Prioritize use cases ity engineering methods are• Review the requirements Contextual Design and• Detail a use case Scenario-Based Design.• Review the requirements

Analysis • Model the user experience reviews the results of the re-• Review the user experience quirements engineering as a• Use–case analysis step prior to the design. This• Review the analysis may include some heuristic

evaluation.Test • Identify targets of test has to deal with usability

• Define test details testing and inspection meth-• Implement test ods. The foundation is the• Perform test result of the requirements

specification.Deployment • Manage acceptance tests comprises a final usability

• Develop support materials test. Supporting materialscomprise the user’s manual.

Environment • Develop user–experience guidelines is part of the context of use,Continued overleaf.

73


Continued.Discipline Activity Usability Engineering

• Develop design guidelines depends on the task and user• Develop test guidelines analysis.

Table 5.6: Usability Activities in SDP

Guidance on Process DetailsThe scope of this thesis is to provide general guidance on how usability can be inte-grated in the development process. However, for concrete execution of the proposedmethods, guidelines are required to show details. Good guidelines are provided by[Rudloff and Becker-Topfer 1997] and [Dzida et al. 2001]. Rudloff and Becker-Topfer provide a hands–on guidance on usability design and on task analysis, prototyp-ing and iterative development. Dzida et al. provide a guide on software testing. Theydescribe in detail, how and why analysis and evaluation can be handled. Especially use-ful are the appendices, providing guidance on the evaluation process, a guide on howto conduct a context analysis, and a questionnaire to test software according to ISO9241, parts 10 and 11. Ansorge et al. point out that the evaluation is not sufficient.The evaluators should also provide proposals for improvement when testing accordingto ISO 9241 ([Ansorge et al. 2004]). Several checklists for the requirements analy-sis especially for the RUP, e.g. on stakeholder requests or the glossary, can be foundin [Doremann and Meyer 2003]

74

6 Summary and remaining ideas

This chapter provides a summary of the analysis results and the proposals to addressidentified problems. The analysis process is discussed and an outlook is given for furtheranalysis.

6.1 Result summary

The main question of this thesis deals with the problem how to integrate usability engi-neering methods into an existing development process. When a development organizationis newly formed, a development process can be installed right from the beginning. Whenthe development organization does yet exist for some time, a more or less unstructuredprocess evolves which does not follow principles of thorough development, let alone witha focus on usability. The development process involves many stakeholders. Apart fromthe development team itself there are involved managers, project manages, customers andusers. A reasonable development process comprises the involvement of all stakeholders.

The development company SofTec develops software for a few years. The developmentwas shaped by the knowledge of the developers and project manager. During this time,the team was exposed to customers who were not satisfied with the quality of the softwaredeveloped by them. A first superficial analysis revealed two major problems, a lack of aproper development process and a lack of software usability.

The first step to approach an improvement concerning the usability problem was toconduct a literature research on usability engineering to get an overview on engineeringmethods to support usability. The research revealed both process models and methodsthat attend to satisfy this demand. The basic principles are user participation and itera-tive development.

At second, I conducted an analysis to identify the problematic items. Representativesof all stakeholders were questioned in open interviews, led by role–specific guidelines.The guidelines focused on questions on the factors usability in practise, developmentprocess, project management and customer contact. The result of this analysis revealedissues being most relevant for improvement. These issues are addressed with proposalsinvolving advice from chapter three. An overview is given in the following list:

• Missing development processNo structured development process is established. Development is guided by aproject support folder which prescribes to produce documents without defining theaccording process.

Proposal: In the near future, a development process is to be installed. This


process has however to be extended by usability methods. The intended processdoes not prescribe method but activities and result documents. These resultdocuments have to be extended with user–related documents like user evaluationdocumentations.

• Missing user involvementThe involvement of users varies. In one project, there was no user involvement at all,but most projects at least involve one representative. Problematic though is thatthe representative sometimes is no future application user and therefore cannot an-swer specific questions. User involvement is also seldom defined in project contracts.

Proposal: The user participation must be forced, both in the requirementsanalysis and during the ongoing project. Although the analysis is not conductedby SofTec, a project contract can define the user participation as a precondition.Additionally, SofTec should offer to take part in the analysis with a usabilityexpert. This can be offered as an extra work package, including a discount whenthe project is assigned to SofTec.

• Missing iterative developmentProjects are guided by a waterfall–like process. No iterations are included here.However, in some projects, it was yet possible to develop software module–wise, sothat some feedback was possible for further development.

Proposal: The missing iterative development can be addressed with the in-troduction of a development process. SofTec plans to use a Rational UnifiedProcess. This combines the demand of the customer to use a waterfall model withthe possibility of ongoing iterations.

• Usability knowledge of development team and of customers The develop-ment team is aware of the relevance of usability. Yet they are not well educated inthis respect. Most developers attended a lecture at university voluntarily. Hence, abasic understanding is present.

Proposal: The developers have to be trained in usability–related issues. Alldevelopers have to gain a good basic knowledge of usability and usability engineer-ing methods. However, it is necessary to have one or two usability experts amongthe developers.

• Specific customer relation The company SofTec has a specific relation to itsmain customer. Both companies belong to one corporation. This is advantageousand disadvantageous at the same time. Beneficial is the condition that due tothe proximity and the experience from previous projects, SofTec has a goodunderstanding of TechProduction’s workflows. However, TechProduction knowsSofTec’ employees well and therefore demands specific staff for its projects.Hence, SofTec lacks a degree of freedom in staffing projects. The relation is

76

6.2 Evaluation of analysis process

additionally difficult, because the customer prevents a thorough developmentprocess. A development project is most often published by an invitation tobid. The requirements specification is then yet conducted without the involve-ment of the future developers. Hence, the development team lacks an optionto develop a detailed understanding of the workflow the application supports.Additionally, SofTec cannot be sure of the degree of user involvement. Even in theongoing project, user participation is not always an issue addressed by the customer.

Proposal: The improvement of the development at SofTec will improve theusability of its software. The customer can therefore expect more quality. Theproximity can be used to let the customer track the quality measures undertakenby SofTec. A first approach could be that the new development process is tried outin a small pilot project. Additionally, SofTec can show its competence by givingadvice on usability engineering methods for the requirements specification.

Further resultsThe analysis revealed that SofTec encounters further problems with software quality.Usability is only one factor of software quality. Other factor need to be improved as well,for example the code documentation and the choice of development tools.

6.2 Evaluation of analysis process

The goal of this thesis was to analyze the situation in a specific company to identifypossibilities for process improvement with respect to usability and to provide appropriateproposals. The analysis approach was to conduct interviews, and the proposals were takenfrom literature. Although I think this is an appropriate process, one could consider toembed this analysis in a general quality assessment. For such assessments, several processcapability models exist. As the analysis revealed weak points also in other quality–relatedfields, proposals should as well be embedded in general quality improvements.

The analysis provided a valuable result. However, the analysis could have been extendedto examine users and customers apart from the main customer. Also, the proposals couldhave been discussed with respect to a cost–benefit analysis, because the company dependson revenues and has to justify every expense.

Helpful during the interview phase was that all stakeholders are very open–minded anddo not resist organizational change. During the interviews, they even showed a sensibilityfor usability problems. Also the organizational culture in general was shaped by a veryopen communication.

From the literature can be derived that many development companies have similarproblems –except for the specific customer relation. Hence, a transferability of the re-sults on comparable companies should be possible. However, not all organizations wouldsupport such a study. Therefore it would be necessary to identify common obstacles andaddress them in advance.

77


6.3 Outlook and further ideas

The analysis revealed that there are good solutions for the problems at SofTec. The taskto introduce a development process has yet been assigned. To carry on this analysis, Irecommend to start in parallel with training measures on usability. The person in chargefor this measures should be a developer who is yet familiar with basic usability engineeringmethods and who has good communicative skills. When this basic knowledge is spreadamong the developers and project managers, the pilot project can be conducted to tryout the new measures. A task for managers and project managers is to improve thecommunication with customers to convince them of the advantages of improved quality.Also, a co–operation with the works committee may be useful, because this board isresponsible for monitoring issues of employees, and the usability of software in professionalenvironment is one of those issues. Additionally, a cost–benefit analysis can be a beneficialinstrument to convince customers. However, this is a difficult task, because there are nogeneral calculations, and a meaningful calculation is based on individual conditions.

Helpful in assuring quality in projects is the installation of a quality system. Thisis an organizational framework, which provides a general framework for development,containing process models, standards and guidelines. For each individual project, a qualityplan can be created, which contains a selection of general measurements adopted to thespecific requirements of the project.

In any case, quality assurance is an ongoing process of improvements and presumes alearning organization. Therefore, it must be supported by both the management whichprovides resources and the staff who must be willing to learn and to contribute to thequality system. An important impact on the customer relationship is based on the trustthe customer has in the development, which is created by such a quality system.

The new process can be monitored to prove its success. Possible measurements includeuser satisfaction, e.g. determined with questionnaires, and the number of change requestsduring and after a project.

78

Appendix

Interview Guidelines

For each stakeholder, an interview guideline was created. The guideline does not consistof concrete questions but of keywords. In this way, I could concentrate on the answersand on the guideline at the same time. While talking with the interviewee, it was easierto search in a list of keywords than in a list of formulated questions to check, if allimportant subjects were discussed. Some of the interviewees had two roles and weretherefore questioned with two guidelines. However, the guidelines are redundant in somesubjects, so the overall interview was not twice as long.

Guideline for Management

Position

• work tasks

• relation to software development

Usability Knowledge

• definition of usable software

• Bildschirmarbeitsverordnung: contents, relevance

• measures or constraints for quality assurance (in general & usability)

• knowledge on usability in the development team or other department?

Staff Training

• usability issue when recruiting staff

• qualifying measures for developers and users

Resources

• which/how much for improvement possible? (hours per person and month,budgets for trainings, . . . )

• need for improvement

81


Guideline for Developers

Position

• tasks, roles in software development

• degree of freedom in working

• education in software development

• education in software usability

• like/dislike work

Usability Knowledge

• definition of usable software

• contents/relevance Bildschirmarbeitsverordnung

• relation development–usability

• measures, constraints for quality assurance

• prototyping

• usability measures existing

Development Process

• what development process

• relation to usability

• how ensure usable software

• what supporting tools/methods

• how user/task analysis

• discussion of usability questions in projects

• what about design questions when not specified in requirements specification

Customer Contact

• organization of customer/user contact

• co–operation: (form/contents/degree. . . )

• methods for analysis, requirements analysis, co–operation

• problems

• change requests

Others

• which support needed

• willingness to learn in free time

82

Appendix

Guideline for Project managers

Position

• tasks, roles

• relation to usability

• education

Usability Knowledge

• def. usable software

• contents/relevance Bildschirmarbeitsverordnung

• relation of your development to usability

• measures, constraints for quality assurance

• prototyping

• usability measures existing

Usability in practise

• usage of usability knowledge

• participation (extend, resources, time lines, . . . )

• prototyping(paper,. . . )

• what obstacles hinder you to use usability measures

• are there usability experts? how involved in projects

• are usability questions discussed in projects

• what about design questions when not specified in requirements specification

Project Management

• choice or project team members

• complexity of projects (number of persons, durance, . . . ), . . . )

• how/who requirements specification (own project?)

• where SofTec’s applications used

• how project communication

• discussion of usability questions in projects

• co–operation with customers and users

• definition of quality, differences project manager–customer

• what happens, if desired quality was not achieved

83


Development Process

• development process

• how create user interface, user participation

• how modelling

• how/when/who user’s manual

• form/contents/degree of co–operation with users

Guidelines for Customers & Users

Position

• tasks

Software

• software environment

• number of users

• works committee

Usability-Knowledge

• def. usable software

• Bildschirmarbeitsverordnung

• measures

• participation

• how design decisions

• usability in projects

• requirements specification

• usability tests

84

Interview Extracts

This appendix contains extracts from the interviews. The interviews were anonymous.Interview Partner is abbreviated IP.

I extracted statements from the interviews grouped by the topic. Each statement isassigned with the interviewees who supported this statement.

On usability

• Usability contains a thorough requirements specification: The customer’s require-ments and the workflow must be well understood to support it adequately.(IP A, IP F)

• Usability works on an emotional/psychological level.(IP A)

• Usability includes performance. If all functional requirements are optimally fulfilled,but the performance is bad, the software will not be accepted.(IP A)

• Usability includes early customer/user integration.(IP A, IP F, IP G)

• Usability is represented in the Bildschirmarbeitsverordnung.(IP C)

• I do not know of a relation between Bildschirmarbeitsverordnung and software.(All but IP C)

• Usability includes a concise interface enabling the user to reach a goal as quickly aspossible with the software.(IP E, IP G)

• 99% of the software usability consists of the user interface, because this is what theuser sees. Software usability considers the usability of the software interface anduser interactions.(IP D)

85

Interview Extracts

On requirements specification

• The main customer offers a very detailed description of the software includingscreens. This is sometimes very detailed, e.g. with a specification of millimetres.The development team is not involved in the requirements phase. The co–operationwith the users is often restricted to an evaluation at the end of the development.(IP A, IP B, IP D)

• Most often, the delivery of a user’s manual is defined as a requirement for thesoftware. But it is seldom defined what it should contain or how comprehensive itmust be.(IP F)

Usability is no requirement in a requirements specification. Performance is definedsometimes.(IP G)

On user participation

• Users often provide detailed requirements because they know the work process andwhich information is needed at what point in process.(IP A)

• The software acceptance can be ensured, if the later users are involves early in thedevelopment.(IP A)

• The most important means to ensure usability is to have a close communicationwith the customer to verify whether the application under development meets thecustomer’s expectations.(IP F)

On customer relation

• The customer can influence what persons have to become members of the projectteam. This begins already in the phase where the offer is created. The customeroften has a concrete idea of who has to take over the project management. Theskills of the team members are so well known that the customer demands the teammembers by name. This makes it difficult to introduce new employees.(IP A)

• When an offer is made for a given concept, the customer is sometimes surprisedbecause of the high price. The first thing required by the customer is to reducesome functions. [...] But the project will be more expensive, if the revision of the

86

Appendix

concept is done half–heartedly, which leads to higher costs due to change requests.(IP B)

• The most important aspect for the customer is that the software is cheap. Thesecond important aspect is the functionality. Usability is least important.(IP B)

• Customers will not spend money to ensure software usability, because it is regardedas a basic attribute of software.(IP F)

• To propose to the customer to involve users in the development process is a criticalpoint, because it is crucial for the development, but customers refuse this due tocosts.(IP A)

• The role of usability depends on the customer. Usability is a criterion that is oftenpresumed implicitly.(IP E, IP G)

• The differentiation against competing companies can be achieved with the criteriaskill, price or time.(IP E)

On prototyping

• A prototype is built to examine a certain aspect of the software, e.g. to showdifferent possible solutions.(IP B, IP C)

• For simple things, such a simple prototype using tools like Word or Excel are veryapplicable. When the customer creates a prototype, this will raise costs as wellas if this was assigned to the contractor, but the important question is, whetherthe money is taken out of the company to pay for a service or whether the moneyremains in the company. IP A explains the Ehda principle: The manager thinksthe employee is ’eh da’ (anyhow at work) and can therefore do the work.(IP A)

• A good idea is to build a prototype at the beginning of the project and to presentit not only to the customer but also to the users. This has the advantage that theuser can see from early on how the later software will look like.(IP B, IP C)

• A prototype is a very useful means because it can show some aspects better thanpainted screens can. Additionally, it is important during the development phase toprovide an idea of the system, apart from a tracer bullet, to be able to react in an

87

Interview Extracts

early stage, if the software is not, what the customer expected.(IP F)

• The problem with throw–away prototypes is that the customer does not understandwhy the prototype cannot be used for further development, at least it seems to betoo expensive.(IP B)

On project management and communication

• The project management is expected to ensure that usability is met in a project,this task may be assigned to somebody or done by the project manager. Ideally,in early phases of the project, a person who has experience with usability shouldreview the software to make usability proposals.(IP B)

• When a new project is set up, the team members are chosen due to their skills andavailability. No usability specialists are in the development team, Hence, this is nota skill at the disposal when grouping the project team.(IP G)

• One of the project manager’s tasks is to allocate work packages to developers ac-cording to their skills. Another task is to ensure communication between teammembers.(IP C)

• Customer and user are different roles. Conflicts may arise if the users want addi-tional features and the customer does not want to pay for them. Then it is the taskof the project manager to negotiate with the customer to prioritize the requests.(IP F)

• The main task of a project manager is to communicate with the customer and toenable the development team to do the work with a maximum of information anda minimum of disturbance.(IP F)

• Communication between project members is very individual. This depends on theproject manager. A good concept is to have a project manager for the whole projectand a technical project manager for the development.(IP A)

• An important success factor for projects is to ensure a good communication betweenthe team members.(IP A, IP C, IP F)

88

Appendix

On development process

• There is no defined software development process. In some projects, an iterativeapproach is used, i.e., the work is split into work packages. Each package is acceptedby the customer separately.(IP B, IP C)

• The customer prescribes the development process and plans the project togetherwith the contractor. The development team tried to use other development process,but those were refused by the customer who prefers a waterfall model.(IP D)

• Development is not related to usability. In projects, these questions are not dis-cussed, because the requirements specification is written by the customer.(IP D)

• The team’s evaluation of the design contains two aspects: one is a very subjectivematter. The design is a matter of taste. This evaluation is done before the software isused and is concerned with design details like buttons. The second aspect deals withusability and appears when the software is used. When the developers think thatthe software is difficult to use, this is always a point to discuss with the customer.(IP B)

On usability education

• Usability was not mandatory in university studies.(All interviewees)

• I took a course/lecture voluntarily.(IP B, IP C, IP D)

• Being a user of several applications fosters an understanding of what is usable andwhat is not.(IP B)

On miscellaneous

• It is important to establish standards and that this is not done during currentprojects.(IP A, IP B)

• Trainings are not offered by the managers, although this is often defined in annualemployee talks. Most of the developers improve their knowledge in learning newtechnologies in their spare time.(IP B, IP D)

89

Interview Extracts

• Trainings may be offered, if a certain skill is needed for a project.(IP E)

90

SDP Details

At first, an overview of projects is given in terms of its size. According to the size of aproject, the numbers of iterations in each phase is determined in table A.1. For example,a medium sized project with a project time of four to six month and a number of teammembers of three to four will have one iteration in the Inception phase, two iterationseach in the Elaboration phase and Construction phase and one iteration in the Transitionphase.

The roles for the SDP consists of 25 roles instead of the 30 roles proposeed by the RUP,whereas many roles were omitted, a few were newly invented and the generic RUP role’reviewer’ was divided into reviewers for specific cases. An alphabetical enumeration isgiven in table A.21. The activities are listed in table A.3, the artifacts are collected intable A.4 on page 96

Project Size Project Time No. of team No. of iterations(in month) members (for each phase)

Small 2-3 2-3 [1, 1, 1, 1]Medium 4-6 3-4 [1, 2, 2, 1]Large 7-9 4-6 [1, 3, 3, 2]Very Large 10+ 6+ [2, 4, 4, 3]

Table A.1: Iterations in SDP

Role Description

Architecture Reviewer Planning and conducting of formal architecture reviewsChange Control Manager Control of the change management within a projectConfiguration Manager Providing infrastructure for the change management and

control of releasesCustomer Accepting the bid and formal accepting the project resultDatabase Designer Design databaseDeployment Manager Planning and conducting of the deployment in a test or

productive environmentContinued overleaf.

1Workflow is a synonym for discipline

91

SDP Details

Continued.Role Task DescriptionDesigner Definition of responsibilities, operations, attributes and

relations of process elementsDesign Reviewer Planning and conducting of formal reviews of the system

designEnd User Using the functionalities of the new systemImplementer Implementing and testing of the elements in the system

designImplementation Reviewer Planning and conducting of formal implementation re-

viewsFramework Architect Extension and maintenance of the SofTec framework.

This framework was build by the company itself and isused and extended in ongoing projects.

Project Manager Planning, controlling and regulation of project resourcesand project progress and coordination of communicationwith customers and users

Project Reviewer Planning and conducting formal reviews of projectprogress

Requirements Reviewer Planning and conducting formal requirements reviewsRequirements Specifier Noting detailed requirementsSoftware Architect Management and coordination of the basic architecture,

the key elements and interfacesSystem Administrator Providing and maintenance of hardware and software for

the project teamSystem Analyst Noting the functionalities and the scope of the system on

behalf of the requirements specificationTechnical Writer Creation of technical documents, e.g. the user’s manualTest Designer Definition of test scenarios and appropriate techniques

and guidelines to conduct the testsTester Implementing, conducting and analysis of function tests,

integration tests and system testsTool Specialist Procurement and installation of development toolsUser–Experience Designer Definition of user interactions, dynamic contents and nav-

igation routes of all screens and definition of their imple-mentation

User–Experience Re-viewer

Planning and conducting formal reviews of user experi-ence

Table A.2: Roles in SDP

92

Appendix

Workflow Workflow Details Activity

Requirements Define the system • Capture a common vocabulary• Find actors and use cases• Prioritize use cases• Review the requirements

Refine the system • Detail use casesDefinition • Structure the use case model

• Review the requirementsAnalysis Define an initial • Architectural analysis

architecture • Review the architecture

Analyze behaviour • Model the user experience• Review the user experience• Use case analysis• Review the analysis

Design Refine the • Identify design mechanismsarchitecture • Identify design elements

• Identify existing design elements• Describe distribution and concurrency• Review the architecture

Detail the design • Use-Case design• Subsystem design• EJB design• Class design• Database design• Review the design

Implementa- Structure the imple- • Structure the implementation modeltion mentation model • Review the implementation

Implement design • Implement design elementselements • Perform unit test

• Review the implementationTest Prepare test • Identify targets of test

• Define test details

Test and evaluate • Implement test• Perform test

Deployment Plan deployment • Develop deployment plan

Perform deployment • Assemble and deploy productcontinued overleaf.

93

SDP Details

Continued.Workflow Workflow Details Activity

• Manage acceptance tests• Develop support materials

Configuration Manage • Set up CM environment& Change configurations • Manage versions and baselinesManagement

Manage change • Submit change requestRequests • Review change request

Project Initialize project • Identify and assess risksManagement • Measure costs and effort

• Initiate project• Develop software development plan• Project approval review• Project planning review

Manage iteration • Monitor and control project• Plan next iteration• Assess iteration• Iteration acceptance review• Iteration planning review

Close out phase • Prepare for close out• Lifecycle milestone review

Environment Support environment • Select and acquire tools• Set up tools• Support development

Prepare Guidelines • Develop use case modelling guidelines• Develop user experience guidelines• Develop design guidelines• Develop implementation guidelines• Develop programming guidelines• Develop test guidelines

Table A.3: Activities in SDP

94

Appendix

Artifact Description

Bug Report Description of an erroneous software part, which will beinserted into a bug control system

Business Case Evaluation of economic efficiencyChange Request Description of a change requestData Model Logic and physic database descriptionDeployment Environment Environment for test and productionDeployment Model Model for configuration in deployment environmentDeployment Plan Time and process plan for deliveryDesign Guidelines Project specific guideline for system and database designDesign Model Description of all use cases in terms of analysis classes,

sub systems, J2EE elements, interfaces and the likeDevelopment Structure Hardware and software environment for developmentGlossary Description of all important notions in the project contextImplementation Model Summary of all artifacts for system managementJ2EE Framework Archi-tecture Document

Description of the framework, architecture and compo-nents

J2EE Component Framework componentJ2EE Framework Framework with its components and control functionsProduct Acceptance Plan Description of the acceptance criteriaProgrammers Guidelines Guideline for programmingProject Measurements Classification numbers to measure project progressProject Repository Repository for all project relevant documents, which can

be assessed by every team memberSoftware Architecture Description of the software architectureSoftware DevelopmentPlan

Comprises time plan, milestones, resources, and otherproject management elements

Status Assessment Result summary of a phase’s iterationSupplementary Specifica-tion

Description or non–functional requirements

System Manual Technical system descriptionTest Case Formal description of a test scenario, including parame-

ters, pre– and post–conditionsTest Guidelines Guideline for implementing of tests in generalTest Plan Description of test object and test goalsTest Script Step–wise instructions to conduct a testTools Tools to support development, e.g. UML toolsUse-Case Model Model of use cases to describe interaction with the systemUse-Case ModellingGuidelines

Guidelines for use case modelling

Use-Case Priority Priority list for use casesUser Manual System description for users

Continued overleaf.

95

SDP Details

Continued.Artifact DescriptionUser Experience Guide-lines

Guidelines to design and implement user experience

User Experience Model Abstract description of the user interface, comprisingstory boards and screens

User Experience Proto-type

Prototype of the user interface

Vision Description of the problem and the functions, which cansolve it

Table A.4: Artifacts in SDP

96

Glossary

Audit Like a review (cf. below), additionally containing proposals to solve the foundproblems

Design ”(i) The process of developing a product, artifact or system; (ii) a representation(simulation) of the product” ([Preece et al. 1994, glossary])

Design Model ”The designers’ conception of the system (how it should be represented,what interface it should have and how it should behave, etc.)” ([Preece et al. 1994,glossary])

Evaluation ”A process though which information about the usability of a system isgathered in order to improve the system or to asses a completed interface”([Preece et al. 1994, glossary])

Evaluation Method A procedure for collecting relevant data about the operation andusability of a computer system

Feasibility Study ”A study undertaken to assess whether something is achievable: thisincludes assessing economic, financial, human resource and technological fac-tors (and may include ecological and social factors as well) that will influencewhether something can be achieved and at what costs and to what benefit”([Field and Keller 1998, glossary])

Going Live The going live is the last step of a project. The new software is integratedinto the intended environment after it was tested in a test environment. This is thepoint, when users can start to use the software productively.

GUI Graphical User Interface

HCI Human–Computer Interaction; synonym: computer–human interaction (CHI), hu-man factors, usability

Heuristic evaluation ”A heuristic evaluation is probably the best method with whichto achieve a quick and relatively coarse usability input into a project because ittends to uncover many potential user problems in a short period of time and withcomparatively little effort.” ([Lindgaard 1994, p. 120])

HTML Hypertext Markup Language, used to create internet pages

97

Glossary

Human Factors see HCI

Implementation ”The process of programming and creating a software system”([Preece et al. 1994, glossary])

Individual Software Software developed for a determined purpose and a single customeror a small group of customers; see also standard software

ISO International Standardization Organization, provides standards on several subjects,e.g. 9241 and DIN 13407 on usability

Java A programming language (see http://java.sun.com)

J2EE Java 2 Enterprise Edition, an ample Java Package to develop complex businessapplications (see http://java.sun.com)

Milestone ”An event selected for its importance in the project”([Field and Keller 1998, glossary]); for the RUP: ”The point at which aniteration or phase formally ends; corresponds to a release point” ([Kruchten 2004,glossary]) In general, it is used to determine project progress.

Project Organized work towards a pre–defined gol and a pre–defined end

Prototype ”An experimental incomplete design of an application used for testing ideas;a horizontal prototype illustrates all of the user interface but has hardly any func-tionality; a vertical prototype contains both high–level and low–level functionalitiesbut for a restricted part of the system” ([Preece et al. 1994, glossary])other forms include throw-away, paper and pencil; see section 3.3.2

Review Process of evaluating the outcome of a process, e.g. a user interface or a code ofa module.

Role ”A definition of the behaviour and responsibilities of an individual or a set of indi-viduals working together as a team.” ([Kruchten 2004, glossary])

Requirement ”A description of a condition or capability of a system; either deriveddirectly from user needs or stated in a contract, standard, specification, or otherformally imposed document.” ([Kruchten 2004, glossary])

Requirements Analysis ”The investigation of a situation which focuses on what is re-quired but not on how to provide it” ([Preece et al. 1994, glossary])

Requirements Specification ”In requirements specification, the designer and customertry to capture a description of what the eventual system will be expected to pro-vide. [...] The transformation from the expressive but relatively ambiguous naturallanguage is one key to successful development.” ([Dix et al. 1998, p. 181])

98

Appendix

Screen A screen is a snapshot of an application, it comprises what the monitor displaysat once. A screen has a layout in that is has a design and interaction elements.Interaction elements include text fields and buttons.

Screen Flow A screen flow defines the flow of the screens. It prescribes what screen isshown next under what conditions, e.g. ”pressing the ok button will call the resultlist screen screen”. This can be shown concise in a diagram.

Stakeholder ”Any person or representative of an organization who has a stake –a vestedinterest– in the outcome of a project or whose opinion must be accommodated. Astakeholder can be an end user, a purchaser, a contractor, a developer, or a projectmanager.” ([Kruchten 2004, glossary]) [Dix et al. 1998] distinguish four levels:

1. Primary: those, who use the system

2. Secondary: those, who do not use the system directly, but receive output fromit or provided input to it

3. Tertiary: those, who do not fall into 1 or 2, but who are affected by thesuccess or failure of the system (for example directors, whose profits increaseor decrease depending on the success or failure of the system

4. Facilitating: those, who are involved with design, development and mainte-nance of the system

Rupp points out that stakeholders can be abstract persons like ’the law’ or a groupof persons like ’manager’. Additionally, as important as the stakeholders above arethose who do not like to have the intended system. [Rupp 2002])

Standard Software software produces for an undefined user group offering support for agroup of tasks, e.g. text processing software; see also individual software

Style Guide ”A collection of design principles and rules which can be used to develop con-sistent user interfaces across a family of applications” ([Preece et al. 1994, glos-sary])

Swing Java package for user interfaces

Systems Specification ”A document that clarifies a client’s requirements in an unam-biguous form by respectifying the requirements and distinguishing between sys-tem functions and the constraints that a software developer has to work under”([Preece et al. 1994, glossary])

Task Allocation ”Deciding which activities are to be carried out by humans and whichby computers” ([Preece et al. 1994, glossary])

Task Analysis ”The process of investigating a problem by breaking down tasks [...] intosequences of actions and objects” ([Preece et al. 1994, glossary])

Tests Tests are conducted for different reasons. Important test are:

99

Glossary

• Unit Test tests, if a software module provides the intended functionality

• Load Test tests, how a software and the environment behaves, if the max-imum of load is produced, i.e., the maximum of users conducting the mostintensive operations in terms of processing time, memory or often use of inter-faces to database systems or the like

• Stress Test similar to the load test, but with a load that exceeds the expectedmaximum

• Performance Test tests the performance of specified functions, e.g. howlong a database query takes that produces a result of 100 entries.

• Acceptance Test tests, if the acceptance criteria are met.

Traceability ”Recording information that will allow any investigation to reconstructevents, changes and reasons for change” ([Field and Keller 1998, glossary])

Tracer Bullet ”A tracer bullet is a sample code that shows the feasibility of a technicalsolution.” ([Hunt and Thomas 2000, p. 48ff.])

UCD User centred Design. ”an approach which views knowledge about users and theirinvolvement in the design process as a central concern” ([Preece et al. 1994, glos-sary])

Use Case ”A sequence of actions a system performs that yields an observable result ofvalue to a particular actor.” ([Kruchten 2004, glossary])

Use Case Diagram A use case diagram shows several interactions of a user with theintended system. It provides information on what the system does and which usersare involved in this task.

User interface ”The way that you accomplish tasks with a product –what you do andhow it responds– that’s the interface.” [Raskin 2000, p. 3]

User Model ”The researchers’ or designers’ description of the users and their predictionof how the users will behave and perform tasks” ([Preece et al. 1994, glossary])

UML Unified Modelling Language, a formal language for software modelling

Work Flow ”The sequence of activities performed in a business that produces a result ofobservable value to an individual actor of the business.” ([Kruchten 2004, glos-sary])

100

Bibliography

[Ackermann and Ulich 1991] Ackermann, D. and E. Ulich (eds.) (1991).Software–Ergonomie ’91 . B. G. Teubner, Stuttgart.

[Ansorge et al. 2004] Ansorge, Peter, G. Frick, J. Friedrich andU. Haupt (2004). ”Ergonomie gepruft” – Das Ende der Benutzungsprobleme? .http://www.akziv.com/Dokumente/Ansorge Frick Friedrich Haupt 1999 Ergonomiegeprueft.pdf). Last Visit: May 1, 2004.

[Balzert 1994] Balzert, Helmut (1994). Integration der Software–Ergonomie in dieSoftware–Entwicklung . In: [Eberleh et al. 1994], p. 407–432.

[Balzert 1998] Balzert, Helmut (1998). Lehrbuch der Software–Technik. Software–Management Software–Qualitatssicherung Unternehmensmodellierung . SpektrumAkademischer Verlag, Heidelberg.

[Balzert 2000] Balzert, Helmut (2000). Lehrbuch der Software–Technik. Software–Entwicklung . Spektrum Akademischer Verlag, Heidelberg 2. Ed.

[Beck 1993] Beck, Astrid (1993). Benutzerpartizipation aus Sicht von SW–Ent-wicklern und Benutzern. In: [Rodiger 1993], p. 263–274.

[Beyer and Holtzblatt 1998] Beyer, Hugh and K. Holtzblatt (1998). Contex-tual Design. Morgan Kaufman Publishers, San Francisco.

[BildschArbVO 1996] BildschArbVO (1996). Bildschirmarbeitsverord-nung. Verordnung uber Sicherheit und Gesundheitsschutz bei der Arbeit anBildschirmgeraten vom 20.12.1996 . http://www.sozialnetz-hessen.de/ergo-online/recht/Bilscharbv/bilscharbv.htm Last Visit: Jan 9, 2004.

[Bortz and Doring 2002] Bortz, J. and N. Doring (2002). Forschungsmethoden undEvaluation. Springer Verlag, Berlin Heidelberg 3. Ed.

[Brodbeck 1991] Brodbeck, Felix (1991). Fehlerbewaltigungsdauer und die Nutzungvon Unterstutzungsmoglichkeiten. In: [Frese and Zapf 1992], p. 80–94.

[Brodbeck 1993] Brodbeck, Felix (1993). Warum es sinnvoll ist, Kommunikationund Kooperation in Software–Entwicklungsprojekten verstarkt zu kultivieren: Ergebnisseaus einer empirischen Untersuchung . In: [Rodiger 1993], p. 237–248.

101

Bibliography

[Brossler and Siedersleben 2000] Brossler, Peter and J. Siedersleben (eds.)(2000). Softwaretechnik . Hanser, Munchen Wien.

[Carrasco and Whiteside 1990] Carrasco, Jane and J. Whiteside (eds.) (1990).Human Factors in Computer Systems. Empowering People. acm Press.

[Chapanis 1991] Chapanis, Alphons (1991). Evaluating Usability . In:[Shackel and Richardson 1991], p. 359–359.

[Constantine 2001] Constantine, Larry L. (2001). The Peopleware Papers . Your-don Press, New Jersey.

[Cooper 1999] Cooper, Alan (1999). The Inmates are Running the Asylum. Sams,Indianapolis.

[Diaper et al. 1990] Diaper, D., D. Gilmore, G. Cockton and B. Shackel (eds.)(1990). Human–Computer Interaction INTERACT IFIP. Camebridge, U.K. KluwerAcademinc Publishers.

[DIN 69901 1987] DIN 69901 (1987). Projektmanagement .

[DIN prEN ISO 13407 1997] DIN prEN ISO 13407 (1997). Benutzer–orientierteGestaltung interaktiver Systeme.

[Dix et al. 1998] Dix, Alan J., J. E. Finlay, G. D. Abowd and R. Beale (1998).Human–Computer Interaction. Prentice Hall Europe.

[Doremann and Meyer 2003] Doremann, Holger and R. Meyer (2003). An-forderungsmanagement kompakt . Spektrum Verlag, Heidelberg.

[Dunn 1993] Dunn, Robert H. (1993). Software–Qualitat . Carl Verlag, Munchen.

[Dzida et al. 2001] Dzida, W., B. Hofmann, R. Freitag, W. Redtenbacher,R. Baggen, T. Geis, J. Beimel, C. Zurheiden, W. Hampe-Neteler,R. Hartwig and H. Peters (2001). ERGONorm. Gebrauchstauglichkeit von Soft-ware. Bundesanstalt fur Arbeitsschutz und Arbeitsmedizin.

[Dzida 2002] Dzida, Wolfgang (2002). DATech Usability Tests fur Produkte undProzesse. i–com. Zeitschrift fur interaktive und kooperative Medien. 01/2002: p. 52–53.

[Earthy 1998] Earthy, J. (1998). Usability Maturity Model . www.ipo.tue.nl/homepages/mrauterb/lecturenotes/USability-Maturity-Model%5B1%5D.PDF. Last Visit:May 01, 2004.

[Eberleh et al. 1994] Eberleh, E., H. Oberquelle and R. Oppermann (eds.)(1994). Einfuhrung in die Software–Ergonomie. de Gruyter, Berlin.

[Engelberg and Seffah 2002] Engelberg, Daniel and A. Seffah (2002).A Framework for Rapid Mid–Fidelity Prototyping of Web Sites . In:[Hammond et al. 2002], p. 203–215.

102

Appendix

[Fetz and Day 1990] Fetz, Bruce H. and M. C. Day (1990). User in-terface and quality planning department – AT&T Bell Laboratories . In:[Carrasco and Whiteside 1990], p. 83–84.

[Field and Keller 1998] Field, Mike and L. Keller (1998). Project Management .International Thompson Business Press, London Boston.

[Flick 1998] Flick, Uwe (1998). Qualitative Forschung . Rowohlt Taschenbuch VerlagGmbH.

[Floyd et al. 1989] Floyd, Christiane, F.-M. Reisin and G. Schnidt (1989).STEPS to Software Development with Users . In: [Ghezzi and McDermid 1989], p.48–64.

[Foote 2003] Foote, Doug (2003). Introducing the RUP buffet . http://www-106.ibm.com/developerworks/rational/library/975.html. Last Visit: Jan 29, 2004.

[Frese et al. 1991] Frese, M., C. Kasten, C. Skarpelis and B. Zang-Scheucher(eds.) (1991). Software fur die Arbeit von morgen. Springer, Berlin.

[Frese and Zapf 1992] Frese, Michael and D. Zapf (eds.) (1992). Fehler beider Arbeit mit dem Computer: Ergebnisse von Beobachtungen und Befragungen imBurobereich. Huber, Bern.

[Gentner and Grudin 1990] Gentner, Donald R. and J. Grudin(1990). Why Good Engineers (Sometimes) Create Bad Interfaces . In:[Carrasco and Whiteside 1990], p. 277–282.

[Ghezzi and McDermid 1989] Ghezzi, C. and J. A. McDermid (eds.) (1989). Lec-ture Notes in Computer Science, ESEC ’89 . Springer, Berlin.

[Gillan and Breedin 1990] Gillan, Douglas J. and S. D. Breedin(1990). Designer’s Models of the Human–Computer Interface. In:[Carrasco and Whiteside 1990], p. 392–398.

[Hammond et al. 2002] Hammond, Judy, T. Gross and J. Wesson (eds.) (2002).IFIP 17th Computer Congress: Usability. Gaining a Competitive Edge Montreal,Quebec, Canada. Kluwer Academic Publishers.

[Hartson and Hix 2000] Hartson, H. Rex and D. Hix (2000). Introduction toHuman–Computer Interaction. Department of Computer Science, Virginia Tech,Blacksburg.

[Helander et al. 1997] Helander, M. T., T. K. Landauer and P. P. V. Prabhu(eds.) (1997). Handbook of Human Computer Interaction. Elsevier 2. Ed.

[Hunt and Thomas 2000] Hunt, Andrew and D. Thomas (2000). The PragmaticProgrammer . Addison–Wesley, Boston.

103

Bibliography

[Ince 1995] Ince, Darrel (1995). Software Quality Assurance. A students introduction.McGraw–Hill, London.

[Incent 2003] Incent (2003). Contextual Design – Overview . http://www.incent.com/cd/cdhow.html. Last Visit: Mar 15, 2003.

[ISO 9241 1996] ISO 9241 (1996). Ergonomic requirements for office work with displayterminals .

[ISO 9241-10 1998] ISO 9241-10 (1998). Ergonomic requirements for office work withdisplay terminals: Dialog Principles .

[ISO 9241-11 1998] ISO 9241-11 (1998). Ergonomic requirements for office work withdisplay terminals: Guidance on usability .

[ISO 9241-4 1998] ISO 9241-4 (1998). Ergonomic requirements for office work with dis-play terminals: Keyboards .

[Jozwicka-Braun 2000] Jozwicka-Braun, Karina (2000). Prototypen. In:[Brossler and Siedersleben 2000], p. 83–93.

[Karat 1997] Karat, Claire-Marie (1997). Cost-Justifying Usability Engineering inthe Software Lifecycle. In: [Helander et al. 1997], p. 767–778.

[Klotz 1991] Klotz, Ulrich (1991). Softwaredesign ist (mehr als) Arbeitsgestaltung .In: [Frese et al. 1991], p. 449–460.

[Knoll et al. 1996] Knoll, Heinz-Dieter, T. Slotos and W. Suk (1996). Entwick-lung und Qualitatssicherung von Anwendungssoftware. Springer, Heidelberg.

[Kotonya and Summerville 1997] Kotonya, Geralf and I. Summerville (1997).Requirements Engineering . John Wiley Editorial Offices, New York.

[Kruchten 2004] Kruchten, Philippe (2004). The Rational Unified Process. An In-troduction. Object Technologies Series. Addison Wesley, Boston.

[Lewis et al. 1990] Lewis, Clayton, P. Polson, C. Wharton and J. Rieman(1990). Testing a Walkthrough Methodology for Theory–Based Design of Walk–Up–and–Use Interfaces . In: [Carrasco and Whiteside 1990], p. 235–242.

[Lindgaard 1994] Lindgaard, Gitte (1994). Usability Testing and System Evalua-tion. Chapman & Hall, London.

[Lindgaard 2002] Lindgaard, Gitte (2002). Deconstructing Silos . In:[Hammond et al. 2002], p. 4–20.

[Mayhew 1999] Mayhew, Deborah J. (1999). The Usability Engineering Lifecycle.Morgan Kaufmann Publishers.

104

Appendix

[McCoy 2002] McCoy, Thomas (2002). Usability: Who cares? . In:[Hammond et al. 2002], p. 283–294.

[Nielsen 2003a] Nielsen, J. (2003a). Return on Investment for Usability .http://www.useit.com/alertbox/20030107.html. Last Visit: Dec 02, 2003.

[Nielsen and Gilutz 2003] Nielsen, J. and S. Gilutz (2003). Usability Return onInvestment . http://www.nngroup.com/reports/roi/ Last Visited: Dec 25, 2003.

[Nielsen and Landauer 1993] Nielsen, J. and T. Landauer (1993). MathematicalModel of the Finding of Usability Problems . p. 206–213. Proc. INTERCHI 1993.

[Nielsen and Mack 1994] Nielsen, J. and R. Mack (1994). Usability InspectionMethods . John Wiley & Sons, New York.

[Nielsen 1990] Nielsen, Jakob (1990). Paper versus Computer Implementation asMockup Scenarios for Heuristic Evaluation. In: [Diaper et al. 1990], p. 315–320.

[Nielsen 2003b] Nielsen, Jakob (2003b). Usability 101 . http://www.useit.com/alertbox/20030825.html. Last Visit: Dec 02, 2003.

[Nielsen and Molich 1990] Nielsen, Jakob and R. Molich (1990). Heuristic Eval-uation of User Interfaces . In: [Carrasco and Whiteside 1990], p. 249–256.

[Norman 1990] Norman, Donald A. (1990). The Design of Everyday Things . Cur-rency Doubleday, New York (Reprint).

[Oivo and Komi-Sirvio 2002] Oivo, Markku and S. Komi-Sirvio (eds.) (2002).Product Focused Software Process Improvement . Springer, Berlin.

[Ortlieb and Holz auf der Heide 1993] Ortlieb, Sybille and B. Holz auf derHeide (1993). Benutzer bei der Software–Entwicklung angemessen beteiligen. Erfahrun-gen und Ergebnisse mit verschiedenen Konzepten. In: [Rodiger 1993], p. 249–261.

[Preece et al. 1994] Preece, Jenny, Y. Rogers, H. Sharp, D. Benyon, S. Hol-land and T. Carey (eds.) (1994). Human–Computer Interaction. Addison Wesley.5. Reprint (1997).

[Pressman 1992] Pressman, R. S. (1992). Software Engineering. A Practitioner’s Ap-proach. McGraw–Hill.

[Raskin 2000] Raskin, Jef (2000). The Humane Interface. Addison–Wesley Profes-sional.

[Rodiger 1993] Rodiger, Karl-Heinz (ed.) (1993). Software–Ergonomie ’93 . B. G.Teubner, Stuttgart.

[Rosson and Carroll 2002] Rosson, Mary Beth and J. M. Carroll (2002). Us-ability Engineering. Scenario–Based Development of Human–Computer Interaction.Morgan Kaufmann Publishers.

105

Bibliography

[Rudloff and Becker-Topfer 1997] Rudloff, Christiane and E. Becker-Topfer (1997). Software–Ergonomie und Arbeitsgestaltung. Ein Arbeitsheft uberGestaltungsmoglichkeiten computergestutzter Arbeitssysteme. Gemeinnutzige hbv–Kommunikations–, Bildungs– und Verlagsgesellschaft.

[Rupp 2002] Rupp, Chris (2002). Requirements–Engineering und –Management . CarlHanser Verlag, Munchen 2. Ed.

[Shackel and Richardson 1991] Shackel, B. and S. J. Richardson (eds.) (1991).Human Factors in Informatics Usability . Cambridge University Press.

[Shneiderman 1998] Shneiderman, Ben (1998). Designing the User Interface. Addi-son Wesley Longman Inc., Reading 3. Ed.

[SofTec 2003] SofTec (2003). SofTec RUP Process Reference. Internal Paper.

[Spinas and Waeber 1991] Spinas, Philip and D. Waeber (1991). Benutzerbeteili-gung aus der Sicht von Endbenutzern, Softwareentwicklern und Fuhrungskraften mitBeteiligungserfahrung . In: [Ackermann and Ulich 1991], p. 36–45.

[Stewart 1991] Stewart, T. (1991). Helping the IT Designer to Use Human Factors .In: [Shackel and Richardson 1991], p. 97–119.

[Unknown 2003] Unknown (2003). No title. I found this poster at a wall at the de-partment of computer science, University of Hamburg. (English translation in bracketsprovided by me).

[Wagner 2000] Wagner, Heike (2000). Kosten und Nutzen benutzergerechter Soft-ware. Studienarbeit, Universitat Hamburg, Fachbereich Informatik.

[Wong and Jeffery 2002] Wong, Bernhard and R. Jeffery (2002). A Frameworkfor Software Quality Evaluation. In: [Oivo and Komi-Sirvio 2002], p. 103–118.

106