CSC 307 Milestone 10

CSC 307 Milestone 10
Completed Design and Implementation
Completed Testing




Due: 11:59PM Wednesday December 9th

Deliverables:

Finished Design and Implementation:

  1. Finish the implementation of the agreed upon requirements, per the comments at the end of the Milestone 6 evaluations, and the discussions of these evaluations during the Week 7 lab meetings. If you have any questions about the requirements to be implemented, please ask.

  2. Provide design documentation for all packages, classes, methods, and data fields

    1. The handout for the 307 Design and Implementation Conventions has details for what the documentation entails.

    2. In particular, class documentation must consist of

      1. a description of the purpose of the class

      2. a summary of the methods that the class provides

      3. for classes that define a significant data structures, a description of what the data structures are, including pictures if necessary

      4. for classes that implement a significant piece of processing, a description of the processing algorithms employed

    3. At the end of the conventions handout is the following point breakdown for the design documentation:
      • packages: 5%
      • classes: 15%
      • methods: 12%
      • data fields: 8%
      which means you will lose up to 40% of the points for your portion of the milestone if any or all design documentation is missing.

Testing:

  1. Per team member, write preconditions and postconditions three additional model methods, in addition to the three methods for which you wrote Spest in the previous milestones. That is, each team member must define the preconditions and postconditions for a total of six of their model methods. The model methods must have some non-trivial logic in their implementation, which is defined simply as having at least one conditional or loop statement.

  2. Per team member, use Spest to generate unit tests for three of the of the methods that have Spest specs; for the other three methods, write the unit tests by hand. This means a total of six unit-tested model methods per team member -- the three model methods you tested for Milestone 8 plus three more for Milestone 10. And for Milestone 10, all the tests must execute, meaning they report results. If you have issues using Spest to generate tests for some methods, choose different methods for the Spest-generated tests.

  3. Describe what's necessary to execute your tests in the HOW-TO-RUN-TESTS file described below. The meaning of "test execution" is the following:

    1. the tests produce a unit test report, with no errors for all tested methods

    2. the test execution produces a coverage report; if the Spest-generated test do not achieve 100% branch coverage of all tested methods, you must write additional unit tests to get to 100% coverage; note that you are not required to produce 100% coverage all methods, only for the methods that have unit tests
Administration:

  1. Refine as necessary the administration/HOW-TO-RUN.html file you provided for milestones 7-8.

    1. This file explains how to start up the one or more executables for your project.

    2. Where necessary, be very precise about what commands the end-user performs, what files need to be present, and any other necessary support structures that need to be in place for execution to be successful.

  2. Provide an m10-duties.html file.

    1. It itemizes for each team member the parts of the project that produce execution results.

    2. It also itemizes precisely for each team member what aspects of the implementation the member is responsible for.

  3. Provide an administration/HOW-TO-RUN-TESTS.html file, describing exactly how to run the one or more testing executable programs, how to run the coverage checker, and where the results of the testing are stored.

  4. Provide an optional README.html file, containing any general project information you'd like to supply, such as an explanation of what things don't work and why.

  5. Update work-breakdown.html as necessary. (The work-breakdown file defines overall project responsibilities. The m10-duties file defines the specific work for Milestone 10. For example, work- breakdown can say that team member X is working on all of the classes in a particular package. The m10-duties file will say which particular classes and methods are the focus of work for Milestone 10.)




index | lectures | handouts | examples | textbook | doc | grades