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: * http://www.acm.org/serving/se_policy/selep_main.html#position. ---- 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: * In this Guide, the IEEE Computer Society establishes for the first time a baseline for the body of knowledge for the field of software engineering, and the work partially fulfills the Society's responsibility to promote the advancement of both theory and practice in this field. In so doing, the Society has been guided by the experience of disciplines with longer histories but was not bound either by their problems or their solutions. * It should be noted that the Guide does not purport to define the body of knowledge but rather to serve as a compendium and guide to the body of knowledge that has been developing and evolving over the past four decades. Furthermore, this body of knowledge is not static. The Guide must, necessarily, develop and evolve as software engineering matures. It nevertheless constitutes a valuable element of the software engineering infrastmcture. The list of proposed Knowledge Areas in the Straw Man version based on ISO/IEC 12207 is: * Development Process * Requirements Analysis * Detailed Design * Coding * Testing * Maintenance Process * Configuration Management * Quality Assurance * Verification and Validation * Improvement Process * Management Process The list of proposed Knowledge Areas in the Straw Man version that do not converge well with ISO/IEC 12207 is: * Software Development Methods * Object Oriented * Formal Methods * Prototyping * Software Development Environments * Software Engineering Overview & Definition * Measurement/Metrics * Software Reliability ---- 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: * "Eventually, a complete and coherent set of system requirements will emerge as a result of the analysis process." * "The fundamental task of software construction is to communicate intent unambiguously between two very different types of entities, people and computers." 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: * Professionals including Engineers are held accountable and sometimes sued in court, while Artists rarely are. * A programmer has a continuing interest in software created independently, in that he has intellectual property rights and copyright protection. An engineer is a salaried professional having no continual income stream as the result of work done under salary. This is somewhat different if the work is patented and the patent is personally held. (Consult a legal professional for specifics regarding copyrights and patents). ---- Topics * Artifical Intelligence * Certification * Data Management * General Interest and Reference * Graphics & Multimedia * Education * Design and Test * Hardware * Human Centered Computing * Information Technology * History of Computing * Internet/Web * Management * Mobile/Wireless * Networking and Communications * Scientific Computing * Security & Privacy * Software * Software Engineering * Standards and Best Practices * Systems Engineering Related * Topics according to Bloom Taxonomy ** http://www.computer.org/portal/web/swebok/html/appendixd ---- Dated News * 20101213 | Newsroom - Dated List of News Releases ** http://www.computer.org/portal/web/certification/news_room * 20110110 | Pace University to Prepare Software Engineers for CSDA ** http://www.computer.org/portal/web/certification/news_room#1-10-11 * 20110512 | IEEE Computer Society Debuts Software Engineering Assessment Series ** http://www.computer.org/portal/web/certification/news_room#5-12-11 * 20110927 | Veterans’ Reimbursement of IEEE Computer Society Software Development Certifications Expanded under GI Bill Provisions ** http://www.computer.org/portal/web/certification/news_room#9-27-11 ---- CategoryProfessionalism