2022年软件开发基本原则 .pdf

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

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

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

3、项目有其自身规律和原则，只有遵守其原则并付诸相应的实践才可能使项目健康稳定地前进。本文讲述的是软件开发的基本原则，它是通用的，几乎适用于所有的软件开发项目。不同项目可以根据自身特点在原则的指导下定义相应的项目开发实践。2 策略和因素2.1 总体策略要避免混乱低效的开发， 就要求每个人能够放弃他们自己的一些坏习惯，通过采取以下四种策略实现快速开发：1、 避免典型错误名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 31 页 - - - - - - - - - 2、 打好开发基

4、础3、 管理风险，避免灾难发生4、 采用面向进度的实践图 2.1-1 快速开发的四跟支柱典型错误：是指一些经常被许多人使用的无效的开发实践，如：不现实的预期，缺乏计划，功能蔓延和银弹综合症等。将在第3章详细讲解。开发基础：是指项目开发过程中管理、技术、质量保证等方面行为和活动，如：计划编制，需求管理和技术回顾等。将在第4章详细讲解风险管理： 是指对有可能影响项目的风险进行评估和控制。将在第 5章讨论进度计划相关的风险。面向进度的实践有以下三类面向速度的实践：可以提升开发速度，帮助你更快的交付软件面向进度风险的实践：可以降低计划风险，帮助你的项目平稳推进面向可视化的实践：可以提高进程的可视化程度

5、，帮助你掌握项目动态名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 31 页 - - - - - - - - - 图 2.1-2 面向进度的实践图2.1-1 所示的前三根柱子为可能的最佳进度提供了最重要的支撑，虽然可能不是最理想的，但却是最需要的。 也就是说， 即使不借助于面向进度的实践方法，也可能实现较优化的项目进度；但是，如果仅仅依赖面向进度的实践却不可以支撑可能的最佳进度计划。图 2.1-3 仅仅依赖面向进度的实践不足以支撑最佳进度计划2.2 软件开发的四维每个软件

6、项目都有四个重要的维：人员：完成任务要么快，要么慢过程：优化人员的工作效率，或者浪费人员的时间产品：以自我完善的形式定义，或者阻碍人员达到最好效果的形式定义技术：促进或者阻碍开发的实现名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 31 页 - - - - - - - - - 图 2.2-1 开发速度的四维2.2.1 人员研究数据：人件极大地影响着生产效率，任何关注提高生产效率的组织首先必须有一套良好的人员激励、团队合作、员工选择及培训机制发挥人员最大潜能，缩短项目周期的

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

8、la 、NASA 、Raytheon 和 Xerox 等组织通过对开发过程的改进将产品上市时间缩短了一半，降低成本、减少错误为原来的1/31/10 。过程是指软件开发生命周期中定义的一系列工作流程和活动的集合。可以概括为以下三类：基本过程：包括获取过程、供应过程、开发过程、运作过程、维护过程和管理过程名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 31 页 - - - - - - - - - 支持过程：包括文档过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审

9、过程、审计过程以及问题解决过程组织过程：包括基础设施过程、改进过程以及培训过程忽略过程容易造成工作效率低下，工作目的交叉重复，产品质量难以保证等问题；另一方面， 如果过程过于严格、 过于官僚同样会挫伤人员的积极性，或者由于执行过程的成本过高而影响实际的工作效率。组织可以对现有的过程进行裁剪和调整，制定出适合特定项目的过程；或者可以为项目从头开始定义过程。无论是裁剪过程或是定义过程，应该把关注点放在以下几个方面：1、 避免返工软件项目节省时间一个最直接的方式就是确定过程，避免重复工作。 如果在项目最后阶段改变需求，就可能不得不重新设计、编码和测试；如果直到系统测试阶段才发现设计有问题，就可能不得

10、不扔掉已经细化的设计和编码。2、 质量保证质量保证有两个目的确保交付的产品能够达到可接受的质量水平在各阶段以最少的时间和成本代价查出错误应尽早在错误发生的时候就查出来，错误在产品中停留的时间越长，清楚错误所花费的时间和成本就越多。质量保证是任何开发过程中必不可少的部分。3、 开发基础一系列的软件工程实践活动形成了开发基础，如：分析、设计、构建、集成和测试等。在过程中对开发基础加以关注，并定义良好的工作规范和任务集合能防止项目失控。4、 风险管理与进度相关的风险管理是开发过程必要的组成部分。风险管理虽然不能直接提高开发速度，但它是避免项目灾难的有效实践。5、 资源目标资源包括人力资源、环境资源和

11、软硬件资源等。优化资源的调配有助于提高生产率。6、 生命周期计划生命周期计划是基本的管理计划，有助于确定软件项目要进行的活动集合和资源分配。每种周期模型都有其适用范围和缺点，为项目选择适当的生命周期模型能有效提高工作效率或降低项目风险。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 5 页，共 31 页 - - - - - - - - - 图 2.2.2-1 纯瀑布模型图 2.2.2-2 瀑布模型的另一种形式鲑鱼生命期模型图 2.2.2-3 编码修正模型（一种不规范的模型）名师资料总

12、结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 6 页，共 31 页 - - - - - - - - - 图 2.2.2-4 螺旋模型图 2.2.2-5 生鱼片模型图 2.2.2-6 包含子项目的瀑布模型图 2.2.2-7 能够降低风险的瀑布模型（对需求分析和架构设计阶段采用螺旋模型）名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 7 页，共 31 页 - - - - - - - -

13、 - 图 2.2.2-8 渐进原型模型图 2.2.2-9 阶段交付模型图 2.2.2-10 面向进度模型图 2.2.2-11 渐进交付模型名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 8 页，共 31 页 - - - - - - - - - 图 2.2.2-12 面向开发工具的设计模型名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 9 页，共 31 页 - - - - -

14、 - - - - 7、 面向客户开发谁是客户？对客户的理解取决于场合，可能是项目委托人，最终用户，市场人员或者老板。现代软件开发非常关注客户的需求与期望，开发出合符产品规格的软件只是完成了一半工作，另一半是帮助客户配置出产品能够实现的功能，而实现这些功能所花费的时间通常远远多于确定纸面上的产品规格所需要的时间。将自己站在客户的角度考虑问题是避免大量返工的最好方法。同时应该建立有效的客户沟通渠道，合理控制客户的期望值。2.2.3 产品在软件开发的四维中， 最切实的维是产品维。 对产品规模和产品特性的关注，意味着巨大的缩短计划进度的机会。削减了产品功能通常就可以缩短产品开发周期1、 产品规模产品规

15、模是对开发进度影响最大的一个因素。构建软件所需的工作量的增长比产品规模的增长要快得多，并且增长是不成比例的，所以产品规模的缩小将大大提高开发速度。将中等规模的软件削减一半通常可以使工作负荷削减2/3。2、 产品特性产品的一些非功能性需求或额外关注点会影响设计的复杂度和构建的工作量，如对性能、稳定性、可维护性和可扩展性等要求很高的产品比没有这些特性要求的产品需要更长的开发周期。2.2.4 技术从使用低效的工具转为使用高效的工具是提高开发速度的快捷方法。选择有效的工具并管理好由此带来的风险也是提高开发速度的方法。软件开发基本原则（二）典型错误名师资料总结 - - -精品资料欢迎下载 - - - -

16、 - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 10 页，共 31 页 - - - - - - - - - 大多数典型错误其表面都具有诱惑性，给人们一种诱人的前景，但通常却不能产生期望的结果。“想挽救进度已经落后的项目吗？- 给项目补充更多人员！”下面分别按照人员、过程、产品和技术四个维度列出36个典型错误。人 员典型错误 1：挫伤积极性对人员不够关心和重视；过度的进度压力；缺乏激励；过分夸张的激励等。典型错误 2：人员素质低人员能力欠佳，工作效率低，甚至做多错多。典型错误 3：对有问题的员工失控不对有问题的人员采取措施是项目组成员对领导

17、最常见的抱怨。典型错误 4：英雄主义强调个人英雄主义会导致发生额外的风险，也会削弱在软件开发过程中多个角色的合作。典型错误 5：项目后期加入人员盲目地在项目后期加入人手等于火上浇油。典型错误 6：办公室环境拥挤嘈杂拥有安静、隐蔽办公环境的人员比工作在嘈杂、拥挤环境中的人员往往会有更好的工作业绩表现。典型错误 7：开发人员与客户之间发生摩擦主要原因是缺乏沟通。这种摩擦耗费时间，它会转移客户和开发人员双方对项目工作的注意力。典型错误 8：不现实的预期过高的期望值和主观的不切实际的设想。是导致开发人员和客户或项目经理之间的摩擦常见原因之一。典型错误 9：缺乏有效的项目支持软件开发项目的许都方面都需要

18、高层的支持，包括实际的计划、 变更控制以及新型开发方法的采用等。缺乏有效的高层支持事实上注定了项目的失败。典型错误 10：缺乏各种角色的齐心协力名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 11 页，共 31 页 - - - - - - - - - 软件开发中所有主要人员必须齐心协力专注于项目，包括高层支持者、 项目领导、 项目成员、 市场人员、最终用户、客户和任何项目介入者。典型错误 11：缺乏用户介入没有用户早期介入的项目充满需求误解的风险，易受项目后期功能蔓延的威胁。典型错误

19、 12：政治高于物质“政治家”型项目强调“管理至上”，主要精力集中在他们与经理的关系上。将政治凌驾于结果之上对软件项目会造成极大伤害。典型错误 13：充满想象闭上眼睛毫无理由地希望某事将像想象那样运作。很多软件开发问题都是由于充满想象造成的。想象示例：项目组不知道他们能不能按时完成项目，但他们认为如果每个人能更努力工作，并且不出现问题，他们应该能完成项目。我们无需向客户演示最新的修改，我们确信这个效果是客户想要的。项目组错过了一个里程碑好几天了，他们说会更努力工作赶上下一个里程碑，我想他们能够及时赶上的。过 程典型错误 14：过于乐观的计划定制过于乐观的项目计划相当于自己为项目失败画出了底线，

20、导致缩短分析、 设计等关键性前期开发活动；同时也向开发人员施加了额外压力，会长期对开发人员的自信心和生产率造成巨大伤害。典型错误 15：缺乏足够的风险管理如果你不主动管理风险，风险随时会来找你，打乱你的开发计划。典型错误 16：承包人导致的失败如果不对承包商加以认真管理，交付可能延期，并且质量难以保证。典型错误 17：缺乏计划没有计划的项目就像飘荡在海洋中的小船，没人知道会飘到哪里。典型错误 18：在压力下放弃计划名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 12 页，共 31 页

21、 - - - - - - - - - 很多项目组定制了计划，但遇到了麻烦时就放弃计划。项目失败的原因不是在于放弃计划本身，而是不能及时修订计划制定替代计划，并一头栽进编码和问题处理中。典型错误 19：在模糊的项目前期浪费时间由于花在审批、预算等前期工作的时间过长，或需求无限循环等原因，导致压缩开发计划。 项目前期节省几周或几个月时间比将开发计划压缩同样时间来得更容易、更廉价，风险也更少。典型错误 20：前期活动不符合要求研究数据：前期被跳过的活动或工作通常在后期会以10倍到100倍的代价来完成。如果一项工作在项目初期需要 5小时完成，那么在项目后期你至少需要50小时才能完成它。（ Fagan

22、1976 ，Boehm and Papaccio 1988 ）典型错误 21：设计低劣前期活动不符合要求的一个特殊情况就是设计低劣。高压环境导致设计缺乏周密思考往往导致设计低劣。典型错误 22：缺少质量保证措施研究数据：项目前期砍掉 1天的质量保证活动，到项目后期就需要3到 10天的处理代价。（Jones 1994 ）典型错误 23：缺少管理控制缺少管理控制点就难以对项目的阶段和状态进行跟踪，因此不能知道项目是否按正常轨道前进。典型错误 24：太早或过于频繁的集成在构建未完全锁定时， 进行过早的集成或额外的集成不利于产品，它仅仅是在浪费时间，延长进度。典型错误 25：项目估算时遗漏必要的任务训

23、、公司和部门会议，技术评审会议等活动在项目估算时通常被遗漏。典型错误 26：追赶计划当进度落后时不重新检查任务和调整计划，而是简单地决定把进度赶上来。另一种情况是，当产品出现变更却没有做相应的计划调整名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 13 页，共 31 页 - - - - - - - - - 典型错误 27：鲁莽编码没有足够的需求基础和清晰的架构设计而进行“边编码边修改”造成太多重复工作和返工，这样的做法使项目大多以失败告终产 品典型错误 28：需求的镀金项目的产品要求

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

25、方式引导项目开发。技 术典型错误 33：银弹综合症过于相信某些技术宣传（某种开发过程、某种程序设计方法、某种开发语言），缺少在特定环境下使用这些工具的必要信息。当团队寄望利用他们来解决进度问题时，不可避免会失败的。典型错误 34：过高估计了新技术或方法带来的节省量无论采用多少新工具或方法，以及这些工具或方法有多好，他们很少能够大幅度提高生产率。软件开发由多个任务组成，特定的工具或方法只会可能提高特定任务的生产效率。同时，它们所带来的效率常常被学习它们所花费的时间抵消了。典型错误 35：项目中间切换工具名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - -

26、- - - - - 名师精心整理 - - - - - - - 第 14 页，共 31 页 - - - - - - - - - 在项目中间更换工具时， 伴随使用新工具而带来的人员学习和掌握的过程、重复的工作、 不可避免的错误等会彻底抵消它所带来的益处。典型错误 36：缺乏自动的源代码控制手段缺乏自动的源代码控制容易造成版本冲突、历时版本丢失、 更新丢失等一系列问题， 并浪费大量的时间处理这些问题。软件开发基本原则（三）基本原则“回顾一下被选为最佳项目的十个软件项目，如果说有所发现的话， 那就是最佳的项目一定是建立在最佳的软件开发基础之上的。我们都知道软件开发基础对于优秀软件的作用，但差别在于大多

27、数软件的基础薄弱，这样不可避免地使自己陷入麻烦之中”（Bill Hetzel 1993）本章的范畴只限定在确定软件开发的基本原则，解析他们是如何影响开发计划的，同时提供参考信息。本章书把软件开发基本原则实践分为三类：管理实践，技术实践和质量保证实践。管理的基本原则管理原则由以下几部分组成：判定产品规模（包括功能、复杂度和其它产品特性）根据产品规模分配资源制定资源计划监控、引导资源以保持项目方向不会偏离1. 项目估算和进度安排一个运行良好的项目一般通过三个基本步骤来定制软件开发进度表。首先估算项目规模大小然后估算完成这样规模的项目需要付出的代价最后基于这种估算定制项目进度计划如果估算不准确就会降

28、低开发效率，所以说估算和项目进度计划是软件开发的基础。精确的估算时进行有效规划的必要前提，而有效的规划又是有效开发的必要条件。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 15 页，共 31 页 - - - - - - - - - 2. 计划编制计划一个软件项目应该包括以下活动：项目估算和时间进度确定项目需要多少人参与、需要什么样的技能、合适加入以及具体人选确定项目组的运作方式确定项目采用的生命周期模型管理风险确定项目策略（例如：如何控制产品的特色，是否需要购买部分产品组建）3.

29、跟踪跟踪是一个基本的软件管理行为。如果不跟踪一个项目就不能管理它，就不会知道计划是否被贯彻执行了，也不会知道下一步该做什么，同时也无法监控项目风险。有效的跟踪能使项目组在还有时间做点什么来改正错误的时候，尽早发现进度表上的问题。制定了一个项目计划就要跟踪检查它是否在按计划进行，包括对它的进度、 费用和质量等目标的检查。典型的管理级跟踪控制包括：任务列表、进展状况会议、进展报告、里程碑审查、预算报告以及走查管理等。 典型的技术级跟踪包括： 技术审查、 技术审计和标志着里程碑是否完结的质量关口等。图 4.1.3-1 不同类型项目的可视度4. 量度老板问你：“我们能够在9各月内开发出这个产品吗？”你

30、怎么回答？！为了使开发更有效， 你需要具备软件量度方面的基本知识。你需要了解收集数据的尺度基准，包括应该要收集什么数据，如何获得这些数据。你还需要具备用来分析状态，质量和生产率的详细基准方面的知识。 任何公司想要进行快速的开发就要收集这些基本的尺度，这样才可以知道他们的开发速度是否正在改善或后退。技术基本原则1984年有关“现代程序设计实践方法技术的基本原则”的一份研究，详细论述了不使用这些基本原则就不可能具有高的生产率的内容。图4.2-1 展示了研究的结果。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - -

31、- - - - - 第 16 页，共 31 页 - - - - - - - - - 图 4.2-1 生产率与“现代程序设计实践方法”的关系（不广泛地使用“现代程序设计实践方法”就无法具有高的生产率）很显然，不采用现代程序设计实践方法的项目不可能具有高的生产率。但技术基本原则的应用，就其本身而言，不足以创造高的生产率。一些项目使用了大量现代程序设计实践方法，但是仍旧和那些完全没有使用该方法的项目具有一样的生产率。因此，注意技术的基本原则是很必要的，但却不足以达到快速开发的目的（例如犯了某些典型错误）。1. 需求管理研究数据：典型项目平均会经历 25% 的需求变化，从而至少产生25% 的额外费用和

32、时间。一项针对 8000多个项目的调查显示， 导致项目推迟发布、 超出预算、 功能比预期减少的最重要的三个原因缺乏用户的介入、不完善的需求分析和用户不断改变需求，都和需求管理有关。（Standish Group1994 ）一项软件工程研究所的调查也有相同的结论：超过半数的项目都遭遇过不充分的需求管理的麻烦。 （Kitson and Masters 1993）需求管理就是收集需求，把需求记录成文档、电子邮件、用户界面串连脚本、可实现的原型等形式，然后依此来跟踪设计和编码，并随时管理、修改需求，以适应项目后续的过程。成功的需求管理取决于了解足够的不同的实践经验，以便能够为特定项目选择可借鉴的一种。

33、需求管理的基础：需求分析方法：包括结构分析、数据结构分析和面向对象分析系统建模实践：如类图表、数据流图表、实体关系图表、数据字典符号和状态跃变图表沟通实践：如联合应用开发、用户界面原型和常规会谈实践等需求管理和其它生命周期类型的关系：如渐进原型、 阶段交付、 螺旋模型、 瀑布模型和编码修正名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 17 页，共 31 页 - - - - - - - - - 需求管理在两个方面对开发速度发挥着巨大的调节作用：首先，正规的需求管理中， 需求收集往往比

34、其他软件开发活动完成得要从容些。如果能加快需求步伐而不伤害质量，就可以缩短总的开发时间。第二，正确地把需求摆在首位，往往要比被动地这样做所花的时间少得多。一些需求管理实践基本原则能够减少需求变化的数量，其他开发实践的基本原则能够减少因需求改变而产生的费用。想象一下， 如果把需求变化从 25% 减少到 10% ，同时把每个需求变化导致的费用减少5%-10% ，那么综合的效果会怎样呢？2. 设计研究数据：一个设计上的错误如果到系统测试时才被发现，那么花费的修补时间要比它在设计阶段时被发现所花费的时间多 10倍。 （Dunn 1984）设计是系统构建、项目进度计划、项目跟踪和项目控制的基础。体系结构

35、和设计的基本原则：主要设计风格：如面向对象设计、结构化设计和数据结构设计基础设计概念：如信息隐藏、模块化、抽象、封装、聚合、耦合、层次、继承、多态、基本算法和基本数据结构对典型挑战性事件的标准设计：包括异常处理、 国际化、 本地化、 便携性、字串存储、 输入输出、内存管理、数据存储、浮点算法、数据库设计、性能和复用对特殊领域应用程序设计的独有思考：例如财务应用、科学应用、嵌入式系统、实时系统、安全性要求高的软件等架构安排：如子系统组织、分层结构、子系统通信方式和典型的系统架构设计工具的使用3. 构建当构建开始时， 项目成功与否大多就已经注定了。需求管理和设计对开发进度计划的调节作用比构建的调节

36、作用大得多，这意味着小的波动可以导致进度的重大变化。尽管构建是一个低层次的活动， 但是它确实可以提供许多机会进一步改进时间效率低的任务或优化一些任务。例如，花时间对那些无需镀金的功能进行镀金；调试那些无用的多余代码，或者对那些并不知道是否需要优化的片段尽心优化。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 18 页，共 31 页 - - - - - - - - - 构建的基本原则：编码实践：如变量和函数命名、版面布局和文档数据相关概念：如作用范围、持续和捆绑时间特定数据类型的使用方

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

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

39、项目进展缓慢，并陷入更深的进度问题中。 （Jones 1994 ）重做有缺陷的需求、设计和编码通常花费整个软件开发成本的40% 50% 。 （Jones 1968b ，Boehm 1987a）最糟糕的情况下，在运行中的软件项目只修改一次软件需求问题的花费通常是在需求分析阶段所花时间的 50到200倍。 （Boehm and Papacio 1988 ）大约60% 的错误通常在设计阶段就存在了。（Gilb 1988 ）如果可以尽早地预防并修正漏洞，可以节省大量时间，在进度的安排上占了先机。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - -

40、 - 名师精心整理 - - - - - - - 第 19 页，共 31 页 - - - - - - - - - 图 4.3-1 错误率和开发时间的关系（大多数情况下，具有低错误率的项目同时实现了最短日程的目标）1. 易错模块易错模块是那些容易存在或多或少漏洞的模块。研究数据：IBM的 IMS项目中， 57% 的漏洞存在于 7% 的模块中。（Jones 1991 ）程序中 20% 的模块包含了 80% 的错误。（Boehm 1987b ）高错误率的模块开发起来要比其它模块更加昂贵和耗时，如果普通模块开发每个功能点要花费$500$1000，那么易错模块每个功能点就要花费$2000$4000。 （J

41、ones 1994 ）易错模块往往比系统中的其它模块更复杂，缺乏结构化， 或者不同寻常的庞大， 并且往往在背负压力下开发，往往没有被完全测试过。对软件开发特别重要的一个方面就是对易错模块的质量保证。2. 测试最寻常的质量保证实践就是毋庸置疑地进行测试，两种基本的测试方法单元测试：程序员检查他自己的代码是否工作正常系统测试：独立测试员检查整个系统是否如期望的那样正常运行研究数据：测试的有效性差异是巨大的。单元测试可以找到程序中10% 50% 的漏洞；系统测试可以发现20% 60% 的程序漏洞。加在一起，累积的漏洞检测率经常少于60% 。 （Jones 1986a ）剩下的错误要么通过其它的查错技

42、巧（如技术回顾） 发现，要么就是在产品发布后被最终用户发现。平衡测试和快速开发的最佳办法是在坏消息出现之前做好计划设置对坏消息的测试，尽早地发现问题。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 20 页，共 31 页 - - - - - - - - - 3. 技术回顾技术回顾包括在需求、 设计、编码和测试等事件中用于查错的所有类型的回顾。回顾在形式上和效果上是多样的，它在开发速度上比在测试上扮演更重要的角色。下面讲述最常见的几种回顾。1) 走查走查是指任何两个以上的开发人员以增进

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

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

45、 Graham 1993）一项对大型程序的调查结果显示，在检查上每花1小时，就可以避免在维护上33个小时的花费。检查比测试有效 20倍以上。 （Russel 1991 ）软件开发基本原则（四）风险管理1988年，Peat Marwick针对600家成功公司的调查结果显示，35% 的公司有过软件项目失控的经名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 21 页，共 31 页 - - - - - - - - - 历。 （Rothfeder 1988 ）1982年，Allstate公司宣

46、布其公司运营全部要实行自动化。他们启动了一个将耗时5年投资 800万美元的大型项目，而在花费了6年和1500万美元后， Allstate公司重新调整了目标和最终期限，重新调整后的预算大约1亿美元。1988年，Westpac Banking公司决定重新设计他们的信息系统。他们做了5年、 8500万美元的计划。3年后，在花费了 1.5 亿美元却依然收效甚微时，Westpac Banking 公司为了减少损失，取消了这个项目，并为此裁员500人。 （Glass 1992 ）从项目管理的角度来看，有五大硬性知识领域：范围管理、进度管理、成本管理、质量管理和风险管理。风险会出现在前面四个领域的各个过程中

47、，只有有效地消除可能发生的危险因素，才能确保项目顺利推进。 项目的风险贯穿于整个项目过程，因此整个项目的生命周期都应该坚持有效的风险管理。根据风险的内容，可以把风险归为以下几类：产品规模风险：与软件的总体规模相关的风险商业影响风险：商业风险影响到软件开发的生存能力客户特性风险：与客户的素质以及开发者和客户沟通能力相关的风险过程定义风险：与软件过程定义相关的风险开发环境风险：与开发工具的可用性及质量相关的风险技术风险：技术风险是指在设计、实现、接口、验证、维护、规约的二义性、技术的不确定性、陈旧的技术等方面存在的风险人员数目及经验带来的风险：与参与工作的软件工程师的总体技术水平及项目经验相关的风

48、险软件项目的风险主要体现在四个方面：需求、技术、成本、进度。风险管理是一个相当重要的话题，但涉及的问题太多，很难在本章中全部囊括，本章主要讲述进度相关的风险管理。风险管理要素软件风险管理就是在风险成为影响软件项目成功的威胁之前，识别、处理并消除风险。 可以在几个层次上定位风险管理：1、危机管理 救火模式，即在风险已经造成麻烦后才着手处理它们2、失败处理 觉察到了风险并迅速做出反应，但只是在风险发生之后3、风险环节 事先制定好风险发生后的补救措施，但不做任何防范措施4、着力预防 将风险识别与风险防范作为软件项目的一部分加以规划和执行5、消灭根源 识别和消除可能发生的风险的根源本章描述如何定位第

49、4、 5个层面上的进度风险管理。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 22 页，共 31 页 - - - - - - - - - 总体来讲，风险管理由风险评估和风险控制组成：图 5.1-1 风险管理由风险评估和风险控制组成1. 风险评估风险识别：建立一个潜在破坏项目进度的风险列表风险分析：评估每一个风险出现可能性及其影响，判定风险的级别风险优先级：按风险影响大小排出一个风险优先级列表，这个列表将作为风险控制的基础2. 风险控制风险管理计划：定制一个应对每个重要风险的方案，同

50、时应确保每一个单独的风险管理计划相互之间以及与项目计划之间保持一致风险化解：执行每一个重要风险所对应管理计划风险监控：对解决风险的过程进行监控。还包括：识别新的风险，并将其加入到正在进行的风险管理进程；在风险列表中移除已经化解的风险等工作风险识别1. 最常见的进度计划风险功能蔓延需求镀金或开发人员镀金质量不稳定计划过于乐观设计欠佳银弹综合症研究导向的开发人员薄弱承包人导致的失败开发人员与客户之间发生摩擦2. 进度计划风险列表下面列出了详尽的可能对软件进度有负面影响的潜在风险。除了这里所列出的风险， 大多数项目名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - -