国军产品开发计划模板.docx

《国军产品开发计划模板.docx》由会员分享，可在线阅读，更多相关《国军产品开发计划模板.docx（19页珍藏版）》请在三一办公上搜索。

1、国军产品开发计划模板软 件 开 发 计 划 书 项目名称： 项目编号： 编制人： 编制部门： 编制日期：版/修 V1.0 共8页 更改日期 文件修改页 页次 序号 更改内容 更改人 项目开发计划书 目 录 1. 范围 . 1 1.1 标识 . 1 1.2 系统概述. 1 1.3 文档概述. 1 1.4 与其他计划之间的关系 . 1 2. 引用文档 . 1 3. 策划背景概述 . 1 4. 项目开发活动的总体实施计划 . 1 4.1 软件开发过程 . 1 4.2 软件开发的总体计划 . 1 4.2.1 软件开发方法. 1 4.2.2 软件产品标准. 1 4.2.3 可重用的软件产品 . 1 4.

2、2.4 关键需求的处理. 2 4.2.5 计算机硬件资源的利用 . 2 4.2.6 决策理由的记录. 2 4.2.7 需方评审所需提问 . 2 5. 详细的软件开发活动实施计划 . 2 5.1 项目策划和监控 . 2 5.2 软件开发环境建立 . 2 5.3 系统需求分析 . 2 5.4 系统设计. 2 5.5 软件需求分析 . 2 5.6 软件设计. 2 5.7 软件实现和单元测试 . 2 5.8 软件使用准备 . 2 5.9 软件移交准备 . 3 5.10 软件验收支持 . 3 5.11 软件配置管理 . 3 5.12 软件产品的评价 . 3 5.13 软件质量保证 . 3 5.14 风险

3、管理. 3 5.15 联合评审. 3 6. 进度表和活动网络图 . 3 7. 项目组织和资源 . 4 7.1项目组织 . 4 7.2项目资源 . 4 7.3 项目依赖关系分析 . 4 6.1 技术方法和工具 . 5 6.2 项目里程碑计划 . 5 6.3 成本估计. 6 6.4 风险管理计划 . 7 8. 客户的参与 . 7 9. 培训计划 . 7 10. 计划更新策略 . 8 项目开发计划书 1. 范围 1.1 标识 本条应描述本文档所适用的系统的完整标识，适用时，包括其标识号、名称、缩略名、版本号和发布号。 1.2 系统概述 本条应概述本文档所适用的系统和软件的用途。它还应描述系统与软件的

4、一般特性;概述系统开发、运行和维护的历史；标识项目的需方、用户、开发方和保障机构等:标识当前和计划的运行现场；列出其他有关文档。 1.3 文档概述 本条应概述本文挡的用途和内容，并描述与它的使用有关的保密性方面的要求 1.4 与其他计划之间的关系 本条应描本计划和其他项目管理计划的关系。 2. 引用文档 编号 标题 编写单位 修订版 3. 策划背景概述 简要描述本项目的类型、项目的目的、范围、目标、保密性要求。 4. 项目开发活动的总体实施计划 如果项目的不同构建版或不同软件要求不同的策划，就应在下述相应条中注明这些区别。 4.1 软件开发过程 本条应描述要采用的软件开发过程，软件生存周期模型

5、的定义和选择。计划的内容应覆盖合同(或软件研制任务书)中涉及该方面要求的所有条款，应包括己标识的计划的构建版，合适时，包括各构建版的目标以及每个构建版要执行的软件开发活动。 4.2 软件开发的总体计划 4.2.1 软件开发方法 本条应描述或引用所使用的软件开发方法，包括为支持这些方法所使用的手工的和自动的工具以及规程的描述。该方法应覆盖合同(或软件研制任务书)中涉及该方面要求的所有条款。如果在本文档方法所适用的活动中，对软件开发方法有更好的描述，则可直接引用。 4.2.2 软件产品标准 本条应描述或引用在表达需求、设计、编码、测试用例、测试过程和测试结果方面要遵循的标准。这些标准应覆盖合同(或

6、软件研制任务书)中涉及该方面要求的所有条款。如果这些标准在本文档标准所适用的活动中有更好的描述，则可直接引用。 4.2.3 可重用的软件产品 采用可重用软件产品 项目开发计划书 V1.0 报告编号： 开发可重用软件产品 4.2.4 关键需求的处理 本条描述安全性保证、保密性保证和其他关键需求保证的处理所遵循的方法，并应覆盖合同(或软件研制任务书)中涉及该方面要求的所有条款。 安全性保证方法 保密性保证方法 其他保证方法 4.2.5 计算机硬件资源的利用 本条应描述分配计算机硬件资源和l监控其使用情况所遵循的方法，应覆盖合同(或软件研制任务书)中涉及该方面要求的所有条款。 4.2.6 决策理由的

7、记录 本条应描述记录决策理由所遵循的方法。在保障机构对项目作出关键决策时，这些决策理由有用。在记录决策理由的地方应对关键决策进行解释，并应覆盖合同(或软件研制任务书)中涉及该方面要求的所有条款。 4.2.7 需方评审所需提问 本条应描述为评审软件产品和活动，让需方或授权代表访问开发方和分承制方设施所遵循的方法，并应覆盖合同(或软件研制任务书)中涉及该方面要求的所有条款。 5. 详细的软件开发活动实施计划 5.1 项目策划和监控 本条应描述软件开发策划、CSCI 测试策划、系统测试策划、软件安装策划、软件移交策划、计划的跟踪和修订应遵循的途径。策划(包括重新策划)工作宜基于估计，包括:规模、工作

8、量、关键计算机资源等估计。本条也包括进度的导出方法等。 5.2 软件开发环境建立 本条应描述在建立、控制、维护软件开发环境所遵循的途径，包括：软件工程环境(含软件测试环境)、软件开发库、软件开发文件和非交付软件。 5.3 系统需求分析 本条应描述参与用户要求分析、运行方案和系统需求所遵循的途径。 5.4 系统设计 本条应描述CSCI 级设计决策、CSCI 体系结构设计和CSCI 详细设计所遵循的途径。 5.5 软件需求分析 本条应描述软件需求分析所遵循的途径。 5.6 软件设计 本条应描述CSCI 级设计决策、CSCI 体系结构设计和CSCI 详细设计所遵循的途径。 5.7 软件实现和单元测试

9、 本条应描述软件实现、单元测试的准备、单元测试的执行、修改和回归测试，以及分析和记录单元测试的结果所遵循的途径。 5.8 软件使用准备 项目开发计划书 V1.0 报告编号： 本条应描述可执行软件的准备、为用户现场准备版本说明、用户手册的准备、在用户现场的安装所遵循的途径。 5.9 软件移交准备 本条应描述可执行软件的准备、源文件的准备、为保障现场准备版本说明、已建成的CSCI 设计和有关信息的准备、系统或子系统设计说明的更新、保障手册的准备以及移交到指定的保障现场所遵循的途径。 交付工作产品名称 总体设计文档 详细设计文档 XXX项目XX总体设计方案 XXX项目XX详细设计 正规检视及评审 归

10、档/发布 归档/发布 归档/发布 归档/发布 归档/发布 归档/发布 归档/发布 文档 文档 文档 文档 文档 文档 产品描述 质量保证活动 验收标准 交付件形式 5.10 软件验收支持 本条应描述可执行软件的准备、源文件的准备、为保障现场准备版本说明、已建成的CSCI 设计和有关信息的准备、系统或子系统设计说明的更新、保障手册的准备以及移交到指定的保障现场所遵循的途径。 5.11 软件配置管理 本条应描述软件配置管理所遵循的途径，可引用软件配置管理计划。 5.12 软件产品的评价 本条应描述过程中的和最终的软件产品的评价、软件产品评价记录(包括所记录的具体条目)、软件产品评价的独立性所遵循的

11、途径。 5.13 软件质量保证 本条应描述软件质量保证所遵循的途径，可引用软件质量保证计划。 5.14 风险管理 本条应描述风险管理，包括已知风险和相应对策所遵循的途径。 5.15 联合评审 本条应分别描述联合技术评审和联合管理评审所遵循的途径。 6. 进度表和活动网络图 本章应给出: a) 进度表。该表应标识每个构建版的活动，并给出每个活动的开始时间、草稿和最终交付产品就绪的时间，其他里程碑及每个活动的完成时间。 b) 活动网络图。该图应描述活动之间的顺序关系和依赖关系，标识对项目施加最大时间限制的活动。 项目开发计划书 V1.0 报告编号： 7. 项目组织和资源 7.1项目组织 本条应描述

12、本项目要采用的组织结构，包括涉及的组织机构、机构之间的关系、每个机构执行所需活动的权限和职责。 7.2项目资源 本条应描述适用于本项目的资源，可包括: a) 人力资源，应包括: 1) 估计此项目应投入的人力(人时数) ; 2) 按职责(如:管理，软件工程，软件测试，软件配置管理，软件产品评估，软件质量 保证等)分解所投入的人力: 3) 每个人员的技术级别、地理位置和涉密程度。 b) 为适应合同(或软件研制任务书)中的工作，开发人员工作的地理位置、要使用的设施、保 密区域和设施的其他特征。 c) 合同(或软件研制任务书)中工作需要的、且由需方提供的设备、软件、服务、文档、数据 及设施，并给出何时

13、需要上述各项的进度表。 d) 其他所需的资源，包括:获得资源的计划、需要的日期、每个资源项的可用性(就绪的时 间)。 序号 资源名称 阶段1 1 2 3 4 项目经理 XX业务 代表 硬件组 软件组 结构组 测试组 阶段2 阶段3 阶段4 说明 7.3 项目依赖关系分析 在本节中，说明项目的内部依赖关系(如：开发测试工具、人力资源等)和对外部的依赖。 可用依赖性列表、活动网络图的方法描述。 列出所有影响项目计划的假设因素(相对于已知的因素)。如果这些假设因素有误，或者没有利用到假设因素，或者假设因素发生变化都会使项目受到影响。另外还要描述项目对外部因素的依赖关系，例如，如项目作为整个大系统的一

14、部分，需要其他部分提供接口定义或者PDT提供正在开发的仿真性能测试工具以代替实际环境测试等等 请参考下例： 表6.3 项目依赖关系 序号 依赖于 责任人 状态OPEN/CLOSE 最早提供日期 验收条件(如果有) 项目开发计划书 V1.0 报告编号： 序号 依赖于 责任人 状态OPEN/CLOSE 最早提供日期 验收条件(如果有) 1 2 3 6.1 技术方法和工具 在本节中，描述对产品项目进行需求分析、设计、实现、测试、文档写作、发布、修改、或维护过程中采用的开发方法、组织结构和其他标记、工具、技术和方法。此外，对使用的技术标准、方针和流程也要用直接描述或参考到其它文档的方式进行说明。 参考

15、下例，对于产品项目所需要的硬件、软件和其他工具设备用下表描述： 表6.4 技术方法和工具 分类 仪表 开发工具 名称 专用仪表 型号 数量 开始使用日期 结束使用日期 6.2 项目里程碑计划 关键里程碑计划可采用图形方式。 将项目的所有里程碑和关键活动标注在下面的时间轴上。注意：如果存在早期功能子集Beta和/或ESP交付件，PDT 需要对交付件进行TR4A/TR5评审，以及对GA层产品交付件进行TR4A和TR5评审。PDT不需要对每一个构件标注TR4，只需要标示第一个TR4的日期。如果需要将所有里程碑和关键活动标注出来，可将时间轴划分成阶段，如上所示。 也可采用如下例子的形式描述里程碑计划。

16、 表5 项目里程碑计划 阶段 估计结束日期 交付件 验收准则 TR1 和概念DR 市场调研报告 市场需求清单 初始业务计划 产品需求规格书 产品可行性分析报告/产品业务计划 TR2项目开发计划书 V1.0 报告编号： 和计划DR 产品开发计划 总体设计方案书/产品设计说明书 产品测试与验证计划 工艺总体方案 装备总体方案 初始物料清单 供应商和物料选择计划 物料认证计划 提前采购决策 模块级概要设计/总体设计 各模块级测试报告 目标成本跟踪表 市场教育和培训计划 测试方案 原型机 原型机测试报告 中试样机验证报告 制造系统验证报告 BETA测试报告 系统认证和标杆测试报告 产品可行性分析报告/

17、产品业务计划 市场发布材料清单 受控销售阶段评估报告 试产验证测试报告 制造系统验证报告 量产检查点确认通知 TR3 TR4 TR5 BETA测试结束 外部认证结束 TR6 和发布DR 量产点GA 6.3 成本估计 估计产品的预算及分配 讨论主要的未解决问题，包括资金投入的及时性及性质。将实际日期的项目资源、成本和时间进度与估计的整个项目的资源、成本和时间进度进行比较。 成本估计，是指对项目完成过程中耗费的人力、物力、财力资源的估算。成本估计应按类别进行估算，可能的成本估算类别，如： 直接人工 直接费用 间接成本 项目开发计划书 V1.0 报告编号： 制造费用 管理费用 不可预见费用 6.4

18、风险管理计划 按照风险管理规程来管理项目的风险。祥见XXX项目风险管理计划。 在此详细说明项目的风险项、风险描述、风险级别、规避措施、应急计划、触发条件。具体操作办法请参考风险评估和管理相关文档。 存在哪些技术、市场和财务风险？ 已确认的风险和假设是否已解决？有无遗留问题？ 有无新的风险和假设？ 提供简洁的风险管理计划。为了减少风险，在各阶段必需做些什么？如果在计划的时间范围内，这些风险不能解决，有没有准备其它的计划？ 如果没有这些风险，对项目会有哪些影响？ 与产品包相关的各方面的风险包括： 市场/客户风险； 技术风险； 财务风险； 制造风险； 采购风险； 技术支持风险； 项目风险 8. 客户

19、的参与 序号 在哪些方面参与 1 2 3 4 期望客户承担的职责 最大响应时间 说明 9. 培训计划 在本节中，明确说明相应人员现有的水平、需要的技能 、培训方式和培训效果评估方式信息。 举例如下： No 培训领域 需要的技能水平 1 2 3 项目组成员 已具备的技能水平 培训方式 培训效果评估方式 项目开发计划书 V1.0 报告编号： 10. 计划更新策略 在本节中，应描述项目计划的更新策略，明确说明项目计划更新的发布方法。还要说明对项目计划进行变更控制和管理的机制以及其载体。以下文字仅供参考： 在发生如下事件时，PM修订项目计划和参考文档： 到达某里程碑，在每个阶段结束后如果必要的话修订项

20、目计划。 项目的范围发生变化 当风险成为现实时采取了相应的行动 当进度、工作量超出控制的范围并需要采取纠正行动时。 当与上阶段规模变化超过+/-15%。 内部或外部审计导致的纠正活动 对修订后的项目计划按照项目管理规程来批准和签发。 项目计划的更新，存在阶段驱动性更新和事件驱动性更新两种类型。阶段驱动性更新是指在每一阶段结束时，如果计划或者工作量估计的变动超过10，就需要对项目计划进行更新；事件驱动性更新是指在计划执行过程中遇到项目突然变动或者其他影响项目正常运行的事件发生，需要对项目的计划进行更新。 项目计划更新需要对计划文档更新和项目里程碑计划的更新。 不论是阶段驱动性更新还是时间驱动性更新都需要对项目的更新计划进行评审，评审需要PDT经理、PQA以及功能领域代表参加。