SDLC and Software Development Methodology: Waterfall Model

SDLC and Software Development Methodology: Waterfall Model

Learning Objectives

After studying this lesson, students should be able to explain SDLC, describe the phases of the Waterfall Model, identify the deliverables of each phase, and evaluate the advantages and disadvantages of Waterfall for different software projects.

1. Introduction to SDLC

Software Development Life Cycle (SDLC) is a structured process used to plan, analyze, design, develop, test, deploy, and maintain a software system.

SDLC provides a systematic approach to software development so that the final product meets user requirements, satisfies quality standards, and is completed within the planned time and budget.

For example, if a university wants to develop a Student Attendance Management System, the development team must understand the requirements, design the system, write the code, test the software, and deploy it for teachers and students.

Objectives of SDLC

• Understand and document user requirements.
• Develop reliable and maintainable software.
• Control development costs and schedules.
• Reduce technical risks and development errors.
• Ensure software quality through systematic testing.
• Make software maintenance and future improvements easier.

2. Phases of SDLC

Phase 1: Planning and Feasibility Study

The project team identifies the problem, defines project objectives, estimates costs and resources, and evaluates whether the project is feasible.

Example: A university decides to replace paper-based attendance records with a digital system.

Phase 2: Requirements Analysis

Analysts collect and document functional and non-functional requirements from users and stakeholders.

Example: Teachers need to record attendance, students need to view attendance records, and administrators need to generate reports.

Phase 3: System Design

The team prepares the system architecture, database schema, user interfaces, UML diagrams, and module specifications.

Phase 4: Implementation (Coding)

Developers translate the design into executable code using programming languages, frameworks, and database technologies.

Phase 5: Testing

The team tests the software to identify defects and verify that the system satisfies its requirements. Testing may include unit, integration, system, and acceptance testing.

Phase 6: Deployment

The software is installed and made available to users. Activities may include server configuration, database setup, data migration, and user training.

Phase 7: Maintenance

The team fixes defects, improves performance, applies security updates, and adapts the software to changing requirements.

3. Software Development Methodology

A software development methodology is an organized approach that defines how a development team plans, designs, builds, tests, and delivers software.

Common software development methodologies include:

• Waterfall Model
• V-Model
• Iterative Model
• Incremental Model
• Prototyping Model
• Spiral Model
• Agile Methodology
• DevOps-oriented development

Each methodology has its own strengths and limitations. The selection depends on requirements, project risks, budget, schedule, complexity, and user involvement.

4. Waterfall Model

4.1 Definition

The Waterfall Model is a traditional software development methodology in which development activities are organized into sequential phases. Each phase is generally completed and reviewed before the next phase begins.

It is called the Waterfall Model because the process flows downward from one phase to another, similar to water flowing over a series of steps.

The model emphasizes upfront planning, clearly documented requirements, formal reviews, and controlled changes.

4.2 Waterfall Model Diagram

1. Planning and Feasibility

↓

2. Requirements Analysis

↓

3. System Design

↓

4. Implementation (Coding)

↓

5. Testing

↓

6. Deployment

↓

7. Maintenance

Figure: Sequential flow of the Waterfall Model.

In the traditional Waterfall approach, phases follow a predefined sequence. Earlier phases can be revisited when necessary, but doing so may require additional time, approval, and rework.

4.3 Phase 1: Planning and Feasibility Study

The project manager and stakeholders establish the project scope, objectives, budget, schedule, and resource requirements.

Key activities:

• Define the problem and project objectives.
• Identify stakeholders.
• Estimate costs, time, and resources.
• Evaluate project feasibility.
• Prepare the initial project plan.

Deliverable: Project proposal or feasibility report.

4.4 Phase 2: Requirements Analysis

The analyst collects and documents the requirements of students, teachers, administrators, and other stakeholders.

Functional requirements describe what the system must do. Examples include:

• Teachers can log in securely.
• Teachers can record attendance by course and section.
• Students can view their attendance records.
• Administrators can generate attendance reports.

Non-functional requirements describe the expected quality and constraints of the system, such as security, reliability, usability, and response time.

Deliverable: Software Requirements Specification (SRS).

4.5 Phase 3: System Design

The development team translates requirements into a technical design. Activities may include:

• System architecture design.
• Database design.
• User-interface design.
• UML diagrams.
• Module and component design.
• Security and access-control design.

For example, the attendance database may contain STUDENT, COURSE, SECTION, ENROLLMENT, and ATTENDANCE tables.

Deliverable: System design document, database schema, and interface specifications.

4.6 Phase 4: Implementation (Coding)

Developers implement the approved design using the selected technologies.

A university attendance system could use:

• Frontend: HTML, CSS, and JavaScript.
• Backend: Java and JSP.
• Database: Oracle Database.
• Database connectivity: JDBC.

Developers implement authentication, attendance entry, attendance calculation, and report-generation features.

Deliverable: Implemented software modules and source code.

4.7 Phase 5: Testing

The testing team verifies whether the implemented software satisfies the documented requirements.

Testing Type	Purpose	Example
Unit Testing	Test individual components.	Verify attendance calculation.
Integration Testing	Test interactions between modules.	Verify that attendance records save correctly to Oracle.
System Testing	Test the complete system.	Verify the full attendance workflow.
Acceptance Testing	Confirm that user needs are met.	Teachers verify the attendance process.

Defects are documented and corrected. Major problems may require the team to revisit earlier requirements or design decisions.

Deliverable: Test reports and a verified software build.

4.8 Phase 6: Deployment

After successful testing and approval, the software is installed in the production environment.

Deployment activities may include server configuration, database setup, user account creation, data migration, and user training.

Deliverable: Operational software available to its intended users.

4.9 Phase 7: Maintenance

After deployment, the team supports the system throughout its operational life.

• Corrective maintenance: Fixing defects.
• Adaptive maintenance: Adapting to new environments or regulations.
• Perfective maintenance: Improving performance or usability.
• Preventive maintenance: Reducing the likelihood of future problems.

For example, the university may request a feature that automatically alerts students when their attendance falls below a specified threshold.

Deliverable: Software updates, patches, and maintenance documentation.

5. Characteristics of the Waterfall Model

1. Sequential development: Activities generally follow a predefined order.
2. Defined requirements: Requirements should be sufficiently clear before detailed design and implementation.
3. Documentation-oriented: Major phases produce documents or formal deliverables.
4. Phase reviews: Outputs are reviewed before moving forward.
5. Controlled changes: Changes to approved requirements may require formal review and rework.
6. Planned testing: Testing is commonly emphasized as a distinct phase, although quality assurance should begin earlier.
7. Milestone-based management: Progress is tracked through phase completion and approval.

6. Advantages of the Waterfall Model

• Easy to understand and manage.
• Clear phases, responsibilities, and deliverables.
• Supports detailed documentation.
• Facilitates milestone-based progress tracking.
• Suitable when requirements are stable and well understood.
• Useful where formal approvals and traceability are important.

7. Disadvantages of the Waterfall Model

• Changes can be expensive after requirements and design have been approved.
• Working software may not be available until relatively late.
• Users may discover misunderstood requirements during testing.
• Late discovery of major defects can cause substantial rework.
• It offers less flexibility when business needs change frequently.
• It is less suitable for projects with high uncertainty or rapidly evolving requirements.

8. When Should the Waterfall Model Be Used?

The Waterfall Model may be appropriate when:

• Requirements are clear, stable, and well documented.
• The technology and architecture are well understood.
• The project has a clearly defined scope.
• Formal documentation and approvals are necessary.
• Changes are expected to be limited.
• The project team can plan the work reliably in advance.

It may be less appropriate when requirements are uncertain, users need frequent releases, or experimentation is essential.

9. Practical Case Study: Student Attendance Management System

Scenario: A university wants to replace its paper-based attendance process with a web-based system.

1. Planning: Approve the project scope, budget, schedule, and development resources.
2. Requirements: Finalize attendance entry, course-wise records, role-based access, and reports with stakeholders.
3. Design: Prepare the Oracle database schema, JSP page structure, access controls, and system architecture.
4. Coding: Develop login, attendance entry, attendance calculation, and reporting modules.
5. Testing: Verify login permissions, duplicate attendance prevention, data accuracy, and report generation.
6. Deployment: Install the application on the university server and train teachers and administrators.
7. Maintenance: Fix operational issues, update security controls, and implement approved changes.

Important Observation: If the university changes attendance rules after the database and application design are approved, the team may need to revise requirements, design, code, and tests. This illustrates why changes can be costly in a traditional Waterfall project.

10. Waterfall Model vs. Agile Methodology

Criteria	Waterfall	Agile
Development Approach	Sequential phases.	Iterative and incremental.
Requirements	Preferably stable upfront.	Can evolve during development.
Customer Feedback	Often concentrated around reviews and milestones.	Frequent throughout development.
Delivery	Commonly a major release after planned phases.	Frequent working increments.
Change Management	Formal and potentially costly.	Designed to accommodate change.
Documentation	Often extensive and phase-based.	Documentation tailored to project needs.
Best Suited For	Stable, well-defined projects.	Projects requiring learning and frequent feedback.

Neither methodology is universally superior. The appropriate choice depends on project requirements, risks, constraints, and stakeholder expectations.

11. Common Misconceptions About Waterfall

• Misconception: Once a phase is completed, it can never be revisited.
  Correction: Earlier phases can be revisited, but doing so may require approval, additional time, and rework.
• Misconception: Testing only means running the software after coding.
  Correction: Although testing is commonly a dedicated phase, test planning, reviews, and quality assurance should begin earlier.
• Misconception: Waterfall is suitable for every large project.
  Correction: Requirement stability, uncertainty, risk, and change frequency matter as well as project size.
• Misconception: Agile does not require planning or documentation.
  Correction: Agile projects also need planning, documentation, testing, and control; they organize these activities differently.

12. Review Questions

1. What does SDLC stand for?
2. What is a software development methodology?
3. Describe the seven phases of the Waterfall Model.
4. What is the purpose of an SRS document?
5. Differentiate between functional and non-functional requirements with examples.
6. Explain two advantages and three disadvantages of the Waterfall Model.
7. Why can late requirement changes be costly in Waterfall?
8. Compare the Waterfall Model and Agile methodology.

13. Classroom Activity / Assignment

Scenario: A university plans to develop an online course registration system.

1. Identify the seven SDLC phases for this project.
2. Write five functional and three non-functional requirements.
3. Identify the main deliverable of each Waterfall phase.
4. Explain two advantages and three disadvantages of using Waterfall for this project.
5. Suppose the university changes its registration policy during implementation. Explain how the Waterfall team should handle the change.

Expected Learning Outcome: Students should be able to explain SDLC, describe the Waterfall phases and deliverables, evaluate its strengths and weaknesses, and select a development methodology based on project characteristics.