時間：2023-04-28 09:08:48
序論：在您撰寫軟件管理論文時，參考他人的優秀作品可以開闊視野，小編為您整理的7篇范文，希望這些建議能夠激發您的創作熱情，引導您走向新的創作高度。
軟件項目管理一個創造性的領域，其以滿足客戶特定的需求為目標，以團隊的形式有效地組織企業項目資源，通過對項目進行管理和控制，實現項目的目標。在我國軟件行業起步較晚，但在最近幾年里得到了迅速的發展，但在應用項目管理中還存在許多的問題。
1.1對軟件項目管理認識程度不足，缺乏整體把握
軟件項目經理或管理人員對項目管理的知識體系沒有全面的了解和把握，在實際工作中不能很好地指導項目管理實踐，依靠個人原有的知識技能對項目進行隨意、盲目的工作管理。在軟件企業中，項目經理往往是在技術上能獨當一面的指揮官，但是他們在項目管理方面知識比較缺乏，對項目管理認識程度不足，導致出現管理混亂現象。一些軟件項目管理人員對項目沒有一個整體的把握，對總個項目沒有系統的認識，不能很全面的做出總體計劃、階段計劃。由于項目中有許多不確定的因素存在，項目經理沒有系統分析各個不確定因素的內在聯系，考慮不周全，做計劃是走過場的形式，做出的計劃不能適應情況的變化，造成計劃與控制管理完全是脫節，銜接不上從而無法進行有效的控制和管理。計劃跟不上變化是軟件項目管理中常見現象。
1.2管理思想和理念沒有得到落實，風險管理不成熟
管理思想和管理理念對軟件項目管理起著引導作用，對軟件項目管理理論上的不足將可能導致軟件項目管理的失敗。我國軟件項目管理發展較晚，管理人員在管理中多依靠自身的實踐經驗去開展工作，而對管理理論較為缺乏。部分項目經理不能總體上去管理整個項目，不能充分認識到自己是一個管理者，造成項目管理中工作任務分工不明確、資源浪費現象。從我國當前軟件企業中，項目經理大多技術方面的知識扎實，但是項目管理知識、管理技能以及必備的素質都比較缺乏。特別是對軟件項目管理中的風險管理認識較為膚淺，有待進一步的學習和提高。由于項目管理人員在項目管理實踐中缺乏高效的管理思想，缺乏有效的方式和技巧，項目工作人員之間的團體協作能力較弱，資源整合優勢難以有效發揮。
1.3缺乏有效溝通
在軟件項目管理中，溝通是維持項目進行的重要條件。若在一些重要信息方面缺乏有效的溝通，將可能導致項目管理出現較多障礙。從當前我國軟件企業項目管理的實踐來看，普遍存在溝通機制不完善，渠道不夠通暢，各相關人員之間在項目管理中制定計劃、意見反饋、情況通報、技術成果等等方面溝通不足，容易造成重復勞動，效率低下等情況發生，有的甚至造成的完全可以節省的損失。在軟件項目管理中項目經理需要花費大量的時間來溝通和協調，而且要善于溝通，提高溝通意識和效率。
2軟件項目管理發展對策
2.1提高項目管理人員計劃意識，優化人力資源配置
軟件項目管理人員在工作中要以身作則，真正發揮帶頭作用。在工作中要及時制定符合工作需要的工作計劃并認真落實。計劃要具有一定的前瞻性，在客觀條件發生變換的時候要不斷完善細化。軟件更新速度較快，企業要在軟件行業發展中搶占先機，要求管理人員要重視計劃的制定，不斷完善和優化工作流程。在軟件項目管理中，要不斷優化人力資源配置，使得每位員工能夠對自身職責有明確的認識，工作責任意識明確，職員之間能夠做到優勢互補。管理人員要具備強烈的責任心和團隊意識，不斷發現和培養優秀人才。
2.2樹立風險管理理念，強化項目管理培訓力度
我們要加強軟件項目管理人員對項目管理知識學習，各方面都能充分認識到項目管理的重要性和必要性，讓項目經理重視對項目管理的知識的學習和一些常用工具和方法使用。不斷樹立項目管理人員風險管理理念，充分意識到風險管理的重要性，經過充分分析、預測、評估可能的風險，積極探索應對風險的策略。對計劃書中風險管理要具有針對性和具體性，真正發揮風險管理在防范風險中的作用。不斷通過項目管理培訓來強化管理人員實踐能力和知識技能。只有具備管理知識和管理經驗的人員才能擔任管理人員和技術人員，大幅提高項目管理水平。
2.3加強溝通，從整體上對軟件項目管理進行把握
軟件項目管理有效開展離不開有效的溝通，這要求要不斷提高溝通意識，在企業中制定切實可行的溝通機制，使得各項企業政策能夠上下通達。在項目管理溝通方式上要不拘一格，實現溝通方式的多樣化，如書面溝通、口頭溝通，提高溝通的有效性。對于因溝通不暢導致的損失要明確責任歸屬，確保企業重要內容信息的有效傳達。軟件項目管理人員要從整體上對軟件項目管理進行把握，綜合考慮各因素，作出全面的總體計劃、階段計劃。同時對于具體問題也要預留空間，確保管理計劃能夠緊跟軟件管理需要。
3結語
1.1能力成熟度模型（CMM）
1.1.1能力成熟度模型的概念能力成熟度模型（CMM）這一概念最初源自于西方發達國家。能力成熟度模型則是針對軟件組織在定義、規劃、實施、度量、控制以及調整軟件等過程的實踐階段的具體描述。從本質上來看，能力成熟度模型（CMM）的主要智能作用便是系統地規劃某一個項目的設計內容以及管控實施過程，直至項目最終建設完成投入使用。對于軟件工程管理項目而言，能力成熟度模型（CMM）的核心功能便是將軟件開發當作一個系統化的過程來處理，并且，根據能力成熟度模型本身的原則來突進軟件開發項目的拓展進度，如若遇到問題或需要進行系統維護，則在能力成熟度模型的操作下，能夠快速將問題解決，促使軟件開發能夠更加順利地執行下去。
1.1.2淺析能力成熟度模型在實施過程中的機理能力成熟度模型（CMM）是一種用于評價軟件承包能力并幫助其改善軟件質量的方法，側重于軟件開發過程的管理及工程能力的提高與評估。能力成熟度模型在實際操作過程中的具體思路為：只要集中精力持續努力去建立有效的軟件工程過程的基礎結構，而且，要不斷進行管理的實踐并適時做出調整，就可以順利跨越軟件開發過程中的各項障礙[4]。
1.2基于能力成熟度模型（CMM）模型框架的軟件工程管理工具的應用效能
隨著國內外軟件產業的迅猛發展，有關軟件工程領域的研究亦日趨深入，給軟件研發以及產業項目的發展提供了有力的策略支持。在當前信息時代背景下，軟件開發不再取決于傳統資源框架搭建得是否完整，而是與能力成熟度指標密切相關。軟件過程成熟度則主要體現于對軟件開發過程的控制能力和自我改善能力，在優化項目質量管理的過程中，可對這兩項能力進行逐一改善，進而提升整體軟件項目的質量。實踐表明，能力成熟度模型（CMM）影響下的軟件工程管理工具具備提升軟件開發效能的作用。
2結語
什么是工業設計？
（略）
工業設計是交互設計的原型
交互設計過程是生產有用、易用和樂用的軟件產品的過程。交互設計和工業設計有很多共同點。和工業設計一樣，交互設計綜合工程，人機和市場方面的因素，對用戶的問題提出解決方案。其最大的不同就在于二者處理的材料不同：工業設計面對三維的造型材料而交互設計面對的主要是計算機顯示器。現在，多數的軟件的物理交互還是限制在鼠標和鍵盤。但在將來人們將可以通過多種形式的交互工具以提高溝通效率。那時，不止是計算機，電視、電話以及其他的信息產品都會在內容和物理形態上發生變化。不過在此之前，大多數的計算機用戶的時間還是要花費在象Word，電子表格，eMail，個人財務軟件等傳統軟件上。鼠標和鍵盤還是最最要的輸入工具。交互設計還是要依靠圖形界面，通過可行的方式與人們溝通，使其能完成復雜的工作。
平面設計與工業設計
由于平面設計主要從事圖形和文字等二維設計工作，所以交互設計一開始被自然地認為屬于平面設計領域。當今的一些軟件著作也把交互設計也和平面設計聯系在一起。造成這樣結果的一個原因是在軟件開發的歷史中，平面設計總是在開發的末端被邀請加入做一些視覺化的工作，如醒目的外形、對話框和圖標。雖然這些是重要的設計因素，但它只是交互設計的部分工作。這些設計和傳統的制作復印機、相機和自動販賣機的標簽沒有區別。這是需要的設計，但和更復雜的交互設計過程相比，這只是設計的一部分。工業設計師的不同之處在于它建立于良好的用戶與產品的角度，并與工程師和市場人員合作解決問題。以柯達公司為例，設計在其中扮演著重要角色。柯達的CEOGeorgeFisher最近就評價RudyKrolopp（工業設計主管）的能力是組織協調最優秀的設計師和工程師將幻想變成現實。如今的軟件，早期的設計都是由工程師和工程背景的人完成的，就像當時在工業設計的初期。很少有軟件的設計在一開始就有交互設計師的參與，不過隨著交互設計作為學科的發展，這一情況將趨向結束。
雖然平面設計只是交互設計的一個環節，但它還是在軟件社會里更多的吸引更多的注意力。部分的原因是圖形界面的不斷增長的圖標和對話框的需要，而更多的原因來自于多媒體。平面設計在多媒體領域被廣泛認可，這源于它對內容的設計，而工程師對這一領域并不擅長。工程師放棄對多媒體的設計控制是他們明白自己的背景不能達到一個平面設計師所能產生的效果。因為多媒體是作為雜志、視頻的競爭者或贈品被投入市場的，它必須在圖片質量和內容上達到或超過這些媒體。因此，平面設計就很具代表性地成為多媒體設計的最高需求。同時，傳統軟件為滿足圖標和對話框地設計需求，自然會將平面設計移植到圖形界面設計領域。
軟件的目的是作為一種工具讓人去用去創造，從這個角度講它和傳統工具如螺絲刀、復印機或叉車并無差別。因此，使用軟件的動機和行為與瀏覽多媒體作品的看和讀是不同的。我們也不會奇怪多媒體的設計會遵從傳統的平面設計的模式，因為它最重要的交互就是導航而沒有創作的成分。與此不同，交互設計更象傳統的工業設計，關注創造有用、易用和樂用的產品使人們在與科技的交互過程中去用，去想象，去創造。由于多數用戶會使用工具軟件去工作，而這些軟件還很少經過專業設計師的設計，所以在軟件交互設計領域工業設計師還是有巨大的機遇。
交互設計發展狀況
越來越多的工業設計師加入到交互設計行列，不過這一數量與平面設計師相比還是太小。許多工業設計師通過設計輸入設備和PDA起到這樣的作用，不過更多的是繼續從事他們的三維建模活動。工業設計被交互設計領域忽視的一個原因是多媒體設計師搶奪了人們過多的注意力。工具軟件也并不是人們日常談論的焦點。另一個更讓人擔憂的原因可以在大學中找到。當你去任何大學打聽關于在哪可以學習到交互設計的課程，你會發現自己被領到計算機房，那里學生們還在學習老套的計算機輔助設計課程，或是你被告知去計算機系尋找。還有許多情況是發現工業設計和平面設計在為誰更應該成立交互設計而爭論不休。事實上，我認為要成為合格的交互設計師，應該具備工業設計和平面設計雙方面的知識、技巧和經驗。不過工業設計應該覆蓋其中更多的內容。因為工業設計的課程中包含了人機工程學和機械工程的內容而平面設計則沒有，同時在完成項目時平面設計也很少考慮人和工程的限制因素。最終，要成為合格的交互設計師，平面設計和工業設計都要從對方身上學習。為了交互事業在軟件行業的繁榮發展，我們不光要為多媒體培養平面設計師，也要為軟件培養交互設計師。
交互設計的未來
雷蒙羅維（RaymondLoewy）這位工業設計大師運用他的藝術修養和個人技巧于美學，人機工程和機械工程之中，開創了一個新的工業時代。今天的設計師也必定要將自己的背景和技巧應用于新的科技時代。當多媒體在網站得到進一步發展的時候，我們不要忘記軟件行業以及其中蘊藏的交互設計的機會。就像早期的工業設計先去為實現產品的有用、易用和樂用的目標與工程師并肩作戰，今天軟件行業更需要工程師和設計師的努力，為了一個共同的目標：軟件的有用、易用和樂用。就在雷蒙羅維去世前十年，他就預測到“軟件設計”的可能性。他也發現了工業設計和交互設計的內在聯系了嗎？隨著對交互設計的興趣的增長，一些交互設計的課程已經開始形成，交互設計的團隊也在世界范圍內建立，交互設計正在穩步地形成自己的學科。正象工業革命幫助建立了工業設計學科，新技術革命也正在幫助建立交互設計，軟件工業里的工業設計，這一新興學科。
參考文獻：
(1)JeffreyMeikle,TwentiethCenturyLimited,Philadelphia,1979,p.39
復雜的機器視覺測量系統在使用時會使你感到迷惑、而且將付出更大的代價。IPD的目的是為你提供容易使用的工具以及容易理解的使用說明。
1精度、重復性和精密度的定義
精度、重復性、精密度是任何測量系統的性能特點。
重復性是重復測量結果的一致性（參見圖1）。
精度是測量結果與真實性的接近程度。可以認為是重復測量結果和真實值的差值平均值平均值。
精度度是提測量結果可讀的位數。
一個機器視覺系統（如iGauge）可以返回7位測量結果，但是只有重復性和精度檢測能告訴這些數字有多少有意義的。在該例中，精密度是通過精度和重復性所決定的，因此我們沒必要進一步討論精密度。
2精度和重復性的確定
機器視覺測量系統在圖像的ROI、鏡頭以及相機已經選定并且已固定時，可以根據物理單位（如微米）確定精度和重復性。因為iGauge的鏡頭以及ROI可以有一定范圍的變化，因此我們必須根據象素（當物體在FOV中時圖象的一元素的尺寸）確定精度和重復性。
如果知道以下條件，便可以估計精度和重復性。
（1）FOV（可以被相機看到的面積）以及相機的圖象傳感器中元素的數量。根據這些你可以以物理單位來計算相應的象素尺寸。
（2）測量系統的精度以及重復性（比象素來測量）。
如：用一個相機拍攝一個6英寸長的FOV，對應的象素尺寸為6/640=0.094英寸。如果象素的精度為1/2，那么我們可以測量到0.0047英寸。
3iGauge的工作過程
為了有效的利用測量零件、尺寸、孔等。首先應進行如下工作：
（1）選擇合適的光源清楚的表示你想測量的東西。
（2）選擇合適的鏡頭以及工作距離（從鏡頭到被測物體的距離）以提供一個最佳的FOV。一個最佳的FOV包括被測零件的面積以及允許零件移動和配準的一點范圍。
（3）用適當的夾具將零件固定在相機的FOV內。
（4）確保iGauge提供的精度和重復性能滿足測量任務的要求。
1.1測試設計重點偏離使用QC軟件測試發現bug統計，如表1所示。根據表1工作量統計，25人/日為5個中級測試工程師一周的工作量，但是根據測試用例發現的bug數量僅占bug總量的44.18%，該比例顯示測試用例的設計重點嚴重出現偏離。需要在測試用例設計的方向上進行調整。
1.2測試過程不可控QC軟件測試計劃中測試執行階段為2013.3.8-2013.3.27，執行三輪測試；實際測試時間為2013.3.23-2013.4.20，執行測試三輪，計劃完成時間嚴重偏離，表2為原計劃與實際計劃的對比。表2顯示測試計劃進行了較大調整，計劃截止時間比原計劃延遲23天。延遲原因經分析主要為開發提交測試時間延遲，開發提交版本問題較多，測試計劃安排不合理，在兩輪測試間為安排開發修改bug時間等。想要解決該問題，不僅需要對測試過程進行管理，同時也需要對開發提交的測試版本質量進行管理。
2軟件質量管理改進對策
2.1需求工程管理軟件開發過程中，需求不明確會帶來需求的頻繁變更，浪費了很多時間。針對此項問題，可對需求相關的活動進行統一管理，其需求管理結構圖如圖2所示。加強需求開發和需求管理的有機結合，不僅減少了需求的變更次數，還解決了工程師對需求不能理解到位的問題。需求開發和需求管理同樣重要，只有兩者互相配合才能做出用戶滿意的產品。
2.2立項管理為了使有限的資源發揮更高的價值，公司可通過立項管理流程進行立項管理，立項管理流程分為立項建議、立項評審和立項籌備三個階段，其具體流程圖3所示。
2.3測試流程管理針對測試流程中發現的問題，可對整體的測試流程做如下的改變：（1）測試部門可進行需求學習及需求討論，對理解不清楚及有疑問的需求，由研發設計部門進行解答，研發設計部門不能解答的由其聯系用戶確認后作出解答；（2）需求確認后，針對系統功能和性能等指標，由測試工程師進行測試測用例的設計，設計從兩個方面進行，一方面測試工程師根據需求進行測試用例的編寫，另一方面測試工程師可根據用戶反饋問題進行分析匯總；（3）使用QC功能測試工具對應用軟件兼容性、操作系統兼容性進行測試，以便于使用測試工具完成多種環境下的功能和兼容性測試；（4）進行自由測試以便于對系統測試用例進行補充，分析測試用例未覆蓋問題的原因；（5）定期分析缺陷庫中的問題，分析問題產生的原因，進行測試用例的修改。
3結論
在實際的項目質量管理中，質量管理總是圍繞著質量保證(QualityAssurance)過程和質量控制(QualityControl)過程兩方面。這兩個過程相互作用，在實際應用中還可能會發生交叉。正如引言所述，關于軟件的質量，很難下一個非常明確的定義。本文主要針對軟件工程中的質量管理來進行討論。
做軟件“大餐”的工序
軟件質量保證（SoftwareQualityAssurance，以下簡稱SQA）的目的是驗證在軟件開發過程中是否遵循了合適的過程和標準。軟件質量保證過程一般包含以下幾項活動：
首先是建立SQA組；其次是選擇和確定SQA活動，即選擇SQA組所要進行的質量保證活動，這些SQA活動將作為SQA計劃的輸入；然后是制定和維護SQA計劃，這個計劃明確了SQA活動與整個軟件開發生命周期中各個階段的關系；還有執行SQA計劃、對相關人員進行培訓、選擇與整個軟件工程環境相適應的質量保證工具；最后是不斷完善質量保證過程活動中存在的不足，改進項目的質量保證過程。
獨立的SQA組是衡量軟件開發活動優劣與否的尺度之一。SQA組的這一獨立性，使其享有一項關鍵權利??“越級上報”。當SQA組發現產品質量出現危機時，它有權向項目組的上級機構直接報告這一危機。這無疑對項目組起到相當的“威懾”作用，也可以看成是促使項目組重視軟件開發質量的一種激勵。這一形式使許多問題在組內得以解決，提高了軟件開發的質量和效率。
選擇和確定SQA活動這一過程的目的是策劃在整個項目開發過程中所需要進行的質量保證活動。質量保證活動應與整個項目的開發計劃和配置管理計劃相一致。一般把該活動分為以下五類：
1）評審軟件產品、工具與設施
軟件產品常被稱為“無形”的產品。評審時難度更大。在此要注意的一點是：在評審時不能只對最終的軟件代碼進行評審，還要對軟件開發計劃、標準、過程、軟件需求、軟件設計、數據庫、手冊以及測試信息等進行評審。評估軟件工具主要是為了保證項目組采用合適的技術和工具。評估項目設施的目的是保證項目組有充足設備和資源進行軟件開發工作。這也為規劃今后軟件項目的設備購置、資源擴充、資源共享等提供依據。
2）SQA活動審查的軟件開發過程
SQA活動審查的軟件開發過程主要有：軟件產品的評審過程、項目的計劃和跟蹤過程、軟件需求分析過程、軟件設計過程、軟件實現和單元測試過程、集成和系統測試過程、項目交付過程、子承包商控制過程、配置管理過程。特別要強調的是，為保證軟件質量，應賦予SQA阻止交付某些不符合項目需求和標準產品的權利。
3）參與技術和管理評審
參與技術和管理評審的目的是為了保證此類評審滿足項目要求，便于監督問題的解決。
4）做SQA報告
SQA活動的一個重要內容就是報告對軟件產品或軟件過程評估的結果，并提出改進建議。SQA應將其評估的結果文檔化
5）做SQA度量
SQA度量是記錄花費在SQA活動上時間、人力等數據。通過大量數據的積累、分析，可以使企業領導對質量管理的重要性有定量的認識，利于質量管理活動的進一步開展。
要說明的是，并不是每個項目的質量保證過程都必須包含上述這些活動或僅限于這些活動，要根據項目的具體情況來定。
SQA計劃中必須明確定義在軟件開發的各個階段是如何進行質量保證活動的。它通常包含以下內容：質量目標；定義每個開發階段的開始和結束邊界；詳細策劃要進行的質量保證活動；明確質量活動的職責；SQA組的職責和權限；SQA組的資源需求，包括人員、工具和設施；定義由SQA組執行的評估；定義由SQA組負責組織的評審；SQA組進行評審和檢查時所參見的項目標準和過程；需由SQA組產生的文檔。
選擇合適的SQA工具并不是試圖通過選擇SQA工具來保證軟件產品的質量，而是用以支持SQA的活動。選定SQA工具時，首先需要明確質量保證目標。根據目標制定選擇SQA工具的需求并文檔化，包括對平臺、操作系統以及SQA工具與軟件工程平臺接口的要求等。
如何使白壁“無瑕”
按工序去做也不一定能得到一盤完美的“大餐”，因為火侯等因素實在很難掌握。萬一掌握不好怎么辦？軟件質量控制主要就是發現和消除軟件產品的缺陷。對于高質量的軟件來講，最終產品應該盡可能達到零缺陷。而軟件開發是一個以人為中心的活動，所以出現缺陷是不可避免的。因此，要想交付一個高質量的軟件，消除缺陷的活動就變得很重要。缺陷消除是通過“評審”和“測試”這類質量控制活動來實現的。
缺陷在軟件開發的任何階段都可能會被引入。項目質量管理過程包含了許多可以識別缺陷、消除缺陷的過程。“識別缺陷”和“消除缺陷”本來是兩個不同的過程，但在這里為了簡便統一用“消除”來代表它們。潛在的缺陷越大，用來消除它所花的費用越高。因此成熟的軟件開發過程在每一個可能會引入潛在缺陷的階段完成之后都會開展質量控制活動。這些為了消除缺陷的活動包括：需求評審、設計評審、代碼走查、單元測試、集成測試、系統測試以及驗收測試等。
一般來說，軟件工程師總是非常樂觀。當他們在計劃軟件項目時，經常認為每件事情都會像計劃那樣運行，或者，又會走向另外一個極端。軟件開發的創造性本質意味著我們不能完全預測會發生的事情，因此制定一個詳細計劃的關鍵點很難確定。當有預想不到的事情引起項目脫離正常軌道時，以上兩種觀點都會導致軟件項目的失敗。
目前，風險管理被認為是IT軟件項目中減少失敗的一種重要手段。當不能很確定地預測將來事情的時候，可以采用結構化風險管理來發現計劃中的缺陷，并且采取行動來減少潛在問題發生的可能性和影響。風險管理意味著危機還沒有發生之前就對它進行處理。這就提高了項目成功的機會和減少了不可避免風險所產生的后果。
2什么是風險
所謂“風險”，歸納起來主要有兩種意見，主觀說認為，風險是損失的不確定性；客觀學認為，風險是給定情況下一定時期可能發生的各種結果間的差異。它的兩個基本特征是不確定性和損失。IT行業中的軟件項目開發是一項可能損失的活動，不管開發過程如何進行都有可能超出預算或時間延遲。項目開發的方式很少能保證開發工作一定成功，都要冒一定的風險，也就需要進行項目風險分析。在進行項目風險分析時，重要的是要量化不確定的程度和每個風險相當的損失程度，為實現這一點就必須要考慮以下問題：
要考慮未來，什么樣的風險會導致軟件項目失敗？
要考慮變化，在用戶需求、開發技術、目標、機制及其它與項目有關的因素的改變將會對按時交付和系統成功產生什么影響？
必須解決選擇問題，應采用什么方法和工具，應配備多少人力，在質量上強調到什么程度才滿足要求？
要考慮風險類型，是屬于項目風險、技術風險、商業風險、管理風險還是預算風險等？
這些潛在的問題可能會對軟件項目的計劃、成本、技術、產品的質量及團隊的士氣都有負面的影響。風險管理就是在這些潛在的問題對項目造成破壞之前識別、處理和排除。
3風險管理
項目風險管理實際上就是貫穿在項目開發過程中的一系列管理步驟，其中包括風險識別、風險估計、風險管理策略、風險解決和風險監控。它能讓風險管理者主動“攻擊”風險，進行有效的風險管理。
在項目管理中，建立風險管理策略和在項目的生命周期中不斷控制風險是非常重要的，風險管理包括四個相關階段：
風險識別識別風險的方法常用的有風險識別問詢法（座談法、專家法）、財務報表法、流程圖法、現場觀察法、相關部門配合法和環境分析法等。
風險評估對已識別的風險要進行估計和評價，風險估計的主要任務是確定風險發生的概率與后果，風險評價則是確定該風險的經濟意義及處理的費/效分析，常用的方法有：概率分布、外推法、多目標分析法等。
風險處理一般而言，風險處理有三種方法，①風險控制法，即主動采取措施避免風險，消滅風險，中和風險或采用緊急方案降低風險。②風險自留，當風險量不大時可以余留風險。③風險轉移。
風險監控包括對風險發生的監督和對風險管理的監督，前者是對已識別的風險源進行監視和控制，后者是在項目實施過程中監督人們認真執行風險管理的組織和技術措施。
在IT軟件項目管理中，應該任命一名風險管理者，該管理者的主要職責是在制訂與評估規劃時，從風險管理的角度對項目規劃或計劃進行審核并發表意見，不斷尋找可能出現的任何意外情況，試著指出各個風險的管理策略及常用的管理方法，以隨時處理出現的風險，風險管理者最好是由項目主管以外的人擔任。
險識別
風險識別就是企圖采用系統化的方法，識別某特定項目已知的和可預測的風險。常用方法是建立“風險條目檢查表”，利用一組提問來幫助項目風險管理者了解在項目和技術方面有些風險。在“風險條目檢查表”中，列出了所有可能的與每一個風險因素有關的提問，使得風險管理者集中來識別常見的、已知的和可預測的風險，如產品規模風險、依賴性風險、需求風險、管理風險及技術風險等。“風險條目檢查表”可以以不同的方式組織，通過判定分析或假設分析，給出這些提問確定的回答，就可以幫助管理或計劃人員估算風險的影響。軟件項目一般有如下五類風險：
4.1產品規模風險
有經驗的項目經理都知道：項目的風險是直接與產品的規模成正比的。與軟件規模相關的常見風險因素有：
估算產品的規模的方法（LOC或代碼行，FP或功能點，程序或文件的數目）。
產品規模估算的信任度
產品規模與以前產品規模平均值的偏差
產品的用戶數
復用的軟件有多少
產品的需求改變多少
4.2需求風險
很多項目在確定需求時都面臨著一些不確定性和混亂。當在項目早期容忍了這些不確定性，并且在項目進展過程當中得不到解決，這些問題就會對項目的成功造成很大威脅。如果不控制與需求相關的風險因素，那么就很有可能產生錯誤的產品或者拙劣地建造正確的產品。每一種情況都會導致使人不愉快。
與客戶相關的風險因素有：
對產品缺少清晰的認識
對產品需求缺少認同
在做需求中客戶參與不夠
沒有優先需求
由于不確定的需要導致新的市場
不斷變化需求
缺少有效的需求變化管理過程
對需求的變化缺少相關分析
4.3相關性風險
許多風險都是因為項目的外部環境或因素的相關性產生的。經常我們不能很好地控制外部的相關性，因此緩解策略應該包括可能性計劃，以便從第二資源或協同工作資源中取得必要的組成部分，并且覺察潛在的問題。與外部環境相關的因素有：
客戶供應條目或信息
內部或外部轉包商的關系
交互成員或交互團體依賴性
經驗豐富人員的可得性
項目的復用性
4.4管理風險
盡管管理問題制約了很多項目的成功，但是不要因為風險管理計劃中沒有包括所有管理活動而感到驚奇。在大部分項目里，項目經理經常是寫項目風險管理計劃的人，并且大部分人都不希望在公共場合暴露自己的弱點。然而，像這些問題可能會使項目的成功變得更加困難。如果不正視這些棘手的問題，它們就很有可能在項目進行的某個階段影響項目。當我們定義了項目追蹤過程并且明晰項目角色和責任，就能處理這些風險因素：
計劃和任務定義不夠充分
實際項目狀態
項目所有者和決策者分不清
不切實際的承諾
員工之間的沖突
4.5技術風險
軟件技術的飛速發展和經歷豐富員工的缺乏，意味著項目團隊可能會因為技巧的原因影響項目的成功。在早期，識別風險從而采取合適的預防措施是解決風險領域問題的關鍵，比如：培訓、雇傭顧問以及為項目團隊招聘合適的人才等。主要有下面這些風險因素：
缺乏培訓
對方法、工具和技術理解的不夠
應用領域的經驗不夠
新的技術和開發方法
不能正確工作的方法
5風險估計
風險估計，又稱風險預測，常采用兩種方法估價每種風險。一種是估計風險發生的可能性或概率，另一種是估計如果風險發生時所產生的后果。一般來講，風險管理者要與項目計劃人員、技術人員及其他管理人員一起執行四種風險活動：
（1）建立一個標準（尺度），以反映風險發生的可能性。
（2）描述風險的后果。
（3）估計風險對項目和產品的影響。
（4）確定風險的精確度，以免產生誤解。
另外，要對每個風險的表現、范圍、時間做出盡量準確的判斷。對不同類型的風險采取不同的分析辦法。
1．確定型風險估計
（a）盈虧平衡分析
盈虧平衡分析（Break-EvenAnalysis）通常又稱為量本利分析或損益平衡分析。它是根據軟件項目在正常生產年份的產品產量或銷售量、成本費用、產品銷售單價和銷售稅金等數據，計算和分析產量、成本和盈利這三者之間的關系，從中找出它們的規律，并確定項目成本和收益相等時的盈虧平衡點的一種分析方法。在盈虧平衡點上，軟件項目既無盈利，也無虧損。通過盈虧平衡分析可以看出軟件項目對市場需求變化的適應能力。
（b）敏感性分析
敏感性分析（SensitivityAnalysis）的目的，是考察與軟件項目有關的一個或多個主要因素發生變化時對該項目投資價值指標的影響程度。通過敏感性分析，使我們可以了解和掌握在軟件項目經濟分析中由于某些參數估算的錯誤或是使用的數據不太可靠而可能造成的對投資價值指標的影響程度，有助于我們確定在項目投資決策過程中需要重點調查研究和分析測算的因素。
（c）概率分析
它是運用概率論及數理統計方法，來預測和研究各種不確定因素對軟件項目投資價值指標影響的一種定量分析。通過概率分析可以對項目的風險情況做出比較準確的判斷。主要包括解析法和模擬法（蒙特卡羅MonteCarlo技術）兩種。
2．不確定型風險估計
主要有小中取大原則、大中取小原則、遺憾原則、最大數學期望原則、最大可能原則。
3．隨機型風險估計
主要有最大可能原則、最大數學期望原則、最大效用數學期望原則、貝葉斯后驗概率法等。
5.1建立風險清單
風險清單是關鍵的風險預測管理工具，清單上列出了在任何時候碰到的風險名稱、類別、概率及該風險所產生的影響。其中整體影響值可對四個風險因素（性能、支持、成本及進度）的影響類別求平均值（有時也采用加權平均值）。
一旦完成了風險表的內容，就可以根據概率及影響來進行綜合考慮，風險影響和出現概率從風險管理的角度來看，它們各自起著不同的作用（見圖1）。一個具有高影響但低概率的風險因素不應當占用太多的風險管理時間，而具有中到高概率、高影響的風險和具有高概率及低影響的風險，就應該進行風險分析。
5.2風險評估
在風險分析過程中，我們對風險進行評估時可以建立一個如下的四元數組：
[ri,li,xi，yi]
其中，ri是風險，li為風險出現的概率，xi則表示風險損失大小，yi則表示期望風險。
一種對風險評估的常用技術是定義風險的參照水準，對絕大多數軟件項目來講，風險因素——成本、性能、支持和進度就是典型的風險參照系。也就是說對成本超支、性能下降、支持困難、進度延遲都有一個導致項目終止的水平值。如果風險的組合所產生的問題超出了一個或多個參照水平值時，就終止該項目的工作，在項目分析中，風險水平參考值是由一系列的點構成的，每一個單獨的點常稱為參照點或臨界點。如果某風險落在臨界點上，可以利用性能分析、成本分析、質量分析等來判斷該項目是否繼續工作。圖2表示了這種情況。
但在實際工作中，參照點很少能構成一條光滑的曲線，大多數情況下，它是一個區域，而且是個易變的區域。因而在做風險評估時，盡量按以下步驟執行：
（1）定義項目的水平參照值
（2）找出每組[ri,li,xi，yi]與每個水平參照值間的關系
（3）估計一組臨界點以定義項目的終止區域
（4）估計風險組合將如何影響風險水平參照值
5.3估計損失的大小
表1是風險分析表的一個例子，可以建立一個用風險、損失概率、損失大小和期望風險這樣的風險評估表。
在表1所示的風險估價的例子中，一個理論項目已經識別了從1到20周期間的潛在的幾個風險，風險發生的概率范圍在5%到50%之間。在現實的項目中，可能會識別出比此表要多得多的風險。
損失的大小常常比概率更容易受到控制。在以上的例子中，可以很精確地估計出完全支持自動從主機更新數據的時間是20個月。根據管理層將在何時討論項目建議書,可以知道項目不是在2月1日就是3月1日會被批準。如果假定會在2月1日批準，項目被批準的風險大小會比期望的長一些，也就是1個月時間。
如果損失的大小不容易直接估計出來，可以將損失分解為更小的部分，再對其進行評估，然后將各部分評估結果累加，形成一個合計評估值。例如，如果使用3種新編程工具，可以單獨評估每種工具未達到預期效果的損失，然后再把損失加到一起，這要比總體評估容易多了。
5.4評估損失的概率
評估損失的概率要比評估損失大小更具有主觀性。這里有許多實踐方法可以提高主觀評估的準確度。有以下方法：
由最熟悉系統的人評估每個風險的發生概率，然后保留一份風險評估審核文件。
使用Delphi法或少數服從多數的方法。使用Delphi法，必須要求每個人對每個風險進行獨立地評估，然后討論（口頭或紙上）每個評估的合理性，特別是最高和最低的那個。一輪輪討論，直到達成共識。?使用“形容詞標準”。首先讓每個人用表示可能性的形容詞短語選擇風險的級別，如非常可能、很可能、可能、或許、不太可能、不可能、和根本不可能。然后把可能性的評估轉換為數量化的評估（Boehm1989）。
5.5整個項目超限和緩沖
實際上，表1中表示的期望風險的計算數值來源于一個被稱為“期望值”的統計術語。設計欠佳引起的風險如果真正發生將花費15周的時間。既然它不是100%地會發生，當然不能預計損失15周時間。但它也不是沒有可能發生，所以也不應指望不會發生損失。統計學認為，預計損失的數量是概率乘以損失大小，即15%乘以15周。因此，在這個例子中，預計的是損失2.25周。由于只是談論計劃風險，可以累加所有的風險暴露量來得到項目的全部可預料超標值。這個項目可預料的超標值是12.8到13.2周，這就是如果不做任何風險管理的話有可能超過計劃的周數。
超出預期值的大小為整個項目風險控制級別的確定提供了依據。如果例子中的項目是個25周的項目，超出預期值的12.8到13.2周就很明顯需要進行風險管理了。
6風險管理策略
風險管理策略就是輔助項目組建立處理項目風險的策略。項目開發是一個高風險的活動，如果項目采取積極的風險管理策略，就可以避免或降低許多風險，反之，就有可能使項目處于癱瘓狀態。一般來講，一個較好的風險管理策略應滿足以下要求：
（1）在項目開發中規劃風險管理，盡量避免風險
（2）指定風險管理者，監控風險因素
（3）建立風險清單及風險管理計劃
（4）建立風險反饋渠道
7風險駕馭和監控
風險的駕馭與監控主要靠管理者的經驗來實施，它是利用項目管理方法及其它某些技術，如原型法、軟件心理學、可靠性等來設法避免或轉移風險。風險的駕馭和監控活動可用圖3來表示。
7.1建立風險駕馭與監控計劃
從圖3中可以看出，風險的駕馭與監控活動要寫入RMMP（RiskMonitoringandManagementPlan風險駕馭與監控計劃）。RMMP記述了風險分析的全部工作，并且作為整個項目計劃的一部分為項目管理人員所使用。
風險管理策略可以包含在軟件項目計劃中，也可以組織成一個獨立的風險緩解、監控和管理計劃（RMMP計劃）。RMMP計劃將所有風險分析工作文檔化，并由項目管理者作為整個項目計劃中的一部分來使用。一旦建立了RMMP計劃，且項目開始啟動，則風險緩解及駕馭及監控步驟也開始了。正如前面討論的，風險緩解是一種問題避免活動。風險駕馭及監控則是一種項目跟蹤活動，它有三個主要目標：?判斷一個預測的風險是否事實、是否發生。
進行風險再估計，確保針對某個風險而制定的風險消除活動正在使用。
收集可用于將來進行風險分析的信息。
風險駕馭及監控的策略如下：
與在職人員協商，確定人員流動原因。
在項目開始前，把緩解這些流動原因的工作列入風險駕馭計劃。
項目開始時，要作好人員流動的思想準備，并采取一些措施確保人員一旦離開時，項目仍能繼續。
制定文檔標準，并建立一種機制，保證文檔及時產生。
對所有工作進行細微詳審，使更多人能夠按計劃進度完成自己的工作。
對每個關鍵性技術人員培養后備人員。
在考慮風險成本之后，決定是否采用上述策略。
7.2軟件項目風險追蹤工具
追蹤風險的一個辦法是將風險輸入缺陷追蹤系統中，缺陷追蹤系統能將風險項目標示為已解決或尚未處理等狀態，也能指定解決問題的項目團隊成員，并安排處理順序。可將軟件風險項目依序排列出來，按照缺陷存在的時間與負責者等資料排列。這樣，缺陷追蹤系統就是追蹤風險的工作能更好執行并且不那么單調。
