DESIGN AND IMPLEMENTATION OF FINGERPRINT BASED ATTENDANCE MANAGEMENT SYSTEM FOR TERTIARY INSTITUTIONS

Chapter 3 & 4

Chapter 3 & 4
3.1 Brief Introduction
This work is based on the development and implementation of fingerprint-based attendance management for tertiary institutes. The system is intended to identify and monitor the check-in and check-out of both lecturers and students during class sessions. The system requires that all administrators, lecturers, and students enroll their fingerprints to allow for identification and verification of their identity. The primary idea behind developing this system was to avoid fake records of student’s attendance.
3.2 Methodology
The developer adopted a top-down approach in designing the proposed system. A top-down approach involves the developer having the bigger picture in mind, then the developer works from that point down to the smaller segments of the program CITATION Lig17 l 1033 (Liggins II et al., 2017). It narrows down to the base level elements until each element of the system is fully and properly defined as shown in figure 3.2 below.
299656525336500

2344420-38735 System
00 System

2344420164465 User Start Page
00 User Start Page

577913530543500528955305435002996565305435005289553054350029959307493000
5009515207010Student sub program
00Student sub program
-161290189865Admin Sub program
00Admin Sub program
2289175184785Lecturer Sub program
00Lecturer Sub program

57778651943100030124401568450052895514160500
5217795229870 Mark Att.
00 Mark Att.
6400165831850049790358318500500951573660005779135831850022275801397000387540524130002543810201930Activate Att.

00Activate Att.
30048202413000222821522860005289551397000-822325222885File
00File
-5302252286000-2152652286000-161290222885Settings
00Settings
18415022860001314450229870Reports
00Reports
1605915228600012388852286000589915229870Setup
00Setup
8680452286000-5302251397000
768985318135Assign Role
00Assign Role

597725593980Enroll
00Enroll
457962086995Scan fingerprint
00Scan fingerprint
17519654445Activate D.time
00Activate D.time
338836029210View marked
00View marked
-66865581280Change PW
00Change PW

-306705297180 Fingerprint Enrolment
00 Fingerprint Enrolment

3.2.1 Methods of data collection
Data collection for the system was done through collaboration with the lecturers, administrators, and students. It involved enquiring about the information they desired and thought would best serve the proposed system. Sample fingerprint biometrics were taken alongside other user data for the purposes of developing and testing of the system.
3.3 Analysis of the present system
The current system comprises of manual entry of student’s data into an attendance sheet. Here, attendance of the students is done by human effort, either by the lecturer who calls the student’s name and ticks whether the student is present or absent or by the students who have to sign against their names. The great human effort is required in this system for retrieval and maintenance of these handwritten registers.
3.3.1 Strength of the present system
The main strength of the current system is that it has managed to regulate student attendance in a great way. Students would blatantly miss classes if the current system was not put in place.
3.3.2 Weaknesses of the present system
The current system is flawed since it provides room for fake attendance. Students who fail to attend classes can tell a friend to sign their attendance. Another major drawback with the current system is the amount of time required to sign the attendance sheets by students, or the time required by the lecturer to call out their names to know whether students have attended a class or not. Further, retrieval of information from the manual system is quite challenging as it requires different registers to be compared.
3.4 Analysis of the proposed system
The proposed system introduces a new technology that integrates fingerprints for checking the attendance of both the students and the lecturers. The system is made up of two essential processes which include the enrolment and the authentication of the users. During the enrolment process, user biometrics are captured using the fingerprint scanner, and the minutiae data is stored within the database for each subject as a template alongside the user’s ID and other basic information. The prime purpose of the enrolment module is to capture the details of a user and their fingerprint to admit them into the database. The data obtained from this crucial step forms a template through which a user is identified by the system during the authentication process. The authentication process requires that the user’s biometrics are captured for comparison with the existing template in the database to determine if they match. A successful match allows the system to mark the attendance of the user against the user’s ID.
3.4.1 Justification for the proposed system
The implementation of the proposed system will be essential in accomplishing various actions. First, the system will eliminate the issue of intentional student’s failure to attend classes. Further, it will eliminate cases of cheating where other students can sign for their colleague who failed to attend a class. Additionally, it will eliminate instances where students take their exam having not attained the minimum class attendance for a semester. Importantly, it will eliminate the manual work which is often tedious for both the students and lecturers, saving a lot of time for the whole institution.
3.4.2 Use case diagram of the proposed system
The use case diagram will be as shown in the figure 3.1 below.
207010-315595060198006067425Admin
020000

Admin
-6096003181350Student
020000Student
right838200Lecturer
020000Lecturer
18383242686050001524000342900000171449922955250043910256772274004057650663892500279082557054750031908765934075003171825519112600423862546577260042862504057650005145406413385000503872519430990045053251876426004295775163829900412432535242518097501914525View personal attendance
View personal attendance
38100260984900left301942500-952521240755886450666751005657849590550005534025400050518159957981850058197755905499005600700508635026289006562725Print Report
Print Report
29908507134225Sort Report by Type
Sort Report by Type
13335005457825Edit Lecturer
Edit Lecturer
17335506019800Delete Lecturer
Delete Lecturer
37052255553075Manage Lecturer Info
Manage Lecturer Info
28479753771900Update Student
00Update Student
27813004410075Delete Student
00Delete Student
right3695700Add New Student
00Add New Student
41719504714875Manage Student info
Manage Student info
17049754895850Add New Lecturer
Add New Lecturer
34671001952625Semester report
0Semester report
45434252190750Individual report
0Individual report
32194501323975Daily report
0Daily report
43624506305550Manage Reports
Manage Reports
616267555816500

8477253629025Update Database
Update Database
4095752314575Track attendance record
00Track attendance record
2657475190500Update Database
0Update Database
44481751428750Check attendance report
Check attendance report
4114800809625Search Attendance history
00Search Attendance history
4286250123825Manually key in attendance
00Manually key in attendance
18859502809875Print Report
00Print Report
2667002962275Check-in attendance
0Check-in attendance
1905001704340Register Fingerprint
Kee
0Register Fingerprint
Kee
-3429002628900061722002571750
3.5 Description of input and output documents
The system will capture the details of the users (Administrator, Lecturer, or Student) and take them to the preferred sub-system. Each user will access the system by placing a fingerprint on the scanner which reads the fingerprint data as input, matches the data with the existing data, and provides an updated record as the output.
2038350451485 Start
00

Start
3.6 Information and Product Flow Diagram
2036445256540 Start
00 Start
1406525220980 Display
00

Display
26162002095500
473519522034500262572513779500530288510477500262572522987000262128095250001543685329565Admin login
Lecturer Activator setup
Student Att. Manager
00Admin login
Lecturer Activator setup
Student Att. Manager

26257251270001406525262255Input Select User
00Input Select User

263588515621000
15830551270Admin login
Lecturer Activator setup
Student Att. Manager
00Admin login
Lecturer Activator setup
Student Att. Manager

262318511366500
196215012065Is user selected?
00Is user selected?
473519532067500530098028702000330327032004000 No
2609850335280005301615-106045000
1406525215900Input Select User
00Input Select User
Yes
530225017145000262128011557000
200977528575Is password correct
00Is password correct
322707033528000 Yes No
262128021907500 Yes
2009775103505Is user=admin
00Is user=admin
5302885359410004656455220980004825365358775003703955220980 Admin subprogram
00 Admin subprogram
379603022098000322707040449500 Yes
261620027241500
2009775368935Is user=Lec
00Is user=Lec
530161535623500 No
5301615-1029970004825365250190004702175901700037960309017000370395590805 Lec subprogram
00 Lec subprogram
322707025082500 Yes
26060408001000
3796665310515004702810325755003703955325755 Stud subprogram
00 Stud subprogram
1997075158750Is user=Stud
00Is user=Stud
No
321183016954500482536511874500 Yes
260413573660002120900244475 Stop
00 Stop

3.7 Specifications and Design
The diagram below shows the design of the system indicating how it will be integrated into the existing system. The process involves creating datasets, capturing fingerprints, processing, and authentication. For example, the lecturer module shown below provides the lecturer with access to fingerprint attendance module, allows him/her to log in and monitor students’ attendance.
Figure 3.7

3.8 Overview Description of the New System
The proposed system introduces an automatic mode of attendance management system. The system is an integration of fingerprint authentication into the attendance management process for administrators, lecturers, and students. Mainly, it’s comprised of two processes: enrolment and authentication.
3.8.1 Architecture of the proposed system
The design of the system is comprised of the following modules:
Enrolment module
Authentication module
System database
3.9 High-Level Model of the Proposed System
The fingerprint acquisition module is comprised of a fingerprint sensor, a high level performing processor and a connection to the main database. The system allows storage a great number of fingerprint templates as the size of each is 212 kb. It allows a user to use fingerprints to log in, allows the administrator to delete fingerprints, verification of fingerprints, upload, and download of fingerprints by the administrator among other functions. The system has self-adaptive measures as it can improve the quality of the image when fingers are dry or wet.
4.1 Brief introduction
The system development adopted the biometric access control techniques which were developed by use of Microsoft Visual Basic.net 2010 and later integrated with a fingerprint scanner. User data was stored using MSSQL server 2008 R2. The access point was designed to be through a fingerprint scanner as the input device.
4.2 Objective of the New System
The new system was the main objective was to eliminate the time wastage that is involved within the manual system during filling of attendance sheets when compiling the percentage for every student to determine whether they are eligible to sit for an exam and to reduce the paperwork done as it’s quite tedious and complex.
4.3 Main Menu
The main menu provides the users (Administrators, Lecturers, and Students) with three options: the administrator login, lecturer activator setup, and student attendant manager. The first option provides the administrator with an option to log in as shown in Figure 4.3 below. Once the administrator is logged in, they are given the privilege to perform settings and update the system. The lecturer and students are also provided with options that allow them to access different data based on the privilege level.

Figure 4.3: User Start Page
4.3.2 Admin Login Page
Figure 4.3.2 shows the login page of the administrator. The administrator types in his/her username and password for them to navigate to the main page where he/she to perform enrollment, updates, and settings.

Figure 4.3.2: Admin Login Implementation
4.3.3 Lecturer Activator Setup Page
The system provides the lecturer with an option to activate an attendance for a particular class as shown in figure 4.3.3. The lecturer is supposed to log in by inputting their fingerprint for verification and then activate a certain class and the duration the class will take. By doing so, it allows students to start marking their attendance for a particular session. The system cannot allow students to sign their attendance if the lecturer has not activated the attendance setup.

Figure 4.3.3: Lecturer Attendance Setup
4.4 Database Specifications
The attendance management system database is comprised of data stored in tables. Each of the records in the database corresponds to a registered user. The records comprise of minutiae templates of the user’s biometrics (fingerprints), ID number and other pertinent information. The database design implementation for this system takes the relational data model which comprises different tables where data is stored. The developer utilized Microsoft SQL server 2008 R2 database. The rationale for using the SQL server is that it’s fast and easy to use. Further, it’s important especially when the system is intended to store large records of data. An ultimate advantage for both the developer is that it requires minimal configuration. The tables 4.1, 4.2, 4.3, and 4.4 shows the different data captured in the administrator database, course database, student database, and lecturer database.
Table 3.1 Administrator database

Table4.1 shows how the administrator database looks like. All the data for the administrator is stored here, and retrieval is done from the same table.
Table 4.2 Course database

Table 4.2 shows the table structure for the course database. Here, all the courses that a student is taking and those that a lecturer is teaching are stored and accessed here. The table provides the data required for the course sub-system and other subsystems that might require such data.
Table 4.3: Lecturer database

Table 4.3 is comprised of the lecturers’ data. All information pertaining to a certain lecturer is placed here. The information in this database is only accessed by the lecturer and the system administrator.
Table 4.4 Student database

Table 4.4 represents the table structure of the student database. The student database is where the information needed from all students are stored and accessed by the administrator for updates.
4.5 Program Module Specification
Each module above performs a specific function that is directly connected to the main system.
4.6 Input/output Screen Format
The input screen for each user will be as shown in figure 4.6 below. Figure 4.6 indicates the administrator’s screen for enrolling a student. Similarly, figure 4.6.1 indicates the output for a student who has been registered and has scanned the finger. The output indicates that the student is verified.
Figure 4.6 Student enrolment submenu

Figure 4.6.1 Student fingerprint verified

4.7 Overall Data Flow Algorithm for Programs Module
4.7.1 Data Flow Algorithm
(Algorithm)
4.7.2 Flow Chart for Admin Sub Program2028190150495 Start
00 Start

1037590272415 Admin subprogram
00 Admin subprogram

24879308699500389572530289500115316030289500
248920011557000944880256540 Print main menu
00 Print main menu

5586730224790002489835224790003826510224790001813560287020Settings
Setup
Reports
File
00Settings
Setup
Reports
File
248920017145000
1885950273050Is option=1?
00Is option=1?
249555025717500
4963795162560003742055162560003665220162560Settings.Admin subprogram
00Settings.Admin subprogram
309753029400500 Yes
5017770-6985005584190-155892500249237573025001882775254000Is option=2?
00Is option=2?
No
3742055121920004963160129540003665220129540Setup.Admin sub program
00Setup.Admin sub program
501777026035000309753026860500558609515303500 Yes
248666048895001882775229870Is option=3?
00Is option=3?
No
370522513462000501777013462000366522083185Report.Admin subprogram
00Report.Admin subprogram
309753025273000501777025971500 Yes
1885950202565Is option=4?
00Is option=4?
55848252673350024809452476500 No
4916805145415003742055145415003665220160655File. Admin sub program
00File. Admin sub program
Yes
501777038100030975304445002484120179070002320290360045A
00

A
No1745615382905Enroll lecturer
Enroll student
Assign courses

Add student
00Enroll lecturer
Enroll student
Assign courses

Add student
411035530035500547179530035500249555029972000248983525273000
5479415-70675500238760021590000

4772025635000036798257112000355854078740 Enroll lecturer sub
Admin sub program

00 Enroll lecturer sub
Admin sub program

1774190-318770Is option=1?
00Is option=1?
299148530099000491172533083500363474033147000 Yes
237617014605001776730255270Is option=2?
00Is option=2?
No
4773930290830003681095265430003556635265430 Enroll student sub
Admin sub program

00 Enroll student sub
Admin sub program

54819558572500 Yes
491172518224500299593018288000
238188516510001774190227330Is option=3?
00Is option=3?
No
4772660257175003682365257175003559175257175 Assign course sub
Admin sub program

00 Assign course sub
Admin sub program

Yes
1934845838835 Stop
00 Stop
238760058420000491680518605500298894518542000
4.7.3 Flow Chart for Student Sub Program
2044065-99695 Start
00 Start
248920020510500
50558703479800036036253479800010445751905Capture Fingerprint
00Capture Fingerprint

244284525527000
153670026670 Verification module
00 Verification module

1644650375920Is Fingerprint valid?
00Is Fingerprint valid?
244348010858500
505587017018000401066015494000326580515430500 No
244157536893500
1676400222250 Mark as Present
00 Mark as Present

244157541973500
5055235-1592580001644650297180 Display Notification
00 Display Notification

318897019113500418020519050000
244157555880001966595373380 Stop
00 Stop

4.8 Program flowchart
1006475461645Capture Fingerprint
00Capture Fingerprint
2044065-99695 Start
00 Start
248920020510500
505587024320500360362526225500
1660525372110 Verification module
00 Verification module
249047017907000
246253042545000
1654175261620Is Fingerprint valid?
00Is Fingerprint valid?

4020185406400032943804000500 No
247967525463500
-666750518795Access Lecturer Sub-Program
Access Lecturer Sub-Program
1657350103505User Status?
00User Status?

425831077470Access Admin Sub-Program
Access Admin Sub-Program
885825111760Lecturer
00Lecturer
6477003251203278505328930003185795134620Administrator
00Administrator
244157541973500
4972050132080-19050132080
-647700329565Access Lecturer and student data
Access Lecturer and student data
4121785310515Access privileged content such as Settings
00Access privileged content such as Settings
2486025205740Student
00Student
247650092710
3253105374650

left393700001714500269875 Mark as Present
00 Mark as Present

2486025153670
24898353086100017240258255 Display Notification
00 Display Notification

2028825175260 Stop
00 Stop

4.9 Program Documentation and Implementation
The program documentation was continuous progress that included every stage being documented from the conception of the idea to the final phase of where the project was implemented. The process is fundamental as it accounts for the whole development process and helps in case the system requires an upgrade or in case of maintenance of the system.
4.10 Language Justification
The rationale behind choosing Visual Basic for this program is that Visual Basics acts the transition between Python and languages such as C and C#. As such, the language has introduced different concepts without complex conventions being required.
4.11 Hardware and Operating System Requirement
4.11.1 Hardware Requirements
The minimum requirements needed to successfully implement this system include a minimum of AMD Athlon II x2 250 u/Intel Pentium D 3.4 GHz as the minimum processors, 1 GB ROM memory, 3 GB hard disk space, LAN connection, and a fingerprint scanner.
4.11.2 Software Requirements
The minimum requirements for the software to run include all 32-bits Microsoft Windows Operating System, Microsoft Visual Studio 2008 R2, Browser Google Chrome (20.0 and above) or Mozilla Firefox (30.0 and above).
4.12 Software Testing
After system development, the system required to be tested to confirm whether the system was free of bugs and to ensure that the system would provide a seamless user experience. The developer ensured that the following testing was done: unit testing which requires the developer to test every single module or component of the system to know whether they are working; Integration testing was done to ensure that the different modules or components of the system were without any problems. The integration process was done after unit testing; System testing was done to ensure that the complete system was functioning well as a whole. System testing is fundamental since it requires the system to meet the threshold quality and requirements as set by the users. Finally, the acceptance testing was done to ensure that the system meets all the requirements from all dimensions. The acceptance testing required the input of a beta-tester to ensure that the system development is perfectly done before deployment.
4.13 User Manual
All users will be provided with a user manual includes the direction for use. The administrators will have a manual that guides them through the basic installation process and operations. The user manual will also have the advanced use directions for the administrators. Lecturers and students will receive a user manual that describes all the functionalities for their various use.

References
BIBLIOGRAPHY Liggins II, M., Hall, D. & Llinas, J., 2017. Handbook of multisensor data fusion: theory and practice. s.l.: CRC press.