Contents
The principles discussed in this course will find practical expression in a software project that you will develop as part of a group effort. This document describes the various structural, managerial, and documentational aspects of the project. A description of the content of the project (i.e., what you will be developing) can be found in the accompanying project description document. Due dates for each milestone can be found in the course master schedule. Individual commitments to the group can be found in the course syllabus. Weekly reporting requirements can be found in the weekly report sheet. Most of the specifics of each milestone (SRS, SDS, VVR) are in separate files; this file provides general information about the project and an overview for each milestone.
I will assign each class member to a group of 3 to 4 persons. I reserve the right to make slight alterations in your group (add/remove a member) during the first week of class as students are adding and dropping the course. If you are unhappy with your group assignment, please see me immediately. Note, however, that I will only change group composition under exceptional circumstances. As I state in the Individual commitments section of the course syllabus, "being friends with or liking your groupmates is not the objective of the group experience, though it may enhance the experience -- the objective is to work effectively as a group regardless of the personal feelings that one has toward the other group members." Also, be aware that your group may lose members during the course of the semester and you will need to adjust accordingly. This makes it all the more important that your group follow a disciplined approach to configuration management and file sharing, so that each person is incrementally documenting the work that they do and storing this in a group-accesible location.
Each part of the project will be graded based on the criteria given in the Grading Guidelines.
You are permitted to resubmit at most one milestone for regrade, as described in the regrade policy sheet.
Each student's grade will be assigned based upon the project grade as just described, as well as the extent to which the individual takes an ethical and responsible role with respect to the other group members as described in the Individual commitments section of the course syllabus. Individual performance will be evaluated using your weekly reports and individual and mutual evaluations.
The percentage of the project grade for each milestone is as follows, although I reserve the right to make slight adjustments to this as the course proceeds:
| Milestone | Project Grade % |
|---|---|
| Software Requirements Specification | 25% |
| Software Design Specification (including walk-through) | 35% |
| Verification and Validation Report | 10% |
| Implementation (including demo) | 30% |
Milestones are due at the start of class on the date specified in the master schedule. Under exceptional circumstances, I will consider a group's appeal for a deadline extension. However, these must be negotiated privately with me in advance by the group (or its representative(s)), and will almost always be accompanied by a penalty of 5% per class session late.
Each milestone will be handed in via softcopy only on a floppy disk, zip disk, or CD, (with the exception of the individual evaluations) unless there are accompanying materials that cannot easily be translated to electronic form. If there are such materials, please include these in a binder or enclosed envelope, along with a header sheet (course name, student names) and a brief explanation of the material that is being included and its relationship to the other documents in the milestone handin. In order to minimize virus spreading, please format the disk before loading your files, and load only the files needed. Please make sure to view your disk to make sure that all hyperlinks work before handing in the disk. Make sure that the outside of the disk is clearly labeled with your groupname and the milestone, and place your disk either in a disk case or in a protective envelope.
You are to create a stand-alone application using Java 1.4 for all code development. Any additional software tools/platform that your project will need must be available on CSS department computers so that I will be able to fully run your program. Your program should run equally well whether I am using Linux, MacIntosh, Windows, Sun, or any other system that supports Java 1.4.
Project development may take place on any platform that your group agrees is best. However, your project should execute via platform-independent software. This means that you should not use any proprietary features of languages, tools, and hardware that persist into your final product. Additional hardware/software constraints if any are specified in the project description document.
All group documents should be kept in a document repository. You may keep this anywhere that is most convenient for the group, but ensure that the following constraints are satisfied. The file server should provide both read and write access to all group members 24 hours/day, 7 days/week, but should prohibit read or write acess to other users and groups, (including myself). If you decide to use a server hosted on the Internet, make sure that it is password restricted, and that only members of your group know the password.
You will also want to use some sort of discipline for ensuring that no more than one person is altering a single document at a time. Unix systems provide excellent facilities for meeting all of these constraints. Specifically, the access control mechanisms of unix that divide the world into user, group, and other allow you to set read, write, and execute permissions for each of these three entities separately. The NT world provides similar access control, and you should make use of this feature of these OS's. Further, configuration management tools such as Revision Control System (RCS) take care of such things as file sharing/locking and keeping track of incremental file changes. For more info on RCS, see Peter Neuhause's RCS Primer or the Free Software Foundation (FSF) man pages for Emacs on version control.
All documents should be uniformly produced and formatted. Specific guidelines are found in the Project Document Layout Requirements. Documents handed in that do not follow the layout requirements may be returned ungraded. Most of the problems that I have had in the past concern file naming and hyperlinking. Please see specific instructions in the previously mentioned guidelines.
Note that each handin after the first should include a version of all previous milestones, appropriately hyperlinked and labeled, as well as all of your weekly report documents up to the date of the milestone.
Students from previous terms give the following advice. Think of these as tactics for survival.
The Software Requirements Specification (SRS), sometimes called the Requirements Analysis Document provides a description of what the system is to do under what constraints. It serves as a communication tool among clients, users and developers on the project. At a minimum, your SRS should include the elements specified in the SRS Guidelines. You may wish to include other sections, descriptions, notations, visualizations, etc. that you believe are necessary to fully convey the requirements. Several examples of SRS templates and "real world" requirements documents can be viewed via the links in the Resources section of the course syllabus. In addition, there are Software Engineering texts on reserve in the UWT library that can help you to understand and document the different parts of the requirements.
The Software Design Specification (SDS) provides a complete specification of the software/hardware platform on which the implementation will execute, the decomposition of the system into large-scale subsytems, strategies for handling access control and persistent data, as well as the detailed design of the software's objects in order to guide implementation. At a minimum, your SDS should include the elements specified in the SDS Guidelines. You may wish to include other sections, descriptions, notations, visualizations, etc. that you believe are necessary to fully convey the design. Additional resources are available as specified for the SRS.
After you have handed in your SDS documents, we will have a design walkthrough by several of the project groups. Ideally, all groups will present a walk-through (the default), but this may be impractical due to time limitations. Those groups not doing a walk-through will do an implementation presentation at the end of the quarter.
The objective of the walk-through is 1) for you to self-assess your own progress to date, and 2) for you to receive feedback on your work from other class participants. The format for the walk-through will be as described on p.261 of the Marciniak paper in the course text. One required variation to his description is that you should split the presentation between at least two presenters. Unless otherwise specified, the walk-through will consist of a 10" presentation of your design, with a focus on both the static and dynamic aspects of how you have divided the responsibilities among the different classes and how these classes collaborate to satisfy the required functionality.
You should assign someone in your group to be the scribe, who will write down all comments made by other class members and myself. A report of this walk-through should be included in your VVR.
The Verification and Validation Results (VVR) provides a report on your verification and validation activities, both static (e.g. reviews, walk-throughs, inspections) and dynamic (system tests). At a minimum, your VVR should include the elements specified in the VVR Guidelines. You may wish to include other sections, descriptions, notations, visualizations, etc. that you believe are necessary to fully convey your group's V and V activities. Additional resources are available as specified for the SRS.
The implementation represents the finished software project. Make sure to include hyperlinks and annotations to each of the below documents in your final "index.html" file. In addition to the documents that you have produced in the previous milestones, which need to be updated/maintained as your project evolves, the implementation should include:
Strive to have your project reach a stable state, even if you are not able to implement all of the functionality. As you implement, you should try to prioritize the functionality, and implement the highest priority components first.
The last day of class will be a demonstration of all projects developed during the term. In class, each group will first discuss their project for 10", making use of their final milestone document. This will consist of the following: a discussion of the final class and/or sequence diagrams, a discussion of what changes were made to the design since the SDS, and a small set of recommendations to the professor for teaching the course the next time and advice for entering 360 students. In the lab, one person from each group will demonstrate that their program meets all of the functional and non-functional requirements by running through each scenario of their use cases, starting with the MSS's of the most important use cases.