High School SIMS Second Semister

Table of Contents
Contents…………………………………………………………………………………….….I
Acknowledgement.................................................................................................................................IV
Abstract…………………………………………………………………………………………………………………………………………….V
Abbreviations.......................................................................................................................................VI
Chapter one...........................................................................................................................................1
1 Introduction...................................................................................................................................1
1.1 Background of the organization.............................................................................................1
1.2 Organizational Structure........................................................................................................2
1.3 Statement of the problem.......................................................................................................2
1.4 Objectives..............................................................................................................................3
1.4.1 General Objective..........................................................................................................3
1.4.2 Specific Objectives........................................................................................................3
1.5 Scope of the project...............................................................................................................3
1.6 Limitation of the project........................................................................................................4
1.7 Methodology..........................................................................................................................4
1.7.1 Data Collection methods................................................................................................4
1.8 System analysis and design methodology..............................................................................5
1.9 Significance of the project.....................................................................................................5
1.10 Feasibility study.....................................................................................................................5
1.11 Beneficiaries of the project....................................................................................................6
1.12 Implementation and programming tools................................................................................6
1.13 Team members roles & responsibly.......................................................................................7
1.14 Constraints and Assumptions.................................................................................................8
1.15 Plan........................................................................................................................................8
1.15.1 Resource plan.................................................................................................................8
1.15.2 Beget plan (project cost)................................................................................................8
Chapter Two........................................................................................................................................10
2.1 Study of the existing system....................................................................................................10
2.1.1 Introduction.........................................................................................................................10
2.2 Overview of the existing system..........................................................................................10
2.4 Users of the Existing System...............................................................................................11
I
2.5 Problems of the Current System..........................................................................................11
2.6 Forms used in Current system..............................................................................................12
Chapter Three......................................................................................................................................13
3.1 Proposed system/New System.................................................................................................13
3.2 Overview of new system..........................................................................................................13
3.3 Product functions.............................................................................................................13
3.4 User characteristics..........................................................................................................13
3.5 General Constraints..............................................................................................................14
Constraints...................................................................................................................................14
Assumption & dependencies...........................................................................................................15
3.6 Hardware and software consideration..............................................................................15
3.7 Functional requirements.......................................................................................................16
3.4 Non-functional requirements...............................................................................................16
3.8.1 User interface...............................................................................................................16
3.9 Use case model....................................................................................................................17
Use case diagram.............................................................................................................................19
Description of Use Case models..................................................................................................27
3.10 Class/objects........................................................................................................................33
3.10.1 Class diagrams.............................................................................................................33
3.11 Dynamic models..................................................................................................................35
3.11.1 Sequence diagram........................................................................................................35
3.12 Analysis Model....................................................................................................................36
3.12.1 Sequence diagram........................................................................................................36
3.13 Activities Diagram...........................................................................................................37
Chapter Four........................................................................................................................................39
4. System Design.............................................................................................................................39
4.1 Design overview..................................................................................................................39
4.2 Security Policy.....................................................................................................................39
4.3 Software Architecture..........................................................................................................39
4.4 Deployment Modeling.........................................................................................................41
4.5 Database Design..................................................................................................................42
Fig 4.3 Database Design Diagram...................................................................................................43
4.6 User Interface Design..........................................................................................................44
4.7 Physical schemas:............................................................................................................45
II
SQL Code That Generates the Above Table Structures...............................................................48
 Conclusion...................................................................................................................................51
III
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 thanks
to Ato Abebe Desalegn Director of organization who gave us necessary resource and information
about their 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.
IV
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.
V
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
GCHS: Gimbi Comprehensive High School
VI
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.
 Update mark of student and subject name

 Determine status rank
 Add mark of student
 Compute average of the mark
3
 Generating report
 Preparation of Transcript and Roster
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
 Online registration of Evening class
 Online fees
 Class schedules
 Online exam
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 xampp 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
7
1.14 Constraints and Assumptions
1. Constraints
 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
 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 xampp 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 120.00 480.00
2 CD-RW 2 16.00 32.00
8
3 Purchasing of different 5 200.00 1000.00
software & hardware
4 Purchasing of flash disk 6 piece 180.00 1080.00
5 Miscellaneous expenses - - 1000.00
Total - - - 3592 birr
Table 1.2.budget distribution
9
Chapter Two
2.1 Study 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;
Oromia TVET Agency
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
Cluster subject. Using the observation the team members proposed it will be good if
of Nekemte
automated system is done for such activities.
Board
2.2ofOverview
Limu TVETof the existing system
Gimbi Comprehensive high school registration system focuses on student registration, updating
subjectDean
name,
of modifying
TVET student records prepare transcript and roster 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, deleting, updating students record; and generating a report is
a tedious and a time consuming task.
Training process Finance office Administrative office
2.3 Major Functions of the current system
 Functionalities
 Register students mark list.
 Register existing student (Registration).
Registrar Library
 Generating report
 Update mark of student and subject name.
 Major activities
o Registering new students
 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.
10
 The registrar workers check whether they are valid or not.
 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.
 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.
 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.
 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.
11
 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 Transcript form.
 Consolidated mark list form (Roster)
 Student registration form.
 Student’s mark list form.
 Section Registration Form
 Subject Registration 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.3 Product functions

The registration system has the following functionalities:
 Registering students.
 Inserting students mark
 Updating students mark
 Preparing mark list
 Preparing Roster
 Preparing Section and Grade.
 Generating report
13
3.4 User characteristics
User classes User Characteristics Technical skills

 Good understanding of HSSIMS  Ability Use different system from
Director operations. past.
 Responsible for the whole  Have basic knowledge of using the
operations. system in a networked environment
 Good understanding on the data  Experience in how to manage the
recording system. overall system.
 Medium of language for  High in technical retrieving and
communication with system recording of information.
(English)  Have basic knowledge in database.
 The Director needs to understand  Basic computer skill and
the information found in user  know how to use the system
interface.
 Good understanding on the data
recording system.
 Good knowledge how to retrieve
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
Assumption & dependencies
 There is a practice and method of taking backup.
14
 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
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
15
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. Reports: The systems generate different kinds of report like Roster, Student transcript
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
3. 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
4. Compute Rank: the system allows to calculate average and rank of student’s
5. 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.
 Since the system performs data validation mechanism while entering the data
that makes data consistency.
16
 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:
 Director
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 and submit mark
 Modify account
 View report
 Approve mark
 Student registration
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
17
 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
uc usecase
EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Versi
Director
EA 12.0 Unregistered Trial Version EA
High12.0 Unregistered
school student Trial Version
information management system EA 12.0 Unregistered Trial Versi
modifyaccount computeav erage
EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Version«extend»
approv emark EA 12.0 Unregistered Trial Versi
v iew report
deleteaccount computerank
EA 12.0 Administrator
Unregistered Trial Version EA
createaccount
12.0 Unregistered Trial Version EA
«include» 12.0
v iew mark Unregistered Trial Versi
«include»
«include»
«include» «include»
EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Version EA 12.0 Unregistered
Student Trial Versi
«include»
«include»
register
EA 12.0 Unregistered Trial Version EA 12.0 Unregistered
login
Trial Version EA 12.0 Unregistered Trial Versi
«include»
insertmark
«include»
«include»
EA 12.0 Unregistered Trial Version EA

updatemark
12.0 Unregistered Trial
«include» Version EA 12.0 Unregistered Trial Versi
«include»
«include»
EA 12.0 Unregistered
Teacher Trial Version EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Versi
generatereport
submitmark
EA 12.0 Unregistered Trial Version EA 12.0 Unregistered
modifyaccount
Trial Version EA 12.0 Unregistered Trial Versi
Recorder
Use case diagram
Scenario
Scenario 1
19
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.
Scenario 2
Name of use case: login
Participating instance actor: Director
Entry condition:
1. The users have valid username and password.

2. The users also have the URL (web site) of HSSIMS.
Flow of events:
20
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 home 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 power should not be down.
Scenario 3
Name of use case: Student Registration
Participating instance actor:
Entry condition: He/she logs in to the system using his user name and password.
Flow of events:
1. He/she clicks on the Student link from the Director page.

2. The system displays Add Student links.
3. He/she fills the form and click on Add 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.
21
Special requirement: when he performs this task power 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.
Scenario 5
Name of use case: Generate report
Participating actor: Director
Flow of events:
1. He/she clicks on “print” link from the HSSIMS home page.

2. The System displays the Report form.
22
3. He/she fills the form properly and clicks on print 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:
him to make correction.
Exit condition: The Student report displayed successfully.
Scenario 7
Name of use case: View status
Participating actor: Student.
23
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
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:
24
Exit condition: The Student mark is modified successfully.
Scenario 9
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 10
Name of use case: Delete Account
Flow of events:
1. He/she clicks on Delete account link from the Administrator page.

3. He/she type the user’s account ID.
25
4. He clicks on the delete button to delete account.
Alternate Case:
Exit condition: The user account is deleted successfully.
Scenario 11
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 12
Name of use case: Insert Mark
26
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.
- 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
27
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
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.
28
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.
 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
29
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

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
30
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.
 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.
31
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
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.
 The System displays search options (by ID).
 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
32
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:
 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.
Fig 3.1 class Diagram
33
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
34
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.
35
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
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
check for redendancy() Trial Version EA 12.0
save()
:return state
successfull message()
Fig 3.2 Sequence diagram for account creation
36
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()
: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
represent control flow (i.e., the order in which operations occur) and data flow (i.e., the objects
that are exchanged among operations).
37
Fig 3.4 Activity Diagram
38
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.
39
PRESENTATION TIER
MIDDLE TIER
DATA TIER
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.
Fig 4.2 Component Diagram
Component diagram illustrates the different pieces or components that make up the Gimbi high
school student information management system
40
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:
41
Figure 4.2: deployment diagram
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
42
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
43
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.
44
Fig 4.5 user interface design
4.7 Physical 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
45
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 Max Description Allow Default Constraint

Type 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
46
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
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
47
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 Max Description Allow Default Constraint

Name Type 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
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,
48
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,
49
[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,
[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,
50
[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
www.codeproject.com
www.w3schools.com
51

High School SIMS Second Semister

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

High School SIMS Second Semister

Uploaded by

Copyright:

Available Formats

Table of Contents

Gimbi comprehensive high school Student information management System;

1. Background of the organization

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

 Update mark of student and subject name

1.6 Limitation of the project

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.15.1 Resource plan

1.15.2 Beget plan (project cost)

Number Name Amount Unit price Total price

1 Printing paper 4 packet 120.00 480.00

2 CD-RW 2 16.00 32.00

4 Purchasing of flash disk 6 piece 180.00 1080.00

5 Miscellaneous expenses - - 1000.00

Total - - - 3592 birr

Table 1.2.budget distribution

2.1 Study 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

3.3 Product functions

User classes User Characteristics Technical skills

3.5 General Constraints

 Students should not be allowed making any changes to the database.

Assumption & dependencies

 There is a practice and method of taking backup.

3.6 Hardware and software consideration

3.7 Functional requirements

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

3.9.3 Use Case Diagram

EA 12.0 Unregistered Trial Version EA

Participating instance actor: Administrator

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

Name of use case: login

Participating instance actor: Director

1. The users have valid username and password.

Name of use case: Student Registration

Participating instance actor:

1. He/she clicks on the Student link from the Director page.

Exit condition: The system saves his record.