软考中项
943人加入学习
(0人评价)
乐凯2311期软考中项直播课程

软考中项

价格 ¥ 1499.00
该课程属于 乐凯2311软考中项班级
请加入后再学习

预期收入   EMV

(收入-投资)*概率+(收入-投资)*概率 =EMV

收入-投资=利润

 

投资回报   =  预期收入-投资

 

(300-100)*0.75  +  (60-100)*0.25=140

 

100*0.5+200*0.2+250*0.15+0.05*-500=

50+40+37.5-25=102.5

 

 

[展开全文]

 

 

约束性目标也叫管理性目标

目标要求遵守SMART原则:五大原则

Specific(具体的)

Measurable(可测量的)

Attainable(可达到的)

Relevant(有相关性的)

Time-bound(有时限的)

[展开全文]

沟通管理计划是有具体的沟通的。

规划沟通管理是识别和记录与干系人的最有效率且最有效果的沟通方式。

有效果的沟通  以正确的形式、在正确的时间把信息提供给正确的受众,并且使信息产生正确的影响

有效率的沟通   只提供所需要的信息

沟通管理计划内容:

干系人沟通需求  

需要沟通的信息,包括语言、格式、内容、详细程度

发布信息以及告知收悉或做出回应

负责授权保密信息发布的人员

将要接收信息的个人或小组

来自法律、技术、组织政策等的制约因素

为沟通活动分配的资源,包括时间和预算

问题升级程序 下层员工无法解决问题时的上报时限和上报路径

通用术语表  可以包括用户沟通的指南和模板

项目管理信息系统 (PMIS)信息化的管理项目的、信息化的软件

信息管理系统只是处理信息的

管理沟通根据沟通管理计划,进行 沟通过程管理的最终目标,就是保障项目干系人之间实现有效率且有效果的沟通。

唯二的启动过程组:制定项目章程、识别干系人

干系人管理计划、沟通管理计划都有具体的内容

识别干系人是识别、分析、分类。

识别干系人输入项目章程有发起人、甲方领导人、BA、项目经理以及其领导等

采购文件(合同各方都是关键的项目干系人)

 

[展开全文]

规划风险管理

项目章程里有高层级的风险、项目描述和需求

干系人登记册识别风险的最重要依据

输出风险管理计划

识别风险 

识别风险原则 1.由粗及细,由细及粗 2.严格界定风险内涵并考虑风险因素之间的相关性 3.先怀疑后排除 4.排除与确认并重 5.必要时,可作实验论证

实施定性风险分析

对风险进行优先排序

实施定量风险分析

规划风险应对

根据优先级来指定应对措施

消极风险或威胁的应对策略

积极风险或机会应对策略

在风险发生前进行应对

应急应对策略在风险发生时

权变措施针对未知风险,走管理储备。

未知风险发生后要登记到问题日志里,不能更新到风险登记册里。  

控制风险是实施风险应,并监督实施情况,跟踪已识别风险、监督残余风险、识别新风险、关闭过时风险、以及评估风险管理过程有效性。

风险审计可以内部也可以外部审计

 

[展开全文]

领导者:确定方向、统一思想、激励和鼓舞

管理者:率众实现目标、做事

规划人力资源管理识别和记录项目角色、职责、并编制人员配备管理计划

组建项目团队

工具:预分派     谈判     招募   虚拟团队   多标准决策分析

输出:项目人员分派(已获得人员清单)    资源日历

建设项目团队(提升项目绩效)

提高工作能力,促进团队成员互动

目标:提高成员知识技能、提高成员信任和认同感、创建富有生气,凝聚力和协作性的团队文化

成功的项目团队特点

1.团队目标明确统一

2.组织结构清晰,岗位明确

3.有成文和习惯的工作流程

4.有明确的考核和评价标准

5.共同制定并遵守组织纪律

6.协同工作

建设项目团队工具:人际关系技能、培训、团队建设活动、基本规则、集中办公(增进沟通)、认可与奖励(奖励要满足需求)、人事测评工具

需求层次理论

生理需求:工作服、工作餐、员工宿舍、班车、工资

安全需求:长期劳动合同、社保

社交需求:定期员工合同、聚会、比赛、俱乐部

受尊重需求:形象、地位提升、奖章、荣誉性奖励

自我实现需求:参与决策、管理、成为智囊团

双因素理论 

建设项目团队输出:团队绩效评估(目标个人和团队)

管理项目团队(解决问题、解决冲突、管理团队变更增加人员以及离开人员)

管理项目团队工具:观察和交谈、项目绩效评估、冲突管理

 

[展开全文]

质量  反应实体满足 主体明确和隐含需求的能力的特性总和。(ISO定义)

一组固有特性满足需求的程度(国标定义)

项目合同通常是进行项目质量管理的主要依据。

质量很根本包含质量成本,质量成本不包括生产成本。

标杆对照关键词识别最佳实践,用于确定质量标准。

实验设计(DOE)系统的改变所有重要元素,而不是每次只改变一个要素。

因果图追溯根本原因

流程图关键词步骤顺序(菱形是判断)识别潜在缺陷、估算质量成本、预测出错环节

核查表(计数表)收集数据、潜在质量问题、缺陷数量或后果、统计分析结果。没有分析

帕累托图 二八定律、80/20法则、优先排序、有重点采取纠正措施。识别主要原因

直方图集中趋势、分散程度、分布形状、特定变量发生的频率(查看趋势分布

控制图确定过程是否稳定(一点原则、七点原则判断)

散点图  两个变量(表XY关系)  回归性  强相关性  自变量  因变量 

规划质量管理输出两个计划一个质量管理计划、一个过程改进计划,两个文件质量测量指标、质量核对单。 将指标放进核对单里。

 规划质量管理 要做的工作 定指标 定计划 估算质量成本

实施质量保证针对过程  ,属于一致性成本预防和评价要用到规划质量管理和质量控制过程所产生的数据。

实施质量保证的工作 1.按质量管理计划和质量测量指标做出合格的质量   2.按过程改进计划改进生产过程,消除非增值活动 3.对照实际质量绩效考察质量指标和可操作定义的合理性,提出必要的变更请求  4.提高主要项目干系人对项目将要达到质量要求的信心

质量控制测量结果是控制质量的输出。

新7工具

亲和图 找同类 

过程决策程序图 识目标

关联图 逻辑识关联

树形图 分层级

优先矩阵 排顺序

活动网络图 箭头图

矩阵图   分析数据用矩阵

质量审计

团队以外的人,组织内部或组织外部 

审计目标:1.识别最佳实践、违规做法、差距及不足  2.分享类似项目的良好实践  3.协助过程该尽、提高生产效率   4.积累经验教训  5.确认已批准的变更请求的事实情况

质量审计旨在过程改进 可事先安排也可随机进行内部外部都可以

 控制质量是针对可交付成果

控制质量要做的工作

1.用质量核对单检查质量

2.检查项目的管理工作质量并记录检查结果(质量控制测量结果)

3.检查已完成的可交付成果是否符合质量要求,并记录检查结果(质量控制测量结果)

4.基于质量控制结果和相关计划,整理出工作绩效信息并提出变更请求

5.检查已批准的变更请求是否已得到合理实施

统计抽样   检查查结果 

 

 

[展开全文]

项目整体管理

1.定义。识别、定义、组合、统一和协调各项目管理过程组的各种过程和活动开展的工作

项目经理承担整合角色,整体管理指导其他九大领域,其他领域也为整体管理服务,整体管理更重要些。

 

 

[展开全文]

挣值分析(EVA)

SV(进度偏差)=EV-PV    SPI(进度绩效指数)=EV/PV

CV(成本偏差)=EV-AC    CPI(成本绩效指数)=EV/AC  

[展开全文]

估算活动资源

输入:资源日历 、活动成本估算(估算活动成本输出)、进度管理计划、活动清单

输出:活动资源需求(项目文件)组件项目团队的输入   RBS(资源分解结构)没有具体资源,只有类别、等级

估算活动持续时间

输入:活动资源需求 、资源日历、项目范围说明数

技术:类比估算、参数估算、三点估算

输出:活动持续时间估算 不包括提前量和滞后量

资源平滑和资源平衡

进度压缩:赶工、快速跟进(造成风险增加的概率很大)

进度基准包括进度模型和进度数据,项目进度计划是项目文件不是项目管理计划。

里程碑进度计划是给客户看的

详细进度计划(逻辑横道图)给项目团队看的

时标网络图

缩短工期的方法

1.赶工,投入更多资源或增加宗座时间,缩短关键活动工期

2.快速跟进并行施工,缩短关键路径长度

3.使用高素质资源或经验丰富的人员

4.甲方同意前提下缩小活动范围或降低活动要求

5.改进技术或方法,以提高生产效率

6.加强质量管理,及时发现问题,减少返工,从而缩短工期

 

 

[展开全文]
  • 项目范围管理之“创建WBS”

WBS 工作分解结构

工作包(80个小时内可完成)一定是可交付成果

层次越高,颗粒度越大

WBS分解的5个步骤(背) 

WBS分解原则(7条背出) 

  • 确认范围

一般步骤(背)

确认范围时需要检查的问题(背)  

[展开全文]

项目工作说明书包含:业务需求、产品范围描述、战略计划。

商业论证是经济可行性方面的论证(乙方对甲方sow论证,商业分析师做的,贯穿项目始终)发起组织拍板。 商业论证:项目经理是确保满足商业理论中规定的组织目的和广大干系人需求

项目建议书是项目启动的依据和基础,而项目工作说明书则是项目执行和交付的指导手册

合同是协议的一种形式。

项目章程的内容:委派的项目经理及其权责、项目目的或批准的原因、概括性的项目描述、可测量的项目目标、项目审批要求、总体要求、总体里程碑进度计划、总体预算、主要风险、发起人或其他批准项目章程的人员信息

工作绩效数据是原始测量值 指导与管理项目工作(执行)

工作绩效信息是整合分析后的绩效数据(监控)

工作绩效报告汇编工作绩效信息形成的文件(监控)

变更在任何过程中都可体现

变更请求必须书面记录。包括:预防措施、纠正措施、更新、缺陷补救

监控项目工作的输出工作绩效报告(只在监控项目工作输出)

变更出现的原因:范围定义的过失或疏忽、客户提出新需求、应对风险的计划、绩效不良带来的被动调整、团队人员调整、技术革新的要求、外部事件

变更按性质(不同审批权限)划分:重大变更、重要变更、一般变更。按迫切性(不同变更处理流程)分:紧急变更、非紧急变更

项目经理对整个变更管理过程负责。

CCB只能建立在项目层面上。

实施整体变更控制  

变更请求流程:提出变更请求    变更影响分析

CCB审查批准(通过实施,未通过更新变更日志)  更新通知实施变更   监控变更实施   结束变更

阶段收尾也需释放资源。

行政收尾针对整个项目以及项目各阶段

合同收尾针对合同,有几个合同进行几次收尾

 

[展开全文]

范围管理是龙头(做什么)进度(多少时间做)成本(多少钱做)质量(按什么要求做)

业务需求(组织高层级需要)功能需求(流程、数据、互动)非功能需求(性能、安全性、可靠性)

产品范围决定项目范围 、项目范围服务于产品范围。产品范围产品需求文件考核、项目范围项目关机计划(范围基准)考核

范围来自需求。

范围潜变是客户不断提出小的、不易察觉的范围改变。外部

多镀金是项目人员讨好客户做的。内部    都属与范围蔓延

出现范围蔓延,一样要走变更流程,审批通过更新基准。审批不过版本回退。

范围管理计划没有范围,要找范围在范围基准里面,范围改变更新范围基准

范围管理计划有助于降低项目范围蔓延的风险

范围管理计划内容:如何制定范围说明书、如何根据范围说明书创建WBS、如何维护和批准WBS、如何确认和正式验收已完成的项目可交付成果、如何处理项目范围书的变更,该工作与实施整体变更过程直接相联。

需求管理计划描述在整个项目生命周期内

配置管理活动如何启动变更、如何分析其影响、如何进行追溯跟踪和报告、变更审批权限

收集需求为实现项目目标而确定、记录并管理干系人的需要和需求的过程。

项目章程作为收集需求的输入是因为项目章程里有产品、服务或成果的高层级描述(即高层级需求)

访谈可能获取机密和敏感的信息

德尔菲技术是专家、匿名、多轮、趋同、消除偏见

群体决策技术:一致同意、大多数原则、独裁、相对多数原则

所有的需求都在需求文件,需求是必须明确的、量化的、可测量的,可以跟踪、完整的、相互协调的

需求跟踪矩阵:每个需求与业务目标联系起来、提供了整个项目生命周期中跟踪需求的一种方法

需求跟踪的内容:业务需求、机会、目的和目标

项目目标      项目范围(WBS可交付成果)   产品设计、产品开发     测试策略和测试场景     高层次需求到详细需求  

定义范围是要在需求文件中选取最终的项目需求

项目范围说明书包含产品范围和项目范围

项目范围说明书包含:产品范围描述、验收标准、可交付成果、除外责任、制约因素、假设条件。 

工作包一定是可交付成果正确,可交付成果一定是工作包错误

WBS中每个组件都是名词性的可交付成果(产品、服务、成果)层次越高可力度越大,范围广工作量大完成时间长,反之颗粒度越小。

WBS分解步骤:识别和分析可交付成果及相关工作(依据项目范围说明书识别分析)、确定WBS的结构和编排方法(依据项目管理计划来确定)、自上而下逐层细化分解、为WBS组件指定和分配标识变码、核实可交付成果分解的程度是否恰当

核实的可交付成果

所有的控制xx过程都是用计划和数据进行偏差分析后得出信息和变更请求。

[展开全文]

生命周期模型 

瀑布模型:使用需求明确或很少变更、开发团队比较弱、有厚实行业实践基础、整批一次*付。预测性、计划驱动,结构化开发方法中最常用本质是一次通过。周期长、适应性差。

迭代模型:不能完整定义产品的所有诉求、多期开发、开发早期需求有变化、需要降低复杂性、部分交付有利于干系人的。重复的循环,分次交付、完善性迭代

增量模型:额外增加、渐进的增加属于功能型迭代。迭代增量。游戏是典型

敏捷开发:人为核心,快速迭代加增量、频繁交付、每次交付最有价值成果。一开始不能完整的确定需求和范 围,需要应对快速变化的环境。

RUP:每个阶段从上到下完成一次迭代,即从核心过程工作流再到核心支持工作流执行一遍完成一次迭代,每个阶段可以多次迭代。 

原型化模型: 需求定义不清、管理决策方法结构化程度不高的系统开发。

螺旋模型:瀑布和快速模型的结合,强调风险分析,适合大型复杂的、风险大的项目。包含:制定计划、风险分析、实施工程、客户评估。

V模型:需求明确、变更不频繁。编码单元测试(模块内)开发做、详细集成测试(模块间)QC、概要系统测试(系统整体)QC、需求验收测试(产品测试)客户做。测试开发对应!

项目立项的过程:项目建议、可行性分析、项目审批、招投标、项目合同谈判与签订。

[展开全文]

1.项目临时性,临时性不意味着时间短,局部重复不改变整体的独特。(临时性是指过程的临时,结果需要持久)

2.批量标准化的生产、每天重复的批量产品不能算作项目(即运营,持久重复的)。

项目终止的情况①达成/未达成项目目标②资金缺乏③需求不存在(不需要做了)④没资源做了⑤法律或便利原因(不让做了)所有的结果都需要进行收尾。

项目具有独特性(会带来不确定性即风险)、渐进明细性(过程中会出现变更)。

系统集成项目特点:满足用户需求、需求不明确复杂多变、需各方重视必要时“一把手”挂帅、高技术集成、对PM领导水平要求高、强调沟通重要性、系统集成不是选择最好产品而是选择最适合用户需求的产品。

事业环境因素客观存在大环境因素、无法控制(组织内部文化结构、设施地理分布、人力资源、人员技能绩效评估、项目管理信息系统)(组织外部市场状况、国家标准行业标准、法律法规、行业数据库

组织过程资产(组织本身特有的可参照可更新可使用可不使用,风险登记册、财务数据库、项目档案、经验学习系统、配置管理知识库

项目一般人员从项目型开始是全职。

项目经理从平衡矩阵开始是全职。

PMO  

pmo也是职能部门,为项目经理提供支持、帮助。(指导培训、监督、管理、协调)  

项目通用生命周期 (启动项目、组织与准备、执行项目工作、结束项目

项目管理过程组(启动、规划、执行、监控、收尾)管理操作维度划分,通用操作过程。

产品生命周期可包含多个项目生命周期。

启动定义批准项目   规划定义细化目标规划最佳技术方案和管理计划、执行项目管理计划、监控进展识别偏差采取纠正措施、收尾正式接受工作成果结束项目。

[展开全文]

2023.7.24 项目管理一般知识(下)

1.典型的信息系统项目的生命周期模型

瀑布模型:按部就班执行,一开始非常了解所有的性能、功能,一次*付

迭代模型(分次交付):不断地再重复循环(每次从头到尾做一遍)、不断地进行完善,完善型迭代,变得更好;适用-多期开发,分次交付,确定的先交付,不断地重复完善

增量模型(分次交付):非整体开发模型,功能型迭代,最后一次迭代之后才能视为完整,第一次迭代东西没有动,额外增加的,渐进增加,不断添加功能

敏捷模型(小步快跑):快速的迭代+增量,面对频繁的变更,2-4周迭代一次,迭代时间短,可频繁交付,每次交付优先级最高的东西,交付最有价值的东西,自组织团队,自己挑活干,对人要求比较高,以人为核心;每次迭代前梳理下最紧急的,去掉伪紧急的

统一过程模型RUP:分成四个阶段,

两个轴-横轴为生命周期,初始、细化、构建、交付等四个阶段;纵轴为自然的逻辑活动,过程的工作流和支持工作流

初始、细化、构建、交付等四个阶段,每个阶段从上到下完成一次迭代,即从核心过程工作流执行一遍,在核心支持工作流执行一遍完成一次迭代;在一个阶段可以完成一次到多次的迭代

原型化模型:快速开发一个原型系统,再不断修改,适用:需求开始定义不清,结构化程度不高,模型返工,模型OK再开发

螺旋模型:瀑布型+快速原型模型,一个个阶段开始做,每个阶段分成四个小阶段,如制定计划、风险分析、实施工程、客户评估,适用于大型复杂,风险大的项目

V模型:细化了瀑布模型的测试部分,8个阶段顺序走,开发阶段清楚、便于控制开发的过程

第五章 项目立项管理

 

[展开全文]