Software Engineering s Body of Knowledge

Software Engineering's Body of Knowledge

In Chapter 4, I argued that software engineering is not the same as computer science, but if it isn't computer science, what is it? Those of us working in software development now have an exciting opportunity to see a new field being born. For more established fields like mathematics, physics, and psychology, we tend to take the contents of the field for granted, assuming that the definition of what is in and what is out of the field has always been the way it is and has to be that way. But at some point people working in each field developed textbooks and university curriculums that required them to decide what knowledge was in and what was out. For hundreds of years, people didn't differentiate between mathematics, physics, psychology, and philosophy. Mathematics began to be treated as separate from philosophy about 300 A.D.. Physics began to be treated as separate from philosophy about 1600. Psychology wasn't distinguished from philosophy until about 1900.

In defining what knowledge is in and what is out of the field of software engineering, experts have recommended that the focus should be on generally accepted knowledge and practices. As Figure 5-3 suggests, "generally accepted" refers to the knowledge and practices that are applicable to most projects most of the time practices that most experts would agree are valuable and useful. Generally accepted does not mean that the knowledge and practices should be applied uniformly to all projects. Project leaders will still be responsible for determining the most appropriate practices for any particular project.^[9]

Figure 5-3. Categories of possible knowledge in the software engineering body of knowledge. The focus of defining the knowledge needed by a professional software engineer is on generally accepted knowledge.

Source: Adapted from "Professionalism of Software Engineering: Next Steps"^[10]

Since 1968, we've made significant progress in the areas Brooks referred to as the "essential difficulties" of software development. We now have adequate or good reference books on requirements engineering, design, construction, testing, reviews, quality assurance, software project management, algorithms, and user interface design, just to name a few topics. New and better books that codify software engineering knowledge are appearing regularly. Some core elements have not yet been brought together in practical textbooks or courses, and in that sense our body of knowledge is still under construction. But the basic knowledge about how to perform each of these practices is available in journal articles, conference papers, and seminars as well as books. (These books are listed on the software engineering professional Web site described at the back of the book.) The pioneers of software engineering have already blazed the trails and surveyed the land. Now the software engineering settlers need to build the roads and develop the rest of the education and accreditation infrastructure.

Researchers at the Université du Québec à Montréal have spearheaded an effort to identify the generally accepted elements of software engineering. This effort has been coordinated by the ACM and the IEEE Computer Society and involves both academic and industrial participants. This effort is called the Software Engineering Body of Knowledge project, or SWEBOK.^[11]

As Figure 5-4 suggests, software engineering draws from computer science, mathematics, cognitive sciences (psychology and sociology), project management, and various engineering disciplines.

Figure 5-4. Sources of knowledge in software engineering's body of knowledge.

Source: Adapted from "Professionalism of Software Engineering: Next Steps"^[13]

From this starting point, SWEBOK has identified knowledge areas that make up the core competencies for a professional software engineer.^[12]

• Software Requirements. The discovery, documentation, and analysis of the functions to be implemented in software.

• Software Design. Definition of the basic structure of the system at the architectural and detailed levels, division into modules, definition of interfaces for modules, and choice of algorithms within modules.

• Software Construction. Implementation of the software including detailed design, coding, debugging, unit testing, technical reviews, and performance optimization. This area overlaps somewhat with Software Design and Software Testing.

• Software Testing. All activities associated with executing software to detect defects and evaluate features. Testing includes test planning, test case design, and specific kinds of tests including development tests, unit tests, component tests, integration tests, system tests, regression tests, stress tests, and acceptance tests.

• Software Maintenance. Revision and enhancement of existing software, related documentation, and tests.

• Software Configuration Management. Identification, documentation, and change control of all intellectual property generated on a software project including source code, content (graphics, sound, text, and video), requirements, designs, test materials, estimates, plans, and user documentation.

• Software Quality. All activities associated with providing confidence that a software item conforms or will conform to technical requirements. Quality engineering includes quality assurance planning, quality measurement, reliability, testing, technical reviews, audits, and verification and validation.

• Software Engineering Management. Planning, tracking, and controlling of a software project, software work, or a software organization.

• Software Engineering Tools and Methods. Tool and methodology support, such as CASE tools, reusable code libraries, and formal methods, including practices for adopting and disseminating tools and methods within an organization.

• Software Engineering Process. Activities related to improving software development quality, timeliness, productivity, and other project and product characteristics.

The extent of this list might surprise some people. Many practicing programmers work as though software construction is the only knowledge area that matters. As important as that area is, it is only one of ten areas that a professional software engineer should know.

Other practicing programmers might be surprised at the complete absence of specific languages and programming environments Java, C++, Visual Basic, Linux, and so on. That's because the body of knowledge emphasizes software engineering principles rather than technology knowledge.

A few people's reaction to these knowledge areas will be, "That's a lot to expect someone to learn just to write computer programs." It is a lot to expect someone to learn, and historically we've been expecting them to learn it implicitly, through on-the-job exposure to new information. The result is that most practicing computer programmers have pretty good knowledge of Software Construction and Software Maintenance; marginal knowledge of Software Requirements, Software Design, Software Testing, and Software Engineering Tools and Methods; and virtually no knowledge of Software Configuration Management, Software Quality, Software Engineering Management, or Software Engineering Process.

I don't expect software engineers to achieve mastery in each of these areas, but a professional software engineer should at least acquire introductory knowledge of all areas, competence in most, and mastery of some. As I described in Chapter 4, one of the differences between a scientist and an engineer is that scientists can afford to have knowledge that is narrow and deep, but engineers need a broad understanding of all the factors that affect the products they create.