软件工程-风险管理
软件工程管理方法
软件工程管理方法软件工程管理方法是指在软件开发过程中，对项目进行有效管理和控制的一系列方法和技术。
它主要包括项目计划、需求管理、风险管理、进度管控、质量管理等方面。
本文将结合实际经验，对软件工程管理方法进行详细介绍。
首先，项目计划是软件工程管理中的关键环节。
一个好的项目计划可以有效规划资源，提前预知项目进展，及时调整任务优先级和安排工作量。
在项目计划中，需要包括需求分析、产品设计、编码和测试等阶段的时间和资源分配。
此外，还需要制定详细的里程碑和交付时间，以便跟踪项目的进展情况。
另外，需求管理也是软件工程管理中的重要内容。
需求管理包括需求获取、需求分析和需求确认等环节。
需求获取阶段，需要与项目干系人进行沟通，了解他们的需求和期望。
在需求分析阶段，需要将需求转化为详细的需求规格说明书，并进行评审和确认。
需求管理的目标是确保项目能够满足干系人的期望和需求。
风险管理是软件工程管理中的一个重要环节。
项目中可能会遇到各种风险，如技术风险、沟通风险、进度风险等。
在风险管理中，需要对可能出现的风险进行识别、评估和监控，并采取相应的措施进行应对。
这些措施可以包括风险规避、风险转移、风险缓解等。
风险管理的目标是降低项目失败的风险，确保项目能够按时、按质地完成。
进度管控是软件工程管理中的关键环节。
在项目执行过程中，需要不断跟踪项目进度，确保项目按计划进行。
进度管控包括制定和更新项目进度计划、监控和调整项目进度等。
在进度管控中，可以使用甘特图、里程碑图等工具，帮助团队成员理解项目的进展情况，及时进行协调和调整。
最后，质量管理是软件工程管理中的一项重要工作。
质量管理包括制定和执行质量计划、进行质量评审和测试、进行缺陷分析和改进等。
在质量管理中，需要建立良好的质量文化，培养团队成员的质量意识。
同时，需要使用适当的工具和方法，提高项目的质量水平。
综上所述，软件工程管理方法是软件开发过程中不可或缺的一环。
通过项目计划、需求管理、风险管理、进度管控和质量管理等方面的有效管理，可以帮助项目顺利进行，保证项目的高质量完成。
软件工程中的软件项目风险识别与应对
软件工程中的软件项目风险识别与应对软件工程项目的成功与否往往受到许多风险因素的影响。
因此，在软件项目的计划和实施过程中，风险管理是一个至关重要的环节。
本文将探讨软件工程中的软件项目风险识别与应对的方法和策略。
一、风险识别风险识别是软件项目风险管理的第一步，只有找到风险，才能有针对性地进行应对。
以下是一些常见的软件项目风险：1. 人员变动风险：例如项目组成员离职、缺乏相关技能的人员加入等，可能导致项目进度延迟或者质量下降。
2. 需求变更风险：客户需求的频繁变更会给项目带来很大的不确定性，可能导致项目计划无法按时完成。
3. 预算不足风险：预算不足可能导致项目无法按时交付或者降低项目的质量。
4. 技术风险：新技术的使用、技术难题的解决等都可能给项目带来一定的风险。
识别风险的方法可以采用头脑风暴、需求分析、经验总结等。
在项目启动阶段，可以组织专家会议或者借鉴类似项目的经验，以识别可能的风险。
二、风险评估风险评估是对已经识别到的风险进行评估和排序，确定其对项目的影响程度和发生概率。
评估风险可以采用专家评估、统计数据分析等方法。
常用的评估方法有风险概率和影响矩阵、风险等级划分等。
在评估风险时，可以根据风险发生的可能性和影响程度进行排序，以确定应对风险的优先级。
高概率高影响的风险往往需要重点关注和应对。
三、风险应对策略针对不同的风险，需要采取相应的应对策略。
以下是一些常见的风险应对策略：1. 人员变动风险：建立一个稳定的项目团队，并进行项目经验的积累和共享，以降低人员变动的风险。
2. 需求变更风险：在项目启动之前，与客户充分沟通和协商，明确项目的目标和需求，尽量减少需求的变更。
3. 预算不足风险：合理评估项目成本，并与客户进行充分沟通，明确项目预算和交付标准。
4. 技术风险：及早评估和解决技术难题，对新技术进行充分的研究和测试，确保其在项目中的稳定性和可靠性。
此外，还可以采用风险转移、风险规避、风险接受等策略，根据具体情况进行选择。
软件工程中的项目控制与风险管理(一)
软件工程中的项目控制与风险管理随着科技的不断进步和信息化时代的到来，软件工程作为一门重要的学科在如今的社会中扮演着举足轻重的角色。
然而，在软件开发过程中，项目的控制和风险管理始终是困扰着软件工程师的难题。
本文将围绕这一主题展开讨论。
一、项目控制的重要性及目标项目控制在软件工程的实践中起着至关重要的作用。
它有助于确保项目按时、按质、按预算完成。
项目控制的目标有三个方面：首先，经济目标。
软件项目开发通常需要投入大量的资源，包括人力、时间和资金。
项目控制的一项重要目标是确保这些资源的合理利用，避免浪费和不必要的投入。
其次，质量目标。
软件工程所开发的产品需要具备高质量、高可靠性，以满足用户的需求。
项目控制的一个重要目标是确保软件开发的各个阶段都能够达到预定的质量标准。
最后，风险目标。
软件项目在开发过程中会面临各种风险，例如需求变更、技术难题等。
项目控制的目标之一是及时发现并解决这些风险，以避免对项目进展产生不利影响。
二、项目控制的方法与技巧项目控制需要采用科学合理的方法和技巧。
以下是几个常用的项目控制方法：1.进度管理。
项目进度管理是确保项目按时完成的关键因素。
软件项目一般可采用甘特图、里程碑计划等工具进行进度管理，以便管理者清晰了解各个任务的完成情况。
2.资源管理。
软件项目需要合理分配人力和物力资源，以保障项目的顺利进行。
资源管理需要根据项目需求和资源可用性进行调配，确保资源的最佳使用效果。
3.团队合作与沟通。
软件开发过程中的沟通与合作是至关重要的，项目管理者需要建立良好的团队合作氛围和沟通机制，以确保团队成员的工作进展和问题解决。
三、风险管理的重要性与策略风险管理是项目管理中至关重要的一环。
风险管理的目标是识别、评估和应对项目中的各种风险，以最大程度地减少或避免对项目的不利影响。
风险管理的策略主要包括以下几个方面：1.风险识别。
项目管理者需要全面了解项目可能面临的各种风险，并及时进行识别和记录。
例如，技术风险、需求风险等。
软件工程项目管理方法
软件工程项目管理方法软件工程项目管理是指在软件开发过程中，通过采用系统的方法和工具，对软件开发项目进行计划、组织、领导、控制和协调，以实现项目目标的过程。
以下是一些常见的软件工程项目管理方法：生命周期管理：将软件开发过程划分为不同的阶段，如需求分析、设计、编码、测试和维护等，并在每个阶段进行详细的计划和监控，以确保项目按时完成，达到预期的质量标准。
风险管理：识别和评估软件开发过程中可能出现的风险，并制定相应的措施来应对这些风险，如制定备选方案、进行风险缓解和监控等。
质量管理：在软件开发过程中，通过采用质量保证方法和工具，对软件产品进行测试、审核和评估，以确保软件产品符合预期的质量标准和质量要求。
变更管理：在软件开发过程中，对变更进行管理和控制，以确保变更不会对项目进度和质量产生不利影响。
沟通管理：在软件开发过程中，通过建立有效的沟通机制和渠道，确保项目团队成员之间的信息交流和协作，以保证项目顺利进行。
成本管理：对软件开发项目进行成本预算和成本控制，以确保项目成本不超过预算，并尽可能地降低成本。
人力资源管理：在软件开发过程中，合理分配人力资源，并通过对员工进行培训和发展，提高员工技能和工作效率。
风险管理：在软件开发过程中，通过采用风险识别、评估、缓解和监控等方法，降低项目风险。
版本控制管理：在软件开发过程中，对代码、文档和其他资源进行版本控制，以确保多人协同开发时的一致性和准确性。
配置管理：在软件开发过程中，对项目文档、代码和其他资源进行配置管理，以确保项目开发和维护过程中的一致性和可追溯性。
以上是一些常见的软件工程项目管理方法，但不同的项目和组织可能会有不同的管理方法和工具。
在具体的项目管理过程中，需要根据项目的实际情况和需求选择合适的管理方法和工具。
软件项目风险管理(风险识别、预测、评估、缓解、监控)
软件项目风险管理一、风险管理概述软件风险是指软件开发过程中及软件产品本身可能造成的伤害或损失。
风险关注未来的事情，这意味着，风险涉及选择及选择本身包含的不确定性，在软件开发过程及软件产品都要面临各种决策的选择。
风险是介于确定性和不确定性之间的状态，是处于无知和完整知识之间的状态。
另一方面，风险将涉及思想、观念、行为、地点等因素的改变。
当在软件工程领域考虑风险时，我们要关注以下的问题：什么样的风险会导致软件项目的彻底失败？用户需求、开发技术、目标计算机、以及所有其它与项目有关的因素的改变将会对按时交付和总体成功产生什么影响？对于采用什么方法和工具，需要多少人员参与工作的问题，我们如何选择和决策？对软件质量要达到什么程度才是“足够的”？当没有办法消除风险，甚至连试图降低该风险也存在疑问时，这些风险就是真正的风险了。
在我们能够标识出软件项目中的真正风险之前，识别出所有对管理者和开发者而言均为明显得风险是很重要的。
二、被动和主动的风险策略被动风险策略是针对可能发生的风险来监督项目，直到它们变成真正的问题时，才会拨出资源来处理它们，更普遍的是，软件项目组对风险不闻不问，直到发生了错误才赶紧采取行动，试图迅速地纠正错误。
这种管理模式常常被称为“救火模式”。
当补救的努力失败后，项目就处在真正的危机之中了。
对于风险管理的一个更聪明的策略是主动式的。
主动策略早在技术工作开始之前就已经启动了――标识出潜在地风险，评估它们出现的概率及产生的影响，对风险按重要性进行排序，然后，软件项目组建立一个计划来管理风险。
主动策略风险管理的主要目标是预防风险。
但是，因为不是所有的风险都能够预防，所以，项目组必须建立一个应付意外事件的计划，使其在必要时能够以可控的及有效的方式作出反应。
三、软件风险1、软件风险包含两个特征：不确定性——刻划风险的事件可能发生也可能不发生，没有100％发生的风险。
损失——如果风险变成了现实，就会产生恶性后果或损失。
软件项目风险管理基本内容
软件项目风险管理基本内容1软件项目风险管理定义软项目的风险管理工作是软专案管理工作的主要部分。
据大量统计资料证明，进行有效的风险管理工作是降低在软项目发展过程中损失的最主要手段。
软件风险管理产生于上世纪末，有近三十年的发展史。
在软件风险管理工作中，人们主要借助项目的管理方式，来处理软件项目发展中的风险问题，对软件风险管理概念的认识源于对其他项目的企业风险管理经验，并在此基础上进行了探讨与完善。
因此，指软件项目风险管理，也就是项目团队通过风险辨识、风险度量和风险管理，利用不同的管理方式、技能和工具，合理地监控和管理在软件项目中涉及的不同风险，从而主动最大化机会，把重大风险事件所造成的不良结果的威胁减至或最小化。
实现以最低成本安全地实施项目，并达到项目的总体目标。
2软件项目风险的特点软件项目管理的风险源于软件项目本身的特点：(1)软件产品都是看不见的，所以很难判断开发进度和软件产品品质是否符合，因此很难捕捉到软件的管理；(2)在软件的生成过程中不是绝对合理的过程形式。
不同的软件开发项目都需要选择不同的或有针对性的软件开发流程，而真正适用的软件开发流程也只能在软件项目开发完毕后才被掌握。
所以，在项目开发之初，我们就可以针对所选择项目特性和开发经验，熟悉软件开发流程，并在开发过程中不断调整；(3)大型软件建设项目通常是一次的，很少有任何地方能够总结以往的成功经验。
避免和控制软件管理风险的唯一方法就是构建一个监测体系，以实现更高效的风险监测与管理工作。
3软件项目风险的分类软件公司的风险只体现在如下四大层面：需求、产品、成本和时间。
软件项目研发中最常见的问题包括：3.1需求风险(1)需求已成为该项目的基准，但需求仍在不断变化；(2)需求定义不好，另一个定义将扩大项目的范围；(3)添加附加要求；(4)产品定义中不明确的部分花费的时间比预期的要长；(5)客户对需求创建的参与不足；(6)缺乏有效的需求变化管理。
3.2计划编制风险(1)公司规划、资源和产品等概念，都根据客户或高管的口头说明，而并不一致；(2)本计划已经优化并达到了最佳状态，但该规划并不现实，只能被视为预期状态；(3)该计划基于特定团队成员的使用，而该特定团队成员不能真正依赖它；(4)产品大小（代码行数、功能点、占以前产品大小的百分比）大于估计值；(5)实际任务的完成时间较预计中提早，且产品范围及可用资源并未随之调整；(6)参与陌生领域的开发，在设计和实施上花费比预期更多的时间成本。
软件工程中的软件项目风险分析与控制
软件工程中的软件项目风险分析与控制软件项目风险是指在软件项目开发过程中可能导致项目失败或无法达到预期目标的潜在问题。
对于软件开发项目而言，风险是不可避免的，因此对软件项目风险进行分析与控制是确保项目成功的关键。
本文将从软件项目风险的确定、分析和控制三个方面展开讨论。
一、软件项目风险的确定软件项目风险的确定是在软件项目开发过程中，对可能存在的风险进行准确定位。
以下是常见的软件项目风险：1. 技术风险：包括技术选型与使用、技术难题解决、软件工具与框架可行性等方面的风险。
2. 人员风险：包括人员配备不足、人员能力匹配度低、人员离职等方面的风险。
3. 进度风险：包括项目进度延误、开发工期不合理、里程碑无法达到等方面的风险。
4. 成本风险：包括项目预算超支、资源利用效率低、需求变更带来的额外成本等方面的风险。
5. 管理风险：包括沟通不畅、决策不当、项目管理工具失灵等方面的风险。
二、软件项目风险的分析软件项目风险的分析是对确定的风险进行细化、评估和排序。
以下是软件项目风险分析的步骤：1. 风险细化：将确定的风险进行具体描述，并分析风险发生的可能性和影响程度。
2. 风险评估：根据风险的可能性和影响程度，对风险进行定量或定性评估。
3. 风险排序：根据风险评估的结果，将风险按照优先级进行排序，确定风险应对的顺序。
4. 风险响应策略：根据风险的优先级和特征，确定相应的风险响应策略，包括风险避免、减轻、转移和接受等策略。
三、软件项目风险的控制软件项目风险的控制是根据风险分析的结果，采取相应的措施来降低风险的发生概率或影响程度。
以下是软件项目风险控制的方法：1. 风险规避：在项目计划和执行阶段预测和规避可能的风险。
2. 风险缓解：通过合理分配资源、优化任务分工、采用成熟的技术和工具等方式降低风险的影响。
3. 风险转移：将风险转交给第三方，通过外包、保险等方式降低项目风险。
4. 风险接受：对一些风险进行合理的接受和管理，对于低影响程度或低概率的风险，可以选择接受而不采取特殊措施。
软件工程中的项目风险管理与应对策略
软件工程中的项目风险管理与应对策略在软件工程中，项目风险管理起着至关重要的作用。
随着项目的复杂性和规模的增加，项目风险也不可避免地出现。
有效的项目风险管理可以提前识别和应对潜在的风险，保障项目的顺利进行和成功交付。
本文将探讨软件工程中的项目风险管理和应对策略。
一、项目风险的分类在软件开发过程中，项目风险可分为以下几类：1.技术风险：包括技术选型不当、技术难题、技术人员能力不足等。
2.进度风险：包括项目进展缓慢、进度延误、资源不足等。
3.需求风险：包括需求变更、需求不明确、用户对软件功能预期不符等。
4.质量风险：包括软件缺陷、系统稳定性差、性能不足等。
5.人员风险：包括人员流动、人员能力不匹配、沟通合作困难等。
二、项目风险管理流程为了有效管理软件项目中的风险，可以采取以下流程：1.风险识别：通过充分分析项目的各个方面，识别潜在的风险因素。
可以借助SWOT分析、头脑风暴等方法，将想象的可能风险一一列举出来。
2.风险评估：对已经识别的风险进行评估，确定风险的概率和影响程度。
可以采用定性分析和定量分析相结合的方法，依据历史数据和专家经验进行评估。
3.风险优先级排序：根据风险的概率和影响程度，对风险进行优先级排序。
将高概率和高影响的风险列为重点关注对象。
4.风险应对策略制定：针对每个风险，制定相应的应对策略。
常见的应对策略包括：避免风险、减轻风险、转移风险和接受风险。
具体策略可以根据风险的特点和项目情况来确定。
5.风险控制与监控：在项目开发过程中，密切关注已识别的风险并采取相应的控制措施。
持续监控风险的变化，及时调整应对策略。
三、项目风险应对策略针对不同类型的项目风险，可以采取不同的应对策略：1.技术风险应对：建立完善的技术评估机制，确保选择合适的技术方案；提供培训和学习机会，提高技术人员的能力；与技术专家合作，解决技术难题。
2.进度风险应对：制定详细的项目计划，合理安排资源；提前做好风险评估，制定应急计划；建立团队沟通机制，及时解决进度方面的问题。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
风险管理引言风险是关注未来将要发生的事情。
今天和昨天已不再被关心，如同我们已经在收获由我们过去的行为所播下的种子。
问题是：我们是否能够通过改变我们今天的行为，而为一个不同的、充满希望的、更美好的明天创造机会。
其次，这意味着，风险涉及改变，如思想、观念、行为、或地点的改变……第三，风险涉及选择及选择本身所包含的不确定性。
因此，就象死亡和税收一样，风险是生活中最不确定的元素之一。
当在软件工程领域考虑风险时，Charette的三个概念定义是显而易见的。
未来是我们所关心的——什么样的风险会导致软件项目彻底失败呢？改变也是我们所关心的——用户需求、开发技术、目标计算机、以及所有其他与项目相关的因素的改变将会对按时交付和总体成功产生什么影响呢？最后，我们必须抓住选择机会——我们应该采用什么方法及工具？需要多少人员参与工作？对质量的要求要达到什么程度才是“足够的”？Peter Drucker［DRU75］曾经说过：“当没有办法消除风险，甚至连试图降低该风险也存在疑问时，这些风险就是真正的风险了”。
在我们能够标识出软件项目中的“真正风险”之前，识别出所有对管理者及开发者而言均为明显的风险是很重要的。
1.1 被动和主动的风险策略被动风险策略被戏称为“印地安那·琼斯学派的风险管理”［THO92］。
印地安那·琼斯在以其名字为影片名的电影中，每当面临无法克服的困难时，总是一成不变地说：“不要担心，我会想出办法来的！”。
印地安那·琼斯从不担心任何问题，直到它们发生，再做出英雄式的反应。
遗憾的是，一般的软件项目管理者并不是印地安那·琼斯，且软件项目组的成员也不是他的可信赖的伙伴。
大多数软件项目组还是仅仅依赖于被动风险策略。
被动策略最多不过是针对可能发生的风险来监督项目，直到它们变成真正的问题时，才会拨出资源来处理它们。
更普遍的情况是，软件项目组对于风险不闻不问，直到发生了错误，这时，项目组才赶紧采取行动，试图迅速地纠正错误。
这常常被称为“救火模式”。
当这样的努力失败后，“危机管理”［CHA92］接管一切，这时项目已经处于真正的危机中了。
对于风险管理的一个更聪明的策略是主动式的。
主动策略早在技术工作开始之前就已经启动了。
标识出潜在的风险，评估它们出现的概率及产生的影响，且按重要性加以排序，然后，软件项目组建立一个计划来管理风险。
主要的目标是预防风险，但因为不是所有的风险都能够预防，所以，项目组必须建立一个意外事件的计划，使其在必要时能够以可控的及有效的方式作出反应。
在本章其余部分，我们将讨论风险管理的主动策略。
1.2 软件风险虽然对于软件风险的严格定义还存在很多争议，但在风险中包含了两个特性这一点上是已达成了共识的［HIG95］：·不确定性——刻划风险的事件可能发生也可能不发生；即，没有100％发生的风险（100％发生的风险是加在项目上的约束）。
·损失——如果风险变成了现实，就会产生恶性后果或损失。
进行风险分析时，重要的是量化不确定性的程度及与每个风险相关的损失的程度。
为了实现这点，必须考虑不同类型的风险。
项目风险威胁到项目计划。
也就是说，如果项目风险变成现实，有可能会拖延项目的进度，且增加项目的成本。
项目风险是指潜在的预算、进度、人力（工作人员及组织）、资源、客户、及需求等方面的问题以及它们对软件项目的影响。
在第5章中，项目复杂性、规模、及结构不确定性也被定义为项目（估算）风险因素。
技术风险威胁到要开发软件的质量及交付时间。
如果技术风险变成现实，则开发工作可能变得很困难或根本不可能。
技术风险是指潜在的设计、实现、接口、验证、和维护等方面的问题。
此外，规约的二义性、技术的不确定性、陈旧的技术、及“先进的”技术也是风险因素。
技术风险的发生是因为问题比我们所设想的更加难以解决。
商业风险威胁到要开发软件的生存能力。
商业风险常常会危害项目或产品。
五个主要的商业风险是：（1）开发了一个没有人真正需要的优秀产品或系统（市场风险）；（2）开发的产品不再符合公司的整体商业策略（策略风险）；（3）建造了一个销售部门不知道如何去卖的产品；（4）由于重点的转移或人员的变动而失去了高级管理层的支持（管理风险）；以及（5）没有得到预算或人力上的保证（预算风险）。
应该注意到的很重要的一点是：简单的分类并不总是行得通。
某些风险根本无法事先预测。
另一种常用的分类方式是由Charette［CHA89］提出的。
已知风险是通过仔细评估项目计划、开发项目的商业及技术环境、以及其他可靠的信息来源（如，不现实的交付时间，没有需求或软件范围的文档、恶劣的开发环境）之后可以发现的那些风险。
可预测风险能够从过去项目的经验中推断出来（如，人员调整、与客户之间无法沟通、由于需要进行维护而使开发人员精力分散）。
不可预测风险就象纸牌中的大王，它们可能、也会真的出现，但很难事先识别出它们来。
1.3 识别风险识别风险是试图系统化地确定对项目计划（估算、进度、资源分配）的威胁。
通过识别已知的和可预测的风险，项目管理者已经迈出了第一步——在可能时避免这些风险，且当必要时控制这些风险。
在1.2节中提出的每一类风险又分为两个不同的类型：一般性风险和特定产品的风险。
一般性风险对每一个软件项目而言都是一个潜在的威胁。
特定产品的风险只有那些对当前项目的技术、人员、及环境非常了解的人才能识别出来。
为了识别特定产品的风险，必须检查项目计划及软件范围说明，并给出以下问题的答案：“本项目中有什么特殊的特性可能会威胁到我们的项目计划？”一般性风险和特定产品的风险都应该被系统化地标识出来。
Tom Gilb［GIL88］很贴切地表达了这点：“如果你不主动攻击风险，风险就会主动攻击你”。
识别风险的一个方法是建立风险条目检查表。
该检查表可以用于识别风险，并使得人们集中来识别下列常见子类型中的已知的及可预测的风险：·产品规模——与要建造或要修改的软件的总体规模相关的风险。
·商业影响——与管理或市场所加诸的约束相关的风险。
·客户特性——与客户的素质以及开发者和客户定期通信的能力相关的风险。
·过程定义——与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险。
·开发环境——与用以建造产品的工具的可用性及质量相关的风险。
·建造的技术——与待开发软件的复杂性及系统所包含技术的“新奇性”相关的风险。
·人员数目及经验——与参与工作的软件工程师的总体技术水平及项目经验相关的风险。
风险条目检查表能够以不同的方式来组织。
与上述每个话题相关的问题可以由每一个软件项目来回答。
这些问题的答案使得计划者能够估算风险产生的影响。
我们也可以采用另一个不同的风险条目检查表，它仅仅列出与每一个常见子类型有关的特性。
最后，列出一组“风险元素和驱动因子”［AFC88］以及它们发生的概率。
关于性能、支持、成本、及进度的驱动因子将在以后讨论。
1.3.1 产品规模风险有经验的管理者几乎都对下面的陈述没有异议：项目风险是直接与产品规模成正比的。
下面的风险检查表中的条目标识了与产品（软件）规模相关的常见风险：·是否以LOC或FP估算产品的规模？·对于估算出的产品规模的信任程度如何？·是否以程序、文件或事务处理的数目来估算产品规模？·产品规模与以前产品的规模平均值的偏差百分比是多少？·产品创建或使用的数据库大小如何？·产品的用户数有多少？·产品的需求改变多少？交付之前有多少？交付之后有多少？·复用的软件有多少？在每一种情况下，待开发产品的信息必须与过去的经验加以比较。
如果出现了较大的百分比偏差，或者如果数字相近但过去的结果很不令人满意，则风险较高。
1.3.2商业影响风险有一个大型软件公司的工程经理在他的墙上挂了一个镜框，上面写着：“上帝给了我头脑使我成为一个优秀的项目管理者，同时每当销售部门设定项目的最后期限时，也让我经历了地狱般的煎熬”。
销售部门是受商业驱动的，而商业考虑有时会直接与技术现实发生冲突。
下面的风险检查表中的条目标识了与商业影响相关的常见风险：·本产品对公司的收入有何影响？·本产品是否得到公司高级管理层的重视？·交付期限的合理性如何？·将会使用本产品的用户数及本产品是否与用户的需要相符合？·本产品必须能与之互操作的其他产品/系统的数目？·最终用户的水平如何？·必须产生并交付给用户的产品文档的量与质如何？·政府对本产品开发的约束？·延迟交付所造成的成本消耗是多少？·产品缺陷所造成的成本消耗是多少？对于待开发产品的每一个回答都必须与过去的经验加以比较。
如果出现了较大的百分比偏差，或者如果数字相近但过去的结果很不令人满意，则风险较高。
1.3.3 客户相关的风险并非所有客户都是一样的。
Pressman和Herron［PRE91］在讨论这个话题时曾经说过：客户有不同的需要。
一些人知道他们需要什么；而另一些人知道他们不需要什么。
一些客户希望进行详细讨论，而另一些客户则满足于模糊的承诺。
客户有不同的个性。
一些人喜欢享受客户的身份——紧张、谈判、一个好产品带来的心理满足；而另一些人则根本不喜欢作为客户。
一些人会高兴地接受几乎任何交付的产品，并能充分利用一个不好的产品；而另一些人则会对质量差的产品猛烈抨击。
一些人会对质量好的产品表示他们的赞赏；而另一些人则不管怎样都会抱怨不休。
客户和他们的供应商之间也有各种不同的通信方式。
一些人非常熟悉产品及生产厂商；而另一些人则可能素未谋面，仅仅通过信件往来和几个匆忙的电话与生产厂商沟通。
客户常常是矛盾的。
他们希望昨天的一切工作都是免费的。
生产厂商经常陷入客户自己的矛盾之中。
一个“不好的”客户可能会对一个软件项目组能否在预算内按时完成项目产生很大的影响。
对于项目管理者而言，不好的客户是对项目计划的巨大威胁和实际的风险。
下面的风险检查表中的条目标识了与客户特征相关的常见风险：·你以前是否曾与这个客户合作过？·该客户是否很清楚需要什么？他能否花时间把需求写出来？·该客户是否同意花时间召开正式的需求收集会议（第11章），以确定项目范围？·该客户是否愿意建立与开发者之间的快速通信渠道？·该客户是否愿意参加复审工作？·该客户是否具有该产品领域的技术素养？·该客户是否愿意让你的人来做他们的工作，即，当你的人在做具体的技术工作时，该客户是否会坚持在旁边监视？·该客户是否了解软件过程？。