Longo School Furniture by Stevens Industries: ID Systems Series
1 Introduction to Systems Engineering SAGE Pilot Teacher Workshop Aug 4 th 2008 Eirik Hole School Of...
-
Upload
jeffery-atkins -
Category
Documents
-
view
215 -
download
0
Transcript of 1 Introduction to Systems Engineering SAGE Pilot Teacher Workshop Aug 4 th 2008 Eirik Hole School Of...
1
Introduction to Systems Introduction to Systems EngineeringEngineering
SAGE Pilot Teacher Workshop Aug 4SAGE Pilot Teacher Workshop Aug 4thth 2008 2008
Eirik HoleSchool Of Systems and Enterprises
Stevens Institute of [email protected] Tel: (201) 216 8308
2
Let’s Engineer a Drive Let’s Engineer a Drive ShaftShaft
Design Loads
EnvironmentalConditions
GeometricEnvelopes
Functions
Interfaces
External DesignStandards
Internal DesignStandards
Geometry
Materials
Coatings
SpecialProcesses
ProductionQA-Procedures
R&D
$
Manuf.
$Time
Resources
3
An Aileron Drive Shaft in a An Aileron Drive Shaft in a Wing AssemblyWing Assembly
Handling
Characteristics
OperationalScenarios
EnvironmentalConditions
FlightPerformance
WeightLimitations
External DesignStandards
Internal DesignStandards
Main Elements
AllocatedFunctions
DecomposedEnvironment
DecomposedLoads
Geometric
Envelopes
Interfaces
4
Why Are We Why Are We Engineering a New Engineering a New
Drive Shaft?Drive Shaft?Capacity
Range
Cruise Speed
Cost of Ownership
Availability
OperationalArea
Image
Standards
RegulationsRegulations
RegulationsRegulations
StandardsStandards
StandardsStandards
Part of a larger system…Part of a larger system…
5
Which is part of a even larger Which is part of a even larger systemsystem
6
7
What is a System?What is a System?Mil-Std 499B: An Mil-Std 499B: An
integrated composite of integrated composite of people, products, and people, products, and
processes that provide a processes that provide a capability to satisfy a capability to satisfy a
stated need or objective.stated need or objective.INCOSE Fellows Consensus: A system is a construct or collection of different elements that together produce results not obtainable by the elements alone. The elements, or parts, can include people, hardware, software, facilities, policies, and documents; that is, all things required to produce systems-level results. The results include system level qualities, properties, characteristics, functions, behavior and performance. The value added by the system as a whole, beyond that contributed independently by the parts, is primarily created by the relationship among the parts; that is, how they are interconnected (Rechtin, 2000).
The V-Model of System The V-Model of System DevelopmentDevelopment
8
Gather & DefineRequirements
System Design
Detailed Design
Fabricate&
Code
Component Test
System Integration& Verification
OperationalAcceptance
Decom
pose
&
Defin
eIn
tegr
ate
&V
erify
Feedback
Component Engineering
Systems Engineering
Systems Engineering Systems Engineering • Systems Engineering addresses the dual
problem of:(1) translating stakeholder needs into system
requirements(2) specifying components that, when integrated, will
satisfy those requirements
• In other words:stating the problem (i.e., defining the problem domain)
- and -
solving it (i.e., defining the solution domain)
“Systems Engineering is really about creating and delivering the courseware for the remaining 90% of the project”
Jack Ring6/3/08
10
Gather and Define Gather and Define RequirementsRequirements
• Identify the problem or need• Understand its context• What constraints are we
bound by?• What are the characteristics
and capabilities of a system that could satisfy this need within the constraints?
Context System (S1)
Realization System (S3)
Intervention System (S2)
Competing System (S7)
Modified Context System (S1’)
Deployed System (S4)
Sustainment System (S6)
Problem (P1)
Problem (P2)
may cause
Collaborating System (S5)
collaborates with
intended to address
becomes
may address
competes with
becomes
sustains
may need to develop or modify
needs to understand
needs to understand
The 7 Samurai, James N. Martin, INCOSE 2004
6/3/08
12
Have you considered the Have you considered the needs of all stakeholders? needs of all stakeholders?
• Users
• Purchasers
• Trainers
• Maintainers
• Distributors
• Sales outlets
• Company policies (and office politics)
• Developers
• Manufacturers
• Testers
• Others?
13
• Toyota launched its luxury automobile project in 1983• Japanese designers lived in California while creating initial designs
– Rented home in upscale neighborhood– Rented and drove luxury cars– Lived target buyer lifestyle
• After 5 months, team returned to Japan with exterior and interior design proposals
• Lexus vehicles an immediate success – well received by target buyersRef. Presentation by Donald Brown, Toyota Sales, USA, April 1, 1996
How Far Do We Go to How Far Do We Go to Understand the Need?? Understand the Need??
14 Copyright 2007 -- Stevens Institute of
Technology
Fat luxury………Fat luxury………
15
Stakeholder Needs – Stakeholder Needs – Capabilities and Capabilities and CharacteristicsCharacteristics• Capabilities – requirements that reflect
functions desired by the stakeholders – Examples for an Automatic Teller Machine: deposit or withdraw
money 24 hours a day; check account balances; transfer funds between accounts, etc.
• Characteristics –requirements that reflect system attributes – Examples for an Automatic Teller Machine: quality, reliability,
safety, security, cost, schedule, usability, aesthetics, performance, compliance with standards and protocols, technology preferences or constraints, etc.
– Others: size, weight, “look and feel”, durability...
16
ATM System
XYZ BankCustomer
UnfriendlyCustomer
ATM Admin
ATM Servicers
Customer Account
DB
NYCENetwork
HW Maint. CIRRUSNetwork
PLUSNetwork
Fraud / Break-inTransactionRequest
TransactionRequest
TransactionRequest
TransactionRequest
Response
Response
Response
Response
Log in /Service
Response
Reports
Log in /Request
RetrieveDeposits
DiagnosticResponse
Fill up w/ Cash
Service
DiagnosticResponse
Credit CardCustomer
Response
Log in /Request
BankManagement
Another Bank'sCustomer
Log in /Request
Log in /Request
Response
Context diagram example: Context diagram example: Automatic Teller MachineAutomatic Teller Machine
17
Capabilities Example: Develop Use Capabilities Example: Develop Use Cases for a Clinic Management SystemCases for a Clinic Management System
Requirements LayersRequirements Layers
Dr. Dinesh Verma
6/3/08
Technical System Technical System RequirementsRequirements
• Functional - necessary tasks, actions, or activities• Performance - extent to which mission or task must be
performed• Physical – constraints on size, weight, materials, etc.• Environmental – conditions like temperature, humidity, shock,
vibration, etc.• Interface – interactions between systems, users, environment • Modes and States – operational conditions of system• Quality characteristics – measures of system’s effectiveness/
efficiency in performing mission • Production – processes, facilities or tooling to produce a
product• Qualification – demonstrate conformance to stakeholder
needs and technical requirements
Requirements must be necessary and sufficient, verifiable, and well-written
“Don’t specify what you can’t verify.”
Characteristics of Good Characteristics of Good RequirementsRequirements
• Necessary and sufficient – defines essential capabilities, characteristics, constraints, quality
• Complete – contains everything pertinent• Feasible – technically possible within cost & schedule • Unambiguous – the language used can only be interpreted
one way • Verifiable – the means exist to show requirement is
satisfied• Consistent – free of conflicts with other requirements• Correct – accurately specifies what is required• What, not How – states problem only, no solutions• Simple – focuses on only one subject• Objective – No room for subjective interpretation or opinion
21
System DesignSystem Design
1. Everything goes somewhere
2. Everything interacts with everything else
3. There is no such thing as a free lunch
Dave F. McClinton
…or getting a balanced architecture that fulfils the requirements
22 Copyright 2007 -- Stevens Institute of
Technology
Generally Increasing Generally Increasing InterdependenceInterdependence
Source: Negele et. al. INCOSE Symp 2006
Take a functional and a physical Take a functional and a physical viewview
23
The carburetor manufacturers disappeared because they saw themselves as carburetor makers, not as providers of mixing fuel and air.
W. Edward Deming
24
Functional View Functional View
• A function is a process that transforms INPUTS into OUTPUTS
• A function describes an ACTION taken by the system or by one of its elements
• A function is represented by a VERB or verb-noun pair
Functional View of a Functional View of a DistillerDistiller
25
26
Physical ViewPhysical View• Provides the system resources to perform its functions
– Hardware– Software– Facilities– People– Procedures
• Generic physical architecture: description of the partitioned elements of the physical architecture without any specification of the performance characteristics of the physical resources that comprise each element
• Instantiated physical architecture: generic physical architecture to which complete definitions of the performance characteristics of the resources have been added
27
Physical View for a DistillerPhysical View for a Distiller
28 Copyright 2007 -- Stevens Institute of
Technology
Expensive fireworks…Expensive fireworks…
29
Derive and Trace Derive and Trace Requirements Requirements
• Every high level requirement will have to be developed into lower level requirements.
• Are subsystem/component requirements consistent with system level requirements?
• Where do the Requirements come from, and where do they go?• Why are they the way they are?• What are the consequences of a proposed change?
Operational EffectivenessOperational Effectiveness
30 04/18/23 Copyright 2007 -- Stevens Institute of
Technology
Reliability/
Supportability/ Maintainability/
Design “Cause”
Operational “Effect”
Operation
Logistics Maintenance
Time toSupport (TTS)
Time toMaintain (TTM)
Time toFailure (TTF)
System DowntimeSystem Uptime
OperationalOperationalEffectivenessEffectiveness
Cost as an Independent Variable (CAIV)/TOC
PerformanceFunctions
Requirements
PrioritiesReliability
MaintainabilitySupportability Availability
Technical
Effectiveness
ProducibilitySystem
EffectivenessOperationMaintenance
LogisticsProcess
EfficiencyProduction
31
The charts here are based on data collected from a recent study analyzing project defects by type and phase. Here ISM defects by phase is compared to 46 similarly sized IBM projects
not utilizing SE.
Total defect counts for non-SE projects exhibited 53.4% of total project defects during
the Test Phase of the project. On ISM defects were detected earlier in the project life-cycle.
In fact 56% of ISM detects were detected in Plan Phase.
The chart on the left illustrates the cost implications of early defect
detection as found with ISM 2.0.
In effect ISM 2.0 expended 2.4 times less than what would have
normally been required for the non-SE oriented projects compared to in
the study.
It Works! It Works!