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

1、項目組軟件開發(fā)行為規(guī)范僅供信息化部使川1概述1.1 編寫目的為了把公司已經(jīng)發(fā)布的軟件開發(fā)過程規(guī)范有效地運作于產(chǎn)品開發(fā)活動中，把各種規(guī)范“逐步形成工程師的作業(yè)規(guī)范”，特制定本軟件開發(fā)行為規(guī)范，以到達提高系統(tǒng)質(zhì)量的目的。在本規(guī)范中，闡述了基本的開發(fā)模式，包括需求驗證、設(shè)計、編碼規(guī)范、代碼審查、單元測試、配置管理等，并明確開發(fā)過程中的方法、策略、工具以及環(huán)境要求，開發(fā)人員都必須遵守本軟件開發(fā)規(guī)范。1.2 讀者對象本規(guī)范讀者對象為軟件開發(fā)項目管理者、項目經(jīng)理、開發(fā)組2需求評審2.1 過程要求按軟件開發(fā)過程經(jīng)驗，問題暴露越早越好。因此，在實施設(shè)計和編碼前，需對項目經(jīng)理提供的需求說明文檔進行充分的驗證，在

2、不明確的需求點上，需要和項目經(jīng)理進一步核實，確保對每個需求點有清晰、一致的認識和理解。在需求驗證的過程中，需按以下檢查點進行逐項檢查（包括不限于）：1 .所有定義、實現(xiàn)方法是否清楚地表達了用戶的原始要求？2 .是否清楚、明確地描述了所有的功能？是否沒有不能理解或造成誤解的描述？3 .需求定義是否包含了有關(guān)功能、性能、限制、目標、質(zhì)量等方面的所有需求？4 .需求是否可以驗證（即是否可以檢驗軟件是否滿足了需求）？5 .是否有術(shù)語定義一覽表？6 .是否標識并定義了在將來可能會變化的需求？7 .各個需求之間是否一致？是否有沖突和矛盾？8 .是否定義了系統(tǒng)所有的輸入、輸出及其來源？主要為客戶或者其他外部

3、接口，是否明確定義了輸入?yún)?shù)和輸出參數(shù)？9 .是否說明了如何進行系統(tǒng)輸入的合法性檢查？10 .功能性需求是否覆蓋了所有非正常情況的處理？11 .對異常數(shù)據(jù)產(chǎn)生的結(jié)果是否作了精確的描述？12 .是否充分定義了關(guān)于人機界面的需求？13 .在不同情況下，是否規(guī)定了系統(tǒng)的響應(yīng)時間？14 .界面需求是否使軟硬件系統(tǒng)具有兼容性？15 .是否有對相關(guān)日志做明確要求？以滿足稽核相關(guān)的需要。針對開發(fā)過程中的需求變更，以上需求驗證點同樣適用，并同時評估需求變更給當前項目的設(shè)計和開發(fā)帶來的風險，包括架構(gòu)、安全、進度等方面，以便項目經(jīng)理進行計劃調(diào)整和安排。2.2 工具及環(huán)境1 .在此過程中，使用Excel對以上檢查點

4、進行跟蹤和標記。記錄文檔需check-in至Usvn.2 .評審?fù)瓿傻男枨笪臋n需check-in到svn。3 .任何需求變更文檔需check-in到svn。4 .登記相關(guān)問題，并跟蹤其狀態(tài)。3系統(tǒng)設(shè)計及評審3.1 過程要求概要設(shè)計要以軟件需求規(guī)格為基礎(chǔ)，必須保證需要實現(xiàn)的需求規(guī)格已經(jīng)被設(shè)計。概要設(shè)計文檔的需涵蓋以下幾方面：1 .涵蓋系統(tǒng)的總體結(jié)構(gòu)、功能。系統(tǒng)共包含哪些模塊，以及模塊之間的關(guān)系。使閱讀者對系統(tǒng)有了全局觀。2 .明確系統(tǒng)使用的外部接口和資源。包括外部環(huán)境、第三方接口、第三方技術(shù)架構(gòu)等。3 .模塊設(shè)計的進一步細化，包括具體的輸入、輸出、處理邏輯、與其他模塊之間的接口等。4 .數(shù)據(jù)結(jié)構(gòu)

5、設(shè)計，文檔中明確數(shù)據(jù)的物理結(jié)構(gòu)和邏輯結(jié)構(gòu)，包括數(shù)據(jù)的存儲方式、緩存策略、備份策略、清理策略等。5 .容災(zāi)設(shè)計，主要指外部資源或接口不可用時，系統(tǒng)如何處理，包括客戶提示信息、錯誤現(xiàn)場記錄等。6 .監(jiān)控設(shè)計，針對系統(tǒng)中的關(guān)鍵業(yè)務(wù)，特別是對實時性、準確性要求較高的功能，需考慮其監(jiān)控指標、監(jiān)控方法、業(yè)務(wù)閥值、告警通知的設(shè)計。7 .安全設(shè)計，在系統(tǒng)概要設(shè)計中，要充分考慮系統(tǒng)安全方面的設(shè)計，包括數(shù)據(jù)傳輸、數(shù)據(jù)存儲、網(wǎng)絡(luò)攻擊等方面的情況。8 .其他情況，未在以上提及的項目其他情況，可進行特別說明。同時，在概要設(shè)計過程中，需遵循以下原則：1、 當需求規(guī)格發(fā)生變更時，必須修訂相關(guān)概要設(shè)計文檔。2、 在概要設(shè)計文

6、檔，必須記錄、驗證需求和概要設(shè)計的跟蹤關(guān)系。3、 必須保證概要設(shè)計文檔和代碼的一致性。當發(fā)生設(shè)計更改時，必須修訂相應(yīng)設(shè)計文檔。4、 概要設(shè)計過程結(jié)束前，必須通過評審，并保存評審記錄。5、 設(shè)計更改必須經(jīng)過相關(guān)評審，并保存評審記錄。在概要設(shè)計評審階段，可按以下檢查點進行逐項驗證（包括但不限于）6、 是否描述了接口的功能特征？7、 接口是否便于查錯？8、 接口相互之間、和其他模塊、和需求說明書及接口規(guī)格書保持一致？9、 對接口的數(shù)量和復(fù)雜度進行了有效的平衡，使接口數(shù)量控制在一個較小數(shù)量，每個接口具有可接受的復(fù)雜度？10、 否所有的接口都能描述了必要的類型、數(shù)量、質(zhì)量等信息？11、 作界面是否考慮了

7、用戶（例如：提供準確、清晰、有用的提示信息）12、 否模塊化設(shè)計？13、 塊遵循高內(nèi)聚、低耦合的原則？14、 否每一部分的設(shè)計都可以追溯到需求說明書，接口規(guī)格說明書、或其他產(chǎn)品文檔？15、 對所繼承下來的那些特別和不常用的特性對目前設(shè)計的影響是否進行了分析？16、 需求規(guī)格評審中不完整的需求是否都已經(jīng)解決？17、 設(shè)計是否考慮了檢錯和恢復(fù)措施？（例如：輸入檢查，數(shù)據(jù)錯誤后如何恢復(fù)）18、 是否考慮了異常情況？19、 是否完全準確描述了所有的出錯情況？20、 設(shè)計是否能夠滿足所有系統(tǒng)集成方面的要求？3.3工具及環(huán)境1 .概要設(shè)計文檔及其評審文檔需check-in到svn中。2 .概要設(shè)計過程中的

8、問題跟蹤需記錄。4系統(tǒng)實現(xiàn)4.1 過程要求編碼必須以設(shè)計文檔為基礎(chǔ)，必須保證所有的設(shè)計都被編碼實現(xiàn)。當設(shè)計發(fā)生變更時，必須修改相關(guān)代碼。同時必須保證設(shè)計文檔和代碼的一致性。當代碼的修改已經(jīng)造成設(shè)計更改時，必須修訂相應(yīng)設(shè)計文檔。在系統(tǒng)實現(xiàn)過程中，需遵循以下規(guī)范：1 .遵照各項編碼規(guī)范。2 .所有代碼使用svn進行統(tǒng)一管理，并至少提供開發(fā)、測試、生產(chǎn)三種構(gòu)建腳本。3 .在系統(tǒng)開始之前，需在svn上創(chuàng)建對應(yīng)的分支，開發(fā)工作統(tǒng)一在分支上進行。4 .針對開發(fā)任務(wù)的分解，需要參照單人單任務(wù)在兩天以內(nèi)完成的標準。5 .開發(fā)過程中，單元測試通過的代碼需要及時check-in到svn。6 .代碼進入系統(tǒng)測試前需

9、進行評審，可以是集中評審或者交叉評審的方式評審內(nèi)容包括基本編碼規(guī)范、基本邏輯、日志規(guī)范、出錯處理等。7 .單元測試的覆蓋率需在80犯上。具體的單元測試要點如下：對所測模塊的數(shù)據(jù)進行測試。檢查不正確或不一致的數(shù)據(jù)類型說明、使用尚未附值或尚未初始化的變量、錯誤的初始值或缺省值。設(shè)計測試用例查找由于不正確的計算（包括算法錯、表達式符號表示不正確、運算精度不夠等）、不正確的比較或不正常的控制流（包括不同數(shù)據(jù)類型量的相互比較、不適當?shù)匦薷牧搜h(huán)變量、錯誤的或不可能的循環(huán)終止條件等）而導(dǎo)致的錯誤。檢查模塊有沒有對預(yù)見錯誤的條件設(shè)計比較完善的錯誤處理功能，保證其邏輯上的正確性。邊界檢查，注意設(shè)計數(shù)據(jù)、控制中

10、剛好等于、大于或小于確定的比較值的用例。8 .開發(fā)過程中，需進行持續(xù)化構(gòu)建，保證check-in的代碼質(zhì)量。9 .項目中引進的新技術(shù)需經(jīng)過統(tǒng)一評審。5測試5.1 過程要求在系統(tǒng)交付給測試組進行測試前，開發(fā)人員需在內(nèi)部進行第一輪功能測試。測試過程中需保持測試代碼的準確性和測試環(huán)境的獨立性。具體測試內(nèi)容包含但不限于以下幾方面：1 .功能測試。對照需求文檔中的功能點，對系統(tǒng)的功能進行測試驗證，確保系統(tǒng)完全滿足需求文檔中的要求。2 .平臺兼容性測試。在不同的瀏覽器、硬件配置環(huán)境下進行測試，主要瀏覽器包括Firefox,safari,IE,chrome。針對移動端，需涵蓋三個主流操作系統(tǒng)，iOS,And

11、roid和WindowsMobile。硬件兼容性則包括不同的智能終端，PC,MAC,IPAD?其他機型的不同分辨率下的兼容性測試。3 .不同網(wǎng)絡(luò)環(huán)境下測試。針對移動端的應(yīng)用，驗證不同網(wǎng)絡(luò)環(huán)境下，終端應(yīng)用功能與性能方面是否正常（數(shù)據(jù)業(yè)務(wù)是否會中斷，業(yè)務(wù)模塊是否出現(xiàn)異常）網(wǎng)絡(luò)環(huán)境包含：4G信號，3G信號，2G強信號。6開發(fā)計劃6.1過程要求軟件開發(fā)是一項復(fù)雜、長期的系統(tǒng)工程，為保證開發(fā)能夠順利地進行實施，必須要制定科學、合理、切實可行的實施計劃，制定嚴格的時間進度表，明確各個環(huán)節(jié)實施的時間，以指導(dǎo)和控制項目的全面實施。在系統(tǒng)實現(xiàn)過程中，需遵循以下規(guī)范：1 .軟件項目計劃必須以產(chǎn)品/軟件的需求規(guī)格為

12、基礎(chǔ)。當發(fā)生需求更改時，必須修訂軟件開發(fā)計劃。2 .對于軟件項目計劃中各項工作產(chǎn)品和工作任務(wù)，必須進行規(guī)模和工作量的軟件估計，并在軟件項目計劃文檔中記錄估計的方法和估計數(shù)據(jù)3 .對某項工作產(chǎn)品和任務(wù)的軟件，同時采用兩種或以上的方法進行估計，以避免一種方法的偏差4 .盡量采用歷史經(jīng)驗數(shù)據(jù)進行軟件估計5 .在“軟件開發(fā)計劃”中須包括項目管理活動的計劃6 .在“軟件開發(fā)計劃”包括人員的培訓(xùn)計劃7 .在“軟件開發(fā)計劃”中應(yīng)考慮軟件項目進行風險分析與評估，可能存在的風險領(lǐng)域含：需求的不明確和變更、外部的限制與對外的依賴、人力資源的到位情況、人力資源的技術(shù)等級滿足要求狀況、技術(shù)問題等，造成的計劃變更。8

13、.在開發(fā)活動中，必須按照項目跟蹤與監(jiān)控計劃和體制，對照“軟件開發(fā)計劃”，跟蹤項目開發(fā)的實際結(jié)果和性能。當實際結(jié)果和“軟件項目計劃”發(fā)生偏離時，必須進行分析，根據(jù)分析結(jié)果標明糾正措施。必要的情況下，要及時修訂“軟件項目計劃”9 .在軟件項目跟蹤監(jiān)控活動中，必須定期進行總結(jié)和評審，撰寫開發(fā)狀態(tài)報告。根據(jù)項目的特點，報告的周期可以為周、雙周、月。7數(shù)據(jù)安全7.1過程要求21世紀是一個信息爆炸的時代，數(shù)據(jù)是信息的主要載體，數(shù)據(jù)安全保證了信息的可用性。而數(shù)據(jù)備份作為保證數(shù)據(jù)安全的方法之一，則顯得尤為重要。數(shù)據(jù)安全不僅在防范計算機病毒、系統(tǒng)漏洞中有體現(xiàn)，更多的還有代碼安全，數(shù)據(jù)庫防脫庫及數(shù)據(jù)庫備份安全。在系統(tǒng)實現(xiàn)過程中，需遵循以下規(guī)范：1 .加強開發(fā)人員安全意識培訓(xùn)，近年來的一系列企業(yè)泄密事件的發(fā)生，根本原因還在于安