Iterative Process: Definition, Meaning, Incremental Delivery and Use in Project Management

"Define the iterative process" and "differentiate iterative and incremental development" are short questions with a surprisingly large footprint in the software papers. The idea sits in the Software Processes unit of TU BSc CSIT Software Engineering (CSC375: process activities, coping with change, incremental delivery, Boehm's spiral model and the Rational Unified Process), in CSC425 Software Project Management, and in BIT302 Software Engineering (Software Process Models) and BIT402 Software Project Management (Software Development Methodologies).

This article gives the iterative process definition and meaning in plain words, separates it from the incremental approach and incremental delivery, compares both with waterfall in a table, shows where iteration appears in project management, and ends with an answer you can write for 5 or 10 marks.

Iterative process: definition and meaning

An iterative process is a way of developing software in which the same set of activities (specify, design, implement, test) is repeated in cycles, and each cycle refines and improves the work of the previous one. Instead of finishing every requirement and every design decision before writing any code, the team builds a version, looks at what is wrong or missing, and goes round again.

The meaning of iterative process comes down to three ideas. Repetition: the cycle runs many times. Feedback: the result of each cycle is reviewed by the customer or the team before the next one starts. Refinement: the same product gets better, because early cycles expose misunderstandings that would be very expensive to find at the end.

The reason it exists is the one Sommerville gives under coping with change: change is inevitable in large projects. Requirements change because the business changes, and because users only understand what they need once they see something running. A process that expects to get everything right in one pass breaks under change. A process that loops expects change and absorbs it.

Incremental approach and incremental delivery

The incremental approach builds the system in pieces. The requirements are divided into increments, and each increment adds new working functionality on top of what already exists. Incremental delivery means each of those increments is actually handed to the customer to use, so the customer gets value early and the earliest increments are tested by real use while later ones are still being built.

A typical incremental plan for a student-record system might deliver login and student registration first, then result entry, then report cards, then fee tracking. Each release works on its own. The highest-priority features get the most use and therefore the most testing.

The two ideas are often mixed up. Iteration is about repeating and improving. Increment is about adding and delivering. A real project usually does both at once: it delivers in increments, and inside each increment it iterates over design and code until the increment is good enough.

Iterative vs incremental vs waterfall

Waterfall is the plan-driven extreme: the stages are separate and the output of one stage is the signed-off input of the next. Both iterative and incremental development are ways of overlapping those stages and repeating them. Boehm's spiral model and the Rational Unified Process, which your syllabus names, are both iterative models, and the RUP also delivers incrementally.

Iterative models in the syllabus

The spiral model draws development as a spiral of loops. Each loop has four sectors: set objectives, assess and reduce risks, develop and validate, and plan the next loop. It is risk-driven, which means the riskiest part is attempted first so that the project fails early and cheaply if it is going to fail at all.

The Rational Unified Process is iterative across four phases: inception, elaboration, construction and transition. Each phase may have several iterations, and each iteration runs through the engineering activities in different proportions. Early iterations are mostly requirements and design, later ones are mostly implementation and testing.

Prototyping, the evolutionary form of which keeps refining a working version until it becomes the final system, is also an iterative technique.

Where iteration appears in project management

In CSC425 and BIT402 the iterative idea is not only a development model, it is a management habit.

Plan, do, review: the basic management cycle (often written plan, do, check, act) is itself iterative. A manager plans an activity, executes it, compares progress with the plan, and adjusts the next plan. Monitoring and control in project management is this loop.

Sprints and timeboxes: in Scrum the work is divided into fixed-length sprints, each producing a potentially shippable increment. At the end the team holds a review with the customer and a retrospective, and the backlog is re-prioritised for the next sprint. The sprint is a timeboxed iteration.

Risk-driven loops: risk management is revisited throughout the project rather than done once. The risk register is reviewed every cycle, risks are re-ranked, and the next iteration is planned to tackle the highest exposure first, which is the spiral idea applied to planning.

Progressive estimation and planning: estimates are rough at the start and are refined as each iteration reveals the real velocity of the team. Plans for the near future are detailed, plans for the distant future stay coarse and are reworked as the project advances.

Advantages and problems

Advantages: requirement changes are cheaper to accommodate; the customer sees working software early and can correct direction; risks are found and reduced early; the team can use what it learned in one cycle in the next; important features are tested the most.

Problems: the process is less visible to management because there are no neat documents at the end of each phase to measure against, so progress must be tracked by working software instead. The structure of the system tends to degrade as changes accumulate, unless time is given to refactoring. It is hard to estimate total cost and schedule at the start. Contracts that fix scope and price in advance fit it badly. And without discipline, "iterating" can turn into rework with no end in sight, so each iteration needs a clear goal and a time limit.

How to write it in the exam

For 5 marks on "define iterative process": give the definition (repeating cycle of activities with review and refinement), say why it is used (change is inevitable, early feedback), and list two or three advantages and two problems. If "incremental delivery" is also asked, add one paragraph distinguishing it: increments add functionality and are delivered, iterations refine.

For 10 marks, add the comparison table with waterfall, a short description of the spiral model's four sectors or the RUP phases, and one paragraph on how iteration appears in project management (review cycles, sprints, risk-driven planning). A small diagram of a loop of specify, design, implement, test with an arrow back is worth drawing.

The full unit notes are on Software Processes in CSC375, with the project side in Introduction to Software Project Management and the CSC425 subject page. BIT students should read Software Process Models in BIT302 and Software Development Methodologies in BIT402.