软件开发基本原则（三）—— 基本原则

管理的基本原则

　　管理原则由以下几部分组成：

• 判定产品规模（包括功能、复杂度和其它产品特性）
• 根据产品规模分配资源
• 制定资源计划
• 监控、引导资源以保持项目方向不会偏离

1. 项目估算和进度安排

　　一个运行良好的项目一般通过三个基本步骤来定制软件开发进度表。

• 首先估算项目规模大小
• 然后估算完成这样规模的项目需要付出的代价
• 最后基于这种估算定制项目进度计划

　

　　如果估算不准确就会降低开发效率，所以说估算和项目进度计划是软件开发的基础。精确的估算时进行有效规划的必要前提，而有效的规划又是有效开发的必要条件。

2. 计划编制

　　计划一个软件项目应该包括以下活动：

• 项目估算和时间进度
• 确定项目需要多少人参与、需要什么样的技能、合适加入以及具体人选
• 确定项目组的运作方式
• 确定项目采用的生命周期模型
• 管理风险
• 确定项目策略（例如：如何控制产品的特色，是否需要购买部分产品组建）

3. 跟踪

　　跟踪是一个基本的软件管理行为。如果不跟踪一个项目就不能管理它，就不会知道计划是否被贯彻执行了，也不会知道下一步该做什么，同时也无法监控项目风险。有效的跟踪能使项目组在还有时间做点什么来改正错误的时候，尽早发现进度表上的问题。

　　制定了一个项目计划就要跟踪检查它是否在按计划进行，包括对它的进度、费用和质量等目标的检查。典型的管理级跟踪控制包括：任务列表、进展状况会议、进展报告、里程碑审查、预算报告以及走查管理等。典型的技术级跟踪包括：技术审查、技术审计和标志着里程碑是否完结的质量关口等。

图 4.1.3-1 不同类型项目的可视度

4. 量度

　　老板问你：“我们能够在9各月内开发出这个产品吗？”——你怎么回答？！

　　为了使开发更有效，你需要具备软件量度方面的基本知识。你需要了解收集数据的尺度基准，包括应该要收集什么数据，如何获得这些数据。你还需要具备用来分析状态，质量和生产率的详细基准方面的知识。任何公司想要进行快速的开发就要收集这些基本的尺度，这样才可以知道他们的开发速度是否正在改善或后退。

技术基本原则

　　1984年有关“现代程序设计实践方法——技术的基本原则”的一份研究，详细论述了不使用这些基本原则就不可能具有高的生产率的内容。图4.2-1展示了研究的结果。

图 4.2-1 生产率与“现代程序设计实践方法”的关系

（不广泛地使用“现代程序设计实践方法”就无法具有高的生产率）

　　很显然，不采用现代程序设计实践方法的项目不可能具有高的生产率。但技术基本原则的应用，就其本身而言，不足以创造高的生产率。一些项目使用了大量现代程序设计实践方法，但是仍旧和那些完全没有使用该方法的项目具有一样的生产率。因此，注意技术的基本原则是很必要的，但却不足以达到快速开发的目的（例如犯了某些典型错误）。

1. 需求管理

　　研究数据：

　　典型项目平均会经历25%的需求变化，从而至少产生25%的额外费用和时间。

　　一项针对8000多个项目的调查显示，导致项目推迟发布、超出预算、功能比预期减少的最重要的三个原因——缺乏用户的介入、不完善的需求分析和用户不断改变需求，都和需求管理有关。（Standish Group1994）

　　一项软件工程研究所的调查也有相同的结论：超过半数的项目都遭遇过不充分的需求管理的麻烦。（Kitson and Masters 1993）

　　需求管理就是收集需求，把需求记录成文档、电子邮件、用户界面串连脚本、可实现的原型等形式，然后依此来跟踪设计和编码，并随时管理、修改需求，以适应项目后续的过程。

　　成功的需求管理取决于了解足够的不同的实践经验，以便能够为特定项目选择可借鉴的一种。

　　需求管理的基础：

• 需求分析方法：包括结构分析、数据结构分析和面向对象分析
• 系统建模实践：如类图表、数据流图表、实体关系图表、数据字典符号和状态跃变图表
• 沟通实践：如联合应用开发、用户界面原型和常规会谈实践等
• 需求管理和其它生命周期类型的关系：如渐进原型、阶段交付、螺旋模型、瀑布模型和编码修正

　　需求管理在两个方面对开发速度发挥着巨大的调节作用：

　　首先，正规的需求管理中，需求收集往往比其他软件开发活动完成得要从容些。如果能加快需求步伐而不伤害质量，就可以缩短总的开发时间。

　　第二，正确地把需求摆在首位，往往要比被动地这样做所花的时间少得多。一些需求管理实践基本原则能够减少需求变化的数量，其他开发实践的基本原则能够减少因需求改变而产生的费用。

　　想象一下，如果把需求变化从25%减少到10%，同时把每个需求变化导致的费用减少5%-10%，那么综合的效果会怎样呢？

2. 设计

　　研究数据：

　　一个设计上的错误如果到系统测试时才被发现，那么花费的修补时间要比它在设计阶段时被发现所花费的时间多10倍。（Dunn 1984）

　　设计是系统构建、项目进度计划、项目跟踪和项目控制的基础。

　　体系结构和设计的基本原则：

• 主要设计风格：如面向对象设计、结构化设计和数据结构设计
• 基础设计概念：如信息隐藏、模块化、抽象、封装、聚合、耦合、层次、继承、多态、基本算法和基本数据结构
• 对典型挑战性事件的标准设计：包括异常处理、国际化、本地化、便携性、字串存储、输入输出、内存管理、数据存储、浮点算法、数据库设计、性能和复用
• 对特殊领域应用程序设计的独有思考：例如财务应用、科学应用、嵌入式系统、实时系统、安全性要求高的软件等
• 架构安排：如子系统组织、分层结构、子系统通信方式和典型的系统架构
• 设计工具的使用

3. 构建

　　当构建开始时，项目成功与否大多就已经注定了。需求管理和设计对开发进度计划的调节作用比构建的调节作用大得多，这意味着小的波动可以导致进度的重大变化。

　　尽管构建是一个低层次的活动，但是它确实可以提供许多机会进一步改进时间效率低的任务或优化一些任务。例如，花时间对那些无需镀金的功能进行镀金；调试那些无用的多余代码，或者对那些并不知道是否需要优化的片段尽心优化。

　　构建的基本原则：

• 编码实践：如变量和函数命名、版面布局和文档
• 数据相关概念：如作用范围、持续和捆绑时间
• 特定数据类型的使用方针：如通用基础数据类型、枚举、常量、数组和指针
• 控制相关的概念：如组织整齐的代码、条件的使用、循环的控制、复杂度的控制、特殊控制结构的使用（goto、return、递归）
• 断言和其它以代码为核心的错误检测方法
• 对例程、模块、类和文件代码打包的规则
• 单元测试和调试实践
• 集成策略：如增量式集成、大爆炸式集成和渐进开发
• 代码优化策略和实践
• 与所使用的特定编程语言相关的其他事情
• 使用构建工具：如编译环境、群组工作支持、源代码控制、代码库和代码生成器

4.软件配置管理

　　软件配置管理(SCM)是管理项目成果的一种实践方法，能使项目在全程中保持一致的状态。SCM包括评估变更、跟踪变更、处理多版本，以及在不同时间保存项目成果的备份等实践。

质量保证基本原则

　　很多公司现阶段开发软件都有一定的不当之处，使得他们的开发时间比需要的长。在调查了4000个软件项目后，Capers Jones递交报告说，糟糕的质量是进度被拖延的最普遍的原因之一。他还说，中途被取消的项目中，大约有一半是由于其糟糕的质量。（Jones 1994）

　　一项软件工程研究所的调查显示，大约有60%的公司遭受着不适当的质量保证体系的困扰。（Kitson and Masters 1993）。

　　在过大的时间压力下发布的产品，其错误率是正常情况下的4倍。有进度问题的项目经常是在进行艰苦的工作而不是轻松活跃的工作，关注质量被认为是有些奢侈。但其结果却是项目进展缓慢，并陷入更深的进度问题中。（Jones 1994）

　　重做有缺陷的需求、设计和编码通常花费整个软件开发成本的40%—50%。（Jones 1968b，Boehm 1987a）

　　最糟糕的情况下，在运行中的软件项目只修改一次软件需求问题的花费通常是在需求分析阶段所花时间的50到200倍。（Boehm and Papacio 1988）

　　大约60%的错误通常在设计阶段就存在了。（Gilb 1988）

　　如果可以尽早地预防并修正漏洞，可以节省大量时间，在进度的安排上占了先机。

图 4.3-1 错误率和开发时间的关系

（大多数情况下，具有低错误率的项目同时实现了最短日程的目标）

1. 易错模块

　　易错模块是那些容易存在或多或少漏洞的模块。

　　研究数据：

　　IBM的IMS项目中，57%的漏洞存在于7%的模块中。（Jones 1991）

　　程序中20%的模块包含了80%的错误。（Boehm 1987b）

　　高错误率的模块开发起来要比其它模块更加昂贵和耗时，如果普通模块开发每个功能点要花费$500—$1000，那么易错模块每个功能点就要花费$2000—$4000。（Jones 1994）

　　易错模块往往比系统中的其它模块更复杂，缺乏结构化，或者不同寻常的庞大，并且往往在背负压力下开发，往往没有被完全测试过。对软件开发特别重要的一个方面就是对易错模块的质量保证。

2. 测试

　　最寻常的质量保证实践就是毋庸置疑地进行测试，两种基本的测试方法：

• 单元测试：程序员检查他自己的代码是否工作正常
• 系统测试：独立测试员检查整个系统是否如期望的那样正常运行

　　研究数据：

　　测试的有效性差异是巨大的。单元测试可以找到程序中10%—50%的漏洞；系统测试可以发现20%—60%的程序漏洞。加在一起，累积的漏洞检测率经常少于60%。（Jones 1986a）

　　剩下的错误要么通过其它的查错技巧（如技术回顾）发现，要么就是在产品发布后被最终用户发现。

　　平衡测试和快速开发的最佳办法是在坏消息出现之前做好计划——设置对坏消息的测试，尽早地发现问题。

3. 技术回顾

　　技术回顾包括在需求、设计、编码和测试等事件中用于查错的所有类型的回顾。回顾在形式上和效果上是多样的，它在开发速度上比在测试上扮演更重要的角色。下面讲述最常见的几种回顾。

1) 走查

　　走查是指任何两个以上的开发人员以增进软件质量为目的所召开的回顾技术工作会议。走查可能是最平常的非正式回顾，走查可以在写设计说明书时，设计和编码完成之前就发现漏洞。

　　研究数据：

　　走查可以发现30%—70%的程序漏洞。（Myers 1979，Boehm 1987b，Yourdon 1989b）

2) 代码阅读

　　代码阅读时比走查更正式些的回顾方式，但仅适用于代码。代码阅读时，写这段代码的程序员把代码清单交给两个或更多的审阅者审阅，审阅者阅读代码，并把发现的错误报告给编写者。

　　研究数据：

　　NASA的软件工程实验室的一项研究发现：代码阅读能发现的漏洞是测试时能发现的漏洞的两倍。（Card 1987）

3) 检查

　　检查是一种正式的技术回顾，它被认为是在整个项目中最具效率的查错方式。使用检查的方法，开发人员需要接受检查的特殊训练，并且在检查中扮演重要的角色。在检查会议之前“仲裁人”发布产品要被检验评估的消息和检查列表，“审阅人”在会议前检查程序，在检查会议上“作者”通常要解释要检验的东西，“审阅人”鉴别错误，“书记员”记录错误。在会后“仲裁人”写一份报告说明每个漏洞和处理办法。

　　在项目中可以使用检查对需求分析、用户界面原型、设计、编码及其他认为的过程查错。

　　研究数据：

　　检查可以查出程序中60%—90%的漏洞，这点比走查或测试要好。因为可以在开发的早期应用，因此，检查方法被证明可以节约10%—30%的开发时间。（Gilb and Graham 1993）

　　一项对大型程序的调查结果显示，在检查上每花1小时，就可以避免在维护上33个小时的花费。检查比测试有效20倍以上。（Russel 1991）