软件产品线工程方法 － Family Evaluation Framework(FEF)

　　Family Evaluation Framework (FEF) 是欧洲工业界和学术界经过六年时间从众多项目整理出来的一个评估框架，该评估框架有5个级别，覆盖了软件工程的四个评估维度（商业、架构、流程和组织），每个维度有三到四个方面。

Business Dimension

• Commercial : 市场、销售和产品管理？
• Financial : 开发预算和投资决策?
• Vision and business objectives: 产品线的愿景和目标?
• Strategic planning: 组织如何计划长期产品线开发和商业战略?

Level 1:基于项目（Project-Based）

这是最基本的级别，商业针对的是单个项目。

• Commercial : 没有考虑产品线，市场、销售和产品管理都是基于单独的产品来考虑的
• Financial : 没有为领域工程准备专门的预算，所有预算都针对每个单独的系统
• Vision and business objectives:没有产品线
• Strategic planning: 没有考虑各个系统之间的关系

Level 2: 有意识（Aware）

意识到产品线能带来好处，但是不知道如何管理产品线。

• Commercial : 市场、销售和产品管理都意识到了产品线工程带来的机会。产品线可以减少开发费用，可变性管理可以带给客户更多价值，但是公司没有清晰的策略来运行产品线。
• Financial : 对领域工程活动进行投入，有一定的预算开支
• Vision and business objectives: 从意识从总体把握产品线，但是没有清晰的产品线愿景
• Strategic planning: 计划仍旧是按照单个系统开发来制定，但是在产品路线中有机会的话会考虑领域工程

Level 3: 可管理（Managed）

公司对产品线已经较深的认识，软件产品线已经是商业战略的一部分。
• Commercial : 产品线预期收益驱动市场、销售和产品开发，可以以较低的成本进行大量定制化工作。
• Financial : 软件产品线影响投资决策
• Vision and business objectives: 组织对产品线愿景和目标都清晰。
• Strategic planning: 分别计划领域工程和应用工程的路标。

Level 4: 可测量（Measured）

• Commercial : 成本、收益和投资回报率都可测量，可变性管理也可度量，市场、销售和产品管理由这些可测量值指导
• Financial : 成本和重用对预算的影响可计算
• Vision and business objectives: 组织外部，包括客户和投资者都对产品线策略也比较清晰
• Strategic planning: 领域工程和应用工程计划和路标协调获取最好的业务价值

Level 5: 最优化（Optimised）

• Commercial : marketing and sales know the costs, profits and return on investment of software product line engineering and use this knowledge to
improve the business strategy.
• Financial : there is an accurate integration of financial information with the forecast of sales, costs and savings of software product line products.
• Vision and business objectives: they are influenced by software product line development upon a well-understood basis.
• Strategic planning: the plans and roadmaps are used strategically to get the best business value out of software product line engineering.

Architecture Dimension

• Asset reuse level : 重用范围
• Reference architecture: 参考架构决定应用架构的范围
• Variability management: 可变性管理

Level 1: 独立开发（Independent Development）

只有一个针对单个系统的架构。
• Asset reuse level : 没有或者毫无系统性的重用
• Reference architecture: 没有软件产品线架构
• Variability management: 可变性不能管理

Level 2: 标准基础设施（Standardised Infrastructure）

重用集中在第三方基础设施。没有正式的可重用领域资产。
• Asset reuse level : 使用通用的第三方基础设施。
• Reference architecture: 产品线架构基于第三方基础设施，主要致力于使用这些基础设施
• Variability management: 有时会受到第三方基础设置提供的可变性限制，大部分可变性还是由应用架构提供

Level 3: 软件平台(Software Platform)

捕获了领域通用性并在平台中实现，所有应用可以公用一个参考架构，通过配置平台可以适用与多个不同产品，但是对可变性管理没有很好的支持。
• Asset reuse level : 在领域资源中定义了多个通用资产，在平台和架构下进行有计划的重用。
• Reference architecture: 参考架构作为应用架构起点
• Variability management: 参考架构决定了核心资产支持应用开发进行哪些配置。它有明确项目应用时的扩展点。

Level 4: 可变性（Variant Products）

在整条产品线上进行领域通用和可变性管理。可变性管理在产品线中被明确提出
• Asset reuse level : 明确的可变性管理
• Reference architecture: there is an explicit reference architecture that determines where application architectures may vary. Many quality solutions are incorporated in the software product line architecture.
• Variability management: the software product line architecture determines which configurations are allowed for application architectures. The reference architecture determines variation points and restricts the allowed variants for most of these variation points. It determines rules that application-specific variants have to obey.

Level 5: 可配置（Configuring）

At this level, the reference architecture is dominant and application architectures divert only marginal from it. Products can be derived automatically, using scripts, tools and very high level languages. Application development consists mainly on configuring within the borders of the reference architecture. As a consequence, automated configuration of products is possible.
• Asset reuse level : there is systematic reuse based on an asset repository, with explicit variability in the assets and their configuration mechanisms.
• Reference architecture: it determines the application architectures completely. There is automated configuration support to derive specific applications. Quality is supported through the managed use of specific variation points.
• Variability management: it is fully integrated in the architecture. Variability is described in models or languages that are semantically and syntactically standardised within the organisation. Variants are derived automatically.

Process Dimension

• Domain engineering: these processes guide the domain engineering work.
• Application engineering: these processes guide the application engineering work.
• Collaboration: these processes guide the collaboration activities between domain and application engineering.

Level 1: Initial

This is the basic level. Domain and application engineering and collaboration processes are performed at CMMI level 1.
• Domain engineering, application engineering and collaboration: if present at all, performed at CMMI level 1.

Level 2: Managed

At this level, basic software product line project-management is in place. For software product line engineering, domain and application engineering projects are synchronised.
• Domain engineering: performed at CMMI level 2. Amplifications are necessary for the following process areas:

– Requirements Management (RM) manage software product line requirements. Maintain traceability between variation points and variants.
– Project Planning (PP) define variability. Involve application engineering as stakeholder for reusing the domain assets. Define a policy of communication and co-operation with application engineering.
– Project Monitoring and Control (PMC) monitor the usage of reusable assets per application.
– Measurement and Analysis (MA) take global product line view into account.
– Configuration Management (CM) pay attention to baseline created and released for reusable assets.
• Application engineering: performed at CMMI level 2. Amplifications are necessary for the following process areas:
– Requirements Management (RM) is management of application requirements, both as reused domain requirements and as applicationspecific requirements.
– Project Planning (PP) reuse domain assets and bind variability. Analyse the risk of dependency on domain engineering. Involve domain engineering as a stakeholder for developing reusable domain assets. Consider the influence of domain engineering on the scope of application projects.
– Project Monitoring and Control (PMC) monitor the usage of reusable assets.
– Measurement and Analysis (MA) measure use of common assets by application engineering activities.
– Configuration Management’s (CM) reusable assets provide a basis for the identification of configuration items.
• Collaboration: performed at CMMI level 2. Amplifications are necessary for the following process areas:

– Requirements Management (RM) maintain bi-directional traceability between software product line and application requirements and use it to identify inconsistencies.
– Project Planning (PP) asset life-cycles live longer than projects. Synchronise between domain and application engineering. Monitor the involvement between domain and application engineering.
– Project Monitoring and Control (PMC) monitor and control the synchronisation points between domain and application engineering.
– Configuration Management (CM) change requests regarding applicationspecific variants of reusable asset variants may lead to change requests on the reusable assets themselves. Synchronise application and domain configuration management.

Level 3: Defined

At this level, processes are aligned across the organisation, and engineering is performed in a disciplined way over the organisation. For software product line
engineering, this means there is control over variability and reusable assets, both in creation and in use.
• Domain engineering: performed at CMMI level 3. Amplifications are necessary for the following process areas:
– Requirements Development (RD) develop requirements for multiple products in a market segment. Define the scope of the software product line. Identify the products to be built. Identify commonality and variability.
– Technical Solution (TS) variability must be included in operational concepts and scenarios for the domain. Develop a platform architecture and the relevant common product derivation support must be defined and implemented. Consider multiple origins and destinations for interfaces.
– Verification (VE) ensure that application engineering makes the proper intended use of domain assets.
– Validation (VA) in application engineering is a stakeholder of the domain validation process.
– Organisational Process Focus (OPF) and Organisational Process Definition (OPD) include the platform for a given domain, procedures of use of this platform, methodologies, reusable components and guidelines. Consider multiple products in a market segment. Use the scope of the software product line.
– Organisational Training (OT) add training on products, application processes and application project groups.
• Application engineering: performed at CMMI level 3. Amplifications are necessary for the following process areas:– Requirements Development (RD) considers a single customer or market segment. The software product line’s variability and capabilities are used in the communication with the customer. Reuse product line process requirements, bind variability and develop application-specific requirements.
– Technical Solution (TS) reuse domain assets, bind variability and develop application-specific assets. Specialise the platform architecture for the application and use the common product derivation support.
– Validation (VA) validate both domain and application work products. Staff must be especially trained to know what use they may make of the domain assets. Domain engineering is a stakeholder of the application validation process.
– Organisational Training (OT) add training on the platform, asset usage, domain processes and domain project groups.
• Collaboration: performed at CMMI level 3. Amplifications are necessary for the following process areas:
– Requirements Development (RD) identify application requirements as potential software product line requirements.
– Technical Solution (TS) determine selection criteria for and co-ordinate the inclusion of application assets in the platform. Communicate existing and planned application and domain assets. Identify application assets as potential domain assets. Co-ordinate make, buy or reuse decisions.
– Product Integration (PI) maintain a roadmap of future products and product enhancements. Determine the actual transfer protocol of deliverables and the timing of the product transfers. Support the integration of domain and application assets.
– Verification (VE) and Validation (VA) develop a domain verification environment, procedures and criteria concurrently and iteratively with the application verification environment. Communicate verification results and corrective actions between domain and application engineering. Share a policy of planning between domain and application engineering.
– Organisational Process Focus (OPF) determine the organisation’s performance objectives over the whole software product line process. Synchronise action plans between domain and application engineering.
– Organisational Process Definition (OPD) assign responsibilities that cover several projects and products.
– Integrated Project Management (IPM) communicate existing and planned application and domain assets. Identify application assets as potential domain assets.
– Risk Management (RSKM) ensure that the risk management strategy and risk mitigation plans cover both domain and application engineering.

– Decision Analysis and Resolution (DAR) ensure that alternative solutions’ evaluations cover aspects from both the applications and the domain.

Level 4: Quantitatively Managed

At this level, processes are managed and measured within the organisation. For software product line engineering, this means that there is quantitative control over variability and reusable assets, both in creation and in use.
• Domain engineering: performed at CMMI level 4. Amplifications are necessary for the following process area:
– Quantitative Project Management (QPM) integrate the related application engineering sub-processes in the project statistics.
• Application engineering: performed at CMMI level 4. Amplifications are necessary for the following process area:
– Quantitative Project Management (QPM) integrate the related domain engineering sub-processes in the project statistics.
• Collaboration: performed at CMMI level 4. Amplifications are necessary for the following process area:
– Quantitative Project Management (QPM) measure the dependencies between domain and application engineering and the behaviour of their synchronisation activities. Communicate the influences between domain and application engineering. Negotiate improvement actions on performance of bottleneck projects. Co-ordinate stakeholder identification over application and domain projects.

Level 5: Optimising

At this level, processes are continuously optimised for their effectiveness for the organisation. For software product line engineering, this means a combined improvement of domain and application engineering together.
• Domain engineering, application engineering and collaboration: performed at CMMI level 5, and software product line processes of level 4 are performed.

Organisation Dimension

• Roles and responsibilities: how does the organisation manage the distinct responsibilities and relationships occurring in software product line
engineering – are they undifferentiated or are there specific roles for product line engineering?
• Structure: this deals with the organisation structure that puts the roles and responsibilities into practice. It involves both the primary structure as shown in the organisation chart and the secondary structure that is not visible in the organisation chart. This aspect is also relevant to small organisations, which have usually less structure than large organisations. People’s tasks will distribute the personnel over virtual departments, some exist of one or a few persons, and persons may be member of several virtual departments. In small organisations, the structure is partially determined by roles and responsibilities.
• Collaboration schemes: this involves the co-operation in primary and secondary organisation structures and the extent of shared values.

Level 1: Project

This is the basic level. The organisation is arranged for project-based single system engineering. With regard to the organisation concerns, we see the following typical situation:
• Roles and responsibilities: only the application engineering roles, which are the traditional software engineering roles, are defined.
• Structure: it is organised around project-based single system development.
• Collaboration schemes: the organisation is internally focused, human resources may be shared among projects, but software assets are usually not shared.

Level 2: Reuse

At this level, application projects drive reuse in an opportunistic way. First, certain common assets are identified and then refactored to reusable components that are shared between projects.
• Roles and responsibilities: there are no explicitly defined domain engineering roles. The application engineering experts collaborate over project borders to identify and share common assets.
• Structure: it is focused on doing projects. Certain senior resources are allocated to reusable component identification and development.
• Collaboration schemes: it is based on negotiations and information sharing among projects.

Level 3: Weakly Connected

At this level, there are one or more separate domain engineering organisations and multiple application engineering organisations There are simple interactions between them at early and late phases of domain and application engineering life-cycles. In small organisations, the different sub-organisations may be less visible.
• Roles and responsibilities: there are both domain and application engineering roles and responsibilities defined. There are responsibilities defined for separate domain and application engineering organisations.

• Structure: the domain and application roles are distributed over the organisation. There is a separate domain engineering department. Both domain and application engineering have mostly project-oriented structures. In small organisations, there are people that are explicitly responsible for the development of domain assets and application aspects. Although certain persons are responsible for both, this is not the normal situation, and domain and application tasks have separated descriptions.
• Collaboration schemes: it is document-based, mostly in exchanging requirements and shared management of change requests and problem reports between domain engineering projects and several application engineering projects.

Level 4: Synchronised

At this level, there are multiple interactions between domain engineering and application engineering, an institutionalised secondary structure for early problem prevention and co-ordinated planning of domain engineering and application engineering.
• Roles and responsibilities: there are co-ordination roles between domain and application engineering and across domain engineering organisations.
Domain engineering has a major role in software development.
• Structure: there is a secondary structure that incorporates cross-functional teams. The primary structure follows the major sub-structure of the reference architecture. Functional domains, which are important for the reference architecture, determine the secondary structure in the organisation. In small organisations, there are people that are explicitly responsible for the development of domain assets and application aspects. Most persons are also responsible for certain functional domains, extending both over domain and application engineering. Domain and application tasks have separated descriptions.
• Collaboration schemes: there is a strong co-operation of domain and application engineering projects in cross-functional teams, task force groups, etc. There are regular meetings of people fulfilling collaboration roles.

Level 5: Domain-Oriented

At this level, the functional domains determine the primary structure for mainly domain engineering. Application engineering now determines a secondary structure.
• Roles and responsibilities: the responsibilities of the people in the organisation are related to the functional domains in the architecture, like in level 1 organisations. However, the most important focus is on domain engineering. Many people in the organisation have explicit determined applicationresponsibilities in addition. Application engineering roles take only a small part of the time of most people.
• Structure: it is driven by disciplines in domain engineering. Specific application engineering is within the secondary structure. Application development teams are formed over the organisational borders. In small organisations people are explicitly responsible for certain functional domains, extending both over domain and application engineering. Few people are responsible for domain or application engineering only. Functional domain tasks in domain engineering have separated descriptions, in addition there are the application task descriptions.
• Collaboration schemes: persons can assume domain and application engineering roles as needed.