軟件的質量高低取決於其是否符合包括功能性、可靠性、易用性、效率、可維護性、可移植性等在內的六個方面的要求。而要達到這六個方面質量要求，就必須對軟件開發過程中各個環節進行全過程的項目管理，從需求分析、設計、編碼、測試到上線驗收進行控制。根據軟件工程的生命週期，軟件項目可分爲項目立項、啓動、需求分析、系統設計、系統開發、系統測試、系統上線、項目驗收和上線後評估等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. 可移植性: 一個軟件（或軟件的部分功能模塊）能再次用於其他相關聯的應用。