1、 1 xxxxxxxxx 毕业设计（论文）外文文献翻译 （本科学生用） 题 目： Poduct Line Engineering: The State of the Practice 生产线工程：实践的形态 学 生 姓 名： 学号： 学 部 （系） : 专 业 年 级 : 指 导 教 师： 职称或 学位： 2011 年 3 月 10 日 2 外文文献翻译（译成中文 1000 字左右）： 【 主要阅读文献不少于 5 篇 ，译文后附注 文献信息，包括 ： 作者、书名（或论文题目）、出 版 社（或刊物名称）、出版时间（或刊号）、页码 。 提供 所译外文资料附件（印刷类含封面、封底、目录、翻译部分的复
2、印件等，网站类的请附网址及原文 】 Requirements engineering practices A precise requirements engineering process a main driver for successful software development is even more important for product line engineering. Usually, the product lines scope addresses various domains simultaneously. This makes requirements en
3、gineering more complex. Furthermore, SPL development involves more tasks than single-product development. Many product line requirements are complex, interlinked, and divided into common and product-specific requirements. So, several requirements engineering practices are important specifically in S
4、PL development: Domain identification and modeling, as well as commonalities and variations across product instances Separate specification and verification for platform and product requirements Management of integrating future requirements into the platform and products Identification, modeling, an
5、d management of requirement dependencies The first two practices are specific to SPL engineering. The latter two are common to software development but have much higher importance for SPLs. Issues with performing these additional activities can severely affect the product lines long-term success. Du
6、ring the investigation, we found that most organizations today apply organizational and procedural measures to master these challenges. The applicability of more formal requirements engineering techniques and tools appeared rather limited, partly because such techniques are not yet designed to cope
7、with product line evelopments inherent complexities. The investigation determined that the following three SPL requirements engineering practices were most important to SPL success. Domain analysis and domain description. Before starting SPL development, organizations should perform a thorough domai
8、n analysis. A well-understood domain is a prerequisite for defining a suitable scope for the product line. Its the foundation for efficiently identifying and distinguishing platform and product requirements. Among the five participants in our investigation, three explicitly modeled the product line
9、requirements. The others used experienced architects and domain experts to develop the SPL core assets without extensive requirements elicitation. Two organizations from the first group established a continuous requirements management that maintained links between product line and product instance r
10、equirements. The three other organizations managed their core assets evolution using change management procedures and versioning concepts. Their business did not force them to maintain more detailed links between the requirements on core assets and product instances. The impact of architectural deci
11、sions on requirements negotiations. A stable but flexible architecture is important for SPL development. However, focusing SPL evolution too much on architectural issues will lead to shallow or even incorrect specifications. It can cause core assets to ignore important SPL requirements so that the c
12、ore assets lose relevance for SPL development. Organizations can avoid this problem by establishing clear responsibilities for requirements management in addition to architectural roles. The work group participants reported that a suitable organizational tool for balancing requirements and architect
13、ure is roundtable meetings in which requirements engineers, 3 lead architects, and marketing and sales personnel discuss SPL implementation. Also,integrating the architects into customer negotiations will solve many problems that can arise from conflicting requirements. Another measure is to effecti
14、vely document requirements and architectural vision so that product marketing and SPL architects can understand each other and agree on implementation. Effective tool support We often discussed tool support for SPL requirements engineering during the investigation. Because requirements engineering f
15、or SPL can become highly complex, effective tool support is important. Existing tools dont satisfactorily support aspects such as variability management, version management for requirements collections, management of different views on requirements, or dependency modeling and evolution. So, an SPL o
16、rganization must design custom solutions for these issues. Specifically, the two participants in the investigation that had established continuous requirements management had to maintain expensive customization and support infrastructures for their tool environment. The other organizations tried to
17、avoid these costs by mitigating insufficient tool support through organizational measures such as strict staging of the requirements specification. 工程实践要求 精确的需求工程过程， 它是 一个成功的软件开发的主要动力，更是对产品线工程的重要。通常，产品线的范围涉及各个领域同时进行。 它要 求工程更加复杂。此外， SPL（ 1） 的发展涉及的任务 往往不止一个 。许多产品线的需求是复杂的，相互关联的，为普通和特定产品的要求不一。如此，一些重要的需求
18、工程具体做法是在SPL 发展： 1、 域辨识与建模，以及在产品实例的共性和差异 2、 单独的规范和验证平台和产品的要求 3、 管理融入平台和产品的未来需求 4、 辨识，建模和属地管理的要求 前两个做法是与 SPL 工程 有关的， 后两个 通常用来发展软件但对 SPL 更重要。可以确定这些适应性的活动 会严重影响产品线的长期成功 运行 。在调查过程中，我们发现，大多数企业 使用这些 组织 性 和程序 性 的措施 来 掌握这些挑战。 而更多基本的工业技术要求和工具的适应性也被相当程度的限制住了，部分原因可能是这些技术还没被设计出能够完全拷贝生产线的功能。 调查 指出 以下三个 SPL 工程要求表现
19、是 SPL 取得成功的重要保证。 域分析和域描述 在开始发展 SPL 之前， 我们 应进行彻底域分析。一个容易理解的定义域是 生产线 的产品适用范围的先决条件。这是 更 有效 的 识别和区分平台和产品的要求。在我们调查的五个参与者，三个 人有 明确 的对 产品线建模的要求。其他人 不依靠已有的经验而是用艺术和域分析的方法来发展 SPL。从第一组的两个组织建立一个连续的要求管理，保持产品线和产品之间的副本要求的链接。其他三个组织管理其核心资产的演化使用变更管理程序和版本概念。 它 们的 联系 并没有强迫他们更 关心 核心资产和产品实例 之间的细微联系 。 于平台要求协商中的冲击 一个稳定而灵活的 平台对 SPL 的发展 是 十分重要 的。 但是，过于 在平 台上过于注重 SPL 则 会 产生一些阴影 ，甚至 是 不 可收拾的结果 。它可以 让我们忽视 SPL 要 求的重要性 ， 故而使 SPL 的 发展失去连贯性。组织性可以通过清除除了平台以外的责任要求避免这种问题。 参加该工作 的工作 组报告说，一个合适组织 性 工具 对于平衡性要求与平台是符
