软件项目估算与计划不是一般的难！
摘要：
估算、计划、计划跟踪是项目管理的主要工作，难度之高超乎你想象！光靠学习项目管理理论难以管好项目，而往往真能管好项目的都是那些在具体项目中滚打出来的实干人士。本文将会让你全面学习项目估算、计划、计划跟踪的知识，体验实际项目管理的难度，学到提高项目管理水平的一些方法。
大纲：
1.从建筑工程说起
2.估算要估啥？
3.估算如何做出来？
4.计划有什么内容？
5.计划是如何做出来的？
6.如何跟踪计划？
7.优秀项目经理是怎样炼成的？
特别声明：
如需转载此文，请给出指向本网站的连接，如下：
作者：张传波
摘自：http://www.umlonline.cn
如不能按此要求，请不要转载此文。
正文：
从建筑工程说起
大家都喜欢用建筑工程与软件工程做比较，但我们常常所说的建筑工程只是指建筑施工部分，而不是一个完整的建设项目。我们常常将施工项目管理与软件项目管理进行比较，这是不合适的。
一个完整的建设项目，由甲方提出需求，设计院根据需求设计出图纸，再由造价公司进行估价，然后公开招标，最后由建筑公司承担建设。相对于软件项目，建筑工程有以下特点：
1.从需求到竣工，经历需求、设计、估价、建设等环节，每个环节由不同专业的公司或人员完成。
2.每个环节签署不同的合同，每个环节对应不同的乙方。而软件项目从需求到开发完成，基本上是签署一个合同，只有一个乙方。
3.整个过程可以认为是瀑布型的，需求和设计会在前期确定，后期基本上不会变动。而软件项目就没有这么理想了，需求和设计不断在变。
4.建筑工程只会采用最成熟的技术，可行性和设计方案要经过反复论证，你看看港珠澳大桥就论证了好多年了。而软件项目往往要采用不成熟的技术，边设计边尝试。
5.建筑工程的估算是在需求与设计都确定的基础上估算的。而软件项目不确定的东西太多，估算无法一次成型。
软件项目管理可能是最复杂的一种项目管理，因为软件项目具备这样的特点：
1.需求、设计不明确。
2.项目组需要在需求设计不明确的基础上，承担需求、设计、编码、实施等全部工作。
如果你是这样项目的项目经理，对你来说是多么大的挑战啊！
建筑行业发展了这么多年，整个建设工程的各个环节已经有很多专业的公司，有很多设计院、造价公司、建筑公司等。而软件行业，几乎很少见到专业的需求分析公司、软件设计公司。这既是软件行业的特点决定的，也是甲方习惯决定的。我们公司在一些项目尝试和客户签署两份合同，第一份合同只做需求的工作，而第二份合同则完成实现与编码，但客户往往不会接受。
软件项目管理难归难，但我们还是要去面对的，我们应该如何应对软件项目的估算与计划呢？
估算要估啥？
很多人问如何才能做好估算？这个问题是问如何正确做事情的问题，而实际上要回答好这个问题，先要回答估算要估算什么内容的问题，也就是什么是正确的事情问题。
对于估算要区分以下几种情况：
1.甲方对项目的估算
甲方想做某个系统，会根据自己对系统的估计以及自己的预算估计出一个价钱。甲方往往不能准确对项目进行估算，项目的价钱往往是来自预算，而所有甲方都是想在有限的预算内办更多的事情。很多项目需要招标，其实重要目的就是希望找出性价比最高的软件公司。
2.乙方在投标阶段对项目的估算
作为软件公司，要判断该项目需要多少的成本，然后稍微“放大”成本作为投标价，这样公司才能有利可图。
然则现实情况很残酷：
1）需求大多数是不明确的，甚至甲方对项目的期望都没有想清楚，这样软件公司无从估算。
2）很多招标其实甲方都“隐含”一个预算价，如果软件公司的报价超出这个价钱，你就别想中标了。而这个预算价往往会小于软件公司对项目的估算，让你难以决定这项目做还是不做好！
这个阶段的估算是最难做的，除了考虑项目实际工作量，还要考虑项目是否要赚钱、客户关系等因素。
在我们公司，对于已经产品化的项目，估价比较容易，这其实是一个积累的过程。而对于全新的以前没有多少经验的项目，估价其实也是很难做得很好的，我们往往是由项目经验与技术经验都实力雄厚的总经理来“拍脑袋”拍出来的。所谓“拍脑袋”，其实不代表乱猜，是以雄厚的经验和强大的知识为前提的。
3.项目组开展项目时对项目的估算
当我们要真刀真枪开干时，项目组需要对项目的实际工作量有充分的认识，并以此为基础来做好项目工作。
我们常常所说的项目估算问题，就是指这第三种情况，后文我们将重点讲述这种情况。
项目估算到底要估什么呢？
项目的成本包括：人工费、差旅费、业务费用、招待费用、采购费用。
人工费：
包括项目组各人的薪金，以及公司运作分摊到项目组各人头上的运作成本。公司运作成本包括非项目组人员的人工、场地设备费用、水电通讯费用、人员培训招聘费用、人员闲适成本、研究失败时的成本、商务活动的成本等。
一般来说，项目组只需要估算出实际的项目工时就可以了，工时再乘以一个折合的人工成本单价就是项目的人工成本了。
差旅费：项目组成员因项目出差的交通费、住宿费、通讯费、差旅补贴等。
业务费用：公司领导、销售人员与客户进行商务谈判、联络所花费的费用，例如送礼、回扣等的费用。这笔费用往往还很大呢，不过项目组一般不需要估算这部分费用。
招待费用：项目组成员因工作需要，和客户相关人员吃饭、娱乐的相关费用。例如：需求调研期间和客户吃饭；项目实施阶段因推动验收和客户一起加班，加班后请客户吃饭。这笔费用一般不会很大，一顿饭一般就是几十到一百多元，一个项目也不会请很多次吃饭。
采购费用：采购项目所需的软硬费用，如数据库平台、服务器等，如果项目部分内容要外包出去，那还要包括外包的费用。有时候这笔费用会比较巨大，但这些费用都很容易估计。
以上费用最难估计的就是人工费，人工费我们以工作量来考虑，下文开始我们重点讲解项目工作量的估算。
如何估计项目的工作量呢？
简单地说，我们需要将项目的所有工作进行分解，直到每个分解后的工作都能估计出具体的所需时间来。
那项目的“所有工作”包含什么呢？回答这个问题其实就是回答“估算要估啥？”这个问题了。
一般情况下，项目工作包括以下内容：
1.项目前期工作。
包括商务谈判、技术方案准备、投标准备、前期需求调研、前期技术研究等工作。当你接手项目的时候，这些工作往往已经做了，你估算项目工作量时，不要忘记这些已经花费的工作量。
2.商务方面的工作。
从客户开始有意向做这个项目，一直到项目验收、维护，整个过程中都会贯穿商务活动。前期的商务活动有商务谈判、投标准备、合同签署等，而签订合同后的商务活动有项目请款和催款、促进验收等。某些商务活动属于灰色地带，如请客、送礼等，这些往往是花费巨大的。一般来说我们不需要估算灰色地带的商务活动，灰色地带的商务活动公司的高层会考虑的了，但我们需要对正常的商务活动进行估算。
3.需求调研方面的工作。
需求调研是一个“反复”的过程，一般来说能在前期确定80%已经是很了不起的成绩。
需求调研的工作量一般由三部分组成：前期调研的工作量，后期需求细化的工作量，后期需求变更的工作量。
前期调研的工作包括：项目组内部讨论、确认，与客户讨论、确认需求，编写需求规格说明书及组织评审等工作。
需求细化是指对之前已确定需求的进一步具体化、优化或轻微调整，如：界面细节的确认、各业务概念的具体化等。需求细化一般是可预见可估计的。
需求变更是指对之前已确认需求的“否定”，变更的原因主要有两种情况：一是之前需求调研工作没有能做好，理解错客户的真正意图或者是遗漏重要的需求；二是客户业务情况发生变化，与之前情况已经不同。第一种情况应该尽量避免，而第二种情况一般是难以估计的。需求变更时需重新估算，和客户签订需求变更协议。
我们一般会充分估计前期需求调研工作量以及需求细化工作量，对于需求变更则暂不考虑，因为一旦变更我们会和客户确认需求变更的费用。但有些项目有很特殊，项目报价中预留了少量的需求变更费用，这时估算中就需要适当考虑需求变更了。
4.软件设计方面的工作。
不少项目为了“赶”进度，设计文档很少，然则项目真的很简单、不需要仔细考虑设计的情况是非常少的！
软件设计工作包括：
1）系统架构设计。
2）技术方案选择。
3）关键模块设计。
4）数据库设计。
5）用户体验设计。
以上内容具体项目可以有所取舍，但不可能全部都不用考虑。
另外不要忘记了以下两方面的工作：
1）各类设计工作产品的讨论、确认、评审工作。
2）设计细化与优化工作。设计是需要持续改进的，不要忘记这些工作。
5.编码方面的工作。
要注意不要遗漏代码返工、代码评审、代码调试、修复缺陷的工作量。
需求、设计没有做好，编码质量不过关，这些会严重增加代码返工、代码调试、修复缺陷的工作量。代码首次完成的时间如果是100小时，那么后面代码调试、修复缺陷等所需要的时间可能是200小时以上，往往我们估算时只考虑了前面的100小时。
6.测试方面的工作。
测试工作包括测试计划、测试用例、测试文档评审、测试环境准备、测试数据准备、执行测试、回归测试等内容。
软件测试一般要经历多轮，我们估算往往只考虑了第一轮，就好象软件只需要测试一回就不用再测试了。而测试环境准备、测试数据准备这些工作也很容易在估算时“忘记”了。
7.实施方面的工作。
实施工作包括实施计划、实施方案的准备，编写管理员手册、用户手册，熟悉系统，搭建实施环境并进行演练，在客户现场安装、部署、调试系统，培训客户，协助系统上线，推动验收等工作。
我们公司通常的做法是：
1）系统在客户处部署后，会推动客户进行初步验收，初验标准是系统的所有功能跑就可以了。初验成功，客户需要支付相应的项目款项。
2）初验后要协助客户让系统正式上线，让客户真正用上这套系统，推动最终验收。
影响终验主要有两个因素，一个是客户在使用系统过程中会提出各式各样的问题，如果在需求范围内应该都予以满足；而另外一个影响因素是客户会因为各种各样的原因推迟使用系统，或者是使用不充分，让项目终验遥遥无期。估算时需要充分考虑这两个影响因素。
8.维护方面的工作。
项目终验后，一般都要提供半年到一年的维护服务，维护器后项目还会有最后一笔款项。
维护期比较长，事情繁杂，一个不小心就很容易估算不足。
维护的工作一般有：
1）用户培训；
2）协助客户录入资料；
3）修复被破坏的数据以及数据库；
4）修改客户或内部发现的软件缺陷；
5）代码重构，提高部分程序的性能与可靠性；
6）修改一些界面文字或显示风格；
7）回答客户反馈的一些安装与操作疑难问题；
8）提供合同中所要求的其它特殊软件维护服务。
在维护期，往往还需要发布数个小版本来解决客户的问题。
9.项目管理方面的工作。
项目管理工作主要有编制项目计划、持续更新项目计划、跟踪计划执行、各种工作协调、指导项目组成员完成工作等等。
项目管理工作量一般占整个项目工作量的10-20%，项目不明确的东西越多、项目组成员水平越不足、项目组成员之间工作磨合度越不好，管理工作量就越大。
项目管理在项目进行整个过程都需要持续进行，一般来说前期工作量会比较大，版本发布前后阶段工作量也会比较大。项目管理前期工作抓得紧抓得好，会大大减轻后期的工作量。
10.配置管理方面的工作。
什么叫配置管理？简单说就是对工作产品的管理，包括对各类文档、各种记录、代码、数据库、脚本、安装程序、组件等等的管理。
软件生产过程的工作产品可分为两类：中间产物和最终产物。
中间产物有：
1）工程类：需求文档、设计文档、测试方案、代码、数据库脚本、数据库、测试脚本等。
2）管理类：开发计划、测试计划、培训计划、采购计划、实施计划等。
3）记录类：会议记录、邮件、缺陷等。
最终产物是指最终会交付给客户的东西，一般有：组件、安装程序、数据库、用户手册、管理员手册等。
针对不同的工作产品应采取不同的针对性管理办法，很多公司会制定单独的配置管理计划。
11.质量保证方面的工作。
严格来说，质量保证是靠项目组全体来保证的，这里所说的质量保证是“狭义”的质量保证，是指：要确保项目组按照既定的规定、过程、标准来工作，需按照既定的格式要求产出相应工作产品。
对于以上十一点，实际项目估算中往往出现这样的问题：
1.忘记包含项目前期工作的工作量。
2.没有考虑商务、维护、配置管理、质量保证方面的工作。
3.需求调研、软件设计、编码、测试、实施方面的工作估计过少。
4.项目管理方面的工作量估计不足。
估算如何做出来？
这里开始所说的估算，全部都是指项目组对项目的估算，这个估算的目的是用来指导项目的具体工作。
有很多种估算办法，大致可以分为两类：
1.先得到软件规模，然后根据公司实际的生产率由软件规模导出工作量。
2.直接得到工作量。
第一类的常见方法有：功能点法、代码行法，第二类的常见方法有Delphi估算法、微软的由底而上估算法。
什么是软件规模？我们先看看一个搬砖头的估算。
假设有1000块砖头，它们的大小和重量一样，每名工人每天能搬100块砖头，于是我们可以估算到需要10人日来搬完。10人日的意思是1名工人需要10天完成，而10名工人只需要1天就搞定了。
这个1000块代表了工作的规模，而生产率就是100块/日，这样就可以推算出工作量为10人日。建筑工程可以得到土石方量、混凝土量、钢筋量等代表工作规模的数据，这样就比较容易推算出完成这些工作需要的工作量。
而软件工程估算也希望能做到类似的效果，但用什么来代表软件项目的工作规模呢？功能点和代码行是常见的两种软件规模表示方式。
软件规模是与软件具体生产技术、项目管理办法、项目组人员水平等无关的东西，软件规模只和软件项目本身的性质相关，如果我们能找到合适的统一的标准来度量每个项目的规模，这样每个软件项目之间就可以进行横向比较了。功能点法和代码行法都希望能达致这样的效果。
功能点法的基本思路是将复杂的软件分解为一个一个独立的粒度一致的功能点，附加一些调整系数，得到软件规模。
我们的项目大部分是数据库四轮马车的操作（查询、增加、修改、删除），功能点法从比较高的层次对这些工作进行抽象，有一套严密的规则可以让你将需求分解成一个一个的功能点。代码行法思路也类似，不过分解的结果是代码行而已。但一般来说代码行与软件的实现技术相关度太大，大家会更加偏爱功能点法。
功能点法和代码行法有比较长的历史，也有很多详细资料，大家可以去查阅一下。这方法理论上很理想，但实践效果很差，我还没有见到一家能成熟应用并且取得比较好效果的公司。功能点法和代码行法有这样的一些难以解决的问题：
1.只适用于数据库四轮马车的操作的项目，高技术含量、创造性高的软件不适用，如游戏软件、计算机负责计算与决策软件等。
2.我们绝大部分项目是需求不明确、设计不明确，并且工期很赶的，这两个方法都无法适应这样的现实条件。需求不明确基本上无法得到软件规模，建筑工程为什么能做到，是因为需求和设计都十分明确了。
3.两个方法的规则都很详细，要花大量时间学习和实战才能掌握。
4.由工作规模导出工作量这样的思考方式，难以适用于软件项目。项目组还是习惯列出具体的任务，逐条任务估计时间，而且只有这样的工作方式才能让项目组感觉更加踏实。
Dephi估算法是比较符合大家实际工作习惯，也是比较容易掌握的估算办法。
Delphi法的大致方法如下：
1.找几名资深专家，一起对项目进行WBS，把项目的工作分解为十几条最多二三十条的工作项。
2.全部专家各自估计每条工作项的工作量，并向其他专家阐述自己的理由。
3.第一次各专家估出来的结果可能差异比较大，每位专家听取别人的意见后，重新估算。
4.按照上述办法，各专家反复估算几次，一般次数就是2-4次，各专家估计的工作量会越来越趋近，这个时候取全部专家的平均值。
普遍认为各专家的经验与知识水平会严重影响结果的准确性，而我的实践经验是：应该让项目组每个人自己来估算，也就是让大家来当专家，在这个基础上可以再增加一两名来自项目组外部的专家。
有时候觉得估算这个问题搞得太复杂了，各式各样的方法是不是太夸张了？其实最简单的方法就是让负责该项工作的人自己来估计工作量，微软的由底而上的估算方法就是这样做的，可谓返璞归真啊！
微软由底而上的估算方法大致是这样的：对项目各项工作进行分解后（即俗称的wbs：work breakdown structure，工作分解结构），每个任务落实负责人，由负责人对自己的任务进行估计。这个办法有以下好处：
1. 最终该任务是由这个人来完成的，他估计多少时间才能做完，这个时间才是最接近实际的。
2. 负责该任务的人进行估算的时候，肯定需要认真思考这个任务的风险，需要做哪些具体的工作，这样更容易在未开始工作之前就发现更多的潜在问题。相反如果由项目经理来分配时间，这个人就可能不会去思考这个任务了。
3. 做这个任务的人会有被重视和尊重的感觉，他会很重视自己承诺的完成时间，并且想法设法按时间完成。这样会减少很多项目管理时间，因为每个任务负责人都会主动地跟踪好自己的工作。
其实微软这个方法根本就没有什么特别，所有正常人都可以想到这个方法，但仍然有很多人去追求那些不太靠谱的估算方法。
这个方法还是有这样的一些问题的：
1.有人会估算偏小，比方他说需要5天，但往往10天还完不成。
2.有人估算过于保守。
3.项目的进度要求就是很紧，基本上你必须在指定时间内完成，估算显得毫无价值。
第一个问题是比较常见的，但我们要这样想：估不准也比不估算好，估算偏差哪怕超过100%，也比不估算好，至少有个谱。
大家是会进步的，估不准往往是对任务和自己能力认识不到位，要让大家不害怕估算，只要敢于估算，问题才会暴露出来，才能持续进步。
第二个问题分两种情况，有些人是确实是过分保守的对自己信心不太足，项目经理可以多多来指导他的工作，看看他具体的进展，让他更加充分地了解任务，更加充分了解自己的能力，增强他的信心，这样他就能持续进步了。而另外一种情况就比较恶劣，少数人会故意增大时间，这样他平时工作不必全力以赴，可以比较悠闲，甚至可以利用工作时间干私事。如果发现这样的情况，就应该严肃处理了，不要做烂好人，这样的人在团队中存在是对团队的极大伤害。
第三个问题往往是各项目经理心中的痛楚，他们会觉得：实在无奈啊！做项目就是在有限时间有限资源内做不可能完成的任务，在这样的情况下，你就不要跟我扯估算了！
我们的项目大部分情况都是非常大压力的，应对这样大的压力越需要冷静。实际上大部分项目尽管是有压力，但只要发挥团队的聪明才智，还是可以高效地做好工作的，不需要加班或者少加班。本文稍后会介绍这个问题的应对办法。
介绍了这么多种估算方法，每种都有很多问题，那到底怎样才能做好项目估算呢？
软件项目的特点就是项目签订时，价钱是死的，工期是死的，而需求和设计是不明确的。
我的经验告诉我，功能点法、代码行法这些方法基本上是不靠谱的，我在实际项目中会综合使用Dephi法和由底而上的估算方法，并予以改良，下面介绍一下我的一些心得体会。
1.项目估算与其说是估出来，还不如说是做出来的。
假设某项目是这样的情况：
1）合同签署的金额是100万，工期是3个月。
2）需求只是大致写了，并不明确。
3）老板要赚50万，给你的预算只有50万。
我们很多项目都是这样的情况，不是等你估算出比较靠谱的数字，然后才去报价签合同的，我们经常要在老板指定的预算下完成项目。
你现在要负责这个项目，你会如何做估算呢？
你需要做好两个事情，才能保证项目实际成本控制在预算内。
第一个事情，控制好需求。需求不明确，这既是不利因素也是有利因素，应尽量往有利的方向控制。不明确的好处就是你有控制需求的空间，抓住客户的关键需求，简化不必要的花销的需求，能极大地降低项目工作量。
第二个事情：想尽办法降低开发工作量。不要因为进度紧就不认真思考软件的设计，应尽量采用简单的成熟的设计方案，简化工作。
2.估算应该持续进行，持续细化。
项目初期很难对项目做完整估算，但能估计的部分应先估计出来，并且针对不明确的部分安排计划去搞清楚。
3.估算是项目各种工作估算的总和。
估算并不是只是得到一个项目估算的总体数字，项目的估算总数其实是由项目各种工作的估算组成的。
前文介绍了项目的各种工作，每一种工作都需要认真估算。如果估算发生偏差，要能定位到具体是哪部分的估算出问题了，否则估算没有指导项目工作的价值。功能点法、代码行法的估算办法，只能得到一个项目估算的总数，而不能定位到具体的哪一部分工作，这样得到的估算结果难以用来指导项目工作。
4.估算依赖项目组的整体实力。
如果你没有软件开发相关经验，只懂理论上的估算，你是不可能做好估算工作的。
项目组由项目管理、软件设计、编码、测试、实施等各类专业人才组成，每个人在自己方面都是专家，每个人都是整个项目组中最有资格对自己专业方面的工作进行估算。前文列出了的项目各方面的工作，应该由相应的项目成员为主进行估算。
5.项目组应该不断学习、总结、进步，提高整体水平。
需求不明确、设计不确定这是项目的特点，我们需要不断地学习来提高水平，将这些不明确的因素逐步明确。
没有什么妙方能解决这些不明确的因素，靠的还是我们的知识和能力。项目组每个人都应该通过持续估算来发现自己的不足并提高水平。
6.公司应该定期组织项目资深人士制定估算指南并持续更新。
我们公司有一份估算模板，里面汇集了以前的估算经验，列出了所有需要考虑的估算内容以及详细的说明。
我们以前没有估算模板时，估算偏差会达到50%以上，总结经验发现偏差的主要原因是估漏！使用估算模板会帮助我们发现遗漏，后来我们的估算偏差基本可以控制在20%以内。
前文的“估算要估啥”小节，我列出了项目通常要考虑的各种工作，也列出了容易估漏和估计不足的地方，大家可在此基础上根据自己公司实际情况，修改和扩充这些内容，写出自己公司的估算模板或估算指南。
先得到项目规模，再由规模导出工作量，这是一个很美好的想法，问题就是和我们的实际情况相去甚远了。
将工作分解，直到分解到可以估计工作量的程度，这个可能是最土最有效的方法了。但你可能会问，这样的估算方法，项目之间就无法横向比较了？
项目估算第一目标是用来指导项目工作，如果这个目标都达不到，那么就不需要考虑项目之间的横向比较了。
另外我要反问：为什么非要用这样的方式来作项目之间的横向比较？有什么好处？国外优秀的软件开发工作室就不会做这样无聊的事情，软件开发可能是人类最厉害的智力活动，你觉得一定能量化度量吗？
要从本质上提升估算水平，你不太可能用几天时间去突击学习某种估算办法就能胜任项目实际的估算工作。
提高估算能力靠你长期的积累，你的实力、你的项目团队的综合实力，还有你们公司的综合实力，决定了估算的水平！
估算是为项目服务的，后文你会看到如何利用估算来管理项目，又如何因应项目实际情况来更新估算。
下面开始，我们将讲述估算与计划的关系、计划及计划跟踪。
计划有什么内容？
关于项目计划，我们要先讨论什么是正确的事情，然后再讨论如何做正确的事情，我们先来看看项目计划应该有什么内容？
让大家做项目计划，很多人以为用Project做一份开发进度计划就完事了。而项目的开发工作只是占了项目工作的其中一部分而已，跟项目所有相关的工作，我们都需要计划。诸如开发计划、测试计划、培训计划、沟通计划、采购计划等等，这些计划的集合，我们称之为项目计划。
项目计划应该包含以下内容：
1.项目背景、目标、概述等。
2.项目需要提交的工作产品，包括内部工作产品和最终工作产品。
3.风险分析及应对措施。
4.项目估算。
5.项目在成本、进度、质量方面的管理目标。
6.项目人员职责。
7.对项目各项工作的安排，包括但不限于前文介绍的11种工作，如下：
1）项目前期工作
2）商务方面的工作
3）需求调研方面的工作
4）软件设计方面的工作
5）编码方面的工作
6）测试方面的工作
7）实施方面的工作
8）维护方面的工作
9）项目管理方面的工作
10）配置管理方面的工作
11）质量保证方面的工作
8.需客户或第三方协调的工作计划。
9.采购计划。
10.项目所需的各种硬件资源，包括开发环境、运行环境、测试环境等。
一般来说项目计划有一个主计划，多个子计划。主计划总体描述项目的背景、管理目标、任务概述等总体信息，而子计划则有测试计划、实施计划、培训计划、配置管理计划等。
下图是主计划目录示例：
