ASSIGNMENT 2 · CHAPTER 11
Reliability Engineering: measure before you claim
One step harder than Assignment 1: you still make a bounded decision, but now you must choose a reliability metric, interpret a measured result, and decide whether the evidence really supports release.
- Warm-up
- FIT → MEASURE → BOUND → ACT + EVIDENCE
- Commit Part A
- STRESS → REFIT
- AI declaration + human review
- Export and submit in LMS
1 · WARM-UP · 5 MINUTES · NOT GRADED
A high uptime number can still hide the wrong failure.
A payment service was reachable for 99.99% of a test, but some payment requests returned an error. Does the availability number alone establish reliability of payment authorization?
Show / hide warm-up answer
No written warm-up response is required. Assignment 2 adds only one new burden: make the reliability claim measurable before you defend the operating decision.
Lecture guide and sentence stems
Use the lecture units on reliability vs availability, POFOD / ROCOF / AVAIL, quantitative reliability requirements, fault-tolerant architectures, operational profiles, Rule 15 — AI assist + human sign-off, and the Decision Card.
FIT: Failure means …; the metric that fits this service is … because …
MEASURE: Observed rate = …; compared with the stated target, this means …
BOUND: This conclusion is valid only while …; reopen if …
ACT + EVIDENCE: My release decision is …; the mechanism is …; the evidence is …
READ BEFORE ANSWERING
How your work is assessed · 5 points
| Criterion | Scoring |
|---|---|
| FIT · 1 point | 1: Defines the relevant service failure, selects an appropriate reliability metric, and links the metric to the demand pattern. 0.5: Plausible metric with an incomplete reason. 0: Metric is absent or materially misinterpreted. |
| MEASURE · 1 point | 1: Correctly computes/interprets the observed failure rate and compares it with the stated requirement without overstating what the test proves. 0.5: Correct direction but incomplete calculation or interpretation. 0: Material calculation/interpretation error or invented result. |
| BOUND · 1 point | 1: States the operating/test conditions that make the claim applicable and a clear trigger to reopen it. 0.5: Boundary or trigger is only partly specified. 0: Boundary is absent, uncheckable or contradictory. |
| ACT + EVIDENCE · 1 point | 1: Gives a feasible release/restrict/hold action, relevant reliability mechanism, responsible role, and inspectable evidence tied to the boundary. 0.5: Action/evidence is concrete but weakly connected. 0: The plan is not defensible or relies on fabricated evidence. |
| REFIT · 1 point | 1: Explains what the new evidence does to the original claim, justifies RETAIN/REVISE/REPLACE, and gives a coherent final record. 0.5: Plausible final choice but weak connection to the original evidence/boundary. 0: Material contrary evidence is ignored. |
The increase from Assignment 1 is deliberately small: one additional scored step — MEASURE. Any REFIT choice can still earn full credit when it is defended.
جاهزية / ETEC alignment used in this task
This task practises GKU 7 · System Paradigms. Reliability requirements exercise SKU 7.1 (functional vs non-functional requirements), while the evidence and post-STRESS decision exercise SKU 7.2 (testing and acceptance). The assignment does not claim to replace the national readiness assessment.
Before you start
Use Save draft while working and Download draft / backup before leaving a shared device. Part A becomes read-only only after you confirm commitment. You can continue editing Part B afterward.
The new evidence opens automatically after you commit Part A. No unlock code is required. Your initial reasoning stays saved and read-only. The sequence is designed to preserve your first judgment; it is not a secure examination system.
Identity
Loaded from the entry page. Drafts are separated by Student ID in this browser.
Submission details
Check the current deadline and submission instructions in the LMS.
2 · PART A · 20 MINUTES
Assessed scenario · fictional university payment authorization service
A candidate release of a fictional university payment-authorization service will be used during registration week. The service handles many short, similar requests. The stated non-functional requirement is: ROCOF shall be no greater than 0.0005 authorization failures per payment transaction during registration service hours.
In the latest reliability test, the candidate processed 20,000 payment-authorization transactions and logged 6 authorization failures. The service was reachable for 99.98% of the test period. Two application instances run behind automatic failover. The test report says the dataset is “registration-like,” but the detailed operational-profile distribution is not included in the brief you received. No duplicate confirmed payments were found in the inspected sample, but the duplicate-payment audit is not yet complete.
You are the duty software engineer preparing a recommendation to the service owner. Choose one immediate action: release, release with explicit restrictions/conditions, or hold. Your recommendation must distinguish what the measured data supports from what remains unverified.
Aim for 300–450 focused words overall. One simple calculation is required. No code or external experiment is required. Cite at least one relevant Chapter 11 unit/title or source page supporting your metric/mechanism.
A1 · FIT · 1 POINT
Define what counts as failure for the payment-authorization service. Select the primary metric (POFOD, ROCOF/MTTF, or AVAIL) and explain why it fits this usage pattern. You may mention a secondary metric, but identify one primary metric.
A2 · MEASURE · 1 POINT
Calculate the observed authorization failure rate from the supplied numbers. Compare it with the stated ROCOF requirement. Then state one sentence about what this comparison does not prove.
A3 · BOUND · 1 POINT
State the operational/test conditions your conclusion depends on and a trigger that would make you reopen it. Include at least one uncertainty visible in the scenario.
A4 · ACT + EVIDENCE · 1 POINT
State release / restricted release / hold, the condition behind it, one reliability mechanism you rely on, and the responsible role.
Name the relevant test/log/audit, the conditions it must cover, who checks it, and what evidence is still missing. Do not describe requested evidence as if it already exists.
Commit is not LMS submission. Confirmation freezes FIT, MEASURE, BOUND, ACT and EVIDENCE before the new information appears.