Professional Documents
Culture Documents
Improvement Opportunities for Systems Engineering Practice in Brasil and in the World 1
CPPI-005210-1 copyright and all Other Rights Reserved Project Performance (Australia) Pty Ltd 1998-2011
Improvement Opportunities for Systems Engineering Practice in Brasil and in the World 2
A SYSTEM IS?
A regularly interacting or interdependent group of items forming a unified
whole
Source: The Merriam-Webster Unabridged Dictionary
Key concepts:
Interaction
Elements
Interrelationships
Whole
P1135-004875-1
Page 3 of 123
Key concepts:
Organization
Interaction
Elements
Purpose
P1135-004875-1
Page 4 of 123
A SYSTEMS APPROACH
P1135-004875-1
Page 5 of 123
The outward looking view, seeing our system as a part of one or more bigger
systems
The object view, seeing our system as an object with a required and desired
set of characteristics
The inward looking view, seeing our system as a set of interacting elements
P1135-004875-1
Page 6 of 123
Engineering
Collaboration
Effectiveness
Stakeholder satisfaction
P1135-004875-1
Interdisciplinary working
Life-cycle balance
Optimization
Stakeholder value
Page 7 of 123
P1135-004875-1
Page 8 of 123
KEY QUESTIONS!
P1135-004875-1
Page 9 of 123
INDICATORS OF EFFECTIVE SE
PRODUCT-ORIENTED ENTERPRISE:
Market leadership
P1135-004875-1
Page 10 of 123
INDICATORS OF EFFECTIVE SE
CONTRACT-ORIENTED ENTERPRISE:
P1135-004875-1
Page 11 of 123
INDICATORS OF EFFECTIVE SE
INTERNAL PROJECTS:
No desire to outsource
P1135-004875-1
Page 12 of 123
Harnessing of creativity
A learning environment
A shared vision of the product and related focus on quality, cost, time
P1135-004875-1
Page 13 of 123
Milestones missed
P1135-004875-1
Page 14 of 123
No measurement, no IV&V
P1135-004875-1
Page 15 of 123
Do:
Why?
P1135-004875-1
Page 16 of 123
P1135-004875-1
Page 17 of 123
System Requirements
Needs, wants, desires, expectations,
intent information
Knowledge of feasible solution
technologies
Value and Risk information
Background information
SYSTEM
REQUIREMENTS
ANALYSIS
capture and validate
requirements, MOEs,
goals and value
relationships
P1135-004875-1
Page 18 of 123
P1135-004875-1
Page 19 of 123
P1135-004875-1
Page 20 of 123
Requirements
come from these
contexts
P1135-004875-1
Page 21 of 123
P1135-004875-1
Page 22 of 123
P1135-004875-1
Page 23 of 123
P1135-004875-1
Page 24 of 123
Do:
Why?
P1135-004875-1
Page 25 of 123
Do:
Apply design skills and technology knowledge in creating
requirements
Why?
Every requirement is a part of a solution to a bigger problem, and in
a contract context, two bigger problems
P1135-004875-1
Page 26 of 123
Dont:
Why?
Partitioning system requirements that cannot be implemented by a
single system element leads to major problems in system integration,
leading, in turn, to cost and schedule blowouts
P1135-004875-1
Page 27 of 123
Do:
Why?
Process alone is valueless without the knowledge and creativity. Sound
processes, selected to match the job at hand, assist in transforming
good ideas into good solutions, great ideas into great solutions
P1135-004875-1
Page 28 of 123
DESIGN
PHYSICAL
SOLUTION
develop
physical
solution descriptions DD
Physical
Concept
DESIGN
FUNCTIONAL
SOLUTION
Legend: AD - Architectual Design
DD - Detail Design
EE&D - Effectiveness Evaluation &
Decision
AD
Other logical prototypes and models
develop
functional
solution descriptions DD
P1135-004875-1
Page 29 of 123
CREATING SOLUTION
Ref
(Innovation)
Identify
Key
Solution
Drivers
Ref
(Innovation)
Detail
Architectural
Solution
Solution
Peer/Peer+ Peer/Peer+
Independent Independent
Review
Review
Apply a systems approach, always with reference to an object and a physical level
of solution
Copyright Project Performance (Australia) Pty Ltd 2011
P1135-004875-1
Page 30 of 123
WATERFALL BASICS
P1135-004875-1
Page 31 of 123
Do:
Use sequential development (waterfall, grand design, big bang, etc) for
development, where requirements (etc.) are able to be well defined and
stable, and solutions are relatively simple or well understood, i.e. the risk
due to technology & complexity are low
Why?
Sequential development is the lowest cost, shortest timeframe
approach to development in these circumstances
P1135-004875-1
Page 32 of 123
P1135-004875-1
Page 33 of 123
Do:
defined and stable, but solutions have risk due to technology and/or due
to complexity
Why?
Incremental development reduces the amount at stake in any build,
and allows developers to apply what they have learned to subsequent
builds
P1135-004875-1
Page 34 of 123
P1135-004875-1
Page 35 of 123
EVOLUTIONARY DEVELOPMENT
P1135-004875-1
Page 36 of 123
Do:
P1135-004875-1
Page 37 of 123
Do:
Why?
P1135-004875-1
Page 38 of 123
P1135-004875-1
Page 39 of 123
Do:
Why?
Doing everything all of the time is a recipe for overkill. Doing nothing all
the time is a recipe for disaster
P1135-004875-1
Page 40 of 123
IMPLEMENT REQUIREMENTS
TRACEABILITY IN DESIGN
SYSTEM
SUBSYSTEMS
SUBSYSTEMS
SUBSYSTEMS
SUBSYSTEMS
P1135-004875-1
Page 41 of 123
Verification
(Test)
Requirements
Test
Cases
Verification
(Test)
Procedure/
Description
Test
Test
Result
Test
Report
Test
Specification
Test
Article
Test
Articles
Master
Test
Plan
Test
Plan
P1135-004875-1
Page 42 of 123
P1135-004875-1
Page 43 of 123
Do:
Why?
P1135-004875-1
Page 44 of 123
Do:
P1135-004875-1
Page 45 of 123
Do:
Identify and develop solution alternatives that are both feasible (i.e. can
meet requirements) and are potentially the most effective
Note: MOEs could include development cost, unit cost of production, timeto-market and other measures unrelated to capability of the product when
used
Why?
Going directly to a point solution may deny the enterprise a much better
solution. It the expected benefit exceeds expected cost of extra work,
we should do the extra work
P1135-004875-1
Page 46 of 123
Do:
P1135-004875-1
Page 47 of 123
CONCURRENT/SIMULTANEOUS ENGINEERING
Concurrent
Collaborative
Balanced
development
of
System
of
Interest
Enablin
g
1System
or more
e.g.
System
Engineering
Production System
Maintenance
System
Disposal System
Copyright Project Performance (Australia) Pty Ltd 2011
P1135-004875-1
Page 48 of 123
P1135-004875-1
Page 49 of 123
1998
ID
Task Name
Project Initiation
Development Planning
Product Design
Production Design
User Documentation
Design of Support
10
11
12
1999
Aug
Sep
Oct
Nov
Dec
Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
Jan
Feb
Mar
13
14
15
16
17
18
19
20
P1135-004875-1
Page 50 of 123
Task Name
Project Initiation
Development Planning
Product Design
Production Design
User Documentation
Design of Support
10
11
12
1999
Aug
Sep
Oct
Nov
Dec
Jan
Feb
Mar
Apr
May
Jun
Jul
2000
Aug
Sep
Oct
Nov
Dec
Jan
Feb
Mar
13
14
15
16
17
18
19
20
P1135-004875-1
Page 51 of 123
Do:
Except for simple problems, develop logical solution descriptions
(description of how the system is to meet its requirements) as a means of
developing physical solution descriptions (description of how to build the
system)
Why?
For simple problems, the cost of formalizing the logic will exceed the
benefit. For other problems, the avoided cost of rework due to design
errors will more than justify the cost in time and money of the extra
work
P1135-004875-1
Page 52 of 123
a, b, c
Y = a(b+c)
SOLUTION
a, b, c
is to be performed by ..
Add b and c
a, (b+c)
Multiply
(b+c) by a
a, (b+c)
Processor 1
Y
is to be performed by ..
Processor 2
P1135-004875-1
a, b, c
Page 53 of 123
P1135-004875-1
Page 54 of 123
P1135-004875-1
Page 55 of 123
P1135-004875-1
Page 56 of 123
Do:
Why?
This strategy will produce the best average outcome from our
engineering
P1135-004875-1
Page 57 of 123
Do:
Why?
P1135-004875-1
Page 58 of 123
P1135-004875-1
Page 59 of 123
Relevant non-requirements
information
DESCRIPTION
OF
SYSTEM
ELEMENTS
write specifications etc.,
P1135-004875-1
Page 60 of 123
SYSTEM INTEGRATION
Built system/sub-system
Build Instructions
SYSTEM INTEGRA
TION
System Integration Plan
System Elements
build the
system/ system
element
P1135-004875-1
Page 61 of 123
Do:
Subject to level of risk, independently verify work products (is the job
being done right, i.e., does the work product meet the requirements for
the work product?)
Why?
P1135-004875-1
Page 62 of 123
VERIFICATION
Work Product
Verification Procedure
Pass/fail criteria
VERIFICATION
does the work product
meet its
requirements?
is the work product
sub-optimum with
respect to MOEs,
etc..?
P1135-004875-1
Pass/FailAssessment
Page 63 of 123
P1135-004875-1
Page 64 of 123
Dont:
Why?
P1135-004875-1
Page 65 of 123
Do:
Subject to level of risk, independently validate work products (is the right
job being done, i.e. does the work product meet the need for the work
product?)
Why?
P1135-004875-1
Page 66 of 123
VALIDATION
Work Product
Needs Information
Validation Procedure
VALIDATION
does the work product
meet the need?
is the work product
sub-optimum in the
extent of doing so?
P1135-004875-1
Pass/Fail Assessment
Page 67 of 123
P1135-004875-1
Page 68 of 123
Do:
Why?
P1135-004875-1
Page 69 of 123
ENGINEERING MANAGEMENT
Engineering Tasking
Knowledge of Management
Principles and Process
Knowledge of Engineering
Principles and Process
Concurrent Engineering Issues
Engineering Resources
Status/Measurement Information
Design Decision Information
ENGINEERING
MANAGEMENT
plan the engineering
organise resources
motivate engineering staff
measure performance of the
engineering
exercise control of outcomes
P1135-004875-1
Ad-Hoc Instructions/Guidance to
Staff
Revisions to Engineering Plan
Page 70 of 123
Do:
Recognize that the engineering system is a system like any other system.
Engineer it as such
Why?
P1135-004875-1
Page 71 of 123
Do:
P1135-004875-1
Page 72 of 123
Do:
Why?
P1135-004875-1
Page 73 of 123
IPT
Leader
stakeholder
needs
Functional
Reps
Specialists
Customer
Product to
customer/
higher level
team
P1135-004875-1
Page 74 of 123
Do:
Why?
P1135-004875-1
Page 75 of 123
Dont:
Defy history without having a very good reason for doing so - adopting
courses of action that have historically failed
Why?
P1135-004875-1
Page 76 of 123
P1135-004875-1
Page 77 of 123
SYSTEMS ENGINEERING
BASIC PROCESS ELEMENTS
P1135-004875-1
Page 78 of 123
ALLOCATION OF FUNCTIONS TO
ARCHITECTURAL ELEMENTS
P1135-004875-1
Page 79 of 123
THE ROLE OF
COGNITIVE SYSTEMS ENGINEERING
P1135-004875-1
Page 80 of 123
The Task
1. Carefully read the handout, titled Systems Engineering Principles. Then consider as a
group, for each principle, the following questions:
a. Is it a valid and beneficial principle in the performance of our engineering?
b. Do I have any questions, issues or qualifications?
In the wrap-up, a person who has carriage of a principle for the group should read out the
principle aloud, present the groups conclusion, and then invite comment. Quickly hand
over to the next group/person/principle when useful discussion has concluded, or if no
useful comment is forthcoming
Your facilitator will be available to answer questions and correct any misunderstandings of
intent of the statements of the principles
P1135-004875-1
Page 81 of 123
P1135-004875-1
Page 82 of 123
P1135-004875-1
Page 83 of 123
Test/verification procedures
Records of test/verification results
Validation procedures
P1135-004875-1
Page 84 of 123
P1135-004875-1
Page 85 of 123
P1135-004875-1
Page 86 of 123
P1135-004875-1
Page 87 of 123
P1135-004875-1
Page 88 of 123
Acronyms: IRS
Standards: PPA-ME04-002234 current release
P1135-004875-1
Page 89 of 123
P1135-004875-1
Page 90 of 123
VERIFICATION REQUIREMENTS
SPECIFICATION
Description: The Verification Requirements Specification (VRS) describes
the qualities of the evidence required that a set of requirements defining an
item is satisfied. The item may be of any nature whatsoever, ranging from,
for example, a physical object, to software, to an interface, to a data item,
to a material, or a service. The VRS is used to communicate to verification
design personnel the characteristics required of any verification solution, i.e.
the VRS is a major input to the development of test procedures and similar.
The VRS also provides the criteria against which test, and other verification
procedures, may themselves be verified. The VRS is not a list of verification
methods, unless the only requirement regarding each verification activity is
that it be performed in a particular way, i.e. a verification solution direction
Acronyms: VRS
Standards: PPA-003914 current release
P1135-004875-1
Page 91 of 123
P1135-004875-1
Page 92 of 123
Supply Support
Support-Related Technical Data
Support-Related Facilities
Support-Related Manpower and Personnel
Packaging, Handling and Storage
Operational Training and Training Support
Support Equipment
Computer Resource Support
Maintenance Planning
End-Use Item Design Interface.
P1135-004875-1
Page 93 of 123
ILSP (2)
P1135-004875-1
Page 94 of 123
P1135-004875-1
Page 95 of 123
TEST/VERIFICATION DESCRIPTION
Description: A System or Software Test Description (STD) describes the
test/verification preparations, test/verification cases, and test/verification
procedures to be used to perform verification testing or other means of
verification of a system or system element. The STD is used to
communicate to test/verification personnel the information necessary for the
test/verification to be performed. The STD also enables the acquirer to
assess the adequacy of the verification activity intended to be performed. A
STD will normally be prepared in satisfaction of a verification requirement
Acronyms: STD, STP, TD, TP
Standards: TAA-ME04-001136 current release
P1135-004875-1
Page 96 of 123
Acronyms:
Standards:
P1135-004875-1
Page 97 of 123
Acronyms:
Standards:
P1135-004875-1
Page 98 of 123
Acronyms:
Standards:
P1135-004875-1
Page 99 of 123
P1135-004875-1
Acronyms:
Standards:
P1135-004875-1
Acronyms:
Standards:
P1135-004875-1
SIMULATION REPORT
Acronyms:
Standards:
P1135-004875-1
SPECIFICATION TREE
Acronyms:
Standards:
P1135-004875-1
MODEL-BASED SYSTEMS
ENGINEERING (MBSE)
APPLIED TO THE PROBLEM
DOMAIN
P1135-004875-1
P1135-004875-1
P1135-004875-1
P1135-004875-1
P1135-004875-1
P1135-004875-1
P1135-004875-1
MODEL-BASED SYSTEMS
ENGINEERING (MBSE)
APPLIED TO THE SOLUTION DOMAIN
P1135-004875-1
ALLOCATION OF FUNCTIONS TO
ARCHITECTURAL ELEMENTS
P1135-004875-1
P1135-004875-1
P1135-004875-1
P1135-004875-1
P1135-004875-1
P1135-004875-1
P1135-004875-1
AADL DIAGRAM
P1135-004875-1
SOFTWARE SUPPORT TO
SYSTEMS ENGINEERING
P1135-004875-1
HARDWARE SUPPORT TO
SYSTEMS ENGINEERING
P1135-004875-1
Robert J. Halligan
Email: rhalligan@ppi-int.com
CPPI-005210-1 copyright and all Other Rights Reserved Project Performance (Australia) Pty Ltd 1998-2011
Improvement Opportunities for Systems Engineering Practice in Brasil and in the World 123