|
|
![TSS_PNG](/uploads/15f2f8428e362669aa70028e50c35ffe/TSS_PNG.png)
|
|
|
|
|
|
The process starts by capturing requirements (for example in a [mustard](https://gitlab.com/trustable/overview/wikis/report#mustard) yaml file).
|
|
|
|
|
|
These requirements are written in such a way that the individual rules of a standard are encapsulated where possible, and in GIVEN/WHEN/THEN [BDD-style](https://gitlab.com/trustable/overview/wikis/Trustable_BDD) scenarios. As such, requirements (and thus, standard compliances) are now in a format which can be tested against the code, using an existing BDD tool such as Yarn or Behave. This metadata is contained in the project repo.
|
|
|
|
|
|
A patch review system is put in place, which ensures that each revision is traceable to the developer. If the code within the patch satisfies a previously un-addressed requirement or introduces a new feature, this must be expressly stated in the commit message. The patch tracker is integrated with a CI system, which ensures that a submitted patch does not break any features, and reports what downstream changes it is responsible for. This means that a scenario (describing a particular requirement of the system) can be shown to function as expected, as well as being directly linked to specific SLOC and the developer who merged it. Often, a standard will dictate its own rules regarding patch review, which can be integrated at this point.
|
|
|
|
|
|
The CI runs the tests set out in the initial G/W/T-format requirements, and test results are produced as a standalone artifact. An automerger is configured with both human and machine reviewing, which creates a branch consumed by a continuous deployment system.
|
|
|
|
|
|
The metadata for each individual requirement and standard control can be consistently updated by the CD system with information from the test result artifacts. This way, the scenario for each requirement that has been satisfied carries with it results from a passing test, information about who submitted the patch(es), and the commit message detailing how the patch satisfies the requirement. This metadata can be consumed by an automatic compliance document generator, such as Compliance Masonry, to produce a consistently up-to-date SSP as the project develops. |
|
|
\ No newline at end of file |