第一篇：软件开发文档规范（定稿）
附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）详细设计说明书；（5）用户操作手册；（6）测试计划；（7）测试分析报告（8）本报告引用的其他资料、采用的开发标准或开发规范。）
二．开发结果
1． 产品（可包括：（1）列出各部分的程序名称、源程序行数（包括注释行）或目标程序字节数及程序总计数量、存储形式；产品文档名称等。）2． 主要功能及性能
3． 所用工时（按人员的不同层次分别计时。）4． 所用机时
5． 进度（给出计划进度与实际进度的对比。）
三．评价
1．生产率评价（如平均每人每周源程序行数、文档的字数等。）2．技术方案评价 3．产品质量评价
四．经验与教训
需求规格说明书
（Requirements Specification）
一．引言
1． 编写目的（阐明编写需求说明书的目的,指明读者对象。）
2． 项目背景（可包括：（1）项目的委托单位,开发单位和主管部门；（2）该软件系统与其他系统的关系。）
3． 定义（列出文档中用到的专门术语定义和缩写词的原文。）
4． 参考资料（可包括：（1）项目开发计划；（2）文档所引用的资料，标准和规范。列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源。）
二．任务概述
1．目标 2．运行环境 3．条件与限制
三．数据描述
1． 静态数据
2． 动态数据（包括输入数据和输出数据。）3． 数据库描述（给出使用数据库的名称和类型。）
4． 数据词典 5． 数据采集
四．功能需求
1．功能划分 2．功能描述
五．性能需求
1．数据精确度
2．时间特性（如响应时间、更新处理时间、数据转化与传输时间、运行时间等。）3．适应性（在操作方式运行环境与其他软件的接口以及开发计划等发生变化时，应具有的适应能力。）
六．运行需求
1．用户界面（如屏幕格式、报表格式、菜单格式、输入输出时间等。）2．硬件接口 3．软件接口 4．故障处理
七．其他需求（如可使用性、安全保密、可维护性、可移植性等。）
概要设计说明书
（Architectural Design Specification）
一．引言
1．编写目的（阐明编写概要设计说明书的目的，指明读者对象。）
2．项目背景（可包括：（1）项目的委托单位,开发单位和主管部门；（2）该软件系统与其他系统的关系。）
3．定义（列出文档中用到的专门术语定义和缩写词的原意。）
4．参考资料（列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源，可包括：（1）项目开发计划；（2）需求规格说明书；（3）测试计划（初稿）；（4）用户操作手册（初稿）；（5）文档所引用的资料、采用的标准或规范。）
二．任务概述
1．目标
2．运行环境 3．需求概述 4．条件与限制
三．总体设计
1．处理流程
2．总体结构和模块外部设计
3．功能分配（表明各项功能与程序结构的关系。）
四．接口设计
1．外部接口（包括用户界面软件接口与硬件接口。）2．内部接口（模块之间的接口。）
五．数据结构设计
1． 逻辑结构设计 2． 物理结构设计 3． 数据结构与程序的关系
六．运行设计
1．运行模块的组合 2．运行控制 3．运行时间
七．出错处理设计
1．出错输出信息
2．出错处理对策（如设置后备、性能降级、恢复及再启动等。）
八．安全保密设计
九．维护设计（说明为方便维护工作的设施,如维护模块等。）
详细设计说明书
（Procedural Design Specification）
一．引言
1． 编写目的（阐明编写详细设计说明书的目的,指明读者对象。）2． 项目背景（应包括项目的来源和主管部门等。）
3． 定义（列出文档中用到的专门术语定义和缩写词的原意。）
4． 参考资料（列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源，可包括：（1）项目开发计划；（2）需求规格说明书；（3）概要设计说明书；（4）测试计划(初稿)；（5）用户操作手册(初稿)；（5）文档所引用的其他资料、软件开发标准或规范。）
二．总体设计
1．需求概述
2．软件结构（如给出软件系统的结果图。）
三．程序描述（逐个模块给出以下的说明:：）
1．功能 2．性能 3．输入项目 4．输出项目
5．算法（模块所选用的算法。）
6．程序逻辑（详细描述模块实现的算法，可采用:：（1）标准流程图；（2）N-S图；（3）PAD；（4）判定表等描述算法的图表。）7．接口 8．存储分配 9．限制条件
10．测试要点（给出测试模块的主要测试要求。）
测试计划（Test Plan）
一、引言
1． 编写目的（阐明编写测试计划的目的,指明读者对象。）2． 项目背景（说明项目的来源委托单位及主管部门。）
3． 定义（列出测试计划中用到的专门术语定义和缩写词的原意。）
4． 参考资料（列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源，可包括：（1）项目开发计划；（2）需求规格说明书；（3）概要设计说明书；（4）详细设计说明书；（5）用户操作手册;(6)本测试计划中引用的其他资料采用的软件开发标准或规范。）
二．任务概述
1．目标
2．运行环境 3．需求概述 4．条件与限制
三．计划
1．测试方案（说明确定测试方法和选取测试用例的原则。）
2．测试项目（列出组装测试和确认测试中每一项测试的内容、名称、目的和进度。）3．测试准备
4．测试机构及人员（测试机构名称负责人和职责。）
四．测试项目说明（按顺序逐个对测试项目做出说明：）
1．测试项目名称及测试内容 2．测试用例
（1）输入（输入的数据和输入的命令。）（2）输出（预期的输出数据。）
（3）步骤及操作
（4）允许偏差（给出实测结果与预测结果之间允许偏差的范围。）3． 进度
4． 条件（给出项测试对资源的特殊要求，如设备、软件、人员等。）5． 测试资料（说明项测试所需的资料。）
五．评价
1．范围（说明所完成的各项测试说明问题的范围及其局限性。）2．准则（说明评价测试结果的准则。）
测试分析报告（Test Specification）
一．引言
1．编写目的（阐明编写测试分析报告的目的，指明读者对象。）2．项目背景（说明项目的来源、委托单位及主管部门。）
3．定义（列出测试分析报告中用到的专门术语定义和缩写词的原意。）
4．参考资料（列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源，可包括：（1）项目开发计划；（2）需求规格说明书；（3）概要设计说明书；（4）详细设计说明
书；（5）用户操作手册；（6）测试计划；（7）测试分析报告所引用的其他资料、采用的软件工程标准或软件工程规范。）
二．测试计划执行情况
1．测试项目（列出每一测试项目的名称、内容和目的。）
2．测试机构和人员（给出测试机构名称、负责人和参与测试人员名单。）
3．测试结果（按顺序给出每一测试项目的：（1）实测结果数据（2）与预期结果数据的偏差（3）该项测试说明的事实（4）该项测试发现的问题。）
三．软件需求测试结论
按顺序给出每一项需求测试的结论。包括：（1）证实的软件能力（2）局限性（即项需求未得到充分测试的情况及原因）。
四．评价
1．软件能力（经过测试所表明的软件能力。）
2．缺陷和限制（说明测试所揭露的软件缺陷和不足,以及可能给软件运行带来的影响。）3．建议（提出为弥补上述缺陷的建议。）4．测试结论（说明能否通过。）
用户操作手册（User Guide）
一．引言
1．编写目的（阐明编写手册的目的，指明读者对象。）
2．项目背景（说明项目的来源、委托单位、开发单位及主管部门。）3．定义（列出手册中用到的专门术语定义和缩写词的原意。）
4．参考资料（列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源，可包括：（1）项目开发计划；（2）需求规格说明书；（3）概要设计说明书；（4）详细设计说明书；（5）测试计划；（6）手册中引用的其他资料、采用的软件工程标准或软件工程规范。）
二．软件概述
1．目标 2．功能 3．性能
（1）数据精确度（包括输入、输出及处理数据的精度。）（2）时间特性（如响应时间、处理时间、数据传输时间等。）
（3）灵活性（在操作方式、运行环境需做某些变更时软件的适应能力。）
三．运行环境
1．硬件（列出软件系统运行时所需的硬件最小配置，如：（1）计算机型号、主存容量；（2）外存储器、媒体、记录格式、设备型号及数量；（3）输入、输出设备；（4）数据传输设备及数据转换设备的型号及数量。）
2．支持软件（如：（1）操作系统名称及版本号；（2）语言编译系统或汇编系统的名称及版本号；（3）数据库管理系统的名称及版本号；（4）其他必要的支持软件。）
四．使用说明
1．安装和初始化（给出程序的存储形式、操作命令、反馈信息及其含义、表明安装完成的测试实例以及安装所需的软件工具等。）2．输入（给出输入数据或参数的要求。）
（1）数据背景（说明数据来源、存储媒体、出现频度、限制和质量管理等。）
（2）数据格式（如：（1）长度（2）格式基准（3）标号（4）顺序（5）分隔符（6）词汇表（7）省略和重复（8）控制。）（3）输入举例
3．输出（给出每项输出数据的说明。）
（1）数据背景（说明输出数据的去向、使用频度、存放媒体及质量管理等。）（2）数据格式（详细阐明每一输出数据的格式,如:首部主体和尾部的具体形式。）（3）举例
3．出错和恢复（给出：（1）出错信息及其含义（2）用户应采取的措施，如修改、恢复、再启动。）
4．求助查询（说明如何操作。）
五．运行说明
1． 运行表 [列出每种可能的运行情况,说明其运行目的.] 2． 运行步骤 [按顺序说明每种运行的步骤,应包括:]（1）运行控制
（2）操作信息（（1）运行目的（2）操作要求（3）启动方法（4）预计运行时间（5）操作命令格式及说明（6）其他事项。）
（3）输入/输出文件（给出建立和更新文件的有关信息，如：（1）文件的名称及编号（2）记录媒体（3）存留的目录（4）文件的支配（说明确定保留文件或废弃文件的准则，分发文件的对象，占用硬件的优先级及保密控制等。）（4）启动或恢复过程
六．非常规过程
（提供应急或非常规操作的必要信息及操作步骤，如出错处理操作、向后备系统切换操作以及维护人员须知的操作和注意事项。）
七．操作命令一览表
（按字母顺序逐个列出全部操作命令的格式功能及参数说明。）
八．程序文件（或命令文件）和数据文件一览表（按文件名字母顺序或按功能与模块分类顺序逐个列出文件名称、标识符及说明。）
九．用户操作举例
第二篇：软件开发管理规范
软件开发过程管理规范
济南明湖建筑节能技术开发有限公司 软件开发过程管理规范
一、总则.................................................................................................................................1 1.软件开发项目管理的目的.........................................................................................1 2.软件开发项目管理规范适用对象.............................................................................1 3.软件项目开发组织管理.............................................................................................1
二、软件项目立项阶段.........................................................................................................1
三、软件项目实施阶段.........................................................................................................2
四、项目需求分析过程.........................................................................................................2
五、项目系统设计过程.........................................................................................................3
六、项目开发编码过程.........................................................................................................3
七、测试提交过程.................................................................................................................4
八、项目验收总结阶段.........................................................................................................4
软件开发过程管理规范
一、总则
1.软件开发项目管理的目的
为保障按时、保质、保量完成预期交付的任务，让整个组织能清楚了解项目实施的目的、影响、进度，做到项目组所有成员都理解项目实施的原因、意义及客户的要求。通过制度化管理来合理组织安排项目组成员的工作职责和角色转换。2.软件开发项目管理规范适用对象
为了达到软件开发项目管理的根本目的，要求公司全体员工必须严格按照本规范执行，同时要求公司业务人员引导合作单位和客户接受并适应公司本《软件项目开发管理规范》。3.软件项目开发组织管理
根据软件开发的标准流程，结合公司的实际情况对软件项目分三个主要阶段进行组织管理，分别为项目立项阶段、项目实施阶段和项目验收总结阶段。
二、软件项目立项阶段
1.成立公司项目评估委员会负责公司的项目立项审批。
2.公司项目评估委员会由公司总经理或指定负责人召集，成员为公司管理层人员、商务负责人、市场负责人、技术总监、技术研发经理、财务负责人组成。
3.公司业务部门按照公司发展要求或外部需求形成《软件项目需求说明书》，确定项目需求管理人或项目申请人。
4.项目申请人填写《软件项目立项申请书》向项目评估委员会提出项目立项申请，主要说明项目的背景、目的、效益、成本、需求等方面，并由技术部门提供支持和技术说明。5.项目评估委员会收到《项目立项申请书》后三个工作日内，召开评估会议。给出评估结果。如果批准立项交公司技术总监组织开发。如果不批准，给出理由后项目中止。中止后的项目可根据情况重新申请。
6.评估结果必须包括：建议项目启动日期，期望项目完成日期，项目等级系数，项目优先级（高中低），资源冲突程度(1~9)。对于资源冲突程度大于5的项目技术总监有权拒绝
软件开发过程管理规范
接受。
三、软件项目实施阶段
1.公司批准立项的项目交由公司技术总监组织实施。
2.技术总监根据资源情况和项目需求组织相关技术人员进行初步需求讨论会，确定项目的等级系数（如分大、中、小对应3、2、1）、指定项目开发负责人。在立项后五个工作日内技术总监和项目开发负责人共同制定《软件项目开发计划》，确定项目启动日并提交项目评估委员会做反馈确认。如果项目评估委员会二位成员以上对计划有异议，项目评估委员会应该召开项目计划协调会，协调《软件项目开发计划》的修改和通过。如果无异议授权技术总监按照《软件项目开发计划》执行。
3.项目启动日后，项目开发负责人根据《软件项目开发计划》的进度每周进行一次分析汇报，形成《项目分析周报》确定项目的状态、分析风险和对策，交技术总监管控。4.《软件项目开发计划》必须按照软件项目实施过程分解为需求分析、系统设计、开发编码和测试提交几个控制过程。
四、项目需求分析过程
1.项目需求分析团队由技术总监负责，组成人员包括技术研发经理、项目开发负责人、部分高级软件开发工程师和需求提供人。
2.需求分析第一次会议将在《软件项目开发计划》通过后，在项目启动日2个工作日内召开，提出需求的不足之处交需求提供人完善。
3.分析团队分工完成提交《软件项目需求功能列表》及《项目关键业务流程》文挡。4.需求分析应该在需求分析第一次会议后的开始，并在（3个工作日*项目等级系数）日内完成。
5.需求分析过程完成后，如果需求变更提供人必须书面提出《项目需求变更通知书》，项目需求分析团队在2个工作日内完成分析反馈，确定项目变更系数；项目负责人变更对应《软件项目开发计划》版本。
6.需求分析阶段完成的标志为技术总监召开文挡审查和阶段总结会，时间为1个工作日。
软件开发过程管理规范
五、项目系统设计过程
1.项目设计团队由技术总监负责，组成人员包括技术研发经理、项目开发负责人、部分高级软件开发工程师。
2.项目分析设计团队在收到需求阶段文档后2个工作日内召开设计工作启动协调会，审查反馈需求阶段文档。
3.协调会明确分工、按计划完成《项目系统接口说明》、《项目系统数据设计文档》和《主要操作界面说明》文档。
4.项目设计应该在启动协调会后开始，并在（5个工作日*项目等级系数）日内完成。5.项目负责人接到《项目需求变更通知书》后，按照1个工作日*项目变更系数调整对应设计和计划。
6.项目设计阶段完成的标志为技术总监召开设计文挡审查和阶段总结会，时间为1个工作日。
六、项目开发编码过程
1.项目开发编码团队由技术研发经理负责，组成人员包括项目开发负责人和软件开发工程师。
2.项目开发编码团队在收到需求和设计阶段文档后2个工作日内召开编码工作启动协调会，学习理解并反馈需求和设计阶段文档。
3.技术研发经理按照项目《软件项目开发计划》中开发编码过程的细分阶段进行控制。
4.项目开发负责人需负责项目联调测试，保证《项目关键业务流程》和《主要操作界面说明》文档的实现。
5.技术研发经理要组织项目开发编码团队对（项目等级系数）关键代码进行集中解读，保证编码的质量和规范。
6.根据项目的情况，要求开发编码人员对《项目系统接口说明》中接口进行性能测试，并产生接口测试报告。
7.技术研发经理负责做好开发编码的版本管理工作。
8.开发编码应该在编码工作启动协调会后开始，并在（10个工作日*项目等级系数）内完成。
软件开发过程管理规范
9.开发编码阶段完成的标志为测试人员接受测试版本后，技术研发经理召开提交和阶段总结会，开发人员的所有代码转交给项目负责人管理。时间为1个工作日。
七、测试提交过程
1.项目测试团队由技术研发经理、项目负责人和测试工程师组成。
2.测试工程师首先检查开发编码团队《项目关键业务流程》、《主要操作界面说明》和《项目系统接口说明》的测试结果。如果通过才接受，否则将退回。
3.测试工程师在开发编码阶段的同时应该编制好《项目软件使用说明书》，接受测试版本后按照《项目软件使用说明书》进行测试。
4.测试工程师重新测试一次《项目关键业务流程》、《主要操作界面说明》和《项目系统接口说明》。
5.测试工程师完成对应版本的《项目测试报告》，发现的问题交项目负责人负责组织开发人员修改完善。
6.测试工程师提交完成版本的《项目测试报告》后，由技术研发经理确认并签字。将对应版本定义为发布版本。
7.测试工作应该在接受测试版本后进行，并在（5个工作日*项目等级系数）内完成。
八、项目验收总结阶段
1.发布版本后，项目负责人打印收集好所有项目过程文挡，并有对应责任人签字。
2.项目负责人回顾总结《软件项目开发计划》，分析总结实际和计划差异，形成《项目计划执行情况报告》。
3.技术研发经理总结项目设计、开发、测试过程的质量控制和开发人员开发效率情况，总结经验教训并提出项目开发改进措施。
4.技术总监总结分析成本控制、对全部项目人员进行考核，形成《项目总结报告》。并完善本规范流程。
5.上述工作完成后，提交项目评估委员会总结会审批后公布。
第三篇：山东08规范软件开发计划
山东08规范软件开发计划
本软件是从江苏提速版本基础之上根据现有山东地区软件进行调整。
软件需要更改的地方我初步填写了《需求表》，请各位针对自己的工作重点，结合相应的软件进行分析和代码设计，并给出时间计划表
1)软件基本信息修改及报表更改。
本部分工作由葛亮完成（吴耀武辅助）。具体内容包括：
软件基本信息的调整：比如显示上的江苏更改为山东。以及模板的调整
山东报表的打印。
2)计价程序以及管理费和利润设置。
本部分工作由陆向荣完成。具体内容包括计价程序相关变量的设置调整和管理费利润费率按山东需求进行调整。
3)其他项目，规费，税金项目等界面调整和修改。
本部分工作有张志浩完成。主要将湖南的相关界面及操作等东西搬过来。同时指导招投标接口的更改工作。
4)招投标接口的更改，采用原有山东的招投标接口。
本部分工作有强浩完成。主要任务是将江苏地区的招投标接口更改为山东接口。另山东现有一个接口规范（试行）及莱芜有一个接口文件，请一并考虑在内。相关文档见《山东省建设工程造价计价软件数据接口标准（试行）》和《莱芜市建设工程计价数据交换规范》。
以上为现有的初步分工，请各位参考自己已有工作量进行计划，回复我计划时间和具体工作内容。对分工任务不明确的请和我联系，以便调整。
第四篇：我总结的一些软件开发规范
我总结的一些软件开发规范
作者：田进恩
为了提高软件开发质量，降低开发周期，增强代码的可重用性和易读性，使软件便于维护，开发人员间便于交流和协作，特总结出开发规范，以为参考。
一． 原则：
1． 软件工程化 2． 模块化
3． 能简单不复杂 4． 强调团队协作 5． 强调创新和特色
二． 具体规范：
1． 命名规范
命名应尽量使用匈牙利命名法，变量名或函数名中使用大写字符来区分各个部分，以便于记忆和阅读。如bPatchMinute, DeleteDirInfo()。全局(包括类中的)变量用长名字，局部变量用短名字。
类成员变量前一般应加上m_，全局变量加上g_，仅与本模块有关的变量加上l_,紧接着是变量的类型。整型： n,i 长整型: l 无符号整型： u 无符号长整型：dw 字符： ch 布尔量： b 浮点数: f 双精度浮点: d 字符串： str,lpsz,sz,p,lp,ac, 指针： p 字节指针： pb 无符号指针： pv 字符指针： lpsz 整型指针： lpn 文件指针： fp 如：
m_nTotalNum,m_strPath,m_bRcving,m_fPrice,g_lOpenDate,g_dwCardNo,lpszNameStr, lpnSysDoomType,uMsgID,m_pProgress
局部变量应尽量易懂简洁，使用常见的变量，如
Num,nCount,i,j,k,n,len,pos, offset,nReadNum,index,nRet,ret, string,filename
临时变量，如ltmp,ftmp,tmpStr,tempStr，函数命名也应该见名知意。如CalcAllDataStyle(),ReadDocDataFromTime(),GetIndexInfo()常见的函数
Init, OpenAll, Create_, Get_, Set_, Read_, Load_, Write_, Start_, Stop_, Check_, Test_, Fill_, Process_, Sort_, Do_, Select_, Is_, Exist_,_Ex。
宏命名和typedef定义类型应详细，避免重复，一律为大写，如
#define DEL_EMPTY(a){if(a){delete a;a=NULL;}} #define SUCCESS 0 #define FAIL-1
typedef struct { char lpzSource[100];char lpzTitle[100];char lpzURL[194];short nType;long npos;long nlen;}ATTBODY,*LPATTBODY;（指针前加LP）
自定义消息从WM_USER开始
#define MYAPP_MESSAGE WM_USER+0x1001
2． 代码规范
有些不易理解的变量或函数应作注释，难懂的代码要有注解，在文件的开始处有该文件的用途描述。一定要保持注释的一致性。
代码组织要清晰，{,},(,),if,else,do,while,for,case等要对应整齐，少用空格，缩进全部用Tab键。变量的定义要集中，函数间要有空行分开，一个程序中的空行数目最好占8%-16%。多态函数和功能相近的函数集中放在一起。
代码应该简洁、清楚并讲述了所发生的一切，我们的目标应该是写出最清晰的代码，而不是最巧妙的代码。例如如果是MFC多文档程序，就要严格按照其生成的框架写代码。尽量使用编译器已经提供的函数，不必花时间另行编写。例如系统已经有qsort函数，可直接拿来排序用。
某些公用代码要注意多平台易移植，最好使用标准C。
代码的重用要仔细，要将相关的代码也拷贝过来，注意那段代码也许不适合你的应用场合。删掉从来没有用过的函数或变量，大篇幅注释掉的代码行也应删除，以免使程序混乱难读。
3． 工程文件组织规范
一个工程往往包含很多很多文件（*.h,*.cpp,*.inc,*.lib,资源文件等），向工程中加入文件或删除工程中的文件要慎重，避免把工程损坏。工程中不起作用的文件或类应删除，工程目录下的非工程文件也应该移走，保持工程的清洁，避免混淆难于管理。工程文件如果很多，应归类。
在VC环境下，建议将常用的头文件全部放入stdafx.h中，而在每个cpp开始处嵌入stdafx.h。避免头文件的交叉引用，如果有严重的交叉引用，适当使用类的声明。
将独立性比较强的模块抽出来，做成DLL，控件或COM组件，该模块可单独编写和测试，也增强了其可重用性。
一个比较大的工程应留有一定的消息接口或插件接口等。
工程的版本控制要严格，版本格式为xx.xx.xx，必要时使用Build次数或日期。高版本尽量兼容低版本的用法、数据或协议。
工程的编译宏定义和工程参数设置应正确，每作一个新工程时应检查工程参数是否正确。建议字节对齐方式为1字节对齐。
工程文件应经常备份，备份时注明备份日期和主要增加的功能。
4． 类组织规范
类一般有两个文件，一个头文件，一个实现体CPP。
类力求封装好，严格区分public,private,protect等作用域，如果一个函数与本类有莫大的关系，可以作为该类的静态成员函数，不用或少用友元函数等破坏类封装性的方法和技巧。如果一些结构或宏仅与本类有关，可在类头文件中定义。
类的成员变量在构造函数或初始化函数中应赋初值。指针在构造函数中赋NULL,析构时DEL_EMPTY它，以免内存泄露。
5． 用户界面规范
有四大类型的用户界面：对话框、单文档界面、多文档界面、其它界面
对话框要易用且简洁，字体和控件的组织搭配要得体，能简单不复杂，各控件的焦点、Tab顺序等要讲究，视应用场合要适当支持键盘。在简洁易用的前提下，力求个性化，设计得更加友好。程序各对话框的风格要保持一致。
单文档和多文档界面的程序功能可以做得很强，也便于扩充和管理。其中菜单、工具栏、状态栏等设计要有特色。菜单按一定的分类弹出，必要时设计成多套菜单，在重要的窗口或区域应能弹出右键，实现常见操作。工具栏上放最常用的操作按钮，必要时动态更换按钮。状态栏显示足够多的有用信息。
消息主控在Mainframe中，单文档的主控也可在View中，所有的对话框的弹出或非模态对话框的控制都在主控窗口中完成，具体的数据处理放在单独的文件中或设计成类。在App类中实现Ini读写，各数据对象的定义和析构，全局变量的赋值和初始计算，存盘退出等。各视图的OnDraw和GDI画图尽量使用内存位图的方式，以免闪烁。
其它还有ATL，控制台，嵌入式程序界面等，也有作为其它容器如IE中的插件等，此类程序可能不用MFC，而采用COM组件等方法实现。
6． 疑难解答和Bug调试方法
勤问、善于问。在不打扰正常工作的前提下，开发人员间应相互帮助，聚思广益，也许你的问题或Bug就是他人的前车之鉴。
从各种途径请求解答。专业书、教材、期刊、电子文档以及国际标准文献、RFC等，Internet上专业网站、论坛、专家组等。
Bug的出现总是有一定的原因的，冷静查找，不要总是拘泥于某一个小局部，换一个想法、从另外一个角度也许让你柳暗花明。使用一些辅助开发或调试工具，如Spy++,Process Viewer,系统监视器等。
拓宽知识面。多参阅其它编程语言、数据库知识、编译原理、网络协议等，熟悉硬件设备、底层汇编、数字逻辑电路等。使用和揣摩其它软件功能和界面，集百家之长，做出有创新意义和有特色的功能性软件。
三． 一些习惯：
我认为比较好的习惯：
1.if(0 == GetDataType(…))比if(GetDataType(…)== 0)好，纵使误将==写成=，在编译一层就会报错。2.#define MAX_DOWNLOADNUM 20 struct DownInfo m_DownInfo[MAX_DOWNLOADNUM];在代码中尽量不用具体的大小数值，定义成宏，便于以后维护。3.CUSTXG_CONTABLE g_lpCustCon[] = { {“数值串1”,C_ZGB,C_CUSTJBM,C_VT_FBJ,“万”}, {“数值串2”,C_ZSZ,C_CUSTJBM,C_VT_FBJ,“万”}, …
{“数值比例”,C_WTB,C_CUSTHQ,C_VT_FBJ,“%”} };int g_nCustNum = sizeof(g_lpCustCon)/sizeof(CUSTXG_CONTABLE);g_ nCustNum自动适应g_lpCustCon的大小。4.函数定义short GetInputType(const char * lpzInput)比short GetInputType(char * lpzInput)好，以免lpzInput在函数体中被破坏。5.协议包头定义成：
typedef struct tagDataHeader { struct{ unsigned char Version:4;unsigned char HeaderFlag:2;unsigned char Reserved:2;//保留Bits位 }Info;long nOther;long Reserved;//保留4个字节 } DATAHEADER;定义有一定的保留字段，供以后扩充使用。6.变量在定义时赋初值，类析构时或程序退出时判断释放所有变量。7.编码空间一定要充分预留，编码时注意可扩充性。
我认为不好的习惯：
1.代码中是“+2”,“+4”,而不是“+sizeof(short)”,“+sizeof(int)”。2.filename[40],而不是filename[MAX_PATH]。
3.GDI资源使用完后不释放，位图、笔刷等用完后不Select出来。这样会将导致系统Gdi资源丢失或内存泄露。
4.大量使用无符号型变量。无符号变量在判断时易造成错误，甚至死循环，尽量少用。5.使用malloc,free不使用new,delete,大量使用realloc。new,delete是规范的C++语法，通用性强，realloc易造成内存抖动。6.#define square(x)(x)*(x)宏的体应加括号，否则容易出问题，如1/square(x)将被替换1/(x)*(x)
以上仅是我总结的一些，比较少，希望能抛砖引玉，请大家补充
第五篇：供电公司软件开发与测试验收管理规范
某某供电公司软件开发与测试验收管理规范
第一条 为提高某某供电公司计算机应用软件的开发与测试验收管理水平，符合国网公司“SG186”软件系统的质量体系，特制定本规范。
第二条 本规范适用于公司内部开发的应用软件，也适用于采购定制开发的应用软件，提供定制开发应用软件的开发商必须遵循本规范执行。
第三条 本规范的应用软件研制开发过程采用生命周期法，分为五个阶段进行：
1． 分析阶段 2． 设计阶段 3． 编码调试阶段
4． 工程实施（部署）、测试验收阶段 5． 培训、试运行阶段
第四条 每个阶段都有确定的任务，并产生相应的文档。后一阶段应在前一阶段提供文档的基础上，继续开展工作。每一阶段结束时，必须对产生的文档，进行仔细复审，发现错误，及时纠正。由于理解能力的限制，以及需求情况、环境条件的变化，反复进行修改，是不可避免的，应不厌其烦地，直至修改完善，保证正常运行使用。力戒凑合。
第五条 应用软件研制开发过程中会出现七个角色：组织机构的设置可根据
第 1页 , 共 9 页 开发平台、开发人员、项目规模等因素有所变化，开发人员也可以随着项目的连续性和项目的进展赋予不同的职责。
1． 项目经理：在一个或多个应用领域内使用整合了道德、法律和经济问题的工程方法来设计合适的解决方案。懂得确定客户需求并将其转换成软件需求的过程。履行项目经理的职责，善于处理技术和管理方面的事务。懂得并使用有用的项目管理工具。调谐互相冲突的目标，在成本、时间、知识、现有系统以及组织的限制下找出可接受的折衷办法。在一个典型的软件开发环境中谈判、有效地工作、在必要时进行领导，并与有关负责人（包含外方）进行良好沟通。从最初创建建议书一直到项目签收结束都应用国际标准。2． 系统分析员：协助项目经理工作。系统分析员是用户和开发者之间的桥梁，负责与用户一起进行需求分析，并对软件需求进行规格化说明。
3． 系统设计员：系统设计员负责设计软件的开发策略，配置软件开发环境，进行数据结构设计和业务系统设计。
4． 程序设计员：负责程序的编写、调试，以实现系统设计员做出的软件设计。
5． 系统测试员：负责程序和业务系统两方面的测试。
6． 文档管理员：负责管理整个系统开发过程中产生的各种文档。7． 用户：应用软件的接受和使用者。
第六条 分析阶段
第 2页 , 共 9 页 1． 分析阶段任务：在项目经理的带领下进行业务需求调研。系统分析员与用户一起充分讨论业务需求、安全保密等要求；对有关业务活动，进行详细分析，切实弄清在满足业务需求的条件下，软件系统应该做什么，并进行可行性论证。
2． 本阶段的文档是《业务需求说明书》、《技术方案设计书》、《草图设计》、《项目开发计划》和《项目约定书》。
3． 《业务需求说明书》由项目经理和系统分析员编写。a)阐述业务范围和内容。
b)分析现行系统的业务概况，系统的不足和用户对新系统的要求。
4． 《技术方案设计书》由项目经理和系统分析员编写。a)由开发组负责制定最优技术设计方案
b)业务流程图：对原系统的描述，为数据流程图提供依据 c)数据流程图：系统说明书中的主要文件，按自顶向下的原则分层进行，先把整个系统当作一个功能，画出最粗略的流程图，然后逐步向下分解，直到所需要的详尽程度。d)数据字典：对数据流程图中的细节，进行描述说明。e)新系统的逻辑模型；提出为达到系统目标，对原系统应作那些修改，系统的人机界面，出错处理，系统的启动和结束，系统输入输出格式，系统性能等。
5． 《草图设计》由项目经理和系统分析员编写。简化和图示化技术方案设计书，让用户直接了解思路。
第 3页 , 共 9 页 6． 《项目开发计划》由项目经理根据项目任务、人员配置和进度制定。
7． 《业务需求说明书》、《技术方案设计书》、《草图设计》和《项目开发计划》在业务部门确认这四个文档满足他们的要求后，提交软件开发部门领导审批，然后由项目经理与业务部门签订《项目约定书》，作为业务部门和软件开发部门之间密切合作的最终文件。（外购软件参照执行）8． 在《项目约定书》中必须包括：
a)开发和实施过程中的人生、信息、设备的安全条款。b)提供明确数量的技术培训和服务（质量）的承诺。
第七条 设计阶段
1． 设计阶段的任务：在设计阶段中，项目经理和系统分析员应根据《技术方案设计书》提出的逻辑模型，精心设计系统实施方案，编写《业务流程总体设计书》尽可能提高系统的安全性、可靠性、可变性、容错性、工作质量和工作效率。2． 本阶段工作是“业务流程总体设计”、“业务流程详细设计”、《项目开发管理规范书》和《任务分配文档》。3． “业务流程总体设计”由项目经理和系统分析员完成 a)“业务流程总体设计”是项目经理和系统分析员根据《业务需求说明书》和《技术方案设计书》的要求，运用结构化程序设计思想，将软件自上而下逐层分解成多个软件模块，直
第 4页 , 共 9 页 到分解成每一个模块只具有单一的功能，能用一个或几个程序实现的树形结构为止。总体设计还要定义各模块的数据传递关系，设计软件的编码方案、文件存储策略、输入输出格式，以及硬件和系统软件配置，最后编制《概要设计说明书》。b)业务流程总体设计的内容主要包括：
(1)代码设计(2)文件设计(3)输入设计(4)输出设计
(5)系统软硬件配置设计(6)设计说明书
4． “业务流程详细设计”由项目经理和系统分析员完成 a)“业务流程详细设计”是对“业务流程总体设计”中划分的每个模块再进行详细定义和说明。它包括定义每一模块的详细功能、输入数据、使用文件及使用方式，确定输出内容及格式，模块实现的详细算法，每一模块的程序构成等，其中包括对数据库关系和流程的设计。“业务流程详细设计”是软件功能、结构实现方法的最详细说明，是程序设计的依据。“业务流程详细设计”的最终成果是编制《详细设计说明书》。
5． 《项目开发管理规范书》：由项目经理和系统分析员编写。对开发人员在变量、代码、编码、数据文件格式、注释等方面
第 5页 , 共 9 页 作出约定的技术性规范书。
6． 《任务分配文档》由项目经理编写，根据《概要设计说明书》、《详细设计说明书》和《项目开发计划》分配人员和任务。
第八条 编写、调试阶段
1． 主要任务是由程序人员在系统分析员的带领下，根据《任务分配文档》分配的各自的模块说明书写出程序《开发文档》，并以此编写逻辑正确、易于阅读和理解的程序。
a)《开发文档》应该包括：程序框图、源程序清单、程序说明书、逻辑正确的程序模块。
2． 高级程序员将程序员开发的模块按《概要设计说明书》、《详细设计说明书》集成系统。
3． 在本阶段中，模块级测试可以由程序员自己或相互测试，也可以由测试员参与模块级测试。
4． 在本阶段中，对开发服务器上集成后的系统进行测试，可以由高级程序员到测试员共同参与进行测试，测试结果由程序员对代码进行消缺，同时编写《集成测试说明书》。5． 在经过系统集成测试后，可以向用户展示系统，项目经理和系统分析员要听取用户的意见，如果用户对业务有所变更，项目经理和系统分析员对此进行分析，对于确实需要变更的业务，由项目经理及时提出《问题说明报告》，让用户和领导审批，审批通过后，系统分析员立即编写《业务变更文档》，第 6页 , 共 9 页 同步记录开发过程中用户提出的业务需求变更的情况，以便及时让组员了解。
6． 在向用户展示系统通过后，系统进入现场安装部署阶段。
第九条 工程实施（部署）、测试验收阶段
1． 在现场部署阶段，首先准备运行服务器。同时，由系统分析员根据《业务需求说明书》、《概要设计说明书》、《详细设计说明书》，编写《项目测试方案与报告》的初稿，《项目测试方案与报告》包括测试案例，以验证系统的功能与性能。2． 成立由项目经理、系统分析员、程序员、测试员和用户在内的测试小组进行现场码测试。
a)现场码测试过程是按照《项目测试方案与报告》的初稿的测试案例，逐条进行。现场代码测试是一个反复的过程，如果没有通过测试，要进行消缺，再全面测试，直到测试通过为止。
b)现场代码测试完成后的系统要移植到最终运行环境（部署），将实际数据采集及导入。
3． 成立由项目经理、系统分析员、测试员和用户在内的测试小组进行现场验收测试。
a)对实际运行系统进行现场验收测试。测试过程是按照《项目测试方案与报告》的初稿的测试案例，逐条进行。b)现场验收测试完成后，测试小组要对被测试系统是否达到
第 7页 , 共 9 页 《项目测试方案与报告》的要求，提出意见，完善《项目测试方案与报告》报告，提交领导审批。
4． 在进行系统测试的同时，系统分析员、程序员积极编写《项目开发文档》汇总整个项目的使用的技术、思路、过程。5． 在工程实施（部署）、测试验收阶段，系统分析员和高级程序员还要积极编写《用户使用手册》，在系统代码测试完成后，向用户进行培训。
6． 现场验收测试通过的系统交用户试运行一段时间（一般要求３～６个月），以进一步发现问题，予以修改、完善。经用户试运行，满意认可后，由用户提出《用户报告》，项目经理则编写《项目验收报告》。
第十条 验收、运行维护阶段
1． 软件验收组应由用户、开发人员和专家三方组成。验收组要对《项目验收报告》、《项目测试方案与报告》、《用户报告》等资料是否完整进行认真审查并作出评价；
2． 在软件系统通过验收，并交付用户正式使用后，用户应对软件系统的资产进行分类统计，编制资产清单，标注资产的重要性，并对资产清单定期维护和更新；
3． 要对软件系统的日常维护工作作出安排。可以委托软件开发人员日常维护。要建立软件系统的《日常维护档案》资料归
第 8页 , 共 9 页 档，作为今后日常维护的依据。在可能的条件下，也可对业务人员作进一步培训，逐步做到由业务部门自行维护。
**供电公司
2009年2月
第 9页 , 共 9 页
点击咨询 