Why did gmail switch from defaulting to reply to list!
---------- Forwarded message ----------
From: Stephen Connolly <stephen.alan.connolly_at_gmail.com>
Date: 2009/7/30
Subject: Re: [FDA] approval
To: "Bolstridge, Andrew" <andy.bolstridge_at_intergraph.com>
2009/7/30 Stephen Connolly <stephen.alan.connolly_at_gmail.com>
> First off, IANAL
>
> As somebody who used to do computer systems validation for the pharma
> industry... (before I went back to pure software development)
>
> The requirements of the FDA are basically:
>
> *'...computer systems used to create, modify, and maintain electronic
> records and to manage electronic signatures are also subject to the
> validation requirements. (See 21 CFR �11.10(a).) Such computer systems must
> be validated to ensure accuracy, reliability, consistent intended
> performance, and the ability to discern invalid or altered records.'
>
> *So, what I always interpreted this to mean w.r.t. a source control system
> is that:
>
> - You must validate that your SCM is accurate & reliable... this
> requires you to define what you mean by accurate... I would think something
> like, commits are atomic, partially committed transactions will not be
> committed and that the SCM is always in a consistent state... So take your
> SCM, create a test repo, commit a big chunk of files, change some of them,
> commit the changes and interrupt the commit while in progress (try a couple
> of ways, e.g. ^C, yank network cable, pull power cord of client, pull power
> cord of server). If following the SOPs you write (for system recovery, or
> what to do when your workspace is corrupted, e.g. svn cleanup) and the
> system as you have configured it (e.g. if you configured HA/drbd) you meet
> *your definition of accurate*, then the SCM system you have chosen passes
> this test.
> - You must validate that your SCM has consistent intended performance..
> again you need to define this... if your intended performance is that
> checkout of a workspace containing no more than 1000 files each of which is
> no more than 20kb will take less than 5 minutes, and committing changes to
> 10% of these files will take less than 5 minutes, then test that and confirm
> you met what you defined your requirements to be.
> - You must validate that your SCM has the ability to discern invalid or
> altered records... OK, first off define what invalid records are... in the
> case of an SCM, you would probably define these as corrupted records, a SOP
> or cron job running svnadmin verify could probably meet the requirements you
> define for discerning invalid records. Second problem is altered records...
> well we can put hook scripts in place to prevent revprop changes, that
> should stop people changing the past from a remote svn client... now we have
> to worry about a single person who has admin access going in and modifying a
> record... the rule the FDA seemed to follow was that if one person on their
> own can effect the change... you fail... but if it takes two people actively
> cooperating... you pass... so you probably just want a post-commit hook that
> sends the transaction to a second server... if the second server has a
> different admin from the primary and is configured to be write once, and you
> have a SOP or cronjob for scheduled comparisons of the two repos... that
> should cover that problem
>
> The smart person will note that none of these concerns are unique to
> Subversion.... in fact throughout I have just referred to a SCM... and none
> of these refer to how the SCM is developed or sourced... in fact they all
> relate to:
>
> - What you say, up front, you want your SCM system to be able to do.
> - How you configured your SCM system servers.
> - What SOPs you put in place for managing your SCM.
> - What validation you performed on the SCM system you chose and
> deployed, and the SOPs you put in place for managing that SCM.
>
> IMHO, do not worry about where you source your SCM. whatever SCM system
> you use, you will have the *exact same* set of hoops to jump through... I
> suspect that Subversion would be the easiest to jump through the hoops with,
> but I could be wrong.
>
> -Stephen
>
>
Before I forget, there are other requirements as well, such as controlling
user access, etc... the same principles apply.
Define what *you* want from *your* system
Get that approved
Design how *you* will deploy *your* system in order to meet *your*
requirements
Define *your* SOPs for using *your* system.
Validate that *your* system and *your* SOPs meet *your* initial requirements
None of the above makes any difference if your OS or closed source... except
that with the closed source systems you usually need to set up an escrow
agreement with the closed source vendor to ensure that, if they go out of
business, you can source maintenance somehow... with an open source product,
just download the source! ;-)
-Stephen.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2377002
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-30 17:10:29 CEST