《{项目管理项目报告}第5讲项目进度安排》由会员分享，可在线阅读，更多相关《{项目管理项目报告}第5讲项目进度安排（55页珍藏版）》请在金锄头文库上搜索。
1、Software Project Management,第5 讲 项目进度安排,主讲：张纲强,基本概念,主要内容,项目进度安排,定义任务网络,进度安排,挣值分析,基本概念,基本概念,虽然软件延期交付的原因很多，但是大多数都可以追溯到下面列出的一个或多个根本原因上： 不切实际的项目结束期限，由软件工程小组以外的某个人所制定,并强加给软件工程小组内的管理者和项目开发者。 客户需求发生变更，而这种变更没有在项目变更进度表上预先安排。 对完成该工作所需的工作量和/或资源数量估计不足。 在项目开始时，没有考虑可预测的和/或不可预测的风险。 出现了事先无法预计的技术困难。 出现了事先无法预计的人力困难。
2、由于项目团队成员之间的交流不畅而导致的延期。 项目管理者未能发现进度拖后，也未能采取措施解决这一问题,4,基本概念,在软件行业中，人们对过于乐观的(即“不切实际的”)项目结束期限已经司空见惯。从设定项目结束期限的人的角度来看，有时候这样的项目结束期限是合理的，但是常识告诉我们，合理与否还必须由完成工作的人员来判断。 不妨举例说明，假定一个软件开发小组的任务是构造一个医疗诊断仪器的实时控制器，该控制器需要在9个月之内推向市场。在进行了仔细的估算和风险分析之后，软件项目管理人员得到的结论是在现有人员条件下，需要14个月的时间才能完成这一软件。这位项目管理者下一步该怎么办？闯进客户的办公室(这里的客
3、户非常可能是市场或销售人员)并要求修改交付日期似乎不太现实。外部市场压力决定了交付日期，届时必须发布产品。而(从事业前途的角度出发)拒绝这一项目同样是鲁莽的。那么应该怎么办呢？,5,基本概念,在这种情况下，推荐以下的处理步骤： 按照以往项目的历史数据进行详细的估算。确定项目的估算工作量和工期。 采用增量过程模型，制定一个软件开发策略，以保证能够在规定的交付日期提供主要功能，而将其他功能的实现推到以后。然后将这一计划做成文档。 与客户会谈并(用详细估算结果)来解释为什么规定的交付日期是不现实的，一定要指出所有这些估算都是基于以往的项目实践，而且一定要指出为了在目前规定的交付期限完成项目，与以往相
4、比在工作效率上必须提高的百分比 将增量开发策略作为可选计划提交给客户,6,项目进度安排,项目进度安排,软件项目进度安排 是一种活动，它通过将工作量分配给特定的软件工程任务，从而将所估算的工作量分配到计划的项目工期内。但要注意的是，进度是随着时间的改变而不断演化的。在项目计划的早期，首先建立一个宏观进度表，该进度表标识出所有主要的软件工程活动和这些活动影响到的产品功能。随着项目的进展，宏观进度表中的每个条目都被精化成一个“详细进度表”。于是(完成一个活动所必须实现的)特定软件任务被标识出来，同时也进行了进度安排。 可以从两个不同的角度来讨论软件工程项目的进度安排。第一个视角，计算机系统的最终发布
5、日期已经确定(而且不能更改)，软件开发组织必须将工作量分布在预先确定的时间框架内。第二个视角，假定已知大致的时间界限，但是最终发布日期是由软件开发组自行确定，工作量以一种能够最好地利用资源的方式进行分配，且在对软件进行仔细分析之后才决定最终发布日期。但不幸的是，第一种情况发生的频率远远高于第二种情况。,8,项目进度安排,划分。必须将项目划分成多个可以管理的活动、动作和任务。为了实现项目的划分，产品和过程都需要进行分解。 相互依赖性。划分后的各个活动、动作或任务之间的相互依赖关系必须是明确的。有些任务必须按顺序出现，而有些任务则可以并发进行。有些活动或动作只有在其他活动产生的工作产品完成后才能够
6、开始，而有些则可以独立进行。 时间分配。每个安排了进度计划的任务必须分配一定数量的工作单位（例如，若干人日的工作量）。此外，还必须为每个任务指定开始日期和完成日期，任务的开始日期和完成日期取决于任务之间的相互依赖性及工作方式是全职还是兼职。,9,项目进度安排：基本原则,项目进度安排,工作量确认。每个项目都有预定数量的人员参与。在进行时间分配时，项目管理人员必须确保在任意时段中分配的人员数量不会超过项目团队中的总人员数量。例如，某项目分配了3名软件工作师（例如，每天可分配的工作量为3人日）。在某一天中，需要完成7项并发的任务，每个任务需要0.50人日的工作量，在这种情况下，所分配的工作量就大于可
7、供分配的工作量。 确定责任。安排了进度计划的每个任务都应该指定特定的团队成员来负责。 明确结果。安排了进度计划的每个任务都应该有一个明确的输出结果。对于软件项目而言，输出结果通常是一个工作产品（例如一个模块的设计）或某个工作产品的一部分。通常可将多个工作产品组合成“可交付产品”。 确定里程碑。每个任务或任务组都应该与一个项目里程相关联。当一个或多个工作产品经过质量评审并且得到认可时，标志着一个里程碑的完成。,10,项目进度安排：基本原则,项目进度安排,对于小型软件开发项目，只需一个人就可以完成需求分析、设计、编码和测试。随着项目规模的增长，必须会有更多的人员参与。（不可能奢望一个人工作十年来完
8、成10人 年的工作量） 在项目后期增加人手通常会对项目产生破坏性的影响，其结果是使进度进一步拖延。后期增加的人员必须学习这一系统，而培训他们的人员正是一直在工作着的那些人，当他们进行教学时，就不能完成任何工作，从而使项目进一步拖延。 除去学习系统所需的时间之外，新加入人员将会增加人员之间交流的路径数量和整个项目中交流的复杂度。虽然交流对于一个成功的软件开发项目而言绝对是必不可少的。但是每增加一条新的交流路径就会增加额外的工作量，从而需要更多的时间。 多年以来的经验数据和理论分析都表明项目进度是具有弹性的。即在一定程度上可以缩短项目交付日期（通过增加额外资源），也可以拖延项目交付日期（减少资源数
9、量）。,11,项目进度安排：人员与工作量之间的关系,项目进度安排,PNR（Putnam-Norden-Rayleigh）曲线表明了一个软件项目中所投入的工作量与交付时间的关系。项目工作量和交付时间的函数关系曲线如图51所示。图中的to表示项目最低交付成本所需的最少时间（即花费工作量最少的项目交付时间），而to左边（即当我们想提前交付时）的曲线是非线性上升的。,12,项目进度安排：人员与工作量之间的关系,图51 工作量和交付时间的关系,项目进度安排,举一个例子 假设一个软件项目团队根据进度安排和现有的人员配置，估算所需要的工作量应为Ed，正常的交付时间应为td。虽然可以提前交付，但曲线在td的左
10、侧急剧上升。事实上，PNR曲线不仅说明了项目的交付时间不能少于0.75td，如果想更少，项目会进入“不可能的区域”，并面临着很高的失败风险；还说明了最低成本的交付时间to应该满足to=2td，即拖延项目交付可以明显降低成本，当然，这里的成本必须将与延期相关的营销成本排除在外。,13,项目进度安排：人员与工作量之间的关系,项目进度安排,14,项目进度安排：人员与工作量之间的关系,项目进度安排,15,项目进度安排：人员与工作量之间的关系,项目进度安排,16,项目进度安排：人员与工作量之间的关系,项目进度安排,在之前学习中讨论的各种软件项目估算技术最终都归结为对完成软件开发所需工作单位（如人 月）的
11、估算。软件过程中的工作量分配通常采用402040法则。总体工作量的40%分配给前期的分析和设计，40%的用于后期测试。因此，你可以推断出编码工作（20%的工作量）是次要的。 这种工作量分配法只能作为指导原则。各个项目的特点决定了其工作量如何分配。用于项目计划的工作量很少超过2%3%，除非提交给组织的项目费用极高且具有高风险。需求分析大约占用10%25%的工作量，用于分析或原型开发的工作量应该与项目规模和复杂度成正比增长。通常有20%25%的工作量用于软件设计，用于设计评审和随之而来的迭代开发也必须考虑。 因为在软件设计时投入相当的工作量，随后的编码工作就变得相对简单。总体工作量的15%20%就
12、可以完成这一工作。测试和随之而来的调试工作将占用30%40%的软件开发工作量。软件的重要性决定了所需测试工作的分量，如是果软件系统是人命相关的，就应该考虑分配更高的测试工作量比例。,17,项目进度安排：工作量分配,为软件项目定义任务集,定义任务集,我们已经学习了多种不同的过程模型。无论一个软件团队选择的是线性顺序模型、增量模型、演化模型，或它们的某种变型，过程模型都是由一个任务集组成的，这些任务集使得软件团队能够定义、开发和最终维护计算机软件。 没有能普遍适用于所有软件项目的任务集合。适用于大型复杂系统的任务集可能对于小型且相对简单的项目而言就过于复杂。因此一个有效的软件过程应该定义一组任务集
13、来满足不同类型项目的要求。 一个任务集包括软件工程工作任务、里程碑，以及为完成某个特定项目就必须完成的工作产品。为获得高质量的软件产品，所选择的任务集必须提供充分的规程要求，但同时又不能让项目团队负担不必要的工作。,19,为软件项目定义任务集,定义任务集,在进行项目进度安排时，必须将任务集分布在项目时序图上。任务集应该根据软件团队所决定的项目类型和严格程序而有所不同。一般项目的类型如下： 概念开发项目：目的是为了探索某些新的业务概念或者某种新技术的应用。 新应用开发项目：根据特定的客户需求而承担的项目。 应用增强项目：对现有软件进行最终用户可见的功能、性能或界面的修改。 应用维护项目：以一种最
14、终用户不会立即察觉到的方式对现有软件进行纠错、适应或者扩展。 再工程项目：为了全部或部分重建一个现有(遗留)系统而承担的项目。,20,为软件项目定义任务集,定义任务集,每种项目类型都可以通过线性顺序、迭代或者演化等过程模型来实现。在某些情况下，项目类型可以从一种形式平滑地转换为另一种形式。例如成功的概念开发项目通常会演化为新应用开发项目，而新应用开发项目结束之后，可能又开始了一个应用增强项目。这个进程是自然的和可预测的，不论组织是采用何种过程模型都将会发生。因此，下面将要介绍的主要软件工程任务可适用于所有过程模型流程。作为一个例子，下面我们将介绍概念开发项目的主要软件工程任务。,21,任务集举
15、例,定义任务集,概念开发项目是在探索某些新技术是否可行时发起的。这种技术是否可行尚不可知，但是某个客户相信其具有潜在的利益。概念开发项目的完成需要应用以下主要任务： 确定概念范围。确定项目的整体范围 初步的概念策划。确定组织承担项目范围所涵盖的工作应具有的工作能力。 技术风险评估。评估与项目范围中将要实现的技术相关联的风险。 概念证明。证明新技术在软件环境中的生命力。 概念实现。以一种可以由客户方进行评审的方式实现概念的表示，而且当将概念销售给其他客户或管理者时能够用于“营销”目的。 客户对概念的反应。向客户索取对新技术概念的反馈，并以特定的客户应用作为目标。,22,任务集举例,定义任务集,上
16、一节中所描述的主要任务可以用来制定项目的宏观进度表。但是，必须将宏观进度表进行细化，以创建一个详细的项目进度表，细化工作始于将每个主要任务分解为一组子任务（以及梯状的工作产品和里程碑）。 作为任务分解的例子，我们考虑在上一节中讨论的“1. 确定概念范围”。任务求精可以使用大纲格式，但在这里将使用过程设计语言来说明“确定范围”这一活动的流程：,23,主要任务的求精,任务定义：任务 1 确定概念范围 1.1 确定需求、效益和潜在的客户 1.2 确定所希望的输出/控制和驱动应用程序的输入事件 开始1.2 1.2.1 FTR：评审需求的书面描述 1.2.2 导出一个客户可见的输出/输入列表 1.2.3 FTP：与客户一起评审输出/输入，并在需要时进行修改结束任务1.2.2 1.3 为每个主要功能定义功能/行为 开始1.3 1.3.1 FTP：评审在任务1.2中得到的输出/输入数据对象 1.3.2 导出功能/行为模型 1.3.3 与客户一起评审功能/行为模型，并在需要时进行修改结束任务1.3,1.4 把需要在软件中实现的技术要素分离出来 1.5 研究现有软件的可用性 1.6 确定技术可行性
