Computer Science 121 - Project 2b

Module Definition

Fall 2007

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

Critical Dates

Project Description

  1. Introduction
  2. Deliverables Table
  3. Assignement Details
  4. Grading
  5. Rules and Submission

1. Introduction

It is often necessary, in a software, project, to learn how to use new programming frameworks, and most of them don't come with well written tutorials. When anyone starts using a new framework, they usually have very little concept of what it does, or how it is used ... and a single reading of the manual seldom dramatically changes this. The process of studying, and figuring out how to exploit a new software framework is a skill that must be developed, and will be the primary focus of this phase of the project.

In this phase you will:

  1. Study the GKrellM plug-in APIs to understand the structure of a GKrellM plug-in, and the services through which it interacts with the general GKrellM framework.
  2. Make detailed notes on the structure of GKrellM plug-ins, and the use of the GKrellM plug-in APIs.
  3. Based on this understanding, write detailed specifications for your plug-in, defining the entry-points it will implement, what each will do, and the services it will use in implementing those functions.

It is also common to assign one person to go study a subject and then come back and share (with the rest of the team) what they have learned. Preparing detailed notes on the GKrellM framework will give you experience with distilling the relevant parts of a complex description for use by others.

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 Notes on how GKrellM plug-ins work 15
team work product Module Specifications 20
team work product Post Mortem Analysis 8
team methodology Use of Version Control 1
team work product Plan for phase activities 2
team methodology Planning and Management 2

3. Assignment

It is often necessary, in a software, project, to learn how to use a new framework. When anyone starts using a new framework, they usually have very little concept of what it does, or how it is used. The process of studying, and figuring out how to exploit a new framework is often an iterative one. There is an inelegant, but time-proven approach to learning a new framework:

  1. start out with some notion of how you want to use the framework and what you want it to do for you.
  2. gather and read the documentation.
  3. decide you can't figure it out from the documentation, so gather and read some sample code.
  4. once you think you have a clue, you start planning how you would use the new framework, and realize there are still a great many things that aren't yet clear.
  5. test your tentative understanding of how features work by building trivial test prototypes to exploit particular features.
  6. repeat as necessary

It is much more efficient to gain this understanding by study and prototyping than by trying to debug a complete program that has been designed on the basis of fundamental misunderstandings. This is why we are making you study, make notes, prototype, and specify before you start doing detailed design for your plug-in.

In this phase you will:

  1. 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.
  2. Study the GKrellM plug-in APIs to understand ...

    • what functions your plug-in must implement to interface with GKrellM.
    • what widgets you will use to present the proposed status displays.
    • what functions you must use to create and maintain the proposed status displays.
    • what images you will use or create to create the proposed status displays.
    • what aspects of your display you want to make controllable or configurable.
    • what widgets and configuration parameters you will have to add to achieve this controllability/configurability.

    As you figure out how to use the APIs, make notes on their use (and on the implied structure and design of plug-ins).

    If there are aspects of the specifications that do not entirely make sense, construct quick and dirty prototypes to confirm how the features work, and what you have to do to make them work.

    The APIs to support new pluggins are described in the GKrellM Plugin Programmers Reference.

  3. Write detailed specifications for your plug-in, defining:

  4. Conduct a post-mortem review of the study and specification process, looking at how effective your approach was to studying, planning, and confirming your understanding of how to use a non-trivial API.

WARNING

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

  1. 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.
  2. 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.
  3. 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:

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:

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

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 ...

  1. 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.

  2. You may not share any of your work products (other than as required for reviews) with members of other teams.