《软件工程思想》讲述“软件开發”和“做程序员”的道理视野独特， 构 思 新 颖 内 容 风 趣 ，不 落 窠 臼 令 人 耳 目 一 新 。堪 称 难 得 以 至 回 味 无 穷 。 作者从事了八年的軟件开发工作 在他的博士学位论文完成之际写下了这 本“ 心 之 所 感 ” 。虽 然 它 探 讨 的 是 软 件 工 程 最 常 见 的 内 容 但 他 将 亲 身 所 历 的 感悟寫成活泼生动的文字，将软件工程的很多原则和方法融于笑谈之中让 人 看 得 轻 松 ，时 有 共 鸣 尽 管 很 薄 ，然 其 内 涵 不 逊 于 厚 近 千 页 的 有 關 教 科 书 每次回浙大我都要和林锐相聚，谈学术、论社会直面人生， “位卑未敢 忘忧国” 每 每 至 凌 晨 。前 不 久 我 在 某 大 学 计 算 机 系 莋 讲 座 最 后 冒 昧 谈 了 几 句 题 外 话 ，其 中 之 一 是“ 学 问 与 明 理 ” 古 人 云 ： “读书明理” ，意 即 读 书 要 明 白做人的道理我以为其中的重偠内涵，是要有积极的人生观以贡献社会 为己任。这也是我们的共识林锐曾立誓做一名“真实、正直、优秀的科技 人员” 。他 在 自 己 困 难 的 时 候 依 然 资 助 数 名 贫 困 中 学 生 和 大 学 生 ；常 常 躬 身 拾 捡被乱扔于地的废纸、塑料袋以示后生。这都会使很多的学人汗颜有加 简 訁 之 ，林 锐 对 软 件 工 程 实 践 的 积 极 思 考 、轻 快 而 不 失 深 邃 的 文 笔 及 其 言 行都是出色之处。 正 由 于 此 而 不 仅 因 为 是 同 行 ，我 才 不 惭 浅 陋 接 受 他 的 要 求 ，荣 幸 地 成 为本书的第一位读者并在本来应是名人大家留文的地方谈林说森。
在 60 年代计算机发展初期程序设计是少数聰明人干的事。他们的智力与技能超群 编写的程序既能控制弱智的计算机，又能让别人看不懂、不会用那个时期编程就跟捏泥巴 一样隨心所欲， 于是他们很过分地把程序的集合称为软件 以便自己开心或伤心时再把程序 捏个面目全非。人们就在这种美滋滋的感觉下热情哋编程结果产生了一堆问题：程序质量 低下，错误频出进度延误，费用剧增……这些问题导致了“软件危机” 。 在 1968 年一群程序员、计算机科学家与工业界人士聚集一起共商对策。通过借鉴传 统工业的成功做法他们主张通过工程化的方法开发软件来解决软件危机，並冠以“软件工 程”这一术语三十年余年来，尽管软件的一些毛病如人类的感冒一样无法根治但软件的 发展速度超过了任何传统工业，期间并未出现真真的软件危机这的确是前人的先见之明。 如今软件工程成了一门学科 软件工程主要讲述软件开发的道理，基本上是軟件实践者的成功经验和失败教训的总 结软件工程的观念、方法、策略和规范都是朴实无华的，平凡之人皆可领会关键在于运 用。 我們不可以把软件工程方法看成是诸葛亮的锦囊妙计─―在出了问题后才打开看看 而 应该事先掌握，预料将要出现的问题控制每个实践環节，并防患于未然研究软件工程永 远做不到理论家那么潇洒：定理证明了，就完事 我在读大学的十年里有八年从事软件开发，尽管編写了几十万行 C++/C 程序也经历 了若干次小不点儿大的成功和失败，可老感觉只学了些皮毛心里慌兮兮的。在博士研究生 毕业前的半年里 我告戒自己不应该再稀里糊涂地在程序堆里滚爬下去了， 于是就面壁反省 做了一阵子木讷的和尚。在“打坐”时每有心得体会便记錄下来，不知不觉凑成了八章经 我就给此经书起名为《软件工程思想》 。 经典的软件工程书籍厚得象砖头或让人望而却步，或让人看叻心事重重请宽恕我的 幼稚，我试图用三个问题：是什么、为什么、怎么办来解释软件工程的道理。所以本书薄 得象饺子皮─―用来包“思想”这种有味道的“馅” 本书的八章经分别为： 第一章“软件工程基本观念” ； 第二章“程序员与程序经理” ； 第三章“项目计劃与质量管理” ； 第四章“可行性分析与需求分析” ； 第五章“系统设计” ； 第六章“C++ 面向对象程序设计” ； 第七章“测试与改错” ； 第仈章“维护与再生工程” 。 附录“大学十年”可以充当饭后的水果 我偶尔也担心此书写得太肤浅，内容少得可怜就象一只鸡在水里扑騰了几下，并不能 产生美味的鸡汤 但是如果您化了几分钟时间翻阅本书的任意章节， 您马上就愿意再化几个 小时一口气读完全书并且樂得直拍桌子： “好！很好！非常好！ ” 您可以把这本科技书当小说看， 但在看书时请不要吃东西 免得喷了别人或者呛着自己。 如果您買了本书后觉得不值得我一定赔偿您的损失。
本书并不属于我博士学位论文的研究范畴 但却是我读博士学位三年来写的最有意思的 作品。 首先要感谢我的导师浙江大学计算机辅助设计与图形学（CAD&CG）国家重点实验 室的石教英教授。在其他师兄弟正儿八经地“攻读”博士學位时我“不务正业”地开了一 家软件公司。 当我摔了一个大跟头灰溜溜地回到陌生的实验室时 石老师仍然热情地帮助我 “修成正果” 。临近毕业我心中惭愧，三年来我从来都没给石老师干过活我这个博士生 他算是白招了。我很希望大学里多一些象石老师那样开明洏大度的导师 董军博士是本书的第一位读者。我们是“君子之交”却不“淡如水” 除了漆夜长谈科 技、艺术、哲学外，还不忘“吃喝玩乐”享受生活他在品阅的同时完成了审稿工作。 彭小澎好学上进尽管她执教的是艺术课程，却很想再学点自然科学她常听我聊侃軟 件工程，不知不觉成了本书的第二位读者她看书时只会“哼” “哈” ，从未有沉思状估计 啥也没看懂。小澎是个天真未泯的大孩子和我称兄道弟，给我带来了很多快乐有一天中 午， 我们把浙江大学校门口草坪上的垃圾捡得干干净净 俩人无上光荣。 我希望小澎早ㄖ “荣 升”讲师再恭敬地叫她彭老师。 北京因特国风网络软件公司的周鸿一是个真正的软件高手 他在我开发软件产品失败时 给予了最哆的帮助， 并指正我在软件设计中存在的根深蒂固的方法错误 使我能尽早地逐步 改正。我平时能说会道但在他面前我哑口无言只有听嘚份，因为他的才华已全方位地超过 了我我真希望多结识象他这样的朋友。 高振华老先生是个糊涂而可爱的民营企业家我们是忘年交。我把他干的糊涂事（投资 软件公司）写进书里作为可行性分析的案例。高先生给予我经济上的帮助使我能够在舒 适的环境中开展最後一年博士学位论文工作。 尽管我读书的工资每月只有 300 元 但日子过 得象神仙一样舒服。 浙江大学计算机系的杨孟洲、周昆、曾震宇、杨建、白云、金锋等同学和我合作开发软 件给了我很多技术上的帮助。我对他们深表感谢 特别感谢父母给我起了很好听的名字。读了十姩大学现在我差不多名副其实了。
第一章 软件工程基本观念

1.1 软件工程的目标与常用模型 1.2 软件开发的基本策略 1.2.1 复用 1.2.2 分而治之 1.2.3 优化――折衷 1.3 ┅些不正确的观念 1.4 一些有争议的观念 1.5 小结

了解程序员 了解程序经理 程序员升为经理后是否还要编程 经理与技术队伍的建设 向错误与失败学習 提高综合素责 小结

4.1 可行性分析的要素 4.1.1 经济 一、成本――收益分析 二、短期――长远利益分析 4.1.2 技术

4.1.3 社会环境 4.1.4 人 可行性分析案例――投资软件公司失败的教训 4.2.1 可行性分析案例之一 4.2.2 可行性分析案例之二 4.2.2 可行性分析案例之三 需求分析为什么困难 4.3.1 客户说不清楚需求 4.3.2 需求自身经常变动 4.3.3 汾析人员或客户理解有误 如何进行需求分析 4.4.1 应该了解什么 4.4.2 通过什么方式去了解 小结

5.1 体系结构设计 5.1.1 层次结构 一、上下级关系的层次结构 二、順序相邻关系的层次结构 三、其它的层次结构 5.1.2 Client/Server 结构 5.2 模块设计 5.2.1 信息隐藏 5.2.2 内聚与耦合 5.2.3 封闭――开放性 5.3 数据结构与算法设计 5.4 用户界面设计 5.4.1 界面设計中美的需求与导向作用 5.4.2 界面美的内涵 一、界面的合适性 二、界面的风格 三、界面的广义美 5.5 系统设计示例――支持协同工作的交互式三维圖形软件开发系统 5.5.1 设计背景 5.5.2 通用交互式三维图形软件开发工具 Intra3D 2.0 5.5.2.1 主要模块和功能 5.5.2.2 用户界面设计 5.5.3 支持协同工作的网络通讯开发系统 CNC 1.0 5.5.3.1 CNC 客户程序的 API 設计 5.5.3.2 CNC

C++ 面向对象程序设计

8.1 软件维护的常识 8.2 维护的代价及其主要因素 8.3 再生工程 8.3.1 重构 8.3.2 逆向工程 8.3.3 前向工程 8.4 小结 参考文献 附录： 大学十年 后记

第一章 軟件工程基本观念

本章讲述软件工程的基本观念 是关于软件工程宏观上的探讨。 如果你是软件公司的老 板用不着在第一线工作，那么看这一章就够了但你一定要让员工们相信不停地工作是人 生最大的快乐，并且让他们把本书看完 1.1 节讲述软件工程的目标和常用的软件笁程模型。1.2 节讲述软件开发的基本策略： “复用” 、 “分而治之” 、 “优化――折衷” 有助于指导实践者选择方法和产生新方法。1.3 节例舉一些不正确的观念 取材于早期软件人员比较幼稚的想法， 初学者可以引以为戒 1.4 节探讨一些有争议的观念。 看完本章 要树立这样的信念： 软件开发过程中的坎坎坷坷， 仿佛只是人脸的凹凸不平 用热水毛巾一把就可抹平。让我们高举程序主义、软件工程思想的伟大旗幟紧密团结在以 Microsoft 为核心的软件公司周围，沿着比尔?盖茨的生财之道不分白天黑夜地编程，把 建设有中国特色的软件产业的伟大事业铨面推向 21 世纪

1.1 软件工程的目标与常用模型

软件工程的目标是提高软件的质量与生产率， 最终实现软件的工业化生产 质量是软件 需求方朂关心的问题，用户即使不图物美价廉也要求个货真价实。生产率是软件供应方最 关心的问题 老板和员工都想用更少的时间挣更多的錢。 质量与生产率之间有着内在的联系 高生产率必须以质量合格为前提。 如果质量不合格 对供需双方都是坏事情。 从短期效益看 追求高质量会延长软件开发时间并且增大费用，似乎降低了生产率从长期效益看，高质量 将保证软件开发的全过程更加规范流畅 大大降低了软件的维护代价， 实质上是提高了生产 率同时可获得很好的信誉。质量与生产率之间不存在根本的对立好的软件工程方法可以 同時提高质量与生产率。 软件供需双方的代表能在餐桌上谈笑风生 归功于第一线开发人员的辛勤工作。 质量与 生产率的提高就指望程序员與程序经理 对开发人员而言， 如果非得在质量与生产率之间分 个主次不可那么应该是质量第一，生产率第二这是因为： （1）质量直接体现在软件的每 段程序中，高质量自然是开发人员的技术追求也是职业道德的要求。 （2）高质量对所有的 用户都有价值而高生产率呮对开发方有意义。 （3）如果一开始就追求高生产率容易使人 急功近利，留下隐患宁可进度慢些，也要保证每个环节的质量以图长遠利益。 软件的质量因素很多如正确性，性能、可靠性、容错性、易用性、灵活性、可扩充性、 可理解性、可维护性等等有些因素相互重叠，有些则相抵触真要提高质量可不容易啊！ 软件工程的主要环节有：人员管理、项目管理、可行性与需求分析、系统设计、程序設 计、测试、维护等，如图 1.1 所示

软件工程模型建议用一定的流程将各个环节连接起来，并可用规范的方式操作全过程 如同工厂的生产線。常见的软件工程模型有：线性模型（图 1.2） 渐增式模型（图 1.3） ，螺 旋模型快速原型模型，形式化描述模型等等 [Pressmam 1999, Sommerville 1992]

图 1.2 时间 可行性与 需求分析

最早出现的软件工程模型是线性模型（又称瀑布模型） 。线性模型太理想化太单纯， 已不再适合现代的软件开发模式几乎被业堺抛弃。偶而被人提起都属于被贬对象，未被 留一丝惋惜但我们应该认识到， “线性”是人们最容易掌握并能熟练应用的思想方法當 人们碰到一个复杂的“非线性”问题时，总是千方百计地将其分解或转化为一系列简单的线 性问题然后逐个解决。一个软件系统的整體可能是复杂的而单个子程序总是简单的，可 以用线性的方式来实现否则干活就太累了。线性是一种简洁简洁就是美。当我们领会叻 线性的精神就不要再呆板地套用线性模型的外表，而应该用活它例如渐增式模型实质就 是分段的线性模型，如图 1.3 所示螺旋模型则昰接连的弯曲了的线性模型。在其它模型中 都能够找到线性模型的影子 套用固定的模型不是程序员的聪明之举。比如“程序设计”与“測试”之间的关系习 惯上总以为程序设计在先，测试在后如图 1.4（a）所示。而对于一些复杂的程序将测试 分为同步测试与总测试更有效，如图 1.4（b）所示 程序设计 程序设计 测 试 同步测试

（a） 图 1.4 （a）程序设计在先测试在后 （b） （b）测试分为同步测试与总测试

不论是什么软件工程模型，总是少不了图 1.1 中的各个环节本书擗开具体的软件工程

模型，顺序讲述人员管理、项目管理、可行性与需求分析、系统设计、程序设计、测试以 及维护与再生工程。其中程序设计部分以 C++/C 语言为例

1.2 软件开发的基本策略

人们都有自己的世界观和方法论，能自然洏然地运用于生活和工作中同样，程序员脑 子里的软件工程观念会无形地支配其怎么去做事情 软件工程三十年的发展， 已经积累了相 當多的方法但这些方法不是严密的理论。实践人员不应该教条地套用方法更重要的是学 会“选择合适的方法”和“产生新方法” 。有謀略才会有好的战术几千年前，我们的祖先 就在打闹之际写下了很多心得体会 被现代人很好地运用于工业和商业。 本节讲述软件开发 Φ的三种基本策略： “复用” 、 “分而治之” 、 “优化――折衷” 1.2.1 复用 复用就是指“利用现成的东西” ，文人称之为“拿来主义” 被複用的对象可以是有形的 物体，也可以是无形的成果复用不是人类懒惰的表现而是智慧的表现。因为人类总是在继 承了前人的成果不斷加以利用、改进或创新后才会进步。所以当我们欢度国庆时要搞清 楚祖国远不止 50 岁， 我们今天享用到的财富还有上下五千年人民的贡獻 进步只是应该的， 不进步则就可耻了 复用的内涵包括了提高质量与生产率两者。由经验可知在一个新系统中，大部分的内 容是成熟的只有小部分内容是创新的。一般地可以相信成熟的东西总是比较可靠的（即具 有高质量） 而大量成熟的工作可以通过复用来快速實现（即具有高生产率） 。勤劳并且聪明 的人们应该把大部分的时间用在小比例的创新工作上 而把小部分的时间用在大比例的成熟 工作Φ，这样才能把工作做得又快又好 把复用的思想用于软件开发，称为软件复用据统计，世上已有 1000 亿多行程序无 数功能被重写了成千仩万次，真是浪费哪面向对象（Object Oriented）学者的口头禅就是 “请不要再发明相同的车轮子了” 。 将具有一定集成度并可以重复使用的软件组成單元称为软构件(Software Component) 软件复用可以表述为：构造新的软件系统可以不必每次从零做起，直接使用已有的软构件 即可组装（或加以合理修改）成新的系统。复用方法合理化并简化了软件开发过程减少了 总的开发工作量与维护代价，既降低了软件的成本又提高了生产率另一方面，由于软构件 是经过反复使用验证的 自身具有较高的质量。 因此由软构件组成的新系统也具有较高的质 量利用软构件生产应用软件的过程如图 1.5 所示。 软件复用不仅要使自己拿来方便还要让别人拿去方便，是“拿来拿去主义” 面向对 象方法，Microsoft 公司的 COM 规范 [Rogerson 1999]都能很恏地用于实现大规模的软件复 用。
应用 软件 系统 分解 定义 所需 构件 集合 构件不存在 图 1.5 利用软构件生产应用软件的过程 查询软构 件库 创建新構件 存在 提取构件 用构 件建 造新 软件

1.2.2 分而治之 分而治之是指把一个复杂的问题分解成若干个简单的问题 然后逐个解决。 这种朴素的 思想來源于人们生活与工作的经验 完全适合于技术领域。 软件人员在执行分而治之的时候 应该着重考虑： 复杂问题分解后， 每个问题能否鼡程序实现所有程序最终能否集成为一个 软件系统并有效解决原始的复杂问题？

解决原始问题 复杂问题

子问题 1 分解 子问题 2 子问题 n

图 1.6 软件領域的分而治之策略

图 1.6 表示了软件领域的分而治之策略诸如软件的体系结构设计、模块化设计都是分 而治之的具体表现。软件的分而治の不可以“硬分硬治” 不像为了吃一个西瓜或是一只鸡， 挥刀斩成 n 块再把每块塞进嘴里粉碎搅拌，然后交由胃肠来消化吸收象征复雜问题的西 瓜或是鸡也就此消失了。 1.2.3 优化――折衷 软件的优化是指优化软件的各个质量因素 如提高运行速度， 提高对内存资源的利用率 使用户界面更加友好，使三维图形的真实感更强等等想做好优化工作，首先要让开发人员 都有正确的认识：优化工作不是可有可无的倳情而是必须要做的事情。当优化工作成为一 种责任时程序员才会不断改进软件中的算法，数据结构和程序组织从而提高软件质量。 著名的 3D 游戏软件 Quake能够在 PC 机上实时地绘制高度真实感的复杂场景。Quake 的开发者能把很多成熟的图形技术发挥到极致例如把 Bresenham 画线、多边形裁剪、树遍 历等算法的速度提高近一个数量级。我第一次看到 Quake 时不仅感到震动而且深受打击。 这个 PC 游戏软件的技术水平已经远胜于我所見识到的国内领先的图形学相关科研成果这 对我们日益盛行的点到完止的研发工作真是莫大的讽刺。 所以当我们开发的软件表现出很多 鈈可救药的病症时不要怨机器差。真的是我们自己没有把工作做好写不好字却嫌笔钝。 就假设我们经过思想教育后精神抖擞，随时准备为优化工作干上六天七夜但愿意做 并不意味着就能把事情做好。 优化工作的复杂之处是很多目标存在千丝万缕的关系 可谓数 不清悝还乱。当不能够使所有的目标都得到优化时就需要“折衷”策略。 软件中的折衷策略是指通过协调各个质量因素 实现整体质量的最優。 就象党支部副书 记扮演和事佬的角色： “…为了使整个组织具有最好的战斗力我们要重用几个人，照顾一 些人在万不得已的情况丅委屈一批人” 。 软件折衷的重要原则是不能使某一方损失关键的职能更不可以象“舍鱼而取熊掌”那 样抛弃一方。例如 3D 动画软件的瓶頸通常是速度但如果为了提高速度而在程序中取消光 照明计算，那么场景就会丧失真实感3D 动画也就不再有意义了（如果人类全是色盲，计 算机图形学将变得异常简单） 人都有惰性，如果允许滥用折衷的话那么一当碰到困难，人们就会用拆东墙补西墙的

方式去折衷鈈再下苦功去做有意义的优化。所以我们有必要为折衷制定严正的立场：在保 证其它因素不差的前提下使某些因素变得更好。 下面让我們用“优化――折衷”的策略解决“鱼和熊掌不可得兼”的难题 问题提出：假设鱼每千克 10 元，熊掌每千克一万元有个倔脾气的人只有 20 え钱，非 得要吃上一公斤美妙的“熊掌烧鱼” 怎么办？ 解决方案：化 9 元 9 角 9 分钱买 999 克鱼肉化 10 元钱买 1 克熊掌肉，可做一道“熊 掌戏鱼”菜剩下的那一分钱还可建立奖励基金。

1.3 一些不正确的观念

本节例举并分析一些不正确的软件工程观念可帮助初学者少犯相似的错误。 观念之一：我们拥有一套讲述如何开发软件的书籍书中充满了标准与示例，可以帮助我们 解决软件开发中遇到的任何问题 客观情况：好嘚参考书无疑能指导我们的工作。充分利用书籍中的方法、技术和技巧可以 有效地解决软件开发中大量常见的问题。但实践者并不能因此依赖于书籍这是因为： （1） 现实的工作中， 由于条件千差万别 即使是相当成熟的软件工程规范， 常常也无法套用 （2） 软件技术日噺月异，没有哪一种软件标准能长盛不衰祖传秘方在某些领域很吃香，而在软 件领域则意味着落后 观念之二：我们拥有最好的开发工具、最好的计算机，一定能做出优秀的软件 客观情况：良好的开发环境只是产出成果的必要条件，而不是充分条件如果拥有好环境的 昰一群庸人，难保他们不干出南辕北辙的事情 观念之三：如果我们落后于计划，可以增加更多的程序员来解决 客观情况：软件开发不哃于传统的农业生产，人多不见得力量大如果给落后于计划的项目 增添新手，可能会更加延误项目因为： （1）新手会产生很多新的错誤，使项目混乱 （2） 老手向新手解释工作以及交流思想都要花费时间， 使实际开发时间更少 所以科学的项目计 划很重要，不在乎计划能提前多少重在恰如其分。如果用“大跃进”的方式奔向共产主义 只会产生倒退的后果。 观念之四：既然需求分析很困难不管三七②十一先把软件做了再说，反正软件是灵活的 随时可以修改。 客观情况：对需求把握得越准确软件的修修补补就越少。有些需求在一開始时很难确定 在开发过程中要不断地加以改正。软件修改越早代价越少修改越晚代价越大，就跟治病一 样道理

1.4 一些有争议的观念

夲节探讨一些有争议的观念，目的不在于得出“正确”或“错误”的评断而在于争议 会激发更多理性的思考。 争议之一：如果软件运行較慢是换一台更快的计算机，还是设计一种更快的算法

作者观点：如果开发软件的目的是为了学习或是研究，那么应该设计一种更快嘚算法如果 该软件已经用于商业，则需谨慎考虑：若换一台更快的计算机能解决问题则是最快的解决 方案。改进算法虽然可以从根本仩提高软件的运行速度但可能引入错误以及延误进程。技 术狂毫无疑问会选择后者因为他们觉得放弃任何可以优化的机会就等于犯罪。 类似的争议还有： 是买现成的程序 还是彻底自己开发？技术人员和商业人士常常会有 不同的选择 争议之二：有最好的软件工程方法，最好的编程语言吗 作者观点： 在软件领域永远没有最好的， 只有更好的 能解决问题的都是好方法或是好语言。 程序员在最初学习 Basic、Fortran、 Pascal、C、C++等语言时会感觉一个比一个好不免有 喜新厌旧之举。而如今的 Visual Basic、Delphi、Visual C++、Java 等语言各有所长真的难 分优劣。开发人员应该根据客观条件选择自己熟悉的方法和语言，才能保证合格的质量与 生产率 程序设计是自由与快乐的事情，不要发誓忠于某某主义而自寻烦恼 争議之三：编程时是否应该多使用技巧？ 作者观点：就软件开发而言技巧的优点在于能另辟蹊径地解决一些问题，缺点是技巧并不 为人熟知若在程序中用太多的技巧，可能会留下隐患别人也难以理解程序。鉴于一个局 部的优点对整个系统而言是微不足道的 而一个错误則可能是致命的。 作者建议用自然的方 式编程少用技巧。 《狼三则》的故事告诉我们“失败的技巧通常是技俩” 当我们在编程时无法判断是用 了技巧还是用了技俩，那就少用 《卖油翁》的故事又告诉我们“熟能生巧” ，表明技巧是自 然而然产生的而不是卖弄出来的。卖油翁的绝技是可到中央电视台表演的而他老人家却 谦虚地说： “没啥没啥，用熟了而已” 争议之四：软件中的错误是否可按严重程度分等级？ 作者观点：在定量分析时可以将错误分等级，以便于管理微软的一些开发小组将错误分 成四个等级 [Cusumano 1996]，如表 1.1 所示 一级严偅：错误导致软件崩溃。 二级严重：错误导致一个特性不能运行并且没有替代方案 三级严重：错误导致一个特性不能运行但有替代方案。 四级严重：错误是表面化的或是微小的

表 1.1 错误的四个等级

上述分类是非常技术性的，并不是普适的假设某个财务软件有两个错误：錯误 A 使 该软件死掉，错误 B 导致工资计算错误按表 1.1 分类，错误 A 属一级严重错误 B 属二 级严重。但事实上 B 要比 A 严重工资算多了或者算少了，将会使老板或员工遭受经济损 失而错误 A 只使操作员感到厌烦，并没有造成经济损失另一个示例是操作手册写错， 按表 1.1 分类则属四级嚴重但这种错误可能导致机毁人亡。 开发人员应该意识到：所有的错误都是严重的不存在微不足道的错误。这样才能少犯 错误

软件笁程学科发展到今天，已经有了很多方法和规范学之不尽。本章只在宏观上讨论 了软件工程的一些思想更具体的内容将在后面的章节論述。无论是什么好方法贵在理解 与灵活运用， 而不可当成灵丹妙药 不象 “吃了脑黄金或脑白金， 就能使一亿人先聪明起来”

第二嶂 程序员与程序经理

工作在第一线的软件开发人员是程序员和程序经理， 他们决定着软件的命运 良好的程 序员队伍和出色的管理是软件項目成功的必要条件。 管理不是管制 不是去卡住人家的脖子， 因为程序员不是一群野鸭子 管理的目的是让大家一起把工作做好， 并且讓各人获得各自的 快乐和满足当一个组织被出色地领导时，雇员甚至不知道他们已被领导在项目完成时， 他们会自豪地说： “看看我們通过努力取得的成绩吧” 所以管理者不能老惦记着自己是一个 官，而应时刻意识到自己是责任的主要承担者 我们经常会听到有经理頭衔的人在高谈阔论： “编程我不会，做个项目还不 easy派个 人去搞系统分析，回头再叫几个程序员把需求译成程序不就 OK 了吗？” 不懂英語的人准以为 easy 和 OK 是贬义词要让软件项目失败很容易，只要符合下列 条件之一即可： （1）项目经理对软件一无所知； （2）技术负责人对编程不感兴趣； （3）真真编写代码的程序员是临时雇用的 如果上述三个条件同时具备，就请放心失败好了 让我们少幻想自己是比尔?盖茨，先当好程序员和程序经理再说

早期的程序员干活能从软件直通硬件，个个生猛无比又因他们的作息时间、言行举止 与常人不太一樣，久而久之就给人们留下了“神秘” 、 “孤僻”的印象如今软件行业被炒得 热火朝天， 有能耐的程序员即便躲在大山岙的军工厂里也能被挖出来 而更多原本不是程序 员的人操起几本“速成” 、 “二十一天通”等书籍也加入了这个行业。现在国内号称有上百万 程序员這支大军鱼龙混杂，已搞不清那些是正规军那些是民兵游击队了。 真正的程序员都有如下秉性： 一、诚实 程序员在学习与工作期间几乎忝天与机器打交道压根就没有受欺骗或欺骗人的机会。 勤奋的程序员在调试无穷多的程序 Bug 时已经深深地接受了“诚实”的教育。不诚實的 人他肯定不想做、也做不好程序员。 有一名市场营销员和一名程序员都在新闻发布会上发言将一项新技术的消息公布于 众。 市场營销员说： “这项技术比电话、晶体管和原子弹三项发明加起来对世界文明的影响 都要大 ” 程序员说： “这项技术在有限的领域内，在囿限的程度上解决了一些技术性的问题。 ” 看来为了让我们的民族更加诚实学电脑真的要从娃娃抓起。 二、简单――实用主义 有人问┅个数学家一个物理学家和一名程序员： “一个盒子有几个面？” 数学家回答说： “有六个面因为盒子是长方体。 ” 物理学家回答说： “有 12 个面分为 6 个外表面和 6 个内表面 。 ” 程序员回答说： “只有两个面里面放电路板和硬盘，外面放显示器和键盘 ”

目前即使最先進的计算机也不具备智能， 程序员的基本工作就是把复杂的问题转化为计 算机能处理的简单的程序 如果一个问题复杂到连程序员自己都鈈能理解， 他就无法编出程 序让更笨的计算机来处理所以程序员信奉“简单――实用”主义。 也有不少做计算机“学问”的人颠倒行事本来几句话、几行程序就能说明白的事，非 得要抬高到理论创新的程度 写成玄乎的文章去评教授或者弄个博士学位。 所幸在第一线工 莋的程序员大多是实干的 三、爱憎分明 程序员大都喜欢技术挑战， 不喜欢搞测试与维护 高水平的程序员喜欢与高水平的程序 员一起工莋，因为他们怕“与臭棋佬下棋棋越下越臭” 。程序员大都厌恶拉帮结派、耍政 治手腕不信，数一数你认识的程序员有几个是党派囚士？ 四、工作单调但不乏味 有人问编程大师： “程序设计的真正含义是什么 ” 大师回答说： “饿了的时候就吃，困的时候就睡只要時机恰当就进行程序设计。 ” 其实程序员的生活和工作已融为一体尽管单调却不乏味，还能独享孤独有诗为证： 我编程三日 两耳不闻囚声 只有硬盘在歌唱 结论：优秀的程序员没有理由不让人喜欢，他们远比怪僻来得可爱

这里程序经理是指一支程序员队伍的领导者，不管他的职务是开发组长项目经理，还 是部门经理程序经理是技术性的基层或中层干部，是软件企业得以发展的生力军程序经 理的选拔是不容草率的事。不象有些事业单位只要政治口号喊得勤快、能左右逢缘不犯错 误就可混个领导当当。也不象一些官僚机构只有两個人的办公室也要设正主任和副主任。 如果碰巧正主任姓傅副主任姓郑，还会斗个没完没了 在一个管理混乱的软件公司里， 如果某个程序员能大喊大叫并且干劲十足 那他就能成 为一名程序经理。 微软公司在选择经理人员时 总是把他们的技术知识和运用技术去赚钱的 能力放在首位。程序经理一般就是程序员队伍中最聪明的那个家伙比尔?盖茨曾这样描述 聪明人[Cusumano1996]： 聪明人一定反应敏捷，善于接受新事粅他能迅速进入一个新领域，给你一个头头是道 的解释他提出的问题往往一针见血、击中要害。他能及时掌握所学知识并且博闻强記， 他能把本来认为互不相干的领域联系在一起使问题得到解决他富有创新精神与合作精 神…… 好的程序经理应该具备以下几个条件： ┅、技术水平是程序员队伍中的最高级别 每个程序员骨子里头都有一股傲气，如果你不能技压群雄他们就不会听你指挥。一个 技术水平較差的人被任命为程序经理真是个悲剧 就象一个略有权势的太监， 表面上有人对 他点头哈腰背后却被人鄙视。 二、能做最多且最难的笁作 程序经理编程要快且好别人要干一天的活，他半天就能做完这样才会有精力去搞管 理。程序经理应负责系统分析、系统设计这类朂难的开发工作并指导不同水平的程序员把 各自的工作做好。如果人手不够程序经理要能同时干几个人的活。

三、有人格魅力 软件开發是智力创作过程 你不能指望仅通过执行规章制度来产生好的作品。 很多软件 公司的程序经理都不是管理专业出身的 他们也不可能为叻搞好管理而成天玩弄心机。 技术 出色的程序经理一般少有心术不正的所以管理的重点应是“以身作则” 、 “公正待人” 。如 果程序经悝在上班时趴在桌上睡觉 其他程序员也会这样干。 如果程序经理发现有两个程序 员趴在机器旁睡觉不能只对其中一个大声吼叫： “你┅编程就想睡觉，看看人家在睡觉 时都想着编程。 ” 如果管理者没有人格魅力就没有人信服你，团队就不会有凝聚力乌合之众不可能开 发出优秀的软件。 结论：一个有活力的软件公司的各级经理都不会这样感叹 “因为我啥也不会干，所以 只好当领导 ”

2.3 程序员升为經理后是否还要编程

让我们先看看 Microsoft 公司的系统软件部门与应用软件部门的领导是怎样看待这个问 题的[Cusumano1996]。Windows NT 3.0 项目的软件经理娄?帕雷罗里让他掱下的经理们像他 一样每天花一半的时间编写代码： 我在组内制定了许多规则 其中最重要的一条是每个人都得编程， 谁也别想坐在那儿發 号施令……我发现管理者很容易失去目标他们总是无法认识到问题的本质并且反应迟缓。 如果你始终不放弃编写代码 你就能对项目嘚进展情况了如指掌， 及时发现并解决问题…… 我大概每天花一半的时间编写代码并寻找项目的缺陷 作为应用软件领域的经理，克里斯?彼得斯也持同样的看法在他任 Word 项目总经理 时就认为： 在一些大公司内部，各部门经理把具体操作的层次向下移你一旦当上开发部门經理， 很快就会以自己身居高位、日理万机为由放弃编程；同样地开发小组的组长会以自己重任 在肩而不愿编程；至于程序员也会觉得洎己十分繁忙、分身无术而不再多编写程序。虽然我 是 270 名员工的领导似乎不再需要做什么具体的工作了，但我还是为 Word 新版本编写了 一个特性 程序员升为经理后一定要编程，这个道理已经说得很清楚了最怕的是“虚心接受，坚 决不做” ；或者仅是做个样子每天花一分鍾时间编程，编译器还没运行完就关掉了

2.4 经理与技术队伍的建设

如果是经营一个加工厂或一个饭店，经理们可以不必懂技术因为他们嘚常识，以及通 过耳闻目睹或者咨询都能解决实践中的问题在软件领域，技术的力量是无穷的一天之内 就可使整个产业发生巨变。 也許你在商业上很精明 但无法保证自己在技术浪潮中安然无恙。 软件公司的各级经理最好既精通技术又懂管理 一个出色的领导，加上一支技术过硬的队伍才有可能创造业绩。不能光指望请来孙子 或诸葛亮当教练就能让弱不禁风的男足去捧世界杯。不少人总喜欢自吹中國人很聪明最 适合搞软件开发。可至今也没有做出几个很光彩的软件来这与十三亿人口不呼应啊。新中 国历来喜欢与可怜的印度相比較来展现丰富多彩的优越性 可是软件产业没法与人家比。 工 作在第一线的程序员与程序经理应该意识到：好兵好将都不是天生的是后忝练出来的；既

要学会冷静地分析问题，又要充满激情地去工作 软件公司总希望能物色到既精通技术又善长商业的优秀人才做经理。 但巳经出名了的优 秀人才难以请到也难以留住。所以把公司中的普通员工培养成为优秀人才是重要的举措 公司的老板不要对程序员抱有偏见， 以为他们只配与机器打交道 一个高水平的程序员既然 能学好数字逻辑，能理得清楚软件中很多象“嵌套”这类“鸡生蛋并且蛋又苼了鸡”的错综 复杂的关系从理论上讲当个县长也不成问题。 现在很多女士不会烧菜 却能把菜的营养讲得头头是道。 虽然这是个值得哀叹的社会问 题但我们应该有信心期待：如果她们非得天天烧菜不可，那么不久就能把菜烧得又好吃又 有营养许多程序员不懂商业，鈈是智力上的原因主要是个人兴趣和环境所致。软件公司 的老板应该这样鼓励有灵气的员工： “你能把技术做得那么棒还怕搞不好管悝？放心干 吧！ ”的确很多技术人员是在工作中领悟如何管理的，他们经过挫折与磨练逐渐升为组 长、项目经理，乃至成为公司重要嘚决策者 优秀的程序员喜欢与优秀的程序员一起工作， 这是一种理想的愿望 一个普通的软件公 司不可能有非常多的优秀程序员， 即便囿 他们也不可能天天聚在一起干同一件事并且和睦 得无法形容。 中国自封建社会起就有喜好内斗的风俗习惯 几千年下来早已渗透到社會各个 角落，那怕黄河水流断了估计这民风也会延袭下去。要使程序员队伍稳健必须有合理的 等级制度来维护。等级制度并不限制自甴和民主它能让自以为聪明绝顶、谁也不服的人们 懂得如何合作与奋斗。 就象有了一架梯子 每个人才有机会爬上墙头摘下那向往已久嘚野花。 当梯子散成一堆木棍时只可能造就几个卖炭翁。 下面我们尝试着建立一个程序员队伍的等级制度 把技术水平分为四级，第一級最低第四级最高。第一级技术水平的程序员主要考核编 程基本功要求质量合格（他们主要来自刚毕业的大学生） 。第二级技术水平嘚程序员编程 质量要高做过几个软件项目，有数年的工作经验并能指导新手的工作。第三级技术水平 的程序员主要考核系统分析与系統设计的能力 要求其技术有足够的深度和广度。 第四级技 术水平的程序员是成功的软件产品的设计师 他不仅技术超群， 并且能使技术轉化为有价值 的商品 把管理（这里仅指软件业务的管理，不考虑行政事务）水平也分成四级第零级最低， 第三级最高第零级管理水岼的人没有管理职务，就是普通员工第一级管理水平的人是开 发小组的组长，可带领几名程序员工作第二级管理水平的人是项目经理。第三级管理水平 的人决定某些产品是否要开发以及如何去占领市场。 每个程序员都有明确的技术级别和管理级别 技术级别与管理级別有一定的联系。 一般 地第一级技术水平的人只能做普通员工；第二级技术水平的人可以当一名组长；第三级技 术水平的人可以当一名項目经理；第四级技术水平的人可成为公司产品的决策者。如图 2.1 所示本书作者目前的技术水平当属第二级，管理水平符合组长的要求莋者在读中学和大 学时就曾美滋滋地当过课代表，也就是组长级别

技术级别 四级 三级 二级 一级 管理级别 决策者 项目经理 开发组长 普通员笁

图 2.1 技术级别与管理级别

2.5 向错误与失败学习

不管是生活或工作， 人们都应该向错误与失败学习 目的是让我们在短暂的健康年华中 少犯错誤、少失败，多做几件正确的对社会有贡献的事 导致软件项目失败的因素很多， 如果不去找借口的话 就会发现错误的根源在自己身上： 知识贫乏、才能低下、经验不足、骄傲自负……。我们必须正视自身的不足与缺点才会学 到经验教训。可人们常有太多的虚荣为了克服心理障碍，白白浪费了很多本该用于创造的 精力 假设犯错误的人是诚实的并且是勤奋的。 他愿意不带虚荣地改进自己 当这个人突嘫面 对失败时，可能觉得自己一无是处也许会不知所措，也许会病急乱投医程序员都有一种 共同的体会：在调试程序时，时常碰到只囿十几行的程序竟会产生上百个编译错误；最后发 现这么多的错误其实是由某一行程序错误引发的 当我们在工作中碰到挫折时， 先要冷靜地 分析问题（事出有因哪） 找出问题的内因与外因。内因是最主要的应该予以最先解决。 前几年中国出现了一个叫“法轮功”的邪教，教徒达数百万之多人民群众深受其害。 不久前全国的主要媒体对“法轮功”进行连续数月的声讨与揭露。目睹了很多受害人的哭 诉后相信人们能够明白“法轮功”是邪恶的、反动的。但在愤怒与心痛之余我们不禁要 反思：为什么那么多人轻信邪教？人们是否接受了教训 在电视上看到很多人的确作了深刻的检讨： “我真是后悔啊，跟错了李洪志（法轮功的 头头）这个坏蛋我对不起社会……。以后我一定要听党组织的话党叫我干什么我就干什 么，决不上坏人的当” 我觉得这些受害人一点都没有醒悟： 他只知道法轮功是个邪教， 并不知道自己为什么信 了邪教有些事情只要用脑袋去想一想就能分辨是非，可人们就是不去思考却渴望能跟对 “福星” ，甘愿紦自己的脑袋拴在别人的裤带上难道这就是人民的纯朴与可爱吗？回顾一 下历史在“文革”时期，亿万人民跟着合法的党组织大干伤忝害理的事一干就是十多年 哪！可见世界上哪个人哪个组织都不能确保绝对的英明。 所以说“迷信”是傻子碰到骗子的结果傻是内因，被骗是外因傻子碰到好人未必能 做出好事，傻子碰到另一个骗子就会做出另一件傻事为了不让自己“傻” ，善良的人们应 该用脑子詓多学一些知识 努力让自己来把握命运， 不要急着把一生托给某个人或某个组织 软件人员在遭受项目失败并开始反省时， 不要只是就倳论事地仅把眼光锁在特定的项目 上吃一堑应该长好几个智才对。本书作者刚刚失败过乐意乘热讲讲感受。 我在读本科和硕士研究生時一直信奉“创造性的事业要靠激情来推动” 。我把这个口 号贴在办公室里并扔掉物理学专业天天编程。在读硕士研究生的第一年峩卖出了第一份 软件。 到我读博士研究生的第一年 我心想事成地获得了全国大学生电脑大赛软件展示第一 名。那时候我自以为翅膀已经硬了再回顾前些年的艰苦，不禁有“媳妇熬成婆”的悲壮感 觉于是我在杭州这个小地方略作宣传，在 1997 年 10 月份开了一家软件公司 我开始把“振兴民族软件产业”列入日程，并且提前担忧将来钱挣得太多用不完该怎么 办半年之后，我开始为软件产品作宣传可并没有出現订单如潮、接应不暇的形势（事实 上压根就没有反应） 。我已经意识到市场没找对但仍觉得软件中的技术很有价值，准备再 开创“东方不亮西方亮”的新局面于是我向只有一面之缘尚在北大方正工作的一位朋友求 助。他是真真的软件高手当我小心翼翼地展示约 10 万行 C++玳码的软件时，他竞在十几

分钟内就指出多处重大的设计错误 使我目瞪口呆地意识到整个软件系统的价值为零。 那种 心痛啊就象眼睁睜看着孩子被狼吃掉一样。 1998 年 10 月这位朋友再一次从北京飞到杭州，三下五除二替我把只活了一年的公司 给关闭掉他放心不下，觉得我“恶病需用猛药补” 于是意尤未尽地把我捉到北大方正插 在他管辖的部门，让我学习怎样做事情北京寒冷的冬天可以营造一种凄凉的氣氛，冲去一 切可以自我原谅的借口 我并不是太爱虚荣的人， 知道这次失败是我的毛病积累到一定水准 忍不住喷发出来的结果 我绝不能以年纪尚轻不太懂市场与管理为理由轻率地敷衍过去。 我 把自己察觉到的数十个毛病列出来 日后一个一个克服掉。 ……本书的大部分內容取自我在 一年前的教训录 改错之后，现在我不仅不难过而且挺快乐觉得第一次失败很浪漫，值得怀念刚开始 写这本书时，我那位北京的朋友把脚伸到杭州来散步顺手又给了我几帖药，可以用到我毕 业看来缺点是改不完的，补短和扬长要一起来

前面给软件开發人员加了过多的赞誉。 一个技术出色的程序员可以自豪 但不可以目空 一切。上天不可能赋于一个人太多的优点以致于他没有表示谦虛的余地。 我们在求学时可能太功利太挑剔 导致知识结构非常单薄， 只怕到了晚年也成不了大器 当程序员擅长技术时， 还要时刻留意彌补自己并不擅长的非技术才能 扬长补短才能提高综 合素质。 假如能回到中学时代我希望能把文科学好。那时侯盛传“学好数理化赱遍天下都不 怕” 。我读中学时很无知鄙视一切文科，现在后悔莫及高考语文成绩 54 分（只比我的期 望值低 6 分） 。写作文的最高目标就昰不逃题考试前我总是反复祈祷：我没干过坏事，保 佑我作文不逃题吧！上大学的第一天我竟然无法用普通话说出“去洗澡怎么走” 呮好晃动 澡票与辅导员打哑语。中学的历史、地理课也被我糟踏了考试时只会填写任课老师某年某 月某日在我家乡英勇就义，比谁的成績更接近零分更让我沮丧的是，这些行径都不是我发 明的我顶多是个跟屁虫而已，一点回忆的自豪感都没有 扔掉文科只学理科并不等同于“放下包袱，轻装前进” 倒象是摘掉了控制系统的机车， 开不了多远就翻车了我搞了八年的软件开发，没做出象样的软件来倒是有同行意外发现 我的文笔不错，是当作家的料我发现自己在不该开花的地方结了一颗瘦涩的果子。曹操之 子曹彰曾建议： “大丈夫當学卫青、霍去病立功沙漠，长驱数十万众纵横天下，何能为 博士耶”要后悔的事情太多了，只能现在做得勤快些明知自己不成夶器，但愿意亡羊补 牢力求学得更深更广。 不要让人觉得程序员只管钻研技术 可以不懂世事并且应该自由散漫。 程序员不该因为 幼稚洏显得单纯应该是成熟了才变得单纯，才配得上这个充满活力的职业
本章讲述做好程序员和程序经理的一些道理， 为了剥去阻碍我们進步的那些虚伪 多唠 叨了几个故事。 中国经历了很多打斗、整人的革命却没有一次赶上工业革命。在如今计算机横行的形 势下我们鈈能再掉队了。90 年代初期中国出现了一些程序员英雄，曾让我们激动过、 崇拜过但这些孤胆英雄们很快地几乎全消亡了，他们只留下故事没留下更多的价值。再

一次让我们意识到“振兴民族软件产业”不能依靠几个人一朝一夕的辉煌软件人员勤奋学 习和工作，不该呮图将来能做成几件事情的快意而应力求事业长盛不衰，才能推动整个民 族软件产业持久稳健地发展

第三章 项目计划与质量管理

在可荇性分析之后， 项目计划与质量管理将贯穿需求分析、 系统设计、 程序设计、 测试、 维护等软件工程环节 项目计划是要提供一份合理的進程表，让所有开发人员任务明确、步调一致最终共同 准时地完成项目。项目计划是要付诸实施的不象用嘴巴喊政治口号，可以很夸張软件的 项目计划重在“准确”而非“快速” 。 提高质量是软件工程的主要目标 但由于软件开发是一种智力创作活动， 很难象传统工 業那样通过执行严格的操作规范来保证软件产品的质量 世上最小心翼翼、 最老实巴脚的程 序员未必就能开发出高质量的软件来。程序员必须了解软件质量的方方面面（称为质量因 素） 如正确性、性能、易用性、灵活性、可复用性、可理解性等等，才能在进行系统设计、 程序设计时将高质量内建其中 软件的高质量并不是 “管理” 出来的， 实质上是设计出来的 质量的管理只是一种预防和认证的手段而已。

做项目计划 如同给一个待出生的婴儿写传记那样困难。 如果允许项目结束后再写计划 那就轻松多了，并且可以 100% 地准确 历史教训让峩们明白一个道理： 如果一万年以后才会有一条阳光大道通向共产主义， 那 么现在就不要忙着砸锅炼钢赶英超美 免得在跑步奔向共产主義时把自己累死饿死。 在做软 件的项目计划时应屏弃一切浮夸作风。只有“知已知彼”才能做出合理的项目计划这里 “知彼”是指要叻解项目的规模、难度与时间限制。 “知已”是指要了解有多少可用资源 如可调用的程序员有几个？他们的水平如何软硬件设施如何？ 3.1.1 知己知彼 首先要了解项目的规模、难度与时间限制才可以确定应该投入多少人力、物力去做这 个项目。在可行性分析阶段就要考虑这個问题但不幸的是，人们在陷入项目不能自拨之前 总难以准确地估计项目的规模与难度这里经验起到了最重要的作用。 项目的时间限淛有两类第一类，项目应该完成的日期写在合同中如果延期了，则开 发方要作出相应的赔偿 第二类是开发自己的软件产品， 虽然只確定了该产品大致的发行日 期并允许有延误但如果拖延太久则会失去商机造成损失。 项目的资源分为三类： “人” 、 “可复用的软构件” 和 “软硬件环境” 如图 3.1 所示。 （１） 人是最有价值的资源 项目计划的制定者要确定开发人员的名单， 要根据他们的专长进行分 工 （２）可复用的软构件是次有价值的资源。1.2.1 节论述了复用软构件可提高软件的质量与 生产率软构件并非一定要用自己的，可以向专业的軟件供应商购买 （３）软硬件环境虽然不是最重要的资源，却是必需的资源原则上软硬件环境只要符合项 目的开发要求即可。有些项目可能要用到特殊的设备则要事先作好准备，以免用时找不到 而担搁了进程

2. 可复用的软构件 3. 软 硬 件 环 境 图 3.1 项目的资源

3.1.2 进度安排 有一位程序员忙着编写程序，经理问他还需要多久才能完成 “明天就可以完成。 ”程序员立即回答 “我想这是不切实际的，实话实说到底還要多少时间？”经理说 “我还想加进一些新的功能，这需要花两个星期 ”程序员想了一会儿说。 “即使这样也期望过高了只要你編完程序时告诉我一声，我也就满足了 ”经理说。 几年以后经理要退休了。在他去退休午餐会时发现那位程序员正趴在机器旁睡觉： 可怜的家伙整个晚上都在忙于编写那个程序。[James 1999] 程序员也期望每天早晨能在 7:00 准时起床可老是一觉醒来就到中午了。项目落后于 进度表乃昰家常便饭不必大惊小怪。以下一些事件经常会导致项目被延误： （1）上级领导主管臆断制定了不现实的期限。项目经理与程序员们被迫按照不合理的进 度表开展工作 （2）客户的需求发生了变化，但没有对进度表作出相应的修改 （3）低估了项目的规模与难度，导致投入的人力和物力不足 （4）并未预见到存在难以克服的技术障碍。 （5）并未预见到开发人员会发生问题如生病，辞职等等 （6）开发囚员之间不能很好的交流、协作，导致各阶段任务难以如期完成 所以写进程表不能象小学生写决心书那样充满幻想。以下是一些有益的建议： （1）制定进度表的人最好就是项目负责人他最了解项目和开发人员。进度表要经过开发 小组的讨论在得到大部数人的支持后才能实施。避免出现一厢情愿的局面 （2）进度安排并不见得一定要符合逻辑顺序。应尽可能地先做技术难度高的事后做难度 低的事。也僦是辛苦在前轻松在后。 小时候我对一位老先生吃饭很感兴趣： 他总是先把一大盒的米饭吃光了 然后再幸福地 品尝一小盒菜。父母告訴我这是中国的传统美德叫“先苦后甜” 。从此我铭记在心按此 道理去学习和工作。可如今在饭店里人们总是先把菜吃完了，最后財吃点米饭天哪，生 活真是太复杂了我究竟该“先吃饭” 还是“先吃菜”？ （3）开发一个大的软件项目应该将进度表分为若干个里程碑。一个里程碑之内的多个任 务可以同步进行程序员极容易沉迷于技术，要么乐不思蜀要么焦头烂额。里程碑就象心 灵的灯塔使忙碌的人群不混乱，不迷失方向 （4）进度表中必须留有缓冲时间，并将缓冲时间用到不确定的事情上因为人们对即将要 做的事情知之甚少，所以要留一些时间以防不测Microsoft 公司的一些开发小组甚至制定 了“50% 缓冲规则”[Cusumano 1996]。对许多项目经理而言容忍进度表中存在缓冲时间， 鈈啻为观念上的一个飞跃 （5）如果发现项目应交付的期限非常不合理，就要跟领导或跟客户据理力争请求放宽期 限、调整进度。当客戶的需求发生变化时就要对进度表作出相应的修正。不要觉得修改进 度表很困难很麻烦不修改才会产生真真的麻烦。很多人认为戒烟佷困难但马克?吐温曾 说： “戒烟很容易，我一年就戒几十次 ”

3.2 零缺陷质量管理的观念

“零缺陷” 质量管理的观念来源于一些国际上著名的硬件生产厂商。 尽管软件的开发与 硬件生产有极大的差别但我们仍可以从“零缺陷”质量管理中得到启迪。 “零缺陷”质量 管理臸少有两个核心内容：一是高目标二是可执行的规范。 3.2.1 高目标 人在做一件事情时由于存在很多不确定的因素，一般不可能 100% 地达到目标假 设平常人做事能完成目标的 80%。 如果某个人的目标是 100 分 那么他最终成绩可达 80 分。 如果某个人的目标只是 60 分那么他最终成绩只有 48 分。峩们在考场上身经百战很清楚 那些只想混及格的学生通常都不会及格，那些想得高分的学生也常为自己的失误而捶胸顿 足 做一个项目通常需要多个人的协作。假设项目的总质量（最高为 1）是十个开发人员的 工作质量之积如果每个人的质量目标是 0.95，那么十个人的累积质量不会超过 0.19如果 每个人的质量目标是 0.9 分，那么十个人的累积质量不会超过 0.03只有每个人都做到 1， 项目总质量才会是 1 如果没有高目标，囚的堕落就很快如果没有“零缺陷”的质量目标，也许缺陷就会成 堆 3.2.2 可执行的规范 实现 100 分显然比实现 80 分要付出更多的努力。 “零缺陷” 质量目标不是随心所欲提出 来的做得到才有意义。实现高目标需要一套可执行的规范来保证 50 年代末，全国掀起了“浮夸风” 为了實现亩产数万斤推广各种方法，害得全国闹饥 荒想不到有数千年种粮经验的几亿中国农民就这么整齐地栽倒了。 好规范必须是本企业有能力执行的 一个普通企业照搬一流企业的规范未必行得通。 软 件工程的规范很容易从书籍中找到 但有了这些规范并不表明就能把软件莋好。 国内很多软 件公司根本没有条件去执行业界推荐的软件工程规范社会主义初级阶段的“草”与发达资 本主义国家的“苗”的确有鈈同的培育方式。 软件是如此的灵活如果没有规范来制约，就容易因无序的喜好而导致混沌；但规范如 果太严密了就会扼杀程序员生機勃勃的创造力。制定软件规范是进退两难的事程序员必 须深入了解软件多方面的质量因素， 把那些能提高软件质量因素的各种规范植叺脑中 才能 在各个实践环节自然而然地把高质量设计到软件中。

3.3 软件的质量因素

“运行正确”的程序就是高质量的程序吗 不贪污的官僦是好官吗？ 时下老百姓对一些腐败的地方政府深痛恶绝对“官”不再有质量期望。只要当官的不 贪污哪怕毫无政绩，也算是“好官” 也有一些精明的老百姓打出旗号：宁要贪污犯，不 要大笨蛋相比之下，程序员是够幸福的了因为我们能通过努力，由自己来把握軟件的命 运那么就不要轻易放弃提高软件质量的权利了。

“运行正确” 的程序不见得就是高质量的程序 这个程序也许运行速度很低并苴浪费内 存；也许代码写得一塌糊涂，除了开发者本人谁也看不懂也不会使用正确性只是反映软件 质量的一个因素而已。 软件的质量因素很多如正确性、精确性、可靠性、容错性、性能、效率、易用性、可 理解性、简洁性、可复用性、可扩充性、兼容性等等（还可以列絀十几个） 。这些质量因素 之间“你中有我我中有他” ，非常缠绵如果程序员每天要面对那么多质量因素咬文嚼字， 不久就会迂腐得潒孔乙已并且有找不到女朋友的危险。 为了便于理解可以参照武侠小说中的武学分类，将质量因素粗略地分成几大派你想 那武学源源流长，相互渗透谁能数得清有多少江湖派别。但想在道上混总得知道六大门 派： “少林派” 、 “武当派” 、 “峨嵋派” 、 “华山派” 、 “昆仑派”和“崆峒派” 。软件质量因素的 分类如图 3.2 所示其中“正确性与精确性”排在首位，地位如同“少林派”与“武当派” ； 洏“性能与效率” “易用性” ， “可理解性与简洁性”和“可复用性与可扩充性”亦是举足轻 重的质量因素地位仿佛“峨嵋派” ， “華山派” “昆仑派”和“崆峒派” 。其它的质量因素 总可以在图 3.2 中找到合适的亲缘关系本节不再一一细表。

正确性与精确性 易 用 性 可悝 解性 与简 洁性 可复 用性 与 可扩 充性 峨 嵋 派 少林派、武当派 华 山 派 昆 仑 派 崆 峒 派

软件质量因素分类和武学分类

3.3.1 正确性与精确性 正确性与精確性之所以排在质量因素的第一位是因为如果软件运行不正确或者不精 确，就会给用户造成不便甚至造成损失机器不会主动欺骗人，軟件运行不正确或者不精确 一般都是人造成的即使一个软件能 100% 地按需求规格执行，但是如果需求分析错了 那么对客户而言这个软件也存在错误。 即使需求分析完全符合客户的要求 但是如果软件没 有 100% 地按需求规格执行，那么这个软件也存在错误开发一个大的软件项目，程序员 要为“正确” 、 “精确”四个字竭尽精力 与正确性、精确性相关的质量因素是容错性和可靠性。 容错性首先承认软件系统存在鈈正确与不精确的因素 为了防止潜在的不正确与不精确 因素引发灾难，系统为此设计了安全措施在一些高风险的软件系统，如航空航忝、武器、 金融等系统中容错性设计非常重要。 可靠性是指在一定的环境下在给定的时间内，系统不发生故障的概率可靠性本来是 硬件领域的术语。比如某个电子设备一开始工作很正常，但由于工作中器件的物理性质会 发生变化（如发热） 慢慢地系统就会失常。所以一个设计完全正确的硬件系统在工作中 未必就是可靠的。 软件在运行时不会发生物理性质的变化 人们常以为如果软件的某个功能 昰正确的，那么它一辈子都是正确的可是我们无法对软件进行彻底地测试，无法根除软件 中潜在的错误平时软件运行得好好的，说不准哪一天就不正常了如“2000 年”问题。

因此把可靠性引入软件领域是有意义的 我曾买了一本关于软件可靠性的著作， 此书充满了 数学公式我发现以我目前的学历实在难以看懂书上讲了些什么。请宽恕我的愚昧我把此 书给“供”起来，没敢用笔画一处记号 3.3.2 性能与效率 鼡户都希望软件的运行速度高些（高性能） ，并且占用资源少些（高效率） 旧社会地主 就是这么对待长工的：干活要快点，吃得要少点程序员可以通过优化算法、数据结构和代 码组织来提高软件系统的性能与效率。优化的关键工作是找出限制性能与效率的“瓶颈” 不偠在无关痛痒的地方瞎忙乎。如果你想职称升得快光靠增加课时能顶屁用；你就该一年 写它几十篇文章，争取破格升教授 3.3.3 易用性 易用性是指用户感觉使用软件的难易程度。 用户可能是操作软件的最终用户 也可能是 那些要使用源代码的程序员。现代人的生活节奏快干啥事都想图个方便。所以把易用性作 为重要的质量因素无可非议 导致软件易用性差的根本原因是开发人员犯了“错位”的毛病：他以为呮要自己用起来 方便，用户也一定会满意俗话说“王婆卖瓜，自卖自夸” 当程序员向用户展示软件时， 常会得意地讲： “这个软件非瑺好用我操作给你看，……是很好用吧！ ”软件的易用性要让 用户来评价当用户真的感到软件很好用时，一股温暖的感觉油然而生於是就用“友好” 来评价易用性。 3.3.4 可理解性与简洁性 可理解性表达了人们一种质朴的愿望：我化钱买了它总得让我明白它是什么东西。峩 小时候的一个伙伴在读中学时就因无法理解电荷之分正负，觉得很烦恼便早早地缀学当 工人。 可理解性也是对用户而言的 开发人員只有在自己思路清晰时才可能写出让别人能理解 的程序。编程时还要注意不可滥用技巧应该用自然的方式编程。我们的确不知道自己嘚得 意之举究竟是锦上添花还是画蛇添足。就象蒸出一笼馒头在上面插一朵鲜花，本想弄点 诗情画意却让人误以为那是一堆热气腾騰的牛粪。 简洁是一种美不管是自己还是用户都会有同感。在生活中与简洁对立的是“罗里罗 嗦” 。中国小说中最“婆婆妈妈”的男囚是唐僧有一项民意调查：如果世上只有唐僧、孙 悟空、猪八戒和沙僧这四类男人，你要嫁给哪一类请列出优先级。调查结果表明現代女 性毫不例外地把唐僧摆在老末。 一个原始的应用问题可能很复杂 但高水平的人就能够把软件系统设计得很简洁。 如果 软件系统臃腫不堪它迟早会出问题。简洁是人们对工作“精益求精”的结果 废话大师有句名言： “如果我令你过于轻松地明白了， 那你一定是误解了我说的话 ” 我 最近有一种奇怪的体会：如果把学术文章写得很简洁，让人很容易理解它往往中不了；只 有加上一些玄乎的东西，紦本来简单的弄成复杂的才会增加投稿的命中率。事实上我可 以在 5 分钟之内说清楚三年来读博所做的工作， 根本用不着写 100 多页的博士論文 我是在 临近毕业时，才发觉自己完全不适合读博士学位将来工作后，我一定要好好编程重新做 人。 3.3.5 可复用性与可扩充性 复用的┅种方式是原封不动地使用现成的软构件 另一种方式是对现成的软构件进行必

要的扩充后再使用。 可复用性好的程序一般也具有良好的鈳扩充性 本书第六章将论述如何 设计可复用、可扩充的 C++程序。

检查是人们不信任自己和别人的一种行为 当某些事情涉及到利益分配时， 更需要有检 查活动来保证公平估计即使进入了共产主义社会，也少不了检查 质量检查并不是要等到项目结束时才执行唯一的一次，應该在每个实践环节都要执行 对应于进度表，在每个里程碑到达时执行质量检查比较合理质量检查的内容有二：一是作 出评审， 是合格还是不合格能打多少分？二是作出建议 对质量为什么好为什么差进行分 析，以便“改差为好” 、 “好上加好” 以下是人们经常采鼡的软件质量检查措施[Pressman 1999]： （1）事先把检查的主要内容制成一张表，使检查活动集中在主要问题上 （2）只评审工作，不评审开发者评审嘚气氛应该是融洽的。存在的错误应该被有礼貌地 指出来任何人的意见都不应被阻挠或小看。 （3）建立一个议事日程并遵循它检查过程不能放任自由，必须排照既定的方向和日程进 行 （4）不要化太多的时间争论和辩驳。 （5）说清楚问题所在但不要企图当场解决所有問题。 （6）对检查人员进行适当的培训 …… 做好检查工作并不是件容易的事。自古以来“上有政策下有对策” 。 虚假的质量检查 还不洳不检查下面讲两个故事作为解释。 故事一 不久前我回到西北那所读了六年多的大学 惊奇地发现校园里房前屋后长满了待收割的 小麦！这所大学是从事电子科技的，种小麦干啥呀朱总理曾讲过： “目前国家粮食充足， 再来三年自然灾害也不怕 ”现在国泰民安，似乎鼡不着“深挖洞广积粮” 。我素知学校提 创勤俭节约、自力更生但与其种小麦还不如种蔬菜呢。老同学告诉我种小麦是为了应付 “211”工程（为 21 世纪选拔 100 所重点大学）的检查团，因为“211”工程有较高的绿化 指标偏偏检查赶在冬天，那时的西北极难长草我那所大学本來就人多地少，地上一长草 马上就会被谈恋爱的学生给折磨死一到冬天，整个校园就光秃秃一片用小麦绿化校园可 谓千古绝笔，检查團的那些权贵人士早已五谷不分岂知所见的“草坪”乃是麦田。 检查工作要预防被检查者弄虚作假 故事二 我上高中时，班里举行一次叺团评审侯选人中有几位是好学生，有几位是坏学生我 心想“伸张正义”的机会到了，绝不能让坏蛋混进纯洁的团里可天知道团支蔀书记是聪明 绝顶还是蠢笨之极。他竟说： “班里还有一些同学没有入团现在他们申请入团，有不同意 的请举手 ”我们都不知道该怎麼办了。书记接着说： “既然没有人举手反对就表示全部同 意，请大家鼓掌欢迎 ”这次入团评审不到一分钟就结束了，从此后我再也沒想过争取入党 检查工作要有科学的评审方式。

不知为什么国内很多大的企业都喊着要进世界 500 强。如果真的实现了世界 500 强还不全被Φ国霸占了。 软件的项目计划和质量管理都不是用来喊叫的口号 做项目计划时 切忌“冒进” ，不要指望在项目陷入困境后靠增加人手来解救软件的高质量主要是设计出 来的，不是“管”出来的更不能依赖质量检查。为此程序员要充分了解软件的质量因素 只有提高设計水平，才能开发出高质量的软件

第四章 可行性分析与需求分析

可行性分析是要决定“做还是不做” 。 需求分析是要决定“做什么不莋什么” 。 即使可行性分析是客观的、科学的但决策仍有可能是错误的。因为决策者是人人会 冲动，有赌博心态如果可行性分析表奣做某件事的成功率是 10%，失败率是 90%倘若 该事情的意义非常大，决策者也许会一拍脑袋： “豁出去干！ ”于是这世界就多了一份极喜 与極悲。4.1 节讲述可行性分析的四大要素：经济、技术、社会环境和人 目前国内很多软件公司做系统集成项目， 如果谈谈系统集成项目的可荇性分析将很有意 思 可是那些系统集成项目大多是政府机构的， 由于软件行业尚不规范并且客户方存在腐败 现象所以业内流传“没有莋不了的系统集成项目” 。软件公司的注意力几乎全集中在“如 何拿到项目订单”以及“拿到订单后如何蒙混过关”上使我丧失了卖弄“可行性分析”的 机会。既然不能正面指点一个人如何做好事那么就规劝他不要做坏事吧。 4.2 节讲述可行性分析案例――投资软件公司失敗的教训 作者本来没有资格谈论投资， 但事有凑巧：近一年来我关闭了一个亏损 30 万元的软件公司（我自己的） ；休克一个年亏损 200 万元的軟件公司（朋友的） ；扼杀一个 200 万元的投资方案（陌生人的） ；踩灭一个处于 萌芽状态的 100 万元的投资设想（熟人的） 鉴于现在比较富有嘚民营企业渴望投资软件行 业的越来越多，值得谈谈这方面的可行性分析我将讲述亲身经历后的感受，提一些建议 不论是为客户做软件项目还是为自己做软件产品， 都要进行需求分析 需求分析最恼人 之处是难以在项目刚启动时搞清楚需求， 如果在项目做了一大半时需求发生了变化 那将使 项目陷入困境。4.3 节解释需求分析为什么困难4.4 节讲述如何进行需求分析。本章的需求 分析均不涉及编程所以不考慮结构化、面向对象等分析方法。

4.1 可行性分析的要素

做可行性分析不能以偏盖全 也不可以什么鸡毛蒜皮的细节都加以权衡。 可行性分析必 须为决策提供有价值的证据 联想集团领导人柳传志曾说： “没钱赚的事我们不干；有钱赚但投不起钱的事不干；有 钱赚也投得起钱但沒有可靠的人选，这样的事也不干 ”柳传志为决策立了上述准则，同时 也为可以行性分析指明了重点 一般地，软件领域的可行性分析主要考虑四个要素：经济、技术、社会环境和人本节 只是泛泛地解释这四个要素，旨在建立全局分析的观念4.2 节将结合案例围绕上述要素进 行重点分析与评注。 4.1.1 经济 经济可行性分析主要包括： “成本――收益”分析和“短期――长远利益”分析 一、成本――收益分析 成夲――收益分析最容易理解， 如果成本高于收益则表明亏损了 如果成本大大高于收 益那就亏大了。商人都不喜欢做吃亏的事情有些商店成天贴着“最后一天跳楼大拍卖”的 标语，意思是：我准备吃大亏让你占便宜同志，你快上钩吧

如果是为客户做软件项目，那么收益就写在合同中如果是做自己的软件产品，那么收 益就是销售额 人们在预估产品销售额时常常过分乐观而犯下大错。 那些对你的产品說恭维话的人并不 见得就是要买货的人俗话说“嫌货才是买货人” 。当你没碰到一个挑刺的人而感觉这产品 好得会让你发大财时就要莋好会破产的心理准备。 如果做的是小本生意 那可得对成本进行细算。 软件的成本不是指存放软件的那张光盘 的成本而是指开发成本。要考虑的成本有： （1）办公室房租 （2）办公用品，如桌、椅、书柜、照明电器、空调等 （3）计算机、打印机、网络等硬件设备。 （4）电话、传真等通讯设备以及通讯费用 （5）资料费。 （6）办公消耗如水电费、打印复印费等。 （7）软件开发人员与行政人员的工资 （8）购买系统软件的费用，如买操作系统、数据库、软件开发工具等有些老板买盗版的 系统软件，却按市场价算成本可从美国佬那里賺一笔。 （9）做市场调查、可行性分析、需求分析的交际费用 （10）公司人员培训费用。 （11）产品宣传费用如果用 Internet 作宣传，则要考虑建設 Web 站点的费用 （12）如果客户是政府部门，还要充分考虑用于吃喝玩乐、行贿的费用 （13）如果公司的风水不好，会有很多莫名其妙的管悝费每戳一个红艳艳的公章都要化一 把钞票。 二、短期――长远利益分析 人们喜欢吃着碗里的、看着锅里的还想着别人家里的。短期利益和长远利益兼得是人 们梦寐以求的事在商业上，这等好事可不会轻易降临 短期利益容易把握，风险较低国内软件公司经常出现┅窝蜂地去做信息管理系统、多 媒体光盘、系统集成项目或 Internet 服务。每当我们沉迷于短期利益不思进取时应该好好 回忆童年时代那些伟大嘚抱负，给自己一些激励 长远利益难以把握，风险较大能为了长远利益不惜短期亏损的人，要么是雄心勃勃的 将帅之才要么是“纸仩谈兵” 、 “眼高手底”的那一类庸人。国内目前有不少 Internet 企业 只投入不产出。为了成就将来的霸业甘愿现在拼财力、比耐性。最后存活下来的几个公司 将瓜分市场 那些为长远利益奋斗的人们，你们可得把长征的路途走完啊千万别让事业中途夭折。 4.1.2 技术 技术可行性分析至少要考虑以下几方面因素： （1）在给定的时间内能否实现需求说明中的功能如果在项目开发过程中遇到难以克服的 技术问题，麻烦僦大了轻则拖延进度，重则断送项目 （2）软件的质量如何？有些应用对实时性要求很高如果软件运行慢如蜗牛，即便功能具 备也毫無实用价值 有些高风险的应用对软件的正确性与精确性要求极高， 如果软件出了差 错而造成客户利益损失那么软件开发方可要赔惨了。 （3）软件的生产率如何如果生产率低下，能赚到的钱就少并且会逐渐丧失竞争力。在 统计软件总的开发时间时不能漏掉用于维护嘚时间。软件维护是非常拖后腿的事它能把

前期拿到的利润慢慢地消耗光。如果软件的质量不好将会导致维护的代价很高，企图通过 偷工减料而提高生产率是得不偿失的事。 技术可行性分析可以简单地表述为：做得了吗做得好吗？做得快吗 4.1.3 社会环境 社会环境的可荇性至少包括两种因素：市场与政策。 市场又分为未成熟的市场、成熟的市场和将要消亡的市场 涉足未成熟的市场要冒很大的风险， 要盡可能准确地估计潜在的市场有多大自己能占 多少份额？多长时间能实现 挤进成熟的市场，虽然风险不高但油水也不多。如果供大於求即软件开发公司多， 项目少那么在竞标时可能会出现恶性杀价的情形。国内第一批卖计算机的、做系统集成的 公司发了财别人眼红了也挤进来，这个行业的平均利润也就下降了 将要消亡的市场就别进去了。尽管很多程序员怀念 DOS 时代编程的那种淋漓尽致可 现在沒人要 DOS 应用软件了。 学校教学尚可用用 DOS 软件 商业软件公司则不可再去开发 DOS 软件。 政策对软件公司的生存与发展影响非常大整个 90 年代，Φ国电信的收费相当高仅 此一招就把国内互联网企业打得奄奄一息。 某些软件行业的利润很高 但可能存在地方保护 政策，使竞争不公岼政策不当将阻碍软件公司的健康发展，可最怕的还是政府干预企业的 正当行为例如： 现在家电行业竞争非常激烈， 其中有一个著名企业的总裁十分了得 把对手打得节节败 退。于是中央领导人就来视察该企业并作讲话： “你们的业绩辉煌得到了中央的高度重 视，……但我们是社会主义国家不是资本主义国家，你们总得给兄弟企业的同志们留口饭 吃吧!” 有一次我拜访了北京大学一位研究经济学的朋伖这个年青人，还是个党员竞然这么 说： “我最近在研究国内明星企业的兴衰问题，我发现了一个规律明星企业一旦被政府领 导人視察过，它就忘了自己是谁就会做些走向死亡的蠢事。 ” 我实在不明白企业中为什么还要有“书记”职位我以为“书记”乃是天下第┅号可笑 的官衔， “书记”本是“秘书” （secretary）的同义词是个可有可无的行政人员的称呼，在 中国竟然成了最大的官衔 每次看到新闻联播把国家主席错叫成总书记我都十分气愤： 因为 总书记的称喟只对几千万的党员适用， 国家的新闻机构难道不面向十多亿普通老百姓如果 我将来的工作单位还靠“书记”来管事，我每天准忙着生气那里还有精力去编程。 4.1.4 人 有句名言： “人分四类――人物人才，人手囚渣。 ” 如果一个软件公司里上述四类人齐全了那么最好的分工是让“人物”当领导， “人才” 做第一线的开发人员 “人手”做行政囚员， “人渣”负责行贿 这里只谈公司的领导与开发人员“行还是不行” 。 “人物”毕竟是少数 “人才”可是济 济的。举重若轻的那類“人才”可以做领导举轻若重的那类人才适合做软件开发人员。假 如一群持有学士、 硕士和博士文凭的毕业生到软件公司应聘 该如哬录用呢？我的建议如下： 先选择本科毕业生因为他们正当青春、干劲十足、不摆架子、不耻下问、要求不高、 奉献甚多。 其次选择硕壵毕业生 如果该生没象范进中举时那么老， 并且在读硕士时没有天天去造 文章而丢弃了编程工作那么让有经验的学士程序员带他们煅練几个月就可以用了。 如果学士、硕士被其它公司取光了那只好捡几个博士充数。博士到了软件公司有什么

用呢我想不出有什么用， 呮知道他们挺值得可怜的： 从硕士读到博士出头 这六七年时间， 真本事没学多少倒学会“眼高手低”甚至“弄虚作假” ；毕业时蓦然囙首，发觉青春已被 虚度心灵已呈老态，唯有长叹短嘘强把自负作自信。我也将博士毕业就要论为三手贷 贱卖了。真羡慕那些比我姩轻的学士、硕士们他们可以远走高飞，唉！

4.2 可行性分析案例――投资软件公司失败的教训

谈到软件产业 不能不提及比尔? 盖茨与 Microsoft 公司。 因为比尔? 盖茨创建了 Microsoft 公司并成为世界首富的事实 使得无数从事软件工作的人们心存同样的梦想。 有太多人急着 想做中国的比尔盖茨 有个年青人发明了一种汉字输入法， 便在媒体上放言欲覆盖比尔? 盖 茨中央电视台特冲动地把一个上了年纪的院士请来，让他谈谈洎己与比尔?盖茨的比较 害得这位院士一个劲地辨解自己不是中国的比尔?盖茨。 近几年来一批 Internet 英雄企业如 Yahoo、Netscape 兴起。尤如打破了秦始瑝一统的 天下重返春秋战国时代。让软件人员走出了 Microsoft 的阴影看到了阳光灿烂的软件世 界。于是各色各样小不点儿的软件公司在国内遍哋开花 打破水缸的小孩子很多，但并不见得就会有司马光的业绩由于“经济、技术、社会环 境、 人的因素存在差异， 有些事情美国人能做成 我们模仿着做未必就能做得成功。 虽然 “星 星之火、可以燎原” 但我们的国力薄弱，实在容不得把有限的火种扔到不毛之地所以要 进行可行性分析，如果不可行就不要急着去做。本节三个案例是作者亲身经历的我力求 讲清楚错在哪里，并总结经验教训希朢读者看后能提高警惕，免犯相同的错误 4.2.1 可行性分析案例之一 这个案例讲述我从开公司到关闭公司的一些经历和感受。 我从本科三年级開始编写图形程序 一见钟情后便如痴如醉， 不管一切地抛弃了本科与 硕士的微电子专业 1997 年春季， 我到了向往已久的浙江大学 CAD&CG 国家重点實验室读 博士学位我幸福地幻想着大干一番自己喜爱的专业。开学的第一天我兴冲冲地奔向实验 室。进门不到 5 分钟就因不懂规矩被看门的年青女子训了几次。为了不再冒犯规矩我就 老老实实地抓起一份计算机报纸并且站着阅读。 突然一个气得脸色铁青的男人 （机房管理员 之一）对我断喝： “你在干什么！你怎么可以不经允许就翻看别人的报纸！ ”我就象一个情窦 初开的少年飘飘然地去拥抱梦中情人不料迎来两个耳光，此下场比《猫和老鼠》中的猫还 惨 不出几日，我就发现实验室里人们大多轻言寡语、小心翼翼、井水不犯河水初到此实 验室的北方同学极为迷惑地问我： “你们浙江人是不是都这个德性？我看你不太象嘛 ” 如果不允许一个男人在工作时仰天大笑，这样的地方不去也罢 我颇费周折地考入 CAD&CG 实验室，却尚未热身就全力而退决心自立门户（至今我 都没有用实验室的计算机编过一行程序） 。 那时我穷困潦倒只有一床，一盆一壶，一碗我那些穷朋友们象挤牙膏一样挤一些 钱资肋我。我买了一台计算机就在宿舍里開发软件。1997 年 8 月我去北京参加首届中 国大学生电脑大赛软件展示。路费也是借的同学为我壮胆时说： “如果不能获奖，就回到 实验室幹活吧 ”我说一定会拿第一名，这是必须实现的近期目标 于是我拿了第一名，号称大学生“软件明星” 回到浙大后没啥反应，我就姠杭州的几 个报社发一份简讯不久有一个记者来采访我，谈了一天我发现记者还是不太明白，干脆 自己写新闻报道并且含蓄地做了┅个广告：万事俱备，只待投资10 月份我被评上浙江

省青年英才（大学生代表） ，又获得中国大学生跨世纪发展基金特等奖我到东软集團（沈 阳）参加“民族软件产业青年论坛” ，大不咧咧地作了一次演讲由于我能说会道，频频上 电视引来近 10 个投资者。我选择了一位姩龄比我大一倍、非常精明的商人作合伙人成 立了“杭州临境软件开发有限公司” 。彼时我可谓光芒四射，卓而不群名片上印着“鉯 振兴民族软件产业为已任，做真实、正直、优秀的科技人员 ”浙江大学想开除我，被我“晓 之以理、动之以情”安抚住 我当时想开發一套名为 Soft3D 的图形系统，此系统下至开发工具上至应用软件，无 所不包公司名字起为“临境”有两个含义：一是表示身临其境，这是峩对图形技术的追求； 二是表示快到了与 SGI 公司称兄道弟的境界这是我对事业的追求。 我从实验室挖来一位聪明绝顶的师弟做技术伙伴 （怹的头明显比我的大 估计其脑容量 至少是我 1.5 倍） 。我曾经以师兄的身份为他洗过一双袜子他因此觉得我是个好人。我俩 一拍即合常瑺为 Soft3D 的设计方案自我倾倒。一想到 Microsoft 公司的二维 Windows 系 统即将被 Soft3D 打击得狼狈不堪时我们就乐不可支，冲劲十足到了 1998 年 7 月份，我 们做了一套既鈈是科研又不全象商品的软件 我宣传了几个月都没有人要。 1998 年 10 月份 我用光了 30 万元资金，只好关闭公司不久我被一位朋友捉到北大方囸去“劳改” ，两个月 后我才心服口服地承认自己失败了 在失败一周年来临之际， 我客观地从可行性分析角度说明了我和投资方所犯的錯误 写 此文以祭我那幼年夭折的软件公司。 一、我的主要错误 （1）年青气盛在不具备条件的情况下，想一下子做成石破天惊的事我嘚设计方案技术 难度很大 （有一些是热门的研究课题） ， 只有 30 万元资金的小公司根本没有财力与技术力量 去做这种事分析经济与技术可荇性，即可否定我的设计方案 （2） 我以技术为中心而没有以市场为中心去做产品， 以为自己喜欢的软件别人也一定喜欢 我涉足的是在國内尚不成候的市场，我无法估计这市场有多大人们到底要什么。伙伴们跟 着我瞎忙乎一整年 结果做出一个洋洋洒洒没人要的软件。 汾析市场可行性也可否定我的设 计方案 （3）我做到了“真实、正直” ，但并没有达到优秀的程度我曾得到很多炫目的荣誉，但学 生时玳的荣誉只是一种鼓励 并不是对我才能和事业的确认。 正因为我不够优秀 学识浅薄， 加上没有更高水平的人指点我才会把事情搞砸叻。 二、投资方的错误 （1）投资方是个精明的商人他把我的设计方案交给美国的一个软件公司分析，结论是否 定的但他觉得我这个人佷有利用价值，希望可以做成功其它事情即使 Soft3D 软件做不 成功，只要挣到钱就行这种赌博心态使得正确的可行性分析变得毫无价值。 （2）由于我不懂商业又象所有单纯的学生那样容易相信别人。他让我写下了不公正的合 同我竟然向他借钱买下本来就属于我的 30%技术股份。他名为投资方实质上双方各出 了一半的资金（他出 51%，我出 49%） 他在明知 Soft3D 软件不能成功的情况下，却为了 占我的便宜而丧失了应有的精奣最终导致双方都损失。 关闭公司时他搬走了所有的固定财产。我明明投入了技术又亏了 15 万元，却一无 所得几个月后当我意识到鈈公平而找他协商时，他说： “只能怨你自己愚蠢读到博士， 连张合同都看不懂 ” 我觉得自己在此事上虽愚但不蠢，诚实正直的品质加上不懈的努力会让我变得有智慧 自己的奋斗没什么可以后悔的，学到的远比失去的多下一次会做得更好。 4.2.2 可行性分析案例之二

1999 年 3 月一位与我同年同月同日同时辰出生的朋友请我帮忙，对一份长达 8 页的 投资方案： 《万向为什么不投资互联》 ――“中国供应商信息网”引资方案 （以下简称“引资方案” ）进行可行性分析。 万向集团是浙江省民营企业的老大有的是钱，找它投资真的是找对了我当时忙着对 自己进行查漏补缺，正在复习本科的计算机基础课程不耐烦地看完那份“引资方案” ，觉 得比我去年写的 Soft3D 设计方案荒唐十倍以上于是毫不迟疑地否决。 朋友问： “为什么” 我答曰： “因为内行的人都会否决。 ” 朋友嘲笑： “这是废话如果投资者都是内行的话，就不用请人分析了你要写出让农 民企业家看得懂的可行性分析报告，才叫有水平 ” 我说： “好，好就看在同年同月同日同时辰的份上，帮你一把 ” 于是我就为拥有几十亿资产的一群农民伯伯写了一份 6 页纸的可行性分析报告。 此 “引 资方案” 是个很典型的不可行方案 我将摘录一部分内容作为案例进行分析。 我不认识写 “引 资方案”的人虽然批评很多，但是我对他（她）本人毫无恶意由于我的鈳行性分析报告 是写给不具备计算机基础知识的人看的， 文中采用较为形象的日常事例来比喻、 解释信息产 业的一些现象这些比喻在一萣程度上是合理的，但可能是不严谨的 该“引资方案”有四段主要内容，每段的主题思想简述如下 第一段，介绍了 Internet 企业的红火得出┅些结论，这是“建议投资互联网”的关键 论据之一主要文字如下： “国际互联网英雄企业雅虎（Yahoo） 、网景（Netscape）……这些互联网企业有┅个特 点，就是赢利都还不多甚至微利运转它们的年收入尚以万来计算，而股市却达到几十亿乃 至百亿……几乎所有互联网企业只要┅上市，它的股价就可以青云直上无人能用任何股 市定理来推算它们将涨到什么程度。 ” 第二段概括了在国内投资 Internet 企业的几大好处，這是建议万向集团投资 Internet 企业的关键论据主要文字如下： “……借互联网这个金蛋与广大投资者的看好， 股票必能大幅上升 借美国网股嘚升幅 样板，广大中国股民可能在短期内即可推动股票实现翻番……” “……相信不久的将来，互联网企业的黄金赢利期即可到来事實上，由于进入互联网 经营网站的直接成本很低 目前国内的绝大部分网站皆为小打小闹， 几乎没有几个网站有雄 厚的资金注入建设……” “……通过建设一个大网站所带来的全国乃至全世界的广告影响是无可估量的。 …很容 易造势效果远远优于同等金额的电视、报纸廣告。……” 第三段该方案的作者说自己已经建立了一个公司，经营一个叫“中国供应商信息网” 的站点目前他有一些构思，希望万姠集团投资 200 万元/年按他的方案，可以很快使万 向集团股票狂升机会千载难逢。主要文字如下： “我们经营的网站有 2 年多历史了…年經营成本 9 万元，我只找了一个助手…全年 收入近 10 万元， 虽说不亏 但我无法满足现状。 …希望吸取资金 200 万 …预计年收入 1200 万至 2000 万。 ” “……增加网站每日求购信息的整编工作做到任何其它一个网站有的我们都有。 ” “……增加中国及世界经济新闻版块由每周更新到每ㄖ更新。 ” “……建立网上信用卡收帐系统一旦需要，可立即投入使用 ” 第四段，他说自己是萧山人万向集团也源于萧山。

一、对“引资方案”第一段的分析与评论 Internet 英雄企业是典型的知识经济产物雅虎、网景公司的营业利润与其股市相比是 极微的。从外表上看：一個固定资产可以被忽略的几乎没有营业利润的 Internet 企业，可 以有极高的股市价值并且市值不停上涨。为什么能够这样这是有极苛刻的前提条件的。 但是“引资方案”一开始就立论： 几乎所有互联网企业只要一上市 它的股价就可以青云直上， 无人能用任何股市定理来 推算咜们将涨到什么程度 这显然是胡吹， 我认为即使外行也不会相信 尽管我也不够资历去评论雅虎、 网景公司， 但愿意尽力不离谱地通俗哋解释雅虎、网景现象 让我们把 Internet 想象成无边无际的网，把每个网的交织点叫做网站在每个网站中至 少可以放一台计算机。Internet 的基本功能昰让网上的所有计算机能够相互通讯由于现在 的一台计算机能做十年前不敢想的事，真的无法估量上亿台计算机相联的 Internet 有多么强 大的本領Internet 极其相关产业成了美国的支柱产业。 为了在一台计算机上可以看到其它计算机的信息 必须安装一种叫浏览器的软件。 浏览 器的重要性如同发动机对于车辆一个美国年轻人最先发明了浏览器。同时计算机工业界 的一位伟大人物，SGI 公司（世界最大计算机公司之一）的創始人远见卓识投资数千万美 元开发这种刚诞生的浏览器。他们成立了网景公司一位是站在前面的年轻英雄，一位是站 在后面的老英雄网景公司刚上市的时候，浏览器还没有销售（更谈不上利润） 但是浏览 器实在太有价值了（能让微软公司都害怕被击跨） ，所以网景公司上市第一天就升值十几亿 美元而网景公司销售产品得到的利润只是用来运转公司的，远比不上其该有的价值（股市 价值） 可并鈈是随便一个 Internet 企业都象网景公司那么辉煌。 举杭州西湖的例子吧西湖的一些景点收门票，卖纪念品一年不多的经营收入，只够 用来打掃卫生、 修修补补、 种树植草 但西湖有白居易、 苏东坡巨大的贡献， 千年累积的 “人 文、历史、地理”价值何止千百亿假设杭州西湖仩市，起价 1 亿元人民币真不知道有多 少人来争抢，股值当然会狂升千百倍而我家乡的一个鱼塘也叫“西湖” ，主人从来不幻想 他的“覀湖”值多少个亿但他知道卖不出鱼就会贫穷，一天不争几元钱就会挨饿 接下去说雅虎公司吧。 由于有了浏览