Electronic Voting System for a Legislative Body Project Design Report

May02-05 December 4, 2001

Client:

Government of the Student Body

Faculty Advisors: Dr. John Lamont

Dr. Ralph E. Patterson III

Members: Robert E. Meyer III

Dan Phan-Quoc Kieu Michael T. Riley

Table of Contents

List of Figures ................................................................................................. ii List of Tables ................................................................................................. iii INTRODUCTORY MATERIALS................................................................. 1

Abstract........................................................................................................ 1 Acknowledgements ..................................................................................... 1 Definition of Terms ..................................................................................... 1

PROJECT DESIGN........................................................................................ 2 Introduction ................................................................................................. 2

General Background ................................................................................ 2 Technical Problem ................................................................................... 2 Operating Environment............................................................................ 2 Intended Users.......................................................................................... 3 Assumptions and Limitations .................................................................. 3

Design Requirements .................................................................................. 4 Design Objectives .................................................................................... 4 Functional Requirements ......................................................................... 4 Design Constraints ................................................................................... 6 Measurable Milestones ............................................................................ 6

End-Product Description ............................................................................. 7 Approach & Design..................................................................................... 8

Technical Approaches.............................................................................. 8 Technical Design ..................................................................................... 8 Testing Description................................................................................ 11 Risk & Risk Management...................................................................... 11 Recommendation for Continued Work.................................................. 12

Financial Budget........................................................................................ 12 Personnel Effort Budget ............................................................................ 13 Project Schedule ........................................................................................ 14

Initial Gantt chart ................................................................................... 14 Revised Gantt chart................................................................................ 15

CLOSURE MATERIAL............................................................................... 16 Project Team Information ......................................................................... 16 Summary ................................................................................................... 17

i

List of Figures Figure 1: GSB Session Layout, Clerk at the top in the box.............................................. 3 Figure 2: Router Internal Design ...................................................................................... 9 Figure 3: Individual Module ........................................................................................... 10 Figure 4: Sample Senate Layout ..................................................................................... 10 Figure 5: Posterior View, Single Module ....................................................................... 11 Figure 6: Single Serial Port Design ................................................................................ 11 Figure 7: Initial Gantt chart............................................................................................. 14 Figure 8: Revised Gantt chart ......................................................................................... 15

ii

List of Tables Table 1: Assumptions and Limitations ............................................................................. 4 Table 2: Functional Requirements .................................................................................... 5 Table 3: Revised Financial Budget ................................................................................. 13 Table 4: Personnel Effort Budget ................................................................................... 14

iii

INTRODUCTORY MATERIALS Abstract

Voting in a legislative body can be a time consuming process, in that individual votes must be counted either by roll call or other means that is not time efficient. Thus having an electronic voting system where the legislative body members can register their votes simultaneously would greatly speed up the legislative process and allow the legislative body to accomplish more. This is particularly useful when the legislative body has to vote several times during a session. The solution to this problem is to provide each legislative member with an electronic voting device that is connected to a computer (via a controller) that will automatically tally the votes and display the results and various statistics. The other major objective is to produce a voting system that is not only time efficient for the legislative body, but also cost effective. This allows the legislative body to be more effective in their sessions.

Acknowledgements

We would like to acknowledge the active role of the Iowa State University: Government of the Student Body (GSB) for their interest and participation in this project. Special thanks to GSB Senator and member of the InterFraternity Council: Michael Schaefer for his support and advice. Special thanks also to former GSB Senator and initial advisor Kathryn Kallaher for her initial work on this project.

Definition of Terms

GSB - Government of the Student Body ISU - Iowa State University LCD - Liquid crystal display LED - Light emitting diode PC - Personal computer SSP - Synchronous serial port, also known as SPI - Serial peripheral interface

1

PROJECT DESIGN Introduction General Background

The Government of the Student Body spends a large portion of their legislative sessions voting on various issues. This process is tedious and time consuming as votes are taken orally one by one. Thus, there is a need to save time by designing and introducing electronic voting that enables the senators to vote simultaneously. This requires that each senator have a voting module that allows him or her to cast either a ‘YES’, ‘NO’, or ‘ABSTAIN’ vote. Votes not received from individual senators are regarded as ‘NOT PRESENT’ votes. This module would then interface to a controller/router, which would transfer its information to a computer, which would in turn display the voting results in spreadsheet format using Microsoft Excel. There must be one module for each senator with a number of modules in reserve for future GSB expansion. There must also be modules in place for replacement of badly damaged modules and parts available for minor repairs.

Technical Problem

The major technical problem will be to design a cost-effective voting system that is easy to understand and use and simple to maintain. GSB meets in a room that must be set up and torn down after each legislative session, thus having a rugged system that will take the abuse of constant wear-and-tear is required. This system must be easy to use, taking into account that the senators possess various technical backgrounds. Another difficulty will be designing a system that uses a minimal amount of wires and connections. The Government of the Student Body has made a very specific request that setup and teardown should incorporate as few wires as possible. This is due to the fact that GSB has relatively short period of time reserved for setting up. This system must also be expandable to a degree that will enable GSB to add more senators as Iowa State University grows and expands. At this time, the major focus of this project is to design a system that incorporates all of these technical issues. There are several options available right now, that would require different design methods. For example, each module could be a micro-controller, thus requiring programming at the assembly level, and a router would be designed to direct the modules’ information accordingly. The software designed for the computer will be programmed primarily in Visual Basic, which allows exportation to Microsoft Excel.

Operating Environment

The electronic voting system will be used primarily the Campanile Room of the ISU Memorial Union. The voting modules must be connected in such a way that the system is adaptable to different layouts; primarily the unit will be deployed in a horseshoe shape with the secretary and computer at the head (see Figure 1). The voting modules and controller must be designed ruggedly to withstand weekly setup or tear down.

2

Figure 1: GSB Session Layout, Clerk at the top in the box.

Intended Users

The Senators of the Government of the Student Body will utilize primary use of the voting system. There exists a possibility that the modules will also be used by other student organizations, including the Inter-Residence Hall Association and the Inter-Fraternity Council. The software interface will be installed on the GSB laptop and used by the Secretary of GSB.

Assumptions and Limitations The primary limitation is budget, as GSB initially, although tentatively, offered funds of up to 1,000 dollars. Currently, the projected budget is approximately $1,700. This means that alternative means of funding must be found in order to lower the overall cost of the system. Additional funding will also increase the likelihood of GSB approving the request for their portion of the funding. Essentially, there are three funding possibilities, with five separate project outcomes. First, GSB, possibly with outside help, could provide the full amount, $1,700. If this event occurs, the project can continue as planned, with full implementation and testing to be completed by May of 2002. The second funding possibility occurs if GSB approves only its initial offer of 1,000 dollars, resulting in two project possibilities. The first option is to create and implement a scaled-down version of the original project, with full implementation and testing being performed on that version. The second option involves using the original design to create a partial implementation, most likely involving fewer individual modules. Testing would be performed up to and including the new limits of the system. The third funding possibility is no funding either from GSB or outside sources. In this eventuality, there exist two outcomes. The first option would be to construct a demo version of the project, with the total cost being approximately 100 to 150 dollars. The final option is to change the project to incorporate solely the design of the system, with no actual construction of hardware or software. The rest of the assumptions and limitations involve the voting system itself, specifically expandability, complexity, and security issues. Components for the modules must be readily available since the project requires components for 50 modules. Once the central controller/router has been designed, the possibility of altering that design to incorporate more users is very difficult. Therefore, the main controller/router must be designed with this limitation in mind. Also, the GSB has

3

limited time for each senate session. Therefore, the setup and teardown of the system must have low complexity in order to fully improve on the time efficiency of the GSB, which is one of the fundamental requirements of this project. The secretary and the PC will handle the entire operation of the system. This means that the secretary must be competent enough to use the system effectively and the PC must be at each meeting. GSB senators will only be using the voting modules. The modules must be designed simplistically to avoid any type of confusion in voting. The tally of the votes will then be sent from the vote-tallying software to Microsoft Excel, thus the controlling PC must also have Microsoft Excel installed. The final limitation deals with security, and the fact that will be no out-of-room connection (i.e. Internet) to compromise the security of the GSB and their voting sessions.

Table 1: Assumptions and Limitations

Assumptions Limitations • GSB Senators will require little or no

training in the use of the system. • GSB has a PC at each meeting • The GSB Secretary will be competent

to use the software created and understand the basic operation of the electronic voting system.

• The GSB Secretary will be familiar with Microsoft Excel.

• GSB will officially approve funding. (See paragraph above for details)

• All means of lowering costs will be employed.

• All necessary components needed will be readily available.

• Cost of approximately $1,700 • Limited expandability after controller is

designed. • Complexity in setup and tear down, in

that too complicated of a system will be rejected by GSB as an adequate solution.

• The controlling computer will not be hooked up to the Internet for the security of the voting system.

• Finite maximum of 99 units

Design Requirements Design Objectives

The primary objective of this project is to provide a high performance, low maintenance voting system at a reasonable price.

• Voting modules daisy chained together, counted by a central router that interfaces with a PC laptop via serial.

• Easy and intuitive voting module user interface • Easy to use computer interface for collecting the votes • Micro-controller based solution • Portable solution that is also designed to take standard misuse and abuse

during normal operation Functional Requirements

Table 2 outlines a list of functional requirements used to define the current system design. These requirements were gathered through consultation with both our

4

previous GSB attaché and her replacement. Each of the functional requirements is accompanied by a list of options associated with that requirement. If there is a choice of options presented, the final decision will be made by GSB at the time of project approval.

Table 2: Functional Requirements Requirement Description Voting Options There are four voting options that must be available to each

senator and must all be selectable on the individual modules: • Yes • No • Abstain

A vote of ‘Not Present’ is recorded if the senator is either absent or unable to record his vote.

ID Referencing There are two possible design options: • Each senator is assigned a module with a unique number

programmed into that module. Votes are recorded based on that number.

• Each module will possess the ability to let any senator log on with an assigned unique ID. Votes are recorded based on the ID number

Display of Results There are several options for displaying results of an individual vote:

• Visual display – Purchasing a scrolling, single-line LED display to provide the results of each vote to everyone present.

• Projector – The purchase (or borrowing) of a computer projector (i.e. ELMO) to project the laptop’s screen onto a larger area viewable by everyone in attendance.

• LCD on module – Incorporating a liquid crystal display on the individual modules assigned to each senator. LCD would consist of two lines, twenty characters per line.

• Imitation LCD display – Creating a large-scale light board with LCD-like display capabilities (see Figure 5).

• No display – GSB may decide that a display is not financially sound or needed.

Port to Microsoft Excel Regardless of the manner in which the votes are received from the individual modules, the end result must be the same. A record must be kept of each senator and the manner in which they voted for each issue. The totals for each of the voting options must also be recorded. These records must all be recorded in a Microsoft Excel spreadsheet for ease of maintaining, readability, and for efficient tallying of votes.

Voting Issue Displayed There are three options for the display of the issue currently being voted on:

5

• No display – The issue would be presented orally without the use of electronic display. The oral presentation of an issue is standard and will not be omitted even with the inclusion of an electronic display.

• Visual display – If the scrolling LED display were incorporated for presenting the voting outcome, it would also be programmed to display the issue being considered.

• LCD on module – If the individual module assigned to each senator contains a liquid crystal display, the display would be used to display the question to each senator.

Roll Call There are two options for handling roll call: • Oral – Attendance will be taken orally, with the clerk

reading a senator’s name and recorded his or her presence or absence.

• On module – If the individual module assigned to each senator allows the senator to log in, this login procedure will be used to produce an electronic attendance record.

Design Constraints

During the design process, there will be many things that either hinder progress or render some options unattainable. One of the primary design constraints will be funding. GSB will provide up to an unknown amount of funding ranging from nothing to approximately 1,700 dollars, and any additional costs would require personal funds from the group. Therefore, the final solution must come near the aforementioned budget limit. Another major concern is the complexity of the design. The solution must take into account that the GSB must make full use of the time that they have, and so setup time, teardown time, and training time must be minimal. Complexity is also an issue in regard to the actual building of the system. Since the group has been reduced to three members, total implementation time will rise drastically for each of the remaining members. The issue of maintenance is also a key constraint, that the modules be virtually free from defect and potential breakdowns.

Measurable Milestones Each milestone will be evaluated using a five-point scale, based on the particular milestone’s level of success. A milestone’s level of success will be measured based on what percentage of the milestone was actually completed, whether or not the milestone met the expectations of the group and the client, and whether or not the budget was maintained. 0. Not attempted 1. Not successful at all 2. Somewhat successful 3. Successful 4. Very Successful 5. Extremely Successful

6

Design Finalization/Research and Development This milestone involves actually working to determine the cost and effectiveness for each of the possible solutions. This would also include putting together a presentation for GSB on the possible solutions to allow them to decide which is best for them. Research and development includes research for suitable parts used in each solution. Funding and Design Approval A presentation will be made to GSB to appeal for funding and to provide design/cost analysis. This presentation would in all likelihood be given using Microsoft PowerPoint and would include both detailed diagrams and descriptions along with cost analysis for each proposed solution. Design This stage involves finalizing any design issues given the approved solution, including cost, complexity, and upkeep. Implementation/Software Development This phase includes building the design and programming the computer interface. Field Testing Actual votes will be performed during a GSB session, with any errors/bugs that may appear being resolved at this time. Final Approval This stage has one goal: having the electronic voting system be approved by the GSB: Rules Committee so that it can be implemented in GSB policy. Delivery The final stage concludes the project by delivering the completed voting system to the GSB with full functionality.

End-Product Description

The Government of the Student Body will use the Electronic Legislative Voting System during their senate sessions. This system will include fifty modules being assigned individually to each senator. Each module will incorporate the ability to identify each senator either by number or login. The module will allow the senator to cast a ‘YES’, ‘NO’, or ‘ABSTAIN’ vote, with a ‘NOT PRESENT’ vote being recorded for a senator that is either absent or unable to vote and the time the vote was opened. From there, a controller/router will recognize and redirect this information to a computer. The computer will then tally the voting results and record them in spreadsheet format in Microsoft Excel.

7

Approach & Design Technical Approaches

The approach for this electronic voting system will include hardware and software. Software will be used to interface between the computer and controller to the voting system. Different design approaches are being considered for the actual design of the voting modules. Various approaches include simple modules with switches to modules that have dual seven-segment displays and multiple operational buttons for a more interactive voting experience. A major consideration is being given to how to wire up the modules, with emphasis on maintaining a minimal number of connecting wires. The group’s final expected output is a system that is virtually foolproof. Thus, different design approaches are being considered on how to exactly wire the modules.

Technical Design When reporting the design to GSB, material to be included all consists of the following: pros/cons, cost, effectiveness, maintenance requirements, usefulness, ruggedness, ease of setup and ease of use. No criteria will be specified for rejecting or accepting a design, because the decision rests solely in the hands of the GSB. The team will offer recommendations based on experience. The physical design of the hardware will vary slightly based on the amount of funding received (See Assumptions & Limitations, page 3). The two design options are presented here. The first design will be constructed if the project receives full funding. The system will consist of a router and 50 individual modules. The router will interface with the PC, receiving and sending data both to and from the PC, and also to and from the modules. Figure 2 displays the internal layout of the router. In this diagram, the µC refers to the 8051 Micro Controller. The router is basically a four-module box in which the four micro controllers talk with each other via the SSP, and each micro controller then talks to its respective serial port connection. The two power supplies would also be installed in the box containing the router.

8

Figure 2: Router Internal Design

The individual modules will consist of the following: one 8051 micro controller with serial and SSP ports, one dual 7-segment display, 5 LED’s, 4 switches, RCA jacks for power, and various other miniscule elements such as capacitors and resistors. Figure 3 illustrates the basic appearance of a single module. Functionality is as follows: upon initial power-up of the module, the user uses the ‘Select First Digit’ and ‘Select Last Digit’ switches to alter the number represented in the dual 7-segment display. Once the user’s pre-assigned number is reached, pressing the ‘Send’ switch performs the login procedure, adding the senator to the list of senators present and lighting the ‘Logged In’ LED. Once all modules are logged in and/or the senate session has commenced, an “Open Vote” command is sent via the router to each module. The LED labeled ‘vote’ begins to flash, and continues to flash until the user has selected a vote. The desired vote is selected by repeatedly pressing the ‘Select Vote’ switch, effectively cycling through the three possible choices, with the LED corresponding to each choice remaining lit while that choice is selected. Once the user has selected the desired vote, the vote is cast by once again pressing the ‘Send’ switch. Once the vote has been closed, the PC tallies the results and the results are broadcast back to the individual modules. The user can then view the number of votes cast for each choice by repeatedly pressing the ‘Select Vote’ switch, effectively cycling through the three voting options (Yes, No, Abstain).

9

Figure 3: Individual Module

All of the modules must be interconnected along a daisy chain in order to be able to perform. A scaled down sample layout of a senate session is shown in Figure 4. The router connects to the first module on each daisy chain via their respective serial ports. The next link on the chain must be interconnected using the SSP port. The connections alternate until the end of each chain. Connections for power are not shown, but simply consist of a single RCA cord from each module connecting it to the next module in line.

Figure 4: Sample Senate Layout

In order to prevent confusion, the back of each module will be identical. A diagram of the rear view of a single module is shown in Figure 5. The SSP port will always be located on the upper half of the module, and the serial port will always be located on

10

the lower half. These connections cannot be interchanged because of the different jack sizes, thereby preventing accidental misuse.

Figure 5: Posterior View, Single Module

The alternative to this design features a single serial port connection between the modules. Each module would have a single serial port, with half of the data lines used for transmitting (Tx), and the other half utilizing a shared bus for receiving (Rx). A module-to-module demonstration of this design is shown in Figure 6.

Figure 6: Single Serial Port Design

Testing Description

Software testing will be done in the lab with regard to controller to computer interfacing. This involves sending and receiving signals over the serial port, and receiving and decoding messages sent by modules. Once the software is performing accurately, a prototype module with full functionality will be constructed and tested. After this, several modules will be produced and incorporated into a scaled down version of the complete system. After this phase of testing is complete, more modules will be built, eventually culminating in a full-scale test on the floor of the Senate of the GSB.

Risk & Risk Management Risk #1: GSB funding failure Probability: 20% Impact: Catastrophic

11

Contingency plan: Work closely with the GSB representative to ensure approval.

Risk #2: Cost exceeds funding Probability: 25% Impact: Catastrophic Contingency plan: Design incorporating funding limitations. Risk #3: Delayed product parts (such as modules) Probability: 45% Impact: Severe Contingency plan: Design the project goal around the shipment and delivery of parts so that the design and implementation is as independent from part delivery as possible. Risk #4: Design exceeds assumptions about GSB Secretary Probability: 30% Impact: Minimal Contingency plan: Work with GSB in training of the software and use of the voting system. Risk #5: Software delay Probability 50% Impact: Severe Contingency plan: Begin software development immediately; continually re-evaluate the complexity to ensure that the timetable is adhered to.

Recommendation for Continued Work

The recommendation of the group is to complete the project as designed. However, for the most part this decision is in the hands of the GSB. The Government of the Student Body will presently be voting on whether or not to appropriate funds for the construction of the voting system. If these funds are approved, construction will continue as planned. If these funds are denied, the recommendation will be to construct a ‘demo’ version of the voting system, comprised of the software and two to four individual modules. Termination of this project is neither constructive nor desired.

Financial Budget

A new Financial Budget has been researched and organized. The overall cost of the system has increased dramatically since the beginning of the project. This is mostly due to the large cost for PC board fabrication and additional parts that were not initially thought to be required. The development kit was also not figured into the initial budget, raising the cost another 100 dollars. These figures, although more in depth than the original figures, are still merely an estimate. It has yet to be determined whether individual companies will offer discounts due to the nature of the project. This could reduce the overall cost substantially. Fields marked ‘NA’ refer to quantities and costs that could not be determined at the time this document was

12

written. Figures for these costs and quantities will be finalized as information becomes available.

Table 3: Revised Financial Budget Item Quantity Cost/Unit Total Cost

8051 Flash Micro controller 55 $6.82 $375.10 Development Kit for 8051 1 $99.00 $99.00 Maxium Quad 7-segment LED drivers

50 $2.00 $100.00

Socket for 8051 55 NA NA Socket for Maxium Quad 50 NA NA PC Board Prototypes 4 $45.00 $180.00 PC Boards 55 $8.00 $440.00 Circuit Board Stand Offs NA NA NA Boxes 52 $3.00 $156.00 Power Supplies 3 $10.50 $31.50 Router Box 1 $20.00 $20.00 Dual 7-Segment Display 50 $0.65 $32.50 LED Surface Mount Holders

260 $0.09 $23.40

LED Red 110 $0.07 $7.70 LED Yellow 65 $0.15 $9.75 LED Green 110 $0.12 $13.20 Switches 204 $0.30 $61.20 RCA Connectors 108 $0.25 $27.00 3.5mm Jack 52 $0.20 $10.40 ¼” Jack 52 $0.50 $26.00 RCA Cable [6’] 52 $0.70 $36.40 3.5mm Cable [6’] 52 $0.70 $36.40 ¼” Cable [6’] 52 NA NA Capacitors 360 $0.05 $18.00 Resistors NA NA NA Total $1,703.55 Personnel Effort Budget

The Legislative voting project is projected to take approximately 382 hours of effort. These hours are then broken down into 3 phases: design, implementation, and testing. The design phase includes all necessary research in the technology of the project, cost of parts, and the presentation of our design to the client for budget approval. The implementation section of the project will be the actual construction of the voting unit and the central control module or router and the writing of the software for the central control module/router, PC user interface, and the voting module. The testing phase will be the testing of the modules in both a controlled environment and in a practical use environment. Testing will begin with software testing, followed by tests incorporating a single voting module, with final testing performed on a multiple-

13

module setup. The controlled environment will be the lab where the units will be tested to ensure basic functionality. The practical use environment will be a GSB meeting using the modules with the team members in a standby position to monitor the situation.

Table 4: Personnel Effort Budget

Personnel Original Design Effort

Revised Design Effort

Implementation Effort

Testing Effort

Michael T. Riley 20 25 68 40 Robert E. Meyer III 16 22 64 42 Dan Phan-Quoc Kieu 17 20 66 35 Total 53 67 198 117 Total Project Effort 382

Project Schedule Initial Gantt chart

Figure 7 illustrates the initial project design. Due to no approval on a particular design, the Gantt chart was preliminary and based largely on speculation. A more detailed Gantt chart has been developed, although the project is still waiting for approval by the GSB. The project has been reanalyzed and the timescale for all components has been reevaluated, as shown in Figure 8.

September October November DecemberTask 9/2 9/9 9/16 9/23 10/1 10/7 10/14 10/21 10/29 11/4 11/11 11/18 11/25 12/2 12/9 12/16 12/23Develop Project PlanResearch & DevelopmentPresentation for GSBDesign & Implementation--Software Design--Purchasing Parts--Hardware Assembly--Lab Testing (hardware)--Software Testing--GSB Testing

January Feburary March AprilTask 1/6 1/13 1/20 1/27 2/3 2/10 2/17 2/24 3/3 3/10 3/17 3/24 4/1 4/8 4/15 4/22Develop Project PlanResearch & DevelopmentPresentation for GSBDesign & Implementation--Software Design--Purchasing Parts--Hardware Assembly--Lab Testing (hardware)--Software Testing--GSB Testing

Figure 7: Initial Gantt chart

14

Revised Gantt chart September October November December

TASK 2 9 16 23 1 7 14 21 29 14 11 18 25 2 9 16 23 Develop Project Plan Research & Development Presentation for GSB Design & Implementation --Software Design --Purchasing Parts --Hardware Assembly --Lab Testing (hardware) --Software Testing --GSB Testing

January February March April TASK 6 13 20 27 3 10 17 24 3 10 17 24 1 8 15 22 Develop Project Plan Research & Development Presentation for GSB Design & Implementation --Software Design --Purchasing Parts --Hardware Assembly --Lab Testing (hardware) --Software Testing --GSB Testing

Figure 8: Revised Gantt chart

15

CLOSURE MATERIAL Project Team Information

Michael T. Riley (Manager & Hardware Design) 404 N. Dakota Ave. Ames IA, 50014 296-2733 mtriley@iastate.edu Computer Engineer Robert Ernst Meyer III (Communications, Design, Web-page & Software Design) 102 N. Dakota #2 Ames IA, 50014 268-4261 rmeyer2@iastate.edu Computer Engineer Dan Phan-Quoc Kieu (Recorder & Software Design) 131 Campus Ave. Ames IA, 50014 292-0532 dqbhere@iastate.edu Computer Engineer Dr. J.W. Lamont (Faculty Advisor) 324 Town Engineering Ames IA, 50011 294-3600 Fax: 294-6760 jwlamont@iastate.edu Electrical and Computer Engineering Dr. R.E. Patterson III (Faculty Advisor) 326 Town Engineering Ames IA, 50011 294-2428 Fax: 294-6760 repiii@iastate.edu Electrical and Computer Engineering Michael Schaefer (GSB Senator and Inter-Fraternity Council Member) GSB c/o East Student Office Space Memorial Union, Ames IA 50011 292-2416 mschaef@iastate.edu Construction Engineering

16

Summary “Time is money:” The motto of the business world. As of now, the GSB spends entirely too much time on voting. This is because historically, GSB has taken votes orally. Ideally each vote takes about 5-10 minutes if all senators are present and ready to vote. Realistically, not all senators are ready to vote making the estimate closer to 10-15 minutes. Taking into account the fact that GSB usually votes at least 8 times a meeting this can cause senate sessions to be unnecessarily long. This system will revolutionize the way GSB handles voting. With the ability to simultaneously vote without the need for an oral vote, time is no longer an issue. Voting can be accomplished in less than 5 minutes. The results are then directly compiled and outputted to the secretary’s PC. This results in a time saving of nearly 66% compared to the current voting process. This will enable GSB to handle business quickly and efficiently, which will then directly increase GSB productivity.

17