Safety methods within agile and rup methods
This presentation is the property of its rightful owner.
Sponsored Links
1 / 18

Safety methods within Agile and RUP methods PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

Safety methods within Agile and RUP methods. TORGRIM LAURITSEN BUCS project. Overview of the presentation. Introduction Safety analysis Heavyweight- and lightweight methods Happy and hazard scenarios Summing up Questions and discussion. Introduction - I.

Download Presentation

Safety methods within Agile and RUP methods

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Safety methods within agile and rup methods

Safety methods within Agile and RUP methods


BUCS project

Overview of the presentation

Overview of the presentation

  • Introduction

  • Safety analysis

  • Heavyweight- and lightweight methods

  • Happy and hazard scenarios

  • Summing up

  • Questions and discussion

Introduction i

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.

Safety analysis i

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.

Safety analysis ii

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.

Safety analysis iii

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.

Safety analysis iv

Safety analysis - IV

It is important to perform system safety

analysis throughout the entire software

development period, not just in the


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


Safety analysis v

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


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.

Heavyweight and lightweight methods i

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.

Heavyweight and lightweight methods ii

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.

Happy and hazard scenarios i

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.

Happy and hazard scenarios ii

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.

Happy and hazard scenarios iii

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.

Test driven development i

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


Test driven development ii

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.

Test driven development iii

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.

Summing up

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.

Questions and discussion

Questions and discussion

  • Thank you for your attention.

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

  • Login