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. The final product should be a system that everyone will want to use. This course will be intensive, and you will be expected to strictly honor the various deadlines, both individually and as a group. Failure to do so will probably result in the failure of the project which will result in an appropriate grade for everyone in the project.
Project(s) will be determined by a vote of the class (subject to approval of the professor and TA). Any project that is chosen or that you want to propose must meet the following criteria:
To provide guidance in the choice of a project, some candidates would include:
The actual projects to be considered will be decided by the class as a whole. We are going to work in teams of about 10 on the actual project and thus will have to achieve a strong consensus on what projects are appropriate. You are free to choose any of these projects (or another of your choice, if approved by the third class) for the first part of the course.
The actual specification of the system (i.e. what it will actually do) is limited only by your imagination and 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 6.0.
This project will be done using C++ on Sparcstations. You are be expected to write efficient programs that will make use of all the tools that are available to you, both those standard with UNIX and those developed at Brown.
Project ideas will be created independently. After the requirements documents, small groups (1-3) will create the specification of the final projects. Each individual or group is responsible first for providing a list of desirable features, and then for producing a full specifications document and a brief in-class presentation. We will choose among the submitted specifications as the basis for the class projects.
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.
At this point we will choose projects and divide the class into groups or teams of about 10 people per project. Each 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 as well as UNIX man pages.
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.
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 > 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.