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）。

人力資源管理中的風險管理

在進行人力資源管理時，我們往往重視招聘、培訓、考評、薪資等各個具體內容的操作，而忽視了其中的風險管理問題。其實，每個企業在人事管理中都可能遇到風險，如招聘失敗、新政策引起員工不滿、技術骨幹突然離職等等，這些事件會影響公司的正常運轉，甚至會對公司造成致命的打擊。如何防範這些風險的發生，是我們應該研究的問題。特別是高新技術企業，由於對人的依賴更大，所以更需要重視人力資源管理中的風險管理。[@more@]

對軟體專案管理的探討（2）（轉）

相關文章