SwE BOK Development

Software Engineering Body of Knowledge (SwE BOK)	Back to WOSE Home Page

The Joint IEEE and ACM Software Engineering Coordinating Committee professes that "achieving consensus by the profession on a core body of knowledge is crucial for the evolution of software development practices into a professional engineering discipline."
Efforts to date The Joint IEEE ACM committee spearheads and coordinates many on going efforts to achieve this consensus. They have published Guide to the Software Engineering Body of Knowledge (SWEBOK) and have developed a SWEBOK, Version 0.7 (Stone Man version) (PDF) A group of faculty at Embry Riddle Aeronautical University (ERAU) have provided an excellent catalogue of all the SwE BOK development initiatives. ERAU has developed and published a SwE BOK which is one of the more stable version of SwE BOK available currently. A preliminary data base version of this SwE BOK is also available. MS Access file Despite earnest efforts to collect, categorize, disseminate, and apply the software engineering body of knowledge (SwE BOK), the success have been limited.		Challenges facing the current SwE BOK development approach: Mostly researchers and not practitioners conduct the SwE BOK development process. SwE BOK development process is human intensive and lacks automated support. Most practitioners do not have easy access to a published SwE BOK. Those who have access can not use it effectively because of the format in which it is organized and published. Practitioners find it difficult to contribute to the SwE BOK. SwE BOK Development is made more difficult by some issues inherent with the software development discipline

A scrutiny of Current Processes

Generally, a group of researchers and/or practitioners collaborate to develop a straw man SwE BOK from their experiences and insights. This process involves activities like developing taxonomy of the knowledge components, conducting literature survey, observing the practitioners and collecting data on actual projects. Once they have developed a straw man SwE BOK, they solicit community agreement (usually through a defined community process) and develop a "mostly agreed" SwE BOK. This SwE BOK is then published either on the Web or in a scholarly journal.

We have observed that the activities involved in collection and categorization of various SwE BOK development efforts have so far been very much human dependent. They lacked any type of automated support except in the areas like document editing and sharing. The lack of automated support augmented by usually a limited number of research personnel contributes to the delay in reporting the collected knowledge. By the time the researchers have developed a straw man SwE BOK, the listed concepts may become outdated. Consequently the community disagrees with the reported knowledge when it is brought to their attention. Like the proverbial dog chasing its tail the "mostly agreed" SwE BOK is always behind the pragmatic application of the knowledge.

Although the primary beneficiary of a generally accepted SwE BOK are developers working in the "trenches," for the most part, efforts to develop a software engineering BOK have been limited to the academia and the research division of very large organizations. The results are published in journals or academic web sites or used for intra-company training. They do not reach the core audience. An enthusiastic practitioner may stumble upon one of these BOKs but she will have to comb through large and complex document for information relevant to the task at hand. The process is not that appealing to some one hard pressed to meet the deadlines. Although, it is conceivable that the presentation of the BOKs in some structured form (database) will enable one to apply filtering or querying mechanism to get quicker access to the relevant information, however, in practice we have not seen a similar initiative. Also, this improvement will only help someone who is aware of the SwE BOK and have access to it.

While the SwE BOK could benefit immensely from the participation of a large group of practicing software developers, the cumbersome community process in place to contribute to the development of SwE BOKs will deter all but the highly enthusiastic developers.

Idiosyncrasies of Software Development

High growth discipline:In recent years we have seen an exponential growth of software in number, complexity and pervasiveness. Software development tools contributed to the increased productivity, abstract interfaces contributed to the increased complexity (for example, compilers are built on the abstraction of the assemblers) and Internet and the embedded chips in consumer goods to the pervasiveness. This self-propagating nature of software makes it likely that its growth will continue at an increasing rate and with the growth BOK remains ever changing.

A discipline plagued with ambiguity: Similar to any other emerging discipline we do not yet have an agreed upon vocabulary of software engineering. We have an abundance of synonyms (multiple terms referring to the same concept) and homonyms (multiple concepts referred to by a single term) in SwE. A good example of this situation would be the endless debate on object-oriented concepts [Qasem, 1994] until the emergence and eventual acceptance of UML.

"Soft" discipline: The "softness" of the software discipline makes it very difficult to apply engineering principles to its development. The problem is two folds. On the one hand by freeing us from the constraints of nature virtual world encourages creative leaps without systematic forethought (development before requirement!). On the other hand, we are deprived of the intuitive wisdom that that we have gained over thousands of years of interacting with the natural world in our problem solving efforts in this less than a century old virtual world.

Applied discipline: Most of the knowledge in this discipline is gained through practice. As a result the more sought-after knowledge is almost always in the mind of the experts and the gurus and not documented in seminal textbooks.

Highly intellectual discipline: The high level of intellectual activity involved combined with the malleability of software makes its development process unique among other mass-produced and engineered products. Therefore, all the data related to the activities that contribute to the final form of software are not only relevant but also crucial to the future success of other software projects. Unfortunately, once a piece of software is put under configuration management, much of the historical process data are either lost or stored in semi-accessible archives. The critical knowledge gained from doing a good job or the lessons learned from a failure resides in the cold storage of old archives or in the minds of the people who were involved in the projects.

Software Engineering Body of Knowledge (SwE BOK)