Process Changes and Productivity Improvements From Adoption in the Siemens Development Process

Main -> DEPLOY Success Stories -> Transport-1

Summary
This description presents an evidence of a successful integration strategy of formal specification at system level (with Event-B) into an existing development chain (based on B at development level). It is evaluated mostly on the productivity gain resulting by the value gained out of the Event-B model in relation with existing processes (requirements, safety analysis, and development).

Every artefact that can be generated from Event-B models provides an increase in productivity and the evidence collection will therefore be centred on studying all artefacts that can be generated from Event-B models and their related costs. These are:
 * state machines/tabular format
 * traceability tables
 * FMEA analysis
 * B models

At this stage only process changes are evaluated. The improvement will be quantified later possibly with respect to past practices based on a project database.

Related FAQ
of interest to Engineers and Analysts
 * EM-EA-1 Is it possible to take advantages of formal models beyond using them to prove certain properties of a system design to automate additional development tasks?

of interest to the QA practitioners:
 * EM-QAP-1 Is it possible to take advantages of formal models to automate part of QA tasks?

Benefits

 * Earlier verification and validation activities, at system level
 * Productivity gain on a project
 * Possible reuse across projects

Limitations

 * Cost of modelling
 * Cost of process and tool integration
 * Training architect not used to formal models and/or hiding the formal models behind domain specific languages (automata/tables)

Elaboration
We mainly present here the identified process changes and then detail some work already done.

Changes in the design chain due to the introduction of Event-B at early stages were identified. The resulting table is reproduced here:



The main change will be that the Event-B model will replace the software specification document. To produce the Event-B model a refinement plan will be needed. The abstract B model will also disappear as it will be generated from the Event-B model. The rest of the design flow will remain the same except some expected changes in the rules for the automated refinements. As already discussed in [D7bis], the deployment strategy for B cannot be used here as the targeted people are quite different. The scope of B was software development and as it looks like a programming language software engineers were productive with the B notation rather quickly and there was no huge conceptual gap for them. In contrast, Event-B is targeted for system engineering at STS, and Event-B does not look like anything already known to them who generally use FMEA, traceability tables and other system-level notations, so that Event-B is a revolution. As a consequence:
 * additional work will be necessary for the EFS (Equipment Functional Specification) as this is mainly specified using automata. The idea is to keep the automata and use UML2B to generate the related Event-B code. Preliminary experiments with the code generated by UMLB have confirmed it is adequate for this purpose. [Later this work will likely become an evidence of its own.]
 * expertise must be devoted to the refinement plan. However it is expected that part of the Event-B model will be quite generic and common to most of the metro lines as it is at system level.

Specific Contributions

 * Extensions of Event-B to model Event failure and capture probabilities, in order to support FMEA.

Further work

 * Experiments with the Event-B to B translator.
 * Second pilot deployment to perform additional experiments with process and tool integration and also attempt to include system architect in the loop.