Working with a software developer who is not setup for IEC 62304

shimonv

Trusted Information Resource
Hi Fellows,
Here is the scenario:
A client of mine would like to outsource the software development to a small firm that are good at what they do, but are not setup to working according to IEC 62304.

Question: Is there any problem/pitfall to allow such a contract developer to work according to their own agile methods and when they get close to the end start working on the software QA docs with my help. This will include the preparation of STD for prospective testing.


Appreciate your thoughts.

Thanks,
Shimon
 
Last edited:

Ed Panek

QA RA Small Med Dev Company
Leader
Super Moderator
62304 asks what risk class the software in question presents; A, B or C I believe. Do you know what the contractor is working on?
 

Ed Panek

QA RA Small Med Dev Company
Leader
Super Moderator
I am not sure I would risk waiting to the end to document their compliance but you could certainly periodically update it since it low risk. Are you going to document this "plan" in your own QMS?
 

yodon

Leader
Super Moderator
are not setup to working according to IEC 62304.

That's a *bit* worrisome - most of 62304 is really just good software engineering practices.

If Class A, as you think, the burden is pretty light and the approach you describe is probably mostly reasonable. Doing the planning work up front will help them see how you will get there.

Requirements documentation can be challenging with this approach. The agile folks often take a different approach to requirements; e.g., use scenarios -v- "shall" and that makes the V&V work really hard. I would recommend going "old school" and writing ("shall" requirements) established. It's possible to use use scenarios as the basis for software system testing but sometimes the scenarios can be just too vague. We generally 'extract' requirements from use scenarios and keep updating throughout the development process.

The configuration management work is pretty fundamental and if they're not "set up to working.." this may be a problem. For Class A, you can pretty much wait until you start software system test before going under change control. After that, though, all changes need to be authorized and all changes to the code need to be linked to that authorization (usually supported through the SW CM system; i.e., check-out / check-in comments). Again, if you set the stage through planning, it will probably go ok.

If, though, the software turns out to be Class B, it gets really hard to back-fill - especially in unit verification & acceptance and integration (testing) - and I wouldn't recommend it.

Oh, and don't forget 62366! Agile is suited quite well for that standard as you will likely be doing a lot of formative studies. It also helps to get all the use specifications understood.
 

shimonv

Trusted Information Resource
I am not sure I would risk waiting to the end to document their compliance but you could certainly periodically update it since it low risk. Are you going to document this "plan" in your own QMS?

All the QA documents will be maintained at the legal entity QMS.
 

shimonv

Trusted Information Resource
Thanks Yodon,
Your writing clearly indicates that you had your fare share of SW QA juggling :)
In my opinion the IEC 62304 has not caught up with the reality of contemporary software development practices.


Shimon
 

yodon

Leader
Super Moderator
fare share of SW QA juggling

Yes, 62304 remediation is certainly a solid revenue stream. :) Not the most fun work, but pays the bills.

There's certainly room for improvement in the standard but given that it's medical device software that could result in harm, there's good rationale, IMO, for most of it.
 

Tidge

Trusted Information Resource
I stand with @yodon ; I will reply to this bit:
In my opinion the IEC 62304 has not caught up with the reality of contemporary software development practices.
Without trying to spark discussion about various agile methods wholly contained within different phases of development (i.e. requirements development v. design solutions) there is nothing about "contemporary development practices" that doesn't fit within 62304... assuming that (medical device) software developers are willing to guarantee the role their software plays in assuring safety.

My experience has been that software developers are no different than many other engineers that bristle at "somebody looking over their shoulder" or "making me explain myself over and over again". The (scaled) deliverables of 62304 can support rapid development... it's just that the developers have to be disciplined enough to admit when they are stepping backwards out of a phase (e.g. by refactoring elements of an established architecture, changing requirements, etc.) and recognize the consequences of doing so.
 
Top Bottom