[SystemSafety] A Fire Code for Software?

[W.L. Mostia]

I am one of the people who would like "software engineers" to complete a basic engineering curriculum and then have an education on software development, languages, user interfaces, human factors, project management, etc. if their end goal is to develop software for systems that utilize and/or manipulate or control the physical environment.  The basic reasoning is that to reliably and safely manipulate the physical environment, you have to know something about the physical environment (chemistry, thermodynamics, physics, electricity, mechanics, human factors, etc.) as well as the computers and software.  You also need to know something about the people in the environment.   In addition, I agree with below that the engineering approach to solving problems was the primary benefit of my engineering education along with understanding first principles.  

If the "software engineer" plans to develop software for the business world or strictly for data manipulations (e.g. databases), they need an education of the basics of the business environment and then software development.  They lose the engineering approach to problems but they get the basics of the business world to work with. The question then are they engineers or are they software developers or programmers; probably the latter.

My state (Texas) licenses software professional engineers starting 2013 (https://engineers.texas.gov/software.html ) though there is some history going back to 1993 ( https://en.wikipedia.org/wiki/Software_engineering_professionalism ).  There are 7 universities in Texas with accredited degrees in software engineering.  I believe that Australia and some provinces of Canada also license software engineers.

In order to take the Texas Principles & Practices of Engineering exam (8 hours) for software engineering, you must pass the Engineering in Training (EIT) fundamentals of engineering exam (6 hours), which is discipline specific.  The fundamental of engineering (FE) exam for software engineering is I believe the electrical and computers FE test . You then need to have 4 years of creditable work experience under a licensed engineer's supervision, have three recommendations from PE's, pass an engineering ethics exam, and a criminal background check.  The FE test description is given at the below link:

   https://ncees.org/wp-content/uploads/FE-Ele-CBT-specs.pdf 

The software Principles and Practice test description is given at the below link:  

   https://engineers.texas.gov/downloads/ncees_PESoftware_2013.pdf 

Licensing is a controversial subject.  It is also understood that passing the PE tests only determines that you know the basics of your craft at the time of the test and not how good an engineer or how professional you will be.  While the PE tests in Texas are discipline specific, Texas does not actually license by discipline but the licensed engineer is legally bound to only practice engineering in areas where they are competent, trained, and qualified.  One of the key purposes of the PE license is to define the professional engineer's legal responsibilities regarding his expertise and maintaining the safety of the public.  It also requires an engineer to take responsibility for his engineering designs by his stamping and sealing the engineering design documents. It also insures that the engineer have a minimum amount of continuing education.  In the US you generally cannot call yourself an engineer if you are not a PE (there is an industrial exception for "engineers," who only work on projects within their own company that do not affect the public, which is unfortunate for projects that affect personnel safety and the public beyond the fence line). 

While the PE license is not equivalent to a fire code, it does at least require an engineer to be legally bound to be competent in their field of endeavor, to take responsibility for their engineering designs, and to design systems where public safety is primary requirement of the engineering design.  As such they can be held responsible if something goes bad (and they should be for what they are responsible for (e.g. individual responsibilities) and what they can reasonably be expected to influence (e.g. group responsibilities)), which should encourage them to do a competent, professional work to the best of their abilities and to not work on projects or companies that do not have high engineering standards for their engineering work both figuratively and literally.  

William (Bill) L. Mostia, Jr. PE
ISA Fellow, FS Eng. (TUV Rheinland)
WLM Engineering Co.
281-728-3722

-----Original Message-----
From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de> On Behalf Of Steve Tockey
Sent: Friday, March 9, 2018 12:48 PM
To: Peter Bernard Ladkin <ladkin at causalis.com>; systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] A Fire Code for Software?


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://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.acm.org%2Fbinaries%2Fcontent%2Fassets%2Feducation%2Fse2014.pdf&data=02%7C01%7C%7Cae4cd9b4d74149cfe33f08d585ee4915%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636562181091428208&sdata=tXpXgl%2B3Y1L9wSkJsAPkKEa%2F%2FD68oKhGRbexANCQ1JQ%3D&reserved=0)



³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 (https://nam01.safelinks.protection.outlook.com/?url=www.abet.org&data=02%7C01%7C%7Cae4cd9b4d74149cfe33f08d585ee4915%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636562181091428208&sdata=yvCYa6ou1c8Mg988V7sJ6XjxJepjI0OsiwQzCBkhBUE%3D&reserved=0) 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  
Tel+https://nam01.safelinks.protection.outlook.com/?url=www.rvs-bi.de&da
Tel+ta=02%7C01%7C%7Cae4cd9b4d74149cfe33f08d585ee4915%7C84df9e7fe9f640afb
Tel+435aaaaaaaaaaaa%7C1%7C0%7C636562181091428208&sdata=vK7QfTwE0IRnpWIPS
Tel+44igR4f4Ap0XQkfhoeu%2FnOk9iU%3D&reserved=0






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