CECS 332 Final Project
CECS 332 Fall, 2003
FINAL REPORT – DUE MONDAY, DEC. 15 by 5 p.m. (hand in a printed
copy to EBW 221 or EBW 201)
Each group will prepare and submit one copy of their final
project report, which should include the sections noted below in the outline. Please follow the outline below, in the
order specified. This will increase
your chances of getting a higher grade. New items are highlighted in red.
In separate sections,
include also your original Specifications
Document and your original Design
Document, with the graded evaluation sheets for each. The final report should include the revisions
suggested on your design document. Label all diagrams
and include a short paragraph to explain which part of the system each diagram
models.
Final Report Outline
- Table of
Contents
- Introduction
- Include the basic idea and the motivation for the project
- Glossary
- Define special terms, especially domain terms (i.e., terms that
are specific to your application domain)
- User
requirements definition
- A high-level description for users in paragraph or bullet form
- Expand your problem statement
- Include functional and non-functional requirements and any domain
requirements.
- System
architecture
- Context
diagram showing how your system interacts with its environment. The
context diagram shows one block which represents your system and other
blocks for external components with which your system must interact. Add detail to the
diagram by converting the lines to arrows to show the direction of
information flow, and document the information transferred between components
(i.e., label the arrows).
- (Required)
Architecture diagram of your system (i.e., the Architectural Design). Again, convert the lines
to arrows and label the arrows according to the information transferred between
components.
- Include a brief description of each block for both the Context
diagram and the Architecture diagram.
- System
requirements specification
- A more technical description in paragraph or bullet form for the
software developers
- Include functional and non-functional requirements and any domain
requirements.
- Include
implementation details on the programming language, operating system, and
hardware platform.
- System models
- Requirements specification
- Use case diagram
- For each use case, include the starting and ending conditions,
the sequence of steps and the exception handling
- Design: Include other models as appropriate for specifying the
system design
- Each
system with a database component should include one or more
Entity-Relationship Diagrams. For systems
with other datastores, include documentation
in the form of a data dictionary (name, data type/format, description).
- One or more Data Flow Diagrams (for object-oriented languages,
use the UML Sequence Diagram) to show sequential process flow.
- One or more Statecharts to show the
event-driven characteristics (e.g., games, web interfaces and other
interactive interfaces)
- A model of the user interface such as sample screen shots for
input and output.
- A layout of any printed reports.
- A
hierarchy diagram showing the structure of the final system,
i.e., what functionality is contained in each module. For
object-oriented languages, use a UML class diagrams showing the
associations. (UML class diagrams can be generated
automatically by using the reverse-engineering option in Rational Rose.)
- System
testing
·
Include a test plan for both unit testing
and integration testing (e.g., specify whether you tested top-down or bottom-up)
Object-oriented programs should be tested by class and clusters of classes.
·
Include a set of test cases
·
Include a log of the test results
·
Include a list of known bugs and rate them
as minor, moderate, or serious.
- Post-project
analysis
- Cost
estimate using the COCOMO model.
Include your estimates and justification of the parameters. Also,
include an accounting of your actual effort (by component and for each
team member). How does the COCOMO cost estimate compare with your actual
development effort?
- Now that you
have completed the project, list what has turned out to be the most
significant risk factors
associated with your project (2-4 most significant). What would you do
differently if you started over again?
What software process model would you use and why?
- System
evolution
- (Optional) projected maintenance requirements
- Appendices
(if applicable)
- Index
(optional)