软件开发过程规范

软件开发过程规范

版本 <1.0>

修订历史纪录

目录

1.前言 (3)

1.1 目的 (3)

1.2 对象 (3)

1.3 要求 (3)

1.4 适用范围 (3)

1.5 软件开发过程模型 (3)

1.6 开发过程划分 (3)

2.技术过程规范部分 (3)

2.1 概述 (3)

2.2 业务建模阶段 (4)

2.3 需求阶段 (5)

2.4 分析设计阶段 (6)

2.5 实现阶段 (7)

3.管理过程规范部分 (7)

3.1 概述 (7)

3.2 接受项目 (8)

3.3 重新评估项目范围和风险（对于较大项目） (8)

3.4 制定开发计划 (9)

3.5 迭代开发管理 (9)

3.6 监控项目的实施 (9)

3.7 结束项目 (10)

软件开发过程规范

1. 前言

1.1 目的

本规范的目的是使整个软件产品开发及项目工程阶段清晰，要求明确，任务具体，便于规范化、系统化及工程化。有利于提高软件生命周期的控制及管理，提高所开发软件的质量，缩短开发时间，减少开发和维护费用，使软件开发活动更科学、更有成效。

1.2 对象

本规范面向产品生命周期的所有相关人员，包括管理人员、开发人员、质管人员。

1.3 要求

具有软件开发管理职能的人员要求熟知项目开发的各阶段过程和各阶段过程相应的规范。

1.4 适用范围

适用于产品开发生命周期中的除产品提交外的其他全部过程；规范分为两部分：技术过程规范和管理过程规范，分别适用于软件开发过程中的技术性活动和管理性活动。

1.5 软件开发过程模型

本规范所采用的软件开发过程模型为简化的RUP开发过程模型；软件开发过程是体系结构为中心，用例驱动和风险驱动相结合的过程迭代。

1.6 开发过程划分

开发过程包括多次迭代，每次迭代的目标和侧重点不同；较早的迭代侧重于业务建模和需求建模；而后的迭代则侧重于分析设计和编码。

2. 技术过程规范部分

2.1 概述

本规范中将软件开发的整个技术过程分为四个顺序实施的阶段，分别为业务建模阶段、需求阶段、分析设计阶段和实现阶段。在对技术过程规范的描述，按阶段内部的活动和产物对四个阶段分别说明。

在本规范中对阶段内活动的说明，是按顺序性活动和持续性活动两类分别进行说明。对于顺序性活动是按该阶段中活动的总体顺序进行的描述，而在实际工作中，从各活动的具体实施的细节来看，各活动之间的顺序是不断交叉变化的。对于持续性活动主要是对贯穿该阶段过程始终的

技术活动进行说明。

规范中所提到的可选文档是指在其所属阶段，可根据具体情况灵活掌握，开发团队自主决定是否开发的文档产物。而提交文档则是指在项目开发过程中必须开发的文档产物，但可根据具体项目情况，在软件开发计划中明确规定是否要形成正式文档并提交。

规范中各阶段提到的技术评审，具体参见《评审规范》中所对应技术性评审的详细描述。2.2 业务建模阶段

2.2.1 顺序性活动描述

1)开始初步调研，获取初始业务需求，进行问题定义，形成《业务概览》并建立《术语表》；

2)制定《调研记录表册》，实施详细的业务调研，建立初始的业务用例模型和《业务用例

规格》；

3)分析业务过程，取出可以实现自动化的用例，分析业务部门和实体对象，形成初始的

业务对象模型；

4)根据初始业务对象模型和初始业务用例模型，分析并提取与系统实现相关的用例和模

型，建立系统域模型；

5)精化域模型中的初始用例，详细描述业务流程，分析业务规则，建立精化的业务用例

模型，形成《业务规则》和《业务用例规格》；

6)精化域模型中的初始对象，进行详细的对象描述，分析对象职责和对象间关系，建立

精化的业务对象模型，形成《业务对象纵览》；

7)分析业务上的非功能性需求，形成《增补业务规格》；

8)应用业务对象，实现业务用例，制定《业务用例实现规格》，以验证业务对象与业务用

例的正确性，根据验证结果，修正业务对象、业务用例及相关文档；

9)汇总《业务规则》《业务用例规格》《业务对象纵览》《增补业务规格》和《业务用例

实现规格》形成《业务架构文档》。

2.2.2 持续性活动描述

1)《业务概览》在业务建模阶段，根据对项目理解的不断加深，随时进行改进；

2)《术语表》的更新维护；

2.2.3 提交文档

1)《业务概览》

2)《术语表》

3)《调研记录表册》

4)《业务架构文档》其附件包括：《业务规则》《业务用例规格》《业务对象纵览》《增

补业务规格》和《业务用例实现规格》

2.2.4 可选文档

1)《目标组织评价》

2.2.5 文档规范

1)《业务概览》

2)《术语表》

3)《项目调研表册》

4)《业务架构文档》

5)《业务规则》

6)《业务用例规格》

7)《业务对象纵览》

8)《增补业务规格》

9)《业务用例实现规格》

10)《目标组织评价》

2.2.6技术评审

1)业务用例模型评审

2)业务对象模型评审

2.3 需求阶段

2.3.1顺序性活动描述

1)界定系统范围，明确委托方需求，形成《项目概览》（系统）《术语表》；

2)定义系统角色，根据《业务用例规格》，分析业务用例，将其转换为系统初始用例，并

开始系统原型界面的开发；

3)结合《增补业务规格》，细致分析用例资源条件，形成初始《增补规格》，同时剔除无

法实现的初始用例，形成初始《用例规格》；

4)为初始用例分析划分优先级、分析依赖性，建立初始用例模型，结合初始《增补规格》

形成初始《软件需求规格》，为子系统分析或包、组件分析奠定基础；

5)精化初始用例模型中的用例，详细描述系统交互过程，建立精化的用例模型，《用例规

格》；

6)根据初始《增补规格》和《业务规则》，进一步深入分析系统的非功能性需求，形成《增

补规格》；

7)汇总《用例规格》《增补规格》形成《软件需求规格》。

2.3.2持续性活动描述

1)《项目概览》（系统）在需求阶段，根据对项目理解的不断加深，随时进行改进；

2)《术语表》的更新维护；

3)通过快速原型的开发、试用、修改，与客户和用户交流以不断获取系统需求，并形成《用

户原型界面描述》。

2.3.3提交文档

1)《项目概览》（系统）

2)《术语表》

3)《需求规格说明》其附件包括：《用例规格》《增补规格》

4)《用户原型界面描述》

2.3.4 可选文档

1)《用户接口风格说明》

2)《委托方需求》

3)《用户手册》（初稿）