08_软件需求工程北大软件需求实现

第八章软件需求实现周立新博士北京大学软件与微电子学院课程提纲1.软件需求基本理论和概念2.软件需求工程过程3.软件需求获取4.软件需求分析5.软件需求规格说明6.软件需求验证7.软件需求管理8.软件需求实现9.软件需求工程新进展10.软件需求开发与需求管理工具内容提要•需求与其他项目过程的联系•过程改进原则及周期•需求相关的风险控制•特殊软件项目(如维护、外包等)的需求实践等8.1需求与其他项目过程的联系•需求是每个软件项目成功的核心所在，它支持其他技术活动和管理活动。•对需求开发方法和需求管理方法的变更会对项目的其他过程产生影响，反之亦然。•右图演示了需求和其他过程之间的某些连接，下面简要介绍一下这些过程之间的接口。8.1.1从需求到项目规划•由于需求定义了项目的预期成果，所以项目规划、项目预算和项目的进度安排都必须以软件需求为基础。•最重要的项目成果是交付满足业务目标的系统，而不一定是根据最初的项目规划实现所有初始需求的系统。•需求和规划只代表团队最初的评估，项目成果就是根据这一评估来完成的。•下表说明对需求工作的投资可以加速项目的开发。需求阶段投入的工作量需求阶段投入的时间开发较快的项目14%17%开发较慢的项目7%9%需求和预估•根据文本需求、图形分析模型、原型或用户界面设计来预估产品的大小。•虽然对于软件的规模没有完善的度量标准，但下面是一些常用的度量标准：–可单独测试需求的数量(Wilson1995)。–功能点和特性点的多少(Jones1996b)，或者将数据、功能和控制三者整合在一起的三维功能点的数量(Whitmire1995)。–图形用户界面(GUI)元素的数量、类型和复杂度。–用于实现特定需求所需的源代码行数。–对象类的数量或者其他面向对象系统的衡量标准(Whitmire1997)。需求和进度安排•主要的规划失误包括:忽略了公共(用)的项目任务，低估了所需的工作量和时间，没有考虑项目风险，没有考虑返工所需的时间，以及对自己的盲目乐观等。•有效的项目规划需要以下元素：–根据对需求的清楚理解来估计产品规模的大小。–根据历史记录了解到的开发团队的工作效率。–一张任务列表，以便完全地实现和验证每一特性或用例。–相当稳定的需求。–有效的预测和规划过程。–经验，这有助于项目经理对不可触及的因素和每一个项目所特有的因素加以调整。注意：不要迫于压力而许下自己明知道不可能做到的诺言，这是避免最后两败俱伤的秘诀。8.1.2从需求到设计和编码•需求和设计之间存在差别,要防止规格说明造成实现上的倾向性，除非是有迫不得已的原因要有意地对设计加以约束。•需求规格说明几乎总是包括某些设计信息，让设计人员或开发人员参与需求审查，这样可以确保需求为后续的设计打下坚实的基础。•产品的需求、质量属性和用户特点可以决定产品体系结构。从需求到设计和编码•对于同时包括软件组件和硬件组件的系统，以及只包括软件的复杂系统，体系结构就显得尤其关键。•将系统功能分配给子系统或组件必须采用自顶向下的方法(Hooks和Farry2001)。•在开始实现产品之前，虽然不需要为整个产品开发完整的、详细的设计，但是，应该先对每一个组件进行设计，然后再对其进行编码。从需求到设计和编码•下面的动作可以使所有的项目类型都从中受益：–为子系统和组件开发一个坚固的体系结构，这一体系结构在产品改进的过程中可以保持不变。–确定需要构建的主要对象类或功能模块，定义它们的接口、职责以及与其他单元的协作。–对并行处理系统，要理解计划的执行线程或对并发进程的功能分配。–根据强内聚、低耦合和信息隐藏等这些良好的设计原则，定义每个代码单元的预期功能(McConnell1993)。–确保设计满足所有的功能性需求，但不要包括不必要的功能。–确保设计能适应可能出现的异常条件。–确保设计能达到所陈述的性能、健壮性、可靠性和其他一些质量属性的目标。8.1.3从需求到测试•测试和需求工程是一种互相促进的关系。•需求是系统测试的基础，对产品的测试应该根据需求文档中所记录的产品的预期行为来进行，而不应该根据设计或编码来测试。•项目测试人员应该确定他们如何验证每一条需求，下面列出了一些可能的方法：–测试(执行软件以便发现缺陷)。–审查(检查代码，以便确保代码满足了需求)。–演示(显示产品的运作与所期望的相符)。–分析(推导在某些情况下系统应该如何运作)。•基于规格说明的测试可以运用若干测试设计策略：动作驱动、数据驱动(包括边界值分析和等价类划分)、逻辑驱动、事件驱动和状态驱动(Poston1996)。8.1.4从需求到成功•使项目更成功的一种方法是，列出与特定的代码版本相对应的所有需求。•项目的质量保证(qualityassurance，QA)小组通过对照相应的需求来执行测试，从而对每一个版本进行评估。这个项目的成功，在很大程度上得益于根据需求文档来决定何时发布产品。•软件开发项目最终的可交付工件应该是一个满足客户需要和期望的软件系统。•需求是从业务需要通向用户满意之路中必不可少的一步。•如果不以高质量的需求作为项目规划、软件设计和系统测试的基础，那么在试图发布优秀产品的过程中将浪费大量的工作。•精确的规格说明与可将产品失败的风险降至可接受程度的编码之间做出明智的选择。8.2.1软件过程改进的基本原则•应该牢记下面4条软件过程改进的原则(Wiegers1996a)：–1.过程改进应该是不断演化的、连续的、周期性的•不要期望一次就能改进全部过程，要知道在第1次尝试变更时，可能无法解决所有问题。–2.只有人们和组织具有变更的动机时才可能实施变更•下面列出了一些典型的问题，也许能为需求过程的变更提供驱动力：–项目超出了最后期限，原因是需求比预期的扩展了很多，也复杂了很多。–开发人员频繁加班，原因是直到开发后期才发现了引起误解的需求和表达不明确的需求。–系统测试工作前功尽弃，原因是测试人员并没有弄清楚产品应该做什么。–虽然正确的功能都实现了，但是用户不满意，这是由于性能不好、易使用性差或存在其他质量缺陷。–维护费用很高，因为客户的对产品的许多增强要求没有在需求获取阶段确定下来。–开发组织名誉受损，因为客户不接受交付的软件。–3.过程变更要有的放矢•在开始运用更好的过程之前，一定要明确变更的目标是什么(PotterandSakry2002)。–4.将改进活动视作小型项目•项目的总体计划应该包括过程改进的资源和任务。与所有项目一样，改进项目也要执行计划、跟踪、测量和报告，只是规模相应地缩小了。8.2.2过程改进周期•右图是一个有效的过程改进周期。•这一方法反映了您在执行下一个任务之前先清楚自己所处位置的重要性；反映了绘制过程路线图的必要性，以及以往的经验在持续的过程改进中的重要性。评估当前方法发现和建议新过程是否达到了预期目标规划改进活动活动计划建立，实验并实现新过程新过程；实验结果；初次结果计划下一个改进周期活动规划过程进行得如何？这一过程进行得如何？评估结果8.2.2.1评估当前用的方法•所有改进活动的第1步都是评估组织当前所使用的方法，找出这些方法的优点和缺陷。•设计结构化问卷表是一种更系统的方法，它能够以较低的费用对当前过程进行评估。与团队成员进行面谈和讨论，可以更准确更全面地了解当前的过程。8.2.2.2规划改进活动•战略性计划描述了组织的总体软件过程改进，战术性的活动计划则描述需要改进的专门领域。•需求管理改进计划，它包括下面这些活动条目：–1.起草一个需求变更控制过程草案。–2.评审并修订变更控制过程。–3.在项目A中试验变更控制过程。–4.根据试验的反馈信息，修订变更控制过程。–5.评估问题跟踪工具，并从中选择一种工具来支持变更控制过程。–6.购买并定制问题跟踪工具以支持变更控制过程。–7.在组织中使用新的变更控制过程和工具。8.2.2.3建立、实验并实现新过程•实现活动计划意味着开发一些过程，并相信这些过程比当前的工作方式会带来更好的结果，但不要期望新的过程第1次试用就很完美。•请牢记下面这些关于指导过程实验的建议：–选择实验参与者，他们将尝试新方法并提供有用的反馈信息。–使改进过程的结果容易解释。–确定需要了解实验情况和实验原因的有关涉众。–考虑在不同的项目中实验新过程的不同部分，这样可以使更多的人尝试新方法，因此提高了了解程度，增加了反馈信息，更易于大家接受。–询问实验参与者。8.2.2.4评估结果•过程改进周期的最后一步是评估完成的活动和取得的成果，这种评估有助于团队在未来的改进活动中做得更好。•评估内容包括判断实验进行得是否顺利，在解决新过程的不确定性方面是否有效，下一次指导过程实验时是否需要做些变更。•同时还要考虑新过程的总体执行情况是否顺利，包括新过程或模板的可用性是否有效地传达给了每一个人，参与者是否理解并成功地应用了新过程，下次工作中是否需要有所变更等。•其中关键的一步是，评估新实现的过程是否带来了期望的结果。8.3.1软件风险管理基本原理•除了与项目范围和需求有关的风险外，项目还面临着许多其他风险。•对外部实体的依赖就是一种常见的风险来源。•项目管理一直面临各种风险的挑战：评估不准确、管理人员拒绝开发人员的准确评估、对项目状态不了解以及进行了人员调整等原因所引起的风险。•技术风险威胁着高度复杂或很前沿的开发项目。•知识的缺乏是风险的另一种来源，另外还有参与者对所用的技术或项目应用领域经验不足。经常变更的或强制执行的一些政府规定可能会使最好的项目规划彻底作废。8.3.1.1风险管理的要素•风险管理(riskmanagement)就是使用某些工具和步骤把项目风险限制在一个可接受的范围内。•风险管理提供了一种标准的方法，可以指出风险因素并将其编写成文档，评估这些风险的潜在威胁，并提出减少这些风险因素的战略(Williams，Walker和Dorofee1997)。•风险管理包括下图所示的这些活动。•风险评估(riskassessment)是一个对项目进行检查以确定潜在风险领域的过程。•风险避免(riskavoidance)是处理风险的一种方法，也就是尽量不要做冒险的事。风险管理评估避免控制识别分析优先级管理计划解决方案监控8.3.1.2编写项目风险文档•只是认识到项目所面临的风险是远远不够的，我们还必须以某种方式对风险进行管理，以便在整个项目开发过程中可以将风险问题和状态传达给项目的涉众。•右图展示了一个模板，用于对单个风险编写文档。风险条目跟踪模板ID号：顺序号确定日期：风险的确认日期撤消日期：风险的撤消日期描述：以“条件-结果”的形式描述风险可能性：风险转变为问题的可能性影响：如果风险转变为问题会有多大的潜在危害危害值：可能性×影响降低风险计划：一种或多种控制、避免、最小化或降低风险的方法负责人：负责解决这一风险的人截止日期：完成降低风险活动的截止日期8.3.1.3制定风险管理计划•对于小型项目，可以把控制风险的计划包括在软件项目管理计划内。•但对一个大型项目，则应该编写一个单独的风险管理计划，详细说明打算采用哪些方法来识别、评估、编档和跟踪风险。这一计划还应该包括风险管理活动的角色和职责。•风险管理计划模板可以从获得。•要建立起周期性进行风险监控的措施。注意：不要想当然地以为，在识别出了风险并采取了降低风险的相应活动之后，风险就会处于您的控制之下。接下来还要实行风险管理活动。8.3.2与需求相关的风险•下面介绍的这些风险因素，是按照需求工程的分支过程组织的，即需求获取、需求分析、编写需求规格说明、需求确认和需求管理过程。•推荐的方法可以减小风险发生的可能性或风险发生后给项目造成的影响。8.3.2.1需求获取•产品前景和项目范围–应该在项目早期，编写一份包括业务需求在内的前景和范围文档，并将它作为添加新需求和修改现有需求的指导。•需求开发所需的时间–将每个项目中需求开发所耗费的实际工作量记录下来，这样就可以判断出需求开发是否充分，并可以改进未来项目的工