Online Delivery Design and Methodology Documentation Chapter 3

Online Medicine Delivery System Documentation

This Online Delivery Design and Methodology Documentation presents the system design of the proponent’s system. The Software Development Life Cycle (SDLC) is a framework defining tasks performed at each step in the software development process. It is a structure followed by a development team with in the software organization.

It consists of a detailed plan describing how to develop, maintain and replace the specific software. The life cycle defines the methodology for improving the quality of the software and over all development process. The proponents will use the Rational Unified Process Methodology as a guide of processing the system flow.

EXTREME PROGRAMMING METHODOLOGY

Figure 1: Extreme Programming Methodology

            Figure 1: Shows Extreme Programming theDiagram 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.

Release Plan

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.

Iteration Plan

            The proponent 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 has 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.

Acceptance Test

            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.

Pair Negotiation

            The Proponent combines two sets of skills for design and implementation to yield the best solution.

Unit Test

            The Proponent takes 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.

Pair Programming

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. Proponent 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.

Code

            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 Diagram of Online Delivery Design and Methodology Documentation

     The use case diagram showed the user’s interaction with the system and its relationship between different use cases and the users involved.

Online Medicine Delivery System with SMS notification

Figure 2. Online Medicine Delivery Use Case Diagram with SMS Notification. 

Figure 2 Showed the major task that the actor must be done to implement the system. As the figure showed, Admin could manage user account and reports, And Employee were responsible for delivery.

Figure 3. Manage Order Use Case Diagram

This use case diagram is more like to purchased products online.

Table 2: Manage Order Use Case Description

Manage Order

Manage Delivery

Figure 4. Manage Delivery Use Case Diagram  

       This use case diagram includes systems that manage delivery entry processed by the Rider and forwarded to Customer who order the product.

Table 3: Manage Delivery Use Case Description    

Manage Delivery

Manage Rider

Figure 5. Manage Rider Use Case Diagram

      This use case diagram includes systems that manage the rider to assign at any location to deliver products.

Table 4: Manage Rider Use Case Description            

Manage Product

Figure 6. Manage Product Use Case Diagram

Table 5: Manage Product Use Case Description              

Activity Diagram for Online Delivery Design and Methodology Documentation

     The activity diagram showed the flow of Online Medicine Delivery System with SMS Notification.

       This use case diagram includes systems that manage Product entry processed by Admin.

Admin Activity Diagram

Figure 7. Admin Activity Diagram

Shows the steps of admin create user details.

Customer Activity Diagram

Figure 8. Customer Activity Diagram    

Showed the steps of customer ordering medicine via online for delivery process that includes the recognition of needs and wants.

Rider Activity Diagram

Figure 9. Rider Activity Diagram

Showed the process of delivery product upon receiving order of customer.

Functional Decomposition Diagram

     The Decomposition Chart showed the breakdown process and its sub-processes of the whole system.

Figure 10. Functional Decomposition Diagram 

Figure 10 showed the breakdown and its sub-processes of the develop system. Every process was being labeled and marked to equate the functionality of the whole system.

CONTEXT DIAGRAM of Online Medicine Delivery Documentation

The context diagram of Online Medicine Delivery System represented below shows the flow of the system throughout the system process. It shows what information could be input, where the data goes and how it is stored.

Figure 11. Context Diagram of the proposed System

     Shows the general process of the develop system. It demonstrated the delivery information needed of the customer.

Online Delivery Design and Methodology Documentation Data Flow Diagram

     Data flow Diagram of Proposed Solution showed the concept and flows of each entity, it showed the processes of the proposed system. Through this flow, the reader could easily identify which process which process to begin with.

Figure 12: Data Flow Diagram of Online Medicine Delivery System with SMS Notification

Showed the entire data flow, the processes, input requirements, processed output and the storage of the developed system.

Entity Relationship Diagram

Figure 13: Entity Relationship Diagram of Online Medicine Delivery System with SMS Notification

     Showed the connection of all tables in the database. Each table required specific information in order for the system works.

Data Dictionaries Online Delivery Design and Methodology Documentation

     These tables below provide the entire database tables details such as Field Name, Descriptions, data types, character lengths.

Table 6: Table Messagein

Field NameDescriptionTypeLength
Id (PK)Id NumberInt11
SendTimeSend TimeDatetime 
ReceiveTimeReceive TimeDatetime 
MessageFromMessage FromVarchar80
MessageTo Message ToVarchar80
SMCSSMCSVarchar80
MessageTextMessage TextText 
MessageTypeMessage TypeVarchar80
MessagePartsMessage PartsInt11
MessagePDU Message PDUText 
Gateway GatewayVarchar80
UserIdUser IdVarchar80

Table 6: This table show the attributes of entity of Messagein

Table 7: Table Messagelog

Field NameDescriptionTypeLength
Id (PK)           IdInt11
SendTimeSendTimedatetime 
ReceiveTimeReceive Timedatetime 
StatuCodeStatus CodeInt11
StatusText Status TextVarchar80
MessageToMessage ToVarchar80
MessageFromMessage FromVarchar80
MessageTextMessage TextText 
MessageTypeMessage TypeVarchar80
MessageIdMessage IdVarchar80
ErrorCodeError CodeVarchar80
ErrorTextError TextVarchar80
GatewayGatewayVarchar80
MessagePartsMessage PartsInt11
MessagePDUMessage PDUText 
ConnectorConnectorVarchar80
UserIdUser IdVarchar80
UserInfoUser InfoText 

Table 7: This table show the attributes of entity of Messagelog

Table 8: Table Messageout

Field NameDescriptionTypeLength
Id (PK)IdInt11
MessageToMessageToVarchar80
MessageFromMessageFromVarchar80
MessageTextMessageTextText 
MessageTypeMessageTypeVarchar80
GatewayGatewayVarchar80
UserIdUserIdVarchar80
UserInfoUserinfoText 
PriorityPriorityInt11
ScheduledScheduledatetime 
ValidityPeriodValidityPeriodInt11
IsSentIsSentTinyint1
IsReadMessageout IsReadTinyint1

Table 8: This table show the attributes of entity of Messageout

Table 9: Table tblautonumber

Field NameDescriptionTypeLength
ID (PK)IDInt11
AUTOSTARTAUTOSTARTVarchar80
AUTOINCAUTOINCInt11
AUTOENDAUTOENDInt11
AUTOKEYAUTOKEYVarchar12
AUTONUMAUTONUMInt11

Table 9: This table show the attributes of entity of tblautonumber

Table 10: Table tblcategory

Field NameDescriptionTypeLength
CATEGID (PK)Category IdInt11
CATEGORIESCategory nameVarchar80
USERIDuseridInt11

Table 10: This table show the attributes of entity of tblcategory

Table 11: Table tblcustomer

Field NameDescriptionTypeLength
CUSTOMERID (PK)    customer idInt11
FNAMEcustomer first nameVarchar30
MNAMEcustomer middle nameVarchar30
LNAMEcustomer last nameVarchar30
HOMEADDRESScustomer home addressText          
DELADDRESScustomer delivery addressText 
GENDERcustomer genderVarchar10
PHONEcustomer contact numberVarchar20
CUSUNAMEcustomer usernameVarchar20
CUSPASScustomer passwordVarchar90
TERMScustomer termstinyint4
DATEJOINcustomer date joindate 

Table 11: This table show the attributes of entity of tblcustomer

Table 12: Table tbllocation

Field NameDescriptionTypeLength
LOCID (PK)Location IdInt11
PLACEMunicipality/cityVarchar90
BRGYbarangayVarchar90
DELPRICEDelivery pricedouble 

Table 12: This table show the attributes of entity of tbllocation

Table 13: Table tblorder

Field NameDescriptionTypeLength
ORDERID (PK)Order  IdInt11
PRODProduct NameInt11
ORDEREDQTYOrdered quantityInt11
ORDEREDPRICEOrdered pricedouble 
ORDEREDNUMOrdered numberInt11
CUSTOMERIDCustomer idInt11
EMPIDEmployee idInt11
PRESCRIBEDQTYPrescribed quantityInt3

Table 13: This table show the attributes of entity of tblorder

Table 14: Table tblproduct

Field NameDescriptionTypeLength
PRODID (PK)Product IdInt11
PRONAMEProduct nameVarchar80
PRODESCProduct descriptionText 
PROQTYProduct quantityInt11
ORIGINALPRICEProduct original priceDouble 
PROPRICEProduct priceDouble 
CATEGIDProduct category idInt11
IMAGESProduct imagesVarchar80
PROSTATSProduct statusVarchar80

Table 14: This table show the attributes of entity of tblproduct

Table 15: Table tblemployee

Field NameDescriptionTypeLength
EMPID (PK)Employee IdInt11
LNAMEEmployee last nameVarchar80
MNAME         Employee  middle nameVarchar80
FNAMEEmployee first nameVarchar80
DOBEmployee BirthdayDate          
AGEEmployee ageInt11
SEXEmployee genderVarchar80
ADDRESSEmployee addressText 
EMAILEmployee emailVarchar80
PASSWORDEmployee passwordVarchar80
CONTACTEmployee contact numberVarchar11
IMAGEEmployee imageText90
Total_deliveredEmployee total deliveredInt30

Table 15: This table show the attributes of entity of tblemployee

Table 16: Table tblsummary

Field NameDescriptionTypeLength
SUMMARYID  (PK)Summary IdInt11
ORDEREDDATE (FK)   Ordered dateDate/Time 
CUSTOMERIDCustomer idInt11
IMAGEProduct imageVarchar80
ORDEREDNUMOrdered numberInt11
DELFEEDelivery feeDouble 
PAYMENTPaymentDouble 
PAYMENTMETHODPayment methodVarchar80
ORDEREDSTATSOrdered statusVarchar80
ORDEREDREMARKSOrdered remarksVarchar80
CLAIMEDDATEClaimed dateDate/Time 
EMPIDEmployee idInt11
USERIDUser idInt11

Table 16: This table show the attributes of entity of tblsummary

Table 17: Table tbluseraccount

Field NameDescriptionTypeLength
USERID (PK)User IdInt11
U_NAME (FK)User nameVarchar80
U_USERNAME     User usernameVarchar80
U_PASSUser passwordVarchar80
U_ROLEUser roleVarchar80
USERIMAGEUser imageVarchar80

Table 17: This table show the attributes of entity of tbluseraccount

Table 18: Table tblwishlist

Field NameDescriptionTypeLength
id (PK)Wishlist IdInt11
CUSID (FK) Customer IdInt11
PROIDProduct idInt11
WISHDATEWishlist datedate 
WISHSTATSWishlist statustext 

Table 18: This table show the attributes of entity of tblwishlist.

System Screen Layout

The screen layout of “Online Medicine Delivery System with SMS Notification”.

Customer Side Interface

This picture shows the interface of Customer Side Home

Figure 14: Screen Design for Client Side Home

Category Interface

This picture shows the interface of Category

Figure 15: Screen Design for Category Interface

Medicine Interface

This picture shows the interface of medicine

Figure 16: Screen Design of Medicine Interface

Add to Cart

This picture shows the interface of Add to Cart

Figure 17: Screen Design for Add to Cart

Submit Order

This picture shows the interface of Submit Order

Figure 18: Screen Design for Submit Order

List of Orders

This picture shows the interface of List of Orders

Figure 19: Screen Design for List of Orders

Admin Side Interface

List of Employee

This picture shows the interface of List of employee

Figure 20: Screen Design for List of Employee

Add Employee

This picture shows the interface of List of employee

Figure 21: Screen Design for Add Employee

Update Employee

This picture shows the interface of Update of Employee

Figure 22: Screen Design for Update Employee

List of Products

This picture shows the interface of List of products

Figure 23: Screen Design for List of Products

Add New Product

This picture shows the interface of Add New Product

Figure 24: Screen Design for Add New Products

Update Product

This picture shows the interface of Update Product

Figure 25: Screen Design for Update Products

List of Orders

This picture shows the interface of List of Orders

Figure 26: Screen Design for List of Orders

List of Categories

This picture shows the interface of List of Categories

Figure 27: Screen Design for List Of Categories

Add New Category

This picture shows the interface of Add New Category

Figure 28: Screen Design for Add New Category

List of User

This picture shows the interface of List of Users

Figure 29: Screen Design for List of User

Add New User

This picture shows the interface of Add New Users

Figure 30: Screen Design for Add New User

Report

This picture shows the interface of List of Report

Figure 31: Screen Design for Reports

Commission

This picture shows the interface of List Commission

Figure 32: Screen Design for Commission

Rider Side Interface

This picture shows the interface of Rider side

Figure 33: Screen Design for Rider Side Interface

ARCHITECTURAL DIAGRAM of Online Delivery Design and Methodology Documentation

Figure 34: Architectural Diagram

System Requirements of Thesis Project Online Medicine Delivery System

     Developing “Online Medicine Delivery System with SMS Notification” 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.

Hardware Requirements

Recommended Hardware Requirement for Development:

Computer Intel Core i5 7th Generation Processor

Hard Disk: 240GB SSD SanDisk Plus

RAM: 4GB DDR4 2133Mhz

Intel HD Graphics 620mx

NVIDIA GeForce 940MX 2GB

Mouse 2 button with scroll

Laptop LCD 14”

Keyboard

Software Requirements

Software Requirement for Development:

HeidiSQL v9.5.0.5273 (64-bit)

Sublime 3.0 (32/64-bit)

XAMPP v3.2.2 (32/64-bit)

Framework Codeigniter v3.1.5

Google Chrome v69.0.3497.100 (Official Build) (64-bit)

Online Delivery Design and Methodology Documentation Gantt Chart

     The Gantt Chart assesses the proponents with the project management throughout the whole Process. It caters of how long the process will take that allow time management effectively. The minimum delivery time of this Online Medicine Delivery Documentation was being figure out means of Gantt chart.

Figure 35: Gantt chart

Conclusion

This Thesis Project Online Medicine Delivery System is for students in order for them to have an idea on what to write in their own Chapter 3 Methodology.

Feel free to leave your comments down below. For other great articles, click the links below.

2 thoughts on “Online Delivery Design and Methodology Documentation Chapter 3”

  1. This app has a user friendly interface. It has really great service of quick delivery. All the prices are affordable and there are regular discounts on the medicines so that i doesn’t face any type of difficulty in purchasing the required medications.

Leave a Comment