SYSTEM INTEGRATION PLAN - PEPPER GREY POINT OF SALE USING MICROSOFT

VISUAL BASIC

1. Introduction
1.1 Test objectives
● Includes checklist
● POS policies are supported by computers
● POS (Point of sale) functions work correctly
● The system is easy to use by the end-users
● The system has a database in which allows administrators to view records and customer
information.

The objective of the system is to provide businesses with the ability to computerize, systematize
and correlate retail information. At the conclusion of the system the research team and the test
team are confident that the system will work according to specific requirements and will meet
business needs.

1.2 Scope of testing

The system integration test of POS will include of the following:
● Financial Calculations
● Point of sale
● Database which includes customer info and records

1.3 System Overview

The Pepper Grey small business that our project team purposely chose to make a POS system
which allows the business to

1.4 Definition and Acronyms

1.4.1 Definitions
a. Build - A functionally independent piece of software that supports a well-defined
logical subset of a system. A build can be tested independently and then integrated
with other builds. Builds can be migrated from one level of testing to another and
possibly installed independently of the rest of the system.
b. System Integration- refers to the process by which multiple individual
subsystems or sub-components are combined into one all-encompassing larger
system thereby allowing the subsystems to function together.
c. POS -which is the point at which a customer purchases and pays for products,
such as on a website or at a store checkout. The POP is the area that surrounds
the POS, where customers often encounter promotional activities or other
products.
 d. Prototype - A working model of the software to be built. Demonstrates look and
feel of
the software, but does not support all features and functions.
e. Databases- structured set of data held in a computer, especially one that is
accessible in various ways.
f. Test Tool - Any equipment that assists in testing.
g. Static Test - A verification performed without execution on a computer. For
example, reviewing a document for accuracy.
h. Unit Testing - A level of testing in which the smallest units of a system (i.e.,
modules)
i. are separately tested.

2. Approach
2.1 Assumptions/Constraints:
2.2.1 Assumptions
● The first build on the project was on december 8 whereas the completion
of the project is expected to finish by the month of january 1st week.
● The system will be ready for system integration on the 1st week of
january.

2.1.2 Constraints
● The system was expected to finish within 1 month and our project team
started by december so as expected that to test the system there might be
a few problems and issues

2.2.1 Software Components

All software modules in the pos, databases, and financial calculations will be
tested.

2.2.2 Requirements
All user requirements as specified in the Requirements Specification Document will be
tested.

2.3 Test Tools

1. Capture/Playback
2. Test Manager
3.3 Major tasks and deliveries

Contributors Task Start Deliverables

Erika Valconchaa, Drafting of system October 28,, 2021 The system has
Wenz Penaflorida, planning been completed yet
Angelo Dela pena, it hasn’t been done
Johnmark parot, perfectly because
Steve Gonzales of previous
selected business
so our project team
come up a solution
and purposely
choose a small
business

Erika Valconcha, Gantt Chart November , 2021 The project team

Wenz Penaflorida shares their
thoughts and ideas
regarding rough
schedules and how
we should provide
estimated dates for
instance.

Erika Valconcha ERD Class diagram November 17, 2021 I myself made and
ERD because we’re
going to use non
object oriented
programming