What Method Should an IT Capstone Use? A Worked SDLC Example (Philippines, 2026)

An IT or computer science capstone needs a named systems development life cycle (SDLC) model in Chapter 3, not just a list of tools — Waterfall, Agile/Scrum, and Iterative/Incremental are the three a Philippine panel most commonly expects to see argued for, not merely mentioned. This guide walks through choosing one and documenting it, with a worked example using Scrum for a mobile ordering app capstone.

What Is an SDLC Model, and Why Does My Capstone Need to Name One?

An SDLC model is the overall process your team follows to plan, build, test and deploy your capstone system — it answers “in what order and in what cycles did we do the work,” which is different from your programming language or your database choice. Panels ask for a named, justified SDLC model because it shows your team made a deliberate process decision rather than building ad hoc and writing the methodology chapter afterward to match whatever happened.

What Are the Three SDLC Models Most Philippine IT Capstones Choose From?

Waterfall moves through sequential phases — requirements, design, implementation, testing, deployment, maintenance — with each phase completed before the next begins. It suits a capstone with a fixed, fully known scope and little expected change (a straightforward inventory system for a single named business, for example). Agile, most often implemented through Scrum, builds the system in short iterations (sprints), with working increments demonstrated and requirements allowed to evolve. It suits a capstone where the client’s needs are expected to be refined as they see working versions (a mobile app for an end user group who will give feedback along the way). Iterative/Incremental sits between the two: the system is built in planned increments, each adding functionality, without the strict re-planning cadence of Scrum’s sprints — useful when scope is mostly known but the team wants to deliver and test core features before adding secondary ones.

Who Actually Created These Models, and What Do They Actually Say?

Winston W. Royce is credited with the first detailed diagram of what became known as the Waterfall model, in a 1970 paper on managing large software systems — notably, Royce’s own paper identified major flaws in a strictly sequential process and proposed additional iterative steps to mitigate them, so citing Royce as “the inventor of Waterfall” without that nuance is a common misattribution worth avoiding in your own literature review. The Agile Manifesto was written in 2001 by seventeen software practitioners meeting in Snowbird, Utah, including Kent Beck, Ward Cunningham, Martin Fowler, Jim Highsmith, Ken Schwaber and Jeff Sutherland among others. Scrum specifically was developed earlier and presented by Schwaber and Sutherland in a 1995 paper, predating the Agile Manifesto itself; it is now one of the most widely used Agile frameworks.

A Worked Example: Choosing Scrum for a Mobile Ordering App Capstone

Illustrative example, not a real project: a four-member BSIT team builds a mobile food-ordering app for a single local restaurant client. The client has a general idea of what they want but expects to see working screens before finalizing several features (payment method, loyalty points display, order-tracking notifications). The team’s Chapter 3 states: “This study adopted the Scrum framework, structured in two-week sprints across a 12-week development period, with the restaurant owner as product owner attending sprint review sessions at the end of each sprint to provide feedback and re-prioritize the product backlog.” This single paragraph names the model, the cadence, the stakeholder role, and the mechanism for requirement evolution — everything a panel needs to evaluate whether the choice fit the project.

How Do I Justify My SDLC Choice, Not Just Name It?

State explicitly why the alternative models were rejected for your specific project, in one or two sentences: “Waterfall was not selected because the client’s exact feature priorities were expected to change after seeing early prototypes, which a strictly sequential model does not accommodate without a formal change-request process.” A justification that only describes the chosen model, without addressing why the others were less suitable, reads as a template paragraph rather than a genuine team decision.

What Does My Chapter 3 Need Besides Naming the Model?

Beyond naming and justifying the model, document the specific artifacts your process actually produced: for Scrum, this typically means a product backlog, sprint backlogs, and a burndown or sprint-review log; for Waterfall, a requirements specification document, design documents, and a test plan completed before implementation began; for Iterative/Incremental, an increment plan showing which features shipped in which build. Screenshots or excerpts of these artifacts (a real sprint backlog table, an actual requirements document excerpt) belong in your appendix, and your Chapter 3 narrative should reference them by name.

Can I Combine Elements of Two Models?

Yes, and many real capstones do — a common hybrid is an Iterative structure with Scrum-style sprint reviews but without full Scrum ceremonies (no dedicated Scrum Master role, less formal daily stand-ups). If you use a hybrid, name it as such explicitly (“an iterative development approach incorporating Scrum-style sprint reviews”) rather than claiming pure Scrum when your team did not actually implement all of its defined roles and ceremonies — a panel member familiar with Scrum will ask about the Scrum Master and product backlog refinement process, and an answer that reveals those were skipped undermines a claim of having “used Scrum” in full.

How Is This Different From the Evaluation Instrument (ISO 25010, SUS, TAM) I Also Need?

The SDLC model describes how you built the system; an evaluation instrument like ISO 25010, the System Usability Scale, or the Technology Acceptance Model measures how well the finished system performs once it exists. Both belong in Chapter 3, but they answer different questions and should not be conflated — a panel asking “what is your SDLC” is not asking about your evaluation instrument, and vice versa.

What About the Spiral Model or Rapid Application Development (RAD)?

Both exist and are legitimate to name if they genuinely fit your project, though they appear less often in Philippine undergraduate capstones than Waterfall, Agile/Scrum, or Iterative/Incremental. The Spiral model, associated with Barry Boehm’s 1986 work, combines iterative development with an explicit risk-analysis phase repeated each cycle — a fit for a capstone with a genuinely novel or higher-risk technical component (a new algorithm, an unfamiliar hardware integration) where the team wants to formally re-assess risk before each build phase. RAD emphasizes rapid prototyping and heavy user involvement with a compressed timeline, sometimes a reasonable fit for a capstone building a straightforward CRUD-style system with a highly available client. Whichever you choose, the same rule applies: name it accurately, document its actual phases as your team implemented them, and do not claim a model’s full formal structure if your team’s actual process only borrowed some of its ideas.

What Common Mistakes Do Capstone Panels Flag About SDLC Sections?

Three recur often enough to check for directly. First, naming a model in Chapter 3 that the team’s actual development log does not support — a Gantt chart or commit history showing continuous, undifferentiated work does not match a claimed Scrum sprint structure, and a panel that asks to see the sprint backlog will notice the mismatch. Second, treating the SDLC section as boilerplate copied from a template with no project-specific detail — a methodology section that could describe any capstone, with no mention of the actual client, features, or team roles, reads as unconvincing regardless of which model is named. Third, confusing the SDLC model with the testing methodology (unit testing, user acceptance testing) — testing approach is a separate sub-section that sits inside whichever SDLC model you choose, not a substitute for naming one.

Where This Fits With the Rest of Your Thesis

Once your SDLC model is chosen, the evaluation instrument you pair it with is covered in our ISO 25010 vs SUS vs TAM capstone evaluation comparison, and if your team is still deciding between a software-project capstone and a research-based thesis track, software project thesis vs research thesis for BSIT/BSCS covers that earlier decision. For citation mechanics specific to a capstone with technical references, APA vs IEEE for a Philippine capstone project is worth checking before you finalize your reference list, and if your system already works but the documentation itself is the bottleneck, your capstone system works, the documentation is empty addresses exactly that gap. If your group is still unsure whether your project even counts as a capstone versus a thesis at your specific school, the general difference between a thesis and a capstone project guide clears that up before you get further into Chapter 3.

Where Tesify Fits

Once your team has chosen and can justify its SDLC model, Tesify turns that decision into a properly structured, well-argued Chapter 3 methodology section.

Frequently Asked Questions

Is Scrum always the right choice for a mobile app capstone?

Not automatically. Scrum fits well when your client or end users are available to give iterative feedback and your requirements are expected to evolve. If your scope is fully fixed and your client is unavailable for regular check-ins, Waterfall or Iterative/Incremental may be more realistic and easier to document honestly.

Did Winston Royce actually invent and recommend the Waterfall model?

Royce produced the first detailed diagram of the model in a 1970 paper, but his own paper identified major flaws in a strictly sequential process and proposed iterative modifications. Citing him as having straightforwardly recommended pure Waterfall is a common misattribution.

Can I claim I used Scrum if my team skipped the Scrum Master role?

No, not as pure Scrum. Name your process accurately as a Scrum-inspired or hybrid iterative approach if you did not implement Scrum’s defined roles and ceremonies in full, since a panel member familiar with Scrum will ask about the specific roles and artifacts.

What artifacts do I need to show for a Waterfall-based capstone?

Typically a requirements specification document completed before design began, design documents, and a test plan — evidence that each phase was substantially completed before the next started, which is the defining characteristic a panel will check for.

Is the SDLC model the same thing as a research design?

No. A research design (descriptive, developmental, experimental) describes your overall study approach; an SDLC model describes specifically how the software artifact within that study was built. Most IT capstones state both, since a developmental research design is common and it is then paired with a specific SDLC model for the build itself.

How many sprints is typical for a capstone using Scrum?

There is no fixed number — it depends on your project timeline and scope. Capstones commonly run four to eight two-week sprints across a semester, but confirm your own program’s expected development timeline and adjust sprint count and length accordingly.

Do all four team members need a defined Scrum role?

Most capstone teams assign roles informally rather than a strict one-person-per-role Scrum structure, since a four-person team is smaller than most professional Scrum teams. State clearly in Chapter 3 how roles were actually distributed among your members, even if one person held more than one responsibility.

Can I change my SDLC model partway through the project if it is not working?

Yes, and if you do, document the change and the reason for it explicitly rather than presenting your final Chapter 3 as if the eventual model had been used from the start — a panel that later sees a development log inconsistent with a tidy single-model narrative will ask about the discrepancy.