海豹平台开发规范v1.0
腾讯科技（深圳）有限公司
*版本信息&保密等级
版本更改日期更改要点说明编制审核批准
V1.0 2014/12/24 新建wilsonwsong
V1.1 2014/12/26 修订rusherding
文档保密等级：□机密■内部□公开
目录
海豹平台开发规范V1.0 (1)
1 引言 (5)
1.1定义及缩略语 (5)
1.2参考文档 (5)
1.3目的 (5)
1.4适用范围 (5)
1.5标准化作用 (5)
2 目录结构规范 (6)
2.1框架路径 (6)
2.2应用目录结构 (6)
2.2.1 配置config (7)
2.2.2 控制器controllers (7)
2.2.3 模型models (7)
2.2.4 视图views (8)
2.2.5 国际化messages (8)
2.2.6 组件components (8)
2.2.7 命令commands (8)
2.2.8 临时目录runtime (8)
2.3路径别名 (8)
2.3.1 类型导入 (8)
3 PHP编码规范 (9)
3.1标签 (9)
3.2编码 (9)
3.3注释 (9)
3.3.1 文件注释 (9)
3.3.2 类注释 (10)
3.3.3 方法注释 (10)
3.3.4 属性注释 (11)
3.3.5 其它 (11)
3.4命名规则 (11)
3.4.1 文件 (11)
3.4.2 类 (11)
3.4.3 函数/方法 (12)
3.4.4 变量名 (12)
3.4.5 常量名 (12)
3.5书写规则 (13)
3.5.1 文件 (13)
3.5.2 行 (13)
3.5.3 缩进 (13)
3.5.4 控制结构 (13)
3.5.5 运算符 (16)
3.5.6 引号 (16)
3.5.7 关键词 (17)
3.5.8 函数 (17)
3.5.9 类 (17)
3.5.10 属性 (18)
3.5.11 方法 (18)
4 数据库命名规范 (20)
4.1命名规范 (20)
4.2实体命名 (20)
4.2.1 前缀命名 (20)
4.2.2 后缀命名 (21)
4.3字段命名 (21)
4.3.1 后缀命名 (22)
4.4字段类型 (22)
4.4.1 数值类型 (22)
4.4.2 字符类型 (23)
4.4.3 时间类型 (23)
4.4.4 ENUM&SET (23)
4.4.5 LOB 类型 (23)
4.5表结构设计 (24)
4.5.1 适度冗余 (24)
4.5.2 尽量使用NOT NULL (24)
4.5.3 索引 (24)
5 附件 (24)
5.1附录一：MYSQL保留字 (24)
1引言
1.1定义及缩略语
缩略词说明
海豹平台运维中心提供的研发平台，提供框架、公共基础组件、公共业务组件加速业
务的日常研发工作
1.2参考文档
海豹平台WIKI：https://www.doczj.com/doc/1a9472814.html,/
1.3目的
本规范由编程原则组成，融合并提炼了开发人员长时间积累下来的成熟经验，意在帮助形成良好一致的编程风格。以达到事半功倍的效果，如果有需要本文档会不定期更新。
1.4适用范围
如无特殊说明，以下规则要求完全适用于基于海豹平台框架开发的应用，同时也可大部分适用于部门其他PHP项目。
1.5标准化作用
当一个软件项目尝试着遵守公共一致的标准时，可以使参与项目的开发人员更容易了解项目中的代码、弄清程序的状况。使新的参与者可以很快的适应环境，防止部分参与者出于节省时间的需要，自创一套风格并养成终生的习惯，导致其它人在阅读时浪费过多的时间和
精力。而且在一致的环境下，也可以减少编码出错的机会。
缺陷是由于每个人的标准不同，所以需要一段时间来适应和改变自己的编码风格，暂时性的降底了工作效率。从使项目长远健康的发展以及后期更高的团队工作效率来考虑暂时的工作效率降低是值得的，也是必须要经过的一个过程。标准不是项目成功的关键，但可以帮助我们在团队协作中有更高的效率并且更加顺利的完成既定的任务。
1)程序员可以了解任何代码，弄清程序的状况
2)新人可以很快的适应环境
3)防止新接触PHP的开发出于节省时间的需要，自创一套风格并养成终生的习惯
4)防止新接触PHP的开发一次次的犯同样的错误
5)在一致的环境下，可以减少犯错的机会
2目录结构规范
2.1框架路径
框架引用路径必须采用绝对路径，托管的开发、测试和正式环境必须为：
/data/php/framework
2.2应用目录结构
应用需要严格参考以下目录安排代码位置：
webroot/
index.php Web 应用入口脚本文件
index-test.php 功能测试使用的入口脚本文件
assets/ 包含公开的资源文件
css/ 包含 CSS 文件
images/ 包含图片文件
themes/ 包含应用主题
protected/ 包含受保护的应用文件
modc 命令行脚本
modc.bat Windows 下的命令行脚本
modc.php 命令行 PHP 脚本
commands/ 包含自定义的 'modc' 命令
components/ 包含可重用的用户组件
config/ 包含配置文件
controllers/ 包含控制器的类文件
SiteController.php 默认控制器的类文件
extensions/ 包含第三方扩展
messages/ 包含翻译过的消息(i8n相关)
models/ 包含模型的类文件
runtime/ 包含临时生成的文件
tests/ 包含测试脚本
views/ 包含控制器的视图和布局文件
layouts/ 包含布局视图文件
main.php 所有视图的默认布局
site/ 包含 'site' 控制器的视图文件 system/ 包含系统视图文件
2.2.1配置config
存放应用配置目录，具体参考WIKI人口脚本
2.2.2控制器controllers
存放控制逻辑的类目录，具体参考WIKI控制器
2.2.3模型models
存放模型定义的类目录，具体参考WIKI模型
2.2.4视图views
存放视图文件的目录，具体目录参考WIKI视图
2.2.5国际化messages
存放国际化定义文件的目录
2.2.6组件components
存放组件的类目录，具体目录参考WIKI组件
2.2.7命令commands
存放Console命令的类目录，具体目录参考WIKI之Cli使用
2.2.8临时目录runtime
目录权限777，可用于存放临时生成的文件。
2.3路径别名
1)system: 表示平台框架目录，默认为/data/php/framework。
2)webroot: 表示入口脚本文件所在的目录，一般为应用的根目录。
3)application: 表示应用的基础目录，一般为webroot/protected。
4)ext: 表示包含了所有第三方扩展的目录，一般为webroot/protected/extensions。
通过使用Mod::getPathOfAlias(), 别名可以被翻译为其相应的路径。例如：
https://www.doczj.com/doc/1a9472814.html,ontroll er 会被翻译为/data/php/framework/core/web/CControll er。
2.3.1类型导入
使用别名可以很方便的导入类的定义，如导入webroot/protected/components/Controller Mod::import('https://www.doczj.com/doc/1a9472814.html,ponents.Controller');
同样可以使用目录导入
Mod::import('https://www.doczj.com/doc/1a9472814.html,ponents.*');
3PHP编码规范
3.1标签
PHP程序可以使用或来界定PHP 代码，在HTML页面中嵌入纯变量时，可以使用这样的形式，不可使用其他的标签变种。
纯PHP类文件，文件最后一个?>省略。
3.2编码
PHP代码必须只使用不带BOM的UTF-8。
3.3注释
1)单行注释：在语句结尾用双反斜杠”// “注释
2)多行注释：多行注视以”/*”或“/**”符号开头，以”*/ “符号作为注释结束符。
需要生成文档的注释必须是以“/**”开头，以“*/”结尾。主流的IDE开发工具（如Eclipse，Zend）会用不同的颜色来区分下面的几种注释。
3.3.1文件注释
/**
*（简述，用在索引列表中）
*
* 详细的功能描述（可略）
*
* @copyright Copyright© 2014, 公司名或作者名
* @author ${AUTHOR}
* @version $Id: ${FILE_NAME}, v ${VERSION} ${TIME} ${AUTHOR} Exp $ *
*/
3.3.2类注释
/**
*（概要）
*
* 详细的功能描述
*
* @property 类型$prop 属性描述
*
* @author ${AUTHOR}
* @package https://www.doczj.com/doc/1a9472814.html,ponents（参见路径别名）
*
*/
3.3.3方法注释
/**
* 功能描述
*
* @param 类型$fields 描述
*
* @return 类型描述
*/
3.3.4属性注释
/**
* @var 类型$fields 描述
*/
3.3.5其它
1)适当的使用HTML标记语言来美化文档。不管是生成HTML格式还是CHM格式的
文档手册，文档工具都是先生成HTML文档页面，所以适当的使用
或标签
可以美化文档，方便阅读。
2)public和private方法：一般情况下，private私有方法不会暴露给其他开发人员，
所以private方法的注释一般以“/*”开头，而public方法以“/**”开头。
3.4命名规则
Pascal命名法：所有单词第一个字母大写，其他字母小写。
Camel命名法(驼峰命名法) ：除了第一个单词，所有单词第一个字母大写，其他字母小写。采用英文单词或其组合，便于记忆和阅读，切忌使用汉语拼音来命名。
3.4.1文件
1)类文件的名称和类名一致,如类HelloWorld，相应的文件名为HelloWorld.php
2)配置文件名小写，如config.php
3)嵌套php的view文件使用Camel命名法，第一个字母小写，其他单词的第一个字
母大写。如：addApp.php
3.4.2类
类命名采用Pascal命名方法，类名应该和文件名相匹配。
3.4.3函数/方法
通常方法一般为一个动作或行为动词，函数/方法的命名采用Camel命名方法
function run()
function runFast()
function getBackground()
尽量用有意义，描述性的词语来命名
用checkForErrors()代替errorCheck()，用dumpDataToFile()代替dataFile()。
有时前缀名是有用的：
is - 含义为问一个关于某样事物的问题。无论何时，当人们看到is就会知道这是一个问题。get - 含义为取得一个数值。
set - 含义为设定一个数值
例如：isHitRetryLimit
内部成员函数命名应该是以“_”开始：
function _isUserTicket ();
3.4.4变量名
1)用有意义的，描述性的词语来命名变量
2)别用缩写。用name, address, salary等代替 nam, addr, sal 全局变量以”g_”开头
3)别使用单个字母的变量象i, n, x 等. 使用 index, temp等，用于循环迭代的变量例
外： for ($i = 0; $i < count; $i++) { ... }
3.4.5常量名
量全部使用大写字母和下滑线组成,常量的名称中不允许出现小写字母，可使用分隔符作为下划线。
3.5书写规则
3.5.1文件
1)所有的PHP文件必须使用Unix LF(换行)作为行结束符。
2)所有PHP文件必须以一个空行结束。
3)纯PHP代码的文件关闭标签?>必须省略
3.5.2行
1)行长度不可有硬限制。
2)行实际长度不应超过80个字符；较长的行应当被拆分成多个不超过80个字符的后
续行。
3)空行可以用来改善可读性和区分相关的代码块。
4)一行不应多于一个语句。
3.5.3缩进
每个缩进的单位约定是4个空格的缩进，并且不可使用制表符作为缩进，需每个参与项目的开发人员在编辑器(Eclipse、EditPlus、Zend Studio等)中进行强制设定将TAB转化为4个空格，以防在编写代码时遗忘而造成格式上的不规范。
3.5.4控制结构
对于控制结构的样式规则概括如下：
1)控制结构关键词之后必须有一个空格
2)左括号之后不可有空格
3)右括号之前不可有空格
4)在右括号和左花括号之间必须有一个空格
5)代码主体必须有一次缩进
6)右花括号必须主体的下一行
每个结构的主体必须被括在花括号里。这结构看上去更标准化，并且当加新行的时候可以减少引入错误的可能性。
3.5.
4.1if,elseif, else
一个if结构看起来应该像下面这样。注意括号，空格，花括号的位置；并且else和elseif 和前一个主体的右花括号在同一行。
if ($expr1) {
// if body
} elseif ($expr2) {
// elseif body
} else {
// else body;
}
关键词elseif应该替代else if使用以保持所有的控制关键词像一个单词。
3.5.
4.2switch, case
一个switch结构看起来应该像下面这样。注意括号，空格和花括号。case语句必须从switch处缩进，并且break关键字（或其他中止关键字）必须和case主体缩进在同级。如果一个非空的case主体往下落空则必须有一个类似// no break的注释。
switch ($expr) {
case 0:
echo 'First case, with a break';
break;
case 1:
echo 'Second case, which falls through';
// no break
case 2:
case 3:
case 4:
echo 'Third case, return instead of break';
return;
default:
echo 'Default case';
break;
}
3.5.
4.3while, do while
一个while语句看起来应该像下面这样。注意括号，空格和花括号的位置。
while ($expr) {
// structure body
}
同样的，一个do while语句看起来应该像下面这样。注意括号，空格和花括号的位置。
do {
// structure body;
} while ($expr);
3.5.
4.4for
一个for语句看起来应该像下面这样。注意括号，空格和花括号的位置。
for ($i = 0; $i < 10; $i++) {
// for body
}
3.5.
4.5foreach
一个foreach语句看起来应该像下面这样。注意括号，空格和花括号的位置。
foreach ($iterabl e as $key => $value) {
// foreach body
}
3.5.
4.6try, catch
一个try catch语句看起来应该像下面这样。注意括号，空格和花括号的位置。
try {
// try body
} catch (FirstExceptionType $e) {
// catch body
} catch (OtherExceptionType $e) {
// catch body
}
3.5.5运算符
1)每个运算符与两边参与运算的值或表达式中间要有一个空格
3.5.6引号
在绝大多数可以使用单引号的场合，禁止使用双引号（性能考虑）。可以或必须使用单引号的情况包括但不限于下述：
1) 字符串为固定值，不包含“\t”等特殊转义字符；
2) 数组的固定下标，例如$array['key'];
3)表达式中不需要带入变量，例如$string = 'test';，而非$string = "test$var";
3.5.7关键词
1)PHP keywords 必须使用小写。
2)PHP常量true, false和null必须使用小写。
3.5.8函数
3.5.9类
1)类必须单独一个源文件，并且类名和文件名相同。
2)类的左花括号必须放到下一行，右花括号必须放在类主体的下一行。
3)类文件“?>”结束标记去掉
class Foo
{
[body]
}
4)一个类的extends和implements关键词必须和类名在同一行。
class ClassName extends ParentClass implements ArrayAccess, Countabl e
{
// constants, properties, methods
}
5)implements一个列表可以被拆分为多个有一次缩进的后续行。如果这么做，列表
的第一项必须要放在下一行，并且每行必须只有一个接口。
class ClassName extends ParentClass implements
ArrayAccess,
Countable,
Serializable
{
// constants, properties, methods
}
3.5.10属性
1)所有的属性必须声明可见性。
2)var关键词不可用来声明属性。
3)一个语句不可声明多个属性。
4)属性名称可以使用单个下划线作为前缀来表明保护或私有的可见性。
class ClassName
{
public $foo = null;
private $_bar = 1;
}
3.5.11方法
1)所有的方法必须声明可见性。
2)方法名不应只使用单个下划线来表明是保护或私有的可见性。
3)方法名在声明之后不可跟随一个空格。左花括号必须放在下面自成一行，并且右花
括号必须放在方法主体的下面自成一行。左括号后面不可有空格，右括号前面不可
有空格。
4)一个方法定义看来应该像下面这样。注意括号，逗号，空格和花括号：
5)在参数列表中，逗号之前不可有空格，逗号之后必须要有一个空格。
6)方法中有默认值的参数必须放在参数列表的最后面。
class ClassName
{
public function fooBarBaz($arg1, &$arg2, $arg3 = [])
{
// method body
}
}
7)参数列表可以被分为多个有一次缩进的多个后续行。如果这么做，列表的第一项必
须放在下一行，并且每行必须只放一个参数。
8)当参数列表被分为多行，右括号和左花括号必须夹带一个空格放在一起自成一行。
class ClassName
{
public function aVeryLongMethodName(
ClassTypeHint $arg1,
&$arg2,
array $arg3 = []
) {
// method body
}
}
9)如果存在，abstract和final声明必须放在可见性声明前面。
10)如果存在，static声明必须跟着可见性声明。
4数据库命名规范
4.1命名规范
数据库的所有表(Table)、视图(View)、索引(Index)、触发器(Trigger)、函数(Function)和存储过程(Store Procedure)均应遵循以下命名规范。
1)命名统一用大写
2)命名只能由小写字母和数字构成，并且只能是以小写字母打头
3)命名应采用能够准确反映其中文含义的英文单词或英文单词缩写构成，避免出现英
文单词和汉语拼音混用的局面
4)命名长度不可以超过25个字符（表名尽量保持在20个字符的长度，然后再其上建
立索引、主键、触发器等等的时候，便于加扩展信息）
5)名称的各部分之间以"_"(下划线)连接
6)字段如有相同定义，应该用相同命名
7)命名应避免用关键字，参见附录一《关键字列表》
4.2实体命名
实体(包括库表、视图、函数和索引等)命名结构如下：
prefix[_modul e]_body[_suffix]
1)
2)
3)
为主体名，应该能够清楚地说明对象的含义4)
存放的表，为可选项。
4.2.1前缀命名
前缀数据库对象
附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 ）详细设计说明
可行性研究报告 来源：国家计算机标准和文件模板作者： 可行性研究报告的编写目的是：说明该软件开发项目的实现在技术、经济和社会条件方面的可行性；评述为了合理地达到开发目标而可能选择的各种方案；说明并论证所选定的方案。 可行性研究报告的编写内容要求如下： 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费用开支 列出由于运行现有系统所引起的费用开支，如人力、设备、空间、支持性服务、材料等项开
产品开发项目文档管 理规范 文档编号：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）文档作者保证所编写的文档与所描述的对象保持很好的一致性，必要时及时更新文档，便于以后维护工作和后续开发工作的开展。
项目开发规范文档编写人：徐文兵日期：2009-7-20 审核人：日期： 批准人：日期：
修改记录（REVISION CHART）
1 概述 目的与概述 本文档为XX公司的开发规范文档，给开发团队提供开发标准和规范。 整体说明 在开发规范中包含了两个部分，第一部分是项目开发流程规范，主要阐述在项目开发过程中的各个阶段的规范。第二部分为Coding开发规范，Coding 开发规范阐述了在一个框架中的各个层的开发规范 （注：在第一版中不包含对工作流开发的规范制定） 覆盖范围 阅读对象 1.项目管理人员 2.系统设计人员 3.系统开发人员 参考资料 略
2 项目开发流程规范 2.1 业务需求调研阶段 ●调研的目标 系统层面：客户的系统运行环境 业务层面：了解客户需要什么样的系统，具体了解业务目的，业务逻辑，业务数据，客户的操作习惯，页面风格习惯等。 ●调研的准备工作： 行业知识的准备： 了解客户的行业背景，行业领域的业务术语，含义。结合客户行业背景，了解客户的业务知识。 业务专家需求： 在行业领域的复杂度不高的情况下，业务分析人员直接收集并学习行业知识就可以了，但行业知识的准备工作还是要做的 在行业领域业务复杂度高的情况下，需要业务专家对客户的业务的进行整理。 ●调研的流程： 第一步，项目启动阶段了解客户的IT环境。 第二步，讨论并具体确定客户系统的范围，并获得客户业务功能点的原始的单据。在这个过程中准备一个本和一只笔记录讨论的业务信息第三步，整理业务信息，和原始表单，抽取出有效业务信息，并对于不明确的业务信息进行整理和归类，并制作成问卷形式进一步调研。 第四步，发放调研问卷，再次进行业务调研（直接转到三） 第五步，卷写调研问卷，并内部评审 第六步，调研问卷客户评审并确认。 ●调研阶段的交付项（可配置项） 软件需求说明书 软件需求说明书的目录： 1 客户行业背景 2 客户系统的意义 3 客户系统运行的环境 4 业务功能点描述（业务目的，业务逻辑，业务数据，优先级别，使用频率等） 5 客户的操作习惯，页面风格习惯。
项目开发规范 1.Java编程规范 1.1命名规范 定义这个规范的目的是让项目中所有的文档都看起来像一个人写的，增加可读性，减少项目组中因为换人而带来的损失。 1.Package的命名：包的名字都由一个小写字母组成。 2.Class的命名：类名必须由大写字母开头，其它字母都小写的单词组成。 3.方法的命名：方法名必须由一个小写字母开始，后面的单词用大写字母开始。 4.变量的命名：变量名必须由一个小写字母开始，后面的单词用大写字母开始。 5.Static final变量的命名：static final变量的名字应该都大写,并且指出完整含义。 6.数组的命名：数组应该以byte [] buffer的形式，而不是byte buffer[]的形式定义。 1.2Java文件样式 1.版权信息：版权信息必须在java文件的开头，比如： /** *Copyright ? 2000 Shanghai XXX Co. Ltd. *All right reserved */ 2.数据库设计规范 2.1命名规范 1.数据库文件名：使用汉语拼音或者英文单词作为文件名，一律使用小写。 2.数据库表名称：数据库表名由前缀tb加实际名字组成，实际名字英文首字母大写 3.数据库表字段名称：每个单词首字母大写。 4.sql语句规范：所有sql语句关键词如：select，update等均大写。 3.网页设计约定 3.1命名规范 1.所有控件id号均由开发人员名称首字母作为前缀。 2.js代码命名规范参考java编程规范。 4.文档书写规范 4.1需求分析书写规范 1.目的和对象：简明编写需求说明书的目的，指明读者对象； 2.项目背景描述： a.项目的委托单位、开发单位和主管部门。 b.该软件系统与其他系统的关系，描述本项目的适应场合及处理业务。 c.项目名称：本项目的名称，包括项目的全称、简称、代号、版本号。 d.名称定义：列出文档中用到的专门术语的定义和缩写词的原文，对重要的或者有 特殊意义的名词进行定义。 3.调研情况描述：描述主要的调研活动及对象。 4.用户特点： a.用户业务描述：描述适用本项目处理的业务。 b.用户情况：介绍本项目的用户情况，包括：用户的工作流程；用户的相关部门及 职责；用户的技术水平；用户原有系统的情况：介绍用户现在使用的系统的主要情况，包括主要的不足。 5.任务概述
软件开发技术文档编写规范 在项目开发过程中，应该按要求编写好十三种文档，文档编制要求具有针对性、精确性、清晰性、完整性、灵活性、可追溯性。 ◇可行性分析报告：说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由。 ◇项目开发计划：为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。 ◇软件需求说明书（软件规格说明书）：对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求，为生成和维护系统数据文件做好准备。 ◇概要设计说明书：该说明书是概要实际阶段的工作成果，它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计提供基础。 ◇详细设计说明书：着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。 ◇用户操作手册：本手册详细描述软件的功能、性能和用户界面，使用户对如何使用该软件得到具体的了解,为操作人员提供该软件各种运行情况的有关知识，特别是操作方法的具体细节。 ◇测试计划：为做好集成测试和验收测试，需为如何组织测试制订实施计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。 ◇测试分析报告：测试工作完成以后，应提交测试计划执行情况的说明，对测试结果加以分析，并提出测试的结论意见。 ◇开发进度月报：该月报系软件人员按月向管理部门提交的项目进展情况报告，报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。 ◇项目开发总结报告：软件项目开发完成以后，应与项目实施计划对照，总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力，此外，还需对开发工作做出评价，总结出经验和教训。 ◇软件维护手册：主要包括软件系统说明、程序模块说明、操作环境、支持软件的说明、维护过程的说明，便于软件的维护。 ◇软件问题报告：指出软件问题的登记情况，如日期、发现人、状态、问题所属模块等，为软件修改提供准备文档。 ◇软件修改报告：软件产品投入运行以后，发现了需对其进行修正、更改等问题，应将存在的问题、修改的考虑以及修改的影响作出详细的描述，提交审批。 1可行性分析报告 1 引言 1.1 编写目的：阐明编写可行性研究报告的目的，提出读者对象。
命名 命名规则对于维护代码来说是非常重要的,。Objective-C方法名往往很长，不过这也有好处，让很多注释变得毫无意义。 本文推荐驼峰法，也是Objective-C社区的标准。 驼峰法分小驼峰法和大驼峰法。小驼峰法：除第一个单词之外，其他单词首字母大写。大驼峰法相比小驼峰法，大驼峰法把第一个单词的首字母也大写了。 1.基本原则 1.1 清晰 又清晰又简洁是最好的了，但简洁不如清晰重要。总的讲不要使用单词的简写，除了非常常用的简写以外，尽量使用单词全称。API的名称不要有歧义，一看你的API就知道是以什么方式做了什么事情，不要让人有疑问 1.2 一致性 做某个事情代码通常都叫这个名字，比如tag、setStringValue，那么你也这么叫。你在不确定怎么起名字的时候，可以参考一些常用的名字：Method Arguments 2. 类命名 类名(不包括类别和协议名)应该用大写开头的大驼峰命名法。类名中应该包含一个或多个名词来说明这个类（或者类的对象）是做什么的。 在应用级别的代码里，尽量不要使用带前缀的类名。每个类都有相同的前缀不能提高可读性。不过如果是编写多个应用间的共享代码，前缀就是可接受并推荐的做法了(型如MBAPhotoBrowser )。 示例1： @interface ImageBrowseView :UIView @end 示例2：（带前缀MBA） @interface MBAPhotoBrowser :UIView @end
3. 类别命名 类名+标识+扩展（UIImageView +HP+Web） 例：如果我们想要创建一个基于UIImageView的类别用于网络请求图片，我们应该把类别 放到名字是UIImageView+HPWeb.h的文件里。UIImageView为要扩展的类名，HP为专属标识，Web为扩展的功能。 类别的方法应该都使用一个前缀(型如hp_myCategoryMethodOnAString ),以防止Objective- C代码在单名空间里冲突。如果代码本来就不考虑共享或在不同的地址空间(address- space)，方法命名规则就没必要恪守了。 类别HPWeb头文件，UIImageView+HPWeb.h如下： @interface UIImageView (HPWeb) - (void)hp_setImageWithURLString:(NSString *)urlStr; @end 4. 方法命名 方法使用小驼峰法命名, 一个规范的方法读起来应该像一句完整的话，读过之后便知函数 的作用。执行性的方法应该以动词开头，小写字母开头，返回性的方法应该以返回的内容 开头，但之前不要加get。 示例： - (void)replaceObjectAtIndex:(NSUInteger)index withObject:(id)anObject; (instancetype)arrayWithArray:(NSArray *)array;
项目开发规范性文档 一:作用 项目开发过程中为了增加程序的可读性和程序的健壮性，方便后期程序的调试和维护，所以需要在开发过程中统一技术规范 二:目录 1.系统框架中模块功能，文件目录和文件名的规范 2.程序代码中文件名类名变量名接口名等规范 3.代码的书写的规范 4.数据库中表名字段名数据类型等规范 三:详细内容 说明 常用的命名风格如下。 (1)Pascal风格：包含一到多个单词，每一个单词第一个字母大写，其他字母小写，其余字母均小写。例如：CollegeStudent、HelloWorld等。 (2)Camel风格：包含一到多个单词，第一个单词首字母小写，其余单词首字母大写，其他字母均小写。例如：name、gender、somePara等。 1.系统框架功能模块、文件目录和文件名的规范 (1)功能模块命名规范 数据访问层(DAL)——DataSet，与数据库打交道的唯一方式；位于最底层； 数据控制层(DCL)——直接与DataSet打交道，通过实体工厂类产生实体对象和数据访问层打交道 数据封装层(DPL)——BEAN 实体类;
业务逻辑层(BLL)——与业务有关的操作，以上三层多不与业务逻辑有关; 通用工具层(CTL)——与项目无关、可独立的类库。如DBControl,Exception等; 系统管理层(SysManeger)--系统管理常用接口比如系统日志系统版本系统信息等 数据访问接口层(IDataFactory)--数据访问层的抽象工厂接口 实体访问接口层(EntityFactory)--数据访问层的实体工厂类，即产生实体对象的实体工厂类 (2)文件目录的命名规范 images --项目图片的目录 styles --项目css文件的目录 javascript --项目中js文件的目录 template --项目模板文件的目录 subsystem --项目子系统或模块的目录(一般用因为名字来表示系统的模块) document --项目说明文档目录 database --项目数据库目录 (3)文件名的命名规范 a.文件名尽量用一个或多个英文单词来表示做到见面知意的效果比如:Index.aspx Default.aspx Product.aspx OrderList.aspx等 b.所有单词的首字母要大些 c.尽量不要使用下划线来连接多个单词 2.程序代码中的命名规范 (1)命名空间 命名空间命名采用Pascal风格，取名的一般规则如下。 CompanyName.TechnologyName 例如： Microsoft.Office MyCompany.NamingRule.Test 另外，需要用复数的时候要使用复数的名称空间名。例如，使用System.Collections 而不是System.Collection。但是，当遇到缩写形式时，通常不需要使用复数。例
项目开发规范书开发工具： Android studio +git+genymotion 项目总体架构: 模式：mvp 网络请求：okhttp+ retrofit Json解析Gson 地图：百度地图 项目包名如下: Activity: 放所有的activity Fagment: 放所有的Fagment Sharedpreferences：放SharedPreferences存取数据 ContentProvider：放内容提供者 Service:放服务 App:放应用程序application Dao :放所有数据库相关的操作 Unti:放所有的工具娄 Myview:放所有的自定义控件 Bean ：放所有的实体类 Adapter：放所有的adapter (listview ,gridview……) Biz:业务逻辑和实体模型Model放这里 Presenter :View于Model间的交互Presenter放在这里 View:对应于Activity，负责View的绘制以及与用户交互类放这里后台一些百度地图，分享等一些其它的东西再重新建包 特殊类介绍: BaseActivity：所有的activity 基类 BaseFragment :所有fragment 基类 Constants:常量类，所有的网络请求url及一些常用的常量 NetworkUtil：网络请求判断类 控件命名规范 1.控件命名规范 TextView：txt_+描述Button ：btn_+描述ImageButton：ib_+描述ImageView：img_+描述CheckBox：chk_+描述RadioButton：rb_+描述AnalogClock：ac_+描述DigitalClock：dc_+描述DatePicker：dp_+描述TimePicker：tp _+描述ToggleButton：tb_+描述EditText：edit_+描述
GB8567－88软件开发主要文档编写规范
GB8567－88软件开发主要文档编写规范
233 GB 8567－88软件开发主要文档编写规范 本附录中列出了《计算机软件产品开发文件 编制指南》GB 8567－88中主要软件文档的编写说明，供编写时参考。这些文档主要是：可行性研究报告、项目开发计划、软件需求说明书、概要设计说明书、详细设计说明书、模块开发卷宗、测试计划、测试分析报告、项目开发总结报告。 一、 可行性研究报告 l 引言 1.1 编写目的 说明：说明本可行性研究报告的编写目的，指出预期的读者。 1.2 背景 说明： a ．所建议开发的软件系统的名称。 b ．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络。 c ．该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3 定义 列出本文件中用到的专门术语的定义和 外文首字母组词的原词组。
234 1.4 参考资料 列出用得着的参考资料，如： a ．本项目的经核准的计划任务书或合同、上级机关的批文。 b ．属干本项目的其他已发表的文件。 c. 本文件中各处引用的文件、资料，包括所需用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表 日期和出版单位，说明能够得到这些文件资料的来源。 2 可行性研究的前提 说明对建议开发项目进行可行性研究的前 提，如要求、目标、条件、假定和限制等。 2.1 要求 说明对所建议开发软件的基本要求，如： a ．功能。 b ．性能。 c ．输出如报告、文件或数据，对每项输 出要说明其特征，如用途、产生频度、接口以及分发对象。 d. 输入说明。系统的输入包括数据 的来源、类型、数量、数据的组织以及提供的频
项目开发流程规范文档 1概述 目的与概述 本文档为网络公司的项目开发规范文档，给开发团队提供开发标准和规范。 整体说明 在开发规范中包含了两个部分，第一部分是项目开发流程规范，主要阐述在项目开发过程中的各个阶段的规范。第二部分为Coding开发规范，Coding开发规范阐述了在一个框架中的各个层的开发规范 （注：在第一版中不包含对工作流开发的规范制定） 阅读对象 1.项目管理人员 2.系统设计人员 3.系统开发人员 2项目开发流程规范 2.1业务需求调研阶段 l调研的目标 系统层面：客户的系统运行环境 业务层面：了解客户需要什么样的系统，具体了解业务目的，业务逻辑，业务数据，客户的操作习惯，页面风格习惯等。 l调研的准备工作： 行业知识的准备：了解客户的行业背景，行业领域的业务术语，含义。结合客户行业背景，了解客户的业务知识。 业务专家需求：在行业领域的复杂度不高的情况下，业务分析人员直接收集并学习行业知识就可以了，但行业知识的准备工作还是要做的，在行业领域业务复杂度高的情况下，需要业务专家对客户的业务的进行整理。 l调研的流程： 第一步，项目启动阶段了解客户的IT环境。 第二步，讨论并具体确定客户系统的范围，并获得客户业务功能点的原始的单据。在这个过程中准备一个本和一只笔记录讨论的业务信息。 第三步，整理业务信息，和原始表单，抽取出有效业务信息，并对于不明确的业务信息进行整理和归类，并制作成问卷形式进一步调研。
第四步，发放调研问卷，再次进行业务调研（直接转到三）。 第五步，卷写调研问卷，并内部评审。 第六步，调研问卷客户评审并确认。 l调研阶段的交付项（可配置项） 软件需求说明书 软件需求说明书的目录： 1客户行业背景 2客户系统的意义 3客户系统运行的环境 4业务功能点描述（业务目的，业务逻辑，业务数据，优先级别，使用频率等） 5客户的操作习惯，页面风格习惯。 2.2概要设计阶段 概要设计阶段主要分两个步骤：1框架设计2业务模块概要设计,下面分别对两个步骤进行描述： 2.2.1框架设计 （注：这边的框架设计是按照传统的开发方式进行阐述，基于平台的开发方式待补） l框架设计的目标： 根据客户需求，设计系统的后台架构，前台界面框架，数据模型。在设计之前要考虑客户的业务特点，性能要求，已有的IT环境，同时还要考虑将来业务的增长，保证系统一定得可扩展性。 l框架设计包含的内容： 后台框架：各层的职能划分，技术实现的方式，层之间的交互规则，异常处理规则，目录定义规则 界面框架：操作主界面定义，页面整体风格的定义，页面流转关系等 数据模型：系统基础数据（组织人员结构，权限设置，字典参数设置），业务数据l框架设计阶段交付项： 文档：系统架构 界面框架 数据模型 注：三份文档可以融合在一份文档之中。 2.2.2业务模块概要设计
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输入输出的要求 解释各输入输出的数据类型，并逐项说明其媒体、格式、数值范围、精度等。 对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报
项目开发规范文档 编写人：徐文兵日期：2009-7-20 审核人：日期： 批准人：日期：
修改记录（REVISION CHART）
1 概述 目的与概述 本文档为XX公司的开发规范文档，给开发团队提供开发标准和规范。 整体说明 在开发规范中包含了两个部分，第一部分是项目开发流程规范，主要阐述在项目开发过程中的各个阶段的规范。第二部分为Coding开发规范，Coding开发规范阐述了在一个框架中的各个层的开发规范 （注：在第一版中不包含对工作流开发的规范制定） 覆盖范围 阅读对象 1.项目管理人员 2.系统设计人员 3.系统开发人员 参考资料 略
2 项目开发流程规范 2.1 业务需求调研阶段 ●调研的目标 系统层面：客户的系统运行环境 业务层面：了解客户需要什么样的系统，具体了解业务目的，业务逻辑，业务数据，客户的操作习惯，页面风格习惯等。 ●调研的准备工作： 行业知识的准备： 了解客户的行业背景，行业领域的业务术语，含义。结合客户行业背景，了解客户的业务知识。 业务专家需求： 在行业领域的复杂度不高的情况下，业务分析人员直接收集并学习行业知识就可以了，但行业知识的准备工作还是要做的 在行业领域业务复杂度高的情况下，需要业务专家对客户的业务的进行整理。 ●调研的流程： 第一步，项目启动阶段了解客户的IT环境。 第二步，讨论并具体确定客户系统的范围，并获得客户业务功能点的原始的单据。在这个过程中准备一个本和一只笔记录讨论的业务信息 第三步，整理业务信息，和原始表单，抽取出有效业务信息，并对于不明确的业务信息进行整理和归类，并制作成问卷形式进一步调研。 第四步，发放调研问卷，再次进行业务调研（直接转到三） 第五步，卷写调研问卷，并内部评审 第六步，调研问卷客户评审并确认。 ●调研阶段的交付项（可配置项） 软件需求说明书 软件需求说明书的目录： 1 客户行业背景 2 客户系统的意义 3 客户系统运行的环境 4 业务功能点描述（业务目的，业务逻辑，业务数据，优先级别，使用频率等） 5 客户的操作习惯，页面风格习惯。 2.2 概要设计阶段 概要设计阶段主要分两个步骤： 1 框架设计 2 业务模块概要设计,下面分别对两个步骤进行描述：
软件开发过程规范 版本 <> 修订历史纪录
目录
软件开发过程规范 1.前言 1.1目的 本规范的目的是使整个软件产品开发及项目工程阶段清晰，要求明确，任务具体，便于规范化、系统化及工程化。有利于提高软件生命周期的控制及管理，提高所开发软件的质量，缩短开发时间，减少开发和维护费用，使软件开发活动更科学、更有成效。 1.2对象 本规范面向产品生命周期的所有相关人员，包括管理人员、开发人员、质管人员。 1.3要求 具有软件开发管理职能的人员要求熟知项目开发的各阶段过程和各阶段过程相应的规范。 1.4适用范围 适用于产品开发生命周期中的除产品提交外的其他全部过程；规范分为两部分：技术过程规范和管理过程规范，分别适用于软件开发过程中的技术性活动和管理性活动。 1.5软件开发过程模型 本规范所采用的软件开发过程模型为简化的RUP开发过程模型；软件开发过程是体系结构为中心，用例驱动和风险驱动相结合的过程迭代。 1.6开发过程划分 开发过程包括多次迭代，每次迭代的目标和侧重点不同；较早的迭代侧重于业务建模和需求建模；而后的迭代则侧重于分析设计和编码。 2.技术过程规范部分 2.1概述 本规范中将软件开发的整个技术过程分为四个顺序实施的阶段，分别为业务建模阶段、需求阶段、分析设计阶段和实现阶段。在对技术过程规范的描述，按阶段内部的活动和产物对四个阶段分别说明。 在本规范中对阶段内活动的说明，是按顺序性活动和持续性活动两类分别进行说明。对于顺序性活动是按该阶段中活动的总体顺序进行的描述，而在实际工作中，从各活动的具体实施的细节来看，各活动之间的顺序是不断交叉变化的。对于持续性活动主要是对贯穿该阶段过程始终的技术活动进行说明。
第一部分总纲 一﹑目的： （1）规范公司内部技术研发工作的文档管理； （2）保持技术研发工作的完整性与连续性； （3）防止技术流失，减少风险； （4）使技术文档成为技术研发工作中的重要组成部分。 二﹑适用范围：本公司内部一切与技术研发有关的部门及个人，包括 （1）总经理； （2）技术部门经理或负责人； （3）研发工程师； （4）测试工程师； （5）技术支持工程师。 三﹑目标： 通过切实可行的文档管理规范，使得研发工作透明，明确，有章可循，合作无障碍，衔接环节畅通；使得所有的研发产品从开始研发——研发进程——测试——修改——阶段性结束——产品转化——升级维护过程中的所有环节都得以在相应的文档中体现。 四﹑版本：E2003V0.10（简称V0.10）。 五﹑制定原则： （1）实用：鉴于公司目前的状况，通用性的开发模板（如国标）在很大程度上对于本公司并不实用，所以本规范将不会完全照搬此类模板，而是根据公司的具体情况制定公司内部的标准； （2）可行：可行性是该标准的起码要求，没有可行性的标准不能成为真正的“标准”； （3）高效：如果将国标中的所有规范内容都纳入本标准，一定可以达到目的，实现目标。但是，同时必将为相关人员增添大量的工作量，而且很多工作对于本公司来说是冗余，从而造成相关人员的抵触情绪，使标准难于贯彻。所以，本标准应力求在尽量少的模板中体现尽量多的内容； （4）科学：本标准的制定虽然不完全照搬其他通用性的标准，但将大量参照通用标准，特别是国标中的某些部分内容，不是抛弃国标，而是以国标为原则，以保证科学性； （5）建立在广泛意见基础上：本标准并非公司某一个人单方面的意愿，而是从公司利益出发，全体相关人员共同参与，集体的结晶。 六﹑实行过程及生效日期： （1）V0.10版的规范为规范草稿，草稿制订完成后，将在相关部门和相关人员中进行传阅和广泛征求意见。经过三次全体相关人员参与讨论和修改，由总经理审批签字后的规范版本为0.40。
软件开发项目管理 *启动阶段 这个阶段的工作目的是决定一个项目是否需要启动。为了达到这个目的，首先要明确项 目的总体战略目标，对项目的需要建立认同。即确定到底需要做什么、开发什么产品或提供 什么服务，以及需要解决什么样的问题和需要满足客户或市场的什么要求等，同时还要总结 项目工作的范围、所需资源、大约开支、各种风险，以及该项目不执行的其他替代选择等。这些代表了对整个项目目标从战略角度和宏观层次所进行的分析，通过项目的意向书总结出 来，由此确证客户或项目发起人和赞助者的要求与期望，并帮助他们判定项目是否上马。项 目意向总结书的通过及项目被批准上马形成了这个项目的起始点。 *计划阶段 这个阶段的工作是为整个项目做计划。项目开始后，首先要确定项目的具体范围，明确 定出项目到底要做什么，总结、归纳并定出产品的功能。然后进一步制定项目的计划，列出 每项具体工作，并建立所有工作任务的重要性及顺序；确定每项工作的执行人和所需资源；根据人员的配置和能力设定各项工作和整个项目的完成时间表。 *执行阶段 这个阶段的工作是通过执行项目的计划来完成项目的任务。它包括落实一切所需资源，如：人员、设备、费用、技术、信息，由管理者领导全体项目参与者开展各项工作。同时跟踪各项具体工作和整个项目的进度，定期向全体项目人员及项目的发起人报告项目状态。 *控制阶段 这个阶段的工作是确证项目工作的结果符合项目的计划。它通过对项目结果的衡量和审 核，与项目计划所期望的结果进行比较，找出实际结果与计划的差别，并制定处理措施。这 个阶段的工作还包括对项目进程中出现的任何更改要求进行审核和批准。同时调解项目进程 中出现的各种问题，女口：对缺乏的资源的补偿调节；对项目的进度表及各项具体工作的优先级或顺序的修订。 *结束阶段 这个阶段的工作是确保项目的最终结果或提交物达到计划的要求，并对完成的结果作可接受的确认。还包括在项目完成之后的收尾工作，对整个项目的经历进行总结，修订项目文档，用户培训等。
（项目名称） 开发文档 创建日期：yyyymmdd 版本号：1.0 电子科技大学通信与信息工程学院无线通信与嵌入式系统研究室
目录 目录 (2) 摘要 (4) 关键词 (4) 修订记录 (4) 缩略语 (4) 表目录 (4) 图目录 (4) 1项目需求与目标任务 (5) 1.1.1总体实现目标 (5) 1.1.2主要指标参数 (5) 1.1.3基本实现原理 (5) 1.1.4主要关键技术 (5) 1.1.5总体进度安排 (5) 2设计规划与实现 (5) 2.1（顶层模块）总体设计 (5) 2.1.1功能描述 (5) 2.1.2工作原理（关键算法） (5) 2.1.3结构框图 (5) 2.1.4数据流程 (5) 2.1.5接口定义 (5) 2.1.6信号时序 (5) 2.1.7寄存器定义 (6) 2.1.8技术难点 (6) 2.1.9实现文件 (6) 2.1.10问题跟踪 (6) 2.2（子模块1）设计 (6) 2.2.1功能描述 (6) 2.2.2工作原理（关键算法） (6) 2.2.3结构框图 (6) 2.2.4数据流程 (6) 2.2.5接口定义 (6) 2.2.6信号时序 (6) 2.2.7寄存器定义 (6) 2.2.8技术难点 (6) 2.2.9实现文件 (6) 2.2.10问题跟踪 (6) 2.3（子模块2）设计 (7) 3测试规划与结论 (7) 3.1测试平台 (7)
3.2（顶层模块）总体测试 (7) 3.2.1测试目的 (7) 3.2.2测试步骤 (7) 3.2.3测试方案及结果 (7) 3.2.4测试指标1 (7) 3.2.5测试指标2 (7) 3.3问题跟踪 (7) 3.4（子模块1）测试 (7) 3.4.1测试目的 (7) 3.4.2测试步骤 (7) 3.4.3测试方案及结果 (7) 3.4.4测试指标1 (7) 3.4.5问题跟踪 (8) 3.5（子模块2）测试 (8) 4使用说明 (8) 4.1功能 (8) 4.2性能 (8) 4.3运行环境 (8) 4.3.1硬件平台 (8) 4.3.2软件平台 (8) 4.4输入输出 (8) 4.4.1输入数据 (8) 4.4.2输出数据 (8) 4.5其它 (8) 参考文献 (8)
软件项目开发流程规范文档 目的与概述 本文档为XX公司的开发规范文档，给开发团队提供开发标准和规范。整体说明 在开发规范中包含了两个部分，第一部分是项目开发流程规范，主要阐述在项目开发过 程中的各个阶段的规范。第二部分为Coding开发规范，Coding开发规范阐述了在一个框 架中的各个层的开发规范 (注:在第一版中不包含对工作流开发的规范制定) 覆盖范围 阅读对象 1. 项目管理人员 2. 系统设计人员 3. 系统开发人员 参考资料 略 2 项目开发流程规范 2.1 业务需求调研阶段 ,,调研的目标 系统层面: 客户的系统运行环境 业务层面:了解客户需要什么样的系统，具体了解业务目的，业务逻辑，业务数据， 客户的操作习惯，页面风格习惯等。
,,调研的准备工作: 行业知识的准备: 了解客户的行业背景，行业领域的业务术语，含义。结合客户行业背景，了解客户的业务知识。 业务专家需求: 在行业领域的复杂度不高的情况下，业务分析人员直接收集并学习行业知识就可以了，但行业知识的准备工作还是要做的 在行业领域业务复杂度高的情况下，需要业务专家对客户的业务的进行整理。 ,,调研的流程: 第一步，项目启动阶段了解客户的IT环境。 第二步，讨论并具体确定客户系统的范围，并获得客户业务功能点的原始的单据。 在这个过程中准备一个本和一只笔记录讨论的业务信息 第三步，整理业务信息，和原始表单，抽取出有效业务信息，并对于不明确的业务 信息进行整理和归类，并制作成问卷形式进一步调研。 第四步，发放调研问卷，再次进行业务调研(直接转到三) 第五步，卷写调研问卷，并内部评审 第六步，调研问卷客户评审并确认。 ,,调研阶段的交付项(可配置项) 软件需求说明书 软件需求说明书的目录: 1 客户行业背景 2 客户系统的意义