Development Strategies for Critical Software — Advantages and Disadvantages

(1) Produces detailed documentation satisfying regulatory and certification authority requirements — essential for safety-critical systems,Strategy A (plan-driven)

(2) Requirements gathered from engineers and regulators are likely to be stable and complete — reducing the risk of late-stage surprises,Strategy A (plan-driven)

(3) Inflexible to requirements changes discovered during development — rework is expensive once the full specification is committed,Strategy A (plan-driven)

(4) Allows stakeholders to interact with a working prototype and refine requirements before committing to final implementation — reduces risk of building the wrong system,Strategy B (prototype then redevelop)

(5) Two-phase development (prototype then final implementation) is expensive and time-consuming,Strategy B (prototype then redevelop)

(6) Allows experienced software engineers and users to validate functional requirements through prototyping before formal development,Strategy B (prototype then redevelop)

(7) Agile approach works well only when a customer can be closely involved — in a critical system with regulatory stakeholders this involvement is hard to sustain,Strategy C (agile with on-site user)

(8) Informal documentation inherent in agile may be insufficient to satisfy the certification authority requirements for safety-critical software,Strategy C (agile with on-site user)

Explanation

Strategy A (plan-driven): produces documentation for regulatory approval; stable requirements from engineers and regulators; but inflexible to changes. Strategy B (prototype then redevelop): allows requirements validation through prototyping; engineers and users interact with working system before final development; but two-phase development is expensive and slow. Strategy C (agile): customer involvement is hard to sustain with regulatory stakeholders; informal documentation is likely insufficient for safety certification.