CEP All Capter Final Projects

HARAMAYA UNIVERSITY
College of computing and informatics
Department of Information Systems
Project Report
HU Continuous and distance education program system A final

project report submitted in partial fulfillment of the requirements
for the degree of BSc
Group Members
HUNDESSA BONEYA (1482/07)
SAGNI DEGEFA (1486/07)
ZAHARA ASSEN (1650/07)
SHIMALLIS SHURAMO (1592/07)
SELAMAWIT GETAHUN (1584/07)
Advisor
Kadir Mohammed
June 19,2018
Haramaya, Ethiopian
By
Group Members:
HUNDESSA BONEYA (1482/07)
IWUNATU DEGEFA (1486/07)
ZAHARA ASSEN (1650/07)
SHIMALLIS SHURAMO (1592/07)
SELAMAWIT GETAHUN (1584/07)
Name of Advisor: ___________ Name of School Head: _____________
Signature of Advisor: _________ Signature of School Head: ___________
Examiner-1 Examiner-2
Name: ____________________ Name: ______________
Sign: _____________________ Sign: ________________

HU CONTINUOUS AND DISTANCE EDUCATION SYSTEM
Acknowledgment
First of all, we would like to praise almighty God who helps us to accomplish this
documentation successfully. Next, our deepest gratitude goes to our advisor Mr. Kadir
Mohammed for his excellent advice and active guidance throughout this project. We also
would like to thank the dean of continuity and distance education Mr. Solomon and some
workers of the colleges for their partial willingness of interview, patience in answering to our
numerous questions.
We will fail in our duty if we are not thanking Haramaya university department of information
systems for their acquiescence of laboratory class, free internet service that make us to
accomplish our project. Special thanks to the people who provided insightful comments and
questions that led to significant improvements in this document: Beyene Bedhasa, Tewodros
Tilahun, student from peer group, Gadisa Dagne, Nigatu Solomon, Bekele Wogari, Bekele
Gidisha and the staff of information systems department at Haramaya University
At the last but not the least, even if it is unusual, the group members would like to thank each
other. The main contributors to do this document project are teamwork, friendship and the
belief that we may achieve something we set out to do. We also hope that this project and the
documentation may be testaments to our continued friendship and better work. And it may also
be the essence of success and symbolic witness of what we are going to work.
I|P age
Abstract
Haramaya University College of continuing and distance education (CCDE) was established 33
years ago with continuing education program (CEP). It started with Certificate and Diploma
Programs in the fields of agriculture delivering education at Haramaya University and Harar
center. It is a web-based application which aim to change the manual system into a computerized.
The developed system will make the process of learning and teaching process more attractive by
reducing the problem currently faced by the existing system. To complete these projects, we used
analysis-based object-oriented method to put the different module that has included in the system.
The objective of this project is to overcome the problem existing system and develop new system
in steady the web-based system.
The very common problems in the continuous and distance education can be attributed using of
manual/file-based recording system. There is also no centralized database used to keep the student
records. Each students of continuous and distance education have the record and all this record
are kept in the shelf and searching to each record take much times. Due to this all discussed
problem above, we initiated to do this project.
Web-based continuous and distance education System is a management system website that
enables students who want to make online registration, online payment, add and drop course,
course and teacher registration, generate evaluation result of student grade, and grade report, it
also provides a centralized CDEP database to manage all this functionality.
The system is developed by using Bootstrap, PHP, and MySQL as a database system to manage
and store the data. The Waterfall Methodology, which is the traditional version and the classic
approach of a system development life cycle, is used to develop and build the web-based
Continuous and distance education program. To sum up, this paper shows the problem of the
existing system and the design of the new proposed system and show the solution to the problems
of the existing system.
II | P a g e
Contents
Acknowledgment ..................................................................................................................................... I
Abstract ................................................................................................................................................... II
CHAPTER ONE ......................................................................................................................................... 1
1. INTRODUCTION ............................................................................................................................... 1
1.1. BACKGROUND OF THE ORGANIZAITON .................................................................................. 1
1.2. Statement of the problem ........................................................................................................... 3
1.3 Objective of the project ................................................................................................................ 3
1.3.1 General objectives .................................................................................................................. 3
1.3.2 Specific objectives ................................................................................................................. 3
1.4 Methodology of the project .......................................................................................................... 4
1.4.1 System development methodology ........................................................................................ 4
1.4.2 Data Collection method ......................................................................................................... 5
1.4.3 Development Methodology .................................................................................................. 5
1.4.4 System Model ........................................................................................................................ 6
1.5 Software tools and Programming Language Used........................................................................ 6
1.6 Scope and limitation of the study ................................................................................................. 7
1.6.1 Scope of study ........................................................................................................................ 7
1.6.2 Limitation of Study ................................................................................................................ 7
1.7 Significance of the study ............................................................................................................... 8
1.8 Budget plan ................................................................................................................................... 8
1.9 Feasibility assessment ................................................................................................................... 9
1.9.1 Economic feasibility .............................................................................................................. 9
1.9.2 Technical feasibility ............................................................................................................. 10
1.9.3 Operational feasibility .......................................................................................................... 10
1.9.4 Schedule feasibility .............................................................................................................. 11
1.10 Management issues .............................................................................................................. 11
1.10.1 Team configuration ............................................................................................................ 11
1.11 Communication plan ................................................................................................................. 12
CHAPTER TWO ...................................................................................................................................... 13
SYSTEM REQUIREMENT SPECIFICATION AND ANALYSIS MODELING ................................................... 13
2. Introduction .................................................................................................................................. 13
2.1. Overview of the existing system ................................................................................................ 13
2.3 Overview of Proposed System .................................................................................................... 15
III | P a g e
2.4 Class Responsibility Collaboration (CRC)..................................................................................... 15

2.6. Use case modeling ..................................................................................................................... 19
2.6.1 Essential use case modeling ................................................................................................. 19
2.6.2 Essential use case description............................................................................................ 20
2.6.3 system use case modeling .................................................................................................... 22
2.7 User interface prototype ............................................................................................................ 29
2.7.1 Traditional User-Interface Prototyping ................................................................................ 29
2.7.2 User-Interface Flow Diagramming ...................................................................................... 31
1.8 Supplementary specification ...................................................................................................... 32
2.8.1 Business rule of the existing system .................................................................................... 32
2.8.2. Business Rules .................................................................................................................... 35
2.9 Functional Requirement ............................................................................................................. 37
2.10 Non-Functional Requirements .................................................................................................. 38
Workability.................................................................................................................................. 40
CHAPTER THREE .................................................................................................................................... 41
System Design Document ..................................................................................................................... 41
3. Introduction ...................................................................................................................................... 41
3.1 Layered class type architecture. ..................................................................................................... 41
3.2. Class diagram modeling ............................................................................................................. 42
3.3 Sequence diagram....................................................................................................................... 44
3.4 Activity Diagram .......................................................................................................................... 53
3.5 User interface design .................................................................................................................. 56
3.6 State chart diagram..................................................................................................................... 58
3.7 Object diagram............................................................................................................................ 60
3.8. Persistent Modeling/ Database Design...................................................................................... 61
3.8.1. Database Design.................................................................................................................. 62
3.9. Normalized Physical database model ........................................................................................ 66
3.10. Component modeling .............................................................................................................. 71
3.11. Deployment Diagram ............................................................................................................... 72
CHAPTER FOUR ..................................................................................................................................... 73
IMPLEMENTATION AND TESTING ......................................................................................................... 73
4. Introduction .................................................................................................................................. 73
4.1 Implementation plan .................................................................................................................. 73
4.2. Sample Code of the system ....................................................................................................... 74
4.2. Test case................................................................................................................................ 86
IV | P a g e
Testing procedures ........................................................................................................................... 86

4.2.1. Unit testing........................................................................................................................ 87
4.2.2. Integrated testing ........................................................................................................... 87
4.2.3. System Testing .............................................................................................................. 87
Here we compile the whole system stating from initial and proceed testing the whole system to
check out for the errors and flow control of the system. ................................................................. 87
4.3. Conclusion ................................................................................................................................. 87
4.4. Recommendation...................................................................................................................... 88
4.5. Clients Feedback ....................................................................................................................... 88
4.6. User manual preparation .......................................................................................................... 88
References............................................................................................................................................. 97
Appendix I ............................................................................................................................................. 98
V|P age
List of Tables
Table 1.1 Software Tools And Programming Language Used. ................................................. 7

Table 1.2 Project Budget Plan ................................................................................................... 8
Table 1.3 Time Schedule Feasibility (Gantt Chart) ................................................................. 11
Table 1.4 Team Configuration ................................................................................................. 11
Table 1.5 Communication Plan................................................................................................ 11
Table 2.1 Essential Use Case Description For Apply For Register ......................................... 12
Table 2.2 Essential Use Case Description For Submit Assignment ........................................ 20
Table 2.3 Essential Use Case Description For Prepare Grade Report ..................................... 21
Table 2.4 System Use Case Description For Login ................................................................. 24
Table 2.5 Use Case Description For Manage User Account .................................................. 25
Table 2.6 Use Case Description For Registration .................................................................... 26
Table 2.7 Use Case Description For Withdrawal Request ...................................................... 27
Table 2.8 Use Case Description For Generate ID Number ..................................................... 28
Table 2.9 Use Case Description For Grade Report.................................................................. 29
Table 2.10 Use Case Description For Submit Assignment...................................................... 30
Table 3.1 Persistent Database Design ...................................................................................... 67
Table 3.2 List Of First Normal Form ....................................................................................... 69
Table 3.3 List Of Secon Normal Form .................................................................................... 70
VI | P a g e
List of figures
figure 2.1 Crc Diagram For Actor Class .................................................................................. 16
Figure 2.2 Crc Diagram For Business Class ............................................................................ 17
Figure 2.3 Crc Diagram for Interface Class.............................................................................18
Figure 2.4 Essential Use Case Modeling ................................................................................. 19
Figure 2.5 System Use Case Design ........................................................................................ 23
Figure 2.6 User Interface Prototype for Registration Form.....................................31
Figure 2.7 User Interface Diagram For Application Form ...................................................... 31
Figure 2.8 User Interface For Upload Module........................................................................ 32
Figure 2.9 Proposed System Flowing Diagram ....................................................................... 33
Figure 3.1 Layered Class Type Architecture ........................................................................... 43
Figure 3.2 Class Diagram ........................................................................................................ 45
Figure 3.3 Sequence Diagram For Registration ....................................................................... 46
Figure 3.4 Sequence Diagram Of Withdrawal ......................................................................... 47
Figure 3.5 Sequence Diagram Of Manage Account ................................................................ 48
Figure 3.6 Sequence Diagram Of Generate Id ......................................................................... 49
Figure 3.7 Sequence Diagram For Grade Report..................................................................... 50
Figure 3.8 Sequence Diagram For Submit Assignment........................................................... 51
Figure 3.9 Communication Diagram Of Upload Module ........................................................ 52
Figure 3.10 Communication Diagram For Registration Student ............................................. 52
Figure 3.11 Communication Diagram For Generate Id ........................................................... 53
Figure 3.12 Communication Diagram For Request Withdrawal ............................................. 53
Figure 3.13 Communication Diagram For Payment................................................ 54
Figure 3.14 Activity Diagram For Registration Request ......................................................... 55

Figure 3.15 Activity Diagram For Upload Module And Assignment ..................................... 55
Figure 3.16 Activity Diagram For Generate Student Id, Username And Password….……...56
Figure 3.17 Activity Diagram For Request Withdrawal .......................................................... 56

Figure 3.18 Activity Diagram For Add Course ....................................................................... 57
Figure 3.19 Student Registration User Interface Design ......................................................... 57
Figure 3.20 User Interface for Login Design……….….…………………………......58
VII | P a g e
Figure 3.21 User Interface For Homepage .............................................................................. 59

Figure 3.22 State Chart Diagram For Apply............................................................................ 60
Figure 3.23 State Chart Diagram For Upload Module ............................................................ 60
Figure 3.24 State Chart Diagram For Download Module........................................................ 61
Figure 3.25 Object Diagram Of Cedp ...................................................................................... 62
Figure 3.26 Persistence Database Diagram ............................................................................. 70
Figure 3.27 Component Diagram For Cedp ............................................................................ 71
Figure 3.28 Deployment Diagram For The Cedp .................................................................... 72
VIII | P a g e
Lists of Abbreviations
CEP = Continuous and Distance Program
SRS = System Requirement Specification
CCDE = College of Continuous and Distance Education

RDAE = Rural Development and Agricultural Extension
NRM = Natural Resource Management
PHP = Preprocess Hypertext
MySQL = My Structured Query Language
Html = Hypertext Markup Language
RAD = Requirement Analysis and Design
CRC = Class Responsible Collaboration
UML = Unified Modeling Language
BR = Business Rule
SUC = System Use Case
UI = User Interface
EUS = Essential Use Case
OO = Object Oriented
Sd=Sequence diagram
IX | P a g e
CHAPTER ONE
1. INTRODUCTION
This System requirement specification document is prepared for Continuing education program
under the college of continuing and distance education of Haramaya University to develop
computerized information management of the CEP. As the time goes by and technology
evolves quickly, people manage to create an easier life in every aspect by manipulating the
rapid growth of technology. So, we need to totally change the existing manual system to
computerized system. The basic aim of this project is to solve the current problem of the
existing system because currently working system is not suitable.
They have maintained series of book of student data and record information, it is time
consuming and difficult task to maintain a system process data manually. Considering this
problem of the organization our development team has proposed to develop new system that
has great significance for work efficiency of the College. During the time of automating system
there are essentials requirement that are gathered from clients and end user of the project. The
SRS document describes the basic requirements in the project. The basic purpose of this SRS
is used to collect the entire necessary requirement and translate them to written document.
Through this process the end user is describing what is expected from the software or product
and the development team also understood what the real need of the customer, what is the
necessary knowledge available to develop the system.
1.1. BACKGROUND OF THE ORGANIZAITON
Haramaya University College of continuing and distance education (CCDE) was established 33
years ago with continuing education program (CEP). It started with Certificate and Diploma
Programs in the fields of agriculture delivering education at Haramaya University and Harar
center.
The distance education program was initiated in 1993 E.C to deliver education (to the level of
diploma) in several fields of education under the Faculty of Education. Distance education centers
were opened in Somali and Harar regions, and Dire Dawa city Administration. These centers
were: -Harar, Dire Dawa, Jigjiga, Godey, Kebridahar, Shinile Fike, Afdher, Degahabour, Warder
and, Liben.
1|P age
After eleven years, in 1999 E.C, degree programs were started to be offered distance under
graduate education program in different fields under the College of Agriculture and Faculty of
Business and Economics. Currently there are more than 6,000 students those have been attending
their education in different fields of studies at the following centers. [1]
Harar center
Accounting, Management, Economics, Agro-Economics, Law, and Horticulture, Rural
development and Agricultural Extension (RDAE), Natural Resource Management (NRM),
Software Engineering
Chiro center
Accounting, Management, Economics, and Agro-Economics, Rural development and
Agricultural Extension (RDAE), Natural Resource Management (NRM).
Adama center
Accounting, Management, and Economics, agro-Economics, Law, Horticulture, Rural
development and Agricultural Extension (RDAE), Natural Resource Management (NRM).
Asela center
Management, Economics, agro-Economics, Law, Rural development and Agricultural
Extension (RDAE).
Addis-Ababa-center
Accounting, Management, and Economics, agro-Economics, Law, Horticulture, Rural
development and Agricultural Extension (RDAE), Natural Resource Management (NRM)
Fiche center
Management, Economics, and Law.
Ambo center
Accounting, Management, Economics, agro-Economics, Law, Rural development &
Agricultural Extension (RDAE) and Natural Resource Management (NRM).
2|P age
Shashemene center
Accounting, Management, and Economics. Agro-Economics, Law, Horticulture
Rural development and Agricultural Extension (RDAE), Natural Resource Management (NRM)
Wolayita Sodo center

Accounting, Management and Economics.
1.2. Statement of the problem
Haramaya University college of continuing and distance Education currently have so many
problems because of the manual system, as we have analyzed the problem of the existing
system the current system has the following problems;
 It takes high cost to duplicate learning material and distribution

 Student registration, to take tutorial or give tutorial and viewing grade reports consume
time and cost. To performs all the above jobs colleges and students make payment for
transportation and spent their time to come and return back.
 Overburden work for the college during providing the service to the students like
distributing materials, assignment in a manual way.
 So, the information recording or filling and retrieval system is too tedious, error prone,
and also time taking.
 Students don’t have the opportunity to get up to date information on time I.e. since the
system is manual based the information that were distributed for students may be
modified, deleted, or changed. Example, the registration date, exam date and receiving
materials were make confusion.
1.3 Objective of the project
1.3.1 General objectives

The main objective of this project to automate the manual-based system and to develop
interactive web-based system in order to overcome the problems and to improve the
problem of the current system.
1.3.2 Specific objectives

 To minimize work complexity of the existing system
 To make data processing fast
3|P age
 To overcome the problem of manual applying and registration system

 To provide fast approval for appliers
 Automating information management system of the college
 To Reduce promotion cost and loss of data
 To provide and generate student grade report online
 To provide the course and accomplish the payment process for appliers online
 Enables fast data retrieval from the database
 To make the information's available to the department at their desk whenever required
in just a click way
 To have a centralized control over the records of the students and monitor the changes
on these records
 To allow all relevant information about an individual to be retrieved readily to meet the
end users need, to facilitate the individuals' rights of access to their own personal
information.
1.4 Methodology of the project
1.4.1 System development methodology

A system development methodology refers to the framework that is used to structure, plan, and
control the process of developing an information system. We select waterfall system
development method. Because, Waterfall model is simple to implement and also the amount
of resources required for it are minimal in this model and output is generated after each stage.
We have used object-oriented approach for the developing system because of the following
 Increase reusability: - the object oriented provides opportunities for reuse through the
concepts of inheritance, polymorphism, encapsulation and modularity.
 Increased extensibility: -when you to need to add new feature to the system you only
need to make changes in one part of the applicable class.
 Financial benefits: - reusability, extensibility and improved quality are all the financial
benefits, because they led to the business benefits of the object- oriented from the point
of view of the users, the real benefits are we can build, system faster and cheaper.
4|P age
1.4.2 Data Collection method

There are so many different data gathering technique which helps as to understand the old
systems general activities and its procedures. We used two methodologies to gather the
needed information. The methods we use for data collection are:
Interviewing: As a method for the collection of data about the activities of college of
continuing and distance education we use interviewing method to understand peoples who
belongs to the current system also we raised questions that helps us to develop the new
system. Review appendix I which contain sample interview question used and written at
the end of this papers
Document analysis: we analyze some documents and forms found in the office to get
information about the current system and Haramaya university website is our more
accessed source. The links of the form we analyzed : http://www.haramaya.edu.et/wp-
content/downloads/CEP/summer%20registration%20form.pdf and
http://www.haramaya.edu.et/wp-
content/downloads/CEP/Application%20form%20for%20MSC%20CEP%20-2007.pdf
1.4.3 Development Methodology

In the system analysis and design phase of a project we should use the object-oriented
approach that examines requirements from the perspective of the class and objects found in
the problem domain. The reasons that we use the object-oriented approach are:
 We can inherit properties of the class that are defined in the super class.
 We can reuse methods for avoiding redundancy.
 The data and functions are encapsulated in the objects that help us for
easily debugging purpose.
 It enables us to comprehensively model a system before we develop it.
 Modification of the object implementation is easy because objects are
loosely coupled.
 Understanding of the structure is easy because object-oriented modeling
represents real world entities.
 Direct manipulation of architectural components is possible because
several object-oriented programming languages exist.
5|P age
1.4.4 System Model

The model that is basically being followed is the WATER FALL MODEL, which states that
the phases are organized in a linear order. Investigation reports of all, the feasibility study is
done. Once that part is over the requirement analysis and project planning begins. If system
exists one and modification and addition of new module is needed, analysis of present system
can be used as basic model.
The design starts after the requirement analysis is complete and the coding begins after the
design is complete. Once the programming is completed, the testing is done. In this model the
sequence of activities performed in a software development project are: -
 Requirement Analysis
 Project Planning
 System design
 Detail design
 Coding
 Unit testing
 System integration & testing
Here the linear ordering of these activities is critical. End of the phase and the output of one
phase is the input of another phase. The output of each phase is to be consistent with the
overall requirement of the system. Some of the qualities of spiral model are also incorporated
like after the people concerned with the project review completion of each of the phase the
work done.
WATER FALL MODEL was being chosen because all requirements were known
beforehand and the objective of our software development is the computerization/automation
of an already existing manual working system.
1.5 Software tools and Programming Language Used.

No Software used Language/ Description
1 Back End MySQL For database and data storing
2 Client-side Java scripting  For it is popular in validation process
scripting  For it can be embedded easily with the
hypertext markup language
6|P age
3 Server-side PHP  Because it is compatible with wide

scripting/front end Varity of web server.
4 Static webpage Html  For it is highly flexible with CSS to
use different layout
5 Word processing MS-word, power  Used for the documentation and
point presentation
6 UML Visio 2016  For design and drawing some
Edraw max 8.92 important diagram
Axure Rp 8  For user interface design
7 MS Project 2016  For drawing Gantt chart for project
scheduling
Table 1.1 Software Tools and Programming Language Used.
1.6 Scope and limitation of the study
1.6.1 Scope of study

The scope of our project is limited to Haramaya University college of Continuing and Distance
education. The following sub systems are required to be automated.
 Giving assessment
 Generating grade report, official and original copy
 Registering student, staff and course
 collect assessment evaluation online
 upload learning material and tutorial
 Withdrawal
 Payment
 Adding, updating and searching student information.
 Accurate way of recording and storing student information into the database.
 Accurate way of accessing and retrieving student information from the database.
 Centralized user friendly and well-organized student records
1.6.2 Limitation of Study

 Cannot support multiple language except English
 Limited to the degree program
 Lack electric power.
7|P age
 Lack of Internet connection.

 It’s not suitable for disable person, like blind people.
 It needs computer skill to operate on the system.
1.7 Significance of the study
Now a day we are living in an information age, so everything is changed from the manual
system to automated system, which makes everything simple, interactive, time saving and
requires less storage space for allocating resources. The manual system has so many drawbacks
like as in above expressed. So, automating the system has significances like Easy for accessing
and managing student information detail, this automated system reduces the load of the
teachers and enables to access easily, Student registration, Course registration, Teacher
registration, generate grade report official and original copy, Registration Payment control, the
level of accuracy for the student information will be higher and seemly information and
modules.
The significance that expected from this system is that, it overcomes the problem stated in the
statement of the problem and listed on our scope of this project/system. The problem that every
activity of the CEP is carried out manually and, it must be automated in order to facilitate
information access and management. So, our system solves these problems of the college for
the colleges’ by automating CEPs activities which discussed in above statements.
1.8 Budget plan
To complete our project starting down from the beginning up to the end, the total costs we
have paid and we will pay are listed in the following table.
8|P age
Table 1.2 Project Budget Plan
1.9 Feasibility assessment
Feasibility study is the process of determination of whether or not a project is worth doing.
There are many types of feasibility study.
1.9.1 Economic feasibility

The system which we are going to develop will have economic benefit. Those economic
benefits may be tangible or intangible
Tangible Benefits
This is the concrete benefit that can be expressed in terms of birr. So, the system
proposed to develop will decrease a lot of birr that was expensive to buy and distribute hard
copy document material. Also reduce the loss of data that means if it reduces the loss of data it
also reduces the cost of replacing the lost data. For example, if the university has 5,000 students
to handle these amount data there must be many people to manage the data and a lot of paper.
But after the system developed the data can be managed with one person and in one computer
in very short time.
 Easy and fast file management.

 Reduce cost for manual data management (Reduced expenses)
 Easy update & retrieval on stored records
 Reduce costs of transportation
9|P age
Intangible Benefits
Intangible benefits are those benefits that cannot be expressed in terms of monetary value.
Intangible benefit that the system will give is the following:
 Give more readable, reliable, easily manageable, and database which

contains all student information.
 The proper and ordered information of employees which has stability
means which is not easily lost.
 Better decision making
 Better service to the office
 Little job burden to employees of office
 Fastest processing time and small amount of processing error.
 Small response time and many services
 Knowledge gain by project developer.
1.9.2 Technical feasibility

Technical feasibility determines whether the work for the project can be done with the existing
equipment, software technology and available users. Technical feasibility is concerned with
specifying equipment and software that will satisfy the user requirement.
This project is feasible on technical because the proposed system can run on any computer and
any browser with internet access so it would be technically feasible.
1.9.3 Operational feasibility

It is a measure of how well a proposed system solves the problems and takes advantage of the
opportunities identified during scope definition and how it satisfies the requirements identified
in the requirements analysis phase of system development. This system of web-based system
for distance and continuous education in Haramaya University will attain its desired objectives.
It can solve the problems in distributing module, assignment, registration time pass problem
and related. To ensure success, desired operational outcomes must be imparted during design
and development of our system. This includes such design-dependent parameters as reliability,
maintainability, usability, supportability, sustainability and affordability; therefore, it will
minimize the amount of effort to do all through manually.
10 | P a g e
1.9.4 Schedule feasibility

Schedule feasibility is a measure of how reasonable the project timeline is. It also shows the
time estimation in which a project will be completed; we used Gantt chart techniques to show
the time schedule.
Table 1.3 time Schedule Feasibility (Gantt Chart)
1.10 Management issues
1.10.1 Team configuration

In our project, we have five members and each of us have specified work. The following are
the types of tasks and as well as the responsibility each of us have been assigned for
Name Role(Responsibility)
1.Hundesa Boneya Boru  Team leader /project manager
 Implementation and testing
2.Selamawit Getahun  System requirement and Specification
 Database designer
3.Zahara Assen Mohammed  System Analyst and designer
4.Iwunatu Degefa Tura  Database designer
 System analyst and designer
11 | P a g e
5.Shimalis Shuramo Sorsa,  Implementation and Testing

Table 1.4 Team Configuration
1.11 Communication plan
While we are working on our project, we use the following techniques in order to meet one
another and then exchange our suggestions or ideas. Those techniques are listed in the
following table.
date Time Techniques

Member with Monday 9:00pm-12:00pm
members Wednesday 9:00pm-12:00pm Face to face and call
Friday 9:00pm-12:00pm phone
Member with Wednesday 8:30am-9:30am Face to face
Advisor Friday 2:30am-3:30am cell phone
Email
Table 1.5 Communication Plan
12 | P a g e
CHAPTER TWO
SYSTEM REQUIREMENT SPECIFICATION AND ANALYSIS

MODELING
2. Introduction
The purpose of system requirement and analyze model of the system is to layout the analyzed
document of system related. The Requirements analysis document (RAD) will provide a detailed
description of the requirements for the continuity and distance education program system (CDEP).
This RAD will allow for a complete understanding of what is to be expected from the newly
introduced system which is to be developed.
The clear understanding of the system and its functionality will allow for the vital website to be
developed for the end user and will be used for the development of the future stages of the project.
This RAD will provide the foundation for the project. From this RAD, the continuity and distance
education program system (CDEP) can be designed, constructed, and finally tested.
This Requirement analysis document (RAD) will be used by the system development team which
is developing Continuous and distance education program system (CDEP). The Project team will
use the RAD to fully understand the expectations of this Continuous and distance education program
system to develop the appropriate dynamic website. Haramaya university college of continuity and
distance education will be able to use this RAD as a “test” to check if the new system fulfills their
expectations or needs.
2.1. Overview of the existing system
Haramaya university CEP under the college of continuing and distance education (CCDE) was
established 33 years ago. it started with certificate and diploma programs in the fields of agriculture
delivering education at Haramaya university and Harar center. after few years, a new CEP center
was established at Dire Dawa and Somali regional state at Jigjiga. The department gives education
service for the students at these sectors. first the students apply to register by coming personally to
one of the specified sectors, then the department has its own criteria to approve the student’s
application.
13 | P a g e
The center employee/supervisor checks the registration form filled by the student weather it satisfies
the criteria or not. if the student satisfies these criteria’s he/she will be approved to be registered.
then after the approval, the student will pay the payment for the courses that he/she will take. then
the student will be registered and start the class by the schedule posted by the department. The
department handles this information manually. and the file management system is paper based. so,
the information recording or filling and retrieval system is too tedious, error prone, and also time
taking. As tried to be maintained here, the existing system activities is paper-based based or required
manually record. Because of this we have found the following problem in the existing system which
described below.
 There is a searching problem. Since there are so many files of students found in the
record room, searching for student file is time consuming for the record employee. So
that, quickly identifying student file is very difficult. This leads to elongation of the
overall working processes.
 there is control and security problem. due to little security control an authorized
worker is capable to access student information.
 The use of several forms and copies in the record keeping will incur additional material
cost.
 Very tedious and time-consuming advertisement and promotion about the department,
application date and registration date.
 Student's waste time and money by traveling back and forth for application and
registration process since application and registration time is different.
 It is tedious to manage historical data of students which needs much space to keep all
the information regarding the students.
 Since the files or records are stored on a cabinet (shelf) data are prone for damage and
loose.
 Tasks are vulnerable for mistakes because they are performed by human beings. As a
result, works done may not accurate.
 Due to the above problems time needed for work completion is very long.
Taking the above problems into consideration new system is proposed to solve student
information management problems including the registration process since the problem are
related to student information.
14 | P a g e
2.3 Overview of Proposed System
The proposed system mainly focuses on solving the problem of managing student information
and student registration, which been carried out manually, by developing a web-based
application for CCDE. This system enables the CCDE to manage the student information
management handled easily and also it makes the retrieval of those information super easy.
Even if the main aim of this project is to develop a computerized system that manage student
information and record, it also performs related work like applying for registration, registration
and different user account management in automated way.
The purpose of the software requirements specification document is to maintain all the
functions of the online continuing and distance education system. The College of Continuing
and Distance Education in Haramaya University runs various programs in continuing
(Extension), Distance and summer. These programs are handled in a manual system thus
creating a lot of problems for the office that made it function ineffectively.
To state some, the problems that are found in this system is, using manual based system to
teach students, to register students, to keeps student grade report, to generate grade report, to
process continuation evaluation of students, to distribute materials and posting paper on wall
from place to place, all these problems are the most common one that makes the users
unsatisfied and spent the organization resources.
Therefore, we try to develop web-based system for the office, for the purpose of solving the
problems and create opportunity in saving time, reducing human power, keeping the records
of students, instructors, announcing the registration date and register students online, students
get learning material online, generating grade report online and producing grade report with
official and original copy for the appliers.
2.4 Class Responsibility Collaboration (CRC)
Class Responsibility Collaboration (CRC) cards are a brainstorming tool used in the design of
object-oriented software. They are typically used when first determining which classes are
needed and how they will interact. A CRC model is a collection of standard index cards that
have been divided into three sections.
15 | P a g e
 Class –represents a collection of similar objects. An object is a person, place, thing,

event, or concept that is relevant to the system at hand. The name of the class appears
across the top of a CRC card and is typically a singular noun or singular noun phrase.
 responsibility – something that a class knows or does
 collaborator - another class that a class interacts with to fulfill its responsibilities
There are three types of classes
 Actor Classes – actors that appear in use case.

 Business Classes – places, things, concepts, and events that describe what the business
is all about
 UI Classes – screens, menus, homepages, and reports
Figure 2.1 Crc Diagram for Actor Class
16 | P a g e
Figure 2.2 CRC diagram for business class
17 | P a g e
18 | P a g e
Figure 2.3 Crc Diagram for User Interface Diagram
2.6. Use case modeling
2.6.1 Essential use case modeling

A use case diagram in the Unified Modeling Language (UML) is a type of behavioral diagram
defined by and created from a Use-case analysis. Its purpose is to present a graphical overview
of the functionality provided by a system in terms of actors, their goals (represented as use
cases), and any dependencies between those use cases. The actors of our projects that we used
to do our projects are manager, students, teachers (instructors), department, registration clerks
and different types of the use case related with our projects.
Apply to register
Assign Instractor
Payfee
approve grade
Get ID
Departemnt
Student
manage cource
Get Resource
distribute learning
materal
submit Assignment
See grade
Give Id
Give Resourse Generate GradeReport

Registarar
approve Register
approve withdrawal
prepare Exam/
Assigment
Generate Report
Instractor generate evaluation

Add Departement
Manage Department manager
Figure 2.4 Essential Use Case Modeling
19 | P a g e
2.6.2 Essential use case description
Use Case ID: EUC-01
Use Case Name: Apply to register
Actors: Applicant
Description: Applicant need to apply and he/she has accepted applicant form which
fulfills the requirement.
Trigger: When the student wants to apply for registration
Preconditions: The applicant should be new applicant and they must provide the required
information
Basic course of 1. The applicant wants to apply Haramaya University College of

action distance and continuance education.
2. The applicant goes to the nearby center
3. The applicant asks for apply to the Haramaya university.
4. The applicant provides the educational information needed with
photo
5. The registration clerk gives a form to the applicant
6. The applicant fills the form correctly
7. The registration clerk checks the form is properly filled
8. The registration clerk tells the applicant he/she applied successfully
9. The use case ends
Post conditions: The new applicant applies for registration and will be accepted.
Alternative course The applicant does not fulfill the admission Requirement
of action A
A7: The registration clerk determines the applicant don’t fill the
admission form properly.
A8: Return to step 5
A9: The use case end
20 | P a g e
Table 2.1 Essential Use Case Description for Apply for Registe r
Use Case ID: EUC-02
Use Case Name: Submit assignment
Actors: Student
Description: Student need to submit assignment for the instructor.
Preconditions: The student must be register of Haramaya University in CDCE for the
course.
Basic course of 1. The student wants to submit assignment.

action 2. The student fills assignment number, title, other personal
information and due date.
3. The student submits assignment by going physically or using
Posta.
4. The student sends the assignment or deliver it physically
5. The use case end
Post conditions: the student will submit the assignment.
Table 2.2 Essential Use Case Description for Submit Assignment
Use Case ID: EUC-03
Use Case Name: prepare grade report and transcript.
Actors: Registration clerk.
Description: preparing grade report and transcription for the students.
Preconditions: accept grade report from department.
Basic course of 1. The registrar wants to prepare grade report.

2. The department gives all student information and marks.
action
3. The registrar prepares grade report
4. The registrar submits to department
5. The department checks the students’ grade report.
Use case end
21 | P a g e
Post conditions: the registration clerk will prepare grade report.
Table 2.3 Essential Use Case Description for Prepare Grade Report
2.6.3 system use case modeling
Process Assasment
Post News and mail
<<extend>>
Edit grade prepare Grade Report

Posts/Mail
Registral Staff
Teach Course Confirm payment
<<include>> and withdrawal
<<include>>
Instructor
<<include>>
<<include>>
Adjust Schedule
Set Registration date
<<include>> <<include>>
<<include>>
Register request
Assign instractor
<<extend>>
LOGIN
Withdrawal request Manage instructor

<<include>>
Download material Check for Applicant
<<include>>
Department
Submit Assignment <<include>>
Manage course
Student
<<include>>
View Grade/ Register staff

Assignment <<include>>
Manage
Department
<<include>>
Pay fee
<<include>>
Manage account
<<include>>
Post News
&manage
feedback Admin
<<include>>
manage
Home Slide
Figure 2.5 System Use Case Design
2.6.4 SYSTEM USE CASE DIAGRAM DESCRIPTION

Use case name Login
Use case id Suc-01
Actors All Actors
Description BR#1, accordingly, this use case describes how a user logs into
the CEP System.
Trigger When the actor wishes to log into the CEP System.
Precondition Actors must have account.
22 | P a g e
Basic course of action 1. The actor clicks login menu bar

2. The system displays login form
3. The user enters user id and password
4. The system validates the entered information.
5. The system displays user page.
6. User logged in to his/her own page
7. use case end
Alternative course of action A A4. Entered User Id or password is Invalid
1. The system informed the user an error message
2. go to step 3
end use case
Post condition If the use case was successful, the actor is now logged into the
system. If not, the system state is unchanged.
Table 2.4 System Use Case Description for Login
Use case name Manage user account

Use case id Suc-02
Actors Admin
Description BR#12, accordingly, this system process, enable the system administrator to
manage all user account of the system. This is user account creation, activate and
deactivate
Precondition The student and staff leave the collage
Basic course of action 1. the system admin need to manage user account
2. system open general homepages
3. user select login button
4. system display login form to the user
5. the user (System admin) inter his/her username and password
6. the system verifies username and password are correct
7. system display admin panel page
8. The system admin selects “manage user account” option
9. User select create, deactivate, activate operations
23 | P a g e
10. User perform the operation

11. System prompt to verify the operation
12. User verify the operation
13. Success message sent to the user through different communication
means namely email
End use case

Alternative course of A.6the system verifies the username and password are incorrect/mismatch
action A 1. system rolled back to step 4
A.12 system verify the operation not correct
1. system replay error message
2. use case continue from step 9
end use case
Post condition User accounts managed by the administrator
Table 2.5 Use Case Description for Manage User Account
Use Case ID Registration

Use Case Name Suc-03
Actors Student
Description This system process helps to register approved and paid applicants, senior
students and readmission students with withdrawal case or dismissal with
readmission.
Trigger When the approved student wants to registration
Preconditions According to BR#5 The student should be approved, to get registered
Basic course of action 1. Student want to register
2. Student open system homepage
3. The student clicks login button
4. The system display login form to the student
5. The student enters username and password and click login button
6. The system verifies username and password is correct.
7. The system display student owned screen
24 | P a g e
8. The student selects “register here” option.

9. The system verifies weather the registration date is outdated or not
10. The System displays students register form.
11. The user enters full information and click "Register" button in the
same page.
12. The system validates user information is correct
13. The system notifies “you are registered successfully” message.
use case end
Post conditions The student will be registered
Alternative course of A6: the system verifies a username and password are incorrect
action 1. The system goes back to step 4
A9: the system verifies that the registration date is passed.
A:10 the system display “the registration date is passed” message.
1. Please go to withdrawal page and register to withdrawal, if any.
A12: the system validates the user information is not valid
1. The system rolled back to the step 11.
Use case end
Table 2.6 Use Case Description for Registration
Use Case Name Withdrawal request

Use Case Id Suc-04
Actors Student
Description According to BR#6 This system process, enable the student to request for
withdrawal in the time of different difficulties by mentioning the reason along with
the request.
Trigger When the student wants to withdraw.
Preconditions The student has provided the more convince reason to send request
Normal Flow 1. Student want to request withdrawal
2. The system controller open system homepage to the student
3. Student clicks login button to login
4. The system controller display login form to the user
25 | P a g e
5. Student enter username and password and clicks login method

6. System verifies the username and password is correct and open
student’s screen
7. Student select “withdrawal request” option
8. System display the form to be filled
9. User fill the form and click submit button
10. System checks all the fields are filled with the valid predefined
reason
11. System save the request
12. System replay success message
Use case end
Post conditions Student sends withdrawal request
Alternative Flows A4. If the form is not filled completely
1. System display error message
2. Use case return to step 3
Use case end
Table 2.7 Use Case Description for Withdrawal Request
Use Case ID: Suc-05

Use Case Name: Generate Id number
Actors: System administrator
Description: According to BR#9
This system process used to prepare student ID number.
Trigger: When the student wants his/her Id number.
Preconditions: The student must be get approved.
Normal Flow: 1. The Administrator of the system select “Manage account” option
2. The system admin selects add user option.
3. The system displays user registration form
4. The admin enters all user information’s or
5. The System admin select for instructor or student link
6. If step 4 clicks register user
26 | P a g e
7. If step 5 select approved student or registered Instructor

8. System display selected user
9. System admin clicks create button
10. System check inserted information
11. System display success message and prompt back to select new user
again
12. The system displays student ID number
13. The user clicks on print button
14. The system prints student ID number
15. The system admin attach that printed id to the user email
16. The user verifies his email address, get id, username and password
Use case end
Post conditions: Student gets his/her ID number
Alternative Flows: A3. If administrator enters wrong student ID number
1. System display error message
Use case end
Table 2.8 Use Case Description for Generate Id Number
Use Case ID Suc-06

Use Case Name Grade report
Actors Registrar staff
Description According to the BR#11 This system process, used for preparing student grade report from
the grade submitted by the lecture. Then the student can view its grade report by logged in
to his/her own account.
Trigger The student wants to get his/her grade report
Preconditions The lecture has to submit student semester grade report
Basic course of 1. System Registrar staff select “grade report” option
action 2. System prompt the system registrar staff to enter department, academic
year and semester
3. System Registrar staff fill the form and click on ok
27 | P a g e
4. System display list of students corresponding with their grade

5. System retrieve grade submitted by lectures and prepare grade report
6. System save grade report and student academic status
Use case end
Post conditions Student get his/her grade report
Alternative A5. If system Registrar staff enters incorrect id
Flows 1. System generate error message
Use case end
Table 2.9 Use Case Description for Grade Report
Use case Name submit assignment

Use case Id Suc-06
Actors Student
Use case description According to BR#13 The student should submit their assignment after
they did.
Pre-condition the student login into the system
Basic course of action 1. The student wants to submit assignments
2. The student enters into the system
3. The system displays home page
4. The student selects login link
5. The system displays login form
6. The student enters his correct username and password
7. The system verifies user name and password
8. The system displays student’s homepage screen
9. The student selects submit assignment link
10. The system displays assignment submission form.
11. The student fills the form correctly.
12. The system determines the student has filled correct information
13. The system displays success message
14. The use case end
28 | P a g e
Post-condition the student will submit the assignment.

Alternative course A6 The student enters incorrect username or password
A7. The system determines the student enters incorrect username
and password.
A8. The system displays failure message to the student
A9. The system returns to step 5.
A10. The use case ends
Alternative course B11 student did not fill the correct information
B12.The system determine the students didn’t fill correct
information
B13.The system display failed message to the student
B14. The use case returns to step 5
B15.the use case end
Table 2.10 Use Case Description for Submit Assignment
2.7 User interface prototype
2.7.1 Traditional User-Interface Prototyping

The traditional user interface prototype is an iterative analysis technique in which users are
actively involved in the mocking-up of the UI for a system. User interface prototype is a low
fidelity model or prototype of the user interface for system that represents the general ideas
behind the user interface in a technology-independent manner, but not the exact details. UI
prototypes have several purposes:
 As an analysis artifact that enables us to explore the problem space with our
stakeholders
 As a design artifact that enables us to explore the solution space of our system;
 As a vehicle for us to communicate the possible UI design(s) of our system
29 | P a g e
Figure 2.6 User Interface Prototype for Registration Form
Figure 2.7 User Interface Diagram for Application Form
30 | P a g e
Figure 2.8 User Interface for Upload Module
2.7.2 User-Interface Flow Diagramming

UI prototypes are an excellent means of exploring your user interface, but unfortunately it is
easy to quickly become bogged down in the details of the UI and not see the bigger picture.
User-interface flow diagrams—also called storyboards, interface flow diagrams, Windows
navigation diagrams, and context-navigation maps of the continuous and distance education
program of Haramaya university. The importance of this diagram is that to show the simple
flow of system function.
The boxes represent major user interface elements, modeled as you would instances/objects
and the arrows represent the possible flow between them, modeled as you would transition in
activity diagrams
31 | P a g e
Figure 2.9 Proposed System Flowing Diagram
1.8 Supplementary specification
2.8.1 Business rule of the existing system

This describes the working rules being followed by the CEP department in the existing
manual system.
Application and admission rules
32 | P a g e
Without any prejudice to directives given by the ministry of Education, eligible applicants to
the continuing program of HU fall into the following categories.
1. Preparatory Education completes

1.1 To join CEP, must applicants have ESLCE result of 2.0 and above either 10 ro12
grades.
1.2 Applicants who have successfully complete ten-plus-two (10+2) preparatory school
education can apply to the continuing education program.
1.3 Applicants must provide original documents and their required number of photo copies
which the office may require.
1.4 Applicants must pass both the university and grade 12 entrance examination set by the
ministry of education.
1.5 During application, applicants must bring two passport sized photographs.
1.6 Applicants may attach any accredited document he/she may think useful for his/her
competition.
1.7 Applicants must pay application fee which is not refundable incase the department the
student apply to may not opened due to justifiable reasons
2. Upgrading applicants
2.1. Applicants who have ESLCE result of 2.0 and above either 10 ro12 grades can apply.
2.2. Applicants with diploma (12+2 or 10+3) and cumulative grade point average (CGPA)
of 2.00 up on graduation from an accredited higher learning institution of similar
program are encouraged to apply.
2.3. Technical and vocational education and training graduates with pertinent qualifications
and who satisfy entrance qualification assessment set by the ministry of education can
be admitted.
2.4. Center of Competence (COC) is mandatory for all applicants having a diploma.
2.5. In case the department is willing to give entrance examination for the applicants, the
applicants must successfully pass the examination.
2.6. The applicants must provide the entire necessary document the institution may require
(ESLCE, Transcripts, Diploma or its equivalent and any other the student thinks is
relevant for competition).
2.7. Applicants is only at nearby centers, but not at the office of the CEP, unless application
for sponsorship.
33 | P a g e
2.8. Workers, who are engaging in the CEP program of the university, cannot apply to CEP,
until only they are working under the program.
2.9. Workers who are engaging under distance and summer education program can apply
to the education program.
2.10. All applicants must apply within the time period of the application days set by the
office of the CEP.
2.11. All applicants must complete the application form carefully. The office of CEP is not
responsible for incorrectly filled forms.
2.12. The application process is facilitated by the center coordinators until to the screening
process is accomplished and list of accepted applicants are posted.
2.13. Application is open for every one who can full fill the required criteria.
2.14. All applicants should sign an agreement to pay tuition and related fees to the
University.
3. Illegal Admission
3.1. Securing or intending to secure admission using forged academic documents and
examination results is illegal.
3.2. Securing admission by posing oneself as a student to the University system after
withdrawal, dropping out or dismissal is illegal.
3.3. The discovery of the above leads to the immediate and automatic dismissal from the
University and liable to other illegal actions.
4. Registration rules
4.1. Registration process should be accomplished with in the period set by the office of the
CEP or according to the calendar of the university.
4.2. Students should be registered in three normal registration days.
4.3. In the failure to complete registration within three normal days three late registrations
with penalty are allowed. The penalty increases from day one to three.
4.4. In the absence of registering within six days is never incorporated by the office the
CEP as well as by the center coordinators.
4.5. A student, who did not accomplish the registration within the six days mentioned
above, is only recommended to withdraw the program.
34 | P a g e
4.6. Before registration days, the center coordinators must be sure that the registration slips
provided by the office of the continuing education program contains all the necessary
information. Information such as the minimum and maximum credit hours to be
offered for the students, course code within the respective curriculum of the
departments, sameness of courses credit hours within the curriculum, course break
down on the basis of the advancement.
4.7. The center coordinators shall carefully register the students.
4.8. The center coordinators shall immediately submit the registration slip with the lists of
students identified by their respective departments to the secretary of CEP; after listing
down the students who registered for the semester; the secretary of CEP submits to the
database worker of the continuing education program.
4.9. The center coordinator should check the payment made by the students with the credit
ours the student registered for.
4.10. The database shall enter the registration slip into the database within five days.
4.11. The database worker shall submit the registration slip to the record officer of the CEP.
2.8.2. Business Rules

The system may not accept customer, Employee and administrator without customer name and
password
Identifier: BR220
Description: Admin, Instructor, Registrar staff Student & Department can access the
system when they enter valid user name and password. Unless access will be denied.
Name: login into the system
Identifier:BR#1:
Description: Admin, Instructor, Registrar staff Student & Department cannot do anything
without logging into website by using their customer name and password.
Name: get username and password
Idenifier:BR#2:
35 | P a g e
Description: Any Actor who need to access the system have get their user name and password
first after they apply to be registered and approved by the system admin.
Name: validation of interred information
Identifier:BR#3:
Description: after the system validate all necessary information then it will be accessed
Name: get access of learning material
Identifier:BR#4
Description: Any students who apply online have to pay for payment he/she required before
getting any learning material
Name: registration date
Identifier:BR#5
Description: Any student who need to registered have to be registered within the specified
registration date, otherwise he/ she have fill withdrawal form with sufficient reason too.
Name: request for withdrawal
Identifier:BR#6:
Description: In case some difficulty the student can request for withdrawal and to be approved
for him her by the required actors of the system.
Name: post course grade
Identifier: #BR7:
Description: Any instructor has to pass grade of each course within the specified time period.
Additionally, in case of some problem, if the grade of the student requires some update, the
instructor has post course value.
Name: Applicant necessary info
Identifier:BR#8
36 | P a g e
Description: any applicant who wishes to join Haramaya University should provide the
necessary educational information.
Name: Student should have unique Id
Identifier: BR#9
Description: Any student who is learning in the Haramaya university college of distance and
continuing education should have a unique ID generated to them by system admin to access
their privileged task.
Name: Modify course grade
Identifier: BR#10
Description: instructors are allowed to input and modify the marks of the students in the
course they instruct only
Name: Generating Grade Report

Identifier: BR#11
Description: Finally, the system will generate the grade report for students.
Name: Manage user account
Identifier: BR#12
Description: admin manage user account in CEP database.
Name: assignment submission date
Identifier:BR#13
Description: the student has to submit assignment to the instructors within the specified due
date.
2.9 Functional Requirement
Functional requirements define the fundamental actions that system must perform. Functional
requirement describes functionality or system services. The system named Continuous and
distance education program (CDEPS) provides the following functionality. Functional
requirements are supported by non-functional requirements also known as Quality
requirements.
37 | P a g e
Functional requirements are statements of services the system should provide, how the system
should react to particular inputs, and how the system should behave in particular situations. It
specifies the software functionality that the developers must build into the product to enable
users to accomplish their tasks.
 The system allows Administrator, student, instructor, registrar staff, department to
access the information they need by logging into their account by their username and
password.
 The system allows the student to apply for register.
 The system allows the student to view the assignment, download the module, upload
their assignment, edit their profile, pay fee, view their grade and comment back to the
instructor if needed.
 The system Allows the instructor to post notice, edit grade, upload material and
process any grade related issue
 The system allows the registrar staff to change grade report in case of change required
and generate grade report by single clicks
 The system enables the system administrator to create user account, distribute the
username and password to the needed users
 The system generates student identification number throughout generate function and
only allows the user to access their need and disables the action performed against ID
to change
 The system should enable authorized users to modify record like is deleting, editing,
inserting as well as retrieving required information from and to the database
 The system should display message when the administrator, Department, Student and
Teacher do operations successfully or not when they insert invalid
information
 The system should display full information of news for the public from the
database to the interface of the web page.
 The system should have well organized information storage and accessing
mechanism.
 The administrator can manage most activities that are done in this system.
 The administrator can activate or deactivate comments received from visitor
2.10 Non-Functional Requirements
38 | P a g e
Non-functional requirements, as the name suggests, are requirements that are not directly
concerned with the specific services delivered by the system to its users. They may relate to
emergent system properties such as reliability, response time, and store occupancy.
Alternatively, they may define constraints on the system implementation such as the
capabilities of I/O devices or the data representations used in interfaces with other systems.
Non-functional requirements, such as performance, security, or availability, usually specify or
constrain characteristics of the system as a whole.
Usability: The website should be user friendly and should require least effort to operate. The web
server used, should provide services like session management to maintain sessions in the application.
Reliability
The ability of the system to behave consistently in a user-acceptable manner when operating
within the environment for which the system was intended. As the system provides the right
tools for discussion, problem solving it must be made sure that the system is reliable in its
operations and for securing the sensitive details.
Security
Describe all of the technical requirements that affect security such as security audits,
cryptography, user data, system identification/authentication, resource utilization, etc. Assign
a unique ID number to each requirement. The main security concern is for users account hence
we use proper login mechanism should be used to avoid hacking. Security is provided from
unwanted use of recognition software.
User Interface
The system must be interactive and the delays involved must be less. So, in every action
response of the system, there are no immediate delays. In case of opening pages, of popping
error messages and saving the settings or sessions there is delay much below 2 seconds, in case
of opening databases, sorting data and evaluation there are no delays and the operation is
performed in less than 2 seconds.
Performance
Describe performance requirements and any related processes. Include a detailed description
of specific performance requirements and associate them to specific project
functionality/deliverables. Include information such as cycle time, speed per transaction, test
39 | P a g e
requirements, minimum bug counts, speed, reliability, utilization. The system should be
responsibly fast in order to access the required information and modules (assignment) easily.
Availability
Describe all of the technical requirements that affect availability such as hours of operation,
level of availability required, down-time impact, support availability, etc. Assign a unique ID
number to each requirement
Maintainability
The System modification can be achieving easily because the system is going to be designed
using an object-oriented approach. If there is change on the continuous and distance education
the system can be modified based on change criteria by the developers or any trained person
that knows the code behind the system.
Documentation
The System has well defined document which helps to easily maintain the system and we will
also prepare short and precise help file on how to use the system for the system users. It will
have a helping page to guide the user of the system and to show the process how they will have
to use.
Workability
The system should be Suitable for the all stakeholder of CEP. It should be accurate in
performing its functions and secured enough from attacks by external users. It should be fully
functional in terms of providing all the functions expected it to perform.
40 | P a g e
CHAPTER THREE
System Design Document
3. Introduction
After the analysis phase, the project proceeded to the detailed design phase, where the
requirements were translated into a representation of the system. This chapter of the project
document contains and describes about what the current software architecture looks like, and
also describes the proposed software architecture with its subsystem decomposition, software
and hardware mapping, persistent data management, access control and security, global
software control, boundary condition and finally describes the subsystem architectures.
The design phase is the interface between the requirement specification and the implementation
part, and one of the importance’s of this phase is to clarify specifications. This document is
basically intended for any individual user, system developer, project manager or documentation
writer that needs to understand the basic system architecture and its specification.
System design is the transformation of the analysis model into a system design model. The
purpose of this document is to provide an overview as to how to actually build the developed
system and to obtain the information needed to derive the actual implementation of our system
[2]. During the last phase we the team has extensively worked on the system analysis to
understand what were built. In many ways, this is a continuation of that work, only here we
draw the system closer towards implementation.
3.1 Layered class type architecture.
The layered architecture presents a high-level layering strategy for a software application. [3]
We originally used the term "class type" because we first started with this approach using
object-oriented (OO) technology. The layered system architecture diagram below shows the
proposed system architecture which is three tiers and must include client, server and database
to make the system fully function. As it will be going to descript in the deployment diagram to
the end of this papers.
41 | P a g e
General_Manu<<UI>>
Student page<<UI>>
Admin Page<<UI>>
Instructor Screen<<UI>>
Registrar page<<UI>>
Login form, Login Controller()

Registration, Registration Controller()
Withdrawal ,withdrawal controller()
Upload form, Upload Controller()
CEP System
Instructor
Student
Department
Admin
Course
Registration
Upload
Submit Assignment
Withdrawal
Payment
CEP
Database
Figure 3.1 Layered Class Type Architecture
3.2. Class diagram modeling
Class diagrams are the most common diagram found in modeling object- oriented systems. It
is diagram that shows the classes within our project so called continuous and education program system
problem domain (or a portion thereof) and the associations between them. A class diagram shows a
set of classes, interfaces, and collaborations and their relationships.
42 | P a g e
We used this diagram not only for visualizing, specifying, and documenting structural models
of our system CEP, but also for constructing executable systems through forward and reverse
engineering for it too. the purpose of this modeling is to model how the implementation part or
system of continuous and distance program is will be build.
We used the techniques to help us to flesh out the details of what needs to be built. Conceptual
domain modeling, also called conceptual modeling or domain modeling, is the task of
discovering the entity types that represent the things and concepts, and their relationships,
pertinent to our continuous and education problem space to model class diagram. Another way
we look at it is that conceptual models are used to depict the continuous and education program
detailed understanding of the problem space for our system
43 | P a g e
CDEP Class diagram
Manages
1..* 1
Student Person Department

+Fullname:varchar -Username:varchar
-Username:varchar +Age:int -Password:varchar 1
-Password:Varchar +Sex:varchar -status:varchar
Is a IS a
-Stud_Identification No +PhoneNumber:varchar -Approve_Regist_Request():Void
+Registration request():void +EmailAddress: -Assign_Instructor():void
+Nationality:varchar -manageCourse():void
-withdrawal Request():void
+Country:varchar -view student result():void
-Payfee():void 1..* +Occupation
-add/drop():void
+Login():void 1
-View Grade():void +Logout():void
1..* teaches manages
Is a Is a Is a
1 1..* Register 1
Instructor Administrator
Regitrar Staff to
payfee
-Username:varchar 1 -UserName:varchar
-Username:varchar -password:varchar
-password:varchar -password:varchar
-ManageAccount():void
-GenerateGradeReport():Void -Upload material():void -Register Staff():void
1..*
-changeGrade():void -Process Assessment():void -GenerateId():Void
Add
-ConfirmPayment():void -Collect Answer():void
Register
Confirms
Teaches 1
Payment Course Registration

-PaymentID:Varchar +CourseName:varchar 1..*
+Registration_Date:Date
-Amount:int +CourseCode:Varchar
-Date:Date 1..* +RegisterYear:Int
-Reason:Varchar +CredirHour:Int +Reg_Semester:varchar
-Payfee():void +PreRequisite +Register():Void
-ConfirmPayment():void +PostRequisite
+AddStudent():Void
for +Add_Instructor():void
+Add_Course():void
+DropCourse():Void
Figure 3.2 Class Diagram
3.3 Sequence diagram
UML sequence diagrams model the flow of logic within our system in a visual manner,
enabling us both to document and validate our logic, and are commonly used for both analysis
44 | P a g e
and design purposes [4]. In fact, they are often described as the bridging technique between
analysis artifacts such as system use cases and robustness diagrams and design-oriented
artifacts such as UML class diagrams [4]
It is a construct of a message sequence chart. A sequence diagram shows object

interactions arranged in time sequence. It depicts the objects and classes involved in the
scenario and the sequence of messages exchanged between the objects needed to carry out the
functionality of the scenario. Sequence diagrams typically are associated with use case
realizations in the Logical View of the system under development [5]. Sequence diagrams can
be used to explore the logic of a complex operation, function, or procedure. One way to think
of sequence diagrams, particularly highly detailed diagrams, is as visual object code [4]
Figure 3.3 Sequence Diagram for Registration
45 | P a g e
Figure 3.4 Sequence Diagram of manage account
46 | P a g e
Figure 3.5 Sequence Diagram of Manage Account
47 | P a g e
Figure 3.6 Sequence Diagram of Generate Id
48 | P a g e
Figure 3.7 Sequence Diagram for Grade Report
49 | P a g e
Figure 3.8 Sequence Diagram for Submit Assignment
3.3 Collaboration or communication diagram
Collaboration diagram is another form of interaction diagram needed to show the behavior of
several objects collaborating together to fulfill a common purpose of one purpose [4]. It
represents the structural organization of a system and the messages sent/received between
different objects. Structural organization consists of objects and links. The purpose of
collaboration diagram is similar to sequence diagram. But the specific purpose that influence
us to use this diagram is to visualize the organization of objects in the CEP (continuous
education program) system and their interaction in simply. The basic notation for modeling
messages on communication diagrams are used like rectangles represent the various objects
involved that make up the application. The lines between the classes represent the relationships
(associations, composition, dependencies, or inheritance) between them. We used some
50 | P a g e
relationship discussed above in sequence diagram here, but we did not used some concepts like
multiplicity because of one diagram only cannot completely putdown the layout of one
projects. For this, we used five communication diagrams with complete collaboration between
them to represent the relationship present in our project so called CEP.
Figure 3.9 Communication Diagram of Upload Module
Figure 3.10 Communication Diagram for Registration Student
51 | P a g e
Figure 3.11 Communication Diagram for Generate Id
Figure 3.12 Communication Diagram for Request Withdrawal
52 | P a g e
Figure 3.13 Communication Diagram for Payment
3.4 Activity Diagram
Activity diagrams is typically graphical representations used for business process modeling,
for modeling the logic captured by a single use case or usage scenario, or for modeling the
detailed logic of a business rule. In many ways UML activity diagrams are the object-oriented
equivalent of flowcharts and DFDs from structured development [6]. We used activity diagram
to represent graphical representation for apply for registration, registration, withdrawal, add
course, upload module or assignment, generate id, username, and password. To draws this
diagram, we also used the following named notation, initial node, activity final node, Activity,
Flow/edge and the like.
53 | P a g e
Figure 3.14 Activity Diagram for Registration Request
Figure 3.15 Activity Diagram for Upload Module and Assignment
54 | P a g e
Figure 3.16 Activity Diagram for Generate Student Id, Username and Password
Figure 3.17 Activity Diagram for Request Withdrawal
55 | P a g e
Figure 3.18 Activity Diagram for Add Course
3.5 User interface design
Figure 3.19 Student Registration User Interface Design
56 | P a g e
figure 3.20 User Interface for Login Design
57 | P a g e
Figure 3.21 User Interface for Homepage
3.6 State chart diagram
UML state machine diagrams depict the various states that an object may be in and the
transitions between those states. In fact, in other modeling languages, it is common for this
type of a diagram to be called a state-transition diagram or even simply a state diagram. A state
represents a stage in the behavior pattern of an object, and like UML activity diagrams it is
possible to have initial states and final states.
State chart diagram is used to model dynamic nature of a system. They define different states
of an object during its lifetime. And these states are changed by events. So, State chart diagrams
are useful to model reactive systems. Reactive systems can be defined as a system that responds
to external or internal events. States are defined as a condition in which an object exists and it
58 | P a g e
changes when some event is triggered. So, the most important purpose of State chart diagram
is to model life time of an object from creation to termination
Figure 3.22 State Chart Diagram for Apply
Figure 3.23 State Chart Diagram for Upload Module
59 | P a g e
Figure 3.24 State Chart Diagram for Download Module
3.7 Object diagram
Object diagrams model the instances of things contained in class diagrams. An object diagram
shows a set of objects and their relationships at a point in time. We use object diagrams to
model the static design view or static process view of continuous and distance education
system. This involves modeling a snapshot of this system at a moment in time and rendering a
set of objects, their state, and their relationships.
An object diagram covers a set of instances of the things found in a class diagram. An object
diagram, therefore, expresses the static part of an interaction, consisting of the objects that
collaborate in the continuous and distance education system, but without any of the messages
passed among them. [7]
60 | P a g e
CDEP Object diagram
Person Department
Student
Fullname "jamal Abdu Elias" Username="Beyman"
Username:Jamal Age:22 Password="hgf454d"
Password:jam12334 Sex='m' status="manager"
Stud_Id:IS1452/09 PhoneNumber="+0952154256"
EmailAddress="jams2@gmial.co"
Nationality="Ethiopian"
Country="Ethiopia"
Occupation="Student"
Instructor Administrator
Regitrar Staff
Username="Hunny12" UserName=""Solom"
Username="caalabr23" password="ghsolo12"
password="fdg3452cc" password="abcd98a"
Payment Course Registration
PaymentID="PA144" CourseName:Chemistry Registration_Date='12/4/

Amount=600 CourseCode:CM1245 2018'
Date= '21/6/2018' CredirHour:3 RegisterYear="2nd"
Reason:"For the purpose second PreRequisite="Cm1244
semester" Reg_Semester="1st"
Figure 3.25 Object Diagram of Cedp
3.8. Persistent Modeling/ Database Design
Persistent data management deals with how the persistent data such as file, database, etc. are
stored and managed and to outlive a single execution of the system. This Persistent data
management describes the persistent data stored by the system and the data management
infrastructure required for it. The proposed system will use MySQL database for storing data.
This will allow the database to be easily integrated and accessible by the rest of the system.
61 | P a g e
Information related to user information detail, course information detail, instructors detail and
some other related information are persistent data and hence stored on a database management
system to make the proposed system operate consistently. Data management issue raises the
questions, which data need to be persistent, where should persistent data be stored, and how
are they accessed. Persistent data represents a bottleneck in the system on many different fronts.
Most functionality in system is concerned with creating or manipulating persistent data. For
this reason, access to the data should be fast and reliable.
3.8.1. Database Design

Database design is the process of producing a detailed data model of a database. This logical
data model contains all the needed logical and physical design choices and physical storage
parameters needed to generate a design in a Data Definition Language, which can then be used
to create a database. A fully attributed data model contains detailed attributes for each entity.
The term database design can be used to describe many different parts of the design of an
overall database system. Principally, and most correctly, it can be thought of as the logical
design of the base data structures used to store the data. In the relational model these are
the tables and views. In an object database the entities and relationships map directly to object
classes and named relationships.
Our database normalization going to contain only the level two normal form which solves the
problem of atomicity and functional dependency among the attributes and key attribute and for
we don’t have the attributes that have transitive dependency to each other’s, we interrupt the
issue of normalization here on the second normal form [8]
Database Name: CEPIMS
Tables:
 Account
 Student
 Administrator
 Instructor Record
 Course Record
 User Course
 Withdrawal
62 | P a g e
 Grade Report
 Messages
 Payment
 Application
 Department
No Table name Attributes Data type Primary key Foreign key
1 Account User Id Varchar User Id

Password (20)
User type Varchar (20)
First Name Varchar (20)
Middle Name Varchar (20)
Last Name Varchar (20)
Sex Varchar (20)
Role Varchar (20)
Varchar (20)
Student Id Varchar
2. Student
Course Code (20)
Sex Varchar (20) Student_Id Course_Code
Age Varchar (20)
Phone Number Int
Email address Int
City Varchar (20)
Region Varchar (20)
Nationality Varchar (20)
Year
Varchar (20)
Semester
Varchar (20)
Department
Varchar (20)
Grade report
Varchar (20)
63 | P a g e
Id Double (10)
Type Varchar (20)
Varchar (20)
Instructor Id Varchar
3. Instructor
Password (20)
Sex Varchar (20) Instructor_Id Course_Code
Experience Varchar (20)
Department Varchar (30)
Phone Number Varchar (20)
Course Code Varchar (20)
Region Char (20)
Nationality Char (20)
Char (20)
Student Id Varchar
4. Withdrawal
Withdraw Id (20)
Reason Varchar (20)
Date Varchar (20) Withdraw_Id Student_Id
Upload File Varchar (100)
Timestamp
(20)
Varchar (100)
User_Id Varchar (20)
5. Message
Content Varchar (20)
E-mail Varchar (100)
User_Id
Date Varchar (30) Message_Id
Message_Id Varchar (30)
Varchar (20)
64 | P a g e
Course Code Varchar

6. Assign Course
Course Name (20)
Credit Hour Varchar (20) Instructor_Id
Instructor Id int (20) Course Code
Instructor Name Varchar
Year (20)
Varchar (20)
Semester
Varchar (20)
Varchar (20)
Varchar (20)
Student Id Varchar (20)
7 Grade Report
Course Title Varchar (20)
Course Code Varchar (20)
Student_Name Varchar (20)
Sex Varchar (20) Course_Code
UID
UID Varchar (20)
Grade Varchar (20)
GPT Varchar (20)
Pre_Total_Credit Varchar (20)
Current_Sem_Credit Int (6)
Current_Total_Point Double (10)
Current_Total_point Double (10)
Semester Varchar (20)
Year Varchar (20)
Academic status Varchar (20)
Issue data Timestamp
(6)
Department Department_ID Varchar (20) Department_ID Course_code
8
Department_Name Varchar (20) Instructor_Id
Email Varchar (20)
Course_Code Varchar (20)
Instructor_Id Varchar ()
Instructor_Name Varchar (20)
Phone number Varchar (10)
65 | P a g e
Administrator Admin_id Varchar (20) Admin_id

9
Frist name Varchar (20)
Middle name Varchar (20)
Last name Varchar (20)
Sex Varchar (20)
Table 3.1 Persistent Database Design
3.9. Normalized Physical database model
1st normalized form
Account
User Id Password type First Name Middle Name Last Name Sex Role
Administrator
Admin_id First Name Middle Name Last Name Sex
Student
Student_i First Middl Last Sex Yea Course Region Nationality Age City Phone
d Name e Nam r _code Number
Name e
Withdrawal
Student Id Withdrawal Year Semester F_Name M_Name L_name Reason Date

id
66 | P a g e
Message
User Id Message Id Email Content Time
Course
Course_code Course_Name Credit Instructor_Id Instructor_Name Year Semester

Hour
Instructor
Instructor_id First Middle Last Se Experience Course_code Phone Region Nation
Name Name Name x Number ality
Grade Report
Current_Total_credit
Current_Sem_Credit
Current_Total_Point
Pre_Total_Credit
Academic status
Course title
Student Id
Issue data
St_Name
C_Code
Semester
Grade
GPT
UID
Sex
Year
67 | P a g e
Department
Dept_Id Dept_Name Dept_Email Course_Code Course_Name Instructor_Id Instructor_Name
Table 3.2 List of First Normal Form
2nd Normalized Form
Student
Student_id First Middle Last Sex Year Region Nationality Age City Phone Number
Name Name Name
New introduced table
Student_id Course_code
Course
Course_code Course Title Credit Year Semester

Hour
Course_code Instructor_Id
Instructor
Instructor_id First Middle Last Sex Experience Phone Number Region Nationality
Name Name Name
Instructor_id Course_code
68 | P a g e
Course
Course_code Course Title Credit Year Semester

Hour
Course_code Instructor_id
Table 1.3 List of Second Normal Form
69 | P a g e
StudentCourse Student Instructor

1
C_Code PK Stud_ID PK Instr_ID
*
Stud_Id FirstName First_Name
MiddleName Midle_Name
LastName Last_Name
PhoneNumber Email_Address
EmailAddress PhoneNumber
Grade evaluation Sex 1 Sex
Country Country
Region Region
PK C_Code 1..* Age Age
D_Name Experience
C_Name C_Code C_Code
Stud_Fullname
Stud_Id
Instuctor_Name
Instructor_Id
AcademicYear
Semister 1..*
point
Grade Report Course

1
PK UID PK C_Code
UserAccount
Stud_Fulln ame * C_Name
Department C_creditHour
PK Username CourseName C_prerequsite
Coursecode Instr_ID
Password crhr
grade
Role gpt
Cgpa
Stud_Id Payment
1 sex
Pre_total_credit
Pre_total_point PK Pay_Id
Withdrawal Current_total_credit
Current_total_Point Stud_Fname
Acedamic status Stud_Mname
PK withdrawal Id Acadamic year Stud_Lname
Semister Stud_id
Stud_ID Issuedate Department
Stud_Fulln ame Amount
Stud_Department Reason
Academic Year 1 Date
Semister
Valid_Reason
Date
Department
InstructorCourse
PK Dept_ID
C_Code
1 Dept_Name
Dept_Phone
Dept_Email Instr_Id
Figure 3.26 Persistence Database Diagram
70 | P a g e
3.10. Component modeling
In the Unified Modeling Language, a component diagram show how Components are wired
together to form larger components and or software system they are used to illustrate the
structure of arbitrarily complex systems.
Figure 3.27 Component Diagram for Cedp
71 | P a g e
3.11. Deployment Diagram
Deployment diagram depicts a static view of the run-time configuration of processing nodes
and the components that run on those nodes. In other words, deployment diagrams show the
hardware for our system, the software installed on that hardware, and the middleware used to
connect the disparate machines to one another.
Figure 3.28 Deployment Diagram for The Cedp
72 | P a g e
CHAPTER FOUR
IMPLEMENTATION AND TESTING
4. Introduction
In the implementation phase all the programs are written, database is created, user
operational document is written, users are trained, and the system tested with operational
data. The implementation is carried out with the results that have been obtained from the
feasibility study and analysis. The system is implemented by finishing the project with the
help of appropriate tools that been suggested and are loaded in to the server. Then the system
is tested with appropriate data inputs to check the successfulness of the system. This being
carried out by inputting data that are of rare to be inputted. Then the administrator will be
trained of the operational functionalities to control and maintain system at a later stage. The
third-party user ‘s role is being carried out by the implementation team itself. There by it is
made sure that the system meets the required standards.
The system developers are in a position of converting all documents gathered and designed
into the code so that the system will be implemented for the user to be used for the purpose it
developed. Implementation refers to the Coding of the all documents gathered starting from
requirement analysis to Design phase. For the implementation of this system the user must have
a server on which the system will be hosted.
4.1 Implementation plan
The first phase in the implementation of a system is the plan to make it implement. For
proper implementation the plan is a pre-requisite and is known as pre-implementation
activity. It is in these steps that various activities which are required for implementing a
system are identified and their sequence and relation to each other is desired. In this step
various other estimates like time required for each activity and cost estimates are also
obtained. For the better description of the plan and implementation various tools like Gantt
charts and Pert chart have been used.
73 | P a g e
4.2. Sample Code of the system
Sample code for home page
<?php include('header.php');?>
<body>
<?php include('navhead.php'); ?>
<div class="container">
<div class="row-fluid">
<div class="span3">
<div class="hero-unit-3">
<div class="alert-index alert-success">
<i class="icon-calendar icon-large"></i>
<?php
$Today = date('y:m:d');
$new = date('l, F d, Y', strtotime($Today));
echo $new;
?>
</div>
</div>
<ul class="nav nav-pills nav-stacked">
<li class="nav-header">Links</li>
<li class="active"><a href="index.php"><i class="icon-home icon-

large"></i> Home
74 | P a g e
<div class="pull-right">
<i class="icon-double-angle-right icon-large"></i>
</div>
</a></li>
<li ><a href="latestupdate.php"><i class="icon-home icon-

large"></i> Latest Update
</div>
</a></li>
<li><a href="contact.php"><i class="icon-envelope-alt icon-

large"></i> Contact Us
</div>
</a>
</li>
<li class="nav-header">About US</li>
<li><a href="#mission" role="button" data-toggle="modal"><i

class="icon-book icon-large"></i> Mission
</div>
</a></li>
75 | P a g e
<li><a href="#vision" role="button" data-toggle="modal"><i class="icon-

book icon-large"></i> Vision
</div>
</a></li>
<li><a href="coursewe_offer.php">
<i class="icon-book icon-large"></i> Course We Offers
</div>
</a>
</li>
<li><a href="Apply.php">
<i class="icon-plus-sign icon-large"></i> Apply Here
</div>
</a>
</li>
</ul>
</div>
<br>
</div>
76 | P a g e
<div class="span9">
<section class="main">
<div class="custom-calendar-wrap">
<div id="custom-inner" class="custom-inner">
<div class="custom-header clearfix">
<nav>
<span id="custom-prev" class="custom-prev"></span>
<span id="custom-next" class="custom-next"></span>
</nav>
<h2 id="custom-month" class="custom-month"></h2>
<h3 id="custom-year" class="custom-year"></h3>
</div>
<div id="calendar" class="fc-calendar-container"></div>
</div>
</div>
</section>
<div class="alert alert-info">
<button type="button" class="close" data-dismiss="alert">×</button>
<strong>Head Up!</strong> Welcome to Haramaya University

Continuity & Distance Education.
</div>
<div class="slider-wrapper theme-default">
<?php include('slider.php'); ?>
</div>
77 | P a g e

</div>
</div>
</div>

<div class="container">
<div class="span12">
<div class="span9" style="font-family: serif; margin-left: 0px;">
</div></div>
<div class="span3">
<div class="alert alert-info">
<i class="icon-building icon-large"></i> Side Menu
</div>
<p><a href="index.php"><i class="icon-sign-

blank"></i> Home</a></p>
<p><a href="latestupdate.php"><i class="icon-sign-

blank"></i> Latest Updates</a></p>
<p><a href="Apply.php"><i class="icon-sign-blank"></i> Apply

Here</a></p>
78 | P a g e
<p><a href="contact.php"><i class="icon-sign-

blank"></i> Contact Us</a></p>
<p><a href="#"><i class="icon-sign-blank"></i> Mission</a></p> <p><a

href="#"><i class="icon-sign-blank"></i> Vission</a></p>
<p><a href="history.php"><i class="icon-sign-blank"></i> History</a></p>
<br>
<h4 style="color:#4d94ff;"><i class="fa fa-plus"></i> Registartion Date<br></h4>
<p>
<?php
$user_check_query = "SELECT `reg_date`, `pay_date` FROM `control_date`";
$result = mysql_query($user_check_query);
$rows=mysql_fetch_array($result);
$reg_date=$rows["reg_date"];
$pay_date=$rows["pay_date"];
echo'<p> ';
echo $reg_date;
?>
<h4 style="color:#4d94ff;"><i class="fa fa-plus"></i>
Payment Date<br></h4>
</p>
<?php
echo $pay_date;
echo'</p>';
?>
79 | P a g e
</div>
</div>
</div>
</div>
</div>
<br>
<div class="alert alert-success"><i class="icon-file icon-

large"></i> <strong>Background History</strong></div>
<?php include('footer.php'); ?>
</div>
</div>
</div>
</body>
</html>
Sample Code for Login
<?php
include('dbcon.php');
if (isset($_POST['login'])){
session_start();
$user_id = trim($_POST['user_id']);
$password = $_POST['password'];
$e_pass=trim(base64_encode($password));
$query = "SELECT * FROM account WHERE user_id='$user_id' AND

password='$e_pass' ";
80 | P a g e
$result = mysql_query($query)or die(mysql_error());
$num_row = mysql_num_rows($result);
$row=mysql_fetch_array($result);
$row_id=$row['user_id'];
$dep_id=$row['Dep_Id'];
$status=$row['status'];
$hunde = mysql_query("SELECT * FROM Assignment where status='New'");
while($keb=mysql_fetch_array($hunde)){
$date_co=trim($keb['dead_line']);
$c_co=trim($keb['code']);
$dat=date('Y-m-d');
echo $date_co;
echo $dat;
if($dat>$date_co){
mysql_query("Update Assignment set status='Pass' where dead_line='$date_co'"); }
$hund = mysql_query("SELECT * FROM Schedule where status='New'");
while($kebe=mysql_fetch_array($hund)){
$date_come=$kebe['date'];
$date=date('Y-m-d');
if($date>$date_come){
mysql_query("Update Schedule set status='Pass' where date='$date_come'");
}}
81 | P a g e
$hu = mysql_query("SELECT * FROM Withdrawal where status='Accept'");
while($kebo=mysql_fetch_array($hu)){
$year=$kebo['year'];
$da=date('Y');
$stud_id=$kebo['stud_id'];
if($da>$year){
mysql_query("Update Account set status='Active' where user_id='$stud_id'");
mysql_query("Update Student set status='Active' where stud_id='$stud_id'");
$user_type =$row["user_type"];
if( $num_row > 0 ){
if($user_type=="Registrar"){
header('location:Registrar/index.php');
$_SESSION['id']=$row_id;
$_SESSION['Dp_Id']=$dep_id;
else if($user_type=="Adminstrator"){
header('location:admin/index.php');
82 | P a g e
else if($user_type=="Dep_Head"){
header('location:Dep_Head/index.php');
else if($user_type=="Instructor"){
header('location:Instructor/index.php');
else if($user_type=="Student"){
if($status=="Active"){
header('location:Student/index.php');
else if($status=="Withdraw"){
echo"<script>alert('Your account has been temporally Deactivated, because you have

withdrew for this semester')</script>";
echo "<script>windows: location='index.php'</script>";
else{
echo"<script>alert('Your account has been temporally Deactivated')</script>";
echo "<script>windows: location='index.php'</script>";
83 | P a g e
}}
else{
header('location:access_denied.php');
}}
else{
header('location:access_denied.php');
}} ?>
Sample code for forget password
<?php
if(isset($_POST['submit'])){
include('dbcon.php');
if (isset($_POST['submit'])){
$e_mail = $_POST['email'];
$subject="password are recovered from Cep database";
$query = "SELECT * FROM Account WHERE e_mail='$e_mail' ";
$result = mysql_query($query)or die(mysql_error());
$num_row = mysql_num_rows($result);
$fname = $row["f_name"];
$mname = $row["m_name"];
$pass =base64_decode($row["password"]);
if($num_row > 0 ) {
require 'PHPMailerAutoload.php';
84 | P a g e
require 'credintial.php';
$mail = new PHPMailer();
//$mail->SMTPDebug = 4; // Enable verbose debug output
$mail->isSMTP(); // Set mailer to use SMTP
$mail->Host = 'smtp.gmail.com'; // Specify main and backup SMTP servers
$mail->SMTPAuth = true; // Enable SMTP authentication
$mail->Username = EMAIL; // SMTP username
$mail->Password = PASS; // SMTP password
$mail->SMTPSecure = 'tls'; // Enable TLS encryption, `ssl` also accepted
$mail->Port = 587; // TCP port to connect to
$mail->setFrom(EMAIL, 'HARAMAYA UNIVERSITY CEP EDUCATION

PROGRAM');
$mail->addAddress($_POST['email']); // Add a recipient
$mail->addReplyTo(EMAIL);
//$mail->addAttachment('/tmp/image.jpg', 'new.jpg'); // Optional name
$mail->isHTML(true); // Set email format to HTML
$mail->Subject ="Dear".$fname.$mname."Your".$pass;
$mail->Body = '<div style="border:2px solid red;">You can use it now! <b>in

bold!</b></div>';
$mail->AltBody = "This is your Password:-";
if(!$mail->send()) {
echo 'Message could not be sent.';
echo 'Mailer Error: ' . $mail->ErrorInfo;
} else {
85 | P a g e
echo 'Message has been sent';
}}
else{
header('location:access_password.php');
}}
?>
4.2. Test case
A test case is a set of sequential steps to execute a test operating on a set of predefined inputs
to produce certain expected outputs. There are two types of test cases:-manual and automated.
A manual test case is executed manually while an automated test case is executed using
automation
In system testing, test data should cover the possible values of each parameter based on the
requirements. Since testing every value is impractical, a few values should be chosen from each
equivalence class. An equivalence class is a set of values that should all be treated the same.
Ideally, test cases that check error conditions are written separately from the functional test
cases and should have steps to verify the error messages and logs. Realistically, if functional
test cases are not yet written, it is ok for testers to check for error conditions when performing
normal functional test cases. It should be clear which test data, if any is expected to trigger
errors. A test case is a set of sequential steps to execute a test operating on a set of predefined
inputs to produce certain expected outputs.
Ideally, test cases that check error conditions are written separately from the functional test
cases and should have steps to verify the error messages and logs.
Testing procedures
Before directly deploying this system, the team will perform different testing for its
functionality and meeting customers need. First the team tests each unit at each phase. So, if a
problem is encountered it will immediately fixed. Then the team will perform an integration
86 | P a g e
testing to check whether the system meets all the functional requirements. System will be tested
using the following system testing procedures
4.2.1. Unit testing
Every module of the System is separately tested. I.e. the team tests every module by applying
some selection mechanism. Through this mechanism every module gets tested. If an error
occurs correction will be taken without affecting another module. We have tried to test UI
screens of our system that needs to verify screen elements that appears on the screen.
4.2.2. Integrated testing

In this testing part, all the modules will be combined together and tested it for its fitness with
each other and with the systems functionality. If error occurs in combining them, the module
with problem will be identified and recombined. Both units testing and integrated testing are
performed by all team members at the work place and we performed both discussed tests
according Haramaya university continuity education program systems.
4.2.3. System Testing

Here we compile the whole system stating from initial and proceed testing the whole system
to check out for the errors and flow control of the system.
4.3. Conclusion
This project which has two phases; the first phase concerned with the analysis phase of the life
cycle, the design phase and the next phase is about implementation. As the end of the first
phase, we need to review that we have covered in accordance with what we have planned at
the beginning. We began our work by identifying the significance of automated system for the
store and the overall techniques to be used in the development process. This involved defining
the system development methodology, identifying process. This involved defining the system
development methodology, identifying resource and cost requirements, and setting the
deliverable and scheduled for the project.
The analysis helps the team to well understand the major functional areas and processes of the
system. Through this method we evaluate the existing system weakness and strength.
After that, we performed requirements elicitation to discover user and system requirements.
This phase consisted of drawing the functional as well as non-functional requirements of the
87 | P a g e
system. Then we have undertaken a major phase in system development process: object-
oriented Analysis. Here, we tried to model the new system we proposed using UML diagrams:
Use case, sequence, and activity and class diagrams Also, we designed the new system user
interface prototype.
4.4. Recommendation
The system that we have tried to automate is not the whole system of the HU distance and
continuing education. Because of time limitation and budget, we can’t develop all parts of the
system. Therefore, others are interested individuals to develop on distance and continuing
education can get some initial idea about the system and no need of more data gathering
process the only need will be improving the system. Next, we need to recommend the
college (Continuity and distance education) as they use this system and we have need and
want to finish the uncompleted part of this system to complete in next time. Finally, we
need to recommend our department (Information systems) to prepare the chance for us to
finish this project and to provides important support for us, if any.
4.5. Clients Feedback
By testing the system by user, we get good feedback. Some of the comments are:
 Since many activities are automated many problems of individual and organizations
are solved. These are resources such as Cost, Man power and Time
 It also attracts many students. Because it reduces man power, cost and time for the
college as well as for the students.
 Since the system needs some knowledge about the system there must be some training
for the users of the system in the future
Those are the comments we get from clients by showing the system for them. So, we
recommend, the system should be entitled to the responsible and skilled person (i.e.
system users and administrators). We highly recommend the system should be kept in
highly safe and favorable condition.
4.6. User manual preparation
88 | P a g e
Since the system is web based everything important for the user will be explained and
implemented while giving short training when the system is deployed.
For accessing the system, they must have a user account or if it is new then it should have to
apply or register to be a user of the Haramaya university continuity education program.
A) User manual for Apply

1 click on apply here:
2 after clicking apply button the application form will be appear the applicant should have to fill all
the fields with correct format then clicks submit
89 | P a g e
3 after application the user have wait for approval and verifies his/her email to get userId and
password.
4 After get his UserId and password through verifying his email address he/she become login into
systems.
90 | P a g e
5. The applicant enters the correct username and password and clicks on login
6. After login in the system display registration form that will be send to the administrator in order
to accept the applicant as a student after filling the form correctly click on register
B) User manual for managing user account
91 | P a g e
For students and Instructors
92 | P a g e
Finished here.
93 | P a g e
94 | P a g e
A) After student Login into student page
1.To download assignment
95 | P a g e
2.select course
3.Submit Assignment link
96 | P a g e
References
[1] H. University, "Directorate Of Continuing and Distance Education," Haramaya University, 2017.
[Online]. Available: http://www.haramaya.edu.et/academics/college-of-distance-and-
continuing-education/. [Accessed 10 2017].
[2] J. R. ,. J. Grady Booch, Unified Modeling Language User Guide, Francis Ching: Addison Wesley,
First Edition October 20, 1998.
[3] Ambsoft, "Building Object Applications That Work," Ambsoft Inc., [Online]. Available:
Class%20Type%20Architecture_%20A%20Strategy%20for%20Layering%20Software%20Applica
tions.html.
[4] S. W. Ambler, The Object Primer, Third Edition, Cambridge : Cambridge University , 2004.
[5] T. Abdulhamid.A, "CEP final report," HU,CCI,Information system, harar, 2007.
[6] GiantDino, Unified Modeling Language User Guid, Addison Wesley, 6th printing, April 2000 .
[7] G. Booch, "Object diagram,chapter 14," in Unified Modeling Language User Guide, The, Addison
Wesley , 2000.
[8] T. C. a. C. Begg, "A Practical Approach to Design,Implementation, And Managment," in

database system, British, 2005, p. 1374.
[9] S. W. Ambler, The Object Primer, Third Edition, Cambridge: Cambrigde University, 2004.
[10 S. W. Ambler, "The Object Primer, Third Edition," Cambridge University Press © 2004 (572
] pages), Cambridge, 2004.
[11 S. W. Ambler, The Object Primer, Third Edition, Cambridge: Cambridge University , 2004.
]
97 | P a g e
Appendix I
The following question are the lists questions that we were used during conducting interview
and gathering requirement. There are two parts of this question one regarding to the background
of organization and second regarding to the existing system of college.
1, when was the college of continuity and distance education were established in Haramaya
university? __________
2, During the establishment of this (CCDE) what is the main purpose that the college focused
on to address? __________________________________________________
3, Is this college is the beginning college of distance and continuous education in different
Ethiopia University or not? _________________________________________
4, At the beginning of this college(CCDE) with how many departments that the college start to
run the program what are their name? ___________________________________
5, In case of some challenges that exist and difficulty how can student come with the solution
to solve and improve their education quality and to come with solution?
___________________________________________________________________________
___________________________________________________________________________
6, Is the college the college starts by giving certificates, diploma program or degree? If it were
started with certificate program? When was the college started providing diploma and degree
program? ______________________________________________________
7, we observe that the college are currently running the manual system and how can student
get registered, get access to college resource related to the learning? ___________________
8, How the student pay fee for the course and what kind of payment was expected from student?
_________________________________
9, In this continuous and distance education, how can student add and drop course in case of
some problem like prerequisite course? __________________________
98 | P a g e
10, In case of distance and some challenges can student change center of college they are taking
course and transferred to other center without challenge? ________________________.
99 | P a g e

CEP All Capter Final Projects

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

CEP All Capter Final Projects

Încărcat de

Drepturi de autor:

Formate disponibile

HARAMAYA UNIVERSITY

College of computing and informatics

Department of Information Systems

HU Continuous and distance education program system A final

IWUNATU DEGEFA (1486/07)

ZAHARA ASSEN (1650/07)

SHIMALLIS SHURAMO (1592/07)

SELAMAWIT GETAHUN (1584/07)

Name of Advisor: ___________ Name of School Head: _____________

Signature of Advisor: _________ Signature of School Head: ___________

Name: ____________________ Name: ______________

Sign: _____________________ Sign: ________________

2.4 Class Responsibility Collaboration (CRC)..................................................................................... 15

Testing procedures ........................................................................................................................... 86

Table 1.1 Software Tools And Programming Language Used. ................................................. 7

Figure 3.14 Activity Diagram For Registration Request ......................................................... 55

Figure 3.17 Activity Diagram For Request Withdrawal .......................................................... 56

Figure 3.21 User Interface For Homepage .............................................................................. 59

SRS = System Requirement Specification

CCDE = College of Continuous and Distance Education

1.1. BACKGROUND OF THE ORGANIZAITON

Wolayita Sodo center

1.2. Statement of the problem

 It takes high cost to duplicate learning material and distribution

1.3 Objective of the project

1.3.1 General objectives

1.3.2 Specific objectives

 To overcome the problem of manual applying and registration system

1.4 Methodology of the project

1.4.1 System development methodology

1.4.2 Data Collection method

1.4.3 Development Methodology

1.4.4 System Model

1.5 Software tools and Programming Language Used.

3 Server-side PHP  Because it is compatible with wide

1.6 Scope and limitation of the study

1.6.1 Scope of study

1.6.2 Limitation of Study

 Lack of Internet connection.

1.7 Significance of the study

1.8 Budget plan

Table 1.2 Project Budget Plan

1.9 Feasibility assessment

1.9.1 Economic feasibility

 Easy and fast file management.

 Give more readable, reliable, easily manageable, and database which

1.9.2 Technical feasibility

1.9.3 Operational feasibility

1.9.4 Schedule feasibility

Table 1.3 time Schedule Feasibility (Gantt Chart)

1.10 Management issues

1.10.1 Team configuration

5.Shimalis Shuramo Sorsa,  Implementation and Testing

1.11 Communication plan

date Time Techniques

SYSTEM REQUIREMENT SPECIFICATION AND ANALYSIS

2.1. Overview of the existing system

2.3 Overview of Proposed System

2.4 Class Responsibility Collaboration (CRC)

 Class –represents a collection of similar objects. An object is a person, place, thing,

There are three types of classes

 Actor Classes – actors that appear in use case.

Figure 2.1 Crc Diagram for Actor Class

Figure 2.2 CRC diagram for business class

Name of Advisor: _ Name of School Head: ___

Signature of Advisor: _ Signature of School Head: ___

Name: ______ Name:

Sign: _____ Sign: