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 1

!!

Past Director, International Council on Systems Engineering (INCOSE) Past INCOSE Head of Delegation to ISO/IEC SC7 on Software and Systems Engineering Past President, Systems Engineering Society of Australia Content contributor to EIA/IS-632, EIA 632, IEEE 1220, ISO/IEC 15288 SE standards Consultant/trainer to Alcatel-Lucent, General Dynamics, Mitsubishi, EADS, Thales, Raytheon, General Electric, NATS, IAEA, JAXA, Boeing, and many other enterprises on six continents Current INCOSE Ambassador
Improvement Opportunities for Systems Engineering Practice in Brasil and in the World 2

!!

!! !!

!!

!!

CPPI-005210-1 copyright and all Other Rights Reserved Project Performance (Australia) Pty Ltd 1998-2011

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

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 3 of 123

AN ENGINEERED SYSTEM IS?

A combination of interacting elements organized to achieve one or more stated purposes

Source: ISO/IEC 15288:2008 Systems and software engineering System life cycle processes

Key concepts: Organization Elements Interaction Purpose

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 4 of 123

A SYSTEMS APPROACH

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 5 of 123

VIEWS RELATED TO SYSTEMS ENGINEERING

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

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 6 of 123

SYSTEMS ENGINEERING IS:

Systems engineering is an interdisciplinary, collaborative approach to the engineering of systems (of any type) which aims to capture stakeholder needs and objectives and to transform these into a description of a holistic, life-cycle balanced system solution which both satisfies the minimum requirements, and optimizes overall project and system effectiveness according to the values of the stakeholders. Systems engineering incorporates both technical and management processes Source: Halligan, 2003 Key concepts:

Engineering Collaboration Effectiveness Stakeholder satisfaction

Interdisciplinary working Life-cycle balance Optimization Stakeholder value

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 7 of 123

PHYSICAL LEVELS RELATED TO KEY INFORMATION TYPES

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 8 of 123

KEY QUESTIONS!

! !

What should we do in practicing systems engineering?

What should we not do in practicing systems engineering!?

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 9 of 123

INDICATORS OF EFFECTIVE SE PRODUCT-ORIENTED ENTERPRISE:

! ! ! ! ! ! !
On, under or close to development budget On, ahead of or close to development schedule High Return on Sales Market leadership Low warranty costs Repeat business is the norm High staff satisfaction and retention

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 10 of 123

INDICATORS OF EFFECTIVE SE CONTRACT-ORIENTED ENTERPRISE:

! ! ! ! ! ! !
On, under or close to development budget On, ahead of or close to development schedule High contract gross margin High customer satisfaction Low warranty costs Repeat business is the norm High staff satisfaction and retention

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 11 of 123

INDICATORS OF EFFECTIVE SE INTERNAL PROJECTS:

! ! ! ! !
On, under or close to development budget On, ahead of or close to development schedule High internal customer satisfaction No desire to outsource High staff satisfaction and retention

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 12 of 123

INDICATORS OF EFFECTIVE SYSTEMS ENGINEERING MANAGEMENT:

! ! ! ! ! !
Effective systems engineering Harnessing of creativity A learning environment Growing intellectual capital within the enterprise High staff satisfaction and retention A shared vision of the product and related focus on quality, cost, time

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 13 of 123

INDICATORS OF NO SE OR INEFFECTIVE SE:

! ! ! ! ! !
Milestones missed Significant dispute with customers over requirements Many problems and delays occur during system integration Significant dispute with customers over testing Significant problems occur in released or fielded systems/products Engineering effort tends to be back-end loaded during development

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 14 of 123

PITFALLS IN EXPLOITING SE:

! ! ! ! ! ! !
United States DoD mindset and standards silver bullet mentality Choosing inappropriate resources (e.g. standards, handbooks) Forcing new processes on unwilling participants Revolution rather than evolution Only superficial training of engineering personnel No measurement, no IV&V

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 15 of 123

Do:
!
Establish an objectively adequate problem definition before committing significant resources to design and development

Why?
!
Inadequate requirements have consistently been the single biggest cause of project failures and losses in all sectors. The cost of inaction typically exceeds the cost of prevention by a factor of 10-100 to one

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 16 of 123

OBJECTIVE CRITERIA FOR ADEQUACY APPLIED TO REQUIREMENTS

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 17 of 123

SYSTEM REQUIREMENTS ANALYSIS

System Requirements Needs, wants, desires, expectations, intent information Knowledge of feasible solution technologies Value and Risk information Background information

SYSTEM REQUIREMENTS ANALYSI S

! capture and validate requirements, MOEs, goals and value relationships

System Requirements Specification (document or database) Operational Concept Description System Verification (Test) Requirements Specification Value (System Effectiveness) Model Requirements Traceability Database Requirements Analysis Records and Analytical Models

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 18 of 123

USE ANALYSIS TOGETHER WITH RESOLUTION OF SPECIFIC ISSUES AS THE PRIMARY RA STRATEGY

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 19 of 123

USE SOUND, EFFECTIVE METHODS OF REQUIREMENTS ANALYSIS

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 20 of 123

CAPTURE AND VALIDATE REQUIREMENTS ON A LIFECYCLE BASIS

LIFE CYCLE CONTEXT IS IMPORTANT.

Requirements come from these contexts

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 21 of 123

CONSIDER MOES & GOALS, NOT JUST REQUIREMENTS

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 22 of 123

MAXIMISE VALUE TO COMPANY, OPTIMISE VALUE TO CUSTOMER

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 23 of 123

PERFORM OPTIMUM VERIFICATION

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 24 of 123

Do:

Design a solution by dividing the big problem into a set of individually sufficiently-well-defined smaller problems, i.e., by defining the required characteristics of each element of the solution (including both product (hardware and software, etc.) and process elements, as applicable)

Why?

To do otherwise works outside the cognitive limits of the human brain, resulting in design errors, the need for much increased design verification, and problems first revealed in system integration (or later)

Copyright Project Performance (Australia) Pty Ltd 2011

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

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 26 of 123

Dont:

!Just partition requirements, allocating system requirements to system

elements, or to categories of technology, e.g. to hardware and software

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

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 27 of 123

Do:

Regard knowledge of relevant technologies, and the creativity and attitudes to apply that knowledge in a team environment, as indispensible ingredients of effective systems engineering

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

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 28 of 123

DESIGN PHYSICAL SOLUTION, DESIGN LOGICAL SOLUTION

System Requirements Specification Value (System Effectiveness) Model Knowledge of relevant solution technologies Design Decisions (from EE&D Process) Concurrent Engineering Issues Design related problems (if any) from System Integration

DESIGN PHYSICAL SOLUTION

develop

The Design: Identification and required characteristics of each system element (product and process) Design Description(s) AD Verification Requirements for each element Requirements Traceability Database (in Design) Feasible Design Alternatives (to EE&D Process)

physical solution descriptions DD

Physical Concept

Concurrent Engineering Issues Residual products, e.g., prototypes

Functions to be physically implemented (with inputs, outputs, performance, start and finish conditions)

DESIGN FUNCTIONAL SOLUTION

Legend: AD - Architectual Design DD - Detail Design EE&D - Effectiveness Evaluation & Decision

AD Other logical prototypes and models

functional solution descriptions DD

develop

Copyright Project Performance (Australia) Pty Ltd 2011

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

Copyright Project Performance (Australia) Pty Ltd 2011

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

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 32 of 123

INCREMENTAL DEVELOPMENT (1)

Note: may be a loop rather than an iteration

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 33 of 123

Do:

!Use incremental development where requirements (etc.) can be well

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

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 34 of 123

INCREMENTAL DEVELOPMENT (2)

Note: may be a loop rather than an iteration

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 35 of 123

EVOLUTIONARY DEVELOPMENT

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 36 of 123

Do:

!Use evolutionary development where requirements (etc.) are as well-

defined as is possible in the circumstances, but remain inadequately defined from the point of view of the company, or are subject to change that the enterprise needs to accommodate Why? ! Evolutionary development is most able to satisfy end-use needs at the time of supply

Note: evolutionary development should not normally be used as an alternative to capturing what is already known or knowable about requirements always do that!

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 37 of 123

Do:

!Use a stage-based, stage gate, risk and opportunity-driven style of

development as an overall strategy for development (sometimes referred to a Spiral development)

Why?

A stage-based, stage gate, risk and opportunity-driven style of development maximises expected value delivered by a project to an enterprise

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 38 of 123

ILLUSTRATION OF THE SPIRAL MODEL

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 39 of 123

Do:

!Apply the systems engineering process elements selectively within the

context of sequential, incremental, evolutionary and/or the risk and opportunity-driven styles of development. Design the development process to match the nature of the problem, using the SE process elements as building blocks

Why?

Doing everything all of the time is a recipe for overkill. Doing nothing all the time is a recipe for disaster

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 40 of 123

IMPLEMENT REQUIREMENTS TRACEABILITY IN DESIGN

SYSTEM SUBSYSTEMS" SUBSYSTEMS" SUBSYSTEMS" SUBSYSTEMS"

Relationships in direction Child to Parent mean:" "is in full or partial satisfaction of"
OP PROC

Note: Only one owdown path is shown in full"

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 41 of 123

IMPLEMENT VERIFICATION TRACEABILITY

System Requirements Verication (Test) Requirements Test Cases

Verication (Test) Procedure/ Description

Test

Test Result

Test Report

Test Specication

Test Article

Test Articles Master Test Plan Test Plan

Note: Similar relationships are applicable for test traceability for software and services.

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 42 of 123

APPLY SYSTEMS ENGINEERING RECURSIVELY ON PROGRESSIVELY SMALLER DEVELOPMENTAL ELEMENTS

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 43 of 123

Do:

!Maintain a distinction between the statement of the problem to be solved,

and the description of the solution to that problem, for the system-ofinterest, and for each element of the evolving solution

Why?

If we dont, and the problem changes, we do not know what we can change and what we cannot change. If we dont, and we need to change the solution, we do not know what we can change and what we cannot change. If we dont, we have lost any reference for verification of solution

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 44 of 123

Do:

!Baseline (establish a reference definition of) the statement of the problem

to be solved, and the description of the solution to that problem. Control changes to requirements (etc.) and to design, maintaining traceability to the applicable baseline Why?

Copyright Project Performance (Australia) Pty Ltd 2011

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

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 46 of 123

Do:

Develop solutions for relevant enabling systems concurrently, and in balance with, the solution to the system of interest practice concurrent engineering

Note: An enabling system is a system which makes possible the creation, or ongoing availability for use, of the system of interest during some part of its life cycle, e.g. a production system, a maintenance system Why?

Developing the system of interest and enabling systems in sequence results in high costs and long timelines. Decisions are stovepipe, resulting in rework, or irreversible decisions that compromise capability. This can seriously damage an enterprise

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 47 of 123

CONCURRENT/SIMULTANEOUS ENGINEERING
! Concurrent ! Collaborative ! Balanced development of

System of Interest
System

Enablin g 1System or more

e.g. Engineering Production System Maintenance

System Disposal System

Copyright Project Performance (Australia) Pty Ltd 2011 P1135-004875-1 Page 48 of 123

CONCURRENT ENGINEERING CONCEPTS

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 49 of 123

SEQUENTIAL DEVELOPMENT TIMELINE

1998 ID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Task Name Project Initiation Development Planning Product Design Production Design User Documentation Design of Support Enhancement Project Initiation Enhancement Development Plannning Enhancement Product Design Enhancement Production Design Enhancement User Documentation Enhancement Support Design Aug Sep Oct Nov Dec Jan Feb Mar Apr May 1999 Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar

2011

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 50 of 123

CONCURRENT DEVELOPMENT TIMELINE

2011
1998 ID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Task Name Project Initiation Development Planning Product Design Production Design User Documentation Design of Support Enhancement Project Initiation Enhancement Development Plannning Enhancement Product Design Enhancement Production Design Enhancement User Documentation Enhancement Support Design Aug Sep Oct Nov Dec Jan Feb Mar Apr May 1999 Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar 2000

Concurrency shortens the timeline

Copyright Project Performance (Australia) Pty Ltd 2011 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

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 52 of 123

PHYSICAL AND LOGICAL DESIGN - EXAMPLE

PROBLEM
a, b, c

Y = a(b+c)

SOLUTION
a, b, c is to be performed by .. Add b and c Multiply (b+c) by a

Processor 2

a, (b+c) Processor 1

a, (b+c)

Y is to be performed by .. a, b, c

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 53 of 123

PHYSICAL AND LOGICAL DESIGN - EXAMPLE

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 54 of 123

DESIGN VIEWS - PHYSICAL AND LOGICAL

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 55 of 123

EFFECTIVENESS EVALUATION AND DECISION

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 56 of 123

Do:

!Select between (feasible) design alternatives based on the evaluation of

risk-adjusted expected benefit to applicable stakeholders, i.e., on expected overall effectiveness Note: expected effectiveness refers to effectiveness which incorporates uncertainty, reflecting risk and opportunity

Why?

This strategy will produce the best average outcome from our engineering

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 57 of 123

Do:

!Be prepared to iterate in design, to drive up the benefit to the applicable

(primary) stakeholders of the outcomes of design

Why?

To do otherwise is to assume that, as designers, we always come up with the best, for our enterprise, implementation of a concept the first time. This is rarely the case

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 58 of 123

TRADE STUDIES AND DESIGN ITERATION

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 59 of 123

DESCRIPTION OF SYSTEM ELEMENTS

Solution (how) decisions, comprising requirements and goals for each system element Standard for specification of each type of system element

DESCRIPTION OF SYSTEM ELEMENTS

! write specifications etc.,

Relevant non-requirements information

System Requirements Specification or Software Requirements Specification or Operating Procedure/ Task List or Maintenance Procedure/ Task List or Integration/Build Instruction or Verification (Test) Requirements Specification or Specification of another Service or Interface Requirements Specification

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 60 of 123

SYSTEM INTEGRATION

Build Instructions

Built system/sub-system

SYSTEM INTEGRA TION

System Integration Plan

Informal evidence that the system meets its requirements Description(s) of problems encountered (if any) + diagnosis as built solution description

System Elements

! build the system/ system element

Copyright Project Performance (Australia) Pty Ltd 2011

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?

Verification is a risk-reduction activity. If the amount of risk reduction exceeds the cost of the verification activity, it is a good thing to do

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 62 of 123

VERIFICATION

Work Product

VERIFICATION
! does the work product meet its requirements? ! is the work product sub-optimum with respect to MOEs, etc..?

Pass/FailAssessment

Standard for the Work Product (Requirements)

Possible statement(s) of deficiency or concern Residual Products (e.g., prototypes, analyses, models)

Verification Procedure

Pass/fail criteria

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 63 of 123

 Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 64 of 123

Dont:

!Rely on technical progress meetings with the customer for design

verification, even if these meetings go under the name of design reviews

Why?

The cost of correction of design errors undiscovered in design verification exceeds the cost of (discovery + early correction) by a factor of about 5:1

Copyright Project Performance (Australia) Pty Ltd 2011

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?

Validation is a risk-reduction activity. If the amount of risk reduction exceeds the cost of the validation activity, it is a good thing to do

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 66 of 123

VALIDATION

Work Product

VALIDATION
! does the work product meet the need? ! is the work product sub-optimum in the extent of doing so?

Pass/Fail Assessment

Needs Information

Possible statement(s) of deficiency or concern

Validation Procedure

Residual products (e.g., prototypes, analyses, models)

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 67 of 123

 Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 68 of 123

Do:

Manage the engineering plan, organize, motivate, assess, control

Why?

Studies show a 7% increase in return on sales between companies that routinely plan and control their projects versus those that dont

Copyright Project Performance (Australia) Pty Ltd 2011

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

Initial Engineering Plan

Ad-Hoc Instructions/Guidance to Staff Revisions to Engineering Plan

Concurrent Engineering Issues

Evolving Configuration Data

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 70 of 123

Do:

!Recognize that the engineering system is a system like any other system.
Engineer it as such

Why?

Engineering the engineering system aims to produce an optimum implementation of the engineering system, with all work done adding maximum value, compared with the alternatives, for the enterprise

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 71 of 123

Do:

!Use a product-oriented structure of products and related services (PBS/

WBS) as a framework for definition, cost estimating, scheduling, risk analysis, measurement, assignment of responsibility, team design and reporting Why?

PBS/WBS is an enormously powerful tool in managing the engineering and the project. But to be a powerful tool, it must be developed within a set of principles and rules

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 72 of 123

Do:

!Use empowered, product-oriented, multidisciplinary team structures for

larger engineering efforts

Why?

Integrated Product Teams (IPTs) have a well-established record of higher performance than alternative organizational units

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 73 of 123

INSIDE AN INTEGRATED PRODUCT TEAM

Other IPT Members IPT Leader Subtea m Leaders

stakeholder needs

Functional Reps

Specialists Customer

Product to customer/ higher level team

! !

A multi-disciplinary, cross-functional, stake holder-focussed team solely responsible for taking a product from need to delivery Knowledge, skills and attitudes of the team members are complementary
P1135-004875-1 Page 74 of 123

Copyright Project Performance (Australia) Pty Ltd 2011

Do:

!Choose to do things only in the rational expectation of producing a better

result by doing so (on the balance of probabilities). Choose to NOT do things for EXACTLY the same reason

Why?

Because to do otherwise is to set out to achieve a worse result for the enterprise, and thats crazy!

Copyright Project Performance (Australia) Pty Ltd 2011

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?

The past is a good pointer to the future

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 76 of 123

 Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 77 of 123

SYSTEMS ENGINEERING BASIC PROCESS ELEMENTS

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 78 of 123

ALLOCATION OF FUNCTIONS TO ARCHITECTURAL ELEMENTS

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 79 of 123

THE ROLE OF COGNITIVE SYSTEMS ENGINEERING

Cognitive Systems Engineering (CSE) is an approach to the design of technology, training, and processes intended to manage cognitive complexity in sociotechnical systems Militelo, Dominguez, Lintern and Klein, The Role of Cognitive Systems Engineering in the Systems Engineering Design Process, Systems Engineering, Vol 13, No. 3, 2010

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 80 of 123

WORKSHOP 1 - PRINCIPLES OF THE ENGINEERING OF SYSTEMS

The Objective
To consider a set of principles which may be applied in the engineering of systems (of all types)

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

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 81 of 123

CAPABILITY MATURITY MODELS

Reference models against which engineering-related capability may be assessed: ! EIA-731 - good ! CMMI - much very good content, but problems in requirements management, requirements development & technical solution development ! ISO/IEC TR 15504 ! Other CMMs

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 82 of 123

LOGISTIC SUPPORT ANALYSIS

! Would better be titled Logistic Support Analysis and Design ! It is to the support solution what end use product design is to the end use product solution - it is a systems engineering approach applied to the design of the support system, and its interface with the products which are to be supported

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 83 of 123

KEY SYSTEMS ENGINEERING ARTIFACTS

! ! ! ! ! ! ! ! ! ! ! Systems engineering plans Operational concept descriptions System requirements specifications Interface requirements specifications Verification requirements specifications Architectural design descriptions Detailed design descriptions Test/verification procedures Records of test/verification results Validation procedures Records of validation results

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 84 of 123

SYSTEMS ENGINEERING PLAN

Description: The Systems Engineering Plan (SEP) defines the plans and procedures of an enterprise for the management and conduct by that enterprise of a fully integrated technical program in conduct of the engineering element(s) of a project or a part thereof. The term SEP is generic, and may be replaced with any meaningful name. The term enterprise may be interpreted to mean any entity responsible for performance of the work which is the subject of the SEP. The SEP, including or supplemented by subordinate plans, is used to provide the primary work planning and process direction and guidance to the technical team responsible for conduct of the work. The SEP may also be used to provide visibility, to a customer, of a suppliers engineering planning and intended processes. The content of the SEP is intended to be responsive to contract requirements, if any, but is not, itself, intended to be invoked contractually Acronyms: SEP, SEMP, EMP Standards: PPA-ME04-000905 current release, DI-MGMT-81024
Copyright Project Performance (Australia) Pty Ltd 2011 P1135-004875-1 Page 85 of 123

OPERATIONAL CONCEPT DESCRIPTION

Description: The Operational Concept Description (OCD) describes, for a system, subsystem, HWCI, CSCI, component or other item, herein referred to generically as the system, who the users of the system are, what are the intended uses of the system, how and where the system is intended to be used, and a representative set of scenarios of use. These scenarios, each associated with a particular intended use (mission), are chosen to represent both typical and limit conditions of use. The OCD provides a direct reference for validation of requirements, and fitness for intended use of the solution Acronyms: OCD, ConUse, ConEmp, SOI Standards: PPA-ME04-000950 current release

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 86 of 123

SYSTEM REQUIREMENTS SPECIFICATION

Description: A System Requirements Specification (SyRS) specifies the requirements to be satisfied by a system, subsystem, HWCI, component or other physical item, and optionally the requirements for evidence that each requirement has been so satisfied. Requirements pertaining to the system, subsystem or items external interfaces may be presented in the SyRS or in one or more Interface Requirements Specifications (IRSs) or Interface Control Documents (ICDs) invoked by reference from the SyRS. The SyRS, possibly supplemented by IRSs or ICDs, is commonly used as the basis for acquisition, supply design and development, verification and acceptance of the system, subsystem or other item Acronyms: SyRS, SSS, SRS, PDS, FPS, ORD, MRD, A B or C Spec, .. Standards: PPA-002235 current release

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 87 of 123

SOFTWARE REQUIREMENTS SPECIFICATION

Description: The Software Requirements Specification (SRS) specifies the requirements to be satisfied by a software item (eg. software system, subsystem, CSCI, component or other item), and, optionally, corresponding verification requirements. Requirements pertaining to the software items external interfaces may be presented in the SRS or in one or more Interface Requirements Specifications (IRSs) referenced from the SRS. The SRS, possibly supplemented by IRSs, is used as the basis for procurement, design, verification testing and acceptance testing of the software item Acronyms: SRS, SoRS Standards: PPA-002237 current release

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 88 of 123

INTERFACE REQUIREMENTS SPECIFICATION

Description: An Interface Requirements Specification (IRS) specifies the requirements to be satisfied at an interface between two items (hardwarehardware including hardware-human, hardware-software or softwaresoftware) and, optionally, corresponding verification requirements. The IRS is used in support of procurement, design, verification testing and acceptance testing of one or both of the items

Acronyms: IRS Standards: PPA-ME04-002234 current release

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 89 of 123

INTERFACE DESIGN DESCRIPTION

Description: The Interface Design Description (IDD) describes the design characteristics at an interface between two items (hardware-hardware including hardware-human, hardware-software or software-software). The IDD is used in system development to record, communicate and control external interface design, at the most detailed level of definition of an external interfaces, and consistent with requirements contained within the corresponding Interface Requirements Specification (IRS). The IRS specifies interface requirements; the IDD describes interface characteristics selected to meet those requirements. The IDD can be used to supplement a System/ Subsystem Design Description (SSDD), Software Design Description (SDD), or Database Design Description (DBDD). An IDD may describe one or more interfaces Acronyms: IDD, ICD Standards: PPA-004611 current release

Copyright Project Performance (Australia) Pty Ltd 2011

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

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 91 of 123

ARCHITECTURAL DESIGN DESCRIPTION

Description: The Architectural Design Description (ADD) describes the architectural (conceptual) design of the system or subsystem which is the subject of the ADD. The ADD may be supplemented by Interface Design Descriptions (IDDs) and Database Design Descriptions (DBDDs) for descriptions of design decisions relating to external interfaces, internal interfaces, externally input databases, externally output databases and databases internal to the system/subsystem. The ADD, with any associated IDDs and DBDDs, is used to communicate the architectural design within the design team, to design reviewers, acquirers, maintainers and modifiers, as applicable. A System/Subsystem Design Description (SSDD) is a common form of ADD. Acronyms: ADD, SSDD Standards: PPA-ME04-002586 current release

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 92 of 123

INTEGRATED LOGISTICS SUPPORT PLAN ILSP (1)

1. Prepared by the customer and/or supplier 2. Documents the plan for operational support - it is a support system solution description 3. May include up to ten elements of ILS: 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

Copyright Project Performance (Australia) Pty Ltd 2011

ILSP (2)

4. Support system requirements must be consistent with readiness or availability requirements or objectives, with End-Use Item design, and with each other 5. Identifies support system structure elements to be developed or acquired so that the End-Use Item is both supportable and supported when released/deployed/installed 6. Includes post-production support to ensure economic logistics support after cessation of relevant production

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 94 of 123

DETAILED DESIGN DESCRIPTION

Description: A Detailed Design Description (DDD) describes the design of a system or subsystem which is the subject of the DDD, at a level of detail sufficient to allow each element of solution to be acquired or itself be designed and developed. The DDD may be supplemented by Interface Design Descriptions (IDDs) and Database Design Descriptions (DBDDs) for descriptions of design decisions relating to external interfaces, internal interfaces, externally input databases, externally output databases and databases internal to the system/subsystem. The DDD, with any associated IDDs and DBDDs, is used to record and communicate the detailed design within the design team, to design reviewers, acquirers, maintainers and modifiers, as applicable. In practice, a DDD may comprise a plethora of individual design records in a variety of forms Acronyms: DDD, TDP Standards:

Copyright Project Performance (Australia) Pty Ltd 2011

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

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 96 of 123

RECORDS OF TEST/VERIFICATION RESULTS

Description: Test/verification results are the original records of the results of performing verification testing, or other means of verification of a system or system element

Acronyms: Standards:

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 97 of 123

VALIDATION PLANS AND PROCEDURES

Description: Validation plans and procedures describe when and how system or system element validation is to be carried out, e.g. test marketing, or operational test and evaluation (OT&E)

Acronyms: Standards:

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 98 of 123

RECORDS OF VALIDATION RESULTS

Description: Validation results are the original records of the results of performing validation of a system or system element

Acronyms: Standards:

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 99 of 123

OTHER POTENTIAL SYSTEMS ENGINEERING ARTIFACTS

! Feasibility study reports ! Trade-off study reports ! Simulation reports ! Specification tree

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 100 of 123

FEASIBILITY STUDY REPORTS

Description: A Feasibility Study Report records and communicates the results of a study as to whether is is possible to solve an adequately defined problem, having regard to all the characteristics that must be present in any solution for the solution to be acceptable

Acronyms: Standards:

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 101 of 123

TRADE-OFF STUDY REPORTS

Description: A Trade-Off Study Report records and communicates the results of a study as to the overall effectiveness of alternative feasible solutions. A Trade-Off Study Report may also contain the results of optimization of one or more solution alternatives

Acronyms: Standards:

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 102 of 123

SIMULATION REPORT

Description: A Simulation Report records and communicates the results of the conduct of simulation activities. Simulation activities are activities which seek to imitate the behavior of something by means of the behavior some other thing suitably analogous

Acronyms: Standards:

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 103 of 123

SPECIFICATION TREE

Description: A specification tree shows the requirements specifications related to a technical system under development in a hierarchical order related to the structure of the system in terms of system elements

Acronyms: Standards:

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 104 of 123

MODEL-BASED SYSTEMS ENGINEERING (MBSE) APPLIED TO THE PROBLEM DOMAIN

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 105 of 123

STATES & MODES ANALYSIS EXAMPLE

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 106 of 123

FUNCTIONAL ANALYSIS - EXAMPLE 1-1

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 107 of 123

FUNCTIONAL ANALYSIS - EXAMPLE 1-2

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 108 of 123

FUNCTIONAL ANALYSIS - EXAMPLE 1-3

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 109 of 123

FUNCTIONAL ANALYSIS - EXAMPLE 1-4

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 110 of 123

FUNCTIONAL ANALYSIS - EXAMPLE 1-5

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 111 of 123

MODEL-BASED SYSTEMS ENGINEERING (MBSE) APPLIED TO THE SOLUTION DOMAIN

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 112 of 123

ALLOCATION OF FUNCTIONS TO ARCHITECTURAL ELEMENTS

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 113 of 123

 Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 114 of 123

Document Number: P006-003763-3 Copyright Project Performance (Australia) Pty Ltd 2011 P1135-004875-1 Page 115 of 123

Document Number: P006-004747-2 Copyright Project Performance (Australia) Pty Ltd 2011 P1135-004875-1 Page 116 of 123

 Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 117 of 123

RDD BEHAVIOUR MODEL

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 118 of 123

SYSML - FUNCTIONAL MODELING

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 119 of 123

AADL DIAGRAM

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 120 of 123

SOFTWARE SUPPORT TO SYSTEMS ENGINEERING

! Requirements management software ! Value modeling and decision support software ! Logical and physical design software ! Design analysis software ! Simulation software ! Test management software ! Configuration management software

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 121 of 123

HARDWARE SUPPORT TO SYSTEMS ENGINEERING

! Computing hardware and peripherals ! Test equipment ! Physical prototypes

Copyright Project Performance (Australia) Pty Ltd 2011

P1135-004875-1

Page 122 of 123

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