日历
| |||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | 5 | 6 | ||||
| 7 | 8 | 9 | 10 | 11 | 12 | 13 | |||
| 14 | 15 | 16 | 17 | 18 | 19 | 20 | |||
| 21 | 22 | 23 | 24 | 25 | 26 | 27 | |||
| 28 | 29 | 30 | |||||||
搜索标题
统计信息
- 访问量: 2328
- 日志数: 18
- 建立时间: 2006-12-18
- 更新时间: 2008-05-22
RSS订阅
我的最新日志
-
如何理解“挣值（时）技术”
2008-5-22
挣值技术从参考基准（Value）上可以反映出美国项目管理团队的特色，拥有很大的财务预算，实用和结算权。放在中国国内的环境，除了建筑和制造等传统能够较为实用外，放在IT行业，则举步维艰。这是为什么呢？作为一个项目经理，你知道你的员工的工资和成本么？由于国内企业会计保密制度的限制，这基本上是不可能的。因此，我们只能把Value改为Time，叫做“挣时技术”。为什么？因地制宜，即可解决挣值面临的财务数据无法采集的困境。如何简易的理解挣值（时）技术？我们以现实和理想的矛盾关系来说明。挣值（时）涉及到三个要素：
（1）努力－成本（AC或AT）
（2）理想－预算（PV或PT）
（3）现实－实际效果（EV或ET）
也就是无论做什么事，我们只要记住：
花了多少精力做了多少事，实际花的这些精力按预想中可以做多少事情
就能理解挣值（时）。理解挣值（时）技术，一定要把握好这几点：（1） 一个是实际效果折算，一定要按照原来的预算的比例折算，即“这些事原来预想只花多少精力”；
（2） 实际花了多少精力；
（3） 实际花的这些精力按预想中可以做多少事情；
例子：一个小学生，老师命令他2小时做10道题（假设题目难度一致，每道题需要12分钟），结果他1小时20分钟结束的时候只做了4道题。
我们可以看出：
实际效果：4道题＝48分钟；
实际精力：80分钟；
理想结果（实际花的这些精力按预想中可以做多少事情）：80×10/120 = 6.67 道题
因此：
进度差＝实际的效果－理想的结果＝4－6.67＝－2.67道（以题为中心）
进度指标＝实际的效果/理想的结果= 0.6
成本差＝实际的效果－成本＝48－80＝－32分钟（以时间为中心）
成本指标＝实际的效果/成本＝0.6
知道为什么在这里进度指标＝成本指标，这是因为我们多了个（假设题目难度一致，每道题需要12分钟）的条件。没有这个条件的话，进度指标和成本指标是不会一致的。但是我们在计算时，依然要坚持“花了多少精力做了多少事，实际花的这些精力按预想中可以做多少事情”这样一个原则。
注：进度以效果来考虑，成本以投入来考虑。由于挣值（时）技术里（计划产出＝计划投入，如上例的1道题＝12分钟），所以EV（ET）在进度计算和成本计算中是一致，不过我们在分析问题时，最好把它拆开分析。即进度计算中我们的是EV（ET）的计划产出的一面（如上例的题目数），而成本分析里我们考虑的是EV（ET）的计划投入的一面（如上例的时间）。这样就能够完整理解令人混淆的挣值（时）技术。
指的注意的是，挣值和挣时计算出来的结果大部分情况下是有偏差的，这是因为，每个员工的工资，成本显不一致，通过工资率（或成本率）换算后，结果自然就有偏差了。但是挣值（时）核心的思想还是一致的。
-
PRINCE 2 vs PMBOK (读书笔记)
2008-4-06
PRINCE2 优点
PRINCE2 提供了一个项目管理团队必须所拥有的标准角色描述；而PMBOK仅仅以项目经理一个角色一笔而过。
PRINCE2 提供了完整的变更控制机制，PMBOK仅仅提及项目管理需要变更控制，但并未涉及其具体实现。
PMBOK几乎未提及配置管理，亦未提及配置管理员的角色以及配置管理与变更控制间的关系；而配置管理则是PRINCE2八大组成部分之一；
PMBOK仅仅谈及项目计划，而PRINCE2提供了项目阶段划分以及团队计划，并讨论了适时中止或修正项目计划的必要性。PMBOK涵盖了WBS的创建内容，很显然PMBOK的计划不能跟PRINCE2的基于产品计划技术相比拟。在产品描述方面，PRINCE2给予了较多的篇幅说明，而PMBOK仅仅只是提供了轮廓性的建议。
PMBOK优点
PMBOK涵盖了项目对人力资源管理的需求，PRINCE2 则未提及；此外PMBOK提供了项目管理中的团队成员沟通的具体细节，PRINCE2显然在这方面没有花工夫。
PMBOK的制定者大多来至于传统的建筑、制造企业，其项目环境显然与信息企业的环境相迥异，例如采购管理是传统行业项目管理的一个重点领域，但对于信息项目来说，除了信息系统集成等软硬件结合的项目，采购管理并不是项目管理的重点，因此PRINCE 2体系中未详细提及。
PRINCE2的制定者基本上来自于信息企业，在商务方面有所专注，因此PRINCE2里涉及到了商业论证，更加重视项目利润率。PMBOK则是单纯地着眼于项目的达成。
-
为什么总是五：各种成熟度的哲学思考
2007-12-27
大凡有点中国古文化常识的中国人，都知道老子《道德经》里的“人法地、地法天、天法道、道法于自然，道生一、一生二、二生三、三生万物”之类的古语。可见中国人向来以三作为标榜，讲求的是三点论，对事物的变化采取正、反、和的观点。革命史亦充斥着“左倾”、“右倾”之说。这即是所谓的“大中至正”，讲求不偏不倚，综合地看待事物（我们称之为：东方人见森），这是东方人优点，不过正是因为这个优点是我们在发现自然规律时拘泥于环境影响，最终为西方所超过（当然这只是其中一个原因，西方技术强势还有其他方面的原因）。
西方人的思维，则是运用分析之技术，抛开环境，参透万物自身（我们称之为：西方人见木），发现事物无时无刻不在变化的规律，遂提出“世界是过程的集合”这一论断。但凡过程必有“发生、发展、鼎盛、衰退、灭亡”这样的五阶段，此外通过类比和对比，西方人还发现（其实东方人也发现了）：任何事物都有这样的过程规律。哲学上称之为“五能演化”。
五能演化有很多的具体实例，下面给出一些例子：项目
态1
态2
态3
态4
态5
事物
发生
发展
鼎盛
衰退
结束
关系
分治态
对峙态
单极态
多极态
共存态
正反能量
能基态
能殊态
能梯态
能近态
能洽态
认知
无知
有知
定性
定量
应用
于是乎我们的IT先哲们，基于自身的思维习惯和五能认知，遂将与成熟度有关的东西，均予以“五能化”，所以你看到了CMM有五个级别而不是四个或六个级别、软件测试成熟度模型（TMM），项目管理成熟度模型（PMMM），人力资源成熟度模型（HRMM）无一不是五级别制。 换做在座的各位，我相信你们亦能根据“五能演化”这样一个观点而推导出恋爱成熟度模型、认知成熟度模型、企业管理成熟度模型等等。
有的人也许会问，我把它分成十个级别行不行，当然行。制度经济学上讲过：制度划分的颗粒度取决于组织的容量。此外，所谓的能态之间是连续的，不是离散的，只不过我们基于认知规律将其人为划分为五个阶段，因为这比较贴合于大家的认知，而不是划分为五个阶段就一定千真万确。此外，如果是划分为五个阶段是为了纯数字化，我问个问题，多少根头发的人才不算秃头？
总结：五能演化是西方人和东方人认知中的一个常见的思维定势，在社会人文科学中有着广泛的应用，对科学技术领域也有着深远的影响。
-
乱弹行为经济学：（一）何谓行为经济学
2007-12-25
顾名思义，就是研究人们的经济行为，目的是为了预测大多数人（中国叫人民）或是特定人群在特定的环境和条件下所做出的基于价值判断的经济行为（由张华定义，非盗版哦）。
为什么要搞出这个很玄的东西来呢？这是因为现实当中有很多事情是不能用现代主流的经济学去解释的，比如彩票和赌博。
传统的经济学假设大家都是“理性”的，如果现实真如此的话，这个世界至少应该没有收藏家、球迷，粉丝，吸毒者等等（递减效应的存在），可是现实并非如此。
行为经济学假设大多数人是“有限理性”的，当然精神病员的病人和医生除外。不过至少站在我这个角度上，考虑东方人和西方人的认知差异，我宁肯假设大多数中国人是“愚昧”的，因为大多数国人的经济行为极其容易受到外因的诱惑而不是出于自身的内因的驱动。为此，我不太相信中国人的行为经济和国外有着相似的类比性，至少它们之间应该是大差异的类比性。
下面谈行为经济学的参照系问题。联想曼昆经济学税收的横向平等，让我想到公司在管理、薪酬方面的平等，每个公司的不和谐因素在于水平差别不大，工作差异不大的人拿着差异较大的工资，特别是当这几个人出于相同的教育背景情况。所以管理学中说员工更看重对比差异而不是绝对基数，这是所谓的“劣根性”所在。所以，我对一些国人恶毒的评价还是有根有据的。吹嘘自己聪明的人定是傻瓜，其实也就是这些人自卑心理的体现。
参照依赖就是大家按某个参照点来衡量自己的“损失”或“获得”，而不考虑其绝对量。上面说得很清楚，我不再说继续说了。
损失厌恶：”期望越大，失望越大”，说的就是这个道理。预定得到的东西后来被取消比事先知道取消在感觉上更痛苦。学到这一点使我对上次某小姐不能一同外出深感愧疚，当时我应该站出来强烈反对外界的扰动，看来只能下次努力补救了。
敏感度递减：“狐狸吃不到葡萄就说葡萄酸”，说的就是这个道理，与期望值相差甚远的东西不会对它有偏好的，虽然有时是违心的，这个时候我们称之为“无奈”，“无奈”另外一种诠释叫做“放弃”。这时候再谈主观能动性就变成了马后炮（马后炮的意思就是说在伟大革命导师马克思先生死后放鞭炮）。
接下来谈锚定心理，“IT人生女孩”就是这种心理的体现，这是一种偏见，要不然国家计划生育委员会的标语早改为“做IT人士好”。锚定心理指的是不同的参照物使行为者对价值判断出现差异化的表现。“近朱者赤，近墨者黑”或是“疑邻盗斧”就是这种心理的极佳诠释。
最后框架效应，我叫它“心理暗示”，实际上就是“朝三暮四”的经济学术语抽象。由于大多数人基于“正义”的价值观，“50％可能生还”比“50%可能死亡”要更有积极的意义。除非你心理阴暗才不会这样想。这就是框架效应，同样的选择采用不同的选择方式呈现出来的时候，人们的行为会发生改变，这是因为我们的参照点变了的缘故。所以呀，跟人攀比不如跟自己比。只有自己才是自己最好的参照点。说了这么多，口干了，休息一下，下次继续茶话。
-
订饭网的商务模式分析
2007-12-21
去年的中国软件技术大会上有公司向我咨询过这个问题，这次再次有公司咨询这个问题，遂作一番书面答复。
判断一个互联网商务模式是否有盈利的可能，首先是人气。人人都要吃饭，从理论上看存在人气的可能性。
其次从用户的使用成本来看。用户只有在低使用成本，高收益情况下才会蜂拥而至，这是人趋避风险的本性所决定的。大凡吃饭之类的小事，都是随性而起。你总不会在大街上、车上拿着个电脑去找吃饭的地方吧。但是你会使用手机去做这个事情。很可惜，我们的3G时代还没有到来，笔记本电脑还没做到手机那样的大小，就算做到了，使用起来肯定不如手机方便。所以从使用成本上来看，网上订饭没有什么优势。
再次从用户接受的服务质量来看，互联网订饭不如人与人直接电话沟通来的方便，口味、推荐菜谱、订座位、时间方面都可以快速响应，至少可以得到服务人员的及时反馈吧。但互联网订饭由于涉及的饭庄、酒家之类太多，就算订饭网公司出专职人员也未必能够及时准确的反馈。对于饭庄、酒家来说，自身的营业员文化水平都比较低，你如何保证他们及时在后台上更新菜肴数据？
最后从资金流向来说，有的用户看了订饭网，打电话直接去找饭庄、酒家，因为他可以得到直接服务。这就意味着客户流失。此外，订饭网自身是不具现金流功能的，既然你不具有现金流功能，你如何保证饭庄，酒家给你支付佣金？再则，在订饭网上订饭，用户失约，饭庄，酒家那头怎么处理违约责任？这都是需要考虑的地方。
那有没有其他的方法，有。但不是那么完美。考虑到用户的使用成本，你可以开通服务专线，如上海这边的57575777。改变只靠互联网单一营销的模式，加入电话销售模式。如果接线生对很细节的东西不熟，可以再转至具体的饭庄、酒家。服务方面质量虽然有些下降，但还不至于过不去。
电话营销与互联网结合虽然一样面临佣金问题，但是采用这种方式后，由于使用成本和服务质量的原因，用户人数自然增多，饭庄，酒家自然甜头大增，会形成一定的利益依赖性。在利益关联度大增的基础上谈佣金问题自然好谈。这是中国人办事的特点，先有实绩再谈预算和原则（这是销售的做法，与做市场的路径刚好相反，实际上中国绝大部分做市场的实际就是做销售）。
以上是一点个人愚见。当然分析一个问题时有各种各样的角度，限于个人经验和学识，不再阐述。 -
软件过程改进的人文途径（SEPG 2007 China 演讲稿）
2007-12-14
诸位朋友，嘉宾：
在开始演讲前给大家讲一个寓言，也算是一个笑话。寓言是这样的，
在一架飞机上，乌鸦对乘务员小姐说：“小妞，给爷来杯水！坐在旁边的猪听后也学道：“小妞，给爷也来杯水！”，乘务员小姐把猪和乌鸦领子一提，扔到机舱外。乌鸦拍拍翅膀，笑着对猪说：“你还真是猪头啊，傻了吧？爷会飞！”。
这个寓言告诉我们，外界因素是一种约束条件，自身能力也是一种约束条件。所以，别人能成功的事，未必自己就能成功。
对于CMM/CMMI和过程改进来说，我们有些企业扮演的是乌鸦的角色，也有不少的企业扮演的是猪的角色。今天我们的主题就是关于从猪的角色转变为乌鸦的角色的一些人文方面的途径。
首先，让我们来看看目前很多企业在实施CMM/CMMI方面的问题。
（1）实施成本高，不少公司在实施后走向玩命生涯。大家去查查国内第一家过CMM和第一家过双五的企业，看看他们现在的一个境况如何。我想你们比我更清楚。我的意思不是说实施CMM/CMMI企业就会败落，有不少企业，包括这次来的很多嘉宾所在的企业，他们的企业在实施CMM/CMMI后业务反而做得很好，为什么，有一点是值得注意的，成本问题。试想一个二三十个人的小公司去实施CMM/CMMI，你们算算多少费用，这样的小公司有多少资金可用。没等实施完，早弹尽粮绝了。所以，没半斤的肚子，就不要吃八两馒头，免得气胀和消化不良。
（2）形式主义加教条主义，我称之为“双症教育”，国内通过CMM/CMMI的企业，实施时靠个“GOLDEN PROJECT”的模板项目骗CMM/CMMI认证的公司多的是，我的先前曾经呆过的一家公司在过CMM 4认证的时候，评估师居然在验收时，面对测试团队，居然没有提一个问题。难道真得没有问题了么。做事讲究的是一个态度，做人讲究的是一个“德”字，很多认证在国内被做烂掉的一个原因就是个“形式主义”。形式主义缺什么，甲方缺做事的态度，乙方缺德。相比形式主义来讲，教条主义也好不到哪里去，一个公司的制度太过于教条，整个公司就会死气沉沉，缺乏活力。关于教条主义的来源，我将在后面给大家讲述。
（3）第三条，我们称之为偏见，这是技术人员出身的人常常犯的错误。我也常常犯这种类型的错误。记住“软件行业无一包治百病，立竿见影，药到病除的狗皮膏药体系和方法。”我是学中药出身的，中药里基本上没有只用一味药的，只有调和各个药的作用，才能发挥最大的药效。一个企业的质量问题同样地，不是仅仅关注于过程就能达到的，过程是人做的，有缺德的人和高尚的人，有先进的技术手段和落后的人工手段的，自然会有过程改进的效果不同。不然的话，为什么不去找个文盲来做过程改进。所以，我们在实施CMM/CMMI的时候，不要以偏概全。只重分析，不重综合。过程、人、技术，软件过程三要素，缺一不可。
（4）目前的很多咨询师在CMM/CMMI方面，仍然轻视人在软件开发中的核心作用，以为有了机制，对人的要求反而不是太重要。机制在一定基础上可以降低对人员素质的要求，但不是没有要求。在座的嘉宾们有很多是名企，一样过CMM/CMMI认证，你看看他们的人材招聘要求，不但不低，而且很高。为什么，人是软件行业赖以生存之本。所以不要把人当机器，机器是没有思想和创造力的，人有思想，有创造力。这就是各位为什么生气勃勃的在这里参加大会的原因，因为我们都是有思想，有创造力的新人类。
我们接下来谈谈过程改进咨询和实践中遇到的最为常见的问题。这些问题目前是目前的过程改进流程中做不到的一些方面。
（1）执行力不足
过程改进强调给管理者、实施人员足够的权限，讲求“授权”二字。很不幸的是，尽管有了授权，相关的过程改进实施执行方面仍旧是拖拖拉拉，大家都在磨时间。这个结症往往出在项目组长和项目经理方面，有法不依。我先前的一家公司的老板，为了这个问题，解雇了所有的中层管理人员，其结果大家可向而知，公司去年倒闭了。可以说，执行力低下这个现象不单是实施过程改进的企业，基本上所有行业都会有这个问题。殡仪行业也许是个例外，所以我们要高歌一曲“学习殡葬好榜样，高效快速执行力强”。至于执行力不足的原因，我在后面的激励机制中将有所阐述。
（2）软件质量仍然达不到要求
我们都知道，软件质量的源头是需求，软件质量的关键是过程。但是，就目前来说，过程改进的一大不足就在于没有真正深入到质量的源头，没有参与到客户价值过程中去。我见过很多公司SEPG成员参与到软件开发的洪流中，热火朝天。但是很少看到SEPG的人员陪同开发人员、市场人员和客户进行业务沟通。或是审查过业务销售的报告和需求单据。往往就是这不经意的一步，对后续的需求质量乃至业务的获取影响至远。
（3）流程过于形式化，重数据而不重本质
我看到这次一个嘉宾的文章，有关标杆数据的，写得非常好，非常有借鉴性。但是在实施过程中，我讲了，人的态度决定一切。最主要的在于数据采集的主观意志太强。这是因为，就软件质量属性来说，有的东西只能定性，比如代码风格好坏，精炼程度，文档正确性和书写的优美性，很多都是模糊的，比较难以数量化，这些模糊的东西不是不可以量化，而是量化所需的成本太高或是算法太复杂。这好比“多少根头发的人算秃头一样，多一根少一根会影响评定结果吗”一样，我们只要给个定性的结论就可以了，但是在标杆数据里，定性的东西却没法处理，我们的SEPG组织总是吹毛求疵的追求最终的数据结果，最后才发觉自己没事瞎白活。此外，很多公司的过程改进中，强调文档的数量而忽略质量，重文档形式而忽略其实质内容。结果是过程改进好像没有给软件质量带来提升。这不是过程改进的错，如木桶理论所言，要达到质量的提升，过程改进有必要在木桶的短板上做足十分的功夫。
引起上述情况的根本根源，我们认为这在于东西方的文化冲突，主要体现在“人治”和“法制”的均衡上。
（1） CMM/CMMI的核心思想
CMM/CMMI的核心思想为三权分立，我们的CMM/CMMI创始人可是标准的孟德斯鸠的门徒。
我们现阶段的司法体系也如此，可以说，我们可以把CMM/CMMI模型当作公司项目开发的小的司法系统，联想一下中国社会上的司法种种现象，你就不难想像我们的小司法系统也会出现哪些同样问题。
过程改进体现的是“三权分立”的思想，强调的是职责明确和授权，但是中国企业现实中更多的是要如何解决“秃头人问题”。这是因为西方人求真，东方人务实。 胡适先生讲过，“多解决些问题，少谈些主义”，在这里也是同样适用的，过程改进不能只是空谈，而是要反应到企业具体的实际问题中去。
此外，从CMM和CMMI的“三权分离”（制度化）理念和持续改进（完美主义）来看，往往忽略了人在软件质量中的核心作用和企业环境对CMM/CMMI的支持作用。这是西方人和东方人不太的地方，西方人考虑问题时，往往将主题对象从环境中剥离，而东方人的思维里，常常考虑的是主题对象和环境的交互作用。既然思维方式不同，所以行为方式自然也不同。（2）CMM/CMMI的初衷
CMM/CMMI的初衷是为了提高软件开发的质量和效率。但是大企业的效率和小企业的效率问题的本源不是一样的。
大企业的效率问题来至于制度的盘根错节，是制度与制度间冲突的效率问题。
小企业的效率问题来自于毫无章法带来的效率低下，与大企业有本质差别。
一个需要“化零为整”，另外一个需要“从无到有”。
制度设计的理念体现为“公平、高效”四个字，对于大企业来说，更兼顾于“公平”、而小企业来说，更兼顾于“效率’。所以我们在实施过程改进时，首先应该考虑到企业的一个规模因素。
在实施过程改进的人文途径方面，首先我们要树立以下一些思想，对我们理解过程改进的人文途径至关重要。
1.不要一来就叫嚣改变企业文化，过程改进只有适应企业文化环境才能有发展。
一个企业文化是企业经过长期的进化、演变而积累的东西，是一个企业精神价值的所在。不是靠开开会，给公司领导洗洗脑就能够改变的。过程改进不能违背企业的基本价值观。过程改进只有审时度势，在公司大环境允许的条件下进行适当的改良，以适应公司的基本环境，然后才能谈改变。因为没有人喜欢变，因为变化很多情况下意味着原有积累的丧失和风险，除非新产生的价值能够弥补已有的沉淀成本。反过来，过程改进只有发展了才能改变企业文化，以一种循序渐进的方式，不断的对企业文化进行改良，但企业的基本价值观是不能动摇的。在很多方面，客户利益是放在第一位，因此在项目开发中会出现不按过程改进原有措施做的实例。一个紧急的单子或是问题，可能是先做后补单。如果什么都按既定步骤，医院死人人数不知要翻几番。企业就会流单子，流单子老板要骂人，最后就是将“制度奴隶”扫地出门。
2.过程改进与客户利益的关系
企业是目标是生存和盈利，而不是过程和制度。但制度和过程可以影响企业的生存和盈利。先进的理念如果不能给公司带来真正的效益，那么说明理念本身的适应性有问题。对于过程改进来说也是同样的道理，过程改进如果不能给公司带来真正的效益，那么说明过程改进这个理念本身适应性有问题。因此，除开发过程中需要导入过程改进机制外，客户价值过程中也应该导入过程改进。通过客户价值过程改进、赢取合格的客户需求，比事后进行过程控制要好的多。需要提醒的是，过程改进在客户价值流程方面要力求务实，而不是新的教条主义。
3.过程改进要协调好利益干系人的利益关系
为什么过程改进在具体的实施中会有太多的阻力？下面给出一些项目经理和开发人员给出的推卸之辞：
1.过程改进没有按项目大小和紧张程度进行剪裁
2.过程改进总是太过于公平，忽略效率
3.我从过程改进中没有获得任何好处，工作量倒是增加不少
4.给我一个式样模板对于我来说更为急需，过程这种看不到的东西就算了
等等
与其大谈过程改进要改变人的思想，不如事先分析一下相关干系人的利益情况，这样你就会知道，谁在过程改进中支持你，谁在过程改进中反对你，以及如何有的放矢的应对。项目管理中的一个核心不也是项目干系人分析，过程改进适合同样的情况。
为什么？因为人的本性都是趋利的。毫不利己，专门利人，你们当中有多少人能做到。每个过程改进所影响到人员在企业内都有自己的利益和自己团队的利益，如果你的过程改进损害到这些人的利益或给他们造成麻烦，谁来支持你。这里面就涉及到一个利益均衡的问题，这点在中国企业制度的建设中非常重要。其实在国外企业，也是同样的重要。不过外国人不会告诉你，他们也有“面子文化”。
过程改进有哪些人文途径，我简单的讲述一下自己的一些体会：
（1）在过程改进中将授权机制变为激励机制
没有激励，仅仅只有“授权”是完全不够的。传统的过程改进总是强调授权而忽略激励，根据制度经济学的论断，制度的接纳的最优途径是激励，而不是授权。激励可以激发过程改进人员、项目管理者、底层开发员工的积极性。权益，权益，为什么项目管理层在授权后老是拖拖拉拉或者是阳奉阴违，因为他们只有权，没有益。换个角度思考，你会不会去做一件跟你完全毫无利益的事情。最简单的例子，就是包产到户，包干到户。一个没有激励只有授权的团队意味着团队的人员只有责任，没有权利。而从人的本性的黑暗面来说，人是风险规避的，也就是责任逃避的。
激励机制可以有很多做法，最简单的就是绩效公示，不过这种做法会太过于打击新手，因此可以采取一些隐性的激励手段，比如项目提成和团队补贴或是精神激励等。如我前面所说,没有一种方法能够单一取得最优效果,因此在实施过程中要结合使用。对于惩罚，没必要公示，中国的技术人员最爱面子，以教育为主。如果实在是“朽木不可雕”，就扫地出门，扔掉把。
（2）取消无限、持续的过程改进说法，讲究适可而止，阶段性提升无限、持续过程改进体现了我们这些技术出身人员最大的一个人性缺点，同时也是人性的优点之一，追求完美，没有最好，只有更好。但是从企业成本和过程改进成本来说，未必就值得。为什么？我举考试的例子，大家考60分需要复习一个小时，从60分到70分肯定不止一个小时，70到80分呢，80到90分呢，100分就更不要说，投入的精力和时间太大，而且稍微闪失就不能达到。过程改进也是一样的。如同经济学边际递减规律所提到的，如果过程改进的投入要素连续地等量增加，增加到一定值后，所提供的过程效果的增量就会下降。追求完美是没错，但是要考虑过程改进的成本，企业的预算是有限度的。这是其一，此外，项目的过程改进也得有个适应期，每个项目都要在前面一个项目上持续地改进，项目开发人员只能愈来愈抵制。因为他们在还没完全适应的基础上又得匆匆忙忙去适应下一个项目的新过程。一个字“累”。
（3）尊重80-20规律，精英意识与平民意识并举
我跟一个CMM/CMMI的咨询师曾争论过这个问题，他跟我讲，你一味强调人，你还没领略CMM/CMM的思想。什么思想，我称之为“民工思想”，在他看来，通过先进的制度和理念可以去除人带来的影响。没错，任何先进的管理制度都在解决这个问题，但是很不幸，人的能力是有差异的。制度要解决的是人的劣根性，激发人的善性，我们的软件开发不是体力劳动，而是有创造性的劳动。我们的管理层都是团队精英，在很多公司，我收到他们对过程改进的一些反馈：为什么管理层人员和技术强人大多抵制过程改进？
1. 增加工作量
2. 太过于教条，不考虑特殊情况和紧急情况
3. 职责变多，无法“踢皮球”
4. 个人作用不再受重视
5. 管理成本增加
你们可以看到，大家都是“唯利主义者”。大家之所以在你们现在的岗位上，是因为你们相对与其他岗位的人员有着相对的“性价比”优势，如果一个制度能抵消掉这方面的优势，那这个岗位没你做也没关系，既然有没有你都无所谓了，你的生存价值何在，你不抵制这个制度才怪。所以，有时候制度需要一点人性化的东西在里面。我前面说过，有很多是名企，一样过CMM/CMMI认证，你看看他们的人材招聘要求，不但不低，而且很高。高素质的人材是潜力股，潜力股要看未来，就个人行为来说，短视者居多，对于企业来说，不能吃了上顿没下顿，潜力股是企业未来保证。
（3）将客户价值的商业流程纳入到过程改进中来
为什么过程改进在企业内部不受重视，不被人理解。没有把客户价值创造的流程包括在过程改进中是一个主要的原因。我们进行过程改进时，不要只考虑公司内部的过程改进，尽可能的把价值链上所牵涉的业务对象也加入流程。软件质量低下跟没有将客户价值的商业流程纳入到过程改进中也有关系。客户的需求是软件质量的本源，单靠我们自身能力不足以 完美无缺，需要客户参与到过程改进中来。否则，你无法预知需求获取之前的东西和需求的质量。实际上很多企业的销售工程师和系统分析师都需要过程人员的协助，包括客户。我们的客户经常会问，你们那边的商务流程是怎么样的，需求流程是怎么样的。过程改进在此时就体现了了它的重要性和必要性。换个角度来说，将客户价值的商业流程纳入到过程改进中来，还可以改变过程改进的“成本中心”形象，由于过程改进参与到企业利润源头的工作中来，往往会获得更多公司内支持。
（4）过程制度建立和完善要依据分工规模
如何剪裁和划分过程制度的颗粒度，这是最为企业过程人员头痛的事情之一。我们从经济学的分工理论上来看，过程制度建立和完善要依据分工规模。
制度划分理论是这样的：
制度划分的力度取决于组织的容量。
同样过程改进的剪裁和力度划分需要按照团队和项目大小来进行调整。分析与项目目标相关的领域的相关性。比如较为低层次的对日外包项目，过程改进活动一般着眼于代码审查和测试复核。而对于产品开发来讲，过程改进关注的中心往往是首尾，一个市场需求的式样化，一个是市场反馈系统完善过程。
还有一点要提醒的是，交易费用理论对我们也有十足的借鉴性：
随着组织规模增加，交易成本将越来越大。
因此对于大项目来说，如何对沟通方面的改进会变得攸关重要。过程改进的实施的效果将取决于沟通的流畅性。
我们可以总结为：
大企业、大团队、大项目，过程改进的重点在于沟通的流畅性。
小企业、小团队、小项目，过程改进的重点在于过程颗粒度的划分。
（4）构建成熟的人力资源成熟度模型为什么我们要引入人力资源成熟度？1.
1.我们确保合适的人在合适的职责岗位上，才能获得最大的工作效果。
2.过程是要靠人来抓住，人来管理，不是制度摆在那里就算完成了。
3.进行诸如软件开发这样的脑力劳动需要高素质人员
过程改进实践往往忽略环境和上下文，有的过程改进甚至需要由顶级专家构成的团队才能施行。没有合格的员工开发不出合格的软件，没有合理的制度，创造不出高绩效。因此，过程改进中，不可缺少人力资源的支持。这跟CMM/CMMI的开展过程教育的宗旨有一定的重合空间，是不违背的CMM/CMMI的“洗脑战术”理念的。
（5）构建合理、公平的劳资、福利体系，并与过程改进相挂钩过程改进要能顺利实施，离不开公司的福利制度。任何一个企业里，没有人会跟钱过不去，但会跟过程改进过不去。将过程改进和员工的福利劳资挂钩，会从很大方面加速过程改进的力度和提高过程改进的效果。当然人是IT企业的立身之本，过程改进需要优秀的人材参与，有些CMM/CMMI企业，自身福利薪资太差，就算你现在过了CMM/CMMI，你又能好到哪里去。近期的钱你是赚足了，但是远期呢。大家有空可以去看看IT红黑榜，看看我们的CMM/CMMI企业有多少在黑榜上，然后预测一下企业存活期。实际上，你们不用预测，你看看这些公司的效益值，就不难发现，口碑差的企业大部分还真是举步维艰。
（6）以经济效益为考核杠杆，通过过程改进提升企业效益
经济效益是企业生存的指标，任何企业的制度，理念，无一不是以合法合理的经济效益为最终目的。要获取企业高层领导及管理层（我这里指的是有心搞好CMM/CMMI,过程改进的企业领导，不是为了骗国家资助，玩形式主义的领导）的大力支持， 首先要灌输过程改进的 “节钱”观念。其次，过程改进的最终目的还是通过提高软件质量从而提升企业的经济效益。如果一个过程改进对企业效益没有任何作用，这样的过程改进不可能长久，也没有存在的必要。我的经验是，分析过程改进中流程与效益的相关性，扶正去负。经过一段时间的过程改进适应后，会做相关的效益评估报告。这样的做法可以去除公司员工对SEPG的成本中心看法，获得公司整个上下文环境的支持。从另外一个侧面讲，让SEPG人员和QA人员知道自己所做的贡献值，增强对过程改进的信心，做出更为出色的成果。
过程改进的人文途径总结：用生态学观点看过程改进，创造和谐的人文环境
我们把企业当作是一个生态系统，过程改进犹如人之进化。进化的本意是先适应后改变，现在到处都在提倡和谐，过程改进也一样，我们考虑过程改进的时候不单单只从过程改进本身出发，更重要的是，联系上下文环境，尊重员工。只有为过程改进创造一个和谐的人文环境，才能够做好过程改进。
我的演讲到此为止，谢谢大家。
-
软件方法、体系和过程的思考
2007-12-14
哲学研究的对象是物质的存在、联系和运动。
软件工程研究的对象是软件技术、方法、过程和工具。
近三十年来软件方法层出不穷，被实际开发所运用的软件方法曾达两三百种之巨。但我们通过对哲学研究的角度进行相关的类比，我们不难发现，这些软件方法归根结底不外乎下面三种角度。
1. 基于物质运动角度：着眼于物质本身，强调物质作为一个整体对外界作用的动态交互，在软件开发方法中体现为基于功能角度的观点。著名的方法有结构化分析方法，强调软件系统（或子系统）的输入和输出，内部对外不可见，处理时宜至上向下，逐层分解，如医学之解剖一般，化整为零。
2. 基于物质联系角度：着眼物质的存在与物质间的恒定关系，强调物质间的层次性和主体地位性，在软件开发方法中体现为基于实体（Entity）角度的观点，分析的重心为对实体的静态描述和恒定联系的界定，这种角度无视实体之间的运动交互，数据库设计的E-R方法即是该观点的典型方法。例如学生的选课系统，我们关心的是学生选的是哪门课程，而不是选课的过程如何进行的。
3. 基于物质存在状态角度：着眼物质系统的自身的存在状态，分析各种存在状态间的变迁缘由和变迁途径。在软件开发方法中常为实时领域所独领风骚，体现为状态迁移分析。常见的例子有十字路口的交通灯模型，我们通过分析灯组的状态变化来对其进行分析和仿真。
近来风靡一时的面向对象方法，兼具上述的物质运动角度与联系角度的特色，诸如对象（Object），类（Class），继承（Inherence）之类的概念，基于的是物质联系的角度；函数（Function）和方法（Method）之概念，基于的是物质运动的角度。我们随便举一个基于存在角度的例子，UML的状态图，它反映了单一对象的各种存在状态，因此广泛应用于实时系统的设计之中。
接下来谈谈体系的问题。
凡方法、体系，皆如哲学的内涵与外延。外延宽广则内涵浅，外延狭窄则内涵丰富。翻译成行业用语即：高效的体系适应范围比较窄，低效的体系适应范围广。由此断定，软件行业无一包治百病，立竿见影，药到病除的狗皮膏药体系和方法。诸多企业、项目应当考虑自身实际，借以标准，适当增删修正，以合自身病症，而不是一味照单全收。君不见如今中国的软件行业，利火攻心，ISO9000做烂了，CMM/CMMI也开始泛滥成灾。暗地高兴的只有那些兜售标准的认证企业，因为他们更关心的腰包里的钱袋。
最后要谈软件过程的问题，过程离不开环境。软件开发更像是一个生态进化，我们应该把软件开发作为一个不断进化的生态体系来看待，强调各方面的和谐有序。一味追求软件过程而忽视相关的环境（行业环境，企业环境）最后的结果只能是侏罗纪的恐龙，在开发生态被破坏的同时自己亦随之消亡。所以我们常常会提到：软件过程和开发方法要结合企业自身的实际。过度的追求标准、规范最终的结果是从体力上和脑力上压倒了整个团队，继而压垮整个企业。在这里我们的意思并不是说标准和规范不重要，但不要让标准和规范成为一张白纸或是开发团队、企业的沉重负担。因此每个企业和项目团队有必要根据自身的环境、规模和资源配置选择合适的软件开发方法和过程。 -
数据库设计走查表（为thinker本人所原创，版权所有）
2007-12-14
前期准备
1 概念层次的ER图和数据库定义书准备齐全
2 ER图关联简洁
3 ER图结构清晰
4 ER图实体个数适中
5 ER图无重复冗余
6 存在原有系统的情况下，对旧系统的数据库进行了整理，本次设计中保留原有数据库的设计优点
7 存在原有系统的情况下，注意原有数据库系统中一些忽略的问题
8 存在原有系统的情况下，进行了数据库方面的设计对比
9 设计采用了CASE工具
10 数据字典完备
11 设计时考虑了将来哪些数据字段可能会发生变更
12 设计时考虑了不同国家，地区可能存在的字段和字段格式
13 设计时考虑了数据库的版本标识
14 设计时考虑了将来的数据挖掘和分析需求
15 使用英文而不是其它语言，编码来作为设计语言
16 存在一数据库标识机制来反映数据库的当前版本和相关配置信息
17 数据库设计时考虑到了备份的安全机制
18 数据库设计时尽量不考虑取值CHECK，有关CHECK的东西通过页面输入检查来解决
表设计
19 实体有主键或有外键，或二者兼备
20 多对多关系被映射为三张基本表
21 基本表的字段不能再分解
22 基本表的数据均来自于用户人工输入或系统设定
23 基本表结构稳定，短期之内不再变化
24 基本表尽量满足3范式，符合2范式
25 根据用户统计，时间统计等统计需求建立中间表
26 临时表是临时的
27 表个数足够精简（多字段分表情况例外）
28 对于多值字段采用了创建子表的做法或预留了足够的字段来存储不同的值
29 表中存在合理的派生性冗余字段或无冗余字段
30 表中字段足够精简，不存在重复性冗余字段
31 有多种权限设计的时候采用用户－权限设计方式
32 表设计包括了管理员(用户)的账号管理设计
数据库
33 数据库命名使用小写英语字母， 数字和下划线，无其他字符
34 数据库命名长度小于20位
35 数据库命名采用项目名或产品名称命名
36 数据库中的所有表字符集统一
37 数据库中对象命名见名知意
38 数据库对象的命名不使用保留关键字
39 数据库设计考虑到了事务机制
40 数据库设计考虑到将来可能存在的异种数据库迁移
41 数据库设计时考虑到了审计追踪机制（警告等）
表
42 组合主键的字段数量不超过3个
43 采用了系统自增字段作为主键
44 不同表的同一意义的字段名称和类型一致（特别是外键场合）
45 为关联字段创建外键
46 所有键取值唯一
47 外键是关联唯一的字段
48 使用商务规则约束数据完整性
49 表的id字段和name字段命名时采用表名_id（name）的形式
50 不存在只有写入没有读取的表
51 不用可能被更新或经常更新的字段作为主键
52 表设计不存在级联性删除
字段
53 字段与画面项目能够一一对应（部分标识符字段和系统设定字段除外）
54 索引是多值字段
55 索引是单一字段
56 字段取值符合域定义
57 字段名称见名知意
58 多个表中出现同一类型字段用表前缀来标识
59 字段的类型和长度能够满足字段的值的最大限量
60 文本字段有充足的余量对应可能的长度变更
61 数字字段考虑了充足的余量和精度对应可能的长度或精度变更
62 不给MEMO（Mysql TEXT类型）之类的大字段建索引
63 为每种查询都建立索引
64 加一个标识更新时间的Datetime字段update_time，不使用mySQL 的timestamp类型。
65 加入一个表示记录插入时间的时间字段create_time, datetime
66 布尔值一律为INTERGER类型
67 有小数的字段使用Integer， 而不用float 等字段
68 普通时间字段使用Integer 或者Datetime
69 如果报表中可能分别按年，月，日进行排序和分组。则把时间字段分成不同的年月日字段
70 支持多国， 则数据库中必须存格林威治时间
71 不需要区别NULL和空字符串的地方，数据表设计时标上NOT NUL
72 用程序逻辑控制Default值， 而不是让数据库控制默认值
73 表中采用了DEL_FLAG字段标明删除
74 表中采用了IS_VALID(CANCEL_FLAG)标明有效性
75 采用了存放路径而不是存放图片（文件）本身的方式来保存图片数据或文件数据
76 Password只存单向加密过的密码， 而不是密码本身
"存储过程-视图-触发器"
77 针对客户的特定应用采用了视图机制
78 采用了常规的存储过程来替代和简化客户程序代码的开发
79 少用触发器，多用存储过程
80 缺乏约束的数据库系统中，采用了触发器用来加强参照和数据完整性
优化
81 计算复杂时，以文件形式处理后才追加至数据库中而不是在数据库中直接计算
82 表记录字段太多时，采用垂直分割（超过80个以上）
83 表记录太多时，采用水平分割（分表）
84 SQL语句符合“先投影后连接再更新”的优化规则
85 所有SQL语句都充分地得到优化
86 数据库管理系统参数均得以优化
87 支持数据库的硬件指标符合项目需求
88 优化设计过程中考虑了“程序优化”，“数据库优化”和“系统优化”三个层次的优化
89 分布式数据库设计时充分考虑了80－20规则
90 XXXX数据库时使用XXXXX作为数据库引擎 -
代码走查表（为thinker本人所原创，版权所有）
2007-12-14
走查前准备
1 得到一份解释代码的最新的设计文档
2 代码解释时使用了严格的警告和错误检查参数并被解释通过
3 代码使用带ISO标准的xxxx编译器进行解释
程序结构
4 所有代码的结构清晰，具有良好的结构外观和整齐
5 所有的模块（函数和外部接口）定义清晰，模块分解清楚
6 所有的功能需求都明显的覆盖
7 高层设计独立于OS/环境
8 结构设计能够满足机能变更
9 代码体系结构描述了如何把代码重用到其他体系结构中
10 整个代码体系结构组合合理
11 所有主要的数据构造描述清楚，合理
12 模块中所有的数据结构都定义为局部的，并且通过定义好的函数进行访问
13 为外部定义了良好的函数接口
14 所有的接口模块化，因此修改时不影响其他代码模块
15 内存使用方法和内存管理策略描述清楚和正确
16 代码体系构架对空间和速度都已经进行考虑
17 提供了处理数据的策略
18 具有同一的错误处理策略
19 通过一套清晰的函数接口提供错误信息
目录文件组织
20 所有的文件名符合文件命名规范，见名知意
21 文件和模块分组清晰
22 每个文件有文件头和标准的习惯一致（描述文件的用途，作者，对外提供的函数）23 每个文件都组织的有序 － 文件头，类型定义，原型，函数
24 所有的代码行在80字符以内
25 每个程序文件都小于2000行
26 每个文件只包含一个完整功能模块的代码
函数组织
27 每个函数都有一个标准的函数头声明
28 函数组织：头，函数名，参数，函数体
29 函数定义符合ANSI或者用标准PERL的编译开关
30 每个函数都能够在最多2页纸可以打印
31 所有的变量声明每行只声明一个
32 所有的函数名都小于64个字符
33 每个函数之间都用2空行进行分开
代码组织
34 每行代码都小于80字符
35 所有的变量名都小于32字符
36 所有的行每行最多只有一句代码或一个表达式
37 复杂的表达式具备可读性
38 续行缩进
39 括号在合适的位置
40 每个顺序的小块用空行隔开
41 注解和代码对齐或接续在代码之后
移植性
42 代码与操作系统无关，不需要任何假设条件
函数
43 函数头清楚地描述函数和它的功能
44 代码中有相关注解
45 函数的名字清晰的定义了它的目标以及函数所做的事情
46 函数的功能清晰定义
47 函数中所有的部分都合理的组成函数，相关独立的语句组组成函数
48 函数高内聚 只做一件事情，并做好
49 函数和其他代码松耦合
50 参数遵循一个明显的顺序；
51 所有的参数都被使用
52 函数的参数接口关系清晰
53 如果一个函数有返回值，在所有的出口都有返回值
54 函数使用了最少数目的return语句
55 函数的参数个数小于7个
56 所有的假设和接口清楚
57 使用的算法说明清楚
58 函数检查了输入数据的合法性
59 函数异常处理清楚
60 函数设计已经考虑了将来的变化
61 调试信息存在于代码中并容易激活
62 代码检查调用函数的返回值，参数和调用匹配
63 函数确保了没有影响函数外代码
64 递归定义了出口
65 递归局限于一个函数
66 堆栈大小支持递归调用的深度
数据类型与变量
67 数据类型存在数据类型解释
68 代码为每种可能改变数据类型的数据使用一个不同的类型
69 代码避免了重新定义预先定义的数据类型
70 数据结构简单以便降低复杂性
71 每一种变量分配了正确的长度、类型和存储空间
72 静态变量明确区分
73 所有的声明与编译器或具体的机器长度无关
74 每一个变量都初始化了
75 每一个变量都在接近使用它的地方才初始化
76 每一个变量都在将要使用它的时候才初始化
77 变量的命名完全、明确的描述了该变量代表什么
78 命名和现实生活中的事务接近而不仅仅是一个程序类型
79 同一种类型或指针命名的前缀指出类型或指针
80 命名不与标准库中的命名相冲突
81 程序没有使用特别的、易误解的、发音相似的命名
82 所有的变量都有最小的活动范围
83 所有的全局变量都描述清楚
84 使用函数访问取代全局数据的访问
85 所有的变量都用到了
86 存取数据的程序与全局数据的用法是兼容的
87 变量按照它的命名用途进行使用
特殊
88 所有的数组访问在它们的边界内
89 代码已经处理了-1错误
90 代码处理了指针异常
91 所有常量定义和使用替代代码中的数字
92 类型转换明确指明
其他注意项
93 代码与比较，计算变量的大小无关
94 代码与操作符的优先级无关
95 所有的表达式使用了正确的操作符
条件判断
96 条件检查和结果在代码中清晰
97 If/else 使用正确
98 普通的情况在if下处理而不是else
99 判断的次数降到最小
100 判断的次数不大于6次，无嵌套的if链
101 数字，字符，指针和0/NULL/FLSE 判断明确
102 boolen表达式表示清楚
103 最常用的情况最先判断
104 所有的情况都考虑
105 判断体足够短，以使得一次可以看清楚
106 嵌套层次小于3次
循环
107 循环体不为空
108 循环之前做好初始化代码
109 循环体能够一次看清楚
110 当有明确的多次循环操作，使用For循环
111 当有不明确的多次循环操作，while循环被使用
112 代码中不存在无穷次循环
113 循环的头部进行循环控制
114 循环索引具有有意义的命名
115 循环设计得很好它，只干一件事情
116 循环终止的条件清晰
117 循环体内的循环变量起到指示作用
118 循环嵌套的次数小于3次
输入输出
119 所有文件的属性描述清楚
120 所有OPEN/CREATE调用描述清楚
121 文件结束的条件进行检查
122 显示的文本无拼写和语法错误
注释
123 有一个简单的说明，用于描述代码的结构
124 每个文件和模块均以给予解释
125 源代码能够自我解释
126 每个人看到代码就能很快理解
127 解释说明代码功能，准确描述代码意义
128 解释不过于简单
129 注解清楚正确
130 注解为用户服务
131 所有的假设和限制进行注解
132 长的控制体结束，进行注解
总括
133 代码直观
134 代码中的用语符合广告用语，而不是技术化的描述
135 代码和设计文档对应
136 无用的代码已经删除
137 无用的注解已经删除 -
单元测试指导 (为thinker本人2001年所做，字字原创)
2007-12-14
一、单元测试环境配置测试
1. 网络连接是否正常
2. 网络流量负担是否过重
3. 软件测试平台是否可选
4. 如果（3），是否在不同的软件测试平台进行软件测试
5. 所选软件测试平台的版本（包括Service Pack）是否正确
6. 所选软件测试平台的参数设置是否正确
7. 所选软件测试平台上正在运行的其它程序是否会影响测试结果
8. 画面的分辨率和色彩设定是否正确
9. 对硬件测试平台的要求和支持程度
二、代码测试
A 静态测试
1. 同一程序内的代码书写是否为同一风格
2. 代码布局是否合理、美观
3. 程序中函数、子程序块分界是否明显
4. 注释是否符合既定格式
5. 注释是否正确反映代码的功能
6. 变量定义是否正确（长度、类型、存储类型）
7. 子程序（函数和方法）接受的参数类型、大小、次序是否和调用模块相匹配合
8. 函数的返回值类型是否正确
9. 程序中是否引用了未初始化变量
10. 数组和字符串的下标是否为整数
11. 数组和字符串的下标是否在范围内（不“越界”）
12. 进行数组的检索及其它操作中，是否会出现“漏掉一个这种情况”
13. 是否在应该使用常量的地方使用了变量（例：数组范围检查）
14. 是否为变量赋予不同类型的值
15. （14）的情况下，赋值是否符合数据类型的转换规则
16. 变量的命名是否相似
17. 是否存在声明过，但从未引用或者只引用过一次的变量
18. 在特定模块中所有的变量是否都显式声明过
19. 非（18）的情况下，是否可以理解为该变量具有更高的共享级别
20. 是否为引用的指针分配内存
21. 数据结构在函数和子程序中的引用是否明确定义了其结构
22. 计算中是否使用了不同数据类型的变量
23. 计算中是否使用了不同的数据类型相同但长度不同的变量
24. 赋值的目的变量是否小于赋值表达式的值
25. 数值计算是否会出现溢出（向上）的情况
26. 数值计算是否会出现溢出（向下）的情况
27. 除数是否可能为零
28. 某些计算是否会丢失计算精度
29. 变量的值是否超过有意义的值
30. 计算式的求值的顺序是否容易让人感到混乱
31. 比较是否正确
32. 是否存在分数和浮点数的比较
33. 如果（32），精度问题是否会影响比较
34. 每一个逻辑表达式是否都得到了正确表达
35. 逻辑表达式的操作数是否均为逻辑值
36. 程序中的Begin…End和Do…While等语句中，End是否对应
37. 程序、模块、子程序和循环是否能够终止
38. 是否存在永不执行的循环
39. 是否存在多循环一次或少循环一次的情况
40. 循环变量是否在循环内被错误地修改
41. 多分支选择中，索引变量是否能超过可能的分支数
42. 如果（41）,该情况是否能够得到正确处理
43. 全局变量定义和用法在各个模块中是否一致
44. 是否修改了只作为输入用的参数
45. 常量是否被作为形式参数进行传递
B 动态测试
1. 测试数据是否具有一定的代表性
2. 测试数据是否包含测试所用的各个等价类（边界条件、次边界条件、空白、无效）
3. 是否可能从客户那边得到测试数据
4. 非（3）的情况下，所用的测试数据是否具有实际的意义（客户业务上的）
5. 是否每一组测试数据都得到了执行
6. 每一组测试数据的测试结果是否与预期结果一致
7. 文件的属性是否正确
8. 打开文件语句是否正确
9. 输入/输出语句是否与格式说明书所记述的一致
10. 缓冲区大小与记录长度是否匹配
11. 使用文件前是否已打开了文件
12. 文件结束条件是否存在
13. 产生输入/输出错误时，系统是否进行检测并处理
14. 输出信息中是否存在文字书写错误和语法错误
15. 数字输入框是否接受数字输入
16. （15）的情况下、数字是否按既定格式显示
17. 数字输入框是否拒绝字符串和“非法”数字的输入
18. 组合框是否的能够进行下拉选择
19. 组合框是否能够进行下拉多项选择
20. 对于可添加数据组合框，添加数据后数据是否能够得到正确显示和进行选择
21. 列表框是否能够进行选择
22. 多项列表框是否能够进行多数据项选择
23. 日期输入框是否接受正确的日期输入
24. 日期输入框是否拒绝错误的日期输入
25. 日期输入框在日期输入后是否按既定的日期格式显示日期
26. 单选组内是否有且只有一个单选钮可选
27. 如果单选组内无单选钮可选，这种情况是否允许存在
28. 复选框组内是否允许多个复选框（包括全部可选）可选
29. 如果复选框组内无复选框可选，这种情况是否允许存在
30. 文本框及某些控件拒绝输入和选择时显示区域是否变灰或按既定规约处理
31. 文本框中数据格式（大小、对齐方向、颜色、背景）是否符合规范
32. 密码输入框是否按掩码的方式显示
33. 控件是否存在默认输入值，若存在，默认值是否得到显示和提交
34. Cancel之类的按钮按下后，控件中的数据是否清空复原或按既定规约处理
35. Submit之类的按钮按下后，数据是否得到提交或按既定规约处理
36. 异常信息表述是否正确
37. 软件是否按预期方式处理错误
38. 文件或外设不存在的情况下是否存在相应的错误处理
39. 软件是否严格的遵循外设的读写格式
40. 产生的文件和数据表的格式是否正确
41. 产生的文件和数据表的计算结果是否正确
42. 打印的报表是否符合既定的格式
43. 错误日志的表述是否正确
44. 错误日志的格式是否正确
C GUI测试
1. 窗体是否能够基于相关的输入或菜单命令适当的打开
2. 窗体是否能够改变大小、移动和滚动
3. 窗体的数据是否能够利用鼠标、功能键、方向箭头和键盘操作
4. 当窗体被覆盖并重新调用后，窗体是否能够正确再生
5. 窗体相关的功能是否可以操作
6. 是否显示相关的下拉菜单、工具条、滚动条、对话框、按钮、图标和其他控制，既能正确显示又能调用
7. 显示多窗体时，窗体名称是否能够正确表示
8. 活动窗体是否能够被反显加亮
9. 多用户联机时所有窗体是否能够实时更新
10. 鼠标无规则点击时是否会产生无法预料的结果
11. 窗体声音及提示是否符合既定编程规则
12. 窗体是否能够被关闭
13. 窗体控件的大小、对齐方向、颜色、背景等属性的设置值是否和程序设计规约相一致
14. 窗体控件布局是否合理、美观
15. 窗体控件TAB顺序是否从左到右，从上到下
16. 窗体焦点是否按照编程规范落在既定的控件上
17. 窗体画面文字（全、半角、格式、拼写）是否正确
18. 鼠标有多个形状时是否能够被窗体识别（如漏斗状时窗体不接受输入）