Traditional SDLC Models: Pros, Cons & When to Use Them

Main ideas and lessons (by topic)

1) Documentation across SDLC phases (what’s produced and why)

The speaker explains that different SDLC phases produce different kinds of documentation—some phases include documentation, others may not.

Key documentation artifacts

• Project / Project Frameworks (project overview)

  • An official starting document showing:
    • Authorization/permission to start work
    • What is known about the project
    • The project’s purpose (main objective)
    • The general scope

• Project Plan (timeline + resources)

  • A preliminary plan for “what you’re doing,” not a complete plan for the entire project at the outset
  • Includes:
    • Initial/estimated timeline (also reflected in budget)
    • Resource distribution (who/what resources are assigned to tasks)
  • May mention additional planning files depending on the chosen model.

• Customer Requirements Specification (CRS)

  • Requirements provided by the client in business language
  • Typically not yet technical
  • Contains requirements in a general sense (“this is what you need”)
  • Requires client confirmation
  • Process:
    • After meeting the client and creating the CRS, send it by email
    • Client signs it and returns it

• Requirement Analysis

  • Next step after CRS
  • Produces technical requirement documentation (speaker references an SRS-like phase/name)
  • Output remains centered on what you will work with through later phases

• Software Design Documentation

  • High-Level Design (HLD) / architecture design
    • Explains the system architecture at a complete conceptual level
    • Includes component-level explanation of what you will be dealing with
    • Produces architecture diagrams and/or UML diagrams
  • Low-Level Design (LLD)
    • More detailed “how” details, including:
      • Data/information handling
      • Database details (e.g., schema)
      • Memory map / data structures
      • Detailed UML diagrams (speaker references LLD-specific content)

• Implementation / Code stage

  • Produces source code
  • Includes a professional code commenting/documentation workflow:
    • The term “docxin/docxin style” is used for a standardized way to write code comments
    • After code is complete, a tool runs over those comments
    • The tool compiles comments into a generated documentation/PDF

• API description

  • Explains how components connect and exchange data:
    • Endpoints
    • How frontend/backend interact
    • Request/response data flow between the “real world” and system layers
  • Includes the response shape as defined by requirements
  • If implementation reveals a mismatch with the requested response format:
    • update the implementation and document what changed

• Testing artifacts

  • Test Plan
    • Covers:
      • What will be tested (features)
      • Who performs testing
      • What tools will be used
      • Overall testing strategy
  • Test Cases
    • More detailed than the test plan
    • Step-by-step verification instructions for testers
  • Bug / Test Report (BAG Report mentioned)
    • If a test is invalid/not passing, it becomes a “bug” report describing the failure

• Deployment / release documentation

  • Plumbing Plan (launch/deployment plan)
    • How to deploy full stack:
      • Upload data
      • Build servers
      • Flashing process (if needed)
      • Backup/rollback plan if something fails during runtime
  • Release Notes
    • What this release contains:
      • New features
      • Problems solved vs. the old version
  • User Manual
    • Needed so users can understand and operate the software

• Operational / change management

  • Logs (Echo Log / log tracking)
    • Tracks events, errors, timestamps, and where/what caused issues
  • Change Request
    • Formal client-requested changes after an initial version

Lesson conveyed: There is a structured set of documents for each phase; you shouldn’t panic about “too much documentation,” but you should know what to read, what’s important, and what can be ignored.

---

2) Traditional SDLC model: Waterfall Model (pros/cons/when to use)

The speaker treats Waterfall as the baseline sequential SDLC model.

Structure / defining rule

Phases proceed in order:

1. Requirements (requirements definition and planning)
2. Design (system/architecture and then detailed design)
3. Implementation / Code
4. Verification / Testing
5. Maintenance

• No overlapping work: a later phase starts only after the previous phase is fully completed.

History/source mentioned

• W. Royce is identified as associated with Waterfall and its popular form.
  • The speaker calls him “Aston Royce,” but the referenced person is Royce.

Problems (disadvantages) emphasized

• No going back easily
  • If you discover issues or missed requirements later, you can’t revise earlier steps without redoing major work (potentially from the beginning).
• Late testing (“no early test”)
  • Testing occurs only at the end of the sequential chain.
  • Problems are discovered too late, making fixes costly.
• Customer not involved until the end
  • The customer/professor sees results only after deployment (potentially years later), increasing the risk that delivered output won’t match expectations.
• Example use case in education
  • University timelines/professors demand delivery; if requirements change, students may have to redo the entire project.

Advantages (pros) emphasized

• Easy to understand and manage
  • Sequential structure simplifies management and coordination
  • Dependencies are clear; phases are handled one at a time
• Works well for simple projects
  • When requirements are stable and the scope is small
• Short timeframes
  • Speaker mentions “two or three months”
• “Good customer” notion
  • Interpreted as the customer does not need frequent check-ins during development; they review near the end.

When to use Waterfall (explicitly stated)

Use Waterfall when:

• The project is easy/simple
• The timeframe is short
• Requirements are unlikely to change significantly
• Customer involvement during the lifecycle is not required frequently (customer sees it at the end)

---

3) Traditional SDLC model: V-Model (pros/cons/when to use)

The speaker presents V-Model as an improvement/extension of Waterfall, mainly to address late testing.

Core idea / how V-Model differs

• V-Model is described as an extension of Waterfall that:
  • Keeps the sequential nature of development/verification but
  • connects each development stage to a corresponding testing stage
• Testing is planned earlier:
  • Test case/test plan preparation occurs before or alongside implementation, not only after everything is coded.

V-Model stage breakdown (as described)

• Left side (requirements/design):

  • Requirements
  • System analysis / system design
    • architecture design
    • model/UML design
  • Coding

• Right side (verification/testing mapped to earlier work):

  • Unit test
  • Integration test
  • System test
  • Acceptance test

Problems from Waterfall that V-Model aims to solve

• Waterfall postponed testing to the end → V-Model reduces this by:
  • Structuring verification per development level
  • Doing acceptance-related test planning earlier (conceptually tied to earlier design/requirements)

Advantages (pros) emphasized

• Earlier verification relative to Waterfall
  • “Good early listeners/faster than Waterfall in terms of time”
  • Testing is more distributed and planned earlier
• More systematic mapping between requirements/design and tests

Disadvantages (cons) emphasized

• Customer still doesn’t see anything until the end
  • Even if tests are earlier, visible delivered progress to customer is delayed.
• Not flexible with requirement changes
  • If requirements change midstream (example: “doctor told you to change it”):
    • you may need to redo from the beginning / large rework.

When to use V-Model (explicitly stated)

Use V-Model when:

• You need fast delivery, and testing should be emphasized earlier
• The project is still relatively simple
• You expect limited requirement change risk

---

Speakers / sources featured (as mentioned)

• W. Royce (referenced as the inventor/associated figure for the Waterfall approach; spoken as “Aston Royce,” likely referring to Winston W. Royce).