關鍵字：軟件 質量管理
2、項目開發各階段的質量保證
a、需求分析
需求分析是開發人員對系統需要做什么和如何做的定義過程。從系統分析的經驗來看，這個過程往往是個循序漸進的過程，一次性對系統形成完整的認識是困難的。只有不斷地和客戶領域專家進行交流確認，方能逐步明了用戶的需求。從系統開發的過程得知，系統分析時犯下的錯誤，會在接下來的階段被成倍的放大，越是在開發的后期，糾正分析時犯下的錯誤所花費的代價越是昂貴，也越發影響系統的工期和系統的質量。
解決系統分析錯誤的方法我們公司通常采用邀請用戶參與進行需求評定，然后對其用戶的意見由質保成員跟蹤檢測是否納入需求規格說明書，同時與用戶簽字確認形成需求基線，交由配置管理員放入配置管理庫。
雖然盡早的邀請用戶參與，仍然避免不了項目進行中用戶的需求變更請求。對于開發過程存在的需求變動，我們要求用戶填寫變更申請單發送給項目配置管理員，在通過配置配置員轉交質保小組，負責組織專家小組和項目組成員一起討論實施變更的可行性及實施后所帶來的影響，小的變更則直接記錄入變更記錄原因分析項和風險項欄，大的變更則需要形成正式的變更報告，無論那種變更都需要對相應的文檔實施同步變更(包括需求規格說明書、詳細設計文、安裝手冊、操作手冊等)。但是對于無法實現或是變更會帶來巨大的影響而將導致進度的延期，這時，我們將變更報告提交給用戶或邀請用戶進行協調會議，討論變更取舍問題或是項目進度變更問題。
決定變更之后，由項目經理組織實施變更，測試人員檢測變更結果，而質保小組成員監督變更實施過程并協助配置管理員對變更后的成果物進行版本控制。變更實施完后，上線前還需要指定人員協助用戶一同測試并由用戶簽字后同意方可上線。
b、系統設計
優良的體系結構應當具備可擴展性和可配置性，而好的體系結構則需要好的設計方法，自然設計選型成為了系統設計首要的工作，究竟是采用哪種設計方法好呢?
對于設計選型不能一概而論，需要針對項目的結構、項目的特征和用戶的需求來分析，同樣也要考慮到參與項目小組成員的素質，如果其中大部分都沒有從事過面向對象的設計且項目進對緊迫，這樣沒有多余的時間來培訓小組成員來掌握面向對象的設計方法，盡管眾所周知面向對象設計方法的優勢，我們還是不如采用面向過程的方式(除用戶指定開發設計方式外)可以減少項目承擔的技術風險。
我們公司有過一個項目，用戶指定需要采用面向對象分析、設計和開發，且開發周期短，在無賴的情況下，項目小組只能選用面向對象的軟件開發過程，由于項目小組很少從事過面向對象的開發，經驗缺乏，導致項目上馬后項目進度延誤，項目沒有達到預期的效果。
針對此次開發，我們分析其原因，發現小組成員在開發過程中對于新技術互相交流少，各自有各自的理解和想法，造成理解上的不一致性，導致工作重復性高，滯后項目進度。建議解決方法是項目組成員采用集中辦公，分塊學習，學習的成果馬上向項目相關人員發布，再由配置管理員對其發布的文檔進行整理、規類放入配置庫以供大家共享。這樣方便大家的互相學習，減少重復的工作。在這次開發中我們公司從管理人員、設計人員到開發人員都汲取了很多教訓，同時經過此次項目的開發，小組成員也積累了豐富的面向對象的開發經驗。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/