Assignment 10: In the beginning...
Out on:
April 16, 2008
Due by:
April 21, 2008, noon (before lecture)
Collaboration:
Team
Grading:
Packaging 10%,
Style 20%, Design 30%, Functionality 40%
Overview
The tenth assignment is the first part of your final project for the course. It describes the general expectations we have but many of the details will probably be discussed in lecture and on the discussion list, so attend lectures and read your email every other hour. :-)
Since you are working in teams now, it's important
that you coordinate your schedules
and stay in touch during the
assignment.
Working together (physically!), either in a lab or
at a laptop in a cafe somewhere, is
highly encouraged!
(Most programming problems are solved by talking
about them, I do the same thing myself when I
can't figure out what I am doing wrong...)
After the assignment is over,
each of you will be asked to
evaluate
the contribution your partner and yourself made to the
assignment.
Each member of a team will receive the same score for
the product you submit together.
Decide early on who is going to be responsible for submitting
the assignment and when!
Make sure to include all the relevant information (who is in the
team?) in your README file!
Problem 1: Project Planning (50%)
Your first task for this assignment is to think through the requirements provided by Peter and to "sketch out" two very different things:
- You have to provide a summary of how users will interact with the web application you are building. You can either do this in textual form, or you can provide an actual sketch in PDF format, up to you.
- You have to summarize how you imagine the remaining weeks of the semester to work out, that is, describe what milestones you will be aiming for with the project, by when you think these will be done, and what you expect to have to do to reach each milestone.
The web application summary should clearly show what options each type of user has after logging into the system, how users navigate from page to page and what happens to the underlying database, etc. You do not have to provide all the details here, but a rough overview of the major tasks users of various types can perform is required.
The project summary should show how you plan to achieve the things you're describing in the web appliation summary. For example, it should include which features you plan to build first and why, what development tasks you think each step will entail, and how you're going to split up the work. Note that too much "splitting" is bad, maybe you should split to pairs of people, not individuals.
Problem 2: Project Prototype (50%)
The second task for this assignment is to build a first, very simple version of your web application. The simplest one that is acceptable is one that has a title/login page and that can be used to either register a new account or login to an existing account.
Ideally you will already be able to do a little more, for example students will be able to invite others in the same course to join them for an assignment that has been set up previously by the instructor. Since there is very little time left in the semester, you're encouraged to go at least this far, but if all you can get done is the registration and login stuff above, so be it.
If you can get even more done for the first assignment, that would be even better! :-)
Note that the details of what the system is about will be explained by Peter in lecture and on the mailing list. A first draft should be on the mailing list today (Wednesday, April 16, 2008). Keep your eyes peeled and ask questions about anything Peter posts in this regard. He's now a "customer" with a problem to solve and you are "software engineers" trying to find out what exactly he wants. Interaction will be necessary to find out what you need to do, don't expect the things he says on the mailing list to be (a) well thought out or (b) useful for you from the get-go.
Hints
- All team members should participate in all tasks, otherwise you'll always have someone without clue asking you how a certain trivial aspect of your project works or will work. Not a fun way to spend your time...
- Take advantage of the infrastructure we provide for your team, namely the discussion list (which now also serves are your "internal" coordination mechanism) and your own Subversion repository. These two things can really help if used appropriately, especially when you can't physically work together for some reason.
Deliverables
Please turn in a
gzip
compressed
tarball
of your assignment;
the filename should be
cs102-assign-10-webbers.tar.gz
(since webbers is the code name of your team).
The tarball should contain no derived files whatsoever
(i.e. no executable files),
but allow building all derived files.
Include a README file (a plain Unix text file) that
contains your answers to written problems, briefly explains what
your programs do, and has any other notes you want us to check
out before grading.
Grading
For reference, here is a short explanation of the grading criteria.
Packaging refers to the proper organization of the
stuff you hand in, following the guidelines for Deliverables above.
Style refers to programming style, including
things like consistent indentation, appropriate identifiers,
useful comments, suitable documentation, etc.
Simple, clean, readable code is what you should be aiming for.
Performance refers to how fast your program can
produce the required results compared to other submissions.
Design refers to proper modularization and the
proper choice of algorithms and data structures.
Functionality refers to your programs being
able to do what they should according to the specification
given above; if the specification is ambiguous and you had
to make a certain choice, defend that choice in your
README file.
If your programs cannot be built/run you will get no points whatsoever. If your programs fail miserably even once, i.e. terminate with an exception of any kind or dump core, we will take off 10%. Finally, make sure to include your name and email address in every file you turn in!
Bonus Problem
The project you have is problem enough. :-)
