DND Documentation Final

ONLINE DIGNOSTIC LAB REPOTING SYSTEM
Vivekanand Education Society’s

Institute Of Information Technology
Collector Colony, Kurla (East),
Mumbai – 400074, Tel: 91-22-261532532.
A Project Report
On
“ONLINE DIAGNOSTIC LAB REPORTING SYSTEM”
Submitted By
Digvijay Jaiswar (20)
Deepanjali Pandey (32)
1
(Web Technology & Web Project Development

Lab)
SUMMER PROJECT
CERTIFICATE
This Mini Project duly signed in this Documentation represents the

bonafide work by ,
Digvijay Jaiswar (20)

Deepanjali Pandey (32)
For SEMESTER - III of Second Year of the Master in Computer

Application (MCA) in the Computer Laboratory of this College during the
academic year 2017-18.
Lecturer In-Charge Head, Department of ICA
Lab In-charge External Examiner
2
ACKNOWLEDGEMENT
It is in good fortune that we find the opportunity to express our deep sense of gratitude
to all those people who helped us with their guidance and assistance without which
this project would not be possible.
The successful completion of any task would be incomplete without the mention of
those people whose cooperation made it possible, whose constant guidance and
encouragement crown all our efforts with success.
We would like to give our heartiest thanks to the Project guide, Prof. Dashrath Mane
for giving us his precious time, incessant encouragement, and for his valuable advice
and guidance without which this project would not have seen the light of day.
We also thank our group members and colleagues who have helped in the successful
completion of this project. And last but not least, we would like to thank all those who
contributed to this project either morally or materially. Thank you all.
3
4
5
6
7
8
ONLINE
DIGNOSTIC LAB
REPORTING
SYSTEM
9
INDEX
CHAPTER TOPIC PAGE NO.
NO.
Acknowledgement 3
1 Synopsis 7
2 Theoretical Background 10
2.1 Introduction of Project 11
2.2 Existing System 11
2.3 Proposed System 11
3 Objectives and Scope 12
3.1 Objectives 13
3.2 Scope 13
4 Problem Definition 14
4.1 Defining a Problem 15
5 System Analysis & Design 16
5.1 Introduction 17
5.2 Risk Analysis 17
5.3 Proposed System Study 17
5.4 System & User Requirements 18-19
5.5 Feasibility Study 19-20
5.6 Diagrams 21
a.) ER diagram 22-27
b.) DFD 28-32
c.) Use Case 33-38
d.) Sequence Diagram 39-48
e.) Activity Diagram 49-50
f.) State Diagram 51-52
g.) Schema Diagram 53
h.) Table List 54-56
6 Planning 57
6.1 System Plan 58
6.2 Gantt Chart 59
7 System Implementation 60
7.1 Methodology Adopted 61-62
10
8 Testing 63
8.1 Testing 64
8.2 Types of Testing 64
8.3 Testing Methodology 65
8.4 Test Cases 66
9 System Maintenance & Evolution 67
9.1 System Maintenance 68
10 Tools For Developing System 69-71
11 Screenshots 72-77
12 User Manual 78-84
13 Cost & Benefit Analysis 85
12.1 Cost Analysis 86-87
12.2 Project Cost Using ‘COCOMO’ 88
12.3 Benefit Analysis 89
14 Limitations 90
Limitation of this Project 91
Conclusion 92-93
Annexure 94
Diagram List 94
Table List 95
Bibliography 96
11
CHAPTER 1:
SYNOPSIS
12
1.1 TITLE: “ONLINE DIAGNOSTIC LAB REPORTING

SYSTEM”
1.2 Statement about the problem

There are no. of sites are available on net those provides efficient services to their
customer as online market, online share trading, online banking, online book shop etc.
But many few sites are available on net related to online diagnostic lab report system.
And those sites don’t provide the test report s on their sites only they provide
information about tests.
1.3 Why this topic

As I mentioned above that few sites are available on web related to the diagnostic
system but usually they do not provides the reporting system to the patients or
customer as other sites provides. So I decide to create a system which is complete
package of all those things as mentioned above.
Where the patients can see the info about tests and can place the tests without
going to any diagnostic centre and they can get reports via email on their mobile
phone or computer. And I make sure that this system could totally changed the old
diagnostic lab reporting system where patients have to came at centre for their reports
but through this system they can get their tests report on their email address.
1.4 Objective and scope

As we know that today web is growing day by day and many people are aware to
net and about its technology. So the patients are able to select the tests easily what
they want to do. The main objective of this system is to save the time of patients and
also save the work of diagnostic centre.
Patients can also get the info about any test by searching or by typing the name of
tests. The scope of this system is to provide 24 X 7 hours services to the customer and
no. Of customer can access this system at the same time from anywhere.
1.5 Proposed architecture

The proposed architecture that we have used in this system is “CLIENT -
SERVER” architecture.
Fig 1.5.1 Proposed Architecture
13
1.6 Methodology
As we are in the learning stage so I have decided to use incremental model for
my system. Because it allow us to debugging the system many times and enhancing
the functions of system.
1.7 Requirements
Hardware requirements
 Memory- 512GB (1.48 GB usable)
 System type: Windows 7
 RAM: 2 GB for 64 bit processor and 1 GB for 32 bit processor.
 Processor: 2.2 GHZ or faster Processor.
Required platform:
 Windows 7 or above
Software requirement:
 Front end: Asp.net
 Back end: SQLSERVER 2014.
1.8 TESTING TECHNOLOGY:

Black box testing approach is used to test this website.
1.9 CONTRIBUTION:
Our project makes current Diagnostic Reporting system automated and saves or
reduces work of and makes the Diagnostic Reporting system more secure.
14
CHAPTER 2:
THEORETICAL
BACKGROUND
15
2.1 Introduction of project

The system is an online diagnostic lab manager application that brings up various
diagnostic working online. Here patients are first allowed to register on the site and
also login using registered details. Once the registered with their address and contact
details, the patients may now see a variety of tests conducted by the lab along with
their costs. The system allows for CBC, blood glucose, KFT, LFT tests to be booked
by patient. Tests are also consists of parameters like Haemoglobin, WBC, RBC etc.
Now the system allows user to book any tests needed. After successful booking
system calculates costs and allows users to pay online. After payment the patient test
is booked and the lab may now collected samples from patients registered address.
After successful testing the user now gets the results through an email. The system
allows admin to attach a copy of the report into the system and automatically email it
to intended patient.
2.2 Existing System

In Existing system all information about patient and the test related Information
are managed manually and this is a very tedious job for operator who want to store
large amount of data and patient related information. But this system is a view to
satisfy the need of all diagnostic or pathology labs who want to store these kinds of
data. This web application helps us to maintain all records of patients and their test
results.
2.2.1 Disadvantage of existing System

The following are the disadvantages of the existing system –
 Data is unorganized. Much time and efforts are requires for searching and
analyzing data from various files.
 The Bundle of Files keeps increasing every year.
 Complications in calculating and generating reports.
 All the data was manually stored in files.
 Each and every task is time consuming.
2.3 Proposed System

In this system, all the information related to the Tests, Patients details and reports
must be added. It also provides security in storing the transaction details. No one can
access information without proper authentication.
2.3.1 Advantages of Proposed System:

Advantages of the system are as follows:
 Since our proposed system does not require advanced and costly devices, it is
low on cost.
 It is user friendly, accurate and robust system. The system will have a GUI so
it provides ease of use and allows valid data entry.
 It provides security of data. The system provides security of data by restricting
access to data.
 It integrates most of the functions into one system. All the important processes
are integrated together for a proper functioning.
 Data inconsistency is reduced to a great extent.
 It reduces paper work completely.
 It provides ease in managing database.
16
CHAPTER 3: OBJECTIVE
AND SCOPE
17
3.1 Objective:
1) The System allows automated diagnostic system.
2) Allows for faster services.
3) Allow increased sales and profits for diagnostic lab.
3.2 Scope:
Scope of this system is very limited where patients can select the test and also can
get their reports online via email.
18
CHAPTER 4: PROBLEM
DEFINITION
19
4.1 DEFINING A PROBLEM:

Identification of the problem is one of the obvious tasks to be performed before
developing a project. A clear understanding of the problem will help build a better
system and reduce the risk of project failure.
This phase consists of two main tasks:
a. The first is to review the needs that originally initiated the project.
b. The second is to identify at an abstract level the expected capabilities of the new
system.
It helps in understanding the system properly so that all the problems are identified
correctly. It also involves considering all the alternatives that exist to achieve the
objectives with respect to modifying the system, even all the various ways to
implement the alternatives.
After we thoroughly understood the existing system, it was concluded that all of the
work was done manually. All kinds of calculations and planning were done using the
human brain instead of taking advantage of the modern Information Technology.
The following limitations were found out in the existing system:

a. Increased paper work.
b. Extended time to access the data, and to search required data.
c. Absence of integration data.
d. Error-prone due to manual work.
e. Lack of tools for manipulation of data.
The proposed system will overcome all problems mentioned above:

a. Storing data into database.
b. Less time required to access the data.
c. No redundancy of data.
d. Reducing manual work by doing tasks automatically.
e. Data Integration is provided.
f. Data is secured from leakage as it is accessible to authenticated user.
20
CHAPTER 5: SYSTEM
ANLYSIS AND DESIGN
21
5.1 Introduction:
In System Analysis and Design phase, the whole software development process,
the overall software structure and its outlay are defined. Analysis and Design are very
important in the whole development cycle process. Any fault in the design phase
could be very expensive to solve in the software development process. In this phase,
the logical product of the system is developed. The software development process, the
software's overall structure and its nuances are defined.
This step refers to the gathering of system requirements, with the goal of
determining how these requirements will be accommodated in the system. Extensive
communication between the customer and the developer is essential. The developer
has to develop the system to meet the client‘s needs. But the developer usually does
not fully understand the client‘s problem domain, and the client often does not
understand the issues involved in the software systems. This causes communication
gap, which can be bridged by gathering information from the client and also making
him understand what the system will do.
In this phase, database design and the data structure design etc. are defined for our
system.
After designing phase, a software development model is created.
5.2 RISK ANALSIS:

Risk Analysis is mostly done at the start of the project. Before collecting all the
information we must check whether it is feasible, safe to do the project or to check
any risk that may occur during the process. These risks may occur at any point during
the process and if proper measures aren’t taken it affects the project in different ways.
There are 3 types of risks:
a. Business
b. Project
c. Product
5.3 PROPOSED SYSTEM STUDY:

It is always necessary to study and recognize the problem of the existing system,
which will help in finding out the requirements for the new system. A thorough study
of the proposed system involves finding different alternatives for a better solution.
This step basically deals with the following different operations:

a. Data Gathering
b. Study of Existing System
c. Analyzing problem
d. Studying various documents
e. Feasibility study for further improvement
5.3.1 TOOLS AND TECHNIQUES USED FOR INFORMATION

GATHERING
Interviews:
I prepared some questionnaires so as to study the actual problems being faced by
the staff in the current method of functioning. It was a kind of informal interview with
the Doctor and Staff working in the Diagnostic center.
These were some of the questions I asked:
 What are the resources required?
22
 Who is responsible for the system?

 How much time is required for the above mentioned processes?
 What all facilities do you expect from the new system?
 How the processes should be handling by the system?
 Which types of functionality should be provided to the patients?
Internet Research:
The Internet is an indispensable tool for getting most of the doubts cleared, if in
case not done so by above methods. Almost any kind of information is available
through the Internet at a click of the mouse. The resources which I referred through
internet are mentioned in the references section of this Document.
5.4 SYSTEM REQUIREMENT

Function: To sends the reports of Test.
Description: Here the patients can selects the test and can pay online or by cash. Once
the test has been done the OPERATOR sends the reports to them via their email id.
Input: The operator can insert and update the test list.
Source: The source is the DIAGNOSTIC CENTER who want to provide better
interface to their
User.
Output: Patients can select the Test.
Destination: Patient who are interested to book the test order.
Action: Patient chooses the test to select and go through the process of payment. Once
successfully
Done with payment process, the reports is then delivered to the patients email
address.
Requires: access to the website i.e. registered user
Pre-condition: patients must be signed in through their proper ID.
Post-condition: Patients successfully passes through payment process.
Side-effect: None.
5.5 User Requirement
5.5.1 Functional requirement:

1) It decided what the system should do.
2) In this system there are two kinds of user are present.
 Operator
 Patients
1.Operator:
 Operator can insert, delete or do any modification in the system.
 It can add new user, update, user information or delete an existing detail of user.
23
 It sends the reports to patients and also can see the status as well as it gives the
appointment to the patients.
2.Patients:
 Patients can register themselves.
 After successful registration patients can login by their respective username or
email id and with password.
 Once the user fills the details, now they are able to select the appropriate test
which they want to do, and they also able to see the details related to tests.
 After that patients can be able to make transaction. After successful
transaction the system informs the patients that their tests get booked and
gives the appointment. And then customers can logout.
5.3.2 Non Functional requirement

These are not directly concern with the service provided.
1. Performance:
Software should support the use of database or application by multiple users at the
same time.
2. Safety:
As the database contains the important data therefore, backup should be present and
that backup should be updated regularly these is because system may crash due to
some hardware or power failure or operating system failure.
3. Security:
Only system operator can handle database directly but with proper authentication. No
one other than authenticated user must not able to access database directly or
indirectly.
4. Availability:
System should be available to operator as well as user at any time.
5.6 Feasibility Study

A feasibility study is performed by a company when they want to know whether a
project is possible in given certain circumstances. It undertake by many circumstances
to find out whether an organization has enough money for a project to find out
whether the product being created will sell, or to see if there are enough human
resources for the project.
A good feasibility study shows the strength and deficits before the project is
planned or budget for.
The different types of feasibility are as follows:

 Economic feasibility.
 Operational feasibility.
 Technical feasibility.
 Scheduled and
 Resource feasibility.
24
 Economic feasibility study: Economic Feasibility study is most required to

develop a system because of that we are able to estimate how much cost are
required to develop a project or if the system cost is greater than estimated cost
then the project is in loss. On the basis of feasibility study we are able to calculate
the system is feasible with our budget or not.
 Operational: Operational feasibility is a measure of how well a proposed system
solves the problems, and takes advantage of the opportunities identified during
scope definition and how it satisfies the requirements identified in the
requirements analysis phase of system development. The new system has
completely user friendly interface. It has been designed to be pretty intuitive, so
that even an inexperienced person can easily handle the system.
 Technical Feasibility study: Technological feasibility is carried out to determine
whether the company has the capability, in terms of software, hardware, personnel
to handle the completion of the project.
 Schedule: Typically this means estimating how long the system will take to
develop, and if it can be completed in a given time period using some methods
like payback period. Schedule feasibility is a measure of how reasonable the
project timetable is.
 Resources Feasibility: it specifies whether the company or an organization have
enough resources to develop a project or not. It also determines if resources are
available then what amounts of resources are required to develop a project and
what facilities will be required for the project.
25
5.7 DIAGRAMS
5.7.1 E-R Diagram
Notations:
Rectangle represents entity sets.
Ellipse represents attributes.
Diamond represents relationships.
It Represents one to one relationship.
It represents one to many relationships.
It represents many to one relationship.
It represents many to many

relationships
Fig 5.7.1.1 Notations
26
Entities used in my system:

1) Patients
Entity Description: it represents the patient’s entity where patients can register
themselves.
Full_name
ID
Email_id
Password
Patients Contact no
Gender
Fig 5.7.1.2 Patients
2) Test
Entity description: The test table includes the list of test conducted by laboratory.
T_code
T_id
T_name
Test
Price
Details
Fig 5.7.1.3 Test
27
3) Book a Test
Entity description: it allows booking a test to patients.
Test_name
BT_id
User_id User_name
Book a Test
Test_Cost
Email_id
Booking_Date
Fig 5.7.1.4 Book a test
4) Operator
Entity description: It holds the entry of operator.
Fig.5.7.1.5 Operator
28
5) Reports
Entity description: it is used for creating the reports.
R_id PT_id
R_time
Report
L_Id
Test_id R_date
Test_id
Fig 5.7.1.6 Reports
6) Appointment
Entity description: It is used for storing the appointment details made by the patients.
PT_id
Ap_id
Appo_Date Test_id
Appo_Time Patient detail
Address
User name
Age
Fig 5.7.1.7 Appointment
29
7) Laboratory
Entity description: It has a detail of diagnostic centre.
L_id L_Name
O_id L_ Address
Laboratory
L_ Contact
Email id
L_Regd_no
Fig 5.7.1.8 Laboratory
8) Notification
Entity description: the operator sends the notification to the patients as confirmation
of their appointment.
Sn_id
Pt_id
Message
Notification
Pt_Email
L_Email
Fig 5.7.1.9 Notification
30
9) Payment
Entity Description: it allows making a transaction.
Pt_name Pt_id
Pmnt_id Bt_id
Test_cost Age
User_email
Apmnt_Time Payment
Address
Apmnt_Date Booked_Test
creditCardNo
SamplePlace CvvNo
ExpiryDate
PaymentMode
Ap_Id
Fig 5.7.1.10 Payment
ER DIAGRAM:
Patients Book Book a Test

31
for
Sent
Fig 5.7.1.11 ER Diagram
5.7.2 DATA FLOW DIAGRAM
32
A data flow diagram (DFD) is a graphical representation of the "flow" of data

through an information system. It differs from the flowchart as it shows the data flow
instead of the control flow of the program. A data flow diagram can also be used for
the visualization of data processing (structured design). Data flow diagrams were
invented by Larry Constantine, the original developer of structured design, based on
Martin and Estrin's "data flow graph" model of computation.
A DFD shows what kinds of data 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 processes, or information about whether processes
will operate in sequence or in parallel
1) Notations:
Name Symbols Description

Process A process transforms
incoming data flow into
outgoing data flow.
Data stores are repositories

Data Store Notation of data in the system.
Data flow notations Data flows are pipelines

through which packets of
information flow. Label the
arrows with the name of the
data that moves through it.
External entity External entities are

objects outside the system,
with which the system
communicates.
33
2) 0 Level DFD:
Fig 5.7.2.2 0 Level DFD
34
First level DFD:
Fig 5.7.2.3 1 Level DFD
35
Second Level DFD:
1) Login
Fig 5.7.3.1 Login
2) Manage test List
Fig 5.7.3.2 Manage test list
36
3) Generating and sending the report.
Fig 5.7.2.3 Generate and send the reports.
37
5.7.3 USE CASE:

A use case is a list of steps, typically defining interactions between a role (known
in UML as an "actor") and a system, to achieve a goal. The actor can be a human or an
external system.
Notation:
Name Notation Description

Actor is represents a user
or another system that will
Actor interact with the system
you are modeling
Use Case It is an external view

of the system that
represents some
action.
Fig 5.7.3.1 Notation
38
Use case for Online Diagnostic Lab Reporting System.
System
Register
Login
Check for tests availability
Book test
Patients
Appointment
Payment
Check Report
operator
Perform opertations
Verifies the Patients details
Make report
Send mail
Logout
Fig 5.7.3.2 Use Case
39
1 Descriptions of Patients Use Case:

1. Use case name: Register
Participating Actors: Patients
Flow of events:
1. System Creates an account for a patients and provides the user id and
password.
Alternate flow:
1) System has nothing to search.
2) System informs actor and ask to fill the details again.
3) If details entered by actor does not matches with Entered details in database,
then system
Informs the Patients and ask to fill the details again.
Entry condition: Waiting to register.
Exit condition: Entered details are not correct or some field value missing.
2. Use case name: Login

Flow of events:
1). Fill Login details according to actor.
2). System searches for the details in the database.
3). If login details matches, then appropriate page is displayed to an actor.
Alternate flow:
1). System has nothing to search.
2).System informs actor and ask to fill the details again.
3).If details entered by actor does not matches with Entered details in database,
then system
Inform to actor and ask to enter details again.
Entry condition: Actor must be registered before login or must enter proper details.
3. Use case name: Check for test availability

Flow of events:
1). Actor searches for tests in the test list.
3). If test name matches, then appropriate page is displayed to an actor.
Alternate flow:
2). If details entered by actor does not matches with Entered details in
database, then system
Entry condition: Waiting to search.
4. Use case name: Book test

Flow of events:
1). System asks the actor to fill the details.
2). System stores all details into database.
3).Confirms the booking.
Alternate flow:
40
2).System informs actor and ask to fill the details again.

3).If details entered by actor does not matches with Entered details in database,
then system
Entry condition: Waiting to book.
Exit condition: Waiting for booked.
5. Use case name: Make Appointment

Flow of events:
1). Fills the required details.
2). System stores the details.
Alternate flow:
2). If details entered by actor does not correct, then system Informs to actor
and ask to enter
Details again.
Entry condition: Actor must to book the test to view this page.
6. Use case name: Make payment

Flow of events:
1). Fills the required details.
2). System stores the details.
3). If transaction details are matches, then appropriate page is displayed to an
actor.
Alternate flow:
2). If details entered by actor does not correct, then system Informs to actor and
ask to enter
Details again.
Entry condition: Actor must make the Appointments to view this page.
7. Use case name: Check Report

Flow of events:
1). To view information about patient test report details must enter user id.
3). If required details match, then appropriate details are displayed to an actor.
Alternate flow:
2). System informs actor and ask to fill the details again.
3). If details entered by actor does not matches with exits details in database,
then system
Informs to actor and ask to enter details again.
Entry condition: Actor must be Book the test before this or must enter proper details.
2. Description of Operator Use Case.

41
1. Use case name: Login

Participating Actors: Operator
Flow of events:
Alternate flow:
3). If details entered by actor does not matches with Entered details in database,
then system
2. Use case name: Check status

Flow of events:
1). Request for patients details.
3). If details matched, then appropriate page is displayed to an actor.
Alternate flow:
then system
Entry condition: Actor must be login before this step or must enter proper details.
3. Use case name: Verifies the patients details

Flow of events:
1). Fill the details according to Patients.
Alternate flow:
3). If details entered by actor does not matches with current details in database,
then system
4. Use case name: Give appointment

Flow of events:
2). System stores and searches the details in the database.
3). If details matched, then only then appointment has been booked.
Alternate flow:
42

then system
Entry condition: Actor must be verifies the patient details before giving appointment
or must Enter proper details.
5. Use case name: Make Report

Flow of events:
1). Fill required details according to actor.
3). If entered details matches, then only then report will be.
Alternate flow:
then system
Entry condition: for this the actor must be sure that the patients should perform the
test.
6. Use case name: Send mail

Flow of events:
1). Fill required details according to actor.
3). If entered details matches, then only then report will be.
4). Operator enters the details according to test result.
Alternate flow:
1).System has nothing to search.
then system
Entry condition: for this the actor must be sure that the patients should perform the
test.
43
5.7.4 Sequence Diagram

A sequence diagram in a Unified Modeling Language (UML) is a kind of
interaction diagram that shows how processes operate with one another and in what
order. A sequence diagram shows object interactions arranged in time sequence. It
depicts the objects and classes involved in the scenario and the sequence of messages
exchanged between the objects needed to carry out the functionality of the scenario.
Sequence diagrams typically are associated with use case realizations in the Logical
View of the system under development.
Notations:
Name Symbol Description
Synchronous An instantaneous
Message communication
between
objects that conveys
Information.
Activation The period during

which an object is
performing an
Action.
An object that is
Objects Instance created,
performs actions,
and/or is
destroyed during the
lifeline.
Fig 5.7.4.1 Notation
44
Sequence Diagram for operator:

1) Login:
Operator System Database
1 : Request for login()
2 : display Login window()
3 : Enter Email_id and password()
4 : Verify Admin details()
5 : Report()
6 : Error()
7 : Successful Message()
Fig 5.7.4.2 Login
2) Check Status:
1 : Request for Status()
2 : Display Status Windows()
3 : Enter details()
4 : Searching Details in Database()
5 : Report()
6 : Error()
7 : Successful()
Fig 5.7.4.3 Check Status
45
3) Perform operation
Operator
System Database
1 : Request for operations()
2 : Display windows()
3 : Enter details()
4 : Store into database()
5 : Report()
6 : Error()
7 : Successful()
Fig 5.7.4.4 Perform operation
4) Verifies the Users details:
Object1 Object3
Object2
1 : Requesting for Verifyimg the patient details()
2 : Display WIndows()
3 : Ask for Patient Details()
4 : Check Details()
5 : Report()
6 : Error()
7 : Display information()
Fig 5.7.4.5 verifies the Users details
46
5) Make report:
Patients System
Database
1 : Request for report()
2 : Diaplay window()
3 : Enter Details()
4 : Store info()
5 : Report()
6 : Error()
7 : Successful()
Fig 5.7.4.6 Make report
47
6) Send reports:
1 : request for report()
2 : display report window()
3 : Enter required details()
4 : Verify Patients details()
5 : Report()
6 : Error()
8 : Enter Parameter details()
9 : Stores the data into database()
10 : Report()
11 : ask to send the report()
12 : Confirms()
13 : Stores the report()
14 : Process()
15 : Successful message()
Fig 5.7.4.7 Send Report
48
7) Logout:
Operator
System Database
1 : Request For Logout()
2 : Store all information()
3 : Report()
4 : Display message()
5 : Confirm/Cancel()
6 : Successful()
Fig 5.7.4.8 Logout
2. Sequence Diagram for patients:

1) Registration
Patients System
Database
1 : Request for registration()
2 : Display forms()
3 : Enter Required details()
4 : Error/ Proceed() 5 : Store information()
6 : Report()
7 : Error Message()
8 : Successful()
Fig 5.7.4.9 Registration
49
2) Login:
Patients System Database
1 : Request for login()
2 : display Login window()
3 : Enter Email_id and password()
4 : Verify Patients details()
5 : Report()
6 : Error()
Fig 5.7.4.10 Login
3) Check for test availability:
Patients System Database
1 : Request for test()
2 : Check For availability()
3 : Sends Report()
4 : Display Availability Message()
Fig 5.7.4.11 Check for Test availability
50
4) Book Test:
1 : Request for booking()
2 : Display form()
3 : Enter required details()
4 : Confirms booking()
5 : Store all details()
6 : Report()
7 : Error()
8 : Successful()
Fig 5.7.4.12 Book Test
5) Sequence for Appointment:
Patients
System Database
1 : Request for appointment()
2 : Display appointment windows()
3 : Enter appointment details()
4 : Store information()
5 : Report()
6 : Error()
7 : Successful()
Fig 5.7.4.13 Appointment
51
6) Make payment:
Patients System
Database
1 : Requesting for make payment()
3 : Enter Required details()
4 : Store information()
5 : Report()
6 : Error()
7 : Successful()
Fig 5.7.4.14 Make Payment
7) Check report:
1 : Request for report()
3 : Enter details()
4 : Store info()
5 : Report()
6 : Error()
7 : Successful()
Fig 5.7.4.15 Check Report
52
8) Logout
Patients
System Database
1 : Request For Logout()
2 : Store all information()
3 : Report()
4 : Display message()
5 : Confirm/Cancel()
6 : Successful()
Fig 5.7.4.16 Logout
53
5.7.5 ACTIVITY DIAGRAM:

Activity diagrams are graphical representations of workflows of stepwise
activities and actions with support for choice, iteration and concurrency.
Notations:
A transition link represents

Free-form control flow between nodes
transition link
Rounded It represents the activity

Rectangle
A logic where a decision is

Diamond to be made is depicted by a
diamond
Initial Activity This shows the starting

point or first activity of the
flow.
The end of the Activity

Final activity diagram, also called as a
final activity.
54
System
Patients
Home Page
Operator
Login check input Register
unsuccessful Check input Unsuccess

Enter Details
enter details
Login
verify input
Check input
unsuccess
Main Page UserName & Password
Successful
Unsuccessful
Select Menu
Main Page
Check Input
Check input
Operation Select Menu
Registered User Unsuccess

unsuccess Book a test
Unsuccess
send mail Verifies Input

Verifies Input
appointment
Unsuccess
Appointment Details
unsuccess Unsuccess
Transaction
Unsuccess
Perform operation Unsuccess
Report
Store info
success
Store info
Response
Perform Task
Take info
Take info
Logout
Log out
Fig 5.7.5.2 Activity Diagram
55
5.7.6 State machine diagram

A state machine model is a model whose nodes are states and directed arcs
transition between states. A state machine model specifies the state sequence
caused by event sequence state names must be unique within the scope of a
state machine model.
Notation:
A transition link represents

Free-form control flow between nodes
transition link
Rounded It represents the activity

Rectangle
Initial Activity This shows the starting

point or first activity of the
flow.
Final activity The end of the Activity

diagram, also called as a
final activity.
56
State Machine Diagram:
Idle
Waiting for Registration/ login
Invalid Enter details
Verifies the details
Patients
operator
Display user window
Display main window
invalid book test

Select any menu for operation
invalid
Appointment
Perform operation
verify input
invalid Transaction
Process data
Display result see notification
Logout Logout
Fig 5.7.6.2 State machine diagram
57
5.7.7 Database schema:

Patients Book a Test Operator
Pt_ID Bt_id OP_id
Full_name User_name Op_name

Contact Email_id Op_email
Email Test_name Op_Contact
Gender BookingDate Op_Password
Password Test_cost
User_id
Laboratory Send Notificaion Test

L_id SN_id Test_id
L_name Pt_id Test_name

L_address Pt_email Test_Details
L_Contact L_email Test_Code
L_email Message Test_Price
L_regdNo
OP_id
Payment
Pmnt_id
Appointment PatientName Report
Ap_id Pt_id
R_id
BookingId
User_name Pt_age
User_name
Pt_id User_email
User_id
Booking_id Address
Test_id
Age BookedTest
L_id
Address TestCost
OP_id
Appo_Time Apmnt_Time
R_Date
Appo_Date Apmnt_Date
R_Time
SamplePlace
Test_Parameter
PaymentMode
CreditCardNo
CVV_no
Expiry_date
Ap_id
Fig 5.7.7.1Schema Diagram
58
5.7.8 Table List:

Registration table:
Sr no Fields Data Types Allow Nulls Keys

1 Pt_id Int No Primary keys
2 Full Name Varchar(50) No -
3 Email Varchar(50) No -
4 Gender Varchar(50) No -
5 Password Varchar(50) No -
Fig 5.7.8.1 Registration Table
Test table:

1 T_id Int No Primary keys
2 Test Name Varchar(50) No -
3 Test Details Varchar(MAX) No -
4 Price Numeric(5,0) No -
Fig 5.7.8.2 Test Table
Operator table:

1 OP_id Int No Primary Keys
2 OP_Name Varchar(50) No -
3 OP_email Varchar(50) No -
4 OP_Contact Varchar(50) No -
5 OP_Password nVarChar(50) No -
Fig 5.7.8.3 Operator Table
Send Notification table:

1 SN_id Int No Primary keys
2 Pt_id Int No Foreign keys
3 L_email Varchar(50) No -
4 Pt_email Varchar(50) No -
5 Message Varchar(MAX) No -
Fig 5.7.8.4 Send Notification Table
59
Book Test table:

1 Bt_id Int No Primary key
2 User Name Varchar(50) No -
3 Email_id Varchar(50) No -
4 Test Name Varchar(50) No -
5 Booking Date Date No -
6 Test Cost Numeric(5,0) No -
7 User_id Int No Foreign Key
Fig 5.7.8.5 Book Test Table
Laboratory table:

1 L_id Int No Primary key
2 L_Name Varchar(50) No -
3 L_Address Varchar(MAX) No -
4 L_Contact Numeric(10,0) No -
5 L_Email Varchar(50) No -
6 L_RegdNo nVArchar(10) No -
7 Op_Id Int No Foreign key
Fig 5.7.8.6 Laboratory Table
Appointment table:

1 Ap_id Int No Primary keys
2 User_name Pt_id No -
3 Pt_id Int No Foreign Key
4 Booking_id Int No Foreign Key
5 Age nChar(3) No -
6 Address Varchar(Max) No -
7 Appo_Time nVarchar(20) No -
8 Appo_Date nVarchar(20) No -
Fig 5.7.8.7 Appointment Table
60
Report table:

1 R_id Int No Primary Key
2 User_name Varchar(50) No -
3 User_id Int No Foreign Key
4 Test_id Int No Foreign Key
5 L_id Int No Foreign Key
6 O_id Int No Foreign Key
7 R_Date Date No -
8 R_Time nVarchar(20) No -
9 Test Parameter nVarchar(25) No -
Fig 5.7.8.8 Report Table
Payment table:

1 Pmnt_id Int No Primary key
2 User Name Varchar(50) No -
3 Pt_id Int No Foreign Key
4 BookingId Int No Foreign Key
5 Pt_age Numeric(3,0) No -
6 Pt_email Varchar(50) No -
7 Address Varchar(MAX) No -
8 Booked Test Varchar(50) No -
9 TestCost Numeric(5,0) No -
10 Apmnt_Time nVarchar(25) No -
11 Apmnt_Date Date No -
12 SamplePlace Varchar(50) No -
13 PaymentMode Varchar(50) No -
14 CreditCardNo Numeric(16,0) No -
15 CVV No Numeric(3,0) No -
16 Expiry Date Date No -
17 Ap_id Int No Foreign keys
Fig 5.7.8.9 Payment Table
61
CHAPTER 6: SYSTEM
PLANNING
62
6.1 Project Plan:

Tas Task name Duration Dependencie Start Finish
k no s
T1 Project 2 Days _ 8th Apr 2018 9th Apr 2018
Definition
T2 Requirement 5 Days T1(m1) 10th Apr 2018 15th Apr 2018
Gathering
T3 Requirement 6 Days T2(m2) 16th Apr 2018 22nd Apr 2018
analysis
T4 Er and schema 8 Days T3(m3) 23th Apr 2018 30th Apr 2018
Diagram
T5 Architecture 7 Days T3,T4(m4) 1st May 2018 8th May 2018
Design
Uml Design
T6 Data flow 8 Days T5(m5) 9th May 2018 17th May 2018
T7 Use case 7 Days T6(m6) 18th May 2018 25th May 2018
T8 Sequence 5 Days T7(m7) 26th May 2018 30th May 2018
diagram
T9 Activity 6 Days T8(m8) 1st June 2018 7th June 2018
Diagram
T10 State Diagram 4 Days T9(m9) 8th June 2018 12th June 2018
T11 Project 4 Days 13th June 2018 17th June 2018
Planning T2,T3,T10(m
10)
T12 Test Case 7 Days T4,T6(m11) 18th June 2018 25th June 2018
Preparation
Coding and
Testing
Module 1:
T13 Development 15 Days T12(m12) 16th June 2018 30th June
2018
T14 Component 6 Days T13(m13) 1st July 2018 7th July 2018
Testing
Module 2:
T15 Development 14 Days T14(m14) 8th July 2018 22nd July 2018
T16 Testing 7 Days T15(m15) 23rd July 2018 31st July 2018
T17 Integration 10 Days T14,T16(m16 1st Aug 2018 10th Aug 2018
Testing (1&2) )
Module3:
T18 Development 10 Days T17(m17) 11th Aug 2018 20th Aug 2018
T19 Testing 5 Days T18(m18) 21st Aug 2018 26th Aug 2018
T20 Integration 8 Days T19(m19) 27th Aug 2018 6th Sept 2018
Testing(1,2&3)
T21 System Testing 6 Days T20(m20) 7th Sept 2018 13th Sept 2018
T22 Acceptance 4 Days T21(m20) 14th Sept 2018 18th Sept 2018
Testing
T23 Implementation 3 Days T22(m22) 19th Sept 2018 22nd Sept 2018
63
Fig 6.1 Project Plan
6.2 Gantt Chart:
08-08-15 27-09-15 16-11-15 05-01-16 24-02-16

T1
T3
T5
T7
T9
START DATE
T11
DURATION
T13
T15
T17
T19
T21
T23
64
CHAPTER 7: SYSTEM
IMPLEMENTATION
65
7.1 METHODOLOGY ADOPTED: INCREMENTAL

MODEL
-Incremental Model:
 It is the method of software development where the model is designed,
implemented & tested incrementally until the product is finished.
 It involves both of development & maintenance.
 In this we can say product is finished when it satisfies or meets all its
requirements.
 All the series of releases is referred as ‘increments’ with each contains
more functionality.
Why this Model is selected?

As all the requirements for my project are well defined & well understood
and also I thought that in future new requirements may arise from the user &
this as all is supported by the incremental model, I have selected it.
It is divided in following stages:
# Analysis –
Decision over changes to be implemented in the next stage are taken here.
Only small portions are implemented at a time.
# Design –
It includes:
1) What the interface will look like.
Fig 7.1 Incremental Model
66
2) How the data will be validated.

# Coding –
Compiling the code to make sure that the code is correct.
# Testing –
It involves running the program by using test data if it is requested.
If error occurs then the program is debugged & either code or design is altered
/ changed.
Advantages & Disadvantages of Incremental Model:

Advantages:-
Generates working software quickly and early during software life cycle.
More flexible-less costly to change scope & requirements.
Easy to test & debug during smaller iteration.
Easy to handle risk as they are identified during iteration.
Disadvantages:-
Needs good planning & design.
Needs clear & complete definition of system.
New requirements might needs new equipment & also will increase budget.
67
CHAPTER 8: TESTING
68
8.1 TESTING:
Software testing is a process which is used to measure the quality of
software developed. It is also a process of uncovering errors in a program and
makes it a feasible task. It is useful process of executing program with the
intent of finding bugs.
In order to prove that a piece of software works, the software must be tested to
determine if the requirements of the application are met. There are several
different types of tests used throughout the development process. The two
main types of testing are white box and black box testing.
White box test cases are used to test specific paths through the code. At
decision points you can test the boundaries of the decision (boundary testing)
and the partitions of the decision (partition testing).
8.2 TYPES OF TESTING:

8.2.1 WHITE-BOX TESTING:
In white-box testing an internal perspective of the system, as well as
programming skills, are used to design test cases. The tester chooses inputs to
exercise paths through the code and determine the appropriate outputs.
8.2.2 BLACK-BOX TESTING:

Black box testing have little or no regard to the internal logical structure of
the system, it only examines the fundamental aspect of the system. It makes
sure that input is properly accepted and output is correctly produced.
8.2.3 FUNCTIONAL TESTING:

Functional tests involve exercising the code with nominal input values
which gives the expected results and boundary values are known.
8.2.4 PERFORMANCE TESTING:

Performance tests are designed to verify response time. If the wrong data is
entered then the system does not allow it and calculations are not performed.
8.2.5 INTEGRATION TESTING:

Integration testing is critical to ensure the functional correctness of the
integrated system.
Integration testing can be divided into two categories. Integration testing is
often the most time consuming and expensive part of testing.
8.2.6 UNIT TESTING:

The first test in the development process is the unit test. The source code is
normally divided into modules, which in turn are divided into smaller units
called units. These units have specific behavior. The test done on these units
of code is called unit test. Unit test depends upon the language on which the
project is developed. Unit tests ensure that each unique path of the project
performs accurately to the documented specifications and contains clearly
defined inputs and expected results.
69
8.2.7 SYSTEM TESTING:

Several modules constitute a project. If the project is long-term project,
several developers write the modules. Once all the modules are integrated,
several errors may arise. The testing done at this stage is called system test.
System testing ensures that the entire integrated software system meets
requirements. It tests a configuration to ensure known and predictable results.
System testing is based on process descriptions and flows, emphasizing pre-
driven process links and integration points.
8.3 TESTING METHODOLOGY:

There are two basic approaches to testing: black-box and white-box. In
black-box testing the structure of the program is not considered. Test cases are
decided solely on the basis of the requirements or specifications of the
program or module, and the internals of the module or the program are not
considered for selection of test cases. White-box testing, on the other hand is
concerned with testing the implementation of the program. The intent is not to
exercise all the different input or output conditions (although that may be a by-
product) but to exercise the different programming structures and data
structures used in the program.
‘White box testing approach not required to test this website.’
Because, this website restricts user to enter wrong values, if user try to entered
wrong value, website won’t allow entering that value.
Therefore, white box testing is not necessary.
‘Black box testing approach is used to test this website.’
BLACK-BOX TESTING:
In this testing, the structure of the program is not considered. Test cases
are decided solely on the basis of the requirements of specifications of the
program or module, and the intervals of the module or program are not
considered for the selection of test cases.
In black box testing, the tester only knows the inputs that can be given to
the system and what output the system should give. In other words, the basis
for declining test cases in functional testing is the requirements or
specifications of the system or module. This form of testing is also called
functional or behavioral testing.
There are various levels of testing which are as follows:
a. Unit testing: Unit testing is essentially for the verification of the code
produced during the code phase.
b. System testing: The entire software is tested.
c. Acceptance testing: The external behavior of the system is focused.
70
8.4 TEST CASES:

If there is a fault in a program, the program can still provide the expected
behavior for many inputs. Only for the set of inputs that exercise the fault in
the program will the output of the program deviate from the expected
behavior. The two fundamental goals of a practical testing activity are —
maximize the number of errors detected and minimize the number of test cases
(i.e., minimize the cost). Hence, an ideal test case set is one that succeeds
(meaning that its execution reveals no errors) only if there are no errors in the
program.
Test case table:
Sr. No. Name Input Expected Actual Output Remark

Output
1. Login Page Valid Navigates to Navigates to Pass
credentials requested page requested page
2. Login Page Invalid Popup showing Popup showing Pass
credentials invalid invalid
password for password for
selected user selected user
3. Request Valid Open Admin Open Admin Pass
Admin Page credentials Page Page
4. Invalid Popup showing Popup showing Pass
Admin Page credentials invalid invalid
password or password or
user name user name
5. Valid details Open Open Pass
Request for Appointment Appointment
book a test Page Page
6. Invalid Error message Error message Pass
Book a test credentials
7. Valid details Navigates to Navigates to Pass
Request for Make Payment Make Payment
Appointment page page
8. Invalid details Popup showing Popup showing Pass
Appointment invalid invalid
page message message
11. Admin Navigates to Navigates to pass
Request for Patients details Patients details
Patients details page page
page
12. Admin Navigate to Navigate to Pass
Request for sending mail sending mail
sending report page paper page
exam
Fig 8.4 Test Case
71
CHAPTER 9: SYSTEM
MAINTAINANCE AND
EVOLUTION
72
9.1 SYSTEM MAINTAINANCE:

Software maintenance is defined in the IEEE Standard for Software
Maintenance, IEEE 1219 [IEEE 1219], as the modification of a software
product after delivery to correct faults, to improve performance or other
attributes, or to adapt the product to a modified environment.
Software maintenance is a very broad activity that includes error
corrections, enhancements of capabilities, deletion of obsolete capabilities,
and optimization. Because change is inevitable, mechanism must be developed
for evaluation, controlling and making modifications. So any work done to
change the software after it is in operation is considered to be maintenance
work. The purpose is to preserve the value of software over the time. The
value can be enhanced by expanding the customer base, meeting additional
requirements, becoming easier to use, more efficient and employing newer
technology. Maintenance may span for 20 years, whereas development may be
1-2 years. Maintenance is not a part of software development, but is an
extremely important activity in the life of a software product. Maintenance
includes all the activities after installation of the software that is performed to
keep the system operational and updated.
Most of the maintenance effort is used for non-corrective actions like
functionality enhancements or inclusion of newer technologies.
The maintenance activities can be categorized into four classes:
 Adaptive – dealing with changes and adapting in the software
environment.
 Perfective – accommodating with new or changed user requirements
which concern functional enhancements to the software.
 Corrective – dealing with errors found and fixing it.
 Preventive – concerns activities aiming on increasing software
maintainability and prevent problems in the future.
It may happen that the software may fail after development. A software
product wears out due to age. In software, bugs or errors may get introduced
during the design and development process which may go undetected during
the Testing phase. In such cases, software may fail after operating correctly for
some time. Such errors need to be removed.
So as not to encounter such problems in the future it is necessary to visit
the organization frequently to check whether the system is maintained
properly and is error free.
There is less probability of such problems as the system is developed by
considering the requirements and detailed study of the system. If any problem
arises the problem can be reported by the user and by visiting the place and
making changes will keep the software maintained.
73
CHAPTER 10: TOOLS FOR

DEVELOPING SYSTEM
74
VISUAL STUDIO 2010:
It includes new modeling tools, such as the Architecture Explorer, which

graphically displays projects and classes and the relationships between them.
It supports UML activity diagram, component diagram, (logical) class
diagram, sequence diagram, and use case diagram. Visual Studio Ultimate
2010 also includes Test Impact Analysis which provides hints on which test
cases are impacted by modifications to the source code, without actually
running the test cases. This speeds up testing by avoiding running unnecessary
test cases.
It also provides easy drag and drop facility to design GUI. We can select .NET
framework for our project.
I have used C# language and .NET Framework for development.
I have designed front end using this.
75
MICROSOFT SQL SERVER:
Microsoft’s SQL server provides facility to create and maintain

Databases. I have used the SQL Server as I wanted to create a ‘Client-Server’
application.
To manipulate the data in database I used ‘SQL Server Management

Studio’ which is freely available on the internet.
I have used it as a back end.
76
CHAPTER 11: SCREENSHOT
Home Page:
77
About Us:
Contact Us:
78
Sign Up:
User
79
Login:
Change Password:
User Home Page:
80
Appointment booking:
81
Payment:
Success Message Page:
82
Reciept:
83
Test List:
84
FeedBack Form:
85
Admin
Login:
Operation:
86
Appointment Details:
Send Reports:
87
Send Notification:
See FeedBack:
88
89
CHAPTER 12: USER

MANUAL
Online Diagnostic Lab Reporting System.
At User System.
This is a home page of the system, which have descriptive information

about system. From there the patient can get into the system by clicking
90
the UserLogin Link given above rightmost. But before login the user must
need to register them first. To register click on Register link.
Registration
The entire fields are mandatory. You need to fill all the required details
correctly. If any field is incorrect then system will prompt you error
message of missing field, password not match, email id is invalid specifies
your gender etc. as follows.
Once you completed your registration, you can login as authorized user.
Login:
91
At the time of login you need to enter your user name and password to get
access of your account. If the password or user name enter by you was
incorrect then system will notify you and ask to fill the correct details.
Once you done with your login now you will be able to book your test.
Book a Test.
92
To book a test you need to enter your correct email address, and select the
appropriate test from the test list and to view the cost of particular test
click on view button. If your email or you haven’t selected your test the
system will prompt you error message as follows.
Once you done with your book a test now make your appointment.
Appointment
93
Now make your appointment here. Entire fields are required. Enter your
date in correct format and choose your sample collection place. If any
error occurred then system will notify you.
Now make your transaction.
Make Transaction.
94
To view your previous details enter your email id and hit the view button.
On other hand you need to select your payment mode as follows.
Once you fill all the details correctly the system accepts your transaction
and informs you as.
95
Now you can logout. The system will send an confirmation message to your email
address.
96
CHAPTER 13: COST AND

BENEFIT ANALYSIS
97
13.1 COST ANALYSIS:

The cost of a project is a function of many parameters. Foremost among
them is the size of the project. Other factors that affect the cost are
programmer ability, experience of the developers in the area, complexity of
the project, and reliability requirements. It is also due to the requirements of
software, hardware and human resources.
LOC is beneficial in many ways as follows:

 It is an easy method to measure effort.
 The alternative methods to the counting of LOC are also fighting with
problems and weaknesses.
 In spite of its unreliability for individual programs, it gives reliable
average results, which is crucial especially for huge projects.
13.2 PROJECT COST USING ‘COCOMO’:

The Constructive Cost Model (COCOMO) is an algorithmic software cost
estimation model developed by Barry W. Boehm. The model uses a basic
regression formula with parameters that are derived from historical project
data and current project characteristics.
COCOMO was first published in Boehm's 1981 book Software Engineering
Economics as a model for estimating effort, cost, and schedule for software
projects. It drew on a study of 63 projects at TRW Aerospace where Boehm
was Director of Software Research and Technology.
The study examined projects ranging in size from 2,000 to 100,000 lines
of code, and programming languages ranging from assembly to PL/I. These
projects were based on the waterfall model of software development which
was the prevalent software development process in 1981.
13.2.1 INTERMEDIATE COCOMO:

It computes software development effort as function of program size and a
set of "cost drivers" that include subjective assessment of product, hardware,
personnel and project attributes. This extension considers a set of four "cost
drivers" as shown in table.
98
Cost Drivers Very Low Nominal High Very high Extreme

low High
Product
Attribute
Required s/w 0.75 0.88 1.00 1.15 1.40
reliability
Size of 0.94 1.00 1.08 1.16
application
Database
Product 0.74 0.85 1.00 1.15 1.30 1.65
Complexity
Hardware
Attribute
Execution 1.00 1.11 1.30 1.66
Time
Constraints
Main Storage 1.00 1.06 1.21 1.56
Constraint
Virtual 0.87 1.00 1.15 1.30
Machine
Volatility
Personnel
Attribute
Computer 0.87 1.00 1.07 1.15
turnaround
time
Analyst 1.46 1.19 1.00 0.86 0.71
capability
Application 1.29 1.13 1.00 0.91 0.82
Experience
Programmer 1.42 1.17 1.00 0.86 0.70
Capability
Virtual 1.21 1.10 1.00 0.90
Machine
experience
Language 1.41 1.07 1.00 0.95
experience
Project
attribute
Application of 1.24 1.10 1.00 0.91 0.82
software
engineering
Methods
Use of 1.24 1.10 1.00 0.91 0.83
Software Tools
Required 1.23 1.08 1.00 1.04 1.10
development
schedule
Fig 13.2.1 Intermediate COCOMO
99
The Intermediate COCOMO formula now takes the form:

Where E is the effort applied in person-months, KLoC is the estimated number
of thousands of delivered lines of code for the project.
Software project ai bi
Organic 3.2 1.05
Semi-detached 3.0 1.12
Embedded 2.8 1.20
13.2.2 ADVANTAGES OF INTERMEDIATE COCOMO:

The Intermediate COCOMO model can be applied to almost entire software
project for easy and rough implementation during early stages. It can also be
applied at the software component level for obtaining more accurate cost
estimation.
13.2.3 DISADVANTAGES OF INTERMEDIATE COCOMO:

A Product with many components is difficult to estimate with
Intermediate COCOMO and secondly the effort multipliers are not
dependent on phase.
13.2.4 CALCULATION:
Calculating EAF from the table gives:

EAF=1.00*0.94*1.00*1.11*1.00*0.87*1.07*1.00*0.91*0.86*0.90*1.00*0.91
*1.00*1.00
Considering the Project as Organic,
‘ai= 3.2’, ‘bi =1.05’, ‘c = 2.5’ AND ‘d = 0.38’
KLOC=3.26 approx.
Using these values Effort Applied can be calculated as,

E = 3.2*0.56(3.26)^1.05 = 6.1974
Development Time (D) = c (Effort Applied)d [months]

D = 2.5(6.1974)^ 0.38 = 5.000
People required (P) = Effort Applied / Development Time [count]

P = 6.5786/5.00 = 1.639 ~ 2
Independent costs = 30000 (approx)

Infrastructure costs = 1500 (approx)
Total Cost of project = Infrastructure costs * People Required (P) +

Miscellaneous independent costs
100
Therefore,
Total cost of project = 1500 X 2 + 30000 = Rs.33,000.
13.3 BENEFIT ANALYSIS:

Benefit analysis implies the estimation of the benefit achieved through the
project in monitory terms. Profit earned by selling the product is the main
source of earning monetary benefit. The selling cost is decided by dividing the
development cost, by the value of estimated customer count, which is based on
various factors like type of project, its Usefulness-affordability ratio etc.
As the project is developed considering particular target, profit earning is
less. The Development cost can be earned by selling the project to minimum
of 5-6 small business. This is not easy to achieve as the project is not
generalized.
101
CHAPTER 14:
LIMITATIONS
102
13.1 Limitation Of This Project:
 The users can only register themselves.

 To work on this website, computer should be connected to Local Area
Network (LAN).
 The user must require basic training of using the system (website).
103
CONCLUSION
104
Conclusion:
This Web Application provides facility to book a test online.
It saves or reduces work of Operator as well as Patients and makes the
Diagnostic system more secure.
Operator has a privilege to create, modify and delete the test list, Appointment
details, and its Staff details.
Patients can login and can book the test with his specific id.
As the Application has a GUI format, it is user friendly too.
105
ANNEXURE
Diagram List:
Diagram no Name Page no

1.5.1 Proposed architecture 8
5.7.1.2 Patient 22
5.7.1.3 Test 22
5.7.1.4 Book a test 23
5.7.1.5 Operator 23
5.7.1.6 Reports 24
5.7.1.7 Appointment 24
5.7.1.8 Laboratory 25
5.7.1.9 Notification 25
5.7.1.10 Payment 26
5.7.1.11 ER diagram 27
5.7.2.2 0 level DFD 29
5.7.2.3 First level DFD 30
5.7.2.4 Second level for login 31
5.7.2.5 Second level for Test 31
5.7.2.6 Second level for transaction 32
5.7.2.7 Second level for report 32
5.7.3.2 Use Case 34
5.7.4.2 Sequence for login 40
5.7.4.3 Sequence for check status 40
5.7.4.4 Sequence for perform 41
operation
5.7.4.5 Sequence for verifies the user 41
details
5.7.4.6 Sequence for make report 42
5.7.4.7 Sequence for send report 43
5.7.4.8 Sequence for logout 44
5.7.4.9 Registration 44
5.7.4.10 Login 45
5.7.4.11 Check for test availability 45
5.7.4.12 Book a test 46
5.7.4.14 Make payment 47
5.7.4.15 Check report 47
5.7.4.16 Logout 48
5.7.5.2 Activity Diagram 50
5.7.6.2 State machine Diagram 52
5.7.7.1 Schema Diagram 53
6.2 Gantt Chart 59
7.1 Incremental Model 61
106
Table List:
Table no Name Page no

5.7.1.1 ER Notation 21
5.7.2.1 DFD Notation 28
5.7.3.1 Use Case Notation 33
5.7.5.1 Activity Notation 39
5.7.6.1 State Machine Notation 51
5.7.8.1 Registration 54
5.7.8.2 Test 54
5.7.8.3 Operator 54
5.7.8.4 Send notification 54
5.7.8.5 Book a Test 55
5.7.8.6 Laboratory 55
5.7.8.8 Report 56
5.7.8.9 Payment 56
6.1 Project Plan 58
8.4 Test Case 66
13.2.1 Intermediate COCOMO 87
107
BIBLIOGRAPHY
Text-Book References:
Software Engineering, “Ian Somerville”, 8th edition, Pearson Education.
Software project management by Walker Royse
Object Oriented Modeling and Design with UML| Michael Blaha & James
Rumbaugh | Prentice
Hall of India | 2nd Edition
Software Testing Foundations: A Study Guide for the Certified Tester Exam By
Andreas Spillner, Tilo Linz, Hans Schaefer.
SQL: THE COMPLETE Reference, Second Edition by James R. Groff and Paul
N. Weinberg
Murach’s ASP.NET 4 Web Programming with C# 2010
Web References
 www.W3schools.com
 www.TutorialPoint.com
 http://stackoverflow.com/
 http://www.msdotnet.co.in/2013/07/how-to-send-mail-from-aspnet-
application.html#VvraWV2t-09
 http://www.c-sharpcorner.com/uploadFile/051e29/session-and-application-in-ASP-
NET/
 http://www.c-sharpcorner.com/upload-images-and -save-the-images-into-
database-using/
 http://www.codeproject.com/Question/212636/insert-only-character-in-text-box-
not-number/ www.nevonProject.com
108
109

DND Documentation Final

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DND Documentation Final

Uploaded by

Copyright:

Available Formats

ONLINE DIGNOSTIC LAB REPOTING SYSTEM

Vivekanand Education Society’s

“ONLINE DIAGNOSTIC LAB REPORTING SYSTEM”

(Web Technology & Web Project Development

This Mini Project duly signed in this Documentation represents the

Digvijay Jaiswar (20)

For SEMESTER - III of Second Year of the Master in Computer

Lecturer In-Charge Head, Department of ICA

Lab In-charge External Examiner

1.1 TITLE: “ONLINE DIAGNOSTIC LAB REPORTING

1.2 Statement about the problem

1.3 Why this topic

1.4 Objective and scope

1.5 Proposed architecture

Fig 1.5.1 Proposed Architecture

1.8 TESTING TECHNOLOGY:

2.1 Introduction of project

2.2 Existing System

2.2.1 Disadvantage of existing System

2.3 Proposed System

2.3.1 Advantages of Proposed System:

2) Allows for faster services.

3) Allow increased sales and profits for diagnostic lab.

4.1 DEFINING A PROBLEM:

The following limitations were found out in the existing system:

The proposed system will overcome all problems mentioned above:

5.2 RISK ANALSIS:

5.3 PROPOSED SYSTEM STUDY:

This step basically deals with the following different operations:

5.3.1 TOOLS AND TECHNIQUES USED FOR INFORMATION

 Who is responsible for the system?

5.4 SYSTEM REQUIREMENT

Output: Patients can select the Test.

Destination: Patient who are interested to book the test order.

Requires: access to the website i.e. registered user

Pre-condition: patients must be signed in through their proper ID.

Post-condition: Patients successfully passes through payment process.

5.5 User Requirement

5.5.1 Functional requirement:

5.3.2 Non Functional requirement

5.6 Feasibility Study

The different types of feasibility are as follows:

 Economic feasibility study: Economic Feasibility study is most required to

5.7.1 E-R Diagram

Rectangle represents entity sets.

Ellipse represents attributes.

Diamond represents relationships.

It Represents one to one relationship.

It represents one to many relationships.

It represents many to one relationship.

It represents many to many

Fig 5.7.1.1 Notations

Entities used in my system:

Fig 5.7.1.2 Patients

Fig 5.7.1.3 Test

Fig 5.7.1.4 Book a test

Fig 5.7.1.6 Reports

Appo_Time Patient detail

Fig 5.7.1.8 Laboratory

Fig 5.7.1.9 Notification

Fig 5.7.1.10 Payment

Patients Book Book a Test

Fig 5.7.1.11 ER Diagram

5.7.2 DATA FLOW DIAGRAM