[HN Gopher] Software Engineering Body of Knowledge (SWEBOK) v4.0...
___________________________________________________________________
Software Engineering Body of Knowledge (SWEBOK) v4.0 is out [pdf]
Author : beryilma
Score : 83 points
Date : 2024-10-21 19:16 UTC (3 hours ago)
(HTM) web link (ieeecs-media.computer.org)
(TXT) w3m dump (ieeecs-media.computer.org)
| beryilma wrote:
| > The Guide to the Software Engineering Body of Knowledge (SWEBOK
| Guide), published by the IEEE Computer Society (IEEE CS),
| represents the current state of generally accepted, consensus-
| based knowledge emanating from the interplay between software
| engineering theory and practice. Its objectives include the
| provision of guidance for learners, researchers, and
| practitioners to identify and share a common understanding of
| "generally accepted knowledge" in software engineering, defining
| the boundary between software engineering and related
| disciplines, and providing a foundation for certifications and
| educational curricula.
| kragen wrote:
| It's so unfortunate that this effort is still alive. The ACM
| canceled its involvement for excellent reasons which are worth
| reading:
| https://web.archive.org/web/20000815071233/http://www.acm.or...
|
| It's probably also worth reading Dijkstra's assessment of the
| "software engineering" field (roughly coextensive with what the
| SWEBOK attempts to cover) from EWD1036, 36 years ago.
|
| > _Software engineering, of course, presents itself as another
| worthy cause, but that is eyewash: if you carefully read its
| literature and analyse what its devotees actually do, you will
| discover that software engineering has accepted as its charter
| "How to program if you cannot."._
|
| https://www.cs.utexas.edu/~EWD/ewd10xx/EWD1036.PDF
|
| The ACM's criticisms, however, are much harsher and much more
| closely focused on the ill-conceived SWEBOK project.
|
| The IEEE's continued involvement calls the IEEE's own credibility
| and integrity into question--as do its continued opposition to
| open-access publishing and its recent history of publishing
| embarrassingly incompetent technical misinformation in _IEEE
| Spectrum_ (cf., e.g.,
| https://news.ycombinator.com/item?id=41593788, though there are
| many other examples). What is going on at IEEE?
| michaelsbradley wrote:
| Any suggestion for a handbook or compendium that you consider
| to be a worthy alternative?
| lifeisstillgood wrote:
| The thing here is, this reads like a prissy textbook that no-
| one can really disagree with but is still not gripping the
| reality. More HR handbook than blood-red manual.
|
| For example, project management. The book covers this but
| does the usual wrong headed way of imagining there are
| executives with clear eyed Vision and lay down directives.
|
| This is of course not how most projects in most companies are
| started. It's a mess - reality impinges on the organisation,
| pain and loss and frustration result in people making fixes
| and adjustments. Some tactical fixes are put in place,
| covered by "business as usual", usually more than one
| enthusiastic manager thinks their solution will be the best,
| and a mixture of politics and pragmatism results in a
| competition to be the one project that will solve the problem
| and get the blessed budget. By the time there is an official
| project plan, two implementations exist already, enough
| lessons learnt that the problem is easily solved, but with
| sufficient funding all that will be abandoned and have to be
| rebuilt from scratch - and at a furious pace to meet
| unrealistic expectations that corners will be cut leading ...
|
| That manual needs to be written.
| Niksko wrote:
| Very interesting. Particularly their notion (paraphrasing) that
| SWEBOK attempts to record generally recognised knowledge in
| software engineering while excluding knowledge about more
| specific subdomains of software.
|
| That over-deference towards general knowledge coupled with some
| sort of tie to a similar Australian effort probably explains
| why the software engineering degree I began in Australia felt
| like a total waste of time. I remember SWEBOK being mentioned
| frequently. I can't say I've gotten terribly much value out of
| that learning in my career.
| beryilma wrote:
| As much as I like Dijkstra and this particular article of his
| (it is an assigned reading in my "Software Engineering" class),
| developing any large scale software that we have today starting
| from formal methods is just a fantasy.
|
| I understand the importance of learning formal methods
| (discrete math, logic, algorithms, etc.), but they are not
| nearly enough to help someone get started with a software
| project and succeed at it.
|
| So, if not "software engineering", then what should we teach to
| a student who is going to be thrown into the software world as
| it exists in its current form?
| numbsafari wrote:
| Since we're talking Dijkstra, perhaps "structured
| programming" is a starting place.
| TrueDuality wrote:
| Wanted to call out the specific requirements for what the ACM
| wanted out of their participation in creating a core body of
| knowledge (from the linked reasoning): * It
| must reflect actual achievable good practice that ensures
| quality consistent with the stated interest; it is not that
| following such practices are guaranteed to produce perfect
| software systems, but rather that doing so can provide
| reasonably intuitive expectations of quality. * It must
| delineate roles among the participants in a software project.
| * It must identify the differential expertise of specialties
| within software engineering. * It must command the
| respect of the community. * It must embrace change in
| each and every dimension of its definition; that is, it must be
| associated with a robust process for ensuring that it is
| continually updated to account for the rapid change both in
| knowledge in software engineering and also in the underlying
| technologies.
|
| It then details exactly how SWEBOK fails to meet those (which
| all still seem to be relevant) and comes to the following
| scathing conclusion: Overall, it is clear
| that the SWEBOK effort is structurally unable to satisfy any
| substantial set of
|
| the requirements we identified for bodies of knowledge in
| software engineering, independent of its specific content.
|
| I haven't read the SWEBOK but some spot checking and a review
| of the ToC seems to indicate they have not meaningfully taken
| that criticism into an account.
| BJones12 wrote:
| > software engineering has accepted as its charter "How to
| program if you cannot.".
|
| Is that supposed to be a negative? Isn't that the point of any
| profession? Like are any of these analogs negative?:
|
| Medicine has accepted as its charter "How to cure disease if
| you cannot."
|
| Accounting has accepted as its charter "How to track money if
| you cannot."
|
| Flight schools has accepted as its charter "How to fly if you
| cannot."
| Rochus wrote:
| > _The ACM canceled its involvement for excellent reasons which
| are worth reading_
|
| Interesting, thanks for the hint; the paper is from 2000
| though, and as it seems it would need an update; just checked
| e.g. the "roles" point and it seems there were significant
| changes. I also think ACM has rather different goals than IEEE.
|
| > _It 's probably also worth reading Dijkstra's assessment of
| the "software engineering" field_
|
| Well, was there anything or anyone that Dijkstra didn't rant
| about ;-)
| ctz wrote:
| Runtime errors surface when a program runs into an
| unexpected condition or situation such as dividing by zero,
| memory overflow, or addressing a wrong or unauthorized
| memory location or device, or when a program tries to
| perform an illegitimate or unauthorized operation or tries
| to access a library, for example. The programs must be
| thoroughly tested for various types of inputs (valid data
| sets, invalid data sets and boundary value data sets) and
| conditions to identify these errors. Once identified,
| runtime errors are easy to fix.
|
| Embarrassing horseshit.
| dustfinger wrote:
| > or tries to access a library
|
| I had to open the PDF and find this line to confirm. It really
| says that. It reads as if claiming that any program that
| accesses a library will then have a runtime error. That is
| obviously not what they intended, but I have read it over a few
| times now and cannot see another interpretation.
| TrueDuality wrote:
| That line is referring to shared libraries linked to a
| dynamic executable. If a shared library isn't installed or
| available you will receive an error similar to the following:
| $ ./main ./main: error while loading shared
| libraries: librandom.so: cannot open shared object file: No
| such file or directory
|
| Which is indeed a runtime error.
|
| There is also the common use case of hot-reloading compiled
| code which dynamically loads and unloads shared libraries
| without restarting the entire application. It needs to be
| done carefully but you've likely used an application that
| does this. Failure to load a library, or loading an
| incompatible one will also create a runtime error.
|
| Looks like there is a lot of bad generalizations in here, but
| they are technically correct on this one.
| dustfinger wrote:
| I understand that is what they meant, but it is not what
| they wrote. They should have qualified the statement as you
| did, with the conditions that yield a runtime error. Even
| if they generalized those conditions that would have been
| fine.
|
| for example: or tries to access a library
| that it is unable to for some reason without handling the
| resulting error.
| stonemetal12 wrote:
| Perhaps if they said "tries and fails to access a library".
| Merely attempting to access (possibly successfully) a
| library is not an error.
| prewett wrote:
| I suppose, yeah, when I figure out the exact reason why the
| error occurred, fixing it is often easy. The finding, however,
| can often take a long time, which leaves me feeling "once you
| have driven across the continent, finding your desired endpoint
| is a quick process". "Once constructed, installing the door on
| your new house is a simple and easy task". Well, sure, if you
| take out the time-consuming parts, it's quick and easy.
|
| Except for all those runtime errors where the fix required
| major refactoring, or the problem is in a third party library,
| the OS, or some other unchangeable component.
| pnathan wrote:
| Swebok is an attempt to look at the whole ox
|
| Cook Ding was cutting up an ox for Lord Wenhui. As every touch of
| his hand, every heave of his shoulder, every move of his feet,
| every thrust of his knee -- zip! zoop! He slithered the knife
| along with a zing, and all was in perfect rhythm, as though he
| were performing the dance of the Mulberry Grove or keeping time
| to the Jingshou music.
|
| "Ah, this is marvelous!" said Lord Wenhui. "Imagine skill
| reaching such heights!"
|
| Cook Ding laid down his knife and replied, "What I care about is
| the Way, which goes beyond skill. When I first began cutting up
| oxen, all I could see was the ox itself. After three years I no
| longer saw the whole ox. And now -- now I go at it by spirit and
| don't look with my eyes. Perception and understanding have come
| to a stop and spirit moves where it wants. I go along with the
| natural makeup, strike in the big hollows, guide the knife
| through the big openings, and following things as they are. So I
| never touch the smallest ligament or tendon, much less a main
| joint.
|
| "A good cook changes his knife once a year -- because he cuts. A
| mediocre cook changes his knife once a month -- because he hacks.
| I've had this knife of mine for nineteen years and I've cut up
| thousands of oxen with it, and yet the blade is as good as though
| it had just come from the grindstone. There are spaces between
| the joints, and the blade of the knife has really no thickness.
| If you insert what has no thickness into such spaces, then
| there's plenty of room -- more than enough for the blade to play
| about it. That's why after nineteen years the blade of my knife
| is still as good as when it first came from the grindstone.
|
| "However, whenever I come to a complicated place, I size up the
| difficulties, tell myself to watch out and be careful, keep my
| eyes on what I'm doing, work very slowly, and move the knife with
| the greatest subtlety, until -- flop! the whole thing comes apart
| like a clod of earth crumbling to the ground. I stand there
| holding the knife and look all around me, completely satisfied
| and reluctant to move on, and then I wipe off the knife and put
| it away."
|
| "Excellent!" said Lord Wenhui. "I have heard the words of Cook
| Ding and learned how to care for life!"
| numbsafari wrote:
| Even he admits, he had to start somewhere.
| pnathan wrote:
| 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.
| walterbell wrote:
| _> If I were to write a swe body of knowledge, it would be
| in koan form, more than likely._
|
| Please do! You can continue with standalone HN comments,
| which can be upvoted to enlighten human and AI bot alike.
| kazinator wrote:
| > _Popular OOP languages include C++, C#, Cobol 2002, Java,
| Python, Lisp, Perl, Object Pascal, Ruby and Smalltalk._
|
| :)
| JanSt wrote:
| If you really want someone interested in software development to
| run away, hand them books like this one.
| NotGMan wrote:
| This was my first thought.
|
| If this ever starts to get thought in CS university courses the
| amount of devs would dramaticaly reduce due to trauma.
| tptacek wrote:
| SWEBOK 4 adds a dedicated section for security, but it's
| painfully 2012 (testing, for instance, centers on the old
| industry-driven "SAST" vs. "DAST" distinction). It also promotes
| stuff like Common Criteria and CVSS. The "domain-specific"
| security section could have been pulled out of the OWASP wiki
| from 2012 as well: "cloud", "IOT", "machine learning".
| aste123 wrote:
| Yes
| miffy900 wrote:
| So at the start of each chapter, the book has a table of
| abbreviations and their definitions, called 'Acronyms'. To
| whoever wrote or edited the book: please lookup the definition of
| the word 'acronym': _" an abbreviation formed from the initial
| letters of other words and pronounced as a word (e.g. NASA)."_
| Not all of the abbreviations listed are acronyms! Most are just
| plain old initialisms.
|
| Since when has anyone ever tried to pronounce 'GPS' as anything
| other than G-P-S? Also "ECS" = "Ecosystem"? Maybe I'm just crazy
| but I've never heard or read anyone abbreviate ecosystem as
| 'ECS'. I've come across ECS as entity component system in video
| game engines, but never as just 'ecosystem'. Also it's defined
| exactly once in chapter 5 and then never used again in the book.
| Why even bother to mention it then?
|
| Oh and publish it as a PDF, but then have no actual page numbers?
___________________________________________________________________
(page generated 2024-10-21 23:00 UTC)