SmartResponse Final - Computer Science & Engineering

advertisement
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 Interesting and Important?
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. Project 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 database 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 are retrieved and stored, a PHP script
automatically generates graphs representing the results.
II. Introduction & Motivation:
a. What is the Problem?
Professors often want to administer a class quiz to gauge students’ understanding of the
material. However, in classes of very large sizes this becomes cumbersome and timeconsuming. A method is needed to quickly and efficiently gather student responses to current
class material.
b. Why is it Interesting and Important?
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 easily 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 page.
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 Requirements

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 should 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 small 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 as 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.
 Statistics 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 dependent 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
simple 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 manage
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 only 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 stored 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 original Gantt chart is shown below:
Our actual Gantt chart is displayed below:
Planned versus Actual:
The green section displays a portion of the project 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 we 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 multiple 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 helps us
learn this new platform 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 feedback from judges at the
presentation, some elements to add to improve our project include:
o
o
o
o
Log-in accounts for students and professors
A way to differentiate between different courses’ quizzes
Expand the mobile application to the iOS.
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 scratch 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.
Download