【正文】 件實現(xiàn)走查 . 進入條件 . 工作任務(wù) EOS 應用開發(fā)過程參考手冊 第 28 頁共 36 頁 . 輸出內(nèi)容 項目源碼 項目 實現(xiàn)的 文檔（ EOS Studio 產(chǎn)生 ） . 階段控制點 需求變更的嚴格控制 . 退出條件 . 參考模板 . 測試階 段 . 概述 本階段是應用項目的啟動階段 EOS 應用開發(fā)過程參考手冊 第 29 頁共 36 頁 測 試 階 段項 目 管 理 工 作項 目 實 施 工 作測 試 結(jié) 果 記 錄編 寫 測 試 用 例迭代編 寫 測 試 報 告系 統(tǒng) 測 試制 定 項 目 階 段 計 劃應 用 功 能 開 發(fā)任 務(wù) 分 配編 寫 測 試 方 案測 試 進 度 跟 蹤編寫用戶手冊測 試 環(huán) 境 準 備 . 進入條件 EOS 應用開發(fā)過程參考手冊 第 30 頁共 36 頁 . 工作任務(wù) . 輸出內(nèi)容 . 階段控制點 . 退出條件 . 參考模板 . 集成、部署階段 . 概述 本階段是應用項目的啟動階段 EOS 應用開發(fā)過程參考手冊 第 31 頁共 36 頁 集 成 、 部 署 階 段項 目 管 理 工 作項 目 實 施 工 作制 定 系 統(tǒng) 集 成 上 線階 段 計 劃編 寫 用 戶 文 檔項 目 驗 收系 統(tǒng) 上 線系 統(tǒng) 部 署 和 集成 測 試進 行 用 戶 培 訓 . 進入條件 系統(tǒng)經(jīng)過內(nèi)部的測試，具備在用戶環(huán)境進行部署和進行集成測試的條件。項目經(jīng)理的職責之一是“管人”。待所有高風險因素明確之后，全面將工作鋪開，投入項目組所有人力資源。面向構(gòu)件方法論主張通過評審、走查、測試等確認活動來決定構(gòu)件的完成進度，下面進行詳細闡述。 已分配到人（0 % ）已設(shè)計（3 0 % ）已實現(xiàn)（7 0 % ）已走查（8 0 % ）已測試（1 0 0 % ）[通 過設(shè)計評審][實 現(xiàn)完畢提交CVS ][未 通過][未 通過][走 查通過嗎][測 試通過嗎][通 過][通 過] . 并行開發(fā) 并行開發(fā)為什么很難呢？因為團隊成員的工作之間有依賴關(guān)系！ 本質(zhì)上，團隊成員之間的依賴關(guān)系是軟件組成部分之間依賴關(guān)系的體現(xiàn)。 重要說明 ：并行開發(fā)和迭代開發(fā)可以綜合實施，具體方法是，宏觀上進行迭代和增量開發(fā)，而每個迭代周期內(nèi)部，不同團隊成員并行工作。架構(gòu)中的接口，成為不同的團隊成員之間協(xié)作的“契約”，可以支持大規(guī)模并行式的團隊開發(fā) —— 架構(gòu)設(shè)計得越穩(wěn)定、越明確，并行的程度就可以越大。 開發(fā)者的考核，可以通過其負責的所有構(gòu)件的完成進度統(tǒng)計而來。任務(wù)的分配以構(gòu)件為單位，每個構(gòu)件都會分配到具體的開發(fā)者。這樣做的重大好處之一是“有利于和外部團隊協(xié)同”，當項目開發(fā)任何涉及外包子系統(tǒng)時非常易于管理；另外，很常見的情況是需求和總體設(shè)計由最終 客戶和中間件廠商共同完成，而后期工作由最終用戶的開發(fā)人員進行，此時，“動態(tài)團隊”的靈活性就十分明顯。 . 參考模板 EOS 應用開發(fā)過程參考手冊 第 33 頁共 36 頁 5. 其他 最佳實踐 待項目組已經(jīng)適應了面向構(gòu)件的軟件開發(fā)，可進一步采納更多體現(xiàn)普元公司多年經(jīng)驗的最佳實踐，使項目管理和生產(chǎn)力水平更上一層樓。 對于項目組而言，本階段的主要控制點包括： ? 確保 系統(tǒng)設(shè)計的質(zhì)量 ： 對于良好的系統(tǒng)設(shè)計，應該滿足如下要求： 1） 應用總體設(shè)計思路清晰，結(jié)構(gòu)簡捷合理 2） 功能設(shè)計可實現(xiàn)性強：通過查看原型、對應的數(shù)據(jù)庫設(shè)計和功能設(shè)計文檔， 功能 實現(xiàn)者 （開發(fā)人員） 比較清楚用戶界面的信息、對應操作的數(shù)據(jù)實體、應用處理的流程、相關(guān)的隱含規(guī)則 、界面流轉(zhuǎn)關(guān)系等等 3） 完整統(tǒng)一、操作性強的項目開發(fā)規(guī)范 ：這是保證項目滿足非功能性需求和系統(tǒng)質(zhì)量的重要工具 ，需要確保開發(fā)規(guī)范的內(nèi)容盡可能覆蓋項目實施的各個環(huán)節(jié)，同時所提供的規(guī)范內(nèi)容具有較強的操作性，而不至于流于形式。 另外，對于參與 EOS 應用設(shè)計的人員，建議對 EOS 的結(jié)構(gòu)和開發(fā)方式以及相關(guān)資源有較好的 理 解 ，這樣才能知道在設(shè)計中哪些工作不需要做了，哪些 內(nèi)容需要結(jié)合 EOS產(chǎn)品的 特點進行考慮。 對于 EOS 應用的設(shè)計 內(nèi)容 ，主要的重心在于業(yè)務(wù)模型的抽象（可理解為業(yè)務(wù)架構(gòu)）、構(gòu)件包的劃分以及功能點的細分， 這樣讓設(shè)計人員能夠從考慮技術(shù)架構(gòu) 和 OO 模 型 的穩(wěn)定、優(yōu)雅和是否符合力學原理的泥沼中解脫出來，將主要的精力花費在考慮業(yè)務(wù)模型的抽象和擴展能力上 （也有助于設(shè)計人員從技術(shù)思維轉(zhuǎn)向業(yè)務(wù)思維，或許我這種說法對于熱衷于技術(shù)研究的設(shè)計師會不以為然，但 如果設(shè)計師跟用戶溝通時如果屢屢提及對象、設(shè)計模式等詞眼未必能讓用戶對于系統(tǒng)的設(shè)計思路有多清晰的理解 ） 。下圖表現(xiàn)了一個系統(tǒng)經(jīng)過設(shè)計后用戶和實現(xiàn)人員的不同視角 這樣我們就很容易理解，當我們選擇 J2EE 實現(xiàn)用戶的應用系統(tǒng)時， 對于設(shè)計工作，一方面要 從技術(shù)層面 設(shè)計一個 應用 架構(gòu)來實現(xiàn)應用軟件的層次封裝， 在開源領(lǐng)域，目前有很多種應用架構(gòu)的成果，但往往只是解決了應用框架中一部分的問題，需要組合或者 EOS 應用開發(fā)過程參考手冊 第 22 頁共 36 頁 自行設(shè)計完整的應用框架結(jié)構(gòu)， 例如，可能選擇 Hibernate+Struts+Spring 經(jīng)過整合后的框架作為應用的框架，或者采用項目 組自行封裝的應用框架實現(xiàn)。 EOS 應用開發(fā)過程參考手冊 第 21 頁共 36 頁 . 退出條件 《項目需求規(guī)格說明書》獲得用戶簽字認可。對于項目經(jīng)理而言，本階段的主要控制點在于： ? 需求范圍的控制：因為在與用戶進行需求調(diào)研的基礎(chǔ)一般是項目的合同文本，往往合同對項目的功能范圍只是做了粗略的描述，這些 內(nèi)容需要通過調(diào)研工作進行細化和明確，功能細化的程度 往往對工作量的影響很大，在調(diào)研中需要掌握需求的主次，避免對非重要功能的需求過度復雜化（要知道一個功能做到不同程度， 付出的工作量的差異是很大的）， 同時 思考某個功能點的需求可能帶來的工作量和付出這種工作量對項目整體而言是否值得 （這就是讓系統(tǒng)架構(gòu)師和開發(fā)經(jīng)理參與需求調(diào)研的重要意義） 。 也有助于新進入項目的成員盡快進入工 作角色。 制定項目總體實施計劃 項目經(jīng)理 必須 應用項目往往有時間進度的要求，一般都明確了系統(tǒng)的上線時 間，在項目合同簽訂后，用戶要求提供針對上線時間安排倒推的項目總體實施計劃，所以制定項目總體實施計劃是項目經(jīng)理開始介入項目工作后的重要事情。 以上兩個工作在需求調(diào)研的過程中是迭代進行的，直到項目組認為需求基本明確，或者主要需求明確，能夠進行后續(xù)的 工作。 編寫需求規(guī)格 需求調(diào)研人員 必須 在進行完一次需求調(diào)研的溝通會議后，應該及時進行消化 ， 并以文檔的 形 式沉淀到 需求規(guī)格 說 明書中 ， 同時將需求溝通中未涉及或未明確的問題再次整理到問題清單中，通過電話、郵件、或會議方式讓用戶進行澄清。 進行需求調(diào)研 需求調(diào)研人員 必須 需求調(diào)研人員 在用戶確認后進入到調(diào)研現(xiàn)場， 由項目經(jīng)理負責組織與用戶的需求調(diào)研工作。 需求調(diào)研人員建議由項目經(jīng)理，開發(fā)經(jīng)理，業(yè)務(wù)專家、架構(gòu)師等人員組成。 這種狀況導致無法在 人為確定的需求階段中固化所有的需求內(nèi)容，因此，對于項目組而言，在本階段所掌握的需求內(nèi)容基本充分，能夠進行后續(xù)的設(shè)計工作，或者說，所不明確的需求，不足以 影響 系統(tǒng)的結(jié)構(gòu)和目前工作的進展，那么，需求階段的目標就算是基本達到了。 對于本階段的工作，如圖所示，詳細的說明，參見“工作任務(wù)”章節(jié)。 EOS 應用開發(fā)過程參考手冊 第 16 頁共 36 頁 4. 開發(fā)過程階段描述 為保證對各個階段的描述有一個完整統(tǒng)一的描述方法，將采用 “ ETOCXM”的方法 進行，具體方式如下： ? Entry（進入條件）：為每個階段定義清晰良好的入口條件； ? Task（工作任務(wù)）：列出所有要實現(xiàn)的任務(wù)列表，名稱，是否需要實現(xiàn)，任務(wù)描述； ? Output（輸出內(nèi)容） ： 階段工作的輸出產(chǎn)物以及評審內(nèi)容 ； ? Control Point（ 階段 控制點） ：本階段中為保證項目成功的關(guān)鍵控制點 ； ? eXit（退出條件） ：階段結(jié)束時所要達到的結(jié)果 ，注意，階段退出條件并不意味下一階段進入條件，因為下一階段可能在上一階段并未結(jié)束的情況下就已經(jīng)啟動了； ? Template（參考模板）： 本階段可供參考的文檔模板或參考案例 . 需求階段 . 概述 本階段是應用項目的啟動階段 ， 它主要完成應用系統(tǒng)需求的采集整理工作，形成系統(tǒng)設(shè) EOS 應用開發(fā)過程參考手冊 第 17 頁共 36 頁 計和實現(xiàn)所需要的需求基線庫。 . 測試人員 在 EOS 應用的開發(fā)中，測試人員主要進行功能測試、集成測試、系統(tǒng)測試、驗收測試、其他非功能性專項測試等，測試主要從需求規(guī)格和功能設(shè)計出發(fā)，以黑盒測試為主。系統(tǒng)管理員具有功能：信息管 理、數(shù)據(jù)管理、權(quán)限管理。 EOS 應用開發(fā)過程參考手冊 第 14 頁共 36 頁 . 支持角色 . EOS 專家 EOS 專家是指精通 EOS 產(chǎn)品的技術(shù)專家，能夠為項目組提供 如下服務(wù)： ? 提供基于 EOS 的應用開發(fā)過程和項目管理方面的指導 ? 結(jié)合應用要求和 EOS 特點的 提供 應用設(shè)計 方面的咨詢和 指導 ? 幫助項目組建立結(jié)合 EOS 特點和應用要求的開發(fā)規(guī)范 ? 為應用開發(fā)中的技術(shù)課題攻關(guān)提供解決方案 或指導 ? 為開發(fā)人員提供產(chǎn)品使用的培訓和指導 ? 開發(fā) 中故障的快速定位 和處理 對于初次采用 EOS 進行項目開發(fā)的項目組， EOS 專家往往是由普元公司的服務(wù)工程師擔任，對于 已經(jīng)有 EOS 應用項目開發(fā)經(jīng)驗的項目組，由具有相關(guān)經(jīng)驗的人員擔任。另外，他還輔助架構(gòu)師進行功能分解、頁面原型設(shè)計等工作。 . 業(yè)務(wù)專家 業(yè)務(wù)專家是具備業(yè)務(wù)領(lǐng)域知識的人才，他負責輔助其他角色建立業(yè)務(wù)模型，并對最終業(yè)務(wù)模型評審把關(guān)。 開發(fā)經(jīng)理應當有良好的技術(shù) 功底，尤以通才為佳。作為項目的操作者和維持者，項目經(jīng)理的工作是創(chuàng)造和維持 一個良好的環(huán)境，使項目組運行在最佳狀態(tài)。通常情況下，會根據(jù)項目的大小，人員的投入情況以及成員的個人能力和經(jīng)驗差異，某個人會承擔一個或多個角色。試圖用過程或技術(shù)取代人的做法是愚蠢的，因為技術(shù)也好，過程也好，沒有項目組人員的支持和參與，就不會發(fā)揮出相應的作用。需要關(guān)注的是相關(guān)的工作是否串行和對其他工作是否存在依賴型。 ? 集成、部署：主要完成系統(tǒng)在用戶環(huán)境中上線，并通過用戶培訓，將應用系統(tǒng)交付用戶使用。需求規(guī)格需明確功能需求、質(zhì)量屬性、約束條件等需求的所有方面。 XML Data Bus 作為