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 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.
I will focus on reducing the product risks in software
development projects. RUP focuses only on project
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.
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
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 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.
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
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.
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
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
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.
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.
The hazard scenarios will be identified
by the use of the system safety methods:
The results from these methods will be a
basis for tests.
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
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.
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.