Talk:Iterative and incremental development

Move to Agile whatever is Agile and not about the Title topic

Folks are mistakenly putting content here that should go to Agile Software Development Text is not describing title, it is stating that it's a key part of Agile, then first section "The basic idea behind the agile method is", and many references listed here were lost because they were agile so deleted as being Agile... People putting Agile content here is a waste, put it where it will apply and be found. Markbassett (talk) 17:27, 28 August 2012 (UTC)

V model

What are the advantages of "V" Model over the other life cycle models. —The preceding unsigned comment was added by 209.78.112.253 (talk • contribs) 19:09, 19 January 2006 (UTC2)

The proper place to see that is in the article about v_model Markbassett (talk) 15:14, 28 August 2012 (UTC)

Merge with Incremental build model

Agree with the merge of Incremental build model.

1. A quick Googling of incremental build model shows that the term is hardly in use.
2. The article is a stub, and is vague to the point of being useless.
3. It is redundant to the text in this article.

—The preceding unsigned comment was added by 65.222.202.26 (talk • contribs) 18:45, 13 March 2006 (UTC2) Perhaps a bit too much emphasis on methodology guideines. In particular, methodology is a bit redundant in the "guidelines" section. I believe the incremental build model should be separate. I concur with many of the contributors; the incremental build model is rarely utilized as a business process model. Does anyone in Software use or employ this methodology? I am not aware of any such cases. On the other hand, I do know of many references to the iterative approach in Technology Consulting.

A project iteration, especially in the DW business process, is not necessarily incremental development. —The preceding unsigned comment was added by 83.41.43.222 (talk • contribs) 00:37, 25 March 2006 (UTC2)

I can certainly understand the point of merging these two documents. However, as a student studying Software Engineering, I can recognize the differences. I think it would be beneficial to keep these two articles separate. I realize that there is an overlap in material, but there is also a vast amount of differences that the stub seems not to have taken account of. —The preceding unsigned comment was added by Blatyo (talk • contribs) 16:40, 6 April 2006 (UTC2)

I am also a student of Software Engineering, and we are currently doing research on building a specific model for incremental development. It differs greatly from iterative development. In ID, each iteration is like a mini-software lifecycle, with design, coding, and testing phases. Incremental development involves adding features in small chuncks, where each change produces valid, working software. The software is complete when all requirements are met. I will add more to the Incremental Development article once research paper is completed. —Preceding unsigned comment added by 68.62.22.177 (talk • contribs) 2006-09-20T21:57:18

---

Please sign your comments! --Bdoserror 22:15, 23 October 2006 (UTC)

The reason it is CURRENTLY hardly used is because it was used in the 1950s (the WWW did not exist at those times). Just because something does not have lots of search engine hits does not mean it did not exist or that it is not relevant. Both incremental and iterative principles were born at about the same time and were used in large military projects together. It seems that the incremental part was adopted in civilian environments first (oldest written mention from 1957) and the iterative part was more widely adopted later (oldest written mention from 1968). The military got the iterative part from other methodologies such as PDCA and PDSA. The incremental part was already in use for any large project since ages. So, it was a natural choice for the military. I have the sources but not the time to explain more or edit this article now. As a final statement, several Agile frameworks combine both. The iterative incremental development process is also called "EVOLUTIONARY" !! George Rodney Maruri Game (talk) 06:14, 7 July 2023 (UTC)

What development models *aren't* iterative and incremental?

Obviously the 'evil' rigid waterfall model wasn't incremental, but it was never really advocated. It seems to me that all software development models, spiral on, have been iterative whenever possible. Could someone add an example or examples of development methodologies that don't fit in this category? If there aren't any, what use does this term serve? --Logomachist 03:40, 5 January 2007 (UTC)

• Was wondering this myself. 71.240.184.133 18:17, 31 January 2007 (UTC)

The waterfall model is apparently still used. The distinction should probably be that other models are designed to be incremental/iterative, while the waterfall model is not designed this way, but since software is rarely 100% right first time... --Michig 19:17, 31 January 2007 (UTC)

I expected a Criticism section - maybe there is no criticism possible? Mdmcginn (talk) 15:42, 10 January 2010 (UTC)

Definition

The definition (the first sentence) is no definition. It only states why this topic exists and where it is used - but not what is ment by iterative and incremental development. --Sebastian Dietrich 09:23, 24 May 2007 (UTC)

History

I moved the following section to the talk page here. There is a cleanup tag for two year now. This should first be improved before replacing this section. -- Marcel Douwe Dekker (talk) 23:59, 9 October 2008 (UTC)

For the June 2003 IEEE Computer issue dedicated to agile methods (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 haven't 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.

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

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

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

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

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

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

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

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

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.

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

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

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.)

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

1986: Barry Boehm, A Spiral Model of Software Development and Enhancement, ACM SIGSOFT Software Engineering Notes (SEN), August 19–6 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.

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

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

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

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

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

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

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

Describes a process for iteratively and incrementally growing a system.

1992: Ph. Kruchten, Un Processus de Développement de Logiciel Itératif et Centré sur l'Architecture 4e Congrès de Génie Logiciel, Toulouse, France, Décembre 1991, EC2, Paris

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

1993: Alistair Cockburn, The Impact of Object-Orientation on Application Development (PDF) IBM Systems Journal, 32(3), March 1993, pp. 420-444, reprinted in the 50-year anniversary 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. Kruchten, A Rational Development Process Crosstalk, 9 (7) July 1996, pp.11-16.

(see [1])

What will become the RUP lifecycle. - PhilippeKruchten

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

where MBASE and RUP aligns concepts and terminology. - PhilippeKruchten

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

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

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

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

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

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

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

1997 Alistair Cockburn, Using VW Staging to Clarify Spiral Development

The image is wrong!

The deployment of course comes after the testing. It's not Windows or GTA we're talking about! ^^
— 88.77.140.123 (talk) 18:50, 25 September 2009 (UTC)

Velocity

I did not find velocity (factor to calculate actual development time from workdays) in any software engineering topic. I think this is a very important term and should be explained somewhere (or rather, should even have its own topic). I'd be glad if someone could add this. Kind regards -- mafutrct (talk) 11:10, 11 November 2009 (UTC)

The image of Iterative development may be misleading

The image is rather a good illustration of an incremental development, and not iterative. We see increments within phases, we do not see iterations. It is quiet common procedure to execute more than just one iteration, in order to achieve the amount of software desired for one increment. This can not be seen here, and the first misleading impression can be, iteration and increment are the same. — Preceding unsigned comment added by MarekLewandowski (talk • contribs) 08:20, 27 July 2011 (UTC)

Merge from Incremental build model

It seems to me as if there is no good reason to have a separate article at Incremental build model. --Slashme (talk) 12:32, 22 August 2011 (UTC)

There is a naming problem here, not just an overlap for merging. What's a "build model"? IMHE (not actually that humble, this has been my day job for years), a "build model" is a manufacturing process within software development, as for software build. The design process is not referred to under that same name. So the article we have at Incremental build model talks about the design evolution, just as this article at Iterative and incremental development, and it's sourced by sources that don't apply the term "build" to it either. It's thus a good target for merging, and the name isn't appropriate to preserve as a redirect.

If we are to have an article on incremental build, then this should be (probably a redirect to a section within software build) an article on the build technique of building by incremental compilation of changed modules, and the need to manage their inter-dependencies. It's a good topic, but it's then of little relation to Iterative and incremental development. Andy Dingley (talk) 11:44, 7 January 2013 (UTC)

• Agree. Merge Incremental build model into Iterative and incremental development. — Aaditya 7 (talk · contribs) 22:29, 10 November 2024 UTC [refresh]
•  Disagree. Both incremental and iterative principles were born at about the same time and were used in large military projects together but subsequently they were adopted separatedly. It seems that the incremental part was adopted in civilian environments first (oldest written mention from 1957) and the iterative part was more widely adopted later (oldest written mention from 1968). The military got the iterative part from other methodologies such as PDCA and PDSA. The incremental part was already in use for any large project since ages. So, it was a natural choice for the military. I have the sources but not the time to explain more or edit this article now. As a final statement, several Agile frameworks combine both so, everything just came back to its roots. The iterative incremental development process is also called evolutionary as I have also mentioned here. George Rodney Maruri Game (talk) 06:44, 7 July 2023 (UTC)

Alternative name: EVOLUTIONARY

Another name for this development model is EVOLUTIONARY. Please, add this datum to the article.

https://dspace.mit.edu/bitstream/handle/1721.1/80490/42757317-MIT.pdF

https://www.geeksforgeeks.org/software-engineering-evolutionary-model/

George Rodney Maruri Game (talk) 06:24, 7 July 2023 (UTC)

"Contrast with Waterfall development" section is misleading

That's some pretty broad statements there that have no evidence like Waterfall needing more human resources than incremental, and Waterfall being unsuitable for small projects. There are counterexamples in real life for these two and other points from this section. I'd add the evidence or delete the section. 2003:DB:4F0C:7196:9DB8:E58A:C6AB:D197 (talk) 16:38, 11 July 2023 (UTC)