| H. S. Lahman 2005-09-09, 6:59 pm |
| Responding to Frye...
> I have always been curious about how Six Sigma techniques are applied
> to the development of software. I was trained in Six Sigma techniques
> (Certified Black Belt) in the mid 1990's in a manufacturing
> environment. But I have never had the opportunity to research how
> these techinques are applied to software development.
>
> It seems to me that software development would be a different problem
> based on the nature of the process. In most manufacturing environments
> you are making many parts with a process that has inherent standard
> variation that you want to contol. If you are applying 6 sigma
> techniques to a large complicated product with a long production time,
> you usually apply the techniques to the components or the processes
> that make up the part, which in themselves are repeated many times.
The notion of 'defect' tends to be different but the basic SPC process
monitoring still applies. For example, suppose one is in a shop that
prepares formal SRSes. Defects coming out of the SRS review would be
things like missing requirements, non-testable requirements, incorrect
requirements, ambiguous requirements, etc. One can still count such
defects and normalize to some measure of SRS size to determine is the
SRS preparation process is within the SPC envelop established for
previous SRSes. That monitoring of the preparation process would be
quite valid regardless of what the specific product was. Similarly, one
can define defects for things like maintainability that have nothing at
all to do with the correctness of the software.
>
> Software Development is fundamentally different. You produce one
> product of variable complexity. For commercial software, you may have
> millions of copies of this product, but the copies are usually produced
> with no variation (digital copies) and if there is variation, its not
> inherent to the programming process. This makes it sound as if Six
> Sigma techniques are only applicable to job shops. (please correct
> me!!!)
I am inclined to disagree with this. Shops do not <usually> create one
application and disband. They tend to create new but similar
applications or provide new features to existing software. IOW, they
tend to product more of the same. In addition, to manage complexity
larger applications are subdivided and modularized so that subsystems or
modules are developed as discrete entities. Thus the shop performs the
same analysis, design, and programming activities repeatedly on a large
number of software units over time. Then each unit produced is a sample
against the development process even if it is only a small part of a
major project.
Thus process improvement frameworks like Six Sigma are aimed at the
/process/ of developing software, not the specific products. So the
subject matter of the unit of software being developed doesn't matter
but conformance to the A/D/P methodology when producing it does. If one
defines defects in a manner than reflects conformance to process, then
the process improvement framework will Just Work.
> Another thing I remeber from my Six Sigma days is the importance of
> having a stable repeatable process before analyzing it for variation
> and then ferreting out the causes of that variation. I can't imagine
> software development being a stable repeatable process unless your just
> writing CRUD programs. Every application seems to have its own
> challenges and solutions and even the same application developed by two
> teams from the same specification is likely to be implemented in
> significantly different ways. For that matter, even the solutions made
> by the same team for the same requirements can be very different. The
> process to achieve the goal of developing the software may follow the
> same steps, but the actual production process (generating the code) has
> to be developed at the time you design the software and that design
> will be different for each piece of software.
Again, the repeatability is not in the product but in the process.
Having a stable A/D/P process does not imply that the results will be
exactly the same because it is primarily an intellectual exercise and
there is often no deterministic standard for "best". So small changes
in problem, environment, personnel, etc. can result in significantly
different software even though the same basic A/D/P process is applied.
An analogy is a linear programming solution with a constraint matrix of
thousands of elements. I have seen a single small change to one cell in
the matrix produce a completely different solution even though one
applies exactly the same algorithm to the solution.
Bottom line: process improvement frameworks monitor How the software is
produced, not What is produced. At a high enough level of abstraction,
all software developers do is move bits from one pile to another
repeatedly. At such a level of abstraction the semantics of the piles
is lost but one can still define the "right" way to move the bits.
*************
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
|