Software's evil

Rene wrote:

> "Lanarcam" <lanarcam1@yahoo.fr> schreef in bericht
> news:47eba670$0$8361$426a74cc@news.free.fr...
>> Rene wrote :
>>>
>>> You are right about that, though it will only be possible to get a
>>> 100% garantuee if You can manage to simulate every possible state in
>>> which something can be and that may be possible with some simple
>>> combinatorial logic circuit but will very rapidly become impossible
>>> if Your design becomes more complex. And only testing managable units
>>> is not always good enough either. Suppose one of them has an error
>>> which does not show up if You examine it because it only alters some
>>> bit somewhere else in memory (and all "replies" You get from Your
>>> unit when testing it are what You expect them to be). However, when
>>> You run the system as a whole, that bit might be a part of a variable
>>> in another managable unit which turned out to be OK as well when You
>>> tested it isolated. So You will have to test the units separately and
>>> together and creating every possible state that Your system might
>>> ever stumble upon, that is impossible.
>>
>> This is indeed impossible to manage unless you find a way to
>> fully test "manageable units" and make sure that they are free
>> of side effects. Needless to say I don't have the solution.
> 
> If anyone would have the solution, he or she would probably win the
> Nobel Prize. You should think about the proportions of the things we
> are talking about. Imagine You have some program that accepts a string
> of up to 50 characters (and these are lower case letters (26 of them),
> upper case letters (26 of them) and numbers (10 of them), not to
> mention other possible characters which I will forget for now. If You
> want to fully test that program, You would have to offer it
> (26+26+10)^50=an incredibly huge number
> of strings. But apart from that, You will  have to offer it strings
> that are too big, to check if the program will handle those in an OK
> fashion.

That is 4.165 E+89 combinations plus the error checking limit tests
(another two orders of magnitude perhaps). Sounds quite formidable.
However, such a routine should be made up of smaller tested components
which have each undergone thorough testing.

> Off course You can check the source if it somehow does input checking
> but to be absolutely sure (what if the compiler has an error?) You
> would have to perform that test.

My methods include static code inspections (including comparison with the
requirements specification), functional performance checking and limits
error checking. It starts with the smallest component (very thoroughly
detailed) through to the upper levels of the application (more
concentration on identified limiting conditions). Of course, the
compilers I use are quite simple, thoroughly tested and validated from
source to the machine code that is laid down. 

Of course, none of the above gets done in any sort of a hurry. Such
thorough testing has to be planned properly and any methods utilised
need to be validated as appropriate and adequate.

-- 
********************************************************************
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..
********************************************************************

Ed Prochak wrote:

> 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.

I remember several Apollo program disasters (not all software related).
Yes I am ancient enough for that. NASA did a significant amount of final
testing on Live TV in those days.
 
> 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.  

Yes, Static Code Inspections, especially when you can also compare with
the requirements specification, will eliminate the majority of the
coding errors (and even some of those errors that other tools will not
discover).

> 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.)

I would suggest that the one man outfit had better have some form of
process in place which he employs to ensure the quality of his product.
As one who has operated as a one man band at times I used to hire people
to just walk through the code inspections with me. Countless silly
errors were eliminated that way.

> 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.

Schedules need to be estimated with a range of likely-hoods and properly
managed in their publication to management. Steve McConnell's
book "Software Estimation - Demystifying the Black Art" is an
interesting read on the topic. I now realise why I like the PERT
planning methods (and diagramming) so much.

The main message in this thread has been (I think) that having a decent
documented and implemented development process matters. Ensuring that
the process is truly followed is paramount. Inspections and Reviews are
worthwhile activities that will improve the overall bottom line for the
accountants even though they may seem intensive and expensive at the
time. And finally, short cuts cost more money in the long run.

-- 
********************************************************************
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..
********************************************************************

Eric Smith wrote:

>>>Ed Prochak wrote:
>>>> Another is to use a sane language, such as Ada.

> CBFalconer wrote:
>>> Another is to use a sane language, such as Ada.
> 
> larwe wrote:
>> WOW! Now, that's something you don't hear every day.

That is probably because they still haven't got the message that the
choice of language has very little to do with the final product
integrity. The Development Process and its proper management is a much
more important factor, along with rigorous code inspection and design
reviews. 

-- 
********************************************************************
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..
********************************************************************

Chris H wrote:
> In message <6596evF2dmo8tU1@mid.individual.net>, Paul E. Bennett 
> <Paul_E.Bennett@topmail.co.uk> writes
>>
>>> CBFalconer wrote:
>>>
>>>>> Another is to use a sane language, such as Ada.
>>>
>>> larwe wrote:
>>>
>>>> WOW! Now, that's something you don't hear every day.
>>
>> That is probably because they still haven't got the message that the
>> choice of language has very little to do with the final product
>> integrity. The Development Process and its proper management is a much
>> more important factor, along with rigorous code inspection and design
>> reviews.
> 
> That has been shown repeatedly  in studies of safety critical projects

Can you give some specific references? I would like to read such 
studies, because my intuition and experience say otherwise. There 
is also evidence for the importance of language, for example in a 
post on c.a.e. by John R. Strohm (12/17/2003) that is part of a 
thread at 
http://www.embeddedrelated.com/usenet/embedded/show/23613-2.php.

Quoting from Strohm:

> Pratt & Whitney accidentally did an internal study,
> over the course of several years, on jet engine controllers.
> They were using roughly equivalent teams, and the tasks to
> be accomplished were about the same.  The commercial side
> of the house was using whatever they wanted to use; the
> military side of the house was required to use Ada.  They 
> kept metrics from all of the projects.  The metrics guy crunched
> the numbers, and discovered that the Ada projects were getting
> something like twice the programmer productivity, across the
> board, and 1/4 the defect density, across the board, compared
> with the commercial side of the house.
>
> The commercial side of Pratt & Whitney now uses Ada for engine
> controllers.

Chris H wrote:
> In the safety critical systems club journal there as an article saying 
> that the choice of language was irrelevant as process was correct.

Same question as above: reference?

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

In message <6596evF2dmo8tU1@mid.individual.net>, Paul E. Bennett 
<Paul_E.Bennett@topmail.co.uk> writes
>Eric Smith wrote:
>
>>>>Ed Prochak wrote:
>>>>> Another is to use a sane language, such as Ada.
>
>> CBFalconer wrote:
>>>> Another is to use a sane language, such as Ada.
>>
>> larwe wrote:
>>> WOW! Now, that's something you don't hear every day.
>
>That is probably because they still haven't got the message that the
>choice of language has very little to do with the final product
>integrity. The Development Process and its proper management is a much
>more important factor, along with rigorous code inspection and design
>reviews.
>

That has been shown repeatedly  in studies of safety critical projects

Proper process is required and requirements... I suggested this on the 
accu mail list and gout laughed out of caught... apparently none of 
their members bother with requirements specs and most say they have 
never done a flow chart! Or much documentation!

In the safety critical systems club journal there as an article saying 
that the choice of language was irrelevant as process was correct.

Incidentally it is easy to have a type safe C... you just run PC-lint 
with the strong typing enabled.  Lint is a much a part of the C language 
as the compiler which is why lint was invented whilst C was still being 
stabilised (before K&R1)

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

On Mar 30, 7:51 am, Chris H <ch...@phaedsys.org> wrote:

> their members bother with requirements specs and most say they have
> never done a flow chart! Or much documentation!

I can beat that - did you know that flowcharting is no longer taught
as part of an embedded engineering degree in many tertiary
institutions here?

Basic UML data relationship modeling is taught (in a
brandy^H^H^H^H^H^HJava sauce); that's about it.

Chris H wrote:
> 
... snip ...
> 
> Incidentally it is easy to have a type safe C... you just run
> PC-lint with the strong typing enabled.  Lint is a much a part of
> the C language as the compiler which is why lint was invented
> whilst C was still being stabilised (before K&R1)

Not so.  Nothing gives you integer sub-ranges, or checks array
access when the mechanism is a pure pointer, for example.  These
dynamic runtime checks are not feasible in C.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.



-- 
Posted via a free Usenet account from http://www.teranews.com

CBFalconer wrote:
> Another is to use a sane language, such as Ada.

Ada is a boring language, because it provides so few
opportunities to show off. And this is only slightly
tongue in cheek: a C++ guru can write code that a novice
would struggle to understand. It would be much more difficult
to do that in Ada.

One of the best experiences I have ever had with a compiler
was an Ada compiler back in the 80's, which gave me a warning
that basically said: "I compiled your program because you asked,
but if you ever try to run it, it will raise constraint_error
on line X. To see why it would do that, see the language reference
manual, section Y.Z."
-- 
Pertti

On Mar 30, 6:51 am, Chris H <ch...@phaedsys.org> wrote:
> In message <6596evF2dmo8...@mid.individual.net>, Paul E. Bennett
> <Paul_E.Benn...@topmail.co.uk> writes
>
>
>
> >Eric Smith wrote:
>
> >>>>Ed Prochak wrote:
> >>>>> Another is to use a sane language, such as Ada.
>
> >> CBFalconer wrote:
> >>>> Another is to use a sane language, such as Ada.
>
> >> larwe wrote:
> >>> WOW! Now, that's something you don't hear every day.
>
> >That is probably because they still haven't got the message that the
> >choice of language has very little to do with the final product
> >integrity. The Development Process and its proper management is a much
> >more important factor, along with rigorous code inspection and design
> >reviews.
>
> That has been shown repeatedly  in studies of safety critical projects
>
> Proper process is required and requirements... I suggested this on the
> accu mail list and gout laughed out of caught... apparently none of
> their members bother with requirements specs and most say they have
> never done a flow chart! Or much documentation!
>
> In the safety critical systems club journal there as an article saying
> that the choice of language was irrelevant as process was correct.
>

But the measurement was limited to correctness of final product,
right?

I would agree that a good process can produce the same result with
either ADA or some "unsafe" language like C or assembler. But I would
bet dollars to donuts that the ADA team will complete the work faster,
with fewer repeat inspections per module, and with fewer modules (not
counting those provided by the language). Why? because programmer
productivity has been shown to be fairly constant in debugged lines
per day. Given that, any language that is closer to the problem domain
will result in shorter development time.

Otherwise, I cannot believe language choice is "irrelevant", even in a
strong development process environment.

Ed

Ed Prochak wrote:

[%X]

> I would agree that a good process can produce the same result with
> either ADA or some "unsafe" language like C or assembler. But I would
> bet dollars to donuts that the ADA team will complete the work faster,
> with fewer repeat inspections per module, and with fewer modules (not
> counting those provided by the language). Why? because programmer
> productivity has been shown to be fairly constant in debugged lines
> per day. Given that, any language that is closer to the problem domain
> will result in shorter development time.
> 
> Otherwise, I cannot believe language choice is "irrelevant", even in a
> strong development process environment.

Language is irrelevant to the final quality and integrity of the product
which depends more on the quality and integrity of the development
process. 

There may be productivity differences between languages but to determine
what they are may require some carefully formulated comparison
experiments to determine. Counting Function Points over a range of
projects using different languages might get some sort of feel for
language choice and productivity.

-- 
********************************************************************
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..
********************************************************************