9 ms·
Software Engineering Body of Knowledge
- pcbro141 6y agoDirect PDF link: https://ieeecs-media.computer.org/media/education/swebok/swebok-v3.pdf https://ieeecs-media.computer.org/media/education/swebok/swe...
- DogWithKeyboard 6y agoThanks!
- de6u99er 6y agoty
- cyberlab 6y agoThanks for that. Had a quick cursory glance and randomly spotted this gem: 'The arsenal of OSs is abstraction'. It sounds debatable, but it's probably correct lol
- drummer 6y agoLol thanks, came here to ask exactly this.
- rwoerz 6y agoSomewhat related (but with focus on architecture): https://itabok.iasaglobal.org/ https://itabok.iasaglobal.org/
- manishsharan 6y agoFor architechture, would you not prefer the TOGAF documentation ? you will get a useful certification out of it once you pass those tests.
- rwoerz 6y agoAFAIR TOGAF is closed source and focuses more on (enterprise) architecture lifecycle management. ISABOK claims to be compatible with TOGAF [0] whatever that means for mere prose. [0] https://itabok.iasaglobal.org/itabok3_0/engagement-model-overview-3-0/togaf-adapter/ https://itabok.iasaglobal.org/itabok3_0/engagement-model-ove...
- keithnz 6y agoI was following grady booches handbook or architecture, but it seems to be somewhat dead(ish). It used to have some good content But his book reference is pretty good https://handbookofsoftwarearchitecture.com/books/ https://handbookofsoftwarearchitecture.com/books/
- auslegung 6y agoI would love to hear some reviews of this. This is the first time I’m hearing about this book, but it looks like the exact kind of thing I’ve wanted for a long time.
- getaclue 6y agogood overview
- Silhouette 6y agoIt's a worthy goal, but this Guide is a strange document. It's only 335 pages long, yet rather than just presenting an outline of the subject and referring to other sources for detailed treatments, it also tries to present some basic knowledge for each topic itself. It's hard to see how even the most expert contributors and skilled editors could compress a whole industry of knowledge that much and end up with something useful. Inevitably, much of the specific knowledge presented in the Guide is simplified to the point of arguably being wrong, dated to the point of arguably being obsolete, or just missing the point altogether. As someone else pointed out, this is only a "guide to" the field of software engineering. It does cite additional references as well (details in appendix C), though there are only 36 references supporting the entire Guide and some of them are old and of debatable relevance to modern software development. This edition of the Guide is nearly a decade old now, so it obviously doesn't include references to good books that have been published more recently and adopt a more objective, evidence-led style when discussing which modern practices actually work that was sorely lacking in most books from a decade or two ago.
- Cthulhu_ 6y agoIt should give enough leads for further investigation though; you can yeet any of the headings into Google and get thousands of results and dozens of book references.
- NAR8789 6y ago+1 it feels like this or something similar could potentially speed up initial steps of picking up new skills by providing "the right term to google for". In particular, it feels like it targets that stage of problem solving where I've defined my problem and am looking for prior art, but am having a trouble searching simply because I don't know what the people who previously met this problem called it. For this particular step of problem solving a very broad, very shallow general outline of the whole field, or even just a glossary of terms that tries to cover the whole field, feels like just the tool for the job.
- nitramm 6y agoKnowledge from which chapter to you consider the most useful for your work?
- getaclue 6y agodepends on the project/place entire work is useful
- getaclue 6y agonice share of the doc pretty common
- veltas 6y agoNot attacking this association, but just wanted to say I really dislike the term "body of knowledge". Areas of knowledge are certainly some kind of 'body', but the term always sounds to me like something you just keep adding more stuff onto the outside as you go, like a big snowball of ideas. And knowledge can become defunct, irrelevant, or disproven over time. And there's something about the way it tries to sound almost authoritative, without claiming to be scientific.
- benjaminjosephw 6y agoThis sounds like a fair description of how software engineering and computer science has progressed over the years so maybe it's a fair term ;)
- sas224dbm 6y agoMaybe. I've worked in the defense industry in and around software as a developer, designer etc for around 30 years. There's some good detail in there, but i think it's a little dated. Try looking for any material on REST in there. If it got refreshed somewhat i'd have it on my virtual bookshelf for sure.
- TomOwens 6y agoI think this is why the PDF is actually the "Guide to the Software Engineering Body of Knowledge". It's not a representation of the complete body of knowledge itself, but extracting key concepts and terms and provides pointers to things that are most relevant. If things are irrelevant or disproven over time, the guide to the body of knowledge would remove those terms, concepts, or references and point to something else.
- Silhouette 6y agoUnfortunately, where it does present "key concepts and terms", that presentation is often flawed. I think it would be more useful as a guide to the field of software engineering if that's the only thing it tried to be, setting out a well-considered structure but then referring to other reliable sources for details. It could be a lot shorter and more accessible, and it wouldn't keep saying things that are misleading or incorrect.
- okl 6y agoThere's also a PMBOK (project management) https://www.pmi.org/pmbok-guide-standards https://www.pmi.org/pmbok-guide-standards You can find the PDF via your favourite search engine.
- okl 6y agoAs an introduction to software development processes I recommend Steve McConnell's Software Project Survival Guide. You can get a used copy for small money.
- emddudley 6y agoThe current revision, V3, was published in 2013.
- deleted 6y ago[deleted]
- agentultra 6y agoI often find myself recommending and sharing this. Nice to see it on the front page. It's something that other engineering professions often share, a guide to the state of the art; pointers to find out about the different practices and tools we use.
- dejj 6y agoA reference to the Business Analysis Body of Knowledge (BABOK)[1] in the requirements engineering section would have been useful. The BABOK costs around 40 USD. [1] https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/ https://www.iiba.org/career-resources/a-business-analysis-pr...
- jes 6y agoI did not know of this document before today. I think it's valuable and I'm glad the link was shared. The value for me, I think, will be this. I'm an older (61) software engineer. A document like this can serve as a starting point for discussion in the software group of which I am a member. It can be something like a reference design for software practice within the group. By reference design, I mean, something that the group considers or consults when discussing or designing how its own practices should be. I'm thinking about facilitating some short (15 minute) discussions within our group to introduce the document and its contents, and then see if people think it would be worth our time to consult it when designing our own policies and procedures. Thoughts?
- deleted 6y ago[deleted]
- barbazoo 6y agoI only skimmed it and I couldn't find anything practical enough that would help me in my day to day work. For example it talks about design patterns but only in an abstract way, not what pattern could help you solve certain classes of problems (2.3.3). Or API design, great that's a constant source of contention, again, nothing meaty to reference in a discussion either (2.4.1). I'm probably grossly misunderstanding the purpose of that document. I was hoping it to be more similar to the OWASP cheat sheets [0] but more general. [0] https://cheatsheetseries.owasp.org/ https://cheatsheetseries.owasp.org/
- deeteecee 6y agoYeah, it's definitely not gonna be that explicit. There's a section under Cover called "Introduction to the Guide" that explains their objectives. Anyways, this doc is gonna be useful for me because while I took computer science & engineering as a major in college, I never ended up taking a course that taught me how to holistically look at software engineering as a discipline and all the terms that come with it.
- nradov 6y agoThe purpose is simply to define a minimum baseline of knowledge that every professional software engineer should memorize. It's kind of like having a common vocabulary so that we can hold productive discussions rather that wasting time defining basic terms. It isn't intended as a guideline to follow in daily work.
- stakkur 6y agoI'm not even sure there's a widely accepted definition of what 'software engineering' is, or what constitutes a 'software engineer'. I like the idea of having a body of knowledge, but given the loose definitions above, I'm not sure this is useful or practical beyond documenting some potential best practices/techniques.
- flakiness 6y agoFor a context, some older version of swebok was edited by Steve McConnell, the author of an old best seller "Code Complete" At that time, there was some consensus on what's software engineering. This version (coming out at 2013) was extension of that line of thought. The IT field has expaneded since then. So your point is kinda right: I don't think SWEBOK covers mobile or ML fields well, for example. But there is a still some value to cover traditinal software engineering field, as it still exists and it's not that small.
- whereis 6y agoMaybe this (and other work) will eventually lead to a Professional Engineering standard for software dev
- NAR8789 6y agotangential: Has anyone read DMBOK and what's your impression of its usefulness for software engineers? https://www.dama.org/cpages/body-of-knowledge https://www.dama.org/cpages/body-of-knowledge I ran into DMBOK just a few days ago when trying to figure out how to level up my schema-design skills. It sounds potentially useful as a map breaking down which directions to research in, but based on my research DMBOK also seems potentially much broader and shallower than what I need if what I'm really interested in is just the data modeling / data implementation slice. SWEBOK doesn't doesn't appeal as much to me personally right this moment, because my software engineering foundation already feels secure. DMBOK and PMBOK on the other hand feel more potentially interesting because they cover adjacent fields, so they feel like they'd be helpful in giving me hooks to grow towards being a "T-shaped" expert. DMBOK in particular sounds intriguing because my company and team are running into more and more data scalability and queryability challenges. I'm no stranger to day-to-day data modeling and schema building as it applies to webapps, but data modeling is something I've never had any formal training in, so I suspect my solutions tend to be only naively mature. I'm probably currently sitting in the Dunning-Kruger valley of data modeling. At the same time, DMBOK is intimidating because it's only available as a giant paper tome. I am a minimalist and am worried about the space on my bookshelf. I'd appreciate any impressions you can give if you've used it in the past. Curious about the other DAMA publications as well.
- haffi112 6y agoI started reading DMBOK, it's quite detailed as you describe. It's more of a reference in my opinion though. It can be a nice exercise to read through it with a group at your company. Have people relate to what is stated in the book to create actionable goals.
- NAR8789 6y agoThanks! To pick your brain... did you approach mostly the data modeling / data security / other slices more closely related to software engineering, or did you also socialize it out and get other people and teams involved in other slices like data governance? Can you speak to your specific situation at the time and any specific takeaways? More nitty-gritty... any suggestions for how to read through as a group in remote work? Feels like the only way might be to get each person a copy...
- postfacto 6y agoA truly worthy book of Software Engineer Dark Arts that’s come in handy multiple times. The Career Programmer: Guerilla Tactics for an Imperfect World (Expert's Voice) https://www.amazon.com/dp/1590596242/ref=cm_sw_r_cp_api_glt_fabc_AAYZT1YG2C0B0G3TT552 https://www.amazon.com/dp/1590596242/ref=cm_sw_r_cp_api_glt_...
- NtochkaNzvanova 6y agoTo each his own, but I found that book to be badly written, outdated, and not applicable to my day-to-day work. Published in 2006, it feels like it was written for a mid-90s world of waterfall process and shrink-wrapped software (6-month death marches to immovable ship dates). No mention of agile methods or the idea that web applications might be developed and deployed differently. It plays upon Dilbert-esque stereotypes of managers and marketing folks, and assumes a 100% adversarial relationship between the brilliant programmers and everyone else. Maybe I've just been lucky, but this isn't at all representative of the world I live in. I guess I'm fortunate not to have to adopt such a cynical worldview as the author. Then again, don't take my word for it, I only read half the book before I put it back into the huge stack of unread books next to my desk.
- deleted 6y ago[deleted]
- playpause 6y agoWhere did the amazing comment from itssatireok go? Was it deleted by them or moderators?
- sirsinsalot 6y agoA gem from the back of the book about staying current: "This article was obsolescent the moment it was drafted." Software.
- dSebastien 6y agoI think that providing a wide (vs deep) overview of software development is interesting & valuable. It's useful for newcomers, but also for people exploring new areas of IT. IMHO it's easier to dive into the details once we have at least a bird's eye view. But I'm a generalist so I'm probably biased ;-) I'm currently writing a series of e-books with a similar goal: https://www.dev-concepts.dev/table-of-contents https://www.dev-concepts.dev/table-of-contents Being aware of ideas, concepts & terms helps a ton to create clear mental models, find solutions more efficiently and reduce tunnel vision (e.g., John Doe works on back-end and thinks that front-end development is simple/easy). Of course a single book, cannot explain all that much, but I really feel like it's possible to share the main ideas, explain the jargon, what matters and why, what to pay attention to, etc. Readers gain a rough understanding of various ideas, and can come back for more if/when they need to dive into other subjects. I'm eager to get opinions/ideas about this.
- jdlyga 6y agoAh, good old SWEBOK. There's a bit of history to this document. Most of us who started our careers in the last decade came up in a time of agile programming. Where code comes first and documentation is mostly just done before prod releases. The programming world wasn't always like this. The software engineering world has a pendulum that swings between "strict process" and "just write code", and right now we're pretty far into the just writing code camp. SWEBOK captures a lot of the push in the late 90s, early 2000s to make software engineering a licensed profession. Where most of the work would be done in UML diagrams and committees before any code was written. The thinking was that if the diagrams were thorough enough that the coding part would be trivial, almost like how blueprints are for building a house.
- feoren 6y agoAnd then everyone realized that the blueprints for the house are not the UML diagrams, but the code itself. Documentation is done at the same time as the code is written, because the code itself is the authoritative documentation about how to build the program and what it will do. If the pendulum does swing back, let's hope those strict processes operate on code this time, instead of on silly code-adjacent time-wasting activities.
- biofox 6y agoAs someone who tends to conceptualise code visually, I find it extremely helpful to sketch-out diagrams of the processes and organisation before getting anywhere near the keyboard -- drawing clarifies my thinking unlike anything else. As such, I find the top-down UML-first approach to be much more natural, but I seem to be in the minority on this.
- HeyLaughingBoy 6y agoThe problem with this response is that the the "code itself" is not the authoritative documentation of what should be done. The "code itself" is what was done and could be absolutely, completely wrong. The point of separating documentation and code is that the assumption is that the documentation (design) is correct, having been reviewed and the code should implement it correctly, correctness being verified by review and testing. Those strict processes should absolutely operate on code, but they are useless if they operate only on the code.