---
aliases: ["Software Engineering 1 - Stendhal - Adding Features"]
---
[[COMP23311|Software Engineering 1]]
# Team Coursework 2 - Stendhal - Adding Features
---

Submission deadline: [[03.12.2021.]]

## Process
1. Release planning.
2. Planning for the releases that will be implemented.
3. Testing and implementation.
4. Code review.
5. Integration and system testing.
6. Making a new release.
7. Preparing for the face-to-face interviews.

## Step 1. Release Planning
For each release, you must describe:

1. The sub-features that will be delivered in the release.
2. The target audience for the release (which group of users the new functionality will be released to)
3. The existing game elements that can potentially be used to support some aspects of the sub-features to be delivered, and how they will need to be adapted.

### Canary release
The first release should be designed to be a “*canary release*” (also sometimes called a “feature rollout”). That is, it should aim to test that the most risky part of the feature is both technically feasible and provides a sensible and enjoyable game play experience. Therefore, for each first release, you must also give a short rationale for why you chose this part of the full feature to implement and deploy into the game first. (Only 3-4 sentences of rationale are required.)

### Wiki Release Plan
Create a wiki with release plans for **all 6**.

- You should create a page in the wiki for each issue, using the page slugs shown on Blackboard (under `Assessment` > `Team Coursework` > `Exercise 2`. For example, for team S1Team107, if the page slug for one issue is given as `slow-innkeeper`, then the wiki page for this issue would be reached at the following URL: [gitlab.cs.man.ac.uk/comp23311_2021/stendhal_S1Team107/wikis/slow-innkeeper](https://gitlab.cs.man.ac.uk/comp23311_2021/stendhal_S1Team107/wikis/slow-innkeeper)
- Please use the following text for the header for this section of the wiki page, so that we can generate links to your release plans in our instructions to GTAs for marking:

	## Release Plan

**Remember when selecting issues that you will only need to implement the first of the releases in your release plan for each selected issue.**
- Remove the issues which you won't do from the milestone (important for RoboTA).

## Step 2. Issue Planning
### Creating a Work Breakdown Structure for the **Selected Issues**
- For each **selected issue**, you should create a work-breakdown structure (WBS) to come up with a defensible estimate for the effort needed to implement the first release. Check out the [[COMP23311 - Team Coursework 2#^cafd2e|marking scheme]].
- Please use the following text for the header for this section of the wiki page, so that we can generate links to your WBSs in our instructions to GTAs for marking:

	## Work Breakdown Structure

### Planning for the Implementation
You must next decide:
1. which team member will be the lead for each selected issue,
2. which team members will work on the implementation of each selected issue, and
3. which team members will act as code reviewers for each selected issue.

- You must break down into **feature teams**.

- Team leads should be assigned as the responsible person for the issue in the issue tracker.
- All other sub-team members for each issue must be recorded on the issue tracker, using a sentence of the form: `Sub-team member: <URL of GitLab profile of team member>`
- GitLab profile links have the form: [https://gitlab.cs.man.ac.uk/name](https://gitlab.cs.man.ac.uk/name), where `name` is a GitLab username.

### Code Review
- All code needs to be reviewed before being integrated into the mainline
- You should also decide who will carry out code review for each issue. Every member of your team must carry out some code review, and the code for every feature must be reviewed before integration.
- While you are welcome to carry out buddy reviews within sub-teams, the *pre-integration code review step must be carried out by someone from* **another sub-team**.

Code reviewers for issues must be recorded on the issue tracker, using a sentence of the form:
`Code review by: <link to GitLab profile of team member>`

### Time Tracking
You should document your estimate for the **effort** required to implement each feature in the issue tracker.
[gitlab.cs.man.ac.uk/help/workflow/time_tracking.md](https://gitlab.cs.man.ac.uk/help/workflow/time_tracking.md)

## Step 3. Testing and Implementation
- Team lead should:
1. Expand the [[COMP23311 - Team Coursework 2#Creating a Work Breakdown Structure for the Selected Issues|WBS]]
2. Allocate parts of the work to other team members. The parts should be divided in such a way that they can be done in parallel.
3. Set a due date for the delivery of the feature to the team, using the issue tracker’s Due Date facility. It should allow time for code reviews, corrections, and merging. *The due date must be set **before** work*
- The team lead should update the estimate for the issue in the issue tracker if, based on the more detailed planning carried out, the sub-team feel the original estimate was inaccurate.
- Everyone should:
- Use feature branches.
- Code in a [[Test-Driven Development (TDD)]] manner.
- Use test coverage tools to check if we've written sufficient tests.

### Starting Commit
We need to choose a clean sensible starting commit:
- **Once a suitable starting commit has been identified or created, one member of your team should create a tag pointing to that commit. The tag should be called:** `COMP23311/EX2/starting_point`
- We have created a Jenkins build for this tag, to help you choose a good starting point for your work for this exercise. ???

### Git Workflow
- Use feature branches with the **exact names** specified for each feature.
- We can further separate them into sub-feature branches, which then have to be merged back into the feature branch.
- Make sure you're configured your git **username** and **email**

### Best Practice Commit messages
- Details of this format can be found on Blackboard under the Course Content for week 6 (“Git Workflows”).

title: Git Message Example

Allow Joshua to list ingredients for spy glass

When asked, Joshua will now list the ingredients he needs for making the new spy glass item. This was trickier than it looked, because Joshua was already using all the available conversation states. I added a new state (QUESTION_4) to make it work.

### Test First Coding
- Begin by writing $2$ failing acceptance tests. The tests should describe **core** elements of the feature.
- Commit these tests **before** any production code (which makes them pass)
- Before working on the production code add a tag to the commit. The names of these tags are given on Blackboard.

	This tag is only used after the initial $2$ tests?

### Test Coverage
- The code written should usually have a coverage above $53$%.

### Documenting your Code
- You should use the issue tracker and the team wiki to document any problems you encounter that require you to make changes to your plan or your team structure.
- Try to document how much time you spend on a feature as accurately as you can. (Add time as you go).
- No need to separate time takes on tests, merging, production.

## Step 4. Code Review
- Reviews must be given using the GitLab commit comment feature, or through merge requests.
- Every contributing team member must perform at least one review in GitLab across the exercise.
- Explained in more detail: [Code review](https://software-eng.netlify.app/reviewing.html#reviewing)

## Step 5. Integrate into the Development Branch
- When satisfied with the code and merging into the development branch we ask that you use
**non-fast-forward** merges for all merges of your feature branch into the development branch.
- To do this in Eclipse, use the `Team` > `Merge`.
- Jenkinks should catch any problems if we fuck this up.

### Updating the Issue Tracker
- Consider the issue closed (and update the status) once the following holds:
1. Feature branch has been merged into the development branch.
2. Commit produces a clean stable build.
3. You have observed the feature working in game.

## Step 6. Prepare the Release
Responsibility of a **single** team member.
- Release name: `Prepare release 1.37uom`.
- Should be associated with the release milestone.

Once again, you will need to update:
1. The version number of the software is updated (to 1.37uom).
2. The `doc/AUTHORS.txt` file
3. The description of the changes included in the release in the `doc/CHANGES.txt` file.

You can make these changes directly on the development branch.

### Final Release
- **Final Release containing all the documentation and code should should be tagged as**: `VERSION_01_RELEASE_37_UOM`

## Step 7: Prepare for the Marking Interview
...

## Resources
- [Jenkings Marking Scheme](https://ci.cs.manchester.ac.uk/jenkins/job/COMP23311%202021%20S1Team14/job/RoboTA%20Exercise%202%20Marks%20and%20Feedback/Team_20Marks_20and_20Feedback/) ^cafd2e
- [Google Document for writing releases](https://docs.google.com/document/d/1eyUBdG0B9tS-w0j5EuQc_t6Kl3j4wHVm3cymzXxwqjo/edit)