软件需求与分析教程（第二十二章）.pptVIP

第22章 改进需求过程 软件过程改进的最终目标是降低软件的创建和维护费用，下面几种方法可以达此目标： 纠正在以前项目或当前项目中遇到的由于软件过程的缺陷而产生的问题。 预见并避免未来的项目中可能会遇到的问题。 采用比当前的方法效率更高的方法。 本章将介绍需求与各种重要的项目过程和涉众之间的联系、有关软件开发过程改进的一些基本概念，并推荐一种用于改进过程的循环法，同时将列出企业组织应该具有的若干有用的需求“过程资产(process assets)”。 最后描述了过程改进路线图，可用于实现改进的需求工程方法。 22.1 需求与其他项目过程的联系 需求是每个软件项目成功的核心所在，它支持其他技术活动和管理活动。 对需求开发方法和需求管理方法的变更会对项目的其他过程产生影响，反之亦然。 图22.1演示了需求和其他过程之间的某些连接，下面简要介绍一下这些过程之间的接口。 项目规划 需求是项目规划过程的基础。 22.1 需求与其他项目过程的联系 项目跟踪和控制 项目跟踪包括监视每一个需求的状态。 变更控制 将一组需求集确定为基线之后，以后的所有变更都应该通过一个预先定义好的变更控制过程来完成，这一过程有助于确保： 理解所提议的变更产生的影响。 由合适的人选作出接受变更的正式决定。 所有受变更影响的人得到关于发生变更的通知。 根据需要对项目资源和所做出的承诺进行调整。 保持需求文档是必威体育精装版版本，并且是准确的。 系统测试 用户需求和功能性需求是系统测试必不可少的参考依据。 构造 通过跟踪需求，可以对从每条需求中衍生出来的特定的软件设计和编码元素编写文档。 编写用户文档 产品需求是用户文档编写过程的依据。 22.2 需求和各涉众组 图22.2展示了与软件开发组有联系的某些项目涉众，也展示了他们对项目需求工程活动产生的某些影响。 22.2 需求和各涉众组 当软件开发团队变更其需求过程时，与其他项目涉众进行沟通的接口也会发生变化。 下面列出了可能会遇到的一些抵制情况： 变更控制过程可能会被看作是开发工作的障碍而被丢弃，因此变更工作很难实施。 有些开发人员认为编写和评审需求文档纯粹是浪费时间的官僚做法，妨碍他们的“真正”工作，即编写代码。 如果用于客户支持的费用与开发过程没有联系，那么开发团队可能会缺少变更需求的动力 。 如果改进需求过程的目标之一是通过创建高质量的产品来减少技术支持费用，那么技术支持经理可能会感到很不安 。 忙碌的客户有时会声称，他们没有时间去从事需求工作 。 22.3 软件过程改进的基本原则 应该牢记下面4条软件过程改进的原则(Wiegers 1996a)： 1.过程改进应该是不断演化的、连续的、周期性的 不要期望一次就能改进全部过程，要知道在第1次尝试变更时，可能无法解决所有问题。 2.只有人们和组织具有变更的动机时才可能实施变更 下面列出了一些典型的问题，也许能为需求过程的变更提供驱动力： 项目超出了最后期限，原因是需求比预期的扩展了很多，也复杂了很多。 开发人员频繁加班，原因是直到开发后期才发现了引起误解的需求和表达不明确的需求。 系统测试工作前功尽弃，原因是测试人员并没有弄清楚产品应该做什么。 虽然正确的功能都实现了，但是用户不满意，这是由于性能不好、易使用性差或存在其他质量缺陷。 维护费用很高，因为客户的对产品的许多增强要求没有在需求获取阶段确定下来。 开发组织名誉受损，因为客户不接受交付的软件。 3.过程变更要有的放矢 在开始运用更好的过程之前，一定要明确变更的目标是什么(Potter and Sakry 2002)。 4.将改进活动视作小型项目 项目的总体计划应该包括过程改进的资源和任务。与所有项目一样，改进项目也要执行计划、跟踪、测量和报告，只是规模相应地缩小了。 22.4 过程改进周期 图22.3是一个有效的过程改进周期。 这一方法反映了您在执行下一个任务之前先清楚自己所处位置的重要性；反映了绘制过程路线图的必要性，以及以往的经验在持续的过程改进中的重要性。 22.4.1 评估当前采用的方法 所有改进活动的第1步都是评估组织当前所使用的方法，找出这些方法的优点和缺陷。 评估当前过程的方法有多种。如果我们已经试过前几章末尾的“下一步”，实际上已经开始对需求方法及其结果进行了非正式评估了。 设计结构化问卷表是一种更系统的方法，它能够以较低的费用对当前过程进行评估。与团队成员进行面谈和讨论，可以更准确更全面地了解当前的过程。 我们可以采用附录A所提供的问卷表来审查组织当前采用的需求工程方法1。这种自我评估法有助于我们确定哪些需求过程最需要改进。 附录B中描述了需求如何适应SW-CMM和新的CMM集成模型CMMI-SE/SW。 22.4.