專利名稱：在用于監(jiān)控開發(fā)人員對軟件代碼開發(fā)過程的遵守的系統(tǒng)中的規(guī)則合并的制作方法
技術(shù)領(lǐng)域：
本公開一般地涉及軟件代碼的開發(fā)，并且特別地涉及用于在用于監(jiān)控開發(fā)人員對軟件代碼開發(fā)過程的遵守的系統(tǒng)中合并規(guī)則的技術(shù)。
背景技術(shù)：
軟件代碼——包括可以用于控制和命令諸如微處理器、微控制器、協(xié)處理器等一個或多個處理設(shè)備的操作的指令——無所不在，并且遍及現(xiàn)代技術(shù)的很多方面。軟件開發(fā)項目領(lǐng)域(有時涉及進行為期數(shù)月甚至數(shù)年的工作的大量軟件開發(fā)人員(即負責(zé)軟件代碼的實際編寫的那些人員))要求使用軟件代碼開發(fā)過程，開發(fā)人員需要采用該軟件代碼開發(fā)過程以便提供高質(zhì)量的代碼。這種軟件開發(fā)過程一般地規(guī)定了開發(fā)人員在考慮軟件代碼 “完成”之前必須采取的各種步驟。例如，軟件開發(fā)過程可以規(guī)定，在使用公知的配置管理和 /或源控制倉庫工具來進行簽入之前，開發(fā)人員將如何查看代碼質(zhì)量、執(zhí)行單元測試、修復(fù)缺陷等。實踐已經(jīng)證明，確保軟件代碼開發(fā)過程的高保真采用會得到更高質(zhì)量的代碼。這種軟件代碼的改善的質(zhì)量最終導(dǎo)致整個集成軟件項目的改善的質(zhì)量，并且最終得到改善的終端用戶滿意度。相反，開發(fā)人員不遵守這種軟件代碼開發(fā)過程會導(dǎo)致更有可能出現(xiàn)更低質(zhì)量的代碼、代碼功能中的更多錯誤、增加的集成問題以及終端用戶的不滿意度。即便不考慮以下代碼開發(fā)過程的重要性，當前項目管理者仍然難以驗證開發(fā)人員實際上遵守了所推薦的軟件代碼開發(fā)過程(特別是對于采用了大量和/或地理上分散的開發(fā)人員的大型項目而言)。由于軟件代碼的實際創(chuàng)建典型地發(fā)生在多個開發(fā)人員的本地工作站和集成開發(fā)環(huán)境(IDE)中，從物理上說項目管理者幾乎總是不可能直接監(jiān)控每個開發(fā)人員的工作站及他/她的工作。這種監(jiān)管缺失通常導(dǎo)致開發(fā)人員繞過軟件代碼開發(fā)過程由此降低了所得到的代碼的質(zhì)量。另外，修正所產(chǎn)生的質(zhì)量問題所需的時間和工作量降低了完成開發(fā)項目的整體效率。為解決這些問題，已經(jīng)開發(fā)了系統(tǒng)來提供對于開發(fā)人員對軟件開發(fā)過程的遵守的自動化監(jiān)控。例如，Johnson 和 Kou 在 AGILE 2007 中的 “Automated Recognition of Test-Driven Development with Zorro，，一t 中了Mi胃的 Zorro 胃·。 ZorrogMiJ 用開源框架(Hackystat)來在各種開發(fā)環(huán)境工具中部署“傳感器”，以收集加有時間戳的原始事件數(shù)據(jù)。軟件開發(fā)流分析(SDSA)應(yīng)用分析原始事件數(shù)據(jù)，以確定“事項(episode)”在按時間排序的事件數(shù)據(jù)流內(nèi)的存在。Zorro應(yīng)用繼而對事項執(zhí)行基于規(guī)則的分析以確定開發(fā)人員是否遵守了特定的開發(fā)過程，例如測試驅(qū)動開發(fā)(TDD)。盡管諸如Zorro之類的系統(tǒng)對于確定開發(fā)人員對所希望的過程的遵守而言是有益的，但是可以預(yù)見，更復(fù)雜的過程將需要跟蹤大量狀態(tài)(例如Zorro系統(tǒng)中所使用的事項)，從而導(dǎo)致大量的更復(fù)雜的規(guī)則。 為了更好地縮放如Zorro之類的過程遵守監(jiān)控系統(tǒng)，提供用于更高效地管理用于評價過程遵守的規(guī)則的技術(shù)將是有益的。

發(fā)明內(nèi)容
本 公開使得項目管理者等能夠監(jiān)控軟件開發(fā)人員對一個或多個軟件代碼開發(fā)過程的遵守。一般地，這是通過如下方式實現(xiàn)的，即捕獲由開發(fā)人員執(zhí)行的相關(guān)活動的發(fā)生 (正如由其所使用的開發(fā)工具所表明的那樣)，并且隨后將這些活動與所希望的軟件代碼開發(fā)過程的基于規(guī)則的模型相比較。給定的基于規(guī)則的模型與所捕獲的活動之間的差異表明并未遵守軟件開發(fā)過程。在一個實施方式中，當接收了第一過程模式和第二過程模式并將其合并以提供合并后的過程模式時，會促進對規(guī)則的管理。每個過程模式，其可以由處理設(shè)備經(jīng)由文本和/或圖形用戶接口來接收，代表了所希望的軟件代碼開發(fā)過程的至少一部分?？蛇x地，可以將合并后的過程模式呈遞給主題專家以獲得對其的反饋。繼而，可以將合并后的過程模式轉(zhuǎn)換為可執(zhí)行過程驗證規(guī)則，其用于在監(jiān)控過程遵守時使用。在一個實施方式中，通過首先將各過程模式轉(zhuǎn)換為曲線圖形式來完成對過程模式的合并。對所得到的第一曲線圖和第二曲線圖進行比較以確定第一曲線圖與第二曲線圖之間的交點，從而使得可以產(chǎn)生合并后的曲線圖。繼而，將合并后的曲線圖轉(zhuǎn)換為合并后的過程模式并隨后如上所述地進行處理。在此處描述的一個實施方式中，事件收集組件收集由開發(fā)人員生成的開發(fā)過程事件信息，并且規(guī)則執(zhí)行組件將其與軟件代碼開發(fā)過程的一個或多個可執(zhí)行驗證規(guī)則代表相比較。根據(jù)這些比較，如果不符合至少一個可執(zhí)行驗證規(guī)則的任何條件，則生成和存儲一個或多個故障指示。此后，報告組件可以生成關(guān)于故障指示的報告，以便隨后呈遞給用戶。在又一實施方式中，事件收集組件采用數(shù)據(jù)收集組件，該數(shù)據(jù)收集組件從由開發(fā)人員使用的一個或多個開發(fā)工具收集原始開發(fā)過程事件數(shù)據(jù)。此后，采用過濾規(guī)則來對原始開發(fā)過程事件數(shù)據(jù)進行過濾以提供開發(fā)過程事件信息。可以采用查詢形成組件來制訂過濾規(guī)則。在此進一步描述根據(jù)這些實施方式和其他實施方式的各種方法和裝置。以這種方式，本公開提供如下技術(shù)，該技術(shù)提高了自動化過程遵守監(jiān)控系統(tǒng)能夠確定開發(fā)人員對一個或者多個軟件代碼開發(fā)過程的遵循程度的效率。例如，在此描述的規(guī)則合并能力減少了必須維持的規(guī)則的數(shù)量以及評價這種規(guī)則所需的處理。也就是說，減輕了跟蹤并定期評價多個不同規(guī)則的負擔(dān)，而由合并后的規(guī)則所提供的覆蓋相對于未合并的規(guī)則而言并沒有任何損失。另外，可以改進評估規(guī)則的速度。在不進行合并的情況下，將需要針對每個規(guī)則而獨立地評價兩個或更多規(guī)則實際上共有的狀態(tài)。為了評價所有規(guī)則，這會導(dǎo)致增加的處理負擔(dān)。這種共有狀態(tài)的合并消除了其冗余評價，降低了處理開銷，并且有益地減小了其為評價規(guī)則而耗費的時間。因此，這種改善的監(jiān)控能力確保了更好的過程遵守和隨后在軟件代碼質(zhì)量、整體開發(fā)效率和終端用戶滿意度方面有所改善。


在所附權(quán)利要求書中特別地闡明了本公開中所描述的特征。在結(jié)合附圖而考慮以下詳細描述后，這些特征和伴隨的優(yōu)點將變得明顯?，F(xiàn)在僅通過示例的方式、參考附圖來描述一個或多個實施方式，在附圖中，類似的參考標號表示類似的元素，并且其中圖1是根據(jù)本公開的裝置的框圖2是更詳細地圖示出的圖1的裝置的事件收集組件的框圖；圖3是更詳細地圖示出的圖1的裝置的規(guī)則執(zhí)行組件的框圖；圖4是可以用于實現(xiàn)在此描述的各種實施方式的處理設(shè)備的框圖；圖5是圖示出根據(jù)本公開對過程模式的處理的流程圖；圖6是圖示出根據(jù)在此描述的實施方式的、用于捕獲過程模式的圖形用戶接口的實施方式的示圖；圖7至圖9是根據(jù)本公開的曲線圖形式的過程模式及其合并的示例的圖示；圖10是圖示出根據(jù)在此描述的各種實施方式的、用于監(jiān)控開發(fā)人員對軟件代碼開發(fā)過程的遵守的方法的流程圖；以及圖11至圖13是圖示出根據(jù)在此描述的各種實施方式的圖形用戶接口的各種實施方式的示圖。
具體實施方式
現(xiàn)在參考圖1，其示出了用于在監(jiān)控軟件代碼開發(fā)人員對一個或多個軟件代碼開發(fā)過程的遵守時使用的裝置100。特別地，裝置100包括事件收集組件102，該事件收集組件102操作性地連接到規(guī)則執(zhí)行組件104。規(guī)則配置組件106操作性地連接到規(guī)則存儲組件108，規(guī)則存儲組件108接著操作性地連接到規(guī)則執(zhí)行組件104。結(jié)果存儲組件110操作性地連接到規(guī)則執(zhí)行組件104和報告組件112兩者，正如所示。正如進一步所示，一個或多個開發(fā)工具120經(jīng)由事件收集組件102與系統(tǒng)100通信。一般地，事件收集組件102從一個或多個開發(fā)工具120收集開發(fā)過程事件信息。開發(fā)過程事件信息包括關(guān)于由開發(fā)人員采取的動作的數(shù)據(jù)，正如由一個或多個開發(fā)工具120 所顯現(xiàn)的。這種數(shù)據(jù)可以包括對由開發(fā)人員采取的動作(或由開發(fā)人員引起的事件)的特定性質(zhì)的指示，事件或動作發(fā)生的日期和/或時間，以及引起事件或動作發(fā)生的特定開發(fā)人員的標識。開發(fā)工具120包括開發(fā)人員在編寫或產(chǎn)生軟件代碼時使用的任何裝置，該裝置易于實現(xiàn)對構(gòu)成開發(fā)過程事件信息的數(shù)據(jù)的自動化收集。例如，開發(fā)工具120可以包括多個公知IDE工具中的任何一種，諸如“ECLIPSE” IDE，Microsoft的“VISUAL STUDIO，，， BEA的“WORKSHOP”，Oracle的“ JDEVEL0PER”等。正如本領(lǐng)域中所知，開發(fā)工具120典型地包括允許收集事件信息的應(yīng)用協(xié)議接口(API)。盡管在圖1中未詳細繪出，事件收集組件 102與開發(fā)工具120之間的連接可以是根據(jù)公知技術(shù)的，并且可以包括例如正如由局域網(wǎng)、 專用或公共(例如萬維網(wǎng)/因特網(wǎng))廣域網(wǎng)等實現(xiàn)的網(wǎng)絡(luò)連接。基于如此收集的開發(fā)過程事件信息，規(guī)則執(zhí)行組件104將由一個或多個可執(zhí)行驗證規(guī)則(存儲在規(guī)則存儲組件108中)確立的條件與開發(fā)過程事件信息相比較。存儲在規(guī)則存儲組件108中的每個可執(zhí)行驗證規(guī)則，在如下程度上代表了軟件代碼開發(fā)過程，即由可執(zhí)行驗證規(guī)則確立的條件確立了如下動作或事件，這些動作或事件需要在開發(fā)過程事件信息內(nèi)標識，以便確認開發(fā)人員已經(jīng)(或尚未)正確地遵守軟件代碼開發(fā)過程。例如，軟件代碼開發(fā)過程可能要求在對給定代碼部分的最新近的編輯之后、但在這種代碼被簽入到配置管理倉庫中之前，在該代碼的給定部分(例如模塊、子例程等)上使用給定代碼質(zhì)量工具。在可執(zhí)行形式下，這一軟件代碼開發(fā)過程可能要求一系列動作/事件，在該動作/事件中對該代碼部分在開發(fā)人員的IDE內(nèi)被修改的最近指示具有早于對正在該代碼部分上運行的質(zhì)量工具的指示的時間/日期戳，正在該代碼部分上運行的質(zhì)量工具的指示轉(zhuǎn)而必須具有早于對該代碼部分已經(jīng)被簽入到配置管理倉庫中的指示的日期/時間戳。如果未能滿足這些條件中的任何一個，無論是由于未能執(zhí)行多個操作之一(例如在該代碼部分上運行代碼質(zhì)量工具)，還是不按順序執(zhí)行這些操作(例如在最新近一次在該代碼部分上執(zhí)行代碼質(zhì)量工具之后對所表明的該代碼部分的進一步編輯)，都將導(dǎo)致生成故障指示。在一個實施方式中，針對開發(fā)過程事件信息執(zhí)行規(guī)則是在某個定期間隔(例如每周、每兩周、每個月等)上執(zhí)行的。執(zhí)行規(guī)則的頻率部分地基于在給定所關(guān)注的開發(fā)人員數(shù)量的情況下對這種執(zhí)行進行縮放的需要。另外，對于相對復(fù)雜的規(guī)則，非常有可能的是有關(guān)的事件/狀態(tài)可以在時間上相對地間隔開。在這些實例中，可能希望的是不太頻繁的規(guī)則執(zhí)行以便確保充分的時間。更進一步，可能希望的是以不同的頻率執(zhí)行不同類型的規(guī)則，例如更頻繁地執(zhí)行不太復(fù)雜的規(guī)則，并且不太頻繁地執(zhí)行更復(fù)雜的規(guī)則。 故障指示包括表明特定可執(zhí)行驗證規(guī)則(代表對應(yīng)的軟件代碼開發(fā)過程)尚未得到滿足的數(shù)據(jù)。在一個實施方式中，故障指示包括對已經(jīng)違反的特定軟件代碼開發(fā)過程/ 可執(zhí)行驗證規(guī)則的指示以及對導(dǎo)致該違反的開發(fā)人員的指示。為了進一步為開發(fā)人員和管理者提供關(guān)于過程是如何被違反的信息，故障指示可以包括關(guān)于未被滿足的確切規(guī)則部分的附加信息，從而支持確定補救步驟，諸如訓(xùn)練、過程重新設(shè)計等。正如所述，這種故障指示存儲在結(jié)果存儲設(shè)備110中。例如，結(jié)果存儲設(shè)備110可以組織為數(shù)據(jù)庫，從而使得可以使用數(shù)據(jù)庫查詢接口來實現(xiàn)報告組件112。以這種方式，可以形成查詢(使用公知技術(shù))來確定結(jié)果存儲設(shè)備110中的哪些故障指示滿足規(guī)定的查詢。繼而，可以使用公知技術(shù)以任何合適的格式并且經(jīng)由合適的接口將所返回的結(jié)果提供給用戶。在一個實施方式中，規(guī)則配置組件106支持用于從用戶接收關(guān)于軟件代碼開發(fā)過程的數(shù)據(jù)，和將該數(shù)據(jù)轉(zhuǎn)換為可執(zhí)行驗證規(guī)則的一個或多個用戶接口方法。特別地，用戶接口用于向規(guī)則配置組件106供給一個或多個過程模式。過程模式包括由用戶提供的如下數(shù)據(jù)，該數(shù)據(jù)描述了給定的開發(fā)過程并且可以被轉(zhuǎn)換、變換或以其他方式進行處理，以提供可執(zhí)行驗證規(guī)則。例如，正如下面更詳細地描述的那樣，可以使用圖形用戶接口(其示例在圖 6中圖示出)來規(guī)定過程模式。備選地，還可以采用用戶用以輸入描述過程的文本串的文本用戶接口，例如“在使用Y配置管理工具時，開發(fā)人員應(yīng)當在對模塊進行編輯之后并且在簽入該模塊之前，運行X質(zhì)量檢查工具”。無論所采用的接口類型如何，規(guī)則配置組件106都允許用戶靈活地限定和/或編輯過程模式，該過程模式接著可以用于提供可執(zhí)行驗證規(guī)則?，F(xiàn)在參考圖2，其更詳細地圖示出了事件收集組件102。在所圖示的實施方式中， 事件收集組件102包括操作性地連接到多個開發(fā)工具202a-n的多個數(shù)據(jù)收集組件204a-n。 用于實現(xiàn)這種數(shù)據(jù)收集組件204的各種各樣的技術(shù)對于本領(lǐng)域普通技術(shù)人員而言是已知的。例如，在所圖示的實施方式中，每個數(shù)據(jù)收集組件204可以經(jīng)由一個或多個中介通信網(wǎng)絡(luò)來訪問其相應(yīng)的開發(fā)工具202的API。備選地，每個數(shù)據(jù)收集組件204可以和與其對應(yīng)的開發(fā)工具202共同駐留在給定工作站上，從而經(jīng)由該工作站的內(nèi)部信道與開發(fā)工具202通信。更進一步，給定的數(shù)據(jù)收集組件204可以直接集成到其對應(yīng)的開發(fā)工具202中，如在本例中作為所謂的“插件”程序等。每個數(shù)據(jù)收集組件204可以在“推送”或“拉取”配置下操作，正如本領(lǐng)域中已知。在推送配置下，數(shù)據(jù)收集組件204主動地按照所檢測到的那樣提供原始事件數(shù)據(jù)。相反，在拉取模式下，數(shù)據(jù)收集組件204定期地請求或另外(例如通過讀取由開發(fā)工具維護的日志)從開發(fā)工具202獲得原始事件數(shù)據(jù)?？蛇x地，可以提供配置管理組件208以允許用戶部署特定傳感器，選擇哪些傳感器應(yīng)當為激活的，等等。下面將參考圖 12對這種配置管理組件208的實施方式進行描述。每個數(shù)據(jù)收集組件204高效地操作為傳感器以收集原始開發(fā)過程事件數(shù)據(jù)206。 原始開發(fā)過程事件數(shù)據(jù)206在如下程度上構(gòu)成“含噪”數(shù)據(jù)流，除對系統(tǒng)100有特定用處的事件數(shù)據(jù)之外，還有很大一部分原始開發(fā)過程事件數(shù)據(jù)206對于該目的而言是無用的。如果不過濾掉這種無關(guān)的數(shù)據(jù)，則將負面地影響系統(tǒng)100監(jiān)控過程遵守的效率并且潛在地影響其準確度。例如，在開發(fā)工具包括單獨開發(fā)人員的工作站上的IDE的實例的情況下，除感興趣的事件(例如“已創(chuàng)建的模塊”、“已打開的模塊”、“已編輯的模塊”、“已關(guān)閉的模塊”、 “已調(diào)用的單元測試”、“在編輯會話中添加或修改的“行”數(shù)量”等)之外，由對應(yīng)的數(shù)據(jù)收集組件收集的原始開發(fā)過程事件數(shù)據(jù)206可以包括其他事件數(shù)據(jù)，諸如“用戶登錄”、對軟件代碼文件所執(zhí)行的特定操作(例如變量的添加或修改)等，該其他事件數(shù)據(jù)并不輔助監(jiān)控過程的遵守。應(yīng)當注意，由于原始開發(fā)過程事件數(shù)據(jù)206可以出于很多目的而重新使用， 數(shù)據(jù)收集組件204收集全面的一組數(shù)據(jù)，諸如時間戳、開發(fā)人員姓名、機器名稱、事件類別、 事件子類別、工具名稱、事件日志等。
原始開發(fā)過程事件數(shù)據(jù)206可以存儲在諸如計算機存儲器之類的合適的存儲組件中，正如由例如通過合適的數(shù)據(jù)庫管理系統(tǒng)實現(xiàn)的數(shù)據(jù)庫所體現(xiàn)的。此后，可以使用查詢處理組件214來基于由查詢形成組件212提供的適當配置的查詢，來僅提取原始開發(fā)過程事件數(shù)據(jù)206的有用部分。接著，由查詢形成組件212提供的查詢可以根據(jù)由系統(tǒng)100的用戶提供的過濾特征210來形成。例如，考慮想要僅集中于與代碼質(zhì)量工具有關(guān)的事件并且進一步僅集中于特定工具的項目；例如PMD (結(jié)合“JAVA”語言程序而使用的公知代碼質(zhì)量工具)。在此情況下，查詢將使用事件類別和工具名稱參數(shù)來過濾原始事件數(shù)據(jù)，并且僅提取由PMD生成的那些事件。在一個實施方式中，過濾特征210由項目用戶限定為一組對系統(tǒng)的配置性質(zhì)選項。例如，可以使用配置文件或用戶接口機制來輸入過濾特征210，用戶接口機制為用戶提供了一組可用的特征，從而使得用戶根據(jù)需求選擇/取消選擇特征。使用這些過濾特征，查詢形成組件212實質(zhì)上創(chuàng)建了過濾器。作為實現(xiàn)示例，過濾器可以實現(xiàn)為在原始事件數(shù)據(jù)206上起作用的SQL查詢。例如，諸如“SELECT*FROMEVENTS WHERE TOOL LIKE ‘PMD’”的查詢將選擇由PMD工具生成的事件的所有特征?？梢酝ㄟ^包括特定字段作為SELECT語句的一部分來實現(xiàn)進一步過濾，例如，使用開發(fā)人員姓名和時間戳作為約束條件將得到經(jīng)處理的事件信息，該經(jīng)處理的事件信息包括已經(jīng)執(zhí)行了 PMD的開發(fā)人員和執(zhí)行時間。查詢處理組件214的輸出是開發(fā)過程事件信息216。在已經(jīng)如上所述地進行了過濾的情況下，開發(fā)過程事件信息216應(yīng)當包括對應(yīng)于在確定軟件開發(fā)過程遵守時最有用的那些事件的數(shù)據(jù)。正如原始開發(fā)過程事件數(shù)據(jù)206的情況那樣，開發(fā)過程事件信息216可以存儲在諸如計算機存儲器之類的合適的存儲組件中，正如由例如通過合適的數(shù)據(jù)庫管理系統(tǒng)實現(xiàn)的數(shù)據(jù)庫所體現(xiàn)的。圖3更詳細地圖示出了規(guī)則執(zhí)行組件104的實施方式。特別地，規(guī)則執(zhí)行組件104 包括規(guī)則引擎302，規(guī)則引擎302基于一個或多個可執(zhí)行驗證規(guī)則304 (例如從規(guī)則存儲組件108獲得)和開發(fā)過程事件信息而操作。在一個實施方式中，規(guī)則執(zhí)行組件104實現(xiàn)為所存儲的、由一個或多個處理設(shè)備執(zhí)行的指令，正如本領(lǐng)域中已知。因此，首先生成規(guī)則引擎302的實例，并且將可執(zhí)行驗證規(guī)則304加載到由規(guī)則引擎使用的工作存儲器中。另外， 還將開發(fā)過程事件信息216(或者其至少一部分)加載到規(guī)則引擎302的工作存儲器中。正如本領(lǐng) 域中已知，對規(guī)則引擎302的工作存儲器進行填充的過程稱為事實判定。在利用必需的規(guī)則和事件信息填充工作存儲器之后，規(guī)則引擎的規(guī)則推斷機制嘗試找到所判定的事實(事件信息)與規(guī)則之間的匹配。正如本領(lǐng)域中進一步已知，規(guī)則推斷機制可以采用前向成鏈，其中規(guī)則推斷機制將每個規(guī)則的前驅(qū)或條件與所判定的事實相比較，如果找到匹配，則將每個規(guī)則的后繼添加到所判定的事實，即如果符合其條件則該規(guī)則被滿足。備選地，規(guī)則推斷機制可以采用后繼成鏈，其中該后繼成鏈首先嘗試匹配每個規(guī)則的后繼，當找到這種匹配時，進一步嘗試找到與所匹配的規(guī)則的前驅(qū)的匹配，即如果找到了規(guī)則的目標，則如果還找到了其條件聲明的話，規(guī)則被滿足。備選地，給定的規(guī)則在如下程度上不會被給定的一組所判定的事實涉及，即其前驅(qū)和目標都不會在所判定的事實中被識另IJ。規(guī)則引擎302的又一種實現(xiàn)對于本領(lǐng)域普通技術(shù)人員而言可能是顯然的。無論所采用的機制如何，在已經(jīng)檢查了所有的規(guī)則之后，可以正如所示地將其相應(yīng)的狀態(tài)(即滿足、違反和/或未涉及)放置在結(jié)果存儲組件110中。另外，還可以將關(guān)于任何規(guī)則違反的附加信息存儲在結(jié)果存儲組件110中。例如，這種附加信息可以包括引發(fā)由給定規(guī)則違反所涉及的事件的開發(fā)人員的標識、關(guān)于這種事件是何時發(fā)生的時間戳、所違反的規(guī)則的標識等?，F(xiàn)在參考圖4，其進一步圖示出了可以用于實現(xiàn)本公開的教導(dǎo)的代表性處理設(shè)備 400。設(shè)備400可以用于實現(xiàn)例如圖1至圖3中所圖示的一個或多個組件。無論如何，設(shè)備 400包括耦合到存儲組件404的處理器402。存儲組件404接著包括所存儲的可執(zhí)行指令 416和數(shù)據(jù)418。在一個實施方式中，處理器402可以包括一個或多個處理設(shè)備，諸如微處理器、微控制器、數(shù)字信號處理器或者其組合，該組合能夠執(zhí)行所存儲的指令416并且對所存儲的數(shù)據(jù)418進行操作。類似地，存儲組件404可以包括一個或多個設(shè)備，諸如易失性或非易失性存儲器，包括但不限于隨機存取存儲器(RAM)或只讀存儲器(ROM)。更進一步，存儲組件404可以體現(xiàn)為各種各樣的形式，諸如硬盤驅(qū)動器、光盤驅(qū)動器、軟盤驅(qū)動器等。圖 4中所圖示的類型的處理器和存儲布置對于本領(lǐng)域普通技術(shù)人員而言是公知的。在一個實施方式中，在此描述的處理技術(shù)實現(xiàn)為存儲組件404內(nèi)的可執(zhí)行指令和數(shù)據(jù)的組合。正如所示，設(shè)備400可以包括與處理器402通信的一個或多個用戶輸入設(shè)備406、 顯示器408、外設(shè)接口 410、其他輸出設(shè)備412以及網(wǎng)絡(luò)接口 414。用戶輸入設(shè)備406可以包括用于向處理器402提供用戶輸入的任何機制。例如，用戶輸入設(shè)備406可以包括鍵盤、 鼠標、觸摸屏、麥克風(fēng)和合適的語音識別應(yīng)用或者設(shè)備400的用戶可以用以向處理器402提供用戶輸入的任何其他裝置。顯示器408可以包括任何常規(guī)的顯示機制，諸如陰極射線管 (CRT)、平板顯示器、或者本領(lǐng)域普通技術(shù)人員已知的任何其他顯示機制。在一個實施方式中，顯示器408結(jié)合合適的所存儲的指令416，可以用于實現(xiàn)圖形用戶接口。以這種方式實現(xiàn)圖形用戶接口對于本領(lǐng)域普通技術(shù)人員來說是公知的。外設(shè)接口 410可以包括與各種外圍設(shè)備通信所需的硬件、固件和/或軟件，諸如媒體驅(qū)動器(例如磁盤驅(qū)動器或光盤驅(qū)動器)、其他處理設(shè)備或者結(jié)合本技術(shù)而使用的任何其他輸入源。類似地，其他輸出設(shè)備412 可以可選地包括類似的媒體驅(qū)動機制、其他處理設(shè)備或者能夠向設(shè)備400的用戶提供信息的其他輸出目的地，諸如揚聲器、LED、觸覺輸出等。最后，網(wǎng)絡(luò)接口 414可以包括允許處理器402經(jīng)由有線或無線網(wǎng)絡(luò)(無論是局域的還是廣域的，私有的還是公共的)與其他設(shè)備通信的硬件、固件和/或軟件，正如本領(lǐng)域中已知。例如，這種網(wǎng)絡(luò)可以包括萬維網(wǎng)或因特網(wǎng)，或者私有企業(yè)網(wǎng)絡(luò)，正如本領(lǐng)域中已知。盡管已經(jīng)將設(shè)備400描述為用于實現(xiàn)在此描述的技術(shù)的一種形式，但本領(lǐng)域普通技術(shù)人員將意識到可以采用其他的、功能性上等同的技術(shù)。例如，正如本領(lǐng)域中已知，經(jīng)由可執(zhí)行指令實現(xiàn)的某些或全部功能性還可以使用諸如專用集成電路(ASIC)、可編程邏輯陣列、狀態(tài)機等固件和/或硬件來實現(xiàn)。另外，設(shè)備400的其他實現(xiàn)可以包括比所圖示的更多或更少數(shù)量的組件。再一次，本領(lǐng)域普通技術(shù)人員將意識到，可以按照這種方式使用的大量變型。更進一步，雖然圖4中圖示出了單個設(shè)備400，但是應(yīng)當理解可以將這種處理設(shè)備的組合配置為聯(lián)合操作 (例如使用已知的聯(lián)網(wǎng)技術(shù))以實現(xiàn)本公開的教導(dǎo)。圖5是圖示出根據(jù)本公開對過程模式進行處理的流程圖。在一個實施方式中，圖5 中所圖示的操作由圖4中所圖示的設(shè)備400在實現(xiàn)圖1的系統(tǒng)100時執(zhí)行。由此，開始于框502，處理開始，其中例如由規(guī)則配置組件106接收第一過程模式和第二過程模式。如上所述，這可以通過使用合適的文本和/或圖形用戶接口來實現(xiàn)。用于這一目的的圖形用戶接口的代表性實施方式在圖6中進一步圖示出。在所圖示的示例中，圖形用戶接口 600包括配置窗口 602和控制面板窗口 604。配置窗口 602和控制面板窗口 604共同實現(xiàn)了用于捕獲過程模式的特定于域的語言(DSL)的前端。在一個實施方式中，圖形用戶接口 600可以使用對特定于域的語言的開發(fā)提供輔助的多個公知工具中的任何一種(諸如結(jié)合集成了 Eclipse的軟件開發(fā)環(huán)境(IDE)而使用的通用Eclipse建模系統(tǒng)(GEMS))來實現(xiàn)。正如本領(lǐng)域中已知，與例如通用編程語言相反，特定于域的語言是專用于特定域、表示技術(shù)和/或解決方案技術(shù)的編程或規(guī)范語言。這在圖6 中圖示出，其中在控制面板窗口 606內(nèi)提供特定于軟件開發(fā)過程的多個模板組件604。正如所示，每個模板組件604體現(xiàn)了典型地在軟件開發(fā)過程的域中找到的已知狀態(tài)(或者動作、 事件等)。例如，在軟件開發(fā)領(lǐng)域中已知，應(yīng)當發(fā)生的典型事件是開發(fā)人員編輯特定的代碼部分。因此，這一點的發(fā)生表示為由標記為“編輯代碼”的模板組件來表明的通用狀態(tài)。需要發(fā)生以便證明開發(fā)人員事實上已經(jīng)編輯了代碼的底層原始事件被限定為在“編輯代碼” 模板中闡明的條件(例如通過主題專家指示)。使用這一已知技術(shù)，可以限定典型的和/或所希望的狀態(tài)的進一步示例，以便確保所有所希望的軟件開發(fā)過程都可以充分地捕獲。在圖6中所圖示的示例中，每個模板組件由圖形式圖標和文本串的組合來表示， 盡管本領(lǐng)域普通技術(shù)人員將意識到這并非必要條件。在一個實施方式中，可以經(jīng)由結(jié)合圖形用戶接口而操作的用戶輸入設(shè)備接收選擇信息，該用戶輸入設(shè)備例如是鼠標和光標組合，從而用戶將光標定位在給定圖標上，并且點擊鼠標上的按鈕以選擇該圖標。再次參考圖 6中所圖示的實施方式，選擇信息可以進一步包括表明用戶已經(jīng)將所選擇的圖標拖曳并放下(再次使用例如光標/鼠標組合)到配置窗口 602中的信息?？梢灾貜?fù)這些過程，直到將所有所希望的狀態(tài)610都被放置在窗口 602中為止。此外，提供連接符模板608以指示各種狀態(tài)之間的流。如現(xiàn)有技術(shù)中已知，當定義狀態(tài)圖時，連接符611可以配置用于定義導(dǎo)致狀態(tài)機從一個狀態(tài)向另一狀態(tài)移動的條件?？傮w上，所希望的狀態(tài)610和此類狀態(tài)之間的連接符611定義過程模式的示例。如進一步示出，可以提供規(guī)則名稱域612，從而使得用戶可以提供用于規(guī)則的名稱，而提供規(guī)則描述域614以便捕獲由過程模式定義的規(guī)則的更詳細的文本描述。一旦過程 模式和所附的數(shù)據(jù)612、614已經(jīng)被完整地提供，用戶可以選擇保存按鈕616以便存儲所輸入的數(shù)據(jù)以供后續(xù)使用。如上所述，與使用圖形用戶接口 600來捕獲過程模式不同，為了這一目的，可以等同地采用文本用戶接口。正如本領(lǐng)域中已知，這種接口可以包括使得用戶能夠限定一組所希望的條件的必要提示(以例如下拉菜單和文本輸入域的形式)。例如，可以提供用于輸入限定“if-then”(如果-那么)條件的數(shù)據(jù)的提示。可以按照類似的方式限定其他條件。更進一步，可以提供提示來將各種所限定的條件鏈接在一起(例如，諸如“and(與)”、 “or (或)”、“not (非)”等邏輯運算符)，從而使得可以完整地限定所希望的狀態(tài)。例如，使用這一方法，可以捕獲規(guī)則如“項目要求所有開發(fā)人員在代碼簽入之前‘修復(fù)’ ‘優(yōu)先級1’ 問題”。本領(lǐng)域普通技術(shù)人員將容易地限定進一步的示例。更進一步，用于實現(xiàn)這種用來捕獲過程模式的文本接口的技術(shù)對于本領(lǐng)域普通技術(shù)人員來說是已知的。再一次參考圖5，如上所述，在框502處使用例如上述用戶接口機制中的任何一種來接收第一過程模式和第二過程模式。注意，第一過程模式和第二過程模式并非一定需要在相對于彼此的短暫時間內(nèi)接收；事實上，因為它們存儲在合適的存儲設(shè)備中，所以實際上在第一過程模式的接收與第二過程模式的接收之間可能經(jīng)過任何時間段。然而，在一個實施方式中，可能希望，在創(chuàng)建新的過程模式時，例如當用戶選擇保存按鈕616時，將新創(chuàng)建的過程模式與現(xiàn)有的過程模式相比較。無論如何，處理在框504處繼續(xù)，其中確定是否有機會合并第一過程模式和第二過程模式。在一個實施方式中，這是通過對限定每個過程模式的各種狀態(tài)進行比較來實現(xiàn)的。注意，在規(guī)則當前并不是如在上述過程模式的情況下那樣以狀態(tài)圖形式表示的情況下，可以使用公知技術(shù)將規(guī)則轉(zhuǎn)換為這種狀態(tài)圖形式。另外， 用于對曲線圖表示進行比較的技術(shù)在本領(lǐng)域中是公知的?？梢允褂弥T如JUNG(當前可在 http Il iunR/sourceforRe. net/獲得)之類的公知曲線圖分析庫來進行曲線圖比較。與此類似，可以通過使用諸如GQL4JUNG(當前可在http://code. ROORle. com/p/gql4iung/獲得)之類的工具，使用XPATH查詢語言來進行曲線圖查詢和比較。無論所使用的方法如何， 曲線圖比較都確立了兩個曲線圖之間的頂點和邊之間的共性度。由此，共性度越高，兩個曲線圖的這些區(qū)段相似的置信度越高。這一點的示例在圖7至圖9中圖示出。圖7圖示出了可以稱為“質(zhì)量檢查遵守”的第一過程模式。正如所示，質(zhì)量檢查遵守過程模式表示為如下狀態(tài)圖，其中初始狀態(tài)是“新代碼文件”或“簽出代碼”，前者針對創(chuàng)建新代碼文件的實例，而后者針對代碼倉庫中已經(jīng)存在代碼文件的實例。無論如何，圖7中圖示的其他狀態(tài)包括“代碼編輯”(其中開發(fā)人員對代碼文件進行編輯)、“編譯代碼”(對應(yīng)于編譯代碼文件中的代碼的動作)、“運行質(zhì)量工具”(對應(yīng)于所關(guān)注的代碼文件上正在執(zhí)行的代碼質(zhì)量工具)以及“簽入代碼”(其中將代碼文件簽入到代碼倉庫中)。正如進一步示出的那樣，可以限定每個狀態(tài)之間的多個狀態(tài)轉(zhuǎn)移。每個狀態(tài)可以包括用于限定該狀態(tài)的給定實例的各種各樣的信息，該狀態(tài)諸如任何輸入狀態(tài)(導(dǎo)致這一狀態(tài)的狀態(tài))和/或輸出狀態(tài)(后接這一狀態(tài)的狀態(tài))；標識哪一部分代碼與該狀態(tài)的這一實例相關(guān)的實體信息；進入時間；退出時間；在完成狀態(tài)后提供可識別的結(jié)果的那些情況下的狀態(tài)結(jié)果；以及表明對于給定的一組原始事件數(shù)據(jù)，這一狀態(tài)被遍歷的次數(shù)的訪問計數(shù)。類似地，每次轉(zhuǎn)移可以包括各種信息，諸如輸入狀態(tài)(轉(zhuǎn)移從中源發(fā)的狀態(tài))和輸出狀態(tài)(轉(zhuǎn)移在其中終止的狀態(tài))；在狀態(tài)結(jié)果可用的那些實例中的最后的狀態(tài)結(jié)果；表明轉(zhuǎn)移何時發(fā)生的發(fā)起時間；以及表明對于給定的一組原始數(shù)據(jù)，發(fā)生了多少次轉(zhuǎn)移的訪問計數(shù)。正如所示，多個轉(zhuǎn)移包括對對應(yīng)于該轉(zhuǎn)移的發(fā)生的狀態(tài)結(jié)果的指示。例如，在“編譯代碼”狀態(tài)的情況下，“失敗”狀態(tài)結(jié)果對應(yīng)于轉(zhuǎn)移回“代碼編輯”狀態(tài)，而“通過”狀態(tài)結(jié)果對應(yīng)于轉(zhuǎn)移回“代碼編輯”狀態(tài)或轉(zhuǎn)移到“運行質(zhì)量工具”狀態(tài)。另外，圖示為虛線的各種有害轉(zhuǎn)移被示出為有時根據(jù)事件數(shù)據(jù)而發(fā)生但不應(yīng)當發(fā)生的轉(zhuǎn)移的示例。例如，根據(jù)所限定的過程，“運行質(zhì)量工具”狀態(tài)中的“失敗”結(jié)果應(yīng)當導(dǎo)致轉(zhuǎn)移到“代碼編輯”狀態(tài)。然而，以某個頻率發(fā)生的有害轉(zhuǎn)移是從“運行質(zhì)量工具”狀態(tài)轉(zhuǎn)移到“簽入代碼”狀態(tài)，而不論 “失敗”結(jié)果是否發(fā)生。以類似的風(fēng)格，圖8圖示出了可以稱為“TDD遵守”的過程模式。TDD(或測試驅(qū)動設(shè)計)是基于測試和代碼編輯的相對快速的迭代的軟件開發(fā)的方法。無論如何，在所示的示例中，TDD遵守過程模式包括多個實際上相同的狀態(tài)，正如在圖7和圖8中用具有加粗輪廓的橢圓來突出顯示的那樣，即“新代碼文件”、“代碼編輯”、“編譯代碼”、“簽入代碼”和“ 結(jié)束”狀態(tài)。然而，與質(zhì)量檢查遵守過程模式不同，唯一的開始狀態(tài)是不同的狀態(tài)，稱為“新單元測試文件”(對應(yīng)于開發(fā)人員創(chuàng)建單元測試文件)，隨后是“單元測試編輯”(其中開發(fā)人員對單元測試文件進行各種改變)。另外，圖7中所圖示的“運行質(zhì)量工具”狀態(tài)基本上被圖8中所示的“運行單元測試”狀態(tài)所替換。如同之前，圖8中所圖示的新狀態(tài)包括狀態(tài)之間的各種轉(zhuǎn)移，包括若干經(jīng)常發(fā)生的有害轉(zhuǎn)移的示例。使用本領(lǐng)域普通技術(shù)人員已知的曲線圖比較技術(shù)，識別兩個曲線圖之間的類似狀態(tài)，即“新代碼文件”、“代碼編輯”、“編譯代碼”、“簽入代碼”和“結(jié)束”狀態(tài)。一般地，當多個曲線圖具有共同的起點和終點，并且中間狀態(tài)可以通過單獨曲線圖中所限定的普通狀態(tài)轉(zhuǎn)移來達到時，可以合并曲線圖。進一步，如果存在任何停滯狀態(tài)或不可達到的狀態(tài)，則不能合并曲線圖。由此，在本示例中，基于這一狀態(tài)共性，可以如圖9中進一步圖示的那樣合并兩個過程模式。正如所示，合并后的過程模式包括共同狀態(tài)以及第一過程模式和第二過程模式中的每一個所特有的附加狀態(tài)兩者。注意，為易于說明，圖9中所圖示的合并后的過程模式不包括圖7和圖8中所示的任何有害轉(zhuǎn)移示例。當然，仍然應(yīng)當理解，在如下程度上圖9中所圖示的那些轉(zhuǎn)移之外的轉(zhuǎn)移可以構(gòu)成有害轉(zhuǎn)移，即它們不符合合并后的過程模式。再次參考圖5，如果沒有找到過程模式之間的合并機會，則處理在框510處繼續(xù)， 其中將相應(yīng)的過程模式轉(zhuǎn)換為可執(zhí)行過程驗證規(guī)則，如果先前沒有完成的話。例如，在GEMS 的上下文中，如上所述，可以獲得插件程序來將過程模式轉(zhuǎn)換為可執(zhí)行代碼。如果不是已經(jīng)存儲，則隨后存儲所得到的可執(zhí)行過程驗證規(guī)則，正如在框512處所表明的那樣。然而，如果在框504處找到了合并機會，則在框506處繼續(xù)處理，其中如例如圖9中所示合并第一過程模式和第二過程模式。此后，處理可以可選地在框508處繼續(xù)，其中將合并后的過程模式提供給用戶，以便獲得對合并后的過程模式的反饋(如果有的話)。在一個實施方式中，用戶可以是主題專家，其具有關(guān)于針對給定軟件開發(fā)項目的所希望的軟件開發(fā)過程的特定知識。本領(lǐng)域普通技術(shù)人員將意識到，可以合并過程模式的事實并非在全部情形下都是所希望的，或者可能僅在以某種方式修改了合并后的過程模式之后才是所希望的。例如，可以經(jīng)由圖中6所圖示類型的圖形用戶接口將圖9中所圖示的合并后的過程模式呈遞給用戶，從而允許用戶同意它而不需要進一步的編輯，編輯它然后表明同意，或者拒絕合并后的過程模式。假定用戶同意合并后的過程模式(需要或不需要進一步編輯)，則處理僅基于合并后的過程模式在框510、512處繼續(xù)，如上所述?，F(xiàn)在參考圖10，其示出了圖示出用于監(jiān)控開發(fā)人員對軟件代碼開發(fā)過程的遵守的方法的流程圖。在一個實施方式中，由圖1中所圖示的系統(tǒng)100至少部分地執(zhí)行針對圖10 而描述的處理。另外，圖10中所圖示的處理可以在一個或多個處理設(shè)備(諸如以上針對圖 4所描述的)的輔助下執(zhí)行。無論如何，處理在框1002處開始，在此配置系統(tǒng)100。在一個實施方式中，這種配置包括執(zhí)行建立一個或多個傳感器以與各種開發(fā)工具120 —起工作， 以及如上所述地為該系統(tǒng)配置一個或多個規(guī)則。前者的示例在圖11中圖示出，該圖提供了圖形用戶接口 1102。接口 1102可以通過例如規(guī)則配置組件106來實現(xiàn)。正如所示，接口 1102包括配置傳感器按鈕1104、規(guī)則管理器按鈕1106和報告按鈕1108。選擇配置傳感器按鈕1104引起將用戶接口 1102顯示為使得用戶可以配置先前部署的傳感器。例如，正如所示，每個傳感器可以包括所圖示的表中的一行(例如通過其相應(yīng)的描述來區(qū)分)，從而用戶能夠操縱復(fù)選框以啟用(選擇)或禁用(取消選擇)給定傳感器。另外，提供列，從而可以指定針對每個傳感器的間隔，這種間隔將被用于確定給定傳感器應(yīng)當提供其原始事件數(shù)據(jù)的頻率(或被檢查以獲得這種原始事件數(shù)據(jù))。正如進一步所示，在給定傳感器是經(jīng)由例如web服務(wù)或其他遠程服務(wù)來實現(xiàn)的情況下，可以提供到給定服務(wù)的路徑名稱。備選地，在傳感器被簡單地嵌入給定工具、應(yīng)用等的情況下，該傳感器可以簡單地根據(jù)所選擇的頻率來推送原始事件數(shù)據(jù)。提供概要視圖窗口 1110，從而可以顯示當前已啟用和配置的傳感器和/或規(guī)則的數(shù)量。一旦已經(jīng)選擇和配置了所希望的傳感器，用戶就可以選擇保存?zhèn)鞲衅髋渲冒粹o1112 來保存輸入傳感器配置數(shù)據(jù)。正如本領(lǐng)域普通技術(shù)人員已知的那樣，隨后使用所保存的傳感器配置數(shù)據(jù)以確保正確的傳感器正在根據(jù)需要而運行。 針對圖12進一步圖示出了以上針對框1002而描述的后一類型的配置的另一示例。特別地，選擇規(guī)則管理器按鈕1106可能引起提供圖形用戶接口 1202。注意，假定使用圖11的傳感器配置數(shù)據(jù)，概要視圖窗口 1110反映了在此時已經(jīng)配置了四個不同的傳感器的事實。以類似于傳感器配置接口 1102所采用的方式，規(guī)則管理器接口 1202可以針對每個可用的規(guī)則提供分開的行。再一次，在所圖示的示例中，各種規(guī)則通過其相應(yīng)的文本描述來區(qū)分。當然，為了這一目的，可以等同地采用某些其他的識別標記，諸如其相應(yīng)的標題。 無論如何，可以提供復(fù)選框，從而用戶能夠啟用或禁用給定規(guī)則。如果已經(jīng)啟用了所有所希望的規(guī)則，則用戶可以選擇保存規(guī)則配置按鈕1206，由此引起保存所輸入的規(guī)則配置數(shù)據(jù)。 備選地或附加地，可以選擇添加定制規(guī)則按鈕1208，從而用戶能夠使用例如上述圖形用戶接口 600來限定新規(guī)則。在已經(jīng)以這種方式限定了新規(guī)則的情況下，用戶隨后可以如上所述地啟用該規(guī)則。再一次參考圖10，在已經(jīng)如需要配置了系統(tǒng)之后，處理可以在框1004處繼續(xù)，其中根據(jù)配置信息來收集上述開發(fā)過程事件信息。在框1006處繼續(xù)，可以將以這種方式收集的開發(fā)過程事件信息與先前在框1002處啟用的各種可執(zhí)行過程驗證規(guī)則相比較。然后，在框1008處確定在框1008處是否有任何可執(zhí)行過程驗證規(guī)則尚未得到滿足，即是否已經(jīng)違反了任何規(guī)則。如果為否，則處理在框1004處繼續(xù)，其中重復(fù)搜集開發(fā)過程事件數(shù)據(jù)和將其與已啟用的規(guī)則相比較的過程。注意，關(guān)于是否已經(jīng)違反了規(guī)則的確定可以由限定該規(guī)則的意義來規(guī)定。例如，肯定規(guī)則可以表明要鼓勵的行為，即該規(guī)則僅在開發(fā)過程事件數(shù)據(jù)表明過程以某種方式偏離時才被違反。備選地，否定規(guī)則可以表明要避免的行為，即該規(guī)則僅在開發(fā)過程事件數(shù)據(jù)表明事實上執(zhí)行了不希望的過程時才被違反。本領(lǐng)域普通技術(shù)人員將認識到，用于限定規(guī)則的各種意義(肯定或否定)可能具有伴隨的優(yōu)點和缺點。例如，在多個事件中的任何一個可能導(dǎo)致不期望的偏離的情況下，肯定規(guī)則可能更有用。相反，在不期望的過程被開發(fā)人員頻繁采用的那些實例中，否定規(guī)則可能有用。無論如何，如果確定已經(jīng)違反了至少一個規(guī)則，則處理在框1010處繼續(xù)，其中如上所述地生成故障指示，并將其存儲在合適的存儲組件中。最后，在框1012處，可以可選地生成報告并將其呈遞給發(fā)出請求的用戶。針對圖13進一步圖示出可以用于這一目的的圖形用戶接口 1302的示例。在一個實施方式中，圖形用戶接口 1302可以由報告組件112提供。特別地，當用戶選擇報告按鈕1108時，可以采用接口 1302。正如所示，該接口可以包括用于選擇要生成的報告的類型的機制；在所圖示的示例中，為了這一目的，采用了下拉菜單。本領(lǐng)域普通技術(shù)人員將意識到，除下拉菜單之外的機制可以用于這一目的。無論用于選擇報告的機制如何，都可以基于使在此處描述的過程遵守系統(tǒng)而獲得的數(shù)據(jù)來生成報告 1306。在所圖示的示例中，提供針對每個規(guī)則的過程違反數(shù)量。使用公知技術(shù)，可以將報告 1306提供給任何所希望的信道(例如用于硬副本輸出的打印機、用于生成和存儲電子文件的合適應(yīng)用、電子郵件、RSS饋送等)。如上所述，本公開描述了用于改善對用于 過程遵守監(jiān)控系統(tǒng)中的各種規(guī)則的管理的各種方法和裝置。這一般地通過如下方式來實現(xiàn)，即在可能的情況下合并過程模式并且使用所得到的合并后的過程模式來生成可執(zhí)行過程驗證規(guī)則。然后，可以在過程遵守監(jiān)控系統(tǒng)中采用這種規(guī)則，以確定對由可執(zhí)行過程驗證規(guī)則代表的一個或多個過程的遵守程度。通過以這種方式合并規(guī)則，可以減少規(guī)則數(shù)量，從而消除了在將規(guī)則與開發(fā)過程事件數(shù)據(jù)相比較時的冗余處理。另外，可以按照這種方式減少規(guī)則的數(shù)量，從而簡化對系統(tǒng)的管理。至少由于這些原因，上述技術(shù)代表了優(yōu)于現(xiàn)有技術(shù)教導(dǎo)的進步。盡管已經(jīng)示出和描述了特定的優(yōu)選實施方式，但本領(lǐng)域普通技術(shù)人員將意識到， 在不脫離本教導(dǎo)的情況下，可以進行改變和修改。因此，可以想到，上述教導(dǎo)的任何和所有修改、變型或等同形式都落入上述基本底層原理和在所要求保護的范圍內(nèi)。
權(quán)利要求
1.一種用于開發(fā)用于監(jiān)控開發(fā)人員對軟件代碼開發(fā)過程的遵守的規(guī)則的方法，包括 由通過處理設(shè)備實現(xiàn)的規(guī)則配置組件接收描述所述軟件代碼開發(fā)過程的至少一部分的第一過程模式；由所述規(guī)則配置組件接收描述所述軟件代碼開發(fā)過程的至少另一部分的第二過程模式；由所述規(guī)則配置組件合并所述第一過程模式和所述第二過程模式以提供合并后的過程模式；以及由所述規(guī)則配置組件將所述合并后的過程模式轉(zhuǎn)換為可執(zhí)行過程驗證規(guī)則。
2.根據(jù)權(quán)利要求1所述的方法，其中合并所述第一過程模式和所述第二過程模式進一步包括分別將所述第一過程模式和所述第二過程模式轉(zhuǎn)換為第一曲線圖和第二曲線圖； 確定所述第一曲線圖與所述第二曲線圖之間的交點；基于所述第一曲線圖與所述第二曲線圖之間的所述交點來生成合并后的曲線圖；以及將所述合并后的曲線圖轉(zhuǎn)換為所述合并后的過程模式。
3.根據(jù)權(quán)利要求1所述的方法，其中接收所述第一過程模式和所述第二過程模式進一步包括經(jīng)由實現(xiàn)特定于域的語言的圖形用戶接口和文本用戶接口中的至少一個，接收所述第一過程模式和所述第二過程模式。
4.根據(jù)權(quán)利要求1所述的方法，進一步包括由通過所述處理設(shè)備實現(xiàn)的事件收集組件收集由所述開發(fā)人員生成的開發(fā)過程事件 fn息；由通過所述處理設(shè)備實現(xiàn)并且操作性地連接到所述事件收集組件和所述規(guī)則配置組件的規(guī)則執(zhí)行組件，將所述開發(fā)過程事件信息與所述可執(zhí)行驗證規(guī)則相比較；以及當所述過程事件信息不符合所述可執(zhí)行過程驗證規(guī)則的至少一個條件時，由所述規(guī)則執(zhí)行組件生成故障指示。
5.根據(jù)權(quán)利要求4所述的方法，其中收集所述開發(fā)過程事件信息進一步包括 由所述事件收集組件從由所述開發(fā)人員使用的至少一個開發(fā)工具收集原始開發(fā)過程事件數(shù)據(jù)；以及由所述事件收集組件根據(jù)過濾規(guī)則對所述原始開發(fā)過程事件數(shù)據(jù)進行過濾以提供所述開發(fā)過程事件信息。
6.根據(jù)權(quán)利要求4所述的方法，進一步包括由所述規(guī)則執(zhí)行組件將所述故障指示存儲在結(jié)果存儲設(shè)備中； 由通過所述處理設(shè)備實現(xiàn)并且操作性地連接到所述結(jié)果存儲設(shè)備的報告組件基于所述故障指示生成報告；以及由所述報告組件將所述報告呈遞給用戶。
7.一種用于開發(fā)用于監(jiān)控開發(fā)人員對軟件代碼開發(fā)過程的遵守的規(guī)則的裝置，包括 處理器；處理器可讀介質(zhì)，其上存儲有指令，所述指令在由所述處理器執(zhí)行時使得所述處理器接收描述所述軟件代碼開發(fā)過程的至少一部分的第一過程模式；接收描述所述軟件代碼開發(fā)過程的至少另一部分的第二過程模式； 合并所述第一過程模式和所述第二過程模式以提供合并后的過程模式；以及將所述合并后的過程模式轉(zhuǎn)換為可執(zhí)行過程驗證規(guī)則。
8.根據(jù)權(quán)利要求7所述的設(shè)備，其中使得所述處理器合并所述第一過程模式和所述第二過程模式的那些指令進一步操作為使得所述處理器分別將所述第一過程模式和所述第二過程模式轉(zhuǎn)換為第一曲線圖和第二曲線圖； 確定所述第一曲線圖與所述第二曲線圖之間的交點；基于所述第一曲線圖與所述第二曲線圖之間的所述交點來生成合并后的曲線圖；以及將所述合并后的曲線圖轉(zhuǎn)換為所述合并后的過程模式。
9.根據(jù)權(quán)利要求7所述的設(shè)備，其中使得所述處理器接收所述第一過程模式和所述第二過程模式的那些指令進一步操作為使得所述處理器經(jīng)由實現(xiàn)特定于域的語言的圖形用戶接口和文本用戶接口中的至少一個，接收所述第一過程模式和所述第二過程模式。
10.根據(jù)權(quán)利要求7所述的設(shè)備，所述處理器可讀介質(zhì)進一步包括指令，該指令在由所述處理器執(zhí)行時使得所述處理器收集由所述開發(fā)人員生成的開發(fā)過程事件信息；將所述開發(fā)過程事件信息與所述可執(zhí)行驗證規(guī)則相比較；以及當所述過程事件信息不符合所述可執(zhí)行過程驗證規(guī)則的至少一個條件時，生成故障指示。
11.根據(jù)權(quán)利要求10所述的設(shè)備，其中使得所述處理器收集所述開發(fā)過程事件信息的那些指令進一步操作為使得所述處理器從由所述開發(fā)人員使用的至少一個開發(fā)工具收集原始開發(fā)過程事件數(shù)據(jù)；以及根據(jù)過濾規(guī)則對所述原始開發(fā)過程事件數(shù)據(jù)進行過濾以提供所述開發(fā)過程事件信息。
12.根據(jù)權(quán)利要求10所述的設(shè)備，所述處理器可讀介質(zhì)進一步包括指令，所述指令在由所述處理器執(zhí)行時使得所述處理器將所述故障指示存儲在結(jié)果存儲設(shè)備中； 基于所述故障指示生成報告；以及將所述報告呈遞給用戶。
13.一種用于開發(fā)用于監(jiān)控開發(fā)人員對軟件代碼開發(fā)過程的遵守的規(guī)則的裝置，包括用尸接口 ；以及操作性地連接到所述用戶接口的規(guī)則配置組件，操作為接收描述所述軟件代碼開發(fā)過程的至少一部分的第一過程模式，接收描述所述軟件代碼開發(fā)過程的至少另一部分的第二過程模式，合并所述第一過程模式和所述第二過程模式以提供合并后的過程模式，以及將所述合并后的過程模式轉(zhuǎn)換為可執(zhí)行過程驗證規(guī)則。
14.根據(jù)權(quán)利要求13所述的裝置，其中所述用戶接口包括各自實現(xiàn)特定于域的語言的圖形用戶接口和文本用戶接口中的至少一個。
15.根據(jù)權(quán)利要求13所述的裝置，其中當合并所述第一過程模式和所述第二過程模式時，所述規(guī)則配置組件進一步操作為分別將所述第一過程模式和所述第二過程模式轉(zhuǎn)換為第一曲線圖和第二曲線圖；確定所述第一曲線圖與所述第二曲線圖之間的交點；基于所述第一曲線圖與所述第二曲線圖之間的所述交點來生成合并后的曲線圖；以及將所述合并后的曲線圖轉(zhuǎn)換為所述合并后的過程模式。
16.根據(jù)權(quán)利要求13所述的裝置，進一步包括事件收集組件，操作為收集由所述開發(fā)人員使用至少一個開發(fā)工具生成的開發(fā)過程事件信息；規(guī)則執(zhí)行組件，操作性地連接到所述事件收集組件和所述規(guī)則配置組件，操作為將所述開發(fā)過程事件信息與可執(zhí)行驗證規(guī)則代表相比較，以及當所述過程事件信息不符合所述可執(zhí)行過程驗證規(guī)則的至少一個條件時，生成故障指示。
17.根據(jù)權(quán)利要求16所述的裝置，其中所述事件收集組件進一步包括數(shù)據(jù)收集組件，操作性地連接到所述至少一個開發(fā)工具，操作為從所述至少一個開發(fā)工具收集原始開發(fā)過程事件數(shù)據(jù)；以及查詢處理組件，操作性地連接到所述數(shù)據(jù)收集組件，操作為根據(jù)過濾規(guī)則對所述原始開發(fā)過程事件數(shù)據(jù)進行過濾以提供所述開發(fā)過程事件信息。
18.根據(jù)權(quán)利要求16所述的裝置，進一步包括 報告組件；以及結(jié)果存儲設(shè)備，連接到所述報告組件和所述規(guī)則執(zhí)行組件，其中所述規(guī)則執(zhí)行組件進一步操作為將所述故障指示存儲在所述結(jié)果存儲設(shè)備中；并且其中所述報告組件進一步操作為基于所述故障指示生成報告以及將所述報告呈遞給用戶。
19.實質(zhì)上如參考附圖而描述和圖示出的裝置和方法。
全文摘要
本公開涉及在用于監(jiān)控開發(fā)人員對軟件代碼開發(fā)過程的遵守的系統(tǒng)中的規(guī)則合并。在系統(tǒng)中，接收第一過程模式和第二過程模式并將其合并以提供合并后的過程模式。每個過程模式按照狀態(tài)圖表示來表達，涵蓋了所希望的軟件代碼開發(fā)過程的至少一部分。可選地，將合并后的過程模式呈遞給主題專家以獲得對其的反饋。然后，將合并后的過程模式轉(zhuǎn)換為可執(zhí)行過程驗證規(guī)則，用于在監(jiān)控過程遵守中使用。在一個實施方式中，將開發(fā)過程事件數(shù)據(jù)與可執(zhí)行過程驗證規(guī)則相比較。違背規(guī)則會導(dǎo)致生成故障指示，根據(jù)需要存儲該故障指示并且隨后進行報告。以這種方式，當確定開發(fā)人員對一個或多個軟件代碼開發(fā)過程的遵循程度時，可以提高自動化過程遵守監(jiān)控系統(tǒng)的效率。
文檔編號G06F9/44GK102253829SQ20111013590
公開日2011年11月23日 申請日期2011年5月20日 優(yōu)先權(quán)日2010年5月20日
發(fā)明者V·S·沙爾馬, V·S·考爾古德 申請人:埃森哲環(huán)球服務(wù)有限公司