Home > Archive > Software Engineering > November 2005 > Six Sigma?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Roy Smith 2005-10-25, 9:56 pm |
| I recently took a one-day into to Six Sigma class. While I can see how
this applies to manufacturing, I'm having trouble figuring out how it can
be applied to software development. I'd be interested to hear any
real-life stories (good or bad).
| |
| Wayne Woodruff 2005-10-26, 8:01 am |
| On Tue, 25 Oct 2005 21:43:06 -0400, Roy Smith <roy@panix.com> wrote:
>I recently took a one-day into to Six Sigma class. While I can see how
>this applies to manufacturing, I'm having trouble figuring out how it can
>be applied to software development. I'd be interested to hear any
>real-life stories (good or bad).
You might have a look here.
http://software.isixsigma.com/libra...nt/c030910a.asp
Lots of good practical uses of SS for Software.
Wayne Woodruff
http://www.jtan.com/~wayne
| |
| H. S. Lahman 2005-10-26, 6:59 pm |
| Responding to Smith...
> I recently took a one-day into to Six Sigma class. While I can see how
> this applies to manufacturing, I'm having trouble figuring out how it can
> be applied to software development. I'd be interested to hear any
> real-life stories (good or bad).
Process models like Baldridge, TQM, and Six Sigma are about how one
monitors and corrects processes. Software development is a process, so
they are applicable. However, the notion of 'quality' that one is
monitoring against is much broader in a software context than in a
manufacturing context. For example, when applied to software
development processes one must broaden the notion of 'defect' to include
things like conformance to coding standards, which don't directly affect
the product performance for the customer. Similarly, one needs to
broaden the notion of what a 'test' is to include things like peer reviews.
The crucial idea behind such process models is that one should not be
putting defects in the product (software) to begin with. IOW, one
should strive to avoid inserting defects into the software during the
construction process. That philosophy is commonly known as "defect
prevention". Thus one employs various forms of testing not to improve
the product quality but to monitor the process to ensure it is working
properly to /provide/ quality. Once one has made adjustments for the
nature of the construction process, the notion of build-it-right applies
equally well for manufacturing and software construction.
Realistically it is infeasible to have no defects, especially where
human fallibility is possible as in largely intellectual processes like
software construction. So models like Six Sigma monitor processes for
/acceptable/ levels of defects, which is where Statistical Process
Control (SPC) comes into the picture. One applies SPC to the results of
testing to determine if the level of defects found is acceptable. If
the level of defects is unacceptable, then the process is broken and
needs to be fixed. The nature of the defects may be different but the
basic monitoring techniques are exactly the same for manufacturing and
software construction.
Another crucial idea behind such process models is the one should, over
time, militantly s to reduce the acceptable level of defects inserted
into the product. One does that by incrementally improving the process
itself so that inserting defects of the type found in the past is
avoided in the future. To support that one must collect data about the
defects when doing SPC. One then uses that data for root cause analysis
and that, in turn, is used to modify the process. Again, that sort of
analysis and process improvement is fundamentally no different for
manufacturing and software construction.
--
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH
| |
|
| I designed some factory equipment for a disk drive manufacturer.
This equipment was used to packwrite (format) the drives.
at a rate of 10,000 drives per day, a failure rate of 0.1% would pile
up 10 drives per day/50 per w. Unacceptable.
We were required to have systems run in a test lab for one w error
free before factory acceptance.
We went through the code and hardware with a fine tooth comb making it
as bullet-proof and error free as possible.
Did we reach 6 Sigma? Probably not but perhaps close.
george
| |
| Wayne Woodruff 2005-10-28, 7:58 am |
|
>We were required to have systems run in a test lab for one w error
>free before factory acceptance.
>
>We went through the code and hardware with a fine tooth comb making it
>as bullet-proof and error free as possible.
>
>Did we reach 6 Sigma? Probably not but perhaps close.
>
What was involved in determining the one w number? Does that map
to some reliability requirement?
Did you have defined metrics and take measurements? If not, you were
not six sigma.
Wayne Woodruff
http://www.jtan.com/~wayne
| |
| Sarr J. Blumson 2005-10-28, 6:59 pm |
| In article <2klul15gukn1u4tebebpd488cejbe6f0en@4ax.com>,
Wayne Woodruff <wayne@jtan.com> wrote:
>On Tue, 25 Oct 2005 21:43:06 -0400, Roy Smith <roy@panix.com> wrote:
>
>
>
>You might have a look here.
>
>http://software.isixsigma.com/libra...nt/c030910a.asp
Lots of good stuff about defining quality metrics for software. The fact
remains, however, that in a manufacturing context the term "six sigma"
actually means something while in software it's pure salespeak.
--
--------
Sarr Blumson sarr.blumson@alum.dartmouth.org
http://www-personal.umich.edu/~sarr/
| |
|
| Wayne:
You are correct. we didnot have a formal six sigma project.
The time period was the mid 1980s. Before six sigma was that popular
or formalized.
But I've not seem much description of actual projects.
The one w was set as a difficult yet reasonable goal so that design
problems (with the equipment) didn't get on to the factory floor.
The customer tracked failures for each manufacturing line and each
system in that line.
Systems that caused errors were removed and returned at our cost so we
have a great interest in creating bullet proof system.
gm
| |
| xpyttl 2005-10-29, 9:56 pm |
| "Sarr J. Blumson" <sarr@umich.edu> wrote in message
news:YBp8f.1071$yb2.271@news.itd.umich.edu...
> Lots of good stuff about defining quality metrics for software. The fact
> remains, however, that in a manufacturing context the term "six sigma"
> actually means something while in software it's pure salespeak.
Keep thinking that. That way my clients who keep finding a few million here
and there lying on the table can gobble you alive.
Process improvement means many things. Yes, in software, defects are
important. But they aren't the only thing. Although SS often focuses on
defects, the real mantra is "show me the money". SS as applied to software
isn't only about better (fewer defects) but also faster and cheaper. Guess
what. All three lead to more money.
Early SS implementations in software shops often focus on defects, however,
because most shops can make mucho dollars by improving their TCE and it's
easy money to grab. Other process improvements can often have greater
returns, but they are generally more difficult and harder to describe. So
you chase the easy money first to build credibility to allow you to go after
the big bucks later.
Another poster sopke about not injecting the defects in the first place, and
that is certainly a worthwhile goal. But it is a lot easier to simply find
them earlier, and it is fairly quick to get metrics to show you what that is
worth. And you can bet it is a lot.
...
| |
| Sarr J. Blumson 2005-10-30, 7:00 pm |
| In article <NCU8f.5310$7s1.2525@fe04.lga>,
xpyttl <xpyttl_NOSPAM@earthling.net> wrote:
>"Sarr J. Blumson" <sarr@umich.edu> wrote in message
>news:YBp8f.1071$yb2.271@news.itd.umich.edu...
>
>
>Keep thinking that. That way my clients who keep finding a few million here
>and there lying on the table can gobble you alive.
What "Six Sigma" means in manufacturing is: the measured size of something
(a hole in a cylinder block is an example I'm used to) is an random
variable. If there are no systematic errors (cutting tool wear, for
example) then the size will be normally distributed around the mean.
If 3 standard deviations (sigmas in the usual notation) from the mean
are within the tolerance, the probability of an out of tolerance hole
is deemed to be infinitesimal. Which is to say: "a six sigma range
must be within the tolerance.
I did not mean to suggest that software process improvement is smoke,
or without value in any other sense. All I meant to say is that what
I just described doesn't translate to software development in any
way that I understand, and so "Six Sigma" reduces to a  name for
"High Quality." High Quality is, of course, a good thing.
--
--------
Sarr Blumson sarr.blumson@alum.dartmouth.org
http://www-personal.umich.edu/~sarr/
| |
| Manager 2005-10-31, 7:01 pm |
| sarr, that is what my problem has been always. Am employee of a very
large defense company told me that they were using Six Sigma in their
software projects. I asked him to give me an example and he said he
couldn't as it is internal company stuff. I am reading some articles
from a site I have been recommended on this group. So far I haven't
found anything. To me, it seems like DMAIC is something we are doing
already.
| |
| xpyttl 2005-10-31, 9:56 pm |
| Sarr J. Blumson wrote:
> I did not mean to suggest that software process improvement is smoke,
> or without value in any other sense. All I meant to say is that what
> I just described doesn't translate to software development in any
> way that I understand, and so "Six Sigma" reduces to a name for
> "High Quality." High Quality is, of course, a good thing.
What you described was the statistical definition of six sigma, not Six
Sigma the process improvement methodology.
In some ways, Six Sigma is an unfortunate name because it is open to
that sort of misinterpretation. But SS is a process improvement
methodology applicable to all sorts of processes. In fact, the big
money is often not in the manufacturing processes, but in the
transactional processes where the defect rates are typically a lot
higher than manufacturing.
...
| |
| xpyttl 2005-10-31, 9:56 pm |
| In many ways, DMAIC is what almost every engineer knows he should be
doing. But few do, often because they somehow feel they don't have
"permission".
One of the many important dimensions of Six Sigma is that it takes
bright talent out of their ordinary jobs and focuses them on changing
things for the better. There are all sorts of things that conspire to
make it a very powerful methodology when you implement it fully, but at
the end of the day if you take bright people and tell them to make it
better, guess what. They will make it better.
...
| |
| xpyttl 2005-11-01, 8:02 am |
| > Process models like Baldridge, TQM, and Six
> Sigma are about how one monitors and corrects processes.
Six Sigma shares some common threads with things like TQM, but
sometimes it can be a mistake to think of SS as something like TQM.
There are substantial, and very meaningful, differences.
> Software development is a process, so
> they are applicable.
Absolutely.
> However, the notion of 'quality' that one is monitoring against is much
> broader in a software context than in a manufacturing context. For
> example, when applied to software development processes one must
> broaden the notion of 'defect' to include things like conformance to
> coding standards, which don't directly affect the product performance
> for the customer.
While often broadening the notion of a defect can be useful, in most
shops there are plenty of customer-affecting defects to be found, and
SS programs in software can usually be supplied with meaningful
projects around defect containment and schedule/budget failures to keep
them entertained for years.
> Similarly, one needs to broaden the notion of what a 'test' is to include
> things like peer reviews
This generally is true, and useful.
> The crucial idea behind such process models is that one should not be
> putting defects in the product (software) to begin with.
While it is certainly true that one should avoid inserting defects, SS
has no compunction at all about picking up dollars available by
removing defects before they become warranty costs.
> So models like Six Sigma monitor processes for /acceptable/ levels of
> defects, which is where Statistical Process Control (SPC) comes into
> the picture.
While SPC is certainly a useful tool, it tends to play a less prominent
role in SS than it does in, say, TQM.
> Another crucial idea behind such process models is the one should,
> over time, militantly s to reduce the acceptable level of defects
> inserted into the product.
Absolutely!
> One does that by incrementally improving the process itself so
> that inserting defects of the type found in the past is avoided in
> the future. To support that one must collect data about the
> defects when doing SPC.
While SPC is certainly a possible source of data, within SS it tends to
be a less important source.
SS is absolutely not TQM, although many of the goals are similar. SS
is largely about changing things for the better. A huge difference
between SS and earlier process improvement models is that in SS it is
important to monetize the benefits, and in most deployments, there is
some kind of involvement with accounting, controller's or some other
bean counter that management trusts. I know of one SS program that has
large benefits claims audited by an outside firm. When management sees
dollars, and those dollars have been validated by someone they trust,
it gets hard for them to loose interest!
Another difference is an openness to a greater variety of tools and
approaches. SPC is a classic example. TQM seemed to be all about SPC,
but in many software contexts, it is difficult to do anything
meaningful with SPC. Sure, you can make pretty charts, but getting
anyone to pay attention to them can be a problem. Especially in
software where the knob to tweak might not be so obvious.
So Six Sigma has a control plan, whose objective is to sustain the
benefits. The control plan might involve SPC, or it might not. And
most likely it involves other things too. But instead of blindly
drawing control charts, one thinks about what you are trying to do and
develops a plan appropriate for the situation.
...
| |
| H. S. Lahman 2005-11-01, 6:59 pm |
| Responding to Xpyttl...
>
>
> While SPC is certainly a possible source of data, within SS it tends to
> be a less important source.
>
> SS is absolutely not TQM, although many of the goals are similar. SS
> is largely about changing things for the better. A huge difference
> between SS and earlier process improvement models is that in SS it is
> important to monetize the benefits, and in most deployments, there is
> some kind of involvement with accounting, controller's or some other
> bean counter that management trusts. I know of one SS program that has
> large benefits claims audited by an outside firm. When management sees
> dollars, and those dollars have been validated by someone they trust,
> it gets hard for them to loose interest!
Actually, every process model I know of emphasizes incremental process
improvement and insists on quantifying the costs and benefits for every
improvement, including TQM. Quantification is the only way to ensure
that the cure isn't worse than the disease.
> Another difference is an openness to a greater variety of tools and
> approaches. SPC is a classic example. TQM seemed to be all about SPC,
> but in many software contexts, it is difficult to do anything
> meaningful with SPC. Sure, you can make pretty charts, but getting
> anyone to pay attention to them can be a problem. Especially in
> software where the knob to tweak might not be so obvious.
I'm afraid this is a misconception. SPC is only relevant to process
monitoring. All process models, including TQM, include far more than
just process monitoring. In fact, SPC is typically almost completely
automated while the core activities in such process models are executed
manually on an ongoing basis. IOW, the process model defines what the
/people/ should do and SPC is just a peripheral tool to assist them.
For example, the use of Hoshin Diagrams in TQM for rolling up planning
on all levels to ensure focus and consistency is about as far as one can
get from SPC. (I think if one were to isolate some feature of TQM as
being what it is all about, it would have to be the 7-Step process
employed by QITs or the PDCA wheel that one sees in CMM L5).
At another level I must disagree with the notion that SPC is not
applicable in some software contexts. Any process can be monitored with
SPC unless the process is not repeatable (in the CMM sense). That is,
whatever one can observe about a process to determine whether it is
being applied in a repeatable fashion can be measured and any such
measurements in repeated executions can be monitored with SPC.
So I don't think there is anything magic about SPC. It is just a
statistical tool for processing observations. As such it has no more
significance to the process model than a Pareto Diagram, Histogram, or
any of the other data processing tools that are bundled with such models.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH
|
|
|
|
|