软件开发基本原则.doc

《软件开发基本原则.doc》由会员分享，可在线阅读，更多相关《软件开发基本原则.doc（51页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、软件开发根本原那么一 策略与因素1 概 述时间 - 本钱 - 质量或特性是评价软件工程成败的三个关键指标，这三个指标之间相互影响与制约，形成了所谓的“工程管理三角形。要提高质量或增加特性意味着本钱与时间的增加，或两者都增加；要在时间不变的前提下缩减开发本钱或本钱不变的前提下缩减时间那么意味着质量的下降或特性的削减。图 1-1 工程管理三角形上述分析其实只是理论上的“理想平衡状态。现实工作中往往出现的情形是：要么时间超过方案，要么本钱超过预算，要么质量达不到要求，要么三个指标都达不到预期。典型例子：由于客户的压力需要尽量缩减开发时间，由于企业间的竞争与盈利压力需要尽量节约本钱，因此需要一个人做两

2、个人的工作，一个月做两个月的工作，同时压缩需求分析、设计、测试、评审与工程会议等活动。可想而知，即使软件的构建阶段能够按时完成，但做出的软件质量是难以保证的。更糟糕的还在后面：由于质量的低劣，构建阶段完毕后对系统进展集成测试时，很多问题就会暴露出来：对某些需求的理解有误差，导致这局部功能要重新分析、设计、编码与测试；架构设计缺乏整体思维导致系统不同模块各自为政，产生大量重复的难以维护的代码；编码太仓促导致一大堆的Bug；沟通不畅顺导致模块接口不兼容从而工程被带入了修改无限循环地带，即使勉强上线发布，修改还是一直持续，直至最后，没有人再敢接近这套代码，对这个工程谈虎色变。软件开发工程有其自身规律

3、与原那么，只有遵守其原那么并付诸相应的实践才可能使工程安康稳定地前进。本文讲述的是软件开发的根本原那么，它是通用的，几乎适用于所有的软件开发工程。不同工程可以根据自身特点在原那么的指导下定义相应的工程开发实践。2 策略与因素2.1 总体策略要防止混乱低效的开发，就要求每个人能够放弃他们自己的一些坏习惯，通过采取以下四种策略实现快速开发：1、 防止典型错误2、 打好开发根底3、 管理风险，防止灾难发生4、 采用面向进度的实践图 2.1-1 快速开发的四跟支柱典型错误：是指一些经常被许多人使用的无效的开发实践，如：不现实的预期，缺乏方案，功能蔓延与银弹综合症等。将在第3章详细讲解。开发根底：是指工

4、程开发过程中管理、技术、质量保证等方面行为与活动，如：方案编制，需求管理与技术回忆等。将在第4章详细讲解风险管理：是指对有可能影响工程的风险进展评估与控制。将在第5章讨论进度方案相关的风险。面向进度的实践有以下三类 面向速度的实践：可以提升开发速度，帮助你更快的交付软件 面向进度风险的实践：可以降低方案风险，帮助你的工程平稳推进 面向可视化的实践：可以提高进程的可视化程度，帮助你掌握工程动态图 2.1-2 面向进度的实践图2.1-1所示的前三根柱子为可能的最正确进度提供了最重要的支撑，虽然可能不是最理想的，但却是最需要的。也就是说，即使不借助于面向进度的实践方法，也可能实现较优化的工程进度；但

5、是，如果仅仅依赖面向进度的实践却不可以支撑可能的最正确进度方案。图 2.1-3 仅仅依赖面向进度的实践缺乏以支撑最正确进度方案2.2 软件开发的四维每个软件工程都有四个重要的维： 人员：完成任务要么快，要么慢 过程：优化人员的工作效率，或者浪费人员的时间 产品：以自我完善的形式定义，或者阻碍人员到达最好效果的形式定义 技术：促进或者阻碍开发的实现图 2.2-1 开发速度的四维2.2.1 人员研究数据：人件极大地影响着生产效率，任何关注提高生产效率的组织首先必须有一套良好的人员鼓励、团队合作、员工选择及培训机制发挥人员最大潜能，缩短工程周期的方法：1、 工程成员的选择五个原那么： 用更少更好的人

6、 使任务及人员的技能与动机相匹配 帮助人员自我实现，而不是强制地把他推到他最有经历或最需要他的岗位上 人员选择应强调人员之间的互补及协调性 尽快排除或替换不称职的人员2、 团队组织构造人员的组织方式对人员的工作效率有很大影响，调整工程团队以使之及工程规模、产品特点以及进度目标相匹配。特定的软件工程也可以从适宜的专门组织中受益。3、 人员鼓励人员鼓励能激发人的动力，从而付出额外的努力工作；它适用于不同组织、不同工程与不同人员。人员鼓励是达成快速开发的最具潜力方法2.2.2 过程研究数据：Hughes Aircraft、Lockheed、Motorola、NASA、Raytheon与Xerox等组

7、织通过对开发过程的改良将产品上市时间缩短了一半，降低本钱、减少错误为原来的1/31/10。过程是指软件开发生命周期中定义的一系列工作流程与活动的集合。可以概括为以下三类： 根本过程：包括获取过程、供给过程、开发过程、运作过程、维护过程与管理过程 支持过程：包括文档过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审过程、审计过程以及问题解决过程 组织过程：包括根底设施过程、改良过程以及培训过程忽略过程容易造成工作效率低下，工作目的穿插重复，产品质量难以保证等问题；另一方面，如果过程过于严格、过于官僚同样会挫伤人员的积极性，或者由于执行过程的本钱过高而影响实际的工作效率。组织可以对现有

8、的过程进展裁剪与调整，制定出适合特定工程的过程；或者可以为工程从头开场定义过程。无论是裁剪过程或是定义过程，应该把关注点放在以下几个方面：1、 防止返工软件工程节省时间一个最直接的方式就是确定过程，防止重复工作。如果在工程最后阶段改变需求，就可能不得不重新设计、编码与测试；如果直到系统测试阶段才发现设计有问题，就可能不得不扔掉已经细化的设计与编码。2、 质量保证质量保证有两个目的 确保交付的产品能够到达可承受的质量水平 在各阶段以最少的时间与本钱代价查出错误应尽早在错误发生的时候就查出来，错误在产品中停留的时间越长，清楚错误所花费的时间与本钱就越多。质量保证是任何开发过程中必不可少的局部。3、

9、 开发根底一系列的软件工程实践活动形成了开发根底，如：分析、设计、构建、集成与测试等。在过程中对开发根底加以关注，并定义良好的工作标准与任务集合能防止工程失控。4、 风险管理及进度相关的风险管理是开发过程必要的组成局部。风险管理虽然不能直接提高开发速度，但它是防止工程灾难的有效实践。5、 资源目标资源包括人力资源、环境资源与软硬件资源等。优化资源的调配有助于提高生产率。6、 生命周期方案生命周期方案是根本的管理方案，有助于确定软件工程要进展的活动集合与资源分配。每种周期模型都有其适用范围与缺点，为工程选择适当的生命周期模型能有效提高工作效率或降低工程风险。图 2.2.2-1 纯瀑布模型图 2.

10、2.2-2 瀑布模型的另一种形式鲑鱼生命期模型图 2.2.2-3 编码修正模型一种不标准的模型图 2.2.2-4 螺旋模型图 2.2.2-5 生鱼片模型图 2.2.2-6 包含子工程的瀑布模型图 2.2.2-7 能够降低风险的瀑布模型对需求分析与架构设计阶段采用螺旋模型图 2.2.2-8 渐进原型模型图 2.2.2-9 阶段交付模型图 2.2.2-10 面向进度模型图 2.2.2-11 渐进交付模型图 2.2.2-12 面向开发工具的设计模型7、 面向客户开发谁是客户？对客户的理解取决于场合，可能是工程委托人，最终用户，市场人员或者老板。现代软件开发非常关注客户的需求及期望，开发出合符产品规格

11、的软件只是完成了一半工作，另一半是帮助客户配置出产品能够实现的功能，而实现这些功能所花费的时间通常远远多于确定纸面上的产品规格所需要的时间。将自己站在客户的角度考虑问题是防止大量返工的最好方法。同时应该建立有效的客户沟通渠道，合理控制客户的期望值。2.2.3 产品在软件开发的四维中，最切实的维是产品维。对产品规模与产品特性的关注，意味着巨大的缩短方案进度的时机。削减了产品功能通常就可以缩短产品开发周期1、 产品规模产品规模是对开发进度影响最大的一个因素。构建软件所需的工作量的增长比产品规模的增长要快得多，并且增长是不成比例的，所以产品规模的缩小将大大提高开发速度。将中等规模的软件削减一半通常可

12、以使工作负荷削减2/3。2、 产品特性产品的一些非功能性需求或额外关注点会影响设计的复杂度与构建的工作量，如对性能、稳定性、可维护性与可扩展性等要求很高的产品比没有这些特性要求的产品需要更长的开发周期。2.2.4 技术从使用低效的工具转为使用高效的工具是提高开发速度的快捷方法。选择有效的工具并管理好由此带来的风险也是提高开发速度的方法。软件开发根本原那么二 典型错误大多数典型错误其外表都具有诱惑性，给人们一种诱人的前景，但通常却不能产生期望的结果。“想挽救进度已经落后的工程吗？- 给工程补充更多人员！下面分别按照人员、过程、产品与技术四个维度列出36个典型错误。人 员典型错误1：挫伤积极性对人

13、员不够关心与重视；过度的进度压力；缺乏鼓励；过分夸大的鼓励等。典型错误2：人员素质低人员能力欠佳，工作效率低，甚至做多错多。典型错误3：对有问题的员工失控不对有问题的人员采取措施是工程组成员对领导最常见的抱怨。典型错误4：英雄主义强调个人英雄主义会导致发生额外的风险，也会削弱在软件开发过程中多个角色的合作。典型错误5：工程后期参加人员盲目地在工程后期参加人手等于火上浇油。典型错误6：办公室环境拥挤嘈杂拥有安静、隐蔽办公环境的人员比工作在嘈杂、拥挤环境中的人员往往会有更好的工作业绩表现。典型错误7：开发人员及客户之间发生摩擦主要原因是缺乏沟通。这种摩擦消耗时间，它会转移客户与开发人员双方对工程工

14、作的注意力。典型错误8：不现实的预期过高的期望值与主观的不切实际的设想。是导致开发人员与客户或工程经理之间的摩擦常见原因之一。典型错误9：缺乏有效的工程支持软件开发工程的许都方面都需要高层的支持，包括实际的方案、变更控制以及新型开发方法的采用等。缺乏有效的高层支持事实上注定了工程的失败。典型错误10：缺乏各种角色的齐心协力软件开发中所有主要人员必须齐心协力专注于工程，包括高层支持者、工程领导、工程成员、市场人员、最终用户、客户与任何工程介入者。典型错误11：缺乏用户介入没有用户早期介入的工程充满需求误解的风险，易受工程后期功能蔓延的威胁。典型错误12：政治高于物质“政治家型工程强调“管理至上，

15、主要精力集中在他们及经理的关系上。将政治凌驾于结果之上对软件工程会造成极大伤害。典型错误13：充满想象闭上眼睛毫无理由地希望某事将像想象那样运作。很多软件开发问题都是由于充满想象造成的。想象例如：工程组不知道他们能不能按时完成工程，但他们认为如果每个人能更努力工作，并且不出现问题，他们应该能完成工程。我们无需向客户演示最新的修改，我们确信这个效果是客户想要的。工程组错过了一个里程碑好几天了，他们说会更努力工作赶上下一个里程碑，我想他们能够及时赶上的。过 程典型错误14：过于乐观的方案定制过于乐观的工程方案相当于自己为工程失败画出了底线，导致缩短分析、设计等关键性前期开发活动；同时也向开发人员施

16、加了额外压力，会长期对开发人员的自信心与生产率造成巨大伤害。典型错误15：缺乏足够的风险管理如果你不主动管理风险，风险随时会来找你，打乱你的开发方案。典型错误16：承包人导致的失败如果不对承包商加以认真管理，交付可能延期，并且质量难以保证。典型错误17：缺乏方案没有方案的工程就像飘荡在海洋中的小船，没人知道会飘到哪里。典型错误18：在压力下放弃方案很多工程组定制了方案，但遇到了麻烦时就放弃方案。工程失败的原因不是在于放弃方案本身，而是不能及时修订方案制定替代方案，并一头栽进编码与问题处理中。典型错误19：在模糊的工程前期浪费时间由于花在审批、预算等前期工作的时间过长，或需求无限循环等原因，导致

17、压缩开发方案。工程前期节省几周或几个月时间比将开发方案压缩同样时间来得更容易、更廉价，风险也更少。典型错误20：前期活动不符合要求研究数据：前期被跳过的活动或工作通常在后期会以10倍到100倍的代价来完成。如果一项工作在工程初期需要5小时完成，那么在工程后期你至少需要50小时才能完成它。Fagan 1976，Boehm and Papaccio 1988典型错误21：设计低劣前期活动不符合要求的一个特殊情况就是设计低劣。高压环境导致设计缺乏周密思考往往导致设计低劣。典型错误22：缺少质量保证措施研究数据：工程前期砍掉1天的质量保证活动，到工程后期就需要3到10天的处理代价。Jones 1994

18、典型错误23：缺少管理控制缺少管理控制点就难以对工程的阶段与状态进展跟踪，因此不能知道工程是否按正常轨道前进。典型错误24：太早或过于频繁的集成在构建未完全锁定时，进展过早的集成或额外的集成不利于产品，它仅仅是在浪费时间，延长进度。典型错误25：工程估算时遗漏必要的任务训、公司与部门会议，技术评审会议等活动在工程估算时通常被遗漏。典型错误26：追赶方案当进度落后时不重新检查任务与调整方案，而是简单地决定把进度赶上来。另一种情况是，当产品出现变更却没有做相应的方案调整典型错误27：鲁莽编码没有足够的需求根底与清晰的架构设计而进展“边编码边修改造成太多重复工作与返工，这样的做法使工程大多以失败告终

19、产 品典型错误28：需求的镀金工程的产品要求要求比实际需求多得多的产品特性或复杂功能，却又不给进度方案分配足够的时间。典型错误29：功能蔓延在整个开发过程中，工程平均会有25%的需求变更，对软件方案至少有25%的影响。如果任由客户不断提出新需求，工程就会一直都做不完典型错误30：开发人员的镀金开发人员着迷于新技术，有时渴望在自己的产品中使用这些技术，而不管那些技术是否适合或是否会对系统整体造成破坏。典型错误31：又推又拉的交易管理者批准进度落后的工程顺延，但同时又给这个工程参加新任务。典型错误32：研究导向的开发软件开发进度是完全有理由可以预测的，而软件研究进度甚至理论上都是不可预知的，不能采

20、用像软件研究一样的工作方式引导工程开发。技 术典型错误33：银弹综合症过于相信某些技术宣传某种开发过程、某种程序设计方法、某种开发语言，缺少在特定环境下使用这些工具的必要信息。当团队寄望利用他们来解决进度问题时，不可防止会失败的。典型错误34：过高估计了新技术或方法带来的节省量无论采用多少新工具或方法，以及这些工具或方法有多好，他们很少能够大幅度提高生产率。软件开发由多个任务组成，特定的工具或方法只会可能提高特定任务的生产效率。同时，它们所带来的效率常常被学习它们所花费的时间抵消了。典型错误35：工程中间切换工具在工程中间更换工具时，伴随使用新工具而带来的人员学习与掌握的过程、重复的工作、不可

21、防止的错误等会彻底抵消它所带来的益处。典型错误36：缺乏自动的源代码控制手段缺乏自动的源代码控制容易造成版本冲突、历时版本丧失、更新丧失等一系列问题，并浪费大量的时间处理这些问题。软件开发根本原那么三 根本原那么“回忆一下被选为最正确工程的十个软件工程，如果说有所发现的话，那就是最正确的工程一定是建立在最正确的软件开发根底之上的。我们都知道软件开发根底对于优秀软件的作用，但差异在于大多数软件的根底薄弱，这样不可防止地使自己陷入麻烦之中Bill Hetzel 1993本章的范畴只限定在确定软件开发的根本原那么，解析他们是如何影响开发方案的，同时提供参考信息。本章书把软件开发根本原那么实践分为三类

22、：管理实践，技术实践与质量保证实践。管理的根本原那么管理原那么由以下几局部组成：判定产品规模包括功能、复杂度与其它产品特性根据产品规模分配资源制定资源方案监控、引导资源以保持工程方向不会偏离1. 工程估算与进度安排一个运行良好的工程一般通过三个根本步骤来定制软件开发进度表。首先估算工程规模大小然后估算完成这样规模的工程需要付出的代价最后基于这种估算定制工程进度方案如果估算不准确就会降低开发效率，所以说估算与工程进度方案是软件开发的根底。准确的估算时进展有效规划的必要前提，而有效的规划又是有效开发的必要条件。2. 方案编制方案一个软件工程应该包括以下活动： 工程估算与时间进度 确定工程需要多少人

23、参及、需要什么样的技能、适宜参加以及具体人选 确定工程组的运作方式 确定工程采用的生命周期模型 管理风险 确定工程策略例如：如何控制产品的特色，是否需要购置局部产品组建3. 跟踪跟踪是一个根本的软件管理行为。如果不跟踪一个工程就不能管理它，就不会知道方案是否被贯彻执行了，也不会知道下一步该做什么，同时也无法监控工程风险。有效的跟踪能使工程组在还有时间做点什么来改正错误的时候，尽早发现进度表上的问题。制定了一个工程方案就要跟踪检查它是否在按方案进展，包括对它的进度、费用与质量等目标的检查。典型的管理级跟踪控制包括：任务列表、进展状况会议、进展报告、里程碑审查、预算报告以及走查管理等。典型的技术级

24、跟踪包括：技术审查、技术审计与标志着里程碑是否完结的质量关口等。图 4.1.3-1 不同类型工程的可视度4. 量度老板问你：“我们能够在9各月内开发出这个产品吗？你怎么答复？！为了使开发更有效，你需要具备软件量度方面的根本知识。你需要了解收集数据的尺度基准，包括应该要收集什么数据，如何获得这些数据。你还需要具备用来分析状态，质量与生产率的详细基准方面的知识。任何公司想要进展快速的开发就要收集这些根本的尺度，这样才可以知道他们的开发速度是否正在改善或后退。技术根本原那么1984年有关“现代程序设计实践方法技术的根本原那么的一份研究，详细论述了不使用这些根本原那么就不可能具有高的生产率的内容。图4

25、.2-1展示了研究的结果。图 4.2-1 生产率及“现代程序设计实践方法的关系不广泛地使用“现代程序设计实践方法就无法具有高的生产率很显然，不采用现代程序设计实践方法的工程不可能具有高的生产率。但技术根本原那么的应用，就其本身而言，缺乏以创造高的生产率。一些工程使用了大量现代程序设计实践方法，但是仍旧与那些完全没有使用该方法的工程具有一样的生产率。因此，注意技术的根本原那么是很必要的，但却缺乏以到达快速开发的目的例如犯了某些典型错误。1. 需求管理研究数据：典型工程平均会经历25%的需求变化，从而至少产生25%的额外费用与时间。一项针对8000多个工程的调查显示，导致工程推迟发布、超出预算、功

26、能比预期减少的最重要的三个原因缺乏用户的介入、不完善的需求分析与用户不断改变需求，都与需求管理有关。Standish Group1994一项软件工程研究所的调查也有一样的结论：超过半数的工程都遭遇过不充分的需求管理的麻烦。Kitson and Masters 1993需求管理就是收集需求，把需求记录成文档、电子邮件、用户界面串连脚本、可实现的原型等形式，然后依此来跟踪设计与编码，并随时管理、修改需求，以适应工程后续的过程。成功的需求管理取决于了解足够的不同的实践经历，以便能够为特定工程选择可借鉴的一种。需求管理的根底：需求分析方法：包括构造分析、数据构造分析与面向对象分析系统建模实践：如类图表

27、、数据流图表、实体关系图表、数据字典符号与状态跃变图表沟通实践：如联合应用开发、用户界面原型与常规会谈实践等需求管理与其它生命周期类型的关系：如渐进原型、阶段交付、螺旋模型、瀑布模型与编码修正需求管理在两个方面对开发速度发挥着巨大的调节作用：首先，正规的需求管理中，需求收集往往比其他软件开发活动完成得要沉着些。如果能加快需求步伐而不伤害质量，就可以缩短总的开发时间。第二，正确地把需求摆在首位，往往要比被动地这样做所花的时间少得多。一些需求管理实践根本原那么能够减少需求变化的数量，其他开发实践的根本原那么能够减少因需求改变而产生的费用。想象一下，如果把需求变化从25%减少到10%，同时把每个需求

28、变化导致的费用减少5%-10%，那么综合的效果会怎样呢？2. 设计研究数据：一个设计上的错误如果到系统测试时才被发现，那么花费的修补时间要比它在设计阶段时被发现所花费的时间多10倍。Dunn 1984设计是系统构建、工程进度方案、工程跟踪与工程控制的根底。体系构造与设计的根本原那么：主要设计风格：如面向对象设计、构造化设计与数据构造设计根底设计概念：如信息隐藏、模块化、抽象、封装、聚合、耦合、层次、继承、多态、根本算法与根本数据构造对典型挑战性事件的标准设计：包括异常处理、国际化、本地化、便携性、字串存储、输入输出、内存管理、数据存储、浮点算法、数据库设计、性能与复用对特殊领域应用程序设计的独

29、有思考：例如财务应用、科学应用、嵌入式系统、实时系统、平安性要求高的软件等架构安排：如子系统组织、分层构造、子系统通信方式与典型的系统架构设计工具的使用3. 构建当构建开场时，工程成功及否大多就已经注定了。需求管理与设计对开发进度方案的调节作用比构建的调节作用大得多，这意味着小的波动可以导致进度的重大变化。尽管构建是一个低层次的活动，但是它确实可以提供许多时机进一步改良时间效率低的任务或优化一些任务。例如，花时间对那些无需镀金的功能进展镀金；调试那些无用的多余代码，或者对那些并不知道是否需要优化的片段尽心优化。构建的根本原那么： 编码实践：如变量与函数命名、版面布局与文档 数据相关概念：如作用

30、范围、持续与捆绑时间 特定数据类型的使用方针：如通用根底数据类型、枚举、常量、数组与指针 控制相关的概念：如组织整齐的代码、条件的使用、循环的控制、复杂度的控制、特殊控制构造的使用goto、return、递归 断言与其它以代码为核心的错误检测方法 对例程、模块、类与文件代码打包的规那么 单元测试与调试实践 集成策略：如增量式集成、大爆炸式集成与渐进开发 代码优化策略与实践 及所使用的特定编程语言相关的其他事情 使用构建工具：如编译环境、群组工作支持、源代码控制、代码库与代码生成器软件配置管理(SCM)是管理工程成果的一种实践方法，能使工程在全程中保持一致的状态。SCM包括评估变更、跟踪变更、处

31、理多版本，以及在不同时间保存工程成果的备份等实践。质量保证根本原那么很多公司现阶段开发软件都有一定的不当之处，使得他们的开发时间比需要的长。在调查了4000个软件工程后，Capers Jones递交报告说，糟糕的质量是进度被拖延的最普遍的原因之一。他还说，中途被取消的工程中，大约有一半是由于其糟糕的质量。Jones 1994一项软件工程研究所的调查显示，大约有60%的公司遭受着不适当的质量保证体系的困扰。Kitson and Masters 1993。在过大的时间压力下发布的产品，其错误率是正常情况下的4倍。有进度问题的工程经常是在进展艰辛的工作而不是轻松活泼的工作，关注质量被认为是有些奢侈。

32、但其结果却是工程进展缓慢，并陷入更深的进度问题中。Jones 1994重做有缺陷的需求、设计与编码通常花费整个软件开发本钱的40%50%。Jones 1968b，Boehm 1987a最糟糕的情况下，在运行中的软件工程只修改一次软件需求问题的花费通常是在需求分析阶段所花时间的50到200倍。Boehm and Papacio 1988大约60%的错误通常在设计阶段就存在了。Gilb 1988如果可以尽早地预防并修正漏洞，可以节省大量时间，在进度的安排上占了先机。图 4.3-1 错误率与开发时间的关系大多数情况下，具有低错误率的工程同时实现了最短日程的目标1. 易错模块易错模块是那些容易存在或多

33、或少漏洞的模块。研究数据：IBM的IMS工程中，57%的漏洞存在于7%的模块中。Jones 1991程序中20%的模块包含了80%的错误。Boehm 1987b高错误率的模块开发起来要比其它模块更加昂贵与耗时，如果普通模块开发每个功能点要花费$500$1000，那么易错模块每个功能点就要花费$2000$4000。Jones 1994易错模块往往比系统中的其它模块更复杂，缺乏构造化，或者不同寻常的庞大，并且往往在背负压力下开发，往往没有被完全测试过。对软件开发特别重要的一个方面就是对易错模块的质量保证。2. 测试最寻常的质量保证实践就是毋庸置疑地进展测试，两种根本的测试方法 单元测试：程序员检查

34、他自己的代码是否工作正常 系统测试：独立测试员检查整个系统是否如期望的那样正常运行研究数据：测试的有效性差异是巨大的。单元测试可以找到程序中10%50%的漏洞；系统测试可以发现20%60%的程序漏洞。加在一起，累积的漏洞检测率经常少于60%。Jones 1986a剩下的错误要么通过其它的查错技巧如技术回忆发现，要么就是在产品发布后被最终用户发现。平衡测试与快速开发的最正确方法是在坏消息出现之前做好方案设置对坏消息的测试，尽早地发现问题。3. 技术回忆技术回忆包括在需求、设计、编码与测试等事件中用于查错的所有类型的回忆。回忆在形式上与效果上是多样的，它在开发速度上比在测试上扮演更重要的角色。下面

35、讲述最常见的几种回忆。1) 走查走查是指任何两个以上的开发人员以增进软件质量为目的所召开的回忆技术工作会议。走查可能是最平常的非正式回忆，走查可以在写设计说明书时，设计与编码完成之前就发现漏洞。研究数据：走查可以发现30%70%的程序漏洞。Myers 1979，Boehm 1987b，Yourdon 1989b2) 代码阅读代码阅读时比走查更正式些的回忆方式，但仅适用于代码。代码阅读时，写这段代码的程序员把代码清单交给两个或更多的审阅者审阅，审阅者阅读代码，并把发现的错误报告给编写者。研究数据：NASA的软件工程实验室的一项研究发现：代码阅读能发现的漏洞是测试时能发现的漏洞的两倍。Card 1

36、9873) 检查检查是一种正式的技术回忆，它被认为是在整个工程中最具效率的查错方式。使用检查的方法，开发人员需要承受检查的特殊训练，并且在检查中扮演重要的角色。在检查会议之前“仲裁人发布产品要被检验评估的消息与检查列表，“审阅人在会议前检查程序，在检查会议上“作者通常要解释要检验的东西，“审阅人鉴别错误，“书记员记录错误。在会后“仲裁人写一份报告说明每个漏洞与处理方法。在工程中可以使用检查对需求分析、用户界面原型、设计、编码及其他认为的过程查错。研究数据：检查可以查出程序中60%90%的漏洞，这点比走查或测试要好。因为可以在开发的早期应用，因此，检查方法被证明可以节约10%30%的开发时间。G

37、ilb and Graham 1993一项对大型程序的调查结果显示，在检查上每花1小时，就可以防止在维护上33个小时的花费。检查比测试有效20倍以上。Russel 1991软件开发根本原那么四 风险管理1988年，Peat Marwick针对600家成功公司的调查结果显示，35%的公司有过软件工程失控的经历。Rothfeder 19881982年，Allstate公司宣布其公司运营全部要实行自动化。他们启动了一个将耗时5年投资800万美元的大型工程，而在花费了6年与1500万美元后，Allstate公司重新调整了目标与最终期限，重新调整后的预算大约1亿美元。1988年，Westpac Bank

38、ing公司决定重新设计他们的信息系统。他们做了5年、8500万美元的方案。3年后，在花费了1.5亿美元却依然收效甚微时，Westpac Banking公司为了减少损失，取消了这个工程，并为此裁员500人。Glass 1992从工程管理的角度来看，有五大硬性知识领域：范围管理、进度管理、本钱管理、质量管理与风险管理。风险会出现在前面四个领域的各个过程中，只有有效地消除可能发生的危险因素，才能确保工程顺利推进。工程的风险贯穿于整个工程过程，因此整个工程的生命周期都应该坚持有效的风险管理。根据风险的内容，可以把风险归为以下几类： 产品规模风险：及软件的总体规模相关的风险 商业影响风险：商业风险影响到

39、软件开发的生存能力 客户特性风险：及客户的素质以及开发者与客户沟通能力相关的风险 过程定义风险：及软件过程定义相关的风险 开发环境风险：及开发工具的可用性及质量相关的风险 技术风险：技术风险是指在设计、实现、接口、验证、维护、规约的二义性、技术的不确定性、陈旧的技术等方面存在的风险 人员数目及经历带来的风险：及参及工作的软件工程师的总体技术水平及工程经历相关的风险软件工程的风险主要表达在四个方面：需求、技术、本钱、进度。风险管理是一个相当重要的话题，但涉及的问题太多，很难在本章中全部囊括，本章主要讲述进度相关的风险管理。风险管理要素软件风险管理就是在风险成为影响软件工程成功的威胁之前，识别、处

40、理并消除风险。可以在几个层次上定位风险管理：1、危机管理 救火模式，即在风险已经造成麻烦后才着手处理它们2、失败处理 觉察到了风险并迅速做出反响，但只是在风险发生之后3、风险环节 事先制定好风险发生后的补救措施，但不做任何防范措施4、着力预防 将风险识别及风险防范作为软件工程的一局部加以规划与执行5、消灭根源 识别与消除可能发生的风险的根源本章描述如何定位第4、5个层面上的进度风险管理。总体来讲，风险管理由风险评估与风险控制组成：图 5.1-1 风险管理由风险评估与风险控制组成1. 风险评估 风险识别：建立一个潜在破坏工程进度的风险列表 风险分析：评估每一个风险出现可能性及其影响，判定风险的级

41、别 风险优先级：按风险影响大小排出一个风险优先级列表，这个列表将作为风险控制的根底2. 风险控制 风险管理方案：定制一个应对每个重要风险的方案，同时应确保每一个单独的风险管理方案相互之间以及及工程方案之间保持一致 风险化解：执行每一个重要风险所对应管理方案 风险监控：对解决风险的过程进展监控。还包括：识别新的风险，并将其参加到正在进展的风险管理进程；在风险列表中移除已经化解的风险等工作风险识别1. 最常见的进度方案风险 功能蔓延 需求镀金或开发人员镀金 质量不稳定 方案过于乐观 设计欠佳 银弹综合症 研究导向的开发 人员薄弱 承包人导致的失败 开发人员及客户之间发生摩擦2. 进度方案风险列表下

42、面列出了详尽的可能对软件进度有负面影响的潜在风险。除了这里所列出的风险，大多数工程都有其特定的风险，如：“Joe要退出工程组，除非可以允许他带自己的小狗来上班，而管理层还没有决定是否同意他这样做 这样的风险就要靠自己识别了！潜在的进度方案风险： 资料来源：Gilb 1988、Boehm 1989 Pressman 1993、Thomsett 1993、Jones 1994类 型风 险1、方案编制1) 方案、资源与产品定义全凭客户或上层领导口头指令，而且不完全一致2) 方案是优化的，是“最正确状态但不现实，只能算是“期望状态3) 方案忽略了必要的任务4) 方案基于使用特定的小组成员，而那个小组成

43、员其实指望不上5) 在限定时间内无法建成已定规模大小的产品6) 产品规模比估计的要打代码行数、功能点或及前一产品规模的百分比7) 工作量大于估计数代码行数、功能点、模块等8) 进度已经拖延的工程在重新评估时过于优化或忽略工程历史9) 过度的进度压力造成生产力下降10) 目标日期提前，但没有相应地调整产品范围或可用资源11) 一个任务的延时导致相关任务的连锁反响12) 涉足不熟识的产品领域，花费在设计与实现上的时间比预期要多2、组织与管理1) 工程缺乏一个用凝聚力的最高领导人2) 由于前期乏力，工程长时间被搁置3) 辞退与削减开支导致工程小组能力下降4) 仅由管理层或市场人员进展技术决策，导致方

44、案进度延长5) 低效的工程组织构造降低生产率6) 管理层审查或决策的周期比预期的时间长7) 预算削减打乱工程方案8) 管理层作出了打击工程组积极性的决定9) 非技术的第三方的工作比预期延长预算批准、设备采购、法律审查等10) 方案性太差，无法到达期望的开发速度11) 工程方案由于压力而放弃，导致开发混乱低效12) 管理层强调英雄主义而忽略客观确切的状态报告，错过发现与改正问题的时机3、开发环境1) 设施没有及时到位2) 设施到位但不配套3) 设施拥挤、杂乱或破损4) 开发工具没能及时到位5) 开发工具不如期望的那样有效6) 开发工具的选择不是基于技术需求，不能提供方案要求的性能7) 开发人员需

45、要长时间创立工作环境或切换新开发工具8) 新开发工具的学习周期比预期的长，内容繁多4、最终用户1) 最终用户坚持新的需求2) 最终用户对于最后交付的产品不满意，要求重新设计或重做3) 最终用户不买进工程产品，无法提供后续支持4) 最终用户的意见未被采纳，造成产品无法满足最终用户的期望而必须重做5、客户1) 客户坚持新的需求2) 客户对规那么、原型与规格的审核与决策周期比预期的长3) 客户没有或不能参及规划与原型审查工作，导致需求不稳定与耗时的变更4) 客户沟通或答复的时间比预期长5) 客户坚持技术决策而导致进度方案延长6) 客户对开发进度管理过细，导致实际进展缓慢7) 客户提供的组件无法及开发

46、的产品匹配，导致额外的设计与集成工作8) 客户提供的组件质量欠佳，导致额外的设计、测试、集成与客户关系管理工作9) 客户要求的支持工具与环境不兼容、性能差或功能不完善，导致生产率降低10) 客户不承受交付的软件，尽管它满足合同的条款要求11) 客户期望的开发速度无法到达6、承包商1) 承包商没有按承诺交付组件2) 承包商递交的组件质量低下无法满足要求，必须再花时间改良3) 承包商没有买进工程开发需要的工具，进而无法提供需要的性能水平7、需求1) 需求已经成为工程的基准，但变化仍在继续2) 需求定义欠佳，但进一步的定义会扩展工程的范畴3) 添加额外的需求4) 需求定义模糊的局部需要的处理时间比预期多8、产品1) 错误发生率高的模块需要比预期更多的设计、实现与测试工作2) 校正质量低下的产品需要比预期更多的设计、实现与测试工作3) 在一个或多个新兴领域推过产品技术使得进度延长或不可预期4) 由于软件的功能错误使得需要重新设计与实现5) 开发额外不需要的功能镀金延长了方案