我总结的一些软件开发规范

第一篇：我总结的一些软件开发规范

我总结的一些软件开发规范

作者：田进恩

为了提高软件开发质量，降低开发周期，增强代码的可重用性和易读性，使软件便于维护，开发人员间便于交流和协作，特总结出开发规范，以为参考。

一． 原则：

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)

以上仅是我总结的一些，比较少，希望能抛砖引玉，请大家补充

第二篇：软件开发文档规范（定稿）

附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

二、做软件开发我觉得要明白：.....................................................................................................2

三、在开发中遇到问题应该怎么去解决？......................................................................................2

四、怎么样才能提高自身的能力？..................................................................................................2

五、怎么样才能做好软件开发？.....................................................................................................2

六、文档的重要性.............................................................................................................................3

七、我的收获.....................................................................................................................................3

八、网盘项目开发的最大体会.........................................................................................................4

九、软件测试（单体测试和连接测试）..........................................................................................4

常熟理工学院SIG小组

3/28/2013

一、软件开发个人体会：

1.软件领域中的知识在于积累。

2.做软件开发，就类似算数学题和世界杯足球赛一样：重在结果，而不在乎过程。3.软件服务于人类，软件是在解决一些生活中的问题和错误，问题决定解决方案。

二、做软件开发我觉得要明白：

1.职业的乐趣：

(A)用自己的智慧去创建新事物的快乐(B)开发对别人有用的东西(C)不断学习来充实自己 2.职业的苦恼:(A)总是追求完美

(B)所有要实现的功能由他人而定

(C)概念设计计是有趣的，但找Bug总是很苦恼的

三、在开发中遇到问题应该怎么去解决？

1.2.3.4.不明白就多问，不要自已一直去琢磨。

一个问题如果30分钟还没有解决就应该考虑是不是问问别人。一个问题在没有用过3种以上的方法解决过就不要去问别人。解决问题思路是关键：

相信问题总归有解决的办法，就算连技术上都没法实现的问题，相信通过良好的沟通终究也会有解决的方法。

5.解决问题的前提是：理解别人的意思，理解别人的需求，多沟通，及时给客户反馈信息。

四、怎么样才能提高自身的能力？

1.程序员怎么样进步最快？ － 理论结合实践

2.不要怕出错，不怕遇到错误，有错误就有挑战，这样才可以进步，但不要让同一个石头把你绊倒2次。

五、怎么样才能做好软件开发？

1.首先要明白解决的问题是什么，理解问题，其次再决定怎么解决这个问题 2.碰到很复杂的问题，我们就简单想，把问题简单化，细化到能够实现为止

常熟理工学院SIG小组

3/28/2013

3.出了问题，我们要先分析问题，然后知道引起问题的原因，最后并想出问题的解决办法 4.我们应该从2个方面去把握一个项目：从业务角度和项目的关键问题上去把握一个项目

(A)从不同的系统场景

(B)从不同的用户角色（充当什么角色）(C)从不同的系统使用角度（拥有那些权限）

5.其实我觉得开发人员说实在应该要比使用系统的人更了解系统需求，只有真正彻底的了解了项目的业务需求，我们才能做真的做好这个项目

六、文档的重要性

记得我当初刚开发项目的时候都是写个大致的需求说明书，做一个E-R图，画几个大致的数据流程图，然后建立数据字典和表结构关系。再接着搭建一个开发环境，配置几台服务器，划分一下模块，分工，我们就可以Coding了，一直到项目结束了，也没有完整的设计文档，更没有完整的测试文档，虽然这样的确是很快的完成了Coding工作，感觉上好像节省了好多成本和开发时间，但后期的维护和Bug 就是经常出现的事。

小项目没有文档关系不大，但如果遇到一个大项目的时候，那这样的开发方式就很有问题很危险的。

大项目没有文档： 首先维护就很麻烦，也很乱，写的代码，过几天都不知道它是完成什么功能的了，其次系统的稳定性和可靠性也让人怀疑，扩展性就不用说了。

七、我的收获

A.程序员大多都不喜欢写文档,我们以前也是特讨厌,记得以前都是系统开发完了，为了应付项目验收，就匆匆忙忙的一组人在那里补文档。在我们的思想里,所谓的文档就是一些废话,一句话硬是用十句话来代替的无聊透顶。B.代码风格要规范

以前做项目，我们都是不怎么去注意代码风格和写代码的规范，都是稍微想一下就直接开始写代码了。注释也很少用，总感觉我们自己写的代码，我们怎么会不知道它做了些什么事呢 ？总觉得我们自己写的代码我们怎么会不知道它是用来做什么的呢。一直都不相信这是个事实，但事实上，项目验收后，系统刚开始使用的人少，也就不会出现潜在的错误，随着时间的增加，久而久之，当大量用户并发访问的时候，系统的Bug 就暴漏出来了，那时你再用熟悉的Eclipse打开整个项目的源码时，再去看自己写的代码的时候，真的发现，我们定义的这个变量名是什么意思啊 ？ 我们的这个Flag 是用来判断什么的啊 ？我们的if（）中条件不知道是判断什么？ Function（）也忘记是什么功能了？ 想想好可怕啊。难道真的都忘记了吗 ？回答是肯定的： 真的忘了。C.心得体会: 通过做该网盘项目，在这2年的锻炼中，我们才真的体会到，良好的文档是正规研发流程中非常重要的环节,一个好的程序是先写好设计文档再进行编程的，在设计文档的指导下，才能写出安全的代码。如果你不写文档，一开始就写程序，这样你就不会按已设计好的路线走，而是想到哪写到哪。小功能还好说，要是大功能，就容易混乱.常熟理工学院SIG小组

3/28/2013

刚开始我们还很不习惯这一系列的编程风格，很多的规范，尤其是命名，方法和注释，都有这着很多限制，让我们觉得真罗唆，写个程序完成功能不就可以了吗，明明1小时做完的事情非得让人用3、4个小时去做，我们现在真的明白这样做的好处了，我们已经习惯这样的编程风格了，这也养成了我们的一个编程习惯了，深有体会啊。

最忙的时候就是我们成长和收获最多的时候。

八、网盘项目开发的最大体会

我们觉得项目开发的开始时候，应该由项目负责人很好的对项目是什么项目，具体大概做什么事情，是谁提出来的，目的是解决什么问题，以及里面用到的很多专有名词做个细致的说明，而不是从一开始就分几本式样书，给个静态Html 的Demo看看，然后搭建好开发环境就按照式样设计书来开发。

九、软件测试（单体测试和连接测试）

我们首先认为，编写程序的时候不要想出了问题再解决，而是要想如何不会出现问题，要根据经验来预测可能出现的问题，然后避免出现。

测试，说的直接点就是给软件找错误。

很多人认为发现错误是软件测试的唯一目的,查找不出错误的测试就是没有价值的测试,实际上我们不这么认为。

我们觉得对开发人员来说，我们要把测试出来的Bug都应该做个分析，知道错的原因之后，我们就应该在下个项目中防止类似的错误发生，而真正来提高我们开发的效率。

常熟理工学院SIG小组

3/28/2013