Enrollment System Essay Example

Enrollment System Essay Example Enrollment System Essay Enrollment System Essay 1 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 esulted 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 s ystem. This system is capable of providing a 2 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 uman error and avoid data losses. 3. To evaluate performance of the proposed system. 3 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’ infor mation 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 Users 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. 4 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, ommunication 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 5 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. 6 CONCEPTUAL MODEL OF THE SYSTEM INPUT PROCESS OUTPUT > SSS 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 System Analysis -Requirement Analysis -Requirement Definition System Design -Contex Flow Diagram System Development -System Developmen t Life Cycle System Testing -Alpha -Beta Munting Ilog National High School West Annex Enrollment System . 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 Pe ntium IV processor. b. Must have at least 128MB of RAM or higher Client Requirements EVALUATION 7 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 re 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 th e 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. 8 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 n attaining the project objectives. Figure 2. System Context Flow Diagrams Registra tion Form 9 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’ informat ion 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. 10 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 ystem 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 3. System Development Life Cycle 11 12 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 he 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 s ource 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. 13 14 Figure 5 shows how data were processed in the system for the registrar cenario. 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. 15 16 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 rinted 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 t able and report will be issued upon updating the account. 17 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 td_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 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 td_mother VARCHAR Student mother std_mother_occ VARCHAR Student mother’s occupation std_guardian VARCHAR Student guardian Table1, the Student’s Personal Information Table, is used for storing the personal information of the student. 18 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 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 td_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 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. tores the requirement’s information of the enrollee and stores the flag that holds the number of users of the system. Table 2. stores the family background information of the student. Table 3. stud_educ Table Table 3. stores the educational background information of the student. Table 4. req_flag Table 19 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 20 year VARCHAR Year tch_code VARCHAR Teacher Code Table 8. subject table 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 7, the section table, is used for storing the section. Field Name Data Type Description subj_code VARCHAR Subject Code subj_name VARCHAR Subject Name or_year VARCHAR Current School Year teacher_nme VARCHAR Teacher Name tch_code VARCHAR Teacher Code 21 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 roo m 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 alue 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 22 Table 12, the sy_flag table, is used for storing the school year DATABASE RELATIONAL DIAGRAM (DRD) 23 Figure 7. Database Relational Diagram Figure 7, shows the relationship among tables NETWORK DIAGRAM 24 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 onnections and designs are made using the Star Topology. It is composed of one server and three workstations pl ugged 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 or 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 25 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 n 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. 26 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 he evaluation. Comments and suggestion were taken into consideration for the improvement of the system. Evaluation Instrument 27 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 ccuracy 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 28 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 29 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 30 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 enu, 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. Munting Ilog National High High School Silang West Annex Enrollment System 31 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. 32 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 33 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. 34 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 e/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. 35 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. 36 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 e printed. This form contains the schedule of the student and may served as the proof of enrollment. 37 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. 38 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. 39 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. 40 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. 41 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. 42 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. 43 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. 44 Project Evaluation Table 15. Evaluation Result 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 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 GoodSpeed Efficiency E. Supportability 4. 5 Excellent Ease of isolating and transferring significant components Serviceability 45 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. 46 CHAPTER IV SUMMARY, CONCLUSIONS, RECOMMENDATIONS This chapter presents the summary, conclusions, and recommendations. 47 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 he 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 t he 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 ith 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 48 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 ser-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.