軟件工程項目開發各階段的質量保證
a、需求分析
需求分析是開發人員對系統需要做什么和如何做的定義過程。從系統分析的經驗來看，這個過程往往是個循序漸進的過程，一次性對系統形成完整的認識是困難的。只有不斷地和客戶領域專家進行交
流確認，方能逐步明了用戶的需求。從系統開發的過程得知，系統分析時犯下的錯誤，會在接下來的階段被成倍的放大，越是在開發的后期，糾正分析時犯下的錯誤所花費的代價越是昂貴，也越發影響系統的工期和系統的質量。
解決系統分析錯誤的方法我們公司通常采用邀請用戶參與進行需求評定，然后對其用戶的意見由質保成員跟蹤檢測是否納入需求規格說明書，同時與用戶簽字確認形成需求基線，交由配置管理員放入配置管理庫。
雖然盡早的邀請用戶參與，仍然避免不了項目進行中用戶的需求變更請求。對于開發過程存在的需求變動，我們要求用戶填寫變更申請單發送給項目配置管理員，在通過配置配置員轉交質保小組，負責組織專家小組和項目組成員一起討論實施變更的可行性及實施后所帶來的影響，小的變更則直接記錄入變更記錄原因分析項和風險項欄，大的變更則需要形成正式的變更報告，無論那種變更都需要對相應的文檔實施同步變更（包括需求規格說明書、詳細設計文、安裝手冊、操作手冊等）。但是對于無法實現或是變更會帶來巨大的影響而將導致進度的延期，這時，我們將變更報告提交給用戶或邀請用戶進行協調會議，討論變更取舍問題或是項目進度變更問題。
決定變更之后，由項目經理組織實施變更，測試人員檢測變更結果，而質保小組成員監督變更實施過程并協助配置管理員對變更后的成果物進行版本控制。變更實施完后，上線前還需要指定人員協助用戶一同測試并由用戶簽字后同意方可上線。
b、系統設計
優良的體系結構應當具備可擴展性和可配置性，而好的體系結構則需要好的設計方法，自然設計選型成為了系統設計首要的工作，究竟是采用哪種設計方法好呢？
對于設計選型不能一概而論，需要針對項目的結構、項目的特征和用戶的需求來分析，同樣也要考慮到參與項目小組成員的素質，如果其中大部分都沒有從事過面向對象的設計且項目進對緊迫，這樣沒有多余的時間來培訓小組成員來掌握面向對象的設計方法，盡管眾所周知面向對象設計方法的優勢，我們還是不如采用面向過程的方式（除用戶指定開發設計方式外）可以減少項目承擔的技術風險。
我們公司有過一個項目，用戶指定需要采用面向對象分析、設計和開發，且開發周期短，在無賴的情況下，項目小組只能選用面向對象的軟件開發過程，由于項目小組很少從事過面向對象的開發，經驗缺乏，導致項目上馬后項目進度延誤，項目沒有達到預期的效果。
針對此次開發，我們分析其原因，發現小組成員在開發過程中對于新技術互相交流少，各自有各自的理解和想法，造成理解上的不一致性，導致工作重復性高，滯后項目進度。建議解決方法是項目組成員采用集中辦公，分塊學習，學習的成果馬上向項目相關人員發布，再由配置管理員對其發布的文檔進行整理、規類放入配置庫以供大家共享。這樣方便大家的互相學習，減少重復的工作。在這次開發中我們公司從管理人員、設計人員到開發人員都汲取了很多教訓，同時經過此次項目的開發，小組成員也積累了豐富的面向對象的開發經驗。
除設計選型，還有一個容易被忽視的問題，就是公共類開發。公共類開發可以減少工作中的重復工作，降低開發成本。這要求我們再設計階段通過對用戶需求的仔細研究，盡可能的識別出公共類，并進行定義指定專人負責設計通知其它設計人員，以減少重復工作。對于項目組提供的設計文檔，由質保小組組織技術專家、項目組設計人員、開發人員和測試人員對其設計文檔的評審，檢測設計文檔對其下一階段工作的可行性，及時發現設計中可能存在的錯誤，降低項目開發風險，同時確保設計文檔能為開發人員、測試人員提供切實的指導。對于可復用的設計進行提取作為公共庫設計和開發，提供項目組或整個公司重用。最后交由配置管理員進行設計文檔的版本控制。
c、實現
實現也就是代碼的生產過程。這里不僅包括代碼的產生，同時也包括測試用例的產生。針對上一階段提供詳細設計，程序員開始編碼并且調試程序，測試人員則根據設計進行測試用例的設計，設計出來的用例需要得到項目組成員認可由項目經理審核通過才能進入配置庫。同時程序員調試完程序提交測試人員進行程序正確性檢測。
d、文檔管理
文檔維護主要是配置管理小組的工作。文檔從用途上分主要分為內部文檔和外部文檔。
內部文檔包括： 項目開發計劃； 需求分析； 體系結構設計說明； 詳細設計說明； 構件索引； 構件成分說明； 構件接口及調用說明； 組件索引； 組件接口及調用說明； 類索引； 類屬性及方法說明； 測試報告； 測試統計報告； 質量監督報告； 源代碼； 文檔分類版本索引； 軟件安裝打包文件。
外部文檔主要包括： 軟件安裝手冊； 軟件操作手冊； 在線幫助； 系統性能指標報告； 系統操作索引。
如何保證文檔的全面性，使其真正為項目的進度提供保證，又不因為文檔的寫作而耽誤項目的進度，這仍然是一個比較難解決的問題。解決此問題，其核心仍然是個"度"的問題。在本項目的開發中，配置管理小組的一個非常重要的任務還是書寫文檔規范和文檔模板。當有文檔模板后需要書寫文檔的人員只剩下"填空"的工作，從某種意義上講，書寫文檔的速度會加快。如果書寫文檔的人員認為文檔的更細致的部分可以由他人幫助完成，則該文檔即交由他人完成，但此時文檔并不算被正式提交，當他人書寫完畢之后，必須由文檔的初寫者進行復審，復審通過后方可以正式提交，進入軟件配置管理的循環中。
配置管理小組真正核心的工作是對文檔的組織管理。根據文檔的不同，文檔的來源也不同，有些是通過質量保證小組經過復審之后轉交給配置管理小組，有些則會直接從文檔的出處到達配置管理小組。文檔的管理是一個非常煩瑣的工作，但是長遠來看它不僅使項目的開發對單個主要人員的依賴減少，從而減少人員流動給項目的帶來的風險，更重要的是在項目進行到后百分之十的時候起到拉動項目的作用。
從以往做大項目的經驗來看，寫作文檔在項目開發的早期可能會使項目的進度比起不寫文檔要稍慢，但隨著項目的進展，各個部門需要配合越來越多，開發者越來越需要知道其他人員的開發思路和開發過程，才能使自己的開發向前推進。一個明顯的例子就是系統整合，或者某些環節是建立在其他環節完成的基礎之上時，就更顯現出文檔交流的準確性和高效性。
3、系統維護質量保證
在我們公司，維護小組的任務一方面是保證對項目客戶的跟蹤服務，另一方面是確保該項目其它的開發人員從項目中盡快的解脫出來以便投入到下一個項目的開發中。所以通常項目維護小組成員主要由項目組的少部分開發人員承擔完成。他們不僅了解軟件的核心內容，而且與客戶也不陌生，以便能夠以最快的速度修正錯誤。對于一般性的錯誤，如操作不當等引起的問題，全部由維護小組執行完成，但需要用戶測試確認上線。如果較大的修改則需要走變更控制流程，用戶或者維護人員填寫變更申請，經專家會議討論分析可行方案在由維護小組實施，通過測試后方可提交用戶。
維護小組的人員基本上是按項目跟進的。當一個項目剛剛交付用戶時，在維護小組有較多的人員進行跟進，隨軟件的穩定，跟進的人逐步減少，并轉移到其它項目中去。
需求分析是開發人員對系統需要做什么和如何做的定義過程。從系統分析的經驗來看，這個過程往往是個循序漸進的過程，一次性對系統形成完整的認識是困難的。只有不斷地和客戶領域專家進行交
流確認，方能逐步明了用戶的需求。從系統開發的過程得知，系統分析時犯下的錯誤，會在接下來的階段被成倍的放大，越是在開發的后期，糾正分析時犯下的錯誤所花費的代價越是昂貴，也越發影響系統的工期和系統的質量。
解決系統分析錯誤的方法我們公司通常采用邀請用戶參與進行需求評定，然后對其用戶的意見由質保成員跟蹤檢測是否納入需求規格說明書，同時與用戶簽字確認形成需求基線，交由配置管理員放入配置管理庫。
雖然盡早的邀請用戶參與，仍然避免不了項目進行中用戶的需求變更請求。對于開發過程存在的需求變動，我們要求用戶填寫變更申請單發送給項目配置管理員，在通過配置配置員轉交質保小組，負責組織專家小組和項目組成員一起討論實施變更的可行性及實施后所帶來的影響，小的變更則直接記錄入變更記錄原因分析項和風險項欄，大的變更則需要形成正式的變更報告，無論那種變更都需要對相應的文檔實施同步變更（包括需求規格說明書、詳細設計文、安裝手冊、操作手冊等）。但是對于無法實現或是變更會帶來巨大的影響而將導致進度的延期，這時，我們將變更報告提交給用戶或邀請用戶進行協調會議，討論變更取舍問題或是項目進度變更問題。
決定變更之后，由項目經理組織實施變更，測試人員檢測變更結果，而質保小組成員監督變更實施過程并協助配置管理員對變更后的成果物進行版本控制。變更實施完后，上線前還需要指定人員協助用戶一同測試并由用戶簽字后同意方可上線。
b、系統設計
優良的體系結構應當具備可擴展性和可配置性，而好的體系結構則需要好的設計方法，自然設計選型成為了系統設計首要的工作，究竟是采用哪種設計方法好呢？
對于設計選型不能一概而論，需要針對項目的結構、項目的特征和用戶的需求來分析，同樣也要考慮到參與項目小組成員的素質，如果其中大部分都沒有從事過面向對象的設計且項目進對緊迫，這樣沒有多余的時間來培訓小組成員來掌握面向對象的設計方法，盡管眾所周知面向對象設計方法的優勢，我們還是不如采用面向過程的方式（除用戶指定開發設計方式外）可以減少項目承擔的技術風險。
我們公司有過一個項目，用戶指定需要采用面向對象分析、設計和開發，且開發周期短，在無賴的情況下，項目小組只能選用面向對象的軟件開發過程，由于項目小組很少從事過面向對象的開發，經驗缺乏，導致項目上馬后項目進度延誤，項目沒有達到預期的效果。
針對此次開發，我們分析其原因，發現小組成員在開發過程中對于新技術互相交流少，各自有各自的理解和想法，造成理解上的不一致性，導致工作重復性高，滯后項目進度。建議解決方法是項目組成員采用集中辦公，分塊學習，學習的成果馬上向項目相關人員發布，再由配置管理員對其發布的文檔進行整理、規類放入配置庫以供大家共享。這樣方便大家的互相學習，減少重復的工作。在這次開發中我們公司從管理人員、設計人員到開發人員都汲取了很多教訓，同時經過此次項目的開發，小組成員也積累了豐富的面向對象的開發經驗。
除設計選型，還有一個容易被忽視的問題，就是公共類開發。公共類開發可以減少工作中的重復工作，降低開發成本。這要求我們再設計階段通過對用戶需求的仔細研究，盡可能的識別出公共類，并進行定義指定專人負責設計通知其它設計人員，以減少重復工作。對于項目組提供的設計文檔，由質保小組組織技術專家、項目組設計人員、開發人員和測試人員對其設計文檔的評審，檢測設計文檔對其下一階段工作的可行性，及時發現設計中可能存在的錯誤，降低項目開發風險，同時確保設計文檔能為開發人員、測試人員提供切實的指導。對于可復用的設計進行提取作為公共庫設計和開發，提供項目組或整個公司重用。最后交由配置管理員進行設計文檔的版本控制。
c、實現
實現也就是代碼的生產過程。這里不僅包括代碼的產生，同時也包括測試用例的產生。針對上一階段提供詳細設計，程序員開始編碼并且調試程序，測試人員則根據設計進行測試用例的設計，設計出來的用例需要得到項目組成員認可由項目經理審核通過才能進入配置庫。同時程序員調試完程序提交測試人員進行程序正確性檢測。
d、文檔管理
文檔維護主要是配置管理小組的工作。文檔從用途上分主要分為內部文檔和外部文檔。
內部文檔包括： 項目開發計劃； 需求分析； 體系結構設計說明； 詳細設計說明； 構件索引； 構件成分說明； 構件接口及調用說明； 組件索引； 組件接口及調用說明； 類索引； 類屬性及方法說明； 測試報告； 測試統計報告； 質量監督報告； 源代碼； 文檔分類版本索引； 軟件安裝打包文件。
外部文檔主要包括： 軟件安裝手冊； 軟件操作手冊； 在線幫助； 系統性能指標報告； 系統操作索引。
如何保證文檔的全面性，使其真正為項目的進度提供保證，又不因為文檔的寫作而耽誤項目的進度，這仍然是一個比較難解決的問題。解決此問題，其核心仍然是個"度"的問題。在本項目的開發中，配置管理小組的一個非常重要的任務還是書寫文檔規范和文檔模板。當有文檔模板后需要書寫文檔的人員只剩下"填空"的工作，從某種意義上講，書寫文檔的速度會加快。如果書寫文檔的人員認為文檔的更細致的部分可以由他人幫助完成，則該文檔即交由他人完成，但此時文檔并不算被正式提交，當他人書寫完畢之后，必須由文檔的初寫者進行復審，復審通過后方可以正式提交，進入軟件配置管理的循環中。
配置管理小組真正核心的工作是對文檔的組織管理。根據文檔的不同，文檔的來源也不同，有些是通過質量保證小組經過復審之后轉交給配置管理小組，有些則會直接從文檔的出處到達配置管理小組。文檔的管理是一個非常煩瑣的工作，但是長遠來看它不僅使項目的開發對單個主要人員的依賴減少，從而減少人員流動給項目的帶來的風險，更重要的是在項目進行到后百分之十的時候起到拉動項目的作用。
從以往做大項目的經驗來看，寫作文檔在項目開發的早期可能會使項目的進度比起不寫文檔要稍慢，但隨著項目的進展，各個部門需要配合越來越多，開發者越來越需要知道其他人員的開發思路和開發過程，才能使自己的開發向前推進。一個明顯的例子就是系統整合，或者某些環節是建立在其他環節完成的基礎之上時，就更顯現出文檔交流的準確性和高效性。
3、系統維護質量保證
在我們公司，維護小組的任務一方面是保證對項目客戶的跟蹤服務，另一方面是確保該項目其它的開發人員從項目中盡快的解脫出來以便投入到下一個項目的開發中。所以通常項目維護小組成員主要由項目組的少部分開發人員承擔完成。他們不僅了解軟件的核心內容，而且與客戶也不陌生，以便能夠以最快的速度修正錯誤。對于一般性的錯誤，如操作不當等引起的問題，全部由維護小組執行完成，但需要用戶測試確認上線。如果較大的修改則需要走變更控制流程，用戶或者維護人員填寫變更申請，經專家會議討論分析可行方案在由維護小組實施，通過測試后方可提交用戶。
維護小組的人員基本上是按項目跟進的。當一個項目剛剛交付用戶時，在維護小組有較多的人員進行跟進，隨軟件的穩定，跟進的人逐步減少，并轉移到其它項目中去。
本文標簽：軟件工程項目開發各階段的質量保證
* 由于無法獲得聯系方式等原因，本網使用的文字及圖片的作品報酬未能及時支付，在此深表歉意，請《軟件工程項目開發各階段的質量保證》相關權利人與機電之家網取得聯系。
：鞏經理
：13915946763
：南京塞姆泵業有限公司
