A PROJECT REPORT

ON

“MEDICAL SHOP MANAGEMENT SYSTEM”

FOR

“SRM MEDICO & PHARMA”

BY

SANTOSH RAJENDRA MORE (EXAM SEAT NO :)

SAVITRIBAI PHULE PUNE UNIVERSITY.

MASTER OF COMPUTER APPLICATION

(MCA)

Dr D Y Patil Educational Enterprises Charitable

Trust’s

Dr. D. Y. Patil School of MCA

Dr DY Patil Knowledge City, Charholi (Bk.), Via

Lohegaon, Pune – 412105

(A.Y. 2020-2022)

2021- 2022

UNDER THE GUIDANCE OF

Prof. Sapna Chavan

 CERTIFICATE OF ORIGINALITY

Date:-

This is to certify that the project entitled “MEDICAL SHOP MANAGEMENT

SYSTEM” Submitted to the Department of MCA, Dr.D.Y.Patil School Of MCA Pune

in partial fulfillment of the requirement for the award of the degree of MASTER OF

COMPUTER APPLICATIONS (MCA Affiliated to Savitribai Phule Pune University),

is an original work carried out by Exam Seat No: . Under my guidance. The matter

embodied in this project is a genuine work done by the student and has not been

submitted whether to this Organization or to any other University/Organization for the

fulfillment of the requirement of any course of study.

Signature of the Internal Guide Signature of the Student

Prof. Sapna Chavan Mr. Santosh More

Signature of the Head

MCA Prof.Ashok

Deokar
 CERTIFICATE

This is to certify that the project report entitle “MEDICAL SHOP MANAGEMENT

SYSTEM” Submitted to the Department of Computer Application,Dr.D.Y.Patil School

Of MCA Pune in partial fulfillment of the requirement for the award of the Degree of

MASTER OF COMPUTER APPLICATIONS (MCA affiliated to Savitribai Phule

Pune University) Exam Seat No:. The matter embodied in this project is a genuine

work done by the student and has been Certified by the following external examiners

deputed by Savitribai Phule Pune University.

External Examiner-1 External Examiner-2

 Acknowledgement

I would like to take this opportunity to express sincerely gratitude to our project guide

Prof. Sapna Chavan who helped me in successful completion of this project. I am

highly indebted to their active participation bringing out vitally important suggestion

all very through the cause of the project. Their extreme patience despite a very hectic

schedule and a character lucid style of explaining concept are very inspiring.

I’m very grateful to project guide and HOD who extended to me generally all helps,

support and achieve assistance during the period of my project.

I also express thanks to all staff member who had directly and indirectly helped me in

completion of the project.

Sr.No Content Page No.
Title& Technology
Company Profile/Institute Profile/Client Profile
Abstract
Existing System and Need for System
1 Scope of System
Operating Environment-Hardware and Software
Brief Description of Technology Used
Operating systems used(Windows or Unix)
1.6.2 RDBMS/No Sql used to build database (MySQL/ oracle, Tera data,etc.)
Proposed System
Study of Similar Systems (If required research paper can be included)
2 Feasibility Study
Objectives of Proposed System
2.4 Users of System
Analysis and Design-I
System Requirements(Functional and Non-Functional requirements)
3 Entity Relationship Diagram(ERD)
Table Structure
Use Case Diagrams
3.5 Class Diagram
Analysis and Design–II
Activity Diagram
4 Deployment Diagram
Module Hierarchy Diagram
Sample Input and Output Screens(Screens must have valid data. All reports must have at-
least 5 valid records.)
Coding
5 Algorithm
Code snippets
Testing
Test Strategy
6 Unit Test Plan
Acceptance Test Plan
Test Case/Test Script
Defect report/Test Log
7 Limitations of Proposed System
8 Proposed Enhancements
9 Conclusion
10 Bibliography
11 Publication/Competition certificates
12 Appendix –Cost sheet, Datasheet
13 User Manual(All screens with proper description/purpose Details about
Validations related to data to be entered.)
14 Internal Project Presentation,
Final Report Submission in Soft Copy along with Executables
Abstract

The “Medical Shop Management System” is the Windows based web application. This
application can be used for managing Medical Shops Center related data and their customers.

The Medical Shop Management System is designed for Manage Medical Shops to

replace their existing manual, paper-based system. The new system is to control the

following information, Customer information, Staff information, Job card information,

Owner information, Payment details, Product availability and details. These services

are to be provided in an efficient, cost-effective manner, with the goal of reducing the

time and resources currently required for such tasks..

 Existing System:

Existing system is a manual one in which users are maintaining books to store the information
like product details, customers details, products, service details and accounts for every month.
It
is very difficult to maintain historical data.

The following are the disadvantages of the existing system

 It is difficult to maintain important information in books.

 More manual hours need to generate required reports.

 It is tedious to manage historical data which needs much space to keep all

the Previous years’ ledgers, books etc.

Scope of System

Now a day, technology is on a boost. People wish to live a luxurious life with minimum
physical work. Here we provide a web application for “Medical Shop Management System”.
TAnother register like stock in this stock the other item is also include are systematically
maintain. The all document and the all difference report are prepared perfect. There is
security some password facility for opening the system’s work. This software stores detail of
medicine purchase stock and sell stock. Modules are as following: - Registration of
Clerk, Add Customer, Add Supplier, Add Stock, Purchase, Sales, Login, Return Product,
Prescription, Bill Generation and View Reports
 OPERATING ENVIRONMENT
– HARDWARE AND SOFTWARE

SOFTWARE REQUIREMENTS:

Software requirements for this system areas listed follows:-

 Front-End : Java

 Backend : MySQL8.0.26

 Middleware : Apache Tomcat

 Operating System : Windows 7 & above

 IDE Used: Apache Tomcat, Eclipse, MySQL Workbench 8.0.

HARDWARE REQUIREMENTS:

For PC and Laptop:

 i3 processoror above

 4GB RAM or higher

 250 ROM or higher

Brief Description of Technology Used

Operating System Used:

We have used Windows10 for developing the web application

RDBMS/NoSQL used to build database:

We have used to used MySQL for storing the data

 Objectives of Proposed System
 To store Supplier, Customer, Staff Person and Stock information.
 Easy to use and user friendly.
 To reduce Paperwork.
 To save Time.
 To maintain easy circulation system using computers.
User Requirement -:
User requirements are categorized by the shopkeeper
Data Entry:
 Ø Add Supplier to the system
 Ø Add Customer to the system
 Ø Add Stock to the system
Ø View Reports

The proposed working system will be simple, yet suitably Effectives user friendly interface,
solve profiles personnel’s Manual system. The admin of the system will have to login him first.
After login himself he can perform various functionalities such as he can log on to the system .
The system has two Users admin and Staff Person. The proposed system automates all the
activities of these two users.
 Login: -The one admin has a login. They will have to login into the system using the
correct username and password.
The proposed system will be simple, yet suitable effective user-friendly interface.
 Add Supplier: In this, Admin to add supplier details.
 Add Customer: In this, Admin to add Customer details.
 Add Staff Person: In this, Admin to add Staff Person details.
 Add Stock: In this, Admin to add Stock details.
The sys-tem should introduce a paperless environment in the organization by cov-ering end-to-
end
activities in the tendering process and yet provide enough control over planning and management
of different tendering activities.
 Feasibility Study:

Feasibility study is conducted once the problem is clearly understood. Feasibility

study is a high-level capsule version of the entire system analysis and design process.

The objective is to determine quickly at a minimum expense how to solve a problem.

The purpose of feasibility is not to solve the problem but to determine if the problem is

worth solving. The system has been tested for feasibility in the following points.

1. Technical Feasibility

2. Economical Feasibility

3. Operational Feasibility.

1. Technical Feasibility

The project entitles "Medical Shop Management System” is technically

feasibility because of the below mentioned feature. The project was developed in java

which is used for developing Graphical User Interface. The project had middleware

apache tomcat server which is capable of connections. It provides the high level of

reliability, availability, and compatibility. All these makes java an appropriate language

for this project. Thus, the proposed software is build using powerful language.
2. Economical Feasibility

The computerized system will help in automate the selection leading the profits

and details of the organization. With this software, the machine and manpower

utilization are expected to go up by 80-90% approximately. The costs incurred of not

creating the system are set to be great, because precious time can be wanted by

manually.

3. Operational Feasibility

The proposed system will provide best services for customers and user, and it

will be highly secure. The system will also be on behalf of origination’s goal and user

satisfaction because the system will be possible to run and use in the organizations.

The system gives better user interface and storage of user information, easy updating,

deletion, and modification etc.

 Objective of Proposed System

Objectives of Proposed System

 To store Supplier, Customer, Staff Person and Stock information.

 Easy to use and user friendly.

 To reduce Paperwork.

 To save Time.

 To maintain easy circulation system using computers.

3. User Requirement -:

User requirements are categorized by the shopkeeper

Data Entry:

 Ø Add Supplier to the system

 Ø Add Customer to the system

 Ø Add Stock to the system

 Ø View Reports

Purchase:

 Add Purchase details

 View Reports

 If Good are Defective Or Expire Then Return it

Sales:

 Add Sales details

 Generate Invoice

 Sales Reports

 Give the sales bill to customer

Customer:

 Ø Add Customer details

 Ø Add Prescription details

 Ø View customer reports

 Ø Sales details

 Ø Pay the bill of medicine

 Users of System

The Medical Shop Management System is used by any executive or person who want to

Purchase Medicines. The Proposed System is also used by Medical staff for maintaining the records of

Customers & Medicines.

Admin(owner) :

Admin has to first register by putting the basic details. He can add & delete executive details . Admin

also check bills & check products.

Executive Staff :

Staff can first login the page. Staff also can check status, check bills, the prouct details of the Medicines

and staff also updates status of Stocks and billing status.

Customer :

Customer first register their details, after successfully registration then the customer fill Personal detail

after that they fill job card in the end the system will generate invoice for the customer.
 Analysis and Design– I

System Requirement

Functional Requirement

Functional Requirement are as follows:

1) Interoperability:

This software system is interoperable across different systems. Web site can

be viewed in any operating system like Windows, Linux, and Android etc. Web

application allows Google sign up.

2) Security:

The user data is secure with our implemented database. The owner

and staff executives password are encrypted which maintains privacy.

3) Accuracy:

When the Executives completed Medicines Status, the status of the Medicines

is completed and no variation in the accuracy is accepted.

4) Compliance:

This website follows the cyber security guidelines and comply with the

WorldWideWeb in terms of accessibility.

Non-Functional Requirement

The non-functional requirements are as follows:

Security:
 Each member is required to have an individual password

 Administrators have the option of increasing the level of password security

their members must use.

 For maximum security, each member must protect their password.

Reliability:

 System will prompt the user if any incorrect input is made.

 To handle data consistency, DBMS software is used.

 User can easily work through the different menus and buttons.

Maintainability:

 Proper documentation is available for further upgradation and maintenance.

 User will be trained enough to handle the minor changes required.

Availability:

 The system shall be available all the time i.e., 24*7*365.

 Portability:

 System is independent of hardware specification.

 It can run on any operating system

 System is independent of browser compatibility because web pages will be designed

by java.

Performance:

 The performance of our product is at its best if stored locally, as the response time

will be much faster.

 If the product accessed via Internet, the performance is limited by the connection speed.

 The only foreseen limitation is that of web server response.

User Friendly:

 Our system is very easy to use and user friendly. Its GUI is very attractive

and understand able to the common users.

Entity Relationship Diagram(ERD):
Class Diagram
Use Case Diagram
Admin & User:-
Use Case Diagram:
Admin & Supplier
Activity Diagram:
Sequence Diagram:
USER INTERFACE DESIGN:-

Login(Admin):-
Registration:-
Login(Cleark):-
Add Supplier:-
View Supplier:-
Add Customer:-
View Customer:-
Add Stock:-
View Stock:-
View Customer:-
Purchase Details:-
Sales Detail:-
Generate Invoice:-
 TABLE SPECIFICATION:-

1.Supplier:-
Sr. Field Name Key Description
No Datatype
1 Supplier_id Int P. K Store supplier
id
2 Supplierame Varchar20 Not Store supplier
Null name
3 Supplier_Address Varchar20 Not Store supplier
Null address
4 Supplier_Mobile No Int Not Store supplier mobile
Null number
5 Supplier_Company_Product Varchar20 Not Store supplier company
Null product
6 Supplier_Discription Varchar20 Not Store supplier
Null discerption

2.Purchase:-
Sr. Field Name Datatype Key Description
No
1 Po. No Int P. K Store Purchase Order
number
2 Pur_Medicien Varchar20 Not Store purchase number
Null
3 Stock_id Int F. K Include Stock Table
3.Genrate Invoice:-
Sr. No Field Name Datatype Key Description
1 Bill_id Int P. K Store bill id
2 Sales_id Int F. K Store sales id

4.Add Stock:-

Sr. No Field Name Datatype Key Remark

1 Stock_id Int P. K Store stock id
2 Stock_Name Varchar20 Not Null store stock name
3 Stock_Quantity Varchar20 Not Null Store stock quantity
4 Stock_Type Varchar20 Not Null store stock type
5 Stock_Unit Int Not Null Store stock unit
6 Product_Mfg Date Not Null Store product MFG
7 Return Good Varchar20 Not Null Store return goods
8 Purches_Rate Int Not Null Store purchase rate
9 Pur_Discount Int Not Null Store pur_discount
10 Pur_GST Int Not Null Store purchase GST
11 Pur_Rate Int Not Null Store purchase rate
12 Sales_Rate Int Not Null Store Sales rate
13 Sal_Discount Int Not Null Store Seles discount
14 Sal_GST Int Not Null store sale GST
15 MRP Int Not Null store MRP
16 Sal_Final_rate Int Not Null Store final sales
product rate
5.Prescription -:
Sr. No Field Name Datatype Key Description

1 Pre_id Int P. K store Prescription id

2 Cust_id Int F. K Customer

3 Pre_MedicienName Varchar20 Not Null Medicine Name

6.Add Customer:-
Sr.no Field Name Datatype Key Descriprition

1 Cust_id Int P. K Store customer id

2 Cust_Name Varchar20 Not Null Store Customer Name

3 Cust_age Int Not Null Store Customer Age

4 Cust_Addr Varchar20 Not Null Store Customer Address

5 Cust_Contact Int Not Null Customer Mobile Number

6 Stock_id Int F. K Store stock id

7 Pre_id Int F. K Store Prescription id

 7.Sales:-
Sr. No Field Name Datatype Key Description

1 Sales_id Int P. K Store customer id

2 Cust_Id Int F. K Customer

3 Stock_id Int F. K Stock

4 Sale_medicien Varchar20 Not Null Medicine Detail

8) Return Goods Header -:

Sr. No Field Name Datatype Key Description

1 Return_id Int P. K Store return good id

2 Stock_id Int F. K Store stock id

3 Supplier_id Int F. K Store supplier id

 9.Registration:-
Sr. No Field Name Datatype Key Description
1 Name Varchar2(MAX) Not Null Store Clerk Name
2 Mobile_Number Int Not Null Store Contact
Number
3 Gender Varchar2(20) Not Null Store
Male/Female
4 Email_id Varchar2(20) P. K Login with Email
5 Password Nchar Not Null Password

10.returns And Goods:-

Sr. No Field Name Datatype Key Description

1 R_Id Int P. K Store return good
id
2 S_Id Int F. K Store stock id
3 Su_Id Int F. K store supplier id
4 Quantity Nchar (10) Not Null Store product
quantity
5 Type Varchar (50) Not Null store product type
6 Method Varchar (50) Not Null store method
7 Reason Varchar (50) Not Null store return
product reason
8 Amount Nchar (10) Not Null store return
product Amount
 11.Purchase Header:-

Sr. No Field Name Datatype Key Description

1 P_Id Int P. K Store Purchase headerid
2 S_Id Int F. K Store Stock id

12.Sales header:-

Sr. No Field Name Datatype Key Description

1 Sales_Id Int P. K Primary Key
2 Cust_Id Int F. K Customer
3 Cust_Name Varchar (MAX) Not Null Store customer name
4 S_Id Int F. K Stock

13.Bill Header:-

Sr. No Field Name Datatype Key Description

1 B_Id Int P. K Store Primary Key
2 Cust_Id Int F. K Store Customer_id
3 S_Id Int F. K Store Stock_id
 14.Bill Master:-
Sr. No Field Name Datatype Key Remark

1 Invoice_Id Int P. K Primary Key

2 Date Date Not Null

3 TotalAmount Number Not Null

4 Cust_Name Varchar (MAX) F.K Customer

15.product:-
Sr. No Field Name Datatype Key Remark

1 product_Id Int P. K Primary Key

2 Product Nam Varchar(MAX) Not Null

3 Product Type Nchar Not Null

4 Product Int F.K Customer

Number
 Validations:-

Test Cases:-
Test case Test case name Test case Input Expected result Actual Test status case Test Test priority status
Id Description Result (Pass/Fail
)

1 Validate user Field not blank Leave blank Alert Alert msg Design P High
name ms “Enter valid field”
g “Enter valid field”

2 Validate Field not blank Leave blank Alert Alert msg Design P High
password ms “Enter valid field”
g “Enter valid field”

93 Login validation To verify Enter rect Redirect and Design P High

E.g. username and cor Control to
Enter password username and the respected login
username= password page
“admin” And click on
password=” button
admin”

Login:-
Test Case Add Supplier:-

Test case Test case name Test case Expected result Test case Test Test
Id Input Actual status priority status
Description Result (Pass/Fail
)
1 Validate Field not Leave blank Alert Alertmsg P High
user name blank ms Design
g “Enter valid “Enter
field” valid
field”
2 Validate Fieldnot Leave blank Alert Alertmsg P High
password blank ms Design
g “Enter valid “Enter
field” valid
field”
93 Login To Enter rect Design P High
validation
E.g. verify cor Redirect
Enter username username and
username= and password Control to
“admin” password click on and the
And button respected
password=” login page
admin”
Add Customer:-

Test Test Test Case Input Expected Actual Result Test Case Test
Case Case Id Description Result Test Priority Status
Name Status(Pass
1 / Fail)

Customer Valid not Leav Msg Msg Design P High

Name Blank e “Enter “Enter
blank Customer Customer
Name” Name”
2 Customer Valid not Leav Msg Msg Design P High
Age Blank e “Enter “Enter
blank Customer Customer
Age” Age”
3 Customer Valid Not Leav Msg Msg Design P High
Address Blank e “Enter “Enter
blank Customer Customer
Address” Address”

4 Medicine Valid Not Leav Msg Msg Design P High

Name Blank e “Enter “Enter
blank Medicine Medicine
Name” Name”
5 Quantity Valid not Leav Msg Msg Design P High
Blank e “Enter “Enter
blank Quantity” Quantity
”
Registration Of User:-
 Validation Screen:-
1) Registration of User (Required Filed Validation):-
2) Registration of User (Regular Expression):-
3) Add Stock (Required Field V alidation):-
4) Registration of User (Compare Validation)
Reports Presentation:-

A)Sales:-
B) Stocks:-
C) Customer:-
D) Purchase:-
E) Supplier:-
F) Prescription:-
Returns Goods:-
Prescriptions: -
Stock Report by Date -: (31-03-2019 To 26-02-2022):-
Stock Report by Date -: (If Invalid Date):-
Coding:
4.1 Algorithm

The word Algorithm means a procedure for solving a mathematical problem in a finite number of
steps that frequently by recursive operations .

Therefore , Algorithm refers to a sequence of finite steps to solve a particular problem.

Algorithms can be simple and complex depending on what you want to achieve.

The Algorithm designed are language-independent, i.e. they are just plain instructions that can be
implemented in any language, and yet the output will be the same, as expected.

Not all written instructions for programming is an algorithms. In order for some instructions to be
an algorithm, it must have the following characteristics:

Clear and Unambiguous: The algorithm should be clear and unambiguous. Each of its steps should
be clear in all aspects and must lead to only one meaning.

Well-Defined Inputs: If an algorithm says to take inputs, it should be well-defined inputs.

Well-Defined Outputs: The algorithm must clearly define what output will be yielded and it
should be well-defined as well.

Finite-ness: The algorithm must be finite, i.e. it should terminate after a finite time.

Feasible: The algorithm must be simple, generic, and practical, such that it can be executed with
the available resources. It must not contain some future technology or anything.

Language Independent: The Algorithm designed must be language-independent, i.e. it must be just
plain instructions that can be implemented in any language, and yet the output will be the same, as
expected.
 4.2 Coding Snippet

<html>
<head>
<link rel="stylesheet" type="text/css" href="style.css">
<style>
article
{
margin-left:1000px;
border-left:1px solid black;
overflow:hidden;
paading:1em;

}
input[type=button]
{
background-color: #4CAF50;
color: white;
padding: 15px 32px;
border: none;
cursor: pointer;
opacity: 1;
}
input[type=button]:hover
{
opacity: 0.91;
background-color:yellow;
color:blue;
}

</style>
<script language="javascript">
function loginex()
{

window.open("login.jsp","_self");

}
function ownerlogin()
{
window.open("ownerlogin.jsp","_self");
}
function registration()
{
window.open("registration.jsp","_self");
}

</script>
</head>

<header><center><h1>Online Vehicle Servicing<h1></center><table border=0 style="float:right;">

</header>
</header>
</table>

<body background="https://images.unsplash.com/photo-1530046614490-89e6f776b83b?ixlib=rb-
1.2.1&ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&auto=format&fit=crop&w=1470&q=80" >
<div align="center">
<br>
<br>
<br>
<br>
<br>
 <br><br>
<br>
<br>

<input type=button onclick='registration()' value="Registration " name="registration"

id="registration"><br>
<br>
<br>
<br>
<input type=button onclick='loginex()' value="Executive login" name="loginex" id="login"><br>
<br><br>
<br>

<input type=button onclick='ownerlogin()' value="Owner login" name="loginow" id="login">

<div>
</body>

</html>
 Testing

5.1 Test Strategy

1. Unit Testing

Unit testing concentrates verification on the smallest element of the program – the module.

Using the detailed design description important control paths are tested to establish errors within

the bounds of the module.

In this system each sub module is tested individually as per the unit testing such as

campaign, lead, contact etc are tested individually. Their input field validations are tested.

2. Integration testing

Once all the individual units have been tested there is a need to test how they were put

together to ensure no data is lost across interface, one module should not have an adverse impact

on another, and a function must perform correctly.

After unit testing each sub module is tested by integrating with each other.
System testing for the current system:

In this level of testing, we are testing the system after integrating all the main modules of the

project. We are testing whether system is giving correct output or not. All the modules were

integrated and the flow of information among different modules was checked. It was also checked

that whether the flow of data is as per the requirements or not. It was also checked that whether

any module is non-functioning or not i.e., once the integration is over each module is functioning

in its entirety or not.

In this level of testing, we tested the following: -

 Whether all the forms are properly working or not.

 Whether all the forms are properly linked or not.

 Whether all the images are properly displayed or not.

 Whether data retrieval is proper or not.

 5.2 Unit test plan

A general unit test plan should be prepared. It may be prepared as a component of the master test

plan or as a stand-alone plan. It should be developed in conjunction with the master test plan and

the project plan for each project. Documents that provide inputs for the unit test plan are the

project plan, as well the requirements, specification, and design documents that describe the target

units. Components of a unit test plan are described in detail the IEEE Standard for Software Unit

Testing. This standard is rich in information and is an excellent guide for the test planner. A brief

description of a set of development phases for unit test planning is found below. The phases allow

a steady evolution of the unit test plan as more information becomes available. Also note that a

unit test plan is developed to cover all the units within a software project; however, each unit will

have its own associated set of tests.

Phase 1: Describe Unit Test Approach and Risks

In this phase of unit testing planning the general approach to unit testing is outlined. The test

planner:

(i) identifies test risks.

(ii) describes techniques to be used for designing the test cases for the units.

(iii) describes techniques to be used for data validation and recording of test results.

(iv) describes the requirements for test harnesses and other software that interfaces with the units

to be tested, for example, any special objects needed for testing object- oriented units.

During this phase the planner also identifies completeness requirement what will

be covered by the unit test and to what degree (states, functionality, control, and data flow patterns).

The planner also identifies termination conditions for the unit tests. This includes coverage

requirements, and special cases. Special cases may result in abnormal termination of unit test (e.g.,

a major design flaw). Strategies for handling these special cases need to be documented. Finally, the

planner estimates resources needed for unit test, such as hardware, software, and staff, and develops

a tentative schedule under the constraints identified at that time.

Phase 2: Identify Unit Features to be Tested

This phase requires information from the unit specification and detailed design description.

The planner determines which features of each unit will be tested, for example: functions,

performance requirements, states, and state transitions, control structures, messages, and data flow

patterns. If some features will not be covered by the tests, they should be mentioned and the risks

of not testing them be assessed. Input/output characteristics associated with each unit should also

be identified, such as variables with an allowed ranges of values and performance at a certain

level.

Phase 3: Add Levels of Detail to the Plan

In this phase the planner refines the plan as produced in the previous two phases. The planner

adds new details to the approach, resource, and scheduling portions of the unit test plan. As an

example, existing test cases that can be reused for this project can be identified in this phase.

Unit availability and integration scheduling information should be included in the revised version

of the test plan. The planner must be sure to include a description of how test results will be

recorded. Test-related documents that will be required for this task, for example, test logs, and test

incident reports, should be described, and references to standards for these documents provided.

Any special tools required for the tests are also described. The next steps in unit testing consist of

designing the set of test cases, developing the auxiliary code needed for testing, executing the

tests, and recording and analysing the results.

5.3 Acceptance Testing

Acceptance tests are a very important milestone for the developers. At this time the clients will

determine if the software meets their requirements. Contractual obligations can be satisfied if the

client is satisfied with the software. Development organizations will often receive their final

payment when acceptance tests have been passed.

Acceptance tests must be rehearsed by the developers/testers. There should be no signs of

unprofessional behaviour or lack of preparation. Clients do not appreciate surprises. Clients should

be received in the development organization as respected guests. They should be provided with

documents and other material to help them participate in the acceptance testing process, and to

evaluate the results. After acceptance testing the client will point out to the developers which

requirement have/have not been satisfied. Some requirements may be deleted, modified, or added

due to changing needs. If the client has been involved in prototype evaluations, then the changes

may be less extensive. If the client is satisfied that the software is usable and reliable, and they

give their approval, then the next step is to install the system at the client ‘s site. If the client ‘s site

conditions are different from that of the developers, the developers must set up the system so that

it can interface with client software and hardware. Retesting may have to be done to ensure that

the software works as required.

 LIMITATIONS OF THE SYSTEM

Limitations of the system:

 Only the permanent user can access the system.

 System works in all platforms and its compatible environments.

 Advanced techniques are not used to check the authorization.

 As the technology emerges, it is possible to upgrade the system and can be adaptable to desired

environment.

 Based on the future security issues, security can be improved using emerging technologies.

 Owner & Executive Staff module can be added.

Future Enhancements:

It is not possible to develop a system that makes all the requirements of the user. User

requirements keep changing as the system is being used. Some of the future enhancements that can

be done to this system are:

 As the technology emerges, it is possible to upgrade the system and can be adaptable to

desired environment.

 Because it is based on object-oriented design, any further changes can be easily adaptable.

 Based on the future security issues, security can be improved using emerging technologies.

 Owner and Executive staff module can be added

 CONCLUSION

The “MEDIAL SHOP MANAGEMENT SYSTEM” was successfully designed and is tested for

accuracy and quality. During this project we have accomplished all the objectives and this project

meets the needs of the organization.

GOALS

 Reduced entry work.

 Easy retrieval of information.

 Reduced errors due to human intervention.

 User friendly screens to enter the data.

 Portable and flexible for further enhancement.

 Web enabled.

 Fast finding of information requested.

BIBILOGRAPHY

The “MEDICAL SHOP MANAGEMENT SYSTEM” was successfully designed and is tested for

accuracy and quality. During this project we have accomplished all the objectives and this project meets

the needs of the organization.

 Site References

 https://www.google.com/

 https://w3schools.com/

 https://tutorialspoint.com/

Websites -:

 https://www.tutorialspoint.com/asp.net/index.htm

 https://www.tutorialspoint.com/object_oriented_analysis_design/index.htm

 https://www.tutorialspoint.com/sql/index.htm

 https://www.tutorialspoint.com/uml/index.htm
 USER MANUAL

This user manual is meant to be used by the whole user using the system, with prior training

session from the Development unit, plus he/she must be skillful enough in operating the intended

system. This manual is used for the benefit of the intended user to make it more understandable

along with functioning of the system, the processes and the precautions that must be followed

during working with the system.

This System is very easy to operate to those who have the Fundamental knowledge of

computer operations & little bit of the help of this user manual. The appropriate error message &

supporting help makes this online web application easy to handle.

Now, to get a better understanding of the system various user interfaces along-with directions

are also provided in the user-interface designs.