You are on page 1of 5

CHAPTER THREE

RESEARCH METHODOLOGY AND DESIGN

3.1 Introduction
This section of the project describes or includes three main areas: software development
methodology, data collection procedures and development tools and platform. In the development
of a system, it is important to obtain the accurate, necessary and needed requirements to ensure
good and quality system development.

3.2 Software Development Methodology


A software development methodology in software engineering is a framework that is used to
structure, plan and control the process of developing an information system. A methodology
defines a paradigm (i.e. approach) to be adopted and a precise lifecycle to be used.
In the development of this system, an Iterative and Build and Fix Methodology was used to ensure
systematic and sequential flow of the system stages and also considering error fixing during
and after development.

3.3 METHODOLOGY
Build and fix methodology is the model that was adopted in the development of this system. In the
build and fix model (also referred to as an ad hoc model), the software is developed without any
design specification especially when the client is not IT inclined. An initial product is built, which is
then repeatedly modified until it (software) satisfies the user’s desired goal. That is:
 The software is developed and delivered to the user.
 The user checks whether the desired functions are present.
 If not, then the software is changed according to the needs by adding, modifying or deleting
functions.
 This process goes on until the user feels the software meets their goal.

The build and fix model (as indicated in Fig 3.1) includes the following three phases:

Build: In this phase, the software code is developed and passed on to the next phase.

Fix: In this phase, the code developed in the build phase is made error free. Also, in addition to the
corrections to the code, the code is modified according to the user's requirements.

Use: This is the stage where the system is deployed and installed for use.
Fig 3.1: Build and
Fix SDLC diagram

Some of the advantages of this approach are:


 Requires less experience to execute or manage any software development project other than
the ability to program.
 Suitable for smaller software/project.
 Requires less project planning.
 Suitable for time critical projects
 Development, testing and debugging are handled concurrently.

3.4 Data Collection


Data collection is the process of gathering and measuring information on targeted variables in an
established systematic fashion, which then enables one to answer relevant questions and evaluate
outcomes (Anon, 2016). Most common approaches for application development studies include
Inquisitive techniques (interviews, questionnaires, Brainstorming and Focus Groups) and
Observational techniques (Work Diaries, Participant Observation).
The data collection approaches used are the observational and the secondary sourcing technique:

3.4.1 Observation
Observation is the process of monitoring something or someone closely to get an information. It
helps one to gather life information or data from naturally occurring situation. This means that
hidden or concealed data would be revealed or disclosed. First-hand information rather than second-
hand information would be collected by looking at what is taking place in the real world situation
again. Observing or seeing the current system in action gives a thorough understanding and
additional perspective of system procedures.

3.4.2 Secondary Source


Secondary sources of data were also used in this project. This includes obtaining or gathering
data from library source, newspapers, Internet, journals, articles, reports, bulletins, newsletters.
Most of the data collected have been covered in the chapter two, the literature review, of the
project.

3.5 Use Case Diagram


A diagram is a visualization of set of elements and the relationships between them. Use case is a
set of scenarios, which defines functionalities of the system from a user’s perspective. The main
components of a use case diagram include actors, use cases and their relationships. They depict
the interaction between actors and system to achieve certain goal. This, a use case diagram is
important in modelling the behavior of a system.

Fig 3.2: Use Case Diagram


Admin: This referes to the adminstrator of the system who has the Super User Access Control over
the system’s interface and can manage both employers and job seekers.
Register Account: This use case denotes a set of actions required for Employer and Job
seeker to register with the application.
Login: This use case denotes a set of actions required for Employer and Job seeker to login
into the application.
Manage Profile: This use case denotes a set of actions required for admin to manage both the
employer and job seeker’s profile.
Post Job: This use case denotes a set of actions required for admin or the employer to post for job
vacancy on the application.
Add Job Vacancy: This use case denotes a set of actions required for Employer to post a job
vacancy.
View Applicants for a Job Post: This use case denotes a set of actions required for Employer to
view the list of applicants for a particular job post.
Employer Profile: This use case denotes a set of actions required for Employer to view Reviews
provided by the applicants.
Job Seeker Profile: This use case denotes a set of actions required for Employer to view all
the jobs posted by the Employer.
Apply Job: This use case denotes a set of actions required for Job Seeker to apply for an available
job vacancy.
Send resume: This use case denotes a set of actions required for Job Seeker to send in their CV for
an available job vacancy
Fill Form: This use case denotes a set of actions required for Job Seeker to add Reviews for an
organization that can be viewed by the Employer.

3.6 Entity Relationship Diagram


Entity relatioship (ER) diagram is a graphical representation of the static view of the system. It
describes the design, structure and maps out the system by displaying the system’s classes, their
attributes, methods and relationships among objects in the database.
Fig 3.3: ER Diagram

The diagram above shows a visual representation of the relationships betweeen entities, how classes
are related and interact with each other on the database.

You might also like