需求开发向设计规划的转化课件.ppt

1、1 1S Softwareoftware R Requirementsequirements E Engineeringngineering软件需求工程软件需求工程 授课对象授课对象:本科本科3 3年级年级授课教师授课教师:徐强徐强2233从需求到项目规划从需求到项目规划从需求到设计和编码从需求到设计和编码从需求到测试从需求到测试从需求到成功从需求到成功44由于需求定义了项目的预期成果，所以项目规划、项目由于需求定义了项目的预期成果，所以项目规划、项目预算和项目的进度安排都必须以软件需求为基础。预算和项目的进度安排都必须以软件需求为基础。最重要的项目成果是交付满足业务目标的系统，而不一最重要的

2、项目成果是交付满足业务目标的系统，而不一定是根据最初的项目规划实现所有初始需求的系统。定是根据最初的项目规划实现所有初始需求的系统。需求和规划只代表团队最初的评估，项目成果就是根据需求和规划只代表团队最初的评估，项目成果就是根据这一评估来完成的。这一评估来完成的。下表说明对需求工作的投资可以加速项目的开发。下表说明对需求工作的投资可以加速项目的开发。需求阶段投入的工作量需求阶段投入的工作量需求阶段投入的时间需求阶段投入的时间开发较快的项目开发较快的项目 14%14%17%17%开发较慢的项目开发较慢的项目 7%7%9%9%55许多软件工程实行许多软件工程实行“从右到左的进度安排从右到左的进度安

3、排”，此时，规，此时，规定了发行产品的具体日期而后定义产品的需求。当开发定了发行产品的具体日期而后定义产品的需求。当开发者要实现预期质量标准下所有要求的功能时，他们常常者要实现预期质量标准下所有要求的功能时，他们常常不能按时完成项目。不能按时完成项目。在做出详细的规划和约定之前定义软件需求是更现实的。在做出详细的规划和约定之前定义软件需求是更现实的。然而，如果你在需求的哪些部分能适应进度安排的限制然而，如果你在需求的哪些部分能适应进度安排的限制哪些部分不能适应进度安排的限制这一问题上还有商量哪些部分不能适应进度安排的限制这一问题上还有商量余地的话，那么余地的话，那么“从设计到进度安排从设计到进

4、度安排”的策略是可以起的策略是可以起作用的。作用的。对于复杂的系统，软件仅是最终产品的一部分时，只有对于复杂的系统，软件仅是最终产品的一部分时，只有在产品级（系统）需求产生以后，才能建立高层的进度在产品级（系统）需求产生以后，才能建立高层的进度安排。安排。66可能考虑按阶段规划和提供项目资金。可能考虑按阶段规划和提供项目资金。需求探索作为第一阶段将提供足够的信息，使你能为一需求探索作为第一阶段将提供足够的信息，使你能为一个或更多的构造阶段进行现实的规划和预测。个或更多的构造阶段进行现实的规划和预测。具有不确定需求的项目也可以从反复或渐增的软件开发具有不确定需求的项目也可以从反复或渐增的软件开发

5、生存期中得以改善。生存期中得以改善。定义需求的优先级可以使你判断出哪些功能应包括在首定义需求的优先级可以使你判断出哪些功能应包括在首发版中，哪些功能放到随后发行的版本中。发版中，哪些功能放到随后发行的版本中。77主要的规划失误包括：忽略公共（用）的项目任务，低主要的规划失误包括：忽略公共（用）的项目任务，低估了要花费的工作量和时间，没有考虑项目风险，并且估了要花费的工作量和时间，没有考虑项目风险，并且没有考虑返工所需的时间。没有考虑返工所需的时间。正确的项目规划需要以下元素：正确的项目规划需要以下元素：根据对需求的清楚理解来估计产品规模的大小。根据对需求的清楚理解来估计产品规模的大小。根据历史

6、记录了解开发小组的工作效率。根据历史记录了解开发小组的工作效率。一张综合的任务列表以完整实现和验证每一特性或使用实例。一张综合的任务列表以完整实现和验证每一特性或使用实例。有效的预测和规划过程。有效的预测和规划过程。经验（这有助于项目经理对不可触及的因素和每一个项目所特经验（这有助于项目经理对不可触及的因素和每一个项目所特有的因素加以调整）。有的因素加以调整）。注意：不要迫于压力而许下自己明知道不可能做到的诺注意：不要迫于压力而许下自己明知道不可能做到的诺言，这是避免最后两败俱伤的秘诀。言，这是避免最后两败俱伤的秘诀。88项目估计（预估）的第一步就是要把需求和软件产品规项目估计（预估）的第一步

7、就是要把需求和软件产品规模的大小相联系。模的大小相联系。你可以根据文本需求、图形分析模型、原型或用户界面你可以根据文本需求、图形分析模型、原型或用户界面设计来预估产品的大小。设计来预估产品的大小。虽然对于软件大小没有完善的度量标准，但以下给出了虽然对于软件大小没有完善的度量标准，但以下给出了一些常用的度量标准：一些常用的度量标准：功能点和特性点的多少，或者将数据、功能和控制三者整合在功能点和特性点的多少，或者将数据、功能和控制三者整合在一起的三维功能点的数量。一起的三维功能点的数量。图形用户界面（图形用户界面（G U I）元素的数量、类型和复杂度。）元素的数量、类型和复杂度。用于实现特定需求所

8、需的源代码行数。用于实现特定需求所需的源代码行数。对象类的数量或者其它面向对象系统的衡量标准。对象类的数量或者其它面向对象系统的衡量标准。单个可测试需求的数量。单个可测试需求的数量。99含糊的和不确定的需求必定会引起你在软件大小预估中含糊的和不确定的需求必定会引起你在软件大小预估中的的不确定性不确定性，从而导致你的工作量和进度安排预估的，从而导致你的工作量和进度安排预估的不不确定确定。在项目的早期阶段，需求的不确定性是在项目的早期阶段，需求的不确定性是不可避免不可避免的，所的，所以在进度安排中应包括临时的事件并要合理预算资金以以在进度安排中应包括临时的事件并要合理预算资金以适应一些需求的增加和

9、可能的超限。适应一些需求的增加和可能的超限。开发时间与产品大小或开发小组的大小开发时间与产品大小或开发小组的大小没有线性关系没有线性关系。在产品大小、工作量、开发时间、生产率和人员技术积在产品大小、工作量、开发时间、生产率和人员技术积累时间之间是存在着复杂的关系。理解这种关系可以防累时间之间是存在着复杂的关系。理解这种关系可以防止你陷入进度安排或人员任务安排承诺的误区。止你陷入进度安排或人员任务安排承诺的误区。1010从需求到项目规划从需求到项目规划从需求到设计和编码从需求到设计和编码从需求到测试从需求到测试从需求到成功从需求到成功1111需求和设计之间存在需求和设计之间存在差别差别，但尽量使

10、你的规格说明的具，但尽量使你的规格说明的具体实现无倾向性。体实现无倾向性。需求开发和规格说明应该强调对预期系统外部行为的理需求开发和规格说明应该强调对预期系统外部行为的理解和描述。让设计者和开发者参与需求审查以判断需求解和描述。让设计者和开发者参与需求审查以判断需求是否可以作为设计的基础。是否可以作为设计的基础。如果直接从需求规格说明跳到编码阶段，你所设计的软如果直接从需求规格说明跳到编码阶段，你所设计的软件将会是空中阁楼，其可能的结果只能是结构性很差的件将会是空中阁楼，其可能的结果只能是结构性很差的一个软件。在构造软件之前，应该仔细考虑构造系统的一个软件。在构造软件之前，应该仔细考虑构造系统

11、的最有效的方法。最有效的方法。设计上的返工比编码返工可能要效率高一些。设计上的返工比编码返工可能要效率高一些。1212产品的需求、质量属性和用户特点可以决定产品体系结产品的需求、质量属性和用户特点可以决定产品体系结构。构。对于同时包括软件组件和硬件组件的系统，以及只包括对于同时包括软件组件和硬件组件的系统，以及只包括软件的复杂系统，软件的复杂系统，体系结构就显得尤其关键体系结构就显得尤其关键。将系统功能分配给子系统或组件必须采用将系统功能分配给子系统或组件必须采用自顶向下自顶向下的方的方法。法。在开始实现产品之前，虽然不需要为整个产品开发完整在开始实现产品之前，虽然不需要为整个产品开发完整的、

12、详细的设计，但是，应该先对每一个组件进行设计，的、详细的设计，但是，应该先对每一个组件进行设计，然后再对其进行编码。然后再对其进行编码。设计规划将有益于大难度项目（有许多内部组件接口和设计规划将有益于大难度项目（有许多内部组件接口和交互作用的系统和开发人员无经验的项目）。交互作用的系统和开发人员无经验的项目）。1313下面介绍的步骤将有益于所有的项目：下面介绍的步骤将有益于所有的项目：为子系统和组件开发一个为子系统和组件开发一个坚固的体系结构坚固的体系结构，这一体系结构在产，这一体系结构在产品改进的过程中可以保持不变。品改进的过程中可以保持不变。确定需要构建的主要对象类或功能模块，定义它们的接

13、口、职确定需要构建的主要对象类或功能模块，定义它们的接口、职责以及与其他单元的协作。责以及与其他单元的协作。对并行处理系统，要理解计划的执行线程或对并发进程的功能对并行处理系统，要理解计划的执行线程或对并发进程的功能分配。分配。根据根据强内聚、低耦合和信息隐藏强内聚、低耦合和信息隐藏等这些良好的设计原则，定义等这些良好的设计原则，定义每个代码单元的预期功能。每个代码单元的预期功能。确保设计满足所有的功能性需求，但不要包括不必要的功能。确保设计满足所有的功能性需求，但不要包括不必要的功能。确保设计能适应可能出现的确保设计能适应可能出现的异常条件异常条件。确保设计能达到所陈述的性能、健壮性、可靠性

14、和其他一些质确保设计能达到所陈述的性能、健壮性、可靠性和其他一些质量属性的目标。量属性的目标。1414当开发者把需求转化为设计和代码时，他们将会遇到当开发者把需求转化为设计和代码时，他们将会遇到不不确定和混淆确定和混淆的地方。的地方。理想情况下，开发者可沿着发生的问题理想情况下，开发者可沿着发生的问题回溯回溯至客户并获至客户并获得解决方案。得解决方案。如果不能马上解决问题，那么开发者所做出的任何假设，如果不能马上解决问题，那么开发者所做出的任何假设，猜想或解释都要猜想或解释都要编写成文档编写成文档记录下来，并由客户代表评记录下来，并由客户代表评审。审。1515从需求到项目规划从需求到项目规划从

15、需求到设计和编码从需求到设计和编码从需求到测试从需求到测试从需求到成功从需求到成功1616详尽的需求是系统测试的详尽的需求是系统测试的基础基础。必须针对软件需求规格说明中所记录的产品的预期行为必须针对软件需求规格说明中所记录的产品的预期行为来测试来测试整个软件整个软件，而不是针对，而不是针对设计或编码设计或编码。产品可以正确呈现基于代码的测试用例所描述的所有行产品可以正确呈现基于代码的测试用例所描述的所有行为，但这并不意味着产品正确地实现了为，但这并不意味着产品正确地实现了用户的需求用户的需求。让测试人员参与需求审查以确保需求是明确的，让测试人员参与需求审查以确保需求是明确的，通过验通过验证的

16、需求证的需求才可以作为系统测试的基础。才可以作为系统测试的基础。1717在需求开发中，当每个需求都稳定之后，项目的系统测在需求开发中，当每个需求都稳定之后，项目的系统测试人员应该编写文档，以记录他们如何验证需求试人员应该编写文档，以记录他们如何验证需求通过通过测试、审查，演示或分析。测试、审查，演示或分析。对如何验证每一需求的思考过程本身就是一种很有用的对如何验证每一需求的思考过程本身就是一种很有用的质量审查实践质量审查实践。根据需求中的逻辑描述，利用诸如因果。根据需求中的逻辑描述，利用诸如因果图等分析技术来获得测试用例，这将会揭示需求的二义图等分析技术来获得测试用例，这将会揭示需求的二义性、

17、遗漏或隐含的其它条件和其它问题。性、遗漏或隐含的其它条件和其它问题。在系统测试方案中，每个需求应在系统测试方案中，每个需求应至少至少由一个测试用例来由一个测试用例来测试，这样就会验证所有的系统行为。可以由跟踪通过测试，这样就会验证所有的系统行为。可以由跟踪通过测试的需求所占的比例来衡量测试进度。测试的需求所占的比例来衡量测试进度。1818基于规格说明的测试适用于许多测试设计策略：基于规格说明的测试适用于许多测试设计策略：o动作驱动动作驱动o数据驱动（包括边界值分析和等价类的划分）数据驱动（包括边界值分析和等价类的划分）o逻辑驱动逻辑驱动o事件驱动事件驱动o状态驱动状态驱动从正式的规格说明中很容

18、易从正式的规格说明中很容易自动生成自动生成测试用例，但是测试用例，但是对于更多的由自然语言描述的需求规格说明，必须手对于更多的由自然语言描述的需求规格说明，必须手工开发测试用例。工开发测试用例。o比起结构化分析图，比起结构化分析图，对象模型对象模型更易于自动生成测试用更易于自动生成测试用例。例。1919在开发的进展过程中，你将通过详细的软件功能需求在开发的进展过程中，你将通过详细的软件功能需求仔细推敲来自使用实例高层抽象的需求，并最终转化仔细推敲来自使用实例高层抽象的需求，并最终转化成单个代码模块的规格说明。成单个代码模块的规格说明。针对需求的测试必须在软件结构的每一层进行，而不针对需求的测试

19、必须在软件结构的每一层进行，而不只是在用户层进行。在一个应用程序中有许多代码不只是在用户层进行。在一个应用程序中有许多代码不会被用户所访问，但这些代码却是产品基础操作所需会被用户所访问，但这些代码却是产品基础操作所需要的。要的。即使有些模块功能在整个软件产品中对用户都不可见，即使有些模块功能在整个软件产品中对用户都不可见，但是每个模块功能必须满足其自身的需求或规格说明但是每个模块功能必须满足其自身的需求或规格说明要求。要求。针对用户需求来测试系统是系统测试的必要但非充分针对用户需求来测试系统是系统测试的必要但非充分条件。条件。2020从需求到项目规划从需求到项目规划从需求到设计和编码从需求到设

20、计和编码从需求到测试从需求到测试从需求到成功从需求到成功2121使项目更成功的一种方法是，列出与特定的代码版本使项目更成功的一种方法是，列出与特定的代码版本相对应的所有需求。相对应的所有需求。项目的质量保证项目的质量保证(quality assurance(quality assurance，QA)QA)小组通过对小组通过对照相应的需求来执行测试，从而对每一个版本进行评照相应的需求来执行测试，从而对每一个版本进行评估。这个项目的成功，在很大程度上得益于根据需求估。这个项目的成功，在很大程度上得益于根据需求文档来决定何时发布产品。文档来决定何时发布产品。软件开发项目最终的可交付工件应该是一个满足客户软件开发项目最终的可交付工件应该是一个满足客户需要和期望的软件系统。需要和期望的软件系统。需求是从业务需要通向用户需求是从业务需要通向用户满意之路中必不可少的一步满意之路中必不可少的一步。努力在精确的规格说明与可将产品失败的风险降至可努力在精确的规格说明与可将产品失败的风险降至可接受程度的编码之间做出接受程度的编码之间做出明智的选择明智的选择。