 |
智力資本和資產(chǎn)作為方法內容和指導進(jìn)行管理
讓我們考慮一下建立方法內容的三個(gè)主要方面和關(guān)系--角色，任務(wù)，工作產(chǎn)品。
在軟件工程文獻中最普遍引用的就是“軟件的發(fā)展是一項團隊運動(dòng)，”17 指出開(kāi)發(fā)者創(chuàng )造了軟件，他們以合作和彼此交流工作成果來(lái)不斷發(fā)展。在某種意義上，RMC 應用了非常普通，甚至標準的方法來(lái)定義開(kāi)發(fā)的方法，18 正如 圖 10 描述的, 通過(guò)定義開(kāi)發(fā)角色，表示一組相關(guān)技能集合，資格和開(kāi)發(fā)團隊的責任。這些角色匹配于某種類(lèi)型的工作產(chǎn)品：例如，開(kāi)發(fā)者對源碼負責，或者系統分析師對用例規范負責。為了創(chuàng )建和修改工作產(chǎn)品，角色被分配來(lái)執行某種具有輸入輸出的工作產(chǎn)品類(lèi)型的任務(wù)。
圖 10: 角色，任務(wù)，工作產(chǎn)品的核心方法內容概念的簡(jiǎn)化概念模型。
有經(jīng)驗的 Rational Unified Process ?， 或 RUP?， 使用者將意識到我們在之前的RUP版本中用 "活動(dòng)（activity）" 來(lái)代替"任務(wù)（task）"。 我們改變了在在內容方法下的一些術(shù)語(yǔ)，正如我在第一部分中所描述的Unified Method Architecture (UMA) 和 SPEM 2.0 部分，來(lái)更好的反映這些術(shù)語(yǔ)的工業(yè)用法，提供更加緊密的過(guò)程制定和項目管理方法的連接。
并對比之前版本的RUP，RMC的一個(gè)新功能就是你可以設置一個(gè)多角色的任務(wù)。這強調了軟件工程的協(xié)作屬性，因為多任務(wù)需要不同技能，不同背景的人們共同完成。例如，一個(gè)叫作“劃分需求優(yōu)先級”的任務(wù)需要來(lái)自不同角色的技能和專(zhuān)業(yè)知識。你需要系統分析師的技能去表達最終用戶(hù)的需求和優(yōu)先權。你需要架構師的技能去為項目經(jīng)理評估可行性和成本，并由此確定成本/收益比率。你還需要項目經(jīng)理的技能來(lái)評估有多少開(kāi)發(fā)資源和技能能夠被獲得，以對不同迭代進(jìn)行資源分配和需求實(shí)現的優(yōu)先級劃分。所以，劃分需求優(yōu)先級就需要具有不同能力的人之間的協(xié)作。在之前版本的RUP建模方法中，我們被迫分配一個(gè)任務(wù)到三種角色中的一個(gè)或者創(chuàng )建一個(gè)新角色來(lái)滿(mǎn)足這些技術(shù)，由此導致了大量的特定角色。在 RMC中，你可以分配你需要的所有角色給任務(wù)，并且清晰的定義執行工作所需的技能。實(shí)際上，當在一個(gè)項目中執行某個(gè)工作時(shí)，項目經(jīng)理仍然可以決定是否一人一個(gè)角色或者一人同時(shí)執行多個(gè)角色。
RUP用戶(hù)將注意到的另外一個(gè)改變就是工作產(chǎn)品的概念替代了 工件。 RUP仍然定義了工件，但是工作產(chǎn)品在RMC中已作為一般化的概念，它支持多于兩種工作產(chǎn)品類(lèi)型：可交付物和成果?？山桓段锉挥脕?lái)打包其他工作產(chǎn)品，交付到內部或外部團體。他們定義了以典型的或推薦的工作產(chǎn)品選擇和某種可交付的文檔形式的內容。成果是一種無(wú)形的工作產(chǎn)品，它們是一種結果或狀態(tài)，如一臺已安裝的服務(wù)器或優(yōu)化的網(wǎng)絡(luò )。成果和工件最重要的區別是成果不是作為可重用資產(chǎn)的候選者。
在 第一部分 中，我解釋了方法內容，它是一種展示軟件工程文獻中的基本開(kāi)發(fā)方法和技術(shù)成果的方式，在RMC中它是通過(guò)角色，任務(wù)，工作產(chǎn)品的概念來(lái)表達的。例如， Rational Unified Process 覆蓋了那些重要的開(kāi)發(fā)規程中使用的所有開(kāi)發(fā)方法。 例如：
用例分析。 許多書(shū)19描述了一個(gè)設計師如何從用例規范系統的創(chuàng )建面向對象分析模型。
開(kāi)發(fā)并確定遠景范圍。另外一些作者20 已定義了一種方法來(lái)映射和交流涉眾問(wèn)題到業(yè)務(wù)需要再到項目的系統特性（需求）。
測試。 Cem Caner 等人已定義和發(fā)布了多種方法21來(lái)系統地進(jìn)行測試計劃，確定和設計測試方法，并進(jìn)行系統回歸測試。
類(lèi)似的方法已由RUP內容團隊從方法的來(lái)源映射到了一個(gè)或者多個(gè)任務(wù)上。如圖 11展示的，每個(gè)任務(wù)由一連串相關(guān)執行角色和輸入/輸出工作產(chǎn)品和提供了額外的背景信息和細節的指導組成。
圖11：執行用例分析的方法在RMC中被作為一個(gè)任務(wù)。此例子展示了一個(gè)任務(wù)如何被轉換成HTML并且顯示給RMC用戶(hù)。在折疊部分提供了詳細的步驟說(shuō)明。所有的藍色正文是相關(guān)方法內容元素的超鏈接。
點(diǎn)擊放大
例如， 圖 11 描述的是用例分析方法作為一個(gè)角色設計者所執行的任務(wù)是在 RUP中是如何表示的。這個(gè)任務(wù)把工作產(chǎn)品用例作為強制性的輸入。它也包括了可選擇輸入的一些其他工作產(chǎn)品，像用例實(shí)現，分析類(lèi)，術(shù)語(yǔ)表等等。作為工作產(chǎn)品的輸出，任務(wù)定義了一個(gè)用例實(shí)現和分析模型組成的一個(gè)分析類(lèi)。任務(wù)與不同的指導元素相連接，比如檢查列表；特定技術(shù)（如執行用例分析）的指導方針；涉及諸如用例實(shí)現，分析類(lèi)等的工作產(chǎn)品的細節的指導。最終，工具指導會(huì )描述如何使用諸如IBM Rational Rose, XDE, 或 Software Architect工具執行用例分析。
任務(wù)本身是一步步構成的，雖然這些步驟在執行中并不是按照嚴格的順序。實(shí)際上，其中的一部分也許只在某種特別情況下才被執行，而且并不是對每一個(gè)用例都適用。例如，步驟"Reconcile the Analysis Use-Case Realizations"要求你已經(jīng)至少執行了一次這個(gè)任務(wù)，才可以協(xié)調各個(gè)用例的實(shí)現。因此，步驟描述了任務(wù)執行者可選擇的任務(wù)中的工作單位。正如你將在"使用 RMC 管理過(guò)程"部分看到的，實(shí)際上過(guò)程定義了某個(gè)時(shí)刻應該被執行的步驟。任務(wù)的步驟確定了執行過(guò)程中的各種不同的用例分析的方法，描述了為了實(shí)現任務(wù)的目標經(jīng)過(guò)一個(gè)生命周期的所有工作。過(guò)程中方法元素的應用，提供了一種環(huán)境允許你決定方法的哪些部分實(shí)際上在生命周期的什么點(diǎn)上執行。
在RMC中定義和使用任務(wù)與軟件工程中的定義有很多共同點(diǎn)。作為一個(gè)用例，一項任務(wù)應該具有清晰的目的，他可以讓執行角色達到預先期望的目標。任務(wù)中的一個(gè)單獨步驟（例如上例中的 "Create Analysis Use-Case Realization"），不能獨立地提供價(jià)值。這個(gè)用例實(shí)現概念僅僅展示了在分析中的各項分析成分。所以，這是一種實(shí)現圖11的分析任務(wù)的途徑。
以清晰的目的定義任務(wù)對于確定和管理任務(wù)提供了相似的優(yōu)勢。涉眾（例如過(guò)程執行者或開(kāi)發(fā)者）與任務(wù)能夠更加容易的聯(lián)系起來(lái)，因為他們可以以更加全局的角度審視：為什么他們要做這項工作。定義和設置太多的低級工作單位不利于管理和交流。而且如果他們實(shí)現了對于發(fā)展目標的間隔劃分，對于任務(wù)的交流和指導將變得更加簡(jiǎn)單。最終，執行一項任務(wù)的時(shí)間從小時(shí)到天。因此，過(guò)程評估不能靠計算任務(wù)數；它需要通過(guò)考慮各個(gè)單獨任務(wù)來(lái)完成。（但是，建議你確定過(guò)程中發(fā)生的任務(wù)的估計，這些已在上文中提供了詳細描述）
一個(gè)任務(wù)粒度的另一個(gè)規則是它一般只作用于一個(gè)或一小部分工作產(chǎn)品。換句話(huà)說(shuō)，一項任務(wù)不應有太多的工作產(chǎn)品輸出類(lèi)型。在這種情況下，你也許會(huì )過(guò)細的定義一些本應合起來(lái)實(shí)現某個(gè)特殊功能的工作產(chǎn)品。也可以這么說(shuō)，你的執行多個(gè)開(kāi)發(fā)方法工作的任務(wù)應當被重新構成為多個(gè)分離的任務(wù)，以增加任務(wù)的可重用性，并關(guān)注于特定的目標。
對于用例，目的就是提供要達到任務(wù)目標所需的完整定義。這包括了二選一和任意選擇的步驟。在這種意義上，對于用例的任務(wù)步驟表能確定過(guò)程中來(lái)源于不同"scenarios"的組合。設置對于任務(wù)的輸入和輸出工作產(chǎn)品關(guān)系在圖 12中顯示說(shuō)明。為了完成用例類(lèi)推，請注意任務(wù)中的執行角色不應和用例角色相互映射，因為角色是外部用戶(hù)。角色象征了執行實(shí)際工作的開(kāi)發(fā)者。所以，角色與在分析中的用例實(shí)現的控制組件或在商業(yè)中的用例實(shí)現的商人有相似之處。
圖 12: 在RMC任務(wù)編輯中使用加號和減號按鍵設置輸入輸出工作產(chǎn)品關(guān)系
點(diǎn)擊放大。
指導成分允許你增加額外信息使你的方法內容更加全面，且允許你加入更詳細的描述，正像在 圖 13 中的一樣。RMC中支持的具體指導種類(lèi)包括白皮書(shū)，目錄，模版或術(shù)語(yǔ)定義。下面的第一張表完整的列出了所支持的指導種類(lèi)。
圖 13: 在RMC中指導與某個(gè)基于表格的編輯是同樣合法的。這個(gè)圖表展示了指導類(lèi)型的編輯?；旧纤俗杂啥温淇臻g，允許像文檔一樣編輯白皮書(shū)。其他指導類(lèi)型提供了更多特定編輯器；如，check item 編輯器被用來(lái)編輯檢查表。
點(diǎn)擊放大.
RMC支持你像圖 13一樣以自由的方式進(jìn)行比如指導元素的創(chuàng )建。然后你能通過(guò)簡(jiǎn)單的對話(huà)框在文檔中創(chuàng )建鏈接，把指導與角色，任務(wù)或工作產(chǎn)品聯(lián)系起來(lái)（例如，在步驟描述中，一個(gè)工作產(chǎn)品定義或另一個(gè)指導成元素的文字）或在獨立參考部分中（如圖 11的"More Information"段）。
| 檢查單 | 確認需要完成或鑒別的條目。目錄經(jīng)常在預排或檢查時(shí)使用。 |
| 概念 | 要點(diǎn)主要方法與基本的相關(guān)原則有關(guān)。概念比指導方針涉及更多的一般要點(diǎn)，并且跨越工作產(chǎn)品和任務(wù)或活動(dòng)。 |
| 例子 | 提供一個(gè)完整工作產(chǎn)品或執行任務(wù)和活動(dòng)的例子。 |
| 指南 | 提供了如何執行某個(gè)特殊任務(wù)或組織任務(wù)的額外細節，或提供對工作產(chǎn)品和屬性的額外細節，規則和推薦。 |
| 實(shí)踐 | 展示對工作產(chǎn)品或過(guò)程質(zhì)量有積極的影響的策略。實(shí)踐被垂直于方法和過(guò)程確定下來(lái)。他們能概述影響許多方法或某種過(guò)程的不同部分的方面。 |
| 報告 | 自動(dòng)產(chǎn)生的關(guān)于工作產(chǎn)品的內容提取的描述的模版。 |
| 可重用資產(chǎn) | 把已給的內容連接到一個(gè)已準備的解決方案。資產(chǎn)實(shí)例是設計模式或機制，框架的解決方案等。IBM Rational 的設計與工具支持資產(chǎn)打包與消費。 |
| 路線(xiàn)圖 | 復雜過(guò)程或活動(dòng)的線(xiàn)形預排。(這是特定過(guò)程指導） |
| 支持資料 | 其他類(lèi)型指導的全部，不是在別處所特定定義的。它可以與全部?jì)热莩煞窒嚓P(guān)聯(lián)。 |
| 模版 | 對于一個(gè)工作產(chǎn)品，提供一組預定義的內容，段落，包，頭，標準格式，和段落包的使用描述。 |
| 術(shù)語(yǔ)定義 | 定義術(shù)語(yǔ)且用來(lái)建立術(shù)語(yǔ)表。 |
| 工具指導 | 表示如何使用某種工具獨立或部分的完成工作。 |
| 白皮書(shū) | 與概念相似，但是可在外部回顧或發(fā)布且可在其他內容成分和指導中理解。 |
除了用指導來(lái)增補非正式的內容，你可以像圖 14一樣使用分類(lèi)來(lái)組織和索引你的陳述內容。RMC 對于它的方法內容成分（諸如規則類(lèi)任務(wù)，域類(lèi)工作產(chǎn)品，角色設置組等）預定義了一組標準類(lèi)。RMC 還允許你定義自己的類(lèi)來(lái)確定你自己的邏輯組和對于角色，任務(wù)，工作產(chǎn)品和指導的陳述結構。你在RMC公布的內容中看到的所有樹(shù)形結構都是基于這些分類(lèi)的。它們本身的分類(lèi)被認為是足夠的成分（是的，有仍然可以按照它們自己分類(lèi)），因為他們仍然可以包含豐富的細節描述來(lái)定義和概述分類(lèi)。而且，你可以使用用戶(hù)自定義類(lèi)來(lái)創(chuàng )建自己內容的索引和目錄。例如，你可以為CMMI22水準定義類(lèi)，為基于這些水準的任務(wù)分類(lèi)。
圖 14: IBM Rational Unified Process的標準的和自定義的類(lèi)的實(shí)例。 Disciplines 和 Role Sets 是對于標準類(lèi)的例子。用戶(hù)自定義類(lèi)可以被用來(lái)對你的內容分類(lèi)和為發(fā)布網(wǎng)頁(yè)定義操控結構。
用Rational Method Composer管理過(guò)程
在文章的 第一段 ，我給了你在RMC中對過(guò)程的總的看法。在這部分，我們將看到創(chuàng )建過(guò)程的細節。我將討論RMC如何使用可重復使用的建造塊使你的工作過(guò)程更加便利 。我將展示給你如何創(chuàng )建混淆的方法內容和相關(guān)過(guò)程的具體方法內容。特別是，我們將看到如何對方法內容定義關(guān)聯(lián)來(lái)指導你系統的完成你的過(guò)程。
發(fā)展過(guò)程定義了發(fā)展項目如何被執行。在大部分不同過(guò)程定義的文獻中的一個(gè)共同屬性，是各個(gè)階段的順序和產(chǎn)品的生命周期的關(guān)鍵點(diǎn)。過(guò)程還定義了如何通過(guò)定義工作，操作，或占用時(shí)間的順序，專(zhuān)門(mén)技術(shù)或其他資源來(lái)發(fā)展，并最終產(chǎn)生成果。
諸如CMMI相關(guān)的過(guò)程框架定義了不同過(guò)程的成熟度水平。每個(gè)水平表示過(guò)程定義和工程制定的不同特性。例如， CMMI 定義了“已管理過(guò)程”，它能執行被識別出的活動(dòng)。類(lèi)似的過(guò)程有某種共同的特性：它按照策略執行；它使用高級技術(shù)人員，有足夠的資源制造可控輸出；它包括相關(guān)的涉眾；他會(huì )是可監測的，可控的，可回顧的；并且可以評估過(guò)程描述。相反，“已定義過(guò)程”是一個(gè)從標準的過(guò)程裁減的管理過(guò)程。已定義的過(guò)程有一個(gè)進(jìn)程描述且把工作產(chǎn)品，測試，和其他過(guò)程更新信息組合到過(guò)程資產(chǎn)中。 正如你將在此段看到的RMC過(guò)程支持許多屬性。
正如我們之前看到的，方法內容是單獨被定義的。它是作為一種為完成某種目的的用例來(lái)對待任務(wù)。為了創(chuàng )建過(guò)程，現在你需要定義在生命周期中有多少方式要被應用與排序。圖 15 從概念上描述了方法內容（以任務(wù)，角色，工作產(chǎn)品三個(gè)主要成分定義）如何在生命周期中被應用。
圖 15: 過(guò)程中應用方法內容。圖表顯示了方法內容如何用任務(wù)，角色，工作產(chǎn)品定義。
然而傳統的基于瀑布式的研發(fā)過(guò)程能或多或少為任務(wù)定義直線(xiàn)型，但當今迭代的過(guò)程，諸如RUP, Scrum, 和 XP需要更復雜的結構來(lái)展現發(fā)展的增量。在這種結構中，工作被打包入可同時(shí)重復的塊。
這些發(fā)展方法的變化仍然需要不同程度的規則和對過(guò)程描述的細節水平。傳統的發(fā)展過(guò)程定義階段基于預定義的可交付的類(lèi)型，提供準確工作順序的描述?？焖侔l(fā)展過(guò)程僅需要非正規的工作描述，因為他們認為一旦目標被確定了，自我組織的團隊能不受指導和控制。他們還很少注意面向可交付的工作的重復范圍，而是專(zhuān)注于面向功能的關(guān)鍵點(diǎn)。最終，現今可升級的迭代過(guò)程提供了清晰的關(guān)于依靠工程類(lèi)型和組織成熟度的工作的描述。 RMC 支持全部這些方法。
為了支持復雜過(guò)程結構和不同程度的形式，傳統的迭代開(kāi)發(fā)過(guò)程被設計成使用網(wǎng)狀工作流程表示法。它允許你以層次化網(wǎng)狀圖定義復雜的過(guò)程結構，這些網(wǎng)狀圖的每個(gè)結點(diǎn)都能包含一個(gè)全新的網(wǎng)絡(luò )圖。例如，RUP 總和UML-like活動(dòng)表一起定義過(guò)程?；顒?dòng)表能與工作一樣表達相同的意思。他們還能使用控制流表達順序。
第二種對于傳統瀑布式和迭代開(kāi)發(fā)過(guò)程的流行表述是工作分解結構。分解結構與網(wǎng)狀活動(dòng)圖表相似，因為它們允許通過(guò)嵌套進(jìn)行工作定義的精細化。他們使用一種被稱(chēng)為父級依賴(lài)關(guān)系的方式來(lái)排列工作，這種方法與控制流有些相似。通過(guò)這些父級節點(diǎn)，不相關(guān)的成分都可以自由的并行執行。另一個(gè)分解結構表示法的優(yōu)勢是他們在項目制定和管理應用方面非常流行，例如 IBM Rational Portfolio Manager 或 Microsoft Project。 在RMC中，分解結構支持在項目中連接過(guò)程定義和過(guò)程制定。 RMC綜合了兩種流行的活動(dòng)圖表過(guò)程表示方法和分解結構，形成了一種新的格式，它可以從內部表現過(guò)程。正如圖 16展示的，基于這種格式，RMC 支持可交互的兩種表達。
圖 16: 對于同一過(guò)程結構的兩種表達。過(guò)程先啟階段迭代不斷出現在分解結構和活動(dòng)圖表中。如果可能，在一部視圖里面的改變將會(huì )被轉移到另一部視圖。諸如在活動(dòng)圖表中的同步條一類(lèi)的特定表達成分不會(huì )在分解結構中出現，但是適當的父級依賴(lài)關(guān)系信息仍然來(lái)源于依據簡(jiǎn)單圖表規則的視圖中。
點(diǎn)擊放大
這里展示的例子用兩種表示法描繪了Eclipse過(guò)程框架的基本統一過(guò)程在先啟階段迭代的過(guò)程。23一個(gè)RMC 過(guò)程工作者在任一個(gè)過(guò)程表達中工作，并且RMC將自動(dòng)改變其他視圖，因為每個(gè)視圖來(lái)源于同一底層數據結構。當然，每個(gè)表述都不是完全相同的，都包括另一個(gè)表述所不具備的信息，例如在圖 16的圖表中的同步條和決定點(diǎn)就不在分解結構中。在這種情況下，另一個(gè)視圖忽略了這個(gè)信息但是提供了一個(gè)連續圖示，正如我們在圖 16看到的父級依賴(lài)關(guān)系。例如，繪制從一個(gè)活動(dòng)的到另一個(gè)活動(dòng)的控制流鏈接或通過(guò)同步條在活動(dòng)的分解結構間創(chuàng )建從結束到開(kāi)始的父級依賴(lài)關(guān)系。正如你在圖16頂部所看到的，父級節點(diǎn)根據圖表里的控制流列出。例如，"Manage Requirements"和 "Determine Architectural Feasibility" 引用了元素四作為其父級節點(diǎn)。
創(chuàng )建一個(gè)帶有分解結構的過(guò)程
例如傳遞過(guò)程或功能模式過(guò)程在RMC的過(guò)程編輯里作為網(wǎng)狀活動(dòng)的細目分類(lèi)被創(chuàng )建。正像我們在上段中看到的，細目分類(lèi)中的每一個(gè)活動(dòng)能在活動(dòng)圖表中表示它的子活動(dòng)。
所以，“活動(dòng)”是定義過(guò)程的主要概念。你看到的過(guò)程編輯內部的許多成分來(lái)源于活動(dòng)概念；換句話(huà)說(shuō)，它們是活動(dòng)的特殊作用。過(guò)程本身實(shí)際上只是特殊的活動(dòng)，它允許過(guò)程在活動(dòng)中嵌套。這提供了我們所定義的過(guò)程模式機制的實(shí)現。階段和重復是作為RMC過(guò)程編輯中的活動(dòng)被創(chuàng )建。你在RMC的過(guò)程中發(fā)現的唯一非活動(dòng)的概念就是解釋和重要事件。在RMC中以生命周期模型創(chuàng )建一個(gè)過(guò)程與在計劃編制工具中創(chuàng )建一個(gè)計劃非常相似。圖 17 描述了一個(gè)如何使用定義階段，反復和重要事件來(lái)開(kāi)發(fā)RUP 或 BUP-like過(guò)程的例子。
圖 17: 在RMC中使用分解結構為類(lèi)RUP過(guò)程創(chuàng )建一個(gè)生命周期模型。這個(gè)屏幕截圖還顯示了“基于RUP過(guò)程”的頂層活動(dòng)和允許你選擇當前文檔的活動(dòng)圖表。
點(diǎn)擊放大。
正如你在 圖 8中已看到的 (文章的第一段 )，展示了類(lèi)似混亂的過(guò)程生命周期，你在RMC中沒(méi)有被限制于使用類(lèi)RUP生命周期模型，因為RMC 支持你創(chuàng )建幾乎任何生命周期模型。
在圖 17的過(guò)程中定義了四個(gè)階段，因為它支持 RUP 生命周期模型。它的四個(gè)階段不得不通過(guò)父級依賴(lài)關(guān)系順序執行。在每個(gè)傳遞過(guò)程的階段，你可以對于反復發(fā)生子活動(dòng)。例如，在四個(gè)階段中，如果每個(gè)階段與其他的不同或者工作產(chǎn)品發(fā)展了，你可以以之前版本的過(guò)程為例，而不必以之后更詳細的為例。舉一個(gè)RUP的例子，之前的詳盡工作需要在建立工作環(huán)境和初始化可執行結構方面作的比之后版本更好。
正像上面提到的，除了描述符和關(guān)鍵事件，在分解結構中的所有成分都是活動(dòng)的，能有自己的活動(dòng)圖表，并且像在圖18中似的能通過(guò)更多活動(dòng)使其更精確。 圖18展示了如何用高水平的四個(gè)活動(dòng)來(lái)使先啟迭代更精確。
圖18：詳細流程顯示了：先啟迭代活動(dòng)如何被定義此類(lèi)型迭代的高級工作的活動(dòng)所改進(jìn)。
同樣的我們需要注意在右側列中所提供的信息。除了先前提到的信息之外，建立這些活動(dòng)的流程管理員同樣也把一些被認為是正在進(jìn)行的（在一個(gè)從這個(gè)流程起源的計劃中，這些活動(dòng)作為父類(lèi)活動(dòng)，動(dòng)態(tài)的擁有相同的持續時(shí)間），可重復的（它們可以在序列中被執行許多次）或者擁有多重的事件（它們被不同的小組平行的執行許多次）的某些活動(dòng)列入了清單。
一個(gè)和靈活的自組建小組工作的流程管理員，應該停下手中的工作，考慮圖 18中所提到的流程是否完成了。這個(gè)流程通過(guò)定義階段，不同的迭代種類(lèi)，里程碑和高級活動(dòng)的執行來(lái)提供了一個(gè)完整的開(kāi)發(fā)流程。它或許僅僅提供了一個(gè)靈活的項目所需要的細節以及形式的數量。然而不管怎樣，在接下來(lái)的部分中，我們將向您展示如何應用方法來(lái)滿(mǎn)足你的流程。這種方法內容應該定義了：當任務(wù)作為這些活動(dòng)的一部分被執行的時(shí)候，哪些工作產(chǎn)品應該被生產(chǎn)或者定義。這種方法參考提供了另外一種細目分類(lèi)細節的級別，這個(gè)細目分類(lèi)可以被用來(lái)計劃或者執行流程。它們同時(shí)應該為開(kāi)發(fā)小組提供一種指導服務(wù)，使他們不致于想要把這個(gè)級別的細節映射到一個(gè)項目中被計劃和跟蹤的工作中。
一個(gè)RMC中的活動(dòng)可以通過(guò)使用其他的嵌套活動(dòng)和引用，改進(jìn)成為方法目錄調用描述符或者兩者的結合物。一個(gè)描述符基本上就是一個(gè)流程中的引用對象，一方面它表現了一個(gè)活動(dòng)中，象一個(gè)任務(wù)或者工作產(chǎn)品這樣的一個(gè)方法目錄元素事件。另一方面，它同時(shí)擁有自己的關(guān)系和文檔屬性，這些關(guān)系和文檔屬性定義了這個(gè)特定的方法目錄元素和其他默認定義之間的區別。
例如，正如我們在圖 5 (第一部分)中所看到的，一個(gè)任務(wù)可以通過(guò)簡(jiǎn)單地把它拖拽到一個(gè)活動(dòng)的頂部，從而被RMC中的一個(gè)流程所應用。然而它并不是建立一個(gè)任務(wù)的拷貝，而是建立一個(gè)任務(wù)的描述符。這個(gè)描述符從任務(wù)中繼承了特征和關(guān)系，使它可以被擴展和重寫(xiě)。這就使得每一個(gè)活動(dòng)都定義了各自一系列的描述符。這種活動(dòng)的每一個(gè)描述符都僅僅包含關(guān)系和信息，而這些關(guān)系和信息都是特定的情況或者它所應用的流程環(huán)境。例如，“項目經(jīng)理”這個(gè)角色，通常是對一個(gè)不同產(chǎn)品（如項目計劃，迭代計劃，風(fēng)險列表，產(chǎn)品項目列表等等）的長(cháng)列表負責。項目經(jīng)理這個(gè)方法目錄元素角色列舉了所有這些關(guān)系，提供了項目經(jīng)理所應負責的工作產(chǎn)品的完整列表。然而，在一個(gè)特定的活動(dòng)環(huán)境中，一個(gè)項目經(jīng)理的角色描述符應該只會(huì )列出管理人員負責的工作產(chǎn)品，這個(gè)工作產(chǎn)品是這個(gè)活動(dòng)在整個(gè)流程中這一點(diǎn)上的環(huán)境中的。把圖 20上面的過(guò)程流程作為例子，你將看到項目經(jīng)理角色被活動(dòng)Manage the Project和活動(dòng)Initiate the Project中的描述符說(shuō)表示。在第一個(gè)活動(dòng)的環(huán)境中，只有"Iteration Plan"和"Work Items"中的項目經(jīng)理職責是相關(guān)的。而第二個(gè)活動(dòng)完全沒(méi)有處理這些工件，因此只有"Project Plan"的職責在這個(gè)角色描述符中顯示出來(lái)了。
當添加描述符到一個(gè)流程時(shí)，你可以從概念上總體描述的圖 15中所提到的三維的任何一維開(kāi)始。RMC提供給你三種過(guò)程視圖樣式，有工作細木分類(lèi)為中心的，工作產(chǎn)品為中心的和角色為中心的。不管你喜歡從哪里開(kāi)始，RMC都可以在另外兩維中支持你完成信息。RMC使用交互式的向導，它可以幫助你動(dòng)態(tài)的從基于圖 15左側插圖所示關(guān)系的方法目錄中找回信息，并且向候選人建議建立額外的描述符。
例如，圖 19顯示了一個(gè)場(chǎng)景，它展示了流程管理員拖拽“項目經(jīng)理”角色到活動(dòng)"Manage the Iteration"中，從而表示了這個(gè)角色在這個(gè)活動(dòng)中履行了工作。
圖 19：在活動(dòng)中應用項目經(jīng)理角色后，RMC要求用戶(hù)如果他想把任何工作產(chǎn)品添加到這個(gè)角色負責的流程。它通過(guò)檢查方法目錄中定義的關(guān)系來(lái)找回信息。用戶(hù)選擇了工作產(chǎn)品之后，RMC把它們作為工作產(chǎn)品描述符添加到流程，并且在它們之間建立職責關(guān)系。
為了指導用戶(hù)在基于知識結構上完成活動(dòng)，RMC已經(jīng)在方法目錄中被應用，RMC現在建議流程管理員進(jìn)一步的添加工作產(chǎn)品到Project Manager負責的活動(dòng)中。在圖 19所示的例子中，流程管理員選擇了“Work Items List”和“Iteration Plan”這兩個(gè)工件。RMC為這兩個(gè)工作產(chǎn)品添加描述符到相同的活動(dòng)“Manage the Iteration”中，并且使得項目經(jīng)理描述符作為這些工作產(chǎn)品描述符的職責角色。在添加這些新的工作產(chǎn)品描述符到流程之后，RMC繼續提出意見(jiàn)（圖 19中不可見(jiàn)的）。這一次，它促使所有的任務(wù)都把被選中的工作產(chǎn)品作為輸出列出，因為這些任務(wù)都將被當作好的候選添加到流程中。
做出這些在RMC中添加描述符的選擇，并沒(méi)有迫使你經(jīng)常的建立包括任務(wù)，工作產(chǎn)品和角色描述符的完整流程。你應該經(jīng)常建立更加靈活的，輕量級別的工作流程，比如說(shuō)在活動(dòng)中僅僅包含被操作的工作產(chǎn)品，和圖 20中所描述例子那樣的工作產(chǎn)品的隨意的角色職責。這個(gè)例子顯示了較低的視圖——我們在每一個(gè)活動(dòng)中為工作產(chǎn)品描述符調用入口和出口狀態(tài)。
圖 20: 一個(gè)沒(méi)有任何任務(wù)描述符的輕量級別的流程。圖中顯示了同個(gè)流程的兩個(gè)視圖。圖中上部的Consolidated View顯示了流程中細目分類(lèi)的定義。每一個(gè)活動(dòng)定義了執行的角色，同時(shí)也是工作產(chǎn)品的角色職責。Work Product Usage視圖顯示了流程的工作產(chǎn)品，為每個(gè)工作產(chǎn)品描述符在每一個(gè)活動(dòng)中定義開(kāi)始（入口）和結束（出口）狀態(tài)。在這個(gè)流程中，相關(guān)聯(lián)的角色的職責是負責把它們的工作產(chǎn)品從入口狀態(tài)轉換到出口狀態(tài)。
入口狀態(tài)表示了活動(dòng)可以開(kāi)始時(shí)，工作產(chǎn)品所應處的狀態(tài)，出口狀態(tài)定義了在活動(dòng)可以結束之時(shí)，工作產(chǎn)品所應處的狀態(tài)。在象上面提到的流程中，角色可以選擇它們自己的方法，用來(lái)達到所需要的工作產(chǎn)品狀態(tài)，而不需要按照形式的和說(shuō)明性的任務(wù)描述那樣做。當然，這些流程中仍然要包括足夠的形式，用來(lái)定義哪些角色為哪些工作產(chǎn)品負責，以及所期望的結果是什么。
在這兩部分文章中，我介紹了一些我對IBM Rational Method Composer以及Eclipse Process Framework (EPF)工具的總體看法和一點(diǎn)想法。另外我還發(fā)表一篇更高級別的，關(guān)于上面兩個(gè)方面的主要概念和性能的文章，在那篇文章中，我們反復的推敲，用詳細的概念以及特定工具描述了這些概念。
為了能夠更好的使用RMC以及EPF工具，我們推薦您瀏覽這些工具的在線(xiàn)幫助，這些幫助中包含了很多交互式的指南，它們可以給您一步一步地介紹如何執行這篇文章中所描述的場(chǎng)景。
RMC額外的應用和性能的介紹是超出這篇初級文章介紹范圍的，我們將在接下來(lái)的The Rational Edge這篇文章或者IBM developerWorks/Rational的其他地方介紹。其它主題包含如何導入以及管理員文本文檔；如何從不同的來(lái)源（特別是RMC的前身，IBM Rational Process Workbench）移植內容；以及如何為發(fā)表的結構建立分類(lèi)的和導航的構造；如何使用動(dòng)態(tài)模式綁定性能快速的匯集和裁剪流程；如何使用可變性和插件機制去擴展第三方內容和流程；如何作為計劃模版從RMC導入流程到IBM Rational Portfolio Manager；以及如何利用版本控制系統，如IBM Rational ClearCase或者CVS來(lái)使用RMC。
如果沒(méi)有很多充滿(mǎn)激情和奉獻精神的優(yōu)秀的團隊，就不會(huì )有現在發(fā)表的這篇文章。我在這里由衷地感謝：RUP開(kāi)發(fā)小組，QA小組，RUP內容小組，RUP產(chǎn)品小組，IRUP小組，IBM Global Services Method小組，UMA指導委員會(huì )Rational領(lǐng)域的成員，以及其他IBM方法小組，Tivoli ITUP小組，以及來(lái)自IBM內外的所有早期改編人員和Beta用戶(hù)，在最后當然還有ISSR為RMC和EPF做出的辛苦努力。
17參見(jiàn)，例如，Walker Royce，Software Project Management: A Unified Framework。Addison-Wesley Professional，1998
18 OMG，"Software Process Engineering Metamodel," 1.1版, formal/2005-01-06, 2005 http://www.omg.org/technology/documents/formal/spem.htm
19 參見(jiàn) I. Jacobson 等，Object-Oriented Software Engineering: A Use Case Driven Approach。Addison-Wesley, 1992; Peter Eeles, Kelli Houston, 和 Wojtek Kozaczynski, Building J2EE Applications with the Rational Unified Process。Addison-Wesley, 2002; 以及我自己的名為"Use Case-Based Software Development"的一章，在場(chǎng)景，故事，用例， 由Ian Alexander 和 Neil Maiden Wiley 2004年編輯。
20 Dean Leffingwell 和 Don Widrig, Managing Software Requirements: A Use Case Approach，第二版，Addison-Wesley 2003; 還有 Kurt Bittner 和 Ian Spence，Use Case Modeling，Addison-Wesley 2003。
21 Cem Kaner, Jack Falk, 以及 Hung Quoc Nguyen，Testing Computer Software，第二版。Wiley 1999。
22 Capability Maturity Model Integration。參見(jiàn)軟件工程研究所的Web站點(diǎn)http://www.sei.cmu.edu/可以得到更多信息。
23 參見(jiàn) Ricardo Balduino，"Basic Unified Process: A Process for Small and Agile Projects，" http://www.eclipse.org/proposals/beacon/Basic%20Unified%20Process.pdf Eclipse.org 2005。
|
|
|
|
| ||
| | Peter Haumer 是一位IBM Rational Method Composer 產(chǎn)品平臺的架構分析師。他負責定義下一代過(guò)程工程工具，并展示了IBM在SPEM2.0 的OMG中所做的開(kāi)創(chuàng )性工作。在加入Rational Unified Process小組之前，他是IBM品牌高級專(zhuān)業(yè)服務(wù)顧問(wèn)。他提供在線(xiàn)咨詢(xún)和培訓，并且輔助和指導客戶(hù)正確使用 Rational Unified Process 和其他 Rational 工具。他所涉及的領(lǐng)域包括需求管理，面向企業(yè)應用架構的面向對象分析與設計，和軟件過(guò)程實(shí)施。加入Rational之前，他專(zhuān)注于基礎研究，涉及的領(lǐng)域包括需求工程和可伸縮性的集成過(guò)程輔助軟件工具架構。 Peter 獲得了德國亞琛技術(shù)大學(xué)頒發(fā)的計算機科學(xué)博士學(xué)位。 |
|
|
聯(lián)系客服
