Safety systems, i.e., systems whose malfunction can result in catastrophic consequences, are usually designed with redundancy in mind to reach high levels of reliability. However, Common Cause Failures (CCF), i.e., single failure events affecting multiple components or functions in a system, can threaten the desired reliability. To solve this problem, practitioners must use proven methods, such as those recommended by standards, to support CCF quantification. In particular, the β-factor model has become the de-facto model since the safety standard IEC 61508 considers it. As such standard applies to all industries, practitioners must figure out the industrial-specific implementation procedures. In this paper, we conducted a systematic literature review to understand how the β-factor model has been used in practice. As a result, we found 20 different models, which are industry/project-specific extensions of the first β-factor model proposed for the nuclear sector. We further classified those models by considering how the β-factor is estimated, and the level of redundancy support. Tool support for the models and their industrial use are also outlined. Finally, we present a discussion that covers the implication of our findings. Our study targets practitioners and researchers interested in using current β-factor models or evolving new ones for specific project needs.

Abstract The processes used to develop software need to comply with normative requirements (e.g., standards and regulations) to align with the market and the law. Manual compliance checking is challenging because there are numerous requirements with changing nature and different purposes. Despite the importance of automated techniques, there is not any systematic study in this field. This lack may hinder organizations from moving toward automated compliance checking practices. In this paper, we characterize the methods for automatic compliance checking of software processes, including used techniques, potential impacts, and challenges. For this, we undertake a systematic literature review (SLR) of studies reporting methods in this field. As a result, we identify solutions that use different techniques (e.g., anthologies and metamodels) to represent processes and their artifacts (e.g., tasks and roles). Various languages, which have diverse capabilities for managing competing and changing norms, and agile strategies, are also used to represent normative requirements. Most solutions require tool‐support concretization and enhanced capabilities to handle processes and normative diversity. Our findings outline compelling areas for future research. In particular, there is a need to select suitable languages for consolidating a generic and normative‐agnostic solution, increase automation levels, tool support, and boost the application in practice by improving usability aspects.

Compliance with process-based safety standards may imply the provision of a safety plan and its corresponding compliance justification. However, the provision of this justification is time-consuming since it requires that the process engineer checks the fulfillment of hundred of requirements by taking into account the evidence presented in the process entities. In this paper, we aim at supporting process engineers by introducing our compliance checking vision, which consists of the combination of process modeling capabilities via SPEM 2.0 (Systems & Software Process Engineering Metamodel) reference implementations and compliance checking capabilities via Regorous, a compliance checker, used for business processes compliance checking. Our focus is on the identification and exploitation of the appropriate (minimal set of) SPEM 2.0-like elements, available in the selected reference implementation, which can be used by Regorous for compliance checking. Then, we illustrate our vision by applying it onto a small excerpt from ISO 26262. Finally, we draw our conclusions.