Documentation Finale

A COMPUTERIZED ENROLLMENT SYSTEM

WITH GRADING AND SECTIONING FOR VGNS

A Case Study

Submitted to the

Department of Information Systems

Faculty of Engineering

University of Santo Tomas

In Partial Fulfillment

Of the Requirements of the Course

System Analysis and Design

Bacatan, Armando Jr. T.

Cauyan, Ian Christopher B.

Co, Marione Miguel T.

Domingo, Joshvin Matthew R.

March 15, 2011

Table of Contents

The Project............................................................................................................................................ 1

A. Introduction...........................................................................................................................................1

B. Objectives..............................................................................................................................................2

C. Scope and Boundary..............................................................................................................................3

D. Feasibility Studies..................................................................................................................................3

E. Planning Activities..................................................................................................................................7

F. Composition of the Team.......................................................................................................................8

G. Responsibility Area of Each Member...................................................................................................11

H. Schedule of Activities..........................................................................................................................11

i. Work Breakdown Structure..............................................................................................................11

ii. Gantt Chart / Milestone...................................................................................................................14

iii. PERT Diagram.................................................................................................................................16

The Company....................................................................................................................................... 18

A. Background and History......................................................................................................................18

B. Organizational Chart............................................................................................................................21

C. Contact Person/s, their position/designation and their contact numbers/addresses..........................23

The Present System............................................................................................................................. 24

A. Detailed Description of the System.....................................................................................................24

B. Statement of the Problem...................................................................................................................25

C. Objectives of the System.....................................................................................................................25

i. General Objectives...........................................................................................................................25

ii. Specific Objectives...........................................................................................................................26

D. Scope and Limitation of the System....................................................................................................26

Analysis of the Current System............................................................................................................. 27

A. Data Gathering Techniques Used........................................................................................................27

i. Sources of Information.....................................................................................................................27

ii. Instruments Used in the Survey, Sample Questionnaires, Interview Questions, Communication Letters,

Documentation of the Observation, etc..................................................................................................27

B. Consolidated Tables, Findings, Analysis of Information Gathered, Summary of Information, etc.......28

C. Business Activities................................................................................................................................29

D. Data Flow Diagram..............................................................................................................................29

E. Use Case Diagram................................................................................................................................35

The Proposed System........................................................................................................................... 36

A. Comparison of the Present and Proposed System in Terms of............................................................36

i. Objectives.........................................................................................................................................37

ii. Advantages and Disadvantages.......................................................................................................37

iii. Technical, Operational, and Economic Justification........................................................................38

B. Development Cost...............................................................................................................................38

C. Technical Specifications.......................................................................................................................40

i. Proposed Data Flow Diagrams..........................................................................................................40

a. Logical Data Flow Diagram.........................................................................................................41

ii. Process Specifications......................................................................................................................46

iii. Data Dictionary...............................................................................................................................63

iv. Database Specifications..................................................................................................................93

a. Enhanced – Entity Relationship Diagram....................................................................................93

a. Normalization of Tables.............................................................................................................94

a. Database Structure....................................................................................................................95

v. Input/Output Forms........................................................................................................................96

vi. Screen Designs................................................................................................................................99

vii. Object-Oriented Systems Analysis and Design Using UML.........................................................102

Summary and Conclusions.................................................................................................................. 104

A. Summary of Changes, and Improvements.........................................................................................104

B. Constraints of the New System..........................................................................................................105

Activities in the Next Stage of Development.......................................................................................105

A. Testing Plans......................................................................................................................................105

B. Maintenance Plans............................................................................................................................106

C. Security Plans.....................................................................................................................................107

Appendices........................................................................................................................................ 107

A. Start-up Procedure............................................................................................................................108

i. Minimum Hardware and Software Specifications...........................................................................108

ii. Installation Procedure...................................................................................................................109

B. Initial Entry / Access...........................................................................................................................109

i. Levels of Users................................................................................................................................110

ii. File/s to Open................................................................................................................................111

iii. Default Password (for each level of user) / How to Change Password.........................................111

C. List of Error Messages........................................................................................................................111

C. Other Messages.................................................................................................................................112

Curriculum Vitae of Developers..........................................................................................................113

List of Tables

Table 1 Net Beans.................................................................................................................................. 1

Table 2 MySQL....................................................................................................................................... 7

Table 3 Gantt Chart.............................................................................................................................. 15

Table 4 PERT Table............................................................................................................................... 17

Table 5 Development Cost................................................................................................................... 39

Table 6 Decision Table......................................................................................................................... 46

Table 7 Structured English.................................................................................................................... 47

Table 8 Data Flow Description.............................................................................................................. 67

Table 9 Element Description Form........................................................................................................ 75

Table 10 Data Store Description........................................................................................................... 90

Table 11 Input / Output Forms............................................................................................................. 96

Chapter 1 l The Project

A. Introduction

Virgen de Guadalupe de Novaliches School is one of those institutions that

started out small and is now growing in terms of structure and population. Structures

can be easily built with the right amount of money but handling 400 or more student

information can’t be solved by just hard cash. What VGNS needs is a system that can

manage enrollment, grading and scheduling of students along with storing of student

records and transactions.

With the fast evolution of technology, it is now easier to replace manual systems

with automated ones. With just two computers, the manual system that the VGNS has

depended upon can be upgraded to an automated system that can reduce the workload

from various personnel. The system will consist of a program for the updating the

database and another program for viewing and editing of student records. The

proponents have decided to implement Java programming language as the front end

and mySQL database software as the backend of the system.

B. Objectives

The general objective of this study is to provide VGNS an automated enrollment

system that will help the school especially the Registrar with the different transactions

involved in the system and minimize the problems encountered in the school’s current

system. This will allow them to provide their customer the utmost satisfaction and

convenience and will help the school be organized and accurate since they handle

numerous record and transactions.

The specific objective of this study is to enhance the analysis, self-management

skills of the proponents as this study needs to be done in series of activities. This study

also aims to familiarize the school with the use of database that can be a key for the

school’s innovation in the future.

C. Scope and Boundary

The Scope of this project is VGNS’s current Enrollment system and the preferred

system to be best applied to it including different areas of the current system that needs

to be resolved in order to make a better system. This project takes account of the

activities done and information evaluated in order to achieve its objectives. It also

includes the expected expenses, length of the project making process and whether the

project is feasible to be installed into company.

This project is limited to the Enrollment system of VGNS including the Grading

system as requested by the company. The proponents will be focusing on the problems

evaluated using some data gathering methods. As for the enrollment system, the

project will not cover the summer enrichment program for the population covered by

this program is too small for a database as well as for the transactions involved. Any

information beyond the system stated will not be covered by the team.

D. Feasibility Studies

These studies will tell the team and the company if this project is possible for

completion whether they have the capacity to provide for the resources required for the

project to be installed. This study will save the company and the team’s time and

money by screening out the projects unrelated to the company’s problem, resources

that already exist in the company and projects that the company will not merit.

i. Technical Feasibility

This section will serve as a guide for the company to know whether they have

the technical resources needed for the project to be implemented. The Directress and

the Registrar are willing to provide the proponents the information and forms that the

proponents needed to conduct the study, they are also willing to be interviewed by the

proponents given that it is scheduled ahead of time.

As for the software to be used, the proponents recommend the use of MySQL as

a back-end application which will serve as the database container and Netbeans as a

front-end application. Both of which are open source and free of charged so the school

will not have any problem regarding this except for the teaching of the user. The

requirements for the recommended software are shown in Table 1 and 2.

The study to be implemented successfully requires the school two sets of

computers, one to be used by the registrar for the Enrollment system and the other to

be used for the grading. The school doesn’t have an available computer in the present

so the proponents will require the school to buy two computers capable of storing large

files and support the requirements shown in Table 1 and 2. Other needed resources are

already available in the school such as fax printer and school supplies.

ii. Economic Feasibility

This section estimates the cost of expenses needed to fully implement, this study

will also tell the school if the school has the budget to implement such. Table 3 provides

an outline of the expenses.

iii. Operational Feasibility

Operational feasibility tells the school whether the system will operate when it is

implemented and if the system will be used.

Since the Registrar is the person most involved in the Enrollment system of the

school and the Registrar also serves as the Cashier in the Assessment and Payment area

of the system, it is safe to assume that even though the proposed system is not very

technical the Registrar still needs to be familiarized with it and allow the proponents to

teach the Registrar of the different functions involved in the system (Proposed). The

Directress and the Registrar both agreed to conduct training for the Registrar once the

study is implemented. This will be free of charged for familiarization with an automated

system is included in the study’s objective.

E. Planning Activities

The team used two data gathering methods to be able to maximize the accuracy

of evaluation of information. First is the interview of the Registrar, the Registrar

handles the registration, assessment and the payment, including the transactions and

information concerning the system. Every dilemma that exists in the current Enrollment

system is supposed to be of known by the Registrar. Next is the reading of school

handbook, this will provide the team a brief explanation of the current system of the

Enrollment system of VGNS and what processes are involved in the system. This will

also support the documentation of the project especially for chapter 1 and 2.

The information gathered may provide a direct problem existing in the current

system or certain evaluations may be needed to further understand the problem.

Evaluated problem will reflect on the project’s objectives and the team will try and

analyze the problem. This study will provide a solution that may exist in the proposed

system or will just be suggested to the company. As for the system, feasibility studies

and data diagrams will be made to provide the company a brief summary of the

expenses and resources needed. And also this will provide the team an outline of how

the system works.

Based from the company’s needs and requests the team will then brainstorm on

the functions needed in the system and how each function will be put into the system so

that it will be a user-friendly, secured and effective system. A prototype of the system

will be given to the company for them to know whether their needs have been met

correctly by the team or if they have any alterations or additional functions to the

proposed system. After any modifications made into proposed system it will be

presented and submitted to the panel considered as final exam as a part of a

requirement in Im203, once the project is complete the company can now install and

implement the proposed system.

F. Composition of the team

The team comprises of four members and will be divided to three Main jobs

where each of the members will choose what will best suit their skills. Because the

team is composed only of four members, the team then is required to choose one to

two jobs for the project to meet its target date of finalization. The three main jobs

would be as follows:

The System Analyst whose responsibility concerns most of the decision making

involved in the project. Evaluation of information as well as making the feasibility

studies and data diagrams which to be used by the programmer will be handled by the

analyst. The system analyst will manage the documentation of the project, and evaluate

the problems, objectives, and solutions to be considered in the project.

The Programmer will be responsible for translating the data diagrams into an

actual program. Together with the System Analyst, the programmer will decide on the

entities, relationship and the processes involved in the proposed system as well as the

look and feel of the system. The programmer will also provide a prototype of the

proposed system and will modify any modifications as suggested by the company or as

decided by the system analyst.

The Researcher will serve as the bridge of the proponents with the company

from asking for permission to conduct the study up to the implementation of the

project. Also the researcher is in-charge of conducting the interview and surveys to

company and of gathering and compiling of the information.

G. Responsibility Areas of each member

Bacatan, Armando Jr. T. - System analyst

Chapter 1, 3, 4, 5

Cauyan, Ian Christopher B. - Researcher

Chapter 1, 4, 6

Co, Marione Miguel T. - Researcher

Chapter 1, 2

Domingo, Joshvin Matthew - Programmer

Chapter 2, 3, 5

H. Schedule of Activities

This section will help the proponents keep track of the step by step activities

needed for the study to be conducted and estimate the length of making this project.

a. Work Breakdown Schedule

The work breakdown schedule is a key project activity that organizes the team’s

work into manageable sections. It defines the scope into manageable chunks that

the project team can understand, as each level of the work breakdown structure

provides further definition and detail. Figure 1 briefly discusses the activities that

need to be done and what activity should come first before the other. As the figure

illustrates that there are three main categories namely Project Management, System

Development and Testing & Implementation. These categories are further defined

by their subcategories.

b. Gantt Chart

This chart is a graphical representation used to determine the timeline of the

scheduled activities of the proponents. Gantt chart allows the proponents to see

immediately what should have been achieved at any point in time. The Figure 2 is

divided into 3 main phase just like Figure 1, but Figure 2 shows specific date of when

a certain activity must be conducted.

Chapter 2 l The Company

A. Background and History

In the year 2002, the founder of Virgen de Guadalupe de Novaliches School came

to realization that he needs to respond to the clamor of multitude of average families

who can’t send their children to big private school. Out of love for the Filipino children

he dared to start from a secondary school with a preschool. On the 12th of June located

at the Left Oval 41 Sampaguita Street Maligaya Park Subdivision, Novaliches, Quezon

City the school had opened and started its operation.

Starting with only 54 students, the founder as the director, 7 eligible teachers

and a principal the school strived for academic excellence through the efficient and

effective teachers to cope up with the quality education expected to center with the

teaching of the church in light of the Gospel. On its second year of existence the

enrollees have increased by almost two hundred students and primary school were

added to the curriculum. And on the next year of its operation the students have

increased from 200 enrollees up to 300 enrollees. Each year the number of enrollees

increased and in gratitude for all the blessings showered to this school they make it a

habit to always recite the rosary before classes start every morning.

B. Organizational Chart

The Organizational Chart presents the positions in the company and guides readers to

the hierarchy of the company which functions as the following;

Director - the chief administrator of the school

Principal - the chief administrator of the grade school and secondary school. He is

directly responsible to the Academic affairs for the successful management of the

school.

Assistant principal - the one who assists the principal in managing the grade school and

high school department and takes over the responsibilities of the Principal whenever

the Principal is absent.

Prefect of Academic Affairs – is the one responsible for all matters pertaining to the

planning, development, implementation and enrichment of the academic program.

Prefect of Student Affairs – is the one responsible for the placement, updating of

activities and discipline of the students and also investigates on all the cases regarding

student violations and acts to them in accordance with the prescribed policies and

procedures.

Prefect of Activities - the one responsible for the planning, coordination,

implementation, supervision and evaluation of the activity program.

Grade level/HS level coordinator - the one responsible for the implementation of

school policies in each grade level and high school level.

Head Councilor – is the one who is responsible in planning, implementation and

evaluation of the operation of school guidance Services.

School Librarian – is the one responsible in the operation of the library.

School Registrar – is the one who facilitates student records and the one responsible for

the whole operation of the enrollment.

Class Adviser – is the teacher responsible for the students in the homeroom

organization.

Figure 1. Organizational Chart

C. Contact Persons

Contact Person Name: Maria Yet Malicse

Position/Designation: School Registrar/Cashier

Department name: Registrar’s Office

Contact number: 4185263

Contact Person Name: Mosdie Mary Abid

Position/Designation: Teacher/Enrollment aid

Department name: Teaching Department

Contact Number: 4185263

Mobile: 09308452518

Chapter 3 l The Present System

A. Detailed Description of the System

I. REGISTRATION

Inquiries about the procedure of the enrollment are done through phone with

telephone number 4185263 or through asking directly in person with address Left Oval

41 Sampaguita Street Maligaya Park Subdivision, Novaliches, Quezon City.

Any student who wants to enroll for a certain school year must complete the

registration within the enrollment period months March onwards to school opening.

Any student who fails to register within the period will be considered a late enrollee.

a) New Student

Before a student is able to register he/she must submit to the registrar’s office

the following documents as a requirement for registration. These documents will

also determine the student’s eligibility as an enrollee for the specific grade level

he/she is enrolling upon:

1.) Form 137

2.) Certificate of Good Moral Character

3.) Photocopy copy of his/her Birth certificate

The following documents are now then submitted to the registrar’s office. The

registrar’s office compiles these documents and stores them in a metal drawer

for future use.

Students having a failure not more than 3 units will have to take the subjects he

failed during summer enrichment program (March to May) only. Students who

failed to take the subjects during summer enrichment program need to take the

subject next summer program.

After submitting the requirement for registration the school registrar then gives

an Accounting form, the student then now needs to fill-up the Accounting Form

which serves as the school’s copy of information about the student.

The student then needs to submit the accomplished form to the school registrar.

The school registrar then now checks for irregularities (erasures, unclear

characters, etc.) in the accomplished accounting form.

Irregularities in the Accounting form are now evaluated by the school registrar.

Complete revision or partial revision of the Accounting Form will be advised

depending on the school registrar.

Incoming grade 1 students with approved Accounting forms are subsequently

qualified to take the entrance exam to test the knowledge of students if he/she

is able to qualify as a first grader in the VGNS which is only conducted within the

school premise.

Entrance exam is divided to different parts which corresponds to subjects

essential for grade 1 students.

Entrance exam results will be given minutes after the exam was taken.

Students who passed the entrance exam will then proceed to Assessment and

Payment. While students who failed shall be evaluated to either take the subject

he/she failed during the summer enrichment program of the school or the

student is advised to transfer school

b) Old Student

Old Student who has failed on a certain subject is assumed to have already

completed the summer enrichment program before the registration.

Old students are required to submit their report cards upon enrollment for

validation of the student’s eligibility to register.

Upon submission of the report card to the registrar’s office, the student needs to

fill up the accounting form given by the school registrar.

Accomplished accounting form must be submitted to the school registrar.

Upon submission of the accounting form the school registrar then checks for

irregularities (erasures, unclear characters, etc.) in the accomplished accounting

form.

Irregularities in the Accounting form are now evaluated by the school registrar.

Complete revision or partial revision of the Accounting Form will be advised

depending on the school registrar.

Students with approved accounting forms can subsequently proceed to

Assessment and Payment.

II. ASSESSMENT AND PAYMENT

Students need to present the accounting form approved by the registrar to the

cashier to assess fees corresponding to the student’s choice of payment option.

Balance incurred by the student from the previous years he/she attended VGNS

are added to the fees he/she needs to pay.

Payment option are as follows:

i. Full – comprise of registration fee, miscellaneous fees, full amount

of balance and a full amount of the tuition fee.

ii. Semestral - comprised of registration, full amount of balance,

miscellaneous and half amount of the tuition fee.

iii. Quarterly - comprised of registration, miscellaneous, full amount

of balance and one fourth amount of the tuition fee.

iv. Monthly- comprised of registration, miscellaneous, full amount of

balance and one-tenth amount of the tuition fee.

The payment method only accepted by the school is through cash basis only any

transactions not in a cash basis should be handled by the administration

(promissory note/deposit through bank).

Students with promissory note will be qualified as a student for the whole school

year provided that he/she will complete the payment before the end of the

school year.

Upon payment of fees, the Registrar calculates the fees the student should pay

(payment option). The Registrar receives payment from the student then notes

how much does the student have paid and compiles the accounting form

together with other accounting forms for future reference.

The Registrar releases a receipt that will be given to the student as a proof of

payment.

III. GRADING

Every grading period, the teachers prepare the grading records for the

students in the subject class he/she handles. Students’ performances are

monitored only by the attending teacher in which he/she records grades

incurred by the students.

Grades that are encoded by the teacher came from the following activities

and tests done by the students: Quizzes, Unit Tests, Projects, Homework,

Behavior, Attendance, and Periodical Test.

Computations for the subject average grade of the students are done by the

subject teachers. Final computed subject grades are forwarded to class

advisers’ for issuance of report cards and to the school registrar for storing of

record grades of the student.

B. Statement of the Problem

The proponents have found problems with regard to the current system of the

school but one problem has been identified as the general problem which is the

tendency of complete file dispossession. Student files and other documents might be

completely lost in case of any accidents like school fire, burglary, earthquake, flood, etc.

because of the nature of the system in storing files, restoration of files is impossible.

There are no means of backing up student information because the school does not

duplicate the accounting forms accomplished by the student. Since it is a school,

student files including grades are the most important files losing such files will be a big

problem for the school.

One specific problem of the current system as identified by the proponents is the

loss of data credibility. Data encoding is done by pen and paper and understandability

depends on the legibility of the handwriting of the writer. Another specific problem

identified is the extravagant resource allocation. The current system has a propensity to

use/waste too much paper during registration especially when complete revision of

accounting form is advised. The school registrar pointed out that during enrollment

when the student lost his/her report card. The registrar needs to get the student record

for the last school year in which he/she was enrolled to check if there are any failed

subjects incurred. And during payment the school registrar tend to look for all

accounting forms of the student to compute for the outstanding balance of the student.

C. Scope and Limitations of the System

The current system is limited to the enrollment of a student which includes

registration, assessment and payment of fees.

The registration process consists of validation of requirements and forms, adding

of student records based from the accounting form. Where the old and new student

both have to pass accounting forms each and every time the register as an enrollee.

The current assessment comprises of students fees which may vary upon the

student’s grade level and balance which will be used to produce to pay of the

student dependent on the payment method.

In the payment section of the current system from the assessed fees and

incurred balance the total payment of the student is calculated.

The current system is also limited to grading system which include only of the

quarterly grades of the student and their final grade. Grades from recitation,

quizzes, exams and attendance will not be handled instead it will be computed by

the teachers as for to calculate every quarterly grades.

Chapter 4 l Analysis of the Current System

A. Data Gathering Techniques Used

i. Sources of Information

a. Interviews which were conducted on the person involved in the

Enrollment system to have a better understanding on how the current

system works.

b. Communication letters which were used by the proponents for request

for permission to implement the study with the approval of the

Directress.

c. Other Sources of information are school documents and forms

provided by the school which contains information necessary for

generating school reports.

ii. Instruments Used in the Survey, Sample Questionnaires, Interview Questions,

Communication Letters, Documentation of the Observation

The following personnel are vital to how the system operates in which

the proponents have selected to ask questions about how the current system

works.

1. School Registrar

Provided an overview of the system

Questions are imposed by asking general to specific questions

2. Teacher aiding enrollment every year

Explained further details about the present system.

Questions are raised from specific questions going to a more

general one.

Aside from the asking the registrar about how the current system works

the proponents have also prepared interview question for the Registrar, as

attached in Appendix A including the transcript of records in Appendix B, which

has been written for further documentation and understanding of the system.

Communication letters which was used in conducting the project is also

attached in Appendix C. This is the letter of request for conducting the study in

Virgen de Guadalupe de Novaliches School.

B. Consolidated Tables, Findings, Analysis of Information Gathered, Summary of

Information

a. Summary of Information

Information gathered through school documents is insufficient for the

handbook only gives the history of the school; however in the interview

the proponents found out that the student files are not secured from

unauthorized personnel, data loss and inconsistency for the it is manual

and only placed on a cabinet.

C. Business Activities

Registration

Student submits necessary documents such as report cards and for New

students, form 137, birth certificate, and a certificate good moral character

Submit the accomplished Accounting form to the school registrar

The school registrar encodes student information as a student for the current

year.

Assessment

The Registrar assess fees based on the payment type, grade level and

balance

Payment

Fees assessed added with the balance to calculate the student’s to pay.

Upon payment of the student, the Registrar releases a receipt as a proof of

payment done by the student.

Grading

The subject teacher records grades

The teacher produces a transmuted grade to be viewed by the student and

the class adviser of the student.

Creation of report cards is done by the class adviser to be distributed on the

date of releasing of report cards.

D. Data Flow Diagram

E. Use Case

Chapter 5 l The Proposed System

A. Comparison of the Present and Proposed System in terms of

i. Objectives

The proposed system’s general objective is to provide Virgen de Guadalupe de

Novaliches School a computerized Enrollment, Grading and Sectioning system. This

is broader but at the same time more convenient compare to general objective of

the current system. As for the specific objectives, the proposed system has the

same objectives as the present system but will me using a server that will serve as

the storage of the records the registered students, the student’s personal

information and the student’s balance if any. This will be more secured and with

ease of use as compare to the present system’s logbook and cabinet. Getting,

updating and deleting information would also be easier for the proposed system and

it will not consume a large amount of space as used by the current system.

ii. Advantages and Disadvantages

As for the advantages of the proposed system, the system will make the job of

the Registrar easier and more accurate as for the recording of the student’s balance.

Instead of making use of a logbook the proposed system will be using an automated

storage that will provide proofs such as the previous transactions of the enrollees.

With particular to the storage, the proposed system will be less space consuming

and more secured for the storage will be automated and will be accessible only by

authorized personnel. In the part of the enrollee, the registration process will be

faster especially if the enrollee is an old student for the student doesn’t need to fill-

up the form anymore instead the Registrar will only require the student’s student

number. Moreover teachers will be able to generate reports such as list of students

easily.

B. Development Cost

The purpose of this development cost is to tell if the company has the budget to

buy this kind of system based on how much will be the expenses based on Table

below. This table includes the quantity of the item, price and total expanse.

Table 3 Economic Feasibility

Equipment Quantity Price TotalComputer 2 8,000 16,000Software and Hardware Rights ---- ---- ----Office SuppliesCoupon bond (Forms) 2 packs 250 500Fax Papers (Reports, Statement of Accounts) 10 rolls 55 550 Fax Printer Ink 1 refill 1000 1000Miscellaneous costElectricity 1500 1500

19,500

C. Technical Specifications

I. Proposed Data Flow Diagrams

a. Logical DFD

b. Physical Diagram

1

Student passed all the requirements

Student did not passed all the requirements

2

5

3

4

Add student record

Update student record

Student is New

Student is Old

Register a student

Are the requirements complete?

Yes No

Is the student new?

Yes No Return documents

Add student Update to enrolleeRecord student record

RulesConditions and Actions 1 2 3Student is New Y - NStudent is Old N - YStudent passed all the requirements Y N YAdd student record XUpdate student record XReturn documents X

II. Process Specification

Figure 9. Structured English

Return documents

Figure 10.1 Decision table for registering a student

Figure 10.2 Decision tree for registering a student

Figure 10.3 Nassi-Shneiderman diagram for registering a student.

Process Specification Form

Number: 3.1Name: Get Student RecordDescription: Use student number to get student record from student master.

Input Data FlowStudent Number

Output Data FlowStudent Information

Type of Process Subprogram/Function Name

Process Logic:

BEGIN IF student number is valid GET record ELSE IF student number is invalidEND IF

Refer to: Name:

Comments:

Online Batch Manual

Structured English Decision Table Decision Tree

Figure 9.1. Structured EnglishProcess Specification Form

Number: 3.2Name: View Student InformationDescription: View old student information from the screen.

Input Data FlowStudent Number

Output Data FlowStudent Information


Process Logic:

BEGIN IF student number is valid GET record DISPLAY student informationEND IF

Refer to: Name:

Comments:

Online Batch Manual



Number: 3.3Name: Update Grade LevelDescription: Update previous grade level of the student from the student record.

Input Data FlowGrade level

Output Data FlowStudent record


Process Logic:

BEGIN IF student number is valid AND requirements are complete UPDATE grade levelEND IF

Refer to: Name:

Comments:

Online Batch Manual



Number: 3.4Name: Update Student InformationDescription: Update student information of student if previous record is un-updated.

Input Data FlowStudent information

Output Data FlowStudent record


Process Logic:

BEGIN IF student number is valid AND requirements are complete UPDATE student informationEND IF

Refer to: Name:

Comments:

Online Batch Manual



Number: 4.1Name: Get feesDescription: Get fees from accounting form to decide what payment, either Full, Semestral, Monthly, Quarterly or Installment.

Input Data FlowPayment type

Output Data FlowAssessed fee


Process Logic:

BEGIN IF payment type is full GET full fees IF payment type is semestral GET semestral fees IF payment type is monthly GET monthly fees IF payment type is quarterly GET quarterly fees IF payment type is installment GET installment feesEND IF

Refer to: Name:

Comments:

Online Batch Manual



Number: 4.2Name: Get balanceDescription: Get previous balance of the student if any.

Input Data FlowStudent number

Output Data FlowBalance


Process Logic:

BEGIN IF student number has previous balance GET balanceEND IF

Refer to: Name:

Comments:

Online Batch Manual



Number: 4.3Name: Calculate total paymentDescription: Using assessed fees and balance calculate total payment to be paid by student.

Input Data FlowAssessed feeBalance

Output Data FlowCalculated to pay


Process Logic:

BEGIN IF balance is NOT EQUAL to zero CALCULATE sum of assessed fee and balance ELSE calculated to pay is EQUAL to assessed fee.END IF

Refer to: Name:

Comments:

Online Batch Manual



Number: 4.2Name: Get balanceDescription: Get previous balance of the student if any.

Input Data FlowStudent number

Output Data FlowBalance


Process Logic:

BEGIN IF student number has previous balance GET balanceEND IF

Refer to: Name:

Comments:

Online Batch Manual


VGNS Enrollment System

RegisterStudent

AddStudentRecord

RegisterStudentRecord

AssessFees

Get fees Get balanceCalculate To pay

GetPayment

Update Student Balance Print receipt

Figure 11. HIPO Diagram

Process Output

Calculated to pay

Input

Balance

Calculate Student’s

To pay

Assessed fees

Input Process Output

Student NumberStudent recordGet student

record

Update grade level

Update student information

Figure 11.1 HIPO Diagram

File Screen Report Form Internal


IV. Data Dictionary

Data Flow DescriptionID:Name: Payment detailsDescription: Contains the total payment made by the student and accounting form.

Source:Process 5

Destination:Registrar

Type of Data Flow:

Data Structure Travelling with the FlowTotal paymentAccounting form

Volume/Time

Comments: Total payment based from the assessed fees of the student. And an accounting form Which includes fees breakdown, type of transaction

Figure 10 Data Flow DescriptionData Flow Description

ID:Name: Student NumberDescription: Contains an eight digit numbers which serves as a unique identifier of the student.

Source:Process 1

Destination:Process 3

Type of Data Flow:

Data Structure Travelling with the FlowStudent number

Volume/Time

Comments: Unique identifier of a student to be used as reference when getting records. Figure 10.1 Data Flow Description



Data Flow DescriptionID:Name: Student NumberDescription: Contains an eight digit numbers which serves as a unique identifier of the student.

Source:Process 3


Type of Data Flow:


Volume/Time

Comments: Unique identifier of a student to be used as reference when getting records.Figure 10.2 Data Flow Description

Data Flow DescriptionID:Name: Student NumberDescription: Contains an eight digit numbers which serves as a unique identifier of the student.

Source:Process 3

Destination:D1 Student record

Type of Data Flow:


Volume/Time


Data Flow Description



ID:Name: Student RecordDescription: Contains student information, grade level and student number.

Source:Process 2

Destination:D1 Student record

Type of Data Flow:

Data Structure Travelling with the FlowFirst name, Last name, Middle nameAddress, Gender, Birth dateStudent numberGrade levelMother name, Mother ContactFather name, Father Contact

Volume/Time

Comments: Records of the student to be stored by the registrar.Figure 10.4 Data Flow Description

Data Flow DescriptionID:Name: Student RecordDescription: Contains student information, grade level and student number.

Source:D1 Student record


Type of Data Flow:

Data Structure Travelling with the FlowFirst name, Last name, Middle nameAddress, Gender, Birth dateStudent numberGrade levelMother name, Mother ContactFather name, Father Contact

Volume/Time

Comments: Records of the student to be stored by the registrar.Figure 10.5 Data Flow Description

Data Flow DescriptionID:



Name: Student NumberDescription: Contains an eight digit numbers which serves as a unique identifier of the student.

Source:Process 4

Destination:D1 Student Master

Type of Data Flow:


Volume/Time


Data Flow DescriptionID:Name: BalanceDescription: Contains the total to pay of the student not yet paid.

Source:D1 Student record


Type of Data Flow:

Data Structure Travelling with the FlowBalance

Volume/Time

Comments: Balance may occur until third yea, when in fourth year the student must be able to pay All the balances to be able to graduate.

Figure 10.7 Data Flow Description




Name: Grade levelDescription: Identifier of a student on which curriculum and fees the student must be assessed.

Source:Process 4

Destination:D2 Fees

Type of Data Flow:

Data Structure Travelling with the FlowGrade level

Volume/Time

Comments: Dependent whether in primary or secondary.Figure 10.8 Data Flow Description

Data Flow DescriptionID:Name: Student fees informationDescription: Contains the breakdown of the student’s fees in accordance to the student’s grade level.

Source:D2 Fees


Type of Data Flow:

Data Structure Travelling with the FlowGrade levelTuition feeMiscellaneous feeRegistration feeComputer feeTotal Amount

Volume/Time

Comments: May vary depending on grade level and payment type.Figure 10.9 Data Flow Description




Name: BalanceDescription: Contains the total to pay of the student not yet paid.

Source:Process 6

Destination:D2 Student Master

Type of Data Flow:

Data Structure Travelling with the FlowBalance

Volume/Time

Comments: Balance may occur until third yea, when in fourth year the student must be able to pay All the balances to be able to graduate.

Figure 10.10 Data Flow DescriptionData Flow Description

ID:Name: Calculated to payDescription: Contains the sum of the total to pay based on the assessed fee and the balance of Student if any.

Source:Process 4


Type of Data Flow:

Data Structure Travelling with the FlowAmount

Volume/Time

Comments: Figure 10.11 Data Flow Description

i. Database Specifications1. Enhanced - Entity Relationship Diagram

Father name

Mothercontact

Mothername

studentId

TotalFees

enroleeidYearEnrolled

GradeLevel

Section

Averagegrade

1stQtr

2ndQtr 3rdQtr4thQtr

Section

schedId

payid

Amount

Date

GradeLevel

RegistrationFee

MiscellaneousFee

Guardian name

Guardiancontact

TotalPaid

Balance

Fees

NameMiddle name

First name

Last name

AgeBirthday

Fathercontact

Password

teacherId

Subject

Person

d

Enroll

Enrolee

subjectId SubjectName

GradeLevelgradeId

subjectid

Student Teacher

TuitionFee

ComputerFee

Address

Units

Paymentoption

FinalGrade

teaches

Pays

Graded

2. Normalization of Tables

3. Database Structure

ii. Screen Designs

LOGIN MAINWINDOW

ADD STUDENT PAYMENT

ASSIGN SECTION ADD TEACHER

Assign subject teacher

GRADING SYSTEM

LOGIN FOR GRADING LIST OF ASSIGNED CLASS

iii. Object-Oriented Systems Analysis and Design Using UML

1. Structural diagrams

a. Class diagrams

class-Section:String-idAssign:int-idSubject:int-idTeacher:int

+setAssignment()+getAssignID()

Enrollee-Enrolleeid:int-GradeLevel:String-Section:String-TotalFees:double-studentid:int+setEnrolee(ResultSet rs)+setEnrolleeid(String id)+setSection()+calculateTotalFees(doublefees)

Grades-Recordid:int-Enrolleeid:int-subjectud:int-1stQtr:double-2ndQtr:double-3rdQtr:double-4thQtr:double+setGrades(ResultSetrs)

Subject-Subjectid:int-SubjectName:String-GradeLevel:String-Units:double+setSubjects(ResultSetrs)+getSubjectname():String+getSubjectID()

Fees-GradeLevel:String-RegistrationFee:double-MiscellaneousFee:double-TuitionFee:double-ComputerFee:double+setFees(String Grade)-CalculateTotalFees()

payment-paymentid:String-enrolleeid:int-Amount:double-Date:Date+setAmount(doublea)+setDate(Date today)+getPaymentid():String+setEnrolleeid(stringa)+getTotalPaid():double

Person-Address:String-Age:int-Birthday:String-Firstname:String-Middlename:String-Gender:String

+getFirstname()+getLastname()+getMiddlename()+getAddress()+setFirstname()+setLastname()+setMiddlename()+setAddress()+getAge()

teacher+teacherid:int+Password:String

+setTeacher(ResultSet rs)+setTeacherID ()

student-Studentid:int-guardianName:String-guardianContact:String-fatherName:String-fatherContact:String-motherName:String-motherContact:String+setStudent(ResultSetrs)+getStudentid():int

can be can be

assigned to

enrolls

consist of

has

has

makes a

1..*

11..*

1..*

1..*

1..*

1..*

1

1

1

1..*

1

1

1..*

is a is a

Use Case Diagram of the proposed system

Registrar

Add Studentrecord

Assess fees

Receivepayment

EnrolleeGuardian

Student

UpdateStudentRecord

Searchstudent

<<extend>>

Logon

PrepareGrading Sheet

Select Class

<<include>>

<<include>>

Encode Grade

<<include>>

<<extend>>

Teacher

Use case Diagram for Porposed Grading System

2. Behavior diagrams

a. Use case diagrams

b. Sequence diagrams

:: GUIAddStudent<GUI>

:: ManageNewStudent<Control>

conn:DBConn newStudent:Student

Initializeinfo()

getNextstudentNumber()

return StudentNumber()

setStudent()

enrol:Enrollee

getEnrolleeid()

return Enrolleid()

setEnrollee(enrolleeid,studentNumber,gradeLevel,)

return Student

return Enrollee

Insert(table,studentValues)

Insert(table,enrolleeValues)

ShowSuccessMessage()

addStudent

:GUIAssesswindow<GUI>

:assessManager<Control> :enrollee Fee:fees

getEnrolleeinfo()

return GradeLevel()

initialize()

getFees(GradeLevel)

return Fees()

TotalFees()

Assess

:GradingMainWindow<GUI>

:classManager<control> class:Assignment

setTeacher()

getAssignments(idTeacher)

return assignmentList()

getEnrolled(gradelevel,subjectid,section)

return studentListshowStudentList()

student:Enrollee

class Selection

:GradingWindow<GUI>

:encoder<control>

student:enrollee record:Grades

Initialize()

getEnrollee(enrolleeid)

return enrollee

getRecords()

return Records

showMainWindow()

conn:DB2Conn

makeUpdatedRecord(grades,idEnrollee,subject)

return updatedRecord()

update(table,updateRecord)

retrun isSuccess()

initialize()= id enrollee, grades from GUI, idSubject

Encode Grades

:GradingWindow<GUI>

:login<control> account:teacher conn:DBConn

login()

setTeacher(Username,Password)

return teacherAccount()

verifyTeacherAccount()

return hasAccountshowMainWindow()

gradingLogon

:GUIPaywindow<GUI>

:payManager<control> enrol:enrollee pay:payment

getEnrolleeinfo()

return Enrolleeid()

initialize()

setPayment(enrolleeid,amount)

return payment

TotalFees ()

conn:DBConn

Insert(table,payment)

return ifSuccess()

payment


:gradeEncoder<control> student:Enrollee

initialize()

getEnrollee(idEnrollee)

return Enrollee()

prepareRecord(enrolleeid,idsubject)

return gradeRecords

showSuccess()

record:Grades conn:DBConn

insert(table,gradeRecords)

return isSuccess()

prepare record

:: GUIOldStudent<GUI>

:: ManageOldStudent<Control>

conn:DBConn oldStudent:Student

studentNumber()

getStudentRecord()

return studentRecord

setStudent()

return Student

SetStudentFields()

search



conn:DBConn oldStudent:Student

getEditStudinfo()setStudent()

enrol:Enrollee

getNewEnrolleeid()

return Enrolleid()


return Student

return Enrollee

update(table,studentValues)

Insert(table, enrolleeValues)


return ifSuccess()

return ifSuccess()

update student

c. Communication diagrams

:: GUIAddStudent<GUI>

:: ManageNewStudent<Control>

conn:DBConn

newStudent:Student

Initi

aliz

einf

o()

getN

exts

tude

ntN

umbe

r()

setStudent()

enrol:Enrollee

getE

nrol

leei

d()


Inse

rt(t

able

,stu

dent

Valu

es)

Inse

rt(t

able

,enr

olle

eVal

ues)

Show

Succ

essM

essa

ge()

Addstudent

:GUIAssesswindow<GUI>

:assessManager<Control>

:enrollee

Fee:fees

getEnrolleeinfo()

initialize()

getFees(GradeLevel)

TotalFees ()

Assess


class:Assignment

setTeacher()

getAssignments(idTeacher)

getEnrolled(gradelevel,subjectid,section)

showStudentList()

student:Enrollee:classManager<control>

class selection

:GradingWindow<GUI>

:encoder<control>

student:enrollee record:Grades

Initialize()

getEnrollee(enrolleeid)

getRecords()

showMainWindow()

conn:DB2Conn

makeUpdatedRecord(grades,idEnrollee,subject)

update(table,updateRecord)

encode grade

:GradingWindow<GUI>

:login<control>

account:teacher

conn:DBConn

login()

setTeacher(Username,Password)

verifyTeacherAccount()

showMainWindow()

grading login

:GUIPaywindow<GUI>

:payManager<control>

enrol:enrollee

pay:payment

getEnrolleeinfo()

initialize()

setPayment(enrolleeid,amount)

TotalFees()

conn:DBConnInsert(table,payment)

payment


:gradeEncoder<control>

student:Enrollee

initialize()

getEnrollee(idEnrollee)

prepareRecord(enrolleeid,idsubject)

showSuccess()

record:Grades

conn:DBConninsert(table,gradeRecords)

prepared record



conn:DBConn

oldStudent:Student

studentNumber()

getStudentRecord()

setStudent()

SetStudentFields()

search



conn:DBConn

oldStudent:Student

getEditStudinfo()

setStudent()

enrol:Enrollee

getN

ewEn

rolle

eid

()


upda

te(t

able

,stu

dent

Valu

es)

Inse

rt(t

able

,enr

olle

eVal

ues

)


update student

d. Activity diagrams

Start

Logon System ValidateAuthenticity

Display errormessage

[invalid]

Input studentinformation

[send error message]

[valid]

ValidateInformation

[student information form]

[validation status]

[validation status]


[invalid format/ missing fields]


[valid data received]

Add studentrecord

Create studentnumber

[Record Added]

[Student Number created]

[valid data] [valid data]

Displayconfirmation

[valid add][confirmation sent][cancel]

GUI CONTROL DATABASE

add student

Start



[invalid]

Assess fees


[valid]

[validation status]

[cancel]


Search forstudentnumber

Receivestudentnumber

[student number form]

[match status]


[no match found]

Display studentdetails

Search forstudent record

[student number matched][student details]

Get fees record

Receive gradelevel

Receivepayment type

[payment type transmitted]

[grade level] [grade level]

[payment type]

Display feesbreakdown

[display successful] [fees breakdown]

assess

StartGUI CONTROL DATABASE

Receive subjectclass

Choose list

Receiveadvisory class

[Subject class]

[Advisory class]

Get Class list[Subject & section]

[section]

Display handledclass

Displayadvisory class

[cancel]

[Successfully displayed]

[Successfully displayed]

class select


ChooseStudent

Displaystudent grades


[student number] Get studentrecords

Enter grades

Updatestudent grade

[grade form sent]

[grade form received]

[Successful update][Cancel]

encode

Start

Receive logonform


Logon System

[Logon form] Get teacher

record[Teacher ID & password]

[Record status]


[Not found / Invalid]

[sent error message]

[cancel] [Successful login]

logon

Start

Receivepayment type

REGISTRAR CONTROL DATABASE

Get feesrecord

Receive gradelevel

[payment type]

[grade level]

Calculate totalto pay

[total fees]

Display to payAcceptPayment

Displaysuccessfultransaction

Update studentrecord

[cancel]

payment


ChooseStudent


[student number] Get studentrecords

Create newgrade record

[Successful]

[Cancel]

prepare sheet

Start



[invalid]

Edit studentinformation


[valid]

ValidateInformation

[student information form]

[validation status]

[validation status]


[invalid format/ missing fields]


[valid data received]

Displayconfirmation

[valid add][confirmation sent][cancel]


Search forstudent

Find matches

[student number/student name form]

[match status]


[no match found]

Display studentinformation

Search formatches

Displaymatches

[student name matched]

[student number matched]

Update studentrecord

update student

Chapter 6 | Summary and Conclusions

A. Summary of Changes, and Improvements

Student info are now stored in a database

File cabinets can be removed after digitizing all other past documents

Faster data mining can be done by the registrar

Reduce the risk of undocumented transactions, every transaction is saved

into the database

The personnel can now keep track of the student’s payment history easily.

Able to issue printed receipts instead of written ones

Easier sectioning of students as their grades can be easily viewed and

deliberated.

Updated picture of the student are recorded within the database

All information in the database is now password protected and tampering of

records will not be easy

B. Constraints of the New System

Filling up of forms can’t be totally removed

Registrar still has to sign printed receipts

Only average of the student’s grades per quarter can be entered in

the database

Enrollment and grading system only

Accounting system not included

Not an online enrollment system

Chapter 7 | Activities in the Next Stage of Development

A. Testing Plans

The team would simulate and enter dummy accounts in the system to

make sure that everything is working as it should. This includes testing for

error trapping mechanisms and verifying if each button does what it's

supposed to do.

Another testing plan is to see whether power outages would affect the

transactions done. If it does interrupt the flow, we would suggest they buy a

UPS or unlimited power supply. This would give the user enough time to save

their work and properly shutdown the system.

B. Maintenance Plans (recommendations for upgrades and / or updates)

The life expectancy of a computer is about 4-6 years, given that it is well

maintained and upgraded from time to time. After that, it should be replaced

as there would be programs that the computer can't keep up anymore.

C. Security Plans

The team has decided to implement a log in system as a first line of

defense against unauthorized people. The principal, a few teachers and the

registrar will have access to the system. Multiple user level accounts with

various capabilities will be enforced so as to prevent any hackers from gaining

access to all the company information with just a single account.

Appendices

A. Start – up procedure

A.1 Minimum Hardware and Software Specifications

Hardware Involved

1. Desktop Computer – this is where the proposed Enrollment System will be

implemented. In order to access the system, the user needs the desktop computer and the

system to be installed in the desktop computer this will enable a fast transaction that is

needed in the enrollment system.

2. Printers – the system lets the user generate reports for the teachers and the

students which will then be used for validation purposes. This can only be done if the

computer is connected to a printer

Software Involved:

1. NetBeans IDE 6.9.1 – this software is one option where the user can access the

Enrollment system. All the user interfaces and documents provided by the system can also

be accessed by using this software.

2. MySQL – this software serves as the database to the files and information stored in

the system.

3. Jaspersoft iReport – this software lets the user to generate reports. And was used by

the developer to design reports

4. JAVA 1.6- this software is also one option where the user can access the Enrollment

system.

B. Initial Entry / Access

The user can only access the system in two ways:

1. Desktop Computer –the computer where the program is installed in. All of the

functions of the system are available for the user. The user should input the correct

username and password before the system can be accessed.

B.1 Levels of Users

Total Number of User Types: 2

Total Number of Users: 2

USER 1

User: School Registrar

Description: Computer Literate aged 20-30 yrs old and familiar to

company’s Enrollment System. Full knowledge about the Enrollment

System

Responsibility: Encoding and Managing Student and Teacher Records

Expected number of user: 1

Location: Registrar’s Office

Usage Exposure: Intermittent

Privileges: Add and Update

USER 2

User: Teacher

Description: The one who encodes grades of the students

Responsibility: calculates and encodes grades of students

Expected number of users: 30

Location: teacher’s faculty

Usage Exposure: Intermittent

Privileges: Add and Update

B.2 Files to Open

Files that only need to be open are reports which are generated by the system upon

request of the user.

B.3 Default Password and Password Changes

Since there are many users, the system is designed to accommodate many teachers by

making a teachers account upon addition of teacher’s information:

1. Registrar

Username: root

Password: 12345

Teachers’ account will have a password which is created by the teacher upon registering. Note

that these usernames and passwords are case sensitive; meaning the inputs of the use should

match the ones given to them as is.

C. List of Error Messages

" might not be Registered “– When the user inputted an Student number wherein he/she is not

registered for that school year.

“Missing fieldst” – the user inputted a data that is not matched or allowed by the system (e.g.

when a user inputted a numerical value in a character field).

“Subject has a similar record” – when the user attempted to add a subject that is already

present on the database.

“check date Format” – when the user was not able to fill up all the date field with correct date

format.

“Problem Encountered during encoding”- when there is a problem during updating/adding of

subjects.

“"No record found"- when the system search an old student and no record was found

"Password don't match"-passwords don’t match when changing password of teacher

Other Messages

“SUCCESSFUL TRANSACTION” – when a user has successfully made a transaction in the

Assessment and Payment Section.

“Update Successful” – when the user changed the information on the database and the

changes and the criteria are satisfied then this message will appear.

“Update Success!”-the user has successfully add an student record.

“Registration Success!”- the user has successfully enrolled an old student.

"Update Success!"- the user has successfully updated a teacher’s record.

Date post:	25-Nov-2014
Category:	Documents
Upload:	virge-cruz
View:	111 times
Download:	0 times

Documentation Finale

Documents