Вы находитесь на странице: 1из 32

TABLE OF CONTENTS I. Introduction.. A. Background.. B. Problem Statement and Objective.. C. CONOPS.. Technical Approach. A. SOW.. B.

Analysis Plan Problem Analysis.. A. CATWOE Analysis B. Objectives. C. Constraints.. Requirements Analysis. A. Requirements Development B. Requirements Derivation.. Analysis of Alternatives A. Identify Alternatives.. B. Risk Analysis and Mitigation C. Technological and Economic Feasibility and Analysis D. Scoring Alternatives .. E. Sensitivity Analysis of Criteria Weighting. Architecture Solution A. Detailed description of solution.. B. Testing, Validation, and Verification. C. Implementation Plan Conclusion. References. Appendix.

Page No.

II.

III.

IV.

V.

VI.

VII. VIII. IX.

I.

Introduction A. BACKGROUND

In an ever evolving technical landscape, nations and institutions must be vigilant in keeping up with the advancement of modern times. Technologies, and its utilities, have changed the manner in which most Americans educate themselves, execute their financial responsibilities, and essentially retrieve all relevant levels of information in order to efficiently manage their academic, professional, and personal lives. While a massive portion of the private sector has transitioned into the Information Age of modernization through electronic communication, technical commercial trade, and academic enhancements brought on by standardized usage of modern technology, many of the federal government institutions lag behind in this respect. Specifically, their out of date systems do not allow for the implementation and deployment of an efficient means of engagement and interaction that mainstream technology provides to most Americans. The voting system in the United States, at both the federal and local levels, is amongst the most highly visible and scrutinized examples of how a governmental function has failed its registered voting citizens. The voting system has received great public scrutiny for the administering of the registration and voting processes as evidenced by high profile elections such as the Presidential race in 2000, and the highly controversial Ohio Gubernatorial race in 2004. This system has also generated great criticism for the means it both provides and fails to provide in the form of tally counts.1 Presently, adult citizens of the United States who are residents of one of the fifty states or the District of Columbia may not be restrained from voting for a variety of reasons stated in the 15th, 19th, 24th, and 26th Amendments of the United States Constitution. Research and studies over the past decade have shown that while this basic civil right is clearly defined, its execution is flawed.2 In the 2000 Presidential Election, the state of Floridas election votes had to be recounted as the administration and tally count of votes was riddled with conflicting results released by poll counters. Due to time constraints, national pressure, and protests, the official recount failed to account for a true consensus vote at a state level accurately and efficiently. It was widely reported and documented that several counties within the state had their votes dismissed due to failed repeat voter turnout on time, and that the manual chad vote counting system had confused voters with regard to whom they were actually voting for. This was the first time in American history that the democratic process and its voting systems were under such high levels of stress and scrutiny.1 The 2004 Gubernatorial race of Ohio brought about even more scrutiny at a national level regarding local administration of elections at state levels, and raised valid concern amongst citizens in states with similar local assembly infrastructures in place. Leading up to the election in Ohio, local Republican Secretary of State and Republican Governor Nominee Ken Blackwell enforced many decisions regarding the election process that ended up placing restrictions on voting for registered citizens. Political analysts responded by saying that Blackwell's newly proposed voting decisions would ultimately suppress the turnout among diverse low middle class populations within the state which were leaning towards, and expected to vote for Democratic nominee Ted Strickland.7 Political experts believed that these pre-election decisions by Blackwell represented a tremendous conflict of interest as he was a co-chair of President George Bush's re-election campaign in 1

2004. Due to the overwhelming belief that Mr. Blackwell was aiming to sway the states political seats in favor of the Bush Administration, local reaction turned to amending the local Ohio Constitution to remove oversight of elections from the Secretary of States responsibilities and to generate true election reform at the state level. At the conclusion of this election, in which Democrat Ted Strickland actually ended up ultimately winning, it was revealed that exit polls displayed a greater lack of confidence by voters in Ohio in comparison to what ended up being a five week recount in Florida during the previously mentioned Presidential Election recount of 2000.7 As recently as the 2008 Presidential election, it has been reported by independent election reform researchers that 2.2 million voters across the nation did not have their votes accurately accounted for due to failures of the authentication of voter registration at the state and county levels across many regions in the country. As a result, the Federal Election Committee (FEC) was tasked by Congress to modernize and standardize the voting system for all states and US territories.8 Our group has been assigned as the engineers to propose, design, develop, and ultimately deploy a new modernized and standardized voting system across the national and local electoral landscapes to improve the process, and to increase confidence in voters at the registration and actual voting points in the political process. It is our mission to utilize the most cost effective technological means to make it easier for voters to participate in the process, to reduce the costs of voting per individual over the long term, to use resources and energy more efficiently in the process, and to revolutionize the democratic process so that exercising this essential right of each registered citizen is a firm and solid representation in ones political views by the 2016 Presidential Election. B. PROBLEM STATEMENT AND OBJECTIVE As a team we composed the following problem statement: The current national voting system has caused a decrease in voter satisfaction by 24.2% over the last five years, creating an anticipated 20% decrease in voter turnout over the next four years. Our team objective is to be able to increase voter satisfaction by over 25%. C. CONOPS Our project team created a Concept of Operations (CONOPS) document to capture the FECs view of the voting system. The CONOPS describes the intentions of the voting system and provides details about what the FEC deems necessary for the new system to be successful. The document has a basic description of the iVOTE system; the FEC goals of the iVOTE system; a list of objectives that the iVOTE system should accomplish; strategies for handling certain parts of the systems engineering process (implementation, testing, etc.); tactics for ideas on functional components, processes, and voting system changes; possible policy changes; constraints for the voting system; and assumptions that are made. The CONOPS, along with the Systems Analysis Worksheet (SAW) and brainstorming, aided the process of deriving the objectives and their associated metrics and targets.

II.

Technical Approach A. SOW

The Statement of Work (SOW) documents the list of work steps and deliverables we are providing on the project to the FEC. It provides a binding agreement with the FEC and provides a boundary for the scope of the project deliverables. We broke the project down into three main phases: proposing the iVOTE project; defining the voting system; and architecting the final solution. For the project proposal phase, we stated that we would create a CONOPS document for the iVOTE system; perform CATWOE analysis; capture content for the first part of the Systems Analysis Worksheet; define the problem statement and objective; provide a system boundary definition; create a Work Breakdown Structure (WBS); define the teams work assignments; and draft a schedule for performing the work assignments on the iVOTE project. In the system definition phase, we stated we would decompose the objectives down to lower level objectives and define metrics and targets for each (and provide an objectives tree); create a functional decomposition diagram; create use case diagrams for the high level functions; state the requirements; provide several architecture alternatives; analyze the architecture alternatives; perform risk assessment on the alternatives; complete an economic analysis; provide a final architecture solution by scoring the alternatives and performing sensitivity analysis on the weights for the evaluation criteria. During the system architecture phase, we articulated that we would provide a detailed description of the chosen solution; create the architecture depictions (OV-1, 2, 3, 5; SV-1, 5; AV-1); describe the testing, verification, and validation of the chosen solution; create an initial implementation plan; and provide this final report. The sections in this final report demonstrate that we have completed these tasks. B. ANALYSIS PLAN Group 2 utilized systems engineering techniques learned during this cohort and applied them towards increasing voter satisfaction and modernizing the voting system. We used the formal methodologies from the systems engineering classes to demonstrate that we have a thorough understanding of the systems engineering process and lifecycle. At each phase of the process, we applied the necessary techniques (such as systems analysis worksheet (SAW), brainstorming, stakeholder elicitation (CONOPS), functional decomposition, use cases, alternatives scoring, etc.) to aid in formulating the foundation and the design of the new modernized and standardized voting system. We also used tools, like the MITRE Risk Tool for risk analysis and Robust Decisions Accord for stakeholder weighting of architecture criteria, to help achieve what was needed to be accomplished at each of the phases. 9,13 To design the new voting system, we first created a blueprint by creating a sound set of requirements based on the objectives and associated metrics and targets (derived from the CONOPS 3

and SAW). Then we explored functional elements to perform the functions outlined in our functional decomposition and satisfy our requirements. After ruling out numerous element options, we were able to create three main architectures that could fulfill the functions and requirements. We then analyzed the risks involved with each architecture, ranked the risks based on level and likelihood, and created mitigations for each. Next, we considered costs associated with the architectures. We also explored ways to save money across all three architectures (such as using virtualization for servers). After that, we created a scoring scale for the criteria (based on all of the objectives), then scored and weighted the criteria based on expert judgment to establish an overall score for each architecture. Using sensitivity analysis, we assessed the appropriate weighting of the criteria. We then used all of the architecture analysis to deduce the optimal solution. Once we found the optimal solution, we showed how the new voting system will be verified and validated (using queue simulation, etc.) and how the new system should be tested to make sure it is performing at the levels stated in the objectives. Lastly, we created an initial implementation plan and schedule and stated the feasibility of the implementation. III. Problem Analysis A. CATWOE ANALYSIS The CATWOE analysis was used to help define and identify the problem with voter satisfaction and the voting system. It provided necessary information to see the big picture and understand what is important. Customers: The customers benefit from, or are victims of, the metamorphosis of the system. The voters are the customers in the voting system and they are the ones that need to be addressed and satisfied during this transformation process. The voters will be using the new voting system and we need to make sure that the system is easy to use, reliable, secure, and protects the voters privacy. The FEC is an indirect customer that will be overseeing the new voting system and will be held responsible if voters needs are not met. Actors: The actors of the system carry out the activities of and support the system. The administrators (booth workers, technicians, etc.) are responsible for assisting voters and supplying information about the voting process, maintaining the voting system, and making sure the election process is followed according to regulations. The voters use the system to cast their votes. Government regulators ensure that everyone involved in the election process and the process itself follow the regulations set forth by Federal and state governments. Transformation: Transformation describes the current and future states of various processes within the system. The voting system will be converted from a manual, inefficient, expensive, error-prone, nonstandardized, and confusing process to an automated, efficient, less expensive, less error-prone, standardized, clear process.

World View: The world view provides insight from people seeing the system from the outside. We have collected six distinct world views. Public perception is that modernized technology will streamline and enhance voting processes. The FEC believes that voter turnout may increase due to an improved voting process. Various media outlets think that a standardized voting process may increase the efficiency and timeliness of polling results. Congress feels that an automated voting system will save tax dollars. The Environmental Protection Agency (EPA) will fully support a voting system that uses modernized technology because they perceive a decrease in the current carbon footprint. Owner: The owner is the person or entity that owns the process and is crucial to its success or failure. The FEC (with a representative from each state) is in charge of overseeing the transformation of the voting system; provides the funding for designing, building, and implementing the voting system; and makes sure the voters satisfaction is considered throughout the transformation process. Environment Constraints: The environmental constraints are the factors that bind the system. We have found several environmental constraints for the modern voting system. The cost of implementing technology for the voting system is constrained by federal funding. The modernization of the voting system is bound by the technology currently available. The placement of polling centers are constrained by geographic areas that can supply the necessary resources for administering polling centers. Weather can cause power failures and deter voters from going out and voting. Federal and state governments, as well as voters, could undergo a paradigm shift in how they view the problems and the importance of fixing the problems in the voting system. The voting system is heavily confined by the amount of government funding Congress will allot for the new system. B. OBJECTIVES As stated in Section 1, our main objective is to be able to increase voter satisfaction by over 25%. That objective was then broken down further into seven objectives. Those objectives were broken down further until we were satisfied with the overall set of lowest-level objectives that the system must accomplish. For each lowest-level objective, a metric and a target were assigned to measure the success or failure of meeting each objective. These objectives were used to generate the requirements of the voting system and were used to assess the functional elements for building the architectures. The full objectives tree is shown in Figure 1 in the appendix. C. CONSTRAINTS The following are primary constraints of the development of our design of the voting system: The initial design needed to be finished by July 18th, 2011 We were confined by the currently available technology to develop the system The federal funding for the project is approved by Congress The amount of federal funding approved for the project may limit the scope The new voting system must be implemented by the 2016 elections

Additional constraints are listed in the CATWOE section. 5

IV.

Requirements Analysis A. REQUIREMENTS DEVELOPMENT

The requirements analysis phase of the project describes what the system will do. The development of requirements laid the foundation for the architecture of the iVOTE system. It was an arduous task that required an immense amount of effort and team focus. The process also helped establish the system boundaries into which the iVOTE system would be developed. The continued dialogue with the FEC was necessary to ensure that changes or refinements were captured. Requirements were developed from the objectives and their associated targets, through functional decomposition (Figure 2), creation of multiple use cases, and brainstorming sessions. Collaborative brainstorming provided freedom for the flow of ideas to allow the team to explore alternatives and easily eliminate ideas that were not relevant. Group 2 developed a detailed list of requirements that evolved and became more and more refined over time. The team wrote iVOTE requirements in a clear and concise manner so that the system can be properly designed to meet FEC needs. We made significant efforts to ensure that each requirement incorporated a performance measure to validate the system.9 For traceability, the team came up with its own unique identifier schema for the requirements. The identification schema is constructed from the system name (iVOTE), the version number, the requirement number (within its type), and the requirement type. An example identifier for a requirement is iVOTE-1.0-001-F. The purpose of this unique numbering is to trace any requirement throughout all documents associated with the iVOTE system development. Its use supports continuous life-cycle management, correlation with the functional decomposition, and interpretation or recognition of sub-systems components. The full table of requirements is shown in Figure 3. B. REQUIREMENTS DERIVATION Articulate, concise requirements were the vehicle that laid out the entire infrastructure for the system architecture and provided the input to operational, functional and physical views of the iVOTE system. Requirements analysis enabled sound design and developmental efforts. Full iVOTE system capabilities were derived as a result of requirements analysis. There is a reconciliation phase of the requirements analysis that ensures support of the customers expectations. The team established a requirements document that categorized them by their type and unique identifier. We also created a Functional Allocation Matrix that maps the lowest-level functions from the functional decomposition diagram to the requirements to show that we have captured the necessary functionality of the system.10 Capturing solid requirements is a difficult process and requires continuous refinement throughout the evolution of the systems engineering process. It is one of the most critical and challenging aspects of systems development because of the need to include major stakeholders in the process to make sure their interests are captured. With good requirements, the entire system development is clearer while making the functional specification feasible. The framework for the iVOTE system was fabricated from the establishment of well written, concise requirements. A Function 6

Allocation Matrix (Figure 4) was created to show how all the functions from the functional decomposition are mapped to the requirements. V. Analysis of Alternatives A. IDENTIFY ALTERNATIVES After we developed our requirements, we found components that would satisfy them and perform the functions in the functional decomposition. We first created component categories (voting and registration interface, identification/authentication, and security) and then identified components that would fit into those categories to potentially be used in the set of alternative architectures. Next, we formed a hierarchy diagram depicting the component categories and associated components. Figure 5 in the appendix shows the hierarchy diagram used for the architecture development. In order to depict how we eliminated various components from the possible choices, yellow callouts, along with red slash lines, were used. Each callout states how each of the eliminated components failed to meet the target of specific objectives. After we went through this process, we developed our architectures based on the available choices that were left. We defined three final architectures (known as A-1, A-2, and A3) as shown in Figure 6 that became the basis for our analysis of alternatives. B. RISK ANALYSIS AND MITIGATION iVOTE system risks were researched and identified through brainstorming sessions. As a result of the collaborations, thirty-seven risks were identified. They were compiled and entered into the Mitre Risk Matrix software tool for consolidation and weighting quantification. The Risk Matrix software was used in the basic mode, and the following columns of information were used in our analysis13: 1) 2) 3) 4) 5) 6) 7) 8) Risk Number an assigned integer value Related Risk Number other risks that are affected Risk risk description Impact of Risk (C=Critical, S=Severe, Mo=Moderate, Mi=Minor, N=Negligible) Po - Probability of Occurrence from 0 to 100% Borda Rank provided by the Risk Matrix Software R Borda ranking as calculated by the Risk Matrix Software Manage/Mitigate a strategy of mitigation provided through group consensus

The thirty-seven risks were applicable for the three reduced architectures that we have evolved. The Risk Matrix Software was applied independently to each architecture using different percentage values for the probability of occurrence. The results were then sorted by Borda Rank to derive each architectures specific Borda ranking. Associated iVOTE risks were a major part of the analysis of alternatives in order to determine which architectural design to select architectural design A-2 as our final solution. As architectures were independently analyzed for risk, information security ranked considerably higher as an area of concern for the iVOTE system. For example, in architecture A-1, information security related risks appeared in 7

six of the top ten riskiest consequences of the voting system. This was also true of architectures A-2 and A-3, leading our team to conclude that information security is the greatest overall risk to the iVOTE system. Mitigation strategies were crafted to each specific risk item to reduce the impact of negative consequences to our system, should a risk occur. The percentage of occurrence value for each risk was derived from expert judgment. Noting that information security was the biggest risk to the iVOTE system, the team composed a strategy to mitigate the risk by creating an information security policy, performing a threat and vulnerability assessment, and applying safeguards (such as encryption, access controls, system auditing and logging, redundancy, etc.). A risk mitigation plan will be drafted and approved by the FEC, and subsequently utilized to manage risks. The risk mitigation plan will have to be monitored and revised as appropriate to align with project evolution. The full risk table is depicted in Figure 7. C. TECHNOLOGICAL AND ECONOMIC FEASIBILITY AND ANALYSIS Many options and alternatives were explored by our engineering team. To implement and deploy within the allotted budget constraints and project schedule, we composed our technical and economic analysis to ensure feasibility and cost effectiveness of the proposed iVOTE system. While undergoing the design phase, selection of a surefire architecture was essential. Our engineering team undertook many technological options via market leading vendor research and analysis, subject matter experts, architectural designs, and potential geographic locations of the data center deployment into consideration for the selection of our architecture. This analysis also contributed to the selection of technical components to procure and integrate into the voting system.3 Ultimately, cost and feasibility determined the architecture that was chosen to design and develop. Each proposed architecture provides functionality that supports identification and authentication of a given user and network security for the voting system. Architecture 1 (A-1), Architecture 2 (A-2), and Architecture 3 (A-3) all possessed web application capabilities; however, only A-2 and A-3 provided web services and a Smartphone application. A-1 was the least costly option to design and develop, but did not provide the aggregate value needed to cover all identified factors captured in the objectives and requirements.11 When analyzing the comparison of final costs associated to build A-2 and A-3 respectively, A-2 proved to be the best value overall as a result of A-3s USB authentication devices which would have exceeded the proposed budget. Total cost figures across architectural designs consisting of software development and information security can be found in Figure 8.12 Other economic cost considerations taken were in the selection of the location of where to host the data center containing virtualized servers. It should also be noted that all costs were found through market research with the exception of specific costs for web services, web application, and intrusion protection systems for the data center.14 The virtualized servers were found to decrease data center costs by 30% compared to completely hardware based servers. Housing the actual host datacenter proved to be most cost effective in the Midwestern states where cost of living and energy costs were significantly lower than the costs associated in major market cities and states. Historic voting mechanisms utilized more stationery and labor costs, while the proposed design interface eliminates much of those costs by measuring the votes virtually. The modernized system as defined by A-2, is 8

estimated to reduce Per Voter cost by 96.4%. This Per Voter cost savings along with the overall economic analysis are significant factors in gaining governmental support.15,16,17 D. SCORING ALTERNATIVES The scoring of alternatives provides one way to find out which alternative would be best suited to be the final solution for the iVOTE system. All of the objectives and their associated targets were used as the evaluation criteria for the basis of the scoring. Using expert judgment, a value was assessed for each criterion as to what a particular architecture would perform at for that criterion. In order to score the alternatives, we first had to create a rating scale that would be used to quantify the criteria on the same level. A scale of 1 to 9 was used (5-meets the target; 1-completely misses the target; 9completely exceeds the target) to rate each of the criteria based on the value each received using expert judgment. A weight was then assessed for each criterion based on expert judgment and the FECs input. The weight and rating were multiplied together to get a score for each criterion per architecture. The scores for each architecture were then added together to get a composite score. Figure 9 shows the Excel table that was used to calculate the scores. As shown in the figure, architecture A-2 scored the highest which coincides with what the FEC decision makers deduced using a software application called Accord (Accord allows multiple decision makers to assess criteria by stating how they feel each criterion satisfied the target value and how certain they are of the assessment). The results from Accord are shown in Figure 10. Based on the scoring, risk analysis, and economic analysis for the three architectures, A-2 was selected as the iVOTE architecture. E. SENSITIVITY ANALYSIS OF CRITERIA WEIGHTING After scoring the architectures, sensitivity analysis was performed on the criteria weights to see if a small change in the weights would cause a significant change in the final outcome. The FEC top five most important criteria (Figure 11) were analyzed in pairs and the weights were traded off to see if the final composite scores would change. A chart depicting this analysis in Figure 12 shows that none of the weight trading seemed to affect the final result of the A-2 architecture scoring the highest. The next step was to perform sensitivity analysis on the top five criteria versus several lowestweighted criteria. The chart in Figure 13 shows again that none of the weight trading seemed to affect the final result of the A-2 architecture scoring the highest. Based on this analysis, the weights of the criteria were not modified from the original weighting schema.

VI.

Architecture Solution A. DETAILED DESCRIPTION OF SOLUTION

A Function Component Matrix (Figure 14) was created to show how the lowest-level functions from the functional decomposition can be mapped to the components of architecture A-2. The OV-1 shown in Figure 15 depicts the system (based on the A-2 architecture) in two main sections. The upper part of the diagram depicts methods for the voter to cast their vote. These methods include voting via

the Internet, smart phone, and polling centers. The lower portion of the diagram depicts the back end of the system: Security, Authentication, Registration, and the Central Voting System. The upper left portion of the diagram depicts the polling centers. Polling centers in the iVOTE system are operated similarly to current polling centers. A registered voter would enter the polling booth, log in to the system with their credentials, and cast their vote. Upon exit, the voter may be asked to participate in a voting survey. The Remote Voting node is where the paradigm shift in the traditional voting system will occur. A web based voting interface, built on Service Oriented Architecture (SOA) principles, allows the voter to cast a vote from any web-enabled device: personal computer, tablet, smart phone, etc. This allows the voter to vote from non-traditional polling places, at their convenience, helping to alleviate the waiting time at the polling centers. Human factorization will have to be taken into account when building the interfaces to make them intuitive and easy to use for the voters. Remote voting increases the satisfaction of both the remote voter (by not having to wait in line) and the polling center voter (by decreasing the crowds at the polling center). As the remote voting concept is increasingly accepted by the voting public, the number of polling centers is anticipated to decrease. The middle and lower section of the OV-1 diagram depicts the central part of the iVOTE system. The registration process takes place prior to the election date. The iVOTE system will provide a national registration web interface in addition to the current registration process: registering with Department of Motor Vehicle offices and local election boards. The iVOTE system will store the registration information. The interfaces between the Registration sub-system and the registration input methods utilize the Network security in place: AES encryption, Medium Security Firewall and Maximum security IPS. When the voter is ready to vote on Election Day, they will also need to interface with the Registration sub-system to authenticate as a registered voter and ensure that they are allowed one vote only. The authentication process uses the same network security process as the registration process. The authentication process also uses a triple user identification method to minimize fraud and bot access: Username/Password; PIN; and CAPTCHA a challenge response test used to help ensure the response is generated by a person. (CAPTCHA WIKI) Once a voter is authenticated, a ballot will be presented for the proper jurisdiction. This ballot will include candidates for national, state, and local offices and referendums that are stored in the Candidates and Referendums database. After the voter makes selections, a confirmation page will then be presented that the voter must either agree to, or return back to the ballot. Once the voter agrees to the confirmation page, the vote will be recorded in the Voting Results database in the National Data Center (NDC) of the Central Voting System node. The three databases housed in the Central Voting System are kept separate for voter confidentiality as well as security; issues in one database will not affect another database. As votes are cast, the NDC compiles, validates, and reports them. Interim and final results are reported to media outlets and other official sources. Final results are also sent to local election boards, state boards, and the FEC. 10

These nodes are made possible with the extent that the Internet has been adopted. The remote voting system is dependent on Internet connections for the voters to cast their votes and have them registered at the NDC. All data transfer between sites is via an Advanced Encryption Standard (AES) encrypted data link (https protocol). AES encryption was chosen over DES and 3DES because of speed and performance factors discussed in the alternatives section. B. VERIFICATION AND VALIDATION This Verification and Validation (V&V) Plan is the systematic strategy to test the iVOTE system to ensure compliance with the design specification, objectives, and requirements. Tests may consist of a simple pass/fail visual inspection, or be comprised of complex statistical figures which must meet or exceed requirements in order to be declared successful. The following details the responsible quality assurance parties and V&V focus areas. Federal Election Committee (FEC): The FEC is responsible for the verification and acceptance of the design deliverables. Each milestone deliverable must be inspected and given a pass or fail designation via consensus vote. In addition, the FEC must perform process improvement verification by validating goals to be reached after each iVOTE project phase. One method for validation will be an iVOTE provided queue simulation program (Figure 23). This program would have the ability to produce polling center statistics such as: Average Number of Voters, Average Number of Voters Waiting in Line to Vote, Average Wait Time, and Average Voting Time. This verification could be used to ensure that the requirements are being met, and to validate the improvements made by the iVOTE system; such as relieving polling center congestion. Voter Focus Group (VFG): The VFG is a randomly selected group of voters that have agreed to participate in our process improvement initiative. These members will conduct product acceptance validation such as customer satisfaction surveys, functional requirement and regression testing, and validation of ballot submissions. The customer satisfaction surveys will consist of qualitative categories like user interface ease of use, information presentation effectiveness, effectiveness of help information, time management efficiency, as well as their overall voting experience. The VFG will also be asked to step through each section of the application to ensure that all functions are properly implemented according to requirements, and verify that their input data has been captured correctly within our database report. iVOTE Team: The iVOTE team will validate the date in the National Data Center (NDC) against the local databases to ensure consistency, validate all functional decomposition items are implemented and working properly as independent components as well as integrated with disparate components or subsystems, and validate network statistics and system efficiency against our requirements. C. IMPLEMENTATION PLAN Factors to be considered for a successful implementation were grouped into three categories: highest probability of failure, necessary resources, and likely obstacles.

11

The two items with the highest probability of failure identified are obtaining full federal funding and handling high volumes of simultaneous ballot submissions. Obtaining federal funding is potentially challenging as the U.S. economy is presently in a recession. The iVOTE systems implementation costs will be offset by lower operating costs and projected profits from selling access rights to early analysis firms (such as CNN and MSNBC). This is essential to garnering funds for the iVOTE system. Necessary resources are funding, smart-phone licenses, data storage facilities, DMV registered voter records, software licenses, hardware acquisition, and contractors to develop the system. As discussed earlier, funding is the main resource for implementation. Acquiring smart phone licenses to deploy our iVOTE software is also crucial for system functionality. In order to satisfy the goal of providing multiple voting options, smart-phone voting has been identified within our architecture solution as feasible and desirable. DMV registered voter records is the primary means for efficiently and effectively compiling the iVOTE user database upon initial implementation. Also, contractors, software, and hardware must be procured in order to ultimately construct the system. Finally, likely obstacles will include: funding approval, throughput management, and data protection advancements. Funding has been discussed at length within this plan and remains a key focus area for implementation success. Throughput management must be monitored because of the large amount of voters that potentially could bring down the system by casting simultaneous ballots. Aside from funding, data protection is the second most likely obstacle that will need to be closely tracked in order to allow for successful implementation. If the iVOTE system is perceived to have insufficient safeguards for the protection of sensitive information, our project will be in jeopardy. The iVOTE implementation schedule shown in Figure 24 follows the engineering development of the system. The Initial System Design is followed by the Critical Design. Once the Engineering team completes the Critical Design and successfully completes the Critical Design Review, the Developers take over to create the prototype system. The prototype is a small scale test of the system to ensure the design is feasible. A successful prototype will lead to the Implementation phase of the project. Implementation has two phases: Trial System and Full Implementation. The Trial System is a small scale implementation where the system is deployed to several voting jurisdictions. With this small-scale deployment, iVOTE testers will deploy with the system to ensure it is implemented properly. This phase will have to include focus groups to provide feedback on the usability of the system as well as other metrics being tracked for the system. The deployment team will be called on to ensure that the full size system is built and the system is deployed to all jurisdictions. The deployment team will also develop a training plan and provide training to local jurisdictions. Once the Full Implementation phase is complete, the iVOTE system is ready for operation. The iVOTE system will transition to Operations and Maintenance. System disposal is a continuous cycle within the Operations and Maintenance phase. As systems are determined not to be economically repairable, they will be replaced. A detailed analysis of the systems deployed will determine the typical lifecycle of the voting machines. The schedule, as it is currently, has the full implementation completed in the third quarter of Calendar Year 2015. The system charter calls for this system to be implemented by the 2016 national election this gives us approximately twelve months of slack time in this schedule. 12

Essentially, the iVOTE team has constructed a detailed implementation schedule which will provide the project team with a roadmap to bridge the gap from the design phase to the operational maintenance phase. The highest level attributes of the implementation schedule consist of an initial system design, system review, critical design, prototype iterations, initial implementation supported by a trial testing system, and ultimately concluding with our full implementation of the system. Along with the identification of the scheduled tasks, we have also designated the appropriate personnel to execute and be accountable for the task completion within our implementation schedule as a whole. VII. Conclusion

The objective of our analysis was to increase voter satisfaction by 25%. Group 2 has demonstrated the use of the systems engineering process to modernize and standardize the voting system. By doing so, we have ensured that the voting system is more efficient, less error-prone, and easier to use, therefore increasing voter satisfaction. We have also shown that a modernized voting system will positively impact the environment by reducing the use of administrative resources such as manpower and stationery. Through our economic analysis, we have stated how virtualization of servers can reduce costs by up to 30% and also decrease the carbon footprint of the new iVOTE system by using less power and space. Even though our risk analysis revealed that information security is clearly our biggest risk, it can be well managed and mitigated through the use of our strong security policy, a thorough threat and vulnerability assessment, and the application of safeguards; such as encryption and network security appliances. This is only the beginning for the modernized voting system. In the future, additional analysis will need to be completed to ensure that the iVOTE system performs at the optimal levels expected in the requirements and objectives. Throughout the maturation of iVOTE system development, refinement of requirements, additional functional elements, future expansion, composition of an extensive cost model, provision of greater levels of detail for the established architecture depictions, and thorough testing procedures are tools that the team will utilize to continuously enhance the modernized voting system. Group 2 will need to further analyze the registration process, verify voter acceptance of the new system, and state how to maintain and upgrade the system throughout its lifecycle. Additionally, the team will need to continually update the FEC on progress as the system is built and implemented to secure congressional funding for the project. We are considering utilizing the National Security Agency (NSA), and other national law enforcement and intelligence agencies to monitor security during elections which should reduce risk and increase voter confidence. Expanding the elections from one day to three days will also increase the efficiency of the system, thus increase voter satisfaction as well. We strongly believe that this new modernized voting system that we have conceptualized during this Capstone course can truly come to fruition if it is planned, designed, and implemented properly. Voter satisfaction will increase, as well as voter turnout, which will provide a more accurate reflection of the people of the United States.

13

VIII.

References

1[WWWdocument],http://www.pewcenteronthestates.org/uploadedFiles/MN_WA_recounts_report.pd

f 3 JUL 2011.
2[WWWdocument],http://www.pewcenteronthestates.org/uploadedFiles/Election%20Preview%20FINA

L.pdf 21OCT 2008. The Real Cost of Voter Registration: An Oregon Case Study (Washington, DC: Pew Center on the States, March 2010); http://www.pewcenteronthestates.org/report_detail.aspx?id=56478.
3

Maintenance of State Voter Registration Databases: A Review of Relevant Policies and Procedures (Washington, DC: National Association of Secretaries of State, September 2009), 411; http://nass.org/index.php?option=com_docman&task=doc_download&gid=792.
4 5 Caltech/MIT Voting

Technology Project, Voting: What Is, What Could Be, July 1, 2001, 51; http://www.vote.caltech.edu/drupal/node/10. Barreto, Glaser, and MacDonald, Online Voter Registration (OLVR) Systems in Arizona and Washington, 93. In fact, approximately 90 percent of all online registrations cost nothing to process, due to an absolute match with data in the motor vehicles database. The other 10 percent required some followup, which cost on average 33 cents per form, leading to an average cost of 3 cents for all online registrations.
6 7 8

[WWWdocument], http://www.eac.gov.

Improving State Voter Registration Databases: Final Report (Washington, DC: National Research Council of the National Academies, 2009) 45; http://books.nap.edu/openbook.php?record_id=12788&page=R1. NYS Project Management Guidebook, Section III:2 System Requirements Analysis; www.cio.ny.gov/pmmp/guidebook2/SystemReq.pdf, Thursday, July 14, 2011
9

Presentation, EMSE 297 Problems in Engineering Management and Systems Engineering, Session #3; A Little Primer on Writing Good Requirements, Dr. Tom Holzer
10 11 http://osxdaily.com/2010/09/07/iphone-development-costs/ 12 http://www.vmware.com/solutions/cost-savings/index.html 13

Software Source: The MITRE Corporation, Risk Matrix Software Version 2.2 November 1999

14 [WWWdocument], http://infosecuritystore.com/aladdin-etoken-pro.html 15 [WWWdocument], http://storagemojo.com/2008/10/12/building-a-18-exabyte-data-center/ 16 [WWWdocument],http://www.infobahn.com/research-information.htm

14

17 [WWWdocument],http://www.kaycircle.com/mt-What-is-the-Average-Cost-of-a-Firewall-Average-

Firewall-Price

15

IX. Appendix

Figure 1 - Objectives Tree 16

Figure2 - Functional Decomposition

17

Unique Identifier* iVOTE-1.0-001-F iVOTE-1.0-002-F iVOTE-1.0-003-F iVOTE-1.0-004-F iVOTE-1.0-005-F iVOTE-1.0-006-F iVOTE-1.0-007-F iVOTE-1.0-008-F iVOTE-1.0-009-F iVOTE-1.0-010-F iVOTE-1.0-011-F iVOTE-1.0-012-F iVOTE-1.0-013-F iVOTE-1.0-014-F iVOTE-1.0-015-F iVOTE-1.0-016-F iVOTE-1.0-017-F iVOTE-1.0-018-F iVOTE-1.0-001-P iVOTE-1.0-002-P iVOTE-1.0-003-P iVOTE-1.0-004-P iVOTE-1.0-005-P iVOTE-1.0-006-P iVOTE-1.0-007-P iVOTE-1.0-008-P iVOTE-1.0-009-P iVOTE-1.0-010-P iVOTE-1.0-001-In iVOTE-1.0-002-In iVOTE-1.0-001-D iVOTE-1.0-002-D iVOTE-1.0-003-D iVOTE-1.0-001-O iVOTE-1.0-002-O iVOTE-1.0-001-I iVOTE-1.0-002-I iVOTE-1.0-001-C iVOTE-1.0-002-C iVOTE-1.0-003-C iVOTE-1.0-004-C

Requirement The voting system shall allow at least 85% of voters to vote remotely The voting system shall provide voters at least 3 different voting methods The voting system shall report official polling data within 8 hours of the last poll being closed The voting system shall allow at least 85% of voters to remotely register to vote The voting system shall allow 100% of the voters to change their choices before casting their final vote The voting system shall automatically capture and tabulate votes with a rate of at least 100 ms per 100,000 votes The voting system shall protect the voters privacy by having less than one unauthorized disclosure per 1,000,000 voters The voting system shall secure all voting information by having less than one unauthorized disclosure per 1,000,000 voters The voting system shall secure the voting environment by having less than one unauthorized disclosure per 1,000,000 voters The voting system shall allow a user to cast one vote and only one vote per election The voting system shall make official voting results available within 8 hours The voting system shall accept write-in candidates with at least 98% accuracy The voting system shall validate the identity of the voter with at least 99.9% accuracy The voting system shall authenticate the voter based on unique information that only the voter knows with at least 99.9% accuracy The voting system shall verify voter registration with at least 99.5% accuracy The voting system shall store all voting information with an integrity failure rate of less than 1.5% The voting system shall backup all voting information resulting in 100% redundancy of the information The voting system shall authenticate the voter with at least a two-factor authentication method The voting system shall increase voter satisfaction by more than 25% The voting system shall decrease the number of voters that go to a physical polling station by at least 30% The voting system shall reduce manual recounts by at least 75% The voting system shall decrease the amount of time voters spend at polling centers by at least 20% The voting system shall decrease the amount of time voters spend voting by at least 25% The voting system shall decrease the number of absentee ballots by at least 80% The voting system shall increase the ease of use to vote by an average voter rating of at least 7 out of 10 The voting system shall increase efficiency in the voting process by at least 40% The voting system shall handle 50% of the voters casting ballots simultaneously The voting system shall capture votes accurately with at least 99% accuracy The voting system shall accommodate at least 99% of disabled voters The voting system shall provide the user access to real-time candidate, legislative, and help information that requires an average voter rating of at least 8 out of 10 The voting system shall use COTS (Commercial Off-The-Shelf) hardware that has a Total Readiness Level (TRL) of at least 8 The voting system shall use modern technology that has a TRL of at least 7 The voting system shall use no more than 70% of newly developed customized technology The voting system shall reduce the number of polling station facilities by at least 30% The voting system shall reduce the amount of polling station staff by at least 35% The voting system shall maintain a reliability of at least 98.5% The voting system shall maintain all voting information making it available at least 97% of the time when needed The voting system shall operate by the 2016 election and maintain a Schedule Performance Index (SPI) >= .96 for each project milestone The voting system design shall stay within the five million dollar budget and maintain a CPI >= .95 for each project milestone The voting system shall reduce the amount of non-electronic administrative resources (paper, pencils, brochures, etc.) by at least 50% The voting system shall reduce maintenance costs by at least 40%

Type Functional Functional Functional Functional Functional Functional Functional Functional Functional Functional Functional Functional Functional Functional Functional Functional Functional Functional Performance Performance Performance Performance Performance Performance Performance Performance Performance Performance Interface Interface Design Design Design Operational Operational -ilities -ilities Constraint Constraint Constraint Constraint

Figure 3 - Requirements Table 18

Figure 4 - Function Allocation Matrix 19

Figure 5 - Component Hierarchy Diagram

Figure 6 - Reduced Architectures

20

21

Figure 7 - Risk Matrix

22

Figure 8 - Economic Analysis

Figure 9 Architecture Scoring 23

Figure 10 Accord Results from FEC

Figure 11 - Function Component Matrix 24

Figure 12 FEC Top 5 Criteria and Weights

Baseline

Figure 13 - Sensitivity Analysis between Two Top 5 Criteria

Baseline

Figure 14 - Sensitivity Analysis between One Top 5 Criterion and Lowest-weighted Objective

25

Figure 15 - OV-1 High Level Operational Concept Diagram

26

Architecture Project Identification


Assumptions and Constraints: All voters can get access to the Internet; constrained by government funding and
Figure 16 - AV-1 Overview and Summary Information Product

Figure 17 - OV-2 Operational Node Connectivity Diagram 27

Figure 18 - OV-3 Operational Information Exchange Matrix

Figure 19 - OV-5 Operational Activity Model: Casting and Processing a Vote

28

Figure 20 - SV-1 Systems and Interfaces Diagram

Figure 21 - SV-4a Data Flow Diagram for Capture Vote

29

Figure 22 -SV-5b System Functions-to-Capabilities Traceability Matrix

FEC Validation Tool:


Pre-iVOTE

Obj_1: To have voters spend 20% less time at polling centers Obj_2: To be able to allow voters to spend 25% less time voting

Post-iVOTE

Figure 23 - Quality Assurance

30

Figure 24 - iVOTE Implementation Schedule

31

Вам также может понравиться