Pārlūkot izejas kodu

Add feature selection documentation

This is a markdown document with introduction and an update of the CI
configuration.
Refs #13.
master
Wouter Horlings pirms 5 gadiem
vecāks
revīzija
144aa405bf
2 mainītis faili ar 62 papildinājumiem un 0 dzēšanām
  1. +16
    -0
      .gitlab-ci.yml
  2. +46
    -0
      feature_selection/selection.md

+ 16
- 0
.gitlab-ci.yml Parādīt failu

@@ -64,3 +64,19 @@ feature_definition:
- tags
changes:
- features/*

feature_selection:
stage: typeset
image: pandoc/latex:latest
script:
- pandoc feature_selection/selection.md $(ls feature_selection/*-iteration.md) -o feature_selection.pdf
artifacts:
paths:
- feature_selection.pdf
only:
refs:
- web
- branches
- tags
changes:
- feature_selection/*

+ 46
- 0
feature_selection/selection.md Parādīt failu

@@ -0,0 +1,46 @@
# Feature selection procedure

## Introduction
The goal of this document is to record the decisions during the feature development.
To make this document more readable the following section will explain the selection procedure.

## Selection procedure
There are three criteria that are applied in the selection procedure.
These are: dependency, test coverage and risk/time analysis.
Each criterion is a hard selection. We will only select on dependencies first.
If any of the features have an equal amount of dependencies then we will look which one completes more tests.
And the last is a risk/time analysis.

### Dependency
With the dependency criteria we count the number of other features each feature depends on.
The feature with the highest number of dependencies will be implemented first.

This is often a design dependency. For example, the engine in a car must be able to pull the weight of the car.
Therefore, we need to know the weight of the car before we can design the engine.
This can be a dependency, however we rather solve this by setting the specifications correctly.
That the car itself has a maximum mass of something. Therefore, the engine has to be able to pull that maximum mass.
Now we solved the dependency.

However, at some point, we might have to test something before we can specify the mass of the complete car.
In that case, a feature that can help us define the mass of the car better should get priority as other features depend on it.

### Test coverage
To see how the different systems work together we have designed multiple tests.
Each test that can be resolved by implementing the feature gives us more information about the system.
And if tests fail early, we can change the design earlier in the design.

### Risk/Time procedure
If we still have multiple features that have a draw in dependency and in test coverage we can assess the risk/time factor.
We want to clear the most amount of risk per time period.
In practice we will clear all the high risk features which have a short implementation time.
And eventually we end up with low risk long implementation time.
By moving al this risk forward we can clear more risk in an early stage of the development.

The time and risk factor will be given _high_, _medium_, or _low_ as factor.
Where _high_ = 3, _medium_ = 2, and _low_ = 1 point.
We divide the risk points by the time points and note down the factor.
The feature with the highest score will be implemented first.





Notiek ielāde…
Atcelt
Saglabāt