Software reviews are a fundamental static testing technique used to evaluate a work product. One of the primary objectives of the review process, especially in formal reviews like inspections, is to verify that the work product conforms to predefined standards, guidelines, and specifications. Checklists used during reviews often contain specific items to check for adherence to coding standards, documentation templates, or architectural principles. By identifying non-conformance as defects, the review process actively ensures that these standards are followed, effectively enforcing them across the project and improving the overall quality and consistency of the software.

B. False: This is incorrect. A key purpose and benefit of conducting software reviews is to ensure and verify compliance with organizational and project-specific standards.

1. ISTQB® Certified Tester Foundation Level Syllabus (2018, Version 3.1), Section 3.2.1, "Work Product Review Process," outlines the objectives of reviews. While not using the word "enforce," the objective of "improving the quality of the software work product" inherently includes ensuring it meets quality standards. More explicitly, review checklists are based on these standards.

2. ISTQB® Certified Tester Advanced Level Test Analyst Syllabus (2019, Version 3.0), Section 2.2.2, "Using Checklists in Reviews," states: "Typical checklist items include checks against common defect types and adherence to standards (e.g., coding standards, modeling standards)." This directly confirms that reviews check for and thus help enforce standards.

3. Sommerville, I. (2016). Software Engineering (10th ed.). Pearson. In Chapter 8, "Software Testing," Section 8.3.1, "Program inspections," the author lists the principal checks made during the inspection process. The second item on the list is: "Compliance with standards is checked (e.g., are comments in the right format?)."

4. Pressman, R. S., & Maxim, B. R. (2020). Software Engineering: A Practitioner's Approach (9th ed.). McGraw-Hill. In Chapter 19, "Software Quality Assurance," Section 19.3, "Formal Technical Reviews," the authors state that a key objective of a review is "to verify that the software element under review conforms to its specification and that it adheres to predefined standards."

An oral system proposal is a presentation that supplements the formal written document. Its purpose is to effectively communicate the proposed solution and gain stakeholder approval. This involves project leaders presenting the system's key features, benefits, and feasibility, guiding users through how it addresses their specific problems (C). A primary and unique advantage of the live, oral format is its interactive nature. It provides an immediate forum for stakeholders, including customers and users, to ask questions, seek clarification on points from the written or oral presentation, and express concerns (B). This two-way communication is vital for building consensus and ensuring the proposed system meets expectations before development proceeds.

A. The oral presentation summarizes and highlights the written proposal; it does not serve as a substitute for the detailed, formal written document required for record-keeping and reference.

1. Kendall, K. E., & Kendall, J. E. (2014). Systems Analysis and Design (9th ed.). Pearson. In Chapter 11, "Presenting the Systems Proposal," the text describes the presentation as a method to "sell the system proposal" by walking the audience through the main points and solution features. It explicitly highlights the importance of the question-and-answer session for clarification and feedback.

2. Satzinger, J. W., Jackson, R. B., & Burd, S. D. (2016). Systems Analysis and Design in a Changing World (7th ed.). Cengage Learning. Chapter 6, "Foundations for Systems Design," discusses the system proposal as the culmination of the analysis phase. The presentation of this proposal is described as a key step for obtaining approval, which involves both explaining the proposed solution (the walkthrough) and addressing stakeholder questions.

3. Valacich, J. S., & George, J. F. (2020). Modern Systems Analysis and Design (9th ed.). Pearson. Chapter 5, "Initiating and Planning Systems Development Projects," details the project proposal process. It notes the importance of presentations for communicating project scope, benefits, and features, and for facilitating a crucial question-and-answer period with stakeholders. The oral presentation is always positioned as a complement to a written report.

The statement is false. Function Point Analysis (FPA) is a standardized method used to measure the functional size of software from the end-user's perspective. It quantifies the business functionality an information system provides based on logical design and user requirements. In contrast, Lines of Code (LOC) is a metric that measures the physical size of a program's source code. A key advantage of function points is their independence from the programming language, technology, and development methodology, whereas LOC is highly dependent on these factors. While models exist to correlate function points with LOC for effort estimation, function points do not directly measure lines of code.

A. True: This is incorrect. Function points and lines of code are fundamentally different software sizing metrics. Function points measure what the software does (functional size), while LOC measures how large the implementation is (physical size).

1. Albrecht, A. J. (1979). Measuring Application Development Productivity. In Proceedings of the Joint SHARE/GUIDE/IBM Application Development Symposium, Monterey, California (pp. 83-92). IBM Corporation.

Reference Detail: In this foundational paper, Albrecht introduces Function Points as a measure of the "function value delivered to the user" (Section: "A New Way of Sizing and Estimating"). He explicitly contrasts this with Lines of Code, which he notes is language-dependent and a poor measure of productivity and value.

2. International Function Point Users Group (IFPUG). (2010). Function Point Counting Practices Manual (CPM), Release 4.3.1.

Reference Detail: Chapter 1, Section 1.1, "Introduction," defines Function Point Analysis as a method for "sizing software based on the functions that are perceived by the user." The manual's methodology is based on identifying logical user functions (e.g., inputs, outputs, inquiries) and has no component for counting physical lines of code.

3. Garmus, D., & Herron, D. (2001). Function Point Analysis: Measurement Practices for Successful Software Projects. Addison-Wesley Professional.

Reference Detail: Chapter 2, "Function Point Fundamentals," states, "Function points are a unit of measure for software size... They are independent of technology. For example, a project's function point count will not change regardless of the language, development tools, or hardware platform used." This directly contradicts the idea that they measure LOC, which is language-specific.

The Malcolm Baldrige National Quality Award is the highest U.S. presidential honor for performance excellence. It recognizes organizations for their achievements in a comprehensive, systematic approach to organizational improvement. The award's criteria are based on the Baldrige Performance Excellence Framework, which is a definitive model for quality management. This framework assesses the entire organization—including leadership, strategy, customers, workforce, and operations—to drive results. Therefore, the award recognizes both the implementation of a robust quality management system and the tangible achievements that result from it.

A. Incorrect because "quality control" is a narrow, product-focused inspection activity, whereas the Baldrige Award evaluates the entire strategic and operational management system.

B. Incorrect because "quality assurance" and "quality control" are specific operational functions, not the all-encompassing organizational management framework that the award assesses.

Note: The trailing phrase in the provided option C, "Meeting all the definitions of quality," is too vague and abstract. The award is based on a specific, defined set of criteria for performance excellence, not on meeting every possible definition of quality.

1. National Institute of Standards and Technology (NIST). (2023). 2023–2024 Baldrige Performance Excellence Framework (Business/Nonprofit). U.S. Department of Commerce. Page 1 states the framework's purpose is to help organizations "evaluate performance, assess where improvements or innovation are most needed, and get results." This directly links the management framework to achievement.

2. National Institute of Standards and Technology (NIST). "About the Baldrige Award." Official Website. Retrieved from https://www.nist.gov/baldrige/about-baldrige-award. The site describes the award as recognizing "outstanding commitment to sustainable excellence through innovation, improvement, and visionary leadership," which are hallmarks of a comprehensive management system leading to achievement.

3. Evans, J. R., & Lindsay, W. M. (2019). Managing for Quality and Performance Excellence (11th ed.). Cengage Learning. Chapter 3, "Frameworks for Quality and Performance Excellence," details how the Baldrige Award criteria provide a framework for a total quality management system and recognize organizations that achieve the highest levels of performance based on that system.

A standard is a formal document that establishes uniform criteria, methods, or practices. By its very nature, its purpose is to set a benchmark for quality, safety, or performance. Once a standard is adopted by an organization, industry, or governing body, adherence to it becomes the required and anticipated behavior. This makes the standard the "expected norm" for any process, product, or service within its scope. For example, the ISO 9001 standard sets the expected norm for quality management systems in certified organizations.

A. True: This is incorrect because the fundamental role of a standard is to create a repeatable, agreed-upon baseline, which directly establishes an expected norm for compliance and practice.

1. ISO/IEC 2382:2015, Information technology — Vocabulary, Clause 01.01.40: Defines a standard as a "document, established by consensus and approved by a recognized body, that provides, for common and repeated use, rules, guidelines or characteristics for activities or their results..." This definition implies the establishment of a norm for "common and repeated use."

2. Naik, K., & Tripathy, P. (2008). Software Testing and Quality Assurance: Theory and Practice. Wiley. Chapter 2, Section 2.4, "Quality Standards": This section explains that standards like ISO and CMMI provide a framework of best practices that are expected to be followed by organizations to achieve a certain level of quality. This establishes them as the expected norm for process implementation.

3. Pressman, R. S., & Maxim, B. R. (2019). Software Engineering: A Practitioner's Approach (9th ed.). McGraw-Hill Education. Chapter 16, "Software Quality Assurance": The text discusses how SQA activities are governed by a set of standards. It states, "A quality management system can be defined as the organizational structure, responsibilities, procedures, processes, and resources for implementing quality management." These procedures and processes, defined by standards, become the organizational norm.

The fundamental purpose of software testing is to find defects. It is an investigative process designed to provide stakeholders with information about the quality of the software product. By executing the software with the intent of making it fail, testers can identify discrepancies between expected and actual results. While successful test execution can increase confidence in the software's functionality, it is a logical fallacy to claim testing proves correctness. Testing can only demonstrate the presence of defects, not their absence.

B: Testing cannot demonstrate that an application works properly under all possible conditions; it can only confirm its behavior for the specific test cases executed.

C: Validating the logical design is a component of the broader verification and validation (V&V) process, often addressed through static methods like reviews and inspections, not solely through dynamic testing.

1. Myers, G. J., Sandler, C., & Badgett, T. (2011). The Art of Software Testing (3rd ed.). John Wiley & Sons. In Chapter 2, "The Psychology and Economics of Software Testing," it is established that a primary goal of testing is to find errors. The text states, "Testing is the process of executing a program with the intent of finding errors" (p. 6).

2. Pressman, R. S., & Maxim, B. R. (2015). Software Engineering: A Practitioner's Approach (8th ed.). McGraw-Hill Education. In Chapter 17, "Software Testing Strategies," testing is defined with the objective of finding errors. The authors state, "Testing is a process of executing a program with the intent of finding an error" (p. 450).

3. Ammann, P., & Offutt, J. (2016). Introduction to Software Testing (2nd ed.). Cambridge University Press. Chapter 1, Section 1.1, "A Fault, Error, Failure Terminology," clarifies that testing's goal is to reveal failures, which are caused by faults (defects). The entire process is oriented around the discovery of these faults.

The statement is correct. Quality Control (QC) is a product-oriented set of activities focused on evaluating a developed product or service. Its primary purpose is to identify defects after a product is developed and before it is released. QC involves operational techniques and activities, such as inspections, reviews, and testing, which are performed directly on the work product to ensure it meets the specified quality requirements and standards. This is distinct from Quality Assurance (QA), which is process-oriented and aims to prevent defects by improving the development and manufacturing processes.

B. False: This is incorrect. The fundamental definition of Quality Control centers on its application to a specific output or artifact, making it inherently product-focused rather than a general or process-focused activity.

1. Pressman, R. S., & Maxim, B. R. (2020). Software Engineering: A Practitioner's Approach (9th ed.). McGraw-Hill. In Chapter 16, "Software Quality Assurance," the text distinguishes Quality Control as a series of inspections, reviews, and tests used to ensure each work product meets its requirements, directly linking QC to specific products.

2. International Organization for Standardization. (2015). ISO 9000:2015: Quality management systems — Fundamentals and vocabulary. Section 3.3.7 defines Quality Control as the "part of quality management focused on fulfilling quality requirements." The application of this principle involves checking the outputs (products/services) against the requirements.

3. Galit, A. (2004). Software Quality Assurance: From Theory to Implementation. Pearson/Addison-Wesley. Chapter 1, "The Software Quality Challenge," explains that quality control activities are "focused on the detection of faults in the specific products" (p. 12), reinforcing the product-specific nature of QC.

This statement is true. It reflects a fundamental principle of software quality engineering: the cost to find and fix a defect increases exponentially the later it is discovered in the software development lifecycle (SDLC). Design and code inspections are static analysis techniques performed early in the lifecycle. They can identify errors in requirements, architecture, and logic before any code is executed. Fixing a design flaw by editing a document is far more economical than fixing the same flaw after it has been coded, integrated, and discovered during system testing, which would require extensive rework, re-coding, and re-testing.

B. False: This is incorrect because it contradicts decades of empirical evidence and established software engineering principles. The economic benefit of early defect detection through static methods like inspections is a cornerstone of modern quality assurance.

1. Boehm, B. W. (1981). Software Engineering Economics. Prentice-Hall. In Chapter 4, "The Cost of Software," Boehm presents seminal data showing the relative cost to fix errors increases dramatically from the requirements phase through the maintenance phase. A defect found in the design phase is orders of magnitude cheaper to fix than one found during system testing.

2. Fagan, M. E. (1976). Design and code inspections to reduce errors in program development. IBM systems journal, 15(3), 182-211. https://doi.org/10.1147/sj.153.0182 This foundational paper on software inspections provides data showing that formal inspections can find 60-90% of defects before the first test is ever run, demonstrating their high cost-effectiveness (see Section: "Inspection results," pp. 196-200).

3. Carnegie Mellon University, School of Computer Science. (2016). 15-214 Principles of Software Construction: Objects, Design, and Concurrency, Lecture 1: Intro & Quality. Slide 22, "Relative Cost to Fix a Defect," visually represents the exponential cost increase, illustrating that a defect found post-product-release can be 100-1000 times more expensive to fix than one found during the design phase. This supports the economic argument for early detection via inspections.

Pareto analysis is a statistical technique used for decision-making and is based on the Pareto principle, often called the 80/20 rule. Its primary function is to identify and prioritize the most significant problems or causes. By arranging factors in descending order of frequency or impact on a bar chart, it visually distinguishes the "vital few" from the "trivial many." This ranking allows teams to focus their limited resources on the items that will yield the most significant improvement, making it an essential tool for strategic problem-solving and quality improvement initiatives.

A. Showing relationships between items: This is incorrect. Tools like cause-and-effect (Ishikawa) diagrams or scatter plots are designed to explore and display relationships between different variables or causes.

C. Measuring the impact of identified items: This is incomplete. While Pareto analysis uses measurements of impact as input, its core effectiveness lies in using those measurements to rank and prioritize items, not just measure them.

1. Guide to the Software Engineering Body of Knowledge (SWEBOK), Version 3.0, IEEE Computer Society, 2014. In Chapter 4, "Software Quality," section 3.2.2 "Analytical Techniques," it states: "Pareto analysis is a statistical technique for selecting a small number of causes that produce a significant overall effect... It is used to identify the most important causes of a problem." (p. 4-10).

2. Montgomery, D. C. (2020). Introduction to Statistical Quality Control (9th ed.). Wiley. In Chapter 5, "The Basic Tools of SPC," the Pareto chart is described as a fundamental tool whose "purpose is to prioritize problems." It helps to "separate the vital few from the trivial many." (Section 5.2.4).

3. MIT OpenCourseWare. (2012). 16.660J Introduction to Lean Six Sigma Methods. IAP 2012. In the lecture notes for "Session 2: Define/Measure I," the Pareto Chart is explicitly listed as a tool used to "Prioritize problems" and "Focus on the 'vital few' not the 'trivial many'."

The primary purpose of the closing section of a system proposal is to serve as a formal call to action. After the proposal has detailed the problem, presented the analysis, and justified the recommended solution, the conclusion's role is to explicitly request approval from decision-makers. This section translates the persuasive arguments made throughout the document into a direct request for the necessary authorization, funding, and resources to advance to the next phase of the project, such as system design or implementation. It is the final step in securing commitment from stakeholders.

A. A succinct overview is the purpose of the executive summary, which is presented at the beginning of the proposal.

B. Emphasizing that you have the best solution is the overarching goal of the entire proposal, not the specific function of the closing.

1. Kendall, K. E., & Kendall, J. E. (2019). Systems Analysis and Design (10th ed.). Pearson. In Chapter 3, "Project Management," the text describes the systems proposal, stating that the summary and recommendations section is where the analyst must "sell the system and gain the approval of management to proceed." This directly aligns the conclusion with the goal of getting approval.

2. Shelly, G. B., & Rosenblatt, H. J. (2012). Systems Analysis and Design (9th ed.). Cengage Learning. In Chapter 3, "Managing Systems Projects," the report to management (a form of proposal) concludes with a recommendation. The purpose is to elicit a decision from management to "continue the project, perform additional study, or terminate the proposal" (p. 111). This confirms the closing's function is to secure a decision to proceed.

3. Valacich, J. S., & George, J. F. (2020). Modern Systems Analysis and Design (9th ed.). Pearson. Chapter 5, "Project Initiation and Planning," discusses the Baseline Project Plan (BPP), a major deliverable analogous to a system proposal. The document's purpose is to be reviewed by a steering committee, which then decides whether to "commit resources to the next phase of the project." The conclusion of this process is the formal request for this commitment.