【導讀】上海普元信息技術有限責任公司。本手冊為基于普元EOS產(chǎn)品進行應用的項目組提供了應用開發(fā)過程的參照性指導文。檔，以幫助EOS的用戶更加細致了解基于EOS開發(fā)企業(yè)應用的過程。本出版物包含Primeton的專利信息，它在許可協(xié)議下提供，并受版權法保護，本出版物包。含的信息不包括任何產(chǎn)品保證。通過您當?shù)氐腜rimeton代表或分部可訂購出版物，或致電021-50805188訂購出版物。當您發(fā)送信息給Primeton后，即授予Primeton非專有權，Primeton對于您所提供的任何。信息，有權利以任何它認為適當?shù)姆绞绞褂没蛏l(fā)，而不必對您負任何責任。您可能會發(fā)現(xiàn)下列資料對您有用：。本書對文本格式的使用有如下約定：。序號版本號修訂日期修訂概述修訂人審批人職位日期。020．22020-09-29并行增補溫昱

　　

【正文】 合 EOS產(chǎn)品的 特點進行考慮。 . 進入條件 ? 已掌握應用項目的基線性需求，即使存在部分不確定的需求，但該部分飄浮不定的需求不足以 對應用架構產(chǎn)生大的影響 ； ? 設計人員到位 ，使得工作的開展有 人 力的保障 。 . 工作任務 制定項目階段計劃 項目經(jīng)理 必須 項目經(jīng)理 通過 階段 工作計劃確定本階段 的 工作 目標和 內(nèi)容，以及人力 計劃 ，時間計劃，里程碑的設置等。 系統(tǒng)總體設計 系統(tǒng)架構師 、開發(fā)經(jīng)理 必須 數(shù)據(jù)庫設計 業(yè)務建模人員 必須 頁面框架設計 開發(fā)經(jīng)理、架構師、美工 必須 系統(tǒng)功能分 解 開發(fā)經(jīng)理、架構師、主程序員 必須 EOS 應用開發(fā)過程參考手冊 第 24 頁共 36 頁 功能設計任務分配 項目經(jīng)理、開發(fā)經(jīng)理 必須 頁面原型設計 主程序員 可選 應用功能設計 主程序員 必須 制定項目開發(fā)規(guī)范 開發(fā)經(jīng)理、架構師 必須 開發(fā)環(huán)境準備 開發(fā)經(jīng)理 必須 開發(fā)人員分析設計人員模板管理頁面布局模板CSS 樣式模板控件模板功能模板模板管理頁面布局模板樣式模板控件模板功能模板導出模板分發(fā)模板數(shù)據(jù)實體設計 導入模板頁面向?qū)гO計視圖源代碼視圖設計視圖源代碼視圖頁面調(diào)試業(yè)務構件開發(fā)展現(xiàn)構件開發(fā)業(yè)務構件開發(fā)展現(xiàn)構件開發(fā)構件調(diào)試 技術課題攻關 架構師 可選 制定和實施配置管理方案 開發(fā)經(jīng)理、配置管理人員 可選 從本階段開始，項目組的人員規(guī)模在不斷擴大，工作的產(chǎn)物也越來越多，為確保項目組工作成果的管理和共享， EOS 應用開發(fā)過程參考手冊 第 25 頁共 36 頁 組織設計評審 項目經(jīng)理 必須 . 輸出內(nèi) 容 ? 數(shù)據(jù)庫設計（ ER 關系）、業(yè)務字典定義 ? 系統(tǒng)靜態(tài)原型 ? 系統(tǒng)設計說明書 ? 系統(tǒng)功能分解矩陣 ? 經(jīng)過項目客戶化后的 EOS 模板文件 ? 項目配置管理方案 ? 技術課題預研的結論或者使用指南 ? EOS 初始項目 源碼 . 階段控制點 設計階段是系統(tǒng)實施的重要階段，設計的完整性和合理性直接決定了系統(tǒng)的擴展能力、易用性、和系統(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)容具有較強的操作性，而不至于流于形式。 ? 有效合理的 需求變更控制： 在本階段，需求階段所遺留的不穩(wěn)定需求對本階段會有較大的影響，一方面需要花費時間來討論這部分需求導致設計階段進度延誤，另一方面需求的變更可能會導致系統(tǒng)設計的變化，因此，項目經(jīng)理和 有經(jīng)驗的設計人員要充分評估這些變更對項目的影響，對于可能影響項目進展而需求重要程度較低的變更，項目經(jīng)理要懂得讓用戶放棄這種變更或者采用雙方可接受的變更方式。 . 退出條件 ? 系統(tǒng)設計工作內(nèi)容 通過 評審 EOS 應用開發(fā)過程參考手冊 第 26 頁共 36 頁 . 參考模板 ? 《系統(tǒng)設計說明書》 ? 系統(tǒng)靜態(tài)原型 ? 功能分解矩陣 . 開發(fā)階段 . 概述 本階段是應用項目的啟動階段 EOS 應用開發(fā)過程參考手冊 第 27 頁共 36 頁 開 發(fā) 階 段項 目 管 理 工 作項 目 實 施 工 作單 元 測 試功 能 實 現(xiàn)（ 構 件 開 發(fā) ）項 目 進 度 跟 蹤提 交 開 發(fā) 結 果迭代制 定 項 目 階 段 計 劃應 用 功 能 開 發(fā)任 務 分 配構件實現(xiàn)走查 . 進入條件 . 工作任務 EOS 應用開發(fā)過程參考手冊 第 28 頁共 36 頁 . 輸出內(nèi)容 項目源碼 項目 實現(xiàn)的 文檔（ EOS Studio 產(chǎn)生 ） . 階段控制點 需求變更的嚴格控制 . 退出條件 . 參考模板 . 測試階 段 . 概述 本階段是應用項目的啟動階段 EOS 應用開發(fā)過程參考手冊 第 29 頁共 36 頁 測 試 階 段項 目 管 理 工 作項 目 實 施 工 作測 試 結 果 記 錄編 寫 測 試 用 例迭代編 寫 測 試 報 告系 統(tǒng) 測 試制 定 項 目 階 段 計 劃應 用 功 能 開 發(fā)任 務 分 配編 寫 測 試 方 案測 試 進 度 跟 蹤編寫用戶手冊測 試 環(huán) 境 準 備 . 進入條件 EOS 應用開發(fā)過程參考手冊 第 30 頁共 36 頁 . 工作任務 . 輸出內(nèi)容 . 階段控制點 . 退出條件 . 參考模板 . 集成、部署階段 . 概述 本階段是應用項目的啟動階段 EOS 應用開發(fā)過程參考手冊 第 31 頁共 36 頁 集 成 、 部 署 階 段項 目 管 理 工 作項 目 實 施 工 作制 定 系 統(tǒng) 集 成 上 線階 段 計 劃編 寫 用 戶 文 檔項 目 驗 收系 統(tǒng) 上 線系 統(tǒng) 部 署 和 集成 測 試進 行 用 戶 培 訓 . 進入條件 系統(tǒng)經(jīng)過內(nèi)部的測試，具備在用戶環(huán)境進行部署和進行集成測試的條件。 . 工作任務 . 輸出內(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)進入試運行階段。 . 參考模板 EOS 應用開發(fā)過程參考手冊 第 33 頁共 36 頁 5. 其他 最佳實踐 待項目組已經(jīng)適應了面向構件的軟件開發(fā)，可進一步采納更多體現(xiàn)普元公司多年經(jīng)驗的最佳實踐，使項目管理和生產(chǎn)力水平更上一層樓。 . 人員 管理 項目經(jīng)理是開發(fā)團隊中特殊的角色，他需要掌握的技能和大多數(shù)人不同。項目經(jīng)理的職責之一是“管人”。 面向構件項目的團隊組織，建議是動態(tài)性的。這樣做的重大好處之一是“有利于和外部團隊協(xié)同”，當項目開發(fā)任何涉及外包子系統(tǒng)時非常易于管理；另外，很常見的情況是需求和總體設計由最終 客戶和中間件廠商共同完成，而后期工作由最終用戶的開發(fā)人員進行，此時，“動態(tài)團隊”的靈活性就十分明顯。 移交構造細化初始定位組 架構組開發(fā)組原型開發(fā)組開發(fā)組開發(fā)組開發(fā)組開發(fā)組 總的來說，資源的投入應該本著風險驅(qū)動的原則：在目標為明確之前，僅投入 5％的工作量；在架構和主要技術風險明確之前，再投入 20％工作量。待所有高風險因素明確之后，全面將工作鋪開，投入項目組所有人力資源。 EOS 應用開發(fā)過程參考手冊 第 34 頁共 36 頁 時間資源5%20%10%65% . 進度管理 面向構件方法論為項目管理中的進度管理提供了良好支持。任務的分配以構件為單位，每個構件都會分配到具體的開發(fā)者。 傳統(tǒng)項目管理中，進度的度量往往靠主觀估計，很不科學。面向構件方法論主張通過評審、走查、測試等確認活動來決定構件的完成進度，下面進行詳細闡述。 構件包的進度，由其包含的所有構件的完成進度統(tǒng)計而得。 開發(fā)者的考核，可以通過其負責的所有構件的完成進度統(tǒng)計而來。 { plete }構件構件包開發(fā)者構件進度已設計（3 0 % ）已實現(xiàn)（7 0 % ）已走查（8 0 % ）已測試（1 0 0 % ）Next Next Next構件包進度1*負責開發(fā)者進度1*1 1* * EOS 應用開發(fā)過程參考手冊 第 35 頁共 36 頁 下圖為構件進度的狀態(tài)轉(zhuǎn)換圖，其中每個狀態(tài)的步進都有評審、提交、走查、測試等顯示的確認活動作為基礎，增加了度量的科學性。 已分配到人（0 % ）已設計（3 0 % ）已實現(xiàn)（7 0 % ）已走查（8 0 % ）已測試（1 0 0 % ）[通 過設計評審][實 現(xiàn)完畢提交CVS ][未 通過][未 通過][走 查通過嗎][測 試通過嗎][通 過][通 過] . 并行開發(fā) 并行開發(fā)為什么很難呢？因為團隊成員的工作之間有依賴關系！ 本質(zhì)上，團隊成員之間的依賴關系是軟件組成部分之間依賴關系的體現(xiàn)。而面向構件方 EOS 應用開發(fā)過程參考手冊 第 36 頁共 36 頁 法強調(diào)構件之間通過清晰的接口協(xié)作，通信數(shù)據(jù)又是標簽化的 XML 數(shù)據(jù)，使得構件及構件包之間的耦合度比較小。架構中的接口，成為不同的團隊成員之間協(xié)作的“契約”，可以支持大規(guī)模并行式的團隊開發(fā) —— 架構設計得越穩(wěn)定、越明確，并行的程度就可以越大。 面向構件方法從本質(zhì)上強調(diào)架構的松耦合品質(zhì)和構件的獨立性，所以，可以支持非?？捎^的并行開發(fā)。 重要說明 ：并行開發(fā)和迭代開發(fā)可以綜合實施，具體方法是，宏觀上進行迭代和增量開發(fā)，而每個迭代周期內(nèi)部，不同團隊成員并行工作。 需求架構功能測試（其他測試）設計構件實現(xiàn)構件（單元測試）組裝構件發(fā)布并行開發(fā)計劃設計構件實現(xiàn)構件（單元測試）????