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

1. Methods for Phase 1: System Family Scoping

Name	Scoping
Topic	General description of scoping, references to methods and tools. More detailed description in Esaps E2.2b.
Process phases	1, 2, 7, 8
Complexity	Medium
Audience	Product managers, architects
Result	Domain description, product portfolio
Input	Domain analysis, market analysis
Short description	Scoping is the process of identifying and bounding the focus of development for reuse in product line development. Product line scoping is the process of systematically developing a Product Portfolio Definition. A Product Portfolio Definition is a description of the specific requirements and the individual products that should be part of the product line. Domain scoping is the process of identifying appropriate boundaries for a domain which is relevant for implementing systems in the product line. Asset Scoping is the process of identifying the various elements that should be made reusable, i.e., the specific assets that should be part of the reuse infrastructure as opposed to being developed application specific. Bosch, Fraunhofer IESE, and Siemens address the planning phase of product lines, University of Karlskrona/Ronneby and University of Groningen the evolution of scope over time.
Interesting points	Using the approach we have a means of evaluating the cost (i.e., additional/ saved effort, time-to-market, etc.) of developing a certain feature using a product line approach versus using a one-at-a-time approach. This is done and graphically depicted using a so-called product map. A product map is a table that consists of a list of features, structured into domains on the vertical axis and a list of the products along the horizontal axis.
To detailed description
Owner / participants	Fraunhofer IESE (ed.), Robert Bosch GmbH, Siemens AG, University of Karlskrona/Ronneby, University of Groningen
Deliverable	Esaps CWD1.2.4: "Scoping" Esaps E2.2b: "A Method for Scoping Software Product Lines From a Functional Point of View"

Name	Quality models for asset scoping
Topic	Quality models for product lines, enabling the evaluation of reusable assets, as basis for the optimisation of the asset scope
Process phases	1, 2
Complexity	Medium
Audience	Product managers, architects, designers
Result	Product map
Input	Quality requirements, information about assets
Short description	The quality models building the base for the PuLSE Eco scoping approach. A quality is modelled as a function of a feature, together with its development context and the product context. This is extended for product lines and used as basis in the product line map where the quality values are used to define the products of the product line.
Interesting points	The development situation can be taken into account.
To detailed description
Owner / participants	Fraunhofer IESE
Deliverable	Esaps CWD1.3: "Aspect Analysis and Modeling", section 3.1 "IESE - Using Aspects to Scope the Product Line"

Name	SPLIT : Software Product-Line Integrated Technology
Topic	1. Requirements description and categorisation 2. Aspect analysis for requirements specification 3. Configuration and deployment onto an execution platform 4. Prototype for System family engineering, based on COTS tools
Process phases	All
Complexity	Medium-high
Audience	Product managers, architects, designers
Result	a) Requirements description; b) Configuration and deployment of SW components to infrastructure; c) Tool infrastructure, based on COTS
Input	a) Features, unstructured and vague requirements; b) Component and infrastructure description; c) Input for tools
Short description	a) Categorisation and separation of requirements: functional vs. non-functional, capabilities (operational services) vs. forces (non-functional services). b) How to map SW components to SW infrastructure (OS, libraries, business frameworks) c) Realisation with tools, based on COTS (DOORS, Rational Rose)
Interesting points	How to find, structure, classify and represent the assets built during requirements engineering in *SPLIT* - Software Product-Line Integrated Technology - from LCAT, the common laboratory of Alcatel and Thales (Thomson-CSF). For applications of SPLIT see #Requirements of switch maintenance and #air supervision The SPLIT/WHEELS process is described in #SPLIT-process For requirements traceability and change management in SPLIT (SPLIT/Cloud) see #Traceability-SPLIT For variability representation and resolution in SPLIT see #Variability-resolution and for product derivation see #SPLIT-derivation
To detailed description Requirements (a)) To detailed description Deployment (b)) To detailed description tools (c))
Owner / participants	Alcatel, Thales (LCAT)
Deliverable	Esaps CWD2.2.1: "System Family Requirements Classification and Formalisms" (a)) Esaps CWD1.3: "Aspect Analysis and Modeling"; section 2.1: "Thales - Air Supervision Systems: aspect analysis"; section 2.2: "Alcatel - Switch Maintenance Systems: aspect analysis" Esaps CWD2.3 "Platform and components, section "Configuration and deployment onto an execution platform" (b)); Esaps CWD2.3 "Platform and components, section "Wrapping existing components of switch maintenance systems" Esaps CWD2.3 "Platform and components, section "Development support prototype for system families based on COTS" (c)) Esaps CWD3.1: "Requirements Modelling and Traceability", section 4: "Requirement traceability support"

Name	Feature analysis
Topic	Identification, processing and description of features
Process phases	1, 2, 3, 4, 7, 8, 9, 10
Complexity	Low
Audience	Product managers, architects
Result	Feature model, part of domain model
Input	Market analysis, product (family) expertise
Short description	Feature analysis can be used as basis of scoping, e.g. in the PuLSE approach (IESE). Features (user-visible product properties) are early indicators for variability. Specific views are essential for feature-based domain analysis (HUT). Configurations of features, mapped to realisation concepts are used as basis for product definition during scoping (Siemens). Feature interactions (dependencies between features) are identified using coloured Petri nets (Nokia).
Interesting points	Features are the basic elements for defining what products shall constitute the family (scooping). So, feature analysis is essential for scoping. Feature interactions can be vary costly to resolve - so identifying them early can save a lot of money.
To detailed description
Owner / participants	Fraunhofer IESE, Helsinki University of Technology (HUT), Nokia, Siemens
Deliverable	Esaps CWD1.2.3: "Feature Analysis"

2. Methods for Phase 2: System Family Economical Analysis

No Methods defined in Esaps for this phase of the process.

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

Name	Conceptual domain analysis
Topic	Description of conceptual domain analysis, modelling techniques, and process; 3 case studies
Process phases	3, 4, 5
Complexity	Low
Audience	Product managers, marketing
Result	Domain model
Input	Market analysis, stakeholder information
Short description	Introduction: In CWD 1.2.1, definitions and descriptions, purpose and role; overview and comparison of existing domain engineering methods. Conceptual domain analysis: The process in which the concepts relevant for a domain are identified, defined, and organised together with their mutual relationships, in order to facilitate a precise and concise description of the domain. The conceptual domain model is the basis for design; there is no general notation - FODA, UML, mind maps, text are used. Case studies: Two from the medical domain: requirements object model and object model for persistent data that are shared between systems or services. One from telecommunications: terminology and features Bosch, Fraunhofer IESE, and Siemens address the planning phase of product lines, University of Karlskrona/Ronneby and University of Groningen the evolution of scope over time.
Interesting points	Three practical examples for a still fuzzy topic.
To detailed description
Owner / participants	Philips, Alcatel
Deliverable	Esaps CWD1.2.1: "Introduction to Domain Analysis"; Esaps CWD1.2.2: "Conceptual domain analysis"

Name	Domain engineering methods
Topic	Description, analysis, and comparison of domain engineering methods
Process phases	3, 4, 5
Complexity	Low
Audience	Product managers, architects
Result	Domain model
Input	Market analysis, stakeholder information
Short description	All domain engineering methods (16) available in literature are described, analysed and compared
Interesting points	Detailed, thorough description and comparison of domain engineering methods
To detailed description
Owner / participants	Bosch
Deliverable	Esaps CWD1.2.1: "Introduction to Domain analysis", section 5 "Overview of existing domain engineering methods" Esaps E2.1d: "Domain Engineering Problem Analysis: An Overview of Methods Supporting Product Line Development / Domain Engineering - Problemanalyse"

Name	Software architecture assessment + metrics
Topic	Description of SW architecture assessment techniques + EPOC assessment report + Architecture Metrics + Architecture assessment with SAA
Process phases	3, 4, 5, 9, 10, 11
Complexity	Small
Audience	Architects
Result	Architecture assessment report + Experience from EPOC assessment + Architecture assessment at Siemens with SAA
Input	An existing architecture
Short description	Architecture assessment methods like SAAM, ATAM, and others are described. Ideas how to evaluate system family architectures are presented. An experience report of an assessment of the EPOC operating systems (used for mobile phones) and software architecture metrics are presented (Blekinge Institute). A detailed description of the architecture assessment method SAA from Siemens is presented in E2.2f.
Interesting points	Real assessment experience report
To detailed description
Owner / participants	Nokia, Ericsson, Blekinge Institute of Technology (Metrics, section 7)
Deliverable	Esaps CWD1.1: "Architecture Analysis and Modelling", sections 3 - 5, 7 Esaps E2.2f: "Methode für die Bewertung von Familienarchitekturen"

Name	Architectural mismatches analysis
Topic	Assessment guidelines for detecting architectural mismatches during systems composition
Process phases	3, 4, 5, 9, 10, 11
Complexity	Medium
Audience	Architects, designers
Result	List of architectural mismatches: sources of future errors
Input	Architectures of components, e.g. COTS or in-house
Short description	Architectural mismatches are inconsistencies between two or more constraints of different architectures being composed. The existence of architectural mismatches can seriously hinder any large-scale reuse effort. A pragmatic approach to detect such mismatches is presented.
Interesting points	One example throughout the whole paper. Real pragmatic approach.
To detailed description
Owner / participants	Fraunhofer IESE
Deliverable	Esaps CWD1.1: "Architecture Analysis and Modelling", section 6 "Architectural Mismatches Analysis" EsapsE2.2a: "Assessment Guidelines for Detecting Architectural Mismatches"

Name	Requirements engineering for system families + Architectural synthesis + Change propagation
Topic	Analysis of commonality, variability and volatility in the requirements specifications
Process phases	3, 4, 5
Complexity	Medium
Audience	Product managers, architects
Result	Requirements model
Input	Features, unstructured and vague requirements
Short description	Structuring requirements in definition hierarchies - from abstract to more concrete goals. The requirement properties and views on requirements are considered. Meta model for product-line requirements defined. Also relations between functional and non-functional properties are considered. The work is extended to architectural synthesis in CWD2.2.3, section 8. An architecture is created by making decision about qualities; these decisions correspond to design increments that are linked to increments in the requirements model. A case study is presented. In CWD 3.2 change propagation and work amount assessment on basis of this approach are presented.
Interesting points	The definition hierarchiy models can be generalized and applied for many purposes
To detailed description
Owner / participants	Helsinki University of Technology (HUT)
Deliverable	Esaps CWD2.2.1: "System Family Requirements Classification and Formalisms", section 3 "HUT - Requirements engineering for system families" Esaps CWD2.2.3: "Style, structures and views for handling commonalities and variabilities", section 8 "Architectural synthesis (HUT)" Esaps CWD3.2: "Change Management and Evolution Support" section 4.1 "Change Propagation and Work Amount Assessment"

Name	Reference requirements for product lines: an example of the medical domain
Topic	A class model for the requirements of the medical domain, with all variations for all products
Process phases	3, 4, 5, 9, 10, 11
Complexity	Medium
Audience	Product managers, architects
Result	Requirements model, specification structure
Input	Features, unstructured and vague requirements
Short description	A class model describes the requirements domain of the entire product family under study, including all variation in the entities identified. The class model is used as a common vocabulary to describe the requirements. The requirements are stored in the System Requirements Specification. Functional requirements are mapped to use cases in the Functional Requirements Specification.
Interesting points	A huge variation over products with a long life span is supported
To detailed description
Owner / participants	Philips
Deliverable	Esaps CWD2.2.1: "System Family Requirements Classification and Formalisms", section 4.1 "Philips - Reference requirements for product-lines: an example of the medical domain"

Name	Reference requirements of switch maintenance
Topic	Application of the SPLIT method on operations, administration and maintenance for standards like UMTS, GSM, GPRS, Edge
Process phases	3, 4, 5
Complexity	Medium
Audience	Product managers, architects, designers
Result	Detailed list of assets of the OAM domain for telecommunication switches
Input	Existing OAM system
Short description	The LCAT approach (SPLIT) provides a requirements hierarchy in order to have a general view of the requirements (marketing) , and then more and more detailed views (technical requirements). This hierarchy facilitates the traceability between each level of requirements. It separates the development of the business requirements (functional requirements) and the constraints (non-functional requirements). This facilitates the construction of the architecture. It introduces variability at each level of requirements in order to facilitate the systematic re-use of the requirements. See also #SPLIT. An example how to wrap existing component models (in UML) for reuse is given for switch maintenance systems in CWD2.3: "Platform and components"; section "Wrapping existing components of switch maintenance systems"
Interesting points	Detailed description of major functional and non-functional assets, capabilities, forces and relations between them in the communication switch domain.
To detailed description
Owner / participants	Alcatel
Deliverable	Esaps CWD2.2.1: "System Family Requirements Classification and Formalisms", section 4.2 "Alcatel - Reference requirements of switch maintenance" Esaps CWD2.2.3: "Case studies and lessons learned (Alcatel)", section 9 "Case studies and lessons learnt (Alcatel)" Esaps CWD2.3: "Platform and components"; section "Wrapping existing components of switch maintenance systems"

Name	Reference requirements of air supervision systems
Topic	Application of the SPLIT method on air supervision systems
Process phases	3, 4, 5
Complexity	Low - medium
Audience	Product managers, architects, designers
Result	Categories of requirements and their attributes for the domain of air supervision systems
Input	Existing air supervision system
Short description	In the experiment requirements of an air supervision system are identified, categorised and analysed, variability of requirement assets (identification of type of variability, notation, expression rules, parameters, realisation, and usage in the decision model), and traceability between all the requirement assets (identification of type, notation and usage) are analysed. See also #SPLIT.
Interesting points	Only 3 types of variability have been identified; 45 percents of the capabilities are variable, and only 8 percents of atomic requirements are variable (50 percents optional and 50 percents partial).
To detailed description
Owner / participants	Thales (former Thomson-CSF)
Deliverable	Esaps CWD2.2.1: "System Family Requirements Classification and Formalisms", section 4.3 "Thomson-CSF - Reference requirements of air supervision systems"

Name	Aspect-driven development
Topic	Handling complexity by structuring a system along a secondary decomposition according to aspects (cross-cutting features like qualities, initialisation, error handling)
Process phases	4, 5
Complexity	Medium
Audience	Architects, designers
Result	Multi-level system decomposition and structuring
Input	Requirements, quality attributes
Short description	Quality attributes are used to get additional views on the system, these are then mapped on aspects which form a secondary decomposition structure of the system, allowing also re-use of these substructures.
Interesting points	Good, practice-oriented approach to manage complexity - allows re-use of assets for cross-cutting aspects.
To detailed description
Owner / participants	Philips
Deliverable	Esaps CWD1.3: "Aspect Analysis and Modeling", section 2.3 "Philips - Aspect Driven Development"

Name	QuESt - Quality evaluation and synthesis of structures
Topic	Rapid architecting: functional decomposition and architecture synthesis
Process phases	3, 4, 5, 9, 10, 11
Complexity	Medium
Audience	Product managers, architects
Result	System decomposition and architecture sketch, metrics evaluating the architecture concepts.
Input	Requirements, features
Short description	Functionalities required from the products are used together with operational scenarios to provide benefits for the customer. Functionalities are grouped to build solution concepts; the solution concepts are evaluated with metrics.
Interesting points	Quantitative approach using metrics, not just guesswork (like usually).
To detailed description
Owner / participants	Siemens
Deliverable	Esaps CWD1.3: "Aspect Analysis and Modeling", section 3.2 "Siemens - Aspect guided functional decomposition" Esaps E2.1c: "Concept for the adaptation of QuESt for Product Family Engineering / Konzept für die Adaption des Ansatzes MoVE für Produktfamilienentwicklung"

Name	Method guidance
Topic	Use-case driven method guidance process
Process phases	All
Complexity	Small
Audience	Architects, designers
Result	Process for applying design methods
Input	Use cases
Short description	A method guidance supports engineers performing the actions of the various development steps of the engineering process. A use-case-driven method guidance process, together with templates for use cases, and an example for use-case driven change integration are provided.
Interesting points	Template for use cases; example use cases for change management
To detailed description
Owner / participants	University of Essen
Deliverable	Esaps E1.2a: Intentional and contextual process modelling language for defining method guidance / Kontextbasierte Modellierungssprache für die Definition der Methodenfragmente Esaps CWD2.1.1: "System family process frameworks", section 10: "Process support for product family engineers"

Name	Trace capture
Topic	Scenario-centred trace structuring
Process phases	3, 4, 5, 9, 10, 11
Complexity	Medium - low
Audience	Architects, designers, testers
Result	Trace structure
Input	Use cases
Short description	Not all design information can be traced because of the complexity. Therefore, information to be traced is restricted depending on its intended usage. This selection is performed with scenarios. See also #Method guidance
Interesting points	Meta models for use cases, use case scenarios, architecture configuration and architecture scenarios with their interrelations
To detailed description
Owner / participants	University of Essen
Deliverable	Esaps E1.2b: "Anleitung für projekt- und produktspezifische Traceaufzeichnung" Esaps CWD3.1: "Requirements Modelling and Traceability", section 5: "Product and Project Specific Trace Capture"

Name	Trace usage guide
Topic	How to use trace information for change integration
Process phases	All
Complexity	Medium
Audience	Architects, designers, testers
Result	Trace structure
Input	Use cases
Short description	Reuse of recorded trace information with change patterns for consistent change integration. Each change situation is specified by goals. See also #Trace capture
Interesting points	The information relevant to describe and integrate changes is neatly specified and captured. Detailed examples.
To detailed description
Owner / participants	University of Essen
Deliverable	Esaps E1.2c: "Goal-driven reuse of experience, Guide for traceability usage / Anleitung für Traceverwendung" Esaps CWD3.2: "Change Management and Evolution Support" section 4.2 "Scenario-based Change Integration"

Name	Traceability between meta model elements
Topic	Traceability from domain characteristics to architecture components
Process phases	3, 4
Complexity	Medium
Audience	Architects
Result	Trace structure
Input	Meta models
Short description	In meta models, traceability is a relation between model elements
Interesting points	Integrated in PuLSE
To detailed description
Owner / participants	IESE
Deliverable	Esaps E2.2e: "Methode für die Verfolgbarkeit von Domänencharakteristika zu Architekturkomponenten" Esaps CWD3.1: "Requirements Modelling and Traceability", section 6: "Traceability from Domain Characteristics to Architectural Components"

Name	Introduction to change management
Topic	Introduction to change management - process and categories
Process phases	1, 3, 4, 5, 7, 9, 10, 11
Complexity	Medium
Audience	Product managers, architects, designers, tester
Result	Items affected by change, change management process (activities etc.)
Input	Traceability structure
Short description	The different kinds of changes and change management are described, as well as system evolution and the difference between change management and evolution.
Interesting points	Comprehensive introduction
To detailed description
Owner / participants	Siemens
Deliverable	Esaps CWD3.2: "Change Management and Evolution Support", section 1: "Introduction"

Name	Architecture evolution
Topic	Architecture transformations in an evolving software product line - case studies + Architecture evolution process
Process phases	3, 5, 11
Complexity	Medium
Audience	Architects
Result	Problems and lessones learned from 2 case studies + viewpoints relevant for change management
Input	Architecture, experience
Short description	The experiences from 2 case studies: storage servers (from Axis) and billing gateways for telephony (from Ericsson) are analysed. The different kinds of changes are categorized and analysed, lessons learned and evolution guidelines deducted. Changes are categorized w.r.t. origins and aspects for business, architecture, process, and organization. Roadmapping, release planning and efficiency are considered.
Interesting points	Consideration of the non-technical aspects
To detailed description
Owner / participants	Blekinge Institute of Technology (University of Karlskrona/Ronneby), Philips
Deliverable	Esaps CWD3.2: "Change Management and Evolution Support", section 2.1: "Architecture Transformations in an Evolving Software Product Line" + section 2.2 "Evolution of system family architectures"

Name	Change management for requirements and reuse objects
Topic	Change management process for changing requirements in product family specifications and reuse objects in a reuse repository
Process phases	3, 4, 5, 9, 10,11
Complexity	Medium
Audience	Product managers, architects, designers
Result	Change management processes
Input	Requirements, information about reuse objects
Short description	The activities of the process for changing system-level requirements in product family specifications and the propagation of changes for parallel developments are described Roles and activities for the process of changing reuse objects in a reuse repository are described.
Interesting points	Detailed process activity descriptions
To detailed description
Owner / participants	Siemens
Deliverable	Esaps CWD3.2: "Change Management and Evolution Support", section 3.1: "Change Impact Analysis and propagation techniques" Esaps E1.2f: "Change Impact Analysis and Propagation Techniques / Entwicklung von Verfahren zur Analyse und Verfolgung von Änderungen"

Name	Change management for parallel projects
Topic	Change management activities for parallel projects for products of the same family
Process phases	3, 4, 5, 9, 10,11
Complexity	Medium
Audience	Product managers, architects, designers
Result	Change management process activities, synchronisation activities
Input	Requirements,specifications of parallel projects
Short description	Solutions to the problems: when to copy specs from one project to another (in the same product family); when and how to merge such specs.
Interesting points	Important for big product families and product populations
To detailed description
Owner / participants	Philips
Deliverable	Esaps CWD3.2: "Change Management and Evolution Support", section 3.2: "Change Management for Working in Parallel Projects"

Name	Cost of change requests in a system product program
Topic	How to determine the cost of change requests based on a committment traceability network
Process phases	3, 4, 5, 9, 10,11
Complexity	Medium
Audience	Product managers, architects
Result	Overall cost of change requests
Input	Committment traceabiltiy network, individual costs
Short description	Based on the committment traceability network, the overall cost for realizing a change request can be determined by evaluating the individual costs.
Interesting points	Important for complex product families
To detailed description
Owner / participants	Nokia
Deliverable	Esaps CWD3.2: "Change Management and Evolution Support", section 3.3: "Cost of Change Requests in a System Product Program"

Name	Logistic Issues in change management
Topic	Change management from a logistic viewpoint
Process phases	3, 5, 6, 10, 11, 12
Complexity	Medium
Audience	Designers, deployers, maintenance
Result	Activities and support for change management from logistic viewpoint
Input	Logistic information
Short description	Based on the organisation of SW as supply chain of production environments, all logistic information is stored and used to retrieve, based on traceability, the relevant information. See also the variability representation of software logistics.
Interesting points	These two contributions are the only ones where the logistic viewpoint is presented
To detailed description
Owner / participants	SERC
Deliverable	Esaps CWD3.2: "Change Management and Evolution Support", section 4.3: "Logistic Isues in Change Management"

Name	Information models
Topic	Information models as basis for method development
Process phases	All
Complexity	Medium
Audience	Architects, Designers
Result	Descriptions of the items and assets we handle and their relations
Input	Basic understanding of the domains
Short description	For coordinating their method development efforts and mutual usage of their results the German partners developed information models with the major submodels: requirements meta model, decision meta model, architecture meta model, design elements meta model.
Interesting points	The major items and their interrelations are described.
No detailed description
Owner / participants	Siemens, Fraunhofer IESE, University of Essen, Bosch
Deliverable	Esaps E4: "D-ESAPS Information Models"

4. Methods for Phase 4: Domain Analysis

Name	Asset management
Topic	Analysis, classification, description and administration of assets and their dependencies
Process phases	All
Complexity	Medium
Audience	Architects, designers
Result	Asset classifications, asset descriptions, asset retrieval methods in asset repositories
Input	Asset data
Short description	All kinds of work products may be assets; it is described how assets of the different process phases can be classified, structured, and described; how their relations are identified and described, and how they can be retrieved in an asset repository. See also #Design-Management.
Interesting points	Detailed description, easily extendable, can be mapped to other domains.
To detailed description
Owner / participants	Bosch
Deliverable	Esaps E3.1b: "Product Line Asset Classification and Dependency Specification / Kategorisierung von Asset-Typen innerhalb des Produktlinien- Entstehungsprozesses sowie Definition und Evaluierung typspezifischer Klassifikationen" Esaps E3.2c: "On the Definition of Requirements for Managing Product Line Asset Repositories / Anforderungen an die Verwaltung und Analyse von Produktlinien-Assets" Esaps CWD3.3: "System-Family Variant Configuration and Derivation", section 2.1: "Product Line Asset Classification and Management"

Name	Nokia product line process framework
Topic	The Nokia Product Line Process Framework (PLPF) is a model that introduces a product line and reuse approach to the product creation processes used in Nokia's Business Units
Process phases	All
Complexity	Medium
Audience	Project managers, managers
Result	Process description with activities, roles, etc.
Input	Process know-how
Short description	The Nokia product line process framework is described with subprocesses, and their purposes, inputs, work products, and roles
Interesting points	Lessons learned
To detailed description
Owner / participants	Nokia
Deliverable	Esaps CWD2.1.1: "System family process frameworks", section 2: "Nokia Product Line Process Framework (PLPF)"

Name	Fraunhofer IESE PuLSE process (ProdUct Line Software Engineering)
Topic	PuLSE^TM is a method for enabling the conception and deployment of software product lines within a large variety of enterprise contexts
Process phases	1, 2, 3, 4, 7, 8, 9, 10
Complexity	Medium
Audience	Project managers, managers
Result	Process description with activities, roles, etc.
Input	Process know-how
Short description	The PuLSE framework is described with subprocesses, and their purpose, inputs, work products, and roles
Interesting points	Lessons learned
To detailed description
Owner / participants	Fraunhofer IESE
Deliverable	Esaps CWD2.1.1: "System family process frameworks", section 3: "Fraunhofer IESE PuLSE"

Name	Philips Research product family process framework
Topic	The Philips Research Product Family Process Framework (PRPFPF) employed at Philips Electronics for development of software intensive electronics products
Process phases	All
Complexity	Medium
Audience	Project managers, managers
Result	Process description with activities etc.
Input	Process know-how
Short description	The Philips Research Product Family Process Framework (PRPFPF) represents Philips Research’s generalisation and description of processes, methods and other best practices employed at Philips Electronics for development of software intensive electronics products. It is described with its processes and procedures.
Interesting points	Iteration through the 5 views
To detailed description
Owner / participants	Philips
Deliverable	Esaps CWD2.1.1: "System family process frameworks", section 4: "Philips Research Product Family Process Framework (PRPFPF)"

Name	Sainco & UPM: RUP and RSEB union
Topic	A combination of the processes RUP (Rational Unified Process) and RSEB (Reuse-oriented Software Engineering Business)
Process phases	All
Complexity	Medium
Audience	Project managers, managers
Result	Process description with activities etc.
Input	Process know-how
Short description	RUP and RSEB are combined for a generic approach for a product line process. That is incremental and iterative, use case driven and architecture centric; and, like RUP, repeats over a series of cycles, where each one concludes with a release of the product. Each cycle consists of four phases: inception, elaboration, construction and transition.
Interesting points	Combination of two well-known quasi-standard processes
To detailed description
Owner / participants	Telvent (Sainco) and Universidad Politécnica de Madrid (UPM)
Deliverable	Esaps CWD2.1.1: "System family process frameworks", section 5: "Sainco & UPM: RUP and RSEB union"

Name	SPLIT / WHEELS (in the LCAT context)
Topic	The process framework for the SPLIT (Software Product Line Integrated Technology) from Alcatel and Thales, developed by LCAT
Process phases	All
Complexity	Medium
Audience	Project managers, managers
Result	Process description with activities etc.
Input	Process know-how
Short description	The process framework WHEELS for SPLIT is described with its processes, and fore each the activities, tasks, inputs and outputs as provided by the common laboratory of Alcatel and Thales (LCAT)
Interesting points	Detailed and structured description
To detailed description
Owner / participants	Alcatel, Thales (Thomson-CSF)
Deliverable	Esaps CWD2.1.1: "System family process frameworks", section 6: "Alcatel SPLIT/WHEELS (in the LCAT context)"

Name	Siemens incremental development process
Topic	The incremental development process for single products and for product families at Siemens
Process phases	All
Complexity	Medium
Audience	Project managers, managers
Result	Process description with activities etc.
Input	Process know-how
Short description	The incremental process is a cyclic model where in each cycle a further feature or level of the system is developed. Independent development groups work in parallel on different variants or versions of a product, using particular synchronisation mechanisms.
Interesting points	Lessons learned
To detailed description
Owner / participants	Siemens
Deliverable	Esaps CWD2.1.1: "System family process frameworks", section 7: "The Incremental Development Process for Product Families at Siemens" Esaps E1.2e: "Process Components in an Incremental Environment for Product Families"

Name	ESI: R-SPICE
Topic	The reuse-oriented SPICE process framework extension based on the standard ISO/IEC 15.504
Process phases	All
Complexity	Medium
Audience	Project managers, managers
Result	Process description with activities etc.
Input	Process know-how
Short description	ESI’s R-SPICE integrates domain engineering and application engineering in the standard ISO/IEC 15.504 (SPICE – Software Process Improvement Capability Determination) process model. The resulting model is called Reuse-SPICE (R-SPICE, for short) and it is a SPICE-compliant extension of the basic ISO/IEC 15.504 model.
Interesting points	Combination with capability levels; detailed process descriptions
To detailed description
Owner / participants	European Software Institute (ESI)
Deliverable	Esaps CWD2.1.1: "System family process frameworks", section 8: "ESI R-SPICE"

Name	Introduction to traceability
Topic	An introduction to requirements traceability
Process phases	All
Complexity	Low
Audience	Product managers, architects, designers
Result	Knowledge about traceability
Input
Short description	The different kinds of traceability are explained, its application and usage in the process, and its place in a conceptual requirements engineering model
Interesting points	Comprehensible, comprehensive and short introduction
To detailed description
Owner / participants	Philips (referring to University of Essen)
Deliverable	Esaps CWD3.1: "Requirements Modelling and Traceability", section 1: "Introduction"

Name	Modelling concept for product families
Topic	A methodology for modelling requirements and other artefacts in product family engineering to support traceability
Process phases	1, 3, 4, 5, 7, 9, 10, 11
Complexity	Medium
Audience	Product managers, architects, designers
Result	Requirements model with trace links; traces from features/requirements to components and back
Input	Requirements, features
Short description	To manage complexity, the model is separated into submodels: one for the family as a whole and one for each product in the family. Each submodel is structured in the same way, containing a document model, a requirements model, and a system model. The document model encompasses all documents imported and generated for the particular product or the family as a whole. The requirements model contains the common requirements (for all products in the family) in case of the product family submodel, the product-specific requirements in the other cases. The system model encompasses the architecture model, version model, and realisation model.
Interesting points	Support for parallel design groups and specific traceability support.
To detailed description
Owner / participants	Siemens
Deliverable	Esaps CWD3.1: "Requirements Modelling and Traceability", section 2: "Modeling Concept for Product Families" Esaps E1.2d: "Modelling concept for product families / Vorgehensweise zum Erstellen von Modellen für die Repräsentation von Requirements, Systemarchitekturen und daraus abgeleiteten Produkten einer Produktfamilie"

Name	Traceability between system variants and reused components
Topic	The traceability mechanisms applied at Philips Medical for legal and business purposes
Process phases	3, 4, 5, 9, 10, 11
Complexity	Medium
Audience	Product managers, architects, designers
Result	Traceability tables for forward, backward, horizontal, and vertical traceability
Input	Requirements and design specifications
Short description	Requirements are tagged to support traceability horizontally (from a requirement to the corresponding test requirement) and vertically (from a requirement to its refinement or a coarser preceding requirement). Forward and backward traces are supported. The tags, together with information about the corresponding modules, are stored in allocation tables that are used for tracing.
Interesting points	Practice-oriented method, not hard to implement. Requirements for traceability tool support
To detailed description
Owner / participants	Philips
Deliverable	Esaps CWD3.1: "Requirements Modelling and Traceability", section 3: "Traceability between System Variants and Reused Components"

Name	Requirements traceability support and SPLIT
Topic	Introduction to requirements management and traceability and the approach in SPLIT
Process phases	3, 4, 9, 10
Complexity	Medium
Audience	Product managers, architects, designers
Result	Traceability support in SPLIT
Input	Requirements and features
Short description	Requirements management, traceability management and change management are described and the approach for them in SPLIT/Cloud. There, traceability is also used for product derivation.
Interesting points	Traceability approach in SPLIT
To detailed description
Owner / participants	Alcatel (and Thales)
Deliverable	Esaps CWD3.1: "Requirements Modelling and Traceability", section 4: "Requirement traceability support"

Name	Traceability-based decision support
Topic	Proposal for a commitment traceability network for identifying the persons/roles who have a responsibility in a system development program
Process phases	3, 4, 5, 6, 9, 10, 11, 12
Complexity	Medium
Audience	Product managers, architects, designers
Result	Commitment traceability network
Input	Responsibilities, commitments
Short description	For supporting a true end-to-end change management in complex multisite, multipartner, multiproject systems development programs: all persons having committed resources to a complex system program have to be identified to agree and comment to changes. A commitment traceability network is proposed.
Interesting points	Integration in processes
To detailed description
Owner / participants	Nokia
Deliverable	Esaps CWD3.1: "Requirements Modelling and Traceability", section 7: "Commitment Traceability Model for System Programs"

Name	COTS assessment
Topic	Applying the COTS acquisition process CAP to requirements engineering methodologies and to MoRE/SLATE
Process phases	3, 4, 9, 10
Complexity	Low
Audience	Architects, designers
Result	Assessment of COTS for certain requirements
Input	Information about COTS
Short description	A process and method for the assessment of COTS (components off the shelf) is customized to assess requirements engineering methods/tools. This customized assessment is then applied to the MoRE/Slate method and tool.
Interesting points	A pragmatic, easily usable assessment method.
To detailed description
Owner / participants	Siemens
Deliverable	Esaps E5.1a: "Applying the COTS Acquisition Process (CAP) to Requirement Engineering Methodologies" Esaps E5.1b: "Applying the COTS Acquisition Process (CAP) to evaluate the MoRE Methodology"

5. Methods for Phase 5 : Domain Design

Name	A method for module architecture verification and its application on a large component-based system
Topic	Checking whether the implicit module architecture of a system is consistent with its specified module architecture.
Process phases	5, 11
Complexity	High
Audience	Designers
Result	List of violations
Input	System documentation (architecture specification) and code
Short description	Use architectural rules to verify that the specified and the actual architectures conform.
Interesting points	A real-life example with 3 MLOC of different programming languages is used.
To detailed description
Owner / participants	Philips
Deliverable	Esaps CWD1.1: "Architecture Analysis and Modelling", section 10 "A Method for Module Architecture Verification and its Application on a Large Component-Based System"

Name	Handling commonalities and variabilities - UML-based techniques - Fraunhofer IESE-approach
Topic	How to model product family reference architectures with UML, with special emphasis on commonalities and variabilities
Process phases	3, 4, 5
Complexity	Medium
Audience	Architects, designers
Result	Commonalities and variabilities of an architecture
Input	Requirements, features
Short description	Variabilities are so diverse that categorisation by level of abstraction is not possible (by binding time, however). A dedicated presentation style is used, based on the "Optional" stereotype and tagged values with references to the decision model.
Interesting points	No extension to standard UML is necessary. The decision model is used.
To detailed description
Owner / participants	Fraunhofer IESE
Deliverable	Esaps CWD2.2.3: "Style, structures and views for handling commonalities and variabilities", section 2: "UML-based techniques (IESE)" Esaps E2.2d: "System Family Architecture Description and Representation / Methode zur Ableitung konkreter Produktar-chitekturen aus einer Referenzarchitektur"

Name	Handling commonalities and variabilities - UML-based techniques - Nokia-approach
Topic	A hierarchical framework (from higher level to lower level: reference architecture – family architecture – lead product architecture and normal product architecture) for architecture design and description to cover the architectures of the entire generation of Nokia mobile phone products
Process phases	5, 11
Complexity	Medium
Audience	Architects
Result	Commonalities and variabilities of an architecture
Input	Requirements, features
Short description	Steps and artefacts: Defining and describing the reference architecture for the generation of Nokia mobile phones. Defining and describing the family architecture for each product family. Designing the lead product architecture of a product family. Product architecture which is copied from the lead product and adapted to the specific product requirements.
Interesting points	Hierarchical architecture framework for a family with lots of product variants.
To detailed description
Owner / participants	Nokia
Deliverable	Esaps CWD2.2.3: "Style, structures and views for handling commonalities and variabilities", section 3 "UML based techniques (Nokia)"

Name	Handling commonalities and variabilities - UML-based techniques - Philips-approach
Topic	A component framework for architectures in the medical imaging domain
Process phases	5, 11
Complexity	Medium
Audience	Architects
Result	Component framework for an architecture
Input	Requirements, features
Short description	Code reuse has shown to be not feasible; therefore a platform is being built consisting of a predefined set of components with well-defined relations between them, which includes all generic behaviour. Variation of the medical imaging platform can be done in two ways: Configuration, the platform components used and their parameterised behaviour can be set to match the desired functionality of the derived product; By extension through well defined interfaces, in which the specific behaviour of the derived product is implemented in a separate component which can be coupled to the platform
Interesting points	Architecture description close to implementation for easier instantiation
To detailed description
Owner / participants	Philips
Deliverable	Esaps CWD2.2.3: "Style, structures and views for handling commonalities and variabilities", section 4 "UML based techniques (Philips)"

Name	Handling commonalities and variabilities - UML-based techniques - Thales-approach
Topic	Describing software product line architectures - Daisy approach (part of SPLIT)
Process phases	5, 11
Complexity	Medium
Audience	Architects
Result	Reference architecture description for the whole product line, with variabilities
Input	Requirements, features
Short description	For each architectural view, architectural perspectives are defined for specific stakeholders; variability is modelled with variation points and product line patterns, using decision models
Interesting points	Thorough approach as part of a systematic framework (SPLIT); mapping between requirements (in SPLIT/CLOUD) and architecture (SPLIT/DAISY)
To detailed description
Owner / participants	Thales (former Thomson-CSF)
Deliverable	Esaps CWD2.2.3: "Style, structures and views for handling commonalities and variabilities", section 5 "UML based techniques (Thales)"

Name	Handling commonalities and variabilities - UML-based techniques - UPM-approach
Topic	Modeling variability with UML
Process phases	5, 11
Complexity	Medium
Audience	Architects, Designers
Result	UML model of variability - for most possible cases
Input	UML elements
Short description	The various variability mechanisms are listed, guidelines how to use them, and for many UML assets the proper extension mechanisms to model variability
Interesting points	Shows directly how the various UML assets can be extended for variability
To detailed description
Owner / participants	Universidad Politécnica de Madrid (UPM)
Deliverable	Esaps CWD2.2.3: "Style, structures and views for handling commonalities and variabilities", section 6 "UML based techniques (UPM)"

Name	Handling commonalities and variabilities - ADL-Darwin-based techniques - EESI-approach
Topic	Modelling variability with Darwin as an ADL
Process phases	5, 11
Complexity	High
Audience	Architects, designers
Result	Darwin-model of product family architecture
Input	Requirements, domain-know-how
Short description	Darwin is used to model the client-server middleware for a family of web-controllable embedded systems
Interesting points	Darwin seems well suited for architecture modelling in this domain; however, all other partners chose UML for architecture modelling.
No detailed description
Owner / participants	Eindhoven Embedded Systems Institute (EESI)
Deliverable	Esaps CWD2.2.3: "Style, structures and views for handling commonalities and variabilities", section 7 "ADL-Darwin based techniques (EESI)"

Name	Petri nets for aspect evaluation
Topic	Using coloured Petri nets to evaluate aspects (reliability, performance) by simulation and formal analysis
Process phases	4, 5, 10, 11
Complexity	Medium
Audience	Architects, designers
Result	System model and model analyses w.r.t. particular aspects, e.g. performance or fault tolerance
Input	Architecture description (UML)
Short description	Based on the general architecture description, an execution architecture model for one or more particular aspects (e.g. reliability or performance) is built with coloured Petri nets and evaluated through model analysis and simulation.
Interesting points	One of the few (may be the only one) methods for aspect evaluation beyond guesswork
To detailed description
Owner / participants	Nokia
Deliverable	Esaps CWD1.3, "Aspect Analysis and Modeling", section 3.3 "Nokia - Formal Method to Evaluate Aspects (reliability, performance) by Simulation and Formal Analysis"

Name	Portability
Topic	Portability - an example for variability in the hardware platform
Process phases	4, 5
Complexity	Medium
Audience	Architects, designers
Result	Architecture description with variabilities for portability to different hardware platforms
Input	System requirements, environment information
Short description	The variability necessary in the architecture for porting a system to different hardware platforms is described
Interesting points	Practical application
To detailed description
Owner / participants	Telvent (SAINCO)
Deliverable	Esaps CWD2.3, "Platform and Components", section "Deployment of a component-based system family for SCADA systems requiring variability in their physical architecture"

6. Methods for Phase 6: Domain Implementation

Name	Analysing the evolution of large OO-systems using metrics
Topic	Find out how components develop in versions over time and systems
Process phases	5, 6, 11, 12
Complexity	Medium
Audience	Designers, implementers
Result	Metrics, statistics of component properties
Input	Database of SW components
Short description	gain an overview of the system evolution qualify the parts of a system in terms of their stability over the versions identify system components which could be reused in other systems identify the migration of components between system parts identify components that have appeared or disappeared over the life-cycle of the system check if components keep on interacting properly and according to the design based on the identification of source code artefacts over several versions of the same system.
Interesting points
To detailed description
Owner / participants	Nokia
Deliverable	Esaps CWD1.1: Architecture Analysis and Modelling, section 8 "Analyzing the Evolution of large OO-systems using metrics"

Name	Reverse architecting
Topic	Extraction of software architecture models from the system implementation.
Process phases	5, 6
Complexity	High
Audience	Designers, implementers
Result	Architecture of legacy components
Input	Code of SW components
Short description	The process for reverse architecting: 1. Definition of architectural concepts 2. Extraction of the source code model 3. Abstraction 4. Improvement of architecture documents 5. Analysis of extracted architecture 6. Architectural reorganisation of source code An example from mobile phones is used to describe the steps. Lessons learned are provided.
Interesting points	Used at Nokia for reusing existing mobile phone SW for future product lines.
To detailed description
Owner / participants	Nokia
Deliverable	Esaps CWD1.1: "Architecture Analysis and Modelling", section 9 "Reverse Architecting"

Name	Component model
Topic	Asset-based meta model of software components for product derivation
Process phases	5, 6, 11, 12
Complexity	Low - medium
Audience	Architects, designers
Result	Component description
Input	Information about architecture and components
Short description	A meta model of SW components, for the activities from design specification to delivery. It allows composition, splitting and refinement of components. Approach for reusing parts of the component-based development, allowing COTS with variability as building blocks.
Interesting points	Specific packaging for development with reuse
To detailed description
Owner / participants	LCAT: Thales, Alcatel
Deliverable	Esaps CWD2.3, "Platform and Components", section "Product-Line Software Components"

Name	Component and interface annotations
Topic	Using semantic interface annotations to find the right components and use them adequately
Process phases	4, 5, 6, 10, 11, 12
Complexity	High
Audience	Designers, implementers
Result	Component interface description
Input	Information about components
Short description	Associating semantic information with components to select the best suited components for composing a product and to employ the components adequately. Message sequence chart are used.
Interesting points	The amount and granularity of annotations can be selected according to the users' needs.
To detailed description
Owner / participants	Siemens
Deliverable	Esaps CWD2.3, "Platform and Components", section "Semantic Component and interface annotations" Esaps E3.1a: "Requirements and Techniques for Component Description and Design Management Methods / Problemcharakterisierung und Anforderungsspezifikation für die Methodik" Esaps E3.2a "Requirements and Techniques for Component Interface Description and Component Selection / Komponentenbeschreibung und bewertungsgestützte Auswahl"

Name	Components as parts of a platform
Topic	How to describe components, interfaces and information models as main parts of a platform
Process phases	5, 6
Complexity	Low
Audience	Designers, implementers
Result	Component and interface descriptions
Input	Information about components
Short description	A platform is described as consisting of components with clearly defined interfaces, some of which have associated information models describing the semantic of the data exchanged.
Interesting points	Experiences with the approach are provided
To detailed description
Owner / participants	Philips
Deliverable	Esaps CWD2.3, "Platform and Components", section "Components, Interfaces, and Information Models"

Name	Components - real-time behaviour specification
Topic	Platform-neutral specification of real-time behaviour and logical specification of functionality of components
Process phases	5, 6, 11, 12
Complexity	High
Audience	Designers, implementers
Result	Component interface descriptions
Input	Information about functional and real-time behaviour of components
Short description	Incorporation of timing constraints specifications in statechart and interaction diagrams
Interesting points	Algebraic calculus of components is provided
To detailed description
Owner / participants	Eindhoven Embedded Systems Institute (EESI)
Deliverable	Esaps CWD2.3, "Platform and Components", section "Specification of functional and real-time behaviour of components"

Name	Component - automatic configuration
Topic	Automatic component configuration by program specialisation
Process phases	6, 12
Complexity	Medium
Audience	Implementers
Result	a) Extended code (for genericity); b) generated code specialisation
Input	Code + declarations about variations
Short description	Declaration language for describing the configurability of components; component configuration by specialsation of the described generic components.
Interesting points	Can easily be integrated into C++ code
To detailed description
Owner / participants	INRIA Rennes (IRISA)
Deliverable	Esaps CWD2.3, "Platform and Components", section "Component Description and Configuration" Esaps CWD3.3: "System-Family Variant Configuration and Derivation", section 3.2: "Configuration Techniques for Product-Line Components"

Name	Component platforms
Topic	Variability and commonality in component platforms
Process phases	5, 6, 11, 12
Complexity	Medium
Audience	Architects, implementers
Result	Variability description in component platforms
Input	Platforms
Short description	Functional and quality properties of components in platforms are described, as well as dependencies among components. Explicit representation of variabilities of component interfaces at different platform layers allows a variety of products in the product family for reduced cost.
Interesting points	Examples.
To detailed description
Owner / participants	Universidad Politécnica de Madrid (UPM)
Deliverable	Esaps CWD2.3, "Platform and Components", section "Assessment of platforms for CBD and domain related services characterisation"

Name	Component description
Topic	How to describe components and their attributes in a platform
Process phases	5, 6, 11, 12
Complexity	Medium
Audience	Designers, implementers
Result	Component attributes description in component platforms
Input	Component property information
Short description	Solutions to problems like description of component functionality, deployment, interfaces etc. are provided.
Interesting points	Well-readable presentation.
To detailed description
Owner / participants	Nokia
Deliverable	Esaps CWD2.3, "Platform and Components", section "Problem Analysis of Component-based Development"

Name	OO framework composition
Topic	How to compose OO frameworks - identification of major problems
Process phases	5, 6, 11, 12
Complexity	Medium
Audience	Designers, implementers
Result	Solutions for OO-framework composition problems
Input	OO-frameworks
Short description	In component-based product family engineering OO frameworks may be product line assets. When composing them to create SW, a series of problems arises. These problems are identified and solutions proposed.
Interesting points	Well-structured representation of problems and causes
To detailed description
Owner / participants	Blekinge Institute of Technology (University of Karlskrona / Ronneby)
Deliverable	Esaps CWD2.3, "Platform and Components", section "Object-oriented Frameworks as Product Line Architecture Components - Integration Problems"

7. Methods for the Derivation Phases

In ESAPS, only few methods for the application engineering subprocess have been developed. Therefore, those were grouped into this chapter.

Name	Intelligent retrieval of domain assets
Topic	How to find the best-suited assets to derive a product (design management)
Process phases	9 - 12
Complexity	Medium
Audience	Designers, implementers
Result	Component annotations, requirements for tools and tool interconnection
Input	Design know-how
Short description	Assets are represented as objects with annotations characterising their behaviour so that for a set of requirements the appropriate assets can be retrieved. Proposal for the interconnection of tools supporting design management.
Interesting points	Tool requirements and tool-chain interconnection proposal
To detailed description
Owner / participants	Siemens
Deliverable	Esaps CWD3.3, "System-Family Variant Configuration and Derivation", section 2.2: "Intelligent Retrieval of Domain Assets" Esaps CWD2.3: "Platform and Components", section "Requirements and Techniques for Derivation Support in Tool-chains", section 3 Esaps E3.2a "Requirements and Techniques for Component Interface Description and Component Selection / Komponentenbeschreibung und bewertungsgestützte Auswahl", section 3. Esaps E3.3a "Methods for Component Description and Selection / Komponentenbeschreibung und Architekturbewertung zur Komponentenauswahl", section 3

Name	Variant configuration and derivation support
Topic	Variability representation and resolution in SPLIT/Cloud and SPLIT/Ladder
Process phases	7 - 12
Complexity	Medium
Audience	Product managers, architects, designers, implementers
Result	Variability description
Input	Requirements, architecture
Short description	The description of variation points and the process of requirements variability capturing and description in SPLIT/Cloud are described, the description of variability with the decision model in SPLIT/Daisy, and the representation of variability in Ladder, the software component development method of SPLIT.
Interesting points	Various variability representations and how they fit together
To detailed description
Owner / participants	Thales
Deliverable	Esaps CWD3.3, "System-Family Variant Configuration and Derivation", section 3.1: "Variant configuration and derivation support"

Name	Variability representation techniques
Topic	The notion of variability in software product lines
Process phases	3-6, 9-12
Complexity	Medium
Audience	Product managers, architects, designers
Result	Variability description on several abstraction levels
Input	Features, architecture
Short description	Variability occurs on all development levels - and on all levels it has to be described. This contribution presents variability description methods and demonstrates them with an example.
Interesting points	Different representation levels; example.
To detailed description
Owner / participants	University of Groningen
Deliverable	Esaps CWD3.3, "System-Family Variant Configuration and Derivation", section 3.3: "On the notion of variability in software product lines"

Name	Software logistics
Topic	Feature-driven software logistics
Process phases	5, 6, 10, 11, 12
Complexity	Medium
Audience	Product managers, deployers, maintenance
Result	Variability description and resolution from a logistic viewpoint
Input	Features, logistic information
Short description	Software logistics deals with the storage, administration, distribution and installation of software artefacts. Variability representation and resolution from a logistic viewpoint are described, together with properties and problems of late binding. See also Change management from a logistic viewpoint.
Interesting points	These two contributions are the only ones where the logistic viewpoint is presented
To detailed description
Owner / participants	SERC
Deliverable	Esaps CWD3.3, "System-Family Variant Configuration and Derivation", section 3.3: "Feature-Driven Software Logistics (SERC)"

Name	MoVE - Selection, derivation, and parameterisation of variants
Topic	Using model-based value engineering (MoVE) for product derivation
Process phases	7, 9, 10, 11
Complexity	Medium
Audience	Product managers, architects, designers
Result	Product architecture
Input	Reference architecture, reusable assets, features, requirements and values for goodness criteria
Short description	Based on product features and requirements, configurations of products are proposed and selected based on evaluations of goodness criteria like cost/benefit
Interesting points	The configuration of products is based on the evaluation of goodness criteria, not just experience and guesswork
To detailed description
Owner / participants	Siemens
Deliverable	Esaps CWD3.3, "System-Family Variant Configuration and Derivation", section 4.2: "Selection, Derivation, and Parameterisation of Variants (Siemens)" Esaps E2.1b: "Concepts for the Adaptation of MoVE for Product Family Engineering / Konzept für die Adaption des Ansatzes MoVE für Produktfamilienentwicklung" Esaps E2.2g: "System Architecture Identification / Methode für die Definition von Familienarchitekturen" Esaps E2.2h: "Selection, Derivation and Parameterisation of Variants / Methode für die Entscheidungsunterstützung für die Definition von Produktfamilien"

Name	Product derivation with SPLIT
Topic	Product derivation with SPLIT - decision model and constraint propagation support
Process phases	7, 9, 10, 11
Complexity	Medium
Audience	Product managers, architects, designers
Result	Product architecture
Input	Reference architecture, reusable assets, requirements and decision model
Short description	Based on the requirements model and the decision model (built with SPLIT/DAISY), variabilities are resolved, application models generated and products configured. See also the other descriptions of SPLIT.
Interesting points	SPLIT is a systematic methodology, covering the whole product-family engineering process
To detailed description
Owner / participants	Thales (LCAT)
Deliverable	Esaps CWD3.3, "System-Family Variant Configuration and Derivation", section 4.3: "Decision Model and Constraint Propagation Support (Thales)"

Name	Product instantiation case study
Topic	Problems and issues associated with the product instantiation in software product lines
Process phases	9, 10, 11
Complexity	Medium
Audience	Architects, designers
Result	Product architecture
Input	Reference architecture, reusable assets
Short description	In a case study some major problems of product derivation are identified and solutions proposed. These are e.g. problems like features spanning over mulitple components, excluding component features, etc. Other results of this case study are in #Architecture-evolution
Interesting points	Case study
To detailed description
Owner / participants	Blekinge Institute of Technology (University of Karlskrona/Ronneby)
Deliverable	Esaps CWD3.3, "System-Family Variant Configuration and Derivation", section 4.4: "Product Instantiation in Software Product Lines"

Name	Derivation process
Topic	A generic product derivation process based on a decision model
Process phases	9, 10, 11
Complexity	Medium
Audience	Architects, designers
Result	Product architecture
Input	Reference architecture, reusable assets, decision model
Short description	A detailed description of the activities, roles, etc. of the steps of the product derivation process.
Interesting points	Detailed description; the results of the economic analysis are used.
To detailed description
Owner / participants	Ivorium Software
Deliverable	Esaps CWD3.3, "System-Family Variant Configuration and Derivation", section 4.5: "A Generic Engineering Process for Derivation "

Name	Requirements for tools
Topic	Requirements for tools and tool chains, mostly for requirements engineering and design
Process phases	3, 4, 5, 9, 10, 11
Complexity	Low
Audience	Architects, designers
Result	Tool requirements
Input	Knowledge about requirements engineering and design, experience
Short description	Some sets of requirements for tools for product line engineering are presented, mostly for requirements engineering and design, but also for product derivation
Interesting points	Combined requirements from Alcatel and Siemens
To detailed description
Owner / participants	Alcatel, Siemens
Deliverable	Esaps CWD3.3, "System-Family Variant Configuration and Derivation", section 5.1: "Tools Requirements and Prototype of Application Engineering Development Platform based on COTS (ALCATEL and SIEMENS)"

8. Documents Considered for Esaps

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)

2. Methods for Phase 2: System Family Economical Analysis

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

4. Methods for Phase 4: Domain Analysis

5. Methods for Phase 5: Domain Design

5. Methods for Phase 5 : Domain Design