1. University of Southern California Center for Systems and Software Engineering SoS Engineering and the ICM Workshop Overview Jo Ann Lane USC CSSE jolane@usc.edu Gary Hafen Lockheed Martin gary.hafen@lmco.com Judith Dahmann Mitre jdahmann@mitre.org

2. University of Southern California Center for Systems and Software Engineering July 2008©USC-CSSE2 Participants John Clark (Northrop Grumman) Judith Dahmann (MITRE) Rusty Graves (ARMY PEO Aviation) Gary Hafen (Lockheed Martin) Jo Ann Lane (USC CSSE) Jeff Loren (SAF/AQR) Ann Reid-Shaw (OSD SSA)

3. University of Southern California Center for Systems and Software Engineering July 2008©USC-CSSE3 3 ICM and SoS Working Group Objectives Identify, discuss, prioritize issues –Some candidates provided below Develop candidate approaches to issues Evaluate SoS issues with respect to ICM –What is value of ICM for SoS issue? –How should ICM be interpreted for SoS issue? Develop, present outbrief –Context and assumptions –Prioritized issues; discussion where appropriate –Candidate initiatives to address issues Rated high/medium/low on importance, difficulty –ICM improvement suggestions

4. University of Southern California Center for Systems and Software Engineering July 2008©USC-CSSE4 Top Priority Issues 4 votes –Capability decomposition/capability engineering 3 votes –Requirements –How to establish each type of management/technical structure 2 votes: –What to review at SoS anchor point milestone commitment reviews (and what are important artifacts/work products. Further discussion led to combining two other issues with this one: What should an SoS team pay attention to/not pay attention to Competitive prototyping

5. University of Southern California Center for Systems and Software Engineering July 2008©USC-CSSE5 Top Priority Issues (continued) One vote each: –SoSE team planning, organizing, staffing, controlling and directing –Network performance and scalability –How to mature network architectures –How to manage risks and opportunities –How to perform CM and DM –Analysis tools and resources –SoS software requirements stability management

6. University of Southern California Center for Systems and Software Engineering July 2008©USC-CSSE6 1. Capability Decomposition/Engineering Description of issue: –How are capability needs statements decomposed into SoS architecture and constituent system requirements –Guidance for various aspects of capability decomposition Management Negotiation Tracking Tradeoffs Etc.

7. University of Southern California Center for Systems and Software Engineering July 2008©USC-CSSE7 1. Capability Decomposition/Engineering (continued) Supporting discussion of aspects to consider in addressing issue –Increasing focus on capabilities (vs. requirements) –Often driven by priorities from operational users –Capability engineering vs. SoS engineering: what is appropriate point of view? –Gap analysis and criticality of identified gaps Are things “good enough” as is? –Solution approach: composition vs. decomposition –Need data from operational circumstances to support gap analysis –How is capability maintained as systems change Next steps: –Investigate value of ICM for SoS (ala Mark Maier discussion): is this an appropriate tool for decomposing/engineering capabilities –Develop case studies

8. University of Southern California Center for Systems and Software Engineering July 2008©USC-CSSE8 2. Requirements Issue covers many areas: –Wide/deep/long rapid requirements renegotiation –Interface management –Capability renegotiation –System level requirements vs. SoS level requirements –SoSs imply new requirements for systems –How to have systems be more responsive to SoS needs/changes Two key parts identified –Figuring out options for needed capability (requires funding at SoS level and support from constituent systems) Mini exploration, valuation, foundation types of activities –Once option(s) determined, how to implement via acquisition process Acquisition constraints can limit options

9. University of Southern California Center for Systems and Software Engineering July 2008©USC-CSSE9 2. Requirements (continued) Supporting discussion –How much of this is an acquisition issue? –SoS changes need to compete with system changes –Need to provide mechanism to allow SoS team to write/fund tasks (IDIQ contract?) –Trades include technical, schedule, system resource “bandwidth”, cost, number of systems impacted –Need to support long term vs short term trades –Need to provide more attention to quality attributes vs technical/performance –How could ICM help SoSE teams handle these related issues? Next steps –Identify specific acquisition issues –Identify candidate changes to acquisition process Need to be more agile –Define capability management process/issues at SoS level

10. University of Southern California Center for Systems and Software Engineering July 2008©USC-CSSE10 2. Requirements (continued) Acquisition issues affecting requirements management –Contracting inflexibility –Risk of opening up a contract for SoS capability –System development processes/upgrade cycles –Funding cycles POM process needed? Lag time for proposed changes to flow through program/contract channels –Role of JCIDS process in adding requirements to systems to support SoS needs Are SoS needs the same as requirements creep from the system perspective?

11. University of Southern California Center for Systems and Software Engineering July 2008©USC-CSSE11 3. Establishing SoSE Team Issue: How to establish each type of management/technical structure –When and how to move SoS from collaborative to acknowledged to directed –SoSs are currently trying to evolve on their own and need guidance Support discussion –Return on investment for options –How much authority is required to communicate and be heard by systems –Who has priority among the systems –What kind of arrangements are necessary between systems (MOAs? Contracts? Something else?)

12. University of Southern California Center for Systems and Software Engineering July 2008©USC-CSSE12 Next steps –Capture lessons learned from successful programs (SoS SE guidebook pilots?) Examples of useful lessons learned: Teambuilding guidance Contract guidance –What are typical issues that drive the type of structure of structure Checklist? Criteria? –What are the skill sets required for a successful SoSE team (by type of SoS structure) SEs and managers –Develop sample plans at SoS level (e.g. SEP) for different structures 3. Establishing SoSE Team (continued)

13. University of Southern California Center for Systems and Software Engineering July 2008©USC-CSSE13 4. SoS Anchor Point Commitment Reviews Issue: What to review at SoS anchor point milestone commitment reviews and what are important artifacts/work products –What should an SoS team pay attention to/not pay attention to –Competitive prototyping—what is the role of CP within SoSs and where/when should it be used Support discussion –Level of detail needed –How far down to drive management of the SoS

14. University of Southern California Center for Systems and Software Engineering July 2008©USC-CSSE14 4. SoS Anchor Point Commitment Reviews (continued) Next steps –Define what an anchor point milestone review is in the context of an SoS –Identify key artifacts and develop samples (e.g., SEP, risk management plan, SoS architecture, V&V plans, TEMP, etc.) –Identify key types of feasibility evidence that might apply to each anchor point milestone review –Depending on SoS structure, how to assign responsibility for defining and conducting anchor point milestone reviews and defining necessary artifacts for review –Analyzing ability of CP to support necessary SoSE decisions

15. University of Southern California Center for Systems and Software Engineering July 2008©USC-CSSE15 Core Elements of SoS SE New SoS SE role SoS upgrade process Persistent SoS overlay framework External influences Translating capability objectives Translating capability objectives Translating capability objectives Addressing new requirements & options Addressing new requirements & options Addressing 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 & evolving SoS architecture Assessing (actual) performance to capability objectives Assessing (actual) performance to capability objectives Assessing performance to capability objectives Orchestrating upgrades to SoS Orchestrating upgrades to SoS Orchestrating upgrades to SoS Monitoring & assessing changes Monitoring & assessing changes Monitoring & assessing changes

16. University of Southern California Center for Systems and Software Engineering July 2008©USC-CSSE16 03/19/2008 ©USC-CSSE The Incremental Commitment Life Cycle Process: Overview Stage I: DefinitionStage II: Development and Operations Developing & evolving SoS architecture Translating capability objectives Understanding systems & relationships Monitoring & assessing changes Addressing requirements & solution options Orchestrating upgrades to SoS Assessing performance to capability objectives

17. University of Southern California Center for Systems and Software Engineering July 2008©USC-CSSE17 Assessment of Next Steps IssueNext StepValueEase Capability Decomp Investigate value of ICM for SoS HighMedium to Hard Research and document case studies HighEasy to hard (start with easy) RequirementsIdentify specific acquisition issues (expand) High if issues can be addressed Easy Identify candidate changes to acquisition process (agility) High if issues can be addressed Hard Define capability management process/issues at SoS level (process building from the bottom up and top down) HighHard Develop process for understanding SoS objectives HighMedium

18. University of Southern California Center for Systems and Software Engineering July 2008©USC-CSSE18 Assessment of Next Steps (continued) IssueNext StepValueEase of Establishing the SoSE Team Capture lessons learned from successful programs (SoS SE guidebook pilots?) HighMedium What are typical issues that drive the type of structure (analyzing lessons learned) HighHard What are the skill sets required for a successful SoSE team (by type of SoS structure) HighMedium Develop sample plans at SoS level (e.g. SEP) for different structures Medium

19. University of Southern California Center for Systems and Software Engineering July 2008©USC-CSSE19 Assessment of Next Steps (continued) IssueNext StepPriorityEase SoS Anchor Point Reviews Define what an anchor point review is for an SoS—to include samples and example feasibility evidence HighHard How to assign responsibility for defining and conducting anchor point reviews and defining necessary artifacts for review HighMedium Analyzing ability of CP to support necessary SoSE decisions HighMedium (but...)

20. University of Southern California Center for Systems and Software Engineering July 2008©USC-CSSE20 General Thoughts on the ICM with Respect to SoSE Not clear that the current view of ICM is useful for SoSs –ICM needs further evaluation with respect to SoSs and maybe some different views When analyzing new capability requests, need to go through Exploration and Valuation phases, not just revisit Foundations and proceed into development –Need to define appropriate levels of rigor for Exploration and Valuation given that most of the SoS is comprised of legacy/existing systems Need to better clarify how ICM differs from current DoD processes

21. University of Southern California Center for Systems and Software Engineering July 2008©USC-CSSE21 Backup Charts

22. University of Southern California Center for Systems and Software Engineering July 2008©USC-CSSE22 Detailed List of SoS Issues (1) Quality factor tradeoffs –Quality of service evidence development across wide/deep/long combinations of component systems/subcontractor levels/increments Safety Security Information assurance Cost and risk –Wide/deep/long risk coordination, tracking SoS-specific cost estimation proxies for SoS critical path scheduling Requirements –Wide/deep/long rapid requirements renegotiation –Interfaces –Capability renegotiation Competitive prototyping –What is the role of CP in an SoS –When would you use it

23. University of Southern California Center for Systems and Software Engineering July 2008©USC-CSSE23 Detailed List of SoS Issues (2) Topic-specific –SoSE team planning, organizing, staffing, controlling, and directing –What and what not to delegate to systems developers –How to plan and execute a multi-owner SoS anchor point milestone review –Mapping the new SoSE Guidebook to the ICM Other –How to determine the right battle rhythm –What to review at SoS anchor point milestone commitment reviews –What are the important work products/artifacts at the SoS level Only those related to interoperability? SoS quality attributes? –What should an SoSE team pay attention to/not pay attention to Only those related to interoperability? SoS quality attributes?

24. University of Southern California Center for Systems and Software Engineering July 2008©USC-CSSE24 Detailed List of SoS Issues (3) Additional topics (added on 7/16/2008) –How to determine type of SoS management and technical structure (directed to collaborative) –How to establish each type of management / technical structure –How to manage risks and opportunities –How to manage software requirements stability –Analysis tools and resources—identification of necessary ones –Resources—what are needed –How to address network performance and scalability –Baseline coordination—how to synchronize –Capability decomposition into SoS architecture and constituent system elements— management, negotiation, tracking, tradeoffs, etc. –How to mature network architectures (for net-centric SoSs) –How to perform CM and DM? –What are the necessary SoSs/enabling systems in the acquisition domain (e.g., test ranges –Capability engineering vs. SoS engineering? What is appropriate point of view? –What is the relationship between SoSE and Enterprise Engineering?