軟件文檔知多少？ （來源于網絡）
如今，軟件開發越來越復雜，軟件功能也越來越豐富。而幾乎所有成熟的商業軟件，都是靠一個開發團隊齊心協力的血汗結晶。“羅馬不是一天建成的！”，當我們震撼于Microsoft Windows的驚世巨著的同時，也道聽途說了微軟公司軟件工程是如何的完善規范。的確，集數百名員工幾年的共同努力之大成，軟件項目管理的成敗是控制開發成本的關鍵環節。這里面，少不了貫穿其中的重要步驟----軟件文檔。
　　軟件文檔可以分為開發文檔和產品文檔兩大類。
　　開發文檔包括：《功能要求》、《投標方案》、《需求分析》、《技術分析》、《系統分析》、《數據庫文檔》、《功能函數文檔》、《界面文檔》、《編譯手冊》、《QA文檔》、《項目總結》等。
　　產品文檔包括：《產品簡介》、《產品演示》、《疑問解答》、《功能介紹》、 《技術白皮書》、《評測報告》、《安裝手冊》、《使用手冊》、《維護手冊》、 《用戶報告》、《銷售培訓》等。
一、開發文檔
　　1. 《功能要求》--來源于客戶要求和市場調查，是軟件開發中最早期的一個環節。客戶提出一個模糊的功能概念，或者要求解決一個實際問題，或者參照同類軟件的一個功能。有軟件經驗的客戶還會提供比較詳細的技術規范書，把他們的要求全部列表書寫在文檔中，必要時加以圖表解說。這份文檔是需求分析的基礎。
　　2. 《投標方案》--根據用戶的功能要求，經過與招標方溝通和確認，技術人員開始書寫《投標方案》，方案書一般包括以下幾個重要的章節：
　　前言--項目背景、公司背景和業務、技術人員結構、公司的成功案例介紹等。
　　需求分析--項目要求、軟件結構、功能列表、功能描述、注意事項等。
　　技術方案--總體要求和指導思想、技術解決方案、軟件開發平臺、網絡結構體系等。
　　項目管理--描述公司的軟件開發流程、工程實施服務、組織和人員分工、開發進度控制、軟件質量保證、項目驗收和人員培訓、軟件資料文檔等。
　　技術支持--公司的技術支持和服務介紹、服務宗旨和目標、服務級別和響應時間、技術服務區域、技術服務期限、授權用戶聯系人等。
　　系統報價--軟、硬件平臺報價列表、軟件開發費用、系統維護費用等。
　　項目進度--整個項目的進度計劃，包括簽署合同、項目啟動、需求分析、系統分析、程序開發、測試維護、系統集成、用戶驗收、用戶培訓等步驟的時間規劃。
　　3. 《需求分析》--包括產品概述、主要概念、操作流程、功能列表和解說、注意事項、系統環境等。以《功能要求》為基礎，進行詳細的功能分析(包括客戶提出的要求和根據開發經驗建議的功能)，列出本產品是什么，有什么特殊的概念，包括那些功能分類，需要具備什么功能，該功能的操作如何，實現的時候該注意什么細節，客戶有什么要求，系統運行環境的要求等。這里的功能描述跟以后的使用手冊是一致的。
　　4. 《技術分析》--包括技術選型、技術比較、開發人員、關鍵技術問題的解決、技術風險、技術升級方向、技術方案評價，競爭對手技術分析等。以《需求分析》為基礎，進行詳細的技術分析(產品的性能和實現方法)，列出本項目需要使用什么技術方案，為什么，有哪些技術問題要解決 ，估計開發期間會碰到什么困難，技術方案以后如何升級，對本項目的技術有什么評價等。
　　5. 《系統分析》--包括功能實現、模塊組成、功能流程圖、函數接口、數據字典、軟件開發需要考慮的各種問題等。以《需求分析》為基礎，進行詳細的系統分析(產品的開發和實現方法)，估計開發期間需要把什么問題說明白，程序員根據《系統分析》，開始在項目主管的帶領下進行編碼。
　　6. 《數據庫文檔》--包括數據庫名稱、表名、字段名、字段類型、字段說明、備注、字段數值計算公式等。以《系統分析》為基礎，進行詳細的數據庫設計。必要時可以用圖表解說，特別是關系數據庫。
　　7. 《功能函數文檔》--包括變量名、變量初植、功能，函數名，參數，如何調用、備注、注意事項等。以《系統分析》為基礎，進行詳細的說明，列出哪個功能涉及多少個函數，以便以后程序員修改、接手和擴展。
　　8. 《界面文檔》--包括軟件外觀、界面素材、編輯工具、文件名、菜單、按鈕和其它界面部件的要求，這里與軟件完成后的運行界面是一致的。
　　9. 《編譯手冊》--包括服務器編譯環境、操作系統、編譯工具、GNU的C++編譯器版本信息、目錄說明、程序生成、源程序文件列表、Makefile配置及其相關程序的對應關系列表。客戶端的編譯過程、編譯結果、編譯示例、編譯環境、操作系統、編譯工具、源文件列表和制作安裝程序的過程。
　　10. 《QA文檔》--包括產品簡介、產品原理、產品功能列表、功能描述、功能流程、執行結果、數據庫結構、測試要求等，提供給軟件測試人員使用。
　　11. 《項目總結》--包括項目簡介、項目參與人員和開發時間、項目風險管理過程、項目功能列表、項目結構特點、技術特點、對項目的升級建議、對以后的項目的建議、人員素質情況等。
二、產品文檔
　　1. 《產品簡介》--包括公司背景、產品概念、適用范圍、產品功能、功能特點、運行要求和公司聯系地址。
　　2. 《產品演示》--包括公司簡介、產品背景、產品描述、產品特點、產品作用、適用范圍、使用分析、功能模塊、解決問題、合作伙伴、成功案例等。一般用Power
point或者VCD錄制軟件實現。
　　3. 《疑問解答》--列出用戶關心的問題和處理方法。用于解答軟件的操作功能和解決用戶的疑難問題。
　　4. 《功能介紹》--以《需求分析》為書寫基礎，包括軟件介紹、軟件結構、功能列表、功能描述和公司聯系地址。
　　5. 《技術白皮書》--以《技術分析》為書寫基礎，包括功能實現、技術選型、關鍵技術問題的解決、技術方案特點、技術升級方向等。
　　6. 《評測報告》--第三方權威評測報告。包括評測目的、評測范圍、評測環境、評測內容、實測數據、性能表現、結果分析和評測總結等。
　　7. 《安裝手冊》--包括系統環境、運行平臺、產品安裝過程、初始環境設置、安裝記錄等。
　　8. 《使用手冊》--包括產品簡介、功能列表、功能描述和解釋、功能操作、客戶服務和聯系方式等。
　　9. 《維護手冊》--包括產品簡介、系統須知、初始環境設置、系統配置、數據管理和備份、技術問題解答和聯系方式等。
　　10. 《用戶報告》--包括產品簡介、購買時間、使用目的、使用時間、使用地點、實施過程、出現問題和解決、產品總結和建議等。
　　11.《銷售培訓》--包括項目簡介、產品功能、產品特點、商業優勢、系統運行環境、適用范圍、目標客戶等。
****************************************************************************************
//**************************************************************************************
****************************************************************************************
概說概要設計怎么做 摘要：
? 本文是在概要設計實踐和學習中的一些心得與學習筆記，希望與大家分享，如有不妥之處歡迎指正。
? 關鍵字：
? 概要設計，結構化，OOD
? 正文：
? 在需求明確、準備開始編碼之前，要做概要設計，而詳細設計可能大部分公司沒有做，有做的也大部分是和編碼同步進行，或者在編碼之后。因此，對大部分的公司來說，概要設計文檔是唯一的設計文檔，對后面的開發、測試、實施、維護工作起到關鍵性的影響。
? 一、問題的提出
? 概要設計寫什么？概要設計怎么做？
? 如何判斷設計的模塊是完整的？
? 為什么說設計階段過于重視業務流程是個誤區？
? 以需求分析文檔還是以概要設計文檔來評估開發工作量、指導開發計劃準確？
? 結構化好還是面向對象好？
? 以上問題的答案請在文章中找。
? 二、概要設計的目的
? 將軟件系統需求轉換為未來系統的設計；
? 逐步開發強壯的系統構架；
? 使設計適合于實施環境，為提高性能而進行設計；
? 結構應該被分解為模塊和庫。
? 三、概要設計的任務
?? 制定規范：代碼體系、接口規約、命名規則。這是項目小組今后共同作戰的基礎，有了開發規范和程序模塊之間和項目成員彼此之間的接口規則、方式方法，大家就有了共同的工作語言、共同的工作平臺，使整個軟件開發工作可以協調有序地進行。
? 總體結構設計：
? 功能（加工）－>模塊：每個功能用那些模塊實現，保證每個功能都有相應的模塊來實現；
? 模塊層次結構：某個角度的軟件框架視圖；
? 模塊間的調用關系：模塊間的接口的總體描述；
? 模塊間的接口：傳遞的信息及其結構；
? 處理方式設計：滿足功能和性能的算法
? 用戶界面設計；
? 數據結構設計：
? 詳細的數據結構：表、索引、文件；
? 算法相關邏輯數據結構及其操作；
? 上述操作的程序模塊說明（在前臺？在后臺？用視圖？用過程？······）
? 接口控制表的數據結構和使用規則
? 其他性能設計。
? 四、概要設計寫什么
? 結構化軟件設計說明書結構（因篇幅有限和過時嫌疑，在此不作過多解釋）
? 任務：目標、環境、需求、局限；
? 總體設計：處理流程、總體結構與模塊、功能與模塊的關系；
? 接口設計：總體說明外部用戶、軟、硬件接口；內部模塊間接口（注：接口≈系統界面）
? 數據結構：邏輯結構、物理結構，與程序結構的關系；
? 模塊設計：每個模塊“做什么”、簡要說明“怎么做”（輸入、輸出、處理邏輯、與其它模塊的接口，與其它系統或硬件的接口），處在什么邏輯位置、物理位置；
? 運行設計：運行模塊組合、控制、時間；
? 出錯設計：出錯信息、處錯處理；
? 其他設計：保密、維護；
? OO軟件設計說明書結構
? 1 概述
? 系統簡述、軟件設計目標、參考資料、修訂版本記錄
? 這部分論述整個系統的設計目標，明確地說明哪些功能是系統決定實現而哪些時不準備實現的。同時，對于非功能性的需求例如性能、可用性等，亦需提及。需求規格說明書對于這部分的內容來說是很重要的參考，看看其中明確了的功能性以及非功能性的需求。
這部分必須說清楚設計的全貌如何，務必使讀者看后知道將實現的系統有什么特點和功能。在隨后的文檔部分，將解釋設計是怎么來實現這些的。
? 2 術語表
? 對本文檔中所使用的各種術語進行說明。如果一些術語在需求規格說明書中已經說明過了，此處不用再重復，可以指引讀者參考需求說明。
? 3 用例
? 此處要求系統用用例圖表述（UML），對每個用例（正常處理的情況）要有中文敘述。
? 4 設計概述
? 4.1 簡述
? 這部分要求突出整個設計所采用的方法（是面向對象設計還是結構化設計）、系統的體系結構（例如客戶/服務器結構）以及使用到的相應技術和工具（例如OMT、Rose）
? 4.2 系統結構設計
? 這部分要求提供高層系統結構（頂層系統結構、各子系統結構）的描述，使用方框圖來顯示主要的組件及組件間的交互。最好是把邏輯結構同物理結構分離，對前者進行描述。別忘了說明圖中用到的俗語和符號。
? 4.3 系統界面
? 各種提供給用戶的界面以及外部系統在此處要予以說明。如果在需求規格說明書中已經對用戶界面有了敘述，此處不用再重復，可以指引讀者參考需求說明。如果系統提供了對其它系統的接口，比如說從其它軟件系統導入/導出數據，必須在此說明。
? 4.4 約束和假定
? 描述系統設計中最主要的約束，這些是由客戶強制要求并在需求說明書寫明的。說明系統是如何來適應這些約束的。
? 另外如果本系統跟其它外部系統交互或者依賴其它外部系統提供一些功能輔助，那么系統可能還受到其它的約束。這種情況下，要求清楚地描述與本系統有交互的軟件類型以及這樣導致的約束。
? 實現的語言和平臺也會對系統有約束，同樣在此予以說明。
? 對于因選擇具體的設計實現而導致對系統的約束，簡要地描述你的想法思路，經過怎么樣的權衡，為什么要采取這樣的設計等等。
? 5 對象模型
? 提供整個系統的對象模型，如果模型過大，按照可行的標準把它劃分成小塊，例如可以把客戶端和服務器端的對象模型分開成兩個圖表述。在其中應該包含所有的系統對象。這些對象都是從理解需求后得到的。要明確哪些應該、哪些不應該被放進圖中。所有對象之間的關聯必須被確定并且必須指明聯系的基數。聚合和繼承關系必須清楚地確定下來。每個圖必須附有簡單的說明。
? 6 對象描述
? 在這個部分敘述每個對象的細節，它的屬性、它的方法。在這之前必須從邏輯上對對象進行組織。你可能需要用結構圖把對象按子系統劃分好。
? 為每個對象做一個條目。在系統對象模型中簡要的描述它的用途、約束（如只能有一個實例），列出它的屬性和方法。如果對象是存儲在持久的數據容器中，標明它是持久對象，否則說明它是個臨時對象（transient object）。
? 對每個對象的每個屬性詳細說明：名字、類型，如果屬性不是很直觀或者有約束（例如，每個對象的該屬性必須有一個唯一的值或者值域是有限正整數等）。
? 對每個對象的每個方法詳細說明：方法名，返回類型，返回值，參數，用途以及使用的算法的簡要說明（如果不是特別簡單的話）。如果對變量或者返回值由什么假定的話，Pre-conditions和Post-conditions必須在此說明。列出它或者被它調用的方法需要訪問或者修改的屬性。最后，提供可以驗證實現方法的測試案例。
? 7 動態模型
? 這部分的作用是描述系統如何響應各種事件。一般使用順序圖和狀態圖。
? 確定不同的場景（Scenario）是第一步，不需要確定所有可能的場景，但是必須至少要覆蓋典型的系統用例。不要自己去想當然地創造場景，通常的策略是描述那些客戶可以感受得到的場景。
? 7.1 場景（Scenarios）
? 對每個場景做一則條目，包括以下內容：
? 場景名：給它一個可以望文生義的名字
? 場景描述：簡要敘述場景是干什么的以及發生的動作的順序。
? 順序圖：描述各種事件及事件發生的相對時間順序。
? 7.2 狀態圖
? 這部分的內容包括系統動態模型重要的部分的狀態圖。可能你想為每個對象畫一個狀態圖，但事實上會導致太多不期望的細節信息，只需要確定系統中一些重要的對象并為之提供狀態圖即可。
? 8 非功能性需求
? 五、概要設計怎么做
? 結構化軟件設計方法：
? 詳細閱讀需求規格說明書，理解系統建設目標、業務現狀、現有系統、客戶需求的各功能說明；
? 分析數據流圖，弄清數據流加工的過程；
? 根據數據流圖決定數據處理問題的類型（變換型、事務型、其他型）；
? 通過以上分析，推導出系統的初始結構圖；
? 對初始結構圖進行改進完善：所有的加工都要能對應到相應模塊（模塊的完整性在于他們完成了需求中的所有加工），消除完全相似或局部相似的重復功能（智者察同），理清模塊間的層次、控制關系，減少高扇出結構，隨著深度增大扇入，平衡模塊大小。
? 由對數據字典的修改補充完善，導出邏輯數據結構，導出每種數據結構上的操作，這些操作應當屬于某個模塊。
? 確定系統包含哪些應用服務系統、客戶端、數據庫管理系統；
? 確定每個模塊放在哪個應用服務器或客戶端的哪個目錄、哪個文件（庫），或是在數據庫內部建立的對象。
? 對每個篩選后的模塊進行列表說明。
? 對邏輯數據結構進行列表說明。
? 根據結構化軟件設計說明書結構對其他需要說明的問題進行補充說明，形成概要設計說明書。
? OO軟件設計方法：
? 在OOA基礎上設計對象與類：在問題領域分析（業務建模和需求分析）之后，開始建立系統構架。
? 第一步是抽取建立領域的概念模型，在UML中表現為建立對象類圖、活動圖和交互圖。對象類就是從對象中經過“察同”找出某組對象之間的共同特征而形成類：
? 對象與類的屬性：數據結構；
? 對象與類的服務操作：操作的實現算法；
? 對象與類的各外部聯系的實現結構；
? 設計策略：充分利用現有的類；
? 方法：繼承、復用、演化；
? 活動圖用于定義工作流，主要說明工作流的5W（Do What、Who Do、When Do、Where Do、Why Do）等問題，交互圖把人員和業務聯系在一起是為了理解交互過程，發現業務工作流中相互交互的各種角色。
? 第二步是構建完善系統結構：對系統進行分解，將大系統分解為若干子系統，子系統分解為若干軟件組件，并說明子系統之間的靜態和動態接口，每個子系統可以由用例模型、分析模型、設計模型、測試模型表示。軟件系統結構的兩種方式：層次、塊狀
? 層次結構：系統、子系統、模塊、組件（同一層之間具有獨立性）；
? 塊狀結構：相互之間弱耦合
? 系統的組成部分：
? 問題論域：業務相關類和對象(OOA的重點)；
? 人機界面：窗口、菜單、按鈕、命令等等；
? 數據管理：數據管理方法、邏輯物理結構、操作對象類；
? 任務管理：任務協調和管理進程；
? 第三步是利用“4＋1”視圖描述系統架構：用例視圖及劇本；說明體系結構的設計視圖；以模塊形式組成包和層包含概要實現模型的實現視圖；說明進程與線程及其架構、分配和相互交互關系的過程視圖；說明系統在操作平臺上的物理節點和其上的任務分配的配置視圖。在RUP中還有可選的數據視圖。
? 第四步是性能優化（速度、資源、內存）、模型清晰化、簡單化（簡單就是享受）。
? 六、概要設計的原則
? 總體原則和方法：由粗到細的原則，互相結合的原則，定性分析和定量分析相結合的方法，分解和協調的方法和模型化方法。
? 要系統考慮系統的一般性、關聯性、整體性和層次性。
? 分解協調：目的是為了創造更好的系統。系統分解是指將一個復雜的系統分解為若干個子系統，系統協調一是系統內協調，即根據系統的總結構、總功能、總任務和總目標的要求，使各個子系統之間互相協調配合，在各個子系統局部優化基礎上，通過內部平衡的協調控制，實現系統的整體優化；
? 屏蔽抽象：從簡單的框架開始，隱含細節；
? 一致性：統一的規范、統一的標準、統一的文件模式；
? 每個模塊應當有一個統一命名的容易理解的名字；
? 編碼：由外向內（界面－>核心）；
? 面向用戶：概要設計是對于按鈕按下后系統“怎么做”的簡要說明；
? 模塊、組件的充分獨立性、封閉性；
? 同時考慮靜態結構與動態運行；
? 每個邏輯對象都應當說明其所處物理對象（非一一對應）；
? 每個物理對象都有合適的開發人員，并且利于分工與組裝。（詳細說明見本人另一篇文章：系統構架設計應考慮的因素）；
? 確立每個構架視圖的整體結構：視圖的詳細組織結構、元素的分組以及這些主要分組之間的接口；
? 軟件構架與使用的技術平臺密切相關，目前常用的平臺有J2EE、.NET、CORBA等等，因此具體的軟件構架人員應當具備使用這些平臺的軟件開發經驗；
? 通過需求功能與設計模塊之間的列表對應，檢查每個需求功能是否都有相應的模塊來實現，保證需求功能的可追溯性和需求實現（模塊）的完整性，同時可以檢查重復和不必要的模塊。
? 在需求調研分析過程中對業務處理過程了解的完整性和準確性非常重要。調查了解清楚所有的業務流程才能設計出適合各流程業務節點用戶業務特點和習慣的軟件，使開發出來的軟件更受歡迎。當然在進行軟件概要設計時，要盡量排除業務流程的制約，即把流程中的各項業務結點工作作為獨立的對象，設計成獨立的模塊，充分考慮他們與其他各種業務對象模塊的接口，在流程之間通過業務對象模塊的相互調用實現各種業務，這樣，在業務流程發生有限的變化時（每個業務模塊本身的業務邏輯沒有變的情況下），就能夠比較方便地修改系統程序模塊間的調用關系而實現新的需求。如果這種調用關系被設計成存儲在配置庫的數據字典里，則連程序代碼都不用修改，只需修改數據字典里的模塊調用規則即可。
? 七、概要設計的重要輸出
? 編碼規范：信息形式、接口規約、命名規則；
? 物理模型：組件圖、配置圖；
? 不同角度的構架視圖：用例視圖、邏輯視圖、進程視圖、部署視圖、實施視圖、數據視圖（可選）；
? 系統總體布局：哪些部分組成、各部分在物理上、邏輯上的相互關系；
? 兩個不可忽視的輸出：
? 與需求功能的關系：對于需求中的每一個功能，用哪一層、哪個模塊、哪個類、哪個對象來實現（一對多關系）；反過來，應當說明將要創建的系統每一層、每個模塊、每個對象、每一個類“做什么”，他們是為了幫助實現哪些功能（一對多關系）。（需求的顆粒度在一開始往往是比較粗的，因此根據功能點對于整體項目規模的估計或得到項目WBS其誤差范圍也是比較大的。更為重要的原因是，需求往往不是編碼工作分解的準確依據，因為一個需求的功能點可能對應多個代碼模塊，而多個需求的功能點也可能只對應一個或少數代碼模塊，同時還有軟件復用等因素要考慮，因此只有在概要設計完成以后才能準確地得到詳細設計或編碼階段的二次WBS，并估計較為準確的整體項目規模。）
? 邏輯與物理位置：每個對象在邏輯上分別落在哪一層、哪個模塊、哪個類；在物理上每個模塊、每個對象、每一個類放在哪個應用服務器或客戶端的哪個目錄、哪個文件（庫），或者是建立在數據庫管理系統中的什么東東（過程、函數、視圖、觸發器等等）。
? 八、結構化與面向對象方法特點比較
? 1. 從概念方面看，結構化軟件是功能的集合，通過模塊以及模塊和模塊之間的分層調用關系實現；面向對象軟件是事物的集合，通過對象以及對象和對象之間的通訊聯系實現；
? 2. 從構成方面看，結構化軟件＝過程＋數據，以過程為中心；面向對象軟件＝（數據＋相應操作）的封裝，以數據為中心；
? 3. 從運行控制方面看，結構化軟件采用順序處理方式，由過程驅動控制；面向對象軟件采用交互式、并行處理方式，由消息驅動控制；
? 4. 從開發方面看，結構化方法的工作重點是設計；面向對象方法的工作重點是分析；但是，在結構化方法中，分析階段和設計階段采用了不相吻合的表達方式，需要把在分析階段采用的具有網絡特征的數據流圖轉換為設計階段采用的具有分層特征的結構圖，在面向對象方法中則不存在這一問題。
? 5. 從應用方面看，相對而言，結構化方法更加適合數據類型比較簡單的數值計算和數據統計管理軟件的開發；面向對象方法更加適合大型復雜的人機交互式軟件和數據統計管理軟件的開發；
? 參考文獻：
? 《實用軟件工程》第二版，鄭人杰、殷人昆、陶永雷等著
? 《微軟項目：求生法則》Steve McConnell著，余孟學譯
? 《軟件工程：實踐者的研究方法》（第5版）Roger S.Pressman著
? 《軟件構架實踐》SEI軟件工程譯叢，林·巴斯著
? 《RUP2000》電子版；
? 《UML與系統分析設計》張龍祥著；
? 《面向對象的分析與設計》楊正甫著；
?? 本文作者郵箱： luls@dragonsoft.com.cn或 lulsnet@21cn.com
? 歡迎指正
*****************************************************************************************
*****************************************************************************************
軟件配置管理計劃示例 計劃名 CADCSC軟件配置管理計劃
項目名 中國控制系統CAD工程化軟件系統
項目委托單位
代表簽名 年 月 日
項目承辦單位
代表簽名 年 月 日
1 引言 1．1 目的
本計劃的目的在于對所開發的CADCSC軟件規定各種必要的配置管理條款，以保證所交付的CADCSC軟件能夠滿足項目委托書中規定的各種原則需求，能夠滿足本項目總體組制定的且經領導小組批準的軟件系統需求規格說明書中規定的各項具體需求。
軟件開發單位在開發本項目所屬的各子系統（其中包括為本項目研制或選用的各種支持軟件）時，都應該執行本計劃中的有關規定，但可以根據各自的情況對本計劃作適當的剪裁，以滿足特定的配置管理需求。剪裁后的計劃必須經總體組批準。
1．2 定義
本計劃中用到的一些術語的定義按GB/T 11457 和GB/T 12504。
1．3 參考資料
GB/T 11457 軟件工程術語
GB 8566 計算機軟件開發規范
GB 8567 計算機軟件產品開發文件編制指南
GB/T 12504 計算機軟件質量保證計劃規范
GB/T 12505 計算機軟件配置管理計劃規范
CADCSC 軟件質量保證計劃
2 管理 2．1 機構
在本軟件系統整個開發期間，必須成立軟件配置管理小組負責配置管理工作。軟件配置管理小組屬項目總體組領導，由總體組代表、軟件工程小組代表、項目的專職配置管理人員、項目的專職質量保證人員以及各個子系統軟件配置管理人員等方面的人員組成，由總體組代表任組長。各子系統的軟件配置管理人員在業務上受軟件配置管理小組領導，在行政上受子系統負責人領導。 軟件配置管理小組和軟件配置管理人員必須檢查和督促本計劃的實施。各子系統的軟件配置管理人員有權直接向軟件配置管理小組報告子項目的軟件配置管理情況。各子系統的軟件配置管理人員應該根據對子項目的具體要求，制訂必要的規程和規定，以確保完全遵守本計劃規定的所有要求。
2．2 任務
在軟件工程化生產的各個階段中，與本階段的階段產品有關的全部信息在軟件開發庫存放，與前面各個階段的階段產品有關的信息則在軟件受控庫存放。在研制與開發階段的階段產品的過程中，開發者和開發小組長有權對本階段的階段產品作必要的修改；但是如果開發者或開發小組長認為有必要個性前面有關階段的階段產品時，就必須通過項目的配置管理小組辦理正規的審批手續。因此，軟件開發庫屬開發這個階段產品的開發者管理，而軟件受控庫由項目的配置管理小組管理。軟件經過組裝與系統測試后，應該送入軟件產品庫，如欲對其修改，必須經軟件配置管理小組研究同意，然后報項目總體組組長批準。關于軟件配置要進行修改時的具體審批手續，將在第3.2條中詳細規定。
2．3 職責
在軟件配置管理小組中，各類人員要互相配合、分工協作，共同擔負起整個項目的軟件配置管理工作。其中各類人員的分工如下：
A． 組長是總體組代表，他對有關軟件配置管理的各項工作全面負責，特別要對更改建議的審批和評審負責；
B． 軟件工程小組組長負責監督在軟件配置管理工作中認真執行軟件工程規范；
C． 項目的專職配置管理人員檢查在作配置更改時的質量保證措施；
D． 各子系統的配置管理人員具體負責實施各自的配置管理工作，并參與各子系統的功能配置檢查和物理配置檢查；
E． 用戶代表負責反映用戶對配置管理的要求，并協助檢查各類人員對軟件配置管理計劃的執行情況；
F． 項目專職的配置管理人員協助組長開展各項軟件配置管理活動，負責審查所采用的配置管理工具、技術和方法，并負責匯總、維護和保存有關軟件配置管理活動的各項記錄。
2．4接口控制
對各類接口進行嚴格、合理的控制，是軟件配置管理中最重要的任務之一。整個軟件項目及其各子系統都必須對進行嚴格的控制。在工程化軟件系統中，主要的接口有如下五類：
A． 用戶界面：用戶界面是指各子系統與設計人員、用戶或維護人員之間的操作約定。同時還指實現這些操作約定的物理部件的功能與性能特性。
B． 系統內部接口：系統內部接口是指各子系統在集成為一個總的軟件系統時的各種連接約定。
C． 標準程序接口：標準程序接口是指各應用子系統與標準子程序庫（包括宿主計算機系統已有的庫程序）之間的調用約定。
D． 設備接口：設備接口是指各子系統與各種設備（包括終端和其他各種輸入/輸出設備）之間的連接約定。
E． 軟件接口：軟件接口是指各個子系統與宿主計算機上的系統軟件以及與調用本軟件的其它軟件系統之間的連接約定。 以上五類接口是一個軟件系統各項配置的重要組成部分。對接口修改進行合理的控制，是軟件配置管理的重要任務之一。這五類接口都涉及到CADCSC軟件系統的全局，因此，當要求對這五類接口中的任一類接口進行修改時，都必須辦理正規的審批手續，最后要經項目總體組批準。具體的審批程序將在本計劃的第3.2條中規定（可參閱表1）。
表1 兩類修改的審批程序
步驟 A類修改的審批程序 B類修改的審批程序
1 發現問題，填寫軟件問題報告單 發現問題，填寫軟件問題報告單
2 項目組長評審 項目組長評審
3 軟件配置管理小組評審 子系統配置管理人員評審
4 項目總體組批準 子系統負責人批準
5 修改配置并填寫軟件修改報告單 修改配置并填寫軟件修改報告單
6 項目組長評審 項目組長評審
7 軟件質量保證小組評審 子系統質量保證人員評審
8 總體組批準 項目的軟件配置管理小組與子系統負責人共同批準并報項目總體組備索
2．5 軟件配置管理計劃的實現
在實現軟件配置管理計劃的過程中，要特別注意實現以下三個里程碑：
A． 建立軟件配置管理小組：在項目總體組批準軟件配置管理計劃之后，立即成立軟件配置管理小組；
B． 建立各階段的配置基線：隨著CADCSC軟件系統及其所屬各子系統的任務書的評審和批準，建立起功能基線；隨著總體組編寫的《CADCSC軟件需求規格說明書》的批準，建立起指派基線；隨著CADCSC工程化軟件系統的集成與系統測試的完成，建立起產品基線。
C． 建立軟件庫：在本項目所屬的各個子系統的研制工作的開始，就建立起各個子系統的軟件開發庫，并在本項目配置管理小組的計算機上建立起有關該系統及其子系統的軟件受控庫。以后在每個開發階段的結束，建立各個子系統的新的開發庫，同時把這個階段的階段產品送入總的軟件受控庫，并在各個子系統的計算機上建立軟件受控庫的副本。軟件受控庫必須以主軟件受控庫為準。當全部開發工作結束，在配置管理小組的計算機上建立起軟件產品庫，并在各子系統的計算機上建立軟件產品庫的副本。
2．6 適用的標準、條例和約定
除應奠定本計劃第1.3條中指出的參考資料以及本計劃中的其他章條所作的各項規定外，還應該遵守如下標準、條例和約定：
A． 軟件開發庫、軟件受控庫與軟件產品庫的操作規程與管理規程；
B． 系統、子系統、模塊和程序單元的命名約定；
C． 文檔和測試用例的命名和管理規程。
這引起命名約定、操作規程與管理規程應由CADCSC項目技術組負責制訂，并應認真聽取各子系統項目負責人的意見，最后報項目總體組審批。在執行過程中，如果發現某些條款需要修改，則必須辦理正規的審批手續，最后要經項目總體組批準。具體的審批程序將在本計劃的第3.2條中規定。
3 軟件配置管理活動
3．1 配置標識
3．1．1 文檔
所有為本項目編制的文檔，都要符合GB 8567中的規定。CADCSC軟件系統及其所屬的各個子系統所編寫的文檔數目，可根據GB 8567的規定作適當的剪裁。剪裁方案由技術組提出建議，報總體組批準。
3．1．2 程序
所有屬于本項目的程序、分程序、模塊和程序單元，都要按照由項目技術組制訂，且經總體組批準的軟件系統的命名約定的規定來標識。
3．1．3 各類基線
所有屬于本項目及其各子系統的各類基線，首先要按照任務書、軟件需求規格說明書的規定確定其技術內容，然后按照軟件系統的上述命名約定的規定來標識。
3．2 配置控制
軟件配置的更改管理適用于本項目的所有文檔和代碼，其中包括本項目的各個運行軟件，也包括為本項目專門開發的支持軟件。配置控制的要點如下：
A． 修改批準權限；對本項目各個子系統及其專用支持軟件的功能基線、指派基線、產品基線及其集成系統的任何修改（稱為A類修改），都必須通過項目配置管理小組討論，并必須經總體組批準；對本項目各個子系統及其專用支持軟件的其他階段產品的任何修改（稱為B類修改），都必須通過本項目各個子系統的配置管理人員審查，并經項目的軟件配置管理小組與各個子系統負責人的共同批準并報項目總體組備案。
B． 修改審批程序：上述兩類修改的審批程序如表1。
C． 修改控制工具：修改控制工具是協助軟件配置管理人員進行配置控制的有效手段。
3．3 配置狀態審計
利用軟件問題報告單和軟件修改報告單對項目子系統及其支持軟件的配置狀態進行追蹤。對軟件問題報告單和軟件修改報告單的追蹤應由軟件配置管理工具自動實現，用戶可通過該軟件系統對其進行查詢。 注：本計劃在此處應給出軟件問題報告單與軟件修改報告單的具體格式，并作出必要的說明。鑒于本計劃擬采用附錄B（參考件）中建議的格式，因而這兩個報告單的格式及其說明可參閱附錄B。
3．4 配置的檢查和評審
項目軟件配置管理小組要對所有由第三方提供的軟件進行物理配置檢查；對本項目及其各個子系統的每一個新的釋放進行功能配置檢查和物理配置檢查；對宿主計算機系統所提供的軟件和硬件配置要每隔半年檢查一次；在軟件驗收前要對宿主計算機系統、各個子系統及其專用支持軟件的配置進行綜合檢查。
在軟件開發周期各階段的評審與檢查工作中，要對該階段所進行的配置管理工作進行必要的評審和檢查。應該進行評審與檢查的內容與次數，由CADCSC軟件質量計劃規定。配置修改的審批程序按本計劃第3.2條的規定處理（見表1）。
4 工具、技術和方法
在軟件的開發過程中，與軟件配置有關的工具有軟件測試工具、軟件配置管理工具、文檔輔助生成工具與圖形編輯工具等到三種。
A． C軟件測試工具：它支持用C語言編寫的模塊的靜態分析、結構測試與功能測試。主要功能為：協助測試人員判斷程序結構與變量使用情況是否有錯；給測試人員提供模塊語句覆蓋C0和分支覆蓋率C1的值、并顯示未覆蓋語句和未覆蓋分支的號碼及其分支謂詞，給出不同測試用例有效性的表格；同時提出功能測試的有效情況，并協助組織最終交付給用戶的有效測試用例的集合。
B． 軟件配置管理工具：它支持用戶對源代碼清單的更新管理以及對重新編譯與連接的代碼的自動組織；支持用戶在不同文檔相關內容之間進行相互檢索并確定同一文檔某一內容在本文檔中的涉及范圍；同時還應支持軟件配置管理小組對軟件配置更改進行科學的管理。
C． 文檔輔助生成工具與圖形編輯工具：它主要協助用戶繪制描述程序流程與結構的DFD圖與SC圖、繪制描述軟件功能（輸入、輸出關系）的曲線以及繪制描述系統特性的一些其他圖形，同時還可生成若干與CADCSC軟件文檔編制大綱適應的文檔模板。用戶利用這個工具的正文與圖形編輯功能以及上述輔助功能，可以比較方便地產生清晰悅目的文檔，也有利于對文檔進行更改，這有助于提高文檔的編制質量。
有關這些工具的詳細需求可參閱這三項工具的需求規格說明書中的規定。
5 對供貨單位的控制
CADCSC項目所屬的各個子系統開發組如果需要從軟件銷售單位購買、委托其他開發單位、從開發單位現存軟件庫選用或從項目委托單位或用戶的現有連鎖反應加中選用軟件時，則在選用前應向CADCSC總體組報告，然后由CADCSC總體組組織"軟件選用評審小組"進行評審、測試與檢查，只有當演示成功、測試合格后才能批準使用。如果只選用其中部分內容，則按等待開發軟件的處理過程辦理，此時CADCSC總體組不予預。在進行上述工作過程中，軟件配置管理人員要進行下列工作：
A． 項目的軟件配置管理小組要參加對上述四類由間接供貨單位提供的軟件的物理配置檢查； 這些軟件的功能配置檢查由項目的軟件質量保證小組負責。
B． 在這些軟件送入軟件受控庫與其他軟件成分進行組裝之前，軟件配置管理小組要對其存放媒體和配置標識進行認真的審查。
C． 由軟件質量保證小組審查選用的上述四類軟件，必須經過正式的驗收手續，并由項目技術管理小組負責人批準，然后置于軟件配置管理小組的控制之下。 6 記錄的懼維護和保存在本項目及其所屬的各個子系統的研制與開發期間，要進行各種軟件配置管理活動。準確記錄、及時分析并妥善存放有關這些活動的記錄，對這些軟件的下沉運行與維護工作十分有利。在軟件配置管理小組中，應有專人負責收集、匯總與保存這些記錄。
A． 基礎上組裝系統、各個子系統、專用支持軟件及選用軟件的功能基線、指派基線與產品基線要送入軟盤或磁帶，至少必須一式兩份且存放在兩個不同的地點。這些記錄應該每6個月拷貝一次，以免意外損傷與自然老化。
B． 上述這些軟件的文檔也應送入軟盤或磁帶，至少必須工式兩份且存放在兩個不同的地點，并應有一份打印的硬拷貝。磁媒體應該每隔6個月拷貝一次，以免意外損傷與自然老化。
C． 軟件產品的源程序、測試數據、測試報告及其他有關文檔，除了按A、B規定妥善存放外，要在項目結束后再保存2年，或在條件成熟時轉交給這些軟件產品的生產系統。
注：具體保存年限要根據項目的性質與開發單位的任務來確定，此處僅作為一個示例。
D． 上述這些軟件的各項配置的個性狀態、評審記錄與修改歷史，要作為這些軟件的歷史記錄來保存，目前可用打印硬拷貝一式兩份存放，有條件時再轉移到在線光學存儲媒體中。
E． 鑒于處理版權或清理財務的需要，本軟件系統的各項配置可能要求存放5~7年，但由于我國對這些問題尚無明確的規定，因此，有關本條款的具體規定待將來有必要與可能時再作修改與補充。

總結

以上是生活随笔為你收集整理的关于软件文档的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。