1.3 人们关注的不仅仅是质量

企业开发产品的目的是赚钱，为了使利润最大化，人们希望软件开发工作“做得好、做得快，并且少花钱”。用软件工程的术语来讲，即“提高质量、提高生产率，并且降低成本”。古代哲学家曾为“鱼与熊掌不可兼得”的问题费尽心思，我们现在却梦想鱼、熊掌、美酒三者兼得，现代人的欲望真是无止境啊。

让我们先谈谈质量、生产率和成本之间的关系。

1.3.1 质量、生产率和成本之间的关系

质量无疑是客户最关心的问题。客户即使不图物美价廉，也要求货真价实。软件开发商必须满足客户对质量的要求（不论是写在合同上的还是约定俗成的），否则做不成买卖。现在就连做盗版光盘生意的人也讲究质量，如果盘片不好，是可以退货的。高质量既是软件开发人员的技术追求，又是职业道德的要求。

在关注质量的同时，软件开发商又期望生产率能高些，并且成本能低些。老板和员工们谁不想用更少的时间赚更多的钱！

质量与生产率之间存在相辅相成的关系。高生产率必须以质量合格为前提。如果质量不合格，软件产品要么卖不出去，要么卖出去了再赔偿客户的损失。这种情况下“高生产率”变得毫无意义。别看开发商和客户双方的代表能在餐桌上谈笑风生，一旦出了质量问题，那就不会很亲热了。从短期效益看，追求高质量可能会延长软件开发时间，一定程度上降低了生产率。从长期效益看，追求高质量将使软件开发过程更加成熟和规范化。日积月累，当开发过程成熟到一定程度后，必将大大降低软件的测试和改错的代价，缩短产品的开发周期，实质上是提高了生产率，同时又获得了很好的信誉。所以质量与生产率之间不存在根本的对立。

提高质量与生产率需要一个过程，企业不可操之过急。一般地，软件过程能力比较低的企业（如低于CMM 2级），应该将质量放在第一位，生产率放在第二位，只有这样才可能持久地提高质量和生产率（“能力成熟度模型CMM”将在1.3.2节介绍）。

如果一个企业的软件过程能力低于CMM 2级，表明其开发能力与管理能力还很薄弱。就其目前的实力而言，无论下多大的决心去做，都不可能一开始就把质量与生产率改善得一样好。并不是我们刻意贬低生产率的“地位”，是公司的现实情况要求在质量与生产率之间分个“轻重缓急”。由于人们天生就有“急功近利”的倾向，如果公司领导人认可“生产率第一、质量第二”，那么员工们做着做着必定会回到混乱的局面。这样的教训实在是太多了！老话说得好：磨刀不误砍柴工，用它类比上述理念最合适不过了。

俗话说“一分钱一分货”，人们买东西的时候大多认可“质量越好价格就越高”。除了垄断性的产品外，一般来说成本是影响价格的主要因素。

对于软件开发而言，质量与成本之间有什么关系？高质量必然会导致高成本吗？

经验表明，如果软件的“高质量”是“修补”出来的，毫无疑问会导致低生产率和高成本。如果能研制出某些好方法，将高质量与高生产率内建于开发过程之中，那么就能自然地降低开发成本，这是软件过程改进的目标。

要提醒大家的是，大公司与小公司对成本的关注程度是不尽相同的。

首先谈一下“市场价”（Marketing Price）与“成本价”（Cost Price）的概念。在某个领域，当市场上只出现尚未形成竞争格局的一个或几个产品时，产品价格基本上是由厂商自己制定的，这里称其为“市场价”。由于缺乏竞争，无论成本多高，产品总能获得高额利润。电影《大腕》里那个搞房地产的精神病人说“不求最好，但求最贵”，真是实话实说。

当产品之间形成竞争时，就会出现“杀价”现象。由于各家产品的功能、质量旗鼓相当，竞争实质上是在拼成本。谁的成本低，谁就有利可图。这时的产品价格称为“成本价”。

由于“市场价”与“成本价”的差价悬殊，IT行业的大公司都想吃“市场价”这块肥肉。大公司的资金雄厚，销售力量强，只要能抢先推出产品，就不愁卖不出去。怎样才能达到目的呢？通常有两种方式。

一种方式是从别处购买快要成型的产品，改头换面，贴上大公司的标签就可以上市销售。所以IT行业的“公司收购”特别盛行。如果Cisco公司的网络产品全部让原班人马来开发，它很难那么快就发展成为网络业的霸主！

另一种方式是自行开发新产品，让公司的研发队伍加班加点地干活。这么辛苦是值得的，产品成功会让员工们有很大的成就感。

无论通过哪种方式抢先推出产品，前提条件都要求产品的质量合格。如果产品因质量不合格而被市场拒绝，那么损失的不仅仅是成本，更惨重的是失去机会和信誉。像Intel这样了不起的公司也会吃败仗。每当Intel公司的CPU芯片出现缺陷时，就会骂声一片。Intel公司不得不大量回收芯片并向用户道歉，此时竞争对手（如AMD公司）就会乘虚而入，抢走像IBM、Compaq这些大客户的部分订单。

在信息高度发达的社会里，你能想得到的产品别人也能想得到。只有少数大公司能够享受到“市场价”的利益，但是好景不会太长。大多数公司在大部分时间里开发的是“成本价”的产品。所以树立“降低开发成本”的理念仍然十分重要。

1.3.2 软件过程改进的基本概念

在20世纪70～80年代，软件工程的研究重点是需求分析、系统设计、编程、测试、维护等领域的方法、技术和工具，我们称为经典软件工程。

现代的软件技术、软件开发工具比几十年前不知好多少倍，而且几乎所有的开发人员都学习过分析、设计、编程、测试等技能，可是如今绝大多数软件项目依然面临着质量低下、进度延误、费用超支这些老问题。

人们逐渐意识到，由于机构管理软件过程的能力比较弱，常常导致项目处于混乱状态，过程的混乱使得新技术、新工具的优势难以体现。经典的软件工程不是不好，而是不够用。自20世纪90年代至今，软件过程改进成为软件工程学科的一个主流研究方向，其中CMM和CMMI是该领域举世瞩目的重大成果。

首先解释什么是过程。过程就是人们使用相应的方法、规程、技术、工具等将原始材料（输入）转化成用户需要的产品（输出）。过程的3个基本要素是：人、方法与规程、技术与工具，如图1-1所示。可以把过程比喻为3条腿的桌子，要使桌子平稳，这3条腿必须协调好。

从图1-1可知，过程与产品存在因果关系，即好的过程才能得到好的产品，而差的过程只会得到差的产品。这个道理很朴实，但是很多人并未理解或者理解了却不执行。毕竟我们销售的是产品，而非过程。人们常常只把眼光盯在产品上，而忘了过程的重要性。例如，领导对员工们下达命令时总强调：“我不管你们如何做，反正时间一到，你们就得交付产品。”其实这是一句因果关系颠倒了的话，却在业界普遍存在。

在过程混乱的企业里，一批人累死累活地做完产品后，马上又因质量问题被折腾得焦头烂额。这种现象反反复复地发生，让人疲惫不堪。怎么办？长痛不如短痛，应该下决心，舍得花精力与金钱去改进软件过程能力。

CMM（Capability Maturity Model）是用于衡量软件过程能力的事实上的标准，同时也是目前软件过程改进最好的参考标准。CMM是由美国卡内基—梅隆大学（Carnegie-Mellon）软件工程研究所（Software Engineering Institute, SEI）研制的，其发展简史如下：

✧ CMM 1.0于1991年制定。

✧ CMM 1.1于1993年发布，该版本应用最广泛。

✧ CMM 2.0草案于1997年制定（未广泛应用）。

✧ 到2000年，CMM演化成为CMMI（Capability Maturity Model Integration），CMM 2.0成为CMMI 1.0的主要组成部分。

✧ CMMI-SE/SW 1.1（CMMI for System Engineering and Software Engineering）于2002年1月正式推出。

CMM将软件过程能力分为5个级别，最低为1级，最高为5级。目前国内只有几家IT企业达到了CMM 2级或CMM 3级。鉴于CMM已经被美国、印度软件业广为采纳，并且取得了卓著成效，近两年来国内兴起了CMM热潮。CMM受欢迎的程度远远超过了ISO同类标准。

国内IT企业采用CMM的目的大体有两种：

（1）主要想提高企业的软件过程能力，但并不关心CMM评估。

（2）既要提高企业的软件过程能力，又想通过CMM评估来提升企业的威望与知名度。

出于第一种考虑的企业占绝大多数，它们主要是一些中小型IT企业。出于第二种考虑的一般是实力雄厚的大型IT企业。无论是哪类IT企业，它们在实施CMM时遇到的共性问题是“费用高、难度大、见效慢”。

企业做一次比较完整的CMM 2～3级咨询和评估大约要花费60万元～100万元。然而CMM咨询师只能起到“参谋”的作用，解决实际问题还得靠自己。企业要组建软件工程过程小组（Software Engineering Process Group, SEPG）专门从事CMM研究与推广工作，SEPG的成本并不比咨询费低。如果企业再购买一些昂贵的软件工程工具（如Rational的产品），那么总成本会更高。

即使企业舍得花钱，也不意味着就能够轻易地提高软件过程能力。目前国内通过CMM 2-3级评估的企业屈指可数，而这些企业的实际能力也没有宣传的那么好。因为参加CMM评估的项目都是精心准备的，个别项目或者事业部通过了CMM评估并不意味着整个企业达到了那个水平，这里面的水分相当大。

曾经有一段时间，IT人士经常争论“CMM好不好”、“值不值得推广CMM”等话题。现在业界关注的焦点则是“企业如何以比较低的代价有效地提高软件过程能力”，攻克这个难题必将产生巨大的经济效益和社会效益。

一般地，为了真正提高软件过程能力，企业至少要做3件最重要的事情：

（1）制定适合于本企业的软件过程规范。

（2）对员工们进行培训，指导他们依据规范来开发产品。

（3）购买或者开发一些软件工程和项目管理工具，提高员工们的工作效率。

本书作者和合作者根据上述需求，研制了一套“软件过程改进解决方案”（Software Process Improvement Solution, SPIS）。SPIS的主要组成部分如下：

✧ 基于CMMI 3级的软件过程改进方法与规范，命名为“精简并行过程”（SPP）。

✧ 一系列培训教材，包括软件工程、项目管理、高质量C++/Java编程等，本书即为其中之一。

✧ 基于Web的集成化项目管理工具，包括项目规划、项目监控、质量管理、配置管理、需求管理等功能，命名为Future。