Student Resources > CMPT 275 > assignment schedule > Final project submission

Project Release 1: Part 1 - Project Documentation

For Part 1 of this project deliverable, you are required to submit revised versions of the set of documents listed below to Coursesys (and, of course, check the revised versions into your SVN directory). Each of these documents should be revised to be consistent with the product your are releasing to your client and to be consistent with corrections suggested in returned marked copies of the earlier versions of the same deliverable. You need only revise the sections of the documents. mentioned below, it is not necessary to revise the other sections of these documents. The whole document, including the sections that were revised and the sections that were not revised, should be submitted. The list of documents (and sections of documents) to update has be reduced to give a manageable workload for the course. If you were actually presenting in an industrial setting all parts of all documents would be need to be revised and up to date.

The indicated sections of each document listed below should be updated. All sections requiring additions or additional revisions are enumerated below.

• A Release Page
• Revised Design document (initially created as Project Deliverable #5)
  • Revised table of contents and revision history
  • Revised class diagram
• Revised Implementation / Test Plan and Test Cases Document (Deliverable # 7)
  • Revised table of contents and revision history
  • Add Post Mortem section
  • Add Getting Started Section
  • Add Know Bugs section

Be sure that your final documents are are submitted to Coursesys and are properly checked into your SVN repository.

Some Helpful Instructions for Final Document Preparation

1) Your release page summarizes all the information about your software release as it is represented by your document package. As discussed in class, the release page should include a list of ALL documents related to the release (not just those documents updated for this deliverable), and their version numbers at the time of release. Follow the format discussed in class (see the configuration management class notes).

2) You will have one revision history for each of your documents. SRS, design document, and test cases document. Be sure to update the revision history for each document that has been changed to reflect the updates you have made.

3) Make all required revisions to the specified sections of the specified documents. Required revisions must include any corrections suggested in the feedback you received for each section of each deliverable you are revising. DO NOT revise sections of the deliverables not listed in the list given in the description of Project Release 1: Part 1 above

4) In your post mortem, discuss what you have learned as a result of doing this project. More specifically:

• First, discuss what you have learned about project management and time estimation. As a part of your discussion, compare your original estimate of the time needed with the actual time needed and draw some conclusions. For example, which phase was the longest? Shortest? Do these observations surprise you?
• Second, discuss what you have learned about testing.
• Third, discuss what you have learned about working in a team setting,

Describe each discussion topic in its own paragraph (1/2 -1 page) and give a descriptive title to each paragraph.

5) The getting started section explains what hardware and software is required to run the system, how the client should install your software system and how you will compile and install your software for the instructor during the UAT (before the instructor becomes the client). This section should be divided into four subsections:

• Software Requirements: List of the software (O.S., etc.) that must already be installed (available) on the target computer in order for your software system to successfully run.
• Hardware Requirements: List the hardware required on the target computer in order for your software system to successfully run
• Installation: Clearly explain all the steps a user must perform in order to successfully install your software system. This includes any customization and/or initialization of any software/hardware required.
• Technical installation for UAT: a detailed step by step set of instructions on how to begin with a copy of your submitted code and end with a functioning version of your product. This series of steps will be consulted when you compile, build and install your code during the UAT, and deviations from the submitted instructions will result in loss of marks on the UAT. NOTE: You MUST start with an uncompiled copy of your code

6) The Known Bugs section lists the known bugs in your software system.

Project Release 1: Part2 - Software System

Submit to Coursys a zipped file containing the implementation of your project. When creating your zip file, make sure you have the following directory structure and content:

• Two text files
  • A text file containing the names, the student numbers, the student account ids and email addresses of all team members in the team: Use the name of your team to name this file following this syntax: <teamname>.txt
  • A README file containing instructions on how to build your system from the submitted code: Be sure to indicate any software you are assuming exists on the computer on which you are building the software. Also indicate if connections to external servers are needed / expected. Feel free to include other important information. This text file should include a copy of the last two parts of the getting started section of your user manual and user interface document.
  • Makesure these files are readily available and visible once your submitted file has been unzipped, i.e., do not hide these files deep into your directories. Put them into the same directory as the four directories listed below
• and four directories
  • src ------ must contain all your SOURCE code files (*.java OR *.c OR *.cpp OR *.h only). DO NOT SUBMIT *.class *.obj *.exe *.jar *.dll ... files which include all code developed by your group. YOU WILL NOT BE PERMITTED TO USE ANY submitted compiled (*.class *.obj *.exe *.jar *.dll ...) files containing code written by your group during your UAT
  • lib ------ anything else your software will require to execute such as:
    • Non standard C++ or Java Libraries.
    • Additional packages or code not developed by your team
    • You may submit and use compiled files (.jar or .exe or .dll or ...) files containing containing code for libraries and packages not written by your group
  • dat ------ your data directory: Be sure to include all data you will need for your UAT
    • Test data to be used to demonstrate the system
    • .csv files for use as input for your demonstrations
    • sample student submissions
    • sample solutions
    • and/or ...(you get the picture :-)
  • misc ------ anything else I may be forgetting that would be specific to your software system.

Feel free to create sub directories under the directories listed above.
Finally, make sure your *.c, *.cpp, *.h, *.java files are consistent with the present version of C++, C, or JAVA in use in CSIL. For this term project the present CSIL windows configuration will be considered to be the configuration available on the clients systems.

Marking Scheme - out of 100

For Part 1 - Project Documentation - We may look at

• Is your release page complete and consistent with your documents?
• Have the required sections of specified documents been revised?
• Do the revised sections of your documents include all corrections from earlier deliverables?
• Have all incomplete sections of your documents been completed?
• Clarity, completeness, and correctness of revisions / additions to text of the documents
• Clarity, completeness, and correctness of revised diagrams representing the model of your software system (seqence diagram, class diagram)
• Organization and neatness (including spelling and grammar)
• Proper use of SVN and revision histories to document changes.

For Part 2 - Code - We may look at

• Completeness and format of software system submission
• Quality of comment blocks (descriptions that are part of the class skeleton) and internal comments (inside source code
• Consistent use of the class skeletons. A minimal class skeleton should include a description of the class / method, authors or licensing, and revision history
• Whether you have acknowledged authors of code you are reusing
• Whether or not your implemented classes match your design document

Specifically:

• 1 marks for Release Page
• 15 marks for Design Document Updates
• 20 marks for Implementation / Test Plan and Test Cases Document updates
• 6 marks for the format and completeness of the submitted zipped project.
• 8 marks for quality of comments
• 6 marks for authorship and release information (in each method)
• 38 marks for consistency of the submitted software system with the design document
• 6 marks for consistency and completeness of class skeletons and for consistent use of the class skeleton in all classes by all team members