10 软件设计规范.docx

10 软件设计规范.docx

《10 软件设计规范.docx》由会员分享，可在线阅读，更多相关《10 软件设计规范.docx（59页珍藏版）》请在冰豆网上搜索。

10软件设计规范

工作文件

文件名称：

软件设计规范

文件编号：

版号：

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顺序等要讲究，视应用场合要适当支持键盘。

在简洁易用的前提下，力求个性化，设计得更加友好。

程序各对话框的风格要保持一致。

单文档和多文档界面的程序功能强，也便于扩充和管理。

其中菜单、工具栏、状态栏等设计要有特色。

菜单按一定的分类弹出，必要时设计成多套菜单，在重要的窗口或区域应能弹出右键，实现常见操作。

工具栏上放最常用的操作按钮，必要时动态更换按钮。

状态栏显示足够多的有用信息。

消息主控在Mainframe中，单文档的主控也可在View中，所有的对话框的弹出或非模态对话框的控制都在主控窗口中完成，具体的数据处理放在单独的文件中或设计成类。

在App类中实现Ini读写，各数据对象的定义和析构，全局变量的赋值和初始计算，存盘退出等。

各视图的OnDraw和GDI画图尽量使用内存位图的方式，以免闪烁。

其它还有ATL，控制台，嵌入式程序界面等，也有作为其它容器如IE中的插件等，此类程序可能不用MFC，而采用COM组件等方法实现。

5.4软件测试

测试时系统投入使用前最关键的一个步骤，由开发人员之间、业务需求人员交叉测试或由软件测试工程师测试。

开发人员将对在测试过程中发现的问题提出可行建议进行改进。

测试方法、测试类型及测试结果判断规范参考《软件测试规范》。

5.5项目验收

建设工程包括多个方面的工作和任务，每一项任务的完成、每一个文档的提交、每一个设备、软件或应用系统的交付，都有相应的完成标志和测试、评估和验收标准。

对于系统、网络和应用这种重大的工作里程碑事件，测试验收工作更为严谨和充分，计划更为周密。

按照系统集成服务的程序和行业惯例，整个项目实施过程中要对不同的交付项目进行如下各类测试和验收中的一种或几种，具体进行哪种或哪些测试验收工作依交付项目的性质不同而不同。

5.5.1审议确认

这是一种采用对交付件内容进行阅读、讲解、评议、问题与回答的形式进行评审，并作出接受或拒绝决定的方法。

对于交付的项目管理文档、设计文档、测试报告、技术资料等交付项目，通常采用这种方法。

5.5.2安装测试

采用标准的测试程序（如硬件设备开机自检）和操作方法，对交付件进行测试的方法。

通常用于对硬件设备和系统软件的验收。

5.5.3初始安装测试

类似于安装测试，通常用于对最终提交结果进行安装测试。

典型的情况是系统软件的初始安装测试，此时安装的是用于进行设计开发的平台或工具，而不是直接提交客户作生产目的。

5.5.4用户验收测试

用户验收测试是用户根据自己的业务处理要求，在实际系统上进行的类似于系统集成测试的过程。

这种测试的目的是检验交付系统是否达到设计要求，是否可以投入业务运行。

与系统集成测试的不同在于，用户验收测试更加着重从业务功能方面的测试，时间也相对短。

验收测试计划确立了对系统进行测试验收的方式和标准。

公司将指导用户制订验收测试计划（在验收测试开始前两周）。

测试计划将包括：

a）测试目标

b）角色和职责

c）测试环境

d）要测试的功能和外观特征

e）测试手段

f）测试案例及预期结果

当所有功能和外观特征经测试达到验收测试计划所说明的完成标志，客户将接收该系统。

在测试过程中，任一项没有达到完成标志，开发商将负责修正然后再进行测试。

某些测试失败可能由于对项目实施目标的误解而导致，对这些误解进行分析。

如果是开发商的责任，将做必要的修正并再进行测试。

5.5.5人员培训

对用户人员进行技术培训是工程成功的重要因素，是整个项目能否顺利实施的重要保证。

针对设备或软件系统的业务和技术特点及要求，我们将提供必要的技术培训，并可就客户的其它具体要求提供其它方面的培训。

5.5.6资料文档

为保证系统的建设和正常运行，我们可以提供如下设计类、计划类、测试类资料和文档，各项目根据自身情况进行剪切。

a）软件需求规格说明

b）系统设计文档

c）数据库设计文档

d）软件开发计划

e）开发计划

f）软件配置项测试计划

g）测试大纲

h）测试报告

i）验收报告

j）用户手册

5.6客服支持

5.6.1培训目标

在实施项目的过程中，使相关操作人员理解软件的基本原理和实际运用，使他们对整套业务软件的具体性能，操作步骤以及具体要求，有一个更深层次的认识，并能在计算机管理下对其业务软件流程熟练操作使用。

再开发人员共同接受软件开发方全面、系统的培训，保证能够在后期推广中独挡一面完成推广及软件升级任务。

5.6.2培训计划

项目组有义务对用户提供及时、有效、全面的培训，并在项目实施过程中充分重视对用户方的技术转移，并提前制订有效可行的培训计划。

5.6.3考核标准

以实际操作方式测试用户对软件系统流程的操作使用能力。

附录AC++编码规范

1文件结构

1.1文件头注释

所有C++的源文件均必须包含一个规范的文件头，文件头包含了该文件的名称、功能概述、作者、版权和版本历史信息等内容。

标准文件头的格式为：

/*!

@file