【正文】 而面向構件方 EOS 應用開發(fā)過程參考手冊 第 36 頁共 36 頁 法強調(diào)構件之間通過清晰的接口協(xié)作，通信數(shù)據(jù)又是標簽化的 XML 數(shù)據(jù)，使得構件及構件包之間的耦合度比較小。 EOS 應用開發(fā)過程參考手冊 第 34 頁共 36 頁 時間資源5%20%10%65% . 進度管理 面向構件方法論為項目管理中的進度管理提供了良好支持。 . 工作任務 . 輸出內(nèi)容 《系統(tǒng)集成測試報告》 《用戶使用手冊》 《系統(tǒng)維護手冊》 《項目驗收報告》 EOS 應用開發(fā)過程參考手冊 第 32 頁共 36 頁 . 階段控制點 協(xié)調(diào)外圍系統(tǒng)，進行集成測試 把握系統(tǒng)需求實 現(xiàn)情況，推進系統(tǒng)驗收 . 退出條件 系統(tǒng)通過用戶的驗收（初驗） 系統(tǒng)進入試運行階段。 需要說明的是，盡管列出了上述的很多工作項，在實際操作中，并不是每個工作項有人專職去做，而是 根據(jù)項目組人員的具體情況， 一人可能同時承擔多項工作，并行處理。設計的過程，是將用戶需求涉及的功能、數(shù)據(jù)、流程等業(yè)務的信息，運用業(yè)務和技術的眼光進行抽象，映射成技術實現(xiàn)內(nèi)容的過程，一方面，經(jīng)過抽象后系統(tǒng)橫向切分為不同的應用系統(tǒng)功能，從而保證這些功能即能夠覆蓋用戶的業(yè)務功能需求，又能體現(xiàn)業(yè)務模型的可擴展能力和低耦合度，另一方面，經(jīng)過抽象后的系統(tǒng) 從縱向切分為不同的層次，有利于實現(xiàn)時的分工合作，同時降低技術層次的耦合性，利于技術層面的擴展。 . 輸出內(nèi)容 《需求調(diào)研的會議紀要》 《 項目 需求規(guī)格說明書》 《項目實施總體計劃》 《項目管理方案》 《需 求變更控制表》 . 階段控制點 由于該階段是項目的啟動階段，項目團隊剛剛建立尚不完整，對于客戶而言，非常關注項目的進度計劃，對于項目組所在公司而言，在關注項目進度的同時，也關心項目的需求范圍。 最終審核通過的需求規(guī)格說明書需要獲得用戶的簽字認可（可提供一份需求認可書進行簽字）。會議結束后按照統(tǒng)一的格式整理會議紀要，發(fā)送給與會相關人員，以及得到用戶方負責人的確認（ 最好能夠簽字認可 ）。 . 進入條件 ? 確定項目經(jīng)理和需求調(diào)研人員 ? 需求工作的條件成熟：有初始的需求材料（如合同等），與用戶確定了具體的需求調(diào)研安排 . 工作任務 組建 項目 團隊 項目經(jīng)理 必須 組建項目團隊 是 項目啟動的標志，一般公司會為項目任命（或指定）項目經(jīng)理，然后由項目經(jīng)理來申請其他的團隊成員，在項目團隊組建初期，并不能明確這個項目中的所有資源，只會確定重要的角色 （如開發(fā)經(jīng)理、架構師等） 以及即將開始的需求工作的參與人員。 對于這兩種情況，項目團隊的管理和工作方法均有一定的差異性，而在本參考中，只提供本階段通用的工作說明，對于上面提到的差異性不做說明，需要項目組結合本參考內(nèi)容的基礎上充分考慮。對于產(chǎn)品型公司，還應負責 產(chǎn)品包裝設計及其其他相關工作。隨著產(chǎn)品生命周期的延續(xù)，構件包所有者應當擔負其維護的責任。 在面向構件方法論中，架構設計師的主要職責如下：從活動方面講，他一是需要了解現(xiàn)有構件資產(chǎn)，二是需要設計出滿足需求（含功能需求和非功能需求）的面向構件的應用架構；具體而言，他應按照面向構件的思想，將解決方案空間合理地分割成不同的構件、確定構件的粒度、描述構件的接口、確定構件之間的協(xié)作關系、并充分考慮構件的并發(fā)和構件的分布；從工作產(chǎn)品方法講，他必須提交架構文檔或模型。 EOS 應用開發(fā)過程參考手冊 第 12 頁共 36 頁 . 關鍵角色 . 項目經(jīng)理 項目經(jīng)理是項目的行政領導，負責報告進度情況、管理預算、 籌措 人員，以及協(xié)調(diào)設備、場地、資源等。 EOS 應用開發(fā)過程參考手冊 第 11 頁共 36 頁 3. EOS 應用開發(fā)的角色 . 理解角色 項目是由人、過程和技術組成的，但是迄今為止，最重要的因素是人。 ? 測試：針對實現(xiàn)的應用進行系統(tǒng)良好性的驗證，可能包含的測試工作如：功能測試、系統(tǒng)測試、集成測試、性能測試等。 EOS Server EOS 運行引引擎 ,負責在調(diào)試及運行期間對構件進行執(zhí)行和管理 。 EOS Package 是 EOS 系統(tǒng)發(fā)布、復用的基本單位，它由一組相關的 EOS構件組成，能夠完成相對獨立、完整的業(yè)務功能。 本出版物包含 Primeton 的專利信息，它在許可協(xié)議下提供，并受版權法保護，本出版物包含的信息不包括任何產(chǎn)品保證。 . 目標讀者 本手冊的目標讀者為采用 EOS 產(chǎn)品進行應用開發(fā)的 所有 項目組成員，具體角色包括項目經(jīng)理、 開發(fā)經(jīng)理 、 架構 師、 業(yè)務專家、開發(fā)人員 、測試人員等。 EOS Runtime Environment EOS 運行和管理環(huán)境是一個獨立的 EOS 應用程序，可以部署在一個獨立的 EOS Server 上，集中管理（包括部署、監(jiān)控，察看日志等）位于不同的物理機器上的 EOS 應用程序；也可以在每臺 EOS Server 上都部署一個 EOS Manager 來實現(xiàn)分散式部署與管理，即只管理本 EOS EOS 應用開發(fā)過程參考手冊 第 7 頁共 36 頁 Server 上的 EOS 應用程序。需求規(guī)格需明確功能需求、質(zhì)量屬性、約束條件等需求的所有方面。需要關注的是相關的工作是否串行和對其他工作是否存在依賴型。通常情況下，會根據(jù)項目的大小，人員的投入情況以及成員的個人能力和經(jīng)驗差異，某個人會承擔一個或多個角色。 開發(fā)經(jīng)理應當有良好的技術 功底，尤以通才為佳。另外，他還輔助架構師進行功能分解、頁面原型設計等工作。系統(tǒng)管理員具有功能：信息管 理、數(shù)據(jù)管理、權限管理。 EOS 應用開發(fā)過程參考手冊 第 16 頁共 36 頁 4. 開發(fā)過程階段描述 為保證對各個階段的描述有一個完整統(tǒng)一的描述方法，將采用 “ ETOCXM”的方法 進行，具體方式如下： ? Entry（進入條件）：為每個階段定義清晰良好的入口條件； ? Task（工作任務）：列出所有要實現(xiàn)的任務列表，名稱，是否需要實現(xiàn)，任務描述； ? Output（輸出內(nèi)容） ： 階段工作的輸出產(chǎn)物以及評審內(nèi)容 ； ? Control Point（ 階段 控制點） ：本階段中為保證項目成功的關鍵控制點 ； ? eXit（退出條件） ：階段結束時所要達到的結果 ，注意，階段退出條件并不意味下一階段進入條件，因為下一階段可能在上一階段并未結束的情況下就已經(jīng)啟動了； ? Template（參考模板）： 本階段可供參考的文檔模板或參考案例 . 需求階段 . 概述 本階段是應用項目的啟動階段 ， 它主要完成應用系統(tǒng)需求的采集整理工作，形成系統(tǒng)設 EOS 應用開發(fā)過程參考手冊 第 17 頁共 36 頁 計和實現(xiàn)所需要的需求基線庫。 這種狀況導致無法在 人為確定的需求階段中固化所有的需求內(nèi)容，因此，對于項目組而言，在本階段所掌握的需求內(nèi)容基本充分，能夠進行后續(xù)的設計工作，或者說，所不明確的需求，不足以 影響 系統(tǒng)的結構和目前工作的進展，那么，需求階段的目標就算是基本達到了。 進行需求調(diào)研 需求調(diào)研人員 必須 需求調(diào)研人員 在用戶確認后進入到調(diào)研現(xiàn)場， 由項目經(jīng)理負責組織與用戶的需求調(diào)研工作。 以上兩個工作在需求調(diào)研的過程中是迭代進行的，直到項目組認為需求基本明確，或者主要需求明確，能夠進行后續(xù)的 工作。 也有助于新進入項目的成員盡快進入工 作角色。 EOS 應用開發(fā)過程參考手冊 第 21 頁共 36 頁 . 退出條件 《項目需求規(guī)格說明書》獲得用戶簽字認可。 對于 EOS 應用的設計 內(nèi)容 ，主要的重心在于業(yè)務模型的抽象（可理解為業(yè)務架構）、構件包的劃分以及功能點的細分， 這樣讓設計人員能夠從考慮技術架構 和 OO 模 型 的穩(wěn)定、優(yōu)雅和是否符合力學原理的泥沼中解脫出來，將主要的精力花費在考慮業(yè)務模型的抽象和擴展能力上 （也有助于設計人員從技術思維轉(zhuǎn)向業(yè)務思維，或許我這種說法對于熱衷于技術研究的設計師會不以為然，但 如果設計師跟用戶溝通時如果屢屢提及對象、設計模式等詞眼未必能讓用戶對于系統(tǒng)的設計思路有多清晰的理解 ） 。 對于項目組而言，本階段的主要控制點包括： ? 確保 系統(tǒng)設計的質(zhì)量 ： 對于良好的系統(tǒng)設計，應該滿足如下要求： 1） 應用總體設計思路清晰，結構簡捷合理 2） 功能設計可實現(xiàn)性強：通過查看原型、對應的數(shù)據(jù)庫設計和功能設計文檔， 功能 實現(xiàn)者 （開發(fā)人員） 比較清楚用戶界面的信息、對應操作的數(shù)據(jù)實體、應用處理的流程、相關的隱含規(guī)則 、界面流轉(zhuǎn)關系等等 3） 完整統(tǒng)一、操作性強的項目開發(fā)規(guī)范 ：這是保證項目滿足非功能性需求和系統(tǒng)質(zhì)量的重要工具 ，需要確保開發(fā)規(guī)范的內(nèi)容盡可能覆蓋項目實施的各個環(huán)節(jié)，同時所提供的規(guī)范內(nèi)容具有較強的操作性，而不至于流于形式。這樣做的重大好處之一是“有利于和外部團隊協(xié)同”，當項目開發(fā)任何涉及外包子系統(tǒng)時非常易于管理；另外，很常見的情況是需求和總體設計由最終 客戶和中間件廠商共同完成，而后期工作由最終用戶的開發(fā)人員進行，此時，“動態(tài)團隊”的靈活性就十分明顯。 開發(fā)者的考核，可以通過其負責的所有構件的完成進度統(tǒng)計而來。 重要說明 ：并行開發(fā)和迭代開發(fā)可以綜合實施，具體方法是，宏觀上進行迭代和增量開發(fā)，而每個迭代周期內(nèi)部，不同團隊成員并行工作。面向構件方法論主張通過評審、走查、測試等確認活動來決定構件的完成進度，下面進行詳細闡述。項目經(jīng)理的職責之一是“管人”。 . 工作任務 制定項目階段計劃 項目經(jīng)理 必須 項目經(jīng)理 通過 階段 工作計劃確定本階段 的 工作 目標和 內(nèi)容，以及人力 計劃 ，時間計劃，里程碑的設置等。 在采用 EOS 實現(xiàn) J2EE 應用時， 由于 EOS 已經(jīng)提供了一套完整的應用軟件框架，使得在設計階段無需考慮應用架構的問題，同時也不用考慮業(yè)務模型與 java 對象抽象的工作。 ? 項目資源的協(xié)調(diào)： 在本階段，將會確定項目實施的總體計劃，保證計劃能得以正常執(zhí)行的前提是有效的資源保障。 制定的總體計劃需要獲得用戶和本公司項目主管領導的認可，這樣才能便于用于的工作協(xié)調(diào)和配合，以及公司的資源調(diào)配。 需求規(guī)格包括了應用系統(tǒng)的功能需求 、非功能性的需求，以及需求調(diào)研 形成的數(shù)據(jù)字典 和公共詞匯 。有時甚至會有一個對等的用戶項目組參與項目（主要承擔配合、監(jiān)控、質(zhì)保等職能），項目團隊同樣包括這些人。另外， 由以上的工作內(nèi)容可以看出，實際上本階段的工作，與是否采用 EOS 是無關 的。 . 文檔人員 文檔人員主要進行用戶手冊等用戶文檔的編寫和編排。他應確保配置管理環(huán)境有利于進行評審、更改和缺陷跟蹤等活動。他還應具有良好的溝通技巧。 . 開發(fā)經(jīng)理 開發(fā)經(jīng)理又稱為技術經(jīng)理，他是應用開發(fā)過程的主要控制者 。以下將分關鍵角色、支持角色和額外角色分別進行說明。實際上，各個階段在不同的應用項目中，不同程度存在一定階段重合（并行）或者迭代現(xiàn)象。 . 配套文檔 項目實施過程模板： 《項目需求規(guī)格說明書》 《項目系統(tǒng)設計說明書》 《應用系統(tǒng)測試方案》