Transcript Lecture 1 - Principles of System Engineering

Principles of Systems Engineering
Introduction & Overview
Jim Andary
NASA Goddard Space Flight Center
[email protected]
October 22, 2009
Morgan State University • Systems Engineering Lecture 1
Agenda
1.
2.
3.
4.
Definitions of system and systems engineer
The role of a systems engineer
Systems engineering vs. project management
Systems engineering functions and processes
–
–
–
–
–
–
–
–
–
Requirements Development and Management
Operations Concept
Decomposition
Technology Planning
System analysis and design
System Integration
Resource Management
Quality Control
Verification and Validation
Morgan State University • Systems Engineering Lecture 1
2
Definitions
What is a System?
“A System is a set of interrelated components
which interact with one another in an organized
fashion toward a common purpose”
NASA Systems Engineering Handbook SP6105
Morgan State University • Systems Engineering Lecture 1
3
Definitions (Continued)
What is Systems Engineering?
“Systems Engineering is an interdisciplinary approach
and means to enable the realization of successful
systems.”
INCOSE Handbook
Morgan State University • Systems Engineering Lecture 1
4
Definitions (Continued)
Another Definition
“Systems Engineering is a robust approach to the design,
creation, and operations of systems.”
NASA Systems Engineering Handbook SP-6105
Morgan State University • Systems Engineering Lecture 1
5
Definitions (Continued)
In simple terms, the systems engineering approach consists of:
–
–
–
–
–
–
Identification and quantification of system goals,
Creation of alternative system design concepts,
Performance of design trades,
Selection and implementation of the best design,
Verification that the design is properly built and integrated, and
Post implementation assessment of how well the system meets
(or met) the goals
Morgan State University • Systems Engineering Lecture 1
6
Definitions (Continued)
“Engineering of Systems”
Anyone involved in engineering a system should
exercise good systems engineering practices.
Morgan State University • Systems Engineering Lecture 1
7
Twelve Systems Engineering Roles
1.
Requirements Owner
7.
Customer Interface
2.
System Designer
8.
Technical Manager
3.
System Analyst
9.
Information Manager
4.
Validation and
Verification Engineer
10. Process Engineer
5.
Logistics & Operations
Engineer
11. Coordinator of the
Disciplines
6.
Owner of the “Glue”
among subsystems
12. “Classified Ads”
Systems Engineer
from Sarah A.Sheard (INCOSE proceedings of 1996)
Morgan State University • Systems Engineering Lecture 1
8
Systems Engineering vs. Project Management
Project Management
Systems Engineering
• System Design • Technical
• Requirement Management
Definition
• Technical
Planning
• Technical
Solution
• Technical
Definition
Control
• Product
• Technical
Realization
Assessment
• Design
• Technical
Realization
Decision
Analysis
• Evaluation
• Transition
• Planning
• Risk
Management
• Configuration
management
• Data
Management
• Assessment
• Decision
Analysis
Project Control
• Management
Planning
• Integrated
Assessment
• Schedule
Management
• Configuration
management
• Resource
Management
• Documentation and
Data Management
• Acquisition
management
Morgan State University • Systems Engineering Lecture 1
9
Key Systems Engineering Functions
Project
Objectives
and
Constraints
Tools help engineers
evaluate their systems
more quickly and more
efficiently, but they do not
replace the “Art” and
“Creativity” necessary to
conceive them
Requirements
Development
and
Management
Verification and
Validation
Architecture
and Design
Verification
and
Validation
Verification
and
Validation
Operations
Concept
Systems Engineering
Management Plan
Project Objectives
Met,
Ready for
Operations
“The objective of systems engineering is to see to it that the system is designed, built, and
operated so that it accomplishes its purpose in the most cost-effective way possible, considering
performance, cost, schedule and risk.”
NASA Systems Engineering Handbook SP6105
Morgan State University • Systems Engineering Lecture 1
10
Systems Engineering Process “V”
Understand User
Requirements, Develop
System Concept and
Validation Plan
Demonstrate and
Validate System to
User Validation Plan
Develop System
Performance Specification
and System
Verification Plan
Integrate System and
Perform System
Verification to
Performance Specification
Expand Performance
Specifications Into CI
“Design-to” Specifications
and Inspection Plan
Evolve “Design-to”
Specifications into
“Build-to” Documentation
and Inspection Plan
Assemble CIs and Perform
CI Verification to CI
“Design-to”
Specifications
Inspect to
“Build-to”
Documentation
Fabricate, Assemble, and
Code to “Build-to”
Documentation
CI = Configuration Item
Morgan State University • Systems Engineering Lecture 1
11
Systems Engineering Process “V” (Continued)
•Developed by Kevin Forsberg and Harold Mooz*
•Starts with user needs on the upper left and ends with a uservalidated system on the upper right
•Adds concurrent risk management
– User involvement
– User approval and in-process validation
•Adds verification problem resolution
Promotes a risk-responsive, phased system
development process
*Kevin Forsberg and Harold Mooz, "The Relationship of System Engineering to the Project Cycle," Proceedings of the First Annual
Symposium of National Council on System Engineering (NCOSE), Chattanooga, Tennessee, Oct. 1991, pp 57 - 65.
Morgan State University • Systems Engineering Lecture 1
12
Requirements Development
•Collect top-level requirements from customers and stakeholders
•Develop an operations concept
•Derive lower-level requirements to support top-level requirements
and the operations concept
– Writing requirements without a fully understood, agreed upon
and documented operations concept will result in poor and
misunderstood requirements, cost overruns and schedule slips.
Morgan State University • Systems Engineering Lecture 1
13
Requirements Development (Continued)
Writing Good Requirements
• “Functional Requirements” - What needs to be done
– Functional Requirements are generally not Verified
because Performance Requirements specify how good
the function needs to be
– Functional Requirements define a logical breakdown
• “Performance Requirements” - How well it needs to be
done
– Performance Requirements are Verifiable
• Requirements Decomposition and Parent-Child
Relationship
– Requirements flow from higher to lower levels
– Requirements at lower levels (“children”) must trace
from a higher level requirement (“parent”)
– Eliminate any “orphan requirements” (requirements
without parents)
• Add rationale or comments to the requirements to help
trace “why” that requirement was created
Morgan State University • Systems Engineering Lecture 1
14
Requirements Development (Continued)
•Decompose the requirements in a hierarchical, parent-child
relationship
– Requirements flow from higher to lower levels
– Requirements at lower levels (“children”) must trace from a
higher level requirement (“parent”)
– Eliminate any “orphan requirements” (requirements without
parents)
•Add rationale or comments to the requirements to help trace why
that requirement was created
Morgan State University • Systems Engineering Lecture 1
15
Requirements Development (Continued)
• Writing the right requirements
– What is necessary to Achieve Full Mission Success Criteria?
– Levels of requirements (Level 1, Level 2, etc.)
• Level 1 Generally Highest Level Agreement with Ultimate Customer
• Lower Levels up to each Project to choose
– Traceability (Parent, child, orphan, widow, etc.)
– Priorities
– Organizing the requirements
(templates and guidelines)
• Reviewing Requirements
– Gate keepers
– Formal reviews (SRR, PDR, CDR)
– Verification Plan must addresses
how each requirement will be verified
Morgan State University • Systems Engineering Lecture 1
16
Requirements Development (Continued)
• Use the word “shall” when defining requirements and only for
requirements:
– “The attitude control system shall point the instrument boresight to
within 6 arc seconds of the commanded attitude.”
– Make it clear to the reader exactly what must be done.
• Requirements should be:
– Measurable
• Avoid vague statements like “shall point as accurately as possible”
– Verifiable
• If no one can demonstrate that a system does or does not meet a
requirement, then there is no requirement: shall not exceed 55 kg, but
we aren’t going to weigh it
• Document rationale!
– Capture the “why” while it is fresh.
– Enable future changes—people are afraid to change things they don’t
understand.
Morgan State University • Systems Engineering Lecture 1
17
Requirements Development (Continued)
The Customer’s Swing
The customer
requested a new kind
of swing that allowed
the customer more
What the Proposal Promised
than one way of
swinging.
Preliminary Design
As Built by Manufacturing Following Inspection and Rework
Design Change
Specification
After Rework
Design Drawings
What the Customer
Wanted
What Happened to
The Engineering
Team
Morgan State University • Systems Engineering Lecture 1
Communication
and
Understanding is
Key!
18
Requirements Management
•Collect top-level requirements from customers and
stakeholders
•Develop operations concept
•Derive lower-level requirements to support top-level
requirements and the operations concept
•Choose an appropriate tool to store and manage the
requirements
– This can range from an Excel spreadsheet for simple
projects to sophisticated tools such as DOORS, Team
Center, CORE, etc. for more complex projects
•Baseline the requirements at a System Requirements Review
(SRR)
– “Baseline” means requirements are signed off and put
under configuration control
•Control any future changes to requirements through a
configuration management process
Morgan State University • Systems Engineering Lecture 1
19
Requirements Management (Continued)
ID
DESCRIPTION
M1 Mission Orbit
REQUIREMENT
575 +/-15 km Sun-synchronous dawn-dusk orbit
M2 Launch Vehicle
M3 Observatory Mass
TRACED
FROM
S3, S11, P3
PERFORMANCE
MARGIN
Comments
REF
Complies
NA
Pegasus XL with HAPS provides
required launch injection
dispersion accuracy
F.2.c
Pegasus XL with HAPS
The NEXUS Observatory total mass shall not exceed 241
kg.
M4 Data Acquisition Quality The NEXUS mission shall deliver 95% data with better
than 1 in 100,000 BER.
P2, P4
M1, M2
Complies
192.5 kg
NA
25.20%
P1
Complies
NA
Standard margins and systems
baselined, formal system analysis
to be completed by PDR
M5 Communication Band
S12, P4
Complies
NA
See SC27, SC28 and G1, G2
P4
Complies
NA
P12
P1, S12
Complies
Complies
NA
12%
P1
Complies
NA
P3
1/51,000
400%
P3
< 10 years
15 years
The mission shall use S-band SQPSK at 5 Mbps for
spacecraft downlink and 2 kbps uplink.
M7 Tracking
MOC shall use NORAD two line elements for observatory
tracking
M8 Data Latency
Data Latency shall be less than 72 hours
M9 Daily Data Volume
Accommodate average daily raw science data volume of
10.8 Gbits
M10 Ground Station
The Mission Shall be Compatible With the Rutherford
Appleton Laboratory Ground Station and the Poker Flat
Ground Station
M11 Orbital Debris (Casualty Design NEXUS observatory for demise upon reentry with
Area)
< 1/10,000 probability of injury
M12 Orbital Debris (Lifetime) Design NEXUS observatory for re-entry <25 years after
end of mission
Table 13
Morgan State University • Systems Engineering Lecture 1
F.2.c
F.5.b
F.7
F.3.f,
F.7
F.7
Marign based on funded ground
contacts
F.7
F.3.e,
F.7
F.7
See Orbital Debris Analysis in
Appendix M-6
See Orbital Debris Analysis in
Appendix M-6
F.2.e,
App.6
F.2.e,
App.6
20
Operations Concept
•An Operations Concept is a vision (in general terms) for what the
system is, and a description of how the system will be used.
•An Operations Concept consists of a set of scenarios describing how
the system will be used during all of its operational phases.
•The scenarios are often accompanied by illustrations of the system
operations.
•An Operations Concept:
– Serves as a validation reference for the design throughout the life
cycle
– Describes how the design can accomplish the mission described
by the objectives
– Key to defining all the requirements
– Evolves into the flight operations plan later in the life cycle
Morgan State University • Systems Engineering Lecture 1
21
Operations Concept (Continued)
•Stakeholders participate in the development of the Operations
Concept
•Trade studies and analyses are used to demonstrate that the
operations concept will meet the mission requirements within cost
and schedule constraints
Morgan State University • Systems Engineering Lecture 1
22
Operations Concept (Continued)
• Considerations for developing an Operations Concept for a Space
Mission:
–
–
–
–
–
–
–
–
–
Allocation of functions between ground segment and flight segment
Mission operational modes and configurations
Time ordered sequence of mission activities
Identification of facilities, equipment and procedures needed to ensure
the safe development and operation of the system
Operations team size, staffing and extent of automation
Ground segment functions
Contingency concepts
Ground test configurations necessary to accomplish verification
including GSE, BTE, simulators and non-flight articles such as ETU’s
Description of functions that cut across various subsystems
• Observation strategy
• Date collection, storage and downlink
• Ground station utilization
• Mission orbit maintenance and maneuvers
• Power and battery management
Morgan State University • Systems Engineering Lecture 1
23
Operations Concept (Continued)
MILITÄRISCHER
NUTZER
Military Planners
Request
Auftrag
for
Data
NUTZERSatellite Operators
BODENSEGMENT
SATELLITENControl Center
BODENSEGMENT
Dossier
Data
Inter -Satellite Link
Data Download
Command Transmission
Image Recording
Morgan State University • Systems Engineering Lecture 1
24
Decomposition
Many types of decomposition
•Requirements Decomposition
•Functional Decomposition
– Functional Architecture
•Physical Decomposition
– Physical Architecture
•Operational Architecture
– Allocates functions to physical subsystems
– Provides complete description of the system design
– Integrates the requirements decomposition with the
functional and physical architectures
Morgan State University • Systems Engineering Lecture 1
25
Decomposition (Continued)
System Requirement
non-exhaustive
inclusive
Effectiveness
Measure
Functional
Requirement
based on content and allocation
Performance
Requirement
Imposed Design
Requirement
User Defined
Physical
Property
Requirement
Interface
Requirement
Reference
Requirement
Morgan State University • Systems Engineering Lecture 1
26
Technology Planning
•Projects are sometimes initiated with known technology shortfalls
– Technology “Pull”
•Often there are areas for which new technology will result in
substantial product improvement
– Technology “Push”
•Technology development can be done in parallel with the project
evolution and inserted as late as the PDR
•Risk mitigation requires a parallel approach that is not dependent
on the development of new technology
•The technology development activity should be managed as a
critical activity
Morgan State University • Systems Engineering Lecture 1
27
Technology Readiness Levels
Morgan State University • Systems Engineering Lecture 1
28
Systems Analysis and Design
Modeling
•Models are the language of the designer.
•Models are representations of the system-to-bebuilt or as-built.
•Models are a vehicle for communications with
various stakeholders.
•Models allow reasoning about characteristics of
the real system.
•Models can be used for verification by analysis.
•All models must themselves be verified.
Morgan State University • Systems Engineering Lecture 1
29
Systems Analysis and Design (Continued)
•There are two basic approaches that are commonly
used for system design and integration
– Structured Analysis
– Object-oriented Analysis and Design
•It can be shown that either approach can be
translated into the other.
Morgan State University • Systems Engineering Lecture 1
30
Structured Analysis
•Structured Analysis
– Process Modeling, also known as Data Flow Modeling or
Functional Decomposition
•IDEF0*
•SADT (Structured Analysis & Design Technique)
– Data Modeling
•IDEF1x
•Entity-Relationship Diagrams
– Behavior Modeling
•Rules
•State Transition Diagrams
*The IDEF process was developed by the Air Force in the early 1970’s as part of the ICAM program
(Integrated Computer Aided Modeling). IDEF originally stood for “ICAM Definition” but NIST
later changed it to “Integration Definition”.
Morgan State University • Systems Engineering Lecture 1
31
Structured Analysis (Continued)
IDEF0
Student
Registration
System
Morgan State University • Systems Engineering Lecture 1
32
Structured Analysis (Continued)
“ICOM”
Control
Input
Function
Output
Mechanism
Morgan State University • Systems Engineering Lecture 1
33
Structured Analysis (Continued)
Behavior Modeling: State Transition Diagram
User ID and Password entered
(User_ID, Password)/ accept
Ready
start
Do: display login page
Do: wait for login
Verifying
Do: verify user
[Invalid user]/Display:”Access Denied”
[Valid user]
Validating Options
Retrieving
Request for course search
Do: display user options
Do: check option vs access permission
Do: display course search page
Do: retrieve course selections
Request to register
(course_nr, user_ID)
Request to register
(course_nr, user_ID)
[Option selected
not allowed]/
Display error message:
“Option not allowed”
[Registration rejected]
Registering
See superstate diagram
[No Conflicts] (course_nr)
Request to generate report (User type)
Validating Report
Do: display report page
Do: validate user vs report selected
Report printed
[Report not allowed]/
Display error message
“Option not allowed”
(Report type) [Report allowed]
Drop request (course_nr)
Updating Schedule
Generating Report
Do: update student schedule
Updating complete/
University-updated
class roster
Do: send database request (report parameters)
Do: format report
Do: print (report)
Morgan State University • Systems Engineering Lecture 1
34
Structured Analysis (Continued)
IDEF1x
DATA MODEL
Morgan State University • Systems Engineering Lecture 1
35
Object-Oriented Analysis and Design
•Object-Oriented Analysis and Design
– The concept of “object” or “object class” is the result of a long
history of software engineering design.
•From a programming viewpoint, an object is a collection of
specialized data packaged with the functions (operations
and methods) which are needed specifically by that
specialized data.
•From a systems design viewpoint, an object is a system or
component which maintains its own information and is
able to perform some specific functions.
– Developed more recently for software engineering, objectoriented design is now migrating to systems engineering.
– Object-oriented design defines the relationships between
object classes and the behavior of the classes.
Morgan State University • Systems Engineering Lecture 1
36
Unified Modeling Language (UML)
•UML is a language for visualizing, specifying, constructing
and documenting the artifacts of software-intensive systems,
as well as for business modeling and other non-software
systems.
•UML supports the entire development lifecycle.
•UML is supported by many tools (e.g., IBM Rational ROSE,
Visio, etc.).
•SysML is the extension of UML to systems engineering.
Morgan State University • Systems Engineering Lecture 1
37
(3)
Domain
of Interest
contained in
contained in
(2)
Category
reference for
built from C
categorizes
(5)
(7)
(63)
System
View
Functional
Breakdown
(64)
(6)
Stakeholder
has view
Environment
Element
System
Breakdown
exhibits
part of
C
(1)
(65)
Physical
Breakdown
has
(8)
Stakeholder
Need
Interacts with
(62)
Realization
View
(61)
Design View
(4)
System
satisfied by
(11)
(9)
System
Requirement
represented by
allocated to
C
Reference
Document
Property
reference for
statement of
(10)
derived from
verifies
(12)
Structure
Behavior
Verification
(13)
Physical
Property
(14)
C
allocated to
Morgan State University • Systems Engineering Lecture 1
C
budgeted to
38
Unified Modeling Language (UML)
(3)
Domain
of Interest
Box means Class or Meta Class (top is name) or type
2nd box means attributes
3rd box means Methods or member functions
Diamond means aggregation/decomposition
Line means relationship (words on line describe relationship)
(1)
C
(XX) Means look at Concept semantic dictionary
Diamond with a C in the middle means a Complete
decomposition
Loop line with Diamond means hierarchal decomposition of
items of the same type
(4)
(22.10)
Arrow/triangle means specialization/generalization
Depending on direction
A number on each end of a line means multiplicity
1
1
From MDSD Workshop 5 Feb 2003
Morgan State University • Systems Engineering Lecture 1
39
UML vs. SysML
Morgan State University • Systems Engineering Lecture 1
40
“Concurrent Design”
Integrated Mission Design Center (IMDC)
at Goddard Space Flight Center
Morgan State University • Systems Engineering Lecture 1
41
“Concurrent Design”
Collaborative, Rapid Design Improves Quality of Conceptual Designs
Preliminary design in one week vs. six months
Morgan State University • Systems Engineering Lecture 1
42
Small Explorers (SMEX) Built at GSFC
Submillimeter Astronomy
Satellite (SWAS)
Transition Region And
Coronal Explorer (TRACE)
Wide-Field Infrared
Explorer (WIRE)
Solar
Anomalous
and
Magnetospheric
Particle
Explorer
(SAMPEX)
Fast
Auroral
Snapshot
Explorer
(FAST)
Morgan State University • Systems Engineering Lecture 1
43
System Integration
•Integration is the process of assembling the
system from components.
•Integration begins with the elementary pieces or
configuration items (CI’s) of the system.
•After each CI is tested, components comprising
multiple CI’s are tested.
•This process continues until the entire system is
assembled and tested.
•Interface Specifications and Interface Control are
critical to a successful system integration.
Morgan State University • Systems Engineering Lecture 1
44
Work and Resource Management
•A Work Breakdown Structure (WBS) is a hierarchical breakdown of
the work necessary to complete a project.
•The WBS should be a product-based, hierarchical division of
deliverable items and associated services.
•The WBS should contain the Product Breakdown Structure (PBS).
•At the lowest level are products such as hardware items, software
items, and information items (documents, databases, etc.) for which
there is a cognizant engineer or manager.
•A project WBS should be carried down to the cost account level
appropriate to the risks to be managed.
Morgan State University • Systems Engineering Lecture 1
45
Work Breakdown Structure (WBS)
Morgan State University • Systems Engineering Lecture 1
46
Product Breakdown Structure (PBS)
Morgan State University • Systems Engineering Lecture 1
47
Technical Resource Management
•Critical mission resources shall be identified, allocated and
managed
•Acceptable resource margins shall be established
•A margin management philosophy shall be set up based on design
maturity and time
– Required margins are reduced as the project matures
– Margins are assessed based on the fidelity of the estimate
•Care must be taken that margins are not added to margins
– Stacked margins that do occur simultaneously in real life
– Lead systems engineer holds the overall system margins
– Subsystem engineers must be allowed to hold some margin in
order to meet their design requirements
– This hierarchy of margins must be taken into account so that the
overall system margins do not drive the design and the cost
Morgan State University • Systems Engineering Lecture 1
48
Example: Technical Resource Margins
Total Margin Progression
SCR
PDR
CDR
Flight
Mass
35-25% 20-30% 15-20%
0
Power (solar array,battery,
load)
25-35% 15-25% 15-20%
0 at
EOL
Fuel
3 Sigma + Uncertainty
3 Sigma
Memory
50%
30%
25%
5%
CPU
50%
30%
25%
20%
Telemetry an
d Commands
20%
15%
10%
0
RF Link
3dB
3dB
3dB
3dB
Margin Factors
Estimate
Calculated
Measured
Mass
20%
15%
3%
Power (solar array,battery,
load)
20%
15%
3%
Fuel
10%
5%
3%
Memory
30%
15%
3%
CPU
50%
30%
25%
Telemetry an
d Commands
20%
15%
10%
RF Link
2dB
1dB
.5dB
Capability
835
11.3% Contingency
Allocation
750
Total Margin
22.8%
10.3% Margin
680
Estimate
% Margin =
3300
Tracking Estimates (Mass)
3100
2900
Total Capability
2700
Max Allocation
Estimate
2500
Jul-02
Feb-03 Aug-03 Mar-04 Oct-04
Apr-05 Nov-05 May-06 Dec-06
Jun-07
Jan-08
• Allocations defined at SRR for
appropriate total margin
• Estimates tracked monthly
• Changes to allocation via CCR
• Estimates over total allocation
trigger risk reduction activities
Capability
-1
Estimate
Morgan State University • Systems Engineering Lecture 1
49
Specialty Engineering
• Specialty engineers support the systems engineering process by applying
specific knowledge and analytic methods from a variety of engineering
specialty disciplines to ensure that the resulting system is actually able to
perform its mission in its operational environment.
• For space systems these specialty areas often include:
– Quality Assurance
– Reliability
– Maintainability
– Producibility
– Logistics
– Safety
– Environment (e.g., radiation, atomic oxygen, atmospheric density, etc.)
– Contamination
– Parts Engineering
Morgan State University • Systems Engineering Lecture 1
50
Quality Assurance
Performance
Providing confidence that the system
actually produced and delivered is in
accordance with its functional,
performance, and design requirements.
Quality
Cost
Time
Engineering
Efficiency
=
Reliability * Performance
Cost * Time
Morgan State University • Systems Engineering Lecture 1
51
Reliability
The “Bathtub Curve”
Failures
For many systems, the failure rate function looks like the classic
"bathtub curve" illustrated in the graph below.
Random
Failures
Burn-in Period
Useful Life Period
Wear-out Period
Time
Morgan State University • Systems Engineering Lecture 1
52
Maintainability
Maintainability is that system design characteristic
associated with the ease and rapidity with which the
system can be retained in operational status, or safely and
economically restored to operational status following a
failure.
Morgan State University • Systems Engineering Lecture 1
53
Verification
•Verification: “Did I build the System Right?”
•Each requirement must be verified
•Verification Methods: Test, Analysis, Inspection and Demonstration
•Rule #1: “Test wherever possible”
– Perform Analysis and Inspection, where Test is not possible
– Pay careful attention to validity of simulators and models
•Rule #2: “Test the way you fly, fly the way you test”
– Identify what is not tested in flight configuration
•Careful review to assure items are properly verified by a
combination of Analysis, Inspection or Test.
•Review of the assumptions and interfaces of element verified
in pieces
•Attention to validity of simulators and simulations
– Careful review to assure these items are properly verified by a
combination of Analysis, Inspection or Test.
Morgan State University • Systems Engineering Lecture 1
54
Verification (Continued)
•Rule #3: “Test the system end-to-end”
– Carefully review the assumptions and interfaces of any
elements verified in pieces
•Rule #4: “Verify Off-Nominal Conditions”
– Verify Redundancy and Graceful Degradation Modes along
with On Board Fault Protection and Ground Contingency
Procedures
– Stress Testing and Negative Testing to find Latent Flaws
Morgan State University • Systems Engineering Lecture 1
55
Validation
•Validation: “Did I design or build the Right System?”
•Validation shows that the Design when used according to the
Operations Concept meets the Requirements and the Customers
Goals and Objectives and can be produced within the Cost,
Schedule and Risk constraints
•Validation Methods: Analysis, Predictions, Trade Studies, Test
•The requirements flow is also validated to show that “Parent”
requirements have valid “Child” requirements and that “Orphan”
requirements are not driving the system design or implementation.
•Initial Validation during Phase A and B is critical to proceeding into
Phase C where detail design occurs
– Otherwise the detail design proceeds on the “Wrong” system
•Validation also occurs in parallel with verification where End to
End Tests, Mission Simulations show that the “Right System” has
been built
Morgan State University • Systems Engineering Lecture 1
56
Summary
•Systems Engineering addresses the total program lifecycle
•Largely a communications activity
•Consistent Requirements, Design, and Operations Concept
•Time Phased “Crawl Before You Walk, Walk Before You Run”
•No Cookbooks or Magic Recipes
•Multilayered Review, Inspection and Test Process
•It is the Project Team, the People, that makes projects successful
Systems Engineering Techniques
Balance Performance, Cost, and
Schedule
Morgan State University • Systems Engineering Lecture 1
57
Some Key References
•Andrew P. Sage and William B. Rouse, Handbook of Systems
Engineering and Management, 2nd edition, John Wiley, 2009
•ISO/IEC 15288, Systems engineering — System life cycle processes,
2002
•Dennis M. Buede, The Engineering Design of Systems: Models and
Methods, Wiley, 2000
•ANSI/EIA-632-1998, Processes for Engineering a System, Electronic
Industries Alliance, 1999
•IEEE 1220, Management of the Systems Engineering Process
•INCOSE-TP-2003-002-03.1, INCOSE Systems Engineering Handbook
v3.1, 2007
•SP-2007-6105, NASA Systems Engineering Handbook
Morgan State University • Systems Engineering Lecture 1
58
Homework Assignment
1. In a brief paragraph describe a system of your choosing
2. In another paragraph describe its operation (operations
concept)
3. Draw a high-level product breakdown structure (PBS)
for that system
Morgan State University • Systems Engineering Lecture 1
59