| Type | Basis | Description | Value |
|---|---|---|---|
| team | work product | Index of Work Products | 2 |
| team | work product | Work Plan | 5 |
| team | methodology | Review Meeting | 16 |
| team | work product | Review Report | 10 |
| team | work product | Architectural Response | 4 |
| team | work product | Updated Architecture | 12 |
| team | work product | Post Mortem Analysis | 8 |
| team | methodology | Use of Version Control | 4 |
| team | methodology | Planning and Management | 4 |
| individual | work product | Prepared Review Notes | 11 |
| individual | work product | Updated Component Design | 12 |
| individual | work product | Quality of Individual Work | 3 |
| individual | methodology | Share of Work | 6 |
| individual | methodology | Schedule Adherence | 3 |
For this project you will:
Standard project activities (like plan development, post-mortem,
and index of work products) should be assigned to different
people (than performed them in previous projects), so that
everyone gets an opportunity to do each of these tasks.
The team that designed that product will be present to
observe and to answer questions, but will have no other
formal role in the process.
WARNING
This is a team project, and most of your individual grades will
be determined by the quality of the team's results. This means that all
of you should be concerned about the quality of all of the work products.
Some of the assigned tasks are intrinsically whole-group activities
(review, architectural response, post-mortem).
Many others, while in principle doable by one person,
will probably have significant input from other team members.
Each major work product should have a primary author,
who works up the basic organization
and personally writes most of the prose.
The author of a work product is expected to gather and
synthesize tributary work from other team members.
Note, however, that since the whole team will be graded
on the quality of each work product, it is only prudent
for the entire team to review any high-value work product
before it is submitted.
The contributions (e.g. measured in hours) of each team member
to each work product should be reflected in the index of
work products, as should be the primary author of each
work product. To be counted as the primary author, you must
have personally written at least 2/3 of the text in the
submitted work-product.
In addition to an overall team grade, a portion of each
individual's grade will be determined by:
This project requires the same general project index, plans
and post-mortems that are part of every project in this class:
This will tell us where to find the files we will grade.
If you use (different versions of)
a single file for multiple deliverables, tell us
which revision number to use for each.
It is expected that this plan will be revised many times
(as your understanding of the problem evolves, and you
respond to unanticipated events). Feel free to update
the plan (with new subversion check-ins) as often as
necessary.
Your plan will be graded on the basis of:
A good plan will ensure that all work is done before the
due date, but allow people a reasonable amount of slack
in when they have to do each particular task. An overly
agressive plan that people won't be able to achieve is
no better than a realistic plan to get the work done late.
Experience has shown that vague plans are easier to create
up-front, but create problems down-stream (when people
turn out to have been unclear about exactly what they were
supposed to do, by when, and in what form they were to
deliver their output). Similarly if you do not specifically
map out the dependency relationships among the tasks, you
may find that your schedule is unrealistic, because it
does not allow sufficient time for sequential tasks.
Individuals will be graded on the extent to which they
were able to perform their work according to the plan
of record.
The project specific grade-ables for this project are:
The review meeting is not a place where reviewers will
study a proposal. Rather it is a meeting where reviewers
will discuss issues they have discovered in their
(already completed) study of that proposal.
Each member of the team (including the facilitator and
scribe) will completely review the submitted project
package, prepare, and check-in to svn, detailed comments.
These will be graded on:
You will conduct a formal review (as described in the reading
and lecture). Your team will be graded on the extent to which
your review ...
The meeting scribe will write up a formal report of your
review session. This report is, most specifically, not a
set of meeting minutes. Rather, it is a distillation of
key issues and decisions. It will be graded on:
This is a final report and should be carefully written, and
well distilled.
This is a summary of the issues to which you had to respond,
and the manner in which you responded to each. The details
of the responses will be found in the updated architectural
and component description. This document is an overview
of the response, that should enable a reader (who is familiar)
with the project to understand (in general terms) how each
issue has been responded to, and should direct them to
the portions of the updated architectural and design
specifications where the details can be found.
This overview will be graded on
I grade for content and not style, and would prefer that
you spend your time organizing your thoughts rather than
formatting documents. My preferred file type for most
work-products is ASCII text (with a reasonable line length).
Some deliverables may be awkward to prepare as ASCII text:
I am telling you the criteria on which I will grade submissions.
I will not, however, give you samples for most of the work products
I expect:
I will, however, suggest a layout for your
Index of Work Products.
I make an exception here because:
3. Assignment
This project involves a great many activities, most of which
require the participation of others and are sequential in nature
(one task cannot be started until other tasks are completed).
If you are to be successful, you will need to devise, and follow
a schedule that spreads this work out over the entire alloted
time.
You may find that the review leaves you with many issues
to respond to, and effective response may require several
iterations of architectural revisions and design analysis.
Make sure you allow yourself suffient time to correct and
redocument your architecture.
SPECIAL WARNING
There are critical interdependencies
between the team whose product is being reviewed and
the team that is conducting the review.
You cannot use late days to defer deliverables owed to
another team:
You must make all of these deliveries on time. Missing
any of these deliveries may result in your receiving a
ZERO for a large portion of this project.
4.Grading
4.1 General Criteria
It should also describe, for each work product:
breaking the project down into sub-tasks, and describing
the interdependencies between them, and who will do which when.
This could be as simple as a dozen tasks with names, dates,
and simple descriptions ... but may find that a more
detailed elaboration gives you a better understanding of
the work to be done and how you will do it.
The team will be graded, as a whole, on its ability to
We will determine when work was done by looking
at the dates of the final subversion check-ins.
Monitoring plans should be included in your
project plan. Problems that come up should be
discussed in your post-mortem.
Detected problems and responses should be discussed
in your post-mortem, and reflected in revisions to
the plan.
4.2 Project Specific Grade-ables
as you go through the process, I will be looking to ensure
that you ...
4.3 Work Product Formats
File Types
If you prepare these using Microsoft Office tools, you can
submit those files as your work-products. If you use other
tools:
The packages you submit for review, and the review report you
return to the team whose product you reviewed should be in a
directly readable form (e.g. pdf and/or ascii text).
Document Format