SE Process Overview
docsity.com
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
SE Process - Applying Systems Engineering - Lecture Slides, Slides of Systems Engineering
Summary Mission Analysis, Functional Analysis, Requirements Analysis, Baseline Management Alternatives, Analysis System Synthesis, System Integration, System Verification, Systems Engineering Planning are the major topics of this course. Key points in this lecture are: SE Process, Nasa, Pile of Components, Dimensions of a System, Systems Engineer, Measure of Effectiveness, Mission Analysis, Requirements Analysis, BaSEline Management, Functional Analysis
Typology: Slides
2012/2013
1 / 35
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download SE Process - Applying Systems Engineering - Lecture Slides and more Slides Systems Engineering in PDF only on Docsity!
SE Process Overview
Objectives
• Discuss a few Systems Engineering Concepts and
Definitions
• Discuss the Principles of System Engineering
• Discuss the DOE-tailored System Engineering Process
• Introduce the concept of a Graded Approach to System
Engineering
• Introduce the In-class Exercise
Why SE? …
Because Projects Fail
DOE INCOSE
Successful Projects 18% 16%
Partially Successful 30%** 31%
Failed Projects 52%** 51%
Total 100% 98%
Average Cost Overrun 43% 89%
Cost of Failed Projects $10B $81B
Cost of Overruns $7B $59B
DOE Source: 1996
GAO report on DOE
project performance
(GAO/RCED-97-17).
INCOSE Source:
Standish Group
1995, and Scientific
American 1994.
**** Partially Successful are DOE projects with <10% cost overrun.**
Failed projects are projects which DOE terminated prematurely.
Why Projects Fail
• The Standish Report attributes the failures to:
– 1. poor requirements,
– 2. poor risk management and
– 3. failures to relate software to the systems
• INCOSE lists the following reasons why projects fail:
– 1. Incomplete requirements 13.1%
– 2. Lack of user involvement 12.4%
– 3. Lack of resources 10.6%
– 4. Unrealistic expectations 9.9%
– 5. Lack of executive support 9.3%
– 6. Changing requirements/specs 8.7%
– 7. Lack of planning 8.1%
– 8. Didn't need it any longer 7.5%
Accounts for
80% of all project
failures!
What is a “System”?
• The American Heritage Dictionary defines
“System” as:
1. A group of interacting, interrelated, or interdependent elements
forming a complex whole. 2. A functionally related group of elements,
esp.: a. The human body regarded as a functional physiological unit. b. An
organism as a whole, esp. with regard to its vital processes or functions. c.
A group of physiologically or anatomically complementary organs or parts:
the nervous system. d. A group of interacting mechanical or electrical
components. e. A network of structures and channels, as for
communication, travel, or distribution. 3. An organized set of interrelated
ideas or principles. 4. A social, economic, or political organizational form.
5. A naturally occurring group of objects or phenomena: the solar system.
What Makes a System
“A System”
- The difference between a pile of components and a
physical, organizational, and/or philosophical “system”
is organization, and understanding of how the various
components are interrelated and arranged.
- A “system” is not merely the sum of its parts. If it does
not matter how those parts are arranged , we are
dealing with a pile and not a “system”.
- The behavior or efficiency of a “system” depends on its
entire, interrelated structure.
Carburetor (Sub)System
Engine (Sub)System
Automobile (Sub)System
Larger (Sub)Systems:
• Parking Lots
• Highways/Roadways
• Gas Stations
• Transport Trucks
• etc.
Smaller
(Sub)Systems
A System of Systems
• A single system can be a part, or subsystem, of a larger system, which in
turn can be a part of an even larger and more complex system, and so
on.
Systems Engineering (Process) VS. Systems Engineer
(Person)
Key SE Terminology
• System : A composite of subsystems, assemblies, skills, and
techniques capable of performing and/or supporting an
operational (or non-operational) role.
• Customer: The recipient or beneficiary of the outputs of the
process work efforts, or the purchaser of its products and
services. (see Martin, pg. 19)
• Requirement: (1) a characteristic that identifies the
accomplishment levels needed to achieve specific objectives
under a given set of conditions and (2) a binding statement
in a document or contract.
* see reprint of “Final Report” for complete description
Systems Engineering Principles*
from: INCOSE SE Practice Working Group, “An Identification of Pragmatic Principles – Final
Report,” Ed. J. C. DeFoe, INCOSE, January 21, 1993.
- Know the problem, the customer, and the consumer
- Use effectiveness criteria based on needs to make system
decisions
- Establish and manage requirements
- Identify and assess alternatives so as to converge on a
solution
- Verify and validate requirements and solution performance
- Maintain the integrity of the system
- Use an articulated and documented process
- Manage against a plan
docsity.com
One Iteration of the
SE Process
Mission Analysis /
Requirements Analysis
Customer
Needs
Statements
Rules, Orders,
Regulations,
Standards
Program /
Technical
Requirements
Alternatives Analysis /
System Synthesis
Analytical
Data
Models &
Simulation
s Parametric
Data
Ranked
Decision
Criteria
Trade
Studies
Physical System
Architecture
System Verification
Detailed Specifications
System Boundary SE Checklist
Customer Needs/Expectations
List
System Requirements List (with Customer Approval)
Top-level Functional Architecture Alternatives Designs (e.g., sketches, designs, etc.)
Decision Criteria (“System has to ...” list with
measurable units)
Concept Matrix (Decision
Criteria vs. Alternatives)
System Engineering Management Plan (SEMP)
Document Control Log Customer Requirements and
System Requirements Documents
System Performance Measures Initial Program and Technical Interface Requirements
Formalized Functional Hierarchy Detailed Alternative Concepts
Decision Criteria System Functional Architecture Technical, Cost Baselines
Trade Studies/Analysis Plans and Results
System Requirements Review
System Requirements Baseline
Preliminary Design Review
System Baselines Revisions
Conceptual Design Review
System Baselines
Revisions
Verification
Matrix
Design Reviews
Syuvemu Engineequ av vhe Idaho Navional Engineeqing and Enviqonmenval Labopeqfoqm vhe follosing qoleu in utppoqv of Lockheed Maqvin Idaho Technologieu Company and U.S. Depaqvmenv
of Eneqgy pqogqamu and pqojecvu:
auueuu upecific pqogqam and ctuvomeq needu and expecvavionu vhqotgh inveqacvion and facilivavion of gqotpu meevingu and diuctuuionu
implemenv an appqopqiave gqaded SE appqoach vo meeving pqogqam and ctuvomeq needu
idenvify and manage uyuvem qertiqemenvu incltding vhe tue of qertiqemenvu managemenv voolu
idenvify and develop uyuvem alveqnaviveu
analyze uyuvem alveqnaviveu vo enutqe pqogqam qertiqemenvu aqe mev incltding evaltaving
uyuvem qiuk couv and ovheq peqfoqmance meautqeu tuing comptveq uimtlavion modelu and ovheq vechnirteu
pqovide shav-if ucenaqio modeling foq uenuivivivy analyuiu of changeu in pqogqam
qertiqemenvu and/oq uyuvem vaqiableu
doctmenv and validave analyuiu qeutlvu
utppoqv vhe deciuion making pqoceuu
Test Plans
Syuvemu Engineequ av vhe Idaho Navional Engineeqing and Enviqonmenval Labopeqfoqm vhe
follosing qoleu in utppoqv of Lockheed Maqvin Idaho Technologieu Company and U.S. Depaqvmenv of Eneqgy pqogqamu and pqojecvu:
auueuu upecific pqogqam and ctuvomeq needu and expecvavionu vhqotgh inveqacvion and
facilivavion of gqotpu meevingu and diuctuuionu
implemenv an appqopqiave gqaded SE appqoach vo meeving pqogqam and ctuvomeq needu
idenvify and manage uyuvem qertiqemenvu incltding vhe tue of qertiqemenvu managemenv voolu
idenvify and develop uyuvem alveqnaviveu
analyze uyuvem alveqnaviveu vo enutqe pqogqam qertiqemenvu aqe mev incltding evaltaving uyuvem qiuk couv and ovheq peqfoqmance meautqeu tuing comptveq uimtlavion modelu and ovheq vechnirteu
pqovide shav-if ucenaqio modeling foq uenuivivivy analyuiu of changeu in pqogqam qertiqemenvu and/oq uyuvem vaqiableu
doctmenv and validave analyuiu qeutlvu
utppoqv vhe deciuion making pqoceuu
utppoqv pqodtcv developmenv and
implemenvavion do
System
Integration
Systems
Engineering
Planning
Functional Analysis
Functional Hierarchy
Functional System
Architecture
Tradeoff
Studies
Baseline
Management
Mission Analysis
Objectives:
• Determine problem /
opportunity
• Identify potential
customers and stakeholder
• Collect high-level
“desirements”
Alternatives Analysis /
System Synthesis
System Verification
System
Integration
Systems
Engineering
Planning
Functional Analysis
Tradeoff
Studies
Baseline
Management
Mission Analysis /
Requirements Analysis
Customer
Needs
Statements
Rules, Orders,
Regulations,
Standards
Customer
Requirements
Baseline Management
Objectives:
n Establish initial system baselines
n Control changes to baselines as
system definition matures
Mission Analysis /
Requirements Analysis
Alternatives Analysis /
System Synthesis
System Verification
System
Integration
Systems
Engineering
Planning
Functional Analysis
Tradeoff
Studies
Baseline
Management
and Change
Control
Baseline
Management
Functional Analysis
Mission Analysis /
Requirements Analysis
Alternatives Analysis /
System Synthesis
System Verification
System
Integration
Systems
Engineering
Planning
Tradeoff
Studies
Baseline
Management
Functional Analysis
Functional Hierarchy
Functional System
Architecture