计算机网络应用项目开发计划模板Word文档格式.docx
《计算机网络应用项目开发计划模板Word文档格式.docx》由会员分享，可在线阅读，更多相关《计算机网络应用项目开发计划模板Word文档格式.docx（14页珍藏版）》请在冰豆网上搜索。
变更人
批准日期
批准人
V1.0
C
创建
V1.1
M
文档编号去掉版本号
2020-4-17
*变化状态：
C――创建，A——增加，M——修改，D——删除
备注：
1、对模版【】括号内的文字为提示如何填写，在形成正式文档时要求去掉这些文字。
1.概述
2.项目概述
【简要说明此项目的目的、范围与目标。
】
3.术语定义
【说明本计划中用到的各种术语。
4.项目干系人列表
角色
责任描述
姓名
电话号码
客户经理
联系客户，与客户进行沟通和承诺。
项目经理
项目经理履行的任务是对整个项目的总体业务负责；
项目经理是指导、控制、管理和调整项目进行构造软件或硬件/软件系统工作的个人，项目经理是最终向客户负责的个人,负责需求管理活动的监控。
高层经理
获得对项目的承诺和支持，以及对项目的总体控制。
客户代表
需求的提出者，也是软件开发的约定者。
用户代表
软件产品的使用者，有时与客户是同一对象。
需求开发人员
对客户的需求进行收集，然后分析成归于软件的需求。
需求管理人员
对需求的管理是要收集需求的变更和变更的理由，并且维持对原有需求和所有产品和产品组件需求的双向跟踪。
开发人员
根据需求，通过设计和编码实现软件的需求。
测试人员
对软件产品进行测试，保证满足软件设计要求和客户的需求。
QA人员
在整个软件生命周期中，监督和检验软件过程与标准的符合性以及软件产品生产规范的符合性。
CM人员
在整个软件生命周期中，控制软件产品的状态和一致性，确保产品的有序变更和发布。
培训人员
负责对项目人员进行相应技能的培训。
组间协调人员
负责协调不同性质的组之间的工作，并与其他小组代表一起监控和协调各项技术和管理、支持工作。
系统管理员
数据库/运行/网络支持。
CCB
管理项目软件基线的委员会。
（主席）
【注意：
一个人可以担任多个角色，如是项目经理、需求人员、开发人员和CCB主席。
5.提交客户的工作产品
【描述对客户作出的承诺（可参考项目合同约定），在各个阶段要求交付的产品、提交时间及其公司的负责人员。
交付的产品分解程可管理的大小粒度。
“产品的形式”分为程序、文档、服务三类，根据交付产品的情况填写。
交付阶段
交付产品的名称
产品的形式
交付日期
负责人
6.项目策划
7.软件生命周期模型定义
【描述该项目采用的软件生命周期模型，可参考《软件生命周期模型描述》中定义的模型，对选用此模型的原因进行简要描述。
模型选用：
原因：
8.项目定义软件过程
参见《XX项目已定义过程》
9.质量目标
10.WBS
【描述项目的里程碑WBS】
《XX项目软件开发明细计划》
《XX项目软件估计WBS&
关键路径》
11.风险管理
12.风险来源
风险的来源参见《风险管理指南》
13.风险分类
风险的类别分为以下几大类：
软件工程类：
需求、设计、实现、测试、部署、维护
开发环境类：
开发过程、开发环境、管理过程、管理方法、工作环境
管理类：
资源、合同、项目接口
14.风险参数
评估风险的参数包括：
风险的可能性（风险发生的概率）；
风险的后果（风险发生的影响和严重程度）；
触发管理活动的阈值：
即为了缓解风险所需要的行动周期。
每个项目根据项目的特点，选择适合本项目使用的风险参数，主要是指定本项目使用的风险属性评价级别。
如果项目需要特定的级别或者特定的具体参数，则需要特别说明和批准。
风险影响严重程度
影响程度
影响
量化值
高
导致产品或项目失败或造成严重危害。
例如：
进度拖延>
15%
费用超支>
20%
最终用户无法使用
人员流失严重
9
中
对产品或项目造成一些麻烦。
进度拖延10%--15%
费用超支10%--20%
用变通办法对付质量问题
士气低落
6
低
对产品或项目影响不大
3
风险发生概率
可能性百分比（p）
发生可能性
描述
P≥75%
很可能
75%>
P≥25%
可能
2
25%>
P
不太可能
1
风险发生时间
准则
发生时间
解决时间
近期
本阶段发生
本阶段准备
中期
下阶段发生
4
远期
下阶段后发生
本阶段或下阶段准备
15.风险管理策略
风险处理采取以下几种方法：
接受风险：
不做任何风险管理工作，当出现风险时把它当作问题处理，不再花费额外的资源来管理风险。
风险监督：
监督风险及其属性，以便在影响、发生概率、时间以及其它方面出现重要变更时提出早期警告。
风险缓解：
通过减小其影响和其发生的概率、改变时间等方面来消除或减弱风险。
需要制定相应的风险缓解计划。
风险转移：
重新计划、分配需求、设计、或分配资源，以消除或降低风险的发生概率和影响。
风险应急：
如果风险缓解计划失败了，应急计划将作为第二方案来使用。
16.决策分析
在进行关乎系统体系结构设计工作时要有一套以上设计方案，每套方案对系统关键点进行不同设计，利用决策分析和决定过程确定方案。
当项目中出现如下情况时，将利用决策分析和决定过程确定方案：
项目严重拖期，已拖期超过整体进度的20%；
产品尚未达到质量目标或者客户需求，是否交付或者发布。
17.数据管理
参见项目《【项目名称】数据管理表》。
18.软件估计
19.估计汇总
【描述项目估计汇总】
参见《XX软件估计书》
20.进度估计
【描述项目里程碑进度】
阶段
计划起日
计划止日
备注
21.软件工程设备和支持工具估计
软件工程设备和支持工具名称
数量
获得方式
预计使用日期
22.关键计算机资源估计
关键计算机资源名称
23.需求管理计划
[说明需求管理使用的资源，角色与责任，需求变更、需求跟踪计划，判断项目工作与需求不一致的准则和纠正流程]
需求管理人员：
需求管理使用的工具：
提供需求方角色与职责：
开发需求方角色与职责：
需求变更流程：
需求跟踪流程：
项目工作产品与需求不一致的准则和纠正流程：
24.沟通计划
[列出整个生命周期内的不同阶段、与客户、不同组、组内中需要沟通和协调活动等事项（预期的产品交付即组间产品交换、需要通知其他受影响组的决定如初步的技术方案即通讯交流）、负责人、参加组和（或）个人、议程（如果是会会议形式，内容包括：
客户的需求、技术问题、关键依懒关系、项目整体状态）、计划日期、计划地点（如果适用）、方式/工具（正式会议、电子交流会议、电子邮件、配置库系统、缺陷跟踪系统等），达到协调项目相关组和个人的活动和交流。
利用下表（可以根据具体情况进行调整）列出]
25.制定与客户的沟通计划
【说明与客户的沟通计划。
序号
活动概述
活动协调负责人
客户的参与人员
方式/工具
协调时间
26.制定与其它小组的沟通计划
【如项目在项目进度、合同和技术、各小组的职责方面。
如本项目采用了其他项目组的产品，请填写此章节。
各小组的参与人员
27.制定组内沟通计划
【说明组内的沟通计划】
组内参与人员
28.明确与客户、其他组间关键依赖关系
拟提供的产品项
提供方负责人
提交日期
使用日期
接受方负责人
验收标准
29.团队建设与维护计划
要求
已到位人员情况
未到位人员
资源占用起止时间
技术
技能
人员
当前技能
团队成员如有增减需要，须向部门经理汇报，由部门经理与项目经理协商确定增减的人员，项目团队的维护及变动情况，在《项目周报》中进行跟踪。
30.培训计划
【项目级培训可以在参见《项目培训计划》。
详见OT培训管理。
参见《【项目名称】项目培训计划》。
31.软件质量保证计划
参见《【项目名称】软件质量保证计划》。
32.配置管理计划
参见《【项目名称】软件配置管理计划》。
33.产品验证计划之同行评审计划
【项目人员对软件生命周期中创建的工作产品可以有选择性的进行验证，以验证是否符合适当的标准，是否满足需求。
有关软件工作产品可以参见软件开发计划（SDP）、SCM计划和软件测试计划（STP）。
在下面表格中定义了要进行验证的工作产品及参照的标准。
以下的说明应该与本项目软件过程定义裁剪表中一致。
验证产品一览表
#
验证对象
验证时间/阶段
验证方法
验证人员
验证标准
1
软件项目计划及子计划（测试、配置管理、质量保证、度量等）
项目策划
公司正式评审
公司评审委员会
公司
升级会员 