Introduction to Product Family Engineering. 11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 2 Product Family Engineering Overview Project Engineering

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


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


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


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


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


7


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


8



• 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


9



• 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


10



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


11


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


12


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


13


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


14


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


15


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


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


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


18


Requirements Variability with Architecting: Allocation Inheritance

11 Oct 2002Ver 2.0


19


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


20



• 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


21



• 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


22


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


23


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


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

Documents

Introduction to Product Family Engineering. 11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 2 Product Family Engineering Overview Project Engineering