在用于监控开发人员对软件代码开发过程的遵守的系统中的规则合并

摘要

本公开涉及在用于监控开发人员对软件代码开发过程的遵守的系统中的规则合并。在系统中，接收第一过程模式和第二过程模式并将其合并以提供合并后的过程模式。每个过程模式按照状态图表示来表达，涵盖了所希望的软件代码开发过程的至少一部分。可选地，将合并后的过程模式呈递给主题专家以获得对其的反馈。然后，将合并后的过程模式转换为可执行过程验证规则，用于在监控过程遵守中使用。在一个实施方式中，将开发过程事件数据与可执行过程验证规则相比较。违背规则会导致生成故障指示，根据需要存储该故障指示并且随后进行报告。以这种方式，当确定开发人员对一个或多个软件代码开发过程的遵循程度时，可以提高自动化过程遵守监控系统的效率。

说明书

技术领域

本公开一般地涉及软件代码的开发，并且特别地涉及用于在用于监控开发人员对软件代码开发过程的遵守的系统中合并规则的技术。 

背景技术

软件代码——包括可以用于控制和命令诸如微处理器、微控制器、协处理器等一个或多个处理设备的操作的指令——无所不在，并且遍及现代技术的很多方面。软件开发项目领域(有时涉及进行为期数月甚至数年的工作的大量软件开发人员(即负责软件代码的实际编写的那些人员))要求使用软件代码开发过程，开发人员需要采用该软件代码开发过程以便提供高质量的代码。这种软件开发过程一般地规定了开发人员在考虑软件代码“完成”之前必须采取的各种步骤。例如，软件开发过程可以规定，在使用公知的配置管理和/或源控制仓库工具来进行签入之前，开发人员将如何查看代码质量、执行单元测试、修复缺陷等。 

实践已经证明，确保软件代码开发过程的高保真采用会得到更高质量的代码。这种软件代码的改善的质量最终导致整个集成软件项目的改善的质量，并且最终得到改善的终端用户满意度。相反，开发人员不遵守这种软件代码开发过程会导致更有可能出现更低质量的代码、代码功能中的更多错误、增加的集成问题以及终端用户的不满意度。 

即便不考虑以下代码开发过程的重要性，当前项目管理者仍然难以验证开发人员实际上遵守了所推荐的软件代码开发过程(特别 是对于采用了大量和/或地理上分散的开发人员的大型项目而言)。由于软件代码的实际创建典型地发生在多个开发人员的本地工作站和集成开发环境(IDE)中，从物理上说项目管理者几乎总是不可能直接监控每个开发人员的工作站及他/她的工作。这种监管缺失通常导致开发人员绕过软件代码开发过程由此降低了所得到的代码的质量。另外，修正所产生的质量问题所需的时间和工作量降低了完成开发项目的整体效率。 

为解决这些问题，已经开发了系统来提供对于开发人员对软件开发过程的遵守的自动化监控。例如，Johnson和Kou在AGILE 2007中的“Automated Recognition of Test-Driven Development with Zorro”一文中描述了所谓的Zorro系统。Zorro系统使用开源框架(Hackystat)来在各种开发环境工具中部署“传感器”，以收集加有时间戳的原始事件数据。软件开发流分析(SDSA)应用分析原始事件数据，以确定“事项(episode)”在按时间排序的事件数据流内的存在。Zorro应用继而对事项执行基于规则的分析以确定开发人员是否遵守了特定的开发过程，例如测试驱动开发(TDD)。尽管诸如Zorro之类的系统对于确定开发人员对所希望的过程的遵守而言是有益的，但是可以预见，更复杂的过程将需要跟踪大量状态(例如Zorro系统中所使用的事项)，从而导致大量的更复杂的规则。为了更好地缩放如Zorro之类的过程遵守监控系统，提供用于更高效地管理用于评价过程遵守的规则的技术将是有益的。 

发明内容

本公开使得项目管理者等能够监控软件开发人员对一个或多个软件代码开发过程的遵守。一般地，这是通过如下方式实现的，即捕获由开发人员执行的相关活动的发生(正如由其所使用的开发工具所表明的那样)，并且随后将这些活动与所希望的软件代码开发过程的基于规则的模型相比较。给定的基于规则的模型与所捕获的活动之间的差异表明并未遵守软件开发过程。在一个实施方式中， 当接收了第一过程模式和第二过程模式并将其合并以提供合并后的过程模式时，会促进对规则的管理。每个过程模式，其可以由处理设备经由文本和/或图形用户接口来接收，代表了所希望的软件代码开发过程的至少一部分。可选地，可以将合并后的过程模式呈递给主题专家以获得对其的反馈。继而，可以将合并后的过程模式转换为可执行过程验证规则，其用于在监控过程遵守时使用。 

在一个实施方式中，通过首先将各过程模式转换为曲线图形式来完成对过程模式的合并。对所得到的第一曲线图和第二曲线图进行比较以确定第一曲线图与第二曲线图之间的交点，从而使得可以产生合并后的曲线图。继而，将合并后的曲线图转换为合并后的过程模式并随后如上所述地进行处理。 

在此处描述的一个实施方式中，事件收集组件收集由开发人员生成的开发过程事件信息，并且规则执行组件将其与软件代码开发过程的一个或多个可执行验证规则代表相比较。根据这些比较，如果不符合至少一个可执行验证规则的任何条件，则生成和存储一个或多个故障指示。此后，报告组件可以生成关于故障指示的报告，以便随后呈递给用户。 

在又一实施方式中，事件收集组件采用数据收集组件，该数据收集组件从由开发人员使用的一个或多个开发工具收集原始开发过程事件数据。此后，采用过滤规则来对原始开发过程事件数据进行过滤以提供开发过程事件信息。可以采用查询形成组件来制订过滤规则。 

在此进一步描述根据这些实施方式和其他实施方式的各种方法和装置。以这种方式，本公开提供如下技术，该技术提高了自动化过程遵守监控系统能够确定开发人员对一个或者多个软件代码开发过程的遵循程度的效率。例如，在此描述的规则合并能力减少了必须维持的规则的数量以及评价这种规则所需的处理。也就是说，减轻了跟踪并定期评价多个不同规则的负担，而由合并后的规则所提供的覆盖相对于未合并的规则而言并没有任何损失。另外，可以改 进评估规则的速度。在不进行合并的情况下，将需要针对每个规则而独立地评价两个或更多规则实际上共有的状态。为了评价所有规则，这会导致增加的处理负担。这种共有状态的合并消除了其冗余评价，降低了处理开销，并且有益地减小了其为评价规则而耗费的时间。因此，这种改善的监控能力确保了更好的过程遵守和随后在软件代码质量、整体开发效率和终端用户满意度方面有所改善。 

附图说明

在所附权利要求书中特别地阐明了本公开中所描述的特征。在结合附图而考虑以下详细描述后，这些特征和伴随的优点将变得明显。现在仅通过示例的方式、参考附图来描述一个或多个实施方式，在附图中，类似的参考标号表示类似的元素，并且其中： 

图1是根据本公开的装置的框图； 

图2是更详细地图示出的图1的装置的事件收集组件的框图； 

图3是更详细地图示出的图1的装置的规则执行组件的框图； 

图4是可以用于实现在此描述的各种实施方式的处理设备的框图； 

图5是图示出根据本公开对过程模式的处理的流程图； 

图6是图示出根据在此描述的实施方式的、用于捕获过程模式的图形用户接口的实施方式的示图； 

图7至图9是根据本公开的曲线图形式的过程模式及其合并的示例的图示； 

图10是图示出根据在此描述的各种实施方式的、用于监控开发人员对软件代码开发过程的遵守的方法的流程图；以及 

图11至图13是图示出根据在此描述的各种实施方式的图形用户接口的各种实施方式的示图。 

具体实施方式

现在参考图1，其示出了用于在监控软件代码开发人员对一个或 多个软件代码开发过程的遵守时使用的装置100。特别地，装置100包括事件收集组件102，该事件收集组件102操作性地连接到规则执行组件104。规则配置组件106操作性地连接到规则存储组件108，规则存储组件108接着操作性地连接到规则执行组件104。结果存储组件110操作性地连接到规则执行组件104和报告组件112两者，正如所示。正如进一步所示，一个或多个开发工具120经由事件收集组件102与系统100通信。 

一般地，事件收集组件102从一个或多个开发工具120收集开发过程事件信息。开发过程事件信息包括关于由开发人员采取的动作的数据，正如由一个或多个开发工具120所显现的。这种数据可以包括对由开发人员采取的动作(或由开发人员引起的事件)的特定性质的指示，事件或动作发生的日期和/或时间，以及引起事件或动作发生的特定开发人员的标识。开发工具120包括开发人员在编写或产生软件代码时使用的任何装置，该装置易于实现对构成开发过程事件信息的数据的自动化收集。例如，开发工具120可以包括多个公知IDE工具中的任何一种，诸如“ECLIPSE”IDE，Microsoft的“VISUAL STUDIO”，BEA的“WORKSHOP”，Oracle的“JDEVELOPER”等。正如本领域中所知，开发工具120典型地包括允许收集事件信息的应用协议接口(API)。尽管在图1中未详细绘出，事件收集组件102与开发工具120之间的连接可以是根据公知技术的，并且可以包括例如正如由局域网、专用或公共(例如万维网/因特网)广域网等实现的网络连接。 

基于如此收集的开发过程事件信息，规则执行组件104将由一个或多个可执行验证规则(存储在规则存储组件108中)确立的条件与开发过程事件信息相比较。存储在规则存储组件108中的每个可执行验证规则，在如下程度上代表了软件代码开发过程，即由可执行验证规则确立的条件确立了如下动作或事件，这些动作或事件需要在开发过程事件信息内标识，以便确认开发人员已经(或尚未)正确地遵守软件代码开发过程。例如，软件代码开发过程可能要求 在对给定代码部分的最新近的编辑之后、但在这种代码被签入到配置管理仓库中之前，在该代码的给定部分(例如模块、子例程等)上使用给定代码质量工具。在可执行形式下，这一软件代码开发过程可能要求一系列动作/事件，在该动作/事件中对该代码部分在开发人员的IDE内被修改的最近指示具有早于对正在该代码部分上运行的质量工具的指示的时间/日期戳，正在该代码部分上运行的质量工具的指示转而必须具有早于对该代码部分已经被签入到配置管理仓库中的指示的日期/时间戳。如果未能满足这些条件中的任何一个，无论是由于未能执行多个操作之一(例如在该代码部分上运行代码质量工具)，还是不按顺序执行这些操作(例如在最新近一次在该代码部分上执行代码质量工具之后对所表明的该代码部分的进一步编辑)，都将导致生成故障指示。在一个实施方式中，针对开发过程事件信息执行规则是在某个定期间隔(例如每周、每两周、每个月等)上执行的。执行规则的频率部分地基于：在给定所关注的开发人员数量的情况下对这种执行进行缩放的需要。另外，对于相对复杂的规则，非常有可能的是有关的事件/状态可以在时间上相对地间隔开。在这些实例中，可能希望的是不太频繁的规则执行以便确保充分的时间。更进一步，可能希望的是以不同的频率执行不同类型的规则，例如更频繁地执行不太复杂的规则，并且不太频繁地执行更复杂的规则。 

故障指示包括表明特定可执行验证规则(代表对应的软件代码开发过程)尚未得到满足的数据。在一个实施方式中，故障指示包括对已经违反的特定软件代码开发过程/可执行验证规则的指示以及对导致该违反的开发人员的指示。为了进一步为开发人员和管理者提供关于过程是如何被违反的信息，故障指示可以包括关于未被满足的确切规则部分的附加信息，从而支持确定补救步骤，诸如训练、过程重新设计等。正如所述，这种故障指示存储在结果存储设备110中。例如，结果存储设备110可以组织为数据库，从而使得可以使用数据库查询接口来实现报告组件112。以这种方式，可以形成查询 (使用公知技术)来确定结果存储设备110中的哪些故障指示满足规定的查询。继而，可以使用公知技术以任何合适的格式并且经由合适的接口将所返回的结果提供给用户。 

在一个实施方式中，规则配置组件106支持用于从用户接收关于软件代码开发过程的数据，和将该数据转换为可执行验证规则的一个或多个用户接口方法。特别地，用户接口用于向规则配置组件106供给一个或多个过程模式。过程模式包括由用户提供的如下数据，该数据描述了给定的开发过程并且可以被转换、变换或以其他方式进行处理，以提供可执行验证规则。例如，正如下面更详细地描述的那样，可以使用图形用户接口(其示例在图6中图示出)来规定过程模式。备选地，还可以采用用户用以输入描述过程的文本串的文本用户接口，例如“在使用Y配置管理工具时，开发人员应当在对模块进行编辑之后并且在签入该模块之前，运行X质量检查工具”。无论所采用的接口类型如何，规则配置组件106都允许用户灵活地限定和/或编辑过程模式，该过程模式接着可以用于提供可执行验证规则。 

现在参考图2，其更详细地图示出了事件收集组件102。在所图示的实施方式中，事件收集组件102包括操作性地连接到多个开发工具202a-n的多个数据收集组件204a-n。用于实现这种数据收集组件204的各种各样的技术对于本领域普通技术人员而言是已知的。例如，在所图示的实施方式中，每个数据收集组件204可以经由一个或多个中介通信网络来访问其相应的开发工具202的API。备选地，每个数据收集组件204可以和与其对应的开发工具202共同驻留在给定工作站上，从而经由该工作站的内部信道与开发工具202通信。更进一步，给定的数据收集组件204可以直接集成到其对应的开发工具202中，如在本例中作为所谓的“插件”程序等。每个数据收集组件204可以在“推送”或“拉取”配置下操作，正如本领域中已知。在推送配置下，数据收集组件204主动地按照所检测到的那样提供原始事件数据。相反，在拉取模式下，数据收集组件 204定期地请求或另外(例如通过读取由开发工具维护的日志)从开发工具202获得原始事件数据。可选地，可以提供配置管理组件208以允许用户部署特定传感器，选择哪些传感器应当为激活的，等等。下面将参考图12对这种配置管理组件208的实施方式进行描述。 

每个数据收集组件204高效地操作为传感器以收集原始开发过程事件数据206。原始开发过程事件数据206在如下程度上构成“含噪”数据流，除对系统100有特定用处的事件数据之外，还有很大一部分原始开发过程事件数据206对于该目的而言是无用的。如果不过滤掉这种无关的数据，则将负面地影响系统100监控过程遵守的效率并且潜在地影响其准确度。例如，在开发工具包括单独开发人员的工作站上的IDE的实例的情况下，除感兴趣的事件(例如“已创建的模块”、“已打开的模块”、“已编辑的模块”、“已关闭的模块”、“已调用的单元测试”、“在编辑会话中添加或修改的“行”数量”等)之外，由对应的数据收集组件收集的原始开发过程事件数据206可以包括其他事件数据，诸如“用户登录”、对软件代码文件所执行的特定操作(例如变量的添加或修改)等，该其他事件数据并不辅助监控过程的遵守。应当注意，由于原始开发过程事件数据206可以出于很多目的而重新使用，数据收集组件204收集全面的一组数据，诸如时间戳、开发人员姓名、机器名称、事件类别、事件子类别、工具名称、事件日志等。 

原始开发过程事件数据206可以存储在诸如计算机存储器之类的合适的存储组件中，正如由例如通过合适的数据库管理系统实现的数据库所体现的。此后，可以使用查询处理组件214来基于由查询形成组件212提供的适当配置的查询，来仅提取原始开发过程事件数据206的有用部分。接着，由查询形成组件212提供的查询可以根据由系统100的用户提供的过滤特征210来形成。例如，考虑想要仅集中于与代码质量工具有关的事件并且进一步仅集中于特定工具的项目；例如PMD(结合“JAVA”语言程序而使用的公知代码质量工具)。在此情况下，查询将使用事件类别和工具名称参数 来过滤原始事件数据，并且仅提取由PMD生成的那些事件。在一个实施方式中，过滤特征210由项目用户限定为一组对系统的配置性质选项。例如，可以使用配置文件或用户接口机制来输入过滤特征210，用户接口机制为用户提供了一组可用的特征，从而使得用户根据需求选择/取消选择特征。使用这些过滤特征，查询形成组件212实质上创建了过滤器。作为实现示例，过滤器可以实现为在原始事件数据206上起作用的SQL查询。例如，诸如“SELECT*FROMEVENTS WHERE TOOL LIKE‘PMD’”的查询将选择由PMD工具生成的事件的所有特征。可以通过包括特定字段作为SELECT语句的一部分来实现进一步过滤，例如，使用开发人员姓名和时间戳作为约束条件将得到经处理的事件信息，该经处理的事件信息包括已经执行了PMD的开发人员和执行时间。 

查询处理组件214的输出是开发过程事件信息216。在已经如上所述地进行了过滤的情况下，开发过程事件信息216应当包括对应于在确定软件开发过程遵守时最有用的那些事件的数据。正如原始开发过程事件数据206的情况那样，开发过程事件信息216可以存储在诸如计算机存储器之类的合适的存储组件中，正如由例如通过合适的数据库管理系统实现的数据库所体现的。 

图3更详细地图示出了规则执行组件104的实施方式。特别地，规则执行组件104包括规则引擎302，规则引擎302基于一个或多个可执行验证规则304(例如从规则存储组件108获得)和开发过程事件信息而操作。在一个实施方式中，规则执行组件104实现为所存储的、由一个或多个处理设备执行的指令，正如本领域中已知。因此，首先生成规则引擎302的实例，并且将可执行验证规则304加载到由规则引擎使用的工作存储器中。另外，还将开发过程事件信息216(或者其至少一部分)加载到规则引擎302的工作存储器中。 

正如本领域中已知，对规则引擎302的工作存储器进行填充的过程称为事实判定。在利用必需的规则和事件信息填充工作存储器之后，规则引擎的规则推断机制尝试找到所判定的事实(事件信息) 与规则之间的匹配。正如本领域中进一步已知，规则推断机制可以采用前向成链，其中规则推断机制将每个规则的前驱或条件与所判定的事实相比较，如果找到匹配，则将每个规则的后继添加到所判定的事实，即如果符合其条件则该规则被满足。备选地，规则推断机制可以采用后继成链，其中该后继成链首先尝试匹配每个规则的后继，当找到这种匹配时，进一步尝试找到与所匹配的规则的前驱的匹配，即如果找到了规则的目标，则如果还找到了其条件声明的话，规则被满足。备选地，给定的规则在如下程度上不会被给定的一组所判定的事实涉及，即其前驱和目标都不会在所判定的事实中被识别。规则引擎302的又一种实现对于本领域普通技术人员而言可能是显然的。无论所采用的机制如何，在已经检查了所有的规则之后，可以正如所示地将其相应的状态(即满足、违反和/或未涉及)放置在结果存储组件110中。另外，还可以将关于任何规则违反的附加信息存储在结果存储组件110中。例如，这种附加信息可以包括引发由给定规则违反所涉及的事件的开发人员的标识、关于这种事件是何时发生的时间戳、所违反的规则的标识等。 

现在参考图4，其进一步图示出了可以用于实现本公开的教导的代表性处理设备400。设备400可以用于实现例如图1至图3中所图示的一个或多个组件。无论如何，设备400包括耦合到存储组件404的处理器402。存储组件404接着包括所存储的可执行指令416和数据418。在一个实施方式中，处理器402可以包括一个或多个处理设备，诸如微处理器、微控制器、数字信号处理器或者其组合，该组合能够执行所存储的指令416并且对所存储的数据418进行操作。类似地，存储组件404可以包括一个或多个设备，诸如易失性或非易失性存储器，包括但不限于随机存取存储器(RAM)或只读存储器(ROM)。更进一步，存储组件404可以体现为各种各样的形式，诸如硬盘驱动器、光盘驱动器、软盘驱动器等。图4中所图示的类型的处理器和存储布置对于本领域普通技术人员而言是公知的。在一个实施方式中，在此描述的处理技术实现为存储组件404内的可 执行指令和数据的组合。 

正如所示，设备400可以包括与处理器402通信的一个或多个用户输入设备406、显示器408、外设接口410、其他输出设备412以及网络接口414。用户输入设备406可以包括用于向处理器402提供用户输入的任何机制。例如，用户输入设备406可以包括键盘、鼠标、触摸屏、麦克风和合适的语音识别应用或者设备400的用户可以用以向处理器402提供用户输入的任何其他装置。显示器408可以包括任何常规的显示机制，诸如阴极射线管(CRT)、平板显示器、或者本领域普通技术人员已知的任何其他显示机制。在一个实施方式中，显示器408结合合适的所存储的指令416，可以用于实现图形用户接口。以这种方式实现图形用户接口对于本领域普通技术人员来说是公知的。外设接口410可以包括与各种外围设备通信所需的硬件、固件和/或软件，诸如媒体驱动器(例如磁盘驱动器或光盘驱动器)、其他处理设备或者结合本技术而使用的任何其他输入源。类似地，其他输出设备412可以可选地包括类似的媒体驱动机制、其他处理设备或者能够向设备400的用户提供信息的其他输出目的地，诸如扬声器、LED、触觉输出等。最后，网络接口414可以包括允许处理器402经由有线或无线网络(无论是局域的还是广域的，私有的还是公共的)与其他设备通信的硬件、固件和/或软件，正如本领域中已知。例如，这种网络可以包括万维网或因特网，或者私有企业网络，正如本领域中已知。 

尽管已经将设备400描述为用于实现在此描述的技术的一种形式，但本领域普通技术人员将意识到可以采用其他的、功能性上等同的技术。例如，正如本领域中已知，经由可执行指令实现的某些或全部功能性还可以使用诸如专用集成电路(ASIC)、可编程逻辑阵列、状态机等固件和/或硬件来实现。另外，设备400的其他实现可以包括比所图示的更多或更少数量的组件。再一次，本领域普通技术人员将意识到，可以按照这种方式使用的大量变型。更进一步，虽然图4中图示出了单个设备400，但是应当理解可以将这种处理设 备的组合配置为联合操作(例如使用已知的联网技术)以实现本公开的教导。 

图5是图示出根据本公开对过程模式进行处理的流程图。在一个实施方式中，图5中所图示的操作由图4中所图示的设备400在实现图1的系统100时执行。由此，开始于框502，处理开始，其中例如由规则配置组件106接收第一过程模式和第二过程模式。如上所述，这可以通过使用合适的文本和/或图形用户接口来实现。用于这一目的的图形用户接口的代表性实施方式在图6中进一步图示出。 

在所图示的示例中，图形用户接口600包括配置窗口602和控制面板窗口604。配置窗口602和控制面板窗口604共同实现了用于捕获过程模式的特定于域的语言(DSL)的前端。在一个实施方式中，图形用户接口600可以使用对特定于域的语言的开发提供辅助的多个公知工具中的任何一种(诸如结合集成了Eclipse的软件开发环境(IDE)而使用的通用Eclipse建模系统(GEMS))来实现。正如本领域中已知，与例如通用编程语言相反，特定于域的语言是专用于特定域、表示技术和/或解决方案技术的编程或规范语言。这在图6中图示出，其中在控制面板窗口606内提供特定于软件开发过程的多个模板组件604。正如所示，每个模板组件604体现了典型地在软件开发过程的域中找到的已知状态(或者动作、事件等)。例如，在软件开发领域中已知，应当发生的典型事件是开发人员编辑特定的代码部分。因此，这一点的发生表示为由标记为“编辑代码”的模板组件来表明的通用状态。需要发生以便证明开发人员事实上已经编辑了代码的底层原始事件被限定为在“编辑代码”模板中阐明的条件(例如通过主题专家指示)。使用这一已知技术，可以限定典型的和/或所希望的状态的进一步示例，以便确保所有所希望的软件开发过程都可以充分地捕获。 

在图6中所图示的示例中，每个模板组件由图形式图标和文本串的组合来表示，尽管本领域普通技术人员将意识到这并非必要条件。在一个实施方式中，可以经由结合图形用户接口而操作的用户 输入设备接收选择信息，该用户输入设备例如是鼠标和光标组合，从而用户将光标定位在给定图标上，并且点击鼠标上的按钮以选择该图标。再次参考图6中所图示的实施方式，选择信息可以进一步包括表明用户已经将所选择的图标拖曳并放下(再次使用例如光标/鼠标组合)到配置窗口602中的信息。可以重复这些过程，直到将所有所希望的状态610都被放置在窗口602中为止。此外，提供连接符模板608以指示各种状态之间的流。如现有技术中已知，当定义状态图时，连接符611可以配置用于定义导致状态机从一个状态向另一状态移动的条件。总体上，所希望的状态610和此类状态之间的连接符611定义过程模式的示例。如进一步示出，可以提供规则名称域612，从而使得用户可以提供用于规则的名称，而提供规则描述域614以便捕获由过程模式定义的规则的更详细的文本描述。一旦过程模式和所附的数据612、614已经被完整地提供，用户可以选择保存按钮616以便存储所输入的数据以供后续使用。 

如上所述，与使用图形用户接口600来捕获过程模式不同，为了这一目的，可以等同地采用文本用户接口。正如本领域中已知，这种接口可以包括使得用户能够限定一组所希望的条件的必要提示(以例如下拉菜单和文本输入域的形式)。例如，可以提供用于输入限定“if-then”(如果-那么)条件的数据的提示。可以按照类似的方式限定其他条件。更进一步，可以提供提示来将各种所限定的条件链接在一起(例如，诸如“and(与)”、“or(或)”、“not(非)”等逻辑运算符)，从而使得可以完整地限定所希望的状态。例如，使用这一方法，可以捕获规则如“项目要求所有开发人员在代码签入之前‘修复’‘优先级1’问题”。本领域普通技术人员将容易地限定进一步的示例。更进一步，用于实现这种用来捕获过程模式的文本接口的技术对于本领域普通技术人员来说是已知的。 

再一次参考图5，如上所述，在框502处使用例如上述用户接口机制中的任何一种来接收第一过程模式和第二过程模式。注意，第一过程模式和第二过程模式并非一定需要在相对于彼此的短暂时间 内接收；事实上，因为它们存储在合适的存储设备中，所以实际上在第一过程模式的接收与第二过程模式的接收之间可能经过任何时间段。然而，在一个实施方式中，可能希望，在创建新的过程模式时，例如当用户选择保存按钮616时，将新创建的过程模式与现有的过程模式相比较。无论如何，处理在框504处继续，其中确定是否有机会合并第一过程模式和第二过程模式。在一个实施方式中，这是通过对限定每个过程模式的各种状态进行比较来实现的。注意，在规则当前并不是如在上述过程模式的情况下那样以状态图形式表示的情况下，可以使用公知技术将规则转换为这种状态图形式。另外，用于对曲线图表示进行比较的技术在本领域中是公知的。可以使用诸如JUNG(当前可在http://jung/sourceforge.net/获得)之类的公知曲线图分析库来进行曲线图比较。与此类似，可以通过使用诸如GQL4JUNG(当前可在http://code.google.com/p/gq14jung/获得)之类的工具，使用XPATH查询语言来进行曲线图查询和比较。无论所使用的方法如何，曲线图比较都确立了两个曲线图之间的顶点和边之间的共性度。由此，共性度越高，两个曲线图的这些区段相似的置信度越高。这一点的示例在图7至图9中图示出。 

图7图示出了可以称为“质量检查遵守”的第一过程模式。正如所示，质量检查遵守过程模式表示为如下状态图，其中初始状态是“新代码文件”或“签出代码”，前者针对创建新代码文件的实例，而后者针对代码仓库中已经存在代码文件的实例。无论如何，图7中图示的其他状态包括“代码编辑”(其中开发人员对代码文件进行编辑)、“编译代码”(对应于编译代码文件中的代码的动作)、“运行质量工具”(对应于所关注的代码文件上正在执行的代码质量工具)以及“签入代码”(其中将代码文件签入到代码仓库中)。正如进一步示出的那样，可以限定每个状态之间的多个状态转移。每个状态可以包括用于限定该状态的给定实例的各种各样的信息，该状态诸如任何输入状态(导致这一状态的状态)和/或输出状态(后接这一状态的状态)；标识哪一部分代码与该状态的这 一实例相关的实体信息；进入时间；退出时间；在完成状态后提供可识别的结果的那些情况下的状态结果；以及表明对于给定的一组原始事件数据，这一状态被遍历的次数的访问计数。类似地，每次转移可以包括各种信息，诸如输入状态(转移从中源发的状态)和输出状态(转移在其中终止的状态)；在状态结果可用的那些实例中的最后的状态结果；表明转移何时发生的发起时间；以及表明对于给定的一组原始数据，发生了多少次转移的访问计数。 

正如所示，多个转移包括对对应于该转移的发生的状态结果的指示。例如，在“编译代码”状态的情况下，“失败”状态结果对应于转移回“代码编辑”状态，而“通过”状态结果对应于转移回“代码编辑”状态或转移到“运行质量工具”状态。另外，图示为虚线的各种有害转移被示出为有时根据事件数据而发生但不应当发生的转移的示例。例如，根据所限定的过程，“运行质量工具”状态中的“失败”结果应当导致转移到“代码编辑”状态。然而，以某个频率发生的有害转移是从“运行质量工具”状态转移到“签入代码”状态，而不论“失败”结果是否发生。 

以类似的风格，图8图示出了可以称为“TDD遵守”的过程模式。TDD(或测试驱动设计)是基于测试和代码编辑的相对快速的迭代的软件开发的方法。无论如何，在所示的示例中，TDD遵守过程模式包括多个实际上相同的状态，正如在图7和图8中用具有加粗轮廓的椭圆来突出显示的那样，即“新代码文件”、“代码编辑”、“编译代码”、“签入代码”和“结束”状态。然而，与质量检查遵守过程模式不同，唯一的开始状态是不同的状态，称为“新单元测试文件”(对应于开发人员创建单元测试文件)，随后是“单元测试编辑”(其中开发人员对单元测试文件进行各种改变)。另外，图7中所图示的“运行质量工具”状态基本上被图8中所示的“运行单元测试”状态所替换。如同之前，图8中所图示的新状态包括状态之间的各种转移，包括若干经常发生的有害转移的示例。 

使用本领域普通技术人员已知的曲线图比较技术，识别两个曲 线图之间的类似状态，即“新代码文件”、“代码编辑”、“编译代码”、“签入代码”和“结束”状态。一般地，当多个曲线图具有共同的起点和终点，并且中间状态可以通过单独曲线图中所限定的普通状态转移来达到时，可以合并曲线图。进一步，如果存在任何停滞状态或不可达到的状态，则不能合并曲线图。由此，在本示例中，基于这一状态共性，可以如图9中进一步图示的那样合并两个过程模式。正如所示，合并后的过程模式包括共同状态以及第一过程模式和第二过程模式中的每一个所特有的附加状态两者。注意，为易于说明，图9中所图示的合并后的过程模式不包括图7和图8中所示的任何有害转移示例。当然，仍然应当理解，在如下程度上图9中所图示的那些转移之外的转移可以构成有害转移，即它们不符合合并后的过程模式。 

再次参考图5，如果没有找到过程模式之间的合并机会，则处理在框510处继续，其中将相应的过程模式转换为可执行过程验证规则，如果先前没有完成的话。例如，在GEMS的上下文中，如上所述，可以获得插件程序来将过程模式转换为可执行代码。如果不是已经存储，则随后存储所得到的可执行过程验证规则，正如在框512处所表明的那样。然而，如果在框504处找到了合并机会，则在框506处继续处理，其中如例如图9中所示合并第一过程模式和第二过程模式。此后，处理可以可选地在框508处继续，其中将合并后的过程模式提供给用户，以便获得对合并后的过程模式的反馈(如果有的话)。在一个实施方式中，用户可以是主题专家，其具有关于针对给定软件开发项目的所希望的软件开发过程的特定知识。本领域普通技术人员将意识到，可以合并过程模式的事实并非在全部情形下都是所希望的，或者可能仅在以某种方式修改了合并后的过程模式之后才是所希望的。例如，可以经由图中6所图示类型的图形用户接口将图9中所图示的合并后的过程模式呈递给用户，从而允许用户同意它而不需要进一步的编辑，编辑它然后表明同意，或者拒绝合并后的过程模式。假定用户同意合并后的过程模式(需要或 不需要进一步编辑)，则处理仅基于合并后的过程模式在框510、512处继续，如上所述。 

现在参考图10，其示出了图示出用于监控开发人员对软件代码开发过程的遵守的方法的流程图。在一个实施方式中，由图1中所图示的系统100至少部分地执行针对图10而描述的处理。另外，图10中所图示的处理可以在一个或多个处理设备(诸如以上针对图4所描述的)的辅助下执行。无论如何，处理在框1002处开始，在此配置系统100。在一个实施方式中，这种配置包括执行建立一个或多个传感器以与各种开发工具120一起工作，以及如上所述地为该系统配置一个或多个规则。前者的示例在图11中图示出，该图提供了图形用户接口1102。 

接口1102可以通过例如规则配置组件106来实现。正如所示，接口1102包括配置传感器按钮1104、规则管理器按钮1106和报告按钮1108。选择配置传感器按钮1104引起将用户接口1102显示为使得用户可以配置先前部署的传感器。例如，正如所示，每个传感器可以包括所图示的表中的一行(例如通过其相应的描述来区分)，从而用户能够操纵复选框以启用(选择)或禁用(取消选择)给定传感器。另外，提供列，从而可以指定针对每个传感器的间隔，这种间隔将被用于确定给定传感器应当提供其原始事件数据的频率(或被检查以获得这种原始事件数据)。正如进一步所示，在给定传感器是经由例如web服务或其他远程服务来实现的情况下，可以提供到给定服务的路径名称。备选地，在传感器被简单地嵌入给定工具、应用等的情况下，该传感器可以简单地根据所选择的频率来推送原始事件数据。提供概要视图窗口1110，从而可以显示当前已启用和配置的传感器和/或规则的数量。一旦已经选择和配置了所希望的传感器，用户就可以选择保存传感器配置按钮1112来保存输入传感器配置数据。正如本领域普通技术人员已知的那样，随后使用所保存的传感器配置数据以确保正确的传感器正在根据需要而运行。 

针对图12进一步图示出了以上针对框1002而描述的后一类型的配置的另一示例。特别地，选择规则管理器按钮1106可能引起提供图形用户接口1202。注意，假定使用图11的传感器配置数据，概要视图窗口1110反映了在此时已经配置了四个不同的传感器的事实。以类似于传感器配置接口1102所采用的方式，规则管理器接口1202可以针对每个可用的规则提供分开的行。再一次，在所图示的示例中，各种规则通过其相应的文本描述来区分。当然，为了这一目的，可以等同地采用某些其他的识别标记，诸如其相应的标题。无论如何，可以提供复选框，从而用户能够启用或禁用给定规则。如果已经启用了所有所希望的规则，则用户可以选择保存规则配置按钮1206，由此引起保存所输入的规则配置数据。备选地或附加地，可以选择添加定制规则按钮1208，从而用户能够使用例如上述图形用户接口600来限定新规则。在已经以这种方式限定了新规则的情况下，用户随后可以如上所述地启用该规则。 

再一次参考图10，在已经如需要配置了系统之后，处理可以在框1004处继续，其中根据配置信息来收集上述开发过程事件信息。在框1006处继续，可以将以这种方式收集的开发过程事件信息与先前在框1002处启用的各种可执行过程验证规则相比较。然后，在框1008处确定：在框1008处是否有任何可执行过程验证规则尚未得到满足，即是否已经违反了任何规则。如果为否，则处理在框1004处继续，其中重复搜集开发过程事件数据和将其与已启用的规则相比较的过程。注意，关于是否已经违反了规则的确定可以由限定该规则的意义来规定。例如，肯定规则可以表明要鼓励的行为，即该规则仅在开发过程事件数据表明过程以某种方式偏离时才被违反。备选地，否定规则可以表明要避免的行为，即该规则仅在开发过程事件数据表明事实上执行了不希望的过程时才被违反。本领域普通技术人员将认识到，用于限定规则的各种意义(肯定或否定)可能具有伴随的优点和缺点。例如，在多个事件中的任何一个可能导致不期望的偏离的情况下，肯定规则可能更有用。相反，在不期望的过 程被开发人员频繁采用的那些实例中，否定规则可能有用。 

无论如何，如果确定已经违反了至少一个规则，则处理在框1010处继续，其中如上所述地生成故障指示，并将其存储在合适的存储组件中。最后，在框1012处，可以可选地生成报告并将其呈递给发出请求的用户。针对图13进一步图示出可以用于这一目的的图形用户接口1302的示例。在一个实施方式中，图形用户接口1302可以由报告组件112提供。特别地，当用户选择报告按钮1108时，可以采用接口1302。正如所示，该接口可以包括用于选择要生成的报告的类型的机制；在所图示的示例中，为了这一目的，采用了下拉菜单。本领域普通技术人员将意识到，除下拉菜单之外的机制可以用于这一目的。无论用于选择报告的机制如何，都可以基于使在此处描述的过程遵守系统而获得的数据来生成报告1306。在所图示的示例中，提供针对每个规则的过程违反数量。使用公知技术，可以将报告1306提供给任何所希望的信道(例如用于硬副本输出的打印机、用于生成和存储电子文件的合适应用、电子邮件、RSS馈送等)。 

如上所述，本公开描述了用于改善对用于过程遵守监控系统中的各种规则的管理的各种方法和装置。这一般地通过如下方式来实现，即在可能的情况下合并过程模式并且使用所得到的合并后的过程模式来生成可执行过程验证规则。然后，可以在过程遵守监控系统中采用这种规则，以确定对由可执行过程验证规则代表的一个或多个过程的遵守程度。通过以这种方式合并规则，可以减少规则数量，从而消除了在将规则与开发过程事件数据相比较时的冗余处理。另外，可以按照这种方式减少规则的数量，从而简化对系统的管理。至少由于这些原因，上述技术代表了优于现有技术教导的进步。 

尽管已经示出和描述了特定的优选实施方式，但本领域普通技术人员将意识到，在不脱离本教导的情况下，可以进行改变和修改。因此，可以想到，上述教导的任何和所有修改、变型或等同形式都落入上述基本底层原理和在所要求保护的范围内。