系統分析員辭職報告

第一篇：系統分析員辭職報告

尊敬的經理：

您好!我是項目的系統分析員haoword，入職以來一直在這個項目參與用户需求調研、負責系統體系結構、功能、性能的分析和總體設計工作等。我錯誤的認為，系統分析是系統分析就是編程，軟件設計，其實我錯了，系統分析應該是管理、引導、戰略發展方向，對於客户需求沒有理解清楚等原因讓我很慚愧，因此我只有引咎辭職。不過我還是要感謝公司對我的栽培，以及同事們的關心，再次謝謝大家。

申請人：haoword

第二篇：如何成為一個好的系統分析員

系統分析員基本功

好的系統分析員都是從優秀的程序員中產生的，堅實的編程功底、豐富的經驗是今後做系統分析的基礎。

沒有對系統本身進行過透徹剖析過，很難領會到其中一些難以言述的 精華。但並不等於好的程序員就能夠 成為好的系統分析員。

合理的知識結構。語言能力、文字表達能力、技術的全面性等是對系 統分析員的基本要求。比如説c/s和3 層開發，如果僅僅對netscape公司的產品熟悉還不夠，還需要了解比如微軟等產品，並且要了解他們中產生歷史,發展思路，技術優劣，以應付各種窮追猛打的提問。但更重要的是，這是你為應用定製技術要求的前提。

系統分析員思想

全局觀念是系統分析員必須具備的觀念。如果系統分析員設計時太注重細節，往往會陷入在某個問題上糾纏不清的泥潭。（93年，我論文指導老師的一席話影響了我隨後幾年對軟件開發的理解----今後計算機會越來越快，多寫幾行代碼少寫代碼無關緊要，最重要的是整體；一開始就錯了，某個部份編得再好，也是沒有用的）

系統分析員要有面向用户的思想。系統分析員應當有能力將自己扮演成用户，來了解要交付的項目看起來想什麼樣式，感覺想什麼，從而瞭解用户的想法並挑選出合理部份去開發。從這個意義上説，系統分析員才能獲得有意義的見解去引導他的開發組成員。系統分析員頭腦 中要對項目結局有一個清楚的認識，並保證項目不偏離方向。系統分析員要有根植於技術，高於技術思考問題的思想。純粹的程序員通常對最終結果考慮的不是很多，當一種新的技術在市場上出現時，他們對能否按時交付的考慮就比較少，而強烈希望他們的計劃能夠建立在 新的技術之上。因此，系統分析員的想法和行動要象一個用户，又要能夠站在技術的高度，成為真正的用户、程序員之間的代言人。

任務難度的預測能力

系統分析員要具備快速的任務難度預測能力以及具備快速確定開發小 組人員構成和任務劃分的能力。（我將這條歸為思想，而不是能力） 昆蟲自然會長出翅膀，而思想卻需要長期的浸潤。要做到這點，需要大量的思考、學習。設計遠比編程重要。當今軟件業的發展，各種開發工具的出現，編程已經不是什麼問題， 程序員的工作某種程度上講是將別人現成的東西拼湊堆砌起來。系統分析員要清楚的認識到，現在大多數程序員沒有學會怎麼去整體的瞭解一個系統，有些甚至不瞭解編程（這不是説他們不會寫代碼）。可視化的開發工具加五花八門的控件，程序員可以偷點懶了。（這可不是誇大，我好幾年的管理工作，接觸過大量的程序員）基於技術，跳出框架。基於現有技術結合用户需求思考問題，設計時跳出框架。

系統分析員的關鍵

獲得信任。系統分析員最重要的素質是獲得信任，這是成為優秀系統 分析員的關鍵。成熟

最為關鍵。成熟可以為整個項目組提供正確的支持,能夠理解技術怎樣才能解決用户的需求。

系統分析員的準備工作

統一的各種文檔模式，這其中包括今後軟件變量、字段命名規則。我推薦用pb制定的規則做基礎，通過改造成為適合自身實用的標準。統一的文檔管理。統一的分析軟件。比如説rose（uml太規範，國內的軟件管理水平根本用不上，只不過儘量應用，你自己對系統分析的理解有好處） 方法是思想的放映，在具體方法上就不多説了。我託人從 u$a弄到幾本書，用於面向對象系統開發的使用》、《面向對象的分析》、《項目管理》等都是很不錯的，推薦大家看看。

我在拙作"在中國沒有人懂計算機"裏發了點牢騷，聽説捱了部份人 （習慣性的）罵。其實，bbs本來就是發泄的地方，在這裏從來就罕有有內容的文章。

自從“維納斯”登陸深圳後，大家更着眼於從宏觀看中國的it業了。中國it這棵小樹，説實在的，長到今天實在是不容易。一些人提出了“反對微軟霸權"的口號，不少人呼喚中國"硅谷"的出現。微軟的成功不是技術的成功，更多的是商業運作的成功。中國it這棵樹能長多高，取決於他所植根於的土壤。而現在的事實是，這片土壤實在是太貧瘠了！如果按我們現在的思路和搞法，是長不成大樹，更別指望能結?quot;微軟”，“硅谷”這樣豐碩的果實。如果説，我們的軟件技術落後美國十年，我們的硬件製造技術則落後美國二十年，我們的管理水平落後美國至少三十年。而最終決定發展速率的恰恰是我們的死穴──低劣的管理水平。低劣的管理水平的形成的原因有着深厚的背景和多方面的原因。

系統分析工作是解決一個問題的工作,目標是將一個對計算機應用系統的需求轉化成實際的物理實現,其中複雜就複雜在實際的面太多.在系統分析過程之中注意問以下的問題,可能會所進行的系統分析設計工作有幫助

1)您所完成的系統目的是什麼?注意不是功能要求,而是目的.也就是為什麼要建設、為什麼要現代建設。在考慮系統目的時，我更多的側重於系統的最終目標考慮，因為一個系統不可能一下子完美，為系統留些餘地。

2）您所完成的系統有哪些方面參與，各方面的初衷是什麼？那些人可能在系統建設中起重要作用，他們會採取什麼樣的態度？你對他們有多少影響力？中國it行業的失敗之一就是

第三篇：計算機系統分析員論文

企業人事信息系統的應用

【摘要】

本文討論《企業人事信息系統》項目的需求分析方法與工具的選用。該系統的建設目標是幫助該企業管理好企業內部的人員和人員的活動，人事信息管理指的是企業員工從招聘面試到離職退休的全過程，涉及的主要活動包括面試、報到、培訓、升職、離職或其他的人事變動，也包括電子化考勤、工資性收入的計算與分發、使用其他公司資源的有關記錄（如宿舍、保險、證件辦理等等）。此外，本系統也涉及到企業在全國各地的人事信息管理，企業的組織架構的設置，級別與職務管理，人力申請直至人力需求報表，從而形成一個對企業真正有用的人事信息管理應用系統。在本文中首先討論了選用面向對象方法與工具的主要理由與策略，進一步通過一個簡例説明該方法與工具使用的效果，也討論了使用多種工具與方法在需求

分析中的必要性，最後簡要小結了選用正確工具與方法的意義和作用。

在項目開展期間，我擔任了系統分析、系統設計與數據庫管理等大量工作。

【正文】

人事信息管理系統是一個有着廣泛應用面的實用性系統，但是，我國各個企業有着自身的體制、機制、特點與不同的要求；在開發這類系統時，系統需求分析是極為重要的一環。在整個分析過程中，我們都採用了面向對象的分析方法，這是因為我們在近幾年的實踐中已堅信這種方法能夠更加有效地表達和描述現

實世界。軟件要具有適用性和擴展性，就必須更接近於現實世界本身的發展規律。

以一個簡單的例子來看，假設要求設計關於引進人才評估的一個系統，按我們過去的做法，先會要求提供給我們一份相關的引進人才評估表，然後依葫蘆畫瓢地設計相應的表單與界面。在短期來説，這樣做是簡便而實用的，但並不能夠符合現實世界的長遠目標，這套設計方法不具有擴展性，因為任何一份評估表的結構都會有可能發生許多改變的。採用面向對象的方法，可以從中提取出表類型、表結構、評分方法以

及能考慮繼承等各方面的要素，這樣就可以保證軟件的通用性，可配置性與可維護性。

在工具的選擇過程中，我們選擇了現在已十分流行的rational系列，包括rational rose、rup、soda等，為什麼選取這個系列工具呢？這是基於我們對軟件需求分析目標的看法，我們認為需求分析應當能正

確地回答如下的幾個關鍵性問題：

（1）用户的需求是否已詳盡地被考慮到了？

（2）用户能理解或明白我們所描述的內容嗎？

（3）分析是否會和設計相脱節，

（4）程序員能明白我們的分析與設計要求嗎？等等。

以下對上述幾個問題逐一簡要地加以説明：

（1）詳盡地獲取用户的需求。

用户的需求可分為顯式的需求與隱性的需求，用户的傾向往往只顧及到當前的與明顯的需求。要達到對需求理解的全面性，不僅僅只是依靠有效的用户談話和調查，因為我們所面對的用户需求往往會有些片面的，採用rational rose（基於uml）提供的用例，以及多種圖的聯合使用，可以使我們發現其中的遺漏。

（2）使用户能充分地理解我們的表示方法，能夠真正明白我們描述的內容。

軟件需求分析規格説明書通常會是宂長而枯燥的，一般的用户不容易深入理解，這樣就削弱了分析的正確性。通過支持面向對象及uml語言的rational rose可以更好地和用户交流，讓用户瞭解系統的運作方

式甚至細節的操作。

（3）使分析和設計兩個階段互相聯繫與貫通。

這是我們選擇面向對象的方法及rational rose工具的重要原因，系統分析要向用户描述的不僅僅是用户的需求，而且包括解決方法，解決方法當然應包括設計（程序）、數據庫與系統配置，我們當然不希望用户得到的是一個與需求規格説明不相同的軟件，也不可能要求程序員完成一個不可勝任的任務。然而我們在以前的多項工作中經常發現這類情節，因為系統分析與設計相互脱節，導致一頭紮在分析中不顧設計

有關的事宜。

分析與設計的脱節，還不利於設計現格説明的評估，因為分析往往會脱離現實，導致缺乏評估的依據。

因為不可能成功地完成設計而使分析需要重來，就會造成巨大的浪費與損失。一個好的工具可以使分析與設計更緊密地連結起來，甚至於—一對應。面向對象的分析方法使對象之間相對而言有獨立性，減少了

任何影響到全局的改動，能避免因需求變化而導致全盤皆動的被動局面。

（4）使程序員明白我們的設計。

一個好的設計應該讓程序員感到清晰明白，更少疑問。一個疑問很多的設計加上溝通不暢，絕對會出現在應用環境下所不需要的另一個軟件，所以設計規格説明書務必清楚、形象與明確，當然，rational rose具有足夠的圖形與其他形式，能使程序員更加明確，甚至能細微到每一個語句（事實上如果使用vb，程序

架構都有可能直接生成了）。

（5）選擇uml可能會有更多的理由。

比如用户文檔的編寫、數據庫設計，我們都需要做到有延續性，有自動化支持和具有質量上的保證。

所以，我們選用了以上的方法和工具。

在分析中，面對考勤班次的問題時，由於過去一直使用紙卡方式考勤，使用户對班次形成了固定的概念，而現在的許多考勤軟件也採用多次刷卡的方法來形成一天的記錄。經過面向對象的分析可以發現，事實上每天的上班記錄是由多個時段所形成的，時段的多少在各個公司，各個工種與部門都不盡相同，每個時段可能有不同的屬性，時段與時段組合可形成為班次，這更適合於現實的情況，使之能更加靈活與更有擴展性。其實，在天與天之間也都有相互之間的關係。在這一點上，我們又發現必須在考勤與薪金工資中加入與mrp中相似的期段（periods）的基本概念，比如可以稱之為考勤期段，允許為用户更加方便地設置考

勤期段，可能使之不一定與自然年月日相同等等。

rational rose使我們更方便地把上面的想法在類上去實現，更進一步地設計好我們的高效率的數據庫。當然，使用單一的一個工具去完成一箇中大型的應用系統的需求分析，是不可能成功的。因為社會在發展，用户的需求也在改變，如何把握住用户的需求是需要時間的，面向對象的方法有時也會忽略外在的與表層的要求，不僅僅是要獲得關鍵的需求，其他更多的需求往往要等到用户在使用後才知道，然而等到用户使用是不現實的，作為原型開發模型中的原型也是收集用户需求，描述與解釋需求的一類相當有效的方

法與工具。

在我們的開發過程中，為了更好地讓用户瞭解我們的系統和我們的設計方案，讓用户在見面會上更有方向性與針對性，我們首先用access開發出原型，讓用户先試用。這樣，我們在真正的分析與設計時就能

更加符合用户的要求。

總之，軟件需求分析方法和工具的使用，對我們軟件開發過程影響是很深遠的，選用高效能的正確的方法與工具，可以使我們的軟件更加正確地反映現實需求，更加具有可用性、可擴展性和可維護性；降低了

軟件項目的風險。

評註：（1）寫得有些特色，觀點鮮明。（2）摘要寫得不錯，既反映了項目內容，也小結了本文的寫作要點。（3）文中所舉的例子雖然簡單，但很實際。（4）多種方法與工具的使用，敍述得簡明扼要。（5）內容可更豐富一些，更深入的例子也可再增多一些，則會更有説服力。（6）對需求分析的全過程的描述太

少。（本文主要參考了廣東延國慶等人的論文）

第四篇：系統分析員級考試大綱

系統分析員級考試大綱

一、考試説明

1. 考試要求

（1）掌握管理科學與系統工程基礎知識

（2）熟悉信息系統開發過程

（3）理解信息系統開發標準

（4）掌握需求分析、系統測試和系統維護基本技術

（5）理解質量保證的手段

（6）掌握計算機硬軟件的基礎知識

（7）理解知識產權的基本知識

（8）掌握組織與管理的基本知識

（9）熟練閲讀和正確理解相關領域的英文文獻

（10）具有大學畢業的數學基礎

（11）熟悉常用的計算方法

2. 通過本級考試的合格人員具有從事計算機應用系統的分析和設計的實際工作能力和業務水平，能指導高級程序員工作。

3. 本級考試的內容包括：

基礎知識（系統分析員）；

計算機應用系統的分析設計；

對相關專題的論述。

二、考試範圍

（一）計算機應用系統的分析與設計能力

1. 系統計劃 系統項目的提出與選擇可行性研究與效益分析定義問題與歸結模型（目標、功能、性能等）系統方案的制定、評價和改進新舊系統的分析和比較所需資源估計現有軟件、硬件和數據資源的有效利用流行的系統分析方法論系統分析的實用技術

2. 應用軟件需求分析與定義 現有軟件系統的分析需求調查與分析可行性研究確認測試計劃流行的需求分析方法論

3. 系統設計 處理流程設計系統人機界面設計系統的文件設計數據庫管理系統的選擇與數據庫設計網絡環境下的計算機應用系統的設計簡單的分佈式計算機應用系統的設計系統運行設計系統處理能力的估計和評價系統過渡計劃

4. 軟件設計 界面設計概要設計測試計劃設計評審

5. 軟件測試 系統測試測試結果的評價確認測試 6. 軟件維護 軟件維護作業的實施和管理 7. 系統的可靠性分析與設計 系統的故障模型和可靠性模型系統的可靠性分析和可靠度計算提高系統可靠性的措施系統的故障對策與系統恢復 8. 系統的安全性和保密性設計 系統的訪問控制技術數據的完整性數據與文件的加密通信的安全性系統的安全管理 9. 文檔編制 可行性研究報告項目開發計劃需求規格説明書數據要求規格説明書用户手冊操作手冊測試計劃、測試分析報告技術報告開發進度記錄項目開發總結報告10. 質量保證 軟件質量設計軟件質量管理軟件質量評價11. 系統的運用 系統的軟硬件配置管理系統的使用效率基本軟件和軟件包的引入、應用、管理和二次開發系統的擴充和集成操作設計和運行管理系統的更新與維護長期計劃和短期計劃新舊系統的轉換交接日常的故障對策與恢復系統的日常安全管理系統的服務質量12. 項目管理 項目計劃進度管理人員管理費用管理軟硬件和數據資源的計劃與管理項目環境管理與用户的協作標準化管理版本管理項目管理工具項目管理信息庫項目管理體制（二） 軟件知識 1. 程序語言 · 種類語言的歷史、特點和適用範圍 2. 操作系統 ·操作系統的類型結構，系統的並行機制，文件組織，系統性能評價 3. 數據庫系統 數據庫管理系統的類型、結構和性能評價常用的關係型數據庫管理系統圖形和圖象數據庫工程數據庫 4. 軟件工程 軟件需求分析與定義軟件設計軟件測試軟件維護軟件質

量保證及軟件質量評價軟件複用原型化方法文檔編制標準 5. 計算機輔助軟件工程（case） 常用的軟件開發工具軟件工程支撐環境分佈式軟件開發環境 6. 軟件工程新技術和新方法 智能軟件工程支撐環境函數型程序設計的概念邏輯型程序設計的概念面向對象型程序設計的概念 7. 計算機應用系統的安全與保密 8. 軟件的知識產權保護 9. 軟件標準化10. 軟件的產品化與軟件商情 （三） 硬件知識 1. 計算機組成與體系結構 構成計算機的各部件的功能及相互關係各種體系結構的特點與應用計算機體系結構的發展2. 存儲器與外圍設備 各類存儀器的功能、特性和使用多級存儲器與虛擬存儲器各類外圍設備的功能、特性和使用輸入/輸出接口和控制方法總路線結構3. 數據通信與計算機網絡 數據通信的基本知識開放系統互連參考模型常用的協議標準計算機網絡的分類應用4. 多媒體系統結構 5. 安全性與可靠性技術 數據安全與保密故障測試與定位容錯技術可靠性模型與分析技術6. 系統配置與性能評價 系統選型與配置模擬（simulation）與仿真（emulation）系統模型和分析技術典型測試程序（benchmark）其它的系統評價方法7. 與軟件的關係 （四）其它基礎知識 1. 專業英語 具有大學畢業程度的英文詞彙量能熟練閲讀和正確理解相關領域的英文科技文獻2. 數學 微積分線性代數：行列式、矩陣和線性方程組概率統計：事件和概率、隨機變量和分佈函數、數字特徵、參數估計和假設檢驗離散數學：數理邏輯、集合論、圖論、組合分析、形式語言與自動機初步數值計算：計算誤差，數值微分與積分，函數插值和逼近，方程的數值解算法複雜性3. 管理科學與系統工程基礎 規劃論、對策論（game theory）、決策論（decision theory）、排隊論系統工程原理系統模型與模擬系統評價

第五篇：系統分析員論文的解答方法

系統分析員論文的解答方法

1.論文試題的目的

論文試題是系統分析員級考試的重要組成部分。它的目的是：

(1) 檢查應試者是否具有參加軟件項目工作的實踐經驗。原則上，不具備實踐經驗的人達不到系統分析員級水平，不能取得系統分析員級的資格。

(2) 檢查應試者分析問題與解決問題的能力，應試者的獨立工作能力。在實際工作中，由於情況千變萬化，作為系統分析員應能把握項目進展情況，發現和分析問題，提出解決問題的對策。在這方面對系統分析員有很高的要求。

(3) 檢查應試者的表達能力。出於軟件文檔是軟件的重要組成部分，並且在軟件開發過程中還要編寫不少工作文擋和報告，文檔的編寫能力很重要。系統分析員作為項目組的負責人或核心成員，要善於表達自己的思想。在這方面要注意抓住要點，重點突出，用詞準確，易讀，易理解。

2.論文試題的特點

根據以上所述，下午論文試題的目的不是考知識(屬上午試題的範圍)，也不是考一般的分析和解決問題的能力(屆下午試題i的範圍)，而是考應試者在軟件系統開發和維護方面的經驗和綜合能力，以及表達能力。論文試題的持點是：

(1) 試題的內容：

為了使考試具有科學性和公正性，試題內容都是軟件開發和維護工作中的具有共性的問題。也就是説，都是通用性問題，與具體的軟件應用領域無關。不論開發什麼樣的軟件都可能遇到這些問題。

例如，1990年度的試題是：成本／效益分析，軟件維護，文檔編制，軟件複用；1991年度的試題是：快速原型技術，系統測試，系統的可靠性，系統的可修改性；1992年度的試題是：軟件排錯，軟件項目的進度管理，面向對象的需求分析或設計，系統的安全與保密控制。在此之前的**年度的試題是：數據庫的設計，軟件開發中的質量管理，信息系統的使用的方便性，系統的集成。

(2) 試題的格式：

系統分析員的論文從性質上説是“業務報告論文”，與通常的學術論文不同。考慮到業務報告論文的特點併為了實現科學評分，論文試題採取統一的格式。

每個試題由兩部分組成，即概述和問題。

① 概述；背景內容和意義。

② 問題：根據實際經驗回答三個問題：

問題1簡要敍述你參與的軟件項目的概要和你所擔任的工作。

問題2具體敍述你作了哪些有關工作?遇到了什麼問題?為了解決這些問題，採取過哪些措施?

問題3簡要敍述你所採取的措施的效果如何?你現在認為還有哪些需要改進的地方?如何改進?

3.論文試題的解答方法

(1) 選擇合適的試題。

選擇試題時應該選擇自己熟悉的內容。有多個試題可選時，要果斷，不要猶豫不決。

(2) 解答時要抓作要點。

試題的要點有：

① 參加的項目的題目和概況(功能，性能等)。}

② 你擔任的工作。}問題1

③ 工作的具體內容。}

④ 遇到的問題。}問題2

⑤ 解決問題的措施。}

⑥ 措施的效果。}

⑦ 需進一步改進的問題，以及如何改進。}問題3

上述幾點都是必不可少的。

(3) 要有具體內容。

解答時，切忌泛泛而談，一定要言之有物。最好有些“土香氣”，令人感到可信，不要給人以“死記硬背”的印象。

特別注意要突出表明是“你”自己做的，而不是別的什麼人做的。語氣要自信，要有自己的觀點。

(4) 注意字數。

論文試題對字數有嚴格的要求。字數不能太多(不能超過3000字)，也不能太少(不能少於2000字)。字數分配要合理，要適合內容的要求。

由於時間較緊，—般字數不會超過3000字，但常有不到2000字的情況。字數過少通常是因為缺乏實踐，或者是因為不善於虛實結合，因而寫出的內容空洞、抽象、枯燥。

(5) 內容要切題。

在(2)中所列的要點，都要緊緊圍繞試題指定的範圍去寫，千萬不要離題發揮，或者寫些無關的東西，這會給人硬湊字數的感覺，因而被扣分。

(6) 要符合邏輯。

論文中的論點應該有事實依據，要有説服力。要注意條理清晰，前後呼應，不要自相矛盾。

(7) 結構化。

論文由摘要和正文兩大部分組成，正文又可分為3個部分(即3個問題)。各個部分的篇幅比例要適當，不要平均分配。建議正文的3個部分的字數儘可能控制在如下範圍內。

問題1 600—700字

問題2 1100—1300字

問題3 500—600字

當然，篇幅的長短和比例要服從內容的需要。以上數字僅供參考。

為了提高論文的易讀性，正文最好適當加些小標題，要適當分段(每個段不要太長)。

(8) 要寫好摘要。

摘要是論文非常重要的組成部分，不能輕視。摘要應該概括地反映正文的全貌，要引人入勝，要給人一個好的初步印象。

摘要是用來檢查應試者概括、歸納和抽象能力的，在解答時不能把它當作可有可無的東西。

摘要可以先寫，也可以在寫完正文之後寫。

切記摘要中不能有圖表，不能寫成分條式的提綱，更不要寫成目錄的形式。字數不能少於200字。

(9) 要提出尚存在的問題。

論文的第3部分很重要。提不出尚存在的問題，往往是因為缺乏實踐經驗．或者是因為容易滿足現狀，不能清晰地認識問題，因而故步自封。這是缺乏系統分析員素質的表現。

(10) 要注意整潔。

字跡要端正。要想好再寫，不要有太多的刪改。整潔的程度也會影響得分。 最後，再説一下如何分配論文考試的120分鐘時間的問題。作為參考，可以考慮如下方案：

選題 5分鐘

擬提綱 10分鐘

寫摘要 10分鐘

寫正文 80分鐘

檢查修改15分鐘

試題一 論項目的風險管理

寫作要點：

1、介紹項目的背景、發起單位、目的、項目週期、交付的產品等，着重介紹項目的風險管理；介紹自己擔任的工作及需要處理的問題。

2、項目是在複雜的自然和社會環境中進行的，受眾多因素的影響。對於這些內外因素，從事項目活動的主體往往認識不足或者沒有足夠的力量加以控制。項目的過程和結果常常出乎人們的意料，有時不但未達到項目主體預期的目的，反而使其蒙受各種各樣的損失；而有時又會給他們帶來很好的機會。項目同其它經濟活動一樣帶有風險。要避免和減少損失，將威脅化為機會，項目主體就必須瞭解和掌握項目風險的來源、性質和發生規律，進而實行有效的管理。

項目風險是一種不確定的事件或條件，一旦發生，會對項目目標產生某種正面或負面的影響。風險有其成因，同時，如果風險發生，也導致某種後果。當事件、活動或項目有損失或收益與之相聯繫，涉及到某種或然性或不確定性和涉及到某種選擇時，才稱為有風險。以上三條，每一個都是風險定義的必要條件，不是充分條件。具有不確定性的事件不一定是風險。

項目風險管理的基本過程包括下列活動：

?風險管理計劃編制過程。風險管理計劃編制過程描述如何為項目處理和執行風險管理活動。

?風險識別。風險識別的目標是識別和確定出項目究竟有哪些風險，這些項目風險究竟有哪些基本的特性，這些項目風險可能會影響項目的哪些方面。

?風險定性分析。風險定性分析包括對已識別風險進行優先級排序，以便採取進一步措施，如進行風險量化分析或風險應對。

?定量風險分析。定量風險分析過程定量地分析風險對項目目標的影響。它對不確定因素提供了一種量化的方法，以幫助我們做出儘可能恰當的決策。

?風險應對計劃編制。風險應對通過開發備用的方法、制定某些措施以便提高項目成功的機會，同時降低失敗的威脅。

?風險監控。風險監控跟蹤已識別的危險，監測殘餘風險和識別新的風險，保證風險計劃 的執行，並評價這些計劃對減輕風險的有效性。

3、信息系統項目所面臨的風險及其產生原因和應對措施

例如：

? 風險：沒有正確理解業務問題

產生原因：項目干係人對業務問題的認識不足、計算起來過於複雜、不合理的業務壓力、不現實的期限

解決辦法：用户教育、系統所有者和用户的承諾和參與

? 風險：客户不能恰當地使用系統

產生原因：信息系統沒有與組織戰略相結合、對用户沒有做足夠的解釋解決辦法：用户的定期參與、項目的階段交付

? 風險：拒絕需求變化

產生原因：固定的預算、固定的期限、決策者對市場和技術缺乏正確的理解解決辦法：變更管理、應急措施

? 風險：對工作的分析和評估不足

產生原因：缺乏項目管理經驗、工作壓力過大、對項目工作不熟悉解決辦法：採用標準技術

? 風險：人員流動

產生原因：不現實的工作條件、較差的工作關係，缺乏對職員的長遠期望解決辦法：保持好的職員條件、確保人與工作匹配、保持候補、外購? 風險：缺乏恰當的技術工具

產生原因：技術經驗不足、缺乏技術管理準則、技術人員的市場調研或對市場的理解有誤、研究預算不足

解決辦法：預先測試、教育培訓、替代工具

? 風險：缺乏合適的技術實施人員

產生原因：對組織架構缺乏認識、缺乏中長期的人力資源計劃、組織不重視技術人才和技術工作

解決辦法：外購、招募、培訓

? 風險：缺乏合適的技術平台

產生原因：缺乏長期遠見、沒有市場和技術研究、團隊龐大陳舊難以轉型、缺乏預算

解決辦法：全面評估、推遲決策

? 風險：技術陳舊過時

產生原因：缺乏技術前瞻人才、輕視技術、缺乏預算

解決辦法：延遲項目、標準檢測、前期研究