软件工程思想3
第三章 项目计划与质量管理 在可行性分析之后，项目计划与质量管理将贯穿需求分析、系统设计、程序设计、测 试、维护等软件工程环节。 项目计划是要提供一份合理的进程表，让所有开发人员任务明确、步调一致，最终共 同准时地完成项目。项目计划是要付诸实施的，不象用嘴巴喊政治口号，可以很夸张。 软件的项目计划重在“准确”而非“快速”。 提高质量是软件工程的主要目标。但由于软件开发是一种智力创作活动，很难象传统 工业那样通过执行严格的操作规范来保证软件产品的质量。世上最小心翼翼、最老实巴 脚的程序员未必就能开发出高质量的软件来。程序员必须了解软件质量的方方面面（称 为质量因素），如正确性、性能、易用性、灵活性、可复用性、可理解性等等，才能在 进行系统设计、程序设计时将高质量内建其中。软件的高质量并不是“管理”出来的，实 质上是设计出来的，质量的管理只是一种预防和认证的手段而已。 3.1 项 目 计 划 做项目计划，如同给一个待出生的婴儿写传记那样困难。如果允许项目结束后再写计 划，那就轻松多了，并且可以100% 地准确。 历史教训让我们明白一个道理：如果一万年以后才会有一条阳光大道通向共产主义， 那么现在就不要忙着砸锅炼钢赶英超美，免得在跑步奔向共产主义时把自己累死饿死。 在做软件的项目计划时，应屏弃一切浮夸作风。只有“知已知彼”才能做出合理的项目计 划。这里“知彼”是指要了解项目的规模、难度与时间限制。“知已”是指要了解有多少可 用资源，如可调用的程序员有几个？他们的水平如何？软硬件设施如何？ 3.1.1 知己知彼 首先要了解项目的规模、难度与时间限制，才可以确定应该投入多少人力、物力去做 这个项目。在可行性分析阶段就要考虑这个问题。但不幸的是，人们在陷入项目不能自 拨之前总难以准确地估计项目的规模与难度。这里经验起到了最重要的作用。 项目的时间限制有两类。第一类，项目应该完成的日期写在合同中，如果延期了，则 开发方要作出相应的赔偿。第二类是开发自己的软件产品，虽然只确定了该产品大致的 发行日期并允许有延误，但如果拖延太久则会失去商机造成损失。 项目的资源分为三类：“人”、“可复用的软构件”和“软硬件环境”，如图3.1所示。（ １）人是最有价值的资源。项目计划的制定者要确定开发人员的名单，要根据他们的专 长进行分工。 （２）可复用的软构件是次有价值的资源。1.2.1节论述了复用软构件可提高软件的质量 与生产率。软构件并非一定要用自己的，可以向专业的软件供应商购买。 （３）软硬件环境虽然不是最重要的资源，却是必需的资源。原则上软硬件环境只要符 合项目的开发要求即可。有些项目可能要用到特殊的设备，则要事先作好准备，以免用 时找不到而担搁了进程。 图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.2 软件质量因素分类和武学分类 3.3.1 正确性与精确性 正确性与精确性之所以排在质量因素的第一位，是因为如果软件运行不正确或者不精 确，就会给用户造成不便甚至造成损失。机器不会主动欺骗人，软件运行不正确或者不 精确一般都是人造成的。即使一个软件能100% 地按需求规格执行，但是如果需求分析错了，那么对客户而言这个软件也存在错误。即 使需求分析完全符合客户的要求，但是如果软件没有100% 地按需求规格执行，那么这个软件也存在错误。开发一个大的软件项目，程序员要为“正 确”、“精确”四个字竭尽精力。 与正确性、精确性相关的质量因素是容错性和可靠性。 容错性首先承认软件系统存在不正确与不精确的因素，为了防止潜在的不正确与不精 确因素引发灾难，系统为此设计了安全措施。在一些高风险的软件系统，如航空航天、 武器、金融等系统中，容错性设计非常重要。 可靠性是指在一定的环境下，在给定的时间内，系统不发生故障的概率。可靠性本来 是硬件领域的术语。比如某个电子设备，一开始工作很正常，但由于工作中器件的物理 性质会发生变化（如发热），慢慢地系统就会失常。所以一个设计完全正确的硬件系统 ，在工作中未必就是可靠的。软件在运行时不会发生物理性质的变化，人们常以为如果 软件的某个功能是正确的，那么它一辈子都是正确的。可是我们无法对软件进行彻底地 测试，无法根除软件中潜在的错误。平时软件运行得好好的，说不准哪一天就不正常了 ，如“2000年”问题。因此把可靠性引入软件领域是有意义的。我曾买了一本关于软件可 靠性的著作，此书充满了数学公式。我发现以我目前的学历实在难以看懂书上讲了些什 么。请宽恕我的愚昧，我把此书给“供”起来，没敢用笔画一处记号。 3.3.2 性能与效率 用户都希望软件的运行速度高些（高性能），并且占用资源少些（高效率）。旧社会 地主就是这么对待长工的：干活要快点，吃得要少点。程序员可以通过优化算法、数据 结构和代码组织来提高软件系统的性能与效率。优化的关键工作是找出限制性能与效率 的“瓶颈”，不要在无关痛痒的地方瞎忙乎。如果你想职称升得快，光靠增加课时能顶屁 用；你就该一年写它几十篇文章，争取破格升教授。 3.3.3 易用性 易用性是指用户感觉使用软件的难易程度。用户可能是操作软件的最终用户，也可能 是那些要使用源代码的程序员。现代人的生活节奏快，干啥事都想图个方便。所以把易 用性作为重要的质量因素无可非议。 导致软件易用性差的根本原因是开发人员犯了“错位”的毛病：他以为只要自己用起来 方便，用户也一定会满意。俗话说“王婆卖瓜，自卖自夸”。当程序员向用户展示软件时 ，常会得意地讲：“这个软件非常好用，我操作给你看，……是很好用吧！”软件的易用性 要让用户来评价。当用...
软件工程思想3