软件项目管理方案模板.docx

软件项目管理方案

23

资料内容仅供参考，如有不当或者侵权，请联系本人改正或者删除。

软件项目管理方案
项目管理

项目过程控制 项目阶段管理 项目变更 术语说明

2011
马晓海
word编辑
2011-9-6

文档信息
日期
修改章节
修改类型*
修改描述
修改人
版本
-9-7
ALL
A
撰写
董赛
V1.0

*修改类型分为 A - ADDED M - MODIFIED D – DELETED

文档编号
文档名称: 软件项目管理方案
拟制:
审核:
SQA:
批准:
文档代号:
收文:
产品版本: v1.0
抄送:

目录
1. 概述 5
1.1 编写目的 5
2. 项目管理过程 5
2.1 启动过程 5
2.2 计划过程 5
2.3 执行过程 6
2.4 控制过程 6
2.5 结束过程 7
3. 项目管理方法论 7
3.1 整体管理(Intergration Management) 7
3.2 范围管理(Range Management) 8
3.3 时间管理(Time Management) 9
3.4 成本管理(Cost Management) 9
3.5 质量管理(Quality management) 10
3.6 人力资源管理(Human Resources Management) 11
3.7 沟通管理(Communication management) 11
3.8 风险管理(Risk Management) 11
3.9 采购管理(Procurement Management) 12
4. 项目阶段管理 13
4.1 需求分析阶段 13
4.2 设计阶段 14
4.3 开发阶段 15
4.4 SIT阶段 16
4.5 UIT阶段 17
4.6 部署推广阶段 18
4.7 验收阶段 20
5. 项目沟通机制 20
6. 需求变更流程 22

1. 概述
1.1 编写目的
说明本项目规范流程化的管理方案, 包括启动过程, 计划过程, 执行过程, 控制过程, 结束过程的科学管理控制。涵盖了项目管理的九大领域: 整体管理, 范围管理, 时间管理, 成本管理, 质量管理, 人力资源管理, 沟通管理, 风险管理, 采购管理。
预期读者: 项目经理、 需求设计者、 系统分析员和程序员。
2. 项目管理过程
2
2.1 启动过程
分析人员必须以系统科学的方式进行项目需求分析, 选择制定好的项目方案, 进行严格筛选和可行性分析和研究等文档。
2.2 计划过程
在项目计划的过程中, 要用计划应对变化, 明确的预防措施和补救措施, 制定项目标准和规章制度, 要避免计划不现实, 不切实际, 过于繁琐等可能造成计划无效和项目失控等因素。
Ø 项目经理根据需求分析做出项目成本预算, 进度预算, 定义项目质量标准, 风险组织和项目综合计划书等, 要求项目控制和执行人员必须高度明确项目目标, 确定项目范围, 并以该目标与项目利益相关者(客户)取得一致意见;
Ø 与项目组织(开发团队)就这一目标进行给沟通交流, 一起制定出实现该项目目标的各项具体计划和集成计划, 并成功的完成目标所应做的工作达成共识;
Ø 定义明细的进度计划甘特图, 任务分配矩阵, 资源计划分配图;
Ø 把计划过程提交给公司领导, 并作详细汇报; 获得项目计划的批准。
2.3 执行过程
Ø 项目实施动员大会, 发布项目信息;
Ø 分析和设计程序的模型, 要求统一建模, 统一规划模型, 模型必须与现实情况紧密相连;
Ø 实时跟踪项目进展, 实施阶段性评审, 严格遵守项目开发准则(1分阶段的生命周期计划严格管理, 2坚持进行阶段评审, 3实行严格的产品控制, 4采纳现代成熟的程序设计技术, 5结果应能清楚的审查, 6开发小组的人员应少而精, 7承认不断改进软件工程实践的必要性);
2.4 控制过程
项目的控制和执行处在同一时间段, 项目控制遵循以下几点:
Ø 客户需求控制
在项目的执行过程中, 可能会出现客户需求的变动, 尽量控制可能会出现的情况, 和客户进行沟通, 找到合适的解决方案;
Ø 人员管理控制
对任务进行跟踪, 避免”镀金”, 所谓镀金是项目开发人员下意识的想做的更完美, 擅自增加程序功能, 结果导致扩大范围和需求脱离, 或者是开发人员误解任务意图等问题。
增强人员之间的沟通, 遇到问题及时汇报, 避免各个模块组合困难, 中间出现问题, 无人过问, 导致工作停滞。
针对技术经验不同的程序员, 安排相关性强的工作, 充分授权项目组成员, 鼓励项目组成员完成一些有挑战性的工作, 提高开发技能, 鼓舞开发人员士气。
利用资源直方图反应开发人员的工作时间合理性。
Ø 项目控制管理
成本, 目标, 进度为项目的管理核心, 必须以严格的图标或记录等手段来统计成本, 目标, 进度, 根据统计数据进行SWOT分析, 经过决策树得到最佳方案, 时时提前预警风险应对措施。对测试数据进行备份。
2.5 结束过程
预定将项目收尾准备更多的时间, 以图更加有条不紊, 将项目资料和开发数据妥善保存以备后鉴。集成测试和调试必须要有测试数据报告。所有参与开发人员做项目总结。
3. 项目管理方法论
1
2
3
3.1 整体管理(Intergration Management)
1. 项目章程(Porject Charter)
项目章程是正式启动项目的文件, 明确项目的目标, 一般可行性研究报告之后由高级管理层签发, 作为项目正式启动的依据。
2. 项目范围说明书(Scope Statement)
项目范围书明确项目的范围。
3. 项目管理计划(Project Management Plan)
项目管理计划是明确”如何完成项目”的文档集合, 包括多个子计划文件, 如: 开发里程碑、 质量计划等。
4. 头脑风暴(Brain Storm)
制定项目计划是一种集思广益的方法, 组织小组成员在会议室放开思维讨论问题的解决问题的方案或者说出项目中的活动, 要收集数据进行处理。在问题没有明确的解决方案或者存在多种潜在方案的时候, 能够使用头脑风暴。
5. 预防措施和补救措施(prevent measure & remedial measures)
预防措施和补救措施针对问题的缺陷, 防范在先, 补救措施有时候也能够叫作纠正措施。一种是积极的行为, 一种是被动的行为。
6. 标准和规章制度(Standards & Rules And Regulations)
标准是在重复性的活动中构成的最佳规则, 有的时候它是可选的, 不一定是强制执行。规章制度是强制要求的规则, 是强制执行的。
3.2 范围管理(Range Management)
1. 工作分解结构(Work Breakdown Structure,WBS)
WBS是项目管理中的重要元素, 是对项目工作的进一步细分, 归纳和定义项目的整个范围。
2. 职责分配矩阵(Responsibiity Assign Martrix, RAM)
职责分配矩阵是把WBS的工作与部门或者责任人联系起来的一张图表, 主要用来进行工作的分配。
3.3 时间管理(Time Management)
1. 里程碑(Milestone)和里程碑图(Milestone Chart)
里程碑是项目的关键点, 是系统分析完成、 核心模块编码完成或者是系统测试完成的时间点。
2. 甘特图(Gantt Chart)
甘特图也叫横道图(业务分析师r Chart), 用横道表示主要活动或者阶段的开始和结束时间。比里程碑含有更多的信息, 能够用来做进度计划审核和确认, 也能够用来与客户和上级领导沟通汇报。
3. 项目网络图(Network Chart)
项目网络图是详细的活动安排, 包含了活动之间的前后和依赖关系, 一般用单代号网络图(PDM)和双代号网络图(ADM)来表示。二者的区别是: PDM采用方框架表示活动, 用箭线连接活动; ADM用箭线表示活动并在节点处将其连接起来。
4. 关键路径(Critical Path)
在项目的进度表或者网络图中, 存在多条路线通往项目的终点, 其中最长的路线称之为关键路径。
5. 进度压缩和进度压缩方法(Progress Compression)
在项目进度延迟的情况下, 要进行进度压缩以加快项目的进行。进度压缩分为两种方法, 一是赶工(Crashing), 另一种是快速跟进(Fast Tracking)。
3.4 成本管理(Cost Management)
1. 成本估算(Cost Estimating)
成本估算是指每项活动的费用, 根据以往的历史数据、 使用数学或者是统计技术。
活动费用的估算的准确度根据需要不同。在项目的初期, 是粗略的、 大概的; 到计划阶段更为详细; 到进行费用分配的时候需要精确估算。
成本估算的方法有类比估算和自下而上的估算。类比估算是以过去类似的项目活动为参照, 自下而上的估算则以单个活动或者工作分解结构要素进行独立估算, 然后分别汇总得到更高层次的估算值。
2. 成本预算(Cost Budgeting)
成本预算是将单个计划活动或者工作包的费用进行汇总, 得到总体费用。预算的结果是要得到一个基准的费用。
3. 挣值管理(Earned Value)
进度或者是成本实际上不会按照计划进行, 随项目的进行会产生进度延迟或者成本超支。只知道计划值、 实际值是不够的, 无法评估到项目的状况, 因为不知道实际完成了多少。例如成本虽然在该时间段超支, 却提前完成了许多工作, 我们不能肯定这是个坏事。
综合考虑计划值(PV)、 实际值(AC)和挣值(EV), 是挣值管理的基本思想。
成本偏差(CV)=挣值-实际值=EV-AC
进度偏差(SV)= 挣值-计划值=EV-PV
3.5 质量管理(Quality management)
1. 统计抽样(Statistical sampling)
统计抽样是从目标群体中抽取部分或者是全部样本进行检查, 以得到质量数据。
2. 因果图(Causal map)
因果图是质量统计的一种图标技术, 也叫石川图或者鱼骨刺图, 用来分析质量问题或者偏差产生的原因, 比较直观的显示各项因素与潜在问题和结果之间的关系。
3. 帕累托图(Pareto plans)
帕累托图也是质量统计的图示技术, 是按照发生频率大小顺序绘制的直方图, 表示有多少结果是由已确认的原因造成的。帕累托图帕累托法则一脉相承, 即数量较少的因素是造成绝大多数问题的原因, 即八二原理, 80%的问题是由20%的原因造成的。
3.6 人力资源管理(Human Resources Management)
1. 资源直方图(Resources histogram)
使用资源直方图表示项目中的资源被使用情况, 用它来反应人员工作的时间。
2. 冲突和冲突管理(Conflict management)
项目中存在各种冲突是很正常的, 冲突的常见来源包括资源匮乏、 工作安排和工作风格。
解决冲突有多种策略, 一般会有”输-输”、 ”输-赢”和”双赢”的策略。
3.7 沟通管理(Communication management)
1. 制定项目沟通计划和制度, 包括方式和频率
2. 领导进行项目沟通活动
3. 评估沟通效率, 进行必要的调整
3.8 风险管理(Risk Management)
1. SWOT分析(Strengths, Weaknesses, Opportunities, Threats)
优势、 弱点、 机会与威胁分析, 是针对具体事情或者风险进行多角度、 全方位的权衡。
2. 决策树(Decision Tree)
决策树是决策支持的一种技术方法, 把不同的决策分支绘制在图表上进行统一考虑。根据”预期收益”与”可能性”的乘积得到分支的决策值, 然后累计分支决策值得到最佳决策。
3. 风险应对措施(Risk of response measures)
根据风险类型、 概率和影响的不同, 需要定制应正确风险策略, 风险应对策略一般有规避、 转嫁和减轻3 种措施。
Ø 风险规避是指采取措施、 避免风险, 例如开发进度很紧, 不能按时完成的情况下, 减少程序或者是系统的功能就是风险规避的举措。
Ø 风险转嫁是把风险转移到第三方, 不将其消除, 例如投保就是典型的风险转嫁。
Ø 风险减轻是指提前采取措施将风险降低到能够接收的范围, 例如经过实地考察, 选择可靠的外包方, 或者经过系统的原型演示, 都能够降低未知的风险。
3.9 采购管理(Procurement Management)
1. 采购文件(Procurement documents)
采购文件是买方发出的, 说明外包产品的要求, 用来获得卖方的报价或者建议书。采购文件在不同的恒业或者领域内都有特定的词汇, 有投标邀请书(IFB)、 征求建议书(RFP)、 询价书(RFQ)、 招标通知及洽谈邀请等。
2. 建议书(Recommendation)
建议书是由卖方制定的文件, 阐述卖方提供的产品或者服务的能力或者意愿, 是对采购文件的答复, ”标书”就是建议书的一种。
4. 项目阶段管理
4
4.1 需求分析阶段
Ø 阶段目标
了解业务现状, 分析业务需求, 制定解决方案;
Ø 关键任务及角色
任务
时间
客户
柯莱特
需求调研、 分析

业务部门
关键客户
项目经理
业务分析师
初审

业务部门
关键客户
项目经理
业务分析师
终审

业务部门负责人
需求负责人
项目经理
需求方确认

项目经理或需求负责人
项目经理

Ø 主要产物
ü 调研计划;
ü 差异分析;
ü 需求说明书;
ü 问题表;
ü 需求跟踪阵列;
ü 需求确认单;
Ø 风险控制
ü 客户参与程度
n 保证关键人员在需求阶段充分的参与度;
n 建立多种沟通方式: 面对面、 电话, 邮件;
ü 解决方案
n 派驻资深BI顾问, 并保持核心队伍的稳定性;
n 充分挖掘客户需求背后的业务价值, 针对客户的需求点, 设计出为各业务部门、 各产品线带来实际价值的多赢的管理/业务流程;
ü 需求实现
n 柯莱特开发小组提前进行POC研究;
n 需求理解上的Gap;
n 采用流程示意、 原型界面等方式描述需求

4.2 设计阶段
Ø 阶段目标
按照需求说明书, 对需求进行系统实现的设计, 为开发阶段提供参考
Ø 关键任务及角色
任务
时间
客户
柯莱特
开发环境到位

项目经理
技术分析师
系统方案评审

项目经理
项目经理
业务分析师
集成方案评审

项目经理
项目经理\集成leader

Ø 主要产物
ü 设计说明书;
Ø 风险控制
ü 设计方案质量
架构师设计评审, 确保设计方案的正确性且符合系统设计原则;
ü 设计方案与需求的匹配度
业务分析人员参与设计评审, 确保设计满足需求的要求;
ü 技术风险
n 柯莱特提前进行POC研究;
n 提交柯莱特技术指导委员会;
4.3 开发阶段
Ø 阶段目标
按照设计文档, 在系统开发中进行实现;
Ø 关键任务及角色
任务
时间
客户
柯莱特
系统测试环境到位

项目经理
技术分析师
UTA测试环境到位

项目经理
技术分析师

Ø 主要产物
ü 源代码级成果;
Ø 风险控制
ü 开发的质量、 开发人员的变化
n 按照《柯莱特开发规范》统一的开发原则;
n 单元测试;
n 交差检查;
4.4 SIT阶段
Ø 阶段目标
按照测试用例, 对系统进行内部测试, 保证系统满足需求说明书;
Ø 关键任务及角色
任务
时间
客户
柯莱特
测试用例评审

项目经理
项目经理

Ø 主要产物
ü 测试计划;
ü 测试用例;
Ø 风险控制
ü 测试质量
n 测试用例经过业务分析师的严格审核;
n 引入企业级测试驱动方法论( ATDD) , 在开发阶段保证单元测试/集成测试的质量, 提高开发质量;
n 测试人员参与需求过程;
ü 性能风险
在需求调研, 设计阶段予以性能考虑, 对系统性能测试贯穿整个开发过程;
4.5 UIT阶段
Ø 阶段目标
用户进行系统测试, 验证系统是否满足其业务需求及业务目标;
Ø 关键任务
任务
时间
客户
柯莱特
用户培训

项目经理
业务部门
关键用户
项目经理
业务分析师
UAT

项目经理
业务部门
关键用户
项目经理
业务分析师

Ø 主要产物
ü 测试计划
ü 测试用例
ü 测试报告
ü 缺陷报告
Ø 风险控制
ü 用户参与程度不够, 会造成项目延期风险
n 在项目计划中予以明确, 并确保最终的执行
n 因操作不熟练, 对系统产生排斥
ü 多种的培训形式:
n 讲解
n 课件
n 业务分析师、 系统测试人员参与UAT, 协助客户一起进行UAT

4.6 部署推广阶段
Ø 阶段目标
挑选几个代表性分支或代表性产品线;
Ø 关键任务
任务
时间
客户
柯莱特
挑选分支用户/
产品线用户培训

项目经理
分支业务部门
Key User
项目经理
业务分析师
系统上线

项目经理
总监\相关领导
项目经理
技术分析师
集成组
其它分支/
产品线用户培训

项目经理
分支业务部门
Key User

系统上线

项目经理
技术分析师
集成组

Ø 主要产物
ü 部署计划;
ü 安装手册;
ü 用户手册;
ü 维护手册;
ü 试运行报告;
Ø 风险控制
ü 一次上线风险
n 分多次推广;
n 培训客户的关键人员, 协助客户进行推广培训;
4.7 验收阶段
Ø 阶段目标
完成项目的验收工作;
Ø 关键任务
任务
时间
客户
柯莱特
验收评审

评审专家
项目经理
业务部门
项目经理
销售经理
验收确认

项目经理
销售经理

Ø 主要产物
ü 验收计划;
ü 项目验收评审报告;
ü 项目验收单;
Ø 风险控制
ü 用户参与程度不够, 会造成项目验收延期风险
n 在项目计划中予以明确, 并确保最终的执行;
5. 项目沟通机制
类型
沟通内容
参与人员
方式
每日项目例会
每日问题汇总与讨论
评审当天工作完成情况及风险
明确第二天的工作计划
及时跟踪项目进度
柯莱特项目小组成员
每日17: 00
会议
每周项目例会
周进度跟踪
汇报本周工作进展
下周计划讨论和制定
讨论项目风险和问题
柯莱特PM
柯莱特各小组Leader
每周五9: 00
会议
每周PMO例会
周进度跟踪
汇报本周工作进展和下周计划
审视项目风险和问题
阶段性成果汇报
PMO
每周一9: 00
会议
专题会
围绕某些专题进行讨论
专题相关人员
按需
日常交流
文档输出、 问题、 评审等
相关人员
按需, 会议、 配置库

6. 需求变更流程