Iterative and incremental development

From Wikipedia, the free encyclopedia

(Redirected from Iterative=20 development)

Jump to: na= vigation,=20 s= earch

Softwa= re=20 Development Process
This article is part of the Software=20 Development Process series
Activities and = Steps
Requ= irements=20 \| Architecture<= /A>=20 \| Implementation= =20 \| Testing = \| Deployment<= /TD>
Models
Agile \|=20 Clea= nroom=20 \| Iterative \| RAD=20 \| RUP \| = Spiral \| Waterfall \| XP
Supporting = Disciplines
C= onfiguration=20 Management \| Documentatio= n=20 \| Project=20 Management \| User = Experience=20 Design

Iterative and Incremental development is a softwa= re=20 development process developed in response to the weaknesses of the = more=20 traditional waterfall = model. The two=20 most well known iterative development frameworks are the Rational = Unified=20 Process and the = Dynamic=20 Systems Development Method. Iterative and incremental development is = also an=20 essential part of Extreme = Programming=20 and all other agile = software=20 development frameworks.

1 Life-Cycle=20
2 Characteristics=20
3 History=20
4 Credit=20
5 See = also=20
6 External = links=20

[edit]=20 Life-Cycle

The basic idea behind iterative enhancement is to develop a software system = incrementally,=20 allowing the developer = to take=20 advantage of what was being learned during the development of earlier,=20 incremental, deliverable versions of the system. Learning comes from = both the=20 development and use of the system, where possible. Key steps in the = process were=20 to start with a simple implementation of a subset of the software = requirements=20 and iteratively enhance the evolving sequence of versions until the full = system=20 is implemented. At each iteration, design modifications are made and new = functional capabilities are added.

The Procedure itself consists of the Initialization step, the = Iteration step,=20 and the Project Control List. The initialization step creates a base = version of=20 the system. The goal for this initial implementation is to create a = product to=20 which the user can react. It should offer a sampling of the key aspects = of the=20 problem and provide a solution that is simple enough to understand and = implement=20 easily. To guide the iteration process, a project control list is = created that=20 contains a record of all tasks that need to be performed. It includes = such items=20 as new features to be implemented and areas of redesign of the existing=20 solution. The control list is constantly being revised as a result of = the=20 analysis phase.

The iteration involves the redesign and implementation of a task from = project=20 control list, and the analysis of the current version of the system. The = goal=20 for the design and implementation of any iteration is to be simple,=20 straightforward, and modular, supporting redesign at that stage or as a = task=20 added to the project control list. The code can, in some cases, = represent the=20 major source of documentatio= n of=20 the system. The analysis of an iteration is based upon user feedback, = and the=20 program analysis facilities available. It involves analysis of the = structure,=20 modularity, usability, = reliability,=20 efficiency, and achievement of goals. The project control list is = modified in=20 light of the analysis results.

Guidelines that drive the implementation and analysis include:

Any difficulty in design, coding and testing a modification should = signal=20 the need for redesign or re-coding.=20
Modifications should fit easily into isolated and easy-to-find = modules. If=20 they do not, some redesign is needed.=20
Modifications to tables should be especially easy to make. If any = table=20 modification is not quickly and easily done, redesign is indicated.=20
Modifications should become easier to make as the iterations = progress. If=20 they are not, there is a basic problem such as a design flaw or a=20 proliferation of patches. =
Patches should normally be allowed to exist for only one or two=20 iterations. Patches may be necessary to avoid redesigning during an=20 implementation phase.=20
The existing implementation should be analysed frequently to = determine how=20 well it measures up to project goals.=20
Program analysis facilities should be used whenever available to = aid in=20 the analysis of partial implementations.=20
User reaction should be solicited and analysed for indications of=20 deficiencies in the current implementation.

[edit]=20 Characteristics

This article may require cleanup to = meet=20 Wikipedia's quality=20 standards.
Please discuss this issue on the talk=20 page or replace this tag with a more=20 specific message.
This article has been tagged since = October=20 2006.

Using analysis and measurement as drivers of the enhancement process = is one=20 major difference between iterative enhancement and the current agile = software=20 development. It provides support for determining the effectiveness = of the=20 processes and the quality of product. It allows one to study, and = therefore=20 improve and tailor, the processes for the particular environment. This=20 measurement and analysis activity can be added to existing agile = development=20 methods.

In fact, the context of multiple iterations provides advantages in = the use of=20 measurement. Measures are sometimes difficult to understand in the = absolute but=20 the relative changes in measures over the evolution of the system can be = very=20 informative as they provide a basis for comparison. For example, a = vector of=20 measures, m1, m 2, ... mn, can be defined to characterize various = aspects of the=20 product at some point in time, e.g., effort to date, changes, defects, = logical,=20 physical, and dynamic attributes, environmental considerations. Thus an = observer=20 can tell how product characteristics like size, complexity, coupling, = and=20 cohesion are increasing or decreasing over time. One can monitor the = relative=20 change of the various aspects of the product or can provide bounds for = the=20 measures to signal potential problems and anomalies.

Several utility software have been developed using this model, = wherein the=20 requirement is basically providing the customer with some working model = at an=20 early stage of the development cycle. As new features are added in, a = new=20 release is launched which has fewer bugs and more features than the = previous=20 release. Some of the typical examples of this kind of model are:

Yahoo Messenger, Azureus, Cyber Sitter, Net Meter, PC Security, = Limewire,=20 P2P, etc. xyz

[edit]=20 History

For the June 2003 IEEE Computer issue dedicated to agile methods = (edited by=20 A. Cockburn and L. Williams), Vic Basili and CraigLarman are writing a = short 1-2=20 page history of iterative/incremental lifecycle processes.

1970: = Royce,=20 W.W., M= anaging=20 the Development of Large-Scale Software: Concepts and Techniques = Proceedings, Wescon, August 1970 (also reprinted in Proceedings, ICSE9), = which=20 includes a "build it twice" prototyping step -- entered by Barry=20 Boehm

1971: = Mills,=20 H., Top-down=20 programming in large systems Debugging Techniques in Large = Systems, R.=20 Rustin, ed., Englewood Cliffs, N.J., Prentice-Hall, 1971. (Frederick = Brooks=20 mentions this in NoSilverBullet: "Some years ago Harlan Mills proposed = that any=20 software system should be grown by incremental development.") - entered = by Christian=20 Ohman

1973: = Mills,=20 H., On=20 the Development of Large, Reliable Programs IEEE Symp. Comp. SW=20 Reliability. Notes: I have heard this paper has relevance to iterative, = but=20 haven't read it yet. - CraigLarman

1975: = Williams,=20 R.D., Managing=20 the Development of Reliable Software Proceedings, 1975 = International=20 Conference on Reliable Software, ACM/IEEE, April = 1975,=20 pp.3-8.

Discusses the use of incremental development on the $100M TRW/Army = Site=20 Defense software project for ballistic missile defense. The project = began in=20 February 1972 and developed the software in 5 loops or increments of=20 functional capability. Loop 1 just did tracking of a single object; = Loop 5=20 covered the full mission. -- entered by BarryBoehm

1975: = Brooks,=20 F., The = Mythical=20 Man-Month

"Plan to throw one away; you will, anyhow." - entered by = PhilippeKruchten=20

Please note that Brooks writes in The Mythical Man-Month after 20 = years:=20 "This I now perceive to be wrong, not because it is too radical, but = because=20 it is too simplistic.=20

The biggest mistake in the "Build one to throw away" concept is = that it=20 implicitly assumes the classical sequential or waterfall model of = software=20 construction."=20

The problem is that you only will know what parts to throw away = after the=20 system is finished and the system testing is over. - ChristianOhman =

1975: = Basili,=20 V. and Turner,=20 A., Itera= tive=20 Enhancement: A Practical Technique for Software = Development :IEEE = Transactions on SW=20 Eng.

1981: = Boehm,=20 B., Software=20 Engineering Economics Prentice-Hall. ISBN=20 0-13-822122-7 (pages 41-2, 254) allows for an iterative process when = developing software.

1983: = Booch,=20 G., Software=20 Engineering with Ada Benjamin-Cummings. (Around page 43) = describes an=20 iterative process for growing an object-oriented system.

1984: = Madden,=20 W and Rone, K., Design,=20 Development, Integration: Space Shuttle Primary Flight Software = System,=20 CACM 27 9, Sept 1984, 914-925.

-- Although the publication was only in 1984, they used an = iterative=20 approach in 1977-79..=20

"An implementation approach was devised for STS-1, which met the=20 objectives by applying the ideal cycle (they mean the waterfall = cycle), to=20 small elements of the overall software package on an iterative basis. = ...=20 STS-1 had 17 interim release drops in a 31-month period starting = October 1977.=20 Full software capability was provided after the 9th release in = December 1978."=20 - PhilippeKruchten

1984: = Rzevski,=20 G., Prototypes=20 Versus Pilot Systems: Strategies For Evolutionary Information Systems=20 Development, Approaches to Prototyping, Editors Budde et al,=20 Springer-Verlag

1985: = Boehm,=20 B., A=20 Spiral Model Of Software Development And Enhancement, 2nd. = International=20 Software Process Workshop. Coto de Caza, Trabuco Canyon, USA 1985. = Wileden, J.=20 and Dowson, M. (Eds.)

Notes: I'm not sure this citation is correct. - CraigLarman;=20 PhilippeKruchten can offer this alternate:

1986: = Barry=20 Boehm, A=20 Spiral Model of Software Development and Enhancement, ACM = SIGSOFT=20 Software Engineering Notes (SEN), August 1986

1985: = Rzevski,=20 G., Trends=20 in Information Systems Design, Infotech State of the Art Review, = Mature=20 Systems Design, edited by L. Evans, Pergamon Press

1986: = Currit,=20 P. Allen, Dyer,=20 Michael and Mills, Harlan D, = Certifying=20 the Reliability of Software IEEE TOSE, Vol. SE-12, = No. 1,=20 Jan86.

Notes: pp 3-11. Executable product increments are the basis for = MTTF=20 estimates. - TomGilb

1988: = Gilb,=20 T Principles=20 of Software Engineering Management AW.

Notes: This had three chapters on Evolutionary Dev. - CraigLarman =

1988: = Brigader=20 General H=20 Edward USA (ret.), Evolutionary=20 Acquisition of Command and Control Systems: Becoming a Reality = Signal,=20 January 1988

Notes: pp 23-26 Found this reference in SPUCK93 (JPL, RDM) - = TomGilb=20

1988: = Boehm,=20 B, A=20 Spiral Model Of Software Development And Enhancement IEEE=20 Computer. May 1988.

1991: = Booch,=20 G, Object-oriented=20 Analysis and Design with Applications Addison-Wesley

Describes a process for iteratively and incrementally growing a = system.=20

1992: = Ph.=20 Kruchten, Un=20 Processus de D=C3=A9veloppement de Logiciel It=C3=A9ratif et Centr=C3=A9 = sur=20 l'Architecture 4e Congr=C3=A8s de G=C3=A9nie Logiciel, Toulouse, = France, D=C3=A9cembre=20 1991, EC2, Paris

Iterative approach the "Rational way" (English version exists as a = whitepaper from Rational) - PhilippeKruchten

1993: = Cockburn,=20 A, The=20 Impact of Object-Orientation on Application Development IBM = Systems=20 Journal, 32(3), March 1993, pp. 420-444, reprinted in the 50-year = anniversary=20 issue, IBM Systems Journal 38(2-3), 1999. http://www.research.ibm.com/journal/sj38-23.html

Presents one view of the difference between incremental and = iterative development (p. 311)

1996: = Ph.=20 Kruchten, A=20 Rational Development Process Crosstalk, 9 (7) July 1996, = pp.11-16.

(see [1])=20

What will become the RUP lifecycle. - PhilippeKruchten

1996: = Barry W.=20 Boehm, 1996, Anchoring=20 the Software Process IEEE Software, = July 1996,=20 pp.73-82.

where MBASE and RUP aligns concepts and terminology. - = PhilippeKruchten=20

1996: = Booch,=20 G, Object=20 Solutions Addison-Wesley.

Explains the importance and substance of an iterative and = incremental=20 lifecycle; talks about the growing of an architecture through = successive=20 refinement; introduces the notion of different rhythms (micro and = macro=20 process) in the lifecycle. About the same time there was a book by = Adele=20 Goldberg and Kenny Rubin of a similar nature. Alistair Cockburn's = "SOOP" book=20 followed shortly afterwards.

1998: = Jennifer=20 Stapleton, DSDM:=20 Dynamic Systems Development Method Addison-Wesley

1998: = Walker=20 Royce, Software=20 Project Management?A Unified Framework, = Addison-Wesley-Longman

1999: = Beedle,=20 Mike; Devos,=20 Martine; Sharon,=20 Yonat; Schwaber,=20 Ken; Sutherland,=20 Jeff. SCRUM:=20 An extension pattern language for hyperproductive software = development.=20 In Harrison, Neil; Foote, Brian; Ronhert, Hans (Eds.) Pattern Languages = of=20 Program Design 4. Addison-Wesley Software Patterns Series.

1992: = Jacobson, Ivar, = Object-Ori= ented=20 Software Engineering: A Use Case Driven Approach. Chapter 2, The = system=20 life cycle.

In my edition, Addison-Wesley revised 1998, pp 23ff. = --StevenNewton=20

[edit]=20 Credit

This page is extensively based on:

http://c2.com/cgi/wiki/wiki?HistoryOfIterative =

[edit]=20 See also

[edit]=20 External links

Article Going round and round and getting nowhere eXtremely = fast? Another=20 look at incremental and iterative development from Methods & = Tools=20

Article The =E2=80=9CCase=E2=80=9D for Waterfall = Development from From The = Trench

Article Iterative Development and The Leaning Tower of Pisa = from From The = Trench

Retrieved from "http://en.wikipedia.org/wiki/Iterative_and_incremental_development= "

Categories: = Software=20 development process | = Cleanup=20 from October 2006 | = All pages=20 needing cleanup

Views

Article=20
Discussion=20
Edit=20 this page=20
History=20

Personal tools

Sign=20 in / create account

interaction

About = Wikipedia=20
Communit= y=20 portal=20
Recent=20 changes=20
Upload file = wizard=20
Contact = us=20
Make a = donation=20
Help=20

Search

Toolbox

What=20 links here=20
Related=20 changes=20
Upload file=20
Special = pages=20
Printable=20 version=20
Permanent=20 link
Cite=20 this article

In other languages

Deut= sch=20
Espa=C3=B1ol<= /A>=20
=E6=97=A5=E6=9C=AC=E8=AA=9E=20
Polski=20

This page was last modified 20:01, 9 April 2007.=20
All text is available under the terms of the GNU=20 Free Documentation License. (See Copyrights= =20 for details.)
Wikipedia=C2=AE is a registered trademark of the Wikimedia Foundation, = Inc., a=20 US-registered 501(c)= (3)=20 t= ax-deductible=20 nonprofit charity= .
Privacy = policy=20
About = Wikipedia=20
Discla= imers=20