Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!uwm.edu!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!purdue!bu-cs!oliveb!amdahl!dgcad!gary
From: gary@dgcad.SV.DG.COM (Gary Bridgewater)
Newsgroups: comp.software-eng
Subject: Re: Information Systems is an Engineering Discipline
Message-ID: <1142@svx.SV.DG.COM>
Date: 28 Sep 89 09:19:22 GMT
References: <592@halley.UUCP> <34371@regenmeister.uucp>
Reply-To: gary@svx.SV.DG.COM ()
Distribution: comp.edu
Organization: Data General SDD, Sunnyvale, CA
Lines: 46

In article <34371@regenmeister.uucp> chrisp@regenmeister.uucp (Chris Prael) writes:
>From article <592@halley.UUCP>, by joannz@halley.UUCP (Joann Zimmerman):
>> One other very noticeable difference between other engineering fields and
>> computing is in the amount of failure analysis to be found in the field. 
>> How would we go about developing this into a real engineering discipline?
>Why not follow the leaders?  Do what the real engineers do.

Yes! Go buy a $1M software tester, hire a team of programmers to generate test
patterns, another team to program the tester to run the patterns, another
team to build a simulator to generate simulated output to compare to the
tester output, another team to take your specs and generate code, another
team to take your specs and emulate the machine to compare to the output from
the simulator to see that is does the right thing (did we forget the team to
write down what the right thing is?). But wait a minute wasn't this what 4GL
was going to free us from? 
Engineers deal with systems that have a finite (possibly large) number of states
so they can actually test or at least simulate all of them. If they can't then
they cheat and make generalizations. Example: to test the load bearing limits
on a bridge build a model and start with a lot of weight and keep adding big
chunks of weight until it breaks then divide that by 2 (or 4, some fudge factor)
and call that the limit. They don't have to get the exact limit just a safe one.
So how do you apply that to software? Tell your boss "This foo works for all
files less than 10Mb in size?" Your boss tells you "Make it work for all
files - software isn't bridge-building."
But look at a simple subroutine with, say, 4 32bit inputs. How many states?
2^128. How do you test them all or whittle that down automatically without a
program that understands programs?
It's got to be pretty smart and understand what can happen if you call a
subroutine or if there are any possible side-effects.
And for a reasonable project, you can have, what? hundreds of these subroutines?
Thousands?
If you have a program that understands programs then you should be able to
synthesize the code from the spec and you can forget testing. You just need
to verify the spec. Now we're back to 4GL. Where the heck is it?

The only thing I think we can get from engineers is the same thing that the
Structured Methodology people have been saying for years - design it right
from the top down and then code to the design. Then get someone to check
both these things. Have a test methodology and stick to it. Do regression
testing on any changes. Document everything, always.
Still, $1M chunks of otherwise useless hardware and hordes of expensive
Computer Aided Software Developement types bowing and scrapping all over
the place is an appealing thought. :-)
-- 
Gary Bridgewater, Data General Corp., Sunnyvale Ca.
gary@sv4.ceo.sv.dg.com or 
{amdahl,aeras,amdcad,mas1,matra3}!dgcad.SV.DG.COM!gary
No good deed goes unpunished.