Murphy
aims to assist builders of software-intensive products in Risk Management of Failure. In particular, Murphy focuses on managing the risk of failures during hardware software co-design. The core concept of Murphy is the introduction of “Risk Walls”. A Risk Wall is a (virtual) wall, accessible to an engineering team that contains an updated view on all the risks identified so far. This includes long living risks, for which the Risk Wall acts as a collective memory and a reminder. The Risk Wall can provide several views (classifications) on the risks and can provide detailed information about the severity and occurrence of risks.
Authors: Vladimir Blagojević, Wim Codenie, Jessie Dedecker, Nicolas Gonzalez-Deleito, Jeroen Deleu, Nick Boucart
Risk Management of Failure (i.e. being able to fully exploit innovation potential of software in products without compromising safety, security, or robustness of mission-critical applications) is a key strategic challenge for many software-intensive product builders.
Some challenges to be addressed are:
- Determining the appropriate level of remaining defects in a product. Companies consider the definition of acceptability criteria for defects (i.e., answering the question “what is good enough?”) as not being straightforward.
- Proactively reasoning about the impact of potential failures (i.e. risk). Outside software engineering, proven techniques exist to manage the risk of failure (e.g. FMEA). Applying these techniques to software development is not easy and not well understood.
- In hardware/software co-design, both the hardware and the software community have conceived several lifecycle models for which specific development parameters and decision criteria have been identified. In a hardware/software co-design environment, however, many software and hardware parameters cannot be treated independently. Many software parameters influence hardware parameters, and vice versa. Not understanding the interferences between hardware and software at the rendezvous points often results in quality problems in the end product. Additional failures originating from mutual interaction between hardware/software parameters are difficult to address and expensive to fix. Not only because they are usually detected in a late stage in the product lifecycle, but also because the fixes usually impact both hardware and software (on the requirements level, the architectural level, the testing level…).
This is a description of the full Murphy solution. Within the scope of the Twins project, some scoping decisions will have to be taken, so not everything (or not to a full extent) described may be available at the end of the project. The Murphy Workbench (see below) consists of three components:
- Risk Walls: In Murphy, a risk wall is an artifact allowing an engineering team to see all the relevant risks identified to the present time in product development. To install a Risk Wall in a company, Murphy will offer:
- A method for identifying the major co-design goals of the company.
- A method to shape Risk Walls for the identified goals; different walls may be designed depending on the identified goal and the context of a company.
- Set of building blocks to implement tool support for the identified Risk Walls
- Event Walls: For a risk wall to be fed with risks Murphy introduces the notion of an Event Wall. An Event Wall is an artifact that contains a continuously updated view of ongoing engineering activities that specifically carry increased risk. The aim is to let the whole team continuously monitor the (relevant, risky) ongoing engineering activities and collaboratively discover induced risk. Similar to the risk walls, the event walls are accessible to the entire engineering team and assist it to discover risks induced by these activities. Since both the risk and event walls are available to the engineering team, risks may be collaboratively discovered. The advantage is that co-design and discipline knowledge of the entire team can be exploited. The support for continuous risk discovery will be realized by installing a wrapper around existing engineering process of a company. Murphy will offer:
- A method for interfacing Murphy with the engineering process. Interfacing the engineering process of product with Murphy will be supported through risk sensors. Risk sensors observe a specific engineering task or part of the product, and generate Murphy Events. Murphy events represent all information about an activity that can be relevant to discover risks.
- A method and building blocks to shape and implement the Event Wall. The Event Wall actually contains all the Murphy Events generated by the Murphy Sensors. The event wall can provide several views (e.g. filters) on the events with a goal to aid risk discovery in ongoing engineering activities
- Building blocks to implement the identified risk sensors and interface them with Murphy (e.g. API, tool integration interfaces…)
- Risk Intelligence: Both the event and risk walls are supported by risk intelligence. Risk intelligence is a body of knowledge and best practices for discovering common risks in co-design. It assists engineers to discover risks from the event wall and to evaluate risks in the risk wall. In order to provide such assistance risk intelligence is extrapolated from the event and risk walls and made explicit in a risk model. This risk model captures insights in common risks and is reusable to assist in future risk discovery. Murphy provides a company with:
- A data model (a meta-model) for risk intelligence
- A set of patterns and best practices for risk discovery. These patterns and best practices assist engineers to link events and risks with risk intelligence.
- A populated risk intelligence repository in hardware/software co-design.
- A method for building company-specific risk intelligence. This includes both upfront initialization of risk intelligence, but also learning from past experiences (e.g. in a form of a post-mortem analysis).
- Tool support for storing risk intelligence
- Login to post comments
