Post on 27-Mar-2015
Introduction to Product Family Engineering
11 Oct 2002Ver 2.0
©Copyright 2002 Vortex System Concepts
2
Product Family EngineeringOverview
• Project Engineering vs. Product Engineering• Requirements Variability: The Beginning of
Product Families• Architecting: Project Adaptations• Product Families: Team Behavior• State of the Discipline
11 Oct 2002Ver 2.0
©Copyright 2002 Vortex System Concepts
3
Product Family Engineering Project Engineering vs. Product Engineering
• Project Engineering– Devoted to satisfying an end customer– Typically oriented toward one customers needs– Team will do anything for the good of the customer
as long as it’s within the current budget and scope.
• Product Engineering– Devoted to satisfying a market need expressed by
multiple end customers– Team considers alternative strategies to satisfy as
many customers as possible, yet stay within budget and scope
11 Oct 2002Ver 2.0
©Copyright 2002 Vortex System Concepts
4
Project Engineering vs. Product Engineering
• Salvage Engineering– Does your engineering development activity work
in a Salvage Yard?– Do you manage projects by piecing together
previous projects?– Do you claim to have a Product, but aren’t quite
sure what the “product” can do, because every instance is different?
• Salvage engineering is a key characteristic of a project oriented business
11 Oct 2002Ver 2.0
©Copyright 2002 Vortex System Concepts
5
Project Engineering vs. Product Engineering
Salvage Engineering
• Salvaging– Copy and paste– Tendency to reinvent– Focus on unique customer needs with little or no
unified product vision
• Sharing– Projects share common product definition - link to
product intellectual property– Focus on product definition across diverse
customers needs, while also enabling custom tailoring
11 Oct 2002Ver 2.0
©Copyright 2002 Vortex System Concepts
6
Product Family Engineering
Requirements Variability The Beginning of Product Families
– Do you manage documents?– Or do you manage requirements/ intellectual
property?
• PFE: Projects share content, not documents
Common functions may be shared withother components. Those same functionsand their requirements would be publishedin a requirements document for eachcomponent.
This is the foundation of intellectual propertyreuse: sharing common information betweenproducts.
11 Oct 2002Ver 2.0
©Copyright 2002 Vortex System Concepts
7
Product Family Engineering
Requirements Variability
• Variation - Understanding product differences and similarities
• Capture Project Differences– Project attribute - multi-enumerated value
• <Blank> = Common Reqt• Project A• Project B• Project C, etc• N/A = Not Applicable to any project - retired
or future
11 Oct 2002Ver 2.0
©Copyright 2002 Vortex System Concepts
8
Product Family Engineering
Requirements Variability
• Understand the differences - why?– Feature attribute - multi-enumerated value
• Different integration needs• Different security needs• Different capability needs• Different performance needs
– Capture why the requirement/ IP is different
11 Oct 2002Ver 2.0
©Copyright 2002 Vortex System Concepts
9
Product Family Engineering
Requirements Variability
• Understand timing - now, later, obsolete?– Currency attribute
• Current• Obsolete• Future Enhancement
– Retire outdated/ no longer supported definition– Capture thoughts on future product upgrades– Understand what is being offered today
11 Oct 2002Ver 2.0
©Copyright 2002 Vortex System Concepts
10
Product Family Engineering
Requirements Variability
DOORS Module
Feature BProject 1 w/
Feature A & B
Project 2 w/Feature A
Feature A
Feature A
Feature B
Common
Project 1
Project 1Project 2
Project 1
Project 1Project 2
Common
Project filtration on projectattribute set to project nameand common productfunctionality
11 Oct 2002Ver 2.0
©Copyright 2002 Vortex System Concepts
11
Requirements Variability
Publishing
• Project Documentation - the by-product– Custom tailored for specific customer needs– Use filters to create reports
• Project = My Project or Common• Feature = my set of selected features• Currency = Current
• Upgrade reports– What opportunities exist for ECPs and upgrades?
• Report new features not currently selected• Find “Obsolete” definition still lingering in deployed
products• Discover “Future Enhancements” for opportunity
11 Oct 2002Ver 2.0
©Copyright 2002 Vortex System Concepts
12
Requirements Variability
The Next Project
• Feature Exploration– New projects filter on and explore product features
- which features address your unique customer needs?
– Apply Project attribute to those feature that are shared
– Copy requirement object when customer needs call for differences
– Capture new difference in feature set
11 Oct 2002Ver 2.0
©Copyright 2002 Vortex System Concepts
13
Product Family Engineering
Architecting: Project Adaptations
• Requirements commonality– Share common problem definition
• Architecture commonality– Share common solution definition
• Individual projects have unique design and architecture– Select reusable components– But structure of solution may differ
11 Oct 2002Ver 2.0
©Copyright 2002 Vortex System Concepts
14
Product Family Engineering
Architecting
• Components have standard interfaces– Similar components must adhere to the same
interface standard
• Integration of components is unique to project– Similar solution may be achieved with similar
components in a different structure
• Product Family Architecting– Most effective when interface standards applied
between all views of the architecture
11 Oct 2002Ver 2.0
©Copyright 2002 Vortex System Concepts
15
Product Family Engineering
Architecting: AllocationLo
gica
l
Sof
twar
e
Ele
ctric
al
Mec
hani
cal
Civ
il/ S
truc
tura
l
Allocation across architectural views
11 Oct 2002Ver 2.0
©Copyright 2002 Vortex System Concepts
16
System Architectural Representation
Elements of complete picture of a system architecture
Lo
gic
al R
epre
sen
tati
on
Ph
ysic
al R
epre
sen
tati
on
Str
uct
ura
l R
epre
sen
tati
on
Syste
m
Subsyst
em
Componen
t
Hierarch
y
Abstra
ctio
n
Realization
Function
Service
Support
FunctionTask
ObjectivePurposeActivity
RoleMission
CapabilityPrincipalPrimary
Application
11 Oct 2002Ver 2.0
©Copyright 2002 Vortex System Concepts
17
System Architecture and Design
Interface Definition
Application
Software Services
Datalink
Physical
Avionics SystemArchitectural Layers
Application
Presentation
Transport
Datalink
Physical
OSI IndustryModel
2a
4
6
InterfaceDefinition Layers
1. Application Interface Definition:Operational InteractionFunctional Flow
2a. Software Services Interface Definition:Application Programmer Interfaces
2b: Application Data Allocation InterfaceDefinition
Sockets, Ports, Data ElementAssignment, Data Structure
3. Transport Protocol Interface Definition:Data Structure/ Label InformationData Communication Protocol
4. Processor & Device Driver ServicesInterface Definition:
Device DriversAddress/ Register Assignment
5. Datalink Interface Definition:Signal/ Bus Characteristics
6. Electromechanical Interface Definition:
Connector/ Pin Allocation
7. Mechanical Interface Definition:Standard ConnectorsInstallation Control Drawings
1
3
5
7
Session
Network
2b
11 Oct 2002Ver 2.0
©Copyright 2002 Vortex System Concepts
18
Product Family Engineering
Requirements Variability with Architecting: Allocation Inheritance
11 Oct 2002Ver 2.0
©Copyright 2002 Vortex System Concepts
19
Product Family Engineering
Product Family: Team Behavior
• Never Delete IP Objects– May be shared by other projects– Use attributes to tailor out
• Apply all current projects to object, except yours
– Add new IP at discretion, adding just your Project attribute
• Write IP with reuse in mind– Don’t reference project name– Don’t reference specific components of design– Don’t make long lists in sentence form – Do bulletize, use tables, etc.
11 Oct 2002Ver 2.0
©Copyright 2002 Vortex System Concepts
20
Product Family Engineering
Product Family: Team Behavior
• Don’t modify baselined objects– Current projects are already sharing that particular
variation• If possible, coordinate with all projects for enhancement• Otherwise,
– Copy current IP object
– Apply changes to new object
– Flag new object for your project
– Flag old object for all other projects
– Flag old object as “obsolete”
11 Oct 2002Ver 2.0
©Copyright 2002 Vortex System Concepts
21
Product Family Engineering
Product Family: Team Behavior
• Managing for reuse, not a salvage operation– Need a Product Family Manager - not a Project
Manager• Champion for product definition• Keeper of the roadmap• Enforcer of discipline• Advocate for Product - better definition for all vs
expedient definition for one
11 Oct 2002Ver 2.0
©Copyright 2002 Vortex System Concepts
22
Product Family Engineering
State of the Discipline
• Version Management – Sharing IP causes unique problems of version
management• When do you baseline shared data?• How do you track changes within a project vs changes
that may apply across several projects?
• Document Management Mentality vs. Architectural Models & Information Management– Management focus on paper products– Tool usage still document based
11 Oct 2002Ver 2.0
©Copyright 2002 Vortex System Concepts
23
Product Family Engineering
State of the Discipline
• Architecting– Limited tools
• Not addressing multi-dimensional views of architecture• Not addressing interface standardization between views• Not addressing relationship of requirements to
architecture• Not addressing component commonality vs. architectural
adaptation
11 Oct 2002Ver 2.0
©Copyright 2002 Vortex System Concepts
24
Summary
• Product Family Engineering– Engineering products for an extended family of
products
– Products derived from a common basis – Custom tailoring for unique customer needs
– Sharing Product IP - no Salvaging– Understanding variability & architecture