1 | Page

Project Report (Paper-410)

B. Sc (H) Computer Science (IV Semester)
Area: Software Engineering

ONLINE VOTING SYSTEM

FOR COLLEGE ELECTIONS

Ram Lal Anand College,

Benito Juarez Rd, South Campus, New Delhi
University of Delhi
Submitted By:
Shubham Nauriyal
Kunal Sharma

Under Supervision
Dr. Vandana Gandotra
(Associate Professor)

2 | Page

CERTIFICATE
This is to certify that the project entitled, ONLINE
VOTING SYSTEM FOR COLLEGE ELECTIONS
has been done by:Kunal Sharma and Shubham Nauriyal of Bachelor of
Computer Science (Hons.) during semester IV from Ram Lal
Anand College, University of Delhi under the supervision of
Dr. Vandana Gandotra.

Dr. Vandana Gandotra

3 | Page

ACKNOWLEDGEMENT
The Project was jointly undertaken by Shubham Nauriyal and Kunal
Sharma as their 4th Semester Software Engineering Project, under the
able guidance and supervision of Dr. Vandana Gandotra. Our primary
thanks goes to her, who poured over every inch of our project with
painstaking attention and helped us throughout the working of the
project. Its our privilege to acknowledge our deepest sense of gratitude
to her for her inspiration which has helped us immensely. We are
extremely grateful to her for her unstilted support and encouragement in
the preparation of this project.

4 | Page

TABLE OF CONTENTS

Acknowledgement
1. INTRODUCTION
1.1 Problem statement
1.2 Process model
2. REQUIREMENT ANALYSIS
2.1 Data Flow Diagram (DFD)
2.2 Data Dictionary (DD)
3. PROJECT MANAGEMENT
3.1 Function Points
3.2 Effort Estimation
3.3 Schedule Estimation
3.4 Risk Table
3.5 Timeline Chart
4. DESIGN ENGINEERING
4.1 Architectural Design
4.2 Data Design
4.3 Component Level Design
5. SOFTWARE TESTING
5.1 Computing Basis Path Testing
6. REFERENCES

5 | Page

1. INTRODUCTION
ONLINE VOTING SYSTEM FOR COLLEGE ELECTIONS is an online voting
technique. In which student can give his \her vote online without going to the college
on the day of elections. This will surely consume less time as whole the day is being
consumed on the day of elections.
There is a DATABASE which is maint ained in which all the names of students with
complete information are stored. Each student is provided by a User ID and
Password by using that ID and PASSWORD he \she can use his\her vote. The scope
of this project will be that it will surely increase the voting percentage in university
and college elections. Online Voting System will be fast enough to calculate the
results and reduce the human efforts, as all the things will be automated.

1.1 Problem statement

As the statistics shows that the percentage of polling on the day of elections is not satisfactory as
majority of students are not coming to vote and thinks is just as a wastage of time.
The manual voting system takes long time as there is a lot of paper work first and then human
effort is also there for counting of the votes.
Manual voting consumes almost 4-6 hrs (approx.) of every voter which is surely a headache.
The voting of the college elections will be done online such that there is no need to come at the
college on the time of elections and the student can vote from the home or from any other place.
A USER ID and PASSWORD will be provided to every student of the college, so that on the time
of elections they can easily login on the election link and can use his/her vote.

6 | Page

1.2 Process Model

A process model for software engineering is choosen based on the nature of the project and
application, the methods and tools to be used, and the controls and deliverables that are required.
The model is used to build the ONLINE VOTING SYSTEM
software is The Prototyping Model. The prototyping paradigm is: - Water fall model

Fig.1.2 Water fall Model

The water fall model is a software development model in which a systems development is viewed as
flowing downwards through the phases of the system development process. The waterfall
methodology is powerful, prcised, and thorough. It has a number of phases that have to be
implemented in a sequential manner.
The phases which come under the waterfall model are as follows:1.Requirement Analysis
2.Design
3.Implementation
4.Testing
5.Maintenance

Advantages:
1.Good for large projects
2.Waterfall suits a principled approach to design
3.Waterfall divides the project into manageable areas
4.Waterfall separates the logical and physical

7 | Page

2. REQUIREMENT ANALYSIS
The basic function of requirement analysis is that it translates the ideas in the mind of the clients
into a formal document. Thus the output of this phase is a set of precisely specified requirements
which are complete and consistent. This document is called Software Requirement Specification.
In order to provide the user with a feeling of community, the following requirement should be
taken care:
Each user will have to create their own profile that they can log into each time they visit the
site.
If the user does not create or log in to an account they will only be able to browse
questions on the site, they will not be able to use any of the sites other functionalities.
In order to create an account the user must have a college email address (verified by
server).
Once they create an account the user will be able to Log in and out of the system, Upload a
picture, choose their status (i.e. Student, TA, Professor).
Upload information about themselves (name, AIM, college email, hobbies, etc.)
Select a college and area of study.
View and send private messages to other users through a custom messaging client.
Questions and Answer functionality: Users will be able to post new questions, able to answer
questions and post sources for their answers, search for questions containing key words, thumbs up
and thumbs down questions and responses Users can bookmark questions, send questions to
friends.

2.1 Data Flow Diagram (DFD)

A data flow diagram is a graphical representation that depicts information flow and the transforms
that are applied as data move from input to output.
The basic form of a data flow diagram, also known as a data flow graph or a bubble chart, The data
flow diagram may be used to represent a system or software at any level of abstraction.
As information moves through software, it is modified by a series of transformations. A data flow
diagram is a graphical representation that depicts information flow and the transforms that are
applied as data move from input to output. The basic form of a data flow diagram, also known as a
data flow graph or a bubble chart. DFD is an abstract description of the system. The data flow
diagram may be used to represent a system or software at any level of abstraction.
DFDs may be partitioned into levels that represent increasing information flow and functional
detail. Therefore, the DFD provides a mechanism for functional modeling as well as information
flow modeling. DFDs are very useful in understanding a system and can be effectively used during
analysis.
DFDs can be hierarchically organized, which helps in progressively partitioning and analyzing
large systems. Such DFDs are called leveled DFDs. Context diagram is a diagram in which the
entire system is treated as a single process and all its inputs, outputs, sinks, and sources are
identified and shown.

8 | Page

USERNAME/
PASSWORD

LOG IN

VOTING
PROCESS

STATUS

LOG OUT

Fig.2.1 (a) level 0 DFD

COLLEGE
DATABASE
STUDENT DETAILS

COLLEGE
VOTING
DATABASE

successful

VOTER
AUTHENTICATION

Authentication

VOTING
PROCESS

LOG IN

Username/
password

Voting
done
unsuccessful

HOME
PAGE

LOG OUT

Receipt

USER

USER

Fig.2.1 (b) level 1 DFD

2.2 Data Dictionary (DD)

The data dictionary is an organized listing of all data elements that are pertinent to the system, with
precise, rigorous definitions so that both user and system analyst will have a common
understanding of inputs, outputs, components of stores and intermediate calculations.
Symbols used + represents composition, | means selection and * means repetition.

9 | Page

Username = Name|Digit
Name = First + Middle + Last
First = [a|b|c_ _ _ _ _ _ _|z|A|B|C_ _ _ _ _ _|Z]*
Middle = [a|b|c_ _ _ _ _ _ _|z|A|B|C_ _ _ _ _ _|Z]*
Last = [a|b|c_ _ _ _ _ _ _|z|A|B|C_ _ _ _ _ _|Z]*
Digit=[0|1|2|3|_ _ _ _ _ |9]*
Successful = Done
Unsuccessful = Not Done
Authenticated = Done
Status = Yes/No
Receipt = [Code] + digit + digit + digit + digit + Name
Password = [word] | digit
Word = [0|1|2|3|_ _ _ _ _|9]*

Fig.2.2 Data Dictionary (DD)

3. PROJECT MANAGEMENT
Project management involves the planning, monitoring, and control of the people, process, and
events that occur as software evolves from a preliminary concept to an operational
implementation. Project managers plan, monitor, and control the work of a team of software
engineers. Effective software project management focuses on the four Ps: people, product,
process, and project.

3.1 Function Points

Function-oriented software metrics use a measure of the functionality delivered by the application
as a normalization value. Since, functionality cannot be measured directly; it must be derived
indirectly using other direct measures. Function points are computed by completing the table 4.1.
Five information domain characteristics are determined and counts are provided in the appropriate
table location. Information domain values are defined in the following manner:
Number of user inputs: Each user input that provides distinct application oriented data to the
software is counted. Inputs should be distinguished from inquiries, which are counted separately.
Number of user outputs: Each user output that provides application oriented information to the
user is counted. In this context output refers to reports, screens, error messages, etc. Individual data

10 | P a g e
items within a report are not counted separately.
Number of user inquiries: An inquiry is defined as an on-line input that results in the generation
of some immediate software response in the form of an on-line output. Each distinct inquiry is
counted.
Number of files: Each logical master file (i.e., a logical grouping of data that may be one part of a
large database or a separate file) is counted.
Number of external interfaces: All machine readable interfaces (e.g., data files on storage media)
that are used to transmit information to another system are counted.
Table 3.1
Measurement factors

Weighting factor
Count

Simple

Average

Complex

Number of user inputs

4(2)

Number of user output

5(2)

10

Number of user inquiries

4(3)

12

Number of internal logical files

10(1)

15

10

Number of external interface files

7(2)

10

14

Count total

54

The Fi (i = 1 to 14) are "Complexity Adjustment Values" based on responses to the

following questions:
5
5
3
4
4
5
3
5
1
1
2
3
5

11 | P a g e
1. Does the system require reliable backup and recovery?
2. Are data communications required?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational environment?
6. Does the system require on-line data entry?
7. Does the on-line data entry require the input transaction to be built over multiple?
8. Are the master files updated on-line?
9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organizations?
14. Is the application designed to facilitate change and ease of use by the user?

Once these data have been collected, a complexity value is associated with each count.
Organizations that use function point methods develop criteria for determining whether a particular
entry is simple, average, or complex. To compute function points (FP), the following relationship
is used:
FP = count total *[0.65 + 0.01 * (Fi)]
= 54*(0.65 + 0.01*51)
=54*1.16
=62 (approx.)
Where count total is the sum of all FP entries obtained from Figure.

3.2 ESTIMATING EFFORTS

Barry Boehm introduced a hierarchy of software estimation models bearing the name COCOMO,
for COnstructive COst MOdel. The original COCOMO model became one of the most widely used
and discussed software cost estimation models in the industry. The COCOMO II application
composition model uses object points.
The object point is an indirect software measure that is computed using counts of the no. of screens
(user interface), reports and components likely to be required to build the application. Each object
instance is classified into one of three complexity levels using criteria suggested by Boehm.
Once complexity is determined, the number of screens, reports, and components are weighted. The
object point count is then determined by multiplying the original number of object instances by the
weighting factor in and summing to obtain a total object point count. When component-based
development or general software reuse is to be applied, the percent of reuse (%reuse) is estimated
and the object point count is adjusted:
NOP = (object points) x [(100 -%reuse)/100],
where NOP is defined as new object points.
To derive an estimate of effort based on the computed NOP value, productivity rate must be
derived.
PROD = NOP/person-month
Table 3.1 presents the productivity rate for different levels of developer experience and
development environment maturity. Once the productivity rate has been determined, an estimate of

12 | P a g e
project effort can be derived as
Estimated effort = NOP/PROD
Object type

No. of objects

Screen
Report
3GL component
Object points sum

Complexity Weight
Simple
1(2)
2(2)

4
2
2

Medium
2(2)
5(1)

Difficult
3(1)
8(0)
10(2)

Count

7
9
20
36

Table 3.2 Estimating object points

Data used in estimating effort are:
(1) Object points is 36(taken from table 3.2)
(2) Estimated reuse is 36%
(3) Prod is 13 (average value taken)
NOP = Object points *[(100-reuse%)/100]
= 36*[(100-35)/100]
= 24
ESTIMATED EFFORT = NOP/PROD
= 24/13
= 2 person-months
Hence estimated effort of the project is 2 person-months.

3.3 ESTIMATING SCHEDULE

Putnam and Myers suggest a set of equations derived from the software equation. Minimum
development time is defined as
= 8.14( )0.43 in months for > 6 months
Since projects time period is less than 6 months, the above equation cannot be applied.
An estimation model of the form:
E = [

.333

] ( 4 )

(equation 1)

where E = effort in person-months or person-years

t = project duration in months or years
B = special skills factor
P = productivity parameter
Calculating development time for project, using equation 1 and effort calculated in section 3.2
2 = [1000
t4 =0.06

0.01.333
8000

] ( 4 )

13 | P a g e
Hence estimated schedule of the project is 0.06 months.

3.4 RISK TABLE

A table provides a project manager with a simple technique for risk production. A risk table is
sorted by probability and impact to rank risks. A project team begins by listing all risks in the 1st
column of the table. This can accomplished with the help of the risk item checklist referenced.
Each risk is categorized in the 2nd column. The probability of occurrence of each risk is entered in
the next column of the table.
Next, the impact of each risk is assessed. Each risk component is assessed using the
characterization presented and an impact category is determine. The categories for each of the four
risk components-performance, support, cost and schedule-are averaged to determine an overall
impact value.
Once the first four columns of the risk table have been completed, the table is sorted by probability
and by impact. High-probability, high-impact, risk-impact risks percolate to the top of the table and
low-probability risks drop to the bottom.

Table 3.4 Risk Table

Risk

Category

Probability

Impact

Hacker attack

TE

30%

Environmental
factors
Delivery deadline
will be tightened
Staff
inexperienced

BU

30%

BU

50%

ST

30%

Size
estimates
may
be
significantly low
Staff
turnover
will be high

PS

60%

ST

60%

Less reuse than

planned
Performance

PS

70%

TE

20%

BU

20%

30%

Unavailability of
team members
Reviews may not
be
conducted

BU

RMMM
Appoint experts team to
overcome the situation.
Replication to different data
centres.
Increase the amount of resources
available.
Meet
with
experienced
developer and experts of
projects.
Check the modules and revise
the algorithm
Meet with current staff to
determine causes for turnover.
Assign the backup staff member
for every critical technologist.
Revise the components than to
be used.
Consult
the
experienced
software makers.
Ensure that there is always an
emergency person who can
always take over the task assign
is not available.
Set dates for reviews for each
documentation.

14 | P a g e
regularly
Impact values:
1catastrophic
2critical
3marginal
4negligible

Category
PS: product size
DE: Development environment
ST: staff size

3.5 TIMELINE CHARTS

When creating a software project schedule, the planner begins with a set of task. If automated tools
are used, the work breakdown is input as a task network or task outline. Effort, duration, and start
date are then input for each task. In addition, tasks may be assigned to specific individuals. A
timeline chart, also called a Gantt chart, is generated. A timeline chart can be developed for the
entire project.
Timeline depicts a part of a software project schedule that emphasizes. All project tasks are listed
in the left-hand column. The horizontal bars indicate the duration of each task. When multiple bars
occur at the same time on the calendar, task concurrency is implied. The diamonds indicate
milestones. Once the information necessary for the generation of a timeline chart has been input,
the majority of software project scheduling tools produce project tablesa tabular listing of all
project tasks, their planned and actual start- and end-dates, and a variety of related information.

15 | P a g e

Jan 2013

ID

Feb 2013

Mar 2013

Apr 2013

Task Name
1/13

Identify needs and benefits

Meetings with customer

identify needs and project constraints

Establish product statement

Describe process model

Milestone : product statement defined

Define function inputs and outputs

Document FIO

Review FIO with customers

10

Milestone : FIO defined

11

Start managing the project

12

Compute function points

13

Estimate the efforts of projects

14

Estimate the schedule of project

15

Make the timeline chart

16

Perform risk analysis

17

Milestone : project is managed

18

Define the functions behaviour

19

Describe the design of module

20

Describe attributes of module

21

Write pseudocode of module

22

Milestone : FIO design complete

23

Computing basis path set

24

Milestone : testing complete

1/20

1/27

2/3

2/10

2/17

2/24

3/3

3/10

3/17

3/24

3/31

4/7

4/14

4/21 4/28

Fig.3.5 Timeline chart

4. DESIGN ENGINEERING
The design of a system is essentially a blueprint or a plan for a solution for the system. A design
methodology is a systematic approach to creating a design approach, a system is viewed as a
transformation function, transforming the inputs to the desired outputs.
The design process for software systems often has two levels. At the first level the focus is on
deciding which modules are needed for the system, the specifications of these modules, and how
the modules should be interconnected. This is what is called the system design or top-level design.
In the second level, the internal design of the modules, or how the specifications of the module can

16 | P a g e
be satisfied, is decided. This design level is often called design to contain a more detailed
description of the processing logic and data structures so that the design is sufficiently complete
for coding.

4.1 Architectural Design

For a function-oriented design, the design can be represented graphically
by structure charts. The structure of a program is made up of the modules of that program together
with the interconnections between modules. The structure chart of a program is a graphic
representation of its structure. In a structure chart a module is represented by a box with the
module name written in the box.
During design, Structured Design Methodology aims to control and influence the structure of the
final program. The aim is to design a system so that programs implementing the design would have
a hierarchical structure, with functionally cohesive modules and as few interconnection between
modules as possible.
The overall strategy is to identify the input and output streams and the primary transformations that
have to be performed to produce the output. High level modules are then created to perform these
major activities ,which are later refined. There are four major steps in this strategy:

4.1.1. Restate the problem as a Data Flow Diagram

No extra inputs or outputs are required to be represented in data flow diagram so DFD remains
same as previous.

17 | P a g e
COLLEGE
DATABASE
STUDENT DETAILS

COLLEGE
VOTING
DATABASE

successful

LOG IN

VOTER
AUTHENTICATION

Authentication

VOTING
PROCESS

Username/
password

Voting
done
unsuccessful

HOME
PAGE

LOG OUT

Receipt

USER

USER

Fig. 4.1.1 Data flow diagram for Online Voting.

4.1.2 Identify the Most Abstract Input (MAI) and Most Abstract Output(MAO)
Data Elements
The most abstract input (MAI) data elements are those data elements in the data flow diagram that
are farthest removed from the physical inputs
but can still be considered inputs to the system. The most abstract input data elements often have
little resemblance to the actual physical data.
Most abstract output data elements (MAO) by starting from the outputs in the data flow diagram
and travelling toward the inputs. These are the data elements that are most removed from the actual
outputs but can still be considered outgoing. The MAO data elements may also be considered the
logical output data items, and the transforms in the data flow diagram after these data items are
basically to convert the logical output into a form in which the system is required to produce the
output.

18 | P a g e
COLLEGE
DATABASE.
STUDENT DETAILS

COLLEGE DATABASE.
VOTING DETAILS

MOST
ABSTRACT
INPUT

successful

LOG IN

Username/
password

VOTER
AUTHENTICATION

MOST
ABSTRACT
OUTPUT

Authentication

VOTING
PROCESS
Voting
done

unsuccessful

HOME
PAGE

LOG OUT

Receipt

USER

USER

Figure 4.1.2 DFD with Most Abstract Data Elements

4.1.3 First-level factoring
We first specify a main module, whose purpose is to invoke the subordinates. The main module is
therefore a coordinate module. For each of the most abstract input data items, an immediate
subordinate module to the main module is specified. Each of these modules is an input module,
whose purpose is to deliver to the main module the most abstract data item for which it is created.
Similarly, for each most abstract data item, a subordinate module that is an output module that
accepts data from the main module is specified. Each of the arrows connecting these input and
output subordinate modules is labelled with the respective abstract data item flowing in the proper
direction. Finally, for each central transform, a module subordinate to the main one is specified.
These modules will be transform modules, whose purpose is to accept data from the main module,
and then return the appropriate data back to the main module. The data items coming to a
transform module from the main module are on the incoming arcs of the corresponding transform
in the data flow diagram.

19 | P a g e

vote

ls
tai
de

List of
candidates

ONLINE VOTING
SYSTEM
Ge
tr
ec
eip
t

VOTING
PROCESS

LOGIN

CONFIRMATION
STATUS

Fig.4.1.3 DFD for first level factoring

4.1.4 Factoring of input, output and transform branches

The first-level factoring results in a very high level structure, where each subordinate module has a
lot of processing to do. To simplify these modules, they must be factored into subordinate modules
that will distribute the work of a module. Each of the input, output and transformation modules
must be considered for factoring. A subordinate input module is created for each input data stream
coming into this new central transform, and a subordinate transform module is created for the new
central transform. The new input modules now created can then be factored again, untill the
physical inputs are reached. The factoring of the output modules is symmetrical to the factoring of
the input modules.
The goal is to determine sub transforms that will together compose the overall transform and then
repeat the process for the newly found transforms, until we reach the atomic modules.

Details

Username/
Password

details

Username/
password

ed
at
tic
en
th
Au

Ge
t
de stud
ta en
ils t

LOGIN

Authentication

Fig.4.1.4(a) Factoring of Input module

20 | P a g e

Voting Process
V
s ot
ca ele e fo
nd cte r
id d
at
es

t
lis

Voting

Candidate list

Fig.4.1.4(b) Factoring of Transform Module

eip
ec
tr
Ge

vo
te

CONFIRMATION
STATUS

STATUS

SUCCESSFULLY
VOTED

Fig.4.1.4(c) Factoring of Output Module

4.2 Data Design

Data Design translates the data objects defined in the analysis model into data structure that reside
within the software. The attributes that describe the object, the relationship between data objects
and their use within the program all influence the choice of data structures. At a higher level of
abstraction, data design may lead to the definition of the architecture for a database or a data
warehouse.

21 | P a g e

FILE 4.2(a) STUDENT DETAILS

ATTRIBUTE

DATA TYPE

LENGTH

Char
Char
Char

20
20
20

Char
Char
Char
Char

20
20
20
50

SEX

Char

CONTACT NUMBER

Int

12

PASSWORD

Char

10

AGE

Int

COURSE

Char

20

USERNAME

Char

20

ROLL NUMBER

Int

10

ENROLLMENT NUMER

Int

10

NAME
First Name
Second Name
Last Name
FATHERS NAME
First Name
Second Name
Last Name
ADDRESS

FILE 4.2(b) ADMINISTRATION

ATTRIBUTE

DATA TYPE

LENGTH

USERNAME

Char

20

PASSWORD

Char

20

22 | P a g e

FILE 4.2(c) LOGIN RELATED DETAILS

ATTRIBUTE

DATA TYPE

LENGTH

STUDENT
First Name
Second Name
Last Name
USERNAME

Char
Char
Char
Char

20
20
20
20

PASSWORD

Char

10

ROLL NUMBER

Int

10

4.3 Component-level Design

Component-level design establishes the algorithm detail required to manipulate data structures,
effect communication between software components via their interfaces, and implement the
processing algorithms allocated to each component. Component-level design, also called
procedural design, occurs after data, architectural, and interface
designs have been established. The intent is to translate the design model into operational software.
But the level of abstraction of the existing design model is relatively high, and the abstraction level
of the operational program is low.

PSEUDOCODE:
OVS homepage_Load()
{
DBconnection.Open
Button Login.enable = true
Button Logout.enable = true
}
Button Login_click()
{ Flag =false
Username =InputBox(Enter Your Name)
Password =InputBox(Enter Your Password)
DBStudent_Details.MoveFirst
Do while DBStudent_Details.EOF=false
{ if
DBStudent_Details.Feilds(Username)<>UsernameAnd
DBStudent_Details.Feilds(Password)<>Password
then

23 | P a g e
DbStudent_Details.MoveNext
Else
flag =true
EXIT do
End if
}Loop
if
flag =false
then
MsgBox(Username or Password is not correct)
End if
if
flag =true
then
MsgBox(Login as voter successful)
Voting Process()
End if
}
Voting Process_Load()
{ count_president1= 0
count_president2=0
count_president3=0
count_Vice_president1=0
count_Vice_president2=0
Please select one candidate from each category
{President Candidate:-
if Radiobutton.1=true then
{ President =1
count_president1++
}
else if Radiobutton.2=true then
President=2
count_president2++
}
else if Radiobutton.3=true then
{
President=3
count_president3++
}
End if
Vice President Candidates:-
if Radiobutton.1=true then
{ Vice president =1
count_Vice_president1++

24 | P a g e
}
else if Radiobutton.2=true then
{
Vice president =2
count_Vice_president2++
}
End if
Button Save_click()
{
DBVoting_Details.Feilds(President) =President
DBVoting_Details.Feilds(Vice President) =Vice President
}
MsgBox(Voted Successfully)
}}
Button Logout_click()
{ unload OVShomepage
End
}

Voting Result Load()

{
If(count_president1> count_president2 && count_president1> count_president3)
{
MsgBox(Selected President is , president1)
}
Else if(count_president2> count_president1 && count_president2> count_president3)
{
MsgBox(Selected President is , president2)
}
Else
{
MsgBox(Selected President is , president3)
}
End if
If(count_Vice_president1> count_Vice_president2)
{
MsgBox(Selected Vice President is , Vice president 1)
}
Else
{
MsgBox(Selected Vice President is , Vice president2 )
}
End if

25 | P a g e

5. TESTING
Testing is the process of running a system with the intention of finding errors. Testing enhances the
integrity of a system by detecting deviations in design and errors in the system. Testing aims at
detecting error-prone areas. This helps in the prevention of errors in a system. Testing also adds
value to the product by conforming to the user requirements.
The main purpose of testing is to detect errors and errorprone areas in a system. Testing must be
thorough and well-planned. A partially tested system is as bad as an untested system. And the price
of an untested and under-tested system is high.
The implementation is the final and important phase. It involves user-training, system testing in
order to ensure successful running of the proposed system. The user tests the system and changes
are made according to their needs. The testing involves the testing of the developed system using
various kinds of data. While testing, errors are noted and correctness is the mode.

5.1 FLOWGRAPH
1

2
4

10

11

12

Figure 5.1 Flowgraph

26 | P a g e

5.2 CYCLOMATIC COMPLEXITY

Cyclomatic complexity is a software metric that provides a quantitative measure of the logical
complexity of a program.
In figure, the cyclomatic complexity can be computed by using the algorithm.
1. The number of regions correspond to the cyclomatic complexity
The flow graph has three regions.
2. Cyclomatic complexity , V(G), for a flow graph, G is defined as
V(G)=E-N+2 (where E= no. of edges, N= nodes)
V(G)=13 edges 12 nodes + 2
V(G)= 3
3. Cyclomatic complexity, V(G), for a flow graph G, is also defined as
V(G)=P+1= 2+1= 3

Independent Programs Paths

An independent path is any path through the program that introduces atleast new set of processing
statements or a new condition. When stated in terms of a graph, an independent bpath must move
along atleast one edge that has not traversed before the path is defined.
A set of independent paths flow graph illustrated in figure is :
path 1: 1-2-4-1
path 2: 1-2-3-5-6-7-8-10-12
path 3: 1-2-3-5-6-7-8-9-11-12

27 | P a g e

REFERENCES
Software Engineering- A practitioner's Approach by Roger S. Pressman: 6th edition
McGraw Hill, 2005
An Integrated Approach to Software Engineering by Pankaj Jalote: 3rd edition
Springer, 2005