Systems Engineering and Open Systems

Systems Engineering and Open Systems
Dr. Martin Falk Mr. Glen Logan

Systems Engineering Recent OSD & Service Initiatives
NASA Accident Experience Current Challenges Related to Technical Management

Uneasy Feeling that You are Headed for Trouble?

Perception Growing realization that systems engineering focus was lost in DoD, NASA, and NRO during last decade. Systems engineering capabilities have deteriorated in both government and industry. Substantial efforts and initiatives now underway to fix the problem.

Cost Overrun Risk vs. Systems Engineering Effort
90% Assurance Average Cost Overrun Source: SECOE 01-03, INCOSE 2002

Schedule Overrun Risk vs. Systems Engineering Effort
90% Assurance Average Schedule Overrun Source: SECOE 01-03, INCOSE 2002

Systems Engineering Process
RISK MANAGEMENT TPM/METRICS COST-PERFORMANCE TRADES TEST EFFECTIVENESS REVIEWS CONFIGURATION MANAGEMENT TECHNICAL REVIEWS Requirements SYSTEMS ANALYSIS & CONTROL REQUIREMENTS ANALYSIS Objectives Track progress Ensure requirements traceability Evaluate alternatives Manage risk FUNCTIONAL ANALYSIS & ALLOCATION DESIGN SYNTHESIS Designs Systems Engineering Fundamentals, DAU Press

System Development ‘V’
SYSTEM LEVEL DESIGN REQUIREMENTS V SYSTEM LEVEL DESIGN SVR SFR ITEMS FAB, INTEGRATE & TEST TRR PDR ITEM LEVEL DESIGN REQUIREMENTS ASSEMBLIES COMPONENTS CDR DESIGN REQUIREMENTS COMPLETE

The Defense Acquisition Management Framework DoDI 5000.2 (Spring 2003)
(BA 1 & 2) User Needs & Technology Opportunities A B C IOC FOC Process entry points at Milestone A, B, or C Entrance criteria met before entering phase Evolutionary Acquisition or Single Step to Full Capability Concept Refinement Technology Development System Integration System Demo LRIP FRP & Deployment Operations & Support Concept Decision Design Readiness Review FRP Decision Review Full-Rate Prod & Deployment Full rate production Deployment of system System Dev & Demonstration Production & Deployment Pre-Systems Acquisition Systems Acquisition Sustainment Funding: BA 3/4 BA 5 BA 5/Procurement Proc/Operations & Maintenance CDD CPD Validated & approved by operational validation authority ICD Rqmnts: Increment II B DRR C FRP Increment III B DRR C FRP Conduct AoA, refine initial concept & develop Technology Development Strategy Concept Refinement Reduce technology risk & determine the appropriate set of technologies to be integrated into a full system Demo the technologies in a relevant environment Technology Development Integrate subsystems, complete detailed design, and reduce system-level risk System Integration Complete development Demonstrate ability of system to operate in useful way consistent with KPPs Combined DT/OT System Demonstration Low-Rate Initial Production Create efficient manufacturing capability LRIP IOT&E, LFT&E of prod-rep articles

Systems Engineering As Applied To Concept Refinement
Prelim Sys Spec T&E Strategy SEP Support & Maintenance Concepts & Technologies Inputs to: -draft CDD, -TDS, -AoA - Cost / Manpower Est ICD AoA Plan Exit Criteria Alternative Maintenance & Logistics Concepts Systems Engineering As Applied To Concept Refinement Analyze & Fix ASR Interpret User Needs, Analyze Operational Capabilities & Environmental Constraints Operational Expectations Analyze/Assess Concepts Versus Defined User Needs & Environmental Constraints MS A Analyze & Fix Trades Develop Concept Performance (& Constraints) Definition & Verification Objectives System Functional Expectations Assess/Analyze Concept & Verify System Concept’s Performance Integration & Verification/ Validation Decomposition & Definition Trades Analyze & Fix Decompose Concept Performance into Functional Definition & Verification Objectives Configuration Item Expectations Assess/Analyze System Concept Versus Functional Capabilities Systems Engineering Responsibility, Component Engineering Participation Trades nalyze & Fix Decompose Concept Functional Definition into Component Concepts & Assessment Objectives Assess/Analyze Enabling/Critical Components Versus Capabilities Component Expectations Component Engineering Responsibility, Systems Engineering Participation Trades Develop Component Concepts, i.e., Enabling/Critical Technologies, Constraints & Cost/Risk Drivers

Systems Engineering As Applied To Technology Development
ICD & Draft CDD Preferred Sys Concept Exit Criteria T & E Strategy Support & Maintenance Concepts & Technologies AoA SEP TDS Sys Performance Spec LFT&E Waiver Request TEMP, SEP, PESHE, PPP, TRA Validated Sys Support & Maintenance Objectives & Requirements Footprint Reduction Inputs to : - IBR, -ISP,- STA, CDD, - Acq Strategy -Affordability Assessment -Cost / Manpower Est Systems Engineering As Applied To Technology Development Analyze & Fix MS A Interpret User Needs. Analyze Operational Capabilities & Environmental Constraints Operational Expectations SRR Demo & Validate Sys Concepts & Technology Maturity Versus Defined User Needs Analyze & Fix Trades Develop System Performance (and Constraints) Specification and Critical Technology Verification Plan System Functional Expectations Demo/Model Integrated System Versus Performance Spec Integration & Verification/ Validation Decomposition & Definition Trades Analyze & Fix Develop Functional Definitions for Enabling/ Critical Technologies & Associated Verification Plan Configuration Item Expectations Demo System Functionality Versus Plan Systems Engineering Responsibility, Component Engineering Participation Trades Analyze & Fix Decompose Functional Definitions into Critical Component Definition & Tech Verification Plan Component Expectations Demo Enabling/Critical Technology Components Versus Plan Component Engineering Responsibility, Systems Engineering Participation Trades Develop System Concepts, i.e., Enabling/Critical Technologies, Update Constraints & Cost/Risk Drivers

Systems Engineering As Applied To System Development and Demo
Sys Performance Spec Exit Criteria Validated Sys Support & Maintenance Objectives & requirements APB, CDD, SEP ISP, TEMP Initial Prod Baseline Test Reports, TEMP Elements of Product Support Risk Assessment SEP, TRA, PESHE Inputs to: -CPD,-STA, - ISP -Cost / Manpower Est Systems Engineering As Applied To System Development and Demo MS B Analyze & Fix SVR/PRR Interpret User Needs, Refine System Performance Specs & Environmental Constraints Combined DT&E/OT&E/LFT&E Demonstrate System to Specified User Needs & Environmental Constraints Operational Expectations Trades Analyze & Fix SRR OTRR Develop System Functional Specs & System Verification Plan System DT&E, LFT&E & OAs, Verify System Functionality & Constraints Compliance to Specs System Functional Expectations Integration & Verification/ Validation Decomposition & Definition SFR Trades Analyze & Fix Evolve Functional Performance Specs into CI Functional (Design to) Specs and CI Verification Plan Configuration Item Expectations Integrated DT&E, LFT&E & EOAs Verify Performance Compliance to Specs Systems Engineering Responsibility, Component Engineering Participation Trades PDR Analyze & Fix Evolve CI Functional Specs into Product (Build to) Documentation and Inspection Plan Component Expectations Individual CI Verification DT&E Component Engineering Responsibility, Systems Engineering Participation Trades CDR DRR Fabricate, Assemble, and Code to “Build-to” Documentation

NASA Small Satellites Accident Investigation
A concise set of mission success criteria should be established early in program Solid engineering discipline is required at all program stages, especially transition to ops Continuous risk management is a must. Risk should be considered on a par with cost, schedule, and performance Entire team must take personal responsibility for the product

Areas Most Common to Failed Programs
Poorly structured and conducted technical reviews (6 of 8) Poor risk management practices (6 of 8) Inadequate testing, simulation, and V&V (6 of 8) Poor communications (5 of 8)

How Did We Get Here? Acquisition reform expectations were not clearly communicated to working level program managers, engineering and contractor staffs. We convinced ourselves that we could have it all – faster, better, and cheaper. We compromised performance and management discipline to save time and money.

Challenges in Systems Engineering Management
Interoperability Systems of Systems Insight vs Oversight Technology Change Rate Commercial-NDI Technical expertise in short supply Design for…everything

Missile Defense System
Systems of Systems Capstone SYSTEM Missile Defense System Cooperating Systems Detection C3I Weapon SE Issues Capstone Capabilities vs. System Level Requirements Interoperability Commonality Modular Designs

Interoperability Systems of Systems demand interoperability among systems Requires ‘reasoned sub-optimization’ to select interface standards that benefit the integrated system. “Systems Thinking” must be a way of life. Demands that systems be integrated from the outset – a top down process vice the system up process used to date Gives rise to JCIDS and Joint Technical Architecture

Problem: IER Scalability
One-to-One Current Interoperability KPP centers around one DoD architectural view (OV-3) that contains “Information Exchange Requirements” (IERs) One-to-one relationship (point-to-point) As new systems are added to the GIG, more one to one system interchanges (IERs) must developed and tracked. Adding new systems multiplies this problem because existing systems must develop additional interfaces (IERs) as well. Growing numbers of systems interfaces mean growing numbers of IERs and growing complexity (i.e.: IERs don’t scale). In the example depicted Using 10 systems you can see the potential for having to come up with 90 various interfaces for the systems. I will now discuss our solution to this dilemma. This example: 10 systems IERs 10(10-1) = 90

Solution: The Net-Ready Approach
One-to-Many Net Ready approach centers on central network: Focus on organizational contributions and consumption of information One-to-network paradigm Network The Net Ready approach focuses on a one-to-many. In this approach Net Ready systems just need to plug into the the Network. NET READINESS provides common capabilities to: Task, post, process, use, store, manage and protect information resources on demand for warriors, policy makers, and support personnel Facilitate information sharing across systems It supports: Entire DoD and Intelligence Community (IC) Conventional and Nuclear Warfighting Business units (e.g., FMMP) It provides programmatic features “Fast Track” Concept development and OSD/JS/Service/Agency Coordination Deals with transition from Common Operating Environment (COE) Systems that plug into to the Network will exchange common data through a set of common enterprise services and interfaces which allow for flexible and dynamic specification of data producers and consumers and data routing (i.e.: Scales easily) and all transparent to the users. The Network-Ready approach will encompass: Technical Standards as the “bedrock” (for basic, “bit-level” interoperability), Configuration Management of the implementation of those standards via the regulation of Key Interface Points (KIPs) (for inter-system and platform interoperability), Standard Tactics, Techniques and Procedures (TTPs) for connection and use of the network (for operational network-level interoperability) and to determine network load. And as you note the potential interfaces that systems will have to deal with is 1 – that is 1 interface to “The Network” This example: 1 system has to deal with 1 interface

Net-Ready KPP Comprised of compliance with:
“Consists of measurable and testable characteristics and/or performance metrics required for timely, accurate, and complete exchange and use of information to satisfy information needs for a given capability.” CJSI C Comprised of compliance with: Net-Centric Operations and Warfare Reference Model Global Information Grid Key Interface Profiles DOD information assurance requirements Supporting integrated architecture products J-6 certifies NR-KPP JITC evaluates and certifies Joint interoperability C4ISP replaced by Information Support Plan The Net Ready KPP does several things for us: It evolves the Interoperability KPP beyond an IER-based construct and incorporates net-centric concepts, It provides means to evaluate both the technical exchange of information and the end-to-end operational effectiveness of that exchange It assesses information needs, information timeliness, information assurance and net-ready attributes for information exchange and use It includes Communities of Interest, processes, activities, and organizations required to assess exchange and use of information And it provides opportunity to assess and balance interoperability with information assurance requirements Net Ready KPP contains the 4 pillars: NCOW-RM or the Net Centric Operations and Warfare Reference Model- Describes the activities required to establish, use, operate, and manage the net-centric enterprise information environment Integrated Architecture Products Information Assurance - DoD Information Technology Security Certification and Accreditation Process (DITSCAP) Key Interface Profiles or KIPs that describe a standard of connecting to the Global Grid for critical warfighting interfaces Each of these pillars bring different but complimentary products and attributes to Net Readiness. By complying with the NET READY KPP systems will be Net Ready when they reach production. *

Architectures

DoD Architectural Framework
DoD Architecture Framework Working Group Version 1.0 Vol ume II: Product Description 9 February 2004 Systems Technical Operational Source for direction and information on the development of Operational, System, and Technical Architectures to support system developments.

Integrated Architecture: One Architecture - 3 Views
The Systems View describes and interrelates the existing or postulated technologies, systems, and other resources intended to support the operational requirements. The Operational View describes and interrelates the operational elements, tasks and activities, and information flows required to accomplish mission operations. The Technical View describes the profile of rules, standards, and conventions governing systems implementation. Operational Systems Technical

Insight vs. Oversight Concept:
Contractor flexibility to innovate, seek improved means to deliver improved products (faster, better, cheaper) Government retains control of top level requirements, has required visibility to make informed key decisions Practice: Technical managers in some cases believe they have little or no leverage to require information or to effect change Frustration with perceived responsibility absent authority Government has obligation to ensure that technical management practices are sound; may at times feel like oversight.

Commercial and Non-Developmental Items
CI-NDI offer real benefits: Shorter development cycles Development costs already amortized Continuing benefits from commercial competition …but also have real (sometimes not apparent) costs: May bias requirements to favor current, known capabilities Integration difficulties may be overlooked Updates and sustainment subject to marketplace Testing is a continuous activity Modified commercial items lose most of perceived benefits

Design for...everything [Some of the] design considerations (per Defense Acquisition Guidebook): Producibility – Interoperability Quality – Survivability Supportability – System Security Open Systems – Electromagnetic Effects Software – Value Engineering Environmental, Safety, Health – Unplanned Stimuli Human Systems Integration – Vertical Integration Standardization Reliability, Maintainability, Availability Corrosion

Technical Expertise in Short Supply
Fewer technical experts available in government Downsizing Hard to attract needed expertise Aging workforce eligible for retirement Inevitable consequence is more dependence on contractors to make technical management judgments Substantial evidence that, when budget and schedule pressures are applied, contractors may not make good technical management decisions

Technology Change Rate
Computer and communications technologies have very short life cycles; much shorter than systems of which they are a part. Designs must accommodate frequent updates - during development and after Open systems architectures and modular designs are recommended design approaches to address problem While conceptually easy to grasp, these strategies are often poorly understood at the implementation level.

Technical Management Leading Indicators
Change vs. Time Requirements Designs Testing Specs and ICDs: Approved vs. Planned Development Specs: 50% by PDR; 100% by CDR Subcontracts: Signed vs. Planned 30-50% by PDR; 100% by CDR 5-10% max deviation USAF/AQ Guidance 01/07/04 Robust Engineering of Air Force Acquisition Programs

Engineering Manpower: Total vs. Plan Design Documentation: Actual vs. Plan Drawing release: 40% by PDR; 90% by CDR Trade Studies: Completion 75-100% design definition studies complete by PDR Software Products: Complete vs. Time 10% variance threshold typical EVMS: Completion and Complexity USAF/AQ Guidance 01/07/04 Robust Engineering of Air Force Acquisition Programs

HW and SW Deliveries vs. Plan Technical Performance Measures: Technical performance vs. plan profile Deficiency Reports: Actual vs. expected Maintenance and Support Facility Changes Minimal after Milestone C Action Item Closure after Design Reviews Key Characteristics Defined 70-90% by PDR; 100% by CDR USAF/AQ Guidance 01/07/04 Robust Engineering of Air Force Acquisition Programs

Testing Activities: Approved vs. Planned Proposed schedule vs. Actual Subcontract Management Listed indicators monitored by prime for subs USAF/AQ Guidance 01/07/04 Robust Engineering of Air Force Acquisition Programs

Systems Engineering “Things to Look For”
Systems Engineering Management Plan Requirements Management/Traceability Risk Management Plan/Process Technical Performance Measures Configuration Management Plan/Process Systems Engineering Training

Summary Systems engineering is in the process of a comeback as a discipline central to acquisition success. Today’s issues and challenges are complex – made more so by virtue of joint warfighting and systems of systems. There is no free lunch – this stuff is hard and it takes time and money to get it right.

Backup

Systems Engineering Process
Requirements The Inputs to the Systems Engineering Process Systems Engineering Process Operational Function Performance Interfaces Support Funding Technology Legal Regulation Compliance The major inputs to the systems engineering process are REQUIREMENTS Requirements take many forms. There is a tendency to focus on operational requirements to the exclusion of other requirements. While operational requirements should be given heavy weight, the system design must consider requirements from other sources Legal – environmental law Regulatory – DoD R Compliance – Joint Technical Architecture Technology – may present restrictions or opportunities

Operational Requirements
Mission Area Analyses Comprehensive, analytic evaluations of capability vs. requirements in an assigned mission area Mission Needs Statement (MNS),Initial Capabilities Document (ICD) Non-specific statement of operational capability required to accomplish a given mission Operational Requirements Document, Capabilities Development Document (CDD) Objectives and minimum acceptable thresholds for a specific concept or system. ANIMATED SLIDE Operational requirements are generally considered to be the prime requirements. The definition flows from MAA to MNS to ORD Explain each as it comes visible Capabilities Production Document (CPD)

Requirements Analysis
OBJECTIVE: Define the Problem REQUIREMENTS ANALYSIS Functions – WHAT must system do? Performance – HOW WELL? Interfaces – UNDER WHAT CONDITIONS? Other Constraints This was discussed earlier Focus here on extracting Function Performance Interface From the requirements documents. These form the basis for the analysis. Note again that most requirements are not stated, but it is critical that those that are be included and considered, lest the result be a system that does not meet requirements. Performance Specifications describe products and services In terms of Function Performance Interface

Requirements Analysis – Two Part Process Operational Concept Definition
functions Cruise Climb Altitude Speed Distance Attack Rate Altitude Takeoff performance Distance Surface Quoting here from INCOSE text on systems engineering The first step is to ensure that the designer has a firm grasp of the Operational Concept. By understanding the mission, the designer comes to a better ability to question and ensure that important characteristics have not been overlooked or omitted. These concepts are best done collaboratively between users and engineers. Note that function and performance are intimately related. Timelines and other devices are often used to conceptually understand the operational imperatives. …to get agreement between users and developers on key mission requirements and parameters timeline

Requirements Analysis Design Requirements Definition
ORD TAKE-OFF CLIMB CRUISE ATTACK Distance Surface Detect Ident Once top level functions and performance are identified and understood, classic functional analysis is generally used to further develop requirements. By decomposing top-level requirements into lower level requirements, one comes to understand what is implied by a given requirement. This is often required to fully understand the operation of the system and it often exposes problems that would not have otherwise been evident. Identify and confirm explicit requirements Identify key implicit requirements – function, performance, and interface Trace flow down of requirements Establish design constraints

Requirements Flowdown
• Aircraft will be capable of air operations from carrier... ORD SYSTEM SPEC • Aircraft landing weight NTE 50,000 lb... • Approach/landing speeds NTE 150 and 110 kts respectively... • System will be supportable by existing USN logistics system... AIRFRAME SPEC ENGINE SPEC Note the ORD-SPEC flowdown here We are translating from operational language into technical requirements There are a number of reasons why a specification may not duplicate the requirements of the ORD Development test facilities may require adjustment – but test must show a growth path to operationally required levels It may be absolutely impossible to test some requirements • Empty gross weight NTE 15,000 lb... • Absorb shock ...15 fps rate of descent... • ...tailhook... • Weight NTE 15,000 lb... • Thrust NLT 30,000 lb at max power (SL/std day)... ITEM SPECS

Functional Analysis & Allocation
INPUTS: Functions Performance Interfaces Other Products From Requirements Analysis REQUIREMENTS ANALYSIS ANALYSIS & CONTROL FUNCTIONAL ANALYSIS & ALLOCATION DESIGN SYNTHESIS OUTPUT: Functional Architecture – Logical Description, Performance Allocated to Functions The outputs from REQUIREMENTS ANALYSIS become the inputs for FUNCTIONAL ANALYSIS. We start with the top-level functions, performance, and interface parameters. The purpose is to understand what is implied by the requirements, how the various functions relate to each other, what functions have precedence over others, etc. Much of what comes out of functional analysis is the set of implied, or derived, requirements – which usually far outnumber the explicitly stated requirements. There are several ways to approach FA&A Scenario/profile descriptions Classic functional decomposition More will be said on these later. The output is a functional description of the system (functional architecture). It could include not only the functional and performance descriptions, but might also include such things as data flow diagrams, system state diagrams, and the like. CRUISE ATTACK TRACK IDENTIFY DETECT AIM Target Types PK Time ATTACK CLIMB TAKEOFF

Example function performance
Requirement: Attack light armored vehicles within 30 minutes of identification under <defined> weather conditions, with a Pk not less than Coordination and control exercised by Army Fire Direction System. interface 30 min Pk 0.85 Attack Detect ID Track Aim Fire Comm TD PD TC PC TID PID TT PT TA PA TF PF AFDS Here is a simple requirement showing the identification of function, performance, and interface The primary (top-level) function ATTACK is decomposed into lower-level functions The performance requirements (time and probability of kill) are then allocated across the lower-level functions The interface with AFDS is shown though this diagram shows none of the protocols and standards that would be needed to adequately define the interface

Alternative Architecture
Or…? This shows two possible architectures that might have been developed from the requirement The first was shown on the previous viewgraph and is shown top left The second shows an alternative Detection and ID are performed by an off-board asset (e.g., AWACS) A handoff is performed – data link to AFDS Linked in turn to our system Leaving the system with only Track, Aim, Fire functions to perform Question: What are benefits and costs associated with the alternative? Which is the better choice? Key functions accomplished by off-board system May require less development if capabilities already exist On board attack function requires less time for this system More interfaces, more complexity Is this a better choice? Depends on technical and cost issues

Functional Analysis & Allocation
Steps in Functional Analysis and Allocation Decompose top level functions to next lower level Allocate performance requirements to functions (higher level to lower level) Evaluate alternative architectures Select and refine preferred architecture How To Emphasize the development of alternatives and the selection of preferred architectures. Cost-Performance trade-offs Result: a logical description of the product with performance parameters such that specific hardware and software elements capable of performing the required functions (at the required levels of performance) can be identified- the Functional Architecture

Design Synthesis Once a preferred architecture is
selected, design alternatives can be developed and compared. A selected Functional Architecture should suggest several alternative concepts or designs that could conceivably do the job. Once the preferred functional architecture is selected, design synthesis can begin The message here is that various physical architectures (designs) can – and should – result from a single, common functional architecture The issue becomes cost-effectiveness. Which will be most effective for the mission in terms of both performance and cost?

Design Synthesis INPUTS: Functional Architecture OUTPUT:
REQUIREMENTS ANALYSIS ANALYSIS & CONTROL FUNCTIONAL ANALYSIS DESIGN SYNTHESIS This is the product element of the WBS! Then the process is to use a disciplined, rational approach to selection of the preferred design. AIR VEHICLE OUTPUT: Physical Architecture An architecture of physical elements capable of performing the functions required at the levels of performance specified AIRFRAME PROPULSION AVIONICS WEAPON

Design Requirements Prime Item Specification Development
As functions and performance parameters are associated with physical elements, a set of design criteria are developed for those elements Item Specification Development comes out of this process As functions and performance are associated with physical elements, these are documented in the Item Performance Specs, which are the design documents for those items Detection Tracking Range Probability Detect Weapon, Chassis Functions Performance Interfaces

Design Requirements Prime Item Development Specification
Definition of the Allocated Baseline A performance spec is developed for each major configuration item to be developed. These specs set out the design requirements for the items Together these specs document the Allocated Baseline for configuration control purposes

Systems Engineering As Applied To Systems Development
Analyze & Fix Elicit User Needs, Analyze & Define Operational Capabilities, Define Environmental Constraints, Develop System Performance Spec and System Validation Pan Demonstrate and Validate System To Specified User Needs & Specified Environmental Constraints Operational Expectations Analyze & Fix Trades Evolve System Functional (and Constraints) Specification and System Verification Plan System Functional Expectations Integrate System Components, Verify System Functionality & Constraints Compliance to Specs Integration & Verification/ Validation Decomposition & Definition Trades Analyze & Fix Evolve Performance Specifications into CI Functional (Design to) Specs and CI Verification Plan Configuration Item Expectations Test System CIs, Verify Performance & Constraints Compliance to Specs Systems Engineering Responsibility, Component Engineering Participation Trades Analyze & Fix Evolve CI Functional Specs into Product (Build to) Documentation and Inspection Plan Component Expectations Inspect to “Build to” Documentation Component Engineering Responsibility, Systems Engineering Participation Trades Fabricate, Assemble, and Code to “Build-to” Documentation

Systems Engineering and Open Systems

Similar presentations

Presentation on theme: "Systems Engineering and Open Systems"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Systems Engineering and Open Systems

Similar presentations

Presentation on theme: "Systems Engineering and Open Systems"— Presentation transcript:

Similar presentations

About project

Feedback