Enrollment System

CHAPTER I

INTRODUCTION

BACKGROUND OF THE STUDY
Information System refers to the interaction of people, data, process and technology. It is used by the society or by an organization for the support in their operations, management and decision-making to make transaction more simple and easy. The activities of an IS are devoted to provide data and information to improve the effectiveness and efficiency of different operation of a business in an organization.
One classification of an Information System is Transaction Process System that handles or records day to day transaction of a business. Example of this is an Enrollment System, a computer generated process which can support the operation and management of a school. This is designed for recording, verifying and processing student’s information who registers on a particular institution.
Despite of helpful services provided by an enrollment system, there are still many institutions that use manual procedures like Munting Ilog National High School Silang West Annex. In their school, they manually do the encoding of students information and listing and checking of students’ requirements. This resulted in lot of difficulties that they encounter in handling their transactions leading to more serious problems like unreliable records of the students and data losses. The manual procedure also takes so much time and effort thus bringing lots of wasted time and more workload for the personnel in charge and for the students enrolling.
To address the above problems, the developers developed a computerized enrollment system. This system is capable of providing a fast-paced enrollment processes resulting to a better enrollment transaction not only for the part of staff but also for the students. It minimized if not completely remove all the drawbacks of the manual enrollment to provide a better service and a high quality process outcome.

OBJECTIVE OF THE STUDY

GENERAL OBJECTIVE
The general objective of the study is to develop the Munting Ilog National High School Silang West Annex Enrollment System.

SPECIFIC OBJECTIVE
This study specifically aims to:
1. To design a system that will replace the manual enrollment resulting to speed up transaction, reliable and accurate students’ information, and fast access to students’ record.
2. To develop a systematic and user-friendly environment that will minimize human error and avoid data losses.
3. To evaluate performance of the proposed system.

SCOPE AND LIMITATIONS
The system is an information system exclusively designed for Munting Ilog National High School Silang West Annex. The Munting Ilog National High School Silang West Annex Enrollment System is proficient of gathering students’ and teachers’ information and summarizing it to produce accurate and reliable records. It is capable of generating automatically the section of the students. It also allows the teachers to view their information and print their updated schedules. This system is implemented on LAN to provide a faster service. It has three direct users with different level of access including of one (1) admin, three registrars (3) and all the teachers in the said school. All these users are allowed to update their accounts providing that their new user name is unique and available. In case they forgot their password they can still access the system by answering the security questions that they provide while creating their account.
The system was developed using Microsoft Visual Studio 2010 Ultimate as the front end which serves as the User's Interface and MySQL (Structured Query Language) as the back end which handles the database. ODBCAD 32 was used to connect the system to its back end (MySQL). It was created for about 3 months with the incorporation of these application software committed to ensure the efficient and fast processing of records.
This system does not automatically generate schedules for the students. The admin is in charge in encoding manually the schedules of each section before the enrollment starts. Another drawback of the system is, if there are instances that a user forgot his/her username, they cannot access their account anymore. There is no security questions provided for unrecognizable username so what they need to do is to create a new account. The system is a network based application but does not work online. In case of power failure, it is not capable of saving any unsaved data or transaction. Only the current unsaved transaction will not be saved, all the other entries will remain in the database.

OPERATIONAL DEFINITION OF TERMS

Munting Ilog National High School Silang West Annex Enrollment System. The title of the study.
Information System. It is the combination of people, hardware, software, communication devices, network and data resources that processes data and information providing a business to operate its daily works more accurate and easier.
Transaction Process System. It is a type of information system that collects, stores, modifies and retrieves the data transactions of an enterprise.
Computerized Enrollment System. The solution of the developers which replaced the manual enrollment of the school.
User-friendly Environment. Interface of the system that is easy to use and understand.
Local Area Network (LAN). It is a single location connection of devices or peripherals/ computers.
Microsoft Visual Studio 2010. It is an application software that the developers used to create the system’s user interface.
Front-end. Refers to the graphical interface of the system where all data are entered; application development.
MySQL. Application software that the developers used to handle the storing of data in the system.
Structured Query Language. The database language which the developers used for managing the data in the system
Back- end. Refers to the database management system (DBMS); the storehouse for the data.
Database. Collection of student’s data which composed his/her record.
ODBCAD 32. Application software that the developers used for the system to connect in MySQL.

Conceptual Model of the System

* System Analysis * Requirement Analysis * Requirement Definition

* System Design * Contex Flow Diagram

* System Development * System Development Life Cycle

* System Testing * Alpha * Beta

Munting Ilog National High School West Annex Enrollment System 1. Knowledge Requirements a. Enrollment System b. Munting Ilog National High School West Annex Enrollment System c. Programming d. Local Area Network e. Database Management System f. System Analysis and Design

2. Software Requirements a. MS Visual Studio Ultimate 2010 b. MySQL c. ODBCAD 32 d. Operating System e. Adobe Photoshop CS4

3. Hardware Requirements a. Networking Cables b. Switch
Server Requirements
a. At least Pentium IV processor.
b. Must have at least 128MB of RAM or higher
Client Requirements
a. At least Pentium IV processor.
b. Must have at least 128MB of RAM or higher

INPUT PROCESS OUTPUT

→
SSS

EVALUATION

Figure 1. Conceptual Model of System
Figure 1, presents the conceptual model of study of Munting Ilog National High School Silang West Annex Enrollment System. It is composed of four important blocks, the input requirements, process involved, output result and the evaluation.
The first block which is the input requirements consists of Knowledge Requirements, Software Requirements and Hardware Requirements. The system requires the knowledge about the enrollment system, programming, LAN, database management system and system analysis and design. Microsoft Visual Studio Ultimate 2010 for programming language, MySQL for the database, ODBCAD 32 as the connector, Operating System and Adobe Photoshop CS4 composed the Software Requirements. For the hardware requirements, RAM with at least 128MB, Pentium IV processor, networking cables and router switch are needed.

For the system to be more sufficient, a lot of major processes were done such as planning, analyzing, designing, developing, testing, implementing and maintaining. The process for the system analysis contains the requirement analysis and requirement definition. For the design and development of the system, it includes context flow diagram and system development life cycle. Through these processes, all the system requirements and objectives were met.

For the evaluation, the user used alpha-beta testing to measure the system performance. It served as the gathering tool for feedbacks, comments and suggestions through the use of evaluation forms. The system was improved in presence of some errors and the output and module design was tested.

CHAPTER II

RESEARCH METHODOLOGY

In this chapter, all the processes that the developers underwent to achieve the objective of the study is shown. This includes the project design, project development, operational and testing procedure, and evaluation of the study.

PROJECT DESIGN To be able to come up with an organized project, there should be a design on how the project should function. This design served as the developer’s guide in attaining the project objectives. Figure 2. System Context Flow Diagrams

Registration Form

Figure 2, illustrates that Admin, being the administrator should log in first his password and username. If he is a valid user, he has all the privileged to use all the features of the system such as encoding students’ and teachers’ information and updating it. The system will generate this information thus returning report to the admin. This report comprises the students section and schedules producing the registration form which will be given to them. The registrars should have a valid account to use the system. If they are authorized user, they can now encode information of the enrollees and search and update students’ records if necessary. The system would generate reports containing students’ information and schedule producing their registration form. In part of the teachers, they should also log in first an authorized account. If they are valid user, they can access minimal features of the system. This includes viewing their profile and schedule of their advisory class. The system will return reports that consist of their schedules which can be printed. PROJECT DEVELOPMENT The developers used the System Development Life Cycle (SDLC) for the development of Munting Ilog National High School West Annex Enrollment System. The diagram shown below illustrates the different phases of SDLC model that show the sequence of the activities that the developers needed to undergo for the project development.
Figure 3. System Development Life Cycle

Analysis and Planning Phase. In this stage, the system was defined based from the interviews, researches, investigations and business requirements of the client. All the needed informations and materials for the development of the system were collected and the time bound was set.

Design Phase. During this stage, layouts and diagrams were created based from the gathered materials and informations, considering also the business rules and specifications given by the client. The actual interface of the system and the database that supported it were also designed.

Figure 4 shows the Data Flow Diagram for Admin Scenario. The admin should first input a username and password. If it is a valid account, he has now the privilege to access all the features of the system. First, he could encode schedule for a section to be stored in the sec_sched. Generating and updating recorded schedules are also obtainable. These schedules could be printed and the report will be given to the admin. Second, the admin could create section that would be stored in the section table. Afterwards, he can add subjects to this section to be stored in subject table. Generating section is also available. Viewing section would allow the admin to view all the students’ and their profile within that selected section. Tables that would be source of data that allow this process were the student table for student information, and section table for the information of the section. Third, the admin could encode teachers’ information to be stored in teacher table. This would produce a teachers’ record that could be viewed, updated and printed together with their schedules. Sec_sched for teachers’ schedule and teacher table for their information would be the source of data. The printed schedule would be given to teachers and the schedule report to the admin Fourth, encoding students’ information could also be done by the admin. These recorded students’ records would store in the student table. Viewing, updating and printing students’ registration forms that contained their schedule and some information from the sec_sched and student tables are allowed. These registration forms would be given to the students and a report would be given to the admin. Lastly, the admin is allowed to update his password and username. The updated username and password would be saved in the password table and report will be issued upon updating the account.

Figure 5 shows how data were processed in the system for the registrar scenario. The registrar should log-in first his/her username and password in order to access the system. After the verification, he/she could the encode enrollees’ information to be stored in the student table. The registrar could also search and update student’s record. Registration form containing the student’s information and its schedule will be printed and given to the enrolled student. Report will be issued to the registrar after the registration form was printed. On the other hand, the registrar can also update his/her account providing his/her username and password. The updated username and password would be saved in the password table and report will be issued upon updating the account.

Figure 6 shows the data flow diagram for the Teachers Scenario. To be able to use the system, the teacher should log in first his username and password. If he is a valid user, he can now successfully access the system. He can view the schedule of his advisory class that would be given by the sec_sched table. He could also view his profile and schedule from the teacher and sec_sched tables by encoding his identification. A teacher report could be printed comprising some of his information and schedule which would be given to him. Another capability of teacher’s account is that, the teacher is allowed to view all the students and their profiles of a particular section providing that he is the registered adviser of them. Updating username and password is also allowed within this account. The updated username and password would be saved in the password table and report will be issued upon updating the account.

DATABASE DESIGN
Table 1. stud_personal Table Field Name | Data Type | Description | std_code | VARCHAR | Student code | std_type | VARCHAR | Student type | std_level | VARCHAR | Student level | std_school_year | VARCHAR | Student school year | grade | VARCHAR | Grade | std_firstname | VARCHAR | Student first name | std_middlename | VARCHAR | Student middle name | std_lastname | VARCHAR | Student last name | std_address | VARCHAR | Student address | std_dob | VARCHAR | Student date of birth | std_pob | VARCHAR | Student place of birth | std_age | VARCHAR | Student age | std_gender | VARCHAR | Student gender | std_citizenship | VARCHAR | Student citizenship | std_religion | VARCHAR | Student religion | Table1, the Student’s Personal Information Table, is used for storing the personal information of the student.

std_contact | VARCHAR | Student contact number | Table 2. stud_family Table | | | | Field Name | Data Type | Description | std_father | VARCHAR | Student father | std_father_occ | VARCHAR | Student father’s occupation | std_mother | VARCHAR | Student mother | std_mother_occ | VARCHAR | Student mother’s occupation | std_guardian | VARCHAR | Student guardian | std_guardian_occ | VARCHAR | Student guardian’s occupation | std_guardian_add | VARCHAR | Student guardian’s address | std_guardian_relation | VARCHAR | Student guardian’s relation | std_guardian_contact | VARCHAR | Student guardian’s contact number | Table 2. stores the family background information of the student. | | | | Table 3. stud_educ Table | | | | | | | | | Field Name | Data Type | Description | std_elem | VARCHAR | Student elementary school | std_elem_add | VARCHAR | Student elementary school address | std_elem_year | VARCHAR | Student elementary school year | std_hs | VARCHAR | Student high school | std_hs_add | VARCHAR | Student high school address | std_hs_year | VARCHAR | Student high school year | std_lsa | VARCHAR | Student last school attended | std_lsa_add | VARCHAR | Student last school attended address | std_lsa_year | VARCHAR | Student last school attended year | Table 3. stores the educational background information of the student.

| | | | | | | | | Table 4. req_flag Table | | | | | | Field Name | Data Type | Description | std_req_nso | VARCHAR | Student nso requirement | std_req_tor | VARCHAR | Student tor requirement | std_req_form138 | VARCHAR | Student form138 requirement | std_picture | VARCHAR | Student picture | std_section | VARCHAR | Student section | std_nonPK | VARCHAR | Student non Primary Key | section_flag | VARCHAR | Section flag | section_flag2 | VARCHAR | Section flag2 | Table 4. stores the requirement’s information of the enrollee and stores the flag that holds the number of users of the system.

Table 5. password table

Field Name | Data Type | Description | ID | VARCHAR | Username | pass | VARCHAR | password | cpass | VARCHAR | Confirm Password | q1 | VARCHAR | Question1 | a1 | VARCHAR | Answer1 | q2 | VARCHAR | Question2 | a2 | VARCHAR | Answer2 | tch_code | VARCHAR | Teacher code | user_type | VARCHAR | User type |

Table 5, the passwords table, is used for storing the user’s account.

Table 6. sec_sched table

Field Name | Data Type | Description | day | VARCHAR | Day | time | VARCHAR | Time | room | VARCHAR | Room | Item_number | VARCHAR | Item Number | flag | VARCHAR | Flag | tch_name | VARCHAR | Teacher Name | tch_code | VARCHAR | Teacher Code | subj_code | VARCHAR | Subject Code | sec_name | VARCHAR | Section Name |

Table 6, the sec_sched table, is used for storing schedule in each section.

Table 7. section table

Field Name | Data Type | Description | sec_name | VARCHAR | Section Name | item_number | VARCHAR | Item Number | year | VARCHAR | Year | tch_code | VARCHAR | Teacher Code |
Table 7, the section table, is used for storing the section.

Table 8. subject table

Field Name | Data Type | Description | subj_code | VARCHAR | Subject Code | subj_name | VARCHAR | Subject Name | for_year | VARCHAR | Current School Year | teacher_nme | VARCHAR | Teacher Name | tch_code | VARCHAR | Teacher Code |

Table 8, the subject table, is used for storing the subject

Table 9. teacher table

Field Name | Data type | Description | tch_code | VARCHAR | Teacher Code | tch_type | VARCHAR | Teacher Type | tch_ name | VARCHAR | Teacher Name | tch_add | VARCHAR | Teacher Address | tch_ dob | VARCHAR | Teacher Date of Birth | tch_age | VARCHAR | Teacher Age | tch_gender | VARCHAR | Teacher Gender | tch_degree | VARCHAR | Teacher Degree | tch_subj | VARCHAR | Teacher Subject | tch_dos | VARCHAR | Teacher Date of Service | tch_tin | VARCHAR | Teacher Tax Identification number | tch_prc | VARCHAR | Teacher Id Number | tch_pic | VARCHAR | Teacher Picture |

Table 9, the teacher table, is used for storing the information of the teacher.

Table 10. tch_sched table

Field Name | Data Type | Description | tch_code | VARCHAR | Teacher Code | tch_name | VARCHAR | Teacher Name | day | VARCHAR | Day | time | VARCHAR | Time | subject | VARCHAR | Subject | room | VARCHAR | Room | itm_no | VARCHAR | Item Number | flag | VARCHAR | Flag | sec_name | VARCHAR | Section Name | subj_code | VARCHAR | Subject Code |

Table 10, the tch_ched table, is used for storing the section of teachers.

Table 11. flags table

Field Name | Data Type | Description | name | VARCHAR | User Name | value | VARCHAR | Number Of User and Student |

`Table 11, the flags table, is used for counting the numbers of users and students in every year.

Table 12. sy_flag table

Field Name | Data Type | Description | name | VARCHAR | | value | VARCHAR | | std_code | VARCHAR | |

Table 12, the sy_flag table, is used for storing the school year

DATABASE RELATIONAL DIAGRAM (DRD)

Figure 7. Database Relational Diagram
Figure 7, shows the relationship among tables

NETWORK DIAGRAM

Figure 8 Network Diagram Figure 8 presents the network diagram of the system. It shows that the developed system is implemented in a Local Area Network where in the connections and designs are made using the Star Topology. It is composed of one server and three workstations plugged into a switch which provides the connection. The server which is intended for the system’s admin stored the database and served as a workstation. It should have at least Pentium IV processor and 128MB of RAM or higher. On the other hand, the workstations are intended for the registrars purely used for enrollment purposes only.

Development Phase. For the development of the system, the developers used the Microsoft Visual Studio Ultimate 2010 for coding and designing, and MySql for the database management. ODBCAD32 is also used to connect the system to MySQL.
Testing and Evaluation Phase. The developers used alpha and beta testing for the entire system. For the alpha testing, the developers tested the system. For the beta testing, they invited 10 faculty staff and discussed to them all the information they have to know to properly use the system. To evaluate the system performance, the respondents were given the evaluation instrument known as FURPS.

Implementation Phase. After the completion of the sytem, it will be implemented on Munting Ilog National High School Silang West Annex. The acting registrar which is the administrator, and the teachers of the said school will be trained to be familiar in using the sytem for them to experience all its features.

Maintenance Phase. The developers in this stage have the task of maintaining the reliability of the system. Developing additional features to support and improve the system will also be created.

OPERATIONAL AND TESTING PROCEDURES

The following procedures were conducted in order to operate and test the system.

1. The software requirements (Microsoft Visual Studio Ultimate 2010 and MySQL) were installed to the computers of Munting Ilog National High School Silang West Annex.

2. Upon installation of the software, users explored the system with the guidance of the developers.

3. Alpha and Beta testing were used in testing the entire system’s performance.

4. 10 faculty and staffs including the direct user of the system tested and evaluated the system for 2 days.

Evaluation Procedure In evaluating the system, the following procedures were used:

Preliminary Evaluation
The system was evaluated in accordance to the system developers’ and users’ requirements and specifications. The following questions were used to evaluate the system:
1. Is the system capable of recording and storing information?
2. Does the system produce reliable and accurate records?
3. Does the system automatically generate section of students?

Final Evaluation The system was evaluated in the span of 2 days. Alpha and Beta testing were used to evaluate the performance of the entire system. 10 faculty members including the administrator of the system tested and evaluated the system. FURPS was used as the evaluation instrument.
The system modifications and enhancements were based on the result of the evaluation. Comments and suggestion were taken into consideration for the improvement of the system.

Evaluation Instrument The evaluation instrument used was the FURPS model. This served as the basis in the terms of functionality, usability, reliability, performance and scalability of the system. Functionality. This criterion is for the evaluation of the features, security and capabilities of the system. Usability. This criterion considers the consistency and documentation of the system. Reliability. This is a criterion in evaluating the frequency of errors, the accuracy of the output and the ability to recover failures. Performance. This criterion is made to test the speed of processing, response time and the efficiency of the system. Scalability. This criterion is the basis on how easy to understand and maintain the good performance of the system.

Table 13. Scoring System NUMERICAL SCALE | INTERPRETATION | 5 | Excellent | 4 | Very Good | 3 | Good | 2 | Fair | 1 | Poor |

Table 13 shows the scoring system used in rating the performance of the system. Each criterion of the evaluation has a scale of 1 to 5; 5 being the highest and 1 as the lowest.

Statistical Treatment of Data

Table 14. Range of Mean Value RANGE OF MEAN VALUE | INTERPRETATION | 4.51-5.0 | Excellent | 3.51-4.50 | Very Good | 2.51-3.50 | Good | 1.51-2.50 | Fair | 1.0-1.50 | Poor |

Table 14 shows the range mean value and its equivalent interpretation. This table was used to determine the mean value of all the data gathered, tabulated and computed in the evaluation.

CHAPTER III

RESULTS AND DISCUSSIONS

This chapter is composed of Project Description, Project Structure, Screen Layouts and Project Evaluation.

PROJECT DESCRIPTION The developed system, Munting Ilog National High School Silang West Annex Enrollment System, is an information system, specifically a transaction system that is designed to provide a better enrollment services and to produce a high quality process outcome. It is capable of minimizing human error and avoiding data losses by providing a more reliable and speed up transaction. It also ensures precision and fast access to the students and teachers recorded information. The system consists of features committed to lessen the workload of the user such as generating automatically the sections of the students. The overture of a computerized enrollment system to Munting Ilog National High School Silang West Annex would bring about ease and convenience to its staff and students by replacing the manual procedures of a hassle free transactions preventing them to undergo the very long and time consuming manual enrollment processes done by preparing and setting a more organize enrollment procedures.

PROJECT STRUCTURE Munting Ilog National High High School Silang West Annex Enrollment System

Figure 9. System’s Project Structure Figure 9 shows the different functions and processes of Munting Ilog National High School Silang West Annex Enrollment System. For the Enrollment menu, the user can encode new student record, search student record, generate sections and change school year. Accessing the previous school year is also allowed but updating the records is no longer available. Teachers menu enables the users to encode new teachers’ records and search old records of them. Schedules menu allows encoding and searching of schedules for the teachers. Lastly, the Sections and Subjects menu is intended for creating sections and encoding and adding their schedules and subjects.

Figure 10. User’s Login Form (Select User) Figure 10, the User’s Login Form, provides the security to the system. It shows that the user should select a type of account before he/she can log in. This is to identify the type of access that the user can acquire.

Figure 11. User’s Login (Menu) Figure 11 shows the User’s Login (Menu). This allows the user to choose whether to create an account or to retrieve a forgotten password.

Figure 12. User’s Login (Create Account)
Figure 12, User’s Login (Create Account), provides the type of account that the user can create. This can be a registrar, adviser or teacher account.

Figure 13. Create User Account Figure 13, Create User Account shows the form that the user should sign up to have access to the system. To create an account, the user needs to provide a valid teacher’s code and unique username.

Figure 14. Lost Password
Figure 14, Lost Password shows the form where the user can retrieve his/her password. In order to retrieve password, the user need to provide a valid teacher’s code and User ID, if these requirements match, the security questions provided while creating the account will appear. Providing the right answers to these questions, the forgotten user’s password will be shown.

Figure 15. Admin Menu (Main Menu) Figure 15, Admin Menu (Main Menu) shows the main form for the admin account. The user has the options whether to work on enrollment, teachers, schedules or sections and subjects.

Figure 16. Admin Menu (Enrollment) Figure 16, Admin Menu (Enrollment), provides the options when the user chose to work on enrollment. This includes the encoding of new record, searching records and changing the year every end of the school year.

Figure 17. New Student Record Figure 17, New Student Record, shows the form for encoding new record of a student. All the information and requirements needed by the school to a student before he/she can enroll are completely provided in this form.

Figure 18. Input Grade Figure 18, Input Grade, shows the form that will be shown after clicking the grade textbox. Gen. Average and Entrance Examination grade are needed to calculate the grade in order to generate sections.

Figure 19. Search Record Figure 19, Search Record, show the form where the admin can search for the student’s record. The Administrator can search by name, student’s number, section or year level. The admin can also search for the records of the past school years by selecting a specific year. Updating record and printing registration form are also available in this form.

Figure 20. Change Search Year Figure 20, Change Search Year, shows the form where the admin can change the school year for searching student’s record from the previous school year.

Figure 21. Update Student’s Record Figure 21, Update Student’s Record, shows the form where the user can update student’s record in case of some changes. For the part of the old students, there is no need to encode again the student’s information.

Figure 22. Registration Form Figure 22, Registration Form, shows the registration form of the students that can be printed. This form contains the schedule of the student and may served as the proof of enrollment.

Figure 23. Admin Menu (Teachers) Figure 23, Admin Menu (Teachers), shows the options when the button teacher was clicked. These include encoding new teacher’s record and searching for old records.

Figure 24. New Teacher’s Record Figure 24, New Teacher’s Record, shows the form for encoding new record of a teacher. All the important information of the teacher and selecting the teacher’s type which are needed to be filled up are shown in this form.

Figure 25. Search Teacher’s Record Figure 25, Search Teacher’s Record, provides searching of teacher’s record by name or teacher’s number. This also allows updating of teacher’s record and clicking teacher’s advisory class.

Figure 26. Teacher’s Advisory Class Figure 26, Teacher’s Advisory Class, shows the form that will appear upon clicking the teacher’s advisory class. This form contains all the names of the students within that section that can be clicked to view their profile.

Figure 27. View Student’s Profile Figure 27, View Student’s Profile, shows the profile of the student upon clicking his/her name.

Figure 28. Update Teacher’s Record Figure 28, Update Teacher’s Record, shows the form for updating the teacher’s profile.

Figure 29. Admin Menu (Schedules) Figure 29, Admin Menu Schedule, shows the option upon clicking the button schedules.

Figure 30. Input Schedule Figure 30, Input Schedule. In this form, the administrator can input schedule for a certain section.

Figure 31. Admin Menu (Sections and Subjects) Figure 31, Admin Menu (Sections and Subjects), shows the options upon clicking the Sections and Subjects button. In this menu, the admin can create section, search for sections and add subjects.

Figure 32. Create Sections
Figure 32, Create Sections, shows the form where the admin can create sections. In order to create a section, the admin should fill up the following textboxes.

Figure 33. Search Section
Figure 33, Search Section, shows the form for searching section. The admin needs to select the name of the section in the combo box and the names of the students enrolled in that section will appear in the flexgrid.

Figure 34. Add Subjects Figure 34, Add Subjects, shows the form for adding subjects. In adding subjects, the admin should fill up the required information needed for adding a subject.

Figure 35. Registrar’s Menu Figure 35, Registrar’s Menu, shows the main form for the Registrar. The Registrar can only add new student’s record and search for old student’s record.

Figure 36. Teacher’s Menu Figure 36, Teacher’s Menu, shows the teacher main form. The teacher can view his/her profile and schedules which can be printed.

Project Evaluation

Table 15. Evaluation Result INDICATORS | MEAN | DESCRIPTIVE RATING | A. Functionality | 4.5 | Excellent | Functions required for the system are implemented | | | Functional accuracy is provided | | | Functions meet specifications | | | Ease of connecting with other systems is provided | | | B. Usability | 4.6 | Excellent | Easy to operate | | | Easy to remember | | | Allows easy operation management | | | C. Reliability | 4.2 | Very Good | Conformance to desired output | | | Absence of failure | | | Accuracy in performance | | | D. Performance | 4.3 | Very Good | Speed | | | Efficiency | | | E. Supportability | 4.5 | Excellent | Ease of isolating and transferring significant components | | | Serviceability | | |

Table 12 shows the evaluation result evaluated by the 10 faculty staff of Munting Ilog National High School Silang West Annex. They rated the system based on its Functionality, Usability, Reliability, Performance and Scalability.
In order to prove that the system is functional, the features set should be implemented, the functions’ accuracy and capabilities were also measured, and it also provide substantial security. With all the requisite system as the basis of the evaluators, half of them gave a rating of 5; and the other half gave 4. Given these sub-criteria, the system over all functionality got an average score of 4.5, which means that the system is “Excellent”.
The system’s usability is concerned with characteristics such as aesthetics and consistency in the user interface. It garnered a score of 5 from the 6 evaluators; a score of 4 from remaining 4 evaluators. After summing all the scores given, the system got an average rating of 4.6 which means “Excellent” for the system’s over all usability.
In this case, the quality requirements are established on the basis of the Performance characteristic. The ability of a system to perform its required functions under stated conditions for a specified period of time or the resistance to a failure of a system should be evaluated. 1 of the evaluators rated the system in the score of 3; 3 of them gave 5; and the remaining 6 of them gave a score of 4. These resulted to an average of 4.2, with a verbal interpretation of “Very Good”.
The system’s performance, is concerned if the system is easy to install, provide a flexible environment, and it allow easy replacement with other software. 3 of the evaluators rated 5 for the performance of the system and 7 of them gave a score of 4. These resulted to an average of 4.3 that has an equivalent of “Very Good”.
For the system’s supportability; ease of isolating and transferring significant components, testability, adaptability, maintainability and compatibility of the system were evaluated. With all these requisite of the system, 6 of the evaluators gave a score of 5 and 4 of them gave 4. This resulted with an average of 4.5, with a verbal interpretation of “Excellent.”
The system got an overall mean of 4.42 which is equivalent to “Very Good.” According to the system evaluation, the evaluators found the system functional, usable, reliable, performing well in terms of speed, and manageable.

CHAPTER IV

SUMMARY, CONCLUSIONS, RECOMMENDATIONS This chapter presents the summary, conclusions, and recommendations.

SUMMARY
Munting Ilog National High School Silang West Annex Enrollment System was developed exclusively for Munting Ilog National High School Silang West Annex to aid the difficulties and problems which they encountered when using the manual process. It is designed specifically to provide a fast-paced computerized enrollment system while producing a more reliable and dependable information for both students and teachers, done by lessening human errors and avoiding data losses. This system is implemented in a network environment. It has three direct users which have different level of accessibility. It can automatically generate sections but cannot generate schedules automatically. For the development of the system, the developers made and followed the context flow diagram, data flow diagram, and database design as guides. They used the System Development Life Cycle (SDLC) to meet the general and specific objectives of the study. For the evaluation, the system underwent two procedures which were the preliminary and final procedures. The developers and their system’s adviser tested the system for the preliminary testing. And for the final testing, they invited 10 staff of Munting Ilog National High School Silang West Annex to test and evaluate the system using the FURPS model. For the evaluation result, the system got an overall mean of 4.42 with the descriptive rating of “very good”. This proves that the system is acceptable based on the gathered data and summarize evaluation showing that evaluators found the system functional and usable.
CONCLUSIONS
Based from the result of the evaluation and objectives, major conclusions are made: 1. The developers have successfully developed a computerized enrollment system that provides a speed up transactions while ensuring to the users that the process outcome is in high quality, accurate, dependable and reliable. 2. The system is easy to learn, understand and operate because of it’s being user-friendly. 3. The system created is usable, maintainable and expandable.

RECOMMENDATIONS Based from the comments, suggestions, and recommendations gathered from the final evaluation of the system, the developers recommend the following to the future researchers: 1) Future researchers may develop an enrollment system that automatically generates schedules for the students. 2) Future researchers may incorporate the use of internet while working in the network of the system. 3) Future researchers may enhance the data retrieval process of the system in case of power failure.