Issue
Article
Vol.29 No.1, January 1997
Article
Issue
Issue |
Article |
Vol.29 No.1, January 1997 |
Article |
Issue |
This paper explores the methodologies for the development of interactive systems proposed by software engineers and human-computer interaction specialists.This paper calls for better methodologies that highlight and value the important contributions of both software engineering and HCI (human-computer interaction) designers.
Introduction and Definitions
In this paper methodologies proposed by software engineers and human-computer interaction specialists are compared. Since in many projects the individuals from these two disciplines must work together to produce a product, methodologies should reveal the relevant points of contact between the disciplines. Methodologies produced by the two disciplines vary greatly in their effectiveness in providing direction for combining methods (or techniques) from both disciplines. Some methodologies attempt to combine the methods from both disciplines into a coherent framework for product development, however most do not.
This survey of methodologies also revealed major differences in the type of methods that were used in each discipline and the value each discipline placed on methodologies. A longer version of this paper [18] is available as a tech report.
A methodology in this context is a description of the process required for the development of a software system. Methodologies vary in breadth. They can be very broad, identifying the major steps involved from the conception of a software system to the final use of that system, or they can be more narrow. Methodologies also vary greatly in their depth. The amount of detail they provide when describing the design process varies considerably.
Each step in a methodology identifies a major task to be performed by the designer. Some methodologies advocate a specific approach to implementing a step such as: a data oriented approach, a functional approach or a object-oriented approach. Approaches can be clarified by methods. A method is a description of a technique for implementing a step. For instance, Booch describes a method for analysis in [1] that advocates an object-oriented approach.
Note that in this paper methods are contained within methodologies. A method is a technique for accomplishing a step in a methodology. A methodology is an integrated collection of methods. Methods can also stand on their own and not be part of a methodology.
In this part of the paper I review common software engineering methodologies a typical computer scientists might encounter in tertiary education courses. While some texts advocate a particular methodology, others present a variety of approaches. Some approaches ignore the role of the HCI specialists, others enhance a SE methodology with HCI techniques.
This well known methodology's major steps are: engineer, analyse, design, code, test and maintain. This methodology is presented in Pressman[3] and many other software engineering textbooks. None of its steps relate to the development of the interface specifically.
With this methodology a sequence of prototypes is built until "a good understanding of the software requirements" is developed. Presented in Pressman this methodology is advocated when "the form that human-machine interaction should take is not clear". It recognizes that iterations of design steps are a normal part of the process. Via a prototyping approach, software engineers can develop a clearer idea of the product they are proposing to develop. When the HCI specialist is the one developing the prototypes, he or she becomes a contributor to only the requirements phase of the developmental cycle according to this methodology.
This methodology, developed by Boehm[5], and also presented in Pressman, presents the software engineering process in a business context where managers make decisions about the feasibility of a project, the resources allocated to it and the risks associated with development. At each cycle of the spiral, a fresh decision is made as to the purpose and value in doing another cycle. The four steps are: planning, risk analysis, engineering and customer evaluation. If the user interface development is important to the success of the product, an HCI methodology is used in the next cycle.
Pfleeger [6] presents a methodology much like the waterfall methodology but with an emphasis on testing. All of the steps are interconnected allowing for development through prototyping. No steps address the development of the user interface specifically.
Downton [7], in his book for systems designers with technical backgrounds, proposes a methodology that enhances a typical waterfall methodology with HCI awareness. Here software engineers use simple cognitive or perceptual models, dialogue guidelines and informal evaluation techniques to replace an ad hoc or intuitive method for designing user interfaces.
Downton proposes a second methodology where the waterfall methodology is related to the methods of the HCI specialist. Task analysis, user modeling, formal interface specifications, dialogue design tools, formal evaluation techniques and standards for documents are used to produce useful interactive software. It is clear that there are vastly different opinions about the role of human-computer interaction specialists in software engineering texts. In [6] Pfleeger states that there is no special process for user interface design. In [3], Pressman presents many methodologies and gives more consideration to the development of the interface. Pressman suggests mixing paradigms at different points in the software engineering process depending on need. In Pressman, HCI is seen as useful for the development of the software requirements. Downton in [7] addresses the issue of user interface design integrated with the software engineering cycle most thoroughly. In his methodology, methods from HCI to develop the user interface, are combined with many of the steps of the classic software engineering life cycle.
There is agreement within the HCI community that an iterative design technique is required for the development of user interfaces. The waterfall approach will not work for the development of user interfaces since a user interface cannot be specified without repeated testing with users. An experimental approach is necessary because there is not a sufficiently firm theory of human cognition and behavior from which a theoretically based interface design could be constructed.
In general the HCI community prescribes developing a prototype of an interface that is evaluated and then rebuilt and reassessed iteratively until the final interface has been designed. The user is seen as being integral to this process. Beyond this basic agreement to an approach, many issues are highly debated such as: the methods that are most effective or economical, the point at which these methods should be applied or the value of prescribing a methodology at all.
In this part of the paper I look at three major design approaches within the HCI community: user centered design, cognitive modeling and participatory design. Of interest here is the emphasis on methodology within each of these approaches.
Wasserman et al. in [8] and [9] advocate the use of a rapid prototyping methodology. From an architectural point of view, the USE methodology makes a distinction between developing the user interface and developing the functional aspects of an application. This encourages developing rapid prototypes of the interface that can be iteratively assessed until a suitable interface has been designed. In this methodology the user interface development process envelops the traditional software engineering process.
In [10] Nielsen outlines 11 steps to a practical and economical process for user interface design (See Figure 1). This methodology was developed in industry and is fairly well known. Nielsen's methodology is practical above all else. There is a major emphasis on knowing the user and the tasks the user must perform as well as having users test prototypes of a product under development.
Figure 1: Usability Engineering
Many of the methods in usability engineering are derived from other disciplines such as Psychology or Marketing. They tend to be a combination of qualitative and quantitative techniques. In general they are much less formal than the methods of software engineers. Specification of the user's characteristics is an example of a step that combines qualitative and quantitative approaches. Testing methods are usually more quantitative, frequently done in a lab situation, and the methods used are borrowed from psychology lab tests on humans.
The relationship of the interface designer to the software engineer is not clarified in Nielsen's methodology. This is a methodology clearly focused on the development of the interface of a product and probably designed with human-computer interaction specialists in mind.
The emphasis of cognitive modeling is to understand and model an activity as it is understood by the user. Cognitive modeling experts assert that if you can get this model right then you can use it to create a design that will be intuitive to the user. Cognitive modeling advocates are interested in why users behave as they do or why one design is better than another. This approach is not focused on methods and does not advocate any particular methodology although there are some methods such as GOMS (Goals, Operators, Methods and Selection Rules). See [11] for a detailed description of GOMS.
In [12] Carroll critiques methodologies. "We now see," he asserts, "how problem stages overlap, that there is no simple solution, that other non-design factors influence design and that the design team is multi-disciplinary." He states that a major shift has occurred from developing methodology to understanding designing rationale. Carroll proposes a scenario-based method to aid design. Recent descriptions of this method include psychological theory embedded in the scenarios to justify the design. With the psychological theory added, design choices can be articulated and design rationale can be better understood.
In general, Participatory Design (PD) advocates do not see methodology as central to producing a good product, however, PD methods do exist. Methods are seen more as a resource for designers to use as they deem appropriate and are not gathered into a coherent framework. Although Muller [14] claims that PD techniques are applicable through the entire software development cycle, Carmel [15] claims these techniques are best for requirements definition phase, noting that PD techniques appear to enhance creativity.
For PD designers, the more important issue is communication between users and designers. This is especially important in participatory design because the user is a peer in the design process. PD advocates work to describe the types of communication desired and to develop methods that can help users and designers move closer to a better design. The focus in PD is on the communication that occurs between designers and users rather than on what particular steps to take when designing. In a review of major PD research projects, Clements reports that "several [PD] researchers noted that it was not the particular methods and techniques that were decisive [in system development], but a strong political focus on participation, communication and learning." [13]
Kensing in [16] believes that techniques [or methodologies] are not the answer. He claims that a more important focus is to develop models that enhance communication between users and developers. He classifies PD and software engineering techniques into 6 different communication enhancing categories (See Figure 2). Each box in this diagram represents a type of communication that needs to occur in order for a successful system to be developed. Techniques that reveal knowledge in all 6 categories are required in design. Kensing notes that software engineering modeling techniques facilitate communication in only 2 of 6 required areas (categories 2 and 5). Prototyping, a more promising technique, covers 3 of Kensing's 6 required categories of communication between user and designer (categories 3, 5 and 6 in the table).
| User's present work | New system | Technological Options |
|---|---|---|
| Abstract Knowledge | Relevant structures on user's present work (2) | Visions and design proposals (5) | Overview of Technological Options (4) |
| Concrete Experience | Concrete Experience with user's present work (1) | Concrete Experience with the new System (6) | Concrete Experience with Technological Options (3) |
Figure 2: Kensing's Communication Enhancing Strategies
Projects that require a user interface are usually more difficult to build. The development of user interfaces stresses the software engineering methodology and requires extra resources and expertise. In order for design teams to meet the challenge of developing software products with substantial user interfaces, an increased awareness of a development process that integrates user interface development and functional development is required.
This review shows that there is a basic fundamental difference between the approaches taken by software engineers and human-computer interaction specialists. Human-computer interface specialists are user-centered and software engineers are system-centered.
Software engineering methodologies are good at modeling certain aspects of the problem domain. Formal methods have been developed to represent data, architectural, and procedural aspects of a software system. Software engineering approaches deal with managerial and financial issues well. Software engineering methodologies are useful for specifying and building the functional aspects of a software system.
Human-computer interfaces emphasize developing a deep understanding of user characteristics and a clear awareness of the tasks a user must perform. HCI specialists test design ideas on real users and use formal evaluation techniques to replace intuition in guiding design. This constant reality check improves the final product.
The contributions that HCI specialists can make to the development of a product are not well known at present, the fault lying at least in part with software engineering textbooks that ignore the contributions of the HCI community to the design process.
Equally inadequate are HCI methodologies that do not clarify the role of the SE process relative to the HCI process. Neilsen's usability engineering approach is typical of HCI methodologies that leave this relationship ambiguous.
There are difficulties in attempting to combine methodologies however. Software engineers and human-computer interaction specialists do not agree on the value of methodologies per se. In line with a systems viewpoint, software engineers, who tend to be analytical by nature, have a preference for specifying a work strategy or methodology. HCI specialists, perhaps because of a need for flexibility in their work practice or because of a lack of maturity in their discipline, resist defining a process. No doubt this very different approach to doing work can cause difficulties when the two professional groups interact.
Another difficulty in combining methodologies of software engineers and HCI communities is the differing approach to methods employed by the communities. Software engineers tend to prefer formal methods and devalue informal methods. Formal methods are part of the HCI process but many informal methods are used and valued.
Methodologies are an idealized articulation of a process. In practice they are seldom perfectly realized. This does not detract from their value however. Methodologies convey the importance of various stages of a process to a community. They can be an aid to structuring work and can help to assess progress towards a final goal of a design team. They can identify key players in the development of a software product and define the boundaries of a task to be accomplished by a portion of a design team. They can help a team work together by clarifying the tasks of members of a team and by giving an overall picture of a process. Current methodologies are inadequate to this task.
[1] Booch, Grady. 1994. Object-Oriented Analysis and Design with Applications. The Benjamin/Cummings Publishing Company, Inc.
[2] Booth, Paul. 1989. An Introduction to Human-Computer Interaction. Lawrence Erlbaum Associates.
[3] Pressman, Roger. 1992. Software Engineering A practitioner's Approach. McGraw-Hill Inc.
[4] Royce, Winston. 1970. Managing the Development of Large Software Systems: Concepts and Techniques. WESCON technical papers, 14.
[5] Boehm, Barry. 1987 (Sept). A Spiral Model of Software Development and Enhancement. Computer, pages 43-57.
[6] Pfleeger, Shari. 1987. Software Engineering. Macmillan Publishing Co.
[7] Downton, Andy et al. 1991. Engineering the Human-Computer Interface. McGraw-Hill Book Company Europe.
[8] Wasserman, A.I. et al. 1985. Developing interactive information systems with the User Software Engineering methodology. IEEE Transactions on Software Engineering, 12(2).
[9] Wasserman et al. 1987. Developing Interactive Information Systems with the User Software Engineering Methodology, from Human-Computer Interaction., ed. Baecker, Ronald and Buxton, William Morgan Kaufmann Publishers, Inc.
[10] Nielsen, Jakob. 1993. Usability Engineering. AP Professional.
[11] Card, Stuart and Moran, Thomas and Newell, Allen. 1983. The Psychology of Human-Computer Interaction. Lawrence Erlbaum Associates.
[12] Carroll, John and Moran, Thomas. 1991. Introduction to This Special Issue on Design Rationale. Human-Computer Interaction, 6, pages 197-200.
[13] Clement, Andrew and Van den Besselaar, Peter. 1993 (June). A Retrospective Look at PD Projects. Communications of ACM, 36(4).
[14] Muller, Michael and Wildman, Daniel and White, Ellen. 1993 (June). Taxonomy of PD Practices: A Brief Practitioner's Guide. Communications of ACM, 36(4).
[15] Carmel, Erran and Whitaker, Randall and George, Joey. 1993 (June). PD and Joint Application Design: A Transatlantic Comparison. Communications of ACM, 36(4).
[16] Kensing, Finn and Munk-Madsen, Andreas. 1993 (June). PD: Structure in the Toolbox. Communications of ACM, 36(4).
[17] Landay, James and Myers, Brad. 1994. Interactive Sketching for the Early Stages of User Interface Design. Technical report. Carnegie Mellon University.
[18] Brown, Judy. 1996, Technical Report CS-TR-96/1, Victoria University of Wellington.
Judy Brown, Department of Computing Science Victoria University, Wellington, New Zealand Judy.Brown@comp.vuw.ac.nz
Issue |
Article |
Vol.29 No.1, January 1997 |
Article |
Issue |