【文章內(nèi)容簡介】 8 頁共 36 頁 . 其余部分的結(jié)構(gòu) 本文檔的其余部分，將依次闡述下列內(nèi)容： ? EOS 應用開發(fā)過程 ? EOS 應用開發(fā)的角色 ? 開發(fā)過程階段描述 ? 其他最佳實踐 EOS 應用開發(fā)過程參考手冊 第 9 頁共 36 頁 2. EOS 應用開發(fā)過程 EOS 應用是典型的 J2EE 企業(yè)應用，所以 EOS 應用的開發(fā)過程將以 J2EE 企業(yè)應用開發(fā)過程為參照并結(jié)合 EOS 的特點進行說明。一般而言，對于 J2EE 的企業(yè)級應用的開發(fā)，可以劃分為如下內(nèi)容： ? 需求： 明確軟件開發(fā)的任務，形成所有相關(guān) 涉眾（如客戶、用戶、項目組）共同認可的軟件需求規(guī)格。需求規(guī)格需明確功能需求、質(zhì)量屬性、約束條件等需求的所有方面。 ? 設(shè)計：針對需求進行分析設(shè)計，形成項目組的設(shè)計說明書和功能清單。 ? 開發(fā)：在設(shè)計說明的指導下完成應用的實現(xiàn)。 ? 測試：針對實現(xiàn)的應用進行系統(tǒng)良好性的驗證，可能包含的測試工作如：功能測試、系統(tǒng)測試、集成測試、性能測試等。 ? 集成、部署：主要完成系統(tǒng)在用戶環(huán)境中上線，并通過用戶培訓，將應用系統(tǒng)交付用戶使用。 應用開發(fā)中， 針對以上工作，一般都劃分為一個獨立階段，然而，各個階段僅僅表明一個工作的重心和職 能以及階段間的順序，并不代表著各個階段的工作是串行的。實際上，各個階段在不同的應用項目中，不同程度存在一定階段重合（并行）或者迭代現(xiàn)象。 如下圖： 需 求設(shè) 計開 發(fā)測 試集 成 部 署0 T 1 T 2T 3 T 4 T 5 T 6 T 7項目階段項 目 開 發(fā) 周 期 對應用開發(fā)過程進行階段劃分的主要目標還是便于界定各個階段的主要工作內(nèi)容，而不在乎你是否把屬于該階段的工作放到上一階段中，或者干脆將某兩個階段合并為一個階段。需要關(guān)注的是相關(guān)的工作是否串行和對其他工作是否存在依賴型。 對于 開發(fā)過程的 描述 ， 除了與應用開發(fā)和項目實施密切相關(guān)的 工作內(nèi)容 以外，還將包括保障 項目實施的各種項目管理方法和手段。 另外，在對各個階段的工作進行描述之前，先對 EOS 應用開發(fā)過程參考手冊 第 10 頁共 36 頁 EOS 應用開發(fā)過程中涉及的各種角色進行簡單的說明。 EOS 應用開發(fā)過程參考手冊 第 11 頁共 36 頁 3. EOS 應用開發(fā)的角色 . 理解角色 項目是由人、過程和技術(shù)組成的，但是迄今為止，最重要的因素是人。試圖用過程或技術(shù)取代人的做法是愚蠢的，因為技術(shù)也好，過程也好，沒有項目組人員的支持和參與，就不會發(fā)揮出相應的作用。在 EOS 項目中，對于項目成員角色的定義與其他的 J2EE 項目的角色定義幾乎是一致的，只是在某些角色的職責方面有一定的差異。以下將分關(guān)鍵角色、支持角色和額外角色分別進行說明。 另外，需要強調(diào)的是，角色代表著項目組的一種職責，并不意味著不同角色都必須由不同的人分別承擔，細分角色的目的是為了了解在應用項目實施過程中，存在哪些工作需要由什么樣知識結(jié)構(gòu)、經(jīng)驗、技能的人承擔。通常情況下，會根據(jù)項目的大小，人員的投入情況以及成員的個人能力和經(jīng)驗差異，某個人會承擔一個或多個角色。例如，某些小型項目的項目經(jīng)理可能主要的職責是管理項目開發(fā)團隊和控制項目的開發(fā)進度，而他同時可能是具有較強業(yè)務知識的業(yè)務專家，同時又具有較深的技術(shù)根底，兼任項目的開發(fā)經(jīng)理的職責。 總之，角色就象帽子，具體人與角色可以是一 對多的關(guān)系。 EOS 應用開發(fā)過程參考手冊 第 12 頁共 36 頁 . 關(guān)鍵角色 . 項目經(jīng)理 項目經(jīng)理是項目的行政領(lǐng)導，負責報告進度情況、管理預算、 籌措 人員，以及協(xié)調(diào)設(shè)備、場地、資源等。作為項目的操作者和維持者，項目經(jīng)理的工作是創(chuàng)造和維持 一個良好的環(huán)境，使項目組運行在最佳狀態(tài)。 項目經(jīng)理一般由有良好項目管理知識、具備實際項目管理經(jīng)驗，良好的協(xié)調(diào)溝通能力，較強的客戶服務意識，同時具有超凡人格魅力的人員擔任。 . 開發(fā)經(jīng)理 開發(fā)經(jīng)理又稱為技術(shù)經(jīng)理，他是應用開發(fā)過程的主要控制者 。 他在其他角色的配合之下，負責對進入條件、退出條件、項目控制點的把關(guān)。 開發(fā)經(jīng)理應當有良好的技術(shù) 功底，尤以通才為佳。 . 架構(gòu)師 他應當為項目的技術(shù)方案負責。當有風險較大的技術(shù)問題時，架構(gòu)師應成為技術(shù)課題攻關(guān)的帶頭人。 在面向構(gòu)件方法論中，架構(gòu)設(shè)計師的主要職責如下：從活動方面講，他一是需要了解現(xiàn)有構(gòu)件資產(chǎn)，二是需要設(shè)計出滿足需求（含功能需求和非功能需求）的面向構(gòu)件的應用架構(gòu)；具體而言，他應按照面向構(gòu)件的思想，將解決方案空間合理地分割成不同的構(gòu)件、確定構(gòu)件的粒度、描述構(gòu)件的接口、確定構(gòu)件之間的協(xié)作關(guān)系、并充分考慮構(gòu)件的并發(fā)和構(gòu)件的分布；從工作產(chǎn)品方法講，他必須提交架構(gòu)文檔或模型。 . 業(yè)務專家 業(yè)務專家是具備業(yè)務領(lǐng)域知識的人才，他負責輔助其他角色建立業(yè)務模型，并對最終業(yè)務模型評審把關(guān)。 在大多數(shù)情況下，擔任業(yè)務專家的人員還應該具備一定的業(yè)務建模知識，懂得如何建模的人才知道如何簡化工作。他還應具有良好的溝通技巧。 . 主程序員 主程序員負責帶領(lǐng)程序員（構(gòu)件包所有者）進行特定子系統(tǒng)的開發(fā)，他是子系統(tǒng)的應用功能設(shè)計的負責人。另外，他還輔助架構(gòu)師進行功能分解、頁面原型設(shè)計等工作。 主程序員應當是在特定子系統(tǒng)方面有豐富經(jīng)驗的高級工程師，應能夠給他的下屬以指導。 EOS 應用開發(fā)過程參考手冊 第 13 頁共 36 頁 . 構(gòu)件包所有者 構(gòu)件包所有者 負責按照項目所采用的標準 來進行構(gòu)件開發(fā)與測試，他是 構(gòu)建構(gòu)件包的程序員（我們不采用 XP 的代碼集體所有），并有義務對自己的工作成果進行單元測試。隨著產(chǎn)品生命周期的延續(xù)，構(gòu)件包所有者應當擔負其維護的責任。 EOS 應用開發(fā)過程參考手冊 第 14 頁共 36 頁 . 支持角色 . EOS 專家 EOS 專家是指精通 EOS 產(chǎn)品的技術(shù)專家，能夠為項目組提供 如下服務： ? 提供基于 EOS 的應用開發(fā)過程和項目管理方面的指導 ? 結(jié)合應用要求和 EOS 特點的 提供 應用設(shè)計 方面的咨詢和 指導 ? 幫助項目組建立結(jié)合 EOS 特點和應用要求的開發(fā)規(guī)范 ? 為應用開發(fā)中的技術(shù)課題攻關(guān)提供解決方案 或指導 ? 為開發(fā)人員提供產(chǎn)品使用的培訓和指導 ? 開發(fā) 中故障的快速定位 和處理 對于初次采用 EOS 進行項目開發(fā)的項目組， EOS 專家往往是由普元公司的服務工程師擔任，對于 已經(jīng)有 EOS 應用項目開發(fā)經(jīng)驗的項目組，由具有相關(guān)經(jīng)驗的人員擔任。 . 配置管理人員 配置管理人員負責為產(chǎn)品開發(fā)團隊提供全面的配置管理環(huán)境。他應確保配置管理環(huán)境有利于進行評審、更改和缺陷跟蹤等活動。 . 系統(tǒng)管理員 系統(tǒng)管理員負責系統(tǒng)級通知 的 發(fā)布 、 反饋意見 的收集、 系統(tǒng)性能 的及時改進 ， 還 對各類數(shù)據(jù)庫進行操作、備份恢復、導入導出，以保證系統(tǒng)正常運行，同時對其它登錄 角色 分配系統(tǒng)使用權(quán)限。系統(tǒng)管理員具有功能：信息管 理、數(shù)據(jù)管理、權(quán)限管理。 . 數(shù)據(jù)庫 DBA 數(shù)據(jù)庫管理員 (DBA)負責設(shè)計、 建立 和維護 項目 的數(shù)據(jù)庫，并保證數(shù)據(jù)庫的準確性和安全性。 EOS 應用開發(fā)過程參考手冊 第 15 頁共 36 頁 . 其他角色 . 美工 美工的職責包括： 進行網(wǎng)頁美術(shù)設(shè)計；應用程序的用戶界面 美術(shù) 設(shè)計 。對于產(chǎn)品型公司，還應負責 產(chǎn)品包裝設(shè)計及其其他相關(guān)工作。 . 測試人員 在 EOS 應用的開發(fā)中，測試人員主要進行功能測試、集成測試、系統(tǒng)測試、驗收測試、其他非功能性專項測試等，測試主要從需求規(guī)格和功能設(shè)計出發(fā)，以黑盒測試為主。 測試人員可以由獨立于項目組的測試部門工程師擔任，也可以由項目組的人員兼任，某些測試內(nèi) 容可能有用戶的人員參與。 . 文檔人員 文檔人員主要進行用戶手冊等用戶文檔的編寫和編排。對于一般中小型的應用項目，一般不需要配備專職的文檔人員，可以由測試的人員兼任。 EOS 應用開發(fā)過程參考手冊 第 16 頁共 36 頁 4. 開發(fā)過程階段描述 為保證對各個階段的描述有一個完整統(tǒng)一的描述方法，將采用 “ ETOCXM”的方法 進行，具體方式如下： ? Entry（進入條件）：為每個階段定義清晰良好的入口條件； ? Task（工作任務）：列出所有要實現(xiàn)的任務列表，名稱，是否需要實現(xiàn)，任務描述； ? 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)所需要的需求基線庫。 對于簽訂客戶合同的應用項目，需求調(diào)研 工作的地點一般在客戶的現(xiàn)場，這種情況下 ，項目組往往只確定了項目經(jīng)理和需求調(diào)研的人員 ，項目團隊還不完整。 而對于開發(fā)應用產(chǎn)品性的項目，則 應用開發(fā)過程 的 地點比較固定。 對于這兩種情況，項目團隊的管理和工作方法均有一定的差異性，而在本參考中，只提供本階段通用的工作說明，對于上面提到的差異性不做說明，需要項目組結(jié)合本參考內(nèi)容的基礎(chǔ)上充分考慮。 對于本階段的工作，如圖所示，詳細的說明，參見“工作任務”章節(jié)。 需 求 階 段項 目 管 理 工 作項 目 實 施 工 作制 定 項 目 實 施 和 管 理的 相 關(guān) 模 板評審不通過制 定 項 目 實 施 計 劃進 行 需 求 調(diào) 研編 寫 需 求 規(guī) 格迭代建 立 項 目 管 理 方 案進 行 需 求 評 審組 建 項 目 團 隊資 料 研 究 和 需 求 初 步整 理 在上圖所示的工作中，項目實施工作和項目的管理工作可以是并行的。另外， 由以上的工作內(nèi)容可以看出，實際上本階段的工作，與是否采用 EOS 是無關(guān) 的。 需求階段的主要目標是明確應用的所有功能需求和其他非功能性需求，然而這往往是一種理想的目標，實際上在進行需求調(diào)研時，配合 參與需求調(diào)研工作的用戶對于系統(tǒng)的需求并不是十分清晰，也是在討論和碰撞中不斷清晰明確的， 由此導致的需求 不穩(wěn)定性特點比較明顯，表現(xiàn)為某些需求現(xiàn)階段無法進一步細化，某些需求可能出現(xiàn)反復，某些需求現(xiàn)階段無法確定是否需要實現(xiàn)等等。 這種狀況導致無法在 人為確定的需求階段中固化所有的需求內(nèi)容，因此，對于項目組而言，在本階段所掌握的需求內(nèi)容基本充分，能夠進行后續(xù)的設(shè)計工作，或者說，所不明確的需求，不足以 影響 系統(tǒng)的結(jié)構(gòu)和目前工作的進展，那么，需求階段的目標就算是基本達到了。 另外，在需求階段，有時用戶會要求提供一個應用的原型，希望在需求討論的基礎(chǔ)上，看到系統(tǒng)實現(xiàn)的基本效果。關(guān)于原型的實現(xiàn)，我認為屬于設(shè)計的工作，將在設(shè)計