Name

Catalogue of Methods and Processes for System Family Engineering from the
CAFÉ Project

1. Methods for Phase 1 "System Family Scoping"

Name	Organisation Structures for Product-Family Engineering
Process phases	Mainly before starting SFE; otherwise 1, 2, 7, 8
Complexity	Low
Audience	Managers
Result	Organisation structure
Input	Information about customers, products, own expertise and culture
Short description	Various organisation structures for product-family engineering are provided with their pros and cons, together with heuristics that give hints for determining the adequate organisation structures in particular situations and circumstances.
Interesting points	Heuristics for practical usage, based on current situation
To detailed description
Owner / participants	Siemens
Deliverable	CAFÉ CWD1.3: "Product Line Transition & Adoption", chapter 3.2 CAFÉ E1.2 "Organisation Structures for Product Family Engineering"

Name	Planning Process for Product Families
Process phases	1, 2, 7, 8
Complexity	Low
Audience	Product managers, marketing, process responsibles
Result	Product portfolio, business plan, marketing mix
Input	Market analysis
Short description	A reference process and supporting methods and techniques are developed for system / system family planning with short descriptions of major activities: business and market analysis, market segmentation, strategy definition, portfolio techniques, business plan, marketing mix
Interesting points	With product management an audience is addressed that has not been addressed in ESAPS and CAFÉ before
To detailed description
Owner / participants	Siemens AG
Deliverable	CAFÉ CWD1.1: "Business and Market Analysis", chapter 1 CAFÉ E1.1.2: "Planning Process for Product Families"

Name	Scoping in the Presence of Multiple Domains and Product Populations
Process phases	1, 7
Complexity	Low
Audience	Product managers, marketing
Result	A scoping approach for multiple stakeholders and product populations; a scalable approach fostering cooperation among diverse stakeholders
Input	User scenarios
Short description	User scenarios are applied to capture the needs of multiple stakeholders with different backgrounds and expertise (marketing, application, architect, different product families)
Interesting points	Using scenarios
To detailed description
Owner / participants	Philips
Deliverable	CAFÉ CWD1.2: "Product Line Scoping", chapter 1.1

Name	Specification for a Product Family Scoping Approach and its Integration in a Tool Workbench
Process phases	1, 7
Complexity	Medium
Audience	Product managers, marketing
Result	A scoping approach to determine the best product family scope and platform
Input	Enterprise goals, marketing information,
Short description	Using 4 dimensions: Enterprise goals, product family definition (based on the product map concept), scoping and ROI, and risk evaluation to adopt product-family engineering
Interesting points	Tool prototype development: Intent^(tm)
To detailed description
Owner / participants	Ivorium
Deliverable	CAFÉ CWD1.2: "Product Line Scoping", chapter 1.2

Name	Scoping Software Product Lines for the Business Context - Agility
Process phases	1, 7
Complexity	Low
Audience	Product managers, marketing, architects
Result	The best software engineering approach for the particular situation, agile vs. product family or combination of both; increasing agility of product family engineering processes
Input	Business strategies, software parameters
Short description	A model to determine the best-fit software development process (heavy-weight vs. agile) depending on size & complexity of the SW (small - large) and the agility needed to respond to market pressures (stable - agile)
Interesting points	Combination of agile SW development processes and product-family engineering; consideration of market volatility
To detailed description
Owner / participants	Nokia
Deliverable	CAFÉ CWD1.2: "Product Line Scoping", chapter 2.1

Name	Guidelines for the Process of SW Development Conforming PLs
Process phases	All
Complexity	Medium
Audience	Managers
Result	Transition process to product-family engineering for an SME
Input	Market knowledge, domain knowledge, PuLSE
Short description	Concentrate on important process steps only: scoping, architectural assessment, component development, component tests, system test, issue management, and change processes. This is done in small steps and ready-to-use tools, methods, and approaches are employed.
Interesting points	Practical experience from SMEs
To detailed description
Owner / participants	MARKET MAKER
Deliverable	CAFÉ CWD1.3: "Product Line Transition & Adoption", chapter 3.3 CAFÉ E5.7 "Handbuch produktfamilienkonformer Softwareentwicklungsprozeß"

Name	Product Management Assessment w.r.t. Product-Family Engineering
Process phases	1, 2, 7, 8
Complexity	Medium
Audience	Product managers, managers
Result	Identification of strengths and weaknesses of product management in an organisation; improvement plan
Input	Status of the product management process in the organisation, identified with a questionnaire
Short description	A product management reference model, mapped to a questionnaire is used to interview product managers of an organisation. The results are analysed, strengths and weaknesses, especially w.r.t. product family engineering are identified and measures for improvement proposed.
Interesting points	A new audience, important for PFE, product managers are addressed
To detailed description
Owner / participants	Siemens
Deliverable	CAFÉ CWD1.3: "Product Line Transition & Adoption", chapter 3.4 CAFÉ E1.5 "Product Management Assessment"

2. Methods for Phase 2: System Family Economical Analysis

Name	Integrated Cost and Investment Model for Product Family Development
Process phases	2, 8
Complexity	Medium - high
Audience	Product managers, marketing
Result	Product portfolio, business plan, marketing mix
Input	Market analysis, data about the organisation's current status
Short description	An economic model for valuing the strategic benefit of product line development in particular situations, taking aspects of uncertainty and flexibility into account
Interesting points	Taking strategy into account
To detailed description
Owner / participants	Fraunhofer IESE
Deliverable	CAFÉ CWD1.1: "Business and Market Analysis", chapter 2 CAFÉ E1.1.1: "Integrated Cost- and Investmentmodels for Product Family Development "

Name	Specification for an Integrated Product Family Economic Model
Process phases	1, 2, 7, 8
Complexity	Low
Audience	Product managers, marketing, (line managers)
Result	Return on investment calculation
Input	Market analysis, data about the organisation's current status, enterprise goals, product map
Short description	Integrated I-IRR (Incremental, Internal Rate of Return generic model) based ROI model, uses the product map approach as a basis to describe the product family on top of which the model is defined; leverages the scoping computations to cost accordingly what is within the scope and outside the scope of the family.
Interesting points	Tool: Intent™
To detailed description
Owner / participants	Ivorium
Deliverable	CAFÉ CWD1.1: "Business and Market Analysis", chapter 2

Name	Measuring Product Lines in Place
Process phases	2, 8
Complexity	Low - medium
Audience	Product managers, marketing, (line managers)
Result	Metrics for all kinds of product line measurements
Input	Market analysis, data about the organisation's current status, enterprise goals
Short description	A process for the measurement of product lines with the goal of achieving business objectives, based on ESI's Balanced IT Score Card method
Interesting points	Consideration of all important perspectives: Financial, customer, process, people, infrastructure & innovation
To detailed description
Owner / participants	European Software Institute, ESI
Deliverable	CAFÉ CWD1.1: "Business and Market Analysis", chapter 3

Name	Estimating (Future) Product Viability: A Platform Development Reasoning Model
Process phases	2, 8
Complexity	Medium
Audience	Product managers, platform managers, line managers
Result	Analysis of platform strategy and product line introduction approaches
Input	Observations from PFE projects, feedback from architects
Short description	A model providing insight in critical factors and alternative approaches to product family introduction and platform development
Interesting points	A model for product family introduction enabling ‘experimentation’ with various product family approaches, even changing strategies
To detailed description
Owner / participants	Philips
Deliverable	CAFÉ CWD1.1: "Business and Market Analysis", chapter 4

Name	Transition Process for Switching to Product-Family Engineering
Process phases	2, 8, before starting PFE
Complexity	Medium
Audience	Product managers, marketing, architects, managers
Result	The most adequate approach for the particular situation of an organisation to move to product-family engineering, encompassing a catalogue of measures for software process improvement
Input	Data about the organisation's current situation
Short description	A process of the actions to go from an organisation's current situation to product-family engineering in five general steps: 1. Analysis and assessment of the current situation of the organisation 2. Definition of a catalogue of measures for PFE transition 3. Improvement Step 4. Training and Coaching 5. Institutionalisation of the PFE approach in the organisation
Interesting points	Actions and questions to answer for analysis
To detailed description
Owner / participants	Siemens
Deliverable	CAFÉ CWD1.3: "Product Line Transition & Adoption", chapter 1.1 CAFÉ E1.3.1, E1.3.2: "Transition Process for Switching to Product-Family Engineering", two parts FAMILIES CWD1.2: "System Familiy Transition Economy", chapter 1 FAMILIES E1.3.2: "Product Family Engineering Transition"

Name	Product-Line Action Plan Specification
Process phases	2, 8, before starting PFE
Complexity	Medium
Audience	Product managers, marketing, architects, managers
Result	A product-line action plan to perform the necessary steps of a transition to product-family engineering
Input	Business objectives, company context, and candidate domain
Short description	A product-line action plan describes how to accomplish organisational changes, introduce product-line activities, and introduce product-line infrastructure, in order to move from single-system software development to software product-line engineering. It consists of three main tasks: Set product-line objectives, select and define product-line strategy, and define the plan for implementing the product-line strategy.
Interesting points	Evaluation of product-family strategies
To detailed description
Owner / participants	ESI
Deliverable	CAFÉ CWD1.3: "Product Line Transition & Adoption", chapter 1.2

Name	The Stage Growth Framework for a Software Product Business
Process phases	2, 8, before PFE start
Complexity	Medium
Audience	Product managers, marketing, managers
Result	Evaluation of current status in each stage for each level, and activities necessary to get from one stage to the next
Input	Business strategy, company and product information
Short description	A framework that allows the business and engineering management to see the probabilistic future of the business, product, and organisational development of the software product company. Different stages, related to product maturity are defined and for several levels - requirements, SW development, internal process, strategy - the corresponding activities and status are defined for each stage.
Interesting points	Evaluation of different stages and corresponding activities
To detailed description
Owner / participants	University of Jyväskylä
Deliverable	CAFÉ CWD1.3: "Product Line Transition & Adoption", chapter 1.3

Name	Lightweight, Incremental Transition Process for PF Adoption
Process phases	2, 8, before start of PFE
Complexity	Medium
Audience	Product managers, marketing, managers
Result	Activities to get from one maturity level to the next in the transition process
Input	Company and product information
Short description	Three dimensions: organisation structure, situation, and maturity scale are used to determine the kind of transition process. For three stages (green field, evolutionary, asset-driven) and four maturity stages, the criteria for reaching each state are provided.
Interesting points	Including organisation structure
To detailed description
Owner / participants	Ivorium
Deliverable	CAFÉ CWD1.3: "Product Line Transition & Adoption", chapter 1.4

Name	Transition from Products to Products Lines (Case Study)
Process phases	All
Complexity	Medium
Audience	Product managers, marketing, architects, managers
Result	Problems of PFE transition process identified and improvement actions defined
Input	Experience from a transition to product-family engineering
Short description	A case study of a system family transition from simple basic product toward a very complex system family. An incremental domain engineering through iterative application engineering is applied, involving a continuous feedback between these activities.
Interesting points	Practical experience and lessons learned
To detailed description
Owner / participants	Telvent
Deliverable	CAFÉ CWD1.3: "Product Line Transition & Adoption", chapter 2.1

Name	Tester Competence Management
Process phases	1, 2, 3
Complexity	Low
Audience	Managers
Result	Training plan to enhance people's skills
Input	Needed skills
Short description	Related to the extended V model, the functions and roles are defined, together with the type of skills needed to successfully work in a role; for each skill the ‘level of expertise’ available is described. The courses, or coaching approaches needed to bring a person from a skill level to a higher level are defined, if needed the skill levels of selected key staff are assessed. The ‘delta’ between required and actual skills are discussed with these persons and the courses to be followed are defined.
Interesting points	Importance of the role of people is recognised
To detailed description:
Owner / participants	Philips
Deliverable	CAFÉ CWD4.1: "Test strategy, methodology & process", chapter 8 "Product line test management and support"

3. Methods for Phase 3: Domain System Analysis / Design

Name	DNV Software’s Experiences with Adoption of Product-Family Engineering (Case Study)
Process phases	All
Complexity	Medium
Audience	Product managers, marketing, architects, managers
Result	Experiences on adopting product family engineering, specifically on leveraging commonality across product lines to increase the level of reuse in the company
Input	Experience from existing products and product families
Short description	Product-family alignment processes across organisational units, incremental development of a product population platform by close cooperation with product development projects. Architecture vision, guideline, product line architecture are provided for the platform.
Interesting points	Practical experience, architecture and component level considered
To detailed description
Owner / participants	DNV Software, SINTEF
Deliverable	CAFÉ CWD1.3: "Product Line Transition & Adoption", chapter 2.2

Name	Natural-Language Techniques for Product-Family Software Requirements
Process phases	3, 4, 9, 10
Complexity	High
Audience	Requirements engineers
Result	Identification of generic and variable parts of use cases in requirements documents
Input	Use cases in requirements documents
Short description	Natural Language (NL) processing techniques are used to identify automatically the necessary generic and variable parts in requirements documents in order to specialise them into specific product features.
Interesting points	A new approach for commonality and variability analysis in requirements.
To detailed description
Owner / participants	IEI / Omega
Deliverable	CAFÉ CWD2.1: "Requirements Engineering", chapter 2.1

Name	Building Domain Models Based on Legacy System Descriptions
Process phases	3, 4, 5
Complexity	Low
Audience	Requirements engineers, architects
Result	Integration of legacy assets from documents into a product family
Input	Legacy documents of existing products that shall be included into a product family
Short description	Legacy documents are scanned for certain keywords and phrases and commonality and variability analysis is performed on the retrieved entities. The results are candidates for model elements that serve as basis for scoping and modeling. The method is called PuLSE-CaVE (for Commonality and Variability Elicitation).
Interesting points	Reuse of document assets
To detailed description
Owner / participants	Fraunhofer IESE
Deliverable	CAFÉ CWD2.1: "Requirements Engineering", chapter 2.2 CAFÉ E2.1 "User Documentation Based Product Line Modeling"

Name	Model Driven Requirements Engineering
Process phases	3, 4, 9, 10
Complexity	Medium
Audience	Requirements engineers
Result	Coherency from requirements down to implementation with one single standard modelling language
Input	Requirements, features
Short description	Requirements are modelled in a Platform Independent Model (PIM) that refines a Product Line Scoping PIM (the context model) and which is refined into an Analysis PIM (the Architecture model) which will be subsequently refined by applying architectural styles, down to implementation. The defined Model Driven Engineering approach, which includes requirements engineering, is compliant with the OMG’s Model Driven Architecture (MDA) approach to software development.
Interesting points	The approach is supported by intense tooling
To detailed description
Owner / participants	Thales
Deliverable	CAFÉ CWD2.1: "Requirements Engineering", chapter 2.5

Name	Use Case Driven Feature Analysis and Modelling
Process phases	3, 4, 9, 10
Complexity	Medium
Audience	Requirements engineers
Result	Feature models, feature dependencies, interactions, variability
Input	Information about requirements and features
Short description	Groups of related features are modelled in feature trees; a feature dependency model is used to describe all possible dependencies among features within the current scope. This is used to provide methods and techniques to connect features to configuration models and test cases and to map features to architecture using use case realisation.
Interesting points	Explicit dependency model
To detailed description
Owner / participants	Nokia
Deliverable	CAFÉ CWD2.1: "Requirements Engineering", chapter 2.3

Name	Considering Product Family Variability when Defining Product Family Applications
Process phases	3, 4, 9, 10
Complexity	Low
Audience	Requirements engineers
Result	Getting the right variability, according to customer wishes
Input	Requirements, features
Short description	Extension of RE techniques to support the communication with the customer about product family variability.
Interesting points	Identification of "essential" variability
To detailed description
Owner / participants	University of Duisburg-Essen
Deliverable	CAFÉ CWD2.1: "Requirements Engineering", chapter 2.4 CAFÉ E2.2.1: "Szenariobasierte Methodik zur Identifikation von Anforderungen an kundenspezifische, produktfamilienbasierte Anwendungen"

Name	Objecteering/Requirements - a Tool for Requirements Engineering
Process phases	3, 4, 9, 10
Complexity	Medium
Audience	Requirements engineers
Result	This is a requirements engineering tool for requirements modelling in PFE context
Input	Requirements
Short description	The technology underlying the tool extends the UML model and uses the UML profile mechanism to offer a tool integrating requirements collection, dictionary definition, UML modeling and code generation.
Interesting points	The tool provides total traceability from requirements right through to code and "deliverable" production, as well as a set of integrated help functions, used, for example, to assist in the creation of models from requirements.
To detailed description
Owner / participants	Softeam
Deliverable	CAFÉ CWD2.1: "Requirements Engineering", chapter 2.6

Name	Requirements Management Improvements
Process phases	3, 4, 9, 10
Complexity	Low
Audience	Requirements engineers
Result	A requirements management process improvement
Input	Requirements
Short description	The RE process has been improved by more stakeholder involvement, by templates and tooling to facilitate stakeholders in gathering, storing and characterising requirements in a standardised way, and by a multi-disciplinary product team of stakeholder representatives which meets regularly on an ongoing basis to discuss, rank and refine requirements and allocate them to releases. A requirements management plan has been used for specifying the improvement. An improved requirements traceability is provided.
Interesting points	Lessons learned and recommendations
To detailed description
Owner / participants	Philips
Deliverable	CAFÉ CWD2.1: "Requirements Engineering", chapter 2.7

Name	Adapting RE Processes to Systems Families - Development by Means of Scenarios
Process phases	3, 4, 9, 10
Complexity	Medium
Audience	Requirements engineers
Result	Introduction of RE processes and of system family concepts in these RE processes, at Telvent
Input	Current RE processes
Short description	Variability is introduced into the RE process by using scenarios. A reference process for all divisions is introduced with document templates and default roles, based on ISO 12207. Elicitation techniques, variability, and roles variability are introduced.
Interesting points	Reference process for different organisational units with different products and customers
To detailed description
Owner / participants	Telvent
Deliverable	CAFÉ CWD2.1: "Requirements Engineering", chapter 2.8

Name	Requirements Engineering for Dynamic Markets
Process phases	3, 4, 9, 10
Complexity	Low
Audience	Requirements engineers
Result	Combination of RE methods and agile development methods
Input	Current RE processes and development methods
Short description	Markets, products, and projects are characterised by particular attributes; RE methods are described and characterised along the market, product, and project dimension with these attributes to identify where they are best usable. They are ranked according to their agility and usability in an agile environment.
Interesting points	List of RE methods and their relations to product, market, and project attributes.
To detailed description
Owner / participants	Siemens
Deliverable	CAFÉ CWD2.1: "Requirements Engineering", chapter 2.9 CAFÉ E2.3.1.1, "Requirements Engineering for Dynamic Markets" (part1) FAMILIES E2.3.1.2: "Requirements Engineering for Dynamic Markets" (part 2)

Name	Investigation of Product-Family Evolution
Process phases	3, 4, 5
Complexity	Low
Audience	Requirements engineers, architects
Result	Visualisation of feature, component and product family evolution
Input	Feature and architecture change history: Source code, CVS repository (remote access; revision information and change reports), Bug report database, (online) documentation: roadmap, release notes, design documents
Short description	For each feature or software module or architecture module, size and changes over time are displayed. The percentage of features or of files last changed at specific revision on module level is displayed. A database of evolution data is established and a unified framework for architecture recovery and software evolution analysis founded.
Interesting points	Case study with Mozilla
To detailed description
Owner / participants	Nokia
Deliverable	CAFÉ CWD2.2: "Platforms", chapter 2 "Analysis of Product Family Evolution"

Name	Architecture Reconstruction
Process phases	3, 4, 5
Complexity	Medium
Audience	Architects
Result	Architecture concepts and multiple views (component, task/process, development, deployment, feature, organisational view)
Input	Source code, intended design of the system and additional sources (documentation etc.)
Short description	Static and dynamic (profilers) source code analysers, design document analyses, expert interviews are used to gather data which are then used to create an architecture model visualised as a relational graph. The model is concretised and abstracted, using domain knowledge. Architectural views are derived. The model is visualised using hierarchical relational graphs for navigating and manipulating the graphs, hyperlinked web documents for publishing the architectural models on the web, and UML diagrams that can be imported in traditional CASE tools.
Interesting points	SARA: semi-automatic component view recovery
To detailed description
Owner / participants	Nokia
Deliverable	CAFÉ CWD2.2: "Platforms", chapter 3 "Architecture Recovery and Reference Architecture"

Name	Feature Oriented Reverse Engineering
Process phases	3, 4, 5
Complexity	High
Audience	Architects, implementers
Result	Feature view: describing the run-time implementation of a particular feature at a high-level of abstraction; feature interaction models: describing the critical interaction points of features
Input	Feature list, reference architecture, instrumented system where to simulate the features, high-level structure of the system
Short description	Dynamic analysis is used to create architectural views based on static and dynamic information; features are represented via use cases and executed on the instrumented system; the traces are used to create the feature view from which interaction patterns are derived and filtered
Interesting points	Tool and case studies
To detailed description
Owner / participants	Nokia
Deliverable	CAFÉ CWD2.2: "Platforms", chapter 3.1 "Architecture Recovery"

Name	Pattern-Supported Architecture Recovery
Process phases	3, 4, 5
Complexity	Medium
Audience	Architects, implementers
Result	High level view of the architectural design where the source code patterns are abstracted and architectural properties are represented by patterns
Input	List of source code patterns that are architecturally significant, source code, intended design of the system
Short description	The approach consists of the following steps: Analysis and pattern candidate identification, pattern definition, pattern recognition, pattern view computation, analysis of pattern views
Interesting points	Revealer: a PSAR (Pattern-supported Architecture Recovery) prototype tool
To detailed description see also #Architecture-Recovery-Q
Owner / participants	Technical University of Vienna
Deliverable	CAFÉ CWD2.2: "Platforms", chapter 3.1 "Architecture Recovery"

Name	Reference Architecture Definition in the Presence of Prior Systems
Process phases	3, 4, 5
Complexity	Medium
Audience	Architects
Result	The reference architecture including most important architectural requirements for the PF plus rationales & trade-offs in the architecture
Input	Source code, external information (documentation of the products, system & domain knowledge), additional requirements on existing/new systems of the PF, and the scope of the PF
Short description	Business goals and product family scope are used to determine the architectural views; information needed to construct these views is the basis for reverse engineering activities of existing systems that shall be included in the product family. These views are then analysed and used to create the reference architecture which gives then feedback for the analysis.
Interesting points	PuLSE-DSSA, a tool to design reference architectures
To detailed description
Owner / participants	Fraunhofer IESE
Deliverable	CAFÉ CWD2.2: "Platforms", chapter 3.2 "Reference Architecture" CAFÉ E2.5.2 "Definition of Reference Architectures based on Existing Systems"

Name	Classification of Variation Mechanisms
Process phases	3, 4, 5
Complexity	Low
Audience	Architects
Result	Overview of platform approaches, variation mechanisms and their properties; support for decision on platform approaches and variation mechanisms
Input	Experience from n product families and design documents of these product families
Short description	A classification of platform approaches, based on experiences with product families. This classification provides guidelines describing which approach is suitable for what context and helps to define the reference architecture when starting with product family development.
Interesting points	Metrics for the classification of platform approaches
To detailed description
Owner / participants	Philips
Deliverable	CAFÉ CWD2.2: "Platforms", chapter 3.2 "Reference Architecture"

Name	Reference Architecture for a Class of Product Families with Similar Characteristics
Process phases	3, 4, 5
Complexity	Medium
Audience	Architects
Result	Reference architecture
Input	Quality requirements, scenarios
Short description	The reference architecture is conceived as a pattern language, consisting of an enforced base part; guidelines are expressed as scenarios with relations to quality attributes and to patterns guiding the specialisation of the reference architecture to meet given quality requirements.
Interesting points	Example guidelines for particular qualities; validation in CAFÉ CWD2.3: "Design for Quality", chapter 1.5.1
To detailed description
Owner / participants	ICT-Norway
Deliverable	CAFÉ CWD2.3: "Design for Quality", chapter 1.4.1 "Reference architecture for a class of product families with similar characteristics"

Name	Supporting “Design for Quality” by Architecture Recovery
Process phases	3, 4, 5
Complexity	Medium
Audience	Architects
Result	Architectural views
Input	Domain knowledge, source code
Short description	Domain knowledge is used to define domain-specific patterns; these are used to analyse code and identify patterns. Associations between recognised pattern instances and other architectural elements are computed. They result in different views of the software architecture. Resulting views and recognised patterns are analysed to abstract higher-level patterns. Already applied patterns are refined, new pattern definitions are validated.
Interesting points	Examples in CAFÉ CWD2.3: "Design for Quality", chapter 1.5.3. Tool
To detailed description see also #Pattern-Architecture-Recovery
Owner / participants	Technical University Vienna
Deliverable	CAFÉ CWD2.3: "Design for Quality", chapter 1.4.2 "Supporting “Design for Quality” by Architecture Recovery"

Name	Using Patterns to Support the Design of Product Family Architectures
Process phases	3, 4, 5
Complexity	Low
Audience	Architects
Result	Patterns for designing product family reference architectures
Input	Quality requirements, decision model
Short description	An example is provided how to document the relationship between the required quality of a product family architecture and patterns employed in such an architecture. The example quality chosen is performance and the patterns supporting performance are a number of caching patterns.
Interesting points	Example in CAFÉ CWD2.3: "Design for Quality", chapter 1.5.2
To detailed description
Owner / participants	Fraunhofer IESE
Deliverable	CAFÉ CWD2.3: "Design for Quality", chapter 1.4.3 "Supporting “Design for Quality” by Architecture Recovery" CAFÉ E2.4.2.1: "Product Family Specific Quality Attributes"

Name	Architectural Design for Quality Meta Model
Process phases	3, 4, 5
Complexity	Low
Audience	Architects
Result	Meta model for architecture design for quality
Input	Modelling knowledge
Short description	A meta model of architecture design is provided, encompassing a quality model. The architecture design cycle is described.
Interesting points	General architecture design meta model
To detailed description
Owner / participants	Nokia
Deliverable	CAFÉ CWD2.3: "Design for Quality", chapter 2.1 "Architectural Design for Quality Meta Model"

Name	Guidelines for Architecture Design in Product Family Engineering
Process phases	3, 4, 5
Complexity	Low
Audience	Architects
Result	Guidelines for architecture design for quality
Input	Domain and design knowledge
Short description	Guidelines for developing a product family reference architecture, based on a quality model.
Interesting points	Practical guidelines
To detailed description
Owner / participants	ICT-Norway
Deliverable	CAFÉ CWD2.3: "Design for Quality", chapter 2.2 "ICT-Norway Guidelines for architecture design in product family engineering"

Name	IESE PuLSE Method (DSSA)
Process phases	3, 4, 5, 9, 10, 11
Complexity	Medium
Audience	Architects
Result	Method for the design, evaluation, and maintenance of product family architectures and meta models for quality models and patterns
Input	Domain and design knowledge
Short description	PuLSE is a product line software engineering method that covers the whole product family development life cycle; it is customisable and can be introduced incrementally by augmenting existing software development processes and products with product family specific aspects. The PuLSE-part DSSA (Domain-Specific Software Architecture) supports the design, evaluation, and evolution/maintenance of product family architectures. It is customisable, iterative, scenario-based; it integrates design and evaluation of architectures and allows the integration of existing components.
Interesting points	General Method, covering the whole product-family engineering process
To detailed description
Owner / participants	Fraunhofer IESE
Deliverable	CAFÉ CWD2.3: "Design for Quality", chapter 2.3 "IESE PuLSE Method"; see also CAFÉ E2.5.3 "Definition of Reference Architectures based on Existing Systems"

Name	UML Profile for Quality of Service
Process phases	3, 4, 5
Complexity	Low
Audience	Architects
Result	General description for Quality of Service
Input	Quality requirements
Short description	Profiles are provided for describing quality of service characteristics, levels, forces, adaptation, and mitigation solutions. Three basic fault tolerance concepts are supported (fault detection, grouping, replication).
Interesting points	This profile is under standardisation at OMG
To detailed description
Owner / participants	Thales
Deliverable	CAFÉ CWD2.3: "Design for Quality", chapter 2.5 "UML Profile for Quality of Service"

Name	Architecture Evaluation
Process phases	3, 4, 5
Complexity	Low
Audience	Architects
Result	Static valuation of a system family architecture for fulfilling their intended use
Input	Scenarios, architecture
Short description	ATAM and ARID are used to evaluate the BriX.Net system family reference architecture
Interesting points
To detailed description: - no details available
Owner / participants	ICT Norway
Deliverable	CAFÉ CWD2.3: "Design for Quality", chapter 3.1 "Architecture Evaluation at DNV Software"

Name	Domain-Specific Modelling Languages for Product Families
Process phases	3, 4, 5
Complexity	Medium
Audience	Architects, designers
Result	A modelling environment that is tailored for the specific domain
Input	Domain knowledge, domain vocabulary
Short description	Domain-specific methods are developed - a domain-specific modelling language, code generators that read the instance models to produce variants, and a domain framework. An elaborate example shows how to use domain-specific methods to all parts of system-family engineering.
Interesting points	Elaborate example
To detailed description
Owner / participants	MetaCase Consulting
Deliverable	CAFÉ CWD2.3: "Design for Quality", chapter 4 "Domain-Specific Modelling Languages for Product Families"

Name	Production of Domain Requirements (PIM) and Derivation of Product Requirements (PSM)
Process phases	3, 4, 6, 7
Complexity	Medium
Audience	Requirements engineers
Result	Model of requirements as an input for PIM analysis, the PIM, specification documents and test scenarios
Input	Model of system context (PIM context) and user requirements from DOORS
Short description	Requirements are modelled in a Platform Independent Model (PIM) that refines a product line scoping PIM and which is refined in an analysis PIM which will be subsequently refined by applying architectural styles, down to implementation. Roles and activities of the process are defined.
Interesting points	Elaborate tool evaluation
To detailed description
Owner / participants	Thales
Deliverable	CAFÉ CWD2.4: "Assets Development Support", chapter 1 "Product Family Requirements Support"

Name	Requirements Management and Expression of Variability in Requirements
Process phases	3, 4, 5, 9, 10, 11
Complexity	Medium
Audience	Requirements engineers
Result	Requirements model with traceability support to product UML models
Input	Requirements
Short description	A requirements engineering tool is being developed as part of a tool suite, especially suited for system families, that supports the management of requirements and dictionaries, the definition of use cases, building the initial model, define variation points and decision points. It automates traceability and ensures documentation generation from requirements and model. There are Word and DOORS extensions and interoperability with Objecteering/UML.
Interesting points	Good tool description; variability support
To detailed description
Owner / participants	Softeam
Deliverable	CAFÉ CWD2.4: "Assets Development Support", chapter 1 "Product Family Requirements Support"

Name	Good practices for PF architectures
Process phases	3, 4, 5, 9, 10, 11
Complexity	Low
Audience	Architects
Result	Architecture development processes
Input	Domain knowledge, business process
Short description	Roles and responsibilities for architecting in a system family environment are defined. Activities for architecting system families are defined, each with objectives/benefits, responsibilities, description, methods, process phase, level (product family level, component level, etc.).
Interesting points	Guidelines for practical usability
To detailed description
Owner / participants	Siemens
Deliverable	CAFÉ CWD2.4: "Assets Development Support", chapter 2 "Product Family Architecture Support" CAFÉ E2.4.1 "Good Practices for Product Family Architectures", CAFÉ E5.2.3 "Erprobung und Anpassung der Good Practices für den Architekturprozess in einem konkreten Entwicklungsumfeld"

Name	Production of PF Reference Architecture and Derivation of Specific Product Architecture
Process phases	3, 4, 5, 9, 10, 11
Complexity	Medium
Audience	Architects
Result	Generated Documents: Requirements specification, architectural documents for the PF and for specific products, evaluation reports on tools, technologies and specific issues related to the implementation phase. Developed models: Business and architecture models for the product family of services. Changes in existing models
Input	Initial documents: Know-how of the organisations involved, ESAPS documents, several studies and analysis about software engineering tools and home network technologies. Initial models (UML diagrams) and existing assets (internal, third party)
Short description	A process for architecting is defined with roles and activities. Architecture meta model and core reference architecture have been defined and refined. The functional and non-functional architecture derivations process phases are defined.
Interesting points	Tool classification
To detailed description
Owner / participants	Telvent
Deliverable	CAFÉ CWD2.4: "Assets Development Support", chapter 2 "Product Family Architecture Support"

Name	Document Automation and Document Access
Process phases	3, 4, 5, 9, 10, 11
Complexity	Low
Audience	Requirements engineers, architects, designers
Result	Standard project documents: requirements specification, design specification, test specification, etc. for systems and subsystems
Input	UML class model of the system; document templates
Short description	For blocks in a UML class diagram, the specification documents (requirements specification, design specification, etc.) are created automatically by selecting the corresponding building block and the type of document required.
Interesting points	Guidelines for traceability and change tracking
To detailed description
Owner / participants	Philips
Deliverable	CAFÉ CWD2.4: "Assets Development Support", chapter 3 "Product Family Implementation Support"

Name	Document Consistency and Traceability
Process phases	3, 4, 5, 9, 10, 11
Complexity	Low
Audience	Requirements engineers, architects, designers
Result	Horizontal traceability: test case specifications are consistent with the requirement specification documents on the corresponding level. Vertical traceability: lower level specification documents are consistent with the higher level specification documents.
Input	Requirements specification documents (Product Requirement Specification, System Requirement Specification, Functional Requirement Specification, Module Requirement Specification), test specification documents (Beta Test Specification, Alpha Test Specification, Functional Requirements Test Specification, Module Test Specification)
Short description	Requirements and test cases are tagged uniquely and linked to their sources. System requirements are linked to corresponding modules or components. Rational Requisite Pro is used for vertical traceability and Mercury Test Director for horizontal traceability.
Interesting points	Tool evaluation
To detailed description
Owner / participants	Philips
Deliverable	CAFÉ CWD2.4: "Assets Development Support", chapter 3 "Product Family Implementation Support"

Name	Requirements and Features of PFE Tools
Process phases	3, 4, 5, 9, 10, 11
Complexity	Low
Audience	Requirements engineers, architects, designers
Result	Requirements for tools needed and applicable in product-family engineering
Input	Product-family engineering process needs
Short description	For certain product-family specific activities, requirements for tools have been specified. These activities are: functional and non-functional derivation, MDE, variability awareness
Interesting points	Tool requirements
To detailed description - not available
Owner / participants	Thales
Deliverable	CAFÉ CWD2.4: "Assets Development Support", chapter 4 "Requirements and features of PFE tools"

Name	Component-Based Platform: Development and Adoption Experiences (Case Study)
Process phases	3, 4, 5, 9, 10, 11
Complexity	Medium
Audience	Architects, managers
Result	Cross-business-unit software development based on a platform with common architecture and common components
Input	Experience from existing products and product families
Short description	The approach uses a thorough adoption plan, a three-staged adoption process, a jointly defined platform architecture, incremental growth and adoption of the component platform, and a jointly defined program guiding the platform’s future.
Interesting points	Practical experience, lessons learned
To detailed description
Owner / participants	Philips
Deliverable	CAFÉ CWD1.3: "Product Line Transition & Adoption", chapter 2.3

Name	Agile Approach to PL Engineering
Process phases	All, process preparation
Complexity	Medium
Audience	Process responsibles, managers
Result	A toolbox where it is possible to select methods and techniques that are suitable for the actual business situation
Input	Current development process, domain knowledge
Short description	A pattern approach is used with SW engineering patterns: principles of agile PLE, individual patterns, team patterns, and organisational patterns
Interesting points	A new approach to integrate agile methods into product-family engineering
To detailed description
Owner / participants	Nokia
Deliverable	CAFÉ CWD1.3: "Product Line Transition & Adoption", chapter 3.5

Name	Component Generalisation in Product Families: Generalisation of a Framework to a Wider Scope
Process phases	3, 4, 5, 6, 9, 10, 11, 12
Complexity	Medium
Audience	Architects, implementers
Result	Adaptation of a component to be used in various platforms or for extended purposes in its platform
Input	A component and a target reference architecture where the component shall be used
Short description	Introduction of generalised interfaces, with extensive data-model dependencies. The old platform infrastructure is copied to the remote service software and then the dependent parts are isolated into separate replaceable components.
Interesting points	Case study, practical application
To detailed description
Owner / participants	Philips
Deliverable	CAFÉ CWD2.2: "Platforms", chapter 3.2 "Reference Architecture"

Name	Component Generalisation in Product Families: Introduction of an Operating System Abstraction
Process phases	3, 4, 5, 6, 9, 10, 11, 12
Complexity	Medium
Audience	Architects, implementers
Result	The product family deployed on multiple operating systems; portability and maintainability introduced by means of an operating system abstraction layer, a common layer for real-time and non real-time environments
Input	A product family based on one operating system for non real time software and another OS for real-time embedded software
Short description	Generalisation of an operating system abstraction layer for multiple environments, especially for a real-time embedded environment. Different builds for different platforms, specific problems isolated in separated link units.
Interesting points	Case study, practical application
To detailed description
Owner / participants	Philips
Deliverable	CAFÉ CWD2.2: "Platforms", chapter 3.2 "Reference Architecture"

Name	Platform Independent and Platform Specific Modelling
Process phases	3, 4, 5, 9, 10, 11
Complexity	High
Audience	Architects, designers
Result	Development approach for system-family engineering with separation of platform-independent and platform-specific models to support different platform and product life cycles
Input	Separation of concerns; platform variability and product variability
Short description	MDA (model-driven architecture) is extended to model-driven family engineering by defining 3 abstraction layers, analysis (PIM), design (PIM), and implementation (PSM) described by meta models. Profiles are used to represent meta-model instances in UML while the mapping between abstraction layers is defined at meta-model level. These models are refined using semi automatic transformation to go from the problem to a solution.
Interesting points	General approach, shared by all partners
To detailed description
Owner / participants	Thales, Softeam, INRIA, edb4tel, ICT Norway
Deliverable	CAFÉ CWD2.2: "Platforms", chapter 4 "Platform Independent and Platform Specific Modelling"

Name	Platform Independent and Platform Specific Modelling: Approaches for the PIM Layer
Process phases	3, 4, 5, 9, 10, 11
Complexity	Medium
Audience	Architects, designers
Result	Component-PIM, the last platform-independent model
Input	Metamodels of component, component specification, and product family architecture
Short description	The base component meta-model defines the base component concepts that describe how to model logical software components using UML. The component Specification meta-model specifies how a product development project should structure its UML model as far as components are concerned. The Product Line Architecture meta-model extends the base component meta-model according to a 4+2 tier reference architecture.
Interesting points	Example
To detailed description
Owner / participants	ICT Norway
Deliverable	CAFÉ CWD2.2: "Platforms", chapter 4 "Platform Independent and Platform Specific Modelling"

Name	Change Management: Managing Changes of Product Family Assets Between Parallel (Component) Projects in a Product Population
Process phases	3, 4, 5, 9, 10, 11
Complexity	Medium
Audience	Architects, requirements engineers
Result	Defined process for: Requirements management, contract management, verification and delivery, change management
Input	Customer needs, domain and process know-how
Short description	Managing supplier-client relations for component based development w.r.t. requirements management, contract management, test and verification, and change management. Process descriptions for project scoping, global design, detailed design, component verification, acceptance phase, integration and problem solving phase, change control.
Interesting points	Process descriptions
To detailed description
Owner / participants	Philips
Deliverable	CAFÉ CWD3.1: "Change management and traceability", chapter 1 "Change management"

Name	Change Management and System Family Engineering: a XML Technology Based Solution
Process phases	3, 4, 9, 10
Complexity	Medium
Audience	Architects, requirements engineers
Result	A product plan tailored to provide an estimation of the change cost, schedule and efforts
Input	Decision model
Short description	The decision model is enriched with change management information as well as the process for establishing the relationship between open decisions and change management information. Deriving the change management information in an automatic way for providing a product plan as well as an estimation in terms of cost, time, and effort for the change activities to perform.
Interesting points	XML usage, estimation support
To detailed description
Owner / participants	ESI
Deliverable	CAFÉ CWD3.1: "Change management and traceability", chapter 2

Name	Traceability Core Meta-Model as UML Extension in Objecteering/UML Modelling Tool
Process phases	3, 4, 5, 9, 10, 11
Complexity	Medium
Audience	Requirements engineers
Result	Traceability based on links between UML model elements
Input	UML models, requirements model (DOORS)
Short description	UML extensions are defined and the Objecteering tool is extended to provide traceability between requirements model elements and design UML elements. Automatic creation of UML elements from requirements or terms, thereby automatically creating traceability links. Creation of traceability links from requirements, dictionaries and terms to different model elements. Automatic creation of requirements documents and traceability matrices, and of dictionary extensions.
Interesting points	Tool, interface to DOORS
To detailed description
Owner / participants	Softeam
Deliverable	CAFÉ CWD3.1: "Change management and traceability", chapter 3

Name	System Feature (Change) Management in a MultiX Environment
Process phases	3, 4, 5, 9, 10, 11
Complexity	Medium
Audience	Requirements engineers
Result	Traceabiltiy of commitments, features and requirements
Input	Features, requirements
Short description	Traceability of the end-to-end system feature allocation commitments ("contracts") between all the parties at all the "layers" related to a system product (SP) program. End-to-end change management within an SP program. Co-ordinated changes of system features across all commitments, in order to prevent "broken" system features. Multisite/multiproject/multipartner-environment (MultiX).
Interesting points	Commitment traceability, tool
To detailed description see also #Committment-Traceability
Owner / participants	Nokia
Deliverable	CAFÉ CWD3.1: "Change management and traceability", chapter 4

Name	Decision Model Modelling and Automatic Derivation Process Using XML Technology
Process phases	3, 4, 5, 9, 10, 11
Complexity	Medium
Audience	Architects
Result	Decision model
Input	Decisions
Short description	Mapping the domain analysis artefacts (decision model, application model and derivation process) using the XML technology in order to implement an automatic derivation process; the decision model is represented using the XML schema document; the application model is mapped using the XML data document; the derivation process is mapped using the XML stylesheet document
Interesting points	XML usage
To detailed description
Owner / participants	ESI
Deliverable	CAFÉ CWD3.3: "Product Derivation and Family Evolution", chapter 1 "Variability Engineering"

Name	COTS Selection Process for Product Families
Process phases	3, 4, 5, 9, 10, 11
Complexity	Medium
Audience	Requirements analysts, architects, designers
Result	The most appropriate COTS components according to requirements, architecture, and variability of the product family
Input	Product family requirements, architecture, and variability; candidate components
Short description	During COTS evaluation for a product family, three aspects need to be considered: requirements, architecture, and variability. Usually, there is no component available (on the market) that fulfils all three aspects completely. In order to avoid a cost-intensive development of the component, it often makes sense to select the best-fitting component from the set of candidates and to accept some minor changes to requirements, architecture, and/or variability of the product family. Thereby, a trade-off decision has to be made between the cost-saving use of a COTS component including the above mentioned, necessary adaptations, on the one hand, and the cost-intensive development of the component, on the other hand. The developed CoVAR process (Component selection considering Variability, Architectural concerns, and Requirements) considers the above mentioned three aspects and supports COTS selection in three steps. During “Component Screening”, candidate components are evaluated a first time and the number of components is reduced to three to seven. During “Detailed Component Evaluation”, these components are evaluated thoroughly. In both steps, necessary changes to requirements, architecture, and variability are analyzed and, if necessary, conducted. Finally, during “Component Selection”, the best-fitting component is selected based on the results of the “Detailed Component Evaluation”.
Interesting points	Consideration of variability during COTS evaluation
To detailed description
Owner / participants	University of Duisburg-Essen
Deliverable	CAFÉ CWD3.3: "Product Derivation and Family Evolution", Chapter 3 "Component Identification & Adaptation" CAFÉ E3.3.1: "Requirements-Based COTS Selection for Product Families" CAFÉ E3.3.2: "Aspects of Change Management in COTS Selection Processes" CAFÉ E3.3.3: "COTS Evaluation for System Families under Consideration of Constant Changes"

Name	System Performance Modelling in UML with Properties and Metrics for Asset Selection
Process phases	3, 4, 5, 9, 10, 11
Complexity	Medium
Audience	Architects, designers
Result	Performance evaluation support
Input	UML models
Short description	An approach for software performance engineering (SPE) by annotating UML design artefacts with software performance related properties and, based on this elaborated annotation concept, to evaluate and simulate the assets and to use metrics for the selection of assets or asset groups from a repository. A concept for the annotation of SPE-related information in UML, and a guideline describing where to model what kind of SPE information are provided, together with a feasibility analysis of the annotation concept with standard UML design tools and the concept for deriving evaluation models out of the annotations.
Interesting points	Adaptation to standard tools
To detailed description
Owner / participants	Siemens
Deliverable	CAFÉ CWD3.3: "Product Derivation and Family Evolution", chapter 4 "Performance Analysis & Engineering" CAFÉ E3.1.1-E3.2.1: "The Annotation Framework with derived Implementation Templates and the Derivation of QoS-Evaluation models from UML-Annotations" CAFÉ E3.1.2-E3.2.2: "Annotations for Component-based Realisation Support and the Exploitation of QoS-Properties & -Metrics for the System Family Asset Selection" CAFÉ E3.1.3-E3.2.3: "Mapping SW-Connectors onto Interface Descriptions & Aggregation of QoSEvaluation Models and their Back- Propagation into the UML Design"

Name	Managing System-Level Asset Bases
Process phases	3, 4, 5, 9, 10, 11
Complexity	Medium
Audience	Architects, designers
Result	Synchronised development and derivation of the system-level assets in a multi-site, multi-project and multi-partner environment, enabled by commitment traceability
Input	Commitments to decisions concerning assets of system development programs
Short description	Commitment traceability is proposed for maintaining the end-to-end system feature focus throughout the system development and for reducing the complexity of managing and co-ordinating the system feature implementation at various layers of a system-level product (system, product, platform, etc.). System features are used as the common denominator between all the parties and layers of a system-level product development program. Any system feature related development commitments between the parties will be recorded in the commitment traceability repository. A commitment traceability "node" consists of a triplet: system features to be implemented, resources and schedule for implementing them. Changes in the commitments between any parties at any level will be propagated via the commitment traceability network between the affected parties.
Interesting points	The commitment traceability repository has been prototyped with a tool (OptiWise)
To detailed description see also #Feature-change-management
Owner / participants	Nokia
Deliverable	CAFÉ CWD3.3: "Product Derivation and Family Evolution", chapter 5 "Product Construction"

Name	CMMI-SFE (V&V) for Nokia
Process phases	3, 4, 5, 9, 10, 11
Complexity	Low
Audience	Architects, designers, process responsibles
Result	Assessment for verification and validation (V&V)
Input	Process data
Short description	Nokia plans to establish a new tentative CMMI scope “CMMI for System Family Engineering (CMMI-SFE)” in addition to existing CMMI scopes (SE/SE/IPPD/SS) w.r.t. V&V. The current CMMI is modified by presenting SFE amplifications for existing specific practices within goals of V&V PAs (VER, VAL) amplification. Titles are: “For SFE” (for both domain and application engineering or their relationship), “For SFE – Domain Engineering”, and “For SFE – Application Engineering” (rarely because this is close to CMMI-SE/SW)
Interesting points	No details available
To detailed description: none available
Owner / participants	Nokia
Deliverable	CAFÉ CWD4.1: "Test strategy, methodology & process", chapter 5 "Product line testing process framework"

Name	Extending the Development V for the Family Test Process Framework
Process phases	3, 4, 5, 6, 9, 10, 11, 12
Complexity	Low
Audience	Testers, Process responsibles
Result	Extended V-model for testing
Input	Test process information
Short description	Testing & integration activities for incremental development of families were identified and where in the development cycle these activities fit; component integration activities were identified and where these activities fit in the development cycle. The results were used to extend the V-model, and roles and tasks were identified. Rocket diagrams were used.
Interesting points	No details available, reference to PCWD PH-WP4.1-PCWD1 and PH-WP4.1-PCWD2
To detailed description: none available
Owner / participants	Philips
Deliverable	CAFÉ CWD4.1: "Test strategy, methodology & process", chapter 5 "Product line testing process framework"

Name	Nokia’s Product Line Testing Practices
Process phases	3, 4, 5, 6, 9, 10, 11, 12
Complexity	Medium
Audience	Testers, Process responsibles
Result	Synchronisation of testing activities and deliverables between system family projects
Input	Test process information
Short description	Maximising reuse by minimising variations where it is not necessary; use of templates & SOPs with supportive infrastructures to facilitate reuse. Prioritisation of the reuse in the platform programs. Using common processes & terminologies throughout all family product line programs, enforcing the use of common master test plan templates and other templates. Common infrastructures for planning and monitoring testing related activities & statuses. In small & simple system family products, the platform organisation plays an active role, in large & complex system family products, application organisations play the active role in planning for producing reusable test assets.
Interesting points	Practical experience, various different project sizes
To detailed description:
Owner / participants	Nokia
Deliverable	CAFÉ CWD4.1: "Test strategy, methodology & process", chapter 6 "Product line test planning & preparation"

Name	Configuration Management for System Family Testing Assets
Process phases	3, 4, 5, 6, 9, 10, 11, 12
Complexity	Medium
Audience	Testers
Result	A configuration management approach for test assets
Input	Current process and test assets
Short description	Integration of test assets with development assets under configuration management from the reference architecture under CM; a model that associates a version of a development asset with the corresponding version of a test asset is defined.
Interesting points	Analysis of tool support
To detailed description:
Owner / participants	Telvent
Deliverable	CAFÉ CWD4.1: "Test strategy, methodology & process", chapter 8 "Product line test management and support"

Name	Scenario-Based Test Case Derivation and Evolution
Process phases	3, 4, 5, 6, 9, 10, 11, 12
Complexity	Medium
Audience	Requirements engineers, architects, testers
Result	Reusable test cases with variability
Input	Use cases, scenarios
Short description	Test cases are derived from use cases with traceability support. To structure the trace information a scenario based and meta-model-driven approach is used. First, all use case scenarios are created and refined, then for each use case scenario, test cases are created, then each test case is refined into a system or integration test and expected failure tests are created.
Interesting points	Approach has been validated and successfully integrated into the Siemens MED HS testing process
To detailed description: see also #Test-Derivation-Validation
Owner / participants	University of Duisburg-Essen
Deliverable	CAFÉ CWD4.1: "Test strategy, methodology & process", chapter 8 "Product line test management and support" CAFÉ E4.2.1: "Use Case- and Architecture-based Derivation of Generic Test Cases for System and Integration Tests for Software Product Families" CAFÉ E4.2.3-E4.2.4: "An Initial Technique for Deriving Test Cases for System and Integration Testing of Software Product Families"

Name	Automatic Test Synthesis from High Level Scenarios
Process phases	3, 4, 5, 6, 9, 10, 11, 12
Complexity	Medium
Audience	Requirements engineers, architects, testers
Result	Automatic derivation of test cases dedicated to a specific product from a (set of) generic scenario(s)
Input	Use cases, scenarios
Short description	First step: building test patterns selected from use case scenarios; second step: deriving the test patterns and generating concrete test cases; use of the tools TGV/UMLaut
Interesting points	Tool UMLaut
To detailed description:
Owner / participants	INRIA
Deliverable	CAFÉ CWD4.2: "Test modelling and tooling", chapter 2 "Test case derivation"

Name	Testing from Natural Language Requirements
Process phases	3, 4, 5, 9, 10, 11
Complexity	Medium
Audience	Designers, testers
Result	Test cases
Input	Use Cases enriched with a notion of variability
Short description	Analysis of natural-language requirements for the assessment of testability of a product family; usage of techniques for natural-language processing techniques; analysis of the software requirements of a product family finalised to the early assessment of testability
Interesting points	No details available
To detailed description: No details available
Owner / participants	IEI
Deliverable	CAFÉ CWD4.2: "Test modelling and tooling", chapter 3 "Testware evaluation and adaptation"

Name	Testing of Non-Functional Requirements
Process phases	3, 4, 5, 6, 9, 10, 11, 12
Complexity	Medium
Audience	Designers, testers
Result	Test cases
Input	Architecture
Short description	Static architecture testing with ATAM, SAAM, ARID; model-based testing includes a family of test planning and specification techniques that derive test material (test conditions or test cases) from abstract system and component models.
Interesting points	No details available
To detailed description: Reference to NOK-WP4-2-PCWD1-V001.000.ppt
Owner / participants	Nokia
Deliverable	CAFÉ CWD4.2: "Test modelling and tooling", chapter 3 "Testware evaluation and adaptation"

Name	Test Process and Implementation
Process phases	3, 4, 5, 6, 9, 10, 11, 12
Complexity	Medium
Audience	Testers, process responsibles
Result	Test process
Input	Design process
Short description	Test levels and phases for each level are defined with documents for each phase. Roles and responsibilities are described, as well as test assets: Test Concept, Test Plan, Test Design, Test Specification, Test Frame, Test Protocol, and Test Report. Regression tests and metrics are defined, together with regression test selection methods. Five test case prioritisation methods are presented to selected the best-fitting regression test suite.
Interesting points	Regression test selection and prioritisation
To detailed description:
Owner / participants	Siemens
Deliverable	CAFÉ CWD4.2: "Test modelling and tooling", chapter 4 "Test modelling" CAFÉ E4.3: "Test Process and Implementation" CAFÉ E5.4.1: "Test Process Validation"

Name	Scenario Based Test Case Derivation
Process phases	3, 4, 5, 6, 9, 10, 11, 12
Complexity	Medium
Audience	Testers, requirements engineers
Result	Test cases
Input	Use cases, scenarios
Short description	The approach consists of three major steps: 1. For each use case: create use case scenarios; 2. for each scenario: create generic test case designs; 3. for each test case design: implement test case. Test documents are described.
Interesting points	Validation in medical domain
To detailed description: see also #Test-case-derivation
Owner / participants	Siemens, University Duisburg-Essen
Deliverable	CAFÉ CWD4.2: "Test modelling and tooling", chapter 4 "Test modelling" CAFÉ E4.2.1: "Use Case- and Architecture-based Derivation of Generic Test Cases for System and Integration Tests for Software Product Families" CAFÉ E4.2.3-E4.2.4: "An Initial Technique for Deriving Test Cases for System and Integration Testing of Software Product Families"

Name	Validating Architectural Concepts with Modelling and Simulation
Process phases	3, 4, 5, 9, 10, 11
Complexity	Medium
Audience	Architects
Result	Petri-net model of architecture concepts
Input	Architecture concepts
Short description	Phone features are simulated with a high-level behavioural/structural model built as a coloured Petri net. The model captures the user interface infrastructure software (UI architecture) and applications (features) of a mobile phone.
Interesting points	Coloured Petri nets
To detailed description:
Owner / participants	Nokia
Deliverable	CAFÉ CWD4.3: "Validation", chapter 2 "Model-based Analysis of Specific Properties"

Name	Validation of Dynamic Properties of Architectures with Respect to Reliability and Safety
Process phases	3, 4, 5, 9, 10, 11
Complexity	High
Audience	Architects, designers
Result	Modelling the dynamic behaviour on architectural level incl. real-time aspects plus automated analysis (reachability, formal verification)
Input	Dynamic system behaviour
Short description	State-transition system models are used to describe dynamic behaviour which can be extended to capture real-time requirements and performance constraints. Timing constraints are described by conditions on discrete state transitions and resets of clock variables. Four different entities were identified that influence the quality of real-time synchronous data: deviations or uncertainty in the provided value, deviations or uncertainty in the reference time of the provided value, provision delay, and processing jitter. These entities can be used to describe the requirements or, as a result of system analysis, the behaviour of the system or its components.
Interesting points	Validation of real-time behaviour
To detailed description:
Owner / participants	Bosch
Deliverable	CAFÉ CWD4.3: "Validation", chapter 2 "Model-based Analysis of Specific Properties" CAFÉ E4.1.1: "Validation of Dynamic Properties of Architectures with Respect to Reliability and Safety"

Name	Summary of UML Model Validation Techniques
Process phases	3, 4, 5, 9, 10, 11
Complexity	Medium
Audience	Architects, designers
Result	Guidelines for reviewing UML models with respect to completeness, correctness, and consistency in the product family context
Input	UML model
Short description	Completeness checks: Measure of the inclusiveness. Is all the knowledge related to the product expressed in the models? Is there something missing? Correctness: All of the models are following the rules. Standard UML notation, architectural concepts, rules and recommendations defined for the product line. Consistency: Between elements of the model and between different products in the product line; traceability between different UML models, traceability between different levels of models, between UML models and different product line artefacts.
Interesting points	UML style guide
To detailed description: Reference to NOK-WP4-3-PCWD2-V001_000.ppt
Owner / participants	Nokia
Deliverable	CAFÉ CWD4.3: "Validation", chapter 3 "Model-based analysis of generic properties"

Name	Annotated Catalogue of Patterns for Reliability and Safety
Process phases	3, 4, 5, 9, 10, 11
Complexity	Medium
Audience	Architects
Result	Architecture patterns for reliable and safe systems
Input	Requirements
Short description	Definition of an analysis model for fault tolerance with an extension of structure-function modelling, classification of root causes, and definition of failure semantics classes for embedded control systems, that is suitable for evaluation of FT patterns and allows systematic documentation and comparison of dynamic fault tolerance mechanisms. Collection of FT-patterns with quality attribute impact analysis and definition of the pattern-oriented design and evaluation process plus definition of a FT pattern description template.
Interesting points	FT patterns
To detailed description:
Owner / participants	Bosch
Deliverable	CAFÉ CWD4.3: "Validation", chapter 4 "Constructive approaches to support validation" CAFÉ E4.1.2: "Architectural Styles and Software Design Patterns for Safe and Reliable Real-Time Embedded Systems"

Name	Feature Logic-Based Configuration Management Models
Process phases	All
Complexity	High
Audience	Architects, designers, requirements engineers
Result	General meta model for configuration management, encompassing most known CM approaches
Input	Know-how about documents, components, and other assets that are subject to change
Short description	Feature logic-based C&CM involving generic product line meta-modelling with generic product line models, change models, change and configuration management middleware layer. Supported by tool process knowledge & content base
Interesting points	Systematic, thorough theory based on feature logic
To detailed description
Owner / participants	Fraunhofer IESE
Deliverable	CAFÉ CWD3.2: "Configuration and Version Management", chapter 1 "Theory" CAFÉ E3.5: "Feature Logic-oriented Configuration Management for SPL"

Name	Configuration Management Process: Support & Tools for Process Support
Process phases	All
Complexity	Low
Audience	Architects, designers, requirements engineers
Result	Configuration management process
Input	Know-how about documents, components, and other assets that are subject to change
Short description	Process and architecture description for adding an OS component to a system family
Interesting points	Tool support
To detailed description
Owner / participants	Telvent
Deliverable	CAFÉ CWD3.2: "Configuration and Version Management", chapter 2 "Process Support"

4. Methods for Phase 4: Domain Analysis

Name	A Derivation Tool Chain Based on Mapping Techniques & Variability Mechanisms
Process phases	4, 5, 10, 11
Complexity	Medium
Audience	Architects
Result	Product derivation support by variability and decision modelling
Input	Architecture information
Short description	Modelling support for variability and decision model in UML, and to derive product line models with variability using model mapping techniques. A software product line engineering approach is proposed based on a Model Driven Engineering approach, compliant with the MDA. Variability and decision model meta-models have been developed, and transformation rules have been designed for deriving product line models. A derivation tool chain has been specified and a prototype has been developed.
Interesting points	Tool chain proposal
To detailed description
Owner / participants	Thales
Deliverable	CAFÉ CWD3.3: "Product Derivation and Family Evolution", chapter 1 "Variability Engineering"

Name	Automated Retrieval of Design Assets in a System Family Design Approach
Process phases	4, 5, 6, 10, 11, 12
Complexity	Medium
Audience	Architects, designers
Result	Identification of design assets by support for description and organisation, search and retrieval, reuse and adaptation of design assets
Input	Information about design assets, especially software components, software architectures, patterns and templates for software solutions
Short description	Design assets are described with UML. Design retrieval relies on case-based reasoning (CBR) techniques. A tool connection to Rationale Rose has been realised to allow access to the different UML specifications defining design assets. The UML metamodel has been extended to allow the descriptions of the various design assets. Several search and retrieval techniques have been investigated and evaluated to see if they are applicable for design asset retrieval.
Interesting points	Usage of case-based reasoning
To detailed description
Owner / participants	Johannes Kepler University Linz
Deliverable	CAFÉ CWD3.3: "Product Derivation and Family Evolution", chapter 3 "Component Identification & Adaptation"

Name	Configuration and Derivation of Product Architectures
Process phases	3, 4, 5, 9, 10, 11
Complexity	Medium
Audience	Architects
Result	Architecture with variability
Input	Assets of existing systems
Short description	Concept for modeling variability among requirements; description of important architectural views, their interrelations, and how they are affected by variability; concept for representing variation points at the architectural level; meta model that documents basic relationships between feature and architecture variability; concept for integrating product line architectures into a feature-driven product configuration methodology
Interesting points	Binding variability on a feature basis
To detailed description
Owner / participants	Bosch
Deliverable	CAFÉ CWD3.3: "Product Derivation and Family Evolution", chapter 1 "Variability Engineering" CAFÉ E3.4.2 "Methodology for Product Configuration in the Context of Product Lines"

Name	Models for Performance Analysis
Process phases	3, 4, 5, 9, 10, 11
Complexity	Medium
Audience	Architects, designers
Result	Performance evaluation support
Input	Performance model
Short description	Creating a performance model up-front: Before the components are actually developed, results of the models are input for the requirements phase; specifying and developing tests to measure the actual performance, using the tests to calibrate the performance models, executing the tests as regression test; sharing the models with customers of the components; models are part of the component specification (as a tool for the system architect)
Interesting points	No information available
To detailed description: No information available
Owner / participants	Philips
Deliverable	CAFÉ CWD3.3: "Product Derivation and Family Evolution", chapter 4 "Performance Analysis & Engineering"

Name	Certifying and Releasing Software Components for Use in Product Lines
Process phases	3, 4, 5, 6, 9, 10, 11, 12
Complexity	Low
Audience	Testers, Process responsibles
Result	Improved test process
Input	Test process information
Short description	For defect prevention: Reviewing specifications on testability, providing requirements traceability, doing static code analysis each night, automated regression testing each night, work in progress deliveries, resource usage testing
Interesting points	No details available, reference to PCWD PCWD PH-WP41-PCWD6
To detailed description: none available
Owner / participants	Philips
Deliverable	CAFÉ CWD4.1: "Test strategy, methodology & process", chapter 6 "Product line test planning & preparation"

Name	Testing Patterns in Product Line Context
Process phases	3, 4, 5, 6, 9, 10, 11, 12
Complexity	Low
Audience	Testers
Result	Test patterns
Input	Architecture
Short description	Pattern template: Problem / motivation; context; forces; solution / implementation issues; resulting context / consequences; known uses; related patterns
Interesting points	No details available
To detailed description: Reference to NOK-WP4-2-PCWD2-V001.001.ppt & NOK-WP4-2-PCWD3-V001.003.xls
Owner / participants	Nokia
Deliverable	CAFÉ CWD4.2: "Test modelling and tooling", chapter 4 "Test modelling"

5. Methods for Phase 5: Domain Design

Name	Platform Independent and Platform Specific Modelling: Approaches for the PSM Layer
Process phases	5, 6
Complexity	Medium
Audience	Designers
Result	PSM Model
Input	Meta-models, PIM
Short description	An example for a PSM using an EJB metamodel, an EJB profile, a CORBA component model (for the IDL), and a CORBA profile
Interesting points
To detailed description
Owner / participants	Thales
Deliverable	CAFÉ CWD2.2: "Platforms", chapter 4 "Platform Independent and Platform Specific Modelling"

Name	Platform Independent and Platform Specific Modelling: PIM to PSM Transformation
Process phases	3, 4, 5, 6
Complexity	Medium
Audience	Architects, designers
Result	PSM model
Input	PIM model
Short description	Model transformation from PIM to PSM
Interesting points	Examples and comparisons of the approaches from Thales, ICT Norway, INRIA
To detailed description
Owner / participants	Thales, ICT Norway, INRIA
Deliverable	CAFÉ CWD2.2: "Platforms", chapter 4 "Platform Independent and Platform Specific Modelling"

Name	Platform Independent and Platform Specific Modelling: Tools for Model Transformation
Process phases	3, 4, 5, 6
Complexity	Medium
Audience	Architects, designers
Result	PSM Models
Input	PIM Models
Short description	UMLAUT (INRIA) and UMT (Sintef) are tools to transform UML2 models, documented in XML, to code
Interesting points	Examples
To detailed description
Owner / participants	INRIA, Sintef
Deliverable	CAFÉ CWD2.2: "Platforms", chapter 4 "Platform Independent and Platform Specific Modelling"

Name	Concurrency Design in PF Reference and Specific Product Architecture
Process phases	5, 6, 11, 12
Complexity	Medium
Audience	Designers
Result	Alternative implementation designs, analysis of constraints for each alternative solution of each implementation design in a tool. Evaluation of tool based solution
Input	A sample logical design, timing constraints, selection of tools
Short description	Starting from a logical collaboration model, alternative designs are explored. As physical design models subsystem mapping, events response flow mapping, and mixed models are considered. Subsystem process scenarios are compared.
Interesting points	Tool evaluation (Rhapsody)
To detailed description
Owner / participants	Nokia
Deliverable	CAFÉ CWD2.4: "Assets Development Support", chapter 2 "Product Family Architecture Support"

Name	Reverse Engineering of a Specific Product Architecture and Abstraction of a PF Reference Architecture
Process phases	5, 6, 11, 12
Complexity	Medium
Audience	Architects, designers
Result	Architectural and design documents; reference architecture; component view
Input	Requirements, design documents, code
Short description	From the existing design documentation, the conceptual architecture of the system is deduced. This is used to configure the tools and extract an architectural model. The components are identified and classified to create the component view. The dependencies among the components are analysed to detect the undesired dependencies (to be removed from the platform) and the usage dependencies among the modules. The architecture and the variation points in the platform are documented. The reference architecture is deduced.
Interesting points
To detailed description
Owner / participants	Nokia
Deliverable	CAFÉ CWD2.4: "Assets Development Support", chapter 2 "Product Family Architecture Support"

Name	Configuration and Version Management for Component Based Product Families
Process phases	5, 6, 11, 12
Complexity	Medium
Audience	Architects, designers
Result	Version management, naming conventions
Input	Know-how about documents, components, and other assets that are subject to change
Short description	The version management process is split into investigation phase and realisation phase; a check-in procedure for configuration management has been defined, together with naming conventions. The release and maintenance model is based on the version management process.
Interesting points	Usage in a product population environment
To detailed description
Owner / participants	Philips
Deliverable	CAFÉ CWD3.2: "Configuration and Version Management", chapter 3 "Component Based Product Families"

Name	Migration of Existing System Assets to Families
Process phases	5, 6
Complexity	Medium
Audience	Architects, designers
Result	Migration of assets of existing systems to a system family
Input	Assets of existing systems
Short description	Configuration and version management are used to migrate assets of an existing system to a component based product family. Procedures to manage component based versions in a family line across multiple projects are provided, together with a model for component release and maintenance and component change control. Wrapping of old (legecy) code in such a way that it conforms to the requires and provides interfaces.
Interesting points	Multi-project management
To detailed description
Owner / participants	Philips
Deliverable	CAFÉ CWD3.2: "Configuration and Version Management", chapter 5 "Migration of existing system assets to families"

Name	Semantic Component Interface Descriptions for Realisation Support
Process phases	5, 6, 11, 12
Complexity	Medium
Audience	Architects, designers
Result	Interface descriptions with semantic information
Input	Information about component behaviour
Short description	An approach to provide a description mechanism that allows to associate semantic information to components and component interfaces. This mechanism is a general means for structuring and handling the description process which is achieved by offering the possibility to define templates according to the needs of the users. This contribution also presents the MSC connector concept as a particular means to describe interface protocols i.e., the behaviour of interacting components.
Interesting points	Systematic approach, full framework, MSC connectors
To detailed description
Owner / participants	Siemens
Deliverable	CAFÉ CWD3.3: "Product Derivation and Family Evolution", chapter 2 "Interface Description & Utilisation" CAFÉ E3.1.1-E3.2.1: "The Annotation Framework with derived Implementation Templates and the Derivation of QoS-Evaluation models from UML-Annotations" CAFÉ E3.1.2-E3.2.2: "Annotations for Component-based Realisation Support and the Exploitation of QoS-Properties & -Metrics for the System Family Asset Selection" CAFÉ E3.1.3-E3.2.3: "Mapping SW-Connectors onto Interface Descriptions & Aggregation of QoSEvaluation Models and their Back- Propagation into the UML Design"

Name	A Laboratory Experiment to Study Component Functionality in a MetaCase Environment
Process phases	5, 6, 11, 12
Complexity	Low
Audience	Architects, designers
Result	Information about metaCASE environments
Input	Design models
Short description	Empirical study of component-based reuse in system analysis and design. Based on a conceptual framework built in prior research, a component meta model is provided and used to define the design models as components. A test case is developed and the laboratory experiment is designed to study the usability of components in system analysis and design and the supporting functionality provided by a metaCASE environment
Interesting points	Case study
To detailed description
Owner / participants	University of Jyväskylä
Deliverable	CAFÉ CWD3.3: "Product Derivation and Family Evolution", chapter 2 "Interface Description & Utilisation"

Name	Testing Framework-Based Software Product Families
Process phases	5, 6, 11, 12
Complexity	High
Audience	Testers, Process responsibles
Result	(OO-) Framework-based testing theory, hot spot coverage theory
Input	Test process information, OO framework
Short description	Hot spot coverage is based on connections between framework-level components, called hot spots. A hot spot or a hook is an expandable element in a framework instantiation or a framelet. A template is a class in a framework instantiation or a framelet that implements an interface to one or more hooks. A template and a hook may be the same class in which case a hot spot expands functionality of a class in a framework instantiation or a framelet. The hot spot coverage is based on independent paths that start from a known template class and traverse through expanded hot spots. A full hot spot coverage includes all independent paths via all connected hot spots. A hot spot is connected if its functionality has been expanded by hand-written code or a framelet.
Interesting points	RITA tool
To detailed description: Reference to PCWDs: UH-WP4-1-PCWD2-V003.000.ppt, UH-WP4-1-PCWD1-V003.000.ppt
Owner / participants	University of Helsinki
Deliverable	CAFÉ CWD4.1: "Test strategy, methodology & process", chapter 7 "Product family test execution and analysis"

Name	Test Case Derivation from State Charts
Process phases	5, 6, 11, 12
Complexity	Medium
Audience	Designers, testers
Result	Automatic derivation of test cases dedicated to a specific product from a (set of) generic scenario(s)
Input	Use cases, scenarios
Short description	State charts are generated from the information of the requirements and the design documents by the designers and testers. The state charts are the testable model of the requirements. Each transition is a test case, and they are linked to the requirements associating to each transition and state the requirements that they model. The test case design is implemented by the test data. The test data contain the information of the test design specification written in tabular form.
Interesting points	Uses INRIA's approach
To detailed description: Reference to UPM-WP4-2-PCWD1_V000.005.ppt
Owner / participants	DIT - UPM
Deliverable	CAFÉ CWD4.2: "Test modelling and tooling", chapter 2 "Test case derivation"

Name	Testability Analysis of Product Line Architectures
Process phases	5, 6, 11, 12
Complexity	Medium
Audience	Testers, designers
Result	Detecting, pinpointing and suppressing potential testability weaknesses of a UML class diagram
Input	OO class diagram
Short description	The focus is on two specific testing difficulties, arising from static design ambiguities, and non-statically decidable concurrent use of the same objects by a common client. These conflicts correspond to specific topological configurations (anti-patterns) that can be detected from the class diagram. These configurations can be made less complex, or even completely avoided at a sub-system level. This includes using informal analyses and advice on how to improve class diagrams, and inclusion of explicit constraints for the implementation. When it is possible, interface classes and dedicated stereotypes are used.
Interesting points	Class dependency graph
To detailed description:
Owner / participants	INRIA
Deliverable	CAFÉ CWD4.2: "Test modelling and tooling", chapter 4 "Test modelling" CAFÉ CWD4.3: "Validation", chapter 4 "Constructive approaches to support validation", 4.2 "Design patterns for testability"

Name	UML Model Simulation Based on the UMLAUT Framework
Process phases	5, 6, 11, 12
Complexity	High
Audience	Architects
Result	Simulation of an UML model
Input	Architecture or design model in UML
Short description	Action semantics are used for transforming an UML model into an executable one representing the simulator. The new model will contain abstract classes that represent the reification of the concepts relevant to simulation (states, messages, timers) and classes representing the simulation engine that manipulates them. The UMLAUT Simulator compiles the UML model into an input/output labeled transition system to weave the various semantics aspects of UML into the subsets. Exhaustive simulation starts with an initial state, explores all possible outcomes (fireable transitions) recursively and stores and compares global states = (dynamic) unions of local states.
Interesting points	UMLaut tool
To detailed description:
Owner / participants	INRIA
Deliverable	CAFÉ CWD4.3: "Validation", chapter 2 "Model-based Analysis of Specific Properties"

Name	Domain-Oriented Software Asset Management
Process phases	3, 4, 5
Complexity	Medium
Audience	Architects, designers
Result	Managing the consistency of the entire product family, managing and developing the product line architecture (variance, non-functional requirements), management of individual products: combinatorial explosion, definition and management of product configurations, change management and traceability of development decisions
Input	Know-how about design artefacts
Short description	Meta-models for the domain; extending software configuration management to being a part of the concept of work; making a clear separation between configuration management, version control, and work contexts; focusing on information storing and processing, and studying each dimension as a separate area to be supported for human working.
Interesting points	Tool analysis
To detailed description
Owner / participants	Nokia
Deliverable	CAFÉ CWD3.2: "Configuration and Version Management", chapter 4 "Domain-oriented software asset management"

Name	Test Evolution
Process phases	3, 4, 5, 6, 9, 10, 11, 12
Complexity	Low
Audience	Testers, architects
Result	Improved test cases
Input	Test strategies, requirements, old test cases
Short description	Instead of describing complete test cases from scratch, the test design strategies to be used are listed per requirement, indicating important values and their ‘why’, indicating persistency of these test cases, and indicating their criticality.
Interesting points	Example
To detailed description:
Owner / participants	Philips
Deliverable	CAFÉ CWD4.1: "Test strategy, methodology & process", chapter 8 "Product line test management and support"

Name	Evolution of System Family Interfaces
Process phases	4, 5, 6, 10, 11, 12
Complexity	Medium
Audience	Architects
Result	Interface descriptions for the detailed architecture
Input	Coarse architecture, interface information
Short description	A systematic approach to set up, deploy and manage evolving interfaces in design models (UML) for large product families; guidelines for defining interface packages and change control process for these interface packages. Generation of interfaces in the code (i.e. a set of idl-files) from the interfaces in the design model.
Interesting points	Usage of metrics
To detailed description
Owner / participants	Philips
Deliverable	CAFÉ CWD3.3: "Product Derivation and Family Evolution", chapter 2 "Interface Description & Utilisation"

6. Methods for Phase 6: Domain Implementation

Name	Generation of Specific Product Code
Process phases	6, 12
Complexity	Medium
Audience	Implementers
Result	Feasibility report of the (automatic) code generator evaluation; code generator SW design specification; source code of the generator
Input	Code generation requirements, Rose model including classes and source code templates
Short description	The feasibility of a tool to automatically generate code from object models and code templates is evaluated for the medical systems domain.
Interesting points	Practicability
To detailed description
Owner / participants	Philips
Deliverable	CAFÉ CWD2.4: "Assets Development Support", chapter 3 "Product Family Implementation Support"

Name	Modeling of PF Reference Behaviour and Derivation of Specific Product Behaviour Models
Process phases	5, 6, 11, 12
Complexity	Medium
Audience	Architects, designers
Result	Extended message sequence charts (MSCs)
Input	Behaviour described with message sequence charts
Short description	Message sequence charts are extended to express virtuality (in one MSC, that is refined in another MSC), optional variability, variation points, and additional constraints
Interesting points	Examples
To detailed description
Owner / participants	INRIA
Deliverable	CAFÉ CWD2.4: "Assets Development Support", chapter 2 "Product Family Architecture Support"

7. Methods for Phase 7: System Definition

No Methods defined in Café for this phase of the process.

8. Methods for Phase 8: System Economical Analysis

No Methods defined in Café for this phase of the process.

9. Methods for Phase 9: System Analysis / Design

Name	Derivation of Applications from Web Services
Process phases	3, 4, 5, 9, 10, 11
Complexity	Medium
Audience	Architects, designers
Result	System families based on web-based services
Input	Requirements
Short description	With the new technology of web services and the Web-Oriented Programming (WOP) paradigm, it becomes possible to define system families that are based entirely on web-based assets. This approach defines quality variability to support products of the same family that differ in quality. A quality trader will play the role of an intermediate agent between clients and suppliers of services taking into account quality aspects. This trader will be used in order to solve the problem of choosing the service that best matches the quality requirements
Interesting points	First approach that uses system families and Multi-Organisational Web-based Systems (MOWS) together
To detailed description
Owner / participants	Telvent
Deliverable	CAFÉ CWD3.3: "Product Derivation and Family Evolution", chapter 5 "Product Construction"

10. Methods for Phase 10: Application Analysis"

Name	Design Patterns for Configuring a Product as a Specialisation of a Product Line
Process phases	4, 5, 10, 11
Complexity	Medium
Audience	Architects
Result	Architecture description with variability in UML class models
Input	Architecture information
Short description	Pattern for variant modelling in UML class diagram; OCL generic constraint at the metamodel level, checked on product line models; OCL specific constraints at the metamodel level, checked on a product model, derived from a product line model; pattern for variability specification.
Interesting points	UMLAUT tool
To detailed description
Owner / participants	INRIA (IRISA)
Deliverable	CAFÉ CWD3.3: "Product Derivation and Family Evolution", chapter 1 "Variability Engineering"

11. Methods for Phase 11: Application Design

No Methods defined in Café for this phase of the process.

12. Methods for Phase 12: Application Implementation

No Methods defined in Café for this phase of the process.

13. Documents Considered for Café

This section lists the documents that have been considered for the contents of this report, together with keywords characterising the documents' contents. These keywords are also a way to retrieve methods for system family engineering. Click into the icon.

BS00851A.gif (2308 Byte)