KehuiCMS文檔-: 應用 Rational 工具簡(jiǎn)化基于 J2EE 的項目第 7 部分 ：構建與演示 -可慧網(wǎng)絡(luò ) KehuiCMS 內容管理系統官方網(wǎng)站
應用 Rational 工具簡(jiǎn)化基于 J2EE 的項目第 7 部分 ：構建與演示
文章發(fā)表:jackei 發(fā)表日期:2005-03-30 閱讀次數:132
本文是演示了在分布式的、基于
J2EE 的項目中使用
Rational 工具的系列文章（如下面所列）的第
7部分。
第 1 部分: 項目介紹；高層次計劃
第 2 部分: 風(fēng)險管理；需求管理
第 3 部分: 模型創(chuàng )建和訪(fǎng)問(wèn)控制；需求分析
第 4 部分: 用例細化；產(chǎn)成報告；工具和技術(shù)選擇
第 5 部分: 體系架構和設計
第 6 部分: 詳細設計；早期開(kāi)發(fā)；雙向工程；早期單元測試
7部分: 繼續開(kāi)發(fā)；早期的構建；演示 第 8
部分: 單元測試策略；功能測試；GUI 測試腳本 第 9
部分: 系統構建和測試；缺陷跟蹤；產(chǎn)品交付 第 10
部分: 項目完成；結論；未來(lái)的工作
本文中所虛構我們是一家軟件公司 Lookoff Technologies Incorporated，我們的客戶(hù) Audiophile Speaker Design, Inc. (ASDI)，它雇用我們實(shí)現他們最初的 IT 需求。對于更詳細的信息，參見(jiàn)
第 1 部分。
這個(gè)系列文章的第七
部分主要關(guān)注在我們繼續開(kāi)發(fā)的構建和演示上。這些話(huà)題在
Rational 統一過(guò)程（RUP）中只是很簡(jiǎn)略的被提到，因為這個(gè)話(huà)題對特定項目的本質(zhì)有著(zhù)非常大的依賴(lài)。你將如何并在什么時(shí)候集成和演示你的系統依靠于你的客戶(hù)、項目規模和項目風(fēng)險。
第
7部分快照
在第
7部分演示的工具和技術(shù)：
Rational 統一過(guò)程 (RUP) — 用于構建和演示計劃的指導方針
被創(chuàng )建或者更新的產(chǎn)物：
在繼續開(kāi)發(fā)期間代碼和設計模型的更新 被創(chuàng )建的構建和演示計劃
演示發(fā)生在 ASDI 項目的幾個(gè)點(diǎn)上，尤其是在 RUP 的細化和構建階段。然而，構建卻是迭代過(guò)程、集成被分別開(kāi)發(fā)的組件和作為小的里程碑為跟蹤開(kāi)發(fā)過(guò)程服務(wù)的常規
部分，演示更趨向于特殊的目標。在我們的項目中，這些目標依賴(lài)于項目進(jìn)展到什么地方而不同，并且這些目標依次的確定了演示的精確性和他的觀(guān)眾。演示可以是基于構建的，也可以不是（例如，他們可以是被模擬的用戶(hù)界面），演示可以是針對公司內部的，也可以是針對于外部用戶(hù)的。
在細化階段，演示具有下列的目標：
顯示現貨供應（OTS）軟件產(chǎn)品的評估結果。 展示用戶(hù)界面的模擬，顯示主要屏幕的草圖，并且有時(shí)顯示系統的工作流程。 通過(guò)演進(jìn)產(chǎn)品的非常早期的演示來(lái)管理客戶(hù)的期望。 減少架構方面的風(fēng)險。 獲取分析的反饋。
在構建階段中，演示有這樣一些目標：
向客戶(hù)提供團隊的進(jìn)展信息。 通過(guò)在階段的早期使用接口識別出問(wèn)題以減輕子系統的集成。 避免“巨大系統”的集成和在項目末期才得到交付系統。 通過(guò)讓團隊在一個(gè)或者多個(gè)子系統演示的會(huì )議中看到項目的進(jìn)展來(lái)鼓舞項目人員的士氣。
另外，早期的演示為后面被集成與測試人員進(jìn)行的正式的構建提供了實(shí)踐上的指導，正式的構建包括測試所有的需求和完整的構建文檔等等。
內部團隊的演示很自然要比外部演示的次數和花費的精力要少。無(wú)論何時(shí)我們向客戶(hù)顯示軟件，我們都希望在向客戶(hù)演示時(shí)避免任何的故障，但是這在內部演示檢查時(shí)并不是十分重要的。
內部演示通常在一周中比較晚的時(shí)候被執行，也許是周五下午的晚些時(shí)候的團隊片刻休息的時(shí)間。在演示的過(guò)程中工作在一個(gè)特定子系統或者線(xiàn)程的一個(gè)或者多個(gè)開(kāi)發(fā)人員可以討論他們的進(jìn)展、顯示他們的工作進(jìn)度和討論任何他們遇到的問(wèn)題，我們能夠在演示中收集到這些信息。討論必然伴隨著(zhù)有關(guān)方案、好的想法和被其他團隊成員發(fā)現的一致性問(wèn)題的產(chǎn)生。這些演示要求很少的準備 — 也許只是不加修飾的構建版本并且快速的執行構建版本的使用過(guò)程以確定系統是可以被接受的。演示很少會(huì )非常順利，但是我們并不把這種現象看作成問(wèn)題，因為我們知道對他們進(jìn)行精化將意味著(zhù)額外的準備和測試的工作。
外部演示具有一個(gè)被增加的正式的標準。因為我們希望維持客戶(hù)的信心，并且不浪費他們的時(shí)間，我們遵循了這樣一些指導方針：
使用議程和其他指引的形式事先溝通演示的目標。 準備好清晰、明確的測試數據集合。 最好是從被版本化的資源存儲庫中重新構建計劃（schema）和代碼基礎。 為演示生成腳本。 在演示場(chǎng)所與團隊領(lǐng)導一起執行一次實(shí)際的演示過(guò)程。 確保在演示期間所有的工程團隊成員停止使用任何共享的資源（尤其是被存儲在 DB2 數據庫中的公共數據和表）。 用一個(gè)小時(shí)的時(shí)間進(jìn)行演示，大概花費另外兩個(gè)小時(shí)的時(shí)間進(jìn)行演示的反饋和討論。
這些防范措施看起來(lái)似乎有些過(guò)分，但是我們發(fā)現一個(gè)準備不充分的客戶(hù)演示將產(chǎn)生很少的價(jià)值，并且是浪費時(shí)間和項目預算的。
7>構建和演示計劃
表 1 列出了在 ASDI 項目的細化與構建階段我們?yōu)闃嫿ê脱菔局贫ǖ拇笾掠媱潱?div style="height:15px;">
我們很多的演示是可以被合并的，或者可以與其他的會(huì )議并行的發(fā)生。 為了準備演示，一些構建是必要的。 我們很多的子系統的構建和局部系統的構建是”小的構建版本“，這些構建版本不是非常正式的，并且花費我們很少的時(shí)間。
RUP 階段 構建或者演示的種類(lèi) 頻率 時(shí)間選擇
細化階段 工具評估原型 一次 OTS 產(chǎn)品評估交付之前
用戶(hù)界面模擬 每個(gè) GUI 用例兩次 在用例分析活動(dòng)早期和細化階段后期
架構原型 一次，滿(mǎn)足性能的要求 在軟件架構文檔(SAD)交付之前
構建階段 用戶(hù)界面外觀(guān) 兩次，分別在兩周執行 構建階段的早期
設計原型 一次 SAD 交付的幾周后
組件演示 每周 開(kāi)始于構建階段早期
子系統構建 每周 進(jìn)入構建階段的 1 到 2 周
子系統演示和局部系統的構建 半個(gè)月 進(jìn)入構建階段的 3 到 4 周
完整系統構建和系統演示 每月 進(jìn)入構建階段的 4 到 6 周
表 1: 構建和演示計劃
有很多方法能夠執行演示。這些方法看起來(lái)是相當明顯的活動(dòng)，但是有一些能夠增加演示價(jià)值的新穎的方法。
聯(lián)合
應用開(kāi)發(fā)（JAD）基本上包括為了非常集中和激烈的自由討論活動(dòng)，將所有的項目涉眾集中在在一個(gè)演示場(chǎng)所中，典型的包括一些演示的種類(lèi)。我們在我們的項目中嘗試了幾次 JAD 方法，但是我們發(fā)現這個(gè)方法執行起來(lái)是困難的，并且產(chǎn)生了一些混合的結果。我們所檢查的多個(gè)參考（有兩個(gè)參考被列在文章結束
部分的
在我們的項目中， JAD 意味著(zhù)將 ASDI 的問(wèn)題領(lǐng)域專(zhuān)家、 ASDI 的 IT 領(lǐng)導、我們的高級工程師和來(lái)自于雙方的項目經(jīng)理集中到一起。我們關(guān)注我們在需求和用戶(hù)界面設計方面的討論（雖然不是在同一時(shí)間）。在 JAD 會(huì )議之前，我們已經(jīng)提供了一個(gè)議程安排，從議程安排中仲裁者將引導會(huì )議進(jìn)行。會(huì )議中進(jìn)行很多的討論，并且一個(gè)高級的圖被畫(huà)在了白板上。（我們使用了一個(gè)數碼的白板，我們可以在這個(gè)數碼白板上保存和打印被畫(huà)出的圖，這是非常節省時(shí)間的。）我們也讓一個(gè)工程團隊的成員花費一些時(shí)間來(lái)記錄任何支持圖的注釋。
我們在項目的兩個(gè)階段嘗試使用了 JAD 方法：在早期的細化階段針對角色（actor）和用例（use case）需求；和在后期的細化階段針對用戶(hù)
應用程序的工作流程和設計（主要是用戶(hù)界面設計）。這里我們將轉向到我們的例子的后者。
在這個(gè)第二次的 JAD 會(huì )議上，我們項目中在 JSP 和 HTML 方面做擅長(cháng)的開(kāi)發(fā)人員展示了基于用例分析和注釋的早期用戶(hù)界面模擬。我們在每個(gè)屏幕界面上花費和 15 分鐘的時(shí)間，與全體參加會(huì )議的人員針對特定的用戶(hù)界面外貌和整體的界面感觀(guān)、被展示的功能和貫穿系統的導航進(jìn)行集體的談?wù)?。當有任何建議時(shí)，我們在現場(chǎng)對這些建議進(jìn)行了探討。我們將所以的討論結果結合到了一起，并在過(guò)程中學(xué)到這些教訓：
對于開(kāi)發(fā)人員來(lái)說(shuō)，在計算機上跟上被建議的重大改變是困難的。我們需要使用一種特殊的快速構建原型的工具、限制建議的范圍，或者由多個(gè)開(kāi)發(fā)人員并行的實(shí)現改變。 仲裁者必須在引導會(huì )議流程方面是非常老練的：具有足夠的技術(shù)背景以跟隨討論，但也必須是足夠外向的以使每一個(gè)參與討論的人在輕松自然的氛圍中，并且從中立的角度來(lái)引導討論。 仲裁者不應該負責跟蹤時(shí)間。相反，應該由另一個(gè)人來(lái)關(guān)注會(huì )議中的任務(wù)和被分配的時(shí)間的控制。如果某一個(gè)議題超過(guò)了規定的時(shí)間，那么這個(gè)議題應該被推延到其他的時(shí)間再討論。 JAD 會(huì )議要求在保護范圍和時(shí)間計劃上有一個(gè)微妙的平衡，并且鼓勵反饋和改進(jìn)的想法。
我們發(fā)現簡(jiǎn)單的顯示和解說(shuō)的演示方法是最有效的并且最容易管理的方法。不像在現實(shí)的 JAD 會(huì )議中處理問(wèn)題那樣，使用被大約一周左右的周期分開(kāi)的小的演示可以給我們時(shí)間來(lái)考慮關(guān)于請求的影響，并且我們可以提出針對于被識別出的問(wèn)題的解決方案。如果經(jīng)過(guò)批準我們能夠有額外的 JAD 的培訓，我們也許能夠將幾個(gè)顯示和解說(shuō)的演示壓縮到一個(gè)或者兩個(gè) JAD 會(huì )議中；在同一場(chǎng)所中保持每一個(gè)人進(jìn)行有效的協(xié)作可以節省我們計劃中的大量時(shí)間。
隨著(zhù)構建階段的進(jìn)展，我們的系統到達了客戶(hù)能夠開(kāi)始對其進(jìn)行操作的時(shí)候了。如
如果系統從外表上看是相當優(yōu)雅的（也就是說(shuō)，在它的用戶(hù)界面上），客戶(hù)也許會(huì )假定所有的工作都已經(jīng)幾乎被完成了。 如果系統從外表上看是很粗糙的（比如，缺乏錯誤處理和穩定性），客戶(hù)也許會(huì )對團隊的進(jìn)度感到不安。
當 ASDI 操作系統的早期版本時(shí)，我們必須不斷的提醒他們，我們僅僅是在創(chuàng )建第一階段的概念驗證，并且那些“外表漂亮”的非關(guān)鍵特性將會(huì )被延遲到后續的項目工作中完成。然而，我們確保了他們所有的建議都被記錄了下來(lái)，因為他們的許多想法都是非常好的，并且值得我們在接下來(lái)的工作中再次的考慮。通常，ASDI 理解我們?yōu)樗麄兲峁?shí)際操作系統的機會(huì )的意圖和限制，因此上面所提到的風(fēng)險對于我們來(lái)說(shuō)不是什么問(wèn)題。
開(kāi)發(fā)團隊花費了一些時(shí)間來(lái)辯論對于早期的演示創(chuàng )建系統正面相比于使用一個(gè)演進(jìn)的產(chǎn)品的優(yōu)點(diǎn)。典型的，正面是一個(gè)掩藏了系統背后場(chǎng)景的產(chǎn)品，它被盡可能快速并且低成本的實(shí)現。另一方面，使用演進(jìn)的產(chǎn)品需要投入更多的設計和實(shí)現的工作到早期的版本中。
實(shí)際上，在 ASDI 項目的第一階段中，為了演示圖形化的用戶(hù)界面，在分析用戶(hù)工作流程的過(guò)程中我們嘗試使用了這兩種方法。表 2 比較了兩種方法的結果。
演示外表 正面 系統早期版本
被使用的開(kāi)發(fā)工具 Microsoft FrontPage JSP/Text 編輯器
在第一個(gè)演示之前準備時(shí)間 3 天 1.5 周
向客戶(hù)傳達工作流程/GUI 的能力 好 好
轉移類(lèi)似的外表到最終產(chǎn)品的能力 一般 好
針對請求和建議的回復更改演示的速度 非?？?慢到中等速度
在演示后的重用機會(huì ) 不好 一般
培訓時(shí)間 短期培訓 短期培訓（因為團隊在在 JSP 上經(jīng)過(guò)了培訓）
與后端的 servlet 和數據庫集成的容易程度 不好到一般
表 2: 使用正面演示 UI VS. 使用早期代碼版本演示 UI
我們在項目的初始階段和細化階段的早期為演示使用了正面。雖然經(jīng)常會(huì )有一些零散的演示，但是我們覺(jué)得投入是值得的。我們使用了 FrontPage ，因為我們沒(méi)有與 Java servlet 和數據庫集成的困難，因為我們還沒(méi)有任何需要連接的數據庫計劃或者組件。因為我們在項目中使用了 FrontPage ，FrontPage 2002 的數據庫集成能力已經(jīng)得到了改進(jìn)，如果我們在將來(lái)的項目中需要，我們甚至可以使用它來(lái)從數據庫計劃中顯示測試數據。
一旦設計開(kāi)始穩定，我們就進(jìn)入到了一個(gè)使用 JSP 和 servlet 的迭代的編碼周期。在項目的早期
部分（在初始和細化期間）編寫(xiě)零散的 Java 代碼是價(jià)值很小的，因為在那個(gè)時(shí)候除了 Java 我們甚至不能確定我們將要使用 JSP 和 servlet 。使用 FrontPage 是更快更容易的，并且我們不用擔心任何隱含的技術(shù)選擇。
在項目的構建階段的早期開(kāi)始產(chǎn)生系統的構建版本能夠更加快速的消除問(wèn)題，并且頻繁的產(chǎn)生構建版本能夠幫助保持項目中每一個(gè)成員的同步。在 ASDI 項目中在過(guò)多和過(guò)少的構建版本之間找到一個(gè)平衡點(diǎn)是重要的。選擇頻繁的構建就必須考慮到項目復雜性、休假計劃、團隊技能、客戶(hù)可用性（對于外部演示）和組件和子系統之間的依賴(lài)的問(wèn)題。
我們的子系統集成了被分別開(kāi)發(fā)的組件，并且有時(shí)導致生成系統的演示。我們并沒(méi)有堅持要求所有的子系統的構建版本都具有演示；而是團隊領(lǐng)導會(huì )實(shí)行一個(gè)內部的構建版本 — 通常每個(gè)構建版本的計劃時(shí)間是每周一次 — 恰好確保了各
部分代碼能夠集合在一起。這同步了工作在子系統中的每一個(gè)人，因為例如，他們所有的人都必須為構建版本使用相同的數據庫計劃。當團隊領(lǐng)導選擇演示被集成的子系統時(shí)，這個(gè)演示會(huì )在周末的團隊會(huì )議上被展示，通過(guò)觀(guān)看他們負責的系統
部分是如何被改進(jìn)的，給團隊一種成就覺(jué)。
團隊領(lǐng)導在建立這些演示上是高效的。整個(gè)團隊都知道在星期五的上午開(kāi)始修改他們的代碼以為集成工作做準備。典型的，生成構建版本是在中午過(guò)后，如果在集成過(guò)程中出現了任何問(wèn)題，允許在一個(gè)或者兩個(gè)小時(shí)時(shí)間修改和討論。在確保所有的最近被更新的代碼都已經(jīng)被檢入（check in）后，團隊領(lǐng)導將從源代碼存儲庫庫中提出所有的代碼。
我們的配置管理工具是我們這個(gè)項目的一塊絆腳石。我們沒(méi)有選擇
Rational ClearCase 作為我們的配置管理方法，而是使用了免費的 CVS (Concurrent Versioning System) 工具提供的能力。配置管理是軟件管理的重要組成
部分，并且在項目之后，我們希望我們能夠投入更多的時(shí)間在我們的配置管理工具的選擇、集成和使用的指導上。我們沒(méi)有使用一個(gè)集成的方案就意味著(zhù)：
團隊幾乎不可能以一種正規的基礎來(lái)檢入（check out）和檢出（check in）文件。 數據在不良的配置管理中丟失。 變更不能被容易的關(guān)聯(lián)到集成與測試（I&T）的問(wèn)題或者軟件的變更請求上。 使用不好的 CVS 工具將使團隊的工作效率大大降低。
我們決定如果我們贏(yíng)得了項目的第二階段的和約，我們將評估 ClearCase 作為我們使用的另一個(gè)
Rational 工具集中的工具。
一些或許所有的最近開(kāi)發(fā)的子系統被集成成為一個(gè)系統構建版本，就像子系統構建一樣，系統的構建有相同的好處和目標，除了：
系統構建會(huì )花費更多的準備工作，對團隊有更大的影響，并且對于我們來(lái)說(shuō)是更大的分散注意力的原因。 他們通常揭示了大量的問(wèn)題，甚至是能夠威脅項目成功的更加嚴重的問(wèn)題。 他們在構建階段的后期開(kāi)始，因為我們需要足夠數量的子系統來(lái)調整集成的工作。 完整的系統構建最終要由集成與測試（I&T）團隊的介入。
工程團隊在沒(méi)有集成與測試團隊的幫助下完成了首先兩個(gè)完整系統的試驗版本。這些最初的構建工作是痛苦的：我們在配置管理上有很多問(wèn)題；一些子系統接口級別的細節已經(jīng)丟失了；并且一些子系統稍微的落后于計劃。在第二個(gè)試驗版本中集成與測試團隊作為觀(guān)察者的身份加入了進(jìn)來(lái)，并且開(kāi)始了下一個(gè)系統構建的集成工作。這有利于向集成與測試團隊平滑的轉移職責和知識，同時(shí)也不會(huì )在首先兩個(gè)構建版本中浪費時(shí)間。
對于工程團隊和后期的集成與測試團隊來(lái)說(shuō)，對在每一個(gè)構建版本中應該包括什么有一個(gè)清晰的概念是十分重要的；否則，構建工作將會(huì )很慢的執行，并且會(huì )以浪費團隊的時(shí)間結束。實(shí)際上，我們很好的理解了迭代構建的過(guò)程和每一個(gè)集成工作的目標，并且我們能夠成本高效的執行構建的工作。
我們的構建和內部演示工作通常進(jìn)行的非常平穩；然而，遠程個(gè)構建需要來(lái)自于項目工程師的額外注意。對于遠程開(kāi)發(fā)的子系統的計劃經(jīng)常不能按時(shí)完成，因為遠程的開(kāi)發(fā)團隊不能訪(fǎng)問(wèn)和核心工程團隊一樣的資源。
我們的客戶(hù)演示是非常成功的。我們非常自信我們在構建階段的早期擁有一個(gè)清晰的客戶(hù)需求的描述，并且客戶(hù)對我們構建的產(chǎn)品也有一個(gè)清晰的概念。在最終的產(chǎn)品交付期間，存在很少的錯誤期望和驚訝。
現在系統的構建開(kāi)始進(jìn)行了，我們很快的將步入測試工作。我們計劃使用
Rational 的測試工具幫助我們完成測試工作。我們需要確保所有 ASDI 項目的功能都被適當的執行過(guò)，并且在一定的負載下測試我們 Web
應用的性能。這些活動(dòng)也增加了集成與測試團隊對系統的熟悉，并且開(kāi)始學(xué)習使用測試工具。
我們的構建和演示沒(méi)有增加任何的新的風(fēng)險；實(shí)際上，發(fā)現并修改早期的問(wèn)題幫助減少了風(fēng)險。我們繼續的感覺(jué)到在時(shí)間進(jìn)度上的壓力，然而，我們知道構建必須以快速的步伐進(jìn)行。在起草我們的功能測試說(shuō)明中我們已經(jīng)落后于計劃了。 RUP 建議在項目的更早的時(shí)候開(kāi)始這些工作，我們現在承受了巨大的壓力，因為我們已經(jīng)延遲了個(gè)活動(dòng)。
by Alan Cline (Carolla Development, Inc. whitepaper) by the University of Texas at AustinSteven Franklin 在軟件的設計、架構和工程過(guò)程方面有非常廣泛的背景，這些經(jīng)驗通常被用到大的，分布式的信息管理和控制系統中。他從1997年開(kāi)始使用
Rational 工具，他主要的興趣在 XML 、
J2EE、無(wú)線(xiàn)和軟件工程技術(shù)方面。你可以通過(guò)
steve@sfranklin.net聯(lián)系 Steven.
作者Blog：
http://blog.csdn.net/jackei/
