Sie sind auf Seite 1von 26

SOC 11103

Group Project

Anil Kumar Ponapalli Matr.No: 08800657


Georgios Athanasopoulos Matr.No: 08017978
Thirupathi Reddy Kallem Matr.No: 08800816
Venu Gopal Abburi Matr.No: 08800774

Supervisor: Dr Colin Dougall


Contents

1. System Specifications...................................................................................2
2. System Design and Architecture...................................................................3
3. Component Mining........................................................................................4
4. Component Selection....................................................................................9
5. Component Adaptation...............................................................................11
6. Component Integration...............................................................................12
7. Testing........................................................................................................12
8. System Evaluation, advantages and drawbacks........................................13
1. Introduction

Existing e-Voting Systems

Electronic Voting (e-Voting) systems have been in use since the 1960’s. By
the term e-Voting systems we refer to the combination of electronic
equipment, software, firmware, and documentation required to program,
control and support a system created for voting and generating the vote
results without the necessity of the traditional paper and ballot box layout.
E-Voting systems can be divided in three broad categories
• Punch card systems

• Optical scan voting systems

• Direct-recording electronic (DRE) systems

1 Punch Card Systems

In a punch card system voters have to punch holes on a card that plays the
role of the ballot using a supplied device. Afterwards their vote is fed into a
counting machine in order to produce the results. The first major success for
the punch card e-voting system came in 1965 with Joseph`s P.Harris
Votomatic, a punch card system developed based on the Port-A-Punch
technology by IBM.
The main advantage of this kind of systems is the low cost. But they come
with a serious disadvantage, especially for a voting procedure where integrity
and accuracy are crucial: if we fold, spindle or mutilate the card then there is
chance of losing the data. The same can happen as a result of a partially
punched card.

2. Optical Scan Voting Systems

Optical scan voting systems working principle is similar to the punch card
systems but instead of reading punched ballots, they use optical scanner to
read marked paper. Varieties of optical scan systems are:
• Marksense systems. These systems use optical mark recognition
scanners. Voters have to fill a rectangle, circle or oval box to vote for
their candidate. By that mark scanners can recognise the votes. In
early days various mark sense voting systems have used in a variety of
approaches to count the votes. An example of this category is Votronic
which was introduced in 1965 and had a single photo sensor per
column of marks on the ballot.

• Electronic ballot marker. An EBM (Electronic ballot marker) or BMD


(ballot marking device) is a marking device which allows a voter to cast
his vote by using alternative methods such as audio interfaces,
translated into marks on the ballot. These systems are mainly used in
order to allow disabled users to vote.

• Digital pen voting systems. In this digital pen system we have a digital
paper which is recognized by a small camera in the pen.

Optical scan voting systems are a form of document ballot voting systems,
thus they share the same risks such as the common ballot stuffing. The main
advantage of the optical scan voting systems is their simplicity of use. Voters
don’t need to learn how to use a voting machine since the voting procedure is
similar to the traditional. Another advantage is that these systems can also
allow manual counting of ballots. This feature has a dual positive impact.
Firstly it is a safety valve against electoral fraud. If suspicions occur about the
results electronically produced, the ballots can be recounted by hand to
confirm the outcome. Secondly they allow the voter in case of system
malfunction to cast his vote which will be recorded later, when the problem will
be resolved.

3. DRE Voting Machines

In a direct recording electronic voting system (DRE) the voter indicate his
choice using a computer interface. The input is then translated into data which
can be processed and stored in memory components either locally or at a
central location.
The main advantage of DRE systems is the easy and quick counting they can
provide. As there is no mechanical or human factor involved the tabulation is
immediate and error free. Another advantage is that using a DRE system
eliminates the possibility of undervoting, overvoting or unintentionally casted
blank votes. The system will not accept votes with the wrong choice number
and will inform the user for his error. DRE systems also give solution to the
loss of data due to physical imperfections of the ballot or the reader as can
happen with punch card systems and optical voting systems. Finally DRE
systems provide the most flexible platform to implement alternative voting
methods targeting people with disabilities.
Most of the disadvantages of DREs come from the distrust of the public
against a voting system that they cannot physically verify. Studies have
shown that significant percentage of people express disbelief that a fully
computerized system is totally trustable. This disbelief comes from fears that
the software can be intentionally or unintentionally -due to coding errors-,
produce inaccurate results. DRE systems are software dependent, and such
as, they are always vulnerable to malicious attacks which in the worst case
scenario are undetected. Another problem with DREs is that voters often
express the need to verify that their vote is actually casted and casted
correctly. Without the physical evidence to support this, people don’t know
what “happens” to their ballot after pressing the button. Giving solution to this
problem is not easy since one of the basic requirements of any voting system
is not to provide voting receipts that voters can use to prove to third parties
their choice. An approach to this catch-22 is the use of paper trails, a printout
of the vote that the voter can see and verify but cannot actually take.

Critical review and proposed system

E-voting scene is a diverse and complex environment. Many different


solutions are proposed to tackle major issues occurring. For the development
of our system we must consider the alternatives in a series of different levels
of our design and choose the best suiting approach.
• General system type. The DRE system is a one-way implementation
choice for our solution. The other types of systems require specialized
hardware (punched cards, optical readers) which is not available to us.
But even if we had the possibility of alternatives a DRE approach
would be still our choice. Most of the disadvantages of these systems
come from the human perception rather than the technology itself.
With the correct design and implementation a DRE system can be as
secure as any other system since as we said every type has its own
security risks involved.

• User Authentication. Regarding the user authentication different


approaches have been proposed. One of the most common is the use
of a voting ID card, similar to a credit card, with which the user can
authenticate himself by inserting it at the voting machine. The ID card
approach has some disadvantages. First of all the cost. Cards must be
issued for any registered voter and we must have the required
hardware and software to read these cards. Another problem is that
cards are always possible to get lost or stolen. In this case a third
person could vote in behalf of the card owner. A combination of card-
password could prevent this, but still the person that has lost his card
would not be able to vote. Finally there are documented cases of
electoral fraud with cards being copied or altered.

The other popular approach and the one we are going to use for our
own application, is the authentication through login and password
combination. The user enters his login and password and the input is
then compared with the stored in a database values in order to
authenticate the person. For this approach there is no need of special
hardware, the authentication is easy, fast and secure. The
login/password schema can be differentiated depending on the time
that the registration is done. Our approach to this is that the voters will
have setup their accounts before the start of the voting procedure. We
assume here that the registration authorities have generated and
distributed the login details to the voters beforehand, in a way similar
to the one that banks use to send their clients the ATM card PINs. An
on-the-spot registration could lead to a number of different problems.
In case it was done by the voter himself at the time of voting there
would be the risk of someone impersonating the legal voter and
register in his place. In the case that registration officers were
responsible for this step, during the elections day, it would require an
excess manpower, as officers should deal with the registration at all
voting canters. Either way, an on-the-spot registration would lead to
last minute problems and disrupt the smooth course of the process.

A last approach would be the use of biometric authentication methods


such as fingerprint or iris recognition. This approach however is out of
the bounds of our implementation.

• Data storage. There are two different approaches followed regarding


data storage. Local and centralized. In the local approach the data
from each voting machine are stored in a removable storage device
such as a USB stick or a CD and at the end of the election day they
are either physically transported to a central location where they are
fed to the counting system, or the containing data is transmitted by the
electoral officers of every voting centre. The problem of this approach
is that the removable devices add an extra security risk since they can
be lost, stolen or stop working properly. In these cases there will be
loss of valuable data that can endanger the integrity of the procedure.
Our approach on this issue will be the use of centralized storage.
When a voter cast his vote, the data is transported to a local database
(implemented in SQL for our application) where it will be kept until the
results tabulation. The advantage of this approach is that loss of data
risk is eliminated. The only place that holds valuable data in any given
moment is the central database, where we assume that is sufficiently
secured and reliable.

• User interface. It is important for a system, as an e-voting system,


that is designed to be used from a wide audience, to be as simple and
self explanatory as possible. In our approach we will use a windows-
like menu where we will try to visualise only the completely necessary
interactions. Complex interfaces with extended menus and diverse
navigation paths tend to be confusing and bearing in mind that the
system will be used from people with different technology background
is something that must be avoided. We will follow a horizontal
navigation system and provide clear message screens to help the user
take the appropriate decisions at any moment.

2 System Specifications

To define the specification of our system we present the system requirements


and based on the analysis of them we produce the design to meet them.

2.1 System Requirements

As our system is a simulation of a real voting procedure, most of the


requirements come from the traditional, paper ballot counterpart. Analyzing
the critical aspects of such a procedure, we list our set of requirements as
following:

• Only eligible voters can vote. The eligible voters will be registered.
• The voter must identify himself before the vote. Only if registered he
can proceed to casting his vote.
• The voter can choose any of the candidates.
• Any voter can vote one and only one time.
• The vote must be confidential. There must be no way to link a specific
ballot back to the voter.
• No one, including the system administrators, should be able to
influence the outcome in any way, except by properly voting.
• The results must be accurate and correspond to the casted votes.
• The voter should be able to review his choices and change his vote as
many times he like before casting it.
• No overvoting. The voter cannot vote more candidates than the voting
protocol allows.
• The voter must have the choice to cast a blank ballot if he desires.
• The tally of the votes will be done by the authorized administrator(s)
and by him only. The results must be secured from anyone else.
• The ballot check boxes must be empty when the user begins using the
system so there is no indirect grace of any candidate.
• The system should provide a paper trail on where the voter can verify
that his vote is cast properly but this trail will be discarded automatically
at a proper box and will not be given to the voter. This way he cannot
prove to third parties his choice. This is crucial so to avoid vote buy or
sell.
• The interface must be simple enough so it can be used by computer
illiterate.
• The system must allow the wider audience possible to use it, including
elders and people with disabilities.

With the requirements set, we can now proceed to designing the system in
order to meet these requirements.

2.2 System Design

For any system there is not a unique approach to the designing procedure.
Different requirements can be met by different implementations on different
levels of the design. From the general system architecture, to the class
hierarchy and the user interface. Aim of this stage is to create our system
specifications by taking decisions on all the aspects of the design.

The design diagrams were made using the Enterprise Architect v7.5 software
by Sparx Systems. The database structure diagram was made using the
Visual Studio 2008.

2.2.1 Architecture

The first step to the design is to set our system architecture. We must define
the general structure of the system, the components from which it is
composed and the interactions between them. The diagram of our
architecture is shown in figure 2.1.

Figure 2.1 System Architecture

Our system will be composed from three different sub-systems. The “e-Voting
application” will be the main component with which the end user can interact
in order to access the provided functionalities. The “Counting and Report
System” will be responsible for the ballot tally-up and the report generation
when the voting procedure ends. The “Verification System” realizes the user
authentication functionality.

The “Registration System” can be viewed as another component of the


architecture but it will not be implemented as part of our system as it will not
provide on-the-spot registration of the voters. There will be prior registration of
the eligible voters by the registration authorities. All the voters will have been
sent their login details and the data will have been loaded to the databases
before the voting procedure starts.

There will be three databases that will hold the necessary data for our system.
The first, namely “Voters DB” will contain the details of all the eligible voters.
When a voter casts his vote, he will be removed from this database and will
be moved to the “Already Voted DB”. There is a dual purpose of this layout.
Firstly to ensure that each voter can vote only one time and secondly to keep
track of who has already voted so this data can be used in order to verify the
correctness of the results. It must be noted here that there will be no entry for
the specific choice of each individual. There will be no way to link a ballot to
his voter in order to meet the confidentiality requirement.

The third database will contain the candidate details. This database will be
used from the counting system in order to calculate the votes of each
candidate. Again there will be no link with specific voters voted for the
candidate but it will be held an entry for the vote total. More detailed
presentation of the database structure will be done in chapter 2.4.
2.2.2 Activity Diagram

Continuing to describe our system in more detail we draw the activity diagram
(figure 2.2). This diagram illustrates the steps that can be made during the
use of the application and show the flow of data and control according to the
decisions made.

Figure 2.2 Activity Diagram

By reading the above diagram we can have a good impression of the program
flow. At the beginning the user is asked to enter his login details. The details
inserted are compared against the stored values in the database and
according to the outcome the user is validated. In order to keep the interface
as simple as possible we will not have a separate login option for the
administrator. The administrator will enter his details in the same field as the
other users and if his login/password combination is recognized to be of an
administrator account he is moved to the admin menu from where he can
view the vote results and generate the reports.
If the login details are correct and belong to a voter that has not voted before,
the user is transferred to the choice menu from where he can vote for the
candidate he wants. At the same menu he will have the possibility to cast a
blank ballot if he desires so. The next screen will be a confirmation message
where the system informs the user about his choice and asks him to verify it.
At this step the user can cancel his vote and return to the selection step, or he
can confirm it. In the latter case the vote is actually cast and the databases
are updated. More specifically the voter is removed from the “Voters”
database, he is added to the “Already Voted database” and his vote is cast in
favor of his chosen candidate.

The final step is to print the paper trail and the systems returns to its initial
state and is ready for the next user.

2.2.3 Class Diagram

Moving in designing more specific details about the software structure we


draw the UML class diagram (figure 2.3). In this diagram we show the classes
that compose our application, their attributes, methods and the relationships
between them.
Figure 2.3 Class Diagram

As we can see we have different classes for the administrator and the voter
which both inherit from the parent class user. The reason for this is that while
administrator and voters have completely different functionalities, they share
some common attributes as well as the authentication procedure via the
LoginDetails class.

Another class will be the ballot which despite being simple is important since it
is the link between the voter and the candidate chosen.
The candidate class will realize the counting methods in order to add votes
casted in favor of specific candidate and calculate the results.
The interface class will provide the functionalities for the GUI.

The class design may change or enhanced during the actual development
procedure. Nevertheless, it is a good starting point for the programmer and
gives him the skeleton of the application allowing him to visualize the structure
of the program and the functionalities provided by each one of the different
components.

2.2.4 Database Structure


As we already said in the architecture part we will use three databases for the
needs of our application. One for the registered voters that have not voted yet,
one for the voters that have voted and one for the candidates. In the
registered voters database we will have a table for the voter personal details
link to table for the login details in order to use it for the authentication step.
We assume here that the login provided by the registration officers will be
unique for each voter, thus it will be used as the primary key.

The “VotersAlreadyVoted” table will have the same structure as the registered
voters ones, since it will hold the same kind of data. The reason of having a
separate table is besides using it for recording reasons, to use it in order to
verify the correctness of the results by comparing the number of votes with
the container of this table at the end of the voting procedure.

Finally the table of candidates will hold data for the personal details of the
candidates, including a unique CandidateID which also acts as the primary
key, as well as the number of votes each candidate has. This table is used to
update the voting results each time the system is used and a vote is cast in
favor of someone, and also will be used for the tally up and report generation
at the end of the voting.
A diagram of the database structure as described above can be seen in the
figure 2.4.

Figure 2.4 Database Structure

2.5 Interface Design

The last step in designing our system is to design the user interface. With the
Enterprise Architect we draw two series of screens, one for the voter interface
(fig.2.5) and one for the administrator interface(fig.2.6), where we can get a
clear first idea of how the visual components will be positioned in our final
system and what interaction they will provide to the user.
Figure 2.5 Voter Interface

Figure 2.6 Administrator Interface

Testing can be broadly classified under two terms: verification and validation.
Verification is defined as whether the software implements the specific
function correctly or not. Validation is defined as whether the implemented
software meets the requirements of the customer (or) end user.
There are many kinds of testing types, we are using bottom-up approach and
Black-box testing techniques in our project.
First step into the testing process will be the Unit testing. Each component will
be tested individually for the correctness of the provided functionality. When
the lower level units are ensured to work properly we will proceed to the upper
level and test the system again for the added functionality. This approach
simplifies the testing procedure as it is easier to test individual components
with limited functionality than bigger more complex blocks of code.
Next stage of the testing will be the integration testing. The low level
components will be added together and the resulting sub-system will be
tested again. This procedure will continue until we reach the uppermost level
of the hierarchy. In this stage test will reveal any interface, data manipulation
or communication errors. When all the modules are connected and the
system is complete, we can proceed to the validation testing where we check
if the system meets all the functional requirements.
For each step we will be using black box testing. This involves the creation of
test cases where with a given input we test if the desired output is produced
according to the system specifications.

Methodology

A software development methodology refers to framework that is used to


structure, plan and control the process of developing an information system.
There are a number of different methodologies used for software development
projects, each with its own strengths and weaknesses. The most commonly
used are:
• Waterfall model. In the waterfall model the project is divided into
sequential phases. The development process is linear and each activity
is regarded as concluded before the next activity begins, with the
output of one activity being the input for the next. Waterfall model has
many drawbacks with main one being the difficulty to handle badly
changes. Any design decisions are difficult to reverse and often
problems are not discovered until the system testing.

• Prototyping. The idea behind the prototyping model is to create smaller


working models of the system, at the beginning without the full
functionality, and add functionality in a number of iterative cycles,
creating more complex prototypes. After a number of iterations we will
conclude with the full system.
• Incremental. In the incremental model the functionality of the system is
produced and delivered in small increments. A series of waterfall
cycles are performed for each increment before proceeding to the next.

• Spiral. The spiral model is a type of incremental model. The difference


is its explicit consideration of risk. In solving the problem the parts that
contain the most risk are tackled first, we then incrementally develop
the software by following a series of iterative cycles.

• Rapid Application Development (RAD). Rapid Application Development


is an incremental, iterative process that emphasizes on extremely short
development cycle.

Our approach during the system development will be to use the Rapid
Application Development model. There are many reasons that make RAD the
most fitting model for our purposes. Firstly the key objective of RAD is the fast
development. Given the short, fixed time to complete our project this is a very
desirable feature. Secondly and equally important, is the reduction of project
risk by breaking the project in smaller segments. This way it becomes easier
to manage the project and make any necessary adjustments to the project
plan as the development proceeds. The use of prototyping cycles will allow
the development team to recognize problems early and consider alternatives
if needed. Testing will follow each prototyping cycle to ensure that each of the
components created that far are working as indented, making the final system
testing easier and less likely to reveal problems. In the RAD model are
defined middle delivery time-boxes. If the project begins to lag, emphasis is
put on reducing the requirements rather than delay the submission time. This
is very suitable for our project since we will be facing a strict deadline and at
the same time our goals can be flexible enough to cut off some of our
application complexity.
References
[1] Barry C, Dacey P, Pickering T, Byrne D (n.d.). Electronic Voting and
Electronic Counting of Votes - A status report. available at
http://www.eca.gov.au

[2] CMS Centers of Medicare and Medicaid Services (2005) Selecting a


development approach. Available at http://www.cms.hhs.gov

[3] Ghassan Q. and Rani T. (2006) Electronic voting systems: Requirements,


design, and implementation. Available at http://www.sciencedirect.com

[4] Jarrett B. (2006) Challenging the Norms and Standards of Election


Administration: Electronic Voting, IFES. Available at http://www.ifes.org

[5] Pressman R. (2009) Software Engineering, A Practitioner`s Approach 7th


Edition, McGraw-Mill (chs. 1,6,8,9)

[6] Sommerville I. (2001) Software Engineering 6th Edition, Addison-Wesley


(chs. 3,5,7,10)
Appendix A

A1. Project Proposal

1. Group members

Georgios Athanasopoulos 08017978


Thirupathi Reddy Kallem 08800816
Anil Kumar Ponapalli 08800657
Venu Gopal Abburi 08800774

2. Suggested project title

NapVote. An e-Voting system application.

3. The aims of the project are as follows:

To create a system that will be used for voting electronically. The system will
have a user friendly interface so it can be used from computer-illiterate people
and host security features to ensure the procedure integrity in various fields
such as not to allow double-voting, keep the vote confidential and produce an
accurate, fraud-free result. After the elections are over the system calculates
the results and generate a report.

4. The main challenges will be:

To make a system as close as a real eVoting system possible. Because of the


importance and security risks involved, the existing systems are extremely
sophisticated thus “simulating” such a system will be challenging. The design
of the interface will also be a challenging part of the development, since the
system should be able to be used from people with no computer experience
or people with disabilities.

5. The final deliverable of the project will be:

An application along with the needed databases to implement an eVoting


system. Generated results from a demo voting can be displayed, as well as
the required set of documentation.

6. The project will involve the following background research:

Existing eVoting systems, security issues for such systems, user


authentication, interface design.
A2. Project Plan
The following Gantt chart illustrates the project plan for our group. For the first
part of the coursework we worked parallely and we did two iterations of the
writing procedure. The parallel work procedure is displayed in the chart wih
four diferent lines running in parallel, one for each of the group members. The
two iterations are displayed in the tasks list as (1) and (2).
For the development phase we are going to use Rapid Application
Development. The initial plan is to have two prototyping cycles. Each
development cycle will be followed by a testing one, as displayed in the task
schedule list.
Appendix B. Minutes of the meetings

Minutes of the meeting of 29/09/2009


Main Topics: Team roles definition. First project approach.
Attended: Georgios Athanasopoulos
Thirupati Reddy Kallem
Anil Kumar Ponapalli
Venu Gopal Abburi
At this first meeting of the group we discussed about the roles of each one in
the team. As all the members have similar academic background and
technical knowledge we initially focused on defining the project manager. We
decided that project manager and project leader would be Georgios. For the
first part of the coursework we would all have equal responsibilities as no one
had more specific knowledge of the application field over the rest of the group.
We would refine the responsibilities later during the work advanced.
Next we discussed about the project idea, and the general approach we
would have in order for all the members to have a clear, common image about
the system and our goals.
We agreed that we should make an initial project plan and meet again the
next day to see it and discuss about it. Georgios would prepare it.

Minutes of the meeting of 30/09/2009


Main Topics: Project plan presentation. Communication method.
Attended: Georgios Athanasopoulos
Thirupati Reddy Kallem
Anil Kumar Ponapalli
Venu Gopal Abburi
The group was introduced to the project plan. We reviewed it and discussed
about it. We then exchanged personal details and agreed that communication
would be easy as all the group shares the same teaching timetable and we
meet most of the week days. In case needed we would contact each other
using mail or phone.
We arranged to have regular meetings to discuss the course of the project or
any unscheduled matters raised. The meetings will be held in the university
library unless otherwise stated.

Minutes of the meeting of 02/10/2009 with the group project supervisor


Attended: Supervisor
Georgios Athanasopoulos
Thirupati Reddy Kallem
Anil Kumar Ponapalli
Apologies : Venu Gopal Abburi

We presented to the supervisor our project idea and our initial thoughts about
it.
Discussing about our alternatives for developing such an application we
concluded that the best approach would be to make it a web application using
ASP.NET. Despite the fact that no one from the group has previous
experience on such applications we agreed that this would be a nice
opportunity to learn a new interesting technology.
We arranged to install the necessary environment and tools in our machine
and bring one of the group`s laptops to the next meeting and test the
installation.
Our next meeting was arranged for the Friday 09/10/2009 at 09.30.

Minutes of the meeting of 06/10/2009


Main Topics: Divide responsibilities regarding the submission of the first
coursework part.
Attended: Georgios Athanasopoulos
Thirupati Reddy Kallem
Anil Kumar Ponapalli
Venu Gopal Abburi
At this meeting we divided the responsibilities of each member regarding the
first part of the submission. We agreed that it would be more effective If every
member focused on one part of the coursework, work on it and then share his
information with the others. Having said that, we proposed an initial logical
division of the work and arranged on who would deal with each one: Thirupati
would focus on existing systems, Georgios would focus on the system design,
Anil would focus on testing and Venu on methodology. We arranged that this
phase would be a week long and in our next meeting we would share our
progress with the rest of the group.

Minutes of the meeting of 09/10/2009 with the group project supervisor


Attended: Georgios Athanasopoulos
Thirupati Reddy Kallem
Anil Kumar Ponapalli
Venu Gopal Abburi

The group has installed the essential tools for developing applications in
ASP.NET and we brought one of the machines to the meeting so the
supervisor could check if we had everything we need.
After running a demo application everything seemed correctly installed and
configured.
We set as plan of the following week to focus on the report writing for the first
part of the coursework.
The next meeting was arranged for the Friday 16/10 at 09.30.

Minutes of the meeting of 12/10/2009


Main Topics: Exchange our experience about the focus part of the
coursework each one undertook.
Attended: Georgios Athanasopoulos
Thirupati Reddy Kallem
Anil Kumar Ponapalli
Venu Gopal Abburi
As everyone have focused on a part of the coursework as arranged at the
06/10 meeting, we shared our findings. Each one discussed about their point
of view about their part and then we all together decided on our approach for
each of the parts. We decided to start writing the report continuing on our
focused part as we now had the experience and the sources required, making
any changes that we decided as a team on this meeting.
We agreed that we must have completed our parts until 16/10 so we have the
time to review each other’s work, make any changes required and integrate
everything in a common report.

Minutes of the meeting of 16/10/2009 with the group project supervisor


Attended: Georgios Athanasopoulos
Thirupati Reddy Kallem
Anil Kumar Ponapalli
Venu Gopal Abburi

We discussed our progress on the report with the supervisor. We agreed that
after the submission date we should focus on the application development.
Our next meeting was arranged for the Friday 23/10/2009 at 09.30.

Minutes of the meeting of 16/10/2009


Main Topics: Review the parts of the coursework each one prepared and
arrangements about the final submission.
Attended: Georgios Athanasopoulos
Thirupati Reddy Kallem
Anil Kumar Ponapalli
Venu Gopal Abburi

Each one of the group members brought at the meeting the part of the
coursework he was working on during the previous days. We read each
other`s documents and proposed some changes that should be done. The
following day we would start integrating our parts together and form the final
report until the submission date.

Das könnte Ihnen auch gefallen