项目管理的内容不外乎计划和执行，如果每个人都对其验证项目进行了良好的计划，那么为什么还会存在质量问题和进度落后的情况？一份的计划中应包含用可度量指标描述的详细目标、的资源利用和现实的进度估计。

在管理者及其团队制定计划时，他们通常都没能触及那些导致进度滞后、资源生产率低和产品质量不佳的常见问题。大部分验证计划都只注重任务性能而不是怎样定义验证问题，这与解决方案无关。
这就几乎必然导致验证过程存在漏洞，使得设计缺陷(bug)被忽略，而要修复这些缺陷又会导致进度推迟，或者导致严重的资源紧张和效率低下。但我们只要对计划稍加改进，就能避免这些问题，收到事半功倍的效果。
为什么说验证计划并不完整
由于时间压力过大，大多数验证团队都没有进行全面的验证计划，而是跳过这一步，直接进入设计前的验证环境开发过程。这样使计划一成不变的，或者毫无灵活性可言，这样的计划几乎没有用处，因为它与实际项目之间的联系很难维持。换言之，这样的验证计划根本不成其为一个计划，充其量它只是一组不完整的讨论笔记。随着项目推进，团队开始工作并认识到他们应该实现怎样的目标，这样的计划终会一无是处。
上面的问题的解决办法是必须使验证计划成为验证过程本身的一个可以执行的部分。当验证过程自动化工具读取验证计划，验证计划变得可执行。这种方法可用来组织和生成项目状态，并成为分析数据以决定下一步行动的基础。
这样一来，计划的价值就得到了化，它在项目的整个周期过程中都将充当验证过程的开始和检验标准的角色。通过用验证计划来自动测试验证过程的完整性，能够直接增大开发和维护它的投资回报。这样，当项目中必须进行改动时，这些改动就会被更新了的可执行的验证计划记录、跟踪并测试，从而使验证计划从规范定义到结束，一直是验证项目的一个有价值的部分。
只要将计划做得更好，并使用可执行的计划来测试项目的完整性，就能提高项目质量，增加项目进度的可预见性，并改善资源生产效率。换言之，有了更好的计划，验证团队就更容易得到他们需要的结果。
在整个项目过程中使用计划能够帮助更早发现问题，而这正是保持项目进度的关键之一。同时，根据计划的标准来跟踪项目进展也能使团队中的所有成员更好地进行自我管理，从而提高生产效率。
怎样的计划才算一个好计划？
验证计划必须从注重“怎样验证”转向到“验证什么”。通过确定什么是需要验证的这个重要目标，验证团队就能保证计划的完整性和平衡性。这时，验证计划就不仅仅是怎样完成验证的工程规范了。
a. 验证计划的基础知识
从过程的来看，验证计划其实十分简单，其基本步骤包括：
1． 分析器件规范
2． 界定(scoping)验证目标
3． 确定设计的特征集
4． 设计详细的覆盖(coverage)模型
5． 选用集合的衡量标准(aggregate metrics)跟踪验证进展
6． 根据过去的度量标准估计工作和进度
通常，团队带头人倾向于按照这个程序来进行验证计划，但他们每一步都至少会遗漏一个关键方面，通过这种投机取巧的方式节省时间，将项目拿来作赌注 。结果，输的往往是他们。
b. 分析器件规范
所有的项目总是从几种规范开始。市场行销过程能够帮助了解用户需求，管理的过程定义资源和进度以及自己构建相对于购买的制约；再由系统工程师和软、硬件工程师以及验证团队分别制定验证实现规范，以该规范引导项目进行。
对一个项目而言，的风险是无法预见变动的目标。有些团队会试图在一开始就找出所有的需求，然后顺序地完成整个项目。这种方法有时也叫瀑布方法(waterfall method)。事实上这个过程中常常出现反覆，而项目的风险就在于无法充分预计反覆的影响以及控制反覆出现的频率及其给项目增加的负担。
c. 界定验证目标
在项目验证目标的界定阶段常见的问题就是没能与所有相关人员进行广泛的验证讨论。而验证目标的界定和建档是鉴定项目规范是否考虑周全以及是否能被充分理解的方法。
在项目开始之后再去计划一个验证项目的细节将十分低效并难以预计后果。管理层必须在前期就投入足够的时间去制定准确和完善的验证目标。需求的扩展变化是另一个问题，将在下节讨论。
所有可能涉及到的人员都必须参与制定验证目标，他们包括管理层、市场人员、系统设计师、硬件设计师、软件设计师和验证团队。因为只有整个团队都参与对话，才可能明确整个项目的需求。市场需求永远不可能完全，因为这些市场需求只解决市场关键因素。
从定义上讲，管理资源和项目进度约束往往具有一定冲突，随着项目目标的全面界定，必须缓和这二者之间的矛盾。系统工程师应该提出与市场需求贴近的技术观点，软、硬件工程师也应为项目实现的关联性提出有价值的见解。
验证团队是整个讨论小组的，正是他们不断地挑战项目组的其他成员，让他们看到并弥补项目的缺陷，同时还要让他们认清哪些特征是无法验证的，这正是面向验证的设计所需达到的关键目标。如果遗漏了其中任何一点，那么项目中就仍存在漏洞和风险，从而不可避免地导致产品质量问题、成本过高或者进度滞后。
d. 确定设计的特性集
高超的测试技术已经成为验证中难以掌握的一个部分，衡量标准则是度量验证过程的一种方式。一直以来，工程师都通过设计测试软件、实现检验器(checker)并利用代码覆盖检查工具来进行验证。测试列表作为一种度量标准已经废弃不用了，因为这种标准在规定和实现上太过繁复。
有些时候，定向测试软件比较容易设计，但它们无法满足现代系统级芯片这样规模的测试要求。检验器并不适合用做度量标准，因为它们只检查错误的系统行为而不记录已经观察到的好的行为。而且，代码覆盖与行为的关系也很松散，因为每一行代码的器件的前后环境条件(context)都没有记录。
业界的电子开发团队都认为功能覆盖是验证的准确的度量标准。功能覆盖是覆盖驱动验证法(CDV)的一部分，采用这种方法，开发小组能测量出他们实际已经完成了多少验证工作，而不是已经执行了多少次(大部分是多余的)仿真周期。
功能覆盖的语言规范被设计成和界定过程中得到的需求规范相匹配，覆盖规范中的断言语言也可用于捕捉实现的假设，这是基于断言的验证(ABV)的一部分。
全部覆盖是完全了解一个项目状态的方法，而功能覆盖则与设计特性直接相关。断言覆盖与功能覆盖以及实现完整性都有关系，硬件和软件代码覆盖可以让我们知道设计完成得怎样。
e. 设计详细的覆盖模型
界定过程的结果是得到一系列需要验证的特性，而规范必须对这些特性加以描述以便度量，覆盖则用来定义验证的度量标准。界定的结果是产生两种类型的度量标准：明确的规范度量标准和明确的实现度量标准。明确的规范标准由工程师从规范中选取，明确的实现标准则当RTL可用后，工程师从RTL实现中选择。
计划阶段出现的典型疏忽是对覆盖模型缺乏仔细研究。覆盖模型必需足够完整以代表需要验证的所有特性，同时它也必须足够简练，这样开发小组和验证工具才能在给定的时间段内完成任务。这样的判断十分关键，因为100%地验证绝大部分关键功能比在很详细的覆盖模型中缺失关键功能要好得多。
f. 选用集合法来跟踪验证过程
所谓管理，不外乎计划和执行，而跟踪项目进度是能够知道项目团队是否在执行的方法。问题是怎样才能选到能够代表项目进度并能揭示项目中存在的问题和风险的少量衡量标准？
通常，项目团队会定义一些重要阶段(milestone)来大致勾画出项目进展情况。要想尽量提高项目团队的效率，在计划这些重要阶段时应注意，这些重要阶段必须能推进项目中费时或者风险的部分向前发展。然而，仅仅验证某个特定的特性已经无法满足要求了。
越来越多的团队定义能暴露可能出现的系统集成问题的重要阶段。他们提供正确的功能性模块的子集以便能进行早期系统验证，这就要求详细定义一些特性，这些特性在每个重要阶段中都必须出现。
利用覆盖来定义这些特性，并对具备系统某部分特性的重要阶段进行仔细的定义和跟踪。这样一来，项目重要阶段不再仅仅是在进度表中标出一块作为阶段完成的标志，它具备了更重要的意义，那就是切实降低项目的质量和进度风险。
还有一些人工跟踪的重要阶段，其中包括首次工作仿真，以及覆盖模型的生成、检查和完成。这两个重要阶段也叫做实现跟踪，预期和完成这两个重要阶段往往会使次采用覆盖驱动验证的团无所适从。一种可执行的验证计划就能为他们分别规定好条件，从而改善这一项目早期关键阶段的可预测性。
g. 采用过去的衡量标准估计进度
创建工程进度表是一种艺术，它反映了负责项目计划的团队经验是否丰富，也会让他们想起过去在类似的任务上花费的时间长短。在功能验证中使用的标准越多，进度估计就越成其为一种工程艺术，它使验证过程是可见的。而问题是过去很少有团队能够得到这些标准，也很少有团队在创建一个能量化和估计项目进度的模型上投入。我们的客户中有一些富有经验的客户除了覆盖标准以外还在跟踪更多的标准，力图进一步提高其进度估计的程度。
他们跟踪的这些标准用于在设计和验证环境中测量实现、调试和集成每IP及其提取所花费的时间，不同大小的IP配以不同的数据点(data point)。他们还要估计开发新IP相对于重用旧IP所造成的不同影响，项目团队的工程经验和工程技能对项目的影响，以及自动化验证过程与人工验证管理之间怎样权衡。他们不但要考察硬件和软件，还要考察模块、芯片以及系统级的问题。
如果没有实际的历史度量标准，那么项目团队可以通过估计得到这些标准。但今天的进度表往往是对任务的估计，而不是对度量标准的估计。项目团队通过将这种估计细分为更多详细的级别，能够发现他们的论证中的假定成分。此外，他们还会针对每个工作人员怎样完成其工作给出详细的细节。
这样我们就能构建出一个模型或等式，它利用历史度量标准，辅以现有的项目估计，创建详细的项目进度表。然后再考虑这些估计以及模型本身的程度，并且根据进度估计许下项目进度的承诺。采用合适的自动化工具，项目团队就能将这些估计与整个项目、任务以及详细的标准进行比较，并从中吸取经验以利于下一个项目的计划。
需求改变
每个工程师都知道，需求总是在变化的，即使推迟计划也不会改变这一事实。许多电子产品所服务的用户市场与季节的关系比与项目结束时间的关系更加密切。管理人员一直都在寻求方法，企图控制变化过程，使项目更具有可预测性。关键问题是“我们晚能在什么时候才引入变化，并按进度发布一款高质量的产品呢？”。
在从规范制定到项目结束阶段一直对验证起推动和管理作用的自动化机制中，历史验证计划是一个关键部分。自动化验证机制中包括：
1. 可执行的验证计划
2. 用于测量验证进度的覆盖和断言
3. 用于检测和汇报违规规范的检验器和断言
4. 激励产生(Stimulus generation)
进行更好的验证计划并采用可执行的验证计划能够带来以下几点好处。
1. 提高产品质量
显而易见，好的计划会促成高质量的产品。每一个接受我们的帮助改善了其验证计划的客户，在这个过程之后都发现了他们的问题。即使对那些进展顺利的项目而言，进行严格的验证计划，其价值也是显而易见的。有时，验证计划的价值就在于它为计划创建了一个通用的流程和术语。
2. 提高项目进度的可预见性
更的工作估计以及更早发现项目与计划的偏差增强项目进度的可预见性。同时，详细设定重要阶段也能帮助更早发现项目中的关键问题，从而使验证团队有机会在项目的正常过程中成功地应对这些挑战。
3. 提高团队效率
一个可执行的验证计划既能帮助一个团队更有效地交流，也能帮助他们更轻松地将工作重点放在项目的关键因素上。而标准汇报方式也增加了团队的工作效率和管理层的管理效率，使资源能集中应用在关键的任务上。