Software Engineering Economics¶
Boehm, B. W. (1981). Software Engineering Economics. Prentice-Hall.
Cited by¶
4 citations across 4 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Brandolini's Law
- Software and code review — writing buggy code is cheap; diagnosing and fixing the bug, especially after it has propagated downstream, is expensive.
This sourceDocuments that the cost to fix a software defect rises sharply the later it is found — up to ~100× more in operation than at requirements — so producing a defect is cheap relative to diagnosing and repairing it after it has propagated downstream.
- Software and code review — writing buggy code is cheap; diagnosing and fixing the bug, especially after it has propagated downstream, is expensive.
- External Analytic Challenge
- Reasoning still open to change, with change still cheap relative to the effort already spent on it. An authoring frame whose assumptions were acquired by working the problem, and are therefore cheapest to hold and most expensive to notice. A challenger scored on two separate axes: substantive competence, and non-overlap of occlusion with the author. Access reaching the working rather than the summary, since a challenger shown only conclusions can only challenge conclusions. Probes as named operations — surface the load-bearing assumption, state the strongest rival reading, list the unaddressed failure modes — rather than an open invitation to comment. A return channel carrying an obligation: revise, or record the reasoning for retaining the challenged choice. A schedule anchored to reversal cost rather than to the calendar, and a record that outlives the meeting it happened in.
This sourceEstablishes that the cost of changing a decision rises with the commitment already built on it, which is the quantity a review has to be scheduled against rather than against the calendar.
- Reasoning still open to change, with change still cheap relative to the effort already spent on it. An authoring frame whose assumptions were acquired by working the problem, and are therefore cheapest to hold and most expensive to notice. A challenger scored on two separate axes: substantive competence, and non-overlap of occlusion with the author. Access reaching the working rather than the summary, since a challenger shown only conclusions can only challenge conclusions. Probes as named operations — surface the load-bearing assumption, state the strongest rival reading, list the unaddressed failure modes — rather than an open invitation to comment. A return channel carrying an obligation: revise, or record the reasoning for retaining the challenged choice. A schedule anchored to reversal cost rather than to the calendar, and a record that outlives the meeting it happened in.
- Progressive Refinement from Core Model
- Progressive Refinement from Core Model is the generalized pattern in which (1) a complex phenomenon is modeled by first identifying a simpler, solvable baseline that captures the dominant structure, (2) the full phenomenon is written as baseline + correction, with the correction controlled by a small parameter ε representing distance from the baseline regime, (3) refinements are added systematically and in increasing orders of ε, stopping at the order that meets accuracy requirements, and (4) the pattern's domain of validity is self-diagnostic: as long as each correction is small compared to what it corrects, the refinement is working; once higher-order terms grow comparably to lower-order ones, the baseline is the wrong baseline and no amount of refinement will help.
This sourceFoundational treatment of incremental development cost models and baseline-plus-adaptation frameworks in software engineering.
- Progressive Refinement from Core Model is the generalized pattern in which (1) a complex phenomenon is modeled by first identifying a simpler, solvable baseline that captures the dominant structure, (2) the full phenomenon is written as baseline + correction, with the correction controlled by a small parameter ε representing distance from the baseline regime, (3) refinements are added systematically and in increasing orders of ε, stopping at the order that meets accuracy requirements, and (4) the pattern's domain of validity is self-diagnostic: as long as each correction is small compared to what it corrects, the refinement is working; once higher-order terms grow comparably to lower-order ones, the baseline is the wrong baseline and no amount of refinement will help.
- Validation
- The structured process of confirming that a model, design, system, or claim satisfies its intended specification and solves the right problem in its actual operational context, as Boehm (1981) characterized in his foundational treatment of software engineering economics.
This sourceFoundational text introducing the V&V distinction in software engineering economics: validation confirms the artifact solves the right problem in its actual operational context, while verification confirms specification conformance.
- The structured process of confirming that a model, design, system, or claim satisfies its intended specification and solves the right problem in its actual operational context, as Boehm (1981) characterized in his foundational treatment of software engineering economics.
Verification¶
This reference passed the adversarial substantiation pipeline: it was checked to exist and to support the claim it is attached to. See how references were verified.
Registry ID ref:01db51358e4a · see in the full table