在初步專案範圍說明書中己文件化的主要的可交付物、假設和約束條件的基礎上準備詳細的專案範圍說明書，是專案成功的關鍵。範圍定義的輸入包括以下內容：
①專案章程。②專案範圍管理計畫。③組織過程資產。④批准的變更申請。
專案範圍是為了達到專案目標，為了交付具有某種特製的產品和服務，專案所規定要做的。
在資訊系統專案中，產品範圍是指資訊系統產品或者服務所應該包含的功能，專案範圍是指為了能夠交付資訊系統專案所必須做的工作。產品範圍是專案範圍的基礎。產品的範圍定義是資訊系統要求的度量。而專案範圍的定義是生產專案計畫的基礎。產品範圍描述是專案範圍說明書的重要組成部分。
專案的成本管理中，成本預算將總的成本估算分配到各項活動和工作包上，來建立乙個成本的基線。
專案時間管理包括使專案按時完成所必需的管理過程。專案時間管理中的過程包括：活動定義、活動排序、活動的資源估算、活動歷時估算、制定進度計畫以及進度控制。
為了得到工作分解結構(work breakdown structure，wbs)中最底層的交付物，必須執行一系列的活動。對這些活動的識別以及歸檔的過程就是活動定義。
魚骨圖(也稱為ishikawa圖)是一種發現問題「根本原因」的方法，通常用來進行因果分析。
配置項是構成產品配置的主要元素，配置項主要有以下兩大類： (1)屬於產品組成部分的工作成果：如需求文件、設計文件、源**和測試用例等; (2)屬於專案管理和機構支撐過程域產生的文件：如工作計畫、專案質量報告和專案跟蹤報告等。這些文件雖然不是產品的組成部分，但是值得儲存。所以裝置清單不屬於配置項。
所有的配置項都應列入版本控制的範疇。配置項的狀態通常有3種，分別是草稿、正式發布和正在修改。
配置管理是pmbok、is09000和cmmi中的重要組成元素，它在產品開發的生命週期中，提供了結構化的、有序化的、產品化的管理方法，是專案管理的基礎工作。配置管理是通過技術和行政手段對產品及其開發過程和生命週期進行控制、規範的一系列措施和過程。
產品配置是指乙個產品在其生命週期各個階段所產生的各種形式（機器可讀或人工可讀）和各種版本的文件、電腦程式、部件及資料的集合。該集合中的每乙個元素稱為該產品配置中的乙個配置項（configurationitem，ci)，配置項主要有兩大類： 屬於產品組成部分的工作成果，如需求文件、設計文件、源**、測試用例等。屬於專案管理和機構支撐過程域產生的文件，如工作計畫、專案質量報告、專案跟蹤報告等。這些文件雖然不是產品的組成部分，但是值得儲存。
軟體系統的文件可以分為使用者文件和系統文件兩類。使用者文件主要描述系統功能和使用方法，並不關心這些功能是怎樣實現的；系統文件描述系統設計、實現和測試等各方面的內容。使用者文件：使用者文件是使用者了解系統的第一步，它可以讓使用者獲得對系統的準確的初步印象。使用者文件至少應該包括下述5方面的內容：(1)功能描述：說明系統能做什麼； (2)安裝文件：說明怎樣安裝這個系統以及怎樣使系統適應特定的硬體配置；(3)使用手冊：簡要說明如何著手使用這個系統（通過豐富的例子說明怎樣使用常用的系統功能，並說明使用者操作錯誤時怎樣恢復和重新啟動）；(4)參考手冊：詳盡描述使用者可以使用的所有系統設施以及它們的使用方法，並解釋系統可能產生的各種出錯資訊的含義（對參考手冊最主要的要求是完整，因此通常使用形式化的描述技術）；(5)操作員指南（如果需要有系統操作員的話）：說明操作員應如何處理使用中出現的各種情況。
系統文件：所謂系統文件指從問題定義、需求說明到驗收測試計畫這樣一系列和系統實現有關的文件。描述系統設計、實現和測試的文件對於理解程式和維護程式來說是非常重要的。
專案管理工具具有以下特徵： (1) 覆蓋整個軟體生存週期； (2) 為專案排程提供多種有效手段； (3)利用估算模型對軟體費用和工作量進行估算； (4) 支援多個專案和子專案的管理； (5) 確定關鍵路徑，鬆弛時間，超前時間和滯後時間； (6)對專案組成員和專案任務之間的通訊給予輔助； (7) 自動進行資源平衡； . (8) 跟蹤資源的使用； (9)生成固定格式的報表和剪裁專案報告。 成本估算工具就是一種典型的專案管理工具。
需求管理
①需求管理的關鍵過程領域不涉及收集和分析專案需求，而是假定已收集了軟體需求，或者已由更高一級的系統給定了需求。
②開發人員在向客戶以及有關部門承諾某些需求之前，應該確認需求和約束條件、風險、偶然因素、假定條件等。
③關鍵處理領域同樣建議通過版本控制和變更控制來管理需求文件。
軟體需求工程是包括建立和維護軟體需求文件所必須的一切活動的過程，可以分為需求開發和需求管理兩大工作。
需求開發包括需求獲取、需求分析、編寫需求規格說明書（需求定義）和需求驗證4個階段。在需求開發階段需要確定軟體所期望的使用者型別，獲取各種使用者型別的需求，了解實際的使用者任務和目標，以及這些任務所支援的業務需求。
需求管理是乙個對系統需求變更、了解和控制的過程，逋常包括定義需求基線、處理需求變更和需求跟蹤方面的工作。需求管理強調：控制對需求基線的變動；保持專案計畫與需求的一致；控制單個需求和需求文件的版本情況；管理需求和聯絡鏈，或者管理單個需求和其他專案可交付產品之間的依賴關係；跟蹤基線中的需求狀態。
需求開發與需求管理是相輔相成的，需求開發是主線、目標；需求管理是支援、保障。
需求定義的過程也就是形成需求規格說明書的過程，通常有兩種需求定義的方法： 嚴格定義方法和原型方法。
嚴格定義方法也稱為預先定義，需求的嚴格定義建立在以下基本假設之上：
①所有需求都能夠被預先定義。這意味著在沒有實際系統執行經驗的情況下，全部的系統需求均可通過邏輯推斷得到。但這種假設在許多場合是不能成立的。
②開發人員與使用者之間能夠準確而清晰地交流。
③採用圖形（或文字）可以充分體現最終系統。在使用嚴格定義需求的開發過程中，開發人員與使用者之間交流與溝通的主要工具是定義報告，包括文字、圖形、邏輯規則和資料字典等技術工具。
原型化的需求定義過程是乙個開發人員與使用者通力合作的反覆過程。從乙個能滿足使用者基本需求的原型系統開始，允許在開發過程中提出更好的要求，根據使用者的要求不斷地對系統進行完善，它實質上是一種迭代的迴圈型的開發方式。採用原型方法時需注意一下幾個問題：
①並非所有的需求都能在系統開發前被準確地說明。
②專案干係人之間通常都存在交流上的困難。
③需要實際的、可供使用者參與的系統模型。
④有合適的系統開發環境。
⑤反覆是完全需要和值得提倡的。需求一旦確定，就應該遵從嚴格定義的方法。
需求變更
(1)所有需求變更必須遵循變更控制過程：
(2) 對於未獲得批准的變更，不應該做設計和實現工作；
(3)變更應該由專案變更控制委員會決定實現哪些變更；
(4) 專案風險承擔者應該能夠了解變更資料庫的內容；
(5)決不能從資料庫中刪除或者修改變更請求的原始文件；
(6) 每乙個整合的需求變更必須能跟蹤到乙個經核准的變更請求。
通常可以按軟體過程活動將軟體工具分為軟體開發工具、軟體維護工具、軟體管理和軟體支援工具。
軟體開發工具：需求分析工具、設計工具、編碼與排錯工具。
軟體維護工具：版本控制工具、文件分析工具、開發資訊庫工具、逆向工程工具、再工程工具。
軟體管理和軟體支援工具：專案管理工具、配置管理工具、軟體評價工具、軟體開發工具的評價和選擇。
cmm即軟體開發能力成熟度模型，是用來指導軟體過程改進的。
系統架構設計師 Cache
試題1 以下關於cache的敘述中，正確的是 答案 b 解析 cache是介於cpu與記憶體之間的一種快取記憶體。這種儲存器速度比記憶體快了很多倍，利用到區域性性原理，只需要少量的cache，便能使整個機器訪問記憶體資料得到極大的提公升。所以cache是一種應用非常普遍的技術，cache在實際應用中...
系統架構設計師 匯流排
試題1 掛接在匯流排上的多個部件，答案 b 解析 本題考查考生對匯流排概念的理解。匯流排是乙個大家都能使用的資料傳輸通道，大家都可以使用這個通道，但傳送資料時，是採用的分時機制，而接收資料時可以同時接收，也就是說，同乙個資料，可以並行的被多個客戶收取。如果該資料不是傳給自己的，資料報將被丟棄。試題2...
系統架構設計師考試心得
對於有志於提公升自己的程式猿，軟考是乙個不錯的選擇，不只是為了證書，在考證的同時也能學到很多知識，擴充套件視野。初 中級考試都沒有什麼難度，高階就要難得多了。本人考了兩次總算是通過了架構考試，回想備考過程，感 dan 慨 tong 萬千。博就談談心得吧。心得 建議都是針對向我一樣記憶力不強 知識面也...