Impact of Program Design

Evidence of reliability has two parts: the conditions must be varied, and the expected behavior must be stated in advance. Without a stated expectation there is nothing to compare the result against, and without variety a program can pass while its untested paths remain broken.

• A is not correct: a clear opening screen describes appearance, which says nothing about whether the alerts are produced correctly.
• C is not correct: one correct alert covers a single condition, so it cannot show how the system behaves in the situations it was not asked to handle.
• D is not correct: speed is not reliability; a message that arrives quickly at the wrong user is still a failure.

Repeated input is one of the standard conditions a reliability test should cover, because it is easy to trigger by accident and its effects are easy to overlook. A useful test states what the records should look like afterward, so a run that changes them twice is recognizable as a failure.

• A is not correct: this describes the failure itself; recording the same enrollment twice is the outcome the test is meant to detect.
• C is not correct: removing the student's schedule destroys valid records, which is a far larger failure than the duplicate it was reacting to.
• D is not correct: available space does not make a duplicate correct; the same request should still take effect only once.

A test plan needs both coverage and expectations. The three conditions named here are genuinely different from one another, and pairing each with an expected behavior is what turns a run of the program into a test that can pass or fail.

• A is not correct: stopping at the first success leaves every unusual condition unexamined.
• B is not correct: without a decision about what each result should be, there is no way to tell a correct outcome from an incorrect one.
• D is not correct: an impression of the page is an opinion about appearance rather than evidence about behavior.

Impact analysis asks who is affected and how, not whether the program works. The same change can help one group and disadvantage another at the same time, and saying so is what makes an analysis balanced rather than one-sided.

• B is not correct: executing its instructions is what any working program does; it is not by itself a benefit to anyone.
• C is not correct: whether the code compiles is a question about the program, not about its effect on the people who use it.
• D is not correct: assuming a uniform effect is what hides the group that has difficulty, so it is the opposite of a balanced analysis.

An economic impact is described by asking who spends or earns differently as a result of the program. Here two groups are affected in opposite directions, so an accurate description has to mention both rather than reporting only the side that improved.

• A is not correct: correct calculations describe the program's behavior; the impact is what happens to the company and the workers because of it.
• B is not correct: the purchase price is one cost among several, and it leaves out both the ongoing savings and the reduced hours.
• C is not correct: a benefit to one group is not evidence about the others, and the reduced hours show that the effect is not shared.

Naming the area of impact means asking what kind of thing changed. Here the program did not fail and no ownership question arose; what shifted was the range of music people chose, which belongs to culture.

• A is not correct: the app is producing recommendations as designed, so nothing here indicates a reliability problem.
• C is not correct: recommending a work does not change who owns it or the terms under which it may be reused.
• D is not correct: a change in listening habits is not a measurement of how fast the program runs.

An unintended harmful effect has two features: someone is worse off, and that outcome was not the purpose of the program. Uneven sensor coverage produces exactly this pattern, because the stated intent was to inform the whole city.

• A is not correct: displaying the readings it has is the app working as designed, so no one is harmed by it.
• B is not correct: learning how air quality changes is a benefit, which is the opposite of what the question asks for.
• D is not correct: the length of the title affects no one and has nothing to do with the information residents receive.

Being able to read code is not the same as being free to use it however one likes. An open-source license grants permission and attaches conditions to that permission, so the license is what has to be read before the code is reused.

• B is not correct: open-source code has an owner, and many licenses require attribution as one of their conditions.
• C is not correct: a permanent ban on modification would contradict the permission an open-source license grants.
• D is not correct: downloading a copy does not release it from the terms that came with it.

The responsible sequence happens before integration, not after. When no license grants reuse in advance, permission has to be obtained directly from the owner, and any condition the owner attaches has to be met.

• A is not correct: being visible online does not make code free to use; visibility and permission are separate things.
• B is not correct: renaming variables changes the surface of the code without changing who owns it.
• C is not correct: waiting for a complaint means the code has already been used without permission.

The three steps are ordered because each one depends on the previous answer. The source has to be identified before its license can be located, and the license determines whether the required action is attribution, payment, or nothing at all.

• A is not correct: it integrates first and investigates last, and removing notices can itself violate the terms the team has not yet read.
• C is not correct: claiming someone else's work as original is exactly what identifying the source is meant to prevent.
• D is not correct: paying before checking skips the step that would reveal whether the existing license already permits the reuse.