（干货）系统集成项目管理工程师4
2024-06-28 16:08:49 0 举报AI智能生成
登录查看完整内容
软考中级，全系列分为7个部分，这是第四部分
作者其他创作
大纲/内容
可行性分析、需求分析、概要设计、详细设计、编码、测试、运行维护
定义
需求明确或很少变更的项目
开发团队比较弱
有厚实的行业实践基础
适用
瀑布模型
四阶段：制定计划、风险分析、实施工程和客户评估
强调风险分析，适用于庞大而复杂的、高风险的项目
特点
螺旋模型
在不同的时间段内工作量不同，几乎所有的工作流在所有时间段内都有工作量，只是大小不同而已
适用于不能完整定义产品的所有需求、计划多期开发的
注意在迭代过程中，每个阶段都包括不同比例的所有活动
特征
初始
细化
构造
移交
工作流阶段
迭代模型
非常清晰的描述了开发阶段和测试阶段的对应关系
意义
编码阶段对应单元测试阶段
详细设计对应集成测试
概要设计对应系统测试
需求分析对应验收测试
对应
V模型
适用于用户需求开始时定义不清、管理决策方法结构化程度不高的系统开发
原型化模型
项目管理模型
启动 过程组
规划 过程组
执行过程组
监控过程组
收尾过程组
过程组
任何项目都必需这5个过程组
过程组极少是孤立的，而是在整个项目期间相互重叠
监控过程通常不能在时间段上独立存在，而是贯穿其他所有 过程
在多阶段项目上，这些过程会在每个阶段重复进行，直到符合阶段完成标准
关系
PDCA戴明循环
有明确的起始和结束时间，项目是一次性的
临时性
独有的，没有完全一样的项目
独特性
项目的成果性目标是逐步完成的
项目的成果随着项目的进行才能逐步明朗、完善和精确
在项目渐进明细的个过程中一定会有修改，产生相应的变更
渐进明细
项目特点
具有不同的优先级
有层次性
特性
成果性目标
约束性目标
分类
项目目标
时间
成本
范围
核心
质量
项目成功4约束
以用户需求为根本出发点
用户需求常常不够明确、复杂多变
不是选择最好的技术，而是最适合用户需求以及投资规模的技术
高技术与高技术的集成
系统工程，包括技术、商务和管理活动
团队年轻，流动性高
强调沟通的重要性
系统集成的特点
项目
又称立项申请
建设单位提交项目申请时必须的文件
项目建议书
项目建议
项目可行性分析
项目审批
项目招投标
项目合同谈判与签订
5环节
解决项目组织战略符合性问题，也就是项目值不值得去做的问题
目标
立项管理
投资的必要性
技术可行性
财务可行性
组织可行性
经济可行性
社会可行性
风险因素及对策
可行性研究的内容
机会研究
初步可行性研究
详细可行性研究
评估和决策
可行性研究阶段
资格预审文件或招投标文件发售期不得少于5日
通过资格预审的申请人少于3个，应重新招投标
投标保证金不得超过项目估算价的2%，且有效期应当与投标有效期一致
招标人可自行决定是否编制标底，且只能有一个标底，必须保密
招标人设有最高投标限价时，应该在投标书中明确最高限价或最高限价的计算方法，投标人不得规定最低投标限价
招标人不得组织单个或部分潜在投标人踏勘现场
文件
招投标
项目意向识别
项目售前沟通
获取招标文件
除必要的修改外，投标文件不允许修改
电话、电报、传值等形式的投标文件概不接受
正本和副本有差异，以正本为准
每一封密信注明何时前不准启封
投标文件由专人递交
编写投标文件
供应商在招投标阶段的主要工作
投标人数少于3人，不得开标
评标报告需要评标委员会全体签字
招标人需要在收到评标报告后3日内公布中标候选人，公示期不得少于3日
公示期有异议的，招标人需要在收到异议之日起3日内作出答复
开标评标要求
中标通知书对招标人和中标人都有法律效力
招标人应该在书面合同签订后5日内退还投标保证金及银行利息
履约保证金不得超过中标合同金额的10%
要求
合同约定或经过招标人同意，可将中标项目的部分非主体、非关键的部分分包
接受分包的需要具备相应的资格认证，并且不得再次分包
中标人就分包项目向招标人负责，接受分包的人承担分包项目的连带责任
分包
选定承建方
项目立项管理
制定项目章程
制定项目管理计划
指导与管理项目工作
监控项目工作
实施整体变更控制
结束项目或阶段
过程
项目整体管理是项目管理的核心，寻找最佳平衡点
地位
整体管理概述
项目整体管理
why
what
who
when
how
4W1H
什么是包括在项目内的，什么是不包括在项目内的，即为项目工作明确划定边界
编辑范围管理计划
收集需求
定义范围
创建工作分解结构
确认范围
范围控制
计划
监控
表示服务、产品或结果的特征和功能，强调结果
以项目管理计划书、项目范围说明书、WBS以及WBS字典作为衡量工具
产品范围
为了完成具有规定特征和功能的服务、产品或结果而必须完成的项目工作，强调过程
以产品要求作为衡量标准
项目范围
补充
描述了如何定义、制定、监督、控制和确认项目范围
有助于降低项目范围蔓延的风险
制定范围管理计划
最重要的任务就是详细定义项目的边界范围
制定项目和产品详细描述的过程
明确所收集的需求哪些将包含在项目范围内，哪些将排除在外，从而明确项目、服务或输出的边界
范围定义
把项目可交付成果、项目工作分解成更小的、更易于管理的组件的过程
层次清晰、结构性强、不易修改，一般用于小项目，
分级树型
反应项目所有工作要素，直观性差，一般用于大型项目
表格
结构
创建WBS
正式验收已完成的项目、已交付的成果的过程
应该贯穿项目的始终
应该以书面形式记录
范围确认
监督项目和产品的范围状态，管理范围基准变更的过程
变更不可避免呢
确定范围变更是否已经发生
对造成范围变更的因素施加影响，以便于这些变更得到一致认可
当范围变更发生时，对实际的变更进行管理
变更控制的焦点问题
范围管理概念
项目范围管理
规划进度管理
定义活动
排列活动顺序
估算活动资源
估算活动持续时间
制定进度计划
控制进度
计划过程组
为实施项目进度管理制定政策、程序，并形成文档化的项目进度管理计划的过程
提供指南和方向
进度管理计划
输出
是项目中时间最长的活动顺序，决定着可能的项目最短工期
关键路径可能存在多条，关键路径越多，风险越大
关键路径法排出来的进度管理计划未必可行
关键路径法
建立在关键路径之上，考虑了资源分配、资源优化、资源平衡和活动历时不确定性对关键路径的影响
引入了缓冲和缓冲管理
增加了作为非工作活动的持续时间缓冲，以应对不确定性
关键链法不再管理网络路径的总浮动时间，而是管理剩余缓冲时间和剩余的活动链的持续时间之间的关系
放置在关键链末端
项目缓冲
放置在关键链和非关键链之间的节点，保护关键链不受非关键链延误的影响
接驳缓冲
组成
关键链法
往往导致关键路径改变，通常是延长
资源平衡
不会改变项目关键路径，也不会延长项目工期
活动只会在自由浮动时间和总浮动时间之内延迟
资源平滑
问关键路径要时间，问非关键路径要资源
资源优化技术
通过增加资源，压缩单个进度的工期以实现总工期减少
并非总是可行的，可能会导致风险、成本的增加
只适用于那些能通过增加资源就能实现压缩持续时间的，且位于关键路径上的活动
赶工
将正常情况下顺序进行的活动改成至少部分是并行展开的
快速更进可能造成返工和风险增加
只适用于能通过并行缩短工期的情况
快速跟进
进度压缩
横道图
甘特图
里程碑
工具
68%、95%、99%
平均时间在正负1倍标准时间差之间的概率为68.26%
平均时间在正负2倍标准时间差之间的概率为95.46%
平均时间在正负3倍标准时间差之家的概率为99.73%
三个点
活动持续时间（平均时间）=（最可能时间*4 + 最乐观时间 + 最悲观时间） / 6
持续时间标准差=(最乐观时间 - 最悲观时间) / 6
PTRT三点估算
计算
进度管理的技术和工具
实箭线表示项目活动，其水平投影的长度表示该活动持续的时间
虚线表示虚活动，其没有时间，因此虚活动通常为垂直虚线
波浪线表示活动与其紧后活动之间的浮动时间
每个活动的总时长为活动开始后所有路径波浪线之和的最小值
双代号时标网络图
项目进度管理
系统集成项目管理工程师
0 条评论
回复 删除
下一页
