软件开发过程规范

1、软件开发过程规范版本 <1.0>修订历史纪录日期版本描述作者<年/月/日 ><x.x><细节><名>目 录1.前言31.1目的31.2对象31.3要求31.4适用范围31.5软件开发过程模型31.6开发过程划分32.技术过程规范部分32.1概述32.2业务建模阶段42.3需求阶段52.4分析设计阶段62.5实现阶段73.管理过程规范部分73.1概述73.2接受项目83.3重新评估项目范围和风险（对于较大项目）83.4制定开发计划83.5迭代开发管理93.6监控项目的实施93.7结束项目10软件开发过程规范1. 前言1.1 目的本规范的

2、目的是使整个软件产品开发及项目工程阶段清晰，要求明确，任务具体，便于规范化、系统化及工程化。有利于提高软件生命周期的控制及管理，提高所开发软件的质量，缩短开发时间，减少开发和维护费用，使软件开发活动更科学、更有成效。1.2 对象本规范面向产品生命周期的所有相关人员，包括管理人员、开发人员、质管人员。1.3 要求具有软件开发管理职能的人员要求熟知项目开发的各阶段过程和各阶段过程相应的规范。1.4 适用范围适用于产品开发生命周期中的除产品提交外的其他全部过程；规范分为两部分：技术过程规范和管理过程规范，分别适用于软件开发过程中的技术性活动和管理性活动。1.5 软件开发过程模型本规范所采用的软件开发

3、过程模型为简化的RUP开发过程模型；软件开发过程是体系结构为中心，用例驱动和风险驱动相结合的过程迭代。1.6 开发过程划分开发过程包括多次迭代，每次迭代的目标和侧重点不同；较早的迭代侧重于业务建模和需求建模；而后的迭代则侧重于分析设计和编码。2. 技术过程规范部分2.1 概述本规范中将软件开发的整个技术过程分为四个顺序实施的阶段，分别为业务建模阶段、需求阶段、分析设计阶段和实现阶段。在对技术过程规范的描述，按阶段内部的活动和产物对四个阶段分别说明。在本规范中对阶段内活动的说明，是按顺序性活动和持续性活动两类分别进行说明。对于顺序性活动是按该阶段中活动的总体顺序进行的描述，而在实际工作中，从各活

4、动的具体实施的细节来看，各活动之间的顺序是不断交叉变化的。对于持续性活动主要是对贯穿该阶段过程始终的技术活动进行说明。规范中所提到的可选文档是指在其所属阶段，可根据具体情况灵活掌握，开发团队自主决定是否开发的文档产物。而提交文档则是指在项目开发过程中必须开发的文档产物，但可根据具体项目情况，在软件开发计划中明确规定是否要形成正式文档并提交。规范中各阶段提到的技术评审，具体参见评审规范中所对应技术性评审的详细描述。2.2 业务建模阶段2.2.1 顺序性活动描述1) 开始初步调研，获取初始业务需求，进行问题定义，形成业务概览并建立术语表；2) 制定调研记录表册，实施详细的业务调研，建立初始的业务用

5、例模型和业务用例规格；3) 分析业务过程，取出可以实现自动化的用例，分析业务部门和实体对象，形成初始的业务对象模型；4) 根据初始业务对象模型和初始业务用例模型，分析并提取与系统实现相关的用例和模型， 建立系统域模型；5) 精化域模型中的初始用例，详细描述业务流程，分析业务规则，建立精化的业务用例模型，形成业务规则和业务用例规格；6) 精化域模型中的初始对象，进行详细的对象描述，分析对象职责和对象间关系，建立精化的业务对象模型，形成业务对象纵览；7) 分析业务上的非功能性需求，形成增补业务规格；8) 应用业务对象，实现业务用例，制定业务用例实现规格，以验证业务对象与业务用例的正确性，根据验证结

6、果，修正业务对象、业务用例及相关文档；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) 业

7、务用例实现规格10) 目标组织评价2.2.6 技术评审1) 业务用例模型评审2) 业务对象模型评审2.3 需求阶段2.3.1 顺序性活动描述1) 界定系统范围，明确委托方需求，形成项目概览（系统）术语表；2) 定义系统角色，根据业务用例规格，分析业务用例，将其转换为系统初始用例，并开始系统原型界面的开发；3) 结合增补业务规格，细致分析用例资源条件，形成初始增补规格，同时剔除无法实现的初始用例，形成初始用例规格；4) 为初始用例分析划分优先级、分析依赖性，建立初始用例模型，结合初始增补规格形成初始软件需求规格，为子系统分析或包、组件分析奠定基础；5) 精化初始用例模型中的用例，详细描述系统交互

8、过程，建立精化的用例模型，用例规格；6) 根据初始增补规格和业务规则，进一步深入分析系统的非功能性需求，形成增补规格；7) 汇总用例规格增补规格形成软件需求规格。2.3.2 持续性活动描述1) 项目概览（系统）在需求阶段，根据对项目理解的不断加深，随时进行改进；2) 术语表的更新维护；3) 通过快速原型的开发、试用、修改，与客户和用户交流以不断获取系统需求，并形成用户原型界面描述。2.3.3 提交文档1) 项目概览（系统）2) 术语表3) 需求规格说明其附件包括：用例规格增补规格4) 用户原型界面描述2.3.4 可选文档1) 用户接口风格说明2) 委托方需求3) 用户手册（初稿）2.3.5 文

9、档规范1) 项目概览（系统）2) 需求规格说明3) 术语表4) 用例规格5) 增补规格6) 用户原型界面描述2.3.6 技术评审1) 需求评审2.4 分析设计阶段2.4.1 顺序性活动描述1) 根据系统需求规格进行体系结构分析设计，确定系统软件架构，形成配置图和软件架构文档；2) 根据需求规格说明和系统软件架构，进一步扩展业务对象模型，建立分析对象模型，明确系统对象的职责；3) 根据业务对象，及业务对象之间的关系，结合分析对象和系统软件架构，进行数据库的分析设计，建立数据模型，完成数据库设计工作，形成数据模型纵览； 4) 应用分析对象实现系统用例，以验证分析对象的正确性，并根据验证结果，修正分

10、析对象模型；5) 汇总分析对象模型和基于分析对象的用例实现，形成分析模型纵览；6) 根据分析对象模型，结合用户原型界面和数据模型，进行系统类设计，建立设计类模型和构件图；7) 实施系统类的详细设计，确定类的属性、方法及参数类型、可见性等，并将用例分配给对象类，形成基于设计类的用例实现；8) 汇总设计类模型和基于设计类的用例实现，形成设计模型纵览，为下一步系统的实现明确工作任务。2.4.2 持续性活动描述无。2.4.3 提交文档1) 软件架构文档2) 分析模型纵览3) 设计模型纵览4) 数据模型纵览2.4.4 可选文档无。2.4.5 文档规范1) 软件架构文档2) 分析模型纵览3) 设计模型纵览

11、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

12、技术评审1) 代码评审3. 管理过程规范部分3.1 概述在本规范中，对软件开发过程的管理，采用阶段性规划。具体为根据软件开发过程中的技术过程，明确开发阶段，主要依据技术过程规范所描述的技术过程阶段划分；而后，将各阶段根据项目的具体情况和实施要求，划分为利于监控管理的一个或多个迭代过程。本规范对于项目的计划和进度安排，采用由粗到细、由简到繁的方式，首先制定描述软件开发过程总体阶段和迭代的软件开发计划，而后根据所划分的迭代过程，在每个迭代开始时，对该迭代过程进行详细的任务分配和进度规划。本规范中所提到的软件开发计划，包含了开发计划、质量管理计划、技术支持计划等多项内容，但主要以开发计划为主，其他计

13、划视具体项目、团队情况确定是否制定。在本规范中风险管理贯穿整个软件开发过程，包括风险列表的更新维护、风险的跟踪管理。对本规范中的各开发计划的具体实施说明，可参见项目监控管理办法相关说明。规范中各阶段提到的管理评审，具体参见评审规范中所对应管理性评审的详细描述。3.2 接受项目3.2.1 活动描述1) 根据项目概览标识和评估风险，制定风险列表；2) 分析项目风险，制定风险防范和解决措施，形成风险管理计划；3) 分析可行性和商业价值，制定商业案例；3.2.2 提交文档1) 风险列表2) 风险管理计划3) 商业案例3.2.3 管理评审1) 项目批准评审3.3 重新评估项目范围和风险（对于较大项目）3

14、.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.

15、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) 应项目管理和客户的要求，定期或不定期根据项目的当