| Title | Marking Rubric - Project |
|---|---|
| Authors | Neil Ernst |
NB: for all milestones, basic clean coding style: comments, standardized indentation, lack of code smells, is expected. Your submission and repository should show the following: - Travis CI is being used (M3+) - a static analysis tool and linter has been applied (M3+) - Typescript project best practices are followed (M3+)
- ASRs complete and capture
- need to persist data
- need to manage user state and cookies
- security and privacy
- usability
- performance and latency
- async issues
Marks deducted:
- scenarios seem to have little to no connection with the project (-2)
- poor technical writing (-2)
- Quality of scenarios (clear analysis of stimulus, response, response measure)
- technical writing is clear and concise (key decisions are documented; organization is easy to follow; basic English spelling and writing conventions adhered to)
- design follows basic principles like cohesion/coupling, single responsibility, open/closed
- design addresses QAR from M1
- design provides path for implementing user stories in M1
- design models follow conventions for class and sequence diagrams
- design justifies technology choices
- ADRs (3+) explain why decision was taken, what the context is, and what alternatives were rejected
- ADRs don't capture trivial design decisions
- code compiles
- code conventions/CI from above (commented, code style, design principles)
- working demo
- clear explanation of what user stories were satisfied in this iteration
- design as implemented follows design doc, or change rationale is present in README
- async is async when necessary
- TSLint does not complain
- test suite present/part of CI
- test coverage reasonable and meaningful
- code compiles
- code conventions/CI from above (commented, code style, design principles)
- working demo
- clear explanation of what (2) user stories were satisfied in this iteration
- design as implemented follows design doc, or change rationale is present in README
- async is async when necessary
- TSLint does not complain
- test suite present/part of CI
- test coverage reasonable and meaningful
- code compiles
- code conventions/CI from above (commented, code style, design principles)
- working demo
- clear explanation of how the remaining user stories were satisfied in this iteration
- design as implemented follows design doc, or change rationale is present in README
- async is async when necessary
- TSLint does not complain
- test suite present/part of CI
- test coverage reasonable and meaningful
And new in M4:
- explanation of how you are automating testing 3 QAS from your list in M1
- explanation of integration testing and CI pipeline
- demo works without error. -1 per bug or workaround.
- demo covers all user stories. Show us your user stories and make it clear what user story you are going through.
- demo has a coherent and organized demo script
- architectural summary is brief and coherent, explaining the key design problems.
- evidence of reflection and meaningful consideration of potential and actual problems.
- presentation and writing style appropriate for technical writing in software engineering.
- demonstrates understanding of design approach using Node/Express/Mongo.