Appearance
Rubrics
As we progress through the course, I will update this page with rubrics for various graded coursework.
Classwork
| Item | Points |
|---|---|
| Submission is missing solutions to most of the tasks or most solutions are incorrect. | 0 |
| Most tasks were attempted and their solution seems to be mostly correct. | 0.5 |
| All tasks were attempted and their solution is mostly correct. | 1 |
Homework
| Item | Points |
|---|---|
| A user must be able to create flashcards. | 1 |
| A user must be able to read flashcards. | 1 |
| A user must be able to update existing flashcards. | 1 |
| A user must be able to remove flashcards. | 1 |
| The system must be able to persist the flashcards. | 1 |
| A user should be able to create decks. | 0.5 |
| A user should be able to add flashcards to a deck. | 0.5 |
| A user should be able to view decks and the flashcards therein. | 0.5 |
| The app has a nice-to-have or authentication feature. | 0.5 |
| README includes detailed instruction on how to run the app locally. | 1 |
| README includes detailed infromation such as app functionality, tech stack, etc. | 1 |
| Code exhibits good practices for writing readable code such as consistent indentation, descriptive naming, code comments (only when needed), etc. Moreover, the submission shows a good programming style: code is modularized so at various levels of abstractions into packages, modules, files, classes, functions, etc. | 1 |
Presentation
Product Pitch (15 points)
| Item | Points |
|---|---|
| Failed to use slides (or other forms of visuals) to supplement the delivery. | -8 |
| Failed to clearly and succinctly communicate the motivation for the project (the problem they are trying to solve). | -3 |
| Presented fewer than 4 must-have user stories (or presented trivial ones such as "user authentication" where every app has one!) | -5 |
| Failed to present at least one user story (a nice-to-have requirement) that captures an interesting (non-trivial, beyond CRUD) feature of the app (unless they don't have any of that!) | -3 |
| Failed to clearly state the high-level software architecture, technology stack, ..., for this project. | -3 |
| Failed to clearly present and elaborate their roadmap. | -5 |
| Little or no effort was made in building excitement about the application. | -2 |
| The presentation was not coherent/well organized. The flow from speaker to speaker was not smooth. E.g., they needed to huddle mid-presentation to decide what to do next. | -5 |
| The presentation went well over the allotment. | -3 |
Product Delivery [Practice] (35 points)
| Item | Points |
|---|---|
| Failed to provide a live demo. | -10 |
| For the live demo, the team did not use the deployed app but rather a version running locally. (Unless the issue is beyond their control, e.g., Heroku is down!) | -5 |
| During the live demo, the app crashed/stopped working (or did not behave as expected/planned) on more than one occasion. The issue seems to stem from poor preparation. | -5 |
| For the demo, they presented use-cases that are too trivial (like user signup or login/logout, etc). | -3 |
| For the demo, they presented fewer than 4 user stories. (Unless that is all they have! or some use cases were so complex and non-trivial that allocated time did not allow presenting more stories!) | -5 |
| For the demo, they failed to show at least one user story that captures an interesting (non-trivial, beyond CRUD) feature of the app. (Unless they don't have any!) | -3 |
| During the demo, when (if) asked by staff to carry a use case, they failed to promptly follow instructions. | -2 |
| During the demo, when (if) asked clarifying questions, the speaker was not able to respond with explanation/elaboration or failed to demonstrate full knowledge of the work done. (E.g., another member had to jump in and answer in their place!) | -3 |
| Failed to use slides (or other forms of visuals) to supplement the presentation. | -8 |
| Failed to clearly state the high-level software architecture, technology stack, ..., used for this project. | -2 |
| Failed to succinctly describe the high-level (object-oriented, data model, ...) design of the software. | -2 |
| Diagrams (e.g., UML, wireframes, ...) were absent or inconsistent with the narrative. | -3 |
| When (if) asked clarifying questions, the speaker was not able to give credible justification for the design choices they made, and/or was not able to articulate the strengths and weaknesses of the choices they made. | -5 |
| Failed to describe note-worthy details such as the libraries, third-party APIs, algorithms, data structures, ... used (i.e., things that take the project beyond simple CRUD) at a level of detail appropriate for the audience, and the time frame of the presentation. (Unless they don't have any of those!) | -5 |
| The technical information was presented either at a too abstract or too detailed level. The delivery was not smooth, e.g., slides were not logically ordered, they needed to constantly pause and ask someone to go back and forth between slides, etc. | -5 |
| Failed to describe testing in sufficient details details such as the libraries used, how they mocked services, what code coverage they have, etc. (Unless they don't have any tests!) | -5 |
| The delivery fails to hold the attention of the audience. The speakers are not enthusiastic about the demo! | -2 |
| The presentation was not coherent/well organized. The flow from speaker to speaker was not smooth. E.g., they needed to huddle mid-presentation to decide what to do next. | -5 |
| The audience had to make a considerable effort to understand the demo on more than one occasion. The issue was not logistical (nor language barrier) but rather stems from a lack of preparation. | -5 |
| Failed to divide up this section amongst group members; only one or two members did most of the talking (unless fewer than 5 members are remaining in the team!) | -3 |
| The presentation went well over the allotment. | -5 |
Product Delivery [Final] (100 points)
| Item | Points |
|---|---|
| The opening remark lacked overall organization. The speaker seems to not have been prepared. | -5 |
| Failed to clearly and succinctly communicate the motivation for the project (the problem they are trying to solve). | -5 |
| Failed to provide a live demo. | -20 |
| For the live demo, the team did not use the deployed app but rather a version running locally. (Unless the issue is beyond their control, e.g., Heroku is down!) | -7 |
| During the live demo, the app crashed/stopped working (or did not behave as expected/planned) on more than one occasion. The issue seems to stem from poor preparation. | -7 |
| For the demo, they presented use-cases that are too trivial (like user signup or login/logout, etc). | -5 |
| For the demo, they presented fewer than 4 user stories. (Unless that is all they have! or some use cases were so complex and non-trivial that allocated time did not allow presenting more stories!) | -7 |
| For the demo, they failed to show at least one user story that captures an interesting (non-trivial, beyond CRUD) feature of the app. (Unless they don't have any!) | -5 |
| During the demo, when (if) asked by staff to carry a use case, they failed to promptly follow instructions. | -5 |
| During the demo, when (if) asked clarifying questions, the speaker was not able to respond with explanation/elaboration or failed to demonstrate full knowledge of the work done. (E.g., another member had to jump in and answer in their place!) | -5 |
| Failed to use slides (or other forms of visuals) to supplement the presentation. | -10 |
| Failed to clearly state the high-level software architecture, technology stack, ..., used for this project. | -5 |
| Failed to succinctly describe the high-level (object-oriented, data model, ...) design of the software. | -5 |
| Diagrams (e.g., UML, wireframes, ...) were absent or inconsistent with the narrative. | -5 |
| When (if) asked clarifying questions, the speaker was not able to give credible justification for the design choices they made, and/or was not able to articulate the strengths and weaknesses of the choices they made. | -7 |
| Failed to describe note-worthy details such as the libraries, third-party APIs, algorithms, data structures, ... used (i.e., things that take the project beyond simple CRUD) at a level of detail appropriate for the audience, and the time frame of the presentation. (Unless they don't have any of those!) | -7 |
| The technical information was presented either at a too abstract or too detailed level. The delivery was not smooth, e.g., slides were not logically ordered, they needed to constantly pause and ask someone to go back and forth between slides, etc. | -7 |
| Failed to describe testing in sufficient details details such as the libraries used, how they mocked services, what code coverage they have, etc. (Unless they don't have any tests!) | -7 |
| Failed to succinctly communicate the status of the project including work not done, the issues/bugs/limitations of the software (what the app does not/cannot/will not do) | -12 |
| Failed to describe future work. | -5 |
| Failed to describe take-aways and reflect on their work as a team. The conclusions simply involved restating information without reflective thought. | -7 |
| The closing remark lacked overall organization. The speaker seems to not have been prepared. | -5 |
| The delivery fails to hold the attention of the audience. The speakers are not enthusiastic about the demo! | -5 |
| The presentation was not coherent/well organized. The flow from speaker to speaker was not smooth. E.g., they needed to huddle mid-presentation to decide what to do next. | -7 |
| The audience had to make a considerable effort to understand the demo on more than one occasion. The issue was not logistical (nor language barrier) but rather stems from a lack of preparation. | -7 |
| Failed to divide up this section amongst group members; only one or two members did most of the talking (unless fewer than 5 members are remaining in the team!) | -5 |
| The presentation went well over the allotment. | -5 |
Project Iterations
Total posts: 100 (per iteration)
Software Development Process [10 points]
| Item | Points |
|---|---|
| The project README is outdated or incomplete. | -3 |
| The project Wiki is outdated or incomplete. | -3 |
| The project planner (GitHub Project) is either disorganized or outdated. | - 5 |
| There is a missing, incomplete, or poorly written plan for the user stories that were planned for implementation in this iteration. Advisors: please use the point adjustment and apply -5 for every extra case. | -3 |
| Not using (or poor use of) GitHub issues for documenting issues, assigning tasks, or introducing changes, updates, or new features. | -3 |
| Not using (or poor use of) branches (and pull requests) to isolate and merge changes/updates. (Includes poor pull request descriptions.) | -3 |
| Not using Continuous Integration & Delivery; The deployment process is not automated. | -3 |
Implementation [20 points]
| Item | Points |
|---|---|
The code in the main branch is not the deliverable of this iteration (does not correspond to the deployed app). | -5 |
| There are visible issues with the organization of code in the repository (poor structuring, temp files that are renamed to avoid merge conflicts, build files contaminated the repository, etc.) | -5 |
| There are visible issues with coding practices, e.g., code that is not modularized, methods/classes too long, poor naming, lack of comments, code that is not readable or requires refactoring (obvious code duplicate, etc.) | -5 |
| Commit history in a state of disarray (poor commit messages, too many or too few commits, unclear how the development progressed, all/most commits are made by one or a few members, etc) | -5 |
| Tried to pull and run the code locally but it didn't work (for any reason including poor documentation!) Advisors: You don't need to run the app locally on every iteration. But it must be done at least on two iterations at your discretion. | -10 |
Test [20 points]
| Item | Points |
|---|---|
| No evidence of automated testing of the changes made to the backend and the API in this iteration. | -5 |
| No evidence of automated testing of the changes made to the frontend (UI) in this iteration. | -5 |
| There are automated tests but those are incomplete, insufficient, or have poor coverage. | -10 |
| Tests are not integrated with the development process (e.g., not run automatically on merge or before deployment). | -5 |
| Poor quality or organization of test code (e.g., lack of modularity or readability). | -5 |
Delivery [40 points]
| Item | Points |
|---|---|
| Completed the iteration backlog but failed to complete several minor tasks that they had planned. | -5 |
| Missing one major deliverable (e.g. a planned user story or a critical bug fix not completed). Advisors please use the point adjustment and apply -15 for every extra major deliverable that is missing. | -10 |
| The app runs locally (the team can demo it on their computer) but the deployed version is not functioning properly. | -10 |
| App works (either locally or the deployed version) but the number of bugs/issues are so many that it is concerning. (They delivered the requirements but did a very poor job of it). Advisors: Please use the comment section to provide a few examples of those bugs/issues. | -20 |
Teamwork [10 points]
| Item | Points |
|---|---|
| Missing (or poorly written) retrospective. | -5 |
| No evidence of code review (e.g., reviewer are assigned but pull request is approved with no feedback). | -5 |
| No evidence of active communication in the team slack channel. | -2 |
| Missing or late standup form submission in the team slack channel. | -2 |
| Most team members missed more than one project meeting during this iteration. | -3 |
| Each team member submitted a self-review and peer reviews for their teammates. Additionally, they read all reviews they received from their peers. | -5 |
Project Delivery
The submission will remain open throughout the reading break period!
Documentation [20 Points]
| Item | Points |
|---|---|
| The Wiki is outdated or missing any of the required sections or it is disorganized or it has poor style and/or grammatical errors. Advisors: Please pay special attention to the API reference and User Manual; it should be complete and updated per the latest changes made to the application. | -10 |
| The README is outdated or missing any of the required sections or it is disorganized or it has poor style and/or grammatical errors. Advisors: Please pay special attention to the instructions to run the app locally; it should be complete and updated per the latest changes made to the application. | -10 |
Implementation [30 Points]
| Item | Points |
|---|---|
The code in the main branch is not the final deliverable (does not correspond to the deployed app). | -5 |
| There are visible issues with coding practices, e.g., code that is not modularized, methods/classes too long, poor naming, lack of comments, code that is not readable or requires refactoring (obvious code duplicate, etc.) | -10 |
| There are visible issues with the organization of code in the repository (poor structuring, temp files that are renamed to avoid merge conflicts, build files contaminated the repository, etc.) | -5 |
| Tests are missing, incomplete, insufficient, or have poor coverage. Tests are not integrated with the development process (e.g., not run automatically on merge or before deployment). | -10 |
| The repository is left in a state of disarray! Advisors: Please check the branches, issues, pull requests, and the project board. In particular, the issues must contain (document) remaining bugs and tasks to further improve the app. | -15 |
Delivery [50 Points]
| Item | Points |
|---|---|
| The app works (either locally or in the deployed version) but it is not as polished as expected for an alpha release. | -20 |
| The app works (either locally or in the deployed version) but it has too many bugs/issues for an alpha release. | -30 |
| The app works (either locally or in the deployed version) but it misses crucial requirements (functionality) for an alpha release and/or is too simplistic for an OOSE project. | -30 |