Safety methods within Agile and RUP methods

1
Safety methods within Agile and RUP methods

• TORGRIM LAURITSEN
• BUCS project

2
Overview of the presentation

• Introduction
• Safety analysis
• Heavyweight- and lightweight methods
• Happy and hazard scenarios
• Summing up
• Questions and discussion

3
Introduction - I

• I will focus on reducing the product risks in
  software
• development projects. RUP focuses only on project
• risk reduction.
• I work with methods that will help the developers
  to
• produce safe software, i.e. software that does
  not
• behave in such a way that it causes the customer
  or
• his users to lose money or important information.

4
Safety analysis - I

• A software product should be analyzed in the
• context of its environment and modes of
• operation, to identify possible hazardous
• states and credible causes.
• This should be done in close co-operation with
• the customers, based on their knowledge of
• similar systems.

5
Safety analysis - II

• My focus will be on identifying product risks,
• and to provide the developers with tools that
• can be used to handle the risks, so that they
• will reduce the possibility reaching the
• hazardous states, based on
• the requirements and models used (both sketches
  and UML diagrams), and
• previous risk analysis done in the development
  project.

6
Safety analysis - III

• The developers should use the risks they have
  found,
• to identify remedies and barriers, to reduce the
• likelihood of the risk factors.
• The developers should implement the remedies and
• barriers in an early stage of the development
  process.
• I will emphasize hazard prevention rather than
• hazard detection and reduction, according to the
• principle of software quality assurance.

7
Safety analysis - IV

• It is important to perform system safety
• analysis throughout the entire software
• development period, not just in the
• beginning.
• This will prevent the developers from
• getting a false comprehension of the safety
• status of the system, since the requirements
• and solutions will most likely change during the
• project.

8
Safety analysis - V

• The only solution the developers has to offer to
• customers with business safety concerns
• today, is that the developers will be more
• careful and test more which is not good
• enough.
• Following the method described here, the
• developers will be able to write safety test
• cases and will have a better chance to
• avoid business critical behavior in the system.

9
Heavyweight- and lightweight methods - I

• In the last few years, two ostensibly conflicting
• approaches to software development have
• competed for hegemony, namely
• heavyweight and lightweight methods.
• I have combined ideas from these with system
• safety analysis methods, and have come up
• with some possible ideas how to reduce the
• product risk.

10
Heavyweight- and lightweight methods - II

• The heavyweight methods emphasize
• documentation, processes, small waterfall
• iterations, prototyping, etc.
• The lightweight methods emphasize
• teamwork and communication between the
• stakeholders, and the awareness that change
• will happen.

11
Happy and hazard scenarios - I

• Based on the ideas in RUP and XP,
• where RUP uses a scenario to describe
• the most damaging project risks in use
• cases, and XP uses stories to describe
• what happens, the developers can use
• the scenarios to analyse the risks.

12
Happy and hazard scenarios - II

• The idea is to distinguish between happy
• scenarios and hazard scenarios.
• By using hazard scenarios, the developers
• will be able to identify hazardous events, and
• find solutions to deal with them effectively.

13
Happy and hazard scenarios - III

• The hazard scenarios will be identified
• by the use of the system safety methods
• HAZOP for the whole system, and
• FMEA at class level.
• The results from these methods will be a
• basis for tests.

14
Test driven development - I

• Using the hazard scenarios to identify the
  hazardous
• states, will make it easy to use the Test Driven
• Development (TDD), where the developers should
• quickly be able to add a test.
• In TDD they write the tests before they do the
  coding.
• At first the test should fail, then the code
  should be
• corrected, and next time the test is run, it
  should be
• successful.

15
Test driven development - II

• After doing the HAZOP or FMEA analysis the
• developers will be aware of possible hazards,
• and following the TDD they should be able to
• take the appropriate mitigation steps to
• reduce the risk of these hazards.
• Implementing the remedies and / or
• safeguards will prevent the system from
• reaching the hazardous states.

16
Test driven development - III

• Every time the code is changed, the
• developers should run the tests, to
• assure that the new code has not
• affected the rest of the system.

17
Summing up

• The main focus is to help the developers to
  implement software that is safe to use.
• The solution is to combine ideas from heavyweight
  and lightweight methods together with system
  safety methods.
• The new method uses hazard scenarios as a basis
  for creating tests that will assure that the
  software will not reach hazardous states.

18
Questions and discussion

• Thank you for your attention.
• If you do have any questions or comments, I would
  like to hear them now.