EVOLUTION OF THE
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.
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:
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:
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.
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.2 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.3
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.