时间：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软件项目风险追踪工具
追踪风险的一个办法是将风险输入缺陷追踪系统中，缺陷追踪系统能将风险项目标示为已解决或尚未处理等状态，也能指定解决问题的项目团队成员，并安排处理顺序。可将软件风险项目依序排列出来，按照缺陷存在的时间与负责者等资料排列。这样，缺陷追踪系统就是追踪风险的工作能更好执行并且不那么单调。
