Name

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

0. Prior using PFE Process

Name	PLA and CMMI: Relationships and Adoption Scenarios
Process phases	Prior to using the family engineering process
Complexity	Medium
Audience	Assessors, Managers
Result	Relationships between CMMI and SPLP, Commonalities and differences of the frameworks and their diagnostic methods, Recommendations for operating with both frameworks in practice, FAQ
Input	-
Short description	CMMI and SPLP are highly interlocked. A mapping is costly and requires expertise of both frameworks. Processes introduced by SPLP framework are always CMMI conform. The opposite is not true. Both frameworks introduce mechanisms that the other framework can profit from.
Interesting points	Practical feedback with respect to the applicability of the Families Evaluation Framwork (FEF)

Owner / participants	Robert Bosch GmbH
Deliverables	FAMILIES CWD1.2, E1.6e

Name	Family Evaluation Framework - FEF
Process phases	Prior to using the family engineering process and for process improvement
Complexity	Medium
Audience	Managers, quality engineers, strategy planners, process people
Result	Evaluation of software system family engineering maturity and performance of a certain development unit
Input	Business, Architecture, Process and Organisational aspects in the execution of software system family engineering
Short description	Evaluation of an organisational unit for each of the BAPO software system family engineering concerns separately (Business, Architecture, Process, and Organisation). For each dimension, five levels are defined. The P-dimension is CMMI-SFE. The maturity of an organisation concerning system family engineering is expressed as a quadruple of numbers or a Kiviat diagram with these 4 dimensions.
Interesting points	Providing an assessment in all relevant dimensions for system-family engineering

Owner / participants	Philips, Nokia, Siemens, Telvent, ESI
Deliverables	FAMILIES CWD 6.1, CWD 2.1, CWD 2.2

1. Methods for Phase 1 "System Family Scoping"

Name	MDE Components Specification
Process phases	All phases
Complexity	High
Audience	Architect, Requirements engineer, Process responsible
Result	Model-driven system definition method and tools specification, product architecture & domain assets
Input	Initial general method, COTS tools; initial domain assets
Short description	Define the main features of reusable methodological component, (process components, transformation components, model definitions (domain models or application models) studied in task 4.1 or task 4.3. It provides a classification of all potential methodology components, identifies what is a reusable methodology component, provides mechanisms and guidelines in order such methodological component may be composed, implement in a tool the notion of reusable methodology component, provides those elements in models, in order to build a methodology based on reusable component and to provide it in the market (as standard or at least as proposal).
Interesting points	The concept permits to deploy methodology inside different tool around the whole process
To detailed description
Owner / participants	THALES, SOFTEAM, UPM, ESI
Deliverable	FAMILIES CWD4.2 "MDE Components specification"

Name	Incremental Product Line Scoping
Process phases	1
Complexity	Medium
Audience	Product manager, requirements engineer
Result	A scope definition (or evolution) in terms of product line (requirements) increments
Input	Expert information, [previous product line scope information, ]
Short description	The approach improves the existing technique for identifying technical subdomains by using requirements tracing information in order to identify potential requirements clusters, that are likely increments. These increments provide a basis for determining in an evolutionary situation, the most appropriate next step for product line development (the scope extension).
Interesting points	Explicit, analytical guidance for derivation of product line increments is provided; Approach extends PuLSE-Eco towards an ongoing, incremental activity.
To detailed description
Owner / participants	Fraunhofer IESE
Deliverable	FAMILIES E1.1a. Systematic Product Line Introduction and Improvement based on Investment models

Name	CMMI-SFE
Process phases	All
Complexity	High
Audience	Architect, Project manager, Process responsible.
Result	Adapt specific and generic goals of CMMI process areas to SFE specific needs.
Input	CMMI activities in the organization (if they exist)
Short description	CMMI-SFE provides a process to organisations willing to adopt SFE approach in their domain.
Interesting points	CMMI-SFE is complementary to CMMI. It can be used as a simple extension to CMMI in any organization if CMMI is already in use or as a complete maturity model if CMMI is not used.
To detailed description
Owner / participants	Owner: CMMI-SFE steering committee. Participants: Nokia, ESI, Siemens, Bosch, Fraunhofer IESE, University of Duisburg-Essen
Deliverable	FAMILIES CWD2.2: CMMI-SFE FAMILIES E1.6: Maturity Assessment for System-Family Engineering FAMILIES E1.6a: Maturity Assessment w.r.t. System-Family Engineering for the Process Areas Organizational Process Definition, Organizational Process Focus and Project Monitoring and Control (Siemens) FAMILIES E1.6b: Maturity Assessment w.r.t. System-Family Engineering for the Process Area Quantitative Project Management (Siemens) FAMILIES E1.6c: Maturity Assessment w.r.t. System Family Engineering for the Process Areas Requirements Development and Requirements Management (University of Duisburg-Essen) FAMILIES E1.6d: Maturity Assessment of Configuration Management for System-Family Engineering (Fraunhofer IESE) FAMILIES E1.6e: PLA and CMMI: Relationships and Adoption Scenarios (Bosch)

Name	SAL3
Process phases	All
Complexity	medium
Audience	Project manager, Process responsible.
Result	Provides a tool to support CMMI-SFE assessments.
Input	CMMI activities in the organization (if they exist)
Short description	SAL3 is a tool created to assess CMMI practices in any organisation in the context of SFE
Interesting points	SAL3 provides a quick way to produce a complete report about the current capability of an organization, with respect to CMMI-SFE. It is easily extensible and can be used also for classical CMMI assessments
To detailed description
Owner / participants	Owner: ESI
Deliverable	FAMILIES WP2.1: SAL3

Name	A Unified Conceptual Model for Product Family Variability Modelling
Process phases	1, 9
Complexity	Medium
Audience	Product manager, architect, requirements engineer
Result	A common conceptual model for variability modelling.
Input
Short description	In this chapter, the various methods taken as input are examined, followed by the resulting conceptual model of variability and it’s illustration using a digital watch example and two different approaches for applying the conceptual model. These are using diagrams mainly from UML to exemplify the use as well as an example where a new domain-specific language is developed using the concepts.
Interesting points	Standard conceptual model for variability modelling
To detailed description
Owner / participants	Nokia, ESI, INRIA, CEA, Fraunhofer, SINTEF/UIO/ICT Norway
Deliverable	Book chapter: A Unified Conceptual Model for Product Family Variability Modelling

Name	Innovation Management and Technology Strategy
Process phases	All
Complexity	Medium
Audience	Managers, process responsibles, product managers, architects, engineers
Result	Innovation folder with Innovation strategy, Prioritised innovation fields, Innovation portfolio with prioritisation according to strategic importance, Innovation roadmap defining innovation projects
Input	Current innovation status of the organisation
Short description	The current innovation status of an organisation is determined by analysing documents (market success, patents, development documents) and by interviews based on a questionnaire. The results are used to create an innovation profile. An innovation folder is created, comprising a new innovation strategy, a SWOT analysis, prioritised innovation fields, an innovation portfolio and an innovation roadmap.
Interesting points	Extension for system family engineering, case study at Siemens Medical Systems, Health Services
To detailed description
Owner / participants	Siemens
Deliverable	FAMILIES CWD 1.2, FAMILIES E1.5a

2. Methods for Phase 2: System Family Economical Analysis

Name	Reuse Action Plan impact in the BAPO-A dimension
Process phases	2, 8
Complexity	medium
Audience	Architect, product manager, manager, process responsible,
Result	The method provides, within the Reuse Action Plan, some specification of the maturity of the BAPO Architecture dimension
Input	Reuse Action Plan
Short description	Using this method a consultant can provide an initial maturity identification of an organization with regards to the BAPO-A dimension. On the other hand an organization can tune its product line strategy according to its maturity with respect to BAPO-A dimension.
Interesting points	The reuse strategies defined in the “Reuse action plan” model developed in CAFÉ has been adequate to the Architecture Dimension of BAPO.
To detailed description
Owner / participants	European Software Institute
Deliverable	FAMILIES: CWD1.3 “Reuse Action Plan impact in the BAPO-A dimension”

Name	Mapping of Reuse-invest Model on BAPO model
Process phases	2, 8
Complexity	medium
Audience	Architect, product manager, manager, process responsible,
Result	Determination of reuse approach maturity in an organization
Input	Reuse Invest results
Short description	The method maps the reuse-invest model to the different BAPO dimensions in order to determine the level of reuse in an organization and its convenience
Interesting points	The method extends reuse-invest making it usable not only as an investment mechanism but also for organization maturity determination
To detailed description
Owner / participants	European Software Institute
Deliverable	FAMILIES: CWD1.2 “Mapping of Reuse-invest Model on BAPO model”

Name	A Cost Model for Software System Families
Process phases	2, 8
Complexity	Medium
Audience	Product managers, managers, requirements engineers, project leaders
Result	Cost estimation for developing products with SFE and ROI compared to single-system engineering
Input	Cost for sinfle-system engineering, estimations for some cost constituents
Short description	The major scenarios are identified that may occur when switching to system-family engineering or extending and evolving a system family or merging system families. The cost model is essentially a divide-and-conquer algorithm partitioning the model describing the cost into factors that can be easily derived from the organization’s experience and current data. For each scenario the constituent cost factors are determined according to this algorithm and thus a cost model for each of these scenarios is provided. Comparison with the cost for single-system engineering provides the ROI and the number of products necessary to achieve a positive ROI.
Interesting points	Simple algorithm that can be calculated rather fast
To detailed description
Owner / participants	Siemens, Fraunhofer IESE
Deliverable

Name	A Model for Product Family Economics in the Automotive Context
Process phases	2
Complexity	Medium
Audience	Managers
Result	Economic models supporting strategic decisions about whether and how to perform a PF transition
Input	1
Short description	In a first phase, factors are discussed which influence cost and benefit of product family development in general. The second step deals with specialization, by setting focus on product families in the automotive field. Features significant for PF development in this domain are discussed. Based on that, PF transition scenarios are described which are representative for the automotive domain. For selected scenarios, cost / benefit models are elaborated, based on the factors identified before.
Interesting points	Specialization of PF economic models with respect to the automotive field

Owner / participants	Robert Bosch GmbH
Deliverables	FAMILIES CWD1.1, E1.1c

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

Name	Family architecture evaluation (FAE) method
Process phases	3
Complexity	Low
Audience	System family architect
Result	Maturity of system family architecture, proposals for improvement
Input	Evaluation criteria framework, architectural artefacts
Short description	The Family Architecture Evaluation method assists in applying any SFE approach to find out the strengths and weaknesses of the product family architecture. The FAE method includes four steps: 1) Evaluation framework for interviews, 2) Review/Inspection of architectural artefacts, 3) Analysis, and 4) Evaluation Framework for Benchmarking
Interesting points	Frameworks for evaluation of interviews, comparison, and benchmarking. Experiences with the FAE method are provided.
To detailed description
Owner / participants	VTT Technical research centre of Finland
Deliverable	FAMILIES Task 1.2 CWD “Practical System Family Engineering Strategies”

Name	Integrability and Extensibility Evaluation (IEE) method
Process phases	3
Complexity	Medium
Audience	Architects, integrators
Result	Evaluated integrability and extensibility of system family architecture
Input	Quality requirements
Short description	The IEE method assists in defining evaluation goals and criteria for IE evaluation, representing architectural models in a way that supports IE evaluation from SFA models and performing IE evaluation in the architecture design phase.
Interesting points	The IEE method has been validated in a laboratory experiment and partly applied to an industrial case study.
To detailed description
Owner / participants	VTT Technical research centre of Finland
Deliverable	FAMILIES Task 3.3 CWD “Evaluation of Integrability and Extensibility from System Family Architecture Models”

Name	Reliability and Availability Prediction (RAP) method
Process phases	3
Complexity	Medium
Audience	Architects, designers
Result	Increased reliability and availability of system family architecture
Input	Quality (reliability and availability) requirements
Short description	RAP method describes how to predict system reliability and availability (R&A) at the architectural level, before actual system implementation. The method helps to define R&A requirements, map the requirements to architectural views and represent them in architectural models, and analyse the architecture to validate whether or not the requirements are met.
Interesting points	RAP method is applied to a case example. Tool support for analysis is provided.
To detailed description
Owner / participants	VTT Technical research centre of Finland
Deliverable	FAMILIES Task 3.2 CWD “Predicting Reliability and Availability at the Architectural Level” Book chapter (in Families technical book): “A method for predicting reliability and availability at the architectural level”

Name	Product Line Behavioural Synthesis (PliBS)
Process phases	3,5,6,9,11,12 (Domain System analysis/design, Domain Design and Implmentation ; System Analysis/design, Application design and implementation)
Complexity	medium
Audience	Designer, tester, implementer, maintenance purposes.
Result	Specific product behaviour, state-charts for any instance involved in the behavioural description.
Input	Message Sequence Charts (MSCs possibly containing variability), decision model accorded to variation points.
Short description	From MSCs describing the behaviour and decisions concerning variability a specific product behaviour is extracted. For this specific behaviour, any Instance life-line may be considered to produce a state-chart from sent/received events along this life-line. Putting all synthetized state-charts together ensures a valid implementation of the described behaviour.
Interesting points	Variability expressiveness and management; models transformation between UML views.
To detailed description
Owner / participants	Irisa/INRIA Participants : Tewfik ZIADI, Jean-Marc JEZEQUEL, Jean-Philippe THIBAULT
Deliverable	FAMILIES Research Book : “Product Line Engineering with the UML : Products Derivation”; User manual for the prototype tool.

Name	From Requirements to Test Cases
Process phases	1,3,4,5,7,9 (SF scoping, System Definition, Domain System analysis/design, Domain Analysis/design, System analysis/Design)
Complexity	Medium
Audience	Product manager, Designer, tester, maintenance purposes.
Result	Test cases
Input	Requirements (enhanced Use Cases and scenarios); Test objectives.
Short description	From enhanced Use Cases allowing variability expressiveness, an UCTS (Use Cases Transition System) is built by matching post-conditions to pre-conditions. A path in the UCTS graph gives an instanciated sequence of several use cases used. Test objectives provide a selection of UCTS paths. Selected paths, coupled with scenarios describing the use case behaviour, provide complete scenarios of testing (called test patterns). Test patterns connected to concrete application design may in turn allow the generation of test cases accorded to the design.
Interesting points	Adaptation to Product Line Engineering by variability introduced in Use Cases specification. Automatic test cases generation from requirements and test objectives.
To detailed description
Owner / participants	Owner : Irisa/INRIA Participants : Clémentine NEBUT, Frank Fleurey, Erwan Drezen, Jean-Marc JEZEQUEL, Yves Le Traon
Deliverable	FAMILIES Research Book, submission entitled “System Testing of Product Families: from requirements to test cases”

Name	Toward the model-driven engineering of large scale systems in THALES - A MDFE case study in the Air-Traffic Management field
Process phases	3 & 9, aspects of 4 and 10
Complexity	Medium-High
Audience	Architect, Designer, Requirements engineer, Manager, Process responsible
Result	Model-driven system definition method and tools, Product architecture & domain assets, Lessons learned from practical experience
Input	Initial general method, COTS tools; initial domain assets
Short description	This case study involves the set-up of a tooled model-driven system definition method, the tooling of this method, and the deployment of this methodology in the context of an Air-Traffic Management project. The system definition method relies on a system architecture modeling framework for addressing requirements capture, domain and application logical architecture definition, and application physical architecture definition. A dedicated set of tools provide system models construction facilities, automated model synchronisation, consistency checking, impact analysis, and integration code generation. Bridges to requirements management and safety analysis tools are also provided. The introduction and deployment of this methodology in the ATM project involved an iterative assessment/adjustement/coaching process. In particular, a particular approach for defining and managing shared domain assets was set-up for the project, taking into account the organisational context. Main lessons learned are relative to tooling, coaching, and management commitment.
Interesting points	MDFE method and toolset; case study
To detailed description
Owner / participants	THALES
Deliverable	FAMILIES CWD4.4 "Model-Driven Family Engineering Supporting Practices", Chapter 2.3: "Towards the model-driven engineering of large scale systems in THALES. A case study in the Air-Traffic Management field "

Name	IESE PuLSE-MDD
Process phases	3, 4, 5, 11, 12
Complexity	High
Audience	architect, designer, developer
Result	Architectural description of an existing system or product line
Input	Functional and non-functional requirements, quality goals, business goals
Short description	PuLSE-MDD combines architecture development (with PuLSE-DSSA) and model driven development techniques and results in one integrated approach.
Interesting points	Product line architecture development with concepts from model-driven development
To detailed description
Owner / participants	Fraunhofer IESE
Deliverable	CAFE E2.4a „Business Goal-Oriented Architecture Development“

Name	IESE Integrated Architecture Reconstruction
Process phases	3,4
Complexity	High
Audience	architect, maintainer, reverse engineer
Result	Architectural description of an existing system or product line
Input	Source code, documentation, and usage scenarios
Short description	Integrated architecture reconstruction does architectural analyses in breadth by considering all kinds of available artifacts (ranging from source code, documentation to version history information, etc.) can be processed if they add value to the development of the product line architecture.
Interesting points	Request-driven reverse engineering, PuLSE-DSSA (architecture development based on existing systems) Combination of all available data sources (static, dynamic, documents)
To detailed description
Owner / participants	Fraunhofer IESE
Deliverable	CAFE E2.5a „Integrated Architecture Reconstruction“

Name	Improve quality of domain requirements
Process phases	3, 9 (Domain System Analysis/Design, System Analysis/Design)
Complexity	medium
Audience	Requirements Engineer, Architects, Project Leaders
Result	Collection of well-founded requirements
Input	Requirements meant for reuse in product families
Short description	By means of an analysis of the attributes of requirements and their tracing rules, a measurement program is proposed. This program is focused on the mandatory attributes, and the coverage of the tracing relations between the different requirement types.
Interesting points	Insight in the current situation of the set of requirements: how well do they respond on application demands, and how well are the mandatory attributes filled in? Defining goals and measure progress at regular basis.
To detailed description
Owner / participants	Owner: Tineke de Bunje (Philips Medical Systems MIT)
Deliverable	FAMILIES cwd3.1, section 1

Name	Risk-based testing
Process phases	All test phases from module to system test
Complexity	Low
Audience	Tester, test manager, architect, designer, project manager, product manager, marketing, sales, maintenance
Result	cost-optimized and controllable assignment of test effort and resources
Input	Stakeholders’ input
Short description	Decompose a product in risk items, let stakeholders determine risk for each items, assign test techniques and resources to each item appropriate for the risk of that item.
Interesting points	Controllable risk (cost) of defects and cost of testing
To detailed description
Owner / participants	Jaap Boumans, Philips Medical Systems
Deliverable	FAMILIES CWD 3.1: An approach for risk-based testing

Name	Security Issues in Dynamically Deployable System Families
Process phases	3,4,5,6,9,10,11
Complexity	Medium
Audience	Architect, Platform manager, Designer, Requirements engineer
Result	A security reference model for component based system (and platform independent)
Input	Countermeasures, threats in terms of system requirements
Short description	One of the most important non-functional requirements nowadays in software systems are those derived from security issues. Specially quality aspects related to security are being considered mandatory in distributed systems environments, where access, trusting and authentication concerns (among others) must be taken into account. New system architecture design patterns based on a component model will facilitate the dynamic and remote deployment of components during execution time; requiring to address security concerns in the whole architecture. A reference model based on standards that addressed security aspects in distributed systems will be covered in this contribution. The proposed security concerns are independent of the target platform. An scenario for model validation is also presented in the contribution.
Interesting points	A scenario for model validation has been defined. The proposed model is based on security standards.
To detailed description
Owner / participants	Telvent
Deliverable	FAMILIES CWD3.2: “Execution Qualities”, section 1, “Security”, chapter 4, “ Security Issues in Dinamically Deployable System Families (for Distributed Systems)”

Name	Quality Variability Techniques for Dynamic Derivation
Process phases	3,4,5,6,9,10,11
Complexity	Medium
Audience	Architect, Designer, Requirements engineer
Result	Technique to represent quality variability and solve quality variability semi-automatically
Input	Demand and offer constraints; catalogue of quality attributes
Short description	During CAFÉ project Quality Variability was identified as one of the most important topics when including third parties assets: COTS, Web Services. However, currently there are no techniques to deal with Quality Variability in a SF development approach. Telvent’s contribution is focused on providing resulting set of techniques to represent quality variability in System Families basing its approach in constraint programming paradigm.
Interesting points	Technique to represent quality variability among a reference architecture
To detailed description
Owner / participants	Telvent
Deliverable	FAMILIES CWD3.3: “Evolution, Adaptation and Maintenance Qualities”; Chapter 5.2: “Quality Variability Techniques for Dynamic Derivation”

Name	Asset Recovery in System Family
Topic	A method and a process for conformance and recovery quality assets from open source systems.
Process phases	3, 4, 9, 10
Complexity	Medium
Audience	Project managers, Architects, Designers, Developers
Result	Proposal for enhancement of Implemented Assets, Proposal for enhancement of standard Assets, Common and Variation point identification.
Input	Requirements, Qualities and Stakeholders requests
Short description	The conformance process needs the two preceding phases where objectives and focus are defined. Then, using the architecture recovery process, the Significant Implemented Assets (SIA) are identified (recovery of the system architecture), and from standard references, Significant Standard Assets (SSA) are abstracted. The conformance process needs SIA and SSA to compare and identify differences and coincidences. Methods for this: Ontology based algorithms that search common artefacts in an architecture, numerical and graph-based algorithms to reduce complexity, etc. In addition, a recovery process is presented for extracting from implementations, significant assets and the whole architecture of the system.
Interesting points	Conformance and recovery processes are keys in the evolutionary development process. Conformance detects possible future improvements and presents a suitable way to find common and variation points. Recovery process defines the best way to reuse assets previously implemented, also from third parties (open source code).
To detailed description
Owner / participants	Universidad Politécnica de Madrid (UPM) and Telvent
Deliverable	FAMILIES CWD: "Asset recovery in System Family" FAMILIES Task 5.2: "Lifecycle and process for family integration" Arciniegas, J.L., et al., Architecture reasoning in support of system family evolution; an example on security, in FAMILIES Research book, T. Käkölä and J. Dueñas, Editors. To be published in LNCS, Springer.2005

Name	Security SF LC Model and Traceability
Topic	Covering security architectural aspects by defining a general approach, including a set of strategies, techniques and/or tools that can be used during the development lifecycle (LC). This method is a generic model for security aspects but also considers specific aspects of system family (SF).
Process phases	3, 4, 5, 6, 9, 10, 11, 12
Complexity	Medium
Audience	Project managers, Architects, Designers, Developers
Result	A framework generic of security for system family lifecycle.
Input	Requirements, Qualities and Stakeholders requests
Short description	The essential idea is to provide a generic abstract security model that reflects common particularities from several platforms in aspects related to security, aspects that can be required at the same time in these platforms. The proposed method defines a set of strategies, techniques and/or tools that can be used during the development lifecycle.
Interesting points	Requirements, Architecture, Components, Testing, Operation and Maintenance Aspect oriented execution qualities focused on security and deployment
To detailed description
Owner / participants	Universidad Politécnica de Madrid (UPM) and Telvent
Deliverable	FAMILIES CWD: "System family security" FAMILIES Task 3.2: "Execution Qualities" Arciniegas, J.L., et al., Architecture reasoning in support of system family evolution; an example on security, in FAMILIES Research book, T. Käkölä and J. Dueñas, Editors. To be published in LNCS, Springer.2005

Name	CoVAR - Component selection considering Variability, Architectural concerns and Requirements
Process phases	3, 4, 5, 9, 10, 11
Complexity	medium
Audience	architect, designer, deployer, line manager
Result	COTS component assessment, requirements refinements, architecture refinements
Input	COTS components, domain requirements, domain architecture
Short description	Evaluation of COTS components considering variability, requirements and architectural concerns
Interesting points	In CoVAR not only variability in requirements but also variability in architectural concerns is taken into account
To detailed description
Owner / participants	University of Duisburg-Essen, Software Systems Engineering
Deliverable	FAMILIES : COTS Evaluation for System Families under Consideration of Constant Changes

Name	Scenario-based Requirements Derivation for Customer-specific Applications based on a Central Variability Model
Process phases	1, 3, 4, 7, 9, 10
Complexity	Medium
Audience	Product Manager, Platform Manager, Line Manager, Requirements Engineer
Result	An application requirements specification with application scenarios, based on the central variability model.
Input	Definition of what should vary in requirements and under what circumstances these requirements-variants should be available --> fully defined central variability model with related requirements artefacts.
Short description	Using the central variability model as an entry point to communicate variability to the customer. Use related scenarios to communicate detailed user requirements, and to identify delta scenarios. The central variability model thereby is the basis the communication and for trade-off decisions in application engineering.
Interesting points	The use of central variability model to communicate variability in scenarios and other requirements artefacts.
To detailed description
Owner / participants	University of Duisburg-Essen
Deliverable	CAFÉ E2.2a: "Scenario-based Derivation of Customer-specific Products" FAMILIES CWD3.1: "Needs Fulfilment Qualities", Section 1: "Requirements Analysis for Product Families"

Name	Scenario-based Derivation of Performance Test Cases
Process phases	3, 4, 5, 6, 9, 10, 11, 12
Complexity	Medium
Audience	Testers, Architects, Requirements Engineers
Result	Reusable Performance Test Cases, Application-specific Performance Test Cases
Input	Use Cases, Performance Requirements
Short description	Reusable performance test cases are derived in domain engineering on the basis of domain use case scenarios. The domain use case scenarios are extended with performance information. In addition to variability in the control flow, also variability in the performance is considered. Depending on the type of performance test (e.g. load test, stress test, performance profiling) in application engineering customer-specific performance test cases are derived by binding the variability.
Interesting points	Approach has been validated at Siemens Medical Solutions HS IM
To detailed description
Owner / participants	University of Duisburg-Essen
Deliverable	CAFÉ E4.2a: "Method for Testing Specific Non-Functional Requirements for Customer-Specific Products" FAMILIES CWD3.1: "Needs Fulfilment Qualities", Section 4: "Test Case Derivation"

Name	Validation of the Extended ScenTED Method for Scenario-based Derivation of Performance Test Cases
Process phases	3, 4, 5, 6, 9, 10, 11, 12
Complexity	Medium
Audience	Testers, Architects, Requirements Engineers
Result	Adapted method for scenario-based derivation of performance test cases in the context of medical PACS systems
Input	Use Cases, Performance Requirements, ScenTED Method
Short description	Reusable performance test cases are developed by supplementing use case scenarios with additional performance aspects. The variability in control flow and performance is modelled in the scenarios. The scenarios are transferred to the test management tool Mercury TestDirector. Depending on the type of performance test (e.g. load test, stress test, performance profiling) customer-specific performance test cases are derived by binding the variability. The assigned test scripts are applied to a real project of Siemens Medical Solutions HS IM.
Interesting points	Approach has been applied to a real productive project of Siemens Medical Solutions HS IM
Owner / participants	Siemens Medical Solutions HS IM, University of Duisburg-Essen
Deliverable	CAFÉ E5.14: "Validation of the Method for Testing Specific Non-Functional Requirements for Customer-Specific Products" FAMILIES CWD3.1: "Needs Fulfilment Qualities", Section 4: "Test Case Derivation"

Name	Evolutional Performance Engineering
Process phases	Applicable from early analysis until maintenance
Complexity	Medium
Audience	Analysts, Developer, Designer, Architects
Result	Suitability + Designs of SW-products and solutions are checked before costly and lengthy coding, purchasing and workaround phases Documentation, verification and monitoring of performance target breakdowns (“performance budgets”) Extrapolations for larger installations / heavier usage for right-sizing infrastructures and tenders
Input	Requirements - Modeling of performance relevant aspects in UML
Short description	Evolutional Performance Engineering lives from modeling of performance relevant aspects in UML and the automatic generation of a comprehensive performance prototype directly out of this single model in one tool. The approach has been already applied to numerous protocols (http, JMS) and technologies (Java, Servlets, EJBs). To further advance the possibilities, we currently work on the extension to activity diagrams, also in context of business process modeling. Since it allows for ensuring suitability + designs of SW-products and solutions before costly and lengthy coding, purchasing and workaround phases, the possible savings potential is enormous. By using this approach, generation for advanced up to date documentation, verification and monitoring of performance target breakdowns (“performance budgets”) can be easily achieved. It further eases extrapolations for larger installations and heavier usage for right-sizing infrastructures or tradeoffs and tenders.
Interesting points	Performance experiments allow for analysis of SW system family variants and allow also for verification of base architecture from different angles.
Detailed description
Owner / participants	Siemens AG, CT SE 1, Dr. Andreas Hennig, Rainer Wasgint
Deliverable	FAMILIES CWD 3.3, Method Evolutional Performance Engineering

Name	A Reference Architecture for Security in System Families
Process phases	3,4,5
Complexity	Medium
Audience	Architects (but also designer, product manager, platform manager, requirements engineer)
Result	Reference architecture
Input	Quality requirements, scenarios
Short description	The reference architecture is a decision support framework for security in system family architectures. It consists of three integrated parts: a quality model for security requirements, a security architecture solution language and a decision model guiding the architect in selecting architecture solutions (tactics, patterns) that will address the relevant security quality requirements.
Interesting points	Security architecture solution language, security quality model, conceptual model for security architecture design in system families.
To detailed description
Owner / participants	ICT-Norway
Deliverable	FAMILIES CWD3.2 “A reference architecture for security in system families”.

Name	Architect Assistant
Process phases	System design, maintenance
Complexity	Medium
Audience	Architect, designer, maintenance
Result	Reverse engineered architecture models, conformance to architectural rules, Naive Bayesian approach for maintaining the reconstruction process
Input	Source code, design documentation, experts, UML architectural profiles
Short description	Software architecture reconstruction is the process of obtaining a documented architecture for an existing system by inferring the architectural information from the available evidence like source code, design documentation and system experts. Our reconstruction approach is based on the selection of the architectural concepts and architectural views according to the sytle and needs of the particular system. The reconstruction process is formalized with the binary relational algebra. This allows us to define the architectural views, to define the graph transformations and to formalize the architectural rules. The architectural rules are automatically checked by the tool and the violations are reported. This provides a mechanism for comparing the intended design against the implemented design. In order to support the maintenance of the reconstruction process, we have proposed a method based on the Naive Bayesian classifier. The classifier allows us to maintaing the mappings between the implementation elements and the corresponding logical elements.
Interesting points	Architecture reconstruction process, formalization of the architectural rules, semi-automatic maintenance of the reconstruction mappings
To detailed description
Owner / participants	Nokia
Deliverable	FAMILIES: Nokia Consortium Wide Deliverable of Families Task 5.2 – Architect Assistant

Name	Evolution of Interfaces in System Families
Process phases	3 (Domain Analysis, Domain Design)
Complexity	High
Audience	Architect, Designer, Developer
Result	Formalised description of variability in component interactions. Initial approach to the reasoning about the impact of evolutionary changes in the interaction protocols.
Input	Descriptions of the component interaction protocols; the variability therein (given as separate feature model).
Short description	The contribution describes language extensions to UML Interactions and the equivalent Message Sequence Charts (MSC) to allow the description of variability in interaction protocols. The thereby introduced two variability operators (that is, the operator “variant” to describe optional message exchanges and the operant “repeat” for lifeline re-duplication) prove to be sufficient to express the needed variability. Both operators are parameterized with respect to a separately defined feature model. Together with the earlier provided concept of UML Interaction or MSC Connectors which allow the definition of component interaction protocols with respect to interaction roles, they build the basis for the reasoning about evolution steps and their impact on the evolving system family.
Interesting points	Variability description within component interaction protocols (MSC / UML Interactions). Formal semantics for the variability operators.
To detailed description
Owner / participants	Siemens AG / Technische Universität München
Deliverable	Evolution of Interfaces in System Families – FAMILIES CWD Task 3.3 Evolution, Adaptation and Maintenance Qualities

Name	Self-configuring Component Interfaces
Process phases	Domain Analysis, Domain Design
Complexity	High
Audience	Architect, Designer, Developer
Result	Identification of the congruent interactions of web services
Input	Web service description according to the Component Description Reference Model; appropriate ontologies.
Short description	The contribution aim at supporting the automated component composition. It uses the behaviour description of component and interface interactions including variability. The integration is based upon a Component Description Reference Model for which both, semantic description patterns, ontologies and inference mechanisms are defined, based upon the respective expressiveness (of the reasoning mechanism) and the required analysis depth (for component property identification). Description Logic and other Logics are integrated by the “Logic on Demand” concept.
Interesting points	Component Description Reference Model. Concept of “Logic on Demand”
To detailed description
Owner / participants	Siemens AG
Deliverable	Self-configuring Component Interfaces – FAMILIES CWD Task 3.3 Evolution, Adaptation and Maintenance Qualities

4. Methods for Phase 4: Domain Analysis

Name	Integration of Third Party Assets
Process phases	4,5,6
Complexity	Low
Audience	SF analists, SF analists, SF architects, SF developers
Result	An asset incorporated to the core assets of the SF
Input	needs, set of candidate assets
Short description	Simple method in order to integrate a third party asset into the core assets of the System Family. It can deal with several assets that can fulfil the needs and select one of them
Interesting points	very simple, give us a sistematic method for reuse (no more ad-hocs processes)
To detailed description
Owner / participants	Telvent
Deliverable	FAMILIES cwd 5.2 - chapter 1

Name	Recovery of Open Source Third Party Assets
Process phases	4,10
Complexity	medium
Audience	Architect, maintenance, platform manager
Result	Final value that can help in the decisson of incorporating an Open Source Third Party Asset
Input	Data extracted from Open Source projects (repositories, mailing lists, bug trackers...)
Short description	Measurement and monitorization of open source assets, mechanism for taking decisions
Interesting points	New point of view: we want to know wether is a good moment or not to incorporate the open source asset
To detailed description
Owner / participants	Telvent
Deliverable	FAMILIES CWD-5.2 - chapter 2

Name	Requirements Management and Modelling in System Family Context
Topic	A method and a process to manage and model system family requirements
Process phases	4, 5, 10, 11
Complexity	Medium
Audience	Product manager, manager, marketing, requirements engineer
Result	Participants list, Domain information, Elicitation Questionnaire, User’s goals, system goals, Use case model, system features specification, functional requirements, non-functional requirements, operational concepts, System object model, architectural requirements, conflict documents, decision documents
Input	Requirement selection criteria, Domain scope, Requirements Management and Development Organisational Policy
Short description	We outline a detailed method concerning requirements engineering disciplines. The following phases are distinguished: requirements obtainment (elicitation), analysis, specification, verification, validation, and management, based on CMMI. These phases can be present in each one of the iterations of the software developing process. For each of the above mention activities an activity diagram using SPEM is proposed.
Interesting points	A guideline covering every aspect related to requirements engineering Main requirements engineering activities and the main roles involved are identified A detailed specification of how to perform every defined activity using the ENAGER tool has been developed
To detailed description
Owner / participants	Universidad Politécnica de Madrid (UPM) and Telvent
Deliverable	FAMILIES CWD Task 2.3 “Tool support framework”

Name	QoS Verification in Accord\|_UML
Process phases	4, 5, 10, 11
Complexity	medium
Audience	architect, designer, developer, tester, deployer, implementer, process responsible, platform manager, requirements engineer
Result	A UML model and analysis results of temporal requirements analysis
Input	A UML model
Short description	A UML models development approach that integrates temporal requirements and possible connection to validation tool (for test generation and schedulability analysis)
Interesting points	Consideration of real-time embedded systems specificities; connection to analysis tool; a UML development methodology; bases on UML2; integration of specific profiles such as SPT, QoS & FT
To detailed description
Owner / participants	CEA-List
Deliverable	FAMILIES CWD3.2 "Introduction of RT-QoS in component interfaces” FAMILIES CWD3.2 “User guide to validate RT-QoS in UML models”

5. Methods for Phase 5: Domain Design

Name	Aspects Weaver
Process phases	3,5,9,11 (Domain System analysis/design, Domain Design; System Analysis/design, Application design)
Complexity	medium
Audience	Designer, tester, implementer, maintenance purposes.
Result	Message Sequence Charts (MSC)
Input	Message Sequence Charts (MSC), mapping informations to determine the weaving point.
Short description	From two MSCs, describing for the first one the program (or behaviour) of a considererd application and for the second one the aspect program, get a third MSC result of the aspect weaving into the application. The weaving process is done by the use of two algebraic operators on MSCs : the amalgamated sum of bMSCs and the fibered product of HMSCs. Mapping informations are necessary as pre-use of these operators to set the exact cut points where the aspect will be merged.
Interesting points	Adequation to Product Line Engineering by various aspects of specific products weaved to a common design structure. Complexity break in easily understandable separate aspects.
To detailed description
Owner / participants	Owner : Irisa/INRIA Participants : Jacques KLEIN, Jean-Marc JEZEQUEL, Jean-Philippe THIBAULT
Deliverable	Papers, PHD Thesis.

Name	Domain architecture tool support for evolution management and variability traceability
Process phases	3, 4, 5, 6, Change Management, Traceability
Complexity	Medium
Audience	Architects, designers, developer, maintenance, platform manager, domain engineers
Result	Tool for managing evolution and traceability evolution of a domain architecture
Input	Decision Model
Short description	V-Architect supports: - The definition of new flexible assets - The definition of the domain variability through the variation point and variation parameter definition - The definition of association between flexible assets. - The evaluation of the family architecture consistency in the sense that flexible assets are checked internally (internal call of variation points, data type and element type checking) and externally (association, external call of variation point defined within external flexible assets) - The evolution change tracking providing the necessary information to the domain engineers for managing the change implementation and estimation. V-Architect is able to provide as information: - The set of flexible assets from the family architecture affected by the change - The set of variation parameters from the flexible assets affected by the evolution - The set of variation points from the flexible assets affected by the evolution
Interesting points	Architecture consistency validation and evolution impact analysis.
To detailed description
Owner / participants	European Software Institute
Deliverable	FAMILIES: CWD3.3 Evolution, Adaptation and Maintenance Qualities

Name	Architectural Modelling in System Family Context
Topic	It is a method and a process to develop system family architecture. In addition, specific system architecture can be obtained from this SF architecture.
Process phases	4, 5, 10, 11
Complexity	Medium
Audience	Architect, designer, platform manager
Result	Core Reference Architecture, System Family Reference Architecture, System functional architecture, System architecture, Domain scoping and product scoping updated
Input	Domain scope, Product Scope, System Family Requirements, Engineering Assets, Product Specific Requirements, Platform, Component Repository
Short description	We propose two processes for Reference Architecture Modelling. In fact, the system family will exhibit this architecture. Its basic purpose is to obtain an appropriate architecture for the system family that will only include the common aspects of it. This activity is closely related to scoping and requirements elicitation tasks. In fact, they are classical activities in system family engineering. Two activities can be distinguished. First, we found the development of the core Reference Architecture. Second, we found the refinement and architecture population. We propose two processes for the derivation of system architectures from the architecture of the system family. First, we found the functional derivation for specific architecture from system family architecture. Second, we found the system architecture using both non-functional and functional properties.
Interesting points	The method proposed an important approach for architecture development in both domain engineering and application engineering. In domain engineering, we found architecture development taking in to account scoping and requirement results. In application engineering, we found architecture development taking in to account domain architecture (or system family architecture), product requirements. This method takes into account iterative and increment approaches of system development. In this way, easy evolution of the system family is obtained.
To detailed description
Owner / participants	Universidad Politécnica de Madrid (UPM) and Telvent
Deliverable	FAMILIES CWD Task 2.3 “Tool support framework”

Name	ART – UML architecture model validation and model operation tool
Process phases	System design, maintenance
Complexity	Medium
Audience	Architect, designer, product/platform/line manager, maintenance
Result	Violations of architectural rules/principles found in the architecture model, comparison of architecture models of different releases
Input	UML architectural profiles, UML architecture models
Short description	An architecture profile describes the product family specific architectural styles/patterns and rules about dependencies/interactions among architectural elements. The ART tool automatically validates a given UML architecture model against the architecture model and report all the violations. The tool can also generate architectural views at different abstract levels and compare different architecture models using UML model operations
Interesting points	Automatic model validation of software architecture
To detailed description
Owner / participants	Nokia
Deliverable	Nokia Case Study in Consortium Wide Deliverable of FAMILIES Task 4.3 – Model Transformation for MDFE

Name	Dealing with Architectural Variation in Product Populations
Process phases	5 (Domain design)
Complexity	Medium
Audience	Architect
Result	Family architecture
Input
Short description	The method provides a way to model variation at the architectural level in family reference architectures
Interesting points	The method introduces the concept of textural variation points, which model architectural decisions that must be left open in the reference architecture to accommodate variation in architecturally significant requirements.
To detailed description
Owner / participants	ICT-Norway/SINTEF
Deliverable	FAMILIES CWD 5.1 "Architecture consequences of integration" and Research book

Name	Using MDA for Automotive Product Line Engineering
Process phases	5, 11
Complexity	Medium
Audience	Architects, Developers
Result	Summary of MDA techniques useful in the context of software-intensive automotive systems, Description of typical model transformations, Description of the model variability and required flexibility of transformations, Examples
Input	3, 4, 9, 10
Short description	In order to instantiate MDA in an automotive systems context, the ideas behind MDA must be adapted: the lack of powerful standard platforms requires to put a substantial amount of design decisions into transformations. Also, the detailed customer requirements may vary considerably, which adds to the complexity of the transformations, as they must be correspondingly flexible. A particular challenge is to guarantee product quality under strict cost constraints. This is why, up to now, there is still a significant share of creative (as opposed to routine) development steps. Still, automotive systems development can profit from the core ideas behind MDA: abstraction, separation of concerns, automation of routine tasks, and standardization of common technological platforms.
Interesting points	Practical examples of transferring the idea of model transformations to the automotive systems context

Owner / participants	Robert Bosch GmbH
Deliverables	FAMILIES CWD4.4, E3.6

6. Methods for Phase 6: Domain Implementation

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

7. Methods for Phase 7: System Definition

Name	PIM and PSM Modelling
Process phases	7, 9, 10, 11, 12 aspects and 6
Complexity	Medium-High
Audience	Architect, Designer, Requirements engineer, Process responsible
Result	Model-driven system definition method and tools, Product architecture & domain assets, Lessons learned from practical experience
Input	Initial general method, COTS tools; initial domain assets
Short description	The system definition method relies on a system architecture modeling framework for addressing requirements capture, domain and application logical architecture definition, and application physical architecture definition. A dedicated set of tools provide system models construction facilities, automated model transformation, synchronisation, consistency checking, impact analysis, and integration code generation.
Interesting points	Tool is a major concern for productivity but also for the basic acceptance of the whole approach.
To detailed description
Owner / participants	THALES
Deliverable	FAMILIES CWD4.1 "Domain and Application modelling Practices", Chapter: "PIM and PSM Modelling "

Name	MOF 2.0 Query/View/Transformation
Process phases	System Family Engineering and part of 7,8,9,10, 11, 12
Complexity	High, medium
Audience	Designer, developer, tester, deployer, implementer
Result	OMG Standard transformation language for PF
Input	Domain assets
Short description	Definition and standardization of a transformation language at OMG. The "MOF 2.0 Query/View/Transformation" is currently in the standardization process. The language provides declarative and imperative features, providing user friendly facilities, as well the ability to deal with complexe transformations.
Interesting points	Standard transformation language
To detailed description
Owner / participants	THALES, INRIA /Irisa
Deliverable	FAMILIES CWD4.3 "Model Transformation for MDFE"

Name	Model Transformation Tool for System Families (UMT for System Families)
Process phases	7
Complexity	Medium
Audience	Architect, designer, implementer
Result	An open source prototype tool which supports model-driven derivation of UML models, based on models with variability.
Input	UML model with variability
Short description	The tool is built using an already existing, open source tool, the UML Model Transformation Tool (UMT), which was developed to support code generation during the CAFÉ [7] project. This has been extended with support for describing decisions of variability and automation of the resolving process, i.e. generation of the new models (product models, partially resolved models) based on decisions.
Interesting points	UMT for System Families is an open source tool that supports variability resolving of UML models
To detailed description
Owner / participants	SINTEF / ICT Norway
Deliverable	FAMILIES CWD T3.4-2.3 - Model Transformation for System Families prototype

8. Methods for Phase 8: System Economical Analysis

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

9. Methods for Phase 9: System Analysis / Design

Name	Variability Management in Accord\|_UML
Process phases	3, 9
Complexity	medium
Audience	Architect, designer, developer, process responsible, product line manager
Result	UML models that integrate variability management (product family model definition or product model derivation).
Input	A UML model
Short description	A UML models development approach that integrates variation management and product line definition in order to automatically define product models.
Interesting points	A UML development methodology; based on UML2; a specific profile for variability management.
To detailed description
Owner / participants	CEA-List
Deliverable	FAMILIES CWD 4.1 Methodological guide for model-based variability modelling”

Name	Quality-Aware Model Transformation
Process phases	9, 10, 11, 12
Complexity	Medium
Audience	Architect, designer, implementer
Result	Establishment of criteria for QoS support in Model Transformation and evaluation of QVT proposals based on these criteria
Input	No input - or a transformation language or technique to be evaluated
Short description	In this document we first identify two modes of how we believe QoS should be handled through model transformations and pin points a set of requirements for QoS-aware model transformations. We then do a survey of the MOF 2.0 QVT submissions currently on the table, investigating to what extent they are capable of supporting the identified requirements.
Interesting points	Provides a framework for evaluating model transformation languages and techniques with respect to QoS
To detailed description
Owner / participants	SINTEF / ICT Norway
Deliverable	FAMILIES CWD 4.3-1.2.2 - Quality-Aware Model Transformation

Name	DSL for model to code generation
Process phases	9, 10, 11, 12
Complexity	Medium
Audience	Architect, designer, implementer
Result	The DSL-based approach described here has proven useable and viable for our product family development. It shows the benefit of automated model to code tools in system family development contexts. It also shows how the usage of domain-specific languages for a family architecture can be beneficial to this process, through the provision of a tailored modelling language. Finally it describes the generic code generator approach, based on text substitution templates, which effectively generates large portions of the system.
Input
Short description	This contribution describes an approach for modelling a product family using a Domain-specific language, which is supported by model to code generation tools.
Interesting points	Usage of DSL, automating product development.
To detailed description
Owner / participants	SuperOffice / ICT Norway
Deliverable	FAMILIES CWD T4.3 - 1.3

Name	Architectural Support for Dealing with Variations in a Product Family
Process phases	10 (application analysis); 11 (application design); 4 (domain analysis); 5 (domain design)
Complexity	Medium
Audience	Architect; Designer; Developer; Platform manager
Result	Solution for dealing with variations on architectural and component level in a product family
Input	Domain and System analysis
Short description	Applying strategies solves variations in architecture. At a variation point, the available strategies are the variation options. Strategies are offered and can be selected by configuring the component. Components get generic properties, which are used to configure the component. The configuration determines which strategy will be applied.
Interesting points	Generic way of associating strategies with a component.
To detailed description
Owner / participants	Philips Applied Technologies
Deliverable	FAMILIES task 5.1 CWD – Equipment control platform – Defining a families platform from existing assets Case description in contribution paper to Families book on system family research: “Dealing with architectural variation in product populations”

10. Methods for Phase 10: Application Analysis

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

11. Methods for Phase 11: Application Design

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

12. Methods for Phase 12: Application Implementation

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

13. Documents Considered for FAMILIES

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)