Compare SDLC Methodologies and Select a Suitable Approach for a Sample Project

Learning objectives

After completing this tutorial, students should be able to:

• Explain the major software development methodologies.
• Compare methodologies based on flexibility, risk, cost, and delivery.
• Identify the strengths and limitations of different methodologies.
• Select a suitable methodology for a sample software project.
• Prepare a basic development plan for the selected methodology.

1. Introduction to SDLC Methodologies

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

A software development methodology defines how these activities are organized and performed. Choosing an appropriate methodology helps a development team manage time, resources, risks, requirements, and software quality.

Different projects require different approaches. A project with stable requirements may benefit from a sequential approach, while a project that requires frequent changes may benefit from iterative development.

2. Major Software Development Methodologies

2.1 Waterfall Model

The Waterfall Model follows a sequential development process. Each major phase is generally completed before the next phase begins.

Typical phases:

1. Requirements analysis
2. System design
3. Implementation and coding
4. Testing
5. Deployment
6. Maintenance

Advantages

• Easy to understand and manage.
• Provides clear documentation and milestones.
• Works well when requirements are stable.

Limitations

• Changes can be expensive after a phase is completed.
• Users may not see a working system until relatively late.
• Problems discovered late may require significant rework.

Example: A university needs a small software system with fully documented and approved requirements that are unlikely to change.

2.2 Agile Methodology

Agile is an adaptive approach that emphasizes collaboration, working software, frequent feedback, and responding to changing requirements. Scrum is one framework commonly used to implement Agile principles.

In Scrum, a team typically works in short iterations called sprints. At the end of a sprint, the team reviews the results and plans the next steps.

Advantages

• Adapts to changing requirements.
• Encourages regular stakeholder feedback.
• Allows useful features to be delivered incrementally.
• Helps identify problems earlier.

Limitations

• Requires regular communication and stakeholder participation.
• Uncontrolled changes can increase project scope.
• Time and cost may be difficult to predict without effective planning.

Example: A university attendance system is developed with teacher feedback after each working version.

2.3 Iterative and Incremental Model

In iterative development, an existing version is reviewed and improved through repeated cycles. In incremental development, new functions are added in manageable portions.

These concepts can be combined: each increment adds functionality, and feedback from testing or users helps refine subsequent versions.

Advantages

• Allows early development of core functions.
• Supports progressive testing and improvement.
• Breaks a large project into manageable modules.
• Helps accommodate feedback without rebuilding the entire system.

Limitations

• Requires good initial architecture and module planning.
• Integration between modules must be managed carefully.
• Repeated revisions can cause rework if requirements are poorly controlled.

Example: First develop login and course management, then attendance recording, and finally attendance reports.

2.4 Spiral Model

The Spiral Model organizes development into repeated cycles, with particular emphasis on identifying and managing risks.

Each cycle generally includes:

1. Planning objectives and alternatives.
2. Identifying and analyzing risks.
3. Developing and verifying the next version.
4. Evaluating results and planning the next cycle.

Advantages

• Provides explicit risk analysis.
• Supports prototyping and repeated evaluation.
• Can be useful for complex projects with significant uncertainty.

Limitations

• Can be costly and complex to manage.
• Requires expertise in risk assessment.
• May be excessive for small, low-risk projects.

Example: A university-wide attendance platform that integrates biometric devices, multiple campuses, and sensitive institutional systems.

2.5 Rapid Application Development (RAD)

Rapid Application Development emphasizes quick prototyping, reusable components, and frequent user evaluation to accelerate the creation of software.

Advantages

• Provides early demonstrations of screens and workflows.
• Encourages rapid feedback.
• Can reduce development time when the project and team are suitable.

Limitations

• Depends on timely user involvement.
• May be unsuitable for systems with complex technical or safety requirements.
• Rapid prototyping does not eliminate the need for testing, security, or documentation.

Example: A developer creates an early attendance-entry screen and asks teachers to evaluate it before finalizing the interface.

3. Comparison of SDLC Methodologies

The following table summarizes common differences among the methodologies. These are general tendencies rather than strict rules.

Criteria	Waterfall	Agile	Iterative / Incremental	Spiral	RAD
Requirement stability	Best with stable requirements	Supports changing requirements	Supports progressive refinement	Handles uncertainty and risk	Works best with reviewable requirements
Flexibility	Relatively low	High	High	High, with structured risk analysis	High for prototypes
User feedback	Often at defined milestones	Frequent	At each iteration or increment	At each cycle	Frequent
Risk management	Planned, but not necessarily repeated formally	Ongoing, depending on practice	Ongoing testing and review	Central focus	Depends on implementation
Delivery	Often later in the process	Frequent working releases	Progressive feature delivery	By development cycles	Rapid prototypes or builds
Management complexity	Relatively low	Moderate	Moderate	High	Moderate
Typical suitability	Fixed-scope projects	Projects with evolving requirements	Projects divisible into modules	Large, high-risk projects	Projects needing rapid prototypes

4. Sample Project: Student Attendance Management System

4.1 Project Overview

Project Name: Student Attendance Management System (SAMS)

Project Type: Web-based information system

Proposed Technology:

• Frontend: HTML, CSS, JavaScript, and JSP
• Application logic: Java
• Database connectivity: JDBC
• Database: Oracle Database
• Database operations: SQL and, where appropriate, stored procedures and triggers

4.2 Problem Statement

In a manual attendance process, teachers may record attendance on paper, calculate attendance percentages manually, and spend additional time preparing reports. Paper-based records may also be difficult to search, update, and maintain consistently.

The proposed system will provide a centralized web-based platform for managing student records, courses, sections, attendance sessions, and attendance reports.

4.3 Main Project Objectives

• Provide secure login for authorized users.
• Maintain student, teacher, course, and section information.
• Allow teachers to record and update attendance according to approved rules.
• Store attendance records in an Oracle database.
• Calculate student attendance percentages.
• Generate student-wise and course-wise reports.
• Reduce manual calculation and improve record retrieval.

4.4 Major System Modules

Module	Main Function
User Management	Manage login, user roles, and access permissions.
Student Management	Maintain student profiles and student identifiers.
Course and Section Management	Maintain course offerings, sections, and teacher assignments.
Attendance Recording	Record attendance for a selected course, section, and class session.
Attendance Reports	Display attendance records, percentages, and summaries.
Database Operations	Validate records and enforce relevant data-integrity rules.

5. Selecting a Suitable Methodology

Recommended Approach: Iterative and Incremental Development with Lightweight Agile Practices

This approach is appropriate for the sample Student Attendance Management System because the system contains several manageable modules, and the student developer can test and improve each module progressively.

For an academic project, the approach also supports regular demonstrations, documented progress, and feedback from the course teacher or intended users.

5.1 Reasons for Selecting This Approach

Selection Factor	Project Situation	Reason for Selection
Requirements	Some requirements may change after users review a working version.	Requirements can be refined between iterations.
Project Size	The system contains several independent modules.	Modules can be implemented progressively.
Development Time	The student has a limited semester.	Core functionality can be prioritized early.
Testing	Database integration and validation may reveal defects.	Each increment can be tested before adding more features.
User Feedback	Teachers can review forms and reports.	Feedback can guide subsequent improvements.
Academic Assessment	The project requires documentation and a final demonstration.	Each phase can produce reviewable deliverables.

5.2 Why Not Choose the Other Methodologies?

Waterfall: Waterfall may be suitable if every requirement is finalized in advance. However, it is less convenient when the student needs to revise attendance rules or report formats after receiving feedback.

Pure Agile framework: Agile principles can be helpful, but a small individual academic project may not require the full roles, meetings, and processes of a framework such as Scrum. Lightweight planning and feedback practices may be sufficient.

Spiral: A basic attendance system usually does not justify extensive formal risk-analysis cycles. Spiral may be more appropriate for a large, complex, high-risk institutional platform.

RAD: RAD can help create prototypes quickly, but the system still needs sound database design, access control, functional testing, and documentation. RAD is not a substitute for those activities.

6. Twelve-Week Development Plan

The following schedule shows how the selected approach can be applied to the project. The time allocation is illustrative and can be adjusted according to project complexity and course requirements.

Week	Development Activities	Expected Deliverable
Weeks 1–2	Investigate the existing attendance process, identify stakeholders, collect requirements, prepare use cases and an initial ERD, and design the database schema.	Requirements document, use cases, and initial database design.
Weeks 3–4	Build the JSP project structure, establish JDBC connectivity, implement login and logout, and create initial user-management functions.	Working system foundation and user management.
Weeks 5–6	Develop student, teacher, course, section, and enrollment functions. Test data relationships and constraints.	Student and course management modules.
Weeks 7–8	Develop attendance-entry forms, store attendance records, validate class dates, and prevent duplicate records for the same student and session.	Working attendance-recording module.
Weeks 9–10	Implement attendance percentage calculations, date-range filters, student-wise reports, and course-wise reports. Add appropriate database procedures or triggers if needed.	Reporting module and verified database operations.
Weeks 11–12	Conduct integration and system testing, correct defects, review usability, prepare user documentation, and demonstrate the final system.	Tested system, documentation, and final presentation.

Important: Testing should be conducted throughout development, not only in Weeks 11–12. Each module should be checked before it is integrated with the rest of the system.

7. Example of Iterative Improvement

Suppose the student completes the attendance-entry module and demonstrates it to a teacher.

Step 1: Initial Version

The teacher can select a course, mark students as present or absent, and save the attendance records in Oracle Database.

Step 2: User Feedback

The teacher requests a warning when a student's attendance falls below 75% and asks for a report covering a selected date range.

Step 3: Next Iteration

The student updates the requirements, implements attendance percentage calculations, adds the warning and date-range filter, and tests the updated features.

Step 4: Evaluation

The teacher reviews the updated version. Any remaining defects or improvement requests are documented and prioritized.

This example illustrates how iterative development allows a working system to be improved through feedback and repeated testing.

The 75% attendance threshold is an illustrative example. The actual threshold must follow the institution's approved attendance policy.

8. Sample Methodology Statement for the Project Proposal

The following section can be adapted and included in a formal project proposal.

Selected Methodology: Iterative and Incremental Development

The Student Attendance Management System will be developed using an iterative and incremental approach supported by lightweight Agile practices. The project will be divided into manageable modules, including user management, course and section management, attendance recording, and report generation. Each module will be designed, implemented, tested, and reviewed before the next increment is completed.

Feedback from the intended users will be considered to refine requirements and improve usability. System integration, database validation, security checks, and functional testing will be performed throughout development. This methodology is selected because it supports progressive delivery, early defect detection, manageable development tasks, and controlled adaptation to changing requirements while maintaining appropriate academic documentation.

9. Learning Activity

Answer the following questions to evaluate your understanding of SDLC methodologies.

Question 1

A university has finalized every system requirement and does not expect any major changes. Which methodology could be suitable?

1. Agile
2. Waterfall
3. Spiral

Show answer

Correct answer: b) Waterfall. Waterfall can work well when requirements are stable and clearly documented.

Question 2

A teacher requests additional features after reviewing a working attendance module. Which approach best supports progressive improvement?

1. Iterative and incremental development
2. Sequential development without revisions
3. Development without testing

Show answer

Correct answer: a) Iterative and incremental development. New functionality can be added and tested in subsequent increments.

Question 3

Why might the Spiral Model be unnecessary for a small academic prototype?

1. It does not allow testing.
2. It cannot support database systems.
3. Its risk-management overhead may be disproportionate to the project's scale.

Show answer

Correct answer: c). A small, low-risk project may not need the extensive risk-analysis activities associated with a full Spiral process.

10. Conclusion

Different SDLC methodologies serve different project needs. Waterfall provides a structured sequential process, Agile emphasizes adaptation and collaboration, iterative and incremental development supports progressive delivery, Spiral emphasizes risk management, and RAD emphasizes rapid prototyping.

For the sample Student Attendance Management System, iterative and incremental development with lightweight Agile practices provides a practical balance of flexibility, manageable implementation, regular testing, and academic documentation.

The final methodology should always be selected based on the project's requirements, scale, risks, development resources, and stakeholder expectations.

---

End of Tutorial

Course: System Analysis and Design