需求工程-软件建模与分析（第3版）课件 第18章：需求工程中的项目管理

第十八章：需求工程中的项目管理2026/9/7目录概述资源支持需求工程的生命周期规划团队管理需求风险管理目录目录概述资源支持需求工程的生命周期规划团队管理需求风险管理目录概述软件项目的目的是保证所有重要的工作都能得到应有的关注，都能顺利有序的完成，以最终产生高质量的软件产品。为此，项目需要建立计划，并跟踪、监督和保证计划的正确执行。计划的重要内容包括：项目需要的资源（人力、金钱、工具、时间等）项目中需要执行的活动（生命周期模型和过程模型）项目中需要产生的交付物件（各种必要的中间物件和最终产品）围绕着项目计划而执行的各种项目活动就是项目管理。概述需求工程是软件项目的一个部分，也是非常复杂的活动，自然也需要项目管理活动的关注。需求工程中的项目管理活动包括资源管理，为需求工程提供各种资源的支持，尤其是提供人力资源的支持，组织和管理需求团队。活动管理，规划和实施需求工程中的各种活动。前面的章节已经详细描述了整个需求工程过程的执行情况。交付物件管理，管理需求工程当中产生的各种交付物件。目录概述资源支持需求工程的生命周期规划团队管理需求风险管理目录资源支持需求工程的成功执行需要项目提供足够的资源支持一定数量技能良好的可用人员；可行的时间限制和充足的资金支持；可用的系统运行环境、软件工具、道具、文档模版、可复用资源等其他资源支持。实践经验表明，时间资源和资金费用的支持对需求工程甚至整个项目都有重要影响。1981年，BarryBoehm发现项目费用的6％和时间的9-12％被消耗在需求阶段。在20年之后，随着需求工程的发展，项目对需求工程的投入也加大了许多：项目工作的15.7％和时间的38.6％被用于进行需求工程。所以，建议将项目工作的15％～30％分配给需求工程活动。资源支持NASA(U.S.NationalAeronauticsandSpaceAdministration)提供的数据显示：当在需求工程当中投入项目总成本的8-14％时，可以极大的降低项目的超支率。目录概述资源支持需求工程的生命周期规划团队管理需求风险管理目录需求工程的生命周期规划需求工程的过程模型很好的阐释了需求工程内部活动的组织和执行，但作为软件开发的一个阶段，需求工程还要规划它自己在整个项目工作的位置，进行需求工程的生命周期规划。需求工程的生命周期规划要受项目特点的约束，要符合软件的过程模型，它是软件生命周期模型的一个部分。瀑布模型在项目的软件过程采用瀑布模型时，需求工程的生命周期规划如图所示。需求工程的生命周期规划——瀑布模型这种情况下的软件过程模型往往将需求开发视为一个线性独立的活动，它为后继的开发工作提供一个稳定可靠的需求基线集。瀑布模型如果软件的问题域比较成熟和易于明确化，并且需求也比较稳定，那么整个项目可以生命周期模型。如果软件的问题域不够成熟或者比较复杂，再或者需求非常易变，那么就不应该采用瀑布模型。瀑布模型下的需求工程还不利于用户的有效参与，因为他们在需求开发结束之后可能就没有机会再继续跟踪和监督需求的实现情况，也没有机会对开发者进一步的解释和明确具体的需求。需求工程的生命周期规划——瀑布模型增量式模型如果软件的问题域比较复杂，但是业务非常成熟而且需求比较稳定，那么可以采用如图所示的增量式模型（又称为渐进交付模型）。需求工程的生命周期规划——增量式模型增量式模型增量式模型采用逐步增量和多次发布的方式减小每一次实现的需求范围，降低需求实现的风险。增量式模型仍然要求需求开发活动为后继的开发工作提供一个稳定可靠的需求基线集，因此在需求易变或者问题域信息很难一次处理完整时（例如问题域不成熟或者极其复杂），它并不适用。而且增量式模型也可能不利于用户的有效参与。需求工程的生命周期规划——增量式模型演化式模型在问题域极其复杂或者需求不稳定时，可以采用如图所示的演化式模型。需求工程的生命周期规划——演化式模型演化式模型演化式模型采用增量迭代和逐步展开的方式进行需求的开发，因此能够处理非常复杂的问题域和业务活动，而且不断迭代的方式还可以使得它更好的应对需求的改变，从而适应需求的不稳定性。演化式模型将需求开发看作是一个长期迭代的工作，因此可以延长用户在项目中的作用时期，提高用户的有效参与度。演化式模型的缺点在于它使得开发工作的协同和管理工作变得更加困难。需求工程的生命周期规划——演化式模型原型式模型在问题域不成熟，业务活动仍然在不断发展和改变时，可以使用如图所示的原型式模型。需求工程的生命周期规划——原型式模型原型式模型在需求开发阶段重视使用原型法（主要是抛弃式原型），能够很好的解决各种不确定性，包括问题域的不确定性和业务活动的不确定性。原型式方法的缺点在于大量原型的使用提高了需求工程阶段的成本，而且易于发生各种原型风险。目录概述资源支持需求工程的生命周期规划团队管理组建需求团队维持需求团队内部的有效沟通需求风险管理目录组建需求团队“人”是软件工程的第一要素，也是需求工程的第一要素，拥有合适的人员才能成功的完成任务。而且随着软件系统越来越复杂，很多工作已经不是一个或者两个人能够胜任的了，软件活动需要集体团队的参与。组建需求团队对需求工程的成功有重要意义。团队管理——组建需求团队组建需求团队在挑选人员组建需求团队时，要注意以下事项：团队成员的技能分布要完备。团队成员的知识和技能应该互补并且完备，要有人能够熟悉业务和问题域，也要有人能够熟悉各种需求工程方法，还要有人熟悉各种后继开发工作对需求工程的要求。团队成员应该尽职尽责，能够耐心和持之以恒的处理各种复杂任务。团队成员应该具备出色的交流能力和沟通技巧，因为需求工程是一个充满交流与沟通的软件开发活动。团队成员应该能够互相信任，要将固执己见的人员排出于团队之外。团队管理——组建需求团队组建需求团队在挑选人员组建需求团队时，要注意以下事项：团队成员的数量要适中。对于小项目，可以由少到2个人组成（一个来自客户；一个来自开发者，即需求工程师）。对于大型项目，可以由数人组成。如果团队成员当中存在客户方有决策权的人，很多时候会更加有利于需求工程活动的进行。要对需求团队进行必要的培训，尤其是那些初次参与需求工程活动的成员。作为团队核心的需求工程师要足够称职。对需求工程师的选择要慎重，必要的时候要进行重点的培养。开发组织切不可仅仅就因为一些人工作比较空闲就任命其为团队的核心。团队管理——组建需求团队维持需求团队内部的有效沟通需求团队要在需求工程的活动中维持有效的沟通，这样才能建立一个“凝聚在一起”的团队，而不仅仅是一组人，才能保证需求工程的成功。团队管理——维持需求团队内部的有效沟通维持需求团队内部的有效沟通建立一致目标团队是由很多个人组成，这里的每一个人都有着自己的工作目标。要想给团队一个整体的感觉和统一的团队精神，那么这些个人的目标就应该有一个共同的契合点，它就是团队的共同目标。如果团队成员都能认同相同的项目目标，那么他们就可以朝着一致的方向努力，在工作中可以互相依靠和协同工作。当然每个团队成员在认同并接受项目共同目标的同时还可以拥有自己的目标，但是他们自己的目标不能和共同目标相冲突，否则整个需求团队就是一盘散沙。对项目前景和范围的定义可以帮助需求团队更好的建立共同目标。团队管理——维持需求团队内部的有效沟通维持需求团队内部的有效沟通建立有效的沟通机制要在团队中维持持续有效的沟通，就不能仅仅依靠团队个人的沟通意识和沟通行为，而是应该建立有效的沟通机制。良好的沟通机制既要帮助团队成员能够顺畅的表达自己的信息，又要能够帮助团队成员及时的得到其他成员的信息。定期的会议是一种比较常见和有效沟通机制。需求管理（尤其是前向跟踪信息的管理）也可以作为需求团队的一种有效沟通机制。团队管理——维持需求团队内部的有效沟通维持需求团队内部的有效沟通利用有效的沟通技巧如果团队的管理者能够掌握一些常见的沟通技巧，也能很好的促进团队内部的有效沟通。例如，自备食品的聚餐，小的集体娱乐活动，等等。能够提高团队成员积极性的手段（成员激励）也能够提高团队内部的沟通效果。利用辅助的工具和技术很多辅助的工具和技术也可以用来提高团队内部的沟通效果。常见的辅助工具和技术有：协同工作的软件工具，例如配置管理工具和日程共享工具。网络即时交流工具，例如网络聊天工具。文件共享工具。常用的通讯途径，例如电子邮件团队管理——维持需求团队内部的有效沟通目录概述资源支持需求工程的生命周期规划团队管理需求风险管理风险管理综述风险管理过程常见的需求风险目录风险管理综述软件开发是个复杂的活动，涉及到很多不可预期的因素，它们都可能会给项目的进行带来很大的影响。在项目管理当中，必须对这些可能发生的因素进行管理，减少这些因素发生时会给项目的正常进度带来的影响，防止项目的实际执行情况与计划发生太大的偏离，以至失去对项目的控制。这种对项目可能发生的各种因素的管理就被称为风险管理，它是项目管理的一种重要实践方法。需求风险管理——风险管理综述风险管理综述在软件开发项目当中，损失是指对项目的负面影响，可能是最终产品的质量下降、成本增加、完成时间推迟，甚至是项目的彻底失败。风险产生的原因是对未来不利事件的不确定性。不确定性是指因为目前知识有限而无法确定未来事件的准确走向，不确定性随着项目的深入和知识的增加会逐步减小直至消失。不确定性的指向可能是未来的有利事件，也可能是未来的不利事件。风险针对的是未来的不利事件。风险管理就是管理风险的活动，它关注软件开发活动和任务的风险和不确定性，并采取行动减少其中的不确定性或者降低风险的影响范围。需求风险管理——风险管理综述风险一词意为“遭受损失或者伤害的可能性”。风险管理过程风险管理的过程如图所示需求风险管理——风险管理过程风险管理过程风险识别风险识别的目的是系统化地指出对项目的威胁，并在识别之后尽可能的进行回避，或者控制这些风险。风险识别的一种常用方法是建立风险条目的检查表，逐一比照和分析该检查表的条目就可以进行项目的风险识别。风险识别的另一种常用方法是进行驱动因素分析。它的核心是一个基于驱动因素建立的决策模型，这样，在分析和得到项目的特定因素之后，就可以依据决策模型，推导出项目的可能风险。工作分解也是一种常用的风险识别方法。它为项目管理计划建立工作分解结构和网络图，寻找其中的优先顺序和瓶颈，识别进度中的关键点和风险因素。需求风险管理——风险管理过程风险管理过程风险分析风险分析活动分析已经识别出来的风险，并使用一定的特征对其进行量化和预测。风险分析通常使用下面几个特征：不确定性：风险发生的可能性；损失：如果风险发生可能造成的损害；严重性：损失的严重程度；期间：风险的持续期间；优先级：风险需要被优先处置的程度，一般为“不确定性×损失”。需求风险管理——风险管理过程风险管理过程制定风险管理计划风险管理的目的是管理和降低风险，所以对已经识别和分析的风险，要制定相应的风险管理计划。风险管理计划的重点是对风险的处理策略，有下述三个方面：风险回避/缓解策略：最好的策略就是采用主动的方法回避和缓解风险，这需要建立一个风险缓解计划。风险监测：说明在项目的执行当中利用哪些数据和特征来进行风险监测。风险应急计划：如果风险的回避策略失效，导致风险发生，那么就采取措施尽可能的减小风险的影响范围或者对风险造成的损失进行及时的弥补。需求风险管理——风险管理过程风险管理过程风险跟踪在项目启动之后，根据风险计划的监测策略，跟踪项目的风险特征和相应的度量数据，监视风险指示和缓解策略的执行情况。风险控制在项目的执行当中，一旦风险发生，就要启动项目风险管理计划中的相应应急计划，及时的纠正风险带来的计划偏离情况。需求风险管理——风险管理过程常见的需求风险需求工程中的风险管理是要识别、分析、计划、跟踪和监控因为需求而可能发生的项目风险。复杂性、稳定性和可得性是需求风险的最大驱动因素。需求风险管理——常见的需求风险常见的需求风险在实践当中发现的常见的需求风险情况如表所示。需求风险管理——常见的需求风险类别需求风险解决策略需求获取遗漏关键需求定义项目的前景和范围没能充分反映用户的真实意图提高用户参与；执行需求验证范围越界定义项目的前景和范围；定义系统边界需求分析忽略了对非功能性需求的建模使用相关技术进行非功能性需求建模，例如NFR混淆了需求分析与设计工作区分“分析”与“设计”不熟悉的新技术和新方法使用熟练技术；进行培训需求规格说明要求过于完美要认识到没有完美的需求，并能够基于不完美的需求进行工作文档的低质量提高文档写作技巧；执行需求验证没能在用户间形成一致的看法引导冲突的协商解决；执行需求验证常见的需求风险在实践当中发现的常见的需求风险情况如表所示。需求风险管理——常见的需求风险类别需求风险解决策略需求验证没有进行文档审查每一条需求都应该进行审查需求管理需求的变更制定策略和过程，控制变更范围越界维护需求基线；维护需求跟踪信息工程管理时间或者进度安排不当使用增量或者迭代