CS-1 6/17/2015 1 6/17/2015 Towards a Work Breakdown Structure for Net Centric System of Systems Engineering and Management 20 th International Forum on.

Slides:



Advertisements
Similar presentations
Incremental Commitment Spiral Model, Expedited Engineering, and Kanban Jo Ann Lane and Alexey Tregubov USC CSSE Rich Turner Stevens University.
Advertisements

Course: e-Governance Project Lifecycle Day 1
© 2009 The MITRE Corporation. All rights Reserved. Evolutionary Strategies for the Development of a SOA-Enabled USMC Enterprise Mohamed Hussein, Ph.D.
Ninth Lecture Hour 8:30 – 9:20 pm, Thursday, September 13
Chapter 2 – Software Processes
Sixth Hour Lecture 10:30 – 11:20 am, September 9 Framework for a Software Management Process – Artifacts of the Process (Part II, Chapter 6 of Royce’ book)
Systems Engineering in a System of Systems Context
CS-1 6/1/ /1/2015 Towards a Work Breakdown Structure for Net Centric System of Systems Engineering and Management 20 th International Forum on COCOCMO.
University of Southern California Center for Software Engineering CSE USC System Dynamics Modeling of a Spiral Hybrid Process Ray Madachy, Barry Boehm,
Software and System Engineering Integration Sponsor Overview Kristen Baldwin Deputy Director, Software Engineering and System Assurance Office of the Under.
R R R CSE870: Advanced Software Engineering (Cheng): Intro to Software Engineering1 Advanced Software Engineering Dr. Cheng Overview of Software Engineering.
COSOSIMO* Workshop 13 March 2006 Jo Ann Lane University of Southern California Center for Software Engineering CSE Annual.
Chapter 5: Project Scope Management
System-of-Systems Cost Modeling: COSOSIMO July 2005 Workshop Results Jo Ann Lane University of Southern California Center for Software Engineering.
4. 2Object-Oriented Analysis and Design with the Unified Process Objectives  Explain the elements of project management and the responsibilities of a.
Chapter 3: The Project Management Process Groups
Chapter 5: Project Scope Management
Unit Slides by UK Versity.  Unit aims:  This unit aims to help the learner with an opportunity to develop their project management and research skills.
Project Management Methodology (PMM)
University of Southern California Center for Software Engineering C S E USC Agile and Plan-Driven Methods Barry Boehm, USC USC-CSE Affiliates’ Workshop.
COMP8130 and 4130Adrian Marshall 8130 and 4130 Test Management Adrian Marshall.
project management office(PMO)
Defining the Activities. Documents  Goal Statement defines why helps manage expectations  Statement of Work what gets delivered defines scope  Software.
Acquiring Information Systems and Applications
Effective Methods for Software and Systems Integration
A Security Training Program through Transformational Leadership and Practical Approaches Tanetta N. Isler Federal Information Systems Security Educators’
S/W Project Management Software Process Models. Objectives To understand  Software process and process models, including the main characteristics of.
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
Software Project Management Introduction to Project Management.
Engineering, Operations & Technology | Information TechnologyAPEX | 1 Copyright © 2009 Boeing. All rights reserved. Architecture Concept UG D- DOC UG D-
THE REGIONAL MUNICIPALITY OF YORK Information Technology Strategy & 5 Year Plan.
Business Systems Development SDLC and introduction to the Microsoft Solutions Framework Team and Process Models.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
The Challenge of IT-Business Alignment
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
Certification and Accreditation CS Phase-1: Definition Atif Sultanuddin Raja Chawat Raja Chawat.
 CS 5380 Software Engineering Chapter 2 – Software Processes Chapter 2 Software Processes1.
MD Digital Government Summit, June 26, Maryland Project Management Oversight & System Development Life Cycle (SDLC) Robert Krauss MD Digital Government.
ISM 5316 Week 3 Learning Objectives You should be able to: u Define and list issues and steps in Project Integration u List and describe the components.
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,
Assessing the influence on processes when evolving the software architecture By Larsson S, Wall A, Wallin P Parul Patel.
I n t e g r i t y - S e r v i c e - E x c e l l e n c e Business & Enterprise Systems The Integrated Master Plan (IMP) and the Integrated Master Schedule.
Microsoft Office Project 2003: Selling EPM in your Organization Matt Wilson Business Solutions Specialist LMR Solutions.
Review of Software Process Models Review Class 1 Software Process Models CEN 4021 Class 2 – 01/12.
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)
Chapter 3 Strategic Information Systems Planning.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
Project Initiation at The Regence Group 12/19/2015John Garrigues1.
The Goal: To Climb Above The Competition Copyright 2005: I Lead Projects, L.L.C. Course Description Project Process Workplates Project Process Workplates.
Software Project Management (SEWPZG622) BITS-WIPRO Collaborative Programme: MS in Software Engineering SECOND SEMESTER /1/ "The content of this.
Chapter 2 : The Project Management and Information Technology Context Information Technology Project Management, Fourth Edition.
Overview of RUP Lunch and Learn. Overview of RUP © 2008 Cardinal Solutions Group 2 Welcome  Introductions  What is your experience with RUP  What is.
Chapter 2 – Software Processes Lecture 1 1Chapter 2 Software Processes.
An organizational structure is a mostly hierarchical concept of subordination of entities that collaborate and contribute to serve one common aim... Organizational.
Modelling the Process and Life Cycle. The Meaning of Process A process: a series of steps involving activities, constrains, and resources that produce.
Unit – I Presentation. Unit – 1 (Introduction to Software Project management) Definition:-  Software project management is the art and science of planning.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
I n t e g r i t y - S e r v i c e - E x c e l l e n c e As of: 3/1/2016 Air Force Weather Agency CEISC Committee Focus Shift - Proposed Modification to.
1 Chapter 11 Planning. 2 Project Planning “establishing a predetermined course of action within a forecasted environment” “establishing a predetermined.
Info-Tech Research Group1 Info-Tech Research Group, Inc. Is a global leader in providing IT research and advice. Info-Tech’s products and services combine.
Advanced Software Engineering Dr. Cheng
CS 389 – Software Engineering
Identify the Risk of Not Doing BA
The Open Group Architecture Framework (TOGAF)
Systems of Systems Challenges and Strategies
Chapter 2 – Software Processes
Chapter 2 Modeling the Process and Life Cycle Shari L. Pfleeger Joanne M. Atlee 4th Edition.
By Jeff Burklo, Director
Presentation transcript:

CS-1 6/17/ /17/2015 Towards a Work Breakdown Structure for Net Centric System of Systems Engineering and Management 20 th International Forum on COCOCMO Workshop October 2005 Gan Wang Ricardo Valerdi Jo Ann Lane Barry Boehm

2 6/17/2015 Outline  Background, motivation, goals and scope −Relevant needs and trends in SoS system engineering and management −Development objectives  Basic foundations for the SoS WBS −Product-oriented structure −Scalable Spiral Model −Three-team construct  Net centric System of Systems (SoS) Program Work Breakdown Structure (WBS)  Implications and anticipated benefits  Conclusions

3 6/17/2015 Background  Systems engineering needs and trends −Increasing focus on capability-based acquisition −Increasing focus on user/value −Increasing complex systems of systems Disproportional increase in complexity and interdependency Disproportional increase in needs for interoperability −Increasing COTS, Open Source, reuse, and legacy integration  New challenges in systems engineering and program management −Evolutionary, rather than revolutionary −Capability, rather than functionality −Lifecycle perspective, rather than acquisition focused −Heterogeneous, rather than homogeneous −Negotiation, rather than mandate

4 6/17/2015 Motivation for Net Centric SoS WBS  A step into continuing understanding of net centric SoS systems engineering and management −What is common, what is different? −New scopes and emphases Beyond traditional systems engineering considerations Emerging behaviors and risk from evolutional process −What is/belongs, what is/does not? −What works, what does not?  Time to step back and rethink −Systematic −Holistic −Mission and capability focused New Perspective Required for Net Centric SoS/FoS

5 6/17/2015 Motivation (cont.)  No standard or commonly-accepted WBS above system level −Traditional program/project management focuses on system and performance Build-to-spec, requirement-driven, waterfall-ish −Existing WBS constructs are system development focused – difficult to scale upward Development/acquisition centric, little attention to O&M Interpretabilities and independencies disregarded Enterprise context absent  Tool needed for integrated systems engineering and program management in net centric SoS programs −Facilitates the unification of SoS SE and PM −Emerging systems engineering method: Capability Planning  Basis for cost estimating

6 6/17/2015 Net Centric SoS WBS Goals  Provide −Standardized, yet flexible, prototypical WBS for net centric SoS engineering and management programs – a standard template to develop program- specific WBS −Reference model for SoS program management, systems engineering and cost estimating −Full SoS life cycle “cradle-to-grave” perspective and support −Systematic and holistic approach −Basic analysis framework for decision making −Clear, consistent and commonly accepted terminology definition −Tailorable and adaptable model

7 6/17/2015 Goals (cont.)  Integrate community-accepted best practices −General systems engineering and program management lifecycle −System-level WBS −Program and practice examples −Existing international standards ISO/IEC 15288: Systems Engineering – System Life Cycle Processes DoD : Operation of the Defense Acquisition System ANSI/EIA 632 Processes for Engineering a System MIL-HDBK-881: Work Breakdown Structure  Leverage leading development in net centric SoS systems engineering and processes, e.g., −Spiral development model −Capability-based acquisition −Capability planning and investment analysis practices

8 6/17/2015 Net Centric SoS WBS Scope  Target SoS/FoS type programs −With the charter to evolve mission capabilities of a SoS/FoS −Prototypical program lifecycle perspective  Consider −Program management and the supporting enterprise functions −Systems engineering and integration products −Development and O&M environments −Governance model  Capture three basic components of the SoS engineering and management practices −Systems Components and relationships Infrastructure −Processes Program management Systems engineering & integration Technology development Operations and support −People Management and acquisition authorities Teams Stakeholder community

9 6/17/2015 Outline  Background, motivation, goals and scope −Relevant needs and trends in SoS system engineering and management −Development objectives  Basic foundations for the SoS WBS −Product-oriented structure −Scalable Spiral Model −Three-team construct  Net centric System of Systems (SoS) Program Work Breakdown Structure (WBS) – Top-level View  Anticipated benefits and conclusions

10 6/17/2015  Product-oriented Work Breakdown Structure −“Product”: physical entity, organization, function/service −Processes and activities associated with products  Scalable Spiral Process Model −Risk-driven OODA loops  Three-team execution model −Plan-driven team −IV&V team −Agile Rebaselining Team Basic Foundations of SoS WBS

11 6/17/2015 Emerging Scalable Spiral Process Decide on next-cycle capabilities, architecture upgrades, plans Stable specifications, COTS upgrades Development, integration, V&V, risk management plans Feasibility rationale Act on plans, specifications Keep development stabilized Change impact analysis, preparation for next cycle (mini- OODA loop) Orient with respect to stakeholders priorities, feasibility, risks Risk/Opportunity analysis Business case/mission analysis Prototypes, models, simulations Observe new/updated objectives, constraints, alternatives Usage monitoring Competition, technology, marketplace ISR Operate as current system Accept new system Source: USC-CSE Life Cycle Architecture Milestone for Cycle

12 6/17/2015 Spiral Bravo Three-Team Execution Model Plan-Driven TeamIV&V Team Environmen t Change Factors Internal Change Factors Agile Team Spiral Charlie Requirements KPPs Architecture Baseline Requirements KPPs Architecture Baseline Requirements KPPs Architecture Baseline 1.Plan-Driven Team 2.IV&V Team 3.Agile Rebaselining Team Emerging technologies New threats Operational environment changes … Requirement creeps Emerging applications Unforeseen complexities … SoS Evolutionary Spirals Spiral Alpha Time

13 6/17/2015 Outline  Background, motivation and goals −Relevant needs and trends in SoS system engineering and management −Development objectives  Basic foundations for the SoS WBS −Product-oriented structure −Scalable Spiral Model −Three-team construct  Net centric System of Systems (SoS) Program Work Breakdown Structure (WBS)  Implications and anticipated benefits  Conclusions

14 6/17/2015 SoS Program WBS The SoS Program The SoS in Operation Spiral AlphaSpiral BravoSpiral CharlieProgram Office Plan- Driven Team IV&V Team Agile Team Level 0 Level 1 Development

15 6/17/2015 The SoS Program WBS (cont.)  The SoS in Operation: consists of legacy systems, current operational organizations, “as-is” doctrine and CONOPS −Important in understanding the baseline “as-is” architecture and business case analysis  Spiral Alpha: current development increment executed by the Plan- Driven Team, with relative stable capability objectives, requirements, architecture baseline, and clear deliverables  Spiral Bravo: next development increment in planning by the Agile Rebaselining Team; new baseline based on near- to mid-term capabilities needs, priorities and new technologies in test labs  Spiral Charlie: future development increment in planning by the Agile Rebaselining Team; new baseline based on future capability needs, priorities and emerging technologies  Program Office: the supporting enterprise with a mission and resources to accomplish the mission −Three teams under it −Enterprise-level/(DoD) DOTMLPF support

16 6/17/2015 The SoS in Operation – the Legacy The SoS in Operation Operational Plans Operational Organizations Member Systems Peer Systems Communications Infrastructure Operational Maintenance & Support Operational Facilities Operational Doctrine Operational Architecture Operational Processes Resources and Budgets Subplans Organization 1 Organization 2 … Organization k System 1 System 2 … System n Peer System 1 Peer System 2 … Peer System p Site 1 Site 2 … Site m Support Centers Support Organizations Training Services Logistics Depots Maintenance Services Data Centers Networks Processes & Procedures Level 1 Level 2 Level 3

17 6/17/2015 The SoS in Operation – Dealing With Legacy  Operations & Maintenance (O&M) centric  Coping with “as-is” architecture, capability and interoperability −Inconsistent doctrine, processes −Different CONOPS −Partial interoperability −Ad hoc communications protocols −Gaps and overlaps in functionality  Adapt to emerging behaviors (trial and error, “learning the rope”)  Typically managed by different program offices or service organizations  Source for new capability needs and acquisition requirements  Baseline for business case analysis, e.g., ROI

18 6/17/2015 Spiral Alpha – Current Development Increment The SoS Version Alpha Phase/Spiral Plan Operational Requirements The Capability Model Peer Systems Member Systems Lifecycle Support Systems Communications Infrastructure Spiral Alpha Operational Plans & Processes Systems Operational Organizations Operational Facilities Training Functions The Integrated and Verified SoS The Validated SoS The Deployed SoS Mission Objectives & Constraints Proposal The WBS Resource & Budgets Estimates Integrated Master Plan & Schedule Subplans Performance, Cost, and Schedule Objectives & Thresholds Requirements by Type CONOPS Operational Architecture Baseline Functional Allocation & Synthesis Products Key Performance Parameters M&S & Analysis Models System 1 … System n Retired System n+1 … Retired System n+k Peer System 1 … Peer System p System 1 … System s Existing Infrastructure Added Infrastructure Plan-Driven Team IV&V Team Requirements, Plan & Processes Integration, Assembly, Test & Checkout Systems Integration Labs & Test Facilities Systems to be Integrated Personnel Requirements, Plan & Processes Operational Test & Evaluation Systems Integration Labs & Test Facilities Validation Data Personnel Level 1 Level 2 Level 3

19 6/17/2015 Spiral Alpha (cont.)  Responsible by the Plan-Driven Team; verified and validated by the IV&V Team  Relative stable requirements and delivery goals  Development/acquisition objective: operational capability  Development methodology predominantly focused on function allocation and synthesis (integration) −Rather than performance-driven at the system level  Increasing emphasis on COTS systems integration  More waterfall like development model  Post-Milestone A/pre-MS B (DoD 5000) entry typically  The delivery becomes the new “as-is” SoS in Operation

20 6/17/2015 Single System The System The System Plan System Requirements The System Design The Integrated and Verified System The Subsystems The Operational System The Validated System Subsystems 1Subsystems iSubsystems n…… Maintenance & Support Systems Operational Personnel (dedicated) Operational Facility (dedicated) Manuals & Procedures Operational Data Support Systems Training Function Support Personnel (dedicated) Support Facility (dedicated) Maintenance & Spares Modified version of Ruskin’s model Lifecycle orientation and O&M extensions Prototypical system WBS for any of the systems in the SoS Modified version of Ruskin’s model Lifecycle orientation and O&M extensions Prototypical system WBS for any of the systems in the SoS Level 3 Level 4 Level 5

21 6/17/2015 Spirals Bravo and Charlie Phase/Spiral Plan Operational Requirements The Capability Model Mission Objectives and Constraints The WBS Resource & Budgets Estimates Subplans Prioritized Performance, Cost, and Schedule Objectives Prioritized Requirements by Type CONOPS Operational Architecture Baseline Functional Allocation & Synthesis Products Key Performance Parameters M&S & Analysis Models Agile Team The SoS Version Bravo (Charlie) Baseline Spiral Bravo (Charlie) Level 1 Level 2 Level 3

22 6/17/2015 Spirals Bravo and Charlie (cont.)  Principal deliverables are capability and architecture models  Principal responsibility of the Agile Team −Working independently from the Plan-Driven Team −May take on the overall SE&I role for the program  Lifecycle perspective for evolution  Focused on prioritization of future capability increments  Primary repository of future/postponed capability needs and requirements for acquisition  Primary drivers for future capability needs: −Changing user needs −Changing environment or threats −Emerging technologies −Budget and resource constraints −Lessons Learned  Pre-concept phase or pre-Milestone A activities typically  Basis for future Spiral Alpha WBS

23 6/17/2015 Program Office – The Supporting Enterprise The Program Office The Program Mission Capability Models Suboffices The Program Plan Stakeholder Group Mission Statement Lifecycle Objectives Doctrine & Policies Capability Needs Documents Lifecycle Architecture Products Joint Capabilities Documents (JCDs) Initial Capabilities Documents (ICDs) Capability Development Documents (CDDs) Capability Production Documents (CPDs) Integrated Architecture Products Capability Roadmap Integrated Master Plan Integrated Master Schedule Business Case Documents Sub-plans The WBS Budget & Accounting Functions Legal & Contract Functions Acquisition & Supply Functions Systems Engineering & Integration Functions HR Function IT Support Function Administrative Support Functions PM End Users Systems Integrator PARM/OEM/System Suppliers Labs Peer Program Offices Operations Offices Level 1 Level 2 Level 3 Level 4

24 6/17/2015 Program Office (cont.)  The supporting enterprise ensuring successful evaluation of the SoS capabilities based on mission −Provides Organizational or (DoD) MOTMLPF supports to projects −Provides infrastructure (e.g., IT) support  Lifecycle evolutionary perspective  Planning, managing, doctrine and oversight roles −Manages the three teams – Plan-Driven, IV&V and Agile  PM role in the stakeholder group includes a stakeholder liaison function −Emerging and important function for SoS/FoS programs  Reports to acquisition/service branch −To (commercial) general manager  System Integrator is a role, not an entity −It has four potential job descriptions simultaneously: On the three teams The systems engineering & integration/capability planning at the program level

25 6/17/2015 Outline  Background, motivation and goals −Relevant needs and trends in SoS system engineering and management −Development objectives  Basic foundations for the SoS WBS −Product-oriented structure −Scalable Spiral Model −Three-team construct  Net centric System of Systems (SoS) Program Work Breakdown Structure (WBS)  Implications and anticipated benefits  Conclusions

26 6/17/2015 Implications of Scalable Spiral Model  Evolution-oriented and capability-focused  Risk-driven and mission assurance  Good transition for the culture and legacy program management −Good talent pool for Plan-Driven Team  Less material-oriented deliverables from early spiral(s) −Architecture baseline more a focus  Different operational philosophy and management skill set −Build-to-spec will not work −“Best value” objectives −Cost, risk and schedule as independent variables  Requires forward-looking vision and a new breed of PMs

27 6/17/2015 Implications of Standardized SoS-Level WBS  Two prevalent structures: −Product-oriented −Activity-based  Integration with process-oriented and activity-based structures −Start with one structure at the top and integrate elements of the other at lower levels  Need to provide clear and consistent definition of terms −Or potential risks of double-counting −Need for glossary and data dictionary  Possible different organizations for different purposes −Different development models  Less clear boundary for scope and division of responsibility −Are the day-to-day operational activities (and personnel) “sunk cost”? −Whose responsibility is it to establish doctrine, program office or larger enterprise?  Implications to cost estimating  Linkage to other architecture products

28 6/17/2015 Anticipated Benefits  Provides a reference model for SoS/FoS engineering and management  Defines a common set of terminology related to SoSs  Enables visibility and insights into unique issues related to SoSs  Provides a holistic view for SoS engineering and program management, particularly in terms of −Interoperability −Complexity and interdependency −Ownership and governance model −Conflict management −Decision framework  Facilitates further understanding of the −Effort and cost in acquiring and owning an SoS −Methodology that can be applied to estimate this cost  Promotes the unification of systems engineering and project management for SoS −Linkage between architecting/engineering activities to the economic effect

29 6/17/2015 Outline  Background, motivation and goals −Relevant needs and trends in SoS system engineering and management −Development objectives  Basic foundations for the SoS WBS −Product-oriented structure −Scalable Spiral Model −Three-team construct  Net centric System of Systems (SoS) Program Work Breakdown Structure (WBS)  Implications and anticipated benefits  Conclusions

30 6/17/2015 Conclusions To Date  General systems engineering principles and project management practices do apply to net centric SoS  Traditional system-oriented WBS construct is inadequate, and there are added ingredients in WBS for net centric SoS, from −Added complexity −Different scope, objectives and strategy −Different environment  Two different acquisition focuses: −System: functionality −System of systems: capability  And, therefore, two different development strategies: −System: waterfall −System of systems: scalable spiral  Not a complete WBS, but a step towards that direction  A lot to learn, and more to explore…

31 6/17/2015 References 1)B. Boehm, “The Future of Software and Systems Engineering Processes,” USC-CSE-TR , )Boehm, B. and Turner, R., Line Dancing with Elephants – the Systems Engineering of Network-centric Complex systems of Systems (NCSOS), SSCI Member Forum, )A. Ruskin, “Using 100% Product-Oriented Work Breakdown Structures to Unify System Engineering and Project Management,” ICSE-INCOSE, )A. Sage and C. Cuppan, “On the Systems Engineering and Management of Systems of Systems and Federations of Systems,” Information.Knowledge.Systems Management, )M. Jamshidi, “System-of-Systems Engineering – a Definition,” IEEE SMC 2005, Hawaii, October )J. Lane and R. Valerdi, “Synthesizing System-of-Systems Concepts for Use in Cost Estimation,” IEEE SMC, )J. Lane, “COSOSIMO Workshop Minutes,” )C. Dickerson and et al, Using Architectures for Research, Development and Acquisition, OASD-NII, )P. Jain, and C. Dickerson, “Family-of-Systems Architecture Analysis Technologies,” INCOSE, )D. Bracamonte, “An Adaptive Automated Model for formatting & Presenting Life Cycle Costs,” ISPP Proceedings, )ISO/IEC 15288, Systems Engineering – System Life Cycle Processes, )DoD Instruction , Operation of Defense Acquisition System, )ANSI/EIA 632, Process for Engineering a System, )J. Martin, “Overview of the EIA 632 Standard – ‘Processes for Engineering a System’ (Tutorial G)” 15)MIL-HDBK-881, DoD Work Breakdown Structure, 1993

32 6/17/2015

33 6/17/2015 Example of Product-Oriented WBS The System The System Plan System Requirements The System Design The Integrated and Verified System The Subsystems System Post- Accomplishment Products The Validated System Subsystems 1Subsystems iSubsystems n…… The Subsystem i Plan Subsystem i Requirements The Subsystem i Design The Integrated and Verified Subsystem i The Subsystem i’s Sub-Subsystems Subsystem i Post- Accomplishment Products The Validated Subsystem i Source: A. M. Ruskin System-level WBS… … for engineering and constructing a system