公司如何制定軟件開發規程？

公司如何制定軟件開發規程？

《軟件開發設計規程》參考

1 簡介1.1 目的

本過程目的在于為需求設計、開發、實現解決方案。根據適當情況，解決方案、設計和實現包括單獨的產品、產品組件以及產品相關的生命周期的過程，或者它們的組合，以及包括如何利用準則進行接口設計。

1.2 適用范圍與預期讀者

適用于本公司的所有軟件項目。

預期讀者：

1、項目經理；

2、項目組；

2 過程總體描述2.1 過程概述

技術解決方案過程包括：

1、選擇最佳解決方案；

2、制定架構設計；

3、制定概要設計；

4、制定詳細設計和數據庫設計；

5、利用準則進行接口設計；

6、實現設計；

7、進行單元測試；

8、進行代碼審查；

9、建立和維護用戶文檔。

2.2 過程流程圖

3 過程元素描述3.1 產品方案3.1.1. 目的

針對需求選擇出最佳解決方案。

3.1.2. 角色和職責

項目經理：選擇產品的解決方案。

項目組：選擇產品的解決方案。

3.1.3. 進入準則

《軟件需求規格說明書》已完成，根據實際問題，已有備選解決方案。

3.1.4. 輸入

《軟件需求規格說明書》

備選解決方案

3.1.5. 工作任務

在《軟件需求規格說明書》完成后，項目選擇最佳技術解決方案時，依據《決策分析指南》啟用《決策分析規程》，選擇最佳解決方案。

3.1.6. 退出準則

選擇出最佳解決方案

3.1.7. 輸出

《決策分析報告》

3.2 產品設計3.2.1. 目的

進行架構設計、概要設計、詳細設計、接口設計和數據庫設計，完成產品或產品模塊的設計。

3.2.2. 角色和職責

項目經理：組織進行架構設計、概要設計、詳細設計、接口設計和數據庫設計，組織相關人員進行設計文檔評審。

項目組：進行架構設計、概要設計、詳細設計、接口設計和數據庫設計，評審相關文檔。

3.2.3. 進入準則

已選擇出最佳解決方案。

3.2.4. 輸入

《決策分析報告》

3.2.5. 工作任務

1.概要設計

（1） 面向結構（數據流）設計方法

結合《軟件需求規格說明書》及系統不同層次的數據流圖，把整個系統分解為模塊并確定各模塊功能，確定每個功能模塊的輸入、輸出數據流，并考慮各方面數據接口、存儲方式等。迭代逐步分解各系統模塊，直到確定每個功能模塊只執行一個行為為止，同時細化數據結構設計，完善數據字典以確保系統能獲得所需的輸出結果，從而完成系統構架設計。

（2） 面向對象設計方法

結合《軟件需求規格說明書》（包括原型圖、類模型）和系統選用的編程語言，確定客戶類（包括子類）及類的各種行為，并使用設計模型及相應的列表，確定每個對象的客戶（模塊）關聯，并給予必要的方法設計。迭代逐步檢查對象及其方法，直到系統中每個對象擁有所有必需的方法，從而完成系統構架設計。

2.工作步驟

項目經理確定系統設計人員，并討論確定階段出口準則，通盤考慮并跟蹤上游順延下來的進度、技術難度等風險、問題，與相關人員溝通，制定階段計劃。必要時，請高層參與問題解決。

評估、確認需求分析結果，并對可重用的軟件或功能模塊進行性能測試，通盤考慮整個系統結構、功能擴展性。

（1） 系統結構設計可選（系統框架設計）

a）傳統架構

用傳統的架構，1000并發量需要2臺服務器做tomcat集群。但是由于系統用的人越來越多，并發量越來越大待到并發量為10000時，需要20臺服務器做tomcat集群。當tomcat集群中節點數量增加，服務器能量先增加后下降。所以集群中節點的數量不能太多，一般也就5個左右。難以實現高數據量的并發，5臺服務器難以正常工作。

b）分布式架構

能用硬件解決的問題就不用軟件解決、硬件解決不了就用軟件解決。

當并發數高時，需要按照功能吧系統拆分，拆分成獨立的功能。單獨為某一個節點添加服務器。需要系統之間配合才能完成整個業務邏輯，叫做分布式。

分布式架構：把系統安裝模塊拆分成多個子系統，多個子系統相互協作才能完成業務流程，系統之間需要進行通信。

c）基于SOA的架構

為了解決分布式的架構的缺點，我們可以使用基于SOA的架構。SOA：Service Oriented Architecture 面向服務架構。也就是把工程拆分成服務層、表現層兩個工程。服務層中包含業務邏輯，只需要對外提供服務即可。表現層只需要處理和頁面的交互，業務邏輯都是調用服務層的服務來實現。

（2） 接口（包括用戶界面）設計

a) 與客戶、測試人員交流界面設計需求，明確用戶界面、接口設計規則，包括：標準控件的使用規則，通用界面（包括主界面和子界面等）、接口設計原則等；

b) 界面設計

分析需求說明中對用戶界面的需求，實施用戶界面設計，包括界面及其關系、工作流程等，必要時采取原型設計，并請客戶或同行評估后細化改進；

c) 接口設計

擴展子系統或功能模塊及其之間的關系和限制條件，實施系統所需的接口設計，并消除冗余后，完善系統的數據流圖，必要時形成功能說明和操作方式。若面向對象方法，則為子系統包、類間的屬性、方法等設計；

由測試人員參與完善測試接口設計；

結合系統錯誤處理和數據驗證方法，驗證接口設計結果，并逆向需求求證；

d) 確定新開發、采購和復用方案

利用決策分析過程確定新開發、采購和復用方案。

（3）購買復用分析：

①確定哪些產品部件應當采購、外包開發或者自主研發，說明理由。

②分析相應的風險。

③列出多個可選方案。（即使沒有可選方案也應有“用”和“不用”兩個方案）

（3）非功能性設計（可選）

a）易用性與可執行

易用性會使產品提高符合用戶習慣的能力以及其對使用的期望。它會對用戶使用產品的生產效率、錯誤率以及用戶對新產品的接收程度產生很大的影響。

可執行需求是指產品可以在給定的時間或者特定的精確度來執行某些任務，或者在一段時間內的極端狀態值。在考慮執行需求時，可以從完成任務的速度、結果的精確度、容量、允許值的范圍、單位時間內完成的任務數、資源的使用效率、兩次故障間的平均無故障時間、連續不停機時間等方面入手。它還應該包括對風險的控制內容。

b)安全性

安全性指產品消除潛在風險的能力和對風險的承受能力。包含、保密性、可靠性和完整性三個子特性。保密性指的是數據不能被授權用戶以外的任何人訪問的能力。可靠性指的是授權用戶可以不受阻止的訪問數據、與其它軟件的兼容的能力和產品的強壯度。完整性指的是安預期目標完成任務的能力。

一般分為程序安全、系統安全、數據安全。程序安全是指開發的程序是否是安全的，程序上有沒有安全的漏洞，例如Web開發中服務器代碼沒有對輸入的參數進行驗證，從而導致客戶端機器人輕易的獲取數據。系統安全指的是系統整體的安全，例如安全的粒度，未經授權的用戶是否可以輕易的訪問非法的數據等。數據的安全是對數據的保護，數據庫中數據有沒有做審核，用戶之間是否會共享數據等。

c)系統的可擴充性與可維護性

這里指的是當系統達到瓶頸的時候怎樣在不修改代碼的情況下提供系統的負載能力，擴展一般分為Scale UP和Scale Out。一般情況下會綜合運用UP和OUT。例如，增加服務器的性能來提高系統的處理能力，但是任何計算機都會有一定的瓶頸，當增加服務器性能不能達到提高系統性能的時候，我們需要考慮橫向的擴展服務器，也即Scale Out。在Scale Out時一般需要我們的系統是狀態無關的，即Stateless。

（4） 整合及評審

項目經理或客戶委派專人負責組織對設計的工作產品執行評審；

指定需求跟蹤人負責跟蹤系統設計結果，完善《需求跟蹤矩陣》。

2.詳細設計

（1） 細化系統設計

項目經理確定詳細設計人員，并通盤考慮上游順延下來的進度、技術難度風險、問題，制定階段工作計劃，確定階段出口準則。必要時，請高層參與解決問題；

項目經理配合詳細設計人員對概要設計方案進行評估，項目組間或組內達成共識；

結合設計方法、工具、需求文檔和軟件系統體系結構設計文檔，逐步細化設計每個功能模塊的主要接口與屬性，必要時還須細化每個用戶界面；若采用面向對象方法，則為設計類的函數和成員變量；

細化設計每個功能模塊的數據結構與算法（若存在的話），并提高其效率，確認并完善重用軟件及模塊單元的算法和處理流程，確保系統一致性；

處理數據流程并充分考慮系統限制，逐步完善系統集成方案；

指定需求跟蹤負責人對需求狀態進行跟蹤，完善《需求跟蹤矩陣》，若發現問題，登記到《問題列表及跟蹤》中；

重復執行以上步驟直到達到出口準則；

（2） 數據庫設計的內容

① 數據庫設計準備：

系統設計人員閱讀《需求規格說明書》、和《概要設計說明書》，明確數據庫設計任務，準備設計工具。

② 邏輯設計：

系統設計人員根據需求文檔，創建與數據庫相關的那部分實體關系圖。明確用戶需求，對于特殊用戶創建特別的用戶組并分配相應權限。

③ 物理設計：

系統設計人員進行表結構設計。一般地，實體對應于表，實體的屬性對應于表的列，實體之間的關系成為表的約束。邏輯設計中的實體大部分可以轉換成物理設計中的表，但是它們并不一定是一一對應的。系統設計人員要對表結構進行規范化處理。

④ 安全性設計：

系統設計人員要提高系統的安全性，應當從“管理”和“設計”兩方面著手。這里僅考慮數據庫的安全性設計。用戶只能用賬號登錄到應用軟件，通過應用軟件訪問數據，而沒有其他途徑可以操作數據庫。對用戶賬號的密碼進行加密處理，確保在任何地方都不會出現密碼的明文。確定每個角色對數據庫表的操作權限，如創建、檢索、更新、刪除等。每個角色擁有剛好能夠完成任務的權限，不多也不少。在應用時再為用戶分配角色，則每個用戶的權限等于他所兼角色的權限之和。

⑤ 設計優化：

分析并優化數據庫的效率，盡可能地“提高處理速度”并且“降低數據庫占用的空間”。分析效率的瓶頸，找出優化對象（目標），并確定優先級。當優化對象（目標）之間存在對抗時，給出折衷方案，給出優化的具體措施，例如優化數據庫環境參數，對表格進行反規范化處理等。

⑥ 撰寫數據庫設計文檔：

系統設計人員利用工具撰寫《詳細設計說明書》。

⑦ 對數據庫設計進行評審：

數據庫設計結束之后，產生《詳細設計說明書》，項目經理需組織同行專家等所有相關人員對設計成果進行評審；評審不通過，系統設計人員要重新修改。

（3） 整合及評審

項目經理負責組織整合設計內容，編寫《詳細設計說明書》并完善用戶文檔；

項目經理負責組織對階段工作產品的驗證和評審，執行評審。

3.2.6退出準則

設計完成。

3.2.7輸出

《概要設計說明書》

《詳細設計說明書》

《概要設計評審》

《詳細設計評審》

3.3 產品實現3.3.1. 目的

依據已經完成的設計，實現各產品模塊。

3.3.2. 角色和職責

項目組：實現設計。

3.3.3. 進入準則

設計完成。

3.3.4. 輸入

《概要設計說明書》

《詳細設計說明書》

3.3.5. 工作任務

1．實現設計

（1） 引用編碼規范

確定適用于項目組的編碼規則，統一定義有意義的變量名、模塊名，注釋規則，提高程序的可靠性和可維護性；

（2） 編碼

開發人員組建開發環境，避免硬件操作系統等的不兼容風險；

開發人員基于架構設計在配置環境下把功能模塊翻譯成代碼，并進行必要的調試；

（3） 代碼評審

項目經理和項目組相互進行代碼評審，形成《代碼檢查表》。

（4） 單元測試

編碼人員根據《單元測試用例》對同伴的代碼進行交叉單元測試工作。項目經理可根據代碼的重要程度選擇需要進行交叉單元測試的模塊。對測試中發現的BUG，由單元測試人員填寫在《單元測試BUG管理表》，并在《單元測試報告》中對缺陷進行分析。

（5）形成用戶文檔

編制用戶相關手冊

3.3.6. 退出準則

完成用戶相關手冊。

3.3.7. 輸出

《單元測試用例》

《代碼檢查表》

《用戶手冊》

源代碼

《單元測試用例》

《單元測試BUG管理表》

《單元測試報告》

【修訂狀況記錄表】

版本號	頁碼	修改條款	審核	批準	批準日期	實施日期