公司通用软件开发过程规范

1、润欣科技软件项目开发规范V1.0单 位： Fortune 润欣科技 日 期： 2011 年 9 月 23 日文档控制更改记录：日期作者版本更改参考2011-09-23RocV 1.0新建审阅：姓名职位签字分发人员：编码姓名地点和位置特殊说明 :目录1.前言 41.1 目的 41.2 对象 41.3 要求 41.4 适用范围 41.5 软件开发过程模型 41.6 开发过程划分 42.技术过程规范部分 42.1 概述 42.2 业务建模阶段 52.3 需求阶段 62.4 分析设计阶段 72.5 实现阶段 73.管理过程规范部分 83.1 概述 83.2 接受项目 93.3 重新评估项目范围和风险（

2、对于较大项目） 93.4 制定开发计划 93.5 迭代开发管理 93.6 监控项目的实施 103.7 结束项目 10软件开发过程规范1. 前言1.1 目的本规范的目的是使整个软件产品开发及项目工程阶段清晰，要求明确，任务具体，便于规范 化、系统化及工程化。有利于提高软件生命周期的控制及管理，提高所开发软件的质量，缩短开 发时间，减少开发和维护费用，使软件开发活动更科学、更有成效。1.2 对象本规范面向产品生命周期的所有相关人员，包括管理人员、开发人员、质管人员。1.3 要求具有软件开发管理职能的人员要求熟知项目开发的各阶段过程和各阶段过程相应的规范。1.4 适用范围适用于产品开发生命周期中的除

3、产品提交外的其他全部过程；规范分为两部分：技术过程规 范和管理过程规范，分别适用于软件开发过程中的技术性活动和管理性活动。1.5 软件开发过程模型本规范所采用的软件开发过程模型为简化的 RUP 开发过程模型；软件开发过程是体系结构为 中心，用例驱动和风险驱动相结合的过程迭代。1.6 开发过程划分 开发过程包括多次迭代，每次迭代的目标和侧重点不同；较早的迭代侧重于业务建模和需求 建模；而后的迭代则侧重于分析设计和编码。2. 技术过程规范部分2.1 概述 本规范中将软件开发的整个技术过程分为四个顺序实施的阶段，分别为业务建模阶段、需求 阶段、分析设计阶段和实现阶段。在对技术过程规范的描述，按阶段内

4、部的活动和产物对四个阶 段分别说明。在本规范中对阶段内活动的说明，是按顺序性活动和持续性活动两类分别进行说明。对于顺 序性活动是按该阶段中活动的总体顺序进行的描述，而在实际工作中，从各活动的具体实施的细 节来看，各活动之间的顺序是不断交叉变化的。对于持续性活动主要是对贯穿该阶段过程始终的 技术活动进行说明。规范中所提到的可选文档是指在其所属阶段，可根据具体情况灵活掌握，开发团队自主决定 是否开发的文档产物。而提交文档则是指在项目开发过程中必须开发的文档产物，但可根据具体 项目情况，在软件开发计划中明确规定是否要形成正式文档并提交。规范中各阶段提到的技术评审，具体参见评审规范中所对应技术性评审的

5、详细描述。2.2 业务建模阶段2.2.1 顺序性活动描述1) 开始初步调研，获取初始业务需求， 进行问题定义，形成业务概览并建立术语表；2) 制定调研记录表册，实施详细的业务调研，建立初始的业务用例模型和业务用例 规格；3) 分析业务过程，取出可以实现自动化的用例，分析业务部门和实体对象，形成初始的 业务对象模型；4) 根据初始业务对象模型和初始业务用例模型，分析并提取与系统实现相关的用例和模 型， 建立系统域模型；5) 精化域模型中的初始用例，详细描述业务流程，分析业务规则，建立精化的业务用例 模型，形成业务规则和业务用例规格；6) 精化域模型中的初始对象，进行详细的对象描述，分析对象职责和

6、对象间关系，建立 精化的业务对象模型，形成业务对象纵览；7) 分析业务上的非功能性需求，形成增补业务规格；8) 应用业务对象，实现业务用例，制定业务用例实现规格，以验证业务对象与业务用 例的正确性，根据验证结果，修正业务对象、业务用例及相关文档；9) 汇总业务规则业务用例规格业务对象纵览增补业务规格和业务用例 实现规格形成业务架构文档。2.2.2 持续性活动描述1) 业务概览在业务建模阶段，根据对项目理解的不断加深，随时进行改进；2) 术语表的更新维护；2.2.3 提交文档1) 业务概览2) 术语表3) 调研记录表册4) 业务架构文档其附件包括：业务规则业务用例规格业务对象纵览增 补业务规格和

7、业务用例实现规格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) 结合增补业务规格，细致分析用例资源条件，形成初始增补规格，同时剔除无 法实

8、现的初始用例，形成初始用例规格；4) 为初始用例分析划分优先级、分析依赖性，建立初始用例模型，结合初始增补规格 形成初始软件需求规格，为子系统分析或包、组件分析奠定基础；5) 精化初始用例模型中的用例，详细描述系统交互过程，建立精化的用例模型，用例规 格；6) 根据初始增补规格和业务规则 ，进一步深入分析系统的非功能性需求， 形成增 补规格；7) 汇总用例规格增补规格形成软件需求规格。2.3.2 持续性活动描述1) 项目概览(系统)在需求阶段，根据对项目理解的不断加深，随时进行改进；2) 术语表的更新维护；3) 通过快速原型的开发、 试用、修改，与客户和用户交流以不断获取系统需求， 并形成用

9、户原型界面描述。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) 根据需求规格说明 和系统软件架构， 进一步扩展业务对象模型， 建立分析对象模型， 明

10、确系统对象的职责；3) 根据业务对象，及业务对象之间的关系，结合分析对象和系统软件架构，进行数据库的 分析设计，建立数据模型，完成数据库设计工作，形成数据模型纵览；4) 应用分析对象实现系统用例，以验证分析对象的正确性，并根据验证结果，修正分析对 象模型；5) 汇总分析对象模型和基于分析对象的用例实现，形成分析模型纵览；6) 根据分析对象模型，结合用户原型界面和数据模型，进行系统类设计，建立设计类模型 和构件图；7) 实施系统类的详细设计，确定类的属性、方法及参数类型、可见性等，并将用例分配给 对象类，形成基于设计类的用例实现；8) 汇总设计类模型和基于设计类的用例实现，形成设计模型纵览，为下

11、一步系统的实 现明确工作任务。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)

12、编制用户手册，制作并集成系统帮助，完成客户或用户所需要的其他文档。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 概述在本规范中，对软件开发过程的管理，采用阶段性规划。具体为根据软件开发过程中的技术 过程，明确开发阶段，主要依据技术过程规范所描述的技术过程阶段划分；而后，将各阶段根据 项目的具体情况和实施要求，划分为利于监控管理的一个或多个迭代过程。本规范对于项目的计划和进度安排，采用由粗到细、由简到繁的方

13、式，首先制定描述软件开 发过程总体阶段和迭代的软件开发计划，而后根据所划分的迭代过程，在每个迭代开始时，对该 迭代过程进行详细的任务分配和进度规划。本规范中所提到的 软件开发计划 ，包含了开发计划、质量管理计划、技术支持计划等多项 内容，但主要以开发计划为主，其他计划视具体项目、团队情况确定是否制定。在本规范中风险管理贯穿整个软件开发过程，包括风险列表的更新维护、风险的跟踪管 理。对本规范中的各开发计划的具体实施说明，可参见项目监控管理办法相关说明。 规范中各阶段提到的管理评审，具体参见评审规范中所对应管理性评审的详细描述。3.2 接受项目3.2.1 活动描述1) 根据项目概览标识和评估风险，

14、制定风险列表；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) 根据不断修正维护的风险列表，完善风险防

15、范和解决措施，改进风险管理计划；2) 根据商业案例中说明的项目的开发要求，结合资源和风险状况，建立项目工作分析 结构(WBS)，明确开发阶段和迭代次数， 同时完成其他开发相关的计划内容， 形成软 件开发计划。3.4.2 提交文档1) 修正的风险管理计划2) 软件开发计划3.4.3 管理评审1) 开发计划评审3.5 迭代开发管理3.5.1 活动描述1) 根据软件开发计划，结合具体的开发状况和资源获取情况，确定在一个迭代期间的开发任务，进度安排，形成迭代计划，并更新软件开发计划；2) 按照迭代计划，将工作任务形成任务单，描述任务要求，明确开发人员职责；3) 根据本次迭代开发的完成情况和提交的成果，

16、 对该迭代开发过程进行分析评价， 形成迭 代评价，并根据实际情况，提出变更请求。3.5.2 提交文档1) 修正的软件开发计划2) 迭代计划3) 任务单4) 变更请求3.5.3 管理评审1) 迭代计划评审2) 迭代评价标准评审3) 迭代评价评审3.6 监控项目的实施3.6.1 活动描述1) 在项目开发过程中随时监控项目的状态，了解项目的进展，特别是根据风险列表， 跟踪风险，及时发现问题，并根据监控结果，及时更新、维护风险列表；2) 分析项目监控过程中发现和出现的问题和意外情况， 制定解决办法， 提出变更请求 ；3) 在监控过程中，根据实际开发情况，调整软件开发计划和迭代计划，并更新和 分配新的任

17、务单；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) 项目状况评价柱务名称IhlratigFrdecessors枉务名称DUrati OrlFret枉务名珈BUrat

18、iOTl1日技术过程103 CiayS34-实现阶段40 IlaySS7制罡迭代计划2 day3.5 dy23日业勞建複阶段25 day35建立实现模型和集成複型4 day33BS形成工作单问题定义2 days36姐件編码24 days35旳迭代开发14 (Iay54业务调研3 days337系统集成实现9 day：3670迭代评协3 dy5 IB自动化分折4 days43S用尸文档編制3 days37Tl-迭代开发管理Ifi d*y崖立域複型3 days53972制定迭代计划2 dT3精化业务用例4 iays540日管理过程104 days73形成工作单3, S d4y3精化业雰対象3 da

19、ys741曰接竟项目3 IIayS74迭代开发9. 5 (IEJrSg分析非功能业务需求2 dy342标识风险1 dyT5迭代评怖3 dy10业务用例实现2 dys943制定凤险策略1 day4276F项目监控96 day¾11i匚总业务架物文档2 days1044制定商业案例1 day4377监控项目状况96 dyIZ更新雒护术语表25 days45T重新评瞥顶目范围和凤脸Z daysI Te处理问题和意外96 (Iay 313改进项目梅览25 daysS修正风险列表1 day4479调整开挖计划96 dy14凹需求阶段16 days47改进商业秦例1 dy46汇报项目状况96 djr15界定系妊范園2 days1148B制定开发计划Z day