[SystemSafety] C for OSs

[Steve Tockey]

Olwen,

You wrote: “Hmm. .... This remark may not be popular:”

Your remark? Or my remark? Either way, I don’t think we are in that much disagreement, really.



Then you wrote: “Above all else, IMO, software engineers require a solid and extensive grounding in discrete mathematics.”

If we disagree here, then it is only on prioritization. FWIW, I subscribe to the Accreditation Board of Engineering & Technology (ABET, see https://www.abet.org/) definition of “Engineering” which is, essentially,

Engineering = Theory + Practice + Engineering Economy

All true engineers need to have a solid foundation in:

*) relevant Scientific & Mathematical Theory
*) useful and relevant Practice
*) Engineering Economy

Take, for example, a Chemical Engineer. The scientific and mathematical theory is Chemistry, Physics, and to some extent Quantum Mechanics. The relevant practice are things like waste heat removal strategies, pressure vessels, catalysts, etc. The theory and practice combine to help the true engineer propose a set of theoretically viable, potential solutions to a real-world problem. Engineering economy comes in to guide the true engineer in identifying the most cost-effective one of those theoretically viable, potential solutions. As a consultant friend of mine once said (slightly paraphrased), “The Theory and the Practice sets ‘em up, Economics knocks ‘em down”.

The extension of this into Software Engineering is straightforward. The relevant theory is Computer Science and Discrete Math. The practice includes things like fundamental software design principles, effective requirements elicitation & analysis techniques, design patterns, architectural styles, various test coverage criteria, and so on.

We definitely agree that, as you said, “software engineers require a solid and extensive grounding in discrete mathematics.”. We just may not agree on the “above all else” part because I claim Computer Science and Engineering Economy are equally important.

By the way, SWEBOK Guide V3 has 15 knowledge areas. Let me highlight three of them in particular:

Chapter 13: Computing Foundations—a sampling of topical content includes:
— programming fundamentals
— low-level vs. high-level languages
— declarative vs. imperative languages
— data structure and representation
— algorithms and complexity
— basic concept of a system
— computer organization
— compiler basics
— operating system basics
— database basics and data management
— networking protocols and standards
— parallel and distributed computing
— basic user human factors
— basic developer human factors
— and so on . . .

The primary references for this chapter are
— [5*] J.G. Brookshear, Computer Science: An Overview, 10th ed., Addison-Wesley, 2008.
— [14*] E. Horowitz et al., Computer Algorithms, 2nd ed., Silicon Press, 2007.
— [32*] I. Sommerville, Software Engineering, 9th ed., Addison-Wesley, 2011.
— [27*] L. Null and J. Lobur, The Essentials of Computer Organization and Architecture, 2nd ed., Jones and Bartlett Publishers, 2006.


Chapter 14: Mathematical Foundations—a sampling of topical content includes:
— sets, relations, functions
— basic logic
— proof techniques
— basics of counting
— graphs and trees
— discrete probability
— finite state machines
— grammars
— numerical precision
— number theory
— algebraic structures
— and so on . . .

The primary references for this chapter are
— [29*] K. Rosen, Discrete Mathematics and Its Applications, 7th ed., McGraw-Hill, 2011.
— [7*] E.W. Cheney and D.R. Kincaid, Numerical Mathematics and Computing, 6th ed., Brooks/Cole, 2007.


Chapter 12: Engineering Economics—a sampling of topics includes:
— cash flow
— time-value of money
— decision making processes
— proposals
— planning horizon
— for-profit decision making
— break-even analysis
— optimization analysis
— inflation
— depreciation
— replacement and retirement decisions
— decisions under risk
— decisions under uncertainty
— multiple attribute decisions
— and so on . . .

The primary references for this chapter are
— [33*] S. Tockey, Return on Software: Maximizing the Return on Your Software Investment, 1st ed., Addison-Wesley, 2004.
— [32*] I. Sommerville, Software Engineering, 9th ed., Addison-Wesley, 2011.

I would classify the other 12 knowledge areas as falling into the category of Practice per the ABET definition of Engineering.



Later you wrote: “They also need to read extensively and be able to figure out what to read without even consulting a BOK document”

The point of SWEBOK Guide V3 is ***NOT*** to be the be-all, end-all core repository of Software Engineering knowledge. The proper name is “The Guide to the Software Engineering Body of Knowledge (SWEBOK Guide)", not “The Software Engineering Body of Knowledge (SWEBOK)”. It’s goal is to provide a survey of the landscape. It was never intended to be the comprehensive knowledge base of Software Engineering:

<quote>
The Guide to the Software Engineering Body of Knowledge (SWEBOK Guide) was established with the following five objectives:

1. To promote a consistent view of software engineering worldwide

2. To specify the scope of, and clarify the place of software engineering with respect to other disciplines such as computer science, project management, computer engineering, and mathematics

3. To characterize the contents of the software engineering discipline

4. To provide a topical access to the Software Engineering Body of Knowledge

5. To provide a foundation for curriculum development and for individual certification and licensing material
</quote>


And then you wrote: “And they must be prepared to buy lots of professional books as an investment.”

Yes. I would be afraid to have to count all of the professional software engineering related books I own. My point with calling out the SWEBOK Guide Consolidated List of References is that it gives you a core set of 36 (keep in mind that some of the 36 are papers, not actually books) to start from that give reasonable coverage of the breadth of Software Engineering.



Finally you wrote: “If you can't or you're not prepared to do that, you may as well forget it, IMO”

The scary statistic I heard several years ago was that the average so-called software professional owns less than three career-related books. This is but one of the many reasons I continue to say,

“We are an industry of highly paid amateurs”.




— steve



From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de<mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de>> on behalf of Olwen Morgan <olwen at phaedsys.com<mailto:olwen at phaedsys.com>>
Date: Monday, September 16, 2019 at 1:47 PM
To: "systemsafety at lists.techfak.uni-bielefeld.de<mailto:systemsafety at lists.techfak.uni-bielefeld.de>" <systemsafety at lists.techfak.uni-bielefeld.de<mailto:systemsafety at lists.techfak.uni-bielefeld.de>>
Subject: Re: [SystemSafety] C for OSs



On 16/09/2019 17:53, Steve Tockey wrote:

-<snip>-

https://www.computer.org/education/bodies-of-knowledge/software-engineering/swebok-reference-list

My point here is that it cannot be one book, it was quite a struggle to narrow it down to 36 representative books and papers.

-<snip>-

Hmm. .... This remark may not be popular:

Above all else, IMO, software engineers require a solid and extensive grounding in discrete mathematics. In addition, they need to be of the mindset that sees mathematics a their pre-eminent problem-solving tool. They also need to read extensively and be able to figure out what to read without even consulting a BOK document. And they must be prepared to buy lots of professional books as an investment. (In my busier years, it was nothing for my annual personal expenditure on professional books to exceed £1000. It's a lot cheaper than going on courses.)

If you can't or you're not prepared to do that, you may as well forget it, IMO.


There's reactionary prejudice for you,

Olwen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20190916/37017e20/attachment-0001.html>