Software Quality Management

Software Quality Management

10.1 Why Quality Management Matters

10.1.1 Quality, Cost, and Time — The Triple Constraints

Quality management is one of the three important factors of software engineering. Those three factors are the triple constraints — quality, cost, and time — which people often summarize as "good, fast, and cheap." The rule of thumb is that you can choose any two at full strength, but the third pays the price:

• Good and fast, but not cheap. You bring in more engineers, better tools, and more testing time, and the budget grows.
• Fast and cheap, but not good. You skip reviews and cut testing to hit the date, and the delivered software is full of defects.
• Good and cheap, but not fast. You keep the team small and the budget tight, so the schedule stretches.

Think of the Venn diagrams of these three constraints and their intersections: the diagram is three overlapping circles. Any pair of circles overlaps in a region where two constraints are satisfied, but the region where all three overlap is a tiny sliver in the middle — it is always challenging to achieve all three simultaneously. Delivering a high-quality product on time and within budget has always been the central challenge of software engineering, and that is exactly what software engineering is about — you need to deliver good quality products on time and within budget, where "good product" means quality products.

10.1.2 What Quality Management Means

Three things that statement contains deserve attention:

• Meets the needs of its users — the software must do the right things for the people who actually use it, not just what the contract literally says.
• Performs efficiently and reliably — it must behave well in normal use and keep working without failures.
• Delivered on time and within budget — a "perfect" product that arrives a year late and twice the agreed price has failed a real constraint.

The use of quality management techniques together with new software technologies and testing methods has led to significant improvements in product quality over the past two to three decades. This is an honest industry-wide observation: quality did not improve by accident or by luck — it improved because organizations deliberately invested in defined quality processes, better tools, and better testing.

Formalized software quality management, especially in plan-driven processes such as the waterfall model, is particularly important for teams that develop large, long-lifetime systems that take several years to build. These systems are developed for external clients and usually use a plan-based process — a sequence of defined phases, each completed before the next begins. For such systems, quality management is an organizational issue as well as an individual project issue: the organization must own the framework, and each project must apply it.

10.1.3 Organizational-Level Quality Management

For a plan-based project — a large, long-lifetime project — there are three principal concerns in quality management. The first is the organizational level. Here a quality management team, led by a quality head, a chief quality officer, or a quality manager, is concerned with establishing a framework of organizational processes and standards that will lead to high-quality software.

Concretely, the quality management team at this level should:

• Take responsibility for defining the software development process to be used across the organization.
• Define the standards that should apply to the software and its related documentation, including the system requirements, the design, the code, and so on.
• Keep that framework alive — reviewing it and updating it as technologies and methods change.

The organizational level answers "how do we want every project in this company to produce software?" It is deliberately broad, because the same framework is shared by many projects.

10.1.4 Project-Level Quality Management

The second and third concerns sit at the project level and have two aspects.

Aspect 1 — apply the quality processes. The first aspect is the application of specific quality processes: checking that the planned processes are being followed and ensuring that the project outputs meet the defined project standards — in other words, checking whether quality processes are being followed. This is the day-to-day enforcement of the organizational framework on one project.

Aspect 2 — write the project quality plan. The second aspect is defining a quality plan for the project. Even while following a standard process, a project needs its own quality plan because it sets out the goals for the project and defines which processes and standards are to be used for that specific project. Organizational plans, standards, and goals may be very broad and may not apply directly at the project level.

So at the project level, depending on project factors — budget and time constraints, the capability of the people, the nature of the product, and the nature and experience of the team — we get a project-specific quality plan. A small web prototype and a five-year banking core system will not share the same quality plan even inside the same organization. Quality management includes having the plan, agreeing to the plan, and checking that everything has been done correctly.

10.2 Quality Assurance and Quality Control

10.2.1 Roots in Manufacturing: QA versus QC

Software quality management techniques have their roots in the methods and techniques developed in the manufacturing industry, where the terms quality assurance and quality control are widely used. In organizations you will often hear "software quality assurance" (SQA) and "quality control" as part of quality management, but quality control is typically part of manufacturing quality terminology. The words sound similar, but they describe two different jobs — one builds the machinery of quality, the other operates it on the production line.

A simple way to hold the two apart: quality assurance sets the rules; quality control applies the rules to remove the bad output. In a toy factory, QA would be "we define how a safe toy is designed and how the assembly line must run," while QC would be "we inspect the finished toys and throw out the ones with loose parts." The same logic transfers to software: QA defines the development and review standards, and QC checks the actual outputs — the documents, the code, the builds — and rejects those that do not meet the required level.

Even within the software industry the meaning of SQA varies by company. Some companies see software quality assurance as the definition of procedures, processes, and standards that ensure software quality is achieved. In other companies, quality assurance also includes verification and validation activities, and all configuration management activities applied after a product has been handed over by the development team. In other words, the exact boundary of "SQA" is a company decision — but the core idea of defining quality processes and standards is shared.

10.2.2 Quality Management as an Independent Check

Notice the double check hidden in that paragraph. The team asks two different questions:

1. Is the product right? — do the deliverables (documents, designs, code) match the organizational standards and goals?
2. Is the process effective? — is the process that produced them actually capable of producing the right product quality?

If a process routinely produces documents that fail review, the problem is not just the documents — the process itself needs fixing. An independent team is in a position to say that out loud, because it does not share the development team's pressure to declare everything on track.

10.2.3 Deliverables, Reviews, and Process Documentation

In a software development process there are deliverables — call them D1, D2, D3, D4, D5 — such as requirements elicitation, user requirements, system requirements, high-level design, detailed design, coding, and so on. You must have a quality plan right at the beginning. But before that, your standards, processes, and procedures for quality management are defined. Based on these, you create a quality plan specific to the project, depending on the project factors, the constraints (budget, time, and even quality), the type of product, and the kind of resources.

After each and every deliverable you conduct a quality review, which results in quality review reports. The quality management processes run in parallel with the software development process, with a review after every deliverable to ensure that the processes are being followed, the standards are being followed, and the product and the processes are of acceptable quality.

The quality management team also checks the process documentation, which records the tasks that have been completed by each team working on the project. The team uses this documentation to check that important tasks have not been forgotten and that one group has not made incorrect assumptions about what other groups have done. Example: if the design team assumed the database team would handle performance tuning, but no one recorded that handover, the process documentation reveals the gap before it becomes a late-project surprise.

10.2.4 Release and System Testing under Quality Management

In large companies, the quality management team is usually responsible for managing the release testing process — the testing of the software before it is released to customers, which appears earlier in the study of software testing. In addition, the quality management team is responsible for checking that the system testing tests provide coverage of the requirements and that proper records of the testing processes are maintained.

Two responsibilities are worth underlining:

• Requirement coverage: the system tests must map back to the requirements, so the team verifies that nothing in the requirements specification is untested.
• Test records: the team checks that the testing was actually carried out and recorded properly — a passing test with no record is, from the quality point of view, a test that did not happen.

10.2.5 Independence and Reporting Line

Ideally, the quality management team should be independent of the development team and not part of the software development group, so that it can take an objective view of the quality of the software. It should have organization-wide responsibility for quality management and should report to a management level above the project manager level.

The reporting line is the mechanism that makes independence real. A project manager's success metric is delivering on time and on budget; if the quality manager reports to that same manager, any quality verdict that threatens the schedule can be quietly overruled. Reporting above the project manager level means the quality voice cannot be silenced by the schedule.

Real-world: cutting testing to save time is a common pressure in real projects; the whole point of an independent quality manager reporting above the project manager is to resist it. In small companies and agile teams the same people do development and quality, so the independence is an ideal that has to be balanced against what is practically possible.

10.3 Quality Planning

10.3.1 What a Quality Plan Must Contain

Formalized quality planning is an integral part of the plan-based development process. Quality planning is done once the standards and procedures are defined. The quality plan should set out the desired qualities and describe how these qualities are to be assessed. In other words, it defines what high-quality software actually means for a particular system, so that the engineers have a shared understanding of the most important quality attributes.

Why does the plan matter if the organization already has standards? Because "high quality" is not one fixed thing — a banking system and a mobile game are both "software," but they prioritize completely different qualities. The quality plan is where the project decides what quality means for this system, which processes to use, and which attributes matter most.

The quality plan should describe which organizational standards should be applied, define new standards if required, and define the quality assessment process, the desired product qualities to be assessed, and the most significant quality attributes.

10.3.2 Typical Quality Plan Outline

A typical quality plan follows this outline — five sections that together cover the product, the schedule, the process, the goals, and the risks:

• Product introduction — a description of the product, its intended market, and the quality expectations for the product. This is the "what are we building and how good must it be" section.
• Product plans — the critical release dates and responsibilities for the product, along with plans for distribution and product servicing. This ties quality to the calendar: what must be ready by each release date, and who owns it.
• Process descriptions — the development and services process standards to be used for product development and management, described in detail. This is the "how will we build it" section: which standards apply, which tools, which reviews.
• Quality goals — the quality goals and plans for the product, including the identification and justification of the critical product quality attributes. Here the project states which attributes matter most and defends the choice.
• Risk and risk management — a quality plan is incomplete without this: list all the risks that will affect product quality and the actions to be taken to mitigate these risks. Example risks: key developer leaves mid-project, the client changes requirements late, the chosen third-party component is withdrawn — each with a mitigation action.

10.3.3 Keeping Quality Plans Short and Simple

Quality plans, developed as part of the general project planning process, may differ in detail depending on the size and type of the system being developed. But when writing quality plans you should try to keep them as short and simple as possible. If the document is too long and complicated, people may not read it, which defeats the purpose of producing the quality plan in the first place.

10.3.4 Does a Good Process Guarantee a Good Product?

The contrast between the two worlds is the heart of this section. In manufacturing, the process largely determines the product, because machines execute it repeatedly. In software, the process is executed by people making creative judgments, so the same process can produce very different products depending on the team, the individuals, and the pressure of the moment. A good process improves your odds — it does not guarantee the outcome.

A related point: traditional quality management is a formal process that relies on maintaining extensive documentation about testing, system validation, and how processes have been followed. In this respect it is diametrically opposed to agile development, where the aim is to spend as little time as possible writing documents and formalizing how development work should be done.

The point is not that one is right and the other wrong: quality management techniques had to evolve with agile methods — agile quality management is based on developing a team quality culture rather than on a standardized process, which we come to later.

10.4 Software Quality versus Manufacturing Quality

10.4.1 The Manufacturing View: Conformance with Tolerance

The fundamentals of quality management were established in the manufacturing industry in Japan, especially in the drive to improve the quality of manufactured products. As part of that effort, the manufacturing industry developed a definition of quality based on conformance with the detailed product specification. The underlying assumption was that the product should be completely specified, and that procedures could be established to check the manufactured product against its specification.

Of course, even precision-manufactured products never exactly meet the specification, so some tolerance is allowed. If the product is almost right, it is classified as acceptable.

10.4.2 Why Software Cannot Be Judged the Same Way

Software quality is not comparable with quality in manufacturing. The idea of tolerances applies to manufactured systems but does not apply to software, and it is impossible to reach an objective conclusion about whether a software system meets its specification.

The rejection of the tolerance analogy is not a minor detail — it changes the whole job of quality management. Three reasons stand behind it:

1. Software specifications cannot be complete and unambiguous. "Usable," "user friendly," "good to look at" — these cannot be written as measurable tolerances. Developers and customers can interpret the same requirement differently, so "conforms to specification" cannot even be agreed on.
2. Specifications are compromises between conflicting stakeholders. Different stakeholder groups want different things; whatever gets written leaves someone out, and those excluded stakeholders will judge the system as poor quality even though it implements the agreed requirements.
3. Key quality characteristics cannot be measured directly. You cannot measure "maintainability" with a gauge the way you measure a bolt. If you cannot measure it, you cannot specify a tolerance for it.

10.4.3 Fitness for Purpose Instead of Conformance

Because of these problems, the assessment of software quality is a subjective process — unlike manufacturing, where you can check conformance to specifications. The quality management team has to use judgment to decide whether an acceptable level of quality has been achieved. They decide whether the software is fit for its purpose rather than checking whether it conforms to its specifications.

To check fitness for purpose, the quality management team asks questions about the system's characteristics:

• Has the system been properly tested, and has it been shown that all the requirements have been implemented properly and correctly?
• Is the software sufficiently reliable, dependable, and safe to be put into use?
• Is the performance of the software acceptable for normal use?
• Is the software usable by the concerned end users and stakeholders?
• Is the software well structured and understandable, and so maintainable?
• Have the programming and documentation standards been followed in the development process?

These are the questions to ask whenever you check the quality of a product before it is released, either to the customer or to the release testing team.

10.4.4 Judging Quality from Test Results

There is a general assumption in software quality management that the system will be tested against its requirements, and that the judgment on whether it delivers the required functionality should be based on the results of these tests during system testing. The quality management team should so review the tests that have been developed for acceptance testing and examine the test records to check that the testing has been carried out properly.

In some companies, the quality management group itself carries out the final system testing. In other companies, an independent testing team does the system testing or release testing and reports to the quality manager.

A follow-up question pushed one level deeper: who actually does the testing that these judgments are based on?

The two class answers show the range of real-world practice: the fitness-for-purpose questions are genuinely asked before release, but who does the final testing varies — the quality group, a dedicated independent testing team, or developers alongside a separate group.

10.5 Quality Attributes and McCall's Quality Factors

10.5.1 Non-Functional Characteristics Drive Subjective Quality

The subjective quality of a software system is largely based on its non-functional characteristics. From the study of requirements engineering, we distinguish functional requirements — the functionality or services provided by the system — from non-functional requirements, which are behavioral properties or emergent properties of the system observed only when the complete system is in execution: performance, usability, reliability, maintenance, and so on.

Where does the analogy break? A car's mileage is a measurable number with a standard test procedure, while most software non-functional qualities (reliability, maintainability) are only observed over time and judged subjectively. The shared point, though, is the emergent nature: these properties are not visible in parts, only in the whole running system.

These emergent, non-functional properties are largely observed through practical user experience. Here the professor made a sharp observation about how users react:

• If the software's functionality is not what is expected, users might often just work around the inefficiency and find other ways to do what they want — they click around, use a keyboard shortcut, or use a workaround path.
• But if the software is unreliable or too slow, it is practically impossible for them to use it for the required purpose. There is no workaround for "the app crashes" or "the page takes a minute to load."

Software quality, so, is not just about whether the functionality has been correctly implemented — it also depends on the non-functional system attributes.

10.5.2 The Four Core Attributes

Notice that none of the four is a functional requirement. A system can implement every requested function and still be a poor product if it is undependable, hard to use, slow, or impossible to change. This is why the four core attributes appear at the center of any quality discussion.

10.5.3 McCall's Fifteen Quality Factors

Some of these attributes are classified under the quality factors described by a software scientist named McCall. McCall's quality factors are 15 factors shown as part of three different arms of a triangle:

• Safety
• Security
• Reliability
• Resilience
• Robustness
• Understandability
• Testability
• Adaptability
• Modernity
• Complexity
• Portability
• Usability
• Reusability
• Efficiency
• Learnability

            Understandability
              /            \
             /   Modernity   \
            /       Complexity \
           /                    \
   Safety/___________ ____________\Usability
   Security            |            Portability
   Reliability         |            Reusability
   Resilience        Learnability   Efficiency
   Robustness          |            Adaptability
   Testability         |

These factors cannot be measured directly; they have to be measured indirectly through various internal attribute measurements, which we see later. For example, you cannot measure "usability" with a gauge — but you can measure proxy quantities: time to complete a task, number of wrong clicks, number of support calls. The indirect measurements are evidence from which the factor is judged.

10.5.4 Prioritizing Attributes in the Quality Plan

It is not possible for any system to be optimized for all of these attributes. For example, improving security may lead to a loss of performance. The quality plan should so define the most important quality attributes for the software being developed. It may be that efficiency is critical and other factors must be sacrificed to achieve it — and if the quality plan emphasizes the importance of efficiency, the engineers working on the development can work together to achieve it.

The quality plan should also include a definition of the quality assessment process: an agreed way of assessing whether some quality such as maintainability, robustness, or usability is present in the product. You must choose only the most important quality attributes, prioritize what should be assessed, and agree on the way to assess each one.

10.6 Process-Based Quality and Its Limits in Software

10.6.1 The Manufacturing Process Loop

Traditional manufacturing quality management is based on the assumption that the product's quality is directly linked to the process quality. This assumption comes from manufacturing systems, where product quality is intimately related to the production process. The manufacturing process involves configuring, setting up, and operating the machines involved in the process. Once the machines are operating correctly, product quality naturally follows. You can measure the quality of the product and fine-tune or change the process until you achieve the level of quality you need. This is called the process-based approach to quality.

The loop works like this:

1. Define the manufacturing process.
2. Use that process to develop the product.
3. Check the product's quality — whether it conforms to its specification.
4. If the quality is okay, standardize the process and run it for subsequent production lots.
5. If the quality is not okay (not within accepted tolerance limits), improve the process, calibrate it, develop the product once again, and check the quality again.
6. Repeat until the quality is okay; then standardize the process and allow it to produce more products.

In manufacturing there is a clear link between process quality and product quality, because it is relatively easy to standardize the manufacturing process and monitor it. Once manufacturing systems are calibrated, they can be run again and again to output high-quality products at the same quality levels.

10.6.2 Why Software Does Not Follow the Loop

Software is designed — it is a creative effort rather than a manufactured product — and the relationship between process quality and product quality is more complex. Software design is a creative process where the influence of individual skills and experience is very significant. External factors such as the novelty of an application or commercial pressure for an early product release may also affect product quality, irrespective of the process used.

The difference is the actor that executes the process. A bottling machine has no bad days, no mood, no new ideas; it runs the calibrated process exactly. A software engineer brings skill, judgment, and creativity — which is exactly why software quality varies with the people even when the process is identical.

10.6.3 Do Deadlines and Budget Pressure Affect Quality?

The honest answer the class reached: external factors do influence quality. Testing is elaborate, time-consuming, and expensive; a tight deadline with no budget simply removes the testing the product needs. This is why the reporting-line argument from topic 10.2 matters — someone must be able to say "we need the time and budget to do this properly."

10.6.4 What Still Holds: Process Quality and Fewer Defects

The development process used has a significant influence on the quality of software, and good processes are more likely to lead to good-quality software. Process quality management and process improvement can result in fewer defects in the software being developed.

But there are real limits. It is difficult to assess software quality attributes such as reliability without using the software for a long period of time, so it is hard to tell how process characteristics influence these attributes. Also, because of the role of design and creativity in the software process, process standardization can sometimes stifle creativity, which may lead to poorer rather than better quality software.

The two limits in one sentence each: reliability is only observable over long use, so you cannot quickly prove a process produces it; and standardization fights creativity, the very source of software quality.

10.6.5 Team Quality Culture

The quality manager should also aim to develop a team quality culture, in which everyone is responsible for achieving a higher level of product quality, and should encourage teams to take responsibility for the quality of their work and to develop new approaches to quality improvement.

While standards and procedures are the basis of quality management in a large project, good quality managers recognize that there are many intangible aspects of software quality — the team culture, the elegance of the code, the readability of the code, the efficiency of the algorithm — that cannot be embodied in standards. They should support people who are interested in these intangible and creative aspects of quality and encourage professional behavior in all team members.

This team quality culture is exactly what agile development follows, relying on culture instead of on standards and procedures.

10.7 Software Standards: Why They Matter

10.7.1 Standards Capture Organizational Wisdom

Software standards can be international, national, organizational, or project-specific standards. They are very important for several reasons.

First, standards capture the wisdom that is of extremely significant value to the organization. They are based on knowledge of the best practices — or the most appropriate practices — for the company. This knowledge is often acquired only after a great deal of trial and error over several projects in the past. Building it into standards helps the company reuse its experience and avoid the previous mistakes. Standards encapsulate best practices and capture wisdom of value to the organization.

10.7.2 Standards Define What Quality Means

Second, standards provide a framework for defining what quality means in a particular setting. Software quality is quite subjective, and by using standards you establish a basis for deciding whether a required level of quality has been achieved. This depends on setting standards that reflect user expectations for software usability, dependability, and performance, and so on.

The connection to topic 10.5 is direct: quality factors like usability are subjective judgments, so "was the quality good enough?" needs a yardstick. The standards are that yardstick — a fixed, agreed definition of "good enough" that the quality team can check against. Without standards, every review is a personal opinion; with standards, it is a comparison.

10.7.3 Standards Give Continuity Across Teams

Third, standards assist continuity when work is carried out by different teams successively. Standards ensure that all engineers, developers, and testers within the organization adopt the same practices, so the learning effort required when starting new work is reduced. Once you have a set of standardized processes, methods, techniques, and tools, everyone knows what to use and what standards to apply. This makes it easier for new teams to take over the work from an earlier team, or from a person who moves to another team or leaves the organization.

The three reasons, in one line each:

10.7.4 The Four P's of Software Engineering

The four P's — people, product, process, and project — are the four pillars of software engineering that must be measured and managed. The class discussion placed people first, and the professor confirmed that is correct: without people there is no software. But each pillar connects to a different kind of measurement:

• People — standards and measurements belong to human resources (HR).
• Product — product standards, the subject of this lecture.
• Process — process standards, also the subject of this lecture.
• Project — project standards, which appear when you pursue PMI certification.

10.7.5 People Cannot Be Replaced by Tools

The question was not hypothetical — the class discussed whether generative AI tools change the software engineer's job. The conclusion: the tool can write code, but it cannot do the two things that start and end every project — giving the specification (requirements come from customers and stakeholders, refined by developers) and checking that the work is correct.

The class concluded that the role changes — engineers increasingly specify, guide, and verify AI-generated code — but the role does not disappear, because the requirements still come from people.

10.8 Product Standards and Process Standards

10.8.1 Two Kinds of Standards

There are two types of standards that are important in software quality management: product standards and process standards.

Product standards apply to the software product being developed. They describe what the product should be like — coding standards, document standards, the structure of documents, and so on. You need a defined and measurable product: your quality is defined and it is measurable. Without a defined and measurable product, you cannot engineer the product and you cannot check that you have achieved it.

Process standards describe how to do things — the processes to be followed during software development. They include good development practices, definitions of how the specification should be collected, how design should be done, how the verification and validation process should be done, what support tools should be used for various processes, and what documents should be written during all these processes. A systematic and quantifiable approach is the standardized process.

The two standards work as a pair: the process standard governs the journey (how the work is done), and the product standard defines the destination (what the work must look like when finished).

When to pick which: if you are defining an artifact's required form, you need a product standard; if you are defining the steps someone must follow, you need a process standard — most projects need both, because a product without a producing process and a process without a defined output are both incomplete.

10.8.2 The Health Checkup Analogy

The analogy maps cleanly onto the two standard types:

• Parameters and ranges — blood pressure, cholesterol, heart rate, each with a normal range. The range is the product standard: it defines what a healthy result looks like.
• Standard operating procedures (SOPs) — how the blood sample must be taken, how the ECG electrodes are placed, how the lab test is run. These are process standards: they define how each measurement must be done so that results are comparable and trustworthy.

Where the analogy breaks: a checkup's ranges come from medical research across millions of patients, while software standards are usually defined inside one organization from its own experience — but the two-layer structure (measured quantity + range, and the procedure that measures it) is exactly the same.

10.8.3 Examples of Product Standards

10.8.4 Examples of Process Standards

Process standards describe how to do things, such as:

• How to conduct a design review. The meeting steps, the roles, what gets recorded — the review process itself.
• How to submit new code for system building. Every day you integrate your code with the build and test, then integrate it with the build again.
• How to release a version. When you have configuration and multiple releases are produced during development, how to control the version release.
• How to approve the project plan. The project plan approval process — who signs off, in what order.
• How to control change. The change control process. Change requests keep coming: you have to measure the impact of the change, assess the cost of the change, do a cost-benefit analysis, and check the priority — is it urgent, immediate, low priority, or already done?
• How to record tests and share them with the teams. Test results are recorded in a standard way and shared, so every team reads the same record.

Standards are not something alien — they are part of your everyday work. Every build you submit, every review you attend, every form you fill is a standard in action.

10.8.5 Standards Must Pay Their Way

Standards should not be just on paper. They should deliver value in the form of increased product quality. There is no point in defining standards that are expensive in terms of time and effort to apply and that only lead to marginal improvements in quality that are hardly noticeable. Product standards have to be designed so that they can be applied and checked in a cost-effective way, and process standards should include definitions of the processes used to check whether the product standards and process standards have been followed.

10.9 Making Standards Work

10.9.1 Standards Are Often Seen as Over-Prescriptive

The software engineering standards used within a company are usually adapted from broader national or international standards. Software engineers sometimes consider standards to be over-prescriptive and irrelevant to the technical activity of software development. This is particularly likely when the project standards require tedious documentation and a lot of recording work. And if the engineers are not supported by tools, following the standards is difficult.

The root of the problem is usually not the concept of standards but the way they are imposed: too many forms, too much recording, no tool support. Engineers usually accept the general need for standards — they object to standards that do not fit their project.

10.9.2 Involve Engineers and Explain the Why

The quality manager should involve the software engineers in the selection of product standards. If developers understand why standards have been selected, they are more likely to be committed to these standards. Ideally, the standards document should not just set out the standards to be followed but should also include commentary explaining why these standardization decisions were made, so that the engineers accept that the standards are relevant to their project.

10.9.3 Keep Standards Alive and Tool-Supported

The quality manager should review the standards often and modify them regularly to reflect changing technologies, the business environment, and methodologies. Standards are expensive to develop, and they often tend to be enshrined in a company's standards handbook that nobody uses — because of the costs and elaborate discussions required, there is often reluctance to change standards once they are put into the quality or standards manual. The standards handbook is essential for the reasons given earlier — encapsulation of best practices, continuity in development, a framework for quality — but it should also evolve to reflect changing circumstances and technology.

Standards also cannot be followed without adequate tool support. The quality manager must make sure that tool support is available for standards-based development. Developers often find standards to be a problem when conformance involves very tedious manual work that a software tool could do. Automatic data collection, analysis, and reporting can be done by software tools, so if tool support is available, standards can be followed without much extra effort. For example, program layout standards can be defined and implemented by a syntax-directed program and editing system. You need tools that capture and collect data, analyze it, and provide inferences.

10.9.4 Adapt Standards to Each Project

Different types of software need different development processes, so standards have to be adaptable. There is no point in prescribing a particular way of working if it is inappropriate for the project or the project team. Each project manager should have the authority to modify the process standards according to the individual circumstances. However, when changes are made, it is important to ensure that the changes do not lead to a loss of product quality — changing standards should not suddenly reduce product quality.

The project manager and the quality manager can avoid the problems of inappropriate standards by careful quality planning early in the project. They should decide which of the organization's standards should be used without change, which should be modified, and which should be ignored. New standards may have to be created in response to customer requirements or project requirements. For example, if you are developing a real-time system, you may have to use formal specifications that include mathematical models, and standards for these may have to be developed as well if they were not used in previous projects.

10.9.5 Measuring against Standards, and What Comes Next

Standards are important in quality assurance because only when you define product standards can you measure them and assess product quality. Similarly, only when you define the process and can measure the process activities — in terms of the time taken, the resources consumed, and the frequency of occurrence of events — can you assess compliance with the processes and standards for ensuring product standards.

There are many standards-based frameworks for standards at the project level and the organizational level. One of them is the ISO 9001 standards framework, which is discussed next along with the review, walkthrough, and inspection techniques used to assess static quality. Frameworks like ISO 9000 and CMMI are part of quality management in the software industry and are widely used in organizations.

Real-world: ISO 9001 certification and CMMI maturity models are the standards frameworks you will most often meet in industry quality programs.

Exam Guidance Summary

• The mid-semester test included a question on the challenges to software engineering in this decade; naming AI tools like ChatGPT as a challenge is a strong answer — and pairing it with the counter-argument (people still give the specification and verify the work) makes it stronger.
• A second quiz is being made available, with an announcement to follow.
• Study the chapter on quality management, plus the modules on quality management in the courseware.
• Quality management is a very important topic related to the software testing topic covered before the mid-semester, and it connects to software project management.
• Next session: the ISO 9000 standards framework, review/walkthrough/inspection techniques for static quality assessment, and quality management in agile projects.
• Be ready to distinguish: quality assurance versus quality control, organizational-level versus project-level quality management, product standards versus process standards, and conformance to specification versus fitness for purpose.
• Know McCall's fifteen quality factors and the fact that they are measured indirectly through internal attribute measurements.
• Know the typical quality plan outline: product introduction, product plans, process descriptions, quality goals, and risk management.
• Remember the fitness-for-purpose questions the quality team asks before release — they are a ready-made answer for any question about how software quality is judged.
• Know why the quality manager reports above the project manager, and why small teams and agile teams cannot always keep the roles independent.

Key Industry Applications

• Real-world: ISO 9001 and ISO 9000 certification frameworks and CMMI maturity models are the standards frameworks used in industry quality programs; you will have seen them in organizations.
• Real-world: companies run software quality assurance teams and, in many cases, independent testing groups that do system testing and release testing and report to the quality manager.
• Real-world: PMI certification introduces project standards; people standards and measurements belong to HR.
• Real-world: standard operating procedures (SOPs), common in manufacturing and in medical testing, are the everyday form of process standards.
• Real-world: generative AI tools like ChatGPT can write code, but people still give the specification and verify the result — the requirements come from customers and stakeholders.
• Real-world: daily build and test integration, version release control under configuration management, and change control processes (impact measurement, cost assessment, cost-benefit analysis, priority setting) are everyday process standards in software companies.
• Real-world: Java programming style, method header formats, design review forms, and change request forms are typical product standards in industry.
• Real-world: McCall's quality factors are a classic quality model for naming and discussing software quality attributes such as safety, security, reliability, portability, and efficiency.
• Real-world: plan-driven (waterfall) projects for large, long-lifetime systems with external clients are where formalized quality management is most visible; agile teams substitute a team quality culture for heavy standardization.
• Real-world: the fitness-for-purpose questions are applied before release in real organizations, and the testing work behind the answers is shared between quality teams, independent testing groups, and developers.