Toward Defining A Software Engineering Body of Knowledge

by Richard Turner, OUSD Software Intensive Systems, Dr. Iraj Hirmanpour, Dr. Soheil Khajenoori, and Dr. Thomas B. Hilburn of Embry-Riddle Aeronautical University

The focus of this paper is to report on our initial work in defining and categorizing a Software Engineering Body of Knowledge (SwE-BOK). This project was sponsored by the FAA to build a software competency model for their research and acquisition work force. Since there was no defined software engineering body of knowledge in the literature upon which to build such a model, we embarked upon the task of developing one. It is our hope that the SwE-BOK will also be usable by other competency modelers and curriculum designers.

This paper offers a view of the content, categorization, and organization of the software engineering domain that is not currently reflected in the literature. It is presented as a hierarchical structure organized into knowledge categories, knowledge areas, and knowledge units. We also offer examples of its application to competency model building and to education and training curriculum design.

Software plays an increasingly important and central role in all aspects of daily life: in government, banking and finance, education, transportation, entertainment, medicine, agriculture, and law, to name only a few. The number, size, and application domains of software programs being developed have grown dramatically. As a result, billions of dollars are being spent on software development, and the livelihood and lives of millions directly depend on the effectiveness of this development. Unfortunately, there are severe problems in the cost, timeliness, and quality of many software products. Particularly serious is the effect these problems can have on the safety-critical elements of software, which are central to many real-time embedded systems. These problems are attributed to the short history of software and immaturity of its discipline.

In recent years, there have been a number of studies and commentaries on the immaturity of the software engineering profession [9,14]. In 1996, a study of the profession by Ford and Gibbs [8] designated eight infrastructure components that could be used to evaluate a mature profession: initial professional education, accreditation, skill development, certification, licensing, professional development, a code of ethics, and a professional society. They went on to classify these components using four levels of maturity. At that time, they argued that the only component at a relatively mature level was Professional Development. If one accepts the argument that the profession is not mature, then a number of questions arise: At what stage are we in the evolution of software development as an engineering discipline? What is (or should be) the content of the profession ­ what is the body of knowledge? How should software engineers be prepared? By which means do we recognize or assure professional work?

Since 1993, the IEEE-CS and ACM have been actively promoting software engineering as a profession. Special task forces have been directed at establishing a software engineering code of ethics and professional practice [11], determining accreditation criteria for software engineering programs [4] supporting curriculum development, and preparing a guide to the software engineering body of knowledge [6]. In 1998, the IEEE-CS and the ACM formed the Software Engineering Coordinating Committee (SWECC) to foster the evolution of software engineering as a professional computing discipline and to coordinate the various software engineering "maturing" activities. In addition, there have been a number of other activities that support defining the profession: the State of Texas has begun to develop a process for the licensing of professional engineers in software engineering [3]; the Working Group on Software Engineering and Training is defining a set of guidelines that support the development of a software engineering curricula; and Lethridge [13] has completed a study and analysis of the knowledge needed and used by practicing software engineers. While the work by the IEEE-CS/ACM holds great promise for defining the software engineering body of knowledge in depth, the completion of the project is still far in the future. All of their activities, however, support and motivate the need for an organized and comprehensive definition and categorization of software engineering knowledge.

This paper reports on our attempt to define a software engineering body of knowledge. This work is part of a larger project sponsored by the Federal Aviation Administration to develop a software engineering competency model aimed toward assessing the capability of their research and acquisition work force.

In 1998, the FAA initiated a project designed to help improve the software engineering knowledge and abilities of their Office of Research and Acquisitions (ARA) personnel. The project involved the development of a software competency model for the FAA documented roles.

In order to build the model it was necessary to define and structure a SwE-BOK.

In order to get a firm grip on the problem and to keep the scope within available time and resources, we decided in advance to ignore the role of system engineering within software engineering. We also excluded any areas of knowledge that may be supportive of software engineering but do not play a direct role in software development. For example, discipline areas such as continuous mathematics, the natural sciences, traditional engineering science, psychology, economics, and business administration were not included the SwE-BOK to keep the scope within our objective.

We determined that the SwE-BOK primary purpose would be to:

• assist with the design of software engineering competency models

• aid in software engineering curriculum design,

• help develop skill assessment programs and tools,

• help with the development of competency based training programs.

In order to achieve a balance between simplicity and clarity, and the appropriate depth and detail of knowledge description, we chose three levels of abstraction to partition the software engineering body of knowledge. The three layers are named Knowledge Category (KC), Knowledge Areas (KA), and Knowledge Units (KU). We assumed that the universe of SwE-BOK can be divided into four major categories that we have named Computing Fundamentals, Software Product Engineering, Software Management, and Software Domains. Knowledge categories are; therefore, subdisciplines of software engineering that are generally recognized as representing a significant part of the body of software engineering knowledge. In our classification scheme, knowledge categories are high-level structural elements used for organizing, classifying, and describing software engineering knowledge.

Each Knowledge Category is then divided into a group of Knowledge Areas. A Knowledge Area is a subdivision of a KC that represents software knowledge that is logically cohesive and related to the KC through inheritance or aggregation. Each Knowledge Area is then decomposed into a set of Knowledge Units (KU). KUs are subdivision of a KA that represents a basic component of SwE knowledge with a crisp and explicit description. For the purposes of this activity, the KU is "atomic" (i.e., will not be subdivided into simpler or more basic elements). See Figure 1.

In summary, an aggregation of Knowledge Units creates a Knowledge Area, and similarly, an aggregation of Knowledge Areas creates a Knowledge Category. Knowledge Units are dependent on the current state of technology and change over time while KA and KC are invariant over time. For example, one of the Knowledge Units specified in the BOK is Architectural Design. The contents of such a unit will change as knowledge about architectural design increases. However, the Knowledge Area of software design and knowledge Category of Product Engineering will stay invariant.

For the purposes of this work, the term "knowledge" is used to describe the whole spectrum of content for the software engineering discipline: information, terminology, artifacts, data, roles, methods, models, procedures, techniques, practices, processes and literature. In our model, we organized software engineering knowledge into three Knowledge Categories: Computing Fundamentals, Software Product Engineering, and Software Management. Since the application domain of software has its own specific knowledge requirements, we created a fourth category called Software Domains. Although this decomposition and the corresponding descriptions encompass a significant portion of the knowledge considered part of the software engineering profession, there are particular areas related to special domains or areas on the periphery of software engineering that are not included ­ such as GUI and human factors. Some areas in this SwE-BOK have also been given more attention and focus because of the context of the project. An example is the inclusion of a description of a "software acquisition" Knowledge Area in the Software Management category.

In the following sections, each of the Knowledge Categories is described, and the Knowledge Areas that are part of each KC are detailed. It should be evident that the body of knowledge has varying levels of decomposition and exposition, depending upon the current state of knowledge in a particular component and the significance of the component to the overall description of the software engineering discipline.

Computing Fundamentals include the knowledge, concepts, theory, and skills of computing that form the foundation for the development of software and the discipline of software engineering. This category is divided into the following Knowledge Areas:

1. Algorithms and Data Structures
2. Computer Architecture
3. Mathematical Foundations
4. Operating Systems
5. Programming Languages

Software Product Engineering is concerned with a well-defined and integrated set of activities to produce correct, consistent software products effectively and efficiently. Software Product Engineering includes the technical activities of producing a software product such as requirements engineering, design, coding and testing. These engineering activities involve documenting software work products and maintaining trace ability and consistency between them. This category includes knowledge about the controlled transition between the stages of the software life cycle and the activities needed to deliver quality software products to the customer. This category is divided in to the following Knowledge Areas:

1. Software Requirements Engineering
2. Software Design
3. Software Coding
4. Software Testing
5. Software Operation and Maintenance

Software Management deals with the concepts, methods and techniques for managing the development or acquisition of software products. Software management includes activities concerned with project management, with management of risk, with the configuration of a software system, and with knowledge about how to produce high-quality software. This category is divided into the following Knowledge Areas:

1. Software Project Management
2. Software Risk Management
3. Software Quality Management
4. Software Configuration Management
5. Software Process Management
6. Software Acquisition

The Software Domains category concerns knowledge about specific domains that involve the application and utilization of software engineering knowledge from the other categories. In this context, a software domain represents an area of knowledge that has two features: its technical content is required in the development of a particular type of software; and it represents a significant field of knowledge, with an established organization and content, that is documented by research and application. This category is divided into the following Knowledge Areas:

1. Artificial Intelligence
2. Database Systems
3. Human-Computer Interaction
4. Numerical and Symbolic Computing
5. Computer Simulation
6. Real-Time Systems

The four categories of SwE-BOK are thus decomposed into the 22 Knowledge Areas listed. These areas are then further subdivided into 64 Knowledge Units. For brevity, we do not list all the 64 Knowledge Units. However, for a more detailed description of Knowledge Areas and Knowledge Units the reader is referred to http://computing.db.erau.edu/SEERS which contains the latest work in this area.

The SwE-BOK can be used for a variety of purposes: it can help to solve problems and address issues in industrial and academic settings. Most importantly, it can serve as a general model for understanding and describing the software engineering profession. Such an understanding is essential to the maturing of a discipline and is a necessary step in determining the professional standards and procedures required for the effective practice of software engineering. In this spirit, the SwE-BOK could be used to develop criteria and assessment instruments for the certification and licensing of software engineers. In addition, the SwE-BOK could be used by individual engineers to assess their own knowledge about the software engineering profession and provide a framework for them to plan for their professional development.

In this section we discuss two ways that the SwE-BOK could be applied: to help develop a competency model for an industrial software organization and to design a software engineering curricula for an academic environment.

In an industrial setting, the SwE-BOK can help organizations to examine, categorize, and organize their software activities and identify the knowledge levels required to carry out their specific software tasks. Organizations that want to assess the knowledge of their engineers could, for example, use the SwE-BOK in designing a competency evaluation system. Such a competency system could use the SwE-BOK to help identify and judge what kind of software engineering knowledge is required to accomplish the tasks associated with individual software-related roles. An assessment of this nature might also be coupled by using the SwE-BOK to design training programs and develop an overall strategy to improve an organization's software capabilities.

A competency model should provide a framework for identifying the required competencies of a successful work force. A competency model was developed as a part of the FAA project. The competency model identifies software roles, software activities related to the role, and maps the role's activities according to the knowledge components, from the SwE-BOK, that are required to carry out the activities.

In an academic setting, the SwE-BOK can provide faculty with the basic information about software engineering knowledge, to support the development of educational curricula in software engineering. In addition, the SwE-BOK can support the creation of a set of more general guidelines for the development and accreditation of software engineering programs by groups such as ABET (Accreditation Board for Engineering and Technology) and CSAB (Computer Science Accreditation Board). The SwE-BOK can provide the foundation for such development and can serve as a framework for curriculum design.

The Knowledge Categories and Knowledge Areas could serve as high-level curriculum components, while the Knowledge Units could serve as the basis for detailed module and course design. Table 1 illustrates how the SwE-BOK can be used to guide and structure a high-level curriculum design for an undergraduate program in software engineering. (In this example we are assuming that the objective of the curriculum is to produce software engineers prepared to develop software for real-time, embedded systems.)

Each of the SwE-BOK Knowledge Categories and Knowledge Areas are listed in Column 1 of the table (for completeness, non-software components are also listed). Column 2 indicates the depth of knowledge required for each of the components (we use three knowledge depth levels: Awareness, Understanding, and Execution). Inclusion of the metric compels curriculum designers to be more careful and thoughtful about design decisions. Column 3 provides semester hour credits associated with the various components; this provides high-level constraints on the future course and module development.

Unfortunately, the current state of software engineering experience and knowledge in academia is in short supply. The curriculum example in Table 1 illustrates how the SwE-BOK can be helpful, especially for faculty without a strong software engineering background, for the design and development of a software engineering curriculum.

There is a need for a defined software engineering body of knowledge, in particular, to provide the basis for the following activities:

• design of competency and skill assessment programs and tools,

• development of competency based training programs, and

• software engineering curriculum design.

The structure and organization of the body of knowledge described in this paper allows for both high level and detailed level design of software engineering curriculum. The knowledge categories and knowledge areas can serve as a guideline to structure the curriculum and knowledge units can provide the necessary detail to design the course contents. We believe base-lining and cataloguing the current body of knowledge will help advance the state of software engineering both as a discipline and as a profession.

Dr. Thomas B. Hilburn received his Ph.D. in Mathematics from Louisiana Tech University in 1973. Prior to that he served in the US Navy where he taught courses in computer programming, and inertial and satellite navigation; he completed an electronics program at the Navy Postgraduate School in Monterey California; and he served a tour in Vietnam as the Officer-In-Charge of the APL-5 . He joined the mathematics faculty at Embry-Riddle Aeronautical University in 1973 and since 1989 has served as a Professor of Computer Science. His current interests include software engineering, formal methods, individual and team software processes, and computer science and software engineering education. He has worked with the MITRE Corporation on a problem involving the analysis of airspace complexity and has presented special short courses on Ada and software engineering at General Electric-Daytona Beach, Martin Marrietta-Daytona Beach, and the National Civil Air Training Organization in Cairo, Egypt. In 1996-1997 he spent a year as a visiting scientist at the Software Engineering Institute, Carnegie Mellon University.

Dr. Iraj Hirmanpour has over 30 years leadership experience in education and industry consulting, an established record as a strategic thinker, a team-based manager, and a people motivator. He successfully re-engineered three different departments over the course of his academic career. As an academic researcher working with industry he lead development of the Operations Maturity Model (OMM) for Andersen Consulting, development of the Software Engineering Body of Knowledge (SoW-BOK) for FAA published as an Software Engineering Institute (SEI) Technical Report, and the development of a Software Engineering Competency Model published as an FAA Technical Report. He has also worked on the Process Improvement Body of Knowledge published as an SEI Technical Report. Research and consulting is in process improvement using improvement models such as the Capability Maturity Model (CMM), Personal Software Process (PSP), and Team Software Process (TSP) from the SEI. He has published and presented extensively on software engineering and information technology subjects.

Dr. Khajenoori has been Project Lead on fifteen research projects and has published a number of articles on software engineering subjects including CASE, software development methodologies (Structured and Object-Oriented methods), software metrics, and software process engineering and improvements. He is currently teaching courses on Personal Software Process, Software Requirements Engineering and Software Design, as a part of the MSE program. For the past three years he has been closely working with Software Engineering Institute (SEI), Watts Humphrey and Iraj Hirmanpour on implementation of Personal Software Process (PSP) and Team Software Process Paradigms.

Author Contact Information
Dr. Thomas Hilburn Dept. of Computing & Mathematics Embry-Riddle Aeronautical Univ. 600 Clyde Morris Boulevard Daytona Beach, FL 32114 (904) 226-6889, Fax: (904) 226-6678 [email protected] http://faculty.db.erau.edu/hilburn/	Dr. Iraj Hirmanpour, Department Chair Dept. of Computing & Mathematics Embry-Riddle Aeronautical Univ. 600 Clyde Morris Boulevard Daytona Beach, FL 32114 (904) 226-6691, Fax: (904) 226-6678 [email protected] http://faculty.db.erau.edu/iraj/
Dr. Soheil Khajenoori Masters of Software Engineering Embry-Riddle Aeronautical Univ. 600 Clyde Morris Boulevard Daytona Beach, FL 32114 (904) 226-7036, Fax: (904) 226-6678 [email protected] http://computing.db.erau.edu/ourteam/home_pages/soheil/	Richard Turner OUSD(AT&L)/ARA/SIS 1931 Jefferson Davis Highway Crystal Mall-3, Suite 104 Arlington, VA 22202 (703) 602-0851-x124, Fax: (703) 602-3560 [email protected]

---