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

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

提高质量是软件工程的主要目标。但由于软件开发是一种智力创作活动，很难象传统工业那样通过执行严格的操作规范来保证软件产品的质量。世上小心翼翼、老实巴脚的程序员未必能开发出高质量的软件来。程序员必须了解软件质量的方方面面(称为质量因素)，如正确性、性能、易用性、灵活性、可复用性、可理解性等等，才能在进行系统设计、程序设计时将高质量内建其中。软件的高质量并不是“管理”出来的，实质上是设计出来的，质量的管理只是一种预防和认证的手段而已。

1、项目计划

做项目计划，如同给一个待出生的婴儿写传记那样困难。如果允许项目结束后再写计划，那轻松多了，并且可以 地准确。

历史教训让我们明白一个道理：如果一万年以后才会有一条阳光大道通向共产主义，那么现在不要忙着砸锅炼钢赶英超美，免得在跑步奔向共产主义时把自己累死饿死。在做软件的项目计划时，应屏弃一切浮夸作风。只有“知已知彼”才能做出合理的项目计划。这里“知彼”是指要了解项目的规模、难度与时间限制。“知已”是指要了解有多少可用资源，如可调用的程序员有几个?他们的水平如何?软硬件设施如何?

1.1 知己知彼

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

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

项目的资源分为三类：“人”、“可复用的软构件”和“软硬件环境”

(1)人是有价值的资源。项目计划的制定者要确定开发人员的名单，要根据他们的专长进行分工。

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

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

1.2 进度安排

有一位程序员忙着编写程序，经理问他还需要多久才能完成。

“明天可以完成。”程序员立即回答。

“我想这是不切实际的，实话实说，到底还要多少时间?”经理说。

“我还想加进一些新的功能，这需要花两个星期。”程序员想了一会儿说。

“即使这样也期望过高了，只要你编完程序时告诉我一声，我也满足了。”经理说。

几年以后，经理要退休了。在他去退休午餐会时，发现那位程序员正趴在机器旁睡觉：可怜的家伙整个晚上都在忙于编写那个程序。

程序员也期望每天早晨能在7:00准时起床，可老是一觉醒来到中午了。项目落后于进度表乃是家常便饭，不必大惊小怪。以下一些事件经常会导致项目被延误：

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

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

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

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

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

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

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

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

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