Edited Project1111

Contents
I
Acknowledgement
First of all, we would like express our heartfelt appreciation and gratitude to almighty God
for helping as through all the challenges we faced particularly in the past four years.
We would like to express our heartfelt appreciation and gratitude to all persons who provided
us with their unreserved support, encouragements, and comments which have been critically
helpful to accomplish our project successfully.
We indebted a special gratitude to Instructor Mr. Daniel Bekele (Msc), our adviser for his
constructive and supportive comments, materials and professional advice in each phase of the
project. We would like to express our heartfelt gratitude to the Director of school Mr.Tesfaye
Nemera who advise us how we make the project for the organization. And, finally we are
very much grateful to all the staff of Wollega University Gimbi Campus that provided us
with all the necessary information as well as comments and encouragements that made this
project possible.
II
Abstract
Gimbi comprehensive high school Student information management System;

application software includes registration of student, displaying student information,
Mark management, control and authentication mechanism, generating report for
desired activities. The software has search engine, interactive interface so that it is
user friendly. The system is secured so that only and only authorized person can
access the system to perform any activity. The system is web based so it integrate
each department of the high school with networking system and avoid any manual
information sharing among those departments. The methodology of this system
includes personal information, interview, document analysis and observation. Use
case diagram, Class diagram, sequence diagram, use case description and activity
diagram will be used to analysis the system.
III
Abbreviations
CD: Compact Disc

GUI: Graphical User Interface
GCHSSIMS: Gimbi Comprehensive High School Student Information Management
System
HTML: Hyper Text Markup Language
PHP: Preprocessor Hypertext
UML: Unified Modeling language
IV
Chapter one
1 Introduction
1. Background of the organization
Gimbi Comprehensive high school is located in Gimbi town near wollega university Gimbi
campus. It started giving teaching service for the first time in 1950 E.C. At that time, the school
started the teaching-learning process by registering 74 students out of which 43 were male and
31 were females, by 8 male teachers and 2 female teachers totally 10 teachers and having for
supporting staff workers out of which 3 were males and 1 was female. Now days, The school is
carrying out its learning-teaching process having 36 male and 13 female teacher with 7 male and
3 female supporting staff workers. Currently the school have already registered 1508 students
and continued its teaching-learning process.
The School compound contains library, laboratory rooms and conference hall apart from
classrooms. The general objective of the establishment of the school was to provide access of
high school education for students those who completed their primary education.
The school registers only students those who have passed the grade 8 national exam. This project
is intended to replace the manual registration system of the school with computerized registration
system. The student registration system is used to provide efficient and reliable service for
Student and staffs. The Registrar office is giving various services such as admission, registration,
generating report, and marks of student for each subject, determine status and updating student
information. Doing these services manually is exhaustive. Due to this reason GCHSSIMS
(Gimbi Comprehensive high school student information management system) solution are
designed to enable the registrar to do every activity effectively.
1
1.2 Organizational Structure
Ministry of Education Bureau
Oromia Regional state Edu.Bureau
West Wollega zone edu .office
Director of GCHS
Vice Director GCH
Education process Finance office Administrative office
Registrar Library
1.3 Statement of the problem

The current registration system of the school has many problems in relation to registration and
traditional file system. The main factor behind this is that the work is based on paper/hard copy.
It is known that there is a great difference between the offices who rely on computer to perform
their jobs and those who depend on paper in providing service for community and outside
society.
Gimbi comprehensive high school relies on paper based record /registration system to perform
its daily task. Records are not properly maintained. This creates a lot of problems like lack of
update, search and information retrieval and storage.
2
The other problem is that the manual system performs a number of operations incorrectly and
lacks accuracy of work appropriately. Due to redundant data, more space is occupied by file
cabinets. In addition to this it is difficult to add some additional requirements to the existing
system’s stored data (i.e. it is not flexible).
There is no control and security mechanism with in the office. Student’s information is not
secured and it can be seen by other peoples, because there is no authentication mechanism.
The services provided by the office are not as fast as possible because the service providers are
busy with the paper and paper related activities
1.4 Objectives
1.4.1 General Objective

The general objective of this project is to automate the manual registration system of Gimbi
Comprehensive high school
1.4.2 Specific Objectives

 To Analyzing the current system they are using and developing a new automated
system.
 To study the existing system
 To design the database
 To test the functionality of the system.
 Using UML for modeling the system
 Using Data Collection methods for gathering data
1.5 Scope of the project

The office of registrar has many duties. However automation of service it provides doesn’t go
with the short reference that we have. So the project only involves the following areas.
 Online registration
 Update mark of student and subject name
 Determine status rank
 Insert mark of student
 Add mark of student
3
 Delete mark of student
 Compute average of the mark
 Generating report
1.6 Limitation of the project

Limitation describes what operations or functions the final result of the proposed system can’t
perform due to different constraints. As a result the proposed system will not include the
following services:-
 Online registration of Evening class

 Online fees
 Class schedules
 Online exam
 Preparation of transcript
1.7 Methodology
1.7.1 Data Collection methods

From the various fact finding methods we used the following tools:
 Personal observation: assessing and analyzing the overall registrar system has been
carried out by personally observing the current working system.
 Interview: This is one of the methods used for the collection of data in which the project
designers have the chance of asking different questions. We conducted the interview at
work by going to the organization and interviewing the workers, the users and as well as
the manager of the organization. We get so many information how the organization
looks in detail.
 Document analysis: the team analyzed different kinds of secondary (published) sources,
unpublished documents from the institution which helps as to understand the existing
system. In order to collect basic information for the project we are sought to use
questionnaire, interview, observation and document analysis .Open ended and close
ended questionnaire are intended to be used.
4
1.8 System analysis and design methodology
Throughout the system development of this project we planned to use object oriented system
analysis and design methodology to develop the system. Reasons we select object oriented
approach are its nature of:
 Reusability of code
 Simple to implement
 Easy to adopt changes at any level
 Models the real world
1.9 Significance of the project

Our system has a great deal on the issues concerned with registration by providing necessary
information, easing the work and the working environment, and others. The registrar office gets
different functionality from the system. These are:
 Information resources can be searched easily.

 It save Space which reserved by rooms.
 Improve the data sharing from one sub-system to another sub-system.
 The authorized access to information resources files of the system is more advanced. This
means secured login to the system will be developed.
 Resources and time saving in system operation and service provision is one of the major
benefits.
 Reduce complexity
 Minimizing work load of the registrar
1.10 Feasibility study

To bring the successful completion of this project goals and objectives the feasibilities issues
listed below has determined the project viability or the discipline of planning, organizing, and
managing resources.
 Technical feasibility: This system provides help description to the user about how to use
the system. And other technical modification on the system is done by the developers.
5
 Operational feasibility: Today there is no automated system in Gimbi Comprehensive
high school. The system will provide adequate through put at desired time to the user and
also give the needed information in a timely usefully formatted way.
 Economic feasibility: As cost/benefit analysis, show the new system is developed using
a very minimum cost and it give a lot of benefits such as advancing the services of the
registration, decreasing the work load of the registrar office, students will register and see
their grade
1.11 Beneficiaries of the project

 Customers/user
 The Customers can save their time after the implementation of the proposed system.
 Employees
 Reduce workload
 Save their time
 Decrease errors in information access of the manual system
1.12 Implementation and programming tools

 Server: - We use Wamp server for storing and communicating between the database and
applications.
 PHP: - to write server side scripting language and a powerful tool for making dynamic
and interactive Web pages. it is fast, stable, secure, and easy to use.
 MySQL Database: - it is one of the RDBMS software which store data. we were use this
database tool to store real estate detail information, user account detail, and security data
 HTML and CSS: using for static part of the website
 JavaScript : for dynamic page or client side validation
 Microsoft word: for the documentation
 Microsoft Visio: for modeling the system.
 Adobe Photoshop CS2: for formatting pictures and buttons.
The project team members used also the knowledge of php as a front end development tool.
6
1.13 Team members roles & responsibly
The success full completion of the project indeed requires the sincerely corporation of the team
members. Each team member has valuable contribution in each aspect of the project.
In addition each member also will be responsible for the overall activity. The group also has
responsibility to arrange communication plan for meeting and perform their work. Collect
information and documentation also discuss it as well as group members have the responsibility
of accepting the advisor comment and perform what they told to do. Also have responsibility of
reporting their work to the advisor
The project team contains six members and each member has their own tasks, activities and
responsibility to the delivery of the project.
Role Description Assigned To
Project Oversees the project and ensures that it meets its Milion Mitiku
Manager objective in time, function, and cost according to the
project plan
Programming Writing a code and design the system Mengistu Mekonen

/Coding
System Design the information system and ensure the Geremu Begire
Analyst system conforms to information systems standards
and analyze the system requirement
System Design the project structure and interface Mengistu Diriba and
Design Tadele Birahanu
Tester The key responsibility will be for coordinating the

development and testing phase of the project. He is
Gurmesa Alemu
also responsible for installing the developed system
in successful manner.
Table 1.1 Roles and responsibilities table
1.14 Constraints and Assumptions

1. Constraints
7
 Students should not allow making any changes to the database.
 The system does not support personal signature.
 The system can’t support online payment.
 Password should not be null
2. Assumption
 Assumption that Gimbi comprehensive high school has sufficient internet access.
 There is a practice and method of taking backup.
 Assume that the users know the basic computer skills
 Assume that the hardware used to interact with the system will be a standard keyboard,
mouse, monitor, and a standard printer for taking hard copy of the reports generated as
and when required.
 Assume that the users know how to start a program from the GUI, and can interact with a
user interface using standard keyboard, mouse, and monitor.
1.15 Plan
1.15.1 Resource plan

The project development needed a set of resource to accomplish several tasks during different
development phases. Some of these are listed below:
Hardware resources such as storage devices (CD/DVD, Flesh disk) and papers
Software resources such as Wamp server package (web server and Mysql RDBMS).
1.15.2 Beget plan (project cost)

The budget required to complete the application is listed in the following table.
Number Name Amount Unit price Total price
1 Printing paper 4 packet 100.00 400.00
2 CD-RW 2 16.00 32.00
3 Purchasing of different 5 200.00 1000.00

software & hardware
8
4 Purchasing of flash disk 6 piece 180.00 1080.00
5 Miscellaneous expenses - - 1000.00
Total - - - 3512 birr
Table 1.2.budget distribution
9
Chapter Two
2.1Study of the existing system
2.1.1 Introduction
This chapter focuses on the objectives, purposes, procedures and goals of the existing system. It
tells how the current system performs its activities within the school. The team members collect
the necessary information of the current manual system using different methodologies such as;
Interview and observation. The process of the interviewing prepared all the interviewees were
asked to understand the existing system the work flow of the registrar system from the registrar
officer to the subject. Using the observation the team members proposed it will be good if
automated system is done for such activities.
Oromia TVET Agency
2.2 Overview of the existing system
Gimbi Comprehensive high school registration system focuses on student registration, updating
Cluster
subject of Nekemte
name, modifying student records when necessary and also it transfers information
(reports) to other class that are concerned to the report. In the current system activities such as
searching,
Board ofdeleting,
Limu TVETupdating students record; and generating a report is a tedious and a time
consuming task.
2.3Dean of Functions
Major TVET of the current system
 Functionalities
 Register students mark list.
 Register existing student (Registration).
Training process Administrative office
Finance office
Generating report
 Update mark of student and subject name.
 Major activities
o Registering new students
Registrar Library  Students should have student transcript and mark list.
 They receive student admission application form.
 They fill the appropriate information on the form and attach his/her
photos, and then they submitted to registrar.
 The registrar workers check whether they are valid or not.
10
 If valid students give photo to get ID.
 Registrar gives ID.
o Registering existing students
 They receive Registration from registrar.
 They fill the appropriate information on the form and attach his/her
photos, and then they submitted to registrar.
 The registrar checks the form and stamp on it.
 The students show their ID and clearance paper.
 The registrar checks the status of student if it is ok, they give student ID
2.4 Users of the Existing System
 Registrar officer (vice director) responsible for:

 Making decision on cancelation of the registration.
 Announcing the registration time.
 Co-coordinating registrar workers for achievement of their goal.
 The Record worker is responsible for:
 Preparing ID and student’s Result report.
 Register the students.
 Accepting the claim from the students and presenting it to the manager.
 Storing the student data into File Cabinet.
 The students:
 Registering on time.
1. Submitting students ID on time.
2.5 Problems of the Current System

 Since the registrar performs registration, Preparing ID for new student,
prepare student roster, generating report. It takes much time.
 Duplication of data occurs when data input in to the system.
 Checking the validity of input data is difficult.
11
 Processing the input data in order to get an output takes much time because of
the manual system (like Marks of student takes time, compute average,
determine status and update mark of student).
 The data stored takes more rooms.
 Since students fills different forms during registration and these forms are
checked by concerned registrar employee on different offices this process
takes much time.
 After students submit registration form the registrar employee check the
validity of student’s information line by line the student’s response time is
low.
 Since the system currently uses manual system it is not economically
sufficient i.e. there is a redundancy of activities, unnecessary ID is given to
student and main registrar (wastage of material and time), transcript is
prepared each and every semester with an unnecessary number of copies
(wastage of material).
 Currently almost there is no control and security mechanism with in the office.
Student’s information especially transcript is not secured that is it can be seen
by other peoples, because there is no authentication mechanism.
 The current system takes time during student registration because they use
some workers for a number of students, which makes the student to wait a lot
until they get their turn.
 The services provided by the office are not as fast as possible because the
service providers are busy with the paper and paper related activities.
2.6 Forms used in Current system

 Student Admission application form.
 Consolidated mark list form (Roster)
 Student registration form.
 Student’s mark list form.
12
Chapter Three
3.1 Proposed system/New System
3.2 Overview of new system

This High school student information management system (HSSIMS) document is the base point
to support in solving problem of Gimbi comprehensive high school and creating web application.
In this document mainly include purpose of the system, scope of the system definition and
references that support as manual guideline. This help to understand clearly what the system
includes and also it includes system function, user characteristics, functional requirement, non-
functional requirement, system constraint and system interfaces. Generally the system
concentrates on different requirements.
3.3Product functions
The registration system has the following functionalities:
 Registering students.
 Inserting students mark
 Updating students mark
 Preparing mark list
 Preparing Roster
 Allow users to view information.
 Generating report
3.4User characteristics
User classes User Characteristics Technical skills
13
 Good understanding of HSSIMS  Ability Use different system from past.
Administrator operations.  Have basic knowledge of using the
 Responsible for the whole operations. system in a networked environment
 Have the good knowledge and  Experience in how to manage the
understanding about the HSSIMS overall system.
system.
 Good understanding on the data  High in technical retrieving and

recording system. recording of information.
 Good knowledge how to retrieve  Have basic knowledge in database.
Recorder information.  Have basic knowledge of using the
 Responsible for retrieving information system and storing data to the system.
each time
 Medium of language for communication  Basic computer skill and
with system (English)  know how to use Internet
Student  The student needs to understand the
information found in user interface.
 Good understanding on the data  Have basic knowledge in database.
recording system.  Have basic knowledge of using the
Teacher  Good knowledge how to retrieve system and storing data to the system.
information.
 Responsible for insert, Delete and
updating mark of student’s
Table 3.1 user characteristics
3.5 General Constraints
Constraints
 Students should not be allowed making any changes to the database.
 The system does not support personal signature
 The system can’t support online Schedule and fees
14
Assumption & dependencies
 Assumption that GCHS has sufficient internet access.
 There is a practice and method of taking backup.
 Assume that the users know the basic computer skills a standard keyboard, mouse,
monitor, and a standard printer for taking hard copy of the reports generated as and when
required.
 Assume that the users know how to start a program from the GUI, and can interact with a
user interface using standard keyboard, mouse, and monitor.
3.6 Hardware and software consideration

All hard ware and soft ware considered based on the performance, types, versions and
technology which is recently developed and also compatible with the selected hard ware and
software.
The below listed equipment and software are required by the system so as to run effectively.
 Hardware requirements
The following sub-sections discuss the various aspects of hardware requirements.
 Database server computers and web server computers having 6 GB of RAM and 500 GB hard
disk and Intel(R) core™i3 CPU 550@3.20GHz processing speed
 Network devices, NIC etc.
 Software requirements
Platform
Typical platforms include a computer's
 Operating system: Microsoft Windows 7, windows 10
 Web browser( fire fox, Internet Explorer )
 Programming language: PHP, JavaScript
 It supports all browser application but Internet Explorer is recommended.
 Other requirements
 Uninterrupted power supply
 Network connection
15
3.7 Functional requirements
Functional requirement is a description of activities and services a system must provide. These
requirements describe the interactions between the system and its environment independent of its
implementation. The environment includes the user and any other external system with which the
system interacts. Functional requirements that must be included in the system are listed below:
1. Student’s data process:
 Registration of student
2. Create account: the system allows user account creation and user management
3. Reports: The system generates different kinds of report like number of promoted,
detained, incomplete and drop out students and show the total number of Students. Etc
 Update: The system allows Updating all available file relate to student information found
in the data base
4. Forms: This requirement is related to preparation of the various forms that the registrar
uses in its day to day activity. Those forms are: Student’s registration form, Student’s
readmission form, student mark list form and etc
5. Compute Rank: the system allows to calculate average and rank of student’s
6. Control and checking mechanism: the system should able to prevent unauthorized
user but allow authorized user to get access to the system and control each user access
according to their privilege.
3.4 Non-functional requirements
3.8.1 User interface

The system provides graphical user interface which is easy to learn and use.
1. Availability
 The system should be available 24 hours in a day and 7 days in a week except
during maintenance.
2. Data integrity
 Data will be critical to its success as a system.
 Systems data integrity needs the consistency, correctness and complete of data
registered the following features improve the data integrity of the system.
16
 Since the system performs data validation mechanism while entering the data
that makes data consistency.
 Extensive data validation and review will be performed both before data are
uploading to the system and as part of upload process which supports the system
to keep data integrity.
3.9 Use case model
3.9.1 Actors identification

Here, we deal only with persons that are involved in major service of GCHS. To this end we
identified some users that are involved in the existing system as follows:
 Administrator
 Recorder
 Student
 Teacher
3.9.2 Use Case identification

Before we develop a use case diagram we must first identify the groups of related use cases. In
addition we need to identify the initiators of the use cases - the actors. Actors reside outside of
the system and interact with it; use cases describe the functionality that helps actors achieve their
goals. In the project we identified the following use cases:-
 Login
 Create account
 Compute mark and average
 Delete account
 Generating report
 Insert ,update, delete and submit mark
 Modify account
 View report
 Approve mark
 Student registration
17
3.9.3 Use Case Diagram
A use case diagram illustrates a set of use cases for a system, the actors of these use cases, the
relations between the actors and these use cases, and the relations among the use cases. The
UML notation for a use case diagram is shown on the figure below, in which
 An oval represents a use case,
 A stick figure represents an actor,
 A line between an actor and a use case represents that the actor initiates and/or participates in the
process.
18
Use case diagram
Scenario
Scenario 1
Name of use case: create account
Participating instance actor: Administrator
Entry condition:
1. He/she login to the system by using his/her account.

2. He/she has the user’s information (full name, id).
Flow of events:
1. He/she click on the create account link from the HSSIMS home page, Administrator
Page.
2. The system displays the create account form.
3. He/she fills the form and click on create button.
4. The system generates new user account with username and password.
Alternate Case:
1. If he/she made error when he fill the form and click on create button with error, the
system displays an error message and it allows him to try again.
2. He/she clicks on the clear button to clear the text field.
Exit condition: The system saves all necessary users’ information in the user table.
Special requirement: when he/she performs this task connection should not be down.
19
Scenario 2
Name of use case: login
Participating instance actor: Student, Recorder, Administrator, Teacher
Entry condition:
1. The users have valid username and password.

2. The users also have the URL (web site) of HSSIMS.
Flow of events:
1. In the HSSIMS login page the user enter his/her user name and password
2. The user clicks on the login button.
3. The system displays the Student or Recorder or Teacher or Administrator page.
Alternate Case:
1. If the username and password are invalid, the system displays an error message and
allows the user to try again.
Exit condition:
2. The system saves all necessary information’s of the user’s activity when he/she interacts
with system.
Special requirement: when the user performs this task connection should not be down.
Scenario 3
Name of use case: Student Registration
Participating instance actor: Recorder
Entry condition: He/she logs in to the system using his user name and password.
Flow of events:
1. He/she clicks on the Registration link from the Recorder page.
20
2. The system displays Student registration form.
3. He/she fills the form and click on Register button.
4. The system displays successfully registered message
Alternate Case:
1. If the registered record exists in the database, the system displays the Student already
registered message.
2. If the input data has error, the system display error message & allow him to try again
Exit condition: The system saves his record.
Special requirement: when he performs this task connection should not be down.
Scenario 4
Name of use case: Modify Account
Participating actor: Administrator, Teacher, Recorder
Entry condition: He/she logs in to the system using his/her account.
Flow of events:
1. He/she clicks on modify account link from the Administrator, Teacher and Recorder page.
2. He /she clicks on update user account button.
3. The System displays search options (by SID).
4. The system displays the user’s old user name and password.
5. He clicks on the update button to modify account.
Alternate Case:
1. If there is a mistake in the data entry, the system displays error message and it allows to
him /her to make correction.
Exit condition: The user account is modified successfully.
21
Scenario 5
Name of use case: Generate report
Participating actor: Record worker
Flow of events:
1. He/she clicks on “Generate Report” link from the HSSIMS home page.
2. The System displays the Report form.
3. He/she fills the form properly and clicks on generate button.
4. The system generates the Student Report.
Alternate Case:
1. If there is a mistake in the data entry the system displays error message and it allows to
him/her to make correction.
Exit condition: The Student report generated successfully.
Scenario 6
Name of use case: View report
Participating actor: Administrator
Flow of events:
1. He/she clicks on “View report” link from the Administrator page.

2. The System displays the View generated report.
Alternate Case:
22
him to make correction.
Exit condition: The Student report displayed successfully.
Scenario 7
Name of use case: View status
Participating actor: Student.
Entry condition: The student logs in to the system using his/her account.
Flow of events:
1. The user clicks on view status button from the Student page.
2. The Student enters ID to view status form.
3. The user clicks on view button.
4. The System displays the user’s status.
Alternate Case:
the user to make correction.
Exit condition: The user views his/her status.
Scenario 8
Name of use case: Update Mark
Participating actor: Teacher
23
Flow of events:
1. He/she clicks on Update mark link from the Teacher page.

2. He /she clicks on update mark of student button.
4. The system displays the student’s old mark.
5. He clicks on the update button to modify the mark.
Alternate Case:
Exit condition: The Student mark is modified successfully.
Scenario 9
Name of use case: Delete Mark
Flow of events:
1. He/she clicks on Delete mark link from the Teacher page.

2. He /she clicks on Delete mark of student button.
4. The system displays the student’s old mark.
5. He clicks on the Delete button to delete the mark.
Alternate Case:
24
Exit condition: The Student mark is deleted successfully.
Scenario 10
Name of use case: Submit Mark
Flow of events:
1. He/she clicks on submit mark link from the Teacher page.

2. The system displays the student marks.
3. He/she clicks on submit button.
Alternate Case:
Exit condition: The Student mark is submitted successfully.
Scenario 11
Name of use case: Delete Account
Flow of events:
25
1. He/she clicks on Delete account link from the Administrator page.
3. He/she type the user’s account ID.
4. He clicks on the delete button to delete account.
Alternate Case:
Exit condition: The user account is deleted successfully.
Scenario 12
Name of use case: Approve Mark
Flow of events:
4. He/she clicks on Approve mark link from the Administrator page.

5. The system displays the student marks.
6. He/she clicks on Approved button.
Alternate Case:
Exit condition: The Student mark is approved successfully.
Scenario 13
26
Name of use case: Insert Mark
Flow of events:
1. He/she clicks on insert mark link from the Teacher page.

2. The System displays search options (by Subject ID).
3. He/she type the subject ID.
4. He clicks on the Insert button to insert student mark.
Alternate Case:
Exit condition: The Student mark is inserted successfully.
Description of Use Case models

Description 1
Use case name Login
Use case number 1
Use case description To login in to the user account.
Participating Actor Administrator, Student, Teacher , Recorder
Pre-condition The users have their valid username and password.
Flow of events - The system is a login link when users click the link.
- The user inserts username and password.
- The system checks the username and password whether it is
valid or not.
27
- The system allows the user to login into the system.
- If the user insert invalid username and password, the system
display an error message and allows trying again.
Post condition The user successfully login into the system.
Alternative flow of If the user forget or want to change username or password the
events system allows them to change the username or password by
asking same security questions.
Table 3 login
Description 2
use case name Insert mark
use case number 2
Use case description To insert mark of student
Participating Actor Teacher
Pre-condition Teacher login in the system.
Flow of events He/she clicks on “insert mark” link from HSSIMS home page.
The System displays the form.
Teacher fills the form properly and clicks on insert button.
The system displays the inserted mark.
Post condition The system display successful inserted message.
Alternative flow of If there is a mistake in the data entry the system displays error
events message and it allows making correction.
Table 4 Inserted Mark
Description 3
28
use case name Generate report
use case number 3
use case description To prepare student report.
Participating Actor Record worker
Pre-condition Record worker login into system.
Flow of events He/she clicks on “prepare student report” link from the
HSSIMS home page.
The System displays the student report form.
He/she fills the form properly and clicks on generate button.
The system generates the student report.
Post condition The system display successful message.
Alternative flow of If there is a mistake in the data entry the system displays
events error message and it allows to him to make correction.
Table 5 Prepare student report
Description 4
use case name create account
use case number 4
Use case description To create new account to the user
Participating Actor Administrator
Pre-condition Administrator login in to the system.

Registrar officer has full information about authorized user
(full name, id, e-mail).
Flow of events  Administrator clicks on the create account button.
29
 The system displays the create account form.
 He/she fills the form and click on create button.
 The system generates new user account with
username and password.
Post condition The system display successful message.
Alternative flow of If there is a mistake in the data entry, the system displays
events error message and it allows to the user to make correction.
Table 6 create account
Description 5
use case name View status
use case number 5
use case description Student’s look information.
Participating Actor Student’s
Pre-condition Student’s login into the system.
Flow of events  The user clicks on view status link from the HSSIMS
home page.
 The System displays view status form.
 `The user fills the form properly and clicks on view
button.
Post condition  The System displays the user’s status.
Alternative flow of If there is a mistake in the data entry, the system displays
events error message and it allows to the user to make correction.
Table 7 View status
Description 6
use case name View Report

30
use case number 6
use case description To view report to the user.
Participating Actor Administrator
Pre-condition The user login into the system.
Flow of events  The user clicks on the “view report information” link
from the HSSIMS home page.
 The System displays search options (module code)
 The user searches the module using module code.
 The system displays the searched module.
 The user selects that module.
 The system displays the full module information.
Post condition The user views the module information.
Alternative flow of If there is a mistake in the searching module case, the system
events displays error message and it allows to the user to make
correction.
Table 8 View Submit Mark
Description 7
use case name Register
use case number 7
use case description To register active students.
Participating Actor Student
Pre-condition Student logs in to the system.
Flow of events  Student clicks on the Register button.
31
 The system displays the registration form
 Student fills registration data and click on Register
button.
Post condition  The system displays successfully registered message.
Alternative flow of If the input data has error the system display error message &
events allow to try again
Table 9 Register
Description 8
use case name Modify account
use case number 8
use case description To modify user account in the system.
Participating Actor Administrator, Recorder, Teacher
Pre-condition Administrator, Recorder, Teacher login into the system.
Flow of events  Administrator clicks on modify account link from the home
page of the HSSIMS.
 Administrator, Recorder, Teacher clicks on search user
account button.
 The System displays search options (by ID).
 Administrator searches using one search method.
 The system displays the user’s profile.
 -Administrator, Recorder, Teacher clicks on the update
button to modify account.
Post condition The system modify successfully.
Alternative flow of If there is a mistake in the data entry the system displays error
events message and it allows making correction.
Table 10 Modify account

32
Description 9
Use case name Delete Account
Use case number 9
Use case Description To delete Account of user in the system
Participating actor Administrator
Pre-condition Administrator should login and the entry should be within the
database
Flow of event
 Administrator clicks on delete account link from the
home page of the HSSIMS.
 Administrator clicks on search user account button.
 Administrator searches using one search method.
 The system displays the user’s profile.
1. Administrator clicks on the delete button to delete account.
Alternate flow of event The system display error message when some information is
missed and it must be corrected.
Post-condition If the activity was successful, account information is deleted
from the system. Otherwise, the system state is unchanged
Table 11 Delete Account
Description 10
Use case name Delete Mark
Use case number 10
33
Use case Description To delete mark of student in the system
Participating actor Teacher
Pre-condition Teachers should login and the entry should be within the
database
Flow of event
 Teacher clicks on delete mark link from the home
page of the HSSIMS.
 Teacher clicks on search user account button.
 Teacher searches using one search method.
 The system displays the user’s Mark.
2. Teacher clicks on the delete button to delete mark of student.
Alternate flow of event The system display error message when some information is
missed and it must be corrected.
Post-condition If the activity was successful, mark of student is deleted from
the system. Otherwise, the system state is unchanged
Table 12 Delete Mark
3.10 Class/objects
3.10.1 Class diagrams

Conceptual models are used to depict the detailed understanding of the problem space for the
system. Class models show the classes of the system, their interrelationship (associations and
multiplicity) among classes, the operations and attributes of the classes. It shows the classes of
the system and their interaction which are typically used to
 Explore domain concept
 Analyze requirement in the form of conceptual analyses model
A class diagram is typically modeled rectangles with three-section:
34
 The top one indicates the name of the class
 the middle one lists the attributes of the class and
 The third one lists the methods. By including those 3 sections class name, an attribute and a
method box in the class we are arguably making design decisions in the model.
35
Fig 3.1 class Diagram
3.11 Dynamic models
3.11.1 Sequence diagram

A sequence diagram in a Unified Modeling Language (UML) is a kind of interaction diagram
that shows how processes operate with one another and in what order. It is a construct of a
Message Sequence Chart. A sequence diagram shows object interactions arranged in time
sequence. It depicts the objects and classes involved in the scenario and the sequence of
messages exchanged between the objects needed to carry out the functionality of the scenario.
Sequence diagrams typically (but not always), are associated with use case realizations in the
Logical View of the system under development.
It shows, as parallel vertical lines (lifelines), different processes or objects that live
simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in
which they occur. This allows the specification of simple runtime scenarios in a graphical
manner.
36
3.12 Analysis Model
3.12.1 Sequence diagram
EAsd12.0
createUnregistered
account Trial Version EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Version EA 12.0
EA 12.0 UnregisteredHSSIMS
Trial VersionAccount
EA 12.0 Unregistered
creation
button
Trial Version
Account creation
form
Account controller Database server
Trial Version EA 12.0
Administrator
EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Version EA 12.0
login()
click create account button()
initiate form()
:view form
fill form()
activated()
:validated filled data
EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Version EA 12.0 Unregistered
check for redendancy() Trial Version EA 12.0
save()
:return state
successfull message()
EA 12.0 Unregistered Trial Version EA 12.0 Unregistered

37 Trial Version EA 12.0 Unregistered Trial Version EA 12.0
Fig 3.2 Sequence diagram for account creation
EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Version EA 12.0 U
sd insert,update and delete
Insert mark
Trial Version EA
Update Mark
12.0 Unregistered
Delete Mark Submit Mark
Trial Version
Form
EA Controller
12.0 Unregistered Trial Version EA 12.0 U
Database
Teacher
click()
show()
click()
show()
click()
show()
EA 12.0 Unregistered Trial Version

Fill
form
EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Version EA 12.0 U
()
validate()
store()
EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Version EA 12.0 Unregistered
:success
Trial Version EA 12.0 U
:successfull
Fig 3.3 sequence diagram for Insert, Update and Delete Mark
3.13 Activities Diagram
An activity diagram describes a system in terms of activities. Activities are states that represent
the execution of a set of operations. The completion of these operations triggers a transition to
another activity. Activity diagrams are similar to flowchart diagrams in that they can be used to
EA 12.0
represent Unregistered
control Trial the
flow (i.e., Version
orderEA
in 12.0
whichUnregistered
operationsTrial Version
occur) EA 12.0
and data Unregistered
flow Trial Version EA 12.0 U
(i.e., the objects
that EA
are12.0
exchanged among
Unregistered operations).
Trial Version EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Version EA 12.0 U
38
Fig 3.4 Activity Diagram
39
Chapter Four
4. System Design
4.1 Design overview

The design phase include deployment diagram in order to indicate how the system would
perform. At this phase the security policy and concurrency policies are also take in to care along
with design goal. In general the system design phase has needed a great focus.
Design Goals
The design goals stated for the system defines the qualities that the system should incorporate.
Most of these design goals are the refinements of the non-functional requirements identified
during requirement gathering, and some of the design goals may not state explicitly in the
requirements specification. However, if the system is to be efficient, these design goals need to
be incorporated.
 The system should be secured.

 The system should be easy to use.
 Ease of access to the required data.
 The database should maintain data normalization by implementing a primary and
foreign key system so that do not occur duplication within the data.
4.2 Security Policy

The Student must first obtain a user name and password from their administrator, and then use it
to log in to the system. The servers will be deployed behind an Internet firewall so that external
access can be tightly controlled.
4.3 Software Architecture

The architecture of the system is based on the three-tier architecture. There are three logical
layers: the Presentation Tier, the Business Tier, and the Data Tier.
PRESENTATION TIER
MIDDLE TIER
DATA TIER
40
Figure 4.1.Shows the three-tier architecture of the Registrar Web Application.
In presentation tier user interfaces are placed on the middle tier business models and rules are
applied and in the data tier database schemas are placed and retrieved by different sql queries
when needed.
4.4 Deployment Modeling

This shows how and where the system is to be deployed. Physical machines and processors are
reflected as nodes, and the internal construction can be depicted by embedding nodes or artifacts.
As artifacts are allocated to nodes to model the system's deployment, the allocation is guided by
the use of deployment specifications. The developed system deploys as follow:
Figure 4.2: deployment diagram
41
4.5 Database Design
The solution that we have given to Gimbi comprehensive high school Registrar System to solve
the listed problems are web application, so based on this we have implemented the PHP
programming language and for database MYSQL. So the following physical database design are
implemented using MYSQL Relational Database Management System
rooster user
enrollment stud_id
stud_id user_id
section_id
section_id user_name
Sem
Ac_year password
Ac_year
status role
Afan_oromo
Remark
Amharic
English
Maths
Physics
course
course_no
course_title
ministry
reg_no
sid
Ac_year
school_name student
zone stud_id
Average sname
sex
mark_list
Persentile
sid
status age
course_no
zone
Ac_year
woreda
section_id
sem
test1
test2
test3
mid
final
total
Fig 4.3 Database Design Diagram
42
Fig 4.4 State Chart Diagram
4.6 User Interface Design

1. As it has been clearly stated, the High school student registrar system which developed
has a graphical user interface which helps the user to deal with the system easily.
43
Fig 4.5 user interface design
4.7Physical schemas:
Table 4.1: Student Table
Attribute Name Data Type Max Description Allow Default Constraint

Length Null value
Sid Varchar 10 No Primary
Key
Sname Varchar 50 No
Sex Varchar 15 No
Age Int 6 No
Zone Varchar 50 No
Woreda Varchar 20 No
Kebele Varchar 20 No
Parent_name Varchar 20 No
Address Varchar 20 No
Phone_no int No
44
Table 4.2: User Table
Attribute Data Type Max Description Allow Null Default Constraint

Name Length value
UId varchar 15 No PRIMARY
KEY
Uname varchar 15 No
Password varchar 25 No
Role varchar 10
Table 4.3: Enrollment Table
Attribute Name Data Type Max Description Allow Default Constraint

Length Null value
Sid Int 6 No Foreign
key
Section_id Int 10 No Primary
Key
Acadamic_year int No
Status Varchar 15 No
Remark Varchar 15 No
Table 4.4: Mark list Table
Attribute Data Type Max Description Allow Null Default Constraint

Name Length value
Sid Int 6 No Primary
Key
Cno Int 10 No Foreign
Key
Test1 Varchar 30 No
Test2 Varchar 10 No
Test3 Varchar 10 No
Mid Int 10 No
Final Int 10 No
Total Int
Semister Int
Table 4.5: Rooster Table
Attribute Name Data Max Description Allow Default Constraint

Type Length Null value
SID Int 5 NO
Section_ID Int 5 NO
Acadamic_year Int 5 NO
Semister Int 5 NO Primary
Key
45
Afan Oromo Int 5 NO
English Int 5 NO
Maths Int 5 NO
Physics Int 5 NO
Chemistry Int 5 NO
Biology Int 5 NO
Civic Int 5 NO
IT Int 5 NO
Amharic Int 5 NO
Physical_Edu Int 5 NO
Geography Int 5 NO
History Int 5 NO
Total Int 10 NO
Average Int 10 NO
Rank Int 10 NO
Table 4.6: Course Table
Attribute Data Max Description Allow Null Default Constraint

Name Type Length value
Cno Int 15 No Primary
Key
Ctitle varchar 15 No
Table 4.7: Ministry Table
Attribute Data Type Max Description Allow Default Constraint

Name Length Null value
Reg_no Int 20 NO Primary
Key
Sid Int 10 NO Foreign
key
Ac_year Int 5 NO
School_name varchar 10 NO
Zone varchar 10 NO
Average Int 5 NO
Persentile Int 5 NO
Status varchar 10 NO
46
SQL Code That Generates the Above Table Structures
Create Database ‘gchs’;
CREATE TABLE [dbo].[course](

[course_no] [nvarchar](255) NOT NULL,
[course_title] [nvarchar](255) NULL,
CREATE TABLE [dbo].[enrollment](

[stud_id] [int] NULL,
[section_id] [nvarchar](255) NOT NULL,
[Ac_year] [int] NULL,
[status] [nvarchar](255) NULL,
[Remark] [nvarchar](255) NULL,
CREATE TABLE [dbo].[mark_list](

[sid] [int] NOT NULL,
[course_no] [nvarchar](255) NOT NULL,
[Ac_year] [int] NOT NULL,
[sem] [int] NOT NULL,
[test1] [int] NULL,
[test2] [int] NULL,
[test3] [int] NULL,
[mid] [int] NULL,
[final] [int] NULL,
[total] [int] NULL,
CREATE TABLE [dbo].[ministry](

[reg_no] [int] NOT NULL,
[sid] [int] NULL,
[Ac_year] [int] NULL,
[school_name] [nvarchar](255) NULL,
[zone] [nvarchar](255) NULL,
[Average] [int] NULL,
[Persentile] [int] NULL,
[status] [nvarchar](255) NULL,
CREATE TABLE [dbo].[rooster](

[stud_id] [int] NOT NULL,
[Sem] [int] NOT NULL,
[Ac_year] [int] NOT NULL,
[Afan_oromo] [int] NULL,
[Amharic] [int] NULL,
[English] [int] NULL,
[Maths] [int] NULL,
[Physics] [int] NULL,
47
[Chemistry] [int] NULL,
[Biology] [int] NULL,
[Civic] [int] NULL,
[IT] [int] NULL,
[Geography] [int] NULL,
[History] [int] NULL,
[Physical_edu] [int] NULL,
[total] [int] NULL,
[Average] [int] NULL,
[Rank] [int] NULL,
CREATE TABLE [dbo].[student](

[stud_id] [int] NOT NULL,
[sname] [nvarchar](255) NULL,
[sex] [nvarchar](255) NULL,
[age] [int] NULL,
[zone] [nvarchar](255) NULL,
[woreda] [nvarchar](255) NULL,
[kebele] [int] NULL,
[pname] [nvarchar](255) NULL,
[address] [nvarchar](255) NULL,
[phone_no] [int] NULL,
CREATE TABLE [dbo].[user](

[user_id] [int] NOT NULL,
[user_name] [nvarchar](255) NULL,
[password] [nvarchar](255) NULL,
[role] [nvarchar](255) NULL
 Conclusion
As we describe above this system is mainly focus on the Gimbi comprehensive high school web
based service. The main cause that initiates us to develop this system is the necessity of the
system for the high school to perform their work effectively and efficiently. High school student
information management System is capable to be used in the organization through internet (local
internet) for the success of activity for its member client and other users that need service from
this organization. The system also the capacity of the expansion is increased highly interims of
the benefit of the organization.
 REFERENCES
Test Planning, http://www.vietnamesetestingboard.org
C. Kaner, J. Bach, and B. Pettichord, Lessons Learned in Software Testing: John Wiley
& Sons, 2002.
Object primer Agile Modeling: Scot W. Ambler
48
www.codeproject.com
www.w3schools.com
49

Edited Project1111

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Edited Project1111

Uploaded by

Copyright:

Available Formats

Contents

Gimbi comprehensive high school Student information management System;

CD: Compact Disc

Ministry of Education Bureau

Oromia Regional state Edu.Bureau

West Wollega zone edu .office

Vice Director GCH

Education process Finance office Administrative office

1.3 Statement of the problem

1.4.1 General Objective

1.4.2 Specific Objectives

1.5 Scope of the project

1.6 Limitation of the project

 Online registration of Evening class

1.7.1 Data Collection methods

1.9 Significance of the project

 Information resources can be searched easily.

1.10 Feasibility study

1.11 Beneficiaries of the project

1.12 Implementation and programming tools

Role Description Assigned To

Programming Writing a code and design the system Mengistu Mekonen

Tester The key responsibility will be for coordinating the

Table 1.1 Roles and responsibilities table

1.14 Constraints and Assumptions

1.15.1 Resource plan

1.15.2 Beget plan (project cost)

Number Name Amount Unit price Total price

1 Printing paper 4 packet 100.00 400.00

2 CD-RW 2 16.00 32.00

3 Purchasing of different 5 200.00 1000.00

5 Miscellaneous expenses - - 1000.00

Total - - - 3512 birr

Table 1.2.budget distribution

2.1Study of the existing system

2.4 Users of the Existing System

 Registrar officer (vice director) responsible for:

2.5 Problems of the Current System

2.6 Forms used in Current system

3.1 Proposed system/New System

3.2 Overview of new system

 Good understanding on the data  High in technical retrieving and

3.5 General Constraints

3.6 Hardware and software consideration

3.4 Non-functional requirements

3.8.1 User interface

3.9 Use case model

3.9.1 Actors identification

3.9.2 Use Case identification

Name of use case: create account

Participating instance actor: Administrator

1. He/she login to the system by using his/her account.

Name of use case: login

Participating instance actor: Student, Recorder, Administrator, Teacher

1. The users have valid username and password.

Name of use case: Student Registration

Participating instance actor: Recorder

1. He/she clicks on the Registration link from the Recorder page.

Exit condition: The system saves his record.

Name of use case: Modify Account

Participating actor: Administrator, Teacher, Recorder

Entry condition: He/she logs in to the system using his/her account.

Exit condition: The user account is modified successfully.

Name of use case: Generate report