A Framework for Software Product Line Practice Version 5.0
Adapted by Dr. Amir Tomer 1
Software Product Lines
What is a Software Product Line? • A software product line (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.
• Note: – software-intensive systems – common, managed set of features – specific needs of a particular market segment or mission – a common set of core assets – developed ... in a prescribed way 2
Software Product Lines
The SPL Framework • A Framework for Software Product Line Practice, Version 5 is a Web-based, living document that aids the software community in software product line endeavors. – Each version represents an incremental attempt to capture the latest information about successful software product line practices.
• The book (2002):
3
Software Product Lines
What Software Product Lines Are Not • fortuitous, small-grained reuse • single-system development with reuse • just component-based or service-based development • just a reconfigurable architecture • releases and versions of single products • just a set of technical standards
4
Software Product Lines
Product Line’s Core Assets • Requirements – The requirements are written for the group of systems as a whole – Requirements for individual systems specified by a delta or an increment to the generic set.
• Architecture – The architecture for the product line is the blueprint for how each product is assembled from the components in the core asset base.
• Software components – The software components that populate the core asset base form the building blocks for each product in the product line. – Some will be reused without alteration. Others will be tailored according to prespecified variation mechanisms.
• Performance modeling and analysis – For products that must meet real-time constraints (and some that have soft realtime constraints), analysis must be performed to show that the system's performance will be adequate. 5
Software Product Lines
Product Line’s Core Assets (cont.) • Business case, market analysis, marketing collateral, and cost and schedule estimates – These are the up-front business necessities involved in any product. – Generic versions are built that support the entire product line.
• Tools and processes for software development and making changes – The infrastructure for turning out a software product requires specific product line processes and appropriate tool support.
• Test cases, test plans, and test data – There are generic testing artifacts for the entire set of products in the product line with variation points to accommodate product variation. • People, skills, and training – In a product line organization, even though members of the development staff may work on a single product at a time, they are, in reality, working on the entire product line. – The product line is a single entity that embraces multiple products. 6
Software Product Lines
Product Line Essential Activities Developing products from core assets
Extracting core assets from existing/developing products
7
Software Product Lines
Core Asset Development
8
Software Product Lines
Core Asset Development - Input: Product Constraints •
What commonalities and variations exist among the products that will constitute the product line?
•
What behavioral features do they provide?
•
What features do the market and technology forecasts say will be beneficial in the future?
•
What commercial, military, or company-specific standards apply to the products?
•
What performance limits must they observe?
•
With what external systems must they interface?
•
What physical constraints must be observed?
•
What quality requirements (such as availability and security) are imposed?
9
Software Product Lines
Core Asset Development - Input: Production Constraints • Must a new product be brought to market in a year, a month, or a day? • What production capability must be given to engineers in the field? • What company-specific standards for software development processes must be followed in during product production?
• Who will be building the products and what environments will they use?
10
Software Product Lines
Core Asset Development - Input: Production Strategy • Proactive Strategy – Starting with a set of core assets and spinning products off of them
• Reactive Strategy – Starting with a set of products and generalizing their components to produce the product line core assets
• Production Strategy Issues – What will the transfer pricing strategy (costing policy) be? – Will generic components be produced internally or purchased on the open market? – How will the production of core assets be managed? – Will products be generated automatically from the core assets, or will they be assembled?
11
Software Product Lines
Core Asset Development - Input: Preexisting Assets • What software and organizational assets are available at the outset of the product line effort? • Are there libraries, frameworks, algorithms, tools, components, and services that can be used? • Are there technical management processes, funding models, and training resources that can be adapted easily for the product line?
12
Software Product Lines
Core Asset Development – Output: Product Line Scope •
The product line scope is a description of the products that will constitute the product line or that the product line is capable of including
•
The scope must be defined carefully – If the scope is too large and product members vary too widely, the core assets will be strained beyond their ability to accommodate the variation – If the scope is too small, the core assets might not be built in a generic enough fashion to accommodate future growth
•
The scope of the product line must target the right products, as determined by – knowledge of similar products or systems The scope definition of a product line is itself a core asset
– the prevailing or predicted market factors – the nature of competing efforts, and – the organization's business goals
•
The scope of the product line evolves as – market conditions change – the organization's plans change – new opportunities arise – the organization becomes more adept at SPL practice
13
Software Product Lines
Core Asset Development – Output: Core Asset Base Example of Attached Process: Requirement CA
14
1.
use the product line requirements as the baseline requirements
2.
specify the variation requirement for any allowed variation point
3.
add any requirements outside the set of specified product line requirements,
4.
validate that the variations and extensions can be supported by the architecture
Software Product Lines
Core Asset Development – Output: Production Plan
15
Software Product Lines
Product Development
16
Software Product Lines
Product Development - Inputs • Product Description (for a particular product) – often expressed as a delta or variation from some generic product description contained in the product line scope • such a generic description is, itself, a core asset
• Product Line Scope – indicates whether it's feasible to include the product under consideration in the product line
• Core Assets – from which the product is built
• Production Plan – details how the core assets are to be used to build the product 17
Software Product Lines
Management •
Organizational Management – Identifies production constraints and determines the production strategy – Creates an appropriate organizational structure – Provides the right resources in sufficient amounts – Determines a funding model and provides the funds – orchestrates the technical activities of core asset development and product development – mitigates risks that threaten the success of the product line – manages the organizational external interfaces – The Organizational management is the authority responsible for the ultimate success or failure of the product line effort
•
Technical Management – Oversees the core asset development and product development activities by ensuring that those who build core assets and products are engaged in the required activities, follow the processes defined for the product line, and collect data sufficient to track progress. – Decides on the production method and provides the project management elements of the production plan.
18
Software Product Lines
Product Line Practice Areas
•
Building a Business Case
•
Configuration Management
•
Architecture Definition
•
Customer Interface Management
•
•
Architecture Evaluation
•
Developing an Acquisition Strategy
Make/Buy/Mine/Commission Analysis
Funding
Measurement and Tracking
Component Development
•
•
•
Launching and Institutionalizing
Process Discipline
Mining Existing Assets
•
•
•
•
Scoping
Requirements Engineering
Market Analysis
•
•
•
Operations
•
Technical Planning
•
Software System Integration
•
Organizational Planning
•
Technical Risk Management
•
Testing
•
Organizational Risk Management
•
Tool Support
•
•
Understanding Relevant Domains
Structuring the Organization
•
Technology Forecasting
•
Using Externally Available Software
•
Training 19
Software Product Lines
Practice Area Structure • For each practice area the following information is presented: – Introductory Overview – Aspects Peculiar to Product Lines – Application to Core Asset Development – Application to Product Development – Example Practices – Practice Risks – Further Reading
20
Software Product Lines
Product Line Practice Areas
•
Building a Business Case
•
Configuration Management
•
Architecture Definition
•
Customer Interface Management
•
•
Architecture Evaluation
•
Developing an Acquisition Strategy
Make/Buy/Mine/Commission Analysis
Funding
Measurement and Tracking
Component Development
•
•
•
Launching and Institutionalizing
Process Discipline
Mining Existing Assets
•
•
•
•
Scoping
Requirements Engineering
Market Analysis
•
•
•
Operations
•
Technical Planning
•
Software System Integration
•
Organizational Planning
•
Technical Risk Management
•
Testing
•
Organizational Risk Management
•
Tool Support
•
•
Structuring the Organization
Understanding Relevant Domains
•
Technology Forecasting
•
•
Training
Using Externally Available Software
21
Software Product Lines
Domain Analysis (Understanding Relevant Domains) • Domain Analysis involves: – identifying the areas of expertise–domains–that are useful for building the product or products under consideration – identifying the recurring problems and known solutions within these domains – capturing and representing this information in ways that allow it to be communicated to the stakeholders and used and reused across the entire effort
• How Much Domain Analysis? Enough for... – reasoning about the technical and business implications of a proposed design – making informed decisions about which features, capabilities, and technologies to offer in proposed products – creating a set of artifacts that exploits the understanding of the relevant domains 22
Software Product Lines
Domain Analysis (Cont.) •
Domain information for a product line helps to determine – which capabilities tend to be common across systems in the domain(s) and what variations are present. – which subsets of capabilities might be packaged together as assets for the product line. – what constraints (e.g., standards, legal restrictions, business constraints, specific hardware platforms) apply to systems in the domain(s) – which assets typically constitute members of the domain(s). – whether to continue with the product line development effort
•
Domain Analysis Risks – analysis paralysis – a lack of access to the necessary domain expertise – inadequate documentation and sharing of relevant domain information – a lack of an understanding of an analysis process – a lack of the appropriate tool support for the process and products of domain analysis – a lack of management commitment
23
Software Product Lines
Product Line Practice Areas
•
Building a Business Case
•
Configuration Management
•
Architecture Definition
•
Customer Interface Management
•
•
Architecture Evaluation
•
Developing an Acquisition Strategy
Make/Buy/Mine/Commission Analysis
Funding
Measurement and Tracking
Component Development
•
•
•
•
Launching and Institutionalizing
•
Process Discipline
•
Mining Existing Assets
Market Analysis
•
Scoping
•
Requirements Engineering
•
Operations
•
Technical Planning
•
Software System Integration
•
Organizational Planning
•
Technical Risk Management
•
Testing
•
Organizational Risk Management
•
Tool Support
•
•
Structuring the Organization
Understanding Relevant Domains
•
Technology Forecasting
•
•
Training
Using Externally Available Software
•
24
Software Product Lines
Mining Existing Assets • Mining existing assets refers to resurrecting and rehabilitating a piece of an old system to serve in a new system for which it was not originally intended • Sources for Asset Mining – business models – rule bases – requirements and design specifications – schedules – budgets – test plans – test cases – coding standards – algorithms – process definitions – performance models
25
Software Product Lines
Mining Existing Assets (cont.) •
•
26
For Software Assets –
Focus first on large-grained assets that can be wrapped or that will require only interface changes rather than changes in large chunks of their underlying algorithms or code.
–
Determine how the candidate asset can fit into the architecture of the targeted new system.
–
Don't forget to consider the requirements for performance, modifiability, reliability, and other nonbehavioral qualities.
–
Be sure to include all the non-software assets associated with the software: requirements, design, test, and management artifacts.
When considering an asset, refer to... –
its alignment with the requirements for immediate products in terms of both common features and variation points
–
its appropriateness for potential future products
–
whether it will be used as a core asset or for a specific product
–
the amount of effort required to make its interface conform to the constraints of the product line architecture
–
its extensibility with respect to its potential future
–
its maintenance history
–
other assets that may be required from the legacy system
–
its projected long-term cost
Software Product Lines
Product Line Practice Areas
•
Building a Business Case
•
Configuration Management
•
Architecture Definition
•
Customer Interface Management
•
•
Architecture Evaluation
•
Developing an Acquisition Strategy
Make/Buy/Mine/Commission Analysis
•
Measurement and Tracking
•
Component Development
•
Funding
•
Process Discipline
•
Mining Existing Assets
•
Launching and Institutionalizing
•
Scoping
•
Requirements Engineering
•
Market Analysis
•
Technical Planning
•
Software System Integration
•
Technical Risk Management
•
Testing
•
Tool Support
•
Understanding Relevant Domains
•
Using Externally Available Software
•
Operations
•
Organizational Planning
•
Organizational Risk Management
•
Structuring the Organization
•
Technology Forecasting
•
Training 27
Software Product Lines
Scoping • Scoping is an activity that bounds a system or set of systems by defining those behaviors or aspects that are "in" and those behaviors or aspects that are "out.” • The following things drive the scope definition: – the prevailing or predicted market drivers, obtained through "Market Analysis" practices – the nature of competing efforts, obtained through "Market Analysis" or "Understanding Relevant Domains" practices – the business goals that led to embarking on a product line approach, obtained through "Building a Business Case" practices. – technology forecasts that identify expected future technologies, obtained through "Technology Forecasting" practices 28
Software Product Lines
Scoping Practices (partial) • Examining existing products – Identify existing products similar to those that will be part of the product line. – Gather any available documentation and conduct product demonstrations. – Conduct oral or written surveys of product experts and the current product developers, users, and maintainers. – Identify the products' capabilities, structure, and evolution and any other relevant factors about them. – Determine which elements of these products should be considered part of the product line.
• Context diagramming – A context diagram places the product line in the context of product users and other systems – not every system in the product may connect with all systems or types of users shown in the diagram – the context diagram may not show all the interactions of all the potential systems
29
Software Product Lines
Scoping: Context Diagram Example A personal Sound System
30
Software Product Lines
