第二讲项目计划总览 - sjtu cs - 上海交通大学.ppt

* * 4.确定项目产品和活动(3) 确定产品实例 同一PFD可以适合于某一产品类型的多个实例，因而我们需要确定每一个产品实例 Amanda认为在她的应用中有四个软件模块都可以用下面的PFD。 而Brigette认为 目前每个产品只有一个实例 系统描述 模块描述 模块设计 模块编码 模块测试 测试用例 * * 4.确定项目产品和活动(4) 定义理想的活动网络 为了从一个产品产生另一个产品，需要一个或多个活动完成这种转换。为了确定这些活动，我们可以生成一个活动网，以显示活动执行的顺序。 IOE帐务项目的部分活动网络如下 “理想”的含义是我们没有考虑资源约束，因而该图中四个模块可以并行开展 * * 4.确定项目产品和活动(4) 练习： 画出刚才确定的PFD的活动网络 * * 4.确定项目产品和活动(5) 考虑阶段和检查点，修改理想的活动网络 刚才的方法将使我们的项目具有最少的完成时间，它假设前面一个活动完成后，后面一个活动马上就能开展 在实际中，我们需要将项目分解为阶段并引入检查活动 检查点(check points)有时也被称为milestone 这些检查活动可能会延误项目，但是我们需要在效率和质量之间进行平衡 * * 4.确定项目产品和活动(5) 练习 Amanda认为四个模块分析完后，需要进行仔细的检查以保证一致性和匹配性。请重画活动图。 * * 5.估计每个活动的工作量(1) 自底向上估计 采用自顶向下估计工作量、成本和时间的方法在3.6中已经采用 此处我们需要对每个活动来估计工作量、资源和时间 估计的方法需要依据活动的类型而定 每个活动的估计将被自底向上的累加起来，然后与自顶向下的估计的方法对照一下 每个活动的完成时间可以在图上标注出来，这样，我们就可以计算整个项目所需要的时间 * * 5.估计每个活动的工作量(2) 对计划进行修改以生成可控的活动 对活动进行估算后我们可以发现某些活动需要相当长的时间。长时间的活动将造成项目难以控制。如果某一系统测试的活动需要花费12个星期，那么在6星期后，你将很难判断是否50％的工作已经完成了。因而最好将它分解为多个子任务 IOE中Amanda必须估计每个模块的代码行数目，她收集了以前IOE进行的相同类型的应用的代码行信息，然后她参考了IOE中将代码行转换为工作量的表格。 尽管Brigette意识到他们必须进行一些二次开发以适合自己的需求，但是主要的软件是购买的现成软件，因此采用代码行来估计是不合适的。因此，她对每一个任务分配了一个时间，她意识到这些只是一个目标，她不能完全确定这些任务实际上要花多少时间。 * * 6.确定活动风险（1，2） 识别和量化活动风险 在第3步中我们已经确定了整个项目的风险。现在我们需要确定每个活动的风险。 确定风险的危害和风险发生的可能性 制定风险降低方法和紧急处理手段 例如如果项目成员在关键时刻病了，紧急处理计划就是使用兼职人员 * * 6.确定活动风险（3） 在考虑风险的基础上调整计划和估计 我们可以通过改变计划，如增加新活动来减少风险。例如新的编程语言可能就要求我们计划一些训练课程和时间 除了四个新模块需要开发外，Amanda发现还有几个模块需要进行修改。模块修改的难易程度将取决于原来编写的方式。因此可能的一个风险就是这些活动花费的时间会比预计的长。Amanda并没用定义风险降低方法，但是她进行了“悲观”估计。 Brigette发现由于用户需求调研被安排在假期中，因而可能找不到关键的人员。为了减少该风险，她在项目开始阶段加了一个活动，“安排用户采访”，这将使她能够预先指导这种情况是否发生。 * * 7.分配资源 确定和分配资源 在考虑资源约束的情况下修改计划 某些人员可能在同一时间内多个任务都需要。在这种情况下，我们就需要确定一个优先级。在这种情况下，项目周期可能会由于人员等待而被延长。 保证某些人在项目一开始就能够到位可能又会造成他们有些时候处于等待状态，效率不高。 * * 7.分配资源 Amanda现在有四个模块需要开发，有两个模块需要修改。在IOE，一般模块的分析由项目主分析师（就是Amanda)在初级分析师/设计师的帮助下进行。项目中有四个分析员/编程者可以进行设计、编码和单个模块的单元测试工作。经过与她的经理的仔细讨论，Amanda决定使用三个分析员/编程者以减少成员等待的风险。当然这有可能会使项目延长。 Brigette发现她自己不得不承担许多重要的任务。她可以将一些任务指派给她另外两个同事以减少工作负荷，但是她意识到这样一来，她将花更多的时间在交待工作检查工作上。因此，她调整了计划。 * * 8.检查/公布计划 检查项目计划中的质量因素 许多项目中经常出现前面完成的活动由于质量的原因需要重做的情况，这种情况将使项目失去控制