WOLKITE UNIVERSITY

COLLEGE OF COMPUTING AND INFORMATICS

DEPARTMENT OF SOFTWARE ENGINERING
RAS ZESELLASIE SCHOOL MANAGEMENT SYSTEM
BY
NAME ID

Alemayehu Bogale CIR/038/06

Solomon Bekele CIR/329/06

Mekonin Aklilu CIR/233/06

Lemi Tasew CIR/215/06

UNDER GUIDANCE OF
Ermiyas Birihanu Belachaw (MSc)

February 24, 2017

 WOLKITE UNIVERSITY
COLLEGE OF COMPUTING AND INFORMATICS
DEPARTMENT OF SOFTWARE ENGINEERING
RASZESELLSIE SCHOOL MANAGEMENT SYSTEM
SUBMITED TO DEPARTMENT OF SOFTWARE ENGINERING

IN PARTIAL FULFILMENT OF THE REQUIREMENT FOR

THE DEGREE OF BACHLER OF SCIENCE IN SOFTWARE ENGNEERING

BY
Name Id

Alemayehu Bogale CIR/038/06

Solomon Bekele CIR/329/06

Mekonin Aklilu CIR/233/06

Lemi Tasew CIR/215/06

WOLKITE UNIVERSITY, WOLKITE, ETHIOPIA

February 24, 2017

i
Approval Form
This is to confirm that the project report entitled Ras ZeSellasie School management system
submitted to Wolkite University, College of Computing and Informatics department of Software
Engineering in partial fulfilment of the requirement for the award of the degree of Bachler of
Science in Software Engineering is an original work carried out by Alemayehu Bogale, Solomon
Bekele, Mekonin Aklilu and Lemi Tasew under my guidance. The matter embodied in this
project is reliable and is genuine work done by the student and has not been submitted whether to
this University or to any other University/Institute for the fulfilment of the requirement of any
study.

Student Team Approval Form

Student name Student Signature

Alemayehu Bogale ______________________

Solomon Bekele ______________________

Mekonin Aklilu _______________________

Lemi Tasew ________________________

Advisor and Department Head Approval form

Advisor name Advisor Signature

Ermiyas Birihanu Belachaw (MSc)

Department head Name Department head Signature

Joseph Wondwosen ____________________

Examiners Approval form

Examiner Name Examiner Signature

______________________ _______________________

______________________ _________________________

______________________ __________________________

ii
Acknowledgements
First of all we would like to thank GOD keeping us healthy to do this project. Next thanks to
our advisor Mr. Ermiyas Birihanu for his advising, guiding and gives necessary comments until
the completion of the documentation of the project. And also we would like to say thanks
Department officer Joseph Wondwosen for his support and adjusting different facilities for the
development of this project documentation. Deeply we would like to say thanks for Wolkite Ras
ZeSellasie School Director Sisay Desu Kiraga for giving us full information about how the
current system work. Finally thanks to group members and other peoples who support us for our
project document completion.

iii
Table of Contents
Approval Form .............................................................................................................................................. ii
Acknowledgements ...................................................................................................................................... iii
List of figure ............................................................................................................................................... vii
List of table ................................................................................................................................................ viii
Abbreviations ............................................................................................................................................... ix
Abstract ......................................................................................................................................................... x
CHAPTER ONE ........................................................................................................................................... 1
1. INTRODUCTION OF WHOLE PROJECT PROCESS ....................................................................... 1
1.1. Introduction ................................................................................................................................... 1
1.2. Background of Organization ......................................................................................................... 1
1.3. Background of the project ............................................................................................................. 2
1.4. Statement of the problem .............................................................................................................. 2
1.5. Objective of the Project................................................................................................................. 3
1.5.1. General Objective ................................................................................................................. 3
1.5.2. Specific objective................................................................................................................... 3
1.6. Feasibility of the Project ............................................................................................................... 3
1.6.1. Operational Feasibility ......................................................................................................... 3
1.6.2. Technical feasibility .............................................................................................................. 4
1.6.3. Economic feasibility .............................................................................................................. 4
1.6.4. Political feasibility ................................................................................................................ 5
1.6.5. Schedule feasibility ............................................................................................................... 5
1.7. Scope of the project ...................................................................................................................... 5
1.8. Significant of the Project............................................................................................................... 6
1.9. Target beneficiary of the project ................................................................................................... 6
1.10. Methodology ............................................................................................................................. 6
1.10.1. Method of data collection ..................................................................................................... 6
1.10.2. System development methodology ......................................................................................... 7
1.10.3. Development Tools ................................................................................................................ 7
1.11. Systems Analysis and Design Approach................................................................................... 8
1.11.1. Limitation of the project ........................................................................................................ 8
1.11.2. Risks & contingencies ........................................................................................................... 8

iv
 1.11.3. Assumptions and constraints ................................................................................................. 8
1.12. Team Decomposition ................................................................................................................ 9
1.13. Project Schedule...................................................................................................................... 10
CHAPTER TWO ........................................................................................................................................ 11
2. DESCRIPTION OF THE EXISTING SYSTEM ................................................................................ 11
2.1. Introduction ................................................................................................................................. 11
2.2. Overview of current system ........................................................................................................ 11
2.3. Organization structure ................................................................................................................. 12
2.4. Users of Current system .............................................................................................................. 13
2.5. Major functions of the Current System ....................................................................................... 13
2.6. Existing System Workflow structure .......................................................................................... 14
2.7. Reports Generated in the existing System .................................................................................. 15
2.8. Forms and other documents of current system ........................................................................... 16
2.9. Bottlenecks of the existing system .............................................................................................. 16
2.9.1. Performance ........................................................................................................................ 16
2.9.2. Input and Output ................................................................................................................. 17
2.9.3. Security and Controls.......................................................................................................... 17
2.9.4. Efficiency............................................................................................................................. 17
CHAPTER THREE .................................................................................................................................... 18
3. PROPOSED SYSTEM ....................................................................................................................... 18
3.1. Introduction ................................................................................................................................. 18
3.2. Product Overview ....................................................................................................................... 18
3.3. User Classes and Characters ....................................................................................................... 20
3.4. Functional Requirements ............................................................................................................ 20
3.5. Non Functional Requirements .................................................................................................... 21
CHAPTER FOUR:...................................................................................................................................... 23
4. SYSTEM ANALYSIS ........................................................................................................................ 23
4.1. System Models ............................................................................................................................ 23
4.1.1. Use Case model................................................................................................................... 23
4.1.2. Use Case Description.......................................................................................................... 25
4.1.3. Scenario .............................................................................................................................. 39
4.2. Object model ............................................................................................................................... 41

v
 4.2.1. Data dictionary ................................................................................................................... 41
4.2.2. Analysis level class diagram ............................................................................................... 45
4.3. Dynamic Model .......................................................................................................................... 47
4.3.1. Sequence Diagram .............................................................................................................. 47
4.3.2. Activity Diagram ................................................................................................................. 56
4.3.3. State Diagrams.................................................................................................................... 59
CHAPTER FIVE ........................................................................................................................................ 63
5. System Design .................................................................................................................................... 63
5.1. System Overview ........................................................................................................................ 63
5.2. Design Considerations ................................................................................................................ 63
5.2.1. Design Goals ........................................................................................................................... 63
5.2.2. Design Trade-offs.................................................................................................................... 65
5.3. Architecture of the System.......................................................................................................... 66
5.4. Subsystem Decomposition .......................................................................................................... 68
5.5. Hardware/Software mapping ...................................................................................................... 70
5.6. Persistent data management ........................................................................................................ 71
5.7. User interface design................................................................................................................... 72
5.8. Object Design.............................................................................................................................. 74
5.8.1. Interface documentation guidelines .................................................................................... 74
5.8.2. Class interfaces ................................................................................................................... 76
Appendix ..................................................................................................................................................... 79
References ................................................................................................................................................... 83

vi
List of figure
Figure 2.1: Organization Structure ............................................................................................... 12
Figure 2.2: existing system Work flow structure diagram ............................................................ 15
Figure 3.1: Product overview ........................................................................................................ 19
Figure 4.1: use case model ............................................................................................................ 24
Figure 4.2: Class diagram ............................................................................................................. 46
Figure 4.3: Registration sequence diagram ................................................................................... 47
Figure 4.4: Account sequence diagram ......................................................................................... 48
Figure 4.5: Login sequence Diagram ............................................................................................ 49
Figure 4.6: Attendance sequence diagram .................................................................................... 49
Figure 4.7: Timetable Sequence Diagram .................................................................................... 50
Figure 4.8: Student discipline record sequence diagram .............................................................. 51
Figure 4.9: various report Sequence diagram ............................................................................... 52
Figure 4.10: Resource sequence diagram ..................................................................................... 53
Figure 4.11: View Report sequence diagram ................................................................................ 54
Figure 4.12: Generate grade report sequence diagram ................................................................. 55
Figure 4.13: Admin side activity diagram .................................................................................... 56
Figure 4.14: teacher side activity diagram .................................................................................... 57
Figure 4.15: other user activity diagram ....................................................................................... 58
Figure 4.16: Registration state machine diagram ......................................................................... 59
Figure 4.17: login state machine diagram ..................................................................................... 60
Figure 4.18: Generate various content state diagram.................................................................... 61
Figure 4.19: Attendance record state machine diagram................................................................ 61
Figure 4.20: Resource record state machine diagram ................................................................... 62
Figure 5.1: Architecture diagram of the system............................................................................ 67
Figure 5.2: System decomposition diagram.................................................................................. 70
Figure 5.3: Deployment diagram .................................................................................................. 71
Figure 5.4: Persistent data management ....................................................................................... 72
Figure 5.5: Main Home page User Interface ................................................................................ 73
Figure 5.6: User Home Page User Interface ................................................................................. 74

vii
List of table
Table 1.1: Cost estimation .............................................................................................................. 4
Table 1.2: Team decomposition...................................................................................................... 9
Table 1.3: Project Schedule .......................................................................................................... 10
Table 2.1: User of current system ................................................................................................. 13
Table 3.1: User class and characters ........................................................................................... 20
Table 4.1: Use case description .................................................................................................... 39
Table 4.2: Data dictionary............................................................................................................. 45
Table 5.1: class interface............................................................................................................... 78

viii
Abbreviations
SMS………….. School Management System

HIV…………….Human Immunodeficiency Virus

RSMS…………. Ras ZeSellasie School Management System

CD/DVD……….Compact Disc/ Digital Versatile Disc

OS………………Operating System

XAMPP ………..X (“cross”-platform), Apache HTTP server, MySQL, PHP and Perl

OOSAD…………Object oriented system analysis and design methodology

SDM…………….Software Development Model

PC……………….Personal Computer

UML…………… Unified Modeling Language

MySQL…………My Structured Query Language

PHP……………..Hypertext Preprocessor

CSS……………. Cascading Style Sheets

HTML…………..Hypertext Markup Language

BSC… ………….Bachelor of Science

KG……………… Kindergarten

PIECES………….Performance, Information, Economics, Control, Efficiency and Service

HRM…………….Human Resource Management

SIMS…..student information management system

RDBMS…Relational Database Management System

HTTP…..Hypertext Transfer Protocol

IIS……internet information server

SIM…..Student information management

IT …..Information technology

ix
Abstract
The aim of this industrial project is to develop automated School management system for
Ras ZeSellasie elementary school. The project is web based that develop by PHP at the front end
and MySQL at the back end based on three tire architecture.

The methodology used in this project is Object oriented system analysis and design
methodology and software development model methodology. The system is developed based on
software development life cycle (SDLC) which includes requirement analysis, system analysis,
system design, implementation, testing and maintenance.

The main functionality of the system is student registration, grade report, transcript generating,
report generating, notice posting, attendance recording, timetable and exam schedule generating,
discipline recording and resource managing. The project organized by the chapter. Each chapter
contents the sub contents of the project. The chapters are Introduction of whole project process,
Description of the Existing System, Proposed System, System Analysis, System Design,
Implementation, Testing Plan and Conclusion. Thus, we need to develop RSMS which is a
versatile and complete end-to-end school management software with precision engineered to
enhance the administrative efficiency of educational institutions.

x
 CHAPTER ONE

1. INTRODUCTION OF WHOLE PROJECT PROCESS

1.1. Introduction
Education is the core for development. Education system is the cornerstone of every nation
to be growth. Advanced technology available today can play a crucial role in streamlining
education-related processes to promote solidarity among students, teachers, parents and the
school staff. It is one of the most powerful instruments for reducing poverty and inequality, and
lays a foundation for sustained economic growth. With this aim currently our government has
given special emphasis to the educational sector and school improvement activities such as
continuous professional development for teachers, training and upgrading teachers and
capacitating schools with manpower and materials are among the major actions which have been
taken in both primary and secondary schools. In order to facilitate and simplify these actions one
of the major tool is to have automated school management system. Automation is the utilization
of technology to replace human with a machine that can perform more quickly and more
continuously.
School Management System (SMS) consists of tasks such as registering students, new teachers
and other staffs, producing different reports for teachers, students, taking attendance of students,
exam scheduling, producing class time table and resource managing etc.

1.2. Background of Organization

The Ras ZeSellasie School found in Wolkite town near to commercial bank of Ethiopia. It is
the one of oldest elementary School in Gurage Zone. It started its functionality in 1930 with 3
teachers and 80 students with the help of society. Now the School services above 1791students
and about 50 teachers and other administration staffs. The school covers one-eighth grade and
also consist night students. Last 79 years the number of the student that pass from class to class
and complete their education in this school is increasing year to year. This indicates the
capability of the school growing widely, so teaching and learning system need to be changed in
to automated system.

1
The society participation in this school is very high that helps in different sectaries like fulfilling
facilities that needed for the school rather than government. Discipline committee also selected
from community those gives advice and come to assembly for some decision and judgements.

The school has different clubs like HIV clubs, sport clubs, min media clubs etc.

1.3. Background of the project

The current system of RSMS is a manual file handling System. The main target of the project
is to develop new, automated or computerized system that has the ability to overcome the
problems that occurred in the existing system. The project utilizes some technological resources
that are intended for the development of the new computerized system. These technological
resources help out in solving many of the problems of the existing system. With the new system,
the personnel can achieve the goals of RSMS in working with fast and better environment.

1.4. Statement of the problem

According to the Ras ZeSellasie school mission statement, the school seeks to produce
generation who’s elegant, responsible, and wiser and who trust on hard-working, and also create
intellectual students with a safe, healthy learning environment. Good management and fast data
transfer are one important aspect of that learning environment, since almost all students,
teachers, unit leaders and admin director had spent a lot of their times doing their day-to-day
activities on that environment.

However, The Ras ZeSellasie elementary school uses the manual based management system,
due to this it has the number of problems such as: it takes a lot of man power to do tasks,
resources, time, and space when managing the system, Searching the data from the number of
files which is difficult, data records are stored on papers that may be damage and redundant,
report generation is very weak, and others time table producing, exam scheduling manual that
take resource and time, also the manual file handling system task time when updating student,
teacher and employee information and school resource files.

2
1.5. Objective of the Project
The objective of this project work is presented here under in terms of general and specific
objectives.

1.5.1. General Objective

The general objective of the project is to design and develop automated (computerized)
School management system for Ras ZeSellasie elementary school.

1.5.2. Specific objective

In order to attain the above objective, we listed down the following specific objectives.

 Study and analysis the existing system

 Review related works with school management system
 Design a system that consider the current situation and technologies
 Select and implement the selected timetable algorithm
 Design and develop the new data base system
 Test and evaluate the proposed system.
 Maintain and deploy the final product of the project

1.6. Feasibility of the Project

Feasibility study is used to investigate the proposed system in multiple dimensions. It is used
to indicate whether the system is feasible or not.

The existing system is clearly understood in statement of problem the next step is to conduct
the feasibility study, which is a high level capsule version of the entire System Analysis and
Design process. The objective is to determine whether the proposed system is feasible. The five
tests of feasibility have been carried out:

1.6.1. Operational Feasibility

The system performs all operations to achieve the specified objective, User friendly and
interactive with the environment and the system will perform all operation that the organization
runs. And it will not have any difficulty or procedures to perform the operation of the system. So
the project is operational feasible.

3
 1.6.2. Technical feasibility
Technical feasibility is the measure of practicality of the specific technical support and the
availability of technical resources and expertise to use the system. The proposed system can be
easily maintained and repaired without requiring high Experts or technical supports, because the
system will be installed in adaptable technology’s and the employee of the organization have
some knowledge about technology by providing training and help how to use the system and can
use the system easily . So the system is technically feasible

1.6.3. Economic feasibility

Economic feasibility is the process of identifying the financial benefits and costs associated
with the project being developed. So the project is economically feasible because the project
reduce the cost of the resources. But Economic Feasibility is expressed as cost- benefit analysis.
Costs- our system use new technology and have centralized database cannot need more
resources. It require minimum amount of cost. The estimate cost of resources that we use to
develop this project shown in table 1.1.

Items Tools Quantity Unit price(birr) Total

price(birr)
Hardware Flash disk 1(8gb) 180 180
Cd/DVD 1 20 20
Paper and pen 1packet paper& 100 110
pen
Printing and 3 copies 50 150
bending
Software OS Free
Visual paradigm Free
Browser Free
XAMP Free
Requirement 300 300
gather and
analysis
Total 760
Table 1.1: Cost estimation

4
 1.6.4. Political feasibility
The project built without violating rules and regulations of the governments as well as the
organization. The system being built is for the sake of service of the organization, so that the
project is legally feasible.

1.6.5. Schedule feasibility

The system after development may give efficient and effective services in short period of time.
And also the tasks may be scheduled for effective use of the system. The project will be finished
at the schedule time that means as the project is planned. So the project is Schedule feasible.

1.7. Scope of the project

The project covers the following parts that functions for the school:

Scope In:
 Registration of the Student, Teacher and administrative staffs
 Attendance
 Class time table
 Exam scheduling
 Grade report/ generating transcript
 Resource managing
 Discipline record
 Post notice

Scope Out:

 Library management
 One to five group management
 Club management
 Fee management

5
1.8. Significant of the Project
After this project is finished and properly used it gives great benefits to employees and
customers of the institution.

The following are main benefits.

 Minimize time delay in getting information/reports of placed employee information.

 It avoids redundancy of data during record employee and student information.
 Displays most secured and reliable information
 Reduce’ manpower or minimize workload of the employees.
 Minimize cost of school by reducing number of employees.
 No paper required for recording, update, employee information.
 Fast data insertion of the employee and student information.
 Student within a team will learn practical skill of programming which in turn helps us to
Graduate

1.9. Target beneficiary of the project

Institution/School: -The school get an advance in the way of Speed up the educational
operation, increase competency and Control user records

Developer Team: -To developers the system will add new knowledge, get problem solving skill
then graduate with it.

Users of the system: -Teachers, students, admin and every employers can be benefit from the
system that the system will save their times and workload, reduce data redundancy, reduce
complexity and get easy access

1.10. Methodology
1.10.1. Method of data collection
There are different methods of data collection methods. From those we used the following
methods respectively to collect data from the organization.

6
  Direct Observation: we had directly observed the school to get the right information
about the organization and also understand by viewing how the existing system works.
 Interview: we had asked some question and interviewed the manager and another
employee of the organization and we have got enough and reliable data which is
important to do the project. Before making an interview, we prepared a number of
questions related with our project.
 Document analysis: we had analyzed the manual resources of the organization how the
current system operates and we reviewed different projects respective with student
management system.

1.10.2. System development methodology

There are different types of software development methodologies from this we used: -

 Object oriented based system analysis and design methodology: It is software

development methodology by building self-contained modules or objects. This
methodology has the following futures increased reusability, increased extensibility,
proved quality, and reduced maintenance burden and managed complexity. Due to this
we select OOSAD methodology.
 Software development model: we use iterative model, because in iterative model you can
iterate back if error is occurs in one phase and we can return back to other phase to fix
errors at any phase of the project life cycle.

1.10.3. Development Tools

 Hardware Tools
 Computer : that to perform whole tasks
 Flash Disk: required for data movement from PC to PC
 CD/DVD: Required for file backup
 Paper and pen for Design practice and take notes during data
gathering
 Software Tools
 Operating system: Windows 10 operating system we used to develop
system that it available in lab and personal PC
 Browser: Firefox

7
  Documentation: Microsoft office 2016
 Designation: Edraw Max and Enterprise architecture for designing
UML diagrams.
 Storage: MySQL for the database back end
 Coding: PHP, HTML, CSS, stylesheet front end

1.11. Systems Analysis and Design Approach

1.11.1. Limitation of the project
The main limitation of the scope is the time to develop the system. By considering the
remaining time of the year we limit the scope of the project.
When we do this project we faced different challenges or limitations that restrict our project. Those
limitations are:
 Finance problem, the cost needed to do the project.
 Time problem, the time given to do the project.
 Facilities such as internet service and electric power
1.11.2. Risks & contingencies
During the development of the project there may be different problems that faced us.

 Risks
 Virus may attack the file.
 File may be corrupted and backup data loss when system crash
 If miss installation or configuration with the development tools occur.
 If internet service is not available
 Contingencies
 We use antivirus and firewall to avoid virus attacks
 The team uses different back up techniques through our daily activity
in the project development as a solution.
 The development tools not working so Re-configure the setup.
 Team Uses optional way out of the campus for internet service.

1.11.3. Assumptions and constraints

During the development of the project there may be different Assumptions that expect based on
our schedule.

8
  Assumptions
 We will finish this project with the given schedule which planned in
section 1.13 below.
 We use the development tools in the listed section 1.10.3 above.
 The internet service may available in the campus at all days.
 The adviser have great role for the success of this project.
 There should be enough facilities from the college.
 We will suggest how to configure full setup on client and server.
 Constraints:
 We should have to finish the project based on given schedule
 Group member should have to attend in project development activities
 The end product of the project should meet the proposal
 The advisor should have to give more than enough advice and
direction.

1.12. Team Decomposition

Each part of tasks of the project will be delivered by collaborating with each of the group
members. Each group members has their own responsibility to complete the project successfully.
The group members and responsibility described in table 1.2 below

No Group name Responsibility

1 Alemayehu Bogale Leader and programmer
2 Solomon Bekele System designer and Tester
3 Lemi Tasew System analysis and Tester
4 Mekonin Aklilu System analysis and designer
Table 1.2: Team decomposition

9
1.13. Project Schedule
The project is developed according to the schedule planed that shown in table 1.3 below:

Table 1.3: Project Schedule

10
 CHAPTER TWO

2. DESCRIPTION OF THE EXISTING SYSTEM

2.1. Introduction
This project emphasizes school management system on Wolkite Ras ZeSellasie elementary
School. Therefore, we give the overview of school management system of the Ras ZeSellasie
elementary school.

Wolkite Ras ZeSellasie elementary school management system is focus on the registration of
students, teacher and other administrative staffs, managing students and the data exchanges of
reports between the offices of the school. The offices of the school include the director office,
teacher office, resource office, and record office and so on. the school management system is
manual. Due to this the system requires different materials like paper, pen, binder, shelfs etc.
Which waste time, labors and costs.

Generally the system is not more developed with computerized system so we going to develop
automated system for the school. In this chapter we were discussed overview of the current
system, organizational structure, users of the current system and major functionalities exists in
the current system and users.

2.2. Overview of current system

The Ras ZeSellasie elementary School service for grade one-eighth. At the beginning of each
academic year which starts in September (Ethiopian New Year), the students get registered and
assigned rooms. Each class (section) of students is assigned to a fixed room. Home room
teachers are assigned to each class of students. There are two semesters per year. The first
semester final examination is usually administered during January, the second semester final
examination is administered during the end of June and consequently the results of each class of
students is collected, organized, ranked by the corresponding home room teacher and reported to
each student. The homeroom teacher also records attendance of each student on each school day
which is later organized by the attendance officer. A student who has been absent for more than
one month is not allowed to take a semester final examination and will be forced to withdraw.
Transcripts are generated by the record officer. A student may request transcript when he/she

11
wants to transfer to other school or when he/she has completed/graduated from the school and
needs to join higher education or for some other purpose. Students and teachers are almost
depending on school timetable for their day-day activities.

2.3. Organization structure

In this section, we looked what look like the current organizational as shown figure 2.1 below.

technology Organization Chart

Director

Unit Leader of
Grade 1-4

Liebrary
HR Manager
Unit Leader of
Grade Coordinetor
Grade 5-8 Vice
Director /Record
Course
officer
Course
Grade Coordinetor
Grade one Club
Labaratory
Liebrary
Amharic

Grade two Grade 7 & 8 Data Management

Grade Five
Grade 5 & 6

English

Amharic
Grade Six Amharic
Grade Three

Basic Science
English
Grade Four English
Grade Seven

Maths

Grade Eight Maths

Biology

Biology

Civic
Civic

Social Science
Social Science

Chemistry
Sport

Art Physics

Sport
Music

Figure 2.1: Organization Structure

12
2.4. Users of Current system
Users are persons who are react in the environment of school. Those persons have directly
interacted to the system. This persons are performs some actions like registering students,
recording discipline , preparing student marks, recording student attendance, producing time
tables, managing student information, generating reports, and so on. So the table 2.1 below
describes the users of current system.

Users Responsibility Technical skill

Directors Viewing reports, manage
school system
Vise director Viewing reports, manage
school system
Record officer Records student data,
preparing grade report card,
record teachers
Teacher Organizes student marks,
teaches students and
attendees school
Students attendees class, get grade
report card
Employee Manages school properties
Parent View their students reports
Takes care of their students
Table 2.1: User of current system
The actors of the system performs all activities by the work divisions as described above.
Ability to work on different
in the past
Ability to work on different
skill in past
Ability to work on record
management system
Should have diploma or BSC
Should learned KG school or
should have above 6 age
Ability to work on different
office
Ability to manage their
children

2.5. Major functions of the Current System

Currently the existing system of the Ras ZeSellasie elementary school manual based. The
main functions of the school are:

 Registering the students every beginning of the year: They fill the appropriate
information on the forms with attaching photos and submit to record officers then
Record officer checks whether valid or not.
 Preparing reports

13
  Preparing transcripts or grade report: Teachers submit the student marks to record
officers and record officers organizes the student marks, after organizing prepare
transcript, then the students take the transcripts
 Managing student information: Teachers gives exams, tests, assignments, etc. to the
students after collecting student marks and organize he calculates and prepare marks,
then students takes mark from their teachers
 Recording the students that has the discipline cases: Students fill the forms, discipline
committee checks it, and then discipline committee stores the student information finally
students take warring letter from school.
 Attendance taking: Homeroom teacher take attendance daily, then reports to record
officer, finally semester attendance is checked whether students seat for exam or not.
 Managing library, laboratory systems and human resources.

2.6. Existing System Workflow structure

The work flow of the existing system described as the flowing: first director assigns the
record officer to job, then students register on record officer, next director assigns teacher to
subject of class, then teacher teaches student and gives test, assignment and exam, then record
student mark result and take attendance, finally submit total mark of the students and attendance
record to record officer, then record officer prepare grade report card and various reports, finally
distributes grade report card to students and submit other report to director. On other hand
director also assign duties or responsibilities to other staffs, then staffs care out their duty, next
submit reports to directors, finally director approves. The figure 2.2: below shows existing
system work flow structure. The number assigned on each arrow shows step of flow for example
1,1 director assign record officer, 1,2 student register to record officer, 2,1 director assign teacher
on each class subject and continuous.

14
 Figure 2.2: existing system Work flow structure diagram

2.7. Reports Generated in the existing System

 Report is being generated to tell about school, students, teachers, other staffs information
in the School.
 It is based on the general information of school.
 This report helps the Departments to ask for additional students, teachers, and other staffs
and for other purpose.
 Specified quires of the party that require those reports .that means by using quires report
about school information.

The following are some of the reports generated in RSMS system:

15
  Annual Report on student registration and skill.
 Semester report teaching learning process
 Daily Report on student attendance.
 Annual Report on new student registration and skill.

2.8. Forms and other documents of current system

The current system has its own forms and documentation that used in the school. Some of them
are lists as follow:

 Student registration form: It is the form that used to register students of the school
that includes section, name, gender, age, parent name, address, phone and signature
shown in appendix 1.1.
 Report form: It’s the form that contain Ras zeSellasie school staff workers job
performance report includes name of worker, sex, age, date limitation for
performance, evaluation criteria and status level shown appendix 1.2.
 Attendance form: Is the form that homeroom teacher use to check whether the
students are present or absent in the class. It contains the attributes like student name,
sex, age, week, date, semester and year shown appendix 1.3 picture.
 Time table form: Is the form that used to show weekly class schedule of the school
shown in appendix 1.4.
 Grade report form: This form describes the student grade report that used to report
student’s grade of the year that contains student name, mark, average and sex shown
in appendix 1.5

2.9. Bottlenecks of the existing system

Problem solving framework is a checklist for identifying problems with an existing
information system. The PIECES framework developed by James whether be is used here as a
means to classify problems. PIECES stand for Performance, Information, Economics, Control,
Efficiency and Service.
2.9.1. Performance
As the system is manual it takes time to perform management of school like report generating,
student information and grade management, and producing timetable and schedule.

16
2.9.2. Input and Output
 Input
 Data is not captured in time to be useful.
 Data is not accurately captured – contains errors.
 Data is captured redundantly – same data is captured more than once.
 output
 Lack necessary and relevant information.
 Sometimes Information is not in a useful format like registering user
information.
 Information is not timely to its subsequent use

2.9.3. Security and Controls

 Too little security or control
 Input data is not adequately edited because of using manual system.
 Data damage with like dust or rain so they storing in room and shelf even on
working desk.
 Redundantly stored data is inconsistent in different files.
 Data privacy regulations or guidelines can be violated.
 Processing errors are occurring by people.
 Decision- making errors are occurring.

2.9.4. Efficiency
 Waste of time
 Data is redundantly input or copied.
 Data is redundantly processed.
 Information is redundantly generated.
 Unavailability of staff’s on time.
 Waste of materials and suppliers
 Effort required for tasks is excessive.
 Materials required for tasks are excessive.

17
 CHAPTER THREE

3. PROPOSED SYSTEM
3.1. Introduction
In this chapter the proposed system is described such as product overview, user class and
characters, functional requirements and nonfunctional requirements. Each elements described
one by one how they are functions to develop the proposed system.

In response to raised problem, our project proposes to investigate several options for making
the school more hospitable. We plan to carry out almost all-inclusive participatory modules into
options for school starting from registration up-to discipline record management, but we may not
cover all of them. We will also consider less expensive ways to mitigate some or all of the
problems noted above by creating simple and easy user-interactive School Management System.

3.2. Product Overview

The proposed system of the Ras zeSellasie school management system is to provide an
efficient management and reduce the system complexity, and also results an easy
implementation. This can be accomplished by developing an automated system. This system is
mainly concern with how the Director and vice Director of the school, record officer, teacher,
students and others are work in their position. The proposed system will improve like:-
 Scaling the progress of technology to the highest level
 Creating effective functioning method in managing the school
 To minimize time and budget
 Director (administrator) can be view teachers and student’s information
 To make easy in searching, generating reports, generating transcript
 To make easy assigning room teacher, taking attendance, producing timetable and
schedule.
 It helps for to give fast service to the students and teachers of the school
:
Generally, the product overview of the Ras ZeSellasie school management system described in
the figure 3.1: below.

18
 e
notic Student
vie view
Administrator Cr ort
ea w e rep
te rep grad
Ge
Ac
co
or
t view
ne un ister
r t R eg
Ge a t ule
ne e tim ch ed
rat eta e x am S
eE ble view table
xa Time
Re
gis po m
s View
st c
ter n o h ed u
Us tic
ers e le

Record attendance
prepare Grade Report
View Exam schedule
u rce
reso view notice
ag e
Man t View Timetable
or

vi
rep Teacher

ew D i
Vi
e

vi
rat

ew

st
ew
ne

ud ipli
Ge

st

en n e
sc
ud

tm
co

en

ar
Employee m

ti

k
m

nf
en

o
t

Parent

Figure 3.1: Product overview

Algorithm: -There are many algorithms that are used to create school management in general.
For instance genetic algorithm, but we use our own algorithm for creating timetable and others

19
3.3. User Classes and Characters
The proposed system has its own user classes and its character. The user classes and their
characteristics are described in the table 3.1: below.
Users Responsibility Technical skill
Directors/Admin Viewing reports, create Ability to work on different
accounts, manage exam in the past and should have
Schedule and timetable and computer skill.
Register users
Teacher Prepare Grade report, Record Should have diploma or BSC
attendance, and View notice,
timetable and exam schedule
Students View Grade report, Should learned KG school or
Discipline, notice, timetable should have above 6 age
and exam schedule
Employee Manages school properties or Ability to work on different
resource and generate report office
Parent View their students Ability to manage or take
information, Grade report and care their children
discipline
Table 3.1: User class and characters

3.4. Functional Requirements

Functional requirement defines a function of a software system or its component. A function is
described as a set of inputs, the behavior, and outputs. Functional requirements may be
calculations, technical details, data manipulation and processing and other specific functionality
that define what a system is supposed to accomplish.

The functional requirement of the Ras ZeSellasie School describes the function of the system.
This system is useful for obtaining effective and efficient service of the school.
The functional requirements should be complete and consistent. Completeness implies that all
the user requirements are defined and consistency implies that all requirements are specified
clearly without any contradiction definition.
Functional requirements

 Registration: To stores the necessary information of those actors of school

management.

20
  Record attendance: To records the student attendance to check student presence
and absence.
 Generate reports: To generate reports of the school activity weekly, monthly and
annually to verify school functionality.
 Generate timetable: To show class timetable of the school how to follow during
education time.
 Generate exam schedule: To prepare schedule for the exam time.
 Records discipline: To record the discipline case of the student.
 Generate Grade report: To prepare grade report of the student.
 Post notice: To inform school members what is going to care out.
 Managing resources.
 Recording student marks
3.5. Non Functional Requirements
The nonfunctional requirements relate to system attributes such as reliability and response time
and they can arise due to user requirements. Here below we list down the possible non
functionalities with related to this SMS system.
Security

Security requirements are important factors in this system as classified data will be stored in the
database. User validation will be done during login to insure that the user is valid and that the
user only has access to his or her permission data. General users will only have access through
the user interface.
Usability

The system will have consistent interface formats and button sets for all forms in the application,
will have a form based interface for all data entry and viewing formats, and will generate reports
that are formatted in a table and that should look like the existing manual report formats for user
friendliness, so the user interface is easy to use.
Maintainability

The system is developed by using high level and dynamic web development language as a result
the system will be easily maintained by the developer or other authorized trained person.

21
Efficiency

The web-based system should have easy and efficient code manipulation and have clear database
thus the response time should be very small i.e. not more than 5 seconds.
Reliability requirements:

The system robust enough to have a high degree of fault tolerance. For example, if the user
enters a wrong password or username or a value too large, the system should identify the invalid
input and produce a suitable error message.
Integrity

Only system administer has the right to change system parameters, such as creating account. The
system should be secure and must use encryption to protect the databases.
Performance

More effective when compared to the manual approach, resulting in fast accomplishment of task
with in some amount of time [Performance / Response time].
Availability

The system doing 24 hours in every day unless there is no internet connection but the system
shall not crash whenever internet connection is not available

22
 CHAPTER FOUR:

4. SYSTEM ANALYSIS
4.1. System Models
To produce a model of the system which is correct, complete and consistent we need to
construct the analysis model which focuses on structuring and formalizing the requirements of
the system. Analysis model contains three models: functional, object and dynamic models. The
functional model can be described by use case diagrams. Class diagrams describe the object
model. Dynamic model can also be described in terms of sequence, state chart and activity
diagrams. For the purpose of this project we have described the analysis model in terms of the
functional model and dynamic models using use case, sequence diagrams, Activity diagram,
State diagram and class diagram.
Finally in this chapter we discuss functional, object and dynamic model with perspective of data
we gathered from the school.
4.1.1. Use Case model
The use case model is model that describes the requirement of the system in diagrammatic form
based on UML language. It describes the relationship between the actors of the system and use
case of the system. Figure 4.1: below shows the use case model of the system.

23
 uc New usecase

Ras ZeSellasie School Management System

Record
Attendance Generate
GradeReport

Record
marks

View
Timetable Student

View Exam
Schedule
Teacher

View Notice

Logout

Record
resource «extend» View
GradeReport

Update
resource Login
Manage
Resource
View Student
Delete Information
«include»
resource

Generate Registration
Report
Employee
View Discipline
Case
Post Notice

Create Exam
Schedule
Comment
Parent
Manage
ExamSchedule
Delete Exam
schedule

Generate
Exam
View Report Schedule
Add Stud_data
Update
Admin Student data

Manage Delete student

Student data data

Delete
timetable
Manage
Timetable
Manage
Account Generate
timetable

Manage
Discipline Create
Delete timetable
account
Create Delete
Update
account discipline
account Update
Record
discipline discipline

Figure 4.1: use case model

24
 4.1.2. Use Case Description
The use case description is used to detail description of the use case what and how the use case
works in order to perform user and system functionality. It can described in table 4.1 below.

Use Use case Use case Description

case Id name

UC_0 Registration Description: To register and store detail information

1
Actor: Student, Admin, Teacher, Parent, Employee.

Pre-condition: actors should be apple or eligible to the Admin. Network

and electric power should be available. Admin should be login to system

Normal flow: System Response

User Action 2 System Display
1. Admin click registration link registration type
3 Admin select registration type 4 System display
5 Admin fill the form and click registration form
register button 6 System verify the
8 Admin conform it information
7 System request
conformation to stores
data
8 System stores user
information into database
Alternative flow: 6.1 If there is error in filled data system return
submission to step 4.

6.2 Admin try to fill form again by correcting error.

Post-condition: User registered

Additional notes: Priority high

25
UC_0 Login Description: To authenticate user to get into the system. Provides log in
2 forms to verify whether the user is authorized or not

Actor: Student, Teacher, Parent, Admin and Employee.

Pre-condition: All the user should an accounts.

Normal flow: System Response

User Action 2: System display login form

1: User click login link 5: System verify the user name and
password
3: User fill the user name and
password with selecting user type 6: System display user home page

4: user click login button

Alternative flow: 5.1: If account error, system display

5.2: user try again to login.
5.3: If user forget password click
forget password link
5.5: user fill necessary
information to change password.
error message and return to step 3
5.4: system display user check form
5.7: system check user information
from database
5.8: update user password

5.6: user click change password 5.9: system return in step 3

button
5.10: If error in step 5.7 system
return to step 5.5.

Post-condition: User logged in

Additional notes: priority high

UC_0 Logout Description: It helps user to get out from the system

26
3 Actor: Student, Teacher, Parent, Admin and Employee.

Pre-condition: Login to the system with user-name and password

Normal flow: 1: User click logout button

2: System process close and display login page

Alternative flow: 2.1: If system stay login after logout, check network
then try again to logout

Post-condition: user logged out

Additional notes: User should not forget logging out from system after
logged in.

UC_0 ViewTimet Description: It displays the class routine timetable for the user
4 able
Actor: Student, Teacher

Pre-condition: User should have logged in to system

Normal flow:

1. User click view button

2. System display timetable

Alternative flow: If system does not display timetable, check if network

is available. Try again

Post-condition: User viewed timetable

Additional notes: User can’t modify the time table except administrator

UC_0 ViewExam Description: It displays the posted exam schedule for the user
5 Schedule
Actor: Student, Teacher

Pre-condition: User should have logged in to system

27
 Normal flow:

1. User click view button

2. System display exam schedule

Alternative flow: 2.1: If system does not display exam schedule, check
if network is available. Try again

Post-condition: User viewed exam schedule

Additional notes: User can’t modify the exam schedule except

administrator

UC_0 ViewGrade Description: It displays student total mark and grade report for the user
6 Report
Actor: Student, Teacher, Parent, Record officer

Pre-condition: User should have logged in to system

Normal flow: System Response

User Action 2: System display student id search

form
1: User click view button
4: System check student id
3: user enter student id and click
search button 5: system fiche student mark and
display.

Alternative flow: 4.1: If student id is not valid system display error

message and return to step 3

4.2: user try again.

Post-condition: User viewed students mark or grade report

Additional notes: priority low

UC_0 ViewDiscip Description: It displays students discipline status for the user

28
7 line Actor: Student and Parent

ttgPre-condition: User should have logged in to system

Normal flow: User Action System response

1: User click view button 2: system display student id search

form.
3: User enters student’s id and
click search button 4: System verify student id

5: System display discipline

information.

Alternative flow: 4.1: If student id error, system display error message

and return to step 3.

4.2: user try again.

Post-condition: User viewed students discipline case

Additional notes: User should know students id

Unable to modify it except record officer and administrator

UC_0 View Description: It displays the students detail information for the user
8 Students
Actor: Student, Teacher and Parent
Information
Pre-condition: User should have logged in to system

Normal flow: User Action System Response

1: User click view information 2: system display student id search

link form.

3: user enter student id and 4: System verify student id

click search button 5: System display student information.

29
 Alternative flow: 4.1: If student id error system display error message
and return to step 3.

4.2: user try again

Post-condition: User viewed student’s full information

Additional notes: priority low

UC_0 Manage Description: To record, update and delete students discipline cases
9 Discipline
Actor: Admin

Pre-condition: Admin log in to system as administrator

Normal flow: User Action System Response

1: Record discipline 1.2: System display options

1.1: Admin click discipline link 1.4: System display discipline form

1.3: Admin select record option 1.6: System verify the information

1.5:Admin fill the form and 1.7: System stores information in to

click record button database

2: Update Discipline 2.2: System display option

2.1: Admin click discipline link 2.4: System query discipline case
registered student
2.3: Admin select update
2.6: System display student
2.5: Admin select student discipline

2.7: Admin edit data and click
update button
3: Delete Discipline
2.8: system verify the information
2.9: System update the data
3.2: System display the option

30
 3.1: Admin click discipline link 3.4: System display discipline case
registered student
3.3:Admin select delete
3.6: System display conformation
3.5: Admin select student and
request.
click delete button
3.8: System delete from the list
3.7: Admin conform

Alternative flow: 1. Record 1.6.1: If there is error in the filling for

1.6.2: Admin try again
2. update
2.8.2: Admin try again
system display error message and
return to step 1.5
2.8.1: If there is error in the filling for
system display error message and
return to step 2.7.

Post-condition: Discipline data is managed

Additional notes: Other user does not manage discipline except record
officer. Priority medium.

UC_1 Manage Description: To record, update and delete students detail information’s
0 Student
information
Actor: Admin

Pre-condition: Admin log in to system as Administrator

Normal flow: User Action System Response

1: Record 1.2: System display the options

1.1: Admin click student data 1.4: System display form

button 1.6: System verify the form

1.3: Admin select the record 1.7: System add in to database

31
option 2.2: System display option

1.5: Admin fill the form and 2.4: System display recorded list
click record button
2.6: System display the data
2. Update
2.8: System verify the filled form
2.1: Admin click student data
2.9: System request conformation
button
2.11: System update the data.
2.3: Admin select update option
2.12: system update the data.
2.5: Admin select the from list
3.2: System display option
2.7: Admin edit and click
update button 3.4: System display list to delete

2.10: Admin confirm request 3.6: System display confirmation

3. Delete 3.1: Admin click 3.8: System delete data from the list
student data link

3.3: Admin select delete option

3.5: Admin select data to delete

and click delete button

3.7: Admin confirm to delete

Alternative flow: 1.6.1: I f there is error system display

error message and return to step 1.5
Record: 1.6.2: Admin try
again 2.8: If there is error system display the
error message and return to step 2.7
Update:

Post-condition: Students data is managed

Additional notes: Other user does not manage student’s data except

32
 Adminstrator. Priority medium.

UC_1 Manage Description: To create, generate, update and delete school exam
1 ExamSched schedule
ule
Actor: Administrator

Pre-condition: Administrator log in to system as administrator

Normal flow: User Action System Response

1. Create 1.2: System display option

1.1: Admin click on schedule link 1.4: system display form

1.3: Admin select create option 1.6: system verify each time

1.5: Admin fill and add form until 1.8: system request confirm
finish 1.10: System stores in data base

1.7: finally click create button 2.2: System display option

1.9: Admin confirm 2.4: System display created list

2. Generate 2.6: system generate exam

2.1: Admin click schedule link schedule

2.3: Admin select generate option 3.2: system display option

2.5: Admin click generate button 3.4: system display schedule

detail
3. Delete
3.6: system request confirm
3.1: Admin click schedule link
3.8: system delete from database
3.3: Admin select delete option

3.5: Admin select and click delete

33
 button

3.7: Admin confirm

Alternative flow: create 1.6.1: display error message and

reset
1.6.2: Admin retry
2.4: If there is no list, system
display error message

3.4: If there is error system display

error message.

Post-condition: Exam schedule is managed

Additional notes: Other user does not manage exam schedule except
administrator. Priority high

UC_1 Manage Description: To create generate, update and delete class timetable
2 Timetable
Actor: Administrator

Pre-condition: Administrator log in to system as Administrator

Normal flow: User Action System Response

1. Create 1.2: System display option

1.1: Admin click on timetable link 1.4: system display form

1.3: Admin select create option 1.6: system verify each time

1.5: Admin fill and add form until 1.8: system request confirm
finish 1.10: System stores in data base

1.7: finally click create button 2.2: System display option

1.9: Admin confirm 2.4: System display created list

2. Generate 2.6: system generate exam

34
 2.1: Admin click timetable link timetable

2.3: Admin select generate option 3.2: system display option

2.5: Admin click generate button 3.4: system display timetable

detail
3. Delete
3.6: system request confirm
3.1: Admin click timetable link
3.8: system delete from database
3.3: Admin select delete option

3.5: Admin select and click delete

button

3.7: Admin confirm

Alternative flow: 1.6.1: display error message and

reset
1.6.2: admin retry
2.4: If there is no list, system
display error message

3.4: If there is error system

display error message.

Post-condition: Time table managed

Additional notes: Other user does not generate time table except
administrator. Priority high

UC_1 View Description: To view various reports from record officer, resource
3 Report manager even teacher.

Actor: Administrator

Pre-condition: Administrator log in to system as Administrator

Normal flow: User action System response

35
 1: Admin click view button 2: System display report type

3: select report type 3: System display report

Alternative flow: 2.1: If report not viewed check if network available

Post-condition: Report viewed

Additional notes: Other user probably does not see the report types
except administrator

UC_1 Manage Description: To record, update and delete resource

4 Resource
Actor: Employee

Pre-condition: Employee log in to system as Employee

Normal flow: User Action System response

1: Record 1.2: System display option

1.4: System display form

1.1: Employee click resource link
1.6: system verify the data
1.3: Employee select record option
1.7: record the resource
1.5: Employee fill the form and
click record button 2.2: system display option

2. Update 2.4: system display recorded list

2.1: Employee click resource link
2.3: Employee select update option
2.5: Employee select list, edit and
click update button
2.6: system verify and request
confirm
2.7: system update the data
3.2: System display option

2.7: Employee confirm request 3.4: system display recorded list

3.6: system request confirmation

36
 3. Delete 3.8: system delete list from
database
3.1: Employee click resource link

3.3: Employee select delete option

3.5: Employee select from list and

click delete button

3.7: Employee confirm request

Alternative flow: 1.6.1: If error system display error

message and return to step 1.5
1.6.2: Employee retry again
2.6: If error system display error
message and return to step 2.5

Post-condition: Resource managed

Additional notes: Only Employee manages the resource. Priority high.

UC_1 Manage Description: To create accounts for the users

5 account
Actor: Administrator

Pre-condition: Administrator log in to system as Admin

Normal flow: User Action System Response

1: create 1.2: system display option

1.1: Admin click account link 1.4: system display form

1.3: Admin select create option 1.6: system verify

1.5: Admin fill the form and click 1.7: system stores account
create button information on database

2: delete 2.1 Admin click on account 2.2: system display option

37
 link 2.4: System display list

2.3: Admin select delete option 2.6: system request confirmation

2.5: Admin select from list and click 2.8: system delete selected list
delete button from database

2.7: Admin confirm list

Alternative flow: 1.6.1: If error, system display error message and

return to step 1.5. Admin try again

Post-condition: Account is created

Additional notes: Only admin can create an account for users

UC_1 Generate Description: To generates various reports

6 Report
Actor: Employee, Teacher

Pre-condition: Both user should log in to system as their account

Normal flow: User visit generate report icon

1. Click on generate report button

2. System display items to generates
3. They select items to generate
4. System show contents overview dialog
5. They conform dialog box

System generates report

Alternative flow: If item is null system display error messages to

generate then back to step (2 above)

Post-condition: Report generated

38
 Additional notes: Both Teacher and Employee can generate reports

UC_1 Record Description: To record students absence and presence and submit result
7 Attendance to record officer

Actor: Teacher

Per condition: Teacher should be log into system with account

Normal Flow: Actor action System Response

1: Record 1.1: Teacher click on 1.2: System display option

attendance link
1.4: System display attendance
1.3: Teacher select record option list and form

1.5: Teacher file check box until 1.6: system verify the data
finish all students of class and click
1.7: system record the attendance
save button

Alternative Flow: 1.6.1: system display error

message, if data not valid and
1.6.2: Teacher retry again
returns to step 1.5

Post condition: attendance managed

Table 4.1: Use case description

4.1.3. Scenario
Scenario is a set of actions performed to achieve a goal under some conditions. A scenario is
an instance of use case describing a concrete set of actions.

Scenarios are used as examples for illustrating common cases; their focus is on
understandability, and a set of actions performed to achieve a goal under some conditions. So, it
will be described below as follows.

Actors involved: Bereket as student, Melkamu as teacher, Mamo as parent, Bedru as Employee
and Sisay as Administrator.

Registration: - To register and store detail information of user

39
Ato Sisay login to the system as Admin, then click on registration link and select user type to
register, the system display registration form, next Sisay enter Bereket’s, Melakus, Mamo’s and
Bedru’s information depending on user type, then system verify the user information and store
the data into database. Even Sisay register himself as he registered others.

Login: - To authenticate user to get into the system. Provides log in forms to verify whether the
user is authorized or not. Bereket visit the page and Select user type, then Fill the user name and
password and click login button, then System verify the user name and password, finally System
display home page

Logout: - It helps user to get out from the system. Mamo, Sisyay, Bereket, Bedru and bereket
click logout button, then System process close and display login page.

ViewTimetable: - It displays the class routine timetable for the user.

After logged in Melkamu visit timetable link, System display option, then Melkamu click view
button, System display timetable.
ViewExamSchedule: - It displays the posted exam schedule for the user

After Bereket logged in visit exam schedule link, System display option, then Bereket click view
button, System display exam schedule.

ViewGradeReport: - It displays Bereket’s total mark and grade report for Bereket, Mamo, also
for Melkamu. Bereket after logged in visit grade report link, System display option, then Bereket
click view button, System display Bereket’s grade report.

ManageStudentsData: - To record, update and delete students detail information.

Sisay clicks record student data button, System display the forms to fill, then Sisay fill the form
and click add record button, System verify and register new record of the students, finally
System display success message. On the other hand Sisay Update recorded student information
by clicking update record button, then System display update form, then Sisay fill the form and
click update button, finally System update the data and gives success feedback. Also Sisay delete
recorded information by clicking delete record button, then System display conformation
message, then Sisay conform message, finally System delete record and display success message
ManageResource: - To create, record, update and delete resource

Bedru click resource link, System display option to select, then Bedru select from the options
such as ether record, update or delete. If Bedru select record option system display resource

40
 form, then Bedru fill the form and click record button, then system verify the information and
add to database.
CreateAccount: - To create accounts for the users

Sisay click create account link, System display account form, then Sisay fill the form and click
create button, System displays conformation dialog, next Sisay then conform the dialog box,
finally System store account information and display feedback message back to Sisay.
GenerateReport: - To generates various reports

Bedru visit generate report link, System displays items type to generate, then Bedru Select items
and click on generate report button, finally System display generates items.

ManageDiscipline: - To record, update and delete students discipline cases

Sisay clicks Discipline link and select option that he wants to perform, If he select record
discipline link the system display the form to fill, then Sisay fill the form and click record button,
The system verify the form and request conformation, then Sisay conform it, finally system
stores the discipline information on the database. Even Sisay follows this step to perform other
operations.

4.2. Object model

4.2.1. Data dictionary
Data dictionary is description of database table of the system such as functionality, data types,
data size, contents item and table relations. It can be described in table 4.2 below.

Table Name: Student

 Primary key: StudId
 Foreign key:
Description: used to register all the information about students
Field Name Data type Constraint Description
StudId Int Primary key It stores registered students
id

First_Name Varchar(30) Not Null It stores first name.

Last_Name Varchar(30) Not Null It stores last name.

Grade Int Not Null It stores students grade

Section Varchar(30) Not Null To stores students section

41
Phone Int Not Null It stores mobile number.
Address Varchar(20) Not Null It stores students address.
Father Name Varchar(20) Not Null It stores students father
name
Mother Name Varchar(20) Not Null It stores students mother
name
Sex Varchar(20) Not Null It stores students sex or
gender
Age Int Not null To stores students age
Birth day Date Not null To stores students birth date
Date Date Not Null It stores registration date

Table Name: Teacher

 Primary key: TrId
 Foreign key:
Description: used to register all the information about teachers.
Field Name Data type Constraint Description
TiId Int Primary key It stores registered teachers
id
Fname Varchar(30) Not Null It stores first name.
Lname Varchar(30) Not Null It stores last name.
Phone Int Not Null It stores mobile number.
Address Varchar(20) Not Null It stores teachers address.
Gender Varchar(5) Not Null It stores teachers sex or
gender
Mirage status Varchar(20) Not Null Stores mirage status
Department Varchar(30) Not Null Stores teachers graduated
filed
Date Varchar(30) Not Null It stores registration date
Table Name: Admin
 Primary key: AdminId
 Foreign key:
Description: used to register all the information about admin.
Field Name Data type Constraint Description
AdminId Int Primary key It stores registered staffs id
Fname Varchar(30) Not Null It stores first name.
Lname Varchar(30) Not Null It stores last name.
Phone Int Not Null It stores mobile number.
Address Varchar(20) Not Null It stores teachers address.
Gender Varchar(5) Not Null It stores teachers sex or
gender
Mirage status Varchar(20) Not Null Stores mirage status

42
Department Varchar(30) Not null Stores teachers graduated
filed
Date Date Not Null It stores registration date
Table Name: Attendance
 Primary key: AttId
 Foreign key: StudId
Description: used for marks students attendance in order to checks students absence or presence.
Field Name Data type Constraint Description
AttId Int Primary key It stores registered
attendance id
StudId Int Foreign key It stores foreign key of
students
StudentName Varchar (30) Not null To stores students name
Time Time Not null Stores attended time
Day Date Not Null It stores attended day
Week Int Not null To stores attendance week
Table Name: Timetable
 Primary key: TTId
 Foreign key:
Description: used to generate all the information about timetable.
Field Name Data type Constraint Description
TTId Int Primary key It stores tome table id
Day Date Not Null It stores day of time table
Subject Varchar(30) Not Null It stores subject.
Teacher varchar(10) Not Null It stores subject teacher.
StartTime Time Not Null To stores class starts time.
EndTime Time Not null To stores class ends time
Grade Varchar(30) Not null To store students grade
Section Varchar(5) Not Null It stores section
Semester Varchar(20) Not Null Stores semester
Date Date Not Null It stores time table date
Table Name:ExamSchedule
 Primary key: ScId
 Foreign key:
Description: used to arrange exam schedule of the school.
Field Name Data type Constraint Description
ScId Int Primary key It stores registered teachers
id
Date Date Not Null It stores first name.
Time Varchar(30) Not Null It stores last name.
Subject numeric(10) Not Null It stores mobile number.
Section Varchar(20) Not Null It stores teachers address.

43
Grade Varchar(5) Not Null It stores teachers sex or
gender
Examiner Varchar(20) Not Null Stores mirage status
Table Name: Discipline
 Primary key: DId
 Foreign key: StudId
Description: used to record all the information about discipline.
Field Name Data type Constraint Description
Did Int Primary key To stores disciplines id
StudId Int Foreign key To stores students id
StudentName Varchar(30) Not null Used to store students name
Date Date Not Null It stores first name.
Time Time Not Null It stores last name.
Case numeric(10) Not Null It stores mobile number.
Punishment Varchar(20) Not Null It stores teachers address.
Table Name: Resource
 Primary key: RId
 Foreign key:
Description: used to record all the information about resource.
Field Name Data type Constraint Description
Rid Int Primary key To stores resources id
ResourceName Varchar(30) Not Null To stores resource name.

ResourceType Varchar(30) Not Null It stores resource types

Time Varchar(30) Not null Stores resource managed
time
Date Date Not Null It stores managed date
Table Name: Account
 Primary key: AccId
 Foreign key: StudId, AdmId, pId, RoId, RmId, comId, TrId
Field Name Data Type Constraint Description

AccId Int Primary key Stores account Id

User type Varchar(30) Not Null Stores user type
User name Varchar(30) Not Null Stores user name
Password Varchar(8) Not Null Stores password
Table Name: parent
 Primary key: PId
 Foreign key:
Field Name Data Type Constraint Description
PId Int Primary key Stores parent id
Fname Varchar(30) Not Null Stores parent first name

44
Lname Varchar(30) Not Null Stores parent last name
Adders Varchar(30) Not Null Stores parent adders
Phone Int Not Null Stores parent phone number
Job type Varchar(30) Not Null Stores parent job type
Table Name: Employee
 Primary key: EmpId
 Foreign key:
Field Name Data Type Constraint Description
EmpId Int Primary key Stores committee id
Fname Varchar(30) Not Null Stores committee first name
Lname Varchar(30) Not Null Stores committee last name
Adders Varchar(30) Not Null Stores committee adders
Phone Int Not Null Stores committee phone
number
Job type Varchar(30) Not Null Stores committee job type
Table Name: mark
 Primary key: marId
 Foreign key: StudId, SubId
Field Name Data type constraint description
marId Int Primary key To store mark id
SubId Int Foreign key To stores subject id
StudId Int Foreign key To stores student id
StudentName varchar Not null To stores student name
Subject varchar Not null To store subject name
Test double Not null To stores test result
Assignment double Not null To stores assignment result
Exam double Not null To stores exam result
Total double Not null To stores total mark result
average double Not null To stores all marks average
Table 4.2: Data dictionary

4.2.2. Analysis level class diagram

Class diagram is the most widely used diagram in modeling object-oriented system. A class
diagram shows a set of classes, interfaces, associations and generalizations of classes.
A class diagram is an illustration of the relationships and source code dependencies among
classes in the Unified Modeling Language (UML). In this context, a class defines the methods
and variables in an object, which is a specific entity in a program or the unit of code
representing that entity. Class diagrams are useful in all forms of object-oriented programming
(OOP).

Analysis level class diagram is conceptual modeling of the system, so it can described in figure
4.2 below.
45
class SMSClassDiagram
asign
View
Generate
1..8
Timetable
- BreakTime: time
+ Date: date
+ Day: S tring
- Description: S tring
- EndTime: time
+ Grade: int
+ Room: S tring
+ S ection: S tring
- S tartTime: time
+ S ubject: S tring
- TT_Id: int
+ Tr_Id: int
+ Add(): void
+ Delete(): void
+ Generate()
+ Update(): void
1
ExamS chedule
1..8
- ES _ID: int
+ examiner: S tring
1 1..*
+ Add(): void
+ Delete(): void
+ Generate(): void
Figure 4.2: Class diagram
User
+ FirstName: S tring
+ LastName: S tring
+ MName: S tring
+ Age: int
+ Gender: S tring
Subject + Phone: int
+ Address: S tring
- SbjectId: int
+ UserName: S tring
- Subject Name: String
- password: S tring
+ AssignToTeacher(): boolean
+ Register(): Void
Teach
+ Login(): Void
*
Admin
S tudent Parent Employee
- AdminId: int Teacher
- Field: S tring - EmpId: int
- BirthDay: int - Parent_ID: int
- Filed: S tring - Filed: S tring
1 + CreateAccount(): void - Grade: int - Jop: S tring 1
- Tr_ID: int
+ Manage(): void - S ection: S tring + ManageResource(): void
+ View(): boolean
+ ViewReport(): void + ManageGradeReport(): void + S tudId: int + GenerateReport(): void
+ Comment(): void Manage
+ RecordDiscipline() + RecordAttendance(): void
+ View(): boolean 1
+ view(): boolean 1
1 * Generate 1..*
1 * 1..*
View * 0..1 *
View Resource
Record 0..* Report
Record 1..
Prepare
+ Date: date
* 1..* - RcId: int
Discipline - item: double
Attendance - report_type: S tring
+ Name: S tring
+ comment: S tring GradeReport + year: date
- att_id: int + Category: S tring
+ Date: date + Date: date
+ day: S tring - Description: S tring - type: S tring
- Decision: S tring - Description: S tring
- Grade: int - GrId: int - status: S tring
- DcId: int - Category: S tring
- S ection: int + Grade: int - RcId: int
- Case: S tring - Name: S tring
+ S emester: S tring + Mark: int
+ S tudId: int - RpId: int + create(): void
- status: int + S ection: S tring view
+ S tudentName: S tring + delete(): void
- studId: int + S emester: int + clear(): void
- year: date + record(): void
+ S tudentName: S tring - S tudId: int + create(): void
+ update(): void
+ Clear(): void + year: date + S tudentName: S tring + Delete(): void
+ Delete(): void + S ubject: S tring 1 + generate(): void
+ edit(): void
+ Record(): void + Clear(): void
+ Record(): void
+ update(): void + Delete(): void
+ update(): void
A + Generate(): void
1 1 + update(): void
View
Assign
Class
- RoomId: int
*
- Room: S tring 1
+ AddClass()
46
 4.3. Dynamic Model
4.3.1. Sequence Diagram
Sequence diagram is emphasizing the time ordering of the message and emphasize the structural
organization of the object. They are helpful to identify the missing objects that are not identified
in the analysis object model.
 Registration Sequence Diagram
The figure 4.3: below Sequence diagram used to how to register all users like students, teacher,
parent and Employee even Admin of the school.
sd Dynamic model

Admin
Registration<Link> Registration<Form> Registration<Controler> DataBase<DB>
ClickLink
(1)

Select Registeration type

(2)

HandleRequest
(3)

DisplayForm
(4)

FillForm(5)

ClickRegisterButton
(6)

Handle filled form

(7)

RequestVerfication
(8)

Conform
(9)
verify
If Invalid (10)
(11)
I valid save
(12)

Success
(13)
feedback
(14)

Figure 4.3: Registration sequence diagram

47
  Account Creation Sequence diagram
The figure 4.4 below show the step of how to create user account.
sd Dynamic Model

Admin
AccountLinck<UI> AccountForm<UI> Account<Controler> AccountDatabase<DB>

ClickLinck
(1)

HandleRequest
(2)

DisplayForm
(3)

FillForm
(4)

ClickCreate
(5)
HndleCreationRequest
(6)

Verify
(7)
Invalid
(8)

Save
(9)
Feedback
(10)

Figure 4.4: Account sequence diagram

 Login Sequence Diagram
The figure 4.5 below used to login to the system with valued user name and password. The
system users are admin, student, teacher, parent and employee.

48
sd Dynamic Model

User
Login<Button> LoginForm<UI> LoginControler UserPage<UI> LoginDatabase
ClickButton
(1)
HandleRequest
(2)

AllowForm
(3)

FiillAccountInfo
(4)

ClickLogin
(5)
HandleLogin
(6)
Verify
(7)
InvalidInput
(8)

Validinput
(9)

Verify
(10)
InvalidAccount
(11)
DisplayUserHome
(12)

Figure 4.5: Login sequence Diagram

 Attendance record Sequence diagram
The figure 4.6 below used to record attendance of the student daily by homeroom teacher that
help to attend student presence and absence of student of the school.

sd Dynamic Model

Teacher
Attendance<Button> AttendanceForm<UI> Attendance<Controler> Database<DB>
ClickButton
(1) HandleRequest
(2)

loop AllowForm
(3)

TickAttendance
(4)

HandleTick
(5)

Ticked
(6)

SaveAttendance
(7)

HandleSaving
(9)
Verify
(10)

Save
(11)

Successful
(12)

Figure 4.6: Attendance sequence diagram

49
  Timetable Sequence diagram
The figure 4.7 below describes how to add and generate timetable of the school.
sd Dynamic Model

Administor
TimeTableLinck<UI> TimetableForm<UI> Timetable<UI> Timetable<Controler> DataBase<DB>
Clicklinck
(1)
HandleRequest
(2)

loop
DisplayForm
(3)

FillForm
(4)

ClickAdd
(5)
HandleAdd
(6)

DisplayConformation
(7)

Conform Verify
(8) (9)

invalid
(10)

AddT oDB
(11)
Success
Successful (12)
(13)
ClearForm
(14)

ClickGenerate
(13)
HandleRequest
(14)
RequestQuery
(15)

Verify
(16)
Invalid_NoEntery
(17)

Query
(18)
DisplayOverview
(19)
Conformation
(20)
Confirm
(21)

GenerateT imetable
(22)

Figure 4.7: Timetable Sequence Diagram

 Student Discipline Record Sequence Diagram
The figure 4.8 below shows the sequence of how administrator record student discipline cases.

50
sd Dynamic Model

Admin
DisciplineRecordLink<UI> DisciplineRecordForm<UI> DisciplineRecord<Controler> Database<DB>

ClickLink
(1)
HandleRequest
(2)
DisplayForm
(3)
FillForm
(4)
Add
(5)
HandleForm
(6)
Verify
(7)
IfNotValid
(8)
IfValidConfirmationRequest
(9)
confirm
(10)

handleConformation
(11)
SaveTo
(12)

Verify
IfNotValidDB_error (13)
(14)

Success
(15)
Feedback
(16)

Figure 4.8: Student discipline record sequence diagram

 Various report sequence diagram
The figure 4.9 below is use to how to generate various reports of the school by different users
like Employee and teacher.

51
sd Dynamic Model

user
ReportLink<UI> ReportForm<UI> Report<UI> Report<controler> Databse<DB>
ClickLink
(1)
HandleRequest
(2)
DisplayForm
(3)
FillForm
(4)
Add
(5)
HandleForm
(6)

Verify
(6)
IfNotValid
(8)

ConformRequest
(9)
Confirm
(10)
HandleConformation
(11)
SaveTo
(12)

Verify
(13)
IfDB_Error
(14)

Success
(15)
Feedback
(16)

option
(17)

ClickGenerate
(18)

HandleGenerate
(16)

RequestQuery
(17)

Verify
(18)
IfDB_Error
(19)

Query
(20)

GenerateReport
(21)

Figure 4.9: various report Sequence diagram

 Resource Sequence diagram
The figure 4.10 below used to describe how Employee manage the school resource. This
includes recording new resources and distributed resources.

52
 sd Dynamic Model

Employee
ResourceLink<UI> ResourceForm<UI> Resource<Controler> DataBase<DB>
ClickLink
(1)
HandleRequest
(2)
DisplayForm
(3)
FillForm
(4)
Add
(5) HandleForm
(6)

ConfirmationRequest
(8)

confirm
(9)
HandleConfirmation
(10)

Verify()

Invalid()

SaveTo
(11)

Verify
(12)
DBError()

Success
(13)
FeedBack(14)

Figure 4.10: Resource sequence diagram

 View Contents
The figure 4.11 below describes how users view the timetable, exam schedule, report, notice, and
grade report. Administrator view reports, timetable, exam schedule and notice viewed by teacher
and students and grade report, discipline are viewed by students and parent.

53
sd Dynamic Model

user
View Contents<Link> View Content<UI> View Content<Controler> DataBase<DB>

ClickLink
(1)

Select View types

(2)
⦁ Users: Teacher, Students,
Admin and parent HandleRequest
⦁ View contents: Timetable, (3)
Exam Schedule, Report,
Notice, Grade Report and RequestQuery
Discipline (4)

verify
(5)
DB_Error
(6)
Query
(7)
DisplayContents(8)

Figure 4.11: View Report sequence diagram

54
  Grade Report

sd Dynamic Model

Teacher
GradeReportLink<UI> GradeReportForm<UI> GradeReport<UI> GradeReport<Controler> Database<Db>

ClickLink
(1)

HandleRequest
(2)

DisplayForm
(3)
FillForm
(4)
*ClickAdd
(5)
HandleAdd
(6)

REquestConfirmation
(7)
Confirm
(8)

HandleConfirmation
(9)
Verify
(10)
Not Valid
(11)
SaveToDataBase
(12)

Verify
(13)
If_Error
(14)

If_Success
(15)
Feedback
(16)
Option
(17)

Select&Click_Generate
(18)
HandleGenerate
(19)

RequestQuery
(20)

Query
(21)
Display Grade
Report(23)

Figure 4.12: Generate grade report sequence diagram

55
 4.3.2. Activity Diagram
Activity diagrams are flow diagrams used to represent the data flow or the control flow
through a system. The activity diagram show parallel behavior of the different event and
activities. Behavior in several use case iteration can be shown swim line between them.
 Administrator side activity diagram
The figure 4.13 below describes how administrator perform his/her functionality such as creating
account, managing timetable, managing exam schedule, viewing reports and post notice.

act Dynamic Model

Display error
message

Invalid
Click login link Fill Login Click logoin
form button Validation

Start
Valid

Admin home

Click Account
link Click click Registration Click Dicipline
Link
Timetable/Exam Link
Click Notice link
Schedule link

Fill form Fill Form Select Registration Fill Form

type
Fill Form

Click Create Fill Form

button Click Record Button
Click Post
Invalid

Add Generate Update Delete

Validate
Click Register
Button
Valid Invalid Invalid
Validation
Validate
Account Created
Valid
Invalid
Invalid Valid
Validate Click Report Notice Posted Validation

link
Valid

Timetable/Exam
Schedule Report viewed User
Discipline
Registered
Managed recorded

Logout

End

Figure 4.13: Admin side activity diagram

56
  Teacher side activity diagram

The figure 4.14 below describes how teacher cares out their activities such as
recording attendance, preparing grade report and viewing notice, timetable and exam
schedule.

act Dynamic Model

Displat error
message

Invalid

Click Login link Fill login form Click login button

Validation
Start

Valid

Teacher home

click Attendance click Grade Views link

link Report link

Fill Form
Select view
fill Attendance type
form

Click save button

Click Add button Click Generate Click Update
Button
Viewed
Button

Invalid

Validate

Valid
Invalid
Attendance Validate
recorded

Valid

Mark added

Logout

End

Figure 4.14: teacher side activity diagram

57
  Other user activity diagram

The figure 4.15 below activity diagram describes how student view time table, exam schedule,
grade report and notice, parent view student discipline, student grade reports and comment and
Employee manage resources and generate grade report.

act Dynamic Model

Click Login link Fill login form Click login

button

Start

Display error Invalid

message Validate

Valid

User Type

Student Home Employee

Parent Home
Home

Click Report clink Resorce

link linck
Views link
Comment
Link

Report Detail &

Select View form Fill Resource
type Fill Comment Form
Form

Content Viewed
Click comment Generate
button Add Update
Update Delete
Add

Comment
Attached

Report managed

REsource managed

Logout

END

Figure 4.15: other user activity diagram

58
 4.3.3. State Diagrams
State are used to represent the behavior of nontrivial objects. A state chart diagram is a view of a
state machine that models the changing behavior of a state. State chart diagrams show the
various states that an object goes through, as well as the events that cause a transition from one
state to another.
The common model elements that state chart diagrams contain are:
 States
 Start and end states
 Transitions
 Entry, do, and exit actions
 Registration state machine diagram
stm Dynamic M odel

Registration
Link

Oncl i ck

Registration
Form

FILL
Form

Register button
active

Oncl i ck button

Inval i d
Display Error
Is Val i d message

val i d

Registered

Figure 4.16: Registration state machine diagram

59
  Account creation state machine diagram
stm Dynamic Model

Login Link

[Onclick link]

Login Form

[Fill Form]

login button

[Onclick button]

Is Display Error
Invalid
Valid?
Messege

Valid

DB
authentication

Not authenticated
Authenticated User home page
Display Error
Authentication
messege

Figure 4.17: login state machine diagram

60
  Generate Timetable, Exam schedule, transcript and report
stm Dynamic M odel

Ge ne ra te Link

OnCl i ck

Form

Fi l l Form

Ge ne ra te Button

OnCl i ck Button

Inval i d Displa y e rror

Validation me sse ge

Val i d

Ge ne ra te d

End

Figure 4.18: Generate various content state diagram

 Attendance record state machine diagram
stm Dynamic M odel

Attendance
Linck

OnCl i ck

Attendance
Form

Check Box

Save Button

OnCl i ck button

Inval i d Display Error

message
Val i d

Attendance
Recorded

Figure 4.19: Attendance record state machine diagram

61
  Resource record state diagram
stm Dynamic M odel

Record
resource Link

Start
OnCl i ck

Rsource Form

Fi l l and Oncl i ck button

Record Button

Inval i d Display Error

Validation message

Val i d

Resource
recored
end

Figure 4.20: Resource record state machine diagram

62
 CHAPTER FIVE

5. System Design
Systems design is the process of defining the architecture, components, modules, interfaces,
and data for a system to satisfy specified requirements. Systems design could be seen as the
application of systems theory to product development. In the previous chapter, we have
identified the functional and non-functional requirements of the system and produced the
analysis model. The following are discussed in this chapter: design goals, system architecture,
Subsystem decomposition, deployment, database design and object mainly, others also included.

5.1. System Overview

RSMS uses a client-server architecture; the back-end service is based around Microsoft
Xampp Server with some business logic handled by a custom PHP Framework module. The
client application is also built with, and handles almost all of the data manipulation and reporting
workload. SIMS is a modular application, the core offering covering storing basic school data
with modules available to handle (among other things) registration, the recording of
achievements and sanctions and the management and documentation of examinations scheduler.

5.2. Design Considerations

There are many aspects to consider in the design of a piece of software. The importance of
each consideration should reflect the goals and expectations that the software is being created to
meet. The RSMS is designed with better and sophisticated consider of the following set of
fundamental design aspects.

5.2.1. Design Goals

It deals with qualities of the system should developers optimize during design phase. Several
elements will impact and shape the design of the application. Such goals are normally derived
from the non-functional requirements of the system. These are:

Performance Criteria

Response time: The part of the system to be used for the record should have a fast response time
(real time) with maximum throughput.

63
Throughput: The system performs a number of tasks at given period of time do to efficient way
of design.

Memory: The system should not be taking up too much space in memory, about 2-4G memory is
enough to run the system.

Dependability criteria

The school needs the system to be highly dependable as it is expected to be used by non-IT
professionals. The system should be robust and fault tolerant. Furthermore, as the system is
handling sensitive data of the school, high emphasis should be given with regards to security, as
there are subsystems to be accessed through web.

Robustness: The system able to survive invalid user inputs such as character instead of number,
and case sensitive for upper cases and lower cases do to validation design.

Security: System use backup by using additional database server do to maybe system crash and
virus attacks.

Fault tolerance: If the system cased error it gives warring message to shows error that may
affect execution of program. This indicates the system not crash if it had an error.

Maintenance criteria

The system should be easily extensible to add new functionalities at a later stage. It should also
be easily modifiable to make changes to the features and functionalities.

Extensibility: The system is easy to add functionality and new class of the system do to easily
way of coding.

Modifiability: As the system coded with considering understandability of the system the
functionality of the system easily modified.

Readability: In the code system developed by putting comments on each lines, so easy to
understand.

64
End User Criteria

Usability: Usability is the extent to which a product can be used by specified users to achieve
specified goals with effectiveness, efficiency and satisfaction in a specified context of use. From
the end users’ perspective, the system should be designed in such a way that it is easy to learn
and use, efficient and having few errors if any.

5.2.2. Design Trade-offs

Trade-off is inevitable in trying to achieve a particular design goal. One best case is the issue
of security versus response time. Checking User-Id and Password before a member can enter to
the RSMS creates response time problem/overhead. The other case is the issue of response time
versus quality. There is some amount of time taken by the system to generate the functional
modules like reports and timetable. So, the user has to wait a little after telling the system to
generate the report timetable and getting the result to get a quality timetable.

Maintainability Vs Modularity: In RSMS bug fixes and functional modifications can be

accomplished. It has high maintainability because of better modularity and extensibility in terms
modularity comprises well defined, independent components which leads to better
maintainability. The components could be then implemented and tested in isolation. There is
division of work in a system development project.

Reusability Vs Usability: The RSMS will be able to use some or all the aspects of the
preexisting system modules in other projects with little to no modification. The system have
better user interface so it’s more usable for its target user. Default values for the parameters must
be chosen so that they are a good choice for the majority of the users.

Functionality Vs Scalability: The RSMS adapts well to increasing data or number of users
with handling such functionality that is easy to learn and operate. The User interface for this
system will be simple and clear. RSMS system is easy to use i.e. it doesn’t require special
training.

Performance Vs Portability: The system should have good performance i.e. fast response
time. In portability, the system should be machine independent so it can be moved different plat
forms.

65
 Security Vs Usability: There is strong user name and password in order to secure the system.
It is designed to be secure login feature which authenticates the user by means of a user name
and password with which user will be able to login to his/her respective pages and use the system
as required without affecting the usability of the system which interrupts users feeling to the
system.

5.3. Architecture of the System

A 3-tier application uses the client/server computing model. The RSMS uses this type
architecture where a client can use Internet browsers to access the online report provided by the
system within the local area network of the school or anywhere using the Internet. Figure 5.1
shows the architecture of the proposed system.

The data tier maintains the applications data such as student data, teacher data, timetable data
etc. It stores these data in a relational database management system (RDBMS).

The middle tier (web/application server) implements the business logic, controller logic and
presentation logic to control the interaction between the application’s clients and data. The
controller logic processes client requests such as requests to view student’s result, to record
attendance or to retrieve data from the database. Business rules enforced by the business logic
dictate how clients can and cannot access application data and how applications process data.

A web server is a program that runs on a network server (computer) to respond to HTTP
requests. The most commonly used web servers are Internet Information Server (IIS) and
Apache. The web server used in this system is IIS. HTTP is used to transfer data across an
Intranet or the Internet. It is the standard protocol for moving data across the internet.

The client tier is the applications user interface containing data entry forms and client side
applications. It displays data to the user. Users interact directly with the application through user
interface. The client tier interacts with the web/application server to make requests and to
retrieve data from the database. It then displays to the user the data retrieved from the server.

66
 Request/Response
HTTP
Request/Response

Transaction

Figure 5.1: Architecture diagram of the system

67
 5.4. Subsystem Decomposition
A subsystem decomposition, the activity of identifying subsystems, their services, and their
relationships to each other. Subsystem decompositions will help reduce the complexity of the
system. The subsystems can be considered as packages holding related classes/objects. The
RSMS under consideration is decomposed into subsystems as shown in figure 5.2. These
subsystems are further decomposed into other subsystems. The major subsystems identified as
following. Users also classified in to the following roles.

Account subsystem: it holds every users account to authenticate them. Contain the following
components

Login: authenticates a user to grant access based on the role of the user.
Logout: exit and stay out the user from the system.
Registration subsystem: subsystem optimization of student’s others registration to any subjects
available. In this part, all information related to student’s necessary for registration will fetched.
This information is not limited to Student profile information, it also included parent
information, and addresses information, academic, teacher’s information, admin information,
other staff’s information and emergency person. Contain the following components

Admin: registers and manage other users

Register and manage: included into admin
View subsystem: this subsystem helps user to view every generated reports according to user
type from user. Contain the following components.

Grade report: is used to generate transcript and report card.

Timetable: this will cover the information regarding time table of all classes subject wise
with their time of class and teacher concerned. This module will also provide time-table
information for staffs. It’s generated by admin and all information will be issued to any
user after login only.
Exam schedule: this is similar to the timetable, and used to view exam schedule after
generated by admin.
Attendance: subsystem facilitates recording absent students on the school day by the homeroom
teacher to control absentees and to report to parents and the administrator to take corrective
measures. Contains the following component

68
 Manage attendance: teacher controls student attendance status
Report: subsystem generates reports to parents, students and teachers to facilitate viewing
students’ status and course achievement online or may be discipline report from discipline
committee to view students discipline case. It has the following components

Generate report: teachers, admin and other staff generate report

View report: students, parents and teachers view the different reports
Discipline: subsystem used to generate students discipline case. Contain the following
component
Manage discipline: admin manages students discipline case.
Resource: subsystem used to store, update, delete and generate resources found on school.
Contain the following component

Manage resource: resource manager controls every new, used and outdated resources.
Participant subsystem: used to control an information of every user and describe their
relationship with another subsystem. Contain the following components

Student Information System: this is for students, after login they can view all their profile
information, manipulate their information subject details and ID.
Teacher: this is for teachers, after login they can view all their profile information, manage
student grade information, subject details and attendance.
Employee: this is for other staffs, after login they can view all their profile information, manage
resource.
Parent: this is for parent, after login they can view all their profile information, view students
information details and grade.
Notice: it is one of the sub system that administrator creates and post it, other users view the
notice like students, teacher, and parent.

69
 Report Substem View Subsystem

Grade
report
Generate view
report report access

Extend Exam
Timetable
schedule

Registeration
Subsystem Account Resourc Discipli
subsystem e ne

Admin
Extend Extend Login Logout Manage Manage
resource discipline

Register Manage
user user

lo
gi
n
Attendance Participants
subsytem

Student Employee
Manage Veiw status
attendance teachs

manage Teacher Parent

Figure 5.2: System decomposition diagram

5.5. Hardware/Software mapping

The web based system also assists parents and officials to get or view status and report on
students’ achievement and progress. The system assists the record officer to generate transcript
and report cards. So, the web based part is expected to run on a networked environment on
different Operating System platforms. The client/server architecture of the system enables
different clients to connect to the server remotely through Internet connection.

Deployment diagram is a diagram which shows architecture of the system as deployment of

software artifacts to deployment targets. Artifacts represent concrete elements in the physical
world that are the result of a development process.

We tried to show hardware software mapping as following in figure 5.3.

70
 Application Server

Registration

Account

Login

Attendance
Data Base Server
Client Computer
Timetable

Exam
Web Schedule Data Base
Browser
HTTP MYSQL
Notice

Resource
Chrome,
Mozilla Firefox
Report

Discipline

Grade Report

Student Data

Figure 5.3: Deployment diagram

5.6. Persistent data management

Persistent Data is data that exists from one instance to another. Data that exists across time
independent of the systems that created it. Now there’s always a secondary use for data, so
there’s more persistent data. A persistent copy may be made or it may be aggregated. The idea of
persistence is becoming more fluid. Persistent data is data that’s considered durable at rest with
the coming and going of software and systems. Here the following figure 5.4 shows data
management for RSMS.

71
 User<<Table>>
UId<<primary Admin<<Table>>
key>>
FirstName
MName AdminId<Primary key>
LastName UId<Foreign key>
Age
Gender Field
Phone
Address
Username
Password
Student<<Table>>
Parent<<Table>>
Teacher<<Table>>
StudId<primary key>
Parent_ID<primary
TR_ID<primary key> key>
UI<foreign key>
UId<foreign key>
UId<Foreign key>
Grade
Job
field
Section

Birthday

Employee<<Table>>
Resource<<Table>>
Class<<Table>>
EmpId<primary key>
RcId<primary key> RoomId<primary
UId<foreign key> key>
item StuId<foreign key>
Field
Name Room

Category

type

status

date

Attendance<<Table>>
GradeReport<<Table>>
att_id<primary key>
GrId<primary key>
StudId<foreign key>
StudId<foreign key>
Grade Semester
Section Grade

Semester Section

Status Subject

StudentName mark

StudentName
Year
Description

Figure 5.4: Persistent data management

5.7. User interface design

Describe the logical characteristics of interface between the system and the users. This may
include graphical user interface standards or product family style guides, screen layout
constraints and standard. The user interface consists of a set of menus through which the user can
interact with data on the scheduling system database server. These menus include home, about
us, help menu will be linked to some page to perform a specified task. The user will interact with
these menus through the pressing menus.
The interface includes the following structures:
Header: under the header logo, school name and logout link are included that shows what header
look likes.

72
Menus: links or buttons that help user what they want to preforms. Each menus depends on user
home page except main home page which is common for all users. For example in admin home
page account, login, view, timetable, notice and exam schedule links found, in record officer
home page registration, report, discipline, student information and grade report links found and
so on.
Contents: Form, displays and any system response messages are displayed here.
News: here some information are displayed such as about system, about the school such as
mission, aims and backgrounds of school and images.
Footer: some notifications such as open windows, performance issues, right copy of the system.

LOGO

RAS ZESELLASIE SCHOOL MANAGEMENT SYSTEM Sign In

Home Login Form News

About

User Name
Contact

Password

User Type

Login Reset

Forget password

Footer

Figure 5.5: Main Home page User Interface

The main home page of the system use to login in to the system by using user name and
password depending on user type.

73
 LOGO

RAS ZESELLASIE SCHOOL MANAGEMENT SYSTEM Logout

Home Contents

Menus

Footer

Figure 5.6: User Home Page User Interface

The user home page helps user to show what each user wants to functions in the system using the
menus listen on the left side of page.

5.8. Object Design

5.8.1. Interface documentation guidelines
In This section we will define rules or guidelines for naming variables, class attributes,
interface, exception and methods.

 Variables

Variable names should be descriptive and indicative of the variable’s use. For multiword
variables, the following notation will be used; the first letter of each word will be capitalized
if the variable contains multiple words except first word.

74
Examples:
integer stuId, age,phone;

double mark, average;

Varchar firstName, Subject;

 Classes

All classes are named with singular nouns or noun phrases, and the first letter of each word
should be capitalized.

Example:Admim, Student, Attendance

 Methods

All methods are named with verb phrases, and the first letter of each word should becapitalized
except first word.

Example:CreateAcount(), Register()

 Exception

When error occurs, the application will display an appropriate error message to the userand then
allow the user to terminate the application or close the error message andproceed with the
application.

 Various Notes

Forms, textboxes, command buttons, labels and so forth that are used for the interface will be
assigned names according to standard and conventional Notation.

Example: login button help user to login

 Database

Database fields are data base name, table name ant attributes that can be named using noun
phrases.

Example: Timetable, Attendance.

75
 5.8.2. Class interfaces
The class interface describes the content of the class such as class name, methods, attributes,
parameters, data type, and visibility and so on. It can be described in the table 5.1 below.
Class Methods and Attributes
class SMSClassDiagram Attributes
+FirstName: public, string and it contains first name of the user
User +Mnane: public, string and it contains middle name of the user
+ FirstName: String +LastName: public, string and it contains last name of the user
+ LastName: String +Age: public, int and it contains age of the user
+ MName: String
+Gender: public, string and it contains gender type of the user
+ Age: int
+ Gender: String +phone: public, int and it contains phone number of the user
+ Phone: int +Address: public, string and it contains address of the user
+ Address: String -UId: private, int and it contains user id of the user
- UId: int -password: private, string and it contains password of user
+ UserName: String
- password: String
-username: public, string and contains username of users
Methods
+ Register(): Void
+ Login(): Void +Login(): void, public and enable user to login to system
Precondition: the user should enter valid user name and password.
Postcondition: system validates and user logged in
+Register(): public, void and enable user to register user information
Precondition: user should be eligible
Postcondition: system verifies and stores in to database user information
class SMSClassDiagram
Attributes
Admin
-field: private, string and it contains administrator department field
- AdminId: int -AdminId: private, int and it contains administrator id
- Field: S tring
+ CreateAccount(): void Methods
+ Manage(): void
+ ViewReport(): void +CreatAccount (): void, public and it enables admin to create account for
+ RecordDiscipline()
the user
Precondition: The users first should be registered
Post condition: The users get an account to login to system
+Manage (): public, void and enables Admin to manages user informations
Precondition: Admin should have user data in the system to manage
Post condition: data managed
class SMSClassDiagram Attributes
-GrId: private, int and it contains student grade report id
GradeReport -studId: private, int and it contains student id
-Grade: public, int and it contains student grade level
- Description: String
- GrId: int
-studentname: public, string and it contains student name
+ Grade: int -section: public, string and it contains student section or room
+ Mark: int -semester: public, string and it contains semester grade report
+ Section: String -year: public, int and it contains year of grade report
+ Semester: int
- StudId: int 76
+ StudentName: String
+ Subject: String
+ Clear(): void
+ Delete(): void
 Methods
+Generate(): public, void and enables teacher to generate grade report
Precondition: teacher should collect mark via assignment, test, quiz and
exam then calculate it.
Post condition: student grade report generated.
+Clear (): public, void and enables teacher to clears form during filling
Precondition: if an error attributes may be happening when form filling
Post condition: teacher clicks clear button then existing form has been
cleared
+Update (): public, void and enables teacher to update student mark.
Precondition: teacher needs to upgrade previous mark then there should be
existing mark attributes
Post condition: student marks are updated
Attributes
-item: private, boolean and it contains item of the resource
-type: private, string and it contains types of the resource
+name: public, string and it contains name of the resource
+category: public, string and contains category of the resource
+date: public, int and contains the date of the resource
-status: private, string and it contains the status of the resource
-RcId: private, int and it contains id of the resource
Methods
+Record (): public, void and enables employee to record resource data
Precondition: employee collects and checks available resources then record
and save resources into database
Post condition: resource recorded in database
+Update (): public, void and enables user to update recorded resource
Precondition: the database must have recorded data to update
Postcondition: recorded resource updated with new record
+Delete (): public, void and enable user to delete recorded data from
database
Precondition: the database must have recorded data to delete
Postcondition: employee deleted recorded data
class SMSClassDiagram
Attributes
Teacher -TrId: private, int and it contains teacher id
-
-
Filed: String
Tr_ID: int -field: private, string and it contains department field of the teacher
+ ManageGradeReport(): void
+ RecordAttendance(): void
+ view(): boolean

Methods
+ManageGradeReport(): public, int and enable teacher to manage student
grade report.
Precondition: teacher should be collect all student marks and calculate it
Post condition: student grade report generated

77
 +RecordAttendance(), public, void and enables teacher to record student
attendance
Per condition: teacher should checks the student attendance
Post condition: student attendance recorded
+view(): public, boolean and enables teacher to view notice, timetable
class SMSClassDiagram Attributes
+StudId: public, int and it contains student id
Student
-Grade: private, int and it contains student grade level
- BirthDay: int
- Grade: int
-Sction: private, string and it contains student section or room
- Section: String -Birthday: private, string and it contains student birthday
+ StudId: int
Methods
+ View(): boolean
+view(): public, boolean and enables students to view timetable, exam
schedule, grade report, notice and discipline
class SMSClassDiagram
Attributes
Parent
-Parent_ID: private, int and it contains parent id
- Parent_ID: int
-Jop: private, string and it stores parents job type
- Jop: S tring
+ View(): boolean
Methods
+ Comment(): void +view(): public, void and enables parent to view their student information
+comment(): public, void and enables parent to give comment on student
information
Precondition: parent should fill comment field
Post condition: comment is submitted on student
class SMSClassDiagram
Attributes
Employee
EmpId: private, int and it contains employee id
- EmpId: int Field: private, string and it contains employee’s department field
- Filed: String
+ ManageResource(): void
Methods
+ GenerateReport(): void +ManageResource(): public, void and enables employee to manage
resources
Per condition: employee should record all recorce information first
Post condition: resource managed
+generateReport(): public, void and enables employee to generate resource
reports.
per condition: resource should be managed first
Post condition: report is generated
Table 5.1: class interface

78
Appendix
Appendix 1.1 Student registration form

79
Appendix 1.2 Report form

Appendix 1.4: Time table form

80
Appendix 1.3: Attendance form

81
Appendix 1.4: Grade report

82
References
1. E. Burke and W. Erben. Practice and Theory of Automated Timetabling, Third International
Conference, Germany, Springer Private Limited, August 2000
2. J. G. Hedberg et. al. (1992). Educational information systems: Problems of the small
educational organisation. Australian Journal of Educational Technology, 8(2), 132-160.

3. Mr. Kean Tak, MSc, Lecturer and IT Project Management, School management system

4. Degif Teka, School of Graduate Studies of Addis Ababa University, Degree of Master of
Science in Computer Science, School management system, June 2008

5. Ras zeSellasie school documents and magazines

83