<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;">
<div><br>
</div>
<div>Derek,</div>
<div><br>
</div>
<div><i>“It cannot be more than the current list of talking points</i></div>
<i>because there is no body of knowledge, apart from snippets<br>
</i>
<div><i>here and there.”</i></div>
<div><br>
</div>
<div>From the foreword to the 2014 edition (<u>underlining</u> added by me for emphasis):</div>
<div><br>
</div>
<div>“<u>Every profession is based on a body of knowledge, although that knowledge is not always</u></div>
<div><u>defined in a concise manner.</u> In cases where no formality exists, the body of knowledge is “generally</div>
<div>recognized” by practitioners and may be codified in a variety of ways for a variety of different</div>
<div>uses. But <u>in many cases, a guide to a body of knowledge is formally documented, usually</u></div>
<div><u>in a form that permits it to be used for such purposes as development and accreditation of academic</u></div>
<div><u>and training programs, certification of specialists, or professional licensing. Generally,</u></div>
<div><u>a professional society or similar body maintains stewardship of the formal definition of a body</u></div>
<div><u>of knowledge</u>.</div>
<div><br>
</div>
<div>
<div>During the past forty-five years, software engineering has evolved from a conference catchphrase</div>
<div>into an engineering profession, characterized by 1) a professional society, 2) standards</div>
<div>that specify generally accepted professional practices, 3) a code of ethics, 4) conference proceedings,</div>
<div>5) textbooks, 6) curriculum guidelines and curricula, 7) accreditation criteria and accredited</div>
<div>degree programs, 8) certification and licensing, and 9) this <i>Guide to the Body of Knowledge</i>.</div>
</div>
<div><br>
</div>
<div>
<div>…</div>
</div>
<div><br>
</div>
<div>
<div><u>It should be noted that this <i>Guide</i> does not present the entire the body of knowledge for software</u></div>
<div><u>engineering but rather serves as a guide to the body of knowledge that has been developed</u></div>
<div><u>over more than four decades. The software engineering body of knowledge is constantly</u></div>
<div><u>evolving. Nevertheless, this Guide constitutes a valuable characterization of the software engineering</u></div>
<div><u>profession.</u></div>
</div>
<div><br>
</div>
<div>…</div>
<div><br>
</div>
<div>
<div>This <i>Guide to the Software Engineering Body of Knowledge</i> is presented to you, the reader, as
<u>a</u></div>
<div><u>mechanism for acquiring the knowledge you need in your lifelong career development as a software</u></div>
<div><u>engineering professional.</u>"</div>
</div>
<div><br>
</div>
<div>Even from the original 2004 edition, SWEBOK <u><b><i>Guide</i></b></u> never claimed to be the entire body of knowledge. That body is simply too big. SWEBOK
<u><b><i>Guide</i></b></u> is just a survey of that knowledge. In fact, what the authors and editors of SWEBOK Guide believe (although it may not be explicitly stated) is that their proposal for a Software Engineering Body of Knowledge is really characterized
by Appendix C The Consolidated Reference List and the “MATRIX OF TOPICS VS. REFERENCE MATERIAL” at the end of each Knowledge Area (KA) chapter.</div>
<div><br>
</div>
<div><br>
</div>
<div><i>“The current role of SWEBOK is to give box tickers a warm</i></div>
<div><i>fuzzy feeling that a body of knowledge exists.”</i></div>
<div><br>
</div>
<div>That may very well be how you perceive the role of SWEBOK Guide, but that’s not at all how it is seen by the people who created it. And by the people who use it as intended.</div>
<div><br>
</div>
<div><br>
</div>
<div><i>“When people</i></div>
<i>suggest that the answer to my question(s) can be found in<br>
SWEBOK, I ask them if they have ever read any of it.<br>
Invariably they have not, but they are ever so sure that<br>
</i>
<div><i>it contains the answers to my question.”</i></div>
<div><br>
</div>
<div>Sad. Not only have I read it—multiple times—I was a reviewer of both the 2004 and 2014 versions. I am also author or co-author of 5 chapters in the new version that should be coming out before the end of this year.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>— steve</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
<div>On Aug 22, 2024, at 6:43 AM, Derek M Jones <derek@knosof.co.uk> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div>Les,<br>
<br>
<blockquote type="cite">From the SWEBOK Foreword:<br>
"Its objectives include the provision of guidance for learners, researchers,<br>
and practitioners to identify and share a common understanding of “generally<br>
accepted knowledge” in software engineering, defining the boundary between<br>
software engineering and related disciplines, and providing a foundation for<br>
certifications and educational curricula."<br>
Q1: Do you feel this is a righteous mission?<br>
</blockquote>
<br>
I don't know about righteous, but the objectives are laudable.<br>
<br>
<blockquote type="cite">Q2: If yes how do you think the SWEBOK could be improved?<br>
</blockquote>
<br>
It cannot be more than the current list of talking points<br>
because there is no body of knowledge, apart from snippets<br>
here and there.<br>
<br>
The current role of SWEBOK is to give box tickers a warm<br>
fuzzy feeling that a body of knowledge exists. When people<br>
suggest that the answer to my question(s) can be found in<br>
SWEBOK, I ask them if they have ever read any of it.<br>
Invariably they have not, but they are ever so sure that<br>
it contains the answers to my question.<br>
<br>
<blockquote type="cite">Les<br>
<blockquote type="cite">Steve,<br>
<br>
> First, I am pulling the “description†of Software Engineering from<br>
</blockquote>
the soon-to-be-released version 4 of the “Guide to<br>
<blockquote type="cite">the Software Engineering Body of Knowledge†(aka “SWEBOK Guide†v4).<br>
</blockquote>
The final publication version should be out in<br>
<blockquote type="cite">October or November (fingers crossed) but you can find the public review<br>
</blockquote>
draft here:<br>
<blockquote type="cite">
<blockquote type="cite"><br>
https://waseda.app.box.com/s/r1j1mavf3glhtf6qh5j0xxdeb4uaws5h<br>
</blockquote>
<br>
Thanks for this link.<br>
<br>
I have always found the SWEBOK Guide to be a very odd document.<br>
<br>
It started out as essential a compendium of terms, and has gradually<br>
accumulated a collection of software related phrases, opinions,<br>
and the briefest of examples.<br>
<br>
It's not so much a body a knowledge as a body of snippets to<br>
throw into a conversation to appear to know something about<br>
software engineering.<br>
<br>
-- <br>
Derek M. Jones Evidence-based software engineering<br>
blog:https://shape-of-code.com<br>
<br>
_______________________________________________<br>
The System Safety Mailing List<br>
systemsafety@TechFak.Uni-Bielefeld.DE<br>
Manage your subscription: https://lists.techfak.uni-<br>
</blockquote>
bielefeld.de/mailman/listinfo/systemsafety<br>
--<br>
Les Chambers<br>
les@chambers.com.au<br>
https://www.chambers.com.au<br>
https://www.systemsengineeringblog.com<br>
+61 (0)412 648 992<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>
Derek M. Jones Evidence-based software engineering<br>
blog:https://shape-of-code.com<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</div>
</div>
</div>
<br>
</body>
</html>