APPENDIX B

EVOLUTION OF THE
GUIDE TO THE SOFTWARE ENGINEERING BODY OF KNOWLEDGE

INTRODUCTION

Although the 2004 Guide to the Software Engineering Body of Knowledge is a milestone in reaching a broad agreement on the content of the software engineering discipline, it is not the end of the process. The 2004 Guide is simply the current edition of a guide that will continue evolving to meet the needs of the software engineering community. Planning for evolution is not yet complete, but a tentative outline of the process is provided in this section. As of this writing, this process has been endorsed by the project’s Industrial Advisory Board and briefed to the Board of Governors of the IEEE Computer Society, but is not yet either funded or implemented.

STAKEHOLDERS

Widespread adoption of the SWEBOK Guide has produced a substantial community of stakeholders in addition to the Computer Society itself. There are a number of projects—both inside and outside the Computer Society—that are coordinating their content with the content of the SWEBOK Guide. (More about that in a moment.) Several corporations, including some of the members of the project’s Industrial Advisory Board, have adopted the Guide for use in their internal programs for education and training. In a broader sense, the software engineering practitioner community, professional development community, and education community pay attention to the SWEBOK Guide to help define the scope of their efforts. A notable stakeholder group is the holders of the IEEE Computer Society’s certification—Certified Software Development Professional—because the scope of the CSDP examination is largely aligned with the scope of the SWEBOK Guide.

The IEEE Computer Society and other organizations are now conducting a number of projects that depend on the evolution of the SWEBOK Guide:

• The CSDP examination, initially developed in parallel with the SWEBOK Guide, will evolve to a close match to the Guide—both in scope¹ and reference material.

• The Computer Society’s Distance Learning curriculum for software engineers will have the same scope as the SWEBOK Guide. An initial overview course is already available.

• Although the goals of undergraduate education differ somewhat from those of professional development, the joint ACM/IEEE-CS project to develop an undergraduate software engineering curriculum is largely reconciled with the scope of the SWEBOK Guide.

• The IEEE-CS Software Engineering Standards Committee (SESC) has organized its collection by the Knowledge Areas of the SWEBOK Guide, and the IEEE Standards Association has already published a CD-ROM collected edition of software engineering standards that reflects that organization.

• ISO/IEC JTC1/SC7, the international standards organization for software and systems engineering, is adopting the SWEBOK Guide as ISO/IEC Technical Report 19759 and harmonizing its collection with that of IEEE.

• The IEEE Computer Society Press, in cooperation with SESC, is developing a book series based on software engineering standards and the SWEBOK Guide.

• The Computer Society’s Software Engineering Portal (“SE Online”), currently in planning, will be organized by the Knowledge Areas of the SWEBOK Guide.

• The Trial Use Version of the SWEBOK Guide was translated into Japanese. It is anticipated that the 2004 Version will also be translated into Japanese, Chinese, and possibly other languages.

THE EVOLUTION PROCESS

Obviously, a product with this much uptake must be evolved in an open, consultative, deliberate, and transparent fashion so that other projects can successfully coordinate efforts. The currently planned strategy is to evolve the SWEBOK Guide using a “time-boxed” approach. The time-box approach is selected because it allows the SWEBOK Guide and coordinating projects to perform revision in anticipation of a fixed date for convergence. The initial time box is currently planned to be four years in duration.

At the beginning of the time box, in consultation with coordinating projects, an overall plan for the four-year revision would be determined. During the first year, structural changes to the SWEBOK Guide (e.g., changes in number or scope of Knowledge Areas) would be determined. During the second and third years, the selection and treatment of topics within the Knowledge Areas would be revised. During the fourth year, the text of the Knowledge Area descriptions would be revised and up-to-date references would be selected.

The overall project would be managed by a Computer Society committee of volunteers and representatives of coordinating projects. The committee would be responsible to set overall plans, coordinate with stakeholders, and recommend approval of the final revision. The committee would be advised by a SWEBOK Advisory Committee (SWAC) composed of organizational adopters of the SWEBOK Guide. The SWAC would also be the focus for obtaining corporate financial support for the evolution of the SWEBOK Guide. Past corporate financial support has allowed us to make the SWEBOK Guide available for free on a Web site. Future support will allow us to continue the practice for future editions.

Notionally, each of the four years would include a cycle of workshop, drafting, balloting, and ballot resolution. A yearly cycle might involve the following activities:

• A workshop, organized as a part of a major conference, would specify issues for treatment during the coming year, prioritize the issues, recommend approaches for dealing with them, and nominate drafters to implement the approaches.

• Each drafter would write or modify a Knowledge Area description using the approach recommended by the workshop and available references. In the final year of the cycle, drafters would recommend specific up-to-date references for citation in the SWEBOK Guide. Drafters would also be responsible for modifying their drafts in response to comments from balloters.

• Each annual cycle would include balloting on the revisions to the Knowledge Area descriptions. Balloters would review the drafted Knowledge Area descriptions and the recommended references, provide comments, and vote approval on the revisions. Balloting would be open to members of the Computer Society and other qualified participants. (Nonmembers would have to pay a fee to defray the expense of balloting.) Holders of the CSDP would be particularly welcome as members of the balloting group or as volunteers in other roles.

• A Ballot Resolution Committee would be selected by the Managing Committee to serve as intermediaries between the drafters and the balloters. Its job is to determine consensus for changes requested by the balloting group and to ensure that the drafters implement the needed changes. In some cases, the Ballot Resolution Committee may phrase questions for the balloting group and use their answers to guide the revision of the draft. Each year’s goal is to achieve  consensus among the balloting group on the new and revised draft Knowledge Areas and to gain a vote of approval from the balloters. Although the SWEBOK Guide would not be changed until the end of the time box, the approved material from each year’s cycle will be made freely available.

At the conclusion of the time box, the completed product, SWEBOK Guide 2008, would be reviewed and approved by the Computer Society Board of Governors for publication. If continuing corporate financial support can be obtained, the product would be made freely available on a Web site.

ANTICIPATED CHANGES

It is important to note that the SWEBOK Guide is inherently a conservative document for several reasons. First, it limits itself to knowledge characteristic of software engineering; so information from related disciplines—even disciplines applied by software engineers—is omitted. Second, it is developed and approved by a consensus process, so it can only record information for which broad agreement can be obtained. Third, knowledge regarded as specialized to specific domains is excluded. Finally and most importantly, the Guide records only the knowledge which is “generally accepted.” Even current and valid techniques may need some time to gain general acceptance within the community.

This conservative approach is apparent in the current SWEBOK Guide. After six years of work, it still has the same ten Knowledge Areas. One might ask if that selection of Knowledge Areas will ever be changed. The plan for evolution includes some criteria for adding a Knowledge Area or changing the scope of a Knowledge Area. In principle, the candidate must be widely recognized inside and outside the software engineering community as representing a distinct area of knowledge and the generally accepted knowledge within the proposed area must be sufficiently detailed and complete to merit treatment similar to those currently in the SWEBOK Guide. In operational terms, it must be possible to cleanly decouple the proposed Knowledge Area from the existing ones, and that decoupling must add significant value to the overall taxonomy of knowledge provided by the Guide. However, simply being a “cross-cutting” topic is not justification for separate treatment because separation, in many cases, simply compounds the problem of topic overlap. In general, growth in the total number of Knowledge Areas is to be avoided when it complicates the efforts of readers to find desired information.

Adding a topic to a Knowledge Area is easier. In principle, it must be mature (or, at least, rapidly reaching maturity) and generally accepted.² Evidence for general acceptance can be found in many places, including software engineering curricula, software engineering standards, and widely used textbooks. Of course, topics must be suitable to the SWEBOK Guide’s design point of a bachelor’s degree plus four years of experience.³

That design point raises the issue of the volume of material referenced by the SWEBOK Guide. The total amount of material should be consistent with the design point of a bachelor’s degree plus four years of experience. Currently, the editorial team estimates an appropriate amount to be 5000 pages of textbook material. During the evolution of the Guide, it will be necessary to manage the lists of cited material so that references are currently accessible, provide appropriate coverage of the Knowledge Areas, and total to a reasonable amount of material.

A final topic is the role to be played by users of the SWEBOK Guide in its evolution. The Editorial Team believes that continual public comment is the fuel that will drive the evolution of the SWEBOK Guide. Public comments will raise issues for treatment by the annual workshop, hence setting the agenda for revision of the SWEBOK Guide. We hope to provide a public, online forum for comment by any member of the software engineering community and to serve as a focal point for adoption activities.

1. The CSDP adds one Knowledge Area, Business Practices and Engineering Economics, to the ten Knowledge Areas covered by the SWEBOK Guide.

2. For the definition of “generally accepted,” we use IEEE Std 1490-1998, Adoption of PMI Standard—A Guide to the Project Management Body of Knowledge: “Generally accepted means that the knowledge and practices described are applicable to most projects most of the time, and that there is widespread consensus about their value and usefulness. It does not mean that the knowledge and practices should be applied uniformly to all projects without considering whether they are appropriate.”

3. Of course, this particular specification is stated in terms relevant to the US. In other countries, it might be stated differently.