Computer Science 121 - Project 2c

Module Design

Fall 2007

$Id: proj_2c.m4 141 2007-11-12 21:47:43Z Mark $

Critical Dates

Plan due (midnight) 11/20/2007
You will determine when you want to submit the work products for this phase, but all submissions for this project are due by (midnight) 12/16/2007.

Project Description

Introduction
Deliverables Table
Assignement Details
Grading
Rules and Submission

1. Introduction

Given specifications for a module, and having already prototyped any novel elements (e.g. data collection, and GKrellM monitor integration), preparing the actual detailed module design should be an extremely straight-forward activity ... which is why we did all of that preparation.

In this phase you will work out the details of module structure, flow of control, data structures, and algorithms, and prepare a detailed module design for your GKrellM plug-in.

Detailed module design is something you have done many times before. The goals of this exercise are

to show you how much simpler the design process can be when you have done adequate preparation.
to give you experience preparing a design that is clear enough for someone else to implement.

2. Deliverables

The graded deliverables for this project are summarized in the following table. They are described in greater detail in the assignment descriptions and grading criteria.

Type Basis Description Value

team work product Index of Work Products 1

team work product Module Design 35

team work product Post Mortem Analysis 8

team methodology Use of Version Control 1

team work product Plan for phase activities 1

team methodology Planning and Management 2

Type	Basis	Description	Value
team	work product	Index of Work Products	1
team	work product	Module Design	35
team	work product	Post Mortem Analysis	8
team	methodology	Use of Version Control	1
team	work product	Plan for phase activities	1
team	methodology	Planning and Management	2

3. Assignment

For this phase you will:

figure out (if you did not already do so in phase 1) how you will organize and divide this effort, and specific due dates for individual activities and work-products.
work out all of the details of module structure, flow of control, data structures, and algorithms, and prepare a complete detailed design for your GKrellM plug-in.
conduct a post-mortem of the design process, and write up a report of that review.

4. Grading

Each phase of this project will receive a team grade. Individual grades (for contribution, quality, and schedule management) will be based on the combined deliverables for all of the phases.

4.1 General Criteria

This project requires the same general project index, plans, subversion use, and post-mortems that are part of every project in this class. An overall project plan will have been created in the first phase, but (if it has not yet already been prepared) you will also need to prepare a detailed plan for how the sub-tasks of this phase will be done, by whom, and on what dates.

The team will be graded, as a whole, on its ability to

Perform the work according to the plan.
We will determine when work was done by looking at the dates of the final subversion check-ins.

Monitor progress and detect problems.
Monitoring plans should be included in your project plan. Problems that come up should be discussed in your post-mortem.

Reasonably adjust the plan in response to problems.
Detected problems and responses should be discussed in your post-mortem, and reflected in revisions to the plan.

Individuals will be graded on the extent to which they were able to perform their work according to (a) the original plan or (b) the plan of record.

4.2 Project Specific Grade-ables

The project specific grade-ables for this project are:

Module Design

Your design will be graded on the basis of:
- Are all classes described, and all routines enumerated along with a description of their purpose and (fairly) complete interface specifications?
- Are all non-obvious algorithms explained sufficiently well to enable a correct implementation?
- Are the purposes, contents, and uses of all non-trivial instance data and data structures described?
- The general reasonableness and understandability of the proposed design.
- The overall understandability, buildability, and likelihood of the design to work.
Post Mortem

Reflect and review the way you organized and conducted the design effort:
- How did you estimate and manage the design process?
- How well did the specifications (and prototypes) developed in the previous phase prepare you for the design.
- How did the process of elaborating the detailed design go?
- Evaluate this activity as a pedagogical exercise.

4.3 Work Product Formats

The standard guidelines for work product formats apply.

5. Rules and Submissions

When you are done, create a message that includes:

the name of your team
the names of your team members
if you are using any slip days, how many from whom
the URL for your subversion repository
your index of work products

And submit all of these things to me in an e-mail with the subject "cs 121 - Project 2c".

If you will be submitting your project late, please let me know (so that I know I haven't lost your submission message).

Collaboration and Citation

This is a team project, but different individuals will have primary responsibility for different processes or work products (or different parts of a single work product or process). Each team will be working on a different type of product. You are free to talk your team members (and for that matter other teams) about the processes you are following. You may review your work products with your own team members, and revise them based on their feedback ... but ...

If you are the primary author of a work-product, you must cite the source of text you did not write (if it is more than a sentence), or any information that did not originate within your team or from your interviews.
You will be doing research to develop your product definition and requirements. I expect that many of the ideas for your product will come from this research. Cite all of your sources for each work product, and explain how each source contributed to your work products.
You may not share any of your work products (other than as required for reviews) with members of other teams.