A Framework for Software Product Line Practice

Antti RaunioMartti JanssonSami HänninenMaria PirhonenAri Manninen

ContentsIntroductionSoftware EngineeringTechnical ManagementOrganizational ManagementCASE – CelsiusTech SystemsConclusion

What Is a Product Line A product line is a group of products sharing a common, managed set of features that satisfy specific needs of a selected market or missionProduct line = strategic reuseProduct lines promise to become the dominating production software paradigm of the new century.

Key Concepts IProduct line

A group of products sharing a common, managed set of features that satisfy specific needs of a selected market or mission area

Product familyA group of systems built from a common set of assets

Core assetA software artifact that is used in the production of more than

one product in a software product line. A core asset may be an architecture, a software component, a process model, a plan, a document, or any other useful result of building a system.

Key Concepts IIDomain

An area of knowledge or activity characterized by a set of concepts and terminology understood by practitioners in that area

Product Line ScopeDescription of the products that will constitute the product line

Product Line ArchitechtureDescription of the structural properties for building a group of related

systems (i.e., product line), typically the components and their interrelationships. The inherent guidelines about the use of components must capture the means for handling required variability among the systems. (Sometimes called a reference architecture)

How Does the Product Line Work

New product is formed by taking applicable components from the base of common assets Components are tailored and new components are added if necessaryAssembled under the umbrella of a common, product-line-wide architecture.The predominant activity in product creation is integration rather than programming

Why To Have Product Lines

Commonalities shared by the products can be exploited to achieve economies of productionBuilding sets of related systems from common assets can yield remarkable quantitative improvements in productivity, time to market, product quality, and customer satisfaction

PL Essential ActivitiesDevelopment processCore Asset DevelopmentProduct DevelopmentManagement

PL Essential ActivitiesCore Asset Development process

PL Essential ActivitiesProduct Development Process

PL Essential Activities Management

Plays a critical role in the successful fielding of a product lineActivities must be given resources, coordinated, and supervisedOrganizational management is responsible for the ultimate success or failure of the product line effort

Product Line Practice Areas

Software engineering practice areas Technical management practice areas Organizational management practice areas

Software EngineeringPractices necessary to apply the appropriate technology to create and evolve both core assets and products

Understanding relevant domains/domain analysisArchitechture definitionArchitecture evaluationSoftware system integration Cots utilization/ Component developmentRequirements engineeringTesting

Domain analysisIncludes:

Identifying the areas(domains) that are useful for building the product(s)Identifying the re-ocurring problems and known solutions within these domainsCapturing and representing this information in ways that allows it to be communicated to the stakeholders and used/reused across entire effort

Domain AnalysisWill produce a domain model which helps to determine:

Common capabilities across systems in the domains and what variations are presentHow subsets of capabilities might be packaged togetherConstraints(e.g. standards, legal restrictions, business restrictions)Which assets typically constitute members of domains

Domain model is the baseline for the architecture definition!

Inputs for a PL architecture Definition

Domain modelWhat is the playground

Product requirementsUses PL scope as an input

PL ScopeSets boundaries for PL

Existing assetsWill be analysed and generalized for use in the product line

Architecture DefinitionPeculiarities in PL architecture

PL architecture is concerned with a set of explicitly allowed variations which, when instantiated, are products of PLIntegration has a greater role because of the number of products produced (integrated from core assets) in product lineUse span of the architecture is long

Architecture has to be flexible enough to enable possible changes in it ( in protocols, platforms )

Architecture EvaluationArchitecture is the key succes factor for the the Entire product line!Evaluation will have to focus to variation points, that is, points in the arcitecture that will vary from product to productEvaluation can lead to an expansion of the product line scope. Architecture may also have to be modified to be more sufficient.

Software System Integration

SSI refers to the practice of combining individual software components into an integrated whole

Components-> subsystems ->products

Integration is considered in the development of the production plan and PL architecture

Software System Integration

Cost of integration will decrease over completed projects/product

Interfaces have been defined and tested

Architecture has been fixed

In PL, emphasis is placed on planning for integration.

Component developmentA software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties[Szyperski 98].

For the purposes of product lines, components are the units of software that go together to form whole system(products)

Component DevelopmentThe product line architecture shows variation points which are implemented using appropriate componentsThe challenge of the component development is to produce reusable and adaptable components that will fill the technical requirements raised from variation needs

COTS UtilizationCommercial Off-The-Shelf -assets

Can be, for example, components, frameworks or architectures

Both COTS and other assets should satisfy the variation needs inherent in the product lineCan set constraints for the architecture

E.g. Use of specific component model(DCOM, Java Beans, CORBA). Different models will not interact easily

Software development in product line

Parts of the product line Overall architecture

FrameworksComponents

Process to integrate frameworks and components to a whole products within defined architecture

Example of a Product Line Architecture

Product Line Architecture

Server architecture

Web Container EJB Container

Client Architecture

Databases

App.layer Service layerBusinesslogic

Businessdata

Requirements engineeringDefines products and features of the products in the PLReqs. common across the entire product family constitute an important core assetThe PL scope and reqs. are tightly coupled and will evolve together

Requirements map the stakeholders’ needs to the evolving scope

TestingPL architecture supports testing by:

Enabling creation of test interfaces that allow special access to the functionality of the subsystems

These types of interfaces and functionality are often too resource intensive to be provided in a one-off systems

Enabling creation of test cases that are reused and used across the organizationTest architecture can be defined and included in the PL architecture so that test component(s) can become a core asset for a PL

Example of Test Core Asset

Product architecture

Core Asset for internal self-testing

Technical ManagementManagement practices necessary to engineer the creation/acquisition and evolution of the core assets and products

Configuration managementMeasuring the product lineMake/Buy/Mine/CommisionProduct line scopingTechnical PlanningTechnical risk managementTool Support

Configuration Management

PurposeEstablish and maintain the integrity of the products of the software project throughout the project's software life cycleConfiguration items of a project are first identified. Then changes to them are controlled and recorded.

ObjectivesHigher quality with less effortMinimize risk of errorsEliminate confusion among team members

Configuration management is

critical for product line practice!

CM Supported TasksParallel DevelopmentDistributed EngineeringBuild and Release ManagementChange ManagementEnvironment ManagementProcess ManagementObject and Repository Management

tabsetPanel

Component Change Management

Changes can effecta product specific componenta component used in many productsa core asset (most complicated)

Asset in use 1

Asset in use 2

Asset in use 3

Measuring the product lineEssential for product line decision makingSteps

Identify product line goalsFind indicators for goalsDefine supporting measuresEstablish performance baseline

Measurement activities should be planned and managed!

What should be measured?

Core assetsNumber and typeCost of developing, evolving and sustainingReuse factors (actual and estimated)Quality characteristics

Product developmentNumber of products and featuresComplexity of requirementsProduct specific reuse factor and development effort

Challenges for measurement

Up-front investment on measurementBoth the core assets and the application development must be measuredProduct lines are a new practice -> validity of metrics have not been demonstratedMeasurement must consider the needs of various stakeholders

Ways to Attain AssetsMake – Create the asset in-houseBuy – Aquire off-the-self-componentsMine – Develop assets from legacy systemsCommision – Asset is built by a third party especially for the organization

How to choose?

Decision

Quality CostAlignement

with PLFlexibility Maintainability Schedule

Requirements Architecture

Product line scopingScope defines product line’s

ProductsGoalsFuture direction

Scope also describesMarket driversNature of competing effortsOther business goals for product line

Product Space

Product Space

product 1

product 3

product 7product 6

product 2

product 4

product 8

product 5Asset a

Asset b

Asset c

Product Line:

product 2product 5product 8

Asset Base:

.

.

.

How To Scope?Examine existing productsConduct a workshop with stakeholdersCreate

Context diagram – What affects the product lineAttribute/product matrix – How products in the PL differ from each otherScenarios – Find similarities in products

Technical PlanningTechnical planning is the process by which plans are createdPL requires special plans for

Core asset developmentHow assets are created, tested, maintained, changed and funded

Production and reusePractices for asset adaptations, list of assets needed for certain product and actions for adding assets to the core asset base

Technical Risk Management

Technical risk management should provide processes, methods and tools to identify and assess what could go wrong and what to do about it. Technical Risk Management Paradigm

Identify risks before they become a problemEvaluate probability and impactPlan actionsTrack risk indicatorsControl and take corrective actions

Factors for Product Line Practice

TRM is best implemented as an integral part of the project management Product line requires also cross-project coordination of risk activities

Tool SupportThere should be tools for:

scopingrequirements engineeringarchitecture definitioncomponent developmentproduction plan practices

There is no single tool that addresses the needs of all PL practicesTools must support concurrently creating, maintaining and using multiple versions of both PL assets and productsInteroperability between tools is critical

Organisational management practice

areaHow the organisation forms groups to carry out the various responsibilities inherent in a product line effort: THE RIGHT ORGANISATIONAL STRUCTURE?Traditionally: software management at project levelProduct line: new roles and responsibilities because of core asset management according to an application life cycleCore assets need to be managed in a long-term life cycle: this will benefit more the whole organisation than the specific product alone

Functional groups within a product line organisationArchitecture group: product line architecture definitionsComponent engineering group: software core asset developmentProduct line support group: development and execution environments for product creationProduct development group: products for customers and users

product-unique components, interaction with Component engineering group, feedback to Support group

Supplement groups: Technical steering group & R&D Group help the organisation avoid stagnation

Successful PL organisationSeparate or integrated groups? - At least someone must have a cross-product perspectiveSuccess factors in implementing structural change

The highest risk: building general assets too general and product-specific software too customized to serve the PLThe adoption of PL approach should be evolutionary: a natural shift from the development of architecture to composition of new systems follows...

The current level oforganisational stress

The implementation history Sponsorship

Resistance management Culture Change agent skills

CONOPS - the operational concept for a product linehow, who & what, when & in what order:implementation / transition plan, specific product development strategies and the role of aqcuisitionProduct development:

Context, Activities, Organisational elements, Rationale, Integration

Core asset development: Components, Context, Activities, Organisational elements, Rationale, Integration

Risks: failure to identify a PL champion, lack of appropriate PL vision, failure to maintain the CONOPS

Training and educationTraining for asset development or aqcuisition is training in the software engineering practices within PLMust occur within the context of the organisation’s adoption plan of PL practices Must be applied in the context of overall PL strategy and specific training for certain practices must be tied to the goal of creating a core asset base to support the PLEmphasis on effective use and reuse of assets1) Augmenting current training activities to support product lines, 2) Replacing existing training activities, 3) Adding new training activities

AcquisitionThe process of obtaining products and services via

contract

The development and maintenance should be systematically constrained by carefully specifying an architecture and a common asset base - the acquisition strategy must be generally compatible with PL practices!Developing an acquisition strategy in PL is more critical than in a conventional system acquisitionIf used in both core assets and product development, use a single strategy to ensure a unified approach

Business Case & Market Analysis

Having capability & resources, providing unique opportunity & creating market demand, financing? ”Go / No go -questions”Also in determining whether to build a product using the core assets or construct it separatelyTwo cycles and as line products are developed, the document gets more tacticalMarket analysis determines the PL scope and is itself a core asset, but maintained and updated as new products come, and gives detailed knowledge about the needs...

Technology forecastingInternal development: developing paradigms & notations, technologies, code development suites, analysis tools, ...

Customer solutions: more efficient hardware platforms, better software platforms, improved user interfaces,…

Especially relevant to PLs: PROCESS INNOVATIONS, CONFIGURATION MANAGEMENT, TRENDS WITHIN THE RELEVANT STANDARDSRisks: wrong technology choice, architecture can’t support new technology, forecasting that is driven by technology (rather than business needs), ivory tower forecasting

Customer interface management

In PL, it is different from single-system developmentIn PL, the interfacing people include usually marketers, a product manager, domain experts, a user’s group coordinator, and othersNew means for managing customer expectations, negotiating requirements, developing and evolving customer products and providing customer supportManaging requirements on a PL, not individual product, basisCommunicate PL strategy to the customer, establish a process for developing work proposals and negotiating new contracts, train marketers, provide centralized product support, establish a group to identify the needs

FundingHow PL assets (used across several products) are paid for equitablyPL often requires a substantial up-front investment to get the product line off the groundFOCUS/Core asset development: develop initial set of core assets & production plan, define PL practices, develop software engineering environmentFOCUS/Product development: develop a product, provide ongoing product supportFunding strategies depend on the fiscal infrastructure of the PL enterprise

Organisational risk management

PL efforts require a great deal of coordination across project boundaries7 principles: Open communicationContinuous process, Integrated management, TeamworkForward-looking view, Global perspective, Shared product vision

CASE: CelsiusTech Systems

A Case study in Successful Product line development

By Lisa Brownsword and Paul Clements

http://www.sei.cmu.edu/pub/documents/96.reports/pdf/tr016.96.pdf

Celsiustech ABWhat is CT?

A Swedish naval defence contractorProduces command-and-control systems using Product Line ApproachCustomers: Scandinavian, Middle Eastern and South Pacific navieswww.celsiustech.se

Products…

Impetus for a PL approach1986 two major contracts

CT found out, that it could’t carry out such projects with current dev. methods

-> A demand for a product line approach

In addition, previous less-challenging projects had been over budget, past schedule… So what would be the result of these major projects with old methods?

Establishing PL

Components, system functions

System functionis considered smallest unit of reuse. (Despite it still consists of Ada units)

ArchitectureOne of crucial elements in building PL

Physicalnetworks, processors

SoftwareComponents, intercomponent coordinationDivision to layers

Architecture: Layers 1/2Components are divided into layers

this is based on the type of information each layer encapsulates

Layers are orderedHW-dependent, Middle, SW-specific layers

e.g. components specific to certain customer form a layer

Interaction between layers is restrictedcomponent can access only components it’s own or next lower layer

Architecture: Layers 2/2

Product schedulesA is the basis of PL.

E, F, G take full advantage of PL

Number of system functions

Things they had to cope with

Ownership changesTechnology changesLearning new approach

70 days of training to every employee

Teaching their approach to customers

Training

Technology changes

Factors of successStrong Management, a good visionCrisis in the beginning was a good ”kick-off” -> idea of PLArchitecture was the foundationMajor investments in time, capital and resources

Lessons LearnedBuilding product line took a long time, but it was worth itReuse almost 80 %, shorter time-to-market. Ability to enter new markets quicklySW/HW cost ratio inverted from 65:35 to 20:80Need of personnel decreased

Frequently Asked Questions I

If a product line is a set of products, does that mean I have to build them all?Isn't product line practice the same as single-system development with reuse?Isn't product line practice just another name for domain engineering/component-based development?My organization is very small/very large. Can we build a product line?The Software Capability Maturity Model® V2 puts important aspects of product line practice at Level 4. Do I have to be at Level 4 before I can hope to field a product line?

Frequently Asked Questions II

We're doing okay. Why should I change the way I do business and undergo the upheaval that a product line will bring?Where is the resistance to adopting a product line approach usually found?What is the relationship between process improvement and product line practice?Must all products in the software product line share the same architecture? If my products have different architectures but make heavy use of other shared assets, isn't that a product line?

ChallengesPractice sets additional constraint on the architectureComponents must be designed to be more general without loss of performanceTools, methods and processes must be more robust to account for the differences between managing a product line and managing a single productPersonnel must be trained beyond general software engineeringThe quality of the core assets becomes absolutely critical

Criticism I The article concentrates mostly on the management point of view. Software engineering is dealt only in general levelThe article is comprehensive in its coverage, but it does not go very deep in any subjectKey concepts are defined too generally

Criticism IIThe abstraction level is in some cases too high. There are no references to real-life case studiesThere is no reference, what is the current state of the art in software engineering community