Project Part 4
Project Part 4 -- Final Checkpoint
- Due date: Check the schedule.
Learning Objectives
- Develop a usable, interactive, mobile application.
- Produce a product demonstration.
- Follow scrum practices.
Overview
Your product is ready to be released!
Most deliverables are final, consistent updates of what was initiated for the previous project part.
Deliverables
-
Addressing feedback: Address any TA feedback on the previous project part.
-
Code Base of Prototype: Your source code will be inspected. The code should conform to some consistent coding convention. Maintain the source code in your source repository.
-
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).
-
Test Cases: Write runnable tests for your model and control classes. Provide intent tests for the requirements you have done. 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 details on key attributes and methods. Add notes as appropriate to clarify. Include notes on the use of design patterns among the classes.
-
Product Backlog: Update the requirements as appropriate. Note which user stories are done at this checkpoint.
-
User Interface Mockups and Storyboards: Update these diagrams as appropriate.
-
Sprint Planning and Reviews: Maintain a record of what user stories are planned for each weekly sprint at its start, including who is to work on them. For each intermediate week, in the lab, have a sprint review with your TA mentor and all team members present to review the completed user stories.
-
Demonstration: Present an engaging demo. The final demo of your final prototype should show the usability of its user interface and the degree to which its functionality fulfills the user's needs. All team members must contribute to the demo. 20240327 clarification: During the last week of labs you and your team will present this demo in less than 4 minutes to the entire lab. It will be your app live, with your team members. No videos, audio, or powerpoint. Just your live app. Make backup videos of the functionality in case your demo fails. Practice your demo in the lab room ahead of time. Make sure you can present your app by testing the projector and your devices the week of April 2,3,4. All teams should participate.
-
Tool Use: Regular and consistent use of GitHub by all team members to share files for the project deliverables, to effectively track issues, and to manage tasks. There must be consistency across the deliverables at this checkpoint.
The evaluation of this project part will also include a component called "relative quality". This is used to differentiate projects that meet the minimum from projects that go "the extra mile".
Restrictions
Use Java, with Android, and Firestore.
Submission Procedure
Use GitHub. Your team repo must be self-contained, i.e., not link to external content that might change.
Please make sure your repository has the right version of code by the deadline. The TA will try to build your program from the submitted code. The TA may contact you if there are build issues.
If you reuse software, give proper credit to the original developers. Obtain approval for the use of third-party libraries as appropriate.
This demo should have a logical flow in what is presented (following a story about what a user would naturally do, not just enumerating assorted features).
Individual Task and Peer Review Form
After the due date, each member must complete an assessment form to describe his or her individual contribution to the project for this stage, and to review the performance of the other members.
Marking
No part marks, no extra marks. No half marks.
-
Failure (0) :
- Incomplete. Missing important components.
- Or no submission
-
Poor (4)
- A project that effort has been put into and doesn't meet the requirements described. Most deliverable points have been met.
-
Unsatisfactory (5)
- A project submission that is missing components. Inconsistency is key. Missing important test cases. Lack of planning or adherence. Lack of attendance etc. Must demonstrate clear understanding of purpose and rationale behind deliverables.
-
Satisfactory (6)
- A project submission that is missing minor components and contains some rough elements, but is NOT missing anything major.
-
Good (7)
- A not-quite excellent submission that meets the majority of all the requirements without problem.
-
Excellent (8)
- A excellent submission that meets the all the requirements without problem.
- A flawless project that meets the requirements described.