UPI Study › Courses › Software Engineering › Free lessons › Lesson 2.1 Free with a free account
Building Software in Cycles: The Iterative Approach
Software Engineering · Chapter 2: Iterative, Incremental, and Specialized Process ModelsSection 2.1 · lesson 11 of 1038 min · free with a free account
Free preview
Create a free account to keep watching
It takes a minute and costs nothing. Your free account unlocks all of Chapter 1 and 3 more lessons of Software Engineering.
Lesson complete
Earn the 3 college credits for Software Engineering
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: Making Progress in Stages: Incremental Decision Models →← Recognizing Process Patterns Across Engineering WorkflowsNext lesson: Making Progress in Stages: Incremental Decision Models →
In this lesson
The iterative approach: how iterations work, why they help, and what they cost.
- Define the iterative model
- Describe how one iteration produces a working, evaluable version
- Compare iteration with a single, front-loaded pass
- Weigh the benefits and costs of iterating
Transcript
Everything said in the video, section by section (1,045 words). Read along, or search it.
Iterative, Incremental, and Specialized Process Models
Building Software in Cycles
This chapter turns to named process models, and the first is the simplest idea of all. Do the process more than once. This section defines the iterative model, walks through how an iteration unfolds, and compares it with a single pass. Then it weighs what iteration buys, and what it costs.
2 Teams, 1 Onboarding Portal
When Did They Find Out?
Two teams are asked to build an employee onboarding portal for a company's H R department. Team A spends the year building it once, top to bottom, from the requirements gathered in the first month. In month twelve, H R opens it, and finds that half the fields no longer match how onboarding works. The process changed in month four, and nobody knew. Team B builds a small, working version every few weeks, and shows it to H R each time. By month four, H R had already flagged the change, while the piece it touched was still small and easy to adjust. Team A was not careless. It built exactly what the first month's requirements said. What it lacked was an early chance to discover that the requirements themselves needed to move.
Defining It
Repeating the Process, Not Just the Work
The iterative model organizes a software effort as a series of iterations. Each iteration passes through the same core process activities, and produces a working, evaluable version of the software. Not a sketch or a plan, but software that can actually be run and judged. Each iteration builds on the one before it, adding capability or refining what is already there, rather than starting over. Contrast that with a single-pass approach, which runs the process once, assuming early decisions stay correct all the way to delivery. A single pass has no scheduled point to discover that an early decision needs to change, until the software is finished.
Table 1
One Iteration Shapes the Next
A single iteration is a compressed pass through the same five framework activities. A short round of communication and planning fixes the iteration's goal, usually one slice of the system. Modeling and construction produce a working version of that slice. And a brief deployment, often just a demo to stakeholders, gathers reactions that shape the next iteration. In the portal, iteration one built a basic employee information form. H R wanted document upload included before go-live. So iteration two added document upload. H R then flagged that a manager needed to approve submissions first. Iteration three added the manager approval step, and H R confirmed the workflow now matched how onboarding really runs.
Table 2
Single Pass vs. Iterative
Here is the comparison in three dimensions. In a single, front-loaded pass, working software is first seen at the very end. In an iterative approach, it appears after the first iteration, and repeatedly after that. In a single pass, requirement changes surface only once delivery reveals a mismatch. Iteratively, they surface early, while the affected piece is still small. And in a single pass, risk concentrates into one late-stage event. Iteratively, it is spread across many smaller events, each resolved as it appears.
Figure 3
How Risk Accumulates
This chart shows how that risk builds up. It is illustrative, not measured. In a single pass, a misunderstanding can sit undetected for months, quietly accumulating consequences. Then it surfaces all at once, near delivery. That is the rising curve. In an iterative effort, each cycle forces an early check. So risk climbs a little, is found, and drops back down, again and again. That is the sawtooth. The risk is addressed in small pieces, instead of one concentrated event.
Table 3
What Iteration Buys
Iteration earns its overhead through three related benefits. Early, concrete feedback, because stakeholders react to working software, not a document describing it. H R caught the process change while reviewing iteration one. Reduced late-stage risk, because problems surface in small pieces, rather than compounding into one large failure. The approval gap was fixed before the system grew larger. And room for evolving understanding. Some requirements cannot be fully known at the start, and iteration lets the plan adjust. All three trace back to one idea. The cost of a misunderstanding rises the longer it goes undetected, and iteration pulls detection earlier.
Table 4
What Iteration Costs
Iteration also carries real costs that a single pass avoids. Repeated overhead. Planning, integration, and review happen many times, because each iteration re-runs a compressed version of the whole process. Scope creep. The project keeps growing without a clear end, because every round of feedback is a chance to request something new. Harder fixed-price estimates. A customer who wants one firm cost and date up front is hard to satisfy, because the detailed scope keeps evolving. And growing integration difficulty. Each iteration's output has to fit into an already-growing system, and that gets harder over time.
A Default, Not a Rule
Calibrated to Uncertainty
So iteration is a strong default, not a rule that helps unconditionally. It earns its overhead when requirements are likely to be incompletely understood, or likely to change. It costs more than it returns when requirements are genuinely stable, and already well understood. Picture a team building a standard payroll calculator with fixed, stable requirements, that insists on six iterations anyway. It pays the full cost of repeated planning and integration, with little for stakeholder feedback to correct. A single, well-planned pass would have reached the same result, for less effort. Deciding how many iterations an effort needs, or whether it needs any, remains an engineering judgment.
Key Terms
The Vocabulary of This Section
Let's lock in the key terms. The iterative model organizes an effort as a series of iterations, each producing a working, evaluable version of the software. An iteration is one repeated cycle through the core process activities, building on the previous version. A single-pass approach runs the process once, with no scheduled point to revisit earlier decisions. Refinement is improving an existing working version in a later iteration. And scope creep is the tendency for requirements to keep expanding as new requests accumulate.
Key Takeaways
What to Carry Forward
To pull this together. The iterative model repeats the core process activities, and each iteration produces working, evaluable software, not a plan. It exists to create the scheduled checkpoints a single pass lacks. Each iteration compresses the five framework activities, and feedback from one round shapes the goal of the next. Iteration brings earlier feedback, less late-stage risk, and room for understanding to grow. It also brings overhead, scope creep, and harder fixed-price estimates, so it is a strong default when requirements are unsettled, and less valuable when they are stable.
About Software Engineering at UPI Study
Software Engineering (Computer Science 301) is a self-paced online course of 103 video lessons in 15 chapters, from process models and agile to requirements, design, user interfaces, reliability, security and project management. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →
Why take it here
Why students take Software Engineering with UPI Study
Where the credit goes
Universities that work with NCCRS
Software Engineering carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About Building Software in Cycles: The Iterative Approach
What is the iterative model in software development?
What happens during a single iteration of iterative development?
What are the disadvantages of iterative development?
When is iterative development not worth it?
About the Software Engineering course
How many college credits is Software Engineering?
How much does Software Engineering cost and what is included?
Which universities accept UPI Study credits?
How long does Software Engineering take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in Software Engineering.
103 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →