AALBORG UNIVERSITYDEPARTMENT OFCOMPUTER SCIENCE

Frederik Bajers vej 7E DK-9220 Aalborg Ø Phone 96 35 80 80

TITLE : MuKuFoTHEME: Design and Evaluation of Computerized Systems in Collaboration with UsersPROJECT DURATION: Inf2, 4th semester, Februrary 2005 until May 2005PROJECT GROUP: i402a

PARTICIPANTS:

Niels Wittrup Andersen_____________________

Rasmus Eriksen_____________________

Morten Holst_____________________

Ole Kallehave_____________________

Kasper Vestergaard Pedersen_____________________

Nino Tiainen_____________________

SUPERVISOR:Linas Bukauskas

Synopsis

In this report we describe how we, in cooperation

with Projekt F, created MuKuFo, a web based ap-

plication for coaches, leaders, and anyone dealing

with organizations with members of various nation-

alities. We designed the system using eXtreme Pro-

gramming, which we found insufficient for our situa-

tion. Therefore we decided to combine it with paper

prototyping and usability testing. We discuss the rel-

evance of combining these methodologies and some

of the reasons and consequences of the choices we

made. We conclude that it is beneficial to combine

eXtreme Programming with both prototyping and us-

ability testing, and that the need for usability testing

exists, when working with a broad variation on end

users.

NUMBER OF COPIES: 9NUMBER OF PAGES: 111PAGES IN APPENDIX: 17FINISHED: May 27th 2005

This report can not be published or reproduced without permission from the project group.Copyright c© 2005, group i402a, Aalborg University.

Contents

Part I - The problem 9

1 Problem 11

1.1 Problem Formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 11

1.2 Problem Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . 11

1.2.1 Challenging Existing Methods . . . . . . . . . . . . . . . . . . . .. . . . . 11

1.2.2 The Need For Adjustment . . . . . . . . . . . . . . . . . . . . . . . . . .. 11

1.2.3 The Need for MuKuFo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Part II - Practical Circumstances 13

2 Choice Of Methodology 15

2.1 Reasons And Consequences . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 15

2.2 Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . 17

3 Choice Of Programming Language 19

3.1 Reasons and consequences . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 19

3.2 Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . 20

Part III - Methodology 21

4 eXtreme Programming 23

4.1 Spikes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

4.2 User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 23

4.2.1 Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2.2 The Planning Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

4.2.3 Metaphor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2.4 Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

4.3 Pair Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . 25

4.3.1 Switching Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

4.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 26

1

CONTENTS

4.4.1 Acceptance Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

4.4.2 Unit Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.5 Iterations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 27

4.6 Our Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 27

4.6.1 Spikes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.6.2 User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

4.6.3 Pair Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

4.6.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.6.5 Iterations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

5 Paper Prototyping 31

5.1 Our Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 31

6 Heuristics 33

6.1 Our Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 34

7 Usability Testing 35

7.1 Testing Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 35

7.1.1 Test Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7.1.2 Data Logger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7.1.3 Test Observers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36

7.2 Test Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 37

7.2.1 Test Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 37

7.3 Test Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . 38

7.4 Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 38

7.5 Our Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 39

7.5.1 Test Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

7.5.2 Test Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

7.5.3 Test Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 40

7.5.4 Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

Part IV - Product Development 43

8 Overall Flow Of The Project 45

8.1 Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 45

8.2 The programming phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . 46

8.3 The writing phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . 50

9 The customer 51

9.1 Customer Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 51

9.1.1 The Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

2

CONTENTS

9.1.2 The Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

9.2 Customer Cooperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 52

9.2.1 Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

9.2.2 Wishes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

10 External Partners 55

10.1 Web Hotel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 55

10.2 Interpreters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 55

11 Paper Prototyping 57

11.1 Relevance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 57

11.2 Actual Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . 57

12 Usability Test 61

12.1 Relevance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 61

12.2 Release Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . 61

12.2.1 Test Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62

13 User Stories 63

13.1 Designing The User Stories . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 63

13.2 Estimating Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 65

14 Iterations 67

14.1 Short Description Of The Final Product . . . . . . . . . . . . . .. . . . . . . . . . 67

14.2 First Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 69

14.2.1 User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 69

14.2.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

14.2.3 Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

14.2.4 Client Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 71

14.3 Second Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 72

14.3.1 User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 72

14.3.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

14.3.3 Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

14.3.4 Client Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 75

14.4 Third Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 75

14.4.1 User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 75

14.4.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

14.4.3 Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

14.4.4 Client Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 78

14.5 First Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 78

14.5.1 Participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 79

3

CONTENTS

14.5.2 Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 79

14.6 Fourth Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 83

14.6.1 User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 83

14.6.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

14.6.3 Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

14.6.4 Client Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 85

14.7 Second Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . 85

14.7.1 Participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 85

14.7.2 Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 85

14.8 Fifth Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 87

14.8.1 User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 87

14.8.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

14.8.3 Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

14.8.4 Client Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 90

15 Final Product Description 91

15.1 Front Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 91

15.1.1 Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

15.1.2 Text Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

15.1.3 Document Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92

15.1.4 Login Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

15.1.5 Help Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92

15.1.6 Footer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

15.2 Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 93

15.2.1 Toolbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

15.2.2 Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

15.2.3 Working Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94

15.3 Translated Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 94

15.3.1 Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

15.3.2 Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

15.4 About MuKuFo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 96

15.5 Document Select . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . 96

15.5.1 Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

15.5.2 Displayed Documents . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 98

15.6 Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98

Part V - Reflections 99

16 Discussion 101

16.1 Customer Availability . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 101

4

CONTENTS

16.2 Combining XP With User Testing . . . . . . . . . . . . . . . . . . . . .. . . . . . 102

16.3 XP In An Academic Context . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 103

16.3.1 Limited Time For Development . . . . . . . . . . . . . . . . . . . .. . . . 103

16.3.2 Pair Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 103

16.4 XP And Software Philosophy . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . 103

16.4.1 XP And Complete Estimations . . . . . . . . . . . . . . . . . . . . .. . . . 103

16.4.2 More Than A Romantic Approach . . . . . . . . . . . . . . . . . . . .. . . 105

17 Conclusion 107

18 Perspective 109

18.1 User Tests And XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 109

18.2 Taking XP Further . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . 109

18.3 Perspectives For MuKuFo . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 110

Part VI - Appendix 113

A User Stories 115

B Test Assignments 121

B.1 Test of First Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 121

B.1.1 Opgave 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

B.1.2 Opgave 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

B.1.3 Opgave 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

B.1.4 Opgave 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

C Participant Questionnaire 123

C.1 Participant P1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . 123

C.2 Participant P2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . 124

C.3 Participant P3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . 125

D Paper Prototypes 127

E CD 131

5

CONTENTS

6

Introduction

According to the curriculum the main purpose of this semester project is to gainexperiencein designing and evaluating a computerized systems in collaboration with users.The goalhas been to get valuable insight into cooperating with real users outside theframework ofthe university.

To meet these guidelines we took on the assignment of developing an application in co-operation with Projekt F, an organization under Aalborg Kommune. ProjektF required anapplication to support communication between local organizations in Aalborg Kommuneand members of different ethnic groups. Roughly outlined the application should be avail-able on the Internet and able to translate documents written in Danish into Arabic, Somaliand English.

The result of our combined efforts is a highly evolved prototype developed with the use ofthe programming technologies: JSP, JavaScript, and HTML. At the current stage of devel-opment it is possible to create and translate documents using the application.

As a method for development we have used the agile method, eXtreme Programming (XP).This is a relatively new and controversial method for software development emphasizing ahigh degree of cooperation between developers and customer, which makes it particularlyinteresting in this context. This report documents the development process we have beengoing through and reflects upon XP as a method for software development.

Reading instructions

When referring to external sources throughout the report, we have used Harvard Style,where the author or authors of the material are listed first followed by the publishing year.An example of this is as follows:

[Steinberg Palmer 2004]

If the reference is listed before a full stop, it only concerns the last sentence. If the referenceis listed after a full stop, the reference concerns the whole section.

All the material referred to is listed in the Bibliography, page 111.

7

CONTENTS

8

Part I

The problem

This part describes the problem area of the project

9

Problem 1This chapter introduces the problem formulation and describes our problem area.

1.1 Problem Formulation

Our problem formulation was as follows:

How is it possible to combine XP with user tests, and doesthe need for this exist?

1.2 Problem Analysis

1.2.1 Challenging Existing Methods

The theme of this semester encouraged us, among other things, to work with user coop-eration in a development process. With that in mind we wanted to challenge an existingdevelopment method.

Obviously not all development projects are the same, and sometimes the ideal circumstancesfor even the most suited method are not met. It will then be necessary to combine the mainmethod with aspects of other development and information gathering methods, inorder toaccommodate the method to the context of the actual project.

1.2.2 The Need For Adjustment

XP contains a collection of techniques, and it is up to the user of the method to pick anduse the different practices to benefit the project. This works in most cases, and the outcomewill reflect how well the method has been put together and used. Generallythis will workwithout problems, however in cases where additional areas needs coverage, problems arise.

11

1.2 Problem Analysis

These problems can be solved by including secondary methods that describe how to solvethe given problem.

In this report we will take a closer look at what can be done, when the customer in an XPdevelopment process is not sufficiently capable of representing the interests of all groups ofend users.

The system requested by Projekt F is intended for being used by a wide range of sportscoaches, organization heads, and coordinators of minor clubs and political organizations,all with different levels of computer knowledge and different needs concerning the system.All these needs should be taken into consideration, and the system should furthermore beintuitive to use for all users.

Another aspect of the problem is that the output of the system will be translated documents,that needs to be correct, thus requiring verification. This leaves the customer incapable ofrepresenting the whole spectrum of possible end users, and examine whether these criteriahas been satisfied.

Due to this situation we decided to involve other methods, that in some way would supportXP on these areas. The choices of methodology we made will be described inChapter 2.

1.2.3 The Need for MuKuFo

When we chose this subject, we did so because it involved a real customer,but also, andjust as important, because we would be dealing with a real problem.

Our customer, Morten Ubbesen, who contacted Aalborg University with theproject pro-posal, had through his job in Projekt F, noticed that there were several problems with non-ethnic Danish children concerning their involvement in the different organizations, due tomisunderstandings in communication.

Among other things, he learned that non-ethnic Danish families with children attending e.g.soccer practice, misunderstand the way Danish organizations charge for the membership.Thus the subscription fee is not paid, because the concept of club duesis misunderstood.That is one scenario, but the missing payment could as well be due to the parents inabilityto sufficiently understand the Danish language. Morten Ubbesens motivation for requestingthe system, was to help prevent the above mentioned complication. His idea for solvingthis, was to have a computerized system developed that could help coachesand leaders ofDanish organizations to better communicate with non-ethnic Danish homes.

A concern about the system could be that it would not promote integration asthe parents willnot to the same extent, be forced to learn the Danish language. To respondto this, MortenUbbesen suggested that the Danish words should be written just below the translated words,and that this would help the reader associate the words and gradually get acquainted withthe Danish language. Another point made was that it promotes integration when children ofdifferent ethnic backgrounds attend social activities together.

12

Part II

PracticalCircumstances

This part describes the practical circumstances concerning the developmentof the system

13

Choice Of Methodology 2In this project we have chosen to develop a system using the eXtreme Programming method.In this chapter we explain our motivation towards this. Furthermore we describe our moti-vation for choosing the additional methodologies used in the development period.

2.1 Reasons And Consequences

eXtreme Programming

At the time we commenced this project, we had to choose a development methodologywhich was based on either an agile or a traditional way of dealing with the assignment infront of us.

We chose to develop using the agile method XP, which will be further described in Chapter4. The choice was made mainly because of the following facts:

• All members of the group had previously only worked with traditional methodologies.Therefore we found it to be more challenging and educative to choose theagile wayof developing software.

• Our customer was not fully aware of what he wanted the application to contain. Thisis a prevalent situation when working with XP, while considered a problem whenworking with traditional methods.

• XP supports close cooperation with the customer throughout the development.

The follow-on effects of this choice are as follows:

• We were able to start coding from day one.

• We had to alter a lot of code, if it was written for one purpose, but later on had tocontain more functionality.

• We were able to show our customer parts of the program to give him feedback on hisrequests.

15

2.1 Reasons And Consequences

• We were able to add requirements for the system continuously during the develop-ment.

In addition to XP we have included paper prototyping, usability heuristics, and usabilitytesting, which will be described in Chapter 4 as well.

Paper Prototyping

Experience shows that information about a systems functionality can be gathered early in adevelopment process, using prototyping.[Molich 2003]

When the decision to use prototyping as a way to ease the communication betweenus andour customer was made, we had two choices: paper prototyping and electronic prototyping.Both solutions bestow certain advantages, and in evaluating these, with our situation inmind, we found the motivation towards using paper prototypes.

Some of the advantages when using paper prototypes are as follows:

• Users and developers are on an equal level, as both can edit the prototypes.

• Only a short period of time is used on making them, which means less work is wasted,if the prototype is not used.

• It is clear to both parts, that it is not a fully developed system.

• They do not invite to cosmetic changes, which means concentrating on functionality.

Usually prototyping is utilized to test the system in its initial phase. This procedure iscarried out to test the usability or to get comments on the design and navigation of thesystem from the customer or the users.[Molich 2003] A description of paper prototypes andhow we used it can be found in Chapter 5.

Usability Testing

To better ensure that the developed system is actually useable by the intended end users,either conducting a usability test or a heuristic inspection seemed obvious choices. Wedecided to conduct a usability test based on the following:

• Usability testing conducted under the right circumstances gives an unparalleled in-sight into the users problems and successes experienced during the useof our system.This gives a wide variety of empirically based data.

16

2.2 Alternatives

2.2 Alternatives

Agile Methods

XP is not the only agile development method available. Scrum, Crystal Orange, DSDM(Dynamic Systems Development Method) are some of the other methods, we could haveconsidered for development. Our main reason for using XP is, that it is the only agilemethod, we have been introduced to in the semester courses. This project have thereforebeen an appreciated possibility of turning our theoretical knowledge into practice.

Electronic Prototypes

Many of the advantages of electronic prototypes are only present, whentesting a system istaking place. Contrary to testing, we used prototyping as a way to communicate our ideas toour customer and showing a visualized version of his own ideas, of what the system shouldcontain as a design suggestion. Thereby our client could ascertain whether the developmentteam shared his understanding of the contents of the agreed user story,and expand his abilityto write better user stories.

Usability

The main reason for not choosing heuristic inspection as a way to enhancethe usabilityof the application was mainly that it does not involve end users. Instead it depends uponan expert evaluation of the user interface using heuristic or guidelines. As emphasized byseveral usability experts this type of evaluation is not as effective as real user testing.

17

2.2 Alternatives

18

Choice Of ProgrammingLanguage 3We have chosen to program using JSP (Java Server Pages). In this chapter we explain ourmotivation towards this choice.

3.1 Reasons and consequences

In choosing our programming language we ended up with two appealing options: JSP andPHP (PHP: Hypertext Processor).Other possible languages and reasons for not choosing these will be mentioned in Section3.2.

There was a number of advantages and drawbacks regarding both languages. The mainreasons why JSP became our final choice are as follows:

• JSP makes it possible to work with Java classes and the standard Java library, whicheveryone in the development team is familiar with.

• The product will be more developed as we know Java already, which is desirable forthe customer.

• Only a few members in the development team had experience, which meant thatmoretime would be spend learning the language and less time spend on actual production.with PHP.

With this decision came certain follow-on effects, which are listed in the following:

• We had some problems in finding a web hotel provider that supported JSP. In additionit was much more expensive than servers that supports PHP.

• Development is very demanding to the workstations, since the development environ-ment and the server required to execute JSP takes up a lot of resources.

• We were able to start the development of the application almost immediately becausewe had some experience with Java.

• JSP is a very secure programming language.[J.F.Pironneau 2001]

19

3.2 Alternatives

• JSP runs fast once the Servlet has been created. This happens on thefirst visit onlyinfluencing the initial person entering the page.[J.F.Pironneau 2001]

Because JSP ïs executed server-side it requires the web server to generate the web pageswhenever the user makes requests to the page. The situation is different when concerningJavaScript, which needs no compiling and is executed on the client-side. Thisminimizes thetraffic between client and server, which is an advantage when working on a client-computerwith a slow internet connection. JavaScript gives the programmer the opportunity to makemany of the dynamic functions client-side, resulting in a smoother experience for the user.

3.2 Alternatives

We considered PHP as an alternative to JSP. Our main reasons for not choosing PHP, wasthat it would mean learning a new language for the majority of the development team. Weassessed that it would probably cost us considerably more time in the learning process, anddue to the fact that the focus in this project was mainly on cooperation with the customer, itwas agreed not to spend time learning a new programming language.Other alternatives such as ASP (Active Server Pages), CGI (Common Gateway Interface),etc. were not considered, as no one on the development team had experience with any ofthem, cf. the above-mentioned reason and because non of the possessed needed features notalready provided by JSP. Instead of JavaScript as our client-side or front-end programminglanguage, we could have chosen e.g. Java Applets or Flash. The clear disadvantage to thelatter languages are, that they require the user to download and install a plugin in order forthe system’s GUI (Graphic User Interface) to be executed.

20

Part III

Methodology

In this part we describe the methods used to develop thesystem

21

eXtreme Programming 4The eXtreme Programming method is described in this chapter as well as our choices

regarding this method. This chapter is based on the book, Extreme Software Engineering.[Steinberg Palmer 2004]

4.1 Spikes

When working with a new programming language, a new method or any other field thatis new to you, it is useful to get a head start regarding a specific assignment before takingit on. In a programming context, this could be learning the syntax of a new programminglanguage, figuring out how to write code specifically for mobile devices, learning how toconnect to a database or just sending a message to the screen. Any kind of knowledgerequired for a part of the development team to take on a certain task.

In XP, the way of acquiring this kind of initial knowledge, is called spiking. Making a spikemeans, trying to work with the required technology and learning the necessary to solve thegiven task. A spike should not be time consuming compared to the actual task,and shouldalso not be related to the task directly, since the goal of making spikes is to gaininsight inthe technology rather than solving the pending task.

This makes spikes useful, not only to programming issues, but as an initiativeway of gettingacquainted with all kinds of unknown areas the development team needs to know aboutwhen developing an application.

4.2 User Stories

Before the development team begins coding, some steps towards defining the intended sys-tem need to be taken. XP’s way of doing this, is by writing user stories.

A user story is a short description of a function the program should contain. XP dictatesthat you should have a lot of short user stories rather than just a few bigones in order tokeep them precise, and easy to inspect.

The user stories are constructed in cooperation with the customer based onan interview.Before this interview the development team needs to have some backgroundinformation, in

23

4.2 User Stories

order to ask the customer questions, that will be useful when creating the user stories. It iscrucial that the customer does not need to twist his mind, trying to understandwhat a userstory is. Instead the team should ask questions that help them create user stories based onthe customer answers. When the interview is done and the user stories havebeen written,the team starts weighting the user stories. This is done by assigning each story an estimatedamount of units. Units are described in Section 4.2.1.

By comparing the amount of units assigned to different user stories, the team clarifies to thecustomer, that will be the heavy parts of the system to develop. This gives him the basis tobetter choose from the user stories, according to the allotted budget. For instance, a featurethat the customer finds rather useful, could be very hard to implement, in whichcase it willtake a long time to program, thus adding to the total cost. This way the customer is ableto pick out what he finds essential to the program and at the same time, get theoverviewof what could be spared as a result of limited time or a tight budget. It is possible for thecustomer to add new user stories throughout the development process.

In time some of the user stories might turn out to be too large, overlap each other or nolonger be wanted by the customer. When these symptoms occur it is time for refinementand the involved user stories are rewritten and the assigned units are reestimated. Thisprocess is a part of the planning game as described in Section 4.2.2.

4.2.1 Units

Every user story needs to be given some sort of measurement of how much time the storywill take to solve. To solve this XP uses a concept called units. A unit is an undefinedamount of time, indicating how much time a user story will take to program relative totheother user stories. It is up to the developers to figure out exactly how muchtime a unitrepresents as the project proceeds. This is relevant in order to give the customer an amountof units to an interation and enabling the customer to control his workload.

At the beginning of every iteration, the team assigns an amount of units to the customer’sdisposal, on the basis of which user stories are picked according to the number of units.

4.2.2 The Planning Game

The planning game is a term used to cover the planning process of XP in total and is carriedout to initiate every iteration. This includes the following:

• Making user stories based on interviews with the client.

• Having these stories accepted by the client.

• Making a budget of units for the client to spend on the user stories he wantsimple-mented in the next iteration.

• Testing if the implemented features live up to the client’s expectations.

24

4.3 Pair Programming

• Rewriting, adding, and refining user stories.

4.2.3 Metaphor

In order for the development team to be able to communicate in a way that is intelligible toall, XP suggests the use of metaphors, a common analogy for the system and itsdifferentsections. A classic example of a modern programming metaphor is the "desktop metaphor"referring to the base of the graphic user interface of Microsoft Windows style operatingsystems. This is intuitively associated with the desktop in your office on which you canplace all the things you need to work with. This analogy is easy to understandand helpsthe end user to think of this part of the system as the basis for all other activities within thissystem.

Metaphors are used to supply a common understanding and terminology regarding the sys-tem and its different areas. This terminology will benefit both the development team, thecustomer and in most cases the end users. The end users will benefit when this terminologyis officially used in the final release, like the "desktop metaphor" .

4.2.4 Refactoring

Briefly, refactoring is cleaning up redundant code, generalizing methods and making classstructure more intuitive. This could include renaming classes or methods so therelationshipbetween name and functionality makes more sense, utilizing a superclass or deleting unusedcode. If a programming pair is going to add functionality to a class that someoneelse wrote,they will have an easier time doing their job if the code is neat and easy to read.If norefactoring is done, implementation will become slow and tiresome, since more andmoretime is spent, trying to figure out what other people meant, when they wrote the code, thecurrent programming pair is supposed to work on. In small projects this problem is easy toovercome and refactoring is rarely needed, as long as XP’s goal to produce working code,is maintained. If the system is intended to be passed on for further development, refactoringwould probably be presented as a demand from the client. This might never be formulatedas a user story, due to the fact that the end user will not be working with theactual code.

4.3 Pair Programming

During the development period, every line of code produced is written in programmingpairs. No code is created by a single programmer alone. This helps ensuring that the systemin its final state is almost flawless, due to on the fly corrections, provided by the conceptof pair programming. Every single algorithm will have had two persons programming,evaluating and correcting it.

When working in pairs, there are two roles that needs to be filled out. One is the driver,which is the term used for the person doing the actual programming. While the driver is

25

4.4 Testing

programming, the other person in the pair takes on the role as the co-pilot who’s role is tobe the driverslsparring partner. The co-pilot will assist the driver in making decisions onhow to approach a given task and read along as the driver programs. In that way there aretwo persons checking the code for errors, that could easily occur if only one programmerwas writing and reviewing the code.

4.3.1 Switching Roles

Another essential element of pair programming is switching roles. Wheneverthe pair feelslike it, the driver and the co-pilot can switch roles. The co-pilot who has been resting fromprogramming, takes the keyboard and continues coding where the other programmer leftoff. In this way, the method is highly efficient, since no programmer is able to get stuckwhen he runs out of ideas. The actual switch, can happen at any time in theprocess, forexample if the co-pilot has a good idea, that he simply cannot explain but justhas to programor if the driver is tired of writing and needs a break. XP encourages the pair to switch often,so that deadlocks and losing the spirit is avoided.

4.4 Testing

XP provides two types of tests that help the developers produce a program which lives upto the customers expectations and ensures that the code being written is working correctly.

The two tests are:

• Acceptance test

• Unit test

4.4.1 Acceptance Test

Acceptance tests are made by the customer to help the developers. Furthermore it helps thecustomer, as writing down the intention of the user story often clarifies the problem area.The tests can be automated or run manually.

Fully automating the tests will ease running them more often as it is done by the push ofa button. The downside is that it takes some time to set this automation up. The non-automated approach is not as time consuming as the automated approach in the startingphase, but will probably not be run as often, as non automated test requires the developer tovisit more test functions, thus makin it more time consuming.

An acceptance test is a test case designed by the customer, to establish when a given userstory is fully implemented. The test case is formulated by the customer in e.g. pseudocode describing the anticipated outcome based on a given input. This pseudocode is thenconverted by the development team into an executable test within the system.

26

4.5 Iterations

4.4.2 Unit Test

Unit tests are made by the developers to make sure that the code being written isworkingintentionally. In XP these tests are urged to be written before the code for theprogram. Thismeans that when a user story is requested to be developed, the first thing programmed is theunit test. It gives the advantage that the development team must evaluate and consider thedetails of the program carefully and precise. These tests can, like the acceptance tests beautomated or non-automated.

This type of test cause certain problems in the sense that novice programmers will not beable to recognize all the functionality of a given user story from the start and thereby not beable to make a test that will be sufficient.

The difference between an acceptance test and a unit test is that acceptance tests are de-signed by the customer, who does not have any insight into how the actual code is going toappear. Therefore he will not be able to create a test that verifies the component parts of thecode. This is the job of the system oriented unit tests created by the developer.

Common for these tests in XP are, that they rely on the development team and thecustomerto judge how to make functionality accessible, and do not involve the final users.

4.5 Iterations

XP works with a concept called iterations which briefly described is a periodof time in thedevelopment process which contains certain tasks.

Some of the tasks are:

• Identify current status

• Look at the next batch of user stories the customer has requested

• Break the user stories into well defined sub tasks

• Estimate and sign up for these sub tasks

• Confer with the client

• Commence work on different sub tasks.

The development process consists of a number of iterations. The first iteration is more timeconsuming, since it includes the added burden of getting the project moving and setting upthe infrastructure.

4.6 Our Choices

In this section we describe how we have chosen to use and work with the method XP.

27

4.6 Our Choices

4.6.1 Spikes

During the entire development phase we have frequently used spiking as prescribed byXP. It has been a most welcome practice of the method, as we were new to JSP, givingus the possibility to learn different features outside the actual program. Using spikes wemade small programs, which contained the functionality requested by the system underdevelopment. This made it easier to keep an overview of how to code some given function.

Aside from that, spiking was used when a programming pair was one man short, as a wayto anticipate pending user stories.

4.6.2 User Stories

A natural and important part of XP is user stories, which we have includedas the foundationof developing our program. We had some starting problems making our user stories fromthe meeting with our customer. These problems were probably caused by the fact that noneof the parties involved had any experience making user stories.

In a situation where the customer needs help expressing the functionality, it demands acertain kind of overview and insight to ask the right questions to the customer, withoutbeing too insisting forcing opinions and functionality on to the customer.

Further information is described in Chapter 13.

Metaphor

We used metaphors in the development phase from day one. When we started discussingthe very essence of the system and the key features, we immediately started referring tothe ’workshop’ as the place the users could edit their ’documents’, usingthe ’toolbox’. Wealso talked about the various sorts of documents in the system, with names associating themto their paper version alternative. It was natural to adopt the terminology of the contextin which the system was intended to provide a service. However not all features in thesystem existed beforehand. This, and the fact that not all end users are used to working withcomputers, stressed the need for intuitively associable metaphors further.

As far as our success in this matter we believe that using metaphors throughout the develop-ment phase has helped us communicating in a commonly understandable language using aterminology that combines esoteric expressions with terms associable to things and actionsin our every day life.

4.6.3 Pair Programming

We made all our programming in pairs as XP suggests. As we all have our different skills,we quickly discovered, that half of the group were better coders than theother half. There-fore we divided the group into pairs accordingly. This had an educational purpose, as well asan assurance that every pair would be able to solve the tasks taken on forthe given iteration.

28

4.6 Our Choices

The programming pairs were changed before every iteration, to avoid the pairs getting intoa routine, and to get a better possibility to inspire each other and draw benefit from eachothers different skills.

To solve the tasks for a given iteration, the user stories chosen for the iteration were splitinto three equally large assignments, for the pairs to choose from.

4.6.4 Testing

Acceptance Test

Both the automated and the non-automated way of executing the acceptance tests has someof the same disadvantages.

We chose not to implement the non-automated approach towards acceptancetests at all.Instead of letting the customer write these tests, we had a weekly meeting in which weshowed him the program with the completed user stories. He would then use theprogramand give feedback deciding wether the user stories have been implementedsatisfactory.

The acceptance criteria that would normally be used in an implemented test case, were usedby the development team to guide the implementation of the related user story. When thesystem was demonstrated to the customer at the meeting, he then tested if the agreed criteriahad been met.

Despite the manual approach to acceptance testing, we still ensure fulfillmentof all thedesired acceptance criteria set by our customer.

This would also allow him to give feedback in relation to the interface and layout of theprogram, as he was uncertain of what he wanted the program to contain and look like as hehad a hard time coming up with suggestions on his own.

Since our education is focused on making programs which are user friendly, we prioritizethis in our program. While XP tests the code and functionality, it lacks tests, thatshowwhether the GUI is understandable and allows the user to navigate around inthe programwithout too much trouble. This is the reason why we have included usability testing as asupplement for XP’s way of testing, as described in chapter 12.

Unit Test

Making unit tests prior to programming a user story is, as mentioned in Section 4.4.2, apractice of XP. Unfortunately none of us had any experience in writing and executing testsbefore the development of software. Therefore we have predominantlyrefrained from doingso. Instead we chose to test while coding. When a part of the system was being developed,we compiled and tested it. E.g. If a function was meant to retrieve data from a database, theoutput was written to the screen to assure that it was indeed returned the intended output.This way of testing is essentially doing what a unit test for the same case woulddo, as itspurpose would be to compare data from a database with data defined and hard coded in thetest.

29

4.6 Our Choices

While not implementing these tests we spent some time compiling and testing the function-ality manually. However we were able to start programming right away saving timeat thebeginning of each iteration. Furthermore conducting all GUI related tests manually helpedto make functionality testing become a routine exercises as well, thus cutting backtimespent on other wise expensive manual testing.

4.6.5 Iterations

Developing using iterations, has been a good experience, as the end of every iterationformed a deadline for the chosen user stories. This has helped us keep the time sched-ule as the iterations were short, making them easier to survey, instead of having to grasp anentire programming phase in one sitting.

Our iterations were designed to span one week. As a minimum containing the following.

• Customer meeting - Choosing user stories

• Assign programming pairs

• Sign up for assignments

• Commence work on different assignments

• Identify current status

• Re-estimate user stories

• Meeting - Accept from the customer

The practical iterations will be described in Chapter 14.

30

Paper Prototyping 5Prototyping is usually used in a test setup. This chapter describes the method of paperprototyping as a way to ease the communication between the customer and us. We willdescribe our choices and argue why we used paper prototyping insteadof the electronicversion

Paper prototyping is a way to get a visual perspective of often rather abstract ideas. Whendelineating your ideas onto a piece of paper, it can be easier for others tounderstand these.This is an essential point when working with customers, who have not worked with softwaredevelopment before. Paper prototyping can, in this way, be used to giveyour customer aclearer view of the system being developed. Drawing his ideas as a sketch, can furthermoreease any future discussion about the systems look and feel between the developers andcustomer.[Molich 2003]

Usually prototyping is utilized to test the system in its initial phase. This procedure iscarried out to test the usability or to get comments on the design of the system from thecustomer or the users[Molich 2003]. This way you can benefit from user involvement earlyin the process. Users are good at reacting to specific designs when presented to them, andto express what they do and do not like about the given design.[Nielsen 1993]

To test a system by this approach, an expert user of the system, typically amember of thedevelopment team, will act as a computer, shifting paper slides as the user interact with thedrawn prototypes. This is a cheap and fast way to collect information about the intendeddesign of the system and its usability thus making this method ideal in relation to XP’sshortiterations.

5.1 Our Choices

Instead of testing we wanted to use prototyping as an aid to design user stories. This was anefficient way to ease the communication between our customer and us. The communicationhad so far suffered from our incapability to help our customer designing user stories and histroubles presenting his ideas as a system.

When no testing was intended, and the prototypes were meant only as a way toreach acommon understanding it would be too time consuming to use electronic prototyping.

31

5.1 Our Choices

Therefore we chose to design some prototypes graphically on a computer,which wereprinted for the next meeting with our customer.

32

Heuristics 6During the development of the system, guidelines are needed. For this weused heuristicsexplained in this chapter

A heuristic is a guideline or a general principle, which can support the developing teamdesigning a system or be used to critique decisions already made. Unfortunately a list that,if followed, will guarantee a usable system simply does not exist. What doesexist areguidelines. Jakob Nielsen and Rolf Molich suggest, that the following principles should befollowed by all user interface designers.

• Visibility of system statusThe system should always keep users informed about what is going on,through ap-propriate feedback within reasonable time.

• Match between system and the real worldThe system should speak the users language rather than system orientedterms. Fol-low real world conventions, making user information appear in natural andlogicalorder.

• User control and freedomUsers often choose system functions by mistake and will need a clearly marked exitto leave the unwanted state without having to go through an extended dialog. Supportundo and redo.

• Consistency and standardsUsers should not have to wonder whether different words, situations or actions meanthe same thing. Follow platform conventions.

• Error preventionEven better than good error messages is a careful design which prevents a problemfrom occurring in the first place.

• Recognition rather than recallInstructions for use of the system should be visible or easily retrievable wheneverappropriate. objects, actions and options should rather be visible than recallable.

33

6.1 Our Choices

• Flexible and efficiency of useAccelerators and shortcuts, unseen by the novice user, may often speed up the inter-action for the expert user to such an extent that the system can cater to both inexperi-enced and experienced users. Allow users to tailor frequent actions.

• Aesthetic and minimalist designDialogs should not contain information which is irrelevant or rarely needed. Everyunnecessary unit of information in a dialog, competes with the relevant units of infor-mation and diminishes their relative visibility.

• Help users recognize, diagnose, and recover from errorsError messages should be expressed in plain language (no codes) with no codes pre-cisely indicate the problem, and constructively suggesting a solution.

• Help and documentationThis information should be easy to search, be focused on the users task,list concretesteps to be carried out, and not be too large.

When using heuristics for motivating critique, they can be used as a checklist in a socalled heuristic inspection, which is conducted to ensure that the goal of each heuristicis reached.[Dix et al. 1997]

6.1 Our Choices

Since we were developing a system which targets both experienced and inexperienced users,naturally we wanted it to be easy, comfortable and intuitive to use. We found that XP is shortof practices to ensure a high level of usability in the developed system.

Testing the system with real users is one way of gaining information about any shortcomingsin regard to the intuitive use of the system. But while user testing is concernedwith findingand correcting errors or usability problems in an already implemented system, bearing theabove heuristics in mind we were able to design for higher usability from the start.

In addition to allowing us to design more considerate GUI earlier in the development pro-cess, these heuristics are clear and simple to follow. This means that they, withminimaleffort, will add considerable support in regard to the users interaction with the system. Theargument for using heuristics, is that developers are likely to think like the expert usersthey obviously are when designing the GUI of a system. This means knowing the intentionof actions and features and consequently not consider the help and guidance novice usersmight need. Using the usability heuristics described by Jakob Nielsen and Rolf Molich thedeveloper is better equipped to design user friendly interfaces considering the needs of anovice user.

34

Usability Testing 7In order to make a system that better satisfies the end users, we chose to combine XP withusability testing. This chapter describes the different usability methods we used for our test.

The thinking aloud technique is used as a way to get to know what the participants arethinking, while interacting with a computer system. During the test the participants areencouraged to express their immediate thoughts, doubts, and what they expect the systemwill do, as they try to solve a task. Carried out under ideal conditions, the method will givea direct insight into the participants thoughts of the computer system. The interpretationsof the user interface given by the participants, will reveal when the design of the system iscausing wrong assumptions and misinterpretations. In addition, the participant will oftencomment on what is liked and disliked. One of the strengths of the thinking aloudtechniqueis the great amount of various qualitative data it generates, even though few participantsare involved. On the other hand, one of the disadvantages of using this technique, is thatmany participants feel that it is unnatural to verbalize their thought process. Some willexperience difficulties in maintaining a running commentary of their thought process. Whenthis occurs it is the job of the test monitor to encourage the participant to continue and ifnecessary ask questions like: "What are your thoughts right now?", ifthe participant makesan action without expressing his thoughts. To increase the probability that most of theusers actions have been understood, the test monitor will make the participant clarify whichactions, he did not understand at first. This can be especially useful when the participantacts inexplicably or forgets to express their thoughts.

7.1 Testing Roles

During a test different roles need to be filled out to take care of different tasks, like operatingthe video equipment and taking notes. In this section we describe the most important rolesthat have been in use during our test.

35

7.1 Testing Roles

7.1.1 Test Monitor

According to Jeffrey Rubin [Rubin 1994], the role of the test monitor is the most demand-ing. The ideal test monitor is a quick learner, has a good memory, is a good listener, isflexible, and has good interpersonal skills. During the test, the test monitor has the primarycontact to the participant and must maintain the different social routines. When arriving atthe laboratory the participant is welcomed by the test monitor and in short explained thebackground of the project. To make the test situation less stressful and overwhelming, thetest monitor is the only member of the team the participant is introduced to. Beforethetest begins, the test monitor explains how the test will be conducted, that the participant issupposed to express their thoughts, and how the tasks should be solved.It is important thatthe test monitor emphasizes, that the purpose of the test is to test the system and not theparticipant. While the participant is engaged in solving the different tasks, the test monitormakes notes of questions, that should be asked after the test, e.g. the test monitor wouldlike to clarify, why the participant chose to click a certain button. In order to make any useof the collected data, it is crucial to know the reason to the actions of the participant. Asthe participant solves the different tasks, it is important that the test monitorsinterferenceis minimal and that neutrality is maintained. It is the participant who should solve thetasksand not the test monitor. Thus if the participant asks for help, it is also important that the testmonitor instead of helping encourages the participant to solve the task independently. If aparticipant shows difficulties in solving a task, it is also important not immediately comingto the rescue. On the other hand it is important that the test monitor ends a task ifthe par-ticipant gets stuck for e.g. five minutes. It is important not to signal, when the participantis close to solving a task by smiling or expressing that the participant is moving in the rightdirection. It is also important, that the test monitor does not stop the participant,when atask is solved. This should expressed explicitly by the participant.

7.1.2 Data Logger

A data logger is according to Jeffrey Rubin supposed to log actions performed by the testparticipant. A way to do this, is to keep track of what parts of the system is accessed at whatpoint in the test.

7.1.3 Test Observers

The test observer is given very little significance in the actual test situation by Jeffrey Ru-bin. The role refers to anyone watching the test and can be filled by e.g. members of thedevelopment team or the customer. Either can get valuable insight by watching participantswork with the application. This way developers get a direct feedback on their product, andan opportunity to evaluate whether the system acts as expected when operated by a user.

36

7.2 Test Goals

7.2 Test Goals

When deciding to perform a usability test, there are always certain goals important to reachin the specific case. The main goal is of course testing whether your product is user friendly.The main objective of testing is to provide certainty that your product is:

• Easy to learn and use.

• Satisfying to use.

• Providing utility and functionality that is highly valued by the target audience.

To ensure that the test created will fulfil the objectives, test goals are defined. In doing so, acommon understanding is reached within the developing team, of what the precise intentionof the test is, this way making it easier to create test assignments.[Rubin 1994]

7.2.1 Test Assignments

In order to be sure of having a test which will help you uncover problems and usabilityissues in all areas of the system, you need to be sure that the participant willcontact allthese areas. By formulating specific tasks it is possible to guide the participant through thesystem, systematically taking the participant through all desired parts of the system in acasual and unforced manner.

These tasks should be designed according to certain guidelines, to ensure that the usersunderstand why they have to solve the task. These guidelines are simple andeasy to follow:

• Provide realistic scenarios complete with motivation to perform.It will make the users more comfortable with the test, if they can see the purposeofthe assignment, therefore you should strive to create tasks that the user can recognizefrom his everyday life.

• Sequence the task scenarios in the order in which they are most likelyto beperformed.Following this guideline, the test will seem like a natural way of using the system,thus avoiding the users to question, why they are forced to doing something thatseems unnatural to do.

• Avoid using jargon and cues.The participants are not expected to know anything about programming or systemsdevelopment. Therefore it is extremely important not to use technical terms, abbre-viations or any words that would be hard for an everyday user to understand, whenformulating the assignments. Also it is important that you try not to guide the usersinto doing something, they would never had done on their own.

37

7.3 Test Environment

• Try to provide a substantial amount of work in each scenario.If the assignment takes only a couple of minutes to complete, you have made an errorin designing the questions or you have an extremely well designed product.Youshould always try to put many assignments into a task, so that the users will have todo some thinking of how to solve it. In this way you can tell, if the users are capableof figuring out how they could use the system to solve the task.

Following these guidelines will help creating a test, that will not only be of use tothedeveloper, but hopefully also will show the user, that the system would bean advantage forthem to use. The customer can see, that whether the right choice was made,when decidingto have the system built.[Rubin 1994]

7.3 Test Environment

Although other less expensive solutions can be used, Jeffrey Rubin recommends using ausability lab specifically designed for testing if possible. The classic testing laboratoryconsists of a room used for observation and control and a room for testing. If preferredthe participant can be the only person situated in the test room. Then all communicationbetween test monitor and participant occur through a speaker arrangement. The more tra-ditional choice of having the test monitor in the test room can also be used. Itshould bepossible to collect test data with cameras and microphones installed in the test room. Someof the benefits of using a usability lab can be:

• Many observers are allowed.

• One way mirrors allowing direct viewing of the test by observersl.

• If the test room is soundproof the observers can communicate during testing withoutdisturbing.

Our testing environment and how it has been a benefit to our test, is described in Section7.5.3

7.4 Data Analysis

The purpose of data analysis is finding the reason to the problems that the user experienceduring testing. The analysis is made during testing, first observing the users difficulty andthen noting what is causing the difficulty. This quick approach to analysis is suggested byRolf Molich if the extensive analysis needed for video recording is not anoption.[Molich2003]

38

7.5 Our Choices

7.5 Our Choices

This section describes choices we have made regarding usability testing.

7.5.1 Test Roles

In any test situation the role as test monitor should be filled as explained by Jeffrey Rubin.This has been strived towards, why no specific choices have been madein relation to thisrole.In relation to the two other roles explained, we chose to modify these, by converting theminto one.The main purpose of this one role, was to take written notes of what the participant saysand does during the test. This to supplement the notes taken by the test monitor,and not somuch to log every move of the participant.The test laboratory gives the possibility to closely watch and log the test. As thisis donethrough one way mirrors and tv-screens, it happens without disrupting the test situation, andimposes no limit on the number of observers. The advantage of having many test observerstaking notes is the possibility for rich intersubjective test data, not only relying on memoryand the notes of one person.

7.5.2 Test Goals

Our goal with a user test was to test the current release of the system. These tests wereconducted along with the coding process, which meant that the system changed due to thedevelopment. Taking this into consideration, planning a full scale user test for each release,with the advised number of participants, would be too time consuming and pointlesscon-sidering how far the system had been developed. Instead, a small test witha few participantsfollowing the guidelines described for usability testing, provided us with information aboutthe system’s usability failures, making it possible to redesign the system to bettermeet theusers’ needs. Testing the second release according to the same principles, once again pro-vided us with enough information to redesign the system into its third and, in the context ofthis project, final release. Ideally, we could have made several more release tests throughout the development process and in the end, making a usability test with the advised num-ber of participants, which would ensure that the system in fact is usable to the end users.It would be appropriate to conduct such an extensive user test later onin the developmentprocess but for at third release, we argue that a release test is still sufficient.

Each of our tests follows an overall plan, from the beginning to the end. Inshort it can bedescribed as follows.

• The participant arrives and is welcomed by the test monitor.

• The test monitor describes the procedures of the test e.g. what the participant issupposed to do, and the role of the test monitor.

39

7.5 Our Choices

• The test is carried out.

• After the last task the participant is asked to fill out a short questionnaire.

• If necessary, a short interview is conducted where questions arising from the test areasked.

7.5.3 Test Environment

For this test we have been using AAU’s usability lab on Fredrik Bajers vej 7which isspecifically designed for the purpose of usability testing. As shown in Figure 7.1 it consistsof a test room and a soundproof observation- and control room.

Figure 7.1: Test environment

From the observation and control room it is possibly to watch what is happening in thetest room through one-way mirrors. This allows several observers watching the test andcommunicating without having to worry about interfering. This has been a great benefitfor our test, because the rest of the group members could be observerssupporting the testmonitor by taking notes thereby making it less possible that we had to rely on the videotapes. This also gave us the possibility to invite our customer to the test. We decided thatthe test monitor should be in the test room with the participant. This helps to ensure that the

40

7.5 Our Choices

participant feels more relaxed and less like a "guinea pig" in an experiment.The test room was equipped with several video cameras that could be operated from thecontrol room, making it possible to refocus or change the angle of the camera. The feedfrom the cameras were displayed on monitors in the control room, showing what was beingrecorded and also giving the observers the possibility of getting a closer look on exactlywhat was happening. On the recording of our test we chose to focus onthe screen of themonitor and make a picture of the participant as illustrated on Figure 7.2. This gives aprecise picture of how the application was used and also captures the bodylanguage of theparticipants.

Figure 7.2: Screen shot from composed recording

7.5.4 Data Analysis

The purpose of the analysis is summing up the worst problems experienced by the par-ticipants and finding the corresponding causes. During the test, the test monitor and testobservers took notes, when the participant had difficulties using the application and the rea-sons for it. After the test s meeting was held where each person involved in observing thetest presented his findings. The benefit of having more group members involved was that

41

7.5 Our Choices

more controversial findings could be discussed and if needed rejected.The different find-ings and the result of the analysis was summed up on and used for correcting the system.

Even though we recorded our tests, we decided only to use the tapes as thelast resort, tosolve disagreements if different interpretations of the test would occur. The main reason forthis, is that basing the analysis on the recordings would be very time consumingand notappropriate at this time of development.

42

Part IV

Product Development

In this part we describe the actual development process

43

Overall Flow Of The Project 8Managing time in a development process is an essential part, and in this chapter we describesome of our considerations towards this.

We made a decision in the beginning of the project to start programming as soonas possible,and continue until one month was left of the project. This last month was dedicated entirelyto writing the documentation of our work.

The programming and development phase of the project, was in many ways controlled byXP with iterations, acceptance tests and so forth. In extension of this, we made the iterationsspan one week, which resulted in the planning of five iterations. At the end of each of theseiterations, we planned a meeting with our customer in order for him to see our work andeither accept or decline various changes. The iterations basically contained the same stepsincluding user stories, meetings and so forth. The last two iterations, also included usabilitytests to test our program with real users. This consumed time from the actualprogramming,but payed off by delivering results about the usability of the system. By theend of thelast iteration we had a meeting with our customer where we demonstrated what wehadachieved.

The next big step of the project was to document what had been going on during the devel-opment process. This process was inspired by XP mostly done in pairs. Aswe had found itto be a good asset to have somebody nearby to discuss subjects with.

8.1 Schedule

When we met with our customer the second time to talk about future cooperation,webrought a schedule to provide him with an survey of the amount of time he could expect usto work on the system. Of course this was made as a means to recognize how much timewe had to complete each assignment.

45

8.2 The programming phase

8.2 The programming phase

The first schedule was, as Figure 8.1 shows, very optimistic, and it was based on the factthat we wanted to start programming as soon as possible.

46

8.2 The programming phase

Figure 8.1: First schedule made for the second meeting.

As we began the process of developing the system we found that some practices took alittle longer than expected. Among other things we had some trouble making user stories.

47

8.2 The programming phase

Because of that we included paper prototyping, causing our plan to slide.This was beforewe even started programming, in spite of the fact that XP claims that deadlines cannot slide[Steinberg Palmer 2004].

After reviewing the schedule, it was shortened a bit and three iterations were removed, asshown on Figure 8.2. Also the first iteration was extended, in order for usto get acquaintedwith XP and its various practices. Furthermore our customer was quite busy inthat periodand therefore had trouble finding the time for a meeting. This gave us time to setupthefoundational structure of the system based on the initial set of user stories.

48

8.2 The programming phase

Figure 8.2: Schedule number one after review.

The iterations we made were quite successful in the sense that the goal of each iteration wasto complete the chosen user stories, which we accomplished. Furthermore our customer

49

8.3 The writing phase

was exited to see what we had made for every meeting and he was very supportive towardsour suggestions on how we had solved the user stories.

8.3 The writing phase

When we started planning for this project, we set the programming phase to end one monthbefore project deadline. This deadline was kept throughout the reviewof the schedule, asFigure 8.1 and 8.2 shows. This decision was based on earlier experiences, and although wewere eager to continue programming until the deadline we followed our initial plan.

50

The customer 9This chapter describes the relationship to our customer and the assignment, which is thefoundation for the cooperation with Aalborg Kommune.

9.1 Customer Relations

The assignment was given by Morten Ubbesen, a project manager of Projekt F under Kultur-og Fritidsforvaltningen in Aalborg Kommune. Projekt F deals with culture, organizationsand social work in Aalborg Kommune. It was initiated to enhance the membershipand par-ticipation of foreign ethic groups in the different local sports clubs and other organizationsin Aalborg Kommune. Jan Madsen, an IT employee in Kultur- og Fritidsforvaltingen, hasoccasionally participated in meetings to assist Morten Ubbesen, when technological topicswhere addressed e.g. regarding programming language and web hosting. Morten Ubbesenis educated as a sociologist and has been working with Projekt F since 1999.

9.1.1 The Settings

As explained in Section 4, we have tried to incorporate as many of the practices for support-ing cooperation provided by XP as possible, in the working relationship with our customer.Luckily we have had a very cooperative and enthusiastic customer willing to spend a lotof time on the project, giving us the possibility to fulfil most of XP’s demands. Toa greatextend the customer has been as a member of the team.

We had our first meeting with Morten Ubbesen on February 18th and endedthe projectwith a presentation of the system developed on April 29th. During this periodwe havehad approximately one meeting a week, with a total of nine meetings in the two monthscommitted to development. The meetings were part of the software development processrecommended by XP as described in Chapter 4. To avoid misunderstandingsand assuregetting all details and information correct, every meeting has been recordedand minuteswere taken. Except for one of the initial meetings, every meeting was held atthe university.

51

9.2 Customer Cooperation

9.1.2 The Assignment

During his work with the social life in different organizations in Aalborg, Morten Ubbesenexperienced a need for better communication between the organizations andthe foreignethnic homes.

The problem is that all written information from organizations to foreign ethnichomes isin Danish. This is a problem because many ethnic families have not sufficientlylearnedthe Danish language. Therefore much of the information handed out in the form of writtendocuments is misunderstood, creating problems when vital information cannotbe commu-nicated e.g. concerning when to play a match or payment of the monthly dues. MortenUbbesen believes that communication problems affect the experience of participating in anorganization negatively, thus resulting in the organizations loosing members from foreignethnic homes. The assignment offered by Aalborg Kommune was to make a system, thatcould help improve the communication between the foreign ethnic homes and the organiza-tions.

Some requirements to the system were made by Morten Ubbesen and Jan Madsen. Theserequirements served as a basis for designing user stories. The main purpose of this systemwould be to translate simple match notes, letters, and similar documents to English, Somali,and Arabic. These are the three main foreign ethnic groups in Aalborg. Instead of makingmany similar notes in paper, one can be produced in danish and subsequently translated toany of the above languages.

Our main focus this semester was to design and evaluate a computerized systemin cooper-ation with the users, and not to produce a fully functional system. Therefore it was empha-sized, before the assignment was accepted, that the final outcome would be a prototype andnot a full scale working application.

Depending on our success in developing the system and the response from end users, MortenUbbesen envisioned that the application would be used in other settings having similarcommunication problems. Morten Ubbesen suggested that DGI (Danske Gymnastik- &Idrætsforeninger) could have an interest in offering the services of the application to clubswithin their organization. With this in mind, it is important that the system is preparedforexpansions like adding a new language and other features corresponding to new demands.

9.2 Customer Cooperation

There are a lot of demands to the customer involved in a software development projectusing XP. The customer has to become familiar with a lot of XP terminology and practices,e.g. writing user stories, estimating in units, and acceptance testing that is a part of everyiteration. Ideally the customer should have an idea of what the application should contain.Our costumer did not have an IT background or any knowledge of system development. Hewas not familiar with the methods at use or the role he should play in an XP developmentcontext, why we had to describe and educate the customer in the necessarypractices. It

52

9.2 Customer Cooperation

was therefore crucial for the success of the usage of XP that we couldcommunicate thisinformation in a way easy to understand. We decided on a combination of oralpresentation,short papers describing essential topics, and an open mind approach towards questions andmisunderstandings in the preface of our cooperation. At the second meeting we gave apresentation of the development method, and afterwards began describing user stories. Theinformation given at the presentations was later e-mailed to Morten Ubbesen,giving him areference for the central terminology. This gave him the opportunity to readdress topics hedid not understand at first or remember clearly. During the different iterations we stressedthat he always had the possibility of asking questions. The customer ideally has a very activerole in the software development process making demands to system functionality. Ourmain problem was that Morten Ubbesen’s thoughts of the system were veryabstract, whichcaused problems specifying the actual user stories. He had a clear picture of the overallpurpose of the system, but only vague ideas of how this should be realizedin functionalityand graphics. Therefore he had a hard time making user stories and relating to those wepreviously had made, from the first meetings. To help him get a clear pictureof the conceptof user stories and to see what the outcome of a user story would be, we produced paperprototypes of the system. These were built on the user stories he had previously beenpresented to. The paper prototypes gave him a better understanding of the concept andeased the creation of user stories.

9.2.1 Meetings

The cooperation with our customer, has been based on the described guidelines of XP.According to these we had prepared the following before each meeting:

• User stories were refined, so the units better indicated the actual time neededto com-plete them.

• An agenda was made and sent to both Morten Ubbesen and Jan Madsen and a numberof units were put to their disposal for the next iteration.

The meetings with our customer started with a presentation of the system where changesand new features were presented. Afterwards comments regarding wishes of changes andquestions about choices made were received from the customer.

It was discussed which user stories were relevant in the current state of the system and userstories were picked for the following iteration.

9.2.2 Wishes

During the first meetings with Morten Ubbesen, we discovered three main issues the systemshould cover when developed:

53

9.2 Customer Cooperation

• The system should be able to translate a match note from Danish to English,Somali, and Arabic.

Morten Ubbesen explained, that 75% of the communication related problems couldbe solved if the system was able to perform the above task.

• The system should above all other tings be easy to use.

A system that is user friendly demands not only heavy considerations whiledevel-oping, but requires usability testing to ensure that the end user can easily use thesystem.

• The application should include an administration part for maintaining th e sys-tem after releasing it.

The administration part should be developed in a way, so Morten Ubbesen and JanMadsen can add new words and languages into the database without further trouble.

54

External Partners 10Working with external partners adds another aspect to the developmentprocess. This chap-ter explains the circumstances finding a suitable web hotel and how we cooperated with theinterpreters.

10.1 Web Hotel

When taking on the assignment of developing the system, we promised our customer thathe would have a running prototype at the end of the semester. We emphasized that thesystem would not be ready for use and therefore needed to be furtherdeveloped after wewere done. Our customer accepted this, but would still like us to arrange hosting at a webhotel and furthermore buy the domain for the system.

When we decided to use JSP as our primary programming language, we did not recognizethe trouble of finding a web hotel which offered JSP on their servers. Wespent many hourssearching, and ended up inviting and accepting an offer from InforceA/S [Inforce.dk 2005]who run Webhotel.net [Webhotel.net 2005]. The price was higher than anticipated, probablydue to the limited numbers of service providers that supports JSP.

A criterion for choosing which programming language to use was that everyone on the de-velopment team could start coding without to much effort. This was essentialas opposed toprice, which was therefor not considered. Fortunately our customer prioritized functionalityover saving money, why the cost of the web hotel was not an issue.

10.2 Interpreters

To enable MuKuFo to translate custom documents and standard texts we needed the ser-vices of external interpreters. Our customer referred to Aalborg Kommunes Tolkekorps,which provides translations and interpretations for most of the departments within AalborgKommune. In advance our customer had prepared the cooperation with the interpreters.

Due to the fact that Aalborg Kommunes Tolkekorps recently has been cut back, part ofthe interpretations had to be done by freelance interpreters. The consequence of this was

55

10.2 Interpreters

that the delivery time was extended, furthermore postponing the work on some parts of thesystem.

Another problem appeared when we had words translated into Arabic. The list of translatedwords we received did not correspond to the list of Danish words originally translated from.Since none on the development team, nor the customer understood Arabic, we had no wayof determining the relationship between Danish and Arabic words. Problems like thesecaused a lack of confidence to be formed.

In order to continue the collaboration with an interpretation service like Aalborg KommunesTolkekorps a standardized form communication regarding exchange of information shouldbe developed to ensure correct word-to-word translations. Furthermore when collaboratingwith interpreters trust is essential, as trying to validate their work will be an ever existinguncertainty, since they would be validating their own translations.

56

Paper Prototyping 11Being in a situation where neither developer nor customer had any experience in using thechosen development method, and the fact that our customer was uncertain about the contentof the system, we included paper prototyping as an aid to the communication between thegroup and customer.

11.1 Relevance

When designing user stories a bit of experience in using XP is needed. What is a userstory? How much should a user story embrace? How much detail should a user storycontain? Answers to these questions and many more should be known before the design ofuser stories takes place, making it possible to explain the customer what he is expected toprovide during the development period.

However, knowing these answers is not sufficient, as the task sets some requirements forthe customer as well. The customer needs to be more or less able to see his ideas, as anapplication, explain how he would like the work flow to be, have an idea of what happenseach time a button is pressed, and so on. This is rarely the case though, whythe developmentteam must be able to help and guide the customer to improve the user stories.[SteinbergPalmer 2004]

In our case the customer knew what he wanted the system to produce whenworking with it,but visualizing how to get there using an application, proved to be a bit harder. This com-bined with our lack of experience designing user stories, and our incapability to compre-hensively help the customer, created the need for an alternative way to make our customerspecify his desires and ideas.

11.2 Actual Implementation

We introduced paper prototyping as an alternative to interviewing the customer about hisideas for the requested software. By reviewing the statements made by our customer, dif-ferent drafts were produced. Subsequently these were presented tothe customer, who nowhad the opportunity to comment on what he saw.

57

11.2 Actual Implementation

Figure 11.1: Examples of paper prototypes of the Front Page

Figure 11.1 shows two examples of paper prototypes of the front page presented to ourcustomer. All the paper prototypes can be found in appendix D.

By presenting more than one prototype for each area of the system, the customer was freeto point out which parts of the prototypes corresponded best with his pristine ideas, andpick the preferred features from each of the prototypes. Additionally being presented witha visual design of a system, supported the customer in thinking of his ideas asa system andrendered him more capable of explaining himself in that context. If the suggested prototypeswere different from the customer’s ideas about how a certain feature should look or act, thisprocedure encouraged him to specify what the system should look like, according to hisideas.

A possible risk of doing this, is that by introducing ideas in a prototype, that originallywas not the customers ideas, the development team could foist their ideas onthe customer.However, we consider this a triviality as the customer still is the one choosing functionalityin the system. Actually it should be considered an advantage to be able to present the cus-tomer with ideas, as it is likely to strengthen the system as long as the ideas are consideredthoroughly. An example of this was the feature Auto Completion as shown in Figure 11.2.

58

11.2 Actual Implementation

Figure 11.2: An example of an idea from the development team presented to the customer

This feature was presented in the prototype, as all members of the development team hadagreed it was a feature, that would benefit the system. When introduced tothe customer, theidea was immediately recognized as an improvement, and added to the list of userstories.

A feature that was presented, but discarded by the customer, was an area with news onthe first page, as shown on the right hand side of Figure 11.1. The customer argued that anews section would be excessive, as the system should be more or less automated, and notupdated with news.

Likewise all features were evaluated by the customer, and eventually a number of userstories were designed. These will be described in Chapter 13.

59

11.2 Actual Implementation

60

Usability Test 12This chapter describes how testing with end users is relevant in the specificcontext of thisproject. As explained throughout this report, our approach to XP was to use it in a situation,where the customer is unable to sufficiently represent all end users. The tests conducted andthe results of these are described as well.

12.1 Relevance

As the system is meant to be released as an online system possible to access for basicallyeveryone, its success rate will predominantly depend upon user satisfaction. Moreover thesystem is intended to be non-profit meaning sparse publicity. This increases the significanceof usability, as the system needs to promote itself through everyday use.Taking all this into consideration user testing is relevant to ensure usability bylistening toand understanding users’ needs, work routines, skills, vocabulary,habits, etc. and subse-quently use this knowledge to improve the system. An approach to this is testing withendusers while developing, and thus avoid releasing a system that to some extent will be uselessor pointless to use. [DialogDesign.dk 2001]

12.2 Release Test

When working with XP, after a number of iterations you come up with a release.A releaseis a version of the system containing the functionality attained, at the given point of thedevelopment. At this point in the progress, it seems natural to bring in user testing, as younow have a system suitable for testing. However, as the releases in XP aremeant to be duein short intervals, doing extensive testing with a large amount of users andmajor analysis,would in most cases demand relatively large amounts of time, and stifle the development.Considering the fact that the system requirements in XP constantly are subjected to change,this way of testing might even be an overkill, as the test result will become worthless ina case of major changes. Furthermore, as the system continuously changes, it holds moresense calibrating the amount of test work with the size of the current release, and instead ofone big test, make a number of minor tests. As the problems found in the tests are corrected

61

12.2 Release Test

along the way, the following tests should reveal whether the corrections are sufficient or not.Therefore we decided to test our first release with end users, sum up the results, fix the prob-lems, make a new release, and test again. When testing with potential end users, a minimumof four to five participants are expected, as this has shown to be adequate, to expose about80% of all problems in a system [Rubin 1994]. As the setup here being only one extensivetest, compared to our case of multiple tests, we cut back on the amount of participants, tominimize the extent of the test.To decrease the scale of each test even further, we did not conduct apilot test, anotherprinciple that would be expected followed when doing traditional usability testing. The as-sessment was that doing a pilot test after the first test would be redundant, as the tests wouldbe almost identical, only changed according to the previous test, or new implementations.However a pilot test before testing the first release, would be well-founded, as a way tomake sure the test is not biased and that the assignments are unambiguous.

12.2.1 Test Goals

The main objective of the test was to examine, whether it makes sense for the participantsto use the system, in related to the job as a coach. Secondarily we wanted to testif the workflow using the system is perceived by intuition. The third purpose of the testwas to locateand note bugs in the system.

Subsidiary we also want to review the actual test, to improve the assignments.

62

User Stories 13This chapter describes how the user stories were made, and how they were estimated.

13.1 Designing The User Stories

User stories are an essential part of developing with XP, and are made bythe customerin cooperation with the development team. In our case none of the parties involved hadpreviously designed user stories. As a consequence, we had some difficulties extracting thespecific wishes from the customer, enabling us to make user stories.

To rectify this, we started asking questions about the desired functionality of the system.Doing this we were aware that it was completely up to the customer to decide and demandwhat should be contained in the system, and not us. At an earlier meeting, thepurpose ofthe system was introduced. Therefore several functions had alreadybeen discussed, makingit difficult not to ask leading questions pointing towards one of our own suggestions.

To ease the continued making of user stories, we produced several paper prototypes forthe third meeting, based on the statements from the second one. This approach seemed tobe more effective in our context, rapidly making progress designing userstories, becauseit was easier for our customer explaining functionality from a visual prototype, than withplain words.

The two meetings produced a lot of thoughts and requests regarding the functionality of thesystem, which we had to sort out and turn into user stories.

We drew a sketch on the blackboard, to get a view of all the details of the program, howthe different pages of the program would be connected, and what functionality they shouldcontain.

63

13.1 Designing The User Stories

Figure 13.1: Navigation diagram of the program.

This drawing, illustrated by Figure 13.1, helped us depict the structure andnavigation ofthe program.

The following is an example of a user story, written in the notation used when dealing withthe customer.

• LoginboksDer skal være en sektion hvor brugeren kan logge sig ind i systemet, med brugernavnog password.

64

13.2 Estimating Units

The user stories derived from the drawing, Figure 13.1, were presented to our customer tobe either accepted or rejected.

13.2 Estimating Units

After the user stories were designed, units had to be assigned. This process is based mainlyon background knowledge, as it demands developers to assess the amount of units is re-quired to develop each function of the system.

Before starting the estimating of user stories, we decided that the customer would get dis-posal over 40 units for the first iteration. With that in mind, we chose the userstory whichwe believed to be most difficult to develop, and assigned the maximum amount ofunits. Allother user stories were given units assessed relative to this one.

The user story exemplified in Section 13, was assessed to last 15 units, as shown in paren-theses:

• Loginboks(15)Der skal være en sektion hvor brugeren kan logge sig ind i systemet, med brugernavnog password.

The amount of units first estimated for each user story, were adjusted as the project movedalong. This was done as a result of our improved skills in programming, and the fact thatwe improved at estimating the time a given user story would take to complete.

65

13.2 Estimating Units

66

Iterations 14This chapter describes the actual development process through the different iterations. Fig-ures used throughout this chapter are all from the final prototype, and may in some casesnot completely reflect the version being described.

14.1 Short Description Of The Final Product

MuKuFo is a web application, which allows users to create and translate miscellaneous doc-uments into Arabic, Somali, and English. Figure 14.1 shows the possible ways of navigationthrough the system. It is implicit that all pages offer the possibility to return to theFrontPage. When a user enters MuKuFo.dk the first page encountered is the Front Page. Thiscontains a small description of MuKuFo, a link to the help section, a link to standardized let-ters, a link to templates, and a login box. The Help section contains a variety of help texts,describing how to use the system. The three links in the bottom left section of theFrontPage offers access either directly to the Workbench or the Document Selector section. Ifthe user has an account on MuKuFo, the login box can be used to gain access to previouslysaved documents. The user is most likely to end up in the Workbench section,where allcreating, editing, and saving of documents takes place. When the documentis finished, theuser can choose to translate it. From the Translated Document section it is possible to save,print, and email the translated document. This section also provides the option of returningto the Workbench, enabling the user to further edit the document.

67

14.1 Short Description Of The Final Product

Figure 14.1: Navigation through the system

Table 14.1 contains a lists of the iterations we have completed and the user stories imple-mented in the respective iterations. The Danish translation in the parenthesesfollowing thename of the user story is the reference name used in Appendix A, where a description of alluser stories can be found.

68

14.2 First Iteration

Iteration Period Units User stories1 18/3 - 3/4 40 - Version View ("Oversigt")2 3/4 - 13/4 20 Welcome Text ("Velkomsttekst")

- Access to Standard Document("Adgang til Standarddokument")

- Access to Template("Adgang til Skabelon")

- Access to New Document("Adgang til Nyt Dokument")

- Help Text ("Hjælpetekster")- Help Section ("Hjælpesektion")- Sender ("Afsender")- Categories ("Kategorier")

3 13/4 - 20/4 20 Print("Print")Guide ("Vejledning")

4 20/4 - 25/4 0 Corrections after first release test5 25/4 - 29/4 0 Corrections after second release test

Table 14.1:Overview of the iterations

14.2 First Iteration

14.2.1 User Stories

Our customer was given 40 units to his disposal. He chose the following userstory to beimplemented:

• Version view ("Oversigt") 40 units

We allowed the costumer to choose auxiliary user stories for us to work on, incase we hadunderestimated, how much we could in fact implement in the time available for the iteration.

Auxiliary user stories:

• Translate Document ("Oversættelse") 10 units

• Print ("Print") 7 units

• Mail ("Mail") 17 units

14.2.2 Summary

Since this was our first iteration, we had a lot of basic features to programfor the system.We had to make quite a few decisions on how the system should actually be designed. The

69

14.2 First Iteration

database had to be established, and main classes needed to be designed before we couldstart solving the user story. We decided to split the user story into smaller parts, so that allprogramming pairs could start programming. We split the assignment into tasks concern-ing database structure, theDocument class, and the web interface that would provide thevisualization of the translated versions of the document. The auxiliary user story ’TranslateDocument’ was completed as well.Neither we nor the customer had decided on a name for the system, so the project got theworking title MuCuPo, which is an abbreviation of ’Multi Cultural Portal’.

14.2.3 Product

At the end of the iteration we had a draft of the document class, which is an essential partof the system. Figure 14.2 shows the final class definition:

Document

HashMap contentArrayList orderString headerString stdTextint ownervar language

addItem()removeItem()moveUp()moveDown()

Figure 14.2: Document class

Instances of the document class are continuously used throughout the system. To makesure that this vital class was paid the proper attention, the design and implementation wasassigned exclusively to one programming pair as their only task. The class changed throughlater iterations, but the main idea behind the design had been established.The purpose of the class is that it contains all the information of a document. TheHashMapcontent is used to store the different elements of the document. The key of each entry intheHashMap, is the label of the element and the value is whatever content the user filledin. e.g. if a user creates a document with a element called "Tid", and then fills in"10:30",the HashMap would contain:

[Tid] => ”10 : 30”

Besides the document class, the main structure of the database was created. Figure 14.3shows the structure of one of the most essential tables, mucupo_dictionary.

70

14.2 First Iteration

mucupo_dictionary

ID intcategory varchararea varcharDansk varcharEngelsk varcharSomalisk varcharArabisk varchar

Figure 14.3: mucupo_dictionary

We structured mucupo_dictionary so that each word had its own row in the table, and therespective columns contained the corresponding word in English, Somali and Arabic. If theword is supposed to be an element the user can add to a document, a categori is assigned.The word will then appear in the toolbox, explained in Section 14.3.

14.2.4 Client Meeting

Agenda of the meeting:

• Status

• Choosing new user stories

• Method

We presented the work we had during the iteration. The customer made a request to see howwe had solved each individual user story. Since it was the first iteration tobe completed,there was a lot of underlying programming done, but no fancy user interface. The systemconsisted mainly of standard HTML forms and tables, and it was evident thatthe customerhad expected to see something more completed. This caused a bit of confusion and thecustomer seemed to lose a little faith in the development team. As the meeting proceededthe process of creating a system was clarified to the customer. This way he gained anunderstanding of why the system looked like it did, and that the underlying functionality atthis point was our main priority.During the meeting the name of the system was discussed, but no better alternative wasfound. It was however decided to use the Danish version of the prior name, ’Multi-KulturelPortal’, why the abbreviation was changed to MuKuPo.

71

14.3 Second Iteration

14.3 Second Iteration

14.3.1 User Stories

For this iteration we gave our customer 20 units, due to the fact that the iterationperiod wasshorter than the last. He chose the following user stories to be implemented:

• Welcome text ("Velkomsttekst")(2)

• Access to Standard Document ("Adgang til Standarddokument")(1)

• Access to Template ("Adgang til Skabelon")(1)

• Access to New Document ("Adgang til nyt dokument")(1)

• Help Text ("Hjælpetekster")(2)

• Help Section ("Hjælpesektion")(3)

• Sender ("Afsender")(3)

• Categories ("Kategorier")(3)

Auxiliary user stories:

• Save Document in Database ("Gem Dokument i Databasen")(10)

14.3.2 Summary

An obvious advantage for many of the user stories in this iteration, was the implementationof the Workbench, where the user can work with the documents. During thelast iterationa basic skeleton of this was constructed, in order to work with the TranslatedDocumentsection. This eased the implementation, but still a lot of work on the graphic interface workhad to be done.To be able to select which type of document to work with, the Front Page hadto be devel-oped as well. It was decided to let the customer produce the welcome text, butbesides fromthat all user stories were completed. The auxiliary user story was completedas well, andthe feature to select previously saved documents was added.

14.3.3 Product

At the end of the iteration, quite a few changes had been made. The major change was thatwe now had a draft of the interface. We made the class Functions.java, which contains staticmethods used for producing HTML code. An example is Code snippet 14.1 that shows thefunctiontop(). This generates HTML used in each page of the system, i.a. Doctype defi-nition, stylesheet reference, and table definitions:

72

14.3 Second Iteration

public static String top(String title, StringtdClassStyleToStartNext){

String topString = "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD" +"HTML 4.01 Transitional//EN\"><html><head><title>" +"MuKuFo - "+title+"</title><link rel=\"stylesheet\" " +"type=\"text/css\" href=\"style.css\"></head><body>" +"<center><table class=\"greatBody\" cellpadding=\"0\"" +"cellspacing=\"0\"><tr><td colspan=\"2\" class=\"head\"" +"align=\"right\"><a href=\"index.jsp\" " +"class=\"indexLink\"></a><a href=\"about.jsp\" " +"class=\"aboutLink\"></a></td></tr><tr><td><div id=\""+tdClassStyleToStartNext+"\">";

return topString;}

Code snippet 14.1:Function that generates header used on most pages

Much of the main functionality was established in this iteration, and it was now possible toselect a document type, work with it, and finally translate it.

Figure 14.4: One way through the system, when working with a document

73

14.3 Second Iteration

When working with a document the Toolbox, shown in Figure 14.5 is an important feature.

Figure 14.5: The Toolbox used when working with a document

The Toolbox contains all elements, that can be added to a document. It is therefore consid-ered to be a vital part of the Workbench. The Toolbox was made to dynamically open andclose the various categories of words, upon user interaction. This way the limited spacedis better utilized. This visual manipulation was implemented using JavaScript. This waychanges in the interface need not be transmitted over the internet, but will beexecuted onthe client-side. The JavaScript function for performing the change of thetoolbox, is shownin Code snippet 14.2.

function setHeight(){i+=20;closeHeight = 200 - i;document.getElementById(last+"_div").style.height=closeHeight;document.getElementById(elemIdC+"_div").style.height=i;if (i>=200){

clearInterval(rollDims);document.getElementById("icon_"+last).src=plus.src;document.getElementById("icon_"+elemIdC).src=minus.src;document.getElementById(last+"_top").style.cursor=’pointer’;document.getElementById(elemIdC+"_top").style.cursor=’default’;document.getElementById(last).style.display=’none’;last = elemIdC;

}}

Code snippet 14.2:JavaScript function changing the toolbox

74

14.4 Third Iteration

ThesetHeight() function is called repeatedly when the user clicks to open another cat-egory of words. Every time the function is called, the variablei is increased by 20. Theheight of an open section is 200 pixels and with this as a starting point, the new height ofthe section being closed, thecloseHeight, is calculated. Whilst one section is closing,another is being opened, the height of this is defined byi. When the value ofi reaches200, the sections that have changed now switch icons from a plus to a minus or the reverserespectively. Similarly the cursor is changed from a hand pointing to the default cursor,normally an arrow.Clicking a word in the toolbox causes the whole workbench to be reloaded, with the wordclicked passed as a parameter.Even though being a part of the workbench, the toolbox is implemented in a separate file.This file is included in the JSP file that generates the workbench. This way any changes tothe existing toolbox, or an implementation of a completely new toolbox, will not affect theworkbench.

14.3.4 Client Meeting

At the end of this iteration, the system was far more developed than after the last iteration.Our customer found this reassuring and regained his faith that the prototype indeed wouldbe put into reality.The issue of copyright of pictures used in the prototype was discussed,and suggestions fornew photos were made. As the intention of this project never was to deliver acompletesystem, it was decided not to touch on this subject any further.

14.4 Third Iteration

14.4.1 User Stories

This was the last iteration before the planned usability test, hence this would bethe iterationfinishing first release of MuKuFo. Our customer was given 20 units, andhe chose thefollowing user stories:

• Print("Print")(7)

• Guide ("Vejledning")(16)

Even though the system’s basic functionality at this point was established, it still lackedsome consistency between the different parts. The customer stressed that this should befixed before a usability test would be conducted. Thus making the system consistent wasmade as an assignment during this iteration.

75

14.4 Third Iteration

Auxiliary user stories:

• Login ("Loginboks")(15)

• Logout ("Log ud")(2)

• Mail ("Mail")(17)

14.4.2 Summary

In this iteration, besides solving the user stories, we had to design the usabilitytest which isdescribed in Chapter 12. We decided to split the iteration into two phases. First we wouldimplement the desired user stories and after finishing this we would start designing the test.We solved both primary user stories, and managed to complete ’Login’ and ’Logout’ aswell. We designed a draft for ’Mail’, but we decided to put this aside. Untila web hotelhad been selected, we would not know the mailing module used by the actual web hotel.The problem with ’Mail’ was that there are more than one Java package forsending mail.Which one to use would be decided by the choice of the future web hotel of the system.Instead we proceeded to design the test, which is described in Chapter 12.

14.4.3 Product

At the end of the iteration, a lot of aesthetic features had been added to the system. Thisincluded uniforming the design of all pages, to make the system more consistent. Further-more the graphics and styling of the entire system, was redesigned to achievea more elegantand professional look.The ’Print’ user story was completed as well, such that a new window opensif the userchooses to print. This window contains the document in the selected language, and auto-matically opens the standard print dialog box. Figure 14.6 shows a documentready to printin Arabic, as it appears in the final prototype.

76

14.4 Third Iteration

Figure 14.6: Print document interface

In the first implementation the toolbar, seen at the top of Figure 14.6, was not visible. Thereason for adding this, is explained in Section 14.5.

To complete the ’Guide’ user story, the structure for the guide section was established andthe main help texts were written. To prepare the system for future change every bit of text inthis section, is stored in the database, and fetched when needed. Furthermore it was madepossible to edit all texts through the web interface. This is a feature that should later bemade accessible to administrators of the system.The auxiliary user stories for this iteration, concerned making it possible for the user tolog in and out. To be able to log in, an interface for creating a user was needed. This wasmade to appear in a separate window, and will not interrupt the user while interacting withthe system. To ensure that the system holds the needed information about theusers, it wasmade obligatory to fill in certain areas in the interface. The mandatory fields were markedby stars. In the first implementation the stars were placed after the respective input fields. Inthe final prototype these stars were placed immediately before the mandatory input fields.

77

14.5 First Release

The motivation for this is explained in Section 14.5.To be able to log a user in or out of the system, aUser object was added to the system. Forthat we used the JSTL (Java Standard Tag Library) expression language, as seen in Codesnippet 14.3.

<jsp:useBean id="loggedInUser" scope="session"class="dk.mucupo.util.User" />

Code snippet 14.3:A User object initialized using JSTL

The Code snippet is used for both initializing anUser object and finding any existing objectwith same name and scope. In JSP the scope of objects is defined at the initialization, withthe possible valuespage, request, session andapplication. Theuser objectwe added had the scopesession, meaning that the object will be available as long as theconnection between client and server is maintained.When a connection between a client and a server is established, a dummyUser objectis initialized. If a user subsequently logs in, a new object is initialized with informationfetched from the database. This new object replaces the prior dummy object, and fromall parts of the system it is now possible to retrieve information about the current user, byinvoking methods on the object. On log out theUser object is removed, and once the pageis reloaded, a new dummy object is created.A user information that needs special treatment is the users personal password. To keepthe password personal, we used MD5, an algorithm with the ability to uniquely encrypt anymessage given [Rivest 1992].

14.4.4 Client Meeting

The client meeting was held immediately before the usability test. Therefore focus wasprimarily on the upcoming test, and changes to the system were only briefly presented tothe customer.

14.5 First Release

In our case the first release was ready after three iterations, and the test was planned accord-ingly. The test in Danish can be found in Appendix B.1.

The test was conducted with two participants, both active coaches. The contact was estab-lished by our customer, as a way to get participants that could be future endusers. Besidesfrom demographic facts collected through the questionnaire subsequentto the test. The par-ticipants will be kept anonymous, instead we will refer to them as participant p1 and p2.Demographic facts, additional thoughts, and opinions towards the system expressed by p1and p2 are located in Appendix C.1 and C.2 respectively.

78

14.5 First Release

14.5.1 Participants

Both participants stated that they used computers on a daily basis, but p2 did not use the webregularly and had limited experience using web based systems. This variationin character-istics is beneficial, regarding the result from a usability test. With one participant using webbased systems on a daily basis and one hardly using web based system at all, the test wouldreveal problems encountered by both experienced and inexperiencedusers. This makes thetest results relevant both towards usability issues regarding intuitive and more advanced use.

14.5.2 Test Results

For the test of both first and second release, problems uncovered arelisted in the first column’Problem’, in the respective tables following. The second column ’Reason’ is our analysisof the problem, where we explain why the problem occurred. The third column ’Action’,shows the necessary steps to be taken to correct the problem.

Table 14.2 gives an overview of the system related problems uncovered by the test of firstrelease.

# Problem Reason Action1 In the help section,

explanatory links aremistaken for redirectinglinks.

The explanatory linksare similar to redirectinglinks.

The links are made as infoicons, after the words thatneed explaining.

2 The help section is todense in text.

Participants do not readthe text.

Help section must containless text, making it easierto read.

3 The explanatory texts forthe three types of docu-ment are incomplete.

The texts are only tempo-rary, and not descriptive.

The explanation for thethree types of documentsneeds to be changed intosomething meaningful.

4 When creating a user, par-ticipants fail to noticewhich fields are manda-tory.

Mandatory fields are notmarked sufficiently clear.

The star that marksmandatory fields, mustbe placed immediatelyafter the text in front ofthe input field, instead ofafter the input field.

5 Participants fail to noticeerror messages that followwhen a mandatory field isnot filled out.

Error messages are notconspicuous enough.

"Making a user" needsto be changed, in orderto make error messagesand demanded fields morevisible.

79

14.5 First Release

# Problem Reason Action6 Participants fail to un-

derstand the intentionof "Kodeordshuske-spørgsmål".

"Kodeordshuskespørgsmål"is a bad choice of wordand it is not clear to theuser what the intention ofit is.

Delete "Kodeordshuske-spørgsmål".

7 The users have troublegetting back to the frontpage.

The link to the frontpage is not conspicuousenough.

The system needs aclearly visible link to thefront page.

8 The help section is choseninstead of the various doc-uments.

The help section lookslike a list of shortcuts tothe documents.

Access to the help sec-tion from the Front Pageneeds to be changed, sothe users are aware thatthey are using the helpsection.

9 The participants do notuse the garbage bin todelete lines.

None of the users findit intuitive to delete linesfrom a document.

The garbage can, will bechanged to a red cross.

10 The word "Oversæt" con-fuses the users, and thefunction is not used be-fore printing the Danishversion.

It has several senses andis not precisely describingthe action.

Find another word for the"Oversæt" link.

11 It is not possible to savethe document once theusers have translated it.

The users have to go backto edit the document in or-der to save.

It should be possible tosave when the documentis translated.

12 Some users did not get thedocuments printed.

Users seem confusedabout the word "Print".

"Print" should be renamedto "Udskriv".

13 It is not possible to fill outa standard document.

The participant could notunderstand that he wasunable to write on theline, as it had been possi-ble earlier in the program.

Text fields which arewritable, will get anotherbackground color to makethe user aware that thesefields are writable.

14 The participants do notuse the toolbar.

The toolbar is not con-spicuous enough.

The toolbar needs to bemade more visible. Moveit to the top and make itorange.

15 The users did not put aheading on the document.

The part "Overskrift" isnot conspicuous enough.

The part "Overskrift"in the "Værktøjskasse"needs to be moved to thetop of the box.

80

14.5 First Release

# Problem Reason Action16 The users had trouble

finding words in the"Værktøjskasse".

The words are not listed inalphabetical order.

Words for each categoryin the "Værktøjskasse"must be listed in alphabet-ical order.

17 Words that are not inthe "Værktøjskasse" can-not be added.

The list of words was in-adequate for the users.

It must be made possiblefor users to request newwords for the system.

18 It is not possible to over-write, update or deleteearlier saved documents.

The test showed that itwas not possible to savea document if a documentwith the same name al-ready existed.

The save function, have tobe extended so it is pos-sible to delete and over-write documents in thedatabase. The ability tosave documents with thesame name as the onesin "Standarddokumenter"should also be made avail-able.

19 The system fails when auser, with no previouslysaved documents, choosesto list own documents.

The system contains anerror when checking forearlier saved documents.

The system needs tocheck if the user has anysaved documents.

20 The system fails to reg-ister alterations made todocuments.

As the users worked withdocuments, the systemsometimes deleted thetyped in text.

When the user is editinghis document the correc-tions need to be saved.

Table 14.2: System related problems uncovered by the first test.

Our customer was present in the observing room during the test, and had specific commentsto corrections in the system. These corrections are stated in Table 14.3 together with specificproblems found by the development team during the test.

81

14.5 First Release

# Problem Reason Action1 It is possible that the user

will have trouble under-standing the help text.

Help in some cases tootechnical.

It is decided that the ad-ministrators will be giventhe assignment to finishthe help texts.

2 Users think they have tocreate an account to beable to use the system.

The option to use the sys-tem without being loggedin, is not obvious enough.

It needs to be clarified,that the system can beused without the user be-ing logged in.

3 It is possible that the usercannot find the appropri-ate header.

The predefined headers inthe system, are inade-quate.

The user should be giventhe possibility to insert ablank heading which af-terwards can be filled outmanually.

4 The earlier used work-ing title MuKuPo is stillfound various places inthe system.

The system has not beenthoroughly correctedsince the name changed.

Correct the name in thecode.

Table 14.3:Problems found by customer or development team

As with most of the problems found by the participants shown in Table 14.2, these problemswere improvements for the second release.

Table 14.4 provides an overview of problems found with the actual test after testing the firstrelease.

# Problem Reason Action1 The participant’s first-

hand impression is notfirst-hand after using thesystem for a while.

We need to record impres-sions before the partici-pant moves on using thesystem.

Participants must be morespecifically asked aboutfirst-hand impressions ofthe system at the begin-ning at the test.

2 The user was to some ex-tent dictated how to solvea task.

The question was tooleading.

Adjust question three,"update the template".

3 The participants haveproblems printing.

The printer is located ina different room, and anumber of different print-ers are installed.

A printer is placed in thetest room, and other print-ers are uninstalled.

Table 14.4:Problems in the test design

82

14.6 Fourth Iteration

The problems found with the test, shown in Table 14.4, were problems regarding the testdesign. Correcting these improved the test for the second release.

14.6 Fourth Iteration

14.6.1 User Stories

This iteration consisted of conducting the usability test, dealing with problems found inthe test, and preparing the second release of the system. It was in consensus with the clientdecided, that no units would be assigned to user stories for this iteration. Instead the iterationwould be dedicated to dealing with problems that had emerged doing the usability test.

14.6.2 Summary

The iteration began with the usability test described in Section 14.5. After the test wehad plenty of assignments to finish, most of which concerned aesthetic features. We keptworking in pairs, but instead of solving user stories we had a list of problems which weredivided between the pairs. One pair was mainly assigned graphic tasks whileanother wasassigned programming tasks, and the third pair was assigned to rewrite the help texts.

14.6.3 Product

When the iteration was finished our product design was aesthetically improved. We discov-ered that text links were not always sufficient to guide the users through the system. Anexample of this is the link to translate the document, which before the test was a plain textlink positioned on the toolbar at the bottom of the page. We decided to move the toolbar tothe top of the page and created icons to illustrate the actions available. See Figure 14.7

Figure 14.7: Toolbar with icons

A feature that none of the test participants discovered, was the ability to remove an elementfrom the document. This was symbolized by a garbage bin positioned to the right of theelements in the document. We decided to change this to a red cross, which wouldstand outfrom the other options the user had to manipulate elements in the document. See Figure14.8.

83

14.6 Fourth Iteration

Figure 14.8: Garbage bin replaced with a red cross

Another feature that needed to be more visible to the user, was the option to return to theFront Page. Since all test assignments ended with the user returning to the Front Page, theproblem repeated itself in the usability test, thereby emphasizing that it neededto be dealtwith. Before the test, the link was located in the picture at the top of the page. This was notobvious to the participants, why we changed it to an icon with explanatory text,see Figure14.9.

Figure 14.9: Link to frontpage

An essential part of using the system, is filling in the document. Before the usability test,the text fields the user was intended to fill in, were only represented with a black line atthe bottom of the field. This was misinterpreted when a participant was asked touse astandardized document. The participant thought the black lines in the text could be filledin. The intension of standardized documents are to print these out and thenfill them inmanually, see Figure 14.10. This naturally caused some confusion. Therefore we decidedto alter the text fields giving them a light blue shade to make them appear more clear to theuser. This is illustrated in Figure 14.11.

Figure 14.10:Standardized text with empty lines

84

14.7 Second Release

Figure 14.11: Improved distinction of text fields

14.6.4 Client Meeting

The focus of the meeting was primarily the results of the first release test. Ourcustomerwas very please to have been present at the test. Especially he noticed problems previouslyundiscovered by the development team, were revealed during the usability test. This indi-cated that the release test was relevant. We discussed the problems that had been uncoveredand showed the improvements that were implemented in the fourth iteration. All in allthecustomer was satisfied.

14.7 Second Release

The test of the second release was conducted with only one participant, since the secondparticipant did not show up. Contact to these participants was arranged by our customer aswell. We will refer to the participant in attendance as participant p3. Demographic factsand additional thoughts and opinions towards the system expressed by p3are located inappendix C.3.

14.7.1 Participants

According to the questionnaire, p3 used a computer for less than one houra day and wasnot very familiar with the internet or web based applications in general. This categorizedp3 as a novice user and the problems uncovered in this test, were therefore relevant to basicand intuitive usability issues.

14.7.2 Test Results

Table 14.5 provides an overview of system related problems uncovered by testing the secondrelease.

85

14.7 Second Release

# Problem Reason Action1 Confusion as of why user-

name and password mustbe typed twice when cre-ating a user.

When creating a new user,username and passwordwere typed in the loginarea of the Front Page,before the button "Opretbruger" was pressed. Sub-sequently it was ques-tioned why this informa-tion was not passed on tothe registration page.

Transfer username andpassword from the FrontPage to the registrationpage.

2 The system does not sup-port usernames contain-ing the characters æ, ø,and å.

The system fails to recog-nize a user at logging in,as the name contains theletter ø.

Support for the specialDanish letters must be im-plemented.

3 The registration form ac-cepts any form of input ase-mail address.

P3 interpreted the field’E-mail’ as a place to in-put a desired e-mail ad-dress, that subsequentlywould be created for thenew user.

Implement validation ofe-mail address input inregistration form.

4 Inserting a new keywordcaused the informationtyped for the previouskeyword to disappear.

As the user worked withdocuments, the systemsometimes deleted thetyped in text.

When the user is editingthe document, changesneed to be saved.

5 It is not conceived thatthe print function in thebrowser and the printfunction in the system isnot coherent.

P3 confuses the printfunction of the systemwith the print function ofthe browser.

The use of the differ-ent buttons in the systemshould be clarified.

6 The dialog that appearswhen clicking the "Man-gler du ord?" link doesnot clearly state, that thepurpose is to request newwords for the system.

The link used to requestnew words in the sys-tem, is mistaken for asearch function, wherewords can be found.

The exact purpose ofthe function needs to bestated in the dialog box.

86

14.8 Fifth Iteration

# Problem Reason Action7 When saving a document,

it is not possible to browsethrough earlier saved doc-uments, and this waychoose to overwrite or up-date documents.

The participant wanted toupdate an earlier saveddocument, but did not re-call the name of that par-ticular document.

The ability to browseearlier saved documentsmust be implemented.

Table 14.5: System related problems uncovered through the test ofsecond release.

All the problems uncovered by the test of second release, listed in table 14.5, were allencountered by the participant.

14.8 Fifth Iteration

14.8.1 User Stories

The fifth and last iteration only lasted a short period of time, and consisted ofcorrectingproblems found in the usability test of second release. As the prior iteration,this iterationwas dedicated to dealing with problems that was uncovered by the usability test.

14.8.2 Summary

As this iteration was ended by the finalizing client meeting, only one programming pair wasassigned to work on the system. The remaining pairs prepared needed material and presen-tation for the meeting. No parts of the system were severely changed through this iteration,but still important functionality was implemented.

14.8.3 Product

The first problem found in the second release test, was to transfer username and passwordfrom the Front Page to the registration page. This was a fairly easy task solved, as it was asimple matter of passing parameters.Problem number two, to implement support for special Danish letters, proved no harder tosolve. This was a case of defining the correct character set and pageencoding. In JSP thisis done at the top of each JSP file, an example is shown in Code snippet 14.4.

87

14.8 Fifth Iteration

<%@page contentType="text/html;charset=ISO-8859-1"%><%@page pageEncoding="ISO-8859-1"%>

Code snippet 14.4:The definition of charset and page encoding in a JSP file

If an unwanted character set or page encoding is defined, characters will be encoded ordecoded to something other than intended.The third problem concerned validation of e-mail address in registration form. This wassolved by making the system read the input and verifying if the submitted text containedan @ or not. This is by no means a guarantee that users are unable to enter an invalid e-mail addresses, as any text string containing an @ will check out ok. However this solutionwould prevent this specific situation from occurring.The fourth problem concerns, that changes need to be saved, when the user is editing thedocument, demanded more restructuring. This problem was a recurrent problem from thetest of first release, that had not successfully been solved. The problem concerned the inputfields in the document as shown in Figure 14.12.

Figure 14.12: Input fields in a document implemented in individual forms

In both first and second release, each line with an input field was implementedas its ownform, as illustrated in Figure 14.12. This meant that to submit changes to any input field inthe document, the whole document needed to be reloaded. An unfortunate implementation,as this resulted in the page reloading very often. Furthermore to ensure that all changes weresaved, the page needed to be reloaded before any actions were performed on the document.To improve this, a different implementation was needed. The improvement was toincludeall input fields in the same form, such that change in any input field will be saved, wheneverthe page is reloaded.Fifth issue that needed to be dealt with, was that the use of the various buttons in the systemshould be clarified. The solution for this can be seen on Figure 14.13.

88

14.8 Fifth Iteration

Figure 14.13:Tooltip

Every button in the toolbar was applied a tool tip text, that appears when the mouse ispositioned over the button.To fix the sixth problem, the exact purpose of the function "Mangler du ord?" (Missingwords?) needed to be stated. This was done by adding a short explanatory text to the dialogbox, as shown in Figure 14.14.

Figure 14.14:The dialog that appears when using the "Mangler du ord?" function

The seventh problem was solved by retrieving all names of documents saved by the userlogged in, and subsequently displaying these in a dropdown menu, see Figure 14.15.

Figure 14.15:The dropdown menu showing previously saved documents when saving

89

14.8 Fifth Iteration

14.8.4 Client Meeting

This meeting was the finalizing meeting of the development phase. The agenda was asfollows:

• Demonstration of the final prototype

• Review of the usability test

• What is yet to be implemented

As the system was being demonstrated, the customer noted a few things that needed atten-tion:

• The terms used in the system should primarily be Danish, e.g. ’login’ should be’logpå’

• The words under the different document types wrap awkwardly

• The word MuKuPo is still found in the system

• Help should be accessible from any part of the system

At the last release test, no major issues had been encountered and the fewchanges thathad been made, was accepted by the customer. The customer noted that it would be veryinteresting to test the printed documents, to ensure that they have the desiredeffect.Giving the customer an idea of how big a part of the system still needed to be implemented,a list with the uncompleted and refined user stories was presented.

90

Final Product Description 15The final product as it looked like after our fifth iteration is described in this chapter.

15.1 Front Page

Figure 15.1: The Front Page of MuKuFo.

The Front Page consists of a header, a text area, a template section, a login box, a helpsection, and a footer.

91

15.1 Front Page

15.1.1 Header

The header is consistent throughout the system. It contains the name MuKuFo, a picturebar, and two links: ’Om MuKuFo’ and ’Til forsiden’. The two links are represented bya descriptive label and a small icon. The link ’Om MuKuFo’ has a small ’i’ traditionallyassociated with information, and links to the page ’Om MuKuFo’. A descriptionof the page’Om MuKuFo’ can be found in Section 15.4. The link ’Til forsiden’ has a small house asicon, and directs the user to the Front Page.

15.1.2 Text Area

The text area contains a short description about MuKuFo. This is intended to welcomethe user and explain what the system can be used for. Furthermore it contains informationabout the people who participated in the development of the system and who contributedeconomically.

15.1.3 Document Area

The document area consists of three parts: ’Nyt dokument’, ’Skabelon’, and ’Standarddokument’. ’Nyt dokument’ links to ’Rediger Dokument’. In system terminology it isknown as the Workbench which is described in Section 15.2. Here a new document can becreated from scratch. ’Skabelon’ links to the page ’Vælg Dokument’, described in Section15.5, where the user either can select a document of his own, a template created by theadministrator, or a standard standard document. The last mentioned is also where the thirdpart of the template area, ’Standard dokument’, links to. A short description of where thelink direct the user, is present in all three parts.

15.1.4 Login Box

The login box is a central part of the Front Page, because it grants access to features onlyavailable when the user is logged in. Under the login box is a small description of thebenefits if the user logs in.

15.1.5 Help Section

The help section consists of a link to the help pages, described in Section 15.6

15.1.6 Footer

The footer in the MuKuFo system is consistent throughout the system. It consists ofthree links: ’Ansvarserklæring’, ’Kontakt webadministrator’, and ’OmMuKuFo’. The

92

15.2 Workbench

’Ansvarserklæring’ links to a disclaimer. ’Kontakt webadministrator’ opens the user’s stan-dard email client, with the address ’admin@mukufo.dk’ typed in the ’address’line. ’OmMuKuFo’ links to the same page as in the header, described in Section 15.4.

15.2 Workbench

’Rediger Dokument’ is the page that provides the system’s Workbench. This is a centralpart of the prototype, which offers the tools for adding and removing items todocuments.

Figure 15.2: Workbench.

This page is divided into three parts, as Figure 15.2 shows. To the left, is the’Ordkasse’, onthe top is the toolbar, and in the center is the working area containing the document.

15.2.1 Toolbox

’Ordkasse’ is the metaphor used to described the Toolbox on the Workbench. The ’Ord-kasse’ contains all the items possible to add to a document, sorted by category. When theuser clicks on the category, a list of words folds out. By clicking these words, a new linewill appear on the working area. The line starts with the chosen word from the ’Ordkasse’,and is followed by an empty text field which is editable. At the end of every line are threeicons. The first icon moves the line one place up, the next moves it one placedown, and thelast icon removes the line from the document.

93

15.3 Translated Document

It is possible to insert more elements, but only one instance of each element from the tool-box. The words under the category ’Overskrift’ controls an element in the document calledheader. If a header is chosen and one already exists in the document, thenew header willsimply replace the old one, as it is naturel only to have one header on each document.

Just beneath the toolbox there is a link called ’Mangler du ord?’. When following this linka box appears, enabling the user to request words missing in the toolbox. The request willbe sent by e-mail to the administrator of the page.

15.2.2 Toolbar

The toolbar on this page consists of three links, ’Gem’, ’Oversæt’, and ’Afslut’.

The link ’Gem’ with the icon of a floppy disk, enables the user to save the document cur-rently in the working area. Saving a document requires the user to be logged into the system.If the user is not logged in, a dialog will prompt the user to do so. If the usertries to savethe document and the name of the document already exists, this will be presented, and theuser will have the opportunity to overwrite the existing file, or choose another name.

When the user is done working with the document, or just wants to preview the translation,he can follow the link ’Oversæt’. This link leads to the page ’Oversat Dokument’ which isdescribed in section 15.3. Here the translated documents will be presented.

The last link ’Afslut’ is followed if the user wants to finish and return to the Front page.

15.2.3 Working Area

The working area represents the document the user is working on. The area is blanc ifentered via the link ’Nyt Dokument’ on the Front page. Entered from any of the otherbuttons, ’Skabelon’, ’Standard document’, or ’Egne dokumenter’, from the Front page, theworking area will contain items respective to the chosen button.

15.3 Translated Document

’Oversat Dokument’ is the page providing the visualization of the translated versions ofthe current document. From the ’Oversat Dokument’ page the user has the possibility ofpreviewing his document to English, Arabic and Somali and using the features from thetoolbar. The pages main elements are the toolbar at the top of the page and the document.

94

15.3 Translated Document

Figure 15.3: The Translated Document page.

15.3.1 Toolbar

The positioning of the toolbar is maintained from the previous page ’Rediger Dokument’making the GUI predictable and coherent. In the toolbar the links ’Gem’ and ’Afslut’ arestill available and provides the same functionality as previously described. In addition linksfor printing, editing and e-mailing are added. When following the link ’Print’ a new windowopens giving the user the possibility of choosing the printer he wants to use and how manycopies he wants to make. The link ’Rediger’ returns the user to the Workbench where he hasthe possibility to edit the document. By pressing the button ’Send’ it will be possible to sendthe current version of the document by e-mail. This functionality is not yet implemented.

15.3.2 Document

At the top of the document the user can select different tabs representing the languagesthe document is translated to. When selecting e.g. Somali the words in the document aretranslated into Somali, if they are available in the system’s dictionary. Beneath thetranslatedwords the corresponding Danish word is listed in a smaller font. If viewing Arabic versionof the document, the reading direction automatically changes from right to left.

95

15.4 About MuKuFo

15.4 About MuKuFo

About the user is presented to the user as ’Om MuKuFo’. It contains a listof the partiesinvolved in making the web application.

Figure 15.4: The About page of MuKuFo.

The logos on the right, are links to the different parties.

15.5 Document Select

The Document Select page provides a list of all documents saved by the user and all tem-plates and all standard documents made by the administrator. This page is accessed byfollowing the link ’Vælg Dokument’ from the Front page.

96

15.5 Document Select

Figure 15.5: The Document Select page

The Document Select page consists of two dropdown menus, ’Type’ and’Katagori’, and ofthe main window displaying the documents selected to be shown.

15.5.1 Toolbar

There are three ways in to the document select page, all linked from the Front Page, asdescribed in Section 15.1. Depending on which link is chosen to get to the document selectpage, different documents are listed. But the display mode can also be setfrom within theDocument Select page. The four display modes are ’Skabeloner’, ’Standarddokumenter’,’Egne dokumenter’, and ’Alle’. The user’s own documents are shown inall display modes,provided the user is logged in.’Kategori’ is used to sort the documents, by organization type. There arefive possibilities:’Idræt’, ’Hobby og idé’, ’Aftenskole’, ’Spejder’, or all four. Thedisplayed documents willthen be sorted, so only documents in the selected category will be displayed.Only ’Skabe-loner’ and ’Standard dokumenter’ will be affected by this, as the users own documents arenot categorized.

97

15.6 Help

15.5.2 Displayed Documents

This area is displays the documents in respect to the dropdown menues. Theuser have thepossibility to delete his own documents and administrators in addition can delete ’Skabe-loner’ and ’Standarddokumenter’.

15.6 Help

This section provides help for every step of working with documents of anytype. It ispresented to the user as ’MuKuFo Hjælp’.

Figure 15.6: Help.

When a topic in the help section is selected, Help will contain both explanations to thespecific subject and links direct to the functions involved.

98

Part V

Reflections

In this part we present our reflections on the accomplisheddevelopment process. These reflections include discussion,conclusion and perspectives of both the MuKuFo systemand the combined methods utilized to develop this.

99

Discussion 1616.1 Customer Availability

In an ideal XP setting the client would be physically present during the development of theapplication [Jeffries et al. 2001]. In XP terms this is called an on-site customer. One ofthe main arguments for having an on-site customer is that during programming questionswill often turn up that need to be answered by the customer. This happens because the de-scriptions provided by the user stories, often need further clarification during development.If the customer cannot be contacted, the programmer can either start programming a lowerprioritized task that is clearly defined or make a choice on his own. By doing the latter werisk that the customer will turn down the decision later, because it is not whathe wants.Neither one of the solutions are optimal.

In this project we have primarily used literature about XP specifically targeted at studentsworking in an academic environment [Steinberg Palmer 2004]. Thereforethe idea of an on-site customer is not introduced directly possibly due to difficulty in fulfilling this demand inan academic setting. Instead it is said that the client needs to be available as much as possi-ble, which ideally means an on-site customer. The ideal of having the customerphysicallypresent during development is, as mentioned before, not achievable in this context. Due tothe nature of academic projects basically offering no guarantee that the customer will get aworking system, he will most likely be reluctant to use many resources on the project. Itwould also be hard for a customer to adapt to the working hours of an academic environ-ment, where e.g. development of the application might find place in between lectures andduring weekends. During the development of this project, the customer hasbeen availableon phone during most hours and at weekly meetings, but never been physically present dur-ing coding sessions. In this context, where even getting a customer can be difficult, this canbe seen as a high degree of participation even though not fulfilling the idealof an on-sitecustomer.

Even though our customer has been available at most times, there has been asilent mutualagreement only contacting him by phone if the questions were really important.More-over many questions can only answered, if the customer is actually able to seethe system.Thereby phone contact is rendered useless. The implication of this solutionhas been that wehave not gotten answers to all our questions during programming. We had tomake choices

101

16.2 Combining XP With User Testing

risking that the customer would later on turn them down. Even though this approach intheory could become a problem, in practice it has been a success measuredby the numberof times the customer has approved the completion of user stories. The reason might be,that the questions needed to be solved during development often tended to be very sim-plistic not making it reasonable to bother our customer in between iterations. This couldconcern choices dealing with the GUI implementation like color choices and the position-ing of elements that would be relatively easy to correct if rejected by the customer. Mostof the time our customer has been satisfied with the outcome, and therefore the need forcorrections were minimal resulting in nearly no wasted time. The explanation could be thatthe customer is not very demanding, because he is not paying for the system, but this doesnot really correlate with the enthusiasm and eagerness in participating and making the sys-tem as complete as possible, that he has shown throughout the project. A more reasonableexplanation is that he did not have a clear vision covering all aspects of what he wantedthe product to be like. Not having any experience participating in the development of acomputer system, our customer focused on the main functionality of the system, not havinga complete understanding of how the GUI could be implemented. Therefore if the choicesmade by the project group were reasonable and work for him he agreedto the solution.

All though having an on-site customer would be a good way to help ensuring that the systemrepresents the wishes and needs of the customer throughout the process, it is also very costlyfor the customer. Depending on the size of the application being developed,and the typeof customer involved in the project having an on-site customer might not always be anoptimal solution. It might be considered to be a waste of time in situations like ours,whereconference with the customer was rarely needed outside the planned iteration meetings.

16.2 Combining XP With User Testing

XP depends heavily on the knowledge of the customer in the development process, since allinformation about the system being developed comes from the customer. In the case wherethe customer differs from the end user, XP is not suggesting any methods for examiningend user needs. It lacks a general discussion on how to ensure that the end system satisfiesthe needs of real end users. We have not been able to find any obviousreasons, why thissubject has not been considered in XP. A reason could be that XP is suited for experiencedsystem developers, who does not need a thorough explanation on e.g. how to conduct anusability test in relation to XP, or other issues not related to the programming activity thatXP so heavily supports.

102

16.3 XP In An Academic Context

16.3 XP In An Academic Context

16.3.1 Limited Time For Development

If a project is utilizing the XP development method, it is accepted that the project will rununtil the customer is satisfied. XP development usually depends on externalparameters andthat such influencing factors are likely not to behave desirably. This makes the exact timeneeded to reach the final system hard or in some cases impossible to determine. We werenot able to find any official descriptions of how to handle time limited developmentperiodsin relation with XP. In our experience and reasoning the only way to handle this limitationsomewhat considerately, is for the customer to be aware of the deadline when choosing userstories for implementation. In this way the customer can control a prioritized order in whichthe features of the system will be implemented, making the final system contain asmanykey features as possible within the limited time available.

16.3.2 Pair Programming

As a project group we do not have the same qualifications as a professional software de-velopment team. With that in mind it can be questioned if pair programming is suitable forsituations, where developers have limited programming experience or, as in our situation,having programmers with different abilities, paired together for an iteration.

The strength of programming pairs is that the two programmers can take turns programmingand support each other. The advantage of taking turns becomes less effective, when one ofthe programmers is more experienced than the other. The result is often a reluctance toshifting roles and the outcome is that the experienced programmer often will domost of thecoding. Pair programming is normally a way of learning and cooperating, trying to solvea given task. But when the gab in skills becomes too wide between two programmers, theless experienced programmer can quickly be demoted to a bystander.

In spite of this we found, that even though the group members programming experiencediffer quite a lot, the concept of pair programming is still an efficient way of developingsoftware. Even if it means that only one of the programmers is doing most of the actual pro-gramming, the other will still give comments to the code, and intercept errors. Often the lessexperienced programmer will learn a lot from watching someone with more experience.

16.4 XP And Software Philosophy

16.4.1 XP And Complete Estimations

Even though estimates are merely assumptions about schedule and price of the project, theyradically reduce the risks of exceeding budgets and deadlines, and areobviously useful.[Pressman 2005]

103

16.4 XP And Software Philosophy

The Need For Estimates

When estimating cost on a project the purpose is to attain the ability to name a price,asaccurate as possible, and make a feasible offer. The hard competition in thesoftware indus-try makes the ability to estimate a prized asset, that can distinct the company from the restof the competitors. Besides the advantage of knowing how much the project will cost, thecustomer will also be able to foresee whether the schedule is kept. [Pressman 2005] In themechanistic world view, which is based upon the conviction that the world rely on formal-ism, rules and rationality, planning and estimation works well. However, when itcomes tothe romantic world view issues appear.

Romantic System Development

The romantic world view sees the world as being continuously changing, a place that hasno rational explanations, and any description of the world is accordingly asubjective inter-pretation. [Dahlbom Mathiassen 2004] Agile development methods should beconsideredto be romantic, as they have continuously changing system requirements, and are based ona creative process, leaving the programmers to decide how to solve problems.

Agile Estimation

As estimates covering the effort and cost of the project revolves around time expenses, thisneeds to be estimated as accurately as possible. Once we know the size of theproject, wecan make an estimate of how long it will take to implement using how many people and atwhat cost. Representing the agile methods, XP lacks a way to estimate the completecostof time and thereby the price of the project. This is due to the fact that the requirementsfor a project using agile development methods, usually keep changing through the process.[Steinberg Palmer 2004] For this reason estimates, on these new or changed requirementsof the project, are made along the way by the individual programmers. These estimatesrely on personal experience, self confidence, and how much of the previously producedframework of the system being developed, supports the implementation of newfeatures.Therefore, since new user scenarios and thereby new tasks are developed along the way, thesum of all these estimates will differ every time it is calculated.

Though not adding up to an applicable total estimate of the project, these minor estimatesare useful when planning an iteration. The number of units assigned to each user scenario,has to be re-estimated, to be as accurate as possible. This needs to be doneto take accountof changes which has eased or complicated the implementation. The necessity of makingthese changes can come from the customer’s lack of knowledge about what the systemshould be like in the end. It could also be due to a development process thatis relativelylong compared to the speed of changes in the context, which the system is intended tobe used in, or technology available to the system. In these cases a sacrificein means ofmoney and time must be made in order to develop a system that, in a more customized way,meets the standards or requirements of the meanwhile changed context. However since the

104

16.4 XP And Software Philosophy

foundation of a desired complete estimate continuously changes and the partial estimatesbeing the only estimates possible, agile estimation is rendered useless in the context ofestimating the complete extent and time span of a development project.

The lack of entity estimation is a natural shortcoming of these in all other aspectsveryflexible development methods, since the flexibility is gained by allowing the customer tochange requirements as needed throughout the development process.

Summarized, this means that it is not possible to usefully estimate the total cost of aprojectdeveloped with agile methods at the beginning of the process.

Development projects using agile methods can be estimated for each iteration only. Anyattempt to estimate the time and price related extent of the project will be futile, sinceallfoundation for estimation is likely to change frequently.

Considering Traditional Methods

It might seem adjacent to consider using estimation methods from the traditionaldevelop-ment methods, concerning the entity estimation at the beginning of a project. Theextent ofboth project types, will at this point be evenly revealed. The traditional estimation methodsare all based upon comparison to previous projects with similar characteristics. Thus ren-dering this approach likely to cause problems, as the desired output product, and therebythe entire development process, will not be known until it is finished. In both cases it ispossible to make an initial analysis and estimate of the project, but since the agile project islikely, or in most cases bound to change, this estimate will not be useful or realistic for verylong.

16.4.2 More Than A Romantic Approach

Extreme Programming was developed and is commonly accepted as a romantic approach tosystem development. Even though it does contain practices that resembles ideas from mech-anistic, construction and evolutionary approaches, still leans towards theromantic approachabove all.

The course toward the final system goes through many considerations, decisions, and dis-cussions that occur throughout the developing process. Since this is primarily taking placein the programming pairs, the programmers producing the code are in chargeof their ownwork and are fully responsible for it as well. A romantic approach builds oncreativity, andin pair programming creativity has favorable conditions.

The code produced by the programming pair is not assured to stay intact. InXP the codebelongs to all of the involved programmers. Therefore it can be changedlater on by an-other pair without the need for consent. This works very well with the romantic world viewwhere chaos, struggle and change are believed to be important keys to change, evolutionand development.[Steinberg Palmer 2004]

105

16.4 XP And Software Philosophy

XP In Relation To The Mechanical Approach

During development the individual pairs follow a certain guideline, represented by a userstory. The user story lays out the goal for the part of the system, which the pair is about toimplement. Besides the user story, the pair begins their task by writing a test case. This willbe the measurement of whether the programming process worked out as intended or if some-thing went wrong. Though the programming process is mainly romantic, these guidelinescan be considered as rules that apply to the programming process, which isin compliancewith this part of the mechanic way of developing software.

XP In Relation To The Evolutionary Approach

Whereas traditional developing paradigms build on a construction approach with schemes,pre-analysis, requirement specification and thorough mapping of context and environment,XP relies on an almost completely evolutionary approach. The system evolves from nothingto a complete system, entirely in the hands of the programming pairs. The programmingpairs develops bits and pieces of the program together, and they will in an iterative mannerpass through existing pieces of the system again and again, during their quest of solvingthe given user story. While designing the programmers often test their code, to see if it isexecuting properly. If not, they will analyze the errors, and learn fromthe mistakes theyhave made. This concept is known in the evolutionary approach as trial and error.[DahlbomMathiassen 2004]

XP In Relation To The Construction Approach

Every user story can be viewed as a small step towards the goal. In a construction approachthis will be referred to as a stepwise refinement. The making of user stories,valuing themwith units, and the process of selecting user stories with the costumer, can beargued to bestructured techniques and thereby to be in compliance with theories from the constructionapproach.[Dahlbom Mathiassen 2004]

106

Conclusion 17This chapter is a summary of the conclusions made in the report. It will answer our problemformulation which reads: "How is it possible to combine XP with user tests, anddoes theneed for this exist?"

In the exploratory work we did developing the system MuKuFo, we workedwith usabilitytests, and found that the need indeed is present for these, when developing with XP.

When considering end users, we had a wide variety to consider. The customer, who in XPwould be the only individual evaluating the system during development, was inour case notqualified to consider the interests of all possible end users. Not considering this would inthe worst case leave the system useless to the desired end user, thus enhancing the need forusability testing.

We decided to implement the usability test in the step of making releases in XP, thus dubbedRelease Test in this report. In order to incorporate usability testing in XP, wehad to modifyit, as the releases in XP are kept small. Doing extensible usability testing would stall thedevelopment process, as it demands a great deal of resources in termsof test crew, partici-pants, and analysis. Furthermore an extensible test would be a waste of manhours, as theresults could become useless when a new release is ready. Because of this, the test mustbe conducted with every new release, but as the main purpose of the system will remainthe same, a new set of test assignments is not needed. This decreases thepreceding worknormally carried out, when designing a usability test.

Summarized, this is how our Release Test differs from a normal usability test:

• A pilot test should only be conducted at first test

• Fewer participants

• Analysis is primarily based on notes made by observers

• Customer watch the test and can request changes based on what he sees

• Members of the development team can suggest changes, based on heuristics

107

The Release Test is both implementable and effective in the context of an XP developmentproject. Furthermore this type of test is time saving in comparison to a traditional usabilitytest.

In relation to working with our customer, we found that using paper prototypes promotesthe process of designing user stories. This helps, in the sense that the customer early in theprocess is presented with a visual presentation of the possible outcome.

Presenting him these prototypes, even if none correspond completely with his ideas, en-couraged him to explain how the presented material differed from his pristine ideas.

Based on the above findings we conclude that Release Testing is an effective way of in-corporating a cheap and efficient variation of usability testing into the XP developmentmethod. The need for this is evidently present in situations where the customeris not fullycapable of representing all groups of intended end users of the systembeing developed.

108

Perspective 18In this chapter we look at XP in a wider context, discussing the relevance ofuser testingand consequences, with this form of cooperation and software development.

18.1 User Tests And XP

Supporting an XP development project with user tests, does indeed have some advantages.For any customer or any system developed, some level of usability is desired. This and thefact that a customer is not always capable of representing all end users of the system, formsa good argument to why it is relevant to combine user testing with XP. It is therefore impor-tant, that the person or group responsible for including user tests, examine what groups ofend users are represented by the customer and which are not.

If user testing is consistently used to cover all user needs not representable by the customer,it is our assessment, based on the results of this project, that these user tests will be able toproduce the input needed to take all users’ needs into account. Taking advantage of usertesting must be considered fully compatible with the XP development method, sinceusertesting covers the area concerning the end product represented by thereal end users.

In this project the non-ethnic Danish homes are still to be represented as a group of endusers with relevant needs, regarding the end product of the system. This is the only group ofactual end users capable of testing the level of comprehension in the translated documents.Granted more time this group would have been obvious for additional usability tests in orderto close the circle and ensure that all end users are represented.

18.2 Taking XP Further

XP as being an agile method is suitable for many types of development projects dealing withproblem areas, contexts or requirements that are constantly changing. But in some of thesecases the tight dictations and rules of the XP method does not seem sufficient as a means ofretrieving all needed inputs, for the development team to create a satisfactory product. Bycombining XP with other methods of development and information gathering, it has shownthat this combined method becomes very powerful and we therefore argue, that XP can be

109

18.3 Perspectives For MuKuFo

developed into a stronger method this way, and thereby ending up with a betterproduct.

18.3 Perspectives For MuKuFo

The intended use of the MuKuFo system is mainly concerned in the lines of sports organi-zations and later on with the possibility of adapting more and more to other organizationsunder the municipal framework. The system was intended to have its start-upphase ina local relation to Aalborg Kommune through e.g. SIFA (Samvirkende IdrætsforeningerAalborg). Over time it is intended to spread to a national level through the adoption by anational umbrella organization like DGI (Danske Gymnastik- og Idrætsforeninger).

When we had our initial meeting with Aalborg Kommunes Tolkekorps, they becamemoreand more interested in using the features of MuKuFo for their own purposes. It appearedthat a vast number of assignments brought to Aalborg Kommunes Tolkekorps are in fact thetranslation of standard formulas and letters that have been interpreted manytimes before.A later version of the MuKuFo system will possibly allow such letters to be structured oncein order to be repeatedly translated afterward with a minimum of effort. A system likethis could also be of use in the departments of the various municipalities or state officeswhich send letters to the homes of recently arrived non-ethnic Danes. If these people wereable to understand the letters at first hand and gradually learn the Danish words through thetranslated subtitles, quite a lot of interpretation services and comprehensionsupport couldbe skimped.

The basic features of the current version of the system provides this use, but we are awarethat the system lacks the possibility of creating letters with more advanced layout such as isneeded for formal letters.

110

Bibliography

Dahlbom B Mathiassen L 2004Computers in contextBlackwell publishing. ISBN: 1-55786-405-5.

DialogDesign.dk 2001. http://www.dialogdesign.dk/brugervenlighed.html.

Dix A, Finlay J, Abowd G Beale R 1997Human-computer interaction2nd edn PrenticeHall. ISBN: 0-13-239864-8.

Inforce.dk 2005. http://www.inforce.dk.

Jeffries R, Anderson A Hendrickson C 2001Extreme Programming installed1th ednAddison-Wesley. ISBN: 0-201-70842-6.

J.F.Pironneau 2001. http://www.web-developpeur.com/english/articles.htm.

Molich R 2003Brugervenligt webdesignNyt Teknisk Forlag. ISBN: 87-571-2481-7.

Nielsen J 1993Usability EngineeringAcademic Press. ISBN: 0-12-518406-9.

Pressman R S 2005Software Engeneering - a practitioner’s approach6th edn McGraw-Hill. ISBN: 007-123840-9.

Rivest R L 1992. http://www.ietf.org/rfc/rfc1321.txt.

Rubin J 1994Handbook of Usability TestingJohn Wiley & Sons Inc. ISBN: 0-471-59403-2.

Steinberg D H Palmer D W 2004Extreme Software Engineering - a hands-on approachPearson Prentice Hall. ISBN: 0-13-047381-2.

Webhotel.net 2005. http://www.webhotel.net.

111

BIBLIOGRAPHY

112

Part VI

Appendix

The appendix contains material from the product develop-ment, that has been referred to through the report

113

User Stories AUser Stories:Punkter skrevet med fed skrift er de allerede udførte user stories

Forside og Ordbog:

Standard forside, uden login

• Velkomsttekst(2)Der skal være en velkomsttekst, som introducerer brugeren til siden. Hvad sidenkan bruges til, hvordan siden er blevet til, hvorfor siden er blevet lavet.

• Adgang til standarddokument(1)Der skal være mulighed for at vælge at arbejde med standarddokumenter.

• Mest brugte standarddokumenter(8)Der skal være direkte adgang til de oftest benyttede standarddokumenter.

• Adgang til skabeloner(1)Der skal være mulighed for at vælge at arbejde med dokumenter.

• Mest brugte skabeloner(8)Der skal være direkte adgang til de oftest benyttede dokumenter.

• Adgang til nyt dokument(1)Der skal være mulighed for at vælge at oprette et tomt dokument.

• Importer dokumenter(15)Brugeren skal fra forsiden have mulighed for at importere egne dokumenter gemtlokalt på dennes computer.

• Hjælpetekster(2)Til hver af de fire adgangsmetoder, skal der være en dækkende hjælpetekst.

• Hjælpesektion(3)Forsiden skal indeholde en "hjælpeboks", som indeholder links til forskelligehjælpefunktioner, som kan hjælpe brugeren til at benytte forsiden.

115

• Afsender(3)Forsiden skal tydeligt repræsentere afsenderen. Der skal væreadgang til atsende e-mail til administratoren af siden.

Login

• Loginboks(15)Der skal være en sektion hvor brugeren kan logge sig ind i systemet, med bruger-navn og password.

• Gensend login oplysninger(4)Der skal være adgang til en funktion, som kan hjælpe en bruger, der har glemt sitpassword. Brugeren får tilsendt et nyt tilfældigt kodeord.

• Rediger bruger oplysninger(4)Brugeren kan redigere sine oplysninger.

• Husk login(8)Der skal være mulighed for at brugeren kan gemme sit password på computeren, sådenne undgår at skulle gentage login hver gang systemet benyttes.

• Opret bruger(7)Brugeren skal have mulighed for at oprette sig som bruger, så denne kan loggesig ind i systemet og derved benytte de mere avancerede funktioner i systemet.

• Hjælpetekst(2)Der skal være en forklaring tilgængelig, på hvilke fordele der er ved at oprette sigsom bruger.

• Log ud(2)Der skal være muligt for brugeren at logge ud.

Tilføjelser til forsiden når brugeren er logget ind

• Adgang til egne dokumenter(6)Der skal være mulighed for at brugeren kan åbne sine gemte dokumenter.

• Sidst brugte dokumenter(5)Der skal være direkte adgang til de dokumenter brugeren sidst har haft åbnet.

Ordbogen

• Opslag(7)Ordene i ordbogen er gruppeinddelt efter begyndelsesbogstav. Dertil er de alfabetisksorteret.

116

• Søgning(8)Brugeren kan indtaste et søgeord og få returneret alle ord der indeholder de indtastedebogstaver.

• Indsæt ord(8)Ord fra ordbogen kan indsættes i det dokument der aktuelt arbejdes med.

• Afslut(1)Det er muligt at afslutte brugen af ordbogen.

Opret nyt dokument:

• Kategori(3)Brugeren har mulighed for at vælge kategori og dermed kun se de dokumenterder hører under denne kategori.

• Skabelon(3)Brugeren har mulighed for at vælge et specifikt dokument.

• Værktøjskasse(30)Brugeren har mulighed for at vælge foruddefinerede elementer ud fra kategorierog sætte dem ind på sit dokument.

• Elementer kan fjernes(6)Elementer kan fjernes fra dokumentet.

• Rediger elementets placering(20)Et element kan flyttes op eller ned på dokumentet.

• Oversæt knap(1)Brugeren trykker OK når dokument er som ønsket.

• Sprogvalg(3)Dokumentet kan oversættes til forskellige sprog ved at afkydse checkbokse.

• Gem dokument i databasen(10)Brugeren kan gemme dokumentet når som helst i databasen.

• Gem dokument lokalt(15)Brugeren kan gemme dokumentet når som helst lokalt på sin computer.

• Luk dokument(5)Brugeren kan lukke det nuværende dokument. Hvis dokumentet ikke er gemt, bliverbrugeren spurgt om dokumentet skal gemmes.

• Luk browser21Brugeren bliver spurgt om det nuværende dokument skal gemmes, hvis browser vin-duet lukkes.

117

• Åbn dokument(5)Brugeren kan åbne gemte dokumenter.

• Arbejd med standardskrivelse(4)Brugeren kan ikke redigere den foruddefinerede tekst, men kan skrive tillæg-stekst i bunden.

• Opret tomt dokument(10)Brugeren kan oprette et tomt dokument.

• AutoCompletion(40)Når brugeren udfylder dokumentet, bliver ord fra ordbogen løbendeforeslået. Detmarkeres om ordet oversættes eller ej.

• Fravalg(15)Brugeren får mulighed for at fravælge oversættelse af ord.

• Hjælp(3)Der skal være hjælp tilgængelig for brugeren.

• Navigation(1)Brugeren skal have mulighed for at komme tilbage til forsiden.

Versionering

• Oversigt(40)Brugere skal via faneblade have adgang til at se alle oversatte versioner afdokumentet. Disse sprog er valgt forud for dette skærmbillede, ogdet danskefaneblad bliver vist først.

• Print(7)Fra de enkelte oversættelser skal brugeren kunne udskrive denaktuelle version.

• Mail(17)Fra de enkelte oversættelser skal brugeren kunne e-maile den aktuelle version. Vede-mailing starter brugerens standard email program, brugeren skal selvindtaste emailadresserne.

• Rettelser(4)Fra dokumentoversigten skal brugeren kunne gå tilbage og rettei dokumentet.

• Oversættelse(10)I oversatte dokumenter står den danske version af de enkelte ord / sætningerumiddelbart under den oversatte version. Stedord, tidspunkter, ugedage osv. erikke oversat.

Hjælp/vejledning

118

• Oversigt(10)Man kan vælge brugervejledninger til hver del af systemet. Hjælpefunktionen ve-jleder brugeren sekventielt igennem valg af område, skabelon og dokumenttype.

• Afslutning af guide(6)Fra hjælpefunktionen er det muligt at begynde at arbejde med den pågældendedokumenttype, eller gå tilbage til forsiden. Begge dele afslutter guiden.

Specificering af dokumenttype

• Oversigt(10)Efter valgt dokumenttype på forsiden præsenteres man for de mulige doku-menter af denne type. Kan specificeres yderligere ved valg af gren.

• Egne dokumenter(5)Er brugeren logget ind er der mulighed for at vælge egne dokumenteraf valgttype.

Admin:

• Tilføj sprog(10)Der skal kunne tilføjes et nyt sprog til databasen. Ordene tilføjes ord for ord. Standarddokumenter oversættes.

• Tilføj sprog(40)Der skal kunne tilføjes et nyt sprog til databasen. Ordene kommer fra etstandardMicrosoft Officec© dokument.

• Udfyld standarddokumenter(5)Mulighed for at formulerer et nyt standard brev, samt indsætte oversættelserneaf dette.

• Tilføj elementer til værktøjskassen(3)Elementer skal kunne tilføjes til værktøjskassen, under angivelse af kategori oggren.

• Fjern elementer fra værktøjskassen(10)Elementer skal kunne slettes fra værktøjskassen.

• Rediger elementer i værktøjskassen(10)Elementer skal kunne redigeres.

• Tilføj ord(3)Der skal kunne tilføjes nye ord i databasen.

119

• Rediger ord(3)Gemte ord skal kunne redigeres.

• Slet ord(3)Gemte ord skal kunne slettes.

• Opret ny kategori til værktøjskassen(2)Der skal kunne oprettes en ny kategori til værktøjskassen.

• Slet bruger(4)Man skal kunne slette en bruger.

• AdminLogin(5)Admin rettigheder tilføjes login.

• Admin interface(10)Konstruer brugerfladen.

120

Test Assignments BB.1 Test of First Release

B.1.1 Opgave 1

Du skal nu forestille dig, at du er træner for et hold juniorer fra Aalborgboldklub. Du haren række typiske opgaver, du skal have løst inden lørdagens kamp, ognogle andre admin-istrative opgaver, der knytter sig til at være træner for et fodboldhold.Du har fået anbefalet et program, der er tilgængeligt på internettet, og duhar besluttet digfor at prøve det. Programmet er det, du har foran dig.

Du skal starte med at oprette dig som bruger.

Opret dig som bruger

Når du har oprettet dig som bruger, skal du logge ind.

Log ind i systemet

B.1.2 Opgave 2

Du skal nu lave en kampseddel til lørdagens kamp mod Nr. Tranders. Du har danske, so-maliske og arabiske spiller på dit hold til denne kamp.

Lav den kampseddel du har på papiret, startende fra et Nyt dokument

Når kampsedlen er som ønsket, vil du have den oversat og printet ud.

Oversæt og print kampsedlen i 1 dansk, 1 somalisk og 1 arabisk version.

Når du har printet din kampseddel og set, at den er som ønsket, gemmer duden på comput-

121

B.1 Test of First Release

eren.

Gem din kampseddel

Du har fået en opringning fra træneren i Nr. Tranders, som har bedt om at få kampenudskudt 1 time.

Print en kampseddel ud, hvor spilletidspunktet er ændret til en time senere i 1 dansk, 1somalisk og 1 arabisk version.

Når du er færdig gå tilbage til forsiden.

B.1.3 Opgave 3

Du skal planlægge et forældremøde, med spillernes forældre. I den forbindelse skal dubruge en tilmeldingsblanket.

Forældremødet er sat til Mandag, d 25/04/05 kl 19.00. I skal mødes i klubhuset, JensJensensvej 25 9000 Aalborg. Du vil gerne have svar senest fredag d. 22 april. på telefon:22334455. Et eventuelt afbud gives til dig, på samme telefon.

Print en tilmeldingsblanket til et forældre møde i 1 dansk, 1 somalisk og 1 arabisk version.

Når du er færdig gå tilbage til forsiden.

B.1.4 Opgave 4

Din arabiske spiller Afif Abram har ikke betalt kontingent endnu.

Kontingentet for at spille i din klub er på 150 kr. halvårligt.

Print en kontingentskrivelse ud på arabisk

Når du er færdig gå tilbage til forsiden.

122

Participant Questionnaire CC.1 Participant P1

De første spørgsmål er stillet for at få en smule kendskab til din baggrundog din erfaringmed IT.

Stilling: KonsulentUddannelse:KontorI hvor mange år har du brugt computer?10Hvilke programmer har du erfaring med at bruge?En delHvor mange timer om dagen bruger du typisk en computer?4 time(r)

De næste spørgsmål er stillet for at få en idé om, hvad du synes om systemet.Du skalher sætte ring om det tal, der passer bedst til dig, ud fra hvert spørgsmål. Der vil være enpåstand og du skal tilkendegive hvor enig du er i denne.

1 er helt enig, 6 er helt uenig.

Jeg synes, forsiden er overskuelig

1 - 2 - 3 - 4 - 5 - 6

Jeg synes, det var nemt at oprette mig som bruger

1 - 2 - 3 - 4 - 5 - 6

Jeg synes, at det er nemt at navigere rundt i systemet

1 - 2 - 3 - 4 - 5 - 6

Jeg fandt hurtigt den hjælp, jeg skulle bruge

1 - 2 - 3 - 4 - 5 - 6Hvis mere tid

Jeg synes, vejen fra forsiden til udprintet kampseddel er nem og overskuelig

1 - 2 - 3 - 4 - 5 - 6

Jeg synes, at systemet reagerede som forventet, når jeg navigerederundt

1 - 2 - 3 - 4 - 5 - 6

123

C.2 Participant P2

Jeg synes, hjælpefunktionen var god og overskuelig

1 - 2 - 3 - 4 - 5 - 6

Jeg tror, at jeg ville kunne få nytte af systemet som træner

1 - 2 - 3 - 4 - 5 - 6

Jeg tror, jeg ville bruge systemet som træner

1 - 2 - 3 - 4 - 5 - 6

C.2 Participant P2

De første spørgsmål er stillet for at få en smule kendskab til din baggrundog din erfaringmed IT.

Stilling: FlyelektrikerUddannelse:ElektrikerI hvor mange år har du brugt computer?10Hvilke programmer har du erfaring med at bruge?De brugerprogrammer jeg bruger i forbindelse med mit job.Hvor mange timer om dagen bruger du typisk en computer?1 time(r)

De næste spørgsmål er stillet for at få en idé om, hvad du synes om systemet.Du skalher sætte ring om det tal, der passer bedst til dig, ud fra hvert spørgsmål. Der vil være enpåstand og du skal tilkendegive hvor enig du er i denne.

1 er helt enig, 6 er helt uenig.

Jeg synes, forsiden er overskuelig

1 - 2 - 3 - 4 - 5 - 6

Jeg synes, det var nemt at oprette mig som bruger

1 - 2 - 3 - 4 - 5 - 6

Jeg synes, at det er nemt at navigere rundt i systemet

1 - 2 - 3 - 4 - 5 - 6

Jeg fandt hurtigt den hjælp, jeg skulle bruge

1 - 2 - 3 - 4 - 5 - 6

Jeg synes, vejen fra forsiden til udprintet kampseddel er nem og overskuelig

1 - 2 - 3 - 4 - 5 - 6

Jeg synes, at systemet reagerede som forventet, når jeg navigerederundt

1 - 2 - 3 - 4 - 5 - 6

Jeg synes, hjælpefunktionen var god og overskuelig

1 - 2 - 3 - 4 - 5 - 6Ikke ved print

124

C.3 Participant P3

Jeg tror, at jeg ville kunne få nytte af systemet som træner

1 - 2 - 3 - 4 - 5 - 6

Jeg tror, jeg ville bruge systemet som træner

1 - 2 - 3 - 4 - 5 - 6

C.3 Participant P3

De første spørgsmål er stillet for at få en smule kendskab til din baggrundog din erfaringmed IT.

Stilling: PædagogmedhjælperUddannelse:MejeristI hvor mange år har du brugt computer?2Hvilke programmer har du erfaring med at bruge?Windows 98Hvor mange timer om dagen bruger du typisk en computer?0,25time(r)

De næste spørgsmål er stillet for at få en idé om, hvad du synes om systemet.Du skalher sætte ring om det tal, der passer bedst til dig, ud fra hvert spørgsmål. Der vil være enpåstand og du skal tilkendegive hvor enig du er i denne.

1 er helt enig, 6 er helt uenig.

Jeg synes, forsiden er overskuelig

1 - 2 - 3 - 4 - 5 - 6

Jeg synes, det var nemt at oprette mig som bruger

1 - 2 - 3 - 4 - 5 - 6

Jeg synes, at det er nemt at navigere rundt i systemet

1 - 2 - 3 - 4 - 5 - 6

Jeg fandt hurtigt den hjælp, jeg skulle bruge

1 - 2 - 3 - 4 - 5 - 6

Jeg synes, vejen fra forsiden til udprintet kampseddel er nem og overskuelig

1 - 2 - 3 - 4 - 5 - 6

Jeg synes, at systemet reagerede som forventet, når jeg navigerederundt

1 - 2 - 3 - 4 - 5 - 6

Jeg synes, hjælpefunktionen var god og overskuelig

1 - 2 - 3 - 4 - 5 - 6

Jeg tror, at jeg ville kunne få nytte af systemet som træner

1 - 2 - 3 - 4 - 5 - 6

125

C.3 Participant P3

Jeg tror, jeg ville bruge systemet som træner

1 - 2 - 3 - 4 - 5 - 6

126

Paper Prototypes D

Figure D.1: Paper prototypes of the document versionizing

Figure D.2: Paper prototypes of the document versionizing

127

Figure D.3: Paper prototypes of working with the document

Figure D.4: Paper prototypes of the document versionizing

128

Figure D.5: Paper prototypes of the document versionizing

129

130

CD E

131