The evidence provided across 40 years of data on the degree of increase in software cost-to-fix versus delay-of-fix is that for large projects, the increase from fixing requirements changes and defects during requirements definition to fixing them once the product is fielded continues to be around 100:1. However, this ratio can be significantly reduced by higher investments in early requirements and architecture verification and validation. As shown by the CCPDS-R project data in Figure 10-6, the ratio can approach 1:1 if the high-risk fixes are addressed early.

The evidence for small projects continues to show ratios around 5:1, but these can also be flattened by the use of outstanding personnel and by Agile methods, such as pair programming and continuous integration, that shorten the delay-of-fix time. Small, noncritical projects can also spread their architecting activity across the life cycle via refactoring, but need to watch out for making easiest-first architectural commitments that cannot be easily undone by refactoring, such as committing to unscalable COTS products or security-incompatible data and control structures.

The evidence provided more recently on the payoff of architecting and risk resolution efforts, such as those on CCPDS-R, is that the location of the highest-payoff “how much architecting is enough” sweet spot is a function of project size and criticality (larger, more critical projects require more architecting investment), but also a function of requirements volatility (more volatile projects would be slowed down by the need to revise extensive documentation). For detailed project planning and budgeting, the sweet-spot numbers need to be adjusted to reflect additional project, personnel, and product-related cost drivers. A recent COSYSMO model is now available to support such adjustments.

Very large projects are likely to have elements that are high in criticality and stability (e.g., safety and security-critical elements), as well as elements that are high in requirements volatility (e.g., user interfaces, external-system interfaces, device drivers, database schemas). In such cases, a hybrid approach using Agile methods for the rapidly changing parts and plan-driven methods for the more stable and high-criticality parts will work, as long as the overall system is based on an architecture using the [Parnas 1979] information-hiding approach of encapsulating sources of change within modules.

Thus, there are no one-size-fits-all solutions for the increasingly rapid change that projects will experience in the future. Large projects or enterprises with a mix of critical and volatile elements are best served by risk-driven process generators, such as the Incremental Commitment Model and risk-driven versions of the Rational Unified Process. These model generators use the degree of developer-supplied evidence of project feasibility to determine project risk. Such evidence is critical to the success of many future projects facing the prospect of having to cope with increasing size, criticality, volatility, and complexity. In addition, the use of such evidence-based models will have the double benefit of reducing risk and adding to the knowledge base of evidence that can be analyzed for further sources of project and enterprise improvement.