Project Handout
Welcome to CS190. In this course we attempt to develop useful software systems. Your goal will be to
develop a system that is useful, friendly and powerful enough so that people will actually use it. You are going to
work as teams of around 10 people to develop a single software system. Everyone is expected to contribute to the
specification and overall design of the software. Moreover, each individual will be responsible for a particular
portion of the detailed design and implementation of the overall system.
Each group member will be expected to honor the various deadlines, both
individually and as a group.
Project
Project(s) will be determined by a majority of the class. Any project that
is chosen or that you want to propose must meet the following criteria:
- It must be something that other people will use. This encourages you to have a set of users to get requirements
from other than yourself. It also means that the project should be something new, i.e. something that doesn't already
exist in the form you propose.
- It must be something that can be scaled to a large project (i.e. larger than a group would typically expect to
get done in one semester). We want to teach aspects of design that encompass systems that are commercial in scale
even if we can't build them practically. Moreover, we want to stress design for extensibility, i.e. designing a
system so as to anticipate change. The scale should be roughly thought of as that of a typical commercial PC product.
- The project must be amenable to being divided into logical components for group programming. This will typically
be the case for a large enough projects.
The specification of the system (i.e. what it will actually do) is limited by the
constraint that it be fully working by the end of the semester. You should think of what a minimal system
implementation should provide, and you should dream of what a fully extended, lots-of-bells-and-whistles-type
applications would provide as well. From a commercial point of view, we will be implementing version 0.1 of the
system, but designing for version 2.
Course Mechanics
Each individual is responsible first for providing a list of requirements
(desirable features), and then for producing a full specifications
document. Everyone will be constructing requirements and specifications for
the same basic project concept, but you're responsible for your own take on
the project idea in order to flesh out these documents. Part of class will
be comparing different people's ideas and seeing where the project takes
the group.
The second part of the course will be spent on generating a workable top-level design for these specifications. You
will again work individually or in small teams and will produce a top-level design document showing how one of the
systems will be implemented and how the work can be broken down on an individual basis. There will again be in-class
presentations and discussion of these designs, and we will again choose one of the competing designs as the basis for
the implementation for each system.
The
group will choose a project manager and a project librarian for their project. The project manager is the one who
will be responsible for coordinating and supervising everyone. She/he will have the power to make modifications to
the design or specifications and to assign or reassign people to different tasks. The project librarian will be the
individual responsible for maintaining a project notebook and eventually coming up with user documentation, both
on-line and a user's manual. Note that responsibility here does not necessarily mean that he/she has to do the actual
work, just coordinate it. Everyone else will be assigned a particular aspect of the implementation as their
responsibility. Note that we expect each group to work as a coordinated team, with people helping out, providing
feedback, etc. to others as necessary.
Documentation is an essential part of the projects. The project notebook that you will develop will contain the
current versions of all documentation, specifications, schedule, etc. This documentation must be kept up to
date at all times: whenever a part of the design or implementation is changed, the corresponding portions of the
project notebook must also be changed. This notebook is subject to inspection at any time. It would be reasonable to
keep this on-line. Your project is also expected to include a readable user's manual and any necessary on-line help
information and files.
Once the projects are broken down into components, the programming work begins. Your first task here will be to
develop the exact interfaces that the different components of the project will use. Each person is responsible for
providing an initial specification of their interface (i.e. external classes, methods, and functions). All interested
parties will then comment on everyone else's specifications, and, with the assistance of the project manager, we
should be able to cast final specifications in concrete. (Although they can change later -- but only after the
project manager, librarian, and all affected parties approve the change.)
The next step will be for each individual to provide a detailed design for her/his sections of the project she/he is
working on. This can be done in one of two ways. For those cases where the implementation is fairly well understood,
we suggest that a full-scale detailed design be done, i.e. modspecs, be written for each routine. For those cases
where the final implementation is not well understood, say with the user interfaces, an initial quick and dirty
prototype can be done to experiment with different designs.
In either case, there is a firm deadline for integrating all the different aspects of the systems. It will be the
responsibility of the project managers to insure that enough of each project is complete so that initial, minimal
systems can be put together at this point. It will also be the responsibility of the project manager to take charge
of integration testing beyond this date, finding bugs in the overall system and reporting them to the individuals in
charge of the components to be fixed. We will attempt to maintain a stable version of all aspects of the systems so
that each individual can experiment with their particular component without affecting everyone else.
The final systems (i.e. full functionality), should be done by the public demo during reading period. Everything
should be implemented by then (or completely forgotten) and almost all bugs should have been found and eliminated.
This will give us a week and a half for formal user testing, polishing, and leeway in case deadlines are otherwise
missed.
Management
You will find that CS190 is as much a course in management and interpersonal relations as it is a course in
programming. This is especially true as groups get large (i.e., more than 5 people). The effort that is required for
communication and coordination within a group is substantial. The project managers that are chosen will effectively
be the class dictators (subject to being overruled by the professor or TA), who will have the final say in all
decisions, etc. While democracy is nice in practice, it tends not to work well in software design.
Project Timetable
- [1/28, first draft; 2/1, final draft] List of Requirements - Working individually,
you will prepare a reasonable set of requirements by this date.
For whatever project you choose, you should
familiarize yourself with similar products, finding out everything you can.
You should also talk to potential users and develop a list of what they see
as their requirements. Using these inputs and your own needs, you should
make a list of all the possible desirable features that you could envision
for such a system. This list should then be broken down into a set of basic
features and one or more sets of optional features (with associated
priorities). Everything should be consistent and some attempt should be
made to keep things reasonable. All the submissions available
electronically immediately so that everyone can read them before
presentations start the following class. Each proposal will be presented
briefly in class.
- [2/6, first draft; 2/11, final draft] Specifications Proposals
- Continuing individually, you should prepare a specifications document
for your project. In addition, you should prepare a short in-class presentation that highlights your proposal. Your
proposal should include a description of the proposed system and how it will be implemented. The description should
include a discussion of the objectives and how they will be met; the inputs, outputs and actions that the system
performs, complete with pictures as needed for understanding; and a discussion of the user's model of the system. The
latter should be enough to give the reader a feel for whether the system will be useful. The implementation
discussion should outline a strategy whereby a core system can be built and then extended with optional features.
This approach ensures that once the core system is implemented, the class will have something to show for their
efforts. The specifications will be discussed by the class as part of your (and others) presentations, and should be
amended appropriately. One project for each ~10 students will be chosen at this point as a course project.
- [2/23] Top-level Design Proposals - Again working individually, you are responsible for preparing a
top-level design that meets the amended set of specifications for your assigned project. You should prepare both an
electronic document and a brief in-class presentation of your proposal. This should include about a 5-10 page
description of how the system will work, replete with pictures that includes:
- A user interface specification, with diagrams if appropriate.
- A functional specification.
- A module breakdown for the implementation, with an interconnection diagram.
- A proposed implementation schedule.
- A breakdown of responsibility for the various components.
- [3/2] Top-level Design Selection - By this date we will have chosen the projects to be implemented, the
top-level design to be used for that project, and we will have assigned people to their projects. We will also select
a project manager and project librarian for each project. During the subsequent week the project manager should, upon
consultation with the project team, assign each individual one or more portions of the system as their primary
responsibility. Class on 3/7 will be allocated to group meetings to finalize this process.
- [3/9] Final Top-level Design - Revisions based on group feedback and assignments of group members must
be complete.
- [3/14] Interface Proposals - Each person in charge of a component of the system should produce a
proposal as to their external interfaces by this date. These should be available both electronically and in hardcopy
and should be coordinated by the project librarian.
- [3/19] Interface Comments - Between the last class and this one, each student should go over all the
interface proposals that affect their components of the system and provide feedback, comments and suggestions. The
project manager and librarian should go over all interfaces to provide such feedback.
- [3/23] Final Interface Definition - Each person should have fixed their proposed interfaces by this
date. This means that they have to respond to all comments and to get final approval for their interfaces from the
project manager. The project manager is responsible for insuring that all interfaces are consistent and complete.
Changes to the interface after this date must go through a full review process including in-class justification.
- [4/6] Detailed Designs - By this date each individual should have finished and had the detailed design
for their components approved. If a full-design approach is being taken this means that they should have written
modspecs for all their modules and have gone over these with both the grader and with the project manager. Once
approved, the design should be submitted to the project librarian. If a prototyping approach is being used, then one
or more prototypes should have been completed by this date and the actual implementation should be decided on by the
TA and project manager based on experiences with the prototypes. Once the prototype is settled, the individual is
still expected to do full modspecs for submission to the project librarian within a reasonable amount of time.
- [4/16] Initial System Integration - This is the magic date where we should see the initial version of
the projects all fit together and work. This should contain the overall control structure and most of the user
interface, but specific functions may be stubbed. All the essential components should be here in some form.
- [4/27] Full System Implementation - This is the target date for having a fully implemented, functional
basic system. The system will be demoed in class. Some bugs may still exist, but system should be stable enough to
demo. Functionality will be frozen at this point
- [5/7] Public Demo - Projects will be demoed to the public in Lubrano on this afternoon.
- [5/17 9am] System Submission - This is the final date for submitting the system. The system should be
fully functional and installed for users with full documentation available. You should turn in a full listing of the
complete system as well as the final project notebook. You will be expected to give a full demonstration of your
system for the professor and TAs.
[an error occurred while processing this directive]