产品生命周期 PH0 产品概念 PH1 产品定义 PH2 产品开发 PH3 产品验证 PH4 用户验收 PH5 产品维护 项目管理过程 ．．．．．．立项管理 项目计划 项目监控 风险管理 需求管理 外包管理 管 理 所 有 的 技 术 开 发 活 动 结项管理 需求开发 技术预研 技术评审 迭代 系统设计 实现与测试 技术开发过程 ．．．．．．根据产品特征确定最合适的开发模型， 如瀑布模型、迭代模型等。 系统测试 用户验收 软件维护 支 撑 所 有 的 技 术 开 发 活 动 支撑过程 ．．．．配置管理 质量保证 采购管理 培训管理 图1-2 精简并行过程（SPP）模型
SPP模型把产品生命周期划分为6个阶段： ? 产品概念阶段，记为PH0。 ? 产品定义阶段，记为PH1。 ? 产品开发阶段，记为PH2。 ? 产品验证阶段，记为PH3。 ? 用户验收阶段，记为PH4。 ? 产品维护阶段，记为PH5。
在SPP模型中，一个项目从PH0到PH5共经历19个关键过程域（Key Process Area, KPA），它们被划分为三大类过程，如表1-2所示。其中项目管理过程含7个关键过程域，技术开发过程含8个过程域，支撑过程含4个过程域。
过程类别 ? 项目管理过程 ? 立项管理 ? 技术开发过程 ? 需求开发 ? 支撑过程 ? 配置管理 5
关键过程域 ? ? ? ? ? ? 结项管理 项目计划 项目监控 风险管理 外包管理 需求管理 ? ? ? ? ? ? ? 技术预研 系统设计 实现与测试 系统测试 用户验收 软件维护 技术评审 ? ? ? 质量保证 采购管理 培训管理 表1-2 SPP过程域分类
SPP模型的主要优点有：
（1）模型直观。SPP模型是三层结构，上层是项目管理过程的集合，中层是技术开发过程的集合，下层是支撑过程的集合。这种模型很直观，高级经理、项目经理、开发人员、质量保证员等人根据SPP模型很容易知道自己“应该在什么时候做什么事情，以及按照什么规范去做事情”。SPP模型有助于使各个过程的活动有条不紊地开展。
（2）方便于用户裁剪SPP模型。项目管理过程和支撑过程对绝大多数软件产品开发而言都是适用的。需求开发、技术预研、系统设计、编程、测试、技术评审、维护都是技术开发过程中必不可少的环节，用户可以根据产品的特征确定最合适的开发模型（例如瀑布模型、快速原型模型、迭代模型等）。
（3）方便于用户扩充SPP模型。如果产品同时涉及软件硬件开发的话，可将产品生命周期、软件开发过程和硬件开发过程集成一起。
1.4.2 复用
复用就是指“利用现成的东西”，文人称之为“拿来主义”。被复用的对象可以是有形的物体，也可以是无形的知识成果。复用不是人类懒惰的表现而是智慧的表现。因为人类总是在继承了前人的成果，不断加以利用、改进或创新后才会进步。所以每当我们欢度国庆时，要清楚祖国远不止50来岁，我们今天享用到的财富还有历史上几千年中国人民的贡献。进步只是应该的，没有进步则就可耻了。
复用的有利于提高质量、提高生产率和降低成本。由经验可知，通常在一个新系统中，大部分的内容是成熟的，只有小部分内容是创新的。一般地可以相信成熟的东西总是比较可靠的（即具有高质量），而大量成熟的工作可以通过复用来快速实现（即具有高生产率）。勤劳并且聪明的人们应该把大部分的时间用在小比例的创新工作上，而把小部分的时间用在大比例的成熟工作中，这样才能把工作做得又快又好。
把复用的思想用于软件开发，称为软件复用。技术开发活动与管理活动中的任何成果都可以被复用，如思想方法、经验、程序、文档等等。据统计，世上已有1000亿多行程序，无数功能被重写了成千上万次，真是浪费哪。面向对象（Object Oriented）学者的口头禅就是“请不要再发明相同的车轮子了” 。
将具有一定集成度并可以重复使用的软件组成单元称为软构件(Software Component)。软件复用可以表述为：构造新的软件系统可以不必每次从零做起，直接使
6
用已有的软构件，即可组装或加以合理修改后成为新的系统。
复用方法合理化并简化了软件开发过程，减少了总的开发工作量与维护代价，既降低了软件的成本又提高了生产率。另一方面，由于软构件是经过反复使用验证的，自身具有较高的质量。因此由软构件组成的新系统也具有较高的质量。
软件复用不仅要使自己拿来方便，还要让别人拿去方便，是“拿来拿去主义”。这想法挺好，但现实中执行得并不如意。企业的业务各色各样，谁也不能坐等着天上掉下可以被大规模复用的东西，一般要靠“日积月累”才能建设可以被复用的软件库。从理论上讲这项工作没有不可逾越的技术障碍。真正的障碍是它“耗时费钱”，前期投入较多，缺乏近期效益。大部分的公司都注重近期效益，不是它天生目光短浅，而是为了生存必须这么做。有些处境艰难的公司下一顿饭还不知道在何处着落，更别提软件复用这样的“长久之计”了。所以软件复用对大多数公司来说不是“最高优先级”。
我到公司工作的最初安排是从事电信领域“可复用软件工厂”的开发。领导在招聘时跟我讲，这个想法已经有数年了，一直没有落实，希望我能做好。待我正式上班时，马上就改成做其它短期的研发项目了。要知道我所在的公司人力与财力相当充足，非国内普通中小型IT企业所能比。即便我们有如此好的条件，软件复用也只是挂在嘴上，没有实际行动。
所以我建议：随时随地尽可能地复用你所能复用的东西，不要等待公司下达复用的行政命令，因为你很难等到那一天，即使等到了也没有多少意义。
1.4.3 分而治之
分而治之是指把一个复杂的问题分解成若干个简单的问题，然后逐个解决。这种朴素的思想来源于人们生活与工作的经验，完全适合于技术领域。
分而治之说起来容易，做好却难，最糟糕的现象是“分是分了”却“治不了”。 软件的分而治之不可以“硬分硬治”。不像为了吃一个西瓜或是一只鸡，挥刀斩成n块，再把每块塞进嘴里粉碎搅拌，然后交由胃肠来消化吸收，象征复杂问题的西瓜或是鸡也就此消失了。
软件的“分而治之”应该着重考虑：复杂问题分解后，每个问题能否用程序实现？所有程序最终能否集成为一个软件系统并有效解决原始的复杂问题？图1-3表示了软件的“分而治之”策略。软件的模块化设计就是分而治之的具体表现。
7
复杂 问题 解决原始问题 软件 系统 子问题1 程序1 子问题2 程序2 子问题n 程序n 图1-3 软件的分而治之策略
1.4.7 质量保证
质量保证（Quality Assurance, QA）的目的是提供一种有效的人员组织形式和管理方法，通过客观地检查和监控“过程质量”与“产品质量”，从而实现持续地改进质量。质量保证是一种有计划的、贯穿于整个产品生命周期的质量管理方法。
过程质量与产品质量存在某种因果关系，通常“好的过程”产生“好的产品”而“差的过程”将产生“差的产品”。人们销售的是产品而不是过程，用户关心的是最终产品的质量，而软件开发团队既要关心过程质量又要关心产品质量。
质量保证的基本方法是通过有计划地检查“工作过程以及工作成果”是否符合既定的规范，来监控和改进“过程质量”与“产品质量”。如果“工作过程以及工作成果”不符合既定的规范，那么产品的质量肯定有问题。基于这样的推理，质量保证人员即使不是技术专家，他也能够客观地检查和监控产品的质量。这是质量保证方法富有成效的一面。但是“工作过程以及工作成果”符合既定的规范却并不意味着产品的质量一定合格，因为仅靠规范无法识别出产品中可能存在的大量缺陷。这是质量保证方法的不足之处。所以单独的“质量保证”其实并不能“保证质量”。
技术评审与测试关注的是产品质量而不是过程质量，两者的技术强度比质量保证要高得多。技术评审和测试能弥补质量保证的不足，三者是相辅相成的质量管理方法。我们在实践中不能将质量保证、技术评审和测试混为一谈，也不能把三者孤立起来执行。建议让质量保证人员参加并监督重要的技术评审和测试工作，把三者有机地结合起来，可提高工作效率，降低成本。
质量保证小组（Quality Assurance Group, QAG）有如下特点：
? 质量保证小组在行政上独立于任何项目。这种独立性有助于质量保证小组客观
地检查和监控产品的质量。
? 质量保证小组有一定的权利，可以对质量不合格的工作成果做出处理。这种权
利使得质量保证小组的工作不会被轻视，并有助于加强全员的质量意识。需要强调的是，提高产品质量是全员的职责，并非只是质量保证小组的职责。
8
质量保证过程域的主要活动如图1-5所示。
周期性地开展 制定质量保证计划 过程与产品质量检查 问题跟踪与质量改进 参加技术评审 --------- 表示质量保证与 技术评审、测试有机结合 参加测试 图1 质量保证过程域示意图
1.4.8 改错
改错是个大悲大喜的过程，一天之内可以让人在悲伤的低谷和喜悦的颠峰之间跌荡起伏。如果改过了成千上万个程序错误，那么少男少女们不必经历失恋的挫折也能变得成熟起来。
我从大三开始真正接受改错的磨练，已记不清楚多少次汗流浃背、湿透板凳。改不了错误时，恨不得撞墙。改了错误时，比女孩子朝我笑笑还开心。
在做本科毕业设计时，一天夜里，一哥们流窜到我的实验室，哈不拢嘴地对我嚷嚷：“你知道什么叫茅塞顿开吗？” 我象文盲似地摇摇头。
他说：“今天我化了十几个小时没能干掉一个错误，刚才我去了厕所五分钟，一切都解决了。”
他还用那没洗过的手拉我，一定要请我吃“肉夹馍”。那得意劲儿仿佛同时谈了两个女朋友。
软件中的错误通常只有开发者自己才能找出并改掉。如果因畏惧而拖延，会让你终日心情不定，食无味，睡不香。所以长痛不如短痛，要集中精力对付错误。
东北有个林场工人，工作勤奋，一人能干几个人的活。前三十年是伐树劳模，受到周总理的接见。忽有一天醒悟过来，觉得自己太对不起森林，决心补救错误。后三十年成了植树劳模，受到朱总理的接见。若能以此大勇来改错，正是无往而不胜也。我们软件开发人员应当向这位可敬的林场工人学习。
改错过程很像侦破案件，有些坏事发生了，而仅有的信息就是它的确发生了。我们必须从结果出发，逆向思考。改错的第一步是找出错误的根源，如同医生治病，必须先找出病因才能“对症下药”。
有人问阿凡提：“我肚子痛，应该用什么药？”
阿凡提说：“应该用眼药水，因为你眼睛不好，吃了脏东西才肚子痛。” 根据软件错误的症状推断出根源并不是件容易的事，因为：
9