第六章整体管理、第七章范围管理--中项作业

第六章项目整体管理

1、项目整体管理的过程包括如下内容(熟练背):

(1)项目启动。制定项目章程,正式授权项目或颈剐阶段的开始。

(2)制定初步的项目范围说明书。编制一个初步的项目范围说明书,概要地描述项目的范围。

(3)制定项目管理计划。将确定、编写、集成以及拂调所有分计划,以形成整体项目管理计划。

(4)指导和管理项目的执行。执行在项强管理计划中所定义的工作以达到项目的目标。

(5)监督和控制项目。监督和控制项目的启动、计划、执行和收尾过程,以达到项目管理计划所定义的项目目标。

(6)整体变更控制。评审所有的变更请求,批准变更,控制可交付成果和组织的过程资产。

(7)项目收尾。完成项目过程中的所有活动,以正式结束一个项目或项目阶段。

以上七条对应五大过程组(第一、二条对应启动过程组;第三条对应计划过程组;第四条对应执行过程组;第五、六条对应监督、控制过程组;第七条对应收尾过程组)。

2、项目启动标志:项目立项以后,就要正式启动项目。所谓的项目启动就是以书面的、正式的形式肯定项目的成立与存在,同时以书面正式的形式为项目经理进行授权。

3、项目章程作用:项目章程是正式批准一个项目的文档,或者是批准现行项目是否进入下一阶段的文档。项目章程应当由项目组织以外的项目发起人发布,若项目为本组织开发也可由投资人发布。项目章程为项目经理使用组织资源进行项目活动提供了授权。

4、项目章程包括内容(重点记忆案例分析至少要回答七条以上才能满分):

(1)基于项目干系人的需求和期望提出的要求;(2)项目必须满足的业务要求或产品需求;    (3)项目的目的或项目立项的理由; (4)委派的项目经理及项目经理的权限级别;(5)概要的里程碑进度计划。(6)项目干系人的影响;(7)职能组织及其参与;(8)组织的、环境的和外部的假设;(9)组织的、环境的和外部的约束;(10)论证项目的业务方案,包括投资回报率; (11)概要预算。

5、项目工作说明书:项目工作说明书(sow)是对项目所要提供的产品、成果或服务的描述。对内部项目而言,项目发起者或投资人基于业务需要,或产品,或服务的需求提出工作说明书。内部的工作说明书有时也叫任务书。对外部项目而言,工作说明书作为投标文档的一部分从客户那里得到,如邀标书、投标邀请书或者合同中的一部分。

6、工作说明书需要说明如下事项(单选):(1)业务要求; (2)产品范围描述;(3)战略计划。

7、项目环境的和组织的因素(4/7/8是重点,特别是”行业数据库”容易放到“组织过程资产中的--各类数据库”中考试):(l)实施单位的企业文化和组织结构;(2)国标或行业标准;(3)现有的设施和固定资产等基础设施;(4)实施单位现有的人力资源、人员的专业和技能,人力资源管理政策如招聘和解聘的指导方针、员工绩效评估和培训记录等;(5)当时的市场状况;(6)项目干系人对风险的承受力;(7)行业数据库;(8)项目管理信息系统(可能是工具,也可能是软件,总之能帮助人们管理项目)。

8、 项目组织过程资产包含:项目实施组织的企业计划、政策方针、规程、指南和管理系统,

实施项目组织的知识和经验教训。

9、项目组织过程资产分类:(1)组织中指导工作的过程和程序;(2)组织的全部知识。①项目档案②过程测量数据库 ③经验学习系统④问题和缺陷管理数据库⑤配置管理知识库⑥财务数据库。

10、项目启动的方法、技术和工具:(1)项目管理方法:项目管理方法可以是项目管理标准,也可以不是。(2)项目管理信息系统:项目管理信息系统(Project Management Information System,PMIS)是组织内可用的系统化的自动化工具集。(3)专家判断:专家判断通常用于评11、估项目启动所需要的输入或依据:(1)项目启动、2初步制定的项目范围说明书、3项目管理计划、4指导与管理执行、5监督控制项目、6整体变更控制六者的方法工具基本相同,“4执行”缺少“专家判断”因为专家不干活,“6监督与控制”多出“挣值分析”)

11、项目范围说明书(初步)也称初步的项目范围说明书(与项目章程比较记忆):

(l)项目和范围的目标;(2)产品或服务的需求和特性; (3)项目的需求和可交付物; (4)产品验收标准; (5)项目的边界; (6)项目约束条件; (7)项目假设; (8)最初的项目组织; (9)晟初定义的风险;    (I0)进度里程碑; (11)对项目工作的初步分解; (12)初步的量级成本估算;(13)项目配置管理的需求; (14)审批要求。

12、制定项目范围说明书(初步)的输入(必须回答第一条,能得该题80%分值):(1)项目章程;(2)工作说明书;(3)环境和组织因素;(4)组织过程资产。

13、制定项目范围说明书(初步)的输出:项目范围说明书(初步)明确了项目及其相关的产品和服务、项目的需求和可交付物以及项目的边界。

14、进度计划和项目预算之外,项目管理计划可以是概要的或详细的,并且还可以包含一个或多个分计划。这些分计划包括但不限于:(l)范围管理计划; (2)质量管理计划; (3)过程改进计划; (4)人力资源管理计划; (5)沟通管理计划; (6)风险管理计划; (7)采购管理计划。

15、制定项目管理计划的输入(第二条必须回答,能得该题80%分值): (1)项目章程;(2)项目范围说明书(初步);(3)来自各计划过程的输出;(4)预测;(5)环境和组织因素;(6)组织过程资产;(7)工作绩效信息。

16、制定项目管理计划的输出(会背):(l)项目管理计划;(2)配置管理系统;(3)变更控制系统。

17、指导和管理项目执行的输入(必须回答第一条,能得该题80%分值,因为这条是上一步(制定项目管理计划)的直接输出):(1)项目管理计划;(2)已批准的纠正措施; (3)己批准的预防措施;(4)已批准的变更申请;(5)已批准的缺陷修复;(6)确认缺陷修复。

18、指导和管理项目执行的输出(必须回答第一条):(1)可交付成果;(2)请求的变更;(3)已实施的变更;(4)已实施的纠正措施;(5)已实施的预防行动;(6)已实施的缺陷修复;(7)工作绩效数据。

19、监督和控制项目的输入:(1)项目管理计划;(2)工作绩效信息; (3)绩效报告。

20、监督和控制项目的输出:(1)请求的变更。(2)项目报告。

21、整体变更控制的方法(会背):(1)项目管理方法论;(2)变更控制流程: ①受理变更申请。 ②变更的整体影响分析。 ③接收或拒绝变更。④执行变更。⑤变更结果追踪与审核。

22、整体变更控制的输入:(I)项目管理计划;(2)申请的变更;(3)工作绩效信息;(4)可交付物。

23、整体变更控制的输出(记忆前三条):(1)变更申请被批准或被拒绝;(2)项目管理计划(已批准更新);(3)已批准的纠正措施;(4)已批准的预防措施;(5)已批准的缺陷修复;(6)可交付物(已批准的)。

24、项目管理收尾: (1)确认项目或者阶段已满足所有赞助者、客户,以及其他项目干系人需求的行动和活动。(2)确认已满足项目阶段或者整个项目的完成标准。 (3)当需要时,把项目产品或者服务转移到下一个阶段。(4)活动需要收集项目或者项目阶段记录、检查项目成功或者失败。

25、项目收尾的输入:(1)项目管理计划;(2)合同文件;(3)组织过程资产。

26、项目收尾的输出(重点第一条):(l)最终产品、服务或成果的移交。 (2)管理收尾办法和合同收尾办法。(3)已更新的组织过程资产。

第7章项目范围管理

1、对项目范围的管理,是通过5个管理过程来实现的:

(l)编制范围管理计划。(2)范围定义。 (3)创建工作分解结构在项目范围管理过程中,最常用工具就是工作分解结构(Work BreakdownStnIture,WBS)。 (4)范围确认:该过程决定是否正式接受己完成的项目可交付成果。(5)范围控制项目和产品的范围状态,管理范围变更。

2、 在项目背景下,范围指如下几个术语:(1)产品范围;表示产品、服务或结果的特性和功能。 (2)项目范围:为了完成具有规定特征和功能的产品、服务或结果,而必须完成的

项目工作。

3、项目范围的确认是指:项目干系人对项目范围的正式承认,但实际上项目范围确认是贯

穿整个项目生命周期。

4、范围管理计划是一个计划工具,用以描述该团队如何定义项目范围、如何制订详细的范围说明书、如何定义和编制工作分解结构,以及如何验证和控制范围。

5、编制范围管理计划的输入:(1)项目章程;(2)项目范围说明书(初步);(3)组织过程资产;(4)环境因素和组织因素;(5)项目管理计划。

6、编制范围管理计划的输出: (1)根据初步的项目范围说明书编制一个详细的项目范围说明书的方法。 (2)从详细的项目范围说明书创建WBS的方法。 (3)关于正式确认和认可己完成可交付物方法的详细说明。 (4)有关控制需求变更如何落实到详细的项目范围说明书中的方法。需求变更常常触发整体变更控制过程。

7、项目的范围定义的输入:(l)项目章程和初步的范围说明书。;(2)项目范围管理计划。(3)组织过程资产。(4)批准的变更申请。

8项目的范围定义的输出: (l)项目范围说明书(详细)。(2)更新的项目文档。

9、详细的范围说明书包括的直接内容或引用内容(会背):①项目的目标。②产品范围描述。③项目的可交付物。 ④项目边界。⑤产品验收标准。⑥项目的约束条件。⑦项目的假定。

10、WBS(项目的工作分解结构)的最底层的工作单元被称为工作包,它是定义工作范围、定义项目组织、设定项目产品的质量和规格、估算和控制费用、估算时间周期和安排进度的基础。

11、WBS常见分解结构:(l)分级的树型结构,类似于组织结构图,优点: 树型结构图的WBS层次清晰,非常直观,结构性很强。缺点:但不是很容易修改,对于大的、复杂的项目也很难表示出项目的全景。由于其直观性,一般在一些中小型的应用项目中用得较多。

(2)列表形式:类似于书籍的分级目录,最好是直观的缩进格式。

优点:该表格能够反映出项目所有的工作要素。缺点:直观性较差。常用在一些大的、复杂的项目中,因为有些项目分解后,内容分类较多,容量较大,用缩进图表的形式表示比较方便,也可以装订成册。在项目管理工具软件中,也会采用列表形式的WBS。

12、工作包(业内一般把一个人2周能干完的工作称为一个工作包,或把一个人80小时能干完的工作称为一个工作包)。

13、把整个项目的工作分解为工作包,一般包括下列活动: (1)识别和分析项目可交付物和与其相关的工作。(2)构造和组织WBS。 (3)把高层的WBS工作分解为低层次的、详细的工作单元。(4)为WBS的工作单元分配代码。(5)确认工作分解的程度是必要和充分的。

14、分解WBS结构的方法至少有如下三种:

(1)使用项目生命周期的阶段作为分解的第一层,而把项目可交付物安排在第二层。(2)把项目重要的可交付物作为分解的第一层,如图7.4所示。

(3)把子项目安排在第一层,再分解子项目的WBS。

15、分解工作结构应把握如下原则(重点7/8条):

(1)在各层次上保持项目的完整性,避免遗漏必要的组成部分。

(2) -个工作单元只能从属于某个上层单元,避免变叉从属。

(3)相同层次的工作单元应有相同性质。

(4)工作单元应能分开不同的责任者和不同工作内容。

(5)便于项目管理进行计划和控制的管理需要。

(6)最低层工作应该具有可比性,是可管理的,可定量检查的。

(7)应包括项目管理工作(因为管理是项目具体工作的一部分),包括分包出去的工作。

(8) WBS的最低层次的工作单元是工作包。

16、 详细的分解对遥远的将来才能完成的交付物或子项目是不需要的,也是不可能的。

一般地,项目管理团队应该等待交付物或子项目足够清晰时才制订详细的WBS。

17、创建WBS的输入:(1)详细的项目范围说明书。(2)项目管理计划。(3)组织过程资产。

18、创建WBS的输出:(1) WBS和WBS字典;(2)范围基准;(3)更新的项目管理计划。

19、范围确认是客户等项目干系人正式验收并接受已完成的项目可交付物的过程。

项目范围确认应该贯穿项目的始终。范围确认与质量控制不同,范围确认是有关工作结果的接受问题,而质量控制是有关工作结果正确与否,质量控制一般在范围确认之前完成。

20、项目范围确认的输入:(1)项目管理计划;(2)可交付物。

21、项目范围确认的输出:(l)可接受的项目可交付物和工作。(2)变更申请。(3)更新的WBS和WBS字典。

22、范围控制涉及以下内容:①影响导致范围变更的因素,②确保所有被请求的变更按照项目整体变更控制过程处理,③范围变更发生时管理实际的变更。

23、范围控制的工具和技术:①偏差分析;②重新制订计划;③变更控制系统和变更控制委员会,由变更控制委员会负责枇准或者拒绝变更申请;④配置管理系统。

24、范围控制的输入:(1)项目管理计划;(2)工作绩效数据;(3)绩效报告;(4)已批准的变更请求。

25、范围控制的输出:(l)变更请求;(2)工作绩效;(3)组织过程资产更新;(4)更新的项目管理计划。

时间: 2024-10-10 16:45:15

第六章整体管理、第七章范围管理--中项作业的相关文章

第六章 函数;第七章 类;

函数: 1. 函数一定存在返回值,没返回值时返回None;    2. 函数内赋新值不会改变外部任何变量的值,这一点类似java:但是对于可变参数列表另当别论: 3. == 判断相等性,值考虑空间里面值的情况:is 同一性(等级更高,必然具有相等性) 4. 位置参数-> 关键字参数-> 收集参数:收集其他位的参数(一个*,函数内部接收到的是tuple,本来是tuple那么前面加*,就成了这种可变参数):定义收集参数,使用位置参数— >同时收集参数:收集带默认的参数构成字典(两个**,函数

0429 六七章读后感

一)第六章 1.从第六章对敏捷流程的介绍,我的理解是敏捷流程就是一个团队做一个项目的整个过程,从开始准备到结束.从与客户交流得知项目的需求,到写出雏形.开始开发.最后冲刺完成,再来就是增添需求. 2.第二敏捷流程要求原则:自主管理.自我组织.多功能型.一个团队需要花很长的时间来磨合成一个成熟的团队,除了需要个人的自主完成,还要帮助落后的队员进行改进. 3.而敏捷流程,从字面上理解,也就是需要速度,从开始到结束,花的时间越短越好,但又要保证质量,每天开个小立会.跟进进度,学会与团队交流进度 二)第

《现代前端技术解析》第七章读书笔记

<现代前端技术解析>是张成文写的一本书,2017年4月出版的.先看的最后一章(第七章),第七章主要讲的是未来前端技术的发展趋势及如何成为一名优秀的前端工程师. 过去几年,前端主流技术框架发展极快,在填补了原有技术框架空白和不足的同时也渐渐趋于成熟.未来前端的发展方向主要是等待下一个风口的到来,可能是VR丶人工智能或者其他.就前端应用开发方向来讲,MVVM丶Virtual DOM和同构的技术解决方案依然会延续发展一段时间,而且这段时间内前端框架技术的变化将不会像原来一样具有颠覆性.当MVVM丶V

0502《构建之法》第六、七章读后感

第六章 本章中所说的“敏捷流程”是一系列价值观和方法论的集合.敏捷开发的原则中包括十二条,这十二条原则无论对软件开发者本身,用户还是市场需求,都具有很强的影响力. “敏捷流程”分为四步,每一步都有着一定的作用. 第一步:找出完成产品需求做的事情——product backlog. 第二步:决定当前的冲刺(Sprint)需要的解决的事情——Sprint Backlo.在我们开发一个产品的时候,实现的过程中可以分为几个互相联系的冲刺. 第三步:冲刺(Sprint) 在这个阶段,也是敏捷步骤中最重要的

第六七章学习体会-----(第六次)

在这周我看了第六章敏捷流程跟第七章MSF.并有了以下学习总结. 敏捷这个词听起来就是反应灵敏迅速而有效,而在软件按工程里,敏捷不同于现有做法之处在于,敏捷的价值观和流程是个人和交流.可用的软件.与客户合作.响应变化,而现有做法的则是流程和工具.完备的文档.为合同谈判.执行原定计划敏捷的开发原则是尽早并持续交付有价值的软件以满足顾客需求.只有不断关注技术和设计,才能越来越敏捷.只有能自我管理的团队才能创造优秀的架构.需求和设计.敏捷开发的原则很多,其中印象最深的就是"经常发布可用的软件,发布间隔

第六、七章读后感

第六章——敏捷流程 “敏捷流程”是一系列价值观和方法论的集合,敏捷的步骤:1.找出完成产品需要做的事情——Product Backlog:2.决定当前的冲刺(Sprint)需要解决的事情——Sprint Backlog:3.冲刺(Sprint):4.得到一个软件的增量版本,发布给用户.有敏捷流程,也要有敏捷的团队,敏捷对团队有以下要求:自主管理.自我组织.多功能型. 这章对敏捷做了总结,也为我们分享了实践者应用敏捷流程的经验教训,同时,也通过故事的形式,为我们解答了很多疑问. 问题:初学者该如何

《构建之法》第六、七章

第六章 敏捷流程 1.敏捷流程概述: (1)找出完成产品需要做的事情 (2)决定当前的冲刺需要解决的事情 (3)冲刺 (4)得到软件的一个增量版本,发布给用户 2.每天跟踪的时间值: (1)实际剩余时间:每个团队成员所有任务的剩余时间的总和 (2)预估剩余时间:根据每个人每天的理论进度推算的剩余时间 (3)实际花费时间:实际花费的时间 3.敏捷团队要求:自主管理.自我组织.多功能型 第七章 MSF 1.MSF基本原则: (1)推动信息共享与沟通 (2)为共同的远景而工作 (3)充分授权和信任 (

【转】第七章、Linux 文件与目录管理

原文网址:http://vbird.dic.ksu.edu.tw/linux_basic/0220filemanager.php 第七章.Linux 文件与目录管理 最近升级日期:2009/08/26 在第六章我们认识了Linux系统下的文件权限概念以及目录的配置说明. 在这个章节当中,我们就直接来进一步的操作与管理文件与目录吧!包括在不同的目录间变换. 创建与删除目录.创建与删除文件,还有寻找文件.查阅文件内容等等, 都会在这个章节作个简单的介绍啊! 1. 目录与路径 1.1 相对路径与绝对路

《构建之法》第六、七章学习总结

第六章讲的是关于敏捷流程的知识.在第一节中,对敏捷流程进行了简单的介绍--产品backlog.sprint backlog.sprint.软件的增量发布:第二节介绍了使用敏捷流程时可能碰到的一些问题和相应的解决方法:第三节则讲到一个敏捷的团队要做到自主管理.自我组织.多功能型:第四节则对敏捷流程进行了总结和评价并介绍了一些经验教训:第五节通过问答形式再次向我们详细地介绍了关于敏捷流程的一些知识点. 第七章介绍的是微软解决方案框架(MSF).第一节介绍的是MSF的简史:第二节则介绍了MSF的基本原

《构建之法》读第六、第七章有感

<构建之法>读第六.第七章有感 第六章: 第六章主要详细介绍了敏捷流程,在软件工程范畴里,“敏捷流程”是一系列价值观和方法论的集合.这一章以敏捷流程的Scrum方法论而展开,Scrum 采用迭代.增量的方法来优化可预见性并控制风险,并且SCRUM 是一个用于开发和维持复杂产品的框架. 敏捷开发的流程如下: 1.找出完成产品需要做的事情,每一项工作用天为单位计算. 2.决定当前的冲刺(Sprint)需要解决的事情--Sprint Backlog. 3.冲刺阶段各个团队相互独立,所有的问题都只能在