软件开发过程的相关规范.docx

1、软件开发过程的相关规范软件开发过程规范版本 修订历史纪录日期版本描述作者软件开发过程规范1. 前言目的本规范的目的是使整个软件产品开发及工程工程阶段清晰，要求明确，任务具体，便于规范化、系统化及工程化。有利于提高软件生命周期的控制及经管，提高所开发软件的质量，缩短开发时间，减少开发和维护费用，使软件开发活动更科学、更有成效。对象本规范面向产品生命周期的所有相关人员，包括经管人员、开发人员、质管人员。要求具有软件开发经管职能的人员要求熟知工程开发的各阶段过程和各阶段过程相应的规范。适用范围适用于产品开发生命周期中的除产品提交外的其他全部过程；规范分为两部分：技术过程规范和经管过程规范，分别适用于

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

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

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

5、验证业务对象与业务用例的正确性，根据验证结果，修正业务对象、业务用例及相关文档；9) 汇总业务规则业务用例规格业务对象纵览增补业务规格和业务用例实现规格形成业务架构文档。持续性活动描述10) 业务概览在业务建模阶段，根据对工程理解的不断加深，随时进行改进；11) 术语表的更新维护；提交文档12) 业务概览13) 术语表14) 调研记录表册15) 业务架构文档其附件包括：业务规则业务用例规格业务对象纵览增补业务规格和业务用例实现规格可选文档16) 目标组织评价文档规范17) 业务概览18) 术语表19) 工程调研表册20) 业务架构文档21) 业务规则22) 业务用例规格23) 业务对象纵览24

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

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

8、程概览（系统）47) 需求规格说明48) 术语表49) 用例规格50) 增补规格51) 用户原型界面描述技术评审52) 需求评审分析设计阶段顺序性活动描述53) 根据系统需求规格进行体系结构分析设计，确定系统软件架构，形成配置图和软件架构文档；54) 根据需求规格说明和系统软件架构，进一步扩展业务对象模型，建立分析对象模型，明确系统对象的职责；55) 根据业务对象，及业务对象之间的关系，结合分析对象和系统软件架构，进行数据库的分析设计，建立数据模型，完成数据库设计工作，形成数据模型纵览； 56) 应用分析对象实现系统用例，以验证分析对象的正确性，并根据验证结果，修正分析对象模型；57) 汇总分

9、析对象模型和基于分析对象的用例实现，形成分析模型纵览；58) 根据分析对象模型，结合用户原型界面和数据模型，进行系统类设计，建立设计类模型和构件图；59) 实施系统类的详细设计，确定类的属性、方法及参数类型、可见性等，并将用例分配给对象类，形成基于设计类的用例实现；60) 汇总设计类模型和基于设计类的用例实现，形成设计模型纵览，为下一步系统的实现明确工作任务。持续性活动描述无。提交文档61) 软件架构文档62) 分析模型纵览63) 设计模型纵览64) 数据模型纵览可选文档无。文档规范65) 软件架构文档66) 分析模型纵览67) 设计模型纵览68) 数据模型纵览技术评审69) 软件架构评审70

10、) 设计评审实现阶段顺序性活动描述71) 根据设计类模型，按照类的详细设计和构件图，结合用例的实现优先级，确定系统实现模型，并根据系统体系结构进行系统集成设计，形成集成模型；72) 根据实现模型进行组件编码实现；73) 根据集成模型对系统编码实现的组件进行系统集成实现；74) 编制用户手册，制作并集成系统帮助，完成客户或用户所需要的其他文档。持续性活动描述无。提交文档75) 实现模型76) 集成设计可选文档77) 用户手册文档规范78) 实现模型79) 集成设计80) 用户手册技术评审81) 代码评审3. 经管过程规范部分概述在本规范中，对软件开发过程的经管，采用阶段性规划。具体为根据软件开发

11、过程中的技术过程，明确开发阶段，主要依据技术过程规范所描述的技术过程阶段划分；而后，将各阶段根据工程的具体情况和实施要求，划分为利于监控经管的一个或多个迭代过程。本规范对于工程的计划和进度安排，采用由粗到细、由简到繁的方式，首先制定描述软件开发过程总体阶段和迭代的软件开发计划，而后根据所划分的迭代过程，在每个迭代开始时，对该迭代过程进行详细的任务分配和进度规划。本规范中所提到的软件开发计划，包含了开发计划、质量经管计划、技术支持计划等多项内容，但主要以开发计划为主，其他计划视具体工程、团队情况确定是否制定。在本规范中风险经管贯穿整个软件开发过程，包括风险列表的更新维护、风险的跟踪经管。对本规范

12、中的各开发计划的具体实施说明，可参见工程监控经管办法相关说明。规范中各阶段提到的经管评审，具体参见评审规范中所对应经管性评审的详细描述。接受工程活动描述82) 根据工程概览标识和评估风险，制定风险列表；83) 分析工程风险，制定风险防范和解决措施，形成风险经管计划；84) 分析可行性和商业价值，制定商业案例；提交文档85) 风险列表86) 风险经管计划87) 商业案例经管评审88) 工程批准评审重新评估工程范围和风险（对于较大工程）活动描述89) 根据工程概览和对工程进一步深入了解，重新标识和评估风险，改进风险列表；90) 根据修正工程风险，重新分析工程可行性和商业价值，改进商业案例；提交文档

13、91) 修正的风险列表92) 修正的商业案例经管评审无。制定开发计划活动描述93) 根据不断修正维护的风险列表，完善风险防范和解决措施，改进风险经管计划；94) 根据商业案例中说明的工程的开发要求，结合资源和风险状况，建立工程工作分析结构（WBS），明确开发阶段和迭代次数，同时完成其他开发相关的计划内容，形成软件开发计划。提交文档95) 修正的风险经管计划96) 软件开发计划经管评审97) 开发计划评审迭代开发经管活动描述98) 根据软件开发计划，结合具体的开发状况和资源获取情况，确定在一个迭代期间的开发任务，进度安排，形成迭代计划，并更新软件开发计划；99) 按照迭代计划，将工作任务形成任务

14、单，描述任务要求，明确开发人员职责；100) 根据本次迭代开发的完成情况和提交的成果，对该迭代开发过程进行分析评价，形成迭代评价，并根据实际情况，提出变更请求。提交文档101) 修正的软件开发计划102) 迭代计划103) 任务单104) 变更请求经管评审105) 迭代计划评审106) 迭代评价规范评审107) 迭代评价评审监控工程的实施活动描述108) 在工程开发过程中随时监控工程的状态，了解工程的进展，特别是根据风险列表，跟踪风险，及时发现问题，并根据监控结果，及时更新、维护风险列表；109) 分析工程监控过程中发现和出现的问题和意外情况，制定解决办法，提出变更请求；110) 在监控过程中，根据实际开发情况，调整软件开发计划和迭代计划，并更新和分配新的任务单；111) 应工程经管和客户的要求，定期或不定期根据工程的当前状况，制定工程状况评价，进行工程开发状况的汇报。提交文档112) 修正的风险列表113) 修正的软件开发计划114) 修正的迭代计划115) 任务单116) 变更请求117) 工程状况评价经管评审118) 1PRA评审结束工程活动描述119) 在工程开发任务全部完成，开发过程结束时，归纳总结工程的开发过程，分析和评价工程完成情况和提交的成果，形成最终的工程状况评价，提交验收。提交文档120) 工程状况评价经管评审121) 工程验收评审附件：软件开发过程规范示意图