A

PROJECT REPORT

ON

Hospital Management System

Submitted to

Jagannath University, Jaipur

In Partial Fulfillment of the requirement for the degree of

BACHELOR OF TECHNOLOGY

JAGANNATH UNIVERSITY

Jaipur, (Rajasthan) 302022

B.TECH (2019-2023)

Submitted To: Submitted By:

Mr. Hukum Chand Saini Shubham Kumar

Assistant Professor 1902003
Department of Computer Science
Jagannath University, Jaipur.
 DECLARATION

I hereby declare that the work, which is being presented in the B.Tech, Project, entitled
‘Hospital Management System’ in partial fulfillment for the award of Degree of ‘Bachelor
of Technology’ in Department of Computer Science submitted to the Jagannath University,
Jaipur, is a record of my own work carried under the guidance of Mr. Hukum Chand Saini .

I have not submitted the matter presented in this Project Report anywhere for the award of any
other Degree.

Submitted To: Submitted By:

Mr. Hukum Chand Saini Shubham Kumar

Assistant Professor 1902003

Department of Computer Science

Jagannath University, Jaipur

1|Page
 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 guide Mr. Hukum Chand Saini 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.

Shubham Kumar (1902003)

2|Page
 CERTIFICATE

This is to certify that Major project report entitled "Hospital Management System" is the work
carried out Shubham Kumar, Kuldeep Sharma students of B.Tech Computer Science VIII
Semester, Jagannath University of Jaipur under the supervision of Mr. Hukum Chand
Saini, Assistant Professor, Department of Computer Science, Jagannath University.
This report has not been submitted to any other organization/institution for the award any other
Degree/Diploma.

Mr. HUKUM CHAND SAINI

(Project Guide)

3|Page
 ABSTRACT

Our project Hospital Management system includes registration of patients, storing their details
into the system, and 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 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 beretrieved 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.
The Patient modules include checking appointments, B i l l Due and Paid.

4|Page
 TABLE OF CONTENTS

S.NO. TOPIC PAGE NO.

1. PROBLEM STATEMENT 9
2. PROCESS MODEL 11
3. INTRODUCTION 12
4. SOFTWARE REQUIREMENTS SPECIFICATION 15
5. CONTEXT LEVEL DIAGRAM 17
6. DFD LEVEL 1 18
7. DFD LEVEL 2 19
8. USE CASE DIAGRAM 26
9. USE CASE DESCRIPTION 27
10. DATA DICTIONARY 37
11. ER DIAGRAM 38
12. DATA DESIGN 39
13. PROJECT SCHEDULING 44
14. FUNCTION POINT METRICS 47
15. COCOMO MODEL 48
16. SAMPLE SCREENSHOTS 54
17. CONCLUSION 67

5|Page
 LIST OF FIGURES USED IN THE PROJECT

FIGURE_NO. NAME PAGE No.

2.1 CONTEXT LEVEL DFD 17

2.2 LEVEL – 1 DFD 18

2.3 LEVEL – 2 REGISTRATION 19

2.4 LEVEL – 2 LOGIN 20

2.5 LEVEL – 2 MAKE APPOINTMENT 21

2.6 LEVEL – 2 DOCTOR MODULE 22

2.7 LEVEL – 2 PAYMENT 23

2.8 LEVEL – 2 CANCEL APPOINTMENT 24

2.9 LEVEL – 2 PAITENT MODULE 25

3.0 USE CASE DIAGRAM 26

3.1 ER DIAGRAM 38

4.1 HOME PAGE 54

4.2 SELECT LOGIN 55

4.2 USER LOGIN PAGE 56

4.3 USER REGISTRATION 56

4.4 PATIENT BOOK APPOINMENT 57

4.5 PATIENT VIEW APPOINMENT 58

6|Page
4.6 PATIENT APPOINMENT STATUS 59

4.7 PAYMENT-BILL RECEIPT 60

4.8 ADMIN LOGIN PAGE 61

4.9 ADMIN LOGOUT 61

4.10 ADMIN HOME 62

4.11 ADMIN ADD AND UPDATE 63

DOCTOR DETAILE

ADMIN VIEW ALL APOINMENT

4.12 & CENCILE APPOINMENT 64

4.13 ADMIN GENERATE BILL 65

4.14 MANAGE ADMIN PROFILE 66

7|Page
 LIST OF TABLES USED IN THE PROJECT

TABLE NO. NAME PAGE NO.

4.1 DATA DICTIONARY 37

4.2 PATIENT 39
4.3 APPOINTMENT 40
4.4 DOCTOR 41
4.5 ADMIN 42
4.6 BILL 42
5.1 PROJECT SCHEDULING 44
5.2 FUNCTION POINT COMPLEXITY 47
WEIGHTS
5.3 COCOMO II COMPLEXITY WEIGHTS 48

8|Page
 PROBLEM STATEMENT

In this busy world we do not 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 cannot 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.

9|Page
Benefits of implementing a hospital management system:

 Appointment booking
 Helps patients cut the long queue and saves their time
 Is equipped with features like automated email and text message reminders
 Role-Based Access Control
 Allows employees to access only the necessary information to effectively perform
their job duties
 Increases data security and integrityOverall cost reduction
 Cuts down paper costs as all the data are computerized
 No separate costs for setting up physical servers
 Data accuracy
 Removes human errors
 Alerts when there is a shortage of stock
 Data security
 Helps to keep patients records private
 Restricts access through role-based access control
 Revenue management
 Makes daily auditing simple
 Helps with statistics and other financial aspects

10 | P a g e
 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 July 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 1 weeks only and staffing available is also
low (2 persons).

11 | P a g e
CHAPTER -1

INTRODUCTION

 PURPOSE
 SCOPE
 DEFINITIONS, ACRONYMS, and ABBREVIATIONS
 REFERENCES
 OVERVIEW

12 | P a g e
  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.

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

 DEFINITIONS, ACRONYMS, and ABBREVIATIONS

Cardiologist - treats heart disease.

Pediatrician - treats infants, toddlers, children and teenagers.
Plastic Surgeon - restores, reconstructs, corrects or improves in the shape and appearance of
damaged body structures, especially the face.
Psychiatrist - treats patients with mental and emotional disorders.
Ophthalmologist - treats eye defects, injuries, and diseases
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.
Ph No - Mobile number.
Add. – Address.
Expr – Experience.

13 | P a g e
  REFERENCES

https://www.officetimeline.com/make-gantt-chart/excel
https://medium.com/@datamateuaecrescent/hospital-management-system- features-
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).

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 toapply for the appointment and make transaction for the
same, and can even cancel appointments with the doctors. They can track details about the
previoustransactions 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

14 | P a g e
CHAPTER 2

SOFTWARE REQUIREMENTSPECIFICATION

 Product Perspective
 System Interfaces
 Data Flow Diagram (DFD)
 Context Level Diagram
 DFD Level – 1
 DFD Level – 2
 Use Case Diagram
 Use Case Description
 User characteristics
 Constraints
 Assumptions and dependencies

15 | P a g e
  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.

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

Software Interfaces
Python 3.11.3
MongoDB – Server
Tkinter - GUI

16 | P a g e
 CONTEXT LEVEL DIAGRAM

FIGURE 2.1 CONTEXT LEVEL DFD

17 | P a g e
 DFD LEVEL – 1

FIGURE 2.2 LEVEL – 1 DFD

18 | P a g e
FIGURE 2.3 LEVEL – 2 Registration

19 | P a g e
FIGURE: 2.4 LEVEL – 2 Login

20 | P a g e
FIGURE 2.5 LEVEL – 2 Make Appointment

21 | P a g e
FIGURE 2.6 LEVEL – 2 Doctor Module

22 | P a g e
FIGURE 2.7 LEVEL – 2 Payment

23 | P a g e
FIGURE 2.8 LEVEL – 2 Cancel Appointment

24 | P a g e
FIGURE 2.9 LEVEL – 2 Patient Module

25 | P a g e
 USE CASE DIAGRAM

26 | P a g e
  USE CASE DESCRIPTION

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 userthen prompt user to fill
the necessary fields.

MAIN FLOW OF EVENTS:

Patient selects sign up in login module.
A registration form get displayed
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:

Patient logs in to the system.
Patient view his record
Patient selects update details.
Now patient July change the necessary fields.
Pop of update details.

POST CONDITION:
The record of patient is updated in HMS database.

27 | P a g e
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 July 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:

Patient first logs in to system.
View his/her record.
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.

28 | P a g e
ADMIN DESCRIPTION:
The admin add doctor, update doctor details and verify payment and generate Bill/Receipt
for the same.

MAIN FLOW OF EVENTS:

Admin logs in the system.
Admin July add doctor new doctor.
admin fills the doctor’s details.
Admin view Doctor record.
Admin enters the doctor id in the system.
Doctor details are displayed, Admin can update details.
Admin Verify the payment submitted by the Patient.
Generate Bill/Receipt and confirmation message for the same.

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

POST CONDITION:
The HMS database is updated.

29 | P a g e
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 andcan 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

30 | P a g e
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.

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.

31 | P a g e
CHAPTER-3

SPECIFIC REQUIREMENTS

 Performance requirements
 Safety requirements
 Security constraints
 Software system attributes
 Usability
 Availability
 Correctness
 Maintainability
 Accessibility
 Functional Requirements

32 | P a g e
PERFORMANCE REQUIREMENTS:
Response time:
The system will give responses within 1 second after checking thepatient information and
other information.
Capacity:
The system must support 1000 people at a time.
User interface:
User interface screen will response within 5 seconds.

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.

SECURITY REQUIREMENTS:
Want take the responsibility of failures due to hardware malfunctioning.
Warranty period of maintaining the software would be one year.
Additional payments will be analyzed and charged for further maintenance.
If any error occur due to a user’s improper use. Warranty will not be allocated to it.
No money back returns for the software.

SOFTWARE SYSTEM ATTRIBUTES:

Usability:
Software can be used again and again without distortion.
Availability:
The system shall be available all the time.

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

Maintainability:
The ability to maintain, modify information and update fix problems of the system.

Accessibility:
Administrator and many other users can access the systembut the access level is controlled
for each user according to their work scope.

33 | P a g e
FUNCTIONAL REQUIREMENTS:

S.No. MODULE APPLICABLE DESCRIPTION

NAME ROLES

1. LOGIN PATIENT DOCTOR PATIENT: Can login using unique Id and

ADMIN Password after this system shall show
his/her 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

andmake an appointment request after this
system shall show a confirmation for
appointment request.

4. CANCL APPT. PATIENTDOCTOR PATIENT : Can Cancel appointment if

want to by just one click after this system
shall ask for re-schedule or refund of
payment.

DOCTOR : Can Cancel appointment if

wantto by just one click after this system
shall
send a message to the patient.
6. DOCTOR ADMIN ADMIN : Can add a new doctor by filling
MODULE allthe details after this system shall show
a confirmation message.
Can Remove a doctor by just one click
afterthis system shall show confirmation
message.

34 | P a g e
7. PATIENT PATIENT PATIENT : Can view payment history or
MODULE can 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
iffound 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.

35 | P a g e
CHAPTER-4

DESIGN

 Data Dictionary
 ER Diagram
 Data Design
 Component Level Diagram

36 | P a g e
 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. ReJunk {legal_character + digit}*

Table 4.1 Data Dictionary

37 | P a g e
ER DIAGRAM:

38 | P a g e
DATA DESIGN:

S NO. COLUMN NAME DATA TYPE CONSTRAINTS DESCRIPTION

1. P_ID Varchar PriJuny Key Contains Unique Id

(50)
2. Name Varchar - Contains Name
(50)
3. DOB Varchar - Contains Date Of
(50) Birth
4. Gender Varchar - Contains Gender
(50)
5. Blood Group Varchar - Contains Blood Group
(50)
6. Email ID Varchar - Contains Email Id
(50)
7. Address Varchar - Contains Address
(50)
8. Mobile No. Integer - Contains Mobile No.
9. CGHS/Private Varchar - Contains Category
(50)

Table 4.2 Patient

39 | P a g e
S NO. COLUMN NAME DATA CONSTRAINTS DESCRIPTION
TYPE

1. P_ID Varchar PriJuny Key Contains Unique Id

(50) Patient
2. Specialization Varchar - Contains Name of the
(50) Department in which
Patient wants to visit
3. Doctor’s Name Varchar - Contains Doctor Name
(50) 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

40 | P a g e
S NO. COLUMN NAME DATA CONSTRAINTS DESCRIPTION
TYPE

1. D_ID Varchar PriJuny Key Contains unique ID

(50)
2. Age Integer - Contains age
3. Gender Varchar - Contains gender
(50)
4. Specialization Varchar - Contains
(50) specialization
5. Experience Varchar - Contains experienceof the
(50) doctor
(In months)
6. Language Varchar - Contains in how many
(50) languages
doctor can speak.
7. Mobile No. Integer - Contains mobile
number
8. Email ID Varchar - Contains Email Id
(50)
9. Schedule Varchar - Contains day and time for
(50) which the
doctor is available

Table 4.4 Doctor

41 | P a g e
S NO. COLUMN NAME DATA CONSTRAINTS DESCRIPTION
TYPE

1. A_ID Varchar PriJuny Key Contains unique ID.

(50)
2. Name Varchar - Contains Name
(50)
3. DOB Varchar - Contains Date Of
(50) Birth
4. Gender Varchar - Contains Gender
(50)
5. Email ID Varchar - Contains Email Id
(50)
6. Mobile No. Integer - Contains Mobile No.
7. Address Varchar - Contains Address
(50)

Table 4.5 Admin

S NO. COLUMN NAME DATA CONSTRAINTS DESCRIPTION

TYPE

1. P_ID Varchar - Contains unique ID.

(50)
2. Bill No. Varchar PriJuny Key Contains number of
(50 the bill.
3. Date Varchar - Contains Date of The
(50 bill.
4. Time Varchar - Contains Time of the
(50 bill generated.
5. Amount Integer - Contains amount of
the bill.

Table 4.6 Bill

42 | P a g e
CHAPTER-5

ESTIMATION AND SCHEDULING:

 Project Scheduling
 Size Estimation (FUNCTION BASED METRICS)
 Cost Estimation (COCOMO II MODEL)

43 | P a g e
PROJECT SCHEDULING:

TASK ~> Planned Actual Planned Actual Assigned person

Start Start complete complete
PROBLEM STATEMENT July W1 July W1 July W1 July W1 Shubham & Kuldeep

SOFTWARE MODEL July W2 July W2 July W2 July W3 Shubham & Kuldeep

PROJECT SCHEDULING July W2 July W2 July W3 July W3 Shubham & Kuldeep

SRS July W3 July W3 May W1 May W1 Shubham & Kuldeep

CONTEXT LEVEL May W1 May W1 May W1 May W2 Shubham & Kuldeep

DIAGRAM
DFD LEVEL - 1 May W2 May W2 May W2 May W3 Shubham & Kuldeep

DFD LEVEL - 2 May W3 May W3 May W3 May W4 Shubham & Kuldeep

DATA DICTIONARY Jun W1 Jun W1 Jun W1 Jun W1 Shubham Kumar

ER DIAGRAM Jun W1 Jun W1 Jun W2 Jun W2 Shubham Kumar

DATA DESIGN Jun W2 Jun W2 Jun W2 Jun W2 Shubham Kumar

USE CASE DIAGRAM Jun W3 Jun W3 Jun W3 Jun W3 Shubham Kumar

USE CASE DISCRIPTION Jun W4 Jun W4 Jun W4 Jun W4 Shubham Kumar

FUNCTION POINT Jun W3 Jun W3 Jun W3 Jun W4 Shubham & Kuldeep

MATRIX
COCOMO MODEL July W1 July W1 July W1 July W1 Shubham & Kuldeep

RISK ANALYSIS July W1 July W1 July W1 July W1 Shubham & Kuldeep

TESTING July W1 July W1 July W1 July W1 Shubham & Kuldeep

44 | P a g e
SIZE ESTIMATION FOR THIS PROJECT:

Screen EIs EOs EQs ILFs EIFs

No

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

4. - 1.Profile - HF -
5. 1. Department - - HospitalFile -
2. Date
3. Time
4. Doctor Name
6. 1.Appointment Hospital -
Status File
7. 1. Registered Mobile No. - - HospitalFile -
2. Edit Appt. Schedule
8. - - 1.Payment Hospital -
History File
9. - 1.Profile - HF -

45 | P a g e
10. 1.Doctor ID 1.Doctor Hospital -
Details File
11. - 1.Bill - Hospital -
File
12. Username - - Hospital -
Password File
13. - 1. Profile Hospital -
File
14. - - 1.appt. Hospital -
Details File
15. 1. TreatmentName 1.Patient - HospitalFile -
2. Medicine Profile
3. Advice
4. Rejunk
5. Patient ID

16. Username - - Hospital -

Password File
17. Name - - HospitalFile -
Age
Gender
Specialization
Experience
Language
Mobile No
Email Id
Schedule

46 | P a g e
TABLE FUNCTION POINT COMPLEXITY WEIGHTS:

TOTAL EXTERNAL INUPUTS = 41 TOTAL EXTERNAL OUTPUTS = 7 TOTAL

LOGICAL INTERNAL FILES = 1TOTAL 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 parametersprovided in the question,

CAF = Complexity Adjustment Factor i.e. 0.65 + (0.01 * ∑fi),

47 | P a g e
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 applicationwill 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?

48 | P a g e
CONSIDERING ALL ADJUSTMENT FACTOR OF AVERAGE INFLUENCE ∑ 𝒇𝒊 = 14 *
3 = 42

TOTAL EXTERNAL INUPUTS = 41 TOTAL EXTERNAL OUTPUTS = 7 TOTAL

LOGICAL INTERNAL FILES = 1TOTAL 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

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

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

= 196 * (0.65 + (0.01 * 42)
= 196 * (0.65 + (0.42)
= 196 * (1.07)
= 209.72

FUNCTION POINT = 209.72

49 | P a g e
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 morecomprehensive estimation
model, called COCOMO II.

COCOMO II models require sizing information. Three different sizing options are available
as part of the model hierarchy:
Object Points
Function Points
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
screens (at the user interface),
reports,
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.3 COCOMO II Complexity Weights

OBJECT TYPE COMPLEXITIY WEIGHT

SIMPLE MEDIUM DIFFICULT
SCREEN 1 2 3
REPORT 2 5 8
3GL COMPONENT 10

50 | P a g e
The object point count is then determined by multiplying the original number of object

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

TABLE 5.4 Productivity Rate For Object Point Counts

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:

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.

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 =
𝐏𝐑𝐎𝐃

51 | P a g e
COST ESTIMATION FOR THIS PROJECT:

SCREENS:

1. Home Page. 12. Login Page for Doctor.

2. Select Login. 13. Doctor Profile.
3. Login Page for Patient. 14. Appointment Details.
4. Registration for Patient. 15. View Patient by Doctor.
5. Patient Profile. 16. Add Prescription.
6. Patient Update Details. 17. Login Page for Admin.
7. Book Appointment. 18. Generate Bill.
8. View Appointment Status. 19. Update Doctor Details.
9. Cancel Appointment. 20. Add Doctor.
10. Payment by Patient. 21. View doctor by Admin.
11. Receipt of Payment. 22. View Records.

REPORTS:

Total Visitors on Website.

Total Patients Treated.
Total Appointments Taken.
Total Appointments Cancelled.
Total Doctors on Leave.
Total Doctors Added.
Total Doctors Removed.
Total Consultant Fee Collected.

52 | P a g e
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+7 = 7.

=

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

ESTIMATED EFFORT NOP 84

= PROD = = 12 Person-Month

53 | P a g e
CHAPTER-6

SAMPLE SCREENSHOTS:

FIGURE 4.1 HOME PAGE

54 | P a g e
FIGURE 4.2 SELECT LOGIN

55 | P a g e
 FIGURE 4.3 USER LOGIN PAGE

FIGURE 4.4 USER REGISTRATION

56 | P a g e
FIGURE 4.5 PATIENT BOOK APPOINTMENT

57 | P a g e
FIGURE 4.6 PATIENT VIEW APPOINTMENT

58 | P a g e
FIGURE 4.7 PATIENT APPOINTMENT STATUS

59 | P a g e
FIGURE 4.8 PAYMENT-BILL RECEIPT

60 | P a g e
FIGURE 4.9 ADMIN LOGIN PAGE

FIGURE 4.10 ADMIN LOGOUT

61 | P a g e
FIGURE 4.11 ADMIN HOME

62 | P a g e
FIGURE 4.12 ADMIN ADD & UPDATE DOCTOR’ DETAILS

63 | P a g e
FIGURE 4.13 ADMIN VIEW ALL APPOINMENTS

64 | P a g e
FIGURE 4.14 GENERATE BILL

65 | P a g e
FIGURE 4.15 MANAGE ADMIN PROFILE

66 | P a g e
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.

67 | P a g e