[SystemSafety] A Fire Code for Software?

[Steve Tockey]

PBL wrote:

³We will never deserve or gain the recognition we seek until we too
specialise appropriately.²

Maybe so, but I would be more than happy just to have ³software
engineering² recognized as a separate discipline from ³computer science²
by universities and hiring managers. I don¹t see any second-order
specialization being relevant until the first-order distinction has been
generally acknowledged.



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

Just curious, but what curriculum committees are you referring to? One
committee seems to have done a fairly good job, namely

³SE 2014²: Curriculum Guidelines for Undergraduate Degree Programs in
Software Engineering (available at
https://www.acm.org/binaries/content/assets/education/se2014.pdf)



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

To get an engineering degree from an ABET (www.abet.org) accredited
university in the US, one has to take classes in Chemistry, Physics,
Statics, and Thermodynamics regardless of specialization. From my
conversations with the people who think this is a good idea, it is less
important what the course subject is, and much more important that the
approach be one of ³experimental/ empirical investigation² vs. ³analytical
investigation². Those courses force the student to think in very different
ways, both of which are important for all engineers. It¹s learning the
thought processes that¹s most important.

A secondary justification (at least in the US) is that if there is some
amount of core curriculum across all specializations, then engineers will
have a better understanding and appreciation of those other
specialization. A mechanical engineer may be called on to work on a
project involving chemical engineering, and may even need to do some of
that Chem E work themselves. At least this way they would have some chance
of succeeding because they had some education in that topic.

So it should follow that if someone were be a software engineer ala the
Parnas et. al. interpretation, then a) they need to be competent in
experimental vs. analytical investigations, and b) any project could
involve some component of some other engineering specialty.

I¹m not saying I agree with that justification, I¹m just reporting on how
the justification was explained to me because I had exactly the same
question.



³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 am sure it is true. I¹m just doing what I can to raise that bar.



³. . . and I don't necessarily want to (re)open the SWEBOK debate.²

OK, but I just want to say that the SWEBOK Guide committee attempted to
follow the PMBOK Guide¹s lead in trying to focus on the things that ³are
useful on most software projects, most of the time². The SWEBOK Guide
committee recognized and acknowledged that someone might want to
specialize off of that core. Whether or not they succeeded may be
debatable, but at least they tried.



Cheers,

‹ steve



-----Original Message-----
From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de>
on behalf of Peter Bernard Ladkin <ladkin at causalis.com>
Organization: RVS Bielefeld and Causalis
Date: Friday, March 9, 2018 at 3:01 AM
To: "systemsafety at lists.techfak.uni-bielefeld.de"
<systemsafety at lists.techfak.uni-bielefeld.de>
Subject: Re: [SystemSafety] A Fire Code for Software?



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