5.

Final Report Layout of senior project

Preliminary pages
I. Title page (See its format)
II. Approval letter (the letter has to be prepared by the department on letter head and
signed by the supervisor)
III. Dedication (One page - optional)
IV. Acknowledgement
V. Table of contents
VI. List of figures
VII. List of Tables
VIII. Abbreviations
IX. Patents Information (optional)
X. Abstract

CHAPTER ONE

INTRODUCTION

CHAPTER TWO:

2 DESCRIPTION OF THE EXISTING SYSTEM

2.1. Introduction of Existing System

Wolaita Sodo High School Registrars have been using a manual Student Registration System
whereby different Student Registration activities were carried out manually. The school registers
new students, transferred from other schools, and regular students manually and keeps
information in the record room for further processing. The school provides education level from
secondary school level (grade 9 and grade 10) and preparatory school level (grade 11 and grade
12) to the students, grade level subdivided into many sections by assigning alphabetic letters A-
Z. When registering students also they assign teacher who supervise each grade level and
section. The role of supervisor is to record daily attendance, to manage roster or student data of
each subject.

2.2 Players in the existing system

Existing system has the following players:-
Director: Higher official, controls overall school activity including teachers attendance, evaluates
teachers study plan, verifies students documents before registration.
Teacher: teaches subject assigned by Director, and prepares their study plan for each subject.
Record Officer: They register every student and manage record room.
Students: provide valid and legal documents for record officer from their last attended school,
and provide document that verifies they are promoted to next grade level that is signed by school
director.

2.3 Functions / Activities of the existing system

In existing student registration systems different activities are done by the record officer and
students of the school.
Students provide their Primary School Leaving Certificate Examination (previous grade 8)
certificate to register to grade 9 or The Ethiopian General Secondary Education Certificate
(previous grade 10) to register to grade 11. The record officer obtains copy of student documents
and fills the form, sign and assigns students to each section, finally filled form signed by school
director and returned back to store in record office.

2.4 Business Rules

Business rule are principles, requirements and polices that must be fulfilled and obligated in
order the system will function properly and effectively. The business rules that must be
considered for this project are described below.
Sodo High school has its own business rule to register the student and to order the students how
it facilitates the service and the type of services which are functional used by whom. The rules
included are:-
 Student must provide original exam certificate
 Student must have his photograph and parent photograph
 Student must have invitation letter from their last attended school
  Record office must prepare enough registration form paper


2.5 Bottlenecks of the Existing System

The existing system has different obstacles that affect the performance, availability and
efficiency of service. Those are:

2.5.1. Performance (response time)

 The performance of the system based on response time is not having a good performance
because load of work.
 Time is wasted to find particular student record from the shelf.

2.5.2. Input and Output

 Significant amount of time is allocated for writing the students info in the form.
 Mistake of repeatedly editing of pen
 The written information of a student could be inaccurate, redundant and inflexible and
also these inputs may leads to inaccurate output.

2.5.3. Security and control

By comparing manual and computer systems, computer system is better than manual in the case
of security and non-tedious. In manual system as the work load is high the Sodo high School has
a probability to loss the documents that have been written in hard copy.

2.5.4. Efficiency
The existing system lacks much efficiency because it takes time to perform tasks;
 The data may be redundantly recorded and data entry procedure may be exposed to
errors. The system is not well organized to perform each activities and it is not flexible to
change or modify the data whenever needed.
 Mistake of skipping some spaces on the form

2. 7 Documents and forms in the existing system

 CHAPTER THREE

PROPOSED SYSTEM MODELING3.1 Description of Proposed System

The newly designed Automated Student Registration System was aimed at solving the problems
that were experienced as a result of using the manual Student Registration practices. This was
done through a number of strategies; Administrator has to register first the teachers with a valid
password and username, to proceed in applying and selecting choice of interests of the tasks that
take place at school, the teacher can register students, this thus, helped in curving a number of
loopholes that were in the old Student Registration practices.

3.2 Proposed System Requirement Specification

3.1.1 Functional RequirementsThe functional requirement for the system describes

the functionally or services that the system is expected to provide. It is a system
requirement that describes an activity or process that the system must perform. The
developed system is expected to provide the following functionalities:
 The system enables to search teacher name and edit it.
 The system enables to search student name and edit it.
 The system enables to create and remove accounts with username and passwords.
 The system enables to register students and delete student names.
 The system enables to register teachers and delete teacher’s names.
 System shall allow the director of school to login to access their information
 The system shall enable the administrator access all data accessed by the other users
of the system, add new users to the system.

3.1.2 Nonfunctional Requirements

A Non-Functional Requirement is usually some form of constraint or restriction that must be
considered when designing the solution. Such as:
User interface: The system interface that will be developed must be interactive and easily
understandable.
Response time: The response time of the system should be short.
Security: Updating, retrieving of information must be only for the manager of the hotel. To
make the proposed system more secured both username and password as well session is going to
be used in this system.
Performance: The system shall support multiple users at the same time.
i. The system should be available and accessible.
ii. The system should use less storage space.
iii. The system should employ security measures for example user authentication.

3.1.3 Actors and use case identification

3.1.4 Actor identificationThe actor of our system is:

Administrator: This is the headmaster who views all the data which other users view. He
registers school staff members, manages the system and adds user to the system and also deletes
them. This user can do anything with the system because he has all the rights
Teacher: This is the one who registers students in the school. This user has limited rights to the
system, since the headmaster can assign the duty of registering students to many people, they
cannot delete any record from the system because they can delete records that were entered by
other people.
School Director: This is also the headmaster who views all the data which other users view.
This user can do anything with the system because he has all the rights as the administration.

3.1.5 Use case identificationLogin

Add teachers
Manage teachers
Add students
Manage students
Add academic year
Manage academic year
Add level and section
Add school info
Logout

3.2 Use case diagram

3.2.1 Use case Description
Use case Uc_1
number
Use case name login
Actors Admin, Teachers
Description System lets above actors to login into the system

Pre-condition Actors must have valid username and password

Flow of event 1. open homepage.

2. The system display login form.
3. enter username and password
4. Click on login button.
Post condition The actors are successfully logged into the system

2
Use case number Uc _2
Use case name Add Teachers
Actors Admin
Description The admin use to add new teachers to the system
and assign sections to them
Pre-condition The teachers must have valid information
and the admin login to the system
Flow of event 1. Open homepage
2. click on teachers button
3. click on add teachers button
4. The system allows the admin to enter teachers
record.
5. Click on save button.
Post Condition The teacher is successfully registered to the system
3
Use case number Uc _3
Use case name Manage Teachers
Actors Admin
Description The admin use to modify/update or delete teachers
information
Pre-condition The information of the teachers should exist in the
data base of the system.
and the admin login to the system
Flow of event 1. Open homepage
2. click on teachers button
3. The system allows the admin to update teachers
record.
4. Update information.
5. Click on save button.
Post Condition The information of teachers is updated and the
system knows that teacher in new information

W
Use case number Uc _4
Use case name Add students
Actors Admin, Teachers
Description The actors use to add or enroll new students to the
system
Pre-condition The students must have valid information
and the actors login to the system
Flow of event 1. Open homepage
2. click on student list button
3. click on enroll new student button
4. The system allows the actors to enter student’s
record.
5. Click on save button.
Post Condition The student is successfully registered to the system

m
Use case number Uc_5
Use case name Manage students
Actors Admin, teachers
Description The actors use to modify/update or delete
student’s information.
Pre-condition The information of the students should exist
in the data base of the system.
and the actors login to the system
Flow of event 1. Open homepage
2. click on all students button
3. The system allows the actors to update
student’s record.
4. Update information.
5. Click on save button.
Post condition The information of students is updated and the
system knows that student in new information

Use case number Uc _6

Use case name Add academic year
Actors Admin, Teachers
Description The actors want to add new academic year to the
system
Pre-condition The actors must have login to the system
Flow of event 1. Open homepage
2. click on academic dropdown menu
3. click on year button
4. click on academic year button
5. The system allows the actors to enter record.
6. Click on save button.
Post Condition The academic year is successfully added to the
 system

Use case number Uc_7

Use case name Manage academic year
4Actor Admin, teacher
Description Actors wants to update or delete academic
year information
Pre-condition The actors login to the system
Flow of event 1. Open homepage
2. click on academic dropdown menu
3. click on year button
4. The system allows the actors to update or delete
record.
5. Click on save button.
Post condition The academic year is successfully updated or
deleted in the system
5

Use case number Uc_8

Use case name Add school Info
Actors Admin
Description Admin wants to add school information into
the system
Pre-condition Admin must be login to the system
Flow of event 1. Open homepage.
2.click on school info button
The system display new form of the school to
the admin.
3. Enter full information about school.
 4.Click on save button
post condition School information successfully added to the
system
G
Use case number Uc_9
Use case name Add level and section
Actors Admin, Teachers
Description Actors wants to add level and section into the
system
Pre-condition Actors must be login to the system
Flow of event 1. Open homepage.
2. click on academic dropdown menu
3. click on level button
4. The system allows the actors to enter record.
5. Click on save button.
post condition The level and section successfully added to
the system
L
Use case number Uc_10

Use case name Logout

Participating Actor Admin, pharmacist, customer

Description The actors should logout of the system when the complete their
tasks
Pre-condition Actors must have logged in to the system

Post condition The actors logged out of the system successfully

Event flow. Actors click on logout button

System closes
Use case ends
Alternative event none
flow

3.3 Dynamic Modeling

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

3.3 Sequence Diagram

A sequence diagram is a form of interaction diagram which shows objects as lifelines running
down the page, with their interactions over time represented as messages drawn as arrows from
the source lifeline to the target lifeline. Sequence diagrams are good at showing which objects
communicate with which other objects; and what messages trigger those communications.

3.4 Activity Diagram

3.5 Class DiagramThe class diagram describes the attributes and operations of a
class and also the constraints imposed on the system. The classes diagrams are
widely used in the modeling of object oriented systems because they are the only
UML diagrams which can be mapped directly with object oriented language.
CHAPTER FOUR:

4 SYSTEM DESIGN

4.1 IntroductionSystem design is the transformation of the analysis model into a

system design model. During system design, developers define the design goals of the
project and decompose the system into smaller subsystems that can be realized by
individual teams. The result of system design is a model that includes a clear
description of each of these strategies, subsystem decomposition, and a UML
deployment diagram representing the hardware/software mapping of the system.
System design is abstraction of solution; it is the general description of the
solution to a problem without details. Design is view pattern seen in analysis phase
to be pattern in a design phase. System design is done before the system
implemented and it is intermediate language between requirement and code. Design
is blueprint of solution system.

4.2 Design GoalThe objectives of design are to model the system with high
quality. The design goals are derived from non-functional requirements that means
non-functional requirement is the description of the feature characteristics and
attribute of the system as well as any constraints that may limit the boundary of the
proposed solution.
Design goals describe the qualities of the system that the developers should consider.
Those are:
Simplicity:-design the system easily understands for user or designs the system that is not
complex.
Reliability: The system should be reliable. That means it performs a required function under
stated condition.
Fault Tolerance: The system should be able to give response (error message) when the user
enter incorrect input. This recommends the user to enter correct input.
Portability: The system should work in different platforms, for there could be platform shifting
in the future and the work to have the acceptance of different institutes having the different
platforms. It is important to have this constraint attempted.
Security: The system does not allow non-authorized users using a form based authentication.
Flexibility: The system able to change to suit new condition or situation.
Efficiency: The system must do what it is supposed to do efficiently without the problem.

4.4 Proposed Software ArchitectureIt is the architecture that determines the type
of interactions that the components are going to have. The architecture that does
this work uses Client/Server architecture. In this type of architecture the server is
responsible to receive a request from the client and respond to the request, whereas

the client is responsible to interact with that of the users of the system.
4.7 Hardware /Software MappingHardware and software mapping is a process
that allows a processor to identify and track the location of each additional piece of
hardware or software, Such as when installing a new driver or installing a new
game or application. These allow the processor to identify where the new hardware
or software is located so when the computer needs to access those files or uses the
hardware, it knows where to go to in order for it to work as it is expected.
The Deployment diagram shows the physical layout of the system and where the various
components will reside. This Deployment diagram tells us much about the layout of the system.
It shows the relationship between among run time components and hardware nodes. This
diagram helps the project manager communicate what the system will be like to the users.
Deployment diagrams are used for describing the hardware components where software
components are deployed.

4.9 Persistence Data Management

4.14 User interface modeling

CHAPTER FIVE

IMPLEMENTATION AND TESTING

5.1 5.1 Introduction

From the implementation and testing part we use a WAMP server to store the system data and
work as a server for the system. And also Dream waver web builder and notepad++ for writing
the source code and designing phase.
In this chapter we mainly focuses on the implementation part, implementation concerned with
the type of material (Hardware and software required), techniques to develop the system,
algorithm for the system, code samples of the system, data preparation, some testing techniques,
startup strategy for the new installed system are briefly described in this part of documentation.
5.2 Final Testing of the system

Testing includes the error result when the user accesses unprivilaged data or
activites in the system. Such as when the unauthorized person try to access the user
account the system display error message.Sample PHP source codes
PHP Code for login

5.3 Hardware software acquisition

For the proper functioning of the system the following hardware and software are
required
 Hardware’s

 Computer

 Hard Disk

 Web application and database server

 Processor: GHz.
 RAM: GB.
 Hard disk: GB
 Software’s
 Notepad++

 Dreamweaver

 Browsers(one required ,client side):

 Internet Explorer JavaScript enabled

 Web application server(one required , server-side):
 Wamp Server
 Relational Database(one required, server-side)
 MYSQL Server
 Wamp server
  MSQL server

5.6 Installation Process

Firstly instal the software adobe dreamwaver or Notepad++ and wamp server, after that follow
the steps:
Step 1- put the developed system folder on C:\wamp\www on your computer.
Step 2- Active your installed wampserver software
Step 3- open the browser on your computer and write localhost (127.0.0.1) or
(localhost/foldername/index.php) on the place of URL or as a url.
Step 4- finally you can view and access the sysem.
NB: Before you are run the system you must have import the databse which is arrived on your
folder to the wamp server databse (on phpmyadmin).
Follow the folllowing steps to success you activity
Step one install the wamp server

5.7. Start-up strategy

Step1
 Activate Wamp server from the Desktop or Start up Menu if it’s not activated.
 Click on start ->Wamp server
THEN :
 check your folder which is available on the C:\wamp\www
 open any of the browser and write on the pace of url “localhost/foldername/filename.file
extention” then run it.
NB: REMEMBER THAT:
Before you are run the project on the wamp server you must have import the database on the
mysql server. To import the databse on the wampserver follow the steps here:
 Step1: activate the wamp server.
 Step2: write “localhost/phpmyadmin” on the browser.
 Step3: then click on “localhost” on the displayed page and click on the “Databases” then
go to “create database” and create the database by the name of your databse name then
click on “create” button. After that:
  Open the newly created database.
 Select import
 Then browse database by pushing the “choose file” button then say “Go” at the bottom of
the page.
 Finally it is successful importing of database.
Finally installation can be successful when you are follow the steps appropraitly.
Then you can run the project.

CHAPTER SEVEN

CONCLUSION AND RECOMMENDATION

7.1 Conclusion

7.2 Recommendation and future enhancement

References