第一篇：軟件開發(fā)過程規(guī)范（模版）

軟件開發(fā)過程規(guī)范

1目的為了規(guī)范軟件研發(fā)各個階段的開發(fā)行為，特制定此規(guī)范。

2適用范圍

本規(guī)范適用于研發(fā)中心軟件產(chǎn)品研發(fā)從立項，到開發(fā)實施、測試、結(jié)項的各個階段，規(guī)定了各開發(fā)階段的文檔編制、代碼編寫和資料備份內(nèi)容與要求。3術(shù)語和縮寫

研發(fā)項目干系人：公司內(nèi)部與研發(fā)項目有關(guān)聯(lián)的任何人。

項目計劃周期：從項目立項到計劃完成時間的實際工作日數(shù)。

項目實際周期：從項目立項到實際完成時間的實際工作日數(shù)。

項目質(zhì)量目標(biāo)：項目允許出現(xiàn)的總的缺陷數(shù)的加權(quán)平均值。

項目實際質(zhì)量：項目實際出現(xiàn)的總的缺陷數(shù)的加權(quán)平均值。

軟件缺陷：在測試過程中被發(fā)現(xiàn)的軟件bug，按照不同的嚴(yán)重程度分為四級；一級，系統(tǒng)崩潰，無法自動恢復(fù)，加權(quán)系數(shù)為100。

二級，系統(tǒng)功能無法實現(xiàn)或性能指標(biāo)無法達(dá)到，但不影響其他功能的使用，加權(quán)系數(shù)為2。

三級，系統(tǒng)功能實現(xiàn)不完整，加權(quán)系數(shù)為1。

四級，不影響系統(tǒng)功能和性能的小錯誤，忽略此錯誤系統(tǒng)可正常運行，加權(quán)系數(shù)為0.5。

加權(quán)缺陷數(shù)量：測試中出現(xiàn)的各種缺陷的數(shù)量乘以其對應(yīng)的加權(quán)系數(shù)，求和。4內(nèi)容和要求

4.1研發(fā)立項

4.1.1立項申請，產(chǎn)品研發(fā)經(jīng)過申請后才能立項，立項申請人可以是公司員工，也可以是公司各職能部門。

4.1.2立項申請人或委托其部門負(fù)責(zé)人召集相關(guān)人員討論通過，確定項目經(jīng)理并初步確定項目組成員。

4.1.2.1《研發(fā)立項申請書》由項目經(jīng)理負(fù)責(zé)編制。

4.1.2.2項目編號規(guī)則為，軟件項目：PS+編制日期；（硬件項目：PH+編制日期）。如：PS20070902。

4.1.2.3《研發(fā)立項申請書》要規(guī)定開發(fā)的產(chǎn)品的具體名稱，以及所屬各個系列的規(guī)格型號定義。

4.1.2.4《研發(fā)立項申請書》規(guī)定開發(fā)的產(chǎn)品的屬性，包括功能詳細(xì)描述，性能要求詳細(xì)描述和穩(wěn)定性要求詳細(xì)描述。

4.1.2.5《研發(fā)立項申請書》明確項目經(jīng)理和項目組成員。

4.1.2.6《研發(fā)立項申請書》明確項目的開始日期和計劃完成日期。

4.1.2.7《研發(fā)立項申請書》概要說明項目開發(fā)的資源需求，包括硬件設(shè)備、軟件工具、場地環(huán)境等。

4.1.2.8《研發(fā)立項申請書》確定項目的質(zhì)量目標(biāo)，包括各級缺陷的數(shù)量和測試周期，所制定的質(zhì)量目標(biāo)不允許有一級缺陷。

4.1.2.9《研發(fā)立項申請書》的編制格式參照《研發(fā)立項申請書模板》。

4.1.3《研發(fā)立項申請書》由研發(fā)項目經(jīng)理、主管軟件的研發(fā)經(jīng)理、營銷中心經(jīng)理認(rèn)可，主管研發(fā)副總經(jīng)理最終確認(rèn)。

4.1.4內(nèi)容變更：研發(fā)項目干系人可對申請對《研發(fā)立項申請書》的內(nèi)容進(jìn)行變更，變更后按申請的流程進(jìn)行簽字確認(rèn)，變更后的內(nèi)容重新填寫《研發(fā)立項申請書》并附在原申請書后。項目組成員的變更由研發(fā)內(nèi)部掌握，不必進(jìn)行變更申請。變更可在結(jié)項前的任何階段提出。

4.1.5項目撤銷，如遇重大變故造成所研發(fā)的項目已經(jīng)無實際意義或其他原因需要立即停止，可申請撤銷，申請人需是項目干系人，并具有中心經(jīng)理以上的級別，申請人負(fù)責(zé)編寫《研發(fā)項目撤銷申請書》,說明撤銷原因，撤銷申請需得到項目經(jīng)理、主管軟件的研發(fā)經(jīng)理、營銷中心經(jīng)理和主管研發(fā)副中經(jīng)理認(rèn)可，經(jīng)由總經(jīng)理批準(zhǔn)后生效。撤銷申請可在結(jié)項前的任何階段提出。

4.2研發(fā)

4.2.1研發(fā)立項確定后，項目經(jīng)理需編寫《項目研發(fā)計劃書》。

4.2.1.1《項目研發(fā)計劃書》初步制定項目開發(fā)的任務(wù)列表和模塊劃分，以及項目組人員的模塊歸屬和工作時間安排。

4.2.1.2《項目研發(fā)計劃書》可以用通用的項目管理工具來完成，編制格式由項目經(jīng)理確定，推薦使用Microsoft Project。

4.2.1.3《項目研發(fā)計劃書》由項目組成員認(rèn)可。

4.2.1.5項目經(jīng)理可根據(jù)實際情況和設(shè)計的深入，隨時變更《項目研發(fā)計劃書》。

4.2.1.6主管軟件的研發(fā)經(jīng)理可抽查《項目研發(fā)計劃書》的編制和實施情況，并給出改進(jìn)建議。

4.2.2研發(fā)設(shè)計

4.2.2.1《軟件需求分析說明書》

4.2.2.1.1軟件項目需編制《軟件需求分析說明書》。

4.2.2.1.2《軟件需求分析說明書》由項目經(jīng)理或其委托人編制。

4.2.2.1.3《軟件需求分析說明書》確定整個系統(tǒng)的物理結(jié)構(gòu)和部署要求，并根據(jù)系統(tǒng)的物理結(jié)構(gòu)進(jìn)行模塊劃分，確定各個模塊的功能范圍和模塊間的接口方式。詳細(xì)說明系統(tǒng)規(guī)模要求和運行環(huán)境限制，并指出系統(tǒng)運行所需資源的要求。明確開發(fā)和系統(tǒng)運行所需軟硬件資源的要求。確定項目進(jìn)行一次全面測試所需要的測試人員人數(shù)和測試周期。《軟件項目需求分析說明書》的格式參照《軟件項目需求分析說明書模板》。在軟件需求分析過程中，如果軟件有用戶界面，要在此階段進(jìn)行界面的初步設(shè)計，為了提高效率，界面草圖的繪制不限定形式和格式。

4.2.2.1.4《軟件需求分析說明書》由項目組全體成員認(rèn)可，主管軟件的研發(fā)經(jīng)理最終確認(rèn)。

4.2.2.1.5《軟件需求分析說明書》的變更，在開發(fā)過程中，項目組成員可提出對《軟件需求分析說明書》的變更申請，變更的范圍限于不能違背《研發(fā)立項申請書》的要求，即不能有涉及到《研發(fā)立項申請書》變更的內(nèi)容，如果有，需要做《研發(fā)立項申請書》變更的流程?！盾浖枨蠓治稣f明書》變更的主要目的是修正其中的錯誤，或者經(jīng)過變更可提高產(chǎn)品的品質(zhì)或性能指標(biāo)或縮短產(chǎn)品的研發(fā)周期。《軟件需求分析說明書》的變更需得到項目經(jīng)理的同意，必要時由項目經(jīng)理召集相關(guān)技術(shù)人員和項目組成員召開簡短的技術(shù)會議進(jìn)行論證。項目經(jīng)理將變

更后的內(nèi)容形成新版本的《軟件項目需求分析說明書》，由主管軟件的研發(fā)經(jīng)理最終確認(rèn)。

4.2.2.2《軟件概要設(shè)計說明書》

4.2.2.2.1軟件項目需編制《軟件概要設(shè)計說明書》。

4.2.2.2.2《軟件概要設(shè)計說明書》由項目經(jīng)理或其委托人編制。

4.2.2.2.3《軟件概要設(shè)計說明書》確定整個系統(tǒng)的邏輯結(jié)構(gòu)，并對需求分析中各物理模塊進(jìn)行邏輯模塊劃分，詳細(xì)描述各邏輯模塊的業(yè)務(wù)規(guī)則和模塊之間的接口以及重要的內(nèi)部接口，確定系統(tǒng)級的全局變量和數(shù)據(jù)結(jié)構(gòu)，確定各邏輯模塊所包含的程序文件名稱和使用的開發(fā)工具，描述每個文件中所包含的函數(shù)功能。確定數(shù)據(jù)庫的類型和所有數(shù)據(jù)表名稱及數(shù)據(jù)表的用途，確定數(shù)據(jù)庫的訪問方式。詳細(xì)描述系統(tǒng)的配置方式。如果軟件有用戶界面，要對界面進(jìn)行詳細(xì)設(shè)計，確定所有界面的名稱、規(guī)格及界面上的元素類型及功能，界面設(shè)計可在開發(fā)工具中直接繪制，也可采用其他繪圖方式，但在概要設(shè)計文檔中要保留圖示并進(jìn)行詳細(xì)說明。格式參照《軟件項目概要設(shè)計說明書模板》。

4.2.2.2.4《軟件概要設(shè)計說明書》由項目組全體成員認(rèn)可，主管軟件的研發(fā)經(jīng)理最終確認(rèn)。

4.2.2.2.5《軟件概要設(shè)計說明書》的變更，在開發(fā)過程中，項目組成員可提出對《軟件概要設(shè)計說明書》的變更申請，變更范圍限于不得違背《研發(fā)立項申請書》和《軟件需求分析說明書》的要求，所涉及的變更不至于影響到《研發(fā)立項申請書》和《軟件需求分析說明書》的變更，如果有，需要做《研發(fā)立項申請書》的變更流程或者《軟件需求分析說明書》的變更流程。《軟件概要設(shè)計說明書》變更的主要目的是修正其中的錯誤，或者經(jīng)過變更可提高產(chǎn)品的品質(zhì)或性能指標(biāo)或縮短產(chǎn)品的研發(fā)周期。概要設(shè)計說明書的變更需得到項目經(jīng)理的同意，必要是由項目經(jīng)理召集相關(guān)技術(shù)人員和項目組成員召開簡短的技術(shù)會議進(jìn)行論證。項目經(jīng)理將變更后的內(nèi)容寫入新版本的《軟件項目概要設(shè)計說明書》，主管軟件的研發(fā)經(jīng)理最終簽字確認(rèn)。

4.2.2.3軟件詳細(xì)設(shè)計

4.2.2.3.1軟件詳細(xì)設(shè)計由項目經(jīng)理指派，項目組成員分擔(dān)完成。

4.2.2.3.2軟件項目詳細(xì)設(shè)計的內(nèi)容及格式要求，軟件項目的詳細(xì)設(shè)計根據(jù)《軟件概要設(shè)計說明書》劃分的各個邏輯模塊包含的程序文件，確定每個程序文件中所包含的函數(shù)的詳細(xì)描述，要求有函數(shù)的功能描述、輸入輸出說明、使用規(guī)則和限制，如有必要，還可以描述函數(shù)的實現(xiàn)流程。詳細(xì)描述軟件中所有全局變量的格式、初始值、用途和使用規(guī)則。詳細(xì)描述軟件中所有的數(shù)據(jù)結(jié)構(gòu)和類結(jié)構(gòu)。詳細(xì)描述數(shù)據(jù)庫中的數(shù)據(jù)表，確定數(shù)據(jù)表的的每個字段，以及數(shù)據(jù)表之間的關(guān)系，確定所有的視圖、觸發(fā)器和存儲過程。詳細(xì)設(shè)計文檔不做具體的格式要求，為了提高研發(fā)效率，可以把詳細(xì)設(shè)計作為代碼的一部分，直接在程序中編寫，編寫時要遵循《研發(fā)中心軟件編碼標(biāo)準(zhǔn)》的規(guī)定。

4.2.2.3.3項目經(jīng)理負(fù)責(zé)組織對詳細(xì)設(shè)計進(jìn)行審核，審核方式可采用項目經(jīng)理主審和項目成員互審相結(jié)合的方式，主要審核詳細(xì)設(shè)計和概要設(shè)計及需求分析的符合性，及詳細(xì)設(shè)計的正確性。主管軟件的研發(fā)經(jīng)理可組織相關(guān)技術(shù)人員對詳細(xì)設(shè)計情況進(jìn)行抽查。

4.2.2.3.4詳細(xì)設(shè)計的變更，可在項目開發(fā)的任何時段進(jìn)行，由項目成員在得到項目經(jīng)理的口頭同意后進(jìn)行，要在變更處做好變更記錄。

4.2.2.4質(zhì)量控制

4.2.2.4.1項目組內(nèi)部互審，在項目的開發(fā)過程中，項目經(jīng)理可組織項目組成員對編制的代碼進(jìn)行互相審核，目的是審查代碼是否符合《研發(fā)中心軟件編碼標(biāo)準(zhǔn)》的要求，并在聯(lián)調(diào)前找到代碼中的缺陷，審核時要做好審核記錄，內(nèi)容為代碼的編寫人、審核人、缺陷位置、缺陷描述和改進(jìn)建議，格式由項目經(jīng)理決定。根據(jù)項目的具體情況，項目經(jīng)理有權(quán)決定不進(jìn)行代碼的互審。

4.2.2.4.2研發(fā)中心內(nèi)部抽查審核，在項目的開發(fā)過程中，主管軟件的研發(fā)經(jīng)理可組織相關(guān)人員對項目組的開發(fā)質(zhì)量進(jìn)行抽查審核，被審核的代碼模塊由研發(fā)經(jīng)理確認(rèn)，審核的主要目的是驗證的代碼書寫的規(guī)范性和與設(shè)計的符合性。在評審中發(fā)現(xiàn)問題，主管軟件的研發(fā)經(jīng)理可口頭通知項目經(jīng)理進(jìn)行整改，問題嚴(yán)重時，可對項目組下達(dá)《軟件整改通知單》，通知項目組進(jìn)行整改。具體使用何種方式由主管軟件的研發(fā)經(jīng)理確定?！盾浖耐ㄖ獑巍废逻_(dá)后，按比例扣除項目組的項目獎金，扣除辦法參見《研發(fā)軟件項目獎金發(fā)放制度》。

4.2.2.4.3項目組內(nèi)部集成驗證測試，項目經(jīng)理可在代碼完成后組織內(nèi)部集成測試，并同時指派項目組成員進(jìn)行《軟件使用說明書》的編制，在內(nèi)部集成測試結(jié)束，《軟件使用說明書》完成后，項目經(jīng)理可申請?zhí)峤卉浖腶測試。

4.2.2.4.4《a測試申請書》，項目經(jīng)理負(fù)責(zé)編制《a測試申請書》，格式參照《a測試申請書模板》。編制完畢后，與《軟件使用說明書》一起提交給主管軟件的研發(fā)經(jīng)理進(jìn)行審核確認(rèn)，主管軟件的研發(fā)經(jīng)理簽字同意后，指定項目的測試人員，進(jìn)行a測試。

4.2.2.4.5測試人員根據(jù)《研發(fā)立項申請書》和《軟件使用說明書》的要求與內(nèi)容，編制《軟件測試大綱》，確定要測試的具體項目以及對這些項目的要求，《軟件測試大綱》編制完成后要由項目經(jīng)理認(rèn)可，主管軟件的研發(fā)經(jīng)理確認(rèn)。同時項目組負(fù)責(zé)協(xié)助測試環(huán)境的搭建。

4.2.2.4.6在一輪測試結(jié)束后，測試人員出具《項目測試報告》。項目組對測試出的問題進(jìn)行修改，然后再申請新一輪的測試，新的一輪測試由項目經(jīng)理決定是進(jìn)行驗證性測試還是完整測試，如果是驗證性測試，可由項目經(jīng)理確定測試內(nèi)容范圍并和測試經(jīng)理協(xié)商測試周期，循環(huán)上述過程直到項目經(jīng)理認(rèn)為可以結(jié)束測試。為了保證測試質(zhì)量，要求最后一次測試必須是完整測試。測試結(jié)束后，測試人員要編制《測試過程總結(jié)報告》。

4.3研發(fā)結(jié)項

4.3.1測試結(jié)束后，項目經(jīng)理可決定對項目進(jìn)行結(jié)項提交。

4.3.2項目經(jīng)理負(fù)責(zé)編制《研發(fā)結(jié)項申請書》，格式參照《研發(fā)結(jié)項申請書模板》。

4.3.3《研發(fā)結(jié)項申請書》要對所存留的問題進(jìn)行詳細(xì)描述。

4.3.4《研發(fā)結(jié)項申請書》說明項目的實際開發(fā)周期，與計劃周期的差異將作為項目獎金的評定依據(jù)。

4.3.5《研發(fā)結(jié)項申請書》要說明項目質(zhì)量目標(biāo)的實現(xiàn)情況，根據(jù)《測試過程總結(jié)報告》統(tǒng)計出項目的實際質(zhì)量，與計劃質(zhì)量目標(biāo)的差異將作為項目獎金的評定依據(jù)。

4.3.6《研發(fā)結(jié)項申請書》中所存留問題部分的內(nèi)容需由此項目的實際測試人員進(jìn)行確認(rèn)。

4.3.7《研發(fā)結(jié)項申請書》由項目經(jīng)理、主管軟件的研發(fā)經(jīng)理、營銷中心經(jīng)理、技服中心經(jīng)理認(rèn)可后，由主管研發(fā)副總經(jīng)理最終確認(rèn)。

4.3.4項目提交后，項目經(jīng)理出具《軟件項目信息統(tǒng)計表》，由主管軟件的研發(fā)

經(jīng)理認(rèn)可，主管研發(fā)副總經(jīng)理最終確認(rèn)，作為項目獎金分配的依據(jù)。

4.4技術(shù)資料的管理與備份

4.4.1項目經(jīng)理負(fù)責(zé)技術(shù)資料的管理與備份，備份內(nèi)容包括項目所涉及的文檔、代碼和其他相關(guān)技術(shù)資料。

4.4.2項目立項后，項目組要在代碼管理服務(wù)器上建立專門的項目目錄。

4.4.3在研發(fā)過程中，項目組不定期的向代碼管理服務(wù)器進(jìn)行代碼備份，備份時機(jī)由項目經(jīng)理決定。

4.4.4項目提交測試前要進(jìn)行一次完整備份。

4.4.5項目結(jié)項后，要進(jìn)行一次完整備份，并將最終項目內(nèi)容刻錄光盤備檔。

4.4.6備檔后的光盤由主管軟件的研發(fā)經(jīng)理統(tǒng)一管理。

4.4.7在研發(fā)過程中，紙質(zhì)文檔由項目經(jīng)理負(fù)責(zé)管理，項目結(jié)項后提交到主管軟件的研發(fā)經(jīng)理備檔。

4.4.8由于項目組備份不及時和備份管理不到位造成項目資料丟失，致使開發(fā)周期延誤的，每發(fā)生一次按比例扣發(fā)項目經(jīng)理的項目獎金，造成重大損失的，全部扣發(fā)項目經(jīng)理項目獎金，并根據(jù)具體情況追究其責(zé)任,是否為重大損失由主管軟件的研發(fā)經(jīng)理確認(rèn)。獎金的扣發(fā)辦法參照《研發(fā)軟件項目獎金發(fā)放制度》。5職責(zé)和權(quán)限

5.1主管研發(fā)副總經(jīng)理負(fù)責(zé)本規(guī)范的編制、發(fā)布、維護(hù)與解釋。

5.2主管軟件的研發(fā)經(jīng)理負(fù)責(zé)推動和監(jiān)督本規(guī)范的實施。

5.3公司所有員工可對本規(guī)范提出修改意見。

6歷史記錄

本規(guī)范于2007年9月25日編制完成，形成V1.0版。

V1.0于2007年11月1日開始施行

第二篇：規(guī)范軟件開發(fā)過程——軟件配置管理實踐

規(guī)范軟件開發(fā)過程——軟件配置管理實踐

2010-05-19 來源：網(wǎng)絡(luò)

隨著軟件系統(tǒng)的規(guī)模、復(fù)雜度日益上升，軟件開發(fā)過程管理已經(jīng)成為保證軟件系統(tǒng)開發(fā)效率、質(zhì)量、成本的關(guān)鍵性因素。作為軟件開發(fā)過程中質(zhì)量保障的重要組成部分，行之有效的軟件配置管理（以下簡稱SCM，Software Configuration Management）能夠顯著提高軟件開發(fā)組織的自身能力、提高軟件開發(fā)過程的完整性，以及降低軟件開發(fā)的風(fēng)險。

軟件配置管理的概念

ISO 9000、CMM、ISO/IEC 12207、IEEE 729-1983對SCM的定義有不同的描述。ISO9000定義SCM為“一個管理學(xué)科，它對配置項的開發(fā)和支持生命周期給予技術(shù)上和管理上的指導(dǎo)。配置管理取決于項目的規(guī)模、復(fù)雜程度和風(fēng)險大小”。

CMM2將SCM定義為一個關(guān)鍵過程域KPA，是“貫穿于整個軟件過程中的保護(hù)性活動，它被設(shè)計來（1）標(biāo)識變化，（2）控制變化，（3）保證變化被適當(dāng)?shù)陌l(fā)現(xiàn)（4）向其他可能有興趣的人員報告變化。”。SCM包括了配置項識別、工作空間管理、版本控制、變更控制、狀態(tài)報告、配置審計等活動，其中以版本控制最為核心和關(guān)鍵。

數(shù)據(jù)集中工程軟件配置管理策略

1、數(shù)據(jù)集中工程項目背景

中國建設(shè)銀行數(shù)據(jù)集中工程的目標(biāo)是通過建立總行級的數(shù)據(jù)中心，向全行38個一級分行、20000多個網(wǎng)點提供完整的核心金融服務(wù)。其核心應(yīng)用系統(tǒng)DCC-CCBS包括主機(jī)、前置、前端三大部分。主機(jī)應(yīng)用部分部署在總行級數(shù)據(jù)中心，前置應(yīng)用部分部署在數(shù)據(jù)中心前置通信網(wǎng)關(guān)、各一級分行業(yè)務(wù)大前置，前端部分部署在網(wǎng)點。

DCC-CCBS項目的SCM需要實現(xiàn)開發(fā)、發(fā)布、部署的全過程軟件配置管理。開發(fā)過程SCM的核心是系統(tǒng)源碼版本管理；發(fā)布過程的SCM核心是系統(tǒng)目標(biāo)碼版本管理；部署過程以確保系統(tǒng)目標(biāo)碼版本在數(shù)據(jù)中心、一級分行、網(wǎng)點和外系統(tǒng)的正確部署為首要目標(biāo)。

2、開發(fā)過程軟件配置管理

系統(tǒng)源碼版本除系統(tǒng)源程序、參數(shù)外，還包括需求規(guī)格說明書、系統(tǒng)總體架構(gòu)設(shè)計說明書、主機(jī)/前置/前端系統(tǒng)結(jié)構(gòu)設(shè)計說明書、各子系統(tǒng)的詳細(xì)設(shè)計說明書、各子系統(tǒng)的對外接口規(guī)范、業(yè)務(wù)操作手冊、系統(tǒng)使用手冊、系統(tǒng)安裝維護(hù)手冊等文檔。根據(jù)配置項的不同屬性，經(jīng)過評審，形成需求基線、設(shè)計基線和源代碼基線等不同的基線。開發(fā)過程SCM按照子系統(tǒng)的性質(zhì)，分為主機(jī)、前置、前端三部分獨立管理。

DCC-CCBS項目總體組負(fù)責(zé)整個需求和變更的控制。通過審批的需求按照功能分布分解為主機(jī)、前置、前端的子需求，再由各部門分別管理和實現(xiàn)。環(huán)境及版本控制小組負(fù)責(zé)向各部門提出形成“系統(tǒng)基線”的要求，以同步主機(jī)、前置、前端的源碼版本。

3、發(fā)布過程軟件配置管理

發(fā)布過程的系統(tǒng)目標(biāo)碼版本包括系統(tǒng)目標(biāo)碼（執(zhí)行碼）、系統(tǒng)參數(shù)及相關(guān)文檔等。按照用途，系統(tǒng)目標(biāo)碼版本可分為測試版和正式版。以前置平臺為例，發(fā)布過程SCM的主要活動包括：構(gòu)建環(huán)境管理，保證編譯環(huán)境的純凈性和正確性；

構(gòu)建過程管理，保證構(gòu)建過程的自動化操作，及其正確性和完整性；

版本編號管理，統(tǒng)一版本命名規(guī)則，確保目標(biāo)碼版本號的唯一性和可追蹤性；

目標(biāo)碼版本生成管理，從各版本管理工具系統(tǒng)收集、整理、打包相應(yīng)的目標(biāo)碼、參數(shù)和文檔，形成完整的或部分（補(bǔ)?。┑哪繕?biāo)碼版本；

配置狀態(tài)檢查，檢查目標(biāo)碼版本包中內(nèi)容的正確性、完整性和一致性；

4、部署過程軟件配置管理

部署過程SCM的主要任務(wù)是：建立安全、可靠和迅速的傳輸流程和傳輸渠道；建立目標(biāo)碼版本記錄和追蹤機(jī)制、版本運行時刻檢查機(jī)制和版本恢復(fù)機(jī)制；確保正確的版本、按照正確的渠道、在規(guī)定時間遞交到正確的用戶并生效。

在DCC-CCBS生產(chǎn)環(huán)境中，軟件開發(fā)中心將通過數(shù)據(jù)中心版本管理系統(tǒng)發(fā)布各單位所需的目標(biāo)碼版本，各單位在版本管理系統(tǒng)和數(shù)據(jù)傳輸通道的支持下，實現(xiàn)版本/補(bǔ)丁的主動分發(fā)、查詢、下載和生效。

軟件配置管理實施經(jīng)驗

1、樹立正確的企業(yè)配置管理意識

SCM是一門管理學(xué)科。歸根結(jié)底，其關(guān)鍵是“管理”，然后才是“軟件配置”。項目級SCM能否成功實施，與企業(yè)的軟件配置管理目標(biāo)、策略、能力、組織和資源息息相關(guān)。

2、提高全員的配置管理素質(zhì)

SCM是規(guī)則和流程的集合，需要依靠流程中所有部門和人員共同的支持和努力。任何環(huán)節(jié)上的疏忽和懈怠，都將直影響SCM的實施效果。

3、采用合適的工具

功能強(qiáng)大的或昂貴的工具未必是合適的工具。往往20%的功能即可解決80％的配置管理問題。目前比較流行的版本管理工具包括CVS、PVCS、ClearCase、Harvest、VSS、Endeavor等。在選擇具體工具時，往往需要考慮以下因素：（1）工具將要使用的范圍；（2）工具自身的功能、穩(wěn)定性、擴(kuò)展行，以及對環(huán)境的要求；（3）工具使用的復(fù)雜度；（4）工具與其他流程和工具的集成度和交互性；（5）工具的投資和維護(hù)費用。

4、及時的檢查和梳理

大系統(tǒng)開發(fā)過程中，配置管理往往采用分步離散管理方式，因此保證整個系統(tǒng)配置管理的完整性成為一件精密細(xì)致的工作，需要投入大量人力及時修訂基線，防微杜漸，避免混亂，以滿足對配置管理正確性、完整性和及時性的要求。

5、系統(tǒng)化思考、分步實施、持續(xù)改進(jìn)

SCM不是一項孤立的管理活動。企業(yè)的戰(zhàn)略目標(biāo)、管理能力、文化背景、組織結(jié)構(gòu)，項目的規(guī)模、性質(zhì)、技術(shù)、人員等都是影響SCM決策的重要因素。因此需要在項目乃至企業(yè)的整體環(huán)境中系統(tǒng)的考慮SCM的實施策略和方法。

通過分階段實施量化的、漸進(jìn)的配置管理目標(biāo)，可以避免由于引入復(fù)雜管理流程所造成的混亂，有利于方便靈活地優(yōu)化配置管理流程。同時，階段性目標(biāo)的實現(xiàn)將有助于整個團(tuán)隊提高士氣、增強(qiáng)信心，并逐步提高開發(fā)隊伍的配置管理素質(zhì)。

第三篇：軟件開發(fā)過程及崗位職責(zé)

軟件開發(fā)過程及崗位職責(zé)

本文主要講述如何組織開發(fā)軟件項目，使之更加快速、有效的完成。并分成以下幾個階段進(jìn)行詳細(xì)講述：項目計劃階段、需求分析階段、軟件開發(fā)階段、測試階段、管理軟件開發(fā)過程、各參與角色的具體職責(zé)描述及對人員的要求。最后提供了一些文檔標(biāo)準(zhǔn)參考。

本開發(fā)過程可以作為中小型（3-7人）軟件項目的開發(fā)指南，而大型軟件項目使用RUP會更好。

總體流程如下：

計劃階段－》需求分析階段－》軟件開發(fā)階段－》測試階段－》完成一、項目計劃階段

項目計劃草案和風(fēng)險管理計劃作為第一步，當(dāng)有一個商業(yè)機(jī)會后，根據(jù)公司高層負(fù)責(zé)制定的初步商業(yè)計劃書來完成項目的計劃草案，確定、分析項目風(fēng)險并確定其優(yōu)先級，還要制定風(fēng)險解決方案。本階段的目的是確立產(chǎn)品開發(fā)的經(jīng)濟(jì)理由。

當(dāng)確定開發(fā)之后則制定軟件開發(fā)計劃、人員組織結(jié)構(gòu)定義及配備、過程控制計劃。

（1）項目計劃草案

項目計劃草案應(yīng)包括產(chǎn)品簡介、產(chǎn)品目標(biāo)及功能說明、開發(fā)所需的資源、開發(fā)時間和里程碑。

（2）風(fēng)險管理計劃

也就是把有可能出錯或現(xiàn)在還不能確定的東西列出來，并制定出相應(yīng)的解決方案。風(fēng)險發(fā)現(xiàn)得越早對項目越有利。

（3）軟件開發(fā)計劃

軟件開發(fā)計劃的目的是收集控制項目時所需的所有信息，項目經(jīng)理根據(jù)項目計劃來安排資源需求并根據(jù)時間表跟蹤項目進(jìn)度。項目團(tuán)隊成員根據(jù)項目計劃以了解他們的工作任務(wù)、工作時間以及他們所依賴的其他活動。

可將計劃分成總體計劃和詳細(xì)計劃，總體計劃中每個任務(wù)為一個里程碑，詳細(xì)計劃中必須將任務(wù)落實到個人。

軟件開發(fā)計劃還應(yīng)包括產(chǎn)品的應(yīng)收標(biāo)準(zhǔn)及應(yīng)收任務(wù)（包括確定需要制訂的測試用例）。

（4）人員組織結(jié)構(gòu)定義及配備

常見的人員組織結(jié)構(gòu)有垂直方案、水平方案、混合方案。垂直方案中每個成員充當(dāng)多重角色。水平方案中每個成員充當(dāng)一到兩個角色?；旌戏桨竸t包括了經(jīng)驗豐富的人員與新手相互融合。具體選擇根據(jù)人員實際技能情況進(jìn)行選擇。

（5）過程控制計劃

過程控制計劃的目的是收集項目計劃正常執(zhí)行所需的所有信息，用來指導(dǎo)項目進(jìn)度的監(jiān)控、計劃的調(diào)整，確保項目按時完成。

二、需求分析階段

需求分析階段的目的是在系統(tǒng)工作方面與用戶達(dá)成一致。

（1）軟件需求規(guī)約

詳細(xì)說明系統(tǒng)將要實現(xiàn)的所有功能。

（2）用戶界面原型

可以有三種表示方法：圖紙（在紙上）、位圖（繪圖工具）、可執(zhí)行文件（交互式）。

三、軟件開發(fā)階段

本階段從物理上實現(xiàn)目標(biāo)系統(tǒng)。采用了面向?qū)ο蠓椒ā?/p>

（1）軟件架構(gòu)

說明軟件的組織結(jié)構(gòu)、部署結(jié)構(gòu)及運行環(huán)境。

（2）類設(shè)計

定義類之間的關(guān)聯(lián)和類的屬性、方法。

（3）數(shù)據(jù)庫設(shè)計

定義數(shù)據(jù)庫表之間的關(guān)聯(lián)和各個表的字段。

（4）編碼和單元測試

按照設(shè)計文檔進(jìn)行編碼，每完成一個模塊應(yīng)進(jìn)行單元測試。

（5）集成系統(tǒng)

按軟件組織結(jié)構(gòu)的要求將各個子系統(tǒng)組合起來。

四、測試階段

測試的目的是在發(fā)布之前找出程序的錯誤。包括：核實每個模塊是否正常運行（參考設(shè)計文檔）、核實需求是否被正確實施（參考需求文檔）。

（1）測試計劃

收集和組織測試信息，為測試工作提供指導(dǎo)。

（2）測試數(shù)據(jù)

盡量使用真實數(shù)據(jù)。

（3）測試報告

記錄測試結(jié)果，詳細(xì)描述問題，提出解決辦法。

（4）幫助文件和用戶操作手冊

五、管理軟件開發(fā)過程

有以下幾方面地工作：

（1）組織會議

討論會議、總結(jié)會議等。

（2）評審程序

對各個階段的工作結(jié)果進(jìn)行審核。

（3）協(xié)調(diào)人員

（4）配置管理

使用一些配置管理工具進(jìn)行開發(fā)文檔管理，如：Visual Sourcesafe，Teamsouce等

六、各參與角色的具體職責(zé)描述及對人員的要求

（1）項目經(jīng)理

職責(zé)：

1、制定產(chǎn)品的目標(biāo)。

2、制定各個工作的詳細(xì)任務(wù)表，跟蹤這些任務(wù)的執(zhí)行情況，進(jìn)行控制。

3、組織會議對程序進(jìn)行評審。

4、綜合具體情況，對各種不同方案進(jìn)行取舍并做出決定。

5、協(xié)調(diào)各項目參與人員之間的關(guān)系。

人員要求：

對產(chǎn)品有激情，具有領(lǐng)導(dǎo)才能。

對問題能正確而迅速地做出確定。

能充分利用各種渠道和方法來解決問題。

能跟蹤任務(wù)，有很好地日程觀念。

能在壓力下工作。

（2）系統(tǒng)分析員

職責(zé)：

1、了解用戶需求，寫出《軟件需求規(guī)約》。

2、建立用戶界面原型。

人員要求：

擔(dān)任系統(tǒng)分析員的人員應(yīng)該善于協(xié)調(diào)，并且具有良好的溝通技巧。擔(dān)任此角色的人員中必須要有具備業(yè)務(wù)和技術(shù)領(lǐng)域知識的人才。

（3）設(shè)計員

職責(zé)：

1、定義類的方法和屬性以及各個類之間的關(guān)聯(lián)，畫出類圖。

2、進(jìn)行數(shù)據(jù)庫設(shè)計。

人員要求：

掌握面向?qū)ο蠓治雠c設(shè)計技術(shù)，統(tǒng)一建模語言(UML)。

（4）程序員

職責(zé)：

按項目的要求進(jìn)行編碼和單元測試。

人員要求：

良好的編程技能和測試技術(shù)。

（5）測試員

職責(zé)：

執(zhí)行測試，描述測試結(jié)果，提出問題解決方案。

人員要求：

了解被測試的系統(tǒng)，具備診斷和解決問題的技能，編程技能

根據(jù)每個人的特長來擔(dān)任其中的一個或多個角色。最好是每個人都能參與設(shè)計和編碼工作，每個人都能夠建立起系統(tǒng)的全局觀。

第四篇：標(biāo)準(zhǔn)的軟件開發(fā)過程

標(biāo)準(zhǔn)的軟件開發(fā)過程

軟件開發(fā)的標(biāo)準(zhǔn)過程包括六個階段，而六個階段需要編寫的各類文件達(dá)14種之多，在每個階段需要編寫哪些文件，以及這些文件的主要內(nèi)容見下：

1.可行性與計劃研究階段

可行性研究報告：在可行性研究與計劃階段內(nèi)，要確定該軟件的開發(fā)目標(biāo)和總的要求，要進(jìn)行可行性分析、投資一收益分析、制訂開發(fā)計劃，并完成應(yīng)編制的文件。

項目開發(fā)計劃：編制項目開發(fā)計劃的目的是用文件的形式，把對于在開發(fā)過程中各項工作的負(fù)責(zé)人員、開發(fā)進(jìn)度、所需經(jīng)費預(yù)算、所需軟、硬件條件等問題作出的安排記載下來，以便根據(jù)本計劃開展和檢查本項目的開 發(fā)工作。

2.需求分析階段

軟件需求說明書：軟件需求說明書的編制是為了使用戶和軟件開發(fā)者雙方對該軟件的初始規(guī)定有一個共同的理解，使之成為整個開發(fā)工作的基礎(chǔ)。內(nèi)容包括對功能的規(guī)定對性能的規(guī)定等。

數(shù)據(jù)要求說明書：數(shù)據(jù)要求說明書的編制目的是為了向整個開發(fā)時期提供關(guān)于被處理數(shù)據(jù)的描述和數(shù)據(jù)采集要求的技術(shù)信息。

初步的用戶手冊：用戶手冊的編制是要使用非專門術(shù)語的語言，充分地描述該軟件系統(tǒng)所具有的功能及基本的使用方法。使用戶（或潛在用戶）通過本手冊能夠了解該軟件的用途，并且能夠確定在什么情況下，如何使用它。

3.設(shè)計階段

概要設(shè)計說明書：概要設(shè)計說明書又可稱系統(tǒng)設(shè)計說明書，這里所說的系統(tǒng)是指程序系統(tǒng)。編制的目的是說明對程序 系統(tǒng)的設(shè)計考慮，包括程序系統(tǒng)的基本處理流程、程序系統(tǒng)的組織結(jié)構(gòu)、模塊劃分、功能分配、接口設(shè)計。運行設(shè)計、數(shù)據(jù)結(jié)構(gòu)設(shè)計和出錯處理設(shè)計等，為程序的詳細(xì)設(shè)計提供基礎(chǔ)。

詳細(xì)設(shè)計說明書：詳細(xì)設(shè)計說明書又可稱程序設(shè)計說明書。編制目的是說明一個軟件系統(tǒng)各個層次中的每一個程序（每個模塊或子程序）的設(shè)計考慮，如果一個軟件系統(tǒng)比較簡單，層次很少，本文件可以不單獨編寫，有關(guān) 內(nèi)容合并入概要設(shè)計說明書。

數(shù)據(jù)庫設(shè)計說明書：數(shù)據(jù)庫設(shè)計說明書的編制目的是對于設(shè)計中的數(shù)據(jù)庫的所有標(biāo)識、邏輯結(jié)構(gòu)和物理結(jié)構(gòu)作出具體的設(shè)計規(guī)定。

測試計劃初稿：這里所說的測試，主要是指整個程序系統(tǒng)的組裝測試和確認(rèn)測試。本文件的編制是為了提供一個對該軟件的測試計劃，包括對每項測試活動的內(nèi)容、進(jìn)度安排、設(shè)計考慮、測試數(shù)據(jù)的整理方法及評價準(zhǔn)則。

4.實現(xiàn)階段

模塊開發(fā)卷宗（開始編寫）：模塊開發(fā)卷宗是在模塊開發(fā)過程中逐步編寫出來的，每完成一個模塊或一組密切相關(guān)的模塊的復(fù)審時編寫一份，應(yīng)該把所有的模塊開發(fā)卷宗匯集在一起。編寫的目的是記錄和匯總低層次開發(fā)的進(jìn)度和結(jié)果，以便于對整個模塊開發(fā)工作的管理和復(fù)審，并為將來的維護(hù)提供非常有用的技術(shù)信息。

用戶手冊完工

操作手冊：操作手冊的編制是為了向操作人員提供該軟件每一個運行的具體過程和有關(guān)知識，包括操作方法的細(xì)節(jié)。

測試計劃終稿：

5.測試階段

模塊開發(fā)卷宗(此階段內(nèi)必須完成)

測試分析報告：測試分析報告的編寫是為了把組裝測試和確認(rèn)測試的結(jié)果、發(fā)現(xiàn)及分析寫成文件加以記載。

項目開發(fā)總結(jié)報告：項目開發(fā)總結(jié)報告的編制是為了總結(jié)本項目開發(fā)工作的經(jīng)驗，說明實際取得的開發(fā)結(jié)果以及對整個開發(fā)工作的各個方面的評價。

6.運行與維護(hù)階段

開發(fā)進(jìn)度月報的編制目的是及時向有關(guān)管理部門匯報項目開發(fā)的進(jìn)展和情況，以便及時發(fā)現(xiàn)和處理開發(fā)過程中出現(xiàn)的問題。一般地，開發(fā)進(jìn)度月報是以項目組為單位每月編寫的。如果被開發(fā)的軟件系統(tǒng)規(guī)模比較大，整個工程項目被劃分給若干個分項目組承擔(dān)，開發(fā)進(jìn)度月報將以分項目組為單位按月編寫。

對于一項軟件而言，有些文件的編寫工作可能要在若干個階段中延續(xù)進(jìn)行。

鑒于軟件開發(fā)是具有創(chuàng)造性的腦力勞動，也鑒于不同軟件在規(guī)模上和復(fù)雜程度上差別極大，本指南認(rèn)為在文件編制工作中應(yīng)允許一定的靈活性，并不是14種文件每種都必須編寫。文件編制的衡量因素

◆在因素總和較低的情況下,項目開發(fā)總結(jié)報告的內(nèi)容應(yīng)包括：程序的主要功能、基本流程、測試結(jié)果和使用說明。

◆測試分析報告應(yīng)該寫，但不必很正規(guī)。

◆數(shù)據(jù)要求說明和數(shù)據(jù)庫設(shè)計說明是否需要編寫應(yīng)根據(jù)所開發(fā)軟件的實際需要來決定。

例2：為了避免在軟件開發(fā)中文件編制的不足或過分，一個簡便的辦法是把對軟件文件的編制要求同軟件的規(guī)模大小聯(lián)系起來，這就是本例的出發(fā)點。軟件的規(guī)模不妨分為四級：

1．小規(guī)模軟件源程序行數(shù)小于5 000的軟件；

2．中規(guī)模軟件源程序行數(shù)為 10 000～ 50 000的軟件；

3．大規(guī)模軟件源程序行數(shù)為 100 000?500 000的軟件；

4．特大規(guī)模軟件源程序行數(shù)大于500 000的軟件。

對上述的四級軟件的文件編制要求分別列于表O3。

至于源程序行數(shù)為 5 000～ 10 000，50 000～ 100 000的軟件，其文件編制要求介于兩級之間，可根據(jù)一個軟件產(chǎn)品的具體情況，由項目負(fù)責(zé)人參照表O3的規(guī)定，確定需要編制的文件種類。

對于源程序行數(shù)大于500 000的特大規(guī)模軟件，可進(jìn)一步把本指南規(guī)定的十四種文件按實際需要擴(kuò)展成更多種類。

第五篇：JAVA學(xué)習(xí)書籍- 軟件開發(fā)過程

了解軟件開發(fā)過程不單純是提高程序員個人的良好編程習(xí)慣，也是增強(qiáng)團(tuán)隊協(xié)作的基礎(chǔ)。

1、《UML 精粹》

UML 其實和軟件開發(fā)過程沒有什么必然聯(lián)系，卻是軟件團(tuán)隊協(xié)作溝通，撰寫軟件文檔需要的工具。但是UML 真正實用的圖不多，看看這本書已經(jīng)足夠了，完全沒有必要去啃《UML 用戶指南》之類的東西。要提醒大家的是，這本書的中譯本翻譯的非常之爛，建議有條件的看英文原版。

2、《解析極限編程擁抱變化》XP

這是Kent Beck 名著的第二版，中英文對照。沒什么好說的，必讀書籍。

3、《統(tǒng)一軟件開發(fā)過程》UP

其實UP 和敏捷并不一定沖突，UP 也非常強(qiáng)調(diào)迭代，測試，但是UP 強(qiáng)調(diào)的文檔和過程驅(qū)動卻是敏捷所不取的。不管怎么說，UP

值得你去讀，畢竟在中國真正接受敏捷的企業(yè)很少，你還是需要用UP 來武裝一下自己的，哪怕是披著UP 的XP。

4、《敏捷建?！稟M

Scott Ambler 的名著，這本書非常的progmatic，告訴你怎么既敏捷又UP，把敏捷和UP 統(tǒng)一起來了，又提出了很多progmatic的建議和做法。你可以把《解析極限編程擁抱變化》、《統(tǒng)一軟件開發(fā)過程》和《敏捷建?！愤@三本書放在一起讀，看XP 和UP的不同點，再看AM 是怎么統(tǒng)一XP 和UP 的，把這三種理論融為一爐，形成自己的理論體系，那么你也可以去寫書了。

軟件項目管理

如果你突然被領(lǐng)導(dǎo)提拔為項目經(jīng)理，而你完全沒有項目管理經(jīng)驗，你肯定會心里沒底；如果你覺得自己管理項目不善，很想改

善你的項目管理能力，那么去考PMP 肯定是遠(yuǎn)水不解近渴的。

1、《快速軟件開發(fā)》

這也是一本名著。可以這樣說，有本書在手，你就有了一個項目管理的高級參謀給你出謀劃策，再也不必?fù)?dān)心自己不能勝任的問題了。這本書不是講管理的理論的，在實際的項目管理中，講這些理論是不解決問題的，這本書有點類似于“軟件項目點子

大全”之類的東西，列舉了種種軟件項目當(dāng)中面臨的各種問題，以及應(yīng)該如何解決問題的點子，你只需要稍加變通，找方抓藥

就行了。__