This semester, students will construct one of two software systems: a hotel-management software system, or a higher education course registration system. Details are described in the requirements documents below.
InnTouch Requirements Document
LUNAR Requirements Document
Project Deliverables
All deliverables are due by 5:00 PM on the specified due date (NOTE: the dates below take precedence over the ones listed in the requirements document(s)). Submission instructions will be posted shortly.
1. Introductory Memo (due Friday, September 11)
Submit a letter on company letterhead stating the name of your team, listing the names and e-mail addresses of all team members, and identifying your team's Project Manager (PM) and Quality Assurance Manager (QM). Project groups should contain 5–6 members; instructor permission is required for smaller or larger project groups.
Use Blackboard to submit your introductory memo (go to the "Assignments" section and submit your file that way). Each group should submit EXACTLY ONE copy of its introductory memo!
2. Issues Document (due Friday, September 25)
You will submit an issues document discussing issues that have come up as your company analyzed the requirements document for the project. At this time, your group should also propose an extension for your project. This extension should take the form of an additional feature (writing part or all of your project code in a new (to you) programming language is also acceptable as your extension). Groups that have more than 6 members should propose two additional features as their project extension.
Your issues document should include the following categories: management/coordination, information storage, procedures, interfaces, and your project extension. Use the attached outline for the issues document.
Model issues document
Grading Criteria:
• Uses outline: 1 point
• Addresses information storage issues: 3 points
• Addresses procedure issues: 3 points
• Addresses interface issues: 3 points
• Addresses extension issues: 3 points
• Addresses management issues (IDE, meeting times, organization): 2 points
3. Specification Document (due Friday, October 9)
Submit a specification document for your project. Use the outline below as a model.
Model specification document
Grading Criteria:
• Uses outline, related documents: 1 point each
• Schedule, budget: 2 points each
• Object decomposition, functional decomposition, dynamic models, GUI, specification list, error conditions, performance requirements, system requirements: 3 points each
4. User Manual (due Friday, October 23)
Submit a user manual for your project.
Grading Criteria:
• Includes company name, logo, names of contributing members: 1 point
• Nicely formatted: 2 points
• Addresses each major use case of the system, including your extension: 18 points total
• Uses non-technical language: 3 points
• Includes appropriate figures: 3 points
• Index, table of contents: 3 points
5. Design Document (due Friday, November 6)
Here is a list of questions to ask as you prepare this document:
1. What is your software architecture? (You should describe this, and explain why you chose it.)
2. What are the subsystems in your system?
3. What are the objects in each subsystem? (These two questions should result in an object diagram, a set of class/object definitions, a list of method definitions with pre/postconditions, parameters, return values, callers and callees, and a list of fields.)
4. What algorithms will your subsystems use? (You should define each algorithm.)
5. How do your objects/subsystems relate to your use cases? (This will lead to a set of sequence diagrams showing the interactions between subsystems and objects, one per use case.)
6. What is your database structure? (This will lead to a set of ER diagrams, table descriptions, and database access method descriptions.)
7. What is your UI like? (This will come mostly from your specification and user manual documents, but should be updated.)
The goal here is to look at things from the system architect's perspective. Get quite close to the implementation. Be specific. Practice rationale-driven engineering, and remember to check your design document using CCCRR.
Grading Criteria:
• Uses outline: 1 point
• Appropriate use of UML: 5 points
• Related documents: 2 points
• Objectives, high-level design, data structures/database design, GUI: 3 points each
• Detailed descriptions of procedures and objects: 5 points each section (10 points total)
6. Compilable Prototype (due Wednesday, November 25)
Submit a first version of compilable code for your project. This assignment should be turned in on CD, not on paper.
Grading Criteria:
• Files include names and IDs of team and team members contributing: 1 point
• README file: 2 points
• Code compiles and runs without crashing: 3 points
• Code meets requirements: 3 points
• Code matches design document: 3 points
• Code matches user manual: 3 points
• Documentation: 3 points
• Evidence of using good software engineering techniques (version control, etc.): 2 points
7. Design Review (December 3–10 in class)
Your group will present a design review of a software system in class. Your presentation will take the following form:
* It will last for 35–40 minutes
* It will be split into: overview of system, issues relating to overall function (platform, purpose of system), issues relating to information storage, issues relating to procedures, interface issues, issues relating to the extension, ethical issues relating to the project, conclusions.
* You will leave 5 minutes for questions from the audience
* You will use Powerpoint and professional-quality slides
* You will dress professionally for your presentation
* You will review another group's project for CSE308. Your other group will be assigned to you at the start of class on 11/19
* You will be assigned to a presentation day (two groups will present per day).
Grading will be done individually and will be based 60% on the instructor's evaluation and 40% on fellow students' evaluations. The instructor and fellow students will use the same evaluation form.
Hints for Design Reviews
To prepare:
1. Get the other group's documents (issues, specification, design, testing, user manual)
2. Get the other group's code drop or do a walkthrough
3. Each person in your group takes one aspect of the other group's project: overview of system, issues relating to overall function (platform, purpose of system), issues relating to information storage, issues relating to procedures, interface issues, issues relating to the extension, ethical issues relating to the project, conclusions.
a. Check the spec. doc. using CCCR, comparing to the requirements and issues docs.
b. Check the design doc. using CCCRR, comparing to the requirements, issues and spec. docs.
c. Check the user manual using the system, the spec. doc. and the requirements doc.
d. Check the testing doc. CCC, comparing to the other docs.
e. Check the system using CCC, comparing to the docs.
f. Check the ethical/management/communication issues using the docs.
4. After reviewing the documents, meet with the other group to ask questions and clarify issues.
5. Construct your presentation, with a set of slides for each of the six sections of the review and an introduction/overview.
6. Practice, making sure that the transition from group member to group member is smooth. Remember, each group member must share equally in the presentation and each one must talk for about 5-7 minutes. Notice that there are five sets of issues, plus system overview and conclusions, so if each of you takes one set of issues it will work out very nicely.
7. Leave a little time for questions and feedback.
A design review is NOT: a complaints list; a list of what could have been included in the requirements; a chance to bully the other group.
A design review IS: a chance for constructive criticism, identifying requirements not met, issues not resolved, and conflicts between documents while there is still time to resolve them.
This is also practice for your final project presentation, in which you will go through much the same procedure, but using your own documents and code. For that presentation also, each group member must share equally in the presentation, talking for 7-10 minutes.
8. Test Plan (due Friday, December 4)
Grading Criteria:
• Uses outline: 1 point
• Related documents: 2 points
• High-level design, scripts/programs, plan for testing, plan for bug reporting, configuration control: 3 points each