From: jcardow@afit.af.mil (James E. Cardow)
Subject: Goal of Software Engineering (Was: Do Software Engineers Actualy do so 
Keywords: Goal
Organization: Air Force Institute of Technology
Date: Wed, 14 Oct 1992 21:02:41 GMT


Since I asked the question, I've received some interesting answers:

	"The goal of software engineering is building software to 
	stated purpose."

	"The goal is to produce reliable software in a predictable
	manner."

	"The goal of software engineering is predictability (features, 
	quality, schedule, and cost)"

	"Improve the quality of engineering products and improve the
	means by which the products are created."

	"Instantaneous control"

	"To produce software which solves problems without creating
	them, and produce that software reliably, on time and on
	budget."

It was interesting that the characters in the book followed some similar
thinking.  The effort started when the manager is trying to convince the
consultant of the value of the factories robots.  He claims they are
highly productive, but the consultant distroys the argument with three
questions "did you ship any more products" "did you reduce staffing" and
"did you reduce levels of inventory"  The consultant says "productivity
is meaningless unless you know what your goal is."  And I'm not sure we
have the goal of software engineering in any of the above.  (By the way,
I'm not saying the book is gospel, but I want to use it for logic
checks.)  The manager in the book eventually rules out many goals for
the factory in the following manner:
	Produce products (not if they are not bought?)
	Produce quality (why did Rolls Royce go bankrupt?)
	Produce a quality product efficiently (why did VW stop making
	the bug?)
	Technology (why aren't R&D types in top positions?)
	Efficiency, quality and technology (?)
	Sales (market shares--can be achieved by selling at loss)

Now, this seems like a senseless argument when applied to software
engineering, but some of the things that come up ring home.  Robots
sounds an awful lot like the arguments for CASE and many other
"productivity" enhancers.  Other arguments in the book for cutting
manning, getting higher utilizations out of people and machines also
reflect on arguments presented to "meet the organizational goals", but
what was most compelling was the management inability to recognize the
flaws in existing procedures (in this case accounting).

Another input to my question asked if we shouldn't look to architecture
as the model, with recognition that the goal was to design buildings
meeting customer needs and safe.

But let me ask a really off the wall question (academics this one will
hurt), why isn't the goal to make money for us as well?  As a craft, we
did okay.  Lotus, microsoft, and many government software houses did
well, especially as the only source of products.  As a production effort
we seem to have problems, unpredictable schedules and costs, unreliable
systems etc.  That is why the term software engineering was coined, but
unfortunately this approach seems to be the goal is to solve our
problems.  Would we be better off with a competitive goal similar to
money?  If results of productivity efforts were tied to the goal would
there be unrealistic management promises?  Would products that did not
meet the customer needs or expectations continue to be a problem?

Aren't the things suggested above as goals really part of the
measurement?  Especially predictability?  As strange as it sounds, I
know and believe that process improvement and measurement are solutions,
but I just can't fix on the goal, so I can't help wondering if we are
running faster on a treadmill.  We teach a lot of process stuff here and
just once I stopped and asked the class if they ever saw a sound
financial arguement for doing process improvement, none had, neither had
I.

Well, I'm definately heading into the "touchy-feelly" world with this so
I'll stop.  Any thoughts on other goals please send them.  By the way, I
think the goal of building to stated purpose is on track, but omitts the
se task of requirement elicitation--one of our fundamental problem
areas.

Jim

Newsgroups: comp.software-eng