All progress reports for Team20 should be updated with the link below:
https://docs.google.com/document/d/1prMKFoJ215ErJ2KCtvMhDXFKkg-5J1QH820hTNTQ0KU/edit?usp=sharing
Object Oriented Analysis >> Why ingredient has no collaborator, Are ingredients not stored in some class. >>What you mean by food in responsibilities of storage, there is no class named food, I think you meant ingredients. Why recipe and storage are named multiple times in collaborators one time is enough (same for other crc cards). >>Mealplan should not have a responsibility of changing the servings. The responsibility “knows the number of servings” should be “knows the number of servings of each recipe or item in the meal plan”. Why shoppinglist contains the list of ingredients in storage and list of ingredients needed for meal plan, it should only contain the list of ingredients required to buy. Fragments and activities are UI classes, you can also say that they are controllers, they should not have responsibilities of business logic, they only display things or take things as input, they don’t sort, store, add, edit, delete things. >> Cohesive classes: some classes interact with many other classes, this should not be the case, first remove your business logic from ui, controller logic, reduce the cohesion between classes >> Coupling managed: no, only one module based design, divide your classes into multiple modules Product Backlog
✘ Requirements are not numbered
##Project Part 3 Rubric
Addressing Feedback • All well addressed • Issues tracked
Code Base of Prototype • Excellent quality • At least ½ of requirements implemented and fully done • Comprehensive connectivity to server • Clear and readable code with useful comments • Follows conventions • Checks for errors
Code Documentation • Third party could easily understand • Complete and correct Javadoc comments for entity (model) classes and methods • Consistent with requirements, design, code, and tests
Test Cases • Test exist and can run • Convincing and passing testing for completed implementation • Comprehensive unit tests of entity (model) classes • Comprehensive intent tests for implemented user stories • Correct tests • Realistic test data • Consistent with requirements, design, code, and documentation
Object-Oriented Design • Proper OO design with clear design intent • Separation of concerns and/or layering • Encapsulation and information hiding • Clear classes and interfaces • Key elements described • Correct notation • Neatly laid out and labeled diagrams • Helpful explanations or commentary • Consistent with requirements, code, tests, and documentation
Product Backlog (Updated) • Numbered, tracked, and organized requirements • Comprehensive requirements • Complete story point estimates • Complete risk levels • Displays understanding of requirements specification/elicitation • Requirements noted for half-way checkpoint
User Interface Mockup and Storyboard (Updated) • Consistent and clear • Complete UI mockups • Labeled elements on UI mockups • Detailed storyboard • Labeled actions for storyboard transitions • Covers all requirements • Intuitive user interface • Displays understanding of UI mockups and storyboarding
Sprint Planning and Reviews • Comprehensive • Displays understanding of Scrum • Displays regular and frequent pacing of working software • Each sprint is planned by user story • Riskier requirements are done earlier • Each sprint is reviewed • Members all present at each review • User stories are fully “done done” (implemented, tested, integrated, documented) • Early and frequent integration • Continuous integration actions
Tangible Demo • Demo ability • Clear and coherent • Logically organized by tangible features • Realistic data and inputs • All members present • Members well coordinated
Code Base of Prototype
• Excellent quality • At least ½ of requirements implemented and fully done • Comprehensive connectivity to server • Code is clear • Readable • Useful comments • Checks for errors • Follows conventions
Relative Quality
• Well above average relative quality, overall comprehensiveness, creativity, attractiveness, and innovation
##Project Part 3 Rubric
Addressing Feedback • All well addressed • Issues tracked
Code Base of Prototype • Excellent quality • At least ½ of requirements implemented and fully done • Comprehensive connectivity to server • Clear and readable code with useful comments • Follows conventions • Checks for errors
Code Documentation • Third party could easily understand • Complete and correct Javadoc comments for entity (model) classes and methods • Consistent with requirements, design, code, and tests
Test Cases • Test exist and can run • Convincing and passing testing for completed implementation • Comprehensive unit tests of entity (model) classes • Comprehensive intent tests for implemented user stories • Correct tests • Realistic test data • Consistent with requirements, design, code, and documentation
Object-Oriented Design • Proper OO design with clear design intent • Separation of concerns and/or layering • Encapsulation and information hiding • Clear classes and interfaces • Key elements described • Correct notation • Neatly laid out and labeled diagrams • Helpful explanations or commentary • Consistent with requirements, code, tests, and documentation
Product Backlog (Updated) • Numbered, tracked, and organized requirements • Comprehensive requirements • Complete story point estimates • Complete risk levels • Displays understanding of requirements specification/elicitation • Requirements noted for half-way checkpoint
User Interface Mockup and Storyboard (Updated) • Consistent and clear • Complete UI mockups • Labeled elements on UI mockups • Detailed storyboard • Labeled actions for storyboard transitions • Covers all requirements • Intuitive user interface • Displays understanding of UI mockups and storyboarding
Sprint Planning and Reviews • Comprehensive • Displays understanding of Scrum • Displays regular and frequent pacing of working software • Each sprint is planned by user story • Riskier requirements are done earlier • Each sprint is reviewed • Members all present at each review • User stories are fully “done done” (implemented, tested, integrated, documented) • Early and frequent integration • Continuous integration actions
Tangible Demo • Demo ability • Clear and coherent • Logically organized by tangible features • Realistic data and inputs • All members present • Members well coordinated
Code Base of Prototype
• Excellent quality • At least ½ of requirements implemented and fully done • Comprehensive connectivity to server • Code is clear • Readable • Useful comments • Checks for errors • Follows conventions
Relative Quality
• Well above average relative quality, overall comprehensiveness, creativity, attractiveness, and innovation
3 = addressed mostly all feedbacks
3 = Consistent and clear • Complete UI mockups • Labeled elements on UI mockups • Detailed storyboard • Labeled actions for storyboard transitions • Covers all requirements • Intuitive user interface • Displays understanding of UI mockups and storyboarding
3 = - Comprehensive
- Displays understanding of Scrum
- Displays regular and frequent pacing of working software
- Each sprint is reviewed -User stories are fully “done done” (implemented, tested, integrated,documented)
- Early and frequent integration
3 = • Very good Demo ability • Clear and coherent • Logically organized by tangible features • Realistic data and inputs • All but one member was present • Members well coordinated
2 = • Somewhat above average relative quality, overall comprehensiveness, creativity, attractiveness, and innovation
3 = • Approximately ½ of requirements implemented and fully done • Connectivity to server • Readable Comments are useful
3 = ✓ Numbered, tracked, and organized requirements ✓ Tracked, and organized ✓ Comprehensive requirements ✓ Complete story point estimates ✓ Complete risk levels ✓ Requirements noted for half-way checkpoint ✓ New requirements are added to the backlog regularly
1 = ✓ Comprehensive intent tests for implemented user stories ✓ Correct tests wtih realistic data ✘ No unit tests of entity (model) classes implemented ✘ All intent tests fail due to the file "google-services.json" being missing
There are many set of classes that are stand alone. which means that they won't have a relationship with other set of classes, I don't think this is the case for example category which is composed in ingredient but this relation is not shown in uml.
Total = 9.11
Demo ability / Polished / Clear and coherent / Motivated / Compelling, holds attention, tells a story / Coverage of features logically organized by customer usage / Well explained user interface / Easy to follow user roles / Realistic data and inputs / All members present / Team well coordinated in demo / Within time limit / No misspellings / Clear vocals from everyone / Eye contact, rarely consulting or reading notes / Involves the audience / Good and concise responses to questions