If we use agile - do we still need to document TF as a waterfall just for the notified bodies need?

Hirvo

Starting to get Involved
Hi,
I have many questions, sorry...
I was told that even though we use agile software development method, we should write the software and product development plans and SOPs as the Waterfall method were used? Is it so?
I wonder this, because I am used to make Quality Management Systems and in those the idea is to describe the process how you actually work - is it true that now according to the ICE 62304 we should describe Product Development Process once again for the notified bodies?

(We develop cloud based software, which is also the product. All development work we make are actually changes to the originally product. They are managed as an agile process. As soon as the feature is coded the ticket is marked "ready for review". The other person review the code, make unit tests and automatic regression test. If there is no problem, they mark is approved. Just thinking, is it really needed a separate Verification document...?)
 

Gisly

Starting to get Involved
Hi, I suggest you take a look at TIR:45 "Guidance on the use of AGILE practices in the development of medical device software" which should provide good guidance and clarification on what the regulators is actually requiring to do. The regulations nor standards require any specific models/processes to be followed such as Waterfall and AGILE.

Secondly I would suggest that you have a look at ex. the MDSAP Assessment Procedures and Forms on the FDA pages where you can see what the auditor would look for.

You can also have a look here: Iterative development and FDA change requests
 

Tidge

Trusted Information Resource
As a practical matter: I would only try to use Agile methods prior to, and distinct from, software system testing. There are many flavors of 'Agile'; the different approaches have varying trade-offs as far as determining that low-level (unit, integration) testing is precisely implemented in a manner that pre-determined requirements have been satisfied in a robust manner. The waterfall model is good at reinforcing the necessary traceability between required elements (of 62304) but at some level (prior to system level testing) I think a case can be made that these deliverables can be 'flexible' up until the point of non-commercial software release. (mileage varies depending on your quality system).

Ultimately the Software System Testing is what will establish that requirements are satisfied, so obviously requirements must be locked down first and the software under test has to be under control. It is preferable that the test methods/protocols be pre-approved with pre-understood acceptance criteria... I don't think there is much daylight on this topic, but I don't know that it is always an airtight requirement (depending on risk).
 
Top Bottom