【正文】 216。 編寫概要設計（系統(tǒng)軟件架構(gòu)）252。 設計者以需求為約束，對系統(tǒng)進行分析，依據(jù)功能獨立性原則分解出系統(tǒng)模塊和組件252。 設計者識取系統(tǒng)主要的內(nèi)部和外部接口252。 設計者在組件級對系統(tǒng)進行動態(tài)建模分析，分析組件的性能和擴展性252。 設計者從組織構(gòu)件庫中選取可重用的系統(tǒng)組件252。 設計者確定組件是否開發(fā)、購買或重用216。 為項目工作環(huán)境建立規(guī)程252。 填寫項目環(huán)境配置表252。 確定項目工具軟件種類和版本252。 準備工具軟件的安裝手冊和使用手冊252。 建立項目通訊錄252。 為項目組成員在配置管理庫、日報系統(tǒng)、QAS系統(tǒng)等其它系統(tǒng)中分配權(quán)限216。 功能設計216。 數(shù)據(jù)庫設計216。 設計評審、驗證和基線化設計采用同行評審。216。 集成測試籌備216。 培訓和研究216。 項目計劃更新項目經(jīng)理重新確認項目計劃。根據(jù)《需求規(guī)格說明書》及《概要設計書》內(nèi)容進行詳細設計，確定設計內(nèi)部結(jié)構(gòu)及內(nèi)部實現(xiàn)流程。根據(jù)詳細設計編寫代碼并進行單元測試。按照《體系結(jié)構(gòu)設計書》中系統(tǒng)開發(fā)環(huán)境的要求搭建開發(fā)環(huán)境。為集成測試和系統(tǒng)測試做好準備工作。216。 編寫詳細設計書，并經(jīng)過評審252。 設計者選取開發(fā)設計方法和工具252。 設計者描述組件接口和數(shù)據(jù)結(jié)構(gòu)252。 設計者將系統(tǒng)組件細分為過程，并定義過程的實現(xiàn)邏輯216。 開發(fā)小組共同協(xié)商制定如下計劃：252。 編碼計劃開發(fā)人員根據(jù)“編程計劃”編寫軟件的代碼，開發(fā)人員在編寫完成每個模塊時，必須對自己的代碼進行必要的審查和測試。252。 代碼審查計劃開發(fā)人員根據(jù)“代碼審查計劃”對同伴的代碼進行審查。252。 單元測試計劃開發(fā)人員根據(jù)詳細設計文檔撰寫單元測試用例。參見Error! Reference source not ! Reference source not found.。單元測試流程圖：圖20252。 系統(tǒng)測試籌備252。 缺陷和問題管理任何人發(fā)現(xiàn)軟件中的缺陷時都必須使用指定的缺陷管理工具(QAS系統(tǒng))。該工具將記錄所有缺陷的狀態(tài)信息，開發(fā)人員要及時消除已經(jīng)發(fā)現(xiàn)的缺陷并馬上進行回歸測試，以確保不會引入新的缺陷。216。 代碼開發(fā)252。 開發(fā)人員根據(jù)審核過的詳細設計文檔，代碼規(guī)范和結(jié)構(gòu)進行開發(fā)工作252。 開發(fā)人員更新需求變更矩陣RTM252。 需求變更的部分，需要更新變更請求日志，同時執(zhí)行需求變更管理流程，修改相應的詳細設計文檔，重新對設計文檔進行審查216。 代碼評審過程代碼采用同行評審。在單元測試結(jié)束的基礎上，按照集成要求，對組裝起來的模塊進行測試，發(fā)現(xiàn)與接口有關的錯誤，驗證程序與概要設計的一致性。216。 產(chǎn)品組件狀態(tài)檢查216。 搭建集成環(huán)境216。 產(chǎn)品集成216。 搭建集成測試環(huán)境216。 執(zhí)行集成測試216。 編寫集成測試報告216。 評審工作產(chǎn)品216。 缺陷和問題管理任何人發(fā)現(xiàn)軟件中的缺陷時都必須使用指定的缺陷管理工具(QAS系統(tǒng))。該工具將記錄所有缺陷的狀態(tài)信息，開發(fā)人員要及時消除已經(jīng)發(fā)現(xiàn)的缺陷并馬上進行回歸測試，以確保不會引入新的缺陷。對最終軟件系統(tǒng)進行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設計，發(fā)現(xiàn)系統(tǒng)中的潛在問題，包括性能情況。對各功能模塊的接口測試，采用的方法是黑盒測試。項目經(jīng)理組建系統(tǒng)測試小組，并指定一名成員任測試組長。系統(tǒng)測試小組各成員依據(jù)產(chǎn)品需求和系統(tǒng)設計文檔依次進行如下活動：216。 搭建系統(tǒng)測試環(huán)境216。 執(zhí)行系統(tǒng)測試系統(tǒng)測試包括功能測試，可靠性測試，負載測試，壓力測試，響應時間測試和可擴展性測試。必要的話，也要進行安全測試，災難恢復測試，可用性測試。216。 編寫系統(tǒng)測試報告216。 評審工作產(chǎn)品216。 缺陷和問題管理任何人發(fā)現(xiàn)軟件中的缺陷時都必須使用指定的缺陷管理工具(QAS系統(tǒng))。該工具將記錄所有缺陷的狀態(tài)信息，開發(fā)人員要及時消除已經(jīng)發(fā)現(xiàn)的缺陷并馬上進行回歸測試，以確保不會引入新的缺陷。在系統(tǒng)測試的基礎上，在合適的時機，將符合要求的產(chǎn)品予以發(fā)布。216。 工作產(chǎn)品已完成并通過評審216。 系統(tǒng)測試結(jié)果達到客戶標準為通過216。 發(fā)布準備252。 待發(fā)布的工作產(chǎn)品已基線化252。 填寫《產(chǎn)品包清單》252。 生成產(chǎn)品包，放入發(fā)布庫252。 通知配置管理員進行發(fā)布配置審核216。 配置審核252。 配置管理員進行配置審核（物理和功能審核）252。 填寫《配置審核報告》 252。 項目經(jīng)理解決審核中出現(xiàn)的問題216。 工作產(chǎn)品發(fā)布252。 項目經(jīng)理填寫《產(chǎn)品發(fā)布報告》252。 質(zhì)量保證人員和配置管理員對《產(chǎn)品發(fā)布報告》進行審核252。 簽署發(fā)布報告由項目經(jīng)理，測試組長，質(zhì)量保證人員，配置管理員在紙制《發(fā)布報告》上簽字確認。216。 客戶對應252。 客戶反饋問題252。 問題記錄到QAS系統(tǒng)，開發(fā)人員對問題進行修改252。 回歸測試，達到客戶發(fā)布標準252。 再次發(fā)布216。 高層經(jīng)理確認發(fā)布客戶驗收階段是客戶依據(jù)合同對產(chǎn)品進行審查和測試，確保產(chǎn)品滿足客戶需求。開發(fā)方項目經(jīng)理和其他成員為客戶驗收工作提供協(xié)助，及時解決客戶方發(fā)現(xiàn)的問題。開發(fā)方將待驗收的工作成果準備好，并將必要的材料（軟件產(chǎn)品、相關代碼及文檔）提前交給用戶驗收小組，確保這些成果是完整的并且是正確的。當待驗收的所有工作成果都通過了審查和測試后，開發(fā)方將其交付給客戶方。雙方的責任人簽字認可。由于客戶參與了測試過程，就可以在上線之前發(fā)現(xiàn)問題，不僅減少了需求和理解的誤差，更加減少了上線后系統(tǒng)出現(xiàn)的問題壓力。在這個階段，需要用戶及時把問題提交到問題報告中，測試人員與開發(fā)負責人，以及客戶協(xié)商后，如果確實是個bug，遵循bug修復和跟蹤流程，如果是個功能改進，遵循功能改進流程，如果是新需求，需要遵循需求變更流程。Error! Reference source not ! Reference source not found.，跟蹤解決發(fā)現(xiàn)的缺陷。BUG修復與跟蹤流程：圖21項目交付后，為積累經(jīng)驗教訓，在項目結(jié)項時仍然有許多工作要做，需要遵守結(jié)項流程。216。 獲取客戶認可項目結(jié)束的簽字216。 項目經(jīng)理起草項目總結(jié)報告216。 項目組成員經(jīng)驗總結(jié)216。 質(zhì)量保證人員根據(jù)檢查單對項目總結(jié)報告進行審計216。 通知高層經(jīng)理進行審核216。 項目所有成員參加評審會議，輸出會議紀要216。 更新公司組織過程資產(chǎn)庫216。 項目經(jīng)理提交結(jié)項申請表，由高層經(jīng)理，項目經(jīng)理，測試組長，質(zhì)量保證人員和資料人員審核簽署第七章 后期維護平臺系統(tǒng)免費維護一年。提供每周7天、每天24小時電話,網(wǎng)絡支持服務。第八章 成功案例成功案例，見PPT。