V-Model and Scrum in medical device context

Transcription

1 Focus on specification V-Model and Scrum in medical device context Senior specialist Carsten Jørgensen, Stakeholder and product requirements Stakeholder requirements specification (Usually called user requirements) Product requirements specifikation What we want What we promise to deliver (and the task we have) 1

2 The V-model Specify requirements Prepare checking Verify / validate system Architecture Verify integration Detailed design Verify components Implement Time Three way checking Resulting document Activity producing the background material Resulting document Activity at any level Time 2

3 Three way checking Document from the activity one level higher Prepare test Activity Review report Review Resulting document How to test Review report Review Next activity Review Does the document live up to what is stated in the input document? Is the document internally consistent? Does it live up to formal requirements? Are decisions given by the document correct? Are decisions testable? These and more question are written in the review report before the review They are used during the review Comments are collected Document corrected (and approved) 3

4 Verification and Validation Verification Did you live up to the specification: Test Review Static analysis Validation Is the system suitable to its purpose Evaluation Test that it can be used in the real environment Can it be used in practise Extension validation Have you done what you planed and what is required? Validation is handled by other standards like IEC series IEC When to make requirements? Traditionally at the start of the project (The V-model) Latter years this point of view has been questioned by agile thinking. 4

5 Agile - The Big Picture Product backlog Product backlog Product backlog Sprint Sprint Software and other work products Software and other work products Software and other work products other work products can e.g. be documents Agile thinking Kind of user requirements Product backlog Enter at any time Take out to development at the start of a new sprint Some will never enter the final product 5

6 Some work is placed in tasks other in done-criteria Product backlog Product backlog +1 Done: Xyz is tested Sprint planning Sprint backlog Daily work Review Other documentation Re-facture code deliv Deliverables like code Agile thinking Product backlog Kind of product requirements Take out to development at the start of a new sprint Sprint backlog 6

7 Scrum and the V-model The V-model assumes documents before development Scum assumes some documentation replaced by talk (with customers) to partly replacing documents The V-model assumes documentation to be updated Scum assumes documents only to be updated if useful later in the process (tries to avoid documentation) The V-model assumes relative stable requirements Scrum assumes constant unforeseeable change, feedback, learning Scrum as a model for Agile development V-model tries to agree up front Scrum tries to agree and adjust in a continuous manner Principle of last responsible moment 7

8 Medical development Medical devices shall be safe This is achieved by continuous risk management This is achieved by following processes that are described This is achieved by designing removing risks This is achieved by checking and reviewing This is achieved by complying to. Medical development Authorities should be able to control that development has been performed in accordance with above properties This requires proof first of all though documentation 8

9 Traditional vs. Agile thinking Traditional Specification is a proxy for the system The final specification represents the final system The system does not exist till it is final The system is developed as planned We got there as planned and we can document it Agile The system represents itself What is now is the final system so far Lots of versions of the system improving all the time Chess thinking we are not interested in how we came here only in next step The system was what we could achieve till this point in time we do not care, how we came here! Traditional vs. Agile thinking Most companies combines them such that there is a requirements specification, but it tends to be at a higher level of abstraction. The requirements are updated during sprints You can (but only to a certain extend) consider one sprint as a full V-model 9

10 Thank your for your attention 10