SE423 · Software Project Management · Chapter 06

Quality isn't inspected in.
It's engineered in, then verified.

Picture a factory floor. Quality Assurance is the engineer who designs the assembly line so defects rarely happen in the first place. Quality Control is the inspector standing at the end of the line, checking what came out. Both jobs matter — but only one of them can actually prevent the fire, the other one just catches it. This chapter is the PM-process view of quality: how you plan it, assure it, control it, and prove it happened with numbers.

QA vs QC, once and for all

Why projects really succeed

Metrics, measures & measurement

PM-process view, not testing-focused

§ 01 — QUALITY BASICS

What "software quality" actually means

A definition of quality should emphasize three points — and testing is only one tool for checking whether you hit them.

📐

Memory hook

"Written, Formal, Implied."

The three things quality is measured against: (1) explicit requirements — lack of conformance is lack of quality. (2) specified standards that guide how the software is engineered — skip them and quality almost certainly suffers. (3) implicit requirements that often go unmentioned (e.g. good maintainability) — meet the explicit spec but miss these, and quality is still suspect.

1️⃣

Explicit requirements

The foundation quality is measured from. If the software doesn't conform to what was asked for, that's a lack of quality, full stop.

2️⃣

Specified standards

Development criteria that guide how software is engineered. Ignore the criteria and lack of quality will almost surely follow.

3️⃣

Implicit requirements

Unmentioned expectations like maintainability. Conforming to the spec but missing these still makes quality suspect.

Software Testing

full-life-cycle assessment

The purpose of testing is to assess and evaluate the quality of work performed at each step of the development process. Its goal is to ensure the software performs as intended, and to improve quality, reliability, and maintainability.

What testing is NOT for

Although it sometimes feels that way, testing is not there to soak up whatever budget or schedule is left over at the end of a development effort.

The exact framing to remember

"Software testing is a full-life-cycle assessment of quality." — it happens throughout, not just at the end.

Quality and Testing

testing measures, it doesn't deliver

A good development process, tools, methods, and people go far in providing quality products. Testing is one aspect of assuring software quality — it is a measure of quality, it does not deliver quality.

The line to remember: "Quality cannot be tested into a product."

Software Quality Assurance includes

SE process improvement Fault-tolerant design V&V (incl. testing)

What each piece is for

Process improvement — prevent the insertion of defects.
Fault-tolerant design — tolerate the existence of defects.
V&V — all aspects of verification & validation, including testing.

§ 02 — THE CORE DISTINCTION

Quality Assurance vs. Quality Control

Every PM exam loves this pair. Lock it in before anything else in this chapter.

🛡️

Memory hook

"QA builds the guardrails. QC checks the road."

QA is the framework of activities and standards that makes good work possible in the first place. QC is the ongoing monitoring that checks whether the actual results comply with those standards, correcting problems as they appear.

Perform Quality Assurance

The framework, applied continuously

Provides the framework of activities and standards for performing quality control. QA activities strive to ensure: (1) few, if any, defects remain in the software system when it is delivered, and (2) any remaining defects will cause minimal disruptions or damages.

Perform Quality Control

Monitoring specific results, throughout the project

Concerned with monitoring specific project results for compliance with quality standards. Performed throughout the project — and may also include taking control actions to correct the causes of quality problems.

One-line test for exam questions: if the question is about setting up the standards and the process that will be followed → QA. If the question is about checking a specific deliverable against those standards right now → QC.

§ 03 — PLANNING QUALITY & THE SQA GROUP

Deciding what "good" means before you build anything

Planning Quality

inputs to consider

Five things need to be considered while planning quality: Scope, Stakeholders, Risks, Internal and External Environmental Factors, and Process. Out of this, project-specific standards and procedures are created.

What those standards must satisfy

Based on quality standards for each deliverable · includes how the PM activities themselves should be done · plans/project must comply with external standards (CISG, ISO 9000, OSHA, etc.) · must comply with organizational standards · must meet the customer's quality standards · tracking/proof may be needed (metrics, measurements, etc.)

The three "must comply with" layers

External standards Organizational standards Customer's standards

Think of it as three concentric rings — the project has to satisfy all three at once, not just pick the easiest one.

The SQA Group

who enforces the framework

The group should prepare an SQA plan for the project. That plan identifies:

Evaluations

To be performed across the project.

Audits & reviews

To be performed on the work.

Applicable standards

Which standards apply to this project.

Error reporting

Procedures for reporting & tracking.

Change management

Procedures for managing change.

SQA documents

What the group itself must produce.

Feedback amount

How much feedback goes to the project team.

What the SQA group actually does

Participates in developing the project's software process description · reviews SE activities to verify compliance with the defined process · audits designated work products to verify compliance · ensures deviations in software work/work products are documented and handled per a documented procedure · records any noncompliance and reports it to senior management.

Chain of accountability

Reviews process → Audits work products → Documents deviations → Reports noncompliance to senior management. The SQA group is the enforcement arm, not just an advisory one.

§ 04 — PROJECT SUCCESS: THE SOFT SKILLS

Discipline, restraint, and knowing when to stop over-processing

Think Small

Keep requirements tight & focused · one milestone at a time · smaller, incremental chunks · as simple as possible, but no simpler.

Process Spectrum

"Too much medicine can kill the patient." Process lives on a spectrum between Chaos and Bureaucracy — balance is crucial. Too little process invites chaos; too much strangles delivery.

🧊

Memory hook

"Paralysis has two flavors: too much thinking, or fear of thinking at all."

Analysis Paralysis — over-process, nothing gets finished. 65% of software professionals have experienced this. Paralysis Paranoia — the opposite over-correction: fear of over-process, which itself becomes process avoidance.

Be Disciplined & Professional

Learn to say "No" — be polite but firm · the value of versions ("we'll put that in phase 2") · an ounce of prevention (is worth a pound of cure).

MBWA — Management By Walk About

Shows you're actually involved day-to-day · recognizes individuals may say more 1-on-1 · allows spontaneity · finds personnel problems sooner.

Delegate

Don't be a "control freak." You need to be the hub — but not everything running through you.

Project Home Page

Give your project an intranet page — a central repository for status, documents, and other resources.

Success Metrics

4 candidates, 1 real answer

The four things people measure

1. On schedule — requires good plan, estimation, control.
2. Within budget — again: planning, estimation & control.
3. According to requirements — importance of good requirements; perception & negotiation are critical.
4. High quality — may or may not be the same as item 3.

The only real measure

Is the customer happy? Customer satisfaction is the only real measure of success — schedule, budget, and requirements are all proxies for it.

§ 05 — WHY PROJECTS SUCCEED OR FAIL

The factors, the evidence, and the satire

To identify a project's success potential you'd look at metrics like project size, project duration, and project team size. But the deeper factors are consistent across studies.

🧩

Chunking mnemonic

"People set the Scope, Process gets it Done."

The nine success factors chunk cleanly into three groups of three: People, Scope, and Process. Executive support is factor #1 — it's called out separately because everything else depends on it.

People

Executive support
User involvement
Experienced project manager

Scope

Clear business objectives
Minimized scope
Firm basic requirements

Process

Standard software infrastructure
Formal methodology
Reliable estimates

Why executive support matters most: top management can secure adequate resources, get approval for unique project needs in a timely manner, generate cooperation from people throughout the organization, and provide leadership guidance.

State of the Practice in Software Management

social factors + technology

Two categories of factors influence success or failure: Social Factors and Technology.

Technology — Unsuccessful projects	Technology — Successful projects
No historical software measurement data	Accurate software measurement
Failure to use automated estimating tool	Early use of estimating tools
Failure to use automated planning tool	Continuous use of planning tool
Failure to monitor progress or milestones	Formal progress reporting
Failure to use effective architecture	Formal architecture planning
Failure to use effective development methods	Formal development methods
Failure to use design reviews	Formal design reviews
Failure to use code inspections	Formal code inspections
Failure to include formal risk management	Formal risk management
Informal, inadequate testing	Formal testing methods
Manual design and specification	Automated design and specification / automated configuration control
More than 30% creep in user requirements	Less than 10% creep in requirements

Social — Unsuccessful projects	Social — Successful projects
Excessive schedule pressure	Realistic schedule pressure
Executive rejection of estimates	Executive understanding of estimates
Severe friction with clients	Cooperation with clients
Divisive corporate politics	Congruent management goals
Poor team communications	Excellent team communications
Naïve senior executives	Experienced senior executives
Project management malpractice	Capable project management
Unqualified technical staff	Capable technical staff
Generalists used for critical tasks (QA, testing, planning, estimating)	Specialists used for critical tasks (QA, testing, planning, estimating)

How To Ensure a Project Fails

the satirical checklist

Straight from the slides — read every line as sarcasm, then do the opposite.

Do the same things you did on the last project, over and over · don't listen to your experts, "the last project worked out okay (mostly)" · don't measure progress with metrics — the only thing that counts is "did you meet the delivery date?" · set delivery dates with the customer but not with the developers, because "developers can meet any schedule we ask for" · don't use new tools, keep using the ones from ten or twenty years ago · spend your time making sure people do it your way · let office politics and vendettas matter more than the project.

§ 06 — MEASUREMENT AND METRICS

Turning "largely qualitative" into something you can compare

"Not everything that can be counted counts, and not everything that counts can be counted." — Albert Einstein

Software measurement is concerned with deriving a quantitative (numeric) value for an attribute of a software product or process that is largely qualitative. This allows objective comparisons between techniques and processes. Although some companies have introduced measurement programs, systematic use of measurement is still uncommon — and there are few standards in this area.

📏

Memory hook — three easily-confused words

"Measure is the number. Measurement is the act. Metric is the standard."

These three sound interchangeable but are formally distinct — see the table below.

Term	Formal meaning
Measure	Provides a quantitative indication of the size of some product or process attribute.
Measurement	The act of obtaining a measure.
Metric	A quantitative measure of the degree to which a system, component, or process possesses a given attribute.

Software Metric

any measurement of the system, process, or docs

Any type of measurement relating to a software system, process, or related documentation — e.g. lines of code in a program, or number of person-days required to develop a component. Metrics allow the software and the software process to be quantified; they may be used to predict product attributes or to control the software process.

Project Metrics

inputs, outputs, results

A software team uses project metrics to adapt project workflow and technical activities — avoiding schedule delays, mitigating potential risks, and assessing product quality on an ongoing basis.

Every project should measure its inputs (resources), outputs (deliverables), and results (effectiveness of deliverables).

Metrics Assumptions

A software property can be measured · a relationship exists between what we can measure and what we want to know · that relationship has been formalized and validated · but it may be difficult to relate what can be measured to desirable quality attributes.

Integrating Metrics With Process

Many software developers don't collect measures. Without measurement, it's impossible to determine whether a process is improving. Baseline metrics data should come from a large, representative sample of past projects — but getting that historic data is very difficult if previous developers didn't collect it on an ongoing basis.

The Measurement Process

part of quality control

A software measurement process may be part of a quality control process. Data collected during it should be maintained as an organizational resource. Once a measurement database has been established, comparisons across projects become possible.

STEP 1

Choose measurements to be made

STEP 2

Select components to be assessed

STEP 3

Measure component characteristics

STEP 4

Identify anomalous measurements

STEP 5

Analyse anomalous components

Feeds back into choosing what to measure next — this is a cycle, not a one-shot list.

Data Collection

A metrics program should be based on a set of product and process data. Data should be collected immediately (not in retrospect) and, if possible, automatically. Three types of automatic data collection: static product analysis, dynamic product analysis, process data collation.

Data Accuracy

Don't collect unnecessary data — decide the questions to be answered in advance, and identify the required data. Tell people why the data is being collected — it should not be part of personnel evaluation. Don't rely on memory — collect data when it is generated, not after a project has finished.

What are metrics for, in one loop: Software process → produces Software product, and feeds → Control measurements → Predictor measurements → inform Management decisions → which loop back into the Software process.

Analysis is hard: it is not always obvious what data means — analyzing collected data is genuinely difficult. Professional statisticians should be consulted if available, and data analysis must take local circumstances into account.

🧮

Memory hook

"Some Fine Web Products."

Size-oriented · Function-oriented · Web Engineering · Product metrics — the four metric-type buckets, with examples below.

Metric type	Examples
Size-oriented	Defects, human effort, Lines of Code (LOC)
Function-oriented	Function points
Web Engineering	Number of static web pages (N_sp), number of dynamic web pages (N_dp), Customization Index: `C = Nsp / (Ndp + Nsp)`
Product metrics	Cyclomatic complexity, fan-in / fan-out

§ 07 — CHEAT SHEET

The whole chapter, one table at a time

Concept	Core idea
Quality (definition)	Conformance to explicit requirements + specified standards + implicit (unwritten) requirements.
Testing	Full-life-cycle assessment of quality — measures quality, doesn't deliver it.
Quality Assurance	Framework of activities/standards for performing QC; prevention + fault-tolerant design + all V&V.
Quality Control	Monitoring specific results for compliance; performed throughout; may include corrective actions.
Planning Quality	Considers Scope, Stakeholders, Risks, Environmental Factors, Process; must satisfy external + org + customer standards.
SQA Group	Writes the SQA plan, audits work products, reviews process compliance, reports noncompliance up the chain.
Project success (real measure)	Customer satisfaction — schedule/budget/requirements are proxies, not the goal itself.
Top success factor	Executive support (secures resources, approvals, cooperation, leadership).
Measure / Measurement / Metric	The number / the act of obtaining it / the standardized quantitative comparison.
Process metrics	Private (individual) vs. public (organizational); never used to evaluate individuals.
Product metrics	Dynamic (execution — efficiency/reliability) vs. static (representation — complexity/understandability/maintainability).
Measurement process	Choose → select → measure → identify anomalies → analyse (cycles back).

§ 08 — COMMON MISTAKES

Where students actually lose marks on this chapter

1. Swapping QA and QC

✗ WRONG"QC is the framework of standards; QA checks compliance on a specific deliverable."

✓ RIGHTQA provides the framework of activities and standards. QC does the monitoring of specific results against that framework, throughout the project.

2. Thinking testing delivers quality

✗ WRONG"If we test enough, the product will become high quality."

✓ RIGHT"Quality cannot be tested into a product." Testing is a measure of quality — the quality itself comes from good process, tools, methods, and people.

3. Believing testing is a budget-mop-up activity

✗ WRONG"Testing exists to use up whatever budget/schedule is left at the end."

✓ RIGHTTesting's purpose is to assess and evaluate quality of work at each step of development — a full-life-cycle activity, not a leftover bucket.

4. Blurring Measure, Measurement, and Metric

✗ WRONGUsing the three terms interchangeably on an exam answer.

✓ RIGHTMeasure = the quantitative indication itself. Measurement = the act of obtaining it. Metric = the quantitative measure of degree-of-possession of an attribute.

5. Using process metrics to grade individuals

✗ WRONG"Let's use each developer's private defect rate in their performance review."

✓ RIGHTMetrics should not be used to evaluate the performance of individuals — private metrics stay with the individual/team; only public, aggregated metrics drive organizational change.

6. Mixing up static vs. dynamic product metrics

✗ WRONG"Static metrics are collected while the program is running."

✓ RIGHTIt's the reverse: dynamic = measured on a program in execution (efficiency/reliability). Static = measured on system representations (complexity/understandability/maintainability).

7. Assuming "according to requirements" = "high quality"

✗ WRONG"If it meets requirements, it's automatically high quality."

✓ RIGHTThe slides explicitly separate these as items 3 and 4 of success metrics — high quality "may or may not be the same as" meeting requirements.

8. Confusing Analysis Paralysis with Paralysis Paranoia

✗ WRONGTreating both as the same over-processing problem.

✓ RIGHTAnalysis Paralysis is actual over-process where nothing gets finished. Paralysis Paranoia is the opposite fear — avoiding process entirely out of fear of over-processing.

§ 09 — POP QUIZ

Click a question to reveal the answer

Self-check before you move to the practice lab. No reload needed.

1. (MC) Which process provides the framework of activities and standards used to perform quality control — QA or QC?

Quality Assurance. QC is the monitoring activity that operates inside the framework QA provides.

2. (Short answer) What is the only real measure of project success, according to the slides?

Customer satisfaction — "Is the customer happy?" On schedule/budget/requirements/quality are all secondary proxies.

3. (MC) A defect rate tracked per individual developer, known only to that developer and their team, is an example of which kind of metric?

A private process metric. Public process metrics, by contrast, enable organization-wide strategic changes.

4. (Short answer) Name the three points a definition of software quality should emphasize.

Conformance to explicit requirements, conformance to specified development standards, and conformance to implicit (unwritten) requirements like maintainability.

5. (MC) Which type of product metric would you use to assess a system's maintainability and understandability — static or dynamic?

Static metrics — collected from the system's representations, not from running the program.

6. (Short answer) What does MBWA stand for, and give one reason a PM would use it.

Management By Walk About. Any one of: shows involvement day-to-day, individuals may say more 1-on-1, allows spontaneity, finds personnel problems sooner.

7. (MC) A site has 40 static pages and 10 dynamic pages. What is its Customization Index C?

C = N_sp / (N_dp + N_sp) = 40 / (10 + 40) = 0.8.

8. (Short answer) Name three of the nine factors that make projects succeed, from different chunking groups (People / Scope / Process).

Any valid combination, e.g.: Executive support (People), Minimized scope (Scope), Reliable estimates (Process).

§ 10 — PRACTICE LAB

Exam-style scenarios, worked through

Same shape of question you'll see on a graded exam — grounded directly in this chapter's content.

1. A PM sets up an org-wide plan defining which audits, reviews, and standards apply to the project, plus procedures for error reporting and change management — before any deliverable is checked. Later, a QA staff member checks a specific deliverable against those standards and finds a defect, then logs a corrective action. Label each activity as QA or QC.

→ Setting up the plan/standards = Quality Assurance. Checking a specific deliverable and taking a corrective action = Quality Control.

Why: QA is the framework of activities/standards; QC is the ongoing monitoring of specific results against that framework, including corrective actions.

2. A project finishes on schedule, under budget, and meets every requirement in the signed-off spec — yet the customer is unhappy with the delivered product. Was this project successful?

→ No — by the chapter's definition, the only real measure of success.

Why: schedule, budget, and requirements are all listed as candidate success metrics, but the slides explicitly state the only real measure is customer satisfaction — "is the customer happy?"

3. A web project has 60 dynamic pages and 15 static pages. Compute the Customization Index and interpret whether the site leans static or dynamic.

→ C = 15 / (60 + 15) = 0.2 — leans heavily dynamic.

Why: C = Nsp / (Ndp + Nsp). A low C (closer to 0) means most pages are dynamically generated rather than static.

4. A team reports "informal, inadequate testing," "manual design and specification," and "more than 30% creep in user requirements" on their retrospective. Which category of factor are these, and what outcome do they predict?

→ Technology factors on unsuccessful projects — predict project failure.

Why: these three items appear verbatim on the "Technologies on Unsuccessful Projects" list from the State of the Practice slide.

Quality isn't inspected in.It's engineered in, then verified.

What "software quality" actually means

Explicit requirements

Specified standards

Implicit requirements

Software Testing

Quality and Testing

Quality Assurance vs. Quality Control

The framework, applied continuously

Monitoring specific results, throughout the project

Deciding what "good" means before you build anything

Planning Quality

The SQA Group

Evaluations

Audits & reviews

Applicable standards

Error reporting

Change management

SQA documents

Feedback amount

Discipline, restraint, and knowing when to stop over-processing

Success Metrics

The factors, the evidence, and the satire

State of the Practice in Software Management

How To Ensure a Project Fails

Turning "largely qualitative" into something you can compare

Software Metric

Project Metrics

The Measurement Process

Choose measurements to be made

Select components to be assessed

Measure component characteristics

Identify anomalous measurements

Analyse anomalous components

The whole chapter, one table at a time

Where students actually lose marks on this chapter

Click a question to reveal the answer

Exam-style scenarios, worked through

Quality isn't inspected in.
It's engineered in, then verified.