2018 ibm agile engineering summit - spotlight presentation

IBM Watson IoT / © 2018 IBM Corporation
What if you could have your
own expert systems
engineering assistant?
—
Stella Liu,
Offering Management
Kevin McHugh,
Services Lead

Agenda
–
Lessons from the Renaissance
The Principal Engineer’s Modern Dilemma
Hiring Watson
Applying Watson to Engineering

Leonardo da Vinci [Public domain], via Wikimedia Commons

Automotive
1M Lines of code in new Ford
F-150 Truck from 155K in
2003
40% of total IT Budget spent
on QA and testing by 2019
90% of F-35 fighter jet
functionality is software
driven
Electronics
12M lines of code in
mobile phone
1.4M lines of code in
robotic surgical system
The need to keep up is more critical
than ever as product development
increases in complexity
Aerospace and Defense

Engineering knowledge
has become big data
Data increasing
Capacity and
ability to learn
and adapt
TIME
RATE

Principal
Engineer
Job Description
• Leads teams of
engineers on a
variety of projects
• Mentors junior and
senior engineers
• Understands all
components in a
system
• Ensures each
component
behaves as
required and
interacts properly
• Applies knowledge
and principles to
create innovative
solutions
Minimum of 12
years of
engineering
experience…
Minimum of 10
years industry
experience…

What we expect…
Expert in their
engineering field
Expert at engineering
Expert with
requirements, Design,
Test, Change Control
etc. etc.
Share and apply
experiences with others
Pass on knowledge to
next generation of
engineers
Understands the big
picture
Understands the
tiniest detail
Tireless
Consistent accuracy
Ensure all teams
adhere to various
standards and
regulations
Do everything

Be everywhere

0
100
200
300
400
500
600
700
800
Cost of being imperfect… we all are
RelativeCosttoRepair
The cost to fix software defects rises exponentially
with each successive phase of the project life cycle
(2004) NASA Publication
Design Build
Test Operations
700
49
12
52
Requirements

But we know it’s not
possible

AI is the application of knowledge
Capacity and
ability to adapt
TIME
RATE
Knowledge
and capability
Data increasing

Let’s hire Watson

AI contrasted with the human mind

When do your engineers have to
cope with massive amounts of
information?

What tasks do your engineers
have to do today that are
manual, consistent and
repetitive?

Where are there gaps of
knowledge in your organization?

Who are the users? And their intents?

What data do they use to make decisions?

What AI models should we use to process that information?

IBM Watson Visual Recognition
• Shortens the claims cycle for certain damage assessments by more than 95%
• Enriches client experience through personalized conversation flows and real-
time answers
• Enables damage assessment advisors to focus on more complex damage claims
Solution:
Autoglass built the world’s first automated vehicle body damage
assessment and quote generation system. Using the IBM Watson Visual
Recognition service, the system analyzes the photos that customers upload
when they submit a body damage claim, applying the same classification
logic as Belron’s highly experienced damage assessment advisors.
“We’re able to automate nearly half of our body damage claims
assessments using image recognition technology, and we expect that
rate to get even higher.”
—Dafydd Hughes, IT Manager at Autoglass BodyRepair

- IBM Watson Knowledge Studio
- IBM Watson Discovery
- IBM Watson Assistant
- IBM Watson Explorer
- IBM Cloud
• 38,000 Woodside documents were used to train the solution — this would take a
human over five years to read
• 30 years of practical engineer experience at the fingertips of all Woodside
employees
• 75% decrease in time employees spend searching for expert knowledge
Solution::::
Working with Watson, Woodside Energy built a customized tool
that allows its employees to find detailed answers to highly
specific questions—even on remote oil and gas facilities.
“It’s helped our engineers get up to speed very quickly on what
has already been done and how the projects were managed in
the past. We can learn from the past and there’s no need to
reinvent the wheel.”
— Caitlin Bushell, Graduate Process Engineer at Woodside

Our approach…
Watson
Services
Customer
Solution
+ +? ?

Our approach… Pre-train Watson for you
Watson
Services
Customer
Solution
+ +? ?
Watson
Services
AI for Engineering
Offering
Architecture and
pre-built assets
Public Domain
Data
+ +

Market
Analytics
System
V & V
System
Test
System
Requirements
System
Design
Deploy or Release
to Mfg
Customer
Requirements
Operations and
Maintenance
Implementation
Electrical /
Electronics
Design
Mechanical
Design
Lean Software
Engineering
Continuous
Engineering
Component
test
Component
Design
The vision: Watson will be embedded inside engineering workflows…
Project Cambridge:
Requirements Quality
Analysis
Intelligent Code Re-Use
Test Case
Quality Analysis
Automatic Model Generation
from Unstructured Data Defect Prediction

Increased complexity of product development and
impact on requirements management:
scale, compliance and multiple stakeholders
Increasing
presence
of software
Inter-disciplinary
Increasing
complexity
Smarter
products and
systems
10 million lines
of code in
GM Volt
Mars Rover Curiosity had
16000+ requirements
Multiple vendors
and supply
chain contractors
Smarter Products & Systems
Complex
Requirements
Increased
number of
stakeholders
Increased compliance and
regulatory requirements
Effective requirements management
Collaboration Across the Value Chain

IBM Requirements Quality Assistant
New Watson capability embedded inside DNG and DOORS…
⎯ Removes risk and ambiguity in the requirements authoring
phase out-of-the-box by using AI (Watson Natural Language
Understanding
⎯ Pre-trained to detect key quality indicators designed to be
consistent with the INCOSE Guidelines for Writing Good
Requirements
⎯ Authors receive coaching from Watson to improve the quality of
the requirement as it is being written
Enterprise benefits (400 engineers example)
⎯ Reduce the cost of defects by 60% to save $3.9M
⎯ Reduce cost of manual reviews by 25%
⎯ Retain engineering expertise for junior engineers

The subject of a requirement statement must to be appropriate to the level to which it refers. Requirements referring
to the business level therefore have the form “The <business> shall ...”; those referring to the stakeholder level have
the form “The <stakeholder> shall ...”; those referring to the system level have the form “The <system> shall ...”;
requirements referring to the subsystem level have the form “The <subsystem> shall ...”; and requirements referring
to the component level have the form “The <component> shall ...”. As a general rule, requirements stated at a
particular level should refer only to that level—that is, the business requirements refer to the business level,
stakeholder requirements refer to the stakeholder level, system requirements refer to the system level, subsystem
requirements refer to the subsystem level, and component requirements refer to the component level. In some
cases, however, a higher level may wish to be prescriptive at a lower level. For example, it may be important for a
business to mandate that the new aircraft under development must utilize a particular engine (perhaps for support
reasons) in which case they may make a statement at the business level that refers to an entity at the subsystem
level, Therefore, any level of the organization can state (at that level) requirements that refer to two levels: to that
level, as well any lower level (should there be a good reason to do so). Consequently, regardless of the level at which
the requirement is stated, the subject of a requirement statement must be appropriate to the level to which it refers.
To continue our aircraft example above, although the majority of requirements at the business level will begin with
“ACME Aircraft Company shall ...”, the business may therefore wish to state at the business level a requirement
referring to the subsystem level regarding the engine “The Engine shall ...”. Similarly, the verb of a requirement
statement must be appropriate to the subject of the requirement at the level it is stated. Requirements with the
verbs “safe”, “support”, “process”, “handle”, “track”, “manage”, “Áag”, etc. are too vague and thus ambiguous and
unveriÀable unless these functions are decomposed into speciÀc sub-functions that are intended by the writer. At
the business level, for example, the use of a verb such as “safe”, may be acceptable as long as it is unambiguous at
that level, decomposed at the lower levels, and is veriÀable at the level stated. Unacceptable system requirement:
“The User shall ..........” {This is unacceptable because the requirement should be on the system, not the user or
operator of the system. This wording is often the result of writing requirements directly from user stories, without
doing the transformation of the user need into a system requirement. Ask, what does the system have to do so that
the user need can be achieved?} A set of requirements that has been documented, agreed-to, and baselined at one
level will Áow down to the next level as shown in Figure 1. At each level, the requirements are a result of the
transformation process of the needs at that level as well a result of the elaboration (decomposition and/or
derivation) of the requirements from the previous level. As such, SyRS or SyRD requirements are either decomposed
from (that is, made explicit) or derived from (that is, implied) by the requirements of the system OpsCon and StRS or
StRD. Consequently, several systems, each described by the system OpsCon and SyRS, may be deÀned to meet the
capability required by the StRS. The same is true at the subsystem level, where the subsystem requirements may be
either decomposed or derived from the subsystem OpsCon and SyRS or SyRD. In all cases, for each
level shown in Figure 1, the set of requirements can be traced back to the needs from which they were transformed
as well as the requirements at the previous level from which they were either decomposed or derived. How
requirements are expressed differs through these levels and, therefore, so do the rules for expressing them. As
requirements are developed - and solutions designed - down through the levels of abstraction, we expect
requirement statements to become more and more speciÀc. At the highest, governance level, the ideal requirement
is not speciÀc to a particular solution, and permits a range of possible implementations or solutions. It is important
to note that the form of requirements at one level may not be appropriate for another level. For example, at the
business management level, there may be a requirement that all products shall be “safe” or of the “highest quality”
or projects shall develop products using “best practices” deÀned by organizations like INCOSE, Project Management
Institute (PMI), or Capability Maturity Model Integrated (CMMI). At the business management level, they may deÀne
process requirements for implementing some capability level of Model Based Systems Engineering (MBSE) or Agile.
While these are poor system level requirements, it is appropriate for the Business Management level. At the system
level, more speciÀc safety and quality requirements will be developed for that speciÀc system. These requirements
will then be allocated to the system elements at the next lower level. The Programs or Projects responsible for
developing the systems will develop speciÀc requirements for how they will implement the management and
systems engineering process requirements deÀned

⎯ Grades requirements against a
criteria that was designed to be
consistent with the INCOSE
Guidelines for Writing Good
Requirements
⎯ Pre-trained to detect 10 quality issues
⎯ Unclear actor or user
⎯ Compound requirement
⎯ Negative requirements
⎯ Escape clause
⎯ Missing units
⎯ Missing tolerances
⎯ Ambiguity
⎯ Passive
⎯ Incomplete requirements
⎯ Unspecific quantities

- Identifies exactly what’s wrong
with the requirement
- Displays the issue to the
requirements engineer

⎯ Learns from the requirements
engineer
⎯ Becomes “smarter” over time

IBM Test Case Quality Assistant (Services Offering)
New Watson capability integrated with RQM…
⎯ Score the content of your Test Cases against a
standard followed by your organization
⎯ Increase the training speed for your new
employees or contractors
⎯ Standardize the content and quality of your Test
Cases
⎯ Ease shifting resources between projects

IBM Test Case Generator Assistant (Services Offering)
New Watson capability integrated with RQM and DNG…
⎯ Generate sections of RQM Test Cases such as Test Design,
Preconditions, and Expected Results
⎯ Raise the quality of the Test Cases
⎯ Speed the authoring phase of Test

Opportunity to engage prior to GA though the Paid Early
Access Program - customize the model for your needs
Evaluate
2 Weeks 2 Weeks 2 Months
Prepare Customize
Configured, trained and delivered in 4 weeks
Off-the-
Shelf
Offering w/
Customer’s
Model
Priced and pre-approved as part of the program Follow-on, not part of program
Option to do additional
complex customization
work with lab services

Recruiting for Usability Tests
Anybody who authors requirements in DNG.
Novices to experts (in writing requirements, and in
using DNG)
We are looking for requirement authors to help us
evaluate Requirements Quality Assistant.
Requirements Quality Assistant uses IBM Watson
to provide feedback on the quality of individual
requirements, based on a set of industry standards.
Requirements Quality Assistant
Who:
Week of Nov 5 and 12
(Subject to change based on development progress)
When:
Participants will use the tool to perform basic
tasks and will be asked to share feedback
and answer questions.
• No advanced preparation is needed.
• Sessions are with 1 participant at a time.
• All sessions are remote using web-conferencing.
• Each session will last about 1 hour.
What:
If interested, contact:
Kirk Grotjohn (kgrot@us.ibm.com) or
Leigh Haith (IoTDPP@us.ibm.com)

Find out more at
the AE Summit
Room Calvert Tuesday - 13:15 – 14:30
Using Cognitive Computing to Elevate Requirements
Quality and Auto-generate Test Cases
Room Capitol Wednesday – 11:15 AM to 11:45 AM
Technical deep dive on near term applications of AI
to engineering
Room Capitol Wednesday – 1:15 PM to 1:45 PM
Technologies and use cases for applying AI to
accelerate engineering processes
Room Capitol Wednesday - 2PM - 2:45 PM
Examining Opportunities to Apply AI to Engineering

2018 ibm agile engineering summit - spotlight presentation

More Related Content

Similar to 2018 ibm agile engineering summit - spotlight presentation

More from M Kevin McHugh

Recently uploaded

2018 ibm agile engineering summit - spotlight presentation