软件开发过程规范

软件开发过程规范

版本 <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 制定开发计划 (8)

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)《用户手册》（初稿）

2.3.5文档规范

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

2)《需求规格说明》

3)《术语表》

4)《用例规格》

5)《增补规格》

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

2.3.6技术评审

1)需求评审

2.4 分析设计阶段

2.4.1顺序性活动描述

1)根据《系统需求规格》进行体系结构分析设计，确定系统软件架构，形成配置图和《软

件架构文档》；

2)根据《需求规格说明》和系统软件架构，进一步扩展业务对象模型，建立分析对象模型，

明确系统对象的职责；

3)根据业务对象，及业务对象之间的关系，结合分析对象和系统软件架构，进行数据库的

分析设计，建立数据模型，完成数据库设计工作，形成《数据模型纵览》；

4)应用分析对象实现系统用例，以验证分析对象的正确性，并根据验证结果，修正分析对

象模型；

5)汇总分析对象模型和基于分析对象的用例实现，形成《分析模型纵览》；

6)根据分析对象模型，结合用户原型界面和数据模型，进行系统类设计，建立设计类模型

和构件图；

7)实施系统类的详细设计，确定类的属性、方法及参数类型、可见性等，并将用例分配给

对象类，形成基于设计类的用例实现；

8)汇总设计类模型和基于设计类的用例实现，形成《设计模型纵览》，为下一步系统的实

现明确工作任务。

2.4.2持续性活动描述

无。

2.4.3提交文档

1)《软件架构文档》

2)《分析模型纵览》

3)《设计模型纵览》

4)《数据模型纵览》

2.4.4可选文档

无。

2.4.5文档规范

1)《软件架构文档》

2)《分析模型纵览》

3)《设计模型纵览》

4)《数据模型纵览》

2.4.6技术评审

1)软件架构评审

2)设计评审

2.5 实现阶段

2.5.1顺序性活动描述

1)根据《设计类模型》，按照类的详细设计和构件图，结合用例的实现优先级，确定系统

《实现模型》，并根据系统体系结构进行系统集成设计，形成《集成模型》；

2)根据《实现模型》进行组件编码实现；

3)根据《集成模型》对系统编码实现的组件进行系统集成实现；

4)编制《用户手册》，制作并集成系统帮助，完成客户或用户所需要的其他文档。

2.5.2持续性活动描述

无。

2.5.3提交文档

1)《实现模型》

2)《集成设计》

2.5.4 可选文档

1)《用户手册》

2.5.5 文档规范

1)《实现模型》

2)《集成设计》

3)《用户手册》

2.5.6 技术评审

1)代码评审

3. 管理过程规范部分

3.1 概述

在本规范中，对软件开发过程的管理，采用阶段性规划。具体为根据软件开发过程中的技术过程，明确开发阶段，主要依据技术过程规范所描述的技术过程阶段划分；而后，将各阶段根据项目的具体情况和实施要求，划分为利于监控管理的一个或多个迭代过程。

本规范对于项目的计划和进度安排，采用由粗到细、由简到繁的方式，首先制定描述软件开发过程总体阶段和迭代的软件开发计划，而后根据所划分的迭代过程，在每个迭代开始时，对该迭代过程进行详细的任务分配和进度规划。

本规范中所提到的《软件开发计划》，包含了开发计划、质量管理计划、技术支持计划等多项

内容，但主要以开发计划为主，其他计划视具体项目、团队情况确定是否制定。

在本规范中风险管理贯穿整个软件开发过程，包括《风险列表》的更新维护、风险的跟踪管理。

对本规范中的各开发计划的具体实施说明，可参见《项目监控管理办法》相关说明。

规范中各阶段提到的管理评审，具体参见《评审规范》中所对应管理性评审的详细描述。3.2 接受项目

3.2.1 活动描述

1)根据《项目概览》标识和评估风险，制定《风险列表》；

2)分析项目风险，制定风险防范和解决措施，形成《风险管理计划》；

3)分析可行性和商业价值，制定《商业案例》；

3.2.2 提交文档

1)《风险列表》

2)《风险管理计划》

3)《商业案例》

3.2.3 管理评审

1)项目批准评审

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

3.3.1 活动描述

1)根据《项目概览》和对项目进一步深入了解，重新标识和评估风险，改进《风险列表》；

2)根据修正项目风险，重新分析项目可行性和商业价值，改进《商业案例》；

3.3.2 提交文档

1)修正的《风险列表》

2)修正的《商业案例》

3.3.3 管理评审

无。

3.4 制定开发计划

3.4.1活动描述

1)根据不断修正维护的《风险列表》，完善风险防范和解决措施，改进《风险管理计划》；

2)根据《商业案例》中说明的项目的开发要求，结合资源和风险状况，建立项目工作分析

结构（WBS），明确开发阶段和迭代次数，同时完成其他开发相关的计划内容，形成《软

件开发计划》。

3.4.2 提交文档

1)修正的《风险管理计划》

2)《软件开发计划》

3.4.3 管理评审

1)开发计划评审

3.5 迭代开发管理

3.5.1 活动描述

1)根据《软件开发计划》，结合具体的开发状况和资源获取情况，确定在一个迭代期间的

开发任务，进度安排，形成《迭代计划》，并更新《软件开发计划》；

2)按照《迭代计划》，将工作任务形成《任务单》，描述任务要求，明确开发人员职责；

3)根据本次迭代开发的完成情况和提交的成果，对该迭代开发过程进行分析评价，形成《迭

代评价》，并根据实际情况，提出《变更请求》。

3.5.2提交文档

1)修正的《软件开发计划》

2)《迭代计划》

3)《任务单》

4)《变更请求》

3.5.3管理评审

1)迭代计划评审

2)迭代评价标准评审

3)迭代评价评审

3.6 监控项目的实施

3.6.1活动描述

1)在项目开发过程中随时监控项目的状态，了解项目的进展，特别是根据《风险列表》，

跟踪风险，及时发现问题，并根据监控结果，及时更新、维护《风险列表》；

2)分析项目监控过程中发现和出现的问题和意外情况，制定解决办法，提出《变更请求》；

3)在监控过程中，根据实际开发情况，调整《软件开发计划》和《迭代计划》，并更新和

分配新的《任务单》；

4)应项目管理和客户的要求，定期或不定期根据项目的当前状况，制定《项目状况评价》，

进行项目开发状况的汇报。

3.6.2 提交文档

1)修正的《风险列表》

2)修正的《软件开发计划》

3)修正的《迭代计划》

4)《任务单》

5)《变更请求》

6)《项目状况评价》

3.6.3管理评审

1)1．PRA评审

3.7 结束项目

3.7.1活动描述

1)在项目开发任务全部完成，开发过程结束时，总结项目的开发过程，分析和评价项目完

成情况和提交的成果，形成最终的《项目状况评价》，提交验收。

3.7.2提交文档

1)《项目状况评价》

3.7.3管理评审

1)项目验收评审

软件开发过程规范示意