Table of Contents

helmetpastoralΛογισμικό & κατασκευή λογ/κού

13 Δεκ 2013 (πριν από 3 χρόνια και 7 μήνες)

105 εμφανίσεις

Table of Contents

1 Frontal Materials…………………………………………………………………………i


1.1 List of Figures………………………………………………………………………..i


1.2 List of Tables………………………………………………………………………..ii


1.3 List of Symbols…………...………………………………………………………..iii


1.4 List of Definitions
…………………………………………………………………..iv
2 Introductory Materials…….…………………………………………………………….1


2.1 Executive Summary…………………………………………………………………1


2.2 Acknowledgment……………………………………………………………………2


2.3 Problem Statement…………………………………………………………
………..2


2.4 Operating Environment……………………………………………………………...2


2.5 Intended Users and Uses…………………………………………………………….2


2.6 Assumptions and Limitations……………………………………………………….3


2.7 Expected End Product and Other Deliverables………………………………….…..3

3 Approach

& Results……………………………………………………………………..4


3.1 Functional Requirements……………………………………………………………4


3.2 Design Constraints…………………………………………………………………..4


3.3 Approaches………………………………………………………………………….5


3.4 Detailed Design……………………………………………………………………...7


3.4.1 Overall Design Architecture………………………………………………….…7


3.4.2 Registration Sub
-
System…………………………………………………….…..8


3.4.3 Identification Sub
-
System…………………………………………………….…8


3.4.4 Data Storage and Display Subsystem…………………………………………...9


3.4.5

Parts List……………………………………………………………………….10


3.5 Implementation Process……………………………………………………………11


3.6 End Product Testing………………………………………………………………..11


3.7 Project End Results………………………………………………………………...12

4 Resources and Schedules……………………………………………………………
…13


4.1 Estimated Resources……………………………………………………………….13


4.1.1 Personal Effort Requirement…………………………………………………..13


4.1.2 Other Resource Requirement………………………………………………….14


4.1.3 Financial Resource Requirement………………………………………………15


4.2 Sche
dules…………………………………………………………………………..17

5 Closure Materials………………………………………………………………………19


5.1 Project Evaluation………………………………………………………………….19


5.2 Commercialization…………………………………………………………………19


5.3 Recommendations For Future Work……………………………………………….20


5.4 Lessons Learned……………………………………………………………………21


5.5 Risk and Risk Management………………………………………………………..22


5.6 Project Team Information………………………………………………………….22


5.6.1 Client Information………………………………………………………….…..22


5.6.2 Faculty Advisor Informa
tion……………………………………………….…..23


5.6.3 Project Team Information………………………………………………….…..23


5.7 Closing Summary…………………………….…………………………………….24


5.8 References………………………………………………………………………….24


5.9 Appendices…………………………………………………………………………25


i

1 Frontal Mater
ials

This section consists of the list of figures, list of tables, list of symbols, and list of
definitions. These, as would be expected, appear at the beginning of the document.


1.1 List of Figures


Figure 3
-
1…………………………………………………………………………..…..6

Figure 3
-
2…………………………………………………………………………..…..8

Figure 3
-
3….……………………………………………………………………..…….9

Figure 3
-
4….……………………………………………………………………..…...10

Figure 4
-
1 …………………………………………………………………………….18

Figure 4
-
2……………………………………………………………………………..18

ii

1.2 List of Tables


Table 3
-
1……………………………
…………………………………………..……..5

Table 3
-
2………………………………………………………………………..……10

Table 4
-
1……………………………………………………………………………..14

Table 4
-
2……………………………………………………………………………..14

Table 4
-
3……………………………………………………………………………..14

Table 4
-
4……………………………………………………………………………..15

Table 4
-
5……………………
………………………………………………………..15

Table 4
-
6……………………………………………………………………………..15

Table 4
-
7……………………………………………………………………………..16

Table 4
-
8……………………………………………………………………………..16

Table 4
-
9……………………………………………………………………………..17

Table 5
-
1……………………………………………………………………………..21

Table 5
-
2………………
……………………………………………………………..22




iii

1.3 List of Symbols


None.



iv

1.4 List of Definitions


The following is a list of terms used in this plan.


Class file



A file common to a professor for a given class. For example, a professor
teaching computer engineerin
g 308 would have a file labeled CprE308.xls that would
contain information particular to each student in his or her class.


GUI



Acronym for graphical user interface. This will be the front
-
end of the running
program that allows the user to easily interf
ace with the system.


Microsoft Excel



Spreadsheet program that will be used to display the final data in
columns and cells.


PC



Acronym for personal computer.


Perl

-

Acronym for
p
ractical
e
xtraction and
r
eport
l
anguage
,

Perl is a programming
especiall
y designed for processing text.


SDK



Acronym for software development kit.


Transaction time



Time it will take for each student to move through the line and press
his or her finger upon the scanning device and be recognized.


Visual Basic



Commonly re
ferred to as VB.

A programming environment from
Microsoft in which a programmer uses a graphical user interface to choose and modify
pre
-
selected sections of code written in the BASIC programming language.





















1

2 Introductory Materials

This

section includes seven subsections, which give a general overview of what the
project is about; who it is intended for and how it will operate.


2.1 Executive Summary

Throughout this report information is given about the need for the project, the actual
p
roject activities, the final results, and recommendations for follow
-
on work. This section
will summarize this information.


Project Need

A growing problem with university classrooms is the inability to effectively and
efficiently record classroom attend
ance. In many classes the student’s grades are
dependent on their attendance to class. Many professors use sign
-
in sheets or attendance
codes, but it is easy to have one student sign somebody else in. So, this project was
started to find a way that atte
ndance could be securely collected.


Project Activities


This project consisted of two major activities: technology selection and design and
implementation. Choosing the right technology for the project was essential for a
successful end product. Befor
e, selecting the technology to use the group researched
several different options for recording attendance, including: magnetic swipe cards, voice
recognition, facial recognition, signature recognition, fingerprint recognition, and more.
The most importan
t features of the technologies were speed, reliability, security,
durability, and cost. It was concluded that fingerprint recognition was the technology
that best suited all of the requirements.


After selecting fingerprint technology
on which
to base th
e attendance system, the design
and implementation phase was ready to begin. During this phase, the group made a
detailed design, and documented the design in the design report. After purchasing the
equipment needed, the implementation of the design with

the fingerprint scanner was
started.


Final Results

The project will end with a prototype of a fingerprint based attendance system. The
prototype will consist of the software needed to run the scanner, one fingerprint scanner,
and an instruction manual.

This system will be able to register students under a specific
class. Also students will be able to record their attendance by giving a fingerprint at the
beginning and end of the class period. A teacher will be able to port all of their
attendance data

into an Excel spreadsheet. The teacher will also be able to add or delete
students from a class list.



Recommendations for Follow
-
up Work

Our main idea in continuing work is making the fingerprint scanner an embedded system.
Having an embedded system

allows easier because laptops are not needed but it adds cost
and difficulty to the system. Either making an embedded system or purchasing an
embedded system and reusing the software is at the top of the list for follow
-
up work.


2.2 Acknowledgment

No
ne.


2


2.3 Problem Statement

This subsection states the problem in which the attendance system is to solve. It also
contains a general description of how the problem will be solved.


Problem

It is difficult to accurately and efficiently record attendance in
a large classroom. A
device is needed to accomplish this task more efficiently. With the current means of
attendance collection, it is easy for students to cheat the system. The speed of this new
procedure is another concern. The process should not cut int
o valuable class learning
time. A way of taking attendance is needed that can uniquely identify an individual
without error, and also quickly log the individual’s attendance information. In the end,
the attendance data needs to be easily accessed by the p
rofessor.


Approach

The approach was initially to use fingerprint scanner with a

micro controller that would
drive the device and keep track of various dates and times when students log in and out of
the device. However, to fit in the budget a pc
-
based fin
gerprint scanner was used. In this
case, the pc will have software to identify the student and store the attendance data.
Finally, a way of getting the information from the device to a Microsoft Excel
spreadsheet is needed. This will be done by formatti
ng the attendance data form the
fingerprint scanner into a text document that can be opened by Microsoft Excel.


2.4 Operating Environment

This device shall be portable so it could operate indoors, or outdoors. Dust exposure is a
possible problem. The dev
ice could be dropped or knocked around by the many hands
that will use it
. The device could become dirty by many people handling it everyday.
Food or beverages could be spilled on it. If used outdoors, it could be rained on, or
affected by excessive tem
perature changes. Transporting the device from freezing
temperatures outside into heated rooms or from high temperatures outside into air
conditioned rooms could hinder its immediate functionality. Condensation occurring or
liquid crystal displays failing
to function are some examples of temperature problems.


2.5 Intended User(s) and Use(s)


Users

The intended users are college professors who need to accurately and efficiently collect
attendance in large classrooms. They need to have experience using a lap
top PC and the
Microsoft Excel

spreadsheet program. College students will also use this system to record
their presence in the class by placing their finger on the device.


Uses

The student users of this system must identify themselves by logging into and
out of the
device. The collected attendance data will be saved to a laptop PC and easily transferred
it into a
Microsoft Excel

spreadsheet using the software that accompanies the device.
With this system, professors will be able to record the times and dat
es students arrive and
depart from class. This system could be used as a substitute for in class quizzes, sign in
sheets and other distracting methods of collecting attendance, thus saving valuable class
time.


3


2.6 Assumptions and Limitations


Assumption
s

IBM compatible laptop PCs are to be used to collect and save data from the device.

The laptop PC will have Microsoft Excel loaded in order for the software to work with
the laptop PC.

There will be two devices for large classes in order to collect data i
n a short period of
time.

The laptop will have
a
required number of open USB slots.

The students won’t object to
the
use of
their
fingerprints.

Attendance data will be collected on both entering and leaving classroom.

There will only be two attendance entr
ies per student, per class.


Limitations

The l
aptop being used will have at least a Pentium 2 CPU, 50 MB hard drive space, and
32 MB RAM.

The o
perating system on
the
laptop must have either Microsoft Windows 98SE, ME,
2000, or XP.

The device will take less

than 5 seconds per student to determine students’ identification.

The system will take up no more than one square foot in area.

The system will not weigh more than 5 pounds.


2.7 Expected End Product and Other Deliverables


1. The attendance
-
taking devic
e.

This is a small finger print scanning hardware connected to a laptop containing
functionality for electronically collecting and storing students’
ID
s and the times and
dates that they were collected.

2. Users manual.

The user manual describes the devic
e and software functionality in depth as well as the
operating instructions of the device and software.

3. Software.

Software is included which allows a professor to access the collected attendance data
from the attendance taking device and their laptop a
nd formatting this information into an
Excel document.

4. USB cable.

A

cable is

included to connect the device to the laptop.

5. Project Poster.

The project poster is a means to communicate the purpose and description of the project
in a constrained time

and space.

6. Project Plan.

A document of how the project will be conducted.

7
. Project Design Report.

A documentation of how the end product is designed.

8
. Final Report.

A document that provides a complete record of the project, its activities, and
i
ts results.


3 Approach & Results


4

This section is divided into seven subsections which describe the functional requirements,
design requirements and the various approaches considered for the automated attendance
system. The detailed design, implementation
process, testing process, and the project’s
end results are also described in this section.


3.1 Functional Requirements

This subsection contains the final set of functional requirements
.
Each functional
requirement is accompanied by a brief description.


a.

Student registration.

The instructor will need to be able to register each of the students’ names and their
unique fingerprint into a database for proper identification later on.

b.

Identification of a student.

The system shall be able to uniquely identify ea
ch student in the class. The identification
is to be done when the student enters and exits the classroom. The identification will be
done in real time.

c.

Storage of students identified.

The system’s database shall be able to store all students’ information
. After the
identification period a text file is created with a record of the students’ names, date, and
timestamps for the class.

d.

Display student’s name after identification and sounds.

The system shall have the ability to display a message with the stude
nts name and an
access granted or denied message to tell the student if their logon was successful. Audible
sounds may be also played for successes and failures.

e.

Time stamping of identification.

An arrival time, exit time and date shall be associated with
each attendance check in
order to assure the student has been in attendance for the entire class period.

f.

Downloading data to Microsoft Excel.

The system shall be able to download the identification data to a Microsoft Excel
readable text file. The data mu
st be formatted and opened in an Excel spreadsheet.


3.2 Design Constraints

This is a list of design constraints for the project. It is derived from
the
assumption and
limitation lists, various project requirements and other decisions made by the team
memb
ers.


a. Unit must be portable.

The system must be
less than a few pounds and fit in an area of about a square foot so

it
is easily transportable to and from the class. A laptop PC is used for processing to ensure
the portability.

b. Internally powered.

T
he system shall operate on internal power and will be used in different classroom
configurations. The laptop PC provides power through its battery.

The scanner is
powered through the USB connection to the laptop.


c. Memory and disk drive space

The system
’s memory and disk drive requirements are limited by the drive space and
memory on the PC it is using.



5

3.3 Approaches

The main parts of the project included the technology used to identify the students and
how the information taken from the class was be s
tored and made available to the
professor. The first task was to choose a technology to use. Our chosen approach greatly
depended on the reliability and cost of the considered technologies. Reliability was a
factor, because the technology had to be accurat
e enough to identify each student in a
large classroom with very little or no error. Also, the technology had to be within a
maximum price range of a few hundred dollars. Once the technology was selected, the
remaining system design was divided among the f
our team members as modules.
Diagrams were then drawn for each module, and implementation began. Upon the
completion of implementation, the modules were integrated and then tested to ensure a
working system.


The technological approaches researched and con
sidered, consisted of fingerprint
recognition, facial recognition, barcode scan, magnetic strip on an
ID

card, proximity
card, voice recognition, signature recognition, and a simple keypad. Each of these
technologies has advantages and disadvantages as sh
own in Table 3
-
1 below

with 5 being
the best and 1 being the worst
.


Table 3
-
1 Advantages and Disadvantages of Technologies

Technology

Cost

ID time

Process
Time

Reliability

Security

Fingerprint

3

2

4

5

5

Facial Recognition

2

5

1

4

5

Voice Recognition

3

2

4

3

4

Signature Recognition

4

1

4

4

4

Magnetic Strip

4

3

5

5

2

Proximity Card

3

4

5

5

2

Barcode

4

3

5

5

2

Keypad

5

1

5

4

1


The barcode scan, magnetic strip and proximity cards have similar advantages and
disadvantages. The advantages include the s
peed of identification and processing, storage
capabilities, and ease of use. The main disadvantage of these technologies was the ease
of fraudulent identification. One student could easily give his identification card to
another student. The keypad could

be easily implemented but is not very secure and has a
slow transaction time.


The signature recognition technology is fairly inexpensive and portable. However, it is
difficult to process and has a relatively high failure rate as well as a slow transactio
n
time. Voice recognition has the capability of being secure but a student may record his
voice and give the recording to another student enrolled in the class. Furthermore, it has
a slow transaction time and a problem with background noise. Two approach
es for facial
recognition were considered: taking a picture of each student as they enter and exit the
room and taking a group picture and picking each face out and identifying it. The single
picture has the advantage of having easier processing. The dis
advantages of this
approach include the device taking a picture at the right time and also being flexible
enough to work in classrooms with wide doorways and multiple entrances. The group

6

picture approach has the main advantage of a quick transaction time
; one picture can be
taken for the whole class. One disadvantage of this approach is the difficulty in
processing the photo to recognize all of the students. Also, some classroom
configurations would make it tough to get the each individual in the pictur
e, i.e. a room
with a balcony or a room that has no slope to it. The last technology considered is a
fingerprint reader. Advantages of this technology include the security it provides, and the
speed of processing. Another advantage is the ease of making

this a portable technology
since most of the readers researched meet the size constraints of the project. The
disadvantage of this approach is that before the system is used, each student needs to
enroll their fingerprints into the system for matching at
a later time. However, the
enrollment is only a one
-
time occurrence.


Ultimately, the fingerprint reader was chosen to be the best option for this project. This
decision was made because the benefit of security, quick processing time, and portability.
Al
so, the time spent enrolling each student is well worth the benefits of the heightened
security the fingerprint scanner provides. Lastly, most of the fingerprint readers come
with a SDK that will help customize the reader to suit the projects requirements.


To begin with, the group wanted to use an embedded, stand
-
alone fingerprint reader.
However, the embedded kits prices were between $1000 and $10,000. This was way too
expensive. So, in order to keep the attendance system portable the group decided to use

a
USB fingerprint reader attached to a laptop PC. The USB reader’s price was only $300,
which included an SDK. This approach seemed to work out better anyway, since memory
and data storage constraints were not as tight because the scanner was using the PC
’s
resources rather than a microcontroller’s.

Figure 3.1 below shows the scanning device
that was chosen.


Figure 3.1 Fingerprint scanner.


The software considered for the project included Perl, Visual Basic and Visual C++. An
advantage of Visual Basic is

that all members in the group are familiar with it. Visual
Basic also works well with file parsing, especially in Microsoft Excel. Perl is a language

7

that works well with file manipulation. It can easily parse through a file to find and
format the data

in a specific way. Although Perl would have worked well with this
project, not all of the group members are familiar with it and the SDK does not support it.
Visual C++ is GUI capable and all the team members are familiar with it. Also, it is the
code o
ur fingerprint reader SDK is coded in. It also interfaces well with Excel through
simple text files formatted for Excel to use. The group decided to use Visual C++ since
the SDK was written in it, everyone is familiar with it and it has the capability to
i
nterface well with Excel through a simple text file.


3.4 Detailed Design

This section will thoroughly describe the details of the system design that will meet the
functional requirements mentioned in section 3.1. It includes a parts list, design diagrams,

descriptions and costs.


3.4.1 Overall Design Architecture

The overall design of this system will be broken into four different subsystems: student
registration, identification, data storage and display, and user interface. These
subsystems will work tog
ether to form the automated attendance taking system. To
begin, the students will register with the fingerprint
-
scanning device prior to the
beginning of the attendance
-
taking period. Following registration, the students’
fingerprint signatures are store
d within the PC as an encrypted text file. After the
professor has collected the attendance records for the session desired, he/she will press
the download to text file button and views the textual attendance records in Microsoft
Excel. This process is d
isplayed in figure 3.
2

below.


8


Figure 3.
2

Overall Attendance System Design


3.4.2 Registration sub
-
system

There are two major parts to the registration process, student registration and class
registration. The professor must do class registration so the
database is created for each
class. Class registration involves entering class name and class section. When the class
database is built, it also adds each class to a text file to keep track of all class databases.
Both the student and the professor must

complete student registration at the same time.
The professor has the only administrative rights to add a new student; therefore he must
access the registration for the student.
Student registration involves the professor
registering

students’
name
s,
id
entification number
s
, and
the
class database the student
will be added to.
The identification number might be a class code a professor gives a
student for grading.
After the professor has registered the students’ information, the
student must then place t
heir fingerprint three times to complete registration.



3.4.3 Identification sub
-
system

After the student has completed the registration process, he/she will be able to be
uniquely identified for classroom attendance. Before class, the professor must lo
ad the
correct class database file into the system. The identification button is then pressed

9

which begins the identification functionality. From now on students are able to log their
attendance by pressing their finger on the device. Different tones wil
l sound, and
different messages will be displayed on the laptop PC screen for successes and for
failures. Students are to log in once when they enter class, and once when they exit class
to ensure they were there the whole time. The database only stores tw
o logons per student
per class period. The information is stored in a database structure residing in memory.
For each student, the structure includes their name and fields for date, arrival time, exit
time and their fingerprint template. When the class ses
sion is finished, a button is pressed
by the professor to output the database in memory to a readable text file ready for
Microsoft Excel. At that point, the database in memory resets all the dates and times for
each student to be ready for the next class
period. This process is displayed in figure 3.
3

below.


Figure 3.
3

Identification Sub
-
System Design


3.4.4 Data Storage and Display Subsystem

After the class has
been
dismissed
,

the professor will press the “DB to TextFile” button in
the “file” menu of

the main GUI window. This will output the contents of the database in

10

memory to a text file in the format of “name, date, arrival time, departure time” for each
student. Each student’s entry will occupy one line of the output file. Once this operation
is complete, the date and time entries currently in memory will be reset to null to prepare
for the next class session. Once the database is in readable text format, it can be imported
to Microsoft Excel where it is formatted into a workable spreadsheet. T
his process is
displayed in figure 3.
4

below.


Figure 3.
4

Storage and Display Sub
-
System Design


3.4.5 Parts List

In order to make the system design work, the following parts are required.

Table 3
-
2. Parts required and their respective costs.

PART

COST

Fingerprint Scanning Device

$300

Microsoft Excel

$300

The System Software(created by team)

$150

PC laptop

$2000



11

3.5 Implementation Process

The implementation process consisted of each team member coding their assigned
modules of the system. The modul
es created were the registration, identification, data
storage and display, and user interfaces. Once each module was complete, they were
individually tested by their corresponding team member to ensure each part fu
nctioned
correctly
. Next the modules were

integrated to form a complete system.


The registration module, identification module, user interface module, and the database
output to text file functionality of the data storage and display module were all coded in
Visual C++ using Microsoft Visual St
udio 6.0. The Microsoft Excel display of the class
database contents was setup in Excel itself by the use of macros to simplify the command
sequence of formatting the textual class data retrieved from the readable database text
file. Most of the base code

was already given in the fingerprint scanners SDK. It was
written using Microsoft Visual Studio 6.0. The code would only compile with this
development environment so the team had no choice but to use it as well for
modifications. Modifications were made t
o the identification, and registration parts of the
code to use multiple database files, incorporate time stamps for arrival and exit times, and
to output the previously encrypted database file to a readable text file.


The greatest problem in implementati
on was familiarizing the team with the SDK’s given
code. It was not commented very well, and
was
very intricate. Luckily a programmer’s
manual was included with the SDK, which listed each function used in the scanner’s
given implementation. After some time
,

the team was comfortable with the code and
implementation went smoothly. Integration of the time stamps went smoothly since there
was already a field in the given program’s database structure for extra binary data. The
extra space was utilized by taking
the system clock’s time, converting it to a readable
string, parsing out the date and time, and finally inserting the date and time string into the
binary field. This was done for each student, each time they logged in and out of the
system. Outputting the

database information to a text file was trivial. It consisted of
opening a new file and looping through each student in the database, to copy their name
and attendance data as a string to the new text file. Once the loop was exhausted the file
was closed.

This function is begun by selecting the “DB to TextFile” menu item in the
“file” menu bar. It should work in each of the GUI windows. However it only operates
correctly in the main GUI window.
This happens because c
ode needs to be added to add
functionali
ty to each of the GUI windows for the “DB to TextFile” command
.

Currently,
code only exists for this function to work in the main window.


There were no serious problems with implementing the system code. However in the
future, the implementation process c
ould be made more efficient by modeling each
module in greater detail to lessen the unknowns and to make module integration easier.


3.6 End
-
Product Testing

System testing includes testing each of the four modules
, registration, identification, data
storag
e and display, and user interface, independently. Once each module has passed
testing, they are integrated and tested as a system. After the integr
ation test passes, the
system will be

brought into a senior design class and tested in a real class atmospher
e.



12

Modular testing is used to ensure each module does what it is supposed to before
integration. Most of the tests include running some code to output specific values to a file
or to the screen. For the registration module, the database content was checke
d after a
new user was enrolled into the system. Outputting the database in memory to a text file
did this. Also database names were checked to ensure there files were created with the
correct unique name. In the identification module, the database content

was checked after
a student was identified by the system. The content was again output to a text file. This
displayed whether or not the identified person was identified correctly. This method also
identified whether or not the timestamps were applied cor
rectly after the identification.
The data storage and display module was tested by comparing the data in its output text
file to the actual data in the database. The actual data was displayed again by outputting it
to another test text file. These two file
s were then compared for the same content. Each
of the modular tests produced little failures. Most failures were in the parsing of the
displayed text. Some of the displayed attendance info was cut off, or the wrong data was
displayed. After a few adjustm
ents in pointers and memory allocation, the problems were
fixed.


Once the modular testing passed, the modules were combined to test as a unit. This is
currently in progress, and no results have been obtained yet. However the testing will
involve positive

enrollment of each group member into the system, positive identification
of each group member using the system, and receiving the proper output file from the
“DB to TextFile” button. Output files of the database will be checked after each test
phase for p
roper functionality of the system.


When the proper output is received from the integration tests, the system will be brought
to a senior design classroom and tested in its working environment with larger number of
students. The time it takes for a large n
umber of students to use the system will be
observed, as well as the accuracy of the fingerprint scanner itself. The times will be
recorded in the output database text file to give the team a good idea of how long a large
class will need to use the system.

Also any false positive or false negative logons can be
observed and recorded. The number of false readings, if any, as well as the time required
to identify the class will tell the team how accurate to set the identification and
enrollment functionalitie
s of the system. As accuracy increases, the time required for a
positive fingerprint match also increases. The students will be asked to enroll and log in
at the beginning of class, and log out at the end. This is done to simulate how the system
will be us
ed in a real situation.


3.7 Project End Results

Currently the system is not in its finished state. Integration testi
ng and class testing still
need

to be performed. Each module is
,

however
,

in a working state and functions
independently of one another. S
ome adjustments are needed in the way the “DB to text
file” function outputs its data to a text file. It is just a matter of parsing the time data,
which is entered into the database memory structure in a different way. All other
components work fine up th
rough modular testing.


As far as functionality is concerned, this project has been a success. Each module has
worked the way expected except for a few minor glitches that can easily be remedied.
The team is slightly behind schedule in integration testing
and class testing. Some coding

13

set backs, and getting each module to function properly consumed more time than was
planned.


The team functioned well together. Everyone respected one another, and each member
did their fair share of work. Improvements could

be made in the process by planning for
more mistakes in implementation than what was previously planned for. This error set
back the testing schedule and the course of implementation.


Currently the attendance system requires a PC with USB capability. In
the future it might
be possible to make an embedded implementation of the system. A microcontroller with
USB capability and extra memory could be used in place of the PC. This would make the
system less cumbersome and less expensive, since a PC is not requ
ired.

4

Resources and Schedules

Here is a detailed account of the resources and schedule that were followed during
implementation of this project from beginning to end. The resources used in this project
were accurately predicted at the beginning. The s
chedules, as time went on, continued to
change and were modified to reflect the correct working schedule. The schedules
contained within the report are accurate as of project completion.


4.1 Estimated Resources

Three separate components make up the estim
ated resource requirements; these include:
(1) personnel effort requirements, (2) other resource requirements, and (3) financial
requirements. There are three parts to each of these components: the original estimate,
the revised estimate, and the final re
sults.

4.1.1 Personnel Effort Requirement

The personnel effort requirement was one of the most difficult to predict. Before
beginning a project, an individual does not know what problems or circumstances may
arise that cut back on or add to the amount of
time necessary to complete the work.
The
estimate was done on a task
-
by
-
task basis and includes the appropriate totals. The
meetings listed include both group meetings and advisor meetings. The group estimates
an average of two hours per group meeting a
nd one hour with their advisor over a 15
-
week semester. The project reports column shall include each project report that the
group has to collaborate and write. Also included in this estimate are the weekly e
-
mails
and other project documentation that m
ay be involved. The estimate is also based on the
projected effort required to perform the task correctly.
Table 4
-
1 gives the original
estimate of the number of man
-
hours required to complete the project.












14

Table 4
-
1. Original Personnel Effort
Requirements.

Personnel Name


Meetings


Project Reports


Project Construction


Totals

Broulette, Kevin


30


30


30


90

Feickert, Wade

30

50

30

110

Hobart, Joshua

30

30

35

95

Seeman, John

30

40

30

100

Totals

120

150

125

395


During the first semester
the schedule was slightly revised to reflect the correct amount of
hours each individual contributed to the project. Table 4
-
2 below shows the revised
personnel effort requirements.


Table 4
-
2. Revised Personnel Effort Requirements.

Personnel Name


Meeti
ngs


Project Reports


Project Construction


Totals

Broulette, Kevin


30


30


35


95

Feickert, Wade

30

50

40

120

Hobart, Joshua

30

30

35

95

Seeman, John

30

40

35

105

Totals

120

150

145

415


Even after revising the personnel effort, there were still mi
stakes and situations that
insisted a more refined schedule to be created. After completion of the project, the group
sat down and reorganized the personnel effort to reflect the amount of work each
teammate contributed to the project. Surprisingly, the
estimated effort was not far off.
Table 4
-
3 shows the final personnel effort requirements.


Table 4
-
3. Final Personnel Effort Requirements.

Personnel Name


Meetings


Project Reports


Project Construction


Totals

Broulette, Kevin


30


30


55


115

Feicke
rt, Wade

30

30

60

120

Hobart, Joshua

30

30

50

110

Seeman, John

30

30

60

120

Totals

120

150

145

465


4.1.2 Other Resource Requirement

In any project, there are always other factors that may be seen, unseen, or may abruptly
arise somewhere in the middle
of the project. At the beginning of the project, the group
attempted to foresee any other resources that would be required to complete the
attendance taker. Table 4
-
4 is the original estimate of the other resources required for the
project.



15

Table 4
-
4.
Original Other Resource Requirements.

Item

Team Hours

Other Hours

Cost

Project Poster

12

0

$45.00

Identification
Equipment

0

0

$150.00

Identification
Software

60

40

$60.00

Totals

72

40

$255.00


After a few weeks of working on the project, the group re
turned to the drawing board to
come up with a revised other resource estimate. This estimate took into account anything
that had taken place during the semester with respect to the other resources. Table 4
-
5
gives a revised look at the other resources.


Table 4
-
5. Revised Other Resource Requirements.

Item

Team Hours

Other Hours

Cost

Project Poster

12

0

$45.00

Identification
Equipment

0

0

$400.00

Identification
Software

60

40

$150.00

Totals

72

40

$595.00


Now that the project is complete, the group w
as able to create a final other effort
requirement table which gave a completely accurate depiction of what the other resources
cost and how much effort was assigned to each. Fortunately, the group’s original
estimate on the resources needed was correct.

Table 4
-
6 gives the final other resource
requirement.


Table 4
-
6. Revised Other Resource Requirements.

Item

Team Hours

Other Hours

Cost

Project Poster

12

0

$45.00

Identification
Equipment

20

0

$300.00

Identification
Software

80

25

Included

Totals

112

25

$345.00

4.1.3 Financial Resource Requirement

The financial requirement for this project was simple enough to determine because of the
budget
the team was

given. Most of the materials needed were recognized at the
beginning of the project. Although t
he financial effort requirement was fairly cut and
dry, it was still very difficult to find a fingerprint scanner, or biometric equipment, that
fell within the price range that the project was given. In order to stay within a reasonable
price range, the g
roup had to move from an embedded scanner to a PC based scanner.
The PC based scanners were less expensive and more manageable at this stage of the
project. Table 4
-
7 details the initial financial effort requirement.



16


Table 4
-
7. Original Financial Reso
urces Requirement.

Item

Without Labor

With Labor

Parts and Materials



Identification Device

$150.00

$150.00

Identification Software

$60.00

$60.00

Poster

$45.00

$45.00

Subtotal

$255.00

$255.00




Labor at $11.00 per hour



Broulette, Kevin


$990.00

Feickert, Wade


$1210.00

Hobart, Joshua


$1045.00

Seeman, John


$1100.00

Subtotal


$4345.00

Total

$255.00

$4600.00


Towards the end of the first semester of work, a more refined table needed to be created
to better reflect the time and resources spe
nt on the project. This estimate was carefully
put together and is detailed in table 4
-
8 below.


Table 4
-
8. Revised Financial Resources Requirement.

Item

Without Labor

With Labor

Parts and Materials



Identification Device

$400.00

$400.00

Identificati
on Software

$150.00

$150.00

Poster

$45.00

$45.00

Subtotal

$595.00

$595.00




Labor at $11.00 per hour



Broulette, Kevin


$1045.00

Feickert, Wade


$1320.00

Hobart, Joshua


$1045.00

Seeman, John


$1155.00

Subtotal


$4565.00

Total

$595.00

$5160.00


With any project, and with any requirement, things change over time. Such is the case
with
the

financial effort requirement. During the second semester of the project, more
time had to be put in to complete the necessary work. This change in time crea
ted an
increase in each group member’s labor cost. The parts and materials that were identified
at the beginning stayed constant throughout, but the price of these materials changed.
Table 4
-
9 below shows the final financial resources requirement.







17


Table 4
-
9. Revised Financial Resources Requirement.

Item

Without Labor

With Labor

Parts and Materials



Identification Device

$300.00

$300.00

Identification Software

Included

Included

Poster

$45.00

$45.00

Subtotal

$345.00

$345.00




Labor at $11.00

per hour



Broulette, Kevin


$1265.00

Feickert, Wade


$1320.00

Hobart, Joshua


$1210.00

Seeman, John


$1320.00

Subtotal


$5115.00

Total

$345.00

$5460.00


4.2 Schedules

A realistic, well
-
planned schedule is an essential component of every well
-
plann
ed
project. Most scheduling errors shall occur as a result of either not properly identifying
all of the necessary activities or not properly estimating the amount of effort required to
correctly complete the activity. Two types of schedules are shown in

this section. The
first schedule is Figure 4
-
1, a Gantt chart showing tasks versus the proposed project
calendar. For each item worked on to date, the chart contains a line for the original
schedule and the actual schedule that occurred. For each item
to be worked on in the
future, the chart shall contain a line for the original schedule, a line for the revised
schedule, and a line for the actual schedule that occurred. The second type of schedule,
Figure 4
-
2, is a Gantt chart that indicates when each
project deliverable shall be
delivered. For each deliverable completed to date, the chart shall contain a line for the
original project schedule, one for the revised project schedule, and one for the actual
schedule that occurred. These Gantt charts shal
l cover the entire project, from beginning
to end. They are shown below.



18


Figure 4
-
1. Gantt Chart Showing Project Schedule.



Figure 4
-
2. Gantt Chart Showing Milestone Status.


19

5 Closure Materials

This section is comprised of information explaining th
e finished product. After months
of work that lead to exhaustion and stress, it is time to put in writing what this project
does and what may be completed in the future. The following sections place closure on
the project.


5.1 Project Evaluation

This se
ction shall evaluate the degree of success of the project. The explanation shall
include whether or not each milestone was greatly exceeded, exceeded, fully met,
partially met, not met, or not attempted. An explanation shall be provided of the
evaluation

process. This explanation shall include a description of how the individual
milestone evaluations are combined into a total project evaluation and what that
evaluation result is.


During
the

project there were many milestones. The first of which was pro
blem
definition. This milestone was attempted and accomplished early in the first semester.
Defining the problem was something that had to be done early in order to begin a
successful project. After defining the problem, the group designed a project pos
ter.
The

project poster expectations were exceeded because of the grade received. The poster was
in the upper 10% of all the posters. Next was the research and product selection. This
was the most difficult task in the entire project. In order to exce
ed expectations, the
group collaboratively researched over 6 different technologies that would make this
project a success. Along with researching the different hardware devices, came
researching different software development kits (SDKs) that were usable

to configure the
system the way it needed to operate. The group spent many hours doing this research and
felt good with the fingerprint technology that was selected.


Along

with selecting the technology
,

was designing a system that would work within a
la
rge classroom. This system design

exceeded expectations and g
ave

a detailed look into
the entire system. After completing the design document, the group began the ordering
process. This was a very lengthy process, and actually changed the scope of
the

p
roject.
During fingerprint scanner selection it was recognized that an embedded system with an
SDK would exceed
the

budget. At this point, the group and advisors t
o the group
suggested that a PC
-
based fingerprint scanner should b
e implemented. Ordering
the PC
-
based scanner fully met the milestone expectations.


After the scanner was received, the group put in many hours with the SDK to develop the
fingerprint scanning system. The
group
met expectations on the system

design
, which
works correctly and t
akes attendance in a large classroom. Those milestones were all
fully met,
however the system did not function as quickly as desired for a large
classroom
.


5.2 Commercialization

This section shall include a discussion of the potential for commercializa
tion of the end
product. At a minimum, it shall include estimates of the following items: (1) what might

20

be the cost to produce the product, (2) what might be the street selling price of the
product, and (3) what might be the potential market for the prod
uct.


The classroom attendance taking system was inexpensive to create. It took many man
-
hours, but the actual cost of the device and software was fairly cheap. With this project,
the goal was to develop a stand
-
alone system, which came with all the nece
ssary software
and hardware in one device. Unfortunately, that system idea was
curbed because of cost
and a PC
-
based system was developed.


The PC
-
based system could be produced and sold at a fairly reasonable price, probably
slightly less than $500. O
nce the code has been developed, a system would be in place to
sell both the hardware and software together. The scanner was bought with a SDK, and
the group used the SDK to develop code to fulfill the project requirements. The system
could be sold with
the software on a CD along with the scanner, which could be
connected to any personal computer.


There are many users that could benefit from the system. At this point a PC based system
would not be the most attractive, but with future effort, an embedded

scanner can be
purchased and the software that was developed may be used. Potential
future
markets
could
include other colleges and universities, traveling lecturers (to record how many
people came to a given lecture), businesses to see what time employe
es are entering and
leaving work, and other places that collect attendance.


5.3 Recommendations for Additional Work

This section shall make recommendations for continued and/or additional work on the
general project problem. Recommendations shall be more

than just a list of items and
shall include a description of each item and specific reason(s) for the recommendation. If
the recommendations include any modifications, enhancements or additions, the reasons
for the changes shall be included.


As stated
above, the system that was developed was simply a prototype attendance
sys
tem that is PC
-
based. There are a few additional work items that were taken into
consideration during development of this attendance system. First, the software that was
developed
by the group was made to be easily transferable, or reusable, for embedded
scanners. The original goal of the project was to develop an embedded system. That is
the primary goal for additional work. There are many scanners out there that will work in
cr
eating an embedded system.


After an embedded scanner is purchased, or built, the individual(s) designing the new
system shall be able to use the software that was developed for this project. There shall
be few modifications that need to be made to the
software. Once the software is set up
for use with the embedded scanner it is expected that the scanner be placed on the market
for potential users within Iowa State University. If it is a success it is up to Iowa State
University and the professors with
in to market the scanner to the general public.



21

5.4 Lessons Learned

This subsection shall contain descriptions of the items listed in Table 5
-
1. What non
-
technical knowledge, such as time management and teamwork, is the least important
since almost eve
ry team has time management and teamwork problems to overcome.



Table 5
-
1. Lessons Learned.

1.

What went well.

2.

What did not go well.

3.

What technical knowledge was gained.

4.

What non
-
technical knowledge was gained.

5.

What would you do differently if you ha
d project to do over again.



During the course of the project all the team members worked well together and
contributed equally to the success of the project. That is always good when there is team
cohesion to accomplish the goal. Other things that w
ent well include technology
research. There was a lot of time that was spent researching the different technologies
and the decision that was made was mutual and respected.


Before purchasing the scanner, trying to find an embedded device was difficult.

Ordering
the scanner and finding which place would be the best to order from also was very
difficult. The group waited a very long time to order any products, and thus forced
rushed implementation at the beginning to get back on track. Those were thing
s that
didn’t go so smoothly during the project.


Technically, each group member learned how to develop code within a SDK. Visual
C++ was used for development and that was new to most members. Also, working with
biometric hardware and interfacing it wit
h the SDK was another lesson

learned
.


Writing reports, giving presentations, participating in reviews, and doing research were
the main non
-
technical skills that were learned. The detailed reports that had to be
written were new to the entire group. T
he presentations that had to be given in front of a
large class and soon the Industrial Review Panel is also something that everyone could
find beneficial
. Participating in class presentation reviews and judging how presentation
went when compared to othe
rs is good because it taught a person how to effectively
critique and give constructive criticism. Finally, doing research on a particular subject
and determining which product is the best for a particular project is always a good skill to
acquire as an e
ngineer.


Although the group did a tremendous amount of research, the amount that is done is
never enough. There is an unlimited amount of reference out there for specific biometric
solutions and determining how to develop a system can take many months,

even years.
The group would choose to make this project a research project. One where the group
researched and developed different systems using different technologies and then passed
on the information to another team which performed more research base
d on the given
systems. Once this research had been done, the system would be chosen and then
implemented. This would guarantee a working, nearly flawless system that took
attendance in a large classroom. Also, when ordering parts, that should always be

done
as early as possible.



22

5.5 Risk and Risk Management

This subsection shall document the risk
-
related topics listed in Table 5
-
2. Each of the
topics shall be discussed in sufficient detail to make the reader aware of what took place.



Table 5
-
2. R
isk and risk management.

1.

Anticipated potential risks and planned management thereof.

2.

Anticipated risks encountered and success in management thereof.

3.

Unanticipated risks encountered, attempts to manage and success thereof.

4.

Resultant changes in risk man
agement made because of encountered

unanticipated risks.



During project design and development the following risks were always a concern.
Having a group member leave was the primary risk. Fortunately, this situation never
occurred and the risk was

avoided. Another risk included having a group member not
carrying his or her load of the work. Again, this risk was never a problem because each
group member contributed equally in one way or another. A risk that was encountered
was running behind sche
dule. Unfortunately, it took a longer than expected to
select

and
purchase the hardware device. This caused a small schedule glitch, which was handled
by working harder once the scanner was received.


Running over budget was another concern of the grou
p. This risk would have been a
reality if the group had purchased an embedded de
vice. Instead, a PC
-
based scanner was
purchased to avoid this risk. Finally, group members not having sufficient knowledge of
the SDK or Visual C++ was another risk associat
ed with the project. This risk was
curbed by having group members become familiar with the SDK and study Visual C++.
Fortunately there were no unanticipated risks encountered so the group did not have to
deal with that aspect of risk management.


5.6 P
roject Team Information

This component has three distinct elements: (1) client information, (2) faculty advisor
information, and (3) project team information. They are described below.


5.6.1 Client Information

C:

Iowa State University Department of Ele
ctrical and Computer Engineering


Contact Information:


Dr. John Lamont





Professor Ralph Patterson III


Client Address:


324/326 Town Engineering



Ames, IA


50011


Client Phone Number:

(515) 294
-
2428

Client Fax Number:


(515) 294
-
6760

Client E
-
Mail:



lamont@ee.iastate.edu





repiii@iastate.edu



23

5.6.2 Faculty Advisor Information

Faculty Advisor Name:

Dr. John Lamont

Faculty Office Address:

324 Town Engineering


Faculty Mailing Address:

2215 Coover



Ames, IA


50011


Faculty Telephone Number:

(515) 2
94
-
3600

Faculty Fax Number:


(515) 294
-
6760

Faculty E
-
Mail Address:

lamont@ee.iastate.edu



Faculty Advisor Name:

Prof. Ralph Patterson III


Faculty Office Address:

326 Town Engineering


Faculty Mailing Address:

2215 Coover



Ames, IA


50011


Faculty Tele
phone Number:

(515) 294
-
2428

Faculty Fax Number:


(515) 294
-
6760

Faculty E
-
Mail Address:

repiii@iastate.edu


5.6.3 Project Team Information

Member Name:


Kevin Broulette

Member Major:


Computer Engineering


Member Mailing Address:

304 Lynn Avenue #14





A
mes, IA 50014


Member Telephone Number:

(402) 651
-
2004

Member E
-
Mail Address:

kbroulet@iastate.edu



Member Name:


Wade Feickert

Member Major:


Computer Engineering


Member Mailing Address:

114 South Hyland #2





Ames, IA 50014


Member Telephone Number:

(
515) 292
-
8201

Member E
-
Mail Address:

wafeicke@iastate.edu



Member Name:


Joshua Hobart

Member Major:


Computer Engineering


Member Mailing Address:

125 Campus Avenue #14





Ames, IA 50014


24


Member Telephone Number:

(515) 292
-
8314

Member E
-
Mail Address:

jw
hobart@iastate.edu



Member Name:


John Seeman

Member Major:


Computer Engineering


Member Mailing Address:

125 Campus Avenue #14





Ames, IA 50014


Member Telephone Number:

(515) 292
-
8314

Member E
-
Mail Address:

seeman@iastate.edu


5.7 Closing Summary

A l
ong
-
standing problem with university classrooms is the inability to effectively and
efficiently record classroom attendance. The solution to this problem is a simple,
reliable, personal computer based system to efficiently record and process student
atten
dance. The system will ensure that the student is present during the majority of the
class period, by establishing the times the student checks in and checks out. The system
will be easily transportable, operate on external power, and be compatible with
the
different classroom configurations on campus. Students will be uniquely identified to
record attendance. This device will contain software with the ability to recognize many
students. This device will be used as a personal computer based system to r
ecord the
student’s check in and check out times, and then easily download this information in a
concise format using Microsoft Excel to the instructor’s window
-
based computer. This
project will revolutionize attendance taking which, in many professors’ e
yes, is a growing
problem in many classrooms around the nation. Future work may be done to create a
stand
-
alone, internally powered system to take classroom attendance.


5.8 References

This component shall completely identify any materials taken from anot
her source and
used in the project.


Authentec, Inc. was used to purchase the fingerprint scanning device and the software
development kit.


Authentec, Inc.

Melbourne, FL, USA
-

Corporate Headquarters

709 S. Harbor City Blvd. Suite 400

Melbourne, FL 3290
1


Telephone Number
:
(
321
) 308
-
1300

Fax

Number
:
(
321
) 308
-
1430


25

5.9 Appendices

None.