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 Schedules…………………………………………………………………………..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 Information……………………………………………….…..23 5.6.3 Project Team Information………………………………………………….…..23 5.7 Closing Summary…………………………….…………………………………….24 5.8 References………………………………………………………………………….24 5.9 Appendices…………………………………………………………………………25

1 Frontal Materials

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.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
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

1.3 List of Symbols

None.

2

3 1.4 List of Definitions

1

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

3

Class file – A file common to a professor for a given class. For example, a professor teaching computer engineering 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 interface 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 practical extraction and report language, Perl is a programming especially 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 referred 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.

4

5 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.

6 2.1 Executive Summary

Throughout this report information is given about the need for the project, the actual project 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 attendance. 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 attendance 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. Before, 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 important 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 the 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.

7 2.2 Acknowledgment

None.

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.

1 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 into 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 professor.

2 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 fingerprint 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 formatting 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 device 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 temperature 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)

1 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 laptop 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.

2 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 dates 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.

2.6 Assumptions and Limitations

1 Assumptions

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 in 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 entries per student, per class.

Limitations
The laptop being used will have at least a Pentium 2 CPU, 50 MB hard drive space, and 32 MB RAM.
The operating 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 device.
This is a small finger print scanning hardware connected to a laptop containing functionality for electronically collecting and storing students’ IDs and the times and dates that they were collected.
2. Users manual.
The user manual describes the device 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 and 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 its results.

3 Approach & Results
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.

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.
Identification of a student.
The system shall be able to uniquely identify each 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.
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.
Display student’s name after identification and sounds.
The system shall have the ability to display a message with the students 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.
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.
Downloading data to Microsoft Excel.
The system shall be able to download the identification data to a Microsoft Excel readable text file. The data must 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 members.

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.
The 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.

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 stored 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 accurate 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 four 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 considered, 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 shown 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 speed 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 transaction 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 approaches 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 disadvantages 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 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 picture, 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. Also, 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.
[pic]
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 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 our 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 interface 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 together 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 stored 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 displayed in figure 3.2 below.
[pic]
Figure 3.2 Overall Attendance System Design

2 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’ names, identification numbers, 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 their fingerprint three times to complete registration.

3 3.4.3 Identification sub-system

4 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 load the correct class database file into the system. The identification button is then pressed which begins the identification functionality. From now on students are able to log their attendance by pressing their finger on the device. Different tones will 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 two 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 session 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.

[pic]
Figure 3.3 Identification Sub-System Design

5 3.4.4 Data Storage and Display Subsystem

6 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 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. This process is displayed in figure 3.4 below.

[pic]
Figure 3.4 Storage and Display Sub-System Design

7

8 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 |

3.5 Implementation Process
The implementation process consisted of each team member coding their assigned modules of the system. The modules 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 functioned 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 Studio 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 to 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 implementation 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 code needs to be added to add functionality 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 could 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 storage and display, and user interface, independently. Once each module has passed testing, they are integrated and tested as a system. After the integration test passes, the system will be brought into a senior design class and tested in a real class atmosphere.

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 checked 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 correctly 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 files 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 adjustments 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 proper 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 number 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 functionalities 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 used in a real situation.

3.7 Project End Results
Currently the system is not in its finished state. Integration testing and class testing still need to be performed. Each module is, however, in a working state and functions independently of one another. Some 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 through 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 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 required.

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 schedules, 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 estimated 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 results.

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 and 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 may 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.

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 | | | | |
| |Meetings |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 mistakes 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 |
|Feickert, 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.

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 returned 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 was 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 the 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 group 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.

Table 4-7. Original Financial Resources 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 spent 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 |
|Identification 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 created 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.

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-planned 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 shall cover the entire project, from beginning to end. They are shown below.

[pic]
Figure 4-1. Gantt Chart Showing Project Schedule.

[pic] Figure 4-2. Gantt Chart Showing Milestone Status.

5 Closure Materials

This section is comprised of information explaining the 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 section 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 problem 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 poster. 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 exceed 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 large classroom. This system design exceeded expectations and gave 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 project. 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 to the group suggested that a PC-based fingerprint scanner should be 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 takes 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 commercialization of the end product. At a minimum, it shall include estimates of the following items: (1) what might 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 product.

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 necessary 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. Once 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 employees 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 system 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 creating 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 within to market the scanner to the general public.

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 every team has time management and teamwork problems to overcome.

Table 5-1. Lessons Learned.
|What went well. |
|What did not go well. |
|What technical knowledge was gained. |
|What non-technical knowledge was gained. |
|What would you do differently if you had 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 went 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 things 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 with 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. The 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 others 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 engineer.

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 based 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.

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. Risk and risk management.
|Anticipated potential risks and planned management thereof. |
|Anticipated risks encountered and success in management thereof. |
|Unanticipated risks encountered, attempts to manage and success thereof. |
|Resultant changes in risk management 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 schedule. 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 group. This risk would have been a reality if the group had purchased an embedded device. 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 associated 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 Project 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 Electrical 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

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) 294-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 Telephone 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 Ames, 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

Member Telephone Number: (515) 292-8314
Member E-Mail Address: jwhobart@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

1

5.7 Closing Summary

A long-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 attendance. 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 record 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’ eyes, 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 another 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 32901

Telephone Number: (321) 308-1300
Fax Number: (321) 308-1430

5.9 Appendices

None.
-----------------------
| |

----------------------- xxviii