Software Engineering Lecture 04 – Incremental & Iterative Development

Incremental Development (Core Idea)

• Definition 1: Develop an initial implementation, collect user feedback, then evolve the product through several versions until the required system is achieved.

• Definition 2 (management-oriented wording): A product is built in small, manageable increments; every increment adds new functionality or features.

• Key characteristics

  • Specification, development, and validation are interleaved, allowing rapid feedback.

  • Each increment builds on the previous one until the full system is complete.

  • Promotes early visibility of working software, encouraging stakeholder involvement.

Generic Process Flow ("Build 1, Build 2 … Build N")

• For every increment:

  • Requirements → Design & Development → Testing → Implementation / Delivery

• Visually, think of a ladder: each rung is an increment that goes through the full SDLC mini-cycle.

• All increments eventually integrate into the final release.

Detailed Life-Cycle Phases (per Increment)

• Requirements Gathering

  • High-level needs collected first; refined detail gathered for the current increment only.

  • Serves as foundation for subsequent work.

• Design

  • Architecture, detailed design, UI/UX snapshots planned.

  • Often decomposed into smaller sub-designs to keep focus manageable.

• Implementation

  • Code the planned feature set for this increment.

  • Enables quick delivery of a usable slice of software.

• Testing

  • Confirm new functionality behaves as expected and does not regress previous behaviour.

  • Early detection → cheaper fixes.

• Integration

  • Merge new code with existing baseline.

  • Resolve merge conflicts, confirm whole-system cohesion.

• Evaluation & Feedback

  • Stakeholders review the increment and supply corrective or enhancement feedback.

  • Output loops back to adjust requirements/design for the next increment.

• Iterative Nature

  • Cycle continues until all required features are present.

  • $\text{Final Product} = \sum<em>{i=1}^{N} (\text{Increment}</em>i + \text{Stakeholder Feedback}_i)$

Requirements Handling Strategy

• Startup Phase

  • Capture only high-level or core requirements.

  • Establish overall architecture (e.g., DB + Frontend/Backend split, hosting constraints).

• Just-In-Time Detail

  • Immediately before each increment, elicit detailed requirements for that slice only.

  • Allows flexibility and learning from earlier increments.

  • Example

  • Increment 1 (Login): password encryption, forgot-password flow, optional 2FA, etc.

  • Increment 2 (Course Registration): prerequisite checking, time-clash rules, wait-list logic.

Advantages of the Incremental Model

• Early Delivery / Early Value

  • Users gain a usable (albeit small) system quickly.

• Continuous User Feedback

  • Stakeholders validate direction every increment.

• Easier Testing & Debugging

  • Smaller codebase per cycle → fewer simultaneous faults.

• Risk Reduction

  • High-risk items can be prioritised in early increments.

  • Investment is spread; failures detected sooner.

• Flexibility for Change

  • New/changed requirements can funnel into future increments with minimal rework.

Disadvantages of the Incremental Model

• Requires Sound Up-Front Planning

  • Correct partitioning of features is essential; otherwise integration pain rises.

• Complex Integration

  • Each new increment introduces potential architectural clashes.

• User Expectation Management

  • Early basic versions may be mis-perceived as “finished,” causing premature demands.

Types of Incremental Model

• Staged Incremental

  • Single team works on increments sequentially.

  • Emphasis on clear, up-front road-mapping of stages.

• Parallel Incremental

  • Multiple teams develop independent modules simultaneously.

  • Requires strong configuration-management and integration discipline.

Staged Incremental Model (Deep Dive)

• System divided into logical stages (core then enhancements).

• Each stage is completed, tested, and integrated before the next begins.

• House-building analogy: foundation → walls → roof → interior.

• Benefits

  • High control, predictable schedule if requirements are mostly stable.

Parallel Incremental Model (Deep Dive)

• Divide system into independent features.

• Assign each increment to a dedicated team; run work streams in parallel.

• Student-group analogy: everyone writes different report sections at the same time, then merge.

• Benefits

  • Shorter calendar time for large projects.

  • Better utilisation of large development staff.

• Challenges

  • Integration coupling, version control, interface contracts must be tightly managed.

Use-Case Suitability for Incremental Process

• When requirements are well-defined and unlikely to change radically per module.

• Long development timeline: manage complexity via smaller releases.

• Customer needs a quick Minimum Viable Product (MVP).

• Desire to deliver most important features first for early feedback.

• Not ideal if

  • Team is inexperienced (complex increment/integration management).

  • Project is extremely small (overhead outweighs benefit).

Worked Example – University Student Portal

Project Goals

• Secure login

• Course registration

• Grade viewing & GPA

• Online tuition fee payment

• Class schedules & notifications

Planned Increments (Staged Scenario)

1. User Authentication / Login

2. Course Registration

3. Grade Viewing

4. Fee Payment System

5. Class Schedule Viewer

Increment-by-Increment Snapshot

• Increment 1 — Objective: secure login & password recovery

  • Activities: requirement gathering, design login UI, implement secure login & reset

  • Delivery: working login + basic profile view

• Increment 2 — Objective: course registration

  • Activities: course search, prerequisite checks, cart add/drop

  • Delivery: students can register; also incorporated bug fixes from Increment 1

• Increment 3 — Objective: grade & GPA view

  • Activities: integrate exam DB, GPA calculation $\text{GPA}=\frac{\sum (\text{grade points}\times\text{credit hours})}{\sum \text{credit hours}}$

  • Delivery: functional grade-book section

• Increment 4 — Objective: online fee payment

  • Activities: payment-gateway integration, balance display, receipt generation

  • Delivery: secure payment subsystem

• Increment 5 — Objective: weekly class schedule + notifications

  • Activities: timetable API, calendar UI

  • Delivery: completes the planned scope; portal ready for production

Iterative Model (Contrast Model)

• Philosophy: "Build something → get feedback → improve → repeat".

• Whole system is built, reviewed, and refined across cycles, not one feature at a time.

• Workflow

  1. Initial planning; craft rudimentary version.

  2. Run full SDLC (design, code, test) on that version.

  3. Collect feedback.

  4. Produce improved iteration.

  5. Stop when quality/features satisfy stakeholders.

• Equation-style expression
  $\text{System}<em>{n+1}=\text{System}</em>n+\text{Improvements}(\text{Feedback}_n)$

Advantages

• Usable software emerges early & updates regularly.

• Scope/requirements can evolve with lower cost.

• Risks identified and mitigated incrementally.

• Well-suited for large, mission-critical or uncertain-requirement projects.

Disadvantages

• Requires more resources & tighter management.

• Architectural rework risk since not all requirements visible early.

• Overkill for small projects.

Note-Taking App Example (3 Iterations)

• Iteration 1: create/save plain notes → feedback: need delete/edit; UI dull.

• Iteration 2: add edit/delete, note title, basic color UI → feedback: search & categorization.

• Iteration 3: add search, subject categories, timestamps → future ideas: export PDF, cloud sync.

Incremental vs Iterative – Comparative Lens

• Main Focus

  • Incremental: add new pieces of functionality each time.

  • Iterative: refine entire system repeatedly.

• Development Style

  • Incremental: Once a module is “done,” usually minimal revisit except bug fixes.

  • Iterative: Same module may be redesigned/re-implemented multiple times.

• Feedback Usage

  • Incremental: shapes future modules.

  • Iterative: improves existing code.

• Risk Handling

  • Incremental: early delivery of key features reduces business risk.

  • Iterative: early prototyping uncovers design/usability issues.

• Analogy

  • Incremental: writing one paragraph, then the next, until essay finished.

  • Iterative: writing full rough essay, then revising multiple drafts.

• Best When …

  • Incremental: early release of key features is critical and requirements are segmentable.

  • Iterative: requirements fuzzy and heavy user feedback is mission-critical.

Ethical / Practical Perspectives

• Early increments hitting production can surface privacy/security concerns sooner (e.g., password encryption decisions in Increment 1).

• Stakeholder expectation management is crucial: communication about version scope avoids ethical misrepresentation of readiness.

Quick Risk Equation Reference (generic)

• $\text{Risk} = \text{Probability of Failure} \times \text{Impact of Failure}$

• Incremental projects often attack high-risk, high-impact areas first to drive this product down.

Key Takeaways

• Incremental ≠ Iterative; both can blend (many agile methods do).

• Each Increment → “mini-waterfall” with full SDLC steps.

• High-level requirements first; detailed ones gathered just in time.

• Two organisational flavours: Staged (sequential) and Parallel (simultaneous).

• Critical success factors

  • Competent integration strategy

  • Clear feature partitioning

  • Continuous stakeholder engagement & expectation management

"You don’t need to build the entire system at once. With the Incremental Model, you deliver value step by step — test, improve, and expand." – Lecture 04 summary quote.