10 软件设计规范
- 格式:doc
- 大小:313.96 KB
- 文档页数:67
工作文件
文件名称:软件设计规范
文件编号:版号:A
编制:日期:
审核:日期:
批准:日期:
受控状态:
生效日期:
分发号:
1目的
本规范是对项目软件设计的一份规范性文件,对软件设计过程中的活动进行总体规范,以有效保证软件产品的质量。
2范围
本规范适用于公司研制的全部软件产品。
3设计流程
软件设计流程按照《软件设计和开发控制程序》中规定执行,软件开发过程可包括以下活动:
a)需求分析;
b)软件开发;
c)软件测试;
d)项目验收;
e)客服支持。
4前期准备
软件开发人员对系统开发前期进行充分的用户调研、需求分析和系统体系结构的设计准备工作。软件开发人员以及业务需求人员共同组建项目组,一名或两名项目经理负责监控项目的整体实施,共同参与系统的全面设计、开发,并针对业务提出进一步开发需求,开展软件用户化工作,制定二次开发方案,参与设计业务系统与其它软件的接口。5实施过程
整个开发过程将经历获取需求、需求分析、系统设计、编码、测试等阶段。
5.1 获取需求
软件在进入正式开发之前,提供准确的书面《需求规格说明书》其中包括:
a)对现有系统的分析。
b)待开发系统的详细需求。
c)功能需求,使用范围,业务流程,用户界面,输出要求,故障处理。
d)网络环境,硬件环境,软件环境,与其他系统的关系,安全与保密。
e)技术可行性分析,经济可行性分析,人员可行性分析,影响待开发系统的主要
因素。
软件项目分为专用软件和通用软件两大类。
对于专用软件,在进入开发之前必须与用户进行比较具体的交流和讨论,了解清楚用户理想的产品究竟是什么样子,这里最好就采用原型化的方法作出一个简单的框架给用户看。
对于通用软件,在开发之前必须做一定的市场调查工作,一方面是从经济效益考虑,调查产品的潜在市场有多大,一方面是从技术的角度,了解清楚潜在用户对软件的各种技术上的要求,另一方面是确定软件的定位,即我们软件具体是为哪一些用户群体服务的。然后对该群体用户现有硬件配置,软件配置,网络使用情况,数据库使用情况,计算机熟悉程度做一定的调研,根据调查的统计结果决定即将开发的软件的一些技术指标。
5.2 需求分析
开发人员构思、确立系统目标、划分业务领域、现行业务分析、建立业务模型、信息需求分析、用户视图规范化、数据元素标准化与一致性控制等。
在项目组和用户充分交互、理解的基础上,提出系统的技术构架,对系统功能、性能等主要指标作描述,对实现方法项目实施人员应有一个比较清晰的轮廓及整体设计思路,对有疑问的地方及时与业务需求人员进行沟通交流,最终达成共识。
综合对该用户群体现有硬件配置,软件配置,网络使用情况,数据库使用情况,计算机熟悉程度做一定的调研,根据调查的统计结果决定即将开发的一些软件适用指标。这个阶段需要出三样东西,用户视图,数据词典和用户操作手册。
用户视图是该软件用户(包括终端用户和管理用户)所能看到的页面样式,这里面包含了很多操作方面的流程和条件。
数据词典是指明数据逻辑关系并加以整理,完成了数据词典,数据库的设计就完成了一半多。
用户操作手册是指明了操作流程的说明书。
5.3 软件开发
5.3.1系统结构建立
确定软件服务器的硬件配置及用户硬件资源配置。
确定用户软件平台的统一协调。
5.3.2软件设计
软件设计阶段的工作包括对模块进行必要的修改,同时可能需要对某些结构做一些修改,确定界面定义、用户服务层、业务逻辑层、数据库服务层和具体数据库,确定软件开发工具。这一阶段还将完成更详细的功能和业务需求调研,制作系统中最符合用户需要的文档。
根据应用系统对安全的要求,同步进行安全保密设计。
5.3.3软件编码
确定软件的界面风格、使用功能、编程语言、数据库结构和具体数据等工作,并开始进入程序编写阶段。
开发人员进入设置和编码工作之后,应先确定编码的风格在开发过程中保持一致,工作过程中如发现前面分析或设计阶段的某些错误,应返回到前面的阶段进行必要的修改,同时主要开发人员之间应相互紧密配合。编码语言除用户特别要求外应尽量使用常用语言,详细语言编码规范参考《C++编码规范》(附件A)和《C#编码规范》(附件B)。
5.3.3.1代码规范
有些不易理解的变量或函数应作注释,难懂的代码要有注解,在文件的开始处有该文件的用途描述。一定要保持注释的一致性。
代码组织要清晰,{,},(,),if,else,do,while,for,case等要对应整齐,少用空格,缩进全部用Tab键。变量的定义要集中,函数间要有空行分开,一个程序中的空行数目最好占8%-16%。多态函数和功能相近的函数集中放在一起。
代码应该简洁、清楚并讲述了所发生的一切。某些公用代码要注意多平台易移植,最好使用标准C。
代码的重用要仔细,要将相关的代码也拷贝过来,注意那段代码是否适合需求的应用场合。
删掉从来没有用过的函数或变量,大篇幅注释掉的代码行也应删除,以免使程序混乱难读。
5.3.3.2工程文件组织规范
一个工程往往包含很多很多文件(*.h,*.cpp,*.inc,*.lib,资源文件等),向工程中加入文件或删除工程中的文件要慎重,避免把工程损坏。工程中不起作用的文件或类应删除,工程目录下的非工程文件也应该移走,保持工程的清洁,避免混淆难于管理。工程文件如果很多,应归类。
在VC环境下,建议将常用的头文件全部放入stdafx.h中,而在每个cpp开始处嵌入stdafx.h。避免头文件的交叉引用,如果有严重的交叉引用,适当使用类的声明。
将独立性比较强的模块抽出来,做成DLL,控件或COM组件,该模块可单独编写和测试,也增强了其可重用性。
一个比较大的工程应留有一定的消息接口或插件接口等。
工程的版本控制要严格,版本格式为xx.xx.xx,必要时使用Build次数或日期。高版本尽量兼容低版本的用法、数据或协议。
工程的编译宏定义和工程参数设置应正确,每作一个新工程时应检查工程参数是否正确。
建议字节对齐方式为1字节对齐。
工程文件应经常备份,备份时注明备份日期和主要增加的功能。
5.3.3.3类组织规范
类一般有两个文件,一个头文件,一个实现体CPP。
类力求封装好,严格区分public,private,protect等作用域,如果一个函数与本类有莫大的关系,可以作为该类的静态成员函数,不用或少用友元函数等破坏类封装性的方法和技巧。如果一些结构或宏仅与本类有关,可在类头文件中定义。
类的成员变量在构造函数或初始化函数中应赋初值。指针在构造函数中赋NULL,析构时DEL_EMPTY它,以免内存泄露。
5.3.3.4用户界面规范
有四大类型的用户界面:对话框、单文档界面、多文档界面、其它界面。
对话框要易用且简洁,字体和控件的组织搭配要得体,能简单不复杂,各控件的焦点、Tab顺序等要讲究,视应用场合要适当支持键盘。在简洁易用的前提下,力求个性