Transcript IBM Rational Systems Engineering Symposium Orlando Science

Michelle Specht
IBM Software, Rational
Using DOORS for Requirement Reuse
DOORS Enlightenment Series
September 21st, 2012
Innovation for a smarter planet
© 2012 IBM Corporation
Software and Systems Engineering | Rational
Agenda
1
What is asset reuse?
2
3
2
Impact of reuse solutions
How DOORS can help with
requirement reuse
© 2012 IBM Corporation
Software and Systems Engineering | Rational
What is Asset reuse?
 Asset reuse has many names: Product family engineering
(PFE), Domain engineering, Product-Line Engineering (PLE),
Asset Recovery
 It’s applicable to different products in many different ways
 Asset reuse is all about reusing components and structures as
much as possible
– Asset reuse can be defined as a method that creates an underlying Architecture
for an organization's products that is based on commonality which can be
implemented multiple times. This allows various product variants can be derived
from the basic common architecture
3
© 2012 IBM Corporation
Software and Systems Engineering | Rational
What is Asset reuse?
 The reuse of assets is a strategy
 Sometimes product components need to be designed with its
ability to fit into several products, not just one, this is what
makes it difficult, what seems to be best for a single
configuration may not be as useful in a family of products
 Example: ATM machines, when you drive up to am ATM
machine you may wonder why there is braille on the keys?
 Why make more variants then you need
 Example: IKEA, same draw on all models (configurations)
A
4
B
C
© 2012 IBM Corporation
Software and Systems Engineering | Rational
Impact of reuse solutions
Organizations of all types and sizes have discovered that a
reuse strategy, when well implemented, can produce many
benefits—and ultimately give the organizations a
competitive edge. including:
– Improved productivity by as much as 10x
– Increased quality by as much as 10x
– Decreased cost by as much as 60%
– Decreased labor needs by as much as 87%
– Decreased time to market (to field, to launch) by as much as 98%
– Ability to move into new markets in months, not years
5
© 2012 IBM Corporation
Software and Systems Engineering | Rational
Impact of reuse solutions
 CelsiusTech
Nokia Mobile phones
ShipSystem 2000 naval command and control
"Nokia Mobile Phones is the world's largest mobile
phone manufacturer, and they believe that
software product line engineering has helped it
to reach that position." - Unprecedented feature
variation and product to market capability.
CelsiusTech Systems was able to decrease
their software staff from 210 to around 30,
while turning out more, larger, and more
complex ship command and control system
products. The product line approach let
them change the hardware-to-software ratio
for their systems from 35:65 to 80:20.
Nokia was able to increase their
production of mobile phones from
5 to 10 new models per year to
over 30 new models per year.
 References
A. Heie. "Global Software Product Lines and
Infinite Diversity."
6

J. Kuusela. "Architectural evolution: Nokia
Mobile Phone Case Study," Software
Architecture. TC2 First Working IFIP
Conference on Software Architecture
(WICSA1), 1999, 471-8 ISBN: 0 7923 8453 9.

A. Maccari & C. Riva. "Architectural
Evolution of Legacy Product Families," F.
van der Linden (Ed.): Proceedings PFE-4
2001, LNCS 2290, Springer-Verlag Berlin
Heidelberg 2002.

M. Jazayeri, A. Ran, & F. van der Linden.
Software Architecture for Product Families.
Addison Wesley, 2000. pp. 169-176.

Frank Van der Linden, Klaus Schmid, &
Eelco Rommes. Software Product Lines in
Action, Springer, 2007, Ch. 12.
 References
 Len Bass, Paul Clements, & Rick Kazman. Software Architecture in
Practice, 2nd edition, Addison Wesley, 2003, Chapter 15.
 Lisa Brownsword & Paul Clements. A Case Study in Successful
Product Line Development (CMU/SEI-96-TR-016).
 Klaus Pohl, Günter Böckle, & Frank van der Linden. Software Product
Line Engineering, Springer 2005, ch. 21.
© 2012 IBM Corporation
Software and Systems Engineering | Rational
Impact of reuse solutions
 Hewlett Packard
Firmware for computer peripherals
Diesel engine controls
HP reported a 400% productivity
improvement and a 2-7x time-tomarket improvement for a
product line of printers.
Cummins can build and integrate the
software for a new diesel engine in
about a week, whereas before, it took a
year. Their production capability
allowed them to quickly enter and
dominate the industrial diesel engine
market.
 References
7
 Cummins
–
Peter Toft, Derek Coleman, & Joni Ohta. "A Cooperative Model for
Cross-Divisional Product Development for a Software Product Line,'"
Patrick Donohoe (ed.) Proceedings SPLC1, Kluwer Academic
Publishers, 2000.
–
Klaus Pohl, Günter Böckle, & Frank van der Linden. Software Product
Line Engineering, Springer 2005, ch. 21.Mebane, H., Ohta, J. "Dynamic
Complexity and the Owen Firmware Product Line Program,"
Proceeding, SPLC 2007, Kyoto, September 2007, IEEE Computer
Society.
 References
–
J. C. Dager. "Cummins' Experience in
Developing a Software Product Line
Architecture for Real-time Embedded
Diesel Engine Controls," Patrick
Donohoe (ed.) Proceedings SPLC1,
Kluwer, 2000. Page: 23-46. ISBN:
0792379403.
–
Paul Clements & Linda Northrop.
Software Product Lines: Practices and
Patterns, Addison Wesley, 2001.
–
Klaus Pohl, Günter Böckle, & Frank van
der Linden. Software Product Line
Engineering, Springer 2005, ch. 21.
© 2012 IBM Corporation
Software and Systems Engineering | Rational
Impact of reuse solutions
Reuse strategies can be very powerful
 Link 16 is a TDMA-based secure, jam-resistant high-speed digital data link
 BAE Systems (then Singer-Kearfott) put a reuse strategy together which gave them the
edge and they dominated the market in the 80’s
 They divided their terminal into two parts,
– the NICP which was the half which interfaced with the outside world and was the same on all
platforms
– the SICP which was the half which interfaced with the host and contained all the HW and SW unique
to each platform
8
© 2012 IBM Corporation
Software and Systems Engineering | Rational
DOORS supporting reuse

There are several ways DOORS can support artifact reuse
from very simple to very complex

Some simple ways to reuse
1. DOORS attribute can be used to define different configurations
2. Separating common requirements
3. A Framework can be created and reused

Some more complex ways to reuse
1. Requirement branching
2. RPE can be used to generate different version
3. For feature based reuse; IBM Business partner BigLever
4. Using the OO properties of DOORS

9
One or more of these or other techniques can be used to help
promote you organization requirement reuse
© 2012 IBM Corporation
Software and Systems Engineering | Rational
 DOORS attribute can be used to define different configurations
 create a project-specific view for end users to use
10
© 2012 IBM Corporation
Software and Systems Engineering | Rational
Separating common requirements
 Modules can be created to store common
requirements
 Variants can be stored to model for
variant unique requirements
User
Requirements
11
Systems
Requirement
Blue
Common
Green
Variants
Software
Common
© 2012 IBM Corporation11
Software and Systems Engineering | Rational
 Use DOORS to create a framework and this DOORS structure can
be reused
12
© 2012 IBM Corporation
Software and Systems Engineering | Rational
Branching DOORS requirements
13
© 2012 IBM Corporation
13
Software and Systems Engineering | Rational
Branching in DOORS
 If you need to work with multiple copies of a requirement set, one approach is to
create a copy of a baseline
 Links are used to relate the multiple copies of requirements
 Use views to see the development of these different branches
14
© 2012 IBM Corporation14
Software and Systems Engineering | Rational
 Branching a baseline
Software
Common
Rev 2.0
 Software Common 3.0= Software Common II 0.0 to
start
 Links are used to establish relationships
Copy
Software
Common
Rev 3.0
Software
Common
Rev 3.0
15
Create links and link module
Software
Common II
Rev 0.0
© 2012 IBM Corporation15
Software and Systems Engineering | Rational
 Identical at creation, DOORS lets you see both sets of requirements from one
module
Software
Common
Rev 3.0
16
Software
Common II
Rev 0.0
© 2012 IBM Corporation16
Software and Systems Engineering | Rational
 Can edit, add or delete to either side
 Can easily see how both sets of requirements are developing over time
 See changes to originals and branched in one view
VB 3.0+
17
VM 1.0
© 2012 IBM Corporation17
Software and Systems Engineering | Rational
 Can see deletions, additions and changes
 Have the information needed to evaluate the merging of requirements
18
© 2012 IBM Corporation18
Software and Systems Engineering | Rational
Rational Publishing Engine (RPE) for asset reuse
19
© 2012 IBM Corporation
19
Software and Systems Engineering | Rational
Rational Publishing Engine: document automation
 RPE can generate product
variants documents
Source 1
– This is done with the Java
scripting features of RPE
Source 2
 RPE can determine what part of
what modules to extract and
how to format for a family of
products using one set of RPE
templates
 RPE can pull from different
baselines if needed
20
Source 3
…
Source n
© 2012 IBM Corporation20
Software and Systems Engineering | Rational
 RPE can pull data from different
modules to build different
configurations
21
© 2012 IBM Corporation21
Software and Systems Engineering | Rational
22
© 2012 IBM Corporation22
Software and Systems Engineering | Rational
Requirements Engineering for
System and Software Product Lines
with DOORS and Gears
23
© 2012 IBM Corporation
23
Software and Systems Engineering | Rational
 With the IBM Rational DOORS/BigLever Gears Bridge
solution, requirements engineers can efficiently and
effectively manage requirements and product
documentation for an entire product line.
 The solution enables you to create a single,
consolidated collection of requirements for the entire
portfolio.
 Gears provides the abstractions and infrastructure for
software product line engineering
24
© 2012 IBM Corporation
Software and Systems Engineering | Rational
A Gears software production line managing DOORS requirements is comprised of
three key elements:
 DOORS Requirements Assets for a Product Line are configurable
DOORS requirements artifacts, engineered to be reused across the product line.
 Feature Profiles model each product in the portfolio in terms of optional and
varying plug-and-play feature choices specified for the product line.
 The Product Configurator automatically assembles and configures the
requirements assets, guided by the product feature profiles, to produce
requirements for each of the product instances in the portfolio.
25
© 2012 IBM Corporation
Software and Systems Engineering | Rational
IBM BigLever PLE solution:
Improve product line management
IBM Rational Focal Point
Manage requirements diversity
IBM Rational DOORS
Feature-based variation management
and automated production
BigLever Gears SPL Framework
Implement variants with MDD
IBM Rational Rhapsody
Collaborative development
IBM Rational Team Concert
Increase product quality
IBM Rational Quality Manager
26
© 2012 IBM Corporation
Software and Systems Engineering | Rational
Using the OO properties of DOORS
27
© 2012 IBM Corporation
27
Software and Systems Engineering | Rational
Reuse data in multiple documents covering different levels of
the system
 DOORS is an Object Orientation traceability tool. Two key features beneficial to
improving document generation.
 Enhances efficiency with central repository and better visualization of data
 DOORS can hold information used by different documents defining different levels of
the systems, different system components and system configurations:
– System
– Sub-systems
– Components
– Ports
– Signals
28
System
Subsystem
Component
Port
Signals
© 2012 IBM Corporation
Software and Systems Engineering | Rational
HTS Config A
Home Theater System
(HTS) Configuration
Display
Sub-System
HTS Config B
Source inputs
Receiver
Sub-system
Sub-system
Audio
Sub-system
HTS Config C
29
© 2012 IBM Corporation
Software and Systems Engineering | Rational
Home Theater System Configuration
Display
Sub-System
 Multiple levels of documents
 Multiple configurations
Source inputs
Receiver
Sub-system
Sub-system
Audio
Sub-system
Sub-System
30
© 2012 IBM Corporation
Software and Systems Engineering | Rational
 Start by defining each level of the system as you would a class with it’s associated
attributes and behavior
– Level 1 Home Theater System
– Level 2 Home Theater Sub-Systems
– Level 3 Components
– Level 4 Interfaces
– Level 5 Signal data
31
© 2012 IBM Corporation
Software and Systems Engineering | Rational
Sample Scenario
Detailed Overview
 We defined the levels and created a View to
represent each Level with the associated data
(attributes)
L4 HT Interface Level
Object ID
Sub-System
Interface Name
Interface Function
 Each object used to define an interface will be
added at level 4
Interface Type
Source
Destination
Location
32
© 2012 IBM Corporation
Software and Systems Engineering | Rational
Sample Scenario
Detailed Overview
 Each object used to define the details of the component will be added at level 5
 This allows any common data from the connector level to flow down to the signal level.
L4 HT Interface Level
L5 HT Signal Detail Level
Object ID
Object ID
Sub-System
Component
Interface Name
Pin Assignment
Interface Function
Signal Description
Interface Type
Source
33
L5 inherits
data from L4
Interface Function
Signal Type
Destination
Source
Location
Destination
© 2012 IBM Corporation
Software and Systems Engineering | Rational
Sample Scenario
 Layered interfaces
 Below is the level 4 interface view
– Increased to show level Five information, and some level 5 Signal Details attributes were added, you can see how some of
the information gets inherited.
 Changing the destination in the Level 4 interface level view all of the destinations for objects in the signal view
for that interface will get updated as well
Lvl 4
Lvl 5
34
© 2012 IBM Corporation
Software and Systems Engineering | Rational
Sample Scenario
 To setup for multiple configurations all you need to
do is setup attributes at the levels you need
L3 HT Interface Level
Object ID
Component
 This will allow different configurations to share
common data by hiding unneeded data
manufacturer
Model Number
HDMI 7 Channel
HDMI 5 Channel
Legacy 7 Channel
35
© 2012 IBM Corporation
Software and Systems Engineering | Rational
Rational Publishing Engine
DOORS Module View
36
Document Table
© 2012 IBM Corporation
Software and Systems Engineering | Rational
DOORS Next
37
© 2012 IBM Corporation
37
Software and Systems Engineering | Rational
Current DOORS
Resource model
DOORS Next Generation
Module 1 Resource model
t1, t2
r1, r2, r3
Module 1
Types: t1, t2
Requirements: r1, r2, r3
Module 2
Module 2
Types: t1, t3
Requirements: r1, r2, r4
Module 3
t1, t3
r1, r2, r4
Types: t1, t2, t4
Requirements: r1, r5, r6
Module 3
When a type or requirement is needed in
multiple modules, copies must be made of each
and maintained
t1, t2, t4
r1, r5, r6
Resource Storage
Module 1
Module 2
Module 3
t1
t2
t3
t4
User Requirement type
System Requirement type
r1
r2
r3
r4
r5
r6
Information is not stored within a module, only
referenced from the module. Types and
requirements can be used in multiple modules but
stored in one place – improves consistency
38
Last Updated: 18 May 2012
© 2012 IBM Corporation
Software and Systems Engineering | Rational
DOORS Integrations for PLM
Change
Team
Concert
Product Line Engineering Variant
management for DOORS
Rhapsody
DOORS
Eclipsed based System Modeling
using SysML
Integrate DOORS with PDM
Focal Point
Product Portfolio Management
39
© 2012 IBM Corporation
Software and Systems Engineering | Rational
40
© 2012 IBM Corporation
Software and Systems Engineering | Rational
The NEW VRUG: Virtual Rational Systems Engineering User Group
About the NEW
Virtual Systems
Engineering User
Group
Next meeting:
September 27th
The purpose of the Systems
Engineering Virtual Rational User
Group is to facilitate information
sharing and group discussions
around the topics of systems
engineering and how IBM
Rational methods and tools can
be applied in these endeavors.
To join, please go to: VRUG: Systems
Engineering
Any questions please contact: Michelle
Specht [email protected]
41
© 2012 IBM Corporation
Software and Systems Engineering | Rational
VRUC: Virtual Rational User Community
VRUC: Systems Engineering
September 27nd, 12 noon EST
How to Capture the Hidden Value Within Your Engineering Data - RELM
Ben Williams - Senior Product Manager - Rational Systems Engineering
 Customers demanding evermore functionality. Shorter market windows. Compliance demands. It’s more difficult
than ever to create products that stand out among the competition, yet are still profitable. Next generation
products require next generation development techniques, such as systems engineering, to leverage knowledge
and drive innovation earlier in the development process. Most organizations actually have the engineering data
required to make this happen, but simply can’t access it or make sense of it due to overwhelming complexity and
lack of integrated views
 Join IBM expert Ben Williams to learn how you can visualize, analyze, and organize the value hidden within your
complex web of engineering data—helping you more efficiently define, design, and validate smarter products.
 Any
questions please contact:
.
Carson Holmes: [email protected]
or Michelle Specht [email protected]
42
© 2012 IBM Corporation
Software and Systems Engineering | Rational
VRUC: Virtual Rational User Community
VRUC: Systems Engineering
October 25th, 12 noon EST
How to Capture the Hidden Value Within Your Engineering Data
Dan Ani – GEBS Reporting Arena
 IBM Rational Publishing Engine automates the generation of documents for ad hoc use, formal reviews, contractual
obligations, or regulatory compliance improving quality and productivity while reducing risk and cost.
This talk discusses how to use RPE to generate large-scale reports across the System Development Life Cycle.
The goal is to create a cross product report that will document all the system requirements (Rational DOORS)
tracing all the work items (Rational Team Concert) that implement each requirement and all the test cases (Rational
Quality Manager) that validate that requirement.
You will learn how to design report templates, how to create and configure document specifications, using existing
templates, and finally how to share resources and generate documents online using the Reporting Arena Web
Publisher (Web Client for RPE – Ready for Rational Software).
 Any questions please contact:
Carson Holmes: [email protected]
or Michelle Specht [email protected]
43
 For our current RPE users:
 If you have anything you would like to see Dan demo which would improve your
current implementation, please contact Michelle Specht with your request
© 2012 IBM Corporation
Software and Systems Engineering | Rational
http://rational-ug.org
44
© 2012 IBM Corporation