Skip to content

Release Planning

Jump to bottom
Monica Bui edited this page Apr 4, 2018 · 11 revisions

Internal Schedule

February 5, 2018 - February 9, 2018

  1. Start creation of internal schedule
  2. Half of use cases
  3. Start UI diagram

DONE

February 11, 2018 - February 17, 2018 (Project Part 2 due Friday February 16, 2018)

  1. All of the use cases
  2. Finish UI Diagram
  3. Finish release planning

DONE

February 18, 2018 - February 23, 2018 (Reading Week)

  1. UML diagram
  2. Unit tests
  3. Clean up user interface
  4. UC 01.01.01
  5. UC 01.02.01
  6. UC 01.03.01
  7. UC 01.04.01
  8. UC 02.01.01
  9. UC 02.02.01
  10. UC 03.01.01
  11. UC 03.02.01
  12. UC 03.03.01
  13. Peer review forms
  14. Address TA feedback

DONE

February 25, 2018 - March 3, 2018 (Project Part 3 due Monday February 26, 2018)

  1. Polish the first 3 use cases

  • Elastic Search for UC 01.01.01, US 01.02.01

  • U.I , Implement US 02.02.01

  • Implement US 02.01.01

  • Implement US 03.02.01

  • Implement US 01.03.01

  • Implement US 03.03.01

  • Implement US 01.04.01

Done

March 4, 2018 - March 10, 2018

Refine use cases 1-4 and test them first before doing the rest of 5.

  1. UC 04.01.01
  2. UC 04.02.01
  3. UC 05.01.01
  4. UC 05.02.01
  5. UC 05.03.01
  6. UC 05.04.01
  7. UC 05.05.01
  8. UC 05.06.01
  9. UC 05.07.01

DONE

March 11, 2018 - March 17, 2018

  1. Fix any remaining bugs
  2. Finish use cases 5
  3. Code documentation
  4. Test cases
  5. Update UML diagram
  6. Update info sources

March 18, 2018 - March 24, 2018 (Project Part 4 due Monday March 19, 2018)

  1. UC 06.01.01
  2. UC 06.02.01
  3. UC 07.01.01
  4. UC 07.02.01

March 25, 2018 - March 31, 2018

  1. UC 08.01.01
  2. UC 09.01.01
  3. UC 09.02.01
  4. UC 09.03.01

April 1, 2018 - April 7, 2018

  1. UC 10.01.01
  2. UC 10.02.01
  3. UC 10.03.01
  4. Record promotional video
  5. Prep live demo
  6. Test Cases
  7. Update UML and sources

April 8, 2018 - April 10, 2018 (Project Part 5 due Monday April 9, 2018)

  1. Practise demo
  2. Fix any bugs from last week
  3. Update any info from previous project parts
  4. Document code
  5. Live Demo (April 10, 2018)
  6. Wow Factor Use case 11

External Schedule

Project Part 2

  • Requirements Specification: Describe, using detailed textual use cases, the tasks for using the application. Number the use cases.
  • User Interface Mockup and Storyboard: Diagram the layout of your main user interface and major dialogs, with comments describing the important elements. Also, provide storyboard sequences of using your application, with transitions between different states of the user interface, caused by the user manipulating the controls or providing input. Enter this information in your team wiki.
  • Release Planning: Plan the major use cases and user stories that need to be done for project part 4, and what will be deferred until later for project part 5. This plan will likely evolve and should be maintained up-to-date in your team wiki. This will be used to help track progress on completing the requirements. You must have some server connectivity working by project part 4.
  • Glossary and Information Sources: Define any special terminology in the application domain (i.e., not programming terms). Provide a list of useful informational references or links to related or competitive products. Enter this information in your team wiki. Please clearly state the open source license for your project.

Project Part 3

  • Addressing Feedback: Address any TA feedback on the previous project part.

  • Object-Oriented Analysis and Design: Document your initial object-oriented analysis and design using a UML class diagram (or diagrams), focusing on the most important anticipated classes, interfaces, and relationships. Include detail on key attributes and methods. Add notes if the purpose of a class or interface is likely not clear to an outsider. The diagram(s) may be reverse engineered from the code, but must be edited, arranged, and selective (not a raw dump). The diagram(s) must be neat and tidy, and drawn well using computer tools. The diagram(s) must be embedded as image(s) in your team wiki, not linked externally. The diagram(s) will likely evolve.

  • Unit Testing: Write runnable unit tests for your model classes. Code is required, and signatures of methods in the model classes must be present, but the full implementation of the model classes need not be complete.

Project Part 4

  • Addressing Feedback: Address any TA feedback on the previous project part.

  • Code Base of Prototype: Your system will be demonstrated in the lab and its source code will be inspected. The code should conform to some consistent coding convention. At this point, your prototype should be implemented to provide something tangible to the user, supporting about half the requirements. Deliver the source code to your source repository.

The code base must be synchronized with the test cases and the requirements spec and the UML diagrams.

  • Code Documentation: For each source code file, you should have a brief introductory comment describing its purpose or role within the application or a design pattern, as well as any currently outstanding issues. Provide Javadoc interface documentation for your model classes and their public methods (at least). Deliver the generated Javadoc documentation to your source repository.

  • Test Cases: Provide unit tests for your model classes. Provide intent tests for the use cases you support. Deliver the test code to your source repository. If you have test data files, also include those. Test data should be realistic.

  • Object-Oriented Design: Update your object-oriented design using a UML class diagram (or diagrams), including detail on key attributes and methods. Include notes on the use of design patterns among the classes. The diagram(s) may be reverse engineered from the code, but must be edited, arranged, and selective (not a raw dump). The diagram(s) must be neat and tidy, and drawn well using computer tools and embedded as image(s) in your team wiki. The diagram(s) will likely evolve.

  • Release Planning: Plan the major use cases and user stories that need to be done for project part 5. This plan will likely evolve and should be maintained up-to-date in your team wiki. It should be clear from the plan the progress towards satisfying all the specified requirements.

  • Reuse Statement: Document instances of software reuse. Give proper credit to the original developers. Obtain approval for the use of third-party libraries as appropriate. Enter this information in your team wiki.

Project Part 5

  • Addressing feedback: Address any TA feedback on the previous project part.

  • Code Base of Prototype: Your final system release will be demonstrated in the lab to evaluate the usability of its user interface and the degree to which its functionality fulfills the user's needs. The source code will be inspected. The code should conform to some consistent coding convention. Deliver the updated source code to your source repository. The code base must match the UML. The code base must match the other artifacts of the project.

  • Code Documentation: For each source file, you should have a brief introductory comment describing its purpose or role within the application or a design pattern, as well as any currently outstanding issues. Provide Javadoc interface documentation for your model classes and their public methods (at least). Deliver the updated generated Javadoc documentation to your source repository.

  • Test Cases: Provide unit tests for your model classes. Provide intent tests for all the use cases you support. The tests should now generally pass. Deliver the updated test code to your source repository. If you have test data files, also include those. Test data should be realistic.

  • Requirements Specification: Provide the updated textual use cases and user stories for the application.

  • Object-Oriented Design: Update the structure of your object-oriented design using a UML class diagram (or diagrams), including detail on key attributes and methods. Include notes on the use of design patterns among the classes. The diagram(s) may be reverse engineered from the code, but must be edited, arranged, and selective (not a raw dump). The diagram(s) must be neat and tidy, and drawn well using computer tools and embedded as image(s) in your team wiki.

  • Release Planning: Your team's release plans will be inspected. It should be clear from the plans the coverage toward satisfying all the specified requirements, the status of your project, and the work done by the team. Note any work that was not done, which would be planned for the "future".

  • Reuse Statement: Document instances of software reuse. Give proper credit to the original developers. Obtain approval for the use of third-party libraries as appropriate. Enter this information in your team wiki.

  • Demo Presentation: Provide an engaging demo. Make sure your demo presentation is live, not a playback of a recording.

  • Promotional Video: Upload a video demo of your application to youtube or another video sharing site and embed or link to it from the front page of your wiki. This video is meant to promote your application and highlight the key features (in under 5 minutes maximum).

Copyright 2018 Monica Bui, Jolene Poulin, Shuai Li, Atharv Vohra, Eivenlour David, Fangting Chen

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Clone this wiki locally