1. University of Southern California Center for Systems and Software Engineering System of Systems Engineering Cost Modeling: Strategies for Different Types of Systems of Systems Jo Ann Lane USC CSSE jolane@usc.edu COCOMO Forum October 2008

2. University of Southern California Center for Systems and Software Engineering October 2008©USC-CSSE2 Overview Key definitions Model implementation Results of research Conclusions and future work

3. University of Southern California Center for Systems and Software Engineering October 2008©USC-CSSE3 What is a “System of Systems”? Very large systems developed by creating a framework or architecture to integrate constituent systems SoS constituent systems independently developed and managed –New or existing systems in various stages of development/evolution –May include a significant number of COTS products –Have their own purpose –Can dynamically come and go from SoS SoS exhibits emergent behavior not otherwise achievable by component systems Typical domains –Business: Enterprise-wide and cross-enterprise integration to support core business enterprise operations across functional and geographical areas –Military: Dynamic communications infrastructure to support operations in a constantly changing, sometimes adversarial, environment Based on Mark Maier’s SoS definition [Maier, 1998]

4. University of Southern California Center for Systems and Software Engineering October 2008©USC-CSSE4 Related Engineering Disciplines SoSE –Term primarily used within DoD to describe engineering activities associated with the development and enhancement of SoS capabilities COTS integration –Special case of SoSE where constituent systems are primarily commercial products, often from different vendors Enterprise-wide systems engineering –Special case of SoSE where constituent systems primarily support business functions May include both COTS and legacy (custom) systems Typically “owned” by the enterprise May include manufacturing and supply chain operations IT Outsourcing –An approach to enterprise-wide engineering where the engineering activities are outsourced to another organization –Typically includes some combination of systems engineering, software development, system operation and administration, and business support

5. University of Southern California Center for Systems and Software Engineering October 2008©USC-CSSE5 Types of SoS Virtual [Maier, 1998] –Lacks a central management authority and a clear SoS purpose –Often ad hoc and may use a service-oriented architecture where the constituent systems are not necessarily known Collaborative [Maier, 1998] –Constituent system engineering teams work together more or less voluntarily to fulfill agreed upon central purposes –No SoSE team to guide or manage activities of constituent systems Acknowledged [Dahmann, 2008] –Have recognized objectives, a designated manager, and resources at the SoS level (SoSE team) –Constituent systems maintain their independent ownership, objectives, funding, and development approaches Directed [Maier, 2008] –SoS centrally managed by a government, corporate, or Lead System Integrator (LSI) and built to fulfill specific purposes –Constituent systems maintain ability to operate independently, but evolution subordinated to centrally managed purpose Research focusing on identifying the “home- ground” for these two types of SoSs...

6. University of Southern California Center for Systems and Software Engineering October 2008©USC-CSSE6 SoS System Interdependency Process Model Overview Purpose –Estimate and compare the effort required to implement an SoS capability using two different management approaches Collaborative (no SoSE team) Acknowledged (SoSE with limited authority/control) Assumptions and constraints –All constituent systems currently exist and have their own evolutionary paths based on system-level stakeholder needs/desires –Model assumes SoSE and traditional SE teams are using relatively mature processes –SoS capabilities are software-intensive –No SoS requirements volatility –No accommodation of schedule factors or the asynchronous nature of SoS constituent system upgrades –Management of SoS internal interfaces reduces complexity for systems –SE effort/information provided to SoSE team in support of SoSE must be added to SE effort for the part of the upgrade requirements that are at the SoS level

7. University of Southern California Center for Systems and Software Engineering October 2008©USC-CSSE7 Systems Engineering Requirements Categories Requirements related to SoS capabilities a)Acknowledged SoS: Initially engineered at SoS level by SoSE team with support from constituent system engineers for those systems impacted by the SoS capability, then allocated to constituent systems for further SE b)Collaborative SoS: Not engineered at the SoS level, but must be engineered fully at the constituent system level through collaborative efforts with other constituent system engineers Non-SoS requirements related to constituent system stakeholder needs –Must be monitored or “managed” by SoSE team to identify changes that might adversely impact SoS –Represents on-going volatility at the constituent system level that is occurring in parallel with SoS capability changes

8. University of Southern California Center for Systems and Software Engineering October 2008©USC-CSSE8 SoS System Interdependency Model Structure Focus is on software- intensive SoSs owned by the US DoD, the number and volatility of constituent systems within an SoS, and the complexity of typical capability enhancements to the SoS... Complexity Factors COSYSMO EMs

9. University of Southern California Center for Systems and Software Engineering October 2008©USC-CSSE9 Model Parameters Stocks –Inputs SoS Equivalent Requirements –Outputs (interim and final) SoSE Effort SoS Upgrade Effort with SoSE SoS Upgrade Effort without SoSE Flows –Capability Rate –SoSE Effort Rate –SE Effort Rate with SoSE –SE Effort Rate without SoSE Converter Parameters –COSYSMO effort multipliers (EMs) COSYSMO SoSE EM COSYSMS SoSE “Managed” EM COSYSMO SE EM with SoSE COSYSMO SE EM without SoSE COSYSMO SE EM –SoS complexity factors Number of systems in SoS Number of systems affected by capability Average system rate of change

10. University of Southern California Center for Systems and Software Engineering October 2008©USC-CSSE10 SoSE EM

11. University of Southern California Center for Systems and Software Engineering October 2008©USC-CSSE11 EM for SoSE “Managed” Requirements

12. University of Southern California Center for Systems and Software Engineering October 2008©USC-CSSE12 SE EM for SoS Requirements with SoSE Support

13. University of Southern California Center for Systems and Software Engineering October 2008©USC-CSSE13 SE EM SoS Requirements without SoSE Support

14. University of Southern California Center for Systems and Software Engineering October 2008©USC-CSSE14 SE EM for System-Specific (Non-SoS) Requirements

15. University of Southern California Center for Systems and Software Engineering October 2008©USC-CSSE15 Effort Calculations Based on COCOMO II approach for combining components with different EMs (SoS changes and Constituent System “managed” oversight)... SoSE Effort SoSE Effort = 38.55*[((SoSCR/SoSTreq)*(SoSTreq)1.06 *EMSoS-CR)+ ((SoSMR/SoSTreq)*(SoSTreq)1.06 * EMSoS-MR)/152] Where: Total SoSE requirements = SoS Capability Requirements + SoS “Managed” Requirements SoS “managed” reqs = [∑SE non-SoS requirements being addressed current upgrade cycles for all SoS constituent systems] * “managed reuse factor” “Managed reuse factor” = 15.4%

16. University of Southern California Center for Systems and Software Engineering October 2008©USC-CSSE16 Effort Calculations (continued) Single System Effort with Support from SoSE Team Total single system reqs w-SoSE = SoS requirements allocated to system + SE reqs in upgrade cycle Single system SE Effort with SoSE Team = 38.55*[1.15*( (SoS CSalloc / CS TreqSoSE )*( CS TreqSoSE )1.06* EM CS-CRwSOSE ) + (CS nonSoS / CS TreqSoSE )*( CS TreqSoSE) 1.06* EM CSnonSOS ] /152 Based on COCOMO II approach for combining components with different EMs plus including a 15% “tax” to support SoSE team in their engineering effort for the SoSE requirements. 15% represents half of the system design effort in the EIA 632 tasks.

17. University of Southern California Center for Systems and Software Engineering October 2008©USC-CSSE17 Effort Calculations (continued) Single System Effort with No SoSE Team Support Total single system reqs wo-SoSE = SoSE capability reqs + SE non-SoS requirements Single system SE Effort without SoSE Team = 38.55*[(( SoS CR / CS TreqwoSoSE )*( CS TreqwoSoSE )1.06* EM CS-CRnSOSE ) + ((CS nonSoS / CS TreqwoSoSE )*( CS TreqwoSoSE )1.06* EM CSnonSOS )] /152 Based on COCOMO II approach for combining components with different EMs (SoS changes and non-SoS changes)...

18. University of Southern California Center for Systems and Software Engineering October 2008©USC-CSSE18 Sample Results When the Number of Systems is over 12, Capability affects half of the systems, and the System and SoS number of requirements are both equal, SoSE begins to save effort... For any number of systems, when the Capability affects half of the systems, and the System requirements are considerably more that the SoS requirements, SoSE does not save effort... (However, there may be other reasons to employ an SoSE team – future research.)

19. University of Southern California Center for Systems and Software Engineering October 2008©USC-CSSE19 Conclusions SoSE team is cost effective when –SoS contains more than a “few” systems –SoS capability changes typically affect a “significant percentage” of constituent systems –SoS capability requirements are a “significant percentage” of the total requirements being addressed by constituent systems in an upgrade cycle –SoS oversight activities and the rate of capability modifications/changes being implemented are sufficient to keep an SoSE team engaged (i.e., little to no slack time)

20. University of Southern California Center for Systems and Software Engineering October 2008©USC-CSSE20 Future Work Expand System Interdependency SDM to –Include schedule factors to allow trade-offs between “faster” and “cheaper” –Include quality factors based on interdependencies and the resulting rework –Allow users to specify specific constituent system configurations to allow capability alternative trade-offs Investigate the factors in going from an Acknowledged SoS to a Directed SoS

21. University of Southern California Center for Systems and Software Engineering October 2008©USC-CSSE21 Questions

22. University of Southern California Center for Systems and Software Engineering October 2008©USC-CSSE22 References ANSI/EIA (1999). ANSI/EIA-632-1988 Processes for Engineering a System. Dahmann, J. and Baldwin. K. (2008); “Understanding the Current State of US Defense Systems of Systems and the Implications for Systems Engineering”, Montreal, Canada: IEEE Systems Conference, 7-10 April. Department of Defense (DoD) (2008); Systems Engineering Guide for System of Systems, draft version 1.0. Maier, M. (1998); “Architecting Principles for Systems-of-Systems”; Systems Engineering, Vol. 1, No. 4 (pp 267-284) Valerdi, R. (2005); Constructive Systems Engineering Cost Model. PhD. Dissertation, University of Southern California. Valerdi, R. and Wheaton, M. (2005); "ANSI/EIA 632 as a Standardized WBS for COSYSMO", AIAA-2005-7373, Proceedings of the AIAA 5th Aviation, Technology, Integration, and Operations Conference, Arlington, Virginia. Wang, G., Valerdi, R., Ankrum, A., Millar, C., and Roedler, G. (2008), "COSYSMO Reuse Extension", Proceedings of the 18th Annual International Symposium of INCOSE, The Netherlands.