<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
hi Steve,
<div><br>
<div> I believe you, but there is not enough public information to determine the spread, the common case, the mean, the mode, etc. for a range of </div>
<div><br>
</div>
<div> projects across a industry type, nor the issues raised later that can be tied back to processes not followed or new processes needed. </div>
<div><br>
</div>
<div> I don’t have enough clues to explain why my experience with scaling was bad and yours good.</div>
<div><br>
</div>
<div>bob s<br id="lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On Feb 24, 2025, at 3:06 PM, Steve Tockey <steve.tockey@construx.com> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div><br>
</div>
<div>Robert,</div>
<div>I don’t agree that all processes cannot be scaled from small to large projects. I would say that this depends entirely on the process in question. Some processes actually scale quite well. Case in point, I have a process that was used in development of
the Mission Systems for the P-8 Poseidon (<a href="https://en.wikipedia.org/wiki/Boeing_P-8_Poseidon">https://en.wikipedia.org/wiki/Boeing_P-8_Poseidon</a>) which involved about 350 developers building around 7 million lines of code over a 7 year project where
that same basic process works fine on single developer, few weeks, under 5000 lines of code projects.</div>
<div><br>
</div>
<div><br>
</div>
<div>— steve</div>
<div><br>
</div>
<br id="lineBreakAtBeginningOfMessage">
<div><br>
<div>On Feb 24, 2025, at 7:38 AM, Robert P Schaefer <rps@mit.edu> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div>Hi, Peter,<br>
<br>
short comment, processes that are viable on small projects do not (and I believe cannot) scale to large projects<br>
<br>
longer explanation:<br>
<br>
in my experience (26 years but ended 15 years ago in the defense industry - and much happier now)
<br>
<br>
The processes that work for small programs do not scale to large developments for various reasons<br>
<br>
including for the firm that is responsible for the processes as prime contractor, gets overwhelmed,
<br>
<br>
by factors that cannot be controlled including: large requirement sets that contain latent<br>
<br>
contradictions (through chains of dependencies) that aren’t discovered until after requirements are signed off, <br>
<br>
not enough engineers to keep track of 1000s of requirements from concept to execution<br>
<br>
that are allocated distant in time (from concept to execution) from where they are defined,<br>
<br>
implicit information lost when the developers in one phase are re-assigned after that phase completes, <br>
<br>
funding for testing (in the future) that is reassigned to earlier phases that go long in the present,<br>
<br>
as previously mentioned when overwhelmed by lists of faults, faults that are regraded as not-faults,<br>
<br>
and (what really opened my eyes to the high level bs going on) adversarial subcontractors who want to be prime in the next go-round.<br>
<br>
bob s<br>
<br>
<blockquote type="cite">On Feb 24, 2025, at 9:53 AM, Prof. Dr. Peter Bernard Ladkin <ladkin@causalis.com> wrote:<br>
<br>
On 2025-02-24 14:54 , Robert P Schaefer wrote:<br>
<blockquote type="cite">I hear you, i have no answers.<br>
</blockquote>
<br>
I do.<br>
<br>
Back when CapGemini, formerly Altran UK, was still called Praxis, they regularly estimated the achieved reliability of delivered products (and still did for iFACTS when they were Altran, a decade ago. Probably still do.) There is a very public project called
Tokeneer, undertaken with the NSA, where the attempt was made to develop a bug-free small (10K LoC, as I remember) biomeasurement system for access control. They almost succeeded (I recall Rod Chapman saying that two bugs were belatedly discovered).<br>
<br>
There are lots of ways, increasingly accessible, in which objective properties of code and its documentation can be rigorously established. You of course need the right kind of tools, right choice of programming language, right compiler, and so on.<br>
<br>
<br>
On Feb 24, 2025, at 8:47 AM, Derek M Jones <derek@knosof.co.uk> wrote:<br>
<br>
<blockquote type="cite"><br>
In systems safety there is the belief that following a process<br>
will lead to reliable code. And the evidence for this is?<br>
</blockquote>
<br>
In system safety there is the standard IEC 61508-3 which says formal methods are highly recommended for high-reliability requirements. It (rather, the definition of "formal methods" in IEC 61508-4 NextEd) refers to IEC 61508-3-2 which describes methods for
establishing objective properties of documentation and code. There are four steps in this "waterfall", namely requirements, design, source code, and object code, and the key relation of "fulfils".<br>
<br>
The evidence for this approach succeeding lies in, for example, the entire project histories of Praxis/Praxis HIS/Altran UK/CapGemini.<br>
<br>
It astonishes me that there are still people who claim some kind of software expertise who deny the efficacy of all this.<br>
<br>
And of course it is not the only example. Modern civil aerospace is full of very-highly-reliable software-based kit, developed according to evolutionary company practices following DO-178C and DO-333 (or EUROCAE ED-12C and ED-216). Evidence, again, in the operational
histories of all this kit.<br>
<br>
PBL<br>
<br>
Prof. Dr. Peter Bernard Ladkin<br>
Causalis Limited/Causalis IngenieurGmbH, Bielefeld, Germany<br>
Tel: +49 (0)521 3 29 31 00<br>
<br>
_______________________________________________<br>
The System Safety Mailing List<br>
systemsafety@TechFak.Uni-Bielefeld.DE<br>
Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety<br>
</blockquote>
<br>
_______________________________________________<br>
The System Safety Mailing List<br>
systemsafety@TechFak.Uni-Bielefeld.DE<br>
Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety</div>
</div>
</div>
<br>
</div>
_______________________________________________<br>
The System Safety Mailing List<br>
systemsafety@TechFak.Uni-Bielefeld.DE<br>
Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety</div>
</blockquote>
</div>
<br>
</div>
</div>
</body>
</html>