Path: utzoo!attcan!uunet!cs.utexas.edu!wuarchive!uwm.edu!uakari.primate.wisc.edu!ames!sun-barr!newstop!sun!frisbee!jcb
From: jcb@frisbee.Sun.COM (Jim Becker)
Newsgroups: comp.software-eng
Subject: Re: Software QUALITY Engineering
Keywords: SOFTWARE QUALITY
Message-ID: <125167@sun.Eng.Sun.COM>
Date: 22 Sep 89 22:10:42 GMT
References: <135@quame.UUCP>
Sender: news@sun.Eng.Sun.COM
Lines: 72


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..