4.1.5 軟件系統工具

　　按軟件過程活動將軟件工具分為 軟件開發工具、軟件維護工具、軟件管理和軟件支持工具。

　　軟件開發工具有：需求分析工具、設計工具、編碼與排錯工具、測試工具 等。

　　需求分析工具，生成完整的、清晰的、一致的功能規范。功能規范是軟件開發者和用戶間的契約，也是軟件設計者的和實現者的依據。正確、完整 表達清晰的、無歧義的。

　　需求分析工具分為 基于自然語言或圖形描述的工具，基于形式化需求定義語言的工具。

　　項目管理工具：項目的 計劃、調度、通信、成本估算、資源分配、質量控制等。

　　4.2 需求管理

　　需求 最終文檔 經過評審批準后，則定義了需求基線 Baseline;構筑了 功能需求 和 非功能需求 的一個 約定Agreement。約定是需求開發和需求管理之間的橋梁。

　　需求管理是一個 對系統 需求變更、了解和控制 的過程，初始需求導出的同時 就啟動了需求管理規劃。

　　4.2.1 需求管理原則

　　過程能力成熟度模型 CMM，指導軟件過程改進，5個成熟級別，6個關鍵過程域KPA。

　　一旦需求 文檔化了，開發組和有關團隊 需要評審文檔。發現問題應與客戶或者其他需求源協商解決。軟件開發計劃是基于 已確認的需求。

　　絕不要承諾 任何 無法實現的事。

　　關鍵處理領域 通過版本控制和變更控制 來管理需求文檔。確保與新的需求保持一致。

　　4.2.2 需求規格說明的版本控制

　　版本控制是管理需求的一個必要方面，必須統一確定需求文檔的每一個版本，當需求發生變更時，及時通知所有涉及人員。

　　為了盡量減少困惑、沖突、誤傳，應該僅允許指定的人員來更新需求。

　　清楚地區分草稿和文檔定稿版本。

　　4.2.3 需求變更

　　遲到的 需求變更 會對已進行的工作產生非常大的影響。

　　如果每一個建議的需求變更都采用，該項目將可能永遠無法完成。

　　需求文檔應該 精確描述 要交付的產品。

　　項目負責人 在信息充分的條件下 做出決策。

　　變更成本計算 應該包括 需求文檔的修改、系統修改的設計、實現的成本。

　　變更控制過程 并不是給變更設置障礙，相反，它是一個渠道和過濾器，確保采納最合適的變更，使變更產生的負面影響降到最低，變更過程應該做成文檔。

　　絕不能 刪除或者修改 變更請求的 原始文檔。

　　變更控制委員會 只要能決定合適的人做正確的事就足夠了，在保證權威性的前提下 應盡可能精簡人員。

　　對每個變更 權衡利弊 做出決定。

　　“利”包括 節省資金 或 額外收入、客戶滿意度、競爭優勢、減少上市時間;

　　“弊”是指 增加開發費用、推遲交付日期、產品質量下降、減少功能、用戶不滿意。

　　變更總是有代價的，即使 拒絕的變更 也因為決策行為 而耗費資源。

　　接受了重要的需求變更時，為了適應變更情況 要與管理部門和客戶重新協商約定。推遲交貨時間、增加人手、推遲實現尚未實現的較低優先級的需求，或質量上進行折中。

　　要是不能獲得一些約定的調整，應該把面臨的風險寫進風險計劃中。

　　4.2.4 需求跟蹤

　　需求、體系結構、其他設計部件、源代碼模塊、測試、幫助文件、文檔 等。

　　跟蹤能力(聯系)鏈(traceability link)是優秀需求規格說明書的一個特征，確保軟件需求規格說明包括所有客戶需求。

　　跟蹤能力聯系鏈 記錄了單個需求之間的 父層、互連、依賴 的關系。

　　不必擁有所有種類的跟蹤能力聯系鏈，要根據具體情況調整。

　　4.2.5 需求變更的代價和風險

　　只有在知道變更成本后 才能做出理智的選擇，一個表面上很簡單的變更 也可能轉變成很復雜的局面。

　　影響分析 確定對現有系統做出是修改或者拋棄的決定，創建新系統以及評估每個任務的工作量，進行 影響分析的能力 依賴于 跟蹤能力、數據的質量、完整性。

　　2010年下半年軟考試題及答案解析匯總

　　2010年下半年軟件水平考試答案

　　2011年軟考系統架構設計師學習筆記匯總