軟件開發規范方案整體規范方案軟件開發規范方案整體規范方案軟件開發規范方案整體規范方案xxx公司軟件開發規范方案整體規范方案文件編號：文件日期：修訂次數：第1.0次更改批準審核制定方案設計，管理制度軟件開發規范SoftwareDevelopmentSpecificationVersion:Date:2010-06-22Preparedby

DocumentRevisionHistory文檔修訂記錄VERSION版本DATE日期DESCRIPTION內容說明INDIVIDUAL修訂人2010-06-22初稿

TableofContents目錄TOC\o"1-4"\h\z\u1 Introduction簡介 5 Purpose目標 5 Scope范圍 6 Definitions,Acronyms,andAbbreviations.術語，縮略詞 6 References引用 7 Overview文檔組織 72 TheOverallDescription概述 8 SoftwareDevelopmentOrganizing開發團隊組織結構 8 ProjectBaseProcess項目基本流程 9 CMMBaseProcessCMM基本過程 10 SCM軟件配置管理 10 SPP計劃策劃 12 SPTO項目追蹤 15 PR同行評審 17 SQA質量保證 18 SDLC生命周期選擇 19 DevelopmentProcess開發過程 20 DevelopmentPhase開發階段 20 PhaseProduct階段制品 21 RoleDuty角色職責 22 Constraints限制 233 SpecificRequirements詳細描述 24 Precondition前提 24 SCM配置庫 24 TestEnvironment測試環境 25 DevelopmentControlProcess開發控制流程 25 項目啟動和策劃階段 26 需求分析、設計、編碼階段 26 提交測試階段 26 生產發布、終測 27 發布后問題反饋修改過程 27 TSP團隊軟件過程 29 會議組織 29 溝通問題 29 代碼走查 29 其它 30 PSP個人軟件過程 30 工作原則 30 日常工作 30 DE開發工程師 31 SCME配置管理員 32 DBA數據庫管理員 32 Deployer發布人員 334 ToolSpecification工具規范 33 通用工具 33 計劃 33 需求分析 34 設計 34 編碼 34 測試 345 Documents文檔 35 項目管理文檔 35 項目策劃 35 項目追蹤 35 質量保證 35 項目終止 35 開發過程文檔 35 軟件配置管理 35 會議管理 36 計劃跟蹤 36 評審管理 36 質量管理 36 測試過程 36 問題解決過程 36 其他 376 Appendix附錄 37 易于理解的代碼 37 Log輸出 37

Introduction簡介一個成熟穩定的組織或者團隊，能夠減少風險，經常地成功地達成目標。成功的含義是：按時、預算內【即符合成本要求】、符合質量要求。換言之，成熟穩定的團隊，能夠避免以下問題：組織方面出現問題對需求缺乏管理缺乏計劃和控制估算錯誤同時，還要在以下幾個方面做得比較出色：人員調度與工作安排工作量估計預算管理責權分配與平衡執行與監控溝通本文檔是軟件開發規范，力求使團隊打下一個良好的基礎，以便逐步成長為成熟穩定的團隊。團隊需要一個逐步標準、規范的開發過程，在這個過程中，團隊得到鍛煉，成員能力得到提高，風險得到控制。主要內容是：定義軟件開發的流程；定義軟件開發的文檔格式；定義涉及的角色；定義涉及的信息；描述開發流程；Purpose目標本文檔的目標是：統一軟件開發團隊的流程、文檔；促進團隊成員的溝通，減少誤解；促使程序員書寫易維護的代碼；提高代碼編寫效率；使每個成員成為一個高效的程序員；

Scope范圍本文檔，包含：項目管理的流程；項目策劃項目追蹤配置管理質量保證同行評審涉及文檔；項目計劃mpp需求規格說明書SRSDelphi估算項目狀態報告配置庫樣式CheckList評審表變更申請表開發工具的規范；數據庫設計工具功能設計工具IDE配置工具Definitions,Acronyms,andAbbreviations.術語，縮略詞SPP 項目策劃SoftwareProjectPlanningSPTO 項目追蹤SoftwareProjectTracking&OversightSCM 配置管理SoftwareConfigurationManagementSQA 質量保證SoftwareQualityAssurancePR 同行評審PeerReviewBaseLine 基線SCCB 軟件配置控制委員會SoftwareConfigurationControlBoardCR 變更請求ChangeRequestSDLC 軟件開發生命周期SoftwareDevelopmentLifeCycleRUP 統一開發過程RationalUnifiedProcessXP 極限【敏捷方法】eXtremeProgrammingTDD 測試驅動TestDrivenDevelopmentReferences引用《CMM2》《CMM3》Overview文檔組織本文檔主要分為四大部分：概述；描述了團隊組織開發過程的高層視圖；TSP和PSP；按照團隊和個人描述流程規范；工具規范；描述了開發工具的詳細規范；文檔；涉及的文檔格式；

TheOverallDescription概述本部分是開發團隊開發過程的高層描述。它描述了開發過程規范的背景，用來和所有涉及各方就基本過程達成共識。SoftwareDevelopmentOrganizing開發團隊組織結構說明：表示公司的行政部門表示公司的邏輯部門實線表示參加產品實現的組織和人員（不表示所屬關系）虛線表示工作的匯報關系，如SQAE向SQA經理匯報。

ProjectBaseProcess項目基本流程識別需求識別需求提出解決方案執行項目結束項目投入力量可行性分析報告需求建議書合同項目目標項目定義制定計劃計劃實施項目終止時間基本流程說明：項目啟動：本階段主要是進行可行性分析，定義項目，識別需求；制定計劃：本階段主要是計劃策劃，估算工作量，制定具體的可執行的計劃；計劃實施：本階段主要是實施計劃，完成計劃中的各項任務，報告計劃狀態；項目終止：計劃執行完畢，總結項目；

CMMBaseProcessCMM基本過程SCMSCMSQAWorkAreaBaseLineSPPSPTOPRChange&PR基本過程說明：SCM：軟件配置管理，所有活動的基礎，一切制品必須放入配置庫；SPP：軟件項目策劃，估算工作量，制定詳細計劃【項目的制定計劃階段】；SPTO：項目追蹤，報告項目狀態，評估并更新計劃【項目的計劃實施階段】；PR：同行評審，進入基線的前提條件，降低風險，提高質量的有效手段；SQA：質量保證，預防風險的有效手段；SCM軟件配置管理配置管理主要解決：版本變更

確定配置項和基線確定配置項和基線確定記錄和報告配置項狀態策略定義配置項定義訪問權限訪問權限確定配置管理工具確定SCCB成員確定配置庫及其目錄結構項目啟動確定配置管理人員Vss、SVN或VSTS一般由：項目經理、技術經理、客戶經理、質量保證人員、配置管理等項目的核心成員人員組成。在配置項（基線）生成和基線變更時配置庫結構權限表基線表確定基線變更過程定義備份與病毒策略定義備份與病毒策略按計劃執行配置管理活動SCM計劃制定和評審記錄和報告基線的狀態在配置項（基線）生成和基線變更時至少在項目的每個里程碑結束時進行備份1建立配置庫2對項目組指導和培訓3對配置項的日常管理4參加評審會議5定期備份和病毒防護6實施發布7進行歸檔8配置管理計劃的維護配置管理情況總結計劃完成總結配置項是否完整、基線的變化情況統計、審核發現問題情況統計、改進建議等，記入項目總結報告定義測試和發布歸檔方式SCM計劃配置審核狀態報告審核報告SPP計劃策劃計劃策劃的核心是工作量估算

從歷史庫中識別可用的信息從歷史庫中識別可用的信息項目啟動從公司的數據中識別項目相似的信息，如項目的總結報告和其它的數據或文擋項目需求、合同以及《軟件項目任務書》等相關要求選擇項目生命周期識別項目的特點了解各個生命周期的特點確定適合項目生命周期模型從對用戶需求的理解是否充分；人員介入項目的方式；產品的交付方式；項目規模大小和風險高低；對項目系統架構的理解是否充分等方面考慮RUPXPRUPXP依據定義的過程，識別必須完成的任務和工作產品分解時考慮的活動事項要詳盡，不要漏掉：教育或培訓的需要；參與評審文檔；參與項目會議；確定、記錄和顯示各種與質量相關和與過程相關的數據；傳播時間文檔制品如：計劃、SRS等規模估算制定工作產品的評審計劃估算表估算結果評審計劃

識別項目需要使用的工具和設施識別項目需要使用的工具和設施風險評估識別與其他組之間的關系確定項目的跟蹤情況確定項目的組織結構和職責識別項目需要進行的培訓制定時間進度表在已知的停工和節假日時間不安排工作；不考慮加班時間；考慮測試及評審中發現問題的返工需要的時間；考慮客戶需求的穩定情況；考慮各項活動的交接和信息的傳遞時間；識別出的風險對活動的影響；在安排工作時應考慮整個項目的效率因素，在正常估算的工期內增加20～40％的余量，分配到項目的所有活動中――特別是關鍵路徑中的活動中工具指南風險表協同工作計劃項目跟蹤計劃組織和角色定義培訓計劃時間進度表

編寫項目開發計劃書及其相關計劃書編寫項目開發計劃書及其相關計劃書計劃評審計劃管理和控制SQA計劃SCM計劃SDP計劃Test計劃風險計劃SPTO項目追蹤軟件項目開發計劃軟件項目開發計劃日常進度跟蹤定期報告項目狀態周例會里程碑總結需要調整計劃修改和評審計劃糾正和預防當出現：規模、工作量、進度和關鍵計算機資源超出規定的閾值；項目總的原始計劃不再可能達到；計劃和實際的任務安排明顯不相符，起不到指導作用；對客戶的承諾不能實現時并滿足下列條件時：導致計劃變化的原因是知道的，并清楚計劃怎么樣改變；提議的項目進度計劃變動是可達到的；提議的項目進度計劃已經得到了必須完成他的人員的許諾在周例會上向項目組的成員傳達客戶方面的信息、交流項目近期進展情況、未完成的工作、工作中存在的問題、好的經驗以及部署下兩周的工作，以使得計劃和實際的開發工作相符合總結到目前為止項目開發總體狀況、項目活動進展情況（一般通過甘特圖來體現）、活動項進展（應特別關注未完成活動項）、本階段好的經驗和典型問題、過程改進建議、客戶方面新要求，項目評審、培訓執行情況、項目風險等其它方面存在的問題，分析在進度、工作量和缺陷等方面收集的數據并根據情況制定相應的措施和調整時間進度表，保持項目正常、健康開發個人工作周報時間進度表數據收集其它組跟蹤周報告分析和預測里程碑報告項目總結項目總結報告PR同行評審評審準備評審準備制定本次評審計劃評審跟蹤正式評審評審人員進行預審，在指定的時間內給出預審意見，反饋給評審組長和作者。評審組長將缺陷（或問題）及工作量匯總填入《評審報告》。要評審的文檔已經完成且文檔符合標準模板要求，項目經理指定評審組長，發放工作產品及參考資料，必要時確定評審重點（參見評審指南）工作產品評審計劃將報告抄送相關人員項目經理組織解決發現的缺陷（或問題）作者根據評審結果進行必要的改進驗證人驗證最終修正評審通過的產品作為基線的要得到SCCB批準評審通知表個人評審表評審報告SQA質量保證軟件項目啟軟件項目啟動指定SQAE制定質量保證計劃并評審通過進行審核發現不符合項計劃完成NoYes制定質量審核計劃詳細的審核時間安排至少在正式審核前2天發給項目經理或技術經理、SQA經理審核、得到項目或技術經理認可詢問相關人員，對項目組的過程執行情況進行審核檢查文檔和其他一切相關的證據，驗證項目組的活動總結審核情況將報告初稿與項目經理及有關人員進行討論，落實問題負責人；形成正式報告后發送給高級管理者、SQA經理、項目經理、項目成員等相關人員項目質量保證情況總結SQA計劃SQA審核計劃CheckListSQA審核報告SQA差異報告SDLC生命周期選擇當前比較成熟穩定的SDLC是：WaterFallRUPXP其中：RUP和XP是迭代式開發過程，風險是可控的。RUP的優點是過程清晰、文檔齊全，但是過于龐雜，比較適合大規模的團隊；XP的優點是過程簡潔、推崇簡單，但是不注重文檔，難于交接，適合小規模團隊。對于中等規模的團隊來說，應該基于RUP和XP，進行裁剪，找到適合的SDLC：SDLC的核心是：迭代式和TDD從全局看：Use-CaseDriven用例驅動基于Architecture迭代和遞增的從微觀看：TDD測試驅動ReFactor重構Pair結對編程

DevelopmentProcess開發過程編碼編碼集成測試計劃系統測試計劃發布維護SRSHLD軟件配置管理軟件質量管理評審管理DevelopmentPhase開發階段需求分析階段需求收集需求總結總體設計階段總體架構部署模型概要設計階段模塊劃分數據庫設計詳細設計階段具體實現編碼階段測試用例Coding單元測試測試階段測試用例測試修正發布階段安裝測試安裝系統維護PhaseProduct階段制品需求階段SRS：需求規格說明書總體設計階段總體設計說明書概要設計階段HLD：概要設計說明書DB：數據庫設計DFD：數據流圖UI：用戶界面詳細設計階段DD：詳細設計說明書編碼階段TestCase：測試用例Coding：源代碼UTTestResult：單元測試報告測試階段TestTask：測試任務書TestCase：測試用例TestResult：測試報告TestApprovals：測試總結發布階段發布申請書

RoleDuty角色職責角色責任研發經理【研發團隊】為軟件項目提供足夠的資源.保證SQA小組的獨立性.解決SQA檢查時發現的問題.審批對外的承諾。定期審查SCM、SQA、項目計劃和跟蹤的相關活動。規定系統需求；將系統需求分配給硬件、軟件和其他成分；規定硬件、軟件和其他成分的界面；監控設計和開發以保證他們符合其規格說明；代表公司下達任務書。SA團隊負責網絡工程計劃的制定及實施；負責對客戶的技術支持與培訓；負責工程服務部內部人員素質與技術培訓負責系統集成工程標識、測試、驗收及質量保證；負責硬件、網絡和系統軟件產品的最后交付；負責組織自產軟件儲運、防護、交付和安裝；負責工程項目的配置管理QA研究制定測試規范和方案；參加實施測試和質量保證過程；對系統測試中發現的缺陷進行驗證；負責組織軟件項目任務書、開發計劃、里程碑等管理評審；負責公司的配置管理；項目經理負責軟件和硬件整個項目的協調、管理進行需求分析，并進行文檔的編寫組織技術評審等活動組織制定項目開發計劃（SDP）、風險管理計劃等計劃配合與協調SQA和SCM小組的活動.管理項目組，執行SQA方針和過程以及SDP.監督和跟蹤SDP、項目估算SA負責硬件工程的實施；負責系統的上線；負責系統的維護；SCCB授權建立軟件基線和標識配置項/單元；審查和審定對軟件基線的更改；審定由軟件基線庫制造的產品的生成。SCM協助軟件項目經理制定SCM計劃、維護SCM計劃；制定并維護項目標識規范；按時歸檔配置項；標識并管理置于配置管理過程之下的軟件工作產品集合；進行軟件項目的軟件基線生成、管理和備份；軟件配置狀態的統計和審計，并向項目組、軟件項目經理、高級管理者匯報有關活動情況；將基線的變更情況通知受影響的組和個人；保存并管理各項評審記錄、與項目相關的技術文檔、標準和規程。SQC依據測試計劃模板制定測試計劃.執行測試計劃進行測試并記錄測試發現的缺陷提供測試報告.SQA主要是策劃軟件質量保證活動、檢驗軟件產品或活動對可用的標準、需求和規則的遵守程度、組織處理項目內部不能解決的不一致問題；定期報告檢查情況，發現偏差組織制定糾正、預防措施并監督更正；參與制定SQA計劃，實施SQA活動，并向SQA經理、軟件項目經理項目組、高級管理者匯報有關的情況。DBA負責DB的創建和維護；為DE提供一個穩定的環境；DE按軟件開發計劃進行開發，并記錄相關數據；遵守公司質量管理體系的要求.Deployer根據發布申請，提取代碼，發布系統和SA、DBA一起配置環境重構和重建系統Constraints限制

SpecificRequirements詳細描述本部分按照角色劃分詳細描述開發過程。Precondition前提SCM配置庫目錄結構開發庫：開發工作區文檔和代碼項目文檔項目啟動項目策劃項目計劃項目報告開發文檔需求設計測試代碼代碼目錄參考資料客戶資料等等基線庫：評審通過后的文檔《文檔同開發庫》測試庫：測試代碼和測試發布包文檔計劃用例測試報告代碼版本1版本2參考資料產品庫：測試通過后的文檔和代碼項目交付制品項目總結驗收報告。。。項目產品版本1版本2權限測試庫：測試人員可以讀寫其它人員只能讀，不能增加、修改和刪除基線庫：只能增加，不能刪除和修改產品庫：只能增加，不能刪除和修改開發庫：TestEnvironment測試環境測試需要一個獨立的環境DB獨立FTP等資源獨立Pass9等外部系統獨立最好是一個單獨的局域網環境，完全和開發分開開發是環境測試是環境每次測試，應當是一個完整的測試過程安裝系統DBWebAppServerClient其它配置系統DB配置AppServer配置系統初始化清除所有歷史數據執行初始化腳本，插入初始數據測試系統DevelopmentControlProcess開發控制流程項目啟動和策劃階段本階段的關鍵是定義項目、估算工作量和制定詳細計劃。一個軟件項目的正式啟動從《軟件項目任務書》的下達開始。任務書中寫明項目的基本信息及相關責任人和詳細分工，規定項目必須提交的產品清單。任務書由研發經理或者項目負責人起草，研發經理批準后下達給相關負責人。項目任務書必須為打印紙質文檔，由相關人員簽字確認后，入配置管理庫歸檔。軟件項目任務書主要作用是明確項目人員職責以及各組之間的協調確認。估算工作量，從確認需求后開始。由項目經理指定評估人員，先按照頭腦風暴法估計各個子系統或者模塊的難易程度，然后按照Delphi法估算各個部分的工作量。項目經理和PMO成員，根據估算的工作量，制定項目計劃。SQA和SCM分別制定各自的計劃。SCM需要確定資源庫的目錄結構和權限結構。項目經理召集PMO、SQA、SCM評審及審核項目計劃、SQA計劃、SQA審核計劃、SCM計劃和測試計劃。對于發布后的一般性程序修改，不需要下達軟件項目任務書。對于關系重大，需要各組人員協調工作的重大修改，項目負責人可以以任務書的形式明確職責、協調關系。測試負責人評估測試資源【人員及機器】，并決定測試人員是否介入項目的需求分析和設計階段。需求分析、設計、編碼階段本階段的關鍵是評審和修訂控制，關鍵評審需要需求、設計、編碼、測試、項目管理、用戶等的參與。需求階段，需求分析人員收集需求，根據SRS模版，作出需求規格說明書。設計階段，設計人員根據總體設計、概要設計、數據庫設計和詳細設計，作出設計文檔。編碼階段，編碼人員根據詳細設計，設計單元測試用例，編寫代碼，進行單元測試。關鍵評審：SRS評審，設計評審，代碼走查提交測試階段項目啟動后，項目經理填寫測試任務通知單，將測試任務下達給測試組。概要設計評審完成后，由各子系統或者模塊的負責人測算完成時間，在確定完成時間后（正式開始編碼前）將測試任務通知單提交給項目測試負責人，項目測試負責人審核通過在通知單上簽字后返回給子項目負責人。開發及單元測試完成后，由開發人員將測試內容提交配置管理員入測試庫后，將測試任務通知單提交給發布人員申請測試發布。發布人員將測試庫中本次測試的內容發布到測試機后，在測試任務通知單上簽字后，提交給測試人員開始測試。測試完成后，測試人員在任務單上填寫測試意見后，交測試負責人確認后，返還給開發人員。如測試沒有通過，開發人員修改測試內容，進入下一個測試流程。如通過測試，開發人員將測試任務通知單提交給項目負責人，由項目負責人、SCCB簽字確認后，提交配置管理員將測試內容入基線庫。過程關鍵：發布實施人員確保發布到測試機上的源程序在配置管理庫中得到了有效的標識。生產發布、終測程序通過測試入庫以后，根據需要，由項目的負責人負責填寫發布申請單。發布申請單由項目測試負責人、配置管理員、SCCB、客戶代表、研發經理簽字確認后，由項目負責人提交給實施發布人員。發布人員拿到簽完字的發布申請后，才能從基線庫中提取程序向生產機上發布。如以上發布確認人員沒有全部簽字同意發布，必須由項目經理簽字同意后發布。程序發布到生產機上以后，進入終測【UAT】流程。測試人員和用戶代表要對生產機上的程序進行最后測試，確保生產機上的系統符合需求。項目負責人負責同用戶協調，項目負責人、測試人員和用戶共同編寫測試用例。項目負責人將《終測意見書》提交三方簽字，根據簽字意見決定修訂系統或者提交正式發布。終測出現的問題修改按照基線變更流程進行。實施人員只有拿到有三方簽字的《終測意見書》后才能將系統正式公開發布。系統正式發布三天之后一周之內，由實施人員負責到用戶處取得有用戶主要負責人簽字的《系統運行報告》，項目負責人負責監督執行。根據《系統運行報告》做相應的處理。過程關鍵：發布到生產機上的程序都在基線庫中得到了有效的標識。發布后問題反饋修改過程系統發布之后，用戶反饋的意見要形成問題清單或者變更申請單，記錄需要修改的地方，提交給項目負責人。項目負責人負責判斷改動是否會影響需求或者設計，負責將任務分配給相關人員進行修改。修改完成后，提交測試直至發布。這個階段的最重要的是保證所做的修改（文檔、代碼）都在配置管理庫的基線庫中得到體現。即基線庫中的文檔和代碼要進行同步更新，關鍵是發布人員嚴格根據發布申請單進行控制，并確保發布的代碼都是從基線庫中取出的。沒有經過流程直接要求發布的，發布人員必須予以拒絕。

TSP團隊軟件過程會議組織會議前，確定會議主持人和記錄員向參與會議人員發送會議資料參與會議人員閱讀會議資料確定會議主題、日期時間和地點注意：留出閱讀資料的時間確定會議議程準備會議用品【如投影儀等】重要會議，需要簽到會議開始前，申明會議紀律發言時間限制發言順序除主持人外，不得打斷別人記錄員記錄會議紀要會議后，發送會議總結溝通問題原則目標明確明確反饋反復溝通請求－答復當有疑問時，發出請求明確求助對象，指定第一對象和輔助對象第一對象接收到請求后，不能及時答復的應當轉發給自己認為合適的答復人，并告知求助人求助方式【高－低】：當面，電話，郵件公告代碼走查項目負責人指定代碼走查對象相互走查循環走查代碼走查發現的問題首先記錄告知代碼作者更新CheckList其它PSP個人軟件過程工作原則計劃管理：把你想做的寫下來行為管理：按照你寫下來的去做報告管理：把做的事情記錄下來跟蹤管理：出現的問題要設法解決日常工作每日工作每日早晨，規劃當日工作；計劃必須細化到一個明確的目標計劃要有余地，比如會議等計劃是可執行的，能夠完成的計劃是可監控的每日下班，總結當日工作；計劃完成情況未能完成原因個人心得：新的發現，新的方法，新的問題會議會議之前，仔細閱讀會議資料如有疑問，可以發郵件向會議主持人提出或者在會議上提出會議中，記錄會議要點如要參與討論，請在別人發言結束后發言，不要打斷別人會議后，如有新的想法，發郵件或者當面向會議主持人提出求助如果一個問題20分鐘還不能理出一個頭緒，應當立即求助求助對象：個人認為能夠解決該問題的人為