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.

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.

SubjectSubchapters
1Software RequirementsSoftware Requirements FundamentalsRequirements ProcessRequirements ElicitationRequirements AnalysisRequirements SpecificationsRequirements ValidationPractical ConsiderationsSoftware Requirements Tools
2Software DesignSoftware Design FundamentalsDesign Key IssuesSW Structure & ArchitectureUser Interface DesignDesign Quality Analysis & EvaluationSW Design NotationsPractical ConsiderationsSoftware Requirements Tools
3Software ConstructionSoftware ConstructionManaging ConstructionPractical ConsiderationConstruction TechnologiesSW Construction Tools
4Software TestingSoftware Testing FundamentalsTest LevelsTest TechniquesTest-Related MeasuresTest ProcessSW Testing Tools
5Software MaintenanceSoftware Maintenance FundamentalsKey Issues in SW MaintenanceMaintenance ProcessRequirements AnalysisTechniques for MaintenanceSoftware Maintenance Tools
6Software Configuration ManagementManagement of Configuration ProcessConfiguration IdentificationConfiguration ControlSW Configuration Status AccountingConfiguration AuditingSW Release Management & DeliverySoftware Configuration Management Requirements Tools
7Software Engineering ManagementInitiation & Scope DefinitionProject PlanningProject EnactmentReview & EvaluationClosureSW Engineering MeasurementSoftware Engineering Management Tools
8Software Engineering ProcessSoftware Process DefinitionSoftware Life CyclesProcess Assessment & ImprovementSoftware MeasurementSoftware Engineering Process Tools
SubjectSubchapters
9Software Engineering Models and MethodsModelingTypes of ModelsAnalysis of ModelsSoftware Engineering Methods
10Software QualitySoftware Quality FundamentalsSoftware Quality Management ProcessPractical ConsiderationsSoftware Quality Tools
11Software Engineering Professional PracticeProfessionalismGroup Dynamics & PsychologyCommunication Skills
12Software Engineering EconomicsSW Engineering Economics FundamentalsLife Cycle EconomicsRisk & UncertaintyEconomic Analysis MethodsPractical Considerations
13Computing FoundationsProblem 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
14Mathematical FoundationsSets, Relation & FunctionsProof TechniquesGraphs & TreesFinite States MachinesNumerical Precision, Accuracy & ErrorsAlgebraic StructuresBasic LogicBasics of CountingDiscrete ProbabilityGrammarsNumber Theory
15Engineering FoundationsEmpirical 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.

— ADVERTISMENT—

Advertise Here

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.

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.

— ADVERTISMENT—

Advertise Here

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


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

 
 
Note: We’ve made the October 2017 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.

Become a Sponsor
+ 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.