Software that meets all explicit requirements but is hard to maintain is still of suspect quality.
- Implicit requirements count too.
Quality, QA vs. QC, what makes projects succeed or fail, and software metrics. No past paper asked about this deck directly, but QA vs. QC, success factors and the metric categories make easy MCQ and true/false questions.
Every original slide is shown unchanged. Yellow marks on a slide point to a numbered note: hover or tap a mark to jump to its note, and hover a note to see its marks. Questions tagged Past exam appeared on a real paper; Prediction questions are likely angles, not confirmed. Pick an answer to each question: a wrong pick tells you why it is wrong, so you can try again.
Quality → QA → QC → project success → metrics.
QA vs QC is the most testable distinction in this deck.
Three tests, and passing one doesn’t mean you’ve passed all. A program can meet its written requirements and still be impossible to maintain, which is why unstated expectations count too.
Meeting only explicit requirements isn’t enough.
Seen again Ch 1, slide 66: Quality principle
Seen again Ch 1.2, slide 69: Quality in the Delivery domain
Software that meets all explicit requirements but is hard to maintain is still of suspect quality.
If testing only happens with whatever’s left at the end, it gets squeezed. Treating it as a way to judge work at each step finds problems while they’re still cheap.
What is the purpose of software testing?
A thermometer tells you a fever exists, but it doesn’t cure you. Testing measures quality, so the fix has to come from better design and process.
Each part handles defects at a different point: prevent them, cope with those that remain, and find them. That’s why SQA is much more than a test team.
Trap “Testing improves quality by itself” ✗. Quality is built in by process, design and people.
“Quality cannot be tested into a product” means:
Nobody can promise zero defects. So QA aims for two things: few problems remain, and any that do won’t cause serious damage.
Which is a goal of quality assurance?
You can’t check quality without first saying what “good” means. So planning sets standards, including outside ones like ISO 9000 and whatever the customer requires.
Which must a project’s plan comply with?
QC looks at the actual results: does this work meet the standard? It’s like inspecting a finished part. If it fails, you act to fix the cause.
QA is one step back: is the way we work likely to produce good results? It sets the framework QC then uses. Exams love this difference.
Memory trick QA = Assure the process. QC = Check the product.
Monitoring specific project results for compliance with quality standards is:
Which provides the framework of activities and standards for performing quality control?
Writing the SQA plan in advance means everyone knows which checks will occur and which documents to expect, so reviews don’t come as a surprise or get skipped.
Who prepares the SQA plan?
Audits only help if someone acts on what they find. That’s why noncompliance goes up to senior management, since they can make it matter.
What does the SQA group do with noncompliance?
Big, vague goals are hard to plan and easy to get wrong. Keeping things small means you can see progress and correct mistakes sooner, which is what think small gets at.
Which reflects “think small”?
No process leaves people guessing, and too much process stops work getting done. The right point depends on the project, which is the same idea as tailoring. That’s why balance is crucial.
Seen again Ch 1.3, slide 4: Tailoring
What are the two ends of the process spectrum?
Every “yes” to a new request costs something. “We’ll put that in phase 2” protects the schedule without just refusing, so saying no politely is a real project skill.
Teams can fail in opposite ways: analyzing forever and never building, or refusing any process for fear of that. Paralysis in either direction stops progress.
A team spends months on process and finishes nothing. What is this?
Problems often don’t reach a manager through reports. Walking around lets you hear things people won’t put in writing, and spot personnel problems early. Delegating gives you the time to do that.
What does MBWA stand for?
A project can tick all four boxes and still leave an unhappy customer. So those four are means to an end. Customer satisfaction is what finally decides whether it succeeded.
According to the slide, the only real measure of project success is:
These are early warning signs you can check before starting. Larger, longer projects with more people have more that can go wrong, which is why size predicts trouble.
Which could indicate a project’s success potential?
Why does executive support come first? Someone with power can remove obstacles and find money, and the others on this list get far harder without that help.
Which success factor is listed first and emphasized?
A PM often can’t get these alone. Top management can reach across departments, which is why a project without their backing tends to stall when it needs resources or cooperation.
Why does executive support help?
Projects don’t only fail because of tools. Social factors like politics often matter just as much, so fixing the technology alone may not save a project.
What two groups of factors may influence success or failure?
Compare each pair across the table: it’s usually the same activity, done or not done. Successful projects aren’t doing magic, just formal basics like reviews and measurement.
Which is found on successful projects?
Look at how many of these are about people, not code. Executives rejecting honest estimates or teams fighting can sink a technically sound project. So social causes deserve attention.
Which social factor appears on unsuccessful projects?
Reading it backward gives good advice: learn from past work, listen to experts, measure progress, and agree dates with developers. It’s easy to remember because it’s funny.
Which is sarcastic advice for making a project fail?
Measure what matters, not just what is easy to count.
What does the quote at this slide warn about?
“Good quality” is a matter of opinion until you measure it. Numbers let you compare two methods fairly, and that’s what objective means here.
What does measurement allow?
Think of it as three steps: 10 defects is a measure, counting them is the measurement, and defects per 1,000 lines tells you something useful, which makes it a metric.
“The act of obtaining a measure” is:
A number on its own means little. The point is what it helps you do: predict or control. So a software metric earns its place by informing decisions.
Which is an example of a software metric?
Different questions need different numbers. Product metrics ask “is what we built good?”, while process and project metrics ask “are we working well?”.
Which category assesses the design and construction of the software?
If people are judged on a number, they’ll improve the number, not necessarily the work. Using metrics to evaluate individuals makes them hide problems and spoils your data.
Process metrics should be used to evaluate individual developers’ performance.
Dynamic metrics need the program running, like speed. Static ones can look at the code itself, like complexity. So each tells you about different qualities.
Cyclomatic complexity measured from source code is a:
These are for acting during this project, not just reviewing later. Noticing delays or risks early lets the team adjust while there’s still time, which is why inputs, outputs and results are tracked.
What should every project measure?
You can easily count lines, but you want to know about maintainability. Metrics only help if what’s countable is genuinely linked to what you care about, and that’s not always so.
Which assumption do metrics rely on?
You can’t claim to be improving without a “before” figure. Without a baseline from past work, any change is just opinion, which is why missing old data is such a problem.
Why is baseline data needed?
Direct measures can simply be counted. Indirect ones, like reliability, have to be inferred from other numbers. That’s why quality attributes are harder to measure.
Which is an INDIRECT product measure?
One project’s data helps a little, but many projects’ data shows real patterns. Keeping it as an organizational resource means the next team doesn’t begin from nothing.
Why keep measurement data as an organizational resource?
In the measurement process, what do you look for after measuring?
Memory fades quickly and people round things off. Collecting data immediately and automatically gives you a true record, without asking busy people to log things by hand.
When should data be collected?
Decide what you’re trying to learn before collecting anything, or you’ll gather a lot and use little. People are also more honest if they know the data won’t be used to judge them.
Should metrics data be part of personnel evaluation?
Metrics exist to support management decisions: control (process) and prediction (product).
What are metrics mainly for?
A high defect count could mean bad code or excellent testing. Numbers don’t explain themselves, so local circumstances matter, and a statistician can stop you drawing the wrong conclusion.
What must data analysis take into account?
Each type suits a different question. Size metrics count things, function metrics measure what the software does, and product metrics like cyclomatic complexity assess how the code is built.
A site has 30 static and 10 dynamic pages. Customization index C = Nsp/(Ndp+Nsp)?