CMMI5文档之软件设计规范.docx
- 文档编号:4794048
- 上传时间:2023-05-07
- 格式:DOCX
- 页数:38
- 大小:115.46KB
CMMI5文档之软件设计规范.docx
《CMMI5文档之软件设计规范.docx》由会员分享,可在线阅读,更多相关《CMMI5文档之软件设计规范.docx(38页珍藏版)》请在冰点文库上搜索。
CMMI5文档之软件设计规范
软件设计规范
文档编号:
FHI_CMMI_DOC_TEM_DESIGN文档信息:
软件设计规范
文档名称:
软件设计规范文档类别:
CMMI指南密级:
内部秘密
版本信息:
1.1建立日期:
2016-1-5
创建人:
EPG
批准人:
李庆林批准日期:
2016.2.25
存放位置:
集成公司组织资产库/组织标准过程编辑软件:
MicrosoftOffice2003中文版
文档修订记录
版本编号或者
更改记录编号
*变化
状态
简要说明(变更内容
和变更范围)
日期
变更人
批准日期
批准人
V1.0
C
创建
2016-1-5
张娜娜
2016-2-25
李庆林
V1.1
M
文档编号去掉版本号
2016-4-17
邓沛沛
2016-4-17
李庆林
*变化状态:
A――增加,M修改,D一一删除
本文定义了组织中书写文档及常用编程语言的编码风格的格式要求及规范要求,以达到风格的统
文档可使用文档模版,具体编码格式需要根据不同的语言和编译器进行适度裁剪。
目前文档中没有列到的语言,在项目需要时,要及时制定,评审通过后,及时充实到文档中。
第一章简介6
1.1目的6
1.2文档结构6
1.3引用文件6
1.4术语表6
1.5参考资料6
第二章体系结构设计原则7
2.1合适性7
2.2结构稳定性7
2.3可扩展性7
2.4可复用性7
第三章用户界面设计8
3.1前言8
3.2共性规则8
3.2.1缩进8
3.2.2边距8
3.2.3结束标志8
3.2.4注释9
3.2.5文件头部9
3.3命名规范9
3.3.1总则9
3.3.2过程与函数10
3.3.3变量(Variable)10
3.3.4常量10
3.3.5大小限制10
第四章界面设计标准11
4.1前言11
4.2易用性11
4.3规范性12
4.4帮助设施12
4.5合理性13
4.6美观与协调性14
4.7菜单位置14
4.8独特性15
4.9快捷方式的组合15
4.10安全性考虑16
4.11多窗口的应用与系统资源17
4.12BS程序标准17
第五章数据库设计标准19
5.1前言19
5.2命名的规范19
5.2.1数据库命名规范19
5.2.2表及表空间命名规范19
5.2.3字段命名规范20
5.2.4存储过程编写规范20
5.2.5函数编写规范21
5.2.6触发器编写规范21
5.3SQL编码规范21
5.3.1参数规范21
5.3.2变量命名规范22
5.4游标(Cursor)的慎用22
5.5索引(Index)的使用原则23
5.6数据的一致性和完整性24
5.7事务的陷阱24
5.8数据库性能调整25
5.9数据类型的选择25
第六章模块设计27
6.1信息隐藏27
6.2高内聚27
6.3低耦合28
第七章数据结构与算法设计29
第八章类和接口设计原则30
第一章简介
1.1目的
本文的目的是建立组织中书写文档及编码有关的格式要求及规范要求。
1.2文档结构
无。
1.3引用文件
无。
1.4术语表
无。
1.5参考资料
Paulk,MarkC.,etal.CapabilityMaturityModelforSoftware,Version1.1CMU/SEI-93-TR-24
Paulk,MarkC.,etal.KeyPracticesoftheCapabilityMaturityModel,Version1.1,CMU/SEI-93-TR-25
第二章体系结构设计原则
2.1合适性
即体系结构是否适合于软件的“功能性需求”和“非功能性需求”。
高水平的设计师高就高在“设计出恰好满足客户需求的软件,并且使开发方和客户方获取最大的利益,而不是不惜代价设计出最先进的软件。
2.2结构稳定性
详细设计阶段的工作如用户界面设计、数据库设计、模块设计、数据结构与算法设计等等,都是在体系结构确定之后开展的,而编程和测试则是更后面的工作,因此体系结构应在一定的时间内保持稳定。
软件开发最怕的就是需求变化,但“需求会发生变化”是个无法逃避的现实。
人们希望在需求发生变化时,最好只对软件做些皮毛的修改,可千万别改动软件的体系结构。
如果当需求发生变化时,程序员不得不去修改软件的体系结构,那么这个软件的系统设计是失败的。
高水平的设计师应当能够分析需求文档,判断出哪些需求是稳定不变的,哪些需求是可能变动的。
于是根据那些稳定不变的需求设计体系结构,而根据那些可变的需求设计软件的“可扩展性”。
2.3可扩展性
可扩展性是指软件扩展新功能的容易程度。
可扩展性越好,表示软件适应“变化”的能力越强。
可扩展性越来越重要,这是由现代软件的商业模式决定的:
社会的商业越发达,需求变化就越快。
需求变化必将导致修改(或者扩展)软件的功能,现代软件的规模和复杂性要比十年前的大得多(对比一下操作系统的变化就明白了),如果软件的可扩展性比较差的话,那么修改(或者扩展)功能的代价会很高。
现代软件产品通常采用“增量开发模式”,开发商不断地推出软件产品的新版本,从而不断地获取增值利润。
如果软件的可扩展性比较差的话,每次开发新版本的代价就会很高。
虽然开发商抓住了商机,但却由于设计水平差而导致没有赚取多少利润,真是要活活气死。
2.4可复用性
由经验可知,通常在一个新系统中,大部分的内容是成熟的,只有小部分内容是创新的。
一般地可以相信成熟的东西总是比较可靠的(即具有高质量),而大量成熟的工作可以通过复用来快速实现(即具有高生产率)。
可复用性是设计出来的,而不是偶然碰到的。
要使体系结构具有良好的可复用性,设计师应当分析
应用域的共性问题,然后设计出一种通用的体系结构模式,这样的体系结构才可以被复用。
第三章用户界面设计
为了提高用户界面的易用性和美观程度,总结了十个设计原则。
用于提高易用性的界面设计原则有
8个:
用户界面适合于软件的功能
容易理解
风格一致
及时反馈信息
出错处理
适应各种用户
国际化
个性化
用于提高美观程度的设计原则有:
合理的布局
和谐的色彩
3.1前言
本文档提取了各种语言、工具中的一些共同的编码规则,如本规则与其他的编程规则
冲突,以其他的编程规则为准。
3.2共性规则
3.2.1缩进
缩进就是每级间有固定数量的空格:
如C语言为三个空格,其他编程语言建议采用此
语言编辑器的默认风格)
3.2.2边距
边距设置为80个字符。
但本规则比较灵活,允许少量的超出。
长度超过一行的语句应
当用逗号或运算符换行。
换行后,应缩进4个字符。
3.2.3结束标志
根据语言的不同,有多种结束标志,包括“end”,“}”等。
这些结束标志总单独一行。
结束标志与相应的起始标志(“begin”,“{”等}的缩进量相同
3.2.4注释
在封存的某一版本的源代码之中不得存在由于调试而留下的大篇的注释。
注释一行不要太多,一般60个字符以内,如有超过,则换行处理。
建议在条件语句或者循环语句的结尾加上注释。
3.2.5文件头部
在所有源文件、项目文件和单元文件使用结构化的文件头信息。
一个文件头至少应包含以下信息:
文件名功能信息版权信息。
一张历史表格,列出日期,作者,变更情况。
例子:
*File:
Example.pas
*Function:
ademoforhowtowriteafile's_head
*Copyright2003ZHONGTIAN.Allrightreserved.
Author
*May12003XXX
Created
*May132003XXX
Addednewdocconventions
3.3命名规范
3.3.1总则
命名应尽量使用有意义的英文单词,不建议采用汉语拼音,应使其名称易于理解并且能够准确表达出它的用途。
具体写法为:
每个单词以大写字母开头,后面的字母小写,单词之间不采用联字符。
不建议使用缩略的写法。
如:
LocalVariable,而不是采用LocVar。
前者明显要比后者容易理解。
如果要采用缩略的写法,应该要注意缩写应易于理解,并且统一采用相同的缩写。
如:
将System缩写为Sys,Procedure缩写为Proc,均为可以采用的方式。
同时应注意名称一般不应超过20个字符,超过的可以适当采用缩写的方式。
命名应该避免的情况:
名称和标准库中名称冲突。
看上去很像的名称(如1stPlaceandlstPlace)。
3.3.2过程与函数
进行一个动作的过程最好在名称前加上表示动作的动词为前缀。
例如:
FormatHardDrive
设置输入参数值的过程名应当以Set为其前缀,例如:
SetUserName
获取数值的过程名应当以Get为其前缀,例如:
GetUserName
3.3.3变量(Variable)
变量应该总是被定义在尽可能小的范围内。
全局变量可以导致极其复杂的状态机构,并且使一个应用程序的逻辑非常难于理解。
全局变量也使代码的重用和维护更加困难。
全局变量以小写字母“g”打头,并遵循其他变量的命名规则。
变量的名称应当能够表达出它的用途。
循环控制变量常常为单个字母,诸如i、j或k也可以使用更有意义的名称,例如Userlndex。
布尔变量名必须能清楚表示出TRUE和FALSE值的意义。
3.3.4常量
常量应采用有意义的单词,并且全部大写,中间采用“_”分开。
如:
MAX_USER
3.3.5大小限制
在一般情况下,文件一般不超过500行,函数不超过100行。
超过的应分成多个文件或函数。
第四章界面设计标准
4.1前言
界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象。
而且设计良好的界面能够引导用户自己完成相应的操作,起到向导的作用。
同时界面如同人的面孔,具有吸引用户的直接优势。
设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉,相反由于界面设计的失败,让用户有挫败感,再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
4.2易用性
各种界面物件名称应该易懂,用词准确,没有模棱两可的字眼,要与同一界面上的其他物件易于区分,最好能够望文知意。
理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。
易用性细则:
完成相同或相近功能的按钮用Frame框起来,常用按钮要支持快捷方式。
完成同一功能或任务的元素放在集中位置,减少鼠标移动的距离或按键的次数。
按功能将界面划分局域块,用Frame框起来,并要有功能说明或标题。
界面要支持键盘自动浏览按钮功能,即按Tab键的自动切换功能。
界面上首先应输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的
同一界面上的控件数最好不要超过10个,多于10个时可以考虑使用分页界面显示。
分页界面要支持在页面间的快捷切换,常用组合快捷键Ctrl+Tab默认按钮要支持Enter操作,即按Enter后自动执行默认按钮对应操作。
可写控件检测到非法输入后应给出说明并能自动获得焦点。
Tab键的顺序与控件排列顺序要一致,总体从上到下,同时行间从左到右的方式。
复选框和选项框按选择几率的高低而先后排列。
复选框和选项框要有默认选项,并支持Tab选择。
选项数相同时多用选项框而不用下拉列表框。
界面空间较小时使用下拉框而不用选项框。
选项数较少时使用选项框,相反使用下拉列表框。
专业性强的软件要使用相关的专业术语,通用性界面则提倡使用通用性词眼。
4.3规范性
通常界面设计都按Windows界面的规范来设计,即包含“菜单条、工具栏、工具箱、状态栏、滚动条、右键快捷菜单”的标准格式,unix界面根据实际情况,可以更侧重于键盘操作,对界面进行适当简化。
可以说:
界面遵循规范化的程度越高,则易用性相应的就越好。
规范性细则:
常用菜单要有命令快捷方式。
完成相同或相近功能的菜单用横线隔开放在同一位置。
菜单前的图标能直观的代表要完成的操作。
菜单深度一般要求最多控制在三层以内。
工具栏要求可以根据用户的要求自己选择定制。
相同或相近功能的工具栏放在一起。
工具栏中的每一个按钮要有及时提示信息。
一条工具栏的长度最长不能超出屏幕宽度。
工具栏的图标能直观的代表要完成的操作。
系统常用的工具栏设置默认放置位置。
工具栏太多时可以考虑使用工具箱。
工具箱要具有可增减性,由用户自己根据需求定制。
工具箱的默认总宽度不要超过屏幕宽度的1/5。
状态条要能显示用户切实需要的信息,常用的有:
目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等,如果某一操作需要的时间较长,还应该显示进度条和进程提示。
滚动条的长度要根据显示信息的长度或宽度能及时变换,以利于用户了解显示信息的位置和百分比。
状态条的高度以放置五号字为宜,滚动条的宽度比状态条的略窄。
菜单和工具条要有清楚的界限;菜单要求凸出显示,这样在移走工具条时仍有立体感。
菜单和状态条中通常使用5号字体。
工具条一般比菜单要宽,但不要宽的太多。
右键快捷菜单采用与菜单相同的准则。
4.4帮助设施
系统应该提供详尽而可靠的帮助文档,在用户使用产生迷惑时可以自己寻求解决方法。
帮助设施细则:
帮助文档中的性能介绍与说明要与系统性能配套一致。
打包新系统时,对作了修改的地方在帮助文档中要做相应的修改。
操作时要提供及时调用系统帮助的功能。
常用F1。
在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。
也就是说帮助要有即时针对性。
最好提供目前流行的联机帮助格式或HTML帮助格式。
用户可以用关键词在帮助索引中搜索所要的帮助,当然也应该提供帮助主题词。
如果没有提供书面的帮助文档的话,最好有打印帮助的功能。
在帮助中应该提供我们的技术支持方式,一旦用户难以自己解决可以方便的寻求新的帮助方式。
MDI的微帮助:
这是指MDI(多文档界面)框下面的状态条中的文字。
窗口底部的微帮助一般有两个作用:
一是在用户选择菜单项或其他窗口控件时,显示更多的文字信息来解释或提示用户所要进行的操作是什么,另一个用途是系统在处理进程中显示正在进行的工作状态,以使用户了解系统的处理进度,从而免去死机的担心。
声音提示,在用户可能进行破坏性操作时,用声音及时提出警告是必要的,但是我们不能滥用,因为当用户无法正确操作软件或做了不希望做的事情时,听到警告声反而会更加烦恼,因此使用这种反馈方法时要慎用。
此外在一个长处理的结束时使用声音反馈(如警告声或小段悦音)也是必要
的。
使用反馈的场合:
在客户/服务器环境下用户最不能忍受的是系统反应速度慢,而在实际的应用中我们会经常遇到计算机需要比较长的时间执行一个或一批操作。
在这种情况下,我们应加入反馈,让用户了解应用正在做什么。
比如:
在需等待时间较短(0-10秒)的情况下应将鼠标显示成为沙漏;在处理需10到18秒时,由微帮助来显示处理进度;当需18秒以上时,要显示这个处理窗口,或显示进度条;
当一个长时间的处理完成时应发出一个提示警告声如beep
(1),这样用户不必总看着屏
幕。
4.5合理性屏幕对角线相交的位置是用户直视的地方,正上方四分之一处为易吸引用户注意力的位置,在放置窗体时要注意利用这两个位置。
合理性细则:
父窗体或主窗体的中心位置应该在对角线焦点附近。
子窗体位置应该在主窗体的左上角或正中。
多个子窗体弹出时应该依次向右下方偏移,以显示窗体出标题为宜。
重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。
错误使用容易引起界面退出或关闭的按钮不应该放在易点位置。
横排开头或最后与竖排最后为易点位置。
与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示,没法使用该按钮)。
对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。
非法的输入或操作应有足够的提示说明。
对运行过程中出现问题而引起错误的地方要有提示,让用户明白错误出处,避免形成无限期的等待。
提示、警告、或错误说明应该清楚、明了、恰当。
4.6美观与协调性
界面应该大小适合美学观点,感觉协调舒适,能在有效的范围内吸引用户的注意力。
美观与协调性细则:
长宽接近黄金点比例,切忌长宽比例失调、或宽度超过长度。
布局要合理,不宜过于密集,也不能过于空旷,合理的利用空间。
按钮大小基本相近,忌用太长的名称,免得占用过多的界面位置。
按钮的大小要与界面的大小和空间要协调。
避免空旷的界面上放置很大的按钮。
放置完控件后界面不应有很大的空缺位置。
字体的大小要与界面的大小比例协调,通常使用的字体中宋体9-12较为美观,很少使用超过12号的字体。
前景与背景色搭配合理协调,反差不宜太大,最好少用深色,如大红、大绿等。
如果使用其他颜色,主色要柔和,具有亲和力与磁力,坚决杜绝刺目的颜色。
界面风格要保持一致,字的大小、颜色、字体要相同,除非是需要艺术处理或有特殊要求的地方。
如果窗体支持最小化和最大化或放大时,窗体上的控件也要随着窗体而缩放;切忌只放大窗体而忽略控件的缩放。
对于含有按钮的界面一般不应该支持缩放,即右上角只有关闭功能。
通常父窗体支持缩放时,子窗体没有必要缩放。
如果能给用户提供自定义界面风格则更好,由用户自己选择颜色、字体等。
4.7菜单位置
菜单是界面上最重要的元素,菜单位置按照按功能来组织
菜单设测试细则:
菜单通常采用“常用--主要--次要--工具--帮助”的位置排列。
常用的有“文件”、“编辑”,“查看”等,几乎每个系统都有这些选项,当然要根据不同的系统有所取舍。
下拉菜单要根据菜单选项的含义进行分组,并切按照一定的规则进行排列,用横线隔开。
一组菜单的使用有先后要求或有向导作用时,应该按先后次序排列。
没有顺序要求的菜单项按使用频率和重要性排列,常用的放在开头,不常用的靠后放置;重要的放在开头,次要的放在后边。
如果菜单选项较多,应该采用加长菜单的长度而减少深度的原则排列。
菜单深度一般要求最多控制在三层以内。
对常用的菜单要有快捷命令方式。
对与进行的操作无关的菜单要用屏蔽的方式加以处理。
菜单前的图标不宜太大,与字高保持一直最好。
主菜单的宽度要接近,字数不应多于四个,每个菜单的字数能相同最好。
主菜单数目不应太多,最好为单排布置。
4.8独特性
如果一味的遵循业界的界面标准,则会丧失自己的个性。
在框架符合以上规范的情况下,设计具有组织独特风格的界面尤为重要。
可以在商业软件流通中有着很好的迁移默化的广告效用。
安装界面上应有单位介绍或产品介绍,并有自己的图标。
主界面,最好是大多数界面上要有组织图标。
登录界面上要有本产品的标志,同时包含组织图标。
帮助菜单的“关于”中应有版权和产品信息。
组织的系列产品要保持一直的界面风格,如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。
4.9快捷方式的组合
在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些。
在西文
Windows及其应用软件中快捷键的使用大多是一致的。
菜单中:
面向事务的组合有:
Ctrl-D删除;Ctrl-F寻找;Ctrl-H替换;Ctrl-1插入;Ctrl-N新记录;Ctrl-S保存Ctrl-O打开。
列表:
Ctrl-R,Ctrl-G定位;Ctrl-Tab下一分页窗口或反序浏览同一页面控件。
编辑:
Ctrl-A全选;Ctrl-C拷贝;Ctrl-V粘贴;Ctrl-X剪切;Ctrl-Z撤消操作;Ctrl-Y恢复操作。
文件操作:
Ctrl-P打印;Ctrl-W关闭。
系统菜单
Alt-A文件;Alt-E编辑;Alt-T工具;Alt—W窗口;Alt—H帮助。
MSWindows保留键:
Ctrl-Esc任务列表;Ctrl-F4关闭窗口;Alt-F4结束应用;Alt-Tab下一应用;
Enter缺省按钮/确认操作;Esc取消按钮/取消操作;Shift-F1上下文相关帮助。
按钮中:
可以根据系统需要而调节,以下只是常用的组合。
Alt-Y确定(是);Alt-C取消;Alt-N否;Alt-D删除;Alt-Q退出;Alt-A添加;Alt-E编辑;Alt-B浏览;Alt-R读;Alt-W写。
这些快捷键也可以作为开发中文应用软件的标准,但亦可使用汉语拼音的开头字母。
4.10安全性考虑
在界面上通过下列方式来控制出错几率,会大大减少系统因用户人为的错误引起的破坏。
开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。
如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。
因为这意味着用户要中断思路,并费时费力地重新登录,而且已进行的操作也会因没有存盘而全部丢失。
安全性细则:
最重要的是排除可能会使应用非正常中止的错误。
应当注意尽可能避免用户无意录入无效的数据。
采用相关控件限制用户输入值的种类。
当用户做出选择的可能性只有两个时,可以采用单选框。
当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种
无效的选择。
当选项特别多时,可以采用列表框,下拉式列表框。
在一个应用系统中,开发者应当避免用户做出XX或没有意义的操作。
对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。
对可能发生严重后果的操作要有补救措施。
通过补救措施用户可以回到原来的正确状态。
对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。
对错误操作最好支持可逆性处理,如取消系列操作。
在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。
对可能造成等待时间较长的操作应该提供取消功能。
特殊字符常有;;’”><,'‘:
“[”{、\|}:
+=)-(_*&A%$#@!
~.。
?
/还有空格。
与系统采用的保留字符冲突的要加以限制。
在读入用户所输入的信息时,根据需要选择是否去掉前后空格。
有些读入数据库的字段不支持中间有空格,但用户切实需要输入中间空格,这时要在程序中加以处理。
4.11多窗口的应用与系统资源
设计良好的软件不仅要有完备的功能,而且要尽可能的占用最低限度的资源。
在多窗口系统中,有些界面要求必须保持在最顶层,避免用户在打开多个窗口时,不停的切换
甚至最小化其他窗口来显示该窗口。
在主界面载入完毕后自动卸出内存,让出所占用的WINDOWS系统资源。
关闭所有窗体,系统退出后要释放所占的所有系统资源,除非是需要后台运行的系统。
尽量防止对系统的独占使用。
4.12BS程序标准
所有程序必须适应800以及1024两种分辨率。
在不能够实现自适应界面的情况下,采用800
的标准居中显示。
但是应该首先努力实现自适应界面。
在repeater或者其他数据浏览控件中的操作图标必须使用alt属性添加操作的说明。
图片按钮
imagebutton建议使用Tooltip属性对按钮的功能作出说明。
程序中所有的数据浏览格式应一致。
翻页控件于list控件的距离应一致。
所有的仅仅针对一行数据操作的功能,通过图标的方式放置在每一行的最后。
能够通过操作多条数据的功能,通过Imagebutton的方式放置在list控件的上方。
界面上的语言应于客户的工作用语保持一致,界面上使用的图标或者按钮应该能够是用户不用
深虑,即可了解其含义。
在逻辑上为一组选项应使用GroupBox框起来,并进行说明。
可写控件检测到非法输入后应给出说明并能自动获得焦点。
在不影响效率的情况下复选框和单选框按选择几率的高低和先后排列。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- CMMI5 文档 软件设计 规范