A

PROJECT REPORT

ON

DocPad - Android Application

DESIGNED AND DEVELOPED

BY

JAY SUMAN MANIYAR

PRATIK DILIP KOTAK

THIRD YEAR BACHELOR OF SCIENCE

(INFORMATION TECNOLOGY)

UNDER THE GUIDANCE OF

Ms. SWEETY GARG

DEPARTMENT OF INFORMATION TECNOLOGY

NAGINDAS KHANDWALA COLLEGE OF ARTS, COMMERCE &

MANAGEMENT STUDIES AND SHANTABEN NAGINDAS
KHANDWALA COLLEGE OF SCIENCE
MALAD (W) 400 064

UNIVERSITY OF MUMBAI
(2015 2016)
 MALAD KANDIVALI EDUCATION SOCIETYS

NAGINDAS KHANDWALA COLLEGE OF COMMERCE, ARTS & MANAGEMENT

STUDIES & SHANTABEN NAGINDAS KHANDWALA COLLEGE OF SCIENCE
MALAD [W], MUMBAI 64
(Reaccredited A Grade by NAAC)
(AFFILIATED TO UNIVERSITY OF MUMBAI)
(ISO 9001:2008)

CERTIFICATE

This is to certify that,

JAY SUMAN MANIYAR

PRATIK DILIP KOTAK

Exam Seat No: 1057137

1057115

Student of Bachelor of Science (Information Technology) from Nagindas Khandwala

College, Malad (W) has successfully completed and submitted the PROJECT REPORT
(USIT607) in partial fulfillment as per the syllabus prescribed by the University of
Mumbai during the academic year 2015-2016.

Project Guide Coordinator External Examiner

(B.Sc.IT/C
ACKNOWLEDGEMENT

I take this opportunity to express my gratitude to our Co-ordinator Mrs. Sindhu P.M.
for giving me this opportunity to accomplish my project work.
I am very thankful to our Principal Dr. (Mrs.) Ancy Jose, for her kind co-operation
during the completion of the project.
A special thanks to our project guide Ms. Sweety Garg for her most sincere efforts,
support and encouraging contribution throughout the project.
Last but not the least, I would like to thank all our friends & our family for their support,
motivation and encouragement.

(JAY SUMAN MANIYAR)

(PRATIK DILIP KOTAK)

 Index
Sr. Contents Pg. No
No

1 ANALYSIS PHASE 1-17

1.1 Requirement Gathering Phase 1-2

1.1.1 Problem Statement 1
1.1.2 Fact Finding Techniques 1
1.1.3 Project Objective and Scope of Project 2
1.1.4 Problems with Existing System 2
1.1.5 Advantages of Proposed System 2

1.2 Feasibility Study 3-10

1.2.1 Operational Feasibility 3
1.2.2 Technical Feasibility 3
1.2.3 Economic Feasibility 4
1.2.4 Cost Benefit Analysis 5-9
1.2.4.1 COCOMO Model1 5
1.2.4.2 Function Point 8
1.2.5 Gantt Chart 10

1.3 Requirement Specification 11-12

1.3.1 Functional Requirement 11
1.3.2 Technical Requirement 11
1.3.3 Software Requirement Specification 12

1.4 Tools and Technology 13-17

2 DESIGN PHASE 18-32

2.1 Detailed Life Cycle of Project 18-33

2.1.1 Event Table 18
2.1.2 E-R Diagram 19
2.1.3 Use Case Diagram 21
2.1.4 Class Diagram 22
2.1.5 Activity Diagram 23
2.1.6 Sequence Diagram 25
2.1.7 State Machine Diagram 27
2.1.8 Component Diagram 29
2.1.9 Deployment Chart 30
2.1.10 Site Map 31
 2.2 Physical Design 32-33
2.2.1 System Flow Chart 32

3 IMPLEMENTATION PHASE 34-65

3.1 Screen Layout 34

3.2 Report Layout 52
3.3 Validations 54
3.4 Test Cases 61

4 MAINTAINENCE AND EVALUATION 66-67

4.1 System Maintenance and Future Enhancement 66

4.2 User Manual 67

5 ANNEXURE 68

5.1 References 68
5.2 Bibliography 68
ANALYSIS PHASE
1. ANALYSIS PHASE
1.1 Requirement Gathering Phase

1.1.1 Problem Statement

Currently the doctor is prescribing medicines on paper.

The main problem doctor is facing is that more time is consumed for writing
prescription.
In case of physical prescription there is always possibility of prescription getting
misplaced or being damaged which leaves the doctor and patient with no
records/medical history.
Sometimes when the doctor and the patient cannot meet in person there is no exchange
of physical prescription which becomes a barrier to get medicines at the right time.

1.1.2 Fact Finding Technique

Q. How do you make prescription currently?

Examine patients and prescribe accordingly in writing i.e. physically.

Q. How much of your time is utilize in writing prescription daily?

Approximately 40% of the time goes in writing prescription.

Q. How much of time and efforts goes into maintaining and retrieving records?
Approximately 55% of time goes into maintaining and retrieving records.

Q. What are the problems you face?

Writing physically.
Time consuming.
Occupies space in maintaining records.
Records sometimes gets misplaced or damaged.
Patients sometimes suffer due to non-availability.
Stationery cost.

Q. What are the results you expect?

A system/application which is less time consuming, saves space, provides
information at a click, reliable and useful.

DocPad Page | 1
1.1.3 Objective and scope of the project
Docpad is an Android app which sets up online communication between a doctor and a
patient. Docpad allows doctors to prescribe the medicines online via email. This will
help doctors in not maintaining the records/history physically which will save the time.
Doctor and patient both can access the records anytime from anywhere.

1.1.4 Problems with existing system

Currently the doctor is prescribing medicines on paper. The main problem doctor is
facing is that more time is consumed for writing prescription. In case of physical
prescription there is always possibility of prescription getting misplaced or being
damaged which leaves the doctor and patient with no records/medical history.
Sometimes when the doctor and the patient cannot meet in person there is no exchange
of physical prescription which becomes a barrier to get medicines at the right time.

1.1.5 Advantages of the proposed system

This app is fast, easy & secure way to send prescription to patients.
There is no performance requirement in this system because the server request
and response is depended on the end user internet connection.
The app maintains the history of the patient.
App will save the time and space of the doctor.
The stationery cost of the doctor will be saved.

DocPad Page | 2
1.2 Feasibility Study

1.2.1 Operational feasibility

Operational feasibility is to gain an understanding of whether the proposed system

will likely to solve the business problems, or take advantage of the opportunities
or not. It is important to understand how the new system will fit the current day-to-
day operations of the organization.
We have also conducted an operational feasibility of our system to identify whether
our system is able to satisfy the goal of developing the system.
The other major requirement of Docpad for which we wanted to develop
application is for growth of business. This requirement was also satisfied.
The next thing was to make a solution to get the prescription details of previous
time from patient. This problem was also solved
The next thing Docpad needed was a system that is easy to use. So we designed an
interface which is extremely easy to use and also we have given attention to
application wherein patient can access the application from smartphone devices.

1.2.2 Technical feasibility

Assessing technical feasibility is to evaluate whether the new system will perform
adequately and whether an organization has ability to construct a proposed system
or not. The technical assessment help answer the question such as whether the
technology needed for the system exists, how difficult it will be to build, and
whether the firm has enough experience using that technology.
In case of technical feasibility, we have made a system that match accord to the
requirements of the doctors and patient.
We have made the project in a language in which we are familiar. The entire project
and website is made in Java and Couchbase. We have chosen these to as the project
is small and also we are familiar with the technologies.
The next area where have concentrated is the operating system architecture. At
presently the users are using jellybean, KitKat and lollipop and very soon it will be
available for marshmallow. So in order to solve this problem we have made the
software operating system and architecture friendly.

DocPad Page | 3
1.2.3 Economic feasibility

Economic evaluation is a vital part of investment appraisal, dealing with factors that
can be quantified, measured, and compared in monetary terms (Chen 1996). The results
of an economic evaluation are considered with other aspects to make the project
investment decision as the proper investment appraisal helps to ensure that the right
project is undertaken in a manner that gives it the best chances of success.
The system according to us is cost effective as this a small group which is containing
little members and only two members are working on this project.
Since the time given to us almost 10 months we are more time and therefore less man
power is required to develop the project.

DocPad Page | 4
1.2.4 Cost Benefit Analysis:

1.2.4.1 COCOMO Model 1:

COCOMO'81 models depends on the two main equations

1. development effort: MM = a * KDSIb based on MM - man-month / person month /
staff-month is one month of effort by one person. In COCOMO'81, there are 152 hours
per Person month. According to organization this values may differ from the standard
by 10% to 20%.
2. effort and development time (TDEV): TDEV = 2.5 * MMc

The coefficients a, b and c depend on the mode of the development. There are three modes
of development:

Development Project Characteristics

Mode Size Innovation Deadline/Constraint Dev.Environment
Organic Small Little Not light Stable
Semi-detached Medium Medium Medium Medium
Embedded Large Greater Tight Complex hardware /
customer interfaces

Basic COCOMO
The basic COCOMO applies the parameterized equation without much detailed
consideration of project characteristics.
Basic COCOMO a b C
Organic 2.4 1.05 0.38
Semi-detached 3.0 1.12 0.32
Embedded 3.6 1.20 0.32

MM = a * KDSIb

TDEV = 2.5 * MMc

DocPad Page | 5
Intermediate COCOMO
Basic equation for the model is used, but fifteen cost drivers are rated on a scale of 'very
low' to 'very high' to calculate the specific effort multiplier and each of them returns an
adjustment factor which multiplied yields in the total EAF (Effort Adjustment Factor).

EAF
Category Cost Driver Very Low Nominal High Very Extra
Low High High
Product RELY Required Software 0.75 0.88 1.00 1.15 1.40 -
Attributes Reliability
DATA Database Size - 0.94 1.00 1.08 1.16 -
CPLX Product Complexity 0.70 0.85 1.00 1.15 1.30 1.65
Computer TIME Execution Time - - 1.00 1.11 1.30 1.66
Attributes Constraint
STOR Main Storage - - 1.00 1.06 1.21 1.56
Constraint
VIRT Virtual Machine - 0.87 1.00 1.15 1.30 -
Volatility
TURN Computer - 0.87 1.00 1.07 1.15 -
Turnaround Time
Personnel ACAP Analyst Capability 1.46 1.19 1.00 0.96 0.71 -
Attributes AEXP Applications 1.29 1.13 1.00 0.91 0.82 -
Experience
PCAP Programmer 1.42 1.17 1.00 0.86 0.70 -
Capability
VEXP Virtual Machine 1.21 1.10 1.00 0.90 - -
Experience
LEXP Language 1.14 1.07 1.00 0.95 - -
Experience
Project MODP Modern 1.24 1.10 1.00 0.91 0.82 -
Attributes Programming Practices
TOOL Use of Software 1.24 1.10 1.00 0.91 0.83 -
Tools
SCED Required 1.23 1.08 1.00 1.04 1.10 -
Development Schedule

DocPad Page | 6
 Basic COCOMO A b C
Organic 2.4 1.05 0.38
Semi-detached 3.0 1.12 0.32
Embedded 3.6 1.20 0.32

MM=a * KDSIb *EAF

TDEV = 2.2 * MMc

KDSI=5.5, a=3.0, b=1.12, c=0.35

EAF = 1*1.08*1.15*1*1.07*1.0*0.91*0.86*0.95
= 0.988
MM = 3*5.51.12*0.988

= 20.00
TDEV = 2.5*20.000.35

= 2.5*2.85

= 7.125

DocPad Page | 7
1.2.4.2 Function points:

Software Complexity Level Total

System CFP
Compon SIMPLE AVERAGE COMPLEX
ents
Count Weight Point Count Weight Point Count Weight Point
A Factor B C=A*B D Factor E F=D*E G Factor H I=G*
H
User Input 5 3 15 15 4 60 - 6 - 75

User Output 4 4 16 1 5 5 2 7 14 35

User 23 3 69 - 4 - - 6 - 69
Online
Queries
Logical Files 1 7 7 2 10 20 2 15 30 57

External - 5 - - 7 - - 10 - -
Files
Total 107 85 44 236
CFP

CALCULATION OF RCAF

Summarizes the complexity characteristics of the software system

Assign grades (0 to 5) to the 4 subjects that substantially affect the
development effort

RCAF=
The RCAF determines the technical complexity factor TCF = 0.65+0.01*RCAF
FP = CFP*TCF

DocPad Page | 8
 Sr. No Subject Grade
1 Requirement for reliable backup and recovery 3
2 Requirement for data communication 3
3 Extent of distributed processing 3
4 Performance requirements 5
5 Expected operational environment 4
6 Extent of online data entries 3
7 Extent of multi-screen or multi-operation online data input 1
8 Extent of online updating of master files 0
9 Extent of complex inputs, outputs, online queries and files 3
10 Extent of complex data processing 3
11 Extent that currently developed code can be designed for reuse 4
12 Extent of conversion and installation included in the design 4
13 Extent of multiple installations in an organization and variety of 0
customer organizations
14 Extent of change and focus on ease of use 4
Total = RCAF 40

Calculating FP
FP = CFP*TCF
TCF = 0.65+0.01*40
TCF= 1.05
FP = 236*1.05
= 247.8

DocPad Page | 9
1.2.4 Gantt Chart

DocPad Page | 10
1.3 Requirement Specification

1.3.1 Functional Requirements

The application that we are making has the following functional requirement:
Functions of Software:
Creating prescription.
Mailing prescription.
Offline syncing of records.
Handling multiple patients.
Backup and Restore facility.

Doctor Functionality:
Add patient.
Add, view and mail prescription.
View patient history and number of visits.
Backup and Restore data.

Patient Functionality:
View Prescription and history.

1.3.2 Technical Requirements

For running software there are some specification and only if it satisfies the specified
requirement it will get installed and works as it is designed for.
A technical requirement pertains to the technical aspects that your system must fulfil,
such as performance-related issues, reliability issues, and availability issues. These types
of requirements are often called quality of service (QoS) requirements, service level
requirements or non-functional requirements.
For our software also there are some specification there are as follows:

Minimum space required in HDD is 200MB.

RAM required is 2GB.
Screen resolution should be 1024x768 or more.
Internet Connection.
Web browser with latest version or any version that is not old than a year.
Pen drive or external HDD for safe backup.
Windows 7, 8.1 or any higher version.
Works with both 32bit and 64bit Operating System.
Android studio 1.0.1 and above.

DocPad Page | 11
 The system will work properly as intended and smoothly only if the requirements are
met or else the software will work but it may lag.

1.3.3 Software Requirements specification

The DocPad software is designed with the aim of creating prescription and mailing faster
and easier.

The software is capable of creating prescription and mailing to different patients.

The software will have a login that keeps track of different doctors and their patients.

Doctor Functionality:
Add patient.
Add, view and mail prescription.
View patient history and number of visits.
Backup and Restore data.

Patient Functionality:
View Prescription and history.

The software also has backup and recovery options to protect the data. This would
help to recover from any type of software or OS or any other failures.

As per the requirement and guidelines that you have given we have formulated this document
and by signing this document you accept that all the requirements are met. Any change
request hereafter will be chargeable as per the requirement

DocPad Page | 12
1.4 Tools and Technology

Android Studio 1.0.1

Android Studio is the official Integrated Development Environment for Android
application development, based on IntelliJ IDEA. On top of the capabilities expected
from IntelliJ, Android Studio also offers:

i. Flexible Gradle-based build system

ii. Build variants and multiple APK file generation
iii. Code templates to help you build common app features
iv. Rich layout editor with support for drag and drop them
editing
v. Lint tools to catch performance, version compatibility,
usability and other problems
vi. ProGuard and app-signing capabilities
vii. Built-in support for Google Cloud Platform, making it
easy to integrate Google Cloud Messaging and App
Engine.

Graphical User Interface: Android Studio

DocPad Page | 13
 Graphical User Interface: Android
Studio

DocPad Page | 14
 CouchBase

Couchbase Server, originally known as Membase, is an open-source, distributed (shared-

nothing architecture) multi-model NoSQL document-oriented database that is optimized
for interactive applications. These applications may serve many concurrent users by
creating, storing, retrieving, aggregating, manipulating and presenting data. In support
of these kinds of application needs, Couchbase Server is designed to provide easy-to-
scale key-value or JSON document access with low latency and high sustained
throughput. It is designed to be clustered from a single machine to very large-scale
deployments spanning many machines.

Graphical User Interface: Cochbase console

DocPad Page | 15
 Graphical User Interface: Cochbase console

DocPad Page | 16
Languages that we have used in our project are as follows:
JAVA
XML
JSON

JAVA

Java is a set of computer software and specifications developed by Sun Microsystems,

which was later acquired by the Oracle Corporation, that provides a system for
developing application software and deploying it in a cross-platform computing
environment. Java is used in a wide variety of computing platforms from embedded
devices and mobile phones to enterprise servers and supercomputers. While they are less
common than standalone Java applications, Java applets run secure sandboxed
environments to provide many features of native applications and can be embedded
in HTML pages.

XML
Extensible Markup Language (XML) is a markup language that defines a set of rules for
encoding documents in a format which is both human-readable and machine-readable. It
is defined by the W3C's XML 1.0 Specification and by several other related
specifications, all of which are free open standards

JSON
JSON (JavaScript Object Notation) is an open-standard format that uses human-
readable text to transmit data objects consisting of attributevalue pairs. It is the most
common data format used for asynchronous browser/server communication (AJAJ),
largely replacing XML which is used by AJAX.
JSON is a language-independent data format. It derives from JavaScript, but as of 2016,
code to generate and parse JSON-format data is available in many programming
languages. The official Internet media type for JSON is application/json. The JSON
filename extension is .json.

DocPad Page | 17
DESIGN PHASE
2. DESIGN PHASE
2.1 Detailed life cycle of project
2.1.1 Event table

Sr. Event Trigger Source Activity Response Destination

No.
1 Doctor Login Doctor Checks for Opens the Doctor
Login valid Doctor
username account if
and successful
password
2 Doctor Logout Doctor Logs out of The Doctor
Logout application standalone
is closed
3 Add Entering Doctor Adding New Doctor
Patient Patient new Patient gets
details Patient to added
application
4 Edit Entering Doctor Editing Doctor Doctor
Doctor Doctor Doctor in details get
details application edited

5 Edit Editing Patient Editing Patient Patient

Patient patient patient in details get
details application edited
6 Patient Login Patient Checks for Opens the Patient
login valid Patient
username account if
and successful
password
7 Patient Logout Patient Logs out The Patient
logout of standalone
standalone is closed
8 View prescription Patient/ Views Shows Patient/
prescription Doctor prescription prescription Doctor

DocPad Page | 18
2.1.2 ER diagram

Figure: Docpad ER diagram (Doctor)

DocPad Page | 19
 Figure: Docpad ER diagram (Patient)

DocPad Page | 20
2.1.3 Use Case Diagram

Figure: Docpad Use Case Diagram

DocPad Page | 21
2.1.4 Class Diagram

Figure: Class Diagram for DocPad

DocPad Page | 22
2.1.5 Activity Diagram

Figure: Activity Diagram (Doctor)

DocPad Page | 23
 Figure: Activity Diagram (Patient)

DocPad Page | 24
2.1.6 Sequence Diagram

Figure: Sequence Diagram(Doctor)

DocPad Page | 25
 Figure: Sequence Diagram (Patient)

DocPad Page | 26
2.1.7 State Machine Diagram

Figure: State Machine Diagram (Doctor)

DocPad Page | 27
 Figure: State Machine Diagram (Patient)

DocPad Page | 28
2.1.8 Component Diagram

Figure: Component Diagram

DocPad Page | 29
2.1.9 Deployment Chart

Figure: Deployment Diagram

DocPad Page | 30
2.1.10 Site Map

Figure: Sitemap

DocPad Page | 31
2.2 Physical design

2.2.1 System flow chart

START

LOGIN

NO
If Valid

YES

Add/Search

Patient

Create/View

Prescription

Mail Prescription

END

Figure: Doctor flow chart

DocPad Page | 32
 START

LOGIN

NO
If Valid

YES

View

Prescription

END

Figure: Patient flow chart

DocPad Page | 33
IMPLEMENTATION
PHASE
3. IMPLEMENTATION PHASE
3.1 Screen Layout
Main Page & Login Options

DocPad Page | 34
 Doctor Sign Up

DocPad Page | 35
 Doctor Log in

DocPad Page | 36
 Doctor Homepage

DocPad Page | 37
 Doctor Profile & Update

DocPad Page | 38
 Add Patient

DocPad Page | 39
 Search Patient

DocPad Page | 40
 Prescription

DocPad Page | 41
 Send Prescription via Gmail

DocPad Page | 42
 Password Change

DocPad Page | 43
 Patient Login

DocPad Page | 44
 Patient Home

DocPad Page | 45
 Patient Profile & Update

DocPad Page | 46
 Prescription History

DocPad Page | 47
 Prescription (in Gmail)

DocPad Page | 48
 Medicine Search & Online Medicine Purchase

DocPad Page | 49
 Password change

DocPad Page | 50
 About us (Doctor & Patient)

DocPad Page | 51
3.2 Report Layout

Prescription History

DocPad Page | 52
 Prescription History (Patients Email Account)

DocPad Page | 53
3.3 Validations

Validations (Doctor Sign Up)

DocPad Page | 54
 Validations (Doctor Sign Up)

DocPad Page | 55
 Validations (Adding Patient)

DocPad Page | 56
 Validations (Adding Patient)

DocPad Page | 57
 Validations (Login Page)

DocPad Page | 58
 Validations (Doctor Password change)

DocPad Page | 59
 Validations (Patient Password change)

DocPad Page | 60
3.4 Test Cases

Black Box Testing:

Technique: Boundary Value Analysis (BVA)

Form: Doctor Sign up

Sr. No Test Case Input Excepted Actual Result

Output output
1 Enter Name Dillip It should It accepted Pass
accept
2 Enter Name Dillip@123 It should not It did not Pass
accept accepted
3 Enter Email Id Dillip@gmail.com It should It accepted Pass
accept
4 Enter Email Id Dillipgmail.com It should not It did not Pass
accept accepted
5 Enter Phone RGE@123 It should not It did not Pass
number accept accepted
6 Enter Phone 8882634523 It should It accepted Pass
number accept
7 Enter Address 101, Shiv Vallabh It should It accepted Pass
road accept

DocPad Page | 61
Doctor Module:

Sr. No Test Case Input Excepted Output Actual output Result

1 Sign Up First name, Last name, Checks and Doctor is Pass

Password, DOB, validates the Registered
Gender, Email id, details and doctor
Address, Phone is registered if
number, Security details are correct
question
2 Login User name and Checks with Logs in Pass
password database and Logs
in
3 Add patient First name, Last name, Patient should be Patient added Pass
Password, DOB, Email added
id, Address, Phone
number
4 Search Name of patient Details of searched Details of pass
Patient patient should be added patient
viewed is viewed

5 Send Required prescription Patient receives Patient Pass

Prescription should be given the required receives the
prescription prescription
6 Update or First name, Last name, Doctor details or Details Pass
Modify Password, DOB, Email info should be updated
Doctor id, Address, Phone updated
Details or number
Info
7 Logout Click on Logout Checks with Logs out Pass
database and logs successfully
out

DocPad Page | 62
Patient Module:

Sr. No Test Case Input Excepted Output Actual Result

Output
1 Login User name and Checks with Login Pass
password database and logs
in
2 View Click on view Prescription Prescription Pass
Prescription prescription or check should be viewed is viewed
mail
3 Search Click on Medicines Page of medicines Page of Pass
Medicines should appear medicines is
appeared
4 Update or First name, Last Patient details or Details Pass
Modify name, Password, info should be updated
Patient DOB, Email id, updated
Details or Address, Phone
Info number
5 Logout Click on Logout Checks with Logs out Pass
database and logs successfully
out

DocPad Page | 63
White Box Testing:

Technique: Cyclomatic Complexity

Form: Doctor Sign up

Cyclomatic Complexity=E-N+P
Where,
E=number of edges in the flow graph.
N=number of nodes in the flow graph.
P=number of nodes that have exit points.
Cyclomatic Complexity for user validate function.
Here, E=36, N=35, p=2
Therefore, cyclomatic complexity = 36-35+2 = 3
Complexity=3

Basic paths to be tested are

Path 1: 1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16-17-33
Path 2: 1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-18-19-20-21-22-23-24-25-26-27-28-29-34-
35- 32-33
Path 3: 1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-18-19-20-21-22-23-24-25-26-27-28-29-30-
31-32-33

DocPad Page | 64
 Figure: Control Flow Diagram/Graph

DocPad Page | 65
MAINTENANCE AND
EVALUATION
4. MAINTENANCE AND EVALUATION
4.1 System maintenance and future enhancement
The major goal of this application is to create online interaction between doctors
and patients, to fulfill the basic needs/problems of the patients. Patients can update their
problem to doctors by messaging and get advice from the doctor. DocPad serves as the
platform for easy and quick treatment, with extended support from doctors to patients.
DocPad has unique features such as issuing online prescription to patients, referring patients
to a specialist, sending health tips to patients, and finally, reducing the cost of customer
service and providing a vital communication link between doctors and patients.

System Maintenance:
Once the application is deployed, then maintenance phase starts. Application requires
maintenance because there are some residual errors remaining in the system that must be
removed as they are discovered.
In Maintenance we will be doing the following:

Fixing bugs if at all anything found during actual working.

Any minor changes that is required when the client working with it will be done.
Periodic checking of software at regular intervals.
Make better use of existing tools and techniques.
Online technical support at any instance of time.

Future Enhancement:
Nothing can be ended in a single step. It is the fact that nothing is permanent in this world.
So this project also has some future enhancements in the evergreen and booming IT industry.
This app can be improved in the future by adding the following functionalities:

Extending to Apple iOS.

Create two separate apps for doctor & patient.
Sharing the medical test reports of patients to doctors through this app.
Supporting video calls to discuss the problems with doctors.

DocPad Page | 66
4.2 User Manual
1. User (doctor) can register his or her self by filling registration form.
2. User (doctor) can send prescription by login into application.
3. User (patient) can view their all prescription history.
4. User (patient & doctor) can view his or her profile and update also.
5. User (doctor) can register patients.
6. User (doctor) can view patient profile.

DocPad Page | 67
ANNEXURE
5. ANNEXURE

5.1 References

Programming Guide:
Mr. Bhavik Nitin Mer

Videos:
Android Programming Tutorial 2015 | The Complete Tutorial to Learn Android
Developing with Couchbase Lite Android

Websites:
Developer.android.com
www.tutorialspoint.com
Stackoverflow.com
www.couchbase.com

Books:
Programming Android (By: Zigurd Mednieks, Laird Dornin, G. Blake Meike &
Masumi Nakamura)

5.2 Bibliography

http://www.google.co.in
https://en.wikipedia.org/wiki/Couchbase_Server/
http://www.couchbase.com/
http://stackoverflow.com/questions/tagged/android
http://developer.android.com/guide
http://www.tutorialspoint.com/android
https://www.youtube.com/

DocPad Page | 68