By the Book
There’s no doubt that achieving high software quality is a human-driven endeavor. No amount of automated code development can substitute for best practices. A great tool for such efforts is the IEEE Computer Society’s Guide to the Software Engineering Body of Knowledge. In this article, George discusses some highlights of this resource, and why he has frequently consulted this document when preparing development plans.
— ADVERTISMENT—
—Advertise Here—
It has been demonstrated over and over again that software quality depends 100% on human activity. Nothing else. There is no wear out, aging or some other mechanism affecting software quality and performance. While many errors can be avoided by automating repetitive tasks, ultimately it is the lone, hard working software engineer who bears responsibility for the quality of the result.
As systems grow ever more complex, the task of competent software engineering practice is getting harder and harder. Experts agree that the only method for bringing software quality under control lies in following strict design guidelines. There’s a vast body of knowledge of different topics a competent software engineer needs to grasp. In recognition of that the Institute of Electrical and Electronics Engineers’ (IEEE) Computer Society issued the Guide to the Software Engineering Body of Knowledge. The common abbreviation of the title is SWEBOK, now in version 3 (Figure 1).
The SWEBOK is an exhaustive compilation of software engineering knowledge but it is not a cookbook. It identifies the multitude of topics software engineers are likely to encounter in the course of software development and points them in the right direction to find solutions. The document begins with top level characterization of the fundamental issues, then continues drilling down to more and more specific matters. Whether a professional software designer or a hobbyist, your familiarity with this document (available for free [1]) can only benefit you and your organization. The SWEBOK’s 355 pages limit me to just a top-level overview, but I cannot recommend any stronger that you download and familiarize yourself with it.
— ADVERTISMENT—
—Advertise Here—
A RICH RESOURCE
The SWEBOK is a comprehensive overview of the entire software development process. It comprises fifteen chapters, each addressing a major topic. Every chapter is subdivided into subchapters, sections, paragraphs and so forth to identify potential issues and where to find their solutions. Table 1 shows the SWEBOK table of contents—limited to the subchapter level in this case.
I have frequently consulted this document when preparing development plans and check lists to make sure that all the pertinent issues have been addressed for the project implementation. This is not to suggest that everything listed in the SWEBOK must be a part of every design or a responsibility of every design engineer. A design of a simple embedded controller may not require the engineer’s familiarity with some sophisticated mathematical processes. Not all engineers need to get involved in management issues, group dynamics or economic considerations. Each project is unique and different.
No SWEBOK topic can be taken in isolation. All the relevant issues, when applicable for the particular project, are related to each other. Therefore, you must make sure the requirements listed in each chapter are consistent across the entire project. This comes under consideration especially during project planning. Project managers must select issues relevant to the project development and prepare a suite of plans to which members of the development team will be held to conform.
— ADVERTISMENT—
—Advertise Here—
One notable feature of SWEBOK—in contrast to the numerous software development documents I’ve studied—is that it addresses software security in terms of its development as well as the operation.
Our industry does not always use very intuitive names, so it occasionally takes a little effort to figure out what a specific title means. Take Chapter 1, for example. There are eight topics identified, all related to the requirements. The eight sub-topics the SWEBOK authors want us to address are the requirements fundamentals, the requirements process, the requirements elicitation, analysis, the requirements specifications, requirements validation, practical considerations and tools selection. The topic meanings may be a little perplexing, but the following subchapters explain it all. While the entire Chapter 1 is focused on the software specification globally, the subchapters define the detail requirements, providing the necessary explanations and helping us not to omit anything important. Let’s consider just a few selected items to get the idea of what it’s all about.
SOME SELECTED TOPICS
It is acknowledged that software projects are critically vulnerable when the requirements-related activities are performed poorly. It has been established that with modern software development tools the majority of “bugs” can be ascribed to a deficient specification. With that in mind, a high-quality Software Requirements document fully defines the needs and constraints placed on a software product to solve a real-world problem. Breaking down the high-level requirements into specific activities as described in the subsections ensures nothing falls through the cracks.
Subsection 1 of the SWEBOK lists Software Requirements Fundamentals. What exactly are they? To understand, they are further broken down into six paragraphs:
- 1. Definition of a Software Requirement
- 2. Product and Process Requirement
- 3. Functional and Non-functional Requirements
- 4. Emergent Properties
- 5. Quantifiable Requirements
- 6. System Requirements and Software Requirements
Paragraph 5 is called Quantifiable Requirements. It means that every software requirement must be stated explicitly, quantitatively, as clearly as possible, with no ambiguities left to interpretation. Vague and unverifiable requirements or those opened to interpretation or subjective judgment, such as “the software shall be reliable” are unacceptable. Instead, you must explicitly state that, for instance, that the probability of the software containing an error shall be less than 1×10-9. (How we establish that is another topic.) Or, instead of calling for a “short propagation delay”, the response time needs to be stated in seconds and verifiable by test.
Consider also Chapter 5, Software Maintenance. It has five subchapters. Subsection 2 addresses Key Issues in Software Maintenance and contains four paragraphs:
- 1. Technical Issues
- 2. Management Issues
- 3. Maintenance Cost Estimation
- 4. Software Maintenance Measurement
Paragraph 3 is a nasty one. To a large degree its successful implementation relies on your experience. There are projects where software maintenance is not required and therefore its cost per Paragraph 3 is no issue. However, the absence of such a requirement must be confirmed, so there is no ambiguity about who pays if a fix is needed. Paragraph 4 helps to identify, analyze and develop measures to be eventually applied to the correction process should future maintenance be a part of the contract. The cost of the effort and the resources to be expended to diagnose the deficiencies or the cause of a failure can only be estimated—same for the cost of potential requalification. The measure of stability is a crucial economic consideration. It encompasses the probability of encountering unexpected behavior as well as the corrective action’s testability, verification and validation. These issues, while very difficult to predict, are sometimes underestimated or ignored during project planning. Unfortunately, they seem to have the tendency to come back and bite us.
It has not been my intention to review the SWEBOK in detail. My goal was to draw your attention to this excellent document, because it can help you and your organization to improve the quality of your software.
For detailed article references and additional resources go to:
www.circuitcellar.com/article-materials
Reference [1] as marked in the article can be found there.
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • APRIL 2019 #345 – Get a PDF of the Issue
Sponsor this Article
George Novacek was a retired president of an aerospace company. He was a professional engineer with degrees in Automation and Cybernetics. George’s dissertation project was a design of a portable ECG (electrocardiograph) with wireless interface. George has contributed articles to Circuit Cellar since 1999, penning over 120 articles over the years. George passed away in January 2019. But we are grateful to be able to share with you several articles he left with us to be published.
