一、引言
隨着信息技術的飛速發展，軟件產品的規模也越來越龐大，個人單打獨鬥的作坊式開發方式已經越來越不適應發展的需要。各軟件企業都在積極將軟件項目管理引入開發活動中，對開發實行有效的管理。我公司是西安一家中型軟件企業，在公司中已經實行了項目管理制度，軟件項目管理是整個項目管理中的一個重要組成部分。
從概念上講，軟件項目管理是爲了使軟件項目能夠按照預定的成本、進度、質量順利完成，而對成本、人員、進度、質量、風險等進行分析和管理的活動。實際上，軟件項目管理的意義不僅僅如此，進行軟件項目管理有利於將開發人員的個人開發能力轉化成企業的開發能力，企業的軟件開發能力越高，表明這個企業的軟件生產越趨向於成熟，企業越能夠穩定發展（即減小開發風險）。
軟件開發不同於其他產品的製造，軟件的整個過程都是設計過程（沒有製造過程）；另外，軟件開發不需要使用大量的物質資源，而主要是人力資源；並且，軟件開發的產品只是程序代碼和技術文件，並沒有其他的物質結果。基於上述特點，軟件項目管理與其他項目管理相比，有很大的獨特性。
二、軟件項目管理的組織模式
軟件項目可以是一個單獨的開發項目，也可以與產品項目組成一個完整的軟件產品項目。如果是訂單開發，則成立軟件項目組即可；如果是產品開發，需成立軟件項目組和產品項目（負責市場調研和銷售），組成軟件產品項目組。
公司實行項目管理時，首先要成立項目管理委員會，項目管理委員會下設項目管理小組、項目評審小組和軟件產品項目組。
1、項目管理委員會
項目管理委員會是公司項目管理的最高決策機構，一般由公司總經理、副總經理組成。主要職責如下：
（1）依照項目管理相關制度，管理項目；
（2）監督項目管理相關制度的執行；
（3）對項目立項、項目撤消進行決策；
（4）任命項目管理小組組長、項目評審委員會主任、項目組組長.
2、項目管理小組
項目管理小組對項目管理委員會負責，一般由公司管理人員組成。主要職責如下：
（1）草擬項目管理的各項制度；
（2）組織項目階段評審；
（3）保存項目過程中的相關文件和數據；
（4）爲優化項目管理提出建議。
3、項目評審小組
項目評審小組對項目管理委員會負責，可下設開發評審小組和產品評審小組，一般由公司技術專家和市場專家組成。主要職責如下：
（1）對項目可行性報告進行評審；
（2）對市場計劃和階段報告進行評審；
（3）對開發計劃和階段報告進行評審；
（4）項目結束時，對項目總結報告進行評審。
4、軟件產品項目組
軟件產品項目組對項目管理委員會負責，可下設軟件項目組和產品項目組。軟件項目組和產品項目組分別設開發經理和產品經理。成員一般由公司技術人員和市場人員構成。主要職責是：根據項目管理委員會的安排具體負責項目的軟件開發和市場調研及銷售工作。
三、軟件項目管理的內容
從軟件工程的角度講，軟件開發主要分爲六個階段：需求分析階段、概要設計階段、詳細設計階段、編碼階段、測試階段、安裝及維護階段。不論是作坊式開發，還是團隊協作開發，這六個階段都是不可缺少的。
根據公司實際情況，公司在進行軟件項目管理時，重點將軟件配置管理、軟件質量管理、軟件風險管理及開發人員管理四方面內容導入軟件開發的整個階段。
在八十年代初，著名軟件工程專家B.W.Boehm總結出了軟件開發時需遵循的七條基本原則，同樣，我們在進行軟件項目管理時，也應該遵循這七條原則。它們是：
（1）用分階段的生命週期計劃嚴格管理；
（2）堅持進行階段評審；
（3）實行嚴格的產品控制；
（4）採用現代程序設計技術；
（5）結果應能夠清楚地審查；
（6）開發小組地人員應該少而精；
（7）承認不斷改進軟件工程實踐地必要性。
四、編寫《軟件項目計劃書》
項目組成立的第一件事是編寫《軟件項目計劃書》，在計劃書中描述開發日程安排、資源需求、項目管理等各項情況的大體內容。計劃書主要向公司各相關人員發放，使他們大體瞭解該軟件項目的情況。對於計劃書的每個內容，都應有相應具體實施手冊，這些手冊是供項目組相關成員使用的。
《軟件項目計劃書》一般應該包括下述內容：
1.引言
1.1計劃的目的
1.2項目的範圍和目標
1.2.1範圍描述
1.2.2主要功能
1.2.3性能
1.2.4管理和技術約束
2.項目估算
2.1使用的歷史數據
2.2使用的評估技術
2.3工作量、成本、時間估算
3.風險管理戰略
3.1風險識別
3.2有關風險的討論
3.3風險管理計劃
3.3.1風險計劃
3.3.2風險監視
3.3.3風險管理
4.日程
4.1項目工作分解結構
4.2時限圖(甘特圖)
4.3資源表
5.項目資源
5.1人員
5.2硬件和軟件
5.3特別資源
6.人員組織
6.1組織結構
6.2管理報告
7.跟蹤和控制機制
7.1質量保證和控制
7.2變化管理和控制
8.附錄
五、軟件配置管理
是否進行配置管理與軟件的規模有關，軟件的規模越大，配置管理就顯得越重要。軟件配置管理簡稱SCM（Software Configuration Management的縮寫），是在團隊開發中，標識、控制和管理軟件變更的一種管理。配置管理的使用取決於項目規模和複雜性以及風險水平。
1、目前軟件開發中面臨的問題
。在有限的時間、資金內，要滿足不斷增長的軟件產品質量要求；
。開發的環境日益複雜，代碼共享日益困難，需跨越的平臺增多；
。程序的規模越來越大；
。軟件的重用性需要提高；
。軟件的維護越來越困難。
2、軟件配置管理應提供的功能
在ISO9000.3中，對配置管理系統的功能作了如下描述：
。唯一地標識每個軟件項的版本；
。標識共同構成一完整產品的特定版本的每一軟件項的版本；
。控制由兩個或多個獨立工作的人員同時對一給定軟件項的更新；
。控制由兩個或多個獨立工作的人員同時對一給定軟件項的更新；
。按要求在一個或多個位置對複雜產品的更新進行協調；
。標識並跟蹤所有的措施和更改；這些措施和更改是在從開始直到放行期間，由於更改請求或問題引起的。
3、版本管理
軟件配置管理分爲版本管理、問題跟蹤和建立管理三個部分，其中版本管理是基礎。版本管理應完成以下主要任務：
。建立項目；
。重構任何修訂版的某一項或某一文件；
。利用加鎖技術防止覆蓋；
。當增加一個修訂版時要求輸入變更描述；
。提供比較任意兩個修訂版的使用工具；
。採用增量存儲方式；
。提供對修訂版歷史和鎖定狀態的報告功能；
。提供歸併功能；
。允許在任何時候重構任何版本；
。權限的設置；
。晉升模型的建立；
。提供各種報告。
4、配置管理軟件PVCS 6.0
PVCS6.0是一套非常優秀的配置管理軟件，它能夠實現配置管理中的各項要求，並且能和多種流行開發平臺集成，爲配置管理提供了很大的方便。
六、軟件質量管理
隨着軟件開發的規模越來越大，軟件的質量問題顯得越來越突出。軟件質量的控制不單單是一個軟件測試問題，在軟件開發的所有階段都應該引入質量管理。我公司除加強了國家標準"信息技術軟件生存期過程"（GB/T8566--1995）的規範管理外，還積極爲通過ISO 9000.3做準備。
1、軟件質量保證計劃
在進行軟件開發前，需要有一個《軟件質量保證計劃》。目前較常用的是ANSI/IEEE STOL
730--1984，983--1986標準，包括以下內容：
1.計劃目的
2.參考文獻
3.管理
3.1.組織
3.2.任務
3.3.責任
4.文檔
4.1.目的
4.2.要求的軟件工程文檔
4.3.其他文檔
5.標準和約定
5.1.目的
5.2.約定
6.評審和審計
6.1.目的
6.2.評審要求
6.2.1.軟件需求的評審
6.2.2.設計評審
6.2.3.軟件驗證和確認評審
6.2.4.功能評審
6.2.5.物理評審
6.2.6.內部過程評審
6.2.7.管理評審
7.測試
8.問題報告和改正活動
9.工具、技術和方法
10.媒體控制
11.供應者控制
12.記錄、收集、維護和保密
13.培訓
14.風險管理
2、質量管理的基本原則
。控制所有過程的質量；
。過程控制的出發點是預防不合格；
。質量管理的中心任務是建立並實施文件化的質量體系；
。持續的質量改進；
。有效的質量體系應滿足顧客和組織內部雙方的需要和利益；
。定期評價質量體系；
。搞好質量管理關鍵在於領導。
3、軟件質量因素
正確性：系統滿足規格說明和用戶目標的程度，即，在預定環境下能正確地完成預期功能的程度。
健壯性：在硬件發生故障、輸入的數據無效或操作錯誤等意外環
境下，系統能做出適當響應的程度。
效率：爲了完成預定的功能，系統需要的計算資源的多少。
完整性（安全性）：對未經授權的人使用軟件或數據的企圖，系統能過控制（禁止）的程度。
可用性：系統在完成預定應該完成的功能時另人滿意的程度。
風險：按預定的成本和進度把系統開發出來，並且爲用戶所滿意的概率。
可理解性：理解和使用該系統的容易程度。
可維修性：診斷和改正在運行現場發現的錯誤所需要的工作量的大小。
靈活性（適應性）：修改或改進正在運行的系統需要的工作量的多少。
可測試性：軟件容易測試的程度。
可移植性：把程序從一種硬件配置和（或）軟件系統環境轉移到另一種配置和環境時，需要的工作量多少。有一種定量度量的方法是：用原來程序設計和調試的成本除移植時需用的費用。
可再用性：再其他應用中該程序可以被再次使用的程度（或範圍）。
互運行性：把該系統和另一個系統結合起來需要的工作量的多少。
4、軟件評審
軟件評審並不是在軟件開發完畢後進行評審，而是在軟件開發的各個階段都要進行評審。因爲在軟件開發的各個階段都可能產生錯誤，如果這些錯誤不及時發現並糾正，會不斷地擴大，最後可能導致開
發的失敗。下面這組數據可以清楚的看出前期的錯誤對後期的影響。
軟件評審是相當重要的工作，也是目前國內開發最不重視的工作。
（1）評審目標
。發現任何形式表現的軟件功能、邏輯或實現方面的錯誤；
。通過評審驗證軟件的需求；
。保證軟件按預先定義的標準表示；
。已獲得的軟件是以統一的方式開發的；
。使項目更容易管理。
（2）評審過程
A、召開評審會議：一般應有3至5人蔘加，會前每個參加者做好準備，評審會每次一般不超過2小時。
B、會議結束使必須做出以下決策之一：接受該產品，不需做修改；由於錯誤嚴重，拒絕接受；暫時接受該產品。
C、評審報告與記錄；所提出的問題都要進行記錄，在評審會結束前產生一個評審問題表，另外必須完成評審簡要報告。
（3）評審準則
。評審產品，而不是評審設計者（不能使設計者有任何壓力）；
。會場要有良好的氣氛；
。建立議事日程並維持它（會議不能脫離主題）；
。限制爭論與反駁（評審會不是爲了解決問題，而是爲了發現問題；
。指明問題範圍，而不是解決提到的問題；
。展示記錄（最好有黑板，將問題隨時寫在黑板上）；
。限制會議人數和堅持會前準備工作；
。對每個被評審的產品要盡力評審清單（幫助評審人員思考）；
。對每個正式技術評審分配資源和時間進度表；
。對全部評審人員進行必要的培訓；
。及早地對自己地評審做評審（對評審準則的評審）。
5、ISO9000.3軟件質量認證體系
ISO9000.3是ISO9000質量體系認證中關於計算機軟件質量管理和質量保證標準部分。它從管理職責、質量體系、合同評審、設計控制、文件和資料控制、採購、顧客提供產品的控制、產品標識和可追溯性、過程控制、檢驗和試驗、檢驗/測量和試驗設備的控制、檢驗和試驗狀態、不合格品的控制、糾正和預防措施、搬運/貯存/包裝/防護和交付、質量記錄的控制、內部質量審覈、培訓、服務、統計系統等二個方面對軟件質量進行了要求。
6、測試
軟件測試是軟件開發的一個重要環節，同時也是軟件質量保證的一個重要環節。所謂測試就是用已知的輸入在已知環境中動態地執行系統（或系統的部件）。測試一般包括單元測試、模塊測試、集成測試和系統測試。如果測試結果與預期結果不一致，則很可能是發現了系統中的錯誤，測試過程中將產生下述基本文檔：
（1）測試計劃：確定測試範圍、方法、和需要的資源等。
（2）測試過程：詳細描述和每個測試方案有關的測試步驟和數據（包括測試數據及預期的結果）。
（3）測試結果：把每次測試運行的結果歸入文檔，如果運行出錯，則應產生問題報告，並且必須經過調試解決所發現的問題。測試結果：把每次測試運行的結果歸入文檔，如果運行出錯，則應產生問題報告，並且必須經過調試解決所發現的問題。
七、軟件風險管理
軟件項目管理存在着風險，如果我們提前重視風險，並且有所防範，就可以最大限度減少風險的發生。進行風險管理是有效的手段。
1、風險的分類
根據風險內容，我們可以將風險分爲項目風險（成本提高，時間延長等）、技術風險（技術不成熟等）、商業風險（銷售問題等）、戰略風險（公司的經營戰略發生了變化）、管理風險（公司管理人員是否成熟等）、預算風險（預算是否準確等）等。
另外，我們還可以將風險分爲已知風險（如員工離職等）、可預報風險（從以往經驗得出可能有風險的）和不可預知風險。
2、風險的識別
風險識別的有效方法是建立風險項目檢查表。主要涉及以下幾方面檢查：
。產品規模風險檢查
。業務影響風險檢查
。與客戶相關的風險檢查
。過程風險檢查
。技術風險檢查
。開發環境風險檢查
。與人員的模式和經驗有關的風險檢查
3、風險評估
風險評估主要從下面七個方面進行：
。發生的可能性
。發生的結果（影響）
。建立一個尺度表示風險可能性（如，極罕見、罕見、普通、可能、極可能）
。描述風險帶來的後果
。估計對產品和項目的影響
。確定風險評估的正確性
。根據影響排定有限隊列
另外，要對每個風險的表現、範圍、時間做出儘量準確的判斷。
4、風險的評價
對風險的評價主要依據三個因素：風險描述、風險概率和風險影響。從成本、進度及性能三個方面對風險進行評價。確定項目的中止點，在中止點出再一次進行風險評價。
5、風險的駕馭和監控
風險的駕馭與監控主要要靠管理者的經驗來實施。如，某開發人員的離職概率是0.7，離職後會對項目造成一定的影響，則該風險駕馭和監控的策略如下：
。與在職人員協商，確定流動原因。
。在項目開始前，把環節這些流動原因的工作列入風險駕馭計劃。
。項目開始時，作好人是會流動的準備，採取一些措施確保人員一旦離開時，項目仍能繼續。
。制定文檔標準，並建立一種機制，保證文檔及時產生。
。對所有工作進行細微詳審，使更多人能夠按計劃進度完成自己的工作。
。對每個關鍵性技術人員培養後備人員。
在考慮風險成本之後，決定是否採用上述策略。
八、人員管理
1、對項目經理的要求
。能夠使小組每個成員都能發揮能力
。有一定的組織能力
。能夠使小組美味成員有成就感
。有提出解決問題方案的能力
。對問題的理解有一定的深度
。要能讓成員知道軟件質量的重要性
2、人員的通訊方式
（1）正式非個人方式，如正式會議等；
（2）正式個人之間交流，如成員之間的正式討論等（一般不形成決議）；
（3）非正式個人之間交流，如個人之間的自由交流等；
（4）電子通訊，如E-MAIL（電子郵件）、BBS（電子公告板系統）等；
（5）成員網絡，如成員與小組之外或公司之外有經驗的相關人員進行交流；
在實踐中發現，（5）的通訊效率最高，其次是（1）。
人力資源管理中的風險管理
在進行人力資源管理時，我們往往重視招聘、培訓、考評、薪資等各個具體內容的操作，而忽視了其中的風險管理問題。其實，每個企業在人事管理中都可能遇到風險，如招聘失敗、新政策引起員工不滿、技術骨幹突然離職等等，這些事件會影響公司的正常運轉，甚至會對公司造成致命的打擊。如何防範這些風險的發生，是我們應該研究的問題。特別是高新技術企業，由於對人的依賴更大，所以更需要重視人力資源管理中的風險管理。
隨着信息技術的飛速發展，軟件產品的規模也越來越龐大，個人單打獨鬥的作坊式開發方式已經越來越不適應發展的需要。各軟件企業都在積極將軟件項目管理引入開發活動中，對開發實行有效的管理。我公司是西安一家中型軟件企業，在公司中已經實行了項目管理制度，軟件項目管理是整個項目管理中的一個重要組成部分。
從概念上講，軟件項目管理是爲了使軟件項目能夠按照預定的成本、進度、質量順利完成，而對成本、人員、進度、質量、風險等進行分析和管理的活動。實際上，軟件項目管理的意義不僅僅如此，進行軟件項目管理有利於將開發人員的個人開發能力轉化成企業的開發能力，企業的軟件開發能力越高，表明這個企業的軟件生產越趨向於成熟，企業越能夠穩定發展（即減小開發風險）。
軟件開發不同於其他產品的製造，軟件的整個過程都是設計過程（沒有製造過程）；另外，軟件開發不需要使用大量的物質資源，而主要是人力資源；並且，軟件開發的產品只是程序代碼和技術文件，並沒有其他的物質結果。基於上述特點，軟件項目管理與其他項目管理相比，有很大的獨特性。
二、軟件項目管理的組織模式
軟件項目可以是一個單獨的開發項目，也可以與產品項目組成一個完整的軟件產品項目。如果是訂單開發，則成立軟件項目組即可；如果是產品開發，需成立軟件項目組和產品項目（負責市場調研和銷售），組成軟件產品項目組。
公司實行項目管理時，首先要成立項目管理委員會，項目管理委員會下設項目管理小組、項目評審小組和軟件產品項目組。
1、項目管理委員會
項目管理委員會是公司項目管理的最高決策機構，一般由公司總經理、副總經理組成。主要職責如下：
（1）依照項目管理相關制度，管理項目；
（2）監督項目管理相關制度的執行；
（3）對項目立項、項目撤消進行決策；
（4）任命項目管理小組組長、項目評審委員會主任、項目組組長.
2、項目管理小組
項目管理小組對項目管理委員會負責，一般由公司管理人員組成。主要職責如下：
（1）草擬項目管理的各項制度；
（2）組織項目階段評審；
（3）保存項目過程中的相關文件和數據；
（4）爲優化項目管理提出建議。
3、項目評審小組
項目評審小組對項目管理委員會負責，可下設開發評審小組和產品評審小組，一般由公司技術專家和市場專家組成。主要職責如下：
（1）對項目可行性報告進行評審；
（2）對市場計劃和階段報告進行評審；
（3）對開發計劃和階段報告進行評審；
（4）項目結束時，對項目總結報告進行評審。
4、軟件產品項目組
軟件產品項目組對項目管理委員會負責，可下設軟件項目組和產品項目組。軟件項目組和產品項目組分別設開發經理和產品經理。成員一般由公司技術人員和市場人員構成。主要職責是：根據項目管理委員會的安排具體負責項目的軟件開發和市場調研及銷售工作。
三、軟件項目管理的內容
從軟件工程的角度講，軟件開發主要分爲六個階段：需求分析階段、概要設計階段、詳細設計階段、編碼階段、測試階段、安裝及維護階段。不論是作坊式開發，還是團隊協作開發，這六個階段都是不可缺少的。
根據公司實際情況，公司在進行軟件項目管理時，重點將軟件配置管理、軟件質量管理、軟件風險管理及開發人員管理四方面內容導入軟件開發的整個階段。
在八十年代初，著名軟件工程專家B.W.Boehm總結出了軟件開發時需遵循的七條基本原則，同樣，我們在進行軟件項目管理時，也應該遵循這七條原則。它們是：
（1）用分階段的生命週期計劃嚴格管理；
（2）堅持進行階段評審；
（3）實行嚴格的產品控制；
（4）採用現代程序設計技術；
（5）結果應能夠清楚地審查；
（6）開發小組地人員應該少而精；
（7）承認不斷改進軟件工程實踐地必要性。
四、編寫《軟件項目計劃書》
項目組成立的第一件事是編寫《軟件項目計劃書》，在計劃書中描述開發日程安排、資源需求、項目管理等各項情況的大體內容。計劃書主要向公司各相關人員發放，使他們大體瞭解該軟件項目的情況。對於計劃書的每個內容，都應有相應具體實施手冊，這些手冊是供項目組相關成員使用的。
《軟件項目計劃書》一般應該包括下述內容：
1.引言
1.1計劃的目的
1.2項目的範圍和目標
1.2.1範圍描述
1.2.2主要功能
1.2.3性能
1.2.4管理和技術約束
2.項目估算
2.1使用的歷史數據
2.2使用的評估技術
2.3工作量、成本、時間估算
3.風險管理戰略
3.1風險識別
3.2有關風險的討論
3.3風險管理計劃
3.3.1風險計劃
3.3.2風險監視
3.3.3風險管理
4.日程
4.1項目工作分解結構
4.2時限圖(甘特圖)
4.3資源表
5.項目資源
5.1人員
5.2硬件和軟件
5.3特別資源
6.人員組織
6.1組織結構
6.2管理報告
7.跟蹤和控制機制
7.1質量保證和控制
7.2變化管理和控制
8.附錄
五、軟件配置管理
是否進行配置管理與軟件的規模有關，軟件的規模越大，配置管理就顯得越重要。軟件配置管理簡稱SCM（Software Configuration Management的縮寫），是在團隊開發中，標識、控制和管理軟件變更的一種管理。配置管理的使用取決於項目規模和複雜性以及風險水平。
1、目前軟件開發中面臨的問題
。在有限的時間、資金內，要滿足不斷增長的軟件產品質量要求；
。開發的環境日益複雜，代碼共享日益困難，需跨越的平臺增多；
。程序的規模越來越大；
。軟件的重用性需要提高；
。軟件的維護越來越困難。
2、軟件配置管理應提供的功能
在ISO9000.3中，對配置管理系統的功能作了如下描述：
。唯一地標識每個軟件項的版本；
。標識共同構成一完整產品的特定版本的每一軟件項的版本；
。控制由兩個或多個獨立工作的人員同時對一給定軟件項的更新；
。控制由兩個或多個獨立工作的人員同時對一給定軟件項的更新；
。按要求在一個或多個位置對複雜產品的更新進行協調；
。標識並跟蹤所有的措施和更改；這些措施和更改是在從開始直到放行期間，由於更改請求或問題引起的。
3、版本管理
軟件配置管理分爲版本管理、問題跟蹤和建立管理三個部分，其中版本管理是基礎。版本管理應完成以下主要任務：
。建立項目；
。重構任何修訂版的某一項或某一文件；
。利用加鎖技術防止覆蓋；
。當增加一個修訂版時要求輸入變更描述；
。提供比較任意兩個修訂版的使用工具；
。採用增量存儲方式；
。提供對修訂版歷史和鎖定狀態的報告功能；
。提供歸併功能；
。允許在任何時候重構任何版本；
。權限的設置；
。晉升模型的建立；
。提供各種報告。
4、配置管理軟件PVCS 6.0
PVCS6.0是一套非常優秀的配置管理軟件，它能夠實現配置管理中的各項要求，並且能和多種流行開發平臺集成，爲配置管理提供了很大的方便。
六、軟件質量管理
隨着軟件開發的規模越來越大，軟件的質量問題顯得越來越突出。軟件質量的控制不單單是一個軟件測試問題，在軟件開發的所有階段都應該引入質量管理。我公司除加強了國家標準"信息技術軟件生存期過程"（GB/T8566--1995）的規範管理外，還積極爲通過ISO 9000.3做準備。
1、軟件質量保證計劃
在進行軟件開發前，需要有一個《軟件質量保證計劃》。目前較常用的是ANSI/IEEE STOL
730--1984，983--1986標準，包括以下內容：
1.計劃目的
2.參考文獻
3.管理
3.1.組織
3.2.任務
3.3.責任
4.文檔
4.1.目的
4.2.要求的軟件工程文檔
4.3.其他文檔
5.標準和約定
5.1.目的
5.2.約定
6.評審和審計
6.1.目的
6.2.評審要求
6.2.1.軟件需求的評審
6.2.2.設計評審
6.2.3.軟件驗證和確認評審
6.2.4.功能評審
6.2.5.物理評審
6.2.6.內部過程評審
6.2.7.管理評審
7.測試
8.問題報告和改正活動
9.工具、技術和方法
10.媒體控制
11.供應者控制
12.記錄、收集、維護和保密
13.培訓
14.風險管理
2、質量管理的基本原則
。控制所有過程的質量；
。過程控制的出發點是預防不合格；
。質量管理的中心任務是建立並實施文件化的質量體系；
。持續的質量改進；
。有效的質量體系應滿足顧客和組織內部雙方的需要和利益；
。定期評價質量體系；
。搞好質量管理關鍵在於領導。
3、軟件質量因素
正確性：系統滿足規格說明和用戶目標的程度，即，在預定環境下能正確地完成預期功能的程度。
健壯性：在硬件發生故障、輸入的數據無效或操作錯誤等意外環
境下，系統能做出適當響應的程度。
效率：爲了完成預定的功能，系統需要的計算資源的多少。
完整性（安全性）：對未經授權的人使用軟件或數據的企圖，系統能過控制（禁止）的程度。
可用性：系統在完成預定應該完成的功能時另人滿意的程度。
風險：按預定的成本和進度把系統開發出來，並且爲用戶所滿意的概率。
可理解性：理解和使用該系統的容易程度。
可維修性：診斷和改正在運行現場發現的錯誤所需要的工作量的大小。
靈活性（適應性）：修改或改進正在運行的系統需要的工作量的多少。
可測試性：軟件容易測試的程度。
可移植性：把程序從一種硬件配置和（或）軟件系統環境轉移到另一種配置和環境時，需要的工作量多少。有一種定量度量的方法是：用原來程序設計和調試的成本除移植時需用的費用。
可再用性：再其他應用中該程序可以被再次使用的程度（或範圍）。
互運行性：把該系統和另一個系統結合起來需要的工作量的多少。
4、軟件評審
軟件評審並不是在軟件開發完畢後進行評審，而是在軟件開發的各個階段都要進行評審。因爲在軟件開發的各個階段都可能產生錯誤，如果這些錯誤不及時發現並糾正，會不斷地擴大，最後可能導致開
發的失敗。下面這組數據可以清楚的看出前期的錯誤對後期的影響。
軟件評審是相當重要的工作，也是目前國內開發最不重視的工作。
（1）評審目標
。發現任何形式表現的軟件功能、邏輯或實現方面的錯誤；
。通過評審驗證軟件的需求；
。保證軟件按預先定義的標準表示；
。已獲得的軟件是以統一的方式開發的；
。使項目更容易管理。
（2）評審過程
A、召開評審會議：一般應有3至5人蔘加，會前每個參加者做好準備，評審會每次一般不超過2小時。
B、會議結束使必須做出以下決策之一：接受該產品，不需做修改；由於錯誤嚴重，拒絕接受；暫時接受該產品。
C、評審報告與記錄；所提出的問題都要進行記錄，在評審會結束前產生一個評審問題表，另外必須完成評審簡要報告。
（3）評審準則
。評審產品，而不是評審設計者（不能使設計者有任何壓力）；
。會場要有良好的氣氛；
。建立議事日程並維持它（會議不能脫離主題）；
。限制爭論與反駁（評審會不是爲了解決問題，而是爲了發現問題；
。指明問題範圍，而不是解決提到的問題；
。展示記錄（最好有黑板，將問題隨時寫在黑板上）；
。限制會議人數和堅持會前準備工作；
。對每個被評審的產品要盡力評審清單（幫助評審人員思考）；
。對每個正式技術評審分配資源和時間進度表；
。對全部評審人員進行必要的培訓；
。及早地對自己地評審做評審（對評審準則的評審）。
5、ISO9000.3軟件質量認證體系
ISO9000.3是ISO9000質量體系認證中關於計算機軟件質量管理和質量保證標準部分。它從管理職責、質量體系、合同評審、設計控制、文件和資料控制、採購、顧客提供產品的控制、產品標識和可追溯性、過程控制、檢驗和試驗、檢驗/測量和試驗設備的控制、檢驗和試驗狀態、不合格品的控制、糾正和預防措施、搬運/貯存/包裝/防護和交付、質量記錄的控制、內部質量審覈、培訓、服務、統計系統等二個方面對軟件質量進行了要求。
6、測試
軟件測試是軟件開發的一個重要環節，同時也是軟件質量保證的一個重要環節。所謂測試就是用已知的輸入在已知環境中動態地執行系統（或系統的部件）。測試一般包括單元測試、模塊測試、集成測試和系統測試。如果測試結果與預期結果不一致，則很可能是發現了系統中的錯誤，測試過程中將產生下述基本文檔：
（1）測試計劃：確定測試範圍、方法、和需要的資源等。
（2）測試過程：詳細描述和每個測試方案有關的測試步驟和數據（包括測試數據及預期的結果）。
（3）測試結果：把每次測試運行的結果歸入文檔，如果運行出錯，則應產生問題報告，並且必須經過調試解決所發現的問題。測試結果：把每次測試運行的結果歸入文檔，如果運行出錯，則應產生問題報告，並且必須經過調試解決所發現的問題。
七、軟件風險管理
軟件項目管理存在着風險，如果我們提前重視風險，並且有所防範，就可以最大限度減少風險的發生。進行風險管理是有效的手段。
1、風險的分類
根據風險內容，我們可以將風險分爲項目風險（成本提高，時間延長等）、技術風險（技術不成熟等）、商業風險（銷售問題等）、戰略風險（公司的經營戰略發生了變化）、管理風險（公司管理人員是否成熟等）、預算風險（預算是否準確等）等。
另外，我們還可以將風險分爲已知風險（如員工離職等）、可預報風險（從以往經驗得出可能有風險的）和不可預知風險。
2、風險的識別
風險識別的有效方法是建立風險項目檢查表。主要涉及以下幾方面檢查：
。產品規模風險檢查
。業務影響風險檢查
。與客戶相關的風險檢查
。過程風險檢查
。技術風險檢查
。開發環境風險檢查
。與人員的模式和經驗有關的風險檢查
3、風險評估
風險評估主要從下面七個方面進行：
。發生的可能性
。發生的結果（影響）
。建立一個尺度表示風險可能性（如，極罕見、罕見、普通、可能、極可能）
。描述風險帶來的後果
。估計對產品和項目的影響
。確定風險評估的正確性
。根據影響排定有限隊列
另外，要對每個風險的表現、範圍、時間做出儘量準確的判斷。
4、風險的評價
對風險的評價主要依據三個因素：風險描述、風險概率和風險影響。從成本、進度及性能三個方面對風險進行評價。確定項目的中止點，在中止點出再一次進行風險評價。
5、風險的駕馭和監控
風險的駕馭與監控主要要靠管理者的經驗來實施。如，某開發人員的離職概率是0.7，離職後會對項目造成一定的影響，則該風險駕馭和監控的策略如下：
。與在職人員協商，確定流動原因。
。在項目開始前，把環節這些流動原因的工作列入風險駕馭計劃。
。項目開始時，作好人是會流動的準備，採取一些措施確保人員一旦離開時，項目仍能繼續。
。制定文檔標準，並建立一種機制，保證文檔及時產生。
。對所有工作進行細微詳審，使更多人能夠按計劃進度完成自己的工作。
。對每個關鍵性技術人員培養後備人員。
在考慮風險成本之後，決定是否採用上述策略。
八、人員管理
1、對項目經理的要求
。能夠使小組每個成員都能發揮能力
。有一定的組織能力
。能夠使小組美味成員有成就感
。有提出解決問題方案的能力
。對問題的理解有一定的深度
。要能讓成員知道軟件質量的重要性
2、人員的通訊方式
（1）正式非個人方式，如正式會議等；
（2）正式個人之間交流，如成員之間的正式討論等（一般不形成決議）；
（3）非正式個人之間交流，如個人之間的自由交流等；
（4）電子通訊，如E-MAIL（電子郵件）、BBS（電子公告板系統）等；
（5）成員網絡，如成員與小組之外或公司之外有經驗的相關人員進行交流；
在實踐中發現，（5）的通訊效率最高，其次是（1）。
人力資源管理中的風險管理
在進行人力資源管理時，我們往往重視招聘、培訓、考評、薪資等各個具體內容的操作，而忽視了其中的風險管理問題。其實，每個企業在人事管理中都可能遇到風險，如招聘失敗、新政策引起員工不滿、技術骨幹突然離職等等，這些事件會影響公司的正常運轉，甚至會對公司造成致命的打擊。如何防範這些風險的發生，是我們應該研究的問題。特別是高新技術企業，由於對人的依賴更大，所以更需要重視人力資源管理中的風險管理。