full chapter summary

1. 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

2. 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

3. 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.

4. 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.

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

6. 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

7. 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

8. 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
requirements
and constraints The formality gap

9. FIGURE 6.2.2
FEEDBACK FROM MAINTENANCE ACTIVITY TO OTHER DESIGN ACTIVITIES

10. 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

11. 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

12. 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.

13. 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

14. 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.

15. 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.

16. FIGURE 6.2.4

17. 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

18. 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

19. PART OF A USABILITY SPECIFICATION FOR A VCR
Attribute: Backward recoverability
Measuring concept: Undo an erroneous programming
sequence
Measuring method: Number of explicit user actions
to 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

20. 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?

21. 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 for
trained users features used compared with satisfaction with
an expert user power features
Learnability Percentage of Time to learn Rating scale for
functions learned criterion ease of learning
Error tolerance Percentage of Time spent on Rating scale for
errors corrected correcting errors error handling
successfully

22. 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

23. 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

24. 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.

25. 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

26. 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.

27. 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.

28. 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.

29. 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.