|
Server : Apache/2.4.62 System : FreeBSD fbsdweb2.web.rcn.net 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64 User : www ( 80) PHP Version : 8.3.8 Disable Function : NONE Directory : /domains/srakitin/newsletter/vol8/no4/ |
Upload File : |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Food for Thought: An Ounce of Prevention…</title>
<link href="/StyleSheet.css" rel="stylesheet" type="text/css">
</head>
<OpenTracking/>
<!-- Do NOT delete previous line if you want to get statistics on the number of opened emails -->
<body>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0">
<tr align="center" valign="top">
<td colspan="2"><img src="/images/food_for_thought_big.gif" alt="Food for Thought" width="436" height="169"></td>
</tr>
<tr class="Reference">
<td align="left" valign="top"><p><br>
An e-newsletter published by<br>
Software Quality Consulting, Inc. </p>
</td>
<td align="right" valign="top"><p><br>
November 2011, Vol. 8 No. 4 <br>
[<a href="/newsletter/vol8/no4/vol8no4.txt" target="_blank">Text-only Version</a>]</p>
</td>
</tr>
</table>
<br>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td align="left" valign="top">
<p>Welcome to <em><strong>Food for Thought™</strong></em>, an e-newsletter from <a href="/index.html?Intro" target="_blank">Software Quality Consulting</a>. I've created free subscriptions for my valued business contacts. If you find this newsletter informative, I encourage you to continue reading. Feel free to pass this newsletter along to colleagues by clicking on the <strong>Forward Email</strong> link at the bottom of this email. If you’ve received this newsletter from a colleague and would like to subscribe, please click this <a href="/e_newsletter.html" target="_blank">Enter New Subscription</a> link. If you don't wish to receive this newsletter, click the <a href="#bottom">SafeUnSubscribe</a>™ link at the bottom of this newsletter, and you won’t be bothered again.</p>
<p>Your continued feedback on this newsletter is most welcome. Please send your comments and suggestions to <a href="mailto:[email protected]">[email protected]</a>.</p></td>
</tr>
</table>
<br>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td width="145" align="left" valign="top"><img src="/images/in_this_issue.gif" alt="In This Issue" width="145" height="36"></td>
<td width="15" align="left" valign="top"> </td>
<td width="440" align="left" valign="top">In <a href="#article">This Month's Topic</a>, I discuss the need to balance defect prevention and defect detection activities.
<p>Regular features to look for each month are: </p>
<ul>
<li> <a href="#morsel">Monthly Morsels</a><br>
Hints, tips, techniques and reference info related to this month’s topic</li>
</ul>
</td>
</tr>
</table>
<br>
<br>
<a name="article"></a>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td width="145" align="left" valign="top"><img src="/images/this_months_topic.gif" alt="This Month's Topic" width="145" height="34">
</td>
<td width="15"> </td>
<td width="440" align="left" valign="top" class="BodyText"><div align="center" class="Headline">An Ounce of Prevention…</div>
<p> The October snowstorm in the northeastern US left many people without electricity and heat for more than a week. In Connecticut, people were without power for more than 10 days. In Massachusetts, an elderly woman froze to death in her unheated home. Further, local town officials have noted that electric utilities have drastically scaled back maintenance activities such as tree trimming. As a result, the question many people are asking is could this power outage have been prevented or shortened?</p>
<p>In fact, Prof. John Sterman from the MIT Sloan School of Management observed that not only have utilities significantly reduced preventive maintenance, such as simple tree trimming, but also they have reduced infrastructure investments that could have made the power grid more resilient. [1]</p>
<p>While most people recognize that an <strong>ounce of prevention is worth a pound of cure</strong>, many organizations fail to put this into practice – even though Prof. Sterman’s research has demonstrated that preventive maintenance can produce significant returns on investment. Let’s look at why this is… </p>
<p><strong>Preventing problems is not sexy </strong></p>
<p>Our culture is fixated on heroes – people who perform extraordinary feats risking life and limb are deservedly given hero status. For example, police and firefighters are often put into situations where they risk their lives to save others from a disaster that could have been prevented. We praise heroic behavior, and rightly so, but we totally ignore people who work often behind the scenes to prevent disasters before they occur.</p>
</td>
</tr>
<tr>
<td align="left" valign="top"><p><img width="145" height="178" src="/newsletter/vol8/no4/vol8no4_clip_image002_0000.jpg"></p>
<p align="center" class="Reference"> Ben Franklin coined the adage “An ounce of prevention is worth a pound of cure.” </p></td>
<td> </td>
<td align="left" valign="top" class="BodyText"><blockquote>
<p><strong>No one is a hero for preventing problems that never occur.</strong></p>
</blockquote>
<p>Within the software engineering community, we have our own “heroes” - developers who are rewarded for fixing problems at the last minute so that the product can ship on time. Upon further review, we often find that these same “heroes” often created the problems that were holding up the release in the first place.</p>
<p>Within the software engineering community, there is very little emphasis on defect prevention. People are not rewarded or even recognized for preventing defects. In fact, we spend much more time and money on <strong>defect detection</strong> than on <strong>defect prevention even though the data clearly shows that it should be the other way around… </strong></p>
<p align="center"> <img width="415" height="305" src="/newsletter/vol8/no4/vol8no4_clip_image002_0000.gif"> </p>
<p> We have long been aware that the longer a defect remains in a product, the more expensive and time consuming it is to fix. Steve McConnell has reported that:</p>
<blockquote>
<p>“… early, upstream defects generally cost 10 to 100 times as much to remove late downstream as they do to remove close to the point where they are created. [2]</p>
</blockquote>
<p>The following diagram from Capers Jones [3] illustrates one of the effects of not focusing on defect prevention. All of the defects introduced over the course of development are found at the end of the project – when they are much more costly to fix and much more disruptive to project schedules.…</p>
<p align="center"><img width="421" height="166" src="/newsletter/vol8/no4/vol8no4_clip_image004.jpg"></p>
<p><strong>Balancing defect detection vs. defect prevention</strong></p></td>
</tr>
<tr>
<td align="left" valign="top"><img width="145" height="102" src="/newsletter/vol8/no4/vol8no4_clip_image001.gif"> </td>
<td> </td>
<td align="left" valign="top" class="BodyText"><p>The challenge for the software industry is how can we make preventing problems just as important as fixing problems? Here are some suggestions for how to accomplish this… </p>
<ol>
<li><strong>Take responsibility for your work. </strong></li>
</ol>
<blockquote>
<p>Every member of every project team must take responsibility for quality of their work. This especially includes developers and testers! Developers ought to be willing to say: </p>
<blockquote>
<p><strong>“I believe my code is as good as it can be and correctly implements defined requirements. I challenge anyone to prove me wrong.” </strong></p>
</blockquote>
<p>Similarly, testers should be willing to say: </p>
</blockquote> <ol>
<blockquote>
<p><strong>“I believe my tests are as good as they can be and accurately reflect defined requirements and how our customers use our software. I challenge anyone to prove me wrong.” </strong></p>
</blockquote>
<li value="2"><strong>Have a good process and follow it.</strong></li>
</ol>
<blockquote>
<p>Preventing defects requires a good, solid development process – that could be Waterfall or Agile – it really doesn’t matter. What does matter is that there is a process and the process is followed. </p>
<p>Who is responsible for ensuring that there (a) is a good process and (b) that the process is followed? Management indirectly owns that responsibility. Management must demand that a process be put in place and hold people accountable for following it. In more mature software organizations, Management often delegates some of this responsibility to SQA…</p>
</blockquote>
<ol>
<li value="3"><strong>Get the requirements right.</strong></li>
</ol>
<blockquote>
<p>Problems with requirements account for the largest percentage of defects in software. Simply getting the requirements right can prevent a significant number of defects. </p>
<p>Requirements training provides project teams with the skills most teams are presumed to have but often don’t have. Learning how to write clear, concise, correct requirements is essential to preventing problems.</p>
<p><a href="/training_mission_best_practices.html" target="_blank">Additional information on Requirements training…</a></p>
</blockquote>
<ol>
<li value="4"><strong> Conduct effective Peer Reviews</strong></li>
</ol>
<blockquote>
<p>Once project teams have been trained in writing requirements, the team needs to learn how to perform effective peer reviews. By far, the most important peer review to perform is a Requirements Review. </p>
<p>People invited to participate in a peer review need to take that responsibility seriously. This means:</p>
<ul>
<li>Coming to the review meeting prepared – having read the relevant documents and identified issues and concerns beforehand. <br>
<br>
</li>
<li>Paying attention to the discussion during the meeting and not to your blackberry or iPhone.<br>
<br>
</li>
<li> Following up with the author to ensure that issues are resolved appropriately and clearly.</li>
</ul>
<p><a href="/training_mission_peer_reviews.html" target="_blank">Additional information on Peer Review and Inspection training…</a></p>
</blockquote></td>
</tr>
<tr>
<td align="left" valign="top"><img width="145" height="184" src="/newsletter/vol8/no4/vol8no4_clip_image001.jpg"> </td>
<td> </td>
<td align="left" valign="top" class="BodyText"><ol>
<li value="5"><strong>Create Rapid Prototypes</strong></li>
</ol>
<blockquote>
<p>Rapid prototyping has long been an effective tool for preventing problems since it can enable users to provide critical feedback on issues of usability and functionality early in the development process.</p>
</blockquote>
<ol>
<li value="6"><strong>Proactively manage project risks</strong></li>
</ol>
<blockquote>
<p>Many project failures are attributable to lack of risk management. Project managers can prevent many problems by learning how to proactively identify, mitigate and manage project risks.</p>
<p><a href="http://www.rspa.com/spi/project-risk.html" target="_blank">Learn more about Project Risk Management…</a></p>
</blockquote>
<ol>
<li value="7"><strong>Expand the role of SQA beyond testing</strong></li>
</ol>
<blockquote>
<p>Within many organizations, SQA often focuses only on testing. Testing is a defect detection technique, not a defect prevention technique. By expanding SQA’s role to encompass the entire software lifecycle, SQA can add value by performing defect prevention activities.</p>
<ul>
<li>Participate in Requirements Reviews to identify poorly written requirements as well as requirements that are not testable.<br>
<br>
</li>
<li>Provide Management with data on process effectiveness and whether the process is being followed.<br>
<br>
</li>
<li>Perform <a href="/training_mission.html" target="_blank">Root Cause Analysis</a> on defects to identify process improvements that can prevent similar defects on future projects.</li>
</ul>
</blockquote>
<ol>
<li value="8"><strong>Provide incentives and rewards for preventing problems</strong></li>
</ol>
<blockquote>
<p>Management needs to recognize the significant cost savings that can be realized by focusing on preventing problems rather than fixing problems. Management can do this by providing incentives and recognition for those who proactively prevent defects on project teams. </p>
Project teams need the ability to balance defect prevention and defect detection activities to achieve the best outcomes.</blockquote>
<p align="center"> <img width="359" height="206" src="/newsletter/vol8/no4/vol8no4_clip_image002_0001.gif"></p></td>
</tr>
<tr>
<td width="145" align="left" valign="top"><img width="145" height="145" src="/newsletter/vol8/no4/vol8no4_clip_image002.jpg"> </td>
<td> </td>
<td width="440" align="left" valign="top" class="BodyText"><blockquote>
<p>One benefit of using a more balanced approach to defect prevention is illustrated by Capers Jones [3]</p>
</blockquote>
<p align="center"><img width="351" height="136" src="/newsletter/vol8/no4/vol8no4_clip_image008.jpg"></p>
<blockquote>
<p>Here, we see that defects introduced into the product are found close to the point where they are introduced – which is much more cost-effective. </p>
</blockquote>
<p><strong> Try something radical… </strong></p>
<p>Mike McGonagle, a colleague of mine, recently told me of a test team that wanted to push developers to take responsibility for the quality of their code. The test team had clearly defined release criteria, developed tests against requirements and ran those tests. If the test results met the release criteria, the product could ship. </p>
<p>If the test results didn’t meet the release criteria, the product wouldn’t ship. In this case, the test team <strong>would not</strong> provide the developers with a list of the tests that failed. It was left to the developers to figure out what wasn’t working. </p>
<p>If more project teams worked this way, developers would eventually take responsibility for the quality of their code – which means that they would deliver code to the test team with far fewer defects. This is an interesting example of providing the right kind of incentives to prevent defects. </p>
<p>Imagine if electric utilities were fined $10 million a day for every day that customers were without power. While we would still have occasional power outages, they would be far shorter in duration than the outages we experienced with the October snowstorm. An ounce of prevention really is worth a pound of cure.</p>
<p>‘till next time… </p></td>
</tr>
</table>
<br>
<br>
<a name="morsel"></a>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td width="145" align="left" valign="top"><img src="/images/monthly_morsels.gif" alt="Monthly Morsels" width="145" height="35"></td>
<td width="15"> </td>
<td width="440" align="left" valign="top">Every month in this space, you’ll find additional information related to this month’s topic.
<ol>
<li>Sterman, J., “Utilities need to cut trees, not costs”, <em>Boston Globe,</em> Nov. 4, 2011.<br>
<br>
</li>
<li>McConnell, S., <em>Rapid Development</em>, Microsoft Press, Redmond, Wash., 1996.<br>
<br>
</li>
<li>Jones, C., <em>Software Quality: Analysis and Guidelines for Success</em>, Thomson Computer Press, 1997.<br>
</li>
</ol>
</td>
</tr>
</table>
<br>
<br>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td width="145" align="left" valign="top"><img src="/images/about_SQC.gif" alt="About SQC" width="145" height="35"></td>
<td width="15"> </td>
<td width="440" align="left" valign="top">Software Quality Consulting provides a full-range of software engineering services for safety-critical industries and mission-critical projects. Our goal is to help create safety-critical and mission-critical software that meets our client’s needs, complies with all applicable standards and regulations, with the highest level of quality possible, and in the most cost-effective and timely manner possible.
<p>To learn more about how we can help your organization, <a href="/index.html?AboutSQC" target="_blank">visit our web site</a> or <a href="mailto:[email protected]">send us an email</a>.</p></td></tr>
</table>
<br>
<div align="center" class="Reference">Food for Thought, Predictable Software Development, Act Like a Customer,<br>
and ALAC are trademarks of Software Quality Consulting, Inc.<br>
Copyright 2011. Software Quality Consulting, Inc. All rights reserved.<br>
Graphic design by <a href="http://www.sarahcoledesign.com/" target="_blank">Sarah Cole Design</a>.</div>
<a name="bottom"> </a></body>
</html>