软件开发作业流程标准规范.doc

软件开发流程规范V1.0德联软件有限责任企业编制人： 侯秀美 审核人： 年 8 月 19 日目录目录0一、概述2二、开发步骤规范32.1 系统软硬件开发环境32.2 系统架构（系统组成）52.3 系统功效模块设计62.4 系统功效开发步骤图62.5 开发修改统计7三、开发代码规范83.1 文件结构83.1.1 文件信息申明83.1.2 头文件结构103.1.3 定义文件结构113.1.4 头文件作用123.1.5 目录结构133.2 命名规则133.2.1 共性标准133.2.2 Windows变量命名规则143.3 程序风格163.3.1 空行173.3.2 代码行183.3.3 代码行内空格193.3.4 对齐203.3.5 长行拆分223.3.6 修饰符位置233.3.7 注释233.4 函数设计263.4.1 参数规则263.4.2 返回值规则273.4.3 函数内部实现规则303.4.4 其它提议323.4.5 使用断言323.4.6 引用和指针比较333.5 变量类型定义35四、软件测试规范364.1 单元测试364.2 系统测试374.6 业务测试384.7 验收测试384.8 用户现场测试38五、软件版本管理394.1版本管理必需性39一、概述本文制订烟台开发区德联软件有限责任企业计算机软件开发规范文档。本规范目标是使企业软件开发项目阶段清楚、要求明确、任务具体、编写代码规范，使之规范化、系统化和工程化，向企业内从事软件开发工程师和管理人员提出一系列规范和要求，从而有利于开发过程控制和管理，提升所开发软件系统质量，缩短开发时间，降低开发和维护费用，以确保项目高质量、顺利进行。本规范包含：开发步骤规范和开发代码规范等，开发步骤规范需要技术开发人员编写相关内容，期望每个技术人员形成习惯，如有新内容更新会立即通知大家，如有好规范要求也可通知编制人员立即更新。本规范为烟台开发区德联软件有限责任企业内部材料，严禁其它商业应用。二、开发步骤规范接收开发任务，具体阅读软件技术规范或技术文档，如对技术文档有疑义或不清楚地方立即和项目总工或用户沟通，依据文档和沟通内容编写项目开发计划，必需包含但不限于系统软硬件开发环境、系统架构、系统功效模块设计、系统功效开发步骤图、开发修改统计。2.1 系统软硬件开发环境开发环境搭建，最好形成文档，便于以后一样工作使用。开发人员要明确系统开发拟采取数据库、操作系统、开发语言、开发工具、服务器等（具体到版本）。明确整个系统开发工作步骤，最少应该包含以下步骤。2.2 系统架构（系统组成）确定系统整体体系架构，各层次之间数据流连接，确定软件服务器硬件配置及用户硬件资源配置， 确定和用户软件平台统一协调。 开发人员在绘制架构图时给出基础框架，能反应出基础意义即可，能够直接用文字替换例子中图片。图1 系统逻辑架构图举例图2 物理架构图举例2.3 系统功效模块设计给出系统关键功效模块，每个模块所包含功效。图3 图书管理系统模块计划图举例2.4 系统功效开发步骤图给出系统关键功效业务步骤图。图4 系统功效业务步骤图举例2.5 开发修改统计1. 开发代码做好备份（能够在完成一个重大功效以后，或按时间周期性进行备份），以免因为不可抗力造成代码不可修复。2.在每次重大修改以后要做好统计（改动具体细节），修改前版本要立即备份，能够方面随时还原系统。修改日期修改内容是否备份备注三、开发代码规范在研究项目团体协作开发情况下（这里团体协作也适合于应用项目标开发），编程时应该强调一个关键方面是程序易读性，在确保软件速度等性能指标能满足用户需求情况下，能让其它程序员轻易读懂你所编写程序。若研究项目小组全部开发人员全部遵照统一、鲜明一套编程风格，能够让协作者、后继者和自己一目了然，在很短时间内看清楚程序结构，了解设计思绪，大大提升代码可读性、可重用性、程序健壮性、可移植性、可维护性。制订本编程规范目标是为了提升软件开发效率及所开发软件可维护性，提升软件质量。本规范由程序风格、命名规范、注释规范、程序健壮性、可移植性、错误处理和软件模块化规范等部分组成。此规范以C/C+程序设计讨论。3.1 文件结构每个C+/C程序通常分为两个文件。一个文件用于保留程序申明（declaration），称为头文件。另一个文件用于保留程序实现（implementation），称为定义（definition）文件。C+/C程序头文件以“.h”为后缀，C程序定义文件以“.c”为后缀，C+程序定义文件通常以“.cpp”为后缀（也有部分系统以“.cc”或“.cxx”为后缀）。3.1.1 文件信息申明文件信息申明在头文件和定义文件开头（参见示例3-1），关键内容有：（1） 版权信息；（2） 文件名称，项目代码，摘要，参考文件；（3） 目前版本号，作者/修改者，完成日期；（4） 版本历史信息；（5） 关键函数描述。/ Copyright (c) , DeLianSoftCompany YanTai/ All rights reserved./ Filename ：filename.h/ Project Code ：The project code about this file/ Abstract ：Describe the content of this file summarily/ Reference ：./ Version ：1.1/ Author ：the name of author(mender)/ Accomplished date ： September 2, / Replaced version : 1.0 / Original Author : the name of original author(mender)/ Accomplished date : September 10, / Main functions ：/Function 1 Return code Function name(Parameter Explain)/Function 2 Return code Function name(Parameter Explain)/./Function n Return code Function name(Parameter Explain)/示例3-1 文件信息申明 【规则3.1-1】文件信息申明以两行斜杠开始，以两行斜杠结束，每一行全部以两个斜杠开始； 【规则3.1-2】文件信息申明包含五个部分，各部分之间以一空行间隔； 【规则3.1-3】在关键函数部分描述了文件所包含关键函数申明信息，假如是头文件，这一部分是能够省略。3.1.2 头文件结构头文件由三部分内容组成： (1) 头文件开头处文件信息申明(参见示例3-1)；(2) 预处理块；(3) 函数和类结构申明等。假设头文件名称为 filesystem.h，头文件结构参见示例3-2。 【规则3.2-1】为了预防头文件被反复引用，应该用ifndef/define/endif结构产生预处理块；“#ifndef”或“#define”后以TAB键替换SPACE键做空格；假如头文件名称是由多个单词组成，则各单词间以下划线“_”连接，比如有头文件名称为“filesystem.h”，则定义以下：“#ifndef_FILE_SYSTEM_H_”； 【规则3.2-2】用 #include 格式来引用标准库头文件(编译器将从标准库目录开始搜索)； 【规则3.2-3】用 #include “filename.h” 格式来引用非标准库头文件(编译器将从用户工作目录开始搜索)； 【提议3.2-1】头文件中只存放“申明”而不存放“定义”； 【提议3.2-1】头文件中应包含全部定义文件所定义函数申明，假如一个头文件对应多个定义文件，则不一样定义文件内实现函数要分开申明，并作注释以解释所申明函数隶属于那一个定义文件； 【提议3.2-3】宏定义和函数申明分离，在两个头文件中定义，假如没有类组员函数，能够将类和结构定义和函数申明分离，也就是说一个头文件专用于宏定义，一个头文件专用于类和结构定义，一个头文件专用于函数申明； 【提议3.2-4】在C+ 语法中，类组员函数能够在申明同时被定义，而且自动成为内联函数。这即使会带来书写上方便，但却造成了风格不一致，弊大于利。提议将组员函数定义和申明分开，不管该函数体有多么小。头文件结构以下：/文件信息申明见示例3-1，此处省略。#ifndef_FILE_SYSTEM_H_/avoid referencing the file filesystem.h repeat#define_FILE_SYSTEM_H_#include /reference standard head file#include “myheader.h” /reference non-standard head filevoid Function1();/global function declareclass CBox /class structure decalre;#endif示例3-2 C+/C头文件结构3.1.3 定义文件结构定义文件有三部分内容：(1) 定义文件开头处文件信息申明(参见示例3-1)；(2) 对部分头文件引用；(3) 程序实现体（包含数据和代码）。假设定义文件名称为 filesystem.c，定义文件结构参见示例3-3。/文件信息申明见示例3-1，此处省略。#include “filesystem.h”/reference a head file/global function realizationvoid Function1()/class member function realizationvoid CBox:Draw()示例3-3 C+/C定义文件结构3.1.4 头文件作用早期编程语言如Basic、Fortran没有头文件概念，C+/C语言初学者即使会用使用头文件，但常常不明其理。这里对头文件作用略作解释：（1） 经过头文件来调用库功效。在很多场所，源代码不便（或不准）向用户公布，只要向用户提供头文件和二进制库即可。用户只需要根据头文件中接口申明来调用库功效，而无须关心接口怎么实现。编译器会从库中提取对应代码；（2） 头文件能加强类型安全检验。假如某个接口被实现或被使用时，其方法和头文件中申明不一致，编译器就会指犯错误，这一简单规则能大大减轻程序员调试、改错负担。3.1.5 目录结构假如一个软件头文件数目比较多（如超出十个），通常应将头文件和定义文件分别保留于不一样目录，方便于维护。比如可将头文件保留于include目录，将定义文件保留于source目录（能够是多级目录）。假如一些头文件是私有，它不会被用户程序直接引用，则没有必需公开其“申明”。为了加强信息隐藏，这些私有头文件能够和定义文件存放于同一个目录。3.2 命名规则比较著名命名规则当推“匈牙利” 命名法，该命名规则关键思想是“在变量和函数名中加入前缀以促进大家对程序了解”。比如全部字符变量均以ch为前缀，若是指针变量则追加前缀p。假如一个变量由ppch开头，则表明它是指向字符指针指针。“匈牙利”法最大缺点是烦琐，比如int i, j, k; float x, y, z;倘若采取“匈牙利”命名规则，则应该写成int iI, iJ, ik; / 前缀 i表示int类型float fX, fY, fZ; / 前缀 f表示float类型如此烦琐程序会让绝大多数程序员无法忍受。总说来，没有一个命名规则能够让全部程序员赞同，且命名规则对软件产品而言并不是“成败悠关”事，而且在不一样平台和不一样环境下编写程序所应遵照规则也不尽相同，所以我们只是追求制订一个令大多数项目组员满意命名规则，并在项目中落实实施。3.2.1 共性标准本节叙述共性规则是被大多数程序员采纳，我们应该在遵照这些共性规则前提下，再扩充特定规则，如3.2.2节 【规则3.2.1-1】标识符应该直观且能够拼读，可望文知意，无须进行“解码”； 【规则3.2.1-2】标识符长度应该符合“min-length & max-information”标准； 【规则3.2.1-3】命名规则尽可能和所采取操作系统或开发工具风格保持一致； 【规则3.2.1-4】程序中不要出现仅靠大小写区分相同标识符。 【规则3.2.1-5】程序中不要出现标识符完全相同局部变量和全局变量，尽管二者作用域不一样而不会发生语法错误，但会使人误解； 【规则3.2.1-6】变量名字应该使用“名词”或“形容词名词”； 【规则3.2.1-7】全局函数名字应该使用“动词”或“动词名词”(动宾词组)； 【规则3.2.1-8】用正确反义词组命名含有互斥意义变量或相反动作函数等； 【提议3.2.1-9】尽可能避免名字中出现数字编号，如Value1,Value2等，除非逻辑上确实需要编号；注：3.2.1 标识符最好采取英文单词或其组合，便于记忆和阅读，切忌使用汉语拼音来命名，程序中英文单词通常不要太复杂，用词应该正确，比如不要把CurrentValue写成NowValue；3.2.2 标示符长度应该以最小长度实现最多信息，通常来说，长名字能愈加好地表示含义，但并非长变量名就一定要比短变量名要好，另外单字符名字也是有用，常见如i,j,k,m,n,x,y,z等，它们通常可用作函数内局部变量；3.2.3 不一样操作系统程序设计风格是不一样，比如Windows应用程序标识符通常采取“大小写”混排方法，如AddChild，而Unix应用程序标识符通常采取“小写加下划线”方法，如add_child，别把这两类风格混在一起使用；3.2.2 Windows变量命名规则 【规则3.2.2-1】变量命名规则要求采取“匈牙利法则”，即开头字母用变量类型，其它部分用变量英文意思或其英文意思缩写，尽可能避免采取汉字拼音，要求单词第一个字母大写；即：变量名变量类型变量英文意思(或缩写)变量类型请参见附表1变量类型表； 【规则3.2.2-2】类名和函数名用大写字母开头单词组合而成；对struct、union、class变量命名要求定义类型用大写，结构采取S开头，联合体采取U开头，类采取C开头；比如：struct SPointintm_nX;intm_nY;union URecordLenBYTEm_byRecordNum;BYTEm_byRecordLen;class CNode/类组员变量或组员函数; 【规则3.2.2-3】指针变量命名基础标准为：一重指针变量基础标准为：变量名 “p”变量类型前缀命名对多重指针变量基础标准为：二重指针：变量名“pp”变量类型前缀命名三重指针：变量名“ppp”变量类型前缀命名.比如一个short*型变量应该表示为pnStart； 【规则3.2.2-4】全局变量用g_开头；比如一个全局长型变量定义为g_lFileNum，即：变量名g_变量类型变量英文意思(或缩写)； 【规则3.2.2-5】静态变量采取s_开头；比如一个静态指针变量定义为s_plPrevInst，即：变量名s_变量类型变量英文意思(或缩写)； 【规则3.2.2-6】类组员变量采取m_开头；比如一个长型组员变量定义为m_lCount，即：变量名m_变量类型变量英文意思(或缩写)； 【规则3.2.2-7】对const变量要求在变量命名规则前加入c_(若作为函数输入参数，能够不加)，即：变量名c_变量命名规则，比如：const char* c_szFileName； 【规则3.2.2-8】对枚举类型(enum)中变量，要求用枚举变量或其缩写做前缀，且用下划线隔离变量名，全部枚举类型全部要用大写，比如：enumEMDAYSEMDAYS_MONDAY;EMDAYS_TUESDAY;.； 【规则3.2.2-9】对常量(包含错误编码)命名，要求常量名用大写，常量名用英文意思表示其意思，用下划线分割单词，比如：#defineCM_7816_OK0x9000； 【规则3.2.2-10】为了预防某一软件库中部分标识符和其它软件库中冲突，能够为多种标识符加上能反应软件性质前缀。比如三维图形标准OpenGL全部库函数均以gl开头，全部常量（或宏定义）均以GL开头。3.3 程序风格程序风格即使不会影响程序功效，但会影响程序可读性，追求清楚、美观，是程序风格关键组成原因。3.3.1 空行空行起着分隔程序段落作用。空行得体（不过多也不过少）将使程序布局愈加清楚。空行不会浪费内存，即使打印含有空行程序是会多消耗部分纸张，不过值得。 【规则3.3.1-1】在每个类申明以后、每个函数定义结束以后全部要加空行。参见示例3.3.1(a)； 【规则3.3.1-2】在一个函数体内，逻揖上亲密相关语句之间不加空行，其它地方应加空行分隔。参见示例3.3.1(b)；/ blank linevoid Function1() / blank linevoid Function2() / blank linevoid Function3() / blank linewhile (condition)statement1;/ blank lineif (condition) statement2;elsestatement3;/ blank linestatement4; 示例3.3.1(a) 函数之间空行 示例3.3.1(b) 函数内部空行3.3.2 代码行 【规则3.3.2-1】一行代码只做一件事情，如只定义一个变量，或只写一条语句,这么代码轻易阅读，而且方便于写注释； 【规则3.3.2-2】if、for、while、do等语句自占一行，实施语句不得紧跟其后，不管实施语句有多少全部要加，这么能够预防书写失误； 【规则3.3.2-3】if、for、while、do等语句“”要单独占用一行； 【提议3.3.2-1】全部函数内变量全部在函数开始处定义； 【提议3.3.2-2】尽可能在定义变量同时初始化该变量(就近标准)，假如变量引用处和其定义处相隔比较远，变量初始化很轻易被忘记。假如引用了未被初始化变量，可能会造成程序错误，本提议能够降低隐患。示例3.3.2(a)为风格良好代码行，示例3.3.2(b)为风格不良代码行。int nWidth;/ widthint nHeight;/ heightint nDepth;/ depthint nWidth,nHight,nDepth;/width,height,depthx = a + b;y = c + d;z = e + f;X a + b; y = c + d; z = e + f;if (nWidth nHight) DoSomething();if (nWidth =”、“=”、“+”、“*”、“%”、“&”、“|”、“”这类操作符前后不加空格； 【提议3.3.3-1】对于表示式比较长for语句和if语句，为了紧凑起见能够合适地去掉部分空格，如for (i=0; i10; i+)和if (a=b) & (c= ) / favorable styleif(year=) / ill styleif (a=b) & (c=b&c=d) / ill stylefor (i=0; i10; i+) / favorable stylefor(i=0;i10;i+) / ill stylefor (i = 0; I 10; i +) / favorable stylex = a b ? a : b; / favorable stylex=aFunction(); / Do not use b - Function();示例3.3.3 代码行内空格3.3.4 对齐 【规则3.3.4-1】程序分界符和应独占一行而且在同一列，同时和引用它们语句左对齐； 【规则3.3.4-2】 之内代码块在右边数格处左对齐； 【规则3.3.4.3】代码对齐采取TAB键而不采取空格键对齐，通常TAB键设置为向后空4个空格。示例3.3.4(a)为风格良好对齐，示例3.3.4(b)为风格不良对齐。void Function(int x) / program codevoid Function(int x) / program codeif (condition) / program codeelse / program codeif (condition) / program codeelse / program codefor (initialization; condition; update) / program codefor (initialization; condition; update) / program codeWhile (condition) / program codewhile (condition) / program code假如出现嵌套，则使用缩进对齐，如： 示例3.3.4(a) 风格良好对齐 示例3.3.4(b) 风格不良对齐3.3.5 长行拆分 【规则3.3.5-1】代码行最大长度宜控制在70至80个字符以内； 【规则3.3.5-2】长表示式要在低优先级操作符处拆分成新行，操作符放在新行之首（方便突出操作符），拆分出新行要进行合适缩进，使排版整齐，语句可读。if (very_longer_variable1 = very_longer_variable12)& (very_longer_variable3 = very_longer_variable14)& (very_longer_variable5 = very_longer_variable16) DoSomething();virtual CMatrix CMultiplyMatrix (CMatrix leftMatrix, CMatrix rightMatrix);for (very_longer_initialization; very_longer_condition; very_longer_update)DoSomething();示例3.3.5 长行拆分3.3.6 修饰符位置修饰符 * 和 应该靠近数据类型还是该靠近变量名，是个有争议活题，若将修饰符 * 靠近数据类型，比如：int* x; 从语义上讲此写法比较直观，即x是int 类型指针，上述写法弊端是轻易引发误解，比如：int* x, y; 此处y轻易被误解为指针变量。即使将x和y分行定义能够避免误解，但并不是人人全部愿意这么做。 【规则3.3.6-1】应该将修饰符 * 和 紧靠变量名；3.3.7 注释C语言注释符为“/*/”。C+语言中，程序块注释常采取“/*/”，行注释通常采取“/”。注释通常见于：（1）版本、版权申明；（2）函数接口说明；（3）关键代码行或段落提醒。即使注释有利于了解代码，但注意不可过多地使用注释。参见示例3.3.7。 【规则3.3.7-1】注释是对代码“提醒”，而不是文档，程序中注释不可喧宾夺主，注释太多了会让人眼花缭乱，注释花样要少； 【规则3.3.7-2】假如代码原来就是清楚，则无须加注释；比如 i+; / i 加 1，多出注释 【规则3.3.7-3】边写代码边注释，修改代码同时修改对应注释，以确保注释和代码一致性，不再有用注释要删除； 【规则3.3.7-4】注释应该正确、易懂，预防注释有二义性，错误注释不仅无益反而有害； 【规则3.3.7-5】尽可能避免在注释中使用缩写，尤其是不常见缩写； 【规则3.3.7-6】注释位置应和被描述代码相邻，能够放在代码上方或右方，不可放在下方； 【规则3.3.7-8】现代码比较长，尤其是有多重嵌套时，应该在部分段落结束处加注释，便于阅读； 【提议3.3.7-9】对于多行代码注释，尽可能不采取“/*.*/”，而采取多行“/”注释，这么即使麻烦，不过在做屏蔽调试时不用查找配正确“/*.*/”。/ Function capacity：/ Parameter declare：/ Return value ：/void Function(float x, float y, float z) if () while () / end of while / end of if示例3.3.7 程序注释3.7.1 文件头注释文件头注释请参见3.1，文件头注释是以两行斜杠开始，以两行斜杠结束(以区分于函数注释)。3.7.2 函数头注释通常说来每个函数全部应该做具体注释，函数头注释是以一行斜杠开始，以一行斜杠结束，注释内容包含“功效”，“参数”，“返回值”，“设计思想”，“调用函数”，“日期”，“修改统计”等多个方面，函数头注释格式以下：/ Function capacity ：Describe the function capacity/ Parameter declare ：/ parameter 1： Describe the function of parameter ( input/output parameter )/ parameter 2： Describe the function of parameter ( input/output parameter )/./ Return value ： Describe the possible return value/ Designed idea ： Describe designed idea about the function/ Author ：/ Creation date ： Creation date(YY-MM-DD)/ Transferred function：List the sub-function in the function/ Modification record：/ (一)Mender 1：Modified date：modified content/