第一篇：系统分析员辞职报告
尊敬的经理：
您好!我是项目的系统分析员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、信息系统项目所面临的风险及其产生原因和应对措施
例如：
? 风险：没有正确理解业务问题
产生原因：项目干系人对业务问题的认识不足、计算起来过于复杂、不合理的业务压力、不现实的期限
解决办法：用户教育、系统所有者和用户的承诺和参与
? 风险：客户不能恰当地使用系统
产生原因：信息系统没有与组织战略相结合、对用户没有做足够的解释解决办法：用户的定期参与、项目的阶段交付
? 风险：拒绝需求变化
产生原因：固定的预算、固定的期限、决策者对市场和技术缺乏正确的理解解决办法：变更管理、应急措施
? 风险：对工作的分析和评估不足
产生原因：缺乏项目管理经验、工作压力过大、对项目工作不熟悉解决办法：采用标准技术
? 风险：人员流动
产生原因：不现实的工作条件、较差的工作关系，缺乏对职员的长远期望解决办法：保持好的职员条件、确保人与工作匹配、保持候补、外购? 风险：缺乏恰当的技术工具
产生原因：技术经验不足、缺乏技术管理准则、技术人员的市场调研或对市场的理解有误、研究预算不足
解决办法：预先测试、教育培训、替代工具
? 风险：缺乏合适的技术实施人员
产生原因：对组织架构缺乏认识、缺乏中长期的人力资源计划、组织不重视技术人才和技术工作
解决办法：外购、招募、培训
? 风险：缺乏合适的技术平台
产生原因：缺乏长期远见、没有市场和技术研究、团队庞大陈旧难以转型、缺乏预算
解决办法：全面评估、推迟决策
? 风险：技术陈旧过时
产生原因：缺乏技术前瞻人才、轻视技术、缺乏预算
解决办法：延迟项目、标准检测、前期研究