50120130406031

International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),

ISSN 0976 - 6375(Online), Volume 4, Issue 6, November - December (2013), © IAEME

269

HCI FRAMEWORK TOWARDS GAP ANALYSIS AND EVALUATION OF

USABILITY FACTORS IN DISTRIBUTED SOFTWARE PROJECT

DEVELOPMENT

Dillip Kumar Mahapatra1, Tanmaya Kumar Das

2

1(Head of the Department of Information Technology, Krupajal Engineering College/Biju Patnaik

University of Technology, Rourkela, Odisha, India,) 2(Assistant Professor, Department of Computer Science & Engineering,

C.V Raman College of Engineering, Bhubaneswar, /Biju Patnaik University of Technology,

Rourkela, Odisha, India,)

ABSTRACT

The science of human-computer interaction (HCI) seeks to understand the constraints and

paradigms that define how people use technology. Cognitive science provides detailed knowledge of

how people perceive, understand, and remember information; HCI applies this knowledge to predict

how people will react to interfaces, and how those interfaces can be optimized for humans. Many of

the basic principles of HCI have a huge impact on usability, and a thorough grounding in these

concepts can help designers bring an informed perspective to unique interface problems. Human-

computer interaction (HCI) is a multi-disciplinary field with a focus on the interaction between

humans and computers. HCI emerged in the 1980s with a focus on usability of computer applications

and productivity of users. With the spread of computing, HCI researchers expanded interests to

include areas such as social computing, ubiquitous computing, creativity, accessibility, and

entertainment.

An interaction designer harmonizes form, content, and behaviour of interactive arte-facts;

both software and hardware, to deliver products that are useful, usable, and desirable. Interaction

designer defines “the structure and behaviour of interactive products and services and user

interactions with those products and services”.

Everyone who has experienced it knows that developing software in teams that are

distributed around the world can be a difficult and frustrating experience. In this paper we have

projected some views on usability factors of HCI framework and its importance in analysing GAP in

developing distributed software project.

INTERNATIONAL JOURNAL OF COMPUTER ENGINEERING &

TECHNOLOGY (IJCET)

ISSN 0976 – 6367(Print)

ISSN 0976 – 6375(Online)

Volume 4, Issue 6, November - December (2013), pp. 269-283

© IAEME: www.iaeme.com/ijcet.asp

Journal Impact Factor (2013): 6.1302 (Calculated by GISI)

www.jifactor.com

IJCET

© I A E M E



270

KEYWORDS: Distributed Software Development, Human Centred Software Engineering, HCI

Process framework, GAP, HCSD Tools,

I. INTRODUCTION

Like Distributed Software Development, HCI too gives a lot of emphasis on processes to

achieve usability and user experience goals. HCI literature suggests many processes, activities,

methods, skills, and deliverables. A typical HCI design process is made up one or more phases, each

of which may consist of one or more HCI activities. Each activity may be associated with one or

more methods. A method may require specific skills. An activity may result in a specific deliverable

that may be an end in itself, or may be an input for another activity in the HCI design process or the

software development process (Ref.02).

The last decade saw further expansion of the use of software beyond productivity and

automation. Interactive products played a very important role in leisure, entertainment, and

socialisation. In this context, the “quality of experience” afforded by a product to its users became a

broader quality attribute beyond usability. So what emotional responses does a Product trigger in the

users’ minds before, during, and after use? Was using the product a nice experience? Do users trust

the product? Do they feel confident while using it? Do they enjoy the experience? Do they feel

anxious, Proud, Drained? Do they save their time with the product and look forward to their next

session with it, or do they dread the ordeal?

In addition to usability, the answers to these questions determined the successes of products in the

last decade and promise to do so in the next few years as well.

II. HUMAN COMPUTER INTERACTION AND DISTRIBUTED SOFTWARE

PROJECT DEVELOPMENT

Since the earliest days of computing, software development tools have been based on a

dangerous stereotype: development is done by a nerd alone in a box. In fact, when one observes

modern software development, it's a very social activity! Members of a development team

collaborate, co-operate, and learn from one another. Even the neediest programmer spends as much

time communicating with colleagues as studying code in an editor(Ref.04).

2.1 Human-Centred Software Development Tools The Human Interactions in Programming (HIP) Group works at the intersection of Human

Computer Interface (HCI), Common Software Co-operative Work (CSCW), and Software

Engineering which leads to Human Centred Software Engineering (HCSE). HIP group includes

usability and human factors specialists, software and computer engineers, cognitive psychologists,

and artists and are meant for advancing the basic science and technology in human-centered software

systems development, human-computer interfaces engineering, usability and quality in use

engineering, empirical studies for software engineering through a program of fundamental research,

graduate education, as well as technology development (Ref.01).

Approximately half of the development time is spent for studying software development,

either through controlled experiments or hanging out with developers through implementation, and

the rest time is spent in creating new tools to help difficult situations that developers face, like being

a newcomer to a team with a lot of existing code or dealing with the interruptions and task switches

that break up a developer's day (Ref.05).



271

These two activities are mutually reinforcing: the studies inspire tools to build; and exploring

treatments that teaches more about the problems (Ref.05).

2.2 Distributed Software Development Large-scale software development is a collaborative activity that requires diverse expertise

and substantial human resources. However, as a software project increases in size, it is often difficult

or impractical to concentrate all the necessary human resources in one location. Furthermore, today’s

advanced telecommunications and collaboration technologies provide an added incentive to

collaborate with geographically distributed colleagues but the fact remains that coordination in

distributed, large-scale software development is still problematic for many organizations because

working from a distance brings increased coordination overhead, reduced richness in communication

media, and more substantial delays (Ref.10).

The increased distance makes communication and coordination much harder. We're

emphasizing the research questions like:

• How can it be that the distant colleagues seem as "real" as local ones?

• How can the team knowledge be spread despite the distance?

• How do newcomers join remote teams when they lack face-to-face connections?

2.2.1 Knowledge Flow in Software Development Teams Developers keep a lot of critical project information only in their heads. As a result,

developers' work is often blocked to look for information, and developers frequently interrupt each

others' work to ask questions. This approach enjoys certain benefits, like demand-driven production

of information that can be tailored to the asker's needs(Ref.12). But, the downsides are also

significant: knowledge loss due to team attrition; slow on boarding of new team members; and

productivity loss due to information seeking. In order to encourage better knowledge flow, some of

these research questions arise like:

• What are the most difficult and frustrating questions to find answers to?

• How much knowledge can we recover from existing team artefacts?

• How can it be encouraged more knowledge capture without impacting productivity?

• How do newcomers to teams learn from their more experienced colleagues?

2.2.2 Coordination and Processes of Software Development Teams As Distributed Software Development (DSD) is a highly collaborative activity hence,

Developers work with people on their own team, and teams work with one another to create large-

scale software products. Within teams, development is split among people of differing roles such as

development, testing and requirements, and is governed by a development life cycle, historically

waterfall, but increasingly Agile. Dependencies between teams require communication, cooperation

and coordination for success, but problems in any of these areas lead to conflicts. In order to

understand how teams work well or poorly together, these research questions are likely to be

answered (Ref.09):

• What are the uses of agile methods?

• What are the work practices that help and hurt inter-team collaboration?

2.2.3 Spatial Representations of Code As developers are frequently blocked and interrupted in their work, they often have to return

to tasks that have been put aside, sometimes for minutes, sometimes for months. Today's

development took place a large burden on a developer to find the documents they work on by

remembering a lot of symbol names -- the names of projects, files, bug reports, classes, methods, and



272

on and on. This memory tax means that developers spend a lot of time searching to find the

documents they previously worked on. In one line of our research, we are exploring the use of spatial

representations of development documents to allow developers to use spatial memory to find them

(Ref.02). So the questions arise here are;

• How do developers depict their code when they explain it to others?

• What are the navigation patterns, developer’s exhibit when working with code?

• What representations of code and other artefacts best support developers' work?

III. HUMAN COMPUTER INTERACTION(HCI) PROCESS FRAMEWORK

Here we propose a multi-disciplinary process framework for HCI design as shown in fig.1

that includes phases, activities, methods, skills, and deliverables. This framework is proposed to be a

flexible way of understanding and communicating the work of HCI practitioners in different

contexts. Our objective is not to come up with another prescriptive a universal HCI design process

model, but to articulate the typical HCI activities within which several methods and deliverables can

be assimilated. Not all activities or methods may be essential in each instance of the process(Ref.11).

Figure 1: Framework for HCI design process.



273

This framework is divided into a number of phases. Each phase consists of one or more

activities. Each activity is associated with one or more methods. Each method requires specific skills

and could be associated with a particular discipline. Each activity results in specific deliverables. A

deliverable may be an end in itself, or may be an input for another activity in the HCI design process

or the distributed software development process. For example, usability evaluation is an HCI activity

that is a part of almost every process. Usability evaluation could be performed by several methods

such as a think-aloud test, a performance test, a heuristic evaluation, a cognitive walkthrough, or an

expert review. Performing each method requires a specific set of skills. E.g. the think-aloud test

requires skills in prototyping, qualitative test design, user recruitment, interviewing users, and

analysing data. The activity results in deliverables such as usability problems with the design,

potential ideas to improve the design, and possibly a decision about the future course of development

(Ref.13).

In this framework, eight HCI activities are identified and it is proposed and essential for

integration with Distributed Software Development (DSD) process models. We organise these

activities into four phases, in terms of four questions; what matters? How should we respond? How

should the design be detailed? How are we doing?

While the whole process is iterative, there are two inner loops as shown in Fig.-1: feasibility of the

product definition and redesign of the prototype to fix problems noticed. If required, it may be

necessary to go through these inner loops more than once, but going through them once will be

required for all projects (Ref.02).

3.1 ANALYZING THE FRAMEWORK In the framework, not all elements are mandatory. While all activities are essential, the

specific methods mentioned above need not be used to do those activities. These methods are only

suggestive, and alternatives could be found (Ref.08).

Further, the deliverables are of two types: essential and optional. Some deliverables are

related to a particular method, and will emerge only if that method is used (e.g. work models,

affinity). Other deliverables are internal work products often preferred by HCI practitioners (such as

personas and storyboards), but not mandatory. However, some deliverables are essential for

completing the HCI design process (Ref.07).

The deliverables that could be considered essential in this framework from an HCI

perspective and the process framework maps on to the divergence, transformation, convergence

design stages. Many of the methods or techniques that help answer the question “what matters” and

some that help answer the question “how should we respond” are the ones that help the team in

divergence and problem setting. Many of the methods and techniques that help answer the questions

“how should we respond” and some of “how the design should be detailed” help in the transforming

the problem space so that a solution become evident(Ref.14).

Finally, the methods and techniques that help answer the questions “how should the design be

detailed” and “how are we doing” help in converging to a particular solution. These ideas are

summarised in Fig.2.



274

Figure 2: Divergence, transformation and convergence and the HCI design techniques and methods.

This framework describes the activities done by a multi-disciplinary team, including the HCI

disciplines, technology, business analysis, domain experts, and marketing. It should be seen as a

framework to design interactive products rather than a process framework to be followed by

designers.

IV. ANALYZING GAPS

4.1 Human Computer Interaction Related Gaps Distributed Software development(DSD) evolved in the context of the IT industry with the

objective of developing “methods and procedures for software development that can scale up for

large systems and that can be used to consistently produce high-quality software at low cost and with

a small cycle time”. Over the same period, computer software made its journey from high-end

scientific equipment to pervasive, almost invisible consumer products of the new millennium that

touch the lives of a large number of people. In the early 1990s, it was estimated that almost half of

the code in systems and 37-50% of efforts are related to the system's user interface. The share has

probably gone up today as computing has become more pervasive. As a result, the importance of

user centred design approaches has gained ground (Ref.15).



275

The fields of HCI and DSD have evolved independently in the past two and a half decades,

apparently almost completely unaware of each other until recently. There still exist major gaps

between HCI and DSD, both in academic institutions and in the industrial practice. The standard

curricula for each field make little if any reference to the other field and certainly do not teach how

to interact with the other field. There are major gaps of communication between the HCI and DSD

fields: the architectures, processes, methods, and vocabulary being used in each community are often

foreign to the other community.” Deliverables of one group are not evidently useful to the other,

hampering workflows. There is an apparent disconnect between the priorities of the two groups

(Ref.15). These gaps could lead to communication and coordination problems, duplication of effort,

compromises in the process, and eventually the quality of the output. There is a need to have shared

processes, common techniques, nomenclature, checkpoints, and measures for success).

The main goal of HCI activities is the same as that of Software process models, viz. to deliver

a high quality product to the end user to satisfy a human need or to solve a human problem.

However, skills and techniques required for doing HCI activities are quite different from the ones

required for doing the DSD activities (Ref.15).

As HCI activities utilise a specialised set of abilities, viz. broad-based designer aptitudes

such as sensitivity, creativity, ability to synthesise form, visualise, sketch and present ideas,

specialised HCI skills such as conducting user studies, analysing user needs, visualising scenarios,

user interface design, information visualisation, prototyping, and usability evaluation, and knowledge

in the areas such as cognitive psychology, ergonomics and social and cultural issues. These abilities

are themselves derived from several disciplines and each may take a lifetime to master. Quite clearly,

HCI is a specialisation distinctly different from traditional software engineering and having the

people with these skills in the team is important. The HCI practitioners must have process support

before they can deliver good quality usable software (Ref.15).

Firstly, skills must be converted into actionable activities. It is a common complaint by HCI

practitioners working in very process-compliant companies that they are seldom called upon to do

user studies or carry out usability evaluations or even allowed to meet the users. This happens

because the prescribed DSD processes adopted by the organisation do not demand that these HCI

activities need to happen (Ref.15).

Secondly, the activities must be done at the right time. For example, if requirements have

already been frozen before the HCI person is involved in the project, and if the use cases already

specify the strategy, scope and structure levels of user experience of the product, doing the activities

related to user needs identification, interaction design or information architecture at this stage may be

irrelevant.

Thirdly, the activities must result in the right kind of deliverables that must be used by the

rest of the team in the intended manner. Though the final deliverable is the user interface design, the

HCI team needs to produce several intermediate deliverables. Some of these are for use internally by

the HCI team members, for example analysis reports of individual interviews, a description of a

persona, or a set of screens tied together through a low-fidelity prototype. Some others are for

stakeholders from marketing, technology, or business to respond, for example findings from an

affinity diagram, or scenarios in the life of the persona. In addition, some others may be elements

that need to be incorporated in the product as is, for example the information architecture, hierarchy,

labels in a menu, colour, font, and size specifications, icons and layouts, or raw html pages. All these

outputs must be planned for and used appropriately(Ref.15).

Tools and techniques need to be put together to enable the HCI team to control their output

depending on the results of their own evaluations. Such tools need to go beyond the usual separation

of the presentation layer from the business logic. Finally, there is a need for mutual trust and

respect between the team members from both disciplines for each other’s activities, deliverables, and



276

decisions. The problems of communication and power within the project existed between developers

and designers as each group defended their discipline. If the HCI design needs to be changed for

some reason, the HCI team must be consulted and given an opportunity to propose an alternative

rather than implementing a design that was deemed right by the programmers. In turn, the HCI team

must review the ongoing development work (Ref.15) regularly to keep track of changes and respond

to new situations quickly to match development cycles.

One obstacle is the deep-rooted myth that usability is not a central topic of DSD. Usability

activities are considered easily dispensable by a software project manager when the project is short

on budget or time. Another obstacle is the ambiguity associated with usability, the different

meanings it presents to different people. Claims about usability methods are hard to prove using

classical scientific techniques because of the difficulty in collecting statistically valid empirical

evidence.

Further obstacles come because HCI activities represent a paradigm of outside-in and holistic

development of products. The parts facing the users are developed first, the system internals later.

Organisations used to DSD paradigm of inside-out and modularised (or reductionist) design have a

natural tendency to resist this major paradigm shift. The social and cultural differences between the

people with HCI and DSD backgrounds do not help(Ref.15).

Gaps exist also in HCI and DSD research. Social and cultural differences play a role there as

well. Sutcliffe is sceptical about whether synthesis will ever emerge in DSD and HCI research for

social rather than intellectual reasons. Disciplines tend to have self perpetuating mechanisms since

they form communities that mutually support individual survival via peer review. Both HCI and

DSD have well developed areas of research, but many researchers in either field rarely reference the

other field, and the research seems to be motivated by quite different ideas (Ref.16).

4.2 Gaps in Real-Life Practices The situation, where HCI practitioners and software Developers do collaborate, the main

impediment in implementing the HCI recommendations is actually the non-availability of time in the

projects. Infrequent contact leads to misperceptions and miscommunications between groups. There

appear to be important differences in how software Developers and HCI practitioners to answer the

question regarding who could done the testing of the usability of software. Software Developers

think quality assurance or software engineers themselves conducted these tests, while HCI

practitioners do think that they can handle it. To g(Ref.05)et a first-hand experience of the gap

between HCI and DSD, The following questions need to be answered;

• How and when do HCI design decisions happen in the SE process?

• What role do the HCI practitioners play? How do they influence the DSD process?

• What are the common objects between HCI and DSD process in use today?

• How are the concerns raised above about HCI and DSD integration handled?

4.3 HCI Inputs Are Not Taken During Requirements Specifications The main issue that pointed out is that HCI inputs are needed early in the process before

requirements are finalised. Use cases in requirements documents routinely over-specified the HCI

design, including details such as the sequence and the contents of dialog boxes in the application.

This over-specification is happened possibly because there is a physical and cultural distance

between the developers and users, the development teams are less familiar with the context of users,

and the requirements specifiers want to have a control on the user interface (Ref.11).

HCI design process is not followed during requirements specification and HCI skills are not

used in most cases. Several participants have complained that customers do not state many usability

requirements explicitly or in responses to questionnaires. It is well known to the HCI practitioners



277

among the participants that such requirements could be captured by ethnographic user studies though

no such studies are carried out in most projects. Inappropriate HCI design decisions specified in use

cases seemed to have a ripple effect in many areas of user experience. HCI practitioners remarked

that once something is written up in a requirements document it gets “set in stone” and subsequent

changes, however desirable, become uphill. The only way solve this problem seems to be to involve

the HCI practitioners early in the project, certainly before freezing UI design, and possibly before

freezing on requirements. Early investment in HCI design makes business sense for users, customers

and the vendors. However, this happened in only 1 of the 8 cases. One related business problem

seemed to be particularly difficult to resolve to several participants. Requirements were typically

specified before a project contract was drawn up between the vendor and the customer.

Requirements were the basis on which project budgets and timelines are worked out. Rarely were

these services paid for, and there was a push on the part of the vendors to go through this phase as

soon as possible so that a concrete project materialised with minimum up-front investment. This has

implications not only on the HCI decisions made during this phase, but also to the other

commitments. However, this does not seem to be an insurmountable problem and some vendors have

managed to modify their business process to resolve this issue (Ref.15).

V. PORTING PROJECTS GET MINIMAL HCI INPUTS

Every software project represents an opportunity to improve the user experience. Conversely,

every project also represents a risk of degrading the user experience. This applies even to porting and

migration projects. Less importance was given to requirements gathering in general and usability

requirements in particular in such projects. It was assumed that most requirements were well-

understood and had to be “copied over” from earlier version. However, such ports often involve a

change of delivery platform, a change of context, or a change of users. Either of these can have a big

impact on HCI design and the corresponding requirements (Ref.11).

In one of the experiments (cases), the quality of user experience deteriorated significantly.

This project was to port a product from a legacy platform to a web-based application. The HCI team

studied screenshots of the existing application and reproduced them as closely as possible in a web

browser. They could not meet real users or observe them using the application. A particularly

important HCI issue was missed out completely. The application was a frequent use product and the

users often used keyboard shortcuts. This problem was discovered very late, after the client

representative had signed off and the first version of the product was delivered to the users. The task

completion times in the new software went up substantially, and the users rejected the product

altogether (Ref.09)

5.1 Client Representatives Take Design Decisions

In practice, a client representative routinely drives many HCI design and usability

considerations. Such a person may have never been a user himself or may have moved out of that

role a long time ago. His / her sign-off may not imply that the product is usable. This can be revealed

only by usability evaluations with real users. In the above case, users in the client organization

rejected the product even though the client representative had given his acceptance. The vendor had

to go in for a major re-write to introduce the keyboard shortcuts. The project was delayed

substantially (Ref.03).

5.2 HCI Skills Do Not Have Process Support This point argued in the literature reviewed above was reinforced. Merely having skilled HCI

practitioners on the team did not resolve all HCI issues automatically. They also needed process



278

support to do their work. While most projects studied had some involvement of HCI practitioners,

they still ended with unresolved usability issues that they knew could be solved. A multi-disciplinary

team needs to work together. The team needs to be armed with appropriate user inputs and needs a

common set of work products and a common process to approach the product development

holistically and add value. Role of each discipline needs to be mutually understood and respected,

first within the team and then across the organization (Ref.16).

5.3 Too little and Too Late is Not Good Enough

In some projects, HCI practitioners were pulled in towards the end when too many obvious usability

problems surfaced (as seen by the client contact person). One HCI practitioner described these as

“last straw” projects, while another described his job as akin to “running an ambulance service”. In

these situations, HCI practitioners worked under severe constraints. Typically, the project would

have already spent its allotted budget and time and the HCI practitioners needed to hit the road

running. They had no time to understand the scope of the project and no budget to do usability

activities they wanted to do. Even if some HCI activities were done, most of the recommendations

they could come up to improve the UI seemed too impractical to implement in the given situation.

Few cosmetic changes would be made, mainly to satisfy the client representative, and the project

would be “pushed through” (Ref.08).

VII. HCI AND USABILITY

HCI and usability have their origins in the falling prices of computers in the 1980s, when for

the first time, it was feasible for many employees to have their own personal computer (a.k.a PC).

For their first three decades of computing, almost all users were highly trained specialists of

expensive centralised equipment. A trend towards less well trained users began in the 1960s with the

introduction of timesharing and minicomputers. With the use of PCs in the 1980s, computer users

increasingly had no, or only basic, training on operating systems and applications software.

However, software design practices continued to implicitly assume knowledgeable and competent

users, who would be familiar with technical vocabularies and systems architectures, and also possess

an aptitude for solving problems arising from computer usage. Such implicit assumptions rapidly

became unacceptable. For the typical user, interactive computing became associated with constant

frustrations and consequent anxieties. Computers were obviously too hard to use for most users, and

often absolutely unusable. Usability thus became a key goal for the design of any interactive

software that would not be used by trained technical computer specialists. Popular terms such as

“user-friendly” entered everyday use. Both usability and user-friendliness were initially understood

to be a property of interactive software (Ref.11). Software either was usable or not. Unusable

software could be made usable through re-design.

Usability is a quality attribute that assesses how easy user interfaces are to use. The word

"usability" also refers to methods for improving ease-of-use during the design process. Usability is

defined by 5 quality components:

Learn ability: How easy is it for users to accomplish basic tasks the first time they encounter the

design?

• Efficiency: Once users have learned the design, how quickly can they perform tasks?

• Memorability: When users return to the design after a period of not using it, how easily can

they re-establish proficiency?

• Errors: How many errors do users make, how severe are these errors, and how easily can they

recover from the errors?

• Satisfaction: How pleasant is it to use the design?



279

There are many other important quality attributes. A key one is utility, which refers to the design's

functionality: Does it do what users need?

Usability and utility are equally important and together determine whether something is useful: It

matters little that something is easy if it's not what it is required. It's also no good if the system can

hypothetically do what we want, but we can't make it happen because the user interface is too

difficult. To study a design's utility, we can use the same user research methods that improve

usability.

Definition: Utility = whether it provides the features we need.

• Definition: Usability = how easy & pleasant these features are to use.

• Definition: Useful = usability + utility.

On the Web, usability is a necessary condition for survival. If a website is difficult to use,

people leave. If the homepage fails to clearly state what a company offers and what users can do on

the site, people leave. If users get lost on a website, they leave. If a website's information is hard to

read or doesn't answer users' key questions, they leave. Note a pattern here? There's no such thing as

a user reading a website manual or otherwise spending much time trying to figure out an interface.

There are plenty of other websites available; leaving is the first line of defence when users encounter

a difficulty (Ref.07).

The first law of e-commerce is that if users cannot find the product, they cannot buy it either.

For intranets, usability is a matter of employee productivity.

Current best practices call for spending about 10% of a design project's budget on usability.

On average, this will be more than double a website's desired quality metrics and slightly less than

double an intranet's quality metrics. For software and physical products, the improvements are

typically smaller, but still substantial — when we emphasize usability in the design process.

For internal design projects, think of doubling usability as cutting training budgets in half and

doubling the number of transactions employees perform per hour. For external designs, think of

doubling sales, doubling the number of registered users or customer leads, or doubling whatever

other desired goal motivated the design project. (Ref.05).

7.1 Improvising the Usability There are many methods for studying usability, but the most basic and useful is user testing,

which has 3 components:

• Get hold of some representative users, such as customers for an e-commerce site or

employees for an intranet (in the latter case, they should work outside the department).

• Ask the users to perform representative tasks with the design.

• Observe what the users do, where they succeed, and where they have difficulties with the

user interface. Shut up and let the users do the talking.

It's important to test users individually and let them solve any problems on their own. If it is required

to help them or direct their attention to any particular part of the screen, then the test results are

contaminated. To identify a design's most important usability problems, testing 5 users is typically

enough. Rather than run a big, expensive study, it's a better use of resources to run many small tests

and revise the design between each one so that we can fix the usability flaws as we identify

them. Iterative design is the best way to increase the quality of user experience. The more versions

and interface ideas we test with users, the better. User testing is different from focus groups, which

are a poor way of evaluating design usability. Focu(Ref.04).s groups have a place in market research,

but to evaluate interaction designs we must closely observe individual users as they perform tasks

with the user interface. Listening to what people say is misleading: we have to watch what they

actually do.



280

7.2 Evaluating the Usability Stability plays a role in each stage of the design process. The resulting need for multiple

studies is one reason we suggest making individual studies fast and cheap. Here are t(Ref.02).he

main steps:

1.Before starting the new design, test the old design to identify the good parts that should keep

or emphasize, and the bad parts that give users trouble.

2.Unless we work on an intranet, test our competitors' designs to get cheap data on a range of

alternative interfaces that have similar features to our own.

3.Conduct a field study to see how users behave in their natural habitat.

4.Make paper prototypes of one or more new design ideas and test them. The less time we

invest in these design ideas the better, because we need to change them all based on the test

results.

5.Refine the design ideas that test best through multiple iterations, gradually moving from low-

fidelity prototyping to high-fidelity representations that run on the computer. Test each

iteration.

6.Inspect the design relative to established usability guidelines whether from earlier self studies

or published research.

7.Once we decide on and implement the final design, test it again. Subtle usability problems

always creep in during implementation.

Fig.3: Usability Evaluation Star Model.

Don't defer user testing until we have a fully implemented design. If so, it will be impossible

to fix the vast majority of the critical usability problems that the test uncovers. Many of these

problems are likely to be structural, and fixing them would require major re-architecting. The only

way to a high-quality user experience is to start user testing early in the design process and to keep

testing every step of the way(Ref.09).There exist multiple methods of evaluating usability depending

on available resources (time facilities and labor), evaluator experience, ability and preference, and

the stage of development of the tool under review. In broad terms it is worth making the following

distinctions between evaluation methods:



281

1. User-based: where a sample of the intended user tries to use the application.

2. Expert-based: where an HCI or usability expert makes an assessment of the application

3. Model-based: where an HCI expert employs formal methods to predict one or more criteria

of user performance

Finally, there are good reasons for thinking that the best approach to evaluating usability is to

combine methods e.g., using the expert-based approach to identify problems and inform the design

of a user-based test scenario, since the overlap between the outputs of these methods is only partial,

and a user-based test normally cannot cover as much of the interface as an expert-based method.

Obviously, where usability evaluation occurs throughout the design process, the deployment of

various methods at different stages is both useful and likely to lead to greater usability in the final

product (Ref.10).

7.3 Interaction Cost and Usability: The interaction cost is the sum of efforts mental and physical efforts that the users must

deploy in interacting with a site in order to reach their goals. Ideally, we’d like users to go to a site

and find the answer they’re looking for right there, in front of their eyes. That would mean zero

interaction cost and is the holy grail of usability as a field. Unfortunately, zero interaction cost is

rarely attainable, since most sites and apps offer many things that users may want to do. Most of the

time, users have to look around, read, possibly scroll, find a promising link, click on it, wait for the

page to load, and then repeat the process all over. Someti (Ref.07).mes a new window may pop up on

top of the existing one, and in that case users have to switch attention to the new window and

perhaps also look back to the old one to integrate information in both windows. In other situations,

users may need to remember information on one page and apply it on a different one. All these

actions require cognitive effort and make up the interaction cost.

Usable sites minimize the interaction cost required to attain a variety of user goals. That is, they

minimize:

• reading

• scrolling

• looking around in order to find relevant information

• comprehending information presented

• clicking or touching (without making mistakes)

• typing

• page loads and waiting times

• attention switches

• Memory load – the information that users must remember in order to complete their task.

These user actions contribute differently to the total interaction cost. Their relative

importance may depend on the user – for example, dyslexic users may have a harder time reading

than clicking around, whereas users with motor impairments may find clicking more difficult. They

also depend on the device — a page load on a desktop connected to a high-speed network may be

insignificant, but a page load on a mobile device may take forever if the cellular coverage is slow.

Many usability guidelines address the question of minimizing the different components of the

interaction cost. For instance, the rules of writing for the web lower the cost of reading by

recommending bullet points and short, to-the-point sentences and paragraphs (Ref.06).

Marketing and branding usually have the job of increasing the user motivation and expected

benefits for engaging with a particular site or brand; usability deals with lowering the interaction

cost. Both methods are ultimately addressing the issue of increasing the expected utility of using a

site or a piece of software.



282

Reason for emphasizing Interaction Cost Interaction cost is a direct measure of usability. In fact, the concept was introduced back in

the early days of Human-Computer Interaction to evaluate the us (Ref.13).ability of a software

system. All usability heuristics minimize the interaction cost for the user.

A quick assessment of the interaction cost of a design can save a lot of money on the long

run, as it can give us a good measure of how difficult the interface is going to be for the user. It can

also serve as a comparison tool between design alternatives: usually, the one that minimizes the

interaction cost has better chances of success.

VIII. CONCLUSION

"Human-computer interaction is a discipline concerned with the design, evaluation and

implementation of interactive computing systems for human use and with the study of major

phenomena. Large-scale software development is a collaborative activity that requires diverse

expertise and substantial human resources. However, as a software project increases in size, it is

often difficult or impractical to concentrate all the necessary human resources in one location. As

Distributed Software Development (DSD) is a highly collaborative activity hence, Developers work

with people on their own team, and teams work with one another to create large-scale software

products. Within teams, development is split among people of differing roles such as development,

testing and requirements, and is governed by a development life cycle.

A HCI framework is proposed in this paper which will be a flexible way of understanding

and communicating the work of HCI practitioners in different contexts. This is not to come up with

another prescriptive a universal HCI design process model, but to articulate the typical HCI activities

within which several methods and deliverables can be assimilated. Not all activities or methods may

be essential in each instance of the process. This framework is rather more suitable to address the

GAPs in the field of conducting distributed software development projects. Usability is a quality

attribute that assesses how easy user interfaces are to use can be assessed w.r.t. User-based, Expert-

based and Model-based criterion where HCI plays important role under distributed software

environment.

REFERENCE

1. Joshi Anirudha, Sarda NL and Tripathi Sanjay Measuring Effectiveness of HCI Integration in

Software Development Processes,

2. Journal of Software Systems, 2010.

3. Nielsen J Agile Development Projects and Usability, November 17, 2008, Accessed March 7,

2009,

4. Joshi Anirudha HCI + SE Integration – Case Studies from Offshore Development Projects,

Workshop on increasing the impact of usability work in software development, ACM CHI,

2007.

5. Lifecycles, in Human Centred Software Engineering, Seffah A, Gulliksen J, and Desmarais

M (eds.), Springer, 2005.

6. Pressman R Software Engineering – a Practitioner’s Approach (6th Edition), McGraw Hill,

2005.

7. Shneiderman B Designing the User Interface: Strategies for Effective Human-Computer

Interaction (4th Edition), Addison Wesley, 2004.

8. Book: Harrison, Andrew, Paul Wheeler, and Carolyn Whitehead. The distributed workplace

sustainable work environments. London: Spon Press, 2004.



283

9. Hinds, P. J., & Bailey, D. E. (2003). Out of sight, out of sync: Understanding conflict in

distributed teams. Organization Science, 14(6), 615-632.

10. Royce W Managing the Development of Large Software Systems, IEEE WESCON, TRW,

1970.

11. Nelson E Extreme Programming vs. Interaction Design, 2002, Accessed August 8, 2009,

http://web.archive.org/web/20070313205440/http://www.fawcette.com/interviews/beck_coop

er/. http://www.useit.com/alertbox/agile-methods.html.

12. Nielsen J Usability Engineering, Morgan Kaufmann, 1993.

13. Olson, G. M. & Olson, J. S. (2000). Distance matters. Human-Computer Interaction, 15(2-3),

139-178.

14. Maznevski, M., & Chudoba, C. (2000). Bridging space over time: Global virtual team

dynamics and effectiveness. Organization Science, 11(5), 473-492.

15. Krauss, R. M. & Fussell, S. R. (1990). Mutual knowledge and communicative effectiveness.

In J. Galegher & R. E. Kraut, et al. (Eds.), Intellectual teamwork: Social and technological

foundations of cooperative work (pp. 111–145). Hillsdale, NJ, England: Lawrence Erlbaum

Associates

16. Clark, Herbert H. & Brennan, Susan E. (1991). Grounding in communication. In L. B.

Resnick, R. M. Levine, & S. D. Teasley (Eds.). Perspectives on socially shared cognition.

(pp. 127–149). Washington, DC: American Psychological Association.

17. Tanmaya Kumar Das, Dillip Kumar Mahapatra and Gopakrishna Pradhan, “An Integrated

Framework for Interoperable and Service Oriented Management of Large Scale Software”,

International Journal of Computer Engineering & Technology (IJCET), Volume 3, Issue 3,

2012, pp. 459 - 483, ISSN Print: 0976 – 6367, ISSN Online: 0976 – 6375.

18. Dillip Kumar Mahapatra, Tanmaya Kumar Das and Gopakrishna Pradhan, “Guidelines for

Managing Distributed Software Project Under Deployment”, International Journal of

Computer Engineering & Technology (IJCET), Volume 4, Issue 1, 2013, pp. 34 - 45,

ISSN Print: 0976 – 6367, ISSN Online: 0976 – 6375.

19. Dillip Kumar Mahapatra and Gopa Krishna Pradhan, “Selection Criterion and

Implementation of Case Tools in Gap Analysis Towards Distributed Software Development”,

International Journal of Computer Engineering & Technology (IJCET), Volume 4, Issue 3,

2013, pp. 389 - 409, ISSN Print: 0976 – 6367, ISSN Online: 0976 – 6375.

20. Dillip Kumar Mahapatra and Tanmaya Kumar Das, “Towards Preventing Software from

Becoming Legacy: A Road Map”, International Journal of Computer Engineering &

Technology (IJCET), Volume 4, Issue 4, 2013, pp. 170 - 184, ISSN Print: 0976 – 6367,

ISSN Online: 0976 – 6375.

50120130406031

Technology

Transcript of 50120130406031