SYSE.23:11 - SoTA and Source Use
Continued engineering can require changes in a target System, its builder platform or both. Relate those alternatives to product and problem portfolios, characterize the changes they make possible, and examine reversibility and the observations that would reopen a choice. Apply the builder question recursively when changing a builder requires changing its own means of construction.
| Source line | Use here | Epistemic boundary |
|---|---|---|
| Bryan et al. (2007), Co-Evolution of Product Families and Assembly Systems; Tolio et al. (2010), SPECIES—Co-evolution of products, processes and production systems; and Albers et al. (2022), Product-Production-CoDesign | Supplies joint product-family and assembly/production-system design, product–process–production-system coevolution, coupling across generations, future-characteristic treatment, and production reconfiguration. This pattern adopts joint alternative development, adapts it into the system-of-interest–builder relation and the manufacturing branch in steps 4, 6, and 7, and rejects the idea that product architecture can be optimized independently of the production arrangement. | The studies concern manufacturing and product–production settings. They do not establish transfer to software, Methods, organizations, human capability, or every builder arrangement. Those extensions remain bounded engineering syntheses and reopen when a transfer failure changes the practitioner decision. |
| Fricke and Schulz (2005), Design for changeability | Supplies a Systems Engineering account of incorporating changeability into architecture and distinguishes flexibility, agility, robustness, and adaptability across industries. | It is a historical field anchor. Its lifecycle and quality vocabulary does not create one FPF evolvability characteristic or settle the claim subject and system-of-interest–builder relation in this pattern. |
| Ross, Rhodes, and Hastings (2008), Defining changeability | Supplies explicit change agents, change effects, change mechanisms, context change, and tradespace-based changeability distinctions. | Its filtered-outdegree measure answers a declared tradespace question; it is not a universal evolvability scalar and does not include every builder, Method, capability, culture, or evidence relation used here. |
| Ford, Parsons, Kua, and Sadalage (2022), Building Evolutionary Architectures, second edition | Supplies practical software-architecture mechanisms for guided incremental change, several architectural dimensions, fitness functions, deployment pipelines, reversibility, and appropriate coupling. | Software examples do not transfer automatically to physical configuration, manufacturing, integration, safety, assurance, specialist authority, or product-family effectivity. A fitness function is evidence input, not the architecture characteristic itself. |
| MacCormack, Rusnak, and Baldwin (2008), The Impact of Component Modularity on Design Evolution | Supplies empirical motivation and cautions for relating component modularity to later software-design evolution, including the need for repeatable measures and longitudinal evidence. | Software source structure and one modularity construction do not make more modules better or establish causality for another engineering profile. |
| Castle, Stock, and Gorochowski (2024), Engineering is evolution, and Zhang et al. (2025), Darwin Gödel Machine | Supplies bounded examples in which engineers change variation-and-selection arrangements or a lineage-bearing builder that generates later variants. | Bioengineering perspective and coding-agent benchmarks do not establish one universal OEE Method, unrestricted self-improvement, transfer to every system-of-interest–builder arrangement, or cultural selection. |
Assess currentness for each relied-on claim. Reopen a source row only when changed evidence alters the claim kind or subject, change family, architecture relation, transfer limit, decision, or observation used here. Recency alone does not make a Method or mechanism preferable.