BU CS 511 Team Project

Software Engineering -- CS511
Boston University -- Fall 2001

Team Programming Projects

Team Roles

Each team should assign people to the following responsibilities:

Functional specification, project leader
Test plan, testing
Documentation (installation guide, user guide, reference)
Technical specification, programming (2 people)
Team presentation (separate from the programming project)

The project leader should send me an email with the name of each member, their ID#, and team role. (Please use a clear subject line, so I can find it later.)

Option #1 -- Connect Four Game

This project implements the Connect Four game, a more complex version of tic-tac-toe.

The game board is seven squares across and six squares tall. The winner is the first person to get four of their markers in a row (vertical, horizontal, or diagonal). The wrinkle is that the board is standing upright and you can only add markers from the top. (So a marker only can be placed at the bottom of a column, or directly on top of an existing marker.)

You will write a program that plays this game against a human user. The two main parts of the program are the user interface and strategy algorithm. The program needs to play reasonably well (it cannot make random moves), but does not have to be provably optimal or play without errors.

Option #2 -- Appointment Book

This project implements a simple appointment book for one person.

The user should be able to:

Create new appointments.
Delete existing appointments.
List all appointments on a given date.
List all appointments in a range of dates.
List all appointments in a given category.

Each appointment contains the following information:

Date and time of appointment.
Length of appointment.
Description of the appointment.
A "category" for the appointment.

Optional features:

Search appointments for a matching string.
Edit existing appointments.
Warn user of conflicting appointments (when creating a new one).

Option #3 -- Contact List

This project implements a simple name and address book for one user.

The user should be able to:

Create new contacts.
Delete existing contacts.
Search for (and display) a person by last name or first name. Should handle multiple matches.
Edit existing contacts.

Each contact contains the following information:

First name, last name.
Street address, town, state, zip code.
Phone number, email address.
A "notes" field, where the user can enter any information.

Optional features:

Search contacts for a matching string (other than name).

General Notes

Because it is quite a bit of work, the design and programming will be done by two people. Divide the program into two logical sections (such as front-end UI and back-end processing). Each programmer will do their part of the program, plus a driver or stubs to allow the code to run on its own. The two programmers will then integrate their code into a single program.

(The reason each part should run on its own is in case the other programmer does not do their work; you may turn in just your own code if necessary. This is a fall-back position though. I expect all teams to turn in a single integrated program.)

The entire team should review each deliverable before it is handed in, since you will share in its grade.

Project deliverables are due at the start of class on the due date.

The functional spec, design spec, test plan, and user guide should be submitted in both printed and electronic forms. Hand in two printed copies on the due date. Also send me an electronic version -- this can be PDF, HTML, or Microsoft Word.

The executable program and source code should be submitted electronically via email -- to both the instructor and grader. Send a single ZIP file with everything in it, including a readme to explain what the pieces are.

The user interface for these programs can be either simple (character mode) or sophisticated (colored GUI). The quality of the code is more important than the fanciness of the interface however.

Much of the work can occur in parallel. For example, the person writing the test plan can begin this as soon as the functional specification is solidified. The user guide can also be sketched out from the functional specification. The people writing the code can begin a prototype (or high-level shell) alongside the technical design document.

You may write the source code in any common language that I can read on Windows -- such as C, C++, Visual Basic, Java, HTML/Javascript. The executable program must run on Windows, a standard BU Unix system, or from a standard browser. (Send a small "hello world" test early in your development to verify this.)

We should not have to load additional software (such as a new windowing system or a special interpreter) in order to run your program.

If you use Visual Basic, export the code to a format I can read, since I do not have the VB system.

Use a programming language / environment that you already know. Do not try to teach yourself a new system at the same time you are doing the project.

All members of the team should assist each other, since you will be sharing the grades for all the deliverables. However, you should not do someone else's work for them.

Please let me know about significant problems on your team and I will help you find a solution. Significant problems include someone not coming to team meetings or not meeting their deadlines.

Use a grammar-checker and spell-checker for all written work. The easiest way to do this is with Microsoft Word.

Grading

Grading criteria for functional specification:

Clarity, readability. Table of contents, headings, white space, good organization, grammar, spelling.
Level of detail. List all of the features and options, and say what they will do. Be specific.
Pictures, diagrams, screenshots, and examples. These are helpful in almost all technical writing.
To state this another way... A programmer should be able to pick up your functional spec and create a technical design for this software. Did you include enough detail to do this?
(You will function as a project leader, but this will not be part of your grade since it is too hard to assess.)

Grading criteria for design spec:

Clarity, readability. Table of contents, headings, white space, good organization, grammar, spelling.
Level of detail. Did you just say there would be two files, or did you show the structure of them? Did you say there would be a subroutine to do X, or did you show its algorithm and methods?
Diagrams and figures where helpful.
If you just repeated what the program will DO for the user, this is the functional spec. The design spec should tell HOW the program will do it.
To state this another way... Another programmer should be able to pick up your design spec and start coding. Did you include enough detail to do this?

Grading criteria for test plan:

Clarity, readability. Table of contents, headings, white space, good organization, grammar, spelling.
Level of detail. Did you just say that you will write a driver to test the file interface, or did you describe exactly what the driver will do and what the tests will be?
Effort to cover all cases, creativity in finding ways to expose flaws.
To state this another way... Another tester should be able to pick up your test plan and start testing. Did you include enough detail to do this?

Grading criteria for installation guide, user guide, reference:

Clarity, readability. Table of contents, headings, white space, good organization, grammar, spelling.
Level of detail. Tell exactly how to install and set up the software. Describe how to use each feature, step by step. Be specific.
Pictures, diagrams, screenshots, and examples. These are helpful in almost all technical writing.
To state this another way... A user who has little computer knowledge should be able to pick up your document, and install and run the software. Did you include enough detail to do this?

Grading criteria for program code:

Design/architecture -- clear, simple, modifiable, maintainable.
Readability of the code. It should be so clear that it barely needs comments.
Generous and meaningful comments. (Tell me the reason for this code and how it relates to other sections. Tell me things that aren't obvious by reading the code.)
Feature count.
Ease of use, clarity of user interface.
Quality (lack of bugs).