architecture Online Quiz - 38

At 64 Kbps, a 40 KB page takes approximately 5 seconds to transfer (40KB × 8 = 320Kb ÷ 64Kbps = 5s), not counting protocol overhead. This is the fundamental bottleneck. DB tuning (A) and web server tuning (B) won't overcome the bandwidth limit. Asking users to work at night (C) is impractical. A web accelerator like Citrix or NetScaler (D) compresses content, caches static resources, and optimizes protocol overhead - directly addressing the bandwidth constraint.

Adding resources only helps if that specific resource is the bottleneck. Adding CPUs won't help if the issue is memory-bound. Adding RAM won't help if CPU is saturated. Adding disks won't help if the problem is network latency. Performance improvement requires identifying the actual constraint first. Options A, B, and C are all false because they claim adding resources will 'always' improve performance. Option D correctly states that none of these universal statements are true.

Once a system is tested and tuned, it performs well under the tested conditions. However, option A is too absolute - systems can always encounter new issues. Option B incorrectly states the system 'will' have problems when it grows (certainty). Option D incorrectly limits problems to only application changes. Option C is correct with 'can have' because growth (more users, more data, more transactions) can introduce new bottlenecks that weren't present at the original scale.

Average response time = (5 + 1 + 3 + 3) / 4 = 12 / 4 = 3 seconds. Individual response times are: 5, 1, 3, 3. Only the first job (response time 5) is greater than the average (3). Jobs 2, 3, and 4 have response times of 1, 3, and 3 respectively - none exceed the average of 3. Therefore, exactly 1 job has a response time greater than the average.

The code for(;;) is an infinite loop in C and C-like languages. The semicolons indicate an empty condition, which evaluates to true, creating a loop that never terminates. The function foo() contains this infinite loop and never returns. Therefore main() never completes after calling foo(). The program will run forever unless externally terminated. Option D is correct - the code will never complete.

A full line-by-line code review taking 1 person-year is impractical and inefficient. Option A wastes time. Option B incorrectly shifts responsibility back to the customer. Option D (automated tool) might help identify patterns but won't replace targeted human analysis. Option C is best: collaborate with the customer to identify which code modules handle critical paths, complex logic, or reported issues. Review those targeted portions first - this is risk-based prioritization rather than exhaustive review.

Response time measures how long a system takes to handle requests when operational. Options A, B, and C all measure actual request handling time, making them valid response time metrics. Restarting a service (D) is about availability and recovery, not response time measurement.

Think time is the standard term in performance testing for the pause between receiving a response and submitting the next request. This simulates real user behavior where people pause to read content before taking action. Wait time, halt, and rendezvous points refer to different testing concepts.

Concurrent users specifically means the number of users actively using the system at a precise moment, which matches the question's definition. Active users could refer to a broader time window, while 'number of users' and 'number of connected users' are ambiguous terms without the temporal specificity.

Network bandwidth fundamentally measures throughput - the amount of data transmitted per unit of time across the network. Response time measures latency, number in the system is a queuing metric, and utilization measures capacity usage. Bandwidth is specifically about data transfer capacity.

Caching data, adding memory, and creating instances all directly improve memory performance. Dedication of memory to specific tasks (B) is an allocation strategy, not a remediation technique - it doesn't solve the underlying memory problem, just partitions existing limited resources differently.

Increasing bandwidth, adding SSL accelerators, and improving node performance all directly address network performance issues. Reducing packet size (B) typically increases overhead due to more headers and doesn't improve throughput - it's often counterproductive for performance.

The question asks for the FALSE statement. In TOGAF and enterprise architecture frameworks, Application Architecture focuses on defining what applications are needed and how they relate to business functions and data. It does NOT involve detailed systems design - that belongs to later implementation phases. Options A, B, and D describe valid aspects of Application Architecture.

Gap analysis identifies missing capabilities (gaps) and overlapping/redundant functions between current and target states. This is a core purpose in architecture development. Option A refers to quality criteria, not gap identification. Option C is about optimization after gaps are found. Option D and E relate to solution selection and specification, not gap identification itself.

Architecture Building Blocks (ABBs) define WHAT functionality is required at an architectural level, while Solution Building Blocks (SBBs) define WHAT specific products, components, or technologies will implement that functionality. ABBs are technology-agnostic specifications. SBBs are concrete implementations. Option A is incorrect because both can be reusable. Option B reverses the definitions. Option C has the relationship backwards.

Application systems should be described as logical groups of capabilities that work together to support business functions. This abstraction-level description is appropriate for architecture work. Computer systems (A) is too technical. Schemas (C) relate to data structure. Data-flow diagrams (D) are analysis tools, not system descriptions.

When selecting building blocks, TOGAF recommends prioritizing reusable components from the Enterprise Continuum (repository of proven assets) before developing custom solutions. This promotes consistency and reduces development effort. Custom components (B) and common systems components (D) are secondary considerations. Integration methods (C) are implementation concerns.

Qualitative criteria in application architecture evaluation include non-measurable attributes like security, maintainability, and flexibility. Security is clearly qualitative (no single metric defines 'secure'). Option A (defects per unit of code) is quantitative. Options B (cost) and E (timeline) are financial/time metrics. Option D (functionality) is about what the system does, not a qualitative quality measure.

The question asks what is NOT a qualitative criterion. Application functionality describes WHAT the system does - it's the deliverable itself, not a quality attribute. Qualitative attributes include availability (B), reliability (D), and security (E) - these describe HOW WELL the system operates. Transaction volume (A) is quantitative (measurable metric).

TOGAF's architecture development method is iterative. If Application Architecture work reveals necessary changes to Business Architecture, the correct action is to revisit and refine the Business Architecture phase before proceeding. This ensures alignment. Options B, C, D, and E suggest workarounds or governance actions that skip proper iteration back to the earlier phase.