前言
在60年代计算机发展初期，程序设计是少数聪明人干的事。他们的智力与技能超群，编写的程序既能控制弱智的计算机，又能让别人看不懂、不会用。那个时期编程就跟捏泥巴一样随心所欲，于是他们很过分地把程序的集合称为软件，以便自己开心或伤心时再把程序捏个面目全非。人们就在这种美滋滋的感觉下热情地编程，结果产生了一堆问题：程序质量低下，错误频出，进度延误，费用剧增……。这些问题导致了“
软件危机”。
在1968年，一群程序员、计算机科学家与工业界人士聚集一起共商对策。通过借鉴传统工业的成功做法，他们主张通过工程化的方法开发软件来解决软件危机，并冠以“软件工程”这一术语。三十年余年来，尽管软件的一些毛病如人类的感冒一样无法根治，但软件的发展速度超过了任何传统工业，期间并未出现真正的
软件危机。这的确是前人的先见之明。如今软件工程成了一门学科。
软件工程主要讲述软件开发的道理，基本上是软件实践者的成功经验和失败教训的总结。软件工程的观念、方法、策略和规范都是朴实无华的，平凡之人皆可领会，关键在于运用。我们不可以把
软件工程方法看成是诸葛亮的锦囊妙计─—在出了问题后才打开看看，而应该事先掌握，预料将要出现的问题，控制每个实践环节，并防患于未然。研究软件工程永远做不到理论家那么潇洒：定理证明了，就完事。
我在读大学的十年里有八年从事软件开发，尽管编写了几十万行C++/C程序，也经历了若干次小不点儿大的成功和失败，可老感觉只学了些皮毛，心里慌兮兮的。在博士研究生毕业前的半年里，我告戒自己不应该再稀里糊涂地在程序堆里滚爬下去了，于是就面壁反省，做了一阵子木讷的和尚。在“打坐”时，每有心得体会便记录下来，不知不觉凑成了八章经，我就给此经书起名为《软件工程思想》。
经典的软件工程书籍厚得象砖头，或让人望而却步，或让人看了心事重重。请宽恕我的幼稚，我试图用三个问题：是什么、为什么、怎么办，来解释软件工程的道理。所以本书薄得象饺子皮─—用来包“思想”这种有味道的“馅”。本书的八章经分别为：
第一章“软件工程基本观念”；
第二章“程序员与程序经理”；
第三章“项目计划与质量管理”；
第七章“测试与改错”；
附录“大学十年”可以充当饭后的水果。
我偶尔也担心此书写得太肤浅，内容少得可怜。就象一只鸡在水里扑腾了几下，并不能产生美味的鸡汤。但是如果您花了几分钟时间翻阅本书的任意章节，您马上就愿意再化几个小时一口气读完全书，并且乐得直拍桌子：“好！很好！非常好！”
您可以把这本
科技书当小说看，但在看书时请不要吃东西，免得喷了别人或者呛着自己。
如果您买了本书后觉得不值得，我一定赔偿您的损失。
目录
软件工程思想
目录
1序言、前言4
1.1序4
1.2前 言4
1.3致 谢5
2软件工程基本观念7
2.1软件工程的目标与常用模型7
2.2软件开发的基本策略9
2.2.1复用9
2.2.2分而治之10
2.2.3优化——折衷11
2.3一些不正确的观念12
2.4一些有争议的观念13
2.5小 结14
3程序员与程序经理15
3.1了解程序员15
3.2了解程序经理17
3.3程序员升为经理后是否还要编程18
3.4经理与技术队伍的建设18
3.5向错误与失败学习20
3.6提高综合素责21
3.7小结22
4项目计划与质量管理22
4.1项目计划23
4.1.1知己知彼23
4.2零缺陷质量管理的观念25
4.2.1高目标25
4.2.2可执行的规范26
4.3软件的质量因素26
4.3.1正确性与精确性27
4.3.2性能与效率28
4.3.3易用性28
4.3.4可理解性与简洁性28
4.3.5可复用性与可扩充性29
4.4质量检查29
4.5小结31
5可行性分析与需求分析31
5.1可行性分析的要素32
5.1.1经济32
5.1.2技术33
5.1.3社会环境34
5.1.4人35
5.2可行性分析案例35
5.2.1可行性分析案例之一36
5.2.2可行性分析案例之二38
5.2.3可行性分析案例之三42
5.3.1客户说不清楚需求44
5.3.2需求自身经常变动44
5.3.3分析人员或客户理解有误45
5.4如何进行需求分析46
5.4.1应该了解什么46
5.4.2通过什么方式去了解47
5.5小结47
6.1.1层次结构49
6.1.2客户机/服务器结构51
6.2.2内聚与耦合54
6.2.3封闭、开放性55
6.3数据结构与算法设计56
6.4用户界面设计57
6.4.2界面美的内涵58
6.5.1设计背景60
6.5.2Intra3D 2.061
6.5.3支持协同工作的网络通讯开发系统 CNC 1.064
6.5.4应用示例69
6.6小 结69
7.1.1类与对象72
7.1.2继承与组合73
7.2良好的编程风格81
7.2.2使用断言82
7.2.4使用const85
7.2.5其它建议87
7.3小结88
8测试与改错89
8.1对测试的理解89
8.1.1测试的目的90
8.1.2测试的心理要求90
8.1.3测试的真理90
8.1.4测试与质量的关系91
8.2测试人员的选择91
8.2.1Microsoft公司的经验教训91
8.2.2测试人员的分工92
8.3测试的主要内容与常用方法93
8.3.1正确性测试93
8.3.3性能与效率测试94
8.3.4易用性测试95
8.4改错95
8.5小结96
9.2维护的代价及其主要因素98
9.3.1重构100
9.3.2逆向工程100
9.4小 结100
第一章 软件工程基本观念
本章讲述软件工程的基本观念，是关于软件工程宏观上的探讨。如果你是软件公司的老
板，用不着在第一线工作，那么看这一章就够了。但你一定要让员工们相信不停地工作是人
生最大的快乐，并且让他们把本书看完。
1.1 节讲述软件工程的目标和常用的
软件工程模型。1.2 节讲述软件开发的基本策略：
“复用” 、 “分而治之” 、 “优化——折衷” ，有助于指导实践者选择方法和产生新方法。1.3
节例举一些不正确的观念，取材于早期软件人员比较幼稚的想法，初学者可以引以为戒。1.4
节探讨一些有争议的观念。
看完本章， 要树立这样的信念： 软件开发过程中的坎坎坷坷， 仿佛只是人脸的凹凸不平，
用热水毛巾一把就可抹平。让我们高举程序主义、软件工程思想的伟大旗帜，紧密团结在以
Microsoft 为核心的软件公司周围，沿着比尔·盖茨的生财之道，不分白天黑夜地编程，把
建设有中国特色的软件产业的伟大事业全面推向 21 世纪。
设计思想
（1） 瀑布模型（waterfall model）
瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将
软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是瀑布开发名称的由来。
瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。
（2） 快速原型模型（原型模式）prototype model
原型是指模拟某种产品的原始模型，在其他产业中经常使用。软件开发中的原型是软件的一个早期可运行的版本，它反映了最终系统的重要特性。
快速原型模型又称原型模型，它是增量模型的另一种形式；它是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。
内容简介
浙大林锐博士的《软件工程思想》一书中的全部8个篇章。这是林锐在自己经营公司不够成功后的深刻总结。《软件工程思想》讲述“
软件开发”和“做程序员”的道理，视野独特，构思新颖，内容风趣，不落窠臼，令人耳目一新。堪称难得，以至回味无穷。