GK One-Line Question & Answer

Reliability is the probability the system will perform its required function without failure for a specified time period; availability is the proportion of time the system is operational and accessible when needed

Architecture describes the high-level structure of a software system — its principal components, their relationships, and the fundamental principles governing their design; design elaborates the internal details of individual components

Non-functional testing verifies quality attributes like performance, security, and usability rather than specific behaviours; it often requires the entire integrated system under realistic load and cannot be decomposed into unit tests

Risk mitigation reduces the probability or impact of a risk before it occurs; risk contingency is a plan activated only if the risk actually materialises — reactive rather than preventive

SCM controls evolution of software products; its four activities are: configuration identification, change control, status accounting, and configuration auditing

Cleanroom SE uses mathematical specification, structured design, and statistical testing to certify a software's mean time to failure — providing quantifiable, statistically defensible reliability certificates

CMMI integrates multiple CMM models (software, systems, acquisition) into one framework and supports both staged and continuous representations, while CMM was software-specific and staged only

Prototyping builds a quick partial implementation to elicit requirements or prove feasibility; it fails when the prototype becomes the product — teams ship poorly structured throwaway code as the final system

V-model maps each development phase to a corresponding verification/validation activity — design decisions and test planning occur in parallel, enabling earlier defect detection than Waterfall

Timeboxing fixes the delivery date and varies scope — delivering the best possible product within a fixed time rather than a fixed scope by a variable date; solving the tendency of software to expand indefinitely

SPI systematically analyses and modifies development processes to improve quality, predictability, and efficiency; studies (SEI, Brodman & Johnson) show typical ROIs of 3:1 to 9:1 but only when sustained over multiple years

DevOps extends the software lifecycle by unifying development and operations, enabling continuous delivery through automation of build, test, and deployment — breaking the traditional handoff barrier between dev and ops teams

FDD plans and delivers based on a feature list derived upfront from domain modelling; XP is customer-driven with features emerging through ongoing collaboration. FDD provides more predictability for large teams; XP more flexibility

DAD is a hybrid process framework that provides choice and pragmatism — it acknowledges that different situations need different approaches and provides a toolkit of agile and lean strategies rather than prescribing one method

MDE creates software from formal models (platform-independent and platform-specific) using automated transformation — assuming models are more productive than code as the primary engineering artefact

Continuous experimentation applies the scientific method to product development: forming hypotheses about user behaviour, running controlled A/B tests in production, measuring outcomes, and making data-driven decisions rather than opinion-driven ones

To analyse and document what the system must do from a user/stakeholder perspective — producing an SRS that serves as the contract between customer and developer

Phase containment means detecting and fixing defects within the phase that introduces them rather than allowing them to propagate to downstream phases where fix cost multiplies

Big bang integration combines all modules simultaneously at the end of development — when multiple simultaneous interface failures occur, isolating and diagnosing individual faults becomes extremely difficult because interactions mask individual defects

Modified Waterfall allows controlled feedback loops between adjacent phases — if design reveals a requirements gap, requirements can be revisited without restarting the entire project

In long projects (18+ months), freezing requirements at initiation means the business environment, regulations, and technology may have changed substantially by delivery, producing a system that is obsolete on release day

A structured record of all design decisions, rationale, alternatives considered, and open issues maintained throughout development — providing traceability and institutional memory that reduces rework when key developers leave

The operational concept describes how the end system will be used in its operational environment — produced by the customer/user representative to ensure the development team understands usage context before writing requirements

DoD found that rigid document-driven Waterfall produced systems that were late, over budget, and often failed to meet operational needs — leading to replacement with iterative methods (MIL-STD-498, then DoD's adoption of agile)

The risk finding should halt further development investment until the sensor technology gap is resolved through: sourcing better sensors, redesigning the algorithm to work with available accuracy, or revising the system requirements with stakeholders

LCA must demonstrate that the architecture is stable enough to support the full system, that all top architectural risks have been resolved, and that the construction phase can proceed without fundamental architectural rework

The planning game splits responsibility: business decides scope and priority (story selection, release dates); technology decides estimates and technical approach (how long, how to implement) — neither can override the other's domain

Test-first programming in XP applies at unit level within the context of frequent release, refactoring, and customer collaboration; TDD is a more general design technique applicable across any development context regardless of other XP practices

Collective code ownership means any developer can improve any code at any time without permission; it introduces the risk of uncoordinated changes causing integration conflicts — managed through CI, test suites, and coding standards

Sustainable pace means working at a pace that can be maintained indefinitely — empirical evidence shows that sustained overtime increases defect rates (fatigue reduces judgment), destroys team morale, and rarely recovers schedule because defect rework consumes the gained time

That independently developed and unit-tested modules work correctly together when combined — specifically verifying interfaces, data exchange contracts, and interactions between integrated components

In a walkthrough, the author leads reviewers through the work product explaining it; in a formal inspection (Fagan), the author is silent while trained inspectors systematically examine the work against checklists — inspections find more defects per hour

By repeating risk identification at every cycle — earlier unknowns may become known as the project progresses and domain understanding deepens, allowing them to be addressed before they become crises

Each Spiral cycle represents a deliberate investment decision — stakeholders review risk status before committing to the next cycle, allowing early termination if the risk-adjusted value of continuation is negative

Win-win Spiral adds a stakeholder negotiation activity at each cycle's start — addressing the problem that different stakeholders have conflicting objectives, ensuring all parties agree on conditions of satisfaction before proceeding

Technical risks concern feasibility (can we build it with available technology?); project risks concern management factors (schedule, cost, staffing, dependencies) — both categories must be analysed in each Spiral cycle

The overall system development follows a Spiral, and each major subsystem may independently use its own Spiral within the context of the system-level spiral — allowing subsystem-specific risk management while aligning to system milestones

The variable number of Spiral cycles makes firm fixed-price commitments difficult — the total cost and duration are not determinable upfront because the number of risk-resolution cycles needed cannot be predicted with confidence

Spiral prioritises features and work items by their risk reduction value — resolving highest-risk unknowns first regardless of business value; Agile prioritises by customer value — delivering highest-value features first regardless of technical risk

In the first cycle's objective-setting and risk-identification quadrant, competitive analysis identifies business risks (will the product differentiate from competitors?) and informs the system's operational concept — ensuring the product addresses a real market need before technical investment