Final Project Report

Driving License Management System

Project Supervisor
<<Supervisor Name>>

Submitted By

<<Project Group ID>>

<<Group Member Name>> <<VU ID>>

<<Group Member Name>> <<VU ID>>

Software Projects & Research Section,

Department of Computer Sciences,
Virtual University of Pakistan
 CERTIFICATE
This is to certify that <<First Member Name>> (<<VU ID>>), <<Second
Member Name>> (<<VU ID>>) have worked on and completed their Software
Project at Software & Research Projects Section, Department of Computer
Sciences, Virtual University of Pakistan in partial fulfillment of the requirement for
the degree of BS in Computer Sciences under my guidance and supervision.

In our opinion, it is satisfactory and up to the mark and therefore fulfills the
requirements of BS in Computer Sciences.

Supervisor / Internal Examiner

<<Project Supervisor Name>>

Supervisor,
Software Projects & Research Section,
Department of Computer Sciences
Virtual University of Pakistan

___________________
(Signature)

External Examiner/Subject Specialist

<<External Supervisor Name>>

___________________
(Signature)

Accepted By:

_____________
(For office use)

EXORDIUM
 In the name of Allah, the Compassionate, the
Merciful.

Praise be to Allah, Lord of Creation,

The Compassionate, the Merciful,
King of Judgment-day!

You alone we worship, and to You alone we pray for

help,
Guide us to the straight path

The path of those who You have favored,

Not of those who have incurred Your wrath,

Nor of those who have gone astray.
 DEDICATION

To

The Last Prophet

Hazrat Muhammad (‫)ﷺ‬

All words dedicated with respect to

LOVING PARENTS
Whose love and prays always accompanies like a
shining star whenever was in darkness.
 ACKNOWLEDGEMENT

I would like to express deep thanks and

wholehearted thanks to my dear friend Mr.
_________ for his valuable guidance,
suggestions and encouragement in
completing the project successfully
 PREFACE

First chapter is Test Phase-I which includes a

problem “Driving License Management System- Database
Category” provide interface to add, show, update, and
delete record.
Second Chapter is Test Phase-II which includes a
problem to create an application that can perform all
the CRUD (Create, Read, Update, and Delete)
operation on a database.
Third chapter is “Gathering and Analyzing Info”
which includes SRS Document. Its sub sections
include Introduction and Scope of the project and
Purpose, a comprehensive detail about the Use Cases
and Usage Scenarios and Supplementary
Requirements, Methodology, Work Plan and Gantt
chart.
Fourth chapter is “Designing the Project” which
includes Design phase documents. Sections of this
chapter are Introduction Scope, purpose,
Architectural Representation, Dynamic Model,
Object Model, Deployment Model, Database Model
and Graphical User Interfaces.
Fifth chapter is “Development Plan”.
 TABLE OF CONTENTS

CHAPTER NO. 1
GATHERING & ANALYZING INFO...................................................10

1.1 INTRODUCTION

1.2 PURPOSE

1.3 SCOPE

1.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS

1.5 USE CASES AND USAGE SCENARIOS

1.5.1 Use Case Diagrams

1.5.2 Usage Scenarios

1.6 SUPPLEMENTARY REQUIREMENTS

1.6.1 Usability

1.6.2 Reliability

1.6.3 Supportability

1.6.4 System Requirements

CHAPTER NO. 2
PLANNING THE PROJECT..............................................................11
2.1 INTRODUCTION

2.2 METHODOLOGY

AVAILABLE METHODOLOGIES

CHOSEN METHODOLOGY

REASONS FOR CHOSEN METHODOLOGY

WORK PLAN
 PROJECT STRUCTUR
2.3.1 Team Structure

2.3.2 Project Schedule (Submission Calendar)

CHAPTER NO. 3
DESIGNING THE PROJECT............................................................12

3.1 INTRODUCTION

3.2 PURPOSE

3.3 SCOPE

DEFINITIONS, ACRONYMS AND ABBREVIATIONS

ARCHITECTURAL REPRESENTATION (ARCHITECTURE

DIAGRAM)

DYNAMIC MODEL: SEQUENCE DIAGRAMS

OBJECT MODEL/LOGICAL MODEL: CLASS DIAGRAM

DATABASE MODEL (DATABASE DIAGRAM)

GRAPHICAL USER INTERFACES

CHAPTER NO.4
DEVELOPMENT.............................................................................13
4.1 DEVELOPMENT PLAN (ARCHITECTURE DIAGRAM)
CHAPTER NO.5
DEPLOYMENT...............................................................................14
4.1 ..............DEPLOYMENT PLAN (DEPLOYMENT DIAGRAM)
 CHAPTER 1
Gathering & Analyzing Info

Introduction;
In digital era of today’s world, almost nearly for all businesses, the driving license
system is now going to online and easy access of user collecting methods from user is
quite complex. So, departments are finding out the ways to make it easy and convenient.
Especially in Govt. sector, paying the lots of time and efforts to apply for license fees
through banks has not been efficient enough especially during the busy days of life and
want quick license. The process of manual laboring of documentation writing is
considered outdated. Furthermore, this process can cause a lot of trouble and it is very
time consuming as well. My main idea of making driving license management system is
to make an automatic real time system that automate the process of issuing driving
license process. System can make the daily activities efficient and providing the fast
response to store and retrieve information. This system will let the Applicant to enter the
personal information to the system. Upon entering information, system will start the
process of driving license according to applicant’s eligibility.

PURPOSE;
The Purpose of Driving License Management System is to tackle all the
obstacles that are faced by user regarding fee file creation manually and paying
challahs in bank. Most of the user are paying fees to meet the requirements for
entering the license process. The process of fees payment in such periods is
suffered by long queues at banks where payments are made, too much waiting
by users and congestion at banks also. Eligibility of an applicant will be checked
automatically based on age.
 Approval of driving license will be done based on theory tests, driving skills test and
medical form automatically.
 System will be real time system.
 It will reduce paper work.
 Maintenance of data record.
 Applicant can apply for driving license at their home.
 Purpose to save time.
 To carry out the license making process efficiently and accurately.

SCOPE
This system will let the Applicant to enter the personal information to the
system. Upon entering information, system will start the process of driving
license according to applicant’s eligibility.
 ● Eligibility of an applicant will be checked automatically based on age.
● Approval of driving license will be done based on theory tests, driving
skills test and medical form automatically.
● System will be real time system.
● It will reduce paper work.
● Maintenance of data record.
● Applicant can apply for driving license at their home.
● System will ask applicant information as input which are as follow:
1. Name
2. Fathers name
3. Date of birth
4. CNIC number
5. Address
6. Phone number
7. City
8. Vehicle type
● Issue date and expiry date along with license number will be
generated automatically when admin will approve it for temporary
license.
● Permanent license will be issued after applicant will clear above
mentioned tests in the system, as per requirement.
● Purpose to save time.

DEFINITIONS, ACRONYMS AND ABBREVIATIONS

User: User means any person who is able to registered and utilize payment method.
User:
Admin:
Driving License Management System

1.5 USE CASES AND USAGE SCENARIOS

1.5.1 Use Case Diagrams
1.5.2 Usage Scenarios

Usage Scenario 1:
Use case related to submission of application of user
Use case title Register user
Abbreviated title Reg_user
Use case ID FR_1
Actors User
Description This use case enable user to apply for license himself.
Pre conditions Internet connection should be available.
Task sequence Exceptions
1. User initiates with his 1. User has left any field empty or
registration with any incompatible data.
questionnaire which is
related to personal &
contact details.
2. System is shown all the
features.
3. User attempts online
test.
4. A test questionnaire
given to the user.
5. The user answers the
questionnaire and
finishes the registration
and obtain temporary/
permanent or renewal
of his license.
6. Alert the user by
sending notification
about the registration
Post User has registered successfully.
condition

Author Bc170201958
Usage Scenario 2:
Use case related to renewal request received at admin
Use case title Register user
Abbreviated title Reg_user
Use case ID FR_1
Actors Admin
Description This use case enable user to review application.
Pre conditions Internet connection should be available.
Task sequence Exceptions
1. Admin login using 1. User has left any field empty or
public contact details. any incompatible data.
2. System is shown all the
features.
3. Checking application
from attempted online
test.
4. Check admin as well as
review applicants.
5. License issued.
Post Admin has registered successfully.
condition

Author Bc170201958
Usage Scenario 1:
Use case related to permanent request received at admin
Use case title Register user
Abbreviated title Reg_user
Use case ID FR_1
Actors Admin
Description This use case enable user to review application.
Pre conditions Internet connection should be available.
Task sequence Exceptions
1. Admin login using 1. User has left any field empty or
public contact details. any incompatible data.
2. System is shown all the
features.
3. Checking application
from attempted online
test.
4. Check admin as well as
review applicants.
5. License issued.
Post Admin has registered successfully.
condition

Author Bc170201958
Usage Scenario 3:
Use case related to temporary request received at admin
Use case title Register user
Abbreviated title Reg_user
Use case ID FR_1
Actors Admin
Description This use case enable user to review application.
Pre conditions Internet connection should be available.
Task sequence Exceptions
1. Admin login using 1. User has left any field empty or
public contact details. any incompatible data.
2. System is shown all the
features.
3. Checking application
from attempted online
test.
4. Check admin as well as
review applicants.
5. License issued.
Post Admin has registered successfully.
condition

Author Bc170201958
 1.6 SUPPLEMENTARY REQUIREMENTS
1.6.1 Usability
Usability is the measure of potential to accomplish the goals of the user. This
software fulfills all the requirements of the user i.e. security personals. Use of the
software is very easy. It has visual consistency and a clear, defined process for
evaluation.

1.6.2 Reliability
Software reliability is another very important quality factor and is defined as
probability of failure free operation of a computer program in a specified
environment for a specified time. For example, a program X can be estimated to
have a reliability of 0.96 over 8 elapsed hours.
Software reliability can be measured, directed, and estimated using historical and
development data. The key to this measurement is the meaning of term failure.
Failure is defined as non-conformance to software requirements.

Hardware reliability is predicted on failure due to wear rather than failure due to
design.

1.6.3 Supportability

Driving License Management System is mobile based application and can be accessed
user.

1.6.4 System Requirements

Computer System having operating system 4 GB Ram, 2.5 Ghz Processor and 16
GB internal space
 CHAPTER 2
Planning the Project

2.1 INTRODUCTION
Project planning involves a series of steps that determine how to achieve a particular
community or organizational goal or set of related goals. This goal can be identified in a
community plan or a strategic plan.

2.2 METHODOLOGY
A software development methodology or system development methodology in software
engineering is a framework that is used to structure, plan, and control the process of
developing an information system.
 AVAILABLE METHODOLOGIES
There are the following methodologies:
 Agile Software Development
 Crystal Methods
 Spiral
 Systems Development Life Cycle
 Waterfall
 Dynamic Systems Development Model
 Extreme Programming
 Feature Driven Development
 Joint Application Development
 Lean Development
 Rapid Application Development
 Rational Unified Process
 Scrum

CHOSEN METHODOLOGY
My Adopted Methodology is VU Process Model. VU process Model is
combination of Water Fall model and Spiral Model.

REASONS FOR CHOSEN METHODOLOGY

Given below are some reasons for preferring VU Process Model for this system:
Selection Reasons:
1. VU Process Model is sequential model with backward repetition.
2. In VU Process Model all activities are performed in a sequence.
3. VU Process Model is more concise and advanced model then waterfall model
because we can go back at any stage of development which is not allowed in
waterfall model.
4. When we want repetition then we can choose VU Process Model.
5. VU Process Model provides us facility to do correction at any stage.
6. Whenever we want any betterment in our system then we can choose VU process
model.
Vu process model:
WORK PLAN
 PROJECT STRUCTURE

In Driving License Management System App we are using single layer

structure.
App_Code
App_Data
Users
Images
Reports

Team ( )
StructureName ( )

( )
Group ID

Project Title (Driving License Management System App)   

Project Supervisor

2.3.3 Project Schedule (Submission Calendar)

 CHAPTER 3
Designing the Project

3.1 INTRODUCTION
 The complete study about different operations that are performed by a system and
the relationship between them within or outside of the system is called Analysis of a
system or the given project.
The Design document contains following data.
 Entity Relationship Diagram
 Sequence Diagram
 Architecture design diagram
 Class Diagram
 Database Design
 Interface Design
 Test cases

Register:
 User Application Database

Enter details

Sign up ()

Okay
Account created
successfully

Login :

Admin/User Application Database

Login to Account

Sign in ()

Okay
Login to account
successfully

Take Test modules:

 Admin Application Database

Add/Update test modules

Adding modules()

Okay
Modules added
successfully

Solve Quiz:

User Application Database

Show Quiz
Solve Quiz method()

Okay
Quiz done successfully

View Result:
 User Application Database

View Result
System View Result

Okay
Action performed
successfully

Logout:

Admin/User Application Database

Click logout
Logout ()

Okay
Logout
Successfully

Sequence Diagram Figure 2.5

OBJECT MODEL/LOGICAL MODEL: CLASS DIAGRAM

DEPLOYMENT MODEL (DEPLOYMENT DIAGRAM)

DATABASE MODEL (DATABASE DIAGRAM)
 Database Diagram Figure 5.0

GRAPHICAL USER INTERFACES

 Home Screen

Dashboard
Register
Login:
View User Record:
Complete Quize
View Result
 CHAPTER 4
Development

4.1 Development plan (Architecture Diagram)

 1.

Presentation Layer

Application Layer

Database Layer

Database

Architecture Diagram Figure 3.0

Development Methodologies
Development team assume project methodologies base on the project

specifications & requirements. Following are the fundamental popular models

used.

AVAILABLE METHODOLOGIES

 Build and Fix Model

 Waterfall Model

 Incremental Models

 Rapid Application Development (RAD)

 Spiral Model

 Object-Oriented Lifecycle Models

 Fountain Model
 BUILD AND FIX MODEL

This model is show in the following diagram:

It is unlucky that many products are developed using what is

known as the build-and-fix model. In this model the product is

build without requirement or any attempt at design. The

developers only build a product that is reworked as many

times as essential to satisfy the client. This model may work

for small projects but is totally unacceptable for products of

any reasonable size. The cost of build-and fix is actually far

larger than the cost of properly specified and carefully

designed product.
Maintenance of the product can be extremely in the absence of

any certification.

WATERFALL MODEL

The initial published model of the software development

process was derived from other engineering processes.
Because of the cascade from one stage to another, this model
is known as the waterfall model. This model is also recognized
as linear sequential model. This model is depicted in the
following diagram.
The 5 stages above are as follows:

1. Requirement Analysis and Definition: What

The systems services, constraints and objectives are
established by discussion with system users. They are
then defined in detail and serve as a system requirement.

2. System and Software Design: How

The system design procedure partitions the requirements
to either hardware of software systems. It established and
overall system architecture. Software design involves
basic system abstractions and their relationships.

3. Implementation and Unit Testing: - How

Throughout this stage the software design is realized as a
set of programs or program units. Unit testing engages
verifying that each unit meets its specifications.

4. Integration and system testing:

The individual program unit or programs are integrated
and tested as a complete system to make sure that the
software requirements have been met. After testing, the
software system is send to the customer.

5. Deployment and Maintenance:

Usually this is the longest stage of the software life cycle.
The system is installed and put into practical use.
Maintenance involves correcting errors which were not
exposed in earlier stages of the life-cycle, improving the
implementation of system units and enhancing the system’s
services as new requirements are discovered.
 INCREMENTAL MODELS

As talk about above, the major drawbacks of the waterfall

model are due to the fact that the whole product is developed
and delivered to the client in one package. This results in late
feedback from the client. Because of the extended elapsed
time, a giant new investment of time and money may be
required to fix any errors of omission or commission or to
accommodate any new requirements cropping up during this
period. This may render the product as unusable. Incremental
model may be used to overcome these problems.
In the incremental models, as opposite to the waterfall model,
the product is partitioned into smaller pieces which are then
built and delivered to the client in increments at usual
intervals. Since each piece is much lesser than the whole, it
can be built and sent to the client rapidly. This results in
rapid feedback from the client and any requirement related
errors or changes can be incorporated at a much smaller cost.
It is therefore less traumatic as compared to the
waterfall model. It also required lesser capital outlay and yield
a rapid return on investment. However, this model needs and
open structural design to allow integration of subsequent
builds to yield the bigger product. A number of differences are
used in object-oriented life cycle models.
RAPID APPLICATION DEVELOPMENT (RAD):
Rapid application development is a further form of incremental
model. It is a high speed adaptation of the linear sequential
model in which completely functional system in a very short
time (2 or 3 months). This model is only valid in the projects
where requirements are well understood and project scope is
constrained. Because of this cause it is used primarily for
information systems.
SPIRAL MODEL
This model was developed by Barry Boehm. The major idea of
this model is to avoid risk as there is always an element of risk
in development of software. For example, key personnel may
leave at a critical juncture, the manufacturer of the software
development may go bankrupt, etc.
In its simplified form, the Spiral Model is Waterfall model plus
risk analysis. In this case each stage is preceded by
identification of alternatives and risk analysis and is then

Risk Analysis

Rapid Prototype
Specification
Design
Implementation
Verify
Followed by assessment and planning for the next stage. If
risks cannot be resolved, project is immediately ended. This is
depicted in the following diagram.

As can be seen, a Spiral Model has 2 dimensions. Radial

dimension represents the increasing cost to date and the
angular dimension represents the progress through the spiral.
Each stage begins by determining objectives of that stage and
at each phase a new process model may be followed.

A full version of the Spiral Model is shown below:

The main power of the Spiral Model comes from the fact that it
is very responsive to the risk. Because of the spiral nature of
development it is easy to judge how much to test and there is
no difference between development and maintenance. It

Determine Identify and

objectives, resolve risks
alternatives
,
constraints

Develop
and
Plan verify
Next next-
Phase level
however can only be used for large-scale software development
and that too for internal (in-house) software only.

Object-Oriented Lifecycle Models

Object-oriented lifecycle models appreciate the need for

iteration within and among stages. There are a number of
these models. All of these models fit in some form of iteration,
parallelism, and incremental development.
Extreme Programming
It is a somewhat contentious new approach. In this approach
user requirements are imprison through stories which are the
scenarios presenting the features needed by the client?
Estimate for period and cost of each story is then carried out.
Stories for the next construct are selected. Then each
construct is divided into tasks. Test cases for task are drawn
up first before and development and continuous testing is
performed throughout the development process.

Architectural User stories

spike

Release Iteration Acceptance

Planning test

Spike Small release

One very vital feature of eXtreme programming is the idea of

pair programming. In this, a team of 2 developers develop the
software, working in team as a pair to the extent that they
even share a solitary computer.
In eXtereme Programming model, computers are put in middle
of large room lined with cubicles and client representative is
always present. One very important restriction imposed in the
model is that no team is allowed to work eventually for 2
successive weeks.
XP has had several successes. It is good when requirements
are vague or changing and the overall range of the project is
limited. It is however too soon to assess XP.

FOUNTAIN MODEL

Fountain model is one more object-oriented lifecycle model. This is depicted in

the following diagram.

Maintenance
Further development

Operations

Implementation and
integration

Implementation

Object-oriented design

Object-oriented
analysis

Requirement

In this model the circles representing the various stages overlap, explicitly

representing an overlap among activities. The arrows within a stage represent

iteration within the stage. The maintenance cycle is smaller, to symbolize

reduced maintenance attempt when the object oriented paradigm is used.

Chosen Methodology

VU PROCESS MODEL:
Vu process model is the combination of waterfall model and spiral model.

The main thought for selection of this model is that to get the benefits of

both these models. We will be deploying the linear nature of waterfall

model here along with minimizing the hazards through spiral model. In

vu process model we will be working in phases to complete our given

project. Several of the phases are explained below:-

Phase I:-
In this first phase we will define the scope, vision and requirements for

our project. We will describe the functional, non functional requirements

in this phase. We will be defining the use cases for our system and their

situations here too.

Phase II:-
In this phase we will be assess the information gathered in our previous

phase. We will be defining time line in which this project should be

completed, the price which will be allocated for our project and all the

essential planning activities will be done in this phase.

Phase III:-
In this phase we will be working on the design of our system. We will be

defining all the aspects of design of system. We will work on the

structural design of the system, the internal and external entities, their

relations between each other and to the others, etc. After completing the

basic design phase we will make our system here.

Phase IV:-
In this phase we will apply our system. We will start working on the

system deployment, installation, working & etc.

Phase V :-
In this phase we will verify and test our system. We will perform different

type of testing here and if got few problems, we will resolve that out.

Phase VI :-
In this phase we will work on the maintenance of our system
after deploying it and if needed.

In all the above phases, we will be analyzing risks for every

phase at its start and will resolve them before entering into
next phase.
 REASONS FOR CHOOSING THE METHODOLOGY

There is certain reason of the Vu process model, which causes it to be

the most widely used model as yet. Some of them can be listed as under.

1. Easy to manage due to the inflexibility of the model – each stage has

specific deliverables and a review process.

2. Simple and easy to use.

3. It takes less time and wages.

4. Works well for smaller projects where requirements are very well

understood.

5. Stages are processed and completed 1 at a time.

6. It is a linear model and of course, linear models are the most easy to

be implemented.

7. The amount of resources required to apply this model is very minimal.

After every main stage of software coding, testing is done to check the

right running of the code

CHAPTER 5
Deployment
 What is Software Deployment?

Software deployment is all of the actions that make a software system available

for use. The general deployment process consists of some unified activities with

possible transitions among them. These activities can happen at the producer

site or at the consumer site or both. Because every software system is sole, the

precise processes or procedures within each activity can barely be defined.

5.1 DEPLOYMENT PLAN (DEPLOYMENT DIAGRAM)

 REFERENCES

http://www.tutorialspoint.com/
http://www.homeandlearn.co.uk/
https://www.android.com//
APPENDIX