EOS應(yīng)用開發(fā)過程參考手冊_v2.0.doc

EOS應(yīng)用開發(fā)過程參考手冊PRIMETON TECHNOLOGIES, LTD.上海普元信息技術(shù)有限責(zé)任公司EOS應(yīng)用開發(fā)過程參考手冊For EOS 5.xNo part of this document may be reproduced, stored in any electronic retrieval system, or transmitted in any form or by any means, mechanical, photocopying, recording, otherwise, without the written permission of the copyright owner.COPYRIGHT 2005 by Primeton Technologies, Ltd. ALL RIGHTS RESERVED./ 第36頁共36頁歡迎使用本手冊為基于普元EOS產(chǎn)品進行應(yīng)用的項目組提供了應(yīng)用開發(fā)過程的參照性指導(dǎo)文檔，以幫助EOS的用戶更加細致了解基于EOS開發(fā)企業(yè)應(yīng)用的過程。本出版物包含Primeton的專利信息，它在許可協(xié)議下提供，并受版權(quán)法保護，本出版物包含的信息不包括任何產(chǎn)品保證。通過您當(dāng)?shù)氐腜rimeton代表或分部可訂購出版物，或致購出版物當(dāng)您發(fā)送信息給Primeton后，即授予Primeton非專有權(quán)，Primeton對于您所提供的任何信息，有權(quán)利以任何它認為適當(dāng)?shù)姆绞绞褂没蛏l(fā)，而不必對您負任何責(zé)任 COPYRIGHT 2005 by Primeton Technologies, Ltd. ALL RIGHTS RESERVED.本書的相關(guān)文檔您可能會發(fā)現(xiàn)下列資料對您有用：格式使用約定本書對文本格式的使用有如下約定：粗體： 表示突出顯示，或可視化操作中的文字【*】 可視化操作中的選項 文檔修訂和審批記錄序號版本號修訂日期修訂概述修訂人審批人職位日期01012005-09-26初稿袁義02022005-09-29并行增補溫昱目 錄1. 引言61.1. 目的61.2. 目標讀者61.3. 術(shù)語與縮寫61.4. 配套文檔71.5. 參考資料71.6. 其余部分的結(jié)構(gòu)82. EOS應(yīng)用開發(fā)過程93. EOS應(yīng)用開發(fā)的角色113.1. 理解角色113.2. 關(guān)鍵角色123.2.1. 項目經(jīng)理123.2.2. 開發(fā)經(jīng)理123.2.3. 架構(gòu)師123.2.4. 業(yè)務(wù)專家123.2.5. 主程序員123.2.6. 構(gòu)件包所有者133.3. 支持角色143.3.1. EOS專家143.3.2. 配置管理人員143.3.3. 系統(tǒng)管理員143.3.4. 數(shù)據(jù)庫DBA143.4. 其他角色153.4.1. 美工153.4.2. 測試人員153.4.3. 文檔人員154. 開發(fā)過程階段描述164.1. 需求階段164.1.1. 概述164.1.2. 進入條件184.1.3. 工作任務(wù)184.1.4. 輸出內(nèi)容204.1.5. 階段控制點204.1.6. 退出條件214.1.7. 參考模板214.2. 設(shè)計階段214.2.1. 概述214.2.2. 進入條件234.2.3. 工作任務(wù)234.2.4. 輸出內(nèi)容254.2.5. 階段控制點254.2.6. 退出條件254.2.7. 參考模板264.3. 開發(fā)階段264.3.1. 概述264.3.2. 進入條件274.3.3. 工作任務(wù)274.3.4. 輸出內(nèi)容284.3.5. 階段控制點284.3.6. 退出條件284.3.7. 參考模板284.4. 測試階段284.4.1. 概述284.4.2. 進入條件294.4.3. 工作任務(wù)304.4.4. 輸出內(nèi)容304.4.5. 階段控制點304.4.6. 退出條件304.4.7. 參考模板304.5. 集成、部署階段304.5.1. 概述304.5.2. 進入條件314.5.3. 工作任務(wù)314.5.4. 輸出內(nèi)容314.5.5. 階段控制點324.5.6. 退出條件324.5.7. 參考模板325. 其他最佳實踐335.1. 人員管理335.2. 進度管理345.3. 并行開發(fā)351. 引言1.1. 目的本手冊旨在為基于EOS產(chǎn)品的項目實施提供開發(fā)過程的參考。本手冊匯集了普元公司多年卓有成效的項目規(guī)劃、實施和上線的最佳實踐，建議基于EOS的項目采用。當(dāng)然，這并不意味著本文檔所描述的方式是EOS應(yīng)用開發(fā)的唯一方法。1.2. 目標讀者本手冊的目標讀者為采用EOS 5.x產(chǎn)品進行應(yīng)用開發(fā)的所有項目組成員，具體角色包括項目經(jīng)理、開發(fā)經(jīng)理、架構(gòu)師、業(yè)務(wù)專家、開發(fā)人員、測試人員等。1.3. 術(shù)語與縮寫EOS普元公司的核心產(chǎn)品名稱，是面向構(gòu)件的應(yīng)用軟件平臺。EOS ComponentEOS提供了一個包括頁面，展現(xiàn)邏輯，業(yè)務(wù)流程，業(yè)務(wù)邏輯，業(yè)務(wù)方法，數(shù)據(jù)邏輯等六種構(gòu)件。EOS Package是EOS系統(tǒng)發(fā)布、復(fù)用的基本單位，它由一組相關(guān)的EOS構(gòu)件組成，能夠完成相對獨立、完整的業(yè)務(wù)功能。EOS構(gòu)件包中可以包含一個或多個的EOS構(gòu)件在EOS應(yīng)用中，它相當(dāng)于一組有關(guān)系的構(gòu)件的容器或命名空間(Namespace)。同一個構(gòu)件包的構(gòu)件不能重名。EOS平臺對構(gòu)件的調(diào)用也是首先通過包名來定位構(gòu)件所在的包。EOS Application基于EOS產(chǎn)品所開發(fā)的應(yīng)用系統(tǒng) 。EOS Runtime EnvironmentEOS運行和管理環(huán)境是一個獨立的EOS應(yīng)用程序，可以部署在一個獨立的EOS Server上，集中管理（包括部署、監(jiān)控，察看日志等）位于不同的物理機器上的EOS 應(yīng)用程序；也可以在每臺EOS Server上都部署一個EOS Manager來實現(xiàn)分散式部署與管理，即只管理本 EOS Server上的EOS應(yīng)用程序。EOS Development Environment普元EOS開發(fā)環(huán)境中包括EOS Studio（集成開發(fā)環(huán)境）、EOS Server（運行/調(diào)試服務(wù)器）、版本控制庫三部分組成。EOS Studio為用戶提供基于向?qū)У膽?yīng)用開發(fā)環(huán)境，包括數(shù)據(jù)構(gòu)件定義、業(yè)務(wù)邏輯開發(fā)、展現(xiàn)邏輯開發(fā)、業(yè)務(wù)流程開發(fā)、JSP頁面開發(fā)、Bizlet開發(fā)、調(diào)試、應(yīng)用部署。EOS ServerEOS運行引引擎,負責(zé)在調(diào)試及運行期間對構(gòu)件進行執(zhí)行和管理。XML Data Bus作為EOS平臺的一個特性，EOS的各種構(gòu)件通過XML數(shù)據(jù)總線進行相關(guān)數(shù)據(jù)的交互，從而以數(shù)據(jù)流的方式來推動業(yè)務(wù)的進行。EOS的XML數(shù)據(jù)總線包含展現(xiàn)數(shù)據(jù)總線和業(yè)務(wù)數(shù)據(jù)總線。1.4. 配套文檔項目實施過程模板：項目需求規(guī)格說明書項目系統(tǒng)設(shè)計說明書應(yīng)用系統(tǒng)測試方案應(yīng)用系統(tǒng)測試報告應(yīng)用系統(tǒng)用戶使用手冊應(yīng)用系統(tǒng)維護手冊項目管理模板項目工作周報會議紀要項目評審報告項目驗收報告1.5. 參考資料標題版本日期來源普元構(gòu)件規(guī)范0.82005-9-15EOS6定位組1.6. 其余部分的結(jié)構(gòu)本文檔的其余部分，將依次闡述下列內(nèi)容：u EOS應(yīng)用開發(fā)過程u EOS應(yīng)用開發(fā)的角色u 開發(fā)過程階段描述u 其他最佳實踐2. EOS應(yīng)用開發(fā)過程EOS應(yīng)用是典型的J2EE企業(yè)應(yīng)用，所以EOS應(yīng)用的開發(fā)過程將以J2EE企業(yè)應(yīng)用開發(fā)過程為參照并結(jié)合EOS的特點進行說明。一般而言，對于J2EE的企業(yè)級應(yīng)用的開發(fā)，可以劃分為如下內(nèi)容：l 需求： 明確軟件開發(fā)的任務(wù)，形成所有相關(guān)涉眾（如客戶、用戶、項目組）共同認可的軟件需求規(guī)格。需求規(guī)格需明確功能需求、質(zhì)量屬性、約束條件等需求的所有方面。l 設(shè)計：針對需求進行分析設(shè)計，形成項目組的設(shè)計說明書和功能清單。l 開發(fā)：在設(shè)計說明的指導(dǎo)下完成應(yīng)用的實現(xiàn)。l 測試：針對實現(xiàn)的應(yīng)用進行系統(tǒng)良好性的驗證，可能包含的測試工作如：功能測試、系統(tǒng)測試、集成測試、性能測試等。l 集成、部署：主要完成系統(tǒng)在用戶環(huán)境中上線，并通過用戶培訓(xùn)，將應(yīng)用系統(tǒng)交付用戶使用。 應(yīng)用開發(fā)中，針對以上工作，一般都劃分為一個獨立階段，然而，各個階段僅僅表明一個工作的重心和職能以及階段間的順序，并不代表著各個階段的工作是串行的。實際上，各個階段在不同的應(yīng)用項目中，不同程度存在一定階段重合（并行）或者迭代現(xiàn)象。如下圖：對應(yīng)用開發(fā)過程進行階段劃分的主要目標還是便于界定各個階段的主要工作內(nèi)容，而不在乎你是否把屬于該階段的工作放到上一階段中，或者干脆將某兩個階段合并為一個階段。需要關(guān)注的是相關(guān)的工作是否串行和對其他工作是否存在依賴型。對于開發(fā)過程的描述，除了與應(yīng)用開發(fā)和項目實施密切相關(guān)的工作內(nèi)容以外，還將包括保障項目實施的各種項目管理方法和手段。另外，在對各個階段的工作進行描述之前，先對EOS應(yīng)用開發(fā)過程中涉及的各種角色進行簡單的說明。3. EOS應(yīng)用開發(fā)的角色3.1. 理解角色項目是由人、過程和技術(shù)組成的，但是迄今為止，最重要的因素是人。試圖用過程或技術(shù)取代人的做法是愚蠢的，因為技術(shù)也好，過程也好，沒有項目組人員的支持和參與，就不會發(fā)揮出相應(yīng)的作用。在EOS項目中，對于項目成員角色的定義與其他的J2EE項目的角色定義幾乎是一致的，只是在某些角色的職責(zé)方面有一定的差異。以下將分關(guān)鍵角色、支持角色和額外角色分別進行說明。另外，需要強調(diào)的是，角色代表著項目組的一種職責(zé)，并不意味著不同角色都必須由不同的人分別承擔(dān)，細分角色的目的是為了了解在應(yīng)用項目實施過程中，存在哪些工作需要由什么樣知識結(jié)構(gòu)、經(jīng)驗、技能的人承擔(dān)。通常情況下，會根據(jù)項目的大小，人員的投入情況以及成員的個人能力和經(jīng)驗差異，某個人會承擔(dān)一個或多個角色。例如，某些小型項目的項目經(jīng)理可能主要的職責(zé)是管理項目開發(fā)團隊和控制項目的開發(fā)進度，而他同時可能是具有較強業(yè)務(wù)知識的業(yè)務(wù)專家，同時又具有較深的技術(shù)根底，兼任項目的開發(fā)經(jīng)理的職責(zé)。總之，角色就象帽子，具體人與角色可以是一對多的關(guān)系。3.2. 關(guān)鍵角色3.2.1. 項目經(jīng)理項目經(jīng)理是項目的行政領(lǐng)導(dǎo)，負責(zé)報告進度情況、管理預(yù)算、籌措人員，以及協(xié)調(diào)設(shè)備、場地、資源等。作為項目的操作者和維持者，項目經(jīng)理的工作是創(chuàng)造和維持一個良好的環(huán)境，使項目組運行在最佳狀態(tài)。項目經(jīng)理一般由有良好項目管理知識、具備實際項目管理經(jīng)驗，良好的協(xié)調(diào)溝通能力，較強的客戶服務(wù)意識，同時具有超凡人格魅力的人員擔(dān)任。3.2.2. 開發(fā)經(jīng)理開發(fā)經(jīng)理又稱為技術(shù)經(jīng)理，他是應(yīng)用開發(fā)過程的主要控制者。他在其他角色的配合之下，負責(zé)對進入條件、退出條件、項目控制點的把關(guān)。開發(fā)經(jīng)理應(yīng)當(dāng)有良好的技術(shù)功底，尤以通才為佳。3.2.3. 架構(gòu)師他應(yīng)當(dāng)為項目的技術(shù)方案負責(zé)。當(dāng)有風(fēng)險較大的技術(shù)問題時，架構(gòu)師應(yīng)成為技術(shù)課題攻關(guān)的帶頭人。在面向構(gòu)件方法論中，架構(gòu)設(shè)計師的主要職責(zé)如下：從活動方面講，他一是需要了解現(xiàn)有構(gòu)件資產(chǎn)，二是需要設(shè)計出滿足需求（含功能需求和非功能需求）的面向構(gòu)件的應(yīng)用架構(gòu)；具體而言，他應(yīng)按照面向構(gòu)件的思想，將解決方案空間合理地分割成不同的構(gòu)件、確定構(gòu)件的粒度、描述構(gòu)件的接口、確定構(gòu)件之間的協(xié)作關(guān)系、并充分考慮構(gòu)件的并發(fā)和構(gòu)件的分布；從工作產(chǎn)品方法講，他必須提交架構(gòu)文檔或模型。3.2.4. 業(yè)務(wù)專家業(yè)務(wù)專家是具備業(yè)務(wù)領(lǐng)域知識的人才，他負責(zé)輔助其他角色建立業(yè)務(wù)模型，并對最終業(yè)務(wù)模型評審把關(guān)。在大多數(shù)情況下，擔(dān)任業(yè)務(wù)專家的人員還應(yīng)該具備一定的業(yè)務(wù)建模知識，懂得如何建模的人才知道如何簡化工作。他還應(yīng)具有良好的溝通技巧。3.2.5. 主程序員主程序員負責(zé)帶領(lǐng)程序員（構(gòu)件包所有者）進行特定子系統(tǒng)的開發(fā)，他是子系統(tǒng)的應(yīng)用功能設(shè)計的負責(zé)人。另外，他還輔助架構(gòu)師進行功能分解、頁面原型設(shè)計等工作。主程序員應(yīng)當(dāng)是在特定子系統(tǒng)方面有豐富經(jīng)驗的高級工程師，應(yīng)能夠給他的下屬以指導(dǎo)。3.2.6. 構(gòu)件包所有者構(gòu)件包所有者負責(zé)按照項目所采用的標準來進行構(gòu)件開發(fā)與測試，他是構(gòu)建構(gòu)件包的程序員（我們不采用XP的代碼集體所有），并有義務(wù)對自己的工作成果進行單元測試。隨著產(chǎn)品生命周期的延續(xù)，構(gòu)件包所有者應(yīng)當(dāng)擔(dān)負其維護的責(zé)任。3.3. 支持角色3.3.1. EOS專家EOS專家是指精通EOS產(chǎn)品的技術(shù)專家，能夠為項目組提供如下服務(wù)：n 提供基于EOS的應(yīng)用開發(fā)過程和項目管理方面的指導(dǎo)n 結(jié)合應(yīng)用要求和EOS特點的提供應(yīng)用設(shè)計方面的咨詢和指導(dǎo)n 幫助項目組建立結(jié)合EOS特點和應(yīng)用要求的開發(fā)規(guī)范n 為應(yīng)用開發(fā)中的技術(shù)課題攻關(guān)提供解決方案或指導(dǎo)n 為開發(fā)人員提供產(chǎn)品使用的培訓(xùn)和指導(dǎo)n 開發(fā)中故障的快速定位和處理對于初次采用EOS進行項目開發(fā)的項目組，EOS專家往往是由普元公司的服務(wù)工程師擔(dān)任，對于已經(jīng)有EOS應(yīng)用項目開發(fā)經(jīng)驗的項目組，由具有相關(guān)經(jīng)驗的人員擔(dān)任。3.3.2. 配置管理人員配置管理人員負責(zé)為產(chǎn)品開發(fā)團隊提供全面的配置管理環(huán)境。他應(yīng)確保配置管理環(huán)境有利于進行評審、更改和缺陷跟蹤等活動。3.3.3. 系統(tǒng)管理員系統(tǒng)管理員負責(zé)系統(tǒng)級通知的發(fā)布、反饋意見的收集、系統(tǒng)性能的及時改進，還對各類數(shù)據(jù)庫進行操作、備份恢復(fù)、導(dǎo)入導(dǎo)出，以保證系統(tǒng)正常運行，同時對其它登錄角色分配系統(tǒng)使用權(quán)限。系統(tǒng)管理員具有功能：信息管理、數(shù)據(jù)管理、權(quán)限管理。3.3.4. 數(shù)據(jù)庫DBA數(shù)據(jù)庫管理員(DBA)負責(zé)設(shè)計、建立和維護項目的數(shù)據(jù)庫，并保證數(shù)據(jù)庫的準確性和安全性。3.4. 其他角色3.4.1. 美工美工的職責(zé)包括：進行網(wǎng)頁美術(shù)設(shè)計；應(yīng)用程序的用戶界面美術(shù)設(shè)計。對于產(chǎn)品型公司，還應(yīng)負責(zé)產(chǎn)品包裝設(shè)計及其其他相關(guān)工作。3.4.2. 測試人員在EOS應(yīng)用的開發(fā)中，測試人員主要進行功能測試、集成測試、系統(tǒng)測試、驗收測試、其他非功能性專項測試等，測試主要從需求規(guī)格和功能設(shè)計出發(fā)，以黑盒測試為主。測試人員可以由獨立于項目組的測試部門工程師擔(dān)任，也可以由項目組的人員兼任，某些測試內(nèi)容可能有用戶的人員參與。3.4.3. 文檔人員文檔人員主要進行用戶手冊等用戶文檔的編寫和編排。對于一般中小型的應(yīng)用項目，一般不需要配備專職的文檔人員，可以由測試的人員兼任。4. 開發(fā)過程階段描述為保證對各個階段的描述有一個完整統(tǒng)一的描述方法，將采用“ETOCXM”的方法進行，具體方式如下：l Entry（進入條件）：為每個階段定義清晰良好的入口條件；l Task（工作任務(wù)）：列出所有要實現(xiàn)的任務(wù)列表，名稱，是否需要實現(xiàn)，任務(wù)描述；l Output（輸出內(nèi)容）：階段工作的輸出產(chǎn)物以及評審內(nèi)容；l Control Point（階段控制點）：本階段中為保證項目成功的關(guān)鍵控制點；l eXit（退出條件）：階段結(jié)束時所要達到的結(jié)果，注意，階段退出條件并不意味下一階段進入條件，因為下一階段可能在上一階段并未結(jié)束的情況下就已經(jīng)啟動了；l Template（參考模板）：本階段可供參考的文檔模板或參考案例4.1. 需求階段4.1.1. 概述本階段是應(yīng)用項目的啟動階段，它主要完成應(yīng)用系統(tǒng)需求的采集整理工作，形成系統(tǒng)設(shè)計和實現(xiàn)所需要的需求基線庫。對于簽訂客戶合同的應(yīng)用項目，需求調(diào)研工作的地點一般在客戶的現(xiàn)場，這種情況下，項目組往往只確定了項目經(jīng)理和需求調(diào)研的人員，項目團隊還不完整。而對于開發(fā)應(yīng)用產(chǎn)品性的項目，則應(yīng)用開發(fā)過程的地點比較固定。對于這兩種情況，項目團隊的管理和工作方法均有一定的差異性，而在本參考中，只提供本階段通用的工作說明，對于上面提到的差異性不做說明，需要項目組結(jié)合本參考內(nèi)容的基礎(chǔ)上充分考慮。對于本階段的工作，如圖所示，詳細的說明，參見“工作任務(wù)”章節(jié)。在上圖所示的工作中，項目實施工作和項目的管理工作可以是并行的。另外，由以上的工作內(nèi)容可以看出，實際上本階段的工作，與是否采用EOS是無關(guān)的。需求階段的主要目標是明確應(yīng)用的所有功能需求和其他非功能性需求，然而這往往是一種理想的目標，實際上在進行需求調(diào)研時，配合參與需求調(diào)研工作的用戶對于系統(tǒng)的需求并不是十分清晰，也是在討論和碰撞中不斷清晰明確的，由此導(dǎo)致的需求不穩(wěn)定性特點比較明顯，表現(xiàn)為某些需求現(xiàn)階段無法進一步細化，某些需求可能出現(xiàn)反復(fù)，某些需求現(xiàn)階段無法確定是否需要實現(xiàn)等等。這種狀況導(dǎo)致無法在人為確定的需求階段中固化所有的需求內(nèi)容，因此，對于項目組而言，在本階段所掌握的需求內(nèi)容基本充分，能夠進行后續(xù)的設(shè)計工作，或者說，所不明確的需求，不足以影響系統(tǒng)的結(jié)構(gòu)和目前工作的進展，那么，需求階段的目標就算是基本達到了。另外，在需求階段，有時用戶會要求提供一個應(yīng)用的原型，希望在需求討論的基礎(chǔ)上，看到系統(tǒng)實現(xiàn)的基本效果。關(guān)于原型的實現(xiàn)，我認為屬于設(shè)計的工作，將在設(shè)計階段進行描述，但并不妨礙將這部分的工作在需求過程中完成。4.1.2. 進入條件l 確定項目經(jīng)理和需求調(diào)研人員l 需求工作的條件成熟：有初始的需求材料（如合同等），與用戶確定了具體的需求調(diào)研安排4.1.3. 工作任務(wù)組建項目團隊項目經(jīng)理必須組建項目團隊是項目啟動的標志，一般公司會為項目任命（或指定）項目經(jīng)理，然后由項目經(jīng)理來申請其他的團隊成員，在項目團隊組建初期，并不能明確這個項目中的所有資源，只會確定重要的角色（如開發(fā)經(jīng)理、架構(gòu)師等）以及即將開始的需求工作的參與人員。需求調(diào)研人員建議由項目經(jīng)理，開發(fā)經(jīng)理，業(yè)務(wù)專家、架構(gòu)師等人員組成。另外，需要強調(diào)的是，項目團隊不僅僅包括項目經(jīng)理所管轄的人員，有時還需要包括對項目起支持作用的組織或成員。有時甚至?xí)幸粋€對等的用戶項目組參與項目（主要承擔(dān)配合、監(jiān)控、質(zhì)保等職能），項目團隊同樣包括這些人。研究資料和需求初步整理需求調(diào)研人員可選 在與用戶開始正式的需求調(diào)研工作之前，利用一定時間針對已掌握的資料（如項目合同的功能需求和系統(tǒng)建設(shè)要求等）進行學(xué)習(xí)，同時，需求調(diào)研組還可以在需求規(guī)格書模板基礎(chǔ)上針對已有資料進行初步的需求整理，整理工作可以達到以下目標：l 形成一致的需求調(diào)研工作思路和需求規(guī)格編寫方法l 形成需求調(diào)研的問題清單和與用戶進行需求溝通的基礎(chǔ)文檔 通過該項工作，將使得接下來的需求調(diào)研工作有的放矢、事半功倍。進行需求調(diào)研需求調(diào)研人員必須需求調(diào)研人員在用戶確認后進入到調(diào)研現(xiàn)場，由項目經(jīng)理負責(zé)組織與用戶的需求調(diào)研工作。一般配合需求調(diào)研工作的用戶還有其他的業(yè)務(wù)工作，需求溝通的時間安排往往比較緊湊，溝通通常以會議的方式進行。每次溝通之前要確定一個主題（不可能一次會議能把所有的需求都討論完），會議過程要做好記錄，會議結(jié)束時要進行簡單的總結(jié)，尤其將一些結(jié)論性意見進行歸納并得到用戶的口頭確認，同時確定某些遺留工作和后續(xù)的工作安排。會議結(jié)束后按照統(tǒng)一的格式整理會議紀要，發(fā)送給與會相關(guān)人員，以及得到用戶方負責(zé)人的確認（最好能夠簽字認可）。編寫需求規(guī)格需求調(diào)研人員必須在進行完一次需求調(diào)研的溝通會議后，應(yīng)該及時進行消化，并以文檔的形式沉淀到需求規(guī)格說明書中，同時將需求溝通中未涉及或未明確的問題再次整理到問題清單中，通過電話、郵件、或會議方式讓用戶進行澄清。編寫需求規(guī)格的過程實際上就是需求分析的過程，需要針對用戶的原始需求進行一定的業(yè)務(wù)抽象和需求點歸類，以便切分和分解形成不同層次的需求點。需求規(guī)格包括了應(yīng)用系統(tǒng)的功能需求、非功能性的需求，以及需求調(diào)研形成的數(shù)據(jù)字典和公共詞匯。功能需求一般要描述出系統(tǒng)用戶的操作和系統(tǒng)的響應(yīng)，以及業(yè)務(wù)規(guī)則、業(yè)務(wù)流程。以上兩個工作在需求調(diào)研的過程中是迭代進行的，直到項目組認為需求基本明確，或者主要需求明確，能夠進行后續(xù)的工作。進行需求評審需求調(diào)研人員、用戶必須需求調(diào)研組認為應(yīng)用的需求范圍和需求內(nèi)容基本確定，而且需求規(guī)格基本形成后，項目經(jīng)理應(yīng)該組織用戶對需求進行評審，評審可選擇會議評審或者需求走查。需求評審后對于有誤的內(nèi)容要進行更正或者重新調(diào)研的工作，對于目前無法確定的問題要形成遺留問題列示在附件中，并確定大致的處理時間計劃。最終審核通過的需求規(guī)格說明書需要獲得用戶的簽字認可（可提供一份需求認可書進行簽字）。制定項目總體實施計劃項目經(jīng)理必須應(yīng)用項目往往有時間進度的要求，一般都明確了系統(tǒng)的上線時間，在項目合同簽訂后，用戶要求提供針對上線時間安排倒推的項目總體實施計劃，所以制定項目總體實施計劃是項目經(jīng)理開始介入項目工作后的重要事情?？傮w計劃將包括項目階段的劃分，以及項目各個階段的時間計劃、大致的資源需求、工作地點等等。制定的總體計劃需要獲得用戶和本公司項目主管領(lǐng)導(dǎo)的認可，這樣才能便于用于的工作協(xié)調(diào)和配合，以及公司的資源調(diào)配。建立項目管理方案項目經(jīng)理可選建立操作性強的項目管理方案是保障項目有序進行的重要工具，也是協(xié)調(diào)項目相關(guān)組織、人員關(guān)系的重要依據(jù)。也有助于新進入項目的成員盡快進入工作角色。項目管理方案包括但不僅限于以下內(nèi)容：l 項目的組織結(jié)構(gòu)和分工界面：有助于明確相關(guān)組織、角色、人員的工作職責(zé)l 項目的內(nèi)外部協(xié)調(diào)機制：例如例會機制，溝通機制、工作周報等l 項目的爭議機制：當(dāng)項目組與用戶方發(fā)生爭議（例如需求不明確導(dǎo)致的爭議、實現(xiàn)方式爭議等）時的解決機制l 需求變更的流程l 項目風(fēng)險方案：列出項目實施可能存在的風(fēng)險以及規(guī)避措施等l 項目團隊人員名單及聯(lián)系方式制定項目實施和管理的模板項目經(jīng)理，開發(fā)經(jīng)理必須項目文檔是項目團隊溝通的載體，而良好的模板方便項目成員的編寫，也有助于閱讀人員的理解。項目模板包括項目實施的過程文檔模板和項目管理的模板，包括但不僅限于以下內(nèi)容：項目實施過程模板：項目需求規(guī)格說明書項目系統(tǒng)設(shè)計說明書應(yīng)用系統(tǒng)測試方案應(yīng)用系統(tǒng)測試報告應(yīng)用系統(tǒng)用戶使用手冊應(yīng)用系統(tǒng)維護手冊項目管理模板項目工作周報會議紀要項目評審報告項目驗收報告不一定所有模板都要在本階段完全確定，也可以考慮本階段暫時確定當(dāng)前迫切需要的模板。4.1.4. 輸出內(nèi)容需求調(diào)研的會議紀要項目需求規(guī)格說明書項目實施總體計劃項目管理方案需求變更控制表4.1.5. 階段控制點由于該階段是項目的啟動階段，項目團隊剛剛建立尚不完整，對于客戶而言，非常關(guān)注項目的進度計劃，對于項目組所在公司而言，在關(guān)注項目進度的同時，也關(guān)心項目的需求范圍。對于項目經(jīng)理而言，本階段的主要控制點在于：l 需求范圍的控制：因為在與用戶進行需求調(diào)研的基礎(chǔ)一般是項目的合同文本，往往合同對項目的功能范圍只是做了粗略的描述，這些內(nèi)容需要通過調(diào)研工作進行細化和明確，功能細化的程度往往對工作量的影響很大，在調(diào)研中需要掌握需求的主次，避免對非重要功能的需求過度復(fù)雜化（要知道一個功能做到不同程度，付出的工作量的差異是很大的），同時思考某個功能點的需求可能帶來的工作量和付出這種工作量對項目整體而言是否值得（這就是讓系統(tǒng)架構(gòu)師和開發(fā)經(jīng)理參與需求調(diào)研的重要意義）。要明白，在用戶理解付出代價的情況下合理有效的需求控制一定會得到用戶的支持。l 項目資源的協(xié)調(diào)：在本階段，將會確定項目實施的總體計劃，保證計劃能得以正常執(zhí)行的前提是有效的資源保障。資源的稀缺性是項目的重要特征，項目經(jīng)理要和公司充分溝通資源的安排和投入時間，以保證項目按照計劃正常實施。4.1.6. 退出條件項目需求規(guī)格說明書獲得用戶簽字認可。項目組所明確的用戶需求基本完備，能夠進入到設(shè)計階段。4.1.7. 參考模板項目需求規(guī)格說明書需求調(diào)研會議紀要項目工作周報需求變更控制表4.2. 設(shè)計階段4.2.1. 概述設(shè)計階段是應(yīng)用項目實施的重要階段，它是將用戶需求轉(zhuǎn)發(fā)為應(yīng)用系統(tǒng)技術(shù)實現(xiàn)的重要環(huán)節(jié)。設(shè)計的過程，是將用戶需求涉及的功能、數(shù)據(jù)、流程等業(yè)務(wù)的信息，運用業(yè)務(wù)和技術(shù)的眼光進行抽象，映射成技術(shù)實現(xiàn)內(nèi)容的過程，一方面，經(jīng)過抽象后系統(tǒng)橫向切分為不同的應(yīng)用系統(tǒng)功能，從而保證這些功能即能夠覆蓋用戶的業(yè)務(wù)功能需求，又能體現(xiàn)業(yè)務(wù)模型的可擴展能力和低耦合度，另一方面，經(jīng)過抽象后的系統(tǒng)從縱向切分為不同的層次，有利于實現(xiàn)時的分工合作，同時降低技術(shù)層次的耦合性，利于技術(shù)層面的擴展。下圖表現(xiàn)了一個系統(tǒng)經(jīng)過設(shè)計后用戶和實現(xiàn)人員的不同視角這樣我們就很容易理解，當(dāng)我們選擇J2EE實現(xiàn)用戶的應(yīng)用系統(tǒng)時，對于設(shè)計工作，一方面要從技術(shù)層面設(shè)計一個應(yīng)用架構(gòu)來實現(xiàn)應(yīng)用軟件的層次封裝，在開源領(lǐng)域，目前有很多種應(yīng)用架構(gòu)的成果，但往往只是解決了應(yīng)用框架中一部分的問題，需要組合或者自行設(shè)計完整的應(yīng)用框架結(jié)構(gòu)，例如，可能選擇Hibernate+Struts+Spring經(jīng)過整合后的框架作為應(yīng)用的框架，或者采用項目組自行封裝的應(yīng)用框架實現(xiàn)。另一方面要針對用戶的需求進行業(yè)務(wù)的建模和抽象，形成系統(tǒng)對應(yīng)與數(shù)據(jù)庫的數(shù)據(jù)對象模型和java的對象模型。在采用EOS實現(xiàn)J2EE應(yīng)用時，由于EOS已經(jīng)提供了一套完整的應(yīng)用軟件框架，使得在設(shè)計階段無需考慮應(yīng)用架構(gòu)的問題，同時也不用考慮業(yè)務(wù)模型與java對象抽象的工作。這也是EOS應(yīng)用開發(fā)與傳統(tǒng)J2EE應(yīng)用開發(fā)在設(shè)計階段工作方面最大的差別。對于EOS應(yīng)用的設(shè)計內(nèi)容，主要的重心在于業(yè)務(wù)模型的抽象（可理解為業(yè)務(wù)架構(gòu)）、構(gòu)件包的劃分以及功能點的細分，這樣讓設(shè)計人員能夠從考慮技術(shù)架構(gòu)和OO模型的穩(wěn)定、優(yōu)雅和是否符合力學(xué)原理的泥沼中解脫出來，將主要的精力花費在考慮業(yè)務(wù)模型的抽象和擴展能力上（也有助于設(shè)計人員從技術(shù)思維轉(zhuǎn)向業(yè)務(wù)思維，或許我這種說法對于熱衷于技術(shù)研究的設(shè)計師會不以為然，但如果設(shè)計師跟用戶溝通時如果屢屢提及對象、設(shè)計模式等詞眼未必能讓用戶對于系統(tǒng)的設(shè)計思路有多清晰的理解）。所以，對于EOS應(yīng)用的設(shè)計，應(yīng)多多考慮的具體工作包括：數(shù)據(jù)庫的設(shè)計、用戶的界面表現(xiàn)和整體風(fēng)格、功能的切分、功能（頁面）的流轉(zhuǎn)方式、應(yīng)用處理的流程或規(guī)則、系統(tǒng)權(quán)限的控制、與外部系統(tǒng)的接口等等，分解成本階段的工作步驟如下圖所示：在上圖中，描述了設(shè)計階段的各項工作以及工作之間的大致關(guān)系，在設(shè)計階段，首先需要進行系統(tǒng)的總體設(shè)計，形成系統(tǒng)的總體結(jié)構(gòu)和總體要求，通過此工作，可以從系統(tǒng)全局的高度分解出系統(tǒng)設(shè)計的各項具體工作內(nèi)容，例如，存在哪些技術(shù)點的風(fēng)險需要進行技術(shù)課題的攻關(guān)或預(yù)研，項目規(guī)范內(nèi)容的總體要求，數(shù)據(jù)庫設(shè)計前的業(yè)務(wù)對象模型（概念模型），應(yīng)用的頁面框架和美工設(shè)計要求等，通過總體設(shè)計工作，可以形成幾條并行工作線，其中，制定項目開發(fā)規(guī)范將與數(shù)據(jù)庫設(shè)計、頁面框架設(shè)計、原型設(shè)計、功能設(shè)計等各個工作相互影響，一方面，項目開發(fā)規(guī)范的內(nèi)容形成對這些工作的約束，另一方面，這些工作進行的過程中，某些約定或者要求會補充到項目開發(fā)規(guī)范中。有關(guān)各個步驟的具體內(nèi)容和要求將在工作任務(wù)章節(jié)進行詳細描述。需要說明的是，盡管列出了上述的很多工作項，在實際操作中，并不是每個工作項有人專職去做，而是根據(jù)項目組人員的具體情況，一人可能同時承擔(dān)多項工作，并行處理。另外，對于參與EOS應(yīng)用設(shè)計的人員，建議對EOS的結(jié)構(gòu)和開發(fā)方式以及相關(guān)資源有較好的理解，這樣才能知道在設(shè)計中哪些工作不需要做了，哪些內(nèi)容需要結(jié)合EOS產(chǎn)品的特點進行考慮。4.2.2. 進入條件l 已掌握應(yīng)用項目的基線性需求，即使存在部分不確定的需求，但該部分飄浮不定的需求不足以對應(yīng)用架構(gòu)產(chǎn)生大的影響；l 設(shè)計人員到位，使得工作的開展有人力的保障。4.2.3. 工作任務(wù)制定項目階段計劃項目經(jīng)理必須 項目經(jīng)理通過階段工作計劃確定本階段的工作目標和內(nèi)容，以及人力計劃，時間計劃，里程碑的設(shè)置等。系統(tǒng)總體設(shè)計系統(tǒng)架構(gòu)師、開發(fā)經(jīng)理必須數(shù)據(jù)庫設(shè)計業(yè)務(wù)建模人員必須 頁面框架設(shè)計開發(fā)經(jīng)理、架構(gòu)師、美工必須系統(tǒng)功能分解開發(fā)經(jīng)理、架構(gòu)師、主程序員必須功能設(shè)計任務(wù)分配項目經(jīng)理、開發(fā)經(jīng)理必須頁面原型設(shè)計主程序員可選應(yīng)用功能設(shè)計主程序員必須制定項目開發(fā)規(guī)范開發(fā)經(jīng)理、架構(gòu)師必須開發(fā)環(huán)境準備開發(fā)經(jīng)理必須技術(shù)課題攻關(guān)架構(gòu)師可選制定和實施配置管理方案開發(fā)經(jīng)理、配置管理人員可選 從本階段開始，項目組的人員規(guī)模在不斷擴大，工作的產(chǎn)物也越來越多，為確保項目組工作成果的管理和共享，組織設(shè)計評審項目經(jīng)理必須4.2.4. 輸出內(nèi)容l 數(shù)據(jù)庫設(shè)計（ER關(guān)系）、業(yè)務(wù)字典定義l 系統(tǒng)靜態(tài)原型l 系統(tǒng)設(shè)計說明書l 系統(tǒng)功能分解矩陣l 經(jīng)過項目客戶化后的EOS模板文件l 項目配置管理方案l 技術(shù)課題預(yù)研的結(jié)論或者使用指南l EOS初始項目源碼4.2.5. 階段控制點設(shè)計階段是系統(tǒng)實施的重要階段，設(shè)計的完整性和合理性直接決定了系統(tǒng)的擴展能力、易用性、和系統(tǒng)運行效率。對于項目組而言，本階段的主要控制點包括：l 確保系統(tǒng)設(shè)計的質(zhì)量：對于良好的系統(tǒng)設(shè)計，應(yīng)該滿足如下要求：1） 應(yīng)用總體設(shè)計思路清晰，結(jié)構(gòu)簡捷合理2） 功能設(shè)計可實現(xiàn)性強：通過查看原型、對應(yīng)的數(shù)據(jù)庫設(shè)計和功能設(shè)計文檔，功能實現(xiàn)者（開發(fā)人員）比較清楚用戶界面的信息、對應(yīng)操作的數(shù)據(jù)實體、應(yīng)用處理的流程、相關(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)容具有較強的操作性，而不至于流于形式。l 有效合理的需求變更控制：在本階段，需求階段所遺留的不穩(wěn)定需求對本階段會有較大的影響，一方面需要花費時間來討論這部分需求導(dǎo)致設(shè)計階段進度延誤，另一方面需求的變更可能會導(dǎo)致系統(tǒng)設(shè)計的變化，因此，項目經(jīng)理和有經(jīng)驗的設(shè)計人員要充分評估這些變更對項目的影響，對于可能影響項目進展而需求重要程度較低的變更，項目經(jīng)理要懂得讓用戶放棄這種變更或者采用雙方可接受的變更方式。4.2.6. 退出條件l 系統(tǒng)設(shè)計工作內(nèi)容通過評審4.2.7. 參考模板l 系統(tǒng)設(shè)計說明書l 系統(tǒng)靜態(tài)原型l 功能分解矩陣4.3. 開發(fā)階段4