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)等方式,以加強審查效果。
文章来源于领测软件测试网 https://www.ltesting.net/