Student Information Menagement System

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 99

Genius Land College

Department of Information Technology

A senior project submitted for the partial fulfillment of degree program


at department of Information Technology

Student Information Management System (SIMS) In Case of Abdi Boru


Primary and Secondary School

By

NAME ID

Temesgen Dejene E/22/11

Husni Zeyenu E/28/11

Ahmed Jibril E/18/11

Mohammed Alo E/31/11

Kabe Adare E/35/11

Advisor

Instructor Hailu

Date: 08/23/2022

i
Submitted by

Temesgen Dejene _____________________ August 23, 2022

Signature Date

Husni Zeyenu _____________________ August 23, 2022

Signature Date

Ahmed Jibril _____________________ August 23, 2022

Signature Date

Mohammed Alo _____________________ August 23, 2022

Signature Date

Kabe Adare _____________________ August 23, 2022

Signature Date

Approved by

1. Instructor Hailu _______________________ August 23, 2022

Advisor Signature Date

2. __________________ ______________________ ____________________

Chairman, Dept.’s Signature Date

Senior project Committee

Department

3. _______________________ ___________________ ___________________

Head of the Dep.t Signature Date

ii
DEDICATION

We dedicate this project to our dear parents for their moral and financial support: brothers,
sisters, friends, course mates, lecturers, and our supervisor. Inst. Hailu and Moti for their helpful
guidance, suggestions and comments which helped to accomplish this task And to our Almighty
Father in Heaven, glory be unto You forever and ever.

iii
ACKNOWLEDGMENT

First and foremost our most profound gratitude goes to the Almighty God, who enables me to
finalize the project successfully.

Next, our appreciation goes to our Advisor Instructor Hailu for their constructive advice, helpful
guidance, and wise suggestions and comments from the beginning to the completion of the
project.

iv
ABSTRACT

The Student Information Management System (SIMS) provides a simple interface for the
maintenance of student information. It can be used by educational institutes or schools to
maintain the records of students easily. The creation and management of accurate, up-to-date
information regarding a student's academic career are critically important in the school as well as
in colleges. Student information system deals with all kinds of student details, student-related
reports, school details, subject details, curriculum, school session details, placement details, and
other resource-related details too. It tracks all the details of a student from day one to the end of
the course which can be used for all reporting purposes, tracking of attendance, progress in the
course, completed semesters, years, coming semester year curriculum details, exam details,
project or any other assignment details, online interface embedded in the school website. It will
also have faculty details, batch execution details, students’ details in all aspects, and the various
academic notifications to the parent and students updated by the school administration. It also
facilitates us to explore all the activities happening in the college, Different reports and Queries
can be generated based on vast options related to students, batch, course, faculty, exams,
semesters, certification, and even for the entire school.

v
ABBREVIATIONS

PHP Hypertext Pre-processor

SIMS Student Information Management System

HTML Hypertext Markup Language

CSS Cascading Style Sheets

JS JavaScript

MYSQL My Structure Query Language

XAMPP Cross-Platform Apache Mariadb PHP Perl

DFD Data Flow Diagram

UML Unified Modeling Language

HDD Hard Disk Driver

RAM Random Access Memory

CGAAEB City Government of Addis Ababa Education Bureau

vi
Table of Contents
Dedicated ......................................................................................................................................III
Acknowledgment .......................................................................................................................... Iv
Abstract ............................................................................................................................................v
Chapter One .....................................................................................................................................1
1. Introduction ................................................................................................................................1
1.1.Background .................................................................................................................2
1.2.Statement Of The Problem ..........................................................................................2
1.3.Objectives ....................................................................................................................3
1.4.1. General Objectives ......................................................................................3
1.4.2. Specific Objectives ....................................................................................3
1.4.Methodology ...............................................................................................................4
1.4.1. Data Collection Method ................................................................................4
1.4.2. Software Development Methodology ...........................................................4
1.5. System Development Tools ........................................................................................5
1.5.1. Front End development tools ..........................................................................5
1.5.2. Back End development tools ..........................................................................6
1.6. Scope ..........................................................................................................................8
1.7. Limitation ...................................................................................................................8
1.8.Significance Of The Project ........................................................................................9
1.9.Feasibility Study ...........................................................................................................9
1.9.1. Technical Feasibility ....................................................................................10
1.9.2. Operational Feasibility .................................................................................10
1.9.3. Economical Study .........................................................................................10
Chapter Two...................................................................................................................................11
2. Literature review ......................................................................................................................11
2.1. Observed Products .....................................................................................................11

Chapter Three.................................................................................................................................13
3. Existing System ......................................................................................................................13
3.1.Description Of The Existing System .........................................................................13
3.2.Major Function Of The Current System ....................................................................13

vii
3.3.Drawback Of The Current System ...........................................................................13
3.4. Business rule of the current system .........................................................................14
Chapter Four ..................................................................................................................................15
4. Proposed System .....................................................................................................................15
4.1. Functional Requirement ...........................................................................................15
4.2.Non-Functional Requirement ....................................................................................16
4.2.1. User Interface ..............................................................................................16
4.2.2. Privacy ..........................................................................................................16
4.2.3. Usability .......................................................................................................16
4.2.4. Workability ..................................................................................................17
4.2.5. Efficiency .....................................................................................................17
4.2.6. Accessibility ................................................................................................17
4.2.7. Portability ....................................................................................................17
4.2.8. Concurrency ...............................................................................................17
4.2.9. Maintainability ...........................................................................................17
4.2.10. Error Handling ..........................................................................................18
4.2.11. Documentation ..........................................................................................18
4.2.12. User friendly ................................................................................................18
4.2.13. Security .....................................................................................................18
4.2.14. Availability ...............................................................................................18
4.2.15. Reliability......................................................................................................19
4.2.16. Correctness ................................................................................................19
4.2.17. Modification ..............................................................................................19
4.2.18. Backup .......................................................................................................19
4.2.19. Hardware Consideration ..............................................................................19
4.2.20. Software Consideration .................................................................................20
4.2.21. Performance consideration ...........................................................................20
4.3.System model .............................................................................................................20
4.3.1. Use case model ............................................................................................20
4.3.2. actor description ..........................................................................................22
4.3.3. Use case description .....................................................................................23

viii
4.4.Object Model .............................................................................................................31
4.4.1. Data dictionary .............................................................................................31
4.4.2. Sequence diagram ........................................................................................35
4.4.3. Activity diagram ..........................................................................................45
4.4.4. State diagram ...............................................................................................50
4.4.5. Data Class diagram .......................................................................................52
4.4.6. Deployment diagram ....................................................................................53
Chapter five ....................................................................................................................................54
5. System design .........................................................................................................................54
5.1.DFD ............................................................................................................................54
5.2.Purpose .......................................................................................................................54
5.3..Design goal ................................................................................................................55
5.3.1. performance ..................................................................................................55
5.3.2. Maintenance ..................................................................................................55
5.3.3. End user ........................................................................................................55
5.3.4. Priorities of Design goal ...............................................................................55
Chapter Six.....................................................................................................................................57
6. Implementation ......................................................................................................................57
6.1.High level design .......................................................................................................58
6.2.Process view ..............................................................................................................58
6.3.Development view .....................................................................................................59
6.3.1. Subsystem Decomposition ............................................................................59
6.3.2. Subsystem description ..................................................................................59
6.4.Testing ........................................................................................................................60
6.4.1. Unit testing ....................................................................................................60
6.4.2. Integration testing .........................................................................................60
6.5.physical view ..............................................................................................................60
6.6.Persistent data management .......................................................................................61
6.6.1. Data schema view ........................................................................................61
6.6.2. Mapping class to table ..................................................................................70
6.6.3. Relationship mapping ..................................................................................70
6.7.Access control ............................................................................................................71
ix
6.7.1. User interface mode ......................................................................................72
Chapter Seven ................................................................................................................................82
7. Conclusion and Recommendation ........................................................................................82
7.1.conclusion ..................................................................................................................82
7.2. Recommendation ....................................................................................................82
References ......................................................................................................................................83
annex I ...........................................................................................................................................84
Some algorithm ..............................................................................................................................84
annex II .........................................................................................................................................84
Questioner .....................................................................................................................................84
annex III ........................................................................................................................................85
User Interface Usability Testing Checklist ....................................................................................85

x
List of Table
Table 4.1 use case for create account ............................................................................................23
Table 4.2 use case description for class assigns ............................................................................24
Table 4.3 use case description for assign unit leader ....................................................................25
Table 4.4 use case description for generate score report ..............................................................26
Table 4.5 use case description for record student .........................................................................27
Table 4.6 use case description for generate student result report card ..........................................28
Table 4.7 use case description for record attendance ....................................................................29
Table 4.8 use case description for view report ..............................................................................30
Table 4.9 data dictionary for parent table ......................................................................................31
Table 4.10 data dictionary for subject table ..................................................................................31
Table 4.11 data dictionary for section table ...................................................................................31
Table 4.12 data dictionary for student table ..................................................................................32
Table 4.13 data dictionary for teacher table ..................................................................................33
Table 4.14 data dictionary for attendance table .............................................................................34
Table 4.15 data dictionary for unite leader table ..........................................................................34
Table 4.16 data dictionary for user table .......................................................................................34
Table 6.1 data schema view for attendance ..................................................................................62
Table 6.2 data schema view for event ..........................................................................................62
Table 6.3 data schema view for parent .........................................................................................63
Table 6.4 data schema view for score...........................................................................................63
Table 6.5 data schema view for section ........................................................................................65
Table 6.6 data schema view for student .......................................................................................65
Table 6.7 data schema view for subject .......................................................................................67
Table 6.8 data schema view for teacher........................................................................................67
Table 6.9 data schema view for unit-leader .................................................................................67
Table 6.10 data schema view for users ........................................................................................67
Table 6.11 access control ...............................................................................................................71

xi
List of Figure

Figure 4.1. uscase Moadal for student infotmation management system .....................................21

Figure 4.2 sequence diagram for add student attendance ..............................................................35

Figure 4.3 sequence diagram for enter assement score..................................................................36

Figure 4.4 sequence diagram for update score...............................................................................37

Figure 4.5 sequence diagram for assign unit leader ......................................................................38

Figure 4.6 sequence diagram for manage student and teacher ......................................................39

Figure 4.7 sequence diagram for Create Account ..........................................................................40

Figure 4.8 sequence diagram for record student and teacher.........................................................41

Figure 4.9 sequence diagram generate transcript ...........................................................................42

Figure 4.10 sequence diagram greate score report ........................................................................43

Figure 4.11 sequence diagram view student status .......................................................................44

Figure 4.12 sequence diagram view score .....................................................................................45

Figure 4.13 active diagrams for admin ..........................................................................................45

Figure 4.14 active diagrams for teachers ......................................................................................46

Figure 4.15 active diagrams for record office ................................................................................47

Figure 4.16 active diagrams for student .........................................................................................48

Figure 4.17 active diagrams for parent...........................................................................................49

Figure 4.18 state diagrams for login...............................................................................................50

Figure 4.19 state diagram assign unit leader ...................................................................................50

Figure 4.20 state diagram record attendance ................................................................................51

Figure 4.21 class diagrams .............................................................................................................52

Figure 4.22 deployment diagrams .................................................................................................53

xii
Figure 5.1 DFD .............................................................................................................................54

Figure 6.1 three tier architecture ...................................................................................................58

Figure 6.2 relationship mapping ....................................................................................................71

Figure 6.3 user login pages ...........................................................................................................72

Figure 6.4 user register page ..........................................................................................................72

Figure 6.5 admin dashboards ........................................................................................................73

Figure 6.6 assign unit leader ..........................................................................................................73

Figure 6.7 teacher info ...................................................................................................................74

Figure 6.8 teacher full info.............................................................................................................74

Figure 6.9user management ...........................................................................................................75

Figure 6.10 exam schedules ...........................................................................................................75

Figure 6.11 record attendance .......................................................................................................76

Figure 6.12 attendance report ........................................................................................................76

Figure 6.13 upload material ...........................................................................................................77

Figure 6.14 download material ......................................................................................................77

Figure 6.15 class activities ............................................................................................................78

Figure 6.16 submit student score ...................................................................................................78

Figure 6.17 view student score ......................................................................................................79

Figure 6.18 roster ...........................................................................................................................79

Figure 6.19 register student............................................................................................................80

Figure 6.20 student record information .........................................................................................80

Figure 6.21 student score report.....................................................................................................81

xiii
CHAPTER ONE

INTRODUCTION
1.1. Introduction
Management of students and class information is very important because it is the foundation of a
good education process. If this process is provided manually, there are big issues to handle a big
number of students, teachers, and classes. To update the class information or to make changes in
the schedule you should make a lot of work.

This proposal automates the school information management system. The system is Web-based
(thin client).

Moving on, this SIMS project in PHP focuses mainly on dealing with students and teachers
regarding their pieces of information, attendance, course, and other information. Also, the system
displays all the available data such as total students, teachers, attendance, etc. The project is
divided into five categories: Admin, Student, Teacher, Record office, and Parents Login. In an
overview of this web app, the admin has full control of the system, and he/she has full access to
the system. An admin can manage students, teachers, and parents' accounts.

All the reports, as well as the attendance sheet, can also be seen by the admin and users'
accounts. After entering for attendance of a particular teacher, the system displays his/her
records under the attendance section with a date. The admin of the system can create an update,
and delete, teachers' and student information. Besides, the system also provides a feature to
register parents' accounts of each and every student. Under all these records, the user has to
provide a photo of the identity of the students as well as teachers.

The web application takes most of the activities such as online student registering, transcript and
report card generation, attendance recording by the homeroom teachers and reporting for school,
parents interacting with the school, and producing the schedule.

1
1.2. Background
Abdi Boru primary and secondary School was built in 1999 and started teaching in September
2000 with 35 children in 17 of the 1st grade and a total of 52 students. When the school started, it
employed 9 teachers and 5 administrative staff for a total of 14 staff.

This school is currently teaching 690 students in 2014. In order for the teaching and learning
process to be carried out properly, the school has 17 kindergarten teachers and 20 regular
education teachers from 1st to 11th grade. It has completed the preparation to continue with 12th
grade in the next year 2015.

According to the vision set by the school, in 2023, the school has designed a plan to be one of the
equivalent schools in Adama city. In the same year, there is a plan to raise the level from 2nd
level to college.

1.3. Statement of the Problem

To help promote students' achievement and success, schools must have access to complete,
accurate, and timely information about students. One of the benefits of automated SIMS is that
the student record systems simplify the retrieval of the required information and is a great
instrument for school improvement by taking measures from the information acquired.

Some of the problems are the following: -

 It is time-consuming to record files

• Schools are using paper-based documentation systems 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.

• Scheduling classes and subjects which wastes manpower and much time
unnecessarily.

• Attendance of students is recorded by the home-room teachers manually


and can’t control absentees and know the number of days.

2
• Retrieving records of students' information difficult task and the manual
system

• Producing different reports which are required by the stakeholders such


as teachers, and administrators.

• Files get lost

• Wastage of material

• Data redundancy

1.4. Objective

1.4.1. General Objective

The study's main objective is to develop a web-based system for Student Information
Management System to provide a more efficient and productive.

1.4.2. Specific Objectives

To attain the general objective, the following list of specific objectives is see

 To real-time registration system,


 To record attendance of students,
 To manage section timely schedule,
 To generate student various reports,
 To recode student score
 To generate student result report card
 To manage student information
 Design the database for storing student information using MySQL.
 Implement a web application using PHP, CSS, and apache web server.

3
1.5. Methodology
1.5.1. Data Collection Method

Observation

An observation since it involves an analyst getting involved in some of the activities of the
interview will be carried out on the operation of the current system and formulate questions and
conclusions based on the observation. The observation carried out during operation hours.

Questionnaires

Questionnaires will also be used and the responses got from them were that very few employees
were computer literate and they were at ease with the new system since it was going to make
work easier for the very busy departments.

We chose questionnaires because we can get different ideas about the project from different
people at the same time. Generally, this method is used for saving time.

1.5.2. Software development methodology


Spiral
The researcher uses this method because it has good documentation standards and also
minimizes changes to the requirement as the project proceeds. It is also referred to as the spiral
model. A blend of the iterative and waterfall approaches, the challenge with the spiral model
knows when the right moment to move on to the next phase is.
The spiral methodology allows teams to adopt multiple SDLC models based on the risk patterns
of the given project. The business that isn't sure about their requirements or expects major edits
during their mid to high-risk project can benefit from the scalability of this methodology.
The advantage of the spiral lifecycle model is that it allows elements of the product to be added
in when they become available or known. This assures that there is no conflict with previous
requirements and design.
This method is consistent with approaches that have multiple software builds and releases which
allows making an orderly transition to maintenance activity. Another positive aspect of this
method is that the spiral model forces early user involvement in the system development effort.

4
On the other side, it takes very strict management to complete such products and there is a risk of
running the spiral in an indefinite loop. So, the discipline of change and the extent of taking
change requests is very important to develop and deploy the product successfully Figure spiral
methodologies.

1.6. System Development Tools


The system will be designed using the programming languages known as software
development tools preferred here as the development tools for the development of the new
system and are classified into Front - End development tools, Back - End development tools, and
Web Servers.

1.6.1. FRONT-END DEVELOPMENT TOOLS

The front-end manages everything that users virtually see first in their browser or application.
Front-end developers are responsible for the look and feel of a site, several front-end designing
tools are available such as HTML, CSS and JavaScript will be discussed here in detail as the
preferred ones.

HTML:- is an acronym for Hypertext Mark-up Language, which is the predominant mark-up
language for web pages. HTML is the basic building - block of a webpage. HTML elements
form the building blocks of all websites. HTML allows images and objects to be embedded and
can be used to create interactive forms. It provides a means to create structured documents by
denoting structural semantics for text such as headings, paragraphs, lists, links, quotes, and other
items. It can embed scripts in a language such as PHP which affects the behavior of HTML
Webpages (Somerset pub, 2008).
It is predominant mark-up language for web pages
 It supports more scripting language
 It is easy to understand
CSS: is an acronym for Cascading Style Sheets, a language that accompanies HTML, and
defines the style of a website’s content, such as layout, colors, fonts, etc.

5
Bootstrap: is a free, open source front-end development framework for the creation of websites
and web apps. Designed to enable responsive development of mobile-first websites, Bootstrap
provides a collection of syntax for template designs.

JavaScript: This is a programming language used for more interactive elements like drop-down
menus, modal windows, and contact forms.

jQuery; is a fast, small, and feature-rich JavaScript library. It makes things like HTML
document traversal and manipulation, event handling, animation, and Ajax much simpler with an
easy-to-use API that works across a multitude of browsers. With a combination of versatility and
extensibility, jQuery has changed the way that millions of people write JavaScript.

Font Awesome: is the world's most popular icon set and toolkit.

1.6.2. BACK-END DEVELOPMENT TOOLS

The back-end development refers to the server side of an application and everything that
communicates between the database and the browser. Although lots of database programming
languages exist such as PHP, MySQL, SQLite, MSSQL, and so forth, MYSQL is selected to be
used as a database development tool for the new system.

Hypertext Pre-processor (PHP): according to (Matt Doyle) PHP is a programming language


for building dynamic, interactive Web sites. As a general rule, PHP programs run on a Web
server and serve Web pages to visitors on request. One of the key features of PHP is that you can
embed PHP code within HTML Web pages, making it very easy for you to create dynamic
content quickly. The process of running a PHP script on a Web server looks like this:
 A visitor requests a Web page by clicking a link or typing the page's URL into the
browser's address bar. The visitor might also send data to the Web server at the same
time, either using a form embedded in a Web page, or via AJAX (Asynchronous
JavaScript and XML).
 The Web server recognizes that the requested URL is a PHP script, and instructs the
PHP engine to process and run the script.

6
 The script runs, and when it's finished it usually sends an HTML page to the Web
browser, which the visitor then sees on their screen.
PHP was developed so it could be inserted directly into HTML documents
MySQL: is a database constructed to enable PHP and Apache to work together to access and
display data in a readable format to a browser. It is a structured query language (SQL) server
designed for processing complex queries. As a relational database system, MySQL allows many
different tables from a particular database to be joined together for maximum speed and
efficiency.
• Handles large database. MySQL with some database that contains 50,000,000 records and
users MySQL with 60,000 tables and about 5,000,000,000 rows.

The Web Server: As the system will be web-based, research must be conducted into the various
available web servers. The web server will host the system and database and will be directly
connected to the projector and network, allowing clients to login and manage its content. Several
web servers exist such as Apache HTTP Server, Microsoft's Internet Information Services (IIS),
Lighted, Sun Java System Web Server, etc. But the main two web servers are Apache and
Microsoft's web server implementation IIS. The use of Apache had been suggested as it is a free
or open source software that can be installed on many different OS platforms such as Windows,
Unix, Mac OS, and more, and of course, offered superior security and is the most popular web
server.

7
1.7. Scope of the project
This system is designed to be fully user-friendly and efficient for a wide range of different tasks.
These tasks may include things like:

 Record student and teacher information


 Record students attendance
 Record student score

 Managing exams program,

 View data about certain students and teachers can edit it by adding or removing
a student

 The parent communicates with the SIMS to see the attendance, academic
planning, and track student behavior.

 Students can send homework, assignment, and project to the teacher

 Students can easily view inserted scores and attendance report

 Generate student result report card


 manage section timely schedule
 Class Rome management

1.8. Limitation of the project


SIMS has some limitations

 The system organization does not have any interaction with other organization
system.
 The system does not have any physical control mechanism.

 The system only supports the English langue

 This system has no phone application only web-based

8
1.9. Significance of the project
The Significance of any new technology is to make people's life easier. This project is a database
used to manage the student and allows the administrators to register the daily required
information of Students and Teachers.

 Recorded attendance and report generate


 Better Exam Management
 A parent can access the student's score and attendance status
 Students can download, upload, and complete assignments, notes, and projects.
 Automatic send notices when student absent for parent
 Easy student management
 User Fridley interface

Administrators and users' information are making effective decisions. The decisions are more
accurate, relevant and timely the information stored or processed is more effective.

1.10. Feasibility Study


A short assessment of the new system will be carried out to determine whether the new system
can effectively meet the specified requirements of the organization. The study will be carried out
to establish whether the direction and the requirement of the project are feasible. It analyses
whether it is worth committing the resources to the computerization of any area of the school
operations and whether it is worth doing operations with a computer system. The study was
aimed at;
Measuring how beneficial or partial the development of the new system of the new information
management system will be to the organization.
a) To outline the present problem and summarize it in terms of cost.
b) To allow the organization management of the school to decide whether or not to commit
resources to the project by showing whether or not a fully system study appears to be
justified.

9
1.10.1. Technical feasibility

The study was to measure the predictability of the technical solution and whether the
organization possesses the necessary technology to solve the problem as projected. It also
measured whether there is enough technical expertise in the organization to develop the
suggested solution. The possibility that the organization has or can procure the necessary
resources will also be checked. It is found out that the existing manual system would not be used
hence new hardware and relevant software is to be acquired. Manpower was lacking in the
organization which was also to be acquired.

1.10.2. Economic feasibility

This will be conducted to find how cost effective the system to be implemented will be. The
following questions are expected to be addressed under Economic feasibility study.

a) What benefits will the candidate system provide compared to the current system?
b) How much will the candidate system cost

The following will be considered when evaluating the candidate system.

a) System development cost


b) Hardware and software cost
c) Maintenance cost after installation
d) User time for testing and training

1.10.3. Operational Feasibility

The feasibility is carried out to measure how well the new system will work in the organization
and the willingness and desire of the users and how they feel about the system. I expect the
stakeholders to be interested in a system that is easy to operate, makes few or no errors, desired
information, and falls within the objectives of the organization.

10
CHAPTER TWO

LITERATURE REVIEW
Automated SMS plays a great role in simplifying the job of employees at the school and
satisfying the need of customers and stakeholders of the school. Even though no documentation
is found in Ethiopia to be reviewed, products have been observed at some schools to help
understand the problem of managing schools and handling school data. This chapter reviews
these products.

2.1. Observed Products


In the year 2003 City Government of Addis Ababa Education Bureau (CGAAEB) was very
much interested to have an automated school information management system to get uniform
and quick access to the students' data for administrative purposes on promoting the students'
achievement and related issues. The bureau has selected Wundrad Preparatory School for a pilot
test. At the time the school principals together with officials from CGAAEB signed a contractual
agreement with a software development company. The developers installed their first version of
the product which can register a student offline and generate an official transcript with some
level of difficulty. As the system is not fully automated, it does not support the management of
attendance, does not support generating report cards, and other important functions such as
generating school timetables and a web-based report for parents. Due to the lack of follow-up by
the government officials at CGAAEB, the company was unable to complete the project. The
school currently is unable to use the partially developed system because of a lack of trained
personnel and lack of hardware and software maintenance.

Another product that is in use is the transcript generator system. The transcript generator system
at Menelik II Preparatory School generates the official transcript of students. To generate a
student result report card, the recording officer enters the student information along with the
grade marks for the grades completed per year and per semester. Then the system generates the
required official transcript. Currently, the school is using the system to generate official
transcripts even though the data entry format has unnecessarily many fields which are not
applicable for the record office but can be used for continuous assessment by the course teacher.
All the record of students’ information, staff, subjects, and Mark list students’ roster is

11
maintained manually in paperback which is an overhead for the management staff. It is a very
time-consuming system that is not efficient for searching, updating, and maintaining
manuscripts. The main objective of the project is to make it easy for the school administrator to
retrieve and store all information related to students and staff, which is to reduce the
consumption of time maintaining the records of the school. Data collection methods by using
interviews and observation gather beneficial information for the developed system. There is no
software development methodology. System development tools back end design tool Microsoft
access software database system will be used in developing and managing the database at the
backend and for database access manipulation, and storage records. Front end design tool used
visual studio 6.0 is very com for the table to create a nice form interface for the end users.

Use for System module use case diagram. For Dynamic model sequence diagram, Activate
diagram, class diagram, state chart diagram, and component diagram. In the architecture of the
proposed System, the most popular client-server architecture is the two-tier and three-tier
architecture. Access Control and Security is password protection and simply proceeded to
prevent unauthorized access provided to the users. The system allows the user to enter the system
only through the proper user name and password also eliminating database injection by limiting
of characters on the user name and password as well as the number of times a user can enter
his/her password wrongly. The conclusion is proposed enlistment system will be a big
improvement over the existing manual system such that it provides the students with faster
service during the registration period. The system will be a substantial improvement over the
current system for students and staff. The recommendation of the system is to improve the
seating management facility then it well is more efficient in a real-time system, adding
certificates, add mark entry, and exam scheduling facility then it will be more efficient and
generation of results and rank list faculty then it will be more efficient.

12
CHAPTER THREE

EXISTING SYSTEM

3.1. Description of the Existing System

In school, records are being kept manually on papers for both the students and the teacher which
are highly unsecured and can be destroyed or altered easily. Furthermore, all the processes of
those records are also highly time-consuming. Likewise, the result computation and compilation
are very tedious and cumbersome task that is associated with a lot of human errors.

3.2. The Major function of the current system

All the records of the student, teacher, subject, exam, and the result are maintained manually in
books which are overhead for the management record office. It is very time-consuming so the
existing system is not so efficient for searching, Updating, and maintaining the record.
Registrations are one activity of the enrolment process which enables to list of the subjects with
the corresponding unit and schedule. Student registration is an enrolment tool offering an
extensive range of subjects and schedules.

The primary reason for the development of the registration process is to develop the enrolment
process.

 Admission office for the enlistment form. The student.


 Academic coordinator for the advice. The coordinator will then check the subjects and
units that the student listed in the enlistment form. The responsibility of encoding the
correct subjects and records of students is normally left to.

3.3. Drawback of the current system


The reviews described have the following problems:

• Generate an official transcript with some level of difficulty,

• Do not sufficiently produce the required reports to allow parents to view the status of
their children and reports for officials of school to help them participate in decision
making,

13
• Genrate timetable manuly

• Do not facilitate attendance record keeping by the homeroom teachers.

This project work tries to fill the gap by automating the various activities at schools. It tries to
satisfy user needs and simplify the works of administrators, record officers, and teachers. With
automated SIMS parents can easily interact with the school community to follow up on their
children's achievements and play their role in the school development processes.

3.4. Business rule of the current system

#Rule 1. The system shall authenticate before accessing the system.

#Rule 2. Add new student compliance without full document can’t register a system

#Rule 3. Can’t create a duplicate section

#Rule 4. Attendance recode only one time per day for one section

14
CHAPTER FOUR

PROPOSED SYSTEM
In this chapter the functional and non-functional requirements of the system are described and
modeled using UML models.

A UML diagram is a diagram based on the UML (Unified Modeling Language) with the purpose
of visually representing a system along with its main actors, roles, actions, artifacts or classes,
in order to better understand, alter, maintain, or document information about the system.

4.1. Functional requirement

Student information management system aims to improve the efficiency of student information
management, and the main function is managing and maintaining information. The administrator
and students are two major functional requirements in the system. The functional requirements of
the system are:

 The Administrator will be given more powers (enable/disable/update) than


other users.
 The system can be accessed any time and any where
 The system upload and download assignment, homework , classwork that is uploaded
by teacher
 User friendly interface and interactive
 the system can be record student and teacher information
 the system can be record student attendance
 the system can be record student score by teacher
 the system can be register subject by admin
 the system can be generate student report card record office
 The system can be manage Exam schedule
 The system can be easily manage student and teacher information
 Parent access to student reports and score

15
4.2. Non-functional requirement

In this system, the authentication of the user is an important factor. In this system, user
authentication will be done by login by user name and password and classified by user type.
Users will get access to the system as permissions are classified for that type of user.

The non-functional requirement

 improve the response time


 develop a user interface that is easy to use
 helps menu-based functions
 The system will have consistent interface formats and button sets for all
forms in the application,
4.2.1. PRIVACY
 The system shall protect the user’s privacy
 The system shall prevent students from viewing the grades of others
 The system shall provide a user-customizable visibility policy for the
personal information
4.2.2. USABILITY

The system should provide an easy-to-use graphical interface so users can easily learn how they
use the system. So, little knowledge of how Web pages can be accessed is required for the user to
use.

 The system is user-friendly so users can use it easily.


 The web interface is attractive and easily navigable Users to understand the menu and
options provided by the system
 If the users enter invalid inputs to the system, the system should warn the user about the
problem.
 To make the system to be easy for the users, there should be online help or instruction.
4.2.3. USER INTERFACE

The SIMS must have a simple user interface that makes it user-friendly and understandable.

16
4.2.4. WORKABILITY

Our system is suitable for a variety of customers or users such as reporters, officers, and the
society of the organization. It should be accurate in performing its functions and secured enough
from intruders and attacks by external users. Moreover, it must support interoperability with
other subsystems and components, and it should be complete i.e. it should be fully functional in
terms of providing all the functions expected to perform.

4.2.5. EFFICIENCY

This system will be efficient and the response time should be fast and minimally reduced since it
is capable of running on minimum hardware requirements and with the accustomed operating
systems.

4.2.6. ACCESSIBILITY

The system should be accessible. Since the system will be a Web-based application that can be
installed and work on any computer.

4.2.7. PORTABILITY

This system is portable in running on different platforms, adaptable with other systems,
installable on different machines architectures, and replaceable if the need arises.

4.2.8. CONCURRENCY

Our system supports multiple accesses of users such as teachers, students and administrators, and
so on. It should give service to multiple users concurrently.

4.2.9. MAINTAINABILITY

The system should be maintainable. Because the interaction between subsystems will be loosely
coupled and the interaction between classes and operations will be highly cohered, changes made
to our systems such as adding other subjects and functionality shouldn't affect the existing
functionality of the system.

17
4.2.10. ERROR HANDLING

Each error that may occur in the system will be handled accordingly to reduce the amount of
failure. When the error (for example invalid input) can be made by the users, the system should
answer these errors accord wrong input If the electricity goes on the main server then the system
should be out. For this we should use a Power supply to avoid this problem if the internet
connection goes on the main server, the problem must be solved fast.

4.2.11. DOCUMENTATION
 The user manual should be developed to let users use the system easily.
 After the project, every activity of the entire development, design, and another process will
be documented for future reference.
 There will also be a documentation of implementation for maintenance during web
application failure.
4.2.12. USER FRIENDLY
 the system is very interactive
4.2.13. SECURITY
 To prevent unauthorized access to the web site Administrative page, a role-based security
method that allows the authorized users to have their username and password should be
developed.
 Only the authorized users with the correct login and password should be allowed to
access and manipulate the data kept in the database.
 To send a request the user must have registered in the system. But, without registering,
the system does not allow to users for requesting.
 Let's say if login teacher and change the URL to admin URL admin page protect redirects
to the teacher
4.2.14. AVAILABILITY
 The system is available whenever the internet connection is available.
 The probability of the system being unavailable to the customer should be in times
when there is system maintenance and this task should be conducted.
Also, the systems work in multiple web browsers like (Chrome, Mozilla, Opera, and
Microsoft edge).

18
4.2.15. RELIABILITY

The system should be reliable; the system should perform all its services and function accurately
and on time.

4.2.16. CORRECTNESS
 This system should be operating correctly for the user to retrieve the desired outputs.
 To ensure this system quality, numerous testing and trial-and-error are carried out.

4.2.17. MODIFICATION

This system should be easily modifiable to meet change requirements, rectify a deficiency or
correct error, change the organization structure and adapt to the change in technology and
environment.

4.2.18. BACKUP

We will take a backup in our system database. To enable the administrator and the user to access
the data from our system.

 The system should provide a backup and restore mechanism for solving accidental
failure
 If the information in the database is changed, the system should be back up. Back up
will be saved in the backup server. The system administrator should be responsible for
backup, system installation, and system maintenance.

4.2.19. Hardware consideration

These are the physical component needed by the system to operate.


 Network Connectivity
 512 MB Ram or Higher
 20 GB HDD or Higher
 Browser supported device
 CPU

19
4.2.20. Software consideration

 Web browser
 Operating system
 Database server (xampp)
 PHP 7.3 and above

4.2.21. Performance consideration

The system should respond fast with high throughput, i.e. it should perform the task quickly
possible as possible such as generating reports and receiving, taking attendance, creating
sections, and also view school information in real-time action on the system

4.3. System model

To produce a model of the system which is correct, complete, and consistent we need to
construct an analysis model which focuses on structuring and formalizing the requirements of the
system. The analysis model contains three models: functional, object, and dynamic models. The
functional model can be described by using case diagrams. Class diagrams describe the object
model. A dynamic model can also be described in terms of sequence, state chart, and activity
diagrams. For this project, we have described the analysis model in terms of the functional model
and dynamic models using use case and sequence diagrams.

4.3.1. Use case model

Use cases of the system are identified to be “Create account”, “Assign unit leader”, “and Create
section”, “View and update record”, and “User management” by admin. Use case of teacher
“Enter assessment scores”, “Update student score”, “Upload Martial” and “Record student
Attendance”. Use case of student and parent “Download Martial”, “View Attendance”, “View
Exam schedule”, “View score”, and “View and update”. Use case of Recorder Office “Generate
score report card”, “Generate transcript”, and “Record student and teacher” The diagram
depicted in Figure 3.1 shows the use case diagram of the system.

20
uc Use Case Model

Student Information Managment System Use Case Diagrame


Class Assignment
Assign unit leader Download Matrial
Update student score

student

Genrate Exam
Schedule

«include»
Admin «include»
«include»
«include» View Score
Parent
Create User Account

«include»
«include»

Delete User «include»


Login

«include»

«include»
«include»

View and update record


«include»
Record Office
«include»
Record student
Generate Score Report «include» Attendance
«include»

«include»

«include»

Teacher

View Report

Record student and


teacher info
Personal profile Submit Student
Score

Upload Material
View Exam Schedule
Genrate transcript

Figure 4.1. uscase Moadal for student infotmation management system

21
4.3.2. Actor Description

Name: Record Officer

Description: A Record Officer is a person who registers a student, input, update student data and
produce a transcript and student result report card.

Name: Teacher

Description: A Teacher is a teacher assigned by the admin on the system to each class of students
to follow the students closely. He/she has the responsibility of recording the attendance of
students and score submission.

Name: Parent

Description: A Parent is a person who is registered as parent of the student and responsible to
follow the student in close contact with the school. He/she can view the status of the student such
as attendance and result/performance of the student online.

Name: Student

Description: A Student is a person recorded by the recording officer who views his attendance
report, and score, enters homework, and views section timely schedule

Name: Admin

Description: Admin is a person who is responsible to produce the schedule for each teacher,
assigning a unit leader for each section, and the classroom by providing the necessary
parameters.

22
4.3.3. Use case description

Name: Create User Account


Actors: Record office and admin
Description: Creating an account needs user type
Precondition: Must be user there

Flow of Event:
(1) Admin wants to create account
(2) Admin logs in
(3) when student or teacher register embed
create account by user type
(4) then display the user ID, give the id for the
user
(5) use case end

Alternative Flow of Events Alternative flow A: No user type


A5. The system can not create an account
A6. Use case end
Table 4.1 use case for create account

23
Name: Class Assign
Actors: Admin
Description: create a section for an assigned student in this
section
Precondition: There should be teachers and students for
creating section
Flow of Event:
(1) Admin wants to Class assign
(2) Admin logs in
(3) Admin Class assign for each section
assigned by letter or number filling a form and
then submitting it
(4) then display section with a letter
(5) use case end
Alternative Flow of Events
Alternative flow A: if not assign a letter
A4. The system can display only section
A5. Use case end
Alternative Flow of Events
Alternative flow A: if section exist
A4. Display section already existes
A5. Use case end
Table 4.2 use case description for class assigns

24
Name: Assign unit leader
Actors: Admin
Description: To assign unit leader for classe/section
Postcondition Registerd techer and ctreated section
Precondition: There should be subject teachers and classes
for which the unit leader is to be assign

Flow of Event: (1) Admin wants to assign unit leader


(2) Admin logs in
(3) select techer and section to assign leader
(4) then display section unit leader name and
subject mater
(5) use case end

Alternative Flow of Events


Alternative flow A: No section is created to
be assigned to unit leader
A3. The system can not assign unit leader
A4. Use case end

Table 4.3 use case description for assign unit leader

25
Name: Generate Score Report
Actors: Record Officer
Description: To produce a report card for students per
semester
Precondition: A student must have complete grade marks in
all subjects of the semester
Flow of Events:
(1) The record officer logs in and selects the
class/section to which the student belongs
(2) The record officer searches the student
from the class/section based on the search
criteria
defined
(3) The system processes the report card
(4) System displays and print the result
5) Use case ends

Alternative Flow of Events


Alternative flow A: The user logged in is not
the record officer
A1. User can not generate report card
A2. Use case ends

Alternative flow B:
The student is incomplete at least in one
subject
B3. The system can not generate the report
card.
B4. Use case ends

Table 4.4 use case description for generate score report

26
Name: Register Student
Actors: Record Officer
Description : To register someone as a student of the
school
Precondition: A student has to be eligible (has to be from
the pre-specified junior schools that the
school will accept)
Flow of Event:
(1) student wants to be registered as a student
of the school
(2) Record officer verifies that the student is
eligible
(3) Registration form will be given to the
student
(4) The student completes the registration
form that contains student’s full name,
address,
parent name, emergency person names and
addresses and other detail information.
(5) RecordOfficer of the school checks
whether the contents of the registration form
is
properly completed
(6) RecordOfficer fills and submits the form
to the system
(7) System registers
(8) Use case ends

Table 4.5 use case description for record student

27
Name: Generate student result report card
Actors: Record Officer
Description: To produce transcript based on the request of
a student
Precondition: A student must have completed at least a
semester to have grade report
Flow of Event:
(1) A student wants to get transcript
(2) The record officer logs in and searches
the students record from the database based
on the
search criteria
(3) The system processes the transcript
(4) System displays and print the result
(5) Use case ends

Alternative Flow of Events


Alternative flow A: The student is incomplete
at least in one subject
A3. The system can not Generate student
result report card
A4. Use case ends

Table 4.6 use case description for generate student result report card

28
Name: Record Attendance
Actors: Home Room Teacher
Description: To record attendance of students in each
school day
Precondition: A home room teacher must login as the home
room teacher of the class to record attendance
Flow of Event: (1) A home room teacher wants to record
absentees from the class
(2) The home room teacher fills in the
attendance slip in the class room
(3) Having the attendance slip the home room
teacher logs in to record
(4) HomeRoomTeacher records absentees and
submits
(5) System acknowledges
(6) Use case ends

Alternative Flow of Events Alternative flow A: User is not a home room


teacher of the class
A3. User can’t record attendance for the
required class of students
A4. Use case ends

Table 4.7 use case description for record attendance

29
Name: View Report
Actors: Parent
Description: To view the status of a student
Precondition: A parent must be recorded in the system as
parent of the student
Flow of Event:
(1) A parent wants to view status of his/her
student
(2) Parent logs in to the system supplying
user name and password
(3) System displays a form for search criteria
for a student
(4) Parent fills in the form and submit
(5) Parent selects to view the required report
(6) System displays the appropriate report
(7) Use case ends

Alternative Flow of Events Alternative flow A: Parent is not recorded as


parent of a student
A2. The parent can not login
A3. Use case ends

Alternative flow B: parent is unable to give appropriate name and


Id number of a student
B5. System can not display the student’s
information
B6. Use case ends

Users Record office, teacher & admin


Table 4.8 use case description for view report

30
4.4. Object Model

In UML models, objects are model elements that represent instances of a class or of classes. You
can add objects to your model to represent concrete and prototypical instances. A concrete
instance represents an actual person or thing in the real world.

4.4.1. Data dictionary

No Name Description Data type Size


1 P_id Parent identifier Varchar 255
2 Std_id Student for Varchar 255
3 status Account disable or not Varchar 50
4 User_name Parent access SIMS name Varchar 50
5 Email Email to reset password Varchar 50
6 Password Authentication to system Varchar 255
7 Date Registered date on sims date 50
Table 4.9 data dictionary for parent table

No Name Description Data type Size


1 sub_id Subject id int 11
2 Subject Varchar 50
3 Grade Subjecte for grade Varchar 50
Table 4.10 data dictionary for subject table

No Name Description Data type Size


1 sec_id Section id Varchar 50
2 section Section full name Varchar 50
3 status Section disabled or enabled int 1
Table 4.11 data dictionary for section table

31
No Name Description Data type Size
1 Std_id User’s unique identifier Varchar 255
2 P_id Parent unique identifier Varchar 50
3 Fname Student first name Varchar 255
4 Mname Student father name Varchar 255
5 Lanme Student grand-father name Varchar 255
6 Full_name Varchar 50
7 Sex Student gender Varchar 255
8 phone Student education level Varchar 255
9 Bdate Student date of birth Date time 255
10 bplace Student birth place Date time 255
11 Age Student age Varchar 255
12 Image Student image Varchar 1000
13 e_call Student emergency call Varchar 255
14 e_phone Student emergency phone number Varchar 255
15 Grade Student grade level Varchar 255
16 Mother name Student mother name Varchar 255
17 Region Student address Varchar 255
18 Zone Student address Varchar 255
19 Wereda Student address Varchar 255
20 kebele Student address Varchar 255
21 Nationality varchar 255
22 Date student registered date on system Date time 0000-00-00
Table 4.12 data dictionary for student table

32
No Name Description Data type Size
1 U_id User’s unique identifier Varchar 50
2 Fname Teacher first name Varchar 50
3 Mname Teacher father name Varchar 50
4 Lanme Teacher grand-father name Varchar 50
5 Full_name Teacher full name Varchar 50
6 Bdate Teacher date of birth Date time 50
7 bplace Teacher birth place Date time 50
8 e_lavel Teacher education level Varchar 50
9 Sex Teacher gender Varchar 50
10 Email Teacher email address Varchar 50
11 Unit_leader Assigned section Varchar 50
12 Gc_year Teacher graduate year Varchar 50
13 Gc_university Teacher graduate university Varchar 50
14 phone Teacher phone number Varchar 50
15 Region Teacher address Varchar 50
16 Zone Teacher address Varchar 50
17 Wereda Teacher address Varchar 50
18 kebele Teacher address Varchar 50
19 Nationality var 50
20 Doc Teacher tempo copy document file Varchar 50
21 Sub_mater Teacher field Varchar 50
22 Rig_date Teacher registered date on system Time date 50
23 Teach_id Teacher id Varchar 50
Table 4.13 data dictionary for teacher table

33
No Name Description Data type Size
1 std_id Varchar 50
2 Full name Varchar 50
3 status Varchar 50
4 Section Varchar 50
5 Sex Varchar 50
6 Age Varchar 50
7 Date Time date 50
Table 4.14 data dictionary for attendance table

No Name Description Data type Size


1 section Section Varchar 50
2 Unit_leader This section leader full name Varchar 50
3 Sub_mater Study field Varchar 50
Table 4.15 data dictionary for unite leader table

No Name Description Data type Size


1 u_id User’s Unique id Varchar 50
2 User_name Varchar 50
3 Email Email address Varchar 50
4 Password Password Varchar 50
5 Profile Varchar 50
6 U_type User type Varchar 50
7 status int 1
Table 4.16 data dictionary for user table

34
4.4.2. Sequence diagram

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. To
see the interaction between objects, the following describe the sequence diagram of each
identified use cases.

In Figure 4.2 below, once the user has activated the registration module by interacting with the
boundary object “Registration Button” button, the control object named “Registration Control”
manages the activities involved in “register Student” use case. First the “Registration Control”
creates registration form which will be filled by the secretary and submitted. The registration
control sends the record to a persistent storage.

Figure 4.2 sequence diagram for add student attendance

35
Figure 4.3 sequence diagram for enter assement score

36
sd Update Score

Login Controller Update Scores Updatet Scores Updatet Scores Database Server
Form Controller
Home Room Teache

Invalide()
Valide()

Create()

Requiest Select Student(want to


update)

Requiest Select Student()

Requiest Select sudent()

Get Select Student()

:Select Student

:Select Student

Fill Update Scre()

Requiest Update Score()

Update Student Score(Selected Student)

:Acknowledgment

Update Success()

Figure 4.4 sequence diagram for update score

37
sd create leader

Login Controller Assign Unit Leader Assign Unit Leader Assign Unit Leader Database Server
Form Controller
Admin

Invalde()

Valide()
Click Assign Unit Leader Button()

Fill Form (Assign Unit Leader)

Submit()

Requiest (Assign unit leader)

Check(if techer not assign)

:warning(Teache assign before)

Requiest(Assign unit leader)

Success()

:Success Message

:Acknowldgment

Figure 4.5 sequence diagram for assign unit leader

38
sd Manage Student and Teacher

Login Controller View Record Info Record info Form Score Report Database server
Button Controller
Record office

Invalide()

Valide()

view Student and Teacher()

Select Student or teacher()

Requiest Select Student or Teacher()

Requiest Select Student or Teacher()

Get Student or
Teacher()
:Student or Teacher info

:Student or Staff info

:Student or Teacher info

Figure 4.6 sequence diagram for manage student and teacher

39
sd Create Account

Login Controller Create Account Create Account Create Account Database Server
Button Form Controller
Admin

Invalide()

Valide()

Select Account Type()

Submit()

Requiest Create Account()

Requiest Create Account()

Requiest Create Account()

:Display User ID

Create Account()

Figure 4.7 sequence diagram for Create Account

40
sd recode Student and Teacher

Login Controller Record Student Record Student Record Student Database Server
Button Form Controller
Record Office

Requiest Login()

Invalide()

Invalide()

Click Record Student Button()

Fill(Student full information and document)

Submit()

Requiest Record Student()

Validate()

Create Success()
:Acknowledgment

Figure 4.8 sequence diagram for record student and teacher

41
sd Genrate transcript

Login Controller Genrate Transcript Genrate Transcript Genrate Transcript Database Server
Button Form Controller
Record Office

Requiest Login()

Invalide()

Valide()

Select Year Section Sem()

Submit()

Requiest Genrate Transcript()

Invalide()

Validte()

Get Transcript info()


:Transcript Info

:Genrate Transcript

Figure 4.9 sequence diagram: generate transcript

42
Figure 4.10 sequence diagram: greate score report

43
Figure 4.11 sequence diagram: view student status

sd v iew score

Login Controller Generate Score Score Report Form Score Report Database server
Report Button Controller
Student

Requiest Login()

Valide()

Create Form()

Requiest login student score()

Requiest login student score()

:Student Score

Figure 4.12 sequence diagram: view score

44
4.4.3. Activity diagram

Describe dynamic aspects of the system. It is basically a flow chart to represent the flow form
one activity to another activity. The activity can be described as an operation of the system. So
the control flow is drawn from one operation to another.

act Activ e

Start

Login Into SIMS

User Enter usernam or


userID with Password

Invalide

Check validte, user level and


Permession

Valide

Assign unit Section


leader Assignment
View Score
Invalide
View, update and Create user account
Delete user account
Invalide
Delete Reocrd

Check Unit Leader


Secton

Valide Valide

Logout

Stop

Figure 4.13 active diagrams for admin

45
act teacher

Login Into SIMS


Start

User Enter usernam or


userID with Password

Valide Invalide

Check Username and Password

Check User Level and Permission

Record student
Attendance Submit scores
Upload Matrial Update scores

Invalide

Attendance controller

Valide

Logout

Stop

Figure 4.14 active diagrams for teacher

46
act record off

Login Into SIMS


Start

User Enter usernam or


userID with Password

Invalide

Check validte, user level and


Permession

Valide

Record student and


Genrate transcript
teacher info

Create User
View and update
Account Invalide
record Invalide
Check
Check Form Score
Fill

Valide

Logout

Stop

Figure 4.15 active diagram for record office

47
act student

Login Into SIMS


Start

User Enter usernam or


userID with Password

Inval i de

Check validte, user level and


Permession

Val i de

View and update View Reposrt Download Matrial


View Score
Personal Profile

Logout

Stop

Figure 4.16 active diagrams for student

48
act Parent

Login Into SIMS

Start

User Enter usernam or


userID with Password

Inval i de

Check validte, user level and


Permession

Val i de

View Studebt
View Score View and update Report
Personal Profile

Logout

Stop

Figure 4.17 active diagrams for parent

49
4.4.4. State diagram

stm login

Start

Login

Enter user name


and password

[Inval i de]

Check

[Val i de]

Dashboard

Final

Figure 4.18 state diagrams for login

stm unit leader

Login
Start

Dashboard

Assign unit
Leader

fill form

[Inval i de]

Check

[Val i de]

Apply
Final

Figure 4.19 state diagrams for assign unit leader


50
stm record attend

Login
Start

Dashboard

Record Student
Attendance

[Inval i d]

Check

[Val i de]

Apply

Final

Figure 4.20 state diagram: record attendance

51
4.4.5. Class Diagram

To illustrate the relationships and source code dependencies among classes, class diagram was
developed. In this context, the 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 Class Model

Student
Section
Teacher - adress: int
- sec_id: int
- age: int
- section: int
- address: int - birth place: int
- status: int
- birth place: int - dateof birth: int
- subject: int
- date of birth: int - emergency call: int
- edu level: int + SectionDetail() - emergency phone: int
- email: int - fname: int
- fname: int - full_name: int
- gc unversity: int schedule - image: int
- image: int - day: varchar - lname: int
- lname: int Subj ect - mname: int
- section: varchar
- mname: int - nationality: int
- Subject: int - subject: varchar
- phone: int - tech_id: varchar - P_id: int
- subject: int + StoreSubject(): int - time slot: varchar - parent_name: int
- tech_id: int - registed date: int
- unit leader: int + Section schdule() - section: int
- sex: int
+ TeacherDetail() + std_id: varchar

+ StudentDetail(): int

Attedance Parent
Score
- by who: int # email: varchar
- by who: int
- date: int # full_name: varchar
- date: int
- section: int + p_id: varchar
- point: int
- status: int # password: varchar
- section: int
- std_id: int # std_id: varchar
- std_id: int
+ student attendance(): int - subject: int + ParentDetail()
- update by who: int
- update date: int

+ student score(): int

Figure 4.21 class diagram

52
4.4.6. Deployment Diagram

deployment Deployment Model

:Client machine :Web/application


T cp/Ip server
Web
SIMS
Browser

T cp/Ip

Databse Server

Database

Figure 4.22 deployment diagram

53
CHAPTER FIVE

SYSTEM DESIGN

5. System design
5.1. Data Flow Diagram (DFD)

The Data Flow Diagram (DFD) is a graphical representation of the "flow" of the student
information management system. The data flow diagram can also be used for the visualization
of Data Processing. DFD shows the interaction between the system and outside entities. This
context-level DFD is then "exploded" to show more detail of the system being modeled. A
DFD represents the flow of data Movement of data through the different transformations or
processes in the system is shown in the Data Flow Diagram.

dfd Data Flow Diagram

Administrator Teacher

Student Information
Managment System

Record Office Student

Parent

Figure 5.1 Data flow diagram

54
5.2. Purpose

• The Software is for the automation of Student Management.

• It maintains two levels of users:-

 Teacher Level
 Student Level
• The Software includes:-
 Maintaining Teacher & Student details.
 Providing Teacher General Information.
 Providing Student General Information & Student’s all
Exam Result.
5.3. 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

5.3.1. Performance

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.

55
5.3.2. Dependability

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.

5.3.3. 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.

5.3.4. End user

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.

The 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 or username and Password before a member
can enter the SIMS creates a 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
roster. So, the user has to wait for a little after telling the system to generate the roster and get the
result to get a quality roster.

56
CHAPTER SIX

IMPLEMENTATION

6. 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 5). 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 6.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.

57
Figure 6.1 three tier architecture

6.1. High level design

High-Level Design (HLD) provides a comprehensive overview of the software development


process along with the system architecture, applications, database management, and complete
flowchart of the system and navigation. It’s a blueprint that consolidates the various steps and
modules, their objectives, variable components, results, architecture, and timeline to develop the
software. HLD translates a business plan into a software product or service.

6.2. Process view

Process view of work is defined as the understanding that work can be viewed as a "process" that
has inputs, steps, and output(s) and that interfaces with other processes within an organization

58
6.3. Development view
6.3.1. Subsystem Decomposition
 Record student attendance
 student score
 student report card
 Class assign
 Personal profile
 Assign unit leader
 User management
6.3.2. Subsystem description

Attendance

 Record Student status


 Record date

Personal profile

 User Address
 User Authentication/Change Password
 User profile

Student score
 submit student score
 view score whit subject
 update score

Registration

 Record student and teacher


 Update student score
 Create account and delete

59
Student result report card

 View past score earned from each subject taken up to the last completed
semester.
 View and Print non-official records of score
6.4. Testing

Testing is the process of executing a program or system with the intent of finding errors”. Simply
testing involves the processes of verifying and validating the program or application. This is
performed at the start of the system by the test team. It’s called black box testing. The system is
tested in a controlled environment. The purpose of system testing is to validate an application’s
accuracy and completeness in performing the function as designed. The system is tested through
the following testing approaches.

6.4.1. Unit Testing


In this approach, each individual program modules of the system were tested separately.
 Testing the registration/login page to allow login
 Testing the record student and the teacher.
 Testing each component on the admin site.
 Testing each component on the teacher site.

6.4.2. Integration Testing


In this approach, the program modules of the system were integrated and tested as the whole.
 The back button which leads you to the previously opened page,
 Checking whether the all buttons on the admin panel are working and displaying
options.

6.5. Physical view (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 SIMS is a broad system that
performs many functions as described in chapter 3. It consists of web-based system used by
homeroom teachers to record attendance. The web-based system also assists parents and officials
60
to get or view status and report on students’ achievement and progress. The system assists the
record officer to generate student result report card. 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.

6.6. Persistent data management

Persistent data 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 student score, the section timely 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 SIMS data to do consistently. Moreover, storing
data in a database enables the system to perform complex queries on a large data set. The schools
register students every year in thousands per grade level. For complex queries over attributes and
large dataset Microsoft SQL Server is implemented, which is a Relational Database Management
System.

6.6.1. Data schema view

A database schema is the skeleton structure that represents the logical view of the entire
database. It defines how the data is organized and how the relations among them are associated.
It formulates all the constraints that are to be applied on the data.

61
Column Type Attributes Null Default Extra Links to Comment
s
std_id varchar(255) No
full_name varchar(50) No
status varchar(50) No
section varchar(50) No section.secti
on ON
UPDATE
CASCAD
E
ON
DELE
TE
CASC
ADE
date varchar(50) No

Table 6.1 data schema view for attendance

Column Type Attribut Null Default Extra Links to Comment


es
id int(11) No auto_inc
rement
event varchar(255) No
eve_for varchar(255) No
eve_date date No

Table 6.2 data schema view for event

62
Column Type Attribut Nu Default Extra Links Comme
es ll to nts
p_id varchar(255) No
std_id varchar(255) No
status varchar(50) Yes NULL
user_name varchar(50) Yes NULL
email varchar(50) Yes NULL
password varchar(255) No
date varchar(50) Yes NULL

Table 6.3 data schema view for parent

Column Type Attributes Null Defau Extra Link to


lt
id int(11) No auto_increm
ent
std_id varchar(255) No
name varchar(255) No
subject varchar(255) No ->
subject.subje
ct ON
UPDATE
CASCADE
ON
DELET
E
CASC
ADE

63
section varchar(255 No ->
) unitleader.sec
tion ON
UPDATE
NO_ACTIO
N
ON
DELETE
NO_ACTIO
N
by_who varchar(255) No
u_who varchar(255) Yes NULL
u_date varchar(255) Yes NULL
date datetime No
exam_20 varchar(255) Yes NULL
exam2_15 varchar(255) Yes NULL
home_20 varchar(255) Yes NULL
class_10 varchar(255) Yes NULL
project_10 varchar(255) Yes NULL
assign_10 varchar(255) No

Table 6.4 data schema view for score

64
Column Type Attributes Null Default Extra Links
to
sec_id varchar(50) No
section varchar(50) No
status tinyint(1) No
date timestamp No current_ on update c
tmestam urrent_ti
p() mestam p()

Table 6.5 data schema view for section

Column Type Attributes Null Default Extra


std_id varchar(255) No

P_id varchar(50) Yes NULL ->


parent
.p_id
ON
UPD
ATE
CAS
CAD
E
ON
DE
LE
TE
CA
SC
AD
E

65
fname varchar(255) Yes NULL

mname varchar(255) No

lname varchar(255) No

full_name varchar(50) Yes NULL


sex varchar(255) No

phone varchar(255) No

password varchar(255) Yes NULL

email varchar(255) Yes NULL

user_name varchar(255) Yes NULL

status varchar(255) Yes NULL

bdate varchar(255) No

bplace varchar(255) No

age varchar(255) No

image varchar(255) No

e_call varchar(255) No

e_phone varchar(255) No

grade varchar(255) Yes NULL

mother_nam varchar(255) No
e
regin varchar(255) No

zone varchar(255) No

kebele varchar(255) No

nationality varchar(255) No

Table 6.6 data schema view for student

66
Column Type Attributes Null Defau Extra Links
lt to
subject varchar(255) No
status int(1) No
grade varchar(50) Yes NULL
date timestamp No current on update c
_t urrent_ti mestam
imesta p()
m p()

Table 6.7 data schema view for subject

Column Type Attribut Null Defau Extra Links to


es lt
u_id varchar(50) No -> user.u_id
ON UPDATE
CASCADE
ON DELETE
CASCADE
fname No
mname varchar(50) No
lname varchar(50) No
full_name varchar(50) No
bdate varchar(50) No
bplace varchar(50) No
e_level varchar(50) No
email varchar(50) No
sex char(1) Yes NULL
unit_leader varchar(50) Yes NULL
gc_year int(50) No

67
gc_niversity varchar(50) No
phone int(50) No
img varchar(100 Yes NULL
0)
region varchar(50) No
keble varchar(50) No
zone varchar(50) No
nation varchar(50) No ETHI
OPI A
doc varchar(250 No
)
sub_mater varchar(50) No
regi_date varchar(50) No
tech_id varchar(50) No
update_date varchar(50) Yes NULL
update_by varchar(50) Yes NULL

Table 6.8 data schema view for teacher

68
Column Type Attributes Null Default Extra Links
to
section varchar(50)
section.sec
tion ON
UPDATE
CASCAD
E
ON
DEL
ETE
CAS
CAD
E
unit_leader varchar(50) No
sub_matter varchar(50) No
Table 6.9 data schema view for unit-leader

Column Type Attributes Null Default Extra Links to


u_id varchar(50) No
userName varchar(50) No
email varchar(50) No
password varchar(50) No
profile varchar(50) No
u_type varchar(50) No
status int(1) Yes NULL
last_seen varchar(50) No
Table 6.10 data schema view for users

69
6.6.2. Mapping

In order to store information persistently, we map objects into tables and the attributes into fields
to the specific table based on the objects found in the system. Therefore, we identified the
significant tables implemented on the selected DBMS.

6.6.3. Relationship mapping

This part is to describe and show the necessary relationships among the tables, which are
selected to store the data persistently in the system. Generally, there are three types of
relationships in a relational database system. These are one-to-one, one-to-many, and many-to-
many relationships. The system under consideration has one-to-many and many-to-many
relationships. Student and parent table one-to-one relationships. Section and unit Leader one-to-
one and section and attendance one-to-many relationship. score and subject one-to-one
relationship. Student and Subject tables have one-to-many relationships. One of the aims of a
database system is to reduce redundancy and for that purpose many-to-many relationship has to
be reduced to a one-to-one relationship. The Student and score and the Subject have a one-to-
many relationship by using the score table as the associate table. The relationship between the
remaining tables and the ones described here is descriptively shown in Fig. 6.2.

70
Figure 6.2 relationship mapping

6.7. Access Control and Security

Security is essential as all users have protectors so not all users can access another user's account.

User Access control functionality

Admin & Registrar office  Delete


 Search
 View
 Update
 Add
Teacher  Update
 Add
 View
Student & parent  Search
 View
Table 6.11 Access control

71
6.8. User interface model

When a user starts the application, a login screen is displayed as shown in Figure 6.3 to
authenticate the user. If the user has typed the correct user id and password to the login screen,
the system displays and then a window containing the main menus of the system as shown in
Figure 6.4. The main window displays menus and sub menus based on the role of the user that
has logged in.

Figure 6.3 users login page

Figure 6.4 users register page

72
Figure 6.5 Admin dashboard

Figure 6.6 assign unit leader

73
Figure 6.7 teacher Info

Figure 6.8 Teacher Full info

74
Figure 6.9 user management

Figure 6.10 exam schedule

75
Figure 6.11 record attendance

Figure 6.12 attendance report

76
Figure 6.13 upload martial

Figure 6.14 download martial

77
Figure 6.15 class activity tracks

Figure 6.16 submit student score by activity

78
Figure 6.17 view student score

Figure 6.18 roster

79
Figure 6.19 register student

Figure 6.20 student record information

80
Figure 6.21 student score report

81
CHAPTER SEVEN

CONCLUSION AND RECOMMENDATION

7.1. Conclusion

This paper assists in automating the existing manual system. This is paperless work. It can be
monitored and controlled remotely. It reduces the manpower required. It provides accurate
information always. Malpractice can be reduced. All years together gathered information can be
saved and accessed at any time. The stored data in the repository helps in making intelligent
decisions by the management. So it is better to have a Web-Based Information Management
system. All the stakeholders, faculty, and management can get the required information without
delay. This system is essential in schools and universities.

7.2. Recommendation

There is future scope for this facility with many more features like online lectures and video
lessons that can be added by teachers; student to take online tests, question bank for each subject
and school fee payment management, and group discussion is a feature. Students can discuss
various topics and issues. This project was created for Abdi Boru School but can be installed and
used by any school.

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 organization. Australian Journal of Educational Technology, 8(2), 132-160.

[3] T. Willis and B. Newsome. Beginning Visual Basic 2005, Wiley Publishing, Inc., 2006.

[4] M. Jensen, J. Schwenk, N. Gruschka, & L. LO. Iacono (2009). On technical security issues
in cloud computing. CLOUD 2009 - 2009 IEEE International Conference on Cloud Computing,
109–116.

[5] S. Subashini,V. Kavitha (2011). A survey on security issues in service delivery models of
cloud computing. Journal of Network and Computer Applications, 34(1), 1–11.

[6] M. B. M. Kamel, L. E. George (2016). Secure Model for SMS Exchange over GSM.
International Journal of Computer Network and Information Security, 8(1), pp. 1-8.

83
Annex 1

Some algorithms

1. Embed security
<?php
require_once "../config/config.php";

$userID = $_SESSION['userId'];
$stm = $conn_db->prepare("SELECT * FROM user WHERE u_id=:id");
$stm->bindValue(":id", $userID);
$stm->execute();
$user = $stm->fetch(PDO::FETCH_ASSOC);

if (!isset($_SESSION['userId']) == true) {
header("location:../");
} else {

$userType = $user['u_type'];
if ($userType != "admin") {
?>
<script>
location.href = "<?php echo "../$userType/" ?>"
</script>

<?php }
}

2. Login identifier

<?php
session_start();
require '../config/config.php';

$stm = $conn_db->prepare("SELECT * FROM user WHERE u_id=:id");


$stm->bindValue(':id', $_SESSION['userId']);
$stm->execute();
$usersInfo = $stm->fetch(PDO::FETCH_ASSOC);

84
Annex 2

Questioner

DATE:………………………………………………………………………………..…….. JOB TITLE: …………………………………..

Question 1:
How do you grade your current manual student’s enrollment system?
(PUT A MARK IN THE APROPRIATE BOX )
VERY GOOD
GOOD
AVERAGE
POOR
Question 2:
Do you think it should be computerized?
 YES(Give two reasons)
1.…………………………………………………………………………………………………………………………………………
…………………………………………
2…………………………………………………………………………………………………………………………………………
……………………………………………
 NO(Give two reasons)
1………………………………………………………………………………………………………………………………………………
……………………………
2………………………………………………………………………………………………………………………………………………
……………………………………………
Question 3.
Does the current system have any advantage over the proposed one?
 YES
 NO
If YES state them:
…………………………………………………………………………………………………………………………………………………
………………………..
……………………………………………………………………………………………

Question 4
What would you like included in the new system?
1……………………………………………………………………..
2…………………………………………………………………….
3……………………………………………………………………
Any other details regarding the new system
………………………………………………………………………………………………
Please fill the form with the right details and hand it in

85
Annex 3

User Interface Usability Testing Checklist

1. is the interface easy and understandable?

1. 2.

Yes No

2. Is the color has impact on interface?

1. 2.

Yes No

3. Is the interface encompasses all necessary content?

1. 2.

Yes No

4. Is there to much discrepancy in the system interface?

1. 2.

Yes No

5. Is there any content to be added further?

1. 2.

Yes No

6. Is there any unwanted content available on the interface?

1. 2.

Yes No

86

You might also like