Suitable SDLC Model for the Online Library Management System

The most suitable Software Development Life Cycle (SDLC) model for this project is the Incremental Model.

Justification

The university librarian wants the system to be delivered in phases, allowing users to provide feedback after each release. The Incremental Model develops and delivers the software in multiple increments, enabling improvements based on user feedback before the next release.

Advantages of the Incremental Model

1. Early Delivery of Software:
The system is delivered in small functional releases, allowing users to start using important features earlier.

2. Easy Incorporation of User Feedback:
Feedback received after each release can be incorporated into subsequent increments, resulting in a system that better meets user requirements.

Conclusion

The Incremental Model is the best choice because it supports phased delivery, continuous user feedback, and gradual enhancement of the Online Library Management System.

The Software Development Life Cycle (SDLC) is a step-by-step process used to design, build, and deliver software. It helps teams plan, control, and manage the entire project from start to finish. Each phase has a clear goal and deliverable that moves the project forward.

1. Planning

In this phase, the project team defines the scope, goals, budget, and timeline. They analyze whether the project is possible and identify risks early. This phase sets the foundation for the whole project.

Example: A company decides to build an online shopping app. The team plans the features, cost, and deadline before starting work.

2. Requirement Analysis

The team collects and studies what the users and business need. They document all functional and non-functional requirements so developers know exactly what to build.

Example: The team asks users what they want in the shopping app, such as payment options, product search, and order tracking.

3. Design

This phase turns requirements into a blueprint. Architects create system designs, database models, and user interface layouts. It acts as a guide for the coding phase.

Example: Designers create wireframes showing how the app screens will look, and architects plan the database tables for users and products.

4. Implementation (Coding)

Developers write the actual code based on the design documents. This is the phase where the software is built. Developers follow coding standards and best practices.

Example: Developers write code in Java or Python to build the login page, product catalog, and payment gateway.

5. Testing

The testing team checks the software for bugs and errors. They run test cases to verify that the application meets requirements and works correctly. Different types of testing like unit, integration, and system testing are performed.

Example: Testers check if a user can add items to cart, make payment, and receive an order confirmation email.

6. Deployment

Once testing is complete, the software is released to the live environment for users. This may be done all at once or in stages depending on the strategy.

Example: The shopping app is launched on the Play Store and App Store for customers to download and use.

7. Maintenance

After release, the team monitors the software, fixes bugs, and adds new features. This phase continues throughout the life of the software to keep it running smoothly.

Example: The team releases updates to fix a login bug and adds a new discount coupon feature based on user feedback.

Summary Table:

To develop and deploy the software system as quickly as possible, I would choose the Incremental Approach over the Waterfall Approach. Here’s why:

1. Faster Delivery & Early Value:

   • Incremental Approach: Delivers software in smaller, working parts, allowing early use and feedback.
   • Waterfall Approach: Requires full completion of all phases before any part is usable, leading to long waiting times.

2. Flexibility & Adaptability:

   • Incremental Approach: Allows changes and improvements throughout development.
   • Waterfall Approach: Changes are difficult and costly once requirements are set.

3. Risk Management:

   • Incremental Approach: Issues are detected and fixed early, reducing risks.
   • Waterfall Approach: Risks are identified late, leading to costly rework.

4. User Feedback:

   • Incremental Approach: Users can give feedback during development to refine the system.
   • Waterfall Approach: Feedback comes only after full development, risking mismatches with user needs.

5. Resource Allocation:

   • Incremental Approach: Resources are managed efficiently, focusing on smaller increments.
   • Waterfall Approach: All resources are tied up until full system completion.

Software Development Life Cycle (SDLC)

The Software Development Life Cycle (SDLC) is a structured process used to design, develop, test, deploy, and maintain software systems. It provides a systematic approach to building high-quality software that meets user requirements, stays within budget, and is delivered on time.

Main Phases of SDLC

1) Requirement Analysis

In this phase, user needs and system requirements are collected and analyzed to understand what the software should do.

2) System Design

Based on the requirements, the overall system architecture, database design, and technical specifications are prepared.

3) Implementation (Coding)

The actual software is developed by writing code according to the design specifications.

4) Testing

The software is tested to identify and fix bugs and ensure it works correctly and meets user expectations.

5) Deployment

After successful testing, the software is released and deployed in a real user environment.

6) Maintenance

Once deployed, the software is maintained through updates, bug fixes, and enhancements based on user feedback.

Preferred SDLC Model: Agile vs Waterfall

Between Agile and Waterfall SDLC models, Agile is generally preferred in modern software development because it is flexible, customer-focused, and adapts easily to changes.

Why Agile is Preferred over Waterfall

• Flexibility: Agile allows changes in requirements even at later stages, while Waterfall does not.
• Customer Involvement: Customers are involved throughout the development process in Agile.
• Early Delivery: Agile delivers working software in small iterations.
• Risk Reduction: Problems are identified early through continuous testing and feedback.

Example of Agile Model

Developing a mobile banking app is suitable for Agile because features like UI design, security, and payment options may change based on user feedback.

When Waterfall is Suitable

Waterfall is suitable when requirements are fixed and well-defined, such as developing payroll software for a government organization.

Platform Independent Software

Platform independent software is software that can run on different operating systems or hardware platforms without any modification. Such software does not depend on a specific OS or hardware architecture.

Key Features of Platform Independent Software:

• Runs on multiple platforms such as Windows, Linux, and macOS
• Written once and executed anywhere
• Uses an intermediate layer like Virtual Machine or Interpreter

Example:

Java is a common example of platform independent software. Java programs are compiled into bytecode, which can run on any system that has a Java Virtual Machine (JVM).

Real-World Example:

A Java-based banking application can run on Windows servers, Linux servers, and cloud platforms without changing the source code.

System Software

System software is a type of software that manages and controls computer hardware and provides a platform for application software to run.

It works directly with the hardware and helps operate the computer system.

Examples: Operating System, Device Driver, Compiler, Utility Programs

Application Software

Application software is software designed to perform specific tasks for users.

It runs on top of system software and helps users complete different activities.

Examples: Microsoft Word, Google Chrome, VLC Media Player, Adobe Photoshop

Difference Between System Software and Application Software

Software Development Life Cycle (SDLC)

Software Development Life Cycle (SDLC) is a structured process used to design, develop, test, deploy, and maintain software systems efficiently and systematically.

The main goal of SDLC is to produce high-quality software within time and budget.

Main Phases of SDLC

1. Requirement Analysis
2. System Design
3. Implementation (Coding)
4. Testing
5. Deployment
6. Maintenance

1. Requirement Analysis

• In this phase, the requirements of the users and organization are collected and analyzed.
• Developers, analysts, and clients discuss system objectives, features, and constraints.

Purpose: Understand what the software should do.

2. System Design

• In this phase, the overall structure and architecture of the software are designed.
• Database design, interface design, system flow, and technology selection are prepared.

Purpose: Create a blueprint for software development.

3. Implementation (Coding)

• In this phase, programmers write the actual source code according to the design specifications.
• Different modules and functionalities are developed.

Purpose: Convert design into working software.

4. Testing

• The developed software is tested to identify and remove bugs, errors, and security issues.
• Different testing methods such as unit testing, integration testing, and system testing are performed.

Purpose: Ensure software quality and reliability.

5. Deployment

• After successful testing, the software is installed and delivered to users or clients.
• It becomes available for real-world use.

Purpose: Release the software into the production environment.

6. Maintenance

• After deployment, the software is monitored and updated regularly.
• Bug fixing, performance improvement, and adding new features are done in this phase.

Purpose: Keep the software functional and updated.

SDLC Phases Summary

SDLC provides a systematic approach for software development. It improves software quality, reduces development risks, and ensures efficient project management.

For a government mobile app that needs frequent updates but also faces strict regulatory requirements, neither pure Agile nor pure Waterfall alone is sufficient. A hybrid model that combines Agile sprints for development with Waterfall gates for compliance is the best fit.

Why Pure Models Fail Here

How the Hybrid Model Works

• Agile sprints for development: Two-week sprints deliver working features based on user feedback. Daily standups, sprint reviews, and retrospectives keep the team responsive.
• Waterfall gates for compliance: Before any release, the code must pass fixed checkpoints: security audit, documentation review, legal sign-off, and penetration testing.
• Regulatory buffer sprint: Every fourth sprint is dedicated solely to compliance tasks — filling documentation gaps, updating security certificates, and preparing audit reports.
• Versioned releases: Instead of continuous deployment, the team batches sprints into quarterly versioned releases that regulators can review as complete packages.

Why This Model is Most Appropriate

Example Workflow:
Week 1-2: Sprint 1 — Develop feedback feature (Agile)
Week 3-4: Sprint 2 — Develop notification improvement (Agile)
Week 5-6: Sprint 3 — Develop UI enhancement (Agile)
Week 7-8: Sprint 4 — Compliance sprint — Document, audit, secure (Waterfall gate)
Week 9: Release version 2.1 with full regulatory package

Limitations of the Waterfall Model

The Waterfall Model is a traditional, linear software development approach where each phase must be completed before moving to the next. Although it is simple and structured, it has several limitations.

• Rigid Requirements: Requirements must be fixed at the beginning. Any change later is costly and difficult to implement.
• Late Testing: Testing is performed only after development is complete, increasing the risk of late defect detection.
• Limited Customer Involvement: Customers are involved mainly at the requirement phase, which may lead to mismatched expectations.
• High Risk: If errors are found late, rework becomes expensive and time-consuming.
• Not Suitable for Complex Projects: Difficult to handle evolving or unclear requirements.

How Agile Methodologies Address These Limitations

Agile is an iterative and incremental approach that emphasizes flexibility, collaboration, and continuous improvement.

• Handles Changing Requirements: Agile welcomes requirement changes even late in development through iterative cycles (sprints).
• Early and Continuous Testing: Testing is integrated into every iteration, reducing defect risk.
• Strong Customer Collaboration: Customers are actively involved throughout the development process.
• Reduced Risk: Frequent feedback and small releases help identify issues early.
• Better Quality and Faster Delivery: Continuous integration and regular delivery ensure higher quality software.

Conclusion: While the Waterfall Model works well for small, stable projects, Agile methodologies are more suitable for modern, dynamic software development environments.

Difference between Unit Testing and Integration Testing

Example

Unit Testing: Testing the login validation function independently.

Integration Testing: Testing whether the Login Module correctly communicates with the Database Module and User Authentication Module.

During the Implementation Stage of the Software Development Life Cycle (SDLC), different types of testing are performed to verify that the software functions correctly and meets the specified requirements.

1. Unit Testing

Unit Testing is performed to test individual modules, functions, or classes independently. It is usually conducted by developers to ensure that each unit works correctly.

2. Integration Testing

Integration Testing verifies that multiple modules work together correctly after integration. It checks the interfaces and data flow between modules.

3. System Testing

System Testing evaluates the complete integrated software system to ensure that it meets all functional and non-functional requirements.

4. Acceptance Testing

Acceptance Testing is performed by customers or end users to verify that the software satisfies business requirements and is ready for deployment. It includes User Acceptance Testing (UAT).

These testing types ensure that the software is reliable, error-free, and ready for deployment by identifying defects at different levels of the implementation stage.

Difference Between Verification and Validation

Example

Verification: Reviewing the Software Design Document to ensure it follows the requirements.
Validation: Running the software to verify that the login functionality works correctly for users.

A Defect Report (also called a Bug Report) is a document used to record and track defects found during software testing. It provides complete information about the defect so that developers can identify, fix, and verify the issue efficiently.

Contents of a Defect Report

• Defect ID.
• Defect Summary or Title.
• Description of the defect.
• Steps to reproduce the defect.
• Expected Result.
• Actual Result.
• Severity and Priority.
• Status (Open, Fixed, Closed, etc.).
• Reporter and Assigned Developer.

Example

If a user enters a valid username and password but cannot log in, the tester records the issue in a Defect Report with all necessary details.

What is a Test Harness?

Answer:

A Test Harness is a collection of software, test data, Test Drivers, and Test Stubs used to execute and test a software component automatically. It provides an environment for running tests and comparing the actual results with the expected results.

Components of a Test Harness

• Test Driver.
• Test Stub.
• Test Data.
• Test Scripts.
• Result Comparison and Reporting Tools.

Example

During Unit Testing, a Test Harness uses a Test Driver to call a function and a Test Stub to simulate dependent modules, then compares the actual output with the expected output.

Software Testing Life Cycle (STLC) is a sequence of activities performed during the software testing process to ensure that the software meets the specified quality requirements. Each phase has specific objectives and deliverables.

Phases of STLC

1. Requirement Analysis
The testing team analyzes the software requirements to identify testable requirements, testing scope, and possible risks.

2. Test Planning
A Test Plan is prepared, which defines the testing strategy, resources, schedule, tools, responsibilities, and estimated effort.

3. Test Case Development
Testers design Test Cases, prepare Test Data, and review them to ensure complete test coverage.

4. Test Environment Setup
The required hardware, software, network, database, and testing tools are configured to create the testing environment.

5. Test Execution
The prepared Test Cases are executed. The actual results are compared with the expected results, and any defects found are reported.

6. Defect Reporting and Tracking
Detected defects are recorded in a Defect Report, assigned to developers, fixed, and retested until they are resolved.

7. Test Closure
Testing activities are completed, test reports are prepared, lessons learned are documented, and the testing process is formally closed.

Software Quality Assurance (SQA)

Software Quality Assurance (SQA) is a systematic process that ensures software meets specified quality standards and customer requirements. It focuses on improving the software development process to prevent defects rather than detecting them after development.

SQA involves activities such as process definition, quality planning, reviews, testing, audits, and continuous improvement to ensure reliable and high-quality software.

Aspects to Look for While Purchasing a Software System (Role of SQA Team Leader)

• Functionality: The software should meet all business requirements and perform expected functions correctly.
• Reliability: The system should work consistently without frequent failures or crashes.
• Usability: The software should be user-friendly and easy to learn for end users.
• Performance: It should respond quickly and handle the expected workload efficiently.
• Security: The software must protect data from unauthorized access and support authentication and authorization.
• Maintainability: The system should be easy to modify, update, and maintain.
• Compatibility: It should work smoothly with existing hardware, software, and operating systems.
• Scalability: The software should be able to handle future growth in users or data.
• Vendor Support: Availability of technical support, documentation, updates, and training.

Software Testing Level : Software Testing Levels are the different stages of testing used to verify and validate that software works correctly and meets requirements.

Types of Testing Levels

1. Unit Testing

• Definition: Testing of the smallest individual unit (function/module) of a program.
• Purpose: To check each part works correctly.
• Performed by: Developer.

2. Integration Testing

• Definition: Testing of combined modules to verify interaction between them.
• Purpose: To find interface/communication errors.

3. System Testing

• Definition: Testing of the complete system as a whole.
• Purpose: To ensure system meets functional and non-functional requirements.

4. User Acceptance Testing (UAT)

• Definition: Final testing performed by end users.
• Purpose: To confirm system meets business needs and is ready for deployment.

How They Complement Each Other

• Unit Testing: Ensures each component is correct.
• Integration Testing: Ensures components work together.
• System Testing: Ensures the whole system works properly.
• UAT: Ensures system satisfies user requirements.
• These levels work step-by-step from small parts to full system, ensuring complete quality assurance.

(a) Definition

Verification: Verification is the process of evaluating work products such as requirements, design, and code against predefined standards and specifications. It answers the question: “Are we building the product correctly?”

Validation: Validation focuses on evaluating the final product to ensure it meets user needs and expectations. It answers the question: “Are we building the right product?”

(b) Implementation of Verification and Validation in Software Testing

Verification Activities

Requirement Analysis: Functional and non-functional requirements are reviewed to identify testable requirements. A Requirement Traceability Matrix (RTM) is created to ensure each requirement is covered by test cases.

Test Planning and Documentation: A test plan is prepared defining scope, objectives, tools, and schedules to verify alignment with requirements.

Test Case Design and Development: Test cases are designed to verify individual components, including unit testing of modules.

Test Environment Setup: The test environment is configured to simulate real conditions, and smoke testing is performed.

Validation Activities

System Testing: The complete system is tested to validate overall functionality.

User Acceptance Testing (UAT): End users test the system to ensure it meets real-world requirements.

Performance and Usability Testing: Confirms system performance and user experience.

Test Execution and Bug Reporting: Test cases are executed, defects are logged, and fixes are retested.

Test Closure and Reporting: Test results are analyzed and documented, and lessons learned are discussed.

CI/CD Development Model

Version Control (Git)

Version Control is a system that helps developers track changes in source code over time. Git is a popular version control system that allows multiple developers to work on the same project, manage different versions of code, and revert to previous states when needed.

Difference between Committing and Pushing Code

Committing Code

Committing means saving changes to the local repository. It records a snapshot of the code with a message describing what was changed. The changes are stored only on the developer’s local machine.

Pushing Code

Pushing means sending committed changes from the local repository to a remote repository (such as GitHub or GitLab). This makes the changes available to other team members.

Key Difference

Committing saves changes locally, while pushing uploads those committed changes to a remote server.

ATM Testing: ATM testing is the process of verifying that an Automated Teller Machine performs banking transactions correctly, securely, and reliably. Testing should cover functional behavior, transaction processing, security, hardware, usability, and failure recovery.

1. Card Validation: Test valid, invalid, expired, and blocked cards. Verify that the ATM accepts eligible cards and rejects invalid or unauthorized cards with appropriate messages.

2. PIN Verification: Test correct and incorrect PINs, repeated incorrect attempts, and PIN retry limits. Verify that the system follows the bank's security policy and does not reveal sensitive PIN information.

3. Cash Withdrawal: Test withdrawals within the available balance and daily limit. Also test insufficient funds, amounts exceeding the limit, invalid denominations, and insufficient cash in the ATM. Confirm that the account is debited correctly and cash is dispensed accurately.

4. Balance Inquiry: Verify that the displayed balance is consistent with the bank's account records and that the ATM does not expose another customer's information.

5. Fund Transfer: If supported, test transfers between eligible accounts. Verify beneficiary details, transaction limits, successful debit and credit, and appropriate handling of failed or duplicate requests.

6. Receipt and Transaction History: Check that printed or digital receipts contain correct transaction details, such as the transaction reference, date, amount, and masked account/card information. Verify that sensitive data is not exposed unnecessarily.

7. Network and Power Failure: Interrupt network communication or simulate power failure in a controlled test environment. Verify that incomplete transactions are reconciled correctly, the customer is not charged incorrectly, and transaction status can be determined safely.

8. Security Testing: Test session timeout, card ejection or retention rules, protection against shoulder surfing, secure PIN entry, and resistance to unauthorized access. Verify that the ATM returns to a secure state after a transaction.

9. Hardware Testing: Test the card reader, keypad, cash dispenser, receipt printer, display, and sensors. Verify that hardware errors are detected and appropriate messages are shown.

10. Performance and Usability Testing: Measure transaction response time, verify that menus are understandable, and test accessibility and multilingual options where supported.

Step 1:
As the complexity adjustment factor is average (given in the question), the scale is set to 3 for each factor.
F = 14 × 3 = 42

Step 2:
Calculate the Complexity Adjustment Factor (CAF) using the formula:
CAF = 0.65 + (0.01 × F)
Substitute F = 42:
CAF = 0.65 + (0.01 × 42) = 1.07

Step 3:
Calculate the Unadjusted Function Points (UFP) using the given values and the corresponding weights (average weighting factors):
UFP = (50 × 4) + (40 × 5) + (35 × 4) + (6 × 10) + (4 × 7)
UFP = 200 + 200 + 140 + 60 + 28 = 628

Step 4:
Calculate the Function Point (FP) using the formula:
FP = UFP × CAF
FP = 628 × 1.07 = 671.96

Final Answer:
The Function Point (FP) is: 671.96

Functional Requirements

Functional requirements describe what a system should do. They define the specific functions, features, and behaviors of the system.

Examples:

• User login and authentication.
• Generating reports.
• Processing online payments.
• Data entry, update, and deletion.

Non-Functional Requirements

Non-functional requirements describe how a system performs its functions. They specify quality attributes and system constraints.

Examples:

• Performance (response time, throughput).
• Security (authentication, authorization).
• Usability and accessibility.
• Reliability and availability.
• Scalability and maintainability.

Requirement Validation

Requirement Validation is the process of ensuring that documented requirements are correct, complete, consistent, feasible, and meet the actual needs of stakeholders. It answers the question: “Are we building the right system?”

Activities in Requirement Validation:

• Requirement reviews and walkthroughs.
• Prototyping.
• Stakeholder approval and sign-off.
• Checking for ambiguity and conflicts.