软件项目管理制度
软件项目管理制度
公司
目 录
4一、总述
、 项目管理办公室职责
、 项目经理职责
、 项目管理范围
6二、项目计划
6三、项目组织
7四、过程管理
、软件开发规范
、命名体系
、编码风格
、界面风格
、版本控制
、通用约束
、开发方法
、开发流程
、交流制度
、代码标准化管理
、备份制度
、文档管理
、项目交付管理
、项目归档管理
、任务分解与分目标制定
、进度检查与绩效考评
、考评原则
、考评标准
、考评矩阵
、应对一些突发事件（协调与调整）
、与干系人共享信息
15五、项目经理绩效考核
、考核总则
、执行步骤
、考核指标模板
、级别划分
18附录4-1项目开发计划
20附录4-2软件需求说明书
22附录4-3详细设计说明书
24附录4-4 用户手册
27附录4-5数据要求说明书
29附录4-6项目开发总结报告
31附录5-1 JAVA编码规范
37附录5-2 应用结构定义与命名规范
37附录5-3 数据库对象命名规范
一、总述
项目管理办公室是公司所有项目的最高管理机构，对公司所有处于项目生命周期内的项目结果负责。
项目经理在项目管理办公室指导下，负责确保项目目标的实现，领导项目团队准时、优质地完成项目生命周期内全部工作。
项目管理办公室职责
1.制定内部项目管理规范，支持组织级项目管理平台的日常运作和改进。
2协助规划、组织和推进公司内部的过程持续改进工作。
3项目的过程和产品质量保证，内部审计、跟踪过程缺陷直至解决、参与技术评审。
4为所有项目提供过程咨询和指导、负责项目过程数据的采集和分析。
5通过组织级的项目视图和分析，给高层领导及时汇报项目信息并提供决策支持。
6负责项目经理的培训、委派、监督和考核以及项目资源分配与回收。
项目经理职责
项目经理的工作职责主要包括项目计划，项目成员组织、领导，项目整体控制。
1计划
项目范围、项目质量、项目时间、项目成本的确认；
项目过程/活动的标准化、规范化；
根据项目范围、质量、时间与成本的综合因素的考虑，进行项目的总体规划与阶段计划；
各项计划得到上级领导、客户方及项目组成员认可。
2组织
组织项目所需的各项资源；
设置项目组中的各种角色，并分配好各角色的责任与权限；
定制项目组内外的沟通计划；
安排组内需求分析师、客户联系人等角色与客户的沟通与交流；
处理项目组与其它项目干系人之间的关系；
处理项目组内各角色之间的关系、处理项目组内各成员之间的关系；
安排客户培训工作。
3领导
保证项目组目标明确且理解一致；
创建项目组的开发环境及氛围，在项目范围内保证项目组成员不受项目其它方面的影响；
提升项目组士气，加强项目组凝聚力；
合理安排项目组各成员的工作，使各成员工作都能达到一定的饱满度；
制定项目组需要的招聘或培训人员的计划；
定期组织项目组成员进行相关技术培训以及与项目相关的行业培训等；
及时发现项目组中出现的问题；
及时处理项目组中出现的问题。
4控制
保证项目在预算成本范围内按规定的质量和进度达到项目目标；
在项目生命周期的各个阶段，跟踪、检查项目组成员的工作质量；
定期向领导汇报项目工作进度以及项目开发过程中的难题；
对项目进行配置管理与规划；
控制项目组各成员的工作进度，及时了解项目组成员的工作情况，并快速解决难题；
不定期组织项目组成员进行项目以外的短期活动，以培养团队精神。
项目管理范围
项目管理覆盖整个项目生命周期，管理制度就是落实到管理过程中的一些基本要素，这里我们将其概括为三项基本业务：
1项目计划
指明要取得的各种结果
指定进度表
估计所需资源
2项目组织
落实项目体系中的角色配置与角色的职责
3过程管理
约束
任务分解与分目标制定
进度检查与质量评估
应对一些突发事件（协调与调整）
与有利害关系的人共享信息
二、项目计划
项目计划的结果体现为“项目开发计划”书面形式，其中要对开发过程中各项工作的负责人、开发进度、进度衡量的标准、完成进度所需经费预算以及所需软、硬件条件等问题详尽的罗列出来，以便根据本计划开展和检查本项目的开发工作。附录4-1给出计划书模板。
三、项目组织
项目组织包括项目角色定义、角色责任定义、角色间关系定义。角色定义是根据项目需求配置（调配、招聘）具备相应素质与能力的成员。角色责任定义就是将具体的任务分解到每个角色；角色间关系定义指明报告与检查体系；一般情况下为三级组织：
业务与商务协调组（商务洽谈、目标与进度及资源定义与落实调整）
项目经理
开发组
系统支持组
负责主机、网络、应用支撑软件的安装调试
开发经理
系统架构组
负责系统的体系结构与应用框架设计
详细设计组
落实到具体语言的功能实现
质量控制组（负责功能、性能、可用性、可维护性、稳定性、压力测试）
质量经理
业务与商务协调组一般由客我双方成员共同组成，负责项目的总体需求、总体目标、里程碑，关键技术路径定义。在制定项目总体目标、里程碑定义与关键技术路径时候要与开发经理联合统筹，并以项目经理意见为主。
开发组的责任人是开发经理，系统体系结构与框架由开发经理与开发组主力程序员联合统筹，并以开发经理意见为主，具体功能实现一般以主力程序员（系统分析员、高级程序员）意见为主。“系统支持”属于临时调配，很可能是外部资源，但工作质量由开发经理检查。
质量控制由质量经理、开发经理、项目经理联合统筹，以质量经理意见为主。
整个项目生命周期中一般角色责任定义如下：
四、过程管理
、软件开发规范
这里只是给出我司软件开发必须遵从的原则，具体内容应该由项目经理或开发经理根据具体项目制定详尽约定。在罗列规范之前，开发组织（团队）必须遵从一个最基本的约定——统一开发环境：
OS:操作系统;
IDE：集成开发工具;
DEBUG：调试工具;
SC：源代码控制器；
IM:即时交流工具；
DD:文档工具（计划，任务，报告）；
ASM:间接交流工具，一般以mail为主。
另外还要为团队固定一些一些角色，builder / Server administrator（dba&osa）。
严格区分开发平台与生产平台之间的界限（安全、测试、性能）
、命名体系
A) 数据库与数据库对象命名;
B) 开发语言的元素命名(类、对象、文件、命名空间、组件、函数、方法等)；
C) 页面与页面元素命名.
D) 文件目录体系
、编码风格
缩进、换行、块大小、文件大小、注释
、界面风格
组件类别、大小、前景、背景、字体、鼠标敏感、边框、布局
、版本控制
创建权限、创建分之权限、更新频度、提交准则。
、通用约束
向导设置、数据校验、提示信息、响应时间与响应方式
、开发方法
鉴于用户需求的不容易澄清性与变动频繁这一特点，所有项目均采用迭代开发方法。这就是说不要指望在明确的需求调研阶段能把问题搞清楚，弄清楚个大概即可，以不超过两周的迭代间隔快速的交互原型，以便反馈更进一步的需求、这样一步步逼近用户的真实想法。这里要特别强调的是多与用户交流，项目组内有关设计方法与策略也要频繁地交流。
、开发流程
纯粹从开发的角度我们将项目周期划分为两个阶段，每个阶段要完成的的如下：
、交流制度
项目组每周至少要进行不少于两次的集体交流，否则就是开发经理或项目经理失职（交流不限制时间长短、方式、内容可以从需要到设计到实现、甚至是抱怨）。
、代码标准化管理
小组内成员必须开展互测，项目经理要督促进行。如果一般性的缺陷被质量组测试发现，项目经理可以作出警告、取消休假、扣发奖金等处理措施。项目经理或开发经理可抽查成员代码，对比规范作出人员基本技术素养评测，计入期末（项目结束）考核（去留）。
、备份制度
应用系统的所有资料[代码（程序、脚本块、数据库脚本）、文档、数据]，除了数据以外，全部纳入源代码控制系统。数据每天备份一次[媒介是磁盘]，代码（程序脚本、数据库脚本）、文档每周一次[媒介是磁盘]，所有信息每月备份一次[媒介是光盘]。
、文档管理
没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介；开发团队更需要编制易于阅读的文挡，来对系统及其设计决策的依据进行描述。
然而，过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间，并且要使这些文档和代码保持同步：就要花费更多的时间。如果文档和代码之间失去同步，那么文档就会变成庞大的、复杂的谎言．会造成重大的误导；
对于团队来说，编写并维护一份系统原理和结构方而的文挡将总是一个好主慝，但是那份文档应该是短小、突出主题的。为此我们拟定所有项目都必须编制以下文档。
1《项目开发计划书》，模板见附录4-1
2《软件需求说明书》，模板见附录4-2
3《详细设计说明书》，模板见附录4-3
4《用户手册》，模板见附录4-4
5《数据库需求说明》，模板见附录4-5
6《项目开发总结报告》，模板见附录4-6
、项目交付管理
软件交付[应用，源代码]
文档交付[视技术合同要求交付的内容而定]
运行维护技术交付：系统、数据库、应用的日常管理与维护。
系统安全性交付：操作系统管理与应用账号、数据库管理与应用开发账号、应用服务器的管理与应用开发账号。
、项目归档管理
项目执行过程的所有资料[程序、脚本、数据、文档]以光盘作媒介，并附上资料清单，交给公司PMO。
、任务分解与分目标制定
组织中的负责人负责具体的任务分解并落实到组织中的每个人。形式如下：
软件开发任务单
项目名称： 任务编号____________
子项名称
按“子系统→模块→功能”最多三级划分
功能描述
技术要求
复杂度
（业务与技术两个层次）
任务发出人
任务承接人
限时开始
yyyy/MMdd
限时结束
yyyy/MMdd
考核标准（百分制）
分值
考评项目
30
1、时效性：（是否按时完成）
40
2、客户关注点：（功能、可靠性、易用性、高效性、可维护性、可移植性）表现如何
10
3、规范与标准
5
4、复用与创新
8
5、团队精神
2
6、奉献精神
5
7、沟通精神
、进度检查与绩效考评
、考评原则
软件开发人员的绩效考评是所有软件公司都深感棘手但又必须面对的问题。棘手的原因是既不能进行计时处理、也不能进行计件处理。计时会造成出工不出力，计件（一般按代码条数）会挫伤优秀软件人员的积极性（同样实现一个功能，差的软件人员成百上千行，而优秀软件人员只有几十行，且好用）。但是只要尊重一些必要的原则，还是能够加以评估的。这里提出六条原则：
1被考核对象必须有明确的任务
项目经理或开发经理必须发出明确的任务书：任务书中指定任务名称、任务内容、完成时限之、考核标准、向谁负责、任务的难易程度（业务与技术两个方面）。难易程度由项目组成员集体评价。没有明确的任务当然就无法考评（见表4-2）。
2考评标准要综合计量量与非计量量。
计量量如：完成时间、完成了对少功能、测试出多少缺陷等，非计量量如：用户接受程度如何、项目组合作情况如何等等，要将这些因素综合考虑。
3要体现多劳多得、奖勤罚懒。
高效、高质完成任务的人员必须得到区别对待（调资、休假、奖金）。
4考评结果要及时与被考评对象沟通，容许争议协调。
5考评时间不得跨度太大，一般为两周一次，不符合这种周期的，项目经理与开发经理需要适当对任务做进一步分解。
6被考评要提供周报月报之类的内容，但不作为考评的依据。我们只注重结果，也就是说根据结果认定过程。
、考评标准
1时效性：
不管是承揽项目还是产品研发都有一定的时间限定，愈期就意味着成本增加甚至是失败。所以能否按时完成任务是绩效考评的一个重要标致。
2客户关注点
客户关注点也就是软件的品质，涉及的内容很多，按国家标准分为六个层面，即：功能、可靠性、易用性、高效性、可维护性、可移植性。这六个项目的次序也就是我们考察的顺序，首先必须完成功能，然后再衡量功能是否可靠，再然后才其他几个方面，如果以百分制来衡量，这六个指标的比例大致是50,25,15,10,5,5。也就是说必须保证前四项。而功能、可靠性又是重中之重75%。
3规范与标准
不以规矩不能成方园，不遵从标准的与规范的设计开发必将造成巨大的维护成本与技术积累成本，同时也给软件交流与究错设置障碍，所以必须强调规范化与标准化。
4复用与创新性
这是软件开发人员设计与开发综合能力的一个集中体现。
5团队精神
没有团队精神的软件开发人员坚决辞退：开发过程中团队精神主要表现在：
对测试出的问题是互相推委，还是协商解决；
接口设计各行其事还是共同制订；
发现他人犯错是善意提醒还是沉默不语；
不注重版本管理。
6奉献精神
任务比较紧张时候，是否不计较个人得失主动加班加点赶任务。
7沟通精神
不懂问题是拖延时间还是主动寻求帮助，技术经验是否主动分享。
、考评矩阵
开发人员当期任务评测表
任务书编号：
项目
指标
时效率
按时
未按时
X%(X=100)
完成
未完成
X%
Y%
客户关注点
功能
可靠
易用
性能
维护
移植
功能
可靠
易用
性能
维护
移植
A≤50%
B≤25%
C≤15%
D≤10%
E≤5%
F≤5%
A≤50%
B≤25%
C≤15%
D≤10%
E≤5%
F≤5%
规范与标准
好
中
差
G≥6
G≤4
G=0
复用与创新性
好
中
差
H≥3
H≤2
H=0
团队精神
好
中
差
I≥5
I≤4
I∈0→2
奉献精神
好
中
差
J∈→
J=
J=
沟通精神
好
中
差
K≥3
K≤2
K=
记分
(30 + (A+B+C+D+E+F)*40+G+H+I+J+K)*X%
功能：实现的结果是否体现的客户的意图，与客户意图之间的差距（x%）, 功能测评比例(1-x%)*50%
可靠性：主要以测试出的缺陷多少来衡量，如果一个最低级功能被测出超过三个缺陷，可靠性为零。
易用性：重要从数据校验与否、出错提示信息明细程度，输入数据量多少，是否符合输入习惯四个方面进行衡量；
性能：主要是响应速度
可维护性与可移植性要看与规范与标准的差距
、应对一些突发事件（协调与调整）
项目
可能造成的结果
人员流动
招聘、调配、项目延期
突发性需求
商务谈判、项目延期
技术更新
利润损失、技术积累损失、项目延期
法律问题
无法进展
其它
、与干系人共享信息
项目
共享范围
一般信息
共享
核心信息
有限共享
专有信息
不共享
五、项目经理绩效考核
、考核总则
公司对项目经理实行360度绩效考核。项目经理来自项目管理办公室，人力资源部是公司绩效管理机构。
项目管理办公室负责绩效指标的考核，人力资源部侧重能力、素质的评估，项目经理进行自我评价，人力资源部进行总结性评议。为保证绩效评价既重结果又重过程，按评价周期，项目经理的绩效评价分为月度评价和结项评价。
公司在评价过程中力求民主氛围，给项目经理提供充分表述意见及申诉的渠道与环境，并鼓励直言不讳。
、执行步骤
1项目启动前，项目管理办公室与项目经理进行绩效目标、指标的制定与绩效计划沟通；
2项目启动后，根据项目经理绩效指标，分解制定详细的项目月度绩效计划并确定月度中需检查的里程碑事件并备案；
3项目实施、监控及过程改进，项目经理逐周积累过程绩效数据，项目管理办公室进行里程碑事件检查，结果记录在案；
4每月底结束，针对项目月度绩效计划和里程碑事件执行情况等进行360度绩效考核，评价结果直接与绩效工资挂钩，同时制定下个月度的绩效计划并确定里程碑事件，即月度评价；
5项目结束后，根据项目经理的整体绩效指标实现情况并结合月度评价情况展开360度绩效考核，评价结果直接与项目奖金挂钩，奖金在项目结束后的第三个月发放，以便由客户来检验项目成果是否经受住考验，即结项评价；
6根据项目月度和结项评价结果，项目管理办公室和项目经理总结经验教训并制定绩效改进计划。
、考核指标模板
此模板在每一个项目启动前，根据实际项目情况进行实例化，项目管理办公室与项目经理沟通并在双方确认后开始执行，每个项目的考核指标实例允许在项目执行过程中进行变更，前提是考核相关的全部干系人一致同意。
所有的差异比取值都是：10% 30% 50% 80% 100%，共5档。
权重值由1-5组成，由低到高。
类别
一级指标
权重
二级指标
基准值与考核方式
满意度
客户满意度
5
客户每月签署一份满意度调查表
合作者满意度
4
合作者每月签署一份满意度调查表
领导满意度
3
项目控制
项目范围
5
需求获取准确度
初始需求与最终需求差异比
变更控制
月变更次数，变更内容与原始需求差异比
质量
4
风险
4
风险识别率
发现风险的数量
风险控制
风险控制与处理结果
计划
5
进度计划准确率
资源计划准确率
沟通
4
信息传递准确度
信息传递完整度
成本
5
预算与实际投入比例
管理能力
组织能力
4
人员成长度
人员满意度
人员积极性
人员工作效率
领导力
3
任务分配合理性
人员执行力
团队成员平均执行力评价
个人执行力
3
对规范化管理的响应程度
商务能力
新项目发掘
2
及时回款
2
情报收集
2
、级别划分
上一级的能力包含下一级能力。
初级
中级
高级
资深
工作年限
2年+
4年+
6年+
8年+
项目管理工作年限
1年+
3年+
5年+
8年+
项目经验
3小项目+
3中项目+或8小项目+
3大项目+
6大项目+
领导团队成员数量
5人-
10人-
20人+
50人+
计划能力
中
良
优
优
需求控制
中：准确获取
良：控制变更
优：引导客户
优：专家身份，以解决方案控制需求
风险评估与控制
中：发现局部风险
良：发现全部风险
局部处理
优：全部控制并处理
优：全部控制并处理
沟通
良
良
优
优
成本控制
中：制定预算
良：制定精确预算
优：控制成本
优：优化成本结构
潜在项目挖掘
中：情报收集
良：发展内线
优：转化销售
优：客户主动咨询
满意度
中：领导满意
良：客户满意
优：全部直接干系人满意
优：全部扩展干系人满意
人员培养
中：技术提升
良：业务提升
优：转化销售
优：客户主动咨询
客户关系
良：基本认可
优：非常认可
优：非常认可
优：非常认可
技术能力
良
良
良
良
组织能力（团队效率）
中
优
优
优
领导力（团队态度）
中
良
优
优
执行力（效率）
中
良
优
优
附录4-1项目开发计划
编制项目开发计划的目的是用文件的形式，把对于在开发过程中各项工作的负责人员、开发进度、 所需经费预算、所需软、硬件条件等问题作出的安排记载下来，以便根据本计划开展和检查本项目的开发工作。编制内容要求如下：
1 引言
1．1编写目的
说明编写这份项目开发计划的目的，并指出预期的读者。
1．2背景
说明：
a．待开发的软件系统的名称；
b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；
C．该软件系统同其他系统或其他机构的基本的相互来往关系。
1．3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1．4参考资料
列出用得着的参考资料，如：
a．本项目的经核准的计划任务书或合同、上级机关的批文；
b．属于本项目的其他已发表的文件；
C．本文件中各处引用的文件、资料，包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2 项目概述
2．1 工作内容
简要地说明在本项目的开发中须进行的各项主要工作。
2．2主要参加人员
扼要说明参加本项目开发工作的主要人员的情况，包括他们的技术水平。
2．3产品
2．3．1程序
列出需移交给用户的程序的名称、所用的编程语言及存储程序的媒体形式，并通过引用有关文件， 逐项说明其功能和能力。
2．3．2文件
列出需移交给用户的每种文件的名称及内容要点。
2．3．3服务
列出需向用户提供的各项服务，如培训安装、维护和运行支持等，应逐项规定开始日期、所提供支持 的级别和服务的期限。
2．3．4非移交的产品
说明开发集体应向本单位交出但不必向用户移交的产品（文件甚至某些程序）。
2．4验收标准
对于上述这些应交出的产品和服务，逐项说明或引用资料说明验收标准。
2．5完成项目的员迟用限
2．6本计划的批准者和批准日期
3 实施计划
3．1工作任务的分门与人员分工
对于项目开发中需完成的各项工作，从需求分析、设计、实现、测试直到维护，包括文件的编制、审批、打印、分发工作，用户培训工作，软件安装工作等，按层次进行分解，指明每项任务的负责人和参加人员。
3．2 接口人员
说明负责接口工作的人员及他们的职责，包括：
a ．负责本项目同用户的接口人员；
b．负责本项目同本单位各管理机构，如合同计划管理部门、财务部门、质量管理部门等的接口人员；
c．负责本项目同各分合同负责单位的接口人员等。
3．3进度
对于需求分析、设计、编码实现、测试、移交、培训和安装等工作，给出每项工作任务的预。定开始日期、完成日期及所需资源，规定各项工作任务完成的先后顺序以及表征每项工作任务完成的标志性事件（即所谓"里程碑"）。
3．4预算
逐项列出本开发项目所需要的劳务（包括人员的数量和时间）以及经费的预算（包括办公费、差旅费、机时费、资料费、通讯设备和专用设备的租金等）和来源。
3．5关键问题
逐项列出能够影响整个项目成败的关键问题、技术难点和风险，指出这些问题对项目的影响。
4 支持条件
说明为支持本项目的开发所需要的各种条件和设施。
4．1计算机系统支持
逐项列出开发中和运行时所需的计算机系统支持，包括计算机、外围设备、通讯设备、模拟器、编译 （或 汇编）程序、操作系统、数据管理程序包、数据存储能力和测试支持能力等，逐项给出有关到货日期、 使用时间的要求。
4．2需由用户承担的工作
逐项列出需要用户承担的工作和完成期限。包括需由用户提供的条件及提供时间。
4．3由外单位提供的条件
逐项列出需要外单位分合同承包者承担的工作和完成的时间，包括需要由外单位提供的条件和提 供的时间。
5 专题计划要点
说明本项目开发中需制订的各个专题计划（如分合同计划、开发人员培训计划、测试计划、安全保密 计划、质量保证计划、配置管理计划、用户培训计划、系统安装计划等）的要点。
附录4-2软件需求说明书
软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解， 使之成为整个开发工作的基础。编制软件需求说明书的内容要求如下：
1 引言
1．1编写目的
说明编写这份软件需求说明书的目的，指出预期的读者。
1．2背景
说明：
a．待开发的软件系统的名称；
b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；
C．该软件系统同其他系统或其他机构的基本的相互来往关系。
1．3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1．4参考资料
列出用得着的参考资料，如：
a．本项目的经核准的计划任务书或合同、上级机关的批文；
b．属于本项目的其他已发表的文件；
c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2 任务概述
2．1目标
叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|
2．2用户的特点
列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重要约束
2．3假定和约束
列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。
3 需求规定
3．1对功能的规定
用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。
3．2对性能的规定
3．2．1精度
说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。
3．2．2时间特性要求
说明对于该软件的时间特性要求，如对：
a．响应时间；
b．更新处理时间；
c．数据的转换和传送时间；
d．解题时间； 等的要求。
3．2．3灵活性
说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：
a．操作方式上的变化；
b．运行环境的变化；
c．同其他软件的接口的变化；
d．精度和有效时限的变化；
e．计划的变化或改进。
对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
3．3输人输出要求
解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
3．4数据管理能力要求
说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。
3．5故障处理要求
列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
3．6其他专门要求
如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。
4 运行环境规定
4．1设备
列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：
a．处理器型号及内存容量；
b．外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；
c．输入及输出设备的型号和数量，联机或脱机；
d．数据通信设备的型号和数量；
e．功能键及其他专用硬件
4．2支持软件
列出支持软件,包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。
4．3 接口
说明该软件同其他软件之间的接口、数据通信协议等。
4．4控制
说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。
附录4-3详细设计说明书
1 引言
1．1编写目的
说明编写这份详细设计说明书的目的，指出预期的读者。
1．2背景
说明：
a．待开发软件系统的名称；
b．本项目的任务提出者、开发者、用户和运行该程序系统的计算中心。
1．3定义
列出本文件中用到专门术语的定义和外文首字母组词的原词组。
1．4参考资料
列出有关的参考资料，如：
a．本项目的经核准的计划任务书或合同、上级机关的批文；
b．属于本项目的其他已发表的文件；
c．本文件中各处引用到的文件资料，包括所要用到的软件开发标准。 列出这些文件的标题、文件编号、发表日期和出版单位，说明能够取得这些文件的来源。
2 程序系统的结构
用一系列图表列出本程序系统内的每个程序（包括每个模块和子程序）的名称、标识符和它们之间 的层次结构关系。
3 程序1（标识符）设计说明
从本章开始，逐个地给出各个层次中的每个程序的设计考虑。以下给出的提纲是针对一般情况的。 对于一个具体的模块，尤其是层次比较低的模块或子程序，其很多条目的内容往往与它所隶属的上一层 模块的对应条目的内容相同，在这种情况下，只要简单地说明这一点即可。
3．1程序描述
给出对该程序的简要描述，主要说明安排设计本程序的目的意义，并且，还要说明本程序的特点（如 是常驻内存还是非常驻？是否子程序？是可重人的还是不可重人的？有无覆盖要求？是顺序处理还是并发 处理卜…．．等）。
3．2功能
说明该程序应具有的功能，可采用IPO图（即输入一处理一输出图）的形式。
3．3性能
说明对该程序的全部性能要求，包括对精度、灵活性和时间特性的要求。
3．4输人项
给出对每一个输入项的特性，包括名称、标识、数据的类型和格式、数据值的有效范围、输入的方式。 数量和频度、输入媒体、输入数据的来源和安全保密条件等等。
3． 5输出项
给出对每一个输出项的特性，包括名称、标识、数据的类型和格式，数据值的有效范围，输出的形式、 数量和频度，输出媒体、对输出图形及符号的说明、安全保密条件等等。
3．6算法
详细说明本程序所选用的算法，具体的计算公式和计算步骤。
3．7流程逻辑
用图表（例如流程图、判定表等）辅以必要的说明来表示本程序的逻辑流程。
3．8接口
用图的形式说明本程序所隶属的上一层模块及隶属于本程序的下一层模块、子程序，说明参数赋值和调用方式，说明与本程序相直接关联的数据结构（数据库、数据文卷）。
3．9存储分配
根据需要，说明本程序的存储分配。
3．10注释设计
说明准备在本程序中安排的注释，如：
a． 加在模块首部的注释；
b．加在各分枝点处的注释； 对各变量的功能、范围、缺省条件等所加的注释；
d．对使用的逻辑所加的注释等等。
3．11限制条件
说明本程序运行中所受到的限制条件。
3．12测试计划
说明对本程序进行单体测试的计划，包括对测试的技术要求、输入数据、预期结果、进度安排、人员职责、设备条件驱动程序及桩模块等的规定。
3．13尚未解决的问题
说明在本程序的设计中尚未解决而设计者认为在软件完成之前应解决的问题。
4 程序2（标识符）设计说明
用类似3的方式，说明第2个程序乃至第N个程序的设计考虑。
附录4-4 用户手册
1 引言
1．1编写目的
说明编写这份用户手册的目的，指出预期的读者。
1．2背景
说明：
a．这份用户手册所描述的软件系统的名称；
b．该软件项目的任务提出者、开发者、用户（或首批用户）及安装此软件的计算中心。
1．3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1．4参考资料
列出有用的参考资料，如：
a．项目的经核准的计划任务书或合同、上级机关的批文；
b．属于本项目的其他已发表文件；
c．本文件中各处引用的文件、资料，包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够取得这些文件资料的来源。
2 用途
2．1功能
结合本软件的开发目的逐项地说明本软件所具有各项功能以及它们的极限范围。
2．2性能
2．2．1精度
逐项说明对各项输入数据的精度要求和本软件输出数据达到的精度，包括传输中的精度要求。
2．2．2时间特性
定量地说明本软件的时间特性，如响应时间，更新处理时间，数据传输、转换时间，计算时间等。
2．2．3灵活性
说明本软件所具有的灵活性，即当用户需求（如对操作方式、运行环境、结果精度、时间特性等的要求）有某些变化时，本软件的适应能力。
2． 3 安 全保密
说明本软件在安全、保密方面的设计考虑和实际达到的能力。
3 运行环境
3．1 硬设备
列出为运行本软件所要求的硬设备的最小配置，如：
a．处理机的型号、内存容量;
b．所要求的外存储器、媒体、记录格式、设备的型号和台数、联机／脱机；
c． I／O设备（联机／脱机？）；
d．数据传输设备和转换设备的型号、台数。
3．2支持软件
说明为运行本软件所需要的支持软件，如：
a．操作系统的名称、版本号；
b．程序语言的编译／汇编系统的名称和版本号；
c．数据库管理系统的名称和版本号；
d．其他支持软件。
3．3数据结构
列出为支持本软件的运行所需要的数据库或数据文卷。
4 使用过程
在本章，首先用图表的形式说明软件的功能同系统的输入源机构、输出接收机构之间的关系。
4． 1安装与初始化
一步一步地说明为使用本软件而需进行的安装与初始化过程，包括程序的存储形式、安装与初始化过程中的全部操作命令、系统对这些命令的反应与答复。表征安装工作完成的测试实例等。如果有的话，还应说明安装过程中所需用到的专用软件。
4．2输入
规定输入数据和参量的准备要求。
4．2．1输入数据的现实背景
说明输入数据的现实背景，主要是
a．情况--例如人员变动、库存‘缺货；
b．情况出现的频度--例如是周期性的、随机的、一项操作状态的函数．
c．情况来源-一例如人事部门、仓库管理部门；
d．输入媒体---例如键盘、穿孔卡片、磁带；
e．限制--出于安全、保密考虑而对访问这些输入数据所加的限制；
f．质量管理--例如对输入数据合理性的检验以及当输入数据有错误时应采取的措施，如建立出错情况的记录等；
g．支配--例如如何确定输入数据是保留还是废弃，是否要分配给其他的接受者等。
4．2．2输入格式
说明对初始输入数据和参量的格式要求，包括语法规则和有关约定，如：
a．长度-一例如字符数／行，字符数／项；
b．格式基准--例如以左面的边沿为基准；
c．标号--例如标记或标识符；
d．顺序--例如各个数据项的次序及位置；
e．标点--例如用来表示行、数据组等的开始或结束而使用的空格、斜线、星号、字符组等。
f．词汇表--给出允许使用的字符组合的列表，禁止使用＊的字符组合的列表等；
g．省略和重复--给出用来表示输人元素可省略或重复的表示方式；
h．控制--给出用来表示输入开始或结束的控制信息。
H．4．2．3输入举例
为每个完整的输入形式提供样本，包括：
a．控制或首部--例如用来表示输入的种类和类型的信息，标识符输入日期，正文起点和对所用编码的规定；
b．主体--输入数据的主体，包括数据文卷的输入表述部分；
c．尾部--用来表示输入结束的控制信息，累计字符总数等；
d．省略--指出哪些输入数据是可省略的；
e．重复--指出哪些输入数据是重复的。
4．3输出 对每项输出作出说明．
4．3．1输出数据的现实背景，说明输出数据的现实背景，主要是：
a．使用--这些输出数据是给谁的，用来干什么；
b．使用频度--例如每周的、定期的或备查阅的；
c．媒体--打印、CRI显示、磁带、卡片、磁盘，
d．质量管理-一例如关于合理性检验、出错纠正的规定；
e．支配--例如如何确定输出数据是保留还是废弃，是否要分配给其他接受者等。
4．3．2输出格式
给出对每一类输出信息的解释，主要是：
a．首部--如输出数据的标识符，输出日期和输出编号；
b．主体--输出信息的主体，包括分栏标题；
c．尾部--包括累计总数，结束标记。
4．3．3输出举例
为每种输出类型提供例子。对例子中的每一项，说明：
a．定义--每项输出信息的意义和用途；
b．来源--是从特定的输入中抽出、从数据库文卷中取出、或从软件的计算过程中得到
c．特性--输出的值域、计量单位、在什么情况下可缺省等。
4．4文卷查询
这一条的编写针对具有查询能力的软件，内容包括：同数据库查询有关的初始化、准备、及处理所需 要的详细规定，说明查询的能力、方式，所使用的命令和所要求的控制规定。
4．5出错处理和恢复
列出由软件产生的出错编码或条件以及应由用户承担的修改纠正工作。指出为了确保再启动和恢 复的能力，用户必须遵循的处理过程。
4．6终端操作
当软件是在多终端系统上工作时，应编写本条，以说明终端的配置安排、连接步释、数据和参数输入 步骤以及控制规定．说明通过终端操作进行查询、检索、修改数据文卷的能力、语言、过程以及辅助性程 序等。
附录4-5数据要求说明书
1 引言
1．1编写目的
说明编写这份数据要求说明书的目的，指出预期的读者。
1．2背景
说明：
a．待开发软件系统的名称；
b．列出本项目的任务提出者、开发者、用户以及将运行该项软件的计算站（中心）或计算机网络系统。
1．3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1．4参考资料
列出有关的参考资料，如：
a．本项目的经核准的计划任务书或合同，上级机关的批文；
b．属于本项目的其他已发表文件；
c．本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位。说明能够得到这些文件资料的来源。
2 数据的逻辑描述
对数据进行逻辑描述时可把数据分为动态数据和静态数据。所谓静态数据，指在运行过程中主要作 为参考的数据，它们在很长的一段时间内不会变化，一般不随运行而改变。所谓动态数据．包括所有在运 行中要发生变化的数据以及在运行中要输入、输出的数据。进行描述时应把各数据元素逻辑地分成若干 组，列如函数、源数据或对于其应用更为恰当的逻辑分组。给出每一数据元的名称（包括缩写和代码）、定 义（或物理意义）度量单位、值域、格式和类型等有关信息。
2．1静态数据
列出所有作为控制或参考用的静态数据元素。
2．2动态输人数据
列出动态输入数据元素（包括在常规运行中或联机操作中要改变的数据）。
2．3动态输出数据
列出动态输出数据元素（包括在常规运行中或联机操作中要改变的数据）。
2．4内部生成数据
列出向用户或开发单位中的维护调试人员提供的内部生成数据。
2．5数据约定
说明对数据要求的制约。逐条列出对进一步扩充或使用方面的考虑而提出的对数据要求的限制（容 量、文卷、记录和数据元的个数的最大值）。对于在设计和开发中确定是临界性的限制更要明确指出。
3 数据的采集
3．1要求和范围
按数据元的逻辑分组来说明数据采集的要求和范围，指明数据的采集方法，说明数据采集工作的承担者是用户还是开发者。具体的内容包括：
a．输入数据的来源，例如是单个操作员、数据输入站，专业的数据输入公司或它们的一个分组；
b．数据输入（指把数据输入处理系统内部）所用的媒体和硬设备。如果只有指定的输入点的输入才是合法的，则必须对此加以说明；
c．接受者说明输出数据的接受者；
d．输出数据的形式和设备列出输出数据的形式和硬设备。无论接受者将接收到的数据是打印输出，还是CRT上的一组字符、一帧图形，或一声警铃，或向开关线圈提供的一个电脉冲，或常用介质如磁盘、磁带、穿孔卡片等，均应具体说明；
e．数据值的范围给出每一个数据元的合法值的范围；
f．量纲给出数字的度量单位、增量的步长、零点的定标等。在数据是非数字量的情况下，要给出每一种合法值的形式和含意；
g．更新和处理的频度给出预定的对输入数据的更新和处理的频度。如果数据的输入是随机的，应给出更新处理的频度的平均值，或变化情况的某种其他度量。
3．2输人的承担者
说明预定的对数据输入工作的承担者。如果输入数据同某一接口软件有关，还应说明该接口软件的来源。
3．3预处理
对数据的采集和预处理过程提出专门的规定，包括适合应用的数据格式、预定的数据通信媒体和对输入的时间要求等。对于需经模拟转换或数字转换处理的数据量，要给出转换方法和转换因子等有关信息，以便软件系统使用这些数据。
3．4 影响
说明这些数据要求对于设备、软件、用户、开发单位所可能产生的影响，例如要求用户单位增设某个机构等。
附录4-6项目开发总结报告
I 引言
1．1编写目的
说明编写这份项目开发总结报告的目的，指出预期的阅读范围。
1．2背景
说明：
a．本项目的名称和所开发出来的软件系统的名称；
b．此软件的任务提出者、开发者、用户及安装此软件的计算中心。
I．3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1．4参考资料
列出要用到的参考资料，如：
a．本项目的已核准的计划任务书或合同、上级机关的批文；
b．属于本项目的其他已发表的文件；
c．本文件中各处所引用的文件、资料，包括所要用到的软件开发标准。 列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2 实际开发结果
2．1产品
说明最终制成的产品，包括：
a．程序系统中各个程序的名字，它们之间的层次关系，以千字节为单位的各个程序的程序量、存储媒体的形式和数量；
b．程序系统共有哪几个版本，各自的版本号及它们之间的区别；
c．每个文件的名称；
d．所建立的每个数据库。 如果开发中制订过配置管理计划，要同这个计划相比较。
2．2主要功能和性能
逐项列出本软件产品所实际具有的主要功能和性能，对照可行性研究报告、项目开发计划、功能需 ．求说明书的有关内容，说明原定的开发目标是达到了、未完全达到、或超过了。
2．3基本流程
用图给出本程序系统的实际的基本的处理流程。
2．4进度
列出原定计划进度与实际进度的对比，明确说明，实际进度是提前了、还是延迟了，分析主要原因。
2．5费用
列出原定计划费用与实际支出费用的对比，包括：
a．工时，以人月为单位，并按不同级别统计；
b．计算机的使用时间，区别CPU时间及其他设备时间；
c．物料消耗、出差费等其他支出。
明确说明，经费是超出了、还是节余了，分析其主要原因。
3 开发工作评价
3．1对生产效率的评价
给出实际生产效率，包括：
a．程序的平均生产效率，即每人月生产的行数；
b．文件的平均生产效率，即每人月生产的千字数；
并列出原订计划数作为对比。
3．2对产品质量的评价
说明在测试中检查出来的程序编制中的错误发生率，即每干条指令（或语句）中的错误指令数（或语句数）。如果开发中制订过质量保证计划或配置管理计划，要同这些计划相比较。
3．3对技术方法的评价
给出对在开发中所使用的技术、方法、工具、手段的评价。
3．4出错原因的分析
给出对于开发中出现的错误的原因分析。
4 经验与教训
列出从这项开发工作中所得到的最主要的经验与教训及对今后的项目开发工作的建议。
附录5-1 JAVA编码规范
1、命名规范
定义这个规范的目的是让项目中所有的文档都看起来像一个人写的，增加可读性，减少项目组中因为换人而带来的损失。命名一般以简介单词构成。
1、package 的命名
package 的名字应该都是由一个小写单词组成。
package
2、class 的命名
class 的名字必须由大写字母开头而其他字母都小写的单词组成,对于所有标识符，其中包含的所有单词都应紧靠在一起，而且大写中间单词的首字母。
public class ThisAClassName{}
class 变量的命名
变量的名字必须用一个小写字母开头。后面的单词用大写字母开头
userName , thisAClassMethod
static final 变量的命名
static final 变量的名字应该都大写，并且指出完整含义。
public static final String
DB_CONFIG_FILE_PATH ="";
5、参数的命名
参数的名字必须和变量的命名规范一致。
6、数组的命名
数组应该总是用下面的方式来命名：
byte[] buffer;
而不是： byte buffer[];
7、方法的参数
使用有意义的参数命名，如果可能的话，使用和要赋值的字段一样的名字：
setCounter(int size){
= size;
}
2、注视规范
Java的注释有三种
// 注释一行
/* ...... */ 注释若干行
/** ...... */ 注释若干行，并写入javadoc文档 ，也叫java文档注释
注释要简单明了。
String userName = null; //用户名
边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码的一致性。
在必要的地方注释，注释量要适中。注释的内容要清楚、明了，含义准确，防止注释二义性。保持注释与其描述的代码相邻，即注释的就近原则。
对代码的注释应放在其上方相邻位置，不可放在下面。对数据结构的注释应放在其上方相邻位置，不可放在下面；对结构中的每个域的注释应放在此域的右方；
同一结构中不同域的注释要对齐。
变量、常量的注释应放在其上方相邻位置或右方。
全局变量要有较详细的注释，包括对其功能、取值范围、哪些函数或过程存取它以及存取时注意事项等的说明。
在每个源文件的头部要有必要的注释信息，包括：文件名；版本号；作者；生成日期；模块功能描述（如功能、主要算法、内部各部分之间的关系、该文件与其它文件关系等）；主要函数或过程清单及本文件历史修改记录等。
/**
* Copy Right Information : stsoft
* Project : jscbmis
* JDK version used :
* Comments : config path
* Version :
* Modification history :
* Sr Date Modified By Why & What is modified
* 1. David Li new
**/
在每个函数或过程的前面要有必要的注释信息，包括：函数或过程名称；功能描述；输入、输出及返回值说明；调用关系及被调用关系说明等
/**
* Description :checkout 提款
* @param Hashtable cart info
* @param OrderBean order info
* @return String
*/
public String checkout(Hashtable htCart,
OrderBean orderBean)
throws Exception{
}
javadoc注释标签语法
@author 对类的说明 标明开发该类模块的作者
@version 对类的说明 标明该类模块的版本
@see 对类、属性、方法的说明 参考转向，也就是相关主题
@param 对方法的说明 对方法中某参数的说明
@return 对方法的说明 对方法返回值的说明
@exception 对方法的说明 对方法可能抛出的异常进行说明
3、排版规范
关键词和操作符之间加适当的空格。
相对独立的程序块与块之间加空行
较长的语句、表达式等要分成多行书写。
划分出的新行要进行适应的缩进，使排版整齐，语句可读。
长表达式要在低优先级操作符处划分新行，操作符放在新行之首。
循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分。
若函数或过程中的参数较长，则要进行适当的划分。
不允许把多个短语句写在一行中，即一行只写一条语句。
函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格。
C/C++语言是用大括号‘{’和‘}’界定一段程序块的，编写程序块时‘{’和 ‘}’应各独占一行并且位于同一列，同时与引用它们的语句左对齐。在函数体 的开始、类的定义、结构的定义、枚举的定义以及if、for、do、while、 switch、case语句中的程序都要采用如上的缩进方式。
4、java文件样式
所有的 Java(*.java) 文件都必须遵守如下的样式规则：
版权信息 版权信息必须在 java 文件的开头，比如：
/*
* Copyright ? 2000 nanjing XXX Co. Ltd.
* All right reserved.
*/
其他需要出现在 javadoc 的信息也可以包含在这里。
package/imports
package 行要在 import 行之前，import 中标准的包名要在本地的包名之前，而且按照字母顺序排列。如果 import 行中包含了同一个包中的不同子目录，则应该用 * 来处理。
package ;
import .*;
import ;
import ;
这里 .* 使用来代替InputStream and OutputStream 的。
Class
接下来的是类的注释，一般是用来解释类的。
/**
* A class representing a set of packet and byte counters
* It is observable to allow it to be watched, but only
* reports changes when the current set is complete
*/
接下来是类定义，包含了在不同的行的 extends 和 implements
public class CounterSet
extends Observable
implements Cloneable
class fields 接下来是类的成员变量：
/**
* Packet counters
*/
protected int[] packets;
public 的成员变量必须生成文档（Javadoc）。proceted、private和 package 定义的成员变量如果名字含义明确的话，可以没有注释。
存取方法
接下来是类变量的存取的方法。它只是简单的用来将类的变量赋值获取值的话，可以简单的写在一行上。
/**
* Get the counters
* @return an array containing the statistical data. This array has been
* freshly allocated and can be modified by the caller.
*/
public int[] getPackets() { return copyArray(packets, offset); }
public int[] getBytes() { return copyArray(bytes, offset); }
public int[] getPackets() { return packets; }
public void setPackets(int[] packets) { = packets; }
其它的方法不要写在一行上
构造函数
接下来是构造函数，它应该用递增的方式写（比如：参数多的写在后面）。 访问类型 ("public", "private" 等.) 和 任何 "static", "final" 或 "synchronized" 应该在一行中，并且方法和参数另写一行，这样可以使方法和参数更易读。
public
CounterSet(int size){
= size;
}
clone,toString,main三个方法为可选，如果是bean，建议实现串行化、克隆两个接口，并完成toString(),hashCode()两个方法
对基于MS平台开发的应用，C#编码规格等同于上述。
附录5-2 应用结构定义与命名规范
建立应用结构的原则：
前端与后端分离；
系统、子系统、模块分离；
页面、脚本、样式、图标分离
私有与通用分离；
命名同样采用名词或动宾结构短语或缩写，每一级别名称不超过12个字符，全部有小些字母组成(26个字母)。
前端
业务功能1
pages
scripts
css
images
业务功能2
……
业务功能n
common
scripts
pages(err,warning,hint dialog)
css
images
后端
应用
业务功能1
业务功能2
……
业务功能n
组件类
工具类 util(tools).
框架类
数据库
视图
存储过程
函数
表、索引、触发器、约束、缺省等脚本
文档
计划、报告、设计等等
测试与修订纪录（ ）
附录5-3 数据库对象命名规范
命名原则：采用名词或动宾结构短语或缩写，名称不超过32个字符，名称由26英文字母，0—9及下划线组成，下划线与数字不能位于名称开始，创建数据库时候建议设置大小写敏感，命名采用大小写混合，不建议全部小写名称。
命名原则：
前缀+ ‘_’ + 子系统 + ‘_’ + 模块+ ‘_’ + 名称
数据库对象有：表、视图、存储过程、函数、约束、缺省、触发器、索引、主外键等，这里通过缩写标识这些对象,也就是命名中的前缀：
缩写
含义
Tb
表
Vw
视图
Sp
存储过程
Fn
函数
Rl
约束
Dft
缺省
Tg
触发器
Idx
索引
Pk
主键
Fk
外键
数据库对象名中的子系统与模块名是子系统与模块名的缩写（甚至编号）
索引与主键外键命名不受32长度约束：
索引命名：
Idx_表名_列名1_列2_列3。。。。。。
外键命名：
Fk_表名_列名
主键命名
Pk_表名_列名1_列2_列3。。。。。。
约束命名
Rl_表名_列名
缺省命名
Dft_表名_列名
标识列:id_xxxxx
编号列:no_xxxxx
编码列:code_xxxx
常用的字典
含义
命名
名称
Name_xxxxx
日期
Date_xxxxx
电话
Tel_xxxxx
地址
Add_xxxxx
邮编
Zip_xxxxx
部门
Dept_xxxxx
负责人
Charge_of_xxxxx
审批人
Approval_xxxxx
填报人
Typer_
申请人
Applicant_xxxx
单价
Unit_price
数量
Quan_
重量
Wei_
大小
Dim_
规格
Spec_
高度
High_
宽度
Wid_
长度
Len_
速度
Vel_
内容
Cont_
描述
Descr
所有表示状态的列，一律采用简明英文或英文缩写为其值：如好/确认/通过/合法:Ok/Yes/Pass 不好/否定/未通过：Cancel/No/Reject,未知状态为none等等，这样做一方面可以避免0/1的重码与解释问题，另一方面避免采用行字造成的编码问题。
Page PAGE 1 DATE \@ "M/d/yyyy" 4/28/2011
