Software Engineering Economics¶
Boehm, B. W. (1976/1981). Software Engineering Economics. Prentice-Hall.
Cited by¶
6 citations across 6 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.
Mechanisms¶
- Immediate Feedback Routing
- Its strength is that it collapses the distance between error and correction to nearly zero, and the cost of fixing a defect rises sharply the later it is caught
This sourceShows that the cost of correcting a software defect rises sharply when it is discovered later in the development lifecycle.
- Its strength is that it collapses the distance between error and correction to nearly zero, and the cost of fixing a defect rises sharply the later it is caught
- Independent Estimate Round
- The producer runs a Wideband-Delphi-style round.
This sourceIdentifies the private, facilitated, iterative estimate round as a Wideband-Delphi-style procedure.
- The producer runs a Wideband-Delphi-style round.
Verification¶
Does it exist? Not checked yet. This entry carries no identifier to resolve. It was extracted from the citation as written in the article, normalized, and deduplicated against the rest of the registry.
Does it back the claim? Not recorded. Neither this nor any other of the 6 citations of this work carries a recorded support check.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Links previously used in the corpus¶
Before the registry existed this work was also linked 2 other ways.
- https://archive.org/details/softwareengineer0000boeh ×1
- https://search.worldcat.org/nl/title/software-engineering-economics/oclc/1171601782 ×1
Registry ID ref:01db51358e4a · see in the full table