软件开发过程规范共12页.docx
- 文档编号:337405
- 上传时间:2022-10-09
- 格式:DOCX
- 页数:13
- 大小:61.51KB
软件开发过程规范共12页.docx
《软件开发过程规范共12页.docx》由会员分享,可在线阅读,更多相关《软件开发过程规范共12页.docx(13页珍藏版)》请在冰豆网上搜索。
软件开发过程规范共12页
软件开发过程规范
一般说来,“教师”概念之形成经历了十分漫长的历史。
杨士勋(唐初学者,四门博士)《春秋谷梁传疏》曰:
“师者教人以不及,故谓师为师资也”。
这儿的“师资”,其实就是先秦而后历代对教师的别称之一。
《韩非子》也有云:
“今有不才之子……师长教之弗为变”其“师长”当然也指教师。
这儿的“师资”和“师长”可称为“教师”概念的雏形,但仍说不上是名副其实的“教师”,因为“教师”必须要有明确的传授知识的对象和本身明确的职责。
版本<1.0>
我国古代的读书人,从上学之日起,就日诵不辍,一般在几年内就能识记几千个汉字,熟记几百篇文章,写出的诗文也是字斟句酌,琅琅上口,成为满腹经纶的文人。
为什么在现代化教学的今天,我们念了十几年书的高中毕业生甚至大学生,竟提起作文就头疼,写不出像样的文章呢?
吕叔湘先生早在1978年就尖锐地提出:
“中小学语文教学效果差,中学语文毕业生语文水平低,……十几年上课总时数是9160课时,语文是2749课时,恰好是30%,十年的时间,二千七百多课时,用来学本国语文,却是大多数不过关,岂非咄咄怪事!
”寻根究底,其主要原因就是腹中无物。
特别是写议论文,初中水平以上的学生都知道议论文的“三要素”是论点、论据、论证,也通晓议论文的基本结构:
提出问题――分析问题――解决问题,但真正动起笔来就犯难了。
知道“是这样”,就是讲不出“为什么”。
根本原因还是无“米”下“锅”。
于是便翻开作文集锦之类的书大段抄起来,抄人家的名言警句,抄人家的事例,不参考作文书就很难写出像样的文章。
所以,词汇贫乏、内容空洞、千篇一律便成了中学生作文的通病。
要解决这个问题,不能单在布局谋篇等写作技方面下功夫,必须认识到“死记硬背”的重要性,让学生积累足够的“米”。
修订历史纪录
唐宋或更早之前,针对“经学”“律学”“算学”和“书学”各科目,其相应传授者称为“博士”,这与当今“博士”含义已经相去甚远。
而对那些特别讲授“武事”或讲解“经籍”者,又称“讲师”。
“教授”和“助教”均原为学官称谓。
前者始于宋,乃“宗学”“律学”“医学”“武学”等科目的讲授者;而后者则于西晋武帝时代即已设立了,主要协助国子、博士培养生徒。
“助教”在古代不仅要作入流的学问,其教书育人的职责也十分明晰。
唐代国子学、太学等所设之“助教”一席,也是当朝打眼的学官。
至明清两代,只设国子监(国子学)一科的“助教”,其身价不谓显赫,也称得上朝廷要员。
至此,无论是“博士”“讲师”,还是“教授”“助教”,其今日教师应具有的基本概念都具有了。
日期
版本
描述
作者
<年/月/日>
<细节>
<名>
软件开发过程规范
1.前言
目的
本规范的目的是使整个软件产品开发及项目工程阶段清晰,要求明确,任务具体,便于规范化、系统化及工程化。
有利于提高软件生命周期的控制及管理,提高所开发软件的质量,缩短开发时间,减少开发和维护费用,使软件开发活动更科学、更有成效。
对象
本规范面向产品生命周期的所有相关人员,包括管理人员、开发人员、质管人员。
要求
具有软件开发管理职能的人员要求熟知项目开发的各阶段过程和各阶段过程相应的规范。
适用范围
适用于产品开发生命周期中的除产品提交外的其他全部过程;规范分为两部分:
技术过程规范和管理过程规范,分别适用于软件开发过程中的技术性活动和管理性活动。
软件开发过程模型
本规范所采用的软件开发过程模型为简化的RUP开发过程模型;软件开发过程是体系结构为中心,用例驱动和风险驱动相结合的过程迭代。
开发过程划分
开发过程包括多次迭代,每次迭代的目标和侧重点不同;较早的迭代侧重于业务建模和需求建模;而后的迭代则侧重于分析设计和编码。
2.技术过程规范部分
概述
本规范中将软件开发的整个技术过程分为四个顺序实施的阶段,分别为业务建模阶段、需求阶段、分析设计阶段和实现阶段。
在对技术过程规范的描述,按阶段内部的活动和产物对四个阶段分别说明。
在本规范中对阶段内活动的说明,是按顺序性活动和持续性活动两类分别进行说明。
对于顺序性活动是按该阶段中活动的总体顺序进行的描述,而在实际工作中,从各活动的具体实施的细节来看,各活动之间的顺序是不断交叉变化的。
对于持续性活动主要是对贯穿该阶段过程始终的技术活动进行说明。
规范中所提到的可选文档是指在其所属阶段,可根据具体情况灵活掌握,开发团队自主决定是否开发的文档产物。
而提交文档则是指在项目开发过程中必须开发的文档产物,但可根据具体项目情况,在软件开发计划中明确规定是否要形成正式文档并提交。
规范中各阶段提到的技术评审,具体参见《评审规范》中所对应技术性评审的详细描述。
业务建模阶段
顺序性活动描述
1)开始初步调研,获取初始业务需求,进行问题定义,形成《业务概览》并建立《术语表》;
2)制定《调研记录表册》,实施详细的业务调研,建立初始的业务用例模型和《业务用例规格》;
3)分析业务过程,取出可以实现自动化的用例,分析业务部门和实体对象,形成初始的业务对象模型;
4)根据初始业务对象模型和初始业务用例模型,分析并提取与系统实现相关的用例和模型,建立系统域模型;
5)精化域模型中的初始用例,详细描述业务流程,分析业务规则,建立精化的业务用例模型,形成《业务规则》和《业务用例规格》;
6)精化域模型中的初始对象,进行详细的对象描述,分析对象职责和对象间关系,建立精化的业务对象模型,形成《业务对象纵览》;
7)分析业务上的非功能性需求,形成《增补业务规格》;
8)应用业务对象,实现业务用例,制定《业务用例实现规格》,以验证业务对象与业务用例的正确性,根据验证结果,修正业务对象、业务用例及相关文档;
9)汇总《业务规则》《业务用例规格》《业务对象纵览》《增补业务规格》和《业务用例实现规格》形成《业务架构文档》。
持续性活动描述
10)《业务概览》在业务建模阶段,根据对项目理解的不断加深,随时进行改进;
11)《术语表》的更新维护;
提交文档
12)《业务概览》
13)《术语表》
14)《调研记录表册》
15)《业务架构文档》其附件包括:
《业务规则》《业务用例规格》《业务对象纵览》《增补业务规格》和《业务用例实现规格》
可选文档
16)《目标组织评价》
文档规范
17)《业务概览》
18)《术语表》
19)《项目调研表册》
20)《业务架构文档》
21)《业务规则》
22)《业务用例规格》
23)《业务对象纵览》
24)《增补业务规格》
25)《业务用例实现规格》
26)《目标组织评价》
技术评审
27)业务用例模型评审
28)业务对象模型评审
需求阶段
顺序性活动描述
29)界定系统范围,明确委托方需求,形成《项目概览》(系统)《术语表》;
30)定义系统角色,根据《业务用例规格》,分析业务用例,将其转换为系统初始用例,并开始系统原型界面的开发;
31)结合《增补业务规格》,细致分析用例资源条件,形成初始《增补规格》,同时剔除无法实现的初始用例,形成初始《用例规格》;
32)为初始用例分析划分优先级、分析依赖性,建立初始用例模型,结合初始《增补规格》形成初始《软件需求规格》,为子系统分析或包、组件分析奠定基础;
33)精化初始用例模型中的用例,详细描述系统交互过程,建立精化的用例模型,《用例规格》;
34)根据初始《增补规格》和《业务规则》,进一步深入分析系统的非功能性需求,形成《增补规格》;
35)汇总《用例规格》《增补规格》形成《软件需求规格》。
持续性活动描述
36)《项目概览》(系统)在需求阶段,根据对项目理解的不断加深,随时进行改进;
37)《术语表》的更新维护;
38)通过快速原型的开发、试用、修改,与客户和用户交流以不断获取系统需求,并形成《用户原型界面描述》。
提交文档
39)《项目概览》(系统)
40)《术语表》
41)《需求规格说明》其附件包括:
《用例规格》《增补规格》
42)《用户原型界面描述》
可选文档
43)《用户接口风格说明》
44)《委托方需求》
45)《用户手册》(初稿)
文档规范
46)《项目概览》(系统)
47)《需求规格说明》
48)《术语表》
49)《用例规格》
50)《增补规格》
51)《用户原型界面描述》
技术评审
52)需求评审
分析设计阶段
顺序性活动描述
53)根据《系统需求规格》进行体系结构分析设计,确定系统软件架构,形成配置图和《软件架构文档》;
54)根据《需求规格说明》和系统软件架构,进一步扩展业务对象模型,建立分析对象模型,明确系统对象的职责;
55)根据业务对象,及业务对象之间的关系,结合分析对象和系统软件架构,进行数据库的分析设计,建立数据模型,完成数据库设计工作,形成《数据模型纵览》;
56)应用分析对象实现系统用例,以验证分析对象的正确性,并根据验证结果,修正分析对象模型;
57)汇总分析对象模型和基于分析对象的用例实现,形成《分析模型纵览》;
58)根据分析对象模型,结合用户原型界面和数据模型,进行系统类设计,建立设计类模型和构件图;
59)实施系统类的详细设计,确定类的属性、方法及参数类型、可见性等,并将用例分配给对象类,形成基于设计类的用例实现;
60)汇总设计类模型和基于设计类的用例实现,形成《设计模型纵览》,为下一步系统的实现明确工作任务。
持续性活动描述
无。
提交文档
61)《软件架构文档》
62)《分析模型纵览》
63)《设计模型纵览》
64)《数据模型纵览》
可选文档
无。
文档规范
65)《软件架构文档》
66)《分析模型纵览》
67)《设计模型纵览》
68)《数据模型纵览》
技术评审
69)软件架构评审
70)设计评审
实现阶段
顺序性活动描述
71)根据《设计类模型》,按照类的详细设计和构件图,结合用例的实现优先级,确定系统《实现模型》,并根据系统体系结构进行系统集成设计,形成《集成模型》;
72)根据《实现模型》进行组件编码实现;
73)根据《集成模型》对系统编码实现的组件进行系统集成实现;
74)编制《用户手册》,制作并集成系统帮助,完成客户或用户所需要的其他文档。
持续性活动描述
无。
提交文档
75)《实现模型》
76)《集成设计》
可选文档
77)《用户手册》
文档规范
78)《实现模型》
79)《集成设计》
80)《用户手册》
技术评审
81)代码评审
3.管理过程规范部分
概述
在本规范中,对软件开发过程的管理,采用阶段性规划。
具体为根据软件开发过程中的技术过程,明确开发阶段,主要依据技术过程规范所描述的技术过程阶段划分;而后,将各阶段根据项目的具体情况和实施要求,划分为利于监控管理的一个或多个迭代过程。
本规范对于项目的计划和进度安排,采用由粗到细、由简到繁的方式,首先制定描述软件开发过程总体阶段和迭代的软件开发计划,而后根据所划分的迭代过程,在每个迭代开始时,对该迭代过程进行详细的任务分配和进度规划。
本规范中所提到的《软件开发计划》,包含了开发计划、质量管理计划、技术支持计划等多项内容,但主要以开发计划为主,其他计划视具体项目、团队情况确定是否制定。
在本规范中风险管理贯穿整个软件开发过程,包括《风险列表》的更新维护、风险的跟踪管理。
对本规范中的各开发计划的具体实施说明,可参见《项目监控管理办法》相关说明。
规范中各阶段提到的管理评审,具体参见《评审规范》中所对应管理性评审的详细描述。
接受项目
活动描述
82)根据《项目概览》标识和评估风险,制定《风险列表》
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 开发 过程 规范 12
![提示](https://static.bdocx.com/images/bang_tan.gif)