|
|
# Project Overview: Trustable Software
|
|
|
|
|
|
TL; DR - We are aiming to identify|provoke|create viable processes|methods|tools for secure|high-integrity|safety-critical|deterministic software engineering
|
|
|
**TL; DR We are aiming to identify|provoke|create viable methods|processes|tools for high-integrity|secure/safety-critical|deterministic software engineering.**
|
|
|
|
|
|
This project sets out to ask questions about the problem of Compliance in software, particularly with regards to software engineering which is expected to be Safety Critical, High Integrity, Mission Critical, Secure, Deterministic.
|
|
|
This project is exploring the problems of Trust and Compliance in software, particularly with regards to software engineering which is expected to be Safety Critical, High Integrity, Mission Critical, Secure, Deterministic.
|
|
|
|
|
|
What is the problem of Compliance in software? From a simplified viewpoint: verification against Compliance requirements, as we know it, does not work. The process is overly bureaucratic and subjective - there is no formal, objective method of guaranteeing that a piece of software will do what it claims it will do, and nothing more or less.
|
|
|
**Trust:** Software has become pervasive and now underpins many critical services and functions for society. Our reliance on software puts people in the position of needing to trust it, and increasingly there are situations where this trust is not justified. Our aim in this project is to demonstrate what trust for software means in practice, and to provide example implementations including evidence to allow others to consider whether or not the examples are trustable.
|
|
|
|
|
|
The volume and complexity of code in the software used in Safety Critical Engineering is rising fast, and we believe that automated processes for formal verification of Compliance are required to mitigate against the costs and risks involved. As far as we can tell there appears to be little applicable work on this available in the open domain.
|
|
|
**Compliance:** From a simplified viewpoint: verification against Compliance requirements, as we know it, does not work. The process is overly bureaucratic and subjective - there is no formal, objective method of guaranteeing that a piece of software will do what it claims it will do, and nothing more or less.
|
|
|
|
|
|
The volume and complexity of code in the software used in Safety Critical Engineering is rising fast, and we believe that automated processes for formal verification of Compliance are required to mitigate against the costs and risks involved. As far as we can tell there appears to be little applicable work on this available in the public domain.
|
|
|
|
|
|
As a initial objective, we are aiming to complete some research into some of the existing technologies in this field, so that we can create something in the way of a 'toy' or minimal framework for the creation of Trustable Software, providing a traceable link from requirements to tests, to code. We intend for this to be used, reviewed and critiqued by the wider community, and then built upon.
|
|
|
|
... | ... | @@ -40,4 +42,3 @@ At a very high level, we are working on the following principles: |
|
|
# Task Tracking
|
|
|
|
|
|
FIXME... |
|
|
|