0% found this document useful (0 votes)
9 views50 pages

Chapter IV

Chapter IV outlines the methodology for a capstone project focused on developing a Sales and Inventory Management System (SIMS) for JAS Agri-Venture. It details the Agile methodology employed, including requirements analysis, design, development, testing, and deployment processes, while also documenting both functional and non-functional requirements. The chapter emphasizes the importance of stakeholder collaboration and iterative refinement throughout the project lifecycle.

Uploaded by

n15406237
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
9 views50 pages

Chapter IV

Chapter IV outlines the methodology for a capstone project focused on developing a Sales and Inventory Management System (SIMS) for JAS Agri-Venture. It details the Agile methodology employed, including requirements analysis, design, development, testing, and deployment processes, while also documenting both functional and non-functional requirements. The chapter emphasizes the importance of stakeholder collaboration and iterative refinement throughout the project lifecycle.

Uploaded by

n15406237
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 50

Chapter IV

Methodology

This chapter presents the approach that the researchers will utilize in the capstone project
creation. The chapter covers various procedures including the analysis of requirements,
documentation of requirements, design of software/systems/products, development plan, testing
plan, description of prototype, and implementation plan. Nevertheless, the methods and techniques
discussed in this section are open to potential refinement and adjustment, as the project is still
ongoing or subject to modification as part of the proposal.

The researchers plan to use the Agile methodology, which is part of the Systems
Development Life Cycle (SDLC), for this project. The Agile methodology was selected because it
emphasizes iterative development, collaboration, and flexibility, making it appropriate for adapting
to changing requirements and stakeholder feedback throughout the project lifecycle. Figure 4.1
depicts the SDLC method, which guides the analysis and design phases of the system.

Figure 4.1: Agile SDLC Model


21

4.1 Requirements Analysis

Requirement analysis is likely all about a process where the project team identifies, gathers,
and documents the needs and expectations of stakeholders for a software system or product. In this
section, requirements analysis is discussed by how the researchers would like to go on requirements
analysis and gathering utilizing the Agile SDLC Model. Specifically, as depicted below, here is
how the researchers will utilize the Agile Model:

• Requirements: During the requirements phase, the researcher's primary objective is


to collect and comprehend the project requirements. This stage requires working
closely with stakeholders to determine their requirements, prioritize features, and
establish the scope and limitations of the project.
• Design: During the design phase, the team responsible for development will create the
architectural and user interface design based on the requirements that have been
gathered. This stage will involve the team creating diagrams, such as system
architecture diagrams or UML diagrams, to provide a visual representation of the
system's structure. The design decisions are then made in an iterative process, with
feedback from both stakeholders and the development team guiding the process.
• Development: During the development phase, the team is responsible for coding and
implementing the designed solutions. Collaboratively, they work to build and integrate
features that are in line with the prioritized requirements.
• Testing: During the testing phase, the newly developed features undergo a thorough
testing process to verify that they fulfill the designated requirements and perform as
expected. The testing process is carried out at various levels, including unit testing,
which concentrates on examining small-scale functionalities, integration testing, and
system testing to ensure the entire system operates correctly.
• Deployment: Once the features are rigorously tested and approved, the system is made
available for end-users by deploying it to the production environment. To automate the
deployment process and decrease time-to-market, continuous deployment practices
may be adopted.
• Review: During the review phase, it is crucial to gather feedback from stakeholders
and assess the progress, performance, and outcomes of the project. This allows for the
identification of areas that need improvement and provides the opportunity to make
necessary adjustments for future iterations.
22

4.2 Requirements Documentation

This document outlines the functional and non-functional requirements for the Sales and
Inventory Management System (SIMS) for JAS Agri-Venture and Consultancy Corporation. This
system is designed to streamline the sales process, manage inventory efficiently, and provide
detailed reporting to improve decision-making. This document serves as a reference for the system's
development and implementation.

The purpose of this document is to define the requirements for the Sales and Inventory
Management System, ensuring that it meets the needs of the business president. By detailing both
the functional and non-functional requirements, this document ensures all aspects of the system are
understood and agreed upon before development begins.

This system will cover various aspects of sales and inventory management, including user
login, product inventory tracking, customer and supplier management, sales transactions, and
generating detailed reports. The system is designed for use by a single user (the business president),
with potential for future expansion to include additional users.

4.2.1 Functional Requirements

In this phase, the researchers have properly documented the functional requirements of the
system, which define the core features and functionalities the software must provide. These
requirements describe how the system will behave in response to user inputs, detailing the specific
tasks the system should perform. They are derived through close collaboration with stakeholders
to ensure that the system meets their needs. Each functional requirement is carefully outlined to
provide clear, actionable specifications for the development team. This ensures that the system will
provide the necessary services, such as user authentication, inventory management, transaction
processing, and reporting, to support business operations.
23

Table 4.2.1.1: Functional Requirements of the System – The table below outlines the essential
functions and features that the system must perform to meet user’s needs.

ID Functional Description Inputs Outputs Preconditi Postconditio


Requiremen on n
ts
FR Login/Logou Allows users to Username User User must User is
1 t securely login and Authentic have an logged in
Functionality and logout of Password ation account. and logged
the system. Status out.
FR Dashboard Displays an Dashboar User must User can
2 overview of d be logged access
system modules, Overview in different
with navigation modules
options. from the
dashboard
FR Transaction Allows users to Product Sale User must Receipt
3 Module create and selection, receipt have the generated
manage sales Customer necessary and
transactions, details permissions transaction
including recorded
printing
receipts.
FR Products Manages Product Updated User must Product
4 Module product details product have the information
information, (name, list necessary updated
including price, permissions
adding, editing, quantity)
and deleting
products.
FR Customers Allows users to Customer Updated User must Customer
5 Module manage details customer have the details
customer (name, list necessary updated
address, permissions
24

information and contact


track purchases. details)
FR Suppliers Manages Supplier Updated User must Supplier
6 Module supplier details supplier have the records
information, (name, list necessary updated
including contact permissions
adding, editing, details)
and deleting
suppliers.
FR Sales Report Generates and Date Sales User must Report
7 Module displays sales range, report, have generated
reports, filters sales permissions and
including (product) graph to view graphical
graphical reports sales trends
representation of displayed
trends.
FR User Module Manages user User Updated User must User account
8 accounts and account user have updated or
roles, including details account administrati deleted
adding, editing, (name, list ve rights
and deleting role)
users.

4.2.2 Non-Functional Requirements

In this phase, the researchers have documented the non-functional requirements, which
address how the system will perform rather than what it will do. These requirements focus on the
quality attributes that affect the user experience, such as system performance, security, usability,
and scalability. Non-functional requirements ensure that the software is efficient, reliable, and
secure, allowing it to meet the expected performance standards and handle future growth. They are
essential for ensuring the system’s overall success and its ability to function effectively in real-
world environments.
25

Table 4.2.2.1: Non-Functional Requirements of the System – The table below highlights the non-
functional requirements that define the system's overall quality attributes.

ID Non- Description Measurement/Target


Functional
Requirements
NFR1 Performance The system must respond The system should provide a
quickly to user actions. response time of less than 3
seconds for user interactions
in normal usage.
NFR2 Availability The system must be The system must be available
available for use at any 99.9% of the time.
time.
NFR3 Security The system must ensure the Data must be encrypted
confidentiality, integrity, during transmission and
and availability of data. storage. User passwords
must be hashed.
NFR4 Usability The system should be easy The system should have a
to use and navigate. user satisfaction rating of at
least 85% based on usability
testing.
NFR5 Compliance The system must comply The system must comply
with relevant legal, with data protection
regulatory, and industry regulations such as GDPR
standards. (General Data Protection
Regulation).

4.3 Design of Software, Systems, Product, and/or Processes

In the design phase of software, systems, products, and processes, all gathered information
and requirements are thoroughly analyzed to create a comprehensive and detailed representation of
the proposed system. This phase is crucial for translating both functional and non-functional
requirements into tangible designs that will guide the development of the project.
26

The first step involves creating a workflow, where the flow of activities within the system
is clearly defined, and the project scope is established using a structured design methodology. Use
case analysis is then conducted to identify all possible interactions and tasks that users can perform,
ensuring that every function is well-documented and aligned with user needs. This step helps
visualize the user’s journey through the system, focusing on specific actions and the outcomes they
generate.

In parallel, a data flow diagram (DFD) is developed to illustrate how data moves
throughout the system. It defines processes for data handling, storage, and communication between
different system modules. The DFD helps identify the flow of information, data transformation,
and interactions between components, which is essential for optimizing system efficiency and
ensuring smooth operation.

Wireframing is also chosen and utilized by the researchers as it is a key component of the
design phase and is easy to understand, especially when shown to users for clarification and
adjustments. It serves as a visual blueprint for the user interface (UI), outlining the layout,
placement of interactive elements, and essential components of the web pages or screens.
Wireframes help visualize the system’s structure before detailed design elements such as colors,
fonts, and images are applied, ensuring a user-friendly and intuitive interface.

Finally, an entity-relationship diagram (ERD) is created to model the relationships between


various data entities within the system's database. This analysis ensures an efficient data structure
by identifying how different data elements relate to one another, which is critical for effective data
storage and retrieval. It also serves as a foundation for designing a normalized database that avoids
redundancy and maintains data integrity.
27

Specifically, this is how the design of software, systems, products, and processes takes
place:

Use Case Diagram

In this section, the developing team utilizes a Use Case Diagram to provide a visual
representation of the interactions between users and the JAS Agri-Venture Sales and Inventory
Management System as shown in Diagram 4.3.1. This diagram outlines key functionalities and user
roles, offering a high-level overview of the system's behavior.

Diagram 4.3.1: Use Case Diagram

The use case diagram for JAS Agri-Venture Sales and Management System is a visual
representation of the system's functionality from the user's perspective. It shows the user (actor)
who interact with the system and the different tasks (use cases) that they can perform.
28

Use Case Model

In this section, the developing team employs a Use Case Model to delve deeper into the
intricacies of user-system interactions within the JAS Agri-Venture Sales and Management System.
The model provides a detailed roadmap of each identified use case, capturing the step-by-step
processes, preconditions, and postconditions associated with critical system functionalities. By
thoroughly analyzing user needs and system requirements, the team refines its understanding of
specific use cases, ensuring a comprehensive and precise blueprint for the system's development.
The Use Case Model serves as a crucial guide, fostering a clearer perspective on user interactions
and system behavior throughout the development lifecycle.

Diagram 4.3.2: Use Case Model: Login Functionality

Name: Login

Participating Actor: User

Entry Condition:

The User should have a device, internet access, an account, and must navigate to the JAS Agri-
Venture Sales and Management System web application.
29

Flow of Events:

1. The User opens the JAS Agri-Venture Sales and Management System application.
2. The system presents the login screen, requesting the User to enter their credentials.
3. The User enters their username and password.
4. The system validates the entered credentials against the stored user data in the system's
database.

Alternative Flow:

If the entered credentials are invalid, the system displays an error message, and the User is prompted
to re-enter the correct credentials.

1. If the credentials are valid, the system authenticates the User and grants access to the
system.
2. The system logs the login event, recording the timestamp and the User who logged in.

Exit Condition:

The User is successfully logged into the JAS Agri-Venture Sales and Management System and is
redirected to the system's dashboard.

Diagram 4.3.3: Use Case Model: Dashboard


30

Name: Dashboard

Participating Actor: User

Entry Condition: The User has navigated to the dashboard for the user is successfully logged into
the JAS Agri-Venture Sales and Management System.

Flow of Events:

1. After successful login, the system redirects the User to the dashboard.
2. The dashboard provides an overview of key information and functionalities, including
total sales, recent transactions, important notifications, and statistical data related to
products, customers, and categories. It also includes functionalities such as navigation
links or buttons for accessing different modules, such as managing products,
categories, customers, sales, and users.
3. The User can click on various sections or links within the dashboard to access detailed
information or perform specific actions.

Exit Condition: The User has successfully viewed the dashboard and can proceed to perform
further actions within the JAS Agri-Venture Sales and Management System.

Diagram 4.3.4: Use Case Model: Product Module


31

Name: Product Management

Participating Actor: User

Entry Condition:

The User has successfully logged into the JAS Agri-Venture Sales and Management System.

Flow of Events:

1. The User selects the "Manage Products" option from the dashboard.
2. The system presents the list of existing products.
3. The User has the option to:

• View Product Details:

1. The User can click on a specific product to view detailed information.

2. If the User chooses to view product details, the system displays the detailed
information for the selected product.

• Add New Product:

1. The User can add a new product to the system by providing necessary details
such as product name, category, price, and quantity.
2. If the User chooses to add a new product, the system prompts for the required
information and add the product to the database.

• Edit Existing Product:

1. The User can edit the details of an existing product, including its name,
category, price, and quantity.
2. If the User chooses to edit an existing product, the system allows the User to
modify the product details and updates the database accordingly.
32

• Delete Product:

1. The User can choose to delete a product from the system.


2. If the User chooses to delete a product, the system removes the product from
the database.

4. The system updates the list of products to reflect any changes made by the User.

Exit Condition: The User successfully manages products and can return to the dashboard with the
updated product information.

Diagram 4.3.5: Use Case Model: Customer Module

Name: Customer Module

Participating Actor: User

Entry Condition:

The User is successfully logged into the JAS Agri-Venture Sales and Management System.
33

Event Flow:

1. The User navigates to the dashboard and selects the "Customer Management" option.
2. The system displays the list of existing customers.
3. The User has the option to:

• View Customer Details:

1. The User can click on a specific customer to view detailed information.


2. If the User chooses to view customer details, the system displays the detailed
information for the selected customer, including transaction history.

• Add New Customer:

1. The User can add a new customer by providing details such as customer
name, contact information, and any other relevant information.
2. If the User chooses to add a new customer, the system prompts for the
necessary information and adds the customer to the database.

• Edit Existing Customer:

1. The User can edit the details of an existing customer, including contact
information and other relevant details.
2. If the User chooses to edit an existing customer, the system allows the User
to modify the customer details and updates the database accordingly.

• Delete Customer:

1. The User can choose to delete a customer, but only if the customer does not
have associated transactions. If transactions are associated, the system
provides a warning.
2. If the User chooses to delete a customer, the system checks for associated
transactions. If transactions are found, the system displays a warning and
prevents deletion until the issue is resolved.

4. The system updates the list of customers to reflect any changes made by the User.
34

Exit Condition:

The User has successfully managed customers and can return to the dashboard with the updated
customer information.

Diagram 4.3.6: Use Case Model: Sales Transaction Module

Name: Sales Transaction Module

Participating Actor: User

Entry Condition:

The User is successfully logged into the JAS Agri-Venture Sales and Management System.

Event Flow:

1. The User navigates to the dashboard and selects the "Sales Management" option.
2. The system displays the list of existing sales transactions.
3. The User has the option to:

• View Transaction Details:


35

1. The User can click on a specific transaction to view detailed information.


2. If the User chooses to view transaction details, the system displays
comprehensive information for the selected sale, including products,
quantities, total cost, and customer details.

• Add New Sale:

1. The User can initiate a new sale by selecting products, specifying quantities,
and entering customer details.
2. If the User chooses to add a new sale, the system guides the User through the
process, allowing the selection of products, specifying quantities, and
entering customer details. The system calculates the total cost.

• Edit Existing Sale:

1. The User can edit the details of an existing sale, including modifying product
quantities or updating customer information.
2. If the User chooses to edit an existing sale, the system allows the User to
modify product quantities, add or remove items, and update customer
information. The system recalculates the total cost.

• Delete Sale:

1. The User can choose to delete a sale, but only if the transaction is not
finalized. If the transaction is finalized, the system provides a warning.

2. If the User chooses to delete a sale, the system checks if the transaction is
finalized. If finalized, the system displays a warning and prevents deletion
until the issue is resolved. If not finalized, the system removes the sale from
the database.

4. The system updates the list of sales transactions to reflect any changes made by the
User.

Exit Condition: The User has successfully managed sales transactions and can return to the
dashboard with the updated sales information.
36

Diagram 4.3.7: Use Case Model: User Management

Name: User Management

Participating Actor: User

Entry Condition:

The User is successfully logged into the system.

Event Flow:

1. The User navigates to the dashboard and selects the "User Management" option.
2. The system displays the list of existing users with their roles and permissions.
3. The User has the option to:

• View User Details:

1. The User can click on a specific user to view detailed information, including
roles and permissions.
2. If the User chooses to view user details, the system displays comprehensive
information for the selected user, including roles and permissions.
37

• Add New User:

1. The User can add a new user by providing details such as username,
password, role, and other relevant information.
2. If the User chooses to add a new user, the system prompts for the necessary
information and adds the user to the database with specified roles and
permissions.

• Edit Existing User:

1. The User can edit the details of an existing user, including modifying roles,
permissions, and other user information.
2. If the User chooses to edit an existing user, the system allows the User to
modify user details, roles, and permissions.

• Delete User:

1. The User can choose to delete a user, but only if the user is not the last User.
If attempting to delete the last User, the system prevents deletion and
provides a warning.
2. If the User chooses to delete a user, the system checks if the user is the last
User. If it is the last User, the system prevents deletion and provides a
warning. If not the last User, the system removes the user from the database.

4. The system updates the list of users to reflect any changes made by the User.

Exit Condition: The User has successfully managed users and can return to the dashboard with
the updated user information.
38

Diagram 4.3.8: Use Case Model: Logout

Name: Logout

Participating Actor: User

Entry Condition: The User is currently logged into the system.

Event Flow:

1. The User initiates the logout process by clicking on the "Logout" option, usually
available in the system's navigation menu.
2. The system confirms the logout action and prompts the user with a message such as
"Are you sure you want to logout?"

Alternative Flow: If there are unsaved changes or ongoing processes, the system may provide a
warning to inform the User about potential data loss.

1. If confirmed, the system logs out the User by ending the session and invalidating the
authentication token.
2. The system redirects the User to the login screen or another landing page that is
accessible to unauthorized users.
3. The system records the logout event in the system logs, including the timestamp and
the username of the User who logged out.

Exit Condition: The User is successfully logged out to the System.


39

Data Flow Diagram

In this section, the development team utilizes a Data Flow Diagram (DFD) to provide a
visual representation of the interactions between users and the JAS Agri-Venture Sales and
Inventory Management System, as shown in Figure 4.3.2.

Diagram 4.3.9: Data Flow Diagram


40

Data Flow Diagram (DFD) illustrates the interaction between the User and various
processes within the system. The User initiates actions such as logging in, managing sales,
products, customers, suppliers, and generating sales reports. Each process interacts with specific
data stores: for example, the Login process interacts with the User Data store to verify credentials,
while the Manage Sales process retrieves and updates Sales Data. Similarly, product-related actions
involve the product data store, customer-related actions interact with customer data, and supplier-
related tasks access supplier data. The Generate Sales Report process pulls information from sales
data, while management of inventory updates and retrieves product stock levels from product data.
This DFD shows a high-level view of how data flows between the user, processes, and stored data
in the system.

System Design (Wireframing)

In system designing, the team made use of wireframing, which is advantageous for
presenting the user interface in a visual format. This method helps clarify the functionality,
streamline the iterative design process, and ensure stakeholders are on the same page as expected.
This also reduced development time and costs. Wireframe layout will serve as the blueprint for the
team during the development of the JAS Agri-Venture Sales and Inventory Management System.

Figure 4.3.1: Wireframing Indicators


41

As depicted in the image, a wireframe is being utilized to depict icons that represent
different elements and their corresponding functions that will be incorporated into the system. To
provide you with a clear understanding, here is a detailed explanation of the role and purpose of
each icon:

1. Image Indicator: This icon signifies the image element (for example, a background
image) within the system.
2. Button or Interaction Button: This rectangular box signifies clickable elements on
the user interface that trigger an action upon clicking.
3. Text Indicator: As illustrated, various lines are presented, right after interaction
button, each representing written content within the system.
4. Scroll Up/Down Indicator: This up and down arrow icon indicates the ability to scroll
up or down through the system’s content.
5. Video Indicator: This icon signifies a video element within the system.
6. List Indicator: This horizontal line with bullet points represents a list of items within
the system.
7. Logo: This square icon represents the logo that identifies the system’s identity.
8. Connector: This arrow icon represents a connection between different parts of the
system.
9. Search Bar: This horizontal bar with a magnifying glass icon represents a search
function that allows users to find specific information within the system.

Figure 4.3.2: Login Page


42

This the login page of the system. It serves as the starting point of our proposed system. It
allows users to authenticate their identity and gain access to a secure system or application. It
consists of two input fields: one for the user's username, and the other for their password.

Figure 4.3.3: Dashboard


43

This is the dashboard, the preliminary page of the system, which provides plenty of
information and resources to the user. This page allows user to access different features seen in the
system whenever the user logged into it. In this page, user will see some information that the user
might interact such as sales management page, customer management page, product management
page, and user management page.

Figure 4.3.4: Product Management Page

This is the product management page of the system. It is the webpage where you can add
products and where the total number of products is listed. You can also delete and edit or update
your product here.

Figure 4.3.5: Customers Management Page


44

This is the customers page of the system. It is the webpage where you can add customers
and see the total number of customers.

Figure 4.3.6: Sales Management Page1

Figure 4.3.7: Sales Management Page2

This is the sales management page of the system. It is the page where you can manage
various aspects of the system, including bills, customers, sellers, payment methods, net cost, total
cost, and dates.
45

Figure 4.3.8: Customer Management Page

This is the customer management page. It displays a lot of data about the customer,
including name, contact information, and address. This page also allows the user to oversee and
track if how many orders and/or purchases does the customers have made over a period of time.

Entity-Relationship Diagram

In this section, the development team employs an Entity-Relationship Diagram (ERD) to


illustrate the relationships between different data entities within the JAS Agri-Venture Sales and
Inventory Management System, depicted in Figure 4.3.2. This diagram visually represents how
various pieces of data interact and relate to each other within the system's database.
46

Diagram 4.3.10: Entity-Relationship Diagram

The Entity-Relationship Diagram (ERD) for the JAS Agri-Venture Sales and Inventory
Management System serves as a graphical depiction of the system's underlying data structure and
relationships, as depicted in Figure 4.3.2 above. The relationships between the entities are
shown by lines connecting the entities. The crowfeet on the lines indicates the cardinality of the
relationship. For example, the relationship between Product Management and Sales Management
is one-to-many. This means that one product can be sold many times, but a sale can only be for
one product. The attributes of each entity are listed in the table below the entity. For example,
the attributes of the user management entity include user id, username, password, email, phone
number, address, and role. The ERD also includes methods for each entity. For example, the user
management entity includes methods for create User (), update user (), and delete user ().
47

4.4 Development Plan

This section explains the guidelines that were followed during the development and
evaluation of the system. The process consisted of several phases, each involving continuous
improvement and adherence to the planning, implementation, and professional review cycle.

Gantt Chart

In this section, the development team utilizes a Gantt chart to plan the JAS Agri-Venture
Sales and Management System development. The chart details tasks, start and end dates, and task
dependencies. Emphasizing system requirements, it involves gathering client input, analyzing
needs, and creating use cases, sequence diagrams, and class diagrams. The chart extends to
coding, unit testing, and integration testing, serving as a visual guide for a structured development
process.

Gantt Charts Legends

Start

End

Estimated Time

Actual

Delay

Milestone
48

Table 4.4.1: Gantt Chart for Month of February - The table below displays the estimated time
required for the present specific task or activity during the month of February.

Month of 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
February
Group
Agreement
Form

Seek for a
client

Letter of
Request
for Client
Interview
49

Table 4.4.2: Gantt Chart for Month of March - The table below displays the estimated time required
for the present specific task or activity during the month of March.

Month of 05 06 07 08 09 10 11 12 13 14 15 16 17 18
March
Interview
Client to
Gather Data
Regarding the
System

Title Proposal
Development

Complete
Chapter 1
Development

Chapter 1
Revision

Chapter 2
Development
50

Table 4.4.3: Gantt Chart for Month of April - The table below displays the estimated time required
for the present specific task or activity during the month of April.

Month of 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2
April 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
Complete
Chapter 2
Developmen
t

Chapter 2
Revision

Chapter 3
Developmen
t
51

Table 4.4.4: Gantt Chart for Month of May - The table below displays the estimated time required
for the present specific task or activity during the month of May.

Month of May 05 06 07 08 09 10 11 12 13 14 15 16 17 18
System
Design
Development

Chapter 3
Revision

Full Checking
of Documents
(Chapter 1, 2,
and 3)

Signatories of
Approval
Letter for Title
Defense
Schedule

Finalization of
Documents
and
Presentation
52

Table 4.4.5: Gantt Chart for Month of June - The table below displays the estimated time required
for the present specific task or activity during the month of June.

Month of June 01 02 03 04 05 06 07 08 09 10 11 12 13

Title Defense
Presentation

Working on Approved
Title (JAS Agri-
Venture Sales and
Inventory
Management System)
53

Table 4.4.6: Gantt Chart for Month of June - The table below displays the estimated time required
for the present specific task or activity during the month of June.

Month of June 05 06 07 08 09 10 11 12 13 14 15 16 17 18
Approved
Title Proposal

Letter of
Request for
Client
Interview

Interview
Client to
Gather Data
Regarding the
System

System
Design
Development

System
Development
54

Table 4.4.7: Gantt Chart for Month of August - The table below displays the estimated time required
for the present specific task or activity during the month of August.

Month of 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
August
Group
Agreement
Form

Seek for a
client

Letter of
Request
for Client
Interview
55

Table 4.4.8: Gantt Chart for Month of September - The table below displays the estimated time
required for the present specific task or activity during the month of September.

Month of 05 06 07 08 09 10 11 12 13 14 15 16 17 18
September
Interview
Client to
Gather Data
Regarding the
System

Title Proposal
Development

Complete
Chapter 1
Development

Chapter 1
Revision

Chapter 2
Development
56

Table 4.4.9: Gantt Chart for Month of October - The table below displays the estimated time
required for the present specific task or activity during the month of October.

Month of 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2
October 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
Complete
Chapter 2
Developmen
t

Chapter 2
Revision

Chapter 3
Developmen
t
57

Table 4.4.10: Gantt Chart for Month of November - The table below displays the estimated time
required for the present specific task or activity during the month of November.

Month of 05 06 07 08 09 10 11 12 13 14 15 16 17 18
November
System
Design
Development

Chapter 3
Revision

Full Checking
of Documents
(Chapter 1, 2,
and 3)

Signatories of
Approval
Letter for Title
Defense
Schedule

Finalization of
Documents
and
Presentation
58

Table 4.4.11: Gantt Chart for Month of December - The table below displays the estimated time
required for the present specific task or activity during the month of December.

Month of December 01 02 03 04 05 06 07 08 09 10 11 12 13

Title Defense
Presentation

Working on Approved
Title (JAS Agri-
Venture Sales and
Inventory
Management System)

Table 4.4.12: Gantt Chart for Month of January - The table below displays the estimated time
required for the present specific task or activity during the month of January.

Month of January 17 18 19 20 21 22 23 24 25 26 27 28 29

Final Defense
Presentation

Finalization of
Manuscript
59

Research/Capstone Project Team

This section outlines the specific roles and responsibilities of each member of the project
team. The team is mainly composed of a Project Manager (PM), Software Engineer (SE), System
Analyst (SA), Quality Assurance Tester (QA), Technical Writer (TW), and UI Designer (UID).

• Mary Jane C. Salud (PM & QA) - responsible for leading the team and however in
charge of ensuring that the system meets the required standards.
• Adzman I. Jainal (SE)- responsible for programming and implementation of the
software.
• Mary Joy C. Salud (TW & SA) - in charge of gathering and analyzing the technical
writer and is responsible for analyzing the system.
• Emmanuel C. Santos Jr. (UID) - in charge of the UI designing of the system.

4.5 Testing Plan

To ensure the system's functionality, it will undergo testing by developers. This includes
unit testing, integration testing, and system testing. This testing is important to make sure that the
system performs as expected and meets the specified requirements of the client. During the unit
testing phase, the developers test the operation of individual components. Each component was
tested one by one to ensure proper functionality. Afterward, the integration testing will be
conducted to test the interaction of different modules to verify if there was data flow and
communication between modules. Any issues identified were resolved and re-tested. On the other
hand, to test the overall functionality of the system, or what we called "system testing", the
researchers decided to conduct a test with 10 participants divided into alpha and beta testing.

The researchers conducted a testing plan involving 10 participants, called alpha and beta
testing, to test the overall functionality of the system and determine whether the system meets the
requirements of the client. Alpha testing will be conducted involving IT experts to get ideas and
suggestions for areas where the system needs improvement. Alpha testing will be conducted at
Zamboanga Peninsula Polytechnic State University (ZPPSU). On the other hand, beta testing
involving clients who represented end-users is conducted at Mercedes, Lumbayao, Zamboanga
City.
60

Analysis Approach

In this study, the researchers utilized a specific questionnaire known as the System
Usability Scale (SUS) to evaluate the ease of use and satisfaction level of users when using the JAS
Agri-Venture Sales and Inventory Management System. The SUS questionnaire consisted of 10
questions that inquired about the system's usability, functionality, and user preference. Participants
responded to these questions by indicating their agreement with the provided statements on a scale,
ranging from strongly agree to strongly disagree. After gathering these responses, the researchers
analyzed them to assess the system's usability. This enabled them to identify areas for improvement
and enhance the system based on authentic user feedback.

Test Document

The researchers used a set of surveys to collect data from the targeted participants. These
surveys were carefully designed to capture useful feedback on various aspects of the system,
including usability, functionality, and overall user satisfaction. The survey design process involved
developing questions aimed at producing detailed responses about the system’s performance and/or
usability, covering critical areas such as user interface design, ease of navigation, system
responsiveness, and the accuracy of outputs. Before full distribution, the surveys undergo a pilot
test with a small group of 10 participants to ensure clarity and relevance.

The surveys were distributed in two main phases to distinct groups of participants to ensure
a thorough evaluation of the system. The first phase, alpha testing, involved IT professionals within
the Department of the College of Information and Computing Science at Zamboanga Peninsula
Polytechnic State University. The primary aim of this phase was to conduct an initial evaluation of
the system in a controlled environment. IT professionals, due to their technical expertise, provided
valuable insights into the system’s technical performance, potential issues, and areas for
improvement. Surveys were distributed in paper form to ensure full participation, with participants
asked to use the system under various scenarios and complete the survey based on their experiences.

The second phase, beta testing, involved a selection of clients who represented the end-
users of the system. The goal of beta testing was to gather feedback from the client, who will be
the actual users in a real-world setting, focusing on evaluating the system’s usability, effectiveness
in meeting user needs, and overall user satisfaction.
61

System Evaluation

SUS score will be able to tell the system’s usability performance on the aspect of
effectiveness, efficiency, and overall ease of use. This will guide researchers in determining the
system’s areas that need improvement.

See the table below. It is presented that the score of 68 represents the average, which simply
means it is at the 50th percentile. This information will give researchers an idea of whether the
system is functioning as expected or not.

Table 4.5.1: SUS Score Guidelines – This table represents the scoring system of SUS, ranging from
excellent up to awful.

SUS Score Grade Adjective Rating


> 80 A Excellent
68-80 B Good
68 C Average
51-68 D Poor
< 50 E Awful

This table illustrates the scoring system for the System Usability Scale (SUS), where
different ranges of scores correspond to different grades and adjective ratings. A score above 80.3
is considered excellent, indicating a high level of usability and satisfaction. Scores between 68 and
80.3 are graded as good, while a score of exactly 68 is considered okay. Scores between 51 and 68
represent poor usability, and scores below 51 are classified as awful, indicating severe usability
issues.

Alpha Testing

In this phase, the 8 IT experts are put into Alpha testing by the researchers using the System
Usability Scale (SUS) questionnaire to gather information about the system's usefulness to know if
the system will be easy to use for future clients who will be using the system.
62

The main goal was to thoroughly evaluate the system's usability and effectiveness from the
viewpoint of experienced professionals in the field. By using the SUS questionnaire, the researchers
sought to gather valuable insights into the system's utility and user-friendliness. This feedback was
essential for refining and optimizing the system before its wider implementation with future clients.
This process not only helped in identifying and addressing potential usability issues at an early
stage but also established the basis for improving the overall user experience of the system for
future users.

Table 4.5.2.: Alpha Testing with I.T Experts – This table represents the tally of responses to the
SUS questionnaire from the 8 IT expert respondents for Alpha testing.

System Usability Scale (SUS) Strongly Disagree Neutral Agree Strongly


Disagree Agree

1 2 3 4 5
1. I think I would like to use the
1 0 3 0 4
system frequently.

2. I found the system unnecessarily 2 2 1 3 0


complex.

3. I thought the system was easy to 0 2 2 0 4


use.

4. I think that I would need the 2 3 3 0 0


support of technical person to be
able to use the system.

5. I found the various functions in this 0 0 4 3 1


system were well integrated.

6. I thought there was too much 3 3 1 1 0


inconsistency in this system.
63

7. I would imagine that most people 0 2 2 2 2


would learn to use this system very
quickly.

8. I found this system very awkward 6 1 1 0 0


to use.

9. I felt very confident using the 1 0 3 1 3


system.

10. I need to learn a lot of things before 2 2 2 2 0


I could get going with the system.

The researchers tally per question and here are the results; In Question 1, 4 respondents
chose "strongly agree," 3 chose "neutral," and 1 chose "strongly disagree." For Question 2, 3
respondents chose "agree," 1 chose "neutral," and 2 chose both "disagree" and "strongly disagree."
Question 3 received 4 "strongly agree," 2 "neutral," and 2 "disagree" responses. Regarding
Question 4, 3 respondents indicated that they would need technical support, 3 chose "neutral" and
"disagree," and 2 chose "strongly disagree." For Question 5, 4 participants agreed, 3 chose "well-
integrated," and 1 chose "strongly agree." Question 6 saw 3 respondents identifying inconsistency,
3 "disagree," and 1 each "neutral" and "agree." In response to Question 7, there were 2 "strongly
agree," 2 "agree," and 2 each of "neutral" and "disagree." For Question 8, 6 respondents found the
system not awkward, 1 disagreed, and 1 was neutral. Question 9 received 3 confident responses, 3
neutral responses, and 1 each of "agree" and "disagree." Lastly, Question 10 had 2 respondents
indicating a need to learn a lot, 2 were "neutral," and 2 chose "disagree" and "strongly disagree."

Beta Testing

In this phase, beta testing was conducted with the full participation of future clients. This
will ensure that the JAS Agri-Venture Sales and Inventory Management System is thoroughly
evaluated from the perspective of its end-users.
64

Table 4.5.3: Beta Testing with End User - This table represents the tally of responses to the SUS
questionnaire from the end user preferences.

System Usability Scale (SUS) Strongly Disagree Neutral Agree Strongly


Disagree Agree

1 2 3 4 5
1. I think I would like to use the system
0 0 0 0 2
frequently.

2. I found the system unnecessarily 0 0 2 0 0


complex.

3. I thought the system was easy to use. 0 0 0 1 1

4. I think that I would need the support of 0 0 0 1 1


technical person to be able to use the
system.

5. I found the various functions in this 0 0 1 1 0


system were well integrated.

6. I thought there was too much 0 1 1 0 0


inconsistency in this system.

7. I would imagine that most people would 0 0 2 0 0


learn to use this system very quickly.

8. I found this system very awkward to use. 1 1 0 0 0

9. I felt very confident using the system. 0 0 2 0 0

10. I need to learn a lot of things before I 0 0 0 1 1


could get going with the system.

The System Usability Scale (SUS) questionnaire had ten questions about the JAS Agri-
Venture Sales and Inventory Management System. People answered these questions by choosing
numbers from 1 to 5. Some questions asked if they liked using the system a lot, while others asked
if they found it complicated or easy to use. For example, some people said they would use the
65

system often, while others were unsure if they would need help from technical people. Overall, the
answers showed different opinions about how easy the system was to use and whether people felt
confident using it. This feedback helps make the system better for everyone.

Evaluation Result

This section will discuss the evaluation result of the System Usability Scale (SUS) for the
JAS Agri-Venture Sales and Inventory Management System. The SUS questionnaire was
administered to participants to gauge their perceptions of the system's usability and satisfaction.

Alpha Testing Result

Table 4.5.4: Alpha Testing Result – This table presents the result of the conducted testing,
particularly in alpha testing involving IT experts.

Result of Alpha Testing

Respondent Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Total Score

R1 5 1 5 1 4 1 5 1 5 2 30

R2 1 4 5 2 5 1 5 1 5 4 33

R3 5 1 5 2 4 1 4 1 5 1 29

R4 5 4 5 3 4 2 4 2 4 3 36

R5 3 4 3 3 3 4 3 3 3 4 33

R6 5 3 2 3 3 3 2 1 1 2 25

R7 3 2 3 2 3 2 3 1 3 3 25

R8 3 2 2 1 3 2 2 1 3 1 20

Total Average 72.19%


66

The table revealed that there are 8 respondents with 10 questionnaires. The researchers
recorded all the answers from the questionnaires in the table. R1 scored 30 percent, R2 scored 33
percent, R3 scored 29 percent, R4 scored 36 percent, R5 scored 33 percent, R6 and R7 both scored
25 percent, and R8 scored 20 percent. Adding up the total scores of all 8 respondents, the average
score is equal to 72.19 percent.

Alpha Testing

The researchers conducted an Alpha testing on respondents from the Department of


College of Information and Computing Science using the SUS questionnaire. These respondents
have tested the system’s performance to determine if it is suitable and will function accordingly.

Figure 4.5.1: Alpha Testing Graph Result

Figure 4.5.1 presents the results of the Alpha Testing Performance from eight (8)
respondents, each of whom checked whether they agreed, disagreed, strongly agreed or disagreed,
or were neutral on each of ten (10) questions.
67

Beta Testing Result

Table 4.5.5: Beta Testing Result - This table presents the result of the conducted testing, particularly
in beta testing involving end users.

Result of Beta Testing

Respondent Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Total Score

R1 5 3 4 4 4 3 3 1 3 4 34

R2 5 3 5 5 3 2 3 2 3 5 36

Total Average 87.5%

The table revealed that there are 2 respondents with 10 questionnaires. Respondent 1
scored over 34 percent, while Respondent 2 scored over 36 percent. Totaling the results, it will be
equal to 87.5 percent.

Beta Testing

In this phase, the researchers conducted Beta testing on respondents from the end user.
These respondents have tested the system’s performance to determine if it is suitable and will
function according to their requirements.

Figure 4.5.2.: Beta Testing Graph Result


68

Figure 4.5.2 presents the results of the Beta Testing Performance from eight (2)
respondents, each of whom checked whether they agreed, disagreed, strongly agreed or disagreed,
or were neutral on each of ten (10) questions.

4.6 Description of the Prototype

The JAS Agri-Venture Sales and Inventory Management System is a comprehensive


solution designed to streamline sales and inventory management processes for businesses like JAS
Agri-Venture and Consultancy Corporation.

Key functionalities of the system include user registration for secure account creation,
login/logout services to protect user privacy, and a robust home/dashboard providing essential
metrics and visual representations like sales graphs. It also offers category and product management
tools for organizing and maintaining accurate product data, alongside customer management
functionalities for efficient handling of customer information. Sales management features enable
the creation of sales, performance tracking, and report generation. Additionally, an administrative
module empowers administrators to manage user accounts, roles, and permissions effectively.

The system stands out for its ability to modernize sales and inventory management
processes. Its user-friendly interface is designed for easy navigation by managers, ensuring a
seamless user experience. Innovative features such as sales graphs provide valuable insights into
performance trends, making it highly relevant for modern businesses seeking to optimize their
operations.

4.7 Implementation Plan

The establishment of a dedicated support system is crucial to address user inquiries and
technical issues promptly. This system will involve a helpdesk system to facilitate effective
communication between users and support staff. To ensure seamless system operation, proactive
maintenance strategies will be employed, such as regular performance monitoring, security audits,
and data backups to mitigate potential risks and maintain data integrity. Additionally, ongoing
project assessments will be conducted to oversee progress and effectiveness by reviewing
milestones and key performance indicators, as well as collecting feedback from stakeholders to
inform project improvements. Finally, periodic project reviews will be conducted to evaluate
overall success and identify areas for refinement.
69

A comprehensive training program will be developed for users to ensure they are equipped
with the knowledge and skills necessary to utilize the system effectively. The training will cover
all key features and functionalities, with hands-on sessions to reinforce learning. Additionally, user
manuals and documentation will be prepared to provide clear instructions and guidelines for system
usage. This will include troubleshooting steps, frequently asked questions (FAQs), and contact
details for support. Regular training updates will also be scheduled to accommodate new features
and system enhancements.

You might also like