Track 2 a improving defence program execution - barclay brown

1. Barclay Brown, ESEP – Global Solution Executive
5 October 2012
Advanced Systems Engineering:
Improving Defense Program Execution
© 2009 IBM Corporation

2. Systems Engineering has both a breadth and depth perspective.
Systems Engineering
Breadth Perspective
Cross-discipline analysis, system-of-systems modeling
System
SubSystem SubSystem SubSystem
Electrical Software Mechanical Software
Component Component Component Component
2 © 2009 IBM Corporation

3. Systems Engineering has both a breadth and depth perspective.
Systems Engineering
Breadth Perspective
Cross-discipline analysis, system-of-systems modeling
System
Systems Engineering is a
profession, a role, even
a job title, for those who
work exclusively at a
SubSystem SubSystem SubSystem
Systems Engineering also system-of-systems level.
names a set of methods,
skills and techniques that
can be applied both at a
Electrical Software
system-of-systems level Mechanical Software
Component Component
and within specific Component Component
engineering disciplines.
3 © 2009 IBM Corporation

4. Value of Systems Engineering: Cost and Schedule
Applying the right amount of systems engineering is critical to
meeting cost and schedule targets.
Source: Honour, Eric (2010), Systems Engineering Return on Investment, University of South Australia, p9
4 © 2009 IBM Corporation

5. Value of Systems Engineering: Success and Quality
Applying the right amount of systems engineering is critical to
program success.
Source: Honour, Eric (2010), Systems Engineering Return on Investment, University of South Australia, p9
5 © 2009 IBM Corporation

6. Today’s reality: for integrated device and
software of systems development
Device software designs completed over
66% budget
EMF 2003
Projects canceled due to unrecoverable
24% slip in schedule
EMF 2003
Produced devices do not meet
33%
XX% performance or functionality requirements
EMF 2003
Software content in devices is doubling
2x every two years
IDC 2002
6 © 2009 IBM Corporation

7. Many notable system failures have been failures in subsystem
interfaces, requirements fidelity and system engineering.
Systems have become more complex through integration
– E.g. automobiles with multiple ECUs are more like a network of general
purpose computers with large network software
Projects with 700-2000 requirements cannot be held in mind at full
detail
– Models with varied levels of abstraction must be used
Managing change and understanding impact of change is a $$$ million
problem
– Requirements models and automated tools must be used to be effective
Interestingly, these are failures of knowledge
and communication, not of engineering.
7 © 2009 IBM Corporation

8. What do each of these have to teach us about Advanced Systems
Engineering?
8 © 2009 IBM Corporation

9. The Philosophy of Advanced Systems Engineering
Models are better than documents (but documents are needed too)
Collaborate and share information across functions
Build Shared Understanding as hedge against risks
Automate as much as possible
Insurance: Invest a little now to avoid large risk later
Optimize for change (not for stability)
Be able to trace everything, but only trace what adds value
ABC: Adopt before Buy, Buy before Create
Measure and improve; closed-loop governance
Start early: what can we do NOW?
9 © 2009 IBM Corporation

10. Advanced Requirements
Management
Derivation
Traceability
Requirements are no longer “one
kind of thing”
Recognize levels and types and
their relationships
Implement “live” traceability
between all kinds of
requirements, including
architecture and design
Link requirements to design,
implementation, verification and
validation, user training, etc.
© 2009 IBM Corporation
10

11. The changing role of
requirements
Text requirements give rise to models
which elaborate and elucidate
Models give rise to additional text
requirements which specify and
constrain
Text
Text and models are useful at all
levels of system abstraction Models
Capture rationale and thinking at
each level to differentiate
requirements from design choices
11 © 2009 IBM Corporation

12. What makes a model a model?
The Dumb Way The Smart(er) Way
=-A11*4*(1-
B11)+4*C11
=NORMDIST(A11,
0,1,FALSE) Smarter or Dumber?
=100+3*50+2*3*70+3*3*40+4*3*100 Requirements
+5*3*125 Trade Studies
Flowdown / Allocation
Designs
The relationships are baked-in Component Specifications
TPMs
Optimized for change
12 © 2009 IBM Corporation

13. Model Philosophy I: What are models for?
Models can
–Document. Derived from already existing reality or agreement.
–Represent. Help people communicate and agree.
–Hold thought. Be a shared mental space for collaborative thinking.
–Illustrate. A picture is worth a thousand words.
–Calculate. Both show and quantify relationships.
–Evaluate. Show alternatives and criteria for trade-off analysis.
–Build. Translate models into real things.
It is important to be clear on the purpose for a model you are
creating (and maintaining.)
13 © 2009 IBM Corporation

14. Model Philosophy II: Model relationships
Models and model elements have relationships with other model elements and with other
information relevant to the system.
Important relationships
– Derivation
– Fulfillment (coverage)
– Decomposition
– Dependency
For instance,
– A model element may fulfill (fully or partially) a requirement.
– A requirement may be derived from another requirement.
– A requirement may arise from a model element.
– A model element may decompose into another model element.
– A model element, or requirement, may depend on another model element.
It is important to figure out how your model elements and requirements relate to each
other.
14 © 2009 IBM Corporation

15. Model Philosophy III: Dangers in Adopting Modeling
All models are good. Causes model proliferation
without meaning and purpose.
Method-centric. We do these models because the
method says so.
Tool-centric. We do these models because the tool
is good at it.
Dead models. Non-executable models risk being un-
implementable.
Doing documentation models exclusively. Limits
benefits of modeling (where are the real models?)
M.C. Escher, 1961
© 2009 IBM Corporation

16. Model-driven system development models a system-of-
systems in four recursive stages.
Context describes the system and the
people and systems who interact with it Context
(actors).
Usage describes how the actors use the
system is used to produce the results and Usage
purposes of the system.
Realization describes how each usage is
accomplished by a collaboration of system Realization
elements using various viewpoints. and Joint Realization
Execution enables demonstration and proof
of the model through execution.
Execution
16 © 2009 IBM Corporation

17. Integrated system / embedded software development
Design iterations in the “V” development lifecycle
Change Request
Stakeholder Systems
Requirements Engineering
System
Validation
Scenarios (ConOps)
Requirements Plan System
Model / Requirements Repository
Analysis Acceptance
Embedded RT
Test Development
Scenarios
System Functional
Analysis
System
Verification
Plan (Sub-)System
Design Synthesis
Integration & Test
System Component
Architecture Verification
Baseline Procedure
SW Module
Analysis & Design Integration & Test
HW HW Component
Analysis & Design Verification
SW Implementation
& Unit Test
HW Build
© 2009 IBM Corporation

18. Asset-Based Systems Engineering
Reuse: doing more with less
Moving from documentation to re-
creation
Capture engineering and business
value
Engineering asset
– What, How and Why
– Tailor and reuse
– Contribute back to library
Precursor to full product line
approach
© 2009 IBM Corporation

19. Technical Work Management:
Collaboration and Communication
Communication among teams facilitated by
Systems Engineering
Reduce wasted time / error associated with
misunderstandings and incomplete mental pictures
of system requirements Why are small teams so effective?
Build common, shared work products among cross-functional teams
– Model-based
– Shared repositories (requirements, change requests, issues, defects, configurations)
Coordinated, automated workflow tied to shared work products
– Avoid email exchange of work products, multiple versions, confusion
Build on integrated tooling infrastructure
– Limitations of point-to-point integration
– Jazz Platform and OSLC Vision
19 © 2009 IBM Corporation

20. Technical Work Management:
Enabling Effective Collaboration (Why better than email?)
Capture customer
requests & market
Manage driven enhancements Execute
Portfolio & Tests
Product Testing Eco-system
Priorities
Collaboration,
Process, Workflow
Integrated
Capture & Change
manage Management
requirements
Configuration Management
Develop - Model-Driven Collaborate across
System Engineering Development Disciplines
Software Engineering
Electrical Engineering Software
Mechanical Engineering Electrical Shared Repository
Mechanical
20 © 2009 IBM Corporation

21. Collaboration in Action
Team
Awareness
• Shows team members
and their online status
• Shows what they are
working on
Change
Awareness
• Automatically links to
changes if mentioned in
chat
• Drag and drop any work
item or query into chat
© 2009 IBM Corporation21

22. Enabling Collaboration with Models
Collaborate with
stakeholders
View design with commenting
over web
Browse Mark-up diagrams to
design elaborate comments
information
© 2009 IBM Corporation

23. Systems Engineering traditionally floats on a sea of documentation
Missing Format
information inconsistency
Document-centric
approach results in
information dead-
ends Document
No access to
source disparate
Changes make products
documents obsolete application
before they are
approved Overwhelmed
Engineers
working off engineers &
Documents remain misinformed
old versions
necessary for of specs managers
contractual
management and
Document
agreement Documentation preparation for
not up-to-date reviews
23 © 2009 IBM Corporation

24. Automated Document Production
Treat documents as reports of live information
Facilitate re-use and consistency
24 © 2009 IBM Corporation

25. One innovative organization made their models visible to
everyone in the company!
Models first developed on flip charts
Later maintained in automated modeling
tools
Finally, produced on large wall charts for
increased visibility, communication,
collaboration
Became center for discussion across all
teams.
© 2009 IBM Corporation

26. Learn more at:
IBM Rational software
Rational trial downloads
IBM Rational Software Delivery Platform
Leading Innovation Web site
Process and portfolio management
developerWorks Rational
Change and release management
IBM Rational TV
Quality management
IBM Business Partners
Architecture management
IBM Rational Case Studies
© Copyright IBM Corporation 2008. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied.
IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties
or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs,
or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on
market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, and other IBM products and services are
trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.
© 2009 IBM Corporation

27. Copyright information
© Copyright IBM Corporation 2011
IBM Corporation
Software Group
Route 100
Somers, NY 10589
Produced in the United States of America
03-07
All Rights Reserved.
Build Forge, ClearCase, ClearQuest, IBM, the IBM logo, PurifyPlus, Rational, Rational Rose, Rational Test RealTime, Rational Unified
Process, RUP, SoDA, XDE and WebSphere are trademarks or registered trademarks of International Business Machines Corporation in
the United States, other countries or both.
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
Microsoft is a trademark of Microsoft Corporation in the United States, other countries, or both.
Other company, product and service names may be trademarks or registered trademarks or service marks of others.
The information contained in this documentation is provided for informational purposes only. While efforts were made to verify the
completeness and accuracy of the information contained in this documentation, it is provided “as is” without warranty of any kind,
express or implied. In addition, this information is based on IBM’s current product plans and strategy, which are subject to change by
IBM without notice. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this documentation or
any other documentation. Nothing contained in this documentation is intended to, nor shall have the effect of, creating any warranties or
representations from IBM (or its suppliers or licensors), or altering the terms and conditions of the applicable license agreement
governing the use of IBM software.
27 © 2009 IBM Corporation