软件开发过程的相关规范

1、软件开发过程标准版本1,0修订历史纪录日期版本描述作者年/月/日<x.x>尊田节<名>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 目的本标准的目的是使整个软件产品开

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、业务用例规格?7?业务对象纵览?8?增补业务规格?9?业务用例实现规格?10?目标组织评价?2.2.6 技术评审1业务用例模型评审2业务对象模型评审2.3 需求阶段2.3.1 顺序性活动描述1界定系统范围,明确委托方需求,形成?工程概览?系统?术语表?；2定义系统角色,根据?业务用例规格?,分析业务用例,将其转换为系统初始用例,并 开始系统原型界面的开发；3结合?增补业务规格?,细致分析用例资源条件,形成初始?增补规格?,同时剔除无 法实现的初始用例,形成初始?用例规格?；4为初始用例分析划分优先级、分析依赖性,建立初始用例模型,结合初始?增补规格?形成初始?软件需求规格?,为子系统分析或包、

8、组件分析奠定根底；5精化初始用例模型中的用例,详细描述系统交互过程,建立精化的用例模型,?用例规 格?；6根据初始?增补规格?和?业务规那么?,进一步深入分析系统的非功能性需求, 形成?增 补规格?；7汇总?用例规格?增补规格?形成?软件需求规格?.2.3.2 持续性活动描述1?工程概览?系统在需求阶段,根据对工程理解的不断加深,随时进行改良；2?术语表?的更新维护；3通过快速原型的开发、试用、修改,与客户和用户交流以不断获取系统需求,并形成?用 户原型界面描述?.2.3.3 提交文档1?工程概览?系统2?术语表?3?需求规格说明?其附件包括：?用例规格?增补规格?4?用户原型界面描述?2.3

9、.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根据业务对象,及业务对象之间的关系,结合分析对象和系统软件架构,进行数据库的分析设计,建立数据模型,完成数据库设计工作,形成?数据模型纵

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

11、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?用户手册

12、?2.5.5 文档标准1?实现模型?2?集成设计?3?用户手册?2.5.6 技术评审1代码评审3.经管过程标准局部3.1 概述在本标准中,对软件开发过程的经管,采用阶段性规划.具体为根据软件开发过程中的技术 过程,明确开发阶段,主要依据技术过程标准所描述的技术过程阶段划分；而后,将各阶段根据 工程的具体情况和实施要求,划分为利于监控经管的一个或多个迭代过程.本标准对于工程的方案和进度安排,采用由粗到细、由简到繁的方式,首先制定描述软件开 发过程总体阶段和迭代的软件开发方案,而后根据所划分的迭代过程,在每个迭代开始时,对该 迭代过程进行详细的任务分配和进度规划.本标准中所提到的?软件开发方案?,

13、包含了开发方案、质量经管方案、技术支持方案等多项 内容,但主要以开发方案为主,其他方案视具体工程、团队情况确定是否制定.在本标准中风险经管贯穿整个软件开发过程,包括?风险列表?的更新维护、风险的跟踪经 管.对本标准中的各开发方案的具体实施说明,可参见?工程监控经管方法?相关说明.标准中各阶段提到的经管评审,具体参见?评审标准?中所对应经管性评审的详细描述.3.2 接受工程3.2.1 活动描述1根据?工程概览?标识和评估风险,制定?风险列表?；2分析工程风险,制定风险防范和解决举措,形成?风险经管方案?；3分析可行性和商业价值,制定?商业案例?；3.2.2 提交文档1?风险列表?2?风险经管方案

14、?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,明确开发阶段和迭代次数,同时完成其他开发相关

15、的方案内容,形成?软 件开发方案?.3.4.2 提交文档1修正的?风险经管方案?2?软件开发方案?3.4.3 经管评审1开发方案评审3.5 迭代开发经管3.5.1 活动描述1根据?软件开发方案?,结合具体的开发状况和资源获取情况,确定在一个迭代期间的 开发任务,进度安排,形成?迭代方案?,并更新?软件开发方案?；2根据?迭代方案?,将工作任务形成?任务单?,描述任务要求,明确开发人员责任；3根据本次迭代开发的完成情况和提交的成果, 对该迭代开发过程进行分析评价,形成?迭 代评价?,并根据实际情况,提出?变更请求?.3.5.2 提交文档1修正的?软件开发方案?2?迭代方案?3?任务单?3.5.3

16、 ?变更请求?3.5.4 经管评审1迭代方案评审2迭代评价标准评审3迭代评价评审3.6 监控工程的实施3.6.1 活动描述1在工程开发过程中随时监控工程的状态,了解工程的进展,特别是根据?风险列表?, 跟踪风险,及时发现问题,并根据监控结果,及时更新、维护?风险列表?；2分析工程监控过程中发现和出现的问题和意外情况,制定解决方法,提出?变更请求?；3在监控过程中,根据实际开发情况,调整?软件开发方案?和?迭代方案?,并更新和分配新的?任务单?；4应工程经管和客户的要求,定期或不定期根据工程的当前状况,制定?工程状况评价?,进行工程开发状况的汇报.3.6.2 提交文档1修正的?风险列表?2修正的

17、?软件开发方案?3修正的?迭代方案?4?任务单?5） ?变更请求?6?工程状况评价?3.6.3 经管评审1） 1. PRA 评审3.7 结束工程3.7.1 活动描述1在工程开发任务全部完成,开发过程结束时,归纳总结工程的开发过程,分析和评价工 程完成情况和提交的成果,形成最终的?工程状况评价?,提交验收.3.7.2 提交文档1?工程状况评价?3.7.3 经管评审1工程验收评审e苣任务名称Snrati onFradfic«ssorE任备名称DurationPra(任务名标Duration1臼技术过程103 days34-实现阶段40 days67制定选代方案2 day；£亚翁

18、建程阶段25 dtyc35建立实现模型和集成模型4 diy?3366形成工作单工.5 dayt3问题定义2 days36蛆件编蚂24 diys3569迭代开发14 diys4业与调研3 days337系综集成赛现9 lays3670迭代评侨3 a町与5自动化分析4 dn.ys438用户文揩编制3 dtys3771迭代开发治理18 days6建立城模型3 dys53Q72制定迭代方案2 days7精化业务用例4 days&40三治理过程104 days73报成工佗单3.5 daysS精化业务对募3 dtysT41-接受工程3 duys74迭代开废9.5 daysg分析韭功多需求2 daysS42标识风随1 day75迭代评价3 dsys10业翁用例实现2 jaysg43制定血脸策略1 day醛76日工程监控96 day目11汇总业架的交者2 day.1044制定商业案例1 day437T监控工程状况96 day鹫12更需维护末活衰25 d*ys45日重新评怙工程范国和风隆2 diys70处理同题和意外96 days13改良工程概览25 days46修正凤脸列表1 day4475调整开鞋方案96 days14-需求阶段1& days47改良商业案例1 day明SO汇报璃目状况96 d%ysIE界定系蟒范围2 daysn48制定开发方案2 (kys81日结束工程1 di