<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Medical Device Software Forensics</title>
	<atom:link href="http://rdn-consulting.com/blog/2007/10/17/medical-device-software-forensics/feed/" rel="self" type="application/rss+xml" />
	<link>http://rdn-consulting.com/blog/2007/10/17/medical-device-software-forensics/</link>
	<description>Software Development and Biomedical Engineering</description>
	<lastBuildDate>Tue, 15 May 2012 17:32:14 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: andy</title>
		<link>http://rdn-consulting.com/blog/2007/10/17/medical-device-software-forensics/comment-page-1/#comment-5599</link>
		<dc:creator>andy</dc:creator>
		<pubDate>Thu, 14 Apr 2011 06:50:18 +0000</pubDate>
		<guid isPermaLink="false">http://rdn-consulting.com/blog/2007/10/17/medical-device-software-forensics/#comment-5599</guid>
		<description>While static code analysis is perhaps not the most efficient way of tracking down bugs causing device failure, it is a good tool to have in the developer&#039;s toolbox.

Finding 180 parts in 100&#039;000 lines of code warranting closer inspection and actually finding 2 defects (of unknown severity/consequence) is fairly good. Manually inspecting 100&#039;000 lines of code takes days if not weeks. Using a static analysis tool manages to reduce the amount up for inspection down to something that can be reviewed in less than a day.

While this is not a safe guard against any device failure (verification &amp; validation anyone?) - it is a good tool for improving overall software quality. Spending some time on grinding the analysis tools might even make it more efficient (and streamline it for ensuring a consistent style and quality of code within ones own guidelines).

A be all, end all - nope, but should be kept as one of several options for improving overall quality.</description>
		<content:encoded><![CDATA[<p>While static code analysis is perhaps not the most efficient way of tracking down bugs causing device failure, it is a good tool to have in the developer&#8217;s toolbox.</p>
<p>Finding 180 parts in 100&#8217;000 lines of code warranting closer inspection and actually finding 2 defects (of unknown severity/consequence) is fairly good. Manually inspecting 100&#8217;000 lines of code takes days if not weeks. Using a static analysis tool manages to reduce the amount up for inspection down to something that can be reviewed in less than a day.</p>
<p>While this is not a safe guard against any device failure (verification &amp; validation anyone?) &#8211; it is a good tool for improving overall software quality. Spending some time on grinding the analysis tools might even make it more efficient (and streamline it for ensuring a consistent style and quality of code within ones own guidelines).</p>
<p>A be all, end all &#8211; nope, but should be kept as one of several options for improving overall quality.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Discomfort with Computerized Medical Devices &#124; Bob on Medical Device Software</title>
		<link>http://rdn-consulting.com/blog/2007/10/17/medical-device-software-forensics/comment-page-1/#comment-5598</link>
		<dc:creator>Discomfort with Computerized Medical Devices &#124; Bob on Medical Device Software</dc:creator>
		<pubDate>Wed, 13 Apr 2011 02:29:08 +0000</pubDate>
		<guid isPermaLink="false">http://rdn-consulting.com/blog/2007/10/17/medical-device-software-forensics/#comment-5598</guid>
		<description>[...] Static Analysis to Find Bugs in the Real World  More Software Forensics and Why Analogies Suck Medical Device Software Forensics Pascal&#8217;s 3 part static analysis series that starts here: Guest Article: Static Analysis in [...]</description>
		<content:encoded><![CDATA[<p>[...] Static Analysis to Find Bugs in the Real World  More Software Forensics and Why Analogies Suck Medical Device Software Forensics Pascal&#8217;s 3 part static analysis series that starts here: Guest Article: Static Analysis in [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bob on Medical Device Software &#187; Blog Archive &#187; More Software Forensics and Why Analogies Suck</title>
		<link>http://rdn-consulting.com/blog/2007/10/17/medical-device-software-forensics/comment-page-1/#comment-718</link>
		<dc:creator>Bob on Medical Device Software &#187; Blog Archive &#187; More Software Forensics and Why Analogies Suck</dc:creator>
		<pubDate>Wed, 02 Jul 2008 04:27:09 +0000</pubDate>
		<guid isPermaLink="false">http://rdn-consulting.com/blog/2007/10/17/medical-device-software-forensics/#comment-718</guid>
		<description>[...] discussed software forensics tools before. Yes, bad software has hurt and killed people, and there&#8217;s no excuse for it.  I still [...]</description>
		<content:encoded><![CDATA[<p>[...] discussed software forensics tools before. Yes, bad software has hurt and killed people, and there&#8217;s no excuse for it.  I still [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bob on Medical Device Software &#187; Blog Archive &#187; Ever heard of FRACAS?</title>
		<link>http://rdn-consulting.com/blog/2007/10/17/medical-device-software-forensics/comment-page-1/#comment-239</link>
		<dc:creator>Bob on Medical Device Software &#187; Blog Archive &#187; Ever heard of FRACAS?</dc:creator>
		<pubDate>Sun, 28 Oct 2007 04:02:05 +0000</pubDate>
		<guid isPermaLink="false">http://rdn-consulting.com/blog/2007/10/17/medical-device-software-forensics/#comment-239</guid>
		<description>[...] interesting one. The difference between CAPA and FRACAS is similar to the argument I made regarding Software Forensics &#8212; these techniques should be used to ensure quality before the product is released.  [...]</description>
		<content:encoded><![CDATA[<p>[...] interesting one. The difference between CAPA and FRACAS is similar to the argument I made regarding Software Forensics &#8212; these techniques should be used to ensure quality before the product is released.  [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

