Applying an Iterative Model
Career Paths
How to interpret this table?
You may choose this advanced topic if you like doing the things listed under “they usually do”, and you are fine with not doing the things listed under “they usually do not do”.
Alternatively, you may choose it if you are interested in applying for the listed job roles and want to practice work that is close to those roles.
| Job title | They usually do | They usually do NOT do | Real-life examples |
|---|---|---|---|
| Software Engineer (iteration-focused) | Improve the system through planned technical cycles, use test results and measurements to drive refinements, stabilize functionality over iterations | Apply Agile values or ceremonies, rely on stakeholder feedback loops, or reframe iteration as team rituals | Performance tuning projects, graphics-heavy systems, algorithm refinement |
Affected SDLC Phases
If a team chooses this advanced topic, the implementation, testing, and refinement phases are most strongly affected. Work proceeds in explicit technical iterations (build → test → improve). Planning defines iteration goals upfront. Feedback comes from measurements, tests, and observed system behavior, not from stakeholders.
Affected Tasks
Features are defined
Minimum Viable Product (MVP)
By the end of this task, your team has defined features with stable scope that will be improved iteratively. Features must not be redefined based on stakeholder feedback.
Technical Details
Feature definitions must assume stable requirements. Iteration is allowed only in how features are implemented, optimized, or stabilized.
Feature descriptions must include what is expected to improve across iterations (e.g. correctness, performance, usability clarity).
Quality
High-quality work clearly separates stable feature scope from iterative technical refinement.
Features are sorted by priority
Minimum Viable Product (MVP)
Your team sorts features once and keeps priorities stable throughout the semester.
Technical Details
Priority changes are not allowed unless a critical technical dependency is discovered. Any such change must be justified as a technical necessity, not feedback.
Quality
High-quality prioritization shows discipline and avoids iterative scope churn.
Features' cost and price are estimated
Minimum Viable Product (MVP)
Your team estimates cost assuming multiple technical iterations per feature.
Technical Details
Estimates must include iteration effort explicitly. Re-estimation due to learning is allowed, but scope must remain unchanged.
Quality
High-quality estimates reflect realistic iteration effort without redefining features.
System is working
Minimum Viable Product (MVP)
By the end of this task, your team demonstrates a working system that has gone through at least two clear technical iterations.
Technical Details
The demo must show:
- Initial working version
- Improved version after iteration (bug reduction, performance gain, clarity improvement)
Improvements must be based on test results or measurements, not stakeholder input.
Quality
High-quality demos make iterative technical improvement clearly visible and measurable.
Bug fixing
Minimum Viable Product (MVP)
During development, your team reports and fixes one bug as part of an iterative refinement cycle.
Technical Details
The bug must be discovered through testing or observation, not external feedback.
The fix must be followed by verification in a later iteration.
Quality
High-quality bug fixing shows structured iteration and verification.
User documentation
Minimum Viable Product (MVP)
User documentation reflects the final stabilized system state.
Technical Details
Documentation updates occur after iterations converge, not after every small change.
Quality
High-quality documentation reflects convergence and stability.
Developer documentation
Minimum Viable Product (MVP)
Developer documentation explains the iteration strategy and refinement criteria.
Technical Details
Documentation must explain:
- What triggered iterations
- What metrics or tests guided improvements
Quality
High-quality documentation makes the iterative model explicit and auditable.