软件开发过程的相关规范

软件开发过程规范

版本 <1.0>

修订历史纪录

目录

1.前言2

1.1目的2

1.2对象2

1.3要求2

1.4适用范围2

1.5软件开发过程模型3

1.6开发过程划分3

2.技术过程规范部分3

2.1概述3

2.2业务建模阶段3

2.3需求阶段4

2.4分析设计阶段5

2.5实现阶段6

3.经管过程规范部分7

3.1概述7

3.2接受工程7

3.3重新评估工程范围和风险（对于较大工程）7

3.4制定开发计划8

3.5迭代开发经管8

3.6监控工程的实施8

3.7结束工程9

软件开发过程规范

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)《工程概览》（系统）在需求阶段，根据对工程理解的不断加深，随时进行改进；