8-软件需求实现-北京大学软件与微电子学院.ppt

第八章 软件需求实现 周立新 博士 北京大学软件与微电子学院 课程提纲 软件需求基本理论和概念 软件需求工程过程 软件需求获取 软件需求分析 软件需求规格说明 软件需求验证 软件需求管理 软件需求实现 软件需求工程新进展 软件需求开发与需求管理工具 内容提要 需求与其他项目过程的联系 过程改进原则及周期 需求相关的风险控制 特殊软件项目(如维护、外包等)的需求实践等 * 8.1 需求与其他项目过程的联系 需求是每个软件项目成功的核心所在，它支持其他技术活动和管理活动。 对需求开发方法和需求管理方法的变更会对项目的其他过程产生影响，反之亦然。 右图演示了需求和其他过程之间的某些连接，下面简要介绍一下这些过程之间的接口。 8.1.1 从需求到项目规划 由于需求定义了项目的预期成果，所以项目规划、项目预算和项目的进度安排都必须以软件需求为基础。 最重要的项目成果是交付满足业务目标的系统，而不一定是根据最初的项目规划实现所有初始需求的系统。 需求和规划只代表团队最初的评估，项目成果就是根据这一评估来完成的。 下表说明对需求工作的投资可以加速项目的开发。 需求阶段投入的工作量 需求阶段投入的时间 开发较快的项目 14% 17% 开发较慢的项目 7% 9% 需求和预估 根据文本需求、图形分析模型、原型或用户界面设计来预估产品的大小。 虽然对于软件的规模没有完善的度量标准，但下面是一些常用的度量标准： 可单独测试需求的数量(Wilson 1995)。 功能点和特性点的多少(Jones 1996b)，或者将数据、功能和控制三者整合在一起的三维功能点的数量(Whitmire 1995)。 图形用户界面(GUI)元素的数量、类型和复杂度。 用于实现特定需求所需的源代码行数。 对象类的数量或者其他面向对象系统的衡量标准(Whitmire 1997)。 需求和进度安排 主要的规划失误包括: 忽略了公共(用)的项目任务，低估了所需的工作量和时间，没有考虑项目风险，没有考虑返工所需的时间，以及对自己的盲目乐观等。 有效的项目规划需要以下元素： 根据对需求的清楚理解来估计产品规模的大小。 根据历史记录了解到的开发团队的工作效率。 一张任务列表，以便完全地实现和验证每一特性或用例。 相当稳定的需求。 有效的预测和规划过程。 经验，这有助于项目经理对不可触及的因素和每一个项目所特有的因素加以调整。 注意： 不要迫于压力而许下自己 明知道不可能做到的诺言， 这是避免最后两败俱伤的 秘诀。 8.1.2 从需求到设计和编码 需求和设计之间存在差别, 要防止规格说明造成实现上的倾向性，除非是有迫不得已的原因要有意地对设计加以约束。 需求规格说明几乎总是包括某些设计信息，让设计人员或开发人员参与需求审查，这样可以确保需求为后续的设计打下坚实的基础。 产品的需求、质量属性和用户特点可以决定产品体系结构。 从需求到设计和编码 对于同时包括软件组件和硬件组件的系统，以及只包括软件的复杂系统，体系结构就显得尤其关键。 将系统功能分配给子系统或组件必须采用自顶向下的方法(Hooks和Farry 2001)。 在开始实现产品之前，虽然不需要为整个产品开发完整的、详细的设计，但是，应该先对每一个组件进行设计，然后再对其进行编码。 从需求到设计和编码 下面的动作可以使所有的项目类型都从中受益： 为子系统和组件开发一个坚固的体系结构，这一体系结构在产品改进的过程中可以保持不变。 确定需要构建的主要对象类或功能模块，定义它们的接口、职责以及与其他单元的协作。 对并行处理系统，要理解计划的执行线程或对并发进程的功能分配。 根据强内聚、低耦合和信息隐藏等这些良好的设计原则，定义每个代码单元的预期功能(McConnell 1993)。 确保设计满足所有的功能性需求，但不要包括不必要的功能。 确保设计能适应可能出现的异常条件。 确保设计能达到所陈述的性能、健壮性、可靠性和其他一些质量属性的目标。 8.1.3 从需求到测试 测试和需求工程是一种互相促进的关系。 需求是系统测试的基础，对产品的测试应该根据需求文档中所记录的产品的预期行为来进行，而不应该根据设计或编码来测试。 项目测试人员应该确定他们如何验证每一条需求，下面列出了一些可能的方法： 测试(执行软件以便发现缺陷)。 审查(检查代码，以便确保代码满足了需求)。 演示(显示产品的运作与所期望的相符)。 分析(推导在某些情况下系统应该如何运作)。 基于规格说明的测试可以运用若干测试设计策略：动作驱动、数据驱动(包括边界值分析和等价类划分)、逻辑驱动、事件驱动和状态驱动(Poston 1996)。 8.1.4 从需求到成功 使项目更成功的一种方法是，列出与特定的代码版本相对应的所