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