Redirected from Iterative development
Iterative and Incremental development is a one of Extreme programming practices.
The basic idea behind iterative enhancement is to develop a software system incrementally, allowing the developer to take advantage of what was being learned during the development of earlier, incremental, deliverable versions of the system. Learning comes from both the development and use of the system, where possible. Key steps in the process were to start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving sequence of versions until the full system is implemented. At each iteration, design modifications are made along with addition new functional capabilities.
The Procedure itself consists of the Initialization step, the Iteration step, and the Project Control List. The initialization step creates a base version of the system. The goal for this initial implementation is to create a product to which the user can react. It should offer a sampling of the key aspects of the problem and provide an solution that is simple enough to understand and implement easily. To guide the iteration process, a project control list is created that contains a record of all tasks that need to be preformed. It includes such items as new features to be implemented and areas of redesign of the exiting solution. The control list is constantly being revised as a result of the analysis phase.
The iteration step involves the redesign and implementation of a task from project control list, and the analysis of the current version of the system. The goal for the design and implementation of any iteration is to be simple, straightforward, and modular, supporting redesign at that stage or at as a task added to the project control list. The code represents the major source of documentation of the system. The analysis of an iteration is based upon user feedback and the program analysis facilities available. It involves analysis of the structure, modularity, usability, reliability, efficiency, and achievement of goals. The project control list is modified in the of the analysis results.
Guidelines the drive the implementation and analysis include: - Any difficulty in design, coding and testing a modification should signal then need for redesign or re-coding. - Modifications should fit easily into isolated and easy-to-find- modules. If they do not, some redesign is needed. - Modifications to tables should be especially easy to make. If any table modification is not quickly and easily done, redesign is indicated. - Modifications should be come easier to make as the iterations progress. If they are not, there is a basic problem such as a design flaw or a proliferation of ?patches?. - ?Patches? should normally be allowed to exist for only one or two iterations. Patches may be necessary to avoid redesigning during an implementation phase. - The existing implementation should be analyzed frequently to determine how well it measures up to project goals. - Program analysis facilities should be used whenever available to aid in the analysis of partial implementations - User reaction should be solicited and analyzed for indications of deficiencies in the current implementation.
Iterative Enhancement was successfully applied to the development of an extendable family of compilers for a family of programming languages on a variety of hardware architectures. A set of 17 versions of the system was developed at one site generating 17 thousand source lines of high level language (6500 lines of executable code). The system was further developed at two different sites, leading to two different versions of the base language: one version essentially focused on mathematical applications, adding real numbers and various mathematical functions, and the other adding compiler writing capabilities. Each iteration was analyzed from the user?s point of view (the language capabilities were determined in part by the user?s needs) and the developer?s point of view (the compiler design evolved to be more easily modified for characteristics like adding new data types). Measurement such as coupling and modularization were tracked over multiple versions.
Using analysis and measurement as drivers of the enhancement process is one major difference between iterative enhancement and the current agile development methods. It provides support for determining the effectiveness of the processes and the quality of product. It allows one to study, and therefore improve and tailor, the processes for the particular environment. This measurement and analysis activity can be added to existing agile development methods.
One major difference between iterative enhancement and the current agile development methods is the analysis and measurement activities as drivers in the iterative enhancement process. This provides support for determining the effectiveness of the processes and the quality of product. It allows one to study, and therefore improve and tailor, the processes for the particular environment. This measurement and analysis activity can be added to agile development methods.
In fact, the context of multiple iterations provides advantages in the use of measurement. Measures are sometimes difficult to understand in the absolute but the relative changes in measures over the evolution of the system can be very informative as they provide a basis for comparison. For example, a vector of measures, m1, m 2, ... mn, can be defined to characterize various aspects of the product at some point in time, e.g., effort to date, changes, defects, logical, physical, and dynamic attributes, environmental considerations. Thus an observer can tell how product characteristics like size, complexity, coupling, and cohesion are increasing or decreasing over time. One can monitor the relative change of the various aspects of the product or can provide bounds for the measures to signal potential problems and anomalies.
History For the June 2003 IEEE Computer issue dedicated to agile processes (edited by A. Cockburn and L. Williams), Vic Basili and CraigLarman are writing a short 1-2 page history of iterative/incremental lifecycle processes.
1970: Royce, W.W.[?], Managing the Development of Large-Scale Software: Concepts and Techniques[?] Proceedings, Wescon, August 1970 (also reprinted in Proceedings, ICSE9), which includes a "build it twice" prototyping step -- entered by Barry Boehm[?]
1971: Mills, H.[?], [[Top-down programming in large systems]] Debugging Techniques in Large Systems, R. Rustin, ed., Englewood Cliffs, N.J., Prentice-Hall, 1971. (Frederick Brooks mentions this in NoSilverBullet: "Some years ago Harlan Mills proposed that any software system should be grown by incremental development." - entered by Christian Ohman[?]
1973: Mills, H.[?], On the Development of Large, Reliable Programs[?] IEEE Symp. Comp. SW Reliability. Notes: I have heard this paper has relevance to iterative, but havent' read it yet. - CraigLarman
1975: Williams, R.D.[?], Managing the Development of Reliable Software[?] Proceedings, 1975 International Conference on Reliable Software, ACM/IEEE, April 1975, pp.3-8.
1975: Brooks, F.[?], The Mythical Man Month[?]
1983: Booch, G.[?], Software Engineering with Ada[?] Benjamin-Cummings. (Around page 43) describes an iterative process for growing an object-oriented system.
1984: Madden, W and Rone, K.[?], Design, Development, Integration: Space Shuttle Primary Flight Software System[?], CACM 27 9, Sept 1984, 914-925.
1984: Rzevski, G.[?], Prototypes Versus Pilot Systems: Strategies For Evolutionary Information Systems Development[?], Approaches to Prototyping, Editors Budde et al, Springer-Verlag
1985: Boehm, B.[?], A Spiral Model Of Software Development And Enhancement[?], 2nd. International Software Process Workshop. Coto de Caza, Trabuco Canyon, USA 1985. Wileden, J. and Dowson, M. (Eds.)
1985: Rzevski, G.[?], Trends in Information Systems Design[?], Infotech State of the Art Review, Mature Systems Design[?], edited by L. Evans, Pergamon Press
1986: Currit, P. Allen[?], Dyer[?], Michael and Mills[?], Harlan D[?], Certifying the Reliability of Software[?] IEEE TOSE, Vol. SE-12, No. 1, Jan86.
Credit This page is extensively based on:
Search Encyclopedia
|
Featured Article
|