Milestone Due Dates
Proposal |
Jan 17, 6pm. On paper at the
begining of the class
|
Progress Reports |
Feb 05, Feb 26, 6pm. On paper
at the begining of the class |
In-class Presentation and
Demo |
Wed. March 07. |
Final Written Report |
Wed. March 07, 6pm. On paper at the
begining of the class |
Introduction
For
the project, you will work in
teams of either 4, or 5 students on a problem of your choosing that
is
interesting, significant, and relevant to database topics.
The
ultimate
goal of your course project is to develop a backend to tackle some
interesting
real-world problem. At the end of the quarter, we will hold a
competition
during our regular class time for your project demonstration. All
members of a
group will receive the same grade on group work. Therefore, it is in
your
interest to choose other group members (ideally, first day of the
class) who have the same goal in the class as you do. It is also in
your
interest to work together and ensure that all tasks are completed
effectively. Your
scores on group work may be adjusted based on your contribution.
The
assignment is flexible: choose a topic of interest to you and your
group and carry out a cohesive,
complete project based around it. The range of possible topics that you
can
choose among is broad. However, the project you pick should incorporate
wide range of Database techniques. I think the most
interesting
problems will be ones in which you identify and work with some
"client" to develop a solution to one of their problems. Such clients
can include organizations with which you are involved, work site, etc.
You can
propose to carry out a project as part of a larger effort. However the
caution
here is that you will need to be able to separate out the contribution
made by
this class' project from the rest.
You will need to prepare a written
project proposal and get it approved by the instructor,
project progress
reports, prepare a final report (written),
and give an oral presentation/demo (in class).
Note that evaluations involving human subjects may fall under
IRB requirements.
If
this is the case,
IRB training and submission of the needed proposal can be (indeed,
should be)
included in the work done for the project.
Information
about the
IRB can be found at
http://www.cpp.edu/~research/irb/
Here are some more details about these pieces:
- All
the project reports should be typed and
checked for spelling and grammar. No handwritten reports will be
accepted.
- Projects
will be
group projects (4-5 members, with more members indicating a larger
project.)
- Peer-assessment:
Individual student's grades for projects will be influenced by their
teamwork as evaluated by their project group members. This will be applied
as an overall weight to
the term project grade.
- Demo-evaluation:
There will be an evaluation forms each individual student will need to
submit
for each demo. This
will be factored
into the grade for the in class presentation/demo.
Project
proposal
The proposal should include the
following information: (2
pages or less)
○ Project
participants and email addresses
○ Problem statement
○ Work plan sketch
(what tasks do you expect to do and in
what order, how long do you expect them to take, and who will be
responsible
for the tasks).
● You can take as
much space as you need for the project
report, but I would guess that most would be in the two-page range.
● You need to have
an acceptable proposal submitted by
the deadline.
Progress status report
In this report, you should assess the progress you are making
on your project and update the work plan as necessary. Include your
group's
names and email addresses on this document as well. This is not likely
to be a
long report--just a checkpoint document to make sure you're on a good
track--
towards completing the project in the available time.
A 2-3 page summary of the problem your
project team is solving, and your high-level approach.
Start with your proposal or previous progress report (if any) and add
the following content to your progress report .
The progress summary report should
inform about,
- Design decisions,
- The target audience for the project (who the users are)
- What tools/technologies will you use and why?
- Data Models (ER diagram and ER to relational mapping) - optional
- System architecture and implementation details (if any) - optional
- What is the overall design? What are the core
features?
- How does the database requirements/design satisfy the needs of your users?
- Screen shots of the user interface or a prototype (if any).
- Current Status
- What is the current status of the implementation?
- What is left to do?
Final
written Report
A
comprehensive report describing
the project. This should be a "complete" document, so it should
include front matter (title page, abstract, table of content,
chapters),
problem statement, explain your design and implementation and
evaluation. This report should stand by
itself as the
archival description of the project. It’s
likely to be reasonably large document – four or five pages is too
short! Written
report will be evaluated both on the quality of the project but also on
the
quality, comprehensibility and completeness of the presentation.
- The
report may include portions of your earlier reports (proposal, progress
reports, prototypes, concept, design, etc.).
- The
project report should be typed and checked for spelling and grammar. No
handwritten reports will be accepted.
- Your
evaluation (or evaluation strategy)
- What
are the characteristics of users that you would invite to evaluate this
system?
- What
kind of tasks will you ask them to perform?
- What
metrics will you use to evaluate the success of your system?
- Comparison
with existing applications (which)?
- Performance
measures (how will you measure them)?
- Other
criteria?
- You
should address the same questions as those you have addressed in the
previous
reports, only with more details, especially regarding some of the
challenges
that you need to solve and your experimental results if any.
- You should
also include your conclusions from the study and point out how your
work can be
further extended (i.e., future work).
- References should
list ALL sources that you used for your project. It
is
recommended that you list your references in the APA
style. All team members must be involved in preparing this
section, and provide a list of URL's, books, or other sources that they
used
for the project.
- Provide
as much graphics as
you can—not only UI components, but any kind of diagrams and
illustrations that
will make it easier for us to understand and evaluate your effort.
Graphics are
always helpful, you have probably heard the saying “a
picture is worth a thousand words”!
- Do
not just show the diagrams—for all figures, tables, and diagrams
provide some narrative
discussion! Unfortunately, diagrams, particularly technical
diagrams, are rarely if ever self-explanatory. You should document the
alternative solutions that you considered as well as the arguments for
the
final choice. Diagrams only represent your final solution, but do not
explain
why you decided on this solutions and what alternatives were
considered. Hence, all diagrams must be accompanied
with
explanation
and discussion of alternatives and tradeoffs. Anything that could lead
to
ambiguity or misunderstanding on the reviewer’s part, should be clearly
explained. Explanations should be written in prose and key arguments
highlighted in bullet points.
- There is no
limit on the number of pages
for the report. Of course,
you should avoid stuffing your report with redundant or irrelevant
material.
Final
project presentations / demos
Project
suggestions
There
will be few indutry projects (strict deliverables) available and will
be offered first come first serve. You can also use projects initiated
in previous relevant courses (e.g., IR, HCI, ML or other relevant course) and propose to make
substantial develpment in the current iteration. Also, If you need
suggestions on projects, please see me. There may
be ideas associated with some ongoing research projects that can be
examined.