Soft Dev Essay Prelim Drei

In a ride-sharing app like Grab, a new government law at the Social/Society layer requiring drivers to respond to ride requests within a fixed time forces the company to update its organizational policies to remain compliant. These policy changes lead to new business processes, such as stricter dispatch rules, response timers, and temporary driver locks for repeated non-responses. To enforce these processes, the application layer must be updated by adding countdown timers, automatic ride rejection, and lock mechanisms in the app. This shows how a social or legal change ripples down to organizational, process, and application-level changes.

Reliability is an emergent property of the entire system, so it cannot be determined by examining a single software module in isolation. For instance, a medical application may have bug-free calculation code, but the system can still be unreliable if a dead pixel on the display prevents the doctor from reading results, or if a confusing user interface causes the doctor to make an error. This demonstrates that even perfect software cannot guarantee overall system reliability without considering hardware and human factors.

Reliability and safety are related but distinct: reliability means a system consistently follows its specification, while safety means it avoids causing harm. A medical infusion pump can be reliable but unsafe if it delivers the programmed drug dose exactly as specified, but the dose is too high for a particular patient, causing harm. Conversely, the pump can be safe but unreliable if it constantly shuts down due to minor power fluctuations, preventing therapy interruptions and protecting the patient, but reducing system availability. This shows that a system can perform correctly according to spec yet be unsafe, or protect users yet be operationally unreliable.

Risk-driven specification recognizes that system requirements should balance risk rather than aim for impossible perfection. A bank cannot set “100% availability and 100% security” because achieving absolute levels is extremely costly and practically impossible. Instead, resources should focus on high-risk areas, such as preventing database corruption or fraud, rather than low-impact issues like interface appearance. Additionally, diminishing returns apply: increasing availability from 99.9% to 99.99% may cost a huge amount while reducing only a tiny fraction of risk, making it inefficient. Risk-driven specification ensures acceptable safety and reliability at a reasonable cost rather than chasing impractical absolutes.

POFOD and ROCOF are reliability metrics used for different system types. POFOD measures the probability that a system fails when it is demanded, making it suitable for systems used only during specific events. A Fire Alarm System should use POFOD because it is rarely used, but must work correctly when a fire occurs. Measuring failures over time is meaningless if the system is not constantly active. ROCOF measures how often failures occur during continuous operation, making it appropriate for a Social Media Web Server that runs all the time. Using the wrong metric can be dangerous. If ROCOF is used for a Fire Alarm, it may appear reliable because it rarely runs, even if it fails during an actual fire. Keywords: on demand, continuous operation, misleading reliability

Functional reliability requirements describe specific features that improve reliability, while non-functional reliability requirements define measurable reliability targets. In an automated insulin pump, a functional reliability requirement could be that the system continuously monitors glucose levels and automatically stops insulin delivery when abnormal values are detected. A non-functional reliability requirement could state that the probability of failure on demand must be less than 1 in 1,000,000. The functional requirement helps achieve the non-functional goal by actively preventing dangerous conditions and reducing the likelihood of system failure. Keywords: feature vs measurement, mechanism vs target

N-Version Programming and Recovery Blocks are both software fault-tolerance techniques but differ in execution. N-Version Programming runs multiple independent versions of a program in parallel and uses a voting mechanism to produce an immediate result, requiring more hardware. Recovery Blocks execute program versions sequentially, checking results and rolling back if an error is detected, which takes more time. For a flight control system, N-Version Programming is more suitable because it is a hard real-time system that cannot afford the delays caused by rollback; the parallel approach ensures immediate, reliable outputs essential for safety-critical operations.

Forward and backward error recovery handle faults differently depending on system requirements. In missile guidance, which is highly time-critical, forward error recovery is preferred because the system cannot roll back; it must estimate corrections and continue operating in real time. In contrast, a banking system prioritizes data integrity over speed, so backward error recovery is suitable: if an error occurs, the system rolls back to a previously correct state to ensure transactions remain accurate and no money is lost. The choice depends on whether timeliness or correctness is the dominant concern.

Defense-in-Depth is a security strategy that implements multiple layers of protection, such as firewalls, web application firewalls, and encryption, to reduce the risk of a single point of failure. Each layer provides redundancy: if an attacker exploits a zero-day vulnerability to bypass an outer layer like the firewall, inner layers such as encryption or application-level protections can still prevent data compromise. By stacking defenses, the system remains secure even when one layer fails, making attacks harder and mitigating the impact of unknown vulnerabilities.

Security often reduces system performance because measures like heavy encryption or real-time checks consume resources. A manager should determine the acceptable performance degradation using risk management, ensuring the cost of protection—including slower performance—remains less than the potential loss from a security breach. High-value assets, like credit card data, justify stronger security and higher latency, while low-value assets, like a lunch menu, do not. This ensures security is risk-compliant, balancing protection with system efficiency.