2. 基本要點
由於變更而造成系統內部版本紊亂是軟體品質的大敵。尤其系統人員常常不願意集中管制程式，使得此一工作更加困難。在建構管理上，至少應達到以下要點：
(1) 軟體產品最新版本之管制
(2) 開發中版本與發行版本間之有效鑑別與區隔
(3) 變更需求之管制，確保變更工作是在良好的協調與管理下進行。
(4) 產品發行管理，包含產品發行時機評估，產品變更清單建立，發行對象掌握與管理等要項。
3. 改善方向
大多數的軟體專案事實上一直飽受版本管理問題之苦，若能實施一定程度的建構管理工作，通常會立即感受到好處，尤其越大型的專案越明顯，此時可進一步推動如以下項目之改善事宜： (1) 文件一致性之管制，確保不同文件在變更過程中能即時的同步變更。
(2) 變更評估與管制，實施變更評估與管制作業，對每一變更適當評估其影響範圍及處理方式，再作變更，以避免因變更作業產生的副作用或後遺癥。
(3) 多版本控管，設計機制以保留多版本之建構項目，以因應回溯及變型(Alias)之需求，更有效的支援各種開發及維護作業需求。
(4) "#000099" face="Comic Sans MS">(5) 自動化工具之引進，搭配引進自動化工具，使得建構管理工作能被更有效率的進行。
(四)、 軟體審查與驗證
1. 對應條文
主要對應"7.3.5 設計與開發審查"，"7.3.5 設計與開發驗證"，"7.3.6 設計與開發確認"等條款之需求。
2. 基本要點
開發過程中之審查與複核作業被證明是確保開發品質，降低開發成本之有效措施。在實施上必須明訂每一開發工作項目或階段之審查方式、審查人、及審查時機，賦予審查所需之資源，並確認審查工作之有效進行。
3. 改善方向
軟體同業一般採用之審查方式常是主管審核或同仁查核(Peer Review)，但常常未賦予適當之時間資源，而且此一方法之有效性事實上亦有待加強。因此，當公司日益發展之後，可考慮以下之改善方向： (1) 引進正規之查核方式，如檢視(Formal Inspection)，徒步檢查(Walkthrough)，技術複核(Formal Technique Review)等方式，以加強審查效果。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
