hnxxcxg软件创建的先决条件.txt

f your application uses MFC in a shared DLL, and your application is in a language other than the

明确的需求也可以避免引起争议。在开始编程之前，系统的范围已经明确确定了。如果在

编程过程中，两个程序员对系统干什么有争议，那么只要查阅一下写好的需求分析，问题就解决了。

注意需求定义，也可以使得在开发工作开始之后，对系统作的改动最小、如果你在编码时
发现某几行有误，那么改掉这几行就是了。而如果在编码阶段发现需求有误，那么你很可能不
得不改变所有的代码以适应新的需求。

一些设计不得不被丢掉，是因为按它们要求写好的代码不具备兼容性。新设计可能要花费
很长的时间，被一同扔掉的还有受到要求变更影响的代码和测试用例，即使未受影响的代码部
分也不得不进行重新测试，以确认其他地方的变动没有引入新的错误。

IBM、GTE、TRW的数据表明．修正在总体结构阶段发现的需求错误，将比当时就发现并
修正的成本要高出5倍，如果是在编码阶段，要高出10倍，在单元或系统测试阶段，高20倍，
在验收测试阶段，高50倍，而在维护阶段，竟要比原来高出多达100倍！在较小规模的计划中，
在维护阶段修正错误的放大因子可能是20 而不是100，因为这时管理费用较低。但无论如何没
有人愿意从自己的收益中拿出这笔钱来。

充分进行需求分析是一个项目成功的关键，很可能比使用有效的创建技术还重要。

稳定的需求可以说是软件开发的法宝。有了稳定的需求，软件开发工作可能从结构设计到
详细设计到编码，都平稳、顺利的进行。这简直是造就了软件开发的天堂。你可以预测开支，
不必担心最终会冒出一个让你多花100倍钱的错误来。

用户一旦接受了写好的需求文件，便再也不会提出更改需求，这简直是太好了。然而事实
上，在实际项目中，用户在代码写出来之前，往往并不能确切可靠地描述出他想要的到底是什
么，这倒并不是说用户是一种低级生物。正如随着工作的进行，你对其理解越来越深刻一样，
用户对自己想要的东西，也是随着项目的进行而越来越清楚的，这也是要求变动的主要原因。
－个从不变更要求的计划，事实上是一个对用户的要求不予理睬的计划。

典型的变动有多少呢？根据IBM 的调查，对于一个典型的有一百万字的需求分析，大约
25%的内容在开发过程中要进行变动。

或许你认为卡迪拉克小汽车是空前绝后的，帝国大厦将万古永存，如果真是这样的话，那
你就相信你的项目要求永远不会更好了。如果不是这样，那么或许我们可以采取一些措施，使
得由于要求变更所造成的冲击最小。

如果你的需求分析不是很好，那么，停止继续工作，重新返回到需求分析阶段。当然，这
样会使人觉得你已经落后了。但是，如果你在开车从芝加哥到洛杉矶的途中，发现自己到了纽
约市郊，那么停下车来看一下地图是浪费时间吗？当然不是。因此，如果你发现方向不对，赶
紧停下来检查你的方向。

让每个人都知道由于变化需求所付出的代价

雇员们往往由于自己有了新的设计想法而激动不已。在这种兴奋驱使之下，他们往往会热
血沸腾，得意忘形。什么讨论要求的会议，什么签约仪式、什么要求文件，统统都会被他们扔
在一边。对付这种人最简单办法就是对他说：“喂，先生，你的想法不错，但是由于它不在要求
文件之中，我想先做一个变动后的进度和成本估计，然后我们再决定是立刻就采用这个想法还
是以后再说”。“时间进度”和“成本”这两个词往往比咖啡和泼冷水更管用，这样说，往往会
把许多“立刻采用”变成“最好采用”。

如果你的组织机构还没有认识到需求分析的重要性，那么就请引述本章前面“进行创建活
动前满足先决条件的安全和必要论据”一节的内容，告诉他们，在要求阶段变更设计是成本最
低的办法。

如果雇员们坚持更改的热情高涨，则可以考虑建立一个审查这种更改建议的正式委员会。
用户改变主意，意识到他们的软件需要更强的功能是非常正常的。但如果他们频繁地改变主意
以至于你无法跟上他们的速度，那就不正常了。这时如果拥有一套控制更改的正式过程，那将
使大家都会感到宽慰。你感到宽慰是因为现在你只在特定的时候处理变动问题。顾客也感到宽
慰是因为有专门机构处理他们的意见，会使他们感到自己倍受重视。

一些开发方法可以极大地扩展你应付变更需求的能力。原型化开发的方法可能帮助你在
全力以赴投入工作以前，首先了解系统的需求。渐进开发的方法是指按阶段公布系统。每次你
只做一点儿，从用户那里得到一些反馈后，你再做一些调整的改动，然后再增加一些内容。这
种方法的关键是使用短周期开发方法，以便你对顾客的需求变更迅速作出反应。

如果需求特别稀奇古怪或者反复无常，上面那些办法全都不起作用，那就放弃这个项目。
即使你并不能真正地砍掉这个项目，你也可以考虑一下这样做会怎么样。考虑在你砍掉这个项
目之前，事情会发展到什么地步。假如在某一情况下，的确可以把这个项目扔进垃圾箱，那么
还可以考虑一下有或没有这个项目会造成什么区别。

一个系统结构首先需要一个总体上的概括性描述。如果没有的话，从成千个细节与几十个
独立模块中勾画出一幅完整的图画将是一件十分困难的事情。如果这个程序仅仅是一个由十二
块积木组成的小房子，那么或许连你那两岁的儿子也会认为这很容易。然而，对于一个由十二
个模块组成的软件系统，事情恐怕就困难得多了。因为你很难把它们组合到一起，而如果不能
把它们组合到一起，你就不会理解自己所开发的这一个模块对系统有什么贡献。

在结构设计中，应该在程序中定义主要模块。在这里，“模块”并不是指子程序。在结构
设计中通常不考虑建立模块一级的子程序。一个模块是一个能完成某一高级功能的子程序的组
合，例如，对输出结果进行格式化，解释命令，从文件中读取数据等。在要求定义中列出的每
一项功能，都应该有至少一个模块覆盖这项功能。如果一项功能由两个或更多的模块覆盖，那
么它们之间应该是互补的而不是相互冲突。

每一个模块作什么应该明确定义。一个模块应该只完成一项任务而且圆满完成。对于与它
相作用的其它模块情况，你知道得越少越好。通过尽可能地降低模块之间的了解程度，就可能
把设计信息都集中在一个模块中。

每个模块之间的交界面也应该明确定义。结构设计应该规定可以直接调用哪些模块，哪些
模块它不能调用。同时，结构设计也应该定义模块传送和从其它模块接收的数据。

应该遵循数据守恒定律：每一个进入的数据都应该出去，或者与其它数据一道出去，
如果它不出去，那他就没有必要进来。

用户界面的精心结构设计，往往是一个深受欢迎的软件与被人弃之不用的软件间的主要不同之处。

这个结构应该是一个近乎完美的整体概念。关于软件工程的最权威的著作<<The Mythical
Man－Month>>，其中心思想便是认为概念完整性是最重要的（Brooks，1975）。一个好的结构
设计应满足这一条，当看到这个结构设计时，应该为其解决方案的自然和简单而折服。而不会
有把问题和答案生拼硬凑到一起的感觉。

你或许知道在开发过程中变动结构设计的途径。每一次变动都应与总体和设计概念相符。
不能使最终完成的结构设计看起来像是一个穿着由各种碎布拼凑起来的百家衣的乞丐。

结构中作出每一个决定的动机都要阐明清楚。要当心“我们过去一直是这么干的”的理由。
有这样一个故事，会给我们启迪。Beth 想按照她丈夫的家传方法做一道红烧牛肉。她的丈夫
Abdul 告诉她，要先把牛肉放在盐和调料中胞一下，再剁掉肉的两边，把中间部分放进锅里，
盖上盖儿焖一下就可以了。Beth 问：“为什么要剁掉肉的两边？”Abdul 说：“我不知道，我总
是这样做的，我们问一下妈妈吧”。便打电话问妈妈、Abdul的妈妈则说是他的外祖母告诉她的。
于是电话打到了Abdul的外祖母那儿，她的外祖母奇怪地说：“我也不知道你们为什么那样做，
我那样做不过是因为肉块太大，放不进锅里”。

结构设计应该恰好在过分定义和定义不足的分界线上。结构中不应该有任何部分受到了它
不应受的重视。设计者不能以牺牲某一部分为代价来重视另一部分。

最后，结构中不应该有任何部分让你感到不舒服。它不应该含有任何仅仅为取悦老板而加
上去的部分。你是最终实现它的人，如果你根本读不懂它，又谈何实现呢？

当程序员使用自己所熟悉的语言时，其工作效率要比使用陌生的语言高得多。TRW 公司的
数据表明，两个水平和经验相当的程序员如果一个用一种他已用了三年的语言编程，而另一个
则用一种他所陌生的语言编程，那么前者的效率要比后者高30％。IBM的调查表明，一个在某
种语言上经验丰富的程序员，其效率要比在这种语言上没什么经验的程序员高三倍（Walston
和 Felix 1977）。

使用高级语言编程，其效率和质量要比使用低级语言高得多。Pascal 和Ada 语言的效率、
可靠性、简单性和可懂性是低级语言，如汇编和机器语言的5 倍（Brooks 1987）。由于不必每
次都为机器正确地执行了指令而欢呼，你当然可以节省许多时间。同时，高级语言的表达能力
比低级语言要高，这样，它的每一行代码就可以表达更多的内容。

程序员也可能同样受到他所懂得的程序语言限制。在某种程序语言方面你所懂得的词汇，
当然会决定你如何表达你的编程想法，还很可能决定你将表达什么样的思想。

程序语言影响程序员的思想方法。一个典型的故事是这样说的：“我们正用Pascal语言开发
一个新的系统，而我们的程序员们却并不熟悉Pascal语言，他们都是搞Fortran语言出身的。结
果他们写出的是用Pascal 编译的代码，但是他们真正使用的却是变形的Fotran 语言。他们用
Fortran 的不好的特性（goto语句和全局数据）歪曲了Pascal语言，而同时又把Pascal丰富的控
制和数据结构弃之不用”。这种现象在整个软件业都有报道（Hanson 1984，Yourdon 1986）

在复杂的软件中，结构设计指导方针对程序进行结构性平衡，而实现指导方式则在较低层
次上实现程序的和谐统一，使得每一个子程序都成为总体设计的一个可以信赖的组成部分。任
何一个大的软件系统都需要结构控制，以便把编程语言的细节统一到一起。大型系统的完美之
处便是它的每一个细节都体现了它的结构设计风格。如果没有一个统一约束，那么你的软件只
能是一个由各种风格不同的子程序拼凑到一起的拼盘而已。

即使你有一个关于一幅画的美妙总体构思，但如果其中一部分是用古典手法的，另一部分
是印象派的，其余则是超现实主义风格的，那么，再美妙的构思又有什么用呢？不论其中每一
部分是如何密切联系主题的，这幅画的概念完整性都将荡然无存。同样，程序也需要较低层次
上的完整性。

在创建工作开始之前，一定要写明你将要采用的编程约定、约定说明一定要写得非常详尽，
使得在编程过程中无法对其进行改动。