Tag: waterfall model

A computer science project in a Nigerian university is judged on two things at once: the system you built, and the methodology you claim you followed to build it. Most students build first and pick a methodology afterwards, then spend the night before submission trying to reverse-engineer a data flow diagram out of code they already wrote. It shows, and panels notice.

Here is the comparison first, then the reasoning.

The four methodologies compared

The recommendation: for a solo undergraduate project that computerises an existing manual system — the most common shape of Nigerian CS project — choose SSADM. The runner-up, for a web or mobile application where the interface is the contribution, choose prototyping. Choose Agile only if you can produce real sprint evidence, and choose plain waterfall only if your department explicitly asks for it.

Why SSADM still wins in Nigerian departments

SSADM — Structured Systems Analysis and Design Methodology — was developed for UK government projects in the 1980s and has been quietly retired almost everywhere in industry. Nigerian computer science departments kept it, and the reason is pedagogical rather than nostalgic: SSADM forces you to produce exactly the artefacts a project examiner wants to mark.

Follow it and Chapter Three writes itself, because the methodology names its own sections:

1. Analysis of the existing system — how the records are kept now, gathered from interviews and observation at your case study organisation
2. Problems of the existing system — a numbered list, each of which your new system will address
3. Analysis of the proposed system — with its advantages stated against the numbered problems
4. High-level model — the top-level data flow diagram
5. Data flow diagrams — context diagram, then level 0, then level 1 for each major process
6. Entity relationship diagram and database design — with the normalised table structures
7. System specification — input design, output design, hardware and software requirements

That is a complete chapter, and every item is a figure or a table rather than paragraphs of theory. It is the single most efficient methodology choice available to a student who is short of time.

The one thing SSADM demands that students skip is the case study. SSADM assumes a real existing system somewhere — a school bursary that keeps fee records in a ledger, a clinic that files patient cards, a cooperative society that tracks contributions in an exercise book. You are expected to visit, interview staff and collect samples of their current forms. Those forms become your input design and belong in your appendix. Without them, your analysis of the existing system is invented, and a panel member who has supervised twenty of these projects will ask where your data came from.

When the waterfall model is the honest answer

Waterfall is the linear sequence: requirements, design, implementation, testing, deployment, maintenance. It is not the same thing as SSADM, though students often present them interchangeably. SSADM is a method with prescribed deliverables; waterfall is a lifecycle shape.

Choose waterfall when your requirements genuinely were fixed at the start and never changed — a simulation, an algorithm implementation, an embedded controller, anything where the specification came from a standard or from your supervisor rather than from a user. Its Chapter Three is thinner than SSADM’s, so you carry more of the weight with UML: use case diagram, class diagram, sequence diagrams for the two or three most important interactions, and an activity diagram for the main workflow.

Waterfall’s weakness in a project context is that it invites an obvious question at defence: “Your requirements never changed at all?” Have an answer ready. The strong version is that your scope was defined by a published specification or a supervisor brief and deliberately frozen so that testing could be exhaustive.

Agile: powerful, and usually a trap for a solo student

Agile is the honest description of how most students actually work — build a bit, show the supervisor, change it, build more. The trouble is that Agile is a team methodology with named ceremonies, and a panel that knows this will ask who your product owner was, how long your sprints were, and where the retrospective notes are.

You can defend Agile in an undergraduate project, but only with evidence:

• A product backlog written as user stories, in the “As a [role], I want [feature], so that [benefit]” format
• Sprints of a stated length — two weeks is standard — with the goal of each sprint recorded
• A git commit history whose dates line up with your sprint boundaries
• A named stakeholder who reviewed at least two increments, usually your supervisor or a staff member at the case organisation, with dates
• Screenshots of the system at the end of each sprint, showing genuine change

If you can produce all five, Agile makes an excellent project and your Chapter Three becomes a sprint-by-sprint narrative. If you are assembling that evidence retrospectively three weeks before submission, do not claim Agile. Claim prototyping instead, which is true and much easier to support.

Prototyping and RAD: the right choice for an app

Prototyping — building a working mock, showing it to users, refining, repeating — is legitimate, well documented in the literature, and a natural fit when the contribution of your project is the interface and the user experience rather than the data model.

It is the strongest choice for a mobile app, an e-commerce platform, a student portal, or anything where you iterated on screens. Your Chapter Three describes the iterations: what the first prototype contained, who reviewed it, what feedback it produced, what changed in the second, and so on, with a screenshot of each version. Three iterations is the usual minimum for a credible account.

Prototyping also handles the situation most students are genuinely in, which is not knowing exactly what the system should do until they have built something and shown it to someone. Distinguish clearly in your write-up between throwaway prototyping, where the mock is discarded and the real system built afterwards, and evolutionary prototyping, where the prototype becomes the system. Undergraduate projects are almost always the second, and saying so precisely is the kind of detail that impresses a panel.

Whichever you choose, Chapter Three still needs these

Methodology choice does not exempt you from the standard structure your department expects. Whatever you pick, Chapter Three must state the methodology and justify it against alternatives, describe your data-gathering for the analysis phase, present the system design artefacts, and specify the development environment — language, framework, database, and the hardware you tested on.

It also needs a testing subsection, and this is where computer science projects most often lose marks. Unit testing, integration testing and user acceptance testing should each be described, with a test case table showing the input, expected output, actual output and pass or fail for at least ten cases. Panels ask for this table by name.

The surrounding structure — research design, sources of data, system analysis, the sequence of subsections — follows the same conventions as any Nigerian project, set out in the guide to writing Chapter Three section by section. Software projects diverge in content, not in shape.

What goes in Chapter Four when you built a system

A software project has no questionnaire and no chi-square, so Chapter Four cannot be tables of respondent means. It becomes system implementation and results: the implementation environment, screenshots of each major module with an explanation of what the user does on each screen, the database tables as implemented, your test case results, and a performance discussion covering response times or query performance where relevant.

This is the same problem faced by engineering students whose data comes from a laboratory rather than a survey, and the structure that works for both is set out in the guide to writing Chapter Four when your project has no questionnaire. The generic template for survey-based Chapter Fours is in the pillar on data presentation, analysis and interpretation, which is worth reading for the interpretation style even though your tables will look different.

The methodology questions the panel will ask

Three of them come up in almost every computer science defence:

1. “Why did you choose this methodology?” Answer with a property of your project, not a property of the methodology. “Because my system replaces an existing manual record system whose current processes had to be analysed before they could be automated” beats “because SSADM is structured and reliable.”
2. “What were the alternatives and why did you reject them?” Name two, and reject each for a concrete reason. Agile rejected because you worked alone without a product owner; waterfall rejected because your requirements changed after the first user review.
3. “Show me where your methodology appears in your work.” Point to the artefact. The DFD for SSADM, the sprint log for Agile, the successive screenshots for prototyping. A methodology with no visible artefact was never actually used.

The full inventory of what panels ask, and how to answer each one, is in the guide to project defence questions in Nigeria.

Write the chapter around the system you actually built

The gap in most computer science projects is not the code. It is the twenty thousand words of documentation that must surround the code, written in departmental prose, consistent from chapter to chapter, and revised every time your supervisor returns a page.

Tesify drafts those chapters against your own topic, methodology and system design, keeps terminology and references consistent as the draft grows, and lets you rewrite a section after corrections without starting again. Your system stays yours; the documentation stops being the bottleneck.

Start your project on Tesify for free and build Chapter Three around the methodology you have chosen.

Frequently asked questions