Wollo University Kombolcha Institute of Technology College of Informatics Department of Information System

WOLLO UNIVERSITY
KOMBOLCHA INSTITUTE OF TECHNOLOGY

COLLEGE OF INFORMATICS
DEPARTMENT OF INFORMATION SYSTEM
Final Year project

TITLE: - WEB BASED TRAFFIC INFORMATION MANAGEMENT SYSTEM
FOR KOMBOLCHA CITY TRAFFIC OFFICE
PREPARED BY:
NAME ID No.
1. Mekonnen Melkamu 0718/11
2. Birtukan Biset 0595/11
3. Assabnesh Mekuriaw 4486/11
Name of Advisors: Moges Tesfa Wollo University

Kombolcha, Ethiopia
17/09/2022
Web Based Traffic Information Management System 2022
Approval Sheet
A project proposal submitted to College of Informatics, Department of Information system. For the
partial fulfillment of the requirements for Bachelor Degree of Science in Information System.
Department head sign
Mr. Kedir Abdu _________
This is to certify that the senior project titled “Web Based Traffic Information Management system”
is
PREPARED BY:
Name ID No Sign
1. Mekonnen Melkamu WOUR/0718/11 _______
2. Birtukan Biset WOUR/0595/11 ________
3. Assabnesh Mekuriaw WOUR/4486/11 _______
To the Department of Information System in Wollo University for the partial fulfillment of the
requirement of the Degree of Bachelor Science in Information System. The contents of this document
in full, or in parts, have not been submitted to any other institute or university for the award of any
degree or diploma.
Advisor Examiner
Moges T. Name: ______________ Signature: _____
Signature: _______ Name: _______________Signature: _____
Date: - 17/09/2022 Date: __________

Acknowledgment
First and for most and above all our biggest thanks would be to Almighty “GOD” because nothing could
be possible without his free will and the future completion of this project is supported by him.
Secondly, we would like to express our special thanks to our Department Head Mr. Kedir Abdu for their
helpful guidance and Leadership attitude into the right direction. And our advisors, Mr. Moges Tesfa,
for their helpful guidance, ongoing support and invaluable contributions until the completion of our
project work.
Thirdly, we would like to forward our gratitude to Kombolcha City Traffic Office personnel Main Sajin
Tigist Eshetu and Commander Genet Aragaw, who helped us by providing useful information and
by giving useful documents and materials that are useful for our project task.
At the last but not the least, even if it were unusual, our group members would like to thank each other
for ours working and motivation until this time and for the next team sprit attitudes for the successful
accomplishment of our project. The main contributors to the success of this 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 successfully accomplished by us and through the will of ‘’GOD’’.
Table of Contents
Approval Sheet.......................................................................................................................................... i
Acknowledgment ..................................................................................................................................... ii
List of Figures ......................................................................................................................................... iv
List of Tables ........................................................................................................................................... v
ABSTRACT............................................................................................................................................ vi
List of Acronyms ................................................................................................................................... vii
CHAPTER ONE: INTRODUCTION ...................................................................................................... 8
1.1 Background of the Organization .................................................................................................... 8
1.2 Background of the Project ............................................................................................................. 9
1.3 Motivation ...................................................................................................................................... 9
1.4 Statement of the Problem ............................................................................................................... 9
1.5 Objectives .................................................................................................................................... 10
1.5.1 General Objective .................................................................................................................. 10
1.5.2 Specific Objectives ................................................................................................................ 10
1.6 Methodology and Tools ............................................................................................................... 10
1.6.1 Methodology ............................................................................................................................. 10
1.6.2 Tools ...................................................................................................................................... 11
1.7 Scope and limitation .................................................................................................................... 13
1.7.1 Scope ......................................................................................................................................... 13
1.7.2 Limitation .............................................................................................................................. 14
1.8 Significance of the Project ........................................................................................................... 14
1.8.1 Benefits for the Organization ................................................................................................ 14
1.8.2 Benefits for Societies ........................................................................................................... 14
1.9 Feasibility Analysis ...................................................................................................................... 14
1.9.1 Operational Feasibility .......................................................................................................... 15
1.9.2 Economic Feasibility ............................................................................................................. 15
1.9.3 Technical Feasibility.............................................................................................................. 15
1.9.4 Schedule Feasibility ............................................................................................................... 16
1.9.5 Political Feasibility ................................................................................................................ 16
1.10 Risk Analysis ............................................................................................................................. 16
1.11 Task Breakdown and Stages ...................................................................................................... 16
1.12 Work Plan (Gantt chart) ............................................................................................................. 17
iii
1.13 Cost Analaysis ........................................................................................................................... 18

1.13.1 Hardware Requirements costs................................................................................................. 18
1.13.2 Software Requirements Cost ............................................................................................... 18
1.14 Organization of the Project ........................................................................................................ 19
CHAPTER TWO ................................................................................................................................... 20
Description of the Existing System and Requirements Gathering ......................................................... 20
2.1 Introduction of Existing System ................................................................................................... 20
2.2 Players (actors) in the Existing System........................................................................................ 20
2.3 Major Functions/activities in the Existing System....................................................................... 20
2.4 Business Rules ............................................................................................................................. 21
2.5 Bottlenecks of the Existing System ............................................................................................. 21
2.5.1 Performance Problem ............................................................................................................ 21
2.5.2 Information Problem.............................................................................................................. 21
2.5.3 Data Storage Problem ............................................................................................................ 21
2.5.4 Efficiency Problem and Security ........................................................................................... 22
2.5.5 Control Problem .................................................................................................................... 22
2.6 Risk and Constraints .................................................................................................................... 22
2.7 Proposed Solution for the New System ....................................................................................... 22
2.8 Requirements of the Proposed System......................................................................................... 22
2.8.1 Functional Requirements ....................................................................................................... 23
2.8.2 Non-functional Requirements ................................................................................................ 23
2.9 Modeling the Existing System ..................................................................................................... 24
2.9.1 Essential Use Case Diagram .................................................................................................. 24
2.9.2 Essential User Interface Prototyping ..................................................................................... 25
CHAPTER THREE ............................................................................................................................... 26
System Analysis of the Proposed System .............................................................................................. 26
3.1 Introduction .................................................................................................................................. 26
3.2 System Requirement Specifications (SRS) .................................................................................. 26
3.2.1 Actor Identification................................................................................................................ 26
3.2.2 Use Case Identification .......................................................................................................... 27
3.3 Modeling the Proposed System ................................................................................................... 27
3.3.1 System Use case Diagrams .................................................................................................... 27
3.3.2 Use Case Documentation....................................................................................................... 29
3.3.3 Domain Modeling with Class Responsibility Collaborator (CRC) ....................................... 44
iv
3.3.4 Sequence Diagrams ............................................................................................................... 46

3.3.5 Activity Diagrams.................................................................................................................. 51
3.3.6 Analysis Level Class Diagram (Conceptual Modeling) ........................................................ 58
3.3.7 User Interface Prototyping..................................................................................................... 59
3.3.8 User Interface Flow Diagraming ........................................................................................... 60
3.4 Identifying Change Cases ............................................................................................................ 61
Chapter Four: System Design ................................................................................................................ 62
4.1 Introduction .................................................................................................................................. 62
4.2 Purpose and goals of design ......................................................................................................... 62
4.3 Class modeling ............................................................................................................................. 63
4.4 State chart modelling ................................................................................................................... 64
4.5 Collaboration Modeling ............................................................................................................... 66
4.6 Current software architecture ....................................................................................................... 68
4.7 Proposed software architecture .................................................................................................... 68
4.8 Subsystem Decomposition ........................................................................................................... 69
4.9 Component Diagram .................................................................................................................... 70
4.10 Deployment Diagram ................................................................................................................. 71
4.11 Persistence Modeling ................................................................................................................. 72
4.12 Access Control and Security ...................................................................................................... 72
4.13 Boundary conditions and Exception Handling .......................................................................... 73
4.13.1 Boundary conditions ............................................................................................................ 73
4.13.2 Exception Handling ............................................................................................................. 74
4.14 User Interface Design ................................................................................................................ 74
Chapter Five: Implementation and Testing ............................................................................................ 76
5.1 Introduction .................................................................................................................................. 76
5. 2 Final Testing of the System ........................................................................................................ 76
5.3 Testing procedures ....................................................................................................................... 76
5.3.1 Unit testing .......................................................................................................................... 77
5.3.2 Integration Testing .............................................................................................................. 77
5.3.3 Performance Testing .............................................................................................................. 77
5.3.4 System Testing ...................................................................................................................... 77
Chapter Six: Conclusions and Recommendation ................................................................................... 82
6.1 Conclusions .................................................................................................................................. 82
6.2 Recommendation ......................................................................................................................... 82
v
APPENDIX ............................................................................................................................................ 83
References .............................................................................................................................................. 84
vi
List of Figures
Figure 1: Essential use case diagram ..................................................................................................... 24

Figure 2: Essential user interface prototype for punishing drivers ........................................................ 25
Figure 3: System use case diagram ........................................................................................................ 28
Figure 4: Sequence diagram for login .................................................................................................... 47
Figure 5: Sequence diagram for create Account .................................................................................... 48
Figure 6: Sequence diagram for activate Account ................................................................................. 48
Figure 7: Sequence diagram for Deactivate Account ............................................................................ 49
Figure 8: Sequence diagram for change Password ................................................................................ 50
Figure 9: Sequence diagram for Add penalty ........................................................................................ 50
Figure 10: Sequence diagram for Add Appointment ............................................................................. 51
Figure 11: Activity diagram for login .................................................................................................... 52
Figure 12: Activity diagram for create Account .................................................................................... 53
Figure 13: Activity diagram for Activate or Deactivate Account.......................................................... 54
Figure 14: Activity diagram for change Password ................................................................................ 55
Figure 15: Activity diagram for Add penalty ........................................................................................ 56
Figure 16: Activity diagram for Add Appointment ............................................................................... 57
Figure 17: Activity diagram for Logout................................................................................................. 58
Figure 18: Analysis level class diagram ................................................................................................ 59
Figure 19: User interface Prototyping Diagram for Login .................................................................... 60
Figure 20: User Interface Flow Diagram of the Proposed System ........................................................ 61
Figure 21:Classes modeling for the proposed system............................................................................ 63
Figure 22:State chart diagram for login ................................................................................................. 64
Figure 23:State chart diagram for create Account ................................................................................. 65
Figure 24:State chart diagram for Add penalty record .......................................................................... 65
Figure 25:Collaboration diagram for login ............................................................................................ 66
Figure 26:Collaboration diagram for create Account ............................................................................ 67
Figure 27:Collaboration diagram for Add penalty record ..................................................................... 67
Figure 28:Proposed software architecture ............................................................................................. 68
Figure 29:Subsystem decomposition ..................................................................................................... 69
Figure 30:Component diagram .............................................................................................................. 70
Figure 31:Deployment diagram ............................................................................................................. 71
Figure 32:Persistent diagram ................................................................................................................. 72
Figure 33:Login user interface ............................................................................................................... 74
Figure 34:Traffic Police page ................................................................................................................ 75
Figure 35:Notice post User interface ..................................................................................................... 75
iv
List of Tables
Table 1: Schedule for the project ........................................................................................................... 17

Table 2: hardware requirements cost ..................................................................................................... 18
Table 3: software requirements cost ...................................................................................................... 18
Table 4: Use case identification ............................................................................................................. 27
Table 5: Login Use case Documentation ............................................................................................... 29
Table 6: Create account Use case Documentation ................................................................................. 30
Table 7: Activate Account Use Case Documentation............................................................................ 31
Table 8: Deactivate Account Use Case Documentation ........................................................................ 32
Table 9: View Own Profile Use Case Documentation .......................................................................... 33
Table 10: Change Password Use Case Documentation ......................................................................... 34
Table 11: Add Driver License Use Case Documentation ...................................................................... 35
Table 12: Add Vehicle Use Case Documentation ................................................................................. 36
Table 13: Pay penalty bill Use case Documentation ............................................................................. 37
Table 14: Add Appointment Use Case Documentation ......................................................................... 38
Table 15: View Driver Information Use Case Documentation ............................................................. 39
Table 16: Update vehicle and Penalty Information Use Case Documentation ...................................... 40
Table 17: View Vehicle information Use case Documentation............................................................. 41
Table 18: Add Penalty Record Use Case Documentation ..................................................................... 42
Table 19: Logout Use case Documentation ........................................................................................... 43
Table 20: CRC diagram for Administrator ............................................................................................ 44
Table 21: CRC diagram for Traffic police ............................................................................................. 45
Table 22: CRC diagram for Driver ........................................................................................................ 45
Table 23: CRC diagram for Employee .................................................................................................. 46
Table 24:Access security table............................................................................................................... 73
Table 25:User Login Authentication ..................................................................................................... 78
v
ABSTRACT
This project is intended to develop a web-based application system for Kombolcha city traffic
information management system and to provide simple and effective way of managing traffic cases.
Ethiopian Transport Authority has been performing complex and risky task with greater responsibility,
from these responsibilities recording Drivers full information and traffic flow control are the major
tasks that the office undertakes, which needs efficiency and accuracy. To process this task in efficient
way, the office should take the full information. The project “Traffic Information Management” has
been selected which is aimed for helping the Kombolcha Town Transport authority and Traffics police
department. Our system will have centralized database and each traffic policemen will have user
account that enables them to view and record criminal driver’s status like penalty. Authorized
Administrators and Employee in the office will manage the system on their computer browser. They will
have privilege to login to the system and they can register and view Driver’s information and records.
vi
List of Acronyms
CSS: Cascaded Style Sheet
KCTIMS: Kombolcha City Traffic Information Management System
HTML5: Hyper Text Markup Language version five
PHP: Hypertext Preprocessing
RTA: Road Transport Authority
UML: Unified Modeling Language
ID: Identification Number
CRC: Class Responsibility Collaborator
SRS: System Requirements Specification
LAN: Local Area Network
vii
CHAPTER ONE: INTRODUCTION

1.1 Background of the Organization
The Ethiopian Road Transport Authority (R.T.A) is a public transport authority based in Addis Ababa,
Ethiopia with regional branches like Amhara Region Road Transport Authority. It was originally founded
as the Road Transport Administration in 1967 by proclamation No 256/67 but restructured and became
the Road Transport Authority (RTA) in 1976, following proclamation No 107/76 [1]. The RTA states that
its mission is “To Ensure the Provision of a Modern, Integrated and Safe Road Transport Services
to Meet the needs of All the Communities for Strong and Unitary Economic and Political System in
Ethiopia”. In doing so it attempts to promote an efficient road service, to coordinate and strengthen the
road traffic safety and to develop the transport data base system to enhance research for the development
of the sector.
In 2005, the Ethiopian Government reorganized the transport sector and although the previously
independent Urban Transport Authority, the Railway Regulatory Authority, the Aviation Authority, the
Airport Administration Authority and the Maritime Regulatory Authority merged into the Ethiopian
Transport Authority, the Road Transport Authority remained independent.
The Kombolcha City Road Transport is branch of RTA which is responsible to Amhara Region Road
Transport office. But until 2005E.c it is responsible to South Wollo Zone, Dessie Road Transport
Authority.
After 2005 E.c Kombolcha Road Transport Authority is organized as an independent office and gained
the name Trade and Transport Authority [2].
Existing System in Kombolcha City Road Transport Authority is manual record system. It has around
30,000 records of drivers including their name, number, category, age, ID and any information regarding
their status like they have punished or not by traffic police. The punishment record has the following
information: - name, driver license no, time the event has arrived, place, kind, level, plate number.
The aim of Kombolcha City Road Transport Office is to give Driver’s license for candidate Drivers who
have finished training course from legal Drivers Training Centers. And after that every Driver must
renewed their license in every four years.
8
1.2 Background of the Project

The project that is going to be developed about is Web Based Traffic Information Management System
for Kombolcha City Traffic Office. The main purpose of the project is to develop and maintain Web Based
Traffic Information management system and to provide efficient and effective services for users. The
system used to manage the trafficking process starting from adding, updating, deleting user and Vehicle
information’s and distributing relevant information’s to users. So, by using the proposed system,
beneficiaries of this project can easily access information about the general working of the office. There
is a plan to develop the traffic information management system for the Kombolcha City traffic office to
produce better and efficient data handling management system.
Our project will bring measurable benefits for Kombolcha City traffic office and also for legitimate users.
This documentation will describe what the project is, how it performs or how it is implemented, the
problem of the current system, benefits of the proposed system, scope of the project, the targeted outcome
of the project, and objectives of the project as described below. The proposed project will be performed
after analyzing the current system, and it will give broad benefits to the traffic office and also for users.
1.3 Motivation
The Traffic Information management activity in Kombolcha City is performed in a manual document way
or the handling of data, dataflow system, the renewal of license cards, and penalty payment activities are
performed in a manual way.
As we visited the work place of Kombolcha City Traffic Information Management office; how the
organizations management activities took placed, we have seen some problems in their data processing
and handling activates. There were many difficulties of manual processing of files/data. So, the intention
of our team members for doing this project is to change the manual system into a technology dependent
system that facilitates and improves traffic information managing activities.
1.4 Statement of the Problem

In the current system storing, processing, handling, and searching of specific information in the traffic
office is done manually. After each driver is punished it is difficult to search that data after several months
or years. When a traffic police need it to know the vehicle information and personal information of the
driver, he/she follows a manual approach which is not efficient and effective. When the drivers need it to
know their personal information, want to renew their license cards and to pay penalty payments it is
difficult.
9
In addition to this the current system has also other limitations; it is time consuming to record files, there
is wastage of material, duplication of papers, no efficient system for the removal of inactive or irrelevant
files or documents, difficulty to integrate data, data redundancy and difficulty of locating & finding files.
In the existing system it is also difficult to Generate Daily, Weekly, Monthly and Annual Reports because
it is difficult to process in a paper-based way. It is also difficult to record day to day Accident information.
Also, difficult to send Notices to users.
The need to improve performance and the urgency to solve the above stated problems contribute to
undertake this project into consideration.
1.5 Objectives
1.5.1 General Objective

The general objective of the project is to develop a web-based Traffic Information Management System
for Kombolcha City Traffic Office.
1.5.2 Specific Objectives

In order to achieve the general objective, the following lists of specific objectives are identified:
✓ To make analysis about the current manual system of the Office.

✓ To perform a requirement analysis to find out the proposed system functional and non-
functional requirements.
✓ To Design the proposed new system
✓ To implement the proposed new system
✓ Test the system using different testing methods to be sure the system is implemented with
all the expected system functionalities.
1.6 Methodology and Tools

1.6.1 Methodology
1.6.1.1 Data Collection Methodology
The method which enables us to capture information about requested system is called Methodology.
To get a precise data from the organization the team has used the following fact-finding techniques.
✓ Interview: - An interview is a conversation between two or more people where questions are
asked by the interviewer to draw out facts. And we have made an interview with personnel of
the office to get an overview of the current system and the problem of the existing system.
10
✓ Observation: - Is an act or instance of viewing or noting a fact or occurrence for some special
purpose. During our observation we saw how the office workers perform their activities.
✓ Documentation analysis: - Is written document which is stored in the office that shows the
overview of the existing system. We read written documents which are the existing system
currently uses; to know rules, regulation and constraints in the existing system that can be used
to design the new proposed system.
1.6.1.2 Analysis and Design Methodology
In order to achieve our aim, we use different methods to bring the system from imagination to realization.
Those methods include different models, techniques and tools for our work.
Our team members decide to use object-oriented methodology. Because:
✓ It provides code and function reuse through the concepts of inheritance, polymorphism,
encapsulation, modularity, coupling and cohesion.
✓ To design the system, the object-oriented modeling techniques and the Unified modeling
language tools are crucial and important.
✓ Understanding of the structure is easy because object-oriented modeling and tools used to
represent real world entities.
✓ Modification of the object implementation is easy because objects are loosely coupled [3].
1.6.1.3 The System Development Model

There are various software development life cycle models defined and designed which are followed during
the software development process. These models are also referred as “Software Development Process
Models". Each process model follows a series of steps unique to its type to ensure success in the process
of software development. But our proposed system follows Iterative Model. In this approach, the phases
do not overlap. In "The Iterative” approach, the whole process of software development is divided into
separate phases and, the outcome of one phase acts as the input for the next phase sequentially and back
to the previous phase [4].
1.6.2 Tools
For the proposed system, we will design an interactive web-based application that the authorized users or
workers can easily manage and get information by using the application and interact with the system. For
the purpose of the development of this project, the team members used different software and hardware
tools, which can be identified as hardware requirement and software requirement.
An interactive web application design requires the following things:
11
✓ Web Server software

✓ Server-side scripting language
✓ Database system
✓ Web browser software
For our project we will use the following hardware and software requirements.
1.6.2.1 Scripting language and Software tools

Nowadays many programming languages are used to develop projects. But we selected the PHP scripting
language due to several reasons.
✓ PHP: - To implement the desired functionality of the server-side implementation we choose

this scripting language. Because PHP is a very strong and power full scripting language. It
is crucial to make website more dynamic and interactive. It is widely-used, open-source,
clear and easy to understand, OS independent, fast, easier to fix problems, it is easy to
integrate popular web applications using this scripting language.
✓ Java-script: - To implement image slider, to implement necessary prompts or alerts and to
implement form validation.
✓ MYSQL: - It is a software tool we used for our project. Because it is unique storage engine,
we are familiar with MYSQL, it is free, its performance is improving all the time, it is quick
and powerful, and it handles large databases. So, we select it to manage database system.
✓ HTML5: - To design necessary interfaces or to develop the client sides scripts.
✓ CSS: - Used for styling of websites.
✓ Bootstrap: - To style our system.
1.6.2.2 Software Requirements
✓ Operating System: - Windows10 pro ultimate for client is a minimum version operating
system to use our system.
✓ Xampp Server: -It is our application server that we used. It provides MySQL to create and
manage databases and PHP to design user interface from the front end of software.
✓ Microsoft application: -We use MS-word to write our documentation, MS-PowerPoint to
present this project.
✓ Paint: For editing image and other.
✓ Web Browser: -Is language Interpreter that used to understand client-side application.
✓ Anti-Virus Software: -Used to keep secure, scan, fix Flash Disk and to prevent data
destruction and corruption.
12
✓ Edromax: To design Sequence Diagram, Class Diagram, Activity diagram and Use Case
Diagram and others for our system.
1.6.2.3 Hardware Requirements
This project used the following hardware requirements. The requirements are needed at minimum to
develop the project.
✓ Computer/PC: Used to write proposal, documentation, develop the system. The computer has
the following specifications: -
• Processor-Intel Corei 7 CPU
• RAM-2 GB
• Hard Drive-64GB
• Monitor LCD-Desktop
✓ Flash: Necessary for the movement of relevant data, storage, for backup and recovery
mechanism.
✓ Printer: To print proposal and documentations.
✓ Stationeries (pen, paper): For writing all necessary documentations associated with the project.
✓ Notebook: - To take notes during data collection and for other documentations.
1.7 Scope and limitation
1.7.1 Scope
Scope is an area in which something acts or operates or controls. And it indicates the boundary or size of
the project.
The main users of the projects are traffic polices or Members, Drivers, Employees and Administrators.
The scope of this new system development will include all the information that needed to handle any
problem that may be faced during data processing of the traffic polices and driver records by manually.
The scope of this project is clearly stated below as a result of what the system is expected to perform.
The proposed system covers the following main tasks:
✓ Creating account for users
✓ The system is used to register, update and delete users and vehicles information.
✓ Providing information about users (traffic polices, employees and drivers) and vehicles.
✓ Allowing drivers to perform penalty payments.
✓ Allowing employees and traffic polices to view drivers’ and vehicles information.
✓ Allowing drivers to add appointments for penalty payments.
✓ Providing interfaces for drivers to view their penalty information’s and personal information.
13
✓ The system allows to record day to day Accidents information.

✓ The system is used to Generate Reports in a date interval way.
✓ The system also allowing to post Notice to users and to Send feedbacks.
✓ The system is allowing users to manage their account information except username.
1.7.2 Limitation
The Ethiopian Transport Authority is very wide institution and the activities also wide. So, by
understanding the time and resource requirements to finish the project successfully there is a necessary
limit to its scope. The new system cannot include the following modules:
✓ The scope of our project is only for Kombolcha City Traffic Office
✓ To perform Penalty payments the Drivers must have Bank Accounts and need to know the
Bank Account of the Traffic Authority.
1.8 Significance of the Project

This project will provide benefits for office workers. Such as:
✓ To avoid data redundancy and to keep data secured
✓ To save resource
✓ To ease data modification like adding, updating and deleting user records
1.8.1 Benefits for the Organization

✓ Relevant information can be accessed any time based on a given privilege.
✓ The project will contribute by making the Traffic Information Management System give
paperless service.
✓ Scheduling will be in a simple way.
✓ They can upload information on the web for customers.
✓ They can secure active files and dead file as they want.
1.8.2 Benefits for Societies

✓ Customers/Drivers could see from the web what they want to see based on their privileges.
✓ Societies get a precise information.
1.9 Feasibility Analysis

Feasibility study is an important issue in both research and software development process. It enables the
developers to have an assessment of the product being developed. It refers to the study of the product in
14
terms of outcomes of the product, operational use and the likelihood the system will be useful to the
organization. Feasibility analysis is undertaken to prove if the proposed system is valuable to implement.
1.9.1 Operational Feasibility

Operational Feasibility is a measure of how well a specific solution will work in the organization. It is
also a measure of how people feel about the system/project. The system to be developed will provide
accurate, active, secured service and decreases the labor of Workers. And also, it is platform Independent
i.e., it runs in all operating systems. The system will also be on behalf of origination’s goal and user
satisfaction, because the system will be possible to run and use in the organizations LAN internet. So, the
system will be operationally feasible or it will be operationally acceptable to users.
1.9.2 Economic Feasibility

Economic feasibility shows the new system should be developed using minimum cost and it give a lot of
benefits such as advancing the services of the system, decreasing the work load of the users.
Tangible Benefits: Are benefits derived from the creation of a system that can be measured in
money and with consistency.
Benefits that are easily quantified from the conducted system are:
✓ Fastest processing time and small amount of processing error.
✓ Small response time and many services.
✓ Easy and fast file management.
✓ Reduce the cost of manual data management (Reducing expenses).
✓ Easy update & retrieval on storing records
Intangible Benefits: Are benefits derived from the creation of a system that cannot be easily
measured in money.
Benefits from the system that are unquantifiable are;
✓ Better decision making.
✓ Better service to the office.
✓ Little job burden to employees of office.
1.9.3 Technical Feasibility

Technical feasibility is a measure of the practicality of a specific technical solution and the availability of
technical resources and expertise. The proposed system can be easily maintained and repaired; technically,
the system will be powerful to be applied by low skilled users as much as possible. There is no need for
the developer involvement in almost all implementation of the entire system. It is easily accessible by the
people who have low level skills.
15
1.9.4 Schedule Feasibility

Schedule feasibility concerned with analyzing the expected completion date of the project and the
constraints that may bring change to this schedule. We have schedules to work our project together. So,
the project team members think that the project would be finished within the specified time.
1.9.5 Political Feasibility

The proposed system has no any conflict with any government directives, because it gave services for the
people effectively and efficiently so the organization is profitable and the system is politically feasible.
1.10 Risk Analysis

Risks are situations or happenings which might or might not occur, but in the case of occurrence, it would
have a negative impact on the development process of the system.
➢ Some common risks that will faced in developing the system are: -
✓ The problem of contacting the traffic office personal at the time we needed.
✓ Lack of internet access.
✓ Unexpected man power failure.
✓ Virus attack on computer.
✓ Failure of electric power.
✓ Time management problem.
1.11 Task Breakdown and Stages

Our project has the following main stages. Those are: -
✓ Proposal: - In this stage the project contains the facts and information’s such as the background
of the organization and the problem of existing system. This stage also shows the needs that the
new system wants to solve the problem. The proposal stage is the main stage that contains the plan
to complete the project effectively.
✓ Analysis: - In the analysis stage requirements will be determined. This means the new system
should do from as many sources as possible. Also, analysis for existing system (user of the existing
system, forms and procedures) will be performed. In the analysis stage requirements that we
determined will be represented diagrammatically in order to make them easier to translate into
technical system specification and design.
✓ Design: - In this stage we will make the layout that shows how the new system will do at its
implementation stage. These are user interface, sequence diagram and others.
✓ Implementation: - It is the last stage that we will run and test the new system according to the
layout in the design phase and requirements specified in the analysis stage.
16
1.12 Work Plan (Gantt chart)

Work plan schedule is concerned with analyzing the expected completion date of the project and the
activities or tasks that the team members perform to provide the project deliverables. So, we have a
work schedule to work together the project with our group members within each day and for the
simplicity and fast developing purpose.
List of activities are depicted in the following Gantt chart. Major tasks are listed here and routines
of activities can be performed accordingly.
Table 1: Schedule for the project
Estimated Task Durations (in dates)
Apr03- May14- May26- Jun24 Jul9 Sept11-

May13- May25- Jun23- -Jul8 - 2022- Sept16- Sep18-
Activities/Tasks
2022 2022 2022 2022 Sept10- 2022 2022
2022
Title Selection and
Proposal Submission
Data collection
Analysis
Design
Coding/Implementat
ion
Testing
Presentation
17
1.13 Cost Analaysis

1.13.1 Hardware Requirements costs
Table 2: hardware requirements cost
No Materials Required Amount Price Per Unit Total Cost

1 Lab Computer (PC) 1 - -
2 Pen 4 10 40
3 A4 Size Paper 2 dozen 800 800
4 Print 300 2 600
5 Flash Disk 1(16GB) 300 300
6 External Hard Disk Drive 1 3,000 3,000
7 Transport - 15 300
8 Photocopy 100 4 400
Total cost 5,440birr
1.13.2 Software Requirements Cost

Table 3: software requirements cost
No Materials Required Price Per Unit

1 Microsoft Word 2019 Free
2 Notepad++ Free
4 XAMPP Server Free
5 Mozilla Firefox/Chrome/opera Free
6 Edrowmax -
Total -
18
1.14 Organization of the Project

This project documentation is organized into five chapters. The first Chapter covers the Introduction part
especially it includes Background information, Motivation, Statement of the problem, Objectives and
Methodologies, Feasibility analysis, Scope and Limitation, Significance, Risk and Cost analysis, Task
break down and Work Schedules. The second Chapter covers Analysis of the existing system such as
Players in the existing system, Major activities and Business rules, Bottlenecks, Risk and constraint
identifications, Proposed solutions, Requirement analysis and Modeling of the existing system. The third
Chapter covers Analysis of the proposed system such as Introductions, SRS identifications and analysis,
and Modeling of the system using different diagrams. The fourth Chapter deals with the System design
activities such as Purpose and goals of design, Class modeling diagrams, Current, and Proposed Software
architecture designs, Access control and Security measures, and User interface design. The fifth Chapter
covers the Implementation and testing phase. The last Chapter encompasses the Conclusion and
Recommendation for future studies.
19
CHAPTER TWO
Description of the Existing System and Requirements Gathering

2.1 Introduction of Existing System
In this section we basically describe about how the existing system work and who are participant of the
system; which means we must identify the actors of the system and what functionalities does they perform
and also we describe the functionalities of the proposed system just by identifying the functional
requirement of the system; those are functionalities that the system must have or activities that must be
done by the system, and the non-functional requirements; those are features of the system that are not
directly related to the actual services provided but relate to the manner in which those services must be
provided.
And also, we mention different diagrams in order to analyze the existing system like Essential use case
diagram, we identify the function of existing system and anything or anyone that interact with the system,
practices that are preserved from the current system i.e., their weakness and strength, what are the Business
rule of the existing system, our constraints and the Alternative solution to the whole system.
2.2 Players (actors) in the Existing System
Actor means a person, organization, or external system that plays role in one or more interactions with
the system. The major players that are involved in the existing system are:
✓ Driver: Is a person who pay penalty payments and perform license cards renewals.
✓ Traffic police: Is a person who punishes illegal Drivers.
✓ Employee: Is a person who record traffic accidents, accept Drivers’ information, record and
update Vehicles and Drivers information by using paper form, and record the license cards of
Drivers.
2.3 Major Functions/activities in the Existing System

Currently, Kombolcha City Traffic Office performs all of its activities manually.
All of the activities are performed on a manual way and there is inefficient utilization of human,
material, time resources. Activities include: -
✓ Accepting new Driver’s information
✓ Recording the license cards of Drivers
✓ Recording traffic accident details
✓ Traffic police punishing criminal Drivers
✓ Recording and updating Vehicle and Driver information in a paper form
✓ Drivers pay penalty payments, and perform license card renewals in the Tanning Centers
20
2.4 Business Rules

Currently, all the data handling and processing functions of the traffic office is done manually and by
using high level manpower. Only a manual document is used to keep records of Drivers, Vehicles, and
accident information’s in the current system. Information is highly exposed to error, incompleteness, lose
as well as damage.
Generally, the following business rules are used in the existing system: -
BR1: Owner must provide original documents and their required number of photo copies which the
office may require by personal.
BR2: To be renewal license card, the license card must be past service expiration date.
BR3: To take license cards, the person must have finished training courses in the training centers.
BR4: To record and update Vehicles and Drivers information, Drivers must be coming to the
institution by personal.
BR5: Every Driver must perform License card renewal in every four years.
2.5 Bottlenecks of the Existing System

The bottleneck of existing system describes the problem encountered in the existing system. In the
existing system Drivers pay penalty payments in bank by person, and after they pay the payment, they
must find the Traffic police to take their license cards. Such process leads Divers to waste their time,
effort, money and make them unsatisfied. In this part we discuss some of the problem related to the
Performance problem, Information Problem, Data storage problem, Efficiency Problem and Security and
Control problem.
2.5.1 Performance Problem

In the current system it is unable to perform tasks and activities with efficient and effective manner. It is
tedious and not fast.
2.5.2 Information Problem

The existing system has many drawbacks concerning data security such as lose of data may occur. due to
manual management of data, there is a redundancy, inconsistency and inaccurate data and information
problems. There is incorrect information which leads to poor decision making and Poor flow of
information between City traffic police and Transport office as well as Higher Authorities like Zone and
Regional Offices.
2.5.3 Data Storage Problem

Problems like lack of a well-organized database system makes data not easily accessible and manageable
due to its integration problem and placed in different location, difficult to update information which leads
21
to inconsistency. There is an exposure to disaster; like fire, flood, volcanic eruption are main data storage
problems.
2.5.4 Efficiency Problem and Security

The efficiency of the existing system is not optimal, because storing, locating and searching data takes
much more time that is not efficient.
2.5.5 Control Problem

The current system can be accessed by unauthorized person, since it doesn’t have any authentication and
authorization system.
2.6 Risk and Constraints

✓ Computer Viruses: While we encounter this problem, we take full scanning of our computer and
documents using the latest antivirus available, also keep our antivirus updated and make random
scans on our computer before this risk encounter.
✓ Power failure and data loss: when there is a power loss, we use laptops, and to prevent a loss of
data we save the copy of our project on different computers (PCs).
✓ Lack of time: The time given may not enough to cover it. We manage our time and we will try to
accomplish it according to the schedule of the project.
2.7 Proposed Solution for the New System

To avoid all problems existing in the traffic office and make the operations and activities more accurate,
the system needs to be computerized. The aim of this project is to develop improved system that can
overcome the problems of the existing system.
In Kombolcha City traffic information management system there is no any computerized system used
before. All activities are performed manually and no any central database. So, user information is stored
on paper. After analyzing all about the current system, we are proposed to do a system that simplifies the
activities performed in the current system.
In general, our proposed system has the properties like better utilization of resources, good performance,
high security, reliability, and accuracy. The new system is aimed to perform basic and crucial tasks of the
traffic. The new system contains a well-organized database which preserves data consistently.
2.8 Requirements of the Proposed System
The purpose of requirement is used to prepare requirement specification before starting the actual design.
22
2.8.1 Functional Requirements

Functional requirements explain what has to be done by identifying the necessary task, action or activity
that must be accomplished. These are the statement of service that the system should provide. The
proposed system is aimed to do the following functionalities:
RQ1: The system should allow the users login to the system by their account.
RQ2: The system should allow the employee and traffic polices to view Vehicles and Drivers
information.
RQ3: The system should allow the Administrator to manage and view users account information.
RQ4: The system should allow the Drivers to view penalty information’s.
RQ5: The system should allow the Divers to add appointment for penalty payments.
RQ6: The system should allow adding and updating penalty payments, new Drivers and Vehicles
information.
RQ7: The system should allow users to change account information except user name.
RQ8: The system should allow search for any vehicle, penalty and users detailed
information.
RQ9: The system should allow to Generate Reports and to Record day to day Accidents
information.
RQ10: The system should allow the Administrator to Post Notices to users. And the users
to send Feedbacks.
2.8.2 Non-functional Requirements

Non-functional requirement describes requirement that support the main part of the system that should
have but they are not the part of the system functionalities. Non-functional requirements describe about
the systems quality rather than the main functionality of the system.
The following are the non-functional requirements associated with the new system: -
✓ Performances: The performances of the system should be optimal. System can withstand even
though many numbers of users request the desired service.
✓ Availability: Since the proposed system is web based it will be available and users can access
it when they want to access it.
✓ Security: The system provides security in such a way that unauthorized users are not access the
required information.
23
✓ Portability: The system must be designed for platform independent and the system supports
every operating system.
✓ Maintainability: The system should be easily modifiable and extensible to add new
functionality without affecting the general frame work of the system.
✓ Error handling: The system should handle invalid inputs and display informative error
messages to users.
2.9 Modeling the Existing System
2.9.1 Essential Use Case Diagram

A use case describes something of value to an actor (often a person or organization). Essential use case
diagram is used to describe the general over view of existing system, identify the function of existing
system and anything or anyone that interact with the system. Essential use case is a use case that is
technology independent, it describes the fundamental business tasks without bringing technological issues
into account.
Figure 1: Essential use case diagram
24
2.9.2 Essential User Interface Prototyping

A technology-independent prototype created using paper that can be used to identify UI requirements.
Figure 2: Essential user interface prototype for punishing drivers
25
CHAPTER THREE
System Analysis of the Proposed System

3.1 Introduction
In this chapter we will make a detail analysis of the proposed system, and there will be diagrams that will
be used to depict the overall system functionalities. These include the System requirement specifications,
Use case diagram, Class Responsibility Collaborator analysis, Sequence diagram, Activity diagram, and
Analysis level class diagram and User interface prototyping.
3.2 System Requirement Specifications (SRS)
3.2.1 Actor Identification

The followings are the actors that will be involved in our proposed system.
✓ Driver: - Is a person who pay penalty payments, add appointment for penalty payments. And
also view their penalty information’s. And also view His/her Appointments.
✓ Employee: - Is a person who adds new Diver and Vehicle information’s. And also update
penalty information’s, Drivers and Vehicle information’s.
✓ Traffic Police: - Is a person who Punish illegal Drivers, add penalty records of drivers and
Accidents. view penalty records, Appoints, Drivers and Vehicles information.
✓ Administrator: - A person who manages Users and Users account that means create, activate
and deactivate user accounts. And also manage the system, Generate Reports and send Notices
to users.
26
3.2.2 Use Case Identification

Table 4: Use case identification
Login Update license cards

Create Account Update penalty information
Change Password Update Vehicle information
Add new Diver license Add appointment
Add new Vehicle Pay penalty payment
Add penalty records Logout
View penalty records Deactivate Account
View Driver information, Activate Account
View Vehicle information Record Accidents
View appointments View Accidents
Generate Reports Send Feedbacks
Post Notices Manage System Interface
3.3 Modeling the Proposed System
3.3.1 System Use case Diagrams
Use case diagrams are diagrams used for capturing functional requirements of the system. Each use case
diagram describes a behaviorally related sequence of transaction in a dialogue between the user and the
system. A use case diagram is a collection of actors, use cases, and theircommunications.
27
The following diagram shows the proposed system use case diagram.
Figure 3: System use case diagram
28
3.3.2 Use Case Documentation

Table 5: Login Use case Documentation
Use-case Number UC-01

Use-Case Name Login
Goal Allowing Administrator and users to login to the system.
Actor Administrator and Users (Employee, Traffic police,
Driver)
Description This use case describes how Administrator and each user
login into the system.
Pre-condition None
Post-condition If the use case was successful, the Administrator and users
is now logged into the system. If not, the system state is
unchanged.
Basic course of Actor Action System Response
Action 1. The Administrator and Users 3. The system verifies
are trying to login to the the password and
system. username.
2. The Administrator and User 4. If the username and
enters user name and password are valid the
password and click login system redirects to their
button. page else 4.1
5 use case ends
Alternate course 4.1 The system displays error message and redirect to the
of Action login page.
29
Table 6: Create account Use case Documentation
Use-case UC-02
Number
Use-Case Create Account
Name
Goal Creating User accounts successfully.
Actor Administrator
Description Allows the administrator to create account for users (Traffic
police, Driver and Employee)
Pre-condition To be authenticate the User and be free to use the system.
Post-condition The Users account will be successfully created.
Basic course Actor Action System Response
of Action 1. The administrator clicks on Add 2. The system displays
user account link under Manage create account UI form
user account page. page.
3. The administrator fills the form 5.The system validates
to be created account. the create account form
4. The administrator press create elements
account button. 6.The system displays
user account successful
create message
7. The use case ends.
Alternate 6.1: If the form is not filled properly. The system displays an
course of error message. The system resumes at step 3.
Action
30
Table 7: Activate Account Use Case Documentation
Use-case UC-03
Number
Use-Case Activate Account
Name
Goal Enabling users account successfully
Actor Administrator
Description This use case describes how Administrator activates user’s
account. When users Resign job, their account should be
deactivated and when they return to their job their account will
be activated by Administrator.
Pre-condition Employee, Driver and Traffic police return to their job
Post-condition If the use case was successful, users can access to their
account
of Action 1. Administrator login to the 2. The system displays
system and clicks on ‘search search user UI form field.
link’ under Manage User 4. The system displays
Account page users’ information if found
3. Administrator fills user’s id. else goes to 4.1.
5. Administrator clicks on 6. The system deactivates
‘Activate user’ button. user’s account and display
‘successful’ message
Alternate 4.1 The system displays ‘no such user found’ message.
course of And redirect to step3.
Action
31
Table 8: Deactivate Account Use Case Documentation
Use-case UC-04
Number
Use-Case Deactivate Account
Name
Goal Disabling users account successfully
Actor Administrator
Description This use case describes how Administrator Deactivate user’s
account. When users Resign job, their account should be
deactivated.
Pre-condition Users are not working currently
Post-condition If the use case was successful, users can’t access to the system
of Action 1. Administrator login to the 2. The system displays
system and clicks on ‘search search user UI form field.
link’ under Manage User 4. The system displays
Account page. users’ information if found
3. Administrator fills user’s id. else goes to 4.1.
5. Administrator clicks on 6. The system Deactivates
‘Deactivate user’ button. user’s account and display
‘successful’ message
Alternate
course of 4.1 The system displays ‘no such user found’ message.
And redirects to step3.
Action
32
Table 9: View Own Profile Use Case Documentation
Use-case UC-05
Number
Use-Case View Profile(self-profile)
Name
Goal Allowing Administrator and users to see their own Account
profiles
Actor Administrator and Users (Employee, Traffic police, Driver)
Description This use case describes how Administrator and Users view
their profile
Pre-condition Administrator and Users logged to the system
Post-condition If the use case was successful, the Administrator and Users
can view their own profile.
of Action 1. The Administrator and User’s 3. The system displays
login to the system their own profile
2.The Administrator and Users information.
open ‘profile’ menu item 5. The system displays
4. Administrator and Users click their page
‘close’ button to return to their
page
6.use case end
Alternate
course of The system displays error message. And allows them to try
again.
Action
33
Table 10: Change Password Use Case Documentation
Use-case UC-06
Number
Use-Case Change Password
Name
Goal Enabling Administrator and Users to update their own
password easily.
Actor Administrator and Users (Employee, Traffic Police, Driver)
Description This use case describes how Administrator and each User
change their own password
Pre-condition Administrator and each User logged to the system
Post-condition If the use case was successful, the Administrator and Users
will have new password
Action 1. Administrator and Users try 2. The system displays their
to login to the system with page.
valid user name and password. 4. The system displays
3.Administrator and User change password UI form
clicks on ‘change password that contain the following: -
link’ under the Account ✓ old password
menu page. ✓ New password
5. Administrator and User fills ✓ Confirm password
the form components and 6. System checks old
Click ‘Apply’ button password and password
8. End of use case policy
7. If old password is correct
and new password fulfil
password policy, then
replace old password with
new password in the
database
and displays ‘Successful’
message and go to
Homepage
else go to 7.1
Alternate 7.1. If the new password doesn’t fulfil the password policy
course of or the old password is incorrect then the system displays
error message and go to 4
Action
34
Table 11: Add Driver License Use Case Documentation
Use-case UC-07
Number
Use-Case Add new Diver License
Name
Goal Registering a new legal driver license into the database
Actor Employee
Description This use case describes how Employee add new Driver
License
Pre-condition Driver must pass field exam. In addition, he/she must able to
bring his/her grade 10 certificate.
Post-condition If the use case was successful, Drivers get license card, new
user id and password.
Action 1.Employee login to the 2. The system displays add
system and click ‘add driver Driver license UI form.
license’ menu item. 4. The system checks or
3.Employee fills the form validates the form fields.
and clicks on ‘add button’. 5. If the form fields are
7. use case end correctly filled then the
system adds Driver licenses
and save the data to the data
base else go to use case 5.1
6. The system displays
‘successfully added Driver’
message.
Alternate 5.1 If the form fields are not correctly filled, the system
course of display error message and redirects to step3.
Action
35
Table 12: Add Vehicle Use Case Documentation
Use-case UC-08
Number
Use-Case Add Vehicle
Name
Goal Registering a new Vehicle information into a database
Actor Employee
Description This use case describes how Employee add new Vehicle.
Pre-condition Employee should login to the system
Post-condition If the use case was successful, the Vehicles information are
registered.
Action 1.Employee login to the 2. The system displays add
system and open ‘Add Vehicle UI form.
Vehicle’ menu. 4. The system checks or
3.Employee fills the form and validates the form fields.
click add button 5. If the form fields are
7. use case end correctly filled then the
system add Vehicle and
save the data to the data
base. Else go to use case 5.1
‘successfully add Vehicle
message.
course of display error message and redirects to step3.
Action
36
Table 13: Pay penalty bill Use case Documentation
Use-case UC-09
Number
Use-Case Pay Penalty Payment
Name
Goal Enabling illegal Drivers to pay for their punishment
Actor Drivers
Description This use case describes how Drivers Penalty payments.
Pre-condition Drivers must have account and login to the system
Post-condition If the use case was successful, Driver Pay their penalty
payments.
Action 1. Driver’s login to the 2. The system displays pay
system and clicks on ‘Set penalty UI form.
Status Link under penalty 4. The system checks or
records menu. validates the form fields.
3.Drivers fills the form and 5. If the form fields are
click pay button correctly filled then the
7. use case end system register bill. Else go
to 5.1
‘successful message.
course of display error message and redirect to step3.
Action
37
Table 14: Add Appointment Use Case Documentation
Use-case UC-10
Number
Use-Case Add Appointment
Name
Goal Enabling drivers to add an appointment for penalty payments.
Actor Driver
Description This use case describes how Driver adds appointment.
Pre-condition Drivers logged into the system
Post-condition If the use case was successful, the Drivers added appoints.
Action 1. Driver’s login to the system 3. The system displays Add
2.The Drivers clicks on add Appointment UI form
appointment menu. 5. The system validates
4. Drivers fill the appointment filled contents
form 7. The system displays
6. The Drivers click ‘Appoint’ success message. Else go to
button. 7.1.
8.use case end
Alternate The system displays error message and redirects to step 4.
course of
action
38
Table 15: View Driver Information Use Case Documentation
Use-case UC-11
Number
Use-Case View Driver Information
Name
Goal Allowing authorized users to see drivers’ information
Actor Users (Employee, Traffic police)
Description This use case describes how the Users (Employee, Traffic
police) view Driver’s information.
Pre-condition Users logged to the system
Post-condition If the use case was successful, the users can view driver
information.
Action 1. The Users login to the 3. The system displays list
system of Driver’s information
2. Users clicks on ‘view 5. The system displays
Driver information’ menu. Driver information
4. Users select Drivers and 7. The system redirects to
‘View information’. their page.
6. Users click ‘close’ button to
return to their page.
8.use case end
Alternate The system displays no such driver found error message.
course of
Action
39
Table 16: Update vehicle and Penalty Information Use Case Documentation
Use-case UC-12
Number
Use-Case Update Vehicle and Penalty Information
Name
Goal To update data of vehicle and penalty
Actor Employee
Description This use case describes how the Employee updates Vehicle
and Penalty information’s
Pre-condition Employee logged to the system
Post-condition If the use case was successful, Employee can update
information.
Action 1. Employee login to the 3. The system displays list
system of vehicle and penalty
2. Employee clicks on ‘View information’s.
vehicle and penalty 5. The system displays fill
information menu. UI forms for Vehicle.
4. Employee click ‘Update’ 7. The system validates the
Link for Vehicle and Set filled elements. And
Status Link for Penalty displays successful message
6. Employee inserts Vehicle else, go to 7.1.
information’s and click
‘Update’ button.
8.use case end
Alternate The system displays error message and redirects to step 6.
course of
action
40
Table 17: View Vehicle information Use case Documentation
Use-case UC-13
Number
Use-Case View Vehicle Information
Name
Goal Allowing authorized users to see Vehicle information’s
Actor Employee, Traffic Police
Description This use case describes how authorized users view Vehicle
information’s.
Pre-condition Employee and Traffic police logged to the system
Post-condition If the use case was successful, users can view vehicle
information.
Action 1. Employee and Traffic 3. The system displays list
police login to the system of Vehicles’
2. Employee and Traffic 5. The system displays
police click ‘View Vehicle Vehicle information.
information ‘menu. 7. The system redirects to
4. Employee and Traffic their page.
police select Vehicle row.
6. Employee and Traffic
police click ‘close’ button
to return to their page.
8.use case end
Alternate The system displays no such Vehicle found error message.
course of
Action
41
Table 18: Add Penalty Record Use Case Documentation
Use-case UC-14
Number
Use-Case Add Penalty Record
Name
Goal To register penalty record information’s to a database
Actor Traffic Police
Description This use case describes how the Traffic police add penalty
records into a database
Pre-condition Drivers violate the rule and Traffic Police must be logged to
the system
Post-condition If the use case was successful, penalty records are added by
the Traffic police.
Action 1. Traffic police login to the 2. The system displays user
system page.
3.Traffic Police clicks on ‘add 4. The system display Add
Penalty’ Link. Penalty Record UI form.
5. Traffic police fill form 6. The system Inspect form
elements and clicks on Add elements.
Penalty Button 7.If form elements are
8.use case end correct, the system saves
the data to the database and
display successful message
else go to 7.1
Alternate 7.1 The system displays error message and redirects to step5.
course of
Action
42
Table 19: Logout Use case Documentation
Use-Case UC-15
Number
Use-Case Name Logout
Goal Enabling Administrator and Users to successfully logged
out from the system
Actor Administrator and (Employee, Traffic police and Driver)
Description These use case allow Administrator and (Employee, Traffic
police and Driver) logout from the system at a time of
accomplishing their work.
Pre-condition UC-1
Post- Condition The system saves the data into the session or the database
and then allowing to logout from the system.
Basic course of User Action System Response
Action 1. The Administrator 3. The system saves the data and
and Users try to log responds to the requested action.
out from the 4. The system redirects to the login
system. page.
2. The Administrator
and Users click the
logout button
43
3.3.3 Domain Modeling with Class Responsibility Collaborator (CRC)

A class responsibility collaborator model is a collection of standard index cards that have been divided
into three sections, as depicted in.
✓ A class: Represents a collection of similar objects. The name of the class appears across the top
of the card.
✓ A responsibility: Is something that a class knows or does. Responsibilities are shown on the
left-hand column of a CRC card.
✓ A collaborator: Is another class that a class interacts with to fulfill its responsibilities.
Table 20: CRC diagram for Administrator
Administrator <<Actor>>
Id Users<<Actor>>
Report<<UI>>
Password
Notice<<UI>>
Name
Address
Sex
Activate Account ()
Deactivate Account ()
Create Account ()
Generate Reports
Post Notices
44
Table 21: CRC diagram for Traffic police
Traffic Police <<Actor>>

Id Penalty Record<<UI>>
Password Vehicle<<UI>>
Name Driver<<UI>>
Address Appointment<<UI>>
Sex Accident<<UI>>
Add penalty Records ()
View penalty Records ()
View driver Info ()
View vehicle Info ()
View Appointments ()
Record Accidents ()
Table 22: CRC diagram for Driver
Driver <<Actor>>
Id Employee <<Actor>>
Password Penalty Payment <<UI>>
Name Appointment <<UI>>
Address Penalty Record <<UI>>
Sex Notice<<UI>>
View penalty records ()
Add Appointment ()
Pay penalty Payment ()
View Notices ()
45
Table 23: CRC diagram for Employee
Employee <<Actor>>
Id Driver<<Actor>>
Password Penalty Record<<UI>>
Name Appointment <<UI>>
Address Vehicle <<UI>>
Sex Accident<<UI>>
Add new driver License () Notice<<UI>>
Add new Vehicle ()
View penalty Records ()
View driver Info ()
View vehicle Info ()
Update license Cards ()
Update penalty Info ()
Update vehicle Info ()
View Accident Info ()
View Notices ()
3.3.4 Sequence Diagrams

Sequence diagrams are used to represent graphically how objects interact with each other via messages in
the execution of a use case or operation. They illustrate how the messages are sent and received between
objects and in what sequence.
46
Figure 4: Sequence diagram for login
47
Figure 5: Sequence diagram for create Account
Figure 6: Sequence diagram for activate Account
48
Figure 7: Sequence diagram for Deactivate Account
49
Figure 8: Sequence diagram for change Password
Figure 9: Sequence diagram for Add penalty
50
Figure 10: Sequence diagram for Add Appointment
3.3.5 Activity Diagrams

Activity diagrams are another important diagram in UML to describe dynamic aspects of the system.
Activity diagram is a flow chart to represent the flow form one activity to another activity. The activity
can be described as an operation of the system. Therefore, the control flow is drawn from one operation
to another. This flow can be sequential, branched or concurrent.
51
Figure 11: Activity diagram for login
52
Figure 12: Activity diagram for create Account
53
Figure 13: Activity diagram for Activate or Deactivate Account
54
Figure 14: Activity diagram for change Password
55
Figure 15: Activity diagram for Add penalty
56
Figure 16: Activity diagram for Add Appointment
57
Figure 17: Activity diagram for Logout
3.3.6 Analysis Level Class Diagram (Conceptual Modeling)

Class diagram gives the static view of an application. A class diagram describes the types of objects in the
system and the different types of relationships that exist among them. This modeling method can run with
almost all Object-Oriented methods. A class can refer to another class. A class can have its objects or may
inherit from other classes.
UML Class Diagram gives an overview of a software system by displaying classes, attributes, operations,
and their relationships. This diagram includes the class name, attributes, and operation in separate
designated compartments.
Essential elements of UML class diagram are:

Class Name
Attribute
Operation
The following shows the class diagram for the proposed system.
58
Figure 18: Analysis level class diagram
3.3.7 User Interface Prototyping

User interface (UI) prototyping is an iterative development technique in which users are actively involved
in the making-up of the UI for a system. User interface prototype is to indicate the surface that can be used
by user and the system to communicate to each other, but, not actual work area.
59
Figure 19: User interface Prototyping Diagram for Login
3.3.8 User Interface Flow Diagraming

User Interface Flow Diagrams are system models the show how different pages of a user interface are
connected and how a user can step through various pages of the system. User Interface Flows are typically
comprised of screens and navigation paths between various screens. They describe how a user might
physically navigate the interface system.
60
Figure 20: User Interface Flow Diagram of the Proposed System
3.4 Identifying Change Cases

Change case will used to describe potential modification requirements to the system. There are some cases
that change the content of the project. From those: -
✓ Missing activities: -When important activities are missed in each project development phase and
the developing team latterly understood them, the developing team take them into consideration.
✓ Important comments: - When crucial comments are raised from the advisors, teachers and
examiners that should be included and excluded, the developing team assess the project again.
✓ Lack of resources: - If there is scarcity of resources occurred to develop the system activities, the
developing team also restructured the contents of the project.
61
Chapter Four: System Design

4.1 Introduction
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 takes into account the nonfunctional
requirements and constraints described in the problem statement and requirement analysis sections
discussed earlier.
In this chapter we will see the Purpose and Goals of Design, Class Modelling, State Chart modeling,
Collaboration Modelling, Current and Proposed System Architectures, Subsystem Decompositions,
Component Modeling, Deployment Diagram, Persistence modeling, Access Control and Security,
Boundary Conditioning and Exception Handling and User Interface Design.
4.2 Purpose and goals of design

The objectives of design are to model the system with high quality. The design goals are derived from
non-functional requirements that means non-functional requirement is the description of the
characteristics and attribute of the system as well as any constraints that may limit the boundary of the
proposed solution.
Design goals describe the qualities of the system that the developers should consider. And include: -
✓ Security: For our system we use strong password in order to secure the system.
✓ Modifiability: the system should be easily scalable and extensible to add new features. And also,
it should be easily modifiable to make changes on the functionalities.
✓ Performance: - The system should respond fast with high throughput.
✓ Cost: The system should require a minimum cost for both developmental cost and the cost to deploy
the system.
✓ Reliability: the system should maintain and perform its functionalities under any condition. It
should have minimum frequency of failure and adaptable for failures.
✓ End User Criteria: - The system should have simple and understandable graphical user Interface
such as forms and buttons, which have descriptive names.
62
4.3 Class modeling

Class diagram are the basis of object-oriented analysis and design. A class diagram shows the classes of
the system, their interrelationships (including, inheritance, aggregation and association) and the operations
and attributes of the classes. Class diagrams are used for wide variety of purposes, including both
conceptual/domain modeling and detailed design modeling.
Figure 21:Classes modeling for the proposed system
63
4.4 State chart modelling

The state chart diagram that we are going to be design shows the change of an object through time. Based
upon events that occur, the state diagram shows how the object changes from start to finish. States are
represented as a rounded rectangle with the name of the state shown in the system. Connecting states
together are transitions. These represent the events that cause the object to change from one state to
another.
Figure 22:State chart diagram for login
64
Figure 23:State chart diagram for create Account
Figure 24:State chart diagram for Add penalty record
65
4.5 Collaboration Modeling

A collaboration diagram resembles a flowchart that portrays the roles, functionality and behavior of
individual objects as well as the overall operation of the system in real time. Objects are shown as
rectangles with naming labels inside. These labels are preceded by colons and may be underlined. The
relationships between the objects are shown as lines connecting the rectangles. The messages between
objects are shown as arrows connecting the relevant rectangles along with labels that define the message
sequencing.
Figure 25:Collaboration diagram for login
66
Figure 26:Collaboration diagram for create Account
Figure 27:Collaboration diagram for Add penalty record
67
4.6 Current software architecture

The existing system of the Kombolcha city trafficking system is a manual system and hence there is no
current software architecture that is deployed. As a result, we only describe the software architecture of
the newly proposed system.
4.7 Proposed software architecture

The architecture of traffic information management system is a three-side architecture. These are client
side, middle side and data side.
✓ In the client side: The user can be browsing the system to retrieve, add and update information.
Performing such activity needs directly interact with the system through web browser.
✓ In the middle side: The traffic information management system contains web server and business
logic. The web server handles all the HTTP requests coming from the client machines. It also
manages the responses that are returned to the client machines. The business logic is responsible
for handling all the core functionalities of the system such as input validation, performing
calculations, and access and retrieval of any data required by the client.
✓ In the data side: Manages the actual data that is being stored in the database. It is implemented
using MY SQL database. The database accepts the SQL statement and executes it by DBMS
component and then returns the required output to the application. It manages and accesses the
persistence data.
Figure 28:Proposed software architecture
68
4.8 Subsystem Decomposition

Subsystem diagram shows the service it provides or it accepts from other subsystems, and the coupling
and the coherence between them. In order to simplify and minimize the complexity of the solution domain,
our system has been divided into two subsystems.
✓ Traffic Information Subsystem: - Is responsible for providing Information Management

services. This service is for Traffic Police, Divers, and employee’s interaction. The Driver class is
responsible for providing Driver information, Traffic Police class is for providing Traffic Police
information and Employee class is for Employee information.
✓ Administration Subsystem: - Enables the administrator to manage Users and User accounts. The
administration includes creation of new accounts, activating and deactivating existing accounts,
Generating of Reports, Posting Notices and Management of System interfaces. The management
of user account is the responsibility of the Account class. The account class is the one that creates,
displays and modify the user’s account.
Figure 29:Subsystem decomposition
69
4.9 Component Diagram

Component diagram provides the physical view of the system. It shows the relationship between software
components, their dependencies, communication, location and other conditions. Component diagrams are
particularly useful with larger teams.
Figure 30:Component diagram
70
4.10 Deployment Diagram

Deployment diagram show how the system will deployed on computers. In other words, it shows which
component of the software will install on which machine and how they communicate with each other if
they are on different machines. Deployment diagrams can also be created to explore the architecture of
embedded systems, showing how the hardware and software components work together.
Figure 31:Deployment diagram
71
4.11 Persistence Modeling

Persistence modeling is used to communicate the design of the database, usually the data base to both the
users and the developers. It is also used to describe the persistence data aspect of the system. Our system
includes the basic table that handles the data of system implemented using SQL server.
The following diagram indicates the persistence diagram of our system.
Figure 32:Persistent diagram
4.12 Access Control and Security

In multi-user systems, different actors have access to different functions and data. During the analysis
stage, we model these different accesses by associating different use cases with different actors and during
system design, we model these different accesses by examining the object model by determining which
objects are shared among actors. Depending on the security requirements of the system, we describe the
privileges or authorities of actors over the functionality.
72
Table 24:Access security table
Actors
Functionality Administrator Driver Traffic Employee
Police
Create Account ✓
Add new diver license ✓
Add new Vehicle ✓
Add penalty record ✓
View driver information ✓ ✓
View Vehicle information ✓ ✓
View penalty records ✓ ✓ ✓
Update license cards ✓
Update penalty information ✓
Update Vehicle information ✓
Add appointment ✓
View appointment ✓ ✓ ✓
Deactivate Account ✓
Activate Account ✓
Login ✓ ✓ ✓ ✓
Generate Report ✓
Post Notice ✓
Record Accidents ✓
View Accidents Information ✓ ✓
4.13 Boundary conditions and Exception Handling
4.13.1 Boundary conditions

Boundary condition focuses on the objects that act as a boundary between the client side and server side
of our proposed system. Some of our proposed system boundary objects are: -
The Home page, Login page, Penalty record page, manage account page, Penalty payment page,
Appointment page, Vehicle page, Driver license page, Password page, Notice Page, Report page, and
Accident page.
73
Since our system has a client–Server architecture, the following requirements are mandatory on both
Client and Server side.
✓ Internet connection should be available.

✓ Web browser is demanding to connect with the web server of our system
✓ The users should be legitimate and having an account provided by the Administrator.
✓ The user can communicate the different pages using the homepage.
✓ The users can get different service from the system.
✓ The Administrator updates users accounts using his/her preferred privileges
✓ Our system server should be registered on the local service provider.
✓ Our proposed system should have database driven-website.
✓ Our system automatically saves the changes made by users.
4.13.2 Exception Handling

Exception handling is the method of building a system to detect and recover from exceptional conditions.
Exceptional conditions are any unexpected occurrences that are not accounted for in a system's normal
operation. The following are some of the exceptions handled by our proposed system.
✓ The system will display error messages if users are tried to access using wrong/invalid account.
✓ The users can’t access functionalities that are not available in the system.
✓ If the user enters random username or passwords, it checks and gives an informative message.
4.14 User Interface Design
Figure 33:Login user interface

74
Figure 34:Traffic Police page
Figure 35:Notice post User interface
75
Chapter Five: Implementation and Testing

5.1 Introduction
In this phase what the group members have done is turning the physical design specification into working
computer code and also application, and then the code is tested until most of the errors have been detected
and corrected. User sites are prepared for new system and user must come totally on the new system rather
than the existing one to get their work done. There are some managerial activities in this, coding, testing,
and installation.
5. 2 Final Testing of the System

Testing is the process of running a system with the intention of finding errors. In our system, testing
enhanced the integrity of the system by detecting deviations in design and errors in the system, reduced
risk of failures once systems are transferred to live operation; it also typically identified the end of the
“development” phase of the project.
5.3 Testing procedures

Before directly deploying this system, the team performed two types of testing procedures for its
functionality and meeting customers need. These techniques are Black box testing and White box testing.
➢ Black box Testing:
To test our system, the tester may use black box testing, if he/she has not enough time to check internal
modules or codes. By looking only input /output or user interface, the tester can test our systems
functionalities without looking the internal code. We used this testing technique for the following reason
This testing type is more effective on larger units of code
✓
Tester needs no knowledge of implementation, including specific programming languages
✓
Tester and programmer are independent of each other
✓ Tests are done from a user's point of view.
➢ White box Testing:
In this type of testing, skilled man in different programming languages tries to test the logic of our system.
If the person who tests the system is not skilled, it is difficult to understand our systems functionality. If
any failures occur while testing the system in all of the above testing methods, the team will take
immediate correction where this fault occurred before jumping to next work. So, that it will meet the goal.
76
5.3.1 Unit testing

Unit testing is the testing of an individual unit or group of related units. It is often done by the programmer
to test that the unit he/she has implemented is producing expected output against given input so that our
team mate performs unit test to test the internal logic of the module/program.
5.3.2 Integration Testing

In this phase software testing in which individual software modules are combined and tested as a group.
The purpose of integration testing is to verify functional, performance, and reliability requirements placed
on major design items.
5.3.3 Performance Testing

Performance testing is the testing to assess the speed and effectiveness of the system and to make sure it
is generating results within a specified time as in performance requirements.
5.3.4 System Testing

System testing of software or hardware is testing conducted on a complete, integrated system to evaluate
the system's compliance with its specified requirements. It ensures that the entire integrated software
system meets the desired requirements. It tests a configuration to ensure known and predictable results.
77
Table 25:User Login Authentication
Test Case ID: TestCase01

Unit to Test: Login Authentication for Users
Expected Results: Redirects to their page.
Test Data: Username (valid username, invalid username, empty)
Password (invalid password, valid password, empty
Steps to be Executed Data Expected Results

Enter valid Username (ID) and Username: xxxxxxx Display “Enter your
Empty Password and Click Login password!”
button.
Enter Valid Password and Empty Password: ******* Display “Enter your
user name and Click Login button Username!”
Enter Invalid Password and Invalid Username: xxxxxxx Display “Invalid user name
or
user name Click Login button Password: ******* password!!”
Enter Invalid Password and Click Username: xxxxxxx Display “Invalid user name
or
Login button Password: ******* password!”
Sample Php Source code for login
<?php
$host="localhost";
$user="root";
$password="";
$database="traffic";
78
$conn=new mysqli("localhost","root","","traffic");
if(!$conn){
echo "Failed to connect!";
if (isset($_POST['login'])){
session_start();
$user_id =$_POST['user_id'];
$password = $_POST['password'];
$password=md5($password);
$query = "SELECT * FROM account WHERE user_id='$user_id' && password='$password' "or

die(mysqli_error());
$result = mysqli_query($conn,$query)or die(mysqli_error());
$num_row = mysqli_num_rows($result);
$row=mysqli_fetch_array($result);
$row_id=$row['user_id'];
$status=$row['status'];
$row_email=$row['e_mail'];
$user_type =$row["user_type"];
$row=mysqli_fetch_array($result);
if( $num_row > 0 ) {
if($user_type=="Administrator"){
$in1 = mysqli_query($conn,"select * from account where user_id='$user_id'");
if (mysqli_num_rows($in1) > 0) {
$in1 = mysqli_fetch_array($in1);
$status = $in1['status'];
79
if ($status == 'Active') {
header('location:Adminer/index.php');
$_SESSION['id']=$row_id;
} else {header('location: Deactive.php');
}} }
else if($user_type=="Traffic Police"){
header('location:traffic_police/index.php');
}else{header('location:Deactive.php');
}}
else if($user_type=="Employee"){
80
header('location:employ/index.php');
}} }
else if($user_type=="Driver"){
header('location:driver/index.php');
}} }
else{
header('location: access_denied.php');
}}
?>
81
Chapter Six: Conclusions and Recommendation

6.1 Conclusions
So far, we were intended in analyzing the existing system of the traffic office up to proposing our new
system that solves the difficulties related to the existing system. Until now we have been doing the
documentation of the traffic management system and mainly the implementation of the system. In the
documentation we have seen the introductory sections about the overall system we have also done the
detail analysis and the design of the system that we developed and implemented. To say something on the
existing system: it is running almost manually, wastage of time, wastage of resource, it doesn’t give
satisfaction for workers and drivers, data is not secure as well as it is not well organized in computerized
form. By having these problems over the existing system our aim was to build a new system that have
greater functionality that enhance effectiveness and efficiency related parameters on the system. By
keeping in mind that the new system will handle problems that exist in the existing system.
6.2 Recommendation
We would like to recommend that the system is open for all interested groups or individuals who wish to
add new functionalities on the system especially developing the system on a distributed databased way
that is used as a whole for our country Ethiopia. Next, the team would recommend that further work should
be done on the system in order to make the system fully functional like official website.
82
APPENDIX
Interview Questions
1. What is the existing system your organization using now?

2. What are the existing system drawbacks?
3. What methods are used to generate reports about drivers, accidents, and vehicles?
4. How illegal (criminal) drivers are punished?
5. How does this office store record and information’s?
6. What methods are used to announce important information’s for whom it concerns?
83
References
[1] Ethiopian_government_stubs,"Wikipedia,"[Online].Available:
https://en.wikipedia.org/wiki/Ethiopian_Road_Transport_Authority.
[2] Main Sajin Tigist E. and CommanderGenet A. Interviewee, Data Collection About The organization.
[Interview]. 03 May 2022.
[3] STEVE McROBB& RAY FARMER, SIMON BENNETT, "Object Oriented System Analysis and
Design Using UML, 2nd edition, McGraw-Hill Education.".
[4] "Eastern Peak," [Online]. Available: https://easternpeak.com/definition/iterative-development/.
84

Wollo University Kombolcha Institute of Technology College of Informatics Department of Information System

Uploaded by

Copyright:

Available Formats

Wollo University Kombolcha Institute of Technology College of Informatics Department of Information System

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Wollo University Kombolcha Institute of Technology College of Informatics Department of Information System

Uploaded by

Copyright:

Available Formats

WOLLO UNIVERSITY

KOMBOLCHA INSTITUTE OF TECHNOLOGY

Final Year project

Name of Advisors: Moges Tesfa Wollo University

Department head sign

Mr. Kedir Abdu _________

1. Mekonnen Melkamu WOUR/0718/11 _______

2. Birtukan Biset WOUR/0595/11 ________

3. Assabnesh Mekuriaw WOUR/4486/11 _______

Moges T. Name: ______________ Signature: _____

Signature: _______ Name: _______________Signature: _____

Date: - 17/09/2022 Date: __________

1.13 Cost Analaysis ........................................................................................................................... 18

3.3.4 Sequence Diagrams ............................................................................................................... 46

Figure 1: Essential use case diagram ..................................................................................................... 24

Table 1: Schedule for the project ........................................................................................................... 17

CHAPTER ONE: INTRODUCTION

1.2 Background of the Project

1.4 Statement of the Problem

1.5.1 General Objective

1.5.2 Specific Objectives

✓ To make analysis about the current manual system of the Office.

1.6 Methodology and Tools

Our team members decide to use object-oriented methodology. Because:

1.6.1.3 The System Development Model

An interactive web application design requires the following things:

✓ Web Server software

1.6.2.1 Scripting language and Software tools

✓ PHP: - To implement the desired functionality of the server-side implementation we choose

✓ The system allows to record day to day Accidents information.

1.8 Significance of the Project

1.8.1 Benefits for the Organization

✓ Scheduling will be in a simple way.

✓ They can upload information on the web for customers.

1.8.2 Benefits for Societies

✓ Societies get a precise information.

1.9 Feasibility Analysis

1.9.1 Operational Feasibility

1.9.2 Economic Feasibility

1.9.3 Technical Feasibility

1.9.4 Schedule Feasibility

1.9.5 Political Feasibility

1.10 Risk Analysis

1.11 Task Breakdown and Stages

1.12 Work Plan (Gantt chart)

Table 1: Schedule for the project

Estimated Task Durations (in dates)

Apr03- May14- May26- Jun24 Jul9 Sept11-

1.13 Cost Analaysis

No Materials Required Amount Price Per Unit Total Cost

1.13.2 Software Requirements Cost

No Materials Required Price Per Unit

1.14 Organization of the Project

Description of the Existing System and Requirements Gathering

2.3 Major Functions/activities in the Existing System

2.4 Business Rules

2.5 Bottlenecks of the Existing System

2.5.1 Performance Problem

2.5.2 Information Problem

Moges T. Name: __________ Signature: _

Signature: _ Name: _____Signature: _