Agnes,
I'd like to re-emphasise Jason's excellent comments, below:
From: "Jason Pyeron" <jpyeron@xxxxxxxx>
From: agi
Sent: Tuesday, June 17, 2014 10:58
Hi Jason,
Thanks for the speedy reply. We are in the process of trying
to make our
software product ISO13485 compatible and we are assessing all systems
that we use.
Do you have a validation document for git that could provide
information
on how to use it in order to comply with ISO legislations?
That would be customized to your QA process. A generalized document
would be too
vague. I am sure any process consultant could draft that up for you.
(disclaimer: I have been paid to do things like this before)
Maybe you could start by searching with things like
https://www.google.com/search?q=using+QA+with+Git or contacting
Atlassian about
their QA product suite integration with Git.
Maybe you could find a process consultant to do it cheaper if you
release it out
to the FOSS community?
The "nice" (read as less effort) thing about ISO 13485 is it:
* does not have a continual improvement requirement
so as long as "defects" are detected and
remediated you are good.
That detection is part of your wider QA system.
Please note:
* git does not detect defects,
* git does not remediate defects.
That's not the job of Git (or any version control system and it's
repository).
What git does is:
* ensure the approved artifact is unchanged in any attribute
to maintain the exact level of quality from first inspection
of that artifact for an unlimited amount of iterations.
* Git has built in "digital signatures" on the artifacts stored in
its repository.
These are the big points. The fact that everything is fully 'signed' by
the sha1 and can't be altered is the guarantee that runs all the way up
and down the git commit heirachy. If you have the same sha1 you have the
same (identical, byte for byte) history - fsck will check all the way
down to the very first entry.
You can also tag specific points as formal releases to simplify the
association of a nice name to a specific sha1. The releaser can even gpg
sign it.
You still need to ensure you take formal backups and archives in the
usual way, though Git gives you extra security because of the implicit
duplication among developers, readers and contributors.
As an aside, branching[1] allows developers to still tidy up their work
(rebase etc) before it is accepted as part of the release software. That
work still has its sha1 signatures, whether for the prior 'ugly' work or
new sha1 signatures for the 'tidy' work that is / hopes to be
incorporated into the release.
Any additional information or material you can think of is more than
welcome.
Thanks in advance for your help!
Best Regards,
Agnes Pasztor
Senior Test Engineer
Omixon Biocomputing Ltd.
On 06/16/2014 05:20 PM, Jason Pyeron wrote:
>> -----Original Message-----
>> From: agi
>> Sent: Monday, June 16, 2014 11:14
>>
>> Hello,
>>
>> I would like to ask a question about GIT v. 1.7
>>
>> Is it compatible with ISO 13485 (quality management system)?
>> Can it be
>> used for developing a medical diagnostic software?
> Yes.
>
> Now, do you have a specific question about how to use Git
in your QA process?
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
[1] Branching is part of the strength of Git's "DAG" (Directed Acyclic
Graph) structure.
Philip.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html