Can the use of a formal method be hidden from most of development and management teams except to a few selected experts ?

Main -> FAQ -> CIF-PQAM-1


 * Theme: Control Impact of Formalism (CIF)
 * Role: PQAM

The use of a formal method can be hidden from most of development and management teams except to a few selected experts who will use it. It is just a matter of selecting the adequate formal method. There are two options to achieve this:
 * using hidden formal methods
 * keeping formal methods confined

1. Hiding formal methods
The adoption of formal methods can generally be made easier by hiding formal models behind some domain specific notations. For instance, SAP they used an existing domain specific language as front-end language for a formal tool. The developers continued working with their familiar notations. This is described in details in our success story Adoption Eased by Using Formal Models behind Domain Specific Notations.

Not all formal methods can be successfully hidden, notably because some of them might require user guidance related to their formal reasoning. This is one of the main risk of this approach as described in our FAQ CIF-PQAM-2.

Some formal methods can very successfully be hidden because they can be run without requiring any user guidance. They require specific input models and are able to perform a selected set of verifications. For instance, the success story Productivity Improvement of Data Consistency in Transportation Models reports on the use of such technique to verify geographical and circuit data for underground systems.

2. Keeping formal methods confined
The idea is to select a specific development step or a specific artefact, and to deploy formal methods on this step or artefact exclusively. The goal is to be able to accomplish the work with a reduced team of selected experts.

A typical example of such setting would be a project where one developed embedded communicating devices. The communication protocol can developed and verified e.g. for deadlocks through formal method, then implemented by another team who must only understand the protocol as described by the formal models and not the properties it is supposed to enforce neither the proofs that have been built about these models.

Another example is the use of the Polyspace code analysis tool. Polyspace is able to spot bugs in source code through static analysis. It however requires some expertise to properly understand and interpret the results of this analysis. Some companies employ a dedicated team of workers to run Polyspace on code developed by another team. This is a form of confinement. It is however not clear in this case that this is the best setting, as entrusting the use of Polyspace to developers would shorten the iteration delays. Furthermore, developers might be willing to test and validate their software incrementally, to keep their mind focused on the module they are developing.

It has also been assessed that the math behind formal methods can be hidden to engineers during their training, putting the emphasis on the essence of formal methods instead of on the notations.