Final Document

Evelyn Hone College
DESIGN AND IMPLEMENTATION OF AN ONLINE DRIVING SCHOOL

REGISTRATION, DRIVERS LICENSE APPLICATION AND ROAD
ACCIDENTS REPORTING SYSTEM FOR THE DRIVING SCHOOL
ASSOCIATION OF ZAMBIA
Name: Titus Phiri

Student Number:
August 2016
A formal proposal for a dissertation that will be submitted in partial fulfillment of the TEVETA
Diploma in Computer Studies
ABSTRACT
The Driving school association of Zambia is the governing body for all driving schools in
Zambia. They have their offices along the Great East Road of Zambia at Cherise Kids Park just
before the Mandahill Shopping Mall Bridge. A number of driving schools are affiliated to the
association. It is working on affiliating all the driving schools in Zambia.
As it stands, most of the driving schools in Zambia operate independently and some illegally.
This has made it even difficult to reduce the illegal obtaining of licenses. It has also made it very
difficult for the public to know exactly which driving schools in the country are fully registered
as a result many of the drivers that we have on the roads are not fully trained. This has led to the
continue increase of road accidents. The driving schools also have no online system to that could
help them to get recognized and do their bookings for students at the Road Transport Service
Agency (RTSA). This has brought about disorganization in how test are done at the testing
grounds.
This Project looks to address this problem by putting in place an online management system
which will provide an integrated view of the driving schools, RTSA, the driving school
association and the public. It will allow. This will enable organization and easy communication
among all the involved parties.
To help ensure this system run as efficiently as possible, Application Frameworks will be
incorporated in its design. These Frameworks provides a comprehensive configuration and
programming model for building modern high quality applications.
|Page
ACKNOWLEDGEMENT
|Page
Contents
1. INTRODUCTION.................................................................................................................................11
1.1 Overview..........................................................................................................................................11
1.2 Background......................................................................................................................................11
1.3 Scope Statement..............................................................................................................................12
1.4 Problem Statement and Solution.....................................................................................................12
1.4.1 Getting Information and applying to a driving school...............................................................12
1.4.2 RTSA bookings..........................................................................................................................13
1.4.3 Getting road traffic information................................................................................................13
1.5 Aim and Objectives..............................................................................................................................13
1.5.1 Aims..........................................................................................................................................13
1.5.2 Objectives.................................................................................................................................14
1.6 Report Road Map.............................................................................................................................14
1.7 Summary..........................................................................................................................................15
2. LITERATURE REVIEW..............................................................................................................................15
2.1. Introduction....................................................................................................................................15
2.2 To investigate what the Online Driving school Management system..........................................16
2.3. Methodology..................................................................................................................................16
2.3.1. Extreme Programming.............................................................................................................16
2.3.2. Dynamic System Development method...................................................................................16
2.4 Application Development Technologies..........................................................................................16
2.4.1Cascading Style Sheets (CSS):.....................................................................................................17
2.4.2. JavaScript.................................................................................................................................17
2.4.3. HTML..................................................................................................................................17
2.4.4. PHP....................................................................................................................................18
2.4.5. MySql.................................................................................................................................18
2.4. Summary.........................................................................................................................................19
Reference..............................................................................................................................................20
3. OBJECTIVES, ACTIVITIES AND METHODS...............................................................................................21
3.1. Introduction....................................................................................................................................21
3.2. Objective One.................................................................................................................................21
|Page
Activities............................................................................................................................................21
Deliverables: Requirements Specifications............................................................................................21
Findings.............................................................................................................................................22
3.3. Objective Two.................................................................................................................................22
Activities............................................................................................................................................22
3.4. Objective Three..............................................................................................................................23
Activities............................................................................................................................................23
3.4.2. Prototyping..............................................................................................................................23
3.5. Objective Four................................................................................................................................29
3.6. Objective Five.................................................................................................................................29
3.6.1. To Evaluate the new system....................................................................................................29
3.7. Summary.........................................................................................................................................30
4. REVIEW OF OTHER SYSTEMS.................................................................................................................30
4.1. Introduction....................................................................................................................................30
4.2. SOAR Student Online Registration System.....................................................................................31
4.2.1. Overview..................................................................................................................................31
4.2.2. Appearance..............................................................................................................................31
4.2.3. Functionality............................................................................................................................32
4.2.4. Navigation................................................................................................................................32
4.2.5. Usability.......................................................................................................................................32
4.2.6. Features Adopted....................................................................................................................32
4.3. Motor Driving School system..........................................................................................................33
4.3.1. Overview..................................................................................................................................33
4.3.2. Appearance..............................................................................................................................33
4.3.4. Navigation................................................................................................................................35
4.3.5. Usability...................................................................................................................................35
4.4. The Driving school Association of Louisiana website......................................................................36
4.4.1. Overview..................................................................................................................................36
4.4.2. Appearance..............................................................................................................................36
4.4.3. Functionality............................................................................................................................37
4.4.4. Navigation................................................................................................................................38
|Page
4.4.5. Usability...................................................................................................................................38
4.5 Summary..........................................................................................................................................39
5. SYSTEMS ANALYSIS................................................................................................................................39
5.1. Introduction....................................................................................................................................39
5.2. Fact finding techniques...................................................................................................................39
5.2.1. Interviews................................................................................................................................39
5.2.2. Review of documents..............................................................................................................40
5.3. Requirement Specification..............................................................................................................40
5.3.1. Functional Requirements.........................................................................................................40
5.3.2. Non-functional requirements..................................................................................................43
5.4. Analysis...........................................................................................................................................44
5.5. Summary.........................................................................................................................................56
6. DESIGN..................................................................................................................................................57
6.1. Introduction....................................................................................................................................57
6.2. Database design..............................................................................................................................57
6.2.1. Entity Relationship Modelling..................................................................................................57
6.4. Interface Design:.............................................................................................................................62
6.4.1. Home page:..............................................................................................................................62
6.4.2. Main Menu..............................................................................................................................63
6.4.3. Site Map...................................................................................................................................64
6.5. System Requirements:....................................................................................................................65
6.6. Summary.........................................................................................................................................65
7. SYSTEM DEVELOPMENT AND IMPLEMENTATION...................................................................65
7.1. Introduction....................................................................................................................................65
7.2. Front end and Back end technologies.............................................................................................66
7.3. Code Samples.................................................................................................................................66
7.3.1. Database Connection...............................................................................................................66
7.3.2 Login Source Code....................................................................................................................67
7.4. System Architecture.......................................................................................................................69
7.5. Summary.........................................................................................................................................70
8. TESTING.................................................................................................................................................70
|Page
8.1 Introduction.....................................................................................................................................70
8.2 Functional Testing............................................................................................................................70
8.3 Summary..........................................................................................................................................72
9. LEGAL, ETHICAL, PROFESSIONAL AND SOCIAL ISSUES...........................................................................72
9.1 Introduction.....................................................................................................................................72
9.2 Legal Issues......................................................................................................................................72
9.3 Social Issues.....................................................................................................................................73
9.4 Ethical Issues....................................................................................................................................73
9.4. Professional issues..........................................................................................................................73
9.6 Summary..........................................................................................................................................73
10.1. Introduction......................................................................................................................................74
10.2. Chapter Summary and results......................................................................................................74
10.2.1. Chapter 1 Introduction..........................................................................................................74
10.2.2. Chapter 2 Literature review...................................................................................................74
10.2.3. Chapter 3 Objectives, Activities and methods.......................................................................75
10.2.4. Chapter 4 Review of other systems.......................................................................................75
10.2.5. Chapter 5 Requirements Analysis..........................................................................................75
10.2.6. Chapter 6 Design....................................................................................................................76
10.2.7. Chapter 7 Development.........................................................................................................76
10.2.8. Chapter 8 Testing...................................................................................................................76
10.2.9. Chapter 9 Legal, Ethical, Social and professional issues.........................................................76
10.3. Summary.......................................................................................................................................77
11. Conclusion...........................................................................................................................................77
11.1. Introduction..................................................................................................................................77
11.2. Project Management....................................................................................................................77
11.3. Product Evaluation........................................................................................................................77
11.4. Lessons Learnt..............................................................................................................................78
11.5. Challenges.....................................................................................................................................78
11.6. Future recommendations.............................................................................................................78
11.7. Summary.......................................................................................................................................78
REFERENCE................................................................................................................................................79
Websites................................................................................................................................................79
|Page
Appendix A: Project Proposal....................................................................................................................80
Appendix A – Model Diagrams..................................................................................................................80
Appendix B Minutes of Meetings..............................................................................................................91
Appendix C: Current Online Presences......................................................................................................91
Appendix D Sample Code..........................................................................................................................91
Appendix E Screen Shots...........................................................................................................................95
|Page
Figure 1; shows the location of the menu tab and the functionality to edit user profile.............................30
Figure 2; shows tutor registration..............................................................................................................32
Figure 3; shows the assigning of a tutor....................................................................................................34
Figure 4; shows the home page of DSAL and the links to the member registration page..........................35
Figure 5; shows a report of the registered schools.....................................................................................37
Figure 6;Administrators use case diagram (DSAZ)...................................................................................44
Figure 7;rtsa use case.................................................................................................................................46
Figure 8; driving school use case...............................................................................................................48
Figure 9; Instructor Use case.....................................................................................................................50
Figure 10; Student use case.......................................................................................................................52
Figure 11; Public use case.........................................................................................................................54
Figure 12; ERD...........................................................................................................................................58
Figure 13; Relational Schema....................................................................................................................59
Figure 14; Flowchart.................................................................................................................................60
Figure 15; homepage.................................................................................................................................61
Figure 16; Main Menu Design...................................................................................................................62
Figure 17; site map of the application........................................................................................................63
Figure 18; welcome page for system.........................................................................................................79
Figure 19; login page.................................................................................................................................80
Figure 20; wrong details entered...............................................................................................................80
Figure 21; admin home page.....................................................................................................................81
Figure 22; Create user...............................................................................................................................81
Figure 23;View user...................................................................................................................................82
Table 1.......................................................................................................................................................27
Table 2; shows the functional requirements of the system.........................................................................41
Table 3; shows the non-functional requirements of the system.................................................................42
Table 4; Administrator inputs, events and response..................................................................................45
Table 5; RTSA inputs, events and response...............................................................................................47
Table 6; Driving School inputs, events and response................................................................................49
Table 7; Instructors inputs, events and response........................................................................................51
Table 10: Technologies used.....................................................................................................................65
Table 11; Functional testing......................................................................................................................69
|Page
1. INTRODUCTION
1.1 Overview
Over the past years, there have been a number of changes in the road transport and safety sector
following the efforts to improve road safety.
In the year 2001, the Zambian government, through the Ministry of Communication and
Transport, signed a contract with a South African agency (RTSA) to improve road safety in
Zambia.
RTSA has entered into an agreement with the Zambia Transport and Information Services to take
over the process of licensing of drivers.
Over the years, a number of issues involving corruption during the registration process have
arisen.
Driving schools are not involved in the process of making road traffic rules. They are not even
part of the team that makes road user training guidelines. They do not have a strong voice that
would help them to act as one and be part of all the training guide implementation. The driving
schools also find it very difficult to get their students registered at RTSA for road tests.
The formation of the Driving School Association of Zambia (DSAZ) in the year 2010 brought
hope to the driving schools. The association is working on uniting all the driving schools and
representing them as one voice to the government, the public and to RTSA.
The association has its offices in Lusaka along the Great East road.
1.2 Background
Driving School Association of Zambia (DSAZ) is the mother body for all driving schools in
Zambia. It was formed in the year 2010 by a group of driving schools who felt that their interests
were not being met by RTSA. It is governed by its chair lady Mrs Hope Kasese Khumalo. It was
formed so that it could be the voice for all the driving schools in the country.
1.3 Scope Statement
This project will design and implement a system that will allow for the following:
 People wishing to apply to a driving school will be able to see the registered driving
schools on online and apply to them.
 Display information to people who need information about road safety such as road
accidents statistics
 Enable the drivers school association to keep track of all registered drivers schools and
instructors and ensure that they are operating on agreed standards of operation
 Enable driving schools to book for their students going for license tests online.
 This project will not encompass online payments
1.4 Problem Statement and Solution

Currently, driving schools in Zambia do not have systems that can help them to interact with
clients remotely via online applications. This results to people having to physically go around
school by school to apply for driving lessons, physically go to RTSA either through the school or
individually to apply for a license. There has not been a system that can help Driving schools, the
association, the public and RTSA to properly formulate a proper way to communicate and
operate in an orderly manner. They act independently from each other resulting to confusion and
the increase in the cases of corruption.
1.4.1 Getting Information and applying to a driving school

If someone wants to apply to a driving school, they have to physically move around in to look
for a driving school. They are sometimes crooked by people with mushrooming unregistered
schools and forced to register with them. People privileged with the internet usually use the
online business directories to get contacts of the driving schools but still cannot enroll online
because there is no driving school at the moment that offers online student registration. The
system will display schools that have paid a subscription fee and have the license to operate.
|Page
1.4.2 RTSA bookings
In order to book for a test at the RTSA, students have to first do their training at a driving school.
The driving schools do the bookings at RTSA on behalf of the students. Sometimes schools let
their students do the bookings by themselves. This gives room to corruption at RTSA because
the students would try to bribe the instructors at RTSA for a license without doing a driving test.
At the moment, rtsa does not do online bookings for driving tests, one has to physically go to the
rtsa offices to make a booking.
1.4.3 Getting road traffic information

Whenever the public needs information from RTSA or the Drivers school association, they either
have to call the RTSA toll free line or go to the RTSA website which is not so up to date with
information.
This Project will address these problems by designing and implementing an online system that
would provide an integrated view of information about RTSA, the Driving School Association,
driving schools and any road safety information relevant for the public to know.
It will greatly help the public apply to registered schools. It will also help the driving schools to
book for driving tests at rtsa for their students conveniently and also be recognized by the public
as well as be heard by RTSA. The association would greatly benefit from the system because it
will easily manage the driving schools and get proper and relevant information from the public,
from the driving school and from RTSA. RTSA would also greatly benefit from the system
because it will be able to communicate with the institutions responsible for training the drivers
and come up with ways of reducing accidents on the road.
1.5 Aim and Objectives
1.5.1 Aims
The purpose of the project is to design and implement an online system for DSAZ that will
integrate all the parties involved in the training and registering of drivers so as to streamline the
whole process of driving lessons to the obtaining of licenses and reporting of road accidents.
|Page
1.5.2 Objectives
In order to achieve the above aim stated, the objectives below have been identified.
 To investigate what the Online Driving school Management system is
 To find and review similar systems in use
 To discuss systems development methodologies and select one to apply in this project
 To design and develop an online driving school registration, drivers’ license application
and road accidents reporting system for the driving school association of Zambia
 To evaluate the developed system through testing.
1.6 Report Road Map

This report has 11 more chapters which have been structured as follows.
Chapter 2 – Literature Review: this chapter compiled from the results of searching through
literature. It will provide a summary of literature, theories, concepts, approaches, methods and
techniques relevant to the project area
Chapter 3 – Project Objectives, Activities and Methods: The Chapter discusses software
development methodologies and also shows the techniques which were used in order to achieve
each objective.
Chapter 4 – Review of similar existing Systems: The Chapter reviews the similar existing
systems elsewhere that are currently being used.
Chapter 5 – Requirements Analysis: describes the collection of information needed to produce

the system requirements of the proposed solution.
Chapter 6 – Systems Design: discusses the design of the system and the design models used.
Chapter 7 – System Development and Implementations: The Chapter describes the selection
development tools and programming languages used and how the system was implemented.
|Page
Chapter 8 – System Testing: This chapter will describe how the system will be tested and the
expected results when the system is executing.
Chapter 9 – Legal, Social, Professional and Ethical Issues: This chapter describes what Legal,
Social, Professional and Ethical Issues that affect the development of this project
Chapter 10 – Summary and Presentation of Results
Chapter 11 – Conclusion – This Chapter provides the critical evaluations of the entire project and
the lessons learnt.
Chapter 12 provides a fast reference of the contents of all the chapters dealt with.
1.7 Summary
Chapter one provided an introduction to issues related to the driving schools in Zambia, the
driving schools association and RTSA. It also shows how an online system can be used to
implement a solution to the problems mentioned. An outline of what’s to come in the rest of the
report was also provided.
Chapter 2 will compile the results of searching through different types of literature. It will
provide a summary of theories, concepts,
2. LITERATURE REVIEW
2.1. Introduction
This part of the report provides a basic outline of the research done during the project for the
purpose of acquiring an understanding of the subject content i.e. the DSAZ Management System
and its components
|Page
2.2 To investigate what the Online Driving school Management system
Online Driving School Registration, Driver’s License Application and Road Accidents Reporting
System
This is a system that is designed to help the driving school association to manage the affairs of
driving schools, help to reduce road accidents by making sure that driving schools adhere to the
teaching standards. It will also help the students to locate legal, fully registered driving schools
that have well qualified driving instructors to teach them. There are more than a 100 driving
schools in Zambia. The online system will also enable the driving public to apply or register to a
driving school of their choice online
2.3. Methodology
System development methodologies have over the past years evolved from traditional System
Development Life Cycle (SDLC) to agile methodologies. The adopted methodology for the
development of the proposed system is the Agile methodology due to its ability to expose
progress and problems. Rico (2007), defines agile methods as lightweight software design
processes based on small teams using flexible technologies to iteratively improve software using
customer feedback to converge on solutions.
Characteristics of the Agile methodology
2.3.1. Extreme Programming; this is a development approach that is more of code

oriented rather than design oriented. Testing is thus made easy with extreme programming.
Abrahanson (2002)
2.3.2. Dynamic System Development method (DSDM); DSDM is an agile project

management method and delivery framework that aims to deliver the right solution at the right
time. Richard( 2010).
2.4 Application Development Technologies

This section of the report describes the technologies used to develop the system. It takes into
consideration both the front and backend technologies used in the whole process.
|Page
Front end technologies are the user interaction processes that enable a user to interact with the
system. These technologies include the tools used in the designing and implementation of forms;
reports input responses and the look and feel of the application.
Frontend processes usually run on the client machine while the actual process is executed in the
backend by backend technologies
The frontend technologies used in the design and implementation of the system are;
2.4.1Cascading Style Sheets (CSS): CSS is used to define styles for your web pages,
including the design, layout and variations in display for different devices and screen sizes. It
saves a lot of work! With an external style sheet file, you can change the look of an entire
website by changing just one file! CSS describes how HTML elements are to be displayed on
screen, paper, or in other media. CSS saves a lot of work. It can control the layout of multiple
web pages all at once.
2.4.2. JavaScript is an object- and prototype based programming language created by

Brendan Eich at Netscape. Although similar, JavaScript is not Java. Unlike Java, JavaScript is
not a full programming language; its main used in the web environment and even then it is used
in conjunction with another language, usually HTML. JavaScript is an excellent language to use
for functionality such as rotating pictures on a page, error handling when inputting information
in forms and setting responses to certain events on a web page. Robbins( 2006)
2.4.3. HTML : HTML is the language for describing the structure of Web pages. HTML gives
authors the means to:
o Publish online documents with headings, text, tables, lists, photos, etc.
o Retrieve online information via hypertext links, at the click of a button.
o Design forms for conducting transactions with remote services, for use in
searching for information, making reservations, ordering products, etc.
o Include spread-sheets, video clips, sound clips, and other applications directly in
their documents.
|Page
Back end technologies are mainly processes that interact with database creation and
manipulation, connections and storage. They provide support to front end technologies for
services such as addition, retrieval, updating and deleting information or data.
The backend technologies used in the design and implementation of the system are;
2.4.4. PHP is a server side scripting language that was designed for creating dynamic websites.
It runs on the server and processes instructions contained in a web page before that page
is sent to a user’s web browser. PHP can also “talk” with various database systems,
giving developers the ability to generate dynamic pages based on the results of an SQL
query. Moncur (2009).
2.4.5. MySql : MySql is the most popular open source SQL database management system
Telecom companies and forward-thinking corporate IT Managers because it eliminates
the major problems associated with downtime, maintenance and administration for
modern, online applications.
o Backup: It’s easier to setup automatic backups in Microsoft SQL Server and
ensure there’s a point of restore.
o Security: Because SQL Server integrates with Windows Active Directory, it is
quite easy to determine access to the databases via logins for the users in the
security module of the database management system.
o Auditability: You cannot copy or duplicate the SQL Database without leaving an
audit trail which administrators can easily review and track the users who logged
in and made any changes.
o Scalability: SQL Server can handle much larger databases with large amounts of
data; it is easy to grow a SQL server database as the data demands of the
organization increase.
|Page
Weaknesses of MySql
o Cost: License and implementation costs of SQL are massive add to that the skills
of administrators is not cheap either.
o Implementation time: It takes long to setup a SQL Server system and this can
impact organizations in cost and projects.
o Complex environment: SQL Server environment is complex and requires users
with a significant amount of knowledge and skills to work with.
2.4. Summary
The chapter described Online Driving School Registration, Driver’s License Application and
Road Accidents Reporting System, the involved parties and its components. It also describes the
technologies used in the development of the proposed system as well as reviewing their
weakness and strengths.
|Page
Reference
Richards, K. (2010) Agile Project Management: Intergrating DSDM Atern into existing Prince2
environment. Bristal;
Robbins J. N. Web Design in a Nutshell 3rd Edition (2006), O’Reilly Media Inc., Sebastopol,
CA95472
http://davidfrico.com/rico07 Date accessed (12/03/2016)
http://www.w3schools.com/html/html_intro.asp Date accessed (12/03/2016)
http://mashable.com/2014/01/21/learn-programming-languages/ Date accessed (15/03/2016)
|Page
3. OBJECTIVES, ACTIVITIES AND METHODS
3.1. Introduction
This chapter is aimed at outlining and explains the methods that will be used to achieve the
different objectives. It will also discusses the various methodologies used for software
development and seek to also justify the chosen methodology for the development for this
project.
3.2. Objective One

To analyze similar online systems used by driving school associations
Activities
 Conduct interviews with stakeholders at RTSA (2 days)
 Review documentation (2 days)
 Read Literature on types and methods of online drivers licensing systems
 Interview employees at RTSA, driving school employees and driving instructors, students
at driving schools and the president of the driving school association.
Deliverables: Requirements Specifications

The first activity was to find out if there was any driving school mentioned in the scope has an
online registration system.
If an online system was found, an analysis of how these systems help the schools operate and
interact with the client was done to determine what specifications would need to be achieved on
the Online Driving School Registration, Driver’s License Application and Road Accidents
Reporting System.
The second objective was achieved by asking some members of public and road users about their
experience with the process of obtaining a driver’s license, their experience with driving schools
and what changes they would like to see in the new online system.
|Page
We also asked RTSA employees on how to help reduce road accidents using the new system
after evaluating the current method of obtaining drivers licenses.
We lastly also interviewed the president of the diving schools association on her views of
maintaining a good operating standard among the driving schools and how to make sure that they
give the best driving lessons to their students
Findings
This research revealed that the furthest the driving schools in the country could go was to have a
page on Facebook. The association also had a static website which is no longer in operation.
RTSA has a website that it periodically updates.
This research further revealed that the public and the driving school students would appreciate an
online system that would list all the registered schools, help them to register to a driving school
online, enable the driving schools to make bookings for tests at RTSA, inform them through the
system whether or not they have passed after the tests and be able to help them interact with the
association for driving schools and RTSA.
RSTA employees also revealed that they would appreciate if the system could help locate the
schools where each driver did their driving lessons so that they could be able to see which
schools produced the best drivers and which schools produced the most road offenders.
The Driving School association revealed that they would appreciate a system that would enable
them to have a record of all the driving schools, driving instructors and a report of the road
accidents, a system that would intergrade the operations of RTSA, the driving schools and the
association itself so that it could have a voice and be up to date with information form the two
parties.
3.3. Objective Two

To review similar systems
Activities
 Browse internet for information on similar systems
|Page
 Review system documentation for similar systems that are implemented elsewhere
 Compare the systems
 Select suitable features to implement
This objective aimed at evaluating other available systems of similar nature in order to assist
with selecting and exploring features that would be incorporated in the proposed system. By
reviewing the systems that have already been implemented, it would help in not having to
reinvent the wheel by redeveloping what already exists and also avoid making similar mistakes
to develop a robust system.
In order to achieve this, thorough research through the internet as well as documentation of
existing systems would have to be done. After comparing the systems suitable features were
selected to include in the final system.
3.4. Objective Three.

To review different systems development methodologies for the purpose of recommending one
to use.
Activities
 Review literature on different system development methodologies
 Compare different methodologies
 Select best methodology to use
3.4.2. Prototyping
Prototyping is the process of building a working replica of a system. The prototype is the
equivalent of a mock-up in the hardware world. Purcell (1995).
The requirements of the system are obtained from the users during the early stages. A working
system is then developed from the initial requirements obtained. When the system is presented, it
is then studied and reviewed in order to see if there could be any other changes made or if it
could be given a go ahead.
|Page
Strengths of prototyping
 It promotes user involvement and participation as well as communication with the

stakeholders.
 It helps to identify difficult and missing functionality because it encourages works on a
problem in modules.
 Enables quick implementation of an incomplete, yet functional application
 Encourages innovation and flexible design.
Disadvantages of prototyping;
 Requirements may frequently change. This delays the full implementation of the system
because changes in requirements would mean redoing a part of the project
 Identification of non-functional requirements is difficult to document.
 Users expect the performance of the final system to the exactly as the prototype.
Where it is appropriate
Prototyping is useful when it comes to demonstrating technical feasibility when the technical risk
is high and also to better understand and extract user requirements. (Purcell, 1995) Prototyping is
also useful where the project requires some interaction with the users to help in understanding
the way the system responds to input from users.
3.4.3. Waterfall/Linear
Waterfall is an approach to development that emphasizes completing a phase of the development
before proceeding to the next phase. It is a sequential step by step approach. (Purcell, 1995)
Strengths
 It being a step by step or sequential process, it makes it easy to allocate resources such as
developers, time and resources in the project.
 It is measurable.
 Provides adequate documentation including change management during the project.
|Page
Weaknesses
 The waterfall method requires that all the resources and requirements are put in place
before the project can commerce
 Project duration is usually extended as all phases must be completed and one phase can
have many requirements and change processes to be adhered to.
 It lacks flexibility because it is
The waterfall method is ideal for a project or system whose requirements are clearly and very
well understood. It is also suitable for an experienced development team.
3.4.4. Rapid Application Development (RAD)

Rapid Application Development RAD is a methodology that aims at satisfying the business need
for the system. It promotes user involvement during the development process. Prototyping is also
used in RAD.
Advantages of RAD;
 It mainly focuses on the important elements from the user’s perspective.

 A system is developed at a low cost because the approach produces the system very
quickly
 It balances both the user requirements and the business requirements
 Designs can be changed at any time to suit the user requirements and demands.
Disadvantages of RAD;
 the speed at which project is developed in order to meet deadlines may compromise the
quality of the project
 The project may end up with more requirements than usual.
 It has a tendency of pushing the difficult activities forward.
|Page
 It is difficult to always have users available and this can hamper the process and possibly
success of the project. (Purcell,1995)
RAD is often suitable in small-to-medium scale projects and where users have detailed
knowledge of the area of application. RAD is also appropriate when senior management has a
buy in and committed to have users available in the project for adequate involvement.
3.4.5. Comparison of Methodologies
Although the outlined methodologies are meant to achieve one goal or common objective of
producing a working system, there are a number of factors i.e. similarities and differences that
determine which methodology to use and these are usually considered when making the
selection.
The table below summarizes some of these factors comparing the different methodologies.
Table 1
Features Waterfall Prototyping Rapid Application

Development (RAD)
Flexibility Low High High
Requires complete Yes No No
definition of
requirements at onset
Active User Low High High
Involvement
Early functionality No Yes Yes
Cost Low High Low
Time/Duration of Long Short Short
|Page
Project
Comparison of features of the different system methodologies based the strengths and
weaknesses of methodologies.
Features adapted from ‘Purcell, 1995’
3.4.6. Selected Methodology and Justification

From the vast number of available development methodologies to use, I believe RAD was more
suitable to producing the product in my project. From the reasons highlighted below and related
to the nature of this project I am convinced it would be appropriate.
The project has a short and fixed duration: this project encompassed a very short period and had
a fixed delivery date for the product.
RAD would enable me to interact with the users. This will be a plus because it will also help me
in knowing if or not the project is meeting the user requirements at each stage or not
3.5. Objective Four

3.5.1. To design the online system for DSAZ the following activities were to be done
Activities
 Create design models: ERD, Class Diagrams, and Use Cases

 Develop code for system
This involved developing a blue print of the system by modeling designs of the back end
databases which included relationships as depicted on Entity relationship diagrams, class
diagrams of the classes used as well as use cases that described the interactions of the system
activities.
The design specification guided in the development of code based on the logic of the different
models that were created. All development was done using PHP, HTML and javascript.
|Page
3.6. Objective Five
3.6.1. To Evaluate the new system

Activities
 Perform testing i.e. unit, module and system tests

 Post implementation testing: comparing results with test plans
Testing is critical in evaluating the success of an application; by ensuring that application is

tested for bugs and application errors we avoid rolling out or commissioning a problematic
system to clients/users.
This meant test plans had to be developed, tests carried out and results compared with the system
giving the developer a chance to correct the errors detected before commissioning.
3.7. Summary
The chapter outlined the different objectives set for the project and reinforced the objectives as
described or introduced in the proposal. These objectives were critical in achieving the goals of
the project and each contained a number of activities required to complete them.
The next chapter reviews some similar systems that have been developed with the same concepts
as the proposed system with similar features.
4. REVIEW OF OTHER SYSTEMS
4.1. Introduction
This chapter of the report discusses different systems with similar concepts implemented
elsewhere. This evaluation will assist in learning from the similar systems i.e. to incorporate
useful similar features and also avoid any likely mistakes that may have been made during
design or development of the systems.
The area on which the evaluation was focused was a simple overview, the appearance,
navigation, usability and functionality.
The three systems that were reviewed in this chapter are ;
 SOAR Student Online Registration System on
|Page
http://1stsystem.com/soar_system_solution.html
 Motor Driving School System on
http://nevonprojects.com/motor-driving-school-system/
 The Driving school Association of Louisiana website
http://www.dsal.org/
4.2. SOAR Student Online Registration System
4.2.1. Overview
The SOAR student online registration system was designed to enable academic institutions to
register students online and manage their academic activities. It enables students to register to
classes and keep track of their academic progress. The main actors in of the system are the
student, tutor and administrator
4.2.2. Appearance
The application has a user-friendly interface. It has a list of menu options to the left of its screen
that are easily accessible to the user. Once logged in, it displays the users’ details and allows the
users to edit their profile details as shown in figure.
|Page
Figure 1; shows the location of the menu tab and the functionality to edit user profile
|Page
Data capture page adapted from http://1stsystem.com/soar_system_solution.html
4.2.3. Functionality
The functionality of the system consists of a number of things such as; capturing of user details,
assigning students to classes and lectures, tracking of students’ progress, viewing of students,
viewing of students and their records. It also enables administrators to manage student
registration, and to manage the school. Professors are able to manage students’ grades, and
attendance.
4.2.4. Navigation
The application has got a menu grid at the left of the screen as shown in figure 1. This grid has
links that a user can select from in order to go to the page that they wish to go to. It also has a
drop down menu at the top right of the screen that enables the user to sign out of the system.
4.2.5. Usability
The responsiveness of the website enables the user to move from one textbox or for to another
using the tab key. Users can complete forms using the autocomplete functionality and
predetermined entries that can be picked from the database. The system also has regular buttons
used for saving or submitting information.
4.2.6. Features Adopted
 The progress view. A student is able to see the status of their academic progress. This is a
very useful functionality because a student is kept aware of their academic status
 The interface display was helpful in that it gave me a guideline in how to place the menu
and the links in the new system.
|Page
4.3. Motor Driving School system
4.3.1. Overview
This Motor Driving School System is a system designed by Nevon projects. System helps
driving schools to automate the manual tasks of maintaining and managing clients. The
application helps in the assigning of instructors to students and also enables instructors to assign
a training slot available to a student.
The system enables students to register online using a registration form. Once a student registers
to the system, a notification is sent to the email address they provide.
4.3.2. Appearance
The system is a web based system that uses. It was developed in php. The system has one log in form on
the home page. Once logged into the system, each profile shows the details of the person logged. Each
page has a menu bar at the top section of the page
The Motor Driving School management system enables users to register online using a
registration form. It enables the administrator to register a tutor as shown in figure 2. The system
also enables a driving school to assign tutors to students as shown in figure 3, view students,
adding tutors and select a training slot. The system also enables students to make online
payments to the school. A school is also able to view the list of all its students and the list of all
tutors
Figure 2; shows tutor registration
|Page
Data capture page adapted from http://nevonprojects.com/motor-driving-school-system/
|Page
Figure 3; shows the assigning of a tutor
Data capture page adapted from http://nevonprojects.com/motor-driving-school-system/
4.3.4. Navigation
The system provides buttons and indicators to assist users find their way around the system
through
Each page has a menu bar that enables a user to navigate to the task that they want for instance,
if a user wants to view their user details they can go to the menu bar and select view user details.
A user is directed to their profile by entering their log in details and then selecting log in
4.3.5. Usability
The system is a very user friendly system. It is not sophisticated and it has a very user friendly
interface. Simple language and on its GUI was used. All users log in using the same form. This
makes it simple because one will not have to start looking for a different type of log in form in
order to log into the system.
|Page
 Assigning of tutors to a student
 View registered students
 Approve applications from the students
 Online registration of students
4.4. The Driving school Association of Louisiana website
4.4.1. Overview
The Driving school Association of Louisiana is an association that was formed in order to help
create a safer driving environment in Louisiana through proactive driver education training
methods as well as to raise the standards of all Driving Schools and their Instructors. The
association works in cooperation with the Office of Motor Vehicles and other Road safety
stakeholders.
4.4.2. Appearance
The organizations website was designed in php. It enables users to login and also apply for
membership as shown in figure 4.
Figure 4; shows the home page of DSAL and the links to the member registration page
|Page
Data capture page adapted from http://www.dsal.org/index.html
The system allows users to register online for membership as shown in figure 4 and also gives
reports of the registered driving school members and instructors within Louisiana as shown in
figure 5. The report serves as a directory to people willing to apply to driving schools.
|Page
Figure 5; shows a report of the registered schools
Data capture page adapted from http://www.dsal.org/pdfs/members.pdf
4.4.4. Navigation
The application is accessible to the public. The welcome page has a number of links. Once a user
clicks on a link, it directs him to the function that is linked to it. The user can use bread crumbs
that enable the user to track back to previous pages. Since the system is accessed using a website,
a user is able to alternate between pages using the back and the forward buttons found in the
browser.
4.4.5. Usability
The system is very easy to use and the reports are very useful in that they provide the clients with
direct information for the driving schools.
|Page
 Reports and its ability to show all the registered school and their contact details.
4.5 Summary
This chapter revealed three systems that are similar to the proposed project. The concept of the
reviewed system is almost the same. These systems have useful features that are useable in the
proposed system such as the reports, student registration and other functions
The next chapter discusses the analysis of the system.
5. SYSTEMS ANALYSIS
5.1. Introduction
This chapter outlines how the requirements of the proposed system used in order to meet its
objectives were derived taking into account both functional and non-functional requirements.
In this chapter we will also explore some fact finding techniques and also illustrate the
requirements by the use of modeling.
5.2. Fact finding techniques

The fact finding techniques are the methods used to acquire information that is to be used for the
purpose of determining the requirements of the proposed system.
5.2.1. Interviews
Interviews are a very essential method of gathering information in projects of many kinds
regardless of the subject of research. Interviews were used to provide an insight on the
challenges that users face in the current system. The current system does not provide for
|Page
accountability and the reporting of accidents is not possible unless done manually. The interview
process also unveiled the challenge of data capture that the users were facing
5.3. Requirement Specification

This chapter mainly focuses on the functional and non-functional requirements of the proposed
system.
5.3.1. Functional Requirements

Functional requirements refer to the fundamental functions a system is able to perform based on
the users’ needs. Bennet (2005), describes functional requirements as functionality that a system
is expected to perform.
For the proposed system the functional requirements were grouped according to the user
categories and included the outlined below;
 System Administrators (DSAZ PRESIDENT )
 RTSA staff
 Driving School Manager
 Instructor
 Students
 The public
Systems Administrator (DSAZ) requirements:

 System should authenticate the users. The home page will have a login form that will
request for the users name and password in order to log in.
 Create Driving School.
 Create User
 Approve or dis approve applications
 View users
 View Reports
|Page
 View Messages
 Delete Driving School.
 Delete User
RTSA Staff requirements:

 System should authenticate the users. The home page will have a login form that will
request for the users name and password in order to log in.
 Approve or disapprove a booking for a test that is made by a driving school instructor on
behalf of the student.
 Enter information about road accidents.
Driving School Manager requirements:

 System should authenticate the users via a log in form prompting users for correct
username and password
 Approve or dis approve applications from the public to enroll to the driving school
 Assign an instructor to a student
 View students training progress
 Message students and also receive messages from students
Instructor requirements:
 View students assigned to them
 Make bookings for tests at RTSA for the students
 View whether or not a student has been awarded license or not
|Page
 Interact with the students
Student requirements:
 Apply to a driving school of his or her choice
 Interact with instructor and driving school manager
 View status of the RTSA bookings made on behalf of them by their instructor
The Public user requirements:

 Blog after entering their details such as email address
 Browse through the messages meant for the public to view
 Create an account in order to apply
Functional Requirements describe what a system does or is expected to do, often referred to as
its functionality (Bennett, 2005).
Table 2; shows the functional requirements of the system
Functional Requirements
Creation and deleting users The administrator of the system will be able
to create new users to the system. The users
of the system are students, driving schools,
RTSA, the public and instructors. The
Administrator will also be able to delete the
users
Registering and deregistering of driving The Administrator will be able to register
schools schools to the system. Students will be able
to browse for a school of their choice and
|Page
apply online.
The administrator will also be able to
deregister driving schools from the system.
Assigning of students to an instructor The system will enable the driving school to
assign a student to an instructor for driving
lessons
Booking a slot for tests at RTSA for Instructors will be able to do online
students bookings for their students to conduct tests
at RTSA.
Entering and retrieving of statistics of RTSA will be able to enter the road accident
accidents records and the administrator at DSAZ will
be able to view them according to date and
according to the school where the students
graduated from
5.3.2. Non-functional requirements

Non-Functional Requirements are those that describe aspects of the system that are concerned
with how well it provides the functionality required (Bennett, 2005).
Table 3; shows the non-functional requirements of the system
Non-functional requirement Description

Security The system will be able to control user
account access. This will be achieved using
passwords and controlling access levels
Capacity The system will be able to manage multiple
transactions at a goal and store them without
having any negative effects on its
performance.
Extensibility It being a very new system, it will be
subjected to a lot of change in terms of
additions and subtractions to its functionality.
The system will be able to handle these
changes without distorting existing data and
functionalities.
Data Recovery The system will be able to recover from
critical failure when it crashes. There will be
able to achieve recovery by database restore.
Data integrity The system will be able to regulate the type of
data entered through input validation that will
be in every form.
|Page
5.4. Analysis
The analysis section of this chapter basically utilizes use cases (figures 7, 8, 9, 10 and 11 ) to
model the requirements of the system, this is aimed at outlining the way the system will perform
functions from the angle of the users. As already highlighted, the category of users includes the
following:
 System Administrators
 RTSA
 Driving School
 Instructor
 Student
 The public
|Page
Figure 6;Administrators use case diagram (DSAZ)
Approve /
disapprove
<<Include>>application
<<Include>>
Create
<<Include>>
user
<<Include>>
View
user <<Include>>
<<Include>>
Register
Driving School
LOGIN
<<Include>>
<<Include>>
<<Include>>
Deregister
Driving
School <<Include>>
View
Message
Delete
user
View
Reports
|Page
Actor: Administrator
Precondition: Should be logged in and must be admin
Post condition: User must be able to perform the following functions.
 Approve / disapprove applications from the pubic
 Create user. The user could either be an instructor or driving school manager
 View users
 Register Driving school to the system
 Edit Driving school
 Delete Driving School from the system
 View Message
 Delete user
 View Reports
Table 4; Administrator inputs, events and response
Input Events from Finance Staff System Events and Response

Login System login form and prompts the user to
enter a valid username and password.
User enters valid username and password and System validates details entered using
submits existing user information stored in the
database. Access is granted if the details are
correct and Administrator menu is displayed
|Page
Figure 7;rtsa use case
Approve /
disapprove
bookings for
tests
<<Include>>
LOGIN
<<Include>>
ENTER RECORDS OF
ROAD ACCIDENTS
<<Include>>
READ AND SEND

MESSAGES
|Page
Actor: RTSA
Precondition: Should be logged in and must be a RTSA employee
Post condition: User must be able to approve / disapprove bookings for tests.
 Enter records of road accidents

 Read and send messages
Table 5; RTSA inputs, events and response

correct the RTSA menu is displayed
|Page
Figure 8; driving school use case
Approve /
disapprove
application from
Student
<<Include>>
Assign an
instructor to a
student <<Include>>
LOGIN
View students
<<Include>>
training progress
<<Include>>
<<Include>>
Interact with
Students
View Student
report from
RTSA
|Page
Actor: Driving School Manager
Precondition: Should be logged in and must be a driving school manager
Post condition: User must be able to view students
 Must be able to approve or disapprove an application from student.
 Must be able to view instructors.
 Must be able to assign an instructor to a student.
 Must be able to view students training progress.
Table 6; Driving School inputs, events and response

correct the driving school managers menu is
displayed
|Page
Figure 9; Instructor Use case
View students
assigned to
instructor
<<Include>>
LOGIN
Make bookings
for tests at RTSA <<Include>>
for the students
<<Include>>
View whether or not <<Include>>

a student has been
awarded license or
not
Interact with the

students
assigned to
instructor
|Page
Actor: Instructor
Precondition: Should be logged in and must be an instructor
Post condition: User must be able to view students assigned to him/her
 Must be able to make bookings for tests at RTSA on behalf of the student
 Must be able to interact with assigned students
Table 7; Instructors inputs, events and response

correct the Instructor menu is displayed
|Page
Figure 10; Student use case
Apply to a
driving school of
choice
<<Include>>
<<Include>>
View status of
the RTSA
bookings made
on behalf of
View & Interact

with instructor
and driving
school manager
|Page
Actor: Student
Precondition: Should be logged in and must be a student
Post condition: User must be able to apply to a school of choice,
 View bookings made at RTSA
 Interact with the instructor and driving school management
. Input Events from Student System Events and Response

User enters valid username and password and System validates details LOGINentered using
correct and Students menu is displayed
<<Include>>
|Page
Figure 11; Public use case
Apply to be a
student
<<Include>>
<<Include>>
Apply to be an
Instructor
Create an
account
<<Include>>
Apply to be a
driving school
Enter details
such as email
address
Browse through
the messages
meant for the
<<Include>>
public to view
Blog
|Page
Actor: Public
Browse through the messages meant for the public to view
Precondition: Should be enter details such as email address

Post condition: User must be able to perform the following tasks
 Blog
Precondition: Create an account

Post condition: User must be able to perform the following tasks
 Apply to be a student
 Apply to be an Instructor
 Apply to be a driving school

Enter email address System input form prompts the user to enter
an email address and name
User enters email and submits System allows user to post a message
User navigates to account registration and System registration form and prompts the user
enters valid details to enter valid information to create an
account.
The user can choose to apply as a student to a The system provides a form that allows a user
school of their choice or to as a Driving to enter details of registration for the user type
school owner they want. (Driving school owner, Instructor
or student)
5.5. Summary
The analysis provided the much needed details of what the system design would focus on. It
highlighted the key requirements of the system for example what user performs what function.
The chapter brought to light that one has to be an administrator in order to create a user and that
|Page
one has to create an account in order to apply to be a driving school owner or to apply to a
driving school of his/her choice as a student. From the analysis I was able to understand the users
accessing the system and their particular roles in the system i.e. when and how they interact with
the system as demonstrated in the use case diagrams.
The next chapter describes the design of the proposed system.
6. DESIGN
6.1. Introduction
Several design models will be used to illustrate the how functional and non-functional
requirements are attained by the proposed system in this chapter.
6.2. Database design

The Stackoverflow website defines Database design as “the process of specifying the logical
and/or physical parts of a database. The goal of database design is to make a representation of
some "universe of discourse" - the types of facts, business rules and other requirements that the
database is intended to model.”
Database design is the method in which all the necessary data to be used in the system as well as
the relationships between that data. To sufficiently achieve this Entity relationship modelling
was used for the design of the database.
6.2.1. Entity Relationship Modelling

Firstly, all the entities and their attributes are identified. After these are identified the
relationships between the data entities are then identified.
|Page
Constraints of the relationships between the entities are then identified.
Listed below are the identified entities with their attributes to be used in the design of the
Database:
USERS (User ID, User Type)
DRIVING SCHOOL (School ID, User ID)
INSTRUCTORS (Instructor ID, User ID, School ID)
STUDENTS (Student ID, Application ID)
APPLICANTS (Applicant ID, User ID)
NOTIFICATIONS (Notification ID, User ID)
RTSA BOOKINGS (Booking ID, Student ID, School ID, License ID)
RTSA ACCIDENTS (Accident ID, Licence ID)
Business rules:
1. A Student can only belong to one driving school at a time
2. A student can only have one license
3. A driving school can have as many students
4. One driving school can have many instructors
5.
|Page
The diagram below is the Conceptual model for the database.
Figure 12; ERD
|Page
The above diagram shows the entities of the online system with their primary attributes. The
diagram also shows the relationships between the entities. To show the logical relationship
between the entities, we will use a logical schema that will show both the primary key attributes
and the foreign keys which indicate how the entities are logically related.
Primary key attributes are underlined while the foreign key attributes are coloured greened.
Figure 13; Relational Schema
|Page
6.3. Flow Chart
Below is the flow chart for the system.
Figure 14; Flowchart
The flowchart above show the sequential flow of transactions in the system from the beginning
starting point to the end taking into consideration all the process the transaction is subject to
undergo.
|Page
6.4. Interface Design:
The interface design helps to show and understand the features of the system that the user will
interact with as they operate it. The main goal of this design is to enable users to understand the
graphical setup of the system. It will help the users not to get confused as they navigate from
page to page.
6.4.1. Home page:

Figure 15; homepage
FUNCTION 1 FUNCTION 2 FUNCTION 3 FUNCTION 4
User name
USER NAME
Password
PASSWORD Keep me logged in
SIGN INLOGIN CANCEL

CANCEL
|Page
The home page the welcome page or the page that a user first accesses when they use the system.
It gives a brief overview of the whole system.
Below is the diagram of the conceptual design.
6.4.2. Main Menu

Figure 16; Main Menu Design
LOGO
FUNCTION 1 FUNCTION 2 FUNCTION 3
FUNCTION 4 FUNCTION 5 FUNCTION 6
|Page
The main menu is the page that contains a list of all the functions of the system or tasks that can
be performed by a user when they log onto their account.
6.4.3. Site Map

Figure 17; site map of the application.
|Page
6.5. System Requirements:
Hardware
 Laptop
 Desktop PC
 Server
 Smart phone
Software
 windows operating system; Windows 7 and above

 Microsoft SQL Server
 Web browser. (Mozilla fire fox, Google chrome or UC web browser)
6.6. Summary
This chapter described the system design. A number of tools such as the flow chart, entity
relation diagram have been used to explain the different component of the systems. The
components talked about in this chapter are; database and the interface, it also shows the activity
diagrams, the hardware and software requirements.
The next chapter discusses the implementation of the designs that have been disclosed in this
chapter.
7. SYSTEM DEVELOPMENT AND IMPLEMENTATION
7.1. Introduction
This chapter describes the front and back end technologies that were used during the
implementation of the system. These technologies are explained in chapter 2. In this chapter we
will also justify why the stated technologies were used and we will also display some samples of
the code used.
|Page
7.2. Front end and Back end technologies
Below is a summary of the technologies used, how and why they were used.
Table 10: Technologies used
Technology Purpose Why

PHP & Hypertext Markup HTML is what was used in The 2 technologies allow
Language (HTML) describing the rendering of separation of static data or
the pages while PHP was text from the code behind the
used in the development of pages.
dynamic web pages.
Cascading Style sheets (CSS) CSS was used to for styling CSS makes it easier to make
the pages and how they changes or define a style
would be rendered. because one change applies to
a number of items on a
number of pages. It also
brings about consistency in
terms of appearance and
styling.
JavaScript JavaScript was used for JavaScript helps to enforce
validating the forms. validation on the input forms.
MS SQL Server MySQL Server was used to SQL Server helps to improve
create the database and its Security. Its ability to
tables as well as enabling the integrate with Windows
querying of the database and Active Directory makes it is
implementing security and quite easy to determine how
access control to the database. the database is accessed.
7.3. Code Samples

This part of the chapter provides some sample code used in the technologies listed above.
7.3.1. Database Connection

<?php
$server='localhost';
$username='root';
$password='';
$database='zdsa';
|Page
#Connect to the MySQL Server
$MySQLcon=mysqli_connect($server,$username,$password) or die("Cannot Connect to
MySQL Server. This is due to invalid host name Defined");
#Select Database from Server
mysqli_select_db($MySQLcon,$database) or die("Could not select the Database Name: ".'[
'.$database.' ]'." Specified... No such Database Name found on the MySQL Server");
?>
7.3.2 Login Source Code
case "login":
$username=$_POST['username'];
$password=$_POST['password'];
$query=mysqli_query($MySQLcon,"Select*from Users WHERE Username='$username' and

Password='$password'");
$rows=mysqli_num_rows($query);
if($rows==0){
$errorMessage='Invalid Username or Password Supplied.. Please Enter Correct Login

Details and then Try Again Later!';
}
else{
$errorMessage='';
$dr=mysqli_fetch_assoc($query);
$userid=$dr['UserID'];
$usertype=$dr['Usertype'];
$_SESSION['userid']=$userid;
$_SESSION['usertype']=$usertype;
$_SESSION['username']=$dr['Username'];
$_SESSION['password']=$dr['Password'];
# END ---------------------------------------------------------------------------------
|Page
7.3.3. CSS
/*Defaults Styling*/
body {font:12px/17px Arial, tahoma; color:#333; background:#ccc; padding:40px 20px 20px

20px;}
fieldset {background:#f2f2e6; padding:10px; border:1px solid #fff; border-color:#fff #666661

#666661 #fff; margin-bottom:36px; width:700px;}
input, textarea, select {font:11px/11px tahoma; padding:0;}
fieldset.action {background:#9da2a6; border-color:#e5e5e5 #797c80 #797c80 #e5e5e5; margin-

top:-20px;}
legend {background:#bfbf30; color:#fff; font:17px/21px Calibri, Arial, Helvetica, sans-serif;

padding:0 10px; margin:-26px 0 0 -11px; font-weight:bold; border:1px solid #fff; border-
color:#e5e5c3 #505014 #505014 #e5e5c3;}
label {font-size:11px; font-weight:bold; color:#666;}
label.opt {font-weight:normal;}
dl {clear:both;}
dt {float:left; text-align:right; width:125px; line-height:25px; margin:0 10px 10px 0;}
dt2 {float:left; text-align:right; width:115px; line-height:25px; margin:0 10px 10px 0;}
dd {float:left; width:450px; line-height:25px; margin:0 0 10px 0;}
dd2 {float:left; width:200px; line-height:25px; margin:0 0 10px 0;}
#footer {font-size:11px;}
#container {width:700px; margin:0 auto;}
|Page
/*##########################################
Script: Niceforms 2.0
Theme: StandardBlue
Author: Lucian Slatineanu
URL: http://www.emblematiq.com/
##########################################*/
7.4. System Architecture

The diagram below illustrates the architecture of the system. It shows how the user or client
computer connects to the server and accesses the database.
When the web browser is run and the url for the online system is entered, the web browser
communicates with the web server that later connects with the MySql database. The web server
then sends back to the client computer through the browser the information retrieved from the
database.
DATABASE
CLIENT
COMPUTER
WEB SERVER
|Page
7.5. Summary
The system was developed using the PHP, HTML, CSS, MySql and javascript which was used
for the validation of forms the chapter also stated why the technologies were used. Some samples
of the code used in the system were also displayed in this chapter. The architechture of the
system and what it comprises of was also.
The next chapter focuses on the system testing and the methods of testing that were used in order
to see to it that the system meets the requirements of the users.
8. TESTING
8.1 Introduction
In this chapter, we will be more focused on the types of tests that were performed on the Online
Driving School Registration, Driver’s License Application and Road Accidents Reporting
System so as to ensure that it meets the user requirements highlighted in the design.
8.2 Functional Testing

The table below shows the steps that were taken and the results attained during the functional test
process
Table 11; Functional testing
Component to Reason For Test User Input Expected Outcome Seen Mark
Test Outcome
Customer and Instructor Functions
Students To ensure that Username Message of Message of PASS
Account the new students First name account being account being
Creation are able to create Last name created created
accounts and are Password successfully. successfully.
able to use the Email address
system Physical
address
Phone Number
Date of Birth
Student To ensure that Emailed Account Account PASS
Account details entered verification activation activation
Verification such as email code message and message
address have not User name application Application
already being main menu main menu
|Page
used in the window
system by aby
other student.
User Login To make sure Correct User account User account PASS
that only registered menu is menu is
registered users Username and displayed displayed
can sign into the Password are
system entered
User Login To make sure Correct Login Error Login Error pop PASS
that only registered pop up up message is
registered users Username and message is displayed
can sign into the Password are displayed
system entered
Students To ensure that a Select a school Confirmation Confirmation of PASS
selection of student is able to of choice of application application is
school apply to a school is sent to the sent to the
of choice student. student.
Students To ensure that Submission of Confirmation Confirmation of PASS
bookings at tutors are able to student details of booking. booking.
RTSA make booking at to RTSA
RTSA on behalf
of the students
Students To ensure that Submission of Fail message Fail message PASS
bookings at tutors are able to student wrong displayed displayed
RTSA make booking at details to
RTSA on behalf RTSA
of the students
only with correct
details
Driving School, RTSA and System Admin Functions
Driving Ensure only Correct Driving Driving School PASS
School Login authorized Username and School Profile Profile Page
users(Driving Password Page
school managers)
can use the
Driving school
web interface
RTSA Login Ensure only Correct RTSA Profile RTSA Profile PASS
authorized Username and Page Page
users(RTSA Password
employee) can
use the RTSA
web interface
System Ensure only Correct DSAZ Admin DSAZAdmin PASS
Admin Login authorized users Username and Page Page
can use the Password
|Page
DSAZ (admin)
Web interface
8.3 Summary
This chapter has explained the types of tests done on the system and the purpose of the tests. It
further on showed how the tests were done using a table which displayed the functionality of the
proposed system and the test results.
The next chapter looks at the Social Legal and ethical issues that come with the implementation
of the new application.
9. LEGAL, ETHICAL, PROFESSIONAL AND SOCIAL ISSUES
9.1 Introduction
In order to develop a very effective system that will work to the benefit and safety of all its users,
we will have to take into consideration a number of issues that are likely to arise as a result of the
existence of the system. This chapter will review such factors or issues as the ethical, social,
legal and professional issues that would affect the development and implementation of the
System.
9.2 Legal Issues

System will require the users to submit confidential information such as passwords, residential
address, background and information of relatives. This information held by the system is
supposed to be kept safely and is not supposed to be disclosed to anyone without the concern of
the owners of the information. According to ACT 13 of 2004 section 9 of the laws of Zambia, it
is a crime to disclose or possess information without the consent of the owners of the
information. Therefore, the breach of privacy and may lead to legal action being taken.
|Page
9.3 Social Issues
It is human nature to resist change. People are used to the physical way of applying for licenses
at RTSA. It will be a challenge to get all the users at RTSA to like the system because it will
reduce or eliminate the aspect of corruption. Implementing this system will result to people who
are applying for licenses to not be getting their licenses illegally at RTSA. Currently some people
opt to bribe the instructors at RTSA to get licenses without having to go through a driving
school. To counter this, a lot of public awareness on the benefits of going through driving
schools in order to obtain a license will have to be made. Possibly, making it a requirement that
people would only obtain drivers’ licenses only if they went through training at a driving school
would really help reduce the resistance from the public.
9.4 Ethical Issues

The information that will be captured in this system is about driving schools and their students.
This information captured into the system always has to be accurate and correct. This will give
people confidence in the system and the information they receive. One of the ways to ensure data
integrity is to include validation in all the forms or fields that require data input from users.
Correct data types and formats were vital in designing the system.
9.4. Professional issues

With a system that deals with providing the public access to choose a school of their choice, it is
very important that this information about the registered schools is presented in an accurate and
non-biased way. This would bring in a level of professionalism that would benefit both the
driving schools and consumers and also provide a good reputation about the platform.
9.6 Summary
This chapter reviewed the different issues that affect the implementation of the system and how
some of these problems must be handled. The issues addressed in this chapter were specific to
this project. These issues must be seriously reviewed and the correct measures must be put in
|Page
place if the proposed system is to be successfully set up and be accepted by the users and the
stakeholders.
The next chapter summarizes the information presented by the different chapters in this
document
10. SUMMARY AND PRESENTATION OF RESULTS
10.1. Introduction
This is a summary chapter for all that has been covered in all the chapters of this document
including the results or conclusions achieved for the chapters.
10.2. Chapter Summary and results

The following sections give an overview of each chapter’s results.
10.2.1. Chapter 1 Introduction
Chapter one is an introduction to Driving Schools Association of Zambia, Driving schools and
the process of attaining a driver’s license in Zambia. It stipulates the challenges that the
organizations in the road service industry face and how difficult it is to legally obtain a drivers
licenses. It also explains how difficult the public finds it to know the legally registered driving
schools when they are looking for schools to do their driving lessons from.
The chapter gives reasons why a there is need to carry out this project, it also states the scope,
aim, objectives of the project and the road map of the report.
10.2.2. Chapter 2 Literature review
Chapter 2 described the Online Driving School Registration, Driver’s License Application and
Road Accidents Reporting System, the involved parties and its components. It also describes the
|Page
technologies used in the development of the proposed system as well as reviewing their
weakness and strengths. It was a basic research which was done during the project in order to
have a better understanding of the Online Driving School Registration, Driver’s License
Application and Road Accidents Reporting System.
10.2.3. Chapter 3 Objectives, Activities and methods
The chapter talked about the objectives and activities of the project. It also explored the different
methods to be used in order to carry out these activities. As the activities were conducted, the
results achieved under each of the methods were also outlined.
10.2.4. Chapter 4 Review of other systems
This chapter investigated other systems of the same nature that are implemented elsewhere. The
main reason for this activity was to help in revealing the features that could be included in the
proposed system.
The main features and areas of the other systems that were accessed are the Navigation,
usability, main functionality and the appearance of the systems.
10.2.5. Chapter 5 Requirements Analysis
This chapter was mainly focused of the requirements of the proposed system. It looked at both
the functional and non-functional requirements of the system and described them in detail
according to the type of user. Use case diagrams were also used in the chapter to further more
explain and illustrate the requirements of each user type
|Page
10.2.6. Chapter 6 Design
The different models that were used in the design of the final system were described in this
chapter based on the requirements that were described in chapter 5. The different types of design
models that were used in this chapter are the as relational database model, conceptual schema,
and the flow chart. A site map and the interface of the system were also provided. The interface
design showed the physical appearance of the system and the forms used for the capturing of
data. At the end of the chapter, a design specification was achieved.
10.2.7. Chapter 7 Development
Chapter 7 outlined the activities involved in the development of the project. Samples of the code
used in the system, the features and the architecture of the system were also included in the
chapter. An overview of the technology used to develop the system and how they were applied
were also explained in the chapter.
10.2.8. Chapter 8 Testing
This chapter demonstrated the tests that were conducted. It explained the types of testing, the
reasons for the tests and their outcomes so as to ensure that the system had met the customer
requirements.
10.2.9. Chapter 9 Legal, Ethical, Social and professional issues
The chapter outlined the legal, ethical, social and professional issues that affected the
implementation of this specific project.
|Page
10.3. Summary
Each of the chapters had a specific goal and provided details of the project according to the stage
at which the project was it that given time. These chapters helped in producing a workable, user-
friendly, secure system that met the user requirements.
The documentation also considered factors that would affect the system such as the legal, ethical
and professional issues.
11. Conclusion
11.1. Introduction
This chapter provides an evaluation of the final product. It also brings to light the challenges
faced and lessons learnt during the whole process from start to end as well as a number of
recommendations for the future.
11.2. Project Management

The project was carefully planned by dividing it into a number of phases. All the phases had
summed up to giving one unique and complete product. In this case all of the phases had to be
managed and measured against time and resources. I had to make sure that each phase was
completed on time in order for the project to meet its deadline. To help me meet my target, I
used Microsoft project tool to plan my project.
11.3. Product Evaluation

The end product had a simple and friendly user interface that is so self-explanatory to the users.
The pages are responsive and fit the screen of whichever device regardless of browser is being
used. The system uses the resources of the server and the client device efficiently. The system
has a login functionality which helps to secure and protect every user’s information from
unauthorized users.
The system was able to achieve its goals and the requirements.
|Page
11.4. Lessons Learnt
The entire project has taught me that there is more to developing a system than just
programming. I have learnt that for a system to become effective there is need to carry out
massive research and to involve the users of the system. System development involves working
around user requirements and taking into consideration the problem at hand. Documenting each
and every activity also helps to keep the developer of the system on track and not end up
working on irrelevant items on the system.
11.5. Challenges
There were a number of challenges I faced during the project i.e. the distances I had to move to
meet the president of DSAZ and the Station manager of RTSA Premium house. At times the
appointments would conflict I would only end up meeting one of the two people. Being the only
person in my department at work, I would have challenges working on my project due to the
massive amounts of work and the trips out of town I had to make. The other challenge was to do
with many restrictions on access to the information that was so vital in the project from the
organizations were I was carrying out my research on.
.
11.6. Future recommendations

To enhance the system further, I would recommend adding some more features such as lesson
scheduling on the driving school side, online payments and a component to show the blacklisted
schools
11.7. Summary
It was an interesting task that seemed impossible at some point until I started to apply the
principles i had learned. It helped me to practically apply all that I have learned in the whole
computing program. There are many things that were implemented and other things that would
have even been done better. I put in my best to see to it that the project was at its best.
|Page
REFERENCE
Books
Ballard P., Moncur M . Sams Teach Yourself Ajax, JavaScript and PHP all in one (2009), Sams Publishing,
Indianapolis, Indiana, USA
Bennett S., McRobb S. & Farmer R. (2005). Object-Oriented System Analysis And Design using UML,
McGraw-Hill Education, Berkshire, England.
Connolly, T., Begg, C. (2005) Database Systems: A Practical Approach to Design, Implementation, and
Management. 4th edn. England: Pearson Education Limited.
DSDM Consortium (2010) The DSDM Student Workbook: a guide to the definitive Agile framework.
Cheshire: Galatea Training Services Limited.
Robbins J. N. Web Design in a Nutshell 3rd Edition (2006), O’Reilly Media Inc., Sebastopol, CA95472
Richards, K. (2010) Agile Project Management: Intergrating DSDM Atern into existing Prince2
environment. Bristal
Websites
BCS(2010) BCS Code of Conduct. Available from http://www.bcs.org/content/conWebDoc/36606

[Accessed on 4th November 2014
( http://php.net/manual/en/intro-whatis.php)
http://davidfrico.com/rico07 Date accessed (12/03/2016)
http://www.w3schools.com/html/html_intro.asp Date accessed (12/03/2016)
http://mashable.com/2014/01/21/learn-programming-languages/ Date accessed (15/03/2016)
|Page
Appendix A: Project Proposal
Appendix A – Model Diagrams

Figure 18;Administrators use case diagram (DSAZ)
Approve /
disapprove
<<Include>>application
<<Include>>
Create
<<Include>>
user
<<Include>>
View
user <<Include>>
<<Include>>
Register
Driving School
LOGIN
<<Include>>
<<Include>>
<<Include>>
Deregister
Driving
School <<Include>>
View
Message
Delete
user
|Page
View
Reports
Actor: Administrator
Precondition: Should be logged in and must be admin
Post condition: User must be able to perform the following functions.

correct and Administrator menu is displayed
|Page
Figure 19;rtsa use case
Approve /
disapprove
bookings for
tests
<<Include>>
LOGIN
<<Include>>
ENTER RECORDS OF
ROAD ACCIDENTS
<<Include>>
READ AND SEND

MESSAGES
|Page
Actor: RTSA
Precondition: Should be logged in and must be a RTSA employee
Post condition: User must be able to approve / disapprove bookings for tests.
Table 13; RTSA inputs, events and response

correct the RTSA menu is displayed
|Page
Figure 20; driving school use case
Approve /
disapprove
application from
Student
<<Include>>
Assign an
instructor to a
student <<Include>>
LOGIN
View students
<<Include>>
training progress
<<Include>>
<<Include>>
Interact with
Students
View Student
report from
RTSA
|Page
Actor: Driving School Manager
Precondition: Should be logged in and must be a driving school manager
Post condition: User must be able to view students
Table 14; Driving School inputs, events and response

correct the driving school managers menu is
displayed
|Page
Figure 21; Instructor Use case
View students
assigned to
instructor
<<Include>>
LOGIN
Make bookings
for tests at RTSA <<Include>>
for the students
<<Include>>
View whether or not <<Include>>

a student has been
awarded license or
not
Interact with the

students
assigned to
instructor
|Page
Actor: Instructor
Precondition: Should be logged in and must be an instructor
Post condition: User must be able to view students assigned to him/her
Table 15; Instructors inputs, events and response

correct the Instructor menu is displayed
|Page
Figure 22; Student use case
Apply to a
driving school of
choice
<<Include>>
<<Include>>
View status of
the RTSA
bookings made
on behalf of
View & Interact

with instructor
and driving
school manager
|Page
Actor: Student
Precondition: Should be logged in and must be a student
Post condition: User must be able to apply to a school of choice,
. Input Events from Student System Events and Response

correct and Students menu is displayed
LOGIN
<<Include>>
|Page
Figure 23; Public use case
Apply to be a
student
<<Include>>
<<Include>>
Apply to be an
Instructor
Create an
account
<<Include>>
Apply to be a
driving school
Enter details
such as email
address
Browse through
the messages
meant for the
<<Include>>
public to view
Blog
|Page

Enter email address System input form prompts the user to enter
an email address and name
User enters email and submits System allows user to post a message
User navigates to account registration and System registration form and prompts the user
enters valid details to enter valid information to create an
account.
The user can choose to apply as a student to a The system provides a form that allows a user
school of their choice or to as a Driving to enter details of registration for the user type
school owner they want. (Driving school owner, Instructor
or student)
Appendix B Minutes of Meetings
Appendix C: Current Online Presences
Appendix D Sample Code

Database connection
<?php
$server='localhost';
$username='root';
$password='';
$database='zdsa';
#Connect to the MySQL Server

$MySQLcon=mysqli_connect($server,$username,$password) or die("Cannot Connect to MySQL Server.
This is due to invalid host name Defined");
|Page
#Select Database from Server
mysqli_select_db($MySQLcon,$database) or die("Could not select the Database Name: ".'[ '.
$database.' ]'." Specified... No such Database Name found on the MySQL Server");
?>
Log in code
#SOURCE CODES FOR LOGIN TO THE SYSTEM ---------------------------------------------------
case "login":
$query=mysqli_query($MySQLcon,"Select*from Users WHERE Username='$username' and

Password='$password'");
$rows=mysqli_num_rows($query);
if($rows==0){
$errorMessage='Invalid Username or Password Supplied.. Please Enter Correct Login

Details and then Try Again Later!';
}
else{
$errorMessage='';
$userid=$dr['UserID'];
$usertype=$dr['Usertype'];
$_SESSION['userid']=$userid;
$_SESSION['usertype']=$usertype;
$_SESSION['username']=$dr['Username'];
$_SESSION['password']=$dr['Password'];
#System User ACCESS LEVELS

switch($usertype){
case "Association Secretary":
header("location: Administrator/");
exit;
case "RTSA":
header("location: RTSA/");
exit;
case "Driving School":
$query=mysqli_query($MySQLcon,"Select*from DrivingSchools WHERE
UserID='$userid'");
$_SESSION['schoolid']=$dr['SchoolID'];
$_SESSION['schoolname']=$dr['SchoolName'];
header("location: Driving School/");
exit;
|Page
case "Instructor":
$query=mysqli_query($MySQLcon,"Select*from Instructors WHERE UserID='$userid'");
$_SESSION['instructorid']=$dr['InstructorID'];
$_SESSION['schoolid']=$dr['SchoolID'];
$_SESSION['fullname']=$dr['FirstName'].' '.$dr['Surname'];
header("location: Instructor/");
exit;
case "Public":
$query=mysqli_query($MySQLcon,"Select*from Applicants WHERE UserID='$userid'");
$_SESSION['applicantid']=$dr['ApplicantID'];
$_SESSION['fullname']=$dr['FirstName'].' '.$dr['Surname'];
$_SESSION['email']=$dr['Email'];
header("location: Public/");
exit;
}
#END System Access Levels
exit;
}
# END ---------------------------------------------------------------------------------
Creating a Driving School
#SOURCE CODES FOR CREATING NEW DRIVING SCHOOL

---------------------------------------------------------------------------
case "savedrivingschool":
$userid=$_POST['userid'];
$usertype='Driving School';
$confirm=$_POST['confirm'];
$schoolname=$_POST['schoolname'];
$address=$_POST['address'];
$phonenumber=$_POST['phonenumber'];
$email=$_POST['email'];
$website=$_POST['website'];
$da=mysqli_query($MySQLcon,"Select*from DrivingSchools WHERE SchoolName='$schoolname'");

$rows=mysqli_num_rows($da);
if($rows>0){
$errorMessage="This School Name: "."[ ".$schoolname." ] ..Is Already Registered with
Zambian Driving School Assocciation";
}
else{
|Page
$da=mysqli_query($MySQLcon,"Select*from Users WHERE Username='$username'");
if($rows>0){
$errorMessage="Username Already Taken by Someone else.. Try Another!!!";
}
elseif($confirm!=$password){
$errorMessage="Confirmed Password is not the Same as the New Password";
}
else{
mysqli_query($MySQLcon,"Insert Into
DrivingSchools(UserID,SchoolName,Address,PhoneNumber,Email,Website)
VALUES('$userid','$schoolname','$address','$phonenumber','$email','$website')");
$code=rand(255,99999);
mysqli_query($MySQLcon,"Insert Into Users(UserID,Username,Password,Usertype,Code,Status)
VALUES('$userid','$username','$password','$usertype','".$code."','Activated')");
mysqli_query($MySQLcon,"Delete from ReservedKeys WHERE UserID='$userid'");
$errorMessage='';
echo '<script language="javascript">alert("Driving School Account Created
Successfully");window.location="Administrator/ViewSchools.php";</script>';
exit;
}
}
# END ------------------------------------------------------------------------------------------
Creating an Instructor
#SOURCE CODES FOR CREATING NEW DRIVING SCHOOL INSTRUCTOR

-----------------------------------------------
case "saveinstructor":
$userid=$_POST['userid'];
$usertype='Instructor';
$confirm=$_POST['confirm'];
$schoolname=$_POST['schoolname'];
$firstname=$_POST['firstname'];
$surname=$_POST['surname'];
$gender=$_POST['gender'];
$address=$_POST['address'];
$phonenumber=$_POST['phonenumber'];
|Page
$email=$_POST['email'];
$da=mysqli_query($MySQLcon,"Select*from DrivingSchools WHERE SchoolName='$schoolname'");

$rs=mysqli_fetch_assoc($da);
$schoolid=$schoolname;//$rs['SchoolID'];
$da=mysqli_query($MySQLcon,"Select*from Users WHERE Username='$username'");

if($rows>0){
$errorMessage="Username Already Taken by Someone else.. Try Another!!!";
}
elseif($confirm!=$password){
$errorMessage="Confirmed Password is not the Same as the New Password";
}
else{
mysqli_query($MySQLcon,"Insert Into
Instructors(SchoolID,UserID,FirstName,Surname,Gender,Address,PhoneNumber,Email)
VALUES('$schoolid','$userid','$firstname','$surname','$gender','$address','$phonenumber','$email')");
$code=rand(255,99999);
mysqli_query($MySQLcon,"Insert Into Users(UserID,Username,Password,Usertype,Code,Status)
VALUES('$userid','$username','$password','$usertype','".$code."','Activated')");
mysqli_query($MySQLcon,"Delete from ReservedKeys WHERE UserID='$userid'");
$errorMessage='';
echo '<script language="javascript">alert("Instructor Account Created
Successfully");window.location="Administrator/ViewInstructors.php";</script>';
exit;
}
# END -----------------------------------------------------------------------------------------------------------
Appendix E Screen Shots
Figure 24; welcome page for system
|Page
Figure 25; login page
|Page
Figure 26; wrong details entered
Figure 27; admin home page
|Page
Figure 28; Create user
Figure 29;View user
|Page
Figure 30; Create Driving School
Figure 31; View Driving School
|Page
Figure 32;Create Instructor
Figure 33; Feedback
|Page
Figure 34; Reports
|Page

Final Document

Uploaded by

Copyright:

Available Formats

Final Document

Uploaded by

Document Information

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

Final Document

Uploaded by

Copyright:

Available Formats

Evelyn Hone College

DESIGN AND IMPLEMENTATION OF AN ONLINE DRIVING SCHOOL

Name: Titus Phiri

1.4 Problem Statement and Solution

1.4.1 Getting Information and applying to a driving school

1.4.3 Getting road traffic information

1.5 Aim and Objectives

1.6 Report Road Map

Chapter 5 – Requirements Analysis: describes the collection of information needed to produce

Chapter 10 – Summary and Presentation of Results

Characteristics of the Agile methodology

2.3.1. Extreme Programming; this is a development approach that is more of code

2.3.2. Dynamic System Development method (DSDM); DSDM is an agile project

2.4 Application Development Technologies

2.4.2. JavaScript is an object- and prototype based programming language created by

http://davidfrico.com/rico07 Date accessed (12/03/2016)

http://www.w3schools.com/html/html_intro.asp Date accessed (12/03/2016)

http://mashable.com/2014/01/21/learn-programming-languages/ Date accessed (15/03/2016)

3.2. Objective One

Deliverables: Requirements Specifications

3.3. Objective Two

3.4. Objective Three.

 It promotes user involvement and participation as well as communication with the

3.4.4. Rapid Application Development (RAD)

 It mainly focuses on the important elements from the user’s perspective.

3.4.5. Comparison of Methodologies

Features Waterfall Prototyping Rapid Application

Features adapted from ‘Purcell, 1995’

3.4.6. Selected Methodology and Justification

3.5. Objective Four

 Create design models: ERD, Class Diagrams, and Use Cases

3.6.1. To Evaluate the new system

 Perform testing i.e. unit, module and system tests

Testing is critical in evaluating the success of an application; by ensuring that application is

4. REVIEW OF OTHER SYSTEMS

4.2. SOAR Student Online Registration System

4.2.6. Features Adopted

Figure 2; shows tutor registration

Data capture page adapted from http://nevonprojects.com/motor-driving-school-system/

4.4. The Driving school Association of Louisiana website

Data capture page adapted from http://www.dsal.org/pdfs/members.pdf

5.2. Fact finding techniques

5.3. Requirement Specification

5.3.1. Functional Requirements

Systems Administrator (DSAZ) requirements:

 Create Driving School.

 Approve or dis approve applications

 Delete Driving School.

RTSA Staff requirements:

 Enter information about road accidents.

Driving School Manager requirements:

 Assign an instructor to a student

 View students training progress

 Message students and also receive messages from students

 View students assigned to them

 Make bookings for tests at RTSA for the students

 View whether or not a student has been awarded license or not

 Apply to a driving school of his or her choice

 Interact with instructor and driving school manager

The Public user requirements: