第08讲软件需求实现_第1页
第08讲软件需求实现_第2页
第08讲软件需求实现_第3页
第08讲软件需求实现_第4页
第08讲软件需求实现_第5页
已阅读5页,还剩33页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、第八章第八章 软件需求实现软件需求实现课程提纲课程提纲1.1.软件需求基本理论和概念软件需求基本理论和概念 2.2.软件需求工程过程软件需求工程过程 3.3.软件需求获取软件需求获取 4.4.软件需求分析软件需求分析 5.5.软件需求规格说明软件需求规格说明 6.6.软件需求验证软件需求验证 7.7.软件需求管理软件需求管理 8.8.软件需求实现软件需求实现 9.9.软件需求工程新进展软件需求工程新进展 10.10. 软件需求开发与需求管理工具软件需求开发与需求管理工具内容提要需求与其他项目过程的需求与其他项目过程的联系联系过程改进原则及周期过程改进原则及周期需求相关的风险控制需求相关的风险控

2、制特殊软件项目特殊软件项目(如维护、如维护、外包等外包等)的需求实践等的需求实践等 8.1 需求与其他需求与其他项目过程的联系项目过程的联系 需求是每个软件项目成功需求是每个软件项目成功的核心所在,它支持其他的核心所在,它支持其他技术活动和管理活动。技术活动和管理活动。 对需求开发方法和需求管对需求开发方法和需求管理方法的变更会对项目的理方法的变更会对项目的其他过程产生影响,反之其他过程产生影响,反之亦然。亦然。 右图演示了需求和其他过右图演示了需求和其他过程之间的某些连接,下面程之间的某些连接,下面简要介绍一下这些过程之简要介绍一下这些过程之间的接口间的接口。8.1.1 从需求到项目规划从需

3、求到项目规划 由于需求定义了项目的预期成果,所以项目规划、项由于需求定义了项目的预期成果,所以项目规划、项目预算和项目的进度安排都必须以软件需求为基础。目预算和项目的进度安排都必须以软件需求为基础。 最重要的项目成果是交付满足业务目标的系统,而不最重要的项目成果是交付满足业务目标的系统,而不一定是根据最初的项目规划实现所有初始需求的系统。一定是根据最初的项目规划实现所有初始需求的系统。 需求和规划只代表团队最初的评估,项目成果就是根需求和规划只代表团队最初的评估,项目成果就是根据这一评估来完成的。据这一评估来完成的。 下表说明对需求工作的投资可以加速项目的开发。下表说明对需求工作的投资可以加速

4、项目的开发。需求阶段投入的工作量需求阶段投入的工作量 需求阶段投入的时间需求阶段投入的时间 开发较快的项目开发较快的项目 14%14% 17%17% 开发较慢的项目开发较慢的项目 7%7% 9%9% 需求和预估需求和预估 根据文本需求、图形分析模型、原型或用户界面根据文本需求、图形分析模型、原型或用户界面设计来预估产品的大小。设计来预估产品的大小。 虽然对于软件的规模没有完善的度量标准,但下虽然对于软件的规模没有完善的度量标准,但下面是一些常用的度量标准:面是一些常用的度量标准: 可单独测试需求的数量可单独测试需求的数量(Wilson 1995)。 功能点和特性点的多少功能点和特性点的多少(J

5、ones 1996b),或者将数据、,或者将数据、功能和控制三者整合在一起的三维功能点的数量功能和控制三者整合在一起的三维功能点的数量(Whitmire 1995)。 图形用户界面图形用户界面(GUI)元素的数量、类型和复杂度。元素的数量、类型和复杂度。 用于实现特定需求所需的源代码行数。用于实现特定需求所需的源代码行数。 对象类的数量或者其他面向对象系统的衡量标准对象类的数量或者其他面向对象系统的衡量标准(Whitmire 1997)。需求和进度安排需求和进度安排 主要的规划失误包括主要的规划失误包括: 忽略了公共忽略了公共(用用)的的项目任务,低估了所需的工作量和时间,项目任务,低估了所需

6、的工作量和时间,没有考虑项目风险,没有考虑返工所需的没有考虑项目风险,没有考虑返工所需的时间,以及对自己的盲目乐观等。时间,以及对自己的盲目乐观等。 有效的项目规划需要以下元素:有效的项目规划需要以下元素: 根据对需求的清楚理解来估计产品规模的大小。根据对需求的清楚理解来估计产品规模的大小。 根据历史记录了解到的开发团队的工作效率。根据历史记录了解到的开发团队的工作效率。 一张任务列表,以便完全地实现和验证每一特一张任务列表,以便完全地实现和验证每一特性或用例。性或用例。 相当稳定的需求。相当稳定的需求。 有效的预测和规划过程。有效的预测和规划过程。 经验,这有助于项目经理对不可触及的因素和经

7、验,这有助于项目经理对不可触及的因素和每一个项目所特有的因素加以调整。每一个项目所特有的因素加以调整。注意:不要迫于压力而许下自己明知道不可能做到的诺言,这是避免最后两败俱伤的秘诀。 8.1.2 从需求到设计和编码从需求到设计和编码 需求和设计之间存在差别需求和设计之间存在差别, 要防止规格说要防止规格说明造成实现上的倾向性,除非是有迫不得明造成实现上的倾向性,除非是有迫不得已的原因要有意地对设计加以约束。已的原因要有意地对设计加以约束。 需求规格说明几乎总是包括某些设计信息,需求规格说明几乎总是包括某些设计信息,让设计人员或开发人员参与需求审查,这让设计人员或开发人员参与需求审查,这样可以确

8、保需求为后续的设计打下坚实的样可以确保需求为后续的设计打下坚实的基础。基础。 产品的需求、质量属性和用户特点可以决产品的需求、质量属性和用户特点可以决定产品体系结构。定产品体系结构。从需求到设计和编码从需求到设计和编码 对于同时包括软件组件和硬件组件的系统,对于同时包括软件组件和硬件组件的系统,以及只包括软件的复杂系统,体系结构就显以及只包括软件的复杂系统,体系结构就显得尤其关键。得尤其关键。 将系统功能分配给子系统或组件必须采用自将系统功能分配给子系统或组件必须采用自顶向下的方法顶向下的方法(Hooks和和Farry 2001)。 在开始实现产品之前,虽然不需要为整个产在开始实现产品之前,虽

9、然不需要为整个产品开发完整的、详细的设计,但是,应该先品开发完整的、详细的设计,但是,应该先对每一个组件进行设计,然后再对其进行编对每一个组件进行设计,然后再对其进行编码。码。从需求到设计和编码从需求到设计和编码 下面的动作可以使所有的项目类型都从中受益:下面的动作可以使所有的项目类型都从中受益: 为子系统和组件开发一个坚固的体系结构,这一体系结构在为子系统和组件开发一个坚固的体系结构,这一体系结构在产品改进的过程中可以保持不变。产品改进的过程中可以保持不变。 确定需要构建的主要对象类或功能模块,定义它们的接口、确定需要构建的主要对象类或功能模块,定义它们的接口、职责以及与其他单元的协作。职责

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

11、、可靠性和其他一些质量属性的目标。质量属性的目标。 8.1.3 从需求到测试从需求到测试 测试和需求工程是一种互相促进的关系。测试和需求工程是一种互相促进的关系。 需求是系统测试的基础,对产品的测试应该根据需求文档需求是系统测试的基础,对产品的测试应该根据需求文档中所记录的产品的预期行为来进行,而不应该根据设计或中所记录的产品的预期行为来进行,而不应该根据设计或编码来测试。编码来测试。 项目测试人员应该确定他们如何验证每一条需求,下面列项目测试人员应该确定他们如何验证每一条需求,下面列出了一些可能的方法:出了一些可能的方法: 测试测试(执行软件以便发现缺陷执行软件以便发现缺陷)。 审查审查(检

12、查代码,以便确保代码满足了需求检查代码,以便确保代码满足了需求)。 演示演示(显示产品的运作与所期望的相符显示产品的运作与所期望的相符)。 分析分析(推导在某些情况下系统应该如何运作推导在某些情况下系统应该如何运作)。 基于规格说明的测试可以运用若干测试设计策略:动作驱基于规格说明的测试可以运用若干测试设计策略:动作驱动、数据驱动动、数据驱动(包括边界值分析和等价类划分包括边界值分析和等价类划分)、逻辑驱动、逻辑驱动、事件驱动和状态驱动事件驱动和状态驱动(Poston 1996)。 8.1.4 从需求到成功从需求到成功 使项目更成功的一种方法是,列出与特定的代码版本相对使项目更成功的一种方法是

13、,列出与特定的代码版本相对应的所有需求。应的所有需求。 项目的质量保证项目的质量保证(quality assurance,QA)小组通过对照小组通过对照相应的需求来执行测试,从而对每一个版本进行评估。这相应的需求来执行测试,从而对每一个版本进行评估。这个项目的成功,在很大程度上得益于根据需求文档来决定个项目的成功,在很大程度上得益于根据需求文档来决定何时发布产品。何时发布产品。 软件开发项目最终的可交付工件应该是一个满足客户需要软件开发项目最终的可交付工件应该是一个满足客户需要和期望的软件系统。和期望的软件系统。 需求是从业务需要通向用户满意之路中必不可少的一步。需求是从业务需要通向用户满意之

14、路中必不可少的一步。 如果不以高质量的需求作为项目规划、软件设计和系统测如果不以高质量的需求作为项目规划、软件设计和系统测试的基础,那么在试图发布优秀产品的过程中将浪费大量试的基础,那么在试图发布优秀产品的过程中将浪费大量的工作。的工作。 精确的规格说明与可将产品失败的风险降至可接受程度的精确的规格说明与可将产品失败的风险降至可接受程度的编码之间做出明智的选择。编码之间做出明智的选择。 8.2.1 软件过程改进的基本原则软件过程改进的基本原则 应该牢记下面应该牢记下面4条软件过程改进的原则条软件过程改进的原则(Wiegers 1996a): 1.过程改进应该是不断演化的、连续的、周期性的过程改

15、进应该是不断演化的、连续的、周期性的 不要期望一次就能改进全部过程,要知道在第不要期望一次就能改进全部过程,要知道在第1次尝试变更时,可能无法解次尝试变更时,可能无法解决所有问题。决所有问题。 2.只有人们和组织具有变更的动机时才可能实施变更只有人们和组织具有变更的动机时才可能实施变更 下面列出了一些典型的问题,也许能为需求过程的变更提供驱动力:下面列出了一些典型的问题,也许能为需求过程的变更提供驱动力: 项目超出了最后期限,原因是需求比预期的扩展了很多,也复杂了很多。项目超出了最后期限,原因是需求比预期的扩展了很多,也复杂了很多。 开发人员频繁加班,原因是直到开发后期才发现了引起误解的需求和

16、表达不明确的需开发人员频繁加班,原因是直到开发后期才发现了引起误解的需求和表达不明确的需求。求。 系统测试工作前功尽弃,原因是测试人员并没有弄清楚产品应该做什么。系统测试工作前功尽弃,原因是测试人员并没有弄清楚产品应该做什么。 虽然正确的功能都实现了,但是用户不满意,这是由于性能不好、易使用性差或存在虽然正确的功能都实现了,但是用户不满意,这是由于性能不好、易使用性差或存在其他质量缺陷。其他质量缺陷。 维护费用很高,因为客户的对产品的许多增强要求没有在需求获取阶段确定下来。维护费用很高,因为客户的对产品的许多增强要求没有在需求获取阶段确定下来。 开发组织名誉受损,因为客户不接受交付的软件。开发

17、组织名誉受损,因为客户不接受交付的软件。 3.过程变更要有的放矢过程变更要有的放矢 在开始运用更好的过程之前,一定要明确变更的目标是什么在开始运用更好的过程之前,一定要明确变更的目标是什么(Potter and Sakry 2002)。 4.将改进活动视作小型项目将改进活动视作小型项目 项目的总体计划应该包括过程改进的资源和任务。与所有项目一样,改进项目项目的总体计划应该包括过程改进的资源和任务。与所有项目一样,改进项目也要执行计划、跟踪、测量和报告,只是规模相应地缩小了。也要执行计划、跟踪、测量和报告,只是规模相应地缩小了。 8.2.2 过程改进周期过程改进周期 右图是一个有效右图是一个有效

18、的过程改进周期。的过程改进周期。 这一方法反映了这一方法反映了您在执行下一个您在执行下一个任务之前先清楚任务之前先清楚自己所处位置的自己所处位置的重要性;反映了重要性;反映了绘制过程路线图绘制过程路线图的必要性,以及的必要性,以及以往的经验在持以往的经验在持续的过程改进中续的过程改进中的重要性。的重要性。 评估当前方法 发现和建议 新过程是否达 到了预期目标 规划改进活动 活动计划 建立,实验 并实现新过程 新过程;实验结果;初次结果 计划下一个 改进周期 活动规划过程 进行得如何? 这一过程 进行得如何? 评估结果 评估当前用的方法评估当前用的方法 所有改进活动的第所有改进活

19、动的第1步都是评估组织当前所使用步都是评估组织当前所使用的方法,找出这些方法的优点和缺陷。的方法,找出这些方法的优点和缺陷。 设计结构化问卷表是一种更系统的方法,它能够设计结构化问卷表是一种更系统的方法,它能够以较低的费用对当前过程进行评估。与团队成员以较低的费用对当前过程进行评估。与团队成员进行面谈和讨论,可以更准确更全面地了解当前进行面谈和讨论,可以更准确更全面地了解当前的过程。的过程。 规划改进活动规划改进活动 战略性计划描述了组织的总体软件过程改进,战战略性计划描述了组织的总体软件过程改进,战术性的活动计划则描述需要改进的专门领域。术性的活动计划则描述需要改进的专门领域

20、。 需求管理改进计划,它包括下面这些活动条目:需求管理改进计划,它包括下面这些活动条目: 1.起草一个需求变更控制过程草案。起草一个需求变更控制过程草案。 2.评审并修订变更控制过程。评审并修订变更控制过程。 3.在项目在项目A中试验变更控制过程。中试验变更控制过程。 4.根据试验的反馈信息,修订变更控制过程。根据试验的反馈信息,修订变更控制过程。 5.评估问题跟踪工具,并从中选择一种工具来支持变评估问题跟踪工具,并从中选择一种工具来支持变更控制过程。更控制过程。 6.购买并定制问题跟踪工具以支持变更控制过程。购买并定制问题跟踪工具以支持变更控制过程。 7.在组织中使用新的变更控制过程和工具。

21、在组织中使用新的变更控制过程和工具。 建立、实验并实现新过程建立、实验并实现新过程 实现活动计划意味着开发一些过程,并相信这些实现活动计划意味着开发一些过程,并相信这些过程比当前的工作方式会带来更好的结果,但不过程比当前的工作方式会带来更好的结果,但不要期望新的过程第要期望新的过程第1次试用就很完美。次试用就很完美。 请牢记下面这些关于指导过程实验的建议:请牢记下面这些关于指导过程实验的建议: 选择实验参与者,他们将尝试新方法并提供有用的选择实验参与者,他们将尝试新方法并提供有用的反馈信息。反馈信息。 使改进过程的结果容易解释。使改进过程的结果容易解释。 确定需要了解实验情况和实

22、验原因的有关涉众。确定需要了解实验情况和实验原因的有关涉众。 考虑在不同的项目中实验新过程的不同部分,这样考虑在不同的项目中实验新过程的不同部分,这样可以使更多的人尝试新方法,因此提高了了解程度,可以使更多的人尝试新方法,因此提高了了解程度,增加了反馈信息,更易于大家接受。增加了反馈信息,更易于大家接受。 询问实验参与者。询问实验参与者。 评估结果评估结果 过程改进周期的最后一步是评估完成的活动和取过程改进周期的最后一步是评估完成的活动和取得的成果,这种评估有助于团队在未来的改进活得的成果,这种评估有助于团队在未来的改进活动中做得更好。动中做得更好。 评估内容包括判断实验进行得

23、是否顺利,在解决评估内容包括判断实验进行得是否顺利,在解决新过程的不确定性方面是否有效,下一次指导过新过程的不确定性方面是否有效,下一次指导过程实验时是否需要做些变更。程实验时是否需要做些变更。 同时还要考虑新过程的总体执行情况是否顺利,同时还要考虑新过程的总体执行情况是否顺利,包括新过程或模板的可用性是否有效地传达给了包括新过程或模板的可用性是否有效地传达给了每一个人,参与者是否理解并成功地应用了新过每一个人,参与者是否理解并成功地应用了新过程,下次工作中是否需要有所变更等。程,下次工作中是否需要有所变更等。 其中关键的一步是,评估新实现的过程是否带来其中关键的一步是,评估新实现的过程是否带

24、来了期望的结果。了期望的结果。 8.3.1 软件风险管理基本原理软件风险管理基本原理 除了与项目范围和需求有关的风险外,项目还面临着除了与项目范围和需求有关的风险外,项目还面临着许多其他风险。许多其他风险。 对外部实体的依赖就是一种常见的风险来源。对外部实体的依赖就是一种常见的风险来源。 项目管理一直面临各种风险的挑战:评估不准确、管项目管理一直面临各种风险的挑战:评估不准确、管理人员拒绝开发人员的准确评估、对项目状态不了解理人员拒绝开发人员的准确评估、对项目状态不了解以及进行了人员调整等原因所引起的风险。以及进行了人员调整等原因所引起的风险。 技术风险威胁着高度复杂或很前沿的开发项目。技术风

25、险威胁着高度复杂或很前沿的开发项目。 知识的缺乏是风险的另一种来源,另外还有参与者对知识的缺乏是风险的另一种来源,另外还有参与者对所用的技术或项目应用领域经验不足。经常变更的或所用的技术或项目应用领域经验不足。经常变更的或强制执行的一些政府规定可能会使最好的项目规划彻强制执行的一些政府规定可能会使最好的项目规划彻底作废。底作废。 风险管理的要素风险管理的要素风险管理风险管理(risk management)就是使用某些工具和步骤把项目风险限就是使用某些工具和步骤把项目风险限制在一个可接受的范围内。制在一个可接受的范围内。风险管理提供了一种标准的方法,可以指出风险因素并将其编写成

26、文风险管理提供了一种标准的方法,可以指出风险因素并将其编写成文档,评估这些风险的潜在威胁,并提出减少这些风险因素的战略档,评估这些风险的潜在威胁,并提出减少这些风险因素的战略(Williams,Walker和和Dorofee 1997)。风险管理包括下图所示的这些活动。风险管理包括下图所示的这些活动。风险评估风险评估(risk assessment)是一个对项目进行检查以确定潜在风险领是一个对项目进行检查以确定潜在风险领域的过程。域的过程。风险避免风险避免(risk avoidance)是处理风险的一种方法,也就是尽量不要是处理风险的一种方法,也就是尽量不要做冒险的事做冒险的事。 风险管理 评

27、估 避免 控制 识别 分析 优先级 管理计划 解决方案 监控 编写项目风险文档编写项目风险文档 只是认识到项目所面只是认识到项目所面临的风险是远远不够临的风险是远远不够的,我们还必须以某的,我们还必须以某种方式对风险进行管种方式对风险进行管理,以便在整个项目理,以便在整个项目开发过程中可以将风开发过程中可以将风险问题和状态传达给险问题和状态传达给项目的涉众。项目的涉众。 右图展示了一个模板,右图展示了一个模板,用于对单个风险编写用于对单个风险编写文档。文档。 风 险 条 目 跟 踪 模 板 I D 号 : 确 定 日 期 : 撤 消 日 期 : 描 述 : 可 能 性 : 影

28、响 : 危 害 值 : 降 低 风 险 计 划 : 负 责 人 : 截 止 日 期 : 制定风险管理计划制定风险管理计划 对于小型项目,可以把控制风险的计对于小型项目,可以把控制风险的计划包括在软件项目管理计划内。划包括在软件项目管理计划内。 但对一个大型项目,则应该编写一个但对一个大型项目,则应该编写一个单独的风险管理计划,详细说明打算单独的风险管理计划,详细说明打算采用哪些方法来识别、评估、编档和采用哪些方法来识别、评估、编档和跟踪风险。这一计划还应该包括风险跟踪风险。这一计划还应该包括风险管理活动的角色和职责。管理活动的角色和职责。 风险管理计划模板可以从风险管理计划模板

29、可以从http:/ 要建立起周期性进行风险监控的措施。要建立起周期性进行风险监控的措施。 注意:不要想当然地以为,在识别出了风险并采取了降低风险的相应活动之后,风险就会处于您的控制之下。接下来还要实行风险管理活动。 8.3.2 与需求相关的风险与需求相关的风险 下面介绍的这些风险因素,是按照需求下面介绍的这些风险因素,是按照需求工程的分支过程组织的,即需求获取、工程的分支过程组织的,即需求获取、需求分析、编写需求规格说明、需求确需求分析、编写需求规格说明、需求确认和需求管理过程。认和需求管理过程。 推荐的方法可以减小风险发生的可能性推荐的方法可以减小风险发生的可能性或风险发生后给项目造成的影响

30、。或风险发生后给项目造成的影响。 需求获取需求获取 产品前景和项目范围产品前景和项目范围 应该在项目早期,编写一份包括业务需求在内的前景和范围文档,并将应该在项目早期,编写一份包括业务需求在内的前景和范围文档,并将它作为添加新需求和修改现有需求的指导。它作为添加新需求和修改现有需求的指导。 需求开发所需的时间需求开发所需的时间 将每个项目中需求开发所耗费的实际工作量记录下来,这样就可以判断将每个项目中需求开发所耗费的实际工作量记录下来,这样就可以判断出需求开发是否充分,并可以改进未来项目的工作计划。出需求开发是否充分,并可以改进未来项目的工作计划。 需求规格说明的完整性和正确性

31、需求规格说明的完整性和正确性 为了确保需求是客户真正需要的,应该以用户任务为中心,应用用例技为了确保需求是客户真正需要的,应该以用户任务为中心,应用用例技术来获取需求。术来获取需求。 创新产品的需求创新产品的需求 对某类产品中的第对某类产品中的第1个产品,不太容易把握市场对产品的反映。个产品,不太容易把握市场对产品的反映。 定义非功能需求定义非功能需求 由于我们一般都会强调产品的功能,所以很容易忽略产品的非由于我们一般都会强调产品的功能,所以很容易忽略产品的非功能性需求。功能性需求。 需求获取 客户对产品需求意见一致客户对产品需求意见一致 确定那些主要的客户,并采用产品代言人的

32、方法,确定那些主要的客户,并采用产品代言人的方法,保证有足够的客户代表的积极参与。保证有足够的客户代表的积极参与。 未加说明的需求未加说明的需求 客户经常会有一些隐含的期望要求,但并未以文档客户经常会有一些隐含的期望要求,但并未以文档的方式说明出来。尽量识别客户可能做出的任何假的方式说明出来。尽量识别客户可能做出的任何假设。设。 把已有的产品作为需求基线来源把已有的产品作为需求基线来源 将通过逆向工程发现的需求编写成文档,让客户评将通过逆向工程发现的需求编写成文档,让客户评审这些需求,以确保其正确性和相关性。审这些需求,以确保其正确性和相关性。 根据需要提出解决方案根据需要提出解决方案 分析人

33、员必须提炼出隐藏在客户提出的解决方案背分析人员必须提炼出隐藏在客户提出的解决方案背后的真正意图。后的真正意图。 需求分析需求分析 设定需求优先级设定需求优先级 要确保对每一个功能需求、特性或用例都设定要确保对每一个功能需求、特性或用例都设定了优先级,并安排在一个特定的系统版本或迭了优先级,并安排在一个特定的系统版本或迭代中实现它们。代中实现它们。 技术上难以实现的特性技术上难以实现的特性 采用项目状态跟踪来监控落后于实现计划的需采用项目状态跟踪来监控落后于实现计划的需求,并尽早采取纠正措施。求,并尽早采取纠正措施。 不熟悉的技术、方法、语言、工具或硬件不熟悉的技术、方法、语言、

34、工具或硬件 留出足够的时间用于从错误中学习经验、实验留出足够的时间用于从错误中学习经验、实验及制作原型。及制作原型。 编写需求规格说明编写需求规格说明 需求理解需求理解 开发人员和客户对需求的不同理解会导致彼此间的开发人员和客户对需求的不同理解会导致彼此间的期望差距,并最终导致交付的产品无法满足客户的期望差距,并最终导致交付的产品无法满足客户的需要。需要。 尽管问题待确定但迫于时间压力而继续向前尽管问题待确定但迫于时间压力而继续向前 在软件需求规格说明中,将需要进一步研究的地方在软件需求规格说明中,将需要进一步研究的地方标上标上TBD(to be determined,待确定,

35、待确定),不失为一个,不失为一个好主意。好主意。 具有二义性的术语具有二义性的术语 对于不同的读者可能会有不同解释的业务术语或技对于不同的读者可能会有不同解释的业务术语或技术术语,应该创建一个术语表对这些术语进行定义。术术语,应该创建一个术语表对这些术语进行定义。 需求中包括了设计需求中包括了设计 软件需求规格说明中所包含的设计对开发人员做出软件需求规格说明中所包含的设计对开发人员做出有效选择造成了不必要的限制,会妨碍他们发挥创有效选择造成了不必要的限制,会妨碍他们发挥创造性设计出最佳方案。造性设计出最佳方案。 需求确认需求确认 未经确认的需求未经确认的需求 软件需求规格说明会

36、令人望而生畏,软件需求规格说明会令人望而生畏,在开发过程早期编写测试用例的想法在开发过程早期编写测试用例的想法就是基于这一点。就是基于这一点。 审查熟练程度审查熟练程度 要对参与需求文档审查的所有团队成要对参与需求文档审查的所有团队成员进行培训,请组织内部有经验的审员进行培训,请组织内部有经验的审查人员或外界的咨询顾问来评述早先查人员或外界的咨询顾问来评述早先的审查。的审查。 需求管理需求管理 变更需求变更需求 将前景和范围文档作为批准需求变更的参照,可以将前景和范围文档作为批准需求变更的参照,可以减少范围蔓延。减少范围蔓延。 需求变更过程需求变更过程 与需求变更的处理方式相关

37、的风险包括,缺少已定与需求变更的处理方式相关的风险包括,缺少已定义的变更过程,采用无效的变更机制,以及不遵循义的变更过程,采用无效的变更机制,以及不遵循制定的过程来做出变更。制定的过程来做出变更。 未实现的需求未实现的需求 需求跟踪矩阵有助于在设计、构造或测试期间避免需求跟踪矩阵有助于在设计、构造或测试期间避免遗漏任何需求。遗漏任何需求。 扩大项目范围扩大项目范围 如果最初的需求定义不够好,那么进一步定义需求如果最初的需求定义不够好,那么进一步定义需求就会扩大项目的范围。就会扩大项目的范围。 8.3.3 风险管理是我们的好帮手风险管理是我们的好帮手 周期性地进行风险跟踪可以使项目经理周期性地进

38、行风险跟踪可以使项目经理了解风险对项目的威胁,没有得到有效了解风险对项目的威胁,没有得到有效控制的风险应该上报高层管理人员,他控制的风险应该上报高层管理人员,他们可能开始采取一些纠正措施,也可能们可能开始采取一些纠正措施,也可能不管风险,依旧按照原来的业务决策思不管风险,依旧按照原来的业务决策思路进行。路进行。 即使不能控制项目可能遇到的所有风险,即使不能控制项目可能遇到的所有风险,风险管理也能帮助我们看清形势,做出风险管理也能帮助我们看清形势,做出合理的决策。合理的决策。318.4 特殊软件项目的需求实践特殊软件项目的需求实践 一般所讲述的需求开发,是针对一个新软件一般所讲述的需求开发,是针

39、对一个新软件或系统开发项目的情况,这种项目有时也称或系统开发项目的情况,这种项目有时也称为零起点项目为零起点项目(green-field project)。 大多数组织的主要精力集中于维护现存的遗大多数组织的主要精力集中于维护现存的遗留系统,或者为已有的商业产品构建新的版留系统,或者为已有的商业产品构建新的版本;其他组织也很少是从零开始构建一个新本;其他组织也很少是从零开始构建一个新系统,而是对商用现货系统,而是对商用现货(off-the-shelf,COTS)产品进行集成、定制和扩充,以满足产品进行集成、定制和扩充,以满足自己的需要。自己的需要。 8.4.1 维护项目的需求维护项目的需求 维

40、护是指对当前运行的项目进行修改,维护是指对当前运行的项目进行修改,有时也称为继续工程有时也称为继续工程(continuing engineering)或后续开发或后续开发(ongoing development)。 程序维护的任务主要是纠正缺陷、为程序维护的任务主要是纠正缺陷、为现有系统添加新功能或新报表,以及现有系统添加新功能或新报表,以及对功能进行修改以便遵循修订后的业对功能进行修改以便遵循修订后的业务规则。务规则。 开始捕获信息开始捕获信息缺少精确的需求文档,那么维护人员就必须进行逆向工缺少精确的需求文档,那么维护人员就必须进行逆向工程,通过代码来理解系统,我将此看作是软

41、件考古学程,通过代码来理解系统,我将此看作是软件考古学(software archaeology)。为了能够从逆向工程中获得最大的收益,考古探险队应为了能够从逆向工程中获得最大的收益,考古探险队应该将通过需求和设计描述表中所了解到的信息记录下来,该将通过需求和设计描述表中所了解到的信息记录下来,然后将有关当前系统某些部分的精确信息积累起来。然后将有关当前系统某些部分的精确信息积累起来。 构建一个包含当前系统部分的需求表示可达到以下构建一个包含当前系统部分的需求表示可达到以下3个个有用的目标:有用的目标: 消除知识鸿沟,使将来的维护人员能更好地理解所做的变更。消除知识鸿沟,使将来的维护人员能更好

42、地理解所做的变更。 收集当前系统的一些信息收集当前系统的一些信息当前系统在以前缺乏良好的书面当前系统在以前缺乏良好的书面文档。当项目团队日后再完成其他的维护任务时,可以对这些文档。当项目团队日后再完成其他的维护任务时,可以对这些零星分散的知识表示加以扩充,进而逐步完善系统文档。记录零星分散的知识表示加以扩充,进而逐步完善系统文档。记录这些新发现的知识所需要增加的费用,比起以后必须重新发现这些新发现的知识所需要增加的费用,比起以后必须重新发现这些知识所需要的费用更少。这些知识所需要的费用更少。 提供一个指标,表明当前的系统测试集对系统功能的覆盖率。提供一个指标,表明当前的系统测试集对系统功能的覆盖率。 亲身实践一下新的需求技术亲身实践一下新的需求技术 技能水平对项目的成功或失败有着至关重要的影响,技能水平对项目的成功或失败有着至关重要的影响,那么实践经验就可以减少在一个零起点项目中第一那么实践经验就可以减少在一个零起点项目中第一次应用

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论