Ambo Koo Chapter All DocPDF

AMBO UNIVERSITY
INSTITUTE OF TECHNOLOGY
DEPARTMENT OF COMPUTER SCIENCE
Title:-Web Based For Ambo Koo Pharmacy Management System

BY:
Name Id No
Usman Abdulaziz BRT/2174/08
Yusuf Abdela BRT/2176/08
Abrahim Umar BRT/2109/08
Dule Merga RIOT/1553/07
Dinka Tamru BRT/2210/08
Chaltu Tefari BRT/2199/08
Tsagenash Fikadu BRT/2321/08
Project Submitted To the Department of Computer Science of Ambo University for the Degree of
Bachelor of Science in Computer Science
ADVISOR: Mr. Haftom B June 2019
Ambo Ethiopia
AMBO UNIVERSITY
INSTITUTE OF TECHNOLOGY
DEPARTMENT OF COMPUTER SCIENCE
Title: - Web Based For Ambo Koo Pharmacy Management System
By
Name Signature ID No
Usman Abdulaziz ____________ ____________
Yusuf Abdela ____________ ____________
Abrahim Umar ____________ ____________
Dule Merga ____________ ____________
Dinka Tamru ____________ ____________
Chaltu Tefari ____________ ____________
Tsagenash Fikadu ____________ ____________
Name and Signature of Member of the Examining Board
Name Title Signature Date
____________ Coordinator, ____________ ____________
Mr. Haftom B Advisor, ____________ ____________
____________ Examine, ____________ ____________
____________ Examine ____________ ____________
AMBO KOO PHARMACY MANAGEMENT SYSTEM DEPARTMENT OF COMPUTER SCIENCE 2019
ii
Declaration
We declare this project is our original work and has not been presented for a degree in
any Other University
Name Signature Date

Usman Abdulaziz ____________ ____________
Yusuf Abdela ____________ ____________
Abrahim Umar ____________ ____________
Dule Merga ____________ ____________
Dinka Tamru ____________ ____________
Chaltu Tefari ____________ ____________
Tsagenash Fikadu ____________ ____________
This project has been submitted for examination with approval of our advisor
Name Signature Date
Mr. Haftom B ____________ ____________
Table of Contents
Declaration ..................................................................................................... iii
iii
Acknowledgment ........................................................................................... vi
List of Figures ............................................................................................... vii
List of Tables ............................................................................................... viii
Abbreviation ................................................................................................ viii
Abstraction .......................................................................................................x
Chapter 1 ..........................................................................................................1
1.1 Introduction .................................................................................................................... 1
1.2 Organizational Back ground ............................................................................................... 1
1.2.1 Vision of the organization ............................................................................................ 1
1.2.2 Mission of the organization .......................................................................................... 2
1.3 Background of the project................................................................................................... 2
1.4 Statement of the Problem .................................................................................................... 2
1.5 Objective of the project ....................................................................................................... 3
1.5.1 General objective .......................................................................................................... 3
1.5.2 Specific objective ........................................................................................................... 3
1.6 Scope of the project .............................................................................................................. 3
1.7 Significance of the project ................................................................................................... 4
1.7.1 Target Beneficiaries of the system ............................................................................... 4
1.8 Methodology for the project ............................................................................................... 4
1.8.1 Data Source.................................................................................................................... 5
1.8.2 Fact Finding Techniques .............................................................................................. 6
1.8.3 Systems Analysis and Design (approach).................................................................... 6
1.8.4 Development Tools ........................................................................................................ 7
1.8.5 Testing procedures ........................................................................................................ 7
1.8.6 Proposed Implementation Method .............................................................................. 9
1.9 Limitation of the project ................................................................................................... 10
1.10 Risks and Contingencies .................................................................................................. 10
1.11 Assumptions and Constraints ......................................................................................... 11
1.12 Schedule of the project (using Gantt chart)................................................................... 11
Chapter Two ..................................................................................................13
2 Description of the Existing System & the Proposed System .....................13
2.1 Introduction of Existing System ....................................................................................... 13
iv
2.1.1 Players in the existing system..................................................................................... 13
2.1.2 Functions/activities in the existing system ................................................................ 13
2.1.3 Business rules .............................................................................................................. 14
2.1.4 Report generated in the existing system.................................................................... 14
2.1.5 Forms and other documents of the existing systems ................................................ 14
2.1.6 Bottlenecks of the existing system.............................................................................. 16
2.2 Practices to be preserved from existing system ............................................................... 17
2.3 The Proposed System .......................................................................................................... 17
2.3.1 Team composition ....................................................................................................... 19
2.3.2 Feasibility Analysis ..................................................................................................... 20
2.4 Requirement of the Proposed System .............................................................................. 22
2.4.1 Functional requirement .............................................................................................. 22
2.4.2 Non -Functional requirement .................................................................................... 22
Chapter There ................................................................................................24
3. System Analysis and Modelling ................................................................24
3.1 Introduction ........................................................................................................................ 24
3.2 System Requirement Specifications (SRS) ...................................................................... 24
Chapter Four: .................................................................................................55
System Design ...............................................................................................55
4.1 Introduction..............................................................................................55
4.1.1 Purpose of the System ....................................................................................................... 55
4.1.2 Design Goals .............................................................................................................. 56
4.1.3 Definitions, acronyms, and Abbreviations ........................................................................ 56
4.1.4 Overview ........................................................................................................................... 56
4.2 Current System Architecture................................................................................................ 57
4.3 Proposed System Architecture ............................................................................................. 58
4.3.1 Subsystem decomposition ........................................................................................... 59
4.3.2 Hardware/Software mapping+ .................................................................................. 60
4.3.3 Persistent data management ...................................................................................... 61
4.3.4 Access control and Security ....................................................................................... 62
4.3.5 Global software control .............................................................................................. 64
4.3.6 Boundary conditions ................................................................................................... 64
4.4 Subsystem services .............................................................................................................. 65
v
Chapter Five: .................................................................................................66
Implementation and Testing ..........................................................................66
5.1 Introduction .......................................................................................................................... 66
5.1.1 Final Testing of the system ............................................................................................... 66
5.1.2 Hardware software acquisitions ........................................................................................ 67
5.1.3 User manual preparation ................................................................................................... 68
5.2 Training ................................................................................................................................ 69
5.3 Installation Process .............................................................................................................. 69
5.4 Start-up strategy ................................................................................................................... 69
Chapter Six: ...................................................................................................71
Conclusions and Recommendation ...............................................................71
6.1 Conclusions .......................................................................................................................... 71
6.2 Recommendations ................................................................................................................ 71
Reference .......................................................................................................72
Acknowledgment
First and foremost and above all our biggest thanks would be to Almighty God because
nothing could be possible without his free will and the completion of this project is
supported by him.
Secondly we would like to thank our Advisor Mr.Haftom B. and Coordinator Mr. Senthil
Kumar Ramadoss, for them restless edition of our documentation, input to the quality of
this document, heart full guidance, valuable advice, and providing to execute this project.
vi
Thirdly we would like to thank Ambo University Institute of Technology Department of
Computer science head Mr. Naol Bekele, for partial willingness of interview, patience in
answering to our numerous questions, giving documents and reading materials that help us
to precede our project.
Fourthly we would like to thank Ambo Koo pharmacy office manager Mr. Robsan Merga
for partial willingness of interview, patience in answering to our numerous questions for
our project.
Finally, the last but not the least, even if it is usual the group members would like to thank
each other. The main contributors to do this document project are teamwork, friendship
and the belief that we may achieve something we set out to do.
We also hope that this project and documentation may be testaments to our continued
friendship and better work. Without helps of the particular that mentioned above, we would
face many difficulties while doing this.
List of Figures
TITLE PAGE
Figure 1 proposed system process ................................................................................................. 18
Figure 2 Use case diagram .......................................................................................... 26
Figure 3 class diagram analysis label............................................................................................. 38
Figure 4 Sequence Diagram for Login ........................................................................................... 39
Figure 5 Sequence Diagram for register drug ................................................................................ 40
vii
Figure 6 Sequence Diagram for check expire date ....................................................................... 41
Figure 7 Sequence Diagram for Delete Employee......................................................................... 42
Figure 8 Sequence Diagram for Sale Drug .................................................................................... 43
Figure 9 Activity Diagram for Login ............................................................................................. 44
Figure 10 Activity Diagram for Register Drug .............................................................................. 45
Figure 11 Activity Diagram for Register Employee ...................................................................... 46
Figure 12 Activity Diagram for Delete Employee ......................................................................... 47
Figure 13 Activity Diagram for Check Expire Date ...................................................................... 48
Figure 14 Activity Diagram for Sale Drugs ................................................................................... 49
Figure 15 State chart diagram for login ......................................................................................... 50
Figure 16 State chart diagram for Register Drug ........................................................................... 51
Figure 17 State chart diagram for delete employee ....................................................................... 52
Figure 18 State chart diagram for delete drug................................................................................ 53
Figure 19 User interface diagram .................................................................................................. 54
Figure 20: proposed system architecture ....................................................................................... 58
Figure 21: Hardware architectures diagram of system .................................................................. 61
Figure 22 : persistence modeling ................................................................................................... 62
Figure 23: User Interface Home Page ............................................................................................ 68
Figure 24:User Interface Login Page ............................................................................................. 69
List of Tables
TITLE PAGE
Table 1 Schedule table using Gantt chart................................................................... 12
Table 2 Team composition structure.............................................................................................. 19
Table 3 Use case description for login ........................................................................................... 27
Table 4 Use case description for manage account ......................................................................... 28
Table 5 Use case description for employee registration ................................................................ 29
Table 6 Use case description for delete employee ......................................................................... 30
Table 7 Use case description for drug registration ........................................................................ 31
Table 8 Use case description for check expired date ..................................................................... 32
Table 9 Use case description for sell drug ..................................................................................... 33
Table 10 Use case description for print use case ........................................................................... 34
Table 11 : Access control and security ........................................................................................... 63
Abbreviation
CD-R: compact disk read only
viii
CSS: Cascading style sheet
DB: database
GB: Giga byte
HTML: Hypertext mark-up language
JS: Java script
MYSQL: Structure query language
PHP: Hypertext Pre-processor.
UI: User interface
UML: Unified modelling Language
ix
Abstraction
The system is web based Pharmacy management system. The main Idea of this project is
to design and implement a web based system which will be used by any peoples for giving
information and data about drug. The proposed system changes the existing manual system
in to computerized by identifies the existing system problem and improves it. This web
based drug order management system primary aim is to improve accuracy and enhance
safety and efficiency in the Ambo Koo pharmacy drug store. This system manages most
drug related activities in the Ambo Koo pharmacy. The system we have proposed is going
through stage of life cycles: requirement gathering, requirement analyzing, system
designing, implementing, testing and maintaining. For requirement gathering we use
interview and observation in the Ambo Koo pharmacy. For requirement analyzing and
design we use UML modeling and E-draw max. And for implementation phase we will use
object oriented system analysis and design development methodology. The expected
outcome of this system the ability to insert, update, retrieve records, display, and store and
delete customer ,drug information from the database. This system is decrease the cost and
time of data accessing process and it is going to be a user friendly system. It is very easy
to use and less time consuming. The system provides authentication this helps to restrict
unauthorized users.
x
Chapter 1
1.1 Introduction
The Pharmacy management system is a management system that is designed to improve
accuracy and to enhance the performance of the task in the pharmacy. It is a computer
based system which helps to the employee inside the pharmacy to facilitate the activity of
the pharmacy in a manner way.
In the pharmacy there are two places in which the drugs are available. Those are stock and
store. The stock is the place in which the drug that needs to be sold is stored. And the store
is the place in which the new bought drug is stored.
The system allows the user to enter a manufacturing and expiry date for a particular product
or drug during opening stock. The system will also give report showing the list of products
expiry after a specified date before the product eventually expires. It also involves manual
entry upon arrival of new batches of drugs and upon drug movement out of the pharmacy
for a certain period, e.g. every month, the pharmacist may want to generate report for the
movement of drugs in and out of the pharmacy, getting information about the drugs e.g.
expiry date, date purchased, number of drug type left, location of a drug in the pharmacy.
At present manual system is being utilized in the pharmacy. It requires the pharmacist to
manually monitor each drug that is available in the pharmacy. This usually leads to
mistakes as the workload of the pharmacist increases.
1.2 Organizational Back ground
Ambo Koo pharmacy which is found in Oromia region ,west Shoa zone ambo town in front
of Ambo Hospital it was established in 2006 E C. Now the pharmacy gives fast service for
the society. Supply and demand of ambo Koo pharmacy is based on market needs.
1.2.1 Vision of the organization

The Ambo Koo pharmacy vision is to see a transformed pharmacy where adverse effects
of patients are minimized and its people are living in peace and creating healthy society.
1
1.2.2 Mission of the organization
The mission is to prevent and improve human suffering and to contribute to the wellbeing
of mankind and prevalence of and satisfaction customer needs, its Additional Optional
Protocols and the fundamental principles of the Ambo Koo Pharmacy.
1.3 Background of the project
The existing system of Ambo Koo Pharmacy Management System has working with the
manual system. This means that, the current drug information is recorded on paper, patient
information is also recorded on paper, patient tuition paid in paper, reports are translate in
paper. The employee uses the manual system in order to manage the overall activity of the
pharmacy.
Today with the growth of population number, our country is facing serious problems. Many
organizations are in trouble to accommodate these large numbers of people according to
their needs. Many problems in the organizations are associated with the increasing number
of customers and way of helping them. Currently, all activities of pharmacy system are
going on manually, which lead to wastage of time, labor, accuracy, and speed. Pharmacy
System is the backbone of the medical health sector. So it should be advanced and
computerized to provide fast services for the community and also for other users of the
system like manager, pharmacist, store coordinator and cashier.
1.4 Statement of the Problem

 Managing a very large pharmacy with records on papers will be tedious and
difficult to keep track of inventory with regards to the drugs in the stock
inside the pharmacy.
 Since it is manual system quantity of drugs available based on the categories
and their functions can’t be easily known. Due to this the patient can’t get
the drug they want.
 There is no well arrangement of drugs.
 The employee’s difficulty of getting full information about drugs when
needed immediately.
2
 Preparing report for each drug takes long time.
 It is difficult to identify which drugs are out dated or expired.
 The most sensitive data is lost because of they are paper based.
 Most of the time redundant data occur.
 Due to data redundancy the pharmacy uses a lot of stationary materials
which makes it expensive.
1.5 Objective of the project

1.5.1 General objective
The main objective of this project is to develop a Web Based Management System for
Ambo Koo Pharmacy which solves the above-mentioned problems with the existing
system.
1.5.2 Specific objective
In order to achieve the main objective, we have the following specific objectives:-
 Previous System analysis.

 To create fast and reliable system.
 To design a user friendly interactive system.
 To check decreasing and increasing items in stock.
 To delete or remove expired drugs.
 To generate report with in short period of time.
1.6 Scope of the project

The scope of the project is concentrating on how to manage the new store item registration,
check availability items in the data base and Store item expired date checking before the
actual expired date reaches, efficient, and functional way. It is also interested to analyze
the system in relation with customer interaction. Therefore the project is bounded on:-
checking the available drugs and System checks expired date whenever the users login,
sale drugs, manage account, register employee, Register drug, view employee, delete
employee, register customer, And effectively gives service for Ambo city society and
around there. And work for only ambo Koo pharmacy.
3
1.7 Significance of the project
As the scope of the project, the outcome will include the Following:-
 Better Stock Management.

 Provide better data stock in the system.
 Minimizing the cost.
 Facility quality control.
 Decrease items damage.
 Better Customer Satisfaction.
 To reduce wastage in terms of time.
 To minimize the work load of the employee.
 Enhance best controlling for the drug.
1.7.1 Target Beneficiaries of the system
Here we described the benefits that are expected to gain after the development of the
system.
 To the system developing team members

 Having knowledge how real life problem should be solved.
 Going back and for the through each and every system development phase
and acquire skill and experience in the developing software.
 To the pharmacist
 Decreasing more time consumption.
 Increasing job satisfaction and eliminating tedious tasks.
 Helping pharmacists by facilitating the work load.
 To the customer
 To get fast response.
 Have more confidence or trust about the drug.
 Better satisfaction.
1.8 Methodology for the project

The team chooses object oriented analysis and design approach to analyze and design the
system, based on our preliminary analysis of the old system.
4
In our project the team will use Object Oriented Software Development Methodology
(OOSD) because it has the following advantages:-
 Increase reusability: - the object oriented provides opportunities for reuse through
the concepts of inheritance, polymorphism, encapsulation and modularity.
 Increased extensibility: - when there is a need to add new feature to the system
you only need to make changes.
 Improved quality: - quality of our system must be on time and meet our exceeded
the expectation of the users of our system, improved quality comes from increased
participation of users in the system development.
1.8.1 Data Source
We use document analysis in order to obtain the information about the practices and
problems of the pharmacy which ultimately assists us in developing the computerized
system. There are saved documents referred for the preparation of the system. In addition,
we use internet access.
Document analysis: The team reviewed documents such as books, e-books and some
related previously done projects which are very important to develop our project. During
the analysis of documents, we give a special consideration to those documents which can
bring more features to our system.
Interview: This is one of data collection method that enables to gather information from
the organization directly in the form of asking question and getting answers for those
questions. So, we will use this method to gather information by asking the manager of the
pharmacy some basic questions regarding the following issues will be asked during the
interview:-
 How drug information management system is going on?
 During managing, are there any problems? If there, what are they?
 What requirements are needed for the process?
 Who is responsible for what?
5
Observation: This is also another data collecting method. In fact we have also used this
observation method to gather data. This method enables us observing and understanding how drug
information management is going on.
1.8.2 Fact Finding Techniques

We gather the necessary information for our project from Ambo Koo Pharmacy through
the following methods:
 Document review
 Observation
 Interviewing users and employee of the pharmacy.
We preferred interviewing because we are able to get reliable information about the
pharmacy. Our data sources for interviewing: Owner of the Pharmacy Degafa Uma, Drug
Manager Robsan Merga accountant Sifan Kalbesa.
1.8.3 Systems Analysis and Design (approach)

In our project, we are applying the concept of object oriented system Analysis and design
development methodology, because it is best way to construct, manage and assemble
objects that we are implement in our system, and the composition of objects and
collaboration between objects on the system. It Models the functions of the system (use case
modeling), identifying the business objects, organize the objects and also the relationship between
them and finally model the behavior of the objects. It also shows object interactions and behaviors
that support the use case scenario, and finally update object model to reflect the implementation
environment we choose this approach because of the following advantages:
 Increased reusability: object oriented support reusability of system.
 Increased extensibility: to add and change the existing module without affecting
the rest of the program
 Improved quality: introduces user participation which improves quality of the
project
 Improved chance of project success: since object oriented approach has good
documentation
 It reduce maintenance cost
6
1.8.4 Development Tools
Software tools:
We use different software to develop the proposed system. This software is used to us for
preparing the documentation and drawing the diagrams and also to design the system.
Those are:
To implementation (developing) this project we will use the following software’s.
 XAMPP Server 2012

 Programming Tools like HTML,CSS.JS,PHP, MySQL database
 Star UML, E draw max:-For designing UML diagrams associated with the project.
 Microsoft office 2013:- for documenting the corresponding deliverables associated
with the project.
 PHP programming language: - for the software developing.
 Edit plus and notepad++:- for writing code.
Hardware tools:
 16GB Flash disk

 CD-R
 Personal Computer.
 Desktop Computer.
1.8.5 Testing procedures

A testing methodology is a tool or method used to test an application or the system. Testing
is the process of evaluation a system item to detect differences between given input and
expected output. Testing is the process of exercising a program with the specific intent of
finding errors prior to delivery to the end user. Testing assesses the quality of the product.
Testing is a process that should be done during the development process. In other words
software testing is verification and validation process. We will use different testing
technique and testing strategy to test the system.
1.8.5.1 Testing technique

We will use two different methods of testing technique.
7
1. Black-box testing.
2. White-box testing
1. BLACK-BOX TESTING:
The technique of testing without having any knowledge of the interior workings of the
application is Black Box testing. Black-box tests are used to demonstrate that software
functions are operational, that input is properly accepted and output is correctly produced,
and that integrity of external information is maintained. The tester is oblivious of to the
system architecture and does not have access to the source code. Typically, when
performing a black box test, a tester will interact with the system's user interface by
providing inputs and examining outputs without knowing how and where the inputs are
worked upon.
 Knowing the specified function that a product has been designed to perform,
test to see if that function is fully operational and error free
 Includes tests that are conducted at the software interface
 Not concerned with internal logical structure of the software
We use in our coding to find errors in the following categories:
 Incorrect or missing functions

 Interface errors
 Errors in database
 Performance errors
 Initialization and termination errors.
Unlike white-box testing, which is performed earlier in the testing process, black-box
testing tends to be applied during later stages of testing. Because black-box testing
purposely disregards control structure, attention is focused on the information domain.
2. WHITE-BOX TESTING:
White-box tests are used to examine the procedural details. It checks the logical paths by
test case. It can also checks the conditions, loops used in the software coding. It checks that
loops are working correctly on defined boundary value. White box testing is also called
8
glass testing or open box testing. In order to perform white box testing on an application,
the tester needs to possess knowledge of the internal working of the code. The tester needs
to have a look inside the source code and find out which unit/chunk of the code is behaving
inappropriately.
 Knowing the internal workings of a product, test that all internal operations
are performed according to specifications and all internal components have
been exercised
 Involves tests that concentrate on close examination of procedural detail
 Logical paths through the software are tested
 Test cases exercise specific sets of conditions and loops
Testing Strategy
We will also use the following testing strategy to test the system.
 Unit Testing: Unit testing is the testing of an individual unit or group of related
units. It falls under the class of white box testing. It is often done by the
programmer to test that the unit he/she has implemented is producing expected
output against given input.
 System testing: System testing is the testing to ensure that by putting the software
in different environments (e.g., Operating Systems) it still works. System testing
is done with full system implementation and environment. It falls under the class
of black box testing.
1.8.6 Proposed Implementation Method

In this we discuss how the proposed system replaces the existing system. I.e. identifying
whether it is rapid installation or parallel installation.
Rapid installation: - the newly proposed system completely replaces the existing system
which means existing system-s are no longer functional.
Parallel installation: - here the newly proposed system functions parallel with the existing
system so there is no complete change or replacement of system.
9
And since our proposed system functions parallel with existing system we go for parallel
installation rather than rapid installation.
1.9 Limitation of the project

This new system that we are going to develop mostly may concerned on information that
required for the drugs in pharmacy that enable them to manage the drug information but
our system will not include
 The system can’t change in to computerize completely because it works hand in
hand documentation.
 Our system works only when a database is active and the network is available.
 Blind people are unable to use the system.
 The system does not support multi language.
 System does not allow online drug shopping
 The system organization does not have any interaction with other organization
system.
 The system applies to only Ambo Koo pharmacy.
1.10 Risks and Contingencies

Risk assessment and contingency planning is the process of determining the risks a
business faces and what it must do if those risks are realized.
Risk assessment and contingency planning is the process of determining the risks a
business faces and what it must do. The project cannot be developed as it is initially
planned. This is due to the fact that risk may happen in the process of project development.
We assume the following risks can encounter: The unavailability of data source
(information gathering) on time may extend the project completion time. We managed
this problem using different methodology.
 For the physical damage on the computers that we work on, it is managed by
using backup.
 Lack of reference books. We managed this problem by using other methods such
as internet.
 Shortage of Time. We managed such problem by using additional time from our
rest time and divide our time by schedule.
 Virus can attack our project. We used updated antivirus to manage this problem.
10
 Power fluctuation problem. It is using laptop that have high power pack ups are
used.
1.11 Assumptions and Constraints

Assumptions: - are thinking about the project or the system how it gives the services for
the needed purpose fairly, efficiently and effectively regarding to facilities and perform all
of these activities they are needed by the organization. We assume our project will be
accepted by Ambo Koo pharmacy. The reason is that the project is politically behavioural
feasible
Constraints: - defines how well a system should perform a function, or set of functions. It
is documented using the following information: A measurable value, which can be used to
judge the performance of the system with respect to this constraint. Our proposed system
can’t handle if the power is lost during the user register to the system, managing in the
system, sent request to the system, searching data from the system.
1.12 Schedule of the project (using Gantt chart)
This involves questions such as how much time is available to build the new system, when
it can be built.
11
Table 1 Schedule table using Gantt chart
ID Task Name Start Finish Duration

20/11/2018 1/12/2018 1/1/2019
20/11/201 27/1/20
25/11/2018 2/12/2018 9/12/2018 16/12/2018 23/12/2018 30/12/2018 6/1/2019 13/1/2019 20/1/2019
8 19
1 Requirement gathering 20/11/2018 30/11/2018 9.0 d.
2 SRS 30/11/2018 14/12/2018 11.0 d.
Description of the
3 Existing System & the 14/12/2018 28/12/2018 11.0 d.
Proposed System
System Analysis &

4 28/12/2018 10/1/2019 10.0 d.
Modeling
Analysis and Checking

5 11/1/2019 22/1/2019 8.0 d.
Documents
12
Chapter Two
2 Description of the Existing System & the Proposed System

2.1 Introduction of Existing System
The current system of Ambo Koo pharmacy information management is manual system.
That means checking expired date and availability of drugs is done by checking every drug
inside the pharmacy. This lead losing time and resource of the organization. An existing
system compromises different players to carry out its job.
2.1.1 Players in the existing system

The main players of the existing system are: -
 Admin: the person who administers a business or director of that organization.
 Pharmacist: the person who receives prescription from the patient.
 Manager: who receive the report from pharmacist, store coordinator and cashier
to help the manager how the service are given to the client.
 Store coordinator: Store coordinator is responsible to register the drugs that buy
from the private sectors or from the governmental association, and also control the
drug that are goes out to the stock.
 Cashier: The cashier receives the cost of the drug from the customer ordered by
the pharmacist.
2.1.2 Functions/activities in the existing system

2.1.2.1 Main activity of existing system
There are so many types of activity in the existing system of special pharmacy from them
 Dispensing it is the process of exchanging meaning selling and buying of drug.
 Advancing counselling drug usage for patient meaning when the patient take drug the
pharmacist give advice how to take drugs, like morning one ,night one style
 Selling cosmetics for adults and children’s
2.1.2.2 Function of existing system

 To sell drug and giving care for the patient
 To satisfy the patient giving quality and fast services with affordable cost and efficiency
 To bring qualified drugs this is not expired.
 To provide different drugs for patient.
2.1.3 Business rules

Every employee of the system must have an account for accessing the system, even the
manager itself to increase the security of the system.
 the drug which is checked its expired date by the pharmacist when the drug is
sold and with a certain interval of days
 The receipt which is contains the cost of the sail drug with drug information. It
is made by pharmacist and given by accountant to the patient.
 The pharmacist who is taking the drug from the store has responsibility to
record and manage properly.
 The pharmacist advice patient on the drug usage methods and patient have
responsible for that usage method.
2.1.4 Report generated in the existing system

The report are generating by pharmacist and other professional in documented form to the
pharmacy Manager
 Stock controlling system like both LIFO and FIFO system to the pharmacy Manager.
 The prescription collected from the patient.
 Copy of receipt that is given to the patient.
2.1.5 Forms and other documents of the existing systems

There are different types of documents that are used in the existing system Like: -
 Invoice record system documentation (buying process receipt)
 Financial statement
 Reports that are described in the report generating
 Input /output documents
Ambo Koo pharmacy drugs and medical supplies request format
KIVOD TRADING PLC
14
SUBCITY-ARADA KEBELE-09/ H.NO-242/D TEL-01112622470/53,
0929900029
TIN-041464278 - kivodmed2051@gmail.com
CREDIT SALES ATTACHEMENT
Customer info
References
Customer AMBOKO PHARMACY
Date 15/01/2019___
Trade name ______________________
FS No 00011438_____
TIN Number _____________ VAT #
Ref No 00011432_____
Sub city N/A Kebele AMBO H.NO Oromia
Reference CRSI-00007938
Tel Halala__--
License # Acc # Ref Note ______________
BEFO/AHITQFFWO/2947
Code Description Batch No Exp. Quantity Unit Total

date Unit Price
FEK-V- 002 V2-plus (MVT) of 24 596 01/20 pact 5 70.00 350.00
EST-S-001 Salbutamol syrup 1833 08/21 Bott 10 26 264.00

MER-D-003 Domadol(Tramadol)50mg GDO-18020 May/21 pact 2 144.20 288.40
Of 10x10cap
TRA-C-001 CA diplex Syrup of 100ml D18001BM35 Feb/20 pact 10 29.30 293.00
RT-A-003 Amoxicillin 250 of 26918 08/23 Box 2 565.70 1,131.40

100X10cap
RT-A-002 Amoxicillin 500 of 25400 03/33 Box 2 509.00 1,081.00

50X10cap
SUBTOTAL 3,344.80
Payment method: CREDIT
Amount in Word: Three Thousand Three Hundred Forty Four Birr and Eight Cent Only VAT (15%) 0.00
GRAND 3,344.80
MEMO: TOTAL
_________________________________________________________________
15
2.1.6 Bottlenecks of the existing system
There are different failure or weakness in the system from them these are as follows
 They have no computerized pharmacy system

 Unable to give fast service for customer of pharmacy
 Absence of centralized drug management
 It is difficult to know the expired date of drug
 It is difficult to know the patient that have credit remain
 They have no unified system for processing drug information
 It is difficult to manage or getting quick information about exact place of drug on
the shelf
2.1.6.1 Performance (Response time)

The existing system does not provide fast response time because it is difficult to access
data from the document and misallocation of land owners profile in the shelf to retrieving
the land owners’ status information. It can only provide required information of the users
after a long period of time (takes a lot of time to perform a specific task).
2.1.6.2 Input (Inaccurate/redundant/flexible) and Output

The existing system takes the input in the form of hard copy or in the form of paper
document. The users request for the service in the current manual system is considered as
input. The output of this system is the response for the user’s request and any service given
to the user in the town from the office. Since, this all thing is done by manual power; there
is inaccuracy because validity is not properly checked and data redundancy. The flexibility
of the input is that, when inputs are inserted to the office and it is easily changed.
2.1.6.3 Security and Controls

Since the data stored in a paper someone can access the data without security. Storing data
is not secure because, anyone who opens the computers, in which the system is installed
and used, can access all the contents of the database. The manager can control all activities
and gives permission for user to use the resources and control the resources. There is no
login form.
16
2.1.6.4 Efficiency
The existing system is less efficient to access information about drugs information. Every
activity and data is share manually.
2.2 Practices to be preserved from existing system
The Strength part of existing system is the presence of work distribution. Management
system is assigned by different people (used to share their experience) and manager front
office are participating in works the files are printed on paper and it stored on the shelf. So
we went to design some useful practice to solve the problem and increase the efficiency of
the service. From the existing system the following are practices to be preserve.
The governing rule and regulation to check expired date of drug within a month
 The business rules.

 Receipt generated.
2.3 The Proposed System
After observing the current manual drug Management system and understanding all the
problems occurred during every activity on the existing system of Ambo Koo Pharmacy
we desired to design a system that solve the problem of the current system. The proposed
system has server, database and client. The server used to fetch data from the database and
store data in to the database according to the instruction of user. Database used to store
data and information about drug and patients. The client is displaying the pages to the user
and after the user input the client send the request to the server and also display the response
of a server to the user. The system that we are proposed store all details of the drug
including their name, type, expire date and all the information related to it. The proposed
system will also support handling inquiries from prospective pharmacy manager handling
the drug detail.it become essential to make from properly managed medicine order
management system so that user can easy access drug record and get the desired
information easily. User friendly interface fast access to database , less error more storage
capacity , search facility, look and feel environment, Easy to handle and feasible ,cost
reduction fast and convenient and accurate .The proposed system will use the major
17
functionality of existing system able to advance accordance with performance (the system
will have faster response time and use minimal space usage ) , security(provide or contain
user name and password for each based user on their privilege ),reliability(system is
reliable by analyzing each information by organization of the system ),speed(regarding on
the speed of the system will generate output)
Figure 1 proposed system process
Purpose
The new system has the following purposes.
 Ability to insert data: - the pharmacist can insert data into the database
 Ability to give delivery system of the drug: - pharmacist sold the drug the sold drug
quantity will be decreased from the register drug quantity and generate receipt by
casher.
 Ability to delete, modify:- the pharmacist can perform these activities
 Ability to access and generate report: - the pharmacist and the casher can access and
generate report based on their needs.
In general, we expect that the new system will solve the problems which are mentioned in
the specified problems of existed system by using different tools and techniques.
18
2.3.1 Team composition
Involves organization of the team and communication among each member of the team.
There are three (3) types of team organization:-those are centralized, decentralized &
mixed. Among these three control team organization our project team chooses
decentralized – control team organization. Because de-centralized – control team
organization: - is ring-like management because of lack of hierarchy. The team member is
at the same level, and then can review each other’s work and responsible as a group. Reason
of choice:
Suitable for less understood, more complicated problem
Higher moral among team member
Higher quality of the product
In our project, we have seven (7) members where each of us has specified work and also
the project is supervised by two of our members. The following are the types of tasks and
as well as the responsibility each of us can have.
Table 2 Team composition structure
Project adviser Mr. Haftom B.
19
2.3.2 Feasibility Analysis
Feasibility means answering questions relating to the utility and viability of the system that
is going to be developed & it is the measure of how beneficial or practical of pharmacy
drug information system will be to an organization. To get user acceptance and making the
system easily understandable and accessible the new system considers the following
feasibilities: -
2.3.2.1 Operational feasibility

The system to be developed will provide accurate, active, secured service and decreases
labor of workers and also it is not limited to particular groups or body. From the user’s
perspective our system fully operational feasible as it just requires some knowledge of
computer. There are enough validations available so operator does not require any special
technical knowledge. Some factors to be operational feasible:
o It is user friendly interface
o It uses web service
o It provides an easier access of drug file rather than searching drug file from the file
cabinet.
o Better management of time .so, the entire team member expects the system to be
operationally feasible.
2.3.2.2 Technical feasibility

The proposed system doesn’t require much technical expertise. The system to be developed
by using technologically system development techniques such as PHP, Java script, CSS
and MySQL database without any problems and the group members have enough
capability to develop the project. So, the system will be technically feasible.
2.3.2.3 Economic feasibility

Economic feasibility determines the costs and benefits related to the developing project. It
also identifies the resources that are needed for the project. Our system is successfully
completed it used to store data & information for drugs & patients. In case of our proposed
system we divided the tangible benefit in to two ways as follows.
One-time cost
 The cost paid for system designers and system analysts
20
 The cost of Software to be acquired to build and run the system
 The cost to buy server.
Recurring cost
 The cost to maintain computers, database and server if there is problem with them.
 Salary of system manager
2.3.2.4 Behavioral / Political feasibility

Behavioral feasibility is the measure that how users use the system effectively. The
proposed system should be easy to operate, convenient in maintenance and effective in its
working. Thus behavioral feasibility is very important factor to be considered for effective
working of the system. Behavioral feasibility is dependent on human resources available
for the project and involves projecting whether the system will operate and be used when
it is functionally operate. The system is behaviorally feasible because of the following:-
 The proposed system is easy to operate.
 Retrieval of information is easy, accurate and fast.
Political feasibility requires identifying the people that are going to be affected by the
information system to be developed and any power shifts it may bring within the
organization. Finding out what people affected by the IS think about it and how they will
react is a part of political feasibility. Our project will try as much hard as possible not to
be a means to harm anyone. The usage and application of the system will be in agreement
to the basic rights and polices of the government.
So the proposed system is politically and behaviorally feasible.
2.3.2.5 Schedule feasibility

Schedule feasibility concerned with analyzing the expected completion date of the project
and the constraints that may bring change to this date. We have so many fixed schedules
to work together. So, the project team members think that the project will be finished within
the specified time. In general, the project is less risky as a result of the reasons specified in
each of the feasibility analysis studies. Project manager is also responsible for monitoring
& controlling the project development based on the previous schedule in chapter one.
21
2.4 Requirement of the Proposed System
Our Requirements are two Component
 Functional requirement
 Non Functional requirement
2.4.1 Functional requirement

The functional requirement of the Project is defines a function of our System and its
components. A function is described as a set of inputs, the behavior, and outputs.
Functional requirements also describe the relations between the system and the user or the
environment. Here the ‘relations’ means the direct or indirect interactions between the user
and the system.
The functional requirement of our system is:-
 The system shall allow employee login to the system by using their username and
password.
 Our proposed system includes reports that are done on the week, Receipt and other
related operation.
 Implement the new system using object oriented technology and methodology.
 The system allows to know easily the quantity of the drug that are existed in the
pharmacy it is used to differentiate the expired drug from unexpired because of these
we can reduce the wastage of the resource (drug) and money.
 The system allows knowing easily the expired date the drug.
 To arrange the type of drug based on pharmacological action on the shelf.
 To provide quick information on the drug and its description and easy access on search.
 The System has to delete the item at the expired date.
 Allows authorized user /personnel to update the database.
 The system shall allow employee to logout by pressing log out button.
2.4.2 Non -Functional requirement

Non-Functional requirement explains and describes requirements that support the main of
the system that should have but they are not part of the system functionalities. Generally
non-functional requirements describe the quality of the system. The following lists states
the non-functional requirements.
22
2.4.2.1 Performance
The user can login to the system easily and can access information on a computer from
database. The server is large which is to accept the request from the users and give
responses after processing the request in a short period of time. The system serves all users
simultaneously.
The performance of the system has short response time for a piece of work,high rate of
processing work, Low utilization of computing resource, high availability of computing
system or application and decreases work overload.
2.4.2.5 User Interface

The system GUI is consistent with all other programs. The interface should be clear to
understand. The interface has help files that describe the usage and about office that
contains the general information about the office access publicly of each user interface.
The homepage contain the entire pages and it is master page. The entire patient, accountant,
pharmacist manager are need to login to the system.
2.4.2.2 Security and Access permissions

The new system provides security to prevent and protect unauthorized modification of data,
the new database must have a security to control the activities that can be performed by the
users and determine which information can be viewed and modified. The system generates
warning messages for every invalid input and secures every document in database.
2.4.2.3 Backup and Recovery

Storing data in another place for backup purpose, if the system is destroyed, then it is easy
to get the lost data. This can be done by placing the data in another place. If the data is
failed or lost, then the lost data can be easily recovered the database. The proposed system
can store any data inserted in to the system in appropriate manner. The stored data can be
kept in database permanently and can be retrieving easily when the user accesses it from
database.
2.4.2.4 Resources, usability, availability

The system consumes resource that required high processer speed both for server and client
and machine having more memory space as a server. We use computer, laptop, disks, paper
23
for layout and properly using them and protecting these resources from damage. We use
powerful mark-up languages which support graphical user interface friendly. The proposed
system can store any data inserted in to the system in appropriate manner. The stored data
can be kept in database permanently and can be retrieving easily when the user accesses it
from database.
Chapter There
3. System Analysis and Modelling

3.1 Introduction
The pharmacy management system is based different model view to represent the system
in understandable way such as in scenarios, use case models, object models, Activity
diagrams, and sequence diagrams.
3.2 System Requirement Specifications (SRS)

Use case model
Use Case represents interaction between a user (human or machine) and the system.
Use case components:

 Actor: is a person, or external entity that plays a role in one or more interaction
with the system.
 Use case: describes a sequence of actions that provides something of measurable
value to an actor and is drawn as a horizontal ellipse.
 System boundary: indicates the scope of the system project. Anything within the
box represent functionalities in side with in scope.
Actor identification
In the use cases an actor interact with the system to perform a piece of meaningful work
that helps them to achieve a goal and has access to define their overall role in the system
and the scope of their action. Depending on the above explanation actors in this system are
the following:
24
 Admin: The owner of the Pharmacy that control over all activity
 Manager: Controls the overall activity in the shop.
 Pharmacist: Manages the drug information in the stock.
 Store coordinator: Manages the outgoing and incoming drug from the stock.
 Cashier: Collect the price of the sold items and generate report to the manager.
Use case identification
Each Use Case describes the functionality to be built in the proposed system, which can
include another Use Case's functionality or extend another Use Case with its own
behaviour. The most important and basic use cases of this system are the following:-
 Login
 Manage account
 Create account
 Delete account
 Change password
 Register employee
 View employee
 Delete employee
 Register drug
 Register Customer
 View drug
 Delete drug
 Check expire date
 Sale Drug
25
Figure 2 :Use case diagram
26
Use case description
Use Case Documentation
Table 3 Use case description for login
Name Login
ID UC1
Actors System Admin, Manager, Pharmacist, Casher, Store coordinator
Description In order to get into or access the system
Pre-condition 1. The System Admin, Manager, Store coordinator, pharmacist, or

Cashier must open the system
1. Open the system.
2. Click on login link.
3. Login form displayed.
Flow of events 4. Select account type and enter user name and password.
5. Click on the login button.
6. System verifies in the account database.
7. Main form displayed.
8. End of use case.
Post condition 1. Access the system
27
Table 4 Use case description for manage account
Name Manage Account
ID UC2
Actors Manager
Description Create new account, delete an account.
Pre-condition 1. The manager initiates the system.

2. The manager should have a valid user name and password.
1. The manager opens the system.
2. The manager log to his or her page.
3. The manager click on the create account or delete account link.
4. The system displays create or delete account form.
5. The manager inserts the necessary information of the user.
Flow of event 6. The manager clicks on sign up or delete button.
7. The system verifies the inserted information.
8. Then the system will generate successfully message
9. End of use case.
1. Access the system

Post condition 2. Close the system
28
Table 5 Use case description for employee registration
Name Employee Registration

ID UC3
Actor’s Manager
Description Register the information of the workers in the pharmacy
Pre- 1. Initiate the system
condition 2. Have user name and password
1. The manager opens the system.
2. The manager log to his or her page
3. The manager click on the register employee link.
Flow of 4. The system displays the register employee form.
event 5. The manager inserts the necessary information of the employee.
6. The manager click on the register button.
8. End of use case.
Post 1. Access the system
condition 2. Close the system
29
Table 6 Use case description for delete employee
Name Delete Employee
ID UC4
Actor’s Manager
Description Delete the employee when it is necessary.
Pre- 1. Initiate the system.

condition 2. Have user name and password.
1. The manager log to his or her page.

2. The manager click on delete employee link.
3. The system displays the delete employee form.
Flow of 4. The manager enters the id_no of the employee.
event 5. Click on the delete button.
7. End of use case
1. Return to home page or

post 2. Close the system
condition
30
Table 7 Use case description for drug registration
Name Register Drug
ID UC 5
Actors Store coordinator
Description Registering the new drug from the store in to the data base.
Pre- 1. Initiate the system.

condition 2. Have user name and password.
1. The Store coordinator opens the system.
2. The Store coordinator log to his or her page.
3. The Store coordinator click on Register drug link.
4. The system displays the register drug form.
Flow of 5. The Store coordinator will enter the attributes of the drug.
event 6. Then click on submit.
7. Then the system will generate successfully message.
8. End of use case
Post 1. Return to home page or

condition 2. Close the system
31
Table 8 Use case description for check expired date
Name Check Expired Date
ID UC 6
Actors Store coordinator
Description In order to check the drug that is the verge of the expired date.
Pre-condition 1. Initiate the system.

2. Have user name and password.
1. Open the system.
2. The Store Coordinator log to his or her page.
3. The Store coordinator click on check expired date link.
4. Then the form will be displayed.
5. The Store coordinator enters the expired date of the drug.
Flow of event 6. Then Store coordinator clicks on search button.
7. The system displays the list of the dug that is inserted in its date.
8. The Store coordinator click on the clear button.
9. Then the system will response successfully message.
10. End of use case.
Post Condition 1. Return to home page or
2. Close the system
32
Table 9 Use case description for sell drug
Name Sale Drug
ID UC 7
Actors Pharmacist
Description To purchase the drug to the customer
Pre-condition 1. The customer brings with his/her prescription.
1. The pharmacist opens the system.

2. The home page will be displayed.
3. The pharmacist inserts user name and password.
4. The system will verify the user name and password.
5. The pharmacist click on check list link.
6. Then the system displays the drug list.
7. Then return to sale drug link.
8. Click on sale drug link.
Flow of event 9. Enter the necessary information of the customer and the drug.
10. Then click on the load button.
11. Then the system will response successfully message.
Post condition 1. Return to home page or
2. Close the system
33
Table 10 Use case description for print use case
ID UC 8
Name Print
Actors Cashier
Description Printing sealed drug for the customer
Pre-condition 1. There must be list of drug that must be inserted by the pharmacist.
1. Open the system.

2. The home page will be displayed.
Flow of event 3. The cashier inserts user name and password with their account type.
4. The system will verify the user name and password.
5. Then the system display his/her page.
6. The cashier click on fetch drug link.
7. The list of drugs with corresponding quantity and price.
8. The cashier calculates the total price.
9. Then click to print.
10. Then the system will display response.
Post condition 1. Return to their appropriate page.
2. Close the system
34
Scenarios
The pharmacy management system registers medicine, store on the database again
accessed when needed, remove when obsolete, and Export reports for weekly sold
medicine.
Scenario 1:
The pharmacy manager and the customer can get information on the pharmacy by
navigating the pharmacy management system. From the system page can see about the
Medicine sell on the pharmacy, about the organization of the pharmacy including basic
information. Through this the pharmacy management system can display different
information about the organization effectively and efficiently in short period of time.
Scenario 2:
The pharmacy manager can control over the system such as record medicine information
store on the system and again retrieve for data see, delete, update, and print also the
pharmacy system controller can see reports on the medicine in weekly, and monthly as the
user needs this is all about the function done by the system and do the pharmacy manager.
The following is a scenarios explain more.
Scenario name: Get Information about Pharmacy
Actors: -Pharmacy manager, Customer
Flow of Event:
1. The pharmacy manager initiates the system.
2. The system displays the first page.
3. The first page consists of menu’s Medicine, and about pharmacy
4. The customer or the pharmacy manager enters Medicine menu

35
5. System displays the medicine available on the pharmacy with cost and purpose.
6. The customer or the pharmacy manager enters about pharmacy
7. System displays about the organization services and establishment.
Scenario1: Get information for pharmacy scenario for PMS
Scenario name: change Medicine Data
Actors: -Pharmacy manager
Flow of Event:
3. The first page consists of menu’s Medicine, and about pharmacy and login Menu’s
4. The pharmacy manager enters login menu
5. The system displays login form to enter the username and password.
6. The pharmacy manager prompts username and password on available fields that the
system displays.
7. The system displays Main admin page.
8. Go on the settings and change Medicine Data
9. Save the changes
Scenario2: Change Medicine Data scenario for PMS
Scenario name: get Notification On Medicine
Actors: -Pharmacy manager
Flow of Event:

36
3. The first page consists of menu’s Medicine, and about pharmacy and login Menu’s
4. The pharmacy manager enters login menu
5. The system displays login form to enter the username and password.
6. The pharmacy manager prompts username and password on available fields that the
system displays.
7. If there is low medicine items the system displays alert
Object Model
The pharmacy management system described in methodology of Data dictionary and
Class diagram. In which different collection of data’s produce were supposed to
Construct this pharmacy management system and the relationship of classes that compose
the system.
Class Diagram
Class diagrams are the most common diagram found in modeling object-oriented systems.
A class diagram shows a set of classes, interfaces, and collaborations and their
relationships. We use class diagrams to model the static design view of a system. Class
diagrams are also the foundation for a couple of related diagrams: component diagrams
and deployment diagrams.
Class diagrams are important not only for visualizing, specifying, and documenting
structural models, but also for constructing executable systems through forward and
System.
37
Customer
Employe *
* +First Name
Salary * +Last Name
+Age
+Sex
-Register Employee()
-Delete Employee() *
-View Em[ployee() -RegisterCustomer()
* *
*
Drug * 1
1 Cashier
-Drug Name User
-Company Name -Sell Number
-Batch Number -Customer Id
-Quantity -Frist Name * -Emp-Id
-Unit Price -Last Name -Batch Number
-Shelf Number -Age -Quantity
-Expire Date -Sex -Date
-Register Drug() -Address -Status
-Sell Drug()
-Check Expire Date() -Insert()
-View()
* 1 1
1
Manager 1
1
Figure 3 class diagram analysis label
38
Dynamic Model
Sequence Diagram
The sequence diagram is used primarily to show the interactions between objects in the
sequential order that those interactions occur. The main purpose of a sequence diagram is
to define event sequences that result in some desired outcome.
Login Data base

Login link Validator
Home page Form
All Actor
User Visit
User click
Send ()
Display Login
Form ()
Enter UN &Pw
nameand
Select
Types
User click Submit () Validate ()

(
Invalid ()
Continue ()
Check ()
Display Target page ()
Figure 4 Sequence Diagram for Login
39
Register Drug Register Drug
Link Form Validator Data Base
Store
Coordinator
Click On Register
drug()
Display Form ()
Fill Form ()
Validate ()
Send Request
()
Tray Again ()
Continue ()
Check ()
Insert User Successful ()
Figure 5 Sequence Diagram for register drug
40
Check Expired Drug Form Validator Data Base
Date Link ()
Pharmacist
Click
onRegistered
Display Form
()
Check
ExpireDate ()
Send Request Validate ()

()
Tray Again ()
Continue ()
Check ()
Check Drug Successful ()
Figure 6 Sequence Diagram for check expire date
41
Click on View User Validator Data Base
Form
Delete
Manager
Click on
DeleteUser()
Display Form ()
Validate ()
Search User Send
ID Request ()
Tray Again ()
Continue ()
Check ()
Delete User
Successful ()
Figure 7 Sequence Diagram for Delete Employee
42
Sale Drug Sale Drug Form Validator Data Base
Link
Pharmacist
Click on
Display Form ()
Fill Form ()
Validate ()
Send Request
Tray Again ()
Continue ()
Check ()
Display User Successful ()
Figure 8 Sequence Diagram for Sale Drug
43
Activity diagram
Activity diagram is another important diagram in UML to describe dynamic aspects of the
system. Activity diagram is basically a flow chart to represent the flow of information one
activity to another activity
All Actor
All
Home Page
Click On Login
Log In Form
Enter Username and

Password Invalid
Verify
Valid
Active Page
Figure 9 Activity Diagram for Login
44
Store Coordinator
Store
Click On Register Drug
Register Form Displayed
Fill Form
Click On Register
Incorrect
Verify
Correct
Display Successful
Figure 10 Activity Diagram for Register Drug
45
Manager
Click On Register Employee Link
Register Form Displayed
Fill Form
Click On Register Invalid
Verify
Valid
Display Successful Message
Figure 11 Activity Diagram for Register Employee
46
Manager
Click On Delete Employee

Link
Delete Employee Form

Displayed
Insert ID No
Click On Delete Button

Invalid
Verify
Valid
Display Successful Message
Figure 12 Activity Diagram for Delete Employee
47
Pharmacist
Click On Check
Expired Date Link
Check Form Displayed
Insert Expired Date
Not Exit
Click Check
Verify
Item Displayed
Click Clear
Display Successful
Figure 13 Activity Diagram for Check Expire Date
48
Pharmacist
Click On Sale Drug Link
Sale Form Display
Fill Form
Incorrect
Click On Sale Button
Verify
Correct
Display Successful
Figure 14 Activity Diagram for Sale Drugs
49
State chart Diagram
A state chart diagram is a view of a state machine that models the changing behaviour of a
state. State chart diagrams show the various states that an object goes through, as well as
the events that cause a transition from one state to another.
The common model elements that state chart diagrams contain are:
 States
 Start and end state
 Transition
Idle State
Activate
Home Page
Select
Login Link
Fill
Login Form
Incorrect
Correct Confirm
Verify
Login
Display
Appropriate
Logout
Final state
Figure 15 State chart diagram for login
50
Initial state Idle State
Activate
Home Page
Log to Page
Select
Register
Drug
Fill Form
Register
Form
Incorrect
Validate Correct Confirm
Display
Successful
Figure 16 State chart diagram for Register Drug
51
Initial state Idle State Activate Home Page
Log to Page
Select
Delete
Employee
Fill
Delete Form
Incorrect
Display
Successful
Final state
Figure 17 State chart diagram for delete employee
52
Initial state Idle State Activate Home Page
Log to Page
Click
Delete Drug
Fill
Delete Form
Incorrect
Display
Successful
Final state
Figure 18 State chart diagram for delete drug
53
User Interface Diagram and Modeling
In this system users will communicate with it through the following user interfaces.
Home Page: This form contains some links which lead it to the concerned page, and if
the user has an account he/she will directly go to concerned page by entering their
username and password
Home
page
Figure 19 User interface diagram
54
Chapter Four:
System Design
4.1 Introduction
Designing a system has a goal to involve converting the proposed system in to logical and
then physical design specification. We expect one can understand our new system
implementation because it gives full description about whole system. Also one can
understand easily and enable to answer how the system developed and functioned in
simplified manner.
This project is Ambo Koo Pharmacy management system it will solve problems related to
computerize system within the organization. Within the Software Design Document are
narrative and graphical used throughout the document, Next, the document describes the
system under development in terms of subsystem decompositions, hardware/software
mapping, persistent data management, access control , Global software control , Boundary
conditions and Subsystem services.
4.1.1 Purpose of the System

The system is designed to implement a solution to an application domain which consists
of a Web Based Ambo Koo Pharmacy Management System.
The main purpose of the proposed system is to improve some activities through
computerized way that simplifies the workload of the existing system and speedup the
operation of the system.
The application areas for the computerization have been selected on the basis of following
factors:-
 Minimizing the manual records kept at different locations.

 There will be more data integrity.
 Facilitate desired and quick information display
 Facilitating various statistical information which helps in decision-making.
 To reduce manual efforts in activities that involved repetitive work.
55
 Updating and deletion of such a huge amount of data will
become easier
4.1.2 Design Goals

The goal of system design according to the proposed project is to manage complexity by
dividing the system into smaller, manageable pieces and to increase the system.
Implementing of high quality system depends on the nature of the design created by the
designer if one wants to make changes to the system after it has been put in to operation
depends on the quality of the system design.
 Efficiency: The system must do what it is supposed to do efficiently without the

problem.
 Flexibility : the system able to change to suite new condition or situation

 Security: The system should be secured from unauthorized user.
 Reliability: System should be reliable to increase user’s confidence.
 Performance: The system should respond fast with high throughput
4.1.3 Definitions, acronyms, and Abbreviations

 GUI: graphical user interface
 SD : Design system
 UML: - Unified Modelling Language.
 UI:- User Interface
4.1.4 Overview
System design could be seen as the application of systems theory to product development.
In this chapter we will cover the design goal, system decomposition, system architecture,
persistence data management, access control and security, Global software control,
Boundary conditions, and Subsystem services.
56
In our system we have preferred System architecture because of the following main
advantages: -
 High Performance – the Presentation tier can cache requests, network

utilization is minimized, and the load is reduced on the Application and Data
tiers.
 High degree of flexibility in deployment platform and configuration
 Better Re-use
 Improve Data Integrity
 Improved Security – Client is not direct access to database.
4.2 Current System Architecture

Currently there is no software architecture for Web based of Pharmacy Management
System for Ambo Koo Pharmacy. The current system is a paper based system that is
outdated and unorganized. There is no full computerized system for handling the data to
delivers the information of customer as well as manages product. In order to handle or
process the data for above mentioned categories of tasks there is the manual system that is
deployed within the Excel.
Whenever the customer wants to register to the Pharmacy they came to office and register
to the manager office in manual way and then the manager keeps the queue of the applicant
and sends applicant data to them as documented in paper. Whenever each employee
generates and report on the paper and as well as to identify customer, product and status
and search to identify them.
57
4.3 Proposed System Architecture
This proposed system uses three-tier architecture. The user interface is implemented on a
desktop PC and uses a standard graphical user interface with different modules running on
the application server. The middle tiers are usually multitier.
Advantages of three-tier:-
 Managing data is independent from the physical storage
 Migration to new graphical environments is faster
 As each tier is independent it is possible to use different sets of developers
 Since the client doesn’t have direct access to the database business logic is
more secure
 When one tier fails there is no data loss, because you are always secure by
accessing the other tier
Figure 20: proposed system architecture
58
4.3.1 Subsystem decomposition
Decomposition refers to the process by which a complex problem or system is broken down
into parts that are easier to conceive, understand, program, and maintain. It results large
systems in to a set of loosely dependent parts which make up the system. To reduce the
complexity of the solution domain, we decompose a system into simpler parts, called
subsystems, which are made of a number of solution domain classes.
From the functional requirements the proposed system could consists of the following
subsystems:
 Register Subsystems:
 Register drug
 Register employee
 Manage account subsystem:
 Create account
 Delete account
 Update account
 Deleting subsystem:
 Delete drug
 Delete employee
 Selling subsystem:
 Selling drugs
 Check the availability of the drug
 Print the selled drug

59
4.3.2 Hardware/Software mapping+
I. Software architectures:
Software architectures are often used to model high-level software components and
how they interact. The interfaces between these components become clearer as the
model grows, which provides a much clearer delineation of duties of each
component. So from that point component diagrams are used to visualize the
physical components in a system. These components are libraries, packages, files
etc.
Component diagrams can also be described as a static implementation view of a

system. Static implementation represents the organization of the components at a
particular moment. It does not describe the functionality of the system but it
describes the components used to make those functionalities. A single component
diagram cannot represent the entire
System but a collection of diagrams are used to represent the whole.
II. Hardware architectures:
Hardware architectures is used to show the hardware of the system, the software that is
installed in the hardware and also the middleware that is used to connect the disparate
machines to one and other. This deployment diagram shows how the software components,
processes, and objects are deployed into the physical architecture of the system and
configuration of the hardware units. A Deployment diagram depicts a static view of the
run-time configuration of processing nodes and components that run on those nodes of our
system. And it shows: -
 The hard ware for the system

 The software that is installed on the hardware
60
 Depict the hardware/network infrastructure of an organization. The deployment
diagram is shown as follows
Client Machine Server Machine
Chrome TCP/IP XAMPP
Mozilla
internate_exp PHP
Centeral Data base
MYSQL
Figure 21: Hardware architectures diagram of system

Description of the architecture of the system is described below.
Clients are responsible for: -Provide user interface to the user enabling to get services
 Receiving inputs from user
 Checking range of performance
 Initiating database transactions once all necessary data are collected.
Server responsible for:-Transaction performance

 Guaranteeing the integrity of data.
 Putting backup of the database
4.3.3 Persistent data management

Persistence modeling is used to communicate the design of the database, usually the data
base to both the users and the developers. It is also used to describe the persistence data
aspect of the system. It is based on the concept of object that have both data and behavior.
Object technology employs concepts that are well supported by the UML such as classes,
61
inheritance, polymorphism, and encapsulation. The following diagram indicate the
persistence diagram of the system
The next diagram implies mapping with the different tables of the database that are
supposed to be found in the database of the proposed system. The implied database table
consists of different attributes with the specified primary key and the foreign keys that
create connection between them.
Figure 22 : persistence modeling
4.3.4 Access control and Security

In the system, different actors have access to different information and data. Access
control and security specifies what the user can access or what cannot perform by
some users. This access control is verified by username and password. We use login
subsystem to check username and password. The following table shows access
control of our system.
62
Actor Account
Administrator
confirm password()
change password()
Create user Account()
Manage Account()
Manager Login()
View users
Add medicine
View stoke
Pharmacist Login()
Create prescription
View prescription
Add medicine
Manage stoke
Casher Login()
Process payment
Manage payment
Table 11 : Access control and security
63
4.3.5 Global software control
The Web Based for Ambo Koo Pharmacy architecture is to have an explicit, centralized
software control. The system's dynamic control is distributed among different controllers
such that each object delegates some responsibility to other objects. The request initiations
are event-driven:
 The Manager initiates the UI Subsystem by logging into the system.

 The Main Subsystem initiates the account subsystem by gathering
information from cashier and Manager.
 The Main Subsystem initiates the employee subsystem by checking the
availability and notifying of the Response.
 The Database Subsystem can be initiated at any point by all Subsystems
except the UI Subsystem. Any request (add/update/retrieve) to the
repository initiates the Database Subsystem. The system stores its contents
in the database between executions. When the application is run again, it
retrieves the contents from the previous execution. Any change in the
contents during this execution updates the database.
4.3.6 Boundary conditions

The boundary condition includes the processes from the deployment of the system to exit
condition.
Startup: go to system URL and login
Shut Down: click log out and close browser
Error Conditions:
 Logging in:
 Username or password field can be blank.
 Password is not 8 characters long.
 Password and username don’t match.
64
 Username is wrong or does not exist.
 User settings
 User is unable to change certain settings or changes don’t reflect.
 Between the time of editing and updating, the system crashes.
 Data Entry
 The system fails when the manager is entering information.
 Product availability
 There are no available product in any.
 Monitor display
 The system crashes or the backup also crashes.
 The system hangs up.
 The desktop application may fail up.
 Relative searching for a customer or product.
 Search criteria do not return any results.
 Logging out
 Manager unable to logout.
4.4 Subsystem services
Subsystem services are services which are performed in each subsystems. Those
subsystems services are described each individually as below.
65
Chapter Five:
Implementation and Testing

5.1 Introduction
The implementation document helps users on how to work with the system. It acts as a user
manual. And it helps users not to be confused with the system. It includes sample forms
and some selected fragment code. It gives the users a brief overview of the system.
5.1.1 Final Testing of the system

This testing is conducted to provide stake holders with information about the quality of
system or services. Here we list some testing levels in association with our project.
Unit testing: -Also known as component testing, refers to tests that verify the functionality
of a specific section of code. These tests are usually written by the developers of the
modules for instance if want to check whether create account is working correctly or not.
So we only specifically test this part.
Integration testing: -Integration testing is any type of software testing that seeks to verify
the interfaces between components against a software design. Integrating testing works to
expose defects in the interfaces & interaction between integrated components (module), so
we are going to check here the quality of our interfaces.
System testing: -The system testing part of a testing methodology involves entire system
for errors & bugs. This test is carried by interfacing the hard ware & software components
of the entire system that have been previously unit tested & integration tested so we will
test our system as a whole in this testing.
Alpha testing: -This testing is implemented as a form of internal acceptance testing. So

we will let the potential customer the agency to test the system by entering the correct
input.
Beta testing: -This comes from alpha testing & can be considered as external user
acceptance testing. This is done by using versions of software known as beta versions are
66
related to a limited audience outside of the programming team. As much as we can we are
gone use this software & implement beta testing.
Usability testing: -It is to check if the user interface is easy to use and understand so we
will try to check these from user how there feedback is concerning the system.
5.1.2 Hardware software acquisitions

In order to implement and use the entire Ambo Koo Pharmacy Management system,
different hardware and software are required as it was described in ‘Hardware and Software
requirement’ in chapter one. Any user who is intended to use this system must have the
following hardware and software to implement and use the complete system.
For the System implementation the following software’s are used:-
 Printer: For printing Documentation
 Computers(lab computers and personal computer)
 Microsoft word: for prepared documentation
 Power point: for presentation
For the System implementation the following software’s are used.

 Microsoft office Visio: for UML diagram drawing.
 Browser for running code
 XAMPP (Apache, MySQL and PHP server).
67
5.1.3 User manual preparation
Since the system is web based everything important for the user will be explained and
implemented while giving short training when the system is deployed. Rather there is no
need of preparing full user manual because it is only deployed (hosted) on a single machine
that is server.
User Interface for Home Page
Figure 23: User Interface Home Page
68
User Interface for Login Page
Figure 24:User Interface Login Page
5.2 Training
During the deployment of the system, the project group members will give short time
training for the system administrators explaining how the system works and in what way
they can manage their system.
5.3 Installation Process

Since the project is web based System, there is no need to install it on a particular machine
rather it will be hosted on a server.
5.4 Start-up strategy

Once the system is hosted, it has two parts: One which needs password and username that
is for Admin, manager, pharmacist and casher. To access those parts one has to have
69
password and user name so that he/she can enter into it and use it. This accessibility has
also two parts, one which is restricted for manager and the other for surveyor and the other
part is those which do not need pass word and username so they can be viewed by anybody
70
Chapter Six:
Conclusions and Recommendation

6.1 Conclusions
It is known that developing a system for an organization is not easy. But the team has tried its
best and developed interesting web based pharmacy management system for Ambo Koo
pharmacy. It is flexible, accurate and attractive with easy GUI approach. Generally, the team
confidently can say that the software is completed successfully with negligible errors. Finally
the team expects the software will change the general the manual system in to web based
pharmacy management system of the Organization and makes it more reliable and efficient than
the previous manual system.
6.2 Recommendations
While doing this system the team has faced different challenges. But by the cooperation of
all the group members and an advisor the team is now able to reach to the final result. I.e.
all the group members strongly fought these challenge and take the turn to the front.
So now all the group members strongly recommend the department that for the coming
students, it has to provide them with better service than the present in better hard ware,
guaranteed software’s, giving orientations how to proceed, offering guest to provide them
with more experienced work, support morally, manually, forming good relation with
students, giving students description of each phases and so on. So that it will get what it
expects from its students and satisfy with them.
71
Reference
 The unified modelling language user guide G.Booch, J.Rumbaugh, and I.Jacobon,
Addison-Wesley, 1999
 Ambler, The Object Primer:Introduction to Techniques for Agile Modeling, June 22, 2001
 Rumbaugh, J., Jacobson, I., & Booch, G. (1999). The Unified Modelling Language
Reference. Reading, MA: Addison-
 Wesley Longman. [Fowler00] Fowler, M., UML Distilled: A Brief Guide to the Standard
Object Modelling Language, Chapters 8, 9. Addison Wesley.
 Rosenberg, D., & Scott, K. (1999). Use Case Driven Object Modelling With UML: A
Practical Approach. Reading, MA: Addison
72

Ambo Koo Chapter All DocPDF

Uploaded by

Document Information

Original Description:

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

Ambo Koo Chapter All DocPDF

Uploaded by

Copyright:

Available Formats

AMBO UNIVERSITY

Title:-Web Based For Ambo Koo Pharmacy Management System

Usman Abdulaziz BRT/2174/08

Yusuf Abdela BRT/2176/08

Abrahim Umar BRT/2109/08

Dule Merga RIOT/1553/07

Dinka Tamru BRT/2210/08

Chaltu Tefari BRT/2199/08

Tsagenash Fikadu BRT/2321/08

ADVISOR: Mr. Haftom B June 2019

Yusuf Abdela ____________ ____________

Abrahim Umar ____________ ____________

Dule Merga ____________ ____________

Dinka Tamru ____________ ____________

Chaltu Tefari ____________ ____________

Tsagenash Fikadu ____________ ____________

Name and Signature of Member of the Examining Board

Name Title Signature Date

____________ Coordinator, ____________ ____________

Mr. Haftom B Advisor, ____________ ____________

____________ Examine, ____________ ____________

____________ Examine ____________ ____________

AMBO KOO PHARMACY MANAGEMENT SYSTEM DEPARTMENT OF COMPUTER SCIENCE 2019

Name Signature Date

Yusuf Abdela ____________ ____________

Abrahim Umar ____________ ____________

Dule Merga ____________ ____________

Dinka Tamru ____________ ____________

Chaltu Tefari ____________ ____________

Tsagenash Fikadu ____________ ____________

Mr. Haftom B ____________ ____________

AMBO KOO PHARMACY MANAGEMENT SYSTEM DEPARTMENT OF COMPUTER SCIENCE 2019

AMBO KOO PHARMACY MANAGEMENT SYSTEM DEPARTMENT OF COMPUTER SCIENCE 2019

AMBO KOO PHARMACY MANAGEMENT SYSTEM DEPARTMENT OF COMPUTER SCIENCE 2019

AMBO KOO PHARMACY MANAGEMENT SYSTEM DEPARTMENT OF COMPUTER SCIENCE 2019

AMBO KOO PHARMACY MANAGEMENT SYSTEM DEPARTMENT OF COMPUTER SCIENCE 2019

AMBO KOO PHARMACY MANAGEMENT SYSTEM DEPARTMENT OF COMPUTER SCIENCE 2019

AMBO KOO PHARMACY MANAGEMENT SYSTEM DEPARTMENT OF COMPUTER SCIENCE 2019

AMBO KOO PHARMACY MANAGEMENT SYSTEM DEPARTMENT OF COMPUTER SCIENCE 2019

1.2 Organizational Back ground

1.2.1 Vision of the organization

AMBO KOO PHARMACY MANAGEMENT SYSTEM DEPARTMENT OF COMPUTER SCIENCE 2019

1.3 Background of the project

1.4 Statement of the Problem

AMBO KOO PHARMACY MANAGEMENT SYSTEM DEPARTMENT OF COMPUTER SCIENCE 2019

1.5 Objective of the project

1.5.2 Specific objective

 Previous System analysis.

1.6 Scope of the project

AMBO KOO PHARMACY MANAGEMENT SYSTEM DEPARTMENT OF COMPUTER SCIENCE 2019

 Better Stock Management.

1.7.1 Target Beneficiaries of the system

 To the system developing team members

1.8 Methodology for the project

AMBO KOO PHARMACY MANAGEMENT SYSTEM DEPARTMENT OF COMPUTER SCIENCE 2019

1.8.1 Data Source

AMBO KOO PHARMACY MANAGEMENT SYSTEM DEPARTMENT OF COMPUTER SCIENCE 2019

1.8.2 Fact Finding Techniques

1.8.3 Systems Analysis and Design (approach)

AMBO KOO PHARMACY MANAGEMENT SYSTEM DEPARTMENT OF COMPUTER SCIENCE 2019

 XAMPP Server 2012

 16GB Flash disk

1.8.5 Testing procedures

Yusuf Abdela

Abrahim Umar

Dule Merga

Dinka Tamru

Chaltu Tefari

Tsagenash Fikadu

Coordinator,

Mr. Haftom B Advisor,

Examine,

Examine

Yusuf Abdela

Abrahim Umar

Dule Merga

Dinka Tamru

Chaltu Tefari

Tsagenash Fikadu

Mr. Haftom B