需求开发向设计规划的转化.pptx

1 1S Softwareoftware R Requirementsequirements E Engineeringngineering软件需求工程软件需求工程 郑州大学软件学院郑州大学软件学院 软件工程专业必修课程软件工程专业必修课程授课对象授课对象:本科本科3 3年级年级授课教师授课教师:徐强徐强22需求开发向设计规划的转化需求开发向设计规划的转化33本章内容本章内容从需求到项目规划从需求到项目规划从需求到设计和编码从需求到设计和编码从需求到测试从需求到测试从需求到成功从需求到成功44从需求到项目规划从需求到项目规划由于需求定由于需求定义了了项目的目的预期成果，所以期成果，所以项目目规划、划、项目目预算和算和项目的目的进度安排都必度安排都必须以以软件需求件需求为基基础。最重要的最重要的项目成果是交付目成果是交付满足足业务目目标的系的系统，而不一，而不一定是根据最初的定是根据最初的项目目规划划实现所有初始需求的系所有初始需求的系统。需求和需求和规划只代表划只代表团队最初的最初的评估，估，项目成果就是根据目成果就是根据这一一评估来完成的。估来完成的。下表下表说明明对需求工作的投需求工作的投资可以加速可以加速项目的开目的开发。需求阶段投入的工作量需求阶段投入的工作量需求阶段投入的时间需求阶段投入的时间开发较快的项目开发较快的项目 14%14%17%17%开发较慢的项目开发较慢的项目 7%7%9%9%55需求和进度安排需求和进度安排许多多软件工程件工程实行行“从右到左的从右到左的进度安排度安排”，此，此时，规定了定了发行行产品的具体日期而后定品的具体日期而后定义产品的需求。当开品的需求。当开发者要者要实现预期期质量量标准下所有要求的功能准下所有要求的功能时，他，他们常常常常不能按不能按时完成完成项目。目。在做出在做出详细的的规划和划和约定之前定定之前定义软件需求是更件需求是更现实的。的。然而，如果你在需求的哪些部分能适然而，如果你在需求的哪些部分能适应进度安排的限制度安排的限制哪些部分不能适哪些部分不能适应进度安排的限制度安排的限制这一一问题上上还有商量有商量余地的余地的话，那么，那么“从从设计到到进度安排度安排”的策略是可以起的策略是可以起作用的。作用的。对于复于复杂的系的系统，软件件仅是最是最终产品的一部分品的一部分时，只有，只有在在产品品级（系（系统）需求）需求产生以后，才能建立高生以后，才能建立高层的的进度度安排。安排。66需求和进度安排需求和进度安排可能考可能考虑按按阶段段规划和提供划和提供项目目资金。金。需求探索作需求探索作为第一第一阶段将提供足段将提供足够的信息，使你能的信息，使你能为一一个或更多的构造个或更多的构造阶段段进行行现实的的规划和划和预测。具有不确定需求的具有不确定需求的项目也可以从反复或目也可以从反复或渐增的增的软件开件开发生存期中得以改善。生存期中得以改善。定定义需求的需求的优先先级可以使你判断出哪些功能可以使你判断出哪些功能应包括在首包括在首发版中，哪些功能放到随后版中，哪些功能放到随后发行的版本中。行的版本中。77需求和进度安排需求和进度安排主要的主要的规划失划失误包括：忽略公共（用）的包括：忽略公共（用）的项目任目任务，低，低估了要花估了要花费的工作量和的工作量和时间，没有考，没有考虑项目目风险，并且，并且没有考没有考虑返工所需的返工所需的时间。正确的正确的项目目规划需要以下元素：划需要以下元素：根据根据对需求的清楚理解来估需求的清楚理解来估计产品品规模的大小。模的大小。根据根据历史史记录了解开了解开发小小组的工作效率。的工作效率。一一张综合的任合的任务列表以完整列表以完整实现和和验证每一特性或使用每一特性或使用实例。例。有效的有效的预测和和规划划过程。程。经验（这有助于有助于项目目经理理对不可触及的因素和每一个不可触及的因素和每一个项目所特目所特有的因素加以有的因素加以调整）。整）。注意：不要迫于注意：不要迫于压力而力而许下自己明知道不可能做到的下自己明知道不可能做到的诺言，言，这是避免最后两是避免最后两败俱俱伤的秘的秘诀。88需求和预估需求和预估项目估目估计（预估）的第一步就是要把需求和估）的第一步就是要把需求和软件件产品品规模的大小相模的大小相联系。系。你可以根据文本需求、你可以根据文本需求、图形分析模型、原型或用形分析模型、原型或用户界面界面设计来来预估估产品的大小。品的大小。虽然然对于于软件大小没有完善的度量件大小没有完善的度量标准，但以下准，但以下给出了出了一些常用的度量一些常用的度量标准：准：功能点和特性点的多少，或者将数据、功能和控制三者整合在功能点和特性点的多少，或者将数据、功能和控制三者整合在一起的三一起的三维功能点的数量。功能点的数量。图形用形用户界面（界面（G U I）元素的数量、）元素的数量、类型和复型和复杂度。度。用于用于实现特定需求所需的源代特定需求所需的源代码行数。行数。对象象类的数量或者其它面向的数量或者其它面向对象系象系统的衡量的衡量标准。准。单个可个可测试需求的数量。需求的数量。99需求和预估需求和预估含糊的和不确定的需求必定会引起你在含糊的和不确定的需求必定会引起你在软件大小件大小预估中估中的的不确定性不确定性，从而，从而导致你的工作量和致你的工作量和进度安排度安排预估的估的不不确定确定。在在项目的早期目的早期阶段，需求的不确定性是段，需求的不确定性是不可避免不可避免的，所的，所以在以在进度安排中度安排中应包括包括临时的事件并要合理的事件并要合理预算算资金以金以适适应一些需求的增加和可能的超限。一些需求的增加和可能的超限。开开发时间与与产品大小或开品大小或开发小小组的大小的大小没有没有线性关系性关系。在在产品大小、工作量、开品大小、工作量、开发时间、生、生产率和人率和人员技技术积累累时间之之间是存在着复是存在着复杂的关系。理解的关系。理解这种关系可以防种关系可以防止你陷入止你陷入进度安排或人度安排或人员任任务安排承安排承诺的的误区。区。1010本章内容本章内容从需求到项目规划从需求到项目规划从需求到设计和编码从需求到设计和编码从需求到测试从需求到测试从需求到成功从需求到成功1111从需求到设计和编码从需求到设计和编码需求和需求和设计之之间存在存在差差别，但尽量使你的，但尽量使你的规格格说明的具明的具体体实现无无倾向性。向性。需求开需求开发和和规格格说明明应该强调对预期系期系统外部行外部行为的理的理解和描述。解和描述。让设计者和开者和开发者参与需求者参与需求审查以判断需求以判断需求是否可以作是否可以作为设计的基的基础。如果直接从需求如果直接从需求规格格说明跳到明跳到编码阶段，你所段，你所设计的的软件将会是空中件将会是空中阁楼，其可能的楼，其可能的结果只能是果只能是结构性很差的构性很差的一个一个软件。在构造件。在构造软件之前，件之前，应该仔仔细考考虑构造系构造系统的的最有效的方法。最有效的方法。设计上的返工比上的返工比编码返工可能要效率高一些。返工可能要效率高一些。1212从需求到设计和编码从需求到设计和编码产品的需求、品的需求、质量属性和用量属性和用户特点可以决定特点可以决定产品体系品体系结构。构。对于同于同时包括包括软件件组件和硬件件和硬件组件的系件的系统，以及只包括，以及只包括软件的复件的复杂系系统，体系体系结构就构就显得尤其关得尤其关键。将系将系统功能分配功能分配给子系子系统或或组件必件必须采用采用自自顶向下向下的方的方法。法。在开始在开始实现产品之前，品之前，虽然不需要然不需要为整个整个产品开品开发完整完整的、的、详细的的设计，但是，但是，应该先先对每一个每一个组件件进行行设计，然后再然后再对其其进行行编码。设计规划将有益于大划将有益于大难度度项目（有目（有许多内部多内部组件接口和件接口和交互作用的系交互作用的系统和开和开发人人员无无经验的的项目）。目）。1313从需求到设计和编码从需求到设计和编码下面介下面介绍的步的步骤将有益于所有的将有益于所有的项目：目：为子系子系统和和组件开件开发一个一个坚固的体系固的体系结构构，这一体系一体系结构在构在产品改品改进的的过程中可以保持不程中可以保持不变。确定需要构建的主要确定需要构建的主要对象象类或功能模或功能模块，定，定义它它们的接口、的接口、职责以及与其他以及与其他单元的元的协作。作。对并行并行处理系理系统，要理解，要理解计划的划的执行行线程或程或对并并发进程的功能程的功能分配。分配。根据根据强内聚、低耦合和信息内聚、低耦合和信息隐藏藏等等这些良好的些良好的设计原原则，定，定义每个代每个代码单元的元的预期功能。期功能。确保确保设计满足所有的功能性需求，但不要包括不必要的功能。足所有的功能性需求，但不要包括不必要的功能。确保确保设计能适能适应可能出可能出现的的异常条件异常条件。确保确保设计能达到所能达到所陈述的性能、健壮性、可靠性和其他一些述的性能、健壮性、可靠性和其他一些质量属性的目量属性的目标。1414从需求到设计和编码从需求到设计和编码当开当开发者把需求者把需求转化化为设计和代和代码时，他，他们将会遇到将会遇到不不确定和混淆确定和混淆的地方。的地方。理想情况下，开理想情况下，开发者可沿着者可沿着发生的生的问题回溯回溯至客至客户并并获得解决方案。得解决方案。如果不能如果不能马上解决上解决问题，那么开，那么开发者所做出的任何假者所做出的任何假设，猜想或解猜想或解释都要都要编写成文档写成文档记录下来，并由客下来，并由客户代表代表评审。1515本章内容本章内容从需求到项目规划从需求到项目规划从需求到设计和编码从需求到设计和编码从需求到测试从需求到测试从需求到成功从需求到成功1616从需求到测试从需求到测试详尽的需求是系尽的需求是系统测试的的基基础。必必须针对软件需求件需求规格格说明中所明中所记录的的产品的品的预期行期行为来来测试整个整个软件件，而不是，而不是针对设计或或编码。产品可以正确呈品可以正确呈现基于代基于代码的的测试用例所描述的所有行用例所描述的所有行为，但，但这并不意味着并不意味着产品正确地品正确地实现了了用用户的需求的需求。让测试人人员参与需求参与需求审查以确保需求是明确的，以确保需求是明确的，通通过验证的需求的需求才可以作才可以作为系系统测试的基的基础。1717从需求到测试从需求到测试在需求开在需求开发中，当每个需求都中，当每个需求都稳定之后，定之后，项目的系目的系统测试人人员应该编写文档，以写文档，以记录他他们如何如何验证需求需求通通过测试、审查，演示或分析。，演示或分析。对如何如何验证每一需求的思考每一需求的思考过程本身就是一种很有用的程本身就是一种很有用的质量量审查实践践。根据需求中的。根据需求中的逻辑描述，利用描述，利用诸如因果如因果图等分析技等分析技术来来获得得测试用例，用例，这将会揭示需求的二将会揭示需求的二义性、性、遗漏或漏或隐含的其它条件和其它含的其它条件和其它问题。在系在系统测试方案中，每个需求方案中，每个需求应至少至少由一个由一个测试用例来用例来测试，这样就会就会验证所有的系所有的系统行行为。可以由跟踪通。可以由跟踪通过测试的需求所占的比例来衡量的需求所占的比例来衡量测试进度。度。1818从需求到测试从需求到测试基于基于规格格说明的明的测试适用于适用于许多多测试设计策略：策略：动作作驱动数据数据驱动（包括（包括边界界值分析和等价分析和等价类的划分）的划分）逻辑驱动事件事件驱动状状态驱动从正式的从正式的规格格说明中很容易明中很容易自自动生成生成测试用例，但是用例，但是对于更多的由自然于更多的由自然语言描述的需求言描述的需求规格格说明，必明，必须手手工开工开发测试用例。用例。比起比起结构化分析构化分析图，对象模型象模型更易于自更易于自动生成生成测试用用例。例。1919从需求到测试从需求到测试在开在开发的的进展展过程中，你将通程中，你将通过详细的的软件功能需求件功能需求仔仔细推敲来自使用推敲来自使用实例高例高层抽象的需求，并最抽象的需求，并最终转化化成成单个代个代码模模块的的规格格说明。明。针对需求的需求的测试必必须在在软件件结构的每一构的每一层进行，而不行，而不只是在用只是在用户层进行。在一个行。在一个应用程序中有用程序中有许多代多代码不不会被用会被用户所所访问，但，但这些代些代码却是却是产品基品基础操作所需操作所需要的。要的。即使有些模即使有些模块功能在整个功能在整个软件件产品中品中对用用户都不可都不可见，但是每个模但是每个模块功能必功能必须满足其自身的需求或足其自身的需求或规格格说明明要求。要求。针对用用户需求来需求来测试系系统是系是系统测试的必要但非充分的必要但非充分条件。条件。2020本章内容本章内容从需求到项目规划从需求到项目规划从需求到设计和编码从需求到设计和编码从需求到测试从需求到测试从需求到成功从需求到成功2121从需求到成功从需求到成功使使项目更成功的一种方法是，列出与特定的代目更成功的一种方法是，列出与特定的代码版本版本相相对应的所有需求。的所有需求。项目的目的质量保量保证(quality assurance(quality assurance，QA)QA)小小组通通过对照相照相应的需求来的需求来执行行测试，从而，从而对每一个版本每一个版本进行行评估。估。这个个项目的成功，在很大程度上得益于根据需求目的成功，在很大程度上得益于根据需求文档来决定何文档来决定何时发布布产品。品。软件开件开发项目最目最终的可交付工件的可交付工件应该是一个是一个满足客足客户需要和期望的需要和期望的软件系件系统。需求是从需求是从业务需要通向用需要通向用户满意之路中必不可少的一步意之路中必不可少的一步。努力在精确的努力在精确的规格格说明与可将明与可将产品失品失败的的风险降至可降至可接受程度的接受程度的编码之之间做出做出明智的明智的选择。