| Title | Authors |
|---|---|
Marking Rubric - Project |
Neil Ernst, Omar Elazhary |
NB: for all milestones, clarity, legibility, and other good technical writing characteristics are vital and marks will be deducted if not followed.
- completeness and relevance of stakeholders
- table is well formatted and easily legible
- properly thought out business goals, referenced from empirical data (videos, blogs, project docs, tech pubs, etc.)
- at least 5 well developed business goals.
Marks deducted:
- lack of evidence for business goals
- lack of evidence of effort in creating stakeholder table.
- proper formatting and references supporting conclusions
- evidence of critical assessment of possible ethical dilemmas
- demonstrated understanding of ACM Ethical Code and how it applies to this project.
(explaining why marks were deducted)
- extensive list of ASRs, bullet form fine. Derived from business goals. (3)
- 7 scenarios in short form (3)
- 3 templated scenarios (of the 7), following the template in the notes (nb: not the full template) (2)
- Utility tree with (H,H) format for prioritization (prioritization should be reasonable but not necessarily referenced) (2)
Marks deducted:
- scenarios seem to have little to no connection with the project
- scenarios seem to have little connection to the previous milestone (business goals)
- poor technical writing
- Quality of scenarios (clear analysis of stimulus, response, response measure)
(explaining why marks were deducted)
- all required sections are present and well-organized. Include a table of contents. (2)
- view's primary presentation (diagram) is thorough and understandable. This means key elements are labeled, relations are typed, color is used appropriately. Use of UML or other diagram notations is not mandatory. (5)
- view and element catalog answers key analysis questions implied by QAS (M2). (5)
- behavior diagram is appropriate and clearly answers important questions from the QAS. (5)
- rationale is well-reasoned and any obvious assumptions are documented. (3)
Potential deductions:
- diagram missing key details and hard to understand in isolation
- no connection to project QA and previous milestones
- disconnect between Github code and your understanding.
- poor technical writing
(explaining why marks were deducted)
- all required sections are present and well-organized. Include a table of contents. (1/2)
- view’s primary presentation (diagram) is thorough and understandable. This means key elements are labeled, relations are typed, color is used appropriately. Use of UML or other diagram notations is not mandatory. (4/5)
- view and element catalog answers key analysis questions implied by QAS (M2). (4/5)
- behavior diagram is appropriate and clearly answers important questions from the QAS. (3/5)
- rationale is well-reasoned and any obvious assumptions are documented. (2/3)
Potential deductions:
- diagram missing key details and hard to understand in isolation
- no connection to project QA and previous milestones
- disconnect between Github code and your understanding.
- poor technical writing
- no evidence of reflection and response to comments in M3
(explaining why marks were deducted)
- Analytics: you ran tools and identified problems or positive parts of the codebase
- Evidence of tool use.
- Report meets tech writing criteria.
- Connection of analysis to other aspects of the project, if any.
- Technical debt is plausible and not merely the simplest rule violation.
- 2% project bonus for using SonarQube and pointing me to a Sonarqube instance
-
5 marks for presentation, 5 for Gitbook formatted PR with final chapter material
-
Presentation organization adequate
-
Presentation competently run
-
Presentation on time.
-
Presentation: questions answered, evidence of in depth knowledge
-
Presentation: slides attractive and clear
-
Presentation: speaking style clear and evidence of rehearsal
-
Report compiles to PDF/Gitbook with no bugs
-
Report has all necessary sections.
-
Report has fixed comments from previous submissions.
-
Report meets tech writing criteria.
-
Report has introduction and organization is consistent
- pull request is interesting and demonstrates knowledge of project architecture.
- PR meets project standards; e.g., not a lot of changes needed by maintainer.
- marks off for triviality or simplicity