Part One
Phase I: Project Requirement
Section 1
Project Overview
1.1 Purpose
Elections are one of the most critical functions of democracy. Not only do they provide for the
orderly transfer of power, but they also cement citizens’ trust and confidence in government when
they operate as expected. The events that transpired in Florida during the 2000 presidential
election focused national attention on how elections are administered.
The subject of voting systems has taken center stage, and is under intense scrutiny by
policymakers, interest groups, and the American people in general. Over the last year, there has
been strong interest in voting over the Internet as a way to make voting more convenient and
precise. In addition to adding convenience and precision, it is believed that Internet voting may
reverse the historical and downward trend of voter turnout in the United States.
As an MSE project, this project will define the scope of the Internet voting system for
Kansas State elections from the technical perspectives and address the technical
challenges. Within this scope, a model of the Internet voting system will be set up, and
the corresponding technical and design requirements will be analyzed and specified in a
formal language; approaches and methodologies to the addressed challenges will be
proposed and implemented. Naturally, all the requirements have to be met when the
model is implemented. The topics addressed in this project, while all related to Internet
voting, are also relevant to discussions about other electronic voting systems.
1.2 Constraints
Internet voting is seen as a logical extension of Internet applications in commerce and
government. In the wake of the 2000 election, Internet systems are among those being considered
to replace older, less reliable systems. Election systems, however, must meet standards with
regard to security, secrecy, equity, and many other criteria, making Internet voting much more
1
challenging than most electronic commerce or electronic government applications. The contested
2000 Presidential election highlighted awareness of the critical importance of ensuring
confidence in the integrity and fairness of election systems.
Technological threats to the security and integrity of Internet ballots are significant. The
possibility of "Virus" and "Trojan Horse" software attacks on home and office computers
used for voting is very real and, although they are preventable, could result in a number
of problems ranging from a denial of service to the submission of electronically altered
ballots.
One of the most difficult tasks for an Internet voting system is the authentication of
voters. To ensure that every voter has the opportunity to cast a ballot and no voter is able
to vote more than one time, this task force believes election officials should initially test
Internet Voting technology through the use of Internet Voting machines that are under the
direct control of election personnel in traditional polling places.
Eventually, election officials can transition toward allowing voters to cast ballots at
publicly accessible county-controlled kiosks or computers and, in the future, provide the
option of remote computer voting from any computer with Internet access.
The democratic process warrants an extremely high level of security, but the security
measures cannot be so cumbersome to voters that the new process would prevent
participation. An appropriate balance between security, accessibility and ease of use must
be achieved before Internet voting systems should be deployed.
1.3 Directions
Despite these challenges, it is technologically possible to utilize the Internet to develop a
method of voting. At this time, it would not be legally and practically to develop a
comprehensive remote Internet voting system that would completely replace the current
paper process used for voter registration, voting, and the collection of initiative,
referendum and recall petition signatures.
To achieve the goal of providing voters with the opportunity to cast their ballots at any
time from any place via the Internet, this task force believes that the elections process
would be best served by a strategy of evolutionary rather than revolutionary change.
2
As with most computer systems, increased security and higher levels of privacy can be
provided by increasing the complexity and the burden on the user of the system. The
success or failure of Internet voting in the near-term may well depend on the ability of
computer programmers and election officials to design a system where the burden of the
additional duties placed on voters does not outweigh the benefits derived from the
increased flexibility provided by the Internet voting system.
1.4 Reference:
1.
http://www.acm.org/crossroads/xrds2-4/voting.html
2.
http://www.calvoter.org/
3.
http://www.cpsr.org/conferences/cfp93/shamos.html
4.
http://www.netvoting.org/
3
Section 2
Software Requirement Specification
2.1 Introduction
This is a software requirement specification (SRS) for Internet Voting Management
System which includes components IVS Manager, Database Connection Manager, Query
Processing, Server, Mail Sender and Client component in Internet Voting project. It is
used to specify the requirement for the initial implementation of the system and up to
date in the future.
The audience of this document is voting software designer,
implementer and tester, voting system manager, and voter.
2.1.1 Purpose
The purpose of this software requirement specification is to define the requirements that
will enable the development of the IVS Manager, Database Connection Manager, Query
processing and Server - and Client components. This specification can be updated in the
future to incorporate a new version of any of the components.
2.1.2 Scope
There will be two functional components developed using this SRS. The first will be the
IVS Manager. The essence of this component is to keep safe the information of the valid
voters, candidates and ballots. The IVS manager functional component includes the
server, query processing, database connection manager and mail sender. The IVS
manager accepts requests from clients by server, distributes query and converts the query
to executable statement by query processing; updates the database and gets the result
from database by connection manager; retrieves the data to server, then send back data to
client. The mail sender will send the voter password requests to voters’ email account.
The goal of IVS manager is to provide and store accurate information about the voters,
candidates, and the ballots. However, none of the other voters except the voter himself is
allowed to access the ballot; none of the voters except the authorized agency is allowed to
access the statistical result of the election which may be subject to further validation or
4
inspection. By limiting the access to ballot exclusively to the one who casts it, the
personal privacy concerning political opinion is protected.
The second component will be the Client. This component will provide the voter with
information that is to be authenticated and the ballot for the voter to cast. These interfaces
are open for the voter to input and will return authentication information for the voter to
confirm the input and the cast. A voter does not have the right to modify his personal
information or the candidate information under any circumstances. However, addition of
new candidates may be allowed. Further plans are for providing cross-reference or search
tools, etc.
2.1.3 Definitions, acronyms, and abbreviations

SLOC – Source Line of Code.

Connection Pool Manager – a program component providing the connection
to query processing with database

Query processing – a program component providing the communication
server and database.

Server – a program component providing services to remote voters.

Mail Sender – a program component providing services to send email to
voters

Client – a program component providing login and online ballot.

IEEE – Institute of Electrical and Electronics Engineers

SRS – Software Requirement Specification
2.1.4 References

IEEE Std-830, IEEE New York, 1993.

Course slides from Dr. David A. Gustafson,
www.cis.ksu.edu/~gustafson/cis748.

Emphasizing Software Quality in Undergraduate Programming Laboratories,
Frontiers in Education conference in 1998.

Pressman, Software Engineering: A Practitioner’s Approach. Fourth Edition,
McGraw Hill 1997.
5

Software Requirement Engineering and Management Process
http://utexas.edu/coe/sqi/seminar/SWRep.html
2.2 Overall Description
This section involves the description of the software being developed and the
corresponding requirements. The product will be compared with other similar products.
A description of any constraint that the product optionally has will be provided. This
project will implement part of following features due to time constraint of MSE project.
Specifically,
• Approaches to meeting the security, secrecy, scalability, and convenience requirements
of elections. Particular emphasis should be placed on the development of secure voting
platforms, and secure network architectures;
• Development of methods to reduce the risk of insider fraud;
• Development of reliable poll site and kiosk Internet voting systems that are not
vulnerable to any single point of failure and cannot lose votes;
• Development of new procedures for continuous testing and certification of election
systems, as well as test methods for election systems;
• The effects of potential open architecture and open source code requirements on
innovation, profitability, and public confidence;
• Human factors design for electronic voting, including the development of appropriate
guidelines for the design of human interfaces and electronic ballots, as well as approaches
to addressing the needs of the disabled;
• Protocols for preventing vote selling and reducing coercion;
• The economics of voting systems, including comparative analyses of alternative voting
systems;
• The effects of Internet voting on participation in elections, both in general and with
regard to various demographic groups—especially those with less access to or facility
with computers;
• The effects of Internet voting on elections, the public’s confidence in the electoral
process, and on deliberative and representative democracy;
• The implications of Internet voting for political campaigns;
6
• The appropriate role of the federal government in state-administered elections;
• Legal issues associated with and the applicability of existing statutes to Internet voting,
including jurisdiction, vote fraud, liability for system failures, international law
enforcement, and electioneering;
• Electronic authentication for kiosk and remote voting; and
• Experimentation, modeling, and simulation of election systems.
2.2.1 Product perspective
The IVS Manager, Client components will be dependent on the main interface of the IVS.
They are also interleaved with other components for message passing.
The block
diagram for the total system in Figure 1 is shown on next page to represent the
relationship among the components.
MailSender
Query
Processing
Query Processing
ConClient
Database
Connection
Manager
Server
Query Processing
ConClient
Server
Client
DBM
Figure 1: IVS System sketch
2.2.2 Product functions
The IVS manager component will adopt some basic functions. These functions are:
7

set up administrator login – define the administrator ID and password;

set up database – define candidates data and voters data;

set up voting period – define voter starting time and stop time;

initialize the server – set up the connection manager and cache manager;

run server – startup the server;

count the ballots – get the voting result.
The user diagram:
administrator
enter passwd
run server
setup database
show result
login
schedule voting
initialize pool
IVSM
Figure 2: User Diagram of IVSM
The Server will adopt some basic functions. These functions are:

accept – wait for any visiting.

query – get the data under the entered topic.

cache – store the data which will be available to next query

send– send the required data to the client.
The user diagram:
8
accept
query
server
IVSM
cache
send
Figure 3: User Diagram of Server
The client component will adopt some basic functions. These functions are:

login – confirm ID and cost a ballot.

vote – vote the candidate.
The User Diagram
login
voter
client
vote
Figure 4: User Diagram of Client
2.2.3 User characteristics
The components will be produced as a project whose primary user will be citizens and
official voting administration in Kansas State. For such a case, the software will be
9
written in a manner in which it is assumed that the voters have no knowledge about the
software. The official voting administration who manager the voting should have basic
knowledge to launch the server. The user also must have the ability to interact with a
computer, using the keyboard and/or mouse.
2.2.4 Constraints
Java JDK 1.1.7 above, Internet browser, such as Netscape 4.0 or above, or Internet
Explore 4.0 or above must be installed in order to use this product. The component codes
must be compiled together with other components in order to integrate them together.
2.2.5 Assumptions and dependencies
It is assumed that the administrator can maintain the system properly and the database
will be set up properly. The voters ID and Code will be distributed in a private way. This
system will not handle the validity of citizen voting right. It is also assumed that the user
has background in the basic use of the GUI programs and the basic operation of the
computer.
2.2.6 Apportioning of requirements
The proper setup of the dataset and the structure of the database will affect the total
structure of the IVS manager components.
2.3 Specific Requirements
2.3.1 External interface requirements
There are four categories in this section. They are the interfaces of the user, hardware,
software, and communication respectively.
2.3.1.1 User interfaces
A Graphic User Interface (GUI) with all menus, toolbars, dialog box, and buttons should
be user friendly so that the user can run the program more efficiently.
10
2.3.1.2 Hardware interfaces
This project should be platform independent since Java is used as the programming
language.
2.3.1.3 Software interfaces
All the software interfaces among the components and classes are adapted from Java JDK
library, Java mail API, Oracle Database Driver.
2.3.1.4 Communication interfaces
The communication interfaces will be built using Java JDK library either appearing as
GUI or hiding into the system.
2.3.2 Classes / Objects
For the IVS Manager:

ADMINISTRATORS– will store the administrator’s name and password.

CONNECTION POOL – store the connection to the database for reusing of
next query.

CONNECTION MANAGER – will manager the connection which server
requests.

Mail Sender – will send emails to voters for their requests and result.

QUERY WRAPER – will handle information query between database and
server.

IVS Manager – will have a GUI and manager all other object.

SERVER – will accept the voter logging on and kick out the idle logging and
dead connection.

Ballot – record the candidates of this election

Candidate – candidate data placeholder.

Message – send between server and client
11
Administrator
MailSender
ConnectionPool
Ticker
IVSM
Server
ConnServer
ConnManager
Trigger
Ballot
QueryWra
pper
Candidate
Figure 5: Class Diagram of IVS Manager Component
For the Client:

CONCLIENT – connect to the server and communicate with it.

BALLOT – display the ballot.

VCLIENT – will manager data communication.

TIMEOUT THREAD – will restore the system to init status.
12
Ballot
VClient
ConnClient
TimeroutT
hread
Candidate
Figure 6 Class Diagram of Client Component
2.3.3 Performance requirements
This project is not processor intensive. The tool would not have any large memory
requirements and would not cause overloading of the system resources. No special
hardware and software consideration needs to be taken into account.
2.3.4 Design constraints
The components in this project come from the total IVS. All other components should be
integrated properly in order to make the total system working well.
2.3.5 Software system attributes
The system will provide all the integrated interfaces among all the components for
message passing. Also the system will verify the voter id and password when the voter
first logs in the system.
2.3.6 Other requirements
13
More important, the instructor will play an important role in the total system. She has
done many researches in software engineering and database management and is familiar
with the standard techniques of the software engineering. She has also supervised many
master projects in the area of software engineering, database management, distributed
system.
2.4 References

IEEE Standard 830, IEEE New York, 1993.

Pressman, Software Engineering: A Practitioner’s Approach. Fourth
Edition, McGraw Hill 1997.

Software
Requirements
Engineering
and
Management
Process
http://utexas.edu/coe/sqi/seminar/SWRep.html

John L. Connell, Object-Oriented Rapid Prototyping. Prentice Hall 1995

James Noble, Prototype-Based Programming. Springer 1999
14
Section 3
Cost Estimate
3.1 Introduction
In this project, Function Point Analysis and COCOMO model are used for estimating the
size and cost of developing the tool. Function point analysis is used to estimate the
source lines of code. The IVS for java code is calculated after the function points are
calculated. COCOMO model is used to estimate the cost estimation of the project.
Number of man-months is calculated from the IVS using COCOMOII calculator. And
also a Gantt chart is plotted from the available man-months.
3.2 Function Points Analysis
The function point model includes three major steps for the cost estimation. First,
calculate the unadjusted function points (UFP) by counting the identical types, input,
output, file, inquiry, and interface. Second, calculate the adjusted function point (AFP)
based on the unadjusted function point and product complexity adjustment (PC). Third,
calculate the source lines of code (SLOC) based on the adjusted function point and
language factor (LF).
3.2.1 Calculate UFP
Calculate for the unadjusted function points (UFP) through classifying and counting
different types. There are five file types. They are external input type, external output
type, logical internal file type, external interface, and external inquiry type. External
input types refer to each user input that provides distinct application-oriented data to the
software.
External output types refer to the user output that provides application-oriented
information to the user. Logical internal file type refers to data stored for an application,
as logically viewed by the user.
External interface refers to all machine readable
interfaces (e.g. data files on tape or disk) that are used to transmit information to another
system. External inquiry refers to a non-line input that results in the generation of some
immediate software response in the form of an on-line output.
15
According to the definitions above, in this project, the five file types can be counted as in
Table 1 through Table 5. The total calculated UFP is shown in bold in Table 6.
Table 1: Function points for the input type
Function Points
Simple
2Input password
Average
Complex
3
Input ballot
6
Command to execute statistics
3
Command to set up database
7
Command to modify connection #
4
Command to set up the deadline
4
Table 2: Function points for the output type
Function Points
Simple
Average
Complex
Display ballot
7
Display the confirm message
4
Display the voting result
Display the error exception
5
4
Store the application data
7
Table 3: Function points for the file type
Function Points
Simple
Average
Voter Data
Complex
15
Records for log
10
Candidate Data
10
16
Table 4: Function points for the inquiry type
Function Points
Simple
Average
Complex
Inquiry to confirm voter ID
7
Inquiry to get ballot
7
Table 5: Function points for the interface type
Function Points
Simple
Average
Complex
Server to local machine
10
Server to database server
10
Remote
10
Table 6: Total function points for all the types
Function Points
Total
Simple
Average
Complex
Value Amount
Value Amount
Value Amount
3
3
4
1
6
1
19
Outputs 4
2
5
1
7
2
27
10
2
15
1
35
Inquiries
7
2
14
Interfaces
10
2
20
Inputs
Files
Total
Function Points
115
3.2.2 Calculation for the adjust for the processing complexity (PC)
To decide the processing complexity, several factors have to be taken into account, e.g.,
backup and recovery, code design for reuse, etc. All the factors and their estimated
values in this project are shown in Table 7. The Processing Complexity is shown in
BOLD letter and the calculation formula is shown in the next section.
17
Table 7: Summary of function point influence factors
Complexity Weighting Factor
Value
Backup and recovery
1
Data communications
5
Distributed processing
5
Performance critical
5
Existing operating environment
4
On-line data entry
3
Input transaction over multiple screens
0
Master files updated on-line
3
Information domain values complex
5
Internal processing complex
4
Code designed for reuse
5
Conversion/installation in design
3
Multiple installations
3
Application designed for change
5
Sum of complexity weighting factors
48
Complexity adjustment factor
1.13
3.2.3 Calculation for the source lines of code (SLOC) and the formulas used

Total Unadjusted Function Points (UFP)

Product Complexity Adjustment (PC) = 0.65 + (0.01 *48) = 1.13

Total Adjusted Function Points (FP) = UFP * PC = 122

Language Factor (LF) for Java assumed as = 38

Source Lines of Code (SLOC) = FP * LF = 5100
= 115
18
3.3 Cost Estimation By COCOMO Model
To simplify the calculation, we can refer to the Table 8 for selecting the correct formula
for this project. This project is in the type of application program, therefore we can select
the associated formula to calculate the PM and TDEV.
Table 8: Summary of formulas for different programs
TDEV
Programmer
Development Time
Productivity
(Month)
PM = 2.4*(KDSI)
Application Programs
1.05
TDEV = 2.5* (PM) 0.38
PM = 3.0*(KDSI)
Utility Programs
1.12
TDEV = 2.5*(PM) 0.35
PM = 3.6*(KDSI)
System Programs
1.20
TDEV = 2.5*(PM) 0.32
KDSI = 5.1 KLOC
PM = 2.4*(KDSI) 1.05 = 13 person-month
TDEV = 2.5 * (PM) 0.38 = 6.7 month
3.4 References

Software Engineering: A practitioner’s approach by Roger S. Pressman

Lecture Notes from Dr. David A. Gustafson, http : //www.cis.ksu.edu/~dag
19
Section 4. Project Plan
This project plan includes the total schedule for the project at all the three phases.
4.1 Phase One: Requirements
August 23, 2001 to November 16, 2001
1
Literature Review: August 23, 2001 to August 27, 2001
Learn the basic concepts and understand the software requirement, specification
design and testing techniques; read literature on electronic voting systems.
2
Overview: August 28, 2001 to September 12, 2001
Write project overview, including the purpose, background, constraints, and
requirements.
3
Project Plan: September 8, 2001 to October 14, 2001
Set up milestones of the project; draw the corresponding Gantt chart.
4
Software Requirement Specification: September 14, 2001 to October 8, 2001
Document overall requirements of the project; draw system model, scenarios.
5
Cost estimation: September 3, 2001 to September 7, 2001
Document the estimation of the size, cost and effort required for the project,.
6
MSE presentation (phase I): October 15, 2001
4.2 Phase Two: Design
October 16, 2001 to March 28, 2002
1
Design: October 16, 2001 to November 25, 2001
Draw detailed object models, sequence diagrams.
2
Formal Requirement Specification: November 26, 2001 to December 24, 2001
Specify the major functions of the project using Z, or UML /OCL or Alloy
3
Software Quality Assurance Plan: December 25, 2001 to February 10, 2002
Develop a software quality assurance plan.
4
Test Plan: February 11, 2002 to February 25, 2002
Develop a test plan.
5
Formal Technical Inspection: February 26, 2002 to March 8, 2002
20
Develop a formal checklist and a formal report.
6
MSE presentation (phase II): March 28, 2002
4.3 Phase Three: Implementation and Testing
March 29, 2002 - August 10, 2002
1
Source Code: March 29, 2002 to May 30, 2002
Write and submit well-documented source code.
2
Testing: May 1, 2002 to June 15 , 2002
Test the software according to the criterion of the test plan. Write the test report
including the testing cases, failures etc.
3
Project Evaluation: June 16, 2002 to July 1, 2002
Review the methodologies and quality of the project.
4
User Manual: July 2, 2002 to July 26, 2002
Compile a user manual that includes common usage of the software.
5
Documentation: July 27, 2001 to August 2, 2002
Edit and finish up the final version of the software with cited references.
6
Final MSE presentation (Phase III): August 12, 2002
21
4.4 Gantt Chart
Figure 7: Gantt Chart of Project Plan
22
Section 5
Time Log for Phase One
Date
Start
Stop
Time
Activity
Comment
8/2/01
3:00
3:30
0.5 hr
Meet with Dr.
Initial meeting
Bleyberg
8/4/01
9:00
11:00
2 hrs
Read materials
Preparation
8/9/01
3:00
3:30
0.5 hrs
Meet with Dr.
Discuss the
Bleyberg
project
8/11/01
2:00
3:00
1 hrs
Read materials
Choose topic
8/16/01
3:00
4:30
1.5 hrs
Meet with Dr.
Choose topic
Bleyberg
8/18/01
2:00
4:00
2 hrs
Read material
Choose project
8/23/01
3:00
3:30
0.5 hrs
Meet with Dr.
Discuss project
Bleyberg
8/25/01
2:00
6:00
4 hrs
Read material
Prepare for the
project
8/26/01
2:00
6:00
4 hrs
Read material
Prepare for the
project
8/30/01
3:00
3:30
0.5 hr
Meet with Dr.
Discuss the
Bleyburg
project
8/31/01
2:00
5:00
3 hrs
Design
9/1/01
1:00
6:00
5 hrs
Read MSE
project
9/2/01
2:00
4:00
2 hrs
Read MSE
project
9/3/01
8:00
11:00
3 hrs
Software
Requirement
Specification
(SRS)
23
9/4/01
1:00
4:00
3 hrs
SRS
9/5/01
2:00
6:00
4 hrs
Modify SRS
9/6/01
2:00
5:00
3 hrs
SRS
9/8/01
3:00
6:00
3 hrs
System diagram
9/9/01
9:00
11:00
2 hrs
More diagram
OK
9/10/01
2:00
6:00
4 hrs
SRS
Add new content
9/11/01
2:00
4:30
2.5 hrs
SRS
9/12/01
8:00
12:00
4 hrs
SRS
Overview
9/13/01
3:00
3:30
0.5 hr
Meet with Dr.
Discuss SRS
Add new content
Bleyberg
9/15/01
2:00
6:00
4 hrs
SRS
9/18/01
2:00
3:00
1 hr
Review
9/20/01
2:00
6:00
4 hrs
Project plan
9/22/01
9:30
12:00
2.5 hrs
Project plan
9/25/01
2:00
6:00
4 hrs
Cost estimate
9/28/01
2:00
5:30
3.5 hrs
Cost estimate
9/30/01
8:00
9:00
1 hr
Cost estimate
10/5/01
2:00
5:00
3 hrs
Review the
OK
OK
OK
document
10/8/01
2:00
5:00
3 hrs
Prepare for
Make slides
presentation I
10/9/01
11:00
12:00
1 hr
Prepare for
presentation
10/10/01
2:00
6:00
4 hrs
Prepare for
presentation
10/11/01
10/15/01
3:00
2:30
3:30
3:30
0.5 hr
1.0 hrs
Meet with Dr.
Discuss
Bleyberg
presentation
Presentation
OK
24
Part Two
Phase II: Project Design
Section 6
Software Quality Assurance Plan
An important part of achieving quality is to plan for quality, that is, to plan those
activities that will help to achieve quality. The software quality assurance (SQA) plan is
to provide a guideline for activities that will ensure the quality of software. I use the
IEEE standard Std 730-1989 for developing the Software Quality Assurance Plan (SQAP)
of my project.
6.1 Purpose
This SQA plan covers the software requirement, design, and implementation phases
of the development of Internet Voting System Manager (IVSM). This plan does not
cover the Cryptix and the Cryptix software that will be used by my project.
This SQAP provides a foundation for managing the IVSM software quality assurance
activities, and is based on project activities and work products as documented in the
project plan. This SQAP plan:

Identifies the SQA responsibilities of the project developer and the SQA
consultant

Defines how to review and audit the development of IVSM system.

Lists the activities, processes, and work products that the SQA consultant will
review and audit

Identifies the SQA work products
6.2 References

Software Engineering, Roger S. Pressman

Lecture Notes, CIS541 Software Engineering II, Dr. David Gustafson, Spring
2001.
25

Lecture Notes, CIS740 Advanced Software Engineering, Dr. David Gustafson,
Fall 1999.

Lecture Notes, CIS748 Software Management, Dr. David Gustafson, Summer
1998.

IEEE Standard for Software Test Documentation, IEEE Std 829-1983

IEEE Standard for Software Quality Assurance Plans, ANSI/IEEE Std 7301989

IEEE Guide for Software Quality Assurance Planning, DRAFT, P730.2/D4
6.3 Management
Organization:

The committee consists of Dr. Maria Zamfir-Bleyberg, Dr. William Hsu and
Dr. Gustafson

Major Professor: Dr. Maria Zamfir-Bleyberg

Developer: MSE student Yonghua Li.

Develop the requirement specification, cost estimation for distributed multiple
Tasks:
sequence alignment system.

Develop the design plan and test plan for distributed multiple sequence
alignment system.

Implement and test the distributed multiple sequence alignment system.
Deliver the final version along with the documentation.

On completion of the analysis, design and testing phases, the developer gives
a formal presentation to the committee. The committee reviews the work
performed by the developer and provides feedback.
Responsibilities

The developer will perform all software development tasks for internet voting
system manager under the supervision of the major professor.
26

The committee will review the work performed by the developer and provide
feedback and advice.
6.4 Documentation
The following documents will be provided at the end of each phase.
Phase 1: Software Requirement

Project Overview

System Diagram

Project Gantt Chart Timeline

Cost Analysis

System Requirements Specification (SRS)

Time Log
Phase 2: Software Design

Software Quality Assurance Plan (SQAP)

Object Model

Formal Specifications

Test Plan

Formal Technical Review (checklist)

Time Log
Phase 3: Software Implementation

Source Code

User Manual

Testing and Reliable Evaluation

Project Evaluation

Final Report

Time Log
27
Appendix:

Source Code
6.5 Standard, Practices, Conventions, and Metrics
Standards
Document Standards – MSE portfolio
Coding Standards - Java 1.2
Coding Documents - Java Documentation
Test Standards - IEEE Standard for Software Test
Documentation
Metrics
LOC - line of code is used to measure the size of the software
6.6 Review and Audits
There will be three formal presentations prepared by the developer and evaluated
by the committee at the end of each phase (Requirement, Design, and Implementation).
In the preliminary design review at the end of design phase, the technique adequacy of
top-level design will be evaluated. All documents pertaining to one specific phase will be
presented at the review. The evaluation is subject to be approved by the committee
members. All deficiencies or inconsistency must be rectified by the developer and
resubmitted to the committee members for approval.
6.7 Test, Tools, Techniques, and Methodologies
A Software Test Plan (STP) will be written to satisfy the software requirements. The
plan will provide management and the testing function with an overview of the test
activities, schedules and resources required to perform testing. The plan will describe
how the testing specifications found in the following sections will be implemented.
28
Unit Test:
All code will be unit tested to ensure that the individual unit (class) performs the
required functions and outputs the proper results and data.
Integration Test:
There are two levels of integration testing. One level is the process of testing a
software capability. A second level of integration testing occurs when sufficient
modules have been integrated to demonstrate a scenario.
Java Virtual Machine will be used for this project during the implementation. For
measuring the size of the project, the function points analysis and COCOMO II were
used. The design of the project is object oriented. Rational-Rose was used for making
object diagram.
I will use the Cryptix framework to encrypt the communication between the
server and client.
6.8 Problem Reporting and Corrective Action
During the whole development process of the project, the developer can report the
problems to his major professor or his committee member. The major professor or
committee member gives their suggestions. In the three presentations, the major
professor or committee member also can ask questions and give their advice. After
presentation, the developer corrects his mistakes.
6.9 Code control
N/A
6.10 Media control
N/A
29
6.11 Supplier control
The source code of the Cryptix and the Cryptix frameworks are from their
developer’s website. Assume that all these source code are reliable.
6.12 Records
All the documents of each phase will be posted on my personal website in the CIS
department. At the end of the phase III, the thesis composed of all the documents of the
project will be committed to the CIS department.
6.13 Training
CIS540 Software Engineering Project
CIS740 Software Engineering
CIS748 Software Management
6.14 Risk Management
The most important risk is that the Cryptix framework is from third party. We do not
know how well it works. I plan to run this system with boundary testing cases first,
then apply it to general running.
30
Section 7
Formal Specification
------------------------------------------------------------------------------------------------------------ Beginning of the formal specification
-- This is the OCL(USE) specification of internet voting manager system.
-- This is the result of validating the UML model and OCL constrains by using USE tool
--------------------------------------------------------------------------------------- ----------------------compiling specification revised_mse.use...
---done.
---Model IVSM (11 classes, 14 associations, 13 invariants, 9 operations)
------------------------------------------------------------------------------------------------------------
model IVSM
enum TYPE
{SHUTDOWN,DISCONNECT,INIT,PWDREQUEST,WAITCONFIRM,CONFIRM,CO
NFIRMFAIL,BALLOT,WAITBALLOT,VOTEDBALLOT,WARNING,MULTILOG,T
HANK}
-- classes
-- class DB
class DB
attributes
url:String
end
-- class voter
class Voter
attributes
31
id:Integer
name:String
pwd:String
voted:Boolean
operation
vote()
end
-- class candidate
class Candidate
attributes
name:String
comm:String
votes:Integer
voted:Boolean
operation
voted()
end
-- class committee
class Committee
attributes
name:String
position:Integer
end
-- class administrator
class Administrator
attributes
id:String
32
password:String
operations
verifyPassword(password:String):Boolean
end
-- class Ballot
class Ballot
end
-- class IVSM
class IVSM
attributes
startTime:Integer
overTime:Integer
end
-- class server
class Server
attributes
MaxInactivity:Integer
currentTime:Integer
operations
run()
tick()
end
-- class ConClient: the client who is logging on
-- In this class, the boolean variable inCritical to model the conclient to update the DB
class ConClient
attributes
33
key:String
status:TYPE
inactivity:Integer
inCritical:Boolean
operations
enterCritical()
exitCritical()
run()
end
-- class Voting Client
class VClient
attributes
id:Integer
status:TYPE
operations
run()
end
-- class Message
class Message
attributes
type:TYPE
end
-- associations
-- the association vTable model the Dababase table voters
association vTable between
34
DB[1] role db
Voter[*] role voters
-- the association vTable model the Dababase table candidates
associaiton cTable between
DB[1] role db
Candidate[*] role candidates
-- the association vTable model the Dababase table committees
association pTable between
DB[1] role db
Committee[*] role committee
association dbConnection between
DB[1] role db
ConClient[*] role client
association candidancy between
Ballot[1..*] role ballot
Candidate[1..*] role cands
association writein between
Ballot[1..*] role ballot
Candidate[*] role writein
association oneToOneLinkage
DB[1] role db
IVMS[1] role manager
association acceptconnection between
Server[1] role server
35
ConClient[*] role con
-- a voter may have many sessions
association session between
Voter[1] role voter
VClient[*] role logon
end
association logon between
VClient[1] role patron
ConClient[1] role receiper
association admin between
Administrator[1] role manager
IVSM[1] role system
end
association service between
Server[1] role server
IVSM[1] role system
end
association belongsTo between
Candidate[1..*] role cands
Committee[1] role com
end
association castballot between
Ballot[1] role ballot
VClient[1] role voter
36
--constraints
constraints
context DB
-- the system only maintain one db
inv oneDB
DB.allInstances->size() = 1
context Administrator::VerifyPassword(psword : String) : Boolean
pre:self.password.isdefined
post:result = self.password.equals(psword)
context Voter
-- Voter ID can't be same
inv nosamevoterid:
Voter.allInstances->forAll(v1,v2:Voter|v1<>v2 implies (v1.id <> v2.id));
-- Every vote can only vote one time
context Voter::vote()
-- the voter did not vote yet
pre:self.voted = false
-- the voter's current session should be in critical section
pre:self.logon.receiper->exist(c:ConClient|c.inCritical=true and
c.patron.voter=self)
-- the voter's current session should be in votedballot status
37
pre:self.logon.receiper->exists(c:ConClient|c.status=TYPE.VOTEDBALLOT and
c.patron.voter=self)
-- the voter has voted.
post:self.voted = true
context Candidate
-- Candidate name can't be same in a committee
inv nosamecandname:
Candidate.allInstances->forAll(c1,c2:Candidate|(c1.name.equals(c2.name)) implies
not(c1.com.name.equals(c2.com.name)))
-- ballot should contain all the candidates and only those candidates
inv
Ballot.allInstances->forAll(b|b.cands.includesAll(Candidate.allInstances and b.cands>size()=Candidate.allInstances->size())) and
Candidate.allInstances.includesAll(Ballot.allInstances.cands)
context Candidate::voted()
-- the ballot's holder should be in critical section
pre:self.ballot.voter.receiper->exist(c:ConClient|c.inCritical=true and
c.status = TYPE.VOTEDBALLOT and
c.patron.ballot.cands.includes(self))
post:self.votes = self.votes@pre+1
context Committee
-- Committee name can't be same
inv nosamecommittee:
Committee.allInstances->forAll(c1,c2:Committee|c1<>c2 implies
not(c1.name.equals(c2.name)))
38
-- Each committee should have at least candidates of number of the positions
inv numOfCandidates
Committee.allInstances->forAll(c:Committee|not(c.can->size() < c.position) and
c.can.forAll(cand:Candidate|cand.comm.equals(c.name)))
context ConClient
-- only one conclient can be in critical section
inv oneconclientincritical
ConClient.allInstances->forAll(c1,c2:ConClient|(c1<>c2 and c1.inCritical=true)
implies c2.incritical = false
context ConClient::enterCritical()
-- no others are in critical section and it is in votedballot status
pre:ConClient.allInstances->forAll(c:ConClient|c.inCritical = false) and
self.status=TYPE.VOTEDBALLOT
-- it is safe to enter the critical section
post:self.inCritical=true
context ConClient::exitCritical()
-- done in critical, so exit
pre:self.inCritical=true
-- other may enter the critical section
post:self.inCritical=false
context IVSM
-- Over time must be greater than Start time
inv overtimeGreaterthanstart:
self.startTime < self.overTime
39
context Server::run()
-- Only after the start time does server begin
pre:self.system.startTime < self.currentTime
-- after the over time less than current time
post:self.system.overTime < self.currentTime
context Server::tick()
-- every time kick those inavtive conclient
post:self.con->forAll(c:ConClient|c.inactivity>self.MaxInactivity implies c.status =
TYPE.SHUTDOWN)
context Server
-- system is ready before it can accept the request
inv systemready:
self.connserver.isdefined() implies self.system.isdefined()
context VClient::run()
-- in starting status
pre:self.status = TYPE.INIT
-- in ending status
post:self.status = TYPE.SHUTDOWN
context Ballot
-- people voted in a ballot can't excess each committee positions
inv
Committee.allInstances->forAll(c:Committee|(self.cands->select(voted=true and
comm.equals(c.name)
)->size() +
self.writein->select(voted=true and
40
comm.equals(c.name)
)->size()) <= c.position
)
-- writein people can't have same name as in the same committee of a ballot
inv
Committee.allInstances->forAll(c:Committee|self.writein->select(
comm.equals(c.name)
)->forAll(
w:Candidate|
not self.cands->select(comm.equals(c.name))->forAll(
can:Candidate|can.name.equals(w.name)
)
)
)
-- writein can't have the same name in one committee of a ballot
inv
Committee.allInstances->forAll(c:Committee|self.writein>select(comm.equals(c.name))->forAll(
c1,c2:Candidate|not c1.name.equals(c2.name)
)
--------------------------------------------------------------------------------------------------------End of the specification
---------------------------------------------------------------------------------------------------------
41
Section 8
Formal Technical Inspection
8.1 Introduction
A formal technical inspection or formal technical review (FTR) is a software quality
assurance activity. The purpose of FTR is to find and eliminate defects. It can be applied
to any product or partial product of the software development process, including
requirements, designs, and code. The formal technical inspections are embedded in the
process of developing products and are done in the early stages of each product’s
development.
In this document, the system design will be subjected to the formal technical inspection.
Some formal checklists will be developed and used to inspect the all aspects of the
software development. This document contains a checklist for the SRS Documents, a
checklist for design, a checklist for OCL specification.
8.2 Reference
NASA Software Formal Inspections Guidebook
http://www.gsfc.nasa.gov/fi/gdb/fi.ps
8.3 Software requirement specification checklist
Completeness

Does SRS include all user requirements (as defined in the concept phase)?
Yes.

Do the functional requirements cover all abnormal situations?
N/A.

Have the temporal aspects of all functions been considered?
No.

Does SRS define those requirements for which future changes are anticipated?
No.

Are the environmental conditions specified for all operating modes (e.g., normal,
abnormal, disturbed)?
42
No.
Consistency

Is there any internal inconsistency between the software requirements?
No.

Does SRS use standard terminology and definitions throughout?
Yes.

Is SRS compatible with the operational environment of the hardware and software?
N/A

Has the impact of software on the system and environment been specified?
N/A.

Has the impact of the environment on the software been specified?
N/A.
Correctness

Does the SRS conform to SRS standards?
Yes.

Does the SRS identify external interfaces in terms of input and output
mathematical variables?
N/A.

Is there justification for the design/implementation constraints?
Yes.
Feasibility

Will the design, operation, and maintenance of software be feasible?
Yes.
Modifiability

Are requirements organized to allow for modifications?
Yes.
43

Is each unique requirement defined more than once? Are there any redundant
statements?
No.
Traceability

Does the SRS show explicitly the mapping and complete coverage of relevant
requirements and design constraints defined in the concept phase?
Yes.

Is SRS traceable forward through successive development phases (e.g., into the
design, code, and test documentation)?
Yes.
Understandability

Is the language ambiguous?
No.

Does the SRS contain only necessary implementation details and no unnecessary
details?
Yes.

Is the SRS over specified?
No.

Are the requirements clear and specific enough to be the basis for detailed design
specs and functional test cases?
Yes.
Maintainability

Does the documentation follow MSE portfolio?
Yes

Is the documentation clear and unambiguous?
Yes
44
Verifiability/Testability

Are the requirements verifiable (i.e., can the software be checked to see whether
requirements have been fulfilled)?
Yes.
8.4 Software design checklist

Is each class a good abstraction?
Yes

Does each class have high cohesive?
Yes

Is there low coupling?
Yes

Is each function limited to necessary knowledge?
Yes
8.5 OCL checklist

Is the syntax of each expression correct?
Yes

For each operation, is it applied to an instance of the correct type?
Yes

For each equality, do the expressions on each side resolve to the same type?
Yes
45
Section 9
Object Model
9.1 Object model of Internet Voting System Manager
Figure 9: Object Model of IVS Manager - Server Side
46
9.2 Object Model of Internet Voting System Client
Figure 10: Object Model of IVS Manager – Client Side
47
9.3 Interactive diagram of Server side:
ivsm : IVSM
administrator :
Administrator
server : Server
connServer :
ConnServer
Handler :
ServerProtocol
wrapper :
QueryWrapper
connManager :
ConnManager
verifyPassword(String)
setStartAndOverTime()
setCandidates(String)
setDatabase(String)
accept( )
start( )
xmlProcess(String)
verifiedQuery(String)
getConnection(String)
verifiedQuery(String)
ballotQuery(String)
ballotQuery(String)
accept( )
Figure 11: Interactive diagram of IVS Manager – Server Side
48
9.4 Interactive diagram of Client side:
vclient : VClient
connclient :
ConnClient
handler :
ClientProtocol
ballot : Ballot
votingFrame :
VotingScreen
run( )
xmlProcess(String)
addCommittee(Object)
xmlProcess(String)
formatBallot()
voting()
sendBallot()
Figure 12: Interactive Diagram of IVS Manager – Client side
49
Section 10
Test Plan
10.1 Identifier
N/A
10.2 Introduction
The Software Test Plan (STP) describes plans for qualification testing of Server
side and client side components in IVSM (Internet Voting System MAnager) project.
The purpose of the test plan should be able to ensure that intended functionality is being
implemented properly in each module of the code. To fulfill this objective, a series of test
will be executed during the coding.
10.3 Scope
This test plan outlines the strategies on unit testing and integration testing. Unit
testing focuses verification effort on the major functions, and integration testing tests
the program structures built with unit-tested modules.
10.4 Approach

Unit testing: each class is tested separately. The testing is focused on the major
functions in each class. White box and black box techniques are both used.

Integration testing: For the Client and Server components, we want to test their
performance together with other components, such as Database and main window.
Stress testing and boundary testing will be used.
10.5 Test Cases

After a user enters the homepage of the program at client side, a friendly GUI
interface will show up with introducing of voting. Test whether the main window
appear properly
50

After a user press OK button in the introducing frame, a friendly GUI interface
will show up with asking for the inputs for user name and password. Test
whether the main window appear properly.

After the user inputs correctly, another widow will show up with the connection
status. Test whether the program can handle the correct inputs and other
exceptions.

At this point, If the client connects to the server correctly, the ballot will show up.
The user can cast the ballot now. Test whether the components has the correct
functionalities.

If the voter press send_the_ballot button, Test whether all functionalities have the
expected responses.

System has robust error handler. By given malicious input, the system will detect
its invalid, give error message and logging on it.

Stress testing, in a short time, a lot of clients will try to connect to the server,
testing if the server can handle it.
10.6 Pass/fail criteria
N/A
10.7 Suspension criteria
N/A
10.8 Deliverables

Test plan

Test case specification

Test logs

Test input data and test output data

Test suit
10.9 Responsibilities
The developer is responsible for all the testing activities to be carried out.
51
10.10 Schedule

Unit testing – each unit will be tested during implementation.

Integration testing – The program is constructed and tested in small segments
after all functions are finished and unit tested.
10.11 Contingency Plans
N/A
10.12 Approvals
Approved by Committee members.
52
Section 11
Time log for Phase Two
Date
Start
Stop
Time
Activity
Comment
10/22/01
10:00
10:30
0.5 hr
Reading rules, design
Start
10/24/01
10:30
12:00
1.5 hrs
Reading materials,
learning Formal Spec
10/28/01
2:00
6:00
4 hrs
Design
List required item
10/30/01
1:30
6:00
4.5 hrs
Object model
Add more details
11/1/01
8:30
12:00
3.5 hrs
Object model
Add more details
11/4/01
2:00
5.30
3.5 hrs
Object model
Add more details
11/9/01
8:30
10:30
2 hrs
Write design document
11/10/01
11:00
2:00
3 hrs
Formal specification
11/12/01
2:00
6:00
4 hrs
Formal specification
11/15/01
8:00
12:00
4 hrs
SQA plan
11/18/01
7:00
11:00
4 hrs
SQA plan
Modify
11/22/01
3:00
7:00
4 hrs
Formal specification
Modify
11/23/01
8:00
10:00
2 hrs
Test plan
11/25/01
8:00
11:30
3.5 hrs
Test plan
11/28/01
2:30
5:30
3 hrs
Test plan
12/5/01
2:00
6:00
4 hrs
Formal technique
Modify
review
12/6/01
9:00
12:00
3 hrs
Formal technique
review
12/13/01
2:00
6:00
3 hrs
Formal specification
Modify
12/14/01
8:00
12:00
4 hrs
Formal specification
Modify
1/17/02
7:00
11:00
4 hrs
Modify object model
1/22/02
8:00
11:00
3 hrs
Modify object model
1/24/02
3:00
3:30
0.5 hrs
Meet with Dr. Bleyberg
2/2/02
8:00
12:00
4 hrs
Formal specification
Modify
53
2/9/02
2:00
6:00
4 hrs
Modify object model
2/16/02
2:00
6:00
4 hrs
Formal specification
Modify
2/23/02
2:00
6:00
4 hrs
Formal specification
Modify
3/1/02
11:30
4:00
4.5 hrs
Review
Check document in
Phase I
3/7/02
8:00
12:00
4 hrs
Write document
3/14/02
2:00
6:00
4 hrs
Prepare for
Make slides
presentation
3/28/02
2:30
3:30
1.0 hrs
Presentation Two
54
Part Three
Phase III Project Implementation
Section 12
Administrator Manual
12.1 System requirement

Communication will be done using TCP/IP sockets. This requires that each
machine participating in the computation must be connected to the network.

Sun’s Java Runtime Environment, version 1.2 or higher must be installed in the
system.

Oracle DBMS 8i or other database must be installed.

The compiled source code is available in the following download site
(ftp://129.130.11.77/mseserver.jar).
12.2 How to install the Internet Voting System Manager – server side
a. Download the package mseserver.jar from ftp://129.130.11.77/mseserver.jar;
b. un-jar the mseserver.jar to destination directory;
c. change directory to the destination directory;
d. issue “runserver”
12.3 How to configure the Internet Voting System Manager – server side
a. After starting the system, first a welcome screen will appear. It will show up for
about 4 seconds.
Figure 13: Welcome Screen of IVMS
55
b. Set up the administrator
Then an administrator input dialog appears. The user should input the
administrator ID and password. The system will use the administrator ID to generate the
key for the whole system.
Figure 14: Administrator Input Dialog
c. IVS Manager main window
After inputting the administrator name and password, IVS Manager main window
comes. There is a menu bar in the main window which includes Election, Server, Result,
Admin and Help menus and a text display screen.
Figure 15: The Main Window for Configure the IVMS
56
d. Make Keys and Init DB
In main window, by selecting the election menu and clicking the Make Keys and
Init DB, user should select a database properties file to make the keys and initialize the
database for the system.
Before the administrator can set the database properties, make sure the database is
available. The administrator can use any database. The following is an example of
db.properties for an Oracle database and JDBC driver.
The data format of db.properties:
jdbc.drivers=oracle.jdbc.driver.OracleDriver
jdbc.url=jdbc:oracle:thin:@zaurak.cis.ksu.edu:1521:PROD
jdbc.user=******
jdbc.password=*******
jdbc.maxconn=10
After initiating the database, the system will build three tables: Voters, Candidates and
Committees
Create Table Voters (
name VARCHAR(50),
code NUMBER,
email VARCHAR(50),
pwd VARCHAR(20),
voted CHAR(5)
)
Create Table Candidates (
name VARCHR(50),
committee VARCHAR(255),
votes NUMBER
)
Create Table Committees (
committee VARCHAR(255),
pnum NUMBER
)
57
e. Import voters and candidates
By selecting the election menu and clicking the Import Voters/Candidates, user
should select a voters.dat/candidates.dat file to populate the voters/candidates/committees
table.
The data format of voters.dat:
Yonghua Li, 1, yli3568@cis.ksu.edu
Maria Bleyberg, 2, maria@cis.ksu.edu
William Hsu, 3, bhsu@cis.ksu.edu
David Gustafson, 4, dag@cis.ksu.edu
Table 9: The Voters Table in DB
Name
Id
email
pwd
Yonghua Li
1
Yli3568@cis.ksu.edu ****
voted
no
The system will generate a password for each voter and set the voted to “no”.
The data format of candidates.dat:
Committee:CITY OFFICES MANHATTAN CITY COMMISSIONERS
Position number:3
Carol Peak
Roger P. Reitz
Mark Taussig
Brad Everett
David L. Johnson
Karen McCulloh
Committee: USD #383 SCHOOL BOARD MEMBER
Position number:3
Jim Shroyer
J. Scott Smith
Dorothy Soldan
Milo Kelly
58
Walter Pesaresi
Flordie Pettis
Table 10: The Candidates Table in DB
Name
Committee
votes
Carol Peak
CITY OFFICES MANHATTAN
0
……
……
……
The system will set the votes to 0.
Table 11: The Committees Table in DB
Committee
Pnum
CITY OFFICES MANHATTAN
3
#383 SCHOOL BOARD MEMBER
3
f. Start the IVS Server
By selecting the server menu and clicking the Start Election Time, set the election
starting time. Then set the election ending time. After the election time has been set up,
the server can be start by selecting the server menu and clicking start server.
g. Set the mailSender
By selecting the result menu and clicking the outMailServer, set the mail server and
account.
Figure 16: The Dialog for Setup the Mail Server
59
h. Hiding the main screen.
By selecting the Admin menu and clicking the Log Off, the main windows can be hidden.
Then only the administrator can log on this system by inputting the administrator ID and
password set at the system starting.
12.4 How to install the Internet Voting System Manager - client side
a. Download the package mseclient.jar from ftp://129.130.11.77/mseclient.jar
b. un-jar the mseclient.jar to the destination directory.
c. Change directory to destination directory.
c. issue “runclient”. A flash screen appears for about 4 seconds, then come with
the IVS Client main windows. The voter can vote through this screen.
60
Section 13
Voter Manual
13.1 Overview
The client main GUI has a display screen and two buttons: Enter to Voter and Password
Request.
Figure 17: The Main GUI for IVMS - Client
13.2 Request Password
If the voter presses the Password Request button, the password request GUI will show.
The password request GUI has two text boxes for inputting the voter name, voter ID. The
requested password will be send to the voter’s email account if data voter enters are
correct and press Send button. If Exit button has been pressed, the system will return to
the client main windows
61
Figure 18: Password Request GUI
13.3 Vote
a. Log on
If the voter presses the Enter Vote button, the confirmation screen shows. The
confirmation screen has three text boxes and two buttons. Fill the boxes and press the
send, if confirmed, press vote button in the next windows to cast the ballot.
Figure 19: Confirmation GUI
b cast ballot
62
The voting ballot screen: each committee is listed as a column. According to the
instruction in the ballot, cast the ballot and press the Vote button. If successfully, return
to the main windows. If not, a wrong message shows, and voter can try again.
Figure 20: The Ballot GUI
63
Section 14
Test and Reliable Evaluation
14.1 Overview
The testing of Internet Voting Manager System (IVMS) was performed on CIS UNIX,
Win-XP machine and Linux machine. The test plan of phase2 was followed to conduct
the testing of the system. Besides testing the correctness of the tool, we also tested its
performance. Correctness test includes unit tests, integration tests, system test. On the
other hand, performance tests were tested by stress testing.
14.2 Unit and Integration test
The internet voting management system consists of two parts: the server side components
and client side components. The server side components includes internet voting system
manager component, database connection and query manager component, the server and
client connection component and mail sender component and client component. The
black box random testing and regression testing are adopted in integration testing.
The following testing technologies are adopted in component unit testing. For each
component, the functional testing, white box testing and/or black box testing, has been
used. In white box testing, path-based domain testing and/or boundary testing are used to
generate test cases. In black box testing, random testing and/or regression testing are used
to generate test case.
The percentage of test result will be used decide to if the software passes or fails. If the
test cases passing rate is greater than 90%, the component passes the testing. If the test
cases passing rate is less than 70%, the component fails in this test. If the rate is among
70 ~ 90%, more test cases are used.
A test bed was written for testing. In this test GUI system, menu bar has three menus,
Action menu, Kiosk Server Tests menu and Poll Server Tests menu. The following is the
snapshot of test bed.
64
Figure 19 Test Bed GUI
14.3 Test Log for Unit Testing and Integration Testing
Table 12: Test Log for Unit Testing
Component
Testing method
Functionality
performance
pass
DBConnectionPool
Path-based
getConnection,
Work well
yes
domain
freeConnection
Path-based
getConnection,
Work well
yes
domain
freeConnection
Path-based
Init()
Work well
yes
domain
importVoter
Boundary
importCandidate
Work well
yes
DBConnectionManager
DBQueryWrapper
confirmVoter
votingResult
sendingResult
pwdRequest
getBallot
addVoter
IVMSManager
Path-based
actionPerformed
65
domain
boundary
IVMSServer
ConClient
Path-based
Tick
Work well
yes
domain
accept
Path-based
Run
Work well
yes
Path-based
singleMailSent
Work well
yes
domain
batchMailSent
Path-based
actonPerformed
Work well
yes
domain
MailSender
IVMSClient
domain
boundary
Table 13: Test Log for Integration Testing
Integration
Testing method
Passing rate
DBManager-DBPool
Regression, random
100%
DBWrapper-DBManager
Regression, random
100%
ConClient-DBManager
Regression, random
100%
mailSender-DBWrapper
Regression, random
100%
14.4 System/Performance test
For system/performance testing, the following testing method are used.
All the GUI input box are tested by boundary testing. The client, server and DB
component are tested by stress testing to check the performance. Errors are injected in the
system to check if the system can catch all the errors. Stamp testing are used to check the
time between the client and server, server and DB. Error handling testing are used to
check the system robotics.
66
Table 14: Test Log for System/Performance Test
Testing type
Functionality
Performance
pass
Boundary
System
Works well
yes
Stress
System
Works well
yes
Error injection
System
Catch all
yes
Stamp
System
Works well
yes
Error handling
System
Works well
yes
14.5 Error-handling test
The following is the list used to Error handling testing.
Table 15: Test Log for Error-handling Test
Test items
result
IVSManager can check if the db.properties is correctly file
pass
IVSManager can check if the voter.dat file is correctly file
Pass
IVSManager can check if the candidate.properties is correctly file
pass
IVSManager can check if the election start time is correct
Pass
IVSManager can check if the end time is correct
Pass
IVSManager can check if the server port is ok
pass
IVSManager can check if the mail sender server is right
pass
IVSClient can check if the pwd request input boxes are filled
pass
IVSClient can check if the confirm input boxes are filled
pass
IVSClient can check if the ballot cast number is right
pass
IVSClient can check if the new candidate is clicked and filled
pass
14.6 Fairness and Integrity test
Fairness is one of the most important factors for a successful voting. For each candidate,
the probability of election should not be affected by the placement of candidate on the
ballot. So each candidate should have the same probability to appear on any place this
group of candidates could appear.
67
This following table is the result which put the candidates of one committee in the first
place. The probability of candidate appeared on other place is distributed totally same.
The total ballots is 10000. From the result we can see, it is pretty fair for each candidate.
Table16: Fairness Test
Candidate
Count
probability
Candidate 1
1662
16.62%
Candidate 2
1656
16.56%
Candidate 3
1673
16.73%
Candidate 4
1666
16.66%
Candidate 5
1671
16.71%
Candidate 6
1670
16.70%
The integrity is another most important factor in election. In this project, the voter should
not vote twice, and the voter’s ballot should not be lost.
Table 17: Integrity Test result
Test Item
Performance
pass
case for voting twice
Works well
yes
case for log on multi place
Works well
yes
case for losing ballot
Works well
yes
14.7 Conclusion
At this time, this project provides a reliable running program with satisfied result. Further
fairness and integrity are possible but beyond this project.
68
Section 15
Project Evaluation
15.1 Overview of the software development life cycle
I applied the most widely used software development life cycle model (Waterfall model)
to develop my MSE project. Waterfall model consists of five stages: (1). Requirement
specification; (2) software design; (3) code generation; (4).Testing and integration; (5).
Maintenance. My MSE project development process includes three phases: (1).
requirement specification phase, (2). design phase, and (3). implementation phase. These
three phases covered all stages in the waterfall model. Each development phase was well
documented, and all documents were reviewed by the committee members. New phase
was started after completion of the previous phase. More important, after each phase,
review and formal inspection was done. In the implementing phase, unit and integration
test were performed to assure quality of the software.
15.2 Evaluation of phase1
Phase one focuses on the requirement of the software development. This stage is based
on the discussion with Professor Bleyberg to make the requirements clear. After a
reasonable understanding is achieved, a basic idea and a preliminary design have been
formed that benefits the further understanding of the requirements. With this
understanding, next steps are to gather and specify the requirements of the project,
including background review, project overview, software requirement specification
(SRS), cost estimate and project plan. Some figure is also made to describe the system
configuration.
The SRS is the central task in this phase, it states the purpose of the tool, the expectation
of the potential user, and the functionality the tool will provide. When the project reaches
the final stage, it turned out that all the requirements specified in Phase 1 have been
achieved. I use the function positions to estimate the size of my product, use COCOMO
model to calculate the development time. The estimated size of my project is 5.1 kLOC.
The estimated development time of my project is 7.0 months. The actual size of my
project is 3.9 kLOC. The actual development time is 10 months. The actual size of code
69
is far less than the estimated value. This is understandable because java has a lot of
library packages which actual coding benefits from them for saving lines and time.
15.3 Evaluation of phase2
The major task in Phase II is to develop a detailed design guiding the implementation of
project. It includes object model, formal specification, SQA, test plan, and formal
technique inspection. The object model is the central task of this phase. The object model
outlines the overall software architecture of project.
It specifies what kinds of components consist of the whole project; what kinds of objects
constitute each component, what kinds of main methods is composed of each object. All
these design issues are very important for the implementation step. The raw idea formed
in Phase One is further developed in details, especially in the form of a computer
language (Java). The results of this make some changes with those object model roughly
designed in Phase One. To make the Phase One document consistent with the current
design requirement, the formal technique inspection has been performed in this phase.
After finishing the object model, we need to choose one formal specification language to
specify the project design. I choose UML/OCL to specify the object model of my project.
The formal specification specifies exactly what each object do, what each method of the
object do. The sequence diagram specified the call sequence of related methods. All this
information is very important fro the phase III. I use the tool USE version 2.0.0 to verify
the correction of my formal specification. Because this tool is a new tool, I spend one
week to study it, then I use it in my case.
The test plan, SQA plan, and formal inspection are also very important for software
design. With the test plan, I can improve the performance of my program by taking all
kinds of possibilities. The SQA plan gives me a guideline to make sure if the software
meets the all functionality requirements, technical requirements, and reliability
considerations. In the formal specification, committee member can gave me very helpful
suggestions.
70
15.4 Evaluation of phase3
Phase III of the project focus on the actual implementation and test of the tool. After
understanding the requirement properly and designing the project efficiently, the coding
was going smoothly for major functions. At first, I modified and developed the
DBConnectionManager component, and wrote a small application program to use the
DBConnectionManager component to connect the dababase. Secondly, I developed an
IVMSManager component, and wrote a small program to run this IVMSManager
component, which configure the system. Thirdly, I implemented the server component
class to handle all the clients logging on. Fourthly, I wrote the client component through
which voters can cast the ballots. Finally, I put these three components together to make
the whole system run.
In this phase, testing is also finished. Basically, this task is performed simultaneously
while coding. When the coding reaches the end, the system test and integration test are
performed using the test case designed in Phase II. At least, the test report has been
provided as in the above section. Refer to Section 14 for details.
15.5 Conclusion
The project is finished successfully according to the software requirement specification in
the Phase I. It was a great experience for me to complete such a parallel and distributed
computation project in a professional style. Working on the project not only gives me a
good understanding of software life cycle, but also gives me a chance to learn scientific
programming, framework implementation. I believe the whole process will make me a
better professional in this fascinating field.
71
Section 16
Time Log for Phase III
Date
Start
Stop
Time
Activity
Comments
4/1/02
10:00
4:30
6.5 hrs
Download java.mail
Learning new thing is
package and practice
time-consumed.
4/5/02
6:30
11:30
5 hrs
Run examples
10:00
2:30
4.5 hrs
Write simple test
Get everything work
application
4/8/02
7:00
11:00
4 hrs
Coding some class for
Looks everything OK
the IVMS manager
component
4/12/02
10:00
4:00
5 hrs
Writing server side
component
7:00
12:30
5.5 hr
Redesigned some
helper class for the
task
4/20/02
10:30
5:00
6.5 hrs
Coding client side
Meet a problem:
component
object input and
output stream in
network connection
6:00
12:00
6 hr
Read material, study
Solving the problem
Java API
4/29/02
12:00
9:00
9 hrs
Coding and debugging
Testbed component
5/4/02
8:00
10:00
14 hrs
System Testing
5/12/02
8:00
11:00
3 hrs
Continue testing
9/1/02
7:00
11:30
4.5 hrs
Testing in Unix
9/5/02
10:00
3:30
5.5 hrs
Testing in Linux
9/12/02
7:00
11:00
4 hrs
Coding the framework
Fix some bugs
72
for other components
9/13/02
10:00
4:00
6 hrs
Try the Unix platform
Class not found
to Windows
problem
9/14/02
7:00
11:00
4 hrs
Search web for help
No clues
9/15/02
7:00
9:00
2 hrs
Asking help from
No clues
System administrator
9/16/02
6:00
11:00
5 hrs
Search web for help
Found a paper and
solve the problem
9/20/02
7:00
10:00
3 hrs
Try Linux platform to
OK
Windows, Unix to
Linux
9/26/02
9:00
11:30
2.5 hrs
Writing documents
9/27/02
2:00
5:00
3 hrs
Testing the project
9/28/02
10:00
4:00
6 hrs
Testing the project
10/1/02
8:30
11:30
3 hrs
Writing documents
10/2/02
11:30
2:00
2.5 hr
Writing testing report
10/3/02
7:00
10:00
3 hrs
Writing documents
10/4/02
6:00
11:00
5 hrs
Writing documents
10/5/02
2:30
6:30
4 hrs
Prepare slides
10/14/02
2:30
3:30
1 hrs
Pre - presentation
Testing OK
Need to update the
web, some changes
are required
10/15/02
7:00
11:00
4 hrs
Modify code to give
more popup dialoge
message, change the
candidate.dat format
10/16/02
6:00
10:00
4 hrs
Edit final report
10/20/02
6:00
11:00
5 hrs
Review final report
10/28/02
2:30
3:30
1 hr
Final presentation
73
Appendix
Source Code
Final Report Document
Presentation Slides for Three Phases
74