开发文档规范检查

开发文档规范检查
开发文档规范检查

采用以下检查表检查软件需求规格文档中需求的清晰性。(另外整理成分支文档)

采用以下检查表检查软件需求规格文档中需求的完备性。

采用以下检查表检查软件需求规格文档中需求的兼容性。

采用以下检查表检查软件需求规格文档中需求的一致性。

采用以下检查表检查软件需求规格文档中需求的正确性。

采用以下检查表检查软件需求规格文档中需求的可行性。

采用以下检查表检查软件需求规格文档中需求的易修改性。

采用以下检查表检查软件需求规格文档中需求的健壮性。

采用以下检查表检查软件需求规格文档中需求的易追溯性。

采用以下检查表检查软件需求规格文档中需求的易理解性。

采用以下检查表检查软件需求规格文档中需求的易测试性和可验证性。

采用以下检查表检查软件需求规格文档中的性能需求描述。

采用以下检查表检查软件需求规格文档中功能需求描述。

采用以下检查表检查软件需求规格文档中的接口需求描述。

采用以下检查表检查软件需求规格文档中的数据需求描述。

采用以下检查表检查软件需求规格文档中的可维护性需求描述。

1.1.项目计划文档规范

项目计划以软件的需求规格为基础。当发生需求更改时,修订开发计划。

说明:项目计划必须依据需求规格进行制定。项目计划中的工作产品

和工作任务应保证能完全实现需求规格的定义。当需求更改时,必须

考虑需求更改的相关性,修订相应开发计划。

在开发活动中,按照“项目计划”,跟踪项目开发的实际结果和性能

当实际结果和“项目计划”发生偏离时,进行分析,根据分析结果标明纠正措施。必要的情况下,及时修订“项目计划”。

在项目跟踪监控活动中,定期进行总结和确认,撰写开发状态报告。

每周五提交周报,并确认本周工作内容是否与需求规格说明书一致,是否存在偏差。

在开发各里程碑阶段结束前,进行阶段确认,必要的情况下修订“项目计划”

1.2.概要设计

概要设计要以需求规格为基础,保证需要实现的需求规格已经被设计。

当需求规格发生变更时,修订相关概要设计文档。

在概要设计文档或需求管理文档中,记录、验证需求和概要设计的跟踪关系。

保证概要设计文档和代码的一致性。当发生设计更改时,修订相应设计文档。

概要设计过程结束前,必须通过签字确认,并保存记录。

设计更改必须经过相关签字确认,并保存记录。

对概要设计文档的正规检视或评审,必须检查概要设计文档的清晰性、完备性、规范性、一致性、正确性、数据、功能性、接口、详细程度、可维护性、性能、可靠性、可测试性、可追溯性。

采用以下检查表检查概要设计文档的清晰性。

采用以下检查表检查概要设计文档的完备性。

采用以下检查表检查概要设计文档的规范性。

采用以下检查表检查概要设计文档的一致性。

采用以下检查表检查概要设计文档的正确性。

采用以下检查表检查概要设计文档的数据描述。

采用以下检查表检查概要设计文档的功能性要求。

采用以下检查表检查设计的接口描述。

采用以下检查表检查设计的详细程度。

采用以下检查表检查设计的可维护性。

采用以下检查表检查设计的性能。

采用以下检查表检查设计的可靠性。

采用以下检查表检查设计的可测试性。

采用以下检查表检查设计的可追溯性。

1.3.详细设计

详细设计要以软件需求规格和概要设计为基础,必须保证需要实现的需求规格已经被设计,必须保证概要设计定义的所有模块已经被详细设计。

当需求规格或概要设计发生变更时,修订相关详细设计文档。

在详细设计文档或需求管理文档中,记录、验证需求、概要设计、详细设计的跟踪关系。

必须保证详细设计文档和代码的一致性。当发生设计更改时,修订相应设计文档。

详细设计过程结束前,必须通过确认签字,并保存记录。

设计更改必须经过确认签字,并保存记录。

对详细设计文档的正规检视或评审,必须检查详细设计文档的清晰性、完备性、规范性、一致性、正确性、数据、功能性、接口、详细程度、可维护性、性能、可靠性、可测试性、可追溯性。

采用以下检查表检查详细设计文档的清晰性。

采用以下检查表检查详细设计文档的完备性。

采用以下检查表检查详细设计的一致性。

采用以下检查表检查详细设计的正确性。

采用以下检查表检查详细设计的数据描述。

采用以下检查表检查详细设计的功能性要求。

采用以下检查表检查详细设计的接口描述。

采用以下检查表检查详细设计的详细程度。

采用以下检查表检查详细设计的可维护性。

采用以下检查表检查详细设计的可靠性。

采用以下检查表检查详细设计的可测试性。

采用以下检查表检查详细设计的可追溯性。

(国内标准)GB-软件开发主要文档编写规范

231 GB 8567-88软件开发主要文档编写规范 本附录中列出了《计算机软件产品开发文件编制指南》GB 8567-88中主要软件文档的编写说明,供编写时参考。这些文档主要是:可行性研究报告、项目开发计划、软件需求说明书、概要设计说明书、详细设计说明书、模块开发卷宗、测试计划、测试分析报告、项目开发总结报告。 一、可行性研究报告 l 引言 1.1 编写目的 说明:说明本可行性研究报告的编写目的,指出预期的读者。 1.2 背景 说明: a .所建议开发的软件系统的名称。 b .本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络。 c .该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3 定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1.4 参考资料 列出用得着的参考资料,如: a .本项目的经核准的计划任务书或合同、上级机关的批文。 b .属干本项目的其他已发表的文件。 c. 本文件中各处引用的文件、资料,包括所需用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。 2 可行性研究的前提 说明对建议开发项目进行可行性研究的前提,如要求、目标、条件、假定和限制等。 2.1 要求 说明对所建议开发软件的基本要求,如: a .功能。 b .性能。 c .输出如报告、文件或数据,对每项输出要说明其特征,如用途、产生频度、接口以及分发对象。 d. 输入说明。系统的输入包括数据的来源、类型、数量、数据的组织以及提供的频度。 e .处理流程和数据流程。用图表的方式表示出最基本的数据流程和处理流程,并输之以叙述。 f. 在安全与保密方面的要求。 g. 同本系统相连接的其他系统。 h. 完成期限。 2.2 目标 说明所建议系统的主要开发目标,如: a. 人力与设备费用的减少。 b. 处理速度的提高。 c. 控制精度或生产能力的提高。

软件开发文档规范

附2: 软件文档编写向导 文档分类 项目包括如下几类文档: 项目管理文档。包括:《软件项目计划》、《项目进度报告》、《项目开发总结报告》 软件开发文档。包括:《需求规格说明》、《概要设计说明》、《详细设计说明》、《测试计划》、《软件测试分析报告》。 产品文档。包括:《用户操作手册》《演示文件》。 软件项目计划 (Software Project Plan) 一?引言 1?编写目的(阐明编写软件计划的目的,指出读者对象。) 2?项目背景(可包括:(1 )项目委托单位、开发单位和主管部门;(2)该软件系统与 其他系统的关系。) 3?定义(列出本文档中用到的专门术语的定义和缩略词的原文。) 4?参考资料(可包括:文档所引用的资料、规范等;列出资料的作者、标题、编号、发 表日期、出版单位或资料来源。) 二?项目概述 1.工作内容(简要说明项目的各项主要工作,介绍所开发软件的功能性能等?若不编写可行性研究报告,则应在本节给出较详细的介绍。) 2.条件与限制(阐明为完成项目应具备的条件开发单位已具备的条件以及尚需创造的 条件?必要时还应说明用户及分合同承包者承担的工作完成期限及其它条件与限制。) 3.产品 (1)程序(列出应交付的程序名称使用的语言及存储形式。) (2)文档(列出应交付的文档。) (3 )运行环境(应包括硬件环境软件环境。) 4?服务(阐明开发单位可向用户提供的服务?如人员培训安装保修维护和其他运行支持。 5.验收标准

三.实施计划 1.任务分解(任务的划分及各项任务的负责人。) 2?进度(按阶段完成的项目,用图表说明开始时间完成时间。) 3?预算 4?关键问题(说明可能影响项目的关键问题,如设备条件技术难点或其他风险因素,并说明对策。) 四.人员组织及分工 五.交付期限 六.专题计划要点(如测试计划等。) 项目开发进度报告 一.报告时间及所处的开发阶段 二.给出进度 1.本周的主要活动 2.实际进展与计划比较 三.所用工时(按不同层次人员分别计时。) 四.所有机时 五.工作遇到的问题及采取的对策 六.本周完成的成果 七.下周的工作计划 八.特殊问题 项目开发总结报告 一.引言 1.编写目的(阐明编写总结报告的目的,指明读者对象。) 2.项目背景(说明项目的来源、委托单位、开发单位及主管部门。) 3.定义(列出报告中用到的专门术语定义和缩写词的原意。) 4.参考资料(列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源,可包括: (1 )项目开发计划;(2 )需求规格说明书;(3 )概要设计说明书;(4 )详细设计说明

软件开发过程管理规范

软件开发过程管理规范文件管理序列号:[K8UY-K9IO69-O6M243-OL889-F88688]

0 引言 如果要提高软件开发人员的开发质量,必须有相应的考核制度,有了制度后才能推动开发人员想方设法改善自已的开发质量。目前研发对软件开发的过程缺乏细粒度的度量,所以不能依据有效的度量数据来考核开发人员的工作绩效,大部份只是凭考核人主观意志来考核,不能形成对被考核人有效的说服力。此绩效考核办法旨在结合实际情况合理客观地评价开发效率和质量。 1 目的 对软件开发的过程所产生的软件项的质量和过程进行定量的评价,用评价的结果指导软件的开发过程,不断地提高软件开发质量水平,并依据度量记录来考核软件开发人员的工作绩效。 2 软件项包括 1)技术文档:主要包括:可行性分析报告、需求分析报告、软件功能规格说明、开发计划、系统设计报告、测试文档、用户手册、总结报告等; 2)计算机程序。 3 度量数据的来源 1)项目计划; 2)评审报告; 3)测试报告; 4)问题报告; 5)软件维护记录; 4 质量度量

4.1 度量指标 主要根据各类软件项检查表的检查指标来确定,例如,软件需求规格说明书检查表(见附录1),有10个检查指标,则根据具体项目检查侧重点不同,可从中选择相应的检查指标作为度量指标。 4.2 质量等级 1)软件项的质量等级的确定根据度量综合指标进行。 2)度量综合指标计算公式为:Total = ∑QiMi。 3)其中i=1,2,...n代表指标数量; 4)Q代表度量的指标; 5)M代表度量的指标Q在整个指标体系中所占的权重系数,对不同的开发项目可能不同,此系数根据开发的不同着重点给出。 度量指标权重系数表: 序号指标权重 1 指标1 权数1 2 指标2 权数2 3 指标3 权数3 4 指标4 权数4 5 指标5 权数5 加权平均分 1.0 6)质量评价:一般地,根据度量综合指标值,有以下评分标准。 质量评价计分标准表 序号得分质量评价

软硬件开发流程及要求规范

0目录 0目录 (2) 1概述 (4) 1.1硬件开发过程简介 (4) 1.1.1硬件开发的基本过程 (4) 1.1.2硬件开发的规化 (4) 1.2硬件工程师职责与基本技能 (5) 1.2.1硬件工程师职责 (5) 1.2.2硬件工程师基本素质与技术 (5) 2软硬件开发规化管理 (6) 2.1硬件开发流程 (6) 2.1.1硬件开发流程文件介绍 (6) 2.1.2硬件开发流程详解 (6) 2.2硬件开发文档规 (10) 2.2.1硬件开发文档规文件介绍 (10) 2.2.2硬件开发文档编制规详解 (11) 2.3与硬件开发相关的流程文件介绍 (13) 2.3.1项目立项流程: (13) 2.3.2项目实施管理流程: (14) 2.3.3软件开发流程: (14) 2.3.4系统测试工作流程: (14) 2.3.5部验收流程 (14) 3附录一. 硬件设计流程图: (16)

4附录二. 软件设计流程图: (17) 5附录三. 编程规 (18)

1概述 1.1 硬件开发过程简介 1.1.1硬件开发的基本过程 硬件开发的基本过程: 1.明确硬件总体需求情况,如CPU 处理能力、存储容量及速度,I/O 端口的分配、接口要求、电平要求、特殊电路(厚膜等)要求等等。 2.根据需求分析制定硬件总体方案,寻求关键器件及电路的技术资料、技术途径、技术支持,要比较充分地考虑技术可能性、可靠性以及成本控制,并对开发调试工具提出明确的要求。关键器件索取样品。 3.总体方案确定后,作硬件和单板软件的详细设计,包括绘制硬件原理图、单板软件功能框图及编码、PCB 布线,同时完成发物料清单。 4.领回PCB 板及物料后由焊工焊好1~2 块单板,作单板调试,对原理设计中的各功能进行调测,必要时修改原理图并作记录。 5.软硬件系统联调,一般的单板需硬件人员、单板软件人员的配合,特殊的单板(如主机板)需比较大型软件的开发,参与联调的软件人员更多。一般地,经过单板调试后在原理及PCB布线方面有些调整,需第二次投板。 6.部验收及转中试,硬件项目完成开发过程。 1.1.2硬件开发的规化 硬件开发的基本过程应遵循硬件开发流程规文件执行,不仅如此,硬件开发涉及到技术的应用、器件的选择等,必须遵照相应的规化措施才能达到质量保障的要求。这主要表现在,技术的采用要经过总体组的评审,器件和厂家的选择要参照物料认证部的相关文件,开发过程完成相应的规定文档,另外,常用的硬件电路(如ID.WDT)要采用通用的标准设计。

软件开发文档说明书(完整流程)

. 在软件行业有一句话:一个软件能否顺利的完成并且功能是否完善,重要是看这个软件有多少文档,软件开发文档是一个软件的支柱,如果你的开发文档漏洞百出,那么你所开发出来的软件也不可能会好;开发文档的好坏可以直接影响到所开发出来软件的成功与否。 一、软件开发设计文档:软件开发文档包括软件需求说明书、数据要求说有书、概要设计说明书、详细设计说明书。 1、软件需求说明书:也称为软件规格说明。该说明书对所开发软件的功能、性能、用户界面及运行环境等做出详细的说明。它是用户与开发人员双方对软件需求取得共同理解基础上达成的协议,也是实施开发工作的基础。软件需求说明书的编制目的的就是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解、并使之面成为整个开发工作的基础。 其格式要求如下: 1 引言 1.1 编写目的。 1.2 背景 1.3 定义 2 任务概述 2.1 目标 2.2 用户的特点

. 2.3 假定和约束 3 需求规定 3.1 对功能的规定 3.2 对性能的规定 3.2.1 精度 3.2.2 时间特性的需求 3.2.3 灵活性 3.3 输入输出要求 3.4 数据管理能力要求 3.5 故障处理要求 3.6 其他专门要求 4 运行环境规定 4.1 设备 4.2 支持软件 4.3 接口 4.4 控制

. 2、概要设计说明书:又称系统设计说明书,这里所说的系统是指程序系统。编制的目的是说明对程序系统的设计考虑,包括程序系统的基本处理。流程、程序系统的组织结构、模块划分、功能分配、接口设计。运河行设计、数据结构设计和出错处理设计等,为程序的详细设计提供基础。 其格式要求如下: 1 引言 1.1 编写目的 1.2 背景 1.3 定义 1.4 参考资料 2 总体设计 2.1 需求规定 2.2 运行环境 2.3 基本设计概念和处理流程 2.4 结构 2.5 功能需求与程序的关系

软硬件开发流程及规范定稿版

软硬件开发流程及规范精编W O R D版 IBM system office room 【A0816H-A0912AAAHH-GX8Q8-GNTHHJ8】

0目录 0目录 (2) 1概述 (4) 1.1 硬件开发过程简介 (4) 1.1.1 硬件开发的基本过程 (4) 1.1.2 硬件开发的规范化 (4)

1.2 硬件工程师职责与基本技能 (5) 1.2.1 硬件工程师职责 (5) 1.2.2 硬件工程师基本素质与技术 (5) 2软硬件开发规范化管理 (6) 2.1 硬件开发流程 (6) 2.1.1 硬件开发流程文件介绍 (6) 2.1.2 硬件开发流程详解 (6) 2.2 硬件开发文档规范 (10) 2.2.1 硬件开发文档规范文件介绍 (10) 2.2.2 硬件开发文档编制规范详解 (11) 2.3 与硬件开发相关的流程文件介绍 (13) 2.3.1 项目立项流程: (13) 2.3.2 项目实施管理流程: (14) 2.3.3 软件开发流程: (14) 2.3.4 系统测试工作流程: (14) 2.3.5 内部验收流程 (14)

3附录一. 硬件设计流程图: (16) 4附录二. 软件设计流程图: (17) 5附录三. 编程规范 (18) 1概述 1.1硬件开发过程简介 1.1.1硬件开发的基本过程 硬件开发的基本过程: 1.明确硬件总体需求情况,如CPU 处理能力、存储容量及速度,I/O 端口的分配、接口要求、电平要求、特殊电路(厚膜等)要求等等。 2.根据需求分析制定硬件总体方案,寻求关键器件及电路的技术资料、技术途径、技术支持,要比较充分地考虑技术可能性、可靠性以及成本控制,并对开发调试工具提出明确的要求。关键器件索取样品。 3.总体方案确定后,作硬件和单板软件的详细设计,包括绘制硬件原理图、单板软件功能框图及编码、PCB 布线,同时完成发物料清单。 4.领回PCB 板及物料后由焊工焊好1~2 块单板,作单板调试,对原理设计中的各功能进行调测,必要时修改原理图并作记录。

软件开发文档标准

可行性研究报告 来源:国家计算机标准和文件模板作者: 可行性研究报告的编写目的是:说明该软件开发项目的实现在技术、经济和社会条件方面的可行性;评述为了合理地达到开发目标而可能选择的各种方案;说明并论证所选定的方案。 可行性研究报告的编写内容要求如下: 1 引言 1.1编写目的 说明编写本可行性研究报告的目的,指出预期的读者。 1.2背景 说明: a.所建议开发的软件系统的名称; b.本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络; C.该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1.4参考资料 列出用得着的参考资料,如: a.本项目的经核准的计划任务书或合同、上级机关的批文; b.属于本项目的其他已发表的文件; C.本文件中各处引用的文件、资料,包括所需用到的软件开发标准。| 列出这些文件资料的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。 2 可行性研究的前提 说明对所建议的开发项目进行可行性研究的前提,如要求、目标、假定、限制等。 2.1要求 说明对所建议开发的软件的基本要求,如: a.功能; b.性能; C.输出如报告、文件或数据,对每项输出要说明其特征,如用途、产生频度、接口以及分发对象; d.输入说明系统的输入,包括数据的来源、类型、数量、数据的组织以及提供的频度; e.处理流程和数据流程用图表的方式表示出最基本的数据流程和处理流程,并辅之以叙述; f.在安全与保密方面的要求; g.同本系统相连接的其他系统;

h.完成期限。 2.2目标 说明所建议系统的主要开发目标,如: a.人力与设备费用的减少; b.处理速度的提高; C.控制精度或生产能力的提高; d.管理信息服务的改进; e.自动决策系统的改进; f.人员利用率的改进。 2.3条件、假定和限制 说明对这项开发中给出的条件、假定和所受到的限制,如: a.所建议系统的运行寿命的最小值; b.进行系统方案选择比较的时间; c.经费、投资方面的来源和限制; d.法律和政策方面的限制; e.硬件、软件、运行环境和开发环境方面的条件和限制; f.可利用的信息和资源; g.系统投入使用的最晚时间。 2.4进行可行性研究的方法 说明这项可行性研究将是如何进行的,所建议的系统将是如何评价的。摘要说明所使用的基本方法和策略,如调查、加权、确定模型、建立基准点或仿真等。 2.5评价尺度 说明对系统进行评价时所使用的主要尺度,如费用的多少、各项功能的优先次序、开发时间的长短及使用中的难易程度。 3 对现有系统的分析 这里的现有系统是指当前实际使用的系统,这个系统可能是计算机系统,也可能是一个机械系统甚至是一个人工系统。 分析现有系统的目的是为了进一步阐明建议中的开发新系统或修改现有系统的必要性。 3.1处理流程和数据流程 说明现有系统的基本的处理流程和数据流程。此流程可用图表即流程图的形式表示,并加以叙述。 3.2工作负荷 列出现有系统所承担的工作及工作量。 3.3费用开支 列出由于运行现有系统所引起的费用开支,如人力、设备、空间、支持性服务、材料等项开

软件开发过程规范

【最新资料,Word版,可自由编辑!】

目录 1.前言 (3) 1.1 目的 (3) 1.2 对象 (3) 1.3 要求 (3) 1.4 适用范围 (3) 1.5 软件开发过程模型 (3) 1.6 开发过程划分 (4) 2.技术过程规范部分 (4) 2.1 概述 (4) 2.2 业务建模阶段 (4) 2.3 需求阶段 (6) 2.4 分析设计阶段 (8) 2.5 实现阶段 (10) 3.管理过程规范部分 (11) 3.1 概述 (11) 3.2 接受项目 (12) 3.3 重新评估项目范围和风险(对于较大项目) (12) 3.4 制定开发计划 (13) 3.5 迭代开发管理 (13) 3.6 监控项目的实施 (14) 3.7 结束项目 (15)

软件开发过程规范 前言 目的 本规范的目的是使整个软件产品开发及项目工程阶段清晰,要求明确,任务具体,便于规范化、系统化及工程化。有利于提高软件生命周期的控制及管理,提高所开发软件的质量,缩短开发时间,减少开发和维护费用,使软件开发活动更科学、更有成效。 对象 本规范面向产品生命周期的所有相关人员,包括管理人员、开发人员、质管人员。 要求 具有软件开发管理职能的人员要求熟知项目开发的各阶段过程和各阶段过程相应的规范。 适用范围 适用于产品开发生命周期中的除产品提交外的其他全部过程;规范分为两部分:技术过程规范和管理过程规范,分别适用于软件开发过程中的技术性活动和管理性活动。 软件开发过程模型 本规范所采用的软件开发过程模型为简化的RUP开发过程模型;软件开发过程是体系结构为中心,用例驱动和风险驱动相结合的过程迭代。

硬件开发管理办法及流程图

硬件开发管理流程 1目的 1.1使开发人员的开发工作能够按照一定的程序进行,保证开发工作的顺 利进行。 1.2使开发工作的管理流程化,保证开发产品的品质。 1.3确保有较高的开发与管理效率。 2范围 2.1本流程适用于硬件部产品硬件开发过程。 3职责 3.1由硬件部负责产品的硬件开发,修正及发行相关文件。 3.2由品管部负责产品开发过程的审核、监督与产品质量的控制、评定。4定义 4.1PCB:Printed Circuit Board印刷电路板 4.2BOM:Bill Of Material 材料表 5程序 5.1新产品硬件开发程序 5.1.1接收新需求 5.1.1.1由市场部提交已通过可行性分析的《客户需求明细》。 5.1.2硬件部针对客户产品需求进行详细硬件参数分析,制定设计方案 与规划,并填写《硬件开发设计规划》 5.1.3原理图设计 5.1.3.1硬件部完成产品原理图设计。 5.1.3.2同部门相关人员负责原理图设计的检查与审核,如不通过 则进行修改,并填写《硬件设计记录表》。 5.1.4PCB设计 5.1.4.1硬件部依据本公司PCB设计规范完成PCB图设计。 5.1.4.2同部门相关人员负责PCB设计的检查与审核,如不通过则 进行修改,并填写《硬件设计记录表》。 5.1.5PCB光绘文件设计 5.1.5.1PCB设计完成并通过审核后,出相应光绘文件。 5.1.5.2同部门相关人员负责光绘文件的检查与审核,如不通过则 进行修改,并填写《硬件设计记录表》。 5.1.6BOM表设计 5.1. 6.1根据原理图出相应产品BOM表。 5.1. 6.2同部门相关人员负责BOM表的检查与审核,如不通过则进 行修改,并填写《硬件设计记录表》。 5.1.7PCB打样,申请器件样片 5.1.7.1硬件部将PCB光绘文件及《PCB制作申请表》交至采购部 门联系安排PCB板打样。 5.1.7.2硬件部到材料库领用配套调试所需的器件,如材料库没有 的,硬件部将欠缺的器件清单交至采购部进行采购。 5.1.8焊接与装配样板 5.1.8.1PCB打样完成后,硬件部负责完成样板的器件焊接与装配。

JAVA开发规范文档

Java 开发规范文档 一:目的 使本组织能以标准的,规范的方式设计和编码。通过建立编码规范,以使每个开发人员养成良好的编码风格和习惯;并以此形成开发小组编码约定,提高程序的可靠性,可读性,可修改性,可维护性和一致性等,增进团队间的交流,并保证软件产品的质量。 二:代码组织与风格 1:长度:为便于阅读和理解,单个函数的有效代码长度当尽量在100行以内(不包括注释行),当功能模块过大时往往采用使用子函数将相应的功能抽取出来,这也有利于提高代码的重用度。 2:单个类不宜过大,当出现此类过大时当将相应功能的代码重构到其他类中,通过组合等方式来调用,建议单个类的长度包括注释行不超过1500行。尽量避免使用大类和长方法。3:间隔:类,方法及功能块间等应以空行相隔,以增加可读性,但不得有无规则的大片空行。操作符两端应当各空一个字符以增加可读性。 三:注释 1:注释应该增加代码的清晰度。代码注释的目的时要使代码更易于被其他开发人员等理解。2:保持注释的简洁。 3:注释信息应该包括代码的功能。 4:除变量定义等较短语句的注释使用行尾注释外,其他注释当避免使用行尾注释。 5:JavaDoc规范 对类,方法,变量等注释需要符合javadoc规范,对每个类,方法都应详细说明其功能条件,参数等。类注释中应当包含版本和作者信息。 1)类,接口注释在类,接口定义之前当对其进行注释,包括类,接口的目的,作用,功能,继承于何种父类,实现的接口,实现的算法,使用方法,示例程序等。 2)方法注释以明确该方法功能,作者,各参数含义以及返回值等。

3)其他注释应对重要的变量及不易理解的分支条件表达式加以注释,以说明其含义等。四命名规范 1:对变量,类,接口及包的命名应该使用英文。严禁使用汉语拼音及不相关单词命名。更不可以使用汉字来进行命名。采用大小写混合,提高名字的可读性。一般应该采用小写字母,但时类和接口的名称的首字母,以及任何中间单词的首字母应该大写。包名全部小写。 2:尽量少用缩写,但如果一定要用,当使用公共缩写和习惯缩写等,如implement可缩写为impl,manager可缩写成mgr等。 3:包名一般以项目或模块名命名,少用缩写和长名,一律小写。 包名按照如下规定组成[基本包].[项目名].[模块名].[子模块名].…. 如:org.skyinn.skyhome.dao.hibernate。 不得将类直接定义在基本包下,所有项目中的类,接口等都当定义在各自的项目和模块包中。 4:类,接口所有单词首字母大写,最好能够见名知意。一般采用名词。接口可带I前缀。 或able,dao后缀。 5:字段常量采用完整的英文大写单词,单词之间用下划线连接,如DEFAULT_V ALUE. 6:变量和参数对不易识别出该变量类型的变量应使用类型缩写作其前缀,如字符串使用strXXX,boolean使用isXXX,hasXXX等等。除第一个单词外其余单词的首字母大写。7:集合采用复数名称来表示队列中存放的对象类型,名词采用完整的英文描述。 例如:Vector vProducts= new Vector(); Array aryUsers= new Array(); 8:方法方法的名称应采用完整的英文描述,大小写混合使用:所有中间单词的第一个字母大写。方法名称的第一个单词常常采用一个强烈动作色彩的动词。取值类使用get前缀,设置类使用set前缀。例如getName(),setSarry()。 9:异常类名由表示该异常类型的单词和Exception组成,如ActionException。异常实例一般使用e,ex等。 10:数组的命名 数组应该总是用下面的方式来命名:byte[] buffer; 而不是:byte buffer[]; 五:类与接口 1:基本原则:一个类只做一件事情。另一个原则时根据每个类的职责进行划分,比如用User 来存放用户信息,而用UserDAO来对用户信息进行数据访问操作,用UserServer对用户信息的业务操作等等。多个类中使用相同方法时将其方法提到一个接口中或使用抽象类,尽量提高重用度。不希望被实例化的类的缺省构造方法声明为private。 2:一般而言,接口定义行为,而抽象类定义属性和共有行为,注意2者的取舍,在设计中可由接口定义公用的行为,由一个抽象类来实现其部分或全部方法,以给子类提供统一的行为为定义。 六:方法 一个方法只完成一项功能。方法参数类型和参数返回值尽量接口化,以屏蔽具体的实现细节,提高系统的可扩展性,例如:public void addUser(List userList){} public List listAllUsers(){} 七:Web 命名规范 一:jsp页面命名 对于某个功能块的增删改查页面定义,最好使用

PRD-产品开发项目文档管理系统要求规范

产品开发项目文档管 理规范 文档编号:COSHIP-CMMI-PRD-PDPDM 密级:机密 版本信息:1.8 批准日期: 编辑软件:Microsoft Word 2003 Microsoft Visio 2003 同洲电子股份有限公司版权所有 内部资料注意保密

*变化状态:C――创建,A——增加,M——修改,D——删除

目录 1 概述 (1) 1.1 目的 (1) 1.2 适用范围 (1) 2 产品开发文档体系 (1) 3 文档质量的度量准则 (3) 4 主要角色和职责 (3) 4.1 文档作者 (3) 4.2 项目经理 (4) 4.3 PPQA (4) 4.4 配置管理工程师 (4) 4.5 评审组 (4) 4.6 部门经理 (4) 5 文档审核流程 (5) 5.1 审核流程 (5) 5.2 归档签名 (6) 5.3 纳入基线 (6) 6 文档保密制度 (7) 7 文档编号 (7) 7.1 文档编号规则 (7) 7.2 阶段代号 (8) 8 文档版本 (9)

1概述 1.1目的 规范公司产品开发项目的文档体系,加强文档的标准化管理。 1.2适用范围 公司内所有产品开发项目。 2产品开发文档体系 在产品开发项目开发过程中,各阶段都有相应的文档输出,文档的编写应先于或同步于开发工作。 产品开发项目过程中的文档体系如表1所示。 表1.产品开发项目文档体系

3文档质量的度量准则 评审文档质量的度量准则有以下六条: 完整性:所承担产品开发任务的项目组,需按照公司文档体系的规定编写相应的文档,以保证在项目结束时其文档是齐全的。 正确性:在项目各个阶段所编写的文档的内容,必须真实的反映阶段的工作且与该阶段的需求相一致。文档与所述的对象保持一致,必要时应进行实时的文档版本升级。 可读性:文档应该表达清晰、逻辑条理分明、表现形式通用。 简明性:在项目各个阶段所编写的各种文档的语言表达应该准确简练。 规范性:文档的规范性是指采用当前最新的模板。其完整性及内容的充实程度应不低于模板的要求。 可追溯性:在项目各个阶段所编写的各种文档应该具有良好的可追溯性。由于各开发阶段编制的文档与各阶段完成的工作有着密切的关系,前后阶段生成的文件,随着开发工作的逐步扩展,具有一定的继承关系。在一个项目各开发阶段之间提供的文件必定存在着可追溯的关系。 4主要角色和职责 4.1文档作者 文档作者包括公司内的项目组成员以及外协人员。文档作者在文档方面的主要工作为:1)在项目开发过程的各个阶段中,按照规定及时地完成项目文档的编写工作,文档作者有责任保证文档编写与开发同步。 2)文档作者不仅要审核文档字面上有无错漏,还要审核所陈述的技术内容是否精确,及表达方式上是否清晰易懂。文档作者对文档的正确性、可读性和规范性全面负责。 3)文档作者保证所编写的文档与所描述的对象保持很好的一致性,必要时及时更新文档,便于以后维护工作和后续开发工作的开展。

软件开发过程文档规范

1.1需求规格说明书 需求规格相当于软件开发的图纸,一般说,软件需求规格说明书的格式可以根 据项目的具体情况采用不同的格式,没有统一的标准。下面是一个可以参照的 软件需求规格说明书的模板。 1.导言 1.1目的 [说明编写这份项目需求规格的目的,指出预期的读者] 1.2背景 说明: a)待开发的产品名称; b)本项目的任务提出者、开发者、用户及实现该产品的单位; c)该系统同其他系统的相互来往关系。 1.3缩写说明 [缩写] [缩写说明] 列出本文件中用到的外文首字母组词的原词组。 1.4术语定义 [术语] [术语定义] 列出本文件中用到的专门术语的定义。 1.5参考资料 [编号]《参考资料》[版本号] 列出相关的参考资料。 1.6版本更新信息 具体版本更新记录如表所列。 表版本更新记录 2.任务概述 2.1 系统定义 本节描述内容包括: ●项目来源及背景; ●项目要达到的目标,如市场目标、技术目标等; ●系统整体结构,如系统框架、系统提供的主要功能,涉及的接口等; ●各组成部分结构,如果所定义的产品是一个更大的系统的一个组成部分, 则应说明本产品与该系统中其他各组成部分之间的关系,为此可使用一张 方框图来说明该系统的组成和本产品同其他各部分的联系和接口。 2.2 应用环境 本节应根据用户的要求对系统的运行环境进行定义,描述内容包括: ●设备环境; ●系统运行硬件环境;

●系统运行软件环境; ●系统运行网络环境; ●用户操作模式; ●当前应用环境。 2.3 假定和约束 列出进行本产品开发工作的假定和约束,例如经费限制、开发期限等。列出本产品的最终用户的特点,充分说明操作人员、维护人员的教育水平和技术专长以及本产品的预期使用频度等重要约束。 3.需求规定 1.1对功能的规定 本节依据合同中定义的系统组成部分分别描述其功能,描述应包括: ●功能编号; ●所属产品编号; ●优先级; ●功能定义; ●功能描述。 1.2对性能的规定 本节描述用户对系统的性能需求,可能的系统性能需求有: ●系统响应时间需求; ●系统开放性需求; ●系统可靠性需求; ●系统可移植性和可扩展性需求; ●系统安全性需求; ●现有资源利用性需求。 1.2.1精度 说明对该产品的输入、输出数据精度的要求,可能包括传输过程中的精度。 1.2.2时间特性要求 说明对于该产品的时间特性要求,如对: a)响应时间; b)更新处理时间; c)数据的转换和传送时间; d)计算时间等的要求。 1.2.3灵活性 说明对该产品的灵活性的要求,即当需求发生某些变化时,该产品对这些变化的适应能力,如: a)操作方式上的变化; b)运行环境的变化; c)同其他系统的接口的变化; d)精度和有效时限的变化; e)计划的变化或改进。 对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。 1.3输入输出的要求 解释各输入输出的数据类型,并逐项说明其媒体、格式、数值范围、精度等。 对软件的数据输出及必须标明的控制输出量进行解释并举例,包括对硬拷贝报

java开发规范文档

一千零一夜产品部系统开发规范V1.0 一千零一夜途遇科技有限公司 2015-11-03

修改记录 目录 1前言 (4) 2开发管理 (4) 3项目周期 (4) 4命名规范 (5) 4.1项目编号命名规范 (5) 4.2文档命名规范 (5) 4.3路径管理 (5) 4.4jsp/html命名规范 (6) 4.5数据库命名规范 (8) 4.5.1表名规范 (8) 4.5.2字段规范 (8) 5文档规范 (8) 6代码规范 (9) 6.1Java源代码规范 (9) 6.1.1命名 (9) 6.1.2代码格式 (11) 6.1.3注释 (12) 6.1.4其他 (13) 6.2jsp/html代码规范 (13) 6.3数据库开发规范 (15) 6.3.1主键 (15) 6.3.2日期类型 (16) 6.3.3固定字段 (16) 6.3.4取值规范 (16) 6.3.5数据库开发工具 (16)

6.3.6Sql书写规范 (17) 6.4其他规范 (17) 7实战代码规范 (18) 7.1Java源代码规范 (18) 7.1.1java代码命名与格式 (18) 7.2jsp/html代码规范 (26) 8FAQ (29) 8.1Logic类中新增数据方法怎么写 (29) 8.2Logic类中修改数据方法怎么写 (30) 8.3Logic类中删除数据方法怎么写 (31) 8.4怎样创建一个没有底部按钮的窗口 (32) 8.5怎样设置弹出窗口的标题 (32) 8.6怎样重写提交数据的方法 (33) 8.7怎样创建单grid的页面 (33) 8.8怎样多个页签的grid的页面 (34) 8.9怎样创建左边树右边grid的页面 (34) 9代码检查规定 (34) 10附录1:JPA使用指南javax.persistence的注解配置 (34)

新产品项目开发规范

项目开发规范文档编写人:徐文兵日期:2009-7-20 审核人:日期: 批准人:日期:

修改记录(REVISION CHART)

1 概述 目的与概述 本文档为XX公司的开发规范文档,给开发团队提供开发标准和规范。 整体说明 在开发规范中包含了两个部分,第一部分是项目开发流程规范,主要阐述在项目开发过程中的各个阶段的规范。第二部分为Coding开发规范,Coding 开发规范阐述了在一个框架中的各个层的开发规范 (注:在第一版中不包含对工作流开发的规范制定) 覆盖范围 阅读对象 1.项目管理人员 2.系统设计人员 3.系统开发人员 参考资料 略

2 项目开发流程规范 2.1 业务需求调研阶段 ●调研的目标 系统层面:客户的系统运行环境 业务层面:了解客户需要什么样的系统,具体了解业务目的,业务逻辑,业务数据,客户的操作习惯,页面风格习惯等。 ●调研的准备工作: 行业知识的准备: 了解客户的行业背景,行业领域的业务术语,含义。结合客户行业背景,了解客户的业务知识。 业务专家需求: 在行业领域的复杂度不高的情况下,业务分析人员直接收集并学习行业知识就可以了,但行业知识的准备工作还是要做的 在行业领域业务复杂度高的情况下,需要业务专家对客户的业务的进行整理。 ●调研的流程: 第一步,项目启动阶段了解客户的IT环境。 第二步,讨论并具体确定客户系统的范围,并获得客户业务功能点的原始的单据。在这个过程中准备一个本和一只笔记录讨论的业务信息第三步,整理业务信息,和原始表单,抽取出有效业务信息,并对于不明确的业务信息进行整理和归类,并制作成问卷形式进一步调研。 第四步,发放调研问卷,再次进行业务调研(直接转到三) 第五步,卷写调研问卷,并内部评审 第六步,调研问卷客户评审并确认。 ●调研阶段的交付项(可配置项) 软件需求说明书 软件需求说明书的目录: 1 客户行业背景 2 客户系统的意义 3 客户系统运行的环境 4 业务功能点描述(业务目的,业务逻辑,业务数据,优先级别,使用频率等) 5 客户的操作习惯,页面风格习惯。

软件开发技术文档编写规范

软件开发技术文档编写规范 在项目开发过程中,应该按要求编写好十三种文档,文档编制要求具有针对性、精确性、清晰性、完整性、灵活性、可追溯性。 ◇可行性分析报告:说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性,评述为了合理地达到开发目标可供选择的各种可能实施方案,说明并论证所选定实施方案的理由。 ◇项目开发计划:为软件项目实施方案制订出具体计划,应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。 ◇软件需求说明书(软件规格说明书):对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的,也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求,为生成和维护系统数据文件做好准备。 ◇概要设计说明书:该说明书是概要实际阶段的工作成果,它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等,为详细设计提供基础。 ◇详细设计说明书:着重描述每一模块是怎样实现的,包括实现算法、逻辑流程等。 ◇用户操作手册:本手册详细描述软件的功能、性能和用户界面,使用户对如何使用该软件得到具体的了解,为操作人员提供该软件各种运行情况的有关知识,特别是操作方法的具体细节。 ◇测试计划:为做好集成测试和验收测试,需为如何组织测试制订实施计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。 ◇测试分析报告:测试工作完成以后,应提交测试计划执行情况的说明,对测试结果加以分析,并提出测试的结论意见。 ◇开发进度月报:该月报系软件人员按月向管理部门提交的项目进展情况报告,报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。 ◇项目开发总结报告:软件项目开发完成以后,应与项目实施计划对照,总结实际执行的情况,如进度、成果、资源利用、成本和投入的人力,此外,还需对开发工作做出评价,总结出经验和教训。 ◇软件维护手册:主要包括软件系统说明、程序模块说明、操作环境、支持软件的说明、维护过程的说明,便于软件的维护。 ◇软件问题报告:指出软件问题的登记情况,如日期、发现人、状态、问题所属模块等,为软件修改提供准备文档。 ◇软件修改报告:软件产品投入运行以后,发现了需对其进行修正、更改等问题,应将存在的问题、修改的考虑以及修改的影响作出详细的描述,提交审批。 1可行性分析报告 1 引言 1.1 编写目的:阐明编写可行性研究报告的目的,提出读者对象。

硬件开发流程及规范 (1)

硬件开发流程及规范 硬件开发流程及规范 一、主板 二、辅助PCB及FPC 三、液晶屏 四、摄像头 五、天线 六、SPEAKER 七、RECEIVER 八、MIC 九、马达 十、电池 十一、充电器 十二、数据线 十三、耳机 版2008-12-13

(一)主板 1.开发流程: 2.资料规范 1)主板规格书 a)基本方案平台; b)硬件附加功能: c)软件附加功能; d)格式和排版布局合理,便于打印; 范例格式见下表:

E519 PDA主板规格书 2)元件排布图 a)标明所有接插件名称、引脚定义,方向及连接器型号;

b)标明所有外部焊接位置的名称,极性; c)位号图可用放大的图纸单独标示,并标明需区分方向和极性的器件; d)标明所有结构尺寸比较高可能影响装配的器件; e)格式和排版布局合理,便于打印; 范例格式见下图: 3)BOM a)每次改版记录要明确记录在改版记录中,明确试产版和量产版及版本号和日期; b)保证数据正确性,物料编码与物料描述一致,位号数量与用量一致,物料种数和数量与改版 记录一致; c)结构件、IC、阻容件分类,按一定顺序排列; d)功能可选项分开列出(注意相互的关联性); e)格式和排版布局合理,便于打印(所用文字全部显示); 范例格式见下表:

4)SMT试产报告 a)召开试产会议,所用发现的问题要全部列出,并修改相关的文件; b)所用问题要有解决措施,并明确责任人限时处理; c)有代表性的问题要列入设计查核表,防止类似问题再次出现; d)记录试产环境及关键参数; e)报告审核后发相关部门负责人; f)保证数据真实性,有任何问题要找到确实的原因,不可用习惯性思维处理; 范例格式见下表: SMT试产报告

软件开发标准化工作流程V10

目录 软件开发标准化工作流程 1引言 1.1编写目的 说明编写这份软件开发标准化工作流程的目的,指出预期的读者。 1.2适用范围 互联网开发中心所有项目。 1.3定义 列出本文件中用到的专门术语的定义、外文首字母组词的原词组。

1.4流程图 2需求调研 2.1概述 需求调研对于一个应用软件开发来说,是一个系统开发的开始阶段,需求调研的质量对于一个应用软件来说,是一个极其重要的阶段,它的质量在一定程度上来说决定了一个软件的交付结果。怎样从客户中听取用户需求、分析用户需求就成为调研人员最重要的任务。

2.2需求调研 总体而言,需求调研可按照业务流程、业务规则、表单数据、贯穿系统的关系四个方向来进行调研。 ●业务规则 各个流程、功能点等事项的办理,都会有相关约束或条件,那么需要对其前置条件、后置条件、数据验证、条件判断等进行分析调研。调研对象一般为操作员。 ●表单数据 对各个功能点的业务数据、数据项、表单格式、查询条件以及其它相关数据进行明确的分析调研。调研对象一般为操作员。 ●贯穿系统的关系 各个模块或科室之间的数据交换、传递以及数据共享等,需要我们调研人员与各个模块或科室的相关负责人进行多方沟通,确定一个多方满意的需求调研结果。 2.3注意事项 ●调研过程中,用户说的很快,不可能等我们全部记录之后, 再讲下一个问题。因此,只能在笔记本上速记,有时只能记录1、2个关键字。因此,每天调研结束之后,当天晚上必须整理当天的调研情况,写成一份调研日记。整理当天的调研记录时,还要整理出待明确的问题,下一次再找机会与用户再沟通、确认。

●调研的各个阶段,必须出具相关文档或文件,比如调研计划、 流程图、表单样式、报表格式、背景图片、数据项列表、讨论记录、问题列表等。 ●所有疑问必须等到明确的答复,不能出现相互矛盾、似是而 非的需求。需准确理解客户的讲解,如果有问题的先做记录,之后将整理的问题向客户询问,得到明确的结果。需求必须是客户接受和确认的,不能有臆测的需求。 ●要合理安排好时间和进度。有时候客户还有自己要做的事情, 不一定能及时相应。所以必须提前预约好时间,保证整个需求调研的进度。 ●能积极引导客户。当客户出现疑虑,而调研人员能明白且能 做好客户想要的东西的时候,调研人员能及时积极引导客户,详细讲解我们所知道的东西,并能让客户接受与确认。 ●如遇公司有相关原型或产品,调研人员需先详细了解公司的 相关原型和产品,根据成品,找出本地化的差异化需求。 3可行性分析 这个阶段要回答的关键问题:“对于上一个阶段所确定的问题有行得通的解决办法吗?”为了回答这个问题,系统分析员需要进行一次大大压缩和简化了的系统分析和设计的过程,也就是在较抽象的高层次上进行的分析和设计的过程。 可行性研究应该比较简短,这个阶段的任务不是具体解决

HTML/CSS代码开发规范文档

HTML/CSS代码开发规范文档

目录 1、前言 (4) 2、HTML编码规范 (4) 2-1HTML标记的关闭规范 (4) 2-2HTML文件头基本标记 (4) 2-2HTML正文代码标记元素 (5) 2-3HTML标记的缩进规范 (6) 3、HTML文件引入CSS样式代码和Javascript代码规范 (6) 3-1引入css样式代码规范 (6) 3-2引入Javascript代码规范 (7) 4、HTML注释标签 (8) 5、CSS编码规范 (8) 5-1 CSS编码要求 (8) 5-2 CSS样式表规范 (8) 5-3 CSS命名规范 (9) 5-4样式文件命名 (10) 5-5样式文件布局 (11) 6、CSS常规书写规范及方法 (11) 6-1文件调用方法: (11) 6-2 CSS结构化书写 (11) 6.2.1派生选择器: (11) 6.2.2辅助图片用背影图处理: (12) 6.2.3结构与样式分离: (12) 6.2.4文档的结构化书写 (12) 6-3 HACK CSS书写规范 (13) 6.3.1 IE6、IE7、Firefox之间的兼容写法 (13) 6.3.2屏蔽IE浏览器 (14) 6.3.3清除浮动 (14) 6.3.4鼠标手势 (15) 7、CSS性代码缩写 (15) 7.1不同类有相同属性及属性值的缩写 (15) 7.2同一属性的缩写 (16) 7.3内外侧边框的缩写 (16) 7.4颜色值的缩写 (18) 8、CSS注释书规范 (18) 8.1行间注释 (18) 8.2整段注释 (18)

1、前言 本编程规范适用于需要编写HTML/CSS代码的网页程序开发人员。本规范并不是一个一成不变的必须严格遵守的条文,特殊情况下要灵活运用,做一定的变通。 2、HTML编码规范 HTML是一种标记语言, HTML没有任何真正的编程语言中的循环或是流程控制语句。然而,HTML代码的格式和风格是非常重要的,因为要经常对HTML代码进行维护和修改,因此HTML代码必须有很清晰的逻辑结构和布局,增强可读性,而使其易懂和易于维护。HTML代码本身是不区分大小写的,但是为了更好的统一代码布局,项目中HTML文件标记都以小写为主。 2-1HTML标记的关闭规范 HTML文档的正文都应在标记中间,而标记则应包含在和标记之间。如: 正文 不同类的标记不能交叉编码: eg: 内容 正确编码应为:内容 开始和关闭标记放在一行的标记有: eg: 各种标题标记,如

2-2HTML文件头基本标记 ① ②

相关文档
最新文档