一、摘要　　

   这是我们的项目计划与跟踪的内容，在项目实施中使用得很好，我拿出来与大家分享，希望大家多提意见，谢谢！最初的项目计划不够精确和准确，不能直接拿来指导我们的日常工作，也不易跟踪。我们采用三层计划机制将计划中的任务拆分成可跟踪的小的任务来执行。另外，采用不同周期不同规模的review活动来跟踪计划的执行，并不断地调整我们的计划。在跟踪的过程中，由项目经理来负责将每个任务的实际工作量记录下来，以便最后的统计。　　

总过程图

备注：

1．根据项目进度定期地（或事件驱动地）进行peer review和progress review.

2．偏差包括实际情况与原计划不相符的任何地方，例如时间安排，人力资源，设备，任务安排，等各方面。

3. Review不仅是查找已执行工作与原计划的偏差。有时候，根据现阶段工作的情况很容易判断后续工作原定计划的不合理性，这部分计划也需要及时修订。

二、第一部分：不同层次的计划　

　

  项目计划的目的是为实施软件工程和管理软件项目制定合理的计划。三层计划机制是艾思普公司项目计划的主要内容。　　

  高层计划：设计师和项目经理根据用户需求制定高层计划，给出项目进行的主要阶段和各种需求。此计划需要经过审核通过后方可执行。为了便于理解，高层计划也可以称为月计划。　　

  中层计划：项目经理，设计师，以及所有的参与人员共同制定中层计划。中层计划是高层计划的任务分解。中层计划也可称为周计划。　　

  低层计划：根据中层计划中的任务安排，每个人制定自己的低层计划。低层计划也称为天计划。

1、 高层计划　　

  在各种估算的基础上，根据用户需求给出项目进行的主要阶段和进度计划，就是高层计划。　　

  进入标准：用户提出的各方面需求（如成本需求和交付时间要求，等）和软件项目的开发策略。　　

  人员：设计师，项目经理　　

内容：

1）阶段：项目总体分为哪几个阶段来进行？标准软件过程是：发现、定义、概念、设计、和实现。根据具体的项目情况，可以将其裁剪和细化。

2）时间：各个阶段要求在多长时间内完成？或严格要求什么时候完成？

3）资源：按阶段阐明需要的资源，包括人力资源和关键的设备资源。人力资源说明角色和数量。设备只需提出特殊的或关键的设备资源，如需要一个特殊配置的服务器，在系统测试中要搭建模拟环境，等等。

4）退出标准：每阶段要达到什么要求才可以退出，即阶段完成的要求是什么？承诺与认可：高层计划需要客户和高层管理者的认可，并且有关人员必须被告知高层计划中与其相关的内容，并得到他们的承诺和认可。比如，通知人力资源部门人员需求，通知财务部门设备要求和经费需求，等等。　　

备注：

1）计划的依据：用户提出的项目要求，公司采用的软件工程过程，以及自己的经验。

2）需要考虑公司的一些实际情况：比如人员调配，员工的技术能力，等因素。

1.1、一个细化的软件工程概念模型　　

下图是笔者理解的软件工程概念模型（采用UML类图的语法）：

1）、模型概述

　　图中，“理论与经验”和“工具”可以认为是2个比较独立的概念，其他概念可以被分为4组——“方法论”、“过程”、“目标”、“项目”，分别标以不同颜色。这4组主要概念构成了软件工程概念模型的骨架，可以描述为：为达到一定的“目标”，我们建立起相应的“项目”，在某种“方法论”的指导下，按照一定的“过程”，生产出相应的软件“产品”。

　　从这个模型的骨架中，我们能清晰看到上面精简模型的影子——（目标，方法，活动）三元组。但显著区别是，更加强调“活动”的组织和控制方式——“过程”。这是软件实践发展的必然结果，因为，随着软件产品的复杂程度不断提高，势必要更加强调“过程”。RogerS. Pressman在其经典著作《软件工程：实践者的研究方法》里就指出：大约每隔5至10年，软件界就会重定义“问题”，将其焦点从“产品”转移到“过程”。

2）、方法论

    “方法论”是在一定“原则与策略”指导下的一套相关的“方法与技术”，而“方法论”可以分为“开发方法论”和“过程方法论”2种。相应的，“原则与策略”可以是开发策略，例如著名的“功能分解”策略；也可以是过程策略，例如迭代模型等“过程模型”，就是过程策略。

　　应当说，“过程方法论”是随着软件实践的深入，在“开发方法论”产生之后才产生的概念。Roger S. Pressman在其经典著作《软件工程：实践者的研究方法》里就指出：大约每隔5至10年，软件界就会重定义“问题”，将其焦点从产品转移到过程。在本文后面的章节，笔者将用“过程方法论”的概念解释“Agile到底是过程还是方法论”的迷惑。

　　另外，值得一提的是，在实际当中，存在“方法”其实是指“方法论”的现象，在此说明一下。一方面，“方法论”是为完成特定目的一套“方法”，“方法论”和“方法”是一对多的关系；另一方面，实际中人们常将“方法论”简称为“方法”，所以也可以认为“方法”是个递归的概念，它可以是“原子方法”，也可以是“方法论”。至此，当你同时面对“Agile方法”和“Agile方法论”这2种说法时，就不必迷惑了。

3）、过程

    “过程模型”是对具体“过程”的抽象，它仅规定了后者的框架，例如瀑布模型规定了“过程”是线性框架；“过程模型”的例子还有螺旋模型、喷泉模型、迭代模型等。一个具体“过程”包括“开发子过程”和“管理子过程”2个子过程，它们分别由一组相关的“开发活动”和“管理活动”组成。“开发活动”开发出或再加工“开发工件”，“管理活动”使用“管理工件”，对“开发活动”和“开发工件”进行管理。

    “过程开发与改进”是一个特殊的“管理子过程”。“过程开发与改进”与其它一般的“管理子过程”相比，后者是为软件产品的开发服务的，而前者是以开发和改进软件过程本身为目的。软件工程大师Osterweil在其论文《SoftwareProcesses are Software Too》中高屋建瓴地指出：软件过程也是软件。软件有一个开发的过程，软件过程也有一个开发的过程；软件开发产出软件产品，软件过程开发产出过程产品。

     RUP是著名的软件过程产品。CMM是著名的软件过程改进框架，它本身不是特定软件过程的定义，它只是建议如何一步一个台阶地改进软件过程。在本文后面的章节，笔者将从“过程开发与改进”的角度，谈谈RUP的定制和CMM的定位问题。

4）、目标

　　任何实践都是有“目标”的，软件实践也不例外；比如“开发Bug跟踪系统”就是一个“目标”的例子。“目标”的完成，依赖于一系列“任务”的完成；比如上述“目标”可以分解为“分析”、“设计”、“编码”、“实现”等“任务”。

      “任务”通常在“方法论”的指导下完成；比如“分析”任务，可以选用“OOA方法论”，也可以选用“结构化分析”方法论。每个“任务”还可以进一步分解成多个“子任务”；比如“分析”可以分解为“需求采集”、“需求分析”、“建立分析模型”等“子任务”。

    “子任务”通常使用相关“方法与技术”来实现；比如“建立分析模型”子任务，可以选用“UML建模技术”，也可以选用“结构化建模技术”。

5）、项目

    “项目”是“目标”、“过程”和“方法论”3者的关联类；这意味着任何一个“项目”，都采用一定的“过程”，在某种“方法论”的指导下，完成某种“目标”。“项目”的“目标”常常就是“软件产品”本身，但也可以不产出任何“软件产品”。“项目”是为完成特定“目标”所做出的临时性努力，可以是建造一栋大楼，一座工厂，也可以是解决某个研究课题，不一而足。

    “产品”就是一组“开发工件”的集合，就象经典的“软件”的定义中说的，“软件是程序、文档和相关数据的统称”。“管理工件”是伴随“项目”的进行产生的，但它并不是要交付给最终用户的。

6）、其他

　　现在回过头来看“理论与经验”和“工具”这2个概念。“理论”是高度系统化的知识，“经验”是尚未进行系统化抽象的知识。“理论与经验”是“方法论”的依据，正是在“理论与经验”的指导下，人们总结出方法论的“原则与策略”，又在后者的指导下，人们将众多“方法与技术”组织成一套完整的“方法论”。“工具”用来支持“方法与技术”的，好的“工具”可以提高人们的工作效率，减小出错几率。

　　其实图中还包含了其它一些信息。比如，“方法”和“工具”是多对多关系：一种“方法”可以采用多种“工具”（比如画Use Case图可以采用Visio、Rose等多种工具），一种“工具”也可支持多种“方法”（比如Visio可以画流程图、UML图等多种图）。

　　又比如，“方法”和“过程”是多对多关系：一种“方法”可以被多种“过程”采用（比如CRC卡方法可以被RUP、XP等多种过程采用），一种“过程”也可采用多种“方法”（比如RUP可以采用OO建模、结构化建模等多种方法）。

　　篇幅所限，恕不一一列举。 

1.2、软件工程概念模型的具体应用

　　下面再举几个具体的例子，以说明软件工程概念模型在快速学习、正确理解和深入掌握软件工程技术方面的作用。

1）、搞清楚Agile是过程还是方法论

　　当前，“Agile过程”和“Agile方法论”的说法都很流行，令初学者相当迷惑。下面根据软件工程概念模型的知识，来弄清这个问题。

　　好的开始是成功的一半，我要做的第一步就是先推翻“Agile是过程还是方法论”这个问法，改问“Agile是过程、开发方法论还是过程方法论”。

  第二步，分析《AgileSoftware Development》一书中给出的Agile模型：

　　通过对模型的分析，可以看出它是对过程建模：

• 如果去掉人和团队的因素，上面的模型最主要的要素就是过程（Process）、活动（Activities）、产品（Products）和技术（Techniques）了，这显然是个过程的模型。

• 上面的模型中有相当多的和人相关的要素，包括角色（Roles）、技能（Skills）、个性（Personality）、团队（Teams），对人的因素的极其重视，正是Agile过程的显著特点。

• Agile过程是面向人的（people-oriented）过程，实施Agile过程的一个关键之处是让人“接受”一个过程而非“强加”一个过程。

  

  我准备提前下结论了——谈过程哪能不谈它背后的方法论呢——Agile是有它自己的过程方法论的过程。

2）、为CMM定位

  CMM是一个大家关注已久的话题，CMM标准的提法颇为流行，下面笔者换个角度，根据软件工程概念模型的探讨，将CMM定位为“过程开发与改进的需求和测试方案”。

CMM是软件过程开发的需求：

• 关键实践描述了应当“做什么”，而不是强制规定“如何做”；关键实践的描述就是过程开发的需求项。

•  关键实践被分组，成为一些关键过程域。相当于需求项的分组，便于管理。

• 关键过程域的实施都是为了达到一定的目的，从需求的层次角度（请参考Wiegers著陆丽娜译《软件需求》一书），可将“目的”理解为“业务需求”，将关键过程域理解为“用户需求”，前者由后者来实现。

• CMM通过定义的这些关键实践和关键过程域，覆盖了我们要开发的软件过程的主要目的（比如需求管理、产品工程）。

CMM是软件过程开发的测试方案：

• 从原理上，需求就是测试依据。软件工程中的一条基本原理就是：依据需求进行测试。

•  从实施上，我们通常依据需求来编写测试用例，然后执行这些测试用例。

•  BrainMarick更是表述了他的具有革命性的观点：“我并不想写出一套用于捕捉用户愿望的需求，取而代之的是，我要写出一套测试，一旦这些测试能够通过，产品就能使她满意。”尽显大师风范。

•  CMM提供的大量提问单，和测试用例的概念对应得很完美，我们通过这些提问单就可以轻松测试出每一个关键实践进行得怎么样，进一步测试出每个关键过程域完成得如何，该组织的软件过程的能力成熟度有多高。

3）、理解RUP定制

  RUP是著名的软件过程产品，包含了相当优秀的思想，比如：

•  为了使风险最小化，RUP引入阶段概念和迭代开发模型，以便给开发者足够多的机会，在付出太多代价之前放弃或调整开发。

•  为了使并行最大化，RUP引入工作流的概念，工作流是相关活动的集合，不仅工作流之间也是并行，工作流内部的活动也是可以并行的。　　

  然而，根据具体的实践情况不同，使用RUP前应当对其进行适当定制。

  “RUP定制”属于“过程开发与改进”中的“过程开发”，而且严格来讲，是“过程开发的再工程”。再工程（reengineering）是对现有软件系统或软件过程的重新开发过程，包括逆向工程、新需求的考虑和正向工程三个步骤。

　　值得一提的是，“RUP定制”既可以是“RUP剪裁”，也可以是“RUP扩充”。RUP剪裁大家讨论的比较多了，有兴趣的读者可以阅读本文参考文献中所列的《RUP的剪裁原理和剪裁过程》一文。

著名的RUP扩充的例子有：

•  RoninInternational公司将RUP扩充成为EUP。

•  再比如爱立信在RUP的基础上进行扩充，开发出ERUP作为公司范围内的框架结构。　　

1.3、软件工程概念模型的启示

1.3.1、软件工程，一门实践的科学

　　通过对软件工程概念模型的研究，强烈地感觉到，软件工程是一门实践的科学——它的出发点和最终目的是指导实践。基于此，我们至少应当注意2点：

•  从时间上，实践是发展的，基于实践的软件工程学科也必然是发展的，比如近几年，软件工程领域的发展就相当大。我们必须意识到这一点，不断学习新知识，才能适应软件实践的需要。Roger S. Pressman说：“软件工程将发生变化——对此我们可以肯定。”

•  从内容上，软件实践的差异是巨大的，我们不能生搬硬套。正如Alistair Cockburn所说：“不同的项目需要不同的方法”。

1.3.2、软件过程，合适的才是最好的

　　据我所知，好的软件过程在不少人的脑子里，是一个“越……越……”的答案。比如，文档越多越好，分工越细越好，控制粒度越小越好，等等。还有，人们认为好的软件过程是可以照搬使用的，我听到过类似“我在某某大公司都是……”的抱怨。

　　其实通过软件工程概念模型的探讨，我们可以看到，软件过程是整个模型很多节点中的一个而已，这意味着软件过程和很多因素有着影响、被影响的关系：

•  软件类型、软件规模、软件重要程度、开发人员素质、管理和支持人员素质、合作单位素质等，都是影响软件过程制定的因素。

•  而且，且不可单纯认为软件过程仅仅涉及到开发人员，用户、合同确定者、投标者、项目管理者等，都可以成为软件过程的“涉众”；也就是说，他们都可能是待开发的软件过程的用户，应当收集他们对软件过程的要求。

1.3.3、对个人的启示

　　分析了软件工程概念模型，可以看出，从某种角度，可以认为软件产品是多种技术协作的结果。技术的协作最终表现为个人的协作，软件工程概念模型对个人有何启示呢？

•  明了自己知道的和不知道的，尊重他人，是一个团队的必要基础。

•  注重团队成员间技术的互补性和全面性。

1.3.4、呼唤高层次人才

　　看着模型，想着近年来国际上软件工程的巨大发展，深感国内在软件工程领域的落后，“透过变化看趋势、透过技术抓原理、把握软件工程发展脉搏”的高层次人才太少。

　　我辈尚需努力。

1.4、简化原型法需求分析的第一个阶段

　　管理信息系统属于数据库应用。数据库应用需求分析应该围绕数据，而不是功能展开，因此应该首先解决"有什么"，然后再明确"做什么"[4]。第一个阶段就是要解决"有什么"，即由项目经理与用户进行协商，确定系统的技术协议，因此可以称为技术协议阶段。技术协议需要开发方的项目经理与用户单位的技术主管签字并盖章，并以合同附件的形式存在。技术协议的主要内容有：系统的边界、系统处理的业务、与其它系统的接口、工程的进度控制、培训安排和技术服务承诺。

1.4.1 系统的边界

　　系统的边界规定系统覆盖的作业范围，主要有地理边界（规定系统运行的部门、分支单位等）、操作员范围（规定操作系统的所有操作员身份、分布和大致权限）和业务范围（规定系统处理的业务，对于不处理的边沿业务特别明确指出）。

1.4.2 系统处理的业务

　　系统处理的业务涵盖系统处理的所有业务，包括各种业务的描述、数据来源、实现要求。但是业务规定不要求过细，可以对应实际系统中的一个模块。如：电力MIS中输电设施管理子系统中的线路设备管理，不详细描述线路设备管理中的所有功能。

1.4.3 与其它系统的接口

　　与其它系统的接口明确规定接口的系统、功能和实施单位。在接口的实施单位中明确是由开发方完成，还是由开发方协助第三方完成。

1.4.4 工程的进度控制

　　工程的进度控制规定工程的开始、结束日期和具体工程项目的名称、完成时间、地点、完成标志及责任分工。具体项目一般包括：采购设备到达现场、采购设备安装调试、完成网络布线、开发准备阶段、业务需求调查、系统分析和设计、软件编制、现场调试、数据准备及录入、功能确认、试运行和系统验收。责任分工规定双方对于具体项目的工作内容和配合方式。在配合方式中规定人员组织方式、人员素质要求、提供的设备和场所。完成标志规定具体项目完成提供的文件名称和要求，如：网络布线验收报告和硬件设备验收报告等。

1.4.5 培训安排

　　训包括操作员和系统维护人员的培训。培训安排包括每种培训的人员数量、培训内容、培训时间、地点、组织方式和教材，并规定教员和学员的素质要求，及培训后学员达到的水平。。

1.5、  简化原型法需求分析的第二个阶段

　　如果说第一个阶段解决"有什么"的问题，那么第二个阶段解决"做什么"的问题。主要工作有需求调查准备、到用户单位进行需求调查分析和进行需求评审。

1.5.1 需求调查准备

　　需求调查准备工作，在系统的技术协议签订后，严格依照技术协议进行，主要有向用户单位发放业务调查表、建立需求分析文档原型和建立系统简化原型。业务调查表在系统的技术协议签订后，立即通过传真发送到用户单位，要求用户单位在需求调查人员到达现场之前完成。业务调查表内容包括：具体业务的名称、上级业务、下级业务、发生条件、处理的数据和详细流程（处理岗位、处理方式和审核细节等）。需求分析文档原型是根据技术协议编写的需求分析说明书原型，它的格式与标准的需求分析说明书相同。其中的状态迁移图和各种表证单书等不明确的内容，采用相似系统的或由系统分析人员根据技术协议和以往经验设计。

  系统的简化模型根据技术协议的要求，仿照相似系统设计。简化模型采用可视化的数据库编程语言设计，一般采用数据库应用开发人员熟悉的PowerBuilder(PB)或Delphi。简化模型的主要设计要求有：

1）充分考虑系统的设计与实现，不得与实际系统脱节；

2）尽量仿真实际系统的操作界面，与实际系统的操作过程完全相同；

3）可以单机安装运行，不与实际数据库连接；

4）演示数据的存储可以通过文本文件、单机的数据库或PB外部数据源的数据窗口；

5）对于界面中容易误解或难以理解的操作，在功能帮助按钮中给出说明；6）界面中难以实现或工作量很大的功能，以标注方式详细说明；

7）运行稳定，并比实际系统对硬件要求低。

1.5.2 需求调查分析

　　需求调查分析在确认需求调查准备的三项工作完成后，由开发单位的系统分析人员到用户单位进行。系统分析人员与用户单位安排的业务主管共同讨论业务调查表和系统简化原型，并不断修改完善系统简化原型和文档原型，最终形成共识，并要求业务主管在需求分析说明书上签字。最终系统简化原型和源代码留在用户现场，便于系统的操作员进一步理解分析，直到最终掌握；而且有利于提出进一步的改进意见。改进意见可以随时通过邮件或传真直接发到开发单位，或由用户单位的系统维护人员修改简化原型后，随时发到开发单位，从而便于开发人员及时修改系统的设计和编码。

1.5.3 进行需求评审

　　需求评审一般由用户单位组织，评审团成员由同行专家、系统分析、设计和测试人员组成。评审的依据不仅有需求分析说明书，还有系统简化原型；同时在评审过程中，系统简化原型不断进行优化。评审的目标是要求需求分析说明书具有正确性、可行性、必要性、具有优先级属性、可验证性和无二义性[5]。需求评审报告作为对需求分析的补充和修正，由双方负责人签字，以需求分析说明书附件的形式存在，同样指导下一步的系统设计工作。　

1.5.4 、几点说明

    1、此方法适合各种MIS工程的需求分析，特别适合致力于某一领域MIS开发的软件公司。采用此方法，开发同类项目越多，需求分析工作的效率越高。

 2、在需求分析过程中，由于需要设计系统简化原型和文档原型，并充分考虑到系统的设计与实现，因此与其它需求分析方法向比，提高了对需求分析人员的要求。在实际工作中，一般由资深的软件分析和设计人员进行。

    3、此方法不仅适合MIS软件工程，同样适合其它大型软件工程。

    4、由于需求分析工作本身的难度和重要性，此方法同样要求用户单位和需求分析人员对需求分析所有工作内容，引起足够重视；科学安排需求分析工作步骤，某些步骤可以同时进行；所有工作步骤不得应负或疏忽。

1.5.5 结束语

　　目前简化原型法已经在多个电力MIS工程中应用，大大提高了需求分析的工作效率。实践证明，简化原型法具有以下特点：

    1）简化的系统原型开发工作量大大降低，修改和补充方便；

    2）简化原型大大缩短了需求分析人员与业务主管之间的距离，便于交流；并大大加强了需求分析人员与业务主管对系统的认识，有利于发现和解决问题；

    3）简化原型的设计提前考虑了系统的设计与实现，大大降低了软件工程的风险；

    4）简化原型增加了系统操作员对实际系统的认识，大大简化了工程实施后系统的操作培训；

    5）简化原型可以直接指导工程的设计和编码，便于系统开发的组织。这种方法也可以用于其它软件工程，对于其它需求分析方法的改革也具有指导意义。　　

参考文献

[1] 毋国庆，朱立松等.嵌入式实时系统的软件需求检测. 软件学报,2002.5(13).

[2] 吕梦雅，陈晶. 面向对象的原型法在需求分析中的应用. 河北省科学院学报, 2002.3(19).

[3] 王继成，高珍. 软件需求分析的研究. 计算机工程与设计, 2002.8(23).

[4] 张峰岭. 数据库应用的需求分析研究.计算机工程与应用, 2002.18.

[5] 李师贤，张珞玲. 需求分析的常见问题及其对策分析. 计算机工程, 2002.1(28). 。

2、 中层计划

　　将高层计划的任务进一步细化为每个人或每个小组在大约一周时间的工作，就成为中层计划。进入标准：高层计划已制定且通过审核。

　　时间：在进入每个大的阶段之前，本阶段的中层计划一定要明确，并取得团队的认可。本阶段的中层计划是开始本阶段的主要输入。　　

  人员：项目经理及设计师领导项目团队共同制定中层计划。中层计划将把任务具体到团队的每个人。

　　

  内容：

1）任务：项目的每个阶段可以拆分为哪些任务？

2）人：每项任务的责任人是谁？一项任务可能不止一个人完成，但必须指明一个负责人（Owner）。

3）设备资源：什么时候需要什么样的设备资源，需要给出设备的具体要求。如性能要求，配置要求等。

4）时间：每项任务要求在多长时间内完成？或严格要求什么时候完成？

5）任务之间的依赖关系：各项任务之间有无依赖关系？是什么样的依赖关系？

6）里程碑：阐明一些关键的事件点，如关键人员或设备的到位期限，什么时候审核，等等承诺与认可：保持与高层计划的一致性，每项任务的估算得到执行者的认同，有依赖关系的任务安排要得到相关人员的认可。

　　备注：

    1）需要邀请有测试经验和部署经验的人分别参与测试和部署的工作计划，他们会帮助团队制定出较合理的中层计划。

    2）当中层计划与高层计划不一致时，将中层计划重新估算一遍。如果还是与高层计划不一致，则以中层计划为准，要求修改高层计划

3、 低层计划

　　每项任务的执行者根据中层计划将自己的任务细化到每一天，即低层计划。

　　进入标准：中层计划已制定且项目团队整体认可。

　　时间：在每周周一的早会之前，制定出本周本周或两周内每天的计划。　　人员：低层计划一般由具体执行任务的每个人来制定。这将是每天Team meeting的依据。　

　内容：每天的任务和需要提交的文档。

　　承诺与认可：要求每个人计划中特定时间所要求的支持得到支持提供者的认可。另外，要求每个人的计划符合中层计划，与其他人的计划进度没有冲突。

　　注：在实际开发过程中，往往有些工作不能拆分到每一天。就是说，一件事情需要几天来完成。如果本任务不在关键路径上，而且与其他人员的工作关系比较独立，可以不拆分此任务，由执行者本人掌握进度。否则，需要将任务尽量拆分开来，按内容划分为几部分，或用百分比来划分，以便更好地掌握整个项目的进度。

4、 三个计划的关系

　　计划更改的时候，一定要保持各层计划的一致性。高层计划会因中层计划的更改而调整，低层计划会受中层计划的影响。

三、第二部分不同周期的Review

　　项目跟踪的任务是对照计划评审和跟踪软件完成的情况和结果，根据实际完成的情况和结果调整这些计划。艾思普公司的Review工具是项目跟踪的主要内容。

　　根据目的和周期的不同，项目跟踪中用到3种Review工具：daily review, Peer review, 和Progressreview。

1、 Dailyreview

　　目的：跟踪团队成员每天的任务完成情况，给团队提供一个交流的机会。

　　时间：在每个工作日的开始。一次Daily review一般持续10~15分钟。　　形式：以teammeeting 的形式进行。

　　参加人：团队所有人员（包括项目经理和设计师）。

　　活动：

1）跟踪团队成员每天的任务完成情况

2）交流相关问题

2、 Peerreview

　　目的：跟踪项目每周的任务完成情况，交流相关问题。

　　时间：每周进行一次。Peerreview一般不超过1小时。

　　形式：会议形式。由项目经理来主持。一般要求项目经理提前将会议邀请发给大家。

　　参加人：团队的所有人员。

　　准备：会议开始之前，项目经理和设计师必须安排好会议的议程。

　　活动：

1）审核项目计划，审核每个组员在项目计划中的对应工作；

2）讨论项目的任何有关问题；

3）共享知识；

　　会议的记录：由项目经理在当天将会议的内容整理出来并放置到CVS中，命名规则为Peer review_date_contents.doc。会议的整理文档必须使用公司统一规定的文档模板。

3、 Progressreview

　　目的：跟踪项目是否在向原定目标进展，提出并沟通项目中的任何相关问题，使得每个人都了解整体项目的进展情况。

　　时间：每四周进行一次。项目的第一次Progress Review应该在项目启动的两周内进行。有时也可以由项目经理临时组织（比如发现项目现状明显偏离了原定目标，需要及时采取措施）。Progress Review通常持续1-3小时。

　　形式：会议形式。由项目经理来主持，一般要求项目经理提前将会议邀请发给大家。

　　参加人：团队所有人员。

　　准备：会议开始之前，项目经理和设计师必须安排好会议的议程。

　　活动：

1）确认团队理解客户对项目的要求；

2）审核项目计划，审核每个组员在项目计划中的对应工作；

3）就项目的现状，粗略地对项目进行估算；

4）讨论客户提出的重要问题；

5）识别项目的风险，并产生减缓策略；

6）讨论并安排合适的QualityReview；

7）审核项目过程（如，信息传递方式是否合适，团队的职责，等）；　　会议记录：由项目经理在当天将会议的内容整理出来并放置到CVS中，命名规则为Progress review_date_contents.doc。会议的整理文档必须使用公司统一规定的文档模板。

4、 Review的记录　

　1）、Dailyreview

Dailyreview的记录内容包括每个人的计划和To do。

     To do：用来记录将要做的事情。这些事情不属于计划中的任务，但需要在一个特定的时间之前完成才能保证项目有关事件的顺利进行。

　2）、Peerreview和Progressreview

      Peer review和Progressreview的记录内容一致，包括：参加人及角色；风险；新的问题；下一步工作；上次Review留下来的问题和工作；下次Review的时间安排。　

　三、第三部分职责