A Safety-Centric Change Management Framework by Tailoring Agile and V-Model Processes - PowerPoint Presentation

A Safety-Centric Change Management Framework by Tailoring Agile and V-Model Processes Abdallah M. Salameh 1 Omar T. Jaradat 2 1 Ph.D. Candidate ; University of Salford, Manchester, UK 2 Ph.D. Candidate ; Mälardalen University; Västerås , Sweden

Agenda Safety assurance and change management Change management in an agile world How to glue the pieces of the puzzle? A maintenance framework to facilitate change management (XP-Kan-Safe) A conceptual model of a change management process XP-Kan- Safe : The Preliminary process XP-Kan- Safe : The Change Management Process Conclusion and future work

Many safety critical systems are subject to compulsory or advisory certification process Certification processes necessitate building the systems in compliance with domain-specific safety standards Safety standards form the basis for the approval and certification of those systems (e.g., ISO 26262, IEC61508 and ARP 4761). Safety certification is costly since safety standards require a lot of V&V activities during the development and maintenance of hardware and software parts of safety critical systems The V&V of safety critical embedded systems may consume up to 70% of the total development cost Safety Certification 3

Safety Case: Why? Developers of safety critical systems might/should defend a position (i.e. make a case) about the safety of their systems Developers may document a safety case in which they explain how the risks in a system have been acceptably managed Safety cases have been used in different safety domains for a number of years: Development of safety cases is a requirement in many standards The usefulness of the safety case has been appreciated in the industry and is used by many organisations as a good practice 4

There are different motivations/purposes to build safety cases. Hence, there are different definitions of the term ‘Safety Case’. The most common definition is: “ A structured argument , supported by evidence , intended to justify that a system is acceptably safe for a specific application in a specific operating environment ” [The UK Defence Standard 00-56] 5 Safety Case: What?

Safety Argument Presentation Goal Structuring Notation (GSN) key elements

GSN Argument Example

8 Safety Cases & Certification

Changes may happen! 9 No longer supports claims made of it No longer reflects operational content Any change that might compromise system safety involves repeating the certification process (i.e., re-certification). Certification Contradicted by new data

A safety case is built as a living document that should always be maintained to justify the safety status of the associated system and evolves as this system evolves Safety Cases and Certification Safety critical systems are expected to operate for a long period of time and they are frequently subject to preventive, perfective, corrective or adaptive changes during their lifecycle Any change that might compromise system safety involves repeating the certification process (i.e., re-certification) and thus, ultimately, necessitates maintaining the corresponding safety case 10

The challenges of maintenance 11 What does safety case maintenance mean? The safety case documents a complex web of interdependent parts : safety requirements, argument, evidence, design and process information. A single change to a safety case may necessitate many other consequential changes — creating a “ripple effect”. No definitive advice on how to maintain safety cases exists

12 Main Problem : Maintaining safety cases after implementing a system change is a painstaking process The lack of documentation of dependencies among the contents of safety cases The lack of traceability between a system and its safety caseSystem changes and their details cannot be fully predicted and made available up front The challenges of maintenance

Agile Software Development Dynamic, non-deterministic and non-linear characteristics Self- organising and cross-functional teams Rapid and on-going deployments within short iterations Communication and collaboration among the stakeholders become more important

Change management in an agile world The Agile way of working minimises the shortcomings of traditional sequential methods and improves the software development process (Principle 3) Unlike the series of isolated phases in the V-model, agile methods depend on iterative and incremental development of software (Principle 3, 7 & 8) Software developers who follow agile methods breakdown their project into manageable fragments which enables a rapid responsive ways to handle software changes (Principle 1 & 4)

Change management in an agile world Each agile method has its own recipe of features Organisations , typically, adapt software development methodologies to be in line with their needs and contexts Agile Tailoring

Kanban: workflow visualization & tracking

Kanban (Cont.) Based on Lean principles Tries to remove the waste by embracing rules to limit WIP Encourages to start from the existing context Provides sufficient visibility and understanding of the workflow and its progress

eX treme P rogramming

e X treme Programming (Cont.)Intends to improve software quality and responsiveness to the changing customer requirements. Lightweight method that focus on: Cost savings Unit tests before and along code activities Test Driven Development (TDD) instead of Test First Development (TFD) Frequent full system integration and Frequent releases

How to glue the pieces of the puzzle? Introducing a novel framework to facilitate the accommodation of non-structural changes to the software parts of safety critical systems by tailoring a hybrid process of agile software development and the traditional V-model

Safety Contracts 21 Contracts have been exploited as a means for helping to manage system changes in a system domain or in its corresponding safety case The concept of contract is familiar in software development and it was first introduced to constrain the interactions that occur between objects

A Maintenance Framework to Facilitate Change Management (XP-Kan-Safe) The framework comprises two main processes: The Preliminary process This process is preparatory and should be performed before handling changes The main objective of this process is to derive safety contracts and enrich them with additional information to increase the traceability between the requirements (i.e., guarantees) and different related artefacts. The Change Management process

A conceptual model of XP-Kan-Safe framework Text

System developers should include additional information into the derived contracts to enable tri-directional safety impact analysis Architectural Elements Test cases Elements of safety arguments XP-Kan- Safe : The Preliminary process System developers should derive contracts from safety analyses on the highest level down to lower levels

XP-Kan-Safe : The Change Management Process Understand the change and its impact in the system and its safety case Identify the impacted contracts Terminate: Forward the change request to the related team Investigate the impacted contracts to estimate the required size of work Derive new contracts or modify existing contracts Document the change and its rejection Plan the implementation of change Implementation by TDD Run all related tests Generate new versions for the modified test reports

Text XP-Kan- Safe : The Change Management Process

Conclusion & future work V-model is very strict V-model might be best fit to structural changes rather than non-structural. ASD can be used for maintaining safety critical systems yet needs to comply with the safety standards XP- Kan -Safe framework exploits safety contracts to tailor a hybrid process of ASD and the V-model Preliminary process (Tri-directional impact analysis) to derive safety contracts to increase the traceability Future work: In-depth case study to: validate both the feasibility and efficacy of the process fully automate its application. 36 th International System Safety Conference, Aug. 13 – 17, 2018

[1] 12 Principles Behind the Agile Manifesto , https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/ [2] XP Planning feedback loops: https :// en.wikipedia.org / wiki / Extreme_programming References

Abdallah M. Salameh: A.Salameh@edu.salford.ac.uk Tel.: + 46 (7) 21844015‬ Omar T. Jaradat: omar.Jaradat@mdh.se Tel.: +46 (21) 101369 Questions ? Thank you