Software Engineering Body Of Knowledge

A process was begun in 1999 to develop a guide to the SoftwareEngineeringBodyOfKnowledge (SWEBOK). It has the goal of providing a comprehensive hierarchical collection of topics addressed with pointers to appropriate reference materials.

The purpose of this Guide is to provide a consensually validated characterization of the bounds of the software engineering discipline and to provide a topical access to the Body of Knowledge supporting that discipline. The Body of Knowledge is subdivided into ten Knowledge Areas (KA) and the descriptions of the KAs are designed to discriminate among the various important concepts, permitting readers to find their way quickly to subjects of interest. Upon finding a subject, readers are referred to key papers or book chapters selected because they succinctly present the knowledge.

Underlying Principles - The two following principles underlie the development approach for this project: transparency: the development process is itself published and fully documented; consensus-building: the development process is designed to build, over time, consensus in industry, professional societies and standards-setting bodies, among practicing software developers and in academia. -- http://www.swebok.org

The "Software Engineering Body of Knowledge" or SWEBOK project is currently an IeeeSociety project to define "generally accepted" practices in software engineering. The current version, released in 2005, is downloadable from http://www.swebok.org.

The original project was a joint effort of the IeeeComputerSociety? and AssociationForComputingMachinery, but the ACM withdrew from the effort in 2000, declaring that the SWEBOK project, which they supported, was being tied too closely to the licensing of software engineers, which they currently oppose:

IEEE and ACM made their first version by forming a union of knowledge in several software engineering textbooks. My reaction when I heard that was that most software engineering knowledge is not in textbooks! I guess they are trying to define what can be taught.

So, I am skeptical, but this is the sort of thing that is likely to have an impact on software developers in the future, and it would be good for practitioners to work on it.

From the swebok website

Excerpt from the Foreward:

The list of proposed Knowledge Areas in the Straw Man version based on ISO/IEC 12207 is: The list of proposed Knowledge Areas in the Straw Man version that do not converge well with ISO/IEC 12207 is:

IMHO This is a total waste of effort and cash. I am a software engineer with nearly two decades of experience behind me and I can't even agree with these people on the definition of Generally Accepted. If this most basic phrase causes dissension, what hope do they have of agreeing anything else?

There is no Medical body of knowledge project, or structural architecture body of knowledge, so why do we need one for SoftwareEngineering?

Perhaps "we" need an equivalent of the medical "residency", or the architectural equivalent of internship to improve the knowledge to a level of certifiable practice. We see in Medicine, Architecture and Engineering the use of "models", "patterns", "standards" and "practices". These are found useful for guidance and discipline, and can be thoughtfully combined as components in a "body of knowledge"

Two answers: (1) There are BoK for other engineering areas. (2) There are other people who want it.

Perhaps, but the fact that the IEEE and ACM are the two driving bodies behind this thing gives me the willies. Aren't these two organizations the Little Old Ladies of the software engineering world?

If this most basic phrase causes dissension, what hope do they have of agreeing anything else?

If they are persistent enough, the otherwise sane participants will drop out of the effort (witness the ACM withdrawal mentioned above), leaving a de facto concensus. HaHaOnlySerious.

There is no software engineering, but, maybe, someday, there will be. SoftwareBlueprints. -- BobBockholt

When it was started ACM was associated with it through the so called "Software Engineering Coordinating Committee", but later on, ACM withdrew it's support for such activities (http://www.acm.org/serving/se_policy/report.html), so now with only IEEE to back it up the SWEBOK effort lost most of its practical chances to become a widely accepted standard.

I have my doubts that this can be seriously considered to be a body of knowledge. A body of standard opinion and popular misconceptions, possibly. Consider the fact that the word "overtime" appears nowhere in the text, or the following quotes:

Consensus does not equate to knowledge, and even that there is such a thing as a "software engineering discipline" is still subject to dispute.

SWEBOK was discussed on SlashDot here:

http://slashdot.org/article.pl?sid=01/11/22/0110249&mode=nested

-- PaulChisholm

The above posting expresses an unfounded fear that the art of programming can be threatened by the science of programming. I do not believe it is an either/or situation. One can approach programming from either end, depending to a large degree on the application. The programming of robots on an automotive assembly line while seemingly scientific, is in a large part an "art". The distinction between the two has to do with how many ways a job can be done. The more possibilities, the more "art" comes into play. When physical laws and principles are involved, the programming is more a science. Example: a falling body, subject to the pull of gravity is less a "art" and more a "science" since the rules and processes are based on a scientific certainty.

If it combines art and science, then it's a craft, which I've always thought was a pretty good way to describe programming. -- MarcThibault

Comment on the concern expressed in the link above: There is a distinction between SoftwareEngineering and Programming. The concern that a engineering discipline could emerge from this work is highly likely. (Note: The SWEBOK is being developed in connection with the IEEE, an engineering society) Due to the legal ramifications of the combination of software in engineered devices such as those used in manufacturing, and the fact that liabilities are imposed on those who produce defective or dangerous products, the certification of design, (including software employed in the manufacturing of the product eventually reaching the market) is not just a possible development, but certainly a legally necessary one.

Here is a listing of 4 Categories and 14 Knowledge Areas:

Category 1 Services and Services Systems 

 01  Principle of Services
 02  Services Lifecycle
Category 2 Services Technologies 
 03  Web Services
 04  Service-Oriented Architecture
 05  Services Relationships 
 06  Services Composition  
 07  Business Process Management & Integration
Category 3 Services Consulting and Delivery 
 08  Business Grid and Cloud Computing
 09  Enterprise Modeling Management 
 10  Service-Oriented Consulting Methodology
 11  Services Delivery Platform and Methodology
Category 4 Services Solutioning and Management 
 12  Application Services and Standards
 13  Security, Privacy, and Trust in Services Computing 
 14  Services Management

Some interesting distinctions:

Topics

Related

Dated News

CategoryProfessionalism

EditText of this page (last edited October 31, 2011) or FindPage with title or text search