Research Methodology 1

CHAPTER III
RESEARCH METHODOLOGY

This chapter presents the research methodology which provides the

source of data, detailed methods that are going to be used in the study and the

tools for data analysis and the instruments that will be used for data gathering.

Research Design

The Agile software development methodology is one of the most simple,

yet effective ways to deliver a great product on the market. Properly implemented

Agile is fast, flexible, error-proof and just plain better way to manage software

development teams (Ihor Feoktistov, 2021).

The Agile software development lifecycle is dominated by the iterative

process. Each iteration results in the next piece of the software development

puzzle working software and supporting elements, such as documentation,

available for use by customers until the final product is complete (Kate Eby,

2016).

The Agile methodology is a collection of principles that value adaptability and

flexibility. Agile aims to provide better responsiveness to changing business

needs and therefore focuses on enabling teams to deliver in workable increments

(Asmo, 2018).

The proponents chose the Agile Methodology for the developed system.

Agile methodology is an adaptability method. It is an iterative development.

Rather than using planning as the method, agile use primary control which is the

feedback. Agile is an iterative approach to project management and software

development that helps teams deliver value to their customers faster and with
 Research Methodology 2

fewer headaches. Figure 2 shows the illustration of process in Agile

Methodology.

Figure 2. Agile Methodology Process

Phase 1. Planning. Phase one, the scope of the project and funding

is specified. A key element is that the executive sponsor provides support for

the project. A needs analysis, requirements specification, and a project plan is

created. Costs, time, tasks, and resources are specified. Phase one will set the

scope, duration, and funding for the development project, planning, and

preparation in this phase are essential (McFarland, 2020).

The proponents gathered data at the barangay office in order to meet

the needs of Barangay. The proponents also coordinated with the barangay

council who are in charge of the manual process of conducting the survey of

population count.

Phase 2. System Design. Phase Three systems design results in high-

level design specifications including system design documentation that contains

 Research Methodology 3

the following diagrams: (a) context diagram(s), (b) data flow diagrams, (c) flow

charts, (d) data modeling (for databases), and other diagrammatic tools that will

support the overall design of the system. Further, use cases are derived that will

support the subsequent development and testing phases. Also, based on use

cases, prototypes are developed and approved by users (McFarland, 2020).

In this phase, the proponents developed a design of the system that

will provide the needs of the Barangay. The proponents also decided to add a

google map that will easily locate the residence location. After the decided

design & features of the system, the programmer starts developing the

system.

Phase 3. Coding. The coding phase begins when the delineated

functional requirements are transitioned into a programming language. Before

taking the functional specifications into code, the systems analyst segments the

functions into modules that are commonly distributed to the development team

for coding. Also, during the development phase, test cases are built that will

later be used in the testing phase to confirm that the system works as

expected. Due to the nature of coding, module testing, the construction of test

cases, and compliance with development standards, the development phase is

typically one of the longest phases in the SDLC model (McFarland, 2020).

In this phase, the proponents will program the system by using Php, Ajax

and SQL.

Phase 4. Implementation. The implementation phase where modules

and programs are deployed from a testing environment into a production

 Research Methodology 4

environment. During implementation, final verification and validation of the new

code and system is done to confirm that the system still executes as expected.

Before the roll-out from a test environment to the production environment, a roll-

back strategy is designed.

The roll-back occurs if the new system is implemented into the production

environment and the new system does not perform as expected. Rolling back

the environment to a previous state is necessary when a new system does not

perform as expected to keep the overall information and networking system in a

consistent state (McFarland, 2020).

In this phase, the system is already developed and tested. It will

be implemented in Barangay for observation if it is efficient and effective.

Phase 5 Maintenance. The Maintenance occurs when the new system is

running in the production environment and users are requesting changes to

adhere to new business requirements. Also, aside from maintaining code to

support new/updated business requirements, the maintenance phase

incorporates a retirement sub-phase whereby a system that is in production

that is being replaced by a newer system is rolled out of production (or retired)

in a measured way (McFarland, 2020).

In this phase, the system requires maintenance in order to keep the

system’s functionality on track and to deliver great service for its customers.

Source of Data
 Research Methodology 5

The primary sources of data are the selected barangay of Dagupan City.

The researcher conducted several interviews and observations to gather system

requirements.

Secondary sources of data would come from sample forms, internet

research and surveys which provide the basis for the design and functionality of

the proposed system.

Instrumentation and Data Collection

The proponents used the following tools for data gathering:

Document Analysis. Document analysis is a form of qualitative research

that uses a systematic procedure to analyze documentary evidence and answer

specific research questions. The proponent used document analysis to collect

data.

Internet Research. Internet Research continues to provide an outlet for

the publication of the latest research relating to internet technologies and

applications, and their impact upon society. It is recommended reading for

academics and practitioners alike, regularly providing material of interest and

value to both communities. The proponents will gather additional information

through the World Wide Web related to the study.

Interview. An interview is a procedure designed to obtain information

from a person’s oral response to oral inquiries. The proponents will interview to

gather and seek information.

The proponents conducted an interview to the stakeholders including

barangay council, and assigned employees in barangay about the processes

 Research Methodology 6

involved in issuing documents and other services that the barangay will issue

to its constituent.

Observation. The method involves watching and recording the behavior

of individuals or groups, or the events that occur in a particular place. The

proponents conducted interviews and observations to review the processes

and activities involved in the barangay.

Survey Questionnaire. A very important aspect of research work is a

survey or questionnaire. A questionnaire is usually composed of one or more

questions, answered by a number of people. Survey is the use of asking

questions to the respondents that is related to the study. The proponents will

provide surveys to all the users of the system for them to comment or write

what are the needs and don’t to the system made by the proponent.

Tools for Data Analysis

In this study, the following instruments were used to analyze data:

Database Schema. The database schema contains the design or list

of attributes and instructions that tells the database engine how the data is

organized and how the components are related ([Link], 2017). The

proponents will be using database schema to properly explain and illustrate

the workflow and relationships in the database.

Data Flow Diagram (DFD). DFD is a graphical representation of the

flow of data through an information system ([Link], 2021). The

proponents will use this type of diagram to help the team visualize how data is
 Research Methodology 7

being processed from one point to another and to improve the latter data

process.

Entity Relationship Diagram (ERD). ERD is a data modeling technique

that graphically illustrates an information system’s entities and the

relationships

between those entities ([Link], 2021). The proponents used the

ERD to depict the current system’s data relationships, reflect and create a

good database design for the proposed system.

Flowchart. Flowchart is a type of diagram that represents an

algorithm, workflow or process, showing the steps of boxes of various kinds, and

the order by connecting the arrows ([Link], 2021). The

proponents used the flowchart to illustrate the flow of procedures in Barangay

Management Information System

Gantt Chart. A Gantt chart is a timeline that is used as a project

management tool to oversee every aspect of the project while keeping a

tracking of its progress. You will easily know who is responsible for what,

how long each task will take and other problems that a team will encounter

during the progress of the project (Kashyap, 2018). The proponents used a

Gantt chart for the schedule of developing the system.

Ishikawa Diagram. Ishikawa diagram is a visualization tool for

categorizing the potential causes of a problem. This tool is used in order to

 Research Methodology 8

identify a problem’s root causes (Sarah Lewis, 2020). The proponents used

Ishikawa diagram to identify possible causes of a problem.

Likert Scale. Likert scale is a rating scale used to assess opinions,

attitudes, or behaviors. Likert scales are popular in survey research because

they allow you to easily operationalize personality traits or perceptions

([Link], 2020). The proponents used this scale to assess respondents'

attitudes by asking how strongly they agree or disagree with a specific question.

Table 1. Weighted Mean of Scoring

Strongly Disagree Neutral Agree Strongly
Disagree Agree
1 2 3 4 5

Use Case Diagram. A use case diagram is a graphic depiction of

the interactions among the elements of a system (TechTarget, 2019). Use case

diagram is a behavioral UML diagram type and frequently used to analyze

various systems. They enable you to visualize the different types of roles in a

system and how those roles interact with the system (Cinergix PTY. Ltd.,

2019). The proponents used this method to identify the functions of the

system together with the interaction between the system and end-user.

Weighted Mean. Weighted mean is a kind of average. Instead of each

data point contributing equally to the final mean, some data points contribute

more “weight” than others. If all the weights are equal, then the weighted mean

equals the arithmetic mean (the regular “average”). Weighted means are very

common in statistics, especially when studying populations. The proponents

used this tool to determine the result of the survey. The proponents will use
 Research Methodology 9

Likert scale to represent the interval of the following rate in Table 2 to compute

for average weighted mean, the formula below will be used is Mean = Σx / n

where the Mean = Average, Σx = Summation of results, and n = Number of

respondents. The proponents used the table shown below to describe the

weighted mean scoring. The scale being the rate, the statistical limitations

corresponding to the descriptive rating and its equivalent descriptive

interpretation.

System Usability Scale. The System Usability Scale (SUS) is a

questionnaire that is used to evaluate the usability of products and services.

These survey questions are used as a quantitative method to evaluate and get

valuable insights into the usability of a wide variety of new systems, whether

software or hardware. The proponent made use of the System Usability Scale in

determining the usability of the proposed system. The System Usability Scale

(SUS) provides a “quick and dirty”, reliable tool for measuring the usability

([Link], accessed 2022). It consists of a 10 item questionnaire with five

response options for respondents; from Strongly agree to Strongly disagree.

Originally created by John Brooke in 1986, it allows you to evaluate a wide

variety of products and services, including hardware, software, mobile devices,

websites and applications

To calculate the system usability score, convert the scale into number for

each of the 10 questions as shown on the table below. Use the formula below to

computer for the SUS score.

Scale:
 Research Methodology 10

 Strongly Disagree: 1 point

 Disagree: 2 points

 Neutral: 3 points

 Agree: 4 points

 Strongly Agree: 5 points

Formula:

X = Sum of the points for all odd-numbered questions – 5

Y = 25 – Sum of the points for all even-numbered questions

SUS Score = (X + Y) x 2.5

SUS Score Interpretation:

The SUS Score can be interpreted using the table shown on Table 1. An

SUS score of higher than 80.3 has an equivalent grade of A and adjective rating

of Excellent. If the SUS score is from 68 to 80.3, the Grade is B and the

Adjective Rating is Good. An SUS score of 68 is the neutral score. The Grade

for this score is C and the adjective rating is Okay, this is the “boundary” grade.

A grade of 51 to 68 is graded as D or Poor. Meaning that if the SUS score for a

system or an application is within this range, the perception of the users who

rated the application is that the application is not efficient, effective and easy to

use. A grade of E or Awful adjective rating is given if the SUS score is below 51.

This means that the software is perceived to be not efficient, not effective and is

not acceptable to the users.

SUS Score Grade Adjective Rating

 Research Methodology 11

> 80.3 A Excellent

68 – 80.3 B Good

68 C Okay

51 – 68 D Poor

< 51 F Awful
Table 1.2: System Usability Scale (SUS) Grade and Adjective Rating