1. System of Systems Engineering and Process Synchronization Jo Ann Lane jolane@usc.edujolane@usc.edu University of Southern California Center for Software Engineering © USC CSE 2008

2. Lane: SoSE and Process Synchronization © USC CSSE 20082 Overview System of Systems (SoS) and SoS Engineering (SoSE) Environment Life Cycle Implications ICM SoS Special Case Process Synchronization in an SoSE Environment Conclusions

3. Lane: SoSE and Process Synchronization © USC CSSE 20083 Key Definitions System of Systems (SoS) –Very large systems developed by creating a framework or architecture to integrate constituent systems –Typically software-intensive and net-centric –SoS constituent systems independently developed and managed –SoS constituent systems have their own purpose –Constituent systems can dynamically come and go from SoS System of Systems Engineering (SoSE) –“The process of planning, analyzing, organizing, and integrating the capabilities of a mix of existing and new systems into a system-of- systems capability that is greater than the sum of the capabilities of the constituent parts. This processes emphasizes the process of discovering, developing, and implementing standards that promote interoperability among systems developed via different sponsorship, management, and primary acquisition processes.” [USAF 2005]

4. Lane: SoSE and Process Synchronization © USC CSSE 20084 Recent Research Findings* Many types of SoS and associated modes of SoSE –Directed (example: Future Combat Systems) –Acknowledged (most SoSs with a defined SoSE team to guide, but not manage constituent systems) –Collaborative (example: Internet) –Virtual (examples: Web/social systems) SoSE Teams: Varying degrees of responsibility and authority Incorporating many agile-like approaches to handle –Multiple constituent systems –Asynchronous activities and events –Quickly take advantage of opportunities as they appear SoSE –Must support multiple purposes and visions –Requires significantly more negotiation –Is content to satisfice rather than optimize SoSE activities map to traditional SE activities (e.g., DAG and EIA 632), but take on a different focus and scope * Based on USC CSSE SoSE cost model research and OSD SoS SE pilot studies

5. Lane: SoSE and Process Synchronization © USC CSSE 20085 SoSE Compared to Traditional SE Activities: Reported Differences Architecting –Architecting composability vs. decomposition (Meilich 2006) –Net-friendly vs. hierarchical (Meilich 2006) Prototypes/experimentation/tradeoffs –Early tradeoffs/evaluations of alternatives (Finley 2006) –Intense concept phase analysis followed by continuous anticipation; aided by ongoing experimentation (USAF 2005) –Modeling and simulation, in particular to better understand “emergent behaviors” (Finley 2006) –First order tradeoffs above the component systems level (e.g., more optimal at the SoS level, instead of at the component system level) (Garber 2006) –Discovery and application of convergence protocols (USAF 2005)

6. Lane: SoSE and Process Synchronization © USC CSSE 20086 SoSE Compared to Traditional SE Activities: Reported Differences (continued) Scope and performance –Added “ilities” such as flexibility, adaptability, composability (USAF 2005) –Human as part of the SoS (Siel 2006, Meilich 2006, USAF 2005) –Organizational scope defined at runtime instead of at system development time (Meilich 2006) –Dynamic reconfiguration of architecture as needs change (Meilich 2006) Maintenance and evolution –Component systems separately acquired and continue to be managed as independent systems (USAF 2005)

7. Lane: SoSE and Process Synchronization © USC CSSE 20087 SoSE Core Elements* Translating capability objectives Translating capability objectives Translating capability objectives Addressing new requirements & options Addressing new requirements & options Addressing new requirements & solution options Understanding systems & relationships (includes plans) Understanding systems & relationships (includes plans) Understanding systems & relationships External Environment Developing, evolving and maintaining SoS design/arch Developing, evolving and maintaining SoS design/arch Developing and evolving SoS design Assessing (actual) performance to capability objectives Assessing (actual) performance to capability objectives Assessing performance to capability objectives Typically not the role of the SE but key to SoS [assumes these are fixed] Block upgrade process for SoS Persistent framework overlay on systems in SoS [architecture] Large role of external influences Orchestrating upgrades to SoS Orchestrating upgrades to SoS Orchestrating upgrades to SoS Monitoring & assessing changes Monitoring & assessing changes Monitoring & assessing changes * [OUSD AT&L, 2008]

8. Lane: SoSE and Process Synchronization © USC CSSE 20088 SoSE Compared to Traditional SE Activities: Key Challenges for DoD SoSE Business model and incentives to encourage working together at the SoS level (Garber 2006) Doing the necessary tradeoffs at the SoS level (Garber 2006) Human-system integration (Siel 2006, Meilich 2006) Commonality of data, architecture, and business strategies at the SoS level (Pair 2006) Removing multiple decision making layers (Pair 2006) Requiring accountability at the enterprise level (Pair 2006) Evolution management (Meilich 2006) Maturity of technology (Finley 2006) For the most part, SoSE appears to be SE+ organized in new ways and with new challenges

9. Lane: SoSE and Process Synchronization © USC CSSE 20089 Life Cycle Implications For the SoS, the life cycle model and associated processes need to –Identify and respond to change quickly –Combine both rigor and agility to provide needed SoS capabilities in the needed timeframe –Provide for extensive modeling and simulation early on to Investigate alternatives and potential new technologies Understand potential SoS emergent behaviors –Provide flexibility to handle the asynchronous nature of constituent system upgrades and evolution For the constituent systems, the life cycle model and associate processes need to –Accommodate the expanding number of stakeholders as the system becomes part of one or more SoSs –Attempt to synchronize (to the extent possible) the implementation of their part of SoS capabilities with other constituent systems

10. Lane: SoSE and Process Synchronization © USC CSSE 200810 What is the ICM? Risk-driven framework for tailoring system life-cycle processes Integrates the strengths of phased and risk-driven spiral process models Synthesizes together principles critical to successful system development –Commitment and accountability of system sponsors –Success-critical stakeholder satisficing –Incremental growth of system definition and stakeholder commitment –Concurrent engineering –Iterative development cycles –Risk-based activity levels and anchor point milestones Principles trump diagrams… Used by 60-80% of CrossTalk Top-5 projects, 2002-2005

11. Lane: SoSE and Process Synchronization © USC CSSE 200811 Common Risk-Driven Special Cases of the ICM Special CaseExampleSize, Complexity Change Rate % /Month CriticalityNDI SupportOrg, Personnel Capability Key Stage I Activities : Incremental Definition Key Stage II Activities: Incremental Development, Operations Time per Build; per Increment 1. Use NDISmall AccountingCompleteAcquire NDIUse NDI 2. AgileE-servicesLow1 – 30Low-MedGood; in place Agile-ready Med-high Skip Valuation, Architecting phasesScrum plus agile methods of choice<= 1 day; 2-6 weeks 3. Architected Agile Business data processing Med1 – 10Med-HighGood; most in place Agile-ready Med-high Combine Valuation, Architecting phases. Complete NDI preparation Architecture-based Scrum of Scrums2-4 weeks; 2-6 months 4. Formal Methods Security kernel; Safety-critical LSI chip Low0.3Extra HighNoneStrong formal methods experience Precise formal specificationFormally-based programming language; formal verification 1-5 days; 1-4 weeks 5. HW component with embedded SW Multi-sensor control device Low0.3 – 1Med-Very High Good; In place Experienced; med-high Concurrent HW/SW engineering. CDR- level ICM DCR IOC Development, LRIP, FRP. Concurrent Version N+1 engineering SW: 1-5 days; Market-driven 6. Indivisible IOCComplete vehicle platform Med – High0.3 – 1High-Very High Some in placeExperienced; med-high Determine minimum-IOC likely, conservative cost. Add deferrable SW features as risk reserve Drop deferrable features to meet conservative cost. Strong award fee for features not dropped SW: 2-6 weeks; Platform: 6-18 months 7. NDI- IntensiveSupply Chain Management Med – High0.3 – 3Med- Very High NDI-driven architecture NDI-experienced; Med-high Thorough NDI-suite life cycle cost-benefit analysis, selection, concurrent requirements/ architecture definition Pro-active NDI evolution influencing, NDI upgrade synchronization SW: 1-4 weeks; System: 6-18 months 8. Hybrid agile / plan-driven system C4ISRMed – Very High Mixed parts: 1 – 10 Mixed parts; Med-Very High Mixed parts Full ICM; encapsulated agile in high change, low-medium criticality parts (Often HMI, external interfaces) Full ICM,three-team incremental development, concurrent V&V, next- increment rebaselining 1-2 months; 9-18 months 9. Multi-owner system of systems Net-centric military operations; Global Supply Chains Very HighMixed parts: 1 – 10 Very HighMany NDIs; some in place Related experience, med- high Full ICM; extensive multi-owner team building, negotiation Full ICM; large ongoing system/software engineering effort 2-4 months; 18- 24 months 10. Family of systems Medical Device Product Line Med – Very High 1 – 3Med – Very High Some in placeRelated experience, med – high Full ICM; Full stakeholder participation in product line scoping. Strong business case Full ICM. Extra resources for first system, version control, multi-stakeholder support 1-2 months; 9-18 months C4ISR: Command, Control, Computing, Communications, Intelligence, Surveillance, Reconnaissance. CDR: Critical Design Review. DCR: Development Commitment Review. FRP: Full-Rate Production. HMI: Human-Machine Interface. HW: Hard ware. IOC: Initial Operational Capability. LRIP: Low-Rate Initial Production. NDI: Non-Development Item. SW: Software

12. Lane: SoSE and Process Synchronization © USC CSSE 200812 Case 9: Multi-Owner SoS Biggest risks: all those of Case 8 plus –Large scale, high complexity, rapid change, mixed high/low criticality, partial NDI support, mixed personnel capability (same as Case 8-Hybrid Agile/Plan-Driven) –Need to synchronize/integrate separately-managed, independently-evolving systems –Extremely large-scale; deep supplier hierarchies –Rapid adaptation to change extremely difficult Examples: Net-centric military operations and global supply chains Size/complexity: Very high Anticipated change rate (% per month): Mixed parts; 1-10% Criticality: Very high NDI support: Many NDIs; some in place Organization and personnel capability: Related experience, medium to high Key Stage I activities: Full ICM; extensive multi-owner teambuilding, negotiation Key Stage II activities: Full ICM; large ongoing system/software engineering effort Time/build: 2-4 months Time/increment:18-24 months

13. Lane: SoSE and Process Synchronization © USC CSSE 200813 SoSE Synchronization Points

14. Lane: SoSE and Process Synchronization © USC CSSE 200814 Conclusions SoSE teams are evolving traditional methods to support the development and on-going evolution of SoSs –Early feasibility assessments and tradeoff analyses –Knowing when to engineer and when not to engineer In general, leave the constituent systems engineering to the constituent system engineers Constituent system monitoring to ensure that constituent system changes are not adversely impacting the SoS –Combining agile with traditional approaches Increases concurrency Reduces risk Compresses schedules The ICM special case for SoSs can provide both the rigor and the flexibility needed to achieve SoS goals A key to success is the ability to maintain an SoS integration lab to –Support modeling and simulation activities –Provide for SoS incremental integrations and test –Synchronize the roll-out of SoS capabilities

15. Lane: SoSE and Process Synchronization © USC CSSE 200815 Workshop Issues, Goals, and Approach ICM provides a tailorable framework for SoSE, but there are many devils in the details Key SoSE core elements are identified in the OUSD AT&L SoS SE Guidebook [OUSD AT&L, 2008] –Summarized on next charts Proposed workshop goals and approach –Discuss SoSE core elements in context of chart #13 –Identify, prioritize key SoSE issues –Discuss solution approaches for top-priority issues –Evaluate degree of payoff, difficulty of solution approaches on 0-10 scale –Prepare summary briefing

16. Lane: SoSE and Process Synchronization © USC CSSE 200816 SoSE Core Element Descriptions* Translating capability objectives –Developing a basic understanding of the expectations of the SoS and the core requirements for meeting these expectations, independent of the systems that comprise the SoS Understanding systems and relationships –In a SoS, the focus is on the systems which contribute to SoS SE capabilities and their interrelationships (as opposed to in a system, the focus is on boundaries and interfaces) Assessing actual performance to capability objectives –Establishing SoS metrics and methods for assessing performance and conducting evaluations of actual performance using metrics and methods Developing, evolving, and maintaining an SoS architecture/design –Establishing and maintaining a persistent framework for addressing the evolution of the SoS to meet user needs, including possible changes in systems functionality, performance or interfaces * [OUSD AT&L, 2008]

17. Lane: SoSE and Process Synchronization © USC CSSE 200817 SoSE Core Element Descriptions* (continued) Monitoring and assessing changes –Monitoring proposed or potential changes and assessing their impacts to: Identify opportunities for enhanced functionality & performance, and Preclude or mitigate problems for the SoS and constituent systems (this may include negotiating with the constituent system over how the change is made, in order to preclude SoS impacts) Addressing new requirements and options –Reviewing, prioritizing, and determining which SoS requirements to implement next Orchestrating upgrades to SoS –Planning, facilitating, integrating, testing changes in systems to meet SoS needs * [OUSD AT&L, 2008]

18. Lane: SoSE and Process Synchronization © USC CSSE 200818 Candidate Agile Change Processing and Rebaselining to Support Monitoring and Assessing Changes Assess Changes, Propose Handling Stabilized Increment-N Development Team Change Proposers Future Increment Managers Agile Future- Increment Rebaselining Team Negotiate change disposition Formulate, analyze options in context of other changes Handle Accepted Increment-N changes Discuss, resolve deferrals to future increments Propose Changes Discuss, revise, defer, or drop Rebaseline future-increment LCA packages Prepare for rebaselined future-increment development Defer some Increment-N capabilities Recommend handling in current increment Accept changes Handle in current rebaseline Proposed changes Recommend no action, provide rationale Recommend deferrals to future increments

19. Lane: SoSE and Process Synchronization © USC CSSE 200819 References Dahmann, J. (2007); “ Systems of Systems Challenges for Systems Engineering”, Systems and Software Technology Conference, June 2007. DiMario, Mike (2006); “System of Systems Characteristics and Interoperability in Joint Command Control”, Proceedings of the 2nd Annual System of Systems Engineering Conference Electronic Industries Alliance (1999); EIA Standard 632: Processes for Engineering a System Finley, James (2006); “Keynote Address”, Proceedings of the 2nd Annual System of Systems Engineering Conference Garber, Vitalij (2006); “Keynote Presentation”, Proceedings of the 2nd Annual System of Systems Engineering Conference INCOSE (2006); Systems Engineering Handbook, Version 3, INCOSE-TP-2003-002-03 Krygiel, A. (1999); Behind the Wizard’s Curtain; CCRP Publication Series, July, 1999, p. 33 Lane, J., Boehm, B., Modern Tools to Support DoD Software Intensive System of Systems Cost Estimation, Data and Analysis Center for Software, August 2007. Lane, J., Valerdi, R., “Synthesizing System-of-Systems Concepts for Use in Cost Modeling,” Systems Engineering, Vol. 10, No. 4, December 2007. Maier, M. (1998); “Architecting Principles for Systems-of-Systems”; Systems Engineering, Vol. 1, No. 4 (pp 267-284) Meilich, Abe (2006); “System of Systems Engineering (SoSE) and Architecture Challenges in a Net Centric Environment”, Proceedings of the 2nd Annual System of Systems Engineering Conference Office of the Under Secretary of Defense for Acquisition, Technology and Logistics (OUSD AT&L), Systems of Systems Systems Engineering Guide: Considerations for Systems Engineering in a System of Systems Environment, Washington, DC: Pentagon, 2008 (forthcoming). Pair, Major General Carlos (2006); “Keynote Presentation”, Proceedings of the 2nd Annual System of Systems Engineering Conference Proceedings of AFOSR SoSE Workshop, Sponsored by Purdue University, 17-18 May 2006 Proceedings of Society for Design and Process Science 9 th World Conference on Integrated Design and Process Technology, San Diego, CA, 25-30 June 2006 Siel, Carl (2006); “Keynote Presentation”, Proceedings of the 2nd Annual System of Systems Engineering Conference United States Air Force Scientific Advisory Board (2005); Report on System-of-Systems Engineering for Air Force Capability Development; Public Release SAB-TR-05-04