Software's evil

<posted & mailed>

Paul E. Bennett wrote:

> Not Really Me wrote:
> 
>> My thought is that the first step is to improve the specification
>> process. When was the last time you got a software specification that
>> was actually complete and didn't require revisions?
> 
> I have seen both ends of the specification problem.
> 
> At the scant end, a specification that left it to the engineer (me) to
> extract by extensive Q&A exactly what was wanted.
> 
> At the enormously complete specification end, it was so complete that
> all the referenced standards and legislature managed to contradict each
> other so much that a working solution was impossible to achieve. This
> specification was reduced from a 900 page document to a mere 35 pages
> of specification that was entirely adequate following a short Q&A with
> the client.
> 
> You are right, though, in recognising that starting off with a decent
> specification that has had conflicting requirements resolved, is
> logically correct and consistent and well structured, will help the
> progress of a project. Doing more of the thinking (Systems Engineering)
> work up front saves an enormous amount of time in integration, testing
> and maintenance.

...and to finish what I was saying.

Decomposing the requirements specification to the point where
recognisable components start to emerge is one of those Systems
Engineering tasks that can be helped by the right sort of tools. Tool
selection is important whatever the project.

Also important is ensuring that a rigorously applied process is in place
where requirements tracked and protected as they are turned into
suitably engineered components and thus a suitably engineered system at
the end of it. The process should also aid in the provision of an audit
trail so that how the process has been managed is very evident
throughout the project development lifetime. With some projects the
process should continue for the full lifecycle of the project.

If that sounds arduous and far removed from the practices you are
currently employing, then you will not be engineering your product.

-- 
********************************************************************
Paul E. Bennett...............<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

Lanarcam <lanarcam1@yahoo.fr> writes:
> A microcontroller is a complex design and generally without bugs.

Huh?  I can't even remember the last time I used a microcontroller
that had no errata.

"Lanarcam" <lanarcam1@yahoo.fr> writes:
> If that is the case, the problem of software doesn't lie in
> the instrinsic properties of software components but
> in the development process.

It's all a matter of complexity.  If you have simple hardware and
complex software, you'll have more schedule slips and bugs in the
software than in the hardware.  But when the hardware becomes as
complex as the software, it will have the same sorts of problems.

I've known several engineering managers that thought that if they
pushed more of the system functionality into the hardware, it would
somehow result in a more reliable product developed in a shorter
time.

Eric Smith wrote:
> "Lanarcam" <lanarcam1@yahoo.fr> writes:
>> If that is the case, the problem of software doesn't lie in
>> the instrinsic properties of software components but
>> in the development process.
> 
> It's all a matter of complexity.  If you have simple hardware and
> complex software, you'll have more schedule slips and bugs in the
> software than in the hardware.  But when the hardware becomes as
> complex as the software, it will have the same sorts of problems.

It depends also on the organisation or on the culture of the company.
Mine is a hardware company and everyone is involved at some
stage in the hardware development process, from design to
procurement, tests, maintenance, etc. For the software, on the
contrary, almost no one is involved apart from the software
developers. Of course it's always the software's fault when
something goes wrong...

> I've known several engineering managers that thought that if they
> pushed more of the system functionality into the hardware, it would
> somehow result in a more reliable product developed in a shorter
> time.

On Mar 27, 9:25=A0pm, CBFalconer wrote:
> larwe wrote:
> > Remember the de Havilland Comet? Remember how difficult it was to get
> > people to board them even once the bugs were fixed?
>
> However they are still flying, I believe (or were very recently).
> They just don't do passenger traffic; they became cargo devices.
> Their eventual record was very good.

The military variant, Nimrod, is still in use and is expected to be
until at least 2020 which would be more than 70 years after the first
Comet flight.

Paul

Op Thu, 27 Mar 2008 15:22:34 +0100 schreef Vladimir Vassilevsky  
<antispam_bogus@hotmail.com>:
> Pertti Kellom&#4294967295;ki wrote:
>
>> But the properties one really wants to
>> verify are much more abstract, such as "does this piece of software
>> land my plane safely?".
>
> It is enough if this piece of software lands the plane safely in 99.999%  
> of cases. There is no point for the further improvement if the insurance  
> premiums and the other possible losses are already lower then the cost  
> of the development and testing.

"A new car built by my company leaves somewhere traveling at 60 mph. The  
rear differential locks up. The car crashes and burns with everyone  
trapped inside. Now, should we initiate a recall? Take the number of  
vehicles in the field, A, multiply by the probable rate of failure, B,  
multiply by the average out-of-court settlement, C. A times B times C  
equals X. If X is less than the cost of a recall, we don't do one."

Fight Club (1999), a very educational movie.


-- 
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/

Lanarcam wrote:

> It depends also on the organisation or on the culture of the
> company.  Mine is a hardware company and everyone is involved at
> some stage in the hardware development process, from design to
> procurement, tests, maintenance, etc. For the software, on the
> contrary, almost no one is involved apart from the software
> developers. Of course it's always the software's fault when
> something goes wrong...

I do the hardware and software and find it's always Microsoft's fault
when something goes wrong. Even on a small uC based project. :D

-- 
-Mike

In message <op.t8pxn1gyy6p7a2@azrael.lan>, Boudewijn Dijkstra 
<boudewijn@indes.com> writes
>Op Thu, 27 Mar 2008 15:22:34 +0100 schreef Vladimir Vassilevsky 
><antispam_bogus@hotmail.com>:
>> Pertti Kellom&#4294967295;ki wrote:
>>
>>> But the properties one really wants to
>>> verify are much more abstract, such as "does this piece of software
>>> land my plane safely?".
>>
>> It is enough if this piece of software lands the plane safely in 
>>99.999%   of cases. There is no point for the further improvement if 
>>the insurance   premiums and the other possible losses are already 
>>lower then the cost   of the development and testing.
>
>"A new car built by my company leaves somewhere traveling at 60 mph. 
>The  rear differential locks up. The car crashes and burns with 
>everyone  trapped inside. Now, should we initiate a recall? Take the 
>number of  vehicles in the field, A, multiply by the probable rate of 
>failure, B,  multiply by the average out-of-court settlement, C. A 
>times B times C  equals X. If X is less than the cost of a recall, we 
>don't do one."
>
>Fight Club (1999), a very educational movie.

One of the most subversive movies ever. However as I discovered when I 
saw it at the cinema and listened to the comments of some on the way 
out: those who could/should have used it as the starting point of the 
revolution did not understand it.


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On Mar 27, 10:38 am, Lanarcam <lanarc...@yahoo.fr> wrote:
> Ed Prochak wrote :
>
>
> I tend to agree with all of that, but somehow, they managed to
> build a "complex" rocket in 1969 which involved communications
> among many teams and at a time when tools were scarce.
> Applying systems building techniques would certainly help.

One thing that helped: they were dealing with the laws of physics
which are pretty stable and well defined. (Heck in 1969 they did most
of the calculations on slide rules!)  Today's systems have a big issue
just dealing with the user interface. And keep in mind the Apollo
program did not go flawlessly.

NASA got very good at software development (and systems development),
but at a high cost.
The developers were HIGHLY motivated. Any mistake could kill
astronauts in possibly spectacular ways, and did! Compare that to
failure in a parking garage gating system.

There are things they do that should be done in our development. One
that I prefer and suggest is using a review technique called
Inspections. Code reviews come in several varieties but Inspections
can be the most thorough and helpful IMHO.  has your company
considered review of its processes according to CMM (the Capability
Maturity Model)? The scale goes from 1 to 5. NASA was the first (and
for a long time the only) level 5. Most companies are level 1: AD HOC.
IOW they have no real formal development process. Some companies may
not need a formal process. (The one man company that makes parking
garage gating systems for example.)

So if you want to improve the development process at your company, you
can. But note that even a CMM level 5 organization can fail under
pressures of schedule and budget.

   Ed

"Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> wrote in message 
news:652nffF2eeuqeU1@mid.individual.net...
> <posted & mailed>
>
> Paul E. Bennett wrote:
>
>> Not Really Me wrote:
>>
>>> My thought is that the first step is to improve the specification
>>> process. When was the last time you got a software specification that
>>> was actually complete and didn't require revisions?
>>
>> I have seen both ends of the specification problem.
>>
>> At the scant end, a specification that left it to the engineer (me) to
>> extract by extensive Q&A exactly what was wanted.
>>
>> At the enormously complete specification end, it was so complete that
>> all the referenced standards and legislature managed to contradict each
>> other so much that a working solution was impossible to achieve. This
>> specification was reduced from a 900 page document to a mere 35 pages
>> of specification that was entirely adequate following a short Q&A with
>> the client.
>>
>> You are right, though, in recognising that starting off with a decent
>> specification that has had conflicting requirements resolved, is
>> logically correct and consistent and well structured, will help the
>> progress of a project. Doing more of the thinking (Systems Engineering)
>> work up front saves an enormous amount of time in integration, testing
>> and maintenance.
>
> ...and to finish what I was saying.
>
> Decomposing the requirements specification to the point where
> recognisable components start to emerge is one of those Systems
> Engineering tasks that can be helped by the right sort of tools. Tool
> selection is important whatever the project.
>
> Also important is ensuring that a rigorously applied process is in place
> where requirements tracked and protected as they are turned into
> suitably engineered components and thus a suitably engineered system at
> the end of it. The process should also aid in the provision of an audit
> trail so that how the process has been managed is very evident
> throughout the project development lifetime. With some projects the
> process should continue for the full lifecycle of the project.
>
> If that sounds arduous and far removed from the practices you are
> currently employing, then you will not be engineering your product.
>
> -- 
> ********************************************************************
> Paul E. Bennett...............<email://Paul_E.Bennett@topmail.co.uk>
> Forth based HIDECS Consultancy
> Mob: +44 (0)7811-639972
> Tel: +44 (0)1235-811095
> Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
> ********************************************************************

I agree completely.  Our work is primarily safety-critical.  For us, the 
proof is in the process.

Scott