项目管理.docx
- 文档编号:2959832
- 上传时间:2022-11-16
- 格式:DOCX
- 页数:32
- 大小:143.24KB
项目管理.docx
《项目管理.docx》由会员分享,可在线阅读,更多相关《项目管理.docx(32页珍藏版)》请在冰豆网上搜索。
项目管理
1项目管理
1.1风险管理
1.1.1目的与范围
风险管理目的是规定了组织对项目进行过程中实施风险分析、控制、监管的具体要求。
实现对产品、解决方案实现过程中各阶段的风险控制管理,开发部门也可依据此规程定义部门的规程或细则。
1.1.2术语与缩略语
RMR(RiskManagermentReport)项目风险管理表。
1.1.3项目职责
●项目经理/项目软件经理
负责在项目进行的各个阶段开始前组织相关人员进行风险分析,在各阶段实施过程中进行风险控制,在项目总结时进行风险管理总结。
●软件质量保证人员
负责在质量管理的相关领域识别项目的关键点,判断风险,并提出控制措施建议;项目进行过程中根据已确认的风险控制措施对其执行情况进行监管。
●项目管理人员
负责建立适用的“风险示例”并定期对其进行更新;在项目管理的相关领域协助项目经理和软件经理进行风险分析,并根据确定的风险控制措施进行风险监管;在项目结束阶段协助项目经理和软件经理进行风险管理总结。
1.1.4管理程序
1.1.4.1风险分析过程示意图
1.1.4.2风险分析
1.1.4.2.1目的
在软件开发或系统集成项目各阶段开始前识别出尽可能多的项目风险,减轻项目过程中风险对项目造成的危害。
1.1.4.2.2过程活动
◆项目任务书下达后,在项目策划阶段由项目经理/项目软件经理组织项目组成员、项目质量保证人员、部门项目管理人员以及部门相关资深人员召开风险评估会议;
◆在会议上发给会议成员项目前期的有关资料,参照组织文件的“风险示例”识别出开发/实施过程中的全部风险,明确风险类型,制定风险控制措施。
项目经理/项目软件经理负责按照会议结果填写《项目风险管理表》。
◆项目的各阶段开始前,或项目发生重大变更时,由项目经理/项目软件经理协同项目组成员识别新的风险,修正前期识别出的不准确的风险,调整风险控制措施,关闭已消失或已发生的风险,进一步完善《项目风险管理表》,按照评审规程中的相关要求进行适当等级、形式的评审。
1.1.4.2.3风险类型
◆项目风险:
威胁到项目进度计划。
即如果项目风险变成现实,有可能会拖延项目的进度、增加项目的成本。
包括预算、进度、资源、客户配合及需求等方面的潜在问题;
◆技术风险:
威胁到待开发软件的质量及正常交付。
即如果技术风险变成现实,开发工作有可能变得很困难或根本不可能。
包括设计、实现、接口、验证及维护等方面的潜在问题;
◆商业风险:
威胁到待开发软件的生存能力。
即如果商业风险变成现实,即便开发出优秀的软件也有无法赢利的可能性。
包括管理层支持、市场、商业策略及销售能力等方面的潜在问题。
1.1.4.2.4注意事项
◆为确保风险控制与风险监管的有效执行,制定的风险控制措施应清晰描述时间、人员、活动,不要简单描述“加班”等概述性风险控制策略;
◆在项目实施过程中如有需与客户协商的重要活动(例如产品交付、系统割接等),项目经理/项目软件经理必须会同客户代表在实施前进行风险分析,以保证该项活动的顺利实施;
◆《项目风险管理表》建立以及每次更新后,项目经理/项目软件经理必须将风险管理的相关信息以适当形式告知项目组成员,并负责将《项目风险管理表》发送给全部项目组成员及公司受风险影响的各级相关人员,确保风险管理过程的全员参与。
1.1.4.3风险控制
1.1.4.3.1目的
在项目开发/实施阶段对已识别的风险实施风险控制,同时定期或事件触发更新《项目风险管理表》。
1.1.4.3.2过程活动
◆项目经理/项目软件经理组织项目组成员按照已确定的风险控制措施实施风险控制;
◆项目经理/项目软件经理负责风险控制措施实施后按照实际执行情况完善《项目风险管理表》的“控制措施”列信息。
1.1.4.4风险监管
1.1.4.4.1目的
相关人员在项目进行过程中对风险进行监管,以保证风险控制措施的确实实施。
同时积累数据,验证风险识别的全面性,控制措施的有效性,为其他项目的风险管理提供有用的信息。
1.1.4.4.2过程活动
◆项目的项目质量保证人员或部门项目管理人员根据已制定的控制措施对项目风险进行跟踪,将对控制措施的验证信息实时填写入《项目风险管理表》;
◆部门项目管理人员在项目总结阶段,以完成的《项目风险管理表》为依据,协同项目经理/项目软件经理对该项目进行过程中的风险进行整理总结,填写“项目风险总结分析”,负责对组织文件的“风险示例”进行更新。
1.1.4.5可能存在的风险及控制策略
风险类型
序号
风险描述
建议风险控制策略
项目风险
1
无法遵循组织标准软件过程,卤莽编码
加强过程培训/SQA人员加强监控力度与频度/项目负责人积极配合SQAL工作
2
过分教条坚持组织标准软件过程,过多耗时
认真制定、评审项目“裁剪工作表”/SQA人员协助项目负责人在项目进行过程中调整项目定义的软件过程
3
开发了额外不必要的功能(需求镀金)
确定需求优先级并加强评审/采用阶段交付的软件生命期模型/使用抛弃型原型策略进一步明确需求/制定弹性进度计划
4
项目进行过程中需求蔓延
使用增量开发的生命期模型/需求优先级确定/制定弹性计划
5
计划过于乐观
使用多种方法进行估计/与领导层或客户进行协商/主动加班
6
项目组人员缺少或能力不足
特定阶段适当增加人员/项目策划与设计借用资深人员/加强培训
7
项目周期过长,影响项目组成员情绪,效率低下
缩短开发周期/制定相应激励政策/鼓励创新,提高人员积极性
8
开发、测试的环境及工具无法及时到位
合理安排进度计划/加强与供应方的沟通/寻找内部替代资源
9
多部门配合,协调各部门关系困难
明确项目相关方网络,提前确认各部门工作计划/项目各阶段结束后将工作产品及时发送到受影响的部门和组及个人/取得领导支持
10
项目原定采用原型开发,实际开发过程中逐渐偏离原型,无法满足客户需求
项目开始前与客户说明开发模式,尽量取得配合/每次原型增量周期结束后取得客户确认/控制阶段计划以符合选定的生命期模型
11
项目实施过程中最终用户有抵触情绪
提前进行最终用户培训/争取客户领导支持/合理制定实施计划
12
设备到货不及时或设备配置有差错及漏配现象
充分分析采购供方的供应能力/合理制定采购计划/实时监控采购活动/及时进行采购验收
13
用户现场环境无法按时或难以达到实施条件
提前与客户协商/实施前做好客户环境调查/准备应急计划/完善软件设计,增强软件的可移植性
14
分包方无法按时完成计划任务
严格评审分包项目计划/按照既定计划监控项目进度/制定多套方案
15
开发人员与客户发生摩擦
加强素质教育/制定相应奖惩制度/项目负责人主动协调客户关系
技术风险
1
需求描述有二义性,开发人员理解错误
加强需求评审/每次项目组例会中加强需求问题沟通/加强客户沟通
2
使用新的技术,使用经验不足
认真评估使用新技术的预期效果/加强培训/以老带新
3
使用旧的技术,难以满足某些特定的功能/性能要求
评估特定功能、性能要求的必要性/加派资深人员/完善设计
4
开发过程中有待研究解决的技术难点
制定弹性进度计划/分包有难点的技术研发/与客户进行协商
5
代码质量低下
加强代码检查/增加额外测试/制定明确的编码规范
6
分别开发的子系统无法有效集成
设计中充分考虑各子系统的相关性/增加集成频度/及时通报问题
7
分包方提交工作产品质量无法保证
评估分包方的能力/增加阶段点监控/参与重要里程碑的前期评审
8
方案出现了错误,内置设备无法安装
加强方案评审/准备多套方案
9
设备质量不合格
加强验收环节,给予充分资源、时间安排/保留必要的验证记录
10
用户线路(包括申请的线路及综合布线)不合实施要求
提前获取用户提供的线路测试报告/专业人员提前验证以保证线路通断和参数符合要求
商业风险
1
未明确产品的使用对象,国外与国内的接受能力等
请专业人士进行评估/提前进行宣传/提前进行用户试用
2
公司整体商业策略改变,重点转移
提前申请足够资源/缩短开发周期/及时向领导层汇报项目进展
3
销售人员对待开发产品不了解,销售不利
加强销售人员培训/及时向销售人员通报产品功能集的变化/获知销售渠道以及销售关注重点
4
软件依赖政府规章,无法预测规章的改变
软件设计加强灵活性/缩短开发周期/及时了解规章变化情况/制定应急方案
5
客户领导不重视
提前进行客户领导层培训/请公司领导与客户领导协商
6
合同制订时细节不明确,或销售与用户有口头协议但未在合同中体现,无法满足客户需求
加强合同评审/请销售人员或客户代表全程介入项目/延长需求分析
时间
7
项目负责人与公司领导不合,无法获得必要资源
更换项目负责人/由部门其他负责人与公司领导商谈/提前申请充足
资源/及时向领导层汇报项目进展
8
产品开发超出预算,资金不到位
充分进行前期预算/准备后备资金/划分需求优先级以便后期裁减
9
产品使用需特定操作系统或数据库系统,用户无法配备
提前进行用户群分析/软件设计加强可移植性/捆绑其他产品/软件功能、性能上进行创新,以增加卖点
10
最终用户水平较低
提高软件的可用性/完善详细的联机帮助文档及用户手册/增加最终用户培训的次数,并评价培训效果
注:
风险示例只做项目风险管理参考,风险内容根据项目具体情况进行识别。
1.2质量管理
1.2.1目的
本文件规定了软件开发各个过程中应遵循的质量保证规范,为软件生命周期各阶段的质量保证提供依据和参考。
1.2.2范围
本文件适用于质量保证部门进行质量管理,以及项目管理人员进行项目管理的全过程。
1.2.3术语与缩略语
SQA:
软件质量保证
SQAP:
软件质量保证计划
SQAL:
软件质量保证负责人
1.2.4项目职责
●软件质量保证负责人SQAL
负责根据项目计划制定《软件质量保证计划》;在项目进行的各个阶段按照《软件质量保证计划》执行软件质量保证活动,对发现的软件问题或潜在问题以《SQA审核报告》的形式提出,并跟踪问题的解决情况直到关闭。
1.2.5管理程序
1.2.5.1软件质量保证概述
软件的质量保证贯穿于软件开发与项目管理全过程中,主要通过SQAP(软件质量保证计划),SQA审计,SQA评审,SQA工作报告来体现。
SQAP主要对软件阶段成果和过程的检查工作作整体的部署。
SQAP中应将要审计的对象(软件工作产品或阶段成果)审计的形式和步骤,将要评审的软件过程,评审的形式、步骤和频率;所需资源及时间进度等内容进行描述,同时由于项目发生变化时要及时修改更新SQAP的内容。
SQA审计主要对生产资料与阶段成果进行检查。
其具体包括三方面内容:
审计软件工作产品、审计软件工具、审计设备。
软件工作产品审计的目的是评估软件工作产品是否符合组织和项目规定的标准或指导方针,鉴别偏差、疏漏并做出报告以对其进行跟踪;软件工具的审计是根据不同项目的需要,确保软件开发过程中选用适当的软件技术和软件工具;软件设备的审计是帮助有关管理部门考虑设备的采购计划以及现有设备的资源共享问题。
SQA评审主要是对生产过程进行检查。
SQA评审的目的是评审项目活动与项目定义软件过程的一致性,确保在项目计划中定义的任务活动在项目进行过程中得以遵循。
SQA工作报告是对检查对象发现的问题,改进措施,改进情况进行总结汇报。
SQA工作报告的内容是编制《质量保证报告》,SQA应当记录对软件工作产品、软件工具、设备,软件过程的审计和评审结果,提出相应的纠正、预防措施建议。
并向受影响的部门、组和个人报告同时跟踪问题解决情况,直到所以问
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 管理