Process Improvement Tools
Process Improvement ToolsThe paradigm shift we really need in software is to believe it is similar to other endeavors and use the process improvement tools that have been successful in other areas. Software repeatedly casts itself as something different and unique from the rest of the world. Hence, we are always struggling to do new things instead of taking advantage of others' knowledge and experience. --WayneMack
Process Improvement Tools -- Candidates:
Process can be improved when guides, and organization of effort are instituted.
SWEBOK - An organized effort to develop a guide to the SoftwareEngineeringBodyOfKnowledge (SWEBOK) was begun in 1999. A comprehensive hierarchical collection of topics is addressed with pointer to appropriate reference materials. The 1.00 (trial) version is available for download at -- http://www.swebok.org
The ACM has distanced itself from the SWEBOK.
Because SWECC has become so closely identified with licensing of software engineers under a professional engineer model, the ACM Council decided to withdraw from SWECC.
Although ACM has withdrawn from SWECC, ACM believes the problem of reliable and dependable software, especially in critical applications, is the most important problem facing the IT profession. ACM will continue to work closely with IEEE Computer Society on projects that further the evolution of software engineering as a professional computing discipline and improve the quality of software and the capabilities of software engineers.
http://www.acm.org/serving/se_policy/selep_main.html
Process can be improved through the use of models, frameworks and conceptual progression
CapabilityMaturityModel - The CMM framework comprises five levels of process maturity, each with specific characteristics and features.
Process can be improved within a LearningOrganization
A learning organization is an organization skilled at creating, acquiring and transferring knowledge [required for the success of the business], and at modifying its behavior to reflect new knowledge and insights [Garvin].
http://www.solutiond.com/smart-wins--background-on-learning-organizations.htm
See also TheFifthDiscipline.
Models and cyclic processes used by learning organizations:
http://members.aol.com/kaizensepg/qprocess.htm
Process can be improved by recognizing its distinctions
AnalogyBetweenProgrammingAndManufacturing
... the failure of software to improve process is evidence that it really is something different. SoftwareIsNotManufacturing.
Software is neither entirely unique nor entirely like any other production endeavor we are familiar with.
A process can be improved only through understanding of the process. After gaining understanding, then lessons learned in other processes can be appropriately applied. To date we have failed to understand software development, so analogies to other things are largely meaningless, and lessons learned are as yet not applicable.
A counter-argument is that new knowledge comes from outside a system (see WilliamEdwardsDeming). If we already know how to improve software development, how come we are not already doing it? In this view, the "failure of software to improve process" is evidence that software development needs to look outside itself to find answers. Please consider that if we truly wish to change the results of the software development process, we need to do fundamentally different things within the software development process. We will not find these things by looking at the current software development process, rather we must look outside it.
Process can be improved by utilizing lessons learned and through enquiry into investigations and reports published by others on the topic.
Software Improvement Process - John D Vu - http://www.sasqag.org/pastmeetings/SASQAGvu.PDF
Process can be improved by the introduction or utilization of constructs from other disciplines
I would suggest looking at the TheoryOfConstraints by EliyahuGoldratt. In software, we could treat software changes begun, but not yet completed as inventory. What are the steps needed to reduce the amount of inventory? What are the steps needed to reduce the delay from the time a user conceives of a need to the time he has software addressing the issue in his hands?
Even calling software development a "process" is problematic. Maybe calling software development (or parts of software development) a "skill" would help. Then we could borrow "skill improvement tools" and "skill improvement techniques" from other endeavors. See WhatRecursEverySoftwareProject.
Would you care to expand on why the term "process" is problematic? I see a "skill" as something an individual may possess, while a "process" is something that a business may do. I think it is also important to distinguish between a "process" and a "project." A project is bounded in terms of budget, resources, and schedule. A process has none of these bounds. A lot of CMM, ISO, and the like focus on software development as a project, not software development as a process.
I'm not the original author above, but I have this to say. Simplistic views of process are problematic. When we catch ourselves talking about "the process", we're living the problem (maybe causing it). Software developments can be decomposed, with difficulty, into overlapping, interacting, interfering, cooperating simple processes. But those products of decomposition are not the "development process" any more than fungicide is "farming".
Software process work is advanced systems work, nonlinearity being its native tongue. Perturbing such systems often yields unanticipated results. This can be most frustrating when management has decreed that "process shall be improved by a measure of 'M' no later than time 'T'". It's refreshingly easier to focus on individual skills, and it remains true to the present that the unskilled continue to enter the field on the welcome mat of bargain prices per line of code. Skills improvement issues will persist, and should not be ignored.
But skills are not software process, not even process improvement tools.
"But skills are not software process, not even process improvement tools."
The first part of the above statement is obviously true, while the second part is probably false. Skills and experience are most definitely tools employed in the improvement of "Process".
The point of this particular section is that often skills applicable in other disciplines can be converted and applied to this improvement process. One example which comes to mind is that of employing graphical modeling and flowcharting (such as in UML). The whole idea of "patterns" is also an example of a method or process which can improve the process of the development of software (even though originally introduced as a tool to be used in an architectural framework).
Clarifying the difference between skill and process
Let's keep clear on the distinction between a skill and a process, and between software engineering skills and software process improvement skills, instead of lumping it all into one big skills/process salad. You can learn the notations and semantics of UML and still be short of an effective process for applying it to your work. You may have a deep appreciation and understanding of software design patterns and still not know what to do next.
"Process" certainly implies activity. So as not to twist the software engineering lexicon into anything uglier than it already is, we should agree that a tool is something besides yourself, used between you and the problem to perform a task better than you could do it by hand? Also agreed is that a skill is an acquired aptitude for using a tool, or for direct manipulation in the absence of tools. In that simple sense, skills are never tools.
If we make a distinction between
process improvement process process improvement tools* process improvement skills* tool improvement process tool improvement tools tool improvement skills* skill improvement process skill improvement tools skill improvement skills*then I guess my viewpoint is that all of the above can be used to improve software development (with the starred ones being my favorites), since software development is part process, part tools, and part skill. -- StanSilver
Process defines skills
I would place "process" at the top of the hierarchy. The process will define what skills are needed. If the process is correct, then skill improvement is helpful. Tools are automation of the process. Again, if the process is correct, then automation of the process is helpful. I am questioning whether we have a strong enough grasp of the software development process to evaluate skills or to automate it. --WayneMack
That brands you as a "process guy", Wayne, which is not at all bad, but it's also not the most versatile stance either. Sometimes, in the interest of getting something done, processes have to be tailored to present skill levels and present tools. That could be part of the definition of "correctness" for the process, could it not?
Doing Things, Not getting things done
Let me first clarify that when I am talking about a software development process, I am not talking CMM nor a project plan full of deliverable documentation. All processes will have unnecessary steps, missing steps, and less than optimal steps and correcting these issues is process improvement. If you do have a process, however, I do not see how you can justify omitting steps because you do not have the necessary skills or tools. In the "interest of getting something done," would you omit compiling software because you do not have the appropriate compiler tool? That is an extreme example, but would someone care to list some necessary parts of the software development process that can be omitted? A process is about doing things not "getting things done." A process can be improved so that you can do things better, but I don't believe it can evaluated for "correctness." Please, don't read "project," "milestone," or "deliverable" into the term process. These things may happen multiple times due to the process, but they are not the process. -- WayneMack
Well, above you refer to the process being "correct", and I was not holding a gun to your head when you wrote that, so I assume you'll take responsibility for it now, and perhaps tell us what you really meant. :-)
Changes, omissions, sequences, and hierarchies
I don't know about omitting essential steps, but I can say that I've seen teams that can't seem to hold productive discussions of requirements jump right into design and end up solving the requirements problems somewhat indirectly and somewhat unconsciously, but adequately nonetheless. Some might object that they are visiting requirements issues out of sequence, and I would offer the opinion that if they developed the skill to discuss requirements a bit more abstractly, they could do their development with less wasteful backtracking, but it's only a hunch. However, without serious motivation to change (which would come from where?), this group is best off doing requirements their own way. And that's a practical matter, whether you call it "doing things" or "getting things done". What I'm saying is that they're better using their own style, at least for now, even if it's unorthodox. Better skills would open up some options... You get my drift. There's nothing special about "the process" that makes me want to list it at the head of the hierarchy, or even have a hierarchy for that matter.
I think we may be in underlying agreement, but using different definitions of the term "process." It is unfortunate that the word "process" has often been recast into meaning a series of discrete, one time steps producing a series of "artifacts" of interest to no one.
Use cases and the software artifacts produced
As an alternative, look at the software development process as taking concepts from the minds of users (user use cases) and returning them to the users as executable software. This definition should probably be word-smithed to include unconscious, non-verbalized needs of the users as well (artifact use cases). Once you define the software process in this manner, then you can analyze your software development work-flow and see what things help and hinder the process. It is only at this point that you can determine what skills and tools are needed to improve the process and it is only at this point that you can make a non-arbitrary decision on what parts to discard. Look at a process as an ongoing activity, not as a set of steps to be completed.
To go back to Walden's concern, does a development group having requirements discussions help or hinder in moving a concept from a user's mind into his hands as working software?
Processes, as per the TheoryOfConstraints, will always have a bottleneck. One of the key concepts is to make sure the process has only one bottleneck and to then optimize the process around that bottleneck.
-- WayneMack
Let me back up and explain the reasoning that got me to this point, and then we can have an open discussion and critique on my logic and choices.
All right, Wayne. Thanks for restoring some sanity. I'm going to take the liberty of numbering your paragraphs, to make reference easier.
Do you want to try to get specific about which tools, etc., you feel transfer from what other disciplines to software, or is it too early to do that? Should I instead interpret the first point as a statement of faith or hope?
I believe it would be premature to discuss specific process improvement tools until there is agreement on item 2. Until there is agreement on the scope of software development, there can be no agreement on the evaluation criteria to apply to tools used to accomplish the improvement.
I'm a little hung up on what you mean by "define" in your second point. In a more mathematical interpretation, a definition includes reference to the inner structure of the thing you are defining. The vulgar meaning of process fits well with that, too. Your overview approach in this point might better be called a goal than a process. Then you don't need to invoke yet another term (work-flow) to develop your thoughts. That's my suggestion on the use of terminology, for what they're worth. So you're really saying: Set some goals before embarking on "improvement"., and I wholeheartedly agree.
The referenced item could using some rewording. I would like to convey the point that we need to identify the scope of software development (who is included), who should evaluate software quality, and how should software quality be evaluated.
The "from mind of users to hands of users" is poetic: I like it. Needs development, though. For instance, how do you address the quality issues of starting with bad ideas from users?
Who decides that users' ideas are "bad?" This again is leading back to the scope issue.
Your fourth point smacks of vulgar truth, but you'd better put some though into the nitty-gritty of how to do this. Once again, the quality problems lay waiting to trip you up. Or do they? In any event please develop further.
This point is merely highlights the need to define what we are discussing before it is possible to determine whether we have improvement. The current practice in software development is to have some unknown party anoint something as an "industry best practice" or proclaim "just do it" with little more than hearsay evidence that the practice actually provides improvement.
By the way, do you know that develop is the opposite of envelop, and that by choosing to develop software, you are unwrapping something to expose its nakedness to the world? Is it the user's thoughts being so exposed, I wonder?
Interesting, but I am not sure I like the implications. In software development we start with a business process and no new software (the existing process may have no supporting software or may have legacy supporting software) and create software to support the process. Note that the existing process may (and it is likely that it will) have to change to take advantage of the software. The software is something new to be created, not an existing thing to be revealed. As an aside, following this concept further invalidates the idea of "developers injecting defects."
Responses added inline with the hope it will aid in conversion to document mode. --WayneMack
Process can be improved when the bottlenecks in the transformation of inputs to outputs are recognized and handled as constraints to be minimized or eliminated.
I am defining the software development process in terms of its inputs and outputs. In general, a process consists of inputs, outputs, and the transformation between the two. Different instances of software development processes will have different transformations but will share inputs and outputs. Process improvement is now a matter of improving the transformation.
For the sake of discussion within this section (and partially due to the lack of better terminology), I have proposed defining the inputs of the software development process as the ideas in the minds of users and the outputs of the software development process as those ideas implemented and in use by the users. Furthermore, I have proposed evaluating the transformation using the TheoryOfConstraints.
The TheoryOfConstraints says every process will have constraints or bottlenecks and the way to optimize a process is to select one constraint as dominant and make the rest of the process subservient to that constraint. The rest of the process runs at the rate of the dominant constraint. At this point and not before, process improvement efforts shift from everything around the constraint to the constraint itself. As an aside, the best way to identify a constraint is to locate a step with a backlog of work in progress preceding it.
For software development then, the next step is to identify possible constraints and select which should be the dominant constraint.
Process can be improved when the unit of measure is defined relative to the user and user function-ability.
To continue on, I think one of the key points is the use "user ideas" as the unit of measure (and I freely admit this is taken from ExtremeProgramming). This is in contrast to more common units of measure such as lines of code, function points, executable files, or releases. Lines of code and function points are too fine a level of detail while executable programs and releases are too large. "Ideas" also seem to have a higher level of persistence, as we are able to define them well before any lines of code are written or modified and can still identify them well after a particular release is forgotten. This makes them traceable and this traceability is needed if we are to do any analysis of a software development process.
Study Successful Projects
Don't forget this one. Civil engineering, to name one other discipline, is big on studying successful (and unsuccessful) projects throughout the industry. Nothing brings a lot of abstract ideas into focus faster than looking at real problems on real projects. --IanRae
Unfortunately, most of the "study" of software projects is done by non-programmers. As anyone working in a "CMM heavy" environment can attest, we are drowning in documentation to describe the operation of software for review by non-programmers and woefully inadequate when trying to make software descriptive for programmers.
I also believe we need to get a definition of what constitutes a "successful" and "unsuccessful" software project. In most software projects this is usually tied to meeting or overrunning funding or continuation or cancellation of funding. To continue the civil engineering analogy, I have never seen civil engineers in a panic because highway projects go over budget or office building projects get canceled part way through during economic hard times. In software, however, we tend to get caught up in these concerns and gloss over true programming failures. For example, a few years back, a Mars lander was lost because part of the system used miles per hour and another part used kilometers per hour. That was a true software failure, but we do soul searching instead on things like the Standish Group reports that large numbers of projects go over budget or are stopped due to lack of funding.
-- Sounding a little bit more soap boxish than I had intended, WayneMack
This is an interesting page. I can't wait till it settles down and gets refactored into document mode. Some good distinctions made so far.
See
Another excellent book that includes a section on software process improvement is "Debugging the Software Process" by Steve Maguire.
Were you thinking of DebuggingTheDevelopmentProcess?
EditText of this page
(last edited October 30, 2010)
or FindPage with title or text search