【導讀】軟件研發(fā)管理制度。版本/狀態(tài)作者參與者修改日期備注。宋孝光2020/3/27整理目錄

　　

【正文】 25 模塊等，從而在需求與代碼之間建立橋梁，指導開發(fā)人員去實現能滿足用戶需求的軟件產品。 本規(guī)范闡述了系統(tǒng)設計過程域的四個主要規(guī)程： ? 體系結構設計 ? 用戶界面設計 ? 數據庫設計 ? 模塊設計 系統(tǒng)設計過程域分為兩個階段：高層設計階段 和詳細設計階段。 高層設計階段的重點是軟件系統(tǒng)的體系結構設計。詳細設計階段的重點是用戶界面設計、數據庫設計和模塊設計，如圖 101 所示。 圖 101 系統(tǒng)設計過程域示意圖 系統(tǒng)設計過程域產生的主要文檔有： ? 《體系結構設計報告》 ? 《用戶界面設計報告》 ? 《數據庫設計報告》 ? 《模塊設計報告》 體系結構設計 分析與設計軟件的體系結構。通過系統(tǒng)分解，確定子系統(tǒng)的功能和子系統(tǒng)之間的關系，以及模塊的功能和模塊之間的關系，產生《體系結構設計報告》。 項目經理指定若干名開發(fā)人員從事體 系結構設計（以下稱為體系結構設計人員）。 體系結構設計流程如圖 102 所示。 詳細設計階段 高層設計階段 體系結構設計 模塊設計 數據 庫設計 用戶界面設計 需求開發(fā) 實現與測試 26 圖 102 體系結構設計流程 《體系結構設計報 告》 用戶界面設計 設計軟件的用戶界面，產生《用戶界面設計報告》。 制作用戶界面的資源如圖像、圖標或者界面專用組件等 項目經理指定若干名開發(fā)人員從事用戶界面設計（以下稱為界面設計人員）。 如果可能的話，邀請用戶或美工人員協助設計用戶界面。 用戶界面設計流程如圖 103 所示。 圖 103 體系結構設計流程 《用戶界面設計》 Step1. 設計 準備 Step5. 撰寫 文檔 Step6. 設計 評審 Step2. 確定 約束 因素 Step3. 確定 設計 策略 Step4. 系統(tǒng) 分解 設計 Step2. 界面設計 Step1. 設計 準備 原型創(chuàng)作 原型評估 細化 Step3. 撰寫 文檔 Step4. 設計 評審 迭代 27 數據庫設計 設計軟件的數據庫，產生《數據庫設計報告》。 項目經理指定若干名開發(fā)人員從事數據庫設計（以下稱為數據庫設計人員）。 數據庫設計流程如圖 104 所示。 圖 104 數據庫設計流程 《數據庫設計報告 》 模塊設計 設計軟件所有模塊的主要接口與屬性、數據結構和算法，產生《模塊設計報告》。 項 目經理指定若干名開發(fā)人員從事模塊的設計（以下稱為模塊設計人員），模塊設計人員將在實現階段編寫這些模塊的代碼。 模塊設計流程如圖 105 所示。 Step2. 數據庫設計 Step1. 設計 準備 邏輯設計 物理設計 安全性設計 優(yōu)化 Step3. 撰寫 文檔 Step4. 設計 評審 迭代 28 圖 105 模塊設計流程 《模塊設計報告》 11 實現與測試 實現與測試（ Implementation and Test, IT）的目的是依據系統(tǒng)設計文檔，編寫并測試整個系統(tǒng)的代碼。在本規(guī)范中，實現與測試是“編程、代碼審查、單元測試、集成測試、缺陷管理與改錯”的綜合表述。 實現與測試的 流程如圖 111 所示。一般地，編程、代碼審查、單元測試、集成測試大致存在先后順序關系，也可以并行、迭代地開展。上述任何活動中發(fā)現的缺陷必須用統(tǒng)一的缺陷管理工具來管理，開發(fā)人員應當及時消除缺陷（改錯）。 圖 111 實現與測試流程圖 由于實現與測試是工作量最大、時間最長、產生 工 作成果（代碼與文檔）最多的一個項目研發(fā)過程域，所以需要作充分的準備工作。 實現與測試工作基本上在開發(fā)小組內部開展。一個項目可能有一個或者多個開發(fā)小 Step2. 模塊設計 Step1. 設計 準備 接口與屬性設計 數據結構 與算法設計 Step3. 撰寫 文檔 Step4. 設計 評審 迭代 編程 代碼審查 單元測試 集成測試 模塊 軟件系統(tǒng) 準備 缺陷管理與改錯 29 組。對于小型項目，項目經理可以兼任開發(fā)組長 。 特別要注意的是，開發(fā)人員應當對自己的代碼進行審查和測試（這是 份內 的工作），但是不能作為該代碼已經通過審查和測試的依據。所以開發(fā)人員還要互相審查和測試同伴的代碼。 實現與測試過程域產生的主要文檔有： ? 《實現與測試計劃》 ? 《編程文檔》 ? 《代碼審查報告》 ? 《測試用例》 ? 《測試報告》 ? 《缺陷管理報告》（由缺陷管理工具自動生成） 一個項目可能有多個開發(fā)小組，視項目規(guī)模而定。開發(fā)組長由項目經理指定。 開發(fā)組長管理編程、代碼審查、單元測試、集成測試、缺陷管理與改錯等活動。 《編程文檔》 《實現與測試計劃 》 12 系統(tǒng)測試 系統(tǒng)測試（ System Test, ST）的目的是對最終軟件系統(tǒng)進行全面的測試，確保最終軟件系統(tǒng)滿足產品需求并且遵循系統(tǒng)設計。 系統(tǒng)測試流程如圖 121 所示。由于系統(tǒng)測試的目的是驗證最終軟件系統(tǒng)滿足產品需求并且遵循系統(tǒng)設計，所以當產品需求和系統(tǒng)設計文檔完成之后，系統(tǒng)測試小組就可以提前開始制定測試計劃和設計測試用例，而不必等到“實現與測試”階段結束。這樣可以提高系統(tǒng)測試的效率。 系統(tǒng)測試過程中發(fā)現的 所有缺陷必須用統(tǒng)一的缺陷管理工具來管理，開發(fā)人員應當及時消除缺陷（改錯）。 30 圖 121 系統(tǒng)測試流程圖 項目經理設法組建富有成效的系統(tǒng)測試小組。系統(tǒng)測試小組的成員主要來源于： ? 機構獨立的測試小組（如果存在的話）。 ? 邀請 其它 項目的開發(fā)人員參與系統(tǒng)測試。 ? 本項目的部分開發(fā)人員。 ? 機構的質量保證人員。 系統(tǒng)測試小組應當根據項目的特征確定測試內容。一般地，系統(tǒng)測試的主要內容包括： ? 功能測試。即測試軟件系統(tǒng)的功能是否正確，其依據是需求文檔，如《產品需求規(guī)格說明書》。由于正確性是軟件最重 要的質量因素，所以功能測試必不可少。 ? 健壯性測試。即測試軟件系統(tǒng)在異常情況下能否正常運行的能力。健壯性有兩層含義：一是容錯能力，二是恢復能力。 ? 性能測試。即測試軟件系統(tǒng)處理事務的速度，一是為了檢驗性能是否符合需求，二是為了得到某些性能數據供人們參考（例如用于宣傳）。 ? 用戶界面測試。重點是測試軟件系統(tǒng)的易用性和視覺效果等。 ? 安全性（ security）測試。是指測試軟件系統(tǒng)防止非法入侵的能力。“安全”是相對而言的，一般地，如果黑客為非法入侵花費的代價（考慮時間、費用、危險等因素）高于得到的好處，那么這樣的系統(tǒng)可 以認為是安全的。 ? 安裝與反安裝測試。 系統(tǒng)測試過程域產生的主要文檔有： ? 《系統(tǒng)測試計劃》 ? 《系統(tǒng)測試用例》 ? 《系統(tǒng)測試報告》 ? 《缺陷管理報告》 對最終軟件系統(tǒng)進行全面的測試，確保最終軟件系統(tǒng)滿足產品需求并且遵循系統(tǒng)設計。 項目經理組建系統(tǒng)測試小組，并指定一名成員任測試組長。 系統(tǒng)測試小組各成員共同制定測試計劃、設計測試用例、執(zhí)行測試，并撰寫相應的文檔。測試組長管理上述事務。 開發(fā)人員及時消除測試人員發(fā)現的缺陷。 制定測試計劃 設計測試用例 執(zhí)行系統(tǒng)測試 缺陷管理與改錯 審批 審批 迭代 31 《系統(tǒng)測試計劃》 《測試用例》 《測試報告》 13 客戶驗收 客戶驗收（ Customer Acceptance, CA）是指客戶依據合同對產品進行審查和測試，確保產品滿足客戶需求。 客戶對產品的驗收主要有兩種方式： ? 成果審查。驗收人員審查開發(fā)方應當交付的成果，如代碼、文檔等等。確保這些成果是完整的并且是正確的。 ? 驗收測試。驗收人員對待交付的產品進行全面的測試，確保產品功能、質量符合需求。 驗收測試的內容、方法與系統(tǒng)測試幾乎是相同的。兩者主要區(qū)別在于執(zhí)行 人員不同。驗收測試人員來自于客戶方，而系統(tǒng)測試人員則來自于開發(fā)方。客戶驗收流程如圖 131所示。 圖 131 客戶驗收流程 客戶驗收過程域產生的主要文檔有： ? 《客戶驗收計劃》 ? 《驗收測試用例》 ? 《客戶驗收報告》 補充說明： “客戶驗收”是針對合同項目而言的。 《客戶驗收計劃》 《客戶驗收報告》 驗收準備 問題處理 成果審查與驗收測試 交付與簽字 32 14 技術評審 技術評審（ Technical Review, TR）的目的是盡早地發(fā)現工作成果中的缺陷， 并幫助開發(fā)人員及時消除缺陷，從而有效地提高產品的質量。 本規(guī)范闡述了技術評審過程域的三個主要規(guī)程： ? 制定技術評審計劃 ? 正式技術評審 ? 非正式技術評審 技術評審能夠在任何開發(fā)階段執(zhí)行，它可以比測試更早地發(fā)現并消除工作成果中的缺陷。技術評審的主要好處有： ? 通過消除工作成果的缺陷而提高產品的質量。 ? 越早消除缺陷就越能降低開發(fā)成本。 ? 開發(fā)人員能夠及時地得到同行專家的幫助和指導，無疑會加深對工作成果的理解，更好地預防缺陷，一定程度上提高了開發(fā)生產率。 可見技術評審有助于“提高質量、提高生產率、降低成本”，符合軟 件過程改進的根本目的。 技術評審有兩種基本類型： ? 正規(guī)技術評審（ FTR）。 FTR 比較嚴格，需要舉行評審會議，參加評審會議的人員比較多。 ? 非正規(guī)技術評審（ ITR）。 ITR 的形式比較靈活，通常在同伴之間開展，不必舉行評審會議，評審人員比較少。 理論上講，為了確保產品的質量，產品的所有工作成果都應當接受技術評審?，F實中，為了節(jié)約時間，允許人們有選擇地對工作成果進行技術評審。技術評審方式也視工作成果的重要性和復雜性而定。 技術評審過程域有三個主要規(guī)程：“制定技術評審計劃”、“正規(guī)技術評審”和“非正規(guī)技術評審”，如圖 141 所示。 圖 141 技術評審過程域示意圖 技術評審的注意事項： ? 評審人員的職責是發(fā)現工作成果中的缺陷，并幫助開發(fā)人員給出消除缺陷的辦法，而不是替開發(fā)人員消除缺陷。 制定技術評審計劃 正規(guī)技術評審 非正規(guī)技術評審 33 ? 技術評審應當“ 就是論事 ”，不要打擊有失誤的開發(fā)人員的工作積極性，更不準搞人身攻擊（如挖苦、諷刺等）。 ? 在會議評審期間要限制過多的爭論，以免浪費他人的時間。 技術評審過程域產生的主要文檔有： ? 《技術評審計劃》 ? 《技術評審通知》 ? 《技術評審報告》 ? 《技術評審檢查表》 《技術評審計劃》 《技術評審通知》 《技術評審報告》 《技術評審檢查表 》 15 配置管理 配置管理（ Configuration Management, CM）的目的是通過執(zhí)行版本控制、變更控制等規(guī)程，以及使用配置管理軟件，來保證所有配置項的完整性和可跟蹤性。 配置管理是對工作成果的一種有效保護。 本規(guī)范闡述了配置管理過程域的四個主要規(guī)程： ? 制定配置管理計劃 ? 配置庫管理 ? 配置項版本控制 ? 配置項變更控制 項目研發(fā)和管理過程中會產生許許多多的工作成果，例如文檔、程序和數據等，它們都應當被保存起來，以便查閱和修改。如果把所有文件一股腦地塞進計算機里，那么使用起來肯定很麻煩。毫無疑問，人們應當將文件分門別類、有條理地保存起來。 凡是納入配置管理范疇的工作成果統(tǒng)稱為配置項（ Configuration Item, CI），配置項主要有兩大類： （ 1）屬于產品組成部分的工作成果，例如需求文檔、設計文檔、源代碼、測試用例 等 。 （ 2）項目管理和機構支撐過程域產生的文檔。這些文檔雖然不是產品的組成部分，但 是值得保存。 每個配置項的主要屬性有 ：名稱、標識符、文件狀態(tài)、版本、作者、日期等。所有配置項都 被保存在配置庫里，確保不會混淆、丟失。配置項及其歷史記錄反映了軟件的演化過程。 34 基線（ Baseline）由一組配置項組成，這些配置項構成了一個相對穩(wěn)定的邏輯實體?；€中的配置項被“凍結”了，不能再被任何人隨意修改（見變更控制規(guī)程）?；€通常對應于開發(fā)過程中的里程碑（ Milestone），一個產品可以有多個基線，也可以只有一個基線?；€的主要屬性有：名稱、標識符、版本、日期等。通常將交付給客戶的基線稱為一個“ Release”，為內部開發(fā)用的基線則稱為一個“ Build”。 所有的項目成員都要使用