项目管理+软件开发摘录

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

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

而非“快速”。

提高质量是软件工程的主要目标。但由于软件开发是一种智力创作活动，很难象传统工业那样通过执行严格的操作规范来保证软件产品的质量。世上最小心翼翼、最老实巴脚的程序员未必就能开发出高

质量的软件来。程序员必须了解软件质量的方方面面（称为质量因素），如正确性、性能、易用性、灵活性、可复用性、可理解性等等，才能在进行系统设计、程序设计时将高质量内建其中。软件的高

质量并不是“管理”出来的，实质上是设计出来的，质量的管理只是一种预防和认证的手段而已。

3.1 项 目 计 划

做项目计划
在做软件的项目计划时，应屏弃一切浮夸作风。只有“知已知彼”才能做出合理的项目计划。这里“知彼”是指要了解项目的规模、难度与时间限制。“知已”是指要了解有多少可用资源，如可调用的

程序员有几个？他们的水平如何？软硬件设施如何？

3.1.1 知己知彼

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

的规模与难度。这里经验起到了最重要的作用。

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

果拖延太久则会失去商机造成损失。

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

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

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

3.1.2 进度安排

以下一些事件经常会导致项目被延误：

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

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

（3）低估了项目的规模与难度，导致投入的人力和物力不足。

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

（5）并未预见到开发人员会发生问题，如生病，辞职等等。

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

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

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

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

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

人群不混乱，不迷失方向。

（4）进度表中必须留有缓冲时间，并将缓冲时间用到不确定的事情上。因为人们对即将要做的事情知之甚少，所以要留一些时间以防不测。Microsoft公司的一些开发小组甚至制定了“50% 缓冲规则”

。对许多项目经理而言，容忍进度表中存在缓冲时间，不啻为观念上的一个飞跃。

（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分要付出更多的努力。“零缺陷”质量目标不是随心所欲提出来的，做得到才有意义。实现高目标需要一套可执行的规范来保证。

软件是如此的灵活，如果没有规范来制约，就容易因无序的喜好而导致混沌；但规范如果太严密了，就会扼杀程序员生机勃勃的创造力。制定软件规范是进退两难的事。程序员必须深入了解软件多方面

的质量因素，把那些能提高软件质量因素的各种规范植入脑中，才能在各个实践环节自然而然地把高质量设计到软件中。

3.3 软件的质量因素

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

正确性与精确性

易用性

可理解性与简洁性

性能与效率

可扩展性与

可复用性

3.3.1 正确性与精确性

正确性与精确性之所以排在质量因素的第一位，是因为如果软件运行不正确或者不精确，就会给用户造成不便甚至造成损失。机器不会主动欺骗人，软件运行不正确或者不精确一般都是人造成的。即使

一个软件能100% 地按需求规格执行，但是如果需求分析错了，那么对客户而言这个软件也存在错误。即使需求分析完全符合客户的要求，但是如果软件没有100% 地按需求规格执行，那么这个软件也存

在错误。开发一个大的软件项目，程序员要为“正确”、“精确”四个字竭尽精力。

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

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

设计非常重要。

可靠性是指在一定的环境下，在给定的时间内，系统不发生故障的概率。可靠性本来是硬件领域的术语。比如某个电子设备，一开始工作很正常，但由于工作中器件的物理性质会发生变化（如发热），

慢慢地系统就会失常。所以一个设计完全正确的硬件系统，在工作中未必就是可靠的。软件在运行时不会发生物理性质的变化，人们常以为如果软件的某个功能是正确的，那么它一辈子都是正确的。可

是我们无法对软件进行彻底地测试，无法根除软件中潜在的错误。平时软件运行得好好的，说不准哪一天就不正常了，如“2000年”问题。因此把可靠性引入软件领域是有意义的。我曾买了一本关于软

件可靠性的著作，此书充满了数学公式。我发现以我目前的学历实在难以看懂书上讲了些什么。请宽恕我的愚昧，我把此书给“供”起来，没敢用笔画一处记号。

3.3.2 性能与效率

用户都希望软件的运行速度高些（高性能），并且占用资源少些（高效率）。旧社会地主就是这么对待长工的：干活要快点，吃得要少点。程序员可以通过优化算法、数据结构和代码组织来提高软件系

统的性能与效率。优化的关键工作是找出限制性能与效率的“瓶颈”，不要在无关痛痒的地方瞎忙乎。如果你想职称升得快，光靠增加课时能顶屁用；你就该一年写它几十篇文章，争取破格升教授。

3.3.3 易用性

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

非议。

导致软件易用性差的根本原因是开发人员犯了“错位”的毛病：他以为只要自己用起来方便，用户也一定会满意。俗话说“王婆卖瓜，自卖自夸”。当程序员向用户展示软件时，常会得意地讲：“这个

软件非常好用，我操作给你看，……是很好用吧！”软件的易用性要让用户来评价。当用户真的感到软件很好用时，一股温暖的感觉油然而生，于是就用“友好”来评价易用性。

3.3.4 可理解性与简洁性

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

可理解性也是对用户而言的。开发人员只有在自己思路清晰时才可能写出让别人能理解的程序。编程时还要注意不可滥用技巧，应该用自然的方式编程。我们的确不知道自己的得意之举究竟是锦上添花

，还是画蛇添足。就象蒸出一笼馒头，在上面插一朵鲜花，本想弄点诗情画意，却让人误以为那是一堆热气腾腾的牛粪。

简洁是一种美，不管是自己还是用户都会有同感。在生活中，与简洁对立的是“罗里罗嗦”。中国小说中最“婆婆妈妈”的男人是唐僧。有一项民意调查：如果世上只有唐僧、孙悟空、猪八戒和沙僧这

四类男人，你要嫁给哪一类？请列出优先级。调查结果表明，现代女性毫不例外地把唐僧摆在老末。

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

3.3.5可扩展性与可复用性

可扩展性反映软件适应“变化”的能力。在软件开发过程中，“变化”是司空见惯的事情，如需求的变化、对需求理解的变化、算法的改进、数据及其描述的变化、程序实现技术的变化等等。

复用的一种方式是原封不动地使用现成的软构件，另一种方式是对现成的软构件进行必要的扩展后再使用。可复用性好的程序一般也具有良好的可扩展性。

3.4 质 量 检 查

检查是人们不信任自己和别人的一种行为。当某些事情涉及到利益分配时，更需要有检查活动来保证公平。

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

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

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

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

（4）不要化太多的时间争论和辩驳。

（5）说清楚问题所在，但不要企图当场解决所有问题。

（6）对检查人员进行适当的培训。

-----------------------------------------
作一个真正合格的程序员，或者说就是可以真正合格完成一些代码工作的程序员，应该具有的素质。

1：团队精神和协作能力

2：文档习惯
缺乏文档，一个软件系统就缺乏生命力，在未来的查错，升级以及模块的复用时就都会遇到极大的麻烦。

3：规范化，标准化的代码编写习惯

4：需求理解能力

5：复用性，模块化思维能力

6：测试习惯

7：学习和总结的能力

那么作为高级程序员，以至于系统分析员，也就是对于一个程序项目的设计者而言，除了应该具备上述全部素质之外，还需要具备以下素质：

第一，需求分析能力

第二，项目设计方法和流程处理能力

第三，复用设计和模块化分解能力

第四，整体项目评估能力

综上可以看到，作为一个主管研发的负责人，一个项目设计者，所需要具备的素质和能力并不是程序代码编写的能力，当然一般情况下，一个程序员通过不断的总结提高达到了这种素质的时候，他

所具有的代码编写能力也已经相当不简单了，但是请注意这里面的因果关系，一个高水平的项目设计者通常已经是代码编写相当优秀的人了，但是并不是一个代码相当优秀的程序员就可以胜任项目设计

的工作，这里面存在的也不是智商和课本的问题，还是在于一个程序员在积累经验，逐步提升的时候没有意识到应当思考哪方面的东西，没有有意识的就项目的组织和复用设计进行揣摩，没有经常性的

文档习惯和总结习惯，不改变这些，我们的合格的项目设计者还是非常欠缺。

最后补充一点东西，一个软件项目研发的设计流程是怎样的呢？以通常标准的设计方法为例，

第一个步骤是市场调研，技术和市场要结合才能体现最大价值。

第二个步骤是需求分析，这个阶段需要出三样东西，用户视图，数据词典和用户操作手册。用户视图是该软件用户（包括终端用户和管理用户）所能看到的页面样式，这里面包含了很多操作方面的流程

和条件。数据词典是指明数据逻辑关系并加以整理的东东，完成了数据词典，数据库的设计就完成了一半多。用户操作手册是指明了操作流程的说明书。请注意，用户操作流程和用户视图是由需求决定

的，因此应该在软件设计之前完成，完成这些，就为程序研发提供了约束和准绳，很遗憾太多公司都不是这样做的，因果颠倒，顺序不分，开发工作和实际需求往往因此产生隔阂脱节的现象。
需求分析，除了以上工作，笔者以为作为项目设计者应当完整的做出项目的性能需求说明书，因为往往性能需求只有懂技术的人才可能理解，这就需要技术专家和需求方（客户或公司市场部门）能够有

真正的沟通和了解。

第三个步骤是概要设计，将系统功能模块初步划分，并给出合理的研发流程和资源要求。作为快速原型设计方法，完成概要设计就可以进入编码阶段了，通常采用这种方法是因为涉及的研发任务属于新

领域，技术主管人员一上来无法给出明确的详细设计说明书，但是并不是说详细设计说明书不重要，事实上快速原型法在完成原型代码后，根据评测结果和经验教训的总结，还要重新进行详细设计的步

骤。
第四个步骤是详细设计，这是考验技术专家设计思维的重要关卡，详细设计说明书应当把具体的模块以最‘干净’的方式(黑箱结构）提供给编码者，使得系统整体模块化达到最大；一份好的详细设计说

明书，可以使编码的复杂性减低到最低，实际上，严格的讲详细设计说明书应当把每个函数的每个参数的定义都精精细细的提供出来，从需求分析到概要设计到完成详细设计说明书，一个软件项目就应

当说完成了一半了。换言之，一个大型软件系统在完成了一半的时候，其实还没有开始一行代码工作。那些把作软件的程序员简单理解为写代码的，就从根子上犯了错误了。

第五个步骤是编码，在规范化的研发流程中，编码工作在整个项目流程里最多不会超过1/2，通常在1/3的时间，所谓磨刀不误砍柴功，设计过程完成的好，编码效率就会极大提高，编码时不同模块之间

的进度协调和协作是最需要小心的，也许一个小模块的问题就可能影响了整体进度，让很多程序员因此被迫停下工作等待，这种问题在很多研发过程中都出现过。编码时的相互沟通和应急的解决手段都

是相当重要的，对于程序员而言，bug永远存在，你必须永远面对这个问题，大名鼎鼎的微软，可曾有连续三个月不发补丁的时候吗？从来没有！

第六个步骤是测试
测试有很多种：按照测试执行方，可以分为内部测试和外部测试；按照测试范围，可以分为模块测试和整体联调；按照测试条件，可以分为正常操作情况测试和异常情况测试；按照测试的输入范围，可

以分为全覆盖测试和抽样测试。以上都很好理解，不再解释。
总之，测试同样是项目研发中一个相当重要的步骤，对于一个大型软件，3个月到1年的外部测试都是正常的，因为永远都会又不可预料的问题存在。
完成测试后，完成验收并完成最后的一些帮助文档，整体项目才算告一段落，当然日后少不了升级，修补等等工作，只要不是想通过一锤子买卖骗钱，就要不停的跟踪软件的运营状况并持续修补升级，

知道这个软件被彻底淘汰为止。

------------------------------