导图社区 信息系统项目管理基础
超详细的的思维导图来啦！这张思维导图归纳了信息系统项目管理师之项目管理基础的十大知识域、五大管理过程、生命走起简短治理。赶快收场起来吧！
PMP项目质量管理章节知识点考前整理复习， 新考纲过程领域 任务7-规划和管理可交付成果的质量，确定项目可交付成果必须达到的标准 根据质量差距提出改进方案的建议 持续调查项目可交付成果的质量。
PMP项目风险管理章节考前知识点整理复习，风险管理的目标在于提高正面风险的概率和（或）影响，降低负面风险的概率和（或）影响，从而提高项目成功的可能性。
PMP项目整合管理章节知识点整理，考前复盘，预测型项目，整合管理由项目经理负责，整合管理的责任不能被授权或转移；项目经理被要求尽早介入启动项目，例如开展商业论证和效益管理。
社区模板帮助中心，点此进入>>
安全教育的重要性
个人日常活动安排思维导图
西游记主要人物性格分析
17种头脑风暴法
如何令自己更快乐
头脑风暴法四个原则
思维导图
第二职业规划书
记一篇有颜又有料的笔记-by babe
伯赞学习技巧
信息系统项目管理基础
十大知识域
整体管理
全局概念，整体思维
范围管理
确定任务边界
时间管理
项目进度管理
成本管理
财务思维，投入多少、产出多少、投资收益
质量管理
产品质量如何，如何管理产品质量
核心知识域，将形成项目目标
人力资源管理
如何管人、如何带团队
风险管理
就是风险在哪里，如何识别，如何应对
采购管理
供应链
沟通管理
干系人管理
如何打交道
辅助知识域，辅助完成项目目标
五大管理过程
启动
规划
执行
监控
收尾
生命周期阶段治理
启动项目
组织与准备
执行项目工作
结束项目
项目管理的理解
项目管理是一种已被公认的管理模式，而不是任意一次的管理过程
项目管理的对象是项目， 即一系列的临时任务
项目管理的职能与其他管理的职能是完全一致的
项目管理职能主要由项目经理执行的。在一般规模的项目中，项目管理由项目经理带领少量专职项目管理人员完成，项目组织中的其他人员，包括技术与非技术人员负责完成项目任务，并接收管理。如果项目规模很小，那么项目组织内可以只有一个专职管理人员，即项目经理
项目
概念
项目是为提供一项独特产品、服务或成果所做的临时性努力
目标
分类
成果性目标
满足客户要求的产品、系统、服务或成果
约束性目标
时间
成本
质量
特性
有不同优先级
有层次性
特点
临时性（一次性）
每一个项目都有确定的开始和结束日期
独特性
创造独特的可交付成果，如产品、服务或成果
逐步完善
分步连续的积累
如：项目早期，项目的范围说明是粗略的，随着项目团队对目标和可交付成果的理解更完整和深入时，项目的范围也更加具体
资源约束
每一个项目都需要具备各种资源来作为实施的保证，而资源是有限的。所以，资源成本是项目成功实施的一个约束条件
目的性
项目工作的目的在于得到特定的结果，即项目是面向目标的
与日常运作
共同点
由人来做
受限于有限资源
需要规划、执行和控制
不同点
持续时间
日常运作是持续不断和重复进行的，而项目是临时性的、独特的
目的
项目的目的是实现其目标，然后结束项目，而日常运作是为了维持经营
实现机制
项目宣布目标实现时，项目就结束了。日常运作是不断确定新目标，持续进行
四重制约
范围
信息系统项目特点
目标不明确
需求变化频繁
智力密集型
设计队伍庞大
设计人员高度专业
设计的承包商多
各级承包商分布在各地，相互联系复杂
系统集成项目中需研制开发大量的软硬件系统
项目生命周期通常较短
通常要采用大量的新技术
使用与维护的要求非常复杂
PRINCE2
是一种基于流程的结构化项目管理方法
人际关系管理
有效的沟通
影响一个组织
领导能力
激励
谈判和冲突管理
问题解决
四要素
原则
流程
主题
项目环境
七个原则
持续业务验证
吸取经验教训
明确定义的角色和职责
按阶段管理
例外管理
关注产品
根据项目环境剪裁
商业论证
组织
计划
风险
变更
进展
组织结构对项目的影响
职能型
简介
项目经理无权无资源，所有项目人员还在所属部门供职，仅花费小部分时间来处理项目的事情。还有相应的职能经理，进行双重管理
优点
可以充分发挥职能部门的资源集中优势
部门的专家可以同时为部门的不同项目使用
便于相互交流，相互支援，可以随时增派人员
可以将项目和本部门的职能工作融为一体
缺点
项目和部门利益发生冲突，职能部门更重视本部门的目标，会忽视项目目标
资源平衡会出现问题
权力分割不利于各个职能部门的交流和团队合作
行政隶属关系使得项目经理没有充分的权力
项目型
将所有的能兵强将集结在一起，财务部、业务部、IT管理部等的精英们脱离原有岗位，形成一个正式的部门，并由项目经理领导
项目经理对项目可以负全责
项目目标单一，可以以项目为中心，有利于项目顺利进行
避免多重领导
组织结构简单，交流简单、快速
资源不能共享
各个独立的项目处于相对封闭的状态，不利于公司政策的贯彻
对项目组织的成员缺少一种事业上的连续性和安全感
项目组织之间处于分割状态，缺少信息交流
矩阵型
兼具项目型和职能型的特点；
弱矩阵
项目经理 < 职能经理
平衡矩阵
项目经理 > 职能经理
强矩阵
专职的项目经理负责整个项目，以项目为中心
公司的多个项目可以共享各个职能部门的资源
即利于项目目标的实现，又利于公司目标方针的贯彻
项目成员的顾虑减少
容易引起职能经理和项目经理权力的冲突
资源共享也能引起项目之间的冲突
项目成员有多头领导
概要
信息系统项目的生命周期
特征
成本与人力投入在开始时比较低，在工作执行期间达到最高，并在项目快要结束时迅速回落
风险与不确定性在项目最开始时最大，并在项目的整个生命周期中随着决策的制定与可交付成果的验收而逐步降低
在不显著影响成本的前提下，改变项目产品最终特性的能力在项目开始时最大
各阶段的类似特点
各阶段的工作重点不同，通常涉及不同的组织，处于不同的地理位置，需要不同的技能组合
为了实现各阶段的主要可交付成果或目标，需要对各阶段及其活动进行独特的控制或采用独特的过程。重复执行全部五大过程组中的过程，可以提供所需的额外控制，并定义阶段的边界
阶段的结束以作为阶段性可交付成果的工作产品的转移或移交为标志。阶段结束点时重新评估项目活动，并变更或终止项目（如果必要）的一个当然时点。这个时点可称为阶段关口、里程碑、阶段审查、阶段门或关键决策点。
阶段与阶段的关系
顺序关系
交叠关系
典型生命周期模型
瀑布模型
瀑布模型是一个经典的软件生命周期模型
阶段
可行性分析（计划）
需求分析
软件设计（概要设计、详细设计）
编码（含单元测试）
测试
运行维护
从上一项开发活动接受该项活动的工作对象作为输入
利用这一输入，实施该项活动应完成的工作内容
给出该项活动的工作成果，作为输出传给下一项开发活动
对该项活动的实施工作成果进行评审
螺旋模型
螺旋模型是一个演化软件过程模型，将原型实现的迭代特征与线性顺序（瀑布）模型中控制的和系统化的方面结合起来。使得软件的增量版本的快速开发成为可能
在螺旋模型中，软件开发是一系列的增量发布。在早期的迭代中，发布的增量可能是一个纸上的模型或原型；在以后的迭代中，被开发系统的更加完善的版本逐步产生
四阶段
制定计划
风险分析
实施工程
客户评估
螺旋模型强调了风险分析，特别适合与庞大而复杂的、高风险的系统
迭代式开发模型
阶段及任务
初始
系统地阐述项目的范围，选择可行的系统架构，计划和准备业务案例
细化
细化构想，细化过程和基础设施，细化构架并选择构件
构造
资源管理、控制和过程最优化，完成构件的开发并依评价标准进行测试，依构想的验收标准评估产品的发布
移交
同步并使并发的构造增量集成到一致的实施基线中，与实施有关的工程活动根据完整的构想和需求集的验收标准评估实施基线
V模型
左边下画线
概要设计
详细设计
编码
右边上画线
单元测试
验证软件单元是否按照单元规格说明（详细设计说明）正确执行，即保证每个最小单元能够正常运行。单元测试一般由开发人员来执行，首先设定最小的测试单元，然后通过设计相应的测试用例来验证各个单元功能的正确性
集成测试
检查多个单元是否按照系统概要设计描述的方式协同工作。主要关注点是系统能够成功编译，实现了主要的业务功能，系统各个模块之间数据能够正常通信等
系统测试
验证整个系统是否满足需求规格说明书
验收测试
从用户角度检查系统是否满足合同中定义的需求或者用户需求
体现的主要思想是开发和测试同等重要，左侧代表的开发活动，而右侧代表的测试活动
针对每个开发阶段，都有一个测试级别与之对应
测试依旧是开发生命周期中的阶段，与瀑布模型不同的是，有多个测试级别与开发阶段对应
适用于需求明确和需求变更不频繁的场景
原型
原型法认为在很难一下子全面准确地提出用户需求的情况下，首先不要求一定要对系统做全面、详细的调查、分析，而是本着开发人员对用户需求的初步理解，先快速开发一个原型系统，然后通过反复修改来实现用户的最终系统需求
实际可行
具有最终系统的基本特征
构造方便、快速、造价低
抛弃型
进化型
敏捷开发
以人为核心、迭代、循序渐进的开发方法
Scrum是一种迭代式增量软件开发过程
五大过程组、47个过程梳理
