AUWC WEB-BASED STUDENT CLERANCE MANAGEMENT SYSTEM

School of Technology and Informatics

Department of: -Information Technology
Summer Program
Project Proposal on: - Web-based Student Clearance Information
Management System for AUWC.

Group Name ID
1. Hailu Chemeda Daba IT-SUM/081/10
2. Lencho Lema Ligaba IT-SUM/087/10
3. Guta Ayano Gemechu IT-SUM/078/10
________________________________
4. Chindi Geleta Dinsa IT-SUM/046/10 __________
5. Hundaol Tolera Sebeta IT-SUM/075/10

Under Advisor of: - Obsa Dagabasa (MSc)

Woliso, Shewa Ethiopia
06, December, 2023

AMBO University Woliso Campus School Of Technology and Page

Informatics Department of Information Technology 1
AUWC WEB-BASED STUDENT CLERANCE MANAGEMENT SYSTEM

I. Table Contents

Contents…………………………………………………………………………………Page
..........................................................................................................................................................I

II. List of Tables.......................................................................................................................V

III. Acronyms...........................................................................................................................VI

Declaration...................................................................................................................................VII

2. Background of the organization...................................................................................................1

2.1. Vision AUWC.......................................................................................................................2

2.2. Mission AUWC.....................................................................................................................2

3. Background of the project...........................................................................................................2

4. Statement of the problem.............................................................................................................2

5. Proposed system..........................................................................................................................3

6. Objective of the project...............................................................................................................4

6.1 General Objective..................................................................................................................4

6.2 Specific Object.......................................................................................................................4

7. Significance of the project...........................................................................................................4

8. Beneficiaries of the system..........................................................................................................5

9. Scope of the project.....................................................................................................................5

10. Limitation of the project............................................................................................................6

10.1. Time constraints..................................................................................................................6

10.2. Financial constraints:..........................................................................................................6

11. Methodology for the project......................................................................................................6

11.1. Data source.........................................................................................................................6

11.2. Fact Finding Techniques.....................................................................................................7

I|Page AUWC School of Informatics, and Technology

AUWC WEB-BASED STUDENT CLERANCE MANAGEMENT SYSTEM

11.3. System Analysis and Design...............................................................................................7

11.4. Development Tools............................................................................................................7

11.5. Testing Procedures..............................................................................................................8

11.6. Implementation...................................................................................................................9

12. Feasibility Analysis...................................................................................................................9

12.1. Operational Feasibility........................................................................................................9

12.2 Technical Feasibility............................................................................................................9

12.3 Economic Feasibility..........................................................................................................10

12.4. Organizational Feasibility.................................................................................................10

12.5. Ethical Feasibility.............................................................................................................11

13. Activity plan............................................................................................................................12

13.1 Team composition..........................................................................................................13

1.4.1 Time Schedule.............................................................................................................14

14. Cost breakdown.......................................................................................................................15

14.1.1. Cost of the project......................................................................................................15

14.1.2. Cost breakdown..........................................................................................................15

Chapter Two..................................................................................................................................16

2.1. Introduction to Business Area Analysis..............................................................................16

2.2Existing System Description.................................................................................................16

2.2.1. Beneficiaries of the Existing System...............................................................................17

2.2.2 Activities in the existing system.......................................................................................17

2.2.2.1 Input Analysis.............................................................................................................17

2.2.2.2 Process Analysis.........................................................................................................17

2.2.2.3. Output Analysis.........................................................................................................17

2.2.3. Problem of the Existing System.......................................................................................18

II | P a g e A U W C S c h o o l o f I n f o r m a t i c s , a n d T e c h n o l o g y
AUWC WEB-BASED STUDENT CLERANCE MANAGEMENT SYSTEM

2.2.3.1. Performance (Response time)...................................................................................18

2.2.3.2. Input (Inaccurate/redundant/flexible) and Output.....................................................18

2.2.3.3. Security and Controls................................................................................................18

2.2.3.4. Efficiency..................................................................................................................18

2.2.4 Forms and Other Documents of the Existing System.......................................................19

2.2.5 Structure of the Organization (System Architecture).......................................................21

2.3 Proposed system...................................................................................................................22

2.3.1. Description and purpose of the proposed system.........................................................22

2.3.2Proposed System Architecture.......................................................................................23

2.3.3. Data processing Architecture of proposed system.......................................................23

2.4. Requirements of the Proposed System................................................................................24

2.4.1. Functional requirements...............................................................................................24

2.4.2. Non-functional requirements........................................................................................25

2.6.2 Essential Use case Diagram Identification........................................................................27

2.6.3 Essential Use case Diagram..............................................................................................29

2.6 .4. Essential User Interface Prototyping...........................................................................30

2.7. Analysis Model...................................................................................................................31

2.7.1. Use Case Actor Identification and Description................................................................31

2.7.2. Use case diagram.............................................................................................................32

2.7.4. Sequence Diagram...........................................................................................................39

2.7.5 Activity Diagram...........................................................................................................45

2.7.6. Collaboration Diagram.................................................................................................50

2.8 State chart.............................................................................................................................54

Chapter Three: System Design......................................................................................................55

3.1. Purpose and design goals....................................................................................................55

III | P a g e A U W C S c h o o l o f I n f o r m a t i c s , a n d T e c h n o l o g y
AUWC WEB-BASED STUDENT CLERANCE MANAGEMENT SYSTEM

3.2. Design Goals.......................................................................................................................55

3.3. Site Map..............................................................................................................................56

3.4. System decomposition........................................................................................................57

3.5. Layer Class Diagram...........................................................................................................57

3.6. Component Modelling.......................................................................................................59

3.7. Deployment modelling........................................................................................................59

3.8. Class Diagram Modelling...................................................................................................61

3.8. 1Inheritance Class Diagram................................................................................................63

3.9. Persistence modelling.........................................................................................................63

3.10. Access Control and Security.............................................................................................64

3.11. User interface design...........................................................................................................65

References..................................................................................................................................66

IV | P a g e A U W C S c h o o l o f I n f o r m a t i c s , a n d T e c h n o l o g y
AUWC WEB-BASED STUDENT CLERANCE MANAGEMENT SYSTEM

II. List of Tables

Table 1.1 Development Tools........................................................................................................8

Table 1.2. Work break down structure.........................................................................................12

Table 1 3: Time Schedule for Our Project.....................................................................................14

Table 1 4. Hardware Requirement Cost.......................................................................................15

Table 1.5:- Software Requirement Cost.......................................................................................15

V|Page AUWC School of Informatics, and Technology

AUWC WEB-BASED STUDENT CLERANCE MANAGEMENT SYSTEM

III. Acronyms

AUWC: Ambo University Woliso Campus

CRC: Class Responsibility Collaboration

CSS: Cascading Style Sheet

DB: Data Base

GB: Giga Byte

HTML: Hyper Text Markup

MYSQL: My Structured Query Language

OOM: Object-oriented modeling

RAM: Random Access Memory
SCIMS: Student Clearance Information Management System.

VI | P a g e A U W C S c h o o l o f I n f o r m a t i c s , a n d T e c h n o l o g y
AUWC WEB-BASED STUDENT CLERANCE MANAGEMENT SYSTEM

Declaration
The project is our own and is not presented for a degree in any other University and all the
source of material used for the project have been duly acknowledged. (Name and signature up to
the number of the project group member).

Name Signature
1. Hailu Chemeda _____________
2. Lencho Lema _____________
3. Guta Ayeno _____________
4. Chindi Geleta _____________
5. Hundaol Tolera _____________

Faculty of: - Informatics and Engineering.

Department of: -Information Technology

Project subject: -AMBO UNIVERSITY WOLISO CAMPUS STUDENTS’S WEB-BASED

CLEARANCE SYSTEM

I certify that this project satisfies the entire requirement as a project for the degree of Bachelor of
science Information technology.

Name of program coordinator: __________________________ Signature______________

This is to certify that I have read this project and that in my opinion it is fully adequate, in scope
and quality, as a thesis for the degree of Bachelor of Science in Information Technology.

Name of Advisor 1. _________________________signature______________

Examining committee members

1. Chairman ______________________Signature ___________________

2. Examiner 1 _____________________Signature ___________________
3. Examiner 2_____________________ Signature ___________________

It is approved that this project has been written in compliance with the formatting rules laid
down by the faculty of the University.

VII | P a g e A U W C S c h o o l o f I n f o r m a t i c s , a n d T e c h n o l o g y
AUWC WEB-BASED STUDENT CLERANCE MANAGEMENT SYSTEM

1. Introduction
Clearance is a status granted to individuals typically students allowing them access to
information. The term clearance is also sometimes used in private organizations that have a
formal process to check the student information. A clearance by itself is normally not sufficient
to gain access the organization must determine the cleared individual has need to know the
information.

Clearance is the process of determining and negotiating any permission that are needed to
use of someone else’s intellectual property creative project. Part of that process includes: -

Determining the owner(s) of the intellectual property.

Contacting the owners and negotiating on agreement.
Administering written contracts.
Handling other issues related to the use and licensing of intellectual property.

No one is supposed to be granted access to classified information solely because of rank or

position, but once a clearance is obtained access to certain information or gain of freedom will be
granted.

The proposed system over comes one problem done by manual system. To reduce misuse of
manpower, avoiding errors, to save time, to provide comfort clearance process for the students
and to provide insurance for the organization especially for workers who play role in the
clearance processing system.

This system works for students of Ambo University Woliso Campus. The online clearance
processing system allows the students to register for the membership to access the service of the
system.

2. Background of the organization

Ambo University is one of the fastest growing Ethiopian Universities, currently expand to four
campuses. In addition to the main campus, it has three functional campuses - Awaro Technology
Campus, Guder agriculture campus and Woliso Business and Economics faculty. Among these
campuses, Woliso is the one, which was started in 2002 E.C by having Accounting and finance,
Economics, management and information technology departments. By now, it is teaching 38

1|Page AUWC School of Informatics, and Technology

AUWC WEB-BASED STUDENT CLERANCE MANAGEMENT SYSTEM

departments and in the course of these developmental processes, it had enrolled students from
various backgrounds. The Directorates of Campus Registrar is responsible Ambo University
Woliso Campus student’s clearance processing system is one of the processes that will be done
to be cleared the students from the campus by re-backing all resource, and student also get their
clearance simply from one system.

2.1. Vision AUWC

AUWC aspires to be the leading higher educational institution being center of excellence in
education and research in areas of natural resources and cultural value utilization for
development.

2.2. Mission AUWC

AUWC has a mission of supporting the development endeavors of the people by tackling the
insistent problems by utilizing natural resources and cultural values, through inculcating
scientific knowledge and skills relevant to the country and assuring quality education.

3. Background of the project

Ambo University Woliso Campus student’s clearance processing system is one of the processes
that will be done to be cleared the students from the campus. The manual clearance system starts
the process as Ambo University Woliso Campus was established in 2003.E.C.

The system gives its function to many users of the University. The numbers of students grow
from year to year in many numbers. Now a day, there are many users of the clearance processing
system. But the project gives a service only the students. The students get one copies of
clearance sheet from department and get signature and stamp from around eight offices. These
are Advisor, Bookstore, Library, Health and physical Education, Student’s Proctor, Student
Service, and Institute Registrar. After they finished all necessary requirements, finally the
students take copies of sheet that has all signature and stamp from all offices. This processing
makes the students bulky because they go to about eight office.

2|Page AUWC School of Informatics, and Technology

AUWC WEB-BASED STUDENT CLERANCE MANAGEMENT SYSTEM

4. Statement of the problem

The process of clearing students of a named institution Ambo University Woliso Campus after
the end of academic year requires that the students must be cleared in their various departments.
This clearance processing system service currently uses manual system which creates the
following major problems.

Data recording system is not centralized or not in the modern system which is difficult to
search.
Data redundancy &loss of data.
Consumes more resources to complete the process which is of high cost such as:-
Stationary material.
Printers and computers.
Need more manpower to process the clearance in the respective offices.
Error is happened during process the clearance System.
The process is very offensive for students when there is a harsh atmosphere like rain.
To process the clearance is lot of queue because of the number of users.
Employees involved in the clearance process are not available 24 hours of the day.

Hence, it became imperative for computer software based online clearance system to
eliminate the shortcoming of the manual system in place as above listed problem.

5. Proposed system
The new system is designed to solve problems affecting the manual system in use. It is design to
be used online thereby relieving both the students and the offices workers from much stress as
experienced in the manual system.

This system will do the analysing and storing of information either automatically or interactively.
It will make use of online access to Internet. The proposed system will also have some other
features like: -

Login system must be present and secured by password and logout after cover.
Accuracy in the handling of data.
Fast rate of operation and excellent response time.

3|Page AUWC School of Informatics, and Technology

AUWC WEB-BASED STUDENT CLERANCE MANAGEMENT SYSTEM

The system is flexible i.e. it can be accessed at any time.

Easy way of back up or duplicating data in diskettes in case of data loss.
Better storage and faster retrieval system.
Accessibility from anywhere.

6. Objective of the project

6.1 General Objective

The main objective of this project is to change the manual clearance processing system to web
based system and solve the above stated problems.

6.2 Specific Object

To accomplish the general objective successfully we will be breaking the general objective into
the following specific objective: -

Able to register students.

clearance approval.
sending clearance form.
property controlling.
user management.
Check students from the data base.
Fast searching and data processing.

7. Significance of the project

The project work will help in a good way to ease the queuing system in the university as the
online clearance system will help students to achieve whatever they want without coming to the
various offices for clearance personally such as dormitory, bookstore, registrar, sport, library
and student service.

Online student clearance system allows the users to check their clearance status as whether they
are in any way obligated to the university, fill and submit their clearance form, and obtain their
clearance letter. There are many other advantages of student’s online clearance system. Some of
them are listed below: -

4|Page AUWC School of Informatics, and Technology

AUWC WEB-BASED STUDENT CLERANCE MANAGEMENT SYSTEM

It saves a time.
It is very convenient to use it right from the dormitories, office or anywhere in the
campus.
Information processing is very fast and delays can be minimized.
Help the University in reducing cost such as labour and stationary.
Process clearance effectively and efficiently.
Provides a reliable and transparent clearance processing system.
It provides borderless access.
It provides a reliable and transparent system devoid of person interest and inclination.
The system removes the problems of stress, travelling to different office and queuing up
of students during processing of the clearance.

8. Beneficiaries of the system

This project provides many benefits for: -

1. Students: - by providing fast access to the clearance system by reducing time like waiting
in the queue and going to different offices. The students also access the system anywhere
and anytime when they need the clearance. It improves the tiredness of student by avoiding
to going to different offices to get the clearance system.
2. University: - In manual system there is loss of materials like time, paper, pen which is cost
and more manpower, the system reduces loss of costly materials and manpower.
3. Developers of the project: - it increases our knowledge and we get moral satisfaction from
the project we developed.

9. Scope of the project

This project is limited only for Ambo University Woliso Campus students. Currently the
university performs clearance system manually or paper-based processing system. Generally, the
scope of this project includes: -

Our system used for AUWC students only.

The System contains all the recorded information that can be handled by the
registrar and other offices.

5|Page AUWC School of Informatics, and Technology

AUWC WEB-BASED STUDENT CLERANCE MANAGEMENT SYSTEM

The proposed system is accessed by English language.

10. Limitation of the project

Defines what the proposed system is not going to perform or what is not including in the
proposed system. This project covers some of the aspects of computer software based online
clearance processing system using Ambo University Woliso Campus as case study. However, we
have identified the following are the constraints: -

10.1. Time constraints

Due to time constrain the web page covers only clearance for various departments by the
students.

10.2. Financial constraints: -

Due financial constraints people cannot afford this kind of process online especially towards the
cost of accessing the internet. Therefore, it would cost a lot to develop a full web-based clearance
processing system. Generally, we may identify some limitation of this project includes: -

This project done only for Ambo University Woliso Campus students.
The system couldn’t give service to academic staff, Supportive, and administrative staff
i.e. limited only for students.
If the students lost/damage the university property, he/she couldn’t gain clearance, until
the students pay the cash/damaged personally to finance (no tolerance for any property
damage/lost).
The proposed system cannot access with their local language.

11. Methodology for the project

11.1. Data source
Is the way or mechanism in which we gather information to develop the system.
We have used the following methods: -

By seeing the forms that the existing system uses how students clear and take out their
property from the campus.

6|Page AUWC School of Informatics, and Technology

AUWC WEB-BASED STUDENT CLERANCE MANAGEMENT SYSTEM

Interviewing the heads of the office and the clerk (asking open and closed question)
Observing different files and reporting documents.
Collecting information from different references, projects and web sites
By discussing and analysing the problems with project team.

11.2. Fact Finding Techniques

I. Practical Observation: - we observed physically the current existing system which is

done by manually. We referred different forms and documents in the department,
registrar and some other offices.
II. Document Analysis: - For more information about the existing system we refer relevant
documents, others reading materials and some forms in different offices.
III. Interview: - To get the basic information and background information about the existing
system structure, we ask different question from different persons who provide clearance
system.

11.3. System Analysis and Design

In this project the team used Object Oriented System Analysis and Development methodology
(OOSAD). This has two phases.

A. Object Oriented Analysis (OOA): - During this phase the team used to model the
functions of the system (use case modelling), find and identify the business objects,
organize the objects and identify the relationship between them and finally model the
behaviour of the object.
B. Object Oriented Design (OOD): - During this phase the team used to refine the use case
model to reflect the implementation environment, model object interactions and behaviours
that support the use case scenario, and finally update object model.

11.4. Development Tools

Software: - This project uses the following system development tools for different activities.

7|Page AUWC School of Informatics, and Technology

AUWC WEB-BASED STUDENT CLERANCE MANAGEMENT SYSTEM

Tools Activities
Notepad++ For editing code
CSS For attractive layout
PHP Back end (Server-side coding)
HTML Client-side coding
MYSQL Back end (data base)
Apache Server As server
Mozilla Firefox, IE, Google Chrome, Opera Browsers
Ms office word 201/19 For Documentation
Ms office PowerPoint 201/19 For Presentation
Ms office Visio 201/19 To draw UML Diagram and for
designs
Adobe Photo Shop CS5 To design back ground images
Table 1.1 Development Tools
Hardware

 Hard Disk
 External Hard drive 1T
 Flash Disk 32GB
 HP LaserJet Printer

11.5. Testing Procedures

We use the above listed software development tools to design or implement the proposed system,
because the tools are compatible to develop the proposed system. We will also perform different
testing for checking functionality of our proposed system.

1. Unit testing: - First we will test each unit at each system. So, if a problem is encountered it
will immediately maintain at which the problem is occurred.
2. Integration Testing: - After we test each unit of the proposed system we will perform an
integration test to check whether the system meets all the functional requirements. When a

8|Page AUWC School of Informatics, and Technology

AUWC WEB-BASED STUDENT CLERANCE MANAGEMENT SYSTEM

number of components are complete, it will test to ensure that they integrate well with each
other like operating system, and other components.
3. System Testing: - After all of the above testing are checked we will test our system by
other peoples and we will conduct some comments how they get our system.

11.6. Implementation

The current student clearance processing system is still working. Since we cannot change it
directly or partially we choose to develop the proposed system parallel to the existing system.
We are going to change the manual clearance Processing system after the user is familiar with
the proposed system, until that the users and the university uses parallel with the manual
clearance processing system.

12. Feasibility Analysis

Feasibility analysis enables the system to determine ether or not the project can be developed,
evaluates and identifies the newly developed system. Therefore, the feasibility analysis of
proposed system involves the following feasibility:

12.1. Operational Feasibility

The proposed system will solve the business and time problem for the organization. Therefore,
the campus administration and other users providing effective processing system, which satisfies
their needs.

The proposed system offers greater level of user-friendliness.

The proposed system produces best results and gives high performance.
The proposed system can solve the existing system problem and challenge.

12.2 Technical Feasibility

The system developers (we) understand the scope, objectives including specific objectives and
limitations of the proposed system well and the users have technical capability/ability to use this
system. As a result, we will develop the system for Ambo University Woliso Campus
successfully within proposed resources (budget, time, etc.). This also deals with the hardware as
well as software requirements. We have to find out whether the necessary technology and the

9|Page AUWC School of Informatics, and Technology

AUWC WEB-BASED STUDENT CLERANCE MANAGEMENT SYSTEM

proposed equipment have the capacity to hold the data used in the project. The technical
feasibility issues usually raised during the stage of fact finding includes the following: -
This software is running in windows and Linux operating system.
The system can be expanded in any system platforms.

12.3 Economic Feasibility

When the team can be analyses the system by comparing the cost with the benefit (the enterprise
can get by using the proposed system), surely the benefit out weights the cost. The cost of
developing a full system, including software and hardware cost for the class of application being
considered should be evaluated. So, the benefit that obtain by using the proposed system can be
categorized as tangible and in tangible.

Tangible benefits are: -

Using less man power than the existing system.

Increase speed of activities and competence.
Reduce cost.

Intangible benefits are: -

Knowledge required by project developer.

Facilitating information processing.
Updating information.
Increasing the competitiveness of the individual.
Improved productivity.
Improving the morale of our team.
Facilitating information processing of our team

Therefore, the team decided the proposed project is economically feasible.

12.4. Organizational Feasibility

Behavioural feasibility is the measure that how users use the system effectively. The proposed
system should be easy to operate, convenient in maintenance and effective in its working. Thus
behavioural feasibility is very important factor to be considered for effective working of the

10 | P a g e A U W C S c h o o l o f I n f o r m a t i c s , a n d T e c h n o l o g y
AUWC WEB-BASED STUDENT CLERANCE MANAGEMENT SYSTEM

system. Behavioural feasibility is dependent on human resources available for the project and
involves projecting whether the system will operate and be used when it is functionally
operating.

As our project plan we try to identify that the system is behaviourally feasible because of the
following: -

The proposed system is easy to operate.

Retrieval of information is easy, accurate, and fast.

Since developing this new system will solve Ambo University Woliso Campus clearance system
problems and also overcome the manual base system, the users will undoubtedly have a positive
attitude towards the system and the system is politically feasible and free from any legal claims.

12.5. Ethical Feasibility

Since developing this new system will be solving the clearance system problems, the users will
undoubtedly have positive attitude towards the system and the system is politically feasible and
free from any legal claims.

11 | P a g e A U W C S c h o o l o f I n f o r m a t i c s , a n d T e c h n o l o g y
AUWC WEB-BASED STUDENT CLERANCE MANAGEMENT SYSTEM

13. Activity plan

Ambo University Woliso Campus Student’s web-based Clearance System

WS Tasks Duratio Predecesso Responsible

N n r
O
R 1 Project initiation and Planning
Gathering information
1 weak All

K 2 Description of the project 2 weak 1 Hailu Chemeda

B Introduction:
Back ground information
R Statement of the problem
E Objective of the problem
Scope and limitation of the
A project
K Methodology
Feasibility study
3 Current system 1 weak 1,2 Lencho Lema
D Description of current system
O Players in the existing system
Business Rules
W Bottlenecks of the existing
N system
4 Proposed System 3 weak 1,2,3 Guta Ayano
Functional Requirement
S Non-Functional Requirements
T User interface
Hardware or software
R requirements
U Security and safety procedure
5 System Modelling 1 weak 4 Chindi Geleta
C
Use case diagram and their
T description
U Object Model
Dynamic Model
R 6 Implementation 12 weak 3,4 Hundaol Tolera
E Design
S Coding
Testing
Documentation
Under Advisor of: -Obsa Dagabasa

Work breakdown structure for the project

Table 1.2. Work break down structure

12 | P a g e A U W C S c h o o l o f I n f o r m a t i c s , a n d T e c h n o l o g y
AUWC WEB-BASED STUDENT CLERANCE MANAGEMENT SYSTEM

13.1 Team composition

We have organized our self (team member) in a decentralized way that every team member
communicates to each other and diagrammatically.

Hailu; - Project
Manager

Guta: -
Programmer
Lencho: -
System Finalist

Hundaol: - Chindi: - System

Testing System Analyst

Fig 1.1 Team composition

13 | P a g e A U W C S c h o o l o f I n f o r m a t i c s , a n d T e c h n o l o g y
AUWC WEB-BASED STUDENT CLERANCE MANAGEMENT SYSTEM

1.4.1 Time Schedule

Within the time duration, we have identified the activities of the project in order to accomplish the project objective within their
schedule requirement which is on the table below.

N Task Start date Duratio End date

o n
1 Title submission Nov07/11/2023 3 Nov/
10/11/2023
2 Proposal Nov16/11/2023 2 Nov/
submission 18/11/2023
3 Requirement Nov/19/2023 8 Nov/26/2023
Analyses
4 Proposal Nov/30/2023 1 Nov/30/2023
documentation
presentation
5 System Design Dec/1/2024 80 Jan/20/2024
6 Project document Jan/25/2024 5 Jan/30/2024
Analysis Defense
7 Coding Feb/16/2024 96 May/20/2024
8 Implementation Jun/21/2024 30 Jun2/20/2024
and Testing
9 Final project Jun/25/2024 5 Jun/30/2024
Presentation

Table 1 3: Time Schedule for Our Project

14 | P a g e A U W C S c h o o l o f I n f o r m a t i c s , a n d T e c h n o l o g y
 14. Cost breakdown
14.1.1. Cost of the project

A. Hardware Requirements cost

No Materials Required Amount Price Per Unit Total Cost

1 Toshiba Computer 2 12000 24000
2 Pen 10 4 40
3 A4 Size Paper 1 Destin 110 110
4 Print 100 1 100
5 Flash Disk 1(8G) 120 120
6 CD-ROM 2 7 14
Total 24384

Table 1 4. Hardware Requirement Cost

14.1.2. Cost breakdown

A. One-time cost: - are costs incurred at the time of developing our project.
B. Recurring costs: -are costs incurred to maintain our project once developed.
A. Software Requirements Cost
No Materials Required Price Per Unit
1 Microsoft Word 2013 Free
2 Notepad++ Free
3 Microsoft Office Visio 2007 Free
4 SQL Server 120
5 Mozilla Firefox Free
Total 120
Table 1.5:- Software Requirement Cost

15 | P a g e
 Chapter Two
2.1. Introduction to Business Area Analysis

Business area analysis is a research discipline f identifying business and determining solutions to
business problems. Solutions often include a software-systems development component, but may
also consist of process improvement, organizational change or strategic planning and policy
development. The person who carries out this task is called a business analyst or BA [2].

Business analysts do not work solely on developing software systems. Those who attempt to do
so run the risk of developing an incomplete solution [3].

Although there are different role definitions, depending upon the organization, there does seem
to be an area of common ground where most business analysts work. The responsibilities appear
to be:

Goals: -
Isolate functions and procedures that allow the area to meet its goals
Define data objects visible at the business area level
(+ relationships & data flow)
Identify information support systems

2.2Existing System Description

The current clearance processing system is a manual system that needs intensive human labor,
resource, consume time, and less security. Here, the students to visit all the clearance offices
with a form for them to fill and get sign by the respective offices. Once these forms are signed, it
proves that the users have been cleared. This process takes some days to be completed and
possess a lot of stress to all the users and workers who provide the clearance system.

In the manual system, the clearance forms are documented in a file cabinet. Each time the
clearance form is needed, a search operation conducted on the file cabinets to locate a particular
user’s clearance form.

16 | P a g e
2.2.1. Beneficiaries of the Existing System

The main players in the existing system include the following: -

Students: - Students will go to department to get the clearance form and fill the form then go
to different offices to get sign.
Registrar: - They sign in the form and give the form to the students.
Proctors: - They check the dorm materials like bed, window, door, and the door key if all are
not damage they sign in the student’s clearance form.
Library: - They check whether the borrowed books were returned or not.
Sport Science: - This office checks sports materials whether the student takes them from the
office or not.
Student Service: - Any student debt is defined in this office.
Book Store: - They check if the students have borrowed a book and returned the book or not,
if they have not borrowed the students are cleared and they sign in to the clearance form.
Departments: - Distribute clearance paper forms for the students in respective department.
Security Guard: -They check the student properties are matched with their clearance paper.

2.2.2 Activities in the existing system

2.2.2.1 Input Analysis

Input to the system is the form which is fulfilled by the proper users. These forms are filled by
student and submitted to the various offices for issuing of receipts.

2.2.2.2 Process Analysis

The form is filling by the students then collected and signed by the concerned offices to certify
that the student has completed all the necessary things. Hence a certificate issued to show that
the student has completed all the clearance processing.

2.2.2.3. Output Analysis

The output from the system is the certificate or one form of clearance issued to the student
stating that the student fulfilled all university obligations and is now free to pass out from the
university.

17 | P a g e
2.2.3. Problem of the Existing System

Due to the manual means being used by the university, in keeping information about student’s
clearance, a lot of problems are encountered which includes: -

2.2.3.1. Performance (Response time)

Wait in the queue while processing the clearance form.

Unavailability of some key staff while processing the clearance form.
Takes a lot of time to get back a particular clearance from the respected offices.
The existing system is not computerized every concerned person should be needed
physical for proofing the clearance.

2.2.3.2. Input (Inaccurate/redundant/flexible) and Output

During filling of the form, the user may fill inaccurate or incorrect information and may miss
necessary information, this show the system is inaccurate and the system is not flexible because
if user wants to erase the form he/she must only change another form.

2.2.3.3. Security and Controls

Loose of vital documents as the filing system is manual.

Damage of document due to fire or rain incident.
Take a lot of time to retrieve a particular clearance form.
Delay in processing clearance form.
Illegal removal of forms by falsified staff leading to insecurity.

2.2.3.4. Efficiency

Due to the manual operation most of the activities are easy to wastage of resources like
stationary materials, manpower, time etc. to produce the corresponding outputs. This makes the
current system inefficient, inaccurate, time consuming and it also utilizing many resources.

18 | P a g e
2.2.4 Forms and Other Documents of the Existing System

The forms generated in the existing system are in the forms of form and files.

Forms: - Forms are the reports generated in the existing system that contains all information
filled by the university student.

Files: -Files are the collection of information about the students who involve in the clearance
processing system. These all reports kept in the offices of the university to store information
about the university student.

19 | P a g e
Figure 2.1 Students Clearance form

20 | P a g e
2.2.5 Structure of the Organization (System Architecture)

Student
(Signature and Stump)

Department

(Signature and Stump)

Procter

(Signature and Stump)

Cafteria
AUWC
Office of
(Signature and Stump)
The
Library Registrar

(Signature and Stump)

Sport Master

(Signature and Stump)

\ Dormitory

Figure 2.2 System Architecture

21 | P a g e
2.3 Proposed system

The new system is designed to solve problems affecting the manual system in use. It is design to
be used online thereby relieving both the students and the offices workers from much stress as
experienced in the manual system.

This system should do the analysing and storing of information either automatically or
interactively. The proposed system will also have some other features like: -

Login system should be present and secured by password and logout after cover.
Accuracy in the handling of data.
Fast rate of operation and excellent response time.
The system is flexible i.e. it can be accessed at any time.
Easy way of back up or duplicating data in diskettes in case of data loss.
Better storage and faster retrieval system.
Accessibility from anywhere.

2.3.1. Description and purpose of the proposed system

The goal of the proposed system is replacing the manual system currently used by Ambo
university Woliso Campus clearance service to computerized web-based system. This will bring
operational efficiency by minimizing time wastage and cost funded by the university to clearance
service and minimizes the burden of all campus clearance management system by replacing
paper-based system to computerized, replace stumping and pasting allocation paper by
announcing throughout internet.

22 | P a g e
2.3.2Proposed System Architecture

Figure 2.3 System architecture

2.3.3. Data processing Architecture of proposed system

Figure 2.4 Data processing architecture

23 | P a g e
2.4. Requirements of the Proposed System
2.4.1. Functional requirements

Functional requirement defines a function of a system and its components. A function is

described as a set of inputs, behavior, outputs, data manipulation and processing and other
specific functionality that define what the system is supposed to accomplish.

Clearance approval: -The system performs to the student clearance approval in order to clear
the user from the compound.

Sending clearance form: -The system performs after the user(student) finish up the form
requirements or the information that the student fill then it will be sent to other concerned
offices.

Property controlling: The system performs proper property control that when the student takes
or borrow any kinds of properties the system will record those properties to its database.

Check students from the campus data base: The system will check whether the student is
active or not when by saying active legally registered to the university from the AUWC registrar
database.

Fast searching and data processing: The system performs fast and accurate result comparing to
the privies one.

Backup and Recovery: - When team member standard to develop a system they must have to
put use a backup mechanism by using removable flash disks, External Hard Disk or CDs.

Input related requirements: - After the system is implemented, to perform a process it needs
inputs like student username, student ID No and other information which are necessary to in
processing clearance are entered in clearing process.

Output related requirements: - The system takes in an input to perform or to process some
function in order to produce an output based on the given input.

Storage related requirements: - The system developed by using MySQL database server which
used to store all the student’s information like cleared students and the current available students’
information to be cleared.

24 | P a g e
2.4.2. Non-functional requirements

While accomplishing a basic functional requirement there is a non-functional requirement which

is successfully accomplished.

Performance: -

The system is very fast since it is automated and computerized.

The software shall support use of multiple users at a time.
It works very well with short response time, high throughput and high availability.
Reduce costs and time waste by providing access to system in available place and time
where Internet connection is available

User Interface: - The developed system provides web application user interfaces that are
compatible browsers like Internet Explorer, Mozilla Firefox, Google chrome, etc.

Security and Access Permissions: - The system provides or contains user name and
password for each user based on their privilege. This performs the following activity: -

Authenticated user with predefined access right will only enter to the information related
to database.
Every user should use strong passwords especially admin.
User must enter valid user name and password to login to system. Without this, access to
the system is denied.
Data is encrypted for security.
System allows only registered users to access clearance system and also allows the users
to view their own profile not the other users’ profile.

Usability: -The system shall be very easy to learn, needs a basic computer knowledge to use
and have a help menu to guide the user.

Availability: - There is no delay in the availability of any information, whatever needed, can be
captured very quickly and easily. The server should be always on to be available.

25 | P a g e
2.5. SRS

2.5.1. System Business Rule

Can only access authorized user.

Unauthorized user cannot access the system for the reason of system security.
Users must be registered to access the system to be authorized user by filling the
necessary information in the registration form.
Users must have username and password to login to the system.
Users id must be valid or correct otherwise it doesn’t work.

2.6. Essential Use case

2.6.1. Actor Identification and Description.

Actors Description

The actors that interact with the system are the Proctors; Registrar, student service, sport science,
bookstore, library, and students are users of the system. They are described here in brief: -

Name: Proctor

Description: A Proctor is a person who is responsible for Approve, Update, delete, and search the
student’s information.

Name: Bookstore

Description: A Bookstore is a person who is responsible for Approve, Update, delete, and search
the student’s information.

Name: Sport science

Description: A Sport science is a person who is responsible for Approve, Update, delete, and
search the student’s information.

Name: Library

Description: A Library is a person who is responsible for Approve, Update, delete, and searchthe
student’s information.

26 | P a g e
Name: Student service

Description: A Student service is a person who is responsible for Approve, Update, delete, and
search the student’s information.

Name: Registrar Admin

Description: Registrar Admin is a person who is responsible for Approve and Generate Report.

Name: Student

Description: Student is people who is responsible for Update profile, Request, and view their
own information.

Key terms of Offices refer to

Proctor
Student service
Bookstore
Library
Sport science
From the above use case diagram.

2.6.2 Essential Use case Diagram Identification

Actors Description

The actors that interact with the system are the Proctors; Registrar, student service, sport science,
bookstore, library, and students are users of the system. They are described here in brief: -

Name: Proctor

Description: A Proctor is a person who is responsible for Approve, Update, delete, and search the
student’s information.

Name: Bookstore

27 | P a g e
Description: A Bookstore is a person who is responsible for Approve, Update, delete, and search
the student’s information.

Name: Sport science

Description: A Sport science is a person who is responsible for Approve, Update, delete, and
search the student’s information.

Name: Library

Description: A Library is a person who is responsible for Approve, Update, delete, and search
the student’s information.

Name: Student service

Description: A Student service is a person who is responsible for Approve, Update, delete, and
search the student’s information.

Name: Registrar Admin

Description: Registrar Admin is a person who is responsible for Approve and Generate Report.

Name: Student

Description: Student is a person who is responsible for Update profile, Request, and views their
own information.

Key terms of Offices refer to

Proctor
Student service
Bookstore
Library
Sport science

28 | P a g e
2.6.3 Essential Use case Diagram

Fig 2.5Essential Use case

29 | P a g e
2.6 .4. Essential User Interface Prototyping

The Proposed system has several user interfaces to communicate easily with the User. Our team
attempt to illustrate this interface in general as follows: -

The system user interface should be consistent with all other program.
The caption and the test of user interface should be self-descriptive and clear to
understand.
The user interface should be easy to understand.
The user interface should be customized.

Figure 2.6 Essential User interface prototyping

30 | P a g e
2.7. Analysis Model
2.7.1. Use Case Actor Identification and Description
The actors that interact with the system are the Proctors; Registrar, student service, sport science,
bookstore, library, and students are users of the system. They are described here in brief: -

Name: Proctor

Description: A Proctor is a person who is responsible for Approve, Update, delete, and search the
student’s information.

Name: Bookstore

Description: A Bookstore is a person who is responsible for Approve, Update, delete, and search
the student’s information.

Name: Sport science

Description: A Sport science is a person who is responsible for Approve, Update, delete, and
search the student’s information.

Name: Library

Description: A Library is a person who is responsible for Approve, Update, delete, and search
the student’s information.

Name: Student service

Description: A Student service is a person who is responsible for Approve, Update, delete, and
search the student’s information.

Name: Registrar Admin

Description: Registrar Admin is a person who is responsible for Approve and Generate Report.

Name: Student

31 | P a g e
Description: Student is people who is responsible for Update profile, Request, and view their
own information.

Key terms of Offices refer to

Proctor
Student service
Bookstore
Library
Sport science

2.7.2. Use case diagram

2.7.3 Use case descriptions

32 | P a g e
 1. Use case description for Create Account.

Use case name Create Account

Actor(s) Admin, Offices
Pre-condition The student must be registered legally to the Campus.
UCID-01

Post-condition The Student will receive confirmation from the system.

Description When the Actors enter user name and password, it stores the
input information in to the database.
Typical course of action: Actor Action System Response
Step1: This use case is initiated Step2: The system displays
when the actors click on the create the create account page.
account option
Step4: The systems check
Step3: The actor enters the the information is correct or
required information. not.
Alternative course of Step5: If the actor does not fill the required information then the
action: system displays error message and return to step 2.

Table2.1 Use case description for Create Account.

2. Use case description for login.

Use case Login

name
Actor Student
Pre- The user should have user name and password
condition
UCID-02

Post- The Student will access the system

condition
Description When the students enter id and password, it checks the inputs from the
database. If it is valid, it allows the user to access and if not, it displays
authorization message.
Typical Actor Action System Response

33 | P a g e
 course of Step1: This use case is initiated Step2: The system displays log in
action: when the actors click on the login form
option
Step4: The systems check
Step3: The actor enters the id and authenticated. If she/he is authorized
password system displays the main page if not
Alternative Step5: If the actor does not fill the id and password then the system displays
course of error message and return to step 2.
action:

Table 2.2 Use case description for Login

34 | P a g e
 3. Use case description for Registration.
Use case name Registration

Actors Students

Pre-condition The Actors should be registered to the university.

Post-condition The user can have User account and can login to the system

Description This use case allows users to register in to the system

Typical course of action: Actor Action System Response

Step1: -The user wants Step2: -The system displays registration
to register in to the page
UCID-03

system. Step4: -The system validates whether the

information submitted is correct or not.
Step3: -The user enters
Step5: -The system registers and displays
the necessary information
registration confirmation page and leads to
in to the form in
home page.
registration page.
Step6: The use case ends
Alternative course of Step5: If the actor does not fill the id and password then the system
action: displays error message and return to step 2.

Alternative course of If the input information invalid or empty

action Step4.1: The system indicates the user information invalid.
Step4.2: The use case continues Step2 of the basic course of action.

Table 2.3 Use case description for Registration.

4. Use case description for Delete.
Use case name Delete
Actor(s) Administrator, Offices
Pre-condition The Actors must login to the system
UCID-04

Post-condition The administrator and offices delete the record from the database.
Description Clearing Students information from database that has finished the
clearance process.

Typical course of action: Actor Action System Response

35 | P a g e
 Step1: Actor clicks Step2: The system displays the delete
delete option. Step3: form page.
The actors enter the id Step4: The system verifies whether the
for delete data from existence of the data base.
the data base.
Step5: The system displays confirmation
message.
Alternative course of If the input information invalid or empty
action Step4.1: The system indicates the user information invalid.
Step4.2: The use case continues Step2 of the basic course of
action.
Table 2.4 Use case description for Delete.
5. Use case description for Update.
Use case name Update profile
Actor(s) Students Admin, and Offices
Pre-condition The Actors must login to the system.
Post-condition The Actors will have updated their profile.
Description This use case allows users to update the user account.
Typical course of action: Actor Action System Response
Step1: The actors can Step2: The system displays user
UCID-05

request to update his/her account update page.

information. The system will Step4: The system validates
display the current customer information is correct or not.
information to the users. Step5: The system displays
Step3: The user enters the confirmation page and save the
necessary information to update information of user.
update.

Alternative course of If the input information invalid or empty

action Step4.1: The system indicates the Actors information invalid.
Step4.2: The use case continues Step2 of the basic course of
action.
Table 2.5 Use case description for Update.
6. Use case description for View Profile
Use case name View Profile
UCID-

Actor(s) Students

36 | P a g e
 06 Pre-condition The Actors not seen profile.
Post-condition The Actors has been viewed his/her profile.
Description This use case allows users request to view his/her profile.
Typical course of action: Actor Action System Response
Step2: The system displays view
Step1: The actors option page.
wants to View his/her Step4: The system process selection.
profile.
Step3: The actor selects Step5: The system displays the actor
the view profile option. profile.
Step6: The use case ends.

Alternative course of If the input information invalid or empty

action Step4.1: The system indicates the user information invalid.
Step4.2: The use case continues Step2.
Table 2.6 Use case description for view profile
7. Use case description for Search.
Use case name Search
Actor(s) Administrator, and Offices
Pre-condition The actors cannot search.
Post-condition The Actors has been searched the selected record.
Description This actors’ requests to search someone’s information.
Typical course of action: Actor Action System Response
UCID-07

Step2: The system displays user view

Step1: The actors want option.
to search some record. Step4: The system processes the
Step3: The user enters selection.
the information to Step5: The system displays the
search from database selected record.
option. Step6: The use case ends.
Alternative course of If the input information invalid or empty
action Step4.1: The system indicates the user information invalid.
Step4.2: The use case continues Step2 of the basic course of
action.
Table 2.7 Use case description for Search

37 | P a g e
 8. Use case description for Approve.
Use case name Approve
UCID-08

Actor(s) Offices and Admin

Pre-condition The actors cannot Approve.
Post-condition The actors should be approved the information.
Description The actor to be approve if they get request some information
from different corners.
Typical course of Actor Action System Response
action:
Step2: The system displays the approve
Step1: The actor option.
wants to submit.
Step3: The user Step4: The system processes the selections.
selects the approve Step5: The system displays confirmation
option. message to the user.
Step6: The use case ends.

Alternative course of If the input information invalid or empty

action Step4.1: The system indicates the user information invalid.
Step4.2: The use case continues Step2 of the basic course of action.
Table 2.8 Use case description for Approve
9. Use case description for Generate_Report.
Use case name Generate Report
Actor(s) Admin
Pre-condition The actor cannot be Generate Report.
UCID-09

Post-condition The Actors should be generating the report.

Description The actor wants to report how many students are clear from the
university.
Typical course of Actor Action System Response

38 | P a g e
 action: Step1: The actor Step2: The system displays the generate
wants to generate report option.
report. Step4: The system processes the
selections.
Step3: The user
selects the generate Step5: The system displays the all
report option. information’s of the students.
Alternative course of If the input information invalid or empty
action Step4.1: The system indicates the user information invalid.
Step4.2: The use case continues Step2 of the basic course of action.
Table 2.9 Use case description for Generate Report.
10. Use case description for Request.
Use case name Request
Actor(s) Student
Pre-condition The actor should request for the form.
Post-condition The student sends request.
Description The Students send a request to the concerned body

Typical course of Actor Action System Response

UCID-10

action:
Step1: The actor Step2: The system displays the request option.
wants to request. Step4: The system processes the selections
action.
Step3: The user
selects the Step5: The system send information’s to the
request option. other page.

Alternative course of If the input information invalid or empty

action Step4.1: The system indicates the user information invalid.
Step4.2 The use case continues Step2 of the basic course of action.

Table 2.10 Use case description for Request.

2.7.4. Sequence Diagram

Sequence diagrams show the interaction between participating objects in a given use case. They
are helpful to identify the missing objects that are not identified in the analysis object model. A
sequence diagram links use case with objects. It shows the interaction between participating
objects in a given use case. It is helpful to identify the missing objects that are not identified in

39 | P a g e
the analysis object model. From the use case and the class diagrams shown in the previous
section the sequence diagrams of the system are shown as follows:

1). Sequence Diagram for Create Account by Admin and Offices

Figure 2.8 Sequence diagram for Create Account by Admin and Offices

2). Sequence diagram for Registration.

40 | P a g e
Figure 2.9 Sequence diagram for registration

3). Sequence diagram for Admin Login.

Figure 2.10 Sequence diagram for login

41 | P a g e
 4). Sequence diagram for Update.

Figure 2.11 Sequence diagram for Update

5). Sequence diagram for View.

42 | P a g e
Figure 2.12Sequence diagram for View

6). Sequence diagram for Delete.

Figure 2.13. Sequence diagram for Delete

7). Sequence diagram for Approve.

43 | P a g e
Figure 2.14 Sequence diagram for Approve

8). Sequence diagram for Generate Report.

Figure 2.15Sequence diagram for Generate Report

9). Sequence diagram for Request.

44 | P a g e
Figure 2.16 Sequence diagram for Request.

2.7.5 Activity Diagram

Activity diagram used to emphasize the flow of control from activity to activity or to model the
flow of an object as it moves from state at different points in the flow of control.

1. Activity Diagram for Create Account.

45 | P a g e
Figure 2.17 Activity diagram for Student

2 Activity Diagram for Create Account

Figure 2.18 Activity diagram for Create Account for Office,admin

3 Activity Diagram for Login.

46 | P a g e
 Figure 2.19 Activity diagram for Login

4 Activity Diagram for Delete

Is the info
Correct?

Figure 2.20 Activity diagram for Delete

47 | P a g e
 5 Activity Diagram for Search

Is the info
Correct?

Figure 2.21 Activity diagram for Search

6 Activity Diagram for Approve

48 | P a g e
 Is the info
Correct?

Figure 2.22 Activity diagram for Approve

7. Activity Diagram for generate report

Figure 2.23 Activity diagram for Generate Report

8. Activity Diagram for Request.

49 | P a g e
 Is the info
Correct?

Figure 2.24 Activity diagram for Request.

2.7.6. Collaboration Diagram

A collaboration diagram describes interactions among objects of our system in terms of
sequenced messages. Collaboration diagrams represent a combination of information
taken from class, sequence, and use case diagrams describing both the static structure
and dynamic behaviour of a system.
2.7.6.1 Collaboration Diagram for Log in

50 | P a g e
 Figure 2.25: Collaboration Diagram for Log in
2.7.6.2 Collaboration Diagram for Register in

Figure 2.26: Collaboration Diagram for Register

2.7.6.3 Collaboration Diagram for View in

Figure 2.27: Collaboration Diagram for View Profile

51 | P a g e
2.7.7. Conceptual Class Diagram

In any System development a conceptual class diagram can represent the properties of entities,
their operations, and relationships. Also, it drives use case diagrams from the use case.

The class diagram is the main building block in our project modelling.
It is used both for general conceptual modelling of the systematic of the application and for
detailed modelling translating the models into programming code.
The classes in a class diagram represent both the main objects and or interactions in the
application and the objects to be programmed.
Generally the project is including the following class in the class diagram the over view of
the class diagram is: -

52 | P a g e
 Figure 2.28 Conceptual class diagrams

53 | P a g e
2.8 State chart

A state chart diagram shows the behavior of classes in response to external stimuli. This diagram
models the dynamic flow of control from state to state within a system.

Figure 2.29: State chart modelling

Figure 2.30 State chart Diagram of Actors login

54 | P a g e
 Chapter Three: System Design

3.1. Purpose and design goals

System design is the transformation of the analysis model into a system design model. System
design is the first part to get into the solution domain in a software development. This chapter
focuses on transforming the analysis model into the design model that considers the non-
functional requirements and constraints described in the problem statement and requirement
analysis sections discussed earlier.

3.2. Design Goals

Design goals describe the qualities of the system that the developers should consider. These
goals can be drawn from the non-functional requirements already discussed. The design goals
can be generally grouped into five categories. These are: Performance Criteria, Dependability
Criteria, Cost Criteria, Maintenance Criteria, and End User Criteria.

Performance: -The system should respond fast with high throughput, i.e. It should perform
searching information, post news, and, registration processing and generating report in a time
less than a minute.

Dependability: -The office needs the system to be highly dependable. The system should be
robust (forceful) i.e. it should be able to carry on invalid user inputs, fault tolerant, reliable and
available. The system shouldn’t allow non-authorized users to access students’ personal data or
modify.

Cost: The system should be developed, deployed, administered and maintained with minimum
cost possible.

Maintenance: The code for the system should be easily readable, understandable, and should be
easily mapped to specific requirements. Means it is platform.

End User Criteria: The system should have simple and understandable graphical user interface
such as forms and buttons which have descriptive names. It should give reliable response for
each user request at least before the session expires.

55 | P a g e
Usability: Usability is the extent to which a product can be used by specified users to achieve
specified goals with effectiveness, efficiency and satisfaction in a specified context of use.

3.3. Site Map

The Proposed system has several user interfaces to communicate easily with the User. Our team
attempt to illustrate this interface in general as follows: -

The system user interface should be consistent with all other program.
The caption and the test of user interface should be self-descriptive and clear to
understand.
The user interface should be easy to understand.
The user interface should be customized.

56 | P a g e
 Figure 3.1Site Map

3.4. System decomposition

Figure 3.2Subsystem decomposition diagram

3.5. Layer Class Diagram

3.5.1. User Interface Layer: - This layer provides the user to access the system. There are two
categories of interface class-user interface (UI) classes that provide people access to external
system to tour system.

3.5.2. Domain Layer: - This Layer implements the concepts relevant to your business domain
such as student focusing on the data aspects of the business objects, plus behaviours specific to
individual objects.

57 | P a g e
 3.5.3. Process Layer: - This process layer implements business logic that involves collaborating
with several domain classes or even other process classes.

3.5.4 Persistence Layer: - This layer encapsulates the capability to store, retrieve, and delete
objects without revealing details of the underlying storage technology.

3.5.5 System Layer: - System classes provide operating system specific functionality for your
application, isolating your software from the operating system (OS) by wrapping OS specific
feature, increasing the portability of your application.
AUWC Web-based clearance Diagram

User interfaces Layer

Process Layer

System
(infrastr
Domain Layer/Business ucture
plat
forms)

Persistence Layer

AUWC SCMS Database

Figure 3.3Class type architecture

58 | P a g e
3.6. Component Modelling

In this Diagram components of the system will be wired showing that there is relation among
components, management of the system, database and operations performed on databases such
security issue. This in some extent shows which component or objects will be accessed by whom
and what type of security infrastructures it is using. The diagram is simulated below:

Figure 3.4 Component modelling diagram

3.7. Deployment modelling

UML deployment diagram show physical view of system, taking software into real world by
showing how software gets assigned to hardware and how communicates. The deployment
diagram shows how the software components, processes, and objects are deployed into the
physical architecture of the system. It shows the configuration of the hardware units (e.g.
Computers, communication devices, etc.) and how the software components are distributed
across the units.

AUWC Web-based clearance System is server client structure architecture, where clients
access services offered by server. The deployment diagram is shown as follows.

59 | P a g e
Figure 3.5 deployment modelling diagram
Description of the architecture of the system is described as follows.

Clients are responsible for: -

Provide user interface to the user enabling to get services

Receiving inputs from user
Checking range of performance
Initiating database transactions once all necessary data are collected.
Server responsible for: -
Transaction performance
Guaranteeing the integrity of data.
Putting backup of the database

60 | P a g e
 3.8. Class Diagram Modelling

This design level introduces changes to analysis class model based on implementation
technologies. It focuses on the solution domain instead of the problem domain.

The class diagram is the main building block in our project modeling.
It is used both for general conceptual modeling of the systematic of the application and
for detailed modeling translating the models into programming code.

Classes are represented by rectangles with three sections.

These are: -

The top section is the name of the class.

The middle section contains the attributes which store information about an item

The bottom section contains the methods/operation that show what are done on object or
class.

The class Diagram below shows the class of our system, their inter relationship (including
inheritance and association) and the operations and attributes of each classes

61 | P a g e
Figure 3.6 Class modelling

62 | P a g e
3.8. 1Inheritance Class Diagram

While developing a AUWC web-based student clearance system an Inheritance class diagram is
class diagram that is inherited from design class diagram that have common properties with each
other. It is used to show the relation of two or more classes that have common properties that are
inherited from each other.

Figure 3.7 Inheritance Class modelling

3.9. Persistence modelling

Persistence of our object can be achieved by relational database since it used as machine to make
object persistent. It describes the persistent data aspect of software system. Our system includes
the basic table that handles the data of system implemented using MySQL server.

Mapping class and relational table

Mapping refers how objects and their relationship are stored in relational database. The mapping
of the data to be persisted in our system is given as follows:

63 | P a g e
Figure 3.8 Relational Database modeling for the system

3.10. Access Control and Security

Because of our system being multi-user environment, different actors have access to different
functionality and data. During analysis, we modelled this distinction by associating different use
cases to different actors. During system design, we model access by examining the object model,
by determining which objects are shared among actors, and by defining how actors can control
access. Depending on the security requirements on the system, we also define how actors are
authenticated to the system. The following access control matrix shows which user has access to
which function.

64 | P a g e
 Actors Functionalities that have been done by the developed System
Manage Info Register news Give Comment
service

Manager Has authority to Register Post news View

create, update, delete student comment
account and to given student
generate report,
Offices Has authority to
Coordinators delete, update and add
records and to
generate report.
Student Access home page Has the View news Has Write
authority to be posted by authority to comment
registered manager get service
Table 3.1 Actor Access control and security table

3.11. User interface design

User interface design; - A developed system is an interface which can be used for the
specification of the interaction between the system users and a system. The process involves
accepting an input mechanism design, output mechanism design, and navigation mechanism.

Navigation mechanism is part of user interface that takes the user form one part of the
system to the other user system. That includes menus or links, graphics buttons,
animating marques, icons, dialog boxes etc.
Input design is about designing a form and its controls for GUI system.
Output design is about designing reports like detailed, summarized, exceptional, graph,
chart, text document report and extra.

65 | P a g e
 References
System Analysis and Design for Software Engineers NIIT 2005

[1] Object Oriented Analysis& Design, Understanding System Development with UML 2.0 and
Mike O Docherty 2005 Anigbogu G. (2000). Systematic planning for educational change.
California: Mayfield publishing company.

[2]http://books.google.com.et/books?
id=bLzOaXQJG8oC&printsec=frontcover&dq=software+project+development+references&hl=
en&sa=X&ei=JQjaUJqVGM3GswaO9IGYCg&ved=0CEQQ6AEwAg#v=onepage&q=software
%20project%20development %20references&f=false

66 | P a g e
 Glossary
Activity diagram – A UML diagram which can be used to model a high-level
business process or the transitions between states of a class (in this respect
activity diagrams are effectively specializations of state chart diagrams).
Actor – Any person, organization, or system that interacts with an application
but is external to it.
Architectural modeling: – High-level modeling, either of the problem or
technical domain, whose goal is to provide a common, overall vision of the
problem domain. Architectural models provide a base from which detailed
modeling can begin.
Class diagram -- Class diagrams show the classes of a system and their
interrelationships. Class diagrams are often mistakenly referred to as object
models.
Deployment diagram: - is used to depict the relationship among run-time
components and hardware nodes.
Package diagram: - is UML structure diagram which shows packages and
dependencies between the packages.
Sequence diagram: – A diagram that shows the types of objects involved in a
use-case scenario, including the messages they send to one another and the
values that they return.

67 | P a g e
 Appendix for unified modeling language
APPENDIX I
o Description of symbols
Symbol Description
Actor

System boundary

Decision

Use case

Class

Component diagram

Destroy

Object life line

Deployment diagram

Note

Message line extends from the lifeline of one object to the

lifeline.
Return message extend from the lifeline of one object to the
lifeline

Starting point of activity/state diagram

68 | P a g e
 Ending point of activity/state diagram

MVC Model view controller

Xampp server

BR Business rule

Interface

Note

Time Activation

Self-delegation

Message call

Message return

Horizontal synchronization

Multiplicity many(zero)

Package

Mandatory
Object
Association role
Transition

69 | P a g e