Pharmacy Management System Thesis | Chapter 3 – Methodology
This chapter, I discuss the Pharmacy Management System Thesis | Chapter 3 – Methodology design, , , Use Case Model, , Context Diagram, Data Flow Diagram and Entity Relationship Diagram.
Here’s the Outline of Pharmacy Management System Thesis | Chapter 3- Methodology
Pharmacy Management System Thesis | Chapter 3
- Use Case Model
- Buy Product Use Case Description of DLT Pharmacy-Payroll Management System
- Process Transaction Use Case Description of DLT Pharmacy-Payroll Management System.
- Context Diagram
- Data Flow Diagram
- Entity Relationship Diagram
- Data Dictionaries
- Architectural Diagram
- Screen Design
- System Requirements
- Hardware Requirements
This Pharmacy Management System Thesis | Chapter 3 – Methodology presents the system design of the proponent’s system.
Figure 1 Shows Extreme Programming the Diagram used by the proponents as their model for the system. It shows how Extreme Programming’s rules work together. A preference for effective action based on other principles so that the results aren’t harmful to the team. Extreme Programming is a software development framework that aims to produce higher quality software, and higher quality of life for the development team. XP stresses the importance of the appropriate kind of communication that is face to face discussion with the aid of a white board or other drawing mechanism. The diagram shows the team sport that relies on communication to transfer knowledge from one team member to everyone else on the team. The advantage of XP model from the other methodologies avoid waste and do only absolutely necessary things such as keep the design of the system as simple as possible so that it is easier to maintain, support, and revise.
In this phase, the proponents used Release Plan meeting to create a release plan, which lays out the overall project for DLT Pharmacy. They will commit themselves to the functionality that will be included and the date of the next release.
The proponents plans the activities and tasks of the developers and decides what content goes into specific iterations. The tasks will be assigned to the proponents and the time it takes to complete will be estimated. The proponents plan by selecting Stories from the team backlog and committing to execute a set of them in the upcoming iteration. The proponent’s backlog has been seeded and partially planned during the Program Increment (PI) Planning meeting. In addition, the Proponent have feedback not only from their prior iterations but from the System Demo and other proponents. That, and the natural course of changing fact patterns, provides the broader context for iteration planning.
The Proponent use acceptance tests as a complement to specification documents containing uses cases or more narrative text. Proponents write as many automated tests as much as possible, and if all of them prove to be successful, then the coding is regarded to be complete. Besides, every piece of code which is written is tested thoroughly before going ahead with the next feature. Acceptance testing is done to ascertain that the programmers understand the requirements and in turn can satisfy the actual requirements of DLT Pharmacy.
Stand Up Meeting
The Proponent report at least three things; what was accomplished yesterday, what will be attempted today, and what problems are causing delays.
The Proponent combine two sets of skills for design and implementation to yield the best solution.
The Proponent take a bit of time to test virtually every line of code when it is written, what is the probability of missing a defect at that point. Proponent do unit testing, they tend to find defects much earlier, resulting in a more cost effective way to eliminate defects.
The Two Proponent working together at a single computer. Effectively get a continuous code review and quicker response to nagging problems that may stop one person dead in their tracks. Proponents used pair programming to improve quality and does not actually take twice as long because they are able to work through problems quicker and they stay more focused on the task at hand, thereby creating less code to accomplish the same thing.
Each pair of proponent writes their code and then integrates it together. The development team has a collective code ownership. Each proponent can change or refactor any part of the code. It ensures that no one developer becomes a bottleneck for changes and it allows proponents to reuse any functionality that might be required by multiple user stories.
Use Case Model
Figure 2 shows the use case of DLT Pharmacy-Payroll Management System and the task of every actors of the system Buy Product
Figure 3 This use case diagram is more like to purchased products. An interaction between customer and sales clerk.
Table 2: Buy Product Use Case Description of DLT Pharmacy-Payroll Management System
Figure 4 This use case diagram includes systems that manage sales order entry processed by the sales clerk and forwarded to cashier who applies the payment to the account/invoice.
Table 3: Process Transaction Use Case Description of DLT Pharmacy-Payroll Management System.
|Use Case Name:||Process Transaction|
|Description:||The cashier process the customer’s order|
|Pre-conditions:||Cashier is identified and authenticated|
|Post-conditions:||Cashier receive payment and create invoice|
|Normal Flow:||1.Cashier receive list of ordered product||1.1 System input ordered product details|
|2.Cashier receive payment||2.1 System calculates total amount|
|2.1 System Print Receipt|
|Alternative Flows:||1.2 System displays the state of the resumed sale, with subtotal|
|Business Rules:||1.2 Cashier calculate total amount and print receipt|
|Use Case Name:||Generate Report|
|Description:||This use case describes the event of creating a report based on the information collected by the system|
|Pre-conditions:||Manager authorized to access database|
|Post-conditions:||Report from the database is generated|
|1. Manager gets access to the database||3.1 Manager selects system information for report Ensure that the available sale product performance|
|2. Manager selects information to generate the report||4.1 Manager opts for system performance report|
|Normal Flow:||3. Manager selects information of transactions for report||5.1 Performance report generated|
|4. Report generated on the basis of the information in the database|
|5. Manager issues new tag for the new transaction|
|Alternative Flows:||If there is no document containing valuable information|
|Business Rules:||Nothing to view|
|Use Case Name:||Manage Payroll|
|Description:||The use case allows the manager to create total hours worked and pay year-to-date report.|
|Pre-conditions:||The manager must be logged onto the system in order for this use case to begin.|
|Post-conditions:||The system state is unchanged by this use case.|
|1. The manager requests that the system create an administrative report.||1.1 The system request that the payroll manager specify the following report criteria. -Report Type (either total hours work or pay year-to-date). -Begin and End dates for the report, -Employee names|
|2. The manager provides the requested information||2.1 System provides the manager with a report satisfying the report criteria.|
|Normal Flow:||3. The manager may then request that the system save the report||3.1 The systems request the manager to provide a name and location for saving the report.|
|4. The Manager provides the requested information and confirms the decision to save the report||4.1The system save the report to the specified name and location.|
|5. If the manager did not elect to save the report, the report is discarded|
|Alternative Flows:||1.1 If in the basic flow, the requested information is unavailable, the system will an error message. The manager can choose to either return to the beginning of the basic flow or cancel the operation at which point the use case ends.|
|Business Rules:||1.2 Manager utilizes and provides various forms of effective dating, deduction amounts, payroll deduction standardized codes, and deduction method to determine an employee’s payroll deduction premium.|
The Figure 8 Activity for Cashier generate report shows the report generation process after the report has been submitted to run.
The context diagram of DLT Pharmacy-Payroll Management System represented below shows the flow of the system throughout the system process. It show what information could be input, where the data goes, and how it is stored .
The Figure 9 DLT Pharmacy-Payroll Management System Context Diagram
Show the product purchased, process transaction, manage inventory and manage
DATA FLOW DIAGRAM
Data Flow Diagram of proposed solution shows all the concept and flows of each entity that shows all the process in proposed system solution showing this flow may help to the reader for identity which the process begins. It often used as a preliminary step to create an overview of pharmacy without going into great detail, which can later be elaborated. It normally consist of overall application dataflow and processes of the pharmacy process. It contains all of the user flow and their entities such as all the flows of pharmacy
The Figure 10 Level 1 Data Flow Diagram of Pharmacy-Payroll Management System shows customer the order and payment received by the sales clerk.
The Figure 11 Level 1 Data Flow Diagram of Pharmacy-Payroll Management System shows the product has been processed.
The Figure 12 Level 1 Data Flow Diagram of Pharmacy-Payroll Management System Shows the order and inventory of product in the pharmacy
The Figure 13 Payroll Data Flow Diagram of Pharmacy-Payroll Management
System shows the time worked calculated payroll and the pay of employee.
ENTITY RELATIONSHIP DIAGRAM
The Entity Relationship Diagram of Pharmacy-Payroll Management System shows the relationship of entity sets stored in a database. It indicates the logical structures of each database.
Figure 14 Shows the relationship of entity sets stored in a database of DLT Pharmacy-Payroll Management System.
These tables below provide the entire database tables details such as Field Name, Descriptions, data types, character lengths.
Table 6: Table Customer
|CIDNO (PK)||Customer Id Number||Int||11|
|CFIRSTNAME||Customer First Name||Varchar||90|
|CLASTNAME||Customer Last Name||Varchar||90|
|CCONTACTNO||Customer Contact Number||Varchar||11|
Table 6 This table shows the attributes of entity of Customer
Table 7: Table User
|EMPID (PK)||Employee Id||Int||11|
|EMPPHONENO||Employee Phone Number||Varchar||30|
Table 7 This table shows the attributes of entity of User
Table 8: Table Supplier
|SIDNO (PK)||Supplier Id Number||Int||11|
|SCONTACTPERSON||Supplier Contact Number||Varchar||90|
|SCONTACTNO||Supplier Contact Number||Varchar||90|
Table 8 This table shows the attributes of entity of Supplier
Table 9: Table Items
|ITEMID (PK)||Item Id||Int||11|
|IBRANDNAME||Item Brand Name||Varchar||90|
|SIDNO||Supplier Id Number||Int||11|
|CID||Customer Id Number||Int||11|
Table 9 This table shows the attributes of entity of Items
Table 10: Table Category
|CATID (PK)||Category Id||Int||11|
Table 10 This table shows the attributes of entity of Category
Table 11: Table Auto Number
|AUTOCODE (PK)||Auto Code||Varchar||30|
Table 11 This table shows the attributes of entity of Auto Number
Table 12: Table Generic
|GID (PK)||Generic Id||Int||11|
Table 12 This table shows the attributes of entity of Generic
Table 13: Table Shelves
|SHID (PK)||Shelves Id||Int||11|
Table 13 This table shows the attributes of entity of Shelves
Table 14: Table Transaction
|TRANSID (PK)||Transaction Id||Int||11|
Table 14 This table shows the attributes of entity of Transaction
Table 15: Table Employee
|EPID (PK)||Employee Id||Int||11|
Table 14 This table shows the attributes of entity of Employee
Table 16: Table Salary
|SALARYID (PK)||Salary Id||Int||11|
|EMPID (FK)||Employee Id||Int||11|
Table 16 This table shows the attributes of entity of Salary
Table 17: Table Payroll
|PAYROLLID (PK)||Payroll Id||Int||11|
|EMPID (FK)||Employee Id||Int||11|
Table 17 This table shows the attributes of entity of Payroll
Table 18: Table Deduction
|DEDUCTIONID (PK)||Deduction Id||Int||11|
|EMPID (FK)||Employee Id||Int||11|
Table 18 This table shows the attributes of entity of Deduction
Architectural diagram of DLT Pharmacy-Payroll Management System. The manager will be the admin that will manage to add staff and products, update and delete records for the database after adding the staff. Cashier will manage his unit for the sales; he will record all the sales report and store it in the database to generate report to the manager for the printing.
The figure 16 Main Dashboard shows the main interface design of the system.
List of Category
The figure 17 List of Category shows the interface design which display the category name of the product.
List of Generic
The figure 18 List of Generic shows the interface design which display the Generic name of the product.
List of shelves
The figure 19 List of Shelves shows the interface design which displays the shelves name of the product.
List of User
The figure 20 List of User shows the interface design which display the employee name.
List of Supplier
The figure 21 List of Supplier shows the interface design which display the name and details of the supplier.
List of Item
The figure 22 List of Item shows the interface design which displays the name of the product.
List of Customer
The figure 23 List of Customer shows the interface design which display the name and details of the customer.
List of Transaction
The figure 24 List of Transaction shows the interface design which display details of the transaction.
Point of Sale
The figure 25 Point of sale shows the interface design which display the cashiering and details of every transaction
Developing “DLT Pharmacy-Payroll Management System ” is not an easy task. It all started from the requirement gathering and passes through so many other stages before it will be implemented.
Based on the benefits of this system and tremendous value it will add to customer-user satisfaction, the below recommendation will be considered;
It is recommended that the new system should be used with the necessary specifications of the system requirements and provision for an uninterrupted power supply should be made available throughout the hours of operation of the pharmacy to avoid power outage. There should also be basic computer knowledge for the users of the developed system.
The following is the list of hardware and software that was used in the development and the recommended software and hardware for deployment for the system to run smoothly. (Pharmacy Management System Thesis | Chapter 3 – Methodology)
Recommended Hardware Requirement for Development:
Processor: Intel® Celeron® CPU N3060 @ 1.60GHz 1.60GHz
RAM: 4GB DDR4 2133Mhz
OS: Windows 10
System Type: 64 bit operating system , x64-based processor
Mouse 2 button with scroll
Laptop LCD 14”
Software Requirement for Development:
XAMPP v3.2.2 (32/64-bit)
VB. NET 201
Download the Full Source Code of this project
Here’s the complete Source code Pharmacy management System project
if you have any questions or suggestions about Pharmacy Management System Thesis | Chapter 3 – Methodology, please let’s me know by dropping your comment below.
1 thought on “Pharmacy Management System Thesis | Chapter 3 – Methodology”
woow such an interesting project . i would love to use it for my project , can i get any tutorials or guidance on it.thanks