IterativeDevelopment is often confused with IncrementalDevelopment.

software - Iterative & Incremental development

"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious". - Fred Brooks, The Mythical Man-Month.

----------------------------------------------------------------------------------------
DEVELOPMENT PLANNING & PREREQUISITES
Cone of Uncertainty:
All software projects are subject to inherent errors in early estimates.
The Cone of Uncertainty represents the best-case reduction in estimation error and improvement in predictability over the course of a project.
Skillful project leaders treat the cone as a fact of life and plan accordingly.
0. Initial concept
1. Approved product definition
2. Marketing / business requirements complete
3. Detailed technical requirements complete
4. Detailed design complete


Software development is a process of continuous refinement.
A well-run software project attacks areas of highest variability first to narrow the cone as rapidly as possible. Active control is needed throughout the project to keep the cone from widening again.

construx.com - Remaining variability in project scope (cost, size, or features)
----------------------------------------------------------------------------------------
--------------------------
To be able to make realistic estimate workload and start planning, we should have answers to these two CRUCIAL questions:
1. What assumptions and preconditions have not been yet fulfilled; so we can not start to make any estimate of the volume of work and start planning development?
2. Have the end user/ client CONFIRMED the future solution mockup (interface layout and operating procedures), before the coding has started!?

CONSTRUX: http://www.construx.com/uploadedFiles/Construx/Construx_Content/Resources/Templates/ActorTable.pdf
- User Manual / bill mockup & menus - Approved product definition - Potrebno je dobiti od korisnika/klijenta POTVDU!
- Terminal Diagnostic
- System diagnostic (echo, log monitoring, health monitoring)

------------------
The art of start
------------------
What we need is to get at least some (elementary, small) part working first, so that we can tell that we are moving forward.
For the start, we need to construct fully functional working base, which is incrementally extendible.
..................................

EXPERT COCOMO
Expert COCOMO was developed by Dr. Ray Madachy and uses heuristics to flag potential risks found in specified project development conditions.
It aids planning projects by identifying, categorizing, quantifying and prioritising projects risks. It also detects cost estimate input anomalies. Further information can be found in [Expert COCOMO] or [Boehm et al. 2000a].

COCOMO® II can be used for the following major decision situations
★ Making investment or other financial decisions involving a software development effort
★ Setting project budgets and schedules as a basis for planning and control
★ Deciding on or negotiating tradeoffs among software cost, schedule, functionality, performance or quality factors
★ Making software cost and schedule risk management decisions
★ Deciding which parts of a software system to develop, reuse, lease, or purchase
★ Making legacy software inventory decisions: what parts to modify, phase out, outsource, etc
★ Setting mixed investment strategies to improve organization's software capability, via reuse, tools, process maturity, outsourcing, etc
★ Deciding how to implement a process improvement strategy, such as that provided in the SEI CMM

------------------------------------------
http://c2.com/cgi/wiki?IterativeDevelopment

Iterative Development
The word "iterative" means that it involves repetition.
Iterative Development is a development approach that "cycles" through the development phases, from gathering requirements to delivering functionality in a working release.
Contrast this with the WaterfallModel, where you gather all the requirements up front, do all necessary design, down to a detailed level, then hand the specs to the coders, who write the code; then you do testing (possibly with a side trip to IntegrationHell) and deliver the whole thing in one big end-all release. Everything is big including the risk of failure.
Consider also IncrementalDelivery; (an XP page that may actually be talking about IterativeDevelopment) IncrementalDelivery also delivers functionality to users in cycles, but is historically less focused on reworking existing functionality. So a traditional "IncrementalDelivery" project will deliver one subsystem at a time to the end users, with "as little change as possible" to each subsystem, after it's delivered.
A key differentiation between the traditional WaterFall and the Iterative processes is how the project tasks are boxed in the plan. If they are functionally boxed you are probably WaterFalling?, if they time-boxed you are probably Iterating.

---------------------------------------------------
Project Apollo: Iterative & Incremental
---------------------------------------------------
The mission Project Apollo had was given with a high level Kennedy goal which says: "Build a system which can control the equipment to carry men to the moon and land them on the surface. The system must also be able to bring men safely back to Earth".
Which piece of the system can I design, code and deliver first to my customer and provide usable functionality?

In XP terms, the Project Apollo was series of spikes:
1. build a rocket engine that has enough thrust
2. build a rocket that can lob a man into space
3. build one that can lob a man into orbit
4. dock two space vehicles in orbit
5. land an unmanned one-way vehicle on the moon to check the environment
6. fly round the moon
7. test out the lander near the moon
etc

Apollo programme was, in itself, an incremental and iterative project. So, NASA has been an Agile organisation for much longer than many might give them credit for.
It wasn’t until Apollo 11 that they landed someone on the moon. Each mission, from 1 to 11 (as well as the numerous missions prior to that not carrying the Apollo name), was a process of experimentation and gradual improvement towards the end goal.
Think of each Apollo mission as a ‘release’, each of which improved upon the previous. Following the tragedy of Apollo 1 (where 3 astronauts lost their life) subsequent Apollo missions were unmanned progressing back to manned flights. Incrementally, missions progressed to achieve earth orbit, then lunar orbit and finally, landing on the moon.
Learning from each mission was used to improve and refine the portion of the journey achieved so far and to guide the next increment.

The mantras of IterativeDevelopment are:
★ Phases are Time-Boxed not Functionally-Boxed.
★ Test early, Test often.
★ Deliver early, Deliver often.
★ Production Quality.
Iterative Development processes grew out of ObjectOrientedDevelopment? where it quick appreciated that a Class could be considered a mini-project and developed in isolation, the task was naturally boxed by its responsibilities.



Learn from each spike and refactor your design
http://c2.com/cgi/wiki?IterativeDevelopment
land on the moon.
-- TomAyerst
Decompose the system into functional parts and implement one of them. E.g. build software which controls the amount of oxygen in the air, or or or...

-------------------------------------------------------------------------------------
Iterative Vs/and/or Incremental
-------------------------------------------------------------------------------------
Often SW development is blend of both Iterative and Incremental approach.
IterativeDevelopment is often confused with IncrementalDevelopment. IterativeDevelopment is about planned rework. You create something, review it and then change it (hopefully improving it) based on the feedback.

A good analogy is when authors write books. Typically they have 2 or 3 external reviews and rewrites before it goes to the copy editors. The iterations are planned rework. Having reviewed lots of initial drafts, believe me when I say you wouldn't want to pay to read the first draft of many books. It's bad enough reading initial drafts when you are being paid to read it (a sentiment I hope is not shared by my reviewers). -- PeteMcBreen

Let me see if I've got this, I'll use the book writing analogy:

IterativeDevelopment means:
- I write loads of stuff that's a complete mess
- I go through it throwing out the irrelevant drivel, expanding on the important bits, and sorting out the structure
- I go through it again now I can start to see the shape of it, sorting it some more
- I go through it yet again, etc, until it's GoodEnough

IncrementalDevelopment means:
- I write part one
- I write part two
- I write part three, etc, until the book is finished
Now incremental development may work OK for novelists (e.g. Charles Dickens, or J.K. Rowling), but when you try doing it with computer systems you find that in writing part two, you need to revise and rework some of part one (e.g. to allow reuse), and in writing part three you need to reworks parts one and two, etc..., especially if you subscribe to OnceAndOnlyOnce and MercilessRefactoring.
So in practice, at least in XP practice, your development is both incremental and iterative. - StephenHutchinson

True - The danger is when people confuse the two. I saw a 200 person project iterating on their requirements (allowing arbitrary amount of change) when they should have been incrementing through their requirements, and incrementing & iterating (as you describe) through their design. They were, of course, not making any progress. Also saw a 100 person project claiming they were iterating through their entire novel, when in fact they were doing neither - they were stuck in the mud. They needed to get at least some part working first so they could tell they were moving - once again, needed incrementing as a base. -- AlistairCockburn
------------------------------------------------------------------------------------