Software Development and Validation SOPs

Hi Guys,

I need to write a number of SOPs around software development and validation and was hoping to get some guidance as to the number of SOPs I would required. I am presuming that I will need SOPs for the likes of:

Software development life cycle
Change Management
Risk Analysis
Validation?
Disaster Recovery
System Backup

Are there others I should add to the list. Do I need seperate procedures around user requirements, functional specs, etc or can all this be covered under SDLC procedure.

Any advice on this would be appreciated.

Re: Software Development SOPs

Hi Lynxbct,

I've attached a few more to consider. You may also require procedures for each of the unit and module tests as required, which in turn should generate specifications.

The final 6 documents in the list are specifications, all the others are SOP's and Process Flows.

I hope this helps,

Jo

Re: Software Development SOPs

Hi Jo,

Thanks for the response. That is a rather longer list that I had hoped for. Is there not a large amount of crossover in all those procedures. Is there a slim down version that would be acceptable?

Thanks

Re: Software Development SOPs

I think it would be worthwhile for you to obtain a copy of IEC 62304 and create as many/few SOPs you deem necessary to cover the aspects of the standard you would like to include in your quality system. I can see this being done with just a couple of SOPs, and even some of these could be combined:
* Software Development (including testing)
* Software Risk Assessment
* Software Configuration Management (including maintenance and change control)
* Software Problem Resolution Process

There is no right answer for this one, but take on board all the suggestions that you have (or will) receive and decide what best fits your need. My approach has always been to start with what you feel is the absolute minimum - and as the need arises expand your existing procedures and create new ones when required.

In our QMS, we started with a "SDLC Overview" document which had links to single procedures for each of: Planning, Requirements Gathering, Design, Development, Testing & Config Management.

As time has gone on we have broken some of the existing single procedures up as more details have been added (eg, we now have 4 Config Management procedures that each cover different aspects of the function). We have also written additional procedures as the need arose (eg, originally we said in the "Overview" that we did a Rick Assessment - but now we have written a Risk Assessment procedure to further explain the process).

Hope that this gices you some food for thought.

Dave

lynxbct said:

I need to write a number of SOPs around software development and validation and was hoping to get some guidance as to the number of SOPs I would require.

Click to expand...

How many?
First:

• Why do you 'need to' write procedures? What is your purpose in doing so?
• Who's the audience? (ie, How many people do you have, what are their skills, experience, background, etc. DO you have a lot of staff turnover or not?)

Because the 'right number' for a small software house with 6 people is quite different from a large one with 150!

We are a medical device company with roughly 150 employees - only 2 IT people though. We have a corrective action open from a customer as we don't have software validation procedures in place so I need to implement something to enable me to close out this corrective action.

We have no real procedures in place around development and release of software. We have a fairly comprehensive Intranet site which houses alot of functionality used by all areas of the business. We only really have procedures around backup and disaster recovery. Nothing on development, validation/testing and release of software.

lynxbct said:

We are a medical device company with roughly 150 employees - only 2 IT people though. We have a corrective action open from a customer as we don't have software validation procedures in place so I need to implement something to enable me to close out this corrective action.

Click to expand...

O..kay.

Um, could we turn this around somewhat? Instead of focussing on 'I have to have procedures in place just to close this action'... presumably there was some problem which led to the corrective action being raised? Or some lack, failure or weakness perceived by the customer which brought it on?

If you're '2 IT people' the chances are extremely high that you do it all yourselves, and that you figure you already know what you're doing (sorry, but it seems to 'go with the IT territory' but there's no defined process/procedure in place. Which means you pretty much do it however you think it oughta be done? But software validation is really important - how else can you establish that the product does do what it was required to do? And if there's no written procedure/process, how can anyone else see what's supposed to be done, much less verify it was done? And if there's no procedures for testing and release... that's a disaster waiting to happen, basically.

I'd focus on: what's the mininim kind of doco I can produce that will meet the need to show what we do and prevent this problem recurring (the failure that is!)?

Thanks for the comments Jane - you are completely correct. All development is done by the two IT guys (I am one of them). And up to a year ago I was the only one. All new systems are fully tested and verified but we have no paper trail to show that - again as you suggested.

There are a couple of systems used in critical areas of the business that have not been "properly" validated and that is probably what caused the corrective action from our supplier.

In relation to the minimum amount of documentation, that is the guidance that I was hoping to get here. It seems that you could be writing procedures for months if you wanted to. I was wondering if SDLC, Validation, Risk Analysis and Change Management (with associated forms) would be enough.

lynxbct said:

All development is done by the two IT guys (I am one of them). And up to a year ago I was the only one. All new systems are fully tested and verified but we have no paper trail to show that - again as you suggested.

Click to expand...

And that's one of the problems. You just know that you do it... but to anyone else (including customers) there's simply nothing to demonstrate that this is so. And that ain't a quality system, it's a couple of guys saying 'trust me, we do that'.

lynxbct said:

There are a couple of systems used in critical areas of the business that have not been "properly" validated and that is probably what caused the corrective action from our supplier.

Click to expand...

Yup - that's what can happen. Look, not having a go at you here, nor criticising, but minimum requirements in a quality system cover you as well, and allow you to respond reasonably to a supplier: 'Yes, we do that. Here's what we do (eg, a flowchart/process map/written procedure) and here's the record(s) that demonstrate it was done". That's all.

lynxbct said:

In relation to the minimum amount of documentation, that is the guidance that I was hoping to get here. It seems that you could be writing procedures for months if you wanted to. I was wondering if SDLC, Validation, Risk Analysis and Change Management (with associated forms) would be enough.

Click to expand...

I'd certainly focus on SDLC (which should include Validation shouldn't it?) and Change Management. Risk Analysis - is that a separate procedure? Idon't understand what you mean there.

But disabuse yourself of the notion of writing lengthy procedures. WHo for? Focus on the absolute minimum needed. In my experience, IT people often write far, far too much in a procedure - I dunno who they think they're writing for! If you can do it in an overview type flowchart with a bit of accompanying text, for example, do it that way! Better to spend the time on the analysis - what are the CCPs (Critical Control Points) or 'gateways' (Go/No Go points)? What must be in place/is required to continue? What record/s exist to show it was done?