Free CPSA-FL Practice Test

This question evaluates the understanding of relationships and trade-offs between software quality characteristics.
Statement C is fundamentally correct. Simplicity in a system's design and implementation (e.g., low complexity, clear structure) is a primary driver for its comprehensibility. A system that is easier to understand is also easier to analyze, maintain, and evolve.
Statement A describes a common trade-off in software engineering. Increased flexibility often implies more features, configuration options, and execution paths. This leads to a combinatorial increase in the number of states to be tested, making it significantly more difficult and costly to achieve thorough test coverage. Therefore, flexibility can negatively impact, or "reduce," practical testability.

B. Increased flexibility improves robustness: This is generally incorrect. Flexibility and robustness are often conflicting quality goals. Increasing flexibility can introduce more complexity and potential points of failure, thereby making the system harder to secure and potentially less robust.
D. Increased efficiency results in reduced performance: This statement is contradictory. In software quality models like ISO/IEC 25010, "Performance efficiency" is a key characteristic. Efficiency (resource utilization) and performance (time-behavior) are positively correlated; improving efficiency typically improves performance, it does not reduce it. ---

1. For Correct Option C (Simplicity increases comprehensibility):

Van Vliet

H. (2008). Software Engineering: Principles and Practice. 3rd Edition. John Wiley & Sons. Chapter 7

Section 7.3

on design heuristics

emphasizes that simplicity and low complexity are crucial for creating understandable and maintainable systems. It states

"A simple design is easy to understand and easy to maintain."

2. For Correct Option A (Flexibility reduces testability):

Patton

R. (2006). Software Testing. 2nd Edition. Sams Publishing. Chapter 1 discusses the testing axiom "The more complex the software

the more bugs it will have." Flexibility adds to this complexity. The book explains how a multitude of options and configurations (a hallmark of flexibility) exponentially increases the number of test cases required

making exhaustive testing impossible and practical testability more challenging.

3. For Incorrect Option B (Flexibility vs. Robustness):

International Software Architecture Qualification Board (iSAQB). (2019). Curriculum CPSA-Foundation Level

Version 2.0.1 DE. Page 19

Section 2.3. This official curriculum explicitly lists "Flexibilität vs. Stabilität/Robustheit" (Flexibility vs. Stability/Robustness) as a well-known example of conflicting quality requirements. This directly contradicts the claim that one improves the other.

4. For Incorrect Option D (Efficiency vs. Performance):

ISO/IEC 25010:2011. Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models. Section 4.2 describes the "Performance efficiency" characteristic

which includes sub-characteristics like "Time-behaviour" and "Resource utilization." The standard defines them as related components of the same high-level quality attribute

indicating they are not in opposition.

This question assesses knowledge of the seven fundamental principles of software testing.
A. In general, exhaustive testing is not possible: This is Principle 2. Testing all possible combinations of inputs, preconditions, and execution paths is infeasible for any non-trivial software. Testers must use risk analysis and prioritization to focus efforts.
B. Where many errors exist, more errors are usually hidden: This is a direct consequence of Principle 4, "Defects cluster together." This principle observes that a small number of modules or components usually contain most of the defects, so finding several defects in one area makes it a good place to look for more.

C. This contradicts Principle 1, "Testing shows the presence of defects, not their absence." Testing can reveal that defects exist but cannot prove that no defects remain.
D. This is Principle 7, the "Absence-of-errors fallacy." Finding and fixing defects does not guarantee the system is useful or meets user needs if the requirements were incorrect.

1. International Software Testing Qualifications Board (ISTQB®). (2018). Certified Tester Foundation Level Syllabus Version 2018. Section 1.3

"Seven Testing Principles (K2)"

pp. 8-9.

Page 8

Principle 2: "Exhaustive testing is impossible. Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases." (Supports answer A).

Page 9

Principle 4: "Defects cluster together. A small number of modules or components usually contains most of the defects discovered during pre-release testing

or is responsible for most of the operational failures." (Supports answer B).

Page 8

Principle 1: "Testing shows the presence of defects

not their absence. Testing can show that defects are present

but cannot prove that there are no defects." (Refutes option C).

Page 9

Principle 7: "Absence-of-errors fallacy. Some organizations expect that testers can run all possible tests and find all possible defects

but Principles 2 and 1

respectively

tell us that this is impossible. Further

it is a fallacy to expect that just finding and fixing a large number of defects will ensure the success of a system. For example

thoroughly testing all the specified requirements and fixing all the defects found could still produce a system that is difficult to use

that does not fulfill the users’ needs and expectations..." (Refutes option D).

A software architect is fundamentally responsible for translating requirements into a viable technical solution. This involves making key decisions that determine the system's quality attributes. Performance (A) is a critical quality attribute (a non-functional requirement) directly shaped by architectural choices like technology stack, component interaction, data management, and concurrency strategies. The suitability of the software design for its purpose (C) is the essence of the architect's role. The architect must create a design that not only fulfills functional requirements but also satisfies all quality attributes and constraints, making it fit for its intended purpose. This is the primary goal and responsibility of the architectural design process.

B. The technical quality of the software implementation: While the architect sets guidelines and reviews the implementation, the primary responsibility for the line-by-line code quality rests with the development team. The architect is more concerned with the design's quality and its correct realization.
D. The software is free of errors: Ensuring the software is free of functional defects (correctness) is a shared responsibility of the entire team, particularly developers and quality assurance (QA) engineers, through coding and testing. It is not a sole responsibility of the architect.

1. ISAQB e.V. (2020). Certified Professional for Software Architecture

Foundation Level

Syllabus

Version 3.0.1.

Page 10

Section 2.2

"Tasks of Software Architects": This section lists key tasks

including "Designing the software architecture

i.e. the fundamental organization of a system..." which directly supports the responsibility for the design's suitability (C). It also lists "Defining

documenting and communicating non-functional requirements (quality requirements) for the system (e.g. reliability

performance

security)

" which directly supports responsibility for performance (A).

2. Bass

L.

Clements

P.

& Kazman

R. (2021). Software Architecture in Practice (4th ed.). Addison-Wesley Professional.

Page 4

Chapter 1

"What is Software Architecture?": "The architectural design decisions are the ones that are hardest to change later. They are the decisions that determine the system’s ability to meet its requirements for performance

reliability

security

and so on." This highlights the architect's responsibility for performance (A).

Page 5

Chapter 1

"What is Software Architecture?": "Architecture is the set of principal design decisions made about the system... The purpose of these decisions is to satisfy the system’s requirements." This statement encapsulates the architect's core responsibility for ensuring the design is suitable for its purpose (C).

3. Hofmeister

C.

Kruchten

P.

Nord

R. L.

& Obbink

H. (2007). A general model of software architecture design derived from five industrial approaches. Journal of Systems and Software

80(1)

106-126.

Section 3.1

"Architectural Drivers": The paper emphasizes that architecture design is driven by functional requirements

quality attributes

and constraints. The architect's job is to create a design that balances these drivers

thus ensuring its suitability for the purpose (C). It explicitly identifies performance as a key quality attribute driver (A). (DOI: https://doi.org/10.1016/j.jss.2006.05.024)

When requirements are not fully determined, the primary architectural goal is to ensure maintainability and adaptability to change. The three most critical properties to achieve this are:
1. Weak coupling (B): This principle minimizes dependencies between components. When a change is required, it can be isolated to a single component without causing a ripple effect across the system, which is essential in an evolving requirements landscape.
2. Strong cohesion (C): This ensures that all responsibilities within a single component are closely related and focused on a common purpose. This makes components easier to understand, maintain, and modify when requirements change, as the change is likely localized within one cohesive unit.
3. Open for extension (D): This refers to the Open/Closed Principle. Components should be designed so that new functionality can be added (open for extension) without modifying existing, proven code (closed for modification). This is crucial for accommodating new requirements as they are finalized.

A. meaningful component names: While important for code readability and general maintainability, this practice does not structurally prepare the architecture for functional changes and evolution.
E. small component size: This is often a positive side-effect of strong cohesion, but it is not a primary principle. A component can be small yet still have high coupling and low cohesion, making it difficult to maintain.

1. International Software Architecture Qualification Board (ISAQB). CPSA-FL - Lehrplan

Version 4.1.1 DE. (2021).

Section 3.2.1

"Kopplung und Kohäsion" (Coupling and Cohesion): This section explicitly defines weak coupling and strong cohesion as fundamental principles for creating modular

maintainable

and understandable software architectures. It states that these principles directly support the quality goal of changeability (p. 31).

Section 3.2.3

"Das Offen-Verschlossen-Prinzip" (The Open-Closed Principle): This section details the principle of designing components to be open for extension but closed for modification

highlighting its importance for creating stable yet extensible systems that can adapt to new requirements without destabilizing existing functionality (p. 33).

2. Garmus

D.

& Herron

D. (2001). Function Point Analysis: Measurement Practices for Successful Software Projects. Addison-Wesley Professional.

While focused on measurement

this and similar foundational texts establish that high cohesion and low coupling are universally accepted indicators of sound architectural design

directly impacting a system's maintainability and cost of change. The principles are presented as essential for managing complexity and evolution.

3. Lattanze

A. J. (2009). Architecting Software Intensive Systems: A Practitioner's Guide. CRC Press.

Chapter 7

"Achieving Quality Attributes": This chapter discusses how architectural decisions and principles like low coupling

high cohesion

and encapsulation are the primary mechanisms for achieving quality attributes such as modifiability and extensibility

which are paramount when requirements are uncertain.

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/ISQI_ISAQB_CPSA-FL/page_7_img_1.jpg

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/ISQI_ISAQB_CPSA-FL/page_3_img_2.jpg

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/ISQI_ISAQB_CPSA-FL/page_21_img_2.jpg

A stack is a fundamental abstract data type that operates on the Last-In, First-Out (LIFO) principle. The push operation is the standard method for adding a new element to the top of the stack. Because of its LIFO nature, operations such as adding (push), removing (pop), or viewing (peek) are restricted to the most recently added element, which is at the top. Consequently, a stack typically provides direct access to only one element at a time—the top one. To access deeper elements, the elements above them must be removed first.

B. A stack (LIFO) and a queue (FIFO) are distinct data structures with opposite principles of element access and removal.
C. The FIFO (First-In, First-Out) principle describes the behavior of a queue, not a stack, which is LIFO (Last-In, First-Out).

1. International Software Architecture Qualification Board (iSAQB). (2023). Curriculum for Certified Professional for Software Architecture - Foundation Level (CPSA-F)

Version 2.2EN. Section 2.3.2

"Data Structures

" describes a stack as a data structure organized according to the LIFO principle.

2. Cormen

T. H.

Leiserson

C. E.

Rivest

R. L.

& Stein

C. (2009). Introduction to Algorithms (3rd ed.). MIT Press. In Chapter 10

Section 10.1

"Stacks and queues

" a stack is defined as implementing a last-in

first-out (LIFO) policy. The PUSH operation is described as inserting an element onto the stack

and access is limited to the element at the "top."

3. Demaine

E. (2011). 6.006 Introduction to Algorithms

Fall 2011. Massachusetts Institute of Technology: MIT OpenCourseWare. Lecture 3

"Stacks

Queues

Linked Lists

" defines a stack with push(x) and pop() operations acting on the top of the stack

enforcing LIFO behavior. It explicitly contrasts this with the FIFO behavior of a queue.

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/ISQI_ISAQB_CPSA-FL/page_22_img_1.jpg

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/ISQI_ISAQB_CPSA-FL/page_28_img_1.jpg Thank you for your visit.