ARSI UNIVERSITY

COLLEGE OF NATURAL AND COMPUTATIONAL SCIENCES

DEPARTMENT OF COMPUTER SCIENCE

Title: Arsi University Model School Web-based Management

System
SUBMITTED TO DEPARTMENT OF COMPUTER SCIENCE

IN PARTIAL FULFILMENT OF THE REQUIREMENT FOR

THE DEGREE OF BACHELOR OF SCIENCE IN COMPUTER SCIENCE

BY:
NO. Name ID E-Mail Phone

1. Andualem Mokonin CCS/UR7924/11 andi.mack85@gmail.com +251927979728

2. Feyisa Demise CCS/UR7735/11 eiseieakewak@gmail.com +251919648017

3. Kaku Zerihun CCS/UR7738/11 kaku13zarihun@gmail.com +251933980081

4. Tefera Kunbushu CCS/UR7762/11 tefera13kumbi@gmail.com +251954629897

5. Usman Kufa CCS/UR7948/11 usmankufa9@gmail.com +251911749925

Advisor: Musa Ahmed (MSc)

Submission date: March 07, 2022

Asella, Ethiopia
DECLARATION
This is to declare that this project work which is done under the supervision of Mr. Musa Ahmed
and having the title ARU Model School Web-based Management System is the sole contribution
of: Tefera Kunbushu, Feyisa Demise, Usman Kufa, Kaku Zerihun, and Andualem Mokonin.

No part of the project work has been reproduced illegally (copy and paste) which can be considered
as Plagiarism. All referenced parts have been used to argue the idea and have been cited properly.
We will be responsible and liable for any consequence if violation of this declaration is proven.
Date: 27/02/2022
Group Members:

Full Name Signature

1. Andualem Mokonin ____________________

2. Feyisa Demise ____________________

3. Kaku Zerihun ____________________

4. Tefera Kunbushu ____________________

5. Usman Kufa ____________________

i
APPROVAL FORM
This is to confirm that the project report entitled ARU Model School Web-based Management
System submitted to Arsi University, College of Natural and Computational Sciences,
Department of Computer Science by: Tefera Kunbushu, Feyisa Demise, Usman Kufa, Kaku
Zerihun, and Andualem Mokonin are approved for submission.

Advisor Name Signature Date

------------------------------------------------- ------------------------------ ---------------------

Department Head Name Signature Date

------------------------------------------------- ------------------------------ -------------------

Examiner 1 Name Signature Date

------------------------------------------------- ------------------------------ -------------------

Examiner 2 Name Signature Date

------------------------------------------------- ------------------------------ -------------------

Examiner 3 Name Signature Date

------------------------------------------------- ------------------------------ -------------------

ii
Acknowledgment
First of all we would like to praise Lord, and we would like to thank our department of computer
science to give us necessary courses and give us this final project to know more about all courses we
have learned and we would like to thank all of our group members who contribute their full effort &
cooperation and also we would like to thank our classmate. Secondly, the highest thanks to our
advisor Musa Ahmed (MSc). For his guidance and constructive comment, advices and help as to
complete this project finally, thanks to peoples who have directly or indirectly support to complete
this project.

iii
Contents
DECLARATION................................................................................................................................i
APPROVAL FORM..........................................................................................................................ii
Acknowledgment..............................................................................................................................iii
List of Figures..................................................................................................................................vii
List of Tables.....................................................................................................................................ix
Acronym and Abbreviation................................................................................................................x
Chapter one.........................................................................................................................................1
1. Introduction.................................................................................................................................1
1.1. Background of the Organization...........................................................................................1
1.1.1. Motivation for the project..........................................................................................................2
1.2. Statement of problem............................................................................................................2
1.3. Objectives of the Proposed System..........................................................................................3
1.3.1. General Objective............................................................................................................................3
1.3.2. Specific Objectives..........................................................................................................................3
1.4. Feasibility Study......................................................................................................................3
1.5. Significant of the Project......................................................................................................4
1.6. Scope and Limitation of the project.........................................................................................4
1.6.1. Scope.........................................................................................................................................4
1.6.2. Limitation of project..................................................................................................................6
1.7. Methodology of the project..................................................................................................7
1.7.1. Data Collection Tools and Techniques......................................................................................7
1.7.2. System analysis and design......................................................................................................7
1.7.3. System development model.......................................................................................................8
1.7.4. System Testing Models..............................................................................................................8
1.8. System Development Tools and Techniques...........................................................................9
1.8.1. Software Tools................................................................................................................................9
1.8.2. Hardware Tools...............................................................................................................................9
CHAPTER TWO..............................................................................................................................10
2. Existing System Description.....................................................................................................10
iv
 2.1. Introduction to Existing System............................................................................................10
2.2. Users in the Existing System.................................................................................................10
2.3. Major Functions of Existing System.....................................................................................11
2.4. Forms used in the existing system......................................................................................11
2.4. Drawbacks of Existing System...........................................................................................20
2.5. Business Rules in the Current System................................................................................21
CHAPTER THREE..........................................................................................................................22
3. PROPOSED SYSTEM..............................................................................................................22
3.1. System Description................................................................................................................22
3.2. Functional Requirements of Proposed System......................................................................22
3.3. Non-Functional Requirement.............................................................................................23
3.3.1. User Interface and Human Factors.............................................................................................23
3.3.2. Hardware Consideration..........................................................................................................24
3.3.3. Security Issue............................................................................................................................24
3.3.4. Performance Consideration........................................................................................................24
3.3.5. Error Handling and Validation...................................................................................................24
3.3.6. Quality Issues..........................................................................................................................24
3.3.7. Backup and Recovery..............................................................................................................25
3.3.8. Physical Environment..............................................................................................................25
3.3.9. Resource Issue..........................................................................................................................26
CHAPTER FOUR............................................................................................................................27
4. SYSTEM ANALYSIS..............................................................................................................27
4.1. System Model.....................................................................................................................27
4.1.1. Use Case Modeling..................................................................................................................27
4.2. Object Model......................................................................................................................38
4.2.1. Class diagram..........................................................................................................................38
4.2.2. Data Dictionary.......................................................................................................................40
4.3. Dynamic Model..................................................................................................................41
4.3.1. Sequence Diagram...................................................................................................................41
4.3.2. Activity Diagram.....................................................................................................................54
4.3.3. State Chart Diagram................................................................................................................60
CHAPTER FIVE..............................................................................................................................65
5. SYSTEM DESIGN...................................................................................................................65
5.1. Design Goals.......................................................................................................................65
v
 5.2. Proposed System Architecture............................................................................................66
5.2.1. Subsystem Decomposition and Description.............................................................................68
5.2.2. Hardware/Software Mapping...................................................................................................69
5.2.3. Detailed Class Diagram...........................................................................................................70
5.2.4. Persistent Data Management....................................................................................................72
5.2.5. Access Control and Security....................................................................................................76
5.3. Algorithm Design...............................................................................................................77
5.4. User Interface Design.........................................................................................................78
References........................................................................................................................................80
APPENDICES..................................................................................................................................81

vi
List of Figures
Figure 1.1 Iterative model.................................................................................................................................8
Figure 2.1: Exam Schedule.............................................................................................................................12
Figure 2.2 teacher assignment figure...............................................................................................................13
Figure 2.3 back of report card grade 5-6.........................................................................................................14
Figure 2.4 front of report card grade 7-8.........................................................................................................15
Figure 2.5 front of report card 5-6...................................................................................................................16
Figure 2.6 back of report card grade 7-8.........................................................................................................17
Figure 2.7 form for accepting new student......................................................................................................18
Figure 2.8 form for leaving school..................................................................................................................19
Figure 2.9 Transcript.......................................................................................................................................20
Figure 4.1: Use case Diagram.........................................................................................................................28
Figure 4.2: Class diagram................................................................................................................................39
Figure 4.3: Sequence Diagram for login..........................................................................................................41
Figure 4.4: Sequence Diagram for registering student....................................................................................42
Figure 4.5: Sequence Diagram for admin create account................................................................................43
Figure 4.6 sequence diagram for delete account..............................................................................................44
Figure 4.7 sequence diagram for add class......................................................................................................45
Figure 4.8 Generate report...............................................................................................................................46
Figure 4.9 sequence diagram for change password.........................................................................................47
Figure 4.10 sequence diagram for student view report...................................................................................48
Figure 4.11 sequence diagram for update user................................................................................................49
Figure 4.12 sequence diagram for upload mark...............................................................................................50
Figure 4.13 sequence diagram for update student mark..................................................................................51
Figure 4.14 sequence diagram for take attendance..........................................................................................52
Figure 4.15 sequence diagram for exam schedule...........................................................................................53
Figure 4.16 Shows activity diagram for login.................................................................................................54
Figure 4.17 shows activity diagram for post information................................................................................55
vii
Figure 4.18: shows activity diagram for generate transcript............................................................................56
Figure 4.19 shows activity diagram for registration........................................................................................57
Figure 4.20 shows activity diagram for insert mark........................................................................................58
Figure 4.21 shows activity diagram for create account....................................................................................59
Figure 4.22 shows activity diagram take attendance.......................................................................................59
Figure 4.23: state Diagram for login...............................................................................................................60
Figure 4.24: State Diagram for Admin create account....................................................................................61
Figure 4.25: State diagram for admin edit account..........................................................................................62
Figure 4.26: State Diagram for Admin delete account....................................................................................63
Figure 4.27 state diagram for insert mark........................................................................................................64
Figure 5.1 Architecture of the System.............................................................................................................67
Figure 5.2 subsystem decomposition Diagram...............................................................................................68
Figure 5.3 Deployment Diagram....................................................................................................................69
Figure 5.4 Component Diagram.....................................................................................................................70
Figure 5.5 show class diagram........................................................................................................................71
Figure 5.6 User Interface.................................................................................................................................78
Figure 5.7 Login interface...............................................................................................................................79

viii
List of Tables
Table 4.1 Admin create account.........................................................................................................29
Table 4.2 register student and parent use case description.................................................................30
Table 4.3 teacher update mark............................................................................................................31
Table 4.4 Admin view record.............................................................................................................32
Table 4.5 generating schedule use case description............................................................................33
Table 4.6 Report use case description.................................................................................................33
Table 4.7 shows that Generating Transcript use case description......................................................34
Table 4.8 shows Search and view use case description......................................................................35
Table 4.9 Student view mark..............................................................................................................36
Table 4.10 shows Login use case description.....................................................................................37
Table 4.11 shows Attendance Record use case description................................................................37
Table 4.12 shows that use case description of delete user account.....................................................38
Table 4.13: Data Dictionary................................................................................................................40
Table 5.1 Class Diagram Documentation...........................................................................................72
Table 5.2 Admin Persistent diagram...................................................................................................73
Table 5.3 Table of Student.................................................................................................................74
Table 5.4 Table of Parent...................................................................................................................74
Table 5.5 Table of Student Mark........................................................................................................75
Table 5.6 Table of Subject.................................................................................................................75

ix
Acronym and Abbreviation
ARU - Arsi University.
BR-Business Rule
CD-Compact Disk.
CSS- Cascading Style Sheet.
DVD-Digital Versatile Disc.
GUI-Graphical User Interface.
HTML- Hyper Text Markup Language.
JS-JavaScript.
HTTP- Hypertext Transfer Protocol
URL- Uniform Resource Locator
KM-Kilo meter.
MS-Microsoft.
MySQL-MySQL Structured Query Language.
OO-Object Oriented.
PC-Personal Computer.
PHP-PHP: Hypertext Preprocessor.
RDBMS-relational database management system
SMS-School Management System.
UML-Unified Modeling Language.
WAMP-Windows, Apache, MySQL, and PHP.
XAMPP-cross-platform, Apache, MySQL, PHP and Perl.

x
Abstract
The system developed in our project, School Management System (SMS), provides users use
simple, and efficient way of maintaining student information. It can be used by educational
institutes or schools to maintain the records of students easily. Achieving this objective is
difficult using a manual system as the information is scattered, can be redundant and
collecting relevant information may be very time consuming. All these problems are solved
using this project. Our project is very useful for those who want to know about School
Management Systems and want to develop software/websites based on the same concept. The
project provides facilities like online registration and profile creation of students thus
reducing paperwork and automating the record generation process in an educational
institution. This document contains the introduction, methodology that uses tools like
Notepad++, Visual studio code, and PHP, data sources like site observation, interview and
document analysis, and for design methodology we use object oriented. For analysis model
we use case diagram, sequence and activity diagram. For system design we include
deployment diagram, UI design, and component diagram, for the project that is going to be
developed.

xi
 Chapter one
1. Introduction
Education system forms the backbone of every nation. School Management System (SMS) is one of
the education system that consists of tasks such as registering students, attendance record keeping and
control absentees of students, preparing and producing different reports for teachers and students, and
the others. Automation is the utilization of technology to replace a human with a machine that can
perform more quickly and more continuously but this system is not fully automated. And hence it is
important to provide a strong educational foundation to the young generation to ensure the
development of open-minded global citizens securing the future for everyone. 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. Education is central to development.
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 tools is to have an
automated school management system. A school management system is a large database system
which can be used for managing school’s daily work.

1.1. Background of the Organization

Arsi University is one of the public institutions of higher learning in Ethiopia, established in 2014(2006 E.C) by
decree No.322/2014 of the Council of Ministers of the Federal Democratic Republic of Ethiopia. Arsi University
started with four Colleges and one School, namely; College of Agriculture and Environmental Sciences, College of
Health Sciences, College of Business and Economics and College of Humanities and School of Law. As a higher
education institution, Arsi University has set itself core responsibilities, with a focus on regionally and nationally
relevant teaching-learning programs, problem-solving, research projects, and community-based services. In
accordance with its core mission, that is, contributing to the economic development of Ethiopia, Arsi University is
committed to promoting practical research culture and dissemination of findings to end-users and appropriate
stakeholders. Within the context of academic institutions, it is evident that quality and relevant research contributes
significantly to the search for excellence and to the ongoing efforts to ensure quality learning and teaching with the
ultimate goal of cultivating and nurturing the new generation for the future of Ethiopia. The significance of
1
research for changing the lives of the immediate and wider communities and improving their wellbeing is beyond
doubt.

ARU Model School found in central part of Oromia Region in Asella town, which is a capital town of Arsi Zone.
The school established in 1956 E.C and 159KM away from capital city of the country. For many years the school
was continued teaching the students by taking many students in elementary school. ARU model school was passed
many problems and now a time this school has been giving a great contribution to the communities. The school is
increased taking capacity of female students and made them be competitor in central parts of Ethiopian schools and
they can succeed in their knowledge and experience as well as their marks.

1.1.1.Motivation for the project

The reason why we motivate to do this project is that we understand the benefits of using computerized
system for the organization and consider the technological growth. Today in this competitive world
every work has been become computerized. The manual way of working has become very tedious,
time consuming as well as very difficult. So when we got the opportunity to make school management
system computerized we made use of it. In ARU Model School all tasks done manually weather
adding students’ information, teacher information, and any relevant information. Manually added by
one or more people, this make burden for saving information. With the existing scenario the work
become very time consuming and needed more labor and facing several problems during work. On
the other hand, as graduate students this kind of project requires to apply courses that we have been
studied in Arsi University. Therefore, we are going to develop this web based school management
system, by observing and analyzing problems that faced in the daily activities of the schools and to
come up with better solution.

1.2. Statement of problem

To promote students achievement and success, schools must have access to complete, accurate, and timely
information about students. ARU Model School is using a paper-based system for performing various tasks and the
school vice directors apply their knowledge of hit and miss approaches in scheduling classes and subject (preparing
the timetable) which wastes manpower and much time unnecessarily that does not utilize the current technology.
Transcripts of students are prepared manually by the record officer and teachers. Report cards are produced by the
home-room teachers. Attendance of students is recorded by the home-room teachers. In order to control absentees
and know the number of days that a student has been absent from the school during the school days the attendance

2
officer has to collect the attendance slips from the corresponding homeroom teachers and compile it which is also a
time taking . Teachers may want to associate a student with his parent or emergency persons for disciplinary
measures which need searching of the students record in the record office. It has been difficult to search a record
from thousands of such records and observed that students can take any person claiming that he/she is their parent
or emergency person which creates problem in control of students.

1.3. Objectives of the Proposed System

1.3.1. General Objective
The main objective of this project is to develop web based school management system for ARU
Model School.
1.3.2. Specific Objectives
In order to attain the general objective, the following list of specific objectives is set:
 Study the existing system and identifying the problems
 Gather requirements
 Study related works and literatures
 Analysis the requirements
 Keep the overall records associated with property into permanent database
 Solve data security problem
 Deploy the system.

1.4. Feasibility Study

Feasibility studies are an evaluation and analyzing of a proposed project to determine if it (1) is technically feasible,
(2) is economically feasible and (3) is operationally feasible or not. 
1.4.1. Economic feasibility
This feasibility checks whether the system can be developed with the available funds. Economic feasibility
identifies that whether the new developing system is economically feasible or not. The proposed system is feasible
with the available fund. This system run on small device smart phone there is no need of buying more sophisticated
device and the system can run almost on every operating system and there is no need of buying software to use the
system. It simply run web browsers. So the system can avoid wastage of materials like paper, pen, printers which
are used in existing system. This cost easily buy input materials for new system that is going developed.

3
 1.4.2. Operational feasibility

The new system can provide sufficient service for the students. The system is operationally feasible as it very easy
for the end users to operate it. The system will correct match with the operation performed in existing system like
registering student, preparing transcript and exam schedule, preparing report card. This all operation are also
included in proposed system.

1.4.3. Technical feasibility

This determines whether the technology needed for the proposed system is available or not. It concerned with
specifying equipment and software that will successfully satisfy the user requirement. The aspects of this feasibility
are operating System compatible and proposed system is fit with currently available technology which mean the
technology currently available like computer generation, network, and available programming language. So our
system will develop by using current available hardware and software.

1.5. Significant of the Project

Now a days we are living in an information age, so everything is changed from the manual system to automated
system, which makes everything simple, interactive, time saving and requires less storage space for allocating
resources. Improve the capability of the student, and teacher by communication between them through different
means like teacher comments on student marks. Provide more timely and update information for school students
like exam day and class end day. Reduce work load on the employees like costs and time consumption. Time
consuming activities (tasks) will be reduced simply by using automated system and reduce man power & material
budget allocations. Generally proposed system have many significances for all actor in terms of reducing labor,
time for completing different tasks like generating report card, generate transcript , view mark , taking attendance ,
announcing information, inserting student mark , controlling student and many more. Especially system have best
significance in terms avoiding redundancy of information and extravagances in storing them in hard copy format
and make easier for searching for specific information which seems difficult in existing system.

1.6. Scope and Limitation of the project

1.6.1. Scope
This project is delimited Web-based School Management System for ARU Model school. There are many
limitations that the team will encounter while developing the project, so the project team will probably plan to
4
accomplish at least the following bulleted functionalities that used to manage the school and allows the
administrators to register the daily required information of Students, Teachers & office staff. School Management
System will organize work inside school and the system boundary including functions like:-

 Register, update, and delete student’s information.

 Register, update, and delete sections and subjects information’s.

 Register, update, and delete employees information

 Taking student attendance: - teacher call his class student name and send their status whether their present
or not .It is not the system that take attendance by its own. It like existing system but there is no need of
paper that have student name.
1.6.1.1. Scope In
Scope In means what a new features that is added to the system. Our proposed system add the following
features.
System admin
 Create ,update and delete user account
 View employee and comment
Record officer
 Register students
 Generate report and transcript
Teacher
 Enter, view and update student mark
 Take attendance
Director
 Post information
 Verify documents
 View students and comment
Vice Director
 Register class room and Subject
 Prepare Exam schedule
 Prepare class schedule

5
 Students
 View result and comment
Record Officer
 Register student and parent
 Generate Report
Parent
 View Their student status like
 Report
 Comment
 Attendance status
1.6.1.2. Scope Out
 Android based app is not developed because we don’t have knowledge of developing android

 Club Organization in the school is not included to the system

 E-library

 Employees Attendance not taken

 ID deliver for student is not included

 Online exam and teacher evaluation are not included

 Photo profile not included in the system because our system have no to identify whether one
person photo is used for more than one person which is prohibited.

1.6.2. Limitation of project

The limitation of this project described as the following:

 Blind can’t use the system

 People who can’t read or write can’t use the system.

 The system is not operate without network

6
1.7. Methodology of the project
A system development method refers to the framework that is used to structure, plan, and control the
process of developing an information system
1.7.1. Data Collection Tools and Techniques
We are going to do a thorough research and inspection to gather the right amount of data needed
to develop this system either directly from the client or by research methods. The methodologies
some specific methods we will use to collect this data include:

 Interviewing: This is one of data collection method that enables to gather information
from the organization directly in the form of asking question and getting answers for
those questions. So, our team uses this method to gather information by asking the
director, co-director, teachers and students of the school some basic questions.

 Observation:-This is also another data collecting method. In fact we have also used this
observation method to gather data. This method enables us observing and understanding
how the teaching and learning process is done. In doing so; we have got some manual
material from school.

 Written document

1.7.2. System analysis and design

The system analysis and design approaches for this project we used the object oriented system
analysis & design [6]. Because

 It provides code and function reuse through the concepts of inheritance,

polymorphism, encapsulation, modularity, coupling and cohesion.

 To design the system the project team has choose Object Oriented Modeling
techniques and Unified modeling language tools.
 Understanding of the structure is easy because object oriented modeling and tools

7
 used to represent real world entities.
 Modification of the object implementation is easy because objects are loosely
coupled.

1.7.3. System development model

The system development model for this project will be iterative model for the following reasons
[5].Iterative model: -this model starts from simple implementation of a small set of the software
requirements and iteratively enhances the evolving versions until the complete system is applied and
ready to be deployed.

 It goes to forward and backward.

 Used to add new feature on the system.
 Reuse concepts of inheritance.

Figure 1.1 Iterative model (source: https://www.geeksforgeeks.org/software-engineering-iterative- -model/)

1.7.4. System Testing Models

System Testing is a type of software testing that is performed on a complete integrated system to evaluate the
compliance of the system with the corresponding requirements. Before directly deploying this system the team
will perform different testing for its functionality and meeting customers need [7]. First the team tests each unit
at each phase. So, if a problem is encountered it will immediately fixed. Second the team will perform an
integration testing to check whether the system meets all the functional requirements. In order to deliver this

8
system as well operated system to test this project at implementation phase by using different types of testing
methodologies. Those testing methods are:

 Alpha testing:-In this testing method, the system will tested by giving the correct input. It is tested by a
customer at the developer Site.

 Beta testing: -In this testing method, team will force the system to be tested for incorrect data input.

1.8. System Development Tools and Techniques

1.8.1. Software Tools
 Wamp/Xampp/MySQL: - to create and design the database which is used to store the
information.

 Browsers: -since our system is web based, it’s a very necessary requirement.

 HTML, PHP, JavaScript and CSS: using for static and dynamic part of the website and
for the style of the website [5].
 Microsoft Word: - it is very useful because it takes less time to write and format the
text, communicate effectively smart diagram and chart tools, quickly assemble document
[11]. By looking its useful properties we use Microsoft word to type our project work to
get all the above benefits of it.
 Microsoft PowerPoint:-use to present the document in abstract forms [4]. We use it to
present our presentation in short and brief way.
 Edraw-max
1.8.2. Hardware Tools
We have used and are using different hardware tools to develop our project.
 Computer: -computer is a machine capable of doing many things. We use it to type on it
and install all software and programming language.
 Flash Disk and CD Hardware: - used for the movement of data from one machine to
another. We use both of the devices when we move our data from one machine to
another.
 Stationery: Stationery like paper, pen and so on that were need. All these are necessary
things that we need to do and use.
 Disks (CD, DVD): necessary for the movement of relevant data and for backup and
9
 recovery mechanism.
 Network cable: since our system is web based, it is very necessary requirement. It also
helps us to extract relevant information about our project from internet.

CHAPTER TWO
2. Existing System Description

2.1. Introduction to Existing System

Existing system focuses on registering of students, registering new employees, managing students and teacher’s
data, exchanging of reports between the offices of the school. 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. 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 teacher also records attendance of each student on each school day
which is later organized by the attendance officer. Transcripts of students are prepared manually by the record
officer. A student may request transcript when he/she wants to transfer to other school. Report cards are produced
by the home-room teachers. Attendance of students is also recorded by the home-room teachers. In order to control
absentees and know the number of days that a student has been absent from the school during the school days the
attendance officer has to collect the attendance slips from the corresponding homeroom teachers and compile it
which is also a time taking process. In addition to that retrieving records of students who have graduated couple of
years ago has been a difficult task. These problems make the school to lead a poor management system are: -
loosing of teachers and students document, difficulty to generating transcripts of students, updating employee’s
data. Teachers may want to associate a student with his parent or emergency persons for disciplinary measures
which need searching of the students record in the record office. It has been difficult to search a record from
thousands of such records and observed that students can take any person claiming that he/she is their parent or
emergency person which creates problem in control of students.

2.2. Users in the Existing System

 School Director and vice directors

10
  Parent
 Teacher
 Student
 Record Officer

2.3. Major Functions of Existing System

The Major Activities Done in Existing System are listed below:
Registration of students
Input: Necessary student information.

Process: Writing all information on forms

Output: student registration

Distribute Report card and transcript for student

Input: Inputs the student mark for each

subject

Process: calculating necessary information form marks.

Output: report card and transcript for student

2.4. Forms used in the existing system

ARU Model School is using a paper-based system for performing various tasks .Transcripts of students are
prepared manually by the record officer and teachers. Report cards are produced by the home-room teachers.
Attendance of students is recorded by the home-room teachers. Record officer generate transcript using Microsoft
excel for each student then print it in the form of hard copy and give student. Some form of the existing system in
ARU Model schools are listed below which are report card , transcript ,letter for leaving school, letter to be accepted
to the school, class schedule, exam schedule and teacher assignment to subject and class.

11
12
Figure 2.2: Exam Schedule

F
i
g
u
r
e

.
3

teacher assignment figure

13
Figure 2.4 back of report card grade 5-6

14
Figure 2.5 front of report card grade 7-8
15
Figure 2.6 front of report card 5-6

16
Figure 2.7 back of report card grade 7-8
17
Figure 2.8 form for accepting new student

18
19
 Figure 2.9 form for leaving school

Figure 2.10 Transcript

2.4. Drawbacks of Existing System

The team reviews many problems in the manual school management system for instance: Generate many
information with some level of difficulty. Do not sufficiently produce the required reports to allow parents
to view status of their children. Do not facilitate attendance record keeping of teacher and student as
well as schools material. The identified problems of the existing system can be classified into
performance problem, information problem, economic problem, efficiency problem and.
Performance problem

 Delay time on searching information, because it is manually arranged.

20
  Difficulty in generating reports.

Information problem

 It takes long time to view the data’s of students and teachers.

 It is difficult for searching the documents.
 It is very difficult to memorize the exact shelf location of documents.
 It is not more enough to exchange information between school members quickly.

Economical problem
 The management is economically affected because it is manual based system. Due to this it
consumes a large space to store all documents; it needs a huge budget to paper, pen, shelf and
other materials.
Efficiency problem
 Takes time to find a specific and general information of the teachers and students

2.5. Business Rules in the Current System

The Business Rules that are involved in the current school management system:-

 BR1:-Any student that full fills the registration will be registered which if he/she get pass mark for
senior student
 BR2:-Each student must wear uniform cloth when they come to the school.

 BR3:-Any students are not learning without their class.

 BR4:-If student does not take test, mid exam or final exam it will be incomplete which
mean his total mark is not calculated

 BR5:-Student can register only once.

 BR6:-Student can’t have more than one mark result per subject

 BR7:-Transcript generate only when semester are completed.

 BR8:-Report card is generated when first and second semester of academic year is
completed
21
  BR9:-Student mark must submitted on time.

CHAPTER THREE
3. PROPOSED SYSTEM

3.1. System Description

The proposed system is the new system which is going to replace the manual or the existing system. The proposed
system is used to provide an efficient management system and to reduce the system complexity. This can be
accomplished by developing an automated system. The proposed system is mainly deals with the all activities how
all actors are work in their position. It is the same as with the existing system, but the proposed system is a solution
for existing system. The proposed system must perform all functional and nonfunctional requirements. The new
system is nothing it is an implementation of the manual system by using new or automated system. It can do most
all activities performed under existing system.

This project work tries to fill the gap by automating the various activities at schools. It tries to satisfy customers
need and simplify the works of actors in the system. With an automated school management system parents can
easily interact with the school community to follow up their children’s achievement and play their role in the
school development processes.

 Registering, updating, inserting, and deleting student’s information.

 Registering, updating, inserting, and deleting employee’s information.

 Generate student report when needed

3.2. Functional Requirements of Proposed System

Functional requirements describe the interaction between the system and its environment independent of its implementation.
It describes what the system should do. The functional requirements of the system are registering student, generating
transcript and report card, take attendance, register class room and subject, manage users account, and manage student data
and verifying document.
The system shall allow system admin to
 Manage user account
The system shall allow Record officer to

22
  Register students
 Generate report and transcript
The system shall Teacher to
 Enter, view and update student mark
 Take attendance
The system shall allow Director to
 Post information
 Verify documents
 view students
The system shall allow Vice Director to
 Register class room
 Prepare Exam schedule
 Prepare Class schedule
 Register Subject
The system shall allow Students to
 View result (it can be per course or all together)
 View comment
The system shall allow Record Officer to
 Register student and parent
 Generate transcript and Report card
The system shall allow Parent to
 View Their student status like
 Transcript and report card
 Comment
 Attendance status

3.3. Non-Functional Requirement

As the name suggests, non-functional requirements are requirements that are not directly concerned with the
specific functions delivered by the system. These are constraints on the services or functions offered by the system.
The non-functional requirements of the system are described as follows:-

23
 3.3.1. User Interface and Human Factors
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.

3.3.2. Hardware Consideration

SMS should use high speed computers, Memory, Network cables and other materials that speed up the system work
flow to gain maximum efficiency from it. System will run on hand held electronic device which mean any users
which have hand held device like:- Smartphone, tablet, lab top.
3.3.3. Security Issue
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.
3.3.4. Performance Consideration
This new system will have good performance rate when executing user’s input and provide response within
a short time period.
3.3.5. Error Handling and Validation
The new system will be capable of dealing gracefully with errors, not stopping at the first sign of trouble.
Additionally, it is easy to separately monitor the presence and performance of each component of the
system, in order that support the school staff can identify and deal with any errors or overload that does
occur.

3.3.6. Quality Issues

Accessibility

 The system will be load quickly, and be viewable in different browsers, operating systems and
monitor resolutions.

Design

 SMS websites have a design that is visually appealing, readable, easy to navigate, and reinforces
the purpose of the site while giving it a unified look and feel. The Web Style Guide is an
excellent resource for the basics of website, Web page, and Web graphic design

24
 Availability

 The system should be available for access 24 hours, 7 days a week.

Usability

 The system shall have a help support. The user can use the system by reading help and
support or manual of the project.

Maintainability

 New capabilities can be added to the system without major changes to the basic design.
The system will be easily maintained by the developer or other authorized trained person
and it shall respond as fast as possible in generating report and producing the timetable.

3.3.7. Backup and Recovery

A backup or the process of backing up refer to making copies of data so that these additional copies may be used to
restore the original after a data loss event. There are several realistic methods for backing up data. Some of them
are Flash Memory, DVD Backup, Tape Backup, cloud storage, and Hard Drives. The best backup method for data
depends upon many factors, including: the importance of the data, the amount of data to be backed up, and the
funds available for backup. These additional copies are typically called "backups." Backups are useful primarily for
two purposes.

1. The first is to restore a state following a disaster (called disaster recovery).

2. The second is to restore small numbers of files after they have been accidentally deleted or
corrupted.

3.3.8. Physical Environment

Since Arsi university is currently growing in technology issues from time to time. Its main data center may afford
server machine to deploy the system effectively. The system is expected to withstand the following external factor.

 Less processor speed of personal computer that are caused by dust and other unnecessary things
happened in client computers for accessing the system.

 Less power that causes the system fail or stop functionality.

25
  The server and the other devices in which system installed should kept in a secured and air-
conditioned rooms.

3.3.9. Resource Issue

SMS will be deployed on Arsi University server without buying new server for configuration. All users
should be able to access an SMS with a web browser. The project team used different tools to implement
the new system. Such as:-
 Programming language: HTML, CSS, PHP and JSP for front end code and MYSQL for
backend.
 SMS should run on any Window operating system

26
 CHAPTER FOUR
4. SYSTEM ANALYSIS

4.1. System Model

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 object model, and dynamic models.
4.1.1. Use Case Modeling
An essential use case is complete meaning full and well design form the point of view on users in
some rolls. In relation to system and that embodies the purpose or intention underlining the
interaction. The essential use case diagram shows a collection of use cases, actors, their
association and a system, boundary box. A use case describes sequence of action that provides a
measurable value to an actor and is drown as horizontal ellipse. It identifiers use case and actors
of the proposed system.

27
28
 Figure 4.11: Use case Diagram
4.1.2. Use case description
Name Create account
ID UC1
actor admin
Pre-condition
A student has to In order to create account fill form which is given to them.
Post condition New account being Registered.
Basic Course of (1) Admin clicks on registration or create account link.
Action
(2) Controller load.

(3) The user fills Registration.

(4) The system Validate User Information with controller.

(5) The system acknowledges admin like that you successfully add user.

(6) Use case ends.

Alternate A: The system validates user information is not valid.
A4: The error controller notify user via from dialog.
Course of Action
A5. Use case continues with basic course of action 3.

A6.The use case end.

Table 4.1 Admin create account

Name: Register Student and parent

ID UC2
Actors Record officer
Description To register someone as a student of the school.
Name Registration
Pre-condition Student has to be eligible. (Has to be from the pre-specified junior schools that the
school will accept). If he/she come from other school.

29
 If junior or new student no need to eligible which mean he/she have only come with
parent and easily registered

Post condition Students are Registered.

Basic Course of (1) Record officer clicks on registration link.
Action
(2) Controller load.

(3) Record officer fills all information.

(4) The system Validate User Information with controller.

(5) The system acknowledges like that you are registered.

(6) Use case ends.

A: The system validates user information is not valid.
A2: The error controller notify user via from dialog.

A3.Use case continues with basic course of action 3.

A4.The use case end.

Name: Updateand
Table 4.2 register student student mark
parent use case description
ID UC3
Actors teacher
Description The teacher updates the student marks.
Name Update
Pre-condition The teacher must be logged in and update information
Post condition The information is updated

30
Basic Course of 1. The teacher is click on update link.
Action 2. The controller load
3. The teacher fills the information via update student mark.
4. The system validates user information with controller.
5. The system displays output.
6. End of use case

Alternate A: The system update student mark information is not valid.

A5. The controller notify user via from dialog.
Course of Action
A6. The use case continue with basic courses of action..3

A7.The use case continues from step 3.

Table 4.3 teacher update mark

Name: Record view
ID UC4
Actors Admin
Description The Admin view the recorded information
Name Record view
Pre-condition The Admin must be log in and check the system record.
Post condition All the records of school information like student data submitted to the system.
Basic Course of 1. The Admin click on Record View link.
Action 2. The controller loads the link.
3. The Admin checks the recorded information via Record
View.
4. The admin solves any problems related to record to the
system..
5. The use case ends.

Alternate A: The systems validate recorded information is not valid.

A3. The error controller notifies Admin via from dialog.
31
Course of Action A4. Use case continues with basic course of action 3.

A5. The system acknowledges.

A6: Use case end.

Table 4.4 Admin view record
Name: Generate schedule
ID UC5
Actors Vice director
Description To generate time table (schedule) for teachers and classes.
Name Generate timetable
Pre-condition
: There should be t There should be subject teachers and classes for which the timetable is to be
produced
Post condition The system generates time table.
Basic Course of 1. Vice director clicks on Generate time table link.
Action
2. controller loads the link

3. Vice director teacher registers schedule

4. Vice director assign classes for each subject teacher by filling a form and
then submits it

5. The system validates user information with the controller.

6. The system generates the timetable.

7. System displays the result.

8. Use case ends

Alternate A: No teacher is registered to be assigned to classes.
A5. The system cannot generate timetable
Course of Action
A6:Use Case continue with basic course of action of3
32
 A7. Use case ends.
Table 4.5 generating schedule use case description

Actors Record officer

Description To give report of student information to the families and record office.
id UC6
Name Report
Pre-condition
: There should be the Record officer has to be specified for a given class.
Post condition Sends the report to the system.
Basic Course of 1. The Record officer click on Report link.
Action
2. The controller loads the link.

3. The teacher checks the report of a student and fills and also submit.

4. The system Validate user information with controller.

5. The system generates the report.

6. use case end

Alternate A: The system validates user information is not valid.
A5. The error controller notify user via from the dialog.
Course of Action
A6. Use case continues with basic course of action 3.

A6. Use case ends.

Table 4.6 Report use case description.

Name: Generate transcript

ID UC7
Actors Record officer
Description To produce transcript based on the request of a student
Name Record officer

33
Pre-condition student must have completed at least a semester to have grade report
Post condition The system generates transcript
Basic Course of 1.The Record officer clicks on the link
Action
2. The Controller loads the link

3. The record officer logs in and searches the students record from the database
based on the search criteria

4. The system processes the transcript

5. System displays and print the result

6. Use case ends

Alternate A1.The system validate user information is not valid.
A3. The error controller notify user via from dialog.
Course of Action
A4. Use case continue with basic course of action 3

A4. Use case ends

Table 4.7 shows that Generating Transcript use case description
Name: Search and view
ID UC8
Actors Record officer
Description The Record officer searches student

Name Search
: There should be
Pre-condition The Record officer wants to retrieve the student information from the data
base based on search criteria in order to record student information for each
student.
Post condition Search from the database.
Basic Course of 1. The record officer click on search button.
Action 2. Controller loads the link.

34
 3 The record officer search student.

4. The record officer retrieves from data center.

5. The record officer checks the student data.

6. The system validates user information with controller.

7. use case end

Alternate A: The system validates user information is not valid.
A5. The error controller notify user via from dialog.
Course of Action
A6.Use case continue with basic course of action 3

A7. Use case ends

Table 4.8 shows Search and view use case description.
Name: View mark
ID UC9
Actors Student
Description To inform the students status to their parents.
Name View mark
Pre-condition
: There should be t The Student’s information must filled
Post condition View to the Student
Basic Course of 1.Student click on links
Action
2. Controller loads the link.

3 student fill form

4. The system validates user information with the controller

5. Student view their

6. use case end

35
Alternate A: The system validates user information is not valid.
A3. The error controller notify user via from dialog.
Course of Action
A4. Use case continue with basic course of action 3

A5. Use case end.

Table 4.9 Student view mark
Name: Login
ID UC10
Actors Student, teacher, admin, record officer, director, parent, and vice director.
Description To access any information all actors except parents and to communicate with in the
school and to facilitate teaching and learning process in the school.
Name Login
Pre-condition Student, teacher, admin, record officer, director, parent, and vice director are
logged in
Post condition Students, teachers, admin, record officer and Director access school
information.
Basic Course of 1.All user click on login link
Action
2. Controller loads the link.

3. All user fill user name and password.

4 The system validates user information with controller.

5. use case end

Alternate A: The system validates user information is not valid.
A3. The error controller notify user via from dialog.
Course of Action
A4. Use case continue with basic course of Action 3

A5. Use case end.

Table 4.10 shows Login use case description.
Name: Attendance record

36
 ID UC11
Actors Teacher
Description To check present and absent.

Name Attendance
Pre-condition
: There should be Attendance form is should be checked by teacher and Admin, i.e.
Homeroom teacher checks student attendance and Admin checks also
teachers.

Post condition Attendance should be submitted to the system.

Basic Course of 1. The homeroom teacher or Director click on attendance record link
Action 2. Controller loads the link.

3.The teacher or director check attendance

4. The teacher or Director submits daily Attendance to the system.

5. The system validates information with the controller.

6. use case end

Alternate A: The system Validate user information is not valid.
A3. The error controller notify user via from dialog.
Course of Action
A4. Use case continue with basic course of action 3

A5. Use case end.

Table 4.11 shows Attendance Record use case description
Name: delete User Account
ID Uc12
Actors Admin
Description To create an account to the users.

37
Name Create user Account
Pre-condition User should exist in the system

Post condition User removed from the system

Basic Course of (1) Admin click on delete account t.
Action
(2) Controller load.

(3) The system Validate User Information with controller.

(4) The system acknowledges admin information like that you delete user
successfully

(5) Use case ends.

Alternate A: The system validates user information is not valid.
A2: The error controller notify user via from dialog.
Course of Action
A3.The use case end.

Table 4.12 shows that use case description of delete user account.
4.2. Object Model
4.2.1. Class diagram
A class is a set of objects that share a common structure and a common behavior (the same attributes,
operations, relationships and semantics) and an abstraction of real world items [1]. When these
items exist in the real world they are instance of the class and are referred to as objects, and an
object can be any person, place, and concepts or user interfaces.

38
 Figure 4.12: Class diagram

4.2.2. Data Dictionary

39
Means a file or a set of files that includes a database’s metadata (hold records about other objects in the
database), like data ownership, relationships of the data to another object, and some other data [13] .
Table 4.13: Data Dictionary
Attribute name Description
User
user_id To uniquely identify a user of the system
Fname To store first name of user
Mname To store middle name of user
Lname To store middle name of user
Password To store password of user
userType To store account type
Address Stores the users recent address
Ph_no Stores users contact number
Email Stores email address of employee
Student
Stud_Id To uniquely identify student in the system
Fname To store first name of student
Mname To store middle name of student
Lname To store last name of student
Sex To store sex of student
Date_of_Brith To store date of birth of student
Place_of_birth To store place of birth of student
wereda To store wereda of student
kebele To store Kebele of student
Grade To store first grade of student which he /she learn
Section To store section of student
Parent_Id To identify uniquely of parent in the system
Stud_Id To store student id
Fname To store first name of parent
Lname To store last name of parent
sex To store sex of parent
kebele To store Kebele of student
job To store occupation of parent
phone To phone number name of parent
email To store email of parent
Subject
subject_Id To store subject id and identify subject uniquely
Subject_Name To store subject name
Period_per_week To store subject period
Student mark
Stud_Id To store id of student
Subject_Id To store id of subject
Acadamic_year To store academic year of subject
Semester To store semester at which the subject given
status To store status in of mark pass or fail
Mark To store of student

40
 4.3. Dynamic Model
A dynamic model represents the behavior of an object over time. It is used where the object's
behavior is best described as a set of states that occur in a defined sequence.

4.3.1. Sequence Diagram

A sequence diagram shows object interactions arranged in time sequence. It depicts the objects and classes
involved in the scenario and the sequence of messages exchanged between the objects needed to carry
out the functionality of the scenario.
Sequence diagrams show the interaction between participating objects in a given use case. They are helpful
to identify the missing objects that are not identified in the analysis object model.
The following sequence diagram describes the identified use cases.

Figure 4.13: Sequence Diagram for login.

41
Figure 4.14: Sequence Diagram for registering student

42
Figure 4.15: Sequence Diagram for admin create account

43
Figure 4.16 sequence diagram for delete account

44
Figure 4.17 sequence diagram for add class

45
Figure 4.18 Generate report
46
Figure 4.19 sequence diagram for change password

47
Figure 4.20 sequence diagram for student view report

48
Figure 4.21 sequence diagram for update user

49
50
 Figure 4.22 sequence diagram for upload mark

Figure 4.23 sequence diagram for update student mark

51
52
Figure 4.24 sequence diagram for take attendance

Figure 4.25 sequence diagram for exam schedule

53
 4.3.2. Activity Diagram
Activity diagram is another important to describe the dynamic aspects of the system. Activity diagram is
basically a flowchart to represent the flow from one activity to another activity. The activity can be described
as an operation of the system. The activity diagrams are shown as the following diagram

54
Figure 4.26 Shows activity diagram for login

55
Figure 4.27 shows activity diagram for post information
56
57
Figure 4.28: shows activity diagram for generate transcript

Figure 4.29 shows activity diagram for registration

58
Figure 4.30 shows activity diagram for insert mark

59
Figure 4.31 shows activity diagram for create account

Figure 4.32 shows activity diagram take attendance

60
 4.3.3. State Chart Diagram

A state diagram is used to represent the condition of the system or part of the system at finite instances of
time. It’s a behavioral diagram and it represents the behavior using finite state transitions. State diagrams
are also referred to as State machines and State-chart Diagrams. These terms are often used
interchangeably. So simply, a state diagram is used to model the dynamic behavior of a class in response to
time and changing external stimuli. We can say that each and every class has a state but we don’t model
every class using State diagrams. We prefer to model the states with three or more states .

Figure 4.33: state Diagram for login

61
Figure 4.34: State Diagram for Admin create account

62
Figure 4.35: State diagram for admin edit account

63
Figure 4.36: State Diagram for Admin delete account

64
Figure 4.37 state diagram for insert mark

65
 CHAPTER FIVE
5. SYSTEM DESIGN
System design has a great part which describes the first solution of the system problem. So
designing a system is the necessary step in any computer system. System design provides a
clear description of the overall design of ARU Model School system, bridging the gap
between the desired and existing system in a manageable way. 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, system
decomposition, deployment and database design.

5.1. Design Goals

Design goals describe the qualities of the system that developers should optimize. Such goals are
normally derived from the non-functional requirements of the system. Design goals are
grouped into four categories. These are

 Performance
 Dependability
 Maintenance
 End User Criteria
Performance Criteria
The part of the system to be used for the record office should have a fast response time (real
time) with maximum throughput. Furthermore, the system should not be taking up too much
space in memory. The record officer has chosen fast response time over throughput and hence
the system should try to be more interactive. In the case of the timetabling subsystem, the system
should be more reliable in order to satisfy the constraints than fast response time

66
 Dependability
The school needs the system to be highly dependable as it is expected to be used by none 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 the web.
Maintenance
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.
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. 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 SMS (School Management System) creates response
time problem/overhead. The other case is the issue of response time versus quality

5.2. Proposed System Architecture

The proposed system is expected to replace the existing manual system by an automated system in all
facets. It is mainly based on the system Analysis document (chapter 4).

The architecture used for the system is a 3 tier Client/Server 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 below 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).

67
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 and Apache. The
web server used in this system is Apache. 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.

Figure 5.38 Architecture of the System

68
 5.2.1. Subsystem Decomposition and Description

Subsystem decompositions will help reduce the complexity of the system. The subsystems can
be considered as packages holding related classes/objects. The SMS under consideration is
decomposed into subsystems as shown in Figure 5.2. These subsystems are further decomposed
into other subsystems. The major subsystems identified are Student Registration, Login,
Attendance, Report Card, Transcript, Schedule, Subject and Post information sub systems. Users
are classified in to roles. The Login subsystem authenticates a user to grant access based on the
role of the user. The Student Registration subsystem registers a student online. It allows
recording the detail information of the student including parental and emergency person.
Transcript and Report Card subsystems are used to generate transcript and report card
respectively. The Timetable or Schedule subsystem generates a timetable, which involves
allocating a time slot to a subject teacher for a class of students.

Figure 5.39 subsystem decomposition Diagram

69
 5.2.2. Hardware/Software Mapping
One of the major tasks in system design deals with hardware/software mapping which deals with
which components would be part in which hardware and so on. The School Management system
is a broad system that performs many functions. It consists of web based system used by
homeroom teachers to record attendance and submitting report card. The system assists the
record officer to generate transcript and register parent and student. 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. The system has two nodes such as the Web server and Clients.
These nodes are shown as UML Deployment diagrams in Figure 5.3. The nodes can represent
specific instances (workstations) or a class of computers (web server), which is a virtual
machine.

Figure 5.40 Deployment Diagram

70
 The applications of the system will run on the web server connected to the database server. The
system has one application to be developed on the same database, its Web applications. Users
merely need to start their browsers and enter the URL of the application Web site. The server
hosting the Web site is responsible for allocating all the resources the Web application requires.

Figure 5.41 Component Diagram

5.2.3. Detailed Class Diagram
A class diagram gives an over view of a system by shows its class and the relationship among them.
Class diagram are static they display what they do interact. In class

Diagram class is represented as a rectangle, where three compartments, the first compartment depicts
the class name, the second depict its attribute of class and the third represent its operations. The Form
Diagram allows you to generate diagram automatically with user-defined scope.

71
Figure 5.42 show class diagram

72
 Table 5.14 Class Diagram Documentation
Class name Attributes Operation or their function Data type

Admin Fname,Mname,Lname,ID Create account for all user and register Varchar()for(Fname ,
Password them, view them Mname, Lname
)Stringor(ID,Password)

Teacher Fname, Mname, Lname, Insert mark Varchar()for(Fname ,

ID, sex and age View post Mname, Lname ,Sex
information ),String for(ID,int for
,age)
Employee Fname,Mname,Lname, Being to Registered by admin Varchar()for(Fname ,
ID, sex ,age,phone no Mname, Lname ,Sex
)String for ID ,int for
,age and phone no
)
Student Sfname,smname,slname View mark and view comment Varchar()for(Fname ,
Sid,ssex,sage Mname, Lname ,Sex
)String for ID ,int
for,age )
Record office Fname,Mname,Lname,ID Register student,employees Generate Varchar() for all
,sex transcript

Director Fname,Mname,Lname,userid Verify document post information Varchar for all

,sex

5.2.4. Persistent Data Management

Persistent data storage and management deals with how the persistent data (file, database, etc)
are stored and managed and it outlives a single execution of the system. Information related to
student basic information, student’s attendance and grade mark, the timetable or schedule
produced and other related information are persistent data and hence stored on a database
management system. This allows all the programs that operate on the SMS data to do
consistently. Moreover, storing data in a database enables the system to perform complex queries
on a large data set. Tables are related to each through their primary and foreign key. Also each
Table has Attribute with compatible data type.
73
The following table is description of the above persistent data storage
Table 5.15 Admin Persistent diagram

Administrator

Filed Name 1. Data Type 2. Description 3. Key 4. Length/Value

user_id 5. Varchar Not Null 6. PK 10

F_Name Varchar Null 50

M_Name Varchar Null 50

Username Varchar Null 50

Password Varchar Null 50

Usert-ype Varchar Null 7. 50

Request_status Varchar Null 8. 50

74
 Table 5.16 Table of Student

Student
Filed Name 1. Data Type 2. Description 3. Key 4. Length/Value
Stud_ID Varchar 5. Not Null 6. PK 10
F_Name Varchar Null 50
M_Name Varchar Null 50
L_Name Varchar Null 50
Sex Varchar Null 10
Age Varchar Null 2
Date_of_Birth Date Null 10
Place_of_birth Varchar Null 20
Woreda Varchar Null 20
Kebele Varchar Null 20
Phone No Int Null 20
Grade Varchar Null 20
Section char null 2
Table 5.17 Table of Parent
Parent/ Emergency Contact

7. Filed Name 8. Data Type 9. Description Key Length/Value

Parent_ID Varchar Not Null PK 16
Stud_ID Varchar Not Null FK 10
F_Name Varchar Null 50
M_Name Varchar Null 50
L_Name Varchar Null 50
Sex Varchar Null 10
Woreda Varchar Null 20
Kebele Varchar Null 20
Job Varchar Null 40
Place of Work Varchar Null 40
Phone No Int Null 20

75
Table 5.18 Table of Student Mark

Student Mark

Filed Name Data Type Description Key Length/Value

Stud_ID Varchar Not Null PK 10

Subject_ID Varchar Not Null PK 7

Semister Varchar Not Null PK 5

AcedamicYear Int Not Null PK 8
GradeSection Varchar Null 10

Status Varchar Null 50

Mark Float Null 20

s
Table 5.19 Table of Subject

Subject

Field Name Data Type Description Key Length/Value

Sub_ID Varchar Not Null PK 10

Subject Name Varchar Null 30

GradeSection Varchar Null 10

Period per Varchar Null 20

Weak

76
 5.2.5. Access Control and Security
The proposed system of School management system provides login account and password
for administrators. For example there is a mechanism of data encryption for passwords.
And the other mechanism is using session variables for the user so that when the user
leaves the main page of the system these session variables would be destroyed. We uses the
following access control mechanisms in particular:
Username: It is a name we use in order to be able to use a computer program or system.
The user identification is that which is required to access the system. This command will
normally be the first command given by the user.
Password: It is a secret word or phrase that you need to know in order to login to a system.
The password must be immediately preceded by the user name.
Actors Access
Create Manage View
Admin account account users View comment
Director View Post Verify
student informat docum
ion ent
Vice Add Add Exam Assign
director class subject schedu home
le room
teache
r
Record View Update Prepar
officer Register student student record e
and parent
transcr
ipt
teacher Insert Update View
mark mark student
mark

77
 Home Take Generate
room attenda report
teacher nce card
student View View
mark commen
t

5.3. Algorithm Design

An algorithm is a specific procedure for solving a well-defined computational problem. The
development and analysis of algorithms is fundamental to all aspects of computer science: artificial
intelligence, databases, graphics, networking, operating systems, security, and so on. Algorithm
development is more than just programming. It requires an understanding of the alternatives
available for solving a computational problem, including the hardware, networking, programming
language, and performance constraints that accompany any particular solution. It also requires
understanding what it means for an algorithm to be “correct” in the sense that it fully and efficiently
solves the problem at hand. There are some algorithm that are going to use in our system to
calculate total mark student got, rank of student.
Algorithm to calculate total mark student got
Step 1: start
Step 2: read marks m1, m2, m3 ...m10
Step 3: calculate sum = m1+m2+m3+…+m10
Step 4: store sum
Step 5: stop
Algorithm to calculate average mark student got
Step 1: start
Step 2: read sum
Step 3: average= sum/10
Step 4: store average
Step 5: stop
Algorithm to determine whether student pass or fail
78
Step 1: start
Step 2: read sum
Step 3: if sum greater than or equal pass mark go step 4 else got step 5
Step 4: store pass
Step 5: store fail
Step 6: stop
5.4. User Interface Design

79
Figure 5.43 User Interface

Figure 5.44 Login interface

80
 References
[1]Arnold, K., Gosling, J. and Holmes, D., 2005. The Java programming language. Addison
Wesley Professional.
[2]Bartsch, R.A. and Cobern, K.M., 2003. Effectiveness of PowerPoint presentations in
lectures. Computers & education, 41(1), pp.77-86.
[3]. Brookshear, J.G., 1991. Computer science: An overview. Benjamin-Cummings Publishing
[4]. Craig, R.J. and Amernic, J.H., 2006. PowerPoint presentation technology and the dynamics of
teaching. Innovative higher education, 31(3), pp.147-160.
[5]. Duckett, J., 2011. HTML & CSS: design and build websites (Vol. 15). Indianapolis, IN: Wiley.
[6]. Fincher, Sally, Marian Petre, and Martyn Clark, eds. Computer science project work: principles
and pragmatics. Springer Science & Business Media, 2001.
[7]. Fowler, M., 2004. UML distilled: a brief guide to the standard object modeling language.
Addison-Wesley Professional.
[8]. Gupta, S., Kaiser, G., Neistadt, D. and Grimm, P., 2003, May. DOM-based content extraction of
HTML documents. In Proceedings of the 12th international conference on World Wide Web (pp.
207-214).
[9]. Jensen, S.H., Møller, A. and Thiemann, P., 2009, August. Type analysis for JavaScript.
In International Static Analysis Symposium (pp. 238-255). Springer, Berlin, Heidelberg.
[10]. Lerdorf, R., Tatroe, K. and MacIntyre, P., 2006. Programming Php. " O'Reilly Media, Inc.".
[11]. Makhija, P.G., Belludi, A., Bhardwaj, A., Bhatia, V., Navlani, M. and Tomar, G., 2013.
Customized Digital Case Presentation Template in Microsoft Word 2007. Journal of Indian
Orthodontic Society, 47(1), pp.44-47.
[12]. Musciano, C. and Kennedy, B., 2002. HTML & XHTML: The Definitive Guide: The Definitive
Guide. " O'Reilly Media, Inc.".
[13]. Welling, Luke, and Laura Thomson. PHP and MySQL Web development. Sams Publishing,
2003.

81
 APPENDICES

Algorithm to calculate total mark student got

Step 1: start
Step 2: read marks m1, m2, m3 ...m10
Step 3: calculate sum = m1+m2+m3+…+m10
Step 4: store sum
Step 5: stop
Home page code
</table>
<table align="center" style="width:900px;border-radius:12px;border:1px solid
black;background:white url(img/tbg.png) repeat-x left top;" height="70px" ><tr>
<td id="link">
<p style="text-align:right;padding-right:30px;"><a href="index.php">Home</a>|<a
href="about.php">About us</a>|<a href="contact.php">Contact US</a></p>
<p ><hr width="350px" align="right"></p>
<p style="text-align:right;padding-right:30px;"><font color="#ffffff">copyright &copy; 2012
protected.</font></p>
</td>
</tr>
</table>
<li ><a href="index.php"><h2>Home</h2></a></li>
<li><a href="contacts.php"><h2>Contact</h2> </a></li>
<li><a href="contacts.php"><h2>help</h2></a></li>
<li><a href="login.php"><h2>Login</h2></a></li>

82