Second quality lecture. Lecture 1 gave the tools (scenarios and tactics); this one applies them to each major quality attribute in turn.

Each quality gets a definition, an example scenario, and its tactics.

The table repeats Chapter 2’s one-line descriptions: usability (complexity of learning or using), modifiability (complexity of changing), security (protecting information), performance (useful work under time and resource limits), reliability (failure rate), portability, testability, availability (uptime), interoperability.

Availability is concerned with system failure and the duration of failures. A failure means the system does not provide the service it was intended for.

Modifiability is about the cost of change, in time and money.

Performance is about timeliness: events occur and the system must respond to them in time.

Security is the ability to prevent or resist unauthorised access while still serving legitimate users. An attack is an attempt to breach security.

Testability is how easily the software can be made to demonstrate its faults. To be testable, a system must let testers control its inputs and observe its outputs.

Usability is how easy it is for users to accomplish tasks, and what support the system gives them to do so.

The general availability scenario lists every possible value of each part. Pick one value per column to write a concrete scenario.

Source: internal or external to the system. Stimulus (the fault): crash, omission, timing, no response, incorrect response. Artifact: processors, communication channels, persistent storage.

Environment: normal operation, start-up, shutdown, repair mode, degraded (fail-safe) mode, overloaded. Response: prevent the failure, log it, notify users or operators, disable the source, or be temporarily unavailable.

Measure: time interval available, availability %, detection time, repair time, degraded-mode time interval, unavailability time.

A concrete availability response: if a server becomes unresponsive, switch to a backup server, reallocate resources, or take other corrective action to keep the service running.

The response measure judges how well the response worked, focusing on its effect on the whole system: the time taken to restore service, or whether the system kept operating with no downtime.

The right-hand box repeats the six parts with examples: source (user, attacker, system), stimulus (request, failure, attack), environment (under load, during maintenance), artifact (database, server, UI), response (log, retry, deny access), measure (under 2 s, 99% uptime).

Fault detection: ping/echo (send a ping, expect an echo), heartbeat (a component sends a regular “I’m alive” signal; a missing beat means a fault), exceptions (catch the error when it happens). The goal is to find faults quickly.

Recovery – preparation and repair: voting (several components compute the result and the majority wins), active redundancy (a duplicate runs in parallel, ready to take over instantly), passive redundancy (the backup starts only when the primary fails), spare (a standby that must be configured before use).

Recovery – reintroduction brings a repaired part back: shadow (run it alongside the active one, or keep a shadow copy of the state, e.g. a database shadow page to fall back to), state resynchronisation (bring its data up to date with the others, e.g. sessions and caches after a server restarts), rollback (restore a previous good state).

Prevention stops faults recurring: removal from service (take a failing component out, e.g. switch off a payment gateway that keeps failing and route customers to another), transactions (all-or-nothing updates), process monitor (watch processes and restart them). The diagram: a fault enters, tactics act, and the fault is masked or repaired.

Three modifiability scenarios, differing by who wants the change. End user: cannot change the code, so they request changes (“I want dark mode”, “it’s too slow with 500 users”). Environment: run time. Artifact: interfaces, resources, configuration. Response: developers or admins implement and redeploy. Measure: cost in money, time, downtime and user satisfaction.

Developer: adds, modifies or deletes functionality or qualities (refactoring, improving security). Environment: design, compile or build time. Artifact: code, components, data. Response: implement → test → integrate. Measure: coding and testing effort, complexity of the changed artifacts.

System administrator: changes capacity or technology (scale servers, upgrade the database, adjust configuration). Environment: initialisation or run time. Artifact: configurations, resources, deployment environments. Response: apply → redeploy → test stability. Measure: downtime, effort, risk of errors.

End user version: a user requests a feature or reports a bug that affects the UI or a function; feedback is handled during updates at run time; the team updates the UI or function; success = user satisfaction and fewer complaints.

Developer version: a developer wants to enhance the UI; the change affects the UI code; it is made at design time; the developer updates and tests it; success = done and tested within three hours (the classic sample scenario on slide 9).

Administrator version: the system faces more load or needs stronger security; scripts, network setup and security settings change during live operation or planned downtime; success = better reliability, faster responses, improved security.

The textbook’s sample modifiability scenario: source developer; stimulus wishes to change the UI; artifact code; environment design time; response change made and unit tested; response measure in three hours. Memorise this one as the model answer shape for a modifiability scenario.

Localise changes: assign responsibilities so a likely change touches as few modules as possible. Tactics: semantic coherence (keep related responsibilities together), anticipate expected changes, generalise the module, limit possible options, abstract common services. Changing the UI should only touch UI components.

Prevent ripple effects: stop a change in one module from forcing changes in others. Tactics: hide information, maintain existing interfaces, restrict communication paths, use an intermediary. Updating a banking app’s UI must not affect how account data is processed.

Defer binding time: postpone decisions as late as possible, ideally to run time, so changes need no recompile. Tactics: runtime registration, configuration files, polymorphism, component replacement, adherence to defined protocols. Example: a UI theme read from a config file at run time instead of hard-coded; a language the user can switch while the app runs.

The response measures for modifiability are costs: time, effort and complexity of implementing the change. The diagram’s output: changes made, tested and deployed within time and budget.

Environment for performance: normal mode, overload (beyond usual capacity), reduced capacity (maintenance or partial failure), emergency (high-priority work first), peak (highest expected demand). The same system may meet its target in one mode and fail in another.

Stimulus = how events arrive: periodic (regular, e.g. daily backups), sporadic (occasional and unpredictable, e.g. a sudden large upload), bursty (sudden spikes, e.g. everyone logging in at once), stochastic (random with a probability distribution, e.g. network traffic). Source: internal (a process) or external (users, other systems). Artifact: the component whose performance matters (server, database, network). Response: process the events, or change the level of service (degrade non-essential services to protect core ones).

Measures: latency (delay before work starts, e.g. 2 s before a video plays), deadline (latest finish time, e.g. payment confirmed within 5 s), throughput (work per unit time, e.g. 1,000 requests/minute), jitter (variation in response time), miss rate (share of deadlines missed, e.g. 2 of 100 frames = 2%), data loss (data that never arrives).

The sample performance scenario: source users; stimulus initiate transactions; artifact system; environment normal operation; response transactions are processed; response measure average latency of two seconds. The same scenario as Lecture 1, slide 10.

Resource demand: reduce the work that reaches the system. Tactics: increase computational efficiency (better algorithms), reduce computational overhead, manage the event rate, control the frequency of sampling.

Resource management: make better use of the resources you have. Tactics: introduce concurrency (process requests in parallel), maintain multiple copies (of data or computations, e.g. caches and replicas), increase available resources (faster CPU, more memory).

Resource arbitration: decide which task gets a contended resource first, through a scheduling policy (FIFO, priority, deadline-first). Events arrive, the tactics act, and the response is generated within time constraints.

The general security scenario. Read the first three columns: source an identified user, an unknown user, or a hacker from outside or inside the organisation.

Stimulus: an attempt to display, modify or delete data, or to access system services. Artifact: system services, data within the system, a component or resource, data produced or consumed by the system.

Careful: the Environment, Response and Measure columns on this slide (normal/overload/peak mode; process events; latency, throughput, jitter) are the performance scenario’s values, copied by mistake. For security, the textbook uses: environment online/offline, connected or not, behind a firewall or not; response authenticate, block access, encrypt, log and notify; measure time or effort to break in, probability of detecting the attack, how much data was exposed, time to restore. Use those in an exam.

A concrete security scenario. Source: a dissatisfied person (e.g. an employee) working from a remote location. Stimulus: the attempt to modify pay-rate data.

Artifact: the targeted payroll data. Environment: normal operation.

Response: the system maintains an audit trail, a record of who did what and when, so the change can be traced.

Response measure: how quickly the correct data is restored and whether the source of tampering is identified (the textbook version: correct data restored within a day, source identified).

Resisting attacks (keep them out): authenticate users (who are you?), authorise users (what may you do?), maintain data confidentiality (encryption), maintain integrity (checksums, hashes), limit exposure (fewer entry points), limit access (firewalls, need-to-know).

Detecting attacks: intrusion detection, comparing traffic and behaviour against known attack patterns.

Recovering from an attack: restoration (uses the availability tactics, “see availability” in the tree) and identification of the attacker through an audit trail. The output: the system detects, resists or recovers from attacks.

The general testability scenario. Source: unit, integration, system or acceptance tester, an end user, or automated testing tools.

Stimulus: tests are executed because a code increment is complete. Artifact: the portion of the system being tested. Environment: design, development, compile, integration, deployment or run time.

Response: execute the test suite and capture results, capture the cause of a fault, control and monitor the system’s state. Measures: effort to find a fault, effort to reach a coverage %, probability that the next test reveals a fault, time to perform tests, effort to detect faults.

A concrete testability scenario. Source: the unit tester. Stimulus: a code unit is completed. Artifact: that code unit.

Environment: the development environment. Response: the test results are captured.

Response measure: 85% path coverage within three hours. Coverage plus a time limit makes the testability goal checkable.

Manage input/output: control what goes in and observe what comes out. Tactics: record/playback (capture real inputs and replay them to reproduce a failure), separate interface from implementation (swap in test doubles behind the interface), specialised access routines/interfaces (test-only hooks into a component).

Internal monitoring: built-in monitors that expose the component’s internal state (counters, logs, performance data) during testing. The diagram: an increment is completed, the tactics act, and faults are detected.

The general usability scenario. Source: an end user, possibly in a special role. Stimulus: what the user wants: use the system efficiently, learn it, minimise the impact of errors, adapt it, configure it.

Artifact: the system, or the part the user is interacting with. Environment: run time or configuration time. Response: provide the features needed and anticipate the user’s needs.

Measures: task time, number of errors, number of tasks accomplished, user satisfaction, gain of user knowledge.

A concrete usability scenario. Source: users. Stimulus: downloading and starting a new app. Artifact: the system that runs the app.

Environment: at run time, while the app is used. Response: the user can use the app effectively almost immediately.

Response measure: the user is productive within two minutes of starting the app. That number is what makes “easy to learn” testable.

Separate the user interface from the system’s operations, so the UI can change on its own. Example: a blog platform’s visual editor changes the design without touching the code (MVC in Chapter 4 does exactly this).

Support user initiative: give users tools to manage their own actions: cancel (remove items before checkout), undo (revert an edit), aggregate (combine many items into one, e.g. a weekly activity summary).

Support system initiative: the system anticipates the user using models: a user model (recommendations from viewing history), a system model (sync the most important emails first), a task model (deadline reminders from the project timeline).

For each major quality you should be able to give the definition, write a general and a sample scenario, and name its tactics.

Next chapter: architecture patterns, ready-made structures that bundle several of these tactics (e.g. MVC separates the UI, a broker hides locations).

The exercise: give one tactic per quality attribute. Name the tactic, not the quality again.

Model answers from the slide: security resisting or detecting attacks, authenticate users; testability separate interface from implementation; modifiability localise changes, encapsulation, hide information; performance concurrency, increase available resources. Add availability: heartbeat or redundancy, and usability: undo or cancel.