忘记密码   免费注册 查看新帖 | 论坛精华区

ChinaUnix.net

  平台 论坛 博客 认证专区 大话IT 视频 徽章 文库 沙龙 自测 下载 频道自动化运维 虚拟化 储存备份 C/C++ PHP MySQL 嵌入式 Linux系统
123下一页
最近访问板块 发新帖
查看: 18983 | 回复: 25

软件工程思想 [复制链接]

论坛徽章:
0
发表于 2002-03-30 13:42 |显示全部楼层
注:
1)浙大林锐博士的《软件工程思想》一书中的全部8个篇章。这是林锐在自己经营公司不够成功后的深刻总结,值得推荐,他的另一篇文章《大学十年》也很不错。
2)文章中的图片我没有贴。

                软件工程思想
               
目录
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.1.2进度安排24
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需求分析为什么困难44
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系统设计48
6.1体系结构设计49
6.1.1层次结构49
6.1.2客户机/服务器结构51
6.2模块设计53
6.2.1信息隐藏53
6.2.2内聚与耦合54
6.2.3封闭、开放性55
6.3数据结构与算法设计56
6.4用户界面设计57
6.4.1界面设计中美的需求与导向作用57
6.4.2界面美的内涵58
6.5系统设计示例60
6.5.1设计背景60
6.5.2Intra3D 2.061
6.5.3支持协同工作的网络通讯开发系统 CNC 1.064
6.5.4应用示例69
6.6小 结69
7C++面向对象程序设计70
7.1C++面向对象程序设计的重要概念71
7.1.1类与对象72
7.1.2继承与组合73
7.1.3虚函数与多态77
7.2良好的编程风格81
7.2.1命名约定81
7.2.2使用断言82
7.2.3new、delete与指针83
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.2容错性测试94
8.3.3性能与效率测试94
8.3.4易用性测试95
8.3.5文档测试95
8.4改错95
8.5小结96
9维护与再生工程97
9.1软件维护的常识97
9.2维护的代价及其主要因素98
9.3再生工程99
9.3.1重构100
9.3.2逆向工程100
9.3.3前向工程100
9.4小 结100


1 序言、前言
1.1序
《软件工程思想》讲述“软件开发”和“做程序员”的道理,视野独特,构思新颖,内容风趣,不落窠臼,令人耳目一新。堪称难得,以至回味无穷。
作者从事了八年的软件开发工作,在他的博士学位论文完成之际写下了这本“心之所感”。虽然它探讨的是软件工程最常见的内容,但他将亲身所历的感悟写成活泼生动的文字,将软件工程的很多原则和方法融于笑谈之中,让人看得轻松,时有共鸣。尽管很薄,然其内涵不逊于厚近千页的有关教科书。
每次回浙大我都要和林锐相聚,谈学术、论社会,直面人生,“位卑未敢忘忧国”,每每至凌晨。前不久我在某大学计算机系作讲座,最后冒昧谈了几句题外话,其中之一是“学问与明理”。古人云:“读书明理”,意即读书要明白做人的道理。我以为其中的重要内涵,是要有积极的人生观,以贡献社会为己任。这也是我们的共识。林锐曾立誓做一名“真实、正直、优秀的科技人员”。他在自己困难的时候依然资助数名贫困中学生和大学生;常常躬身拾捡被乱扔于地的废纸、塑料袋,以示后生。这都会使很多的学人汗颜有加。
简言之,林锐对软件工程实践的积极思考、轻快而不失深邃的文笔及其言行,都是出色之处。
正由于此,而不仅因为是同行,我才不惭浅陋,接受他的要求,荣幸地成为本书的第一位读者,并在本来应是名人大家留文的地方谈林说森。


董军,2000年2月于
朝夕室


1.2前 言

在60年代计算机发展初期,程序设计是少数聪明人干的事。他们的智力与技能超群,编写的程序既能控制弱智的计算机,又能让别人看不懂、不会用。那个时期编程就跟捏泥巴一样随心所欲,于是他们很过分地把程序的集合称为软件,以便自己开心或伤心时再把程序捏个面目全非。人们就在这种美滋滋的感觉下热情地编程,结果产生了一堆问题:程序质量低下,错误频出,进度延误,费用剧增……。这些问题导致了“软件危机”。
在1968年,一群程序员、计算机科学家与工业界人士聚集一起共商对策。通过借鉴传统工业的成功做法,他们主张通过工程化的方法开发软件来解决软件危机,并冠以“软件工程”这一术语。三十年余年来,尽管软件的一些毛病如人类的感冒一样无法根治,但软件的发展速度超过了任何传统工业,期间并未出现真真的软件危机。这的确是前人的先见之明。如今软件工程成了一门学科。
软件工程主要讲述软件开发的道理,基本上是软件实践者的成功经验和失败教训的总结。软件工程的观念、方法、策略和规范都是朴实无华的,平凡之人皆可领会,关键在于运用。我们不可以把软件工程方法看成是诸葛亮的锦囊妙计─—在出了问题后才打开看看,而应该事先掌握,预料将要出现的问题,控制每个实践环节,并防患于未然。研究软件工程永远做不到理论家那么潇洒:定理证明了,就完事。
我在读大学的十年里有八年从事软件开发,尽管编写了几十万行C++/C程序,也经历了若干次小不点儿大的成功和失败,可老感觉只学了些皮毛,心里慌兮兮的。在博士研究生毕业前的半年里,我告戒自己不应该再稀里糊涂地在程序堆里滚爬下去了,于是就面壁反省,做了一阵子木讷的和尚。在“打坐”时,每有心得体会便记录下来,不知不觉凑成了八章经,我就给此经书起名为《软件工程思想》。
经典的软件工程书籍厚得象砖头,或让人望而却步,或让人看了心事重重。请宽恕我的幼稚,我试图用三个问题:是什么、为什么、怎么办,来解释软件工程的道理。所以本书薄得象饺子皮─—用来包“思想”这种有味道的“馅”。本书的八章经分别为:
第一章“软件工程基本观念”;
第二章“程序员与程序经理”;
第三章“项目计划与质量管理”;
第四章“可行性分析与需求分析”;
第五章“系统设计”;
第六章“C++ 面向对象程序设计”;
第七章“测试与改错”;
第八章“维护与再生工程”。
附录“大学十年”可以充当饭后的水果。
我偶尔也担心此书写得太肤浅,内容少得可怜。就象一只鸡在水里扑腾了几下,并不能产生美味的鸡汤。但是如果您化了几分钟时间翻阅本书的任意章节,您马上就愿意再化几个小时一口气读完全书,并且乐得直拍桌子:“好!很好!非常好!”
您可以把这本科技书当小说看,但在看书时请不要吃东西,免得喷了别人或者呛着自己。
如果您买了本书后觉得不值得,我一定赔偿您的损失。

1.3致 谢

本书并不属于我博士学位论文的研究范畴,但却是我读博士学位三年来写的最有意思的作品。
首先要感谢我的导师,浙江大学计算机辅助设计与图形学(CAD&CG)国家重点实验室的石教英教授。在其他师兄弟正儿八经地“攻读”博士学位时,我“不务正业”地开了一家软件公司。当我摔了一个大跟头灰溜溜地回到陌生的实验室时,石老师仍然热情地帮助我“修成正果”。临近毕业,我心中惭愧,三年来我从来都没给石老师干过活,我这个博士生他算是白招了。我很希望大学里多一些象石老师那样开明而大度的导师。
董军博士是本书的第一位读者。我们是“君子之交”却不“淡如水”,除了漆夜长谈科技、艺术、哲学外,还不忘“吃喝玩乐”享受生活。他在品阅的同时完成了审稿工作。
彭小澎好学上进,尽管她执教的是艺术课程,却很想再学点自然科学。她常听我聊侃软件工程,不知不觉成了本书的第二位读者。她看书时只会“哼”“哈”,从未有沉思状,估计啥也没看懂。小澎是个天真未泯的大孩子,和我称兄道弟,给我带来了很多快乐。有一天中午,我们把浙江大学校门口草坪上的垃圾捡得干干净净,俩人无上光荣。我希望小澎早日“荣升”讲师,再恭敬地叫她彭老师。
北京因特国风网络软件公司的周鸿一是个真正的软件高手。他在我开发软件产品失败时给予了最多的帮助,并指正我在软件设计中存在的根深蒂固的方法错误,使我能尽早地逐步改正。我平时能说会道,但在他面前我哑口无言只有听的份,因为他的才华已全方位地超过了我。我真希望多结识象他这样的朋友。
高振华老先生是个糊涂而可爱的民营企业家,我们是忘年交。我把他干的糊涂事(投资软件公司)写进书里,作为可行性分析的案例。高先生给予我经济上的帮助,使我能够在舒适的环境中开展最后一年博士学位论文工作。尽管我读书的工资每月只有300元,但日子过得象神仙一样舒服。
浙江大学计算机系的杨孟洲、周昆、曾震宇、杨建、白云、金锋等同学和我合作开发软件,给了我很多技术上的帮助。我对他们深表感谢。
特别感谢父母给我起了很好听的名字。读了十年大学,现在我差不多名副其实了。


林锐,2000年2月
于浙江大学CAD&CG国家重点实验室


2 软件工程基本观念


本章讲述软件工程的基本观念,是关于软件工程宏观上的探讨。如果你是软件公司的老板,用不着在第一线工作,那么看这一章就够了。但你一定要让员工们相信不停地工作是人生最大的快乐,并且让他们把本书看完。

1.1节讲述软件工程的目标和常用的软件工程模型。1.2节讲述软件开发的基本策略:“复用”、“分而治之”、“优化——折衷”,有助于指导实践者选择方法和产生新方法。1.3节例举一些不正确的观念,取材于早期软件人员比较幼稚的想法,初学者可以引以为戒。1.4节探讨一些有争议的观念。

看完本章,要树立这样的信念:软件开发过程中的坎坎坷坷,仿佛只是人脸的凹凸不平,用热水毛巾一把就可抹平。让我们高举程序主义、软件工程思想的伟大旗帜,紧密团结在以Microsoft为核心的软件公司周围,沿着比尔·盖茨的生财之道,不分白天黑夜地编程,把建设有中国特色的软件产业的伟大事业全面推向21世纪。

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

软件工程的目标是提高软件的质量与生产率,最终实现软件的工业化生产。质量是软件需求方最关心的问题,用户即使不图物美价廉,也要求个货真价实。生产率是软件供应方最关心的问题,老板和员工都想用更少的时间挣更多的钱。质量与生产率之间有着内在的联系,高生产率必须以质量合格为前提。如果质量不合格,对供需双方都是坏事情。从短期效益看,追求高质量会延长软件开发时间并且增大费用,似乎降低了生产率。从长期效益看,高质量将保证软件开发的全过程更加规范流畅,大大降低了软件的维护代价,实质上是提高了生产率,同时可获得很好的信誉。质量与生产率之间不存在根本的对立,好的软件工程方法可以同时提高质量与生产率。

软件供需双方的代表能在餐桌上谈笑风生,归功于第一线开发人员的辛勤工作。质量与生产率的提高就指望程序员与程序经理。对开发人员而言,如果非得在质量与生产率之间分个主次不可,那么应该是质量第一,生产率第二。这是因为:(1)质量直接体现在软件的每段程序中,高质量自然是开发人员的技术追求,也是职业道德的要求。(2)高质量对所有的用户都有价值,而高生产率只对开发方有意义。(3)如果一开始就追求高生产率,容易使人急功近利,留下隐患。宁可进度慢些,也要保证每个环节的质量,以图长远利益。

软件的质量因素很多,如正确性,性能、可靠性、容错性、易用性、灵活性、可扩充性、可理解性、可维护性等等。有些因素相互重叠,有些则相抵触,真要提高质量可不容易啊!

软件工程的主要环节有:人员管理、项目管理、可行性与需求分析、系统设计、程序设计、测试、维护等,如图1.1所示。

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

最早出现的软件工程模型是线性模型(又称瀑布模型)。线性模型太理想化,太单纯,已不再适合现代的软件开发模式,几乎被业界抛弃。偶而被人提起,都属于被贬对象,未被留一丝惋惜。但我们应该认识到,“线性”是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的“非线性”问题时,总是千方百计地将其分解或转化为一系列简单的线性问题,然后逐个解决。一个软件系统的整体可能是复杂的,而单个子程序总是简单的,可以用线性的方式来实现,否则干活就太累了。线性是一种简洁,简洁就是美。当我们领会了线性的精神,就不要再呆板地套用线性模型的外表,而应该用活它。例如渐增式模型实质就是分段的线性模型,如图1.3所示。螺旋模型则是接连的弯曲了的线性模型。在其它模型中都能够找到线性模型的影子。

套用固定的模型不是程序员的聪明之举。比如“程序设计”与“测试”之间的关系,习惯上总以为程序设计在先,测试在后,如图1.4(a)所示。而对于一些复杂的程序,将测试分为同步测试与总测试更有效,如图1.4(b)所示。


不论是什么软件工程模型,总是少不了图1.1中的各个环节。本书擗开具体的软件工程模型,顺序讲述人员管理、项目管理、可行性与需求分析、系统设计、程序设计、测试,以及维护与再生工程。其中程序设计部分以C++/C语言为例。


2.2软件开发的基本策略

人们都有自己的世界观和方法论,能自然而然地运用于生活和工作中。同样,程序员脑子里的软件工程观念会无形地支配其怎么去做事情。软件工程三十年的发展,已经积累了相当多的方法,但这些方法不是严密的理论。实践人员不应该教条地套用方法,更重要的是学会“选择合适的方法”和“产生新方法”。有谋略才会有好的战术。几千年前,我们的祖先就在打闹之际写下了很多心得体会,被现代人很好地运用于工业和商业。本节讲述软件开发中的三种基本策略:“复用”、“分而治之”、“优化——折衷”。

2.2.1复用

复用就是指“利用现成的东西”,文人称之为“拿来主义”。被复用的对象可以是有形的物体,也可以是无形的成果。复用不是人类懒惰的表现而是智慧的表现。因为人类总是在继承了前人的成果,不断加以利用、改进或创新后才会进步。所以当我们欢度国庆时,要搞清楚祖国远不止50岁,我们今天享用到的财富还有上下五千年人民的贡献。进步只是应该的,不进步则就可耻了。

复用的内涵包括了提高质量与生产率两者。由经验可知,在一个新系统中,大部分的内容是成熟的,只有小部分内容是创新的。一般地可以相信成熟的东西总是比较可靠的(即具有高质量),而大量成熟的工作可以通过复用来快速实现(即具有高生产率)。勤劳并且聪明的人们应该把大部分的时间用在小比例的创新工作上,而把小部分的时间用在大比例的成熟工作中,这样才能把工作做得又快又好。

把复用的思想用于软件开发,称为软件复用。据统计,世上已有1000亿多行程序,无数功能被重写了成千上万次,真是浪费哪。面向对象(Object Oriented)学者的口头禅就是“请不要再发明相同的车轮子了” 。

将具有一定集成度并可以重复使用的软件组成单元称为软构件(Software Component)。软件复用可以表述为:构造新的软件系统可以不必每次从零做起,直接使用已有的软构件,即可组装(或加以合理修改)成新的系统。复用方法合理化并简化了软件开发过程,减少了总的开发工作量与维护代价,既降低了软件的成本又提高了生产率。另一方面,由于软构件是经过反复使用验证的,自身具有较高的质量。因此由软构件组成的新系统也具有较高的质量。利用软构件生产应用软件的过程如图1.5所示。

软件复用不仅要使自己拿来方便,还要让别人拿去方便,是“拿来拿去主义”。面向对象方法,Microsoft公司的COM规范 [Rogerson 1999],都能很好地用于实现大规模的软件复用。



2.2.2分而治之

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

  

图1.6表示了软件领域的分而治之策略。诸如软件的体系结构设计、模块化设计都是分而治之的具体表现。软件的分而治之不可以“硬分硬治”。不像为了吃一个西瓜或是一只鸡,挥刀斩成n块,再把每块塞进嘴里粉碎搅拌,然后交由胃肠来消化吸收,象征复杂问题的西瓜或是鸡也就此消失了。

2.2.3优化——折衷

软件的优化是指优化软件的各个质量因素,如提高运行速度,提高对内存资源的利用率,使用户界面更加友好,使三维图形的真实感更强等等。想做好优化工作,首先要让开发人员都有正确的认识:优化工作不是可有可无的事情,而是必须要做的事情。当优化工作成为一种责任时,程序员才会不断改进软件中的算法,数据结构和程序组织,从而提高软件质量。

著名的3D游戏软件Quake,能够在PC机上实时地绘制高度真实感的复杂场景。Quake的开发者能把很多成熟的图形技术发挥到极致,例如把Bresenham画线、多边形裁剪、树遍历等算法的速度提高近一个数量级。我第一次看到Quake时不仅感到震动,而且深受打击。这个PC游戏软件的技术水平已经远胜于我所见识到的国内领先的图形学相关科研成果。这对我们日益盛行的点到完止的研发工作真是莫大的讽刺。所以当我们开发的软件表现出很多不可救药的病症时,不要怨机器差。真的是我们自己没有把工作做好,写不好字却嫌笔钝。

就假设我们经过思想教育后,精神抖擞,随时准备为优化工作干上六天七夜。但愿意做并不意味着就能把事情做好。优化工作的复杂之处是很多目标存在千丝万缕的关系,可谓数不清理还乱。当不能够使所有的目标都得到优化时,就需要“折衷”策略。

软件中的折衷策略是指通过协调各个质量因素,实现整体质量的最优。就象党支部副书记扮演和事佬的角色:“…为了使整个组织具有最好的战斗力,我们要重用几个人,照顾一些人,在万不得已的情况下委屈一批人”。

软件折衷的重要原则是不能使某一方损失关键的职能,更不可以象“舍鱼而取熊掌”那样抛弃一方。例如3D动画软件的瓶颈通常是速度,但如果为了提高速度而在程序中取消光照明计算,那么场景就会丧失真实感,3D动画也就不再有意义了(如果人类全是色盲,计算机图形学将变得异常简单)。

人都有惰性,如果允许滥用折衷的话,那么一当碰到困难,人们就会用拆东墙补西墙的方式去折衷,不再下苦功去做有意义的优化。所以我们有必要为折衷制定严正的立场:在保证其它因素不差的前提下,使某些因素变得更好。

下面让我们用“优化——折衷”的策略解决“鱼和熊掌不可得兼”的难题。

问题提出:假设鱼每千克10元,熊掌每千克一万元。有个倔脾气的人只有20元钱,非得要吃上一公斤美妙的“熊掌烧鱼”,怎么办?

解决方案:化9元9角9分钱买999克鱼肉,化10元钱买1克熊掌肉,可做一道“熊掌戏鱼”菜。剩下的那一分钱还可建立奖励基金。


2.3一些不正确的观念


本节例举并分析一些不正确的软件工程观念,可帮助初学者少犯相似的错误。


观念之一:我们拥有一套讲述如何开发软件的书籍,书中充满了标准与示例,可以帮助我们解决软件开发中遇到的任何问题。

客观情况:好的参考书无疑能指导我们的工作。充分利用书籍中的方法、技术和技巧,可以有效地解决软件开发中大量常见的问题。但实践者并不能因此依赖于书籍,这是因为:(1)现实的工作中,由于条件千差万别,即使是相当成熟的软件工程规范,常常也无法套用。(2)软件技术日新月异,没有哪一种软件标准能长盛不衰。祖传秘方在某些领域很吃香,而在软件领域则意味着落后。


观念之二:我们拥有最好的开发工具、最好的计算机,一定能做出优秀的软件。

客观情况:良好的开发环境只是产出成果的必要条件,而不是充分条件。如果拥有好环境的是一群庸人,难保他们不干出南辕北辙的事情。


观念之三:如果我们落后于计划,可以增加更多的程序员来解决。

客观情况:软件开发不同于传统的农业生产,人多不见得力量大。如果给落后于计划的项目增添新手,可能会更加延误项目。因为:(1)新手会产生很多新的错误,使项目混乱。(2)老手向新手解释工作以及交流思想都要花费时间,使实际开发时间更少。所以科学的项目计划很重要,不在乎计划能提前多少,重在恰如其分。如果用“大跃进”的方式奔向共产主义,只会产生倒退的后果。


观念之四:既然需求分析很困难,不管三七二十一先把软件做了再说,反正软件是灵活的,随时可以修改。

客观情况:对需求把握得越准确,软件的修修补补就越少。有些需求在一开始时很难确定,在开发过程中要不断地加以改正。软件修改越早代价越少,修改越晚代价越大,就跟治病一样道理。


2.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分类则属四级严重,但这种错误可能导致机毁人亡。

开发人员应该意识到:所有的错误都是严重的,不存在微不足道的错误。这样才能少犯错误。


2.5小 结


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


3程序员与程序经理


工作在第一线的软件开发人员是程序员和程序经理,他们决定着软件的命运。良好的程序员队伍和出色的管理是软件项目成功的必要条件。管理不是管制,不是去卡住人家的脖子,因为程序员不是一群野鸭子。管理的目的是让大家一起把工作做好,并且让各人获得各自的快乐和满足。当一个组织被出色地领导时,雇员甚至不知道他们已被领导。在项目完成时,他们会自豪地说:“看看我们通过努力取得的成绩吧”。所以管理者不能老惦记着自己是一个官,而应时刻意识到自己是责任的主要承担者。

我们经常会听到有经理头衔的人在高谈阔论:“编程我不会,做个项目还不easy?派个人去搞系统分析,回头再叫几个程序员把需求译成程序,不就OK了吗?”

不懂英语的人准以为easy和OK是贬义词。要让软件项目失败很容易,只要符合下列条件之一即可:

(1)项目经理对软件一无所知;

(2)技术负责人对编程不感兴趣;

(3)真真编写代码的程序员是临时雇用的。

如果上述三个条件同时具备,就请放心失败好了。

让我们少幻想自己是比尔·盖茨,先当好程序员和程序经理再说。



3.1了解程序员



早期的程序员干活能从软件直通硬件,个个生猛无比。又因他们的作息时间、言行举止与常人不太一样,久而久之就给人们留下了“神秘”、“孤僻”的印象。如今软件行业被炒得热火朝天,有能耐的程序员即便躲在大山岙的军工厂里也能被挖出来。而更多原本不是程序员的人操起几本“速成”、“二十一天通”等书籍也加入了这个行业。现在国内号称有上百万程序员,这支大军鱼龙混杂,已搞不清那些是正规军,那些是民兵游击队了。

真正的程序员都有如下秉性:

一、诚实

程序员在学习与工作期间几乎天天与机器打交道,压根就没有受欺骗或欺骗人的机会。勤奋的程序员在调试无穷多的程序Bug时,已经深深地接受了“诚实”的教育。不诚实的人,他肯定不想做、也做不好程序员。

有一名市场营销员和一名程序员都在新闻发布会上发言,将一项新技术的消息公布于众。

市场营销员说:“这项技术比电话、晶体管和原子弹三项发明加起来对世界文明的影响都要大。”

程序员说:“这项技术在有限的领域内,在有限的程度上,解决了一些技术性的问题。”

看来为了让我们的民族更加诚实,学电脑真的要从娃娃抓起。

二、简单——实用主义

有人问一个数学家,一个物理学家和一名程序员:“一个盒子有几个面?”

数学家回答说:“有六个面,因为盒子是长方体。”

物理学家回答说:“有12个面,分为6个外表面和6个内表面 。”

程序员回答说:“只有两个面,里面放电路板和硬盘,外面放显示器和键盘。”

目前即使最先进的计算机也不具备智能,程序员的基本工作就是把复杂的问题转化为计算机能处理的简单的程序。如果一个问题复杂到连程序员自己都不能理解,他就无法编出程序让更笨的计算机来处理。所以程序员信奉“简单——实用”主义。

也有不少做计算机“学问”的人颠倒行事。本来几句话、几行程序就能说明白的事,非得要抬高到理论创新的程度,写成玄乎的文章去评教授或者弄个博士学位。所幸在第一线工作的程序员大多是实干的。

三、爱憎分明

程序员大都喜欢技术挑战,不喜欢搞测试与维护。高水平的程序员喜欢与高水平的程序员一起工作,因为他们怕“与臭棋佬下棋,棋越下越臭”。程序员大都厌恶拉帮结派、耍政治手腕。不信,数一数你认识的程序员,有几个是党派人士?

四、工作单调但不乏味

有人问编程大师:“程序设计的真正含义是什么 ?”

大师回答说:“饿了的时候就吃,困的时候就睡,只要时机恰当就进行程序设计。”

其实程序员的生活和工作已融为一体,尽管单调却不乏味,还能独享孤独。有诗为证:

我编程三日

两耳不闻人声

只有硬盘在歌唱



结论:优秀的程序员没有理由不让人喜欢,他们远比怪僻来得可爱。



3.2了解程序经理



这里程序经理是指一支程序员队伍的领导者,不管他的职务是开发组长,项目经理,还是部门经理。程序经理是技术性的基层或中层干部,是软件企业得以发展的生力军。程序经理的选拔是不容草率的事。不象有些事业单位,只要政治口号喊得勤快、能左右逢缘不犯错误就可混个领导当当。也不象一些官僚机构,只有两个人的办公室也要设正主任和副主任。如果碰巧正主任姓傅,副主任姓郑,还会斗个没完没了。

在一个管理混乱的软件公司里,如果某个程序员能大喊大叫并且干劲十足,那他就能成为一名程序经理。微软公司在选择经理人员时,总是把他们的技术知识和运用技术去赚钱的能力放在首位。程序经理一般就是程序员队伍中最聪明的那个家伙。比尔·盖茨曾这样描述聪明人[Cusumano1996]:

聪明人一定反应敏捷,善于接受新事物。他能迅速进入一个新领域,给你一个头头是道的解释。他提出的问题往往一针见血、击中要害。他能及时掌握所学知识,并且博闻强记,他能把本来认为互不相干的领域联系在一起使问题得到解决。他富有创新精神与合作精神……

好的程序经理应该具备以下几个条件:

一、技术水平是程序员队伍中的最高级别

每个程序员骨子里头都有一股傲气,如果你不能技压群雄,他们就不会听你指挥。一个技术水平较差的人被任命为程序经理真是个悲剧,就象一个略有权势的太监,表面上有人对他点头哈腰,背后却被人鄙视。

二、能做最多且最难的工作

程序经理编程要快且好。别人要干一天的活,他半天就能做完,这样才会有精力去搞管理。程序经理应负责系统分析、系统设计这类最难的开发工作,并指导不同水平的程序员把各自的工作做好。如果人手不够,程序经理要能同时干几个人的活。

三、有人格魅力

软件开发是智力创作过程,你不能指望仅通过执行规章制度来产生好的作品。很多软件公司的程序经理都不是管理专业出身的,他们也不可能为了搞好管理而成天玩弄心机。技术出色的程序经理一般少有心术不正的,所以管理的重点应是“以身作则”、“公正待人”。如果程序经理在上班时趴在桌上睡觉,其他程序员也会这样干。如果程序经理发现有两个程序员趴在机器旁睡觉,不能只对其中一个大声吼叫:“你一编程就想睡觉,看看人家,在睡觉时都想着编程。”

如果管理者没有人格魅力,就没有人信服你,团队就不会有凝聚力,乌合之众不可能开发出优秀的软件。

结论:一个有活力的软件公司的各级经理都不会这样感叹,“因为我啥也不会干,所以只好当领导。”



3.3程序员升为经理后是否还要编程



让我们先看看Microsoft公司的系统软件部门与应用软件部门的领导是怎样看待这个问题的[Cusumano1996]。Windows NT 3.0项目的软件经理娄·帕雷罗里让他手下的经理们像他一样每天花一半的时间编写代码:

我在组内制定了许多规则,其中最重要的一条是每个人都得编程,谁也别想坐在那儿发号施令……我发现管理者很容易失去目标,他们总是无法认识到问题的本质并且反应迟缓。如果你始终不放弃编写代码,你就能对项目的进展情况了如指掌,及时发现并解决问题……我大概每天花一半的时间编写代码并寻找项目的缺陷。

作为应用软件领域的经理,克里斯·彼得斯也持同样的看法。在他任Word项目总经理时就认为:

在一些大公司内部,各部门经理把具体操作的层次向下移。你一旦当上开发部门经理,很快就会以自己身居高位、日理万机为由放弃编程;同样地,开发小组的组长会以自己重任在肩而不愿编程;至于程序员也会觉得自己十分繁忙、分身无术而不再多编写程序。虽然我是270名员工的领导,似乎不再需要做什么具体的工作了,但我还是为Word新版本编写了一个特性。

程序员升为经理后一定要编程,这个道理已经说得很清楚了。最怕的是“虚心接受,坚决不做”;或者仅是做个样子,每天花一分钟时间编程,编译器还没运行完就关掉了。



3.4经理与技术队伍的建设



如果是经营一个加工厂或一个饭店,经理们可以不必懂技术。因为他们的常识,以及通过耳闻目睹或者咨询都能解决实践中的问题。在软件领域,技术的力量是无穷的,一天之内就可使整个产业发生巨变。也许你在商业上很精明,但无法保证自己在技术浪潮中安然无恙。软件公司的各级经理最好既精通技术又懂管理。

一个出色的领导,加上一支技术过硬的队伍,才有可能创造业绩。不能光指望请来孙子或诸葛亮当教练,就能让弱不禁风的男足去捧世界杯。不少人总喜欢自吹中国人很聪明,最适合搞软件开发。可至今也没有做出几个很光彩的软件来,这与十三亿人口不呼应啊。新中国历来喜欢与可怜的印度相比较来展现丰富多彩的优越性,可是软件产业没法与人家比。工作在第一线的程序员与程序经理应该意识到:好兵好将都不是天生的,是后天练出来的;既要学会冷静地分析问题,又要充满激情地去工作。

软件公司总希望能物色到既精通技术又善长商业的优秀人才做经理。但已经出名了的优秀人才难以请到,也难以留住。所以把公司中的普通员工培养成为优秀人才是重要的举措。公司的老板不要对程序员抱有偏见,以为他们只配与机器打交道。一个高水平的程序员既然能学好数字逻辑,能理得清楚软件中很多象“嵌套”这类“鸡生蛋并且蛋又生了鸡”的错综复杂的关系,从理论上讲当个县长也不成问题。

现在很多女士不会烧菜,却能把菜的营养讲得头头是道。虽然这是个值得哀叹的社会问题,但我们应该有信心期待:如果她们非得天天烧菜不可,那么不久就能把菜烧得又好吃又有营养。许多程序员不懂商业,不是智力上的原因,主要是个人兴趣和环境所致。软件公司的老板应该这样鼓励有灵气的员工:“你能把技术做得那么棒,还怕搞不好管理?放心干吧!”的确,很多技术人员是在工作中领悟如何管理的,他们经过挫折与磨练,逐渐升为组长、项目经理,乃至成为公司重要的决策者。

优秀的程序员喜欢与优秀的程序员一起工作,这是一种理想的愿望。一个普通的软件公司不可能有非常多的优秀程序员,即便有,他们也不可能天天聚在一起干同一件事并且和睦得无法形容。中国自封建社会起就有喜好内斗的风俗习惯,几千年下来早已渗透到社会各个角落,那怕黄河水流断了,估计这民风也会延袭下去。要使程序员队伍稳健,必须有合理的等级制度来维护。等级制度并不限制自由和民主,它能让自以为聪明绝顶、谁也不服的人们懂得如何合作与奋斗。就象有了一架梯子,每个人才有机会爬上墙头摘下那向往已久的野花。当梯子散成一堆木棍时,只可能造就几个卖炭翁。

下面我们尝试着建立一个程序员队伍的等级制度。

把技术水平分为四级,第一级最低,第四级最高。第一级技术水平的程序员主要考核编程基本功,要求质量合格(他们主要来自刚毕业的大学生)。第二级技术水平的程序员编程质量要高,做过几个软件项目,有数年的工作经验,并能指导新手的工作。第三级技术水平的程序员主要考核系统分析与系统设计的能力,要求其技术有足够的深度和广度。第四级技术水平的程序员是成功的软件产品的设计师,他不仅技术超群,并且能使技术转化为有价值的商品。

把管理(这里仅指软件业务的管理,不考虑行政事务)水平也分成四级。第零级最低,第三级最高。第零级管理水平的人没有管理职务,就是普通员工。第一级管理水平的人是开发小组的组长,可带领几名程序员工作。第二级管理水平的人是项目经理。第三级管理水平的人决定某些产品是否要开发,以及如何去占领市场。

每个程序员都有明确的技术级别和管理级别。技术级别与管理级别有一定的联系。一般地,第一级技术水平的人只能做普通员工;第二级技术水平的人可以当一名组长;第三级技术水平的人可以当一名项目经理;第四级技术水平的人可成为公司产品的决策者。如图2.1所示。本书作者目前的技术水平当属第二级,管理水平符合组长的要求。作者在读中学和大学时就曾美滋滋地当过课代表,也就是组长级别。



3.5向错误与失败学习

不管是生活或工作,人们都应该向错误与失败学习,目的是让我们在短暂的健康年华中少犯错误、少失败,多做几件正确的对社会有贡献的事。

导致软件项目失败的因素很多,如果不去找借口的话,就会发现错误的根源在自己身上:知识贫乏、才能低下、经验不足、骄傲自负……。我们必须正视自身的不足与缺点,才会学到经验教训。可人们常有太多的虚荣,为了克服心理障碍,白白浪费了很多本该用于创造的精力。

假设犯错误的人是诚实的并且是勤奋的。他愿意不带虚荣地改进自己。当这个人突然面对失败时,可能觉得自己一无是处,也许会不知所措,也许会病急乱投医。程序员都有一种共同的体会:在调试程序时,时常碰到只有十几行的程序竟会产生上百个编译错误;最后发现这么多的错误其实是由某一行程序错误引发的。当我们在工作中碰到挫折时,先要冷静地分析问题(事出有因哪),找出问题的内因与外因。内因是最主要的,应该予以最先解决。

前几年,中国出现了一个叫“法轮功”的邪教,教徒达数百万之多,人民群众深受其害。不久前,全国的主要媒体对“法轮功”进行连续数月的声讨与揭露。目睹了很多受害人的哭诉后,相信人们能够明白“法轮功”是邪恶的、反动的。但在愤怒与心痛之余,我们不禁要反思:为什么那么多人轻信邪教?人们是否接受了教训?

在电视上看到很多人的确作了深刻的检讨:“我真是后悔啊,跟错了李洪志(法轮功的头头)这个坏蛋,我对不起社会……。以后我一定要听党组织的话,党叫我干什么我就干什么,决不上坏人的当。”

我觉得这些受害人一点都没有醒悟:他只知道法轮功是个邪教,并不知道自己为什么信了邪教。有些事情只要用脑袋去想一想就能分辨是非,可人们就是不去思考,却渴望能跟对“福星”,甘愿把自己的脑袋拴在别人的裤带上。难道这就是人民的纯朴与可爱吗?回顾一下历史,在“文革”时期,亿万人民跟着合法的党组织大干伤天害理的事,一干就是十多年哪!可见世界上哪个人哪个组织都不能确保绝对的英明。

所以说“迷信”是傻子碰到骗子的结果。傻是内因,被骗是外因。傻子碰到好人未必能做出好事,傻子碰到另一个骗子就会做出另一件傻事。为了不让自己“傻”,善良的人们应该用脑子去多学一些知识,努力让自己来把握命运,不要急着把一生托给某个人或某个组织。

软件人员在遭受项目失败并开始反省时,不要只是就事论事地仅把眼光锁在特定的项目上,吃一堑应该长好几个智才对。本书作者刚刚失败过,乐意乘热讲讲感受。

我在读本科和硕士研究生时,一直信奉“创造性的事业要靠激情来推动”。我把这个口号贴在办公室里,并扔掉物理学专业天天编程。在读硕士研究生的第一年,我卖出了第一份软件。到我读博士研究生的第一年,我心想事成地获得了全国大学生电脑大赛软件展示第一名。那时候我自以为翅膀已经硬了,再回顾前些年的艰苦,不禁有“媳妇熬成婆”的悲壮感觉。于是我在杭州这个小地方略作宣传,在1997年10月份开了一家软件公司。

我开始把“振兴民族软件产业”列入日程,并且提前担忧将来钱挣得太多用不完该怎么办。半年之后,我开始为软件产品作宣传,可并没有出现订单如潮、接应不暇的形势(事实上压根就没有反应)。我已经意识到市场没找对,但仍觉得软件中的技术很有价值,准备再开创“东方不亮西方亮”的新局面。于是我向只有一面之缘尚在北大方正工作的一位朋友求助。他是真真的软件高手,当我小心翼翼地展示约10万行C++代码的软件时,他竞在十几分钟内就指出多处重大的设计错误,使我目瞪口呆地意识到整个软件系统的价值为零。那种心痛啊,就象眼睁睁看着孩子被狼吃掉一样。

1998年10月,这位朋友再一次从北京飞到杭州,三下五除二替我把只活了一年的公司给关闭掉。他放心不下,觉得我“恶病需用猛药补”,于是意尤未尽地把我捉到北大方正插在他管辖的部门,让我学习怎样做事情。北京寒冷的冬天可以营造一种凄凉的气氛,冲去一切可以自我原谅的借口。我并不是太爱虚荣的人,知道这次失败是我的毛病积累到一定水准忍不住喷发出来的结果。我绝不能以年纪尚轻不太懂市场与管理为理由轻率地敷衍过去。我把自己察觉到的数十个毛病列出来,日后一个一个克服掉。……本书的大部分内容取自我在一年前的教训录。

改错之后,现在我不仅不难过而且挺快乐。觉得第一次失败很浪漫,值得怀念。刚开始写这本书时,我那位北京的朋友把脚伸到杭州来散步,顺手又给了我几帖药,可以用到我毕业。看来缺点是改不完的,补短和扬长要一起来。

3.6提高综合素责

前面给软件开发人员加了过多的赞誉。一个技术出色的程序员可以自豪,但不可以目空一切。上天不可能赋于一个人太多的优点,以致于他没有表示谦虚的余地。

我们在求学时可能太功利太挑剔,导致知识结构非常单薄,只怕到了晚年也成不了大器。当程序员擅长技术时,还要时刻留意弥补自己并不擅长的非技术才能。扬长补短才能提高综合素质。

假如能回到中学时代,我希望能把文科学好。那时侯盛传“学好数理化,走遍天下都不怕”。我读中学时很无知,鄙视一切文科,现在后悔莫及。高考语文成绩54分(只比我的期望值低6分)。写作文的最高目标就是不逃题,考试前我总是反复祈祷:我没干过坏事,保佑我作文不逃题吧!上大学的第一天我竟然无法用普通话说出“去洗澡怎么走”,只好晃动澡票与辅导员打哑语。中学的历史、地理课也被我糟踏了,考试时只会填写任课老师某年某月某日在我家乡英勇就义,比谁的成绩更接近零分。更让我沮丧的是,这些行径都不是我发明的,我顶多是个跟屁虫而已,一点回忆的自豪感都没有。

扔掉文科只学理科并不等同于“放下包袱,轻装前进”,倒象是摘掉了控制系统的机车,开不了多远就翻车了。我搞了八年的软件开发,没做出象样的软件来。倒是有同行意外发现我的文笔不错,是当作家的料。我发现自己在不该开花的地方结了一颗瘦涩的果子。曹操之子曹彰曾建议:“大丈夫当学卫青、霍去病,立功沙漠,长驱数十万众,纵横天下,何能为博士耶?”要后悔的事情太多了,只能现在做得勤快些。明知自己不成大器,但愿意亡羊补牢,力求学得更深更广。

不要让人觉得程序员只管钻研技术,可以不懂世事并且应该自由散漫。程序员不该因为幼稚而显得单纯,应该是成熟了才变得单纯,才配得上这个充满活力的职业。


3.7小结

本章讲述做好程序员和程序经理的一些道理,为了剥去阻碍我们进步的那些虚伪,多唠叨了几个故事。

中国经历了很多打斗、整人的革命,却没有一次赶上工业革命。在如今计算机横行的形势下,我们不能再掉队了。90年代初期,中国出现了一些程序员英雄,曾让我们激动过、崇拜过。但这些孤胆英雄们很快地几乎全消亡了,他们只留下故事,没留下更多的价值。再一次让我们意识到“振兴民族软件产业”不能依靠几个人一朝一夕的辉煌。软件人员勤奋学习和工作,不该只图将来能做成几件事情的快意,而应力求事业长盛不衰,才能推动整个民族软件产业持久稳健地发展。

4 项目计划与质量管理

在可行性分析之后,项目计划与质量管理将贯穿需求分析、系统设计、程序设计、测试、维护等软件工程环节。

项目计划是要提供一份合理的进程表,让所有开发人员任务明确、步调一致,最终共同准时地完成项目。项目计划是要付诸实施的,不象用嘴巴喊政治口号,可以很夸张。软件的项目计划重在“准确”而非“快速”。

提高质量是软件工程的主要目标。但由于软件开发是一种智力创作活动,很难象传统工业那样通过执行严格的操作规范来保证软件产品的质量。世上最小心翼翼、最老实巴脚的程序员未必就能开发出高质量的软件来。程序员必须了解软件质量的方方面面(称为质量因素),如正确性、性能、易用性、灵活性、可复用性、可理解性等等,才能在进行系统设计、程序设计时将高质量内建其中。软件的高质量并不是“管理”出来的,实质上是设计出来的,质量的管理只是一种预防和认证的手段而已。

4.1 项目计划

做项目计划,如同给一个待出生的婴儿写传记那样困难。如果允许项目结束后再写计划,那就轻松多了,并且可以100% 地准确。

历史教训让我们明白一个道理:如果一万年以后才会有一条阳光大道通向共产主义,那么现在就不要忙着砸锅炼钢赶英超美,免得在跑步奔向共产主义时把自己累死饿死。在做软件的项目计划时,应屏弃一切浮夸作风。只有“知已知彼”才能做出合理的项目计划。这里“知彼”是指要了解项目的规模、难度与时间限制。“知已”是指要了解有多少可用资源,如可调用的程序员有几个?他们的水平如何?软硬件设施如何?



4.1.1知己知彼

首先要了解项目的规模、难度与时间限制,才可以确定应该投入多少人力、物力去做这个项目。在可行性分析阶段就要考虑这个问题。但不幸的是,人们在陷入项目不能自拨之前总难以准确地估计项目的规模与难度。这里经验起到了最重要的作用。

项目的时间限制有两类。第一类,项目应该完成的日期写在合同中,如果延期了,则开发方要作出相应的赔偿。第二类是开发自己的软件产品,虽然只确定了该产品大致的发行日期并允许有延误,但如果拖延太久则会失去商机造成损失。

项目的资源分为三类:“人”、“可复用的软构件”和“软硬件环境”,如图3.1所示。(1)人是最有价值的资源。项目计划的制定者要确定开发人员的名单,要根据他们的专长进行分工。

(2)可复用的软构件是次有价值的资源。1.2.1节论述了复用软构件可提高软件的质量与生产率。软构件并非一定要用自己的,可以向专业的软件供应商购买。

(3)软硬件环境虽然不是最重要的资源,却是必需的资源。原则上软硬件环境只要符合项目的开发要求即可。有些项目可能要用到特殊的设备,则要事先作好准备,以免用时找不到而担搁了进程。




4.1.2进度安排

有一位程序员忙着编写程序,经理问他还需要多久才能完成。

“明天就可以完成。”程序员立即回答。

“我想这是不切实际的,实话实说,到底还要多少时间?”经理说。

“我还想加进一些新的功能,这需要花两个星期。”程序员想了一会儿说。

“即使这样也期望过高了,只要你编完程序时告诉我一声,我也就满足了。”经理说。

几年以后,经理要退休了。在他去退休午餐会时,发现那位程序员正趴在机器旁睡觉:可怜的家伙整个晚上都在忙于编写那个程序。[James 1999]

程序员也期望每天早晨能在7:00准时起床,可老是一觉醒来就到中午了。项目落后于进度表乃是家常便饭,不必大惊小怪。以下一些事件经常会导致项目被延误:

(1)上级领导主管臆断,制定了不现实的期限。项目经理与程序员们被迫按照不合理的进度表开展工作。

(2)客户的需求发生了变化,但没有对进度表作出相应的修改。

(3)低估了项目的规模与难度,导致投入的人力和物力不足。

(4)并未预见到存在难以克服的技术障碍。

(5)并未预见到开发人员会发生问题,如生病,辞职等等。

(6)开发人员之间不能很好的交流、协作,导致各阶段任务难以如期完成。

所以写进程表不能象小学生写决心书那样充满幻想。以下是一些有益的建议:

(1)制定进度表的人最好就是项目负责人,他最了解项目和开发人员。进度表要经过开发小组的讨论,在得到大部数人的支持后才能实施。避免出现一厢情愿的局面。

(2)进度安排并不见得一定要符合逻辑顺序。应尽可能地先做技术难度高的事,后做难度低的事。也就是辛苦在前,轻松在后。

小时候我对一位老先生吃饭很感兴趣:他总是先把一大盒的米饭吃光了,然后再幸福地品尝一小盒菜。父母告诉我这是中国的传统美德,叫“先苦后甜”。从此我铭记在心,按此道理去学习和工作。可如今在饭店里,人们总是先把菜吃完了,最后才吃点米饭。天哪,生活真是太复杂了,我究竟该“先吃饭” 还是“先吃菜”?

(3)开发一个大的软件项目,应该将进度表分为若干个里程碑。一个里程碑之内的多个任务可以同步进行。程序员极容易沉迷于技术,要么乐不思蜀,要么焦头烂额。里程碑就象心灵的灯塔,使忙碌的人群不混乱,不迷失方向。

(4)进度表中必须留有缓冲时间,并将缓冲时间用到不确定的事情上。因为人们对即将要做的事情知之甚少,所以要留一些时间以防不测。Microsoft公司的一些开发小组甚至制定了“50% 缓冲规则”[Cusumano 1996]。对许多项目经理而言,容忍进度表中存在缓冲时间,不啻为观念上的一个飞跃。

(5)如果发现项目应交付的期限非常不合理,就要跟领导或跟客户据理力争,请求放宽期限、调整进度。当客户的需求发生变化时,就要对进度表作出相应的修正。不要觉得修改进度表很困难很麻烦,不修改才会产生真真的麻烦。很多人认为戒烟很困难,但马克·吐温曾说:“戒烟很容易,我一年就戒几十次。”



4.2零缺陷质量管理的观念


“零缺陷”质量管理的观念来源于一些国际上著名的硬件生产厂商。尽管软件的开发与硬件生产有极大的差别,但我们仍可以从“零缺陷”质量管理中得到启迪。“零缺陷”质量管理至少有两个核心内容:一是高目标,二是可执行的规范。


4.2.1高目标

人在做一件事情时,由于存在很多不确定的因素,一般不可能100% 地达到目标。假设平常人做事能完成目标的80%。如果某个人的目标是100分,那么他最终成绩可达80分。如果某个人的目标只是60分,那么他最终成绩只有48分。我们在考场上身经百战,很清楚那些只想混及格的学生通常都不会及格,那些想得高分的学生也常为自己的失误而捶胸顿足。

做一个项目通常需要多个人的协作。假设项目的总质量(最高为1)是十个开发人员的工作质量之积。如果每个人的质量目标是0.95,那么十个人的累积质量不会超过0.19。如果每个人的质量目标是0.9分,那么十个人的累积质量不会超过0.03。只有每个人都做到1,项目总质量才会是1。

如果没有高目标,人的堕落就很快。如果没有“零缺陷”的质量目标,也许缺陷就会成堆。



4.2.2可执行的规范

实现100分显然比实现80分要付出更多的努力。“零缺陷”质量目标不是随心所欲提出来的,做得到才有意义。实现高目标需要一套可执行的规范来保证。

50年代末,全国掀起了“浮夸风”。为了实现亩产数万斤推广各种方法,害得全国闹饥荒。想不到有数千年种粮经验的几亿中国农民就这么整齐地栽倒了。

好规范必须是本企业有能力执行的。一个普通企业照搬一流企业的规范未必行得通。软件工程的规范很容易从书籍中找到,但有了这些规范并不表明就能把软件做好。国内很多软件公司根本没有条件去执行业界推荐的软件工程规范。社会主义初级阶段的“草”与发达资本主义国家的“苗”的确有不同的培育方式。



软件是如此的灵活,如果没有规范来制约,就容易因无序的喜好而导致混沌;但规范如果太严密了,就会扼杀程序员生机勃勃的创造力。制定软件规范是进退两难的事。程序员必须深入了解软件多方面的质量因素,把那些能提高软件质量因素的各种规范植入脑中,才能在各个实践环节自然而然地把高质量设计到软件中。



4.3软件的质量因素



“运行正确”的程序就是高质量的程序吗?

不贪污的官就是好官吗?

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

“运行正确”的程序不见得就是高质量的程序。这个程序也许运行速度很低并且浪费内存;也许代码写得一塌糊涂,除了开发者本人谁也看不懂也不会使用。正确性只是反映软件质量的一个因素而已。

软件的质量因素很多,如正确性、精确性、可靠性、容错性、性能、效率、易用性、可理解性、简洁性、可复用性、可扩充性、兼容性等等(还可以列出十几个)。这些质量因素之间“你中有我,我中有他”,非常缠绵。如果程序员每天要面对那么多质量因素咬文嚼字,不久就会迂腐得象孔乙已,并且有找不到女朋友的危险。

为了便于理解,可以参照武侠小说中的武学分类,将质量因素粗略地分成几大派。你想那武学源源流长,相互渗透,谁能数得清有多少江湖派别。但想在道上混,总得知道六大门派:“少林派”、“武当派”、“峨嵋派”、“华山派”、“昆仑派”和“崆峒派”。软件质量因素的分类如图3.2所示。其中“正确性与精确性”排在首位,地位如同“少林派”与“武当派”;而“性能与效率”,“易用性”,“可理解性与简洁性”和“可复用性与可扩充性”亦是举足轻重的质量因素,地位仿佛“峨嵋派”,“华山派”,“昆仑派”和“崆峒派”。其它的质量因素总可以在图3.2中找到合适的亲缘关系,本节不再一一细表。



4.3.1正确性与精确性

正确性与精确性之所以排在质量因素的第一位,是因为如果软件运行不正确或者不精确,就会给用户造成不便甚至造成损失。机器不会主动欺骗人,软件运行不正确或者不精确一般都是人造成的。即使一个软件能100% 地按需求规格执行,但是如果需求分析错了,那么对客户而言这个软件也存在错误。即使需求分析完全符合客户的要求,但是如果软件没有100% 地按需求规格执行,那么这个软件也存在错误。开发一个大的软件项目,程序员要为“正确”、“精确”四个字竭尽精力。

与正确性、精确性相关的质量因素是容错性和可靠性。

容错性首先承认软件系统存在不正确与不精确的因素,为了防止潜在的不正确与不精确因素引发灾难,系统为此设计了安全措施。在一些高风险的软件系统,如航空航天、武器、金融等系统中,容错性设计非常重要。

可靠性是指在一定的环境下,在给定的时间内,系统不发生故障的概率。可靠性本来是硬件领域的术语。比如某个电子设备,一开始工作很正常,但由于工作中器件的物理性质会发生变化(如发热),慢慢地系统就会失常。所以一个设计完全正确的硬件系统,在工作中未必就是可靠的。软件在运行时不会发生物理性质的变化,人们常以为如果软件的某个功能是正确的,那么它一辈子都是正确的。可是我们无法对软件进行彻底地测试,无法根除软件中潜在的错误。平时软件运行得好好的,说不准哪一天就不正常了,如“2000年”问题。因此把可靠性引入软件领域是有意义的。我曾买了一本关于软件可靠性的著作,此书充满了数学公式。我发现以我目前的学历实在难以看懂书上讲了些什么。请宽恕我的愚昧,我把此书给“供”起来,没敢用笔画一处记号。



4.3.2性能与效率

用户都希望软件的运行速度高些(高性能),并且占用资源少些(高效率)。旧社会地主就是这么对待长工的:干活要快点,吃得要少点。程序员可以通过优化算法、数据结构和代码组织来提高软件系统的性能与效率。优化的关键工作是找出限制性能与效率的“瓶颈”,不要在无关痛痒的地方瞎忙乎。如果你想职称升得快,光靠增加课时能顶屁用;你就该一年写它几十篇文章,争取破格升教授。



4.3.3易用性

易用性是指用户感觉使用软件的难易程度。用户可能是操作软件的最终用户,也可能是那些要使用源代码的程序员。现代人的生活节奏快,干啥事都想图个方便。所以把易用性作为重要的质量因素无可非议。

导致软件易用性差的根本原因是开发人员犯了“错位”的毛病:他以为只要自己用起来方便,用户也一定会满意。俗话说“王婆卖瓜,自卖自夸”。当程序员向用户展示软件时,常会得意地讲:“这个软件非常好用,我操作给你看,……是很好用吧!”软件的易用性要让用户来评价。当用户真的感到软件很好用时,一股温暖的感觉油然而生,于是就用“友好”来评价易用性。

4.3.4可理解性与简洁性

可理解性表达了人们一种质朴的愿望:我化钱买了它,总得让我明白它是什么东西。我小时候的一个伙伴在读中学时,就因无法理解电荷之分正负,觉得很烦恼,便早早地缀学当工人。

可理解性也是对用户而言的。开发人员只有在自己思路清晰时才可能写出让别人能理解的程序。编程时还要注意不可滥用技巧,应该用自然的方式编程。我们的确不知道自己的得意之举究竟是锦上添花,还是画蛇添足。就象蒸出一笼馒头,在上面插一朵鲜花,本想弄点诗情画意,却让人误以为那是一堆热气腾腾的牛粪。

简洁是一种美,不管是自己还是用户都会有同感。在生活中,与简洁对立的是“罗里罗嗦”。中国小说中最“婆婆妈妈”的男人是唐僧。有一项民意调查:如果世上只有唐僧、孙悟空、猪八戒和沙僧这四类男人,你要嫁给哪一类?请列出优先级。调查结果表明,现代女性毫不例外地把唐僧摆在老末。

一个原始的应用问题可能很复杂,但高水平的人就能够把软件系统设计得很简洁。如果软件系统臃肿不堪,它迟早会出问题。简洁是人们对工作“精益求精”的结果。

废话大师有句名言:“如果我令你过于轻松地明白了,那你一定是误解了我说的话。”我最近有一种奇怪的体会:如果把学术文章写得很简洁,让人很容易理解,它往往中不了;只有加上一些玄乎的东西,把本来简单的弄成复杂的,才会增加投稿的命中率。事实上,我可以在5分钟之内说清楚三年来读博所做的工作,根本用不着写100多页的博士论文。我是在临近毕业时,才发觉自己完全不适合读博士学位。将来工作后,我一定要好好编程,重新做人。



4.3.5可复用性与可扩充性

复用的一种方式是原封不动地使用现成的软构件,另一种方式是对现成的软构件进行必要的扩充后再使用。可复用性好的程序一般也具有良好的可扩充性。本书第六章将论述如何设计可复用、可扩充的C++程序。



4.4质量检查

检查是人们不信任自己和别人的一种行为。当某些事情涉及到利益分配时,更需要有检查活动来保证公平。估计即使进入了共产主义社会,也少不了检查。

质量检查并不是要等到项目结束时才执行唯一的一次,应该在每个实践环节都要执行。对应于进度表,在每个里程碑到达时执行质量检查比较合理。质量检查的内容有二:一是作出评审,是合格还是不合格?能打多少分?二是作出建议,对质量为什么好为什么差进行分析,以便“改差为好”、“好上加好”。

以下是人们经常采用的软件质量检查措施[Pressman 1999]:

(1)事先把检查的主要内容制成一张表,使检查活动集中在主要问题上。

(2)只评审工作,不评审开发者。评审的气氛应该是融洽的。存在的错误应该被有礼貌地指出来,任何人的意见都不应被阻挠或小看。

(3)建立一个议事日程并遵循它。检查过程不能放任自由,必须排照既定的方向和日程进行。

(4)不要化太多的时间争论和辩驳。

(5)说清楚问题所在,但不要企图当场解决所有问题。

(6)对检查人员进行适当的培训。

……

做好检查工作并不是件容易的事。自古以来“上有政策,下有对策”。 虚假的质量检查还不如不检查,下面讲两个故事作为解释。



故事一

不久前我回到西北那所读了六年多的大学,惊奇地发现校园里房前屋后长满了待收割的小麦!这所大学是从事电子科技的,种小麦干啥呀?朱总理曾讲过:“目前国家粮食充足,再来三年自然灾害也不怕。”现在国泰民安,似乎用不着“深挖洞,广积粮”。我素知学校提创勤俭节约、自力更生,但与其种小麦还不如种蔬菜呢。老同学告诉我,种小麦是为了应付“211”工程(为21世纪选拔100所重点大学)的检查团,因为“211”工程有较高的绿化指标。偏偏检查赶在冬天,那时的西北极难长草。我那所大学本来就人多地少,地上一长草马上就会被谈恋爱的学生给折磨死。一到冬天,整个校园就光秃秃一片。用小麦绿化校园可谓千古绝笔,检查团的那些权贵人士早已五谷不分,岂知所见的“草坪”乃是麦田。

检查工作要预防被检查者弄虚作假。

故事二

我上高中时,班里举行一次入团评审。侯选人中有几位是好学生,有几位是坏学生。我心想“伸张正义”的机会到了,绝不能让坏蛋混进纯洁的团里。可天知道团支部书记是聪明绝顶还是蠢笨之极。他竟说:“班里还有一些同学没有入团,现在他们申请入团,有不同意的请举手。”我们都不知道该怎么办了。书记接着说:“既然没有人举手反对,就表示全部同意,请大家鼓掌欢迎。”这次入团评审不到一分钟就结束了,从此后我再也没想过争取入党。

检查工作要有科学的评审方式。



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

5可行性分析与需求分析


可行性分析是要决定“做还是不做”。

需求分析是要决定“做什么,不做什么”。

即使可行性分析是客观的、科学的,但决策仍有可能是错误的。因为决策者是人,人会冲动,有赌博心态。如果可行性分析表明做某件事的成功率是10%,失败率是90%,倘若该事情的意义非常大,决策者也许会一拍脑袋:“豁出去,干!”于是这世界就多了一份极喜与极悲。4.1节讲述可行性分析的四大要素:经济、技术、社会环境和人。

目前国内很多软件公司做系统集成项目,如果谈谈系统集成项目的可行性分析将很有意思。可是那些系统集成项目大多是政府机构的,由于软件行业尚不规范并且客户方存在腐败现象,所以业内流传“没有做不了的系统集成项目”。软件公司的注意力几乎全集中在“如何拿到项目订单”以及“拿到订单后如何蒙混过关”上,使我丧失了卖弄“可行性分析”的机会。既然不能正面指点一个人如何做好事,那么就规劝他不要做坏事吧。

4.2节讲述可行性分析案例——投资软件公司失败的教训。作者本来没有资格谈论投资,但事有凑巧:近一年来我关闭了一个亏损30万元的软件公司(我自己的);休克一个年亏损200万元的软件公司(朋友的);扼杀一个200万元的投资方案(陌生人的);踩灭一个处于萌芽状态的100万元的投资设想(熟人的)。鉴于现在比较富有的民营企业渴望投资软件行业的越来越多,值得谈谈这方面的可行性分析。我将讲述亲身经历后的感受,提一些建议。

不论是为客户做软件项目还是为自己做软件产品,都要进行需求分析。需求分析最恼人之处是难以在项目刚启动时搞清楚需求,如果在项目做了一大半时需求发生了变化,那将使项目陷入困境。4.3节解释需求分析为什么困难,4.4节讲述如何进行需求分析。本章的需求分析均不涉及编程,所以不考虑结构化、面向对象等分析方法。



5.1可行性分析的要素



做可行性分析不能以偏盖全,也不可以什么鸡毛蒜皮的细节都加以权衡。可行性分析必须为决策提供有价值的证据。

联想集团领导人柳传志曾说:“没钱赚的事我们不干;有钱赚但投不起钱的事不干;有钱赚也投得起钱但没有可靠的人选,这样的事也不干。”柳传志为决策立了上述准则,同时也为可以行性分析指明了重点。

一般地,软件领域的可行性分析主要考虑四个要素:经济、技术、社会环境和人。本节只是泛泛地解释这四个要素,旨在建立全局分析的观念。4.2节将结合案例围绕上述要素进行重点分析与评注。



5.1.1经济

经济可行性分析主要包括:“成本——收益”分析和“短期——长远利益”分析。



一、成本——收益分析

成本——收益分析最容易理解,如果成本高于收益则表明亏损了,如果成本大大高于收益那就亏大了。商人都不喜欢做吃亏的事情。有些商店成天贴着“最后一天跳楼大拍卖”的标语,意思是:我准备吃大亏让你占便宜,同志,你快上钩吧。

如果是为客户做软件项目,那么收益就写在合同中。如果是做自己的软件产品,那么收益就是销售额。

人们在预估产品销售额时常常过分乐观而犯下大错。那些对你的产品说恭维话的人并不见得就是要买货的人,俗话说“嫌货才是买货人”。当你没碰到一个挑刺的人而感觉这产品好得会让你发大财时,就要做好会破产的心理准备。

如果做的是小本生意,那可得对成本进行细算。软件的成本不是指存放软件的那张光盘的成本,而是指开发成本。要考虑的成本有:

(1)办公室房租。

(2)办公用品,如桌、椅、书柜、照明电器、空调等。

(3)计算机、打印机、网络等硬件设备。

(4)电话、传真等通讯设备以及通讯费用。

(5)资料费。

(6)办公消耗,如水电费、打印复印费等。

(7)软件开发人员与行政人员的工资。

(8)购买系统软件的费用,如买操作系统、数据库、软件开发工具等。有些老板买盗版的系统软件,却按市场价算成本,可从美国佬那里赚一笔。

(9)做市场调查、可行性分析、需求分析的交际费用。

(10)公司人员培训费用。

(11)产品宣传费用。如果用Internet作宣传,则要考虑建设Web站点的费用。

(12)如果客户是政府部门,还要充分考虑用于吃喝玩乐、行贿的费用。

(13)如果公司的风水不好,会有很多莫名其妙的管理费。每戳一个红艳艳的公章都要化一把钞票。



二、短期——长远利益分析

人们喜欢吃着碗里的、看着锅里的,还想着别人家里的。短期利益和长远利益兼得是人们梦寐以求的事。在商业上,这等好事可不会轻易降临。

短期利益容易把握,风险较低。国内软件公司经常出现一窝蜂地去做信息管理系统、多媒体光盘、系统集成项目或Internet服务。每当我们沉迷于短期利益不思进取时,应该好好回忆童年时代那些伟大的抱负,给自己一些激励。

长远利益难以把握,风险较大。能为了长远利益不惜短期亏损的人,要么是雄心勃勃的将帅之才,要么是“纸上谈兵”、“眼高手底”的那一类庸人。国内目前有不少Internet企业,只投入不产出。为了成就将来的霸业,甘愿现在拼财力、比耐性。最后存活下来的几个公司将瓜分市场。

那些为长远利益奋斗的人们,你们可得把长征的路途走完啊,千万别让事业中途夭折。

5.1.2技术

技术可行性分析至少要考虑以下几方面因素:

(1)在给定的时间内能否实现需求说明中的功能。如果在项目开发过程中遇到难以克服的技术问题,麻烦就大了。轻则拖延进度,重则断送项目。

(2)软件的质量如何?有些应用对实时性要求很高,如果软件运行慢如蜗牛,即便功能具备也毫无实用价值。有些高风险的应用对软件的正确性与精确性要求极高,如果软件出了差错而造成客户利益损失,那么软件开发方可要赔惨了。

(3)软件的生产率如何?如果生产率低下,能赚到的钱就少,并且会逐渐丧失竞争力。在统计软件总的开发时间时,不能漏掉用于维护的时间。软件维护是非常拖后腿的事,它能把前期拿到的利润慢慢地消耗光。如果软件的质量不好,将会导致维护的代价很高,企图通过偷工减料而提高生产率,是得不偿失的事。

技术可行性分析可以简单地表述为:做得了吗?做得好吗?做得快吗?



5.1.3社会环境

社会环境的可行性至少包括两种因素:市场与政策。

市场又分为未成熟的市场、成熟的市场和将要消亡的市场。

涉足未成熟的市场要冒很大的风险,要尽可能准确地估计潜在的市场有多大?自己能占多少份额?多长时间能实现?

挤进成熟的市场,虽然风险不高,但油水也不多。如果供大于求,即软件开发公司多,项目少,那么在竞标时可能会出现恶性杀价的情形。国内第一批卖计算机的、做系统集成的公司发了财,别人眼红了也挤进来,这个行业的平均利润也就下降了。

将要消亡的市场就别进去了。尽管很多程序员怀念DOS时代编程的那种淋漓尽致,可现在没人要DOS应用软件了。学校教学尚可用用DOS软件,商业软件公司则不可再去开发DOS软件。

政策对软件公司的生存与发展影响非常大。整个90年代,中国电信的收费相当高,仅此一招就把国内互联网企业打得奄奄一息。某些软件行业的利润很高,但可能存在地方保护政策,使竞争不公平。政策不当将阻碍软件公司的健康发展,可最怕的还是政府干预企业的正当行为。例如:

现在家电行业竞争非常激烈,其中有一个著名企业的总裁十分了得,把对手打得节节败退。于是中央领导人就来视察该企业并作讲话:“你们的业绩辉煌,得到了中央的高度重视,……但我们是社会主义国家,不是资本主义国家,你们总得给兄弟企业的同志们留口饭吃吧!”

有一次我拜访了北京大学一位研究经济学的朋友。这个年青人,还是个党员,竞然这么说:“我最近在研究国内明星企业的兴衰问题,我发现了一个规律,明星企业一旦被政府领导人视察过,它就忘了自己是谁,就会做些走向死亡的蠢事。”

我实在不明白企业中为什么还要有“书记”职位。我以为“书记”乃是天下第一号可笑的官衔,“书记”本是“秘书”(secretary)的同义词,是个可有可无的行政人员的称呼,在中国竟然成了最大的官衔。每次看到新闻联播把国家主席错叫成总书记我都十分气愤:因为总书记的称喟只对几千万的党员适用,国家的新闻机构难道不面向十多亿普通老百姓?如果我将来的工作单位还靠“书记”来管事,我每天准忙着生气,那里还有精力去编程。



5.1.4人

有句名言:“人分四类——人物,人才,人手,人渣。”

如果一个软件公司里上述四类人齐全了,那么最好的分工是让“人物”当领导,“人才”做第一线的开发人员,“人手”做行政人员,“人渣”负责行贿。

这里只谈公司的领导与开发人员“行还是不行”。“人物”毕竟是少数,“人才”可是济济的。举重若轻的那类“人才”可以做领导,举轻若重的那类人才适合做软件开发人员。假如一群持有学士、硕士和博士文凭的毕业生到软件公司应聘,该如何录用呢?我的建议如下:

先选择本科毕业生,因为他们正当青春、干劲十足、不摆架子、不耻下问、要求不高、奉献甚多。

其次选择硕士毕业生,如果该生没象范进中举时那么老,并且在读硕士时没有天天去造文章而丢弃了编程工作,那么让有经验的学士程序员带他们煅练几个月就可以用了。

如果学士、硕士被其它公司取光了,那只好捡几个博士充数。博士到了软件公司有什么用呢?我想不出有什么用,只知道他们挺值得可怜的:从硕士读到博士出头,这六七年时间,真本事没学多少,倒学会“眼高手低”甚至“弄虚作假”;毕业时蓦然回首,发觉青春已被虚度,心灵已呈老态,唯有长叹短嘘,强把自负作自信。我也将博士毕业,就要论为三手贷贱卖了。真羡慕那些比我年轻的学士、硕士们,他们可以远走高飞,唉!

5.2可行性分析案例

谈到软件产业,不能不提及比尔·盖茨与Microsoft公司。因为比尔·盖茨创建了Microsoft公司并成为世界首富的事实,使得无数从事软件工作的人们心存同样的梦想。有太多人急着想做中国的比尔盖茨 。有个年青人发明了一种汉字输入法,便在媒体上放言欲覆盖比尔·盖茨。中央电视台特冲动地把一个上了年纪的院士请来,让他谈谈自己与比尔·盖茨的比较,害得这位院士一个劲地辨解自己不是中国的比尔·盖茨。

近几年来,一批Internet英雄企业如Yahoo、Netscape兴起。尤如打破了秦始皇一统的天下,重返春秋战国时代。让软件人员走出了Microsoft的阴影,看到了阳光灿烂的软件世界。于是各色各样小不点儿的软件公司在国内遍地开花。

打破水缸的小孩子很多,但并不见得就会有司马光的业绩。由于“经济、技术、社会环境、人的因素存在差异,有些事情美国人能做成,我们模仿着做未必就能做得成功。虽然“星星之火、可以燎原”,但我们的国力薄弱,实在容不得把有限的火种扔到不毛之地。所以要进行可行性分析,如果不可行,就不要急着去做。本节三个案例是作者亲身经历的,我力求讲清楚错在哪里,并总结经验教训。希望读者看后能提高警惕,免犯相同的错误。



5.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万元,却一无所得。几个月后当我意识到不公平而找他协商时,他说:“只能怨你自己愚蠢,读到博士,连张合同都看不懂。”

我觉得自己在此事上虽愚但不蠢,诚实正直的品质加上不懈的努力会让我变得有智慧。自己的奋斗没什么可以后悔的,学到的远比失去的多,下一次会做得更好。



5.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公司(世界最大计算机公司之一)的创始人远见卓识,投资数千万美元开发这种刚诞生的浏览器。他们成立了网景公司,

论坛徽章:
0
发表于 2002-03-31 13:07 |显示全部楼层

软件工程思想

这本书还真不错...
看得出又作者自己的经验在里面

论坛徽章:
0
发表于 2002-04-04 13:59 |显示全部楼层

软件工程思想

//nod

可是看的人不多啊

论坛徽章:
0
发表于 2002-04-18 12:12 |显示全部楼层

软件工程思想

是本好书!我要收藏!

论坛徽章:
0
发表于 2002-04-23 10:52 |显示全部楼层

软件工程思想

我要拷贝、粘贴、再拷贝、再粘贴。。。。。。。。。。。

论坛徽章:
0
发表于 2002-04-28 13:13 |显示全部楼层

软件工程思想

全了吗? 很有实际性.

论坛徽章:
0
发表于 2002-05-19 18:52 |显示全部楼层

软件工程思想

全了,那个大学十年我没拷,嫌太长了

论坛徽章:
0
发表于 2002-05-21 08:55 |显示全部楼层

软件工程思想

那里有大学十年?

论坛徽章:
0
发表于 2002-05-22 10:44 |显示全部楼层

软件工程思想

不是講沒拷嗎

论坛徽章:
0
发表于 2002-05-24 14:43 |显示全部楼层

软件工程思想

不错,不错,多推荐!!
您需要登录后才可以回帖 登录 | 注册

本版积分规则

久等啦!10张门票开启你的DTCC2017之旅

2017中国数据库技术大会将于2017年5月11-13日如约而至,本届大会以“数据驱动•价值发现”为主题,共设定2大主场和21个技术专场,云集海内外120+位技术大牛,共同探讨Oracle、MySQL、NoSQL、云端数据库、区块链、深度学习等领域的前瞻性热点话题。
即日起,填写DTCC2017会前调查问卷,即有机会赢取价值2600元的大会门票1张!仅限10张!
----------------------------------------
活动截止时间:2017年5月5日统一公布

问卷入口>>
  

北京皓辰网域网络信息技术有限公司. 版权所有 京ICP证:060528号 北京市公安局海淀分局网监中心备案编号:1101082001
广播电视节目制作经营许可证(京) 字第1234号 中国互联网协会会员  联系我们:
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP