《软件开发计划》由会员分享，可在线阅读，更多相关《软件开发计划（11页珍藏版）》请在金锄头文库上搜索。
1、博恩软件软件开发计划状 态撰 写标 识 号BNSW-PRJ-项目名缩写-SPP-PLNo审 批当前版本V1.0o发 布发布日期2003-05-31模板编号BNSW-TEMP-SPP-PLAN密 级o无密级 秘 密 o绝 密注：以下提供的模板用于博恩软件。其中包括用方括号括起来并以蓝色斜体（样式=InfoBlue）显示的文本，它们用于向作者提供指导，在发布此文档之前应该将其删除。按此样式输入的段落将被自动设置为普通样式（样式=Body Text）。要定制 Microsoft Word 中的自动字段（选中时显示灰色背景），请选择 文件属性，然后将 标题、主题 和 公司 等字段替换为此文档的相应信息
2、。关闭该对话框后，通过选择 编辑全选（或 Ctrl-A）并按 F9，或只是在字段上单击并按 F9，可以在整个文档中更新自动字段。对于页眉和页脚，这一操作必须单独进行。按 Alt-F9，将在显示字段名称和字段内容之间切换。有关字段处理的详细信息，请参见 Word 帮助。 版本： 0.1软件开发计划 日期：YYYY-MM-DDBNSW-PRJ-项目名缩写-SPP-PLN修订历史记录日期版本说明作者2003-05-280.1提供模板草案蒋程2003-9-220.2根据使用情况,调整了目录结构,并重点细化了“需求管理”蒋程2003-10-91.0发布蒋程2004-9-221.1修改模板蒋程目录1.简介
3、51.1目的51.2范围51.3定义、首字母缩写词和缩略语51.4参考资料51.5概述62.项目概述62.1项目的目的、规模和目标62.2假设与约束62.3项目的可交付工件62.4软件开发计划的演进63.项目组织63.1组织结构63.2对外联系63.3角色与职责64.管理流程64.1项目估计64.2项目计划74.2.1阶段计划74.2.2项目生命周期74.2.3项目时间表74.2.4项目资源分配74.2.5预算74.3项目监测与控制74.3.1需求管理计划74.3.2进度控制计划94.3.3预算控制计划94.3.4质量控制计划94.3.5报告计划94.3.6测试计划94.4风险管理计划94.5
4、收尾计划95.技术流程计划105.1开发案例105.2方法、工具和技巧105.3基础设施计划105.4产品验收计划106.支持流程计划106.1配置管理计划106.2评估计划106.3文档计划106.4质量保证计划106.5问题解决计划116.6分包商管理计划116.7流程改进计划117.其他计划118.附录119.索引11软件开发计划1. 简介软件开发计划的简介应提供整个文档的概述。它应包括此软件开发计划的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。1.1 目的阐明此软件开发计划的目的。1.2 范围简要说明此软件开发计划的范围：它的相关项目，以及受到此文档影响的任何其他事物。1.
5、3 定义、首字母缩写词和缩略语本小节应提供正确解释此软件开发计划所需的全部术语的定义、首字母缩写词和缩略语。这些信息可以通过引用项目词汇表来提供。1.4 参考资料本小节应完整列出此软件开发计划中其他部分所引用的任何文档。每个文档应标有标题、报告号（如果适用）、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过对附录或其他文档的引用来提供。 对于软件开发计划，引用工件的列表中应包括： 迭代计划 需求管理计划 评测计划 风险管理计划 开发案例 业务建模指南 用户界面指南 用例建模指南 设计指南 编程指南 测试指南 手册风格指南 基础设施计划 产品验收计划 配置管理计划 评估计划（仅
6、当该计划是单独的计划时，但它通常是 SDP 的第 6.2 节。） 文档计划 质量保证计划 问题解决计划 分包商管理计划 流程改进计划1.5 概述本小节应说明此软件开发计划其他部分所包含的内容，并解释文档的组织方式。2. 项目概述2.1 项目的目的、规模和目标简要说明此项目的目的与目标，以及此项目将要交付的可交付工件。可以从项目视图、需求规格说明书中引用2.2 假设与约束列出此计划所依据的假设和项目所受到的所有约束（如预算、人员、设备、时间表等）。2.3 项目的可交付工件以表格的形式列出将在项目中创建的工件，其来源主要是“客户需求”（或“技术协议”）并包括预定交付日期。2.4 软件开发计划的演进
7、以表格的形式列出软件开发计划的提议版本，以及在计划外修订与重新发行此计划需符合的标准。3. 项目组织3.1 组织结构说明项目团队（包括管理部门和其他复审权威部门）的组织结构。3.2 对外联系说明项目与外部组织的联系方式。对于每个外部组织，应确定其内部和外部联系人的姓名。3.3 角色与职责确定将负责各个核心工作流程、工作流程明细和支持流程的项目组织单位。4. 管理流程4.1 项目估计提供估计的项目成本与进度、这些估计所依据的基础，以及在何时和什么情况下需要对项目进行重新估计。4.2 项目计划4.2.1 阶段计划应包括以下内容： 工作细分结构 (WBS) 显示项目各阶段或迭代的时间分配情况的时间线
8、或甘特图 确定主要里程碑及其实现标准确定所有重要的发布点和演示4.2.2 项目生命周期说明项目采用的周期模型，并说明采用的原因。4.2.3 项目时间表用图或表显示完成迭代与阶段、发布点、演示以及其他里程碑的预定日期。4.2.4 项目资源分配4.2.4.1 人员配备计划在此处确定所需人员的数目和类型，以及项目阶段或迭代所需的任何特殊技能或经验。4.2.4.2 资源获取计划说明您将如何发现并招募项目所需的人员。4.2.4.3 培训计划列出项目团队成员所需的所有特殊培训，以及完成这些培训的预定日期。4.2.5 预算按照 WBS 和阶段计划分摊成本。成本至少可以分为三类进行说明：固定工资、外出费用以及
9、项目奖金。4.3 项目监测与控制4.3.1 需求管理计划通过引用附加。如果项目不是非常庞大,可以考虑使用4.4.1.1、6.4.1.2的方式。需要说明，为了便于了解需求管理有什么内容可以做，下面的项目可能比较多，在实际项目中，可以考虑适当删减。4.3.1.1 需求管理的负责人明确指定需求管理活动的负责人。分为两类：一是需求初始化和变更的确定人，由他批准需求；二是，需求追溯活动的协调人员，确保所有的需求都得以实现，所有的变更都有条不紊进行。通常，我们考虑：u 在项目初期，需求要通过正式的同行评审，并由公司技术负责人决定该需求是否通过。u 在项目进行过程中，客户如果提出了变更，经小组讨论，由项目经
10、理决定是否进行变更。u 在项目进行过程中，需求追溯活动由XXX进行跟踪和协调。4.3.1.2 需求工件与需求类型对于项目中的每种需求文档或工件，都应列出其中包含的需求类型，并简要解释其用途。您最好也列出承担相应职责的角色。通常情况下，可以用较为简单的技术协议、需求规格说明书、需求变更的组合，也可以采用比较严格、细致的RUP模型。如下表所示工件需求类型说明涉众请求涉众请求（STRQ）涉众的关键请求，包括变更。本项目，仅使用“需求变更申请”。客户需求（产品蓝图）特征（FEAT）系统的这一发布版的状况或功能需求规格说明书规格（SPEC）系统的规格化功能和非功能性要求用例模型用例（UC）该发布版的用例
11、，记录在RoseTogether中工件需求类型说明涉众请求涉众请求（STRQ）涉众的关键请求，包括变更前景涉众需要（NEED）关键的涉众或用户需要 前景特征（FEAT）系统的这一发布版的状况或功能用例模型用例（UC）该发布版的用例，记录在RoseTogether中补充规约补充需求（SUPP）为记录在用例模型中的非功能需求。4.3.1.3 需求属性对每一类型的需求都有公用属性，以便于跟踪和管理，其主要反映在需求追溯表中，将会采用以下属性：根据实际情况，对下面的各属性进行保留或删除，并适当整理，考虑用表格等方式进行一致的说明。但要注意，状态、工作量、职责分配必须保留。状态在经过项目管理团队商谈和复
12、审后设置，用于在确立项目基线的过程中对进度进行跟踪。已提出用于说明正在进行讨论但尚未经过“正式渠道”（例如由项目团队、产品管理部门和用户或客户群的代表所组成的工作组）复审和验收的特性。已获准被认为是有用的、可行并已获得正式渠道批准，准备实施的功能。已并入在特定时间定并入到产品基线的特性。工作量由开发团队设置。由于有些特性所需的时间和资源多于其他特性，所以估计团队工作周数或个人工作周数、所需的代码行数或功能点数（举例来说），即是一种最佳方式，用来估计复杂程度并预计在给定时间限度内能完成哪些工作。用于管理规模并确定开发的优先级。职责分配在项目中，特性必须分配给具体执行人员，他们负责进一步获取需求，
13、并编写软件需求和实施方案。同样，需求规格化后，具体执行依然要制定具体人员，从而实现了从需求到实现的职责分配。风险由开发团队根据项目遭遇意外事件的可能性来设置，这些事件包括超支、工期延误，甚或是项目取消。虽然可以对风险级别进行细分，但大多数项目经理都认为将风险归为高、中、低就足够了。通过评测项目团队估计进度的不确定性（范围），一般都可以间接地对风险进行评估。原因此文本字段用于跟踪所需特性的来源。需求的提出总有其具体的原因。此字段用于陈述解释或陈述解释所引用的内容。例如，引用内容可以是产品需求规约的页码及行号，或是某次重要的客户访谈录像的会议记录标号。目标发布版记录将首次展示特性的产品版本。该字段
14、可用于将前景文档中的职责分配给特定的基线发布版。如果将其与状态字段结合，您的团队就可以提出、记录和讨论发布版的各种特性，而此时还不必前进到开发阶段。只有状态设置为“已并入”且目标发布版已定义的特性才将被实现。管理规模时，可以增加目标发布版本号，这样该项特性虽然仍保留在前景文档中，但将安排在以后发布。4.3.2 进度控制计划说明以何种方法按照设定的时间表监控项目进展，以及如何在需要时采取纠正措施。比如：u 当进度延迟超过计划的2天，项目经理就记录为问题，寻找问题原因，并想办法解决。u 当进度延迟超过计划的5天，项目经理必须召开内部会议，迅速制定并采取解决措施。SQA参与其具体任务的实施情况。u 当进度延迟超过10天，高级管理者参与，协调解决相关问题。并调整开发计划。4.3.3 预
