This describes how to submit the final version (v. 2) of the code, and
what is required for the final demo (Misc. Tasks 3-5) and User
Manual (Misc. Task 6). Note: everything is due on Dec. 3. (Remember that version 1 was supposed to be a
complete, compiled, unit-tested --but not integrated-- implementation of
release 2 features of the code, and any drivers or stubs for unit testing.) The final version of the code should be a
complete compiled, integrated, running system (release
2 features). See the course web page for information on how the
implementation will be graded.
Definitions of implementation Version 1 and 2
(Note: You have already done version 1; the information about version 1 is repeated here for context. Follow the instructions for version 2 now!)
· Version 1: Your group should have designed the system architecture so that classes can be implemented and unit tested by each student alone without depending on other students in your group. Remember that only one student can get credit for a class (see Grading information about implementation deliverables on course web page). For example, your 6-person group has divided the product into 2 classes in each of the 3 layers. Assuming that the classes are the same length and complexity, then you would assign each person one class to implement. For version 1 each person implements his/her class or classes and creates additional code, drivers and stubs, to enable him/her to thoroughly test his/her class/es. (A driver is a test program that shows that the class works by calling all of its methods with test arguments. Stubs are fake methods or objects that you create to enable your code to be partially tested independently of the other classes that your class uses.) Each person will turn in, individually, for one task unit of credit:
o Classes implemented: C++ source code for each class, with comments fully documenting the class as a whole and each method and major data structure (public and private). Do not turn in any code that does not compile or that does not work with the drivers and stubs that your turn in! You may only receive credit for code that does compile and that does pass unit testing!
o Drivers implemented: any C++ source code used as drivers for your class(es), with header comments documenting what class it is used to test and with in-line comments documenting test case arguments and expected results
o Stubs implemented: any C++ source code used as drivers for the class with header comments documenting what classes the stub is used as a substitute for
· Version 2: To create this version, your group will integrate the unit-tested (version 1) code; drivers and stubs should no longer be necessary. No new functionality will be added; only bug fixes will be made. However, if code cannot be fixed and integrated in time for the delivery date then stubs and drivers may be used at the demo and the missing units will not receive credit for version 2.
Submission Instructions for Implementation v. 2 and Other Final
Deliverables
Paper – Individual Code: Turn in a paper copy of your own code with: (1) a single cover page stating your name, project name, and “version 2”; (2) a second page with an alphabetically ordered list of the classes that you implemented, and for each class whether or not it is has been integrated into the group demo; and (3) the code listings in the same order as the table of contents. Fasten (stapled or paper clipped) all the sections of your task unit together. Turn in each person’s work separately. It is important to follow these instructions so that you get proper credit for your work!
On-line – Individual Folders: The on-line version of each person’s source code should be put in a subfolder called <yourname>-individual-code-v2 under the folder for your group called Implementation-final-individual. For example, a student named Green would turn in her source code in a folder called Green-individual-code-v2. Finally, copy the information listed under (1)-(2) of the paper version (described above) into a readme file in this folder. (Remember that students can access their folders from off-campus using NetStorage. I will check the folder 30 minutes before the beginning of class on the due date.)
On-line – Group Folder: The group member responsible for Misc. Task Unit 5 should put a copy of the complete integrated system in the folder Implementation-final-group. This should include both source code and executables, and any sample input/output files necessary for running the group demo from this folder. (Do not include any code that is not part of the working, integrated system. Do not include any drivers or stubs unless they are needed to demonstrate certain features because total integration failed.) Also, a brief readme file should be included in the folder giving any information needed to install and/or run the group’s product from this folder (including information about any stubs or drivers included in the final version).
User Manual (Misc. Task Unit 6): Include a title page with your product name, “User Manual”, your group members, and your name. First, the user manual should describe how to use each feature. (You may cut and paste text from other written deliverables but the end result should be understandable.) Second, the user manual should cover a user going through at least one detailed scenario, with screen shots illustrating the text; you may work with the person giving Part I of the PowerPoint demo presentation and use the same scenario and screen shots. The user manual should be turned in both as an on-line copy (in a file named UserManual in the Implementation-final-group folder) and as a printed copy before the demo.
Live Demo: For content, see detailed outline below. Each person doing a PowerPoint presentation should put an on-line copy of his/her Demo slides in a folder under the project folder named FinalDemoSlides. Also, turn in a printed copy of the slides to the instructor before the demo.
Demo Outline for Implementation version 2
Part I - Requirements (15 min PowerPoint presentation, 20-30 slides) – Misc. Task Unit 3:
· Title slide with name of product and list of group members and your name
· Describe the intended class of users and the problems that your product solves for them
· Describe the user requirements
· Describe several scenarios that show the benefit of your product and will be shown live in part III of the demo
o Use screen shots to illustrate the scenario
o Coordinate your work with the User Manual writer so that the two of you can share some of the work
· Briefly describe the main system requirements
Part II – Internal Design (15
min PowerPoint presentation, 15-20 slides) – Misc. Task Unit 4:
· Title slide with name of product and list of group members and your name
· Describe high-level system architecture (layers with all classes in each layer)
· Describe sequence diagrams for one or two of the scenarios covered in part I that show the flow of messages from object to object through all three layers
· Describe important algorithms (e.g. merging tables in Table Manager, comparing email to rules in Email Classifier) and their space/time complexity
Part III (15 min live demo) –
part of Misc. Task Unit 5:
· Note: before the day of the demo, you are responsible for creating interesting sample files for the demo (both for the scenarios and for the unsupervised part of the demo)
· Demonstrate the program using the scenarios discussed in Part I
· Demonstrate features not covered in the scenarios
Part IV (15 min live unsupervised
demo):
The audience (mainly the instructor) is given a chance to try the product.
Send comments and requests about this web site to nlgreen@uncg.edu