軟考筆記（九）高階系統架構師/分析師：軟體工程與專案管理
目錄
資訊系統開發方法
1，結構化系統分析與設計方法（SSA&D）
基本思想是：用系統的思想，系統工程的方法，按使用者至上的原則，結構化、模組化、自頂向下對資訊系統進行分析與設計；
嚴格區分工作階段，每階段有任務和結果；強調系統開發過程的整體性和全域性性；系統開發過程工程化，文件資料標準化。
自頂向下的開發方式，適用於那些需求明確，但技術難度不大的系統開發
面向資料流的方法
結構化方法使用的主要分析設計工具是“程式流程圖、資料流程圖等”
2，原型方法
基本思想是：憑藉著系統分析人員對使用者要求的理解，在軟體環境支援下，快速地給出一個實實在在的模型（或稱為原型、雛形），然後與使用者反覆協商修改，最終形成實際系統。
適用於需求不明確的情況。
3，面向物件的開發方法（OO）
出發點和基本原則是：儘可能模擬人類習慣的思維方式，使開發軟體的方法與過程儘可能接近人類認識世界、解決問題的方法與過程；更好的複用性；關鍵在於建立一個全面、合理、統一的模型；分析、設計、實現三個階段，界限不明確。
4，面向服務的開發方法 SOA
以粗粒度、鬆散耦合和標準的服務為基礎，加強了系統的可複用性和可演化性
企業資訊工程
資訊工程方法認為，與企業的資訊系統密切相關的三要素是：企業的各種資訊、企業的業務過程和企業採用的資訊科技
資訊工程自上而下地將整個資訊系統的開發過程劃分為四個實施階段，分別是資訊規劃階段、業務領域分析階段、系統設計階段和系統構建階段。
資訊系統生命週期
軟體工程開發模型
開發模型主要包括：
- 瀑布模型
- 演化模型
- 增量模型
- 迭代模型
- 螺旋模型
- 快速原型
- 噴泉模型
- V模型
瀑布模型是將軟體生存週期各個活動規定為依線性順序連線的若干階段的模型。它包括可需求分析、設計、編碼、測試、執行和維護。
瀑布模型的優點是：容易理解，管理成本低，強調開發的階段性早期計劃及需求調查和產品測試。不足之處是：客戶必須能夠完整、正確和清晰地表達他們的需要，需求或設計中的錯誤往往只有到了專案後期才能夠被發現。
增量模型融合了瀑布模型的基本成分和原型實現的迭代特徵，它假設可以將需求分段為一系列增量產品，每一增量可以分別地開發。該模型採用隨著日程時間的進展而交錯的線性序列，每一個線性序列產生軟體的一個可釋出的“增量”。而瀑布模型難以適應這種需求的不確定性和變化，於是出現了快速原型這種新的開發方法。原型是預期系統的一個可執行版本，反映了系統性質的一個選定的子集。一個原型不必滿足目標軟體的所有約束，其目的是能快速、低成本地構建原型。
螺旋模型將瀑布模型和演化模型結合起來，加入了兩種模型均忽略的風險分析，彌補了這兩種模型的不足。螺旋模型強調風險分析，使得開發人員和使用者對每個演化層出現的風險有了解，繼而做出應有的反應。因此特別適用於龐大、複雜並且具有高風險的系統。與瀑布模型相比，螺旋模型支援使用者需求的動態變化，為使用者參與軟體開發的所有關鍵決策提供了方便，有助於提高軟體的適應能力，並且為專案管理人員及時調整管理決策提供了便利，從而降低了軟體開發的風險。
瀑布模型：
- 瀑布模型是一個特別經典的，老套的週期模型。工序簡化，將功能實現和設計分開。便於分工協作。
- 一般情況下將軟體開發週期分為計劃、需求分析、概要設計、詳細設計、編碼以及單元測試、測試、執行維護等幾個階段。
- 瀑布模型的週期是環環相扣的。每個週期中互動點都是一個里程碑，上一個週期的結束需要輸出本次活動的工作結果，本次的活動的工作結果將會作為下一個週期的輸入。這樣，當某一個階段出現了不可控的問題的時候，就會導致返工，返回到上一個階段，甚至會延遲下一個階段。
自上而下、相互銜接的固定次序
優點:
(1)為專案提供了按階段劃分的檢查點。
(2)當前一階段完成後，您只需要去關注後續階段。
(3)可在迭代模型中應用瀑布模型。
增量迭代應用於瀑布模型。迭代1解決最大的問題。每次迭代產生一個可執行的版本,同時增加更多的功能。每次迭代必須經過質量和整合測試。
缺點:
(1)在專案各個階段之間極少有反饋。
(2)只有在專案生命週期的後期才能看到結果。
(3)通過過多的強制完成日期和里程碑來跟蹤各個專案階段。
(4)瀑布模型的突出缺點是不適應使用者需求的變化。
V模型：
- V模型從整體上看起來，就是一個V字型的結構，由左右兩邊組成。
- 左邊的下劃線分別代表了需求分析、概要設計、詳細設計、編碼。
- 右邊的上劃線代表了單元測試、整合測試、系統測試與驗收測試。
- 看起來V模型就是一個對稱的結構，它的重要意義在於，非常明確的表明了測試過程中存在的不同的級別，並且非常清晰的描述了這些測試階段和開發階段的對應關係。
優點：相對於瀑布模型，V模型測試能夠儘早的進入到開發階段。
缺點：雖然測試儘早的進入到開發階段，但是真正進行軟體測試是在編碼之後，這樣忽視了測試對需求分析，系統設計的驗證，時間效率上也大打折扣。
明確標註了測試過程中存在不同的測試型別，明確表示出了開發階段與測試各階段的對應關係。
原型化模型：
- 過程：
- 第一步就是建立一個快速原型，能夠滿足專案干係人與未來的使用者可以與原型進行互動
- 再通過與相關干係人進行充分的討論和分析，最終弄清楚當前系統的需求
- 進行了充分的瞭解之後，在原型的基礎上開發出使用者滿意的產品
- 在實際的專案過程中，藉助於組織過程資產以及快速模型軟體，一般在需求分析的時候，就可以建立一些簡單的原型，例如在第一家YH公司中，因為是“行業軟體提供商”，所以擁有各個地域的行業解決軟體方案，慣用的伎倆就是將其他地市的專案拿到本次專案實施地，作為原型化模型。原型化模型是極具意義的專案實踐。
在系統開發中，原型是系統的一個早期可執行的版本，它反映最終系統的部分重要特性。從原型是否實現功能來分，可分為:水平原型和垂直原型兩種。
水平原型也稱為行為原型，用來探索預期系統的一些特定行為，並達到細化需求的目的。水平原型通常只是功能的導航，但未真實實現功能。水平原型主要用在介面上。
垂直原型也稱為結構化原型，實現了一部分功能。垂直原型主要用在複雜的演算法實現上。
從原型的最終結果來分，可分為拋棄式原型和演化式原型。
拋棄式原型也稱為探索式原型，是指達到預期目的後，原型本身被拋棄。拋棄式原型主要用在解決需求不確定性、二義性、不完整性、含糊性等。
演化式原型為開發增量式產品提供基礎，逐步將原型演化成最終系統，主要用在必須易於升級和優化的場合，適合於Web專案。
螺旋模型：
- 尤其重視風險分析階段，特別適用於龐大並且複雜，非常高風險的專案。
- 通常螺旋模型由四個階段組成：
制定計劃、風險分析、實施工程和客戶評估。螺旋模型中，釋出的第一個模型甚至可能是沒有任何產出的，可能僅僅是紙上談兵的一個目標，但是隨著一次次的交付，每一個版本都會朝著固定的目標邁進，最終得到一個更加完善的版本。
構件組裝模型CBSD模型
基於構件的軟體開發（Component Based Software Development，CBSD）模型是利用模組化方法，將整個系統模組化，並在一定構件模型的支援下，
複用構件庫中的一個或多個軟體構件，通過組合手段高效率、高質量地構造應用軟體系統的過程。基於構件的開發模型融合了螺旋模型的許多特徵，本質上是演化型的，開發過程是迭代的。
基於構件的開發模型由軟體的需求分析和定義、體系結構設計、構件庫建立、應用軟體構建、測試和釋出5個階段組成。
統一過程 RUP模型
UP/RUP把一個專案分為4個不同的階段：
初始階段
（1）專案藍圖文件（核心需求，關鍵特性，主要約束）
（2）用例模型
（3）專案計劃
細化階段
（1）完成架構設計
（2）淘汰高風險元素
構造階段
（1）UML 設計模型
（2）測試用例
交付階段
（1）可執行的軟體產品
（2）使用者手冊
（3）使用者支援計劃
用例驅動， 以架構為中心，迭代和增量
噴泉模型：
（fountainmodel,(面向物件的生存期模型,OO模型)）
噴泉模型與傳統的結構化生存期比較，具有更多的增量和迭代性質，生存期的各個階段可以相互重疊和多次反覆，而且在專案的整個生存期中還可以嵌入子生存期。就像水噴上去又可以落下來，可以落在中間，也可以落在最底部。
RAD模型：
快速應用開發（RAD）模型是一個增量型的軟體開發過程模型。強調極短的開發週期。RAD模型是瀑布模型
採用RAD模型的軟體通過大量使用可複用構件，採用基於構件的建造方法贏得快速開發。如果需求理解得好且約束了專案的範圍，隨後是資料建模、過程建模、應用生成、測試及反覆。
設計思想：
（1）讓使用者更主動地參與到系統分析、設計和構造活動中來。
（2）將專案開發組織成一系列重點突出的研討會，研討會要讓專案投資方、使用者、分析員、設計人員和構造人員一同參與。
（3）通過一種迭代的構造方法加速需求分析和設計階段。
（4）讓使用者提前看到一個可工作的系統。
是構件組裝模型（CBSD）+ 瀑布模型
構建 庫 就是抽取 共性部分形成模組元件
軟體工程開發方法
主要包括：
開發方法主要包括：
- 迭代開發方法
- 快速應用開發
- 構件組裝模型/基於構件的開發方法
- 統一過程/統一開發方法
- 模型敏捷開發方法
- 模型驅動的開發方法
- 基於架構的開發方法
敏捷方法：
基本原則：
短平快的會議
小型版本釋出
較少的文件
合作為重
客戶直接參與
自動化測試
適應性計劃調整
結對程式設計
測試驅動開發
持續整合
重構
極限程式設計（XP）：敏捷開發的典型方法之一，是一種輕量級（敏捷）、高效，低風險、柔性、可預測的、科學的軟體開發方法，它由價值觀、原則、實踐和行為4個部分組成。其中4大價值觀為溝通、簡單性、反饋和勇氣。
水晶法（Crystal）：水晶方法體系與XP一樣，都有以人為中心的理念，但在實踐上有所不同。水晶方法體系考慮到人們一般很難嚴格遵循一個紀律約束很強的過程，認為每一種不同的專案都需要一套不同的策略、約定和方法論。因此，與XP的高度紀律性不同，水晶方法體系探索了用最少紀律約束而仍能成功的方法，從而在產出效率與易於運作上達到一種平衡。也就是說，雖然水晶系列不如XP那樣的產出效率，但會有更多的人能夠接受並遵循它。
並列爭球法（Scrum）：用迭代的方法，其中把每30天一次的迭代稱為一個“衝刺”，並按需求的優先順序來實現產品。多個自組織和自治小組並行地遞增實現產品。協調是通過簡短的日常會議來進行的
自適應軟體開發（ASD）：ASD的核心是三個非線性的、重迭的開發階段：猜測，合作與學習。
逆向工程：
- 實現級：包括程式的抽象語法樹、符號表、過程的設計表示
- 結構級：包括反映程式分量之間相互依賴關係的資訊，例如呼叫圖、結構圖、程式和資料結構
- 功能級：包括反映程式段功能及程式段之間關係的資訊，例如資料和控制流模型
- 領域級：包括反映程式分量或程式諸實體與應用領域概念之間對應關係的資訊，例如實體關係模型
參考：https://www.jianshu.com/p/3069f9c5a17e
CMMI
CMMl成熟度級別為五個成熟度級別，每一級是一個層次，作為繼續進行過程改進的基礎。
（1）成熟度級別1級：初始級。該級別過程是隨意且混亂的，組織不能提供穩定的環境支撐這些過程。組織的成功依賴於內部人員的能力，且組織有過渡承諾的傾向。
（2）成熟度級別2級：已管理級。該等級的過程是按照方針和計劃執行的過程，僱傭有技能的人，有充分資源，有干係人蔘與，有監督和控制等。
（3）成熟度級別3級：已定義級。處於這個級別時，專案的過程得到清晰的說明與理解，並以標準、規程、工具與方法的形式進行描述。與能力等級2級相比，3級採用的專案標準是從組織標準中剪裁過來的，2級適用於特定專案而3級適用於特定的組織，同時3級的過程描述比2級更為嚴謹，過程得到了更積極的管理。
（4）成熟度級別4級：已量化級。組織與專案建立了質量與過程效能的量化目標並將其用作管理專案的準則。成熟度級別4級和3級的區別是，4級對於過程效能的可預測性高。
（5）成熟度級別5級：持續優化級。5級關注於通過增量式的與創新式的過程與技術改進，不斷地改進過程效能。4級與5級的區別是，在4級別時關注子過程層面的績效，5級則是關注整體績效。
專案可行性分析
可行性是指在企業當前的條件下，是否有必要建設新系統，以及建設新系統的工作是否具備必要的條件。也就是說，可行性包括必要性和可能性。參考國家標準《計算機軟體文件編制規範》（GB/T8567-2006），在資訊系統建設專案中，可行性研究通常從經濟可行性、技術可行性、法律可行性和使用者使用可行性四個方面來進行分析，其中經濟可行性通常被認為是專案的底線。
1.經濟可行性經濟可行性也稱為投資收益分析或成本效益分析，主要評估專案的建設成本、執行成本和專案建成後可能的經濟收益。多數專案只有建設成本能控制在企業可接受的預算內的時候，專案才有可能波批准執行。而經濟收益的考慮則非常廣泛，可以分為直接收益和間接收益、有形收益和無形收益，還可以分為一次性收益和非一次性收益、可定量的收益和不可定量的收益等。要注意的是，在系統開發初期，由於使用者需求和候選系統方案還沒有確定，成本不可能得到準確的估算。因此，此時的經濟可行性分析只能大致估算系統的成本和收益，判斷資訊系統的建設是否值得。
2.技術可行性技術可行性也稱為技術風險分析，研究的物件是資訊系統需要實現的功能和效能，以及技術能力約束。技術可行性主要通過考慮以下問題來進行論證：
（1）技術：現有的技術能力和資訊科技的發展現狀是否足以支援系統目標的實現。
（2）資源：現有的資源（例如，掌握技術的員工、企業的技術積累、構件庫、軟硬體條件等）是否足以支援專案的實施。
（3）目標：由於在可行性研究階段，專案的目標是比較模糊的，因此技術可行性最好與專案功能、效能和約束的定義同時進行。在可行性研究階段，調整專案目標和選擇可行的技術體系都是可以的，而一旦專案進入開發階段，任何調整都意味著更多的開銷。需要特別指出的是，技術可行性絕不僅僅是論證在技術手段上是否可實現，實際上包含了在當前資源條件下的技術可行性。例如，開發一個計算機作業系統對於美國微軟公司來說，這是可行的，但對其他絕大多數企業來說，這都是不可行的。投資不足、時間不足、預設的開發目標技術難度過大、沒有足夠的技術積累、沒有熟練的員工可用、沒有足夠的合作企業和外包資源積累等都是技術可行性的約束。實踐證明，如果只考慮技術實現手段而忽視企業當前的資源條件和環境，從而對技術可行性分析得出過於樂觀的結果，將會對後期的專案實施導致災難性後果。對於技術的選擇，有的企業鍾情於新技術，有的則喜歡使用成熟的技術。具體要根據專案的實際情況（例如，開發環境、開發人員的素質、系統的效能要求等）進行決策，但通常的建議是儘可能採用成熟的技術，慎重引入先進技術。IT業界流行的諧語”領先一步是先進，領先兩步是先烈”講的就是對技術的選擇原則。
3.法律可行性法律可行性也稱為社會可行性，具有比較廣泛的內容，它需要從政策、法律、道德、制度等社會因素來論證資訊系統建設的現實性。例如，所開發的系統與國家法律或政策等相牴觸，在政府資訊化的領域中使用了未被認可的加密演算法，未經許可在產品中使用了其他企業的被保護的技術或構件等，這樣的專案在法律可行性上就是行不通的。
4.使用者使用可行性使用者使用可行性也稱為執行可行性，是從資訊系統使用者的角度來評估系統的可行性，包括企業的行政管理和工作制度、使用人員的素質和培訓要求等，可以細分為管理可行性和執行可行性。
（1）管理可行性。管理可行性是指從企業管理上分析系統建設可行性。主管領導不支援的專案一般會失敗，中高層管理人員的牴觸情緒很大，就有必要等一等，先積極做好思想工作，創造條件。另外，還要考慮管理方法是否科學，相應的管理制度改革的時機是否成熟，規章制度是否齊全等。
（2）執行可行性。執行可行性也稱為操作可行性，是指分析和測定資訊系統在確定環境中能夠有效工作，並被使用者方便使用的程度和能力。例如，ERP系統建成後的資料採集和資料質量問題，企業工作人員沒有足夠的IT技能等。這些問題雖然與系統本身無關，但如果不經評估，很可能會導致投入巨資建成的資訊系統卻室無用處。執行可行性還需要評估系統的各種影響，包括對現有IT設施的影響、對使用者組織機構的影響、對現有業務流程的影響、對地點的影響、對經費開支的影響等。如果某項影響會過多改變使用者的現狀，需要將這些因素作進一步的討論並和使用者溝通，提出建議的解決方法。否則，系統一旦建成甚至在建設過程中，就會受到使用者的竭力反對，他們會抵制使用系統。
軟體開發環境
軟體開發環境（Software Development Environment，SDE）是指支援軟體的工程化開發和維護而使用的一組軟體，由軟體工具集和環境整合機制構成。
軟體開發環境應支援多種整合機制，如平臺整合、資料整合、介面整合、控制整合和過程整合等。軟體開發環境應支援小組工作方式，併為其提供配置管理。環境的服務可用於支援各種軟體開發活動，包括分析、設計、程式設計、除錯和文件等。較完善的軟體開發環境通常具有多種功能，如軟體開發的一致性與完整性維護、配置管理及版本控制、資料的多種表示形式及其在不同形式之間的自動轉換、資訊的自動檢索與更新、專案控制和管理，以及對開發方法學的支援。軟體開發環境具有整合性、開放性、可裁減性、資料格式一致性、風格統一的使用者介面等特性，因而能大幅度提高軟體生產率。整合機制根據功能的不同，可劃分為環境資訊庫、過程控制與訊息伺服器、環境使用者介面3個部分。
（1）環境資訊庫：軟體開發環境的核心，用於儲存與系統開發有關的資訊，並支援資訊的交流與共享。其中主要儲存兩類資訊，一類是開發過程中產生的有關被開發系統的資訊，如分析文件、設計文件和測試報告等；另一類是環境提供的支援資訊，如文件模板、系統配置、過程模型和可複用構件等。
（2）過程控制與訊息伺服器：實現過程整合和控制整合的基礎，過程整合是按照具體軟體開發過程的要求進行工具的選擇與組合；控制整合使各工具之間進行並行通訊和協同工作。
（3）環境使用者介面：包括環境總介面和由它實行統一控制的各環境部件及工具的介面。統一併具有一致性的使用者介面是軟體開發環境的重要特徵，是充分發揮環境的優越性、高效地使用工具並減輕使用者的學習負擔的保證。
模組內聚耦合問題
耦合表示模組之間聯絡的程度。緊密耦合表示模組之間聯絡非常強，鬆散耦合表示模組之間聯絡比較弱，非耦合則表示模組之間無任何聯絡，是完全獨立的。模組的耦合型別通常分為7種，根據耦合度從低到高排序如下表所示。
專案管理
範圍管理
範圍計劃編制->範圍定義->建立WBS->範圍確認->範圍控制
範圍管理就是要確定專案的邊界，也就是說，要確定哪些工作是專案應該做的，哪些工作不應該包括在專案中。這個過程用於確保專案干係人對作為專案結果的產品或服務，以及開發這些產品所確定的過程有一個共同的理解。
WBS 工作分解結構（把專案整體或者主要的可交付成果分解成容易管理、方便控制的若干個子專案，子專案需要繼續分解為工作包。
持續這個過程，直到整個專案都分解為可管理的工作包，這些工作包的總和就是專案的所有工作範圍。建立WBS的目的是詳細規定專案的範圍，建立範圍基準。具體來說，其主要目的和用途如下：
①明確和準確說明專案範圍，專案組成員能夠清楚地理解任務的性質和需要努力的方向。
②為各獨立單元分派人員，規定這皆人員的相應職責，可以確定完成專案所需要的技術和人力資源。
③針對各獨立單元，進行時間、費用和資源需求量的估算，提高估算的準確性。
④為計劃、預算、進度安排和費用控制奠定共同基礎，確定專案進度測量和控制的基準。
⑤將專案工作與專案的財務賬目聯絡起來。
⑥清楚地定義專案的邊界，便於劃分和分派責任，自上而下將專案目標落實到具體的工作上，並將這些工作交給專案內外的個人或組織去完成。
⑦確定工作內容和工作順序。可以使用圖形化的方式來檢視工作內容，任何人都能夠清楚地辨別專案的階段、工作單元，並根據實際進展情況進行調節和控制。
③估計專案整體和全過程的費用。
④有助於防止需求蔓延。當用戶或其他專案干係人試圖為專案增加功能時，在WBS中增加相應工作的同時，也就能夠很容易地讓他們理解，相關費用和進度也必須要做相應的改變。
時間管理
.時間管理的過程包括活動定義、活動排序、活動的資源估算、活動歷時估算、制定計劃和進度控制。
前導圖法（單代號網路圖，PDM）
- 結束-開始的關係（F-S型）
- 結束-結束的關係（F-F型）
- 開始-開始的關係（S-S型）
- 開始-結束的關係（S-F型）
關鍵路徑法
關鍵路徑法是在制訂進度計劃時使用的一種進度網路分析技術，
關鍵路線法沿著專案進度網路路線進行正向與反向分析，從而計算出所有計劃活動理論上的最早開始與完成日期、最遲開始與完成日期，不考慮任何資源限制
總時差（鬆弛時間）：在不延誤總工期的前提下，該活動的機動時間。活動的總時差等於該活動最遲完成時間與最早完成時間之差，或該活動最遲開始時間與最早開始時間之差
自由時差：在不影響緊後活動的最早開始時間前提下，該活動的機動時間。
- 對於有緊後活動的活動，其自由時差等於所有緊後活動最早開始時間減本活動最早完成時間所得之差的最小值
- 對於沒有緊後活動的活動，也就是以網路計劃終點節點為完成節點的活動，其自由時差等於計劃工期與本活動最早完成時間之差
對於網路計劃中以終點節點為完成節點的活動，其自由時差與總時差相等。此外，由於活動的自由時差是其總時差的構成部分，所以，當活動的總時差為零時，其自由時差必然為零，可不必進行專門計算
甘特圖
優點：甘特圖直觀、簡單、容易製作，便於理解，能很清晰地標識出直到每一項任務的起始與結束時間，一般適用比較簡單的小型專案，可用於WBS的任何層次、進度控制、資源優化、編制資源和費用計劃。
缺點：不能系統地表達一個專案所包含的各項工作之間的複雜關係，難以進行定量的計算和分析，以及計劃的優化等。
PERT圖
求專案 關鍵路徑，鬆弛時間
關鍵路徑能夠完成整個專案的最長路徑，
鬆弛時間，一個任務能夠空閒，歇息的時間，在不影響總工期的前提下
①最早開始時間（某段工程開始點之前最長的輸入流之和），
②最晚開試（關鍵路徑-開始點到最後整個工程最後結束點的距離），
③最早結束（某段工程結束點之前最長的輸入流之和），
④最晚結束（關鍵路徑-該結束點到整個工程最後結束點的距離）
鬆弛時間=最晚開始-最早開始②-①
鬆弛時間=最晚結束-最早結束④-③
鬆弛時間=關鍵路徑-所求活動在的最長路徑
成本管理
成本估算，成本預算，成本控制
軟體質量管理
軟體配置管理
軟體配置管理（Software Configuration Management，SCM）是指通過執行版本控制、變更控制的規程，以及使用合適的配置管理工具，來保證所有配置項的完整性和可跟蹤性。
軟體配置管理中，每一項配置變更都要在配置狀態報告中進行詳細的記錄。在配置狀態報告中，需要對每一項變更進行詳細的記錄，
包括：發生了什麼？為什麼會發生？誰做的？什麼時候發生的？會有什麼影響？整個配置狀態報告的資訊流如下圖
如上圖所示，每次新分配一個配置項，或者更新一個已有配置項或配置項標識，或者一項變更申請被變更控制負責人批准，
並給出了一個工程變更順序時，在配置狀態報告中就要增加一條變更記錄條目；
一旦進行了配置稽核，其結果也應該寫入報告中。配置狀態報告可以放在一個聯機資料庫中，以便開發人員或者維護人員對它進行查詢或修改。此外，在配置狀態報告中，新記錄的變更應當及時通知給管理人員和其他專案干係人。
主要目標是標識變更，控制變更，確保變更正確地實現，報告有關變更。SCM是一組管理整個軟體生存期各階段中變更的活動。軟體配置管理的內容包括版本控制、變更控制及過程支援