UNIVERSITY OF DELHI

SOFTWARE ENGINEERING PROJECT REPORT

B.Sc (Hons.) COMPUTER SCIENCE

(2020 - 2023)

Submitted By –
Saurabh Kumar
Swapnil Verma
Richa Kothari
Siddhi Datri
Kirti Rawat
 RAM LAL ANAND COLLEGE
(University of Delhi)

Department of Computer Science

(Software Engineering Project Report)

B.Sc (Hons.) COMPUTER SCIENCE

(2020 - 2023)

SUBMITTED BY –
Saurabh Kumar (20058570035)
Richa Kothari (20058570028)
Swapnil Verma(20058570042)
Siddhi Datri (20058570055)
Kirti Rawat (20058570019)

-Under the Supervision of:

(Dr. Vandana Gandotra)
 CERTIFICATE

This is to certify that Software Engineering project report

entitled “DRIVER MONITORING SYSTEM” is the work carried
out by Saurabh , Swapnil Verma, Kirti Rawat, Richa Kothari
and Siddhi Datri students of B.Sc(H) Computer Science 4th
Semester, Ram Lal Anand College , University of Delhi under
the supervision of Dr. Vandana Gandotra .
This report has not been submitted to any other
organization/institution for the award of any other
degree/diploma.

Dr. Vandana Gandotra Dr. Rakesh Kumar Gupta

(Supervisor) (Principal)
 ACKNOWLEDGEMENT
The success of any project depends largely on the
encouragement and guidelines of many other people. We
take this opportunity to express our gratitude to the people
who have been instrumental in the successful completion of
this project.
We would like to express our sincere gratitude to our project
supervisor Dr. Vandana Gandotra for guiding us . We are
highly indebted for her guidance and constant supervision as
well as for providing necessary information regarding the
project and also for her support in completing the project.
The guidance and support received from all staff members
was vital for the success of the project.
We are grateful for their constant support and help. We
would take this opportunity to express our gratitude towards
principal Dr. Rakesh Kumar Gupta . Who was always a source
of encouragement for us. We have taken efforts in this
project. However, it would not have been possible without
the kind support and help of many individuals. I would like to
extend my sincere thanks to all of them.
 ABSTRACT
Absence of forbearance among drivers, fatigue and
irresponsible behaviour among drivers result in countless
fatal crashes and road traffic injuries. Driver drowsiness is a
highly problematic issue which impairs judgment and
decision making among drivers resulting in fatal motor
crashes. This paper describes a simple drowsiness detection
approach for a smartphone with Android application using
Android Studio 3.6.1 and Mobile Vision API for drowsiness
detection before and while driving. Physiological analysis and
a quick facial analysis were performed to check drowsiness
before the driver starts driving. The smartphone camera was
used for analysing the heart rate by tracking colour changes
due to blood flow on the fingertip. Facial analysis was
undertaken by Google Vision API which determined the head
position, blinking duration and yawning frequency through
the eye opening and mouth opening probabilities. The heart
rate, blinking duration, yawning frequency and speeding
were used as indicators for drowsiness. The facial analysis
was repeated with speeding data while driving with results
analysed each one minute. A performance accuracy of the
combined results with speeding detection proved to be
around 93.3%.
 CONTENTS
1. INTRODUCTION
1.1 Background
1.2 Problem Statement
1.3 Process Model
2. REQUIREMENT AND ANALYSIS
2.1
2.1.1 Purpose
2.1.2 Objective
2.1.3 Project Scope
2.1.4 Scope for future work
2.1.5 Environment Used
2.2 USE CASE APPROACH
2.3 DATA FLOW DIAGRAM
2.4 DATA DICTIONARY
3. Project Management
3.1 Functional Point Estimation
3.2 Effort Estimation
3.3 Cost Estimation
3.4 RISK MANAGEMENT
4. DESIGN ENGINEERING
4.1 ARCHITECTURAL DESIGN
4.2 PSUEDOCODE EXPLANATION FOR
CODE
4.3 UI DESIGN
5. IMPLEMENTATION

6. SOFTWARE TESTING
6.1 SOFTWARE TESTING
FUNDAMENTALS
6.2 Test Case Design
6.2.1 Test Case-1
6.2.2 Test Case-2
6.2.3 Test Case-3

7. MAINTENANCE
7.1 Need For Maintenance
7.2 Categories of Software Maintenance

8 . LIMITATIONS OF SOFTWARE
 8.2 Future Improvement
9 . CONCLUSION
10. BIBLIOGRAPHY

LIST OF FIGURES:
Fig1: Different system to detect drowsiness
Fig:2 V model
Fig3 use case diagram
Fig4: 0 level DFD
Fig5: level 1 DFD
Fig6: level 2 DFD
Fig7 Risk Management
Fig 8: design engineering

LIST OF TABLES
Table:1 Function point Estimation
Table:2 Complexity Adjustment Factor
Table: 3 Risk table
Table: 4 Timeline chart
Table: 5 Test case 1
Table: 6 Test case 2
Table: 7 Test case 3
Table: 8 Test case 4
1.1) INTRODUCTION
The name of the project is Driver Monitoring System , It is a car
safety technology which helps prevent accidents caused by the driver getting
drowsy. According to surveys by the World Health Organization (WHO) on
road accidents, about 1.3 million people die every year on road highways in
2018. Also, a survey report and research provided by the National Highway
Traffic Safety Association (NHTS) on road accidents, about 795 people die from
drowsy-driving and 91,000 people die from motor vehicle crashes involving
drowsy driving in 2017. So, the drowsy driver is considered as one of the
factors for road accidents. Likewise, the researchers show that after 2 to 3
hours, the driver is exhausted and the steering efficiency is also reduced.
Likewise, in the early afternoon, after getting lunch and at midnight, there is a
larger risk. So, in simple terms, drowsiness is defined as a disorder in which a
person feels asleep during active hours. Thus, in this program i.e. Driver
Drowsiness Detection System helped us to research three types of people who
are suffering from drowsiness: they are categorized as awake, rapid eye
movement (REM), and non-rapid eye movement (NREM). Similarly, persons
suffering from non-rapid eye movement are subdivided into three stages. They
are listed below:

Humans have always invented machines and devised techniques to ease

and protect their lives, for mundane activities like traveling to work, or
for more interesting purposes like aircraft travel. With the advancement
in technology, modes of transportation kept on advancing and our dependency
on it started increasing exponentially. It has greatly affected our lives as we
know it. Now, we can travel to places at a pace that even our grandparents
wouldn’t have thought possible. In modern times, almost everyone in this
world uses some sort of transportation every day. Some people are rich
enough to have their own vehicles while others use public transportation.
However, there are some rules and codes of conduct for those who drive
irrespective of their social status. One of them is staying alert while driving.
 DRIVER MONITORING
Driver Monitoring

Figure 1: Different system to detect drowsiness

1.2)PROBLEM STATEMENT
Major studies have suggested that around 20% of all road accidents are
fatigue-related. Drowsy Driving can be extremely dangerous, a lot of road
accidents are related to the driver falling asleep while driving and subsequently
losing control of the vehicle. However, initial signs of fatigue and drowsiness
can be detected before a critical situation arises. Driver Monitoring System is a
car safety technology that helps to prevent accidents caused by drivers getting
drowsy. In this project, we aim to design and develop a driver monitoring
system and use image processing for detecting whether the driver is feeling
fatigued or sleepy, using image processing we detect the eyes of the person
and detect how much time the eyes are closed the driver if the eyes are closed
for greater than 20 sec the speaker included in the system will sound an alert
thus alerting the driver and waking him up, preventing an accident.
The current system in use can detect fatigue and drowsiness, there is no such
functionality for the detection of yawning and head-nodding which will be
helpful to alert the driver in advance about the risk of an accident. Hence, we
decided to add these features to our developed app.
1.3) PROCESS MODEL
A process model is an abstract representation of the development process.
The main motive of creating a process model is to get guidance for controlling
and coordinating the tasks to achieve the end product and objectives as
effectively as possible. After considering all the requirements of this project,
we decided to continue with V-Model.
The V-Model is an extension of the waterfall model and is based on the
association of a testing phase for each corresponding development stage. This
is a highly-disciplined model and the next phase starts only after the
completion of the previous phase. This model is also known as the Verification
and Validation model.
The different Verification phases of the V-Model, are as follows:-

 Requirement Analysis

This is the first phase in the development cycle where the product
requirements are understood from the customer’s perspective. This phase
involves detailed communication with the customer to understand his
expectations and exact requirement.

 System Design

Once the product requirements are clear and detailed, the design of the
complete system is done. The system design will have the understanding and
detailing of the complete hardware and communication setup for the product
under development.

 Architectural Design

Architectural specifications are understood and designed in this phase. The

system design is broken down further into modules taking up different
functionality. This is also referred to as High-Level Design (HLD). The data
transfer and communication between the internal modules and with the
other systems is clearly understood and defined in this stage. With this
information, integration tests can be designed and documented during this
stage.
  Module Design

In this phase, the detailed internal design for all the system modules is
specified, referred to as Low-Level Design (LLD). The design must be
compatible with the other modules in the system architecture and the other
external systems. These unit tests can be designed at this stage based on the
internal module designs.

 Coding Phase

The actual coding of the system modules designed in the design phase is
taken up in the Coding phase. The best suitable programming language is
decided based on the system and architectural requirements. The coding is
performed based on the coding guidelines and standards. The code goes
through numerous code reviews and is optimized for best performance before
the final build is checked into the repository.

The different Validation phases of the V-Model, are as follows:-

 Unit Testing

Unit tests designed in the module design phase are executed on the code
during this validation phase. Unit testing is the testing at the code level and
helps eliminate bugs at an early stage.

 Integration Testing

Integration testing is associated with the architectural design phase.

Integration tests are performed to test the coexistence and communication of
the internal modules within the system.

 System Testing

System testing is directly associated with the system design phase. System
tests check the entire system functionality and the communication of the
system under development with external systems. Most of the software and
hardware compatibility issues can be uncovered during this system test
execution.

 Acceptance Testing

Acceptance testing is associated with the business requirement analysis phase

and involves testing the product in the user environment. Acceptance tests
uncover the compatibility issues with the other systems available in the user
environment.
Fig:2 V model

2.1)REQUIREMENT ANALYSIS
The basic function of requirement analysis is that it translates the ideas
in the mind of the clients into a formal document. Thus the output of
this phase is a set of precisely specified requirements which are
complete and consistent. This document is called Software
Requirement Specification.

2.1.1) Purpose:
Real Time Drowsiness behaviours which are related to fatigue are in the form
of eye closing. head nodding or the brain activity. Hence, we can either
measure change in physiological signals, such as brain waves, heart rate and
blinking to monitor drowsiness or consider physical changes such as sagging
leaning of driver's head and open/closed state of eyes. The former technique,
while more accurate, is not realistic since highly sensitive electrodes k have to
be attached directly on the driver body and hence which can be annoying and
distracting to the driver. In addition, long time working would result in
perspiration on the sensors, diminishing their ability to monitor accurately. The
second technique is to measure physical changes (i.e. open/closed eyes to
detect fatigue) is well suited for real world conditions since it is non-intrusive
by using a video camera to detect changes. In addition, micro sleeps that are
short period of sleeps lasting 2 to 3 minutes are good indicators of fatigue.
Thus, by continuously monitoring the eyes of the driver one can detect the
sleepy state of driver and a timely warning is issued. Driver in-alertness is an
important resulting from sleep deprivation or sleep disorders and is an
important factor in the increasing number of the accidents on today's roads.
Drowsy driver warning system can form the basis of the system to possibly
reduce the accidents related to driver's drowsiness. In a year there were 824
fatalities recorded in NHTSA's FARS database that were drowsy driving-related.
According to the results of the study presented at the International Symposium
on Sleep Disorders, fatigue of drivers is responsible for30% of road accidents[1]
Different techniques are used in driver-fatigue monitoring systems. These
techniques are divided into four categories. The first category includes
intrusive techniques, which are mostly based on monitoring biomedical signals,
and therefore require physical contact with the driver.
The second category includes non-intrusive techniques based on visual
assessment of driver's bio-behaviour from face images. The third category
includes methods based on driver's performance, which monitor vehicle
behaviour such as moving course, steering angle, speed, braking etc. Finally,
the fourth category combines techniques from the above mentioned three
categories. The computer vision based techniques from the second category
are particularly effective, because observing the facial features and visual the
drowsiness can be detected by bio-behaviour such as head position, gaze, eye
openness, eyelid movements, and mouth openness Proposed algorithm is
based on computer vision method. The main focus is on the detection of blinks
by estimating the EAR(Eye aspect Ratio). This is achieved by monitoring the
eyes of the driver throughout the entire video sequence. An IR camera will be
used for capturing live video of driver eyes in all light conditions and frames
will extracted for image processing scheme of video capturing.
2.1.2) Objective:
Driver monitoring system is a car safety technology which helps to save the life
of the driver by preventing accidents when the driver is getting drowsy.
 The main objective is to first design a system to detect driver’s drowsiness by
continuously monitoring retina of the eye.
 The system works in spite of driver wearing spectacles and in various lighting
conditions.
 To alert the driver on the detection of drowsiness by using buzzer or alarm.
 Speed of the vehicle can be reduced.
 Traffic management can be maintained by reducing the accidents.

2.1.3) Project Scope

1. This project can be implemented in the form of a mobile application to
reduce the cost of hardware. The purpose behind this is to make this
system affordable for everyone.
2. The application can detect the drowsiness of the driver and give an
alert which will help to prevent the chances of an accident and can save
one's precious life.
3. The application should have an easy-to-use UI. Some people (mostly
truck drivers) have less knowledge about the different technologies and
applications as a result they are unable to take benefits of such existing
systems, so an easy-to-use UI will remove that barrier also.
4. The application can also take track of your trip. It will keep a record of
the total distance travelled by car during the trip.

2.1.4) Scope for future work :

 The future works may focus on the utilization of outer factors such as
vehicle states, sleeping hours, weather conditions, mechanical data, etc,
 for fatigue measurement. Driver drowsiness pose a major threat to
highway safety, and the problem is particularly severe for commercial
motor vehicle operators. Twenty-four hour operations, high annual
mileage, exposure to challenging environmental conditions, and
demanding work schedules all contribute to this serious safety issue.
Monitoring the driver’s state of drowsiness and vigilance and providing
feedback on their condition so that they can take appropriate action is
one crucial step in a series of preventive measures necessary to address
this problem. Currently there is not adjustment in zoom or direction of
the camera during operation. Future work may be to automatically zoom
in on the eyes once they are localized.
 This project can be integrated with car, so that automatic speed control
can be imparted if the driver is found sleeping.

2.1.5) Environment Used:

Android Studio - IDE used for making the application is android studio.
JAVA - The programming language used is “JAVA”. java is an object oriented
programming language.

2.2) USE CASE APPROACH :

A use case is a software and system engineering term that describes how a
user uses a system to accomplish a particular goal. A use case acts as a
software modelling technique that defines the features to be implemented
and the resolution of any errors that may be encountered.
Use cases define interactions between external actors and the system to attain
particular goals. There are three basic elements that make up a use case:

• Actors: Actors are the type of users that interact with the system.

• System: Use cases capture functional requirements that specify the intended
behaviour of the system.
• Goals: Use cases are typically initiated by a user to fulfil goals describing the
activities and variants involved in attaining the goal.

Use cases are modelled using unified modelling language and are represented
by ovals containing the names of the use case. Actors are represented using
lines with the name of the actor written below the line. To represent an actor's
participation in a system, a line is drawn between the actor and the use case.
Boxes around the use case represent the system boundary.

Characteristics associated with use cases are:

• Organizing functional requirements

• Modelling the goals of system user interactions

• Recording scenarios from trigger events to ultimate goals

• Describing the basic course of actions and exceptional flow of events

• Permitting a user to access the functionality of another event

The steps in designing use cases are:

• Identify the users of the system

• For each category of users, create a user profile. This includes all roles played
by the users relevant to the system.

• Identify significant goals associated with each role to support the system. The
system’s value proposition identifies the significant role.

• Create use cases for every goal associated with a use case template and
maintain the same abstraction level throughout the use case. Higher level use
case steps are treated as goals for the lower level.

• Structure the use cases

• Review and validate the users
Fig3 use case diagram
2.3) DATA FLOW DIAGRAM:
A data flow diagram (DFD) maps out the flow of information for any process or
system. It uses defined symbols like rectangles, circles and arrows, plus short
text labels, to show data inputs, outputs, storage points and the routes
between each destination. Data flowcharts can range from simple, even hand-
drawn process overviews, to in-depth, multi-level DFDs that dig progressively
deeper into how the data is handled.
Fig4: 0 level DFD

Fig5: level 1 DFD

 Fig6: level 2 DFD

2.4) DATA DICTIONARY

A data dictionary is a collection of the names, definitions, and attributes for
data elements and models. The data in a data dictionary is the metadata about
the database. These elements are then used as part of a database, research
project, or information system.
The data dictionary contains information about the following −
● Names of all the database tables and their schemas.
● Details about all the tables in the database, such as their owners, their
security constraints, when they were created etc.
● Physical information about the tables such as where they are stored and
how.
● Table constraints such as primary key attributes, foreign key information etc.
● Information about the database views that are visible.

3.Project Management
Project management is the process of leading the work of a team to achieve all
project goals within the given constraints.[1] This information is usually described in
project documentation, created at the beginning of the development process. The
primary constraints are scope, time, and budget.[2] The secondary challenge is
to optimize the allocation of necessary inputs and apply them to meet pre-defined
objectives

3.1) Functional Point Estimation

Table:1 Function point Estimation

Questions VAFs
Does the system require reliable backup and 0
recovery?
Are specialized data communications required to 5
transfer
information to or from the application?
Are there distributed processing functions? 0
Is performance critical? 2
Will the system run in an existing, heavily utilized 3
operational
environment?
Does the system require on-line data entry? 0
Does the on-line data entry require the input 0
transaction to be
built over multiple screens or operations?
Are the ILFs updated online? 3
Are the inputs, outputs, files, or inquiries complex? 2
Is the internal processing complex? 3
Is the code designed to be reusable? 3
Are conversions and installations included in the 0
design?
Is the system designed for multiple installations in 0
different
organizations?
Is the application design to facilitate change and for 5
ease of use by
the user?
VALUE ADJUSTMENT FACTOR (VAFs) = Σfi = 30

Now ,
CAF(Complexity Adjustment Factor) = 0.65 + (0.01 * Σfi)

=0.65+ (0.01*26)

=0.65+ (0.26)

=0.91
Table:2 Complexity Adjustment Factor

INFORMATION COUNT WEIGHING WEIGHING

DOMAIN FACTOR (average) COUNT
VALUE

EXTERNAL 1 7 7
INPUT
EXTERNAL 2 7 14
OUTPUT
EXTERNAL 5 6 30
ENQUIRY
INTERNAL 0 10 0
LOGIC FILES
EXTERNAL 0 10 0
INTERFACE FILES

TOTAL=51

COMPUTING FUNCTION POINTS:

FP = UFP * (0.65 + 0.01 * Σfi)
FP = UFP * CAF
FP= 51*0.91
FP=46.41

3.2 Effort Estimation

Assume that the past data shows that the complexity for these types of
systems is 5 function point per month. Assume burdened labour cost of 2500,
the cost per fp is Rs 500.
Estimated project cost-500*46.41 = 23,205
Estimated effort = 46.41/5 = 9.3

3.3 Cost Estimation

Total cost of the project: Total effort* labour rate

= 9.3×2500
=₹ 23,250

3.4 RISK MANAGEMENT

Risk is the possibility of suffering loss, and total risk exposure to a specific
project will account for both the probability and the size of the potential loss.
Identifying and aggregating risks is the only predictive method for capturing
the probability that a software development project will experience unplanned
or inadmissible events. These include terminations, discontinuities, schedule
delays, cost underestimation, and overrun of project resources.

1. Lack of skills :
To improve the performance of software, a number of practices are
encouraged that serve to control certain risks in the development
process, including a lack of essential skills and knowledge related to
the application domain and system development process.
 2. App Crash:
A app crash itself is not crucial, but rather the loss of data will result
in not being able to deliver the output to the customer.
3. Less friendly interface:
The app in its very initial stages can be a little bit less friendly to the
user. This can decrease the interest of the user and belief to use the
app . As we all know the major requirement of the app is making it as
simpler and easy to handle as possible.
4. Requirement changes:
It can occur due to changes in user requirement, increased
understanding of the stakeholders’ needs, or availability of new
technologies.

RISK TABLE:
Table: 3 Risk table

RISK PROBABILITY CATEGORY IMPACT

APP CRASH 30% TECHNICAL RISK 1

LACK OF SKILLS 20% PROJECT RISK 1
LESS FRIENDLY 20% PROJECT RISK 2
INTERFACE
REQUIREMENT 25% PROJECT RISK 2
CHANGES

RISK MITIGATION, MONITORING AND MANAGEMENT:

Mitigation
The cost associated with a computer crash resulting in a loss of data is crucial.
A computer crash itself is not crucial, but rather the loss of data. A loss of data
will result in not being able to deliver the product to the customer. As a result,
the organization is taking steps to make multiple back-up copies of the
software in development and all documentation associated with it, in multiple
locations.
Monitoring
When working on the product or documentation, we should always be aware
of the stability of the computing environment they are working in. Any changes
in the stability of the environment should be recognized and taken seriously.
Management
The lack of stable-computing environment is extremely hazardous to a
software development team. In the event that the computing environment is
found unstable, the development team should cease the work on that system
until the environment is made stable again, or should move to a system that is
stable to use and continue working there.
Fig7 Risk Management
 TIMELINE CHART:
Table: 4 Timeline chart

MONTH 1 MONTH 2 MONTH 3 MONTH 4

W W W W W W W W W W W W W W W W
TASK 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Complete project
execution
Problem Statement
Problem Solution
Process Model
Discussion with
Clients
Beacon Ordering
Supervision and
meetings
Software and
hardware
requirement
Schedule Estimation
Effort Estimation
Cost Estimation
Risk Analysis
Architectural Design
Use Case Approach
Data Flow Diagram
Sequence Diagram
Data Dictionary
UI Design
Coding Software
Implementation
Testing
Maintenance
Documentation

4 DESIGN ENGINEERING
The design phase of software development deals with transforming the
customer requirements as described in the SRS documents into a form
implementable using a programming language. The software design process
can be divided into the following three levels of phases of design:
1. Interface Design
2. Architectural Design
3. Detailed Design

Fig 8: design engineering

4.1 ARCHITECTURAL DESIGN

Architectural design is the specification of the major components of a
system, their responsibilities, properties, interfaces, and the
relationships and interactions between them. In architectural design, the
overall structure of the system is chosen, but the internal details of
major components are ignored.
The architectural design adds important details ignored during the
interface design. Design of the internals of the major components is
ignored until the last phase of the design.

4.2 PSUEDOCODE EXPLANATION FOR CODE :

Begin

Input driver's video

ClosedEyeCount := 0

For every tenth frame in the video Do

Localize eyes

Check status of eyes

If eyes are closed Then

ClosedEyeCount := ClosedEyeCount + 1

Else If eyes are open Then

ClosedEyeCount := 0

End If

If ClosedEyeCount == 3 Then

Generate Alarm

ClosedEyeCount := 0

End If

End For

End
4.3) UI DESIGN:
5) IMPLEMENTATION :
 SOFTWARE TESTING
“Testing is the process of executing the program with the intent of finding
errors.”
Software testing is a critical element of software quality assurance and
represents the ultimate review of specification, design, and code generation.
Once source code has been generated, software must be tested to uncover as
many tests as possible before delivery to the customer.

6.1 SOFTWARE TESTING FUNDAMENTALS

A strategy for software testing provides a road map that describes the steps to
be conducted as part of testing, when these steps are planned and then
undertaken, and how much effort, time, and resources will be required.
Therefore, any testing strategy must incorporate test planning, test case
design, test execution, and resultant data collection and evaluation. At the
same time, it must be rigid enough to encourage reasonable planning and
management tracking as the project progresses. It must accommodate low-
level tests that are necessary to verify that a small source code segment has
been correctly implemented as well as high-level tests that validate major
system functions against customer requirements.
The terms verification & validation are often confused and used
interchangeably but have different meanings. Verification is the process of
evaluating a system or component to determine whether the products of a
given development phase satisfy the condition imposed at the start of that
phase. Hence verification activities are applied to early phases in SDLC such as
requirements, design, planning etc. We check and review the documents
generated after completion of every phase in order to ensure that what comes
out of that phase is 65 what we expected to get. Whereas validation is the
process of evaluating a system or component during or at the end of the
development process to determine whether it satisfies the specific
requirements. Therefore, validation requires actual execution of the program
and is also known as computer based testing. We experience failures and
identify the causes of the failure. Hence testing includes both validation and
verification.
 The terms alpha and beta testing are used when the software is developed as
a product for anonymous customers. Hence formal acceptance testing is not
possible in such cases. However, some potential customers are identified to
get their views about the product. The alpha tests are conducted at the
developer’s site by a customer. These tests are conducted in a controlled
environment. The beta tests are conducted by the customers/end users at
their sites. Unlike alpha testing, developer is not present here. Beta testing is
conducted in a real environment that cannot be controlled by the developer.
Customers are expected to report failures, if any, to the company. After
receiving such failure reports, developers modify the code and fix the bug and
compare the product after the final release.
Table4: Eye Blink detection module accuracy:
 MAINTENANCE
With the term System Maintenance it actually refers to the changes need to
be made to a system after it has been implemented. Changes may be required
to fix bugs or to make enhancements to the system in order to accommodate
new user requirements or adapt to new hardware or software.
Users may notice an error in certain type of files which are not compatible with
the software. Maintenance would be required to fix this bug. Whenever a user
notices an error in the software or an enhancement is required, he passes on
the finding and requirements to the software maintenance department. The
analyst in the department identifies the impacted items (problem areas),
corrects them, tests the package and requests the user to check if the request
has been serviced properly.
Software maintenance can be defined as the process of changing a system
after it has been delivered and is in use. It is basically the process of changing a
system to maintain its ability to survive. Software Maintenance is the process
of modifying a software product after it has been delivered to the customer.
The main purpose of software maintenance is to modify and update software
application after delivery to correct faults and to improve performance.

7.1 Need for Maintenance Software Maintenance must be

performed in order to:
 Correct faults.
 Improve the design.
 Implement enhancements.
 Interface with other systems.
 Accommodate programs so that different hardware, software, system
features, and telecommunications facilities can be used.
 Migrate legacy software.
 Retire software.
7.2 Categories of Software Maintenance Maintenance can be
divided into the following:
 Corrective maintenance:
Corrective maintenance of a software product may be essential either to
rectify some bugs observed while the system is in use, or to enhance the
performance of the system.
 Adaptive maintenance:
This includes modifications and updations when the customers need the
product to run on new platforms, on new operating systems, or when they
need the product to interface with new hardware and software.
 Perfective maintenance:
A software product needs maintenance to support the new features that the
users want or to change different types of functionalities of the system
according to the customer demands.
 Preventive maintenance:
This type of maintenance includes modifications and updations to prevent
future problems of the software. It goals to attend problems, which are not
significant at this moment but may cause serious issues in futur

8) LIMITATIONS OF THE SOFTWARE:

1.Dependence on ambient light:- With helpless lighting conditions
despite the fact that face is effectively identified, now and again the
framework can't identify the eyes. So it gives an erroneous result which must
be dealt with. Continuously situation infrared backlights ought to be utilized
to maintain a strategic distance from helpless lighting conditions.

2.Optimum range required When the separation among face and webcam
isn't at ideal range then certain issues are emerging. At the point when face is
away from the webcam (more than 70cm) at that point the backlight is
deficient to light up the face appropriately. So eyes are not identified with high
exactness which shows mistake in detection of laziness. This issue isn't
genuinely considered as progressively situation the separation between
drivers face and webcam doesn't surpass 50cm. so the issue never emerges.
Considering the above difficulties, the optimum separation go for
drowsiness identification is set to 40-70 cm.

3.Hardware Requirement:- Our framework was run in a PC with a

design 2.2GHz and 2GB RAM Pentium double center processor. In spite
of the fact that the framework runs fine on higher designs, when a framework
has an inferior design, the framework may not be smooth and drowsiness
discovery will be moderate. The issue was settled by using committed
equipment progressively applications, so there are no issues of casing
buffering or more slow identification.

4.Delay in sounding alarm:- When drowsiness level surpasses a certain limit,

an alarm is delivered by a framework speaker. It requires a media player to
run the sound record. There is a noteworthy deferral between when drowsiness
is recognized and when the media player begins and creates the alarm. Be thatas
it may, progressively, drowsiness is a continuous wonder as opposed to a
coincidental event. So the deferral isn't unreasonably hazardous.

5.Orientation of face:- when the face is inclined to a limited degree it tends to

be distinguished, however past this our framework neglects to recognize the
face. So when the face isn't recognized, eyes are likewise not detected.This
issue is settled by utilizing following capacities which track any development
and turn of the items in a picture. A prepared classifier for inclined face and
inclined eyes can likewise be utilized to keep away from this sort of issue.

6.Problem with multiple faces :-If more than one face is identified by the
webcam, at that point our framework gives an incorrect outcome. This issue
isn't significant as we need to recognize the laziness of a solitary driver.

8.1) FUTURE IMPROVEMENTS

• Interface of the app can be made more user friendly and easy to use.
• Latest technology and IoT devices can be used to enhance user experience.
• Precise detection of obstacles in the path can also be done through latest
hardware and software technologies for providing more convenience to user.
• A well defined systematic approach needs to be used to collect the
feedback from our users from time to time and to constantly put efforts to
remove problems and improve efficiency.
9) CONCLUSION
Drowsy driving is a serious threat to drivers and traffic participants. The
present’s system lacks one or the other important feature that provides non-
reliable results. Our proposed system will overcome these drawbacks and
provide accurate and reliable results. The general flow of our drowsiness
detection algorithm is fairly straightforward. A camera is setup to monitor
stream of faces. After which, we apply facial landmark detection and extract
the eye regions.

We can compute the eye aspect ratio to determine if the eyes are closed.
Video segments whose average eye state point exceeds the threshold value
are detected as drowsy and the driver is alerted. The system can also be used
efficiently in locomotives and aero planes. It has a wide scope in the future and
can be improved to meet excellence.
In the future, this thesis will be a part of a safety system being used in vehicles
and help us save many lives. In near future, the project can be improved to
detect passenger faces and only focus on the driver's face. The vehicle
manufacturers can make this system inbuilt by using the dashboard screen and
speakers. The system can be effectively used in locomotives and flights for
detecting driver drowsiness. System can be improved to detect and track eyes
even if the driver is wearing shades.
10) BIBLIOGRAPHY:

1. SOFTWARE Engineering: A Practitioner’s

Approach. 8th edition. McGraw-Hill.
2. •Aggarwal, K. K., & Singh, Y. (2007). Software
Engineering.
3. •Indoor Navigation System - Bachelor’s Thesis :
Milan Herrera Vargas
4. •en.wikipedia.org
• www.google.com
•www.slideshare.net
•www.tutorialspoint.com