项目管理.docx
- 文档编号:5249406
- 上传时间:2022-12-14
- 格式:DOCX
- 页数:33
- 大小:145.51KB
项目管理.docx
《项目管理.docx》由会员分享,可在线阅读,更多相关《项目管理.docx(33页珍藏版)》请在冰豆网上搜索。
项目管理
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应当记录对软件工作产品、软件工具、设备,软件过程的审计和评审结果,提出相应的纠正、预防措施建议。
并向受影响的部门、组和个人报告同时跟踪问题解决情况,直到所以问题得以解决。
1.2.5.2编制软件质量保证计划SQAP
在项目的策划阶段,项目SQAL负责制定SQAP。
SQAL要依照项目的实际情况,在项目经理/项目软件经理协助下识别项目关键点,确定SQA任务,编写SQAP,参见《软件质量保证计划》模板。
按照《评审规程》的规定,对SQAP进行适当级别、形式的评审。
在项目的SQAP的执行过程中,由于项目的变化,SQA的任务和计划执行的时间等会有所更改。
SQAL须在项目进行过程中对SQAP进行相应调整,重新评审。
1.2.5.3SQA审计
SQA审计工作内容说明
审计类型
审计目的
审计对象(内容标准,适用性)
审计结果
备注
软件工作产品
评估软件产品是否符合组织和项目规定的规程与标准,鉴别偏差、疏漏并做出报告以对其进行跟踪。
前期策划文档
需求文档
项目计划
设计文档
测试文档
编码实现
交付产品
配置管理文档(软件项目配置状态报告、配置库结构层次图)
其它软件工作产品
软件工具
确保项目选用适当的软件开发技术和软件工具
SQA要对现有的与计划选用的用于软件开发和技术支撑的软件工具进行评估。
对软件工具的评估要同时考虑其适用性与可行性。
适用性:
首先考虑软件工具的功能是否满足项目的需要,二要考虑软件工具所具有的功能是不是项目所需要的。
可行性:
确定技术可行性以及所需计算机资源的可用性。
设备
确保项目选用适当的设备
SQA要对现有的与计划选用的设备进行评估。
适用性:
主要是通过考查提供的装备是否能够满足软件开发和技术支撑的要求以评定其适用性。
资源共享:
从组织的范围考虑资源共享问题。
采购计划:
帮助管理部门综合考虑采购计划。
1.2.5.4SQA评审
SQA评审的目的是评审项目活动与项目定义软件过程的一致性,确保项目“裁剪工作表”及“项目计划”中定义的任务活动在项目进行过程中得以遵循。
SQA评审的具体评审任务参见“软件开发过程”的评审。
SQA评审工作内容说明
评审类型
评审目的
评审内容(过程是否与计划中相对应)
评审结果
备注
产品策划过程
在产品项目启动与策划阶段,SQAL协助并参与质量策划。
确保项目《软件开发裁剪工作表》的建立与评审。
确保项目立项与可行性分析阶段准确定义产品,明确软件范围,项目的各项限制以及支持条件。
确保项目启动阶段以《项目启动计划》为依据实施需求调研活动,需求文档经评审和确认,变更得到有效控制。
确保《项目开发计划》的编制与评审符合质量管理体系的要求,并符合项目的实际需要。
软件开发过程
评审设计与实现过程的活动,保证其符合《软件开发计划》和相关过程与规范
确保设计经评审,变更得到有效控制。
编码实现有确定的规范与标准,进行代码检查与单元测试。
建立项目级的配置管理
评审设计与编码实现过程的各项活动符合相应的过程与规范。
确保测试过程中的阶段划分以及测试范围的界定。
评审软件测试阶段的各项活动符合相应的过程与规范。
软件交付、实施、验收、维护过程
评审软件产品/项目的交付、实施
、验收、维护等活动符合相关过程与规范
合同项目系统集成过程中可考虑不同特点与需求可建立《系统集成裁剪工作表》裁剪相应的活动。
确保系统集成过程中形成的各种计划与方案进行了正式的评审并得到客户的确认。
评审各项活动符合相应的过程与规范。
对重要的工作产品取得了客户的确认。
项目风险管理
保证风险管理的一系列活动符合有关的过程、规程和标准
保证项目的风险分析、管理、总结的全部过程活动符合《风险管理规程》的要求。
项目配置管理
保证配置管理的一系列活动符合有关的过程、规程和标准
保证配置管理策划、配置标识活动、配置状态记录以及版本的控制符合《配置管理规范》的要求。
评审
保证需要的评审得到执行
保证软件生命周期中需要评审的等级和形式已在计划中明确,并得到执行,且评审的进行符合有关的规程和标准,有关评审的分类和详细内容请参考《评审规程》。
1.2.5.5SQA评审报告
SQA应当记录对软件工作产品、软件工具、设备,软件过程的审计和评审结果,提出相应的纠正、预防措施建议,填写《质量保证报告》并向受影响的部门、组和个人报告。
1.3配置管理
1.3.1目的
本文件规定了项目进行过程中配置管理活动的流程以及组织对配置管理的具体要求。
公司项目过程中的配置活动必须以本文件的规定进行实施配置管理。
1.3.2范围
本文件适用于公司项目全过程中的软件配置活动,包括项目的配置计划,配置评审,配置实施,配置变更等等。
1.3.3术语
配置项:
项目开发或系统集成实施过程中所需要或所产生的软件、硬件、工具、释放产品、文档,包括基准配置项与非基准配置项。
基准配置项:
通过正式评审成为下一步开发或实施基础的配置项,只有通过规范要求的变更控制程序才能被更改。
更改:
配置项的变更与更改统称为更改。
CAR(ConfigurationAuditReport):
配置审计报告
1.3.4项目职责
●配置管理负责人(CML)
负责制定配置管理计划,并在项目进行过程中按照计划执行配置管理活动,实时更新项目的“配置状态报告”和《配置库结构层次图》,并向所有受影响的项目组和个儿通报当前配置管理状态。
●软件质量保证负责人(SQAL)
负责根据《软件质量保证计划》的安排实时跟踪项目软件配置管理的实施情况;参与配置审计并跟踪纠正/预防措施的执行情况直到问题关闭。
●项目经理/项目软件经理(PM/PSM)
负责协调配置管理活动实施,协同配置管理负责人管理项目配置库;参与配置审计,会同项目相关人员实施确定的纠正/预防措施。
1.3.5管理程序
1.3.5.1配置管理中的阶段划分
根据配置管理过程中不同时期不同侧重点,配置管理活动划分为以下几个阶段:
(1)配置管理策划阶段;
(2)配置管理实施阶段;
(3)配置库结构层次变更;
(4)软件基准变更;
(5)配置审计;
(6)配置备份
1.3.5.2配置管理策划与计划
通常情况下,在项目产品策划阶段制定配置管理计划。
配置管理计划一般包含人员职责,配置管理软硬件资源描述,配置项描述,基准配置项描述,项目成员的操作权限划分以及备份方案等。
配置管理计划的制定由软件配置管理负责人在开发策划阶段根据项目经理/项目软件经理的任务分解及进度安排情况制定。
具体内容可参照《配置管理计划》模板和《配置库结构层次图》。
1.3.6配置库建立
1.3.6.1配置管理工具
常见的配置管理工具有微软公司的Vss,IBM的ClearCase以及Cvs等。
公司常规软件项目产品开发所使用的开发工具为Vs2003,由与Vs2003与Vss集成比较好,所以公司的配置管理工具采用Vss。
1.3.6.2配置库结构
项目立项后,配置管理负责人即可根据评审后的《配置库层次结构图》建立项目配置库,为保证配置项目录的顺序可在目录名前加上序号进行确认。
1.3.6.3配置库存取权限控制
配置管理负责人按照项目计划并和项目经理充分沟通的情况下来设定项目组及有关人员对配置库的存取控制,并且负责在项目进行中维护配置库的存取权限。
1.3.6.4配置库文件存取时间控制
对配置库进行操作的人员,对公共部分的文件“Checkout”和“Checkin”的时间间隔不能过长,以方便其他人进行共享操作。
通常情况下在配置管理策划过程中应明确项目文档、需实时更新的各种记录以及源代码、可执行程序的操作间隔时间,以保证查阅人员可以及时从配置库中获取最新信息。
配置审计过程中可将文件存取时间作为审计内容之一。
1.3.7配置项标识
开发过程中要标识的配置项主要包括以下几部分:
1)开发环境与测试环境:
软件工具、硬件设备等;
2)开发工具:
自动设计工具、测试工具、维护工具等;
3)项目文档:
立项建议报告、可行性分析报告、项目计划、软件需求规格说明书、任务分解书、质量保证计划、系统设计报告、测试文档、技术报告、项目总结报告、系统集成方案、交付和安装记录等;
4)质量记录:
各类评审记录和表格文档,如《项目任务书》、《变更控制报告》、《软件需求变更记录》等;
5)提交产品:
源代码、可执行程序、联机帮助、用户手册等。
标识要求
1)在开发与实施过程中项目组人员提交的文档,按照《标识规范》进行标识;
2)合同有明确标识和追踪要求时,按合同要求进行标识,以保证满足合同的追踪要求;
3)外购产品使用原有标识;
4)在《标识规范》中没有明确要求的项目进行过程中形成的中间文档,在纳入配置前应加以唯一标识,文档类别代号可自行采用合适的英文缩写。
1.3.8配置控制
1.3.8.1配置项和软件基准的存储控制
配置项的存储
在项目立项后,投标书、方案等市场前期策划的文档及相应评审记录由配置管理负责人从市场人员处获得放入市场前期策划阶段子目录下进行保存;启动阶段的技术和表格文档及相应的评审记录等由项目组和配置管理负责人放在配置库的启动阶段子目录下进行管理和控制;进入实施阶段,项目组人员按照配置管理计划及时提交配置项,通过评审的配置项及评审记录,放在项目组的配置库里,同时配置管理负责人进行备份。
项目基准配置项的建立
项目组人员提交的配置项按照《评审规程》进行正式评审通过后即可作为基准配置项,并由配置管理负责人将成为基准的配置项及相应的评审记录放入配置库中,以便进行管理和控制;同时部门项目管理人员及时在部门服务器中对基准配置项进行备份。
基准建立后,需将基准内容及时在“配置状态记录”中进行记录并通知所有受影响的部门、项目组和个人。
1.3.8.2配置库结构层次的变更
根据项目的实际情况需要,项目进行过程中项目组可能需要在项目的配置库对目录结构进行增加、删减或更名操作。
CML得到配置库结构层次变更的请求后,需首先调整项目的《配置库结构层次图》,再进行相应的变更。
1.3.8.3非基准配置项的变更控制
客户或开发、实施部门要求变更非基准配置项时,配置项的提交人员可以进行任何被管理和技术需求证明是合适的修改,但必须得到所有有关人员的认可,由配置管理负责人更新“配置状态记录”。
1.3.8.4基准配置项的变更控制
变更请求的提出
客户或开发部门要求变更已建立的基准配置项、重要的项目组成员、重要的项目资源(环境、工具等)时,一定要填写《变更控制报告》。
填写《变更控制报告》时,要求进行变更请求说明和变更评估,变更评估时要考虑以下几种情况:
1)一般情况下,变更评估要考虑变更对其它配置项尤其是对当前基准配置项的影响及变更的效果;
2)如果变更较大,还要评估变更对项目进度、成本和质量的影响;
3)如果变更是为了增加需求,还要将报价单交给客户审批。
变更请求的审批与实施
按照《评审规程》的要求,部门项目管理人员组织对本次变更的评审,建议的变更请求被批准,由部门项目管理人员负责跟踪相应变更的实施。
1.3.8.5变更信息沟通
配置库中任何信息的变更实施结束后,配置管理负责人在将对配置库中内容进行调整、更新《配置库结构层次图》和相关“配置状态记录”的同时必须将变更的信息通知给所有受影响的部门、项目组和个人。
1.3.9配置状态跟踪
配置库可以通过《配置库结构层次图》和《项目配置状态报告》进行状态跟踪,要求《配置库结构层次图》和《项目配置状态报告》始终保持最新状态。
1.3.10配置审计
1.3.10.1配置审计的目的与时机
配置审计的目的在
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 管理
![提示](https://static.bdocx.com/images/bang_tan.gif)