[SystemSafety] A Fire Code for Software?

[Peter Bernard Ladkin]

On 2018-03-09 00:17 , Michael Jackson wrote:
> 
>> On 8 Mar 2018, at 19:00, Steve Tockey <Steve.Tockey at construx.com> wrote:
> ...
>> In this new movement, anyone who uses the term “software engineer” is required to:
>>
>> A) provide a reference to a definition of the term “engineer(ing)” that has been accepted by already-recognized engineers (e.g., Civil, Chemical, Mechanical, Industrial, . . .)
> 
> Surely the relevant analogous recognised engineers would be “physical engineers”. Of course, such engineers do not exist as a single profession, because they form the specialised branches in which their professional knowledge and skills have been developed. We will never deserve or gain the recognition we seek until we too specialise appropriately. 

I support the suggestion to determine appropriate specialisation. I don't know whether my comments
below go in the right direction. It seems to be getting near to curriculum, and I don't necessarily
want to (re)open the SWEBOK debate.


Consider Todd Carpenter's comments about SEUs, metastability and Byzantine faults. How many people
engineering financial systems software need to know about any of that? Whereas people engineering
transport control-systems software need to know about it intimately (supposedly-cosmic-ray-induced
SEUs occur in rail MOSFETs also). People building large databases need to know not only about DB
architecture, but have a good understanding of Paxos algorithms and how to choose one suitably for
the system requirements, whereas control-system engineers need to know none of that. People writing
financial systems could best have some understanding of the underlying financial mechanisms
(including law); people writing health-support systems could best have some understanding of the
underlying legal framework concerning data protection and the general needs of healthcare data
collection and retention.

There is certainly some material which engineers of software of any sort should understand in
common. All the stuff involved in programming digital computers: processor architecture and
operations; machine/assembler code and how it works; basic functions we used to call an "operating
system" that used to be implemented in SW and now are a mix of HW and Firmware; higher-level
languages and semantics; requirements and design specification techniques, assurance techniques
(including testing). Then there is basic SW-project management, including commenting code, project
planning and costing, time management.

I had thought all that was basic. Indeed, I have thought for nearly four decades now that the list
in "all the stuff involved in programming digital computers" above was core. Apparently various
curriculum committees don't necessarily agree. But I still don't see how you can reliably program a
computer without knowing all that to some degree. My experience says you can do all that to a
reasonable degree, with the appropriate background math, in two years.

Dave Parnas suggested that "software engineers" are engineers, and thus should pursue an engineering
curriculum, and then specialise to SW. I have never understood why he thinks a year's course in
Newtonian mechanics would have any relevance at all for someone who intends to engineer large IT
systems for finance, commerce, health or government administration. I would agree that Newtonian
mechanics would be a good idea for people intending to engineer embedded systems, and might go
further to suggest, for example, some study of aerodynamics (after the Newtonian mechanics) for
someone intending to specialise in avionics.

Since most IT systems nowadays are networked, and everyone is "on" the Internet, a basic
understanding of TCP/IP computer networking would not be amiss. For those specialising in avionics
and other embedded systems, understanding the fundamentals of digital-communication protocols with
more examples than just TCP/IP would not be amiss (CAN-Bus and SAFEbus might be a good start).

Consider, for comparison, subjects such as math. There is general material one has to know (groups,
rings, fields, matrices; Newtonian differential and integral calculus, Cauchy-Weierstrass analysis,
set theory) then one can specialise: a ring theorist will not necessarily know much functional
analysis; conversely a functional analyst might not need to know any number theory; a logician might
not need to know any of that. That has all been dealt with in every university's math curriculum for
decades.

The point about the dependable-software issue is that SW is widely regarded as not very dependable
compared with other engineered systems, and there is the feeling that standards are inappropriately
low. I think that is true. I have seen it in informatics students for nearly four decades now. More
than 90% graduate without having much of any understanding of how you say what a system is to do,
and, when you have designed it, how to check that your design is going to do what you said, and when
you've finished implementing it, how to check that your implementation fits the design. That is OK
when you are engineering the Mark II fridge to follow your Mark I fridge. That is not OK when you
are now building an electric car to follow your Mark I fridge (which is the kind of leap SW houses
can make). I suspect the issue of how to make software dependable has different answers for
different types of SW, just as how to make a car dependable requires a different collection of
knowledge from how to make a fridge dependable.

PBL

Prof. Peter Bernard Ladkin, Bielefeld, Germany
MoreInCommon
Je suis Charlie
Tel+msg +49 (0)521 880 7319  www.rvs-bi.de





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20180309/40a201e5/attachment.sig>