软件开发过程的相关规范

软件开发过程规范版本 <1.0>修订历史纪录目录1.前言21.1目的21.2对象21.3要求21.4适用范围21.5软件开发过程模型31.6开发过程划分32.技术过程规范部分32.1概述32.2业务建模阶段32.3需求阶段42.4分析设计阶段52.5实现阶段63.经管过程规范部分73.1概述73.2接受工程73.3重新评估工程范围和风险（对于较大工程）73.4制定开发计划83.5迭代开发经管83.6监控工程的实施83.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)《工程概览》（系统）在需求阶段，根据对工程理解的不断加深，随时进行改进；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)根据本次迭代开发的完成情况和提交的成果，对该迭代开发过程进行分析评价，形成《迭代评价》，并根据实际情况，提出《变更请求》。