软件开发规范
软件开发规范
1. 目的
为了保证企业编写出的程序都符合相同的规范，保证一致性、统一性而建立的程序编码规范。编码规范对于程序员而言尤为重要，有以下几个原因：
- 一个软件的生命周期中，80%的花费在于维护
- 几乎没有任何一个软件，在其整个生命周期中，均由最初的开发人员来维护
- 编码规范可以改善软件的可读性，可以让程序员尽快而彻底地理解新的代码
- 如果你将源码作为产品发布，就需要确任它是否被很好的打包并且清晰无误，一如你已构建的其它任何产品
为了执行规范，每个软件开发人员必须一致遵守编码规范。每个人。
2. 范围
适用于企业所有基于C#.NET平台的软件开发工作。
3. 规范内容
3.1. 文件规范
3.1.1. 文件命名
与类名名称相同
3.1.2. 文件内容格式
开头注释
引用
命名空间
类体
变量(代理事件)：用#region 变量………#endregion包括
属性：用#region属性………#endregion包括
构造：
方法(事件的实现)：用#region方法………#endregion包括
3.2. 代码格式
所有的缩进以Tab代替空格。
在代码中垂直对齐左括号{和右括号}。
if(x==0)
{
Response.Write("用户编号必须输入！");
}
不允许以下情况：
if(x==0) {
Response.Write("用户编号必须输入！");
}
或者：
if(x==0){ Response.Write("用户编号必须输入！");}
为了防止在阅读代码时不得不滚动源代码编辑器，每行代码或注释在1024*800的显示频率下不得超过一显示屏
当一行被分为几行时，通过将串联运算符放在每一行的末尾而不是开头，清楚地表示没有后面的行是不完整的。
每一行上放置的语句避免超过一条，即一条语句一行。
在大多数运算符之前和之后使用空格，这样做时不会改变代码的意图却可以使代码容易阅读。
例：
int j = i + k;
而不应写为
int j=i+k;
将大的复杂代码节分为较小的、易于理解的模块。
编写SQL 语句时，对于关键字使用全部大写，对于数据库元素（如表、列和视图）使用大写。
将每个主要的SQL 子句放在不同的行上，这样更容易阅读和编辑语句，例如：SELECT FirstName, LastName
FROM Customers
WHERE State = 'W A'
3.3. 注释（Comment）规范
注释规范包括：模块（类）注释规范、类的属性、方法注释规范、代码间注释
3.3.1. 模块（类）注释规范
模块开始必须以以下形式书写模块注释：
///
///定义某某类的方法
///
///
///
///
如果模块有修改，则每次修改必须添加以下注释：
///
3.3.2. 类属性注释规范
在类的属性必须以以下格式编写属性注释：
///
///属性说明
///
3.3.3. 方法注释规范
在类的方法声明前必须以以下格式编写注释
///
/// 说明：<对该方法的说明>
///
/// <参数说明>
///
///
代码间注释规范
代码间注释分为单行注释和多行注释：
单行注释：
//<单行注释>
多行注释：
/*多行注释1
多行注释2
多行注释3*/
代码中遇到语句块时必须添加注释（if,for,foreach,……）,添加的注释必须能够说明此语句块的作用和实现手段（所用算法等等）。
别每行代码，每个声明的变量都做注释
在需要的地方注释。可读性强的代码需要很少的注释。如果所有的变量和方法的命名都很有意义，会使代码可读性很强并无需太多注释。
行数不多的注释会使代码看起来优雅。但如果代码不清晰，可读性差，那就糟糕。
如果因为某种原因使用了复杂艰涩的原理，为程序配备良好的文档和重分的注释。
对一个数值变量采用不是0,-1等的数值初始化，给出选择该值的理由。
简言之，要写清晰，可读的代码以致无须什么注释就能理解。
对注释做拼写检查，保证语法和标点符号的正确使用
3.4. 变量（V ariable）命名规范
3.4.1. 程序文件(*.cs)中的变量命名规则
程序中变量名称= 变量的前缀+代表变量含意的英文单词或单词缩写
- 不能使用“_”，必须用有意义的，描述性的词语来命名变量。
- 合理使用缩写。不能用nam, addr, sal等代替name, address, salary
- 别使用单个字母的变量象i, n, x 等. 使用index, temp等，用于循环迭代的变量例外：
- 变量名中不使用数字。
- 命名空间需按照标准的统一的模式命名
- 文件名要和类名匹配，例如，对于类HelloWorld, 相应的类文件名应为helloworld.cs
- 如果变量只用于迭代计数，没有在循环的其他地方出现，可以使用i, n, x 等，而不是另外取名。for ( int i = 0; i < count; i++ ){ ...}
3.4.2. 类模块级的变量以变量类型的缩写作前缀
public class hello
{
private string strName;
private DateTime dtDate;
}
3.4.3. 类的属性所对应的变量，采用属性名前加类型的缩写作前缀前缀的形式
public class hello
{
private string s_Name;
public string Name
{
get
{
return m_Name;
}
}
3.4.4. 过程级的变量不使用前缀
public class hello
{
void say()
{
string SayWord;
}
}
3.4.5. 过程的参数使用“p”作为参数前缀
public class hello
{
void say(string pSayWord)
{
}
}
补充说明：
针对异常捕获过程中的Exception变量命名，在没有冲突的情况下，统一命名为e；如果有冲突的情况下，可以重复e，比如：ee。
Try
{
//your code
try
{
//code
}
catch(Exception ee)
{
//your code
}
}
catch(Exception e)
{
//your code
}
补充：如果捕获异常不需要作任何处理，则不需要定义Exception实例
例：
try
{
//your code
}
catch( Exception )
{
}
3.4.6. 鉴于大多数名称都是通过连接若干单词构造的，请使用大小写混合的格式以简化它们的阅读。每个单词的第一个字母都是大写.
3.4.7. 即使对于可能仅出现在几个代码行中的生存期很短的变量，仍然使用有意义的名称。仅对于短循环索引使用单字母变量名，如i 或j。
3.4.8. 在变量名中使用互补对，如min/max、begin/end 和open/close。
3.4.9. 别在程序中使用固定数值，用常量代替。不要使用原义数字或原义字符串，如for( i = 1,i< 7;i++)。而是使用命名常数，如for( i = 1,i< NUM_DAYS_IN_WEEK ; i++) 以便于维护和理解。
3.4.10.使用C# 或https://www.360docs.net/doc/167906613.html,的特有类型，而不是System命名空间中定义的别名类型，好：int age; string name; object contactInfo; 不好：Int16 age; String name; Object contactInfo
3.5. 控件命名规则
控件命名=Web控件缩写前缀+ “_” +变量名
控件
缩写
Label
lbl
TextBox
txt
CheckBox
ckb
Button
cmd
ListBox
lst
DropDownList
drp
等等
3.6. 常量命名规范
常量名也应当有一定的意义，格式为NOUN 或NOUN_VERB。常量名均为大写，字之间用下划线分隔。
例：
private const bool WEB_ENABLEPAGECACHE_DEFAULT = true;
private const int WEB_PAGECACHEEXPIRESINSECONDS_DEFAULT = 3600;
private const bool WEB_ENABLESSL_DEFAULT = false;
注：
变量名和常量名最多可以包含255 个字符，但是，超过25 到30 个字符的名称比较笨拙。此外，要想取一个有实际意义的名称，清楚地表达变量或常量的用途，25 或30 个字符应当足够了。
3.7. 类（Class）命名规范
1．名字应该能够标识事物的特性。
2．名字尽量不使用缩写，除非它是众所周知的。
3．名字可以有两个或三个单词组成，但通常不应多于三个。
4．在名字中，所有单词第一个字母大写，缩写都要大写。
例如IsSuperUser，包含ID的，ID全部大写，如CustomerID。
5．使用名词或名词短语命名类。
6．少用缩写。
7．不要使用下划线字符(_)。
例：
public class FileStream
public class Button
public class String
3.8. 接口（Interface）命名规范
和类命名规范相同，唯一区别是接口在名字前加上“I”前缀
例：
interface IDBCommand;
interface IButton;
3.9. 方法（Method）命名规范
和类命名规范相同。
另：方法开头尽量使用e文动词表示，
如：GetMoney , SetMoney
3.4.7 命名空间（NameSpace）命名规范
方法的命名.一般将其命名为动宾短语.
ShowDialog()
CreateFile()
GetPath()
3.10. 异常处理
A. 不必在所有方法中捕捉一般异常。不管它，让程序崩溃。这将帮助你在开发周期发现大多数的错误
B. 不必每个方法都用try-catch。当特定的异常可能发生时才使用。比如，当你写文件时，处理异常FileIOException
C. 别写太大的try-catch 模块。如果需要，为每个执行的任务编写单独的try-catch 模块。这将帮你找出哪一段代码产生异常，并给用户发出特定的错误消息
D. 不要“捕捉了异常却什么也不做“，除非有特殊需求。如果隐藏了一个异常，你将永远不知道异常到底发生了没有
E. 错误消息需能帮助用户解决问题。永远别用象"应用程序出错", "发现一个错误" 等错误消息。而应给出象"更新数据库失败。请确保登陆id和密码正确。" 的具体消息
F. 显示错误消息时，除了说哪里错了，还应提示用户如何解决问题。不要用象"更新数据库失败。"这样的，要提示用户怎么做："更新数据库失败。请确保登陆id和密码正确。
G. 显示给用户的消息要简短而友好。但要把所有可能的信息都记录下来，以助诊断问题
3.11. 良好的编程习惯需注意以下几点：
1) 别用字符串常数。用资源文件。
2) 别把成员变量声明为public 或protected。都声明为private 而使用public/protected 的Properties
3) 不在代码中使用具体的路径和驱动器名。使用相对路径，并使路径可编程。
4) 永远别设想你的代码是在“C:”盘运行。你不会知道，一些用户在网络或“Z:”盘运行程序。
5) 应用程序启动时作些“自检”并确保所需文件和附件在指定的位置。必要时检查数据库连接。出现任何问题给用户一个友好的提示。
6) 如果需要的配置文件找不到，应用程序需能自己创建使用默认值的一份。
7) 如果在配置文件中发现错误值，应用程序要抛出错误，给出提示消息告诉用户正确值。
8) 所有的成员变量声明在类的顶端，用一个换行把它和方法分开
9) 建议局部变量在最接近使用它时再声明
10) 使用某个控件的值时，尽量命名局部变量
11) 把引用的系统的namespace和自定义或第三方的分开
12) 目录结构中要反应出namespace的层次
13) 大括号"{"一定要新起一行
14) 尽量不要手工更改机器生成的代码，若必须更改，一定要改成和机器生成的代码风格一样
15) 文字常量和数字常量不要硬编码，应该用常量类或枚举代替
16) 不要用goto系列语句
17) 不要声明public的event，应用事件访问器
18) 生成和构建一个长的字符串时，一定要使用StringBuilder，而不用string
19) 始终使用"{ }"包含if下的语句，即使只有一条语句
20) switch语句一定要有default来处理意外情况
21) 尽量不用使用this引用，除非是要调用类中的另一个Constructor public class Person
{
public Person(string name)
{
}
public Person() : this("Jim")
{
}
}
4.
5.
SQL编码规范
1. 书写格式
示例代码：
存储过程SQL文书写格式例
select
c.dealerCode,
round(sum(c.submitSubletAmountDLR + c.submitPartsAmountDLR + c.submitLaborAmountDLR) / count(*), 2) as avg,
decode(null, 'x', 'xx', 'CNY')
from (
select
a.dealerCode,
a.submitSubletAmountDLR,
a.submitPartsAmountDLR,
a.submitLaborAmountDLR
from SRV_TWC_F a
where (to_char(a.ORIGSUBMITTIME, 'yyyy/mm/dd') >= 'Date Range(start)' and to_char(a.ORIGSUBMITTIME, 'yyyy/mm/dd') <= 'Date Range(end)' and nvl(a.deleteflag, '0') <> '1')
union all
select
b.dealerCode,
b.submitSubletAmountDLR,
b.submitPartsAmountDLR,
b.submitLaborAmountDLR
from SRV_TWCHistory_F b
where (to_char(b.ORIGSUBMITTIME, 'yyyy/mm/dd') >= 'Date Range(start)' and to_char(b.ORIGSUBMITTIME,'yyyy/mm/dd') <= 'Date Range(end)' and nvl(b.deleteflag,'0') <> '1')
) c
group by c.dealerCode
order by avg desc;
C#中里的SQL字符串书写格式例
strSQL = "insert into Snd_FinanceHistory_Tb " +
"(DEALERCODE, " +
"REQUESTSEQUECE, " +
"HANDLETIME, " +
"JOBFLAG, " +
"FRAMENO, " +
"INMONEY, " +
"REMAINMONEY, " +
"DELETEFLAG, " +
"UPDA TECOUNT, " +
"CREUSER, " +
"CREDA TE, " +
"HONORCHECKNO, " +
"SEQ) " +
"values ('" + draftInputDetail.dealerCode + "', " +
"'" + draftInputDetail.requestsequece + "', " +
"sysdate, " +
"'07', " +
"'" + frameNO + "', " +
requestMoney + ", " +
remainMoney + ", " +
"'0', " +
"0, " +
"'" + draftStruct.employeeCode + "', " +
"sysdate, " +
"'" + draftInputDetail.honorCheckNo + "', " +
index + ")";
1.1. .缩进
对于存储过程文件，缩进为1个TAB
对于C#里的SQL字符串，不可有缩进，即每一行字符串不可以空格开头
1.2. 换行
1>.Select/From/Where/Order by/Group by等子句必须另其一行写
2>.Select子句内容如果只有一项，与Select同行写
3>.Select子句内容如果多于一项，每一项单独占一行，在对应Select的基础上向右缩进1个TAB（C#无缩进）
4>.From子句内容如果只有一项，与From同行写
5>.From子句内容如果多于一项，每一项单独占一行，在对应From的基础上向右缩进1个TAB（C#无缩进）
6>.Where子句的条件如果有多项，每一个条件占一行，以AND开头，且无缩进
7>.(Update)Set子句内容每一项单独占一行，无缩进
8>.Insert子句内容每个表字段单独占一行，无缩进；values每一项单独占一行，无缩进
9>.SQL文中间不允许出现空行
10>.C#里单引号必须跟所属的SQL子句处在同一行，连接符（"+"）必须在行尾
1.3. 空格
1>.SQL内算数运算符、逻辑运算符连接的两个元素之间必须用空格分隔
2>.逗号之后必须接一个空格
3>.关键字、保留字和左括号之间必须有一个空格
2. .不等于统一使用"<>"。虽然SQLServer认为"!="和"<>"是等价的，都代表不等于的意义。为了统一，不等于一律使用"<>"表示
3. 使用表的别名, 数据库查询，必须使用表的别名。
4. SQL文对表字段扩展的兼容性。在C#里使用Select *时，严禁通过getString(1)的形式得到查询结果，必须使用getString("字段名")的形式；使用Insert时，必须指定插入的字段名，严禁不指定字段名直接插入values
5. 减少子查询的使用。子查询除了可读性差之外，还在一定程度上影响了SQL运行效率，请尽量减少使用子查询的使用，用其他效率更高、可读性更好的方式替代。
6. 适当添加索引以提高查询效率，适当添加索引可以大幅度的提高检索速度，请参看SQLSERVER SQL性能优化系列。
7. 对数据库表操作的特殊要求
本规范对数据库表的操作还有以下特殊要求：
1).以逻辑删除替代物理删除
注意：现在数据库表中数据没有物理删除，只有逻辑删除
以deleteflag字段作为删除标志，deleteflag='1'代表此记录被逻辑删除，因此在查询数据时必须考虑deleteflag的因素，deleteflag的标准查询条件：NVL(deleteflag, '0') <> '1'
2).增加记录状态字段
数据库中的每张表基本都有以下字段：INITIAL_DT、INITIAL_USR、REC_UPDA TE_DT、REC_UPDA TE_USR
要注意在对标进行操作时必须考虑以下字段
插入一条记录时要置INITIAL_DT =sysdate, INITIAL_USR =登录User；修改一条记录时要置REC_UPDA TE_DT =sysdate, REC_UPDA TE_USR =登录User,
8. 用执行计划分析SQL性能
EXPLAIN PLAN是一个很好的分析SQL语句的工具，它可以在不执行SQL的情况下分析语句。通过分析，我们就可以知道SQLSERVER是怎样连接表，使用什么方式扫描表（索引扫描或全表扫描），以及使用到的索引名称，按照从里到外，从上到下的次序解读分析的结果，EXPLAIN PLAN的分析结果是用缩进的格式排列的，最内部的操作将最先被解读，如果两个操作处于同一层中，带有最小操作号的将首先被执行。目前许多第三方的工具如PLSQL Developer和TOAD等都提供了极其方便的EXPLAIN PLAN工具，PG需要将自己添加的查询SQL文记入log，然后在EXPLAIN PLAN中进行分析，尽量减少全表扫描，
9. SQLSERVER SQL性能优化系列
9.1. 选择最有效率的表名顺序(只在基于规则的优化器中有效)
SQLSERVER的解析器按照从右到左的顺序处理FROM子句中的表名，因此FROM子句中写在最后的表（基础表driving table）将被最先处理，在FROM子句中包含多个表的情况下，必须选择记录条数最少的表作为基础表，当SQLSERVER处理多个表时，会运用排序及合并的方式连接它们，
首先，扫描第一个表（FROM子句中最后的那个表)并对记录进行排序；然后扫描第二个表（FROM子句中最后第二个表)；最后将所有从第二个表中检索出的记录与第一个表中合适记录进行合并
例如: 表TAB1 16,384 条记录表TAB2 5 条记录，选择TAB2作为基础表(最好的方法) select count(*) from tab1,tab2 执行时间0.96秒，选择TAB2作为基础表(不佳的方法) select count(*) from tab2,tab1 执行时间26.09秒；
如果有3个以上的表连接查询，那就需要选择交叉表（intersection table）作为基础表，交叉表是指那个被其他表所引用的表
例如:
EMP表描述了LOCA TION表和CA TEGORY表的交集
SELECT *
FROM LOCA TION L,
CA TEGORY C,
EMP E
WHERE E.EMP_NO BETWEEN 1000 AND 2000
AND E.CA T_NO = C.CA T_NO
AND E.LOCN = L.LOCN
将比下列SQL更有效率
SELECT *
FROM EMP E ,
LOCA TION L ,
CA TEGORY C
WHERE E.CA T_NO = C.CA T_NO
AND E.LOCN = L.LOCN
AND E.EMP_NO BETWEEN 1000 AND 2000
9.2. WHERE子句中的连接顺序
SQLSERVER采用自下而上的顺序解析WHERE子句，根据这个原理，表之间的连接必须写在其他WHERE条件之前，那些可以过滤掉最大数量记录的条件必须写在WHERE 子句的末尾
例如：
(低效,执行时间156.3秒)
SELECT *
FROM EMP E
WHERE SAL > 50000
AND JOB = 'MANAGER'
AND 25 < (SELECT COUNT(*) FROM EMP WHERE MGR=E.EMPNO);
(高效,执行时间10.6秒)
SELECT *
FROM EMP E
WHERE 25 < (SELECT COUNT(*) FROM EMP WHERE MGR=E.EMPNO)
AND SAL > 50000
AND JOB = 'MANAGER';
9.3. SELECT子句中避免使用'*'。当你想在SELECT子句中列出所有的COLUMN时，使用动态SQL列引用'*'是一个方便的方法，不幸的是，这是一个非常低效的方法。实际上，SQLSERVER在解析的过程中，会将'*'依次转换成所有的列名，这个工作是通过查询数据字典完成的，这意味着将耗费更多的时间
9.4. 减少访问数据库的次数。当执行每条SQL语句时，SQLSERVER在内部执行了许多工作：解析SQL语句，估算索引的利用率，绑定变量，读数据块等等
由此可见，减少访问数据库的次数，就能实际上减少SQLSERVER的工作量，例如：以下有三种方法可以检索出雇员号等于0342或0291的职员
方法1 (最低效)
SELECT EMP_NAME, SALARY, GRADE
FROM EMP
WHERE EMP_NO = 342;
SELECT EMP_NAME, SALARY, GRADE
FROM EMP
WHERE EMP_NO = 291;
方法2 (次低效)
DECLARE
CURSOR C1 (E_NO NUMBER) IS
SELECT EMP_NAME,SALARY,GRADE
FROM EMP
WHERE EMP_NO = E_NO;
BEGIN
OPEN C1(342);
FETCH C1 INTO …,…,…;
…
OPEN C1(291);
FETCH C1 INTO …,…,…;
…
CLOSE C1;
END;
方法2 (高效)
SELECT A.EMP_NAME, A.SALARY, A.GRADE,
B.EMP_NAME, B.SALARY, B.GRADE
FROM EMP A, EMP B
WHERE A.EMP_NO = 342
AND B.EMP_NO = 291;
9.5. 使用DECODE函数来减少处理时间
使用DECODE函数可以避免重复扫描相同记录或重复连接相同的表
例如：
SELECT COUNT(*), SUM(SAL)
FROM EMP
WHERE DEPT_NO = '0020'
AND ENAME LIKE 'SMITH%';
SELECT COUNT(*), SUM(SAL)
FROM EMP
WHERE DEPT_NO = '0030'
AND ENAME LIKE 'SMITH%';
你可以用DECODE函数高效地得到相同结果
SELECT COUNT(DECODE(DEPT_NO, '0020', 'X', NULL)) D0020_COUNT,
COUNT(DECODE(DEPT_NO, '0030', 'X', NULL)) D0030_COUNT,
SUM(DECODE(DEPT_NO, '0020', SAL, NULL)) D0020_SAL,
SUM(DECODE(DEPT_NO, 0030, SAL, NULL)) D0030_SAL
FROM EMP
WHERE ENAME LIKE 'SMITH%';
'X'表示任何一个字段
类似的，DECODE函数也可以运用于GROUP BY和ORDER BY子句中
9.6. 用Where子句替换HA VING子句
避免使用HA VING子句，HA VING只会在检索出所有记录之后才对结果集进行过滤，这个处理需要排序、统计等操作
如果能通过WHERE子句限制记录的数目，那就能减少这方面的开销
例如：
低效
SELECT REGION, A VG(LOG_SIZE)
FROM LOCA TION
GROUP BY REGION
HA VING REGION REGION != 'SYDNEY'
AND REGION != 'PERTH'
高效
SELECT REGION, A VG(LOG_SIZE)
FROM LOCA TION
WHERE REGION REGION != 'SYDNEY'
AND REGION != 'PERTH'
GROUP BY REGION
9.7. 减少对表的查询
在含有子查询的SQL语句中，要特别注意减少对表的查询
例如：
低效
SELECT TAB_NAME
FROM TABLES
WHERE TAB_NAME = (SELECT TAB_NAME
FROM TAB_COLUMNS
WHERE VERSION = 604)
AND DB_VER = (SELECT DB_VER
FROM TAB_COLUMNS
WHERE VERSION = 604)
高效
SELECT TAB_NAME
FROM TABLES
WHERE (TAB_NAME, DB_VER) = (SELECT TAB_NAME, DB_VER
FROM TAB_COLUMNS
WHERE VERSION = 604)
Update多个Column例子：
低效
UPDA TE EMP
SET EMP_CA T = (SELECT MAX(CA TEGORY)
FROM EMP_CA TEGORIES),
SAL_RANGE = (SELECT MAX(SAL_RANGE)
FROM EMP_CA TEGORIES)
WHERE EMP_DEPT = 0020;
高效
UPDA TE EMP
SET (EMP_CA T, SAL_RANGE) = (SELECT MAX(CA TEGORY), MAX(SAL_RANGE) FROM EMP_CA TEGORIES)
WHERE EMP_DEPT = 0020;
9.8. 使用表的别名(Alias)，当在SQL语句中连接多个表时，请使用表的别名并把别名前缀于每个Column上，这样可以减少解析的时间并减少那些由Column歧义引起的语法错误
9.9. 用EXISTS替代IN
在许多基于基础表的查询中，为了满足一个条件，往往需要对另一个表进行联接
在这种情况下，使用EXISTS(或NOT EXISTS)通常将提高查询的效率
低效
SELECT *
FROM EMP (基础表)
WHERE EMPNO > 0
AND DEPTNO IN (SELECT DEPTNO
FROM DEPT
WHERE LOC = 'MELB')
高效
SELECT *
FROM EMP (基础表)
WHERE EMPNO > 0
AND EXISTS (SELECT 'X'
FROM DEPT
WHERE DEPT.DEPTNO = EMP.DEPTNO
AND LOC = 'MELB')
9.10. 用NOT EXISTS替代NOT IN
在子查询中，NOT IN子句将执行一个内部的排序和合并
无论在哪种情况下，NOT IN都是最低效的，因为它对子查询中的表执行了一个全表遍历
为了避免使用NOT IN，我们可以把它改写成外连接(Outer Joins)或NOT EXISTS
例如：
SELECT …
FROM EMP
WHERE DEPT_NO NOT IN (SELECT DEPT_NO
FROM DEPT
WHERE DEPT_CA T = 'A');
为了提高效率改写为
高效
SELECT …
FROM EMP A, DEPT B
WHERE A.DEPT_NO = B.DEPT(+)
AND B.DEPT_NO IS NULL
AND B.DEPT_CA T(+) = 'A'
最高效
SELECT …
FROM EMP E
WHERE NOT EXISTS (SELECT 'X'
FROM DEPT D
WHERE D.DEPT_NO = E.DEPT_NO
AND DEPT_CA T = 'A');
9.11. 用表连接替换EXISTS
通常来说，采用表连接的方式比EXISTS更有效率
例如：
SELECT ENAME
FROM EMP E
WHERE EXISTS (SELECT 'X'
FROM DEPT
WHERE DEPT_NO = E.DEPT_NO
AND DEPT_CA T = 'A');
更高效
SELECT ENAME
FROM DEPT D, EMP E
WHERE E.DEPT_NO = D.DEPT_NO
AND DEPT_CA T = 'A';
9.12. 用EXISTS替换DISTINCT
当提交一个包含多表信息（比如部门表和雇员表）的查询时，避免在SELECT子句中使用DISTINCT，一般可以考虑用EXIST替换
例如：
低效
SELECT DISTINCT DEPT_NO, DEPT_NAME
FROM DEPT D, EMP E
WHERE D.DEPT_NO = E.DEPT_NO
高效
SELECT DEPT_NO, DEPT_NAME
FROM DEPT D
WHERE EXISTS (SELECT 'X'
FROM EMP E
WHERE E.DEPT_NO = D.DEPT_NO);
EXISTS使查询更为迅速，因为RDBMS核心模块将在子查询的条件一旦满足后，立
华为软件开发规范
软件开发规范 1 排版 11-1：程序块要采用缩进风格编写，缩进的空格数为4个。 说明：对于由开发工具自动生成的代码可以有不一致。 11-2：相对独立的程序块之间、变量说明之后必须加空行。 示例：如下例子不符合规范。 if (!valid_ni(ni)) { ... epssn_index; repssn_ni = ssn_data[index].ni; 应如下书写 if (!valid_ni(ni)) { ... epssn_index; repssn_ni = ssn_data[index].ni; 11-3：较长的语句（>80字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读。 示例： = NO7_TO_STAT_PERM_COUNT_LEN + STAT_SIZE_PER_FRAM * sizeof( _UL ); act_task_table[frame_id * STAT_TASK_CHECK_NUMBER + index].occupied
= stat_poi[index].occupied; act_task_table[taskno].duration_true_or_false = SYS_get_sccp_statistic_state( stat_item ); report_or_not_flag = ((taskno < MAX_ACT_TASK_NUMBER) && (n7stat_stat_item_valid (stat_item)) && (act_task_table[taskno].result_data != 0));
软件开发团队管理手册
目录 1.前言 团队管理是项目管理工作的重要组成部分，是一种通过更好的团队合作来提升绩效的有效机制。本文档将对团队管理的过程作出明确的规定和说明。 2.目的 本过程的目的是通过更好的团队合作来提升绩效，加强团队成员之间的合作力度，更有效的管理和更好地作出决定，并提高生产率，从而获得更高的效率和更好的绩效。为软件项目团队的管理提供指导。 3.适用范围 适用于公司的所有的软件开发项目。 4.团队简介 团队是由员工和管理层组成的一个共同体，该共同体合理利用每一个成员的知识和技能协同工作，解决问题，达到共同的目标。 团队由目标(Purpose)、人(People)、团队的定位(Place)、权限(Power)、计划(Plan)等五要素构成。 4.1.团队和群体的区别 图团队和群体的比较 4.2.团队的类型 团队有以下几种不同的类型。 项目团队 项目团队是为某项具体任务而临时组成的团队。它通常是一个大项目团队的分队，为了完成某项具体任务而独立开展活动。项目团队的生命期取决于任 务的长短。 公司各个事业部独立承担且开发周期比较固定的项目都属于项目团队。例如：汽车回收系统项目，多面评价系统项目等。 部门团队 在部门内部长期从事某项工作的人组成了工作团队。工作团队使共同工作的员工之间配合得更加默契。对于工作团队来说，沟通和解决问题是关键任务。 公司各个事业部独立承担且开发周期比较长的项目都属于部门团队。 例如：水处理项目，证卷系统开发项目，铁路管理系统项目等。
跨部门团队 跨部门团队涉及几个部门的人员，它的目的是制订计划，完成一个项目或解决某个重要问题。公司各个事业部联合开发的项目都属于跨部门团队。例如： ERP系统开发项目等。 领导团队 领导团队由某位高层领导和他或她的直接下属组成。领导团队的工作是组织所有高层或中层领导参与项目决策和对项目实施提供资源支持。 公司领导直接负责和管理的项目属于领导团队。 例如：CMMI项目等。 4.3.过程总体概述 启动期动荡期规范期表现期调整期 5.过程活动描述 5.1.进入条件 根据项目需求,经过项目管理委员会审批,组建项目开发体制。 5.2.输入 立项书 项目开发体制图 5.3.启动期 即团队形成的初期。也是团队成员理解和接受他人，关注团队的时期。 5.3.1.启动期的特征 感受和想法激动, 骄傲, 害怕… 我们的任务是什么 ? 我们应该干什么 ? 可观 察到的行为表现 警惕,提防,焦虑，最低限度的沟通,缺乏自信团队需求了解目标、成员资格、角色、责任、工作任务、标准以及工作流程所需领导艺术--引导 引导 -- 确定目标, 明确任务,确定团队工作流程,时间,地点 5.3.2.团队组建初期的两个工作重点 形成团队内部的工作流程和管理框架。 建立和维护与客户的联系渠道。 项目团队组建初期的两个工作重点简单地说一个是对内，在内部建立什么样的体制；一个是对外，怎样跟客户保持联系。 (1)团队的内部体制需要考虑的问题： 团队的任务是什么？ 团队成员的需要有那些资质或资格？
软件开发过程管理规范
软件开发过程管理规范文件管理序列号：[K8UY-K9IO69-O6M243-OL889-F88688]
0 引言 如果要提高软件开发人员的开发质量，必须有相应的考核制度，有了制度后才能推动开发人员想方设法改善自已的开发质量。目前研发对软件开发的过程缺乏细粒度的度量，所以不能依据有效的度量数据来考核开发人员的工作绩效，大部份只是凭考核人主观意志来考核，不能形成对被考核人有效的说服力。此绩效考核办法旨在结合实际情况合理客观地评价开发效率和质量。 1 目的 对软件开发的过程所产生的软件项的质量和过程进行定量的评价，用评价的结果指导软件的开发过程，不断地提高软件开发质量水平，并依据度量记录来考核软件开发人员的工作绩效。 2 软件项包括 1）技术文档：主要包括：可行性分析报告、需求分析报告、软件功能规格说明、开发计划、系统设计报告、测试文档、用户手册、总结报告等； 2）计算机程序。 3 度量数据的来源 1）项目计划； 2）评审报告； 3）测试报告； 4）问题报告； 5）软件维护记录； 4 质量度量
4.1 度量指标 主要根据各类软件项检查表的检查指标来确定，例如，软件需求规格说明书检查表（见附录1），有10个检查指标，则根据具体项目检查侧重点不同，可从中选择相应的检查指标作为度量指标。 4.2 质量等级 1）软件项的质量等级的确定根据度量综合指标进行。 2）度量综合指标计算公式为：Total = ∑QiMi。 3）其中i=1,2,...n代表指标数量； 4）Q代表度量的指标； 5）M代表度量的指标Q在整个指标体系中所占的权重系数，对不同的开发项目可能不同，此系数根据开发的不同着重点给出。 度量指标权重系数表： 序号指标权重 1 指标1 权数1 2 指标2 权数2 3 指标3 权数3 4 指标4 权数4 5 指标5 权数5 加权平均分 1.0 6）质量评价：一般地，根据度量综合指标值，有以下评分标准。 质量评价计分标准表 序号得分质量评价
软件开发规范标准整体规范标准
软件开发规范 Software Development Specification Version: V1.0 Date: 2010-06-22 Prepared by
Document Revision History文档修订记录
Table of Contents目录 1Introduction 简介5 1.1Purpose 目标5 1.2Scope 范围6 1.3Definitions, Acronyms, and Abbreviations. 术语，缩略词6 1.4References 引用7 1.5Overview 文档组织7 2The Overall Description 概述8 2.1Software Development Organizing 开发团队组织结构8 2.2Project Base Process 项目基本流程9 2.3CMM Base Process CMM基本过程10 2.3.1SCM软件配置管理10 2.3.2SPP 计划策划12 2.3.3SPTO项目追踪16 2.3.4PR同行评审18 2.3.5SQA质量保证19 2.4SDLC 生命周期选择20 2.5Development Process 开发过程21 2.5.1Development Phase 开发阶段21 2.5.2Phase Product 阶段制品22 2.6Role Duty 角色职责23 2.7Constraints 限制24 3Specific Requirements 详细描述25 3.1Precondition 前提25 3.1.1SCM配置库25 3.1.2Test Environment 测试环境26 3.2Development Control Process 开发控制流程26 3.2.1项目启动和策划阶段27 3.2.2需求分析、设计、编码阶段27 3.2.3提交测试阶段27 3.2.4生产发布、终测28 3.2.5发布后问题反馈修改过程28 3.3TSP 团队软件过程30 3.3.1会议组织30 3.3.2沟通问题30 3.3.3代码走查30
公司行为规范管理制度(1)
公司行为规范管理制度 编辑日期： 版本号： 编撰人： 批准人： 制度编号：
一、 目的：为了规范公司员工行为准则，建立公司的企业形象，完善企业的管理、营造良好的工作环境，提高员工工作效率，特制订员工行为规范管理制度。 二、 适用范围：全体员工 三、 内容： 第一条 着装要求：员工着装标准（包括胸卡、胸徽）是工作服必须保持熨烫平整、干净。一般着装规范： 1、要求正装（男士：浅色衬衣，深色西裤，不得穿运动鞋和旅游鞋；女士不允许穿牛仔裤、运动鞋和旅游鞋） 2、员工在每周的正式上班时间内，必须按上述规定着装。每周末，视不同岗位的工作性质，可允许穿工作便装。下述类型的服装可视为工作便装：带领T 恤衫和便裤。牛仔衣、短裤、紧身衣裤、运动鞋之类的服装和鞋类不可作为工作便装，不适合办公时穿着。 3、在接待客户时必须着职业服装，着装要求是在对外交往中,如会见客户、政府官员、来访者，体现职业气质所必不可少的。 4、接待客户时的衣着仪表要求 （男性） 5、接待客户时的衣着仪表要求 （女性） 在进入公司前请确认： 头发是否妨碍工作 妆画得是否过于浓艳 是否有头皮屑 服装是否得体 饰品是否过于华丽 服装是否整齐 甲是否修整好了 （指甲油是否过于浓艳） 鞋是否干净 牙齿上是否有异物 第二条 吸烟规定：为营造安全、舒适和健康的工作环境，建立企业形象，吸烟需要到指定的吸烟区。 1、在有禁烟桌牌标志的区域严禁员工吸烟。 2、有吸烟习惯的员工到指定吸烟区吸烟。公司提倡公用办公室禁烟。 3、公司严禁任何人吸游烟（即禁止手上有点燃的香烟时走动）。
4、公司召开各种会议时规定禁烟。 5、违反的员工将处罚50元/次，经理及以上人员处罚100元/次。 第三条应答电话 1、应答电话时不允许超过三声，应答时必须报出公司名称：“您好，龙骑天际”或根据情况报出部门名称。电话转接时必须回答对方：“请您稍等”之后转接。没有马上接电话时，请先说“您好，让您久等了”。 2、为保证办公室的工作环境，员工应尽快应答电话，如不在位置上请周围的员工代接电话应答时，代接员工应先自报姓名，应答或转接电话，一定要尽力帮助对方。切记你代表的是龙骑天际，第一形象十分重要。打电话的人会根据你接电话的语言及态度做出判断。 3、提示： 1）应答电话要精神振作，声调悦耳； 2）对方留言时，要正确记下对方的姓名和电话号码、认真记录5W1H（5W1H—何时、何地、谁、干什么、为什么；何种方式)，并且要重复。 3）如同事离开办公桌，要替他应答电话； 4）如自己离开办公桌，要告诉秘书或同事，或在桌上留言，讲明去何处及估计何时回来。 第四条工作场所礼仪 1、上班进入公司内，初次与同事、主管相见，要礼貌热情点头致意，并率先问候：“早上好！”或“你好！”，声音要清晰洪亮。 2、下班离开前，要礼貌与同事道别，问候“再见！”或“明天见！”。 3、日间办公时间出入，与公司领导、同仁相遇要礼貌点头致意，并问候“你好！”。 4、国内外客户与外宾参观来访时，行进间相遇，应停留侧立礼让先行，并微笑点头致意，问候“欢迎光临”或“您好”等；如正在岗位工作状态，微笑点头示意后应立即投入工作，不得无理观望、议论，或东张西望，要体现出应有的礼貌修养与工作投入感。 5、欲与别人谈话时，请先征得对方同意：“对不起，打扰您一下。可以吗？”或“可以占用您一点儿时间吗？”。交谈时态度要亲切、礼貌，谈话声音要清晰、小声。谈完后请不要忘记说“谢谢！”。 6、进入其他办公室沟通或请示、报告，一定要先轻轻敲门，得到允许后方可入内；出入行走及开关门亦要动作轻。 7、办公时间，不要谈论与工作无关事宜，特别是不要和其他人谈论公司内部人事或其他机密；严禁到其它办公室随意走动闲聊；严禁在办公时间放音乐干扰他人。 8、维护安静、严肃的工作气氛，不得在办公室及楼道内大声喧哗、高声叫人、吵闹。休息时间请不要忘记可能还有别的同事在工作。 第五条办公室管理规定 1、办公桌面可摆放电脑、电话、资料架（夹）、必要的办公文具、茶杯。放置必须整齐、美观、安全，不得摆放个人物品。 2、抽屉、文件柜须按大小、常用与否、类别等分类建档管理，保持其整齐、清洁。 3、涉及保密的文件、资料不得任意摆放，须锁藏在抽屉里。 4、每天下班前，必须整理桌面、抽屉。将一天所使用的文具、资料等归回原位。 5、每月整理一次抽屉、文件柜。一个月以上使用一次的物品、资料，放置在抽屉里。 6、每季度最后一天，定为“清理日”。将保留物和舍弃物清理出来。保留物按规定存放；舍弃物及时处理掉，其中保密资料必须严格处理、销毁。 7、每天上班，必须对办公桌桌面进行清洁。维持桌面干净无尘，电话、文件柜、文件架（夹）、电脑等的表面清洁；每一位员工对自己的办公区域的用品、桌面、地面清洁负责。 8、不得在禁烟区吸烟。不允许在办公室内吃零食。 9、接听电话、接待来客时应言行得体。交谈声音不宜过大，以免干扰他人办公。不在公司打私人电话。原则上不得在办公区域接待来客。 第 3 页共5 页
软件开发与维护管理规范
软件开发与维护管理规范 1 目的通过规范软件的开发与维护过程，达到提高软件质量，降低维护成本的目的。 2 范围适用于新产品的软件开发设计以及定型产品的改进升级。 3 职责与权限 研发中心负责： a)编制软件开发过程的实施、协调和控制工作； b)编制各阶段的技术文件； c)组织软件的测试、验收、升级和维护工作。 各部门参与软件开发过程中有关的设计评审。 4 内容 软件项目的开发实施过程管理要求 软件项目实施过程总体要求 本部分主要要求工程师制定软件开发工作计划，对过程进行控制，一般包括以下的内容。a) 工程师提交软件开发工作大纲，项目组织者对工作大纲进行评审，并提出整改意见。 b)通过评审后，工程师根据整改意见完善工作大纲，经过项目经理认可后组织项目组进行 软件开发。软件开发工作按照需求分析、概要设计、详细设计、编码、测试等几个阶段进行，在开发过程中，工程师需分阶段提交相关文档。 c)在软件开发工作完成后，工程师应向项目组提交完整的软件文档，相关人员组织验收组对软件进行验收审查。 软件项目实施变更要求在开发过程中，需求或设计不可避免地需要发生变更，相关变更必须提交《软件变更申请》经过项目组书面同意方可进行。在需求或设计发生变更时，需要对原有文档进行修改，并提供完整的变更记录，以使变更处于可控制的状态。 软件项目实施里程碑控制本部分主要对软件开发过程中的重要节点进行控制。项目组将分四个阶段进行把关，召开审查会。 a）需求分析（结合原型进行审查）确认；
b）概要设计+数据库设计； c）预验收（样机测试时）； d）正式验收（产品定型后）。 软件开发 软件开发必须严格按照软件工程的要求进行。开发过程包括工程师的活动和任务。此过程由软件需求分析、概要设计、详细设计、编码、测试、验收、鉴定等活动组成。 软件的需求分析 需求分析 需求分析要求开发人员准确理解用户的需求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转化到相应的形式功能规约《软件需求规格说明书》的过程。 在《软件需求规格说明书》必须描述的基本问题是：功能、性能、强加于实现的设计限制、属性、外部接口。 需求报告评审在软件需求分析工作完成后，软件工程师应向项目组提交《软件需求规格说明书》。项目组组织有关人员（系统客户和系统开发人员等）对需求进行评审，以决定软件需求是否完善和恰当。项目组严格验证这些需求的正确性，一般从一致性，完整性，现实性，有效性四个方面进行验证。评审完成后，就可以进入软件的设计阶段。 软件的概要设计 概要设计 概要设计也称为系统设计，需要确定软件的总体结构，应该由哪些模块组成，以及模块与模块之间的接口关系，软件系统主要的数据结构和出错处理设计等，同时还要制定测试方案，形成概要设计说明书，为软件的详细设计提供基础。在概要设计时一般从以下几方面来考虑，遵循以下的流程。 概要设计和需求分析、详细设计之间的关系和区别需求分析不涉及具体的技术实现，而概要设计注重于从宏观上和框架上来描述采用何种技术手段、方法来实现这些需求。详细设计相对概要设计更注重于微观上和框架内的设计，是编码的依据。概要设计是指导详细设计的依据。 概要设计的评审 在软件概要设计工作完成后，软件工程师应向项目组提交《软件概要设计》。评审通过后，即可进入详细设
国家标准软件开发主要编写规范
国家标准(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. 控制精度或生产能力的提高。
软件开发工作制度规范
软件开发工作制度规范 【工作流程规范】 1.对于工作小组或部门组织的会议和培训应由专门负责人员及时记录并 上传至svn（李路为负责人）。 2.在每工作日开始时，应将所负责项目进行更新，在每工作日结束前必须 将代码在不报错的形式下上传至svn,并做好自己本地备份。程序更新应 及时告知和说明，以保持项目代码和功能的同步。 3.每周根据当周所完成的工作任务进行总结，并对下周的工作进行计划安 排，以周报记录的形式上传至svn，完成时间为当周周日工作结束之前， 由专门负责人进行提醒安排（李路为负责人）。 4.由小组制定的工作计划和安排不可私自更改，每个负责人有制定的任 务，若有问题和异议需及时向领导反映和声明，并根据客观条件进行工 作调整。 5.小组内部组织技术评审、会议等应由负责人提前30分钟通知参加人员， 与会人员应及时根据自身工作安排协调。 6.组内人员请假应由本人向领导申请，不得由他人代申请。 7.组内人员讨论问题的时间控制在10分钟之内，若需长时间的问题探究 应安排至洽谈室进行内部讨论。 8.与其他部门工作人员之间的协调，要有及时的结果信息反馈，对于长时 间未得结果的工作问题，应由相应的负责人员进行催促和问询。 9.对于其他部门所安排的工作任务，应统一由杨工进行任务分配，不可私 自认领工作内容。
10.小组新成员的培训内容包括两方面：工作制度的培训和代码开发规范的 培训（js,java，数据库开发规范） 【个人规范】 1.对于svn中组内成员所总结的会议记录、评审日志、培训记录等文档， 应注意查看和学习。 2.每日工作前，要对自己当天的工作有一个详细的计划和安排，认真梳理 工作步骤，按照自身安排有序开展工作内容。 3.编码之前要做好沟通工作，明确自己所要完成的功能方向，以免盲目编 码，理解偏差，导致最终返工，降低工作效率。 4. 程序的思考过程远远重要于对程序的编写过程，程序员的能力主要体现 在思维能力，不要仅局限于对某项技术的表面使用上，要学会站在一定 的高度上思考、分析、解决问题，并在具体实践中验证和修正这些思想 与方式，最终达到程序员自身的完善。 5 所编程序的扩展性要强，构思和编写过程应遵循设计模式的六大原则：单 一职责原则（Single Responsibility Principle）、里氏替换原则（Liskov Substitution Principle）、依赖倒置原则（Dependence Inversion Principle）、接口隔离原则（Interface Segregation Principle）、迪米 特法则（Law Of Demeter）、开闭原则（Open Close Principle） 6. 拓展数据库知识，从项目执行性能和效率角度加强数据库优化。 7. 扩充自身知识面，作为技术人员应对自身专业知识外的领域多了解，以 应对实际的客户需求。 【团队规范】
华为软件开发行为规范
软件开发行为规范 第一版 深圳市华为技术有限公司 版权所有不得复制
软件开发行为规范 (第一版） 为了把公司已经发布的软件开发过程规范有效地运作于产品开发活动中，把各种规范“逐步形成工程师的作业规范”，特制定本软件开发行为规范，以达到过程控制的目的。 与软件开发相关的所有人员，包括各级经理和工程师都必须遵守本软件开发行为规范。对违反规范的开发行为，必须按照有关管理规定进行处罚。 本软件开发行为规范的内容包括：软件需求分析、软件项目计划、概要设计、详细设计、编码、需求管理、配置管理、软件质量保证、数据度量和分析等。 本软件开发行为规范，采用以下的术语描述： ★规则：在软件开发过程中强制必须遵守的行为规范。 ★建议：软件开发过程中必须加以考虑的行为规范。 ★说明：对此规则或建议进行必要的解释。 ★示例：对此规则或建议从正或反两个方面给出例子。 本软件开发过程行为规范由研究技术管理处负责解释和维护。 研究技术管理处
目录 1 软件需求分析 5 2 软件项目计划9 3 概要设计11 4 详细设计14 5 编码18 6 需求管理19 7 软件配置管理21 8 软件质量保证23 9 数据度量和分析25
1 软件需求分析 1-1：软件需求分析必须在产品需求规格的基础上进行，并保证完全实现产品需求规格的定义。 1-2：当产品的需求规格发生变更时，必须修订软件需求规格文档。软件需求规格的变更必须经过评审，并保存评审记录。 1-3：必须对软件需求规格文档进行正规检视。 1-4：软件需求分析过程活动结束前，必须经过评审，并保存评审记录。 1-5：在对软件需求规格文档的正规检视或评审时，必须检查软件需求规格文档中需求的清晰性、完备性、兼容性、一致性、正确性、可行性、易修改性、健壮性、易追溯性、易理解性、易测试性和可验证性、性能、功能、接口、数据、可维护性等内容。 说明：参考建议1-1到1-16。 1-1：采用以下检查表检查软件需求规格文档中需求的清晰性。 1-2：采用以下检查表检查软件需求规格文档中需求的完备性。
软件开发工作规范章程
软件开发工作规范章程 Document serial number【KK89K-LLS98YT-SS8CB-SSUT-SST108】
软件开发工作规范章程 编写目的 本文档是开发团队的日常工作规范，主要侧重开发工作流程的控制，明确软件工程的各阶段开发团队应完成的工作。开发技术和策略等问题不在本文档描述范围内。开发团队构成 1.1职责 肩负着如下责任： 负责开发项目的系统分析、研发与组织实施。 负责开发符合要求的软件。 制定软件开发规范。 协助相关应用软件的安装调试工作。 1.2角色划分 在人力资源有限的情况下，一个团队成员可能会同时承担多个角色。 角色名称相关主要责任 开发组长负责研发团队建设 负责研发项目的工作分工、实施、监控及后续完善工作 参与确定研发产品的种类，并制定研发产品的相关标准及研发工作计划 负责技术路线与方向 完成研发过程中的其他任务 超出能力权限向上一级汇报 根据项目情况，向所属组制定技能提升计划并实施 特性负责人负责研发特性的工作分工、实施、监控及后续完善工作 制定特性的软件开发技术规范及研发工作计划
负责《详细设计》的编写。 按期、按预算交付高质量的产品 建设有凝聚力团队环境，并促使高效的团队协作 负责软件实施规范执行 根据开发规范实施开发工作 软件的程序设计、代码编写与单元测试。 协助《详细设计》的编写。 承担开发任务，按计划完成任务目标。 配合系统分析人员完成软件系统以及模块的需求调 研、需求分析。 协助测试人员完成软件系统及模块的测试。 1.3需求澄清 1.4编码阶段 1.4.1开发规范
1.4.2开发环境准备 1.4.3详细设计 1.4.4编码
软件开发标准化工作流程V10
目录 软件开发标准化工作流程 1引言 1.1编写目的 说明编写这份软件开发标准化工作流程的目的，指出预期的读者。 1.2适用范围 互联网开发中心所有项目。 1.3定义 列出本文件中用到的专门术语的定义、外文首字母组词的原词组。
1.4流程图 2需求调研 2.1概述 需求调研对于一个应用软件开发来说，是一个系统开发的开始阶段，需求调研的质量对于一个应用软件来说，是一个极其重要的阶段，它的质量在一定程度上来说决定了一个软件的交付结果。怎样从客户中听取用户需求、分析用户需求就成为调研人员最重要的任务。
2.2需求调研 总体而言，需求调研可按照业务流程、业务规则、表单数据、贯穿系统的关系四个方向来进行调研。 ●业务规则 各个流程、功能点等事项的办理，都会有相关约束或条件，那么需要对其前置条件、后置条件、数据验证、条件判断等进行分析调研。调研对象一般为操作员。 ●表单数据 对各个功能点的业务数据、数据项、表单格式、查询条件以及其它相关数据进行明确的分析调研。调研对象一般为操作员。 ●贯穿系统的关系 各个模块或科室之间的数据交换、传递以及数据共享等，需要我们调研人员与各个模块或科室的相关负责人进行多方沟通，确定一个多方满意的需求调研结果。 2.3注意事项 ●调研过程中，用户说的很快，不可能等我们全部记录之后， 再讲下一个问题。因此，只能在笔记本上速记，有时只能记录1、2个关键字。因此，每天调研结束之后，当天晚上必须整理当天的调研情况，写成一份调研日记。整理当天的调研记录时，还要整理出待明确的问题，下一次再找机会与用户再沟通、确认。
●调研的各个阶段，必须出具相关文档或文件，比如调研计划、 流程图、表单样式、报表格式、背景图片、数据项列表、讨论记录、问题列表等。 ●所有疑问必须等到明确的答复，不能出现相互矛盾、似是而 非的需求。需准确理解客户的讲解，如果有问题的先做记录，之后将整理的问题向客户询问，得到明确的结果。需求必须是客户接受和确认的，不能有臆测的需求。 ●要合理安排好时间和进度。有时候客户还有自己要做的事情， 不一定能及时相应。所以必须提前预约好时间，保证整个需求调研的进度。 ●能积极引导客户。当客户出现疑虑，而调研人员能明白且能 做好客户想要的东西的时候，调研人员能及时积极引导客户，详细讲解我们所知道的东西，并能让客户接受与确认。 ●如遇公司有相关原型或产品，调研人员需先详细了解公司的 相关原型和产品，根据成品，找出本地化的差异化需求。 3可行性分析 这个阶段要回答的关键问题：“对于上一个阶段所确定的问题有行得通的解决办法吗？”为了回答这个问题，系统分析员需要进行一次大大压缩和简化了的系统分析和设计的过程，也就是在较抽象的高层次上进行的分析和设计的过程。 可行性研究应该比较简短，这个阶段的任务不是具体解决
软件详细设计说明书
软件详细设计说明书 编号?______ 版本?______ 软件详细设计说明书 项目名称：精确化管理系统 委托单位：铁岭消防局 承办单位：启馨科技 : : : : 启馨科技 1.引言 1.1目的 编写详细设计说明书是软件开发过程必不可少的部分，其目的是为了使开发人员在完成概要设计说明书的基础 上完成概要设计规定的各项模块的具体实现的设计工作。 1.2背景 一、软件名称 精确化管理系统 二、相关单位 委托单位?铁岭市消防局 承办单位?铁岭启馨科技 2.总体设计 2.1软件描述
精确化管理系统可实现精确管理、日常管理、安全管理、制度管理、设施管理、兵员管理、量化管理、战勤保 障、系统管理及各功能的录入、修改、查询及打印。采用B/S的软件体系结构，服务器采WINDOWS/NT/2000， SQLSERVER。客户端采用WINDOWS/NT/2000/XP,浏览器采用IE6.0。 2.2设计方法 本软件采用传统的软件开发生命周期的方法，采用自顶向下，逐步求精的结构化的软件设计方法 2.3软件结构 1、总体结构 2 启馨科技 精 确 化 管 理 系 统 精 确制设兵量战系 管度施员化勤统日安理管管管管保管常全理理理理障理管管理理 精机基
确关层骨三行内办合会日要计专投派兵查士请报量量量报装士装装配大查预车报用权化管管议常事划项车干无政外公同员询兵消化化化备兵备备队辆户限管理理票记管日类活申队竞责部设制增证假表分考标表分装入库发仓询警装表管管理百百录理记动请赛伍任管施管加修打管类核准类备库存库备理理模分分理建事理安删改印理管查管式制制设故制排除理询理度报安表放 2.4 2.4.1精确管理模块 （1）精确化管理模式 3 启馨科技 以图片和文字相结合的形式展现给大家，内容主要是队内的相关制度标准，对外对内达到公平，公正，公开的 目的。 （2）机关管理百分制 （3）基层管理百分制 2.4.2日常管理模块 （1）会议记录 记录会议的主要内容及主要精神等，以方便快捷的方式将开会内容及精神，很好的传达到每个人。（2）日常生活 1.起床 中队值班班长提前十分钟起床向中队值勤队长（分别由正、副中队长、正副指导员轮流担任但必
软件开发工作规范章程
软件开发工作规范章程 1编写目的 本文档是开发团队的日常工作规范，主要侧重开发工作流程的控制，明确软件工程的各阶段开发团队应完成的工作。开发技术和策略等问题不在本文档描述范围内。 2开发团队构成 2.1职责 肩负着如下责任： 负责开发项目的系统分析、研发与组织实施。 负责开发符合要求的软件。 制定软件开发规范。 协助相关应用软件的安装调试工作。 2.2角色划分 在人力资源有限的情况下，一个团队成员可能会同时承担多个角色。 角色名称相关主要责任 开发组长负责研发团队建设 负责研发项目的工作分工、实施、监控及后续完善工作 参与确定研发产品的种类，并制定研发产品的相关标准及研发工作计划 负责技术路线与方向 完成研发过程中的其他任务 超出能力权限向上一级汇报 根据项目情况，向所属组制定技能提升计划并实施 特性负责人负责研发特性的工作分工、实施、监控及后续完善工作制定特性的软件开发技术规范及研发工作计划 负责《详细设计》的编写。
按期、按预算交付高质量的产品 建设有凝聚力团队环境，并促使高效的团队协作 负责软件实施规范执行 根据开发规范实施开发工作 软件的程序设计、代码编写与单元测试。 协助《详细设计》的编写。 承担开发任务，按计划完成任务目标。 配合系统分析人员完成软件系统以及模块的需求调研、需 求分析。 协助测试人员完成软件系统及模块的测试。 3工作流程及规范 3.1需求澄清 3.2编码阶段 3.2.1开发规范
3.2.2开发环境准备 3.2.3详细设计 3.2.4编码
3.2.5单元测试 3.2.6代码走查 3.2.7持续集成测试 3.3交付测试
软件开发文档规范标准[详]
附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.1 编写目的 为了把公司已经发布的软件开发过程规范有效地运作于产品开发活动中，把各种规范“逐步形成工程师的作业规范”，特制定本软件开发行为规范，以到达提高系统质量的目的。在本规范中，阐述了基本的开发模式，包括需求验证、设计、编码规范、代码审查、单元测试、配置管理等，并明确开发过程中的方法、策略、工具以及环境要求，开发人员都必须遵守本软件开发规范。 1.2 读者对象 本规范读者对象为软件开发项目管理者、项目经理、开发组 2需求评审 2.1过程要求 按软件开发过程经验，问题暴露越早越好。因此，在实施设计和编码前，需对项目经理提供的需求说明文档进行充分的验证，在不明确的需求点上，需要和项目经理进一步核实，确保对每个需求点有清晰、一致的认识和理解。 在需求验证的过程中，需按以下检查点进行逐项检查（包括不限于）： 1.所有定义、实现方法是否清楚地表达了用户的原始要求？ 2.是否清楚、明确地描述了所有的功能？是否没有不能理解或造成误解的 描述？ 3.需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有
需求？ 4.需求是否可以验证（即是否可以检验软件是否满足了需求）？ 5.是否有术语定义一览表？ 6.是否标识并定义了在将来可能会变化的需求？ 7.各个需求之间是否一致？是否有冲突和矛盾？ 8.是否定义了系统所有的输入、输出及其来源？主要为客户或者其他外部 接口，是否明确定义了输入参数和输出参数？ 9.是否说明了如何进行系统输入的合法性检查？ 10.功能性需求是否覆盖了所有非正常情况的处理？ 11.对异常数据产生的结果是否作了精确的描述？ 12.是否充分定义了关于人机界面的需求？ 13.在不同情况下，是否规定了系统的响应时间？ 14.界面需求是否使软硬件系统具有兼容性？ 15.是否有对相关日志做明确要求？以满足稽核相关的需要。 针对开发过程中的需求变更，以上需求验证点同样适用，并同时评估需求变更给当前项目的设计和开发带来的风险，包括架构、安全、进度等方面，以便项目经理进行计划调整和安排。 2.2工具及环境 1.在此过程中，使用Excel对以上检查点进行跟踪和标记。记录文档需check-in 到svn. 2. 评审完成的需求文档需check-in到svn。 3.任何需求变更文档需check-in到svn。
软件开发管理办法
软件开发管理办法 第一章总则 第一条为规范公司的开发管理流程，使各开发项目的管理进行标准化管理，特制定本管理办法。 第二条本管理办法详细规定软件开发程的各个阶段及每一阶段的任务、要求、交付文件，使整个软件开发过程阶段清晰、要求明确、任务具体，实现软件开发过程的标准化。 第三条本管理办法适用于计算机的自主软件开发项目。适用对象：软件开发管理人员，软件开发人员，软件维护人员，系统管理人员。 第二章组织机构与职责 第四条软件开发管理人员职责： 第五条软件开发人员职责： 第六条软件维护人员职责： 第七条系统管理人员职责： 第三章软件开发环境管理 第八条软件建设环境根据项目不同的时期，需要搭建生产运行环境、系统测试环境、系统开发环境三种不同的软硬件网络环境，便于生产、开发、测试等工作的安全、顺畅的进行。 第九条生产环境为系统维护管理人间管理的范畴，是系统正式运行，提交给各业务科室的正式环境，包括系统运行的硬件、网络等设备和进行集群处理的软件系统。 第十条测试环境为测试人员提供功能测试、性能测试的运行环境，包括运行环境模拟、测试工具服务器、测试工具客户端。 第十一条开发环境为系统开发人员提供系统开发需要的软件硬件环境，包括数据库服务器、应用服务器、开发工具客户端。 第十二条生产环境、测试环境、开发环境都存在自己独立的数据库服务器、应用服务器、客户端。在开发环境完成内部测试后，提交发布版本到测试环境中，由专门的测试人
员进行集成测试和功能测试。并进行一定的压力性能测试。在测试环境通过的版本在发布到生产环境。 第十三条生产环境与测试环境、开发环境需要物理隔离，保障生产环境的安全。 第四章开发过程管理 第十四条项目开发流程根据软件工程的流程，分为可行性研究与计划、需求分析、总计设计、详细设计、代码开发、系统测试五个阶段。 第十五条可行性研究与计划 1实施要求 1.软件开发部分析人员进行市场调查与分析，确认软件的市场需求 2.在调查研究的基础上进行可行性研究，写出可行性报告 3.评审和审批，决定项目取消或继续 4.若项目可行，制订初步的软件开发计划，建立项目日志 5.根据市场环境、公司软硬件情况预测十大风险因素 2交付文档 1.可行性研究报告* 2.初步的软件开发计划 3.十大风险列表* 4.软件项目日志* 第十六条需求分析 1实施要求 1.调查被开发软件的环境 2.软件开发提出的需求进行分析并给出详细的功能定义 3.做出简单的用户原型，与用户共同研究，直到用户满意 4.对可利用的资源（计算机硬件、软件、人力等）进行估计，制定项目进度计划（可 有相应的缓冲时间） 5.制定详细的软件开发计划 6.测试人员制订质量控制计划和测试计划 7.编写初步的用户手册 8.进行需求方案评审 2交付文档 1.软件需求说明书 2.更新后的软件开发计划 3.项目进度计划 4.计划
GB8567-88软件开发主要文档编写规范
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. 输入说明。系统的输入包括数据 的来源、类型、数量、数据的组织以及提供的频
软件开发项目规范
软件项目开发和管理规范 本文阐述软件项目开发和管理的流程规范，作为软件项目开发的高级指引，本规范定义了软件开发的各个阶段以及每个阶段的工作活动和工件，但不对活动和工件的细节作过多规定。在项目开发过程中，每个项目根据自身的需要确定这些活动和工件的细节。 项目阶段 图2-1 项目开发的五个阶段 ?启动阶段 这个阶段的工作目的是决定一个项目是否需要启动。为了达到这个目的，首先要明确项目的总体战略目标，对项目的需要建立认同。即确定到底需要做什么、开发什么产品或提供什么服务，以及需要解决什么样的问题和需要满足客户或市场的什么要求等，同时还要总结项目工作的范围、所需资源、大约开支、各种风险，以及该项目不执行的其他替代选择等。这些代表了对整个项目目标从战略角度和宏观层次所进行的分析，通过项目的意向书总结出来，由此确证客户或项目发起人和赞助者的要求与期望，并帮助他们判定项目是否上马。项目意向总结书的通过及项目被批准上马形成了这个项目的起始点。 ?计划阶段 这个阶段的工作是为整个项目做计划。项目开始后，首先要确定项目的具体范围，明确定出项目到底要做什么，总结、归纳并定出产品的功能。然后进一步制定项目的计划，列出每项具体工作，并建立所有工作任务的重要性及顺序；确定每项工作的执行人和所需资源；根据人员的配置和能力设定各项工作和整个项目的完成时间表。 ?执行阶段 这个阶段的工作是通过执行项目的计划来完成项目的任务。它包括落实一切所需资源，如：
人员、设备、费用、技术、信息，由管理者领导全体项目参与者开展各项工作。同时跟踪各项具体工作和整个项目的进度，定期向全体项目人员及项目的发起人报告项目状态。 ?控制阶段 这个阶段的工作是确证项目工作的结果符合项目的计划。它通过对项目结果的衡量和审核，与项目计划所期望的结果进行比较，找出实际结果与计划的差别，并制定处理措施。这个阶段的工作还包括对项目进程中出现的任何更改要求进行审核和批准。同时调解项目进程中出现的各种问题，如：对缺乏的资源的补偿调节；对项目的进度表及各项具体工作的优先级或顺序的修订。 ?结束阶段 这个阶段的工作是确保项目的最终结果或提交物达到计划的要求，并对完成的结果作可接受的确认。还包括在项目完成之后的收尾工作，对整个项目的经历进行总结，修订项目文档，用户培训等。 阶段完成标志 在项目开发过程中，当一个阶段完成后才会开展下一个阶段的工作；另外，“某个阶段完成”通常被定义为项目的一个里程碑，里程碑标识了项目的进度，它是项目开发和控制的重要参考，对整个项目有重要的意义。因此，“确证某个阶段是否已经完成”的工作非常有重要。 ?每一个阶段的结束以它特定任务的完成为象征 只有当某个阶段中被规定的所有工作任务都完成了，这个阶段才算真正结束，整个项目才可以进入到下一个阶段中去。反过来说，要是阶段中某个任务没有全部完成，按照项目的定义，整个阶段就不能算是完成，因此项目就不能进入到下一个阶段去。 ?衡量阶段结束的工作结果必须是实在的交付品 阶段中的任务是否完成是透过任务活动中产生的交付品来体现的，交付品必须是可交付的、非抽象的、实质的并且可以通过用衡量的方法来判断是否真正地完成了的具体事物。如：某一阶段的完成是以建造一个样品或完成某分文件作为象征。任何项目阶段的结束，都应该有这样的实质性东西的完成作为象征。 ?跨阶段的进程以阶段结尾的合格验证和审核来决定 当一个阶段结束时，在进入到下一个阶段之前所需要做的工作应包括对交付品进行合格验证，并检查这一阶段的工作质量和效率，由此判断是否可以进入到下一个阶段。这些检验象征了一个阶段的结尾终点，表示项目的进程离开了上一个阶段而进入了下一个阶段。 启动阶段