Re: Software Engineering: Art or Science?

In article <[EMAIL PROTECTED]>
           [EMAIL PROTECTED] "Mark Borgerson" writes:

> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> > In these cases the software has not broken. It is still operating
> > within the requirements in place for which it was written. What you
> > cite is a case of requirements being exceeded or changing functionality.
> > I can't think of anything similar to metal fatigue or corrosion in software.
> > Not one bit of the code changes as a result of time or use. Software
> > does not wear out.
> > 
> 
> True,  but it is not uncommon for software to fail as the underlying
> OS changes.  How many old DOS apps,  particularly those directly
> accessing the hardware,  will still run properly under Win XP?

If you change the underlying OS you have just changed the requirements
of the application. The specification for software must include the
environment in which it is expected to run. Change the OS you need to
re-do validation and make new statements of performance under the
changed operational environment. To not do so is sheer negligence.

As to the costs of developing software in an appropriate engineering
manner, this is not that much greater than merely hacking code together.
Those who just hack code together without much by way of design are
going to spend an innordinate amount of time seeking out the bugs that
they will have introduced. They will have no idea how many bugs are
in their software and so will not know how many they need to eliminate.

A proper engineering process for software is not that complicated or
onerous to implement. It does not have to cost very much to apply and
there are benefits in minimising the testing that must be done (due
to what can be inferred about modules prior to final integration).
This latter may be seen to apply where there is a high level of re-use 
of software modules and a level of trust built up in the compiler tools
in use in a development team. Naturally, if you change the tools you 
need to revisit building the trust in those tools.

A hardware developer will have access to a component datasheet for
each component he designs into the product. There is absolutely no
reason for a software developer not to have access to similar levels
of documentation about every software component he uses. If you have 
none of this then you are really just guessing at your solutions.

In conclusion, if you are not following an engineering process to 
develop your software then you are not engineers. Those who are not
engineers should steer well clear of mission critical applications.

-- 
********************************************************************
Paul E. Bennett ....................<email://[EMAIL PROTECTED]>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************