CS342 Semester Project: Web based Bug Tracking System
CS342 Semester Project: Web based Bug Tracking System
Spring 2005
In this project you will work as an individual to build a web-based
bug tracking system web site. You will be required to submit
functionality and design documents to complement your project.
The completed project is due last day of class but you will do interim
releases roughly every two weeks during the semester. For these
releases, you can demo in front of the class if you want, but in
general you will demo your project for the instructor.
Goals
My goal with this project is to have you produce something interesting
and useful that makes you learn about the following:
- Java file I/O
- databases
- sockets
- Java Collections (data structures)
- multi-threaded programs
- protocols such as SMTP, POP
- web servers and web page generation
- HTML
- search engines
- statistical pattern matching
- revision control systems (perforce)
- UNIX (your server will run on linux)
Features
There are two predefined levels of completion corresponding to C and B
letter grades, but I will adjust your grade according to the quality
of your project's functionality for those levels. To get an A you
must go significantly beyond the B level and will be judged in
comparison to other students' projects.
You are to write all functionality unless specified otherwise--you
cannot take James or other SMTP code from the web, for example. The
only code you may reuse is Resin, StringTemplate, and Lucene. Any
code you cut/paste must be attributed to the source. Naturally, you
may do "research" on the web by looking at other software, but you
must actually implement all code yourself.
Required Functionality
- store/retrieve a bug entity in the database
- basic web site, page infrastructure
- log in
- registration
- log out
- display bug in web page
- display list of all bugs
- bug entity must contain at least:
- one-liner description/subject/title
- unique identifier (an integer)
- description
- date created
B Level Functionality
- add fields
- bug type (crash, bad result, is-this-really-supposed-to-work-this-way, ...)
- bug status (i.e., fixed, new, rejected),
- project id/name
- submitter
- assign to
- version of the software
- "steps to reproduce" text field
- resolution text field (how you fixed it)
- edit a bug to change any field
- edit user preferences; e.g., email address, passwd, etc..
- allow bugs to be grouped by project
- "cockpit" page(s) to allow creation of new projects, renaming, etc...
- email notification; e.g., email submitter when bug fixed or email
developer when new bug appears
Possible A Level Functionality
Here are some suggestions (not requirements and not exhaustive):
- file attachments; e.g., screen shots, logs, dumps, ...
- a Java GUI version that communicates with your server
- a system to cut down on noise by trying to detect duplicate and
reject bug submissions.
- multiple site "looks"
- allow SQL or other style query to retrieve bug data optionally
allowing them to specify a template for report. Or, could provide a
form that let the user pick fields and such to automatically create an
SQL query and generate a report.
These features are deliberately ill-specified. Part of your
evaluation will be how well you listen in class to the instructor and
the other people concerning feature definition. You are responsible
for listening and recording people's ideas and comments. If you have
questions, you are encouraged to discuss feature definitions (not
actual implementations) with other people and you are encouraged to
discuss the project with the instructor. Again, you are responsible
for defining the features more precisely.
Recall that the other students are your competitors for A-level work.
Your grade will be computed relative to the lead student beyond B-level.
Guidelines
- You will have to release and demonstrate your project on a regular
basis every 2 weeks during the semester. At each release, you must
have a working server. "Almost working" does not count. Imagine that
you are building a site that users will begin to access immediately
after the first release--you cannot release anything in a buggy or
"almost-working" state. Show the working server from the last release
rather than a new one that introduces bugs in the old functionality or
that doesn't work. You can decide on partial functionality but not a
partially implemented server. Every release must be tested and will
optimally have new features even if the features are simplified
versions. You will be graded on how many release dates you hit with
new features.
- As you can see from the list of features, there may be more work
than you can do in the allocated time period. You will need to
prioritize the tasks and then decide which you will do, which you will
simplify, and which you will not do. You may suggest alternative
features or modified features. You may suggest that the instructor is
nuts and a feature cannot be implemented. Your project management
skills will be evaluated in this manner and will affect your grade. A
few groups from last year had excellent code structure and well
written documents, but were graded lower because they had fewer
features than other groups. You must balance beauty with
feature-completeness.
- The project requirements and feature set may change during the
semester in ways that will force fundamental changes in your software.
You must learn to balance speed of coding with flexibility. Your
ability to anticipate change in your code by making it flexible and
your ability to refactor existing code will be evaluated.
- Once you have demonstrated your server at the first release, you
must keep all email and users you add to your system even if it means
writing software to change the schema or other data formats. Learning
to backup your data from mysql is highly recommended. I will be
looking for data continuity.
- You must use perforce's revision control system (a server running on
stargate) when working on this project. I know this complicates life
for those used to working off campus, but part of your grade is how
well you work with others. Revision control is the fundamental
means by which programmers work with each other in the real world.
- As your software will be actually sending email, you must be careful.
You could potentially get into some
kind of trouble if your system started blasting SMTP servers.
This sort of "denial of service" attack could be taken very seriously
by other computers around the net. You must write your software
with "failsafes" that, for example, refuse to send more than 10 emails
a day or something. You are responsible for writing code that does
not cause trouble. This is part of being a real programmer--there are
consequences to errors in your software.
You should expect to generate about 6000 lines of code per project.
Submission
To grade your project, I will evaluate your work with you
demonstrating it during/after class every two weeks. I will normally
ask you to walk me through the code so I can get an idea of your
programming style.
You must demonstrate your software running under linux (though you may
use a PC browser to access the server). In other words, you will need
to be able to compile and run your software with RESIN web server on
linux. I will not accept software that only runs on a PC.
You must also submit in printed form at each release a well-written
summary of your system features, system design, and database schema.
You will update this document as your system progresses. How well and
how thoroughly you write this up is a nontrivial part of your grade
for the project. If you must, have a native English speaker proofread
your summary document and make suggestions.
Grading
Projects will be judged against the C and B levels first. Then, if
you get beyond B level, your project will be judged in comparison to
other projects. The student whose project has few bugs and has the
largest subset of the desired features working is the "lead team".
The evaluation of "quality" is necessarily a subjective measure, but I
will do my best to quantify what I'm looking for and rate you all
according to the same measure. I will have a chart with the list of
features down the left and releases across the top. Each feature will
be rated at each release (if it is complete).
By definition, there is no late project--your last working release
will be considered in lieu of any unfinished project. Missing a
release in order to achieve a better result at the next release is
acceptable once, but remember missing all releases to turn in
a finished project at the end of the semester will yield a poor score.
I will also be evaluating your work in our team meetings.