Process Evolution to Support System of Systems Engineering Jo Ann Lane
Dr. Judith Dahmann
USC CSSE th 941 West 37 Street, SAL 318 Los Angeles, CA 90089-0781 01-858-945-0099
The MITRE Corporation 7525 Colshire Drive McLean, VA 22102-7539 Telephone number, incl. country code
[email protected]
[email protected]
ABSTRACT One of the current research areas at the University of Southern California (USC) Center for Systems and Software Engineering (CSSE) is the development of large scale, software intensive systems of systems (SoS). These SoS are a type of Ultra-LargeScale Software-Intensive System (ULSSIS) that have become increasingly prevalent in both government and commercial sectors. Research activities have focused on cost estimation and risk assessment associated with the development and evolution of these systems. As part of this research, USC CSSE has teamed with others to learn how SoS engineering processes are evolving to support the development of these systems. This paper highlights the findings of these research activities.
Categories and Subject Descriptors K.6.0 [Management of Computing and Information Systems]: General – economics. K.6.1 [Management of Computing and Information Systems]: Project and People Management – life cycle, management techniques, staffing, strategic information systems planning, systems analysis and design, systems development.
General Terms Management, Economics.
Keywords System of systems, system of systems engineering.
1. INTRODUCTION Many organizations are attempting to provide new system capabilities through the net-centric integration of existing systems into systems of systems (SoS). These SoS are a type of UltraLarge-Scale Software-Intensive System (ULSSIS) that have become increasingly prevalent in defense and which have analogs
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Conference’04, Month 1–2, 2004, City, State, Country. Copyright 2004 ACM 1-58113-000-0/00/0004…$5.00.
beyond the defense community, both in government and commercial sectors. Development of these systems poses extraordinary challenges in systems and software engineering for the SoS and for the component systems or services. The engineering activities used to architect and develop these SoS are often referred to as SoS engineering (SoSE). Many have reported that SoSE activities are considerably different from classical systems engineering (SE) activities and that classical SE is not sufficient for today’s SoSs [4]. To better understand SoSE, studies are currently underway to evaluate the differences between classical SE and SoSE, more clearly describe the SoSE processes, and determine the primary cost drivers and associated risks for SoSE. As a result, two complementary approaches for engineering SoS and systems have been identified that provide a new perspective on engineering for large systems: the SoSE model (SoSEM) and the Incremental Commitment Model (ICM). They explicitly recognize the need to directly consider change as an important dynamic of engineering (to, in effect, design for change) and the need to address dimensions in the engineering trade space beyond technical considerations. This paper presents highlights of these findings to date.
2. BACKGROUND: SOSE CHALLENGES Today’s systems engineers are facing challenges with the scope, scale, and shape of system problems in today’s large scale, complex, networked environments. In the world of defense, the environment is increasingly characterized by networks of systems which work together to meet user capability needs. In this environment individual systems are no longer considered as independent bounded entities, but rather as components in larger, more variable, ensembles of interdependent systems that interact based on end-to-end business processes and networked information exchange. Traditional approaches to SE are based on the ability of the systems engineer to define boundaries and requirements clearly and to control the development environment so that requirements can be optimally allocated to components based on technical trade analyses—and these engineering goals are seldom achievable in the SoS environment. Increasingly, systems engineers are challenged to use existing systems as the components of these SoS. They are faced with an allocation of functionality and implementation details which may not be optimal from the SoS perspective. In addition, the SoSE teams lack control over the component systems that retain their
independent ownership, funding, and development processes. This means that the SoS systems engineer needs to take into account considerations beyond the technical when evaluating capability objective options. Also, there is added complexity due to multiple layers of management and technical development and this significantly complicates SE in the SoS context. Finally, the environment changes during development and unanticipated component system changes may have an overriding effect on user capabilities, further complicating the work of the systems engineer.
3. SOSE MODEL The SoSEM was developed as a result of an OUSD AT&L review of current defense programs where SE is being applied in SoS environments. This model, illustrated in Figure 1, addresses SE for ensembles of existing and new systems that together address SoS capability needs [3, 5].
Assessing Assessing (actual) Assessing (actual) performance performance performance to capability to capability to capability objectives objectives
Translating Translating capability Translating capability objectives capability objectives
objectives
objectives
Understanding Understanding Understanding systems & systems & relationships systems & relationships (includes plans) (includes plans) relationships
(includes plans)
Orchestrating Orchestrating Orchestrating upgrades upgrades upgrades to toSoS SoS to SoS
Addressing Addressing Addressingnew new requirements requirements
new &&options options requirements & options
Developing, Developing, Developing, evolving and evolving and maintaining evolving and SoSmaintaining design/arch SoS design/arch maintaining
SoS design
Monitoring Monitoring &Monitoring assessing & assessing &changes assessing changes
changes
External Environment
Figure 1. SoSE Model [5] The SoS is viewed as an overlay on existing and new systems, where the component systems retain their identity and responsibility for the management, engineering, and evolution of the systems. SoS managers and systems engineers do not have full control over the systems, but rather work collaboratively with the managers and systems engineers of the systems to leverage and influence systems’ developments to address SoS needs. There are seven elements that characterize SE for SoS. In SoSE, systems engineers are key players in 1) translating SoS capability objectives into SoS requirements and 2) assessing the extent to which these capability objectives are being addressed, as well as 3) anticipating and assessing the impact of external changes on the SoS. Central to SoSE is 4) understanding the systems which contribute to the SoS and their relationships and 5) developing a design for the SoS which acts as a persistent framework for 6) evaluating new SoS requirements and solution options. Finally the SoS systems engineer 7) orchestrates enhancements to the SoS, monitoring and integrating changes made in the systems to improve the performance of the SoS. Based on current SoSE experience, there are a number of cross cutting approaches that seem to be well-suited to SE in this environment. First, it is important for SoSE to address organizational as well as technical issues in making SE trades and decisions. SoS systems engineers need to acknowledge the role
and relationship between the systems engineering done at the systems versus the SoS level. In general, the more systems engineering the SoS systems engineer can leave to the systems engineers of the individual systems, the better. In addition, technical management of the SoS needs to balance the level of participation required on the part of the systems, encouraging transparency and trust coupled with focused active participation in areas specifically related to the systems and the SoS. There is a real advantage to an SoS design based on open systems and loose coupling that impinges on the systems as little as possible and provides systems with maximum flexibility to address their changing needs and new technology opportunities. Finally, SoS design strategy and trades need to begin early and continue throughout the SoS evolution, which is an ongoing process.
4. ICM The ICM is a risk-driven framework for tailoring system life-cycle processes. The ICM uses risk to determine how much process agility or rigor is enough to satisfy the system’s objectives subject to its constraints. This may vary across different parts of the system, depending on the risks associated with the various parts. And for SoSs, where the component systems are owned and maintained by different organizations, this variation is often unavoidable. The ICM pulls together and integrates a) agile processes for assessing the system environment and user needs and then planning for the implementation of new and modified system capabilities, b) plan-driven (often time-boxed) processes to develop and field new capabilities, and c) continuous verification and validation (V&V) to provide high assurance of the requisite system qualities. The ICM strives to integrate key engineering disciplines (e.g., systems, software, human factors) to develop desired systems and system capabilities in a cost/scheduleeffective manner and to support the evolution of these systems over time to meet changing user needs. The ICM is based upon the premises that many systems of today contain a significant amount of software, the requirements for these systems cannot be specified up front, and the requirements associated with these systems can and do change over time. A key to success is building in system adaptability and flexibility—and software is often the enabler for this needed adaptability and flexibility. Essential to the ICM are its six core principles: 1) commitment and accountability of system sponsors, 2) success-critical stakeholder satisficing, 3) incremental growth of system definition and stakeholder commitment, 4) concurrent engineering, 5) iterative development cycles, and 6) risk-based activity levels and milestones. As part of the ICM research effort, several cases of the ICM have been defined and examples developed to show how the ICM can be tailored to the development of the system of interest [2]. One of these cases is the SoS case. This case shows how one would apply the ICM to the on-going evolution of an SoS. What is different about the SoS case is that the SoSE activities must consider and attempt to synchronize as best as possible, the engineering and development activities of the component systems that comprise the SoS. Figure 2 shows how the activities of the SoSE team and the SoS increment’s suppliers are coordinated and synchronized using the ICM’s Life Cycle Objectives (LCO), Life Cycle Architecture (LCA), and Operational Capability Release (OCR) reviews.
Figure 2. Using the ICM to Synchronize SoS Component System/Supplier Processes. [1] Figure 3 elaborates on this further and shows how the SoSE agile, forward-looking team (using the SoSE elements described above)
works to monitor and guide the SE teams responsible for the SoS component systems.
Figure 3. View of ICM Agile, Plan-Driven, and V&V Processes in an SoSE Environment. [1]
This figure also illustrates how the ICM agile, plan-driven, and V&V processes can also be used by the component system SE teams.
5. SOSE COST ESTIMATION AND RISK ASSESSMENT There are many cost models and associated cost estimation tools to support the estimation of effort for more classical systems engineering and software development activities. As described in [4], these tools are still useful in estimating the effort associated
with the development and evolution of SoS component systems. And now, with this deeper understanding of SoSE processes, one can begin to consider cost models to support the estimation of effort required to evolve and guide the SoS at the SoSE level and to use the cost model parameter values to conduct early risk assessments of the planned SoSE activities. Figure 4 illustrates a conceptual view of the current SoSE cost model under development at USC CSSE. Note that the SoSE sub-models map well to both the ICM agile, plan-driven, and V&V activities as well as to the SoSE elements.
Figure 4. Overview of SoSE Cost Model. The SoSE cost model inputs consist of a set of size drivers (number of SoS capabilities, number of unique SoS interface protocols, number of component system organizations, number of unique component systems, and number of operational scenarios that are part of the concept of operations) that are used to estimate a nominal effort for the SoSE activities of interest plus a set of cost modifiers that provide additional information about the SoS to be developed, the processes used to perform the SoSE activities, and the skills and experience levels of the people that will perform these activities. These cost modifiers are used to adjust the nominal effort up or down, depending on whether the selected value is a positive or negative influence on the nominal effort. The risk assessment evaluates the size drivers and their complexity with the cost modifiers to determine poor or undesirable combinations. For example, “many complex capabilities” and a “low understanding of these capabilities” will flag a high risk in this area. Additional information on the cost model size drivers and cost modifiers can be found in [4].
6. SUMMARY As engineers are increasingly called upon to expand system capabilities through the integration of systems into SoSs and to continue to evolve these SoSs to meet changing user needs, they encounter significant challenges when trying to apply classical engineering processes. Because SoS engineers are starting with existing systems with independent owners, objectives and development processes, they are faced with a new set of conditions for their engineering processes. This paper has presented some new engineering frameworks, the SoSEM and ICM, that reflect the dynamics and uncertainty associated with SoS development and evolution. These frameworks have also been used to develop cost models to better understand the engineering effort associated with these SoSE activities.
7. ACKNOWLEDGMENTS Our thanks to Professor Barry Boehm of the USC CSSE for his ICM work, Kristen Baldwin of OUSD AT&L for her support of the SoS SE Guide and pilot project, and George Rebovich and Ralph Lowry for their work as part of the SOS SE team.
8. REFERENCES [1] Boehm, B. and Lane, J. 2007. Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering. CrossTalk, Vol. 19, No. 10 (Oct. 2007), 4-9. [2] Boehm, B. and Lane, J. 2008. A Process Decision Table for Integrated Systems and Software Engineering. In Proceedings of the Conference on Systems Engineering Research (Los Angeles, CA, USA, April 04-05, 2008). [3] Dahmann, J., Lane, J., Rebovich, G., and Baldwin, K. 2008. A Model of Systems Engineering in a System of Systems Context. In Proceedings of the Conference on Systems Engineering Research (Los Angeles, CA, USA, April 04-05, 2008). [4] Lane, J. and Boehm, B. 2008. Modern Tools to Support DoD Software Intensive System of Systems Cost Estimation. Data and Analysis Center for Software, Rome, NY. [5] Office of the Under Secretary of Defense for Acquisition, Technology and Logistics (OUSD AT&L) 2008. Systems of Systems Systems Engineering Guide: Considerations for Systems Engineering in a System of Systems Environment, Washington, DC: Pentagon, (forthcoming).
