bryan@quame.UUCP (Bryan A. Woodruff) (09/22/89)
I am the Product Manager for a Software Development firm. We publish software for use in quality control. One important aspect of quality control is PROCESS control. I feel that the software development process needs to be redefined. It seems that too much emphasis is on coding and not enough time is spent on the actual design. This is a fatal flaw with current engineering practices in the automobile industry, the aerospace industry and the electronic industry to name a few. Americans are too quick to get to production and spend too much time in rework areas. The Japanese have found a better way. They have controlled the process and are producing higher quality goods at a lower cost. Face it... the Japanese have to import practically EVERYTHING... their key is PRODUCTIVITY... minimize the rework and produce higher quality, and they are beating us in our own markets! The scary thought is that the Japanese are beginning to use this philosophy to work with software (philosophy -> Deming philosophy). If all follows, they will have perfected the software development process, and produce higher quality software (error free), faster and cheaper. Americans are catching on in the manufacturing areas, DOD will require that SPC (statistical process control) to be used on all defense contracts. I would hope that we catch on and begin to perfect the design process, get it under control, and produce higher quality software. (No vaporware, and no errors.) Please feel free to comment on this topic!! Send replys to ...!uunet!quame!bryan Bryan Woodruff, Product Manager / Sr. Programmer, Quality America, Inc. (...!uunet!quame!bryan) P.S. I refuse to use the term BUG -- it makes it sound as if it is not the fault of the software developer... it is an error... it is WRONG!!! (Process control --- a DEFECT!)
jcb@frisbee.Sun.COM (Jim Becker) (09/23/89)
In comp.software-eng you write: ->I am the Product Manager for a Software Development firm. We publish ->software for use in quality control. ->One important aspect of quality control is PROCESS control. ->I feel that the software development process needs to be redefined. [stuff deleted] I think that you are right on the money with this, and that there is a lot that can be learned from the Japanese and others. In my opinion, the reason that the process has not been standardized upon is that software is a very slippery creature. There are any number of methods and tools that can be used to generate it. This bastion to programmer creatitivity has prevented those that have tried to formalize it into a set process. With hardware design there are defined physical limitations and constraints that the engineer has to develop to for the product to function correctly. Hence the market for CAE has been a successful one. The manufacturing process also has these characteristics, and the metrics are will known. The software world is different in that there are few limitations to what can be done with software, and any number of ways that an implementation can proceed. My work for some time had to do with Configuration Management, CASE, and the software lifecycle. When selling a product that is to be used for an unknown customer base the process that that customer has defined for internal organization and evolution of their system is an unknown. Most of the elements of it are well understood, but the combinations into which the elements are assembled different greatly. This makes it difficult to move from the general to the specific in terms of the process. There have been over a hundred CASE products developed and introduced to the market in the past five years. In general these have to define a fairly specific process and project evolution path, thus greatly defining the working environment for the customer. This specificity has contributed to the downfall of a majority of these efforts, as the desired process for a given software development effort is determined on a company or group level rather than by a chunk of software from a third party vendor. Object oriented techniques, and high level tools, are needed within the scope of an entire system software development world before the process can be standardized upon. Once parts of the process are encapsulated at higher levels it will be possible to grab these chunks and organize them as needed for the specifics of the project. [Note that I am talking about OO in a very high level abstracted sense here.] If everyone continues to build off of the programmer tools of the past (SCCS/Make level) it will be difficult to revolutionize the software development process (IMHO). Hopefully CASE tools of the future will make the quantum leap needed to advance the evolution process to meet the increasingly complex needs of the software world. ->P.S. I refuse to use the term BUG -- it makes it sound as if it is not ->the fault of the software developer... it is an error... it is WRONG!!! I hate this term also, it's a defect -- not an insect. -Jim -- Jim Becker / jcb%frisbee@sun.com / Sun Microsystems ...these are my opinions, and even my id disagrees..
rsd@sei.cmu.edu (Richard S D'Ippolito) (10/05/89)
In article <135@quame.UUCP> bryan@quame.UUCP (Bryan A. Woodruff) writes: >The scary thought is that the Japanese are beginning to use this philosophy >to work with software (philosophy -> Deming philosophy). >If all follows, they will have perfected the software development process, >and produce higher quality software (error free), faster and cheaper. I have to disagree here -- error free does not equate to quality. The best process in the world can not turn a poor design into a good one; all it can do is produce faithful copies of the design. >I would hope that we catch on and begin to perfect the design process, >get it under control, and produce higher quality software. (No vaporware, >and no errors.) Again, the implication is that production process control has something to do with the design process -- they are separate! >Please feel free to comment on this topic!! Gee, thanks, but you knew we would feel free without the invitation! >P.S. I refuse to use the term BUG -- it makes it sound as if it is not >the fault of the software developer... it is an error... it is WRONG!!! Excellent sentiment -- I agree! Rich -- It is not the possible that determines what to hope for -- it is hope that determines what is possible. Richard J. Oman rsd@sei.cmu.edu -----------------------------------------------------------------------------
linda@rtech.rtech.com (Linda Mundy) (10/12/89)
In article <4331@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes: >In article <135@quame.UUCP> bryan@quame.UUCP (Bryan A. Woodruff) writes: > >>The scary thought is that the Japanese are beginning to use this philosophy >>to work with software (philosophy -> Deming philosophy). >>If all follows, they will have perfected the software development process, >>and produce higher quality software (error free), faster and cheaper. > >I have to disagree here -- error free does not equate to quality. The best >process in the world can not turn a poor design into a good one; all it can >do is produce faithful copies of the design. > I have some problems with your response. First, while "error free" is not the whole story of software quality, it's certainly a key element, not to be waved away lightly. Second, you imply that improving the software development process somehow means ignoring design issues, while also managing to imply that neither the Japanese nor Deming's system deal with those issues. I find this attitude both smug and naive. In fact, it reinforces Mr. Woodruff's comments -- it is a scary thought indeed that the Japanese will proceed with improvements in the software process, while our own engineers sneer at "process" and believe that they can produce quality software while ignoring process. In fact, process can affect design in a very positive way. For example, the process can ensure that marketing, sales, testing, and technical support people (to name but a few) are involved in initial high-level design, and in later (possibly lower-level) design reviews. This could have impact on: the usability of the interface, the actual features included in the product, the organization of the code, how it is shipped (what media, what is the organization of files, what is the installation procedure, etc.), and on whether it truly meets customer needs (marketing, sales and tech support are often in a better position to judge customer needs than are development engineers -- note I said "often", not always). And of course, to reiterate the original poster's point, process can certainly help to minimize errors in the code. Good code management procedures can make bug fixes visible (serving an educational purpose, helping people to avoid the same kinds of mistakes); it can help to ensure that old bugs don't creep back into the code, etc. In other words, process, at whatever level you chooose to define it, can have a major impact on software quality. Good theory, good algorithm design, good coding style -- all of these are necessary, but most certainly not sufficient to produce a quality product. > >>I would hope that we catch on and begin to perfect the design process, >>get it under control, and produce higher quality software. (No vaporware, >>and no errors.) > >Again, the implication is that production process control has something to >do with the design process -- they are separate! > Wrong. And especially in the arena of software! But don't take my word for it, allow me to quote Tom Peters from his latest book _Thriving on Chaos_: (discusses the flexibility of Japanese motorcycle companies, their ability to quickly introduce new models and to perfect the production process): "This requisite increased flexibility is possible only because of much tighter linkages among design, engineering, and manufacturing in Japan than in the United States. (This trait, also taught to the Japanese by American W. Edwards Deming,...etc.)" and later in the same book: "Thus, in the first place, the Japanese treat every product as an ongoing experiment and are constantly engaged in improving it. Second, the typical Japanese firm's close integration of design, engineering, and manufacturing induces constant experimentation..." and later: (discussing the success of Ford's Team Taurus effort): "With Taurus ... we brought all disciplines together ... The manufacturing people worked right with the design people, engineering people, sales and purchasing, legal, service and marketing." Note that while the above discussions mention flexibility, the whole point is *better quality, as perceived by the customer*. The flexibility allows the necessary responsiveness to customers, so that those other quality issues -- like, are these features useful to actual paying customers -- can be addressed effectively. > >>Please feel free to comment on this topic!! > >Gee, thanks, but you knew we would feel free without the invitation! > >>P.S. I refuse to use the term BUG -- it makes it sound as if it is not >>the fault of the software developer... it is an error... it is WRONG!!! > >Excellent sentiment -- I agree! > > >Rich >-- >It is not the possible that determines what to hope for -- >it is hope that determines what is possible. >Richard J. Oman rsd@sei.cmu.edu >----------------------------------------------------------------------------- -- "Who are you to tell me to question authority?" Linda Mundy {ucbvax,decvax}!mtxinu!rtech!linda
rsd@sei.cmu.edu (Richard S D'Ippolito) (10/13/89)
In article <3806@rtech.rtech.com> Linda Mundy writes: >In article <4331@ae.sei.cmu.edu> Richard S D'Ippolito writes: >>In article <135@quame.UUCP> Bryan A. Woodruff writes: >> >>>The scary thought is that the Japanese are beginning to use this philosophy >>>to work with software (philosophy -> Deming philosophy). >>>If all follows, they will have perfected the software development process, >>>and produce higher quality software (error free), faster and cheaper. >> >>I have to disagree here -- error free does not equate to quality. The best >>process in the world can not turn a poor design into a good one; all it can >>do is produce faithful copies of the design. >> >I have some problems with your response. > >First, while "error free" is not the whole story of software quality, it's >certainly a key element, not to be waved away lightly. Beg pardon, but I don't see why there is a problem here -- I can't see where I said otherwise. We have a large process group here at the SEI. >Second, you imply that improving the software development process somehow means >ignoring design issues, while also managing to imply that neither the Japanese >nor Deming's system deal with those issues. I find this attitude both smug and >naive. Indeed, it is naive, but it is not my attitude. My comments were that quality means more than absence of errors and that a perfect process does not guarantee quality (nor even absence of all errors!). Yes, I wrote "perfect" process. >In fact, it reinforces Mr. Woodruff's comments -- it is a scary thought >indeed that the Japanese will proceed with improvements in the software process, >while our own engineers sneer at "process" and believe that they can produce >quality software while ignoring process. I don't find that attitude prevalent in the large-system industries, and I'd have to conclude that anyone who sneers at processes is not an engineer. Perhaps we'd better settle on a definition of process lest we pass in the dark. What is it to you? Are you refering to the design process or to the production process? Are methodologies included? Later, you reproduce several quotes (from Tom Peters) that separate design and engineering, using those quotes in an attempt to prove that for software, production process control is the same as the design process. As a professional design engineer, I disagree. Furthermore, the products cited do not have the same kind of post-deployment modification/enhancement requirements. We simply can't expect to upgrade a Taurus to a Town Car. Rich -- We use kill ratios to measure how the war is going. We use SLOC ratios to measure how our software is coming. (Idea from Gary Seath) rsd@sei.cmu.edu -----------------------------------------------------------------------------
linda@rtech.rtech.com (Linda Mundy) (10/17/89)
In article <4472@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes: >In article <3806@rtech.rtech.com> Linda Mundy writes: > >>In article <4331@ae.sei.cmu.edu> Richard S D'Ippolito writes: >>>In article <135@quame.UUCP> Bryan A. Woodruff writes: >>> >>>>The scary thought is that the Japanese are beginning to use this philosophy >>>>to work with software (philosophy -> Deming philosophy). >>>>If all follows, they will have perfected the software development process, >>>>and produce higher quality software (error free), faster and cheaper. >>> >>>I have to disagree here -- error free does not equate to quality. The best >>>process in the world can not turn a poor design into a good one; all it can >>>do is produce faithful copies of the design. >>> >>I have some problems with your response. >> >>First, while "error free" is not the whole story of software quality, it's >>certainly a key element, not to be waved away lightly. > >Beg pardon, but I don't see why there is a problem here -- I can't see where >I said otherwise. We have a large process group here at the SEI. > I read your response as a dismissal of Bryan's concerns. While that may not have been your intent, I don't see that my reading was out of line, since you not only pointed out that error-free does not equate to quality (I agree), you also went on to downplay the role of process in software design. > >>Second, you imply that improving the software development process somehow means >>ignoring design issues, while also managing to imply that neither the Japanese >>nor Deming's system deal with those issues. I find this attitude both smug and >>naive. > >Indeed, it is naive, but it is not my attitude. My comments were that >quality means more than absence of errors and that a perfect process does >not guarantee quality (nor even absence of all errors!). Yes, I wrote >"perfect" process. > I don't believe that there can be such a thing as a "perfect" process. I do believe, however, that process can have a huge influence on quality. Of course, there are never any guarantees: that's what keeps life interesting! > >>In fact, it reinforces Mr. Woodruff's comments -- it is a scary thought >>indeed that the Japanese will proceed with improvements in the software process, >>while our own engineers sneer at "process" and believe that they can produce >>quality software while ignoring process. > >I don't find that attitude prevalent in the large-system industries, and I'd >have to conclude that anyone who sneers at processes is not an engineer. >Perhaps we'd better settle on a definition of process lest we pass in the >dark. What is it to you? Are you refering to the design process or to the >production process? Are methodologies included? > Okay. Process exists at many levels: from inception of an idea, to the more detailed design level, to the initial software construction (where, for example, CASE tools may help to track relationships between modules, etc.), to the methods of building a system, to handoff/testing/CM procedures, to shipping. Some of these have methodologies (e.g. CASE, CM tools) which may be used; some don't. > >Later, you reproduce several quotes (from Tom Peters) that separate design >and engineering, using those quotes in an attempt to prove that for >software, production process control is the same as the design process. As >a professional design engineer, I disagree. Furthermore, the products cited >do not have the same kind of post-deployment modification/enhancement >requirements. We simply can't expect to upgrade a Taurus to a Town Car. > Actually, I am not trying to "prove" anything. And while I don't believe that design and production are the same thing, I think that one can influence the other, and I think that Peters' points are valid for software too. You say, for example, that software is unique in its enhancement requirements. In the book cited, however, Peters points out that Japanese motorcycle manufacturers can introduce one new model *per month*, on average, because of flexibility in the production process. Such flexibility can only be attained with designs which allow flexibility also (like modularity). No, we can't upgrade a Taurus to a Town Car. But, can the production line be changed, thus allowing the manufacturer more flexibility in response to market demand? Actually, software customers don't upgrade models either -- we send them a new model. But in order to do this, we need to have the process to do so. Given that software is more readily and frequently modified, then isn't the payoff even greater if we can design it in a modular fashion, so that changes are more easily (and robustly) plugged in? I am not just speaking at the lowest code level, rather, look at functional units, look at build processes, look at how the software can be put together on the different target platforms; all of these things can influence *flexibility*, and they can influence design. > >Rich >-- >We use kill ratios to measure how the war is going. >We use SLOC ratios to measure how our software is coming. >(Idea from Gary Seath) rsd@sei.cmu.edu >----------------------------------------------------------------------------- -- "Who are you to tell me to question authority?" Linda Mundy {ucbvax,decvax}!mtxinu!rtech!linda
rsd@sei.cmu.edu (Richard S D'Ippolito) (10/17/89)
In article <3828@rtech.rtech.com> Linda Mundy writes: >In article <4472@ae.sei.cmu.edu> Richard S D'Ippolito writes: [deleted -- see references] >>Perhaps we'd better settle on a definition of process lest we pass in the >>dark. What is it to you? Are you refering to the design process or to the >>production process? Are methodologies included? >> >Okay. Process exists at many levels: from inception of an idea, to the more >detailed design level, to the initial software construction (where, for >example, CASE tools may help to track relationships between modules, etc.), >to the methods of building a system, to handoff/testing/CM procedures, to >shipping. Some of these have methodologies (e.g. CASE, CM tools) which may >be used; some don't. There is a rather large jump here from "inception of an idea" to "detailed design level" that I don't know what to make of. Furthermore, there seem to be some initial stages missing having to do with what I would call the design process. Except for the first item in your list (which I am unable to paste on a process model familiar to me), the items listed all are post-design. It is in this gap where quality is designed in, and the process of design is not subject to statistical control. Production is, and feedback to the designer is necessary, but the optimum process does no more than guarantee that one obtains the quality designed in. >You say, for example, that software is unique in its enhancement requirements. Nope -- I didn't say that! I said that "the products cited" in your example are not in the same league as the large systems that I refered to before with respect to "post-deployment modification [and] enhancement." Actually, except for recalls to fix assembly or design errors, they are never enhanced. Motorcycles and cars are rather trivial systems compared to the big boys. >Actually, software customers don't upgrade models either -- >we send them a new model. Not true for many large systems having lifetimes measured in decades. Rich -- We use kill ratios to measure how the war is going. We use SLOC ratios to measure how our software is coming. (Idea from Gary Seath) rsd@sei.cmu.edu -----------------------------------------------------------------------------
sps@ico.isc.com (Steve Shapland) (10/19/89)
In article <4520@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes: >In article <3828@rtech.rtech.com> Linda Mundy writes: >>In article <4472@ae.sei.cmu.edu> Richard S D'Ippolito writes: > >[deleted -- see references] > >>... Process exists at many levels: from inception of an idea, to the more >>detailed design level, to the initial software construction (where, for >>example, CASE tools may help to track relationships between modules, etc.), >>to the methods of building a system, to handoff/testing/CM procedures, to >>shipping. ... > >... the process of design is not subject to statistical control. Perhaps the process of design is not subject to statistical control, but it CAN be measured. The "products" of the design process are documents describing the design and the resulting code. Consider the following metrics (to mention just a few): 1) Differences from the functional specifications. 2) Design complexity (number of modules, control parameters, etc) 3) Amount of "re-used" concepts/code 4) Design flaws found "down stream" Once these metrics are being collected, they may be used to monitor the design process. The process may be altered, and the metrics may be used to determine if the modification has improved the process. (This is a basic process improvement technique.)
rsd@sei.cmu.edu (Richard S D'Ippolito) (10/21/89)
In article <1989Oct18.223311.6954@ico.isc.com> Steve Shapland writes: >Perhaps the process of design is not subject to statistical control, >but it CAN be measured. The "products" of the design process are >documents describing the design and the resulting code. Partly right -- the code is not part of the design; it is the implementation of the design. >Consider the following metrics (to mention just a few): > 1) Differences from the functional specifications. Which functional specs? Design or implementation? > 2) Design complexity > (number of modules, control parameters, etc) At what level are you measuring this? Many of these items are implementation dependent. > 3) Amount of "re-used" concepts/code Again, the level and quality of the reused material matters. One should also measure this against the potential of reuse. > 4) Design flaws found "down stream" Sure, as long as those errors can properly be attributed to design and not production. Rich -- We use kill ratios to measure how the war is going. We use SLOC ratios to measure how our software is coming. (Idea from Gary Seath) rsd@sei.cmu.edu -----------------------------------------------------------------------------
PAAAAAR@CALSTATE.BITNET (10/25/89)
Steve Shapland <gem.mps.ohio-state.edu!ginosko!cs.utexas.edu!ico!vail!sps@ohio-state.arpa> Writes >>... the process of design is not subject to statistical control. >Perhaps the process of design is not subject to statistical control, but >it CAN be measured. The "products" of the design process are documents >describing the design and the resulting code. Consider the following >metrics (to mention just a few): > 1) Differences from the functional specifications. It is possible to automatically compare successive documents to see if they use the same vocabulary. This assumes that the clients/users words are an important part of the problem and so should appear in the solution. For example if a requirement mentions "widget" then so must appear in at least one program specification and possibly as an object or at least a piece of the source code or variable. Dick Botting, Department computer science, California State University, San Bernardino, CA 92407 "where smog of LA, is blown away, and the sun shines bright all the day"! PAAAAAR@CCS.CSUSCC.CALSTATE paaaaar@calstate.bitnet PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU Disclaimer: The above are not opinions of CSU or any part of of CSU