软件企业软件产品收入、研发费用和应交税金明细表专项审计报告(参考格式)
专项审计报告
X审（XX）号有限公司：
我们审计了后附的有限公司（以下简称贵公司）XX年度软件产品开发销售（营业）收入情况归集表（附件1）、研究开发费用情况归集表（附件2）和企业主要应交税金明细表（附件3）（以下简称三张明细表）。
一、管理层的责任
在企业会计准则框架下，按照《软件企业评估规范》（T/310104003-F001-2015）、《关于进一步鼓励软件产业和集成电路产业发展企业所得税政策的通知》（财税[2012]27号）和《关于完善研究开发费用税前加计扣除政策的通知》（财税〔2015〕119号）的规定，如实编制三张明细表，是贵公司管理层的责任。这种责任包括：（1）按照上述相关文件规定编制三张明细表，并使其实现公允反映；（2）设计、执行和维护与三张明细表相关的内部控制，以使三张明细表不存在由于舞弊或错误而导致的重大错报；（3）恰当界定软件产品（服务）和研究开发项目的具体范围。
二、注册会计师的责任
我们的责任是在实施审计工作的基础上对三张明细表发表审计意见。我们按照中国注册会计师审计准则的规定执行了审计工作。中国注册会计师审计准则要求我们遵守职业道德守则，计划和执行审计工作以对三张明细表是否不存在重大错报获取合理保证。
我们相信，我们获取的审计证据是充分、适当的，为发表审计意见提供了基础。
三、审计意见
我们认为，贵公司XX年度三张明细表在所有重大方面在企业会计准则框架下，按照《软件企业评估规范》（T/310104003-F001-2015）、《关于进一步鼓励软件产业和集成电路产业发展企业所得税政策的通知》（财税[2012]27号）和《企业研究开发费用税前扣除管理办法[试行]》（国税发〔2008〕116号）的规定编制，公允反映了贵公司在所审计期间的软件产品开发销售（营业）收入、研究开发费用和主要税金的应交和已交情况。
四、其他需说明的事项
（如有）
五、使用限制
本报告仅供贵公司申报软件企业评估（年检）时使用。
上海XXX会计师事务所有限公司中国注册会计师：
中国·上海中国注册会计师：
地址：东方路818号14F座日期：二○XX年月日
附件1
径按照财税〔2012〕27号文件第十六条的规定归集。
附件2
局关于印发《关于完善研究开发费用税前加计扣除政策的通知》（财税〔2015〕119号）规定进行归集。
附件3
年企业主要应交税金明细表
软件工程国家标准、行业标准一览
软件工程国家标准、行业标准一览摘自计算机软件工程规范国家标准汇编2003 DZ/T 0169-1997 物探化探计算机软件开发规范 GB 17917-1999 商场管理信息系统基本功能要求 GB 8566-1988 计算机软件开发规范(已为GB/T8566-1995替代) GB/T 11457-1995 软件工程术语 GB/T 12504-1990 计算机软件质量保证计划规范 GB/T 12505-1990 计算机软件配置管理计划规范 GB/T 14079-1993 软件维护指南 GB/T 14085-1993 信息处理系统计算机系统配置图符号及约定 GB/T 15532-1995 计算机软件单元测试 GB/T 15538-1995 软件工程标准分类法 GB/T 15853-1995 软件支持环境 GB/T 16260-1996 信息技术软件产品评价质量特性及其使用指南 GB/T 16680-1996 软件文档管理指南 GB/T 17544-1998 信息技术软件包质量要求和测试 GB/T 17917-1999 商场管理信息系统基本功能要求 GB/T 18234-2000 信息技术C ASE工具的评价与选择指南 GB/T 18491.1-2001 信息技术软件测量功能规模测量第1部分：概念定义 GB/T 18492-2001 信息技术系统及软件完整性级别 GB/T 18905.1-2002 软件工程产品评价第1部分: 概述 GB/T 18905.2-2002 软件工程产品评价第2部分: 策划和管理 GB/T 18905.3-2002 软件工程产品评价第3部分: 开发者用的过程 GB/T 18905.4-2002 软件工程产品评价第4部分: 需方用的过程 GB/T 18905.5-2002 软件工程产品评价第5部分: 评价者用的过程 GB/T 18905.6-2002 软件工程产品评价第6部分: 评价模块的文档编制 ★GB/T 8566-1995 信息技术软件生存期过程(已为GB/T8566-2001替代) GB/T 8566-2001 信息技术软件生存周期过程 GB/T 9385-1988 计算机软件需求说明编制指南 GB/T 9386-1988 计算机软件测试文件编制规范 GB/Z 18493-2001 信息技术软件生存周期过程指南 GB/Z 18914-2002 信息技术软件工程CASE工具的采用指南 GJB 1091-1991 军用软件需求分析 GJB 1419-1992 军用计算机软件摘要 GJB 2115-1994 军用软件项目管理规程 GJB 2255-1994 军用软件产品 GJB 3181-1998 军用软件支持环境选用要求 GJB 437-1988 军用软件开发规范 GJB 438-1988 军用软件文档编制规范 GJB 438A-1997 武器系统软件开发文档 GJB 439-1988 军用软件质量保证规范 GJB/Z 102-1997 软件可靠性和安全性设计准则 GJB/Z 115-1998 GJB 2786《武器系统软件开发》剪裁指南 GJB/Z 117-1999 军用软件验证和确认计划指南
Quidway NetEngine20产品软件质量标准V6
NE20产品软件质量标准V6.0 总则： 1.申明 本标准旨在规范安装和维护华为公司设备的相关操作，不作为建设单位或监理单位用于工程验收的标准。 本总则的各条说明与华为公司相关流程制度相冲突时，以华为公司相关流程制度为准。 2.计分办法 总分为50分。采用扣分制，违反一条就扣掉该条款对应的分数，质量得分为50减去所有扣分，最低0分。得分小于45分为质量不合格。 3.扣分原则 一个工程（对应一个工程号）含有多个产品时，各产品质量问题扣分要累加计算。 一个工程（对应一个工程号）含有多个局点时，各个局点质量问题扣分要累加计算，但最多累计3个局点。 一个工程（对应一个工程号），相同质量问题扣分必须累加计算，但最多累计3次。 对于自检报告中遗漏的问题，或自检报告中注明的原因不符合华为公司相关规定，或没有注明原因的问题，华为公司在质量检查时要按照该标准条款进行扣分。 4.整改要求 i.违反A类条款（标准条款编码的最后一位为“A”） 所有问题必须整改，否则必须与客户签署备忘录。经过多方协调客户仍然不同意签署备忘录时，请知会华为公司工程管理相关人员，且必须在自检报告中注明以备查。 ii.违反B、C类条款（标准条款编码的最后一位为“B”或“C”） 本次工程产生的问题：本次工程产生的无法整改的质量问题可以不整改（必须在自检报告中注明原因以备查），其余必须全部整改。 本次工程以前的遗留问题：本次工程如果有条件整改时必须整改。 5.自检报告的填写规范 工程督导必须将工程存在的所有违反质量标准的问题（包括质量检查工具误判的问题），在自检报告中全部列出，同时注明其原因。未整改的以及没有注明合理原因的问题，在自检报告中应该按照质量标准进行扣分。 6.数据的及时归档 工程督导应在华为公司规定时间归档或刷新CEAS系统工程文档，华为公司在质量检查时所使用的相关数据若取自CEAS系统,因CEAS数据问题，造成华为公司的质量检查结果出错，责任由工程督导及相关单位承担，华为公司不会因此更改质量检查结果。 7.备忘录的签署规范和归档要求 工程督导自检时与客户签署的备忘录，须有客户的签章（或签字），要尽量描述清楚存在的质量问题，以及可能引起的后果和相关各方应该承担的责任。 工程督导必须在华为公司规定的时间内，将备忘录扫描件（或数码照片）随同自检报告一起上载到EPMS系统中。其它形式的或超时上载的备忘录无效，相关质量问题在工程督导自检或华为公司质量检查时应按照质量标准进行扣分。 8.本标准适用范围 一级标准，适用于县级以上（含县级）通信机房安装的NE20路由器等产品的安装与维护涉及的工程督导自检、合作单位质量检查、华为公司工程质量检查、华为公司维护质量检查等。 9.本标准解释与生效 本标准的解释权归华为技术有限公司所有。 对本标准存在任何疑问，必须向华为公司工程管理相关人员进行咨询和寻求解决，否则由此引起的后果由相关责任人或单位承担。 本标准从颁布之日起执行，一切与以往标准的不同之处，以本标准为准。 10.本标准各条款编码的含义 A、第1、2、3位：“DSD”为本标准的代号。依次为：“D”表示数通产品线，“S”表示软件质量标准，“D” 表示本产品线软件质量标准的序号。 B、第4、5、6位：本标准中各条款的分类编号。第4位为大类编号，按照“A”、“B”、“C”等顺序编写， 第5、6位为该大类下的序号。 C、第7位：本标准中各条款的重要程度：用“A”、“B”、“C”表示。 A类条款：重要问题。违反该条款，将严重影响设备安全运行。 B类条款：次要问题。违反该条款，将影响设备正常运行，或给设备正常运行埋下隐患。 C类条款：轻微问题。违反该条款，不影响设备正常运行，但是将影响、今后扩容和维护操作的便利性等。
计算机软件产品开发的标准化规范化要求
计算机软件产品开发的标准化规范化要求 发布部门：工业中华人民共和国机械工业部发布文号： 分类导航：所属类别：部委行业规章 发布日期：1991-01-19关键字： 【阅读全文】 —、划分阶段 一个软件项目从可行性研究起到开发成功投入使用，要经过若干互相区别而又联系的阶段。一般划分为以下六个阶段： （１）可行性研究与计划阶段。确定项目开发目标和总的要求，进行可行性分析、投资、效益分析，并制订开发计划。 （２）需求分析阶段。根据对系统的分析，确定软件项目的各项功能、性能。 （３）设计阶段。在充分理解软件需求的基础上，提出多个设计方案，经分析比较，确定最佳方案。 （４）实现阶段。完成源程序的编码、编译和调试工作。 （５）测试阶段。对程序进行全面测试，并检查审阅已编制的文件。 在整个开发过程中（即前五个阶段），开发单位要按月编制开发进度月报。 （６）运行与维护阶段。在软件运行使用中，不断进行维护，并根据新的要求，对原程序进行必要的扩充与删改。 在每个阶段中，都要编制一定的文件。这些文件是整个软件项目成果的不可缺少的组成部分。其作用是： （１）本阶段工作的成果和结束标志。 （２）反映开发工作的进展情况，以便对各阶段进行检查。 （３）提供技术和管理信息，便于管理人员、开发人员、操作人员和用户之间相互了解和协作。 （４）对整个项目内容、功能和性能的描述。
二、各阶段所需完成的文件和文件编制目的与内容 （１）可行性研究报告：在可行性研究与计划阶段完成。目的是说明该软件开发项目在技术、经济和社会条件方面的可行性，并在多方案中论证所选定的方案，内容包括：
①对现有系统的分析；②系统方案的选定；③投资与效益分析。 （２）项目开发计划：在需求分析阶段完成。目的是把项目开发过程中各项工作的负责人、进度、对软硬条件、经费预算的安排以文件形式记载下来，以利据此检查项目的开发工作，内容包括： ①项目概述：项目内容；主要参加人；产品及成果验收标准；完成时间等。 ②实施总计划：任务分解；进度；预算；关键问题等。 ③支持条件：计算机系统支持；需用户承担的工作等。 ④专题计划要点。 （３）项目需求说明：在需求分析阶段完成。目的是对项目完成后应达到的具体要求作出规定，作为开发工作的基础，内容包括： ①任务概述：目标；项目环境的特点；约束条件。 ②要求规定：主要性能；可靠性、灵活性、时效性、友好性等要求；输入输出要求；常规处理要求；异常处理要求；其他专门要求。 ③环境规定：设备；支持软件；接口；控制。 （４）测试计划：在需求分析和设计阶段完成。目的是为提供一个对开发软件项目的测试计划，内容包括： 测试内容；进度安排；测试方案设计考虑；测试数据的整理方法；测试结果的评价准则。 （５）项目设计说明：在设计阶段完成。目的是说明对程序系统的设计考虑和说明系统各层次中的每个程序的设计考虑。此部分由于工程项目的不同而差异很大。开发单位可参照有关标准具体编写，总的要求是： ①总体设计：包括需求规定；运行环境；逻辑结构；物理结构；关键问题和解决方案等。 ②详细设计：包括控制及处理流程；功能、性能和输入输出设计等。表达形式：有文字、图、表等。 （６）使用说明：在需求分析、设计和实现阶段中逐步完成，内容包括： ①用户手册：提交给用户的使用说明，主要内容： １）概述 ２）用途：功能、性能 ３）运行环境：硬件、支持软件
软件产品验收测试标准
软件产品验收测试标准和流程 1. 验收测试简介 验收测试即由产品开发方按照需求文档中所有内容（或按合同及其它有效约定，对方承诺实现的需求）进行开发、内测完毕，提交版本符合验收测试标准，通过验收小组进行的测试。通过验收测试判断产品质量是否符合产品需求，功能实现是否正确并可以最终上线。 2. 验收测试目的 通过验收测试判断产品质量是否符合产品需求、功能实现是否正确，性能和安全性方面是否符合发布标准，并且产品可以最终上线。 3. 验收测试范围 3.1界面测试 所有页面浏览，连接的正确、所有功能按钮及界面显示正确 3.2功能测试 所有需求文档描述的功能实现正确 3.3性能测试 重点业务功能、性能能满足上线运营需求 3.4安全性测试 接口和数据调用等方面符合安全性规范；没有安全性漏洞 4. 验收测试流程 验收测试基本工作流程如下： 4.1. 准入条件检测 4.1.1文档 进入验收测试的文档准备齐全： a) 验收版本的需求文档（提交方提供）：要求需求文档与最终提交验收测试的程序完全匹配； b) 验收版本的测试用例（提交方提供）：要求测试案例覆盖最终版本的需求文档；
c) 验收版本的测试告（提交方提供）：在测试报告书中说明测试总体情况，缺陷列表及修复情况； 4.1.2缺陷 要求开发方在合同双方约定的环境中对需要文档上提及的所有功能进行全面测试，且提交验收测试时，开发方发现的所有缺陷都已解决。 4.1.3测试环境 验收测试环境准备完成，与线上真实环境一致 4.1.4沟通和联系 1. 提交验收测试的开发方负责人联系方式及测试工程师联系方式齐全； 2. 提交验收测试缺陷的沟通渠道建立完毕，要求快捷、准确、反馈及时； 4.2 验收测试 4.2.1文档验收 进入标准：文档准备必须齐全且符合标准，可以进入文档验收流程 中断标准： 1. 需求文档并非最终版，需求文档上描述的功能程序并未实现 2. 测试用例与需求文档不匹配，测试用例中测试的模块在需求文档中不存在或者需求文档中的功能模块未在测试用例中体现 3. 测试报告书不完整，遗留缺陷不符合遗留缺陷允许限制的数量 退出标准： 文档符合标准并通过验收，进入程序验收流程 4.2.2程序功能验收 进入标准：文档验收流程结束 中断标准： 1. 出现A，B级缺陷 2. C级缺陷达到8个 3. 验收测试过程中，提交新的版本 退出标准： 验收测试合格，缺陷按照标准修复完成 通过标准： 要求验收测试结束后，未解决的缺陷达到以下要求时，才能验收通过： a) A级缺陷：0个； b) B级缺陷：0个； c) C级缺陷：小于等于总缺陷数的3%； d) D级缺陷：小于等于总缺陷数的5%个； e) E级缺陷：小于等于总缺陷数的15%个。 注：对于放弃处理的提案，必须提前经过我方同意。
软件工程国家标准.doc
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. 控制精度或生产能力的提高。
软件产品管理办法
软件产品管理办法 中华人民共和国信息产业部令第5号 《软件产品管理办法》，已经2000年10月8日信息产业部第4次部务会议通过，现予发布，自发布之日起施行。 部长吴基传 二○○○年十月二十七日 第一章总则 第一条为了加强软件产品管理，促进我国软件产业的发展，根据国家有关法律法规和国务院《鼓励软件产业和集成电路产业发展的若干政策》（以下简称《产业政策》），制定本办法。 第二条中华人民共和国境内的软件产品（含国产软件和进口软件）经营与管理活动，适用本办法。单位或个人自己开发并自用的软件以及委托他人开发的自用专用软件不适用本办法。 第三条本办法所称的软件产品，是指向用户提供的计算机软件、信息系统或设备中嵌入的软件或在提供计算机信息系统集成、应用服务等技术服务时提供的计算机软件。 本办法所称国产软件，是指在我国境内开发生产的软件产品。本办法所称进口软件，是指在我国境外开发，以各种形式在我国生产、经营
的软件产品。 第四条软件产品的开发、生产、销售、进出口等活动应遵守我国有关法律、法规和标准规范。任何单位和个人不得开发、生产、销售、进出口含有以下内容的软件产品： （一）侵犯他人知识产权的； （二）含有计算机病毒的； （三）可能危害计算机系统安全的； （四）含有国家规定禁止传播的内容的； （五）不符合我国软件标准规范的。 第五条信息产业部负责全国软件产品的管理，其主要职责是：（一）制定并发布软件产品测试标准和规范； （二）对各省、自治区、直辖市登记的国产软件产品备案； （三）指导并监督、检查全国各地的软件产品管理工作； （四）授权软件产品检测机构，按照我国软件产品的标准规范和软件产品的测试标准及规范，进行符合性检测； （五）制定全国统一的软件产品登记号码体系、制作软件产品登记证书； （六）发布软件产品登记通告。 第六条各省、自治区、直辖市信息产业主管部门负责本行政区域内软件产品的管理工作，审查和批准本行政区域内国产软件的登记。省、自治区、直辖市信息产业主管部门授权的软件企业认定机构负责受理本行政区域内国产软件的登记。
软件企业认定标准
软件企业的认定标准是： 1.在我国境内依法设立的企业法人； 2.以计算机软件开发生产、系统集成、应用服务和其他相应技术服务为其经营业务和主要经营收入； 3.具有一种以上由本企业开发或由本企业拥有知识产权的软件产品，或者提供通过资质等级认定的计算机信息系统集成等技术服务； 4.从事软件产品开发和技术服务的技术人员占企业职工总数的比例不低于50%； 5.具有从事软件开发和相应技术服务等业务所需的技术装备和经营场所； 6.具有软件产品质量和技术服务质量保证的手段与能力； 7.软件技术及产品的研究开发经费占企业年软件收入8%以上； 8.年软件销售收入占企业年总收入的35％以上，其中，自产软件收入占软件销售收入的50％以上。 9.企业产权明晰，管理规范，遵纪守法。 申请认定的企业应向软件企业认定机构提交下列材料； 1.软件企业认定申请表，包括资产负债表、损益表、现金流量表、人员配置及学历构成、软件开发环境和企业经营情况等有关内容； 2.企业法人营业执照副本及复印件； 3.企业开发、生产或经营的软件产品列表，包括本企业开发和代理销售的软件产品；
4.本企业开发或拥有知识产权的软件产品的证明材料，包括软件产品登记证书、软件著作权登记证书或专利证书等； 5.系统集成企业须提交由信息产业部须发的资质等级证明材料； 6.信息产业部要求出具的其他材料。 新办软件企业的税收优惠政策？ 新办软件企业经认定后，自开始获利年度起，第一年至第二年免征所得税，第三年至第五年减半征收所得税。（两免三减半）软件企业享受优惠政策是从获利年度，获利年度是指企业开始生产经营后第一个获利的年度，企业开办初期有亏损的，可以按规定逐年弥补，以弥补后有利润的纳税年度为开始获利的年度。如果获利年度中间有亏损的应连续计算。 如：某企业2000年成立，当年亏损100万元，2001年盈利30万元，2002年亏损50万元，2003年盈利120万元。该企业开始获利年度为2003年，因为2001年虽然有盈利但是不足弥补2000年的亏损，而2003年将2000年和2002年发生的亏损弥补以后开始有盈利。 软件企业的企业所得税是否减半征收？ 问：我公司认定为软件企业后，企业所得税是不是减半征收？ 答：根据《关于鼓励软件产业和集成电路产业发展有关税收政策问题的通知》（财税[2000]25号）文件规定，对我国境内新办软件生产企业经认定后，自开始获利年度起，第一年和第二年免征企业所得税，第三年至第五年减半征收企业所得税。你公司可到主管税务机关办理减免税审批手续。 问：软件企业即征即退的增值税如何做纳税调整？
开发类软件产品验收标准
保密 XXX 项目产品验收标准产品验收标准 ***有限公司 ***有限公司 20XX 年 XX 月 XX 日 产品验收标准 文档修订记录 版本号 *变化状态 C 初始版本 简要说明 日期 变更人
批准日期 批准人 *变化状态：C = 创立，A = 增加，M = 修改，D = 删除 *正式发布时文档版本号从开始。对文档进行小改动时，版本号以进阶；大改动时版本号以进阶。 文档审批记录 序号 审批人 角色 审批日期 签字 备注
第 2 页共 15 页 产品验收标准 目录 1. 前言.................................................................... ....................................................................... 5 . 目的.................................................................... ....................................................... 5 . 范围.................................................................... ....................................................... 5 . 术语定义.................................................................... ............................................... 5 . 预期读者与阅读建议 ................................................................... ............................ 5 . 参考.................................................................... ....................................................... 5 2. 项目概述.................................................................... ............................................................... 6 3. 验收原
计算机软件产品开发标准与规范
引言 1 目的 一项计算机软件的筹划、研制及实现，构成一个软件开发项目。一个软件开发项目的进行，一般需要在人力和自动化资源等方面作重大的投资。为了保证项目开发的成功，最经济地花费这些投资，并且便于运行和维护，在开发工作的每一阶段，都需要编制二定的文件。这些文件连同计算机程序及数据一起，构成为计算机软件。文件是计算机软件中不可缺少的组成部分，它的作用是：a．作为开发人员在一定阶段内的工作成果和结束标志； b．向管理人员提供软件开发过程中的进展和情况，把软件开发过程中的一些“不可见的”事物转换成“可见的”文字资料。以便管理人员在各个阶段检查开发计划的实施进展，使之能够判断原定目标是否已达到，还将继续耗用资源的种类和数量； C．记录开发过程中的技术信息，便于协调以后的软件开发、使用和修改； d．提供对软件的有关运行、维护和培训的信息，便于管理人员、开发人员、操作人员和用户之间相互了解彼此的工作； e．向潜在用户报导软件的功能和性能，使他们能判定该软件能否服务于自己的需要。 换言之，本指南认为：文件的编制必须适应计算机软件整个生存周期的需要。 计算机软件所包含的文件有两类：一类是开发过程中填写的各种图表，可称之为工作表格；另一类则是应编制的技术资料或技术管理资料，可称之为文件。本指南规定软件文件的编制形式，并提供对这些规定的解释。本指南的目的是使得所编制的软件文件确实能够起到软件文件应该发挥的作用。 2 范围 本指南是一份指导性文件。本指甫建议，在一项计算机软件的开发过程中，一般地说，应该产生十四种文件。这十四种文件是： 可行性研究报告； 项目开发计划； 软件需求说明书；
数据要求说明书； 概要设计说明书； 详细设计说明书； 数据库设计说明书； 用户手册； 操作手册； 模块开发卷宗； 测试计划； 测试分析报告； 开发进度月报； 项目开发总结报告。 本指南将给出开发过程中建议产生的这十四种文件的编制指导，同时，本指南也是这十四种文件的编写质量的检验准则。但是，本指南并未涉及软件开发过程中如何填写工作表格的问题。 一般地说，一个软件总是一个计算机系统（包括硬件、固件和软件）的组成部分。鉴于计算机系统的多样性，本指南一般不涉及整个系统开发中的文件编制问题，本指南仅仅是软件开发过程中的文件编制指南。 3 文件的使用者 对于使用文件的人员而言，他们所关心的文件的种类，随他们所承担的工作而异。 管理人员：可行性研究报告， 项目开发计划， 模块开发卷宗， 开发进度月报， 项目开发总结报告； 开发人员：可行性研究报告， 项目开发计划， 软件需求说明书， 数据要求说明书， 概要设计说明书， 详细设计说明书， 数据库设计说明书， 测试计划，
软件工程国家标准
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. 控制精度或生产能力的提高。
软件质量国家标准GB(质量管理度量)
软件质量国家标准GB-T8566--2001G,软件质量要素: 1.功能性-与一组功能及其指定性质有关的一组属性,这里的功能是满足明确或隐含的需求的那些功能.包含: a.完备性-软件功能完整,齐全有关的软件属性. b.正确性-能否得到正确或相符结果或效果有关的软件属性 2.可靠性-在规定的一段时间和条件下,与软件维持其性能水平的能力有关的一组属性.包含: a.可用度-软件运行后在任一随机时刻需要执行规定任务或完成规定功能时,软件处于可使用状态的概率. b.初期故障率-软件在初期故障期(一般为软件交付用户后的3个月)内单位时间(100小时)的故障数. c.偶然故障率-软件在偶然故障期(一般为软件交付用户后的4个月以后)内单位时间的故障数. d.平均失效前时间(MTTF)-软件在失效前正常工作的平均统计时间. e.平均失效间隔时间(MTBF)-软件在相继两次失效之间正常工作的平均统计时间.一般民用软件大体在1,000小时左右. f.缺陷密度(FD)-软件单位源代码(1,000行无注释)中隐藏的缺陷数量.典型统计表明,开发阶段平均50-60个缺陷/千行源码, 交付后平均15-18个缺陷/千行源码. g.平均失效恢复时间(MTTR)-软件失效后恢复正常工作所需的平均统计时间. 3.易用性-由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性.包含: a.易理解性-用户认识软件的逻辑概念及其应用范围所花的努力有关的软件属性. b.易学习性-用户为学习软件(运行控制,输入,输出等)所花的努力有关的软件属性. c.易操作性-用户为操作和运行控制所花的努力有关的软件属性 4.效率性-与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性.包含: a.输出结果更新周期-软件相邻两次输出结果的间隔时间. b.处理时间-软件完成某项功能(辅助计算或决策)所用的处理时间(不含人机交互的时间). c.吞吐量-单位时间软件的信息处理能力(各种目标的处理批数). d.代码规模-软件源程序的行数(不含注释), 属于软件的静态属性 5.可维护性-与进行指定的修改所需的努力有关的一组属性 6.可移植性-与软件从一个环境转移到另一个环境的能力有关的一组属性. 影响软件系统质量的4个关键技术要素 1.技术平台的寿命 2.试运行期 3.对于现有系统的迁移 4.技术扩展 服务质量的要素 1.可靠性-不仅可靠,而且准确地实现许诺服务的能力
软件标准规范
软件界面设计及编码标准规范 (仅供内部使用) 文档作者：____________________ 日期：___/___/___ 开发/测试经理：____________________ 日期：___/___/___ 产品经理：____________________ 日期：___/___/___ 管理办：____________________ 日期：___/___/___ 请在这里输入公司名称 版权所有不得复制
电能质量数据分析软件界面设计及编码标 准规范 文档修改记录
目录 一、开发环境 (4) 二、软件界面设计标准规范 (4) 2．1编写目的 (4) 2．2内容： (4) 2.2.1界面设计思想 (4) 2.2.2界面设计原则 (4) 2.2.3界面设计样式 (4) 2.2.4常见提示信息样式 (4) 2.2.5常见错误信息样式 (5) 2.2.6其他界面约定 (5) 三、软件编码设计标准规范 (5) 3．1．编写目的： (5) 3．2内容： (6) 3．2．1对象命名约定 (6) 3．2．2常量和变量命名约定 (7) 3．2．3结构化编码约定 (8) 3．2．4数据源的约定 (9) 3．2．5数据库访问约定 (9) 3．2．6其他约定 (9)
一、开发环境 NT4。0、WIN98作开发操作平台 前台采用(此处输入开发工具名称)作开发工具，后台以（此处输入数据库名称）作数据库来管理数据存储。 屏幕分辨率：800*600 ,大字体，可在程序启动后自动设定。 二、软件界面设计标准规范 2．1编写目的 当今软件界的所有软件无不是可视化的用户界面，它的好处不外乎它有美观、直接、操作者易懂和操作方便等好处。（此处输入编写文档的具体目的）。 2．2内容： 2.2.1界面设计思想 “为用户设计，而不是设计者”。 2.2.2界面设计原则 （1）界面要美观、操作要方便并能高效率地完成工作。 （2）界面要根据用户需求设计。 （3）界面要根据不同用户的层次设计。（有的用户对计算机相当了解而有的从来就没碰过计算机） （4）避免出现嵌套式的界面设计。 （5）界面和代码要相互制约。 （6）界面要通“人性”。即要有引导用户操作的功能，不能是操作一有误就卡住什么都做不下去，又无任何提示来帮助用户如何进行操作。 2.2.3界面设计样式 (1)登录界面 （此处加入登陆界面图） （2）系统功能布局 菜单形式 （此处加入界面图） 标签栏形式 （此处加入界面图） （3）录入界面 （此处加入界面图） （4）查询界面 （此处加入界面图） （5）统计界面 （此处加入界面图）
软件设计文档国家标准GB8567
软件设计文档国家标准GB８５６７-88 一、文档编写标准化 在整个项目开发及使用过程中,应该有完备的文档支持，文档编制要求具有针对性、精确性、清晰性、完整性、灵活性和可追溯性。 完备的文档对软件的开发及使用起了很大的作用。一般要求编写好十三种文档。 1、可行性分析报告 说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性,评述为了合理地达到开发目标可供选择的各种可能实施方案,说明并论证所选定实施方案的理由。 2、项目开发计划 为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。 3、软件需求说明书(软件规格说明书） 对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求,为生成和维护系统数据文件做好准备。 4、概要设计说明书 是概要设计阶段的工作总结。主要包括功能分配、模块划分、程序总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理等，为详细设计作好准备。 5、详细设计说明书 着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。 6、用户操作手册 详细描述了该软件的功能、性能和用户界面，使用该软件的具体方法等。 ７、测试计划 包括测试内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。8、测试分析报告 测试计划的执行情况,对测试结果的分析,提出测试结论。 9、开发进度月报 按月提交的项目进展情况报告。包括计划与实际执行情况的对比、阶段成果、遇到的问题、解决的方法以及下一步的打算。 １0、项目开发总结报告 项目完成以后，总结实际执行情况。如进度、成果、资源利用、成本和投入的人力，对项目开发作出评价，总结经验与教训。 11、软件维护手册 主要包括软件系统说明、程序模块说明、操作环境、支持软件说明、维护过程说明等。12、软件问题报告 记录软件出现问题的日期、发现人、状态、问题所属模块等，为软件修改提供准备文档。13、软件修改报告 软件产品投入使用后,发现了需修改、更正的问题,要将出现的问题、修改意见、修改可能出现影响作出详细描述,提交审批。 二、可行性分析报告的撰写要求 可行性研究报告的编写内容要求如下： 1引言
(完整版)计算机软件产品交付准则
计算机软件产品交付准则 计算机软件的交付阶段是继计算机软件的需求、设计、编码、测试等阶段之后的一个核对用户需求、检验软件产品、面向客户实施应用的阶段（本阶段后期的工作主旨在于：通过对计算机软件产品客户方安装、应用及维护，收集计算机软件产品运行期出现的问题，及时反馈用户的使用信息，并转化为计算机软件产品的升级换代的重要性材料）。 具体过程如下： 1、对计算机软件项目进行交付前的最终评审。这部分工作主要包括： a) 核对软件项目开发周期各阶段形成文档的完整性。这些阶段性文档包括： i. 需求阶段：《需求规格说明书》、《项目开发计划》、《可行性研究报告》、《产品设计说明书》、《产品发布计划》、《用户手册》、《操作手册》。 ii. 设计阶段：《概要设计说明书》、《数据字典》、《详细设计说明书》、《数据库设计说明书》、《测试计划》、《质量保证计划》、《质量配置方案》。 iii. 编码阶段：《测试报告》。 iv. 测试阶段：《测试报告》。 b) 评审阶段性文档的真实性、有效性。各阶段文档应当反映出所处阶段的工作特点，待完成的工作指标和工作任务，符合软件生命周期各阶段的具体工作要求。 2、对计算机软件项目进行交付阶段的最终评审。这部分工作主要包括： a) 评审最终产品是否符合需求阶段《需求规格说明书》对用户需求的定义。严格检查计算机软件在完成功能的形式上是否符合《需求规格说明书》中对计算机软件功能内容的阐述。对于需求变更的部分，是否形成了变更部分的实时性说明书，并在《产品设计说明书》、《产品发布计划》、《用户手册》和《操作手册》有所体现。对用户操作平台进行标准化评审，从设计标准、设计风格、操作风格等方面重点进行考核。并检查是否在《产品设计说明书》、《产品发布计划》、《用户手册》和《操作手册》中有所体现。 b) 评审最终产品在逻辑设计上是否完全覆盖了用户的需求。完全检查《概要设计说明书》、《数据字典》、《详细设计说明书》和《数据库说明书》中对各个功能模块的定义是否符合用户需求，各技术说明书之间是否严格按照阶段性划分对模块进行定义，彼此之间是否存在着功能调用上的联系；检查各模块所用到的系统级参数的传递定义是否完全符合用户对需求的要求。对于新功能的增加部分，要严格同《产品设计说明书》、《产品发布计划》、《用户手册》和《操作手册》进行比较，从模块定义、接口设计、数据及数据库定义等方面检查是否同以上文档的阐述内容相吻合。 c) 评审最终产品在软件的测试上是否完全覆盖了用户的操作需求。核对单元测试记录报告，检查模块测试接口覆盖率、错误测试覆盖率、代码覆盖率。核对集成测试记录报告，验收测试记录报告，并检查测试范围是否覆盖了用户的全部需求；对于增加部分的功能测试，要核对是否与技术文档（《概要设计说明书》、《数据字典》、《详细设计说明书》和《数据库说明书》）和非技术文档（《产品设计说明书》、《产品发布计划》、《用户手册》和《操作手册》）相应部分的说明吻合。 d) 安排、评审最终产品后期维护的准备工作。