View Full Document


Unformatted text preview:

Factors Affecting Effort to Integrate and Test a System of Systems Richard D Stutzke Science Applications International Corp 6725 Odyssey Drive Huntsville AL 35806 3301 USA 256 971 6528 office 256 971 6678 facsimile 256 971 6562 asst Presented at the 20th International COCOMO and Software Cost Modeling Forum Los Angeles California 25 28 October 2005 Richard D Stutzke saic com 2005 by Richard D Stutzke SoS 1 Agenda Context Factors to Consider Modeling Approach Size Measures Single Build Multiple Builds Estimating Process 2005 by Richard D Stutzke SoS 2 Context 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 2005 by Richard D Stutzke SoS 3 Key Activities Requirement Analysis Ivy Hooks Architectural Design Dave Brown Build Integrate and Test Pieces COCOMO SEER SLIM Integrate the Component Systems Deploy Linear Model Operate and Maintain COTS Refresh Risk Management Edmund Conrow MBASE RUP 2005 by Richard D Stutzke SoS 4 Essential Complexity Factors The number of application domains 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 Maturity of business processes detail of description Compliance uniform use of the defined processes Speed of response ops tempo Dependability Safety Security etc Unprecedentedness in any of the above 2005 by Richard D Stutzke SoS 5 Man Made Complexity Factors Choice of solution technology Maturity of engineering Buyer Owner Operator User Developer Maintainer Regulator the Public the Media Personnel turnover for all types of stakeholders Inadequate funding Development Test Transition Maturity of management processes The number of stakeholder organizations involved Number of domains Technology maturity and readiness Technology refresh 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 2005 by Richard D Stutzke SoS 6 Modeling 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 2005 by Richard D Stutzke SoS 7 Activities 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 doable 2005 by Richard D Stutzke SoS 8 An N Squared Matrix TO A B C D E A FROM B C D E Notes 1 Assumes symmetry for each interface pair 2 Each cell may identify more than one interface 2005 by Richard D Stutzke SoS 9 Counting a Single Release A 1 B 2 2 C Symbols D Counts component system Systems 4 interface APIs 2 Links 3 glue code Glue modules 5 Note Glue modules 2 Links 2005 by Richard D Stutzke SoS 10 Estimating a Single Release Assume constant effort for a given activity EAPI Build and unit test common code EGLUE Build and unit test one glue module ELINK Effort to test one link Estimated Effort ETOTAL API EAPI Build API GLUE EGLUE Build Glue LINK ELINK Test Links 2005 by Richard D Stutzke SoS 11 Notation for Multiple Incremental Builds Object Develop Test Instance Total Component System c C API interface Glue module end a g A G New Link Modified Link Unmodified Link n m u N M U 2005 by Richard D Stutzke SoS Constant Effort per Instance EA EG EN EM EU 12 Effort for Build b Build and unit test items EffortBUT A b ENA New APIs added Glue modules added at each end APIs modified Glue modules modified G b ENG MA b EMA MG b EMG The above equation assumes that no links are deleted Integrate and test links EffortIAT LN b ENL Test new links Test modified APIs Test modified links Test unmodified links MA b E MA ML b EML U b EU 2005 by Richard D Stutzke SoS 13 Recursion Equations First build L 1 LN 1 M 1 0 U 1 0 Subsequent Builds L b L b 1 LN b U b L b 1 M b These equations assume that no links are ever deleted 2005 by Richard D Stutzke SoS 14 Steps of the Estimating Process 1 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 volatility 2005 by Richard D Stutzke SoS 15

Access the best Study Guides, Lecture Notes and Practice Exams

Loading Unlocking...

Join to view FactorsAffectingEffort and access 3M+ class-specific study document.

We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view FactorsAffectingEffort and access 3M+ class-specific study document.


By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?