Read an Excerpt
Chapter 1: The Prototyping Approach to Software Development
From the middle 1980s the topic of software prototyping has received an intensive and widespread attention in the literature, thus resulting in a correspondingly extensive and confusing terminology. In the 1990s, primarily thanks to object-oriented technology, prototyping has evolved from a requirement definition strategy into a mainstream approach to software development.
A prototype is a dynamic model of the software system under construction. From the implementation point of view, a prototype is either a throwaway or the core of an application system. In the first case, the prototype serves specification purposes, in the latter, it is the first delivered version of the final system, which, starting from the prototype, will grow in form and size through design, code, and test cycles.
Prototyping can be useful at various stages of design in order to fulfill many different goals. Conversely, different kinds of prototypes are appropriate for different stages of design. So, several distinct prototypes can be developed during the same project.
In the early stages of system development, prototyping can be used to gain a better understanding of the kind of product required and of the kind of support needed by the users in carrying out their tasks with computer aid. Later in the project, prototyping offers designers and developers an opportunity to try architecture and implementation alternatives. Moreover, prototyping plays an important role in testing out the proposed solutions: users can interactively experiment with application objects, behavior, data structure, or control mechanisms, while viewing familiar data being manipulated by the prototype.
Throughout the software project, a prototype can help to facilitate an effective communication between members of the design team, application domain experts, customers, and users.
The concepts hastily introduced above are delved into in more detail in the next sections of this chapter, which deals generically with the development of software systems, without classifying them into categories such as information systems or knowledge-based systems. The chapter is organized as follows: Section 1.1 deals with the waterfall model of the software life cycle and Section 1.2 introduces the concept of prototyping as an answer to its flaws. Section 1.3 describes two iterative software life cycle models, both including prototyping as a basic step. Iterative life cycles are the foundation of the continuous software development paradigm, which is discussed in Section 1.4, while Section 1.5 focuses on the user-centered paradigm, which is favored by prototyping. Section 1.6 introduces three prototyping approaches, Section 1.7 classifies four different kinds of prototypes, and Section 1.8 relates prototyping approaches to prototypes. Section 1.9 surveys the present main goals of software prototyping, and Section 1.10 investigates the use of prototyping in software evaluation. Section 1.11 stresses the importance and the difficulties of the involvement of end users in prototyping projects, and Section 1.12 highlights some major misconceptions about prototyping. Section 1.13 lists sixteen general rules for performing good prototyping. Section 1.14 highlights some requirements in order for CASE environments and tools to be adopted for prototyping. Finally, Section 1.15 emphasizes the appropriateness of object-oriented programming for prototyping, and Section 1.16 hints at some requirements of object-oriented development environments necessary to support prototyping projects.
1.1. Linear Software Development
In the 1980s, poor understanding of system requirements, and, by extension, the lack of adequate validation of the correctness of requirements, had proven a major cause of system failure and customer dissatisfaction. Statistical data testified that half of all bugs discovered in software projects could be traced to errors in requirements (Tavolato and Vincena, 1984).
An underlying cause of requirement difficulties was the reliance on idealized software life cycle models that fail to take into consideration the fact that requirements of large, complex systems are often not well understood prior to development and evolve over time. The classical model of the software life cycle was the waterfall model (Royce, 1970; Boehm, 1976; Agresti, 1986), according to which software development is organized into sequential phases. Requirements gathering and analysis is carried out first, being followed by the definition of specifications. The next phase is design, which precedes coding and testing. Clearly defined criteria are used in order to assess the completion of each phase: they basically specify that a given document or piece of software must be produced in order to successfully finalize the phase.
The waterfall model helps in project management by providing checkpoints to ensure that the product development can be effectively handled and that it remains on schedule. However, this organization is based on the tacit assumption that it is possible to produce complete and correct requirements and specifications before designing the system and developing any software. Instead, although it is important to specify the desired system behavior as much as possible at the start, it is almost always infeasible for users to accurately describe operational requirements prior to development since the human mind cannot foresee all the ramifications of the behaviors of a dynamic system. Moreover, users, being often unable to comment on technical design documents, approve paper specifications out of frustration with the lengthy specification process and lack of comprehensibility of the resulting product.
Conversely, in spite of the traditional developers' conviction that they know what the users really want, the more substantial the system, the more developers may fail to understand the users' statement of requirements and translate them into software specifications. So, many requirements errors are passed undetected to the later phases of the waterfall life cycle and their correction becomes progressively more and more expensive as it is delayed (Davis, 1990a). In addition, designers may misunderstand requirement specifications, as they are often expressed in natural language, and therefore they are liable to be ambiguous.
1.2. Software Prototyping
Prototyping was initially advocated by the software engineering community as a means for the early exploration and validation of system requirements (Gomaa and Scott, 1981; Rzepka and Daley, 1986) and as an answer to the need to reveal, understand, enforce and check user requirements within the ongoing design. A prototype was meant as a dynamic model that can be tested by developers and real operators so as that requirements can be validated, changed, or refuted. Paper documents representing requirements and design are static and passive, while a prototype is a dynamic visual model of the user requirements, which provides a far more effective basis for dialog between developers and users. The word `model' is intentionally vague: prototypes range from crude non-interactive, to realistic interactive systems that cannot, at a glance, be distinguished from the final product.
Various kinds of prototypes may be developed to elicit different kinds of requirements. Each group of requirements is then demonstrated in the dedicated software prototype, thereby allowing the assessment by users. This form of prototyping is sometimes called requirements animation (Preece et al., 1994).
Broadly speaking, depending on the `material' with which prototypes are built, two categories can be identified: paper-based and computer-based prototypes (Preece et al., 1994)...
