Exam Generator Oral Presentationx


Nov 17, 2013 (3 years and 4 months ago)



James Domagalski

in Partial Fulfillment of the

Requirements for the Degree of

Master of Software Engineering

October 18, 2010


I would like to express my sincere thanks to my
project advisors Dr. Kenny Hunt and Dr. Kasi
Periyasamy for their guidance

I would also like to express my thanks to the
Computer Science Department and the
University of Wisconsin
La Crosse for providing
the knowledge and tools for completing the

Finally, I wish to thank my friends and family for
their patience and encouragement throughout
the project’s tenure


Faculty members at education institutions look
for ways to properly evaluate their students
understanding of a course’s content

Multiple choice exams is a proven method for
doing so.

Creating exams can be a time consuming

To create an exam, a faculty member must :

Create the document

Properly format it

Keep questions choices next to their questions.

Keep question references, such as tables, bodies of text or
images next to the questions that refer to them.


Using exams for evaluating knowledge comes
with the risk of students cheating on that exam.

Having each student within a course take multiple
versions of the same exam can discourage
cheating on the exam

Prevents students from viewing his or her neighbors exam
for answers

However, creating

multiple versions of the same
exam can be a time consuming process

Faculty member must take a created exam and rearrange
the questions


A students may not have a proper means of
preparing for it.

To help these students, faculty members may
create practice exams that can be taken by the
student on their own time.

Though this can aid the student in preparing, it
creates more work for the faculty member.

Faculty member still must create the practice exam

Faculty member needs to distribute the practice exam to
the students, either by printing it, emailing it, hosting it on
a web site.


If faculty members did not have to worry
about managing and formatting the
exam, more time could be spent
improving the quality of the questions on
the exam.


The idea of the Exam Generator was to develop a
web application that would do the following.

Aid faculty members in creating multiple choice exams.

Easy means of storing questions for future retrieval

Easy means of creating and properly formatted exams

Easy means of randomizing an exam.

Easy means of automatically generating an exam using
created questions.

Provide students the ability of taking online practice

Allow a student to search for and take a practice exam that
has already been prepared by a faculty member.

Auto generate an exam using questions that a faculty member
had shared with the student.



Either true false or multiple choice question.

Contains the question text and a list of correct and incorrect
choices that can be selected for answering the question.

Exam Question

Question stored in an Exam.

Contains all the same information as a Question does. (A Copy )

Exam Question Group

Grouping of questions on an exam.

Grouping is determined by Question Reference


Collection Exam Question Groups



An image, table, or body of text that is referred to by a


Classification for References, Questions, and Exams.

Used for searching for References, Questions, and Exams in the


Person who has access to the Exam Generator

Account Type

Role within applications that belongs to a certain grouping of
functionality within the application.


No one development life cycle model was
used for creation of Exam Generator.

Used a combination of

Waterfall Model

An Iterative Development Model

A Prototyping Model

Combination of the three models allowed
the developer to receive the benefits from


Waterfall Model

Use within Project :

Used in gathering all of the requirements for the
application at the beginning of the development of
the application.

Benefits :

Allowed the developer to know all of the
requirements before designing and coding

Allowed the developer to make better decisions in
the development stage.


Iterative Development

Use within Project :

Used multiple cycles of designing, coding, and testing to
develop the application

Benefits :

Developer was able to implement smaller portions of
requirements instead of implementing all of the
requirements at a giving time.

Allowed the developer to spot potential weaknesses within
the design and code earlier in the development stages,
rather than the testing stage in the waterfall model


Evolutionary Prototyping

Use within Project :

After each iteration of designing, coding, and testing, the
developer demoed the application.

Customer gave feedback to user

Benefits :

If the customer did not like how the application fulfilled a
set of requirements, the developer could redesign and
recode the application to the customer’s liking within that
current iteration of development.


Image of life cycle model used for

Test Final
Go Live with
Demo to

Multiple meetings were held and emails exchanged
between the developer and the customer in order to
gather the requirements for the Exam Generator

The customer for the application was Dr. Kenny Hunt
from UW
La Crosse.

Gathering of requirements occurred throughout the
Spring 2008 until fall of 2009

Meetings ranged from thirty minutes to a hour.

During this time, the requirements was placed within
a requirements document.


The requirements document provides a complete
description of all functions and specifications
that are to be found within the application

The completed requirements document contains
a total of thirty nine requirements

Thirty four requirements are functional requirements.

Remainder of the requirements are non functional.

Three UML Use Case diagrams were included
within the document to aid in the understanding
of the requirements.


Functional requirements are grouped by the user
account types that would exist within the system

Each functional requirement within the requirements
document contains the following:

an index that assigns a unique name to the functional

a descriptive name

a purpose (a short description of the requirement)

input parameters (valid input for the requirement)

output parameters (valid output for the requirement)

actions ( a set of tasks or activities that must be performed in
order to satisfy this requirement)

exceptions (set of conditions that indicate a situation in which
the function will stop)

remarks that explain more about the functionality

references to other functional requirements that are
related to the current function




Non functional requirements do not have
any specific format within the
requirements document

The four Non functional requirements
describe requirements in




Software Quality


Three UML use case diagrams are placed
within the requirements document.

Each diagram covers functionality that is
provided for one user account types.

Diagrams work in conjunction with the
functional requirements listed in the





Exam Generator was developed as a Java

Both the developer and customer was familiar with Java

Familiarity would help with development and future
maintenance of the application by both the developer
and customer.

Tools used for development were

Eclipse IDE w/




Tomcat Application Web Server

Seam Framework (Web Application Framework)

Hibernate and JPA Persistence ( Relational DB


(PDF Creator)


There were four major development iterations
for the Exam Generator which occurred between
fall 2009 through fall of 2010.

Within each iteration the developer fulfilled a
subset of the functional requirements by :

Updating the design document to incorporate the new

Coding the new requirements into the current code base

Testing the implemented requirements

Demoing the application to the customer.

The iteration was complete when the subset of
the requirements were fully developed and
approved by the customer.


Iteration 1

Implemented overall design for application

Implemented authentication into and out of application

This included creating notion of an user, but not providing
functionality for creating and editing user.

Implemented Categories, Questions, and References.

Create, edit, delete, search for each

Questions could be shared with specific users or users of a specific
account type.

Iteration 2

Implemented notion of an Exam.

Create, edit, delete, search

Implemented adding and removing questions

Implemented printing exam and its answers sheet to PDF file


Iteration 3

Implemented administrator functionality

creating, edit, delete, search users

Implemented random generation of exam

Implemented randomization of current exam

Iteration 4

Implemented Student functionality

Search for exams

Randomly create an exam

Take online Exam


The design document contains object
design for the Exam Generator.

The document was created in the first
development iteration and updated in the
following iterations.

The document includes:

Class definitions for all classes found within the entity
and session layer designs.

Two UML class diagrams aiding in the description of the
entity layer and session layer designs

A UML Entity Relationship Diagram describing the
database design


For each Java class within the Exam
Generator, there exists a class definition.

Each class definition contains :

Class Header describing what is included in the

All of the methods that can be found within that class

A total of thirty six class definitions are
found within the design document.


Class Definitions : Header Description


Class Definitions : Method Description







Testing on the Exam Generator occurred within
each development iteration.

Testing occurred before demoing the new
implemented requirements to the customer.

Testing included

Creating and updating a test plan with new tests that
pertain to the implemented requirements.

Following the test plan and ensuring all implemented
requirements worked as desired

Issues found within the testing stage were fixed
within the same development iteration.



The Exam Generator was demoed to the customer
after the testing stage in each development iteration

Application was demoed in two ways

First two iterations

The developer held meetings with the customer, physically walking
through the newly created functionality.

The last two iterations,

The developer hosted the application on the web server and the
customer logged in and individually used the application.

After each demo, feedback was gathered from the

Feedback was then used to improve the application
within the next iteration of development.


No ability to dynamically update
questions on exams

If a question is updated, and that question
belongs on an Exam as an Exam Question, the
Exam Question will not be updated.

If user wants the updated question, the old
question must be removed from the exam, and
then added to the Exam

Future work could inform the user that the
Question has been updated when the user views
the Exam.


Faculty Members currently receive no
notifications informing them that a
student has taken one of his or her own
exams as a practice exam.

An emailing system or user dash board can be
created so that if a exam was taking as a practice
exam by a student, the faculty member would be

A flag can be added to Exams to allow Faculty
member to mark the Exams they would like to
receive notifications on.


Click Here