Preliminary (final contest)

1. There are four documents:

a. This document (Preliminary)

This document describes important information that contestants have to know before developing products.

b. Resource Sharing Community

This document describes a new product (for the final contest) and the reason why we need it. Note that this document is not an MRD. An actual MRD is derived from this document.

c. MRD of Resource Sharing Community

This document is for reference only. When receiving requirements like that stated in the Resource Sharing Community, we (the product manager and developers) may come out with something like this. Again, this document describes the features the product should have. Products should be designed and implemented according to this document; test plans and test cases should also be designed based on this document. However, you can write your own MRD (that may be totally different from this document), modify this MRD to suit your needs, or implement products according to this MRD. (Note: use different font color when you modify this document.)

Contestants should read these documents in the sequence they are shown above.

2. Staged delivery

To ensure the developing process is under control, we define two checkpoints and examine the process at each checkpoint.

a. Checkpoint 1 (16:00, 8/29/2001): You should hand in the following documents.

l MRD

l Architectural and technical design documents

l Test plan and test cases

Note that there are some requirements that are imprecise from the point of developers/testers¡¦ point of view. For example, there is a requirement in the ¡§Resource Sharing Community¡¨: A sleeper provider can reject requests from other members if its sleeper sleeps too much. In the test cases, you have to explicitly state the procedure for verifying that the requirement is achieved. Also note that your test plan and test cases should be designed according to your MRD.

b. Checkpoint 2 (13:00, 8/30/2001, also deadline): You must upload the following things to our ftp server before deadline.

l Installation Guide

l User Manual

l Source Code

l Executables and Libraries

l Finalized Documents: MRD, test plan/cases, etc.

l Presentation Slides

3. Test Environment:

The test environment is a miniature of the Internet. There are four hosts in the test environment and each belongs to a different network. There is no firewall in front of any host. Note that there are UNIX-like platforms (Linux, RedHat 7.0) and WIN32 platforms (Windows 2000) in the test environment.

4. Grading Criteria:

a. Any product that cannot be properly installed for testing is deducted 5 points from its total score. [Installation procedure]

b. FSC functional test: there is a set of test cases that are designed to test the FSC features.

c. RSC functional test: There are six primary requirements (join/leave the community, directory services and information exchange, commands, configuration files, interactive mode (UI), and batch mode). These requirements will be verified according to test cases that are designed according to the ¡§MRD of File Sharing Community¡¨ and ¡§Resource Sharing Community.¡¨ [Functional test]

d. The grading criteria can be roughly expressed as below:

Checkpoint 1:

document review (10%)

Checkpoint 2:

installation procedure

if (fail to install the product)

minus 5 points

functional test { // total 60%

FSC feature test (25%)

RSC feature test (35%)

}

Usability test and user manual (5%)

Presentation { // total 25%

Clarity of presentation (10%)

Design quality (12%)

Design extensibility (3%)

}

5. Guideline for Presentation

First of all, the presentation you are going to make is a technical presentation. This means that you are expected to present to the judges technical information regarding your product, especially those technical merits that cannot be easily tested.

Each team has 25 minutes to make its presentation. During this period you should also expect to be bombarded with questions from the judges, especially if you could not clearly present your design.

Your presentation should include, but is not limited to, the following:

l Original FSC architecture;

l How to adapt the original architecture to the new RSC requirements;

l Key design considerations and design issues, if any;

l How to extend your design to cope with new, arbitrary services in the future; and

l What would the architecture be if you could re-design it.

6. Extra points: (no more than 10 points)

RSC can provide meaningful extra functionalities or services.