1 / 18

Safety methods within Agile and RUP methods

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.

lena
Télécharger la présentation

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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.

More Related