Trends Toward Increasing the Value of Systems Engineering
With traditional artifacts such as railroads, reservoirs, and refrigerators, the systems engineer faced a self-contained system, with relatively stable requirements, a sound scientific base, and numerous previous precedents. As more systems are intended to become parts within one or more evolving systems of systems (SoS) featuring rapidly increasing scale, dynamism, interdependence, human-intensiveness, sources of vulnerability, and novelty, the performance of effective SE takes on an ever-higher economic value.
Further Quantitative Evidence of the Value of Systems Engineering
Analysis of the effects of shortfalls in systems architecture and risk resolution (the results of inadequate SE) for software-intensive systems in the 161-project COnstructive COst MOdel II (COCOMO™ II) [1] database, show a statistically significant increase in rework costs as a function of project size measured in source lines of code (SLOC): averages of 18% rework for ten-thousand-SLOC projects, and 91% rework for ten-million-SLOC projects.
This result has helped major system projects to rectify initial underinvestments in SE (e.g., Boehm et al. 2004), and to determine “how much SE is enough” in general by balancing the risks of underinvesting in SE against those of overinvesting (often called “analysis paralysis”).
In general, small projects can quickly compensate for neglected SE interface definition and risk resolution, but as projects get larger, with more independently-developed components, late-rework costs rise much more rapidly than the savings in reduced SE effort. Medium-sized projects have relatively flat operating regions, but very large projects pay extremely large penalties for neglecting thorough SE.
Extensive surveys and case study analyses corroborate these results. Survey data on software cost and schedule overruns in My Life Is Failure: 100 Things You Should Know to Be a Better Project Leader (Johnson 2006) indicate that the primary sources of the roughly 50% of the commercial projects with serious “software overruns” were actually due to shortfalls in SE (lack of user input, incomplete requirements, unrealistic expectations, unclear objectives, and unrealistic schedules). The extensive Software Engineering Institute (SEI) [2] - National Defense Industrial Association (NDIA) [3] survey of 46 government-contracted industry projects showed a strong correlation between higher project SE capability and higher project performance (Elm et al. 2007). Ongoing research combining project data and survey data reported in “Toward An Understanding of The Value of SE” (Honour 2003) and “Effective Characterization Parameters for Measuring SE”(Honour 2010) provide additional evidence of the economic value of SE, and further insights on critical SE success factors.
A calibrated model for determining “how much SE is enough” has been developed in (Valerdi 2008). It estimates the number of person-months that a project needs for SE as a function of system size modified by 14 factors that affect SE effort needed. System size is defined in terms of numbers and complexity of requirements, interfaces, operational scenarios, and key algorithms. The factors that affect SE effort include architecture understanding, technology maturity, legacy-system migration, personnel capabilities, process maturity, and tool support.
Systems Engineering: Historic and Future Challenges
We can view the evolution of Systems Engineering (SE) in terms of challenges and responses. Humans have faced increasingly complex challenges and have had to think systematically and holistically in order to produce successful responses. From these responses, generalists have developed generic principles and practices for replicating success.
Evolution of Systems Engineering Challenges
From 1990 on, rapidly increasing scale, dynamism, and vulnerabilities in the systems being engineered have presented ever-greater challenges. The Internet offers efficient interoperability of net-centric systems of systems (SoS), but brings new sources of system vulnerability and obsolescence as new Internet services (clouds, social networks, search engines, geolocation services, recommendation services, and electrical grid and industrial control systems) proliferate and compete with each other.
Meanwhile, challenges come from several ways in which solution approaches have proliferated:
• While domain-specific model-based approaches offer significant benefits, reconciling many different domain assumptions to get domain-specific systems to interoperate is a challenge.
• The appearance of many competing object-oriented methods posed a problem that was addressed by the development of the Unified Modeling Language (UML) (Booch-Rumbaugh-Jacobson 1998) and the Systems Modeling Language (SysML) (Friedenthal 2008). However, the wave of UML and SysML tools that followed, along with a number of alternative requirements and architecture representations intended to compensate for shortcomings of UML and SysML, again create dilemmas around interoperability and choice.
• Among the areas that have seen a sometimes bewildering growth of alternatives are: enterprise architecture, lean and agile processes, iterative and evolutionary processes, and methods for simultaneously achieving high-effectiveness, high-assurance, resilient, adaptive, and life cycle affordable systems.
This trend towards diversity has increased awareness that there is no one-size-fits-all product or process approach that works best in all situations. In turn, determining which SE approaches work best in which situation, and how to sustain workable complex systems of systems containing different solution approaches, emerges as yet another challenge.
Similarly, assessing and integrating new technologies experiencing increasing rates of change presents further SE challenges. This is happening in such areas as biotechnology, nanotechnology, and combinations of physical and biological entities on the one hand, and mobile networking, social network technology, cooperative autonomous agent technology, massively parallel data processing, cloud computing and data mining technology on the other.
Ambitious projects to create smart services, smart hospitals, energy grids, and cities are underway. These promise improved system capabilities and quality of life, but carry risks of reliance on immature technologies or on combinations of technologies with incompatible objectives or assumptions. The advantages of creating network-centric systems of systems to “see first,” “understand first,” and “act first” are highly attractive in a globally competitive world, but carry challenges of managing complexes of hundreds of independently-evolving systems over which only partial control is possible. SE is increasingly needed but increasingly challenged in the quest to make future systems scalable, stable, adaptable, and humane.
To accommodate this complexity, the SEBoK presents alternative approaches along with current knowledge of where they work best. Being a wiki allows the SEBoK to evolve quickly while maintaining stability between versions.