The Master might say something like this, if translated crudely -
Software engineering is programming professionally, with a dialogue on quality. Everything else is details.
The IEEE has been riding this horse for a very long time, in the face of very serious criticism (see the ACMs comments from a quarter century ago).
The presentation of it is _not even wrong_. It reads like a mid level manager at a very old enterprise firm wrote out what important at their firm, and took no material care for other ways. The SWEBOK has been that way for as long as I can remember ( an aside: my experience of Software Engineering academia has been so deeply negative to the point I wrote the field off in 2013. Decoupled from reality, PM oriented, toy studies- irrelevant. The SWEBOK is an artifact of that world. I should dip back in... Maybe Google & MS Research have done the real work here...)
There's a body of _practice_ that is mildly incidental. Most acronyms are fads. Lots of ephemeral technologies that only exist as painful grimaces. IE- CORBA- SOAP, etc...
Project management and quality management are also essentially contingent. One company does this. One that. Waterfall here. Agile there. Whirlpool the other.
What you're left with as non contingent and timeless is in the area of compilers, algorithms, etc. Which is not SWE at all.
If I were to write a swe body of knowledge, it would be in koan form, more than likely.
> The IEEE has been riding this horse for a very long time
Well, there's your mistake right there. You're supposed to be riding an ox.
All this talk of oxen and horses got me curious about the PDF, so I went and took a look. It's really far worse than you've described.
I couldn't stomach it for too long, but here's some highlights:
(1) The first ~65 pages are about "requirements gathering." Page 60 offers up this gem of insight:
Priority = ((Value * (1 - Risk)) / Cost
(2) The next hundreds of pages go through topics in sequence, like "Architecture" and "Design" (who knew they were different?). Naturally, "Security" is slapped on several hundred pages later.
I couldn't make it through the whole PDF, in all honesty. But I'm quite certain the soul of software engineering is nowhere to be found in there; they've eliminated it entirely and replaced it with stamp-collecting and checklists.
Software engineering is programming professionally, with a dialogue on quality. Everything else is details.
The IEEE has been riding this horse for a very long time, in the face of very serious criticism (see the ACMs comments from a quarter century ago).
The presentation of it is _not even wrong_. It reads like a mid level manager at a very old enterprise firm wrote out what important at their firm, and took no material care for other ways. The SWEBOK has been that way for as long as I can remember ( an aside: my experience of Software Engineering academia has been so deeply negative to the point I wrote the field off in 2013. Decoupled from reality, PM oriented, toy studies- irrelevant. The SWEBOK is an artifact of that world. I should dip back in... Maybe Google & MS Research have done the real work here...)
There's a body of _practice_ that is mildly incidental. Most acronyms are fads. Lots of ephemeral technologies that only exist as painful grimaces. IE- CORBA- SOAP, etc...
Project management and quality management are also essentially contingent. One company does this. One that. Waterfall here. Agile there. Whirlpool the other.
What you're left with as non contingent and timeless is in the area of compilers, algorithms, etc. Which is not SWE at all.
If I were to write a swe body of knowledge, it would be in koan form, more than likely.