软件设计编码规范标准[详]
- 格式:doc
- 大小:208.50 KB
- 文档页数:9
通用编码规范1.引言本规范编制是为了指导程序员编码,其目的是:1)改善软件的可读性,使程序员尽快而彻底地理解新的代码;2)防止新接触本语言的人出于节省时间的需要,自创与组织成员不相容的一套风格;3)防止新接触本语言的人一次次的犯同样的错误;4)新加入的程序员可以很快的适应环境;5)在一致的环境下,减少程序员犯错的机会。
2.编排风格约定编排风格应遵循下列规定:1)严格采用阶梯层次组织程序代码:各层次缩进的分格采用VC的缺省风格,即每层次缩进为4格。
功能块、语句块的边界大括号一律独占一行,相匹配的大括号在同一列,对继行则要求再缩进4格;2)对变量的定义,尽量位于函数的开始位置;3)函数名之后不要留空格,紧跟左括号‘(’,以与关键字区别;4)‘(’向后紧跟,‘)’、‘,’、‘;’向前紧跟,紧跟处不留空格;5)‘,’之后要留空格,如Function(x, y, z)。
如果‘;’不是一行的结束符号,其后要留空格,如for (initialization; condition; update);6)赋值操作符、比较操作符、算术操作符、逻辑操作符、位域操作符,如“=”、“+=”“>=”、“<=”、“+”、“*”、“%”、“&&”、“||”、“<<”,“^”等二元操作符的前后应当加空格;但是,对于表达式比较长的for语句和if语句,为了紧凑起见可以适当地去掉一些空格,如for (i=0; i<10; i++)和if ((a<=b) && (c<=d));7)一元操作符如“!”、“~”、“++”、“--”、“&”(地址运算符)等前后不加空格。
“[]”、“.”、“->”等操作符前后不加空格;8)修饰符*和&紧靠变量名。
9)各个大的功能块之间最好留一空行以及适当的注释;10) if、for、do、while、switch、case、default等语句自占一行,且if、for、do、while 等语句的执行语句部分无论多少都要加括号{ },对“return语句”不要求;11)不允许把多个短语句写在一行中,即一行只写一条语句;12)长表达式要在低优先级操作符处拆分成新行,操作符放在新行之首(以便突出操作符),拆分出的新行要进行适当的缩进,使排版整齐,语句可读;13)对于switch…case…语句,break语句要放在{ }内。
软件项目代码编码规范
软件项目代码编码规范
一、前言
本规范旨在为软件项目的代码编写提供统一的标准和规范,以提高代码质量、可读性、可维护性和可扩展性。
本规范涵盖了代码格式、命名规范、注释规范、代码优化等方面的内容,适用于各类软件开发项目。
二、代码格式
1.缩进:使用4个空格进行缩进,不使用制表符。
2.行宽:一行代码不超过80个字符。
3.换行:在运算符之后换行,例如a = b + c应写为:
a =
b +
c
4.空行:在函数之间、类定义之间和逻辑段落之间插入空行,以增加代码可
读性。
三、命名规范
5.变量名:使用小写字母和下划线,例如my_variable。
6.函数名:使用小写字母和下划线,例如my_function()。
7.类名:使用驼峰命名法,例如MyClass。
8.常量名:使用全大写字母和下划线,例如MY_CONSTANT。
9.模块名:使用小写字母和下划线,例如my_module.py。
10.数据库表名:使用驼峰命名法,例如my_table。
11.字段名:使用驼峰命名法,例如my_field。
12.避免使用具有特殊含义的缩写或简写,例如sum应写为total。
四、注释规范
13.对变量、函数、类等进行注释,解释其作用和用法。
14.对于复杂的代码段或算法,应添加注释以说明意图。
15.使用文档字符串(docstrings)对函数、类等进行详细说明。
16.避免过度注释,尽量让代码本身可读性强。
17.在需要注释的地方使用英文注释,以提高代码国际化程度。
软件编码规范编制审核批准发布日期 20XX-XX-XX目录1 计划规范 (6)1.1考虑冗余时间 (6)1.2尽早制定软件部署方案和用户反馈方案 (6) (6)2 版本规范 (8)3 C/C++代码规范 (9)3.1排版、布局 (9)3.2注释 (11)3.3命名 (13)3.4可读性 (14)3.5变量、结构 (14)3.6函数、过程 (15)3.7类 (16)3.8可测性 (16)3.9程序效率 (17)3.10质量保证 (17)3.11代码编辑、编译、审查 (18)3.12代码测试 (19)3.13宏 (19)3.14其他 (21)阅读说明:◆加“【强制】”的条款为必须满足的内容。
◆加“【建议】”的条款为建议性的内容,根据具体情况实行,不做检查。
◆加“【说明】”的为补充性内容,可以作为实行与检查的依据。
◆其他条款默认为检查项,如果在某些情况下违反,说明理由。
1计划规范1.1 考虑冗余时间软件设计的工时预估是世界公认“估不准”问题,这是导致软件行业“加班”与“跳票”的重要原因。
现在比较通行的做法是:◆【建议】软件设计工作划分得尽量细;◆【建议】由具体的设计人员和上一级管理者预估具体任务的完成时间;◆【建议】在所有统计工时的基础上增加80%的时间;◆【建议】根据工作的进展尽早汇报并调整计划;1.2 尽早制定软件部署方案和用户反馈方案◆【建议】有些部署与反馈方案要在软件内部实现,比如:在线升级、故障数据保存与发送。
这些是软件设计的一部分,应整体考虑。
2版本规范◆【建议】软件产品(可执行文件、动态库等)和安装包使用如X.Y.Z.T的四段版本。
X.Y为主版本号,Z:功能变化时+1;T:逐次编译+1;功能变化且重新编译时,Z+1,T重新置0。
3C/C++代码规范3.1 排版、布局【目标】清晰,利于阅读,防范低级错误。
◆缩进为4个字符宽(使用TAB键,其宽度设置为4个空格)。
◆【建议】函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格,case语句下的情况处理语句也要遵从语句缩进要求。
软件工程规范软件工程规范============引言-软件工程规范是指在软件开发过程中,为了确保软件的质量、可维护性和可重用性而制定的一系列规定和标准。
规范的制定有助于提高软件开发效率,降低软件开发风险,并促进团队合作。
本文档将介绍一些常见的软件工程规范,旨在帮助开发人员和团队遵循最佳实践,提高软件开发质量。
编码规范--编码规范是一个团队共同遵守的标准,用于规范代码的书写风格和命名。
以下是一些常见的编码规范:1.命名规范:命名应具有一定的描述性,在命名变量、函数和类时,应采用有意义的名字。
使用驼峰命名法或下划线命名法来命名变量和函数。
示例:`myVariable`或`my_variable`。
2.缩进和空格:使用适当的缩进和空格来提高代码的可读性。
建议使用 4 个空格或一个制表符进行缩进。
3.注释:在代码中添加注释,解释代码的作用和用途。
注释应该简洁明了,并且容易理解。
4.避免使用魔术数:避免在代码中直接使用未解释的数字。
应该使用常量或变量来表示这些数字,并在代码中进行引用。
5.错误处理:在代码中处理异常情况,并提供适当的错误处理机制。
避免使用空的 try-catch 块。
代码版本管理代码版本管理是用于管理软件开发过程中代码的变更和版本的工具。
以下是一些常见的代码版本管理工具:1.Git:Git 是一个分布式版本控制工具,被广泛应用于软件开发过程中。
它提供了强大的分支管理和合并功能,便于团队协作和代码发布。
2.SVN:SVN 是一个集中式版本控制工具,也是软件开发中常用的版本管理工具。
它允许多用户同时工作在同一个项目中,可以对代码进行更加细粒度的权限控制。
3.分支管理:在开发过程中,使用分支来进行不同功能的开发和测试是一个常见的做法。
在使用分支时,应该定期进行分支合并,确保代码的一致性和稳定性。
文档标准--规范的文档可以帮助开发人员更好地理解和使用软件。
以下是一些常见的文档标准:1.需求文档:需求文档应包含清晰的功能描述,以及需求的优先级和截止日期等信息。
HTML5编码规规目的本文档的目标是使HTML5代码风格保持一致,容易被理解、维护和升级,提高团队协作效率, 便于后台人员添加功能及前端后期优化维护, 输出高质量的文档,同是为有一个更好的前端架构,的发展及未来打好一个基础。
基本准则符合web标准, 语义化html, 结构表现行为分离, 兼容性优良. 页面性能方面, 代码要求简洁明了有序, 尽可能的减小服务器负载, 保证最快的解析速度.文件规1、html, css, js, images文件均归档至约定的目录中。
2、html文件命名: 必须单词全字母小写,单词间以-分隔,依实际模块命名,如果同一模块以_& title& _ 来组合命名, 以方便添加功能时查找对应页面,团结里的相互理解。
HTML5代码规1. 代码风格1.1 缩进与换行[建议]使用4个空格作为一个缩进层级。
[建议]模板代码的缩进优先保证HTML 代码的缩进规则。
1.2 命名规则[强制]class:必须单词全字母小写,单词间以-分隔,且必须代表相应的模块或部件的容或功能,不得以html置样式进行命名,命名应该具有明确的语义。
[强制]id:必须保持在页面中的唯一性,命名应该具有明确的语义。
1.3 标签[强制]Html中的标签名必须使用小写字母。
[强制]标签的闭合要符合html5的规定。
[强制]标签的使用必须符合标签的嵌套规则,例:div不得置于p中,tbody必须置于table 中。
[建议]标签的使用必须遵循标签的语义,例:p -段落h1,h2,h3,h4,h5,h6 -层级标题strong,em -强调ins -插入del -删除abbr -缩写code -代码标识cite -引述来源作品的标题q -引用blockquote -一段或长篇引用ul -无序列表ol -有序列表dl,dt,dd -定义列表[建议]在CSS可以实现相同需求的情况下不得使用表格进行布局。
1.4 属性[强制]属性必须使用小写字母,其属性值必须用双引号包围。
软件工程规范(二)引言:软件工程规范是指在软件开发过程中,为了达到高质量的软件产品而制定的一系列标准和规范。
本文将介绍软件工程规范的相关内容,包括需求分析、设计、编码、测试和文档编写等方面的规范。
正文:1. 需求分析规范小点1: 确定需求的具体范围和优先级小点2: 分析需求的稳定性和可行性小点3: 编写清晰、准确的需求文档小点4: 与客户充分沟通,确保需求理解一致小点5: 实施需求变更管理,避免频繁修改需求2. 设计规范小点1: 使用合适的设计模式和架构,提高系统的可扩展性和维护性小点2: 制定设计规范,确保代码的一致性和可读性小点3: 进行详细的系统设计和模块设计,明确功能和接口小点4: 定期进行设计评审和修改,确保设计的合理性小点5: 关注系统的性能和安全性,在设计中考虑这些方面的问题3. 编码规范小点1: 遵循编码规范,包括命名规则、注释规范等小点2: 使用合适的编码工具,提高编码效率和质量小点3: 保持代码的清晰和简洁,避免冗余和重复代码小点4: 注重代码的可测试性和可维护性小点5: 进行适当的代码审查和测试,及时修复bug4. 测试规范小点1: 制定测试计划和测试用例,覆盖各个功能和场景小点2: 进行单元测试、集成测试和系统测试等多层次的测试小点3: 使用自动化测试工具,提高测试效率和一致性小点4: 关注测试结果和覆盖率,及时修复测试中发现的问题小点5: 进行性能和安全测试,确保系统的质量和稳定性5. 文档编写规范小点1: 编写清晰、准确的技术文档,包括需求文档、设计文档等小点2: 使用合适的文档模板和工具,提高文档的可读性和一致性小点3: 注重文档的结构和组织,便于他人理解和使用小点4: 更新文档时要及时通知相关人员,并确保版本控制的一致性小点5: 进行文档评审和修改,提升文档质量和可用性总结:软件工程规范是确保软件开发过程中质量和效率的重要保障措施。
本文总结了需求分析、设计、编码、测试和文档编写等方面的规范要点,通过遵循这些规范可以提高软件的质量、可维护性和可扩展性,从而满足客户的需求。
软件开发规范:编码规范C#编码规范目标:1. 安全:代码完成所需的功能之余,不要产生负作用,即要稳定可靠。
2. 易读: 类、实例、成员变量、成员函数的命名一目了然3. 美观: 尽量统一项目组内人员的编程风格。
第一部分:命名1. 命名原则1) 所有的函数(变量/类/文件名)应该代表其实际的作用,应该使用有意义的单词或多个词组合,但不要使用人名、项目组名。
2) 所有的函数(变量/类名)一律使用英文。
3) 使用多个单词时不需要使用连线(如下划线), 但对于全部大写的宏需要使用连线。
4) 多个词组合较长时, 可以使用单词的缩写。
5) 不得使用非常相近的名字类表示几个不同含义的函数(变量/类)。
6) 命名时请考虑名字的唯一性和含义的准确性。
7) 使用项目组专用词汇来表达特定的含义(概念), 不得把专用词汇挪作他用。
2. 变量的命名原则: 使用匈牙利命名法命名变量1) 变量名一般由“类型修饰+代表变量含意的英文单词或单词缩写”等部分组成。
类型修饰(小写字母):n: int,l: LONG/long, s: short,u: UINT,f: floatb: bool,by: BYTE,ch: char, sz: char[],str: string2) 针对异常捕获过程中的 Exception 变量命名,在没有冲突的情况下,统一命名为e;如果有冲突的情况下,可以重复 e,比如:ee。
3. 函数的命名1) 使用动宾词组表达函数实际所作的事。
2) 同名的函数(重载函数)在功能上应该完全相同, 在参数上的差别也应一目了然。
3) 不得出现名字非常相近但功能不同的函数. 如 CreatePage1(), CreatePage2()等。
4. 类命名1) 名字应该能够标识事物的特性。
2) 名字尽量不使用缩写,除非它是众所周知的。
3) 名字可以有两个或三个单词组成,但通常不应多于三个。
4) 在名字中,所有单词第一个字母大写,缩写都要大写。
软件开发技术标准规范在软件开发领域,技术标准规范是非常重要的,它可以有效地规范开发流程,提高软件质量,降低开发成本,保证软件的可维护性和可扩展性。
本文将从软件开发的整个流程出发,对软件开发技术标准规范进行详细的介绍和分析。
首先,软件开发的技术标准规范需要包括需求分析、设计、编码、测试、部署和维护等方面。
在需求分析阶段,要求开发人员充分了解用户需求,进行详细的需求调研和分析,确保需求的准确性和完整性。
在设计阶段,需要遵循统一的设计规范,包括软件架构设计、模块设计、界面设计等,确保设计的合理性和可扩展性。
在编码阶段,需要遵循编码规范,包括命名规范、注释规范、代码风格规范等,确保编码的规范性和可读性。
在测试阶段,需要遵循统一的测试规范,包括单元测试、集成测试、系统测试等,确保测试的全面性和有效性。
在部署和维护阶段,需要遵循统一的部署和维护规范,包括部署流程、维护策略、版本管理等,确保软件的稳定性和可维护性。
其次,软件开发的技术标准规范需要注重规范的执行和监督。
在软件开发的整个流程中,需要建立专门的质量管理团队,负责执行和监督技术标准规范的执行情况。
质量管理团队需要定期对各个阶段的规范执行情况进行检查和评估,及时发现和解决规范执行中的问题和不足,确保规范的有效执行。
最后,软件开发的技术标准规范需要不断的完善和优化。
随着软件开发技术的不断发展和变化,技术标准规范也需要不断地进行更新和完善。
因此,需要建立健全的规范更新机制,及时对技术标准规范进行修订和更新,确保规范的时效性和有效性。
综上所述,软件开发的技术标准规范对于提高软件质量、降低开发成本、保证软件的可维护性和可扩展性具有非常重要的意义。
只有严格遵循和执行技术标准规范,才能保证软件开发的顺利进行和软件质量的可靠性。
希望本文的介绍和分析能够对软件开发人员有所帮助,引导大家更加重视和规范软件开发的技术标准规范,提高软件开发的质量和效率。
质量管理体系过程文件软件设计编码过程文件版本信息:目录1.目的 (3)2.围 (3)3.术语 (3)4.角色与职责 (3)5.入口准则 (3)6.输入 (3)7.流程图 (3)8.主要活动 (4)8.1.设计原则 (4)8.2.设计方法.................................................................................... 错误!未定义书签。
8.3.多方案选择 (4)8.4.概要设计.................................................................................... 错误!未定义书签。
8.4.1.概要设计............................................................................ 错误!未定义书签。
8.4.2.概要设计评审.................................................................... 错误!未定义书签。
8.5.详细设计.................................................................................... 错误!未定义书签。
8.5.1.详细设计 (5)8.5.2.详细设计评审 (6)8.6.编码............................................................................................ 错误!未定义书签。
8.7.单元测试 (7)8.8.代码走查 (7)8.9.制作用户文档............................................................................ 错误!未定义书签。
8.10.变更............................................................................................ 错误!未定义书签。
9.输出 (8)10.出口准则 (8)11.引用文档 (8)1.目的设计编码的目的在于设计和实现关于需求的解决方案。
保证《需求规格说明书》中的各项要求在设计时都能够得到满足;对项目的编码实现进行质量控制,保证编码实现活动按计划顺利完成并与设计相一致。
2.围适用于公司的各类软件项目的系统设计编码过程。
3.术语无4.角色与职责5.入口准则●《需求规格说明书》已通过评审。
6.输入●《需求规格说明书》7.流程图图1: 系统设计编码过程8.主要活动系统设计编码过程包括系统设计、系统实现。
系统设计是指设计软件系统的体系结构、数据库、模块等,在需求和代码之间建立桥梁,一般分概要设计和详细设计两个阶段;系统实现是指开发人员按照系统设计去编码开发,并进行单元测试、代码走查;在设计编码过程中同时进行用户文档的编制。
8.1.概要设计概要设计是分析各种设计方案和定义软件体系结构的过程。
设计人员在充分了解需求的基础上,依据《需求规格说明书》选用适当的设计方法,分析与设计软件的结构、模块功能。
通过系统分解,确定子系统的功能和子系统之间的关系,以及模块的功能和模块之间的关系,编写《概要设计说明书》。
《概要设计说明书》必须经过技术评审。
8.1.1.解决方案选择系统设计时可能会涉及到多种解决方案的选择,如:●系统实现路线;●采用的工具和技术;●产品架构;●设计模式;●模块的制作、购买或重用等。
当出现多种候选方案,难以通过简单的方法判断出方案的优劣时,应按照《S_DAR00_决策分析和决定过程》进行决策。
8.1.2.概要设计概要设计是建立整个软件的体系结构,包括子系统、模块以及相关层次的说明、每一模块的接口定义等。
概要设计的主要步骤有:⏹选择设计方法;⏹识别解决方案的主要组件:根据解决方案的技术架构和分析方法(面向对象、面向结构),相应确定解决方案的组件模块;⏹对候选技术和工具、组件进行评估,确定是进行开发、购买还是复用已有技术(工具或者组件)。
评估开发、购买或复用方案时需要考虑的事项包括:业务方面:可行性、产品成本、经验、投资回报、成熟度及其他因素;企业体系结构方面:解决方案必须与当前状态和远景状态计划的约束相适应。
包括与企业现有系统的集成等;技术方面:安全、组件模块交互标准、数据访问、数据存储、系统服务、开发工具、操作系统等。
⏹识别解决方案主要组件的重要属性和关键关系:在前一任务的基础上,对解决方案主要组件的重要属性和关键关系进行识别;⏹进行数据库设计,建立数据库的逻辑模型和物理模型;⏹进行用户界面设计,确定整个系统的界面框架以及界面风格;⏹形成《概要设计说明书》。
8.1.3.概要设计评审概要设计的结果应进行技术评审。
技术评审由设计人员提出,由项目经理组织召开。
技术评审会议应邀请需求分析师、公司的技术专家、开发人员、测试人员等参加。
关于技术评审会议的要求详见《评审过程》。
8.2.详细设计详细设计可以和概要设计并行进行,但应考虑并行设计不会因概要设计而导致较大的详细设计返工。
8.2.1.详细设计详细设计是从开发需求的角度描述解决方案的组件、服务和技术的过程。
详细设计定义了解决方案的各个组成部分,以及这些组成部分的开发方法和交互方式。
详细设计的步骤包括:⏹选择用于开发解决方案的技术并完善设计模型:在概要设计的基础上,选择开发解决方案采用的技术,并且完善对应的设计模型。
⏹确定分发和打包策略:分发和打包策略决定了最终各模块功能服务在解决方案体系结构中的位置以及模块功能服务在哪个组件的基本原理。
设计时需要在理解客户业务环境、业务架构现状和发展趋势的基础上,考虑设计的可伸缩性、性能、可管理性、重用性。
此外,高聚性、低耦合性是优秀组件模块设计的特征之一,需要作为设计参考。
⏹将组件和服务打包:根据解决方案的基础架构,将各功能组件模块分布到基础架构的各个部分。
⏹将组件分发到网络拓扑中:将应用程序模块与网络、物理服务器拓扑联系起来构成部署模型。
⏹确定编程模型:编程模型是一组特定的准则,提供了一致性的组件实现。
编程模型包含了:实现技术、状态对象和无状态对象、进程函数调用和进程外函数调用、聚性和耦合性、连接模型和非连接模型、同步编程模型和异步编程模型、线程模型、错误处理、安全性和分发等方面的准则。
⏹指定详细的组件接口、属性和服务:包括了组件接口设计、用户详细界面设计。
⏹详细设计输出《详细设计说明书》。
8.2.2.详细设计评审详细设计根据设计需要确定是否进行评审。
一般,以下情况应进行详细设计评审:●新业务的设计;●涉及3个及以上业务流程的设计;●复杂算法和数据结构的设计;●新设计人员设计的结果。
技术评审由详细设计人员提出和组织召开。
技术评审会议应邀请概要设计人员、开发人员等参加。
关于技术评审会议的要求详见《评审过程》。
8.3.编码实现8.3.1.开发环境准备代码开发前应对开发环境进行规并搭建开发环境。
开发环境搭建应考虑的容有:●开发服务器环境(开发数据库、源代码管理、网络、项目组门户等);●开发工具及版本;●编码涉及的复用组件及版本;●代码目录结构;●编码规等。
开发环境应由开发负责人配置好后,对开发人员进行培训。
8.3.2.代码编写开发人员根据《详细设计说明书》进行编码实现。
代码编写应考虑以下两个方面:●编程方法:为提高代码的质量,可使用一些有效的编程方法来编制软件。
常见的编程方法有:结构化编程、面向对象编程、重用已有代码或者组件等。
此外代码编写根据所使用的开发语言不同,应该遵循相应的编码规。
●编程实现顺序:根据《项目进度计划》确定各功能单元的编程顺序,在编程过程中要严格按顺序来进行编码。
8.3.3.单元测试单元测试的目的是为保证编写的每个代码单元片段功能实现满足设计要求,提高提交的代码质量而由开发人员进行的测试工作。
单元测试指通过设计测试用例,执行待测程序来跟踪比较实际结果与预期结果来发现错误。
单元测试由模块开发人员进行,有条件的可以由其它开发人员进行互换测试。
单元测试需要关注以下几个方面:➢源代码编译-----测试代码是否通过编译。
➢SQL脚本-----测试数据库脚本、存储过程运行是否正常。
➢模块接口-----对被测模块,信息是否能正确地流入和流出。
➢局部数据结构-----在模块的工作过程中,其部的数据能否保持其完整性。
➢出错处理-----检查模块的错误处理是否有效。
可关注以下几个方面:➢边界条件-----在边界上模块是否能正常工作。
➢覆盖条件------模块的运行是是否满足设计的逻辑要求。
建议引用测试工具自动执行单元测试。
测试结果形成《单元测试报告》,纳入配置管理。
➢利用工具自动执行单元测试的,可由工具直接导出《单元测试报告》;完成各模块的单元测试后,开发人员填写《需求跟踪矩阵》的相关编码模块。
8.3.4.代码走查软件模块经过单元测试,由开发经理在进度计划中策划并安排开发人员进行程序代码走查。
代码走查策划的原则可以从以下几个方面关注:◆新员工编写的代码◆关键业务或系统核心代码◆问题较多的代码◆新增模块的代码等◆让步发布或发到用户现场测试的代码开发经理可以在项目的PDP说明中策划确认代码走查策划的原则,并在进度计划中安排代码走查的任务。
代码走查由开发经理确定是个人走查或是团队走查。
8.4.用户文档编写作为最终产品的一部分,项目还应编写《用户使用手册》、用户培训教材等用户文档。
由测试人员在验收测试完成前完成用户文档的编写。
用户文档经过项目经理验证后纳入配置库中进行管理。
9.输出●《概要设计说明书》●《详细设计说明书》●源代码●《单元测试报告》●《用户操作手册》●《用户安装手册》10.出口准则●设计文档评审通过●代码通过单元测试和代码走查●完成用户文档11.引用文档●决策分析和决定过程●评审过程●变更管理过程。