Academia.edu no longer supports Internet Explorer.

To browse Academia.edu and the wider internet faster and more securely, please take a few seconds to upgrade your browser.

Log In
Sign Up

Figure from:Systems 2020: Strategic Initiative

See full PDF downloadDownload figure

Another definition of complexity that is often useful distinguishes static measures such as parts count, which it defines as “complicated,” from an operational measure of complexity as “the degree of difficulty in accurately predicting the behavior of a system over time.” (Wade et al 2010a). Often, these are highly correlated, as noted in (DSB 2007) for the growth in thousands of source lines of code (KSLOC) of large commercial software systems such as Red Hat Linux (17,000 KSLOC in 2000; 30,000 KSLOC in 2001) and Windows NT (35,000 KSLOC in 2001; 50,000 KSLOC in 2007), “This increasing size brings with it increasing complexity.” Another definition of complexity that is often useful distinguishes static measures such as parts count, Table 2. Factors Associated with Complexity — Table 2 Another definition of complexity that is often useful distinguishes static measures such as parts count, which it defines as “complicated,” from an operational measure of complexity as “the degree of difficulty in accurately predicting the behavior of a system over time.” (Wade et al 2010a). Often, these are highly correlated, as noted in (DSB 2007) for the growth in thousands of source lines of code (KSLOC) of large commercial software systems such as Red Hat Linux (17,000 KSLOC in 2000; 30,000 KSLOC in 2001) and Windows NT (35,000 KSLOC in 2001; 50,000 KSLOC in 2007), “This increasing size brings with it increasing complexity.” Another definition of complexity that is often useful distinguishes static measures such as parts count, Table 2. Factors Associated with Complexity

Related Figures (29)

Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number.

Table 1. Systems 2020 Transformation of Systems Design and Development 1.4 Systems 2020 Program Risks and Recommended Next Steps

For any threat or opportunity presented to DoD, there is a need to analyze the available solution options and pick the best cost/schedule-effective option for generating the solution. Starting at the top, it may be that none of the available off-the-shelf modeling, platform, or self-adaptive capabilities can generate a solution, and a new solution needs to be built. Then there are several options that may be most cost/schedule effective. Again, starting at the top, the best solution may be to extend an existing model so that it can generate the solution. The net result of this is that the goals of FAST and FLEX are addressed via the rapid solution generation and the increased flexibility of the MBE capability. For any threat or opportunity presented to DoD, there is a need to analyze the available solution options 1.1. Decision Tree Relating Research Areas to Systems 2020 Goals

Figure 2. Software Content of Sample Major DoD Weapons Systems 1960-2020 The right hand curve in Figure 3 shows the program cancellation probability as a function of KSLOC. | indicates that the likelihood of cancellation reaches 50% even at 1250 KSLOC, indicating that the cancellation probability is over 50% for programs the size of Future Combat Systems. Currently, moré and more programs are going for the benefits of net-centric operations, such as the F-35 with it Autonomic Logistics information System (ALIS), which uses net-centric technology to significanth reduce aircraft turnaround time between sorties. As a result, net-centric systems’ software sizé increases significantly (about 14,000 KSLOC for the F-35, including its ground segment, vs. about 3,00( KSLOC for the F-22 airborne software). Given such trends, it is clear that more rapid and trouble-fre: methods of systems and software development are needed. For example, the F-35 ALIS’ use of ar Architected Agile method of development appears to be holding up well. One of the keys to reducin; schedule and cancellation probability for very complex systems is to increase investment in system engineering. cancellation probability is over 50% for programs the size of Future Combat Systems. Currently, more

Figure 3. Development Schedule and Cancellation Probability vs Complexity in SLOC

Figure 4. Effect of Size on “How Much Systems Engineering is Enough?”

In response to the primary Systems 2020 objectives of increasing the speed of development, flexibility for foreseeable change, and adaptability to unforeseeable change, Figure 6 provides a Rapid Application Development (RAD) Opportunity Tree for shortening the critical path from inception to fielding. It was inspired by a presentation by Motorola (Pittler 1997) on their corporate “10X” initiative to reduce their critical-path time by a factor of 10. They only achieved factors of 3 to 4, but such factors are consistent with the Systems 2020 goals. Details on the Opportunity Tree strategies are provided in Appendix B.

A representative Platform Based Engineering investment achieving a factor-of-4 decrease ir development time is shown in Figure 7. In the late 1980s, Hewlett Packard (HP) found that several of it: market sectors had product lifetimes of about 2.75 years, while its waterfall process was taking 4 year: for software development. HP’s investment in a product line architecture and reusable component: increased development time for the first two products in 1986-87, but had reduced development tims to one year by 1991-92 (Lim 1998). Similar Platform Based Engineering initiatives in DoD hardware anc software domains can have similar payoffs in time to first article development.

2.1.3 Model-Based Engineering (MBE)

The MBE solution to address this grand challenge is comprised of four big game-changer ideas: Stakeholder-Centric Concept Engineering, Virtual Design & Modeling, Model Driven Manufacturing, and Complementary Systems Engineering Process, Property, Environment and Mission Models. The lower parts of Figure 8 highlight the role and impact that these ideas would have on traditional system acquisition and development processes. Figure 9 highlights the overall technical approach and the importance of linking all four game changers to create an open-system development environment supporting cross-model change propagation and change impact analysis, and linking CONOPS with produced platforms (manufacturing). The first three game changers are shown to the right of Figure 9; the fourth game changer provides the complementary set of models that determine the appropriate process and context for integrating the first three.

Figure 9. Concurrent Model Development and Integration Framework trust and assurance; and model verification and validation. It is also important to emphasize that the models are not just of the physical system, but also of the system’s information and human aspects, its environment, the processes of its definition and development, and the tradeoffs among the system’s levels-of-service goals such as trust and assurance, reliability, interoperability, and performance. Research challenges include integration of these model areas; integration of models across multiple domains, timescales, and competitive tool vendors; tool trust and assurance; and model verification and validation.

In this figure, an MBE solution is comprised of an integrated, yet modular framework composed o capabilities in eight critical areas that are necessary to achieve the Systems 2020 objectives. The Prioritization & Tradeoff Analysis module provides the capability to input the particular factors relating to the relative value and priority of high-level capabilities of the system under development. The Concept Engineering module provides an interactive, collaborative, multimedia environment to multiple stake holders, along with a library of concept modules, and Reuse and Synthesis capabilities to quickl) construct concepts of operation and other high-level abstract models of the system under development Together these two modules provide critical capabilities in the areas of decision making and provide the front end to continuous verification and validation. The Concept Engineering research thrust noted ir this report is roughly comparable to these two areas in this framework.

Table 3. MBE Thought Leaders ..3 Platform Based Engineering (PBE) Analysis

2.3.2 Adaptive Product Line Architectures The U.S. Military needs fast, flexible and adaptable capabilities (and tools that enable the development of these capabilities) to succeed in unprecedented asymmetric conflicts during the conduct of irregular and hybrid warfare. To this end, adaptive product line architectures go beyond product line architectures (PLAs) in that they address the critical DoD need for long-lived systems that need to adapt and evolve (Madni 2008a,b). As such, adaptive PLAs are a game-changer for advancing the state-of-the- art in PBE for long-lived systems that need to adapt to and evolve in the operational environment. The U.S. Military needs fast, flexible and adaptable capabilities (and tools that enable the development

Table 4. Agility Platform Benefits There is ample evidence in the real world to substantiate these claims. Many companies offer virtualization, including VMWare, SUN (now Oracle), and Microsoft. Cloud computing is being exploited by Forbes.com. In fact, Forbes is hosting its website in Amazon’s Elastic Compute Cloud (EC2) and “paying for use” only, while letting Amazon worry about the hardware.

Figure 12. Exemplar Software Patterns [adapted from (Booch 2007)] Software architectural patterns can either directly apply as system architectural patterns or can apply after re-interpretation of the pattern. An example of the former is model-view-control. An example of the latter is service-oriented architecture. SoA can be reinterpreted at the systems level as capabilities- oriented architecture where the “capabilities” can be delivered through hardware (i.e., physical) platforms or software.

Table 5. Technology Gaps To appreciate these technology gaps, we need to put PBE into perspective for DoD/military applications. To begin with, the typical lifetime of a platform, especially a military platform, spans multiple product generations. Thus, one of the key challenges is to either develop the ability to “predict the future” — a daunting undertaking — or design platforms in a manner that accounts for both expected and unexpected changes down the line. The key questions that need to be answered in this regard include: To appreciate these technology gaps, we need to put PBE into perspective for DoD/military applications.

Table 8. COD Thought Leaders 2.5 Trusted System Design (TSD) Analysis

2.5.2 TSD Thought Leaders

An initial example of this approach has been developed in discussions of Systems 2020 pilot projects in the space domain between USC as a technology agent and Aerospace Corporation and the Air Force's Space and Missile Systems R&D Center. Aerospace has a significant Concept Design Center (CDC) that consists of a large room with roughly 30 workstations that are operated by specialists in structures, propulsion, power management, communications, reliability, cost, operational concept formulation, etc. These are supported by numerous models to accelerate the preliminary design and feasibility evidence generation for alternative solution concepts.

Table 10. Proposed MBE Pilot Projects FINAL TECHNICAL REPORT — Systems 2020 — SERC-2010-TR-00! UNCLASSIFIED electromagnetic compatibility with the battlefield system of systems, open architectures, rapic manufacturing services and trusted supply chains. Natural partners would be ONR and PM JCREW Systems Engineering for future Naval Fleets: Establish a collaborative Navy/CISD DDR&E/SERC pilot project to develop and apply systems engineering methods for decisior making under uncertainty and impact of complexity on costs to affordable fleet modularization An initial pilot application could address ship structural design standards and ship machiner control systems commonality.

3.5 Description of Potential Pilot(s) for Innovative TSD Approaches

With respect to the model in Figure B-1, the RAD Opportunity Tree of sources of cycle time reduction is presented in Figure B-2. Each major source is elaborated below. te ee EEE EES: LOIWYS Business process re-engineering can discover and eliminate non value-adding tasks, such as unnecessary purchase approvals or change control boards operating at too low a level. Reusing assets and automated applications generation can eliminate many tasks, but they require up-front investment in domain architecting and product line infrastructure. Design-to-schedule can also be highly effective, but again requires up-front investment in prioritizing features and architecting so that features can be dropped without ripple effects.

About
Press
Papers
Topics
We're Hiring!
Help Center

Find new research papers in:
Physics
Chemistry
Biology
Health Sciences
Ecology
Earth Sciences
Cognitive Science
Mathematics
Computer Science

Terms
Privacy
Copyright
Academia ©2025