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.