Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Student Attendance and Monitoring System Based On Fingerprint Recognition

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 43

CHAPTER I

INTRODUCTION

1.1Problem Definition
In older method we took attendance using paper & there is possibility of proxy and it
is hassles of roll calling. This increases manual work of teachers such as attendance
calculation.
Designing a better attendance management system for students so that records are
maintained with ease and accuracy was an important key behind motivating this
project.
This would improve accuracy of attendance records because it will remove all the
hassles of roll calling and will save valuable time of the students as well as teachers.
Designing a student attendance management system based on fingerprint recognition
and faster identification that manages records for attendance in institutes.

1.2 What is BIOMETRICS?


Biometrics involves identifying a person based on a unique physical characteristic
that is different from any other person. Biometrics can be either innate such as
fingerprints, face or iris; or behavioural such as handwriting, gait or typing style.
Biometric characteristics are measured using sensors that produce data values that
can then be processed by a computer using specialized algorithms for analysis and
comparison. Biometric system is the integrated biometric hardware and software
used to conduct biometric identification or verification.

1.3 What is Fingerprint?


A Fingerprint is the pattern of ridges and valleys on the surface of a fingertip. The
endpoints and crossing points of ridges are called minutiae. It is a widely accepted
assumption that the minutiae pattern of each finger is unique and does not change
during one's life. Ridge endings are the points where the ridge curve terminates; and
bifurcations are where a ridge splits from a single path to two paths at a Y-junction.
Figure 1 illustrates an example of a ridge ending and a bifurcation. In this example
the black pixels correspond to the ridges, and the white pixels correspond to the
valleys.

Figure 1.3: A ridge ending and a bifurcation


When human fingerprint experts determine if two fingerprints are from the same
finger, the matching degree between two minutiae pattern is one of the most
important factors. Thanks to the similarity to the way of human fingerprint experts
and compactness of templates, the minutiae-based matching method is the most
widely studied matching method.

1.4 Why Use Fingerprints?


Fingerprints are considered to be the best and fastest method for biometric
identification. They are secure to use, unique for every person and do not change in
one's lifetime. Besides these, implementation of fingerprint recognition system is
cheap, easy and accurate up to satisfiability. Fingerprint recognition has been widely
used in both forensic and civilian applications. Compared with other biometrics
features, fingerprint-based biometrics is the most proven technique and has the
largest market shares. Not only it is faster than other techniques but also the energy
consumption by such systems is too less .
1.5 Using Fingerprint recognition system for attendance management:
Managing attendance records of students of an institute is a tedious task. It consumes
time and paper both. To make all the attendance related work automatic and on-line,
we have designed an attendance management system .It uses a fingerprint
identification system developed in this project.
1.6 Future Scope:

1.7 Objectives:
This system takes daily accurate attendance of students.

The system also generates monthly average attendance of students and send the sms
To the parent as well as student.
Student monitoring for searching the student in college campus as per his/her time
table.

CHAPTER II
REQUIREMENT ANALYSIS
2.1 Requirement

Software requirement engineering is a process of discovery, refinement, modeling,


and specification. Requirement analysis is a software engineering task that bridges
gap between system-level requirements engineering and software design.

Figure 2.1: Analysis a bridge between system engineering and


software design

Requirements analysis enables the system engineer to specify software function and
performance, indicate software interface with other system elements, and establish
constraints that software must meet. Requirements analysis allows the software
engineer to refine the software allocation and build models of data, functional and
behavioral domains that will be treated by software. Requirements analysis provides
the software designer with a representation of information, function, and behavior
that can be translated to data, architectural, interface, and component-level designs.
We use matching algorithm that accurately calculate attendance and store in the
database of particular student.
2.1.1Normal:
Normal requirement of our system is to takes student attendance using finger print.
So there is no possibility of proxy and also there is no hassle of roll calling.

2.1.2Expected:
Expected requirement of our system is to calculate average attendance of student as
per week, month & semester and also send the sms to parents.

2.1.3Excited:
Excited requirement of our system is to monitor student i.e. Shows the class room or
lab of student as per his/her time table.

2.2 Facilitated Application Techniques


This approach encourages the creation of a joint team of customers and developers
who work together to identify the problem, propose elements of the solution,
negotiate different approaches and specify a preliminary set of solution requirements.
FAST has been used predominantly by the information systems community, but the
technique offers potential for improved communication in applications of all kinds.
By using the FAST approach we start our project development
1) Our Project approach define by using FAST

By using the FAST approach we start our project development firstly we search the
topics for admin applications. We take the IEEE paper for biometrics attendance
system. We are inspiring from that paper & develop our system. Our system is
mainly used for taking attendance of student.
After that we discuss with our project guide & other faculty member on that paper. &
we present our own ideas to the teachers & we get the suggestion from all of those.
We analyze the entire requirement for that project Using all suggestion & ideas we
start the development of these project.
2) Model

This is a recent model that has been proposed by Boehm. As the name suggests, the
activities in this model can be organized like a spiral. The spiral has many cycles.
The radial dimension represents the cumulative cost incurred in accomplishing the
steps dome so far and the angular dimension represents the progress made in
6

completing each cycle of the spiral. The structure of the spiral model is shown in the
figure given below. Each cycle in the spiral begins with the identification of
objectives for that cycle and the different alternatives are possible for achieving the
objectives and the imposed constraints.
3) Business Modeling

The information flow among business functions in a way distributor distribute


records to the multiple agents & based on the probability we decide the guilty agent
by comparing the target & sample data by using specific algorithm given in IEEE
paper..
4) Data Modeling:

The information flow defined as part of the business modeling phase. In data
modeling we define the relationship between the entire object which is use in our
system.
5) Process Modeling

We process all the object which is defines in the data modeling. In process modeling
us actually perform the comparison between sample data & target data and calculate
probability.
Many different approaches to FAST have been proposed. Each makes use of a
slightly different scenario, but all apply some variation on the following basic
guidelines:
1. A meeting is conducted at a neutral site and attended by both our project team
and administrator.
2. Rules for preparation and participation are established.
3. An agenda is suggested that is formal enough to cover all important points but
informal enough to encourage the free flows of ideas.
4. Our project facilator means the Developer & customer means the distribute
controls the meeting by this approach the communication between
administrator and our team member will be successful.
5. The goal is to identify the problem, propose elements of the solution,
negotiate different approaches, and specify a preliminary set of solution

requirements in an atmosphere that are conductive to the accomplishment of


the goal.
6. To better understand the flow of events as they occur in a typical FAST
meeting, we present a brief scenario that outlines the sequence of events that
lead up to the meeting, occur during the meeting, and follow the meeting.
7. Initial meetings between the developer and administrator occur and basic
questions and answers help to establish the scope of the problem and the
overall perception of a solution. Out of these initial meetings, the developer
and Administrator write a one- or two-page "product request." A meeting
place, time, and date for FAST are selected and a facilitator is chosen.
Attendees from both the development and user organizations are invited to
attend. The product request is distributed to all attendees before the meeting
date.

2.3 Specification of Requirement


A software requirements specification is a comprehensive description of the intended
purpose and environment for software under development. The SRS fully describes
what the software will do and how it will be expected to perform.
An SRS minimizes the time and effort required by developers to achieve desired
goals and also minimizes the development cost. A good SRS defines how an
application will interact with system hardware, other programs and human users in a
wide variety of real-world situations.

2.3.1 Task Identification Plan:

Initiating the system analysis to first goal was to understand the existing manual
system and the functionality provided by it, and more importantly, the objective is
that needed to be achieving objective. We have analyzed the entire educational
system for Institute. The entire analysis is performed in different phases:
1. Understand The Definition:
Firstly we understand that what problem is comes to teacher to taking
attendance of student i.e. teacher take attendance on paper.
2. Primary Goal Of The System:
The primary goal of our system is comparison between fingerprint that store
in database and student fingerprint then taking attendance depends on it.
3. Scope:
In future services may be because this application for the other purpose such as
we also used ID card for attendance and search location of student.
4. User Requirement:
The main requirement of the teacher is to check the report of student.
5. Technical Requirement:
We require the detail knowledge about database, C#, Verifinger DB.
6. Functional Requirement:
We use functions like attendance which check the fingerprint of student in
database and take attendance. The search function is use to see the classroom of
student.

2.4 Validation of Requirements


Requirements validation is an iterative process which takes place throughout the
lifecycle of the project. During elicitation, analysis and specification you should
constantly be questioning and clarifying the data given to you in order to check its
validity. This will ensure that the SRS that you produce is complete, consistent and
ready for the formal validation process.

2.4.1 Object Oriented Analysis:


Object oriented analysis is basically concerned with decomposition of problem into
its component, parts and establishing the logical model to describe the system
function. We follow this analysis as for the project.

2.4.2 Understanding the Problem:


This is the first step in the analysis process. The problem statement should be refined
and redefined in terms of computer system engineering that could suggest a
computer based solution. The problem statement should be stated, as far as possible,
in a single, grammatically correct sentence.
The problem statement provides the basic for drawing the requirements specification
of both the users and software.

2.5 Hardware Requirement (minimum):


RAM 216 MB
1.83 GHz Intel Core2Duo processor

10

Hard Disk - 40GB.


BIOMETRIC Device SM 511

2.6 Software Requirement (minimum):


Microsoft Visual Studio 2012.
Nex Serial Monitor.
Nex USB TTL.
MSAccess10.
OS windows XP and above version.

2.7 Breakdown Structure


Breakdown structure is a hierarchical and incremental decomposition of the project
into phases, deliverables and work packages. It is a tree structure, which shows a
subdivision of effort required to achieve an objective; for example a program,
project, and contract. In a project or contract, the WBS is developed by starting with
the end objective and successively subdividing it into manageable components in
terms of size, duration, and responsibility (e.g., systems, subsystems, components,
tasks, subtasks, and work packages) which include all steps necessary to achieve the
objective.
2.7.1 User Registration:
User Registration module use for registration of student. In which details of the
student is taken and fingerprint of the student is store in database.
2.7.2 Validation:
Validation module is use for validating the student when taking attendance of student
that means it check the fingerprint of student and image of fingerprint store in
database.
11

2.7.3 Attendance:
This module used to taking attendance of student and store in database for further
use.
2.7.4 User Adding & Deleting
In this module student are add and delete is done.
2.7.5 Searching
In searching module the class room of the student is shown & this is done through
time table of the student.
2.7.6 View
In this module class room of the student is highlighted on search module

2.7.7Report Generation
Report generation module generates report of attendance on weekly, monthly and
semester basis.

2.8 Project Estimation


The Constructive Cost Model (COCOMO) is an algorithmic Software Cost
Estimation Model developed by Barry Boehm. The model uses a basic regression
formula, with parameters that are derived from historical project data and current
project characteristics.
Basic COCOMO is a static, single-valued model that computes software
development effort (and cost) as a function of program size expressed in estimated
lines of code.
1. Line of Code
This is the number of lines of the delivered source code of the software, excluding
comments and blank lines and is commonly known as LOC. Although LOC is
programming language dependent, it is the most widely used software size metric.
Most models relate this measurement to the software cost. However, exact LOC can
only be obtained after the project has completed. Estimating the code size of a
program before it is actually built is almost as hard as estimating the cost of the
program.
12

2. Function points
This is a measurement based on the functionality of the program and was first
introduced by Albrecht. The total number of function points depends on the counts of
distinct (in terms of format or processing logic) types in the following five classes:
1. User-input types: data or control user-input types.
2. User-output types: output data types to the user that leaves the system.
3. Internal file types: files (logical groups of information) that are used and
shared inside the system
4. External file types: files that are passed or shared between the system and other
systems FPs can be used to estimate LOC depending on the average number of LOC
per FP for a given language:
LOC = AVC * number of function points
AVC is a language dependent factor varying from 200300 for assembles language to
240 for a 4GL.Estimation predicts the efforts and schedule of software
Generally there are the classes of the software project:
1) Organic Mode Projects
2) Semi-Detached Projects
3) Embedded Projects
1) Organic Mode Projects:
In this class relatively small simple software projects with a small team are handle
such a team have good application experience to less rigid requirements.
2) Semi-Detached Projects:
In this class an intermediate projects in which teams with mixed experience level are
handled. Such projects may have mix of rigid and less than rigid requirements.
3) Embedded Projects:
13

In this class projects with tight hardware, software and operational constraints are
handled.

Equations:
E = a (KLOC) ^ b
D = c (E) ^ d
P=E/D
Where E is the effort applied in person-month.
D is the development time in months.
KLOC means Kilo lines of code for the project.
P is total number of persons required to accomplish the project.
The coefficients a, b, c, d for the three modes is given below:
Class of software project

Coefficients

Software projects

Organic
Semi-Detached
Embedded

2.4
3.0
3.6

1.05
1.12
1.20

2.5
2.5
2.5

0.38
0.35
0.32

Table 2.8: Constant Values for coefficient

14

CHAPTER III
SYSTEM ANALYSIS
3.1 Project Scheduling and Tracking:
We have scheduled our project work to be done as per the week basis i.e. on three
days of the week those are Wednesday, Thursday and Friday. The work had been
assigned as well as checked for completion on these days. The work for the week are
been divided between the group members as per the need. A task is assigned to us by
our project guide and we spent two hours on the project i.e. three days in a week
when all group members are together as well as individual work is also allotted to us.
At the beginning we collected research paper for our project and for the
starting of this project we did the requirement analysis. In the later phase we
constructed different diagrams for the project such as DFD,E-RD,CFD. At last we
performed designing of the layout. This documentation helps us to understand the
task performed up till now and the work to be carried future.

3.2 Timeline Chart:


Sr.N
o
1
2
3
4
5
6

Task

July

Preliminary Tasks
Contact To Department
Initial Meeting With
HOD
Searching And Topic
Finalization
Submission Of Primary
Document
Correction and Final
Document
Report To Guide

15

Aug

Sep

Oct

7
8
9
10

Synopsis submission
Requirement Analysis
Analysis And Record
View
Literature Survey
Preparation of Modular
View
Design

11
12
13
14
15

Data Flow
Entity Relationship
Diagram
Control Flow Diagram
Design user interface,
form screen layout
Design of all UML
diagram

Sr.No

Task

Jan

Feb

Preliminary Tasks
16
17

Functional Implementation
Database and GUI connection
coding

18

Testing Of Modules

29

Reverse Engineering

20

Documentation
Table 3.2: Timeline chart

16

Mar

Ap
r

3.3Tracking- Preparing Project Table:


Tasks

Communicatio

Planned

Actual

Planned

Actual

Effort

Start

Start

D End

End

Assignment

07/08/2013

07/08/2013

10/08/2013

11/08/2013

Bapusaheb

n
Requirement

Nikhil
14/08/2013

14/08/2013

20/08/2013

20/08/2013

gathering
Project

Nikhil
21/08/2013

21/08/2013

22/08/2013

23/08/2013

Initiation
Planning

Swati
Bapusaheb
Swati
Bapusaheb
Nikhil

24/08/2013

27/08/2013

30/8/2013

30/8/2013

Swati
Bapusaheb
Nikhil

Scheduling

1/09/2013

1/09/2013

3/09/2013

3/09/2013

Swati
Swati

Estimation

05/09/2013

05/09/2013

07/09/2013

07/09/2013

Nikhil
Swati

Analysis

10/09/2013

10/09/2013

12/09/2013

12/09/2013

Bapusaheb
Nikhil

Requirement

15/09/2013

15/09/2013

20/09/2013

20/09/2013

Swati
Bapusaheb

specification
Functional

20/09/2013

20/09/2013

21/09/2013

22/09/2013

Swati

description
Non-functional

22/09/2013

22/09/2013

23/09/2013

23/09/2013

Nikhil
Nikhil

description
SRS document

22/09/2013

22/09/2013

23/09/2013

23/09/2013

Bapusaheb

17

Nikhil
Design

23/8/2013

23/8/2013

10/9/2013

10/9/2013

Swati
Bapusaheb

Use Case

24/9/2013

24/9/2013

25/9/2013

25/9/2013

Swati
Bapusaheb

diagram
DFD diagram

25/9/2013

25/9/2013

26/9/2013

26/9/2013

Swati

Architecture

26/9/2013

26/9/2013

30/9/2013

30/9/2013

Nikhil

27/1/13

2/2/13

30/3/13

Bapusaheb,

6/4/13

Nikhil, Swati
Bapusaheb,

9/4/13

Nikhil,Swati
Bapusaheb,

diagram
Construction
Testing
Documentation

26/1/13
31/3/13
7/4/13

1/4/13

5/4/13

7/4/13

8/4/13

Nikhil,Swati.
Table 3.3: Tracking-preparing project table

3.4 Analysis Model


The analysis model describes the structure of the system or application that you are
modeling. It consists of class diagrams and sequence diagrams that describe the
logical implementation of the functional requirements that you identified in the use
case model. The analysis model identifies the main classes in the system and
contains a set of use case realizations that describe how the system will be built.
Class diagrams describe the static structure of the system by using stereotypes to
model the functional parts of the system. Sequence diagrams realize the use cases by
describing the flow of events in the use cases when they are executed. These use case
realizations model how the parts of the system interact within the context of a
specific use case.

18

3.4.1 Spiral Model:


This is a recent model that has been proposed by Boehm. As the name suggests, the
activities in this model can be organized like a spiral. The spiral has many cycles.
The radial dimension represents the cumulative cost incurred in accomplishing the
steps dome so far and the angular dimension represents the progress made in
completing each cycle of the spiral. The structure of the spiral model is shown in the
figure given below. Each cycle in the spiral begins with the identification of
objectives for that cycle and the different alternatives are possible for achieving the
objectives and the imposed constraints.
The next step in the spiral life cycle model is to evaluate these different alternatives
based on the objectives and constraints. This will also involve identifying
uncertainties and risks involved. The next step is to develop strategies that resolve
the uncertainties and risks. This step may involve activities such as benchmarking,
simulation and prototyping. Next, the software is developed by keeping in mind the
risks. Finally the next stage is planned.
Figure depicts a spiral model that contains six task regions:

Figure 3.4.1: Spiral Model phases

Customer communicationtasks required to establish effective communication


between developer and customer.
Planningtasks required to define resources, timelines, and other project related
information.
19

Risk analysistasks required to assess both technical and management risks.


Engineeringtasks required to build one or more representations of the application.
Construction and releasetasks required to construct, test, install, and provide
user support (e.g., documentation and training).
Customer evaluationtasks required to obtain customer feedback based on
evaluation of the software representations created during the engineering stage and
implemented during the installation stage. Each of the regions is populated by a set
of work tasks, called a task set, that are adapted to the characteristics of the project to
be undertaken. For small projects, the number of work tasks and their formality is
low. For larger, more critical projects, each task region contains more work tasks that
are defined toachieve a higher level of formality.
management and software quality assurance)

20

Software configuration

Figure 3.4.2: Spiral Model

The development spiral consists of four quadrants as shown in the figure above
Quadrant 1: Determine objectives, alternatives, and constraints.
Quadrant 2: Evaluate alternatives, identify, and resolve risks.
Quadrant 3: Develop, verify, next-level product.
Quadrant 4: Plan next phases.
Although the spiral, as depicted, is oriented toward software development, the
concept is equally applicable to systems, hardware, and training, for example. To
better understand the scope of each spiral development quadrant, lets briefly address
each one.
Quadrant 1: Determine Objectives, Alternatives, and Constraints
Activities performed in this quadrant include:
Establish an understanding of the system or product objectivesnamely
performance, functionality, and ability to accommodate change. Investigate
implementation alternativesnamely design, reuse, procure, and procure/ modify
Investigate constraints imposed on the alternativesnamely technology, cost,
schedule, support, and risk. Once the system or products objectives, alternatives,
and constraints are understood, Quadrant 2 (Evaluate alternatives, identify, and
resolve risks) is performed.
Quadrant 2: Evaluate Alternatives, Identify, Resolve Risks
Engineering activities performed in this quadrant select an alternative approach that
best satisfies technical, technology, cost, schedule, support, and risk constraints. The
focus here is on risk mitigation. Each alternative is investigated and prototyped to
reduce the risk associated with the development decisions. Boehm describes these
activities as follows: This may involve prototyping, simulation, benchmarking,
reference checking, administering, user, questionnaires, analytic modeling, or
21

combinations of these and other risk resolution techniques. The outcome of the
evaluation determines the next course of action.
Quadrant 3: Develop, Verify, Next-Level Product
If a determination is made that the previous prototyping efforts have resolved the
COIs/CTIs, activities to develop, verify, next-level product are performed. As a
result, the basic waterfall approach may be employedmeaning concept of
operations, design, development, integration, and test of the next system or product
iteration. If appropriate, incremental development approaches may also be
applicable.
Quadrant 4: Plan Next Phases
The spiral development model has one characteristic that is common to all models
the need for advanced technical planning and multidisciplinary reviews at critical
staging or control points. Each cycle of the model culminates with a technical review
that assesses the status, progress, maturity, merits, risk, of development efforts to
date; resolves critical operational and/or technical issues (COIs/CTIs); and reviews
plans and identifies COIs/CTIs to be resolved for the next iteration of the spiral.
3.4.2 Behavioral Modeling:
Behavioral models are used to describe the overall behavior of a system.
3.4.2.1 Use case Diagram:
To model a system the most important aspect is to capture the dynamic behavior. To
clarify a bit in details, dynamic behavior means the behavior of the system when it is
running /operating.

22

Registration
Registration

Regular
attendance

Attendance
User

System

Monitor the
student

Maintain the
Database

Display Student
Details

Figure 3.4.2.1: Use case diagram


3.4.3 Functional Modeling:
Functional model in system engineering and software engineering is a
structured representation of

the functions (activities, actions, processes, operations)

within the modeled system . The purposes of the function model are to describe the
functions and processes, assist with discovery of information needs, help identify
opportunities, and establish a basis for determining product and service costs.

23

3.4.3.1 DFD Diagram:


A data-flow diagram (DFD) is a graphical representation of the "flow" of data
through an information system. DFDs can also be used for the visualization of data
processing (structured design).

Figure 3.4.3.1.1: Level 0 DFD

Figure 3.4.3.1.2: Level 1 DFD

24

Figure 3.4.3.1.3: Level 2 DFD

25

CHAPTER IV
SYSTEM DESIGN
4.1 Data Design
4.1.1 ER Diagram

Figure 4.2.1: ER-Diagram

26

4.1.2 Class Diagram:


The class diagram is a static diagram. It represents the static view of an application.
The class diagram describes the attributes and operations of a class and also the
constraints imposed on the system.

Attendance
No. of Stud:Integer

Store()
Update()

Monitor
1

Find()

Registration

Stud_Name:String
Stud_Adress:String
Stud_ID:Integer

Validation

Stud_ID

location:String

Report
Add_data()
Delete()
Display()

Match()

Stud_info:String

Diplay()

Figure 4.2.2: Class Diagram

27

4.2Procedeural Diagram
4.2.1 Activity Diagram:
Activity diagram is basically a flow chart to represent the flow form one activity to
another activity. The activity can be described as an operation of the system.

Registration
if

Successful

if
not
Registor

Take Attendance

Monitor student

if

if
not

Found

Display Student
Detail

Generate Avarage
attendance Report

Figure 4.3.1: Activity Diagram

28

4.2.2 Sequence Diagram:


From the name Interaction it is clear that the diagram is used to describe some type
of interactions among the different elements in the model. So this interaction is a part
of dynamic behavior of the system.
This interactive behavior is represented in UML by two diagrams known as
Sequencediagram.

student

System

Database

1: Registration
2: Take Regular
attendance

4:Enter name of
Student

3:Class
Attendance Report

5:Monitor The
Student

6:Display student
Details

7: Generate
Avarage
Attendance

8:Maintain the
Databasee

Figure 4.3.2: Sequence Diagram

29

4.2.3 Collaboration Diagram:


This interactive behavior is represented in UML by two diagrams known as
Sequence diagram and Collaboration diagram. The basic purpose of collaboration
diagram is collaboration diagram emphasizes on the structural organization of the
objects that send and receive messages.

30

31

Figure 4.3.3: Collaboration Diagram

4.2.4 Deployment Diagram:


Deployment diagrams are used to visualize the topology of the physical components
of a system where the software components are deployed.

Biometric
Device

Student
Database

Server

Printer

Rna
M
d
o
cren
iti:a

32

ae
Gee
e
e
o
v
trp
raag
ran
tr:

Figure 4.3.4: Deployment Diagram

n4
d
m
suote
eEtr:ne
fa

5:Moni
co

6
Report

4.2.5 Component Diagram:


Component diagrams are used to visualize the physical components in a system.
Component diagrams can also be described as a static implementation view of a
system. Static implementation represents the organization of the components at a
particular moment.

Monitor.java

Register.Java

Report.Java

Figure4.3.5: Component Diagram

33

CHAPTER V
SNAPSHOTS
5.1 Login:

Figure5.1: Login
5.2 Registration:

34

Figure5.2:.Registration
5.3 Submitting Attendance:

Figure5.3 Submitting Attendance


5.4 Attendance Report:

35

Figure 5.4 Attendance Report

5.5 Location Monitoring:

Figure 5.5 Attendance Report


5.6 Student Record:

36

Figure 5.6 Student Record


5.7Add Course:

Figure 5.7 Add Course


5.8 Add Time Table:

37

Figure 5.8 Add Time Table

5.9 Add Class Rooms:

Figure 5.9 ADD Class Rooms

38

CHAPTER VI
APPLICATION AND FUTURE SCOPE
6.1Applications
Accountability: By using a physical characteristic rather than simply using a
swipe card or PIN, ensures that the student is actually present. This avoids
issues such as buddy punching, a term used to describe when other student
clock in and out for one another.
Efficiency: Using biometric attendance software allows for increased
efficiency in multiple areas. First, student dont have to worry about
remembering to bring in a punch card or remembering a PIN, so there is less
time spent on recovering lost passwords and manually inputting an students
clock-in time. Second, when it comes to attendance, it is much easier to track
in and out times by simply downloading the data from your biometric
scanning device, and in putting it into your attendance software.
Profit: A natural bi-product of increased accountability and efficiency is
increased profit. By making student more accountable to attendance times,
you will increase productivity. The same is true for increased efficiency.
Access control
Immigration checks
39

Customer identification, Loyalty programs


Security systems
Preventing identity theft

6.2Future Scope:
Using RFID and GPRS, we can also trace location of student.
In future we will also track the person by using mobile IP address.
In future with Biometrics, one can go to shopping without money purse or credit
card.
It just needs to place his/her finger on the reader device and can debit money from
their bank accounts.
Two computers connected via LAN and fingerprint scanner will be used initially.
One computer will serve the purpose of server for storing reports which may be MS
Access, MS Excel or SQL/Oracle database. Other one will be storing the enrolled
database, will have software for automatic attendance management and will be
connected to USB fingerprint scanner.

40

CHAPTER VII
CONCLUSION
This project mainly comprised of development of attendance management system
and fingerprint identification system. Attendance management is very helpful in
saving valuable time of students and teachers, paper and generating report at
required time. This project provides a framework using which attendance
management can be made automated.
Fingerprint Identification System used for student identification is faster in
implementation than any other fingerprint identification systems. Using Location
Monitoring , it is possible to monitor location of the student according to his time
table.

41

BIBLIOGRAPHY

[1] Raymond Thai. Fingerprint Image Enhancement and Minutiae Extraction".


Technical report, The University of Western Australia.
[2] Kenneth Nilsson and Josef Bigun.Localization of corresponding points in
fingerprintcomplexltering". Pattern Recognition Letters 24, page 2135 2144,
October 2003.
[3] Vinod C. Nayak, TanujKanchan, Stany W. Lobo, and PrateekRastogi etc. Sex
Dierencesfrom fingerprint ridge density in the Indian population". Journal of
Forensic and Legal Medicine, 17(1):84 86, September 2007.
[4] Mary Jane and AlimanManalo.Development of a Fingerprint Classication
scheme forImprovedFingerprintIdentication". Technical report, University of
the Philippines, Diliman.
[5] Roger Pressman, Software Engineering- A Practitioners Approach.

42

43

You might also like