HCI IN THE SOFTWARE PROCESS

GROUP MEMBERS• SAAD AKBAR• SALMAN MALIK• FAIZAN KHAN• SYED MUTTAHAR ALI• H.M OWAIS• ALI JAVAID• ANIL AMJAD

CHAPTER : 6

OVERVIEW

Software engineering along with HCI provides us a effectiveness and interactive system design.

Usability engineering promotes the product in terms of its usability.

Software engineering and the design process for interactive systems

Usability engineering

Iterative design and prototyping

Design rationale

INTRODUCTION

concerned with the usable interactive systems to reached successful paradigms. The design goal is to provide reliable techniques for the successful and usable interactive systems. Within computer science there is already a large sub discipline that addresses the management and

technical issues of the development of software systems – called software engineering. When HCI affecting the usability of interactive systems the other relevant within all the activities of the

software life cycle are disturbed. Some famous techniques or models of software engineering are imposed in HCI to get a better system.

THE SOFTWARE LIFE CYCLE

In the development of a software product, we consider two main parties: The customer who requires the use of the product and the designer who must provide the product. Typically, the customer and the designer are groups of people and some people can be both customer and

designer. It is often important to distinguish between the customer who is the client of the designing company and

the customer. who is the eventual user of the system. These two roles of customer can be played by different people. The group of people who negotiate the features of the intended system with the designer may never be

actual users of the system. This is often particularly true of web applications. In this chapter, we will use the term ‘customer’ to refer

to the group of people who interact with the design team and we will refer to those who will interact with the designed system as the user or end-user.

FIGURE 6.2.1 THE ACTIVITIES IN THE WATERFALL MODEL OF THE SOFTWARE LIFE CYCLE

6.2.1 ACTIVITIES IN THE LIFE CYCLE

Requirements specification In requirements specification, the designer and customer try to capture a description of what the eventual

system will be expected to provide.

Architectural design An architectural design performs this decomposition. It is not only concerned with the functional

decomposition of the system, determining which components provide which services.

Detailed design Detailed design of the system is the last design activity before implementation begins. The hardest design

problems must be addressed by the detailed design or the design is not complete. The detailed design is still an abstraction as compared to source code

Coding and unit testing

After coding, the component can be tested to verify that it performs correctly, according to some test criteria that were determined in earlier activities.

Integration and testing It may also be necessary to certify the final system according to requirements imposed by some outside

authority, such as an aircraft certification board.

Maintenance After product release, all work on the system is considered under the category of maintenance Maintenance

involves the correction of errors in the system which are discovered after release and the revision of the system services to satisfy requirements that were not realized during previous development.

CONT.'S

6.2.2 VALIDATION AND VERIFICATION

Verification designing the product right

 Validation designing the right product

 

The formality gap validation will always rely to some extent on subjective means of proof

Management and contractual issues design in commercial and legal context. Real-world

requirementsand constraints The formality gap

FIGURE 6.2.2

FEEDBACK FROM MAINTENANCE ACTIVITY TO OTHER DESIGN ACTIVITIES

6.2.3 MANAGEMENT AND CONTRACTUAL ISSUES

• In a technical discussion, management issues of design, such as time constraints and economic forces, are not as important.

• The different activities of the life cycle are logically related to each other

• In management, a much wider perspective must be adopted which takes into account the marketability of a system

• its training needs, the availability of skilled personnel or possible subcontractors, an other topics outside the activities for the development of the isolated system

EXAMPLE

take the development of a new aircraft on which there will be many software subsystems. in the case of commercial aircraft in terms of passenger capacity and flight range analysis, both the specification

of the aircraft and determination of training needs Some of these systems will be software systems, such as the flight management system or the training simulator,

and these will be designed according to the life cycle described earlier. This will be the job of manager to consult this things to user companies

CONT.'S

In managing the development process, the temporal relationship between the various activities is more important, as are the intermediate deliverables which represent the technical content

So that designer must demonstrate to the customer that progress is being made. the managerial perspective is described in phases Called Documentations the requirements phase will take any marketing or conceptual development information a requirements specification that must be agreed upon between customer and designer. from the management perspective. the customer and the designer must sign off on various documents indicating

their satisfaction with progress to date.

CONT.'S

contractual obligation has negative implications on the design process as well. It is very difficult in the design of an interactive system to determine a improvements to impose on the system to

maximize its usability. because of some requirements being fixed too early

6.2.4 INTERACTIVE SYSTEMS AND THE SOFTWARE LIFE CYCLE

• in the 1960s and 1970s the majority of large systems produced were concerned with data-processing applications in business

• With the advent of personal computing in the late 1970s and its huge commercial success and acceptance, most modern systems developed today are much more interactive

• The actual design process is iterative, work in one design activity affecting work in any other activity both before or after it in the life cycle.

CONT.'S

A classic survey in 1978 by Sutton and Sprague at IBM resulted in an estimate that 50% of the designer’s time was spent on designing code for the user interface

Our models of the psychology and sociology are incomplete and do not allow us to predict how to design for maximum usability ,There is much research on models of human users that allow prediction of their performance

Figure below 6.2.4 how discovery in later activities can be reflected in iterations back to earlier stages.

FIGURE 6.2.4

CONT.'S

in order to test certain usability properties of their designs, designers must observe how actual users interact with the developed product and measure their performance.

In order for the results of those observations to be worthwhile, the experiments must be as close to a real interaction situation as possible.

One problem with this interactive system design is that the tasks a user will perform are often only known by the user after he is familiar with the system on which he performs them.

A final point about the traditional software life cycle is that it does not promote the use of concepts and techniques that support the user’s perspective of the interactive system

6.3 USABILITY ENGINEERING

The ultimate test of usability based on measurement of user experience

Usability engineering demands that specific usability measures be made explicit as requirements

Usability specification usability attribute/principle measuring concept measuring method now level/ worst case/ planned level/ best case

Problems usability specification requires level of detail that may not be possible early in design satisfying a usability specification does not necessarily satisfy usability

PART OF A USABILITY SPECIFICATION FOR A VCR

Attribute: Backward recoverability

Measuring concept: Undo an erroneous programming sequence

Measuring method: Number of explicit user actionsto undo current program

Now level: No current product allows such an undo Worst case: As many actions as it takes to

program-in mistake Planned level: A maximum of two explicit user actions Best case: One explicit cancel action

ISO USABILITY STANDARD 9241

adopts traditional usability categories:

effectiveness can you achieve what you want to?

efficiency can you do it without wasting effort?

satisfaction do you enjoy the process?

SOME METRICS FROM ISO 9241 Usability Effectiveness Efficiency Satisfaction

objective measures measures measures

Suitability Percentage of Time to Rating scale for the task goals achieved complete a task for satisfaction

Appropriate for Number of power Relative efficiency Rating scale fortrained users features used compared with satisfaction with

an expert user power features

Learnability Percentage of Time to learn Rating scale forfunctions learned criterion ease of learning

Error tolerance Percentage of Time spent on Rating scale for errors corrected correcting errors error handling successfully

6.4 ITERATIVE DESIGN AND PROTOTYPING

The only way to be sure about some features of the potential design is to build them and test them out on real users

The design can then be modified to correct any false assumptions that were revealed in the testing This is the essence of iterative design, a purposeful design process which tries to overcome the inherent problems On the technical side, iterative design is described by the use of prototypes

THROW-AWAY

The prototype is built and tested. The design knowledge gained from this exercise is used to build the final product Figure shows the procedure in using throw-away prototypes to arrive at a final requirements

specification

INCREMENTAL

The incremental build model is a method of software development where the prototype is designed, implemented and tested incrementally (a little more is added each time) until the product is finished

The product is defined as finished when it satisfies all of its requirements.

EVOLUTIONARY

This prototype is presented to the user. They provide feedback and suggestions for improvements. So at each stage the prototype 'evolves' towards the final system

ON THE MANAGEMENT SIDE THERE ARE SEVERAL POTENTIAL PROBLEMS

Time Building prototypes takes time and, if it is any prototype, it can be time taking Seen as precious time taken away from the real design task Planning Most project managers do not have the experience necessary for adequately planning and costing a design 

Non-functional features Often the most important features of a system will be non-functional ones such as safety and reliability. These features are sacrificed in developing a prototype

Contracts The design process is often governed by contractual agreements between Customer and designer And so an iterative design process will still require documentation which serves as the binding agreement. 

6.4.2 WARNING ABOUT ITERATIVE DESIGN

we have studied about the iterative design process and its benefits. Iterative design is not only beneficial but also very important for good interactive system design. It is important to recognize some of its drawback also. There are two main drawbacks of this design which are discussed ahead.

FIRST PROBLEM

It is the case that design decisions made at the beginning of prototyping are wrong. As we know that iterative design process is a process which is amended after every iteration. But the problem is that if the initial prototype has bad features will not be amended.

SECOND PROBLEM

it is important to understand the reason for the problem and not just detect the symptom. In the clock example, the designers could have noticed that some subjects with a 24-hour time model were having difficulty setting the time. Say they were trying to set the time for 14:45, but they were not being allowed to do that. If the designers did not know the subject’s goals, they might not detect the 24/12 hour discrepancy. They would instead notice that the users were having trouble setting the time and so they might change the buttons used to set the time instead of other possible changes, such as an analog time dial, or displaying AM or PM on the clock dial to make the 12-hour model more obvious, or to change to a 24-hour clock.