HCI in the software process Waterfall Model This is the most common and classic of life cycle models,

also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed in its entirety before the next phase can begin. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project. Unlike what I mentioned in the general model, phases do not overlap in a waterfall model. Waterfall Life Cycle Model

Software Development Model - Waterfall Model Life Cycle The waterfall model in software engineering was originally designed in 1970 by Winston W. Royce. However, the model was not named as 'waterfall' model. In this model there is sequential progression from one phase to another. To elaborate this further, after the first phase is completed, it is considered as a stepping stone to the next phase. The phases in the waterfall - software development model are requirement analysis and project planning, system design and specification, coding and verification, system integration and testing and not to forget deployment and maintenance phase. Here is the waterfall model explained. Requirement Analysis and Project Planning In this first stage of waterfall model diagram, there is a meeting with the customer, to understand the requirements. The first stage, this is said to be the most crucial stage, as any miscommunication and misinterpretation at this stage may give rise to the software, that is being developed. When the requirements have been noted, it is important to make sure the requirements are detailed and accurate and there is no place for any ambiguity. Understanding the requirements and expectations of the

customer properly will ensure, that the end product meets the specification. System Design The requirements, that are gathered in the previous phase are broken down into logical units, so that the software process becomes easy for implementation. This is the stage, when the software requirements along with the hardware requirements for every unit are identified. Then the designs are made accordingly. The interrelation between the various units of the software are identified and the connections are made, using algorithms and diagrams. To sum it up, this is the phase, where the fundamental work for actual programming and implementation is done. System Implementation In this phase the actual development of the software takes place. This phase is also known as coding and verification phase. Based on the algorithms written in the previous phase, software program is written. For every module, software code is written and tested, to check if the correct output is received. System Integration and Testing Now all the modules are integrated, after which the software is tested for correct output. All the bugs, that are made, due to integration are removed. Then software testing is carried out again. They are normally a series of tests, which are run to check the performance of the software, and also to find if any new bugs were introduced into the system, after the previous bugs were fixed. If any more errors do exist, the bugs are fixed only to be retested. The waterfall model in testing is followed, to make the software bug free, as far as possible. System Deployment and Maintenance This makes for the final phase of the waterfall model, where the software is deployed at the clients side, after it has undergone thorough testing. After the deployment of the software, routine maintenance work is carried out. Once the software has been deployed, in case the customer asks for any changes or enhancements, then the entire process is restarted. There are various waterfall model advantages and disadvantages. The biggest advantage of this model is that, the phases are completed one at a time. However, the biggest disadvantage is that it is laborious, when any changes are to be made to the system. To sum up waterfall model life cycle in short, this model requires, that one moves from one phase to another, only after the preceding phase is completed satisfactorily. At the same time, it should not be forgotten, that various waterfall models may include slight or major variations in the process. Advantages

Simple and easy to use. Easy to manage due to the rigidity of the model each phase has specific deliverables and a review process. Phases are processed and completed one at a time. Works well for smaller projects where requirements are very well understood.

Disadvantages

Adjusting scope during the life cycle can kill a project No working software is produced until late during the life cycle.

High amounts of risk and uncertainty. Poor model for complex and object-oriented projects. Poor model for long and ongoing projects. Poor model where requirements are at a moderate to high risk of changing.

Usability Engineering The Software Usability Engineering Process The relevance of usability as a quality factor is continually increasing for software engineering organizations: usability and user acceptance are about to become the ultimate measurement for the quality of todays telematics applications, e-commerce web sites, mobile services and tomorrows proactive assistance technology. Taking these circumstances into account, human-centered design (HCD) methods for developing interactive systems are changing from a last minute add-on to a crucial part of the software engineering lifecycle. It is well accepted both among software practitioners and in the human-computer interaction research community that structured approaches are required to build interactive systems with high usability. On the other hand specific knowledge about exactly how to most efficiently and smoothly integrate HCD methods into established software development processes is still missing (Mayhew, 1999). While approaches such as the usability maturity model (UMM) (Earthy, 1999) provide means to assess an organizations capability to perform HCD processes they lack guidance on how to actually implement process improvement in HCD. It often remains unclear to users of HCD methods if and why certain tools and methods are better suited in a certain development context than others (Welie, 1999). We need strategies and tools that support engineering organizations in evolving and selecting an optimal set of HCD methods for a given development context and perform systematic process improvement in HCD. Little research has been done on integrating methods and tools of HCD in the development process and on gathering knowledge about HCD activities in a form that can capture relationships between specific development contexts, applicable methods and tools and their impact on the engineering process (Henninger, 2000). This article is an elaborated version of the paper presented at the 4 international CADUI2002 Conference, Valenciennes, France (Metzker and Reiterer, 2002). It is organized as follows. In this paper we propose six claims that point out shortcomings of current HCD practice and requirements for improvement. First we take a look at existing HCD process models and existing approaches to capture HCI design knowledge, trying to identify the organizational

obstacles that hamper the establishment of these models and the use of the knowledge in mainstream software development processes. Parts of the claims are based on a survey we have made, which examined how exactly HCD methods are applied in real projects. To address the shortcomings and to meet the requirements described in our claims we present next an evidence-based usability engineering approach to the improvement of HCD processes. We show a first prototype of a computer-aided usability engineering environment called ProUSE, that we developed to support our evidence-based usability engineering approach. We discuss the deployment of ProUSE in an industrial setting and present results of an evaluation, that has been undertaken to get initial feedback on the validity of the underlying the concepts and acceptance of the support tool ProUSE by development teams. A short overview about related work and a discussion of our evidence-based usability engineering approach finishes this article. The role of engineering is to apply scientific knowledge to produce working systems that are economically devised and fulfill specific needs. Our software usability group has adapted engineering techniques to the design of user interfaces. To understand user needs, engineers must observe people while they are actually using computer systems and collect data from them on system usability. Observation and data collection can be approached in the following ways:

Visiting people while they use computers in the workplace Inviting people to test prototypes or participate in usability evaluations at the engineering site Soliciting feedback on early versions of systems under development Providing users with instrumented systems that record usage statistics

Our group uses these methods to gather information directly from users, not through second hand reports. We use these methods to study the usability of current versions of our products, competitive systems, prototypes of new systems, and manual paper-based systems. Our software usability engineering process evolves as we use it in product development. As of 1987, the process consists of three principal activities:

Visiting customers to understand their needs. By understanding a customers current experience with a system, we gain insight into our opportunities to engineer new and better systems. We collect data on users experiences primarily through contextual interviews, that is, interviews conducted while users perform their work. Developing an operational usability specification for the system. We base the system specification on our understanding of users needs, competitive analysis, and the resources needed to produce the system. This specification is a measurable definition of usability that is shared by all members of the project team. Adopting an evolutionary delivery approach to system development. Developers start by building a small subset of the system and then growing the system throughout the development process. We continue to study users as the system evolves. Evolutionary delivery

is an effective method for coping with changing requirements a fundamental aspect of the development process. USABILITY SPECIFICATIONS Usability is not something warm, fuzzy, but is quantitative Quantitative usability goals against which user interaction design is measured Target levels for usability attributes * Operationally defined metrics for a usable interaction design If you can't measure it, you can't manage it * Management control for usability engineering life cycle * Indication that development process is converging toward a successful interaction design * Establish as early in process as feasible

USABILITY SPECIFICATION DATA Usability specifications based on * Objective, observable user performance * Subjective user opinion and satisfaction - Subjective preferences may reflect users desire to return to your Web site, but flash and trash soon bores and irritates Objective and subjective usability specifications can both be quantitative

USABILITY SPECIFICATION TABLE * Usability attribute what general usability characteristic is to be measured - May need separate usability attributes for each user class Some quantitative usability attributes * Objective - Initial performance - Longitudinal (experienced, steady state) performance - Learnability - Retainability Observed Results ISO 9241 ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of r preparing International Standards is normally carried out through ISO technical committees. Each

member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and nongovernmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization. Draft International Standards adopted by the technical committees are circulated to the member bodies for voting. Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote. International Standard ISO 9241-11 was prepared by Technical Committee ISO!TC 159, Ergonomics, Subcommittee SC 4, Ergonomics of human- system interaction. ISO 9241 consists of the following parts, under the general title Ergonomic requirements for office work with visual display terminals (VDTs): The objective of designing and evaluating visual display terminals for usability is to enable users to achieve goals and meet needs in a particular context of use. ISO 9241-11 explains the benefits of measuring usability in terms of user performance and satisfaction. These are measured by the extent to which the intended goals of use are achieved, the resources that have to be expended to achieve the intended goals, and the extent to which the user finds the use of the product acceptable. ISO 9241-11 emphasizes that visual display terminal usability is dependent on the context of use and that the level of usability achieved will depend on the specific circumstances in which a product is used. The context of use consists of the users, tasks, equipment (hardware, software and materials), and the physical and social environments which may all influence the usability of a product in a work system. Measures of user performance and satisfaction assess the overall work system, and, when a product is the focus of concern, these measures provide information about the usability of that product in the particular context of use provided by the rest of the work system. The effects of changes in other components of the work system, such as the amount of user training, or the improvement of the lighting, can also be measured by user performance and satisfaction. The term usability is sometimes used to refer more narrowly to the attributes of a product which make it easier to use (see Annex D). Requirements and recommendations relating to the attributes of the hardware, software and environment which contribute to visual display terminal usability, and the ergonomic principles underlying them, are provided in other parts of ISO 9241. 1 Scope ISO 9241-11 defines usability and explains how to identify the information which is necessary to take into account when specifying or evaluating usability of a visual display terminal in terms of measures of user performance and satisfaction. Guidance is given on how to describe the context of use of the product (hardware, software or service) and the relevant measures of usability in an explicit way. The guidance is given in the form of general principles and techniques, rather than in the form of requirements to use specific methods. The guidance in ISO 9241-11 can be used in procurement, design, development, evaluation, and communication of information about usability .ISO 9241-11 includes guidance on how the usability of a product can be specified and evaluated. It applies both to products intended for general application and products being acquired for or being developed within a specific organization. ISO 9241-11 also explains how measures of user performance and satisfaction can be used to measure how any component of a work system affects the whole work system in use. The guidance includes procedures for measuring usability but does not detail all the activities to be

undertaken. Specification of detailed user-based methods of measurement is beyond the scope of ISO 9241-11, but further information can be found in Annex B and the bibliography in Annex E. ISO 9241-11 applies to office work with visual display terminals. It can also apply in other situations where a user is interacting with a product to achieve goals. ISO 9241 parts 12 to 17 provide conditional recommendations which are applicable in specific contexts of use. he guidance in this Part of ISO 9241 can be used in conjunction with ISO 9241 Parts 12 to 17 in order to help identify the applicability of individual recommendations. ISO 9241-11 focuses on usability and does not provide comprehensive coverage of all objectives of ergonomic design referred to in ISO 6385. However, design for usability will contribute positively to ergonomic objectives, such as the reduction of possible adverse effects of use on human health, safety and performance. ISO 9241-11 does not cover the processes of system develop ment. Human-centred design processes for interactive systems are described in ISO 13407. Iterative design and prototyping Iterative design: a purposeful design process which tries to overcome the inher-ent problems of incomplete requirement spcication by cycling through severaldesigns, incrementally improving upon the nal product with each pass. Onthe technical side, this is described by the use of prototypes. There are 3 main approaches of prototyping: Throw-away: the knowledge gained from the prototype is used in the naldesign, bu the prototype is discarted (g 6.5). Incremental: the nal product is released as a series of components that have been prototyped seperately (g 6.6). Evolutionary: the prototype is not discarted but serves as a basis for thenext iteration of the design (g 6.7).Prototypes dier according to the amount of functionality and performancethey provide relative to the nal product. The importance lies in its projected realism, since they are tested on real users. Since providing realism in prototypesis costly, there are several problems on the management side: Time: prototyping costs time which is taken away from the real design. Therefore, there are rapid-prototyping techniques. Planning Non-functional features: some of the most important features, as safety and reliability, cannot be tested using a prototype. Contracts: Prototyping cannot form the basis for a legal contract and must be supported with documentation