[SystemSafety] The "Real world" [was: Qualifying SW as "proven in use"]

RICQUE Bertrand (SAGEM DEFENSE SECURITE) bertrand.ricque at sagem.com
Wed Jul 3 10:34:24 CEST 2013


Yes I agree. But there is a common complaency to believe in fairy tales and to hope that the cup of coffee will be 2 € instead of 4 as it has been told...

Bertrand RICQUE
Program Manager, Optronics and Defense Division
 
T +33 (0)1 58 11 96 82
M +33 (0)6 87 47 84 64
23 avenue Carnot 
91300 MASSY - FRANCE 
http://www.sagem-ds.com

 


-----Original Message-----
From: Steve Tockey [mailto:Steve.Tockey at construx.com] 
Sent: Tuesday, July 02, 2013 6:54 PM
To: RICQUE Bertrand (SAGEM DEFENSE SECURITE); systemsafety at techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] The "Real world" [was: Qualifying SW as "proven in use"]


Bertrand,
Please ask that manager if he is happy paying between 3x and 200x as much
for the same thing because that's what's happening. If a normal cup of
coffee costs 4 Euro, would he be willing to pay between 12 and 800 Euro
for that same cup? If he's already paying 1.50 Euro for a litre of petrol,
then is he also willing to pay between 4.50 and 350 Euro for that same
litre?

Credible research on real software projects has revealed that the cost
increase to fix a defect later rather than sooner is at least a factor of
3. Other research has shown growth rates of 200 times or more. One study
cited a factor of up to 1000x. In case anyone is looking for references,
here are a few:

Fagan, Michael E. 1976. ³Design and Code Inspections to Reduce Errors in
Program Development.² IBM Systems Journal 15, no. 3: 182­211

Humphrey, Watts S., Terry R. Snyder, and Ronald R. Willis. 1991. ³Software
Process Improvement at Hughes Aircraft.² IEEE Software 8, no. 4 (July):
11­23

Leffingwell, Dean, 1997. ³Calculating the Return on Investment from More
Effective Requirements Management,² American Programmer, 10(4):13-16

Willis, Ron R., et al, 1998. ³Hughes Aircraft¹s Widespread Deployment of a
Continuously Improving Software Process,² Software Engineering
Institute/Carnegie Mellon University, CMU/SEI-98-TR-006, May 1998

Grady, Robert B. 1999. ³An Economic Release Decision Model: Insights into
Software Project Management.² In Proceedings of the Applications of
Software Measurement Conference, 227-239. Orange Park, FL: Software
Quality Engineering

Shull, et al, 2002. ³What We Have Learned About Fighting Defects,²
Proceedings, Metrics 2002. IEEE; pp. 249-258

Boehm, Barry and Richard Turner, 2004. Balancing Agility and Discipline: A
Guide for the Perplexed, Boston, Mass.: Addison Wesley, 2004


And keep in mind that the accounting system used is only counting the
costs measured within the development organization. The consequential
costs to the user's organization--in terms of down time, lost data,
etc.--aren't included, meaning that the true cost has to be even higher.

I will send you(in a separate email) the paper I offered yesterday because
it will allow you to prove to that manager that he is paying a lot more
for the same thing than he should.


Regards,

-- steve



-----Original Message-----
From: "RICQUE Bertrand   (SAGEM DEFENSE SECURITE)"
<bertrand.ricque at sagem.com>
Date: Tuesday, July 2, 2013 5:38 AM
To: "systemsafety at techfak.uni-bielefeld.de"
<systemsafety at techfak.uni-bielefeld.de>
Subject: Re: [SystemSafety] The "Real world" [was: Qualifying SW as
"proven in use"]

I have been during two years operation manager, and thus number 2 of a
company and when I have tried to convince my CEO to stop splilling money
while fixing software problems nights and days during plant start-up, he
told me: why should we spend money upstream ? We allways did it like that
? If there are bugs it is because your project managers have a problem
managing their engineers...

Bertrand RICQUE
Program Manager, Optronics and Defense Division
 
T +33 (0)1 58 11 96 82
M +33 (0)6 87 47 84 64
23 avenue Carnot 
91300 MASSY - FRANCE
http://www.sagem-ds.com

 


-----Original Message-----
From: Steve Tockey [mailto:Steve.Tockey at construx.com]
Sent: Monday, July 01, 2013 7:00 PM
To: RICQUE Bertrand (SAGEM DEFENSE SECURITE);
systemsafety at techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] The "Real world" [was: Qualifying SW as
"proven in use"]


Bertrand,
The silliest thing in all of this is that the stakeholders are clearly
clueless about the true source of cost in their software projects. We've
actually measured the degree of rework (fixing things that were done
incorrectly earlier, simply, waste) in software organizations to be over
50%. I've got a technical paper on the topic, if anyone wants. I don't
believe I can include attachments on this list, so if anyone wants just
email me direct and I'll sent it back as a PDF attachment.

The root issue here is that corporate accounting systems lie. They are
*cost* accounting systems, not *value* accounting systems. They are great
for measuring how much money was spent, but they fail miserably at
measuring how much money was saved.

The corporate accounting systems will surely measure the cost of doing
everything we're talking about on the list recently. But tell me where the
accounting system measures how much was saved because we did it a better
way? It doesn't. It can't. So the key problem underneath all of this is an
inability for the stakeholders to really see and appreciate the economic
impacts of what's being discussed here. I'm convinced that if they had a
clue of the value of doing things better, they'd demand that it be done
that way.


-- steve



-----Original Message-----
From: "RICQUE Bertrand   (SAGEM DEFENSE SECURITE)"
<bertrand.ricque at sagem.com>
Date: Monday, July 1, 2013 2:05 AM
To: "systemsafety at techfak.uni-bielefeld.de"
<systemsafety at techfak.uni-bielefeld.de>
Subject: Re: [SystemSafety] The "Real world" [was: Qualifying SW as
"proven in	use"]

I agree and I am afraid that we are just requested to stop bothering
stakeholders by raising issues understood as costs.

Bertrand RICQUE
Program Manager, Optronics and Defense Division
 
T +33 (0)1 58 11 96 82
M +33 (0)6 87 47 84 64
23 avenue Carnot 
91300 MASSY - FRANCE
http://www.sagem-ds.com

 


-----Original Message-----
From: systemsafety-bounces at techfak.uni-bielefeld.de
[mailto:systemsafety-bounces at techfak.uni-bielefeld.de] On Behalf Of Martyn
Thomas
Sent: Monday, July 01, 2013 10:56 AM
Cc: systemsafety at techfak.uni-bielefeld.de
Subject: [SystemSafety] The "Real world" [was: Qualifying SW as "proven in
use"]

On 01/07/2013 01:01, Les Chambers wrote:
> I encourage the
> brains trust on this list to engage with the aggressive ugliness that is
>the
> real world and consider how we might deal with it.

I recall a lecture given by Dijkstra in 1973. A member of the audience
asked " do your methods work on real world problems?" Dijkstra paused,
and then said quietly "real world problems. Ah yes, those that remain
when you have failed to apply all the known solutions".

Over the years, I have heard many excuses for failures to use
professional engineering methods.

"if we train the programmers, they'll leave for a better paid job".
"we can't hire programmers who are willing to use that programming
language"
"universities don't teach (maths, project management, quality control,
planning, team working ... ...)"
"the customer insists that we use this (buggy) middleware for
compatibility"
"modern software isn't written - it's assembled from lots of (buggy) COTS"
"if we try to include that in the standard, industry will revolt."
"if we were to ask for that evidence, industry would charge us a fortune"

... and many many more.

Most software developers appear to have lost sight of the problem. Every
week, I hear someone use the verb "test" when what they mean is "gain
assurance that  ... is fit for purpose"; this reveals a dangerous,
implicit assumption that "test-and-fix" is the only practical way to
develop software. Most software is still written in languages without
good data structures and strong type-checking. Most software
requirements (and even interface specifications) are written in English
(or another natural language) - perhaps with some diagrams that lack any
rigorous semantics. Most projects have grossly inadequate change
control. I rarely see a risk register that is worth anything (except as
a demonstration that the project manager isn't managing the project).

Is there another trade that (a) builds complex, novel and critical
systems using poorly-qualified staff, (b) almost exclusively uses tools
that have major known defects, (c) builds systems from components of
unknown provenance that cannot be shown to be fit for purpose and (d)
nevertheless claims to be professional engineers?

Surely it is self-evident that the current state of our profession is
unsustainable. Let's stop making excuses and look for ways to accelerate
the changes that we know are needed.

(Which may be what Les was saying in the extract quoted above).

Martyn






_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE
#
" Ce courriel et les documents qui lui sont joints peuvent contenir des
informations confidentielles ou ayant un caractère privé. S'ils ne vous
sont pas destinés, nous vous signalons qu'il est strictement interdit de
les divulguer, de les reproduire ou d'en utiliser de quelque manière que
ce soit le contenu. Si ce message vous a été transmis par erreur, merci
d'en informer l'expéditeur et de supprimer immédiatement de votre système
informatique ce courriel ainsi que tous les documents qui y sont attachés."
******
" This e-mail and any attached documents may contain confidential or
proprietary information. If you are not the intended recipient, you are
notified that any dissemination, copying of this e-mail and any
attachments thereto or use of their contents by any means whatsoever is
strictly prohibited. If you have received this e-mail in error, please
advise the sender immediately and delete this e-mail and all attached
documents from your computer system."
#

_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE

#
" Ce courriel et les documents qui lui sont joints peuvent contenir des
informations confidentielles ou ayant un caractère privé. S'ils ne vous
sont pas destinés, nous vous signalons qu'il est strictement interdit de
les divulguer, de les reproduire ou d'en utiliser de quelque manière que
ce soit le contenu. Si ce message vous a été transmis par erreur, merci
d'en informer l'expéditeur et de supprimer immédiatement de votre système
informatique ce courriel ainsi que tous les documents qui y sont attachés."
******
" This e-mail and any attached documents may contain confidential or
proprietary information. If you are not the intended recipient, you are
notified that any dissemination, copying of this e-mail and any
attachments thereto or use of their contents by any means whatsoever is
strictly prohibited. If you have received this e-mail in error, please
advise the sender immediately and delete this e-mail and all attached
documents from your computer system."
#

_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE

#
" Ce courriel et les documents qui lui sont joints peuvent contenir des informations confidentielles ou ayant un caractère privé. S'ils ne vous sont pas destinés, nous vous signalons qu'il est strictement interdit de les divulguer, de les reproduire ou d'en utiliser de quelque manière que ce soit le contenu. Si ce message vous a été transmis par erreur, merci d'en informer l'expéditeur et de supprimer immédiatement de votre système informatique ce courriel ainsi que tous les documents qui y sont attachés."
******
" This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system."
#


More information about the systemsafety mailing list