Computer Science 121 - Project 2a

Concept & Schedule

Fall 2007

$Id: proj_2a.m4 136 2007-11-07 18:01:29Z 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

GKrellM (pronouced G-krell-M) is an exensible and highly configurable system monitoring tool. You can find a great deal of information on the GKrellM web site. GKrellM includes a wide range of system activity monitors, ranging from basic system performance (CPU, network, disk, memory) to computer status (temperature, fan-speeds, battery status). Perhaps more interesting, however, is the fact that it is designed to incorporate an open ended set dynamically addable monitoring plug-ins. A summary of recent contributions can be found in the GKrellM Plugin registry.

In this phase, you will

come up with, and prove the viability of a concept for a GKrellM information collection and display plug-in module.
develop a schedule for the remainder of the project.

This schedule will be more complex than those you have prepared before, because it will involve many activities and deliverables, spread over a wider period of time, and potentially more intricate divisions of responsibilities. This will be an acid test of your abilities to intelligently plan and carry out a complex group endeavor.

2. Deliverables

The graded deliverables for this project are summarized in the following table. All 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 Plug-in Concept 5

team work product Proof-of-Concept 3

team work product Work Plan 5

team methodology Use of Version Control 1

Type	Basis	Description	Value
team	work product	Index of Work Products	1
team	work product	Plug-in Concept	5
team	work product	Proof-of-Concept	3
team	work product	Work Plan	5
team	methodology	Use of Version Control	1

3. Assignment

For this (initial planning phase) you will:

review the descriptions of all of the phases of this project.
come up with a plan and schedule for carrying out each phase of the project, creating all of the required work products, and dividing that work among your team members, and check this plan in by the required plan date.
Note that this plan only needs to assign starting and ending dates, and primary contributors for each phase. You can (and may get benefit from) preparing a more detailed plan up-front, but the details of how and when the individual sub-tasks in each phase are performed do not have to be prepared until the start of each phase.
come up with a basic concept for a GKrellM plug-in, what information it will gather, what it will display, how it will gather it, the form in which it will be displayed, and any key details about configuration, control and processing.
ensure the buildability of your plug-in by doing a quick (and dirty) proof of concept to collect the information you plan to display.

WARNING

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.

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, subversion use, and project plan updates that are part of every project in this class. This phase is so simple that there will be no post-mortem for it.

4.2 Project Specific Grade-ables

There are two project specific grade-ables for this phase:

New Plug-in Concept

This is a brief (e.g. a single page) description of:
1. The information that will be gathered, and (if it is not obvious) why that information is interesting.
2. The general technique that will be used to gather the necessary information.
3. How the information will be stored, managed, and/or processed to produce the desired displays.
4. The forms in which the information will be presented (e.g. a chart per ski resort of the snow depth, each morning, for a scalable number of days or weeks).
5. What configurable parameters and/or display options your plug-in will have.
This should be sufficient to enable a reviewer to understand what your plug-in will do, and (in general) how it will do it.
It will be graded on the extent to which it provides the above information.
Proof of Concept

This a quick and dirty program or script that obtains and prints out the required information. We expect to be able to run it, so include any information we might need in order to compile and/or run it and prove that it works.
It will be graded on the basis of whether or not it successfully obtains the required information in the manner described in the concept description.

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 2a".

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.