It is time to start thinking about class projects!
Here is the schedule of deadlines:
- now: project shopping.
- March 29: project proposal.
- April 5: design proposal.
- April 12: design refinement.
- April 19: demos begin!
- May 3: final design report due.
- May 14-16: Expo
We will have some time in class for people to present project ideas,
with the goal of getting suggestions from the class and possibly
finding people with similar interests to work with. You can also post
messages on the class mailing list, firstname.lastname@example.org, either looking for people or ideas.
Your proposal should be a short document (1-2 pages) with answers
to the following questions:
- Who's in the group?
- What's the project?
- What's the minimum/maximum deliverable?
- What's your first step?
- What's the biggest problem you foresee or question you
need to answer to get started?
You should turn in one copy of your proposal for each project group.
As the project proceeds, you will be editing this document and turning
A note on style: The documents you turn in at various stages do not
have to be complete, or polished, or formatted beautifully. Think
of them as successive drafts of the final report. But please don't
take that as a license to make them incoherent, or verbose, or silly.
You should try to present your ideas clearly and concisely, with the
goal of producing a final report that you would be proud to show to
the outside world.
At this point in the project you should have at least a rough idea of
the design you are planning to implement, you should have chosen the
packages you will use, and be familiar with them, and you should have
written some code that at least tests out the packages. You might also
have a prototype of some kind.
The design proposal should explain at least one part of your design
by telling a story. The structure of the story should be something
- Here is a problem that we want to address.
- Here are two or three ways we considered addressing it.
- Here is the one we chose (at least provisionally) and why.
You don't have to document every design decision you made, but you
should choose at least one that you think is interesting.
Also, your design proposal must include both a UML Class diagram and
a UML Object diagram. If there are no classes or objects in your
design, that might be a sign that you need to rethink your design,
or your project!
Some projects may not involve any significant data structures or
algorithms, but if yours does, you should describe them at an
appropriate level of abstraction.
Finally, your proposal should include a development plan. What have
you done so far, and how do you plan to proceed? How will the work be
divided among the members of the team? If you are planning to split
up the work, how will you manage the interfaces between the parts of
the project? If you are planning to specialize, I suggest that you
make some effort to ensure that all members of the team understand all
parts of the design at an appropriate level of abstraction.
Reminder: this status report should include material from the previous
report, updated and refined.
At this point you should have at least a prototype, and possibly
you will have achieved your minimum deliverable. You should turn in an
updated version of your design proposal that includes any improvements
I might have suggested during the previous iteration, and any
refinements you have made in your design.
In particular, I would like to know if there are any significant
changes you made in the design while you were in the process of
implementing it, and why. Examples might include:
- You added new classes to the design, or consolidated classes,
or changed the relationships among the classes.
- You discovered a performance problem and changed
your data structures and/or algorithms.
- You started out with the intention of using some package,
but you needed something it didn't have or you found something better.
Also, this report should include a discussion of abstraction and
language. As you develop your design, you should find yourself
developing abstractions (like new classes and collections of functions
and methods) and vocabulary for talking about your program, and for
expressing the computation that makes up your program. What are the
elements of this language, and how are they reflected in your design?
Reminder: this status report should include material from the previous
reports, updated and refined.
Your final report should include the following elements:
- All the elements from the previous documents, edited to
bring them up to date. Sections that are no longer relevant
can be removed.
- A final refinement of the design, including any changes
since the previous iteration and an explanation of why the change
- An analysis of the outcome. Did you achieve your minimum
deliverable? If not, why not? Did you achieve your maximum
deliverable? If so, what went right (that is, why was the project
easier to complete than you thought)?
- A reflection on your design. What was the best decision
that you made? What would you do differently next time?
- A reflection on the division of labor. Were you able to
divide the project in a way that allowed the members of the team
to work independently and then integrate their work into a whole?
- Bug report: what was the most difficult bug you had to find?
How did the bug manifest itself? What did you do to find it?
How long did it take? What was the cause of the problem? In
retrospect, what could you have done to find it faster?
Of course, the organization of these elements will depend on your
project, and some may more more applicable than others.
During the last week or two of class, you will have the opportunity
to demonstrate your project for the class.
We will figure out the schedule later, but you should aim to be
ready to demonstrate your minimum deliverable on April 19.
Depending on what else you are doing this semester, you might choose
to present your Software Design project at Expo. If so, then each
member of the team will make an individual presentation. It is
possible that only some members of the team will present this project.
If you choose to present your project as a poster, it should
include a description of the project as a whole, and also an explanation
of what part of the project you worked on. This part of the poster
should be targeted to a general audience with no programming experience.
Your poster should also include an explanation of at least one design
decision; this part of the poster can be targeted to an audience of
In my opinion, the most important criterion of a good poster is that
it should pass the 15-second test. Someone should be able to walk up
to your poster, know immediately where to start reading, and, in the
first 15 seconds, they should learn what kind of project it is (that
is, a software design project), who worked on it, and what you did.
After that (unfortunately) most people will walk away. For the ones
who stay, your poster should tell a short, coherent story about your
project. The flow of the poster should be obvious (that is, what
to read first, and so on) and there should be a small number of
conclusions (like one) that are clear and apparent. The total number
of words should be small. The figures should be clearly labeled,
and there should be text that explains what the figures are meant
to show. You should design the poster as if you will not be there to