Hospital Management System

Software Engineering Project

Report
MICHAEL MADHUSUDHAN
MEMORIAL COLLEGE

Affiliated to
KAZI NAZRUL UNIVERSITY
Year of Examination:
2024

BCA.(H) Computer Applications

Submitted By:-
NAME- Rahul Chakraborty Manisha Bhandary Antara Mondal

REG.NO- 111221250069 111221250015 111221250013

ACKNOWLEDGEMENT

Apart from the efforts of 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, co-
ordination and combined efforts of several sources of knowledge.
We are eternally grateful to our teacher “Smitaparna Biswas” 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.

Rahul Chakraborty (111221250069)

Manisha Bhandary (111221250015)
Antara Mondal (111221250013)
CERTIFICATE
This is to certify that Software Engineering project report entitled "Hospital
Management System" is the work carried out Rahul Chakraborty, Manisha
Bhandary, Antara Mondal students of BCA. (H) Computer Application V Semester,
Michael Madhusudhan Memorial College, affiliated to Kazi Nazrul University, under
the supervision of “Smitaparna Biswas “ mam, Assistant Professor, Department of
computer application.
This report has not been submitted to any other organization/institution for the
award any other degree/diploma.

Smitaparna Partha Pratim

Biswas Chattaraj
(PROJECT GUIDE) ( OUR HOD SIR)
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. User can search 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 are well protected for
personal use and makes the data processing very fast.

It is having 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 task includes 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 user will
be referred by authorities.
The Patient modules include checking appointments, prescription. User can also pay
doctor’s Fee online.
Table of Contents
SNO TOPIC Page No

1. PROBLEM STATEMENT 9
2. PROCESS MODEL 11
3. SOFTWARE 15
REQUIREMENTS
SPECIFICATION
4. CONTEXT LEVEL DIAGRAM 18
5. DFD LEVEL 1 19
6. DFD LEVEL 2 20
7. USE CASE DIAGRAM 24
8. USE CASE DESCRIPTION 25
9. DATA DICTIONARY 35
10. ER DIAGRAM 36
11. DATA DESIGN 37
12. COMPONENT LEVEL DIAGRAM 40
13. PROJECT SCHEDULING 44
14. TIMELINE CHART 45
15. FUNCTION POINT METRICS 46
16. COCOMO MODEL 52
17. SAMPLE SCREENSHOTS 56
18. RISK ANALYSIS 69
19. TESTING 70
20. CONCLUSION 75
LIST OF FIGURES USED IN THE PROJECT

FIGUR NAME PAGE No

E_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 PAITENT MODULE 23

6.1 HOME PAGE 56

6.2 SELECT LOGIN 57

6.3 PATIENT LOGIN PAGE 58

6.4 REGISTRATION 58

6.5 PATIENT BOOK APPOINTMENT 59

6.6 PATIENT CANCEL APPOINTMENT 60

6.7 PAYMENT 61

6.8 PATIENT VIEW PAYMENT HISTORY 62

6.9 PATIENT VIEW DOCTORS 63

6.10 DOCTOR LOGIN PAGE 64

6.11 DOCTOR PROFILE 65

6.12 ADMIN LOGIN PAGE 66

6.13 ADMIN ADD DOCTOR 67

6.14 ADMIN UPDATE DOCTOR DETAILS 68

6.15 ADMIN VIEW RECORDS 68

LIST OF TABLES USED IN THE PROJECT

TABLE NO NAME PAGE NO

4.1 DATA DICTIONARY 38

4.2 PATIENT 40

4.3 APPOINTMENT 40

4.4 DOCTOR 41

4.5 PRESCRIPTION 41

4.6 ADMIN 42

4.7 BILL 42

5.1 PROJECT SCHEDULING 44

5.2 TIMELINE CHART 45

5.3 49
FUNCTION POINT COMPLEXITY
WEIGHTS

5.4 COCOMO II COMPLEXITY 52

WEIGHTS

PRODUCTIVITY RATE 53
FOR OBJECT POINT
5.5 COUNTS
7.1 RISK ANALYSIS 69
PROBLEM STATEMENT
In this busy world we don’t have the time to wait in infamously long hospital queues.
The problem is, queuing at hospital is often managed manually by administrative staff,
then take a token there and then wait for our turn then ask for the doctor and the most
frustrating thing - we went there by traveling a long distance and then we come to know
the doctor is on leave or the doctor can’t take appointments.

HMS will help us overcome all these problems because now patients can book their
appointments at home, they can check whether the doctor they want to meet is
available or not. Doctors can also confirm or decline appointments, this help both
patient and the doctor because if the doctor declines’ appointment then patient will
know this in advance and patient will visit hospital only when the doctor confirms’ the
appointment this will save time and money of the patient.

Patients can also pay the doctor’s consultant fee online to save their time.

HMS is essential for all healthcare establishments, be it hospitals, nursing homes, health
clinics, rehabilitation centers, dispensaries, or clinics. The main goal is to computerize all
the details regarding the patient and the hospital. The installation of this healthcare
software results in improvement in administrative functions and hence better patient
care, which is the prime focus of any healthcare unit.

Benefits of implementing a hospital management system:

• Appointment booking o Helps patients cut the long queue and

saves their time o Is equipped with features like automated email
and text message reminders
• Role-Based Access Control o Allows employees to access only
the necessary information to effectively perform their job duties
o Increases data security and integrity
• Overall cost reduction o Cuts down paper costs as all the data
are computerized o No separate costs for setting up physical
servers

• Data accuracy o Removes human errors

o Alerts when there’s a shortage of stock

• Data security o Helps to keep patients records private o Restricts

access through role-based access control

• Revenue management
o Makes daily auditing simple

o Helps with statistics and other financial aspects

PROCESS MODEL

Hospital Management System follows INCREMENTAL MODEL because

initially software requirements are reasonably well defined but the overall
scope of development effort is a purely linear process. There may be other
requirements of the user which will be known later. So, those requirements
can the implemented and delivered in the following next increments. Our
project is a short term project of 3 months and 3 weeks only and staffing
available is also low (3 persons).
CHAPTER 1
INTRODUCTIO
1. PURPOSE N
2. SCOPE
3. DEFINITIONS, ACRONYMS, and ABBREVIATIONS
4. REFERENCES
5. OVERVIEW
1. PURPOSE

This software will help the company to be more efficient in registration of their patients
and manage appointments, records of patients. It enables doctors and admin to view
and modify appointments schedules if required. The purpose of this project is to
computerize all details regarding patient details and hospital details.

2. SCOPE

The system will be used as the application that serves hospitals, clinic, dispensaries or
other health institutions. The intention of the system is to increase the number of
patients that can be treated and managed properly.
If the hospital management system is file based, management of the hospital has to put
much effort on securing the files. They can be easily damaged by fire, insects and natural
disasters. Also could be misplaced by losing data and information.

3. DEFINITIONS, ACRONYMS, and ABBREVIATIONS

1. Cardiologist - treats heart disease.
2. Pediatrician - treats infants, toddlers, children and teenagers.
3. Plastic Surgeon - restores, reconstructs, corrects or improves in the shape and
appearance of damaged body structures, especially the face.
4. Psychiatrist - treats patients with emotional disorders. 5.
mental and Ophthalmologist - treats eye
defects, injuries, and diseases
6. ENT- Ear, Nose and Throat Specialist.
• SRS: Software Requirement Specification.
• DFD: Data Flow Diagram.
• ENT- Ear, Nose and Throat Specialist.
• BG - Blood group

✓ Appt – Appointment.
✓ Sign up - Creating New User.
✓ Log in - Logging in Existing User.
✓ PhNo - Mobile number.
✓ Addr – Address.
✓ Expr – Experience.
4. REFERENCES

➢ https://www.officetimeline.com/make-gantt-chart/excel
➢ https://medium.com/@datamateuaecrescent/hospital-management-systemfeatures-objectives-62eeb13f4fc4
➢ R.S Pressman, Software Engineering: A Practitioner’s Approach, Mc-Graw-Hill,
Edition-7 (2010).
➢ P. Jalote, an Integrated Approach to Software Engineering, Narosa publication
house, Edition -3 (2011).

5. OVERVIEW
Our application contains two modules – the admin module and the user module.
Our application will not only help the admin to preview the monthly and/or yearly
data but it will also allow them to edit, add or update records. The software will
also help the admin to monitor the transactions made by the patients and generate
confirmations for the same. The admin will be able to manage and update
information about doctors.
The user module can be accessed by both the doctors and the patients. The doctor
can confirm and/or cancel appointments. The doctors can even add prescriptions
for their patients using our application. The patients will be able to apply for the
appointment and make transaction for the same, and can even cancel
appointments with the doctors. They can track details about the previous
transactions made by them.

Advantages
• The system automates the manual procedure of managing hospital activities.
• Doctors can view their patients’ treatment records and details easily.
• It even generates an instant bill.
• The system is convenient and flexible to be used.
• It saves their time, efforts, money and resources.

Disadvantages
• Requires large database.
• The admin has to manually keep updating the information by entering the details
in the system.
• Need Internet connection.

CHAPTER 2
SOFTWARE REQUIREMENT
SPECIFICATI
ON
1. Product Perspective
1. System Interfaces
2. System Specifications
1. H/W Requirement
2. S/W Requirement
3. Communication Interfaces
2. Product functions
3. Data Flow Diagram (DFD)
1. Context Level Diagram
2. DFD Level – 1
3. DFD Level – 2
4. Use Case Diagram
5. Use Case Description
6. User characteristics
7. Constraints
8. Assumptions and dependencies
1. Product Perspective
This Hospital Patient Info Management System is a self-contained system that manages
activities of the hospital.
Due to improperly managed details medical center faces quite a lot of difficulties in
accessing past data as well as managing present data. The fully functional automated
hospital management system which will be developed through this project will eliminate
the disadvantages caused by the manual system by improving the reliability, efficiency
and performance. The usage of a database to store patient, employee, stock details etc.
will accommodate easy access, retrieval, and search and manipulation of data. The
access limitations provided through access privilege levels will enhance the security of
the system. The system will facilitate concurrent access and convenient management of
activities of the medical center.

1. System Interfaces
❖ User Interfaces
▪ This section provides a detailed description of all inputs into and outputs from
the system. It also gives a description of the hardware, software and
communication interfaces and provides basic prototypes of the user interface.
▪ The protocol used shall be HTTP.
▪ The Port number used will be 80.
▪ There shall be logical address of the system in IPv4 format.

❖ Hardware Interfaces
▪ Laptop/Desktop PC-Purpose of this is to give information when Patients ask
information about doctors, medicine available lab tests etc. To perform such
Action it need very efficient computer otherwise due to that reason patients
have to wait for a long time to get what they ask for.
▪ Laser Printer (B/W) - This device is for printing patients’ info etc.
▪ Wi-Fi router - Wi-Fi router is used to for internetwork operations inside of a
hospital and simply data transmission from pc’s to sever.

❖ Software Interfaces
▪ JDK 1.8 - Java is fast, secure, and reliable. From laptops to data centers, game
consoles to scientific supercomputers, cell phones to the Internet,
▪ Mysql server - Database connectivity and management
▪ OS Windows 7/8/8.1- Very user friendly and common OS
▪ JRE 1.8 - JAVA Runtime Environment for run Java Application and System
2. System Specifications

1. H/W Requirement
 Core i5 processor  2GB Ram.
 20GB of hard disk space in terminal machines
 1TB hard disk space in Server Machine
2. S/W Requirement
 Windows 7 or above operating system
 JRE 1.8
 Mysql server

3. Communication Interfaces

 NIC (Network Interface Card) – It is a computer hardware component that

allows a computer to connect to a network. NICs may be used for both wired
and wireless connections.
 CAT 5 network cable- for high signal integrity
 TCP/IP protocol- Internet service provider to access and share information over
the Internet
 Ethernet Communications Interface- Ethernet is a frame-based computer
network technology for local area networks (LANs)
 Ubiquitous, easy to set up and easy to use. Low cost and high data
transmission rate.

2. Product functions
o Provide access to registered users only.
o Registration of new patients.
o Enable patient to view their record.
o Enable patient to update their record.
o Generate appointment date and timing.
o Confirmation by doctor. o Patients can do Payment.
o Modification in schedule by patient.
O Admin access to patient’s record.
o Admin Verify Payment and Generate Bill/Receipt.
o Admin can view monthly/yearly records.
2.3 DATA FLOW DIAGRAM
(DFD)

CONTEXT LEVEL DIAGRAM

FIGURE 2.1 CONTEXT LEVEL DFD

DFD LEVEL – 1

FIGURE 2.2 LEVEL – 1 DFD

FIGURE 2.3 LEVEL – 2 Registration

FIGURE 2.4 LEVEL – 2 Login

FIGURE 2.5 LEVEL – 2 Make Appointment

FIGURE 2.6 LEVEL – 2 Add Description

FIGURE 2.7 LEVEL – 2 Doctor Module

FIGURE 2.8 LEVEL – 2 Payment

FIGURE 2.9 LEVEL – 2 Cancel Appointment

FIGURE 2.10 LEVEL – 2 Patient Module

2.4 USE CASE DIAGRAM
5. USE CASE DESCRIPTION

(1) PATIENT

* REGISTRATION
DESCRIPTION - The new patient can register themselves and add their details like name,
age , gender, blood group etc. The patient entry will be made in the hms database.

PRE -CONDITION – The patient must be a new patient, If necessary fields left by user
then prompt user to fill the necessary fields.

MAIN FLOW OF EVENTS

1. Patient selects sign up in login module. 2.
A registration form get displayed
3. Patient fills the required details.

POST CONDITIONS - Patient record is added

to hms database.

* UPDATION
DESCRIPTION-The patient should be enabled to update his/her details and the changes
should reflect in hms database.

PRE-CONDITION – The patient must be a registered patient, The patient cannot update
details after treatment starts.

MAIN FLOW OF EVENTS

1. Patient logs in to the system.
2. Patient view his record
3. Patient selects update details.
4. Now patient may change the necessary fields.
5. Pop of update details.

POST CONDITION - The record of patient is updated in hms database.

*APPOINTMENT
DESCRIPTION - It shows users a list of available doctors, timings, dates and enables
patients to select the most suitable appointment date and doctor. The patient may also
the cancel the appointment.

PRE-CONDITION - The patient must be a registered patient, Patient can fix only one
appointment for a particular department.

MAIN FLOW OF EVENT

1. Patient first logs in to system.
2. View his/her record.
3. Create a new appointment or cancel the appointment..

POST CONDITIONS - patient details are displayed and a new appointment is fix or a
existing appointment is cancelled. The hms database is updated.

*PAYMENT
DESCRIPTION – It enables user to pay the consultant fee of Doctor online.

PRE-CONDITION - The patient must be a registered patient, If Patient don’t wants to pay
online he/she can pay by cash also.

MAIN FLOW OF EVENT

4. Patient first logs in to system.
5. View his/her record.
6. Appointment confirmed by the Doctor then go for Payment.

POST CONDITIONS – A Reciept will be displayed. The hms database is updated

(2) DOCTOR
DESCRIPTION- The doctor view patient record/ update his details and add description of
the treatment given to patient.

PRE-CONDITION – The doctor must be a registered doctor, System does not allow the
doctor to modify the qualification, hospital managed details.

MAIN FLOW OF EVENTS

1. Doctor logs in to the system.
2. Doctor may select view patient.
1. Patient record is displayed with treatment history.
3. Doctor add description of patient treatment.
4. Doctor may select appointment details
1. Appointment Requests is displayed with schedule.
5. Doctor confirm or cancel appointment.

POST CONDITION – The patient and doctor ‘s database are updated.

(3) ADMIN

DESCRIPTION - The admin add doctor, update docotr details and verify payment and
generate Bill/Reciept for the same.

MAIN FLOW OF EVENTS

6. Admin logs in the system.
7. Admin may add doctor new doctor.
1. admin fills the doctor’s details.
8. Admin view Doctor record.
1. Admin enters the doctor id in the system.
2. Doctor details are displayed, Admin can update details.
9. Admin Verify the payment submited by the Patient.
1. Generate Bill/Reciept and confirmation message for the same.

PRE –CONDITION - Admin must first log in with his/her credentials.

POST CONDITION - The hms database is updated.

2.6 User characteristics
ADMIN
Admin has the full access to the system which means he is able to manage any activity
with regard to the system. He is the highest privileged user who can access to the system.

Key functions:
• Access patient record, doctor Record.
• Add new doctor entry in system database.
•Confirm Payment and Generate Bill.
•View Records.(Total no of patients treated, doctor added/remove, consultant fee).

PATIENT
Patients can choose the best preferred appointments from the options provided and can
also change the appointment schedule or cancel it. After appt. is confirmed by the
respective doctor they can pay their consultant fee online. Patients have access to only
their records.

Key functions:
•Make appointment.
•Cancel appointment.
•Update Details.
•Payment.
•View Payment History.
DOCTOR
Doctors can view the patient appointment list and provide the confirmation or make
changes in the appointment list if required. Doctors have access to only records of those
patients whom they are treating.

Key functions:
•Confirmation of appointment.
•Cancellation of appointment.
•Modification of appointment
list.
•Add Prescription.

7. Constraints
•System is wirelessly networked with an encryption.
•System is only accessible within the hospital’s website only.
•Database is password protected.
•Should use less RAM and processing power.
•Each user should have individual ID and password.
•Only administrator can access the whole system.

8. Assumptions and dependencies

▪ Each user must have a valid user id and password ▪ Server must be
running for the system to function ▪ Users must log in to the system
to access any record.
▪Only the Administrator can delete records.
CHAPTER 3
SPECIFIC REQUIREMENTS
1. Performance requirements
2. Safety requirements
3. Security constraints
4. Software system attributes
1. Usability
2. Availability
3. Correctness
4. Maintainability
5. Accessibility
5. Functional Requirements
3.1 PERFORMANCE REQUIREMENTS
oResponse time- The system will give responses within 1 second after checking the
patient information and other information.
o Capacity-The system must support 1000 people at a time
o User interface- User interface screen will response within 5 seconds

2. SAFETY REQUIREMENTS
If there is extensive damage to a wide portion of the database due to catastrophic failure,
such as a disk crash, the recovery method restores a past copy of the database that was
backed up to archival storage and reconstructs a more current state by reapplying or
redoing the operations of committed transactions from the backed up log, up to the time
of failure. All the administrative and data entry operators have unique logins so system can
understand who is login in to system right now no intruders allowed except system
administrative nobody cannot change record and valuable data.

3. SECURITY REQUIREMENTS

1. Want take the responsibility of failures due to hardware malfunctioning.

2. Warranty period of maintaining the software would be one year.
3. Additional payments will be analyzed and charged for further maintenance.
4. If any error occur due to a user’s improper use. Warranty will not be allocated to it.
5. No money back returns for the software.

4. SOFTWARE SYSTEM ATTRIBUTES

1. Usability: Software can be used again and again without distortion.

2. Availability: The system shall be available all the time.

3.Correctness: Bug free software which fulfills the correct need/requirements of

the client.

4.Maintainability: The ability to maintain, modify information and update fix

problems of the system.

5.Accessibility: Administrator and many other users can access the system but the
access level is controlled for each user according to their work scope.
3.5 FUNCTIONAL REQUIREMENTS

S.No. MODULE APPLICABLE DESCRIPTION

NAME ROLES
1. LOGIN PATIENT PATIENT: Can login using unique Id and
DOCTOR Password after this system shall show his/her
ADMIN profile.
DOCTOR: Can login using unique Id and
Password after this system shall show his/her
profile.
ADMIN: Can login using unique Id and
Password after this system shall show a profile
with links to maintain the website.

2. REGISTRATION PATIENT PATIENT: Can Register by filling all the required

details, after this the system will verify the
details and check if already registered or not.

3. MAKE APPT. PATIENT PATIENT: Can Select doctor, date time and
make an appointment request after this system
shall show a confirmation for appointment
request.

4. CANCL APPT. PATIENT PATIENT : Can Cancel appointment if want to

DOCTOR by just one click after this system shall ask for
re-schedule or refund of payment.
DOCTOR : Can Cancel appointment if want to
by just one click after this system shall send a
message to the patient.

5. PAYMENT PATIENT PATIENT : Enter payment details and make

payment after this system shall show the
generated bill by the hospital.

6. DOCTOR ADMIN ADMIN : Can add a new doctor by filling all the
MODULE details after this system shall show a
confirmation message.
Can Remove a doctor by just one click after
this
system shall show confirmation message.
7. PATIENT PATIENT PATIENT : Can view payment history or can
MODULE search for a particular bill also after this system
shall show a bill or history.
Can also See or search for a doctor by entering
dept. name or doctor id if known after this
system will check for the doctor if found shall
show doctor’s profile.
Can also update details after this system shall
ask for re-enter password and after verifying
password shall update details.

8. ADD DOCTOR DOCTOR : Enter Patient Id and after this all the
PRESCRIPTION treatment details and medicine, remark and
advice for the patient after this system shall
show a message for update.
CHAPTER 4
DESIGN

1. Data Dictionary
2. ER Diagram
3. Data Design
4. Component Level Diagram
4.1 DATA
DICTIONARY
1. legal_character [a-z| A-Z]
2. Dig it [0-9]
3. special_ch [@|$|#|+|-]
4. Blood [A|B|AB|O]

1. Name first_name + (middle_name) + last_name

2. first_name {legal_character}*
3. middle_name {legal_character}*
4. last_name {legal_character}*
5. P_ID {legal_character + digit}*
6. D_ID {legal_character + digit}*
7. A_ID {legal_character + digit}*
8. Password {legal_character + digit + special_ch}*
9. Address House_no + (Street) + City
10. House_no {legal_character + digit}*
11. Street {legal_character}*
12. City {legal_character}*
13. Mobile No. { digit }*
14. Blood_Group {Blood + special_ch}*
15. Specialization {legal_character}*
16. Consultant Fee { digit }*
17. Medicine {legal_character + digit}*
18. Advice {legal_character + digit}*
19. Remark {legal_character + digit}*

Table 4.1 Data Dictionary

4.2 ER DIAGRAM
4.3 DATA
DESIGN DESCRIPTION
S NO. COLUMN DAT CONSTRAINTS
NAME A
TYPE
1. P_ID Varchar(50) Primary Key Contains Unique Id
2. Name Varchar(50) - Contains Name
3. DOB Varchar(50) - Contains Date Of Birth

4. Gender Varchar(50) - Contains Gender

5. Blood Group Varchar(50) - Contains Blood Group
6. Email ID Varchar(50) - Contains Email Id
7. Address Varchar(50) - Contains Address
8. Mobile No. Integer - Contains Mobile No.
9. CGHS/Private Varchar(50) - Contains Category
Table 4.2 Patient

DESCRIPTION
S NO. COLUMN DAT CONSTRAINTS
NAME A
TYPE
1. P_ID Varchar(50) Primary Key Contains Unique Id
Patient
2. Specialization Varchar(50) - Contains Name of the
Department in which
Patient wants to visit

3. Doctor’s Name Varchar(50) - Contains Doctor

Name Patient Wants
To Visit

4. Consultant Fee Integer - Contains Consultant

Fee Of Doctor
5. Date Date - Contains Date For The
Appointment
6. Time Time - Contains Time For The
Appointment
Table 4.3 Appointment
CONSTRAINTS DESCRIPTION
S NO.
COLUMN NAME DATA TYPE

1. D_ID Varchar(50) Primary Key Contains unique ID

2. Age Integer - Contains age
3. Gender Varchar(50) - Contains gender
4. Specialization Varchar(50) - Contains specialization

5. Experience Varchar(50) - Contains experience

of the doctor (In
months)

6. Language Varchar(50) - Contains in how many

languages doctor can
speak.

7. Mobile No. Integer - Contains mobile

number
8. Email ID Varchar(50) - Contains Email Id
9. Schedule Varchar(50) - Contains day and time
for which the doctor is
available

Table 4.4 Doctor

COLUMN DAT CONSTRAINTS DESCRIPTION
S NO.
NAME A
TYPE
1. D_ID Varchar(50) - Contains unique ID
2. P_ID Varchar(50) Primary Key Contains unique ID
3. Medicine Varchar(50) Contains name of the
medicine.
4. Remark Varchar(50) Contains Remark given by the
doctor for the patient.

5. Advice Varchar(50) Contains any advice for the

patient.

Table 4.5 Prescription

DESCRIPTION
S NO. COLUMN DAT CONSTRAINTS
NAME A
TYPE
1. A_ID Varchar(50) Primary Key Contains unique ID.
2. Name Varchar(50) - Contains Name
3. DOB Varchar(50) - Contains Date Of Birth

4. Gender Varchar(50) - Contains Gender

5. Email ID Varchar(50) - Contains Email Id
6. Mobile No. Integer - Contains Mobile No.
7. Address Varchar(50) - Contains Address
Table 4.6 Admin

DESCRIPTION
S NO. COLUMN DAT CONSTRAINTS
NAME A
TYPE
1. P_ID Varchar(50) - Contains unique ID.
2. Bill No. Varchar(50 Primary Key Contains number of
the bill.
3. Date Varchar(50 - Contains Date of The
bill.
4. Time Varchar(50 - Contains Time of the
bill generated.
5. Amount Int - Contains amount of
the bill.
Table 4.7 Bill
4.4 COMPONENT LEVEL DIAGRAM
Book Appointment Module
enum Status { confirm , cancel} ;

int Department, Date , Time, mode, ch;

char Dr_Name(50);

cout<< Enter The Information :

cin>> Department;
cin>>Dr_Name;
cin>> Date; cin>>
Time;
bool
Appointment =
cancel;

cout<<Mode; cout<<1.Cash;
cout<<2.Debit Card/Credit Card
cout<<3.Net Banking
cout<<Enter mode of
payment; cin>>mode;

if(mode==1)
{
Generate a
Receipt and send
confirmation message;
}
else if(mode == 2)
{
Enter Card Details
Make Payment
Send
confirmation
message
}
else
{
} //end if

Send appointment Request to the doctor

Doctor will check the Appointment Requests;

cout<<Mode;
cout<<1.Confirm;
cout<<2.Cancel;
cout<<Enter Your choice;
cin>>ch;

if(ch==1)
{
Appointment =
Confirm;
Send a Confirm
Message to the
patient.
}
else
{
Send a Cancel
Message to the
patient.
}//end if
CHAPTER 5
ESTIMATION AND SCHEDULING
1. Project Scheduling
2. Timeline chart
3. Size Estimation (FUNCTION BASED METRICS)
4. Cost Estimation (COCOMO II MODEL)
5.1 Project Scheduling
Planne Actu Planne Actual Assigned
TASK ~> d
d al person
Start Start comple comple
te te
PROBLEM STATEMENT Jan W1 Jan W1 Jan Jan W1 Rahul,
Manisha,
W1 Antara
SOFTWARE MODEL Jan
Jan W2 Jan W2 Jan W3 Antara,
Manisha
W2
PROJECT Jan
Jan W2 Jan W2 Jan W3 Manisha,
SCHEDULIN
G Antara
W3
SRS Fe
Jan W3 Jan W3 Feb W1 Manisha,
b
Antara
W1
CONTEXT Fe
Feb W1 Feb W1 Feb W2 Rahul, Manisha
LEVEL b
DIAGRAM W1
DFD LEVEL - 1 Fe
Feb W2 Feb W2 Feb W3 Antara,
b
Manisha
W2
DFD LEVEL - 2 Feb W3 Feb W3 Fe Feb W4 Rahul,
b Manisha,
W3 Antara
DATA DICTIONARY Ma
Mar W1 Mar W1 Mar W1 Rahul, Manisha
r
W1
ER DIAGRAM Ma
Mar W1 Mar W1 Mar W2 Rahul
r
W2
DATA DESIGN Ma
Mar W2 Mar W2 Mar W2 Manisha
r
W2
USE CASE DIAGRAM Ma
Mar W3 MarProject
Table 5.1 W3 Scheduling Mar W3 Manisha
r
W3
USE CASEJan – January Feb – February Mar – MarchMa Apr – April W - Week
Mar W4 Mar W4 Mar W4 Manisha, Rahul
DISCRIPTI r
ON W4
FUNCTION POINT Ma Rahul,
Mar W3 Mar W3 Mar W4
MATRIX r Manisha,
W3 Antara
COCOMO MODEL Apr W1 Apr W1 Apr W1 Apr W1 Rahul,
5.2 Timeline chart
Table 5.2 Timeline Chart

3. Size Estimation (FUNCTION BASED METRICS)

Information domain values are defined in the following manner:

• Number of external inputs (EIs) - Each external input originates from a user or is
transmitted from another application and provides distinct application-oriented
data or control information. Inputs are often used to update internal logical files
(ILFs). Inputs should be distinguished from inquiries, which are counted separately.

• Number of external outputs (EOs) - Each external output is derived data within
the application that provides information to the user. In this context external
output refers to reports, screens, error messages, etc. Individual data items within
a report are not counted separately.

• Number of external inquiries (EQs) - An external inquiry is defined as an online

input that results in the generation of some immediate software response in the
form of an online output (often retrieved from an ILF).

• Number of internal logical files (ILFs) - Each internal logical file is a logical
grouping of data that resides within the application’s boundary and is maintained
via external inputs.

• Number of external interface files (EIFs). - Each external interface file is a logical
grouping of data that resides external to the application but provides information
that may be of use to the application.
SIZE ESTIMATION FOR THIS PROJECT
Screen EIs EOs EQs ILFs EIFs
No
1. 1.Select - 1.Doctor’s On Hospital File -
Language Leave
2.Visitors on
Website

2. - - - - -
3. 1. Username - - Hospital File -
2. Password
4. 1 .Name - - Hospital File -
2 .Dob
3. Gender
4 .Email
5. Blood Group
6 .Mobile No
7 .Address
8.CGHS / Private
9.Card Picture

5. - 1.Profile - HF -
6. 1. Department - - Hospital File -
2 .Date
3 .Time
4 .Doctor
Name

7. 1.Appointment Hospital File -

Status
8. 1 .Card Holder - - Hospital File -
Name
2. Card
number
3. Expire Date
4. CVC
Number
9. 1.Registered - - Hospital File -
Mobile No.
2.Edit Appt.
Schedule

10. - - 1.Paymen Hospital File -

t History
11. - 1.Profile - HF -
12. 1.Doctor ID 1.Doctor Hospital File -
Details
13. - 1.Bill - Hospital File -

14. 1. Username - - Hospital File -

2. Password
15. - 1. Profile Hospital File -

16. - - 1.appt. Hospital File -

Details
17. 1. Treatment 1.Patient - Hospital File -
Name Profile
2 .Medicine
3 .Advice
4.Remark
5.Patient
ID
18. 1. Username - - Hospital File -
2. Password
19. 1.Payment - - Hospital File -
Verify
20. 1 Name - - Hospital File -
2 Age
3 Gender
4 Specialization
5 Experience
6 Language
7 Mobile No
8 Email Id
9 Schedule

21. 1.Doctor Id 1.Doctor - Hospital File -

Profile
22. 1.Select - 1.Records Hospital File -
Monthly/Yearl
y 2.Select Year
3.Select Month

TABLE 5.3 Function Point Complexity Weights

TOTAL EXTERNAL INUPUTS = 41
TOTAL EXTERNAL OUTPUTS = 7
TOTAL LOGICAL INTERNAL FILES = 1
TOTAL EXTERNAL INQUIRIES = 6
TOTAL EXTERNAL INTERFACE FILES
=0

Function point = FP = UFP x CAF = Count Total * (0.65 + (0.01 *∑ 𝒇𝒊)

UFP (Count Total) = Sum of all the complexities i.e. the 5 parameters
provided in the question,
CAF = Complexity Adjustment Factor i.e. 0.65 + (0.01 * ∑fi),
CALCULATING ( ∑ 𝒇𝒊 )

Total Degree of Influence of the 14 General System Characteristics

1. How many communication facilities are there to aid in the transfer or exchange of
information with the application or system?

2. How are distributed data and processing functions handled?

3. Did the user require response time or throughput?

4. How heavily used is the current hardware platform where the application will be executed?

5. How frequently are transactions executed daily, weekly, monthly, etc.?

6. What percentage of the information is entered online?

7. Was the application designed for end-user efficiency?

8. How many ILFs are updated by online transaction?

9. Does the application have extensive logical or mathematical processing?

10. Was the application developed to meet one or many user’s needs?

11. How difficult is conversion and installation?

12. How effective and/or automated are start-up, back-up, and recovery procedures?

13. Was the application specifically designed, developed, and supported to be installed at
multiple sites for multiple organizations?

14. Was the application specifically designed, developed, and supported to facilitate change?

Considering all adjustment factors of average influence ∑ 𝒇𝒊 = 14 * 3 =

42

TOTAL EXTERNAL INUPUTS = 41

TOTAL EXTERNAL OUTPUTS = 7
TOTAL LOGICAL INTERNAL FILES = 1
TOTAL EXTERNAL INQUIRIES = 6
TOTAL EXTERNAL INTERFACE FILES =
0

Assuming all the parameters are of

SIMPLE COMPLEXITY.
UFP (Count Total) = {41 * 3} + {7 * 4}
+ {1 * 3} + {6 * 7} + {0 * 5} = 196

of average influence ∑ 𝒇𝒊 = 14 *
Considering all adjustment factors

3 = 42

(0.65 + (0.01 *∑ 𝒇𝒊)

Function point = FP = Count Total +

= 196 * (0.65 +
(0.01 * 42)
FUNCTION POINT = 209.72
= 196 * (0.65 +
(0.42)
= 196 * (1.07)
5.4 Cost Estimation (COCOMO II MODEL)

The original COCOMO model became one of the most widely used and discussed
software cost estimation models in the industry. It has evolved into a more
comprehensive estimation model, called COCOMO II.

COCOMO II models require sizing information. Three different sizing options are
available as part of the model hierarchy:- o Object Points
o Function Points
o Lines Of Source Code

The COCOMO II application composition model uses object points.

Like function point, the object point is an indirect software measure that is computed
using counts of the number of
(1) screens (at the user interface),
(2) reports,
(3) components likely to be required to build the application.
Each object instance (e.g., a screen or report) is classified into one of three complexity
levels (i.e. ,simple ,medium, or difficult).
Once complexity is determined, the number of screens, reports, and components are
weighted according to the table illustrated in Table 5.4 .

TABLE 5.4 COCOMO II Complexity Weights

OBJECT TYPE COMPLEXITIY WEIGHT
SIMPLE MEDIUM DIFFICULT
SCREEN 1 2 3
REPORT 2 5 8
3GL COMPONENT 10

The object point count is then determined by multiplying the original number of object
instances by the weighting factor in the figure and summing to obtain a total object point
count.

When component-based development or general software reuse is to be applied, the

percent of reuse (%reuse) is estimated and the object point count is adjusted:

NOP = (Object Point) * [ (100 - %reuse) / 100 ]

where NOP = defined as new object points.

To derive an estimate of effort based on the computed NOP value, a “productivity rate”
must be derived.

𝐍𝐎𝐏

𝐏𝐞𝐫𝐬𝐨𝐧−𝐌𝐨𝐧𝐭𝐡
PROD =

Table 5.5 presents the productivity rate for different levels of developer experience and
development environment maturity. Once the productivity rate has been determined, an
estimate of project effort is computed using

𝐍𝐎𝐏

𝐏𝐑𝐎𝐃
ESTIMATED EFFORT =

TABLE 5.5 Productivity Rate For Object Point Counts

Developer’s experience/capability Very Low Low Normal High Very high
Environment maturity/capability Very Low Low Normal High Very high

PROD 4 7 13 25 50
COST ESTIMATION FOR THIS PROJECT

(1) SCREENS

1. Home Page. 12. Login Page For Doctor.

2.Select Login. 13.Doctor Profile.
14.Appointment Details
15. View Patient by Doctor
17.Login Page For Admin. 16. Add Prescription
18.Generate Bill.
19.Update Doctor Details.
20.Add Doctor.
21.View doctor By Admin.
22.View Records.

2. Login Page For Patient .

3. Registration For Patient.
4. Patient Profile.
5. Patient Update Details.
6. Book Appointment .
7. View Appointment Status .
8. Cancel Appointment.
9. Payment By Patient.
10. Receipt Of Payment .

(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 .

TOTAL SCREENS = 22
TOTAL 3GL MODULES = 0
TOTAL REPORTS = 8

CONSIDERING ALL OF THE ABOVE HAVE MEIDEM COMPEXITY, 0% OF

COMPONENTS ARE REUSED AND TAKING THE DEVELOPER EXPERIENCE AND
ENVIRONMENT MATURITY AS LOW.

PRODUCTIVITY RATE = = 7.

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

NOP 8
ESTIMATED EFFORT = =4 = 12 Person-Months.
PROD
7
CHAPTER 6
SAMPLE SCREENSHOTS
FIGURE 6.1 HOME PAGE
FIGURE 6.2 SELECT LOGIN
FIGURE 6.3 PATIEN LOGIN PAGE

FIGURE 6.4 REGISTRATION

FIGURE 6.5 PATIENT BOOK APPOINTMENT
FIGURE 6.6 PATIENT CANCEL APPOINTMENT
FIGURE 6.7 PAYMENT
FIGURE 6.8 PATIENT VIEW PAYMENT HISTORY
FIGURE 6.9 PATIENT VIEW DOCTORS
FIGURE 6.10 DOCTOR LOGIN PAGE
FIGURE 6.11 DOCTOR PROFILE
FIGURE 6.12 ADMIN LOGIN PAGE
FIGURE 6.13 ADMIN ADD DOCTOR
FIGURE 6.14 ADMIN UPDATE DOCTOR DETAILS

FIGURE 6.15 ADMIN VIEW RECORDS

CHAPTER 7
RISK ANALYSIS
S.No RISK CATEGORY PROBABLITY IMPAC RMMM
(P) T (I) PLAN
1. TECHNICAL 20% 2 OTHER TEAM
SOME TEAM RISK
MEMBER MEMBERS
BECOME SICK IN DISTRIBUTE THE
BETWEEN WORK IN
BETWEEN THEM
2. PROJECT RISK 30% 1
TEAM MAY USE
DELIVERY
DEADLINE EXTRA MEMBERS
TIGHTENED TO DO JOB ON
SCHEDULED TIME

3. LOSING OF ALL PROJECT RISK 20% 2

BACK UP THE
PROJECT DATA PROJECT ONLINE
THIS MAY OR IN EVERY
HAPPEN DUE TO SYSTEM OF EVERY
HARD DISK MEMBER
FAILURE

4. TEAM PROJECT RISK 10% 3

WE MAKE SOME
DISTENTION / RULES HOW WE
LACK OF CONSULT EACH
COHESION OTHER

TABLE
7.1

CHAPTER 8
TESTING
1. WHITE BOX TESTING
1. Basic Path ( Pseudo code )
2. Flow Graph
3. Cyclomatic Complexity
4. Independent Paths
BASIS PATH TESTING FOR BOOK APPOINTMENT MODULE
enum Status { confirm , cancel} ;

int Department, Date , Time, mode, ch;

char Dr_Name(50);

cout<< Enter The Information :

cin>> Department;
cin>>Dr_Name;
cin>> Date; cin>>
Time;
bool 1
Appointment =
cancel;
cout<<Mode; cout<<1.Cash;
cout<<2.Debit Card/Credit Card
cout<<3.Net Banking
cout<<Enter mode
of payment; cin>>mode;
if(mode==1) 2

{
Generate a
Receipt and send
{
confirmation message;
Enter Card Details
3
Make Payment
}
Send
else if(mode == 2)
confirmation
message
}4
else
{

Enter Account Details

Make Payment
Send confirmation
message
Send appointment Request to the doctor 8
} //end if
Doctor will check the Appointment Requests;
cout<<Mode;
7 cout<<1.Confirm;
cout<<2.Cancel; 9
cout<<Enter Your choice; cin>>ch;

if(ch==1) 10
{
Appointment = Confirm;
Send a Confirm Message to the patient. 11
}
else
{
Send a Cancel Message to the patient.
}//end if 13

FLOW GRAPH NOTATION

2) CYCLOMATIC COMPLEXITY V(G)
1. Cyclomatic complexity V(G) = Total number of Regions.
V(G) = 4.
2.Cyclomatic complexity V(G) = (E – N) + 2 where E = the
number of flow graph edges. i.e. 15 N = the number
of flow graph nodes. i.e. 13 V(G) = (15 – 13) + 2 = 4.

3.Cyclomatic complexity V(G) = P + 1 where P = the number of

predicate nodes contained in the flow graph G. V(G) = 3 + 1
= 4.

There will be 4 independent Paths.

3) INDEPENDENT PATHS

Path A : 1 – 2 – 3 – 7 – 8 – 9 – 10 – 11 – 13

Path B : 1 – 2 – 4 – 5 – 7 – 8 – 9 – 10 – 12 – 13

Path C : 1 – 2 – 4 – 6 – 7 – 8 – 9 – 10 – 11 – 13

Path D : 1 – 2 – 3 – 7 – 8 – 9 – 10 – 12 – 13

CHAPTER – 9
CONCLUSION
Working on the project was an excellent experience. It helped us to understand the
importance of planning, designing and implementation so far we have learnt in our
theory books. It helped us unleashing our creativity while working in a team. It also
realized the importance of team working, communication as a part of this project.

The project was successfully completed after a lot of efforts and work hours. This project
underwent number of compiling, debugging, removing errors, making it bug free, adding
more facilities in Hospital Management System and interactivity making it more reliable
and useful.

This project focused that scheduling a project and adhering to that schedule creates a
hard sense of time- management. It has also let us known that co-operative teamwork
always produce effective results.

The entire project has been developed and deployed as per the requirements stated by
the user. It is found to be bug free as per the testing standards that are implemented.

The estimated cost of the project is (efforts) 12 and the estimated size of the project
is (FP) 209.72.

There are also few features which can be integrated with this system to make it more
flexible. Below list shows the future points to be consider :

• Getting the current status of patient.

• Including a different module for pharmacy, LAB, Bed Allotment and many
more.
• Including a Frequently Asked Questions Section.
Finally, we like to conclude that we put all our efforts throughout the development of
our project and tried to fulfill most of the requirements of the user.