From: A.J.C.Blyth@newcastle.ac.uk (Andrew J C Blyth)
Newsgroups: comp.software-eng
Subject: Re: What is Software Engineering
Date: 19 Aug 92 18:48:16 GMT
Organization: University of Newcastle Upon Tyne

In article <1992Aug6.130619.21016@widget!uunet.uu.net>, brandon@widget!uunet.uu.net (Brandon) writes:
> 
> I agree with your 4th definition (that Software Engineering is a complete
> engineering discipline that provides rules, guidelines, etc based on 
> proven techniques and sound theories.  I also feel that Software Engineering 
> NEEDS to be recognized as a true engineering field or else the cost of
> business as usual (always the bottom line) will continue to damage the software
> field.  However,  I see some hurdles to overcome:

There have been disgussions before on this news group about what is 
software emgineering and these discussions generally as a rule come
down to what is ment by the term engineer. 

Now I have no problems with people calling them selves software engineers.
And yes I agree that there are certain engineering pronciples that 
software engineers can use when attempting to solve problems in software.
However you have to be carful about how the term engineer in applied.
As has been stated before on this newsgroup engineering disaplines such
as civil engineering draw upon the physical sciences to give the mean.
For example we can talk about the physical properties of a bridge, the
question as to where or not we can talk about the physical properties
of a piece of software remain unansered. It is because of this unanswered
question that I do not that that you can say that Software Engineering is 
a complete engineering discipline.

In 1987 Kalle Lyytinen published a paper called "Different Perspectives on
Information Systems: Problems and Solutions". This paper appeared in ACM
computing surveys Vol.19 No.1 March. In this paper he outlines three types 
of process models that a software engineer could use to solve a problem.
The first type is the engineering model, this model works best on technical
system. The second model is the learning model and this works best on 
soical system. Finally, the final process model is the dialogue process
model, again this works best on a soical systems. 

By stateing that software engineering is a total engineering disapline
you are forceing engineering priciples and practices to be applied to
soical problem. The evidence of where people have failed to deliver
software solutions to soical problems would seem to surgest that using
and pure (hard) engineering option to understand and solve what are
in essence soical problems does not work.

> 	1)  A majority of persons developing software are still using ad-hoc
> techniques and I think this reduces the entire software community.  In Electrical
>  Engineering it is unlikely that someone without extensive training could go out and 
> begin designing and building chips (especially ones that people base their life
> and livelyhood on).  In software this situation is far too common.   

This situation is changeing as sofware engineers are being held accountable by
law for the software that they write. In addition companies are impossing 
firm rules about who pays for what if the software does not work. The day is
comeing when Software Engineers will have to carry insurance and have professional
status similar to the Doctors in the US today.
 
> 	2)  If Software Engineering is recognized as a true engineering than the 
> responsibility of those claiming to be SE's will be enforcable.  For example, it 
> will be much easy to prove gross negligence on someone claiming to be an SE if they
> failed to follow accepted standards (such as IEEE testing guidelines) when a mishap
> occurs.    

I do not think that by using your approach you will solve the software crisis, the
problems that gave rise to it will still be there unsolved.
 
> The solutions to these problems (training, managerial support and enforcement,
> etc) are easy to say (lip service) but a LOT harder for large organizations to
> actually change.  

On the above point I totally agree with you. Large organizations have to want to
change and inorder for them to do so they will require clear payback after a
specific time. 


Andrew.