Difference between revisions of "Evaluating software engineering GitHub repository setup"

From Knowledge Kitchen
Jump to navigation Jump to search
m
m
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
[[Category: Software Engineering]]
 
[[Category: Software Engineering]]
 
[[Category: Grading]]
 
[[Category: Grading]]
 
The Task Board is supposed to show exactly what each member of the team is working on at any given moment.  If it fails to accurately show this, it is not done correctly.
 
  
 
The following eight parts of the project should be thoroughly completed.  Each is worth 1/8th of the total grade for setting up the project documentation correctly. Any of these 8 parts will be graded all or none... if a group has clearly not put in effort to think through and set up the project nicely, they will not be given a good grade!
 
The following eight parts of the project should be thoroughly completed.  Each is worth 1/8th of the total grade for setting up the project documentation correctly. Any of these 8 parts will be graded all or none... if a group has clearly not put in effort to think through and set up the project nicely, they will not be given a good grade!
Line 11: Line 9:
  
 
==Task Board set up==
 
==Task Board set up==
# Is the Task Board, viewable under the Projects tab of the repository, must be named correctly, e.g. "Sprint 0 Task Board", "Sprint 1 Task Board", etc.
+
The Task Board is supposed to show exactly what each member of the team is working on at any given moment.  If it fails to accurately show this, it is not done correctly.
 +
 
 +
# The Task Board, viewable under the Projects tab of the repository, must be named correctly, e.g. "Sprint 0 Task Board", "Sprint 1 Task Board", etc.
 
# Are the columns named correctly, e.g. "Sprint Backlog", "To Do", etc.
 
# Are the columns named correctly, e.g. "Sprint Backlog", "To Do", etc.
 
# User stories should be in the Sprint Backlog column, never in any other column
 
# User stories should be in the Sprint Backlog column, never in any other column
Line 19: Line 19:
 
# Issues in the Task Board must be labeled either "user story", "spike", or "task", but never more than one of those labels.
 
# Issues in the Task Board must be labeled either "user story", "spike", or "task", but never more than one of those labels.
 
# All issues in a sprint must be assigned to the proper milestone, such as the "Sprint 0" milestone.
 
# All issues in a sprint must be assigned to the proper milestone, such as the "Sprint 0" milestone.
# All tasks and spikes must be assigned to one or more team members - it is not acceptable for these to be unassigned
+
# All tasks and spikes must be assigned to one or more team members - it is not acceptable for any to be unassigned
# If an issue needs to be independently completed by team members (such as installing something on their own computer or learning something individually), it is not okay to have just a single issue for it on the Task Board - there should be one issue for it assigned to each team member individually.
+
# If an issue needs to be completed independently by multiple team members (such as installing something on their own computer or learning something individually), it is not okay to have just a single issue for it on the Task Board - there should be one issue for it assigned to each team member individually.
  
 
==User stories in the Task Board==
 
==User stories in the Task Board==
 
# All user stories must have a title like, "As a ___ I want to ___ so I can ___", where the blanks are filled.
 
# All user stories must have a title like, "As a ___ I want to ___ so I can ___", where the blanks are filled.
 
# All user stories must have a description that includes Acceptance Criteria and an Estimate of Work
 
# All user stories must have a description that includes Acceptance Criteria and an Estimate of Work
# Every User Story must have at least one Task associated with it.
+
# Every User Story must have at least one Task associated with it.  More likely than not, there should be many Tasks for any one User Story.
  
 
==Tasks in the Task Board==
 
==Tasks in the Task Board==
Line 34: Line 34:
  
 
==Markdown files in the repository==
 
==Markdown files in the repository==
# Students are required to keep their README.md and CONTRIBUTING.md files should be well written with proper markdown syntax and clear formatting.  Sloppiness is not allowed.
+
# Students are required to keep their README.md and CONTRIBUTING.md files well written, and up to date, with proper markdown syntax and clear formatting.  Sloppiness in text formatting or writing is not allowed and will be punished.
# The README.md must show a clear description of the project, a link to the CONTRIBUTING.md file, and very clear and thorough instructions on how to install and build the project code
+
# The README.md must show a clear description of the project, a link to the CONTRIBUTING.md file, and very clear and thorough instructions on how to install and build the project code.  As the project evolves and the steps to install and build the project change, these files must be kept up-to-date.e
# The instructions on the README.md file for how to to install and build their code must work.  If you can't figure out how to install and build their code, then their instructions are useless.
+
# The instructions on the README.md file for how to to install and build the project code must work.  If someone elses can't figure out how to install and build the code, then the instructions are useless.
 
# The CONTRIBUTING.md file must show a clear description of how members of the team contribute to the project, and what is and is not acceptable to the team.
 
# The CONTRIBUTING.md file must show a clear description of how members of the team contribute to the project, and what is and is not acceptable to the team.
  

Revision as of 17:18, 9 September 2019


The following eight parts of the project should be thoroughly completed. Each is worth 1/8th of the total grade for setting up the project documentation correctly. Any of these 8 parts will be graded all or none... if a group has clearly not put in effort to think through and set up the project nicely, they will not be given a good grade!

Product backlog

  1. A list of all User Stories and Spikes in the Product Backlog must be viewable in the Issues tab on the repository.
  2. The students should have spent some effort thinking about most of the obvious user stories that their project might require - a small list is a sign of little effort.

Task Board set up

The Task Board is supposed to show exactly what each member of the team is working on at any given moment. If it fails to accurately show this, it is not done correctly.

  1. The Task Board, viewable under the Projects tab of the repository, must be named correctly, e.g. "Sprint 0 Task Board", "Sprint 1 Task Board", etc.
  2. Are the columns named correctly, e.g. "Sprint Backlog", "To Do", etc.
  3. User stories should be in the Sprint Backlog column, never in any other column
  4. Tasks and Spikes should be in the other columns, and they should be placed in the column that accurately represents their current status

Issues in the Task Board (including User Stories, Spikes, and Tasks)

  1. Issues in the Task Board must be labeled either "user story", "spike", or "task", but never more than one of those labels.
  2. All issues in a sprint must be assigned to the proper milestone, such as the "Sprint 0" milestone.
  3. All tasks and spikes must be assigned to one or more team members - it is not acceptable for any to be unassigned
  4. If an issue needs to be completed independently by multiple team members (such as installing something on their own computer or learning something individually), it is not okay to have just a single issue for it on the Task Board - there should be one issue for it assigned to each team member individually.

User stories in the Task Board

  1. All user stories must have a title like, "As a ___ I want to ___ so I can ___", where the blanks are filled.
  2. All user stories must have a description that includes Acceptance Criteria and an Estimate of Work
  3. Every User Story must have at least one Task associated with it. More likely than not, there should be many Tasks for any one User Story.

Tasks in the Task Board

  1. Every Task must contain a link to the User Story from which it was created.

Spikes

  1. In Sprint 0, each team member has to install software on their local machines and learn how to use the technology stack for their project. If these two things are not represented as separate Spikes in the Task Board for each team member, then their Task Board is not accurately showing the work they need to do. In subsequent sprints, these sorts of spikes may or may not be present.

Markdown files in the repository

  1. Students are required to keep their README.md and CONTRIBUTING.md files well written, and up to date, with proper markdown syntax and clear formatting. Sloppiness in text formatting or writing is not allowed and will be punished.
  2. The README.md must show a clear description of the project, a link to the CONTRIBUTING.md file, and very clear and thorough instructions on how to install and build the project code. As the project evolves and the steps to install and build the project change, these files must be kept up-to-date.e
  3. The instructions on the README.md file for how to to install and build the project code must work. If someone elses can't figure out how to install and build the code, then the instructions are useless.
  4. The CONTRIBUTING.md file must show a clear description of how members of the team contribute to the project, and what is and is not acceptable to the team.

The project requirements

The Product Requirements is graded independently but also as part of the overall Project Setup grade.

  1. The REQUIREMENTS.md file must include at least two Use Case diagrams, a Domain Model diagram, and documentation of the needs and pain points of the intended users of the software
  2. Use Case diagrams must be drawn following UML standard practices.
  3. The Domain Model must include all entities that the project deals with, drawn in standard UML style, including the multiplicity of each entity. For example, an app that lets users see a list of nearby restaurants and read reviews for each restaurant would have at least four entities in the diagram: Users, List of Restaurants, Restaurants, and Reviews.


What links here