Assignment 9: Stable and Efficient Frontiers
Out on:
April 21, 2008
Due by:
May 2, 2008, before midnight
Collaboration:
Teams
Grading:
Packaging 10%, Style 10%, Performance 10%,
Design 10%, Functionality 60%
Overview
The ninth and fina assignment for is all about finishing your final project. 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: Profiling Automation (30%)
You need to improve your existing build and test process
by integrating the gprof tool to measure the
performance of your code and look for bottlenecks.
The goal is to add specific test cases that focus on the
performance of your system, to evaluate them automatically
using gprof, and to optimize system performance to whatever
degree is sensible.
Modify your automated build processes to include performance
evaluation as well!
You must submit all your automation scripts and a short description of your automation setup when you turn in your project!
Problem 2: Stable Implementation (70%)
The most important part of this assignment is that you develop a stable 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 never ever crash or hang or lose data or whatnot!
Deliverables
Please turn in a
gzip
compressed
tarball
of your assignment;
the filename should be
the filename should be
cs211-assign-9-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!
