Basics of Design Research & Design Hub

Improving Software Quality

Written by George Novacek

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.

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).

FIGURE 1 – Title page of the Software Engineering Body of Knowledge (SWEBOK)

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.

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.

Subject Subchapters
1 Software Requirements Software Requirements FundamentalsRequirements ProcessRequirements ElicitationRequirements AnalysisRequirements SpecificationsRequirements ValidationPractical ConsiderationsSoftware Requirements Tools
2 Software Design Software Design FundamentalsDesign Key IssuesSW Structure & ArchitectureUser Interface DesignDesign Quality Analysis & EvaluationSW Design NotationsPractical ConsiderationsSoftware Requirements Tools
3 Software Construction Software ConstructionManaging ConstructionPractical ConsiderationConstruction TechnologiesSW Construction Tools
4 Software Testing Software Testing FundamentalsTest LevelsTest TechniquesTest-Related MeasuresTest ProcessSW Testing Tools
5 Software Maintenance Software Maintenance FundamentalsKey Issues in SW MaintenanceMaintenance ProcessRequirements AnalysisTechniques for MaintenanceSoftware Maintenance Tools
6 Software Configuration Management Management of Configuration ProcessConfiguration IdentificationConfiguration ControlSW Configuration Status AccountingConfiguration AuditingSW Release Management & DeliverySoftware Configuration Management Requirements Tools
7 Software Engineering Management Initiation & Scope DefinitionProject PlanningProject EnactmentReview & EvaluationClosureSW Engineering MeasurementSoftware Engineering Management Tools
8 Software Engineering Process Software Process DefinitionSoftware Life CyclesProcess Assessment & ImprovementSoftware MeasurementSoftware Engineering Process Tools
Subject Subchapters
9 Software Engineering Models and Methods ModelingTypes of ModelsAnalysis of ModelsSoftware Engineering Methods
10 Software Quality Software Quality FundamentalsSoftware Quality Management ProcessPractical ConsiderationsSoftware Quality Tools
11 Software Engineering Professional Practice ProfessionalismGroup Dynamics & PsychologyCommunication Skills
12 Software Engineering Economics SW Engineering Economics FundamentalsLife Cycle EconomicsRisk & UncertaintyEconomic Analysis MethodsPractical Considerations
13 Computing Foundations Problem Solving TechniquesProgramming Language BasicsAlgorithms & ComplexityOperating System BasicsNetwork Communications BasicsBasic Developer Human FactorsAbstractionDebugging Tools & TechniquesBasic Concept of a SystemCompiler BasicsParallel & Distributed ComputingSecure Software Development and MaintenanceProgramming FundamentalsData Structure & RepresentationComputer OrganizationDatabase Basics & Data ManagementBasic User Human Factors
14 Mathematical Foundations Sets, Relation & FunctionsProof TechniquesGraphs & TreesFinite States MachinesNumerical Precision, Accuracy & ErrorsAlgebraic StructuresBasic LogicBasics of CountingDiscrete ProbabilityGrammarsNumber Theory
15 Engineering Foundations Empirical Methods & Experimental TechniquesStatistical AnalysisMeasurementEngineering DesignModeling, Simulation and PrototypingStandardsRoot Cause Analysis

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.

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.

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


Advertise Here

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:
Reference [1] as marked in the article can be found there.


Keep up-to-date with our FREE Weekly Newsletter!

Don't miss out on upcoming issues of Circuit Cellar.


Advertise Here

Note: We’ve made the Dec 2022 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

Would you like to write for Circuit Cellar? We are always accepting articles/posts from the technical community. Get in touch with us and let's discuss your ideas.

Sponsor this Article
+ posts

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.

Supporting Companies

Upcoming Events

Copyright © KCK Media Corp.
All Rights Reserved

Copyright © 2024 KCK Media Corp.

Improving Software Quality

by George Novacek time to read: 6 min