软件需求工程第二部分软件需求开发(精).ppt

2023-3-10第第十七十七章章 超越需求开发超越需求开发第第 17 章章 超越需求开发超越需求开发 2/25学习目标学习目标在学完本章内容之后，你应该能够：在学完本章内容之后，你应该能够： 1)了解做好从需求到项目规划转换的意义与方法；了解做好从需求到项目规划转换的意义与方法；2) 分析从需求到设计、编码、测试的关系与区别；分析从需求到设计、编码、测试的关系与区别；3) 掌握从需求到设计、编码、测试的过程控制原则掌握从需求到设计、编码、测试的过程控制原则与方法。与方法。第第 17 章章 超越需求开发超越需求开发 3/2517.0 做好需求做好需求转化的意义和作用转化的意义和作用一个软件开发项目最终可发行的是满一个软件开发项目最终可发行的是满足客户需求和期望的软件系统。足客户需求和期望的软件系统。需求是从产品概念通向用户满意之路需求是从产品概念通向用户满意之路的最本质的一步。的最本质的一步。把软件需求转化为健壮的设计和合理把软件需求转化为健壮的设计和合理的项目规划是项目成功的基本保证。的项目规划是项目成功的基本保证。第第 17 章章 超越需求开发超越需求开发 4/2517.0 做好需求做好需求转化的意义和作用转化的意义和作用 软件开发人员与客户、用户对需求的理解不软件开发人员与客户、用户对需求的理解不同、对系统的要求不同、甚至由于利益关系的同、对系统的要求不同、甚至由于利益关系的不同，将影响转化工作的顺利进行。不同，将影响转化工作的顺利进行。 需求分析人员与软件设计和编码人员在对系需求分析人员与软件设计和编码人员在对系统的理解角度、认识水平、掌握的技术，甚至统的理解角度、认识水平、掌握的技术，甚至在年龄、工作经历、和所处地位的差别，将影在年龄、工作经历、和所处地位的差别，将影响转化工作的顺利进行。响转化工作的顺利进行。第第 17 章章 超越需求开发超越需求开发 5/2517.0 做好需求做好需求转化的意义和作用转化的意义和作用基线基线需求需求项目计划项目计划设计和代码设计和代码测测 试试l根据需求确定项目的规模根据需求确定项目的规模l根据产品规模进行评估根据产品规模进行评估l当需求改变时更新计划当需求改变时更新计划l使用需求优先级驱动迭代使用需求优先级驱动迭代l让开发人员评审需求让开发人员评审需求l根据质量属性决定体系结构设根据质量属性决定体系结构设计计l将需求分配给各组件将需求分配给各组件l跟踪需求到设计和代码跟踪需求到设计和代码l尽早开始测试设计尽早开始测试设计l用需求驱动系统测试用需求驱动系统测试l让用户开发验收测试让用户开发验收测试l跟踪需求到测试跟踪需求到测试图图17-1 需求推动项目规划、设计、编码和测试活动需求推动项目规划、设计、编码和测试活动P209第第 17 章章 超越需求开发超越需求开发 6/2517.1 从需求到项目规划从需求到项目规划由于需求定义了项目预期的成果，所以项目由于需求定义了项目预期的成果，所以项目规划、预测和进度安排都必须以软件需求为基规划、预测和进度安排都必须以软件需求为基础。础。但是，请大家牢记，最重要的项目成果是交但是，请大家牢记，最重要的项目成果是交付满足业务目标的系统，而不一定是根据最初付满足业务目标的系统，而不一定是根据最初的项目规划实现所有初始需求的系统。的项目规划实现所有初始需求的系统。P210第第 17 章章 超越需求开发超越需求开发 7/2517.1 从需求到项目规划从需求到项目规划项目团队到底应该在需求工程中投入多项目团队到底应该在需求工程中投入多少时间和精力，是一个必须解决的问题少时间和精力，是一个必须解决的问题。对小型项目而言，团队在需求工程上所对小型项目而言，团队在需求工程上所发费的故障量应该占项目的发费的故障量应该占项目的1215。相当多的证据表明，花一些时间理解需相当多的证据表明，花一些时间理解需求实际上可以加速项目的开发进度。求实际上可以加速项目的开发进度。P210第第 17 章章 超越需求开发超越需求开发 8/2517.1 从需求到项目规划从需求到项目规划欧洲的一份研究表明，产品开发较快的欧洲的一份研究表明，产品开发较快的团队，与产品开发较慢的团队相比，在团队，与产品开发较慢的团队相比，在需求阶段所投入的时间和工作量更多一需求阶段所投入的时间和工作量更多一些。些。P210投入的工作量投入的工作量投入的时间投入的时间开发较快的项目开发较快的项目1417开发较慢的项目开发较慢的项目79表表17-1 对需求工作的投入可以加速项目的开发对需求工作的投入可以加速项目的开发第第 17 章章 超越需求开发超越需求开发 9/2517.1 从需求到项目规划从需求到项目规划l需求和预估需求和预估 可以根据文本需求、分析模型、原型或用户界面来可以根据文本需求、分析模型、原型或用户界面来估计软件产品的规模；估计软件产品的规模；虽然软件的规模没有规定的度量标准，但可以采用虽然软件的规模没有规定的度量标准，但可以采用如下一些方法来进行度量：如下一些方法来进行度量：l需求的数量；需求的数量；l功能点和特性点的数量；功能点和特性点的数量；l图形用户界面（图形用户界面（GUI）元素的数量、类型和复杂度；）元素的数量、类型和复杂度；l用于实现特定需求所需的源代码行数；用于实现特定需求所需的源代码行数；l对象类的数量或其他面向对象系统的衡量标准。对象类的数量或其他面向对象系统的衡量标准。P211第第 17 章章 超越需求开发超越需求开发 10/2517.1 从需求到项目规划从需求到项目规划l需求和进度安排需求和进度安排 许多软件工程实行许多软件工程实行“从右到左的进度安排从右到左的进度安排” ，这，这种方式常常不能按时完成项目。种方式常常不能按时完成项目。在做出详细的规划和约定之前定义软件需求是更现在做出详细的规划和约定之前定义软件需求是更现实的。实的。进度进度范围范围成本成本需需求求进度进度范围范围成本成本需需求求图图17-2 两种不同的进度安排两种不同的进度安排P212第第 17 章章 超越需求开发超越需求开发 11/2517.1 从需求到项目规划从需求到项目规划l需求和进度安排需求和进度安排 对于复杂的系统，软件仅是最终产品的一部对于复杂的系统，软件仅是最终产品的一部分时，只有在系统需求（产品级需求）产生以分时，只有在系统需求（产品级需求）产生以后，才能建立高层的进度安排。后，才能建立高层的进度安排。 将系统需求分解并分配到各个不同的软硬件将系统需求分解并分配到各个不同的软硬件子系统中，有利于进度的安排和执行。子系统中，有利于进度的安排和执行。 必须根据市场需求、销售计划、客户服务要必须根据市场需求、销售计划、客户服务要求以及产品开发计划等的为基础建立起一致的求以及产品开发计划等的为基础建立起一致的产品发行日期。产品发行日期。P213第第 17 章章 超越需求开发超越需求开发 12/2517.1 从需求到项目规划从需求到项目规划l 需求和进度安排需求和进度安排 正确的项目规划需要以下元素：正确的项目规划需要以下元素： n根据对需求的清楚理解来估计产品规模的大小；根据对需求的清楚理解来估计产品规模的大小； n根据历史记录了解开发小组的工作效率；根据历史记录了解开发小组的工作效率； n需要一张综合的任务列表，以便完整地实现和验需要一张综合的任务列表，以便完整地实现和验证每一特性或用例；证每一特性或用例； n 相当稳定的需求；相当稳定的需求； n 项目团队的经验。项目团队的经验。P213第第 17 章章 超越需求开发超越需求开发 13/2517.2 从需求到设计和编码从需求到设计和编码 需求和设计之间存在差别，需求开发和规格说需求和设计之间存在差别，需求开发和规格说明应该强调对预期系统外部行为的理解和描述。明应该强调对预期系统外部行为的理解和描述。 必须让设计者和开发者参与需求审查以判断需必须让设计者和开发者参与需求审查以判断需求是否可以作为设计的基础。求是否可以作为设计的基础。 直接从需求规格说明跳到编码阶段，其可能的直接从需求规格说明跳到编码阶段，其可能的结果只能是结构性很差的一个软件。结果只能是结构性很差的一个软件。在构造软件之前，应该仔细考虑构造系统的最在构造软件之前，应该仔细考虑构造系统的最有效的方法。有效的方法。P213第第 17 章章 超越需求开发超越需求开发 14/2517.2 从需求到设计和编码从需求到设计和编码 分析模型代表了用户和开发小组对正在解决分析模型代表了用户和开发小组对正在解决的问题的理解，而设计模型则描绘了应该如何的问题的理解，而设计模型则描绘了应该如何构造系统。构造系统。如果在需求分析之后立刻进行编码，那么必定如果在需求分析之后立刻进行编码，那么必定会出现代码重复。而且设计上的返工比编码返会出现代码重复。而且设计上的返工比编码返工可能要效率高一些。工可能要效率高一些。以需求为基础，反复设计将产生优良成果，用以需求为基础，反复设计将产生优良成果，用不同的方法进行设计可以精细化最初的概念。不同的方法进行设计可以精细化最初的概念。P213第第 17 章章 超越需求开发超越需求开发 15/2517.2 从需求到设计和编码从需求到设计和编码在开始实现产品之前，虽然不需要为整个产在开始实现产品之前，虽然不需要为整个产品开发完整的、详细的设计，但是，应该先对品开发完整的、详细的设计，但是，应该先对每一个组件进行设计，然后再对其进行编码。每一个组件进行设计，然后再对其进行编码。 当项目难度很大、涉及的接口和交付复杂、当项目难度很大、涉及的接口和交付复杂、开发人员经验不足时，最能体现设计规划的好开发人员经验不足时，最能体现设计规划的好处。处。P215第第 17 章章 超越需求开发超越需求开发 16/2517.2 从需求到设计和编码从需求到设计和编码如下的建议对所有的项目类型都有益：如下的建议对所有的项目类型都有益：l 为子系统和组件开发一个坚固的体系结构，这一体系结构为子系统和组件开发一个坚固的体系结构，这一体系结构在产品改进的过程中可以保持不变；在产品改进的过程中可以保持不变；l明确需要创建的对象类或功能模块，定义他们的接口、职明确需要创建的对象类或功能模块，定义他们的接口、职责以及与其他单元的协作；责以及与其他单元的协作；l对并行处理系统，要理解计划执行的线程或对并发进程的对并行处理系统，要理解计划执行的线程或对并发进程的功能分配；功能分配；l 根据强内聚、松耦合和信息隐藏的设计原则，定义每个代根据强内聚、松耦合和信息隐藏的设计原则，定义每个代码单元的预期功能码单元的预期功能 ；l 确保设计满足所有的功能需求，但不包括不必要的功能；确保设计满足所有的功能需求，但不包括不必要的功能；l确保设计能适应可能出现的异常条件；确保设计能适应可能出现的异常条件；l确保设计能达到所陈述的性能、健壮确保设计能达到所陈述的性能、健壮 性、可靠性和其他一性、可靠性和其他一些质量属性的目标。些质量属性的目标。 P215第第 17 章章 超越需求开发超越需求开发 17/2517.3 从需求到测试从需求到测试测试和需求工程是一种相互促进的关系，好的需求测试和需求工程是一种相互促进的关系，好的需求工程可以生存更好的测试，工程可以生存更好的测试， 好的测试分析可以生存好的测试分析可以生存更好的需求。更好的需求。 需求是系统测试的基础，对产品的测试应该根据需需求是系统测试的基础，对产品的测试应该根据需求文档中所记录的产品的预期行为来进行，而不应该求文档中所记录的产品的预期行为来进行，而不应该根据设计或编码来测试。根据设计或编码来测试。产品可以正确地展示基于代码的测试用例所描述的产品可以正确地展示基于代码的测试用例所描述的所有行为，但这并不意味着产品正确地实现了用户或所有行为，但这并不意味着产品正确地实现了用户或功能性需求。功能性需求。应该让测试人员参与需求审查，这样可以确保需求应该让测试人员参与需求审查，这样可以确保需求是可以验证的并可以作为系统测试的基础。是可以验证的并可以作为系统测