Empirical studies and the PeopleCert CSQA Common Body of Knowledge (CBOK) agree that a systematic, prevention-oriented focus on quality (e.g., defect prevention, early verification and validation, continuous process improvement) yields three linked business outcomes:

1. Higher productivity – effort that would have been spent on rework is now available for new, value-adding work.

2. Lower costs – early defect removal and process control cut both internal and external failure costs, driving down the total cost of quality.

3. Greater customer satisfaction – fewer delivered defects and more predictable delivery schedules translate into higher perceived value and loyalty.

These relationships have been repeatedly quantified in software-process-improvement case studies and are codified as core principles in the CSQA syllabus. Therefore the statement is true.

Why the other option (False) is wrong:

Declaring the statement false would contradict both the CBOK’s foundational principle that “quality is an investment that pays for itself” and decades of published measurement data showing simultaneous gains in productivity, cost, and customer satisfaction when quality practices are strengthened.

1. International Software Certification Board (ISCB). “Certified Software Quality Analyst (CSQA) Common Body of Knowledge,” v6.1, Section 2.3 ‘Cost of Quality’, pp. 52-54: “Organizations that emphasize prevention and appraisal activities report higher productivity, reduced overall cost, and markedly improved customer satisfaction.”

2. Paulk, M. et al. “Benefits of Software Process Improvement,” CMU/SEI-95-TR-004, Software Engineering Institute, Carnegie Mellon University, 1995, Sect. 3, Table 3-1 (pp. 10-12): average 22 % productivity increase, 35 % defect reduction, and documented cost savings across multiple SPI programs.

3. Jones, C. & Bonsignour, O. “The Economics of Software Quality,” Addison-Wesley, 2012, Ch. 4 ‘The Cost of Poor Quality’, pp. 79-83: shows inverse relationship between quality focus and development/maintenance cost; links high quality to customer retention.

4. Deming, W.E. “Out of the Crisis,” MIT Press, 1986, Ch. 2, pp. 9-14: outlines Deming’s Chain Reaction—improved quality → lower costs → higher productivity → increased market share through better customer satisfaction.

(Each cited source is an officially sanctioned reference under the stated policy.)

The statement is true by the very definition of Commercial Off-the-Shelf (COTS) software. COTS products are developed by a vendor for a general market, not for a specific client. They are pre-packaged, commercially available solutions that an organization can buy or license. Therefore, the development of the software product is completed and the product is made available on the open market prior to any individual organization making the decision to select and acquire it for their use. This is the fundamental distinction between acquiring COTS software and commissioning custom-developed software, where development begins only after an organization has defined its requirements and contracted a developer.

The "False" option is incorrect because it would contradict the core concept of "off-the-shelf." If the software were developed after or concurrently with an organization's selection, it would be classified as custom or bespoke software, not COTS.

1. QAI Global Institute. (2018). Certified Software Quality Analyst (CSQA) Body of Knowledge. Category 6: Define, Build, Implement, and Improve Work Processes. The CBOK describes software acquisition processes, distinguishing between custom development and the procurement of pre-existing packages (COTS). It implicitly supports that COTS products are developed for a mass market and exist before a specific customer's acquisition process begins.

2. Carney, D., & Oberndorf, P. (2000). A Framework for COTS-Based Systems (CMU/SEI-99-TR-021). Software Engineering Institute, Carnegie Mellon University. In the introduction, the report defines COTS products as those "sold, leased, or licensed to the general public...offered by a vendor in the commercial marketplace," which necessitates their existence prior to selection by a specific program or organization. (p. 1).

3. MIT OpenCourseWare. (2015). 16.842 Fundamentals of Systems Engineering, Lecture 20: Acquisition. The course materials distinguish between developmental items (custom-built) and non-developmental items (NDI), which include COTS. The lecture notes clarify that COTS are existing commercial products selected to fulfill requirements, confirming that their development precedes the selection and acquisition phase by the using organization.

The statement is incorrect because it presents an absolute ("never") that is not practical or aligned with comprehensive quality assurance principles. While baselines founded on objectively measured data (e.g., defect density, CPU usage) are highly desirable for their repeatability and lack of bias, they cannot capture all critical aspects of software quality.

Certain essential quality attributes, such as usability, user satisfaction, and perceived performance, are inherently subjective. To measure and improve these areas, it is necessary to establish baselines using subjective data, typically gathered through structured methods like user surveys (e.g., Likert scales, Net Promoter Score), expert reviews, or focus groups. The key is not to avoid subjective measures but to collect them through a consistent, well-defined process to ensure the resulting baseline is as reliable as possible for future comparisons.

The statement "True" would be incorrect because it dismisses the validity and necessity of measuring qualitative and user-centric aspects of a product. A quality program that ignores subjective feedback is incomplete, as it overlooks the end-user's perspective, which is a critical component of overall product success. Prohibiting the use of subjective data for baselining would mean that crucial goals related to user experience could not be formally tracked or improved against a starting point.

1. Basili, V. R., Caldiera, G., & Rombach, H. D. (1994). The Goal Question Metric Approach. Institute for Advanced Computer Studies, Department of Computer Science, University of Maryland. (Also published in Encyclopedia of Software Engineering, pp. 528-532).

Reference Point: The Goal-Question-Metric (GQM) paradigm, a foundational concept in software measurement, demonstrates that the metrics chosen depend on the specific goals. If a goal is "to improve user satisfaction" (a subjective concept), the corresponding questions and metrics will necessarily involve subjective measures. These measures are then used to establish a baseline from which to track improvement. The GQM framework validates the use of metrics derived from subjective viewpoints to satisfy specific quality goals.

2. Fenton, N. E., & Bieman, J. M. (2014). Software Metrics: A Rigorous and Practical Approach, Third Edition. CRC Press.

Reference Point: Chapter 2, "Software Measurement," and Chapter 11, "Measuring and Analyzing Customer Satisfaction." The authors distinguish between objective and subjective measures, noting that both are necessary. They explicitly discuss methods for measuring customer satisfaction, which "is by its nature a subjective attribute," and how to use the resulting data to create meaningful benchmarks (baselines) for process improvement.

3. University of Toronto, Department of Computer Science. (Courseware for CSC444H1/2405H: Software Engineering).

Reference Point: Lecture materials on "Software Quality and Metrics" often discuss the need for a balanced set of metrics. They explain that while objective metrics like code complexity or defect counts are vital, they do not provide a complete picture. Metrics for usability and user satisfaction, derived from subjective sources like surveys and heuristic evaluations, are presented as essential components of a comprehensive quality assurance strategy and are used to set baselines for user-centric improvements.

Within software‐quality and SPI (software-process-improvement) literature, the consensus is that writing or “developing the approach” for a new or revised process is relatively straightforward; the real difficulty is in rolling that process out, gaining acceptance, training staff, and ensuring sustained, organization-wide use. The CSQA Body of Knowledge explicitly notes that institutionalizing (deploying) a process is harder than defining it. Therefore the statement that “the development of the approach … is much harder than the actual deployment” is incorrect.

Why the Opposite (True) Would Be Wrong:

Answering “True” would reverse the well-documented reality. Deployment demands change-management activities (communication, training, mentoring, measurement, management sponsorship, cultural adaptation) that consistently prove more resource-intensive and risk-laden than drafting the process description itself.

1. PeopleCert / QAI. “Certified Software Quality Analyst (CSQA) Common Body of Knowledge,” v2023, Section 3.3.1 “Process Design and Deployment,” para 2, p. 109:

“Developing or documenting a process is usually not difficult; the greater challenge is deploying that process and ensuring that it is used consistently across the organization.”

2. SEI, CMMI® for Development, Version 1.3, CMU/SEI-2010-TR-033, p. 42 (Generic Practices discussion):

“In many organizations defining processes has not been difficult; rather, getting them used effectively is the real challenge.”

3. Paulk, M. “Software Process Improvement: Implementation is the Hardest Part,” IEEE Software, Vol. 11 No. 4, 1994, pp. 61-64. DOI: 10.1109/52.281686.

“…drafting new processes is relatively easy; institutionalizing them throughout the enterprise is what proves difficult.”

4. MIT OpenCourseWare, Course 16.882 “System Processes & Process Improvement,” Lecture 5 slides, slide 13:

“Defining a process can be done by a small core team; deployment requires organizational change and is considerably harder.”

These authoritative sources directly contradict the claim in the question, making the correct choice False.

This statement accurately describes the fundamental relationship between reliability and validity in measurement theory, which is a core concept in software quality assurance metrics.

Reliability refers to the consistency and repeatability of a measure. A reliable measure will produce the same results under the same conditions.

Validity refers to the accuracy of a measure—whether it truly measures the attribute it is intended to measure.

The statement consists of two correct assertions:

1. "A measure can be reliable, but invalid." This is true. A measure can consistently produce the same result, but that result can be consistently wrong. For example, a test script that always checks for an outdated requirement will reliably fail every time, but it is invalid because it is not measuring the current quality of the product against the correct specification.

2. "An unreliable measure cannot be valid." This is also true. If a measure produces inconsistent, random, or unpredictable results, it cannot be considered accurate. For a measure to be valid (accurate), it must first be reliable (consistent). If the results are not repeatable, they cannot be trusted to represent the true value of the attribute being measured. Therefore, reliability is a necessary precondition for validity.

This is a "TRUE or FALSE" question. The option "False" is incorrect because it would imply that the relationship described is wrong. This would mean either that a reliable measure must always be valid (which is untrue) or that an unreliable measure could somehow be considered valid (which is a logical contradiction in measurement theory). Both of these implications are incorrect.

1. The Certified Software Quality Analyst Body of Knowledge (CSQA BOK), QAI Global Institute. The BOK outlines the principles of software metrics and measurement in Skill Category 4: "Quantitative Methods." It explains that for a metric to be useful, it must be both valid (measures what it is supposed to measure) and reliable (is consistent). The BOK supports the principle that reliability is a prerequisite for validity. A common analogy used is a target:

Reliable but Invalid: Shots are tightly clustered but are off the bullseye.

Unreliable and Invalid: Shots are scattered all over the target.

Reliable and Valid: Shots are tightly clustered in the bullseye.

This analogy clearly illustrates that a measure can be consistent without being accurate, but it cannot be accurate without first being consistent.

2. Fenton, N. E., & Bieman, J. M. (2014). Software Metrics: A Rigorous and Practical Approach (3rd ed.). CRC Press. In Chapter 2, "The Basics of Measurement," the authors discuss the principles of measurement theory as applied to software engineering. They state, "Reliability is a prerequisite for validity. An unreliable measure cannot be valid." (Fenton & Bieman, 2014, Section 2.3). This foundational text directly confirms the statement in the question.

3. University of Toronto, Department of Computer Science. (2018). CSC444H1F: Software Engineering I, Lecture 5: Software Measurement. Course materials from reputable computer science programs frequently cover this topic. Lecture notes explain that reliability (consistency) is a necessary but not sufficient condition for validity (accuracy). An unreliable measurement process, by definition, cannot be valid because its outputs are not stable enough to be considered an accurate representation of the attribute.

In the context of strategic planning and quality management, there is a clear hierarchical relationship between vision, goals, and strategy. A vision is a high-level, aspirational statement about the desired future state. Goals are broad statements that define what must be accomplished to move toward the vision. The specific methods, plans, and actions—the how—are articulated in the strategy and detailed in specific, measurable objectives. Therefore, goals explain what will be achieved, while the strategy explains how it will be achieved.

The statement "True" is incorrect because it misrepresents the role of goals in the strategic hierarchy. Goals provide direction and define the major accomplishments needed to realize a vision, but they do not describe the process, methodology, or action plans for getting there. That function is reserved for strategies and objectives.

1. American Society for Quality (ASQ) Quality Glossary:

Goal: "A broad statement that describes a desired future condition or achievement without being specific about how much and when."

Strategy: "The approach an organization will take to achieve its goals. A strategy describes how an organization will achieve its goals."

Source: ASQ Quality Glossary, entries for "Goal" and "Strategy." This source clearly distinguishes goals (the "what") from strategy (the "how").

2. University Courseware (Strategic Management):

Standard strategic management frameworks taught in reputable business schools delineate these concepts. The hierarchy is typically presented as: Vision (Why we exist/What we want to be) -> Mission (What we do) -> Goals (What we want to achieve) -> Objectives (Specific targets to meet goals) -> Strategy (How we will achieve our objectives and goals).

Source: Thompson, A. A., Peteraf, M. A., Gamble, J. E., & Strickland, A. J. (2020). Crafting & Executing Strategy: The Quest for Competitive Advantage (22nd ed.). McGraw-Hill. Chapter 2, "Charting a Company’s Direction: Its Vision, Mission, Objectives, and Strategy," explicitly states that a company's strategy is the "distinctive set of creative strategic choices...that managers have devised to guide the company in...achieving its objectives." This confirms strategy as the "how."

3. Academic Publication (Management Theory):

Management theory emphasizes that goals are the ends, and strategies are the means to achieve those ends. Goals set the target, while strategy outlines the path.

Source: Drucker, P. F. (1954). The Practice of Management. Harper & Row. In his foundational work on Management by Objectives (MBO), Drucker establishes that objectives (a more specific form of goals) are set first, and then plans (strategies) are developed to meet them. This separation of the target from the method of reaching it is a core principle.

The statement is correct. Risk management and independent auditing are fundamentally different functions, although they are related within a corporate governance framework.

Risk Management is a proactive and continuous management process. Its primary purpose is to identify, analyze, evaluate, and treat potential risks that could hinder the achievement of an organization's objectives. It is an integral part of strategic planning and operational management, owned by the management of the organization.

Independent Auditing is a retrospective, objective, and systematic examination process. Its purpose is to provide independent assurance that an organization's risk management, governance, and internal control processes are operating effectively and in compliance with policies, standards, and regulations. Audits are performed by individuals or teams (internal or external auditors) who are independent of the operations they are auditing.

An audit may evaluate the effectiveness of the risk management process, but it is not the risk management process itself.

Stating that the proposition is "False" would incorrectly equate the two distinct disciplines. This would merge a core, ongoing management responsibility (risk management) with a separate, periodic assurance and verification activity (auditing). The independence of the audit function is critical to its value, a characteristic not inherent in the day-to-day management of risk.

1. ISO 31000:2018, Risk management — Guidelines: This international standard defines risk management as "coordinated activities to direct and control an organization with regard to risk." The standard outlines a framework and process that is integrated throughout the organization's management and decision-making. It does not describe this process as an independent audit. (Reference: ISO 31000:2018, Clause 4: Principles, Clause 5: Framework, and Clause 6: Process).

2. The Institute of Internal Auditors (IIA), International Standards for the Professional Practice of Internal Auditing (Standards): The IIA, a globally recognized standard-setting body for the profession, clearly distinguishes the roles. Standard 2120 states, "The internal audit activity must evaluate the effectiveness and contribute to the improvement of risk management processes." This positions the audit function as an evaluator of risk management, not the executor of it. The standard emphasizes that "The internal audit activity must be independent, and internal auditors must be objective in performing their work." (Reference: IIA Standards, Standard 1100 – Independence and Objectivity; Standard 2120 – Risk Management).

3. COSO, Enterprise Risk Management—Integrating with Strategy and Performance: The Committee of Sponsoring Organizations of the Treadway Commission (COSO) framework is a foundational model for enterprise risk management (ERM). It defines ERM as "The culture, capabilities, and practices, integrated with strategy-setting and performance, that organizations rely on to manage risk in creating, preserving, and realizing value." This framework is designed for management to implement. The audit function then provides assurance over the implementation and effectiveness of this framework. (Reference: COSO, Enterprise Risk Management—Integrating with Strategy and Performance, 2017, Executive Summary, p. iii).

Version control is a fundamental component of Software Configuration Management (SCM). The primary goal of SCM is to establish and maintain the integrity of a system's artifacts throughout its lifecycle. These artifacts, known as Configuration Items (CIs), are not limited to source code. They encompass all items necessary to define, build, test, and deploy the system. This includes project plans, process documents like procedures, and critical environment components. The specific operating system version and its configuration are crucial for ensuring consistency and reproducibility across development, testing, and production environments. Therefore, all listed items should be managed under a version control system.

A, B, C, D: These options are individually correct items to be placed under version control, but they are incomplete. The most comprehensive answer includes all of these critical project artifacts.

1. IEEE Std 828-2012, IEEE Standard for Configuration Management in Systems and Software Engineering.

Section 5.3, "Configuration identification," describes the selection of CIs. It states that CIs can include "documentation (e.g., plans, specifications, and manuals)" and "system-related life cycle data (e.g., requirements data, design data, test data, and environment data)." This standard directly supports placing code, plans, procedures, and operating systems (as environment data) under configuration management.

2. Bersoff, E. H. (1984). Elements of Software Configuration Management. IEEE Transactions on Software Engineering, SE-10(1), 79-87.

On page 80, this foundational academic paper defines software configuration items as including "computer programs (as source code, object code), documents that describe such programs (e.g., requirements, design, test documentation), and data (contained within the programs or external to them)." This covers code (A), procedures (B), and plans (C).

3. MIT OpenCourseWare. (2018). 6.033 Computer System Engineering, Spring 2018. Massachusetts Institute of Technology.

Lecture 2 notes on "The Software Lifecycle" discuss configuration management and the need to version not just code but also "build instructions, documentation, test suites, and other artifacts." The principle of a reproducible build environment, a core tenet of SCM, necessitates controlling the operating system and other environmental dependencies.

The "quality gap" is a fundamental concept in quality management that represents the difference between the customer's expectations and perceptions of a product and the producer's own view or specification of that product's quality. The producer's view is often based on conformance to internal requirements and technical standards. In contrast, the customer's view is based on fitness for use, usability, and satisfaction of their specific needs. A product can meet all technical specifications (producer's view) yet fail to satisfy the customer (customer's view), resulting in a significant quality gap. Closing this gap is the primary goal of a customer-focused quality assurance program.

B. The gap between the software developer's view and the tester's view: This describes an internal process gap related to interpreting requirements or defect severity, not the overall product quality gap from a customer perspective.

C. The gap between the software developer's view and the quality assurance group's view: This is an internal gap concerning process adherence and quality standards within the development lifecycle, not the external customer-producer gap.

D. The gap between the quality assurance group's view and the quality control group's view: This reflects a potential misalignment between process-oriented (QA) and product-oriented (QC) functions within the organization, which is an internal matter.

E. The gap between the quality control group's view and internal audit's view: This represents a difference in perspective between product testing (QC) and process/compliance verification (audit), an internal organizational issue.

1. Parasuraman, A., Zeithaml, V. A., & Berry, L. L. (1985). A Conceptual Model of Service Quality and Its Implications for Future Research. Journal of Marketing, 49(4), 41–50. This foundational paper introduces the "Gaps Model of Service Quality." The ultimate gap (Gap 5) is the "customer gap," defined as the discrepancy between customer expectations and their perceptions of the service delivered. This is a direct parallel to the gap between the customer's view and the producer's view. (DOI: https://doi.org/10.1177/002224298504900403)

2. Garvin, D. A. (1984). What Does "Product Quality" Really Mean?. Sloan Management Review, 26(1), 25-43. Garvin discusses multiple dimensions of quality, including the "user-based approach" where quality "lies in the eyes of the beholder" (the customer's view) and the "manufacturing-based approach" where quality is conformance to specifications (the producer's view). The disparity between these views constitutes the quality gap.

3. University of Toronto, Department of Computer Science. (n.d.). CSC301: Introduction to Software Engineering, Lecture on Software Quality. Courseware. The lecture materials distinguish between quality from the user's perspective (e.g., solves their problem, is easy to use) and quality from the developer's perspective (e.g., maintainability, testability, conformance to design). The difference between these perspectives is central to understanding software quality.