You are on page 1of 156

CHAPTER 1.

0 - PROJECT CHARTER
1.1

PROJECT BACKGROUND
POS, abbreviation for Point- of- Sale is a comprehensive definition that
can include merchandising benefits, displays and the procedures used to
facilitate transactions. A POS system is a computer software and hardware
system that archives sales as they occur; it solves diverse problems of
operations and record-keeping.
POS systems are designed to record any and all sales. Not only does
that mean timely and precise sales tracking, but it also lets you freely classify
inventory levels, particularly when there is a mismatch of figures in the system
with actual available stock.
POS system not only lets you regulate your transactions, but it also
puts a wealth of information. Imagine being able to compare years of sales
data with just a few mouse-clicks. A POS system can also track inventory,
even modifying quantities for seasonal demands. In a nutshell, a POS system
aids to keep a constant eye on bottom line.
POS is used primarily for managing retail goods. It is used for stores,
restaurants, hospitals and other forms of business that transact the goods or
products purchased by a customer or consumer from a cashier. Maybe the
most traditional use is in the stores, focusing on merchandising.
A check-out counter is at the aisle where people place items that they
have chosen to purchase from a store, such as supermarket or department
store. The cashier rings up each item on the cash register and obtains the
total. The items are placed in bags and the customer can take them after
paying. POS system calculates the total cost of purchased products or goods
by means of scanners, weighing scales, electronic and manual cash registers,
touch screens and other wide variety of hardware and software available that
is used in POS. At the end of every transaction, a receipt will be generated,

Point- of- Sales with Price Management Module

having the purchase report. Sales report is also produced to monitor and
manage business. The system provides the capabilities to carry out
transactions and conduct daily store activities such as scanning items,
applying price adjustments, tendering, and printing receipts.
Scoping with Price Management, it is used in dealing with monitoring of
the overall price of products, creating product price, updating price, printing
tags, and implementing it. The management will be the one to decide the
prices of the products. Price Management defined as the process of
integrating all perspectives and information necessary, to arrive consistently at
optimal pricing decisions.
1.1.1 Problem/ Opportunity Description

Primitive way of computing purchased products


It will take time when a cashier computes the purchase
products of customer only by using standalone cash registers.
Also, discrepancies of information are possible because the old
process of paying purchased products has limited features; this
primitive way of transaction is already outdated and doesnt
meet good customer services.

Unsecured information of transaction in manual process


The cashier only uses a standalone cash register to
compute transactions and purchases of customers and there is a
big possibility that the file copies of receipts can be misplaced.
Manual operations cannot get information of all transactions
rapidly because compiling is only done manually through writing
and typing in a pc. Hence, it is not secured from any unexpected
circumstances.

Point- of- Sales with Price Management Module

An old way of managing price of products


Price of a product cannot be updated easily in manual
process when theres a price change, discounts and sales.
Addition is the confusion in putting price tags depends on the
categories. Hence, that causes discrepancies not just in the
transaction when a customer purchases, but also in the sales
and inventory.

Insufficient information of receipts and obsolete way of creating


price tags
Specific descriptions of product in receipts are not
available in primitive cash registers. These include taxable
items, specialized discounts and product names. Primitive cash
registers only give limited information of the transaction and
other information cannot be overviewed accordingly.
Primitive Merchandising Stores only use gun taggers on
pricing their products. Indeed, price of a specific product is only
included at the stock- keeping unit. Hence, determining

the

product name is quite confusing in manual process without


proper stock keeping unit. Additional are the price tags of sales
are not properly implemented.

Improper management of void products on the counter


Products that have been voided dont have proper
management resulting in discrepancies of the inventory
because these products are not sold.

No holding of transactions in primitive process


Repeating of transactions of customers that are about to
pay at the cashier and went back to the store to get the

Point- of- Sales with Price Management Module

products that theyve forgotten or paused their transactions due


to some reasons are not possible. Thus, the customer will fall in
line again to repeat the transaction purchase process.

Hanging POS systems in automated process


Merchandises

that

use

automated

POS

systems

sometimes experienced hanging on their systems at the middle


of transactions. Worse, leads the unit to shut down and lose the
current transaction.
1.1.2 Benefits

Transaction enabled
The cashier who is about to use the proposed Point- ofSales with Price Management Module can be able to create
automated transactions with the products being purchased by
the customers with faster and more efficient process than the
manual process.

Reports
The cashier and its supervisor who are using the
proposed module can be able to generate Sales Reports,
Terminal Reports of the proposed module to secure the
business and avoid cash and inventory shortages.

Price Viewing
The user of the proposed module can look up the
price of products using the proposed module. It is essential
for the users to view first the amount of the products they

Point- of- Sales with Price Management Module

desire before deciding what must be done with the specific


products being viewed its price.

Manage Price
The user of the proposed module can create the price of
the products accordingly. The user can also manage the price
of products and apply discounts. The user shall be benefited
from the proposed module because it will be automatically be
updated once the command of the user is given in managing
price. Additional is the security of data records.

Produce Outputs
The users of the proposed module have the ability to
produce receipts and price tags accordingly. Unlike the old
way, the proposed module shall be convenient not just in
doing transactions, but also in producing valuable outputs that
the company and the customer needs. The user of the
proposed module shall have convenience in their job for they
will just click and the system will do the other jobs.

Good Image
The end users of the proposed module will be having a
good image from the customers theyre serving. The
proposed module can give good customer service for
transactions will be made on time. The data being processed
will be accurate and reliable to avoid any conflicts for both
parties.

Point- of- Sales with Price Management Module

Higher Profit
The company that will use the proposed module shall be
benefited by having a higher profit for the system can manage
fast transactions and can avoid data discrepancies because it
has accuracy of its processes.

1.1.3 Goals

To make checkouts and transaction process efficient


A Point- of- Sale system enables cashiers to process
transactions and serve customers efficiently, and allows
managers to maintain tight control. The cashier uses his or her
handheld scanner to read the cost and description of every item.
The system automatically totals the quantities, deducts suitable
discounts, and applies tax.

To reduce pricing discrepancies


The proponents will create a system where the prices of
the products, SKUs and price tags can be added, modified and
can be easily updated in no time and in less likely to have
mistakes.

To generate valuable outputs


In any Point- of- Sale System, printing of receipt is a
must- important feature so this will not be excluded in the
system. To add a feature that will produce a receipt where all of
the transactions information will be inputted. Also, sales report
can also be made after each day. Another output is for producing
price tags for updating the price of the products accordingly.

To have a system integration with other connected


systems

Point- of- Sales with Price Management Module

The proponents will create a system that can synchronize


the proposed modules database to other systems databases to
acquire needed information and also to share information
through the use of database.

To create a system where it can meet good customer satisfaction


The proponents shall create a system that will speed the
process of transaction and shall manage the prices of products,
meeting good customer satisfaction.

1.1.4 Stakeholders and Clients

Point- of- Sales with Price Management Module

Stakeholders
Cashier

Description/ Participation
He/she is the person who scans the goods
through a machine called a cash register that the
customer wishes to purchase at the store.
He/she is the recipient of a good, service,

Customer

product, or idea, obtained from a merchandiser,


seller, vendor, or supplier for a monetary or other
valuable consideration.
He/she is a person or group of people such as

Consumer

household, who are the final users of products or


services.
He/she is a manager in a position of trust in

Checkout
Supervisor

business.

The

checkout

supervisor

gives

instructions and/or orders to subordinates and


responsible for the work and actions of other
employees.
He/she is a software engineer in charge of one

Lead

or more software projects. Participate in project

Programmer

activities including planning, implementation of


deliverables and quality control.
He/she is a professional in the field of project
management.

Project

Manager reports

and

receives directions from sponsors. He/ she is


Project Manager

managing, reviewing and prioritizing project work


plans. He/ she manage project team and
recommend

changes,

escalate

issues

and

mitigate risks.
He/she is an IT professional who specializes in
System Analyst

analyzing,

designing

information

systems.

and
Participate

implementing
in

project

activities including planning, implementation of


deliverables and quality control.
He/she is someone who analyzes an
organization and designs its processes and
Business Analyst

systems, assessing the business model and its


integration with technology. Participate in project
activities including planning, implementation of
deliverables and quality control.
8
He/she is an expert at creating effective

Point- of- Sales with Price Management Module

Documents

information

products

traditionally

known

as

Table No 1.1 Stakeholders and Clients with their participation

1.2

PROJECT SCOPE
1.2.1 Objectives

Create an automated system


To create a Point- of- Sale System that will eliminate the
manual efforts in the process and make an understandable and
easily- used system. Integrate bar-code scanners and credit card
authorization ability with the POS system. The proposed module
aims to create a cost-efficient, understandable, reliable and user
friendly system for every merchandising company that needs it.

Security of Data and Information


To generate accurate and secure data that will help the
company in terms of efficiency. To secure all the information
including the records of transactions, receipts of customers and
sales of the company.

Include Price Management


To create a system where price management can be
updated rapidly, accurately and will avoid discrepancies. Improve
pricing accuracy, identify underperforming products and markets,
analyze and respond faster to changing market conditions and
implement differentiated pricing policies like value- based
pricing.

Produce valuable outputs


To create a system where sophisticated and valuable
outputs can be produced like informative receipts and price tags
to improve further from the primitive way.

Point- of- Sales with Price Management Module

Manage special conditions in transaction processes


The proponents will include proper management of
voided products to the proposed module to avoid inventory and
sales discrepancies. To make the transaction process customerfriendly that holding of transactions will be also implemented at
the proposed module to meet customer satisfaction in their
needs without repeating the transaction process of purchasing.

1.2.2 Deliverables
Objective no.1: Create an automated system

Point- of- Sales with Price Management Module

10

Project Deliverable
Transactions

Work Products/ Description


Purchasing of Products
Items will be scanned by the cashier
After being processed at the system,

the customer pays the items by the use


of:
o

Cash Most common mode of

payment

especially

in

stores

and

merchandises. It is pertaining to the


regular payment transaction where the
customer is giving the amount physically
or on hand.

On the proposed module,

money will be accepted from 5 cents to


P1, 000 bills.
o

Credit

Card

Transactions

Pertains to the payment card issued to


card holder as a mode of payment. It
allows the card holder to pay for goods
and services based on the terms &
conditions. The issuer of the card creates
revolving accounts and grants a credit line
to the card holder. It uses a swipe card
machine and process the total amount of
purchased item.

If the credit card has

insufficient balance, to acquire the total


amount of the items, the system will
automatically

communicate

to

the

respective bank.
o

Debit Card Transactions - Also

known as a bank card or check card is


plastic money that provides the card
holder electronic access to his or her bank
account at a financial institution. Some
card have a stand value which a payment
is made while most relay message to the
card holders bank to withdraw funds from
Point- of- Sales with Price Management Module
a payees designated bank account 11
the

card where accepted can be used instead

Table No 1.2 Deliverables of Objective no. 1


Objective no. 2: Security of Data and Information
Project Deliverable
Reports

Work Products/ Description


Terminal Report- Terminal Reports of the
transactions being held will automatically
be produced after a time out of a specific
cashier.
Sales Report - This pertains to the day-toay report granted to the supervisor this is
the way of monitoring the daily sales of the
customers. This is also the way of tracking
the financial state of the business in daily
basis. Sales Reports of the transactions
being held will automatically be produced
after the shift of the last cashiers in a
specific day.
Audit Trail - Cashiers system logs, date,
time, name/ user of the system on a
specific day and time can be viewed for
security purposes.
Proof List Report Reports about products
that have been added in the system.
Price List Report Reports about prices of

products.
Table No 1.3 Deliverables of Objective no. 2

Objective no. 3: Include Price Management


Project Deliverable
View Price

Work Products/ Description


A functionality where The details of products
are being viewed. Especially the price.

Point- of- Sales with Price Management Module

12

Add/ Edit Price

A functionality where prices of products can

Update Price

be added and altered.


This will update the Point of Sales according
to

Apply Discounts and


Promos

the

changes

had

done

to

price

management.
Discounts
Senior Citizen If requirements are met,
accumulated

of

P650.00

will

be

discounted on agricultural products, meat


products, and daily necessity products
each and will be the budget per month
(rules may change vary from the senior
citizens handbook).
PWD (Person with Disability) If
requirements are met, a discount budget
accumulated of P1, 500.00 can be the
budget per month.
Color Tags
20% Discounts on Orange tag
50 % Discounts on Yellow tag
70% Discounts on Red tag
Privilege Card This is used to earn
points, have rewards and discounts of
items in the merchandise. Only those
people who have the membership within
the merchandise can only have the
service

of

the

card.

Members

that

purchase specific amount of products will


be given points to redeem products within
the store. P200 worth of accumulated
products = 1 point, and can redeem
products depends on the points. Products
will be given their corresponding points.
Point- of- Sales with Price Management Module

13

This will be used as when members


redeem products using their points and
the points are used as the currency.
Coupons Discounts can be obtained
from coupons that are approved by the
company to be used.
Table No 1.4 Deliverables of Objective no. 3
Objective no. 4: Produce valuable Outputs
Project Deliverable
Receipts

Work Products/ Description


Receipt - The proposed module can
create receipts or sales invoice after
every

transaction

as

proof

of

purchase.
Good
Price tags

receipts

are

from

normal

transactions
White Tags (Normal Price Tags),
Orange, Yellow and Red Tags can be

produced accordingly.
Table No 1.5 Deliverables of Objective no. 4
Objective no. 5: Manage special conditions in transaction processes
Project Deliverable
Voiding

Work Products/ Description


Managing of voided products will be available at
the proposed module to meet customer
satisfaction and avoid sales and inventory
conflicts.
Holding of
Customers that hold their transactions can be
Transactions
resumed later and another transaction process
can be executed while waiting to resume from
previous transaction process.
Table No 1.6 Deliverables of Objective no. 5

Point- of- Sales with Price Management Module

14

1.2.3 Out of Scope


Product Management
Monitoring and managing of products will be the scope of
Product Management w/ Store Inventory Control System in
doing the main project integration.
Inventory System and Inventory Control
Inventory System and its control will be the scope of
Product Management w/ Store Inventory Control System in
doing the main project integration.
Sales Monitoring
Monitoring of Sales will be the scope of Sales Monitoring
System in doing the main project integration. Only Price
management and printing of tags will be the scope of the
proposed module. Reports will be done by the proposed module,
but only in a daily basis, for the sake of the cashier and cashier
supervisor and sales clerks required reports. Sales Monitoring
shall focus on doing weekly, monthly and annual reports.
Online based system
Creating an online- based system will not be the scope of
the proposed module because merchandise stores are not
available online for purchasing.
SKU (Stock Keeping Unit)
The proposed module shall only handles on pricing of
products. Doing SKUs shall not be the scope of the proposed
module.
1.2.4 Enterprise Information System Required Functionalities
The following requirements must be included in this section:

Mobile Apps
Free Format Query

Point- of- Sales with Price Management Module

15

1.3

Personalized Screen
Import Export
Analytical Reports

PROJECT PLAN

1.3.1 Approach and Methodology


1.3.1.1

Methodology
The proponents used System Development Life
Cycle (SDLC) as the methodology in doing the proposed
module.
SDLC Chart (Waterfall Diagram)

Planning

Point- of- Sales with Price Management Module

16

Analysis

Design

Implementation

Maintenance

1.1.3.2

Approach
Phases
Planning

Plan
The proponents conducted a meeting
with the other groups about the
proposed main system.
The
proponents
conducted
a
brainstorming
about
the
subsystem/ proposed module.
The proponents conducted researches,
surveys and interviews about the
proposed module.
The proponents ask guidance to their
adviser about the proposed module.
The project manager divided the jobs
according to the ability of a single
group member.

Point- of- Sales with Price Management Module

17

The proponents analyze the problems


and coped up with solutions to solve
the adversaries using the proposed
module.

Analysis

The adviser of the proponents gave his


analysis about the proposed module to
his proponents.
From what has been researched, the
proponents created the system that will
solve the problems that had been
encountered during the research.

Design

The lead programmer encodes the


front- end and the back- end of the
proposed module, test the system if all
features are implemented and solve
errors within the system making.
The running system has been
implemented after many trials and
errors
The system has been used by endusers and enable for transacting with
customers.
Maintenance
Maintenance will be done to improve
and add some features to the system.
Maintenance will be done to fix
discovered bugs and errors.
Maintenance will be done to fix the
system in case it causes malfunctions.
Table No 1.7 SDLC of the proposed module
Implementation

1.3.2 Project Timeline


I
D
1
2

Task Name
Group meeting
(Planning)
Overall meeting (4th yr

Start
06/24/14
06/28/201
4

Point- of- Sales with Price Management Module

Finish
06/24/2014
06/28/2014

Duration
2 hours
4 hours

18

3
4
5
6
7
8
9

BSIT)
Group meeting with
other groups
Group Meeting
(brain storming about
system)
Look/Search
for
Adviser
Adviser is selected
Group Meeting with
head PMs
Meeting with Adviser
PM divided the group
work for each member

10

Conduct a Research

11

Group Meeting

12

Conduct a Survey

13

Group Meeting

14

Conducted a Interview

15
16

Group Meeting
Group Meeting with
Adviser

17

Project Charter

18
19

Group Meeting
Chapter 2

20

Group Meeting

21
22

Chapter 3
Group Meeting with
Adviser

23

Mock Defense

24

Group Meeting

07/01/201
4
07/04/201
4
07/07/201
4
07/09/201
4
07/10/201
4
07/12/201
4
07/14/201
4
07/15/201
4
07/19/201
4
07/21/201
4
07/26/201
4
07/28/201
4
08/01/201
4
08/02/201
4
08/04/201
4
08/09/201
4
08/11/2014
08/16/201
4
08/18/201
4
09/05/201
4
09/08/201
4
09/13/201
4

Point- of- Sales with Price Management Module

07/01/2014

1 day

07/04/2014

1day

07/07/2014

1 day

07/09/2014

1 day

07/10/2014

1day

07/12/2014

1 day

07/14/2015

1day

07/18/2014

1 week

07/29/2014

1day

07/25/2014

1 week

07/26/2014

1day

07/31/2014

3 days

08/01/2014

1day

08/02/2014

1 day

08/08/2014

1 week

08/09/2014
08/15/2014

1 day
1 week

08/16/2014

1 day

09/05/2014

3 weeks

09/05/2014

1 day

09/12/2014

1 week

09/13/2014

1 day
19

25

Revision of Chapter 1
and 2

26

Group meeting

27

Revision of Chapter 3
Group Meeting with
Adviser

28
29
30
31
32
33
34
35
36

37
38
39
40
41
42
43
44
45
46

Study the Documents


Checking of Revised
Documents
Re- Defense
Planning for system
design(sem-break)
Group
Meeting(Review ps1)
Identify
Group
Members Role
Group Meeting with
Adviser
Analyzing
of
problems(recall)
Group Meeting (brain
storming about the
design
of
the
proposed module
Group Meeting
Design the System
(1st part )
Group Meeting
Discussion of Chapter
4
Design the system
flow
Start
Coding
for
proposed module
Group Meeting with
Adviser
Continuation
of
Creating
the
Proposed module
Group Meeting with
Adviser

09/15/201
4
09/20/201
4
09/22/201
4
09/27/201
4
09/29/201
4
10/06/201
4
10/13/2014

09/19/2014

1 week

09/20/2014

1day

09/26/2014

1 week

09/27/2014

1 day

10/03/2014

1 week

10/10/2014
10/17/2014

1 week
1 week

11/03/2014

11/14/2014

2 weeks

11/17/2014

11/17/2014

1 day

11/18/2014

11/18/2014

1 day

11/22/2014

11/22/2014

1 day

11/24/2014

11/24/2014

1 day

11/25/2014
11/26/2014
12/01/201
4
12/06/201
4
12/08/201
4
12/09/201
4
12/15/201
4
12/20/201
4

11/25/2014
11/26/2014

1 day
1 day

12/05/2014

1 week

12/06/2014

1 day

12/08/2014

1 day

12/12/2014

1 week

12/19/2014

1 week

12/20/2014

1 day

01/09/2015

1 week

01/10/2015

1 day

01/05/201
5
01/10/201
5

Point- of- Sales with Price Management Module

20

47

Discussion of Chapter
5

48

Chapter 4

49

Group Meeting

50

Chapter 5

51

Group Meeting
Continuation
of
Creating
the
Proposed module
Group Meeting with
Adviser
Continuation
of
creating the proposed
module

52
53
54
55

58

Group Meeting
Continuation
of
Creating the proposed
module
Finished the proposed
module
and
Documents
Checking of proposed
module with Adviser

59

Final Defense

60

Group Meeting

61

Re-Defense

62

Group Meeting
Submission of Final
project

56
57

63

01/12/201
5
01/19/201
5
01/24/201
5
02/02/201
5
02/07/201
5
02/09/201
5
02/14/201
5
02/16/201
5
02/21/201
5
02/23/201
5
02/28/201
5
03/02/201
5
03/09/201
5
03/14/201
5
03/16/201
5
03/21/201
5
03/23/201
5

Point- of- Sales with Price Management Module

01/16/2015

1 week

01/23/2015

1 week

01/24/2015

1 day

02/06/2015

1 week

02/07/2015

1 day

02/13/2015

1 week

02/14/2015

1 day

02/20/2015

1 week

02/21/2015

1 day

02/27/2015

1 week

02/28/2015

1 day

03/02/2015

1 day

03/13/2015

1 week

03/14/2015

1 day

03/20/2015

1 week

03/21/2015

1 day

03/23/2015

1 day

21

Table No 1.8 Project Timeline of the proposed module


1.3.3 Success Criteria

When the proposed module is already at


its full functionality.
The project is considered a success if the systems is
fully functional and were able to cater transactions, generate
accurate reports and be able to use all of its functions properly.

When the proposed module is already


implemented
The project will be successful if the proposed module is
already running and already being applied, used by end- users
and free from errors.

When the proponents already met the


proposed modules goals and objectives
In meeting the projects goals and objectives, the
proposed module will becomes successful because all of its
goals and objectives are done effectively.

When end- users are already contented


in using the system.
Indeed, end- users will be the one that will use the
running system. If they are already contented about the process
and the system becomes helpful to them, there, it will be said
that the proposed module is successful. The project is success if

Point- of- Sales with Price Management Module

22

the system met the requirements of the users. User is an


important part of the system, thus this project must conform to
the needs of the user to be considered a success.
1.3.4 Issues and Policy Implications
Issues

Policy Implications

Issues acquired during the


development stage of the
proposed module

planning

about

each sub- system.


Meeting with other

scoping

becoming

and

sub-

out-

systems

groups

the

and

main system.
Issues of budget in doing

subproper

communication

proposed

is

being

implemented.
Auditor and Treasurer must

the project sometimes lead

implement

to

book in accounting budgets

misunderstanding

of

group members.

being

an

open

and right spending must be


practiced

attain

success in integrations within

features and integrating it,

to

Issues of group members


scoping

Right

to

avoid

budget

Issues about the time in

issues.
Proper time management and

doing the project because a

doing

project

Timeline.

lot of tasks are needed to

Discipline

in

time

do, thus, doing the project

management

is not just the only priority.

implemented to avoid time

Issues

shortages.
Meeting with other groups,

about

the

dependencies to the other


modules/

Subsystems

connected to the proposed

proper

must

scoping

be

of

functionalities of the system to


avoid confusions and proper

module.
Point- of- Sales with Price Management Module

23

doing of the work breakdown


structure

of

the

proposed

module to become a guide in


doing the system integrations.

Issues acquire after the


proposed module is being
implemented

Risks that may occur after

Proper management of risks.

the proposed module is

already implemented
System Malfunction

If the cashier and checkout


supervisor dont know how to
troubleshoot, they may want
to

call

the

system

administrator.
Table No 1.9 Issues and Policy Implications
1.3.5 Risk Management Plan
Risk Factor

Probability

Hardware and Software


malfunctions;

(H-M-L)
H

power

Impact

Risk Management

(H-M-L)
Action
H
Always have a back- up
of

the

system

either

or

cloud

shortage while doing the

external

project.

storage. Do the project

Unexpected

problems that will stop

in

setting

where

the progress of project-

problems can possibly

making.

evade and will avoid


distractions.

Point- of- Sales with Price Management Module

24

Unexpected

expenses

Budgeting of Expenses,

that requires in project-

save

making.

thrifty.

Shortage

of

money and

be

funds unable to comply


necessary requirements
Ability of a group
member

is

Choose worthy group

not

members that can do

expectedly available in

his/ her responsibilities

doing a specific task in

and

project-

problems.

making.

The

tasks

to

avoid

outcome of the project


greatly depends on the
people

assigned

to

complete it
The hardware and

As often as can, check

software used in POS

the system, system unit

gets malfunction.

and hardwares used in


the proposed module.

Table No 1.10 Risk Management Plan


1.3.6 Service Transition
The objective of Service Transition is to build and deploy the
proposed module from the manual to its automated process properly.
Service Transition also makes sure that changes to services and
processes are carried out in a coordinated way.

Knowledge Management about the proposed module


To gather information about the manual and existing
system, analyze, store and share knowledge and information
about the proposed module.

Project Management (Transition Planning and Support)

Point- of- Sales with Price Management Module

25

The proponents will plan and coordinate the resources to


deploy a major release within the predicted cost, time and quality
estimates of the proposed module.

Change Evaluation of the proposed module


To assess major changes, additional new features or a
substantial change to the proposed module will be discussed by
the proponents, before those changes are allowed to proceed to
the next phase of the project making.

Application Development
To make available applications and systems which
provide the required functionality for the proposed module. This
process includes the development and maintenance of custom
applications as well as the customization and implementing the
system.

Service Validation and Testing of the proposed module


To ensure that deployed Releases and the resulting
services meet customer expectations, and to verify that
operations are able to support the service.

1.3.7 Options Analysis


Situations
Researching on companies and

Alternative Options
Research on libraries about the

knowing the process of the system project, also in the internet to minimize
similar to the proposed module.

Point- of- Sales with Price Management Module

time and effort in going back forth from

26

the companies.
Required
Hardwares

in

Softwares

and

developing

the be downloaded from torrent sites but

proposed module.

Required softwares in the internet can


caution is needed to avoid malwares
and viruses. If not, the last option is to
buy the things that are needed in
developing the proposed module.

Time in doing the revisions about

In terms of system integration, the

the proposed modules scopes, and project team will be on the guard for
integrations
systems

with

and

other

revisions

related- any adjustment and revision that will be


on

the needed by the whole Merchandising

proposed modules documentations system.

Proposed modules Budget in


doing the proposed module.

In terms of the budget, the whole


team will stick in the budget of the
project however if there are unexpected
necessities for the project, the team will
produce the needed money to support
the necessities.

Technical Support in developing


the proposed module

The

teams

thoughts

about

the

software and the technical support of


the development of the project is that
the software that will be needed should
be licensed and for the technical
support that team will have their own
gadget or laptops that is needed for the
development.

Table no 1.11 Options Analysis

Point- of- Sales with Price Management Module

27

1.4.0 TECHNICAL FEATURES

Hardware Specification:
Processor
Minimum requirement is core i3 CPU or higher m350 @2.27 Ghz

Memory
Minimum requirement of 1 GB RAM and 2GB higher.
Hardware Peripheral:

Computer Monitor
Computer Monitor will be used as a screen to view the
interface of the proposed module.

Terminal/ Card Scanner


Used as credit and debit card scanner and scans the card
details.

Barcode Scanner
Barcode scanners are used to scan bar codes that are placed
at the products. Scanned items details will be seen on screens/
monitors.
Thermal (Printer)
Thermals are used to print hard copy of receipts, price tags
and SKUs.
Software Specification:
Operating System

Point- of- Sales with Price Management Module

28

Windows 7 or higher serves as the environment for the


development of the system.
Programming Language
Java (Netbeans) is the front-end or the interface of the
proposed module.

Database
MSSQL is the back-end or the storage of the proposed
module.

1.5

PROJECT ORGANIZATION AND STAFFING


ROLE
NAME
RESPONSIBILITIES

Project Manager

Business Analyst

Marayag,
Vivian

Riodique,
Jayson

She

responsible

of

the

planning,

controlling, facilitating, decision making,


and all knowing about the propose system.
He is responsible in knowing the problems
pertaining to the researches about the
proposed module.
She

System Analyst

is

is

responsible

for

knowing

the

Elepana,

solutions of the problems given by the

Mary

Business Analyst throughout the system

Joylyn

making. She will be able to give the flow of


the system.

Point- of- Sales with Price Management Module

29

Sale,

Lead Programmer

RJay

Documents Specialist

Adviser

He is responsible in creating the front end


and the back end of the system by means
of programming.

Decelo,

He is responsible in documenting all what

Angelo

has happened in the system making.

Mr. Billy

He is responsible in guiding the group

Tierra

throughout the project.


They are responsible in implementing rules

PEC
(Project Evaluation Committee)

and regulations of project making and a


board that checks the proposed modules.

Table no 1.12 Project Organization and Staffing


1.6

PROJECT BUDGET

BUDGET ITEM

DESCRIPTION

BUDGETED COST

ONE-TIME
COSTS
Computer Monitor

Computer Monitor will be used as a P10,000.00 x 50 pcs=


screen to view the interface of the P500,000
proposed module.

Terminal (Card
Swiper)

Barcode Scanner

Used as credit card scanner and P35,000.00 x 50 pcs=


scans the card details.

P1,750,000.00

Barcode scanners are used to scan P8,000.00 x 50 pcs=


bar codes that are placed at the P400, 000.00
products. Scanned items details will be
seen on screens/ monitors.

Point- of- Sales with Price Management Module

30

Thermal (Printer)

Thermals are used to print hard copy P1,000.00 x 50 pcs.=


of receipts, price tags and SKUs.

P50, 000.00

TOTAL ONE-TIME COSTS

P2,700,000.00

Broadband

Used for research and communication

P50.00 x 30 days =

(Internet Provider)
Electricity

Power source

P1,500.00
P2,500 x 30 days =

ONGOING
COSTS
Utility Expenses

P75,000.00
HR
Project Manager

P50,

Business

months = P500,000.00
P40,000 x 10 months =

Refer to Project Organization and Staffing

000.00

10

Analyst
System Analyst

P400, 000.00
P40, 000 x 10 months

Documents

= P400, 000.00
P30, 000 x 10 months

Specialist
Lead

= P300, 000.00
P18,000.00 x 5 months

Refer to Project Organization and Staffing

Programmer
TOTAL ONGOING COSTS

= P90,000.00
P1,766,500.00

Table No 1.13 Project Budget

Point- of- Sales with Price Management Module

31

CHAPTER 2.0 RELATED STUDIES AND SYSTEMS


INTRODUCTION
In this section, local and foreign studies of the proposed Point of Sale with
Price Management System will be discussed. Here, there will be five different local
and five different foreign studies will be tackled. Each study will be sorting its
systems features and their descriptions depending on their literature; giving their
synthesis and comparing their features using a matrix diagram.
2.1

FOREIGN STUDIES

2.1.1 Pizza Hut


Pizza Hut leads the industry with continuous menu innovation
and a wider choice of pizzas from Pan and Italian to Stuffed Crust and
Edge than any other brand. According to O'Neill, benefits fall into two
key areas: financial and operational. "Firstly, the System has helped
drive up revenue by increasing average guest ticket," O'Neill
commented. "That has happened particularly thanks to the intuitive
nature of the system and the way it leads staff through the selling
process, in addition to the ability to incentivize individual team members
through the use of detailed employee performance reporting." The

Point- of- Sales with Price Management Module

32

previous POS system had a relatively unresponsive greenon black


screen and required several keys to be pressed when registering
orders. Now, operators can quickly suggest deals as soon as
customers specify order components, with the crisp color graphics of
the MICROS screen helping progress transactions

speedily and

flagging up strategic information. For example, a typical home delivery


meal for four costing around 18 offers the opportunity to "bump"
customers up to 20 by bringing in extras which enhance perceived
value. "MICROS support staff in a contemporary and userfriendly way,
putting a lot more intelligence behind the selling process," O'Neill said.
He estimates average increase in guest check at around 1 to 2 per
cent. Behind the scenes, the MICROS system is allowing better sales
and product forecasting, enabling staff in both restaurants and home
delivery stores to predict more accurately how many pizzas they need
to defrost and proof prior to service. The MICROS system also has a
staging

process which enables kitchen

staff at restaurants to

automatically progress orders through the kitchen in the most efficient


way. This allows all the items which make up an order to be completed
in exactly the same time frame, preserving good quality and increasing
guest.
Source:
http://www.micros.com/NR/rdonlyres/564EA342-DEEA-48E2-A90417B29977EA34/0/PizzaHutCaseStudy.pdf

2.1.2 McDonalds
McDonalds is very busy restaurant because many costumers goes
there, the first priority for McDonalds is to deliver best restaurant
experience for the customers, for that McDonalds used pos system
point of scale system to ensure fast accurate order because this
Point- of- Sales with Price Management Module

33

system is used to speed the business process, it can track massive


amounts of data in seconds. With these systems, each order is
instantly transmitted to several workstations throughout the facility. The
cashier instantly knows what payment is due. The kitchen knows what
orders are coming up, and how long a customer has been waiting.
Source:
http://mcdonaldsmis.blogspot.com/p/mcdonalds is_04.html
http://mcdonaldsmis.blogspot.com/p/information-system_02.html

2.1.3 JD Edwards Point-of-Sale


Cost savings is one of the top priorities for any retailer. But most
often they have to invest heavily on third party POS solution; thus cost
savings seem like a far-fetched idea. Now retailers who are using JD
Edwards as their ERP have some reasons to cheer. KPIT, the worlds
largest JD Edwards practice has a proven POS solution, which works
on Enterprise One ERP. The POS solution is native to a JD Edwards
ERP, thus enabling huge cost savings.
The POS solution shares the same underlying network and
database of the JD Edwards ERP system. One can deploy the POS
solution for unlimited number of times as it is not licensed. It is an addon module to JD Edwards. Additionally in todays challenging business
economy access to real-time information is imperative to maximize
sales, especially in the retail industry. While JD Edwards Enterprise
One can streamline your data, a POS solution can give you access to
integrate and real-time data. While working on POS, you are logged
into Enterprise One; thus you can access any application such as Item
Ledger or Order Inquiry, at any given point of time. Whats more is that
the POS does not require specialized training for users with the
exception of familiarizing the POS functionality. The POS provides
Point- of- Sales with Price Management Module

34

similar look and feel, which is similar to JD Edwards application


reports.
Features:

Standard POS features and functionality.

Rapid sales and payment processing

Integrated with POS devices with JD Edwards ERP framework

Integrated with payment gateway JD Edwards ERP framework

Standard store operations and procedures with security

Multi-currency processing

Payment tender by multiple payment instruments

Reconciliation within the JD Edwards ERP system

Order booking in Call center Mode

Order processing for Walk-in & On-Account customers

Reward points tracking

Standard POS reports


Source: http://www.kpit.com/downloads/brochures/oracle/kpit-jde-pointof-sale-solution.pdf

2.1.4 SPAR SUPERMARKET


According to A.F. Blakemore (July 2013) Extends Charitable
Giving Scheme to Independent Retailers, SPAR retailers enjoy the
benefits of highly advanced in-store point of sale technology, which
provides a comprehensive stock control and ordering system.

Point- of- Sales with Price Management Module

35

SPAR POS is a competitively priced, centrally linked and


maintained scanning system suitable for all types and sizes of stores.
It has been developed to cater for the unique requirements of
independent retailers and provides flexible hardware and software
solutions.
The system itself is a PC based system and is highly fail safe,
efficient and easy to operate. As the system is developed in-house, it
is able to cope with a SPAR retailers present and future needs.

SPAR POS offers many benefits that should significantly increase gross
profit through:
Improve price control
Faster replenishment of stock
Improved shelf discipline
Improved efficiency at the till
Improved stock control
Suggested ordering
Sales and gross profit reporting at the end of each week.
A credit card facility with chip and pin and ISDN authorizations
SPAR POS has a full stock control module that will put you in total
control of your stock.

Stock control can also be linked in with

suggested ordering to produce accurate ordering requirements at the


touch of a button.

Point- of- Sales with Price Management Module

36

SPAR is fully committed to supporting your SPAR PoS system, and


provides a full back up service that includes:
Seven day Help Desk support
Onsite maintenance covers, 364 days per year with a four hour response
time
Software upgrades to ensure that SPAR POS is kept up to date
Source:
http://www.afblakemore.com/spar/sparpos-technology

2.1.5 Syncrons Global Price Management


Syncron Global Price Management offers a complete set of price
execution tools for your sales and pricing teams by communicating
pricing and policy changes quickly and accurately across the entire
supply chain - all while dealing with thousands of SKUs and millions of
price points.

Eliminate manual effort

Identify underperforming products and markets

Analyze and respond faster to changing market conditions

Implement sophisticated, differentiated pricing policies, like value-based


pricing
Our price management software makes pricing easy. We accurately
and efficiently group products, apply value drivers, model business

Point- of- Sales with Price Management Module

37

impacts,

and

implement

new

prices.

Syncron

delivers

price

improvements by focusing on:

Execution

Optimization

Analytics

Gain control. Improve profits


With increasing globalization and tougher competition, price
management professionals are struggling to adapt to changing markets
and react to competitive advancements. To be successful in this
environment, price management professionals need careful pricing
policies, supported by sophisticated analytics and robust price
execution tools.
Syncron leverages multiple price strategies, including lifecycle,
competitive and value-based pricing. Value-based pricing sets price on
the perceived benefit to the customer. Value-based pricing can improve
profits without impacting sales volume. Syncron helps you determine
when to use value-based pricing and what the customer is willing to
pay.
Syncrons Global price management software helps businesses
automatically generate the optimal price for each price list, market, or
customer by:

Segmenting products and customers

Identifying appropriate value drivers and price strategies

Point- of- Sales with Price Management Module

38

Modeling and comparing results of various strategic and tactical pricing


elements

Increase margins, sales and customer satisfaction

Enhance customer price perception and deliver a consistent brand


message

Minimize labor costs and eliminate compliance concerns

Analyze and respond faster to changing market conditions

Provide well-defined price corridors to your sales team when they need
it most

Communicate changes quickly across the entire supply chain

Support both centralized and de-centralized price decision making

Consolidate rules and policies

Administer price feedback and inquires with audit controls


Source:
http://www.syncron.com/en/solutions/global-price management/

2.2

LOCAL STUDIES

2.2.1 SHOPWISE-

CYWARES

RETAIL

(SIMPLE

RETAIL)

POS

SOFTWARE
According to CYWARE INCORPORATED (2009) a software
development firm specializes in retail and payment processing
Point- of- Sales with Price Management Module

39

solutions. We offer cost-effective software customization to address all


of our customers' unique business requirements. We aim to meet and
even exceed our clients expectations through open communication,
exceptional support, seamless implementation and ultimately, the timely
delivery of an outstanding solution.
Our solutions utilize the most progressive tools and languages
today, ensuring that our products are cost-effective, efficient and most
importantly, compatible with future technologies. Trends in IT
change every day, but one thing that will always remain constant is
CYWARE commitment to its customers. We strive to accomplish our
goals by providing simple and reliable software solutions for their
complex business needs.
We are confident that we can meet our clients requirements of
selecting an organization that will provide them with the necessary
technology, solutions and support to meet their growing needs.
We realize that they are not only searching for a supplier, but a partner
that understands their goals and is capable of fulfilling them effectively
and efficiently.
Simple Retail is a proven solution with an install base of over five
thousand retail branches in the Philippines. It is a flexible solution,
running on Linux, MAC OSX or Windows, and supports the following
database engines: MySql, PostgreSQL, SQLite, DB2, Oracle and all
other ODBC compliant databases. Written entirely using C++ and
Trolltechs QT Toolkit, it is extremely fast and robust, requiring only 32
megabytes of RAM and Pentium I processor for the point-of-sale
terminal hardware.
Source:

http://infotemajorproject.blogspot.com/2009/06/shopwise-

cywares-retail-simple-retail.html

2.2.2 PUREGOLD PRICE CLUB- TPLINUX POS SYSTEM


Point- of- Sales with Price Management Module

40

According to Jun Auza (April 2009), Puregold is one of the


leading retailers here in the Philippines is set to deploy a Linux-based
point-of-sale system (POS) to cut down operating costs. It has
reportedly ordered more than 2,000 licenses of TP Linux software,
which will be installed to Puregolds network of stores.
TP Linux is owned by Wincor Nixdorf, a German corporation that
provides retail and retail banking hardware, software, and services. TP
Linux has the capability to run on other vendors hardware as well as
Wincor Nixdorfs own systems. Puregold is the first Filipino company
that will utilize the German firms open source-based software.
Puregold is looking to cut overall licensing costs in terms of security
while standardizing on an open-source platform, covering both current
and

future

store

openings.

In an interview by Lawrence Casiraya of Inquirer.net, according


to Ruel Magat, the company's IT Manager said, We wanted to cut the
cost of buying anti-virus licenses and save on the cost of the license of
(Microsoft) Windows per POS. Christian Charlton, Wincor Nixdorfs
Asia Pacific head of retail solutions, added that Puregold also intends
to use the open source-based software to boost its customer-related
initiatives such as promos and discounts.
In these tough economic times, I hope more and more
companies here will follow what Puregold has done and will somewhat
realize the true value of open source software.
TPLinux is one of the most flexible Linux-based store solutions
available on the global market. Coupled with its versatility of use,
outstanding integration mechanisms and the experience gained with
over 50,000 TPLinux installations worldwide, TPLinux is ideal both for

Point- of- Sales with Price Management Module

41

modernizing store IT and for migrating and using established POS


hardware platforms.
Source:
http://www.junauza.com/2009/04/one-of-philippines-leading-retailersto.html
http://infotemajorproject.blogspot.com/2009/06/puregold-price-clubtplinux-pos-system.html

2.2.3 7-Eleven
At 7-ELEVEN stores, each swipe of a barcode represents a
piece of sales transaction being saved to the immense database of the
POS system, which collects information from the seven million
consumers who shop at 7-ELEVEN every day. Our powerful POS
system, which manages thousands of products, the processing of
orders from stores, and the collection and analysis of daily sales data,
is an essential tool which facilitates the operation of 7-ELEVEN.

To pinpoint consumer needs, PCSC introduced the secondgeneration POS (point of sales) system in 2003. The new system
updates immediate sales and inventory information hourly, publishes
weather forecasts four times a day, and transmits consolidated product
information for multi-media presentation. This system has enabled us to
manage

information

in

strategic

way

and

increase

our

competitiveness.

Through this powerful information system, the 7-ELEVEN


headquarter responds to consumer needs timely, improves our line of
products

and

develops

new

Point- of- Sales with Price Management Module

products

accordingly, strengthens

42

procurement power and sales forecast, and devises targeted marketing


strategies information system also allows store owners to learn the
characteristics of the business district in which they operate, place
accurate orders, minimize inventory and write-offs, and upgrade
operations standards to boost sales performance.

Source:
http://www.7-11.com.tw/en/business/is.html

2.2.4 KFC
Before year 2000, KFC Philippines was using multiple IT
solutions to address their corporate requirements. Because of this, the
integrity of the reports became

difficult to validate and management

had a hard time tracking down their stocks. The KFC management
could not react as quickly and as timely as they wanted to. The reason
behind

these

problems

was

evident:

the

systems

could

not

communicate with one another.


In 2004, Kaisa Consulting updated KFCs enterprise IT structure
with SAP R/3 version 4.7 to be able to solve KFCs growing problem of
misinformation and inaccurate reports. The existing version used by
KFC at that time was 4.0B and although it drastically helped the fastfood chain in its business functions, it was unable to fully support KFC
due to increasing demands of the market, expansion projects and new
business ventures. KFC realized that they need to enhance their ERP
system to be able to support and be prepared for the ever-changing
market.

Point- of- Sales with Price Management Module

43

Fully integrated system increased visibility across the Enterprise


The project with KFC involved business enhancements,
corporate

restructuring,

user

training/

re-training,

new

report

requirements, and legacy systems integration with SAP. With a team of


seasoned SAP consultants, Kaisa spearheaded the challenge. The
upgrade turned out to be an overhaul; it addressed everything from
Financial Accounting to Asset Management to Controlling to Materials
Management to Sales and Distribution to Production Planning to
Customer Service. Through the joint effort of KFC and Kaisa
Consulting, a fully integrated system was installed and it drastically
increased visibility across the enterprise. Data integrity and reliability
became intact. Also with the improved GUI and SAP Enjoy
transactions, the users are not burdened to switch from window to
window just to post a simple transaction.
Integrated web-ordering applications and POS back-end systems
with ERP.
At present, there are eighty-three (83) KFC stores nationwide.
Stock replenishment and financial visibility were always the main
concerns. A web-ordering system was put in place and integration into
SAP was established. Replenishment requirements of the stores and
kitchens can be viewed by the commissaries through the MRP system
in SAP. This enabled the commissaries to map out their production and
procurement plans more efficiently.
Ease report generation improved response time.
In the fast food industry, everything moves fast.

All the

departments should be able to respond quickly to the requirements of


the market and of the top management to be able to stay ahead of the
game. Some reports were real time and some were combined with
historical data. Most of these reports were not standard, and it entailed
Point- of- Sales with Price Management Module

44

development from the Kaisa team. Kaisas solution was to use the
readily available SAP-LES, and SAP Query functionality, and SAP
Business Warehousing (BW) for more complex reports.
Improved system controls without compromising the speed of
process flow.
KFC needed to improve controls in the system and in the
business process to eliminate pilferage and unnecessary losses. New
functionalities such as shelf-life expiration date check, the use of
delivery notes for stock transport, and a custom physical inventory
taking transaction among others were introduced to optimize the flow of
goods and to improve stock keeping. The main objective was to make
sure that stocks are delivered on time, of the right type, of the right
quantity, and are of the highest quality.
Improved forecasting
KFCs Accounting and Purchasing groups were concerned that
they might lose the data of past transactions since these were logged in
the old system. This historical data is used by both groups as reference
points for forecasting. Through SAP BW, Kaisa addressed these
concerns and incorporated the live data into the reports with historical
data. Through SAP BW, KFC was able to track price changes,
accounting balances, and other vital information and was able to
compare it with the current data in a seamless way.
Change drives efficiency and profitability.
It is inevitable that in every organization, users might be reluctant
to change since they might be well accustomed to their present system
already. However, with the ever evolving business landscape, it is
pertinent that companies upgrade continuously to be able to keep up
with the changing times so as to not get left behind.

Point- of- Sales with Price Management Module

45

In KFC, they did not expect that their cluttered business process
and bad practices were going to be replaced with a more controlled and
structured environment. With the new Enjoy transactions, enhanced
report generation tools, and with more controls in the system, the users
saw that the upgrade in the system made their load lighter and their
business work process more efficient. KFC was able to increase their
annual

profits as a result of the information generated by the

upgraded system.
Source:
http://www.kaisa.com/wpcontent/themes/kaisa/pdf/KFC_Success_Story
.pdf

2.2.5 Meat Market Point-of-Sale


Meat Markets need to process orders quickly and maintain
accurate inventories to ensure repeat business. Our Meat Market Point
of Sale Systems can interface with scales that have been developed
that enable workers to print barcodes with prices for the selected
purchase right from the weight scale. The purchases can be scanned
right away with a bar code reader to complete the purchase or brought
to a register in another location.
Our Meat Market POS Software has inventory tracking features that
enable the purchase weight to be deducted from the total meat or deli
inventories. The Meat market Point of Sale Software updates inventory
levels in real-time as items are purchased.
More Meat Market Point-of-Sale Features:

Analyze profit and loss margins with accounting reports

Setup loyalty plans to keep customers coming back

Sell gift cards to get new customers in your store.

Detailed Inventory Reports:

Point- of- Sales with Price Management Module

46

Top selling items

Low stock

Pending orders

Quick Checkouts
Touch screen and bar code scanner enabled

Record Employee Hours and Wages

Shift Reports

Hour and Wage report

Source:
http://posnation.com/meat-market-pos-system

2.3

SYNTHESIS AND

RELEVANCE

TO THE

STUDY (MATRIX-

COMPARATIVE ANALYSIS)
Synthesis of the study:
Point- of- Sales with Price Management Module

47

The special feature that the proponents would want to put on the
proposed module is the facility for mobile application that runs with android
application. In this generation where technology are reigning, the needs of
customers about the knowledge and accessibility of their necessities must be
given as easiest as possible as could be. Hence, a lot of people are already
using smart phones because it has a lot of features, and other phone brands
sells cheaper price of it. So the proponents would want to put the ease of
transactions in their palms by the use of their android phones. This will be
used as price guide for the customers and they could reserve the product and
just get and pay the purchased items at the store.
Based on the researches concluded by the proponents, all related
companies gathered have the ability to speed the process of their business.
Majority of those related companies automatically progress orders, process
rapid sales and can forecast products. Some are PC based, maybe others are
using touch screens. Few only create backups, few also can track rewards
points. Five out of five produce POS reports, can communicate pricing and
policy changes quickly and accurately that makes pricing easy. Some can
implement new prices while the others cant. All literatures of course runs in
an operating system. None of them are using ms sql as their back ends.
Finally, six out of ten immediately updates their sales.
Hence, in all features being stated, the proponents get all of the said
features and added it to the proposed module. The main feature also will be a
big help to the customers especially in choosing and knowing their desired
purchases. It is important because today, many want for a better convenience
and as possible as it could be, process of purchasing must be done as easy
as possible.
Matrix Diagram
System
Description
and Features

Related Literatures
Pizza Hut

McDonald
s

SPAR
Supermarket

JD Edwards
Point-ofsale

Syncrons
Global Price
Managemen
t

ShopwiseCywares
Retail(Simpl
e Retail)POS
Software

PUREGOL
D Price
Club

7eleven

KFC

Meat
Market
Point-ofSale

-TPLINUX
POS

Point- of- Sales with Price Management Module

48

Proposed
module

System

Speed the
business
process
Automatically
progress
orders
Rapid sales

Product
forecasting

PC based
system

Backups data

Reward
points
tracking
Standard

Communicati
ng
pricing
and
policy
changes
quickly
and
accurately
makes pricing
easy

implement
new prices

Facility
for
mobile apps

POS reports

Running in
operating
system
Database: Ms
sql
Immediate
update of
sales

Table No 2.1 Matrix Diagram of Studies and the proposed module

Point- of- Sales with Price Management Module

49

CHAPTER 3 - EIS PROJECT MANAGEMENT AND DEVELOPMENT


3.1

RISK MITIGATION, MONITORING AND MANAGEMENT PLAN


3.1.1 INTRODUCTION
This section gives a general overview of the Risk Mitigation,
Monitoring and Management (RMMM) Plan for Point- of- Sale w/ Price
Management System. RMMM contains all the possible risks that may
affect the implementation of the system. RMMM also contains the
possible solutions to the difficulties might be a possible risk in the
implementation of the system.
3.1.1.1

SCOPE AND INTENT OF RMMM ACTIVITIES


The scope of this section will focus mainly on
managing risks that may help in doing the proposed
module to become unsuccessful. The proponents wanted
the proposed module to be successfully created, errorfree and contented being used by end- users. Having a
risk mitigation, monitoring and management plan will help
the proposed module and also the proponents to counter
or handle unexpected problems that may occur during the
developing stage of the project making. RMMM activities
are to identify and monitor the possible errors and defects
that the system might meet. RMMM activities intents good
communication between the client and the proponents of
the proposed module. This is done to efficiently do the
proposed module successfully.

Point- of- Sales with Price Management Module

50

3.1.1.2

RISK MANAGEMENT ORGANIZATIONAL ROLE


The proponents have the task of managing the
risks that may occur while or after doing the proposed
module.

The development of the proposed module can be


avoided having risks by properly monitoring the hardware
and softwares being used, costing of development, the
schedule of the development of the project and other
aspects that are connected in the proposed module.

The end- users could also help avoid risks in the


proposed module by knowing and providing all necessary
information of the proposed module itself during its
developmental stage.

The proponents of the proposed module can avoid


having risks by getting all the details and the information
needed for the equipment of hardware and software to
the proposed module.
Project Manager
The Project Manager is the leader of the group and
the ultimate decision maker. Hence, the Project Manager
shall decide how to manage upcoming risks of the
proposed module.
Business Analyst
The Business Analyst manages the risks under his
job descriptions which is the Business Process. Out of his
scopes is being managed by his other group mates.

Point- of- Sales with Price Management Module

51

System Analyst
The System Analyst manages the risks that occur
which may occur in the process of the proposed module
being planned. The System Analyst keeps the process of
the system clean and free from possible risks that may
occur.
Lead Programmer
The Lead Programmer manages the risks in doing
the syntaxes of the proposed modules. He keeps avoiding
the risks by keeping his codes right.
Documents Specialist
The Documents Specialists shall only document all
things connected in the proposed module. List all risks
and put right decisions on managing it.

The proponents clients can avoid risk by making


all necessary business changer before initiating request
for the software.

3.1.2 RISK DESCRIPTION


This section describes the risks that are likely to be encountered
during the development of the proposed module.
3.1.2.1

RISK TABLE
The

following

table

describes

all

the

risks

associated with the project. The appropriate categories of


the risks are also given, as well as probability of each risk
and its impact on the development process.

Point- of- Sales with Price Management Module

52

Risks

Probability

Impact

Risk
Managemen

Hardware

and

Software

15%

t Action
Always have a

malfunctions; power shortage

back- up of the

while

system

doing

Unexpected

the

project.

either

problems that

external or cloud

will stop the progress of

storage. Do the

project- making.

project

in

setting

where

problems

Unexpected expenses that

15%

a
can

possibly

evade

and will

avoid

distractions.
Budgeting

of

requires in project- making.

Expenses, save

Shortage of funds unable to

money and be

comply

thrifty.

necessary

requirements
Ability of a group member is

14%

Choose

worthy

not expectedly available in

group members

doing

that can do his/

specific

project-

making.

outcome
greatly

task

of

the

depends

in
The

her

project
on

responsibilities

the

and

people assigned to complete


it
The hardware and software
used

in

POS

gets

malfunction.

tasks

avoid problems.
14%

As often as can,
check

the

system, system
unit

Point- of- Sales with Price Management Module

to

and

53

hardwares used
in the proposed
module.
Table No 3.1 Risks Table
3.1.2.1.1

DESCRIPTION OF RISKS
Business Impact Risk:
This is the risk where concern is that
of the not being able to come up or produce
the product that has impact on the clients
business. If the software produced does not
achieve its goals or if it fails.
Customer Risk:
This is the risk where concern is
clients motivation or willingness in helping
the software development team. If the client
fails to attend meeting regularly and fails to
describe the real need of the business, the
information needed of the proponents will be
lacking.
Development Risks:
If the proponents itself, their sponsors
and clients failed to provide all necessary
equipment

for

the

development

and

execution of the software, it will lead to


system failure. All must commit in providing
their time resources and effort to support the
developers of the proposed module.
Employee Risks:
Point- of- Sales with Price Management Module

54

This risk is totally dependent on the


ability, experience and willingness of the
proposed modules proponents that develop
the system. If the group members are not
well

experienced

application

enough

necessary

to

to

use

the

develop

the

proposed module, it will lead to push


development dates until its too late to save
the project. If one or more group members
are not putting in all the effort required to
finish the proposed module, it will cause the
project to fail. Employee risk is one of the
major risks to consider while designing the
software.
Process Risk:
Process risk involves risk regarding
product quality. If the project development
does not meet the standards set by the
customer or the development team, it will
become failure. This can happened because
the customer fails to describe the true
business need or the failure of the proposed
modules development team to understand
the project than to use proper equipment
and employees to finish the project.

Product Size:

Point- of- Sales with Price Management Module

55

This risk involves misjudgment on


behalf of the user and also the proponents
proposed module. If the proponents fail to
provide the proper size of the product that is
to be developed, it will cause major
problems for the completion of the project. If
the proposed modules proponent team
misjudges the size and the scope of the
project, the budget of the project may be
mis- calculated, thus either spending much
or less in the project without knowing the
output

of

the

project

is

risky if

the

proponents didnt plan on it properly.


Technology Risk:
Technology risk involves of using
technology that already is or is soon to be
obsolete in development of the proposed
module. Since technology changes rapidly
these days, it is important to pay importance
to the risk. If the user request use of
software that is soon to be obsolete, the
proposed modules development team must
argue the call and have to pursue customer

3.1.2.1.2

PROBABILITY AND IMPACT FOR RISKS

Point- of- Sales with Price Management Module

56

The following is the sorted version of the above table by


probability and impact:
Category
Employee Risks

Risks
Lack of training

Probability
15%

Impact
1

Customer Risk

and experience
Customer may

15%

fail to
Process Risks

participate
Low Product

14%

Product Size

Quality
Where size

14%

Development

could be wrong
Insufficient

14%

Risks
Technology Risk

Obsolete

14%

Business Impact

technology
Product may

14%

estimates

harm the
business
Table No 3.2 Risks Table (sorted)

Impact Values

Point- of- Sales with Price Management Module

Description

Catastrophic

Critical

Marginal

57

Negligible

Above is the table that categorizes the risks involved in


software development. It gives brief description of the risk in
Risks column and also provides the probability of risk occurring
in percentages in Probability column and also the impact of the
risk in the Impact column.
The impact values assigned to the each risk are
described in the section below the risk table. It is very convenient
way to look at the risk and derive the information of the risk.
3.1.3 RISK MITIGATION, MONITORING AND MANAGEMENT
This

section

describes

Risk

Mitigation,

Monitoring

and

Management for each possible risk in details. It will tackle about the
ways on how to avoid, monitor and to have ways to manage the risks.
3.1.3.1

RISK MITIGATION FOR RISKS


In

this

section,

several

different

software

development risks will be identified, a plan will be created


to avoid these risks. The proponents will think the
possible risks that may happen and keeping it resolved to
develop the proposed module. This is important to avoid
upcoming risks. The goal of the proponents is to manage
the possible risks that may happen before it comes to
existence.
3.1.3.1.1

PRODUCT SIZE
In this risk, the size of the codes
inputted at the proposed module varies. The
proponents must estimate the duration time
in coding the functionalities of the proposed

Point- of- Sales with Price Management Module

58

module. The Lead Programmer must be


aware of this risk and he/ she must manage
this by starting of coding as early as
possible that he can get information at an
early time. By that, estimation of product
size can be adjusted because a lot of time
will be given at the proponents.
3.1.3.1.2

BUSINESS IMPACT
In this risk, the quality of product will
be

concerned.

The

Proponents

shall

keeping up with people who will use the


proposed module. It is important to know
their opinion on what must and mustnt
include at the system. It is important to
understand the needs of the user on using
the system before implementing it.
3.1.3.1.3

CUSTOMER (USER) RISKS


If the user of the system doesnt
participate or the proponents dont get
proper information of the system from its
user, failure in identifying the problems will
occur resulting in failure in identifying the
objective. The proponents would want them
to keep in touch via texting, calling or via
social media or emails. Indeed, a formal
meeting must be settled.

3.1.3.1.4

PROCESS RISKS

Point- of- Sales with Price Management Module

59

The proponents would want the


quality of product will met high standards as
possible. The proponents shall research
other related system and have a compilation
of

features,

get

useful

feature

and

implement at the proposed module.


3.1.3.1.5

TECHNOLOGY RISKS
This risk will be avoided if the
technology

used

in

developed

in

the

proposed module must be the latest and up


to date. The proponents do will not let the
proposed module be obsolete or un- useful
at the near future so that the proposed
module must be updated with the latest
software and hardware at the market to
provide quality assurance and customer
satisfaction. Also, risks about open source
softwares and proprietary softwares will be
managed by the proponents accordingly..
3.1.3.1.6

DEVELOPMENT RISKS
Effectiveness of tools in developing
the system must be met in this risk. This risk
includes

the

Hardware

and

Software

malfunctions; power shortage while doing


the project. Unexpected problems that will
stop the progress of project- making.
Unexpected

expenses

that

requires

in

project- making. Shortage of funds unable to


comply necessary requirements.

Point- of- Sales with Price Management Module

60

3.1.3.1.7

EMPLOYEE RISKS (Proponents)


This

risk

involves

each

of

the

proponents who developed the proposed


module.

Performing

tasks

and

doing

activities in developing the proposed module


must be observed here and also the abilities
of each member must be performed.
3.1.3.2

RISK MONITORING FOR RISKS


In this section, the proponents will identify the
conditions to monitor and determine whether risk m is
becoming more or less likely.
3.1.3.2.1

PRODUCT SIZE
The proponents shall monitor the
development of proposed module. Starting
from its database size, the database can be
imported

and

exported,

can

also

be

converted to avoid system hangings due of


database fullness. The proponents shall
keep tracked with the functions of the
system.
3.1.3.2.2

BUSINESS IMPACT
The proponents shall have a meeting
with the end user of the proposed module, s
and their checkout supervisor. End users
must be determinant in the system if it is
good already or lacking of features and
needs improvement. The proponents will be
then aware on what ways must be done and

Point- of- Sales with Price Management Module

61

what functionalities of the proposed module


must be improves to make it user- friendly.
3.1.3.2.3

CUSTOMER (USER) RISKS


This risk will monitor the risk of the
attendance of users meeting with the
proponents. The proponents must keep in
touch with the end users always updating
them

about

the

development

of

the

proposed module.
3.1.3.2.4

PROCESS RISKS
Each proponents tasks must be seen
by other proponents to ensure the product
quality of the proposed module. Informing
other proponents about their duties must be
practiced if it meets the right standards in
system development.

3.1.3.2.5

TECHNOLOGY RISKS
Observing latest technologies and
applying it at the proposed module must be
observed

for

the

improvement

of

the

system. Also, the Front end and the Back


end of the proposed module shall be
observed in this risk which is Java Netbeans
and MySql.
Observing the tools and equipments
used for developing the system must be
done for the effectiveness of its use in
developing the proposed module.

Point- of- Sales with Price Management Module

62

Hardware Computers used for developing


the system must at least meet high quality of
specifications
- Must able to support the software being
used to develop the proposed module.

Software Software must not be obsolete


and must be in the latest trend of softwares.
- Front end and Back end used must not be
obsolete.

3.1.3.2.6

DEVELOPMENT RISKS
Proponents

must

observe

the

development stage of the proposed module.


Avoid and solve all the possible risks that
may

occur

while

doing

the

proposed

module.
3.1.3.2.7

EMPLOYEE RISKS (TEAM MATES)


Proponents must look at each other
about

their

duties

and

responsibilities.

Difficulties in performing tasks must be


observed and every proponent must work
out in helping each other to develop the
proposed module.
3.1.3.3

RISK MANAGEMENT FOR RISKS


In this section, the proponents shall identify the
risks in developing the proposed module and create a
plan to manage these risks if occurred.

Point- of- Sales with Price Management Module

63

3.1.3.3.1

PRODUCT SIZE
Time and manpower in doing the
project must be observed. If it lacks, double
time must be needed to meet the projects
objectives.

3.1.3.3.2

BUSINESS IMPACT
If problems occur, end users must be
willing

to

give

information

about

the

problems that the proponents encountered


and give the proper management and
adjustments in the problems met.
3.1.3.3.3

CUSTOMER (USER) RISKS


The

proponents

will

only

ask

important topics that are must on developing


the

proposed

module

to

make

time

essential.
3.1.3.3.4

PROCESS RISKS
If work is not done properly, other
proponent must take over to do the job to
meet the standards in developing the
proposed module.

3.1.3.3.5

TECHNOLOGY RISKS
The proponents shall keep in touch
with the latest trends of technology in the
market; new trends that could make the
process of the proposed module become

Point- of- Sales with Price Management Module

64

easier and implement these changes at the


proposed module.
3.1.3.3.6

DEVELOPMENT RISKS
In developing the proposed module, if
problems occurred, as soon as possible,
these problems must be solved as early as
possible to resume in developing the
proposed module and must always be
informed about new changes.

3.1.3.3.7

EMPLOYEE RISKS (TEAM MATES)


This risk must be done by looking out
for each other that is if some other
proponent

is

having

hard

time

in

performing his / her task in developing the


proposed module; other proponents must
help him to ensure that the job must be
done accordingly. Team work must be done
to create a work effectively. The best way is
to put the proponent in the duty that he/ she
can ensure that he/ she can do the job.

3.1.4 SPECIAL CONDITIONS


1.

Login
Users of the proposed module shall depend on the
Human Resource Module. This module shall burdens the
risks that the Log- in may occur.

2.

Use of proprietary software

Point- of- Sales with Price Management Module

65

Proponents must use legitimate softwares in


doing the proposed module.

3.2

SOFTWARE CONFIGURATION MANAGEMENT PLAN


3.2.1 INTRODUCTION
During the time of software development, the proponents will be
making changes from the original plans. Software Configuration
Management Plan is developed so that the proponents can identify the

Point- of- Sales with Price Management Module

66

change, control the change, make sure the plan is implemented


correctly and to make sure that the proponents report the changes.
3.2.1.1

SCOPE AND INTENT OF SCM ACTIVITIES


The main purpose of SCM is to make report and
track any changes made to the original software
development plan. It is applied throughout the software
development process and will help the proponents to
keep track of changes and also help the proponents go
through and make changes. SCM procedures will give the
proponents a good map out of the software so that if
changes are needed, it will be relatively easy to do. SCM
will maximize productivity by minimizing mistakes. For
SCM to be successful, all the proponents of software
production team will have to take time to report the
changes that the proponents think that are necessary
and/ or to notify others of changes that had made. This
may be boring kind of work but this is indeed important.
SCM activities are developed to:

Identify change in doing the proposed module


Control the changes in doing the proposed module
Ensure that changes being applied in the proposed

module is being properly implemented and managed.


Also have a way to document the changes in doing the
proposed module, and update the system and the
documents simultaneously.
Above describes the scope and purpose of doing
the SCM activities.

3.2.1.2

SCM ORGANIZATIONAL ROLE


Marayag, Vivian Project Manager

Point- of- Sales with Price Management Module

67

Riodique, Jayson Business Analyst


Elepana, Mary Joylyn System Analyst
Sale, R-Jay Lead Programmer
Decelo, Angelo Documents Specialist
Above

listed

are

proposed

modules

SCM

Organizational Role. The project development team is


consisting of five members and each member of the team
will accept the responsibility for the software configuration
management. If one member/ proponent reports changes,
the remaining group members have to take up a job
authorizing change and to ensure that change is properly
implemented. This will reduce or eliminate confusion
between the proponents regarding changes with the
software.
3.2.2 SCM TASKS
In this section, the proponents will detail all important SCM tasks
and will assign responsibilities for each member. All of the SCM tasks
will be performed by the members/ proponents of the project
development.

After the proponents do the system, test samples will be done to


check the proposed module.

The proponents shall identify the defects, bugs, glitches


happening on the proposed system.

The proponents shall make a solution within the problems being


identified.

The proponents shall apply fixes within the problems mentioned.

Point- of- Sales with Price Management Module

68

Testing will be done again to find problems until the system


becomes stable.

3.2.2.1

IDENTIFICATION
In this section, the proponents will describe the
way software configuration items will be identified for the
software configuration management plan.
3.2.2.1.1

Description

Identify change
During

the

system

development phase, if a proponent/


member of project making have a
suggestion for the configuration of the
software, A group meeting will be
made to talk about the proposed
change in the process of the software
if it will be necessary or not.

Approve change
All of the proponents of the
group must be informed about the
changes to the software development
that was proposed by one of the
proponent. After being informed, the
proponents will decide if the change
will be approved or declined.

Ensure that change is being properly


implemented

Point- of- Sales with Price Management Module

69

If

the

change

is

being

approved and implemented, all of the


proponents will check the change if
mistakes

and

discrepancies

are

occurring. This will be made to


finalize the change that has been
done.

Document the change


After the change is approved
and applied, documenting all of the
changes will be done to have a
proper

documenting

of

all

that

happened.
3.2.2.1.2

Works products and documentation

Identify change
Once change is identified, all
members/ proponents of the group
will be informed for the proposed
change to the system development.

Control change
Evaluation of the change is
being planned by the proponents if it
will be implemented or not. If granted,
it will be implemented. If not, it will be
declined.

Point- of- Sales with Price Management Module

70

Ensure that the change is properly


implemented

Document the change


Once the change is being
approved and implemented, it will be
documented.

3.2.2.2

CONFIGURATION CONTROL
3.2.2.2.1

Description
Changes

will

be

controlled by using human


procedures

and

automated

tools. Here are the steps,


which will be taken in order to
control change.

Request change.
Lead
Programmer

evaluate the request change.


The result of the evaluation will

will

be told to other proponents

about the change.


Final decision on change will
be made.
If change is approved
1.
Define constraint
2.
Check out items for
changes
3.
Make

necessary

change
4.
Apply SQA activities
5.
Check in items
6.
Apply testing activities

Point- of- Sales with Price Management Module

71

7.
8.
3.2.2.3

Rebuilt the software


Distribute the software

VERSION CONTROL
3.2.2.3.1

Description
As a result of changes,
the version number of various
modules

will

be

increased

accordingly. The proponents


will

be

using

universal

version number system for all


modules. Final version of the
entire product will also be
made.
Major documentation will also
have version numbers.

3.2.2.3.2

Increasing Version Number


When a change request
is filed, a change report will be
created. After the change is
finalized,

it

will

be

documented. The proponents


will be using a decimal point
version number system:
<major update>.<minor
update><bug fix>

Point- of- Sales with Price Management Module

72

Bug fix
If
have

enough

been

bug

done

fixes

on

the

product/ module, the bug fix


portion of the version number
will be increased. The number
of user visible bug fixes will
also affect when the bug fix
number

is

increased.

The

more visible bug fixes have


been made, the closer the bug
fix number will need to be
increased.
Minor Update
The functionality of the
system

will

be

added

to

increase its user friendliness


and performance but does not
change the way a function/
interface
update

work,

the

number

minor

may

be

increased. Several of changes


will

increase

the

version

number.
Major Update
Major update will be
done if the proposed module
will

be

upgraded

and

enormously will change its


Point- of- Sales with Price Management Module

73

atmosphere but the process of


the system is still there.
3.2.2.3.3

Work Products and

Documentation
Document control will
be made for the development
of the proposed module and
document there all of version
revisions.
3.2.2.4

CONFIGURATION STATUS ACCOUNTING

(CSA)
Configuration

Status

Accounting

(CSA) is used to inform every proponent


and end- users that are related in doing the
proposed module about the changes that
may occur in doing it. The proponents will
be using two ways to communicate with
other person that are related in system and
also with the end- user which are the
cashier, cashier supervisor and price clerk to
be

informed

from

changes

that

may

concern.
3.2.2.4.1

Description
Describes on how the
Configuration

Status

Accounting will be done.


Verbal Communication

Point- of- Sales with Price Management Module

74

Since the hospital team


is small and they commonly at
the university and constantly
see each other, it would be
necessary

to

communicate

verbally.
Online Help Desk
This will be used by the
client

to

changes

request
in

the

some

developed

software or other concerns.


They may send their request
through e-mail or through the
meeting

together

with

the

team. This tool will be also


used to help the proponents
connect

with

end-

users/

cashier. They can submit bug


reports or enhancement report
through

emails.

The

proponents can reply with the


message

and

take

further

actions.
Social Networking Site
This tool is commonly
used to communicate online.
The client may announce the
changes
Also,

Point- of- Sales with Price Management Module

the

or

enhancements.
developers

can

75

communicate with each other


by this
3.2.2.4.2

Work

products

and

documentation

Verbal suggestions

E-mails and chats

Notes

of

end-

users

suggestions

Documentation of test

3.2.3 SOFTWARE QUALITY ASSURANCE OVERVIEW


This section gives a general overview of the Software
Quality Assurance Plan (SQA) for Point- of- Sales with Price
Management Module. SQA will focus on the management issues
and the process specific activities that enable a software
organization to ensure that it does. SQA plan provides a help for
instituting quality assurance in doing the proposed module.
SCOPE AND INTENT OF SQA ACTIVITIES
The objectives of SQA are:

Point- of- Sales with Price Management Module

76

A quality management approach


Effective software engineering technology (methods and tools)
Formal technical reviews that are applied throughout the software

process
A multi testing strategy is draw
Control of software documentation and the changes made to it.
A procedure to assure compliance with software development

standards when applicable


Measurement and reporting mechanisms
To inform every user of the proposed module

REVIEWS AND AUDITS


A formal and technical review (FTR) is a software quality assurance
activity that is performed by software engineers. The objectives of FTR
are:
1.

To uncover errors in function, logic, or implementation for any

representation of software;
2.
To verify that the software under review meets its requirements;
3.
To ensure that the software has been represented according to
predefined standards;
4.
To achieve software that is developed in a uniform matter;
5.
To make projects more manageable.
3.2.3.1

GENERIC REVIEW GUIDELINES


ISO 9001 is the quality assurance standard that applies to
software engineering. The following are the 20 requirements
delineated. And the proponents are trying to follow these as
quality assurance plan.
-

Management Responsibility
Quality System
Contract Review
Design Control
Document and Data Control
Purchasing
Control of Customer Supplied Product

Point- of- Sales with Price Management Module

77

Product Identification and Trace Ability


Process Control
Inspection and Testing
Control of Inspection, Measuring and Test Equipment
Inspection of Test Status
Control of Nonconforming Product
Corrective and Preventive Action
Handling, Storage, Packaging, Preservation and Delivery
Control of Quality Audits
Training
Servicing
Statistical Techniques

CONDUCTION A REVIEW
There are two kinds of reviews, review case with the enduser and review case with other proponents.
For the changes that will affect the end user when they
use the system, the proponents must consult the end- users first.
But first, every proponents of the group must have agreed with
the change and must have a good record of the project before
and after changes.

ROLES AND RESPONSIBILITIES


Below are listed the proponents name corresponds with
their position:

Point- of- Sales with Price Management Module

78

Project
M anager

D ocum ent
S pecialist

B usiness
A nalyst

Lead
Program
m er

S ystem
A nalyst

Project Manager: Marayag, Vivian

Business Analyst: Riodique, Jayson

System Analyst: Elepana, Mary Joylyn

Documents Specialist: Decelo, Angelo

Lead Programmer: Sale, RJay

REVIEW WORK PRODUCT


The proponents shall review the proposed system as
often as they could to ensure the quality of the system. Anything
that will be noticed while developing the proposed system shall
be documented and arrange as soon as possible.

3.2.3.2

FORMAL TECHNICAL REVIEWS


FTR that the proponents will be conducting during system
development:

Description of Review Walkthroughs

Point- of- Sales with Price Management Module

79

This review mainly focuses on the integration of


the parts such as interfaces, form, and database. The
Project Manager will ask the other team members to
do walkthroughs with the presence of the Lead
programmer.

Description of Review Inspection


This review mainly focuses on the correctness
of the parts that the System Analysts designed.
Usually the Project Manager allows the other team
member to do a test.

System Specification Review


The systems specification is usually changed
after each weekly meeting, and after each meeting
with the client.

Software Project Plan Review


The purpose of software project plan is over
look of the whole project.

RMMM Review
RMMM is use to prevent, monitor and manage
the risk.

Requirements Reviews (Models, Specification)


Software

requirements

stated

the

data

requirement, specification.

Data Design Review


The Data Design Document is about the data
flow between each form (interface), and forms to the
database.

Architectural Design Review


The Architectural Design Document is about the
whole project design, layout and data flow.

Point- of- Sales with Price Management Module

80

Interface (GUI)
Up on the request of the client, the proponents
will design the interface from the previous version.

Component Design Review


The proponents will also do integration and help
desk for a period of time. And do some database reengineering for the clients database to make it more
efficient and suit for project need.

Code Review
Errors, bugs, glitches that were found will be
reviewed according to the codes being applied to fix
encountered problems.

Test Specification Review


This will be checking of the features of the
proposed module if objectives are met.

Change Control Reviews and Audits


Change control of the proposed module shall
conduct are review and audits will be applied.

After each form (interface) the proponents designed, a


test will be done on the interface of the system. Meeting is done
and the proponents must look up the interface of the system to
do an inspection.

DESCRIPTION OF REVIEW WALKTHROUGHS


The review will mainly be focusing on the
integrations for the parts that the proponents designed
(such as interfaces, form, and database).

DESCRIPTION OF REVIEW INSPECTION

Point- of- Sales with Price Management Module

81

The review will be focusing on correctness of the


parts that the proponents designed in the system
development.
3.2.3.2.1

SYSTEM SPECIFICATION REVIEW


Usually change after each meeting with the
proponents and their adviser. For this moment,
most of the systems designs have been settle
down. Bug fixing is done here originally.

3.2.3.2.2

SOFTWARE PROJECT PLAN REVIEW


The purpose of software project plan review
is to over look the whole project.

3.2.3.2.3

RMMM REVIEW
RMMM,

Risk

Mitigation,

Monitoring

&

Management are used to prevent, monitor and


manage the risk.
3.2.3.2.4

REQUIREMENTS REVIEWS (MODELS,

SPECIFICATIONS)
Software Requirements stated the data
requirement and specifications.
3.2.3.2.5

DATA DESIGN REVIEW

Point- of- Sales with Price Management Module

82

The Data Design Document is about the


data flow between each form (interface) and forms
to the database.
3.2.3.2.6

ARCHITECTURAL DESIGN REVIEW


The architectural Design Document is about
the whole project design, layout and data flow.

3.2.3.2.7

INTERFACE (GUI)
Interface is the design of the proposed
module and known as front- end of the system.

3.2.3.2.8

COMPONENT DESIGN REVIEW


Beside of the Interface, components of the
front end and back end will be checked to make it
more efficient and suit to project needed.

3.2.3.2.9

CODE REVIEW
Reviewing of codes is done to check the
errors and prompt a solution to it.

3.2.3.2.10

TEST SPECIFICATION REVIEW


Testing of systems specs will be done for
compatibility issues with other hardware that the
system will be installed.

3.2.3.2.11

CHANGE CONTROL REVIEWS AND AUDITS


It is done to manage and control reviews
and audits properly.

3.2.3.3

SQA AUDITS

Point- of- Sales with Price Management Module

83

The proponents will have a weekly report on the individual

performance for the past week. Any problems, questions regardless on the
performance of the proponents will be noted.

Members will write part of the help menu that related to their

design parts.

Any changes that will be done to the project making must inform

the co- proponents and their adviser before implementing the changes
throughout the process of the system
3.2.3.4

PROBLEM REPORTING AND CORRECTIVE ACTION/

FOLLOW UP
This section will describe problem reporting mechanisms
that occur as a consequence of the FTRs that are conducted
and the means for corrective action follow- up.
3.2.3.4.1

REPORTING MECHANISMS
In reporting mechanisms, the system will
give the reports of sales to the integrating system.
After every transaction and at the end of the day,
sales reports will automatically produce.

3.2.3.4.2

RESPONSIBILITIES
Below are listed the proponents name
corresponds with the position

Point- of- Sales with Price Management Module

84

Project
M anager

D ocum ent
S pecialist

B usiness
A nalyst

Lead
Program
m er

System
Analyst

Project Manager: Marayag, Vivian

Business Analyst: Riodique, Jayson

System Analyst: Elepana, Mary Joylyn

Documents Specialist: Decelo, Angelo

Lead Programmer: Sale, RJay

3.2.3.4.3

DATA COLLECTION AND VALUATION


To

properly

conduct

software

quality

assurance, data about the systems process should


be collected, evaluated and disseminated.
The

proponents

conducted

researches,

interviews and guidance to their adviser to collect


data needed to develop the proposed module.

3.3

SOFTWARE QUALITY ASSURANCE PLAN


3.3.1 INTRODUCTION

Point- of- Sales with Price Management Module

85

Software Quality Assurance Plan (SQA) is implemented to make


the quality of the system more efficient and eliminate the system
discrepancies. This section gives a general overview of the Software
Quality Assurance Plan (SQA) for Point- of- Sales with Price
Management System.
3.3.1.1

SCOPE AND INTENT OF SQA ACTIVITIES


This section contains the range of all the SQA
activities by giving the objectives and these are as
follows:

A quality management approach


The proponents shall have a proper setting of
standards that will meet a good quality- based system.
Effective software engineering technology
The proponents shall use software programs that
are at the edge of technology and being used by many.
Formal Technical Reviews that are applied
throughout the process
The proponents shall review the process of the
proposed module known as Formal Technical Reviews

to ensure the quality of the proposed module.


A multi testing strategy is draw
After codings, sort of testing must be done to check
the discrepancies of the proposed module.
Control of software documentation

and

the

changes made to it
All changes made while doing the proposed

module shall be documented.


A procedure to assure compliance with software
development standards when applicable
The proponents shall check if standards are met in

doing the software module.


Measurement and reporting mechanisms
Reports produced by the proposed module shall be
properly measured to give proper information.

Point- of- Sales with Price Management Module

86

To define the approach that will be used in quality


management
The proponents shall elaborate the ways in

maintaining the good quality of the proposed module.


To describe the methods and tools or the software
Softwares and hardwares being used in developing
the proposed module shall be explained.
engineering technology for the development and
testing of the software
Proper use of software and hardware must be

observed while developing the proposed module.


To know all the personnel that needs to be
involved.
The proponents itself must know their parts in dong

the proposed module.


Create a procedure to assure compliance with the
software development standards when applicable.
The proponents shall get the guide of the
standards in the project study book because it has the
standards in doing the proposed module and its
documentation.

3.3.1.2

SQA ORGANIZATIONAL ROLE


Below

are

listed

the

proponents

name

corresponds with the position

Point- of- Sales with Price Management Module

87

Project
M anager

D ocum ent
Specialist

Business
Analyst

Lead
Program
m er

S ystem
A nalyst

Project Manager: Marayag, Vivian

Business Analyst: Riodique, Jayson

System Analyst: Elepana, Mary Joylyn

Documents Specialist: Decelo, Angelo

Lead Programmer: Sale, RJay

3.3.2 SQA TASKS


These are the following task that we have for Software Quality
Assurance:
Voting System
When it comes to decision making about the proposed
module, voting must be practiced to ensure that majoritys

decision must be followed.


Have a good communication and relationship in the client
Good communication with the clients could avoid

problems while developing the proposed module.


Create a system with an extensive and detailed design
The proponents shall focus on not just the interfaces/
front- end but also the functional design of the system itself.

Point- of- Sales with Price Management Module

88

3.3.2.1

Task Overview
The tasks stated above will cover the quality
control of the project, the design that will be use
conforming on the implemented design of the system, the
time and cost for the project, minimizing the errors that
the connected modules will encounter, problem tracking
and data flow.

3.3.2.2

Standard, Practices and Conventions (SPC)


Voting System
The proponents would want the decision in
developing the proposed module to be decided by the use
of majority decisions.
In touch with the end- user
The proponents conducted interviews with the end
users about the process on how they use their POS
systems.
System Analysis
The proponents analyze the problems that are
gathered, collect all information, and analyze

the

opportunities about the proposed module.


Researches
The proponents conducted researches about the
proposed module to collect additional information in
developing the proposed module.
3.3.2.3

SQA Resources

Point- of- Sales with Price Management Module

89

Research modules The proponents searched for


sample modules that can be used as a guide in
developing the proposed module
Adviser The proponents ask guidance to their adviser if
the system being developed has the quality and capability
to meet the standards.
3.3.3 REVIEWS AND AUDITS
A formal technical review (FTR) is a software quality
assurance activity that us performed by software engineers. The
objectives of FTR are:

To uncover errors in function, logic or implementation of proposed

module
To verify that the proposed module meets its requirements
To ensure that the proposed module meet the predefined

standards.
To achieve software that is developed in a uniform manner

3.3.3.1Generic Review Guidelines


3.3.3.1.3

Conducting a Review
The

proponents

will

be

having

reviews

in

developing the proposed module

Documentation Review Review the documents and its


format, review updates throughout the system making
process.

Objective Review Review the proposed modules


objectives if the proponents are in the right way of
developing the proposed module.

Point- of- Sales with Price Management Module

90

Interview Review Interview with the user of the system


must be reviewed accordingly to ensure all details must
be taken.

System Development Review A review in the systems


processes must be done to ensure that the proposed
module is doing the objectives of the project.

3.3.3.1.2

Roles and Responsibilities


Below

are

listed

the

proponents

name

corresponds with the position

3.3.3.1.3

Project Manager: Marayag, Vivian

Business Analyst: Riodique, Jayson

System Analyst: Elepana, Mary Joylyn

Documents Specialist: Decelo, Angelo

Lead Programmer: Sale, RJay

Review Work Product


The proponents shall review the proposed module
as often as they could to ensure the quality of the system.
Anything that will be noticed while developing the
proposed module shall be documented and arrange as
soon as possible.

3.3.3.1.4

Formal Technical Reviews


The proponents shall observe, check and outright
the process of the proposed module as often as they
could.

Point- of- Sales with Price Management Module

91

Description of Review Walkthroughs


This review mainly focuses on the integration of
the parts such as interfaces, form, and database. The
Project Manager will ask the other team members to
do walkthroughs with the presence of the Lead
programmer.

Description of Review Inspection


This review mainly focuses on the correctness
of the parts that the System Analysts designed.
Usually the Project Manager allows the other team
member to do a test.

System Specification Review


The systems specification is usually changed
after each weekly meeting, and after each meeting
with the client.

Software Project Plan Review


The purpose of software project plan is over
look of the whole project.

RMMM Review
RMMM is use to prevent, monitor and manage
the risk.

Requirements Reviews (Models, Specification)


Software

requirements

stated

the

data

requirement, specification.

Data Design Review

Point- of- Sales with Price Management Module

92

The Data Design Document is about the data


flow between each form (interface), and forms to the
database.

Architectural Design Review


The Architectural Design Document is about the
whole project design, layout and data flow.

Interface (GUI)
Up on the request of the client, the proponents
will design the interface from the previous version.

Component Design Review


The proponents will also do integration and help
desk for a period of time. And do some database reengineering for the clients database to make it more
efficient and suit for project need.

Code Review
Errors, bugs, glitches that were found will be
reviewed according to the codes being applied to fix
encountered problems.

Test Specification Review


This will be checking of the features of the
proposed module if objectives are met.

Change Control Reviews and Audits


Change control of the proposed module shall
conduct are review and audits will be applied.

3.3.3.1.5

SQA Audits
a.

Any changes must be immediately presented to

other members before doing so. These changes are


small but still different from the current ones.
Point- of- Sales with Price Management Module

93

b.

After presenting the changes in the team members,

the client should also know the changes made. Clients


will be notified for small changes, while an agreement
between the client and the development team should be
made for major changes.
c.

Past and revised versions of the project will also be

recorded. The documents will be noted to identify what


kind of revision was made and by who.
3.3.4 PROBLEM REPORTING AND CORRECTIVE ACTION/ FOLLOW- UP
This section will describe problem reporting mechanisms that occur as
a consequence of the FTRs that conducted and the means for corrective
action and follow- up.
3.3.4.1

Reporting Mechanisms
It shows information about the procedure in producing
reports about quality assurance. The proponents shall make
sales, terminal and price reports.

3.3.4.2

Responsibilities
Below are listed the proponents name corresponds
with the position

Project Manager: Marayag, Vivian

Point- of- Sales with Price Management Module

94

3.3.4.3

Business Analyst: Riodique, Jayson

System Analyst: Elepana, Mary Joylyn

Documents Specialist: Decelo, Angelo

Lead Programmer: Sale, RJay


Data Collection and valuation
The proposed Point- of- Sales with Price Management
Module shall collect information especially on transactions and
pricing of products. After the data were gathered, information will
be sent to other modules by means of integration.

3.3.4.4

Statistical SQA
Statistical quality assurance reflects a growing trend
throughout industry to become more quantitative about quality.
For software, statistical quality assurance implies the following
steps:

Information about software defects is collected and categorized

An attempt is made to trace defect to its underlying cause (e.g.,

nonconformance to the specification, design error, violation of standards and


poor communication with customer).

Using the Pareto principle (80% of the defects can be traced to 20% of

all possible causes), isolate the 20% (the vital few).

Once the vital few causes have been identified, move to correct the

problems that have caused the defects.


3.3.5 SOFTWARE PROCESS IMPROVEMENT ACTIVITIES
Determinants for Software Quality and Organizational Effectiveness

Product
Point- of- Sales with Price Management Module

95

Business
Conditions

Customer
Characteristics

Process
People

3.3.5.1

Development
Environment

Technology

Goal and Object of SPI


Here are the goals of SPI:
1.
Errors and defects are categorized by origin
(e.g., flaw in specification, flaw in logic, nonconformance to
standards).
2.
To correct each error and defect is recorded.
3.
The number or errors and defects in each
category are counted and ordered in descending order
4.
The overall cost of errors and defects in each
category is computed.
5.
Resultant data are analyzed to uncover the
categories that result in highest cost to the organization.
6.
Plans are developed to modify the process with
the intent of eliminating (or reducing the frequency of
occurrence of) the class of errors and defects that is most
costly.

Field
Logic

%
Reason
3 None of the member has any experience on doing a project in this
0 size, or the experience on the project in this degree of difficulties.

Point- of- Sales with Price Management Module

96

Interface
Data
Handlin
g
Error
Checkin
g

2
5
1
5
1
0

HW /
SW

1
0

Standar
d

1
0

Table No 3.3

Up on the request of the client, the proponents will design the interface
from the previous version.
This project involved a lot of data accessing / storing, data flow
between each interfaces. It's not easy to keep track of them. And the
queries that the database used are pretty much outdated.
Since the member have a very close contact with the client, and have
done an exceptional work on research and study the old version, the
member can keep the field under 10%.
The proponents will also do integration and help desk for a period of
time. And do some database re-engineering for the clients database to
make it more efficient and suit for project need.
Since the member has no experience on such degree of project, so
other errors might be uncover, but the member must be optimist since
they did a pretty good research on the project, and spent many times
on designing phase before any actual coding.
Errors that must expect on this project.

3.3.5.2

SPI Tasks and Responsibilities


Below

are

listed

the

proponents

name

corresponds with the position

Project Manager: Marayag, Vivian

Business Analyst: Riodique, Jayson

System Analyst: Elepana, Mary Joylyn

Documents Specialist: Decelo, Angelo

Lead Programmer: Sale, RJay


Since the proponents are not a large team, the
responsibilities of each team member will do SPI activities. Each

Point- of- Sales with Price Management Module

97

proponent has the responsibility in improving the process of the


proposed system. It is important to produce a high- quality
system that will meet customer satisfaction.
3.3.6 SOFTWARE CONFIGURATION MANAGEMENT AND OVERVIEW
Since the time of the software development, the proponents will be making
changes from the original plans. Software Configuration Management Plan is
developed so that the proponents can identify changes, control the changes,
making sure that the plan is implemented correctly and to make sure that all
proponents, clients/ end- users are able to know all the changes. For further
information, please go to the document entitled, Software Configuration
Management Plan.
3.3.7 SQA TOOLS, TECHNIQUES, METHODS
The proponents have described a lot of tools, techniques and methods for
SQA using voting system, in touch with the end- user, system analysis and
researches to minimize errors. Different tools had been use for the SQA for
the proposed project using software review, problem tracking, the proponents
tried to follow the ISO 9001 Standards as the proponents organizational
structure,

responsibilities,

procedures,

processes

and

resources

for

implementing quality management.

3.4

SYSTEM SPECIFICATIONS
3.4.1 INTRODUCTION

This section gives a general overview of Point of Sales with


Price Management System.
3.4.1.1

GOALS AND OBECTIVES


The main purpose of Point of Sales with Price
Management System is to automate the entire process
and keep the manual processes.

Point- of- Sales with Price Management Module

98

The goals of the proposed module are:

To make checkouts and transaction process efficient


A Point- of- Sale system enables cashiers to
process transactions and serve customers efficiently, and
allows managers to maintain tight control. The cashier
uses his or her handheld scanner to read the cost and
description of every item. The system automatically totals
the quantities, deducts suitable discounts, and applies
tax.

To secure records and cash in the cash register


The proponents will develop a system that can
secure the records of transactions, prices and receipts.
Also the cash being inserted at the cash drawer will be
managed and secured by having a system that is only
accessible by authorized users.

To reduce pricing discrepancies


The proponents will create a system where the
prices of the products, SKUs and price tags can be
added, modified and can be easily updated in no time and
in less likely to have mistakes.

To generate valuable outputs


In any Point- of- Sale System, printing of receipt is
a must- important feature so this will not be excluded in
the system. To add a feature that will produce a receipt
where all of the transactions information will be inputted.
Also, sales report can also be made after each day.

Point- of- Sales with Price Management Module

99

Another output is for producing SKUs and price tags for


updating the price of the products accordingly.

To have a system integration with other connected


systems
The proponents will create a system that can
synchronize the proposed modules database to other
systems databases to acquire needed information and
also to share information through the use of database.

To create a system where it can meet customer


satisfaction
The proponents shall create a system that will
speed the process of transaction and shall manage the
prices of products, meeting customer satisfaction.

The objectives of the proposed module are:


To create an automated system
To create a Point- of- Sale System that will
eliminate the manual efforts in the process and make an
understandable and easily- used system. Integrate barcode scanners and credit card authorization ability with
the POS system.

Security of information
To secure all the information including the records
of transactions, receipts of customers and sales of the
company pertaining to the point- of- sale by putting
security features to the proposed module.

To include Price Management

Point- of- Sales with Price Management Module

100

To create a system where price management can


be

updated

rapidly,

discrepancies.

Improve

accurately
pricing

and

will

accuracy,

avoid
identify

underperforming products and markets, analyze and


respond faster to changing market conditions and
implement differentiated pricing policies like value- based
pricing.

To produce valuable outputs


To create a system where sophisticated and
valuable outputs can be produced like informative
receipts, reports and price tags to improve further from
the primitive way.

To manage transaction process of products properly


The proponents will include proper management of
voided products to the proposed module to avoid
inventory and sales discrepancies.

To save time in transaction processes


To make the transaction process customer- friendly
that holding of transactions will be implemented at the
proposed module to meet customer satisfaction in their
needs without repeating the transaction process of
purchasing.

To eliminate system malfunctions in automated


process

Point- of- Sales with Price Management Module

101

Hanging of system is caused by hardware and


software malfunctions. The proponents would want to
eliminate the problem and avoid system failures by the
use of the proposed module.

To create a mobile app for price viewing and


purchasing of products
The proponents will create an android application
to provide users in price viewing of the products and then,
purchase them using the mobile app and update the
system.

3.4.1.2

SYSTEM STATEMENT OF SCOPE


In this section, the general requirements of the
proposed module will be discussed.

Record Purchase Product This is by means of making


transactions and accepts different kinds of modes of
payments.

Record Payment The proposed module can record


payments, it is essential to every transaction to ensure the
safety of money being collected.

Print Invoice/ Receipt The proposed module can


produce invoice and receipt to give a transaction copy for
the customer.

Price Tagging Used to put price on specified products


3.4.1.2.1

General Requirements

Point- of- Sales with Price Management Module

102

The following general requirements


were laid out for the proposed Point of Sales
with Price Management Module:
1.

Interface
The proposed module will be
a user-friendly interface.

2.

Database
The proposed module shall
have a database so that data could
have a proper storage.

3.

Training
The users of the proposed
module shall have proper training
before using it.

4.

Mobile Apps
The proposed module will be
having a mobile application.

5.

Free Format Query


The users of the proposed
module

can

modify

the

system

accordingly.
6.

Personalized Screen
Personalized

screens

according to the user of the module.


7.

Point- of- Sales with Price Management Module

Import Export

103

The proposed module can


Import and Export database.
8.

Analytical Reports
Reports

will

be

produced

according to the requirements of the


proposed module.
3.4.1.3

SYSTEM CONTEXT

Specify the benefits of the designs


applied in the module.

User-friendly

interface

for

an

organized system resulting to more


faster processing of transactions

Database Design structure following


the

business

intelligence

of

the

proposed module.
3.4.1.4

MAJOR CONSTRAINTS
The proponents specified the
constraints of the system in terms of
design
Developing Environment
The use of Open Source Software and a
Proprietary Software is an advantage in the
system. From the flexibility of the open
source and security of the proprietary
produces powerful system.
Compatibility

Point- of- Sales with Price Management Module

104

The proposed system can be used in


different environment and will encounter
minimal error.
Time
The proponents only have limited
time in doing the project because of other
matters. The proponents will have to do a
double time to fulfill the documentation.
Funding
Funds needed in hardware used in
the proposed module are a major constraint.
The proponents would want to ask help with
the other groups in attaining these needed
hardwares.

3.4.2 FUNCTIONAL DATA DESCRIPTION


This section describes overall system function and the
information domain which it operates.

DATA DESCRIPTION
3.4.2.1

Major Data Objects:

Point- of- Sales with Price Management Module

105

3.4.3 HUMAN INTERFACE DESCRIPTION


Cashier
The cashier can only manipulate the proposed modules
functionality of transactions. The cashier can scan products, apply
discounts, accept payments and print receipts based on the individual
transactions.
Cashier Supervisor
The cashier supervisor guides the cashier in his/ her job. The
cashier supervisor also manages the price by adding, alternating and
Point- of- Sales with Price Management Module

106

applying discount rates. Another job of the CS is to manage SKUs and


price tags and be printed.
Price Clerk
Price Clerk manages the price management of the proposed
system. His job is to change, add and modify prices of specific
products. Also, his job is to put price tags, print, put discounts, and all
related to price management will be the job of price clerk.
Program Structure
Provide a diagram showing the program structure of the system in
terms of process and overall system.
System Setup
Product
Product Category
Location
Store
Price
Payment Type
Membership
Discount
Promos
Transaction
Record Purchased Product
Record Payment
Price Tagging
Queries
List of Purchased Product
List of Promos
List of Memberships
Reports

Point- of- Sales with Price Management Module

107

Invoice/Report
Sales Report
Terminal Report
Product Price Report
Proof List Report
Utilities
Configuration
Logout
Description for Components:
Checkout Supervisor
Cashier
Cashier Supervisor

3.4.4 USER- INTERFACE DESIGN


3.4.4.1 Description of the User- Interface
The proponents separated the interface of
Point- of- Sales from Price Management. Reasons are:

Pos screens and interfaces are different from Price

Management
Pos and Price Management are different and theyre

individual systems.
Pos and Price Management have different users.

3.4.4.2 Screen Images

Point- of- Sales with Price Management Module

108

POS Main Screen:

Price Management Main Screen:

3.4.4.3 Objects and Actions

Point- of- Sales with Price Management Module

109

Login Screen
Main Menu
Record Purchased Product
Payment
Price Tagging
3.4.4.4 Interface Design Rules
Provide rules for the interface design of the system
1. Strive for consistency
2. Enable frequent users to use shortcuts
3. Offer informative feedback
4. Design dialog to yield closure
5. Offer simple error handling
6. Permit easy reversal of actions
7. Support internal locus of control
8. Reduce short-term memory load
3.4.4.5 Components Available
Below are the components that will be used in the
interface of the proposed module.
1. Basic Controls
2. Interactive Displays of Highly Formatted Information
3. Un-editable Information Display
4. General-Purpose Containers

Point- of- Sales with Price Management Module

110

5. Special-Purpose Containers
3.4.4.6 Intrinsic Controls
Below are the intrinsic controls that will be
used in the interface of the proposed module:
Text Box
Label
Line
Image
List Box
Scrollbars
Command Button
Menu
Combo Box
Check Box
Option Button
3.4.4.7 Active XControls
Below listed are the activeX controls that will be
used in the interface of the proposed module.
Data Repeater
Date Time Picker
MS Flex Grid
Tree View
Status Bar
Tool Bar
Common Dialog

3.4.4.8 Restrictions, Limitations and Constraints


Provide

the

Restriction,

Limitations,

and

constraints of the system with in terms of design

The Cashier Supervisor will have the full control of the

System
Cashier can only Record Purchased Product and
Payment, Also to Issue Invoice/Receipt

Point- of- Sales with Price Management Module

111

The Price Clerk shall manage the Price Management of


the Module.

3.4.4.9 Testing Issues


Specify Testing Issues
System Interface
Login Window
System Setup
Transactions
Search Engine
Integration
Printable and Viewable Reports
3.4.4.10 Performance Bounds
Response time of search function
Best case Scenario Immediate
Worst case Scenario 10 seconds
Response time of browse function
Next list of records in 1 second
Done within 5 seconds
Log on - User login interval should be within 0.1 second

3.4.4.11 Critical Component Identification


1. Real-time search engine
2. Security of the System
3. Data Migration
4. Point of Sales System
5. Mobile App
6. Letter Generator

Point- of- Sales with Price Management Module

112

3.5

SOFTWARE REQUIREMENTS SPECIFICATION


3.5.1 INTRODUCTION
This section will describe the software requirements and
specifications of the proposed Point of Sales with Price Management
System.
3.5.1.1

GOALS AND OBJECTIVES

Provide a software that will automate process of Point- of- Sales

and Price Management


The proponents aim to create a system
where processes of transactions and workloads of

employees will be lightened in few clicks.


Create a Generic system to be used by any merchandising

company.
The proponents aim to create a system
where any merchandising companies can cope on with it

and use its full functionality without having a problem.


The system is integrated with other system of the Merchandising

system.
The proponents aim to create a system
where it can pass and collect data with other connected
systems.

Point- of- Sales with Price Management Module

113

3.5.1.2

SYSTEM STATEMENT OF SCOPE

Record Purchase of Product


The

proposed

module

shall

record

purchased products for transaction process.

Record Payment
The

proposed

module

shall

record

payments from cash, debit, credit card and

certificates.
Print Invoice/ Receipt, Reports and Price Tags
The proposed module shall print invoice/
receipt depending on the type of payment given by
a customer during transactions, daily Sales and
Terminal Reports and also Price Tags.

Price Tagging
The proposed module shall be able to
apply price and discounts on products.

3.5.1.2.1

General Requirements
The following general requirements
were laid out for the proposed module
named

Point

of

Sales

with

Price

Management Module:

System Functionality
The proposed module shall be 100%
at its full functionality means all of its

Point- of- Sales with Price Management Module

114

features will be implemented when it is


already done.

Interface
Interface is important in every system
because it guides the user according to
the functionalities the system have. It is

the front- end of the system itself.


Database
Database is the back- end of the
system. Data being gathered by the
system went to the database to be

stored, keep and use as information.


Training/Support
Training/ Support is needed to guide

the user in using the system.


Mobile Apps
Mobile
Application
will
implemented

on

android

be

operating

system.
Free Format Query
The system can be flexible to its user.
Personalized Screen
Screens intended for a specific user
of the system.
Import Export
The system has a functionality where
database can be imported and also
exported.

Analytical Reports
Reports were made according to the
purpose and scopes of the system.

Point- of- Sales with Price Management Module

115

3.5.1.2.2

Extended Enhancement
Mobile App
The proponents will add an android
mobile application for the price viewing and
purchasing of products.

3.5.1.3

SYSTEM CONTEXT

The proposed module shall be able to transact products


being purchased by the customers. Unlike other Point- ofSales system, the proposed module shall be easier
because fewer clicks will be made to create a transaction.
In Price Management, proper application of price, sales
and discounts will be made to observe accuracy of
information resulting of reliability. The proposed module
shall also update price, view and print daily sales and
terminal reports, receipt of customers and price tags. The
proposed module could also update its integrated
modules.

When

the

system

is

already

implemented,

all

functionalities are working and transactions shall be made


in no time, it will be reliable because accuracy of it is
observed.

If the proposed module successfully be implemented, it


will be used by three users at a time; cashier, checkout
supervisor and price clerk. The proposed module is
important to the merchandise because it manages the
sales of the store. Without the system, there will be no
accuracy

in

counting

sales,

products

cannot

determined and the merchandise will be in bankruptcy.

Point- of- Sales with Price Management Module

116

be

3.5.1.4

MAJOR CONSTRAINTS
Time
The proponents only have limited time in doing the
project because of other matters. The proponents will
have to do a double time to fulfill the documentation.
Funding
Funds needed in hardware used in the proposed
module are a major constraint. The proponents would
want to ask help with the other groups in attaining these
needed hardwares.
Integration
Integration is important because the proposed
module cant have data without connecting with other
modules.
Developing Environment
Developing Environment is a high constraint
because it can affect the project that is being made,
whether it may become successful or a failure.
Compatibility
Compatibility is also important so hardwares and
softwares being used must be properly checked to
observe its compatibility if it fits with other units to avoid
problems.

3.5.2 USAGE SCENARIO


3.5.2.1

USER- PROFILES

Point- of- Sales with Price Management Module

117

There will be three levels of users:

3.5.2.2

Checkout

Override)
Cashier (Transaction)
Price Clerk (Price Management)
Customer (Purchasing of Products)
Administrator (Full Accessibility of the system)

Supervisor

(POS

transaction,

System

USE- CASES
The following are the use cases of the proposed
Point- of- Sales with Price Management Module.
1. Login to the system
2. Record Purchased Product
3. Record Payment
4. Record Price Tagging
5. Generate Invoice/Receipt
6. Logout from system

3.5.2.3

Use Case Diagram


1. Login to the system
2. Record Purchased Product
3. Record Payment
4. Record Price Tagging
5. Generate Invoice/Receipt
6. Logout from System

Point- of- Sales with Price Management Module

118

3.5.2.4

Use Case Description


1. Login to the system
2. Record Purchased Product
3. Record Payment
4. Record Price Tagging
5. Generate Invoice/Receipt
6. Logout from system

3.5.2.5

Special Usage Considerations

Constraints of the system must be indicated


Administrator has full access in the system
Payment of products can be through credit card. If so, a
terminal will be used to record credit card details

3.5.2.6

Activity Diagrams
1. Login to the system
2. Record Purchased Product
3. Record Payment
4. Record Price Tagging
5. Generate Invoice/Receipt
6. Logout from system

3.5.3 DATA MODEL AND DESCRIPTION


3.5.3.1

Data Objects and Dictionary


POS:
POS_Purchased_Product Data Object

Point- of- Sales with Price Management Module

119

Trans_No

unique

number

assigned

for

Transaction Number
Prod_BarCode
A

unique

number

assigned

for

Product Barcode
Punch_Prod_Qty A number

assigned

for

Product

Quantity
Purch_amount

A number assigned for purchased

amount
Time_Scan

Scanned Time

POS_Terminals Data Object


Terminal_ID
Counter_No
Terminal_Desc

A unique ID given in Terminals


A unique number given in counters
Description for Terminals

POS_Return Data Object


Return_No
Trans_No
Prod_Barcode

A number given to return items


A number given to transactions
Identification assigned in Product

Barcodes
Return_Qty

Identification that were assigned in

return items
Return_Date
Remarks

Date Item were returned


Comment about returned item

POS_Transaction Data Object


Trans_No

A unique number assigned in every

Transactions
Terminal_ID

A unique identification assigned in

every Terminals
Emp_ID

A unique identification assigned in

every Employee
Trans_Date_Time Transaction Date and Time
Items_purchased Items that were purchased
Total_Amt
Total amount of transactions
Point- of- Sales with Price Management Module

120

Payment_type

Identification assigned for payment

types
Trans_Desc

Description for Transactions

POS_Pending Data Object


Trans_No

transactions
Customer_name

unique
unique

identification
identification

for

given

to

customer

POS_Privilege_Card Data Object


Trans_No

A unique identification assigned for

transactions
Mem_ID

A unique identification assigned for

members
Earned_Pts

Points earned

POS_GC Data Object


Trans_No

A unique identification assigned for

transactions
GC_No

A unique number assigned for Gift

Certificates
GC_Amt
GC_Exp
GC_Total_Amt

Amount of Gift Certificate


Expiration of Gift Certificate
Total amount of Gift Certificate

POS_Cash Data Object

Point- of- Sales with Price Management Module

121

Trans_No

A unique identification assigned for

transactions
Total_Amt
Change

Total amount of cash


Change of total amount tendered

POS_Card_Transaction Data Object


Trans_No

A unique identification assigned for

transactions
Card_No

A unique identification assigned for

card number
Card_Name
Card_BankName
Card_Pin
Card_Desc

Name of card
Name of Bank
Pin number of card
Description of card

POS_Void_Item Data Object


Trans_No

A unique identification assigned for

transactions
Prod_Barcode

Identification assigned in Product

Barcodes
Item_qty
Quantity of items
VoidItem_Description
Description of void item

POS_Mem Data Object


Mem_ID

A unique identification assigned for

members
Mem_Lname
Mem_Fname

Members last name


Members first name

Point- of- Sales with Price Management Module

122

Mem_Mname
Mem_Age
Mem_Gender
Mem_Bday
Mem_Add
Date_Reg
Earned_Pts

Members middle name


Members age
Members gender
Members birthday
Members address
Date registered
Members earned points

POS_Trans_Mem_PTS Data Object


Trans_No

A unique identification assigned for

transactions
Mem_ID
Gained_Pts

A unique ID assigned for members


Points gained by members

Price Management:
PM_Tag Data Object
Tag_Code
Code assigned for tags
Color_Code
Code assigned for colors
Promo_Discount Discounts for promos
Promo_Disc_Type
Type of discount
PM_Price_List Data Object
Price_Code
Code assigned for price
Prod_Code
Code assigned for products
Tag_Code
Code assigned for tags
P_vat
Price vat
P_price
Price
P_date_issue
Date where price issued

3.5.3.2

Relationships
The cashier makes up the transaction process by
getting the information of products and money tendered.
The cashier supervisor shall manage the restricted
features of pos that cashiers cannot access because of
security purposes.

Point- of- Sales with Price Management Module

123

The

price

clerk

shall

manage

the

price

management of the proposed system.

3.5.4 FUNCTIONAL MODEL AND DESCRIPTION


3.5.4.1

SYSTEM FLOW DIAGRAMS

Prompt user ID and password

Enter user ID and password

Verify Password

(No)
Incorrect Password
(Yes)

Access Granted

Point- of- Sales with Price Management Module

124

3.5.4.1.1

Activity Diagram for logging in the system

Log into System

Search for product/s

Add price

Determine Cashier Supervisor authorization

(No)

(Yes)

Save Product

Point- of- Sales with Price Management Module

125

3.5.4.1.2

Activity Diagram for adding product price

Log into System

Search for product/s

View product /s info

Determine Cashier Supervisor authorization

(No)

(Yes)

Edit record

Save record

Point- of- Sales with Price Management Module

126

3.5.4.1.3

Activity Diagram for viewing/ updating product price

Log into System

Select Product info

Enter Product Name

Display Information

3.5.4.1.4

Activity Diagram for viewing/ searching of products

Point- of- Sales with Price Management Module

127

Log into System

Determine user- authentication

(No)

(Yes)

Sales Report

Display Report

View Report

(No)

(Yes)
Print Report

Point- of- Sales with Price Management Module

128

3.5.4.1.5

Activity Diagram for viewing and printing sales report

Log in to system

Determine user authorization

(No)

(Yes)

Select Thermal

Print Receipt/ Invoice

3.5.4.1.6

Activity Diagram for printing receipt/ invoice

Point- of- Sales with Price Management Module

129

3.5.4.2

HUMAN INTERFACE
Cashier
The

cashier

can

only manipulate

the

proposed modules functionality of transactions.


The cashier can scan products, apply discounts,
accept payments and print receipts based on the
individual transactions.
Cashier Supervisor
The cashier supervisor guides the cashier in
his/ her job. The cashier supervisor also manages
the price by adding, alternating and applying
discount rates. Another job of the CS is to manage
SKUs and price tags and be printed.
Price Clerk
The system administrator manages the
system itself. Import/ export database and manage
the software and hardware configuration.
3.5.5 RESTRICTIONS, LIMITATIONS AND CONSTRAINTS
1.

The system shall be integrated with the other systems of the

Merchandising System
2.

All server side code shall be written in JAVA.

Microsoft SQL Server will be the database server of the system.


3.

Procurement will not be covered in the system.

Point- of- Sales with Price Management Module

130

3.5.6 VALIDATION CRITERIA


Functional Requirements
1. The transaction processes that are needed in the system should all
be working and can generate real time records.
2. Search engine on the Query section should produce a real time data
that is stored in the database. 3. Reports should be informational and
the contents should be based on the data that has been inputted in the
system and stored in the database.
4. The contents and setting should be based on the user (e.g. Admin,
Consignee).
5. The System set-up should be working in terms of generating on time
data that was inputted in the database.
6. The system should be well-integrated to the system that is related to
it.
7. Data migration should be flawless or data that are needed should not
be jammed or lost.
Non-Functional Requirements
1. The system should have a splash screen and it should be working.
2. As for the security of the system, the log in page should be working
and should be strict when it comes to inputting the username and the
password. The password should display asterisk (*) instead of the
actual password for the privacy and security purposes of the user.
3. The report should be viewable and can be printed.

Point- of- Sales with Price Management Module

131

4. System should have windows dialog for warning, errors, success and
conformation for the users awareness in the system.
5. The system should follow the standards that have been approved by
the Merchandising System and by the client
6. The data that have been inputted in the system should be stored in
the database.
7. System interface should be organized and easily understandable by
the users of the system.
8. The system should be well integrated to the other module or system.

Point- of- Sales with Price Management Module

132

3.6

SOFTWARE DESIGN SPECIFICATION


3.6.1 INTRODUCTION
This section describes the design for the proposed Point- ofSales with Price Management System.
3.6.1.1

GOALS AND OBJECTIVES


The goals of the proposed module are:

To make checkouts and transaction process efficient


A Point- of- Sale system enables cashiers to
process transactions and serve customers efficiently, and
allows managers to maintain tight control. The cashier
uses his or her handheld scanner to read the cost and
description of every item. The system automatically totals
the quantities, deducts suitable discounts, and applies
tax.

To secure records and cash in the cash register


The proponents will develop a system that can
secure the records of transactions, prices and receipts.
Also the cash being inserted at the cash drawer will be
managed and secured by having a system that is only
accessible by authorized users.

To reduce pricing discrepancies


The proponents will create a system where the
prices of the products, SKUs and price tags can be

Point- of- Sales with Price Management Module

133

added, modified and can be easily updated in no time and


in less likely to have mistakes.

To generate valuable outputs


In any Point- of- Sale System, printing of
receipt is a must- important feature so this will not
be excluded in the system. To add a feature that
will produce a receipt where all of the transactions
information will be inputted. Also, sales report can
also be made after each day. Another output is for
producing SKUs and price tags for updating the
price of the products accordingly.

To have a system integration with other connected


systems
The proponents will create a system that
can synchronize the proposed modules database
to other systems databases to acquire needed
information and also to share information through
the use of database.

To fulfill the EIS required functionalities


The proponents will add these required
functionalities of Enterprise Information System
(EIS) to the proposed modules objectives:

Facility for mobile apps


Personalized screens according to role (portal

based) for users


Import/ Export facility in migrating data from other

sources
Free reporting facility (user has the option what to

Point- of- Sales with Price Management Module

display)

134

6 Analytical reports in the EIS Analytics menu


To create a system where it can meet customer
satisfaction
The proponents shall create a system that
will speed the process of transaction and shall
manage the prices of products, meeting customer
satisfaction.

The objectives of the proposed module are:


To create an automated system
To create a Point- of- Sale System that will
eliminate the manual efforts in the process and
make an understandable and easily- used system.
Integrate bar-code scanners and credit card
authorization ability with the POS system.

Security of information
To secure all the information including the
records of transactions, receipts of customers and
sales of the company pertaining to the point- ofsale by putting security features to the proposed
module.

To include Price Management


To

create

system

where

price

management can be updated rapidly, accurately


and will avoid discrepancies. Improve pricing
accuracy, identify underperforming products and
markets, analyze and respond faster to changing
market conditions and implement differentiated
pricing policies like value- based pricing.

Point- of- Sales with Price Management Module

135

To produce valuable outputs


To create a system where sophisticated and
valuable outputs can be produced like informative
receipts, daily sales report and price tags to
improve further from the primitive way.

To manage transaction process of products properly


The

proponents

will

include

proper

management of voided products to the proposed


module to avoid inventory and sales discrepancies.

To save time in transaction processes


To make the transaction process customerfriendly that holding of transactions will be
implemented at the proposed module to meet
customer satisfaction

in

their needs without

repeating the transaction process of purchasing.

To eliminate system malfunctions in automated


process
Hanging of system is caused by hardware
and software malfunctions. The proponents would
want to eliminate the problem and avoid system
failures by the use of the proposed module.

To create a mobile app for price viewing and


purchasing of products

Point- of- Sales with Price Management Module

136

The proponents will create an android


application to provide users in price viewing of the
products and then, purchase them using the mobile
app and update the system.
3.6.1.2

SYSTEM STATEMENT OF SCOPE


3.6.1.2.1

General Requirements
The following general requirements
were laid out for the proposed Point of Sales
with Price Management System:

A way that the system will be limited to the


cashier, checkout supervisor, price clerk and
administrator usage.

A way that the system administrator can


view

the

cashiers

and

checkout

supervisors name, system logs, date, time.

A way that the cashier can manage his/ her


starting money at cash drawer.

A way that the cashier can make cash


transactions

A way that the cashier can make sales


invoice/ receipt with the cash transaction

A way that the cashier can make credit and


card transactions

A way that the cashier can make gift


certificate transactions

Point- of- Sales with Price Management Module

137

A way that the cashier can make sale sales


invoice/ receipt with the cash transaction

A way that the cashier can use members


points as a currency in obtaining products
having the equivalent points.

A way that the cashier can print the sales


information of his/ her day

A way that the checkout supervisor can


modify and view transaction

A way that the checkout supervisor can view


inventory of products

A way that the checkout supervisor can add


price of products

A way that the checkout supervisor can edit


price of products

A way that the checkout supervisor can add


discounts to the products

A way that the checkout supervisor can add


pwd (person with disability) discount to the
products

A way that the checkout supervisor can print


price tags

A way that the system administrator can


configure the system

3.6.1.3

SYSTEM CONTEXT

Point- of- Sales with Price Management Module

138

If

the

proposed

module

successfully

be

implemented, it will be used by three users at a time;


cashier, checkout supervisor and system administrator.
3.6.1.4

MAJOR CONSTRAINTS
Time
The proponents only have limited time in doing the
project because of other matters. The proponents will
have to do a double time to fulfill the documentation.
Funding
Funds needed in hardware used in the proposed
module are a major constraint. The proponents would
want to ask help with the other groups in attaining these
needed hardwares.

3.6.2 Data Design


3.6.2.1

Database Description
Below are mentioned all tables, their corresponding
attributes and a small description of each.
POS:
Table Name: POS_Terminals
Attributes: Terminal_ID, Counter_No, Terminal_Desc
Description: Table used for assigning terminal
Table Name: POS_Purchased_Product
Attributes: Trans_No, Prod_BarCode, Purch_Prod_Qty,
Purch_amount, Time _Scan
Description: Table used for Purchased Products
Table Name: POS_Return

Point- of- Sales with Price Management Module

139

Attributes: Return_No,

Trans_No,

Prod_BarCode,

Return_Qty, Return_Date, Remarks


Description: Table used for return items
Table Name: POS_Transaction
Attributes: Trans_No,
Terminal_ID,
Trans_Date_Time,

Emp_ID,

Items_Purchased,

Total_Amt,

Payment_type, Trans_Desc
Description: Table used for transactions
Table Name: POS_Pending
Attributes: Trans_No, Customer_name
Description: Table used for pending transactions
Table Name: POS_Mem
Attributes: Mem_ID,
Mem_Lname,

Mem_Fname,

Mem_Mname, Mem_Age, Mem_Gender, Mem_Bday,


Mem_Add, Date_Reg, Earned_Pts
Description: Table used for Membership
Table Name: POS_Privilege_Card
Attributes: Trans_No, Mem_ID, Earned_Pts
Description: Table used for Privilege Card
Table Name: POS_Void_Item
Attributes: Trans_No,
Prod_Barcode,

Item_Qty,

VoidItem Description
Description: Table used for void items
Table Name: POS_Card_Transaction
Attributes: Trans_No,
Card_No,

Card_Name,

Card_BankName, Card_Pin, Card_Desc


Description: Table used for Card Transactions
Table Name: POS_Trans_Mem_PTS
Attributes: Trans_No, Mem_ID, Gained_Pts
Description: Table used for viewing of members points
Table Name: POS_GC
Attributes: Trans_No,

GC_No,

GC_Amt,

GC_Exp,

GC_Total_Amt
Description: Table used for Gift Check
Point- of- Sales with Price Management Module

140

Table Name: POS_Cash


Attributes: Trans_No, Total_Amt, Change
Description: Table used for Cash

Price Management:
Table Name: PM_Tag
Attributes: Tag_Code, Color_Code, Promo_Discount,
Promo_Disc_Type
Description: Table used for Tags
Table Name: PM_Price_Lists
Attributes: Price_Code, Prod_Code, Tag_Code, P_vat,
P_price, P_date_issue
Description: Table used for Price Lists

3.6.3 Architectural and Component- Level Design

Maintenance & SelfTest


Administrat
Checkout
Cashier

Point- of- Sales with Price


Management Module

Price Clerk

Java
Netbeans
Point- of- Sales with Price Management Module

MS
SQL
141

3.6.3.1

Program Structure
3.6.3.1.1

Overall

Point- of- Sales with Price Management


Log- in

Main Screen

System
Setup

Transaction

Query

Report

Utility

Menu Items:
The following shows the architecture of the main menu:

System Setup
Tags
Promo Type
Transaction
Product Pricing
Product Promotion
Tag Printing
F1- Re- Print Receipt
F2 Payment
F3 Modes of Payment
F4 Customer Card

Point- of- Sales with Price Management Module

142

F5 Senior Citizen Card


F6 Pending Transaction
F7 Continue Pending Transaction
F9 Item Void
F10 Free Scan Product
F11 Input Barcode
F12 Return Product
Space Set Quantity
ESC Cancel/ New Transaction
Query

List of Purchased Product

List of Promos
Report

Sales Report

Terminal Report

Proof List Report

Price List Report


Utility

Audit Trail

Configuration

Log- out
3.6.3.2

Description for Components

3.6.3.3

User Interface Design


3.6.3.3.1

Description of the User- Interface

Point- of- Sales with Price Management Module

143

3.6.3.3.1.1 Screen Images


POS:

Point- of- Sales with Price Management Module

144

Point- of- Sales with Price Management Module

145

Point- of- Sales with Price Management Module

146

Point- of- Sales with Price Management Module

147

Point- of- Sales with Price Management Module

148

Point- of- Sales with Price Management Module

149

Login Screens
3.6.3.3.1.2 Objects and Actions
Menu Items
3.6.3.3.2

Interface Design Rules


To improve

the

usability

of

an

application, it is important to have a welldesigned interface. These Eight Golden


Rules of Interfaces Design are a guide to
good interactive design.
1. Strive for Consistency

Point- of- Sales with Price Management Module

150

Consistent

sequences

of

actions should be required in similar


situations;

identical

terminology

should be used in prompts, menus,


and help screens; and consistent
commands

should

be

employed

throughout.
2. Enable frequent users to use shortcuts
As

the

frequency

of

use

increases, so do the users desires to


reduce the number of interaction.
3. Offer Informative Feedback
For every operation action,
there

should

be

some

system

feedback. For frequent and minor


actions, the response can be modest,
while

for

infrequent

and

major

actions, the response should be more


substantial.

4. Design dialog to yield closure


Sequences of actions should
be organized into groups with a
beginning, middle and end. The
informative

feedback

at

the

compilation of a group of actions


gives the operators the satisfaction of
accomplishments, a sense of relief,
the signal to drop contingency plans
Point- of- Sales with Price Management Module

151

and options from their minds, and an


indication that the way is clear to
prepare for the next group of actions.
5. Offer simple error handling
As much as possible, design
the system so the user cannot make
a serious error. If an error is made,
the system should be able to detect
the

error

and

comprehensible

offer

simple,

mechanisms

for

handling the error.


6. Permit easy reversal actions
This feature relieves anxiety,
since the user knows that error can
be

undone,

it

thus

encourages

exploration of unfamiliar options. The


units of reversibility may be a unit of
single action, a data entry, or a
complete group of actions.
7. Support internal focus of support
Experienced

operators

strongly desire the sense that they


are in charge of the system and that
the system responds to their actions,
designs the system to make users
the initiators of actions rather than the
responders.
8. Reduce short-term memory load

Point- of- Sales with Price Management Module

152

The

limitation

of

human

information processing in short-term


memory requires that displays be
kept simple, multiple page displays
be

consolidated,

windows-motion

frequency be reduced, and sufficient


training time be allotted for codes,
mnemonics

and

sequences

of

actions.
3.6.3.3.3

Components Available
Java

has

many

components

available, but only JFrame, JTextLabel,


JTextField, and JButton are being used in
library has been added also for the choosing
of date and time. MS SQL connector library
was also used for the connection of the
database.
3.6.3.4

Restriction, Limitations and Constraints


Time Time is so far the biggest restriction or constraint for the
proposed system. It is very important for the proponents to watch
the time spent over every phase of the software development
project. The proponents could have included many more
components to the system but time restricts from doing so.
Skills The proponents especially the lead programmers
programming and design skills is also one of the restriction. It
does not have as big of an impact on the project but it sure does
limit the project team from doing more addition to the projects.
Insufficient Resources Not having all the necessary
instruments also is a problem for the proposed module.

Point- of- Sales with Price Management Module

153

3.6.3.5

Testing Issues
3.6.3.5.1

Classes of Test
Test strategy and preliminary test
case specification are presented in this
section. The various tests to be conducted
are the following:
Login The first class of test is login which
will be done by authorized person for the
security and safety of all the records inside
the system. To access the system, the
specified user needs to enter the username
and password. The user cannot login with
incorrect username and password and error
message will be shown. Log in will be
observed when the integrated module which
is HR give the log- in screen to every
module.
Database connection This test class is
defined if the assigned database connection
has been successfully connected to the
database server.
Test System Configuration This test
class is used to test tags and promo types.
Test Transaction This test class is used
during POS. the process of transactions
worked properly if all of its functionalities are
applied and all working. Also, it tests product
pricing, product promotion and tag printing.

Point- of- Sales with Price Management Module

154

Test Query- This test class is used to test


list of purchased product and list of promos.
Test Report - This test class is used test all
of reports of the proposed module.
Test Utility This test class is used to test
audit trail, configuration and log- out.
3.6.3.5.2

Performance Bounds
The proponents have setup certain
bounds or criteria for the proposed module
so that by following that criteria will be able
to maintain quality and user friendliness of
the proposed module
Response time of search function
Best Case Scenario -> Immediate
Worst Case Scenario -> Fail to create
transactions
Response time of browse function
Completing a transaction When the
cashier

successfully

completed

transaction.
Done with a short period of time depends on
the items being scanned.
User should be able to log on within 0.1
second
3.6.3.5.3

Identification of Critical Components


Integration The connected modules must
be properly connected to share and get
proper information.
Mobile App The data being input must be
consistent with the proposed module.

Point- of- Sales with Price Management Module

155

Point- of- Sales with Price Management Module

156