Grading

The grades for this course are based on a group grade for the deliverables, contributions, presentations, and chapter, as well as an individual points for the review and participation.

Participations points are bonus points that can be earned by being proactive in helping other team members, for example during class, or on line in GitHub or on Mattermost.

The grade is composed of the following subgrades:

• D = Average team score for D1-D3 [1..10]
• C = Team grade for chapter [1..10]
• P = Team grade for the final presentation [1..10]
• I = Individual participation points

The final grade is then calculated via:

F = (2*D + 2*C + P)/5 + I

Grading criteria

Team work

• Use of issues: (1) All communication via well-structured issues; (2) People respond to issues; (3) Pull requests solve issues; (4) Issues closed after they’re done; (5) At least 10 issues; (6) use of task lists in selected issues. (7) Good use of labels; (8) issues assigned
• Use of pull requests: (0) At least 10 merged pull requests (1) All .md via pull rqeuests; (2) PRs are reviewed (majority has >= 1 comment); (3) PRs contain coherent units; (4) PRs are well described; (5) Reference issue; (6) no self merges.
• Git branching: All of (1) Clear branches / network structure; (2) good handling / avoiding of conflicts; (3) no commits to master; (4) branches closed; (5) branch names
• Git commit messages: For all commits (1) Short title + explanations (2) Commits tell a story.
• Repo understandability: README.md gives good pointers; issues + PRs give good overview; Repository is well organized
• Planning: Use of milestones with assigned issues, and clear distribution of work. All deliverables scheduled. Current milestone closed. Meetings announced and minutes recorded in e.g. issues.
• Journal: (0) Compelling, concise and clear. (1) Hours per person + (2) indication of what has been done. (3) hours for all weeks. (4) Honest.
• Distribution of work: All team members spend >= 14 hours per week and activily participate
• Language/Communication: Clear, constructive, and understandable communication via github. Grammatically correct sentences with punctuation; they use Mattermost to exchange information
• Release: git tag + described release + reference to all issues in milestone + files attached + in time
• Team Description: complete with pictures

D1: Stakeholders

• Issue analysis: >= 10 rich and diverse issues analyzed; each covered in depth
• PR analysis: >= 10 rich and diverse pull requests analyzed, each covered in depth.
• R&W stakeholders identified: all categories of R&W thoroughly addressed
• Other stakeholders identified: >= 3 additional categories meaningfully described, or compelling explanation why this is not needed
• Stakeholder involvement: (1) explain what sort of stakeholders are involved, (2) what their interest in the system is, (3) and how they are trying to influence the development of the system, e.g., though Stakeholder power interest grid
• Integrators identified: (1) integrators named; (2) challenges identified; (3) merge decision strategies named
• Contact persons identified: >= 3 persons to be contacted
• Sources used indicated: Clear where all information comes from
• Well structured document: intro; conclusions; overview of all stakeholders; discussion per stakeholder; tradeoffs. To the point
• Well written document: <= 1 error per 200 words

D1: Context View

• Scope / Responsibilities: Scope & responsibilities clearly articulated. Perhaps some history?
• External entities: Systems, organizations, external data, explicitly listed
• External interfaces: Interfaces explicitly discussed
• Stakeholders: Context view and stakeholder connections are well explained
• Relevant context diagram: Appealing diagram, addresses key entities, explained in text; legend

D2: Development View

• Relevant Diagram(s): Illustration with two or more relevant (generated, reused, or self-created documents)
• Component overview / module structure: Key modules (or packages, components) covered, their dependencies, and their organization (e.g. layers)
• Common design models: Relevant common approaches covered. Processing (internationalizaiton, initialization, logging, …); pattern usage; common software
• Codeline models / dev process: Mapping of components to code level organization; build and test processes
• Document quality: Excellent document; Well structured, sources mentioned, good grammar + spelling

D3: Technical Debt View

• Identification of TD: Previous + identification strategy (tool, issue tracker, manual, …) + why this instance of TD was chosen.
• Impact: Impact of TD is clearly described in terms of (SOLID) violations, metrics, UML diagram or clear arguments in natural language.
• Historical analysis: number of previous changes to entity affected by TD thoroughly analyzed (pulsar, dead code, etc.)
• Solution + before/after analysis: Solution is described and before/after situation is discussed. It is clear why solution improves situation under particular circumstances.
• Testing: Previous + necessary steps to create good tests (e.g. breaking dependencies) are described in detail.
• Document quality: Excellent document; Well structured, sources mentioned, good grammar + spelling

Final DESOSA Chapter

• Improved D1: All feedback from TAs were either applied or discussed in the journal.
• Improved D2: All feedback from TAs were either applied or discussed in the journal.
• Improved D3: All feedback from TAs were either applied or discussed in the journal.
• New perspective and viewpoint: Well detailed, clear, and interesting new perspective.
• Final document quality: Excellent document; Well structured, sources mentioned, good grammar + spelling.

Contributions

• Interaction with the architects: The team was able to open a communication channel with the developers and architects of the system under analysis, by means of PRs, discussions, or issues.
• Increased their knowledge about software architecture: The team was able to learn more about the architecture of the project while working on PRs, or by means of interviewing developers, or asking questions in their forum/issues/slack.
• Valuable contribution submitted: The contribution, while possibly small, is valuable to some of the stakeholders of the project.
• EXTRA: The contribution itself: The contribution is impressive and really improves the system. Examples of impressive contributions: the introduction of missing documentation by means of code examples + videos, fixing a highly complex or important bug, the implementation of a highly required or complex feature.