Software design, development and deficiencies – Auteur theory
François TruffautBeing a cinephile, let me introduce you to a term called ‘Auteur Theory’. The theory was born with the French New Wave cinema, in late 50s and early 60s, with a group of French filmmakers headed by Francois Truffaut.
The word Auteur is simply the French word for author and the theory implies that ‘An auteur is a singular artist who controls all aspects of a collaborative creative work, a person equivalent to the author of a novel or a play or an orchestra master’.
In the previous article we took a high level look on software development process and what it means to reach a global maximum and how design of the software plays a greater role in the controlled software development.
So, what makes a high-quality development process? International standards such as ISO 9001 and ISO 26262 (automotive specific) describe in detail the kinds of considerations required for the creation of high-quality processes, but the decisions of what to consider is up to the needs of the specific product and organization.
There is no doubt that software of the future will bring new technical changes and development complexity – and these changes are not far away and they are happening now. It may be THE time to welcome the idea of ‘Auteur Theory’ to complement the software development.
A contract based approach of software development is what can be correlated with the auteur theory. The interface contract orchestrates the complete software development process starting from design, development, testing and verification. When looking at this at a very high level, the contract theory (or auteur theory) takes on three basic principles:
#1: Say what you do
The architecture and design process must state the high level of behaviors of the architecture and how and when each activity will be performed, what are the input/parameter assumptions, what the expected outcomes are etc. As a simple example, it is not sufficient to do a data flow analysis of the system with respect to all the different values of inputs/parameters, you should state what the assumptions are, how are the dependencies between output and input.
Definition of interface contracts (red box) as part of architecture definition and its propagation to development and verification activities (orange box)
The interface contracts helps architects to specify the high level requirements/executable specification in order to set the boundary conditions for developers and test engineers such that the developers have no choice but to deliver good code which meets specifications (boundary conditions/contracts) by design.
#2: Do what you say
After you have gone through the detailed architecture and interface design process, it is important that development, verification, quality and testing teams adhere to these interface contracts. Any violation of the interface contracts results in failure and an error message.
#3 Be able to show a 3rd party that you did the first two tenets
When constructing the quality software, consider that you will likely be audited by internal and external agents. They will not understand your process or the products you are creating, but what they will be interested in is whether your development was done in the alignment of other two principles. To be able to show this, you need to make certain that you are able to show the results, of using interface contracts, that shows that you did what you said you had to do.
Going back to the data flow analysis example, when you specify assumptions and guarantees for input and output respectively, you’ll want to make sure that the data flow is consistent and no o/p guarantee violates the i/p assumptions. You will also want to make sure that these interface contracts flows to the development teams. Finally you’ll want to make sure that any contract violation, whether in architecture analysis, testing or verification, results in a failure condition and filed as an issue.
As long as all of this is considered as part of your development process, then the additional overhead for certification or conformance will be minimized.
Will following the auteur (contract) theory automatically mean that you’re doing no wrong in the software development process? Not necessarily. But these principles do put your process aligned with ISO, SPICE standards, and that you did in the way that improves quality rather than generating lot of documentation. The main take-away here is that once a solid controlled development process is in place, expanding that process to ensure safety and security is straightforward.
To know more how we are changing the ways companies think about software development, take a look at this whitepaper and stand by for more discussion…
