Slide 1Slide 2ContextKey ActivitiesEssential Complexity FactorsMan-Made Complexity FactorsModeling AssumptionsActivities CoveredAn N-Squared MatrixCounting a Single ReleaseEstimating a Single ReleaseNotation for Multiple Incremental BuildsEffort for Build “b”Recursion Equations*Steps of the Estimating ProcessSoS 1 2005 by Richard D. StutzkeFactors Affecting Effort to Integrate and Test a System of Systems Richard D. Stutzke Science Applications International Corp.6725 Odyssey DriveHuntsville, AL 35806-3301USA(256) 971-6528 (office)(256) 971-6678 (facsimile)(256) 971-6562 (asst)Presented at the 20th International COCOMO and Software Cost Modeling ForumLos Angeles, California25-28 October 2005 [email protected] 2 2005 by Richard D. StutzkeAgenda•Context•Factors to Consider•Modeling Approach–Size Measures–Single Build–Multiple Builds•Estimating ProcessSoS 3 2005 by Richard D. StutzkeContext•Definition:–A System of Systems (SoS) connects multiple systems to solve a large scale problem.•Engineers have built systems of systems for a century or so: –Hardware-intensive (e.g., large ships)–Complex analog/mechanical systems (e.g., airplane)–Complex digital systems (servos, computers) (e.g., modern airplane)–Large integrated plants and information systems (oil refiners, airport)–Ultralarge netcentric systems (e.g., Future Combat System)•Example: the Future Combat System–Design and integrate 14 major weapons systems–Integrate and synchronize with ~157 complementary systems–Use ~53 “critical technologies”SoS 4 2005 by Richard D. StutzkeRequirement Analysis(Ivy Hooks)Architectural Design(Dave Brown)Build, Integrate, and Test Pieces(COCOMO, SEER, SLIM)Integrate the Component SystemsDeploy (Linear Model)Operate and Maintain(COTS Refresh)Risk Management (Edmund Conrow)“MBASE/RUP”Key ActivitiesSoS 5 2005 by Richard D. StutzkeEssential Complexity Factors•The number of application domains –Maturity of business processes (detail of description)–Compliance (uniform use of the defined processes)•The number of sites –Homogeneity of configurations (platforms, applications)–Geographic dispersion•The number of functional threads–Use cases–Must include exception handling (90/10 rule)•Degree of autonomy ( more functionality)•Required Performance–Speed of response (ops tempo)–Dependability, Safety, Security, etc.•Unprecedentedness in any of the aboveSoS 6 2005 by Richard D. StutzkeMan-Made Complexity Factors•Choice of solution technology –Number of domains–Technology maturity and readiness (-)–Technology refresh (+)•Maturity of engineering (-?)–Development–Test–Transition•Maturity of management processes (-)•The number of stakeholder organizations involved–Buyer, Owner, Operator, User–Developer, Maintainer–Regulator, “the Public”, “the Media” •Personnel turnover for all types of stakeholders (+)•Inadequate funding –Omitted activities (-)–Low estimates (assume “best case”, ignore risks) (+)–Incremental funding (+)•Unprecedentedness in any of the above (-)Note: Long project duration increases (+) or decreases (-) the adverse effects.SoS 7 2005 by Richard D. StutzkeModeling Assumptions•The original design identifies all of the necessary interfaces. -May overlook some interfaces-Misunderstood interfaces lead to volatility and rework.•Each interface for the SoS has two parts:-Common part : shared components that provide the interface functionality (“API”)-System-specific part : glue code for the component system.•Producing multiple builds incurs additional costs for:-Breakage-Maintenance and support-Note: These will affect the glue code and common API differently.SoS 8 2005 by Richard D. StutzkeActivities Covered•Build and unit test the interface code–API (common, shared code)–Glue code (component-specific)•Implement and test each link–Identify links using an N-squared matrix–Multiple builds are messy but doableSoS 9 2005 by Richard D. StutzkeAn N-Squared MatrixA B C D EABCDETOFROMNotes: 1 – Assumes “symmetry” for each interface pair 2 – Each cell may identify more than one interfaceSoS 10 2005 by Richard D. StutzkeCounting a Single ReleaseSymbols = component system = interface = glue codeCBAD12 2Note: # Glue modules ≠ 2 * (# Links)Counts# Systems = 4# APIs = 2#Links = 3# Glue modules = 5SoS 11 2005 by Richard D. StutzkeEstimating a Single Release•Assume “constant effort” for a given activity:EAPI = Build and unit test common codeEGLUE = Build and unit test one glue moduleELINK = Effort to test one link•Estimated EffortETOTAL = (# API) * EAPIBuild API + (# GLUE) * EGLUEBuild Glue + (# LINK) * ELINKTest LinksSoS 12 2005 by Richard D. StutzkeNotation for Multiple Incremental BuildsObject Instance Total (Constant) Effort per InstanceComponent System c CDevelop API (interface )Glue module (“end”)agAGEAEGTest New LinkModified LinkUnmodified LinknmuNMUENEMEUSoS 13 2005 by Richard D. StutzkeEffort for Build “b”•Build and unit test items EffortBUT = A(b) * ENA+ G(b) * ENG+ MA(b) * EMA+ MG(b) * EMGNew APIs addedGlue modules added (at each end)APIs modified Glue modules modified [The above equation assumes that no links are deleted.]•Integrate and test links EffortIAT = LN(b) * ENL+ MA(b) * E'MA+ ML(b) * EML+ U(b) * EUTest new linksTest modified APIsTest modified linksTest unmodified linksSoS 14 2005 by Richard D. StutzkeRecursion Equations*•First build:L(1) = LN(1)M(1) = 0U(1) = 0•Subsequent BuildsL(b) = L(b-1) + LN(b)U(b) = L(b-1) - M(b)*These equations assume that no links are ever deleted.SoS 15 2005 by Richard D. StutzkeSteps of the Estimating Process1. Identify the component systems (name, owner)2. Identify and categorize the interfaces (name, owner, API complexity and/or size*)3. Build the triangular N-squared matrix (from/to, glue code complexity and/or size*)4. Calculate the effort by build –Build and unit test APIs and glue modules–Integrate and test links (new, modified, and possibly deleted)5. Sum the values for all builds*If the interface will evolve, specify values by build and include breakage or