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:
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.
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:
SWEBOK was discussed on SlashDot here:
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 LifecycleCategory 2 Services Technologies
03 Web Services 04 Service-Oriented Architecture 05 Services Relationships 06 Services Composition 07 Business Process Management & IntegrationCategory 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 MethodologyCategory 4 Services Solutioning and Management
12 Application Services and Standards 13 Security, Privacy, and Trust in Services Computing 14 Services Management
Some interesting distinctions: