第二讲 项目计划总览 2019/5/9

内容 项目计划的步骤 每一个步骤需要的技术 对每一个活动如何细化 2019/5/9

项目计划模型 有多种项目计划模型 我们讲以Step Wise Project Planning方法为例 PRINCE 2 【 Central Computing and Telecommunications Agency(CCTA) for use on British government IT projects.】（荷兰和澳大利亚也采用） 我们讲以Step Wise Project Planning方法为例 2019/5/9

例子 Brigette是一位在政府的管理服务部门工作的工程师。她看到了Brightmouth学院招聘信息系统开发部门负责人的广告。她被这样一个在小型部门中工作，从头开始建立一个合适的信息系统，“当自己的老板”的机会吸引了。她发出了申请并且得到了这个职位。 她面临的第一个任务就是实现一个独立的工资处理系统。 2019/5/9

例子 Amanda在一家国际办公自动化设备公司（IOE)工作，该公司生产各种高技术的办公设备并承担维护服务。目前，公司的一项拓展的业务就是对IT设备进行维护。他们现在开始对那些并非购买他们产品的客户提供维护服务。 公司原来采用的发票打印系统是针对每一项任务单独进行打印的。这样，其它公司可能需要多次使用该系统才能完成打印工作。现在公司决定对系统进行扩展，以使系统能够每月打印出财务信息的系统。 Amanda作为项目管理者，承担了该项任务 她们如何办？ 2019/5/9

计划过程（1） 0：选择项目 1：确定项目范围和目标 确定目标和这些目标的衡量方法 选择项目的责任人 确定项目所有的涉及人员和他们的兴趣 根据对项目涉及人员的分析修改目标 建立各方通信的渠道 2019/5/9

计划过程（2） 2. 确定项目结构 建立项目和策略计划的关系 建立标准和过程 建立项目团队组织 2019/5/9

计划过程（3） 3. 分析项目特征 分析项目是目标驱动的还是产品驱动的 分析其它项目特征 确定高层次的项目风险 考虑用户有关实现方面的需求 选择一般的生命周期方法 检查估计的资源 2019/5/9

计划过程（4） 4. 确定项目产品和活动 确定和描述项目产品（或交付物） 写出一般性的生产流程 确定产品实例 定义理想的活动网络 考虑阶段和检查点，修改理想的活动网络 2019/5/9

计划过程（5） 5. 估计每个活动的工作量 6. 确定活动风险 7. 分配资源 自底向上估计 对计划进行修改以生成可控的活动 识别和量化活动风险 制定风险降低方法和紧急处理手段 在考虑风险底基础上调整计划和估计 7. 分配资源 确定和分配资源 在考虑资源约束底情况下修改计划 2019/5/9

计划过程（6） 8. 检查、公布计划 9. 执行计划 10. 更细层次上的计划 检查项目计划中的质量因素 计划书面化并上报批准 2019/5/9

2019/5/9

1.识别项目范围和目标(1) 确定目标和这些目标的衡量方法 Brightmouth学院工资系统的目标我们已经讨论过了 IOE的Amanda的目标是已经被IOE管理部门批准的可行性分析中规定的那些目标。主要的目标是允许将详细的月帐单寄给每个客户，并将客户按月支付的钱分配到各项工作上。当然还有一些其它目标，如项目的时间、所用的资源等。 2019/5/9

1.识别项目范围和目标(2) 选择项目的责任人 Amanda发现她的经理和那些主要的用户已经建立了一个项目委员会来负责项目的方向。她发现不同部门使用不同的设备，而且各个部门也有不同的意见。这就需要委员会中的用户代表来解决他们的意见冲突。 Brigette发现她有两类客户：财务和职员部门。为了解决两个部门之间的不一致，他们同意两个部门每个月与该项目小组中的一位副主任来进行讨论。 2019/5/9

1.识别项目范围和目标(3) 确定项目所有的涉及人员和他们的兴趣 我们已经在第一章中讨论了这一问题 Brightmouth学院工资系统中的涉及人员已经讨论过了 那么，IOE公司中的维护帐务系统项目涉及人员有哪些？ 当然是客户，通过咨询那些客户代表显然有助于系统的开发 2019/5/9

1.识别项目范围和目标(4) 根据对项目涉及人员的分析修改目标 2019/5/9 为了使所有参与人员能够完全合作，有必要对项目目标进行修改。这就有可能需要为系统添加新特征以使某些人员满意。这有可能存在潜在的危险性，因为这样的话系统的规模越来越大，而原来的目标被模糊化了。因此该方法应该小心对待。 IOE维护人员现在增加了一个额外的任务：他们在完成任务后，需要将数据输入。他们又没有从中获益。因而为了给他们一些好处，系统加了一个功能：系统将自动记录余下的零部件。 而对于Brightmouth学院，人力资源部门为了准备工资细节需要大量工作。那么我们可以加上一个功能就是为该部门产生管理信息报表 2019/5/9

1.识别项目范围和目标(5) 建立各方通信的渠道 对于内部人员，是很直接的。但是对于开发工资系统的项目管理者需要与银行建立一个接触点。 2019/5/9

2.确定项目结构(1) 建立项目和策略计划的关系 2019/5/9 组织需要确定实施各个项目的顺序。同时，我们也需要建立新系统可符合的框架。例如为了使系统能够通信所需的软硬件标准 Amanda发现她从事的项目符合IOE的战略规划，由于该项目是对原系统的扩展，因此系统运行的软硬件平台是确定的。 从事Brightmouth学院项目的Brigette发现学院的战略规划中描述了需要开发新课程等内容，并且提到了“合适的管理过程”。在一份咨询公司的报告中提到了“财务独立”，并且建议开发独立的工资系统。尽管学院里有了很多教学用的IT设备，但是却没有专门为工资系统准备的硬件，因此在考虑软件时也需要考虑硬件。 2019/5/9

2.确定项目结构(2) 建立标准和过程 开发软件的组织必须定义开发过程。在最简单的情形下，在定义产品的同时，需要对软件生命周期的每个阶段进行定义。 这些标准和过程可能有： 变更控制和配置管理标准 质量标准和过程手册 度量程序 项目计划和控制标准 2019/5/9

2.确定项目结构(2) IOE的Amanda发现企业里有很多开发标准，其中规定了分析和设计方法将采用SSADM方法。她发现有一个单独的文档规定了质量过程。它规定了何时开展检查工作并且详细规定了如何开展检查工作。Amanda还发现了一套项目管理指南。 Brigette没有发现任何现成的规范，只有某些教师指导学生做的建议上有一些相互矛盾的叙述。Brigette写了一个简单的文档，规定了项目中的主要阶段。她强调每增加一个新功能或对功能进行修改都必须首先写一个详细的说明；而在每一项功能进行实现前，都必须得到用户的确定。同时，她对用户需求的修改过程规定了一个流程。 2019/5/9

2.确定项目结构(2) Brigette当然手头也没有质量管理过程方面的规定。但是她规定小组中的每个人（包括自己）每次完成工作后，都需要交给另外一个人进行检查；而在软件交给用户前，其它人需要对系统进行测试。她建立了一个系统来记录每一个错误和它们的解决方法。 Brigette并没有制定严格的时刻表。但是她每周星期一早晨都将和她的同事开会来讨论事情的进展。同时她也会每月去找副主任（她的上司），以及财务和人力资源部门的头来讨论进度。 2019/5/9

2.确定项目结构(3) 建立项目团队组织 项目领导在大型项目中经常需要定义一个组织结构。在组织结构中，可能会将人员分成若干组。 IOE中，系统分析员构成了一个团队，他们每一个人与那些用户直接接触。因此，一旦用户有问题，他们能够与信息系统部中的联系人进行沟通。编码人员构成了一个“池”，他们根据需要被分配到各个项目中。 Brightmouth学院中，Brigette任命了一个曾经作为学院中计算课程支持技术员的软件开发人员作第二负责人，她也被允许再招一个分析员/编程人员。 2019/5/9

3.分析项目特点(1) 分析项目是目标驱动的还是产品驱动的 分析其它项目特征 确定高层次的项目风险 2019/5/9 在IOE中，Amanda发现可能存在新系统不被维护人员接受的危险，特别是当需要建立一个新的中央帐务管理机构时。Amanda认识到需要先到各个部门进行一些咨询工作，然后新的流程逐渐引入，以使职员们慢慢适应。 Brigette认为应用领域已经定义的很清楚了。但是也存在一个风险就是可能市场上没有类似的系统，因此她决定项目中安排一个早期任务就是对主要的工资系统进行调查 2019/5/9

3.分析项目特点(2) 考虑用户有关实现方面的需求 选择一般的生命周期方法 检查估计的资源 客户经常会有他们自己的有关过程方面的要求。例如要求你采用面向对象技术等。 选择一般的生命周期方法 项目生命周期将根据上面讨论的一些内容来确定。例如如果用户的需求不明确，我们可能就需要用原型法。 检查估计的资源 一旦我们确定好主要的风险和项目的大致方法，我们就可以重新估计项目的工作量和所需的资源。如果信息足够，我们可以采用功能点方法来进行估计。 2019/5/9

4.确定项目产品和活动(1) 此时，我们可以对马上要去做的活动进行更详细的计划。长期的计划可以粗一点，而近期的活动则要详细一些。 确定和描述项目产品（或交付物） 没有活动，就没有产品，反过来说，如果不产生产品，也就没有活动。因此，确信我们已经完全确定了项目中生成的所有产品是保证我们确定了所有必要活动的前提。 产品包括：技术产品(如训练材料和操作指令），但是也包括管理和质量方面的材料，例如计划书就是管理方面的产品 产品将形成一个层次结构。主要的产品有一些子产品构成，子产品又有更小的产品构成。该关系可以用产品分解结构来记载。（Product Breakdown Structure, PBS) 2019/5/9

4.确定项目产品和活动(1) PBS的描述方法 2019/5/9 产品的名字/标识 产品的功能 产品的派生物（从中派生的其它产品） 产品的分解结构 产品的形式 相关标准 适用的质量标准 2019/5/9

4.确定项目产品和活动(1) 2019/5/9 IOE项目中，Amanda发现她可以用一个标准的PBS Brightmouth学院的Brigette发现没有标准的PBS,所以她就参考一些书籍来定义PBS，她决定PBS的某一部分中需要包含选择软硬件的辅助材料（如下）： 产品选择 容量（如多少雇员的信息需要维护） 办公室布置 用户需求 现存系统描述 用户所需的修改 测试案例 潜在供应商列表 邀请信 2019/5/9

4.确定项目产品和活动(2) 写出一般性生产流程 某些产品需要其它产品产生后才能进行，例如程序设计必须在编码前，需求分析后进行。该关系可以用产品流图(Product Flow Diagram, PFD)来描述。 系统描述 模块描述 模块设计 模块编码 模块测试 测试用例 2019/5/9

4.确定项目产品和活动(2) 在IOE项目中，Amanda有一个标准的PFD。Amanda的应用中的许多产品都有相同的类型：因此可以对每一个实例采用统一的PFD，没必要对每一个产品实例画单独的PFD了。 练习：根据PBS画出PFD。它代表了需要提交给软硬件供应商信息时需要产生的产品。 产品选择 容量（如多少雇员的信息需要维护） 办公室布置 用户需求 现存系统描述 用户所需的修改 测试案例 潜在供应商列表 邀请信 2019/5/9

4.确定项目产品和活动(2) 2019/5/9

4.确定项目产品和活动(3) 确定产品实例 同一PFD可以适合于某一产品类型的多个实例，因而我们需要确定每一个产品实例 Amanda认为在她的应用中有四个软件模块都可以用下面的PFD。 而Brigette认为 目前每个产品只有一个实例 系统描述 模块描述 模块设计 模块编码 模块测试 测试用例 2019/5/9

“理想”的含义是我们没有考虑资源约束，因而该图中四个模块可以并行开展 4.确定项目产品和活动(4) 定义理想的活动网络 为了从一个产品产生另一个产品，需要一个或多个活动完成这种转换。为了确定这些活动，我们可以生成一个活动网，以显示活动执行的顺序。 IOE帐务项目的部分活动网络如下 “理想”的含义是我们没有考虑资源约束，因而该图中四个模块可以并行开展 2019/5/9

4.确定项目产品和活动(4) 练习： 画出刚才确定的PFD的活动网络 2019/5/9

4.确定项目产品和活动(5) 考虑阶段和检查点，修改理想的活动网络 刚才的方法将使我们的项目具有最少的完成时间，它假设前面一个活动完成后，后面一个活动马上就能开展 在实际中，我们需要将项目分解为阶段并引入检查活动 检查点(check points)有时也被称为milestone 这些检查活动可能会延误项目，但是我们需要在效率和质量之间进行平衡 2019/5/9

4.确定项目产品和活动(5) 练习 Amanda认为四个模块分析完后，需要进行仔细的检查以保证一致性和匹配性。请重画活动图。 2019/5/9

5.估计每个活动的工作量(1) 自底向上估计 采用自顶向下估计工作量、成本和时间的方法在3.6中已经采用 此处我们需要对每个活动来估计工作量、资源和时间 估计的方法需要依据活动的类型而定 每个活动的估计将被自底向上的累加起来，然后与自顶向下的估计的方法对照一下 每个活动的完成时间可以在图上标注出来，这样，我们就可以计算整个项目所需要的时间 2019/5/9

5.估计每个活动的工作量(2) 对计划进行修改以生成可控的活动 2019/5/9 对活动进行估算后我们可以发现某些活动需要相当长的时间。长时间的活动将造成项目难以控制。如果某一系统测试的活动需要花费12个星期，那么在6星期后，你将很难判断是否50％的工作已经完成了。因而最好将它分解为多个子任务 IOE中Amanda必须估计每个模块的代码行数目，她收集了以前IOE进行的相同类型的应用的代码行信息，然后她参考了IOE中将代码行转换为工作量的表格。 尽管Brigette意识到他们必须进行一些二次开发以适合自己的需求，但是主要的软件是购买的现成软件，因此采用代码行来估计是不合适的。因此，她对每一个任务分配了一个时间，她意识到这些只是一个目标，她不能完全确定这些任务实际上要花多少时间。 2019/5/9

6.确定活动风险（1，2） 识别和量化活动风险 制定风险降低方法和紧急处理手段 在第3步中我们已经确定了整个项目的风险。现在我们需要确定每个活动的风险。 确定风险的危害和风险发生的可能性 制定风险降低方法和紧急处理手段 例如如果项目成员在关键时刻病了，紧急处理计划就是使用兼职人员 2019/5/9

6.确定活动风险（3） 在考虑风险的基础上调整计划和估计 2019/5/9 我们可以通过改变计划，如增加新活动来减少风险。例如新的编程语言可能就要求我们计划一些训练课程和时间 除了四个新模块需要开发外，Amanda发现还有几个模块需要进行修改。模块修改的难易程度将取决于原来编写的方式。因此可能的一个风险就是这些活动花费的时间会比预计的长。Amanda并没用定义风险降低方法，但是她进行了“悲观”估计。 Brigette发现由于用户需求调研被安排在假期中，因而可能找不到关键的人员。为了减少该风险，她在项目开始阶段加了一个活动，“安排用户采访”，这将使她能够预先指导这种情况是否发生。 2019/5/9

7.分配资源 确定和分配资源 在考虑资源约束的情况下修改计划 某些人员可能在同一时间内多个任务都需要。在这种情况下，我们就需要确定一个优先级。在这种情况下，项目周期可能会由于人员等待而被延长。 保证某些人在项目一开始就能够到位可能又会造成他们有些时候处于等待状态，效率不高。 2019/5/9

7.分配资源 Amanda现在有四个模块需要开发，有两个模块需要修改。在IOE，一般模块的分析由项目主分析师（就是Amanda)在初级分析师/设计师的帮助下进行。项目中有四个分析员/编程者可以进行设计、编码和单个模块的单元测试工作。经过与她的经理的仔细讨论，Amanda决定使用三个分析员/编程者以减少成员等待的风险。当然这有可能会使项目延长。 Brigette发现她自己不得不承担许多重要的任务。她可以将一些任务指派给她另外两个同事以减少工作负荷，但是她意识到这样一来，她将花更多的时间在交待工作检查工作上。因此，她调整了计划。 2019/5/9

8.检查/公布计划 检查项目计划中的质量因素 许多项目中经常出现前面完成的活动由于质量的原因需要重做的情况，这种情况将使项目失去控制。 我们必须能够确信在任务报告完成时，它确实是完成了。因此质量检查是非常重要的。每一个任务都必须有“退出需求”，这些需求是活动必须通过的质量检查。 Amanda发现在IOE中，对每一种类型的活动都规定了质量标准和过程手册。例如，所有的模块设计文档都必须通过小组检查后，才能进行编码工作。 2019/5/9

练习：除了她自己写的很少的标准外，Brigette没有任何现成的标准，为了保证用户需求理解的正确无误，Brigette可以引入什么样的质量检查手段呢？ 最简单的就是用户需求文档需要经过用户的阅读和确认，但是如果直到最后才给用户看，可能太晚了，因此可以在每次会谈后，将采访记录交给用户看。 计划书面化并上报批准 2019/5/9

9.执行计划和10. 更细层次上的计划 项目开始后，每一个活动都必须进行细化。对于那些近期的活动，我们首先要定义临时的详细计划，随着项目的进行，我们得到了更多的信息，此时项目计划将进一步细化。 当进行模块分析时，Amanda有一些时间可以对集成测试进行更详细的计划。她发现，对六个模块中的两个进行的集成测试可以单独进行。 当Brigette开始考虑活动“写邀请信”时，她发现自己必须对很多规则和过程有更多了解，因此为了写该文档，她需要从用户那儿连接更多的信息。 2019/5/9

小结 一个计划需要包含下列活动： 项目管理是一个迭代的过程 建立项目目标 分析项目特点 建立包含组织、标准、方法和工具在内的基础架构 确定项目的产品和所需的活动 分配资源 建立质量控制手段 项目管理是一个迭代的过程 2019/5/9