Transitioning to Agile in Safety-Critical Device Development
•Als PPTX, PDF herunterladen•
0 gefällt mir•216 views
Some software development companies, especially those working on safety-critical devices, still stick to their traditional Waterfall methods, believing that Agile will fail to satisfy their requirements regarding safety and process control. With FDA’s endorsement of Agile in 2013, it became obvious that even safety-critical industries (such as medical device development) can take advantage of Agile. Watch this webinar recording to learn how you could reap the benefits of Agile while maintaining complete control over your processes. This webinar teaches you about transitioning to Agile while still developing safe, reliable and high quality products, and also shows you how codeBeamer’s advanced workflow engine helps you define and enforce compliant safety processes. http://intland.com/webinar/2015-12/transitioning-to-agile-in-safety-critical-device-development/
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (8)
Mehr von Intland Software GmbH
Mehr von Intland Software GmbH (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Transitioning to Agile in Safety-Critical Device Development
- 1. Transitioning to Agile in Safety-Critical Device Development Peter Haller 2 December 2015
- 2. 2 Agenda 1. Introduction of Intland Software 2. Safety-critical development 3. Fundamental differences of Waterfall/V-model and Agile 4. Adopting Agile in safety-critical development 5. Live demo
- 3. 3 Transitioning to Agile in Safety-Critical Device Development Webinar info o Live demonstration will be followed by a Q&A session o Webinar recording will be available at www.intland.com/webinars/ o Sign up for our upcoming webinars: 9 Dec 2015 – What is new in codeBeamer 7.8
- 4. 4 o Founded in 1998 o Headquarters in Stuttgart, Germany o Office in Silicon Valley, CA, USA o Partners Lufthansa Industry Solutions, and resellers in Korea & Taiwan o codeBeamer ALM components: • Requirements Management • Software Development Management • QA & Test Management • Demand Management • IT Operations (DevOps) o Introduction Intland Software © 2008–2014 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved. Used with the written permission of Scaled Agile, Inc.
- 6. 6 Transitioning to Agile in Safety-Critical Device Development Safety–critical development • Railway, automotive, medical, avionics, nuclear, etc. industries • Risk of harming human lives: safety & reliability crucial • Standards, regulations, guidances to control risks & process quality • IEC 61508: functional safety requirements of • Electrical/Electronic/Programmable Electronic • Safety-related Systems http://intland.com/using-codebeamer-to-achieve-iec-61508-compliance-2/
- 7. 7 Transitioning to Agile in Safety-Critical Device Development Waterfall in a nutshell • Waterfall is a popular development model for software engineering. • It is in use since the 1960’s for large scale projects. • Long delivery cycle, separate testing phase and requirements with no change. • Waterfall model describes a development method that is linear and sequential. • Once a phase of development is completed, the development moves to the next phase. Requirements Design Implementation Verification Maintenance
- 8. 8 • What is Agile? “Agile is a time boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end.” (agilenuteshell.com) Transitioning to Agile in Safety-Critical Device Development Agile in a nutshell – The Agile Manifesto Individuals and interactions over Processes and tools Customer collaboration over Contract negotiation Working software over Comprehensive documentation Responding to change over Following a plan “That is, while there is value in the items on the right, we value the items on the left more” (Agile Manifesto)
- 9. 9 Transitioning to Agile in Safety-Critical Device Development Adopting Agile in safety-critical development • Total control over all processes • Reduce risks • Reduce the time to market • Increased efficiency and product quality • Comprehensive documentation • Gapless traceability
- 11. Thank you for your attention! Any questions? What is new in codeBeamer 7.8 Date: 2 Dec 2015 Time: 4 PM (CET) / 10 AM (ET) http://intland.com/webinars-events/
Hinweis der Redaktion
- But, before we jump off to our presentation, let me just quickly tell you about the structure of this webinar. After the live demonstration, where we will show you how we support agile and waterfall development for hardware and software, we will start a Q&A session. A recording of today’s webinar will be available on our website soon after the webinar. And once you’re visiting our webpage, make sure you’ll browse through our upcoming webinars as wel (Last time we talked about SAFe)
- Building software to be used in safety-critical environments (for example, software embedded in medical devices, automotive or aviation systems, railway software, etc) is different to “ordinary” software development. As human lives may be dependent on these systems, it is imperative that they operate reliably, without the risk of malfunction, over extended periods of time, under all possible circumstances and operating environments. Therefore, great emphasis is placed on managing risks, controlling processes (both of development and testing), and ensuring complete transparency and traceability throughout the lifecycle. The enforcement of adequate development & testing processes is vital if you’re aiming to achieve compliance with relevant industry standards, guidelines and regulations. In addition to ensuring the use of compliant processes, you also have to prove this, finding a way to show that your lifecycle fits the requirements set forth by regulations. To verify adherence to these rules & regulations, development companies have to document their compliance measures & processes, and compile reports on them to facilitate audits.
- The Waterfall methodology is a popular development model for software engineering and is in use since the 1960’s for large scale projects. Waterfall has a long delivery cycle and a separate testing phase and requirements with no change. Also, Waterfall model describes a development method that has a linear and sequential design process. The traditional waterfall methodology treats analysis of the requirements, design, implementation, verification and maintenance. In the Requirements phase all the requirements are collected. The Design phase is differentiated into the subphases Logical Design and Physical Design. In the Logical Design phase, the system analyst uses the information which has been collected in the requirements phase to design the system and transforms them into the physical design dependent on the specification of hardware and software technologies. In the implementation phase, the source code is written. Once a phase of development is completed, the development moves to the next phase. The next phase verification is the phase where the project meets customer expectations. During the Maintenance phase, the customer is using the application which has been developed.
- This slide shall give you an overview on what is agile and what are the principals behind agile development. Per definition from the agilenuteshell.com, agile is a time boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end. But the agile approach can and is being applied more and more to the development of products. It works by breaking projects down into little bits of user functionality called user stories, prioritizing them, and then continuously delivering them in short two week cycles called iterations. User stories are features which the clients might one day like to see in their software. Therefore the agile manifesto was created by a group of experienced people who just wanted to create better methods to create software. These are the following four fundamental main concepts in the agile manifesto: Individuals and interactions over processes and tools Customer collaboration over contract negotiation Working software over comprehensive documentation Responding to change over following a plan Basically the items on the right are waterfall. One of the myths of the Agile movement is that documentation is not required or useful. It is true that one of the core values within the Agile Manifesto is "Working Software over Comprehensive Documentation." However, note the word "over" in this statement. The Manifesto is not saying no to any kind of documentation; it's saying there is a preference for working software over documentation. The goal is to remove barriers and defects from the system and leave things that add value. If your organization is creating lengthy documents to produce any kind of products and you're still struggling to release them on time and also within your budget, then ask of what it will take to drive value to the client. Also, the agile manifesto focuses on self-organizing and self-correcting teams to drive quality and efficiency in the system. So this manifesto, who was created by that group of people, is already part of their organisation and they say that the value in the items on the left handside are much more than on the left side. Basically there are also values in the items on the right handside, but in order to reach much more value, there is more need to put effort into the key concepts to achieve these values. Instead of treating the fixed stages like in the waterfall, Agilists believe that the phases are continuous activities. So, by doing them continuously, the quality improves because testing starts from day one, ensuring that bugs are found earlier in the process. In addition to that, Changes can be made after the initial planning phase, and as the client makes changes in the requirement the program can be re-written easily. There is a much closer relationship between the customer and the developer. Also the visibility is enhanced and The product itself is released much faster. Risk is reduced because you are able to get feedback early, and you can meet customer’s expectations
- A lot of companies working in industries that are highly regulated by standards and guidelines (safety-critical industries, such as the medical, automotive and aviation sectors) still rely on the Waterfall/V-model development method when creating software for their end products. While this doesn’t allow them to take advantage of more modern Agile methods, they choose to stick with these tried and tested methods because they help these companies ensure that certain processes are always enforced, which is key to achieving compliance with relevant standards. Process control is simply easier to do in a Waterfall environment. However, adhering to the regulations of industry standards can also be ensured in Agile development. Adequate process control measures can be implemented just the same, which is best demonstrated by FDA’s endorsement of Agile practices. If it can be used in medical software development, where rigorous standards apply to various processes, Agile is surely compatible with development in other regulated industries. Indeed, that’s the conclusion more and more companies in various industry sectors are coming to. Agile helps teams cut risks by working on smaller chunks of the software at a time, reduce the time of development, and improve the quality of their software products. However, aligning Agile techniques with the requirements of relevant industry standards and regulations takes a bit of effort. Therefore, if you’re looking to adopt Agile while maintaining the same control over your processes that you had using Waterfall, you will first need to map Agile practices and the stipulations of standards that apply to your industry or product. Any inconsistencies between these two will have to be addressed at an early stage of planning your Agile implementation. The end product of this analysis is hugely important: it’s going to be the set of (compliant) processes that you’ll need to enforce throughout the development lifecycle. Any deviation from these will likely result in non-compliance, and could increase the risk levels of your end product. This is a task that’s difficult enough, but there’s more to compliance than this. Traceability down to source code will have to be ensured and proven along the lifecycle. The processes that you have set in stone in the first step should help achieve this – but proving it means that all the links between all work items will need to be recorded, documented, and shown during audits. This is where you’ll realize that adequate Application Lifecycle Management tools such as codeBeamer ALM are simply necessary when it comes to implementing Agile in safety-critical development. The reason is simple: not only does using such solutions help enforce set processes through pre-configured workflows for each item, they can also automatically record all changes, and generate documentation to help compliance audits. Agile favours “working software over comprehensive documentation”, which is why it’s so much faster than Waterfall – but regulators in safety-critical sectors still require thorough, complete documentation, whatever development process you decide to use. ALM tools like codeBeamer take the burden of documentation off the shoulders of your team by automatically recording a comprehensive change history on all artifacts, and letting you customize reports that can be simply exported, taking care of documentation without requiring manual effort from your team.