1

Chapter I

Introduction

1.1. Background of the project

An Enrollment System is a system designed to perform the process
involved in registration, advising, and payments of students as well as scheduling
of classes. It is a good step for the school and useful especially when the school
retrieves the important information about the student. In the enrollment system,
the school can trace what are the standings of the students. It automatically
computes for student transaction in enrollment, tuition fee, calculates other
charges, miscellaneous fees and even penalties. Lack of proper enrollment system
in a school can lead to problems and troubles, the students will be confusing on
what they should so and how they will do to be able to enroll. It is useful in the
school in the way of making the enrollment processes much easy. However, it is
one of the most tedious and costly processes during the school year. For college
districts that are still using a paper-based enrollment system, this process is a
prime candidate for becoming a computerized process since there are many
benefits in switching to computerized enrollment system.
Initao College (IC) is an institution of higher learning established through a local
ordinance which is Municipal Resolution No. 186, s.2003 dated October 14, 2003
signed by Hon. Enerito J. Acain V, who is the Municipal mayor as well as the
Board of Trustee of IC. Four days after, IC starts to operate as a college offering
various courses like Bachelor of Science in Business Administration, Hotel and
Restaurant Management and Bachelor of Science in Elementary Education.
Currently, IC is composed of 54 employees and 612 students and most of their
services such as enrollment are still done through manual procedure and paper-
based system, which is the records are literally written on a paper and physically
stored on enveloped, box and cabinet. One of the biggest challenges that the
college face is how to manage and integrate their increasing amount of
information both from the students and their employees.
 2

There are available Computerized Student Information Systems however

exclusively designed to a certain institution which is with accordance to
institutional policies.

1.1.1 Narrative Listing of the Existing System

IC enrollment process has six (6) steps, it starts with Step 1 the New
Students and Transferees will go to Guidance Office to undergo interview
by the guidance counselor, the student must take the entrance exam, fill
out Personal Information Sheets, and Needs Survey Form and Training
Form. And also the student must submit the requirements to the Guidance
Counselor and secure signature of the Guidance Counselor. These are the
steps that included in step 1. In Step 2 the students will undergo interview
and submit requirements to the Dean and undergo grade evaluation or
assessment of subjects taken, and also fill out Registration Form and
personal Information Data Sheet. Importantly, Secure the signature of
your Dean. These are the steps that the student must be completed that
are included in step 2.
In Step 3, the student must undergo interview by the School
Administrator and Present the certificate of Registration (COR) for
signature. These are the steps that are included in Step 3. In Step 4 and
Step 5, the student will go to the assessment office to present the
assessment form for computation of school fees and secure signature of
Assessment Officer and also the student must pay their respective
accounts and secure receipt payment. Lastly, Step 6 the student will
Submit the filled out registration form to the registrar for signature, submit
the Receipt of Payment for the Assessment Officer and Secure own copy of
duly signed Certificate of Registration to be presented to the instructors at
the start of classes. These are the steps that are included in Step 6.

This is the flow or the process of Enrollment System in Initao College

 3

Figure 1-1 Existing Enrollment Process of Initao College

Figure 1-1 Shows the Existing Enrollment Process of Initao

College, the process will accept for new students, returnees and
transferees.
 4

Figure 1-2 The Computerized Enrollment Information System Process

for Initao College

1.1.2. Issues and Problem

At present, the Initao College (IC) doesn’t have computerized systems for
their everyday transactions. These are the following issues and problems of Initao
College, that this system will address.

 Loss of Records
a.) Since storing of data in IC is through file based or filing
in packets. The Inputting of data is through manual and
paper-based system. There is a big possibility that some
of the data might be lost or might be missing.
 Unnecessary duplication of records.
a.) The IC enrollment system is manual and paper-based system
that produce paper loads that causes data work redundancy.
b.) Since the students are manually filling- up the official
documents of the school, there is a big possibility to obtain
 5

duplication of records that can cause further complexity in

the enrollment process.
 Time consuming and effort of searching the retrieval of data.
a.) Retrieval of information is a tedious and time consuming
task. The number of students increases every enrollment
making the management of information in hard copies even
more difficult.
b.) In the case of Initao College, students were consuming a lot
of time in doing such things. Manually filling-up of the
school’s official documents takes so much work to
accomplish especially IC is manned with only few
personnel.
c.) IC has using manual paper-based system for searching and
retrieving data. There is a big possibility that too much time
and effort will exert on manual searching and retrieval of
records and delayed in the issuance of requested records.

1.2. Statement of the problem

As mentioned in the Issues and Problems (Section 1.1.2), the recording,
retrieving, searching and enrolling manual processes being implemented in Initao
College, Initao College is very tedious and causes problems like losing of records,
unnecessary duplication data, and Time consuming and effort of searching the retrieval
of data. In this case, there is a need of developing a system that would help the Initao
College in obtaining a precise and comprehensive Computerized Enrollment Student
Information System that would lessen the problems stated in the Issues and Problems
(Section 1.1.2).

1.3. Objectives of the Project

Below are the objectives of this project that will guide the developers to solve
the presented problems.

1.3.1. General Objectives

The main objective of the project is to develop a Computerized Enrollment
Information System for Initao College at Initao, Misamis Oriental that will compensate
the school’s file-handling, and generation of forms and other documents.
 6

1.3.2. Specific Objectives

The following are the specific objectives of this project.

a.) To gather essential data about the process and the flow of activities
that related to the proposed system.
b.) To analyze the architectural design of the proposed system.
c.) To develop a web-based application based on the proposed system
architectural design that being analyzed.
d.) To evaluate the developed system through the testing that being used
(Functionality Testing and Acceptance Testing).
e.) To apply the changes encountered in developing the system and apply
the refinement based on the result evaluation conducted.
f.) To deploy the refined system to Initao College.

1.4. Scope and limitation of the project

This section discusses the scope and limitations of the proposed system.

1.4.1 Scope
The Computerized Student Information System is a web-based type
application that gives the end user to access via internet or LAN. Using LAN, it
has the capability of storing a fair amount of information, users can store their
files on a computer that is part of the LAN. And LAN has a built-in security
features such as it would virtually impossible for anyone to get hold of the files.
In the other side using Internet it helps several users to get online information
fast and Internet can store big data using cloud storage.

Computerized Enrollment Information System focuses on the major

processes of enrollment in Initao College such as computerized registration of
new students, enrollment for the returnee students, file maintenance and
handling, student assessment and generation of reports. With this, the Initao
College has four (4) users namely; School Administrator, Registrar, Department
Chairman and Assessor. The School Administrator has the privileges of using the
system such as view enrollment records, create user accounts, add subject,
update student information, create course and curriculum, and also create
academic year. In other side the Registrar can print the reports including COR,
list of student information enrolled, schedules, and add grades.
 7

In the Department Chairman (Dean), the Dean can enroll a student

(Returnee and Old), add student information, add new curriculum, add
instructor’s load, update student detail, add subject details, view enrollment
records, and print pre enrollment form. Lastly, the Assessor can assess student,
update student payment information and print assessment form.

1.4.2 Limitations
Computerized Enrollment Information System does not include scheduling
system for subject and instructor’s loading but instead, the assigned officer has
to input the schedule of each subject and instructors load. The system cannot
generate the official receipt for student payment since the school have no cashier
and then the student will pay their obligations in the office of the treasurer at the
Municipal Hall, Initao College, Misamis Oriental.

1.5. Significance of the project

This study is significant to the following entities:

School. The proposed system once implemented, it will help the school to
persuade new and incoming students to enroll. The computerized enrollment
system will provide the employee easy access to the files and records of the
students. With this, it will give the available student information quickly and
accurately.

Registrar office. With regards to the registrar’s office the proposed system
will help the school in maintaining the data of the students and the school will
not use the manual data gathering. The staff will just need to check the database
for the records needed. They will have the records updated, accurate and follows
fast issuances of documents requested by school clients.

Employees. The proposed system will speed up transactions and facilitate

efficient management of data.

Students. This proposed system will able to minimize the time and effort
that it takes to process student’s enrollment. Also it is beneficial to those parents
who are enrolling their children because it lessens the time during enrollment
process.
 8

1.6. Methodology
This section discusses the information being gathered by the proponents,
the procedures used, the observations and evaluations formed in developing the
proposed system.
1.6.1 Modified Waterfall Model
This section shows and describes how the proposed system is done.

Figure 1-7 The project methodology model (Modified Waterfall)

The proponents used modified waterfall instead of the traditional waterfall

to reduce the development cycle and to address the target user needs precisely.
When there is a bug and errors found during the different phases, the agile
arrows which is shown in the figure above allows the proponents to quickly
change direction to any phase. In this model, the requirements analysis is the
first phase then followed by requirements analysis, it will be followed by the
system design. The design is based on gathered data during the previous phases.
And in the development phase is where the construction and coding of the
proposed project is being done. The testing is discussing on the testing phase
and for the deployment of the project is deliberated in the implementation phase.

1.6.2 Requirement Analysis

In this Phase, the proponents have conducted a set of interviews last

September 2015 with the School administrator PhD. Olivia Hambre and finalized
the data last February 2016 with the new School Administrator PhD. Grace C.
Lapinig in the selected users such as the School Administrator, Department
Chairman, Registrar, and Assessor. These four users oblige and authorized to
 9

use the system. In order to achieve the requirement of the project, the proponents
conducted set of consultations with the client and to identify if there are any
clarifications and concerns with the functionality of the system. The
requirements of the project were gathered such as the student information form,
prospectus, list of students, list of instructors, assessment form and other related
forms.

1.6.3 Design Phase

The Design phase is the first interpretation and translation of the

requirements into systems conceptual designs and architecture models. During
design phase, the analysis results of the gathered requirements are translated
and being presented through diagrams which will be the basis for the actual
implementation of the proposed system which will be done during the succeeding
phase.

Figure 1-8. The Conceptual Framework of the Computerized Student

Information System for Initao College
 10

Figure 1-8 presents the overall structure of Computerized Enrollment

Information System for Initao College. The given design above Illustrates how
the data being gathered in requirement analysis and come up with this kind of
structure and design. Compared to the current flow of how enrollment being
processed and how the data of students being retrieved.

1.6.5 Testing
The functionality and operability of the new system depends on testing
and debugging phase. If there are errors encountered, adjustments are done to
further improve the system. To test if the final design functions properly, the
proponents shall repeat the testing and debugging phase. This process helps the
proponents to identify the missing program in the proposed application and
errors. Testing and debugging of codes are also done to ensure accuracy.
 11

Chapter II

Review on the Related Literature

2.1. Introduction
This chapter presents the related literature and existing systems that is used as
basis in constructing this project. These are carefully reviewed and analyze to acquire
significant ideas towards the realization of this project.

2.2. Related Literature

This section presents a review of related literature of the propose study.

2.2.1. Enrolment System Description

“An Enrolment system is a worldwide system that designed to do
the process involved in registration, assessments’, scheduling of classes
and student’s payment”. (Hachero, 2013).

Enrolment is the completion of the registration process, and affords

the full rights and privileges of student status. Enrolment is
accomplished by the payment or other satisfaction of tuition and
fees and by the satisfaction of other obligations to the University.
(The Columbia University in the city of New York, 2014). The
importance of enrolment system provides an organized way of
registering students, it avoids mix-up and confusion, it saves time
and effort and minimizes paper use and it provides a secured way
of keeping a database of enrolees, especially if you have a great
security and backup system provided with the enrolment system.
(Yahoo, 2006).

2.3. Related Existing System

Below are the related studies or existing studies that the proponent might
adopt in increasing the development of the proposed system.

2.3.1. Enrolment Information System for the Secondary Education of

Initao National Comprehensive High School (INCHS) at Poblacion, Initao,
Misamis Oriental
 12

This project was developed in 2015 by the BS-IT students of Mindanao

State University at Naawan, namely, Vini Kristi S. Gimena, Juneril L. Kwan,
Rolloves Vin F. Lobendina and Ressan E. Ocampo as a requirement to fulfil their
course subject “Capstone Project 2”. According to the developers, the purposed
of the project was to create a Computerized Enrolment Information System for
Initao National Comprehensive High School. The project aims to help the
Registrar (Head Teacher) and other personnel that assigned in keeping and
handling important information of the students. The system focuses the teachers'
load and sectioning of the students. Including school clinic, and guidance
counselor, and also the prefect of discipline will be computerized.
The main features of the project are: the system has four (4) modules
which are the Clinic, Guidance, Registration and Prefect, the Administrator
(Registrar) was responsible in inputting the enrolment information of the student
to the system. This system includes the teachers’ load, student information
system, subjects and sectioning also student schedules. Also generate and
printing the reports that were administered. In the clinic, the student physical
fitness information was inputted, while in the prefect side students’ information
like approved or disapproved remarks were inputted, and also in Guidance, only
the scholarship was inputted like a member of 4P’s or not.
Some features of INCHS enrolment system are adopted by the developers
of the proposed system such as adding student information, teacher’s load,
scheduling and generate reports.

Figure 2.1 INCHS enrolment system conceptual framework

 13

The process of enrolling student in INCHS enrolment system is shown in

figure 2.1, the administrator (Registrar) or the head teacher was responsible in
inputting the enrolment information included the teachers' load and student
information, subjects, section and schedules. And also the generation and
printing of the reports that were administered, this enrolment information was
stored to the ICNHS enrolment system.
In registration, the assigned user that inputted in student information to
the enrolment system. The following student information system are included:
LRN, name, gender, birthdate, birthplace, religion, address, school last attended,
average grade, mother’s name, father’s name, guardian’s name, home address,
grade level, and the school year last attended.
In the Clinic, only the height and weight of the students were inputted to
the system, while in the prefect side, the students' information like approved or
disapproved remarks were inputted. Lastly, in the guidance only scholarship
status of the student was inputted such as member of 4P's or not.

2.3.2 A Student scheduling system for a Microcomputer

The scheduling system are used by high schools to schedule their
students, balance classes, and print student schedules and class lists. This
project was developed by Michael C. Mahaney Jr, year 1985. This project is
flexible to provide for the generation of many different types of schedules. And
also the system will allow the school to enter required data using a
microcomputer. A microcomputer is a complete computer on a smaller scale and
is generally a synonym for the more common term, personal computer or PC , a
computer designed for an individual. A microcomputer contains a microprocessor
(a central processing unit on a microchip ), memory in the form of read-only
memory and random access memory , I/O ports and a bus (Rouse, 2005). Schools
send their schedules to the BOCES (Board of Cooperative Educational Services)
Regional computer center to be run on mainframe computers. The system was
developed to do student scheduling for high school of less than 1200 students.

The main features of the system are: the system will assign section to
students and provide the school with student schedules, class lists as well as the
 14

computer will then be able to generate the information necessary to build the
schedule. Finally, the schedule and final reports will be printed.

The following are the final schedule and report that will be printed:

1.) All data that are being entered by the user.

A.) Student information

1.) Name, grade, address.

2.) Courses requested.

B.) Schedule information

1.) Courses offered.

2.) Time and room information.

C.) Teacher information

1.) Courses and sections offered.

2.) Room or rooms used.

2.) The data that are being generated by the system.

A.) Information used to help build the master schedule.

1.) The number of student’s list registered for each course grade
levels.

2.) A conflict matrix which is used to determine how many students

are taking a given combination of courses.

B.) Conflicts after scheduling the students, the system will provide
information to resolve.

1.) Students list of all requested courses unable.

2.) A partial schedule for each student whose schedule contained a

conflict, listing any course in which a student was unable to enrol.
 15

3.) A listing of all classes and the number of students enrolled in

each.

C.) Changes can then be mad e to both student course selections and
course offerings.

D.) After arriving at an acceptable schedule the system will print the
following information:

1.) Individual student schedules for every student.

2.) Class lists.

3.) Master list of classes with enrolments.

Some features of the project are adopted by the developers of the proposed
system such as the scheduling and generate reports. This study is very essential
to the proposed system because it covers some features of the proposed system
that can be applied and develop by the developers.

2.3.4 Mindanao State University at Naawan – Integrated Developmental

School (MSUN-IDS) Enrolment System
This project was developed year 2011 by the BS-IT Students at Mindanao
State University at Naawan namely, Philip Cesar B. Garay, Jocebhel M. Bagares
and Farrah L. Arienza as a requirement of the subject “Software Engineering II”
according to the developers, the project aimed to replace the manual system of
MSUN-IDS to lessen and minimized the hassle time of manual enrolment system.
The procedures of the registration of students in manual enrolment system are
still the same to computerized enrolment system process. The system has five (5)
modules including Administrative, Cashier and Assessor, Registrar, Enrolment,
and Student Information/Kiosk.
The general features of the system are: the system contains all the
features that can be found of all the modules, the system defines school directory,
faculty members, subjects, subject prerequisites, composites, class room, class
section, and schedule template, also the system defines course prospectus and
course master list, manages course offerings, reservations, class scheduling, and
faculty teaching load, blocks students with liabilities, handles enrolment fees,
assesses and monitors student fees, generates billable and collectible accounts
 16

and summary of fees. Lastly, the system can produce and generate Certificate of
Registration (COR) for the students who are enrolled.
Basically, general features of the project are adopted by the developers of
the proposed system such as manages course offering and class scheduling, and
enrolment fees, assessment, and also the printing of Certificate of registration
(COR) is included.
2.4 Summary
Base on the data obtained among the related existing system, the
proponents found out that the related existing system mentioned above was
needed, it can be great help to the proponents that it caters some of the proposed
system might be needed such as adding student information and updating all
records of students and enrollment process. And also It speed-up the processing
of data can make accurate and organize report which is easy to understand.
 17

Theoretical Framework

The purpose of this chapter is to present a theoretical and conceptual framework,

which will be employed by this study. The theoretical and conceptual framework is
based on the findings presented in the literature reviewed earlier. It serves as a
foundation of the proposed system and ensuing the discussion will highlight the
relationship and the influence of these theoretical concepts in relation to the
development of the system.

3.1 Technology Used Details

This section discusses the technologies used in creating and implementing
the Computerized Student Information System in Initao College as a web-based
application.

The following are the technologies used in making the CEISIC.

3.1.1 JavaScript
JavaScript is a programming language commonly used in web
development. It is a client-side scripting language, which means the source code
is processed by the client's web browser rather than on the web server. This
means JavaScript function scan run after a webpage has loaded without
communicating with the server (Per Christensson, 2005).

Figure 3-1 JavaScript Logo

The proponents considered to used JavaScript as their front end of
the system and client scripting language since the system depends on
 18

client’s web browser and JavaScript gives the user more control over the
browser, and also validates user’s input.
3.1.2 PHP (Hypertext Preprocessor)
PHP is an HTML-embedded Web scripting language. This means PHP code
can be inserted into the HTML of a Web page. When a PHP page is accessed, the
PHP code is read or "parsed" by the server the page resides on. The output from
the PHP functions on the page are typically returned as HTML code, which can
be read by the browser. Because the PHP code is transformed into HTML before
the page is loaded, users cannot view the PHP code on a page. This make PHP
pages secure enough to access databases and other secure information (Per
Christensson, 2005).
PHP found on most web servers and is used by developers to create
dynamic and database driven websites (Jennifer kyrnin, 2016).

Figure 3-2 PHP Logo

The proponents preferred to used PHP as their back end since PHP
provides cross platform compatibility, unlike some other server side scripting
language. It also supports extended regular expression that leads extensive
pattern matching with remarkable speed.

3.1.3 Wamp Server (Windows, Apache, MySQL, PHP)

Wamp Server is a Windows web development environment. It allows you
to create web applications with Apache, PHP and the MySQL database. It also
comes with PHP MyAdmin to easily manage your databases (Abhishek Sanghvi,
2013).

Figure 3-3 Wamp Server Logo

 19

The proponents considered to used Wamp Server as their server since it

manage Apache and Database services, it can switch online or offline that gives
access to everyone or only localhost and manage server’s settings and also
access setting files to the system.
3.1.3 MySQL Database
MySQL, pronounced either "My S-Q-L" or "My Sequel," is an open source
relational database management system. It is based on the structure query
language (SQL), which is used for adding, removing, and modifying information
in the database. Standard SQL commands, such as ADD, DROP, INSERT, and
UPDATE can be used with MySQL.

Figure 3-4 MySQL Logo

The proponents decided to use MySQL as their database since it
supports most administrative tasks for MySQL and A common
scheduling dialog that allows you to perform action of the management
dialogs at a later time.
 20

Chapter 4

The System

4.1. System Requirements & Specifications

This section gives the overall specifications and functional requirements of the
system to be developed.

4.1.1. System’s Function

This section provides a listing of all the functions that must be performed
or delivered by the system & a description of each, Screen designs are included,
to help visualize the menu & toolbar options.

4.1.2 Physical Environment & Resources

This section discusses the hardware & software resources needed to
implement & to execute the system.

4.1.2.1 Software Requirements

Software Uses

Windows XP or Higher, MAC OS, Operating System

Linux

WAMP Server Server

Any Browser (HTML 5 Compatible) Browser

Table 4.1.2.1.1 Software Requirements for Deployment

 21

4.1.2.1 Hardware Requirements

Hardware Definition

1 GB Memory

80 GB Above Hard Drive

Modern GSM Modem/ Broadband

Table 4.1.2.1.2 Hardware Requirements for Deployment

4.2. Design Models

The Design Model is an Object model that describes the realization of use
cases, and serves as an abstraction of the implementation model and its source
code. The design model is used as an essential input to activities in
implementation and test.

Below are the diagrams that illustrates the system designs which are
context diagram, use-case diagram, activity diagram, sequence diagram, entity
relationship diagram and data dictionary.

4.2.1 Context Diagram

A Context diagram is a single high-level process and then shows
the relationship that the system has with other external entities.

The Below figure shows the context diagram of IC.

Figure 4-2 context diagram (Level-0) of the proposed enrollment

System for Initao College
 22

Figure 4-3 The context diagram (Level-1) of the proposed enrollment

system for Initao College

By referring to figure 4-3, the context Diagram illustrates the structure of

the proposed system which has five modules; the college administrator, registrar,
assessor and department chairman.

The assessor will request and record the paid amounts of the students to
the database and the proposed system will produce the assessment form for the
students, print billing information, and compute the student payment details.
The administrator has the over-all privilege to the proposed system. He/she will
be the one to add class schedules, subjects, curriculum, users, courses,
departments, and others. The enrollment officer will be the one to add, update
and enroll new students and lastly, the registrar will override the maximum loads
per student and requisites per subjects.

4.2.2 UML Use Case Model

This section shows the use case diagram and use case specification od
CSIS.
 23

4.2.2.1 Use Case Diagram

A use case diagram describes the behavior of a system from a user’s
standpoint. The functional description of a system and also its major
processes it provides a graphic description of who will use the system and
what kind of interactions to expect within that system.

Below figure shows the Use Diagram of CEIS

Figure 4-4 Use Case Diagram of Computerized Enrollment

Information System for Initao College (CSIS)

Figure 4-4 Shows the Use Case Diagram of CEIS. As shown below,
it has four (4) actors namely: administrator, assessment, registrar, and
department chairman.

4.2.2.2 Use Case Specification

A use case specification is a list of actions or event steps,
typically defining the interactions between a role (known in the Unified Modeling
Language as an actor) and a system, to achieve a goal. The actor can be a human
or other external system.
 24

4.2.2.2.1 Actors
Can be a human or other external system.

Administrator

The administrator has the over-all privileges in the system. They

are the one who will create the new curriculum, subject, requisites and
other important matter with regards to the enrollment.

Registrar

The registrar is the who has the capability of printing of all the
reports including printing of (COR, exam permit, master list, schedules,
grades and student information and also the registrar can add grades.

Department Chairman

The department chairman (Enrollment Officer) will be the one to

add, update and enroll new students and also the one who can manage all
the scheduling.

Assessor

The assessor (assessment Officer) is the one who prints the student
assessment form, update student assessment and update the student
payment such as printing of billing information and computation of
student payment details.

4.2.2.2.2 Add Account

Purpose

Allows the administrator to add new user account.

Pre-condition

The administrator must have logged in first into the system

before this use case begins.

Post- condition
 25

If this process is successful, new user account is added into

the system database. Else the system will state unchanged.

4.2.2.2.3 Manage User Account

Purpose

Allows the administrator to manage user accounts.

Pre-condition

The administrator must have logged in first into the system

before this use case begins.

Post-condition

If this process is successful, user accounts are managed,

either activated or deactivated. Else the system will state
unchanged.

4.2.2.2.4 Add New Student

Purpose

Allows the department chairman to add new student.

Pre-condition

The department chairman must have logged in first into the

system before this process or this use case begins.

Post-condition

If this process is successful, new student is added to the

system. Else, the system will state unchanged.

4.2.2.2.5 Enroll Student

Purpose

Allows the department chairman to enroll student.

Pre-condition

The department chairman must search or add the student

first to the system before this process will begins.
 26

Post-condition

If this process is successful, student is enrolled to the

system. Else, the system will state unchanged.

4.2.2.2.6 Add New Course

Purpose

Allows the department chairman to add new course.

Pre-condition

The department chairman must have search first the course

to the system before this process will begins.

Post-condition

If this process is successful, new course is added. Else, the

system will state unchanged.

4.2.2.2.7 Add Subject

Purpose

Allows the department chairman to add new subject.

Pre-condition

The department chairman must have logged in first into the

system before this process or this use case begins.

Post-condition

If this process is successful, new subject is added to the

system. Else, the system will state unchanged.

4.2.2.2.7 Add Faculty

Purpose

Allows the department chairman to add faculty.

Pre-condition
 27

The department chairman must have logged in first into the

system before this process or this use case begins.

Post-condition

If this process is successful, faculty is added to the system.

Else, the system will state unchanged.

4.2.2.2.8 Add Room

Purpose

Allows the department chairman to add room.

Pre-condition

The department chairman must have logged in first into the

system before this process or this use case begins.

Post-condition

If this process is successful, room is added to the system.

Else, the system will state unchanged.

4.2.2.2.9 Manage Offered Subject

Purpose

Allows the department chairman to manage offered subject.

Pre-condition

The department chairman must have logged in first into the

system before this process or this use case begins.

Post-condition

If this process is successful, offered subject is managed to

the system. Else, the system will state unchanged.

4.2.2.2.10 Evaluation
Purpose

Allows the department chairman to add grades.

 28

Pre-condition

The department chairman must have logged in first into the

system before this process or this use case begins.

Post-condition

If this process is successful, grade is added and update to

the system. Else, the system will state unchanged.

4.2.2.2.11 Print Reports

Purpose

Allows the registrar to print. Including grades, COR, master

list, schedules, student information and exam permit.

Pre-condition

The registrar must have search first the student into the
system before this process or this use case begins.

Post-condition

If this process is successful, reports are printed. Else, the

system will state unchanged.

4.2.2.2.12 Assessment
Purpose

Allows the assessor to assess student and update student

payment.

Pre-condition

The registrar must have search first the student into the
system before this process or this use case begins.

Post-condition

If this process is successful, assessment of student is

updated and assessed. Else, the system will state unchanged.
 29

4.2.3 Activity Diagram

This section shows and provides all the activity diagram from each
modules namely: Administrator, Registrar, Assessor and Dept. Chairman. It
illustrates one individual activity. Fundamental elements of the activity are
actions and control elements (decision, division, merge, initiation, end, etc.) as
shown below. Elements are connected by so-called” activity edges” it represents
the action of the activity and from the” control flow”, which can also be casually
called “flow”. The execution of an activity can contain parallel flows. A border can
surround the activity, meaning the entire activity diagram.

The below figures are the activity diagram of CEIS per use case.

Figure 4.5 Activity of log in account

 30

Figure 4.6 Activity Diagram of Student Assessment

Figure 4.7 Activity Diagram of View rooms

 31

Figure 4.8 Activity Diagram of view and add grade

Figure 4.9 Activity Diagram of Print COR

 32

Figure 4.10 Activity Diagram of Export to Excel

Figure 4.11 Activity Diagram of Add Course

 33

4.2.4.1 Sequence Diagram

Sequence Diagrams are interaction diagrams that detail how operations are
carried out (Massimo, 2004).
The below figures are the sequence diagrams of CEIS per use case.

Figure 4-12 Sequence diagram of add user account

Figure 4-13 Sequence diagram of Manage user accounts

 34

Figure 4-14 Sequence diagram of add and & update

Figure 4-15 Sequence diagram of view rooms

Figure 4-16 Sequence diagram of search subject

 35

Figure 4-17 Sequence diagram of search subject

Figure 4-18 Sequence diagram of view grade

Figure 4-19 Sequence diagram of print COR

 36

4.2. 4.2 Entity relationship Diagram

An entity relationship diagram (ERD) is a representation of data within a
domain. It Consists of entities as well as relationships between entities.

Below figure is the entity diagram of CSIS.

Figure 4-20 Entity Relationship Diagram of CSIS

 37

The figure 4-22 is the presentation of all collection of entities, attributes

and relationship among entities, typically used in computing in regard to the
organization of data within databases or information systems of the project.

4.2.4.2 Data Dictionary

TABLE NAME ATTRIBUTE DATA TYPES DESCRIPTI REFERE
ON NCE
TBL_STUDENT
STUDENT_ID INTEGER PRIMARY
KEY
LNAME VAR(30)
FNAME VAR(30)
MNAME VAR (30)
GENDER VAR (30)
BDATE DATE
RELIGION VARCHAR
(50)
MOTHER_NAME VARCHAR
(50)
FATHER_NAME VARCHAR
(50)
FATHER_OCCUP VARCHAR
(50)
MOTHER_OCCUP VARCHAR
(50)
CONTACT_NUMBER VARCHAR
(35)
STATUS VAR (20)
SPOUSE VAR (50)
ADDRESS VAR (50)

TBL_OTHER_
COURSE
STUDENT_OTHER_ INTEGER PRIMARY
COURSE KEY
SUDENT_ID INTEGER FOREIGN
KEY
COURSE_ID INTEGER FOREIGN
KEY
DATE_IN DATE

TBL_COURSE
COURSE_ID INTEGER PRIMARY
KEY
 38

COURSE_DESCRIPTI VARCHAR
ON_OLD (20)
COURSE_DESCRIPTI VARCHAR
ON_OLD (20)
MAJOR VARCHAR
(15)
COURSE_ABB VARCHAR
(10)
TBL_ASSESMENT
ASSESSMENT_ID INTEGER PRIMARY
KEY
STUDENT_ID INTEGER FOREIGN TBL_ASS
KEY ESSOR
EMPLOYEE_ID INTEGER FOREIGN
KEY
TERM_SCHOOL_YEA VARCHAR FOREIGN
R_ID (35) KEY
MISC_AMOUNT FLOAT
AMOUNT_PAID FLOAT
REMARKS VAR (20)
MANDATORY VAR (35)

TBL_MISCELLENEOUS
MISCELLENEOUS_ID INTEGER PRIMARY
KEY
MISCELLENEOUS_FE FLOAT
E
AMOUNT FLOAT

TBL_STUDENT_MISCELL
ENEOUS
STUDENT_MISCELLE INTEGER PRIMARY
NEOUS _ID KEY
MISCELLENEOUS_ID INTEGER PRIMARY
KEY
ASSESSMENT INTEGER PRIMARY
KEY

TBL_TUITION_FEE
TUITION_FEE_ID INTEGER PRIMARY
KEY
TUITION_FEE_CODE INETEGER
TUITION_FEE_DESCR VAR(30) FOREIGN
IPTION KEY
TUITION_FEE_AMOU VARCHAR FLOAT
NT (15)
SY VAR (15)

TBL_TUITION_ASSESS
 39

TUITION_ASSESS _ID INTEGER PRIMARY

KEY
TUITION_FEE_ID INTEGER FOREIGN
KEY
ASSESSMENT_ID INTEGER FOREIGN
KEY
TBL_ENROLLED_SUBJE
CT
ENROLLED_SUBJECT INTEGER PRIMARY
_ID KEY
OFFERED_SUBJECT_ INTEGER FOREIGN
ID KEY
EMPLOYEE_ID INTEGER FOREIGN
KEY
TUITION_ASSESS_ID INTEGER FOREIGN
KEY
ASSESSMENT_ID INTEGER FOREIGN
KEY
STUDENT_ID INTEGER FOREIGN
KEY

TBL_TERM_SCHOOL_YE
AR
TERM_SCHOOL_YEA INTEGER PRIMARY
R _ID KEY
AY VAR (10)

TBL_OFFERED_SUBJEC
T
OFFERED_SUBJECT INTEGER PRIMARY
_ID KEY
ROOM_ID INTEGER PRIMARY
KEY
SUBJECT_ID INTEGER PRIMARY
KEY
INSTRUCTOR_ID INTEGER PRIMARY
KEY
TERM_SCHOOL_YEA INTEGER PRIMARY
R_ID KEY
SLOTS VAR (5)
SEMESTER VAR (15)
AY VAR (15)
SECTION VAR (15)

TBL_EMPLOYEE
EMPLOYEE_ID INTEGER PRIMARY
KEY
FULLNAME VAR (50) FOREIGN
KEY
 40

POSITION VAR (50)

STATUS VAR (20)
USERNAME VAR (30)
PASSWORD VAR (30)
REMARKS VAR (30)

TBL_ROOM
ROOM_ID INTEGER PRIMARY
KEY
CAPACITY VAR (10)
ROOM_NUM VAR (10)
BUILDING_NAME VAR (10)

TBL_SUBJECT
SUBJECT_ID INTEGER PRIMARY
KEY
SUBJECT_CODE VAR (20)
DESCRIPT_TITLE VAR (15)
SECTION VAR (15)
UNITS_LEC DOUBLE
UNITS_LAB DOUBLE

TBL_COURSE_SUBJECT
COURSE_SUBJECT INTEGER PRIMARY
_ID KEY
SUBJECT_ID INTEGER PRIMARY
KEY
COURSE_ID INTEGER PRIMARY
KEY
PRE-REQUISITES VAC (50)

TBL_INSTRUCTOR
INSTRUCTOR _ID INTEGER PRIMARY
KEY
FULLNAME VAR(50)
ADDRESS VAR(30)
POSITION VAR(20)
SPECIALIZATION VAR(20)
EMPLOYEE_STATUS VAR(20)
 41

4.2.4.1 Functional Decomposition Diagram CEIS

Mainly, functional decomposition diagram focusses on how the overall

functionality is developed and its interaction between various components.

Figure 4-21 Deployment Diagram of CSIC

4.2.4.3 Deployment Diagram

A deployment diagram is a structure diagram which shows architecture of
the system as deployment (distribution) of software artifacts to deployment
targets.

Figure 4-22 Deployment Diagram of CS

 42

4.3 Structure & Interface

This section discusses the system functions through screen shots.
Walkthrough to the system’s interface will be reflected here.

4.3.1 System Walkthrough

This section shows the walkthrough or the demonstration of each
task of the system.
The below figures are the tasks of each modules.

Figure 4-23 Log in User Account

Figure 4-1 shows the log in user account of CSIS, in which every user has
different types of account and can only log in to their designated user modules.

Figure 4-24 Administrator module

 43

Figure 4-2 shows the administrator module and has the over-all
privileges in the system. They are the one who will create the new
curriculum, subject, requisites and other important matter with regards
to the enrollment.

Figure 4-25 Add New Student

Figure 4-3 shows the add student interface, in this scenario it allows the
department chairman to add new student.

Figure 4-26 Enroll Student

Figure 4-4 shows the enroll student interface, in this scenario the
department chairman can only enroll a student.
 44

Figure 4-27 Add New Course

Figure 4-5 shows the add new course interface, in this scenario the
department chairman is the one who can add or define a new course.

Figure 4-28 Add Subject

Figure 4-6 shows the add subject interface, in this scenario the
department chairman can only add subject.
 45

Figure 4-29 Add Faculty

Figure 4-7 shows the add faculty interface, in this scenario the department
chairman can only add faculty member.

Figure 4-30 Manage Offered Subject

Figure 4-8 shows the manage offered subject interface, in this

scenario it allows the department chairman to manage offered subject.
 46

Figure 4-31 Grade Evaluation

Figure 4-9 shows the grade evaluation of student, in this scenario

the department chairman and registrar can only add grades of student.

Figure 4-32 COR Sample Print

 47

Figure 4-10 shows the printed COR, in this scenario all printing of reports
are included, and Allows the registrar to print. Including grades, COR, master
list, schedules, student information and exam permit.

Figure 4-33 Student Assessment

Figure 4-11 shows the Student Assessment, it this scenario it Allows the
assessor to assess student and update student payment.

Figure 4-34 Sample Print Assessment

 48

Figure 4-35 Add Tuition Fee

Figure 4-36 Sample PEF form Print

Figure 4-37 Manage User Account

 49

4.3.2 Graphical User Interface

This section discusses the GUI design issues. Discussions are best
presented through sample screenshots of the running system’s interface.
4.3.2.1 GUI Design Issues
This section discusses the GUI design issues encountered during the
running of the system’s interface. The following are GUI errors detected by the
proponents and the users.

Figure 4-38 Error in viewing list of class in admin module

Figure 4-39 Error in enrolling a student in admin module

 50

Figure 4-40 Error in advising a subject in admin module

 51

Table of Contents
Chapter I .................................................................................................................................................. 1
Introduction ............................................................................................................................................ 1
1.1. Background of the project .............................................................................................. 1
1.1.1 Narrative Listing of the Existing System ................................................................ 2
1.1.2. Issues and Problem ................................................................................................... 4
1.2. Statement of the problem ............................................................................................... 5
1.3. Objectives of the Project .................................................................................................. 5
1.3.1. General Objectives .................................................................................................... 5
1.3.2. Specific Objectives ..................................................................................................... 6
1.4. Scope and limitation of the project .............................................................................. 6
1.4.1 Scope...................................................................................................................................... 6
1.4.2 Limitations ........................................................................................................................... 7
1.5. Significance of the project ............................................................................................... 7
1.6. Methodology ............................................................................................................................... 8
1.6.1 Modified Waterfall Model ................................................................................................. 8
1.6.2 Requirement Analysis ....................................................................................................... 8
1.6.5 Testing ............................................................................................................................. 10
Chapter II .............................................................................................................................................. 11
Review on the Related Literature ................................................................................................... 11
2.1. Introduction ...................................................................................................................... 11
2.2. Related Literature ............................................................................................................ 11
2.2.1. Enrolment System Description ................................................................................... 11
2.3. Related Existing System ....................................................................................................... 11
2.3.1. Enrolment Information System for the Secondary Education of Initao
National Comprehensive High School (INCHS) at Poblacion, Initao, Misamis
Oriental .......................................................................................................................................... 11
2.3.2 A Student scheduling system for a Microcomputer............................................... 13
2.3.4 Mindanao State University at Naawan – Integrated Developmental School
(MSUN-IDS) Enrolment System .............................................................................................. 15
2.4 Summary .................................................................................................................................... 16
Chapter 3 ............................................................................................................................................... 17
 52

Theoretical Framework ...................................................................................................................... 17

3.1 Technology Used Details........................................................................................................ 17
3.1.1 JavaScript .......................................................................................................................... 17
3.1.2 PHP (Hypertext Preprocessor) ....................................................................................... 18
3.1.3 Wamp Server (Windows, Apache, MySQL, PHP) ..................................................... 18
3.1.3 MySQL Database .............................................................................................................. 19
Chapter 4 ............................................................................................................................................... 20
The System............................................................................................................................................ 20
4.1. System Requirements & Specifications .................................................................... 20
4.1.1. System’s Function .......................................................................................................... 20
4.1.2 Physical Environment & Resources ........................................................................... 20
4.1.2.1 Software Requirements ........................................................................................... 20
4.2. Design Models ......................................................................................................................... 21
4.2.1 Context Diagram .............................................................................................................. 21
4.2.2 UML Use Case Model ...................................................................................................... 22
4.2.2.1 Use Case Diagram .................................................................................................... 23
4.2.2.2 Use Case Specification ............................................................................................ 23
4.2.2.2.1 Actors ................................................................................................................... 24
4.2.2.2.2 Add Account ....................................................................................................... 24
4.2.2.2.3 Manage User Account ...................................................................................... 25
4.2.2.2.4 Add New Student .............................................................................................. 25
4.2.2.2.5 Enroll Student ................................................................................................... 25
4.2.2.2.6 Add New Course ................................................................................................ 26
4.2.2.2.7 Add Subject ........................................................................................................ 26
4.2.2.2.8 Add Room ............................................................................................................ 27
4.2.2.2.9 Manage Offered Subject .................................................................................. 27
4.2.2.2.10 Evaluation ........................................................................................................ 27
4.2.2.2.11 Print Reports .................................................................................................... 28
4.2.2.2.12 Assessment ...................................................................................................... 28
4.2.3 Activity Diagram ............................................................................................................... 29
4.2. 4.2 Entity relationship Diagram .................................................................................... 36
4.2.4.2 Data Dictionary ............................................................................................................. 37
4.3 Structure & Interface .......................................................................................................... 42
 53

4.3.1 System Walkthrough ................................................................................................... 42

4.3.2 Graphical User Interface ................................................................................................ 49
4.3.2.1 GUI Design Issues .................................................................................................... 49