專案管理: 軟體質量的可靠保證（轉）

中國石油新疆油田公司科技資訊處軟體工程師，連續多年參與編制新疆油田公司資訊化建設專案計劃。
）
對軟體開發的各個階段進行管理，增強對軟體開發的控制能力，提高軟體開發質量，這是軟體專案管理的根本目的。

軟體的質量高低取決於其是否符合包括功能性、可靠性、易用性、效率、可維護性、可移植性等
在內的六個方面的要求。而要達到這六個方面質量要求，就必須對軟體開發過程中各個環節進行全過程的專案管理，從需求分析、設計、編碼、測試到上線驗收進行控制。根據軟體工程的生命週期，軟體專案可分為專案立項、啟動、需求分析、系統設計、系統開發、系統測試、系統上線、專案驗收和上線後評估等9個階段進行。加強軟體專案管理，就是以軟體工程的各個環節為管理主線，將動態專案管理貫穿其中，透過對軟體開發的專案範圍、專案進度、專案質量、專案溝通、人力資源、專案成本六大核心要素的整合管理，實現軟體開發管理效能的最大化，從而大大提高軟體的開發質量。

準確把握軟體需求

軟體開發專案的提出，應由迫切的業務需求來驅動。很多不成功的軟體專案，往往是由資訊科技部門提出，按照技術人員的思路主導開發，並理所當然地被認為能夠在業務部門取得良好的應用效果。這樣的專案由於得不到業務部門的理解和支援，脫離業務需求，多數面臨失敗或半途而廢的命運。因此軟體專案業務需求的迫切性、技術實現的成熟性、經濟效益的可行性等方面的因素，都是考慮的要素，將對專案的成敗產生直接影響。

正確的做法應該是，由軟體的需求單位根據自身業務需要，向資訊科技管理部門提出軟體專案的立項建議，對立項的目的、業務需求範圍、技術經濟指標、開發週期要求等方面做簡要概述，再由資訊科技管理部門組織業務專家和資訊科技專家組成聯合專家組，進行專案立項的可行性論證。透過專家組論證稽核後，專案提出單位需要進行開題設計，進一步明確軟體開發範圍、技術路線、進度安排、經費預算、研究人員組成、合作隊伍，並以此為基礎編制完成開題設計書。資訊科技管理部門組織專家組對開題設計進行論證，只有業務需求合理、技術路線可行、開發隊伍落實的專案，才能透過專家組稽核，進入專案啟動階段。

軟體開發過程的監督和管理

軟體開發專案具有建設範圍難界定、技術含量高、人員流動快、協作性強、開發成功率低等特點。目前國內對軟體專案的監理制度尚不規範，對軟體開發仍然缺乏有效控制。因此由企業的資訊科技管理部門設立軟體監督崗位，加強對軟體專案的開發過程管理，就顯得非常必要。

軟體監督的主要職責是在專案的進行過程中，協調業務需求部門和軟體開發方的關係，監控軟體開發任務的執行情況，給開發人員和管理層提供反映軟體過程質量的資訊和資料，提高專案透明度，從而保證專案按照計劃實施，實現預期目標。軟體監督應具備以下三方面的基本素質:

● 具有較強的工作責任感和良好的溝通能力;

● 熟悉業務管理流程，掌握軟體開發流程、開發規範以及相關標準;

● 具有軟體開發專案的建設和管理經驗，掌握專案管理知識;

軟體監督的工作任務主要有:

● 確保軟體按照業務需求方確認的範圍進行開發。

● 保證軟體開發進度符合雙方確認的計劃指標。

● 保證軟體開發過程中存在的不符合要求的問題能夠及時得到溝通和處理，必要時需要將問題反映給管理層。

● 確保專案組中軟體開發人員隊伍相對穩定。

● 保證軟體開發過程和開發出來的軟體符合相應標準和規範。

● 收集軟體開發過程中的成功經驗，為企業提供軟體開發過程的有效控制方法和規範。

1.監督管理的範圍

《需求分析說明書》是對軟體開發範圍的書面表達依據。由於《需求分析說明書》往往是採用軟體設計的術語編寫，因此常常令計算機背景知識較少的業務需求方難以理解，也就很難發現需求報告中與實際需求不符之處，更難提出建設性的意見。

軟體監督要對軟體開發範圍進行管理，首先要確定雙方都能認可的《需求分析說明書》。如要求軟體開發方對《需求分析說明書》做出進一步更詳細的解釋，編制業務模型，以便使用者方準確地理解《需求分析說明書》的內容，能及早地發現需求與實際的偏差。這也是對需求分析工作的總結與確認。

在專案需求分析階段，雙方必須全面地、儘可能細緻地討論專案的應用背景、功能要求、效能要求、操作介面要求、與其他軟體的介面要求，以及對專案進行評估的各種評價標準。

《需求分析說明書》完成後，軟體監督應組織專案組與業務需求方共同討論，聽取業務需求方的意見和建議，並進行相應的修改完善。各方確認《需求分析說明書》內容後，需在說明書上簽字確認。

在軟體開發過程中，雙方應嚴格按照簽字確認的《需求分析說明書》中規定的業務範圍進行開發。有些需求可能在專案初期很難確定，在開發過程中需要不斷地加以修正，專案軟體監督要及時與使用者充分溝通，建立可以直接聯絡的渠道，共同進行需求確認，保證專案範圍可控。

2.進度管理

為確保專案按時、按量、保質完成，必須控制任務和跟蹤里程碑。按照軟體專案的開發規律，將軟體開發過程分為幾個重要階段，對這幾個階段的關鍵事件設立里程碑進行跟蹤管理。專案進度管理可以透過以下方式完成:

● 制定專案里程碑管理執行表（里程碑管理表的主要內容見表1）。
表 專案里程碑管理執行表(點選小圖看大圖)


● 定期舉行專案狀態會議，由軟體開發方報告進度和問題，使用者方提出意見。

● 比較各項任務的實際開始日期與計劃開始日期是否吻合。

● 確定正式的專案里程碑是否在預期完成。

從軟體專案實施的過程來看，很少有一個專案是完全按照實施計劃來進行的，因為再好的計劃也不能完全預見所有的問題，並事先制訂出對策。計劃可以調整，但是調整必須合理，並得到業務需求方和管理層的批准。當有問題發生時，其直接的表現就是實施結果偏離了原來的計劃和目標，在這種情況下，軟體監督就要及時發現這種偏離，並分析這種原因，如果是因為原來的計劃和目標制訂的不合理，或者發生了預料之外的情況而又無法克服，這樣就必須調整計劃和目標。

3.溝通管理

資訊系統本身就是溝通的產物。軟體開發過程實際上就是將手工作業轉化成計算機程式的過程。軟體開發的原料和產品就是資訊，中間過程傳遞的也是資訊，而資訊的產生、收集、傳播、儲存正是溝通管理的內容。可見溝通不僅僅是軟體專案管理的必要手段，更重要的，溝通是軟體生產的手段和生產過程中必不可少的工序。

軟體開發的柔性標準需要溝通來彌補。軟體開發不像加工螺釘、螺母，有具體的標準和檢驗方法。軟體的標準柔性很大，比如在使用者的心裡好用是軟體成功的標準，而這個標準在軟體開發前很難確切地、完整地表達出來。因此，開發過程專案組和使用者的溝通互動是解決這一現實問題的惟一辦法。

軟體監督要有效地安排開發方軟體人員與需求方使用人員的交流，保證有暢通的交流渠道。制定完善的專案彙報制度，明確溝通時間、頻率和渠道。按照專案彙報制度定期組織專案組向業務需求方和管理層彙報，包括專案進度計劃、已完成工作、與計劃的比較、存在的問題、措施和建議以及下一步工作計劃等。

4.軟體版本管理

目前的軟體開發是團隊開發的時代，軟體開發技術更新迅速，開發人員流動頻繁，因此對軟體版本的管理就顯得尤其重要。在軟體開發的過程中，在多人共同開發一個軟體時，會出現多人同時修改軟體的情況，這是不可避免的，由於部分功能模組版本可能要進行不斷地升級完善，而老的軟體版本又沒有即使更新，隨著時間的推移，開發人員對自己機器上的不同版本間的差異就會模糊不清。另外由於軟體開發工期的壓力，開發人員只將注意力集中在設計和編碼上，未將文件納入到版本控制中。為了解決這些問題，軟體監督就要注意跟蹤記錄整個軟體的開發過程，包括軟體本身及其相關文件，重視程式碼的一致性。這一工作可以透過應用軟體版本管理的工具軟體實現，如Microsoft公司的Visual SourceSafe等對原始碼和整個專案進行管理，從而建立正常的軟體版本管理機制，

把握正確的驗收方法

軟體專案驗收是對軟體專案成果的檢驗和確認，也是對軟體專案範圍的再確認。軟體驗收應是一個過程的概念，包括驗收前的系統測試、資料移植、系統上線和正式驗收四個階段。

1.系統測試

系統測試是對系統進行全面的測試，應在測試環境中進行，以確保系統的功能和技術設計滿足企業的業務需求，並能正常執行。系統測試階段應包括以下主要流程和工作內容:

（1）制訂測試計劃，包括編制測試用例，建立測試環境。

（2）測試。在測試環境中，專案組根據需要，對系統依次進行單元測試、整合測試、壓力測試和使用者接受測試，記錄測試結果並由相關測試人簽字確認，編制相應的測試報告。對於未透過測試的內容，專案組應查詢失敗的原因，並修改相應程式或設定，重新進行測試。除了進行充分的系統功能測試，測試應包含與內部控制相關的測試內容，如系統認證和授權、交易完整性及資料真實、完整性的有關功能。

（3）提交測試報告、使用者確認簽字。專案組撰寫測試報告，將測試報告提交給各相關使用者，使用者應在測試報告上簽字確認。

2.資料移植

新系統上線時如需要將原始資料移植到新系統，則應完成以下主要工作內容:

（1）制訂資料移植/轉換計劃。除了要定義資料收集的格式、範圍、進度外，還要考慮系統介面的影響，並建立了資料移植完整性和準確性測試方法以及意外事件處理程式。

（2）資料收集。如果專案實施涉及到資料收集，應由資料收集小組根據資料收集格式，對資料進行收集，資料收集小組在收集資料時應培訓業務部門的資料提供人員，以確保資料提供人員瞭解和掌握對資料收集的各項規定和要求。

（3）資料移植前的測試。在測試環境中對資料移植方法進行測試，書面記錄測試結果，解決測試中發現的問題，進行問題記錄並歸檔。

（4）資料匯入並核查結果。

專案組成員將資料匯入系統，並在匯入後按照事先制定的資料移植完整性和準確性測試方法對系統中的資料做進一步的核查，確保匯入資料的質量。如有意外，按照事先制定的意外事件處理程式處理，並留下記錄。資料移植完成之後，使用者應對資料移植結果簽字確認。

（5） 資料移植後要進行適當時間的試執行，確認資料移植的真實性和完整性。試執行時間視具體系統的規模、影響程度而定。對影響較大的系統，至少應試執行三個完整的月結週期。

3.系統上線

系統上線階段應包括以下的主要流程和工作內容:

（1） 上線前準備工作。在上線前，軟體開發方應制定系統上線計劃，包括上線檢查清單、上線支援人員、退回機制等，並提交《上線申請表》。系統上線計劃和《上線申請表》應經過資訊科技部門和業務部門管理層的正式批准，並通知各相關部門。

（2）系統上線。所有的上線準備工作做好之後，由軟體監督人員確認上線系統版本正確性後，與使用者確認系統上線時間，下達上線指令。系統上線操作人員將最後版本的系統程式移植到生產環境。
4.正式驗收

正式驗收前，軟體開發方應向資訊科技管理部門提交軟體開發過程中各階段性文件，包括需求分析說明書、概要設計說明書、詳細設計說明書、資料庫設計說明書、源程式程式碼、可供安裝使用的系統安裝程式、系統管理員手冊、使用者使用手冊、測試計劃、測試報告、使用者報告、資料移植計劃及報告、系統上線計劃及報告、使用者意見書、驗收申請等。

資訊科技管理部門接到驗收申請後，組織專家對專案進行初審。初審透過後，組織管理層領導、業務管理人員和資訊科技專家成立專案驗收委員會，負責對軟體專案進行正式驗收。

軟體監督應根據軟體開發方在整個軟體開發過程中的表現，向驗收委員會提出全面的軟體監督報告，並根據開題設計書、軟體開發合同以及《需求分析說明書》，制定驗收標準，提交驗收委員會。資訊科技管理部門組織由驗收委員會、軟體監督、軟體開發方參加的專案驗收會，軟體開發方以專案彙報、現場應用演示等方式彙報專案完成情況，驗收委員會根據驗收標準對專案進行評審，形成最終驗收意見。

連結:軟體質量的六個考核要素

1. 功能性: 滿足使用者的要求，在預定環境下能夠完成預期的功能。

2. 易用性: 使用者容易理解和使用功能，操作方便，符合使用者業務習慣。

3. 可靠性: 軟體按照設計要求，在規定時間和條件下不出故障，具有異常捕獲功能並提供異常處理與恢復功能。

4. 效率: 降低系統資源的開銷，響應時間快，提高使用者工作效率。

5. 可維護性: 遵從統一的標準和規範，編碼具有良好的可讀性。為滿足使用者新的要求，或當環境發生了變化，或執行中發現了新的錯誤時，能夠對一個已投入執行的軟體進行相應診斷和修改。

6. 可移植性: 一個軟體（或軟體的部分功能模組）能再次用於其他相關聯的應用。[@more@]