Assignment 8: Staking the Final Frontier
Out on:
April 7, 2008
Due by:
April 21, 2008, 11:00 am (before lecture)
Collaboration:
Teams
Grading:
Packaging 10%, Style 10%, Performance 10%,
Design 10%, Functionality 60%
Overview
The eighth (sp?) assignment for is all about getting your final project into a state where it mostly does the things you had planned at the proposal stage. Note that some parts of this assignment are (again) not really about actual code. You'll see... :-)
This is a team assignment, and all of you should
know which team you're in (I hope).
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!
Decide on a schedule early on as well, nothing delays working
in a team more than having to schedule meetings ad-hoc; compare
your schedules and arrange to meet in advance!
All members of a team will receive the same score for the project
you submit together.
After the assignment is over, each of you will be asked to
evaluate
the contribution your partners and yourself made to the assignment.
Problem 1: Covering Automation (30%)
You need to improve your existing build and test process
by integrating the gcov tool to measure test
coverage.
The goal is to have enough test cases (and ideally automated
ones, hint hint!) to show that you achieve 100% line coverage
for your code.
While this doesn't mean that you're "done" with testing, it is
simple way to make sure that you're not missing anything trivially
obvious anymore.
Your second task is to modify the nightly build process to actually send a concise (!) log of the build and the automated tests to your team's mailing list. This way it should be easy to tell who broke a certain build and you can collectively go after that person; on the other hand, if everything's fine, it's reassuring to get a nice "all clear" message in the morning. :-)
Finally, if for some reason your last submission did not yet conform
to the "ideals" set in Problem 2 on the previous assignment, please
"round things out" in a suitable way for this assignment.
As a tiny reminder:
You should have everything related to the project in
Subversion
(except for derived files of course),
you should use make or a similar tool to
automate building and (to the extent possible) testing,
you should use cron to regularly run
a clean build and all your tests, you should have easily accessible
developer documentation, maybe out of
doxygen;
feel free to write scripts to help
with any or all of these tasks.
You must submit all your automation scripts and a short description of your automation setup when you turn in your project!
Problem 2: Working Implementation (70%)
The most important part of this assignment is that you develop a mostly working implementation of your project as it was outlined in your proposal. What exactly that is depends on what your project is, but whatever the outcome of this assignment, it should run and it really work. It might still not have all the features you want, but it should have most; and it should definitely be recognizable as the product you had set out to develop.
Deliverables
Please turn in a
gzip
compressed
tarball
of your assignment;
the filename should be
the filename should be
cs211-assign-8-teamcode.tar.gz
with teamcode replaced by the code
assigned to your team for your repository and your mailing list.
The tarball should contain no derived files whatsoever
(i.e. no executable files),
but allow building all derived files.
In particular, make sure you don't submit all those
.svn folders from your repository!
Include a README file that briefly explains what your
programs do and contains any other notes you want us to check out
before grading.
We expect that your Makefile handles "the usual" targets
like clean and test aside from all
(which is the main way we will build your program).
Include other "common" files such as INSTALL describing
how to install your tool, CREDITS to pay your respects
to the people whose code you're reusing, and LICENSE
to describe copyright and distribution terms if you feel like it.
You can look at any number of "famous" open source projects to see
what kind of structure is appropriate;
gif2png
is a relatively small example, but you don't need everything in
there.
Aside from your code, what you really need is a README
and a Makefile that works. :-)
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 C 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 the amount of resources
your program needs to produce the required results; this can
include space, time, and other metrics.
Design refers to proper modularization and the
proper choice of algorithms and data structures; often this can
be judged by asking "How hard would it be to add feature X?"
and "How hard is it to replace algorithm X with algorithm Y?".
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 the specification is too general
and you had to add certain restrictions, defend those in your
README file as well.
If your programs cannot be built on ugradx.cs.jhu.edu
you will get no points whatsoever.
If your programs cannot be built without warnings using
gcc -ansi -pedantic -Wall -Wextra -std=c99 -O
we will take off 10% (except if you document a very good reason).
If your programs cannot be built using make we will
take off 10%.
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!
