Voting schemes are one of the most important examples of advanced crypto-graphic protocols with immediate potential for practical applications. Such protocols should of course have security properties similar to those of ordi-nary paper based elections, but the fact that digital communication is used may also open up new possibilities. Informally, the most important goals for electronic voting schemes are:
- Privacy: Only the final result is made public, no additional information about votes will leak.
- Robustness: The result reflects all submitted and well-formed ballotscorrectly, even if some voters and/or possibly some of the entities running the election cheat.
- Universal visibility: After the election, the result can be viewd by anyone.
- Other properties may be considered as well, such as receipt-freeness. In a receipt-free election, voters are not able to prove that they voted for a particular candidate after the election, thereby discouraging votebuying or coercing.
2.0 System study
The Online voting is best way to vote through internet access. It is a growing product and successively implemented. We can add more functionality in this system. We can give more secure to the online polling. The main difficulty is to kept secret of user vote and prevent from unauthorized access. No one can be cast the vote twice.
2.1 Existing system
The existing system was an automated system. But It was found that it is very hard to conduct voting in hectic areas in such areas the new technology is very efficient.
2.1.1 Drawbacks in the existing systems
The existing system is not user-friendly system. Disadvantage of the existing system:
- Extremely insecure
- Time Consuming
- Needed an agent
- Hard to conduct voting in naxalites areas.
3. 0 System analysis
The purpose of this document is to describe the design of the project named SECURITY IN ONLINE NATIONAL POLLING. The purpose of design documentation is to express the vision for the project, describe the contents, and present a plan for implementation.
A design document is a bible from which the producer preaches the goal, through which the designers champion their ideas, and from which the artists and programmers get their instructions and express their expertise.
This product has great future scope. The Security In Online National Polling software developed on and for the WindowsXP and later versions environments and Linux OS. This project also provides security with the use of Login-id and Password, so that any unauthorized users. The only authorized user have proper access authority can access the software.
3.3 Need for the proposed system
The basic need of SECURITY IN ONLINE POLLING is to provide security in polling. This is developed to vote via internet. The proposed availability of the System is 24 X 7 with full security.
Features and benefits
- Providing security
- Low cost
- Basic computer knowledge required
- Configurable and extensible application UI design
The proposed system can be used even by the naïve users and it does not require any educational level, experience, and technical expertise in computer field but it will be of good use if the user has the good knowledge of how to operate a computer.
3.4 Feasibility study
A feasibility study is a short, focused study, which aims to answer a number of questions:
- Does the system contribute to the overall objectives of the organizations?
- Can the system be implemented using current technology and within given cost and schedule constrains?
- Can the system be integrated with systems which are already in place?
3.4.1 Technical feasibility
- Is the project feasibility within the limits of current technology?
- Does the technology exist at all?
- Is it available within given resource constraints (i.e., budget, schedule)?
3.4.2 Financial feasibility
- Is the project possible, given resource constraints?
- Are the benefits that will accrue from the new system worth the costs?
- What are the savings that will result from the system, including tangible and intangible ones?
- What are the development and operational costs?
3.4.3 Operational feasibility
Define the urgency of the problem and the acceptability of any solution; if the system is developed, will it be used? Includes people-oriented and social issues: internal issues, such as manpower problems, labour objections, manager resistance, organizational conflicts and policies; also external issues, including social acceptability, legal aspects and government regulations.
4.0 System requirements specifications
System requirements are expressed in a software requirement document. The Software requirement specification (SRS) is the official statement of what is required of the system developers. This requirement document includes the requirements definition and the requirement specification. The software requirement document is not a design document. It should set out what the system should do without specifying how it should be done.
The requirement set out in this document is complete and consistent. The software specification document satisfies the following:-
- It specifies the external system behaviors.
- It specifies constraints on the implementation.
- It is easy to change.
- It serves as reference tool for system maintainers.
- It record forethought about the life cycle of the system.
- It characterizes acceptable response to undesired events.
4.1 User class and characteristics
There are 4 types of user of this software
- General Public.
- Field officer
- General public can request for access votting rites. He can vote to desired candidate and see the result.
- Administrators can grant and revoke various candidates. Publish the result. Create new party for the election.
- Field officer can verify the voter and after that he can approved or deapproved the voter.
- Candidate can apply to participate in election.
4.2 Functional requirements
The System must provide following functionalities:
- Online registration.
- Those already have voter id card can register for online national polling.
- A detailed profile for candidate.
- Once registered is over user can vote for the candidates.
- Devise a mechanism for restrict the duplicate voting.
- The system will show the current statistics as well as how many vote which candidate have got.
- Administrator produce the result
4.3 Performance requirements
In order to maintain an acceptable speed at maximum number of uploads allowed from a particular user will be any number of users can access the system at any time. Also connections to the servers will be based on the criteria of attributes of the user like his location, and server will be working whole 24X 7 times.
4.4 Non functional requirements
Following Non-functional requirements will be there in the Insurance on internet:
- Secure access of confidential data (user’s details).
- 24 X 7 availability.
- Better component design to get better performance at peak time.
- Flexible service based architecture will be highly desirable for future extension Non functional requirements define system properties and constraints. It arise through user needs, because of budget constraints or organizational policies, or due to the external factors such as safety regulations, privacy registration and so on.
Various other non-functional requirements are:
- Application Affinity/Compatibility
- Resource Utilization
4.5 External interface requirements
4.5.1 User interface:
User of the system will be provided with the Graphical user interface, there is no command line interface for any functions of the product. The user will get 2 pages
- Login page followed by Password
4.5.2 Hardware interface
Hardware requirements for security system on internet will be same for both the parties which are follows:
Processor: – Pentium I or above.
RAM: – 128 MB or above.
HD: – 20 GB or above.
NIC: – For each party
4.5.3 Software interface
Software required to make working of product is:
- Operating System: Windows XP/vista or later version, Linux OS which supports networking.
- JAVA development tool kit
4.5.4 Communication interfaces
The two parties should be connected through either by LAN or WAN for the communication.
4.6 General constraints, assumptions, dependencies, guidelines:
4.6.1 General constraints
1 The interface will be in English only.
2 The system is working for single server.
3 There is no maintainability or backup so availability will get affected.
4 The system is a single user system.
5 GUI features available.
4.6.2 Assumptions and dependencies
The product does require back-end database server MySQL for storing the username and password for different types of user of the system as well as various databases regarding various secure information in encrypted form.
- User must be trained for basic computer functionalities.
- User must have the basic knowledge of English
- The system must be able to respond to database software within reasonable time.
Front-end (user interaction)
- The product will require a computer with an application program or with any other application program and an communication channel.
- The speed of the communication channel (if any) must be, at a minimum 28.8 kbps in order to support message transfer in reasonable time.
System design specification
5.1 Architectural design
5.1.1 Data flow diagrams
Data flow diagrams (DFD) was first developed by LARRY CONSTANTINE as way representing system requirements in a graphical form; this lead to modular design.
A DFD describes what data flow (logical) rather than how they are processed, so it does not depend on hardware, software, data structure or file organization. It is also known as ‘bubble chart’.
A Data Flow Diagrams is a structured analysis and design tool that can be used for flowcharting in place of, or in association with, information-oriented and process-oriented systems flowcharts. A DFD is a network that describes the flow of data and the processes that change, or transform, data throughout a system. This network is constructed by using a set of symbols that do not imply a physical implementation. It has the purpose of clarifying system requirements and identifying major transformations that will become programs in system design.
So it is the starting point of the design phase that functionality decomposes the requirement specifications down to the lowest level of detail.
The symbols used to prepare DFD do not imply a physical implementation, a DFD can be considered to an abstract of the logic of an information-oriented or a process-oriented system flow-chart. For these reasons DFDs are often referred to as logical data flow diagrams. The four basic symbols used to construct data flow diagrams are shown below:
These are symbols that represent data flows, data sources, data transformations and data storage. The points at which data are transformed are represented by enclosed figures, usually circles, which are called nodes. The principle processes that take place at nodes are:
- combining data streams
- splitting data streams
- modifying data streams.
DFD LEVEL 1 FOR GENERAL PUBLIC
DFD LEVEL 1 FOR CANDIDATE
DFD LEVEL 1 FOR FIELD OFFICER
DFD LEVEL 1 FOR ADMINISTRATOR
5.1. 2. Database design
A database design is a collection of stored data organized in such a way that the data requirements are satisfied by the database. The general objective is to make information access easy, quick, inexpensive and flexible for the user. There are also some specific objectives like controlled redundancy from failure, privacy, security and performance.
A collection of relative records make up a table. To design and store data to the needed forms database tables are prepared. Two essential settings for a database are:
- Primary key: The field that is unique for all the record occurrences.
- Foreign key: The field used to set relation between tables. Normalization is a technique to avoid redundancy in the tables.
Data base TABLE DESIGN:
Table Name: adm–
This table stores the administrator login name and password.
Table Name: cand–
This table stores the candidate login name and password.
Table Name: cand_detl—
This table stores the general information about candidate.
Table name : fieldoff—
This table store the login id and password of field officer.
TABLE NAME: KEYD:–
This table store information about encryption and decryption key.
TABLE NAME : party_detail
This table store the information about different party.
TABLE NAME : pub—
This table store the login name and password of voter.
TABLE NAME:: pub_detl
This table store the general information about public.
TABLE NAME: Result
This table store the the status of the result
TABLE NAME: Vote
This table store the status of voter that he/she cast the vote or not.
TABLE NAME: votting
This table store information about the total number of vote cast in encrypted form.
Software Testing is an empirical investigation conducted to provide stakeholders with information about the quality of the product or service under test, with respect to the context in which it is intended to operate. Software Testing also provides an objective, independent view of the software to allow the business to appreciate and understand the risks at implementation of the software. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs. It can also be stated as the process of validating and verifying that a software program/application/product meets the business and technical requirements that guided its design and development, so that it works as expected and can be implemented with the same characteristics.
Software Testing, depending on the testing method employed, can be implemented at any time in the development process, however the most test effort is employed after the requirements have been defined and coding process has been completed.
6.1 Unit testing
The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect. Each unit is tested separately before integrating them into modules to test the interfaces between modules. Unit testing has proven its value in that a large percentage of defects are identified during its use.
Unit testing is a software verification and validation method where the programmer gains confidence that individual units of source code are fit for use. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual program, function, procedure, etc., while in object-oriented programming, the smallest unit is a class, which may belong to a base/super class, abstract class or derived/child class.
Ideally, each test case is independent from the others: substitutes like method stubs, mock objects, fakes and test harnesses can be used to assist testing a module in isolation. Unit tests are typically written and run by software developers to ensure that code meets its design and behaves as intended. Its implementation can vary from being very manual (pencil and paper) to being formalized as part of build automation.
6.2 Integration testing
Integration testing, also known as integration and testing (I&T), is a software development process which program units are combined and tested as groups in multiple ways. In this context, a unit is defined as the smallest testable part of an application. Integration testing can expose problems with the interfaces among program components before trouble occurs in real-world program execution. Integration testing is a component of Extreme Programming (XP), a pragmatic method of software development that takes a meticulous approach to building a product by means of continual testing and revision.
There are two major ways of carrying out an integration test, called the bottom-up method and the top-down method. Bottom-up integration testing begins with unit testing, followed by tests of progressively higher-level combinations of units called modules or builds. In top-down integration testing, the highest-level modules are tested first and progressively lower-level modules are tested after that. In a comprehensive software development environment, bottom-up testing is usually done first, followed by top-down testing.
6.3 Validation testing
At the validation level, testing focuses on user visible actions and user recognizable output from the system. Validations testing is said to be successful when software functions in a manner that can be reasonably expected by the customer.
Two types of validation testing:
- Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers’ site. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing, before the software goes to beta testing.
- Beta testing comes after alpha testing. Versions of the software, known as beta version, are released to a limited audience outside of the programming team. The software is released to groups of people so that further testing can ensure the product has few faults or bugs.
Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users.
Software Quality Assurance Plan
Each development and maintenance project should have a Software Quality Assurance Plan that specifies its goals, the SQA tasks to be performed, the standards against which the development work is to be measured, and the procedures and organizational structure.
The IEEE Standards for the Software Quality Assurance Plans states that the plan should contain the following sections:
- Reference documents
- Standards, practices and conventions
- Reviews and Audits
- Configuration Management
- Problem reporting and corrective action
- Tools, techniques and methodologies
13.Records collection, maintenance and retention.
- Purpose, Scope and Overview:
The purpose of this Software Quality Assurance (SQA) Plan is to establish the goals, processes, and responsibilities required to implement effective quality assurance functions for the SECURITY SYSTEM IN ONLINE NATIONAL POLLING project.
The SECURITY SYSTEM IN ONLINE NATIONAL POLLING Software Quality Assurance plan provides the framework necessary to ensure a consistent approach to software quality assurance throughout the project life cycle.
This plan establishes the SQA activities performed throughout the life cycle of the SECURITY SYSTEM IN ONLINE NATIONAL POLLING Specifically, this SQA Plan will show that the SQA function is in place for this project. It will show that the SQA group has a reporting channel to senior management that is independent of the project manager, the project’s software engineering group, and software related groups that include Software Configuration Management (SCM), System and Software Test, and Logistics.
The goal of the SQA program is to verify that all software and documentation to be delivered meet all technical requirements.
- Reference documents:
- Software Quality Assurance, Principles and Practice: Nina S Godbole.
An IEEE standard lays down three aspects that should be covered in the
Software Quality Assurance Plan:
a) Organization: The organization section includes the roles of the team members, their hierarchy etc. It is important that the head of the Software Quality Assurance (SQA) function in the organization has the adequate authority to be able to perform independent verification that the processes are adhered to.
Figure below shows the SQA organization with relation to the project organization:
(Figure: SECURITY SYSTEM IN ONLINE NATIONAL POLLING Organization)
The following describes the functional groups that influence and control software quality.
a). Program Management/Line Management (Sponsor) is responsible for the following items:
- Identifying an individual or group independent from the project to audit and report on the project’s SQA function.
- Identifying the quality factors to be implemented in the system and software.
b). Project Management is responsible for:
- Resolving and following-up on any quality issues raised by SQA.
- Identifying, developing and maintaining planning documents such as the Program Management Plan.
c). System Engineering is responsible for:
Implementing the engineering practices, processes, and procedures as defined in program/project planning documents.
d). Software Design/Development is responsible for:
Identifying, implementing, and evaluating the quality factors to be implemented in the software.
e). Software Test is responsible for:
Verifying, Implementing the software test practices, processes, and procedures as defined in program/project planning documents.
f). System Test is responsible for:
Verifying the quality factors are implemented in the system (software and hardware).
g). Logistics is responsible for:
- Reviewing and commenting on the “” SQA Plan.
- Implementing the quality program in accord ONLINE NATIONAL POLLING assurance with this SQA Plan.
h). Software Configuration Management (SCM) is responsible for:
Implementing the SCM practices, processes, and procedures as defined in reference and other program/project planning documents.
i). Independent Verification and Validation (IV& V) is responsible for:
Implementing the practices, processes, and procedures as defined for IV&V in program/project planning documents.
j). Systems Engineering Process Office (SEPO) is responsible for:
- Maintaining the SQA Process.
- Ensuring SQA training availability.
- Providing assistance in software process engineering and software process improvement.
- b) Tasks: An SQA task is performed in relationship to what software development activities are taking place. One or more SQA tasks can be performed concurrently until a task is completed.
The following are the tasks of SQA plan:
- Evaluate System Requirements Analysis Process
- Evaluate System Design Process
- Evaluate Software Requirements Analysis Process
- Evaluate Software Design Process
- Evaluate Software Tools
- Evaluate Software Implementation and Unit Testing Process
- Evaluate End-item delivery Process
- Evaluate Configuration Management Process
- c) Responsibilities: The project manager and design/development teams have primary responsibility for the quality controls applied during the development of the software project.
The quality manager will:
- Define the responsibilities of quality personnel in the form of quality assurance procedures applicable to the project.
- Agree to the quality plan with the project manager.
- Approve the plan of the audits for the project which are to be carried out by quality personnel.
- Resolve any disagreement between the project manager and quality personnel on matters relating to quality.
- Review the activities performed by project personnel to ensure that the requirements of the quality plan and quality procedures are being satisfied.
Quality personnel will:
- Carry out planned internal audits of the project to assess compliance with quality objectives.
- Agree on corrective action with the project manager for any discrepancies, non-conformities found and ensure that corrective action is taken.
- Evaluate defect trends and take appropriate action.
The basic purpose of the documentation section of the Software Quality Assurance Plan is to describe the documentation to be produced and how it is to be reviewed. The documentation section normally includes the following:
- Software Requirements Specification (SRS)
- Software Design Description
- Software Verification Plan
- Software Verification report
- Reference to Software Standards (ISO, CMM, IEEE etc) and procedures mentioned and defined as in the Quality Manual and Quality Management System
- User guides, operators and programmers manual
- Configuration Management Plan
- Software Quality Objectives.
- Standards, practices and conventions:
To verify the delivery of a fully conforming, high-quality product, every individual assigned to the project will participate in quality assurance. This section describes the procedures used by SQA to verify that the quality assurance provisions of this SQA Plan and applicable standards, practices, conventions, and metrics are met.
The following measurements will be made and used to determine the cost and schedule status of the SQA activities: SQA milestone dates (planned)
- SQA milestone dates (completed)
- SQA work scheduled (planned)
- SQA work completed (actual)
- SQA effort expended (planned)
- SQA effort expended (actual)
- SQA funds expended (planned)
- Reviews and Audits:
The review and audits sections of Software Quality Assurance Plan will state which technical and managerial reviews will be undertaken and how they will be carried out. The ANSI standard suggests that the following would be a minimum set of reviews:
- Software Requirements Specification Review: This review is held to approve the document defining the software requirements specifications and it aims to check the adequacy of the requirements.
- Primary Design Review: The purpose of this review is to approve formally, the software top-level design document.
- Critical Design Review: The purpose of this review is to approve the software detailed design document as a basis for further development work.
- Software Verification Review: The purpose of this review is to approve the test plan. It is the evaluation of the adequacy and completeness of the methods described.
- Functional Audit: This is held to verify that all the requirements in the software requirements specification have been met.
- Physical Audit: This is held to verify that the software and its documentation are internally consistent prior to delivery to the user.
- In-Process Audit: In-Process audits of a sample design are held to verify the consistency of the design.
- Configuration Management:
This Configuration Management section of the Software Quality Assurance Plan covers configuration identification, configuration control, configuration status accounting, and configuration auditing.
- Problem reporting and corrective action:
This section of the Software Quality Assurance plan describes the system, which ensures that software problems are documented and resolved. It should be a closed-loop system. All the problems should be promptly reported at appropriate level, acted upon and resolved. Each problem should be analysed to determine its significance and causes and classified by category and each problem must have severity level and a priority number. For each problem, some corrective action and a target completion date should be identified. The appropriate level of management should be made aware of the problems and adverse trends. The corrective action taken will be evaluated to ensure that it solved the problem without introducing any new problems. Management should monitor the status of all unresolved problems.
- Tools, techniques and methodologies:
Tools – SQA software tools include, but are not limited to, operating system utilities, debugging aids, documentation aids, checklists, structuring preprocessors, file comparators, structure analyzers, code analyzers, standards auditors, simulators, execution analyzers, performance monitors, statistical analysis packages, software development folder/files, software traceability matrices, test drivers, test case generators, static or dynamic test tools, and information engineering CASE tools.
Techniques – techniques include review of the use of standards, software inspections, requirements tracing, requirements and design verification, reliability measurements and assessments, and rigorous or formal logic analysis.
Methodologies – methodologies are an integrated set of the above tools and techniques. The methodologies should be well documented for accomplishing the task or activity and provide a description of the process to be used.
- Code Control:
Code control includes the items listed below:
- Identifying, labeling, and cataloging the software to be controlled
- Identifying the physical location of the software under control
- Identifying the location, maintenance, and use of backup copies
- Distributing copies of the code
- Identifying the documentation that is affected by a change
- Establishing a new version
- Regulating user access to the code.
- Media Control:
The Media Control section of the Software Quality Assurance Plan will describe how the media are to be protected from unauthorized access or damage. Security threats to a software project come from the following environmental factors:
- Fire Damage
- Water Damage
- Energy Variations
- Structural Damage
- Unauthorized Intrusion
- Viruses and Worms
- Misuse of Software, Data and Services.
- Supplier Control:
Prior to any purchase of software to support the development effort, SQA and project members will define and provide complete requirements to the supplier/vendor. The Software Tool Evaluation Process will be followed. Part of the evaluation process will require the supplier or vendor to describe their technical support, handling of user questions and problems, and software product upgrades.
- Records collection, maintenance and retention:
SQA activities are documented by records and reports that provide a history of product quality throughout the software life cycle. Measurement data collected will be reviewed for trends and process improvement. All SQA records will be collected and maintained in the SDL or archival storage for the life cycle of the product.
Appendices used in the Software Quality Assurance Plan:
AI – Action Item
CMM – Capability Maturity Model
CRLCMP – Computer Resource Life Cycle Management Plan
CI – Configuration Item
DBDD – Database Design Description
DCR – Document Change Request
DID – Data Item Description
FCA – Functional Configuration Audit
FQR – Formal Qualification Review
IDD – Interface Design Description
IEEE – Institute of Electrical and Electronics Engineers
IRS – Interface Requirements Specification
IV&V – Independent Verification and Validation
KPA – Key Process Area
OJT – On-the-Job
PCA – Physical Configuration Audit
P/CR – Problem/Change Report
PDR – Preliminary Design Review
PP&O – Project Planning and Oversight
PRR – Product Readiness Review
SCM – Software Configuration Management
SDD – Software Design Document
SDF – Software Development File
SDP – Software Development Plan
SDR – System Design Review
SEI – Software Engineering Institute
SEPO – Systems Engineering Process Office
SME – Software Management for Everyone
SPI – Software Process Improvement
SQA – Software Quality Assurance
SRR – System Requirements Review
- DATA FLOW DIAGRAMS:
Data flow diagrams (DFD) was first developed by LARRY CONSTANTINE as way representing system requirements in a graphical form; this lead to modular design. A DFD describes what data flow (logical) rather than how they are processed, so it does not depend on hardware, software, data structure or file organization. It is also known as ‘bubble chart’.
A Data Flow Diagrams is a structured analysis and design tool that can be used for flowcharting in place of, or in association.
This is to conclude that the project that I undertook was worked upon with a sincere effort. Most of the requirements have been fulfilled up to the mark. The Security in online national polling is a most important in the online polling. it is believed that it is going to sustain for a long time. Without security there is no aspect of online polling. It provides the security in online polling.
- Future scope of project
The project made here is just to ensure that this product could be valid in today real challenging world. Here all the facilities are made and tested. Currently the system works RSA encryption algorithm. Which is the one of the most secure algorithm for the encryption.
Books which I referred for the reference
- Core Java 2 Volume I and II, by Cay S. Horstmann and Gary Cornell
- The Complete Reference JSP 2.0 by Hanna
- The Complete Reference MYSQL
- The Complete Referance HTML.
- CryptoGraphy and network security
and some more cryptography website