Constructive System of Systems Integration Cost Model (COSOSIMO) ****************** Tutorial Jo Ann Lane, USC Center for Systems & Software.

Slides:



Advertisements
Similar presentations
© 2009 The MITRE Corporation. All rights Reserved. Evolutionary Strategies for the Development of a SOA-Enabled USMC Enterprise Mohamed Hussein, Ph.D.
Advertisements

Ninth Lecture Hour 8:30 – 9:20 pm, Thursday, September 13
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Sponsored by the U.S. Department of Defense © 2005 by Carnegie Mellon University 1 Pittsburgh, PA Dennis Smith, David Carney and Ed Morris DEAS.
Systems Engineering in a System of Systems Context
COCOMO Suite Model Unification Tool Ray Madachy 23rd International Forum on COCOMO and Systems/Software Cost Modeling October 27, 2008.
1 Jo Ann Lane University of Southern California Center for Systems and Software Engineering Dr. Paul Carlock Northrop Grumman Corporation.
Software Engineering Techniques for the Development of System of Systems Seminar of “Component Base Software Engineering” course By : Marzieh Khalouzadeh.
Rational Unified Process
University of Southern California Center for Software Engineering CSE USC System Dynamics Modeling of a Spiral Hybrid Process Ray Madachy, Barry Boehm,
March 2002 COSYSMO: COnstructive SYStems Engineering Cost MOdel Ricardo Valerdi USC Annual Research Review March 11, 2002.
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
University of Southern California Center for Systems and Software Engineering USC CSSE Research Overview Barry Boehm Sue Koolmanojwong Jo Ann Lane Nupul.
University of Southern California Center for Software Engineering CSE USC COSYSMO: Constructive Systems Engineering Cost Model Barry Boehm, USC CSE Annual.
Cost and Management Challenges of Systems of Systems True Program Success TM Cost and Management Challenges of System of Systems Arlene Minkiewicz, Chief.
Introduction and Overview “the grid” – a proposed distributed computing infrastructure for advanced science and engineering. Purpose: grid concept is motivated.
COSYSMO: Constructive Systems Engineering Cost Model Ricardo Valerdi USC CSE Workshop October 25, 2001.
COSOSIMO October 2005 Workshop Jo Ann Lane University of Southern California Center for Software Engineering COCOMO Forum – October 2005.
COSOSIMO* Workshop 13 March 2006 Jo Ann Lane University of Southern California Center for Software Engineering CSE Annual.
University of Southern California Center for Systems and Software Engineering Massachusetts Institute of Technology System of Systems Engineering Cost.
University of Southern California Center for Systems and Software Engineering System of Systems Engineering Cost Modeling: Strategies for Different Types.
Process Synchronization Workshop Summary Report Jo Ann Lane University of Southern California Center for Software Engineering.
Valuing System Flexibility via Total Ownership Cost Analysis Barry Boehm, JoAnn Lane, USC Ray Madachy, NPS NDIA Systems Engineering Conference October.
System-of-Systems Cost Modeling: COSOSIMO July 2005 Workshop Results Jo Ann Lane University of Southern California Center for Software Engineering.
Estimating System of Systems Engineering (SoSE) Effort Jo Ann Lane, USC Symposium on Complex Systems Engineering January 11-12, 2007.
Iterative development and The Unified process
COSOSIMO* Workshop Outbrief 14 March 2006 Jo Ann Lane University of Southern California Center for Software Engineering CSE.
DITSCAP Phase 2 - Verification Pramod Jampala Christopher Swenson.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Enterprise Architecture
What is Business Analysis Planning & Monitoring?
Process: A Generic View
Using SysML to Estimate SoS Engineering and Development Effort Jo Ann Lane Tim Bohn COCOMO.
CMMI Course Summary CMMI course Module 9..
UML - Development Process 1 Software Development Process Using UML (2)
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
Requirements Management for Net-Centric Enterprises: An Overview Doug Bodner*, Nenad Medvidovic+, Barry Boehm+, Jo Ann Lane+, Bill Rouse*, George Edwards+,
T. Dawson, TASC 9/11/13 Use of a Technical Reference in NASA IV&V.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Role-Based Guide to the RUP Architect. 2 Mission of an Architect A software architect leads and coordinates technical activities and artifacts throughout.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
OOI CI LCA REVIEW August 2010 Ocean Observatories Initiative OOI Cyberinfrastructure Architecture Overview Michael Meisinger Life Cycle Architecture Review.
Software Engineering Principles Principles form the basis of methods, techniques, methodologies and tools Principles form the basis of methods, techniques,
Object-oriented Analysis and Design Stages in a Software Project Requirements Writing Analysis Design Implementation System Integration and Testing Maintenance.
CHECKPOINTS OF THE PROCESS Three sequences of project checkpoints are used to synchronize stakeholder expectations throughout the lifecycle: 1)Major milestones,
© 2012 xtUML.org Bill Chown – Mentor Graphics Model Driven Engineering.
Software Engineering - I
Fifth Lecture Hour 9:30 – 10:20 am, September 9, 2001 Framework for a Software Management Process – Life Cycle Phases (Part II, Chapter 5 of Royce’ book)
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
March Jo Ann Lane University of Southern California Center for Software Engineering CONSTRUCTIVE SYSTEM OF SYSTEMS INTEGRATION COST MODEL COSOSIMO.
University of Southern California Center for Systems and Software Engineering COCOMO Suite Toolset Ray Madachy, NPS Winsor Brown, USC.
Software Architecture Evaluation Methodologies Presented By: Anthony Register.
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Software Project Management (SEWPZG622) BITS-WIPRO Collaborative Programme: MS in Software Engineering SECOND SEMESTER /1/ "The content of this.
INCOSE Systems of Systems Working Group Alan Harding BAE Systems Dr. Judith Dahmann MITRE Corporation SoS Working Group Co-chairs.
Overview of RUP Lunch and Learn. Overview of RUP © 2008 Cardinal Solutions Group 2 Welcome  Introductions  What is your experience with RUP  What is.
Unit – I Presentation. Unit – 1 (Introduction to Software Project management) Definition:-  Software project management is the art and science of planning.
Iterative development and The Unified process
Process 4 Hours.
Software Engineering: A Practitioner’s Approach, 6/e Chapter 23 Estimation for Software Projects copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
Systems of Systems Challenges and Strategies
COSYSMO: Constructive Systems Engineering Cost Model
Software engineering -1
Constructive System of Systems Integration Cost Model (COSOSIMO)
Software Engineering: A Practitioner’s Approach, 6/e Chapter 23 Estimation for Software Projects copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
Ramin Moazeni Winsor Brown Barry Boehm
Chapter 26 Estimation for Software Projects.
Presentation transcript:

Constructive System of Systems Integration Cost Model (COSOSIMO) ****************** Tutorial Jo Ann Lane, USC Center for Systems & Software Engineering October 2006

2 Overview  COSOSIMO Background  System of Systems (SoS) and SoS Engineering (SoSE) Environment  Current COSOSIMO Cost Estimation Approach  Conclusions  References

3 COCOMO Cost Model Suite Overview* * Barry Boehm, Ricardo Valerdi, Jo Ann Lane, and Winsor Brown, “COCOMO Suite Methodology and Evolution”, CrossTalk, April 2005.

4 Analyze existing literature Step 1 Perform Behavioral analyses Step 2 Identify relative significance Step 3 Perform expert-judgment Delphi assessment, formulate a-priori model Step 4 Gather project data Step 5 Determine Bayesian A-Posteriori model Step 6 Gather more data; refine model Step 7 Concurrency and feedback implied… USC-CSE Modeling Methodology* * Boehm, et. al., Software Cost Estimation with COCOMOII, 2000.

5 Goal of Research  Develop a cost model (COSOSIMO) to –Support the estimation of effort associated with System-of-System Engineering (SoSE)  May be performed by one or more Lead System Integrator (LSI) organizations –Complement the other USC CSE cost models for software development, system engineering (SE), and Commercial-Off-the-Shelf (COTS) integration, leading toward a more comprehensive and unified cost model to support the much broader system of interest life cycle COSOSIMO will not estimate the total SoS development costs, but rather just the SoSE costs at the SoS level…

6 History of COSOSIMO Model Early 2003Potential need for SoSE cost model identified Fall/Winter 2003Initial model developed based on software size Fall 2004Early design model based of SoS architecture characteristics (not software size) Spring/Summer 2005 EIA 632-based survey conducted to determine SoSE differences from traditional systems engineering Fall 2005SoSE WBS analysis Fall/Winter submodel version of COSOSIMO investigated Spring/Summer 2006 SoSE-specific characteristics captured from SoSE conferences/workshops Spring submodel version of COSOSIMO proposed

7 What is a “System-of-Systems”?  Very large systems developed by creating a framework or architecture to integrate component systems  SoS component systems independently developed and managed –New or existing systems –Have their own purpose –Can dynamically come and go from SoS  SoS exhibits emergent behavior not otherwise achievable by component systems  SoS activities often planned and coordinated by a Lead System Integrator (LSI)  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  INCOSE Handbook Definition: “Systems of Systems” are defined as an interoperating collection of component systems that produce results unachievable by the individual systems alone. (Krygiel 1999)

8 What is a “Lead System Integrator”?  Organization (or set of organizations) selected to accomplish the definition and acquisition of SoS components, and the continuing integration, test, and evolution of the components and SoS  Typical activities –Lead concurrent engineering of requirements, architecture, and plans –Identify and evaluate technologies to be integrated –Conduct source selection –Coordinate supplier activities and validate SoS architecture feasibility –Integrate and test SoS-level capabilities –Manage changes at the SoS level and across the SoS-related IPTs –Manage evolving interfaces to external systems  Typically do not develop system components to be integrated (possible exception: SoS infrastructure)

9 What is SoSE  USAF SAB Report on SoSE for Air Force Capability (USAF 2005): 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.  National Centers for Systems of Systems Engineering (NCOSOSE): The design, deployment, operation, and transformation of metasystems that must function as an integrated complex system to produce desirable results. These metasystems are themselves comprised of multiple autonomous embedded complex systems that can be diverse in technology, context, operation, geography, and conceptual frame. (

10 What is SoSE (continued)  Wikipedia ( SoSE is a set of developing processes and methods for designing and implementing solutions to System-of-Systems problems. SoSE is relatively new term being used in Department of Defense applications, but is increasingly being applied to non-military/security related problems (e.g. transportation, healthcare, internet, search and rescue, space exploration). SoSE is more than systems engineering of complex systems because design for System-of-Systems problems is performed under some level of uncertainty in the requirements and the constituent systems, and it involves considerations in multiple levels and domains. SoSE and Systems Engineering are related but different fields of study. Where as systems engineering addresses the development and operations of products, SoSE addresses the development and operations of programs. In other words, traditional systems engineering seeks to optimize an individual system (i.e., the product), while SoSE seeks to optimize network of various systems brought together to meet specific program's (i.e., the SoS problem's) objectives. SoSE enables decision-makers to understand the implications of various choices; thus, SoSE methodology seeks to prepare the decision-makers for effective architecting of System-of-Systems problems. Due to varied methodology and areas of applications in existing literature, there is no unified consensus for processes involved in System-of-Systems Engineering. One of the proposed SoSE frameworks, by Dr. Daniel A. DeLaurentis, recommends a three-phase method where a SoS problem is defined (understood), abstracted, modeled and analyzed for behavioral patterns.

11 SoSE Compared to Traditional SE Activities  Traditional SE Activities (EIA/ANSI 632) –Acquisition and supply  Product Supply  Product Acquisition  Supplier Performance –Technical management  Process Implementation Strategy  Technical Effort Definition  Schedule and Organization  Technical Plans  Work Directives  Progress Against Plans and Schedules  Progress Against Requirements  Technical Reviews  Outcomes Management  Information Dissemination –System design  Acquirer Requirements  Other Stakeholder Requirements  System Technical Requirements  Logical Solution Representations  Physical Solution Representations  Specified Requirements  Traditional SE Activities (continued) –Product realization  Implementation  Transition to Use –Technical evaluation  Effectiveness Analysis  Tradeoff Analysis  Risk Analysis  Requirements Statements Validation  Acquirer Requirements Validation  Other Stakeholder Requirements Validation  System Technical Requirements Validation  Logical Solution Representations Validation  Design Solution Verification  End Product Verification  Enabling Product Readiness  End Products Validation

12 SoSE Compared to Traditional SE Activities (continued)  Key Areas Where SoSE Activities Differ From Traditional Systems Engineering –Architecting composability vs. decomposition (Meilich 2006) –Added “ilities” such as flexibility, adaptability, composability (USAF 2005) –Net-friendly vs. hierarchical (Meilich 2006) –First order tradeoffs above the component systems level (e.g., optimization at the SoS level, instead of at the component system level) (Garber 2006) –Early tradeoffs/evaluations of alternatives (Finley 2006) –Human as part of the SoS (Siel 2006, Meilich 2006, USAF 2005) –Discovery and application of convergence protocols (USAF 2005)

13 SoSE Compared to Traditional SE Activities (continued)  Key Areas Where SoSE Activities Differ From Traditional Systems Engineering (continued) –Organizational scope defined at runtime instead of at system development time (Meilich 2006) –Dynamic reconfiguration of architecture as needs change (USAF 2005) –Modeling and simulation, in particular to better understand “emergent behaviors” (Finley 2006) –Component systems separately acquired and continue to be managed as independent systems (USAF 2005) –Intense concept phase analysis followed by continuous anticipation; aided by ongoing experimentation (USAF 2005)

14 SoSE Compared to Traditional SE Activities (continued)  Key Challenges for 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+

15 Sample Dynamic SoS: Metropolitan Area Crisis Management System Net-Centric SoS Net-Centric Connectivity

16 Sample “Steady-State” SoS: Enterprise Wide Integration of Core Business Applications Supplier 1Supplier n Net-Centric Connectivity Net-Centric Connectivity Net-Centric Connectivity

17 System of Systems Cost Estimation SOS SmSm S 2 (SoS)S1S1 S 11 S 12 S 1n S 21 S 22 S 2n S m1 S m2 S mn …… Level 0 Level 1 Level 2 ActivityLevelsCost Model SoS Lead System Integrator Effort (SoS scoping, planning, requirements, architecting; source selection; teambuilding, re-architecting, feasibility assurance with selected suppliers; incremental acquisition management; SoS integration and test; transition planning, preparation, and execution; and continuous change, risk, and opportunity management) Level 0, and other levels if lower level systems components are also SoSs (e.g., S 2 ) COSOSIMO Development of SoS Software-Intensive Infrastructure and Integration ToolsLevel 0COCOMO II System Engineering for SoS ComponentsLevels 1-nCOSYSMO Software Development for Software-Intensive ComponentsLevels 1-nCOCOMO II COTS Assessment and Integration for COTS-based ComponentsLevels 1-nCOCOTS

18 System of Systems Cost Model Size Drivers Cost Drivers SoS Definition and Integration Effort Calibration COSOSIMO  Characteristics of SoSs supported by cost model –Strategically-oriented stakeholders interested in tradeoffs and costs –Long-range architectural vision for SoS –Developed and integrated by an LSI –System component independence  Size drivers and cost drivers –Based on product characteristics, processes that impact LSI effort, and LSI personnel experience and capabilities

19 Proposed Size Drivers  Number of SoS-related requirements  Number of of distinct interface protocols to be provided by the SoS framework  Number of independent system component organizations that are providing system components that will operate within the SoS framework  Number of SoS user scenarios  Number of unique component systems S1 S2 S3 S4 Each weighted by complexity…

20 Conceptual LSI Effort Profile LSI activities focus on three somewhat independent activities, performed by relatively independent teams A given LSI may be responsible for one, two, or all activity areas Some SoS programs may have more than one organization performing LSI activities

21 Planning, Requirements Management, and Architecting (PRA) Source Selection and Supplier Oversight (SO) SoS Integration and Testing (I&T) Size Drivers Cost Drivers SoS Definition and Integration Effort COSOSIMO Reduced Parameter Sub-Model Overview

22 Planning, Requirements Management, and Architecting Size Drivers # SoS-related requirements # SoS interface protocols Cost Drivers Requirements understanding Level of service requirements Stakeholder team cohesion SoS team capability Maturity of LSI processes Tool support Cost/schedule compatibility SoS risk resolution COSOSIMO: PRA Sub-Model LSI PRA Effort

23 COSOSIMO PRA Effort Estimation m n SoS PRA PM = A PRA [  C REQi +  C IPj ] B PRA i=1 j=1 Where: PRA PM LSI Planning, Requirements Management, and Analysis effort in person- months A PRA Constant derived from PRA historical data C REQi Complexity factor associated with the i th SoS requirement C IPj Complexity factor associated with the j th SoS interface protocol m Number of SoS-related “sea-level” requirements n Number of interface protocols supported by the SoS architecture B PRA Effort exponent based on the PRA exponential scale factors. The geometric product of the scale factors results in an overall exponential effort adjustment factor to the nominal PRA effort

24 Source Selection and Supplier Oversight Size Drivers # independent component system organizations Cost Drivers Requirements understanding Architecture maturity Level of service requirements SoS team capability Maturity of LSI processes Tool support Cost/schedule compatibility SoS risk resolution COSOSIMO: SO Sub-Model LSI SO Effort

25 COSOSIMO SO Effort Estimation n SoS SO PM = A SO [  C SCOj ] B SO j=1 Where: SO PM LSI Source Selection and Supplier Oversight effort in person-months A SO Constant derived from SO historical data C SCOj Complexity factor associated with the j th SoS component system organization n Number of organizations providing independently developed and maintained system components for the SoS B SO Effort exponent based on the SoS SO exponential scale factors. The geometric product of the scale factors results in an overall exponential effort adjustment factor to the nominal SO effort

26 SoS Integration and Testing Size Drivers # SoS interface protocols # SoS scenarios # unique component systems Cost Drivers Requirements understanding Architecture maturity Level of service requirements SoS team capability Maturity of LSI processes Tool support Cost/schedule compatibility SoS risk resolution Component system maturity and stability Component system readiness COSOSIMO: I&T Sub-Model LSI I&T Effort

27 COSOSIMO I&T Effort Estimation q r s SoS I&T PM = A I&T [  C IP i +  C SCEN j +  C SCO k ] B I&T i=1 j=1 k=1 Where: I&T PM LSI Integration and Test effort in person-months A I&T Constant derived from I&T historical data C IPi Complexity factor associated with the i th SoS interface protocol C SCENj Complexity factor associated with the jth SoS interface protocol C SCOk Complexity factor associated with the k th SoS component system organization q Number of interface protocols supported by the SoS architecture rNumber of SoS scenarios s Number of organizations providing independently developed and maintained system components for the SoS B I&T Effort exponent based on the I&T exponential scale factors. The geometric product of the scale factors results in an overall exponential effort adjustment factor to the nominal I&T effort

28 COSOSIMO Total SoSE Effort Estimation SoSE PM = PRA PM + SO PM + I&T PM Where: PRA PM LSI Planning, Requirements Management, and Analysis effort in person- months SO PM LSI Source Selection and Supplier Oversight effort in person-months I&T PM LSI Integration and Test effort in person-months

29 SoS Schedule Estimation Customer, Users LSI – Agile LSI IPTs – Agile Suppliers – Agile Suppliers – PD – V&V LSI – Integrators RFP, SOW, Evaluations, Contracting Effort/Staff Proposals Similar, with added change traffic from users… Assess compatibility, short- falls Rework LCO  LCA Packages at all levels COSOSIMO -like Assess sources of change; Negotiate rebaselined LCA 2 package at all levels COSOSIMO -like Similar, with added re- baselineing risks and rework… Inception Elaboration Source SoS Selection Architecting Increment 1 Increments 2,… n Develop to spec, V&V CORADMO -like Degree of Completeness risks, rework Proposal Feasibility LCOLCA LCA 1 IOC 1 Effort/staff at all levels risks, rework Risk-manage slow- performer, completeness risks, rework Integrate COSOSIMO -like LCA 2 shortfalls risks, rework Effort COSYSMO-like. Schedule = Effort/Staff Try to model ideal staff size LCA 2

30 Conclusions  Traditional systems engineering takes too long and too much effort  LSIs are finding better ways to engineering SoSs (SoSE)  Many combine agile with traditional approaches –Increases concurrency –Reduces risk –Compresses schedules  Reduced-parameter set COSOSIMO captures effects of new processes in three key areas –Planning, requirements management, and architecting –Source selection and supplier oversight –SoS integration and testing  Sub-models have fewer parameters that are more tailored to associated SoSE activities  Allows LSIs to estimate areas of interest and conduct “what ifs” comparisons of different development strategies

31 Conclusions (continued)  With the addition of a new COSOSIMO cost model to existing cost model tools, it will be possible to get more complete estimates of the SoS development effort  Key to this process is –Having an SoS architecture sufficiently defined so that component system modifications to support operation in the SoS environment can be made with few dependencies on other SoS development efforts –Structuring the WBS so that  SoS and component system tasks can be decomposed into parts that can be estimated using the existing cost model tools  Parts not covered by cost models can be clearly identified and estimated using non-parametric methods  Expected COSOSIMO availability: Fall 2007 “All models are wrong, but some of them are useful” (W. E. Deming)

32 What is Needed to Support Fall 2007 Availability  Participation in current SoSE surveys  Data from both SoS and SE programs –Process descriptions to help understand the differences between SoSE and SE –Effort data to calibrate COSOSIMO (either standalone model or special calibration of COSYSMO) For those organizations that provide SoSE effort from at least 3 SoS projects, a local calibration will be provided…

33 COSOSIMO-Related References Boehm, B., et al. (2000); Software Cost Estimation with COCOMO II; Prentice Hall Boehm,B., Valerdi, R., Lane, J., and Brown, W. (2005); COCOMO Suite Methodology and Evolution; CrossTalk, Vol. 18, No. 5 (pp ) Boehm, B., and J. Lane (2006); “21st Century Processes for Acquiring 21st Century Systems of Systems; CrossTalk Vol. 19, No. 5 (pp. 4-9) Lane, J. (2005); System of Systems Lead System Integrators: Where do They Spend Their Time and What Makes them More/Less Efficient; USC-CSE-TR Lane, J. (2005); Factors Influencing System-of-Systems Architecting and Integration Costs; Conference on Systems Engineering Research Lane, J (2006); COSOSIMO Parameter Definitions, USC-CSE-TR Lane, J and Boehm, B. (2006); Synthesis of Existing Cost Models to Meet System of Systems Needs; Conference on Systems Engineering Research Lane, J and Boehm, B. (2006); System-of-Systems Cost Estimation: Analysis of Lead System Integrator Engineering Activities; InterSymposium Symposium on Information Systems Research and Systems Approach Lane, J and Valerdi, R (2005); Synthesizing SoS Concepts for Use in Cost Estimation; IEEE Systems, Man, and Cybernetics

34 SoSE-Related References Carlock, P.G., and R.E. Fenton, "System of Systems (SoS) Enterprise Systems for Information- Intensive Organizations," Systems Engineering, Vol. 4, No. 4, pp , 2001 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 Krygiel, A. (1999); Behind the Wizard’s Curtain; CCRP Publication Series, July, 1999, p. 33 Maier, M. (1998); “Architecting Principles for Systems-of-Systems”; Systems Engineering, Vol. 1, No. 4 (pp ) 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 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, May 2006 Proceedings of Society for Design and Process Science 9 th World Conference on Integrated Design and Process Technology, San Diego, CA, 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