在可行性分析之后，项目计划与质量管理将贯穿需求分析、系统设计、程序设计、测试、维护等软件工程环节。
项目计划是要提供一份合理的进程表，让所有开发人员任务明确、步调一致，终共同准时地完成项目。项目计划是要付诸实施的，不象用嘴巴喊政治口号，可以很夸张。软件的项目计划重在“准确”而非“快速”。
提高质量是软件工程的主要目标。但由于软件开发是一种智力创作活动，很难象传统工业那样通过执行严格的操作规范来保证软件产品的质量。世上小心翼翼、老实巴脚的程序员未必能开发出高质量的软件来。程序员必须了解软件质量的方方面面（称为质量因素），如正确性、性能、易用性、灵活性、可复用性、可理解性等等，才能在进行系统设计、程序设计时将高质量内建其中。软件的高质量并不是“管理”出来的，实质上是设计出来的，质量的管理只是一种预防和认证的手段而已。
项 目 计 划
做项目计划，如同给一个待出生的婴儿写传记那样困难。如果允许项目结束后再写计划，那轻松多了，并且可以 地准确。
历史教训让我们明白一个道理：如果一万年以后才会有一条阳光大道通向共产主义，那么现在不要忙着砸锅炼钢赶英超美，免得在跑步奔向共产主义时把自己累死饿死。在做软件的项目计划时，应屏弃一切浮夸作风。只有“知已知彼”才能做出合理的项目计划。这里“知彼”是指要了解项目的规模、难度与时间限制。“知已”是指要了解有多少可用资源，如可调用的程序员有几个？他们的水平如何？软硬件设施如何？
知己知彼
首先要了解项目的规模、难度与时间限制，才可以确定应该投入多少人力、物力去做这个项目。在可行性分析阶段要考虑这个问题。但不幸的是，人们在陷入项目不能自拨之前总难以准确地估计项目的规模与难度。这里经验起到了重要的作用。
项目的时间限制有两类。第一类，项目应该完成的日期写在合同中，如果延期了，则开发方要作出相应的赔偿。第二类是开发自己的软件产品，虽然只确定了该产品大致的发行日期并允许有延误，但如果拖延太久则会失去商机造成损失。
项目的资源分为三类：“人”、“可复用的软构件”和“软硬件环境”。
（１）人是有价值的资源。项目计划的制定者要确定开发人员的名单，要根据他们的专长进行分工。
（２）可复用的软构件是次有价值的资源。软构件并非一定要用自己的，可以向专业的软件供应商购买。
（３）软硬件环境虽然不是重要的资源，却是必需的资源。原则上软硬件环境只要符合项目的开发要求即可。有些项目可能要用到特殊的设备，则要事先作好准备，以免用时找不到而担搁了进程。
进度安排
有一位程序员忙着编写程序，经理问他还需要多久才能完成。
“明天可以完成。”程序员立即回答。
“我想这是不切实际的，实话实说，到底还要多少时间？”经理说。
“我还想加进一些新的功能，这需要花两个星期。”程序员想了一会儿说。
“即使这样也期望过高了，只要你编完程序时告诉我一声，我也满足了。”经理说。
几年以后，经理要退休了。在他去退休午餐会时，发现那位程序员正趴在机器旁睡觉：可怜的家伙整个晚上都在忙于编写那个程序。[James 1999]
程序员也期望每天早晨能在7:00准时起床，可老是一觉醒来到中午了。项目落后于进度表乃是家常便饭，不必大惊小怪。以下一些事件经常会导致项目被延误：
（1）上级领导主管臆断，制定了不现实的期限。项目经理与程序员们被迫按照不合理的进度表开展工作。
（2）客户的需求发生了变化，但没有对进度表作出相应的修改。
（3）低估了项目的规模与难度，导致投入的人力和物力不足。
（4）并未预见到存在难以克服的技术障碍。
（5）并未预见到开发人员会发生问题，如生病，辞职等等。
（6）开发人员之间不能很好的交流、协作，导致各阶段任务难以如期完成。
所以写进程表不能象小学生写决心书那样充满幻想。以下是一些有益的建议：
（1）制定进度表的人好是项目负责人，他了解项目和开发人员。进度表要经过开发小组的讨论，在得到大部数人的支持后才能实施。避免出现一厢情愿的局面。
（2）进度安排并不见得一定要符合逻辑顺序。应尽可能地先做技术难度高的事，后做难度低的事。也是辛苦在前，轻松在后。
小时候我对一位老先生吃饭很感兴趣：他总是先把一大盒的米饭吃光了，然后再幸福地品尝一小盒菜。父母告诉我这是中国的传统美德，叫“先苦后甜”。从此我铭记在心，按此道理去学习和工作。可如今在饭店里，人们总是先把菜吃完了，后才吃点米饭。天哪，生活真是太复杂了，我究竟该“先吃饭” 还是“先吃菜”？
（3）开发一个大的软件项目，应该将进度表分为若干个里程碑。一个里程碑之内的多个任务可以同步进行。程序员极容易沉迷于技术，要么乐不思蜀，要么焦头烂额。里程碑象心灵的灯塔，使忙碌的人群不混乱，不迷失方向。
（4）进度表中必须留有缓冲时间，并将缓冲时间用到不确定的事情上。因为人们对即将要做的事情知之甚少，所以要留一些时间以防不测。Microsoft公司的一些开发小组甚至制定了“50% 缓冲规则”[Cusumano 1996]。对许多项目经理而言，容忍进度表中存在缓冲时间，不啻为观念上的一个飞跃。
（5）如果发现项目应交付的期限非常不合理，要跟领导或跟客户据理力争，请求放宽期限、调整进度。当客户的需求发生变化时，要对进度表作出相应的修正。不要觉得修改进度表很困难很麻烦，不修改才会产生真真的麻烦。很多人认为戒烟很困难，但马克·吐温曾说：“戒烟很容易，我一年戒几十次。”
零缺陷质量管理的观念
“零缺陷”质量管理的观念来源于一些国际上的硬件生产厂商。尽管软件的开发与硬件生产有极大的差别，但我们仍可以从“零缺陷”质量管理中得到启迪。“零缺陷”质量管理至少有两个核心内容：一是高目标，二是可执行的规范。
高目标
人在做一件事情时，由于存在很多不确定的因素，一般不可能 地达到目标。假设平常人做事能完成目标的80%。如果某个人的目标是100分，那么他终成绩可达80分。如果某个人的目标只是60分，那么他终成绩只有48分。我们在考场上身经百战，很清楚那些只想混及格的学生通常都不会及格，那些想得高分的学生也常为自己的失误而捶胸顿足。
做一个项目通常需要多个人的协作。假设项目的总质量（高为1）是十个开发人员的工作质量之积。如果每个人的质量目标是0.95，那么十个人的累积质量不会超过0.19。如果每个人的质量目标是0.9分，那么十个人的累积质量不会超过0.03。只有每个人都做到1，项目总质量才会是1。
如果没有高目标，人的堕落很快。如果没有“零缺陷”的质量目标，也许缺陷会成堆。
可执行的规范
实现100分显然比实现80分要付出更多的努力。“零缺陷”质量目标不是随心所欲提出来的，做得到才有意义。实现高目标需要一套可执行的规范来保证。
50年代末，掀起了“浮夸风”。为了实现亩产数万斤推广各种方法，害得闹饥荒。想不到有数千年种粮经验的几亿中国农民这么整齐地栽倒了。
好规范必须是本企业有能力执行的。一个普通企业照搬企业的规范未必行得通。软件工程的规范很容易从书籍中找到，但有了这些规范并不表明能把软件做好。国内很多软件公司根本没有条件去执行业界推荐的软件工程规范。社会主义初级阶段的“草”与发达资本主义的“苗”的确有不同的培育方式。
软件是如此的灵活，如果没有规范来制约，容易因无序的喜好而导致混沌；但规范如果太严密了，会扼杀程序员生机勃勃的创造力。制定软件规范是进退两难的事。程序员必须深入了解软件多方面的质量因素，把那些能提高软件质量因素的各种规范植入脑中，才能在各个实践环节自然而然地把高质量设计到软件中。
软件的质量因素
“运行正确”的程序是高质量的程序吗？
不贪污的官是好官吗？
时下老百姓对一些腐败的地方政府深痛恶绝，对“官”不再有质量期望。只要当官的不贪污，哪怕毫无政绩，也算是“好官”。也有一些精明的老百姓打出旗号：宁要贪污犯，不要大笨蛋。相比之下，程序员是够幸福的了。因为我们能通过努力，由自己来把握软件的命运。那么不要轻易放弃提高软件质量的权利了。
“运行正确”的程序不见得是高质量的程序。这个程序也许运行速度很低并且浪费内存；也许代码写得一塌糊涂，除了开发者本人谁也看不懂也不会使用。正确性只是反映软件质量的一个因素而已。
软件的质量因素很多，如正确性、精确性、可靠性、容错性、性能、效率、易用性、可理解性、简洁性、可复用性、可扩充性、兼容性等等（还可以列出十几个）。这些质量因素之间“你中有我，我中有他”，非常缠绵。如果程序员每天要面对那么多质量因素咬文嚼字，不久会迂腐得象孔乙已，并且有找不到女朋友的危险。
正确性与精确性
正确性与精确性之所以排在质量因素的第一位，是因为如果软件运行不正确或者不精确，会给用户造成不便甚至造成损失。机器不会主动欺骗人，软件运行不正确或者不精确一般都是人造成的。即使一个软件能 地按需求规格执行，但是如果需求分析错了，那么对客户而言这个软件也存在错误。即使需求分析完全符合客户的要求，但是如果软件没有 地按需求规格执行，那么这个软件也存在错误。开发一个大的软件项目，程序员要为“正确”、“精确”四个字竭尽精力。