Project On : Development of Patient Management System

This Report is submitted in partial fulfillment of the requirement for the degree of Bachelor
of Science in Computer Science and Telecommunication Engineering,
Noakhali Science and Technology University

Supervised by
Md. Javed Hossain
Associate Professor
Department of Computer Science and Telecommunication Engineering
Noakhali Science and Technology University

Submitted by
Md .Sohel Rana
ID: ASH1501002M
Session: 2014-15

Date of Submission:
The project titled “Development of Patient Management System” submitted by ID:
ASH1501002M, session 2014-2015 has been accepted as satisfactory in fulfillment of the
requirement for the degree of Bachelor of Science in Computer Science and
Telecommunication Engineering, Noakhali Science and Technology University

Board of Examiners

Acknowledgement

At first I give to thanks Allah who is the most merciful and the most graceful. I am
extremely grateful to honorable project supervisor Md. Javed Hossain, Associate Professor,
Department of Computer Science and Telecommunication Engineering, Noakhali Science
and Technology University, for his valuable advices, constructive suggestions and sincere
guidance with all the necessary facilities for assimilation, research and preparation for the
project. Finally, I am heartily thankful to my supervisor, Md. Javed Hossain whose
encouragement, guidance and support from the initial to the final level enabled me to
develop an understanding of the subject

Abstract

The manual Patient management system represents a huge number but there were no such
initiatives to modernize the system. The manual processing of manual patient’s
maintaining system is a lengthy, erroneous, time consuming, less administrative control,
lack of monitoring and needed more patience. So if we can turn it to modernized system it
will help them as well as the patients. The main goal and objectives of this project is to
improve the manual patient management system into an online based processing system.
Receptionist can maintain Patient and manage test. Doctors can Store Patient Information
with prescription along with test. Patient can store his/ her appointment history along with
prescription. Admin can control all the access. Patient, Doctor and receptionist can search
for blood donor and contact with him/ her. Receptionist can generated an auto generated
Invoice. The system will store all information of Patient, Doctor, Receptionist, Admin
and test. Admin can add or update Patient, Doctor, Receptionist and Test Information.
Admin can also add another admin and update his/her Information.
.
 Contents
Acknowledgement ...........................................................................2
Abstract ............................................................................................ 2
Chapter 1(Project introduction).................................................... 6
1.1 Indtroduction ........................................................................................ 6
1.2 Background of Study ............................................................................ 6
1.3 Objectives .............................................................................................. 6
1.3.1 Broad Objective ................................................................................................... 7
1.3.2 Specific Objective................................................................................................ 7
1.4 Proposed System ................................................................................... 7
1.5 Methodology .......................................................................................... 7
1.5.1 Data Sources ........................................................................................................ 7
1.6 Limitation of the Project ...................................................................... 8
1.7 Process Model........................................................................................ 8
1.7.1 Why Incremental Model ...................................................................................... 8
1.8 Feasibility Study ................................................................................... 9
1.8.1 Technical feasibility ............................................................................................ 9
1.8.2 Economic feasibility ............................................................................................ 9
1.8.3 Operational feasibility ....................................................................................... 10

Chapter 2 (Requirement Engineering) .......................................10

2.1 Requirements Engineering ................................................................ 10
2.1.1 User Requirements ............................................................................................ 10
2.1.2 System Requirements ........................................................................................ 11
 2.1.3 Functional Requirements ................................................................................... 15
2.1.4 Non-Functional Requirements ........................................................................... 16
2.1.5 Specification of Each Requirement ................................................................... 16
2.2 Benefits of the System......................................................................... 17
Chapter 3 (System Planning) ....................................................... 19
3.1 Function Description .......................................................................... 19
3.2 System Project Planning .................................................................... 20
3.2.1 System Project Estimation ................................................................................. 20
3.2.2 Project Planning and scheduling........................................................................ 21
3.2.3 Function Point Estimation ................................................................................. 21
3.2.4 Process Based Estimation .................................................................................. 22
3.2.5 Time Line Calculation ....................................................................................... 23
3.2.6 Effort Distribution ............................................................................................. 23
3.2.7 Task Scheduling ................................................................................................ 24
3.2.8 Project Schedule Chart ...................................................................................... 25
3.2.9 Cost Estimation.................................................................................................. 25

.....................................................................................................26
Chapter 4 (Risk Management) .................................................... 26
4.1 Risk Analysis ....................................................................................... 26
4.2 Category of stage ................................................................................ 27
Chapter 5 (Analysis Modeling) .................................................... 27
5.1 Structural Diagrams ........................................................................... 27
5.2 Class Diagram ..................................................................................... 28
Chapter 6 (Designing) ...................................................................29
6.2 Database of the project....................................................................... 33
6.3 Data Flow Diagram ............................................................................ 34
Chapter 7 (Quality Assurance) .................................................... 36
7.1 System testing ...................................................................................... 36
7.1.1 Software Testing Strategy ................................................................................. 37
7.2 System Testing Methodology ............................................................................... 38

Chapter 8 (Conclusion) ................................................................ 39

8.1 Future Plan .......................................................................................... 39
 8.2 Limitation ............................................................................................ 39
References ...................................................................................... 39
 Chapter 1(Project introduction)

1 Indtroduction
Patient management software is referred to as software that is regulated as a medical
device. It is software that is used to acquire medical information from a medical device to
be used in the treatment or diagnosis of a patient.The patient management system can be
entered using a email , password. It is accessible by admin, doctor, patient, receptionist.
The interface is very user friendly.

1.2 Background of Study

Now a day’s management software is common software for all of us. Each and every
office needs management software for manage all the work done in the office. Before
start the work I have done some study such as which type of company it is. What they
want in the software is, to add Patient information, create appointment, checkup patient,
search blood donor information, add test to cart system and last of all generate an invoice
and prescription.
1.3 Objectives
Around in present world, everything is technically sophisticated. Therefore, throughout
the emergent of this scheme I tried to give an intercontinental stance. The ultimate
objective of the system is to provide facility to the user for management of a clinic.
Security of this system is very high and the possibility of doing wrong in the calculation
is low. Since, now-a-days every system become increasingly technically advanced, the
proposed system will involve computerized information system, patient management,
database storage, retrieval (through several functions), test management, patient checkup,
modifications and appointment schedule making supports which will make all processes
involving the system much faster and easier for the users.
The main objective of this system is to record all information including patient name, age,
contact, which is essential when I need to appoint a patient to a specific doctor and assign
a test. This software provides to find out the information of patient. It will also generate
the report of all the information including test, prescription and the patient details.
1.3.1 Broad Objective

The broad objective of this project is to use my institutional educational experience in the
real life working environment by developing Patient Management System .

1.3.2 Specific Objective

1. Add, Edit, Delete patient.
2. Update patient details.
3. Appoint a patient to a specific doctor.
4. Assign test to a patient.
5. Add, Delete, and Edit doctor.
6. Checkup Patient.
7. Create invoice according to patient test.
8. Search Patient, Doctor and Blood Donor information.
1.4 Proposed System
Development of Patient Management System which can control and manage a clinic. My
proposed system is management software which can store patient details, assign test to a
patient, search blood and appoint that patient to a specific doctor. The system can appoint
a patient to a doctor by choosing an available date and generate a report with all of the
information, test and prescription of a patient.
1.5 Methodology
“Development of Patient Management System using Incremental Model” will complete
following the structure described later on Software Analysis & Design. It aims to
development of management System. The variables identified to manipulate through a
handy inspection and from primary and secondary data.
1.5.1 Data Sources

For this project in data collection phase I collected two types of data
Primary Data
Secondary Data
Primary data are generated within the clinic. The clinics practical experience and
observation helped me generate the primary data.
Secondary data are generated by studying different articles, newspapers, research papers
and of course information collected via Internet. Data, facts and statistics collected from
different web sites and sources made us understand the project better.

1.6 Limitation of the Project

1.7 Process Model

In my project I am using the Incremental Model. Incremental Model is a process of
software development where requirements are broken down into multiple standalone
modules of software development cycle.
Each iteration passes through the requirements, design, coding and testing phases. And
each subsequent release of the system adds function to the previous release until all
designed functionality has been implemented. That’s why I am chosen this type of
process Model.

Figure 1.1: Incremental Process Model

1.7.1 Why Incremental Model

i. In this model customer can respond to each built.

ii. Lowers initial delivery cost.
iii. Software will be generated quickly during the software life cycle.
iv. It is flexible and less expensive to change requirements and scope.
v. Thought the development stages changes can be done.
vi. Errors are easy to be identified.
vii. Generates working software quickly and early during the software life cycle.

1.8 Feasibility Study

Feasibility study determines whether that solution is feasible or achievable for the
organization. There are three major areas of feasibility study.
• Technical feasibility
• Economic feasibility
• Operational feasibility
1.8.1 Technical feasibility

The technical feasibility assessment is focused on gaining an understanding of the present

technical resources of the organization and their applicability to the expected needs of the
proposed system. It is an evaluation of the hardware and software and how it meets the
need of the proposed system.

SN Hardware Requirement Software Requirement

1. Computer(Desktop/Laptop/Equivalent) Operating System(Windows 10 or

equivalent) with browser(Google
Chrome/Firefox)
2. Proper electricity Support PHP

3. Adequate system memory and secondary MySQL

memory

Communication Interface
Client on Internet will be using HTTP/HTTPS protocol.
Client on Internet will be using TCP/IP protocol.
1.8.2 Economic feasibility

The purpose of the economic feasibility assessment is to determine the positive economic
benefits to the organization that the proposed system will provide. My system is
economically feasible because by using the proposed system many works can be done
within small time and which is not possible by man power within the same time. It also
reduces the man power needed for providing the patient information, doctor information,
test information, appoint to a doctor and generating report. So they have to pay less salary
where the current system needs many stuff and they are paying much salary. So I can say
that, if they use proposed system they will be economically benefited.
1.8.3 Operational feasibility

User can easily operate the proposed system because the system is user friendly. It’s easy
to insert patient information and easily appoint to a doctor. If the stuff of the organization
has the basic to computer knowledge they could operate the software easily. Every
features and the activity that I combined within the system is designed and developed
belongs to previous format they had used with a more attractive user interface.

Chapter 2 (Requirement Engineering)

2.1 Requirements Engineering
Requirements engineering is, as its name suggests, the engineering discipline of
establishing user requirements and specifying software systems. There are many
definitions of Requirements Engineering; however, they all share the idea that
requirements involves finding out what people want from a computer system, and
understanding what their needs mean in terms of design. Requirements engineering is
closely related to software engineering, which focuses more on the process of designing
the system that users want.
User requirements
System requirements
Functional requirements
2.1.1 User Requirements

1. Admin will add Doctor Info/ Patient info/ Receptionist info/ Test info.
2. Patient will view his/her own profile.
3. Doctor will view his/her own profile.
4. Admin will update Doctor Info/ Patient info/ Receptionist info/ Test info.
5. Admin will delete Doctor Info/ Patient info/ Receptionist info/ Test info.
6. Update patient profile from patient dashboard.
7. Update doctor profile from doctor dashboard.
8. Admin will change the behavior of receptionist and another admin.
9. Receptionist will add patient info.
10. Receptionist will update patient info.
11. Receptionist will create appointment for patient and cancel appointment.
12. Patient will create appointment of specific doctor.
13. Patient will search for Blood.
14. Doctor will search for Blood.
15. Receptionist will search for Blood.
16. Patient will search for doctor.
17. Receptionist will assign test/ add to cart system.
18. Generate invoice system.
19. Doctor will check up a patient and generate prescription.
20. Doctor will store the prescription and store test report of a patient.
2.1.2 System Requirements

1. Admin will add Doctor Info/ Patient info/ Receptionist info/ Test info.
1.1. First of all, admin will login into the system.
1.2. Check whether it is admin or not.
1.3. Select insert new patient/ insert new doctor/ insert test/ insert access option.
1.4. When admin will click the insert option he/she will be able to added new patient/
doctor/ test/ receptionist information.
1.5. If admin fill up the form without any blanks, then he/she can save it.
1.6. If the form does not fill up properly then system will show the error message
“Please fill out this field”.
2. Patient will view his/her own profile.
2.1. First of all, patient will login into the system.
2.2. Check whether it is patient or not.
2.3. Select profile option from patient panel.
2.4. If patient want to view profile information, then he/she has to click on patient
profile.
2.5. Patient will show his/her profile information.
3. Doctor will view his/her own profile.
3.1. First of all, doctor will login into the system.
3.2. Check whether it is doctor or not.
3.3. Select profile option from doctor panel.
3.4. If doctor want to view profile information, then he/she has to click on doctor
profile.
3.5. Doctor will show his/her profile information.
4. Admin will update Doctor Info/ Patient info/ Receptionist info/ Test info.
4.1. First of all, admin will login into the system.
4.2. Check whether it is admin or not.
4.3. Select edit doctor/ patient/ receptionist/ test info.
4.4. If admin want to update doctor/ patient/ receptionist/ test info, click on edit option.
4.5. If updated, then show a confirmation message “Successfully Updated”.
5. Admin will delete Doctor Info/ Patient info/ Receptionist info/ Test info.
5.1. First of all, admin will login into the system.
5.2. Check whether it is admin or not.
5.3. Select delete doctor/ patient/ receptionist/ test info.
5.4. If admin want to delete doctor/ patient/ receptionist/ test info, click on delete
option.
5.5. If deleted, then show a confirmation message “Successfully data deleted”.
6. Update patient profile from patient dashboard.
6.1. First of all, patient will login into the system.
6.2. Check whether it is patient or not.
6.3. If patient want to edit his/her profile, first view the profile and then click edit
option.
6.4. If updated, then show a confirmation message “Successfully Updated”.
7. Update doctor profile from patient dashboard.
7.1. First of all, doctor will login into the system.
7.2. Check whether it is doctor or not.
7.3. If doctor want to update his/her profile, first view the profile and then click edit
option.
7.4. If updated, then show a confirmation message “Successfully Updated”.
8. Admin will change the behavior of receptionist and another admin.
8.1. First of all, admin will login into the system.
8.2. Check whether it is admin or not.
8.3. If admin want to change the behavior of receptionist and another admin then
he/she has to click access option and then click on edit option.
8.4. If want to change the access, then select receptionist or admin.
9. Receptionist will add patient info.
9.1. First of all, receptionist will login into the system.
9.2. Check whether it is receptionist or not.
9.3. Select insert new patient option.
9.4. When receptionist will click the insert option, he/she will be able to add new
patient information.
9.5. If receptionist fills up the form without any blanks, then he/she can save it.
9.6. If the form does not fill up properly then system will show the error message
“Please fill out this field”.

10. Receptionist will update patient info.

10.1. First of all, receptionist will login into the system.
10.2. Check whether it is receptionist or not.
10.3. Select edit patient option.
10.4. If receptionist want to update patient info, click on edit option.
10.5. If updated, then show a confirmation message “Successfully Updated”.
11. Receptionist will create appointment for patient and cancel appointment.
11.1. First of all, receptionist will login into the system.
11.2. Check whether it is receptionist or not.
11.3. Select create appointment option.
11.4. Select patient for whom you want to create appointment.
11.5. Select specific doctor name from whom you want to take appointment.
11.6. Select a date, which date you want to create appointment.
11.7. If want to confirm then click create appointment option.
11.8. If receptionist want to cancel appointment, then click on delete button.
12. Patient will create appointment of specific doctor.
12.1. First of all, patient will login into the system.
12.2. Check whether it is patient or not.
12.3. Find a doctor from whom you want to get appointment.
12.4. Select a date, which date you want to get appointment.
12.5. If you want to confirm appointment, then click on create appointment option.
13. Patient will search for Blood.
13.1. First of all, patient will login into the system.
13.2. Check whether it is patient or not.
13.3. If patient want to search blood, then he/she can use the search bar.
13.4. Enter the data in the search box which patient want to search.
13.5. If the data is found, then show the desire information what patient want to see.
14. Doctor will search for Blood.
14.1. First of all, doctor will login into the system.
14.2. Check whether it is doctor or not.
14.3. If doctor want to search blood, then he/she can use the search bar.
14.4. Enter the data in the search box which doctor want to search.
14.5. If the data is found, then show the desire information what doctor want to see.
15. Receptionist will search for Blood.
15.1. First of all, receptionist will login into the system.
15.2. Check whether it is receptionist or not.
15.3. If receptionist wants to search blood, then he/she can use the search bar.
15.4. Enter the data in the search box which receptionist want to search.
15.5. If the data is found, then show the desire information what receptionist wants to
see.
16. Patient will search for doctor.
16.1. First of all, patient will login into the system.
16.2. Check whether it is patient or not.
16.3. If patient want to search doctor, then he/she should click on appointment schedule.
16.4. Then search by doctor name/ speciality.
16.5. If patient want to view detail about this desire doctor, then click on doctor name.
17. Receptionist will assign test/ add to cart.
17.1. First of all, receptionist will login into the system.
17.2. Check whether it is receptionist or not.
17.3. Test will be added to cart system.
17.4. If test more than one, then calculate all tests price together.
17.5. If only one test, then pay for only one test.
17.6. If receptionist wants to get the test report, then he/she has to pay for the test.
17.7. If receptionist wants to cancel test from cart, then he/she can click on delete
button.
18. Receptionist will generate invoice.
18.1. First of all, receptionist will login into the system.
18.2. Check whether it is receptionist or not.
18.3. If user clears the payment for test, then generate an automated invoice.
19. Doctor will check up a patient and generate prescription.
19.1. First of all, doctor will login into the system.
19.2. Check whether it is doctor or not.
19.3. If doctor want to check up patient, then click on patient name.
19.4. Assign medicine and test for patient.
19.5. If doctor want to generate prescription, then click on prescribe button.
20. Doctor will store the prescription and store test report of a patient.
20.1. First of all, doctor will login into the system.
20.2. Check whether it is doctor or not.
20.3. Test report will store into completed test option and prescription will store into the
History.
2.1.3 Functional Requirements

• Admin can maintain whole system.

• Admin can add, delete and edit patient.
• Admin can add test.
• Admin can update access modifier.
• Admin can add, delete and edit doctor.
• Receptionist will create invoice.
• Receptionist will appoint a patient to a doctor.
• Doctor can checkup patient.
• Patient can add, delete and edit his/ her own information.
2.1.4 Non-Functional Requirements

• Admin can log in by using username and password.

• Patient, doctor and receptionist can log in by using username and password.
• Only admin can maintain the whole system.
• Total secured system.
• Any operating system supported.
2.1.5 Specification of Each Requirement

2.1.5.1 Admin specification

• Function: Log in, add information, edit information and delete information.
• Description: All the access of the system.
• Input: Admin input his information in his criteria.
• Output: Information submits successfully.
• Side effects: None
2.1.5.2User specification

•
• Function: Log in, add information, edit information.
• Description: Easily use the system for his useful purpose.
• Input: User input his information in his criteria
• Output: Information submits successfully.
• Side effects: None
2.1.5.3 Database specification

• Function: Store whole information.

• Input: assign data
• Output: Progress and provide information
• Action: Support Data
• Side effects: none
2.2 Benefits of the System
• Receptionist will be able to maintain this system more accurately.
• All the information will be stored on to the computer with its formatted screens
and built in databases.
• All the information can be carried out more easily or quickly than any other
manual process.
• Admin can easily take all information any time when he needs that stored by
himself previously.
• Receptionist can easily appoint a patient to a doctor.
• Patient can easily get appointment.
2.3 Use Case Diagram
In order to achieve the highest understanding of the project next there will be illustrations
containing various cases of system. First, the following diagram is the use case diagram
of the system:
 Figure 2.1: USE CASE Diagram of Patient Management System
Use Case diagrams show the various activities the users can perform on the system. The
System is something that performs a function. They model the dynamic aspects of the
system. It provides a user’s perspective of the system.
 Chapter 3 (System Planning)
3.1 Function Description
Function description descriptive the function in details. It concerns on three factors: what
is the possible input, possible output for a particular function and which table of the
database uses by that function.
• Login into the System
Input: E-mail and Password
Output: If login data is valid then set authorization as admin, doctor, patient or
receptionist to the login person as defined in database otherwise will show error message.
Use table of the database: admin*table
• Add to Cart
Input: Select test and click on add to cart
Output: Test gets added to cart and cart is displayed with test name, price and total price.
• Invoice Generation
Input: Click on invoice button
Output: Generate an invoice with test name, price, quantity, total, subtotal, tax and grand
total
Use table of the database.
• Add Patient
Input: Patient Name, Address, Age, Gender, Mobile Number, E-mail, Blood group,
Password
Output: Create a Patient profile and show confirmation message.
Use table of the database.
• Appointment
Input: Select Doctor and click on Confirm button
Output: Display Successful or error
Use table of the database.
• Patient Checkup
Input: Select Patient and prescribe medicine/ test
Output: Generate a Prescription
Use table of the database.

• Report Generation
Input: Write Test report
Output: Generate a Test report
Use table of the database.
• Add Test
Input: Test Name, Price
Output: Display Test List
Use table of the database.
• Edit Test
Input: Test Name, Price
Output: Display Updated test list and display successful or error
Use table of the database.
• Invoice Print
Input: Insert Patient information, test information and click on Print button
Output: Print an auto generated invoice
3.2 System Project Planning
Before starting any project, it is compulsory to estimate the work to be done, the
resources that will be required, the time that will elapse from start to finish and to analyze
the project to determine whether it is feasible or not.
The following activities of software project planning that have followed in this project
are:
System Project Estimation
Function Oriented Metrics
Process Based Estimation
Effort Distribution
Task Scheduling
Project Schedule Chart
Cost Estimation
3.2.1 System Project Estimation

The accuracy of a software project estimate predicated based on a number of things:

Properly estimated the size of the product to build.
The ability to translate the size estimation into human effort, calendar time and
money.
The degree to which the project plan reflects the abilities of the software team or
engineer.
The stability of the product requirements and the environment that supports the
software engineering effort.
Software size estimation is the most important matter that I have to consider during the
software project. If the software size not calculate properly, then this will cause various
problems such as scheduling problems, budget problem etc. As the project goes on before
estimating the software size, I have to confirm that software scope is bounded.
3.2.2 Project Planning and scheduling

3.2.3 Function Point Estimation

Functionality Input Output

Admin
Delete/ Update (2*EI) Delete Patient/ Doctor/ Display confirmation or
Receptionist/ Admin info error
Add New Patient/ Add patient/ Doctor/ Display successful or error
Doctor/Receptionist/Admin Receptionist/ Admin info
(EI)
Add Test Info (EI) Add test Display successful or error

Functionality Input Output

Doctor

Check Appointment List (EQ) Click on name View Patient info,

completed test and create
prescription
Check Appointment History (EQ) Click on prescription View prescription with
button test name
Search for Blood (EQ) Search text View patient name, blood
group, location and
mobile no

Functionality Input Output

Receptionist

Update Patient Info (EI) Edit Patient Display Successful or error

Add new patient (EI) Add Patient Display Successful or error

Check test list (EQ) Click on test list List of doctor

recommended test
Create Appointment (EI) Click on Appointment option Display Successful or error

Order for Test (EI) Click on order Item gets added to cart is
displayed with test name
price and total Price
 Invoice Generate (EO) Select Patient and then click Generate an Invoice
on Invoice with test name, price,
quantity, total, subtotal, tax
and grand total
Search for blood (EQ) Search text View Patient name, blood
group, location and mobile
no

Functionality Input Output

Patient

Create Appointment (EI) Select doctor and click on Display successful or error
confirm button
Check Appointment Details(EQ) Click on Appointment Detail View Patient name, Doctor
Name, Speciality, Date
time
Check Test Info (EQ) Click on test option View Test name, Price

Search for Blood (EQ) Search text View Patient Name, blood
group, location and mobile
no

3.2.4 Process Based Estimation

In process-based estimation, process is decomposed into a relatively small set of tasks and
the effort required to accomplish each task is estimated. Process based estimation begins
with a delineation of software functions obtained from the project scope. A series of
software process activities must be performed for each function.

Table 3.1: Process Based Estimation

Activity CC Planning Engineering Construction Imp. Total

Function Analysis Design Code Test
F1 0.011 0.053 0.115 0.104 0.133 0.021 0.032
 F2 0.010 0.051 0.165 0.129 0.264 0.052 0.024
F3 0.016 0.030 0.102 0.175 0.139 0.031 0.016
F4 0.013 0.023 0.049 0.192 0.238 0.057 0.025
F5 0.015 0.016 0.102 0.147 0.297 0.018 0.012
F6 0.016 0.021 0.151 0.113 0.234 0.063 0.026
F7 0.010 0.039 0.123 0.121 0.232 0.039 0.027
F8 0.012 0.032 0.112 0.295 0.236 0.016 0.022
F9 0.014 0.061 0.125 0.192 0.334 0.032 0.029
F10 0.013 0.064 0.185 0.282 0.233 0.061 0.047
Total 0.13 0.39 1.23 1.75 2.34 0.39 0.26 6.5
Effort 2% 6% 19% 27% 36% 6% 4% 100%

3.2.5 Time Line Calculation

Process Based Estimation= 6.5 man months

Estimated time for the project= Estimated Man Month / 2
= (6.5 / 2) months
= 3.25 months
Approximately 3 months required for 2 persons to finish the project.
3.2.6 Effort Distribution

The project estimation technique leads to estimates of work units required to complete the
software development. A recommended distribution of effort across the definition and
development phases referred as the 40-20-40 rule. Forty percent of all effort allocated to
front-end analysis and design, twenty percent allocated to coding and the remaining forty
percent allocated to back-end testing. This rule used as a guideline only.
In this project, 46% of full software development has been allocated to analysis and
design, 36% has allocated to coding and the remaining 18% is allocated to software
testing and support.
 Eeffort Based Estimation

6% 4% 2% 6%
Cuatomer Communication
19%
Planning
36% Analysis
27% Design
Code
Test
Implementation

Figure 3.1: Effort Based Estimation

Description:
1 (2% - Customer Communication)
2 (6% - Planning)
3 (19% - Analyzing)
4 (27% - Designing)
5 (36% - Coding)
6 (6% - Testing).
7 (4% - Implementation).

3.2.7 Task Scheduling

Project scheduling is an activity of distributing the estimated efforts within the planned
project duration. There are some basic rules for project scheduling. They are as follows –
Compartmentalization – The project must compartmentalize into a number of manageable
activities and tasks.
Interdependency – The interdependency of each compartmentalized activity or task must
be determined. Some tasks must occur in sequence while others can occur in parallel.
Time allocation – Each task to be scheduled must allocated some number of work units.
Effort validation – Every project has a defined number of staff members. It should ensure
that no more than the allocated number of people has scheduled at any given time.

Defined responsibilities – Every task that is scheduled should assign to a specific team
member.
Defined outcomes – Every task that is scheduled should have a defined outcome. The
outcome is normally a work product or a part of a work product.

3.2.8 Project Schedule Chart

Total system development is a combination of set of tasks. These set of tasks should done
sequentially and timely. Project schedule works as the guideline of the system developer.
The following is the schedule chart of this project:

Category W1 W2 W3 W4 W5 W6 W7 W8 W9 W10 W11 W12

Customer
Communicator
Planning

Analysis

Design

Coding

Testing

Implementation

Figure 4.2: Project Schedule Chart

3.2.9 Cost Estimation

The approximation of the cost of a program is cost estimation. In this project, there are
two factors to analyze and calculate the cost. Given bellow,
Hardware cost
Other cost

Hardware Cost
Cost of the computer that used to complete the project.
Table 3.2: Hardware cost

Particulars TK
Computer 34,000
Scanner 4,830
Printer 7,700
Total 46,530
Total Hardware Cost = 46,530.00 TK

Software Cost
It is the cost of the software is which used in this project.
Table 3.3: Software Cost

Software Number Amount Total

1 OS (Windows 10) 1 100 Tk.

2 MS Office 2010 1 80 Tk. 330 Tk.

3 Notepad++ 1 100 Tk.

4 SQL 1 50 Tk.

Other Cost
Name Price

Pen and paper 300 Tk.

Mobile 200 Tk.

Transport 500 Tk.

Total 1000 Tk.

Chapter 4 (Risk Management)

4.1 Risk Analysis
Risk analysis and management am a series of works that help a system development team
to understand and manage uncertainty. Many problems can arise while developing a
system. A risk is a potential problem – it may happen may not. There are several steps to
analyze and manage risks. The first step is risk identification. Next each risk is analyzed
to determine the likelihood that it will occur and the damage that it will do if it does
occur. Once this information is established risks am remarked. Finally, a plan is
developed to manage those risks with high probability and impact.

4.2 Category of stage

There are different Stages of risks. They area:
Risk identification: Risk identification is the process of detecting potential risks or
hazards through data collection. A range of data collection and manipulation tools and
techniques exists. The team is using both automated and manual techniques to collect data
and begin to characterize potential risks to Web resources. Web crawling is one effective
way to collect information about the state of Web pages and sites.
Risk classification: Risk classification is the process of developing a structured model to
categorize risk and fitting observable risk attributes and events into the model. The team
combines quantitative and qualitative methods to characterize.
Risk assessment: Risk assessment is the process of defining relevant risk scenarios or
sequences of events that could result in damage or loss and the probability of these
events. Many sources focus on risk assessment. Rosenthal describes the characteristics of
a generic standard for risk assessment as "transparent, coherent, consistent, complete,
comprehensive, impartial, uniform, balanced, defensible, sustainable, flexible, and
accompanied by suitable and sufficient guidance.
Risk analysis: Risk analysis determines the potential impact of risk patterns or scenarios,
the possible extent of loss, and the direct and indirect costs of recovery. This step
identifies vulnerabilities, considers the willingness of the organization to accept risk given
potential consequences, and develops mitigation responses.
Risk management implementation: defines policies, procedures, and mechanisms to
manage and respond to identifiable risks. The implemented program should balance the
value of assets and the direct and indirect costs of preventing or recovering from damage
or loss.

Chapter 5 (Analysis Modeling)

5.1 Structural Diagrams

Analysis modeling uses a combination of text and diagrammatic forms to depict

requirements for data, function, and behavior in a way that is relatively easy to
understand, and more important, straightforward to review for correctness, completeness
and consistency. This section presents resources for conventional and object-oriented
analysis (OOA) methods as well as resources for UML.
5.2 Class Diagram

Figure 5.1: Class diagram

 Chapter 6 (Designing)

Figure 6.1: Interface design of login

Figure 6.2: Interface design of admin

Figure 6.3: Interface design of Doctor List

Figure 6.4: Interface design of Add Doctor

Figure 6.5: Interface design of Doctor Checkup
Figure 6.6: Interface design of Doctor Profile

Figure 6.7: Interface design of Patient Appointment

 Figure 6.8: Interface design of Search Blood

6.2 Database of the project

Admin

Doctor

Patient
Receptionist

Test

Appointment

Figure 6. 9 : Database of the project

6.3 Data Flow Diagram

Data Flow Diagram (DFD)
A Data Flow Diagram (DFD) is a graphical representation of the "flow" of data through
an information system, modeling its process aspects. A DFD is often used as a
preliminary step to create an overview of the system, which can later be elaborated. DFDs
can also be used for the visualization of data processing (structured design).
A DFD shows what kind of information will be input to and output from the system,
where the data will come from and go to, and where the data will be stored. It does not
show information about the timing of process or information about whether processes will
operate in sequence or in parallel (which is shown on a flowchart).
A context level DFD of the system is given below

Figure 6.10: Context level DFD

7.4 ERD
 Figure 6.11: ER Diagram

Chapter 7 (Quality Assurance)

7.1 System testing
According to the common process framework (CPF), the software testing is the final
activity that has to initiate after testing. Software testing is a critical element of software
quality assurance and represents the ultimate review of specification, design and code
generation.
The objectives of software testing are:
• Testing is a process of executing a program with the intent of finding an error.
• A good test case is one that has a high probability of finding an as-yet-
undiscovered error.
• A successful test is one that uncovers an as-yet-undiscovered error.
The design of tests for software can be challenging as the initial design of the product
itself. Software can be tested in one of two ways:

• Knowing the specified function that the software has been designed to perform,
tests can be conducted that demonstrate each function fully while at the same time
searching for errors in each function. This approach is known as black-box testing.
• Knowing the internal workings of software, tests can be conducted to ensure that
internal operations am performed according to specifications and all internal components
have been adequately exercised. This approach is known as white-box testing.

7.1.1 Software Testing Strategy

A strategy for software testing integrates software test case design methods into a well-
planned series of steps that result in the successful construction of a software. The
strategy provides a road map that describes the steps to be conducted as part of testing.
Testing strategy that will be followed in this software project –
• Unit testing
• Integration testing
• Validation testing
The first step in software testing is unit testing. Unit testing concentrates on each unit of
the software as implemented in source code. Unit testing focuses on each component
individually. The unit test is white-box oriented. Thus, unit testing of this library software
will be done after completion of every module or component.
The next step is integration testing. Integration testing is a systematic technique for
constructing the program structure while at the same time conducting tests to uncover
errors associated with interfacing. The objective of integration testing is to take unit tested
components and build a program structure that has been dictated by design.
The integration testing strategy that has been chosen for this project is top down testing.
Black-box testing method is the most prevalent for integration testing. Top down
integration strategy will be used to perform integration testing. Top down integration will
be done by breadth-first manner. Breadth-first integration incorporates all components
directly subordinate at each level, moving across the structure horizontally.
After the software has been integrated, a set of high order tests am conducted. Hence, the
validation criteria that have been mentioned in requirements engineering should be tested.
Validation testing provides final assurance that software meets all functional, behavioral
and performance requirements. The black-box testing method is exclusively used in
validation.
7.2 System Testing Methodology

• Black-box Testing
Black-box testing which is also known as behavioral testing focuses on the functional
requirements of the software. It enables the software engineer to derive sets of input
conditions that will fully exercise all functional requirements for a program. Black-box
testing method will be applied to test the modules of LMS.

Figure 7.1: Black box and White box testing

• White-box Testing
White-box testing, which also known as glass-box testing, is a test case design method
that uses the control structure of the procedural design to derived test cases. Using white-
box testing methods, software engineer can derive test cases that,

1. Guarantee that all independent paths within a module have been exercised at least
once
2. Exercise all logical decisions on their true and false sides
3. Execute all loops at their boundaries and within their operational bounds
4. Exercise internal data structures to ensure their validity.
The modules that contain some complex calculations or decision making code such as
check the availability of the library item will be tested using white-box method.

Chapter 8 (Conclusion)
8.1 Future Plan
Add online payment system.
Patient can pay money from his/her account.
Add online consultation with doctor.
Add diagnostic system.
Recover user password, through email address.

8.2 Limitation
Patient cannot pay money through online.
There is no diagnostic system.
There is no option to recover user password, through email address.

References
1. Kendall, E. &Kendall. (1999). System Analysis and Design. 4th Ed. New Delhi:
Prentice Hall.
2. Pressman, Roger S. (2004). Software Engineering: A Practitioner’s Approach. 5th
ed. Boston: McGraw Hill.
3. Silberschattz, Abraham, Korth, Henry F., &Sudrashan S. (2002). Database System
Concepts. 4th ed. Boston: McGraw Hill.
4. Meyer, Bertrand. (1997), OOSC2: The Use Case Principle. (2018, July 02).
Retrieve From http://www.elj.com/elj/v1/n2/bm/usecases.
5. Longstreet, David. (2005). Fundamentals of Function Point Analysis. (2018,
July05).Retrieve fromhttp://www.softwfaremetrics.com/fpafund.htm.
6. Software testing. (2018, July 10). Retrieve from
http://en.wikipedia.org/wiki/Software_testing
7. kushal. S, (2007, Mar 14). Calculating Function Points. (2018, July 16). Retrieve
from https://www.codeproject.com/articles/18024/calculating-function-points
8. Pearson Education Limited (2004) & cah, UoN (2008). The Function Point
Method. (2018, July 20). Retrieve from
http://www.cs.nott.ac.uk/~pszcah/G53QAT/G53QAT12pdf6up.pdf
9. Function Point Overview. (2018, July 24). Retrieve from
http://www.csee.umbc.edu/~mgrass2/cmsc645/function_point.html
10. How to calculate function points. (2018, Aug03). Retrieve from
http://stackoverflow.com/questions/34473698/how-to-calculate-function-points
11. Mamčenko. J, Introduction to Dta Modeling and MSAccess. (2018, Aug07).
Retrieve from
http://gama.vtu.lt/biblioteka/Information_Resources/i_part_of_information_resources.pdf
12. Nishadha, (2012). Ultimate Guide to ER Diagrams. (2018, Aug10). Retrieve from
http://creately.com/blog/diagrams/er-diagrams-tutorial/
13. Silberschatz, Korth, Sudarshan S. (2007). Introduction to Databases E-R Data
Modeling. (2018, June02). Retrieve from
http://labe.felk.cvut.cz/~stepan/AE3B33OSD/Lesson08-IntroDatabases.pdf
14. Tutorials Point. (2015). Database Management System. (2018, June30). Retrieve
from https://www.tutorialspoint.com/dbms/dbms_tutorial.pdf
15. E-R Diagram. (2018, May27). Retrieve from
http://www.cs.sfu.ca/CourseCentral/354/jpei/slides/ER-diagram.pdf
16. Shingote, S. Explain incremental Process Model with example. (2018, Aug09).
Retrieve from http://www.ques10.com/p/21784/explain-incremental-process-model-with-
example/