<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Public Knowledge &#187; Quality Assurance and IV&amp;V</title>
	<atom:link href="http://www.pubknow.com/topics/quality-assurance-and-ivv/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.pubknow.com</link>
	<description>Management Consulting for Public Sector Agencies</description>
	<lastBuildDate>Fri, 27 Aug 2010 19:00:13 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Where do you devote your efforts on MMIS systems?</title>
		<link>http://www.pubknow.com/2010/04/where-do-you-devote-your-efforts-on-mmis-systems/</link>
		<comments>http://www.pubknow.com/2010/04/where-do-you-devote-your-efforts-on-mmis-systems/#comments</comments>
		<pubDate>Mon, 19 Apr 2010 16:09:11 +0000</pubDate>
		<dc:creator>kdisbrow</dc:creator>
				<category><![CDATA[General Interest]]></category>
		<category><![CDATA[Health]]></category>
		<category><![CDATA[Project Management]]></category>
		<category><![CDATA[Quality Assurance and IV&V]]></category>

		<guid isPermaLink="false">http://www.pubknow.com/2010/04/where-do-you-devote-your-efforts-on-mmis-systems/</guid>
		<description><![CDATA[Medicaid Management Information Systems (MMIS) are some of (if not the) largest and most complex systems states have to deal with. We&#8217;ve been around long enough to know they need to be replaced every 10 to 15 years and are costly to develop. What most states don&#8217;t know is when developing systems of this size [...]]]></description>
			<content:encoded><![CDATA[<p style="clear: both;">Medicaid Management Information Systems (MMIS) are some of (if not the) largest and most complex systems states have to deal with. We&#8217;ve been around long enough to know they need to be replaced every 10 to 15 years and are costly to develop. What most states don&#8217;t know is when developing systems of this size the bulk of the work goes into removing defects, problems that keep the system from functioning as it should. The graph below is based on information from Capers Jones (from his book &#8220;Applied Software Measurement&#8221;) for MMIS sized systems.</p>
<p style="clear: both;"><img style="text-align: center; display: block; margin: 0 auto 10px;" src="http://www.pubknow.com/wp-content/uploads/2010/04/Untitled_2-thumb.jpg" alt="" width="380" height="145" />The graph shows most of the effort in large system development goes into removing defects. Defects can occur in the feasibility, requirements, analysis, design, and coding phases of a project. The sooner a defect is detected in the development life cycle the less expensive it is to correct. So, defects detected in requirements are relatively inexpensive to correct whereas a defect in code is significantly more expensive to correct. Once a system is in operation defects are very expensive to correct. Think about it: not only do you have to fix the code but potentially you fix documentation, retrain users, etc.</p>
<p style="clear: both;">So this all begs the question &#8211; where do you put your effort and resources during the development of a large system like an MMIS? Focus on quality early (rather than waiting for the testing phase of a project) saves money.  A modest investment in quality assurance or independent validation and verification up front results in real dollar savings down the road.</p>
<p><br class="final-break" style="clear: both;" /></p>
]]></content:encoded>
			<wfw:commentRss>http://www.pubknow.com/2010/04/where-do-you-devote-your-efforts-on-mmis-systems/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Can Independent Verification and Validation (IV&amp;V) be too rigorous?</title>
		<link>http://www.pubknow.com/2010/02/can-independent-verification-and-validation-ivv-be-too-rigorous/</link>
		<comments>http://www.pubknow.com/2010/02/can-independent-verification-and-validation-ivv-be-too-rigorous/#comments</comments>
		<pubDate>Sun, 21 Feb 2010 18:24:47 +0000</pubDate>
		<dc:creator>kdisbrow</dc:creator>
				<category><![CDATA[Managing Your Consultant]]></category>
		<category><![CDATA[Quality Assurance and IV&V]]></category>

		<guid isPermaLink="false">http://www.pubknow.com/?p=336</guid>
		<description><![CDATA[Each proposal you receive for Independent Verification and Validation (IV&#38;V) of a software project will state the vendor’s approach is “rigorous”.  Vendors fight to explain how their methodology is more “rigorous” than a competitor.  This is what you want right?  Isn’t rigor a good thing?  Maybe, but not when rigor:
Takes over for experience. Vendors will [...]]]></description>
			<content:encoded><![CDATA[<p>Each proposal you receive for Independent Verification and Validation (IV&amp;V) of a software project will state the vendor’s approach is “rigorous”.  Vendors fight to explain how their methodology is more “rigorous” than a competitor.  This is what you want right?  Isn’t rigor a good thing?  Maybe, but not when rigor:</p>
<p><strong>Takes over for experience.</strong> Vendors will try and bury you in details about how rigorous their process is so you’ll hopefully overlook the fact they are staffing your project with individuals that have barely used software let alone written it, performed quality assurance on it, or managed it’s development.   The truth is effective and efficient IV&amp;V is art as much as science.  You need qualified consultants as much as rigorous process.  Make sure you examine who will staff your project very closely, asked to see the results of each individual’s previous IV&amp;V efforts.</p>
<p><strong>Is used as marketing hype</strong>.  Vendors will try and convince you they are “scientists” or “engineers” performing science or engineering on your projects/software. After all, V&amp;V was pioneered by NASA and, for software IV&amp;V, the base standard is defined by the IEEE (Rocket Scientists and Engineers) so who better to perform it?  IV&amp;V is, conceptually, pretty simple:</p>
<ul>
<li>Identify the products and processes to undergo verification and validation (preferably before or in the early stages of development),</li>
<li>Determine the criteria with which each of those products and processes can be evaluated (starting with standards where available e.g. the IEEE-1012-2004 standard for software verification and validation),</li>
<li>Assess the products/processes while in production and upon completion to verify they meet the predefined criteria and note where they don’t,</li>
<li>Re-assess products/processes when deficiencies have been addressed.</li>
</ul>
<p>IV&amp;V is hard work that takes expertise (there are many nuances in developing criteria and evaluating products etc), independence, and yes a degree of rigor.  But it’s not “Rocket Science”.  We’ve seen a significant amount of rigor added to an IV&amp;V process that adds little value to the client and seems to be there to convince the client that IV&amp;V is engineering and they are hiring the best “engineer”.  There is no professional certification of IV&amp;V “engineers” like there is for electrical or civil engineers.  Don’t buy into the hype that this line of reasoning purports.  Understand you need competent, experienced professionals but this is not a mystical art.</p>
<p><strong>Is used as an excuse for lack of social and political savvy of vendor staff.</strong> Beyond competence in performing IV&amp;V your consultants need communications skills and an understanding of the political landscape public sector projects face.  We’ve actually witnessed an IV&amp;V vendor reporting to a state legislature stating strictly facts (“the project is 2.3 months behind schedule” and “523 out of 1232 test cases failed”) without explaining context (“critical features were added” and “we’re only a quarter of the way through testing”).  The poor agency receiving the “benefit” of IV&amp;V spent the next month trying to keep funding for what was a thoroughly successful project.  When called on the carpet about this the IV&amp;V vendor explained that their rigorous methodology required they describe only the facts not the context of those facts.  Just what you need, Joe Friday (“Just the facts ma’am”).</p>
<p><strong>Creates unnecessary bureaucracy that just wastes your money.</strong> Sign-offs of intermediate IV&amp;V products, large review meetings, and repeated reviews of materials provide you with little value.  Often this “rigor” is applied not for your benefit but for the consultants, to ensure their rear is covered (“but you approved the interim deliverable”) or to enhance consultant cash flow (“you approved the first interim IV&amp;V checklist so we can bill you”).  This unnecessary bureaucracy simply costs you time and money.</p>
<p>IV&amp;V helps your software projects succeed and should be rigorous – meaning thorough, focused, and disciplined.  However, be aware “rigor” can be used for the wrong reasons.  When working with your IV&amp;V consultant or the next time you’re reviewing an IV&amp;V proposal keep in mind excess “rigor” provides little if any value; is used to cover a vendor’s weaknesses or benefits the vendor not you; and unnecessarily raises the costs of IV&amp;V services.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.pubknow.com/2010/02/can-independent-verification-and-validation-ivv-be-too-rigorous/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Playing Fast and Loose with Independence on IV&amp;V Projects.</title>
		<link>http://www.pubknow.com/2010/01/playing-fast-and-loose-with-independence-on-ivv-projects/</link>
		<comments>http://www.pubknow.com/2010/01/playing-fast-and-loose-with-independence-on-ivv-projects/#comments</comments>
		<pubDate>Wed, 13 Jan 2010 18:46:32 +0000</pubDate>
		<dc:creator>kdisbrow</dc:creator>
				<category><![CDATA[General Interest]]></category>
		<category><![CDATA[Managing Your Consultant]]></category>
		<category><![CDATA[Quality Assurance and IV&V]]></category>
		<category><![CDATA[featuredstory]]></category>

		<guid isPermaLink="false">http://www.pubknow.com/?p=300</guid>
		<description><![CDATA[More States are recognizing the value of having an unbiased, outside, opinion expressed about their systems development projects]]></description>
			<content:encoded><![CDATA[<p>More States are recognizing the value of having an unbiased, outside, opinion expressed about their systems development projects.  Independent Verification and Validation (IV&amp;V – for more information reference the IEEE-1012-2004 specification) is a standardized approach to providing these opinions that States are beginning to request contractor’s use. A key tenet of IV&amp;V is “Independence”.  That is the ability for your IV&amp;V contractor to give you an opinion about your systems project without being biased or unduly influenced.</p>
<p>We have seen many “IV&amp;V” contractors play a game with Independence.  They avoid procurement conflict of interest rules by partnering with a systems integration (SI) vendor in one State on the construction or implementation of a project and bid in another State to provide IV&amp;V over the same SI vendor.  Technically they aren’t working for the systems integration contractor in your State but in the larger picture they do receive money from the contractor they are charged with overseeing on your behalf.  This, obviously, negates the independence they profess to bring to your project.</p>
<p>IV&amp;V vendors do need to remain technically smart about system integrators, system developers, software solution vendors, and fiscal agents offerings so we’re not suggesting there be no communication.  Just that no financial relationships exists between your IV&amp;V vendor and these entities.</p>
<p>So what do you need? You need a consultant who does not contract with or have an obligation to system integrators, system developers, software solution vendors, and fiscal agents that will likely bid on your projects.   You need language in your IV&amp;V procurements that guarantees this independence.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.pubknow.com/2010/01/playing-fast-and-loose-with-independence-on-ivv-projects/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
