An Internet Voting System Manager

1
An Internet Voting System Manager
MSE Project - Phase 2

• Yonghua Li
• Kansas State University
• March 28, 2002

2
Give my thanks to

• Dr. Maria Zamfir-Bleyberg
• Dr. William Hsu
• Dr. David Gustafson

3
Presentation Overview

• Project Overview
• Prototype GUI
• Project Design Object Model
• Formal Specification
• Test Plan
• Formal Technical Review (FTR)
• Software Quality Assurance (SQA)
• Summary and Question

4
Project Review Goals

• To design an internet voting system where voters
  can cast ballots through internet
• To test some approaches on internet voting
  system
• Also to improve the integrity and fairness of
  voting

5
Project Review Components

• Emphasis on two components
• IVS manager (IVSM) (sever side)
• Voter (client side)
• Integration with other components, e.g., database

6
Basic Functions of IVSM

• Administrator login setup
• login id administrators ID
• password administrators password
• Database setup
• Candidate list database
• Voter database
• Voting period setup
• Start time
• Stop time

7
Basic Functions of IVSM (Contd)

• Server initializing
• Ballot counting doing statistics on the voting
  ballots.

8
Basic Functions of the Server

• Idling waiting for visit
• Querying getting ballots for the requested
  election title from the database
• Caching storing data and making them available
  to querying
• Uploading sending required blank ballots to
  client.

9
Basic Functions of Client

• Login
• providing voter ID and password
• downloading a blank ballot
• Voting casting the ballot.

10
Prototype GUI (Server Side)
11
Prototype GUI (Client Side)
12
Object Model IVSM
13
Object Model Client
14
Sequence Diagram for Server Side
15
Sequence Diagram in Client Side
16
Formal Specification USE-Class

• model IVSM
• -- Class
• class Administrator
• attributes
• passwordString
• operations
• verifyPassword(passwordString)boolean
• end
• class ConnectionPool
• end
• class ConnManager
• end
• class QueryWrapper
• end

17
Formal Specification USE-association

• association session between
• ConnServer1 role connserver
• ConnClient1 role connclient
• end
• association admin between
• Administrator1 role manager
• IVSM1 role system
• end
• association service between
• Server1 role server
• IVSM1 role system
• end
• association mediator between
• QueryWrapper1 role wrapper
• IVSM1 role system
• end

18
Formal Specification USE-Constraints

• context AdministratorVerifyPassword(psword
  String) boolean
• pre passwordNotNullpsword.isdefined()
• post resultPost
• result self.password.equals(psword)
• context IVSM
• -- Over time must be greater than Start time
• inv overtimeGreaterthanstart
• self.startTime lt self.overTime
• context Server
• -- system is ready before it can accept the
  request
• inv systemready
• self.connserver.isdefined() implies
  self.system.isdefined()
• context ConnServer
• -- every ConnServer must have its own
  ConnClient
• inv connServerClientPair
• ConnServer.allInstances-gtforAll(c1,c2ConnServ
  erc1ltgtc2 implies (c1.connclientltgtc2.connclient))

19
Test Plan

• Unit Testing
• each class is tested separately. Focus on major
  functions in each class
• Integration Testing
• tests the program structure, the program is built
  with unit-tested modules.
• System Testing Performance Testing
• Stress testing
• Boundary testing

20
Test Plan Test Case

• Stress Testing
• - From the same machine, keep sending a number
  of connecting requests to the server to test the
  performance
• Boundary testing
• - Sending the server some special characters,
  eg !_at_()_-\
• Authentic testing
• - testing voter id, password, registering code

21
Test Plan Test Case (Contd)

• Error Handling Testing
• - The error handling testing case will test if
  the server and client will show the right
  feedback
• Log Handling Testing
• - This type of testing case will check if the
  log system will works well when the system run.
• Voting Period Testing
• - Voting period testing will check if the
  server will accept connection in the right time.

22
Prototype Test Suite GUI
23
Formal Technical Review (FTR)

• Software Formal Inspection Process Standard
  NASA-SYD-2202-93
• Ensure consistency between previously approved
  documents of phase I and the new design concepts
  resulting from documents of phase II
• In this project, the system design will be
  subjected to the FTR. A formal checklist will be
  developed and used to inspect the document

24
FTR Checklist

• Check list
• Completeness Modifiability
• Consistence Tracebility
• Correctness Understandability
• Feasibility Maintainability
• Verifiability Testability

25
Software Quality Assurance Plan (SQA)

• IEEE standard Std 730-1989
• Software Quality Assurance Plan documents a plan,
  which assures the quality of the software during
  the whole life cycle of the software.
• Including Purpose, Reference, Management,
  Documentation, Standards Practices Conventions
  and Metrics, Review and Audit, Tools Techniques
  and Methodologies, Code Control, Training, Risk
  Analysis

26
Phase III Implementation

• User Manual
• Source Code
• Formal Technical Review
• Testing Reliability Evaluation
• Project Evaluation

27
Summary

• Project Overview
• Project Design Object Model
• Formal Specification
• Test Plan
• Formal Technical Review (FTR)
• Software Quality Assurance (SQA)
• URL http//www.cis.ksu.edu/yli3568/mse/mse.ht
  ml

28
Thank!