User Centred Design through an Iterative and Incremental Approach

Contents
1. Introduction: ......................................................................................................................................... 3
1.1 Purpose: .............................................................................................................................................. 4
1.2 Objective: ............................................................................................................................................ 5
1.3 Organization of research:.................................................................................................................... 5
2. Literature review:.................................................................................................................................. 6
3. Methodology:........................................................................................................................................ 8
4. Data Collection: ..................................................................................................................................... 9
4.1 Questionnaire 1 – Medical Staffs: ....................................................................................................... 9
4.1.1 Analysis of the survey: ............................................................................................................... 12
4.2 Questionnaire 2 - Software vendors ................................................................................................. 13
4.2.1 Analysis of the questionnaire: ................................................................................................... 15
5. User centred design: ........................................................................................................................... 16
5.1 Cognitive engineering: ...................................................................................................................... 17
6. Iterative and incremental development: ................................................................................................ 24
6.1 Why Iterative and Incremental?: ...................................................................................................... 25
6.2 Iterative and Incremental Development in Project Managers Viewpoint: ....................................... 27
6.3 Shortcoming of IID: ........................................................................................................................... 29
7. Medical software ................................................................................................................................... 30
8. Analysis ................................................................................................................................................... 33
8.1 User Requirement Management: ..................................................................................................... 33
8.1.1 Brief description of the proposed system from customer’s point of view: ............................... 33
8.1.2 User requirement analysis and planning: .................................................................................. 34
8.2 System design: .................................................................................................................................. 37
8.3 Implementation and deployment: .................................................................................................... 41
9. Findings: .................................................................................................................................................. 42
10. Conclusion ............................................................................................................................................. 45
11. Appendices ............................................................................................................................................ 46
11.1 List of reference: ............................................................................................................................. 46
11.2 Entity Relationship Diagram............................................................................................................ 49

1Page
 User Centred Design through an Iterative and Incremental Approach

11.3 Data Definition Library .................................................................................................................... 50

11.4 Surveys ............................................................................................................................................ 53
11.4.1 Questionnaire 1 – Medical Staffs: ............................................................................................ 53
11.4.2 Questionnaire 2- Software vendors ......................................................................................... 55

2Page
 User Centred Design through an Iterative and Incremental Approach

1. Introduction:
The diversity of web application and ease of publishing content has made it one of the best sources of
information now a days. Internet comes in handy in almost every aspect in modern day to day life of a
person. For this reason as this media is getting more popular every day, the end users started to expect
more from it. Web sites too, became more interactive and user oriented. Big corporations like Microsoft
Corporation (2001) and Google Inc (2002) are taking user experience as a major issue in making their
software. However the question is whether the software developers should limit user involvement to let
them influence the aesthetic feature of the software. The answers is with no doubt user should be
included in all the phases of software development rather than making their mark in UI design. The
developers should not forget, the users are integral part of any software. They are the ones who mark
the software’s success. More involvement of the user makes software more close to the users. On the
other hand, more user involvement also increases the cost of the software. It is because most of the
users are aware of the end product but they are ignorant of the processes and engineering lies beneath.
So when they are included, their adoption time in the development process makes the development
slow. One of the other factors is when the users are included in the system they waste time with giving
away useless requirement for the software. Last but not the least, there are no software which can
make its end user hundred percent happy. User centred development though comes us with the
software which is more user focused, it does not consider the software development life cycle from a
designer’s point of view. Issues like how to adopt to the requirement changes of the user are not
discussed in the user centred design. If the user centred design become more iterative in nature will it
be benefitting the system development? How a crucial software like a medical information software, if
put to the development in such manner, will result in? These questions will be answered in the later part
of the research.

Iterative and incremental development methodology has been a buzzword for quite a long time.
Introduced as quality (Larman, Craig and Basili, Victor (2003)), this process has been modified time and
again to overcome traditional downside waterfall approach. However, question always arises whether it
can address all the issues in development of a software. Apparently iterative and incremental
development has a tendency to break down the actual objectives into measurable pieces. Question is
how we can define measurable chunks. And when the chunks are joined together do they portray the
actual objective that was initially set. Iterative and incremental software development becomes very
successful as a project when it is short lived and less innovative. I will be concentrating on whether this
will be the answer for making a successful health care software. In order to that I will try to figure out
the common but critical criteria for an average health care software thorough gathering requirement
from potential customer. I will try to identify the common requirement of a heath care organization. The
later part of the project will deal with the success and cost factors for these softwares. In my practical
part of the research I will try to make a software that is based on the preference of criteria of health
care software that has been indentified earlier. The other important objective of the project will be to
find out whether user centred development process is ideal for the development of this kind of
softwares.

3Page
 User Centred Design through an Iterative and Incremental Approach

Use of computer aided information system in medical sectors is relatively new concept. Since the
software deals with highly sensitive data extra cautions has to be taken while making the software. This
is one of the many reasons why softwares of these kinds are normally expensive. Issues such data
security and integrity are also crucial while making the software. Medical service differs geographically.
So a software which is working very well in a developed country, might not work that successfully in the
underdeveloped country.

1.1 Purpose:
The Purpose of the research to find out the user centred development can be done is an in iterative and
incremental manner. If the iterative and incremental approach includes user centred design approach in
it then how the two distinctive models fit in together. Furthermore if both of the methodologies are
used to build a prototype for a medical information and front office management system will the
development methodology is helpful for both the client and developers. In short, in the later part of the
paper we will take a deeper look of the three subject matters. (Fig 1)

Iterative and
Incremental
Development

User Centred
Design

Healthcare
Software
Development

Fig 1: Subject matter for the research

4Page
 User Centred Design through an Iterative and Incremental Approach

1.2 Objective:
1. To find out the how two concepts IID and UCD can work together and make a successful
development methodology concept.
2. To produce a prototype of medical software through combining these two concepts.
3. Finding out some critical factors of the two process and some recommendations to overcome
the problems.

1.3 Organization of research:

In the first part of the research I will compare and contrast two concepts namely user centred design
(UCD) and iterative and incremental development (IID). I will also concentrate what the researches have
been done in the area. The discussion will come in background literature review. Then I will move one
and discuss about UCD, IID and medical software in general and elaborately. The analysis part will hold
the step by step development process of the prototype software and how I am using the proven
concepts on IID and UCD. In my findings I will speculate about some of the critical factors of the method
used and some recommendation to overcome those. In the conclusion I will speculate on the future of
the two concepts and further research option in the field.

5Page
 User Centred Design through an Iterative and Incremental Approach

2. Literature review:
From its beginning before most of the writer like Laurel, B. (1986) and Hutchins, E. et al (1986) wanted
to contain user centred development in the field of interface design. Katz-Haas, R (2004) showed user
centred design is not only making good interface, it works to provide the user of a system complete
satisfaction while using the software. Her concepts of design usability and test usability actually give in
AGILE dimension to the concept. According to her a system while being built should be built not as a
system all by itself but as a collection of usability. One usability should be designed and then tested and
then the programmers should move on to the next usability. However, she failed to discussed the
designers can also design more than one related usability (ie modules) if there is no relation among one
another.

On the other hand according to Larman, C. and Basili, V. (2003), iterative and incremental approaches
dates back to mid 60s as a quality insurer methodology. Slowly developers find it as a way to solve the
problems in the traditional software development process. The fact that it sees the software
development process as collections of strategies and as the user has the leverage of going back and
forth in the development process made it ideal for the short lived project and projects which have less
requires innovation power in it. Iterative and incremental development is not devoid of setbacks as well.
Cockburn, A. (2005) agreed that making workable chunks for iterative and incremental methodology is
time consuming and requires lots of analytical ability from the user. There are some other facts as well
Hooper, K. (1986) believes that iterative and incremental approach does not perform well when it
comes to innovative project. Spence, I. and Bittner, K (2005) give us the idea that if a software is divided
into measurable chunks then it can easily be manageable. But they have also failed to show us the
segregating criteria on the basis of which we can divide a software to multiple but manageable goals.

From above discussion we can easily find out some of the major setback in both the approach. User
centred design encourages the software developer to include end user in the development process. But
it fails to describe how and when to include the user in the development. My data collection in the next
chapter always portrays this fact. I have conducted a survey on programmers who have worked in the
software development process of medical software. In the survey I have found out that most of the
programmers want to have users’ opinion in the software development but they do not know who to
include them in the process. At the same time if we look at the iterative and incremental development
we will view the opposite scenario. Cockburn, A. (2007) has rightly argued that incremental
development as nothing but staging and scheduling strategy and iterative is reworking the schedules.
Iterative and incremental approach though encourages users’ opinion in the software development
process; it does not actually define in what process the users should be included in the system
development. Therefore it can be concluded that both of the methodology actually concentrates on
their own self only. User centred development wants the users to be included in the system but does
not concentrats how much man power, how much training one needs to give in to the users as they

6Page
 User Centred Design through an Iterative and Incremental Approach

master the new system and give in constructive opinion. On the other hand iterative and incremental
approach argues that it is best to take in users’ opinion and develop the whole system in part by part
manner. However it does not say how much the user will be a part in the development process.

There are a number of types and makes of medical software in present world. However the client tale
for this software is numbered. For this reason number of vendors are making open source medical to
software to encourage new clients to merge. Apart from these open source software most of the
licensed software are hugely expensive. At the same time as Nielson, J. (2005) indentified there are
number of setbacks are at large in the software as well. Koppel, R. et al (2005) also agree with him. For
this reason most of the potential buyers do not always like to buy the new software rather they want a
vendors to build a software according to their need. Eventually when a vendor makes a customize
software from the requirement, most of time the software comes with the same faults that has been
identified the vendor made software. Often the software that is built only for the medical organization
results in standards error over number of other vendors. Hutchins, E. et al (1986) argues that the
interface is the key to understanding a difficult software. So if we assume that most medical software
users are expert when it comes to handling computer software, then we have to agree with Mark, W.
(1986) as he argued

Communication with human beings requires shared understanding of the way the world works –
senders hope receiver’s understanding is similar enough to allow their messages to make sense.
Communication with a computer must work in the same way.

The questions now build up, how we can include in the user centred methodology in iterative and
incremental concept? If we successfully include the users in the part by part development of the
software does users satisfaction actually results in the intelligent interface but not on the performance
of the software?

7Page
 User Centred Design through an Iterative and Incremental Approach

3. Methodology:
Most of the theories and concepts of user centred development approach are taken from User Centred
System Design: New Perspective in Human-Computer Interaction. To look for the proven concepts for
iterative and incremental develop approach I have searched online journals mainly from IBM, Alister
Cockbarn and Robert C Martin. To get real time data on the concepts I conducted two separate survey;
one is conducted on medical professionals in Bangladesh to understand their mindset on medical
software. The second survey is conducted over some programmers who have worked in making medical
software in Bangladeshi IT industries. I conducted both the surveys through email. To put the new
concept in effect I have made a prototype of a medical software. I gathered the requirement of the
medical software from a management user of the IT section in one of the leading privately owned
hospital. Since he is bonded with nondisclosure agreement with the management of the hospital, i
cannot disclose his identity. I used to upload the development releases in a hosting site then he would
download the files and upload it to his convenient infrastructure and would test the prototype. Since the
prototype is essentially and database application, the database connectivity has been made through my
computer’s authentication. For this reason the software will not run if it is installed in any other
computer unless it is using the same password.

8Page
 User Centred Design through an Iterative and Incremental Approach

4. Data Collection:
As I have already stated in the introduction, user centred development though argues that it takes in
end users opinion in the software development, it has not actually put forward what are the best
programming practices are available there to make the user more related with the proceeding. On the
other hand iterative and incremental development fails to show a black and white phase where users
are giving their opinion. My understanding to the problem is before even the process started there
evolves two major stakeholder of the system. One is of course the clients. The other one is the software
developers. To make a proper use of user centred development process one has to bring these two
parties closer. In a quest to find out the existing problem for developing software, I managed to make
two separate questionnaires.

4.1 Questionnaire 1 – Medical Staffs:

Since in the practical part I am developing a prototype of medical information software, I have made
one questionnaire for the client that is the users of the medical software. My target population are the
medical software users of the third world country. In total of eight persons kindly agreed to take part
with in the survey. Two of them is a works in managerial post is a privately owned hospital. I managed
three doctors who work as physicians in different departments of a hospital. The departments are
Gastro Enterology, Hepatology, Neorology. I also managed three medical students who work as interns
in the cardiology section. Five of them work in private sector in health care two of them works in
government hospital and remaining one work in both type of organization as a part timer.

0%
37% Physician 13%
0% 38% 37% 25% Govt.
Male
Manager Private
Female
63% 25% Intern 62% Both

Gender distribution Occupation Sectorwise segregation

Population distribution

The data collected from the survey is shown in the following table.

9Page
 User Centred Design through an Iterative and Incremental Approach

Have you ever heard/used medical software?

a. Heard 5
b. Used 5
c. No 4 2 Heard
3
1 Used
2
1 No
0
Heard Used No

If you used/ heard of that kind of software,

then what kind of software were those? 6
a. Public Health and Biosurveillance 6
b. Electronic health or medical record a
c. Medical Practice Management 4 b
1
Software
2 c
d. Other 0 0
0 d

a b c d

Provided the cost factor of these softwares,

1
do you thing every medical organization
should have automated software to do their Yes
day to day activity.
No
a. Yes
7
b. No

What software do you think is necessary in

the present scenario of your organization?
7
a. Public Health and Biosurveillance 8
b. Electronic health or medical record a
6
c. Medical Practice Management b
4
Software 0 c
d. Other 2 0 0
0 d

a b c d

10 P a g e
 User Centred Design through an Iterative and Incremental Approach

If there is an ongoing development of these

kind of software, would you want to give 3
your opinion in the development process. Yes
a. Yes 5
No
b. No

If yes then what phases of the software 0

development do you think you will be able to 2
take part? 3 a
a. Data Gathering 0 b
b. Requirement Analysis
0 e
c. Designing the system
d. Execution 1 f
e. Evaluation g
f. All
g. I do not know what does the phases 3
refer.

Why do you think there is not many of these

kind of software present.
a. Lack of awareness 4 3
2 a
b. Cost factor 2
c. Both b
2 1
d. Cannot state the possible reason. c
0 d
a b c d

How do you think these softwares will

become helpful? 7
a. Adversely 8 a
b. So so. 6 b
c. Wastage of money 4
1 c
d. Do not know the possible outcome. 2 0 0
0 d
a b c d

11 P a g e
 User Centred Design through an Iterative and Incremental Approach

How the patients will like these software, if

4
deployed.
a. Very much 4 a
b. Will be suspicious 2
b
c. Won’t be happy because they need a 2 1 1
human touch. c
d. Will not have any problem, will not 0 d
be happy though.
a b c d

4.1.1 Analysis of the survey:

Before going to the analysis, one critical observation should be taken into account. That is the survey has
been conducted in a third world country, Bangladesh. Lack of knowledge on state of the art software
like medical software is compelling in here. For this reason probably some of the answers of some
crucial questions seemed unusual and unexpected to me.

Among the eight people, most of them (5 people) used or heard of a medical software. Most of these
people are acquainted with the normal patient information system. This is also notable that almost all of
them (7) like to see more of these softwares in effect despite the high price tag. Furthermore, they
believe that only patient information system can be a software of their necessity. This is probably
because their lack of knowledge of the variation of these software. Most of the people who thinks
medical software is necessary, likes to take part in the development process. 3 persons think that they
should take part in all the phases of software development. However same number of persons is not
aware of the phases of the software. 3 of the surveyee accepts that the main reasons for not having this
kind of software are both lack of knowledge and price factor. While 2 people think the reason is either
lack of knowledge or cost of the software. All most all of the surveyees believe that this software will be
adversely helpful to the patient. However 2 of them believe that the patients will be suspicious about
the usage of the software.

12 P a g e
 User Centred Design through an Iterative and Incremental Approach

4.2 Questionnaire 2 - Software vendors

I have surveyed on in total of 12 people in three separate software firms in Bangladesh. All of the
surveyees had had some exposure in this kind of software development process. I managed to conduct
the survey on 4 managers, 2 testers and 6 coders. Two of the firms where the survey was conducted are
real time software developer while one o them are part of big software company (Microsoft Inc.) and
they do consultation and system customization in Bangladesh.

17%
17% 33% Manager 33%
Male Developers
Coder
Female
83% Tester Vendors
50% 67%

Gender distribution Occupation Sectorwise segregation

Population distribution

The survey question and summery of their response is given below,

Do you have any experience of working is

medical software project?
12
a. Yes
b. No 15
Yes
10 0
5 No
0
Yes No

13 P a g e
 User Centred Design through an Iterative and Incremental Approach

What kind of software project you worked

in? 2 0 1
1 a
a. Public Health and Biosurveillance
b. Electronic health or medical record b
c. Medical Practice Management 8
c
Software
d
d. Other
e. None e

What was your responsibility in the 2 3

development process?
a. Manager, Team Lead 2 a
b. Coder b
5
c. Tester
d. Other (e.g requirement analyst) c
d

The software that was developed, was it on

time on budget project? 6
6
a. Yes 6 Yes
b. No
4 No
2
0
Yes No

How the customers felt about the software,

when delivered? 7
a. They were very happy 8
b. Not very happy but not very 6 a
3
disappointed. 4 b
1
c. Disappointed. 2
c
0
a b c

14 P a g e
 User Centred Design through an Iterative and Incremental Approach

In what phases the customers where

included of the development phases? a
15 11
a. Data Gathering 9 10 b
b. Requirement Analysis 10
5 c
c. Designing the system 5 0 1 d
d. Execution 0 e
e. Evaluation a b c d e f f
f. All

In what phases in the development process

do you think that the customers should be 9 a
10
included? b
8 6
a. Data Gathering 6 c
b. Requirement Analysis 4 2
1 1 0 d
c. Designing the system 2
d. Execution 0 e

e. Evaluation a b c d e f f
f. All

4.2.1 Analysis of the questionnaire:

Since pharmacy is a key industry in Bangladesh, all most all software industry has some exposure to
some medical software development. This is the reason why all of the target population of the survey
said that they have some experience in the medical software management. And most of them (8
persons) have experience on electronic health and medical record in short in some of medical
information system. About 5 people worked as a coder in the development. Other responsibilities
include manager or team lead (3 persons), tester (2 persons) and other position like requirement
analyst, business development (2 persons). Half of the suveyees think that their software was on time
and on budget. The other half thinks the contrary. Seven persons thought that the software they
produced made the customer satisfied. And most of them (11 persons) only included the client in the
data gathering phase. One interesting point that came up from this survey was most of the professionals
think that the clients should be included in all phases of the software development. But in their case
they were unable to include them probably because lack of state of art facility and lack of knowledge on
how to gather customer opinion.

15 P a g e
 User Centred Design through an Iterative and Incremental Approach

5. User centred design:

User centred design is the concept of development process that puts the user of a software in the
driver’s sit for the development. It asks the users of the feature of a software rather than depending of
the programmers of the software. The common concept of this design methodology is to take users
opinion on each phase of the development process. This approach though comes with an expense of
monitory cost but makes the end user more satisfied by the end product. According to, Katz-Haas, R
(2004) there are some questions that user centred design concentrates on. These basic questions define
what user centred design is. The questions are,

 Who are the users?

The basic question that the development team has to answer in the users centred development
process is to identify the users. The common practice while making a software is to take the
consent of the person who are not the actual users of the product. For example, while making a
POS system of retail chain, the common practice for a developing software firm is to meet with
the management of the software. The management team decides the feature of the system
although they are the not the users of the software. In most cases this common practice results
in an unsuccessful project.

 What are the users tasks and goals?

A software may have many utilities and can address many problems all in one. So it is expected
that the requirement of the software may vary from person to person. This question segregate
the user by the way they interact with the system. If the designers can identify how the users
will interact with the system then they can understand what the users are accepting from the
software.

 What is the users’ experience level about the end product?

This question also segregates the users in terms of the experience to the proposed system. It is a
process which somewhat prioritize the users, thus prioritizing their opinion about the proposed
system. If a user is highly experienced with the current system of work flow then he can easily
identify the flaws of the system and the probable reason for it.

 What are the functionalities that users require from the end product?
This is a very basic and common question which asks about the functional requirement of the
software form the users. Every kind of development methodology has this level. User Centred
Development (UCD) believes on focused group discussion (Lazer, J et al (2002)). The purpose of
the session is to review the requirements and development teams comments on the proposed
system.

16 P a g e
 User Centred Design through an Iterative and Incremental Approach

 What is the information that is needed for the users need to make judgement?
This question tells about the presentation of the data. The users has to be presented with the
development information in way that is easily understandable by the users so that they can put
their valuable opinion to the development process.

 How the users are expecting the product to work?

This key question tells about the user cognitive view point of the software. The more the
development process is closer to the users the more successful the project becomes. The end
users’ opinion has to be the key requirement criteria. Sometimes a bad practice in the client
environment has to be given priority rather than perfecting their business process.

Hooper, K. (1986) believes that the functionality of the software should be the main concern for the
designer. The users of a software has to be aware of its functionality. For this reason the information has
to be presented in a way that users can easily understand. This is why interface is crucial for information
system (software). Lazer, J et al (2002) is more specific with the users touch point in the software
development process. They believe that users should be involved in requirement gathering, usability
testing, and participatory design. They did not think that users’ opinion should be taken while the
software is finished. The users’ opinion on the finished product is necessary for any new update on in
case there is new software deployed.

5.1 Cognitive engineering:

User centred software design in present time depends a lot in cognitive engineering. Cognitive
engineering deals with the machine interpretation of human behaviour. Though lots of research has
been done in the sector but lack of knowledge and standard in the field is still compelling. Roth, E. M.,
Roth, E., Patterson, E. and Mumaw, J. (2002), define cognitive engineering in this way,

Cognitive Engineering is an interdisciplinary approach to designing computerized systems

intended to support human performance

They also discussed the common question asked by the cognitive engineering. According to them
cognitive engineering should ask,

 What are the goals and constraints of the application domain?

 What range of tasks do domain practitioners perform?
 What strategies do the use to perform these tasks today?
 What factors contribute to task complexity?

17 P a g e
 User Centred Design through an Iterative and Incremental Approach

 What tools can be provided to facilitate the work of domain practitioners and achieve their
goals more effectively.

Gersh, J., McKneely, J., and Remington, R. (2004) believe four different study fields make up cognitive
engineering. They are

1. Cognitive Science
2. Human Computer Interface
3. Human Factors
4. Systems Engineering

System
Engineering

Human
Cognitive Cognitive
Computer
Science Engineering
Interface

Human
Factors

Fig 2: Intregal field for cognitive engineering

Cognitive engineering becomes in close contact with the user centered development because how the
user perceive systems is necessary to understand to make more user centric information system.
Norman, D. (1986) also gives three reasons why study of cognitive engineering is necessary. According
to him cognitive engineering is important for the users because of,

a. Difficulties in Mapping Variables:

The designers have to determine the users’ expectation for a single action. It also very important to
know that which control should be a center of focus to the users. The following figure shows two log

18 P a g e
 User Centred Design through an Iterative and Incremental Approach

in control. One is an arbitrary log in control another one is taken from google.com account log in
page.

Fig 3: Comparing good and bad example of variable mapping in users prespective

One can visibly see the difference between the two interfaces. The one in the left shows the by
emphasizing on a virtually unnecessary control (Forgot your password.) the first interface is
misdirecting the users to different action where most users will anticipate to go. On the other hand
the google.com gives correct emphasize to the correct control and does the job as the users will
anticipate.

b. Need of Ease of Control:

There can be many a way to make a specific job done. The designers have to make the solution in
way that it takes less overhead from the system. This issue becomes important when there are
millions of transactions has to be done and the processing power is scarce.

c. Problems with Evaluating the next Steps:

This issue in one of the most critical factors for which cognitive engineering is necessary. The
computer systems do not always know how to accomplish the next step the best way. To explain the
problems let assume a scenario where in a screen A, users has to provide their details like name,
date of birth and his gender. Upon entering the values when the users click the submit button the
system takes them to a screen B. Now it can be a case that name and date of birth for a user is
already in there in the database. So that user does not always have to provide the same information
over and over again. This simple fact is causing an overhead for the system. In the end when this
small overhead is multiplied by millions of times by different users, can become a serious backlog for
the whole system.

Combining physical factors of the system and psychological factors in users mind is always very tough.
According to Norman, D. (1986),

19 P a g e
 User Centred Design through an Iterative and Incremental Approach

The user of the system starts off with goals expressed with the psychological terms. The system,
however, represents its current state in physical terms. Goals and system state differs
significantly in form and content creating gulfs that need to be bridged if the system can be
used.

Gulf of Execution

Physical
Goals
System

Gulf of Evaluation

Fig 4:Gulf of execution and evaluation Source Norman, D. (1986)

Gulf of execution can be bridged the psychological aspect of the of the users’ intention, determining
what action should be taken to solve the problem and applying to the interface of the system. On the
other hand, gulf of evaluation can be addressed by concentrating on physical aspect of the system. That
is determining how the interface is organized, interpretation of users’ need and evaluating them to the
systems performance.

20 P a g e
 User Centred Design through an Iterative and Incremental Approach

Interface Action Intentions

Mechanism Specification

Bridge of Execution

Physical
Goals
System
Interface Interpretati Evaluation
Display on

Bridge of Evaluation

Fig 5: Bridging the two gulf in system design. Source Norman, D. (1986)

Norman, D. (1986) argues that there is a structural procedure make proper use of the bridge of
evaluation and bridge of execution. He also shows that to make the systems more close to the goals and
these two bridges are interconnected. The user activities to perform a task can show their
interdependence.

According to him ‘a task’ starts with defining a goal. When the goal is set then designers make a work
flow to complete the task. This phase of the activity is called intention. After that the work is confirmed
with the all the stakeholder of the system. In this phase the course of action is set. This phase is called
action specification. After the action specification is set then these steps are executed in execution
phase.

21 P a g e
 User Centred Design through an Iterative and Incremental Approach

Mental Activity
Goals

Intention Expectation Evaluation

Action
Interpretation
Specification

Execution Perception

Physical Activity
Fig 6: Task Completion Stages Provided by Norman, D. (1986).

22 P a g e
 User Centred Design through an Iterative and Incremental Approach

After the execution, the system is done and delivered to the client. Client then use the system that has
been provided by the designers, Norman, D. (1986) defines this stage of the system as perception. After
few days of using the system the user then starts to ‘interpret’ how the system is affecting their work
culture. After that they start to ‘evaluate’ the system and at this stage they start to come up with the
expectation miss match with their initial intention.

From the above discussion, we can easily understand user centred development can provide softwares
which are more close to the users’ requirements. However, it does not consider the software
development process from a developers’ perspective. That is it does not discuss what practises in the
development process that can make the software easier and quicker to make. Other improvement
factor of the process is, this process is a linear process like waterfall. Therefore if there is a change in the
evaluation stage or any of the phases then all of the process has to be redone from the very beginning.
So inevitably the question comes, “What if there is a fallback mechanism in the process? If we do make
the process reversible, then does it solve the most, If not all, of the inconveniences in the development
process?”

There is no doubt and misconception that software has to be closer to the user. That is software must
meet all the requirement of the client. But in strive to meet the clients’ requirement are we not making
the software more complex to make and thus ending up making the software expensive? User centred
development does the trick when it comes to meet the requirement. As a development methodology,
however, it does not catch the designers’ eye.

23 P a g e
 User Centred Design through an Iterative and Incremental Approach

6. Iterative and incremental development:

I have mentioned in the introduction that iterative and incremental software development methodology
has been introduced to overcome the shortcoming of waterfall method. This section of the paper will
discuss the iterative and incremental development elaborately.

Iterative and incremental development is a software development methodology which instead of

developing the whole software in one go concentrates on developing a part of the software and before
going to the development of the next phase it makes sure the development of the previous is error free.
In this way it makes the development process easier. The following figure is the most common figure
that has been used for describing iterative and incremental development.

Fig 7: Iterative and Incremental Development Methodology (wikipedia)

Let us explain iterative and incremental development part by part. By iteration it is meant that a
particular job in development process is done over and over again. By Cockburn, A. (2007),

By iterative development, I specifically wish to mean a rework scheduling strategy in which time
is set aside to revise and improve parts of the system.

Iterative development is nothing but planned reworking strategy of a task. Iteration of a task is done to
get the optimal result of a task. It is based on feedback based improvements. Software development
should encourage the new ideas to improve the system itself. Iterative development can include new
ideas and adopt to the change in the requirements easily. It provides the programmers with ease of
modifying and improving the quality of code while preserving its functionality. Bugs should be fixed as

24 P a g e
 User Centred Design through an Iterative and Incremental Approach

we go, not in a phase squeezed in as an afterthought just before delivery. By Incremental development
Cockburn, A. (2007) said,

By incremental development, I specifically mean a staging and scheduling strategy in which the
various parts of the system are developed at different times or rates, and integrated as they are
completed. It neither implies, requires nor precludes iterative development or waterfall
development – both of those are rework strategies. The alternative to incremental development
is to develop the entire system with a big bang integration.

That is by incremental development it means that a project is divided in number of sub parts. These sub
part are done is same or different rate and integrated when is done. For example let us assume we are
making an email portal. In a incremental development strategy all the components (i.e login, email
organizer) are prepared as a component and then integrated any time.

Fig 8 : iterative development Spence, I. and Bittner, K (2005)

6.1 Why Iterative and Incremental?:

I have already stated earlier that iterative and incremental development has been introduced to
overcome the inconveniences offered by waterfall method. Generally, the question comes what were
waterfall’s flaws that made it almost obsolete in present software development world. According to
Martin, R (1999) as a development methodology water fall has three most agreed upon flaws. They are,

1. No feedback between phases.

Below is a hypothetical structure of waterfall.

25 P a g e
 User Centred Design through an Iterative and Incremental Approach

Fig 9: Water fall method

A general observation on the figure show that the process is linear and single directional. That
means that there is no reverse mechanism in place in the methodology. If the process is in
implementation stage and then it is discovered that there was a major fault in design phase
which can lead the whole project in wrong direction. The process is really simple and
understandable for a perfect world. However, as Berard, E. (2006) said Walking on water and
developing software from a specification are easy if both are frozen, we have to accept that the
requirement can change. And as it changes the project should have a mechanism to adopt to
the change.

2. Hard dates on phases.

In water fall method planning for the whole project takes place before hand. This practice
always challenges the management and planning capability of the project managers.
Unfortunately, it is rare when the plan is executed 100% accurately. In this methodology asks
requires managers to put hard dates on each task. So whenever one task is a day over, it creates
a chain effect putting all the tasks coming after that late start and late end. It causes major
budget overrun in the project.

26 P a g e
 User Centred Design through an Iterative and Incremental Approach

3. No completion criteria for either Analysis or Design

This problem is not directly related to the waterfall method itself. It is actually the result of bad
planning. Since all the tasks has to be defined way before the actual project starts, the project
managers tend to give longer time and budget allocation to the analysis and design phase. This
results in no closing condition in either of the phases. The designers and the developers alike
then finds it hard to allocate their time properly to the stages.

Other shortcoming of the waterfall method includes often the customer do not know what is coming at
the end of the execution because the customers’ opinion on the system is only taken on the
requirement gathering session. Since change of customers’ mind when the development is in progress is
very common, the water fall method finds that really hard to adopt. Another criticism of waterfall is
since the method is non reversible, the design which were easier to make out in paper becomes very
hard to execute when it comes to cost and the time factor of the project. Waterfall method clearly
makes a division between designers, coders and testers who most of the time are the same persons.

6.2 Iterative and Incremental Development in Project Managers Viewpoint:

According to Spence, I. and Bittner, K (2005) project management is not only note taking and reducing
the budget. Proper project management effort should answer the following question,

 Are we solving the right problem?

 Do we have the resources to deliver the solution?

 Are we working on the right things, right now, to get us to our end goal?

 Are we fooling ourselves into thinking that we can actually deliver a solution within the time and
resources allotted?

Iterative and incremental development can help the managers achieve the answer of these questions
more easily. This methodology helps the managers to look at the problem is more segregated manner.
The managers practicing this methodology have the luxury to solve the problem in a part by part
manner. It is like doing a small project on agreed objectives at a time then integrating it to the rest of
the project when it is done. Bellow is a hypothetical steps of iterative and incremental development
methodology from project managers prespective.

27 P a g e
 User Centred Design through an Iterative and Incremental Approach

Fig 10: Construction of Iteration in IID in project manager’s eye - Spence, I. and Bittner, K (2005)

Managers also provide direction to the project as a whole, organizing work so that each iteration
progressively contributes to delivering the solution. To do this they must plan, execute, and assess the
project as a whole, and organize it as a series of contiguous iterations. Below is a overall project
management structure of the IID.

28 P a g e
 User Centred Design through an Iterative and Incremental Approach

Fig 11: Hypothetical project management process in project managers view (Spence, I. and Bittner, K
(2005))

As we can see in the figure the whole project is divided in small parts of project. Then along with the
time these small tasks are managed iteratively by the managers.

6.3 Shortcoming of IID:

Martin, R (1999) and many others agreed that iterative and incremental development is not free from
shortcoming as well. The main problem for IID is according to Martin, R (1999), it makes a framework of
every task in the project. So it cannot make itself adoptive if there are some changes in a particular
iteration of a task. The other problem includes the negligence of managers. Since IID breaks down the
project into small tasks and smaller objectives, the manager gets into a bad habit of taking thing too
lightly. They tend to over look the small discrepancies of tasks which could add up to some major cost
factors of the project. Another problem of IID is all the tasks are performed in a time boxed manner. This
is why the tasks are done in a hurry and less effort is put into planning. Which can lead to redoing the
tasks and doing tasks is less efficient manner.

29 P a g e
 User Centred Design through an Iterative and Incremental Approach

Hooper, K. (1986) argues though iterative and incremental design is the best for the providing quicker
software but it does not always good for providing the results which the designers have opted for.
According to her,

rapid prototyping however does not guarantee we will end up with the result that are useful for
the designers, even if the contribute magnificently to our understanding of the general field of
interface design.

7. Medical software
With the advancement of technology more and more systems are getting automated. However this rate
is very slow when we consider medical field. One of the main reason is probably this software depends
upon some crucial biological information of the patients that remains debatable privacy factors to the
patients. The accuracy of these softwares has to be spot on. This makes the software almost
unachievably expensive. According to Meijer, J. (2009) the following are the major sectors where
medical software adds value.

 Diagnostics aids
 Health aids
 Emergency response and risk analysis
 Occupational safety and health
 Education training for the stuff and resource providing

One can easily understand medical software has lot of different dimension of usage. In late 1990s health
care providers shift focus from automating individual departments to building integrated care delivery
systems which required hospitals and clinics also integrate different types of IT systems used in their
clinic systems (Goulde, M. And Brown, A (2006)). However conventional software presents many
obstacles to achieve this goal, a number of IT health care leaders are considering open source software
as an option. Below are some types of these softwares.

1. Public Health and Biosurveillance

2. Electronic health or medical record
3. Medical Practice Management Software
4. Health System Management
5. Imaging/Visualization
6. Medical Information Systems
7. Standards Libraries
8. Older Libraries
9. Signal Processing
10. Research
11. Operating System

30 P a g e
 User Centred Design through an Iterative and Incremental Approach

12. Data Translation

13. Mobile / Handheld Devices

Except for the expense factors, there are number of weakness has been discovered by Nielson, J. (2005)
that proved medical software to be non comprehensive. The weakness’ are

a. Misleading default values.

This error is caused because of poor handling. The error cannot be identified as the system
error. It occurs when storing new information many fields are left blank. Most of the systems
are designed in a way that when some of the necessary fields were blank they fill in default
value. It is not a good practice while storing crucial information like medical information. One
way to solve the problem is, instead of putting default values they should gave an error message
to the user that some of the necessary data fields are yet to be filled in though it will reduce the
work speed quite a bit.

b. New commands are not checked against previous ones

This is a classic error only related with medical software. Most of the medical softwares are
designed in a way that they do not compare the old value with new one while storing same type
of data. To explain this error let us consider a scenario. A patient visits a doctor for a problem.
He is seeing this doctor for 2 years now. During these two years he visited the same doctor for in
total of seven times. All the time he is having a medicine, A. Upon seeing a minor change in his
condition doctor changes the dosage of the medicine from three times a day to two times a day.
If the system does not keep track of the changes then it is very likely that it will add up the
dosages and make it as 5 times a day. To check this error the system should have some analysis
capability by which it can sense the changes in data.

c. Memory Overload
Memory overload occurs when there is more data than projected. Memory over load can cause
many errors in the system. Some of the errors include erroneous data, more time in data
processing etc. There are some aesthetic problems as well. When volume of data gets more, and
if the system does not know how to manage it then often the information is represented in a
way that creates confusion in the users mind. In present word database vendors like SQL and
oracle uses database increment policy. By this policy if the database increases beyond a certain
amount of disk space then it reserves more space from the disk. The problem can still occur if
the disk space is overrun.

31 P a g e
 User Centred Design through an Iterative and Incremental Approach

d. Date Description Errors

It is another classic example which only happens in medical software. This problem is caused for
lack of artificial intelligence in the system. Let us assume a doctor prescribes a patient an anti
biotic which he will have for seven days. For any reason if the patient discontinue it and then
want to continue once again then the system should make the calculation of dosage for the
patient. Most of the softwares do not have any mechanism to handle this kind of problem. To
come up with the dosage the patient needs to visit the doctor again and then the doctor
calculates the optimal dosage. To save precious time it will be very helpful if the software can do
this calculation and save lot man power.

e. Overly Complicated Workflow

Normally any medical software has ties with different department of the management. For
instance the same software which helps doctor to diagnose patient is controlling the state of art
pathological equipment. The setback is this centralize facility though increase the performance
of the management but there procedure of work becomes so complex that it becomes hard for
the designers to design this kind of software. The normal practice though is layer by layer
implementation of this kind of software. For example at first the front office of the organization
is automated, then the patient management system. After this two is done may be the
pathological test unit is designed and implemented. Then the cost of the software remains low
and the information in the database has less chance to be compromised.

32 P a g e
 User Centred Design through an Iterative and Incremental Approach

8. Analysis
8.1 User Requirement Management:
As I have said the methodology chapter that for the practical that for my practical part of the project I
am developing a module of a medical software. My objective for the research will be to make a proper
use of user centred development ideology for the development process. At the same time the software
development will be following iterative and incremental methodology. Expected outcome of the paper
will be the learning of the development methodology not the module itself.

8.1.1 Brief description of the proposed system from customer’s point of view:
The proposed software will be a medical solution for a privately owned hospital in Bangladesh. The
software will be a centralized automated system which will enhance the productivity of the hospital. The
software will have a POS interface for the front desk manager, a interface for the doctors to input day to
day patient information. The software will also connect to the central ERP of the hospital and feed the
ERP information about daily transaction. The potential features of the software are as follow,

1. The software will have a privilege based log in system. That is when the user logs in to the
system he will only view the pages relevant to his role in the organizations. It will also show
different pages for different departments.
2. A point of sale for the front desk managers which will enable the user the user to create new
patient, allocate the patient to appropriate doctors and manage the schedule of the doctors.
3. An interface for the doctors which will show them the potential appointment that they have for
today. It will also help the doctors to do view/read write the history of the patient.
4. It will also have an employee payroll management which will have a connection with the finance
and accounts department of the organization.
5. The software will also run the pathological test unit for the patients.
6. It will have a connection with the central ERP of the organization and feed data to the system.

As the practical part of the paper I will develop the sign in module, front desk and doctor’s interface for
patient management.

Let us take a look at the work flow of the potential module that I want to produce as a part of the
practical phase of the paper. As shown in the previous figure I will be developing the sign in, front office
and the doctor’s interface of the proposed system.

33 P a g e
 User Centred Design through an Iterative and Incremental Approach

Sign In
Module

Doctors’ Pathological ERP

Front Office
Interface Test Unit extension

Fig 12: The proposed module for the prototype.

8.1.2 User requirement analysis and planning:

One of the most important phases any software development process is user understanding. As a
developer one should understand how the user of the system is working when the software is not in
place. If he can understand that then he can easily add value to the system by making the physical
software more productive. For this reason I try to understand and visualize the basic workflow of the
modules that I am concentrating on. According to Riley, M (1986) there are three important criteria for
evaluating the representation generated during problem solving. They are

1. Internal Coherence:
Internal coherence is the extent to which the components of knowledge are related to the
integrated structure. That is how a designer will see and divide the component of the system.
The concept has nothing to do with the client’s side of the system. It is a process how the
designer is viewing the problem.

2. Validity
Validity asks whether the designer’s internal coherence actually reflecting physical behaviour of
the system. This process involves the client and brings in their opinion about the problem
solving plan that the designer devised.

3. Integration
Integration is the step where the validated system is configured to the perfection and deployed
for enduser.

34 P a g e
 User Centred Design through an Iterative and Incremental Approach

If we take a deeper look in the criteria we will see this problem solving approach has similarity with the
Norman, D. (1986) model of steps of users activities for problem solving discussed in the User (earlier.)

I tried to keenly understand the basic workflow of t he module I intend to develop. I applied Riley, M
(1986)’s three criteria for representation generated problem solving. Though diSessa, A (1986) argued
against structural model and given emphasize on functional model of problem solving I preferred the
former model for the requirement gathering. It is because structural model streamlines each iterations
in iterative and incremental development. According to Tattersall, G (2002) iterative and incremental
development has to have clearly stated objectives and closing condition. If I would have opted for
functional model then at the end of each iteration user will be adding new functionalities to the system.
To overcome this problem I followed Lewis, C. (1986)’s validation approach to the problem. This
approach helped to come closer to the customer at the same time it kept the iteration intact. For the
requirement gathering I managed to arrange three sessions with a management user of the software.
After the initial requirement gathering session I came up with the story board of the modules. The user
then given in some opinion of the story board. Depending on those opinions I made further changes to
make the story board come more closer to the real world scenario. I managed to come in contact with
some programmers who have worked in such project. They gave in some major insight of the software
which came very handy in the later part of the development procedures. At the end of the requirement
session I managed to produce a general story board of the modules I intend to develop. The story board
is as follows,

After successful log in a front office manager will see the appointments for the doctors for current day
or shift. In case of new appointment they can create new patient and allocate the patient to the
available time for the doctors. On the other hand when the user signs in as a doctor then he will view
the potential appointment they have in the day or shift.

When the patient visits the doctor physically then any previous history of that the patient can be
viewable to the doctor. If the patient is new then the doctor will add history and probable medicine to
the patient. He can also refer the patient to the pathological test unit. Furthermore when necessary the
doctors can obtain results and report from the pathological test unit.

35 P a g e
 User Centred Design through an Iterative and Incremental Approach

Log in

Doctor

Allocate patient See/Create

Create/Update
to the available History and
Patient
doctor medicine

Send to the test

Update History centre if
necessary

Add results to the

system

Test Centre
Fig 13: Story board of the proposed prototype.

36 P a g e
 User Centred Design through an Iterative and Incremental Approach

8.2 System design:

Whatever the development methodology is, the developers are used to spend most of the time of their
development process is system designing. We have noticed in User Centred Development chapter that
while following the waterfall strategy the designers do not have the leverage to fall back and modify
something which will cause problem in later part of the project. Iterative and incremental development
(IID) formulates a mechanism which enables the programmers to reverse and redo something. However
this power comes with a price. Every time iteration is redone it cost the project team cost and time. For
this reason before the start of project every managers should have tolerance level of iteration of each
task. Though the power iteration can be counted as blessing for the designers they should try to make
the number of iteration as minimum as possible.

User Centred Design has clearly identified end users as the one of the most crucial stakeholders in any
kind of software development. Their opinion in software development is very important. However user
centred development does not provide any mechanism by which the user can be attached in the
development while it is design state. For this reason, I choose more AGILE approach to come up with the
solution. For designing the system I took Ambler, S (2001) approach. I took the following approaches
proposed by him.

 Requirement Based Architecture

I contacted with the customer over and over again. By doing that I tried to keep him notified
about the probable release and what is expected in the software.
 Architecture modelling
I modelled the architecture in a way that can easily be understandable by the client. Modelling
mostly had been done in oral format. I did not take bulk of requirement a long dateline. Rather
I took smaller requirements and less time to achieve those.

 Travelling light
I did not create lots of documentation which will only puzzle the client. I have only created
some use cases for the client and ERD and DDL library for the development purpose. The
documents can be found in the appendix.

 Communicate your architecture

As I said earlier I have kept the customer notified and in control of the design process. I
contacted the customer every now and then for the development related query.

 Think about the future but do not overbuild

I always kept it mind and think about the possibilities of things that can happen along the way.
As I have kept the customer informed I always had a clear idea of what will come up in the
future.

37 P a g e
 User Centred Design through an Iterative and Incremental Approach

 Take a multi-view to the problem

The approach comes in handy when the customer has a clear idea what is going in the
development. Then he can give good productive view which can optimize the process.
However I did not managed to get the customers view to that extent. To have a multi view I
have shared my designed ideology with some of the programmers who have worked in the
field. They gave in some good point in the design which I will be discussing in the later part.

I wanted to have some user centred attributes to the design process as well. Owen, D. (1986) given is
some answer question paradigm for the doing design based architecture. He believed that while
designing there are three steps to follow,

a. Preparing a tentative goal:

In this stage the user should be presented with number of potential outcome of the project.
They needed to be explained pros and cons of each outcome and probably time and monitory
cost.

b. Selecting a goal:
In the next phase customer has to choose one potential outcome of provided by the developer.
He should not be influenced by the developer by any means

c. Pursuing the goal:

This is the last stage for the question and answer paradigm. In this stage the developer designs
the steps according to the customer’s specification and need. At every step he keeps the client
informed about the steps.

Since for the prototype I am working with only two modules, I have created two use cases of the system.
Bellow are the latest versions of the use cases for the system.

38 P a g e
 User Centred Design through an Iterative and Incremental Approach

Log in

>>
es
at
<<Include>>

ic
un
m
om
C
<<

Password recovery
policy

User

Fig 14: Use case 1 – log in.

In the first use case we see that it is a simple log in module. It includes password recovery use case if the
users forget the password. I did not include the password recovery policy in the first release of the
design. But the client insisted that I include the module in the system despite the fact that the users
hardly forget the password. However the password recovery policy is not included in the prototype.

39 P a g e
 User Centred Design through an Iterative and Incremental Approach

<<Include>>
Creating Patient Allocating Patient

>>
es
at
ic
<<Include>>

un
m
om
C
<<
<<Communicates>>
Creating Schedule

<<Extends>>

Front <<Include>>
Create/update
`
desk user history
Seeing patient <<Include>> <<Extends>>
<<Include>>
<<Communicates>>
Path. Test

Listing medicine
<<Include>>

<<Communicates>>
Doctor

Path. Test

Fig 15: Use case 2 – front desk and doctors’ panel.

40 P a g e
 User Centred Design through an Iterative and Incremental Approach

Second use case actually holds most of the requirement for the software. There are two types of users
in the system at the moment. One is the front office. Front office creates new patients, making schedule
for the patients and the doctors. And allocate the patients to the appropriate doctors. They also manage
all the information of the patient in case of revisit. The doctors on the other hand can see the patients.
At the end of each visit they gave some medicine to the patients. With that they update the history of
the patient for future reference. If necessary the doctors sends the patient over to the test centres for
pathological test. If necessary they can also obtain the test results from the test centre.

The customer also asked me to build a pay-role for the front desk employees on the basis of their hourly
job. As I drilled down the system workflow I came to know that the front desk employees over that
hospital are not paid in an hourly basis. So if I do create a pay-role module for the front desk employees
it will create serious data discrepancy with their finance and accounts department. For design purpose I
have also created a simplified entity relationship diagram and data definition language library. I have
attached these two documents in the appendix.

8.3 Implementation and deployment:

My key objective in the implementation phase were making the module as quick as possible and keeping
the customer informed in all time of the development process. While implementing the software the
challenge was to keep customer in touch with the lines and lines of coding and explaining what to
expect, when to expect. By the looks of the GUI customer had a bit of idea what will be coming up in the
releases. However until the release was out customer was unable to comment on the probable
outcome. I find the scenario very similar what Martin, R (1999) has predicted in iterative and
incremental development.

Of course getting the users involved in this way means that there will be some substantial
amounts of rework as those users make changes. Indeed, there will also be rework as the
problem domain and solution domains settle down. Sometimes the rework can be so significant
that the team decides to reimplement whole slices. So long as this is infrequent, this is not a bad
thing.

I have to accept the fact that though I kept customer notified of all the things going in the process, the
most of the change request came when the first release was given to the customer.

I have used Martin, R (1999)’s concept of reusable framework. I have used create/update/delete doctor
to show the client how to create/update/ delete record from the system. Once customers agreed with
the format, I have used the same format for history, patient and test and medicine.

I was not able to deploy the module to the customer environment for their security reasons. But since
the software has not got any problem deploying in a test environment, I do not thing it will be much of a
difference in the client environment.

41 P a g e
 User Centred Design through an Iterative and Incremental Approach

9. Findings:
As I have mentioned in introduction that my objective of the project is to use User Centred Design
methodology in more AGILE way. Through my practical part of the project I tried to learn how can I
make the user more closer while making development process more iterative and modular in nature.
One of my other purposes of the paper was to understand how cost and time of the project will be
affected if we use this approach. I came up with the result that as predicted iterative incremental
approach is very handy when the iterations are put in harness. That is the project manager has to have
the power to say no to the overwhelming user requirements. At the same time the programmers have
to be well aware of their target.

Getting the scope right and intact is one crucial thing that a project manager has to maintain in this
methodology. He has to observe keenly all the parts of the project and search for things going out of
scope. One easy way to do it is communicating with the user. For communicating with the user I have
faced two very distinctive problems.

a. Am I communicating with the right person?

This problem occurs in client side. My contact for developing this software was one a person
who is holding a key position in the IT department of the hospital. It was fairly very easy to let
him understand about what is going on in development process. However the setback is, he is
not the actual user of the modules. In my case the actual users are front desk managers and
doctors. But I cannot come across to any of the group, it is because they are too busy with the
patients or there are tied with number of non-disclosure agreements (NDA)s by the
management. For this reasons they are always unable to exchange their view regarding the
software. The actual time when they are allowed to use this software and give opinion, by then
the software is readily deployed, up and running in the customer environment. So even if they
find some major bugs in the system, there is nothing much the programmer can do about it but
to wait until the next release. Other fact is the most of the user in the project are ordinary
management or doctor user who has almost no technical knowledge about any kind of
computer. So to make them understand what is going on in development the need to be trained
by the programmers. I do not think it is an affordable solution to the problem. Because if we are
to follow this procedure then the users are needed to be trained every time after a new release
is out.

b. Is right person is communicating with me?

In most of the extreme programming scenario, actual user does not communicate with the
designers and coder of the potential software. Most of the time the project is handed over to
the project management team consisting project managers, team leads and test team leads.
They sit together and plan out the system in terms of paper based design and then hand out to
document and work order to the implementation. This practice results in less or even to

42 P a g e
 User Centred Design through an Iterative and Incremental Approach

communication between the customer and developers. To make proper practice of user centred
development the distance between the developer and the client.

These setbacks can easily be overcome by getting the customer and actual implementers closer to each
other. Focus group discussion can be one of the major ways we can handle this kind of problem. Proper
use of management time for both the clients and the developer side become crucial in any kind of
customer meeting. Many programmers value the work in hand rather than spending time with the
customer finding a way to optimize the code.

To make a proper use of these focused group discussion only the related stake holder should identified
to come to the meeting. The actual persons who will be using the software and the person who are
making it for them have to come face to face. The managers of the project and managers for the clients
can work as arbitrator in the meeting. To make a proper use iterative and incremental approach more
than one focus group discussion for spate unrelated modules can be done all at a time.

Before going deep into speculation of the cost factor of the software let us have a look at the number of
iterations per stage. The following graph shows the number iteration needed the two modules that I
developed. Please note that I have not deployed the module in the client environments. Therefore
number of iteration may vary considering if there is any deployment issue.

5
5
3 3
4
3
2
2 2

1 0 Log in
0
0 F/O and doc interface
0

Fig 16: Iteration count per module

The above graph shows number of iteration so far for while producing the two modules. Initially no
requirement was acquired for specifically log in module. I have already mentioned in system design
chapter the only thing was changed in the first iteration was password recovery policy. On the other
hand while doing the front office and doctors’ interface for the system lots of iteration was done

43 P a g e
 User Centred Design through an Iterative and Incremental Approach

between me and the client. If we take front office and doctors’ interface module as standard then we
can compute that at least three and half iteration has been needed or successfully complete each
module. This brings up that a module can be done in 15 iterations. (If we consider average number of
iterations in deployment as well.)

The number of iterations is one of the critical cost factors if we concentrate keeping the price of the
software low. For me average iteration per module came up to be 15. However, I do not think it is an
absolute number for iteration per module. I had the privilege to work with only one stakeholder in the
client side. In a real life scenario however there will be different types of stakeholders all wanting the
module in a way that will be helpful to them. So the number of iteration can greatly increase if we
consider that. On the other hand number of iterations can be put in chains if the requirement gathering
is done in an efficient manner and evaluation meeting is none in a productive manner.

Production time is another crucial factor in software’s budget. The less the productions time, less the
cost of the software becomes. For me it took only seven days to make four releases one after another
and get job done remark from the customer. It happened with such ease because I have worked with
isolated module of a big software. Another compelling reason for making the modules very fast is I had
the privilege of contacting the client informally at any given time of the day. In real world focus group
discussion has to be organized in a planned manner. The stakeholder and attendees have to be notified
well prior to the meeting. We should not forget unlike the programmer they have many other
responsibilities apart from the software. Making the modules as discrete as possible depends on the
credibility of the project manager and planner for the project. The modules need to be discrete because
then it can easily be possible to run more than one module at the same time thus making the software
fast. At the same time they have to consider the fact that if the modules are too discrete then there will
be issues while integrating them. Data type mismatch is one of the common issues while making
software in modular manner. If the variables are not casted properly there can be major discrepancy in
data when the software is put into effect. For this reason, using common framework and library are
must while developing.

Since I was not given a chance to deploy my software in client environment another important issue,
namely data migration, has been overlooked. Getting a already existing data in desirable format and
then migrating the data to the new environment always becomes major risk in these kind of projects.

Lastly, post deployment product support though is very critical in software projects but I do think that it
lies in the project managers hand whether he will consider it inside the iterative and incremental
development methodology or not. Normally post deployment product support is considered as a
separate project in itself. During the product support the support engineers find the bugs or
customization issues in the system. If possible they fix the bug or customize the software according to
customers’ need. They keep record of the bugs which are not possible to fix at that very moment. The
software engineers fix the bugs in later releases. I do not think this practice should fall in either IID or
UCD. Because the former deals with functional evaluation not computation error while the later deals
with only functional feature of the software.

44 P a g e
 User Centred Design through an Iterative and Incremental Approach

10. Conclusion
One of my prime objectives for the paper was to find out whether iterative and incremental approach
and user centred design can work together and enhance productivity of the developers. To me the two
methodologies are just two sides of coin. Both of the methodologies look to the software development
process from two different but prime point of view. The first one, iterative and incremental approach,
concentrates on the mechanism of software development from the developers’ perspective. On the
other hand user centred design looks into software development from customers’ point of view.
Through my research I was able to show that if a manager develops a software in part by part manner at
the same time rests on the users opinion to measure success factor of the software, can produce the
best output possible. At the same time I have find out that managing the customer opinions on ongoing
software development process is not easy as it seems. It lies to the efficiency of the project manager to
make level between actual prospect of the project and overwhelming customers’ requirements. The
management of short customer focus group meeting is very crucial to make this kind of software
development a success. This is why the roles for the arbitrator in these meetings are of high importance.
They have keenly observe the processing and put any out of the scope discussion in chains. For this
reason I recommend one more arbitrator should be included in the focus group discussion. This
arbitrator will come from the customer side but will be highly technically sound person. He will then
have in depth knowledge on what is going on in the customers’ minds and what is an achievable target
given the present condition. The developers will also feel fairly secure when they will see a ‘techy’
person is owns the process and taking effective role to mitigate arguments. The major setback pf the
proposed methodology is however, in this methodology the developers has to have more access to the
potential users. For this reason I recommend building a project team in the client side as well. It will
facilitate developers access to the customer and thus enhancing the information flow.

The concept that I tried to figure out can go a long way in future problems. One of the major arguments
against iterative and incremental approach is this methodology is not very good for innovative projects
because in the innovative projects the project managers do not have any clue where to break the
process down and make a new iteration. Since by using my proposed methodology the project team will
have more access to the customer, the managers will have better understanding of the risks that can
occur in future. For this reason I believe it will perform very well in the innovative project as well. Some
of these kind of project might be software support and maintenance, data migration projects and
projects in some computing project as well. In the end I would like to say it is not a group of managers or
really motivated team that makes a project success. It is and all out effort starting from requirement
analyst to evaluation and test manager in the client side makes the project an on time on budget
project. Making successful information flow and interpretation is something which adds up to the
project’s success.

45 P a g e
 User Centred Design through an Iterative and Incremental Approach

11. Appendices
11.1 List of reference:
Ambler, S (2001) Agile Architecture: Strategies for Scaling Agile Development. Ambysoft Inc. [Online].
Available At: http://www.agilemodeling.com/essays/agileArchitecture.htm (Accessed: 29/04/09)

Berard, E. (2006) Life Cycle Approaches. The object agency [Online]. Available At:
http://www.itmweb.com/essay552.htm (Accessed: 15/04/09)

Cockburn, A. (2005) Are Iteration Hazardous for Your Project. Alister Cockburn [Online]. Available At:
http://alistair.cockburn.us/Are+iterations+hazardous+to+your+project%3f (Accessed: 17/03/09)

Cockburn, A. (2007) Incremental versus Iterative Development. Alister Cockburn [Online]. Available At:
http://alistair.cockburn.us/Incremental+versus+iterative+development (Accessed: 18/03/09)

diSessa, A (1986) ‘Notes on the Future Programming: Breaking the Utility Barrier ’. User Centred System
Design: New Perspective in Human-Computer Interaction. New Jersey: Lawrence Erlbaum Associates
Publishers.

Gersh, J., McKneely, J., and Remington, R. (2004) ‘Cognitive Engineering: Understanding Human
Interaction with Complex Systems’. Johns Hopkins APL Technical Digest. 26, pp.377.

Google Inc (2002) Google User Experience: Our aspirations. Google Inc [Online]. Available at:
http://www.google.com/corporate/ux.html (Accessed: 13/03/09)

Goulde, M. And Brown, A (2006) Open Source Software: A Primer for Health Care Leaders. California
Healthcare Foundation [Online]. Available At:
http://www.uversainc.com/download/OpenSourcePrimer.pdf (Accessed: 26/04/09)

Hooper, K. (1986) ‘Architectural Design: An Analogy’ User Centred System Design: New Perspective in
Human-Computer Interaction. New Jersey: Lawrence Erlbaum Associates Publishers.

Hutchins, E. et al (1986) ‘Direct Manipulation Interfaces’ User Centred System Design: New Perspective in
Human-Computer Interaction. New Jersey: Lawrence Erlbaum Associates Publishers.

Katz-Haas, R (2004) Usability Techniques: User Centred Design and Wed Development. Society for
Technical Communication [Online]. Available At:
http://www.stcsig.org/usability/topics/articles/ucd%20_web_devel.html (Accessed: 15/03/09)

Koppel, R. et al (2005) ‘Role of Computerized Physician Order Entry Systems in Facilitating Medication
Errors’. Journal of the American Medical Association. Vol. 293 pp1197-1203.

Larman, C. and Basili, V. (2003) Iterative and Incremental Development: A Brief History. IEEE Computer
Society [Online]. Available At: http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf (Accessed:
13/03/09)

46 P a g e
 User Centred Design through an Iterative and Incremental Approach

Laurel, B. (1986) ‘Interface as Mimesis’ User Centred System Design: New Perspective in Human-
Computer Interaction. New Jersey: Lawrence Erlbaum Associates Publishers.

Lazer, J et al (2002) User Involvement in the Web Development Process. [Online]. Available At:
http://www.chi2004.org/res/LazarUserInvolvSIGprop-2002.pdf (Accessed: 01/04/09)

Lewis, C. (1986) ‘Understanding What’s Happening in the System Interaction’. User Centred System
Design: New Perspective in Human-Computer Interaction. New Jersey: Lawrence Erlbaum Associates
Publishers.

Mark, W. (1986) ‘Knowledge-Based Interface Design’ User Centred System Design: New Perspective in
Human-Computer Interaction. New Jersey: Lawrence Erlbaum Associates Publishers.

Martin, R (1999) Iterative and Incremental Development (IID). Engineering Notebook Column. [Online].
Available At: http://www.objectmentor.com/resources/articles/IIDII.pdf (Accessed: 14/04/09)

Meijer, J. (2009) Importance of Medical Information Software. Article Alley[Online]. Available At:
http://www.articlealley.com/article_868378_45.html (Accessed: 14/04/09)

Microsoft Corporation (2001) Windows User Interface Technical Articles: Microsoft Inductive User
Interface Guidelines. Microsoft Corporation [Online]. Available at: http://msdn.microsoft.com/en-
us/library/ms997506.aspx (Accessed: 13/03/09)

Nielson, J. (2005) Medical Usability: How to Kill Patients through Bad Design. Jakob Nielsen [Online].
Available At: http://www.useit.com/alertbox/20050411.html (Accessed: 29/03/09)

Norman, D. (1986) ‘Cognitive Engineering’ User Centred System Design: New Perspective in Human-
Computer Interaction. New Jersey: Lawrence Erlbaum Associates Publishers.

Owen, D. (1986) ‘Answers First then Questions’. User Centred System Design: New Perspective in
Human-Computer Interaction. New Jersey: Lawrence Erlbaum Associates Publishers.

Riley, M (1986) ‘User Understanding’. User Centred System Design: New Perspective in Human-Computer
Interaction. New Jersey: Lawrence Erlbaum Associates Publishers.

Roth, E., Patterson, E. and Mumaw, J. (2002) Cognitive Engineering: Issues in User-Centered System
Design. In J. J. Marciniak (Ed.), Encyclopedia of Software Engineering, 2nd Edition. New York: Wiley-
Interscience, John Wiley & Sons.

Spence, I. and Bittner, K (2005) What is Iterative Development: The Management Perspective.
IBM:DeveloperWorks [Online]. Available At:
http://www.ibm.com/developerworks/rational/library/may05/bittner-spence/index.html (Accessed:
17/03/09)

47 P a g e
 User Centred Design through an Iterative and Incremental Approach

Tattersall, G (2002) Supporting Iterative Development through Development Management.

IBM:DeveloperWorks [Online]. Available At:
http://www.ibm.com/developerworks/rational/library/2830.html (Accessed: 17/04/09)

48 P a g e
 User Centred Design through an Iterative and Incremental Approach

11.2 Entity Relationship Diagram

User

Doctor Schedule

Medicine

History

Patient Test

49 P a g e
 User Centred Design through an Iterative and Incremental Approach

11.3 Data Definition Library

Doctor

History

Medicine

50 P a g e
User Centred Design through an Iterative and Incremental Approach

Patient

Schedule

51 P a g e
User Centred Design through an Iterative and Incremental Approach

Test

User

52 P a g e
 User Centred Design through an Iterative and Incremental Approach

11.4 Surveys

11.4.1 Questionnaire 1 – Medical Staffs:

They following surveys are prepared for University of East London, School of Computing & Technology
as a part of dissertation (Course # CNM015). Please be assured that the information of the survey will be
used for the course work only and will not contain any evidence of your identity.

Personal Information

1. Please state your gender.

a. Male
b. Female
2. Please select your role in the organization
a. Physician
b. Manager
c. Intern
3. Please enter the state of the organization you work in
a. Private
b. Public/State owned
c. Both

Research question

1. Have you ever heard/used medical software?

a. Heard
b. Used
c. No

2. If you used/ heard of that kind of software, then what kind of software were those?
a. Public Health and Biosurveillance
b. Electronic health or medical record
c. Medical Practice Management Software
d. Other

3. Provided the cost factor of these softwares, do you thing every medical organization should
have automated software to do their day to day activity.
a. Yes
b. No

4. What software do you think is necessary in the present scenario of your organization?

53 P a g e
 User Centred Design through an Iterative and Incremental Approach

a. Public Health and Biosurveillance

b. Electronic health or medical record
c. Medical Practice Management Software
d. Other
5. If there is an ongoing development of these kind of software, would you want to give your
opinion in the development process.
c. Yes
d. No

6. If yes then what phases of the software development do you think you will be able to take part?
h. Data Gathering
i. Requirement Analysis
j. Designing the system
k. Execution
l. Evaluation
m. All
n. I do not know what does the pahses refer

7. Why do you think there is not many of this kind of sogyware ar present
a. Lack of awareness
b. Cost factor
c. Both
d. Cannot state the possible reason.

8. How do you think these softwares will become helpful?

e. Adversely
f. So so.
g. Wastage of money
h. Do not know the possible outcome.

9. How the patients will like these software, if deployed

a. Very much
b. Will be suspicious
c. Won’t be happy because they need a human touch.
d. Will not have any problem, will not be happy though.

54 P a g e
 User Centred Design through an Iterative and Incremental Approach

11.4.2 Questionnaire 2- Software vendors

They following surveys are prepared for University of East London, School of Computing & Technology
as a part of dissertation (Course # CNM015). Please be assured that the information of the survey will be
used for the course work only and will not contain any evidence of your identity.

Personal Information

1. Please state your gender.

a. Male
b. Female
2. Please select your role in the organization
a. Manager
b. Coder
c. Tester
3. Please enter the type of the organization you work in
a. Vendors
b. Freelance developers

Research Question

1. Do you have any experience of working is medical software project?

a. Yes
b. No
2. What kind of software project you worked in?
a. Public Health and Biosurveillance
b. Electronic health or medical record
c. Medical Practice Management Software
d. Other
e. None
3. What was your responsibility in the development process?
e. Manager, Team Lead
f. Coder
g. Tester
h. Other (e.g requirement analyst)

4. The software that was developed, was it on time on budget project?

a. Yes
b. No

55 P a g e
 User Centred Design through an Iterative and Incremental Approach

5. How the customers felt about the software, when delivered?

a. They were very happy
b. Not very happy but not very disappointed.
c. Disappointed.
6. In what phases the customers where included of the development phases?
a. Data Gathering
b. Requirement Analysis
c. Designing the system
d. Execution
e. Evaluation
f. All
7. In what phases in the development process do you think that the customers should be included?
a. Data Gathering
b. Requirement Analysis
c. Designing the system
d. Execution
e. Evaluation
f. All

56 P a g e
 User Centred Design through an Iterative and Incremental Approach

List of figure

Name of figure Page No.

Fig 1: Subject matter for the research 4
Fig 2: Intregal field for cognitive engineering 18
Fig 3: Comparing good and bad example of variable mapping in users prespective 19
Fig 4:Gulf of execution and evaluation Source Norman, D. (1986) 20
Fig 5: Bridging the two gulf in system design. Source Norman, D. (1986) 21
Fig 6: Task Completion Stages Provided by Norman, D. (1986). 22
Fig 7: Iterative and Incremental Development Methodology (wikipedia) 24
Fig 8 : iterative development Spence, I. and Bittner, K (2005) 25
Fig 9: Water fall method 26
Fig 10: Construction of Iteration in IID in project manager’s eye - Spence, I. and Bittner, 28
K (2005)
Fig 11: Hypothetical project management process in project managers view (Spence, I. 29
and Bittner, K (2005))
Fig 12: The proposed module for the prototype. 34
Fig 13: Story board of the proposed prototype. 36
Fig 14: Use case 1 – log in. 39
Fig 15: Use case 2 – front desk and doctors’ panel. 40
Fig 16: Iteration count per module 43

57 P a g e