软件开发基本原则.docx
《软件开发基本原则.docx》由会员分享，可在线阅读，更多相关《软件开发基本原则.docx（34页珍藏版）》请在冰豆网上搜索。
软件开发基本原则
软件开发基本原则
（一）——策略和因素
1概述
时间--成本--质量（或特性）是评价软件项目成败的三个关键指标，这三个指标之间相互影响和制约，形成了所谓的“项目管理三角形”。
要提高质量或增加特性意味着成本和时间的增加，或两者都增加；要在时间不变的前提下缩减开发成本或成本不变的前提下缩减时间则意味着质量的下降或特性的削减。
图1-1项目管理三角形
上述分析其实只是理论上的“理想平衡”状态。
现实工作中往往出现的情形是：
要么时间超过计划，要么成本超过预算，要么质量达不到要求，要么三个指标都达不到预期。
典型例子：
由于客户的压力需要尽量缩减开发时间，由于企业间的竞争和盈利压力需要尽量节约成本，因此需要一个人做两个人的工作，一个月做两个月的工作，同时压缩需求分析、设计、测试、评审和项目会议等活动。
可想而知，即使软件的构建阶段能够按时完成，但做出的软件质量是难以保证的。
更糟糕的还在后面：
由于质量的低劣，构建阶段结束后对系统进行集成测试时，很多问题就会暴露出来：
对某些需求的理解有误差，导致这部分功能要重新分析、设计、编码和测试；架构设计缺乏整体思维导致系统不同模块各自为政，产生大量重复的难以维护的代码；编码太仓促导致一大堆的Bug；沟通不畅顺导致模块接口不兼容……从而项目被带入了修改无限循环地带，即使勉强上线发布，修改还是一直持续，直至最后，没有人再敢接近这套代码，对这个项目谈虎色变。
软件开发项目有其自身规律和原则，只有遵守其原则并付诸相应的实践才可能使项目健康稳定地前进。
本文讲述的是软件开发的基本原则，它是通用的，几乎适用于所有的软件开发项目。
不同项目可以根据自身特点在原则的指导下定义相应的项目开发实践。
2策略和因素
2.1总体策略
要避免混乱低效的开发，就要求每个人能够放弃他们自己的一些坏习惯，通过采取以下四种策略实现快速开发：
1、避免典型错误
2、打好开发基础
3、管理风险，避免灾难发生
4、采用面向进度的实践
图2.1-1快速开发的四跟支柱
典型错误：
是指一些经常被许多人使用的无效的开发实践，如：
不现实的预期，缺乏计划，功能蔓延和银弹综合症等。
将在第3章详细讲解。
开发基础：
是指项目开发过程中管理、技术、质量保证等方面行为和活动，如：
计划编制，需求管理和技术回顾等。
将在第4章详细讲解
风险管理：
是指对有可能影响项目的风险进行评估和控制。
将在第5章讨论进度计划相关的风险。
面向进度的实践有以下三类
∙面向速度的实践：
可以提升开发速度，帮助你更快的交付软件
∙面向进度风险的实践：
可以降低计划风险，帮助你的项目平稳推进
∙面向可视化的实践：
可以提高进程的可视化程度，帮助你掌握项目动态
图2.1-2面向进度的实践
图2.1-1所示的前三根柱子为可能的最佳进度提供了最重要的支撑，虽然可能不是最理想的，但却是最需要的。
也就是说，即使不借助于面向进度的实践方法，也可能实现较优化的项目进度；但是，如果仅仅依赖面向进度的实践却不可以支撑可能的最佳进度计划。
图2.1-3仅仅依赖面向进度的实践不足以支撑最佳进度计划
2.2软件开发的四维
每个软件项目都有四个重要的维：
∙人员：
完成任务要么快，要么慢
∙过程：
优化人员的工作效率，或者浪费人员的时间
∙产品：
以自我完善的形式定义，或者阻碍人员达到最好效果的形式定义
∙技术：
促进或者阻碍开发的实现
图2.2.2-1纯瀑布模型
图2.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、面向客户开发
谁是客户？
对客户的理解取决于场合，可能是项目委托人，最终用户，市场人员或者老板。
现代软件开发非常关注客户的需求与期望，开发出合符产品规格的软件只是完成了一半工作，另一半是帮助客户配置出产品能够实现的功能，而实现这些功能所花费的时间通常远远多于确定纸面上的产品规格所需要的时间。
将自己站在客户的角度考虑问题是避免大量返工的最好方法。
同时应该建立有效的客户沟通渠道，合理控制客户的期望值。
2.2.3产品
在软件开发的四维中，最切实的维是产品维。
对产品规模和产品特性的关注，意味着巨大的缩短计划进度的机会。
削减了产品功能通常就可以缩短产品开发周期
1、产品规模
产品规模是对开发进度影响最大的一个因素。
构建软件所需的工作量的增长比产品规模的增长要快得多，并且增长是不成比例的，所以产品规模的缩小将大大提高开发速度。
将中等规模的软件削减一半通常可以使工作负荷削减2/3。
2、产品特性
产品的一些非功能性需求或额外关注点会影响设计的复杂度和构建的工作量，如对性能、稳定性、可维护性和可扩展性等要求很高的产品比没有这些特性要求的产品需要更长的开发周期。
2.2.4技术
从使用低效的工具转为使用高效的工具是提高开发速度的快捷方法。
选择有效的工具并管理好由此带来的风险也是提高开发速度的方法。
软件开发基本原则
（二）——典型错误
大多数典型错误其表面都具有诱惑性，给人们一种诱人的前景，但通常却不能产生期望的结果。
“想挽救进度已经落后的项目吗？
----给项目补充更多人员！
”
下面分别按照人员、过程、产品和技术四个维度列出36个典型错误。
人员
典型错误1：
挫伤积极性
对人员不够关心和重视；过度的进度压力；缺乏激励；过分夸张的激励等。
典型错误2：
人员素质低
人员能力欠佳，工作效率低，甚至做多错多。
典型错误3：
对有问题的员工失控
不对有问题的人员采取措施是项目组成员对领导最常见的抱怨。
典型错误4：
英雄主义
强调个人英雄主义会导致发生额外的风险，也会削弱在软件开发过程中多个角色的合作。
典型错误5：
项目后期加入人员
盲目地在项目后期加入人手等于火上浇油。
典型错误6：
办公室环境拥挤嘈杂
拥有安静、隐蔽办公环境的人员比工作在嘈杂、拥挤环境中的人员往往会有更好的工作业绩表现。
典型错误7：
开发人员与客户之间发生摩擦
主要原因是缺乏沟通。
这种摩擦耗费时间，它会转移客户和开发人员双方对项目工作的注意力。
典型错误8：
不现实的预期
过高的期望值和主观的不切实际的设想。
是导致开发人员和客户或项目经理之间的摩擦常见原因之一。
典型错误9：
缺乏有效的项目支持
软件开发项目的许都方面都需要高层的支持，包括实际的计划、变更控制以及新型开发方法的采用等。
缺乏有效的高层支持事实上注定了项目的失败。
典型错误10：
缺乏各种角色的齐心协力
软件开发中所有主要人员必须齐心协力专注于项目，包括高层支持者、项目领导、项目成员、市场人员、最终用户、客户和任何项目介入者。
典型错误11：
缺乏用户介入
没有用户早期介入的项目充满需求误解的风险，易受项目后期功能蔓延的威胁。
典型错误12：
政治高于物质
“政治家”型项目强调“管理至上”，主要精力集中在他们与经理的关系上。
将政治凌驾于结果之上对软件项目会造成极大伤害。
典型错误13：
充满想象
闭上眼睛毫无理由地希望某事将像想象那样运作。
很多软件开发问题都是由于充满想象造成的。
想象示例：
项目组不知道他们能不能按时完成项目，但他们认为如果每个人能更努力工作，并且不出现问题，他们应该能完成项目。
我们无需向客户演示最新的修改，我们确信这个效果是客户想要的。
项目组错过了一个里程碑好几天了，他们说会更努力工作赶上下一个里程碑，我想他们能够及时赶上的。
过程
典型错误14：
过于乐观的计划
定制过于乐观的项目计划相当于自己为项目失败画出了底线，导致缩短分析、设计等关键性前期开发活动；同时也向开发人员施加了额外压力，会长期对开发人员的自信心和生产率造成巨大伤害。
典型错误15：
缺乏足够的风险管理
如果你不主动管理风险，风险随时会来找你，打乱你的开发计划。
典型错误16：
承包人导致的失败
如果不对承包商加以认真管理，交付可能延期，并且质量难以保证。
典型错误17：
缺乏计划
没有计划的项目就像飘荡在海洋中的小船，没人知道会飘到哪里。
典型错误18：
在压力下放弃计划
很多项目组定制了计划，但遇到了麻烦时就放弃计划。
项目失败的原因不是在于放弃计划本身，而是不能及时修订计划制定替代计划，并一头栽进编码和问题处理中。
典型错误19：
在模糊的项目前期浪费时间
由于花在审批、预算等前期工作的时间过长，或需求无限循环等原因，导致压缩开发计划。
项目前期节省几周或几个月时间比将开发计划压缩同样时间来得更容易、更廉价，风险也更少。
典型错误20：
前期活动不符合要求
研究数据：
前期被跳过的活动或工作通常在后期会以10倍到100倍的代价来完成。
如果一项工作在项目初期需要5小时完成，那么在项目后期你至少需要50小时才能完成它。
（Fagan1976，BoehmandPapaccio1988）
典型错误21：
设计低劣
前期活动不符合要求的一个特殊情况就是设计低劣。
高压环境导致设计缺乏周密思考往往导致设计低劣。
典型错误22：
缺少质量保证措施
研究数据：
项目前期砍掉1天的质量保证活动，到项目后期就需要3到10天的处理代价。
（Jones1994）
典型错误23：
缺少管理控制
缺少管理控制点就难以对项目的阶段和状态进行跟踪，因此不能知道项目是否按正常轨道前进。
典型错误24：
太早或过于频繁的集成
在构建未完全锁定时，进行过早的集成或额外的集成不利于产品，它仅仅是在浪费时间，延长进度。
典型错误25：
项目估算时遗漏必要的任务
训、公司和部门会议，技术评审会议等活动在项目估算时通常被遗漏。
典型错误26：
追赶计划
当进度落后时不重新检查任务和调整计划，而是简单地决定把进度赶上来。
另一种情况是，当产品出现变更却没有做相应的计划调整
典型错误27：
鲁莽编码
没有足够的需求基础和清晰的架构设计而进行“边编码边修改”造成太多重复工作和返工，这样的做法使项目大多以失败告终
产品
典型错误28：
需求的镀金
项目的产品要求要求比实际需求多得多的产品特性或复杂功能，却又不给进度计划分配足够的时间。
典型错误29：
功能蔓延
在整个开发过程中，项目平均会有25%的需求变更，对软件计划至少有25%的影响。
如果任由客户不断提出新需求，项目就会一直都做不完
典型错误30：
开发人员的镀金
开发人员着迷于新技术，有时渴望在自己的产品中使用这些技术，而不管那些技术是否适合或是否会对系统整体造成破坏。
典型错误31：
又推又拉的交易
管理者批准进度落后的项目顺延，但同时又给这个项目加入新任务。
典型错误32：
研究导向的开发
软件开发进度是完全有理由可以预测的，而软件研究进度甚至理论上都是不可预知的，不能采用像软件研究一样的工作方式引导项目开发。
技术
典型错误33：
银弹综合症
过于相信某些技术宣传（某种开发过程、某种程序设计方法、某种开发语言），缺少在特定环境下使用这些工具的必要信息。
当团队寄望利用他们来解决进度问题时，不可避免会失败的。
典型错误34：
过高估计了新技术或方法带来的节省量
无论采用多少新工具或方法，以及这些工具或方法有多好，他们很少能够大幅度提高生产率。
软件开发由多个任务组成，特定的工具或方法只会可能提高特定任务的生产效率。
同时，它们所带来的效率常常被学习它们所花费的时间抵消了。
典型错误35：
项目中间切换工具
在项目中间更换工具时，伴随使用新工具而带来的人员学习和掌握的过程、重复的工作、不可避免的错误等会彻底抵消它所带来的益处。
典型错误36：
缺乏自动的源代码控制手段
缺乏自动的源代码控制容易造成版本冲突、历时版本丢失、更新丢失等一系列问题，并浪费大量的时间处理这些问题。
软件开发基本原则（三）——基本原则
“回顾一下被选为‘最佳项目’的十个软件项目，如果说有所发现的话，那就是——最佳的项目一定是建立在最佳的软件开发基础之上的。
我们都知道软件开发基础对于优秀软件的作用，但差别在于大多数软件的基础薄弱，这样不可避免地使自己陷入麻烦之中”
（BillHetzel1993）
本章的范畴只限定在确定软件开发的基本原则，解析他们是如何影响开发计划的，同时提供参考信息。
本章书把软件开发基本原则实践分为三类：
管理实践，技术实践和质量保证实践。
管理的基本原则
管理原则由以下几部分组成：
判定产品规模（包括功能、复杂度和其它产品特性）
根据产品规模分配资源
制定资源计划
监控、引导资源以保持项目方向不会偏离
1.项目估算和进度安排
一个运行良好的项目一般通过三个基本步骤来定制软件开发进度表。
首先估算项目规模大小
然后估算完成这样规模的项目需要付出的代价
最后基于这种估算定制项目进度计划
如果估算不准确就会降低开发效率，所以说估算和项目进度计划是软件开发的基础。
精确的估算时进行有效规划的必要前提，而有效的规划又是有效开发的必要条件。
2.计划编制
计划一个软件项目应该包括以下活动：
∙项目估算和时间进度
∙确定项目需要多少人参与、需要什么样的技能、合适加入以及具体人选
∙确定项目组的运作方式
∙确定项目采用的生命周期模型
∙管理风险
∙确定项目策略（例如：
如何控制产品的特色，是否需要购买部分产品组建）
3.跟踪
跟踪是一个基本的软件管理行为。
如果不跟踪一个项目就不能管理它，就不会知道计划是否被贯彻执行了，也不会知道下一步该做什么，同时也无法监控项目风险。
有效的跟踪能使项目组在还有时间做点什么来改正错误的时候，尽早发现进度表上的问题。
制定了一个项目计划就要跟踪检查它是否在按计划进行，包括对它的进度、费用和质量等目标的检查。
典型的管理级跟踪控制包括：
任务列表、进展状况会议、进展报告、里程碑审查、预算报告以及走查管理等。
典型的技术级跟踪包括：
技术审查、技术审计和标志着里程碑是否完结的质量关口等。
图4.1.3-1不同类型项目的可视度
4.量度
老板问你：
“我们能够在9各月内开发出这个产品吗？
”——你怎么回答？
！
为了使开发更有效，你需要具备软件量度方面的基本知识。
你需要了解收集数据的尺度基准，包括应该要收集什么数据，如何获得这些数据。
你还需要具备用来分析状态，质量和生产率的详细基准方面的知识。
任何公司想要进行快速的开发就要收集这些基本的尺度，这样才可以知道他们的开发速度是否正在改善或后退。
技术基本原则
1984年有关“现代程序设计实践方法——技术的基本原则”的一份研究，详细论述了不使用这些基本原则就不可能具有高的生产率的内容。
图4.2-1展示了研究的结果。
图4.2-1生产率与“现代程序设计实践方法”的关系
（不广泛地使用“现代程序设计实践方法”就无法具有高的生产率）
很显然，不采用现代程序设计实践方法的项目不可能具有高的生产率。
但技术基本原则的应用，就其本身而言，不足以创造高的生产率。
一些项目使用了大量现代程序设计实践方法，但是仍旧和那些完全没有使用该方法的项目具有一样的生产率。
因此，注意技术的基本原则是很必要的，但却不足以达到快速开发的目的（例如犯了某些典型错误）。
1.需求管理
研究数据：
典型项目平均会经历25%的需求变化，从而至少产生25%的额外费用和时间。
一项针对8000多个项目的调查显示，导致项目推迟发布、超出预算、功能比预期减少的最重要的三个原因——缺乏用户的介入、不完善的需求分析和用户不断改变需求，都和需求管理有关。
（StandishGroup1994）
一项软件工程研究所的调查也有相同的结论：
超过半数的项目都遭遇过不充分的需求管理的麻烦。
（KitsonandMasters1993）
需求管理就是收集需求，把需求记录成文档、电子邮件、用户界面串连脚本、可实现的原型等形式，然后依此来跟踪设计和编码，并随时管理、修改需求，以适应项目后续的过程。
成功的需求管理取决于了解足够的不同的实践经验，以便能够为特定项目选择可借鉴的一种。
需求管理的基础：
需求分析方法：
包括结构分析、数据结构分析和面向对象分析
系统建模实践：
如类图表、数据流图表、实体关系图表、数据字典符号和状态跃变图表
沟通实践：
如联合应用开发、用户界面原型和常规会谈实践等
需求管理和其它生命周期类型的关系：
如渐进原型、阶段交付、螺旋模型、瀑布模型和编码修正
需求管理在两个方面对开发速度发挥着巨大的调节作用：
首先，正规的需求管理中，需求收集往往比其他软件开发活动完成得要从容些。
如果能加快需求步伐而不伤害质量，就可以缩短总的开发时间。
第二，正确地把需求摆在首位，往往要比被动地这样做所花的时间少得多。
一些需求管理实践基本原则能够减少需求变化的数量，其他开发实践的基本原则能够减少因需求改变而产生的费用。
想象一下，如果把需求变化从25%减少到10%，同时把每个需求变化导致的费用减少5%-10%，那么综合的效果会怎样呢？
2.设计
研究数据：
一个设计上的错误如果到系统测试时才被发现，那么花费的修补时间要比它在设计阶段时被发现所花费的时间多10倍。
（Dunn1984）
设计是系统构建、项目进度计划、项目跟踪和项目控制的基础。
体系结构和设计的基本原则：
主要设计风格：
如面向对象设计、结构化设计和数据结构设计
基础设计概念：
如信息隐藏、模块化、抽象、封装、聚合、耦合、层次、继承、多态、基本算法和基本数据结构
对典型挑战性事件的标准设计：
包括异常处理、国际化、本地化、便携性、字串存储、输入输出、内存管理、数据存储、浮点算法、数据库设计、性能和复用
对特殊领域应用程序设计的独有思考：
例如财务应用、科学应用、嵌入式系统、实时系统、安全性要求高的软件等
架构安排：
如子系统组织、分层结构、子系统通信方式和典型的系统架构
设计工具的使用
3.构建
当构建开始时，项目成功与否大多就已经注定了。
需求管理和设计对开发进度计划的调节作用比构建的调节作用大得多，这意味着小的波动可以导致进度的重大变化。
尽管构建是一个低层次的活动，但是它确实可以提供许多机会进一步改进时间效率低的任务或优化一些任务。
例如，花时间对那些无需镀金的功能进行镀金；调试那些无用的多余代码，或者对那些并不知道是否需要优化的片段尽心优化。
构建的基本原则：
∙编码实践：
如变量和函数命名、版面布局和文档
∙数据相关概念：
如作用范围、持续和捆绑时间
∙特定数据类型的使用方针：
如通用基础数据类型、枚举、常量、数组和指针
∙控制相关的概念：
如组织整齐的代码、条件的使用、循环的控制、复杂度的控制、特殊控制结构的使用（goto、return、递归）
∙断言和其它以代码为核心的错误检测方法
∙对例程、模块、类和文件代码打包的规则
∙单元测试和调试实践
∙集成策略：
如增量式集成、大爆炸式集成和渐进开发
∙代码优化策略和实践
∙与所使用的特定编程语言相关的其他事情
∙使用构建工具：
如编译环境、群组工作支持、源代码控制、代码库和代码生成器
4.软件配置管理
软件配置管理（SCM）是管理项目成果的一种实践方法，能使项目在全程中保持一致的状态。
SCM包括评估变更、跟踪变更、处理多版本，以及在不同时间保存项目成果的备份等实践。
质量保证基本原则
很多公司现阶段开发软件都有一定的不当之处，使得他们的开发时间比需要的长。
在调查了4000个软件项目后，CapersJones递交报告说，糟糕的质量是进度被拖延的最普遍的原因之一。
他还说，中途被取消的项目中，大约有一半是由于其糟糕的质量。
（Jones1994）
一项软件工程研究所的调查显示，大约有60%的公司遭受着不适当的质量保证体系的困扰。
（KitsonandMasters1993）。
在过大的时间压力下发布的产品，其错误率是正常情况下的4倍。
有进度问题的项目经常是在进行艰苦的工作而不是轻松活跃的工作，关注质量被认为是有些奢侈。
但其结果却是项目进展缓慢，并陷入更深的进度问题中。
（Jones1994）
重做有缺陷的需求、设计和编码通常花费整个软件开发成本的40%—50%。
（Jones1968b，Boehm1987a）
最糟糕的情况下，在运行中的软件项目只修改一次软件需求问题的花费通常是在需求分析阶段所花时间的50到200倍。
（BoehmandPapacio1988）
大约60%的错误通常在设计阶段就存在了。
（Gilb1988）
如果可以尽早地预防并修正漏洞，可以节省大量时间，在进度的安排上占了先机。
图4.3-1错误率和开发时间的关系
（大多数情况下，具有低错误率的项目同时实现了最短日程的目标）
1.易错模块
易错模块是那些容易存在或多或少漏洞的模块。
研究数据：
IBM的IMS项目中，57%的漏洞存在于7%的模块中。
（Jones1991）
程序中20%的模块包含了80%的错误。
（Boehm1987b）
高错误率的模块开发起来要比其它模块更加昂贵和耗时，如果普通模块开发每个功能点要花费$500—$1000，那么易错模块每个功能点就要花费$2000—$4000。
（Jones1994）
易错模块往往比系统中的其它模块更复杂，缺乏结构化，或者不同寻常的庞大，并且往往在背负压力下开发，往往没有被完全测试过。
对软件开发特别重要的一个方面就是对易错模块的质量保证。
2.测试
最寻常的质量保证实践就是毋庸置疑地进行测试，两种基本的测试方法
∙单元测试：
程序员检查他自己的代码是否工作正常
∙系统测试：
独立测试员检查整个系统是否如期望的那样正常运行
研究数据：
测试的有效性差异是巨大的。
单元测试可以找到程序中10%—50%的漏洞；系统测试可以发现20%—60%的程序漏洞。
加在一起，累积的漏洞检测率经常少于60%。
（Jones1986a）
剩下的错误要么通过其它的查错技巧（如技术回顾）发现，要么就是在产品发布后被最终用户发现。
平衡测试和快速开发的最佳办法是在坏消息出现之前做好计划——设置对坏消息的测试，尽早地发现问题。
3.技术回顾
技术回顾包括在需求、设计、编码和测试等事件中用于查错的所有类型的回顾。
回顾在形式上和效果上是多样的，它在开发速度上比在测试上扮演更重要的角色。
下面讲述最常见的几种回顾。
1）走查
走查是指任何两个以上的开发人员以增进软件质量为目的所召开的回顾技术工作会议。
走查可能是最平常的非正式回顾，走查可以在写设计说明书时，设计和编码完成之前就发现漏洞。
研究数据：
走查可以发现30%—70%的程序漏洞。
（Myers1979，Boehm1987b，Yourdon1989b）
2）代码阅读
代码阅读时比走查更正式些的回顾方式，但仅适用于代码。
代码阅读时，写这段代码的程序员把代码清单交给两个或更多的审阅者审阅，审阅者阅读代码，并把发现的错误报告给编写者。
研究数据：
NASA的软件工程实验室的一项研究发现：
代码阅读能发现的漏洞是测试时能发现的漏洞的两倍。
（Card1987）
3）检查
检查是一种正式的技术回顾，它被认为是在整个项目中最具效率的查错方式。
使用检查的方法，开发人员需要接受检查的特殊训练，并且在检查中扮演重要的角色。
在检查会议之前“仲裁人”发布产品要被检验评估的消息和检查列表，“审阅人”在会议前检查程序，在检查会议上“作者”通
升级会员 