软件项目管理复习课件汇总.ppt

第1章 软件项目管理概论,项目与软件项目项目管理项目管理的范围项目管理知识体系(PMBOK)过程管理与软件项目管理的关系软件项目管理过程,项目与项目管理,项目及其特征项目群、项目与子项目软件项目软件项目要素,哪些活动是项目？,上课 野餐活动超级女声社区保安开发微软的操作系统每天的卫生保洁 神州七号飞船计划女生节的特别礼物,?,项目定义,项目是为了创造一个唯一的产品或提供一个唯一的服务而进行的临时性的努力。,给你一个浪漫的惊喜,项目的特征,明确的目标性项目之间的活动具有相关性时限性独特性（唯一性）资源成本的约束性 项目的不确定性,哪些活动是项目？,上课 野餐活动超级女声社区保安开发操作系统每天的卫生保洁 神州飞船计划女生节的特别礼物,日常运作,项目,项目群、项目与子项目,项目划分的粒度大型项目项目子项目（并行、串行）（项目）活动同族项目的特点（最高）目标的一致性任务内在的关联性,软件项目,项目成果：软件=程序+数据+文档软件项目的特点成果的逻辑（抽象）性劳动的智力密集型管理的复杂性投入的前期性易形成“先入为主”的垄断优势,软件项目的要素,客户(提出需求、提供资金、接受和评价成果)项目资源项目开发过程软件开发成果,项目无所不在，关键在于管理,生活中的项目生日聚会野餐活动集体婚礼社会中的大项目微软的操作系统开发阿波罗计划神州飞船计划,项目管理,项目管理的定义为什么要实施项目管理国内首例推行项目管理的工程项目管理的特点项目管理的制约要素软件项目管理与软件工程的关系,项目管理定义,常见：项目管理是一系列的伴随着项目的进行而采取的、以确保项目能够达到期望的结果为目的的一系列管理行为。PMI：在项目活动中应用一系列的知识、技能、工具和技术，以满足或超过相关利益者对项目的要求。,项目管理的特点,项目管理是组织管理活动的重要组成部分，并表现出如下特点：目标性平衡性动态性创造性,项目管理的特点,项目管理与运作管理的区别,项目管理的制约要素,项目管理的因素很多，项目目标的实现主要受到以下四个因素制约。,TQC三角制约关系,软件项目管理与软件工程的关系,软件工程的三部分开发过程（技术层面）管理过程（管理层面）过程改进,项目管理的要素,技术,方法,团队建设,项目管理要素,信息,包含,沟通,项目干系人,项目经理客户用户项目执行组织项目团队成员项目出资人项目业主项目承包人供货商,战略上的范围,人员(People）疑人不用，用人不疑培养人、给人以希望适当的激励机制团结、互助、向上量才而用、人尽其才问题(Problem)及早发现问题和解决问题过程(Process),战术上的范围,三角形制约关系,项目管理知识体系(PMBOK),项目的生命周期项目管理研究体系项目管理的知识与认证体系项目管理知识体系(PMBOK),项目的生命周期,任何项目都有明确的起始时间和结束时间，其过程中包含四个基本阶段。,项目的生命周期,启动阶段项目的可行性分析、立项、招投标、合同签署。计划阶段目标确定、范围定义、进度安排、资源计划、成本估计等。实施阶段实施计划、进度控制、费用控制、质量控制、变更控制、合同管理、现场管理等。结束阶段范围确认、质量验收、费用结算与审计、项目资料验收、项目交接与清算、项目审计与评估等。,项目管理研究体系,以欧洲为首的体系-国际项目管理协会(IPMA)代表各国家的项目管理研究组织（1965年-瑞士）以美国为首的体系-美国项目管理学会(PMI)以企业、大学、研究机构(如：AT&T,Bell South,Bell Core,IBM,EDS，Bell Atlantic,Us West,Citibank,ABB等参与)的专家为主（1969年-美国），完整开发了一套项目管理知识体系（PMBOK）；1984年提出项目管理认证计划(PMP)：目前全球认可程度最高的项目管理专业认证详细信息参看：或 http:/,项目管理的知识与认证体系,1991年6月中国项目管理研究委员会(PMRC)正式成立，促进了我国项目管理与国际项目管理专业领域的沟通与交流，促进了我国项目管理专业化和国际化的发展。PMRC 2001开始建立中国项目管理知识体系和资格认证标准工作。,IPMP的四个级别,PMBOK的9个知识领域,PMBOK的39个标准化模块,PMBOK的5个标准化过程组,不关注过程,特点：同一需求，不同过程，不同质量；,关注过程,特点：不同需求，同一过程，相同质量；,过程管理与软件过程管理,过程管理就是对过程进行管理，目的是要让过程能够被共享、复用，并得到持续的改进。软件过程管理就是要注重循序渐进地积累，积累项目中的各个环节的实践经验和项目管理的实践经验，改善和优化软件管理过程。,强调软件开发过程的可模式化、可成长性、可共享性,软件项目管理过程,项目初始确定“做什么？、达到什么目标？”项目计划编制计划，确定“怎么做？”项目执行与控制具体实施、实时监控项目结束认定成果、项目总结,软件项目管理中的常见问题,需求不明确，变化比较多；工作量估计过低；项目团队水平不足；开发计划不充分；项目经理的管理能力不足；,软件项目管理的成功原则,平衡原则注意“需求、资源、工期、质量”四要素的平衡；切记“80/20”原则；分解原则降低难度、减少风险、下放权力、发挥能动；实时控制原则微软的“每日构建”出成效；简单有效原则“没有完美的管理，只有有效的管理”；坚持“密而不紧、疏而不漏”原则；规模控制原则坚持“兵精将寡”原则;,第2章 软件项目初始过程,项目立项合同项目内部项目授权项目初始项目范围案例分析,项目立项,主要内容项目目的及必要性项目的可行性分析项目定义、方案设计项目的实施准备主要工作成立调研小组开展专项论证资金预算准备成立项目协调机构招标、投标、评标、定标签署项目合同,项目立项,项目实施方案自行开发购置软件产品项目整体外包（定制）决策依据项目实施成本（人财物）项目维护成本系统扩展性升级成本系统运行时间（生命周期）系统的独立性或行政约束项目的规模与组织的性质,第2章 软件项目初始过程,项目立项合同项目内部项目授权项目初始项目范围案例分析,合同项目,主要概念甲方：项目的投资方、项目成果的接收方乙方：项目的承接方、项目成果的提供方合同：用以约定甲乙双方在项目实施过程中享有的权利和 应该承担的义务的、具有法律约束力的协议的总和。甲方初始过程招标书定义乙方选择合同签署,招标书主要内容技术说明商务说明投标说明投标书的评估标准（一般包含）,合同项目,招标书定义过程,招标书内容与格式见教材P20,招标方式公开招标有限招标多方洽谈直接谈判,合同项目,乙方选择,一般分初评、细评两个阶段,合同项目,合同签署,合同项目,软件项目合同的主要条款项目的内容、范围及要求项目的技术指标及采用的标准体系项目的开发计划项目的付款计划与方式甲乙双方的责任项目技术、商业情报的保密项目的范围变更处理项目成果归属项目验收的标准与方式项目风险承担项目违约与合同纠纷处理合同的有效期合同的附件说明(含术语解释）其他（培训、维护等）,合同项目,乙方初始过程项目分析投标、竞标合同签署项目分析,合同项目,投标、竞标,合同项目,软件项目竞标决策须关注的要点技术要求完成时间经济效益风险分析,合同签署须注意的重点问题明确规定项目实施的有效范围合同的付款方式、时间范围变更及违约处理系统验收标准与方式维护期约定及后期费用标准,第2章 软件项目初始过程,项目立项合同项目内部项目授权项目初始项目范围案例分析,内部项目,内部项目交由组织内部的开发部门负责实施，不需要招投标过程；内部项目实施的核心是确定任务范围和与相关各方进行有效的配合；为了约定开发组的权益与责任，往往也需要签署具有内部处罚约束力的协议，但一般没有法定的特别的商业合同约束力；内部项目协议的范围、技术、计划、验收标准与方式、报酬等条款跟商业项目合同基本类似。,第2章 软件项目初始过程,项目立项合同项目内部项目授权项目初始项目范围案例分析,项目授权,软件项目的生命周期,组建项目团队项目授权项目组制度建立,项目授权,项目章程项目执行组织高层批准的确认项目存在、有效的书面文件。主要内容项目名称项目发起人及联系方式项目经理及联系方式项目目标项目背景及基本业务情况介绍项目成果定义项目团队工作的一般性描述项目的基本时间计划项目资源与预算项目组成员、外围协作部门或组织说明,IT升级项目的项目章程P25,项目授权,项目经理的责任编制开发计划组织项目实施跟踪项目的运行及纠偏控制项目经理的权利项目组内重大问题的决策权项目组成员的挑选权项目资源获取与分配权,项目授权,项目经理的能力要求,软件公司的岗位设置(补充),项目经理 开发经理 需求调研员 系统分析员 架构设计师 系统设计师 模块设计师 程序员 测试经理,测试工程师 测试员 实施经理 实施工程师 SQA经理 SQA工程师配置管理工程师 配置管理员 美工,岗位：项目经理,主要职责组织制定项目的总体计划和阶段计划；协调项目组资源和内部工作关系，安排项目组成员工作；跟踪、检查项目组成员工作质量；为保障项目正常运作，与客户、项目组成员之间进行必要的沟通；负责控制项目，保证项目在预算成本范围内按规定的质量和进度达到项目目标。,岗位：开发经理,主要职责负责制定从需求分析开始到系统测试前的开发计划；在开发计划的约束下，协调项目组相关资源，完成系统分析、架构设计、系统设计、模块设计、代码实现、单元测试和集成测试工作；在项目开发阶段，跟踪、检查项目组成员的工作质量；负责重点代码检查和单元测试；负责编写集成测试用例和集成测试脚本，负责组织相关人员执行集成测试并提交集成测试报告；负责编写系统管理手册和安装手册。,岗位：需求调研员,主要职责根据需求调研计划进行需求调研；收集整理客户需求，负责编写用户需求说明书；负责解决用户需求说明书被评审后发现的问题；就用户需求说明书的内容与项目组、用户达成一致并得到用户的确认。,岗位：系统分析员,主要职责深入分析和归纳用户需求，总结翻译出系统需求；负责将系统需求整理成软件需求规格说明书；负责解决软件需求规格说明书被评审后发现的问题；必要时负责向架构设计师或系统设计师解释系统需求。,岗位：架构设计师,主要职责：深度剖析系统需求，抽象出应用系统架构模型，确定应用系统实现模式；利用当前先进、成熟的计算机应用技术，负责设计和实现稳健、实用、灵活、高效的应用系统（技术）架构；指导项目组相关人员了解并灵活使用（技术）架构；协助测试人员进行系统架构测试。,岗位：系统设计师,主要职责深入分析系统需求，剖析出界面层、业务层和数据层应用模块；针对项目选定的（技术）架构，负责完成应用系统的概要设计和详细设计；负责完成应用系统的数据库逻辑设计和物理设计；指导项目组相关人员完成模块设计；协助编写集成测试用例和集成测试脚本。,岗位：模块设计师,主要职责在系统设计师的指导下，负责进行模块设计（包括功能界面布局设计和人机交互界面设计）和编写设计文档；在系统设计师的指导下，负责编写集成测试用例和集成测试脚本；负责完成应用系统的集成测试并编写集成测试报告；指导程序员根据模块设计进行代码实现。,岗位：程序员,主要职责在模块设计师指导下，根据模块设计进行代码实现；编写单元测试用例和单元测试脚本；负责执行代码走读和单元测试，记录单元测试结果；执行集成测试。,岗位：测试经理,主要职责独立编写测试计划；独立编写测试用例；安排和指导测试工程师/测试员的工作；协调测试团队内部的工作以及与开发团队之间的工作。,岗位：测试工程师,主要职责在测试经理的安排和指导下，编写测试计划；在测试经理的安排和指导下，编写测试用例；在测试经理的安排下，独立完成“执行测试”的工作；在测试经理的指导下，掌握较深层次的测试方法、测试技术和较复杂的业务流程。,岗位：测试员,主要职责在测试经理的安排和指导下，编写测试用例；在测试经理的安排和指导下，完成“执行测试”的工作；在测试经理的指导下，基本完成测试计划的编写工作；在测试经理帮带下，掌握基本的测试方法、测试技术和业务流程。,岗位：实施经理,主要职责：负责制定项目实施计划；在项目实施计划的约束下，协调项目组相关资源，完成系统实施相关工作（包括系统安装、用户培训、系统上线、系统试运行等）；在项目实施阶段，跟踪、检查实施人员的工作质量；负责编写用户手册、操作手册和相关培训教材；负责协助用户进行“用户确认测试”和编写确认测试报告。,岗位：实施工程师,主要职责：在实施经理安排和指导下，执行项目用户现场实施任务；参与编写用户手册、操作手册和相关培训教材；参与进行“用户确认测试”和编写确认测试报告。,岗位：SQA 经理,主要职责负责被分派项目的质量审计；对工程部门进行CMM 过程培训和指导；负责被分派的过程改进工作；负责过程工具的研究、推广与维护。,岗位：SQA 工程师,主要职责：负责被分派项目的质量审计；对工程部门进行CMM 过程培训和指导；负责过程工具的研究、推广与维护，负责过程数据库维护工作。,岗位：配置管理工程师,主要职责：负责部门项目配置管理库的管理并承担大型项目的配置管理活动；指导配置管理员编写配置管理计划并实施配置管理活动；为部门各项目提供SCM 理论和相关工具的培训，并提供技术支持；对配置管理流程进行监督、跟踪，并提供优化改进建议。,岗位：配置管理员,主要职责据软件项目计划制定配置管理计划；在配置管理计划约束下，负责配置项、基线的生成、变更和相关管理；为项目组提供SCM 理论和相关工具的培训，并提供技术支持。,岗位：美工,主要职责负责完成项目经理安排的功能界面设计。,第2章 软件项目初始过程,项目立项合同项目内部项目授权项目初始项目范围案例分析,初始项目范围,初始的项目范围说明书（初始的需求说明书）项目需要完成的工作项目需要提交的成果需求规格说明书的编写基础,第2章 软件项目初始过程,项目立项合同项目内部项目授权项目初始项目范围案例分析,案例讨论与分析,案例1：校务通系统案例2：投标人资格案例3：评标标准案例4：非招标采购案例5：合同履行,引论,明确项目应该包括什么及不包括什么等基本需求内容。,甲乙方达成需求共识的重要手段。,范围管理包含需求管理。,第2章 范围计划,关于软件需求需求管理过程编写需求规格的方法任务分解定义任务分解的方法任务分解结果的检验案例讨论与讲评,关于软件需求,软件需求的概念用户对软件功能和性能的要求，即用户希望软件能做什么，具有什么功能，达到什么性能或效果。软件需求的重要性项目中4060的问题与需求分析阶段的工作有关；软件项目中的返工开销占总费用的40，而其中的7080因需求分析缺陷导致；失败的软件项目中，80因需求分析不明确产生。,软件项目失败的原因分析,关于软件需求,软件需求的层次业务需求（高层次的目标需求）用户需求（软件产品需要完成的任务）功能需求（软件需要具备的功能）,隐性需求,隐性需求,需求管理过程,需求工程,需求获取,需要获取的信息客户部门的现有组织架构现有的软硬件环境与运行系统现有的业务流程业务人员及用户类型主要活动访谈、提问与调查收集现有业务处理档案材料需求专题讨论会,需求获取,需求获取时应该注意的问题识别真正的客户（影响力与重要性排序）正确理解用户的需求具备较强的忍耐力和清晰的思维说服和教育客户,需求管理过程,需求工程,需求分析,需求分析又称需求建模，为最终用户所需要的系统建立一个概念模型，是对需求的抽象描述。解决目标系统“做什么？”的问题，与技术无关。,需求分析,需求分析的主要活动以图形表示的方式描述系统的整体结构，包括系统的边界和接口；通过原型、页面流或其他方式向用户提供可视化界面，征求用户的意见，确定需求优先级；以模型描述系统的功能项、数据实体、外部实体、实体之间的关系与状态转换等方面的内容，建立需求模型，编写数据字典。,需求管理过程,需求工程,需求规格说明,需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。,需求规格说明,软件需求规格模板参考引言系统定义 应用环境功能规格 性能需求产品提交实现约束质量描述其它签字确认,教材P49-50,需求规格说明,经验之谈错误理解：粗线条描述需求，细节在开发过程中逐步完善。正确做法：全面且尽可能细致地与客户讨论项目的应用背景、功能要求、性能要求、操作界面要求、与其他软件的接口要求、以及对项目进行评估的各种评价标准。,需求管理过程,需求工程,需求验证,验证的内容需求是正确的吗？需求是一致的吗？需求是完全的吗？需求是实际可行的吗？需求是必要的吗？需求是可检验的吗？需求是可跟踪的吗？签字确认,需求管理过程,需求工程,需求总在变化,只要不变的目标尽可能满足用户合理的、有效益的需求，在项目约束条件下追求用户满意度的最大化。没有不变的需求需求一成不变的软件项目是不存在的。需求变更的原因需求分析不完整、存在二义性、范围不清晰用户改变需求没有良好的软件结构适应变化,需求总在变化,需求变更时间与所付代价关系图,需求变更管理,主要内容建立需求基线确定需求变更控制过程建立变更控制委员会(SCCB)进行需求变更影响评估分析跟踪所有受需求变更影响的工作产品建立需求基准版本和需求控制版本文档维护需求变更的历史记录跟踪每项需求的状态衡量需求稳定性,需求变更管理,需求变更处理流程 需求变更是不可避免的，但必须有套规范的处理流程，并按照“提出变更、变更评估、实施变更、变更检验”的操作步骤来进行。,需求变更管理,需求变更管理,需求变更申请表,需求变更管理,需求变更影响分析,任务分解定义,任务分解面向可交付成果,将一个项目由粗到细地分解为更多的工作细目或者子项目，使项目的可控管理单元变得更小。任务分解的结果 WBS（Work Breakdown Structure）,任务分解定义,WBS的分解策略按系统功能按任务类型,按照系统功能分解,实例：学生成绩管理系统的WBS,成绩管理系统,学生成绩管理系统需求分析,实例：学生成绩管理系统的WBS,按照任务类型分解,任务分解定义,WBS的分解策略按系统功能按任务类型WBS的表示形式图表类型清单类型,图表形式,实例：学生成绩管理系统的WBS,成绩管理系统,实例：学生成绩管理系统的WBS,1 课程管理1.1课程增加1.2课程修改1.3课程查询2成绩管理2.1成绩录入2.2成绩查询 2.2.1 课程成绩查询 2.2.2 个人成绩查询 2.2.3 班级成绩查询2.3 成绩打印3,清单形式,任务分解定义,WBS的分解策略按系统功能按任务类型WBS的表示形式图表类型清单类型说明也有直接在WBS中确定任务责任人的情况，即将WBS和OBS（组织分解结构）结合起来，编制综合的WBS。,任务分解定义,WBS与OBS（组织分解结构）,任务分解定义,任务分解定义,WBS字典,任务分解的方法,模版参照法,任务分解的方法,类比法自顶向下法自下而上法,任务分解结果的检验,检验WBS分解结果的标准最底层的要素是否是实现目标的充分必要条件；每个要素是否清晰完整定义；最底层要素是否有重复的；最底层要素是否可以进行成本估算和进度安排。,任务分解结果的检验,WBS分解的注意事项任务分解的规模和数量因项目而异，确保最低层是可控的和可管理的，推荐分解到40小时的任务比较恰当；每个任务必须确定一个定义明确的提交物；任务分解层数最好不要超过7层；,案例讨论与分析,案例1：校务通系统案例2：范围定义 案例3：工作要点 案例4：范围确认,引论,项目成本与开发时限构成项目进度计划的基本红线；项目进度计划涉及到项目的活动编排和资源计划制定；合理的进度计划能有效提高软件项目资源利用效率。,引论,进度管理的重要性按时完成项目是项目经理最大的挑战之一；合理的并行性活动安排是项目按期完成的重要保证,引论,软件项目进度管理过程任务(活动)定义(Activity definition)任务(活动)排序(Activity sequencing)任务(活动)历时估计(Activity duration estimating)制定进度计划(Schedule development)进度控制(Schedule control)-项目跟踪,第3章 软件项目进度管理,任务（活动）定义任务（活动）排序进度管理工具任务资源估计项目历时估计进度计划制定案例分析,任务(活动)定义,将项目工作分解为一个个易管理、可控制、责任明确的活动或任务，并列出活动清单的过程。,成果：项目活动清单,任务(活动)排序,确定项目中各项任务(活动)的先后顺序及其之间的逻辑关系。,任务(活动)之间相互依赖关系依据强制性(先后)依赖关系：项目活动之间的固有的、不可改变性的依赖关系（也称内在相关性）软逻辑关系：由项目管理人员（人为）确定的项目活动之间的依赖关系（也称指定性相关）外部依赖关系：项目活动与非项目活动之间的依赖关系,任务(活动)排序,任务(活动)之间的逻辑关系,进度管理工具,甘特图网络图里程碑图资源图,甘特图（Gantt Chart),甘特图表示项目各活动开始时间与结束时间、明确体现项目活动工期与进度计划的图形表示方法。表示方法水平线段表示阶段任务线段的起点和终点分别对应于任务的开始时间和结束时间；线段的长度表示完成任务所需的时间；棒状图三角图（上三角：开始；下三角：结束）,甘特图（Gantt Chart),开始时间,结束时间,网络图,前导图法(PDM-Precedence Diagramming Method）箭线法(ADM-Arrow Diagramming Method),网络图,说明PDM中的结点表示活动，箭线表示顺序。ADM中的结点表示时间点，箭线表示活动。ADM中的一对结点间只能有一条箭线。,不允许,1,3,系统规划,2,市场调查,虚活动:用虚线箭头表示-不消耗时间,网络图,例题：已知某软件需求分析项目活动及紧前活动序列如下表，试绘制其网络图。,网络图,PDM网络图,网络图,双号网络图？,1,2,3,4,5,6,7,8,9,10,里程碑图,用于显示项目进展中的重大工作完成的时间节点。,里程碑与活动的区别活动是需要消耗资源的里程碑仅仅表示事件的标记，不需资源,资源图,显示项目的进展中的资源需求情况,任务资源估计,资源类型人力资源设备资源其他辅助资源需要注意的问题资源类型资源来源与限制资源成本,项目历时估计,需要考虑的因素实际工作时间有效工作时间连续工作时间项目人员规模生产率人员级别历史项目,项目历时估计方法,定额估计法经验导出模型工程评估评审技术专家估计法类推估计法模拟估计法基于承诺的进度估计法Jones的一阶估计准则管理预留,应用PERT估算项目历时,计划评审技术(Program Evaluation and Review Technique PERT)利用网络顺序图逻辑关系和加权历时估算来计算项目历时的技术。当估算项目中某项单独的活动，存在很大的不确定性时采用。,应用PERT估算项目历时,它是基于对某项任务的乐观，悲观以及最可能的概率时间估计，假设标准方差是时间需求范围的1/6，且活动所需时间的概率分布服从正态分布，则期望时间E的计算公式E=(O+4m+P)/6O是最小估算值:乐观(Optimistic)P是最大估算值:悲观(Pessimistic)M是最大可能估算(Most Likely),应用PERT估算项目历时,为了把握项目中每个活动的不确定性程度，可以利用方差计算公式计算出其活动工期的方差与标准差，公式如下：标准差=(P-O)/6方差 2=(P-O)/6 2O是最小估算值:乐观(Optimistic)P是最大估算值:悲观(Pessimistic)M是最大可能估算(Most Likely),PERT应用举例,例题：已知某软件需求分析项目活动的乐观、可能、悲观时间如下表，试计算其各活动的工期估计值。,PERT应用举例,2（P-O）/62,应用PERT估算项目历时,用PERT技术评估存在多个活动的一条路径,期望值E=E1+E2+.En方差2=(1)2+(2)2+.+(n)2标准差=(1)2+(2)2+.+(n)2)1/2,应用PERT估算项目历时,设有三活动J、K、L，求其总工期及标准差。,标准差与保证率,根据概率理论，符合正态分布的取值区间与可信度存在以下关系：,标准差与保证率,项目在14.57内天完成的概率是多少？,标准差与保证率,-2,+2,-3,-1,+1,+3,68.3%,95.5%,99.7%,E,T=E+=13.5+1.07=14.57,P=50%+34.2%=84.2%,68.3/2%=34.2%,50%,进度计划编制,关键路径法时间压缩法资源平衡关键链法,关键路径法(CPM：Critical Path Method),方法的核心内容根据网络图逻辑关系计算和确定每一个活动的最早、最迟开始日期和最早、最迟完成日期;计算每个活动的浮动时间，求关键路径。关键路径的特征关键路径是由浮动时间为0的活动(关键活动)组成的路径，是网络图中最长的路径;关键路径上的任何活动延迟，都会导致整个项目完成时间的延迟。,关键路径（CP:Critical Path）,穷举法求CP,路径1：1、2、3、4、6路径2：1、2、3、5、6,路径长度=A+B+C+E=2+5+2+1=10,路径长度=A+B+D+F=2+5+7+2=15,正逆推法求CP,关键路径（CP:Critical Path）,正逆推法求CP正推过程(Forward pass)逆推过程(Backward pass)求关键活动(浮动时间为0的活动),ES,关键路径（CP:Critical Path）,正推过程(Forward pass)首先建立项目的开始时间(网络图中首个活动ES:项目的开始时间)从左到右，从上到下进行任务编排,求出每一个活动的ES与EF(EF=ES+活动估计工期）当一个后置活动有多个前置活动时，选择其中最大的最早完成时间作为后置活动的最早开始时间.公式:ES(S)=MaxEF(Pi)Pi:活动S的所有直接前置活动,关键路径（CP:Critical Path）,实例:设开始时间为1,正推过程图示.,1,1,8,8,14,14,17,4,4,7,4,6,7,10,17,19,关键路径（CP:Critical Path）,逆推过程(Backward pass)首先建立项目的结束时间(网络图中最后一个活动的最晚结束时间)从右到左，从上到下进行计算,求出每一个活动的LF和LS(LS=LF-活动的估计工期)当一个前置活动有多个后置活动时，选择其中最小的最晚开始时间作为前置活动的最晚完成时间.公式:LF(P)=MinLS(Si)Si:活动P的所有直接后置活动,关键路径（CP:Critical Path）,实例:设开始时间为1,逆推过程图示.,17,19,17,14,14,8,8,1,17,14,14,11,14,12,11,8,关键路径（CP:Critical Path）,实例:设开始时间为1,求关键活动.,关键路径:A-C-G-H,路径长度:19-1=18,课堂练习,作为项目经理，你需要给一个软件项目做计划安排，经过任务分解后得到任务A，B，C，D，E，F，G，假设各个任务之间没有滞后和超前，下图是这个项目的PDM网络图。通过历时估计已经估算出每个任务的工期，现已标识在PDM网络图上。假设项目的最早开工日期是第天，请计算每个任务的最早开始时间，最晚开始时间，最早完成时间，最晚完成时间，同时确定关键路径，并计算关键路径的长度，计算任务F的自由浮动和总浮动.,课堂练习,确定以及的长度？,课堂练习-答案,4,4,10,4,12,12,19,19,24,12,20,24,27,27,24,24,24,16,19,19,12,12,6,12,4,4,0,CP:A-E-C-D-G,Pathlength:27,时间压缩法,实质时间压缩法是在不改变项目范围的前提下缩短项目工期的数学分析方法。主要措施应急法-赶工（Crash）平行作业法-快速跟进（Fast tracking:搭接）,时间压缩法,应急法-赶工（Crash）在不改变网络图与活动的前提下，通过压缩某一个或者多个活动的工期来达到缩短整个项目工期的目的；一般选择压缩关键路经上的关键活动的工期。进度压缩成本在工期的可压缩范围内，活动工期 的压缩都将导致活动成本的增加；一定的可压缩区间内，可假设进度 的压缩与成本的增加成正比。单位压缩成本=,时间压缩法,例如：活动A:正常进度7周,成本5万；压缩到5周的成本是6.2万；则：进度单位压缩成本=(6.2-5)/(7-5)=6000元/周若：压缩到6周 成本是：5.6万,时间压缩法,例题：请问如果将工期压缩到17，16，15周时应该 压缩的活动和最后的成本？,总工期：18周；总成本20万,时间压缩法,7+9=16,10+8=18,C,C、D,20+0.5,20.5,时间压缩法,7+9=16,10+8=18,D,C、D,20.5+0.6,21.1,时间压缩法,7+9=16,10+8=18,A、D,A、B、D,21.1+0.6+0.6,22.3,时间压缩法,进度压缩因子理论Charles Symons(1991)提出；进度与成本上涨并不是总成正比关系，当进度压缩到正常范围以外，其成本将迅速上涨；任何软件项目都存在着一个可能的最短进度，无论如何调整，该进度都是不可能再压缩和突破的，越接近该进度值，项目成本将呈指数增加；,时间压缩法,例如：初始进度估算是12月，初始工作量估算是78人月，如果进度压缩到10月。则：进度压缩因子=10/12=0.83，则：进度压缩后工作量=78/0.83=94人月,时间压缩法,平行作业法-快速跟进（Fast tracking:搭接）实质改变活动间的逻辑关系，并行开展某些活动。,资源平衡法,通过调整进度计划，形成平稳连续的资源需求资源闲置时间最小化，提高资源效率；维持工期不变，使资源强度平衡、峰值最小；,资源平衡法,案例讨论,案例1：校务系统案例2：时间管理,概述,软件项目的范围决定软件的规模；软件的规模决定项目的成本与开发时限；项目成本与开发时限构成项目进度计划的基本红线；项目进度计划涉及到项目的活动编排和资源计划制定；合理的项目计划能有效提高软件项目资源利用效率。,概述,无计划情况下的资源利用分布,概述,有计划情况下的资源利用分布,概述,项目时间管理原则时间管理技巧进度管理的基本概念软件项目进度管理重要性与过程,概述,项目时间管理原则区分活动的重要与紧急的关系，把握平衡适当运用Pareto(20/80)原则，关注“关键性活动”合理的预算(墨菲第2定律：做比想要难，凡事留余地！)有限反应(切合实际、把握原则、轻重有度)果断决策(有效即可行，只求最好，不求更好)大胆、完整的授权(疑人不用，用人不疑，责权利结合)例外管理(抓大放小、忌讳面面俱到)效能与效率(有效的活动比有效的方法更重要)活动与效果(重效果、轻细节、活动过程要规范),概述,时间管理技巧每日计划预料分析时间最后时限上交问题合并反馈计划躲避可见性习惯,概述,进度管理的基本概念进度：对执行的活动和里程碑制定的工作计划日期表。进度管理：为确保项目按期完成所需要的管理过程。进度管理目的：在给定的限制条件下，以最短的时间、最低的成本、最小的风险、按质按量完成项目目标规定的任务。总进度确定依据成果的交付日期依据可利用的资源估算的项目开发时限,浮动时间(Float),定义一个活动在不影响其它活动或者项目完成的情况下可以延迟的时间量。自由浮动（Free Float）在不影响后置活动最早开始时间的情况下,本活动可以延迟的时间。总浮动（Total Float）在不影响项目最早完成时间的情况下,本活动可以延迟的时间。,浮动时间(Float),例如：,浮动时间(Float),进度时间参数,B:10,A:ES=0,EF=100LS=0,LF=100,B:ES=0,EF=10LF=100,LS=90,公式:EF=ES+duration LS=LF-duration TF=LS-ES=LF-EF FF(P)=ES(S)-EF(P),TF=LS-ES=90TF=LF-EF=90,浮动时间(Float),任务滞后Lag,浮动时间(Float),同时浮动,B:ES=0,EF=10LS=80,LF=90TF=LS-ES=80FF=0,C:ES=15,EF=20LS=95,LF=100TF=LS-ES=80,浮动时间(Float),同时浮动时间B可以浮动的时间：80*10/15=53C可以浮动的时间：80*5/15=27,问题：如果由于B，C分别延误80天，造成100万损失，应该如何赔偿？,浮动时间(Float),同时浮动赔偿B赔偿：100（1-10/15）C赔偿：100（1-5/15）,时间压缩法,任务超前(Lead),A完成之前3天B开始,作用：1）解决任务的搭接 2）对任务可以进行合理的拆分 3）缩短项目工期,时间压缩法,任务拆分,项目计划制定,软件项目计划的要素项目目标WBS规模估算成本(工作量)估算进度安排,项目计划制定,软件项目计划周期,项目计划制定,软件项目计划的内容为什么？目标(范围、费用、进度、质量)做什么？任务分解(活动,要求)谁负责？资源分配(组织、角色、分工)什么时间？进度安排(人、时、事不能有冲突),项目计划制定,进度安排过程与方法根据项目总体进度目标，编制人力资源计划；比较所需资源与实有资源，确定各阶段的初步进度，进而拟定整个项目的初步进度；初步进度评审，确保进度的有效性和可行性，否则，需返回上面步骤，进行计划和进度调整。,项目进度监控,项目进度控制的前提项目进度计划已取得项目干系人的共识；项目监控中能充分掌握项目进展的各种数据；项目监控目标、任务、监控人员及岗位职责明确；项目进度监控的方法、程序及统计、预测工具已经具备；项目进度信息的报告、沟通、反馈及信息的管理制度已经建立。,项目进度监控,项目进度控制工作的主要内容建立进度协调、沟通机制(定期召开进度协调例会)；按照已制定的程序定期获得项目的进度数据；比较实际进度与计划的偏差，分析偏差产生的原因；有针对性排除进度偏差形成的主要干扰因素，调整原有的进度计划,采取必要可行的补救措施。,