In Project 1, we told you when each phase (1a, 1b, 1c) was due. For project 2 we are only giving you a final completion date, and are leaving it up to you to figure out when you should deliver each incremental phase.
This is a multi-phase specification, design, and review project.
Whereas project 1 dealt with large systems issues
(requirements, architecture, and architectural review),
this project deals with a relatively small project, and
with specification, design, and test plans on a much
more detailed level. The number of tasks you will perform
in the next month is much greater than the number you have
performed in project 1 (which spanned two months) ... but
the component you will be designing is much simpler, and
the total work per person will be less than for project 1.
This is an overview of the entire project. There are
separate, and more detailed descriptions for each of the
phases:
This project will complement the treatments (in the lectures and reading)
on:
We broke project 1 down into three phases for you,
and assigned them separately. Project 2 is being
assigned to you as a single large multi-phase activity.
Based on your experiences with project 1a-c, you should
now be well prepared to break down more complex projects
into sub-tasks, schedule their completion and manage
to that schedule. We will define incremental sets of
deliverables for project #2, and a final delivery date
by which all of them are due. It will be up to you
figure out when you want to do and deliver which work
products. This gives you much greater freedom in how
to structure your effort, and a much greater opportunity
to fail if you do not correctly understand the task
interdependencies, or if you don't allow enough time
to complete all of the work.
1. Introduction
| type | Phase | Description | Value |
|---|---|---|---|
| team | A | Plan & Concept | 15 |
| team | B | Module Specifications | 45 |
| team | C | Module Design | 45 |
| team | D | Module Test Plan | 45 |
| team | E | Review & Revise | 45 |
| team | Z | All Project Post-mortem | 20 |
| team | X | Management | 15 |
| individual | all | work share | 20 |
| individual | all | work quality | 30 |
| individual | all | management | 20 |
| all | combined total | 300 |
If, after completing all of these phases, you would like to go for as much as 25% extra credit, you can build and test your plug-in (according to your plan). This will take more time (at a time when you will probably already be very busy), but I expect you will find that the planning done in the prior phases makes the actual implementation quite anti-climactic ... which is the point.
| Phase | Description | Value |
|---|---|---|
| XC | Build & Test | 75 |
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.
The APIs to support new pluggins are described in the
GKrellM Plugin Programmers Reference.
In this project you will:
Come up with a plan and schedule for defining, designing, reviewing,
and writing a test plan for a new GKrellM plug-in, producing
all of the required work products, and dividing that work
among your team members.
Standard project activities (like plan development, post-mortem,
and index of work products) should be assigned to different
people (than in the previous projects), so that everyone
gets an opportunity to do each of these tasks.
WARNING: the GKrellM plug-in APIs are extremely rich. Do
not under-estimate the amount of time it will take you to
digest them and figure out what you need to know.
revise your design and test plans to deal with any issues
raised by the reviewing team, and (if appropriate) get their
approval of the changes.
At the end of each major phase, you will conduct a post-mortem of that
phase and submit your work-products for that phase. Your final
submission should include a broader post-mortem of all of the
projects assigned in this class.
The detailed assignment descriptions for each phase are described
in the individual project descriptions:
WARNING
The detailed Grading Criteria for each phase are described
in the individual project descriptions:
It is expected that different people may carry heavier and
lighter loads in each phase of the project. Trying to get
everyone involved in every activity may not make sense.
Individual work-share and quality scores (for this project)
will be computed on the basis of the union of the work
done for all phases.
At the end of this project, you will prepare a post-mortem on all of
the projects in the course. Rather than looking at the specific
activities in any given project, you will look at the overall
effectiveness (or lack thereof) of the combined set of projects,
in complementing theoretical material presented in the lectures
and reading. This post-mortem should specifically deal with:
Each of the primary phases should be sumitted separately.
Your final submission should be the pan-project post-mortem.
When you have completed this, create a message that includes:
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.
4. Grading
4.1 Grading Criteria
4.2 Individual Scores
4.3 Final Post-Mortem
5. Rules and Submissions
And submit all of these things to me in an e-mail with the
subject "cs 121 - Final Post-mortem"