Computer Science 121 - Project 2f

Build & Test

OPTIONAL - EXTRA CREDIT

Fall 2007

$Id: proj_2f.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

After you have sketched out a product, studied the issues, prototyped any non-obvious pieces, prepared detailed design and test plans, submitted them to review, and revised them accordingly, we expect the actual implementation to be a relatively uneventful process. The purpose of all of those preparatory steps is to ensure that all major problems and issues have been addressed before the first line of code is written, and greatly enhance our probability of building the product correctly the first time.

The proof of the pudding is in the eating.

If you choose to do so, you can (for extra credit) implement your design, execute your test plan, and build your GKrellM plug-in.

The goals of this exercise are to:

  1. show you how much easier it is to build something after it has been designed.
  2. show you how much more reliable code turns out to be when you understood its correctness before you started writing it.
  3. give you something concrete to show for all the work you have put into this sucker.

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 Plan for phase activities 3
team work product Module Implementation 15
team work product Build/Install/Run automation & documentation 5
team work product Test Plan Implementation 15
team work product Build/Run Test automation 5
team work product Post Mortem Analysis 5
team methodology Use of Version Control 1
team methodology Planning and Management 5
individual work product Quality of Individual Work 10
individual methodology Share of Work 5
individual methodology Schedule Adherence 5

3. Assignment

For this project 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. Implement the plug-in design that you prepared in phase C, as updated by the test planning in phase D, and feedback from the review in phase E.

    It should build (from a directory checked out of your repository) with a standard makefile.

  3. Implement the test plan that you prepared in phase D, as updated by feedback from the review in phase E.

    All necessary testing tools should be obtainable from (or buildable from sources obtained from) your repository.

    The execution of the test suite and verification of the results should be entirely automated.

  4. Build and debug the module, ensuring that it builds from a newly checked-out version, and passes all specified test cases.
  5. Write a brief document describing the building, testing, installation and use of your plug-in.
  6. conduct a post-mortem of this implementation process, and write up a report.

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

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.