SDLC Models - Plan and Document Perspective

The early days of software engineering were characterized by a simple approach: write code, see if it works, and fix problems as they arose. As software grew more complex, structured methodologies emerged to bring predictability and control to the development process.

The Beginning: Build and Fix

Before formal methodologies existed, software development followed what we now call the "build and fix" model:

How It Worked:

1. Write code for the desired functionality
2. Run the software and observe results
3. Fix any bugs or issues discovered
4. Repeat until satisfied

Characteristics:

• No upfront planning or design
• Rapid initial progress
• No clear endpoint—projects continued indefinitely
• High risk of scope creep and missed deadlines
• Poor scalability for complex projects

Why It Was Problematic:

• No clear requirements meant developers built what they thought was needed
• No design meant architecture decisions were made ad-hoc
• No testing strategy meant bugs were found by users, not QA
• No maintenance plan meant software degraded over time

Software Lifecycle Overview

Modern software engineering recognizes that software goes through distinct phases:

This lifecycle forms the foundation for all structured development methodologies.

What Is a Software Development Lifecycle Model?

A software development lifecycle (SDLC) model is a framework that defines:

• The phases of development and their sequence
• The activities performed in each phase
• The deliverables produced by each phase
• The transitions between phases
• The feedback loops for correction and improvement

Models help teams:

• Plan and estimate effort and timeline
• Coordinate work across team members
• Communicate progress to stakeholders
• Manage risk through structured approaches

The Waterfall Model

The Waterfall model, introduced by Winston Royce in 1970, is the classic plan-and-document approach:

Core Principles

Plan and Document:

• Extensive documentation at each phase
• Formal sign-offs between phases
• Detailed specifications before coding begins

Sequential Progression:

• Each phase must be completed before the next begins
• No returning to previous phases (in theory)
• Clear milestones and deliverables

Phase-by-Phase

1. Requirements Analysis

   • Document all functional and non-functional requirements
   • Create use cases and user stories
   • Obtain stakeholder approval

2. System Design

   • Define system architecture
   • Design data structures and interfaces
   • Create technical specifications

3. Implementation

   • Write code according to specifications
   • Integrate components
   • Produce working software

4. Testing

   • Verify software against requirements
   • Find and document defects
   • Ensure quality standards are met

5. Deployment and Maintenance

   • Release software to production
   • Provide ongoing support
   • Implement changes and fixes

Advantages

Drawbacks and Criticisms

Costly Changes:

• Modifying requirements after the design phase is expensive
• Late-discovered issues require restarting phases
• Inflexible to evolving needs

Client Communication Challenges:

• Clients may not know what they want until they see working software
• Long timelines mean clients can't preview progress
• Misunderstandings aren't discovered until testing

Developer Usability Gaps:

• Designers may not understand real user needs
• Built features may not match actual user workflows
• Technical decisions may not align with user capabilities

Long Timelines:

• Months or years before any usable software
• High risk of market changes during development
• Delayed feedback means delayed corrections

The "50% Problem":

"I have been a participant in a very large number of studies... in which it was estimated that from 1/3 to 1/2 of the money time and trouble... was spent on documentation, which was only occasionally read and rarely used." — Winston Royce, 1970

The Prototype Model

When requirements are unclear, the Prototype model offers an alternative:

When to Use:

• Requirements are poorly understood
• Users have difficulty articulating needs
• High-risk or innovative projects
• User interface design is critical

The Prototyping Process

Types of Prototypes

Advantages

• Reduced Risk: Catches misunderstandings early
• Better Requirements: Users see and react to actual functionality
• User Involvement: Continuous feedback improves buy-in
• Faster Clarification: Ambiguities resolved quickly

Disadvantages

• Scope Creep: Users keep requesting changes
• Throwaway Code: Rapid prototypes may be poorly designed
• Client Expectations: Users may expect prototype quality in production
• Incomplete Solutions: Focus on appearance over substance

The Spiral Model

The Spiral model, introduced by Barry Boehm in 1988, combines planning with risk management:

Core Concept

Each iteration (or "spiral") produces a working prototype at increasing levels of fidelity, with risk assessment at each cycle.

Four Quadrants per Spiral

1. Determine Objectives: What are we building? What are the constraints?
2. Identify Risks: What could go wrong? How do we mitigate?
3. Develop and Validate: Build and test the current iteration
4. Plan Next Phase: What do we do in the next spiral?

Advantages

• Explicit Risk Management: Risks are identified and addressed
• Flexibility: Scope can evolve across iterations
• Customer Involvement: Continuous feedback at each spiral
• Large Project Suitability: Scales well for complex systems

Disadvantages

• Complexity: Requires expertise in risk analysis
• Longer Timelines: Multiple iterations extend schedules
• Contract Challenges: Difficult to define fixed-price contracts
• Overkill for Small Projects: Heavyweight approach for simple systems

Comparing Plan and Document Models

When to Use Each Model

Choose Waterfall when:

• Requirements are well-understood and stable
• The technology is well-known
• The project is small to medium
• Contracts require fixed scope

Choose Prototype when:

• Requirements are unclear or evolving
• User interface is critical
• User needs are difficult to articulate
• Exploratory development is needed

Choose Spiral when:

• Projects are large and complex
• Significant risks exist
• Requirements may change
• Significant investment requires risk mitigation

Summary

The plan and document perspective encompasses several structured approaches to software development:

• Waterfall: Classic sequential model with extensive documentation
• Prototype: Iterative approach for exploring requirements through working models
• Spiral: Risk-driven iterative model combining planning with flexibility

Each model addresses different project characteristics, and modern practice often blends elements from multiple models to suit specific needs.