Maestro Development Blog

Larman: Agile and Iterative Development: A Manager's Guide - Google Scholar
Agile and Iterative Development: A Manager's Guide

Link

At the bottom of the Wikipedia entry

Protoyping consists of four steps:

1. Fucntional Selection
2. Construction
3. Evaluation
4. Further use

Functional Selection refers to the choice of funcitons whicyh the prototype should exhibit. The selection should always be based on relevant work tasks which can serve as model cases for demonstration. he range of features offered by is never the same as that of the final product; otherwise they would be identical. The difference between the functional scope of the prototype and the product may be that

• the system functions implemented are offered in their intended final form but only the selected functions are included ("verical prototyping");
• the functions are not implemented in detail as required in the final system; thus, they can be used for demonstration, part of their effect being omitted or simulated ("horizontal prototyping").

Often these two elements are combined in differenct parts of one prototype.

Construction refers to the effort required to make the protottype available. Generally, this effor should be much smaller than that involved in developing the final product. This can be achieved by both appropriate finctioanl seletion and be the use of suitable techniques and tools for prototype construction.
in construction a prototype, the emphasis should be on the intended evaluation, not on regular long term use. this implies that certain quality requirments pertaining to the final product, such as reliability, data security or efficiency, can be disregarded unless they are part of what the prototype is supposed to demonstrate.

Evaluation must be considered to be the decisive step in prototyping since it provides feedback for the further development process. Therefore, the overall project organization must ensure that resources are made available for the evaluation, including all the participation of all relevant groups of prospective users. The evaluation only makes sense after appropriate training. it should be based on a document making explicit the criteria for evaluation and specifiying the work steps to be performedwith the system. It is essential that the context of these work steps in the surrounding organization be taking into account and that attnetion also be paid to aspects of the work which cannot be formalized such as time, place, interuptions, communicaiton with others.

There are several possibilities for the further use of the protoype. Depending on the experiences gained with the prototype and on the available production environmnet, it may merely serve as a learning vehicle and be thrown away afterwards, or it may be used fully or partially as a component of the target system.
Since the prototype is to be used primarily as a learning vehicle, care should be taken to design the prototyping process as a learning process. This involves several aspects:

• Early availability: A prototype should be available very early in software development so as to offer full benefit to all parties concerned: developes, customers and users (hence the term "rapid prototyping").
• Demonstration, evaluation and modification: A prototype should work in such a way that it can be demonstrated to the users. The demonstration should make snese in the context of the users' work processes, i.e. it should involve authentic and nontrivial problems so as to make the evaluation relevant. There should be an easy way of changing the prototype be revising existing or adding new features as needed in the evaluation, so as to allow for modification cycles on the basis of one prototype.
• Teaching and training: After evaluation and modification, a successful prototype may serve as a teaching environment to prepare prospecitve users for their wok with the target system.
• Commitment: It must be kept in mind that if a prototype is demonstrated and there is a discussion ith the prospective users about it's evaluation, the commitment to the targeet system is very strong. Should essential changes of some features of the prototype be made during imiplementation of the final product without the explicit consent of the user, serious problems regarding its acceptance must be expected.

Exactly what kind of commitment is relevant depends on the specific approach to prototyping.

Davis, A.M., Bersoff, H. & Comer, E.R., 1988. A Strategy for Comparing Alternative Software Development Life Cycle Models. IEEE Transactions on Software Engineering, 14(10), 1453-1461.

Incremental development is the process of constructing a partial implementation of a total system and slowly adding increased functionality or performance. This approach reduces the costs incurred before an initial capability is achieved. It also produces an operational system more quickly, and it thus reduces the possibility that the user needs will change during the development process.

When using incremental development, software is deliberately built to satisfy fewer requirements initially, but is constructed in such a way as to facilitate the incorporation of new requirements and thus achieve higher adaptability. This approach has two effects:

1. the initial development time is reduced because of the reduced level of functionality, and
2. the software can be enhanced more easily and for a longer period of time.

Fig. 6 shows how this approach compares to the conventional approach. Note that the initial development time is less than for the conventional approach, that the initial functionality (A) is less than for the conventional approach (B), and that the increased adaptability is indicated by a higher slope of the curve A-C than for the conventional approach (line BD). The stair step aspect of the graph indicates a series of well-defined, planned, discrete builds of the system.

Davis, A.M., Bersoff, H. & Comer, E.R., 1988. A Strategy for Comparing Alternative Software Development Life Cycle Models. IEEE Transactions on Software Engineering, 14(10), 1453-1461.

THE classic waterfall model (see Fig. 1) was defined as early as 1970 by Royce [ 1] and later refined by Boehm [2] in 1976 to help cope with the growing complexity of the software projects being tackled. The use of such a model

• encourages one to specify what the system is supposed to do (i.e., to define the requirements) before building the system (i.e., designing);
• encourages one to plan how components are going to interact (i.e., designing) before building the components (i.e., coding);
• enables project managers to track progress more accurately and to uncover possible slippages early;
• demands that the development process generate a series of documents which can later be utilized to test and maintain the system;
• reduces development and maintenance costs due to all of the above reasons; and
• enables the organization that will develop the system to be more structured and manageable.

Boehm, B.W., 1988. A Spiral Model of Software Development and Enhancement. Computer, 21(5), 61-72.

The stagewise and waterfall models. As early as 1956, experience on large software systems such as the Semi-Automated Ground Environment (SAGE) had led to the recognition of these problems and to the development of a stagewise model’ to address them. This model stipulated that software be developed in successive stages (operational plan, operational specifications, coding specifications, coding, parameter testing, assembly testing, shakedown, system evaluation). The waterfall model,3 illustrated in Figure 1, was a highly influential 1970 refinement of the stagewise model. It provided two primary enhancements to the stagewise model:

1. Recognition of the feedback loops between stages, and a guideline to confine the feedback loops to SUCcessive
   stages to minimize the expensive rework involved in feedback across many stages.
2. An initial incorporation of prototyping in the software life cycle, via a “build it twice” step running in parallel with requirements analysis and design.

The waterfall model’s approach helped eliminate many difficulties previously encountered on software projects. The
waterfall model has become the basis for most software acquisition standards in government and industry. Some of its initial difficulties have been addressed by adding extensions to cover incremental development, parallel developments, program families, accommodation of evolutionary changes, formal software development and verification, and stagewise validation and risk analysis.

However, even with extensive revisions and refinements, the waterfall model’s basic scheme has encountered some more
fundamental difficulties, and these have led to the formulation of alternative process models.

A primary source of difficulty with the waterfall model has been its emphasis on fully elaborated documents as completion criteria for early requirements and design phases. For some classes of software, such as compilers or secure operating systems, this is the most effective way to proceed.

However, it does not work well for many classes of software, particularly interactive end-user applications. Document-driven standards have pushed many projects to write elaborate specifications of poorly understood user interfaces and decisionsupport functions, followed by the design and development of large quantities of unusable code.

These projects are examples of how waterfall-model projects have come to grief by pursuing stages in the wrong
order. Furthermore, in areas supported by fourth-generation languages (spreadsheet or small business applications), it is clearly unnecessary to write elaborate specifications for one’s application before implementing it.