CSC640 - Software Engineering Project - Fall 2004


Grading	Requirements Review Instructions	Requirements Document Instructions	Design Document Instructions	Version 1 Instructions (including demo)	Version 2 Instructions (including demo)	Version 2 Presentation Instructions	Submission Instructions (for paper, in-class presentation & on-line)	Course Web Page

Schedule


Due Date	Milestone or Deliverable	Brief Description (see more detailed instructions on each below)	Form (see detailed submission instructions below)
9/15	Requirements Review	In-class presentation describing SW team's current understanding of requirements through discussion of scenarios, etc. with client and asking client focused questions	in-class (with overheads and/or short handouts)
9/29	Requirements Document	Requirements Document	paper & on-line
11/3 (Note changed to after v.1)	Design Document	Design Document	paper & on-line
10/27	V.1 Implementation	Implementation of parts of system needed to run highest priority use cases and documentation in source code of all public class attributes and methods (even for parts of the system not yet implemented)	paper & on-line
10/27	V. 1 Demo	Run V. 1 implementation to show that the highest priority use cases have been implemented	in-class (with handout of use case descriptions for the ones shown in demo)
12/1	V. 2 Implementation	Implementation of rest of system (with brief instructions on how to install and run)	paper & on-line
12/1	V. 2 Demo	Run V. 2 implementation to show that all functionality has been implemented	in-class
12/1	V. 2 Presentation	Formal presentation to client about completed system	in-class (with overheads and printed copy of overheads)

Grading

Description Maximum Points
(totals 50)

Individual contribution to Requirements Document 15

Individual contribution to Design Document 5

Individual contribution to Version 1 Implementation 10

Individual contribution to Version 2 Implementation 15

Individual contribution to miscellaneous tasks:

Requirements Review

V. 1 Demo

V. 2 Demo

V. 2 Presentation

5

Extra credit/Points off: Added for contributing more than your share to the success of the project/Subtracted for deficiencies in teamwork such as consistently missing team meetings, not meeting internal deadlines, failing to cooperate or communicate with team up to 5 (but total for project not to exceed 50)

Description	Maximum Points (totals 50)
Individual contribution to Requirements Document	15
Individual contribution to Design Document	5
Individual contribution to Version 1 Implementation	10
Individual contribution to Version 2 Implementation	15
Individual contribution to miscellaneous tasks: Requirements Review V. 1 Demo V. 2 Demo V. 2 Presentation	5
Extra credit/Points off: Added for contributing more than your share to the success of the project/Subtracted for deficiencies in teamwork such as consistently missing team meetings, not meeting internal deadlines, failing to cooperate or communicate with team	up to 5 (but total for project not to exceed 50)

Requirements Review

The purpose of this in-class presentation is to check your team's current understanding of requirements through discussion of scenarios, etc. with the client and by asking the client specific questions about the proposed requirements. You should come prepared with scenarios and questions. You may make a short oral presentation describing what you think the requirements are. Handouts or overheads are optional but might be a good way to help the client follow your presentation. You may include pictures with a mock-up of the interface to help the client visualize the functionality. However, do not give the client much written material to read on handouts or overheads; this should be primarily a spoken presentation.It would be a good idea to have several people in the group taking notes.

Requirements Document

Here are the required sections of the Requirements Document. The parts marked with * are defined in Fig. 6.17 (p.139) of the textbook. Other sources of information that you should use as a guide are listed also. The entire group should collaborate on what to say in each section, but only the main author will receive credit for writing the section.Begin each section with a cover page containing the section title (such as Preface), the name of the group, and the name of the main author of the section; a list of other contributing authors may be included. It is up to the group to divide up the work fairly; some sections will require much more writing or figure preparation than others, so some people will need to write more than one section. The sections will be graded on completeness (in terms of capturing the client's requirements), consistency, and writing.

Table of Contents:

Preface*
Introduction*
Glossary*
User Requirements* (Example: Fig. 6.10)
Scenarios, Use Cases (Do not follow the book for this section; follow the handout from Bruegge and Dutoit given in class)
UML Use Case Diagram (one diagram showing all use cases) (Example: Fig. 7.7, handout from Bruegge and Dutoit)
System Architecture* (Example: Fig. 2.6, Fig. 2.7)
System Requirements* (Example: Fig. 6.1)
System Evolution*
System Models: Context Model (Example: Fig. 8.1) and Dataflow Diagram (Example: Fig. 8.2, Fig. 8.3)
Appendix: User Interface Specification

if the UI is command-driven, specify user command language in BNF or STD (follow lecture in class)
if the UI is graphical, specify all user selections using pictures showing screen mock-ups
in either case, give examples of format and contents of all results to be output by system

Design Document

Here are the required sections of the Design Document. Sources of information that you should use as a guide are listed.The entire group should collaborate on what to say, i.e., the entire group should design the product. Turn in one main cover page for the whole document giving title (Design Document), name of group, and authors. Because this is much shorter than the Requirements Document, all authors listed on the main title page will share equal credit for preparing the document. It is up to the group to divide up the work fairly. If a group member contributes very little or nothing to preparing the document (even if he or she participated in planning the design), the group may omit his or her name from the cover page. This deliverable will be graded on how clearly the design is expressed.

Table of Contents:

Architecture: main subsystems and classes in each (Example: Fig. 14.7, 14.10, and 14.12)
Object Model: show only public attributes and methods (Example: Fig. 14.2, 14.3, 14.4, 14.11)
Sequence Diagram(s) for Scenario(s) to be executed at the V. 1 demo (Example: Fig. 8.14) Note: to show that the highest priority use cases have been implemented in version 1, you will demonstrate several scenarios of each of those use case(s).

Note that this deliverable is due on the same date as version 1 of the implementation. You should begin Design activities before you begin the implementation of version 1. Then, as you are implementing version 1, you may realize that you need to refine the design. By the end of implementing version 1, you should have settled on a final design for the system (including the parts of the system that will be implemented in version 2).

Version 1 Implementation and Demo

For this milestone you should implement the parts of system needed to run the highest priority use cases, and you must document (in the source code) all public class attributes and methods (even for parts of the system not yet implemented). The purpose of documenting all public attributes/methods, even if not implemented yet, is so that other group members that will use that code do not have to wait for it to be implemented before they can write their code that uses it! Include in the source code documentation the name(s) of the project member(s) who should be credited for each part. (Different members may get credit for different activities, such as specifying the interface, implementing the code, fixing bugs, etc.)

At the in-class demo, you must run v. 1 on the same computer platform on which the final product is intended to run. (E.g. if a non-functional requirement for the product is that it runs on Windows, do not demo the program on a Unix system.) Have your system ready to run at the beginning of the demo. To show that the highest priority use cases have been implemented, you should demonstrate several scenarios of the use case(s). Before demonstrating each scenario, describe the scenario to the audience. Then, as you run the demo, point out the steps of the scenario as they happen.

Version 2 Implementation and Demo

For this milestone you should implement the rest of the system. All class/function interfaces, public and private, should be documented in the source code. Include a very short "read-me" explaining how to install and run the program. Include in the source code documentation the name(s) of the project member(s) who should be credited for each part. (Different members may get credit for different activities, such as specifying the interface, implementing the code, fixing bugs, etc.) Make it clear whether the credit is for version 1 or version 2!

At the in-class demo, you must run v. 2 on the same computer platform on which the final product is intended to run. (E.g. if a non-functional requirement for the product is that it runs on Windows, do not demo the program on a Unix system.) Have your system ready to run at the beginning of the demo. Pick scenarios from all of the use cases (v.1 and v.2) to run at the demo. Before demonstrating each scenario, describe the scenario to the audience. Then, as you run the demo, point out the steps of the scenario as they happen. Note that after your demo, the client will be given an opportunity to try the system.

Version 2 Presentation

This is a formal presentation (about 15 min., 20-30 slides) to the client and it will precede the demo. Create the presentation using PowerPoint. Give the instructor a printed copy (six slides per page) before you begin your presentation.

Follow this organization:

Title slide: name of product, list of group members (1 slide)
Summarize user requirements (2-3 slides)
Summarize system requirements (1-2 slides)
Describe the use cases (Begin with a use case diagram, followed by 1 slide per use case)
Describe a problem and a scenario that illustrates how the user solves that problem using the system. Show what the user interface looks like as the user goes through that scenario. (as many slides as needed to show user interaction with system)
Summarize system architecture (1-3 slides): if changed since the Design Document was written, describe the final design.
Summarize the most challenging design/implementation problems you encountered; for example, design of a complex data structure or algorithm (1-3 slides)

Submission Instructions

Paper

Written documents: All text documents (non-code listings) should be typewritten and formatted using a computer program (Latex, Word, etc.) and printed on standard 8.5x11 paper. (Make sure that you use a computer program that produces a file that can be converted to PDF.) If longer than one page, staple the pages together.
Graphics (diagrams, screen shots, etc.) should be printed using a computer printer. (Make sure that graphics are in a format that can be embedded in a PDF document.)
Code listings: Print out all code listings on standard 8.5x11 paper. All code should be formatted so that it is readable on 8.5x11 paper, not just on a computer screen.

In-class

The classroom has a camera that can be used to project graphics. Also, you will be allowed to use the computer in the front of the room for running your program and PowerPoint presentations. Details will be given in class on preparing to use the classroom computer.

On-line

Written documents (including graphics): All of these must be converted by you to PDF first. Then copy the PDF files into the folder assigned to you in class.
Source code, executables, and data files needed by program: You will copy these into the folder assigned to you in class. Details will be given in class.