第16章--需求开发面临的特殊难题.pptVIP

第16章 需求开发面临的特殊难题 本书所讲述的需求开发，是针对一个新软件或系统开发项目的情况，这种项目有时也称为零起点项目(green-field project)。 大多数组织的主要精力集中于维护现存的遗留系统，或者为已有的商业产品构建新的版本；其他组织也很少是从零开始构建一个新系统，而是对商用现货(off-the-shelf，COTS)产品进行集成、定制和扩充，以满足自己的需要。 16.1 维护项目的需求 维护是指对当前运行的项目进行修改，有时也称为继续工程(continuing engineering)或后续开发(ongoing development)。 程序维护的任务主要是纠正缺陷、为现有系统添加新功能或新报表，以及对功能进行修改以便遵循修订后的业务规则。 16.1.1 开始捕获信息 缺少精确的需求文档，那么维护人员就必须进行逆向工程，通过代码来理解系统，我将此看作是软件考古学(software archaeology)。 为了能够从逆向工程中获得最大的收益，考古探险队应该将通过需求和设计描述表中所了解到的信息记录下来，然后将有关当前系统某些部分的精确信息积累起来。 构建一个包含当前系统部分的需求表示可达到以下3个有用的目标： 消除知识鸿沟，使将来的维护人员能更好地理解所做的变更。 收集当前系统的一些信息——当前系统在以前缺乏良好的书面文档。当项目团队日后再完成其他的维护任务时，可以对这些零星分散的知识表示加以扩充，进而逐步完善系统文档。记录这些新发现的知识所需要增加的费用，比起以后必须重新发现这些知识所需要的费用更少。 提供一个指标，表明当前的系统测试集对系统功能的覆盖率。 16.1.2 亲身实践一下新的需求 技术 技能水平对项目的成功或失败有着至关重要的影响，那么实践经验就可以减少在一个零起点项目中第一次应用用例的风险。 我们还可以在小规模项目维护中试试其他一些技术： 创建数据字典(第10章)。 绘制分析模型(第11章)。 指定质量属性和性能目标(第12章)。 构建用户界面和技术原型(第13章)。 审查需求规格说明(第15章)。 根据需求编写测试用例(第15章)。 制定客户验收标准(第15章)。 16.1.3 遵循跟踪链 需求的跟踪数据有助于程序维护人员确定由于某一特定的需求发生了变更。 由于许多软件修改都会引发很大的连锁反应，所以我们必须确保每次需求变更都要正确地传给下游工作产品，审查就是检查这种一致性的一种好方法。 第15章描述了审查参与者应该代表的下面4种观点，这也适用于维护工作： 对需求进行修改或增强的作者。 提出请求的客户或市场代表，他们能确保新的需求准确地描述所需要的变更。 开发人员、测试人员或者其他必须以新的需求为基础来完成自己工作的人们。 其工作产品可能受这种变更影响的人们。 16.2 软件包解决方案的需求 需要对商用现货产品进行配置、定制、集成和扩展之后，才能在目标环境中正常运行它。 需求也可以用来评估候选方案，以确定哪种软件包最能满足我们的需要： 确定需求的重要程度，用0～10对它们进行区分。 就每个候选软件包满足每一条需求的程度进行评价。 评估每个软件包的非功能性需求。 评估产品费用、厂商的生存能力、厂商对产品的支持能力、使扩展和集成得以进行的外部接口，以及是否遵循了具体环境所要求的技术需求或某些限制条件。 16.2 软件包解决方案的需求 如图16.2所示，它将COTS软件包定制、集成到现有的应用环境中，并用其他增补的模块(bolt-on)对其进行扩展。 16.2.1 开发用例 计划购买现成的产品，那么就没有必要指定详细的功能性需求或设计用户界面了，而应该将精力集中于在用户需求这一级别上的商用现货的需求上，用例就是能够达此目标的一个很好的选择。 为了确定用户是否可以用这一软件包完成自己的任务，以及任务完成的程度如何，我们需要从这些高优先级的用例中衍生出测试用例。 运行商用现货产品，使其覆盖一整套场景套件，这些套件代表了期望的使用模式，这些使用模式被称为运行模式(operational profile) (Musa 1996)。 16.2.2 考虑业务规则 经过需求探索，就应该确定商用现货产品必须遵守的相关的业务规则。 是否可以对这一软件包进行配置，使其符合公司策略、业界标准或政府规则呢？ 当这些规则有所变化时，我们对这一软件包进行修改的难易程度如何？ 是否能够以正确的格式生成要求的报表？ 有些软件包还整合了一些全局性的业务规则。 计算所应扣除的所得税或打印税表。当这些规则或计算方法有所变化时，软件包供应商是否能为我们提供新的版本？ 16.2.3