PADDLE UP & TRANSVERSE

A Project Report
Submitted in partial fulfillment of the
Requirements for the award of the Degree of
BACHELOR OF SCIENCE (INFORMATION TECHNOLOGY)

By

Kunal Singh & Kaushal Soni

Seat Number :- 3021494 & 3021510

Under the esteemed guidance of

Miss. Thiru Menaga Prabhu Nadar

DEPARTMENT OF INFORMATION TECHNOLOGY

MAHENDRA PRATAP SHARDA PRASAD SINGH DEGREE COLLEGE
(Affiliated to University of Mumbai)
MUMBAI, 400051
MAHARASHTRA
2024-25
 MAHENDRA PRATAP SHARDA PRASAD SINGH DEGREE COLLEGE
(Affiliated to University of Mumbai)
MUMBAI-MAHARASHTRA-400051

DEPARTMENT OF INFORMATION TECHNOLOGY

CERTIFICATE

This is to certify that the project entitled, "Hospital Management System ", is
bonafide work of Kunal Singh & Kaushal Soni bearing Seat.No: (3021494 &
3021510) submitted in partial fulfillment of the requirements for the award of
degree of BACHELOR OF SCIENCE in INFORMATION TECHNOLOGY
from University of Mumbai.

Internal Guide Coordinator

External Examiner

Date: College Seal

 Abstract
Our project Hospital Management system includes registration of patients,
storing their details into the system, and also booking their appointments with
doctors. Our software has the facility to give a unique id for every patient and
stores the details of every patient and the staff automatically. Users can search for
the availability of a doctor and the details of a patient using the id. The Hospital
Management System can be entered using a username and password. It is
accessible either by an administrator or receptionist. Only they can add data into
the database. The data can be retrieved easily. The interface is very user-friendly.
The data is well protected for personal use and makes the data processing very
fast.
It has mainly two modules. One is at Administration Level and other one is
of user I.e. of patients and doctors. The Application maintains authentication in
order to access the application. Administrator tasks include managing doctors
information, patient’s information. To achieve this aim a database was designed
one for the patient and other for the doctors which the admin can access. The
complaints which are given by the user will be referred to by authorities. The
Patient modules include checking appointments, prescription. Users can also pay
doctor’s Fee online.
 ACKNOWLEDGEMENT

Apart from the efforts of the team, the success of any project depends
largely on the encouragement and guidelines of many others. We take this
opportunity to express our gratitude to the people who have been instrumental in
the successful completion of this project. The completion of any inter-disciplinary
project depends upon cooperation, coordination and combined efforts of several
sources of knowledge. We are eternally grateful to our teacher Miss. Thiru
Menaga Prabhu Nadar for her even willingness to give us valuable advice and
direction under which we executed this project. Her constant guidance and
willingness to share her vast knowledge made us understand this project and its
manifestations in great depths and helped us to complete the assigned tasks.
 DECLARATION

I hereby declare that the project entitled, “HOSPITAL MANAGEMENT

SYSTEM” done at the place where the project, has not been in any case
duplicated to submit to any other university for the award of any degree. To the
best of my knowledge other than me, no one has submitted to any other university.
The project is done in partial fulfillment of the requirements for the award of
degree of BACHELOR OF SCIENCE (INFORMATION TECHNOLOGY)
tobe submitted as final semester project as part of our curriculum.

—-----------------------------------
—-----------------------------------

Name and Signature of the Student

 TABLE OF CONTENTS

Chapter 1: Introduction …………………………………………………………………………………………………. 08

1.1 PURPOSE
1.2 SCOPE
1.3 DEFINITIONS, ACRONYMS, and ABBREVIATIONS
1.4 REFERENCES
1.5 OVERVIEW

CHAPTER 2 : SOFTWARE REQUIREMENT SPECIFICATION ………………15

2.1 Product Perspective
2.1.1 System Interfaces
2.1.2 System Specifications
2.1.2.1 H/W Requirement
2.1.2.2 S/W Requirement
2.1.3 Communication Interfaces
2.2 Product functions
2.3 Data Flow Diagram (DFD)
2.3.1 Context Level Diagram
2.3.2 DFD Level – 1
2.3.3 DFD Level – 2
2.4 Use Case Diagram
2.5 Use Case Description
2.6 User characteristics
2.7 Constraints
2.8 Assumptions and dependencies

Chapter 3: SPECIFIC REQUIREMENTS ……………………………….…………30

3.1 Performance requirements
3.2 Safety requirements
3.3 Security constraints
3.4 Software system attributes
3.4.1 Usability
3.4.2 Availability
3.4.3 Correctness
3.4.4 Maintainability
3.4.5 Accessibility
3.5 Functional Requirements
Chapter 4: DESIGN …………………………………………………………………..35
4.1 Data Dictionary
4.2 ER Diagram
4.3 Data Design
4.4 Component Level Diagram

Chapter 5: ESTIMATION AND SCHEDULING ……………………………………44

5.1 Project Scheduling
5.2 Timeline chart
5.3 Size Estimation (FUNCTION BASED METRICS)
5.4 Cost Estimation (COCOMO II MODEL)

Chapter 6: SAMPLE SCREENSHOTS ………………………………………….…50

Chapter 7: RISK ANALYSIS …………………………………………………...……61

CHAPTER 8 : TESTING………………………………………………………………63
8.1 WHITE BOX TESTING
8.1.1 Basic Path ( Pseudo code )
8.1.2 Flow Graph
8.1.3 Cyclomatic Complexity
8.1.4 Independent Paths

CHAPTER : 9 CONCLUSION……………………………………………………..…67
 LIST OF FIGURES USED IN THE PROJECT
FIGURE NO. NAME PAGE NO.

2.1 CONTEXT LEVEL DFD 18

2.2 LEVEL – 1 DFD 19

2.3 LEVEL – 2 REGISTRATION 20

2.4 LEVEL – 2 LOGIN 20

2.5 LEVEL – 2 MAKE APPOINTMENT 21

2.6 LEVEL – 2 ADD DESCRIPTION 21

2.7 LEVEL – 2 DOCTOR MODULE 22

2.8 LEVEL – 2 PAYMENT 22

2.9 LEVEL – 2 CANCEL APPOINTMENT 23

2.10 LEVEL – 2 PATIENT MODULE 23

6.1 HOME PAGE 57

6.2 SELECT LOGIN 57

6.3 PATIENT LOGIN PAGE 58

6.4 REGISTRATION 58

6.5 PATIENT PROFILE 59

6.6 PATIENT UPDATE DETAILS 59

6.7 PATIENT BOOK APPOINTMENT 60

6.8 PATIENT APPOINTMENT STATUS 60

6.9 PATIENT CANCEL APPOINTMENT 61

6.10 PAYMENT 61

6.11 PATIENT PAYMENT RECEIPT 62

6.12 PATIENT VIEW PAYMENT HISTORY 62

6.13 PATIENT VIEW DOCTORS 63

6.14 DOCTOR LOGIN PAGE 63

6.15 DOCTOR PROFILE 64

6.16 DOCTOR VIEW APPOINTMENT 64

6.17 DOCTOR ADD DESCRIPTION 65

6.18 ADMIN LOGIN PAGE 65

6.19 ADMIN ADD DOCTOR 66

6.20 ADMIN UPDATE DOCTOR DETAILS 66

6.21 ADMIN PAYMENT REQUEST 67

6.22 ADMIN VIEW RECORDS 67

 CHAPTER 1
INTRODUCTION
1.1 PURPOSE
1.2 SCOPE
1.3 DEFINITIONS, ACRONYMS, and
ABBREVIATIONS
1.4 REFERENCES

1.5 OVERVIEW
 INTRODUCTION

In today's fast-paced digital era, the healthcare sector demands

advanced and reliable systems to manage the vast amount of patient data,
appointments, billing, medical records, and other essential hospital
activities. Manual record-keeping often leads to inefficiencies, human
errors, and time-consuming processes. Therefore, there is a need for an
integrated solution that streamlines hospital operations, improves patient
care, and enhances data management.

The Hospital Management System (HMS) is designed to meet these needs

by offering a web-based solution that automates the entire workflow of a
hospital. This project is developed using PHP as the server-side scripting
language and MySQL as the backend database, with HTML, JavaScript,
AJAX, and jQuery for front-end development. It is compatible with
commonly used browsers and can be hosted on software like XAMPP,
WAMP, MAMP, or LAMP.

This project simplifies the management of administrative tasks, ensures

security and privacy of patient data, and provides a user-friendly interface
for doctors, nurses, administrative staff, and patients alike

1.1 PURPOSE

The purpose of the Hospital Management System is to develop a

digital platform that will help hospitals and healthcare institutions manage
their day-to-day operations more effectively and efficiently. The system
aims to:
 ● Automate hospital activities such as patient registration, appointment
scheduling, billing, and medical record tracking.

● Minimize paperwork and reduce administrative workload.

● Ensure accurate and secure storage of patient data.

● Improve communication between hospital departments and

streamline operations.

● Provide real-time data access to authorized users including doctors,

nurses, and staff.

1.2 SCOPE
The Hospital Management System (HMS) is a comprehensive
web-based application that aims to streamline the functioning of healthcare
institutions such as hospitals, clinics, nursing homes, and dispensaries. The
scope of this project encompasses the digitization and automation of
various hospital operations including patient management, appointment
scheduling, doctor management, billing, prescription generation, and report
handling.

This system is intended to provide different levels of access for

different types of users such as administrators, doctors, and patients,
ensuring that every user can perform only those tasks which fall under their
specific roles. It supports real-time data entry, secure data storage, and
easy retrieval of information, ensuring improved workflow and efficient
resource utilization.

The system will enable:

 ● Patients can register, book appointments, view their records, and pay
consultation fees online.

● Doctors manage appointments, view patient history, and add

prescriptions.

● Administrators to manage doctor and patient data, verify payments,

and generate reports.

1.3 DEFINITIONS, ACRONYMS, and ABBREVIATIONS

This section defines the technical terms, acronyms, and abbreviations
used throughout the Hospital Management System project documentation.

🔹 Definitions
● Hospital Management System (HMS):
A web-based software application that automates various hospital
operations such as patient management, doctor scheduling,
appointments, and billing.

● Patient:
A user who seeks medical consultation and uses the system to
register, book appointments, and view health records.

● Doctor:
A registered medical professional using the system to manage
appointments, prescribe treatments, and access patient history.

● Admin:
The system administrator responsible for managing doctor and
 patient data, appointments, reports, and user access.

🔹 Acronyms
Acronym Full Form

HMS Hospital Management System

UI User Interface

DBMS Database Management System

SRS Software Requirement Specification

CRUD Create, Read, Update, Delete

SQL Structured Query Language

HTML HyperText Markup Language

CSS Cascading Style Sheets

JS JavaScript

AJAX Asynchronous JavaScript and XML

MVC Model-View-Controller
🔹 Abbreviations
Abbreviation Description

Appt. Appointment

ID Identification

DOB Date of Birth

Addr. Address

Ph No. Phone Number

BG Blood Group

Expr. Experience

Spec. Specialization

1.4 REFERENCES

1. https://www.php.net/ – Official PHP documentation.

2. https://www.mysql.com/ – MySQL official website for database

references.
3. https://www.w3schools.com/ – Frontend tutorials and web
development references (HTML, CSS, JS).
4. https://getbootstrap.com/ – Bootstrap framework
documentation for UI design.
5. https://www.javatpoint.com/hospital-management-system –
General references on HMS logic and flow.
1.5 OVERVIEW

This document outlines the complete software requirements, design, and

functionality of the Hospital Management System (HMS). It aims to
provide a clear understanding of the system to developers, testers, and
stakeholders involved in the development process. The HMS is structured
in a modular way and allows seamless integration of new features in the
future.

The primary objective of the system is to manage the essential functions of

a hospital, including patient registration, doctor appointments, medical
records, billing, and administrative reports. The system is designed with
multiple user roles (Admin, Doctor, and Patient), each with defined
capabilities and access levels to ensure data privacy and operational
efficiency.
 CHAPTER 2
SOFTWARE REQUIREMENT
SPECIFICATION
2.1 Product Perspective

2.1.1 System Interfaces

2.1.2 System Specifications

2.1.2.1 H/W Requirement

2.1.2.2 S/W Requirement

2.1.3 Communication Interfaces

2.2 Product functions

2.3 Data Flow Diagram (DFD)

2.3.1 Context Level Diagram

2.3.2 DFD Level – 1

2.3.3 DFD Level – 2

2.4 Use Case Diagram

2.5 Use Case Description

2.6 User characteristics

2.7 Constraints

2.8 Assumptions and dependencies

2.1 PRODUCT PERSPECTIVE
The Hospital Management System (HMS) is a web-based software
solution developed as an independent application to streamline and digitize
the administrative and medical operations of a hospital or healthcare facility.
This system is a self-contained product and does not depend on any
existing system or software, but it is designed with future scalability and
integration in mind.

The system provides an end-to-end digital platform for managing hospital

processes including patient registration, appointment scheduling, doctor
management, billing, and report generation. It is built using open-source
technologies — primarily PHP for server-side scripting and MySQL for
database management — making it cost-effective and
platform-independent.

This system follows a modular architecture, which means each core

functionality (e.g., admin dashboard, patient booking, doctor profile, etc.) is
managed as a separate component. These modules interact with each
other through clearly defined data flows, ensuring a cohesive and
well-organized structure.

The product is accessible through standard web browsers and can be

deployed on any server that supports PHP and MySQL. It also supports
role-based access control, allowing different types of users (Admin, Doctor,
Patient) to access only the features relevant to their roles.
2.1.2 SYSTEM SPECIFICATIONS

2.1.2.1 Hardware Requirements

Category Minimum Requirement

Processor Intel Core i3 or higher

RAM 4 GB or more

Hard Disk 1 TB HDD or 256 GB SSD

Display 1024x768 resolution

Input Devices Keyboard, Mouse

Printer (Optional) For report generation

2.1.2.2 Software Requirements

Component Description

Operating System Windows 7/8/10/11, Linux, macOS

Web Server Apache (via XAMPP/WAMP/LAMP/MAMP)

Backend PHP (version 5.6, 7.x, or 8.x)

Database MySQL 5.x / 8.x

Front-end HTML, CSS, JavaScript, jQuery, AJAX

Web Browser Chrome, Firefox, Edge, Opera

Editor (IDE) VS Code, Sublime Text, Notepad++ (any one)

2.1.3 COMMUNICATION INTERFACES

The system operates as a client-server application, and the communication

interfaces are as follows:
 ● Client to Server: HTTP/HTTPS protocol over a local network or the
internet.
● Database Access: MySQL accessed via PHP using SQL queries.
● Admin, Doctor, and Patient: Each user role interacts with the server
through web-based UI components using browsers.
● Optional Email/SMS Notification (Future Scope): Can use SMTP,
Twilio, or other APIs to communicate appointment details.

2.2 PRODUCT FUNCTIONS

The main functionalities of the system are:

● User Registration & Login: Separate access for patients, doctors,

and admin.
● Profile Management: Edit and manage user-specific details.
● Appointment Booking: Patients can book/cancel appointments;
doctors can view/manage them.
● Medical History Management: Patients and doctors can access
history records.
● Admin Dashboard: Complete control over users, doctors,
appointments, and reports.
● Search & Reporting: Admin/Doctors can search patients and
generate reports by date, ID, etc.
● Session Logs: View login/logout activity of users and doctors.
2.3 DATA FLOW DIAGRAM (DFD)

2.3.1 Context Level Diagram

● Shows one single system process interacting with external entities:

Admin, Doctor, Patient.

2.3.2 DFD Level – 1

● Breaks down into key modules:

○ Patient Management

○ Appointment Booking

○ Doctor Management

○ Report Handling
2.3.3 DFD Level – 2
2.4 USE CASE DIAGRAM

A high-level diagram showing relationships between:

● Actors: Admin, Doctor, Patient

● Use Cases: Login, Register, Book Appointment, View Records,
Generate Reports, Manage Profiles
 ●

2.5 USE CASE DESCRIPTION

Use Case Description

Register Patient creates a new account

Login Any user logs into the system

Book Appointment Patient selects doctor and slot

Manage Profile Edit or update user details

View History Patient and doctor access past appointments

Manage Users Admin updates/deletes user data

2.6 USER CHARACTERISTICS

User Type Characteristics

Admin Technical knowledge, access to all modules

Doctor Familiar with medical terms and patient records

Patient General public, minimal computer knowledge needed

2.7 CONSTRAINTS

● Application must be hosted on a PHP-supported server.

 ● Internet access is required for online deployment.

● Only one appointment per user per slot is allowed.

● User data must be validated to avoid duplication.

2.8 ASSUMPTIONS AND DEPENDENCIES

● Users will have access to a compatible web browser.

● MySQL and PHP environments are correctly configured.

● No third-party integrations are used at this stage (e.g., payment

gateway).

● Users are expected to enter correct data as there is minimal input

validation.
 CHAPTER 3

SPECIFIC REQUIREMENTS

3.1 Performance requirements

3.2 Safety requirements

3.3 Security constraints

3.4 Software system attributes

3.4.1 Usability

3.4.2 Availability

3.4.3 Correctness

3.4.4 Maintainability

3.4.5 Accessibility

3.5 Functional Requirements

SPECIFIC REQUIREMENTS

3.1 Performance Requirements

● The system should be able to handle multiple users (admin, doctors,

patients) accessing it simultaneously without performance
degradation.

● Page load time should not exceed 2 seconds under normal network
conditions.

● The database should support up to 10,000 records of patients,

appointments, and doctors without impacting system efficiency.

● System operations like booking appointments or fetching records

must execute within 1-2 seconds.

3.2 Safety Requirements

● System backups should be taken periodically to prevent data loss.

● Users must be warned before performing critical actions like deleting

data.

● System should have proper logout functionality to prevent

unauthorized access from unattended sessions.

● Data entry should include basic validation to reduce errors or misuse.

3.3 Security Constraints

 ● Passwords must be stored in an encrypted format (e.g., using MD5,
SHA-256, or bcrypt).

● Only authorized users should access restricted modules (Role-Based

Access Control).

● Admin must approve or monitor access to sensitive patient and doctor

data.

● SQL Injection, XSS, and CSRF vulnerabilities must be prevented

using prepared statements and secure coding practices.

● HTTPS should be used for all data transmission (in online

deployments).

3.4 Software System Attributes

3.4.1 Usability

● The system provides an intuitive, clean, and easy-to-navigate user

interface.

● Minimal training is required for doctors, admins, or patients to operate

the system.

● Interactive forms and real-time feedback ensure better usability.

3.4.2 Availability

● The application should be available 24/7, especially in online

deployment scenarios.

● Scheduled maintenance or downtime should be communicated in

advance.

3.4.3 Correctness
 ● The system must function as intended, displaying accurate
information about appointments, users, and medical records.

● All modules should return correct responses based on inputs, without

system crashes.

3.4.4 Maintainability

● The code should be modular, well-documented, and easy to update.

● Developers should be able to add new features (e.g., payment

gateway, reports) without overhauling the existing system.

3.4.5 Accessibility

● The application should be accessible on different devices like

desktops, laptops, and tablets.

● Browser compatibility is ensured across Chrome, Firefox, and Edge.

● (Optional) Future versions can include screen reader compatibility for

visually impaired users.
3.5 Functional Requirements

ID Requirement Description

FR The system shall allow patients to register and log in.

1

FR The system shall allow patients to book, view, and cancel

2 appointments.

FR The system shall allow doctors to manage appointments and

3 patient records.

FR The admin shall manage doctors, users, appointments, and

4 system reports.

FR The system shall allow password recovery through email.

5

FR The system shall restrict access based on user roles (Admin,

6 Doctor, Patient).

FR The system shall maintain logs of login/logout activities.

7

FR The system shall enable search functionality by patient name

8 or mobile number.
 CHAPTER 4

DESIGN
4.1 Data Dictionary

4.2 ER Diagram

4.3 Data Design

4.4 Component Level Diagram

DESIGN

4.1 DATA DICTIONARY

Table Name Field Data Type Description

users id INT Primary key,

auto-increment

fullName VARCHAR(100) Name of the patient

email VARCHAR(100) Email ID (unique)

passwor VARCHAR(255) Encrypted password

d

gender VARCHAR(10) Male/Female/Other

address TEXT Full address

city VARCHAR(50) City of residence

regDate TIMESTAMP Date of registration

Table: doctors

Field Data Type Description

id INT Primary key

specialization VARCHAR(100) Field of specialization

doctorName VARCHAR(100) Full name of doctor

address TEXT Clinic or hospital address

 contactNo VARCHAR(15) Phone number

email VARCHAR(100) Email address

password VARCHAR(255) Encrypted password

Table: appointments

Field Data Type Description

id INT Primary key

userId INT Foreign key to users table

doctorId INT Foreign key to doctors table

appointmentDate DATE Chosen appointment date

appointmentTime TIME Selected time slot

userStatus BOOLEAN Status updated by user (0 = pending, 1 =

done)
 doctorStatus BOOLEAN Status updated by doctor (0 = pending, 1 =
done)

Table: contacts

Field Data Type Description

id INT Primary key

fullName VARCHAR(100) Name of the sender

email VARCHAR(100) Sender's email

message TEXT Contact message

4.2 ER DIAGRAM

The Entity-Relationship (ER) Diagram includes:

● Entities:

○ Patient (User)

○ Doctor

○ Admin
 ○ Appointment

○ Contact Query

● Relationships:

○ A Patient can book many Appointments.

○ A Doctor can handle many Appointments.

○ Admin manages Doctors, Patients, Appointments, and Queries.

4.3 DATA DESIGN

The data design focuses on ensuring normalization and efficiency in

accessing and managing records.

● Normalization: All tables are normalized up to 3NF (Third Normal

Form) to reduce redundancy and ensure integrity.

● Primary and Foreign Keys: Each main table has a unique primary
key and appropriate foreign keys to establish relationships.

● Indexing: Fields like email, appointmentDate, and doctorId

are indexed for faster query execution.

● Security: Passwords are stored in encrypted format. No sensitive

data is stored in plain text.

4.4 COMPONENT LEVEL DIAGRAM

This diagram breaks down the project into logical components/modules:

1. Frontend (UI Layer)

● Registration/Login Page

● Dashboard (User, Admin, Doctor)

● Appointment Booking/Management Pages

2. Business Logic Layer (PHP Controllers)

● UserController

● DoctorController

● AdminController
 ● AppointmentManager

● ContactQueryManager

3. Database Layer

● MySQL Database

○ Tables: users, doctors, appointments, contacts

 CHAPTER 5
ESTIMATION AND SCHEDULING
5.1 Project Scheduling

5.2 Timeline chart

5.3 Size Estimation (FUNCTION BASED METRICS)

5.4 Cost Estimation (COCOMO II MODEL)

5.1 PROJECT SCHEDULING

The project was developed following an incremental development

approach, divided into several phases. Each phase involved planning,
designing, coding, testing, and reviewing. The tasks were allocated to team
members based on their strengths and availability.

Project Phases:

1. Requirement Gathering & Analysis

2. System Design (UML, ERD, DFD, Architecture)

3. Frontend Development (HTML/CSS/JS)

4. Backend Development (PHP, MySQL)

5. Testing and Debugging

6. Documentation and Final Report

5.2 TIMELINE CHART

Phase Duration Start Date End Date

Requirement Analysis 1 Week 01-Feb-2025 07-Feb-2025

System Design 1 Week 08-Feb-2025 14-Feb-2025

Frontend Development 1 Week 15-Feb-2025 21-Feb-2025

Backend Development 2 Weeks 22-Feb-2025 07-Mar-2025

Testing & Bug Fixing 1 Week 08-Mar-2025 14-Mar-2025

Final Documentation & 1 Week 15-Mar-2025 21-Mar-2025

Report

Total Duration 7 Weeks 01-Feb-2025 21-Mar-2025

5.3 SIZE ESTIMATION (Function-Based Metrics)

Using Function Point (FP) Analysis:

Function Type Estimated Weight Total

Count FP

External Inputs (e.g., forms) 5 4 20

External Outputs (e.g., 4 5 20

reports)

External Inquiries 3 4 12

Internal Logical Files 4 7 28

External Interface Files 2 5 10

Total Unadjusted FP (UFP) 90

Estimated Source Lines of Code (SLOC) = FP × Language

Factor
PHP Approx. = 50 SLOC/FP → 90 × 50 = 4,500 LOC

5.4 COST ESTIMATION (COCOMO II MODEL)

COCOMO II Basic Model Formula:

Effort = a × (KLOC)^b × EAF

● Estimated Size: 4.5 KLOC (from above)

● a = 2.4 (organic mode)

● b = 1.05 (organic mode)

● EAF (Effort Adjustment Factor) = 1.0 (assuming average

environment)
Effort Estimation:

Effort = 2.4 × (4.5)^1.05 ≈ 11.32 Person-Months

Time Estimation:

Tdev = 2.5 × (Effort)^0.38

Tdev = 2.5 × (11.32)^0.38 ≈ 5.8 Months

Cost Estimation (Assuming ₹25,000/PM):

Total Cost ≈ 11.32 × ₹25,000 ≈ ₹2,83,000

COST ESTIMATION FOR THIS 13. Doctor Profile.

PROJECT 14. Appointment Details.
(1) SCREENS 15. View Patient by Doctor.
1. Home Page. 16. Add Prescription.
2. Select Login. 17. Login Page For Admin.
3. Login Page For Patient . 18. Generate Bill.
4. Registration For Patient. 19. Update Doctor Details.
5. Patient Profile. 20. Add Doctor.
6. Patient Update Details. 21. View doctor By Admin.
7. Book Appointment . 22. View Records.
8. View Appointment Status .
9. Cancel Appointment. TOTAL SCREENS = 22
10. Payment By Patient. TOTAL 3GL MODULES = 0
11. Receipt Of Payment . TOTAL REPORTS = 8

(2) REPORTS
1. Total Visitors on Website.
2. Total Patients Treated.
3. Total Appointments Taken.
4. Total Appointments Cancelled.
5. Total Doctors on Leave.
6. Total Doctors Added.
7. Total Doctors Removed.
8. Total Consultant Fee Collected .
12. Login Page For Doctor.
CONSIDERING ALL OF THE ABOVE HAVE MEDIUM COMPLEXITY, 0%
OF COMPONENTS ARE REUSED AND TAKING THE DEVELOPER
EXPERIENCE AND ENVIRONMENT MATURITY AS LOW.

PRODUCTIVITY RATE =7+7 / 2 = 7.

OBJECT POINT = {22 * 2} + {8 * 5} = 84.

ESTIMATED EFFORT = NOP / PROD = 84 / 7 = 12 Person-Months.

 CHAPTER 6
SCREENSHOTS
This section contains the screenshots of various modules and user
interfaces from the Hospital Management System web application. These
images illustrate the working of the system and how different user roles
interact with it.
 CHAPTER 7

RISK ANALYSIS
RISK ANALYSIS

Risk analysis is a crucial part of the software development lifecycle. It

helps identify potential issues that could negatively impact the project
and outlines strategies to mitigate them. The following table highlights
key risks associated with the Hospital Management System project:

Risk Risk Probab Impa Mitigation Strategy

ID Description ility ct

R1 Delay in Mediu High Set fixed client

requirement m meetings, maintain
gathering requirement checklist

R2 Poor Mediu Medi Use collaboration tools

communication m um like Trello, Slack, or
between team WhatsApp
members

R3 Technical skill Low Medi Assign training

gap in using um sessions or refer to
PHP or MySQL documentation

R4 Server or hosting Low High Use reliable hosting;

failure regular backups of the
database

R5 Security breach Mediu High Implement secure

or data leakage m login, encrypt sensitive
data, update patches

R6 Scope creep due High Medi Freeze requirements

to late um early; document
requirements changes formally

R7 Incomplete Mediu High Perform thorough unit

testing leading to m and integration testing
 bugs in
production

R8 Browser Mediu Medi Test application on

compatibility m um multiple browsers
issues (Chrome, Firefox, etc.)

R9 Delay in final High Low Assign responsibilities

documentation early; follow
documentation
schedule

R10 Inefficient Low Medi Optimize SQL queries;

database um use indexing where
queries slowing necessary
performance

Risk Monitoring and Management

● Regular team meetings will be conducted to monitor and

address emerging risks.

● Risk logs will be maintained to document potential issues and

mitigation steps.

● Any high-probability or high-impact risk will be prioritized and

addressed immediately.
 CHAPTER 8
TESTING
8.1 WHITE BOX TESTING
8.1.1 Basic Path ( Pseudo code )
8.1.2 Flow Graph
8.1.3 Cyclomatic Complexity
8.1.4 Independent Paths
TESTING
Testing is one of the most critical phases in the software development
lifecycle. It ensures that the system functions as intended and is free
from defects. For this project, both White Box and Black Box
Testing methods were applied. This chapter focuses on White Box
Testing.

8.1 WHITE BOX TESTING

White Box Testing is also known as structural or glass-box testing. It
involves testing the internal structure, design, and coding of the
application. Testers require knowledge of the source code and use it
to design test cases.

8.1.1 Basic Path (Pseudo Code)

Below is a sample pseudo code for the Appointment Booking

module:

Function BookAppointment(UserID, DoctorID, Date,

Time):

IF UserID and DoctorID are valid:

IF SlotAvailable(Date, Time) == True:

Create new Appointment

Display “Appointment Booked

Successfully”

ELSE:

Display “Selected Time Slot is

Unavailable”
 ELSE:

Display “Invalid User or Doctor ID”

8.1.2 Flow Graph

Nodes : 1 (Start), 2 (Check IDs), 3 (Slot Availability), 4 (Book), 5

(Error), 6 (End)
Edges : 7
Regions : 3

8.1.3 Cyclomatic Complexity

Cyclomatic Complexity (CC) is calculated as:

CC = E − N + 2P

Where,

E = Number of edges = 7

N = Number of nodes = 6

P = Number of connected components = 1

ini

CopyEdit

CC = 7 − 6 + 2(1) = 3

So, the Cyclomatic Complexity = 3 , meaning 3 independent

paths must be tested.

8.1.4 Independent Paths

The three independent paths through the code are:

1. Valid IDs → Slot Available → Book Appointment → End

2. Valid IDs → Slot Not Available → Show Error → End

 3. Invalid IDs → Show Error → End

These paths will be used to design corresponding test cases.

CHAPTER 9
CONCLUSION
CONCLUSION
The Hospital Management System project successfully addresses
the fundamental needs of a modern healthcare facility by providing a
centralized, digital platform to manage patients, doctors,
appointments, and reports. This system simplifies administrative and
clinical workflows, improving efficiency, accuracy, and user
experience.

During the development process, we implemented key software

engineering practices, including requirements gathering, system
design, database management, testing, and risk analysis.
Technologies such as PHP , MySQL , HTML, and JavaScript were
effectively utilized to develop a dynamic, interactive, and scalable web
application.

Key Achievements:

● Streamlined the appointment booking process for patients and

doctors.

● Enabled administrative users to manage doctors, patients,

reports, and communication efficiently.

● Implemented secure login mechanisms and session handling

for different user roles.

● Created a user-friendly interface that ensures accessibility and

usability.

Learning Outcomes:

● Gained hands-on experience in full-stack web development.

● Understood the importance of documentation and structured

project planning.
 ● Learned to apply software engineering principles, including
Data Flow Diagrams , ER Models , UML Use Cases , and
Testing Strategies .

● Improved team collaboration and task management through

effective project scheduling and risk mitigation.

In conclusion, this project not only demonstrates our technical

capability but also emphasizes the importance of designing software
that has real-world applications in vital sectors like healthcare. With
further enhancements, this system can be deployed in small to
mid-sized hospitals for practical use.