CN103617190A - 一种上下文感知的动态需求跟踪方法 - Google Patents

Abstract

本发明公开了一种上下文感知的动态需求跟踪方法，包括以下步骤：监控步骤：收集开发人员的操作；分析步骤：聚合收集到的操作信息，根据操作信息以及制品间的关联关系，自动生成扩展规则，并以此推测开发人员可能感兴趣的制品；推荐步骤：利用扩展规则从制品集合中自动挖掘开发人员最有可能感兴趣的软件制品；维护步骤：将推荐的制品类型展现给开发人员，建立并维护跟踪历史记录，以便进一步提高扩展规则的有效性和准确性。本发明通过上下文感知，系统性地整合制品之间多种类型的关联信息、开发人员的偏好和操作信息，具有更加准确和快捷的特点。

Description

一种上下文感知的动态需求跟踪方法

技术领域

本发明涉及软件开发管理技术领域，尤其涉及一种上下文感知的动态需求跟踪方法。

背景技术

软件需求跟踪是“一种描述和跟踪整个需求生命周期（包括前向和后向）的能力”。软件需求跟踪可以帮助人们在高层的特征或功能和低层的软件制品之间建立映射关系，这将大大地提高开发人员在维护代码时的效率。一旦高层的需求发生变化，开发人员便可以通过这种映射关系快速地找到与之相对的一系列软件制品，从而保证了高层需求与不同软件制品之间的一致性。

软件需求跟踪辅助软件开发生命周期中很多活动的执行，它不仅可以作为确认和验证系统功能的活动的一种方式，挖掘代码变更背后蕴含的设计决策，帮助开发人员对系统组件进行复用，最后它还可以作为变更管理的重要依据。AybükeAurum等学者提出“若在软件开发生命周期中忽略了需求跟踪，或使用了不完整、不一致的需求跟踪关系，将导致系统质量的下降和反复修改，从而提高了系统开发的时间和成本”。因此，软件需求跟踪被认为是一个影响软件开发和维护过程中各个阶段的重要因素，并影响最终软件产品的质量。

美国食品和药物管理局（FDA）声明，在软件开发过程中，必须使用需求跟踪分析来验证软件的所有需求都得到实现，而且所有的软件制品都可以跟踪到软件需求。美国联邦航空局通过DO-178B认证标准对所有新开发的航空软件进行验证，要求在开发的每个阶段“软件开发人员都必须证明设计与需求之间的可跟踪性”。此外，越来越多的组织在采用标准化软件开发过程（例如CMMI）时，也要求将需求跟踪实践纳入自身的开发及管理过程中。

由于需求跟踪在软件开发和管理过程中的重要性，由美国美国国家航空航天局出资，多位来自美国和欧洲学术界、工业界和政府的著名学者和研究人员在2006年组建了卓越软件跟踪性中心（Centerof Excellence for Software Traceability,CoEST），专门解决在实施软件需求跟踪时所面临的挑战。美国国家科学基金会特别资助一个讨论会来讨论需求跟踪所遇到的一系列重大挑战（Grand Challenges ofTraceability,GCT）。除此之外，美国国家科学基金会还提供了300万美元用于帮助需求跟踪研究社区将所研究出的技术或方法服务于软件行业协会和政府团队。

需求跟踪方法有静态跟踪和动态跟踪两种。传统的需求跟踪大多以静态跟踪为主，主要有需求跟踪矩阵和需求跟踪图等方法。静态需求跟踪需要进行手动设置，面临着易于出错、代价过大等问题。特别是在项目规模较大且周期较长的时候，跟踪关系的维护便成了一个巨大的负担。

在2005年的需求工程大会上，Cleland-Huang提出“动态需求跟踪（Dynamic Requirement Traceability）”。动态需求跟踪从手工建立需求跟踪代价过高且易于出错的问题入手，以自动化技术为手段辅助开发人员建立和维护需求跟踪关系，而且在需求发生变更的时候可以根据跟踪关系自动提出变更提醒。因此，对动态需求跟踪的研究是现阶段的主要方向。主要的动态跟踪方法有基于信息检索的跟踪、基于规则的跟踪等。

下面将对几种主要的需求跟踪技术作一概述。

需求跟踪矩阵

需求跟踪矩阵（Requirements Traceability Matrix，RTM）是表示需求和其他系统元素之间联系链的最普遍方式。需求跟踪矩阵可以保持需求和其他软件制品之间的双向跟踪能力。双向跟踪能力是正向跟踪和逆向跟踪的能力，也就是从需求跟踪到最终产品和从最终产品回溯到需求的能力。需求跟踪矩阵的优点是易于创建和维护，可以很容易发现需求在软件制品之间的不一致情况，有助于开发人员及时纠正偏差。其缺点是，当需求或软件制品发生变更时，开发人员要及时更新需求跟踪矩阵。否则，随着开发工作的进行，跟踪矩阵会变得越来越不准确，并最终导致跟踪的失败。

需求跟踪图

需求跟踪图通过软件人员自已定义的对象和关系，将需求项与测试用例、设计文档和代码等软件制品之间的关系通过图形方式进行表述。需求跟踪图的一大特点是允许对象之间存在多种软件人员自定义的跟踪链，软件人员可以根据需要对它们进行调整以适应不同的环境。通过数学方法，软件人员可以为彼此之间没有直接链接关系的对象建立跟踪。由于需求跟踪图中的对象和关系都是由用户定义的，它们所表达的意义也就易于被软件人员所理解。但另一方面，它仍然没有解决跟踪关系难于维护的问题。而且，多种跟踪链的存在会更得跟踪关系的维护变得更加困难。

基于信息检索的动态需求跟踪

基于信息检索的动态需求跟踪利用文本之间的相似度来确定需求与软件制品之间的跟踪关系。这类方法将文本形式的需求文档与软件制品都视为待检索的文档，然后计算需求与软件制品之间的相似度，对于相似度高于一定阈值的需求与软件制品，就认为它们之间存在关联关系。基于信息检索的动态模式其优点在于方法简单且无需人工干预，通过文本之间的相似度就能够自动地建立关联。其缺点是这类方式是通过需求与软件制品中的标引词（Term）来计算相似度，如果标引词无法匹配，那么即使两个标引词描述的意义相同或者相近，最终计算得出的相似度也会很低，从而无法建立跟踪关系。因此基于信息检索的动态需求跟踪技术需要解决的一个关键问题是对一词多义和同义多词的处理。

基于规则的动态需求跟踪

Spanoudakis等学者提出了一种启发式需求跟踪方式，并称之为基于规则的动态需求跟踪。他们将动态需求跟踪分为两种情况，一种是需求文档或用例与软件制品之间的跟踪关系，另一种是需求文档以及用例相互之间的跟踪关系，这种关系是在前一种跟踪关系的基础上建立起来的。Spanoudakis还将跟踪关系按其逻辑上的关联分为四大类，软件开发人员可通过这些关联了解具有跟踪关系的软件制品之间彼此驱动的先后顺序和逻辑关系。这类方法的优点在于可以建立任何制品之间的跟踪关系，缺点在于需要针对不同的制品制定不同的跟踪关系匹配规则。

最近似的实现方案有两个，一个是加拿大麦吉尔大学的Robillard等学者提出的基于拓扑结构的软件探索工具Suade，以及美国德拉华大学的Emily Hill等学者提出的软件探索工具Dora。软件开发人员可以通过Suade或Dora对代码进行探索，并在探索的过程中建立不同制品之间的跟踪关系。

使用Suade对代码进行探索时，软件开发人员需要通过先验知识等找出若干个与需求相关的代码元素（例如方法，字段等，在此特指代码中的方法）。之后，Suade会通过语法信息（例如方法调用，字段访问等）计算其它代码元素与需求的相关度。最后，Suade根据相关度对代码元素进行排序，并向用户提供排序结果。用户得到排序结果之后，并根据相关度建立起软件制品之间的跟踪关系。

Dora是对Suade的扩展，除了使用语法信息之后，他还利用了语义信息。使用Dora对代码进行探索时，开发人员首先需要构造一个用于计算方法相关度（Method Relevance Score）的特征查询（一组关键词），方法相关度取决于关键词在方法体和方法名中出现的次数。之后，以开发人员给定的一个与特征相关的方法为出发点，Dora计算出所有与该方法存在调用以及被调用关系的所有方法以及它们的方法相关度，并以方法相关度作为判断方法是否与特征相关的指标。与Suade相同，Dora将根据相关度对方法进行排序，并向用户提供排序结果。

现有的技术存在以下不足：当开发人员为一个不熟悉的项目建立制品之间的跟踪关系时，他们很有可能花费大量的时间去探索与需求并不相关的软件制品，或者沿着错误的关联关系对软件制品进行探索。而现有的技术往往无法根据开发人员的操作提供必要的反馈。类如Suade和Dora所使用的探索技术，他们更多的是提供一步到位的扩展支持，无法根据开发人员的操作和上下文动态地调整所应推荐的代码元素或软件制品。

发明内容

本发明需要解决的技术问题是如何更好地实现软件需求跟踪。

为了解决以上技术问题，本发明通过监控用户的操作推测用户期望获取的软件制品，从而帮助开发人员建立不同软件制品之间的跟踪关系。该方法包括监控、分析、推荐和维护四个部分。监控部分收集开发人员的操作，如浏览的软件制品，设置的偏好或厌恶制品信息等；分析部分聚合收集到的操作信息，根据操作信息以及制品间的关联关系，自动生成扩展规则，并以此推测开发人员可能感兴趣的制品；推荐部分利用扩展规则从制品集合中自动挖掘开发人员最有可能感兴趣的软件制品；维护部份将推荐的制品类型展现给开发人员，并维护制品间的跟踪信息，如跟踪关系的创建轨迹，历史变化信息等。

本发明通过上下文感知，系统性地整合制品之间多种类型的关联信息、开发人员的偏好和操作信息，具有更加准确和快捷的特点。

附图说明

当结合附图考虑时，通过参照下面的详细描述，能够更完整更好地理解本发明以及容易得知其中许多伴随的优点，但此处所说明的附图用来提供对本发明的进一步理解，构成本发明的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定，其中：

图1是本发明实施例一种上下文感知的动态需求跟踪系统框图。

具体实施方式

参照图1对本发明的实施例进行说明。

为使上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

如图1所示。感知器（1）可获取开发人员在前一个单位时间（例如20分钟）之内操作信息，其中包括操作的制品集合以及操作类型（如打开、编辑等）。另外，开发人员可以通过偏好设置（2）或厌恶设置（3）将他们认为与需求相关或不相关的制品提交给系统。得到操作信息、偏好设置信息和厌恶设置信息之后，位置相关性度量模型（5）、语义相关性度量模型（6）和依赖相关性度量模型（4）将分别从位置、语义和依赖这三个方面推导出用于查找开发人员所期望的制品的扩展规则。通过厌恶设置得到的不相关制品信息对扩展规则（投票机制）（7）进行去噪，然后再通过感知器得到的操作信息对扩展规则进行加权（8），从而最大程度地精化扩展规则。制品匹配器（9）得到扩展规则后，从制品集合（10）中筛选出所有与规则匹配的制品，并将制品的偏好一齐发送到制品推荐器（11）。在得到匹配的制品及其偏好信息后，制品推荐器（11）将生成一个推荐制品列表。推荐列表中详细记录了各制品间的跟踪关系、跟踪关系创建过程以及制品的推荐度。通过这个推荐制品列表，推荐列表管理器（12）将向软件开发人员提供一个推荐列表的查看界面，软件开发人员可以通过该界面查看所有的推荐列表，并根据自己的需求对列表进行排序或过滤等操作。跟踪关系创建器（13）将保存所有的跟踪关系及其历史变更信息。报表生成器（14）可以生成一个跟踪关系的报表，为软件开发人员提供一个更为全面的信息。开发人员在得到推荐列表之后，可以根据自己的理解，再从推荐列表中选择一部份加入到偏好设置或厌恶设置（15）。当开发人员对偏好设置或厌恶设置做任何操作时，该方法将自动开启新一轮的迭代，并自动为开发人员提供新的推荐列表。

上下文感知的动态需求跟踪方法，包括以下步骤：

（1）感知器自动记录开发人员在前一个单位时间的所有操作，例如打开的文件，浏览文件花费的时间等。

（2）开发人员在探索的过程中可以根据自己的理解，通过偏好设置将自己认为最有可能与需求相关的制品加入偏好集合，以及通过厌恶设置将自己认为不可能与需求相关的制品加入厌恶集合。

（3）当开发人员进行了偏好设置或厌恶设置时，该方法会自动将所收集到偏好设置、厌恶设置和操作记录发送到相关性度量模型。（4）相关性度量模型会分别从位置相关、语义相关和依赖相关这三个方向去挖掘用户的偏好，从而创建扩展规则。

a)位置相关度利用制品所在的位置信息（例如所在的目录）来计算不同制品之间的相关性。给定两个制品m1和m2，可以通过它们的目录信息来比较从根结点至最终包含制品的目录的路径差异性来计算相关性。对于两个制品节点n1和n2，path(n1,n2)表示从n1至n2的最小路径，而len(n1,n2)则表示路径path(n1,n2)的长度。对于给定的两个制品m1和m2，令c1和c2分别表示制品m1和m2所在的目录，r表示两个制品的根目录，而a表示c1和c2的最近公共父目录。那么可以通过以下的公式来计算m1和m2之间的位置相关度如下：

$R_{\mathrm{loc}}(m_1,m_2)=\frac{\mathrm{len}(r,a)}{\mathrm{len}(r,a)+\mathrm{Max}(\mathrm{len}(a,c_1),\mathrm{len}(a,c_2))}$

得到两个制品之间位置相关性计算公式之后，制品m与制品集S之间的位置相关度可定义如下：

$R_{\mathrm{loc}}(m,S)=\frac{1}{\left|S\right|}\×\underset{m^{\′}\∈S}{\mathrm{\Σ}}{R}_{\mathrm{loc}}(m,m^{\′})$

b)依赖相关度利用程序元素之间的语法信息来计算不同程序元素之间的相关性，例如方法调用/被调用、成员变量读/写、类间的继承等。在面向对象的设计中，方法的调用关系与成员变量的读/写是出现频率最高，且最为重要的两种依赖关系。因此，本发明针对这两种依赖关系定义了依赖相关度计算公式。对于程序中经常出现多个方法被嵌套调用以实现某种特定功能的情况，本发明称这种多个方法的嵌套调用为方法调用链，方法之间的嵌套的深度为方法的调用距离。一般而言，对于调用距离越小的不同方法，它们之间的关系越紧密。对于给定的两个方法m1和m2，令它们之间的调用距离为length，衰减系数为ac（Attenuation Coefficient）。可以通过以下的公式来计算m1和m2之间的距离依赖相关度:

R_dist(m₁,m₂)＝ac^length

由于距离依赖相似度仅仅考虑方法之间存在的直接调用关系，因此本发明还考虑方法之间的上下位关系，即方法之间存在的相似的调用/访问上下文。对于某个方法m，令被m调用的方法集合为CallBym，被m访问的成员变量集合为AccessBym，所有调用m的方法集合为Callm。对于给定的两个方法m1和m2，可以通过以下的公式来计算它们之间的上下位依赖相关度：

$R_{\mathrm{context}}(m_1,m_2)=\frac{|{\mathrm{call}}_{m1}\∩{\mathrm{call}}_{m2}|+|{\mathrm{calledBy}}_{m1}\∩{\mathrm{calledBy}}_{m2}|+|{\mathrm{accessBy}}_{m1}\∩{\mathrm{accessBy}}_{m2}|}{|{\mathrm{call}}_{m1}\∪{\mathrm{call}}_{m2}|+|{\mathrm{calledBy}}_{m1}\∪{\mathrm{calledBy}}_{m2}|+|{\mathrm{accessBy}}_{m1}\∪{\mathrm{accessBy}}_{m2}|}$

虽然上下位依赖相关度和距离依赖相关度并非完全正交，但它们都是以语法信息来判断方法之间的相关度。因此，它们不应该被视为两个完全不同的相关度度量公式。对于给定的两个方法，本发明将同时为它们计算上下位相关度和距离相关度，之后取其中最大的一项作为最终的依赖相关度。即对于给定的两个方法m1和m2，可以通过以下的公式来计算它们之间依赖相关度：

R_dep(m₁,m₂)＝max{R_dist(m₁,m₂),R_context(m₁,m₂)}

得到两个方法的依赖相关度之后，方法m与制品集合S之间的依赖相关可定义为：

$R_{\mathrm{dep}}(m,S)=\frac{1}{\left|S\right|}\×\underset{m^{\′}\∈S}{\mathrm{\Σ}}{R}_{\mathrm{dep}}(m,m^{\′})$

c)语义相关度利用程序元素之间的语义信息来计算不同制品之间的相关性。本发明借鉴了向量空间模型（VSM）的思想，使用多维向量表示文档和查询，通过空间上的相似性计算语义上的相似性，另外本发明也借鉴了TF-IDF（Term Frequency–InverseDocument Frequency）的思想来评估每个单词在制品集合中的重要程度。首先，本发明采用一些标准化的IR预处理操作（例如切词、去除停用词、词干化等），将制品文本中存在的标识符和注释等转化为文本文档。之后，通过这些文本文档中的单词集构建TF-IDF向量空间V，每个文本文档中的单词集可视为一个TF-IDF的一个向量。任何一个方法都可以表示为V中的一个向量，称为方法向量，例如第j个制品可以表示为D_j＝(d_1,j,d_2,j,...,d_m,j)^T，其中d_i，j表示单词w_i在制品D_j出现的次数，m表示向量空间的维度，也就是方法中单词的个数。在V中，对于给定两个制品m1和m2，它们的语义相关度可通过其向量Dm1和Dm2的相似度求得：

$R_{\mathrm{lex}}(m_1,m_2)=\frac{{\mathrm{\Σ}}_1^n{D}_{m1}\left[i\right]\×D_{m2}\left[i\right]}{\sqrt{{\mathrm{\Σ}}_1^n{D}_{m1}{\left[i\right]}^2}\×\sqrt{{\mathrm{\Σ}}_1^n{D}_{m2}{\left[i\right]}^2}}$

得到两个制品的语义相关度公式之后，制品m与制品集合S的语义相关可定义为：

$R_{\mathrm{lex}}(m,S)=\frac{1}{\left|S\right|}\×\underset{m^{\′}\∈S}{\mathrm{\Σ}}{R}_{\mathrm{lex}}(m,m^{\′})$

（5）通过相关性模型计算之后，可以得到一系列的扩展规则。其中通过厌恶设置得到的扩展规则与通过偏好设置得到的扩展规则可能会存在一定的重复。本方法通过投票机制对重复的部份进行确认。对于每个重复的扩展规则，偏好设置与厌恶设置分别可以从位置、依赖和语义三个方面进行投票。当且仅当来自偏好设置的投票大于来自厌恶设置的投票时，该扩展规则才可以参与后续的操作。

（6）除了厌恶设置和偏好设置，感知器获得的操作集合也可以一定程度地体现开发人员的偏好。因此，感知器得到的操作集合经过相关性模型计算之后生成的扩展规则也可以一定程度上体现出开发人员的偏好。但由于感知器的内容并没有得到用户的确认，因此本方法仅利用由感知器得到扩展规则对扩展规则进行加权，从而一方面可以更充分地利用上下文信息，另一方面又不会由于开发人员的一些下意识的操作而引入不必要的错误。

（7）得到精化后的扩展规则之后，制品匹配器可以根据规则从制品集合中筛选出与规则匹配的制品，并将他们及偏好信息发送到制品推荐器。

（8）制品推荐器得到制品及其偏好信息后，制品推荐器将生成一个推荐制品列表。推荐列表详细记录了各制品之间的跟踪关系、跟踪关系创建过程以及制品的推荐度。

（9）获得推荐列表之后，推荐列表管理器将向软件开发人员提供一个推荐列表的查看界面，软件开发人员可以通过该界面查看所有的推荐列表，并根据自己的喜好对列表进行排序或过滤等操作。

（10）跟踪关系创建器将自动保存所有跟踪关系及其变更记录。通过变更记录，开发人员不仅可以得到某一阶段的跟踪关系变化情况，还可以查看指定制品或跟踪关系的历史变化信息。

（11）报表生成器可以生成一个跟踪关系的详细报表，从而为软件开发人员提供一个更为全面的信息。

（12）开发人员在得到推荐列表之后，可以根据自己的理解，再从推荐列表中选择一部份加入到偏好设置或厌恶设置。当开发人员进行任何的偏好设置或厌恶设置时，将会跳转到步骤3），并自动开启新一轮的迭代，从而为开发人员提供更具针对性的推荐列表。

本节给出了一个需求至代码的跟踪关系的恢复过程，并实现为Eclipse插件。在这个流程中，开发人员可以通过修改偏好设置或厌恶设置令工具生成相应的推荐集合。该工具的主要使用过程为：

（1）安装插件，并在Eclipse IDE中载入所需分析的软件项目。

（2）在Eclipse IDE中阅读代码，将可能与需求相关的代码元素（如方法，成员变量等）加入偏好设置，或将认为与需求无关的代码元素加入厌恶设置。

（3）工具将根据用户的浏览操作，偏好设置以及厌恶设置的内容自动生成推荐列表。

（4）开发人员可在推荐列表中选择他认为与需求相关的代码元素，并将其加入到偏好列表。或者开发人员也可以在推荐列表中选择他认为与需求无关的代码元素，并将其加入到厌恶列表。工具将根据开发人员的操作再次生成新的推荐列表，直至开发人员完成跟踪关系的建立。

由此可看出，本方法可以向使用者隐藏绝大部份的运算过程。使用者只需进行简单的确认操作（设置偏好或厌恶），便可以得到及时的反馈以及更具针对性的推荐制品集合。

软件制品之间存在着大量错综复杂的关联关系，如依赖关系（例如调用、访问、继承等）、相关关系（例如内容相关和位置相关）、语义关系（例如命名相似性）。当需要对已知的入口点进行扩展时，即使开发人员只关注少数关联关系，他们仍然需要分析大量的依赖路径和软件制品。本发明关注的制品之间的关联类型更加全面，不仅有语法、语义还有位置等关联类型，本发明能提供自动化工具支持节省了大量的时间和精力。

需求所涉及的横切关注点往往分布在不同软件制品，而这些关注点之间可能并不存在直接的关联关系。本发明能够为开发人员建立不同制品之间的跟踪关系。

开发人员往往需要经过多次的探索尝试才能加深对系统的了解，并提高探索的有效性，进而建立更为准确的制品间的跟踪关系。本发明能够提供这种迭代式探索支持，从而充分发挥开发人员的作用。

开发人员在探索的过程中，可能难于准确地定位与需求相关的软件制品，但是他们可以较为轻松且准确地识别出与需求不相关的软件制品。本发明考虑开发人员提供的这种负反馈信息，进而确保了需求跟踪工具的有效性。

虽然以上描述了本发明的具体实施方式，但是本领域的技术人员应当理解，这些具体实施方式仅是举例说明，本领域的技术人员在不脱离本发明的原理和实质的情况下，可以对上述方法和系统的细节进行各种省略、替换和改变。例如，合并上述方法步骤，从而按照实质相同的方法执行实质相同的功能以实现实质相同的结果则属于本发明的范围。因此，本发明的范围仅由所附权利要求书限定。

Claims (6)

1.一种上下文感知的动态需求跟踪方法，其特征在于，包括以下步骤：

监控步骤：收集开发人员的操作；

分析步骤：聚合收集到的操作信息，根据操作信息以及制品间的关联关系，自动生成扩展规则，并以此推测开发人员可能感兴趣的制品；

推荐步骤：利用扩展规则从制品集合中自动挖掘开发人员最有可能感兴趣的软件制品；

维护步骤：将推荐的制品类型展现给开发人员，建立并维护跟踪历史记录，以便进一步提高扩展规则的有效性和准确性。

2.根据权利要求1所述上下文感知的动态需求跟踪方法，其特征在于，所述收集开发人员的操作包括：收集浏览、编辑的软件制品以及制品内容，在制品之间切换时所依赖的关联信息。

3.根据权利要求1所述上下文感知的动态需求跟踪方法，其特征在于，所述收集开发人员的操作包括：设置的偏好或厌恶制品信息。

4.根据权利要求1所述上下文感知的动态需求跟踪方法，其特征在于，在监控步骤和分析步骤之间还包括相关性度量步骤，确定软件制品的相关度。

5.根据权利要求1所述上下文感知的动态需求跟踪方法，其特征在于，所述相关性度量步骤具体包括：位置和/或语义和/或依赖相关性度量。

6.根据权利要求3所述上下文感知的动态需求跟踪方法，其特征在于，所述维护步骤还包括：开发人员在推荐列表中选择他认为与需求相关的代码元素，并将其加入到偏好列表；或者开发人员在推荐列表中选择他认为与需求无关的代码元素，并将其加入到厌恶列表；重复分析步骤、推荐步骤和维护步骤，直至开发人员完成跟踪关系的建立。

Images