SmartResponse Final Report

goatishspyMobile - Wireless

Dec 10, 2013 (3 years and 7 months ago)

82 views

SmartResponse Final Report

CSE 379


Fall 2012

Emily Montelione and John Birkholz

Advisor
-

Professor Chuah


Table of Contents:

I.
Executive Summary

II.
Introduction & Motivation

a. What is the Problem?

b. Why is it I
nteresting

and I
mportant?

c.
Our
Solution


d. What are the merits of the proposed solution?

III. Project Planning

a. Client Meetings and Progress Reports

b. Technical Requirements

c. Project Management

IV. Software Design

a. Components

V. Implementation Results

a. Results

b
. Projec
t Schedule

VI. Verification & Validation

a. Verifying Correctness

b. What Was Learned

VII. Documentation

VIII. Future Work

IX. Discussion

I
. Executive Summary:

We created a Moodle block and Android Application that allows professors to gather student
responses instantaneously. The Moodle block has a simple user interface for the professor to fill

in question and answer text. This data is then sent to the MySQL da
tabase using a TCP
connection where it is then retrieved by the Android Application. After a student views the quiz
and submits their response, their name and answer are sent back to the database through a
unicast connection. After all student responses ar
e retrieved and stored, a PHP script
automatically generates graphs representing the results.


II
. Introduction & Motivation:

a
. What is the P
roblem?

Professors often want to administer a class quiz to g
auge students’ understanding

of the
material. Howeve
r, in classes of very large sizes this becomes cumbersome and time
-
consuming. A method is needed to quickly and efficiently gather student responses to current
class material.

b. Why is it Interesting and I
mportant?

Solving this problem would change the
way professors and students can interact with each
other while in class. It can save an immense amount of time while administering quizzes, can
increase class participation with the use of in class practice problems, and can allow the
professor to more eas
ily gauge how well the students understand the material.

c
.
Our Solution


We will create a web site within the Moodle environment. On this web site professors may log
on and create a course web page. Students’ accounts will then be added to this course pag
e.
There will be a feature for the professor to easily input multiple choice questions. Students will
then be able to log into this web page on their Android phone and view the question along with
the answer choices. The student will input their answer by
touching the corresponding area on
the screen. At this point, this response will be sent back to the professor’s account of the web
page so they can view the results.

d
. What are the merits of the proposed solution?

Our solution deals with the original problem as simply and efficiently as possible. With an
incredibly simple and easy to use interface on both the Android Application and the Moodle
web page, we are minimizing the time required for the entire quiz taking
process. A simple TCP
connection between the mySQL database and
the Android server will make the data transfer
very fast and efficient. Also since Android based phones and Moodle based course websites are
both widely used already, our project could easily
be integrated into existing courses.


III. Project Planning:


a. Client Meetings and Progress Reports:



Progress reports will be completed by 12:00pm on Thursday every week.



Face
-
to
-
Face meetings as needed, most likely weekly meetings


b.
Technical Requirem
ents



Development platform:

o

Running Moodle Client on Windows 7




Development environment/software/languages:

o

We have set up a WAMP environment (Windows Apache MySql and PHP). The
languages being used are PHP, mySql
, Java. The Moodle Module will be in PHP.
We will manage the databases with phpMyAdmin in mySql. The Android
Application will be in Java.




Performance Requirements:

o

Our main performance requirement is the real
-
time display of results. Quizzes
responses s
hould be stored in the database and a graphical representation of
results should appear within the Moodle Module in less than 5 seconds.




Resources required:

o

The WAMP environment provides all required resources. The amount of data in
our database will be s
mall and easily stored within the space we have. The
amount of data to be processed at any time is also small so our laptops have
plenty of computing power.




Testing Methods:

o

The system is functioning correctly when:



A user can log into a Moodle Web page a
s a student or professor account



A professor account can create quizzes



A student account can access quizzes from Android application and input
a response.



The correct response is sent to the database.



Accurate statistics are created from these results.



St
atistics are sent back to the students and the professor



c.
Project Management



Project Execution:

o

Set up Moodle platform

o

Create a sample course page

o

Set up professor and student accounts

o

Set up a sample quiz page

o

Set up Android application with access to

quizzes and touch screen feature

o

Set up connection between Moodle and Android

o

Receive signals and store information in Moodle database instantaneously

o

Display results in a user
-
friendly format




Enumeration of Customer Requirements:

o

Sample course page with

professor and students accounts

o

Quiz feature of course page implemented

o

Functioning Android application to view quiz

o

Success sending and receiving of information between application and course
page.




Risk areas

o

Dependence on Moodle platform

o

Device depende
nt implementation of android application




Interfaces:

o

Mobile interface with touch screen navigation and input

o

Web interface based on Moodle environment displaying information of the
database, and creating web pages

















IV. Software Design:


a.

Components:


Android Application:

This is a java based
application

developed

in the Android SDK, and it displays a very
si
m
ple user interface for use by the students. It displays the current quiz and answer

choices,
and then allows the students to select a response and submit it. Feedback is given to the
student if their answer was submitted properly, and if not why.


Moodle Page:

The block on the Moodle page allows for the professor to interface with and ma
nage
quizzes. From Moodle, they are able to create a quiz, submit it, or view past quiz results. After
the quiz has ended, the Moodle block also allows the professor to view graphical statistics
related to how the students responded.


Database:

There is on
ly one database used for this project, and it stores all of the quiz data as well
as responses. The primary data table receives submissions from the students when they are
submitted, and this data is then copied to a new table when the professor chooses to

end and
save the quiz.



V
. Implementation Results:


a. Results:

Our final project structure is displayed in the diagram below. A screenshot of the Moodle block
is shown first with a sample question entered. When submitted, this question is added to the
mySQL database. From the database a PHP script queries the question and sends the question
text and answers to the Android Application. The Android server then sends the student’s
submitted response back to the database. Once all student responses are stor
ed in the
database,
a PHP script queries the different answer responses and creates graphs of the results
similar to those shown in the diagram.







b. Project Schedule:


Our orig
inal Gantt chart is shown below:




Our actual Gantt c
hart is displayed
below:





Planned versus Actual:

The green section displays a portion of the proj
ect that we did not implement due

to changes in
our project design. We decided against having student log
-
ins on the application so the process
of taking the quiz is faster
and more efficient. The red areas represent the tasks that took
longer than we first planned. We had some trouble implementing the TCP connection and took
longer to complete that. Also, the time off at the end of October put us back a few days.
Otherwise w
e stuck to our Gantt chart.



VI
. Verification & Validation:


a. Verifying Correctness:



We united tested along the way, testing the different functions of the android
application and messaging separately.



We tested our code at completion by

o

Testing the
sending of multiple lengths of questions, including extreme cases like
an empty string or an extremely long question.

o

Testing different situations of responses, including extreme cases of a student
clicking send without a response and a student sending mul
tiple answers.

o

Will be test the statistical results created from our databases for accuracy with
many different sets of test data.



We met with our client and provided a demo of our project.


b. What Was Learned:

We learned the importance of testing
throughout the process with unit tests rather than after
we implemented an entire task. Also, as we both were working with languages we were
previously unfamiliar with, experimenting with different approaches and then tested h
elps us
learn this new platfor
m

and languages.



VII
. Documentation:


We thoroughly commented our code. For each PHP script, a simple summary as well as
comments throughout explain the purpose of that script. Also, documentation throughout the
Android code helps one to understand what
each object (Button, text field, etc.) is used for and
where it is used throughout the code.



VIII
. Future Work:

We did fully implement our minimum required project. However, we were not able to
implement our extra deliverables. Moving forward based on f
eedback from judges at the
presentation, some elements to add to improve our project include:

o

Log
-
in accounts for students and professors

o

A way to differentiate between different courses’ quizzes

o

Expand the mobile application to the iOS.

o

Expand the variety

of quiz questions. For example, different numbers of answer
choices, or write in responses.

o

An attendance feature



IX
. Discussion:

Our ultimate goal was to hide as much of the complexity of the quiz taking process from the
students as possible, and to
make the process quick and easy for the professors as well. Our
final product also runs very quickly and automates the grading process for the teacher. A lot
was learned about the entire software engineering process by both group members during the
course
of this project, including scheduling skills, planning ahead, and allowing time for unseen
obstacles. This project also provided a greater overall understanding of inter
-
device
communication and data storage using databases. Creating user interfaces from s
cratch also
gave us a greater understanding of how the average user will interact with our product, and
ways to design better products in the future.