soft dev True or False Prelim drei

If every individual software component in a system is proven to be reliable, the reliability of the entire integrated system is automatically guaranteed

In a sociotechnical system, the "Application Layer" sits directly on top of the "Equipment Layer" without any intermediaries

"Wicked problems" are difficult primarily because the mathematical algorithms required to solve them are too complex for modern computers

A software engineer must consider the "Organizational Layer" because office politics and power structures can cause a technically sound system to be rejected by users

Non-deterministic behavior in a sociotechnical system is often viewed as a failure, but it can also be beneficial when human operators use their judgment to handle unexpected situations

"Repairability" is considered a functional property because it describes a specific function the system performs

The "Communications and Data Management" layer in the system stack typically includes the operating system

Success in a sociotechnical system is defined solely by whether the software code executes without crashing

A change in the "Society Layer" (such as a new privacy law) can force mandatory changes all the way down to the "Application Layer" code

Hardware reliability, software reliability, and operator reliability are independent factors that do not influence one another

Emergent properties can only be measured or evaluated once the system components have been integrated together

It is generally easier to define success criteria for a technical computer-based system than for a sociotechnical system

When investigating a system failure, it is sufficient to look only at the software logs, as human error is rarely the root cause in modern engineering

A system's "Volume" (the space it occupies) is an example of an emergent property that can be easily calculated by summing the volume of its parts

The primary goal of the "Procurement" phase is to write the software code

A system that is 100% available is automatically considered 100% reliable

It is possible for a system to be safe (cause no harm) even if it is unreliable (crashes frequently)

In the context of dependability, a "fault" and a "failure" are synonymous terms that can be used interchangeably

Adding redundancy (e.g., duplicate code modules) strictly increases system reliability without introducing any negative side effects or complexity

Risk-driven specification suggests that it is economically wasteful to apply the highest level of dependability assurance to every single component of a software system

Security is considered a functional requirement because it describes a specific service the system provides to the user (e.g., logging in)

A "hazard" is the actual damage caused by a system failure

Reliability is a deterministic property; if you know the inputs and the code, you can predict exactly when the system will fail

The use of COTS (Commercial Off-The-Shelf) software generally increases the difficulty of proving the safety of a critical system because the source code is often unavailable for analysis

If a software system is mathematically proven to be correct according to its specification, it is impossible for the system to cause an accident

Diversity in engineering (e.g., N-version programming) is used to prevent common-mode failures where the same error exists in multiple backup systems

Operational profiles are used during testing to simulate how the system will likely be used in the real world, rather than testing every theoretical path

Safety-critical systems should be designed so that if they fail, they fail into a known safe state (fail-safe)

Improving the "Repairability" of a system increases its overall "Availability"

It is generally cheaper to add security features to a system after it has been deployed and vulnerabilities are discovered, rather than during the design phase

It is generally possible to test a software system to prove that it has a failure rate of 1 in 100 million (very low probability of failure)

The POFOD (Probability of Failure on Demand) metric is the best choice for a standard banking transaction system that processes millions of requests per day

Functional safety requirements define specific behaviors or functions the system must perform to ensure safety, whereas non-functional requirements define the required level of reliability

The ALARP principle dictates that all risks must be eliminated completely, regardless of the cost

Hazard identification should ideally be performed after the software implementation phase to ensure the code is stable

A "safety case" is a legal lawsuit filed against an engineer after an accident occurs

If a system has a high Mean Time To Failure (MTTF), it automatically implies that the system is safe

Quantitative reliability requirements (using numbers) are often difficult to verify because software failure is usually caused by design errors, not physical wear and tear

A "hazard" and an "accident" are the same thing in safety engineering terminology

Reducing the probability of a hazard occurring is one form of risk reduction; another form is mitigating the damage after the failure occurs

Formal methods (mathematical analysis) can be used to prove that a specification conforms to safety requirements, but they are expensive to implement

Software safety requirements often evolve from an analysis of the hardware and the wider system, rather than just the software itself

Availability is calculated solely based on how many times the system crashes, regardless of how long it takes to fix

In safety-critical systems, it is common practice to identify "excluded" hazards—events that are considered so unlikely they are ignored in the design

A system can meet all its functional requirements (do everything it is supposed to do) and still be considered unsafe

Implementing redundancy in a software system (e.g., N-version programming) reduces the overall development cost because it simplifies the testing phase

Forward error recovery is generally faster than backward error recovery because it does not require restoring a large amount of state data

In a Triple Modular Redundancy (TMR) system, the system can successfully mask a failure even if two of the three modules fail simultaneously

Software diversity (e.g., N-version programming) guarantees that the system will be reliable because it is impossible for independent teams to make the same logic error

The "Acceptance Test" in a Recovery Block architecture must be completely independent of the primary algorithm to be effective

Hardware fault tolerance is generally considered more straightforward to implement than software fault tolerance because hardware components do not typically suffer from "design errors" in the same way software does

Backward error recovery is ill-suited for real-time systems where the output is needed immediately, as the rollback process introduces unpredictable delays

A "fail-stop" system is designed to output incorrect data for a short period before shutting down to allow the user to see the error

Fault tolerance focuses on keeping the system running, whereas fault avoidance focuses on preventing bugs from entering the code in the first place

In N-version programming, the different versions of the software run sequentially (one after the other)

Exception handling in high-level programming languages (like Java try-catch) is a form of forward error recovery

Using Commercial Off-The-Shelf (COTS) components usually increases the risk of common-mode failures if the exact same COTS component is used in redundant channels

Recovery blocks rely on a voting system to determine which output is correct

Checkpointing is a necessary prerequisite for implementing efficient backward error recovery

It is possible to apply diversity to data representations (e.g., storing altitude in meters and feet) to detect computation errors

It is generally considered good engineering practice to delay security considerations until the implementation phase to ensure the functional requirements are fully met first

A system that is 100% secure is theoretically possible if enough resources are invested in formal verification and testing

There is often a direct conflict between security and usability; increasing security controls (like complex passwords) often makes the system more difficult to use

Security risk assessment should be a one-time activity performed at the beginning of the project

The "weakest link" in a security chain is often the human operator rather than the cryptographic algorithms

If a system uses standard 256-bit encryption, the security of the data is guaranteed regardless of how the encryption keys are managed

Asset identification includes intangible items such as the organization's reputation and customer trust, not just physical servers and databases

Authorization must always precede authentication in a standard security interaction

Commercial Off-The-Shelf (COTS) software helps reduce security risks because the vendor assumes full responsibility for all vulnerabilities

An "Attack Tree" is a visual diagram used to model the different paths an attacker might take to compromise a system goal

Security is classified as a functional requirement because it describes specific functions (like logging in) that the system performs

Design for security involves explicit decisions to avoid shared data and to isolate critical assets from public interfaces

Social engineering attacks target the software code directly to bypass firewalls

System availability is considered a component of security because a Denial of Service (DoS) attack aims to compromise it

A security policy should be generic and high-level to allow developers total freedom in how they implement specific controls