精华内容
下载资源
问答
  • 软件设计开发规范(国标)

    千次阅读 2019-08-02 09:08:42
    软件开发规范,包括:1-操作手册(GB8567——88).doc2-测试分析报告(GB8567——88).doc3-测试计划(GB8567——88).doc 4-概要设计说明书(GB8567——88).doc5-开发进度月报(GB8567——88).doc 6-可行性研究...

    软件开发规范

    包括:1-操作手册(GB8567——88).doc
                2-测试分析报告(GB8567——88).doc
                3-测试计划(GB8567——88).doc
                4-概要设计说明书(GB8567——88).doc
                5-开发进度月报(GB8567——88).doc
                6-可行性研究报告(GB8567——88).doc
                7-模块开发卷宗(GB8567——88).doc
                8-软件需求说明书(GB856T——88).doc
                9-数据库设计说明书(GB8567——88).doc
                10-数据要求说明书(GB856T——88).doc
                11-文件给制实施规定的实例(GB8567-88).doc
                12-详细设计说明书(GB8567——88).doc
                13-项目开发计划(GB856T——88).doc
                14-项目开发总结报告(GB8567——88).doc
                15-用户手册(GB8567——88).doc

    转载于:https://www.cnblogs.com/jillzhang/archive/2007/06/24/793939.html

    展开全文
  • 软件开发规范

    千次阅读 2018-07-25 15:17:42
    1.软件开发的过程:  ★需求规范:是一个规范化的过程,旨在理解软件要处理的问题,以及将软件系统需要做的详细记录在文档中,这个阶段涉及和用户的有效沟通;  ★系统分析:旨在分析数据流,并且确定系统的输入...

    1.软件开发的过程:

        ★需求规范:是一个规范化的过程,旨在理解软件要处理的问题,以及将软件系统需要做的详细记录在文档中,这个阶段涉及和用户的有效沟通;

        ★系统分析:旨在分析数据流,并且确定系统的输入和输出,当进行分析的时候,首先确定输出,然后弄清楚要什么样子的输入从而产生结果是有帮助的; 

        ★系统设计:是设计一个从输入获得输出的过程,这个阶段涉及多层的抽象,将系统分解为可管理的子系统,系统分析和设计的本质就是输入,处理和输出; 

        ★系统实现:是将系统设计翻译成程序,并且为每个子系统编写独立的程序,然后集成在一起工作;

        ★系统测试:测试确保代码符合需求规范,并且排除潜在的错误,通常由一个没有参与产品设计和实现的工程团队来完成;

        ★系统部署:按照软件类型的不同,可以被安装在个人电脑,移动端,服务器端等等;

        ★系统维护:是针对产品进行更新和改进,产品必须在一直演化的环境中连续运行和改进,一般是进行周期性的改进个更新,以修正新发现的错误,并且将更改集成到产品中;

    展开全文
  • 软件开发设计规范书的撰写

    千次阅读 2008-08-05 16:30:00
    整个软件开发过程是一个相当复杂的流程,并不是简单的靠几个设计工程师自己在那边写软件就完,而是要有从头到尾,包括很多人,不同专家,不同的专业,不同的知识放在一起,最后才造成一个完善的软件产品。...
     
    

    整个软件开发过程是一个相当复杂的流程,并不是简单的靠几个设计工程师自己在那边写软件就完,而是要有从头到尾,包括很多人,不同专家,不同的专业,不同的知识放在一起,最后才造成一个完善的软件产品。从决定开始,到计划、设计,最后到写程序、执行,然后还有测试、纠错、保证稳定、发行、部署、调试,整个过程是一个相当长的过程,并不是一个简单的程序。要为了保证软件的质量,能够达到客户满足和满足市场的要求,很要紧的工作,早期工作做的越是完善、仔细,避免后面的工作,由于前面不完善造成的返工,造成的浪费,起到关键性的作用。大家可能在网上读到在美国软件项目管理的权威,写过很多关于软件管理方面的书,很有名一个理论就是说他做过很多研究和调查,发现早期的工作要是没有做好,而造成后面工作的返工,带来的浪费是巨大的。有类似这样的图表,他做出的结论,如果在设计阶段出现了问题,在设计阶段如果你没有及时找到和纠正的话,到执行阶段才发现,你会看到三条不同的曲线,越是早期的错没有发现,最后由于要返工而造成的代价费用越来越高,如果前面没有问题,到最后只是发现半个纠错,花费的代价相当低,因为你是纠错,然后重新测试就完了。可是如果执行的时候,程序编程编错了,后来重新编,重新测试,这个费用相对来说就要高。如果是设计的时候出现错误,由于对需求管理没有管理好,客户和市场的要求都错了,开发出来的东西完全到后面重新执行、重新纠错的话,会看到这个曲线,几乎是几何形上升的,成倍的费用的增加。能够保证控制产品开发过程中间的费用增加,早期工作完善,做设计的时候,越早做的越完善,对控制后面的消耗起的作用是非常大的。

    从这个方面讲,我早上举的例子造房子一样,造房子的蓝图,对盖一个房子的重要性,对早期设计的完善作用也是一样的。

    什么是设计规范书。大家听过很多不同的名称,叫法也不一样,到底是什么东西。首先它是总结一个软件功能和性能、使用方案的总结书,是描述一个产品,到底该为客户提供什么服务,起到什么样的作用,到底可以完成什么任务,从这个角度对软件产品做一个总结,是提供软件功能和性能以及使用方案的总结。也就是说,他应该包括的内容是向开发人员很详细的描写清楚,这个软件到底应该怎么工作,他使用方案的总结,他的功能性的总结,而不应该包括产品具体的设计的构架,到底怎么执行,怎么设计,这方面内容其实是有不的文档或者文件去总结的。早上也提到,作为开发团队人员,当设计经理、项目经理把软件功能定完以后,真正产品怎么开发,是应该由设计团队人员去做。在微软有的比较大型的团队,我们有所谓的设计师,具体开发也开发团队的领队和开发人员,他们每个人根据功能的描写总结出来具体设计的执行方案,这个其实是不应该写在设计规范书里的,所以要理解清楚,设计规范书是描写产品对客户怎么用,而不是描写这个产品具体开发逻辑怎么执行,这个是和开发有关系的。作为设计规范书是项目经理的工作,就是要把这个产品的功能描写清楚。它该包含的内容和不该包含的内容不要搞混乱。

    影响设计规范书的因素很多,首先最重要的是功能需求,客户对使用软件有它一定的要求,这个软件应该提供什么样的服务,该完成什么样的任务,这方面就叫做功能需求。其实是有不同的好几个因素来影响整个功能需求的,对市场竞争的分析,我们竞争的对手他的产品有什么样的功能,从而得出我们产品应该也有什么样的功能,甚至功能比他更好,这是对功能需求的起影响因素的。还有客户之间的回馈,他说我这个产品为我的行业做工作,这个和明显是客户具体的要求。还有就是用户解决问题的要求,比如说他说我不在乎你这个产品怎么开发,不管你以前的产品,或者你开发的产品以前有什么功能,由于要解决新的问题,必须加进这样的功能。还有用户所谓的使用方案,他真正解决问题,使用的方案流程是怎样的,由于他商业之间运行有直接关系,如果客户商业流程决定是这样的运作的顺序,你软件设备也应该要配合客户使用方案设计。所有这些是最关键的因素影响功能需求,功能需求也是第一个最要紧的影响到设计规范书该描述清楚的,解决的什么样的问题。

    除此之外是性能需求,光描写说我这个软件按一个键可以写一个数字还不够,如果是客户要求我按一个数字,在0.3秒之内写出来,或者是我按键以后印出五百万字来,他显示数据的速度怎么样,他的要求也是影响到设计规范书的。他包括整个系统的要求,如果大型的软件,运行的系统,什么样的硬件,什么样的内存存什么样的网络,所有这些对性能的需求都起到影响。他的运行的环境,到底是有没有兼容不同的操作平台,不同的操作平台之间不同。对软件的功能也是起到影响的,还有安装部署,特别是大型的系统,因为我在搞工业控制很多年也知道,安装部署的要求,软件在实验室完成跑到真正大型的工厂里,完全是另外一回事。环境的安装部署要求,在很脏的环境里,边上有各种干扰的因素,在这样的运行这样的软件,性能是不是有保证,保证不会死机,数据不会出现什么错误,或者出现错误有什么样的反应,这些都会影响到开发软件的要求。还有是质量要求,有一部分是能解决的,还有一部分是不能解决的,中间的质量要求是碰到什么情况能够对付,碰到什么情况怎么应付,这些不同的用户都会有详细的要求,这些都是规范设计书应该总结的内容。

    除了这些以外,还有非功能的要求,但是在设计的时候非得考虑到,包括地区、行业,甚至国家在某一个行业里的标准。象在欧美市场上,每个行业都有自己的标准。如果你是设计软件,为某一个行业设计,里面软件设计接口标准,可能使用数据规范,对于很多标准,如果你是对那些不熟悉,或者是不了解,甚至是用错的话,开发出来不符合那些客户要求就要改。这些和真正产品的功能毫无关系,可是要为了保证在以后产品开发出去避免这样的错误,由于这样的错误重新返归,就要把这些要求了解清楚。技术还有技术开发的局限,你想这样开发,你想提供这样的功能,但是首先得了解,目前客户所用的设备的硬件,或者他的运作的操作系统环境,有没有某些局限,你想开发性能的时候他没有办法达到,把这些事情弄很清楚的话,避免和客户讲不清楚的争论。在描写功能的时候,这个功能有什么样的能力,没有什么样的能力,描写的很清楚。

    还有对时间的依赖,对外在因素的依赖,这里面是需要时间的。项目管理上所谓三角形的定理,有这么多时间,你有这么多资源只能开发出这么多功能。如果把你的时间砍掉一半,其他因素不变的情况下,绝对不能按时间、质量研发出来。这些都会影响到你设计规范书的撰写,你要写得很清楚,软件开发哪些能力我是可以完成的,哪些是不可以完成的。还有可用性的需求,软件为了要赢得客户的心,赢得市场的心,很要紧的一点,不光是把软件开发出来大家可以用,客户用了不会觉得很混乱,还是很闹心,还是用起来很顺手,这里面的可用性,这些东西也是很重要。什么因素决定可用性,用户的特点,不同的用户,不同的使用者,也会决定软件开发应该按照适合他们的要求。开发出来的软件是给一些专门的设计人员用的,那些人受过高等教育,都是很熟悉的,和你开发出来给爷爷奶奶用,这里边不同的客户,都有专门的特性,所以在微软把不同的使用者,分成不同类型的组群,这里的要求怎么回事。所有这些都是影响到可用性需求。整个设计规范书在描写完善的软件过程,这些都要考虑到。你不考虑的,不在乎的就去写软件,等你开发出来这些搞错的话,一定影响软件最后的质量。

    软件规范书的读者,规范书是干什么的,为谁而写?作为开发管理人员项目经理到底做什么工作。第一个是给开发团队用的,构架设计、开发执行的计划。开发团队是第一位读者,需要拿这个来盖房子。除此以外,测试团队,在定测试计划的时候,也是根据你对功能的描述。所以如果一个软件里调出一千多个功能,就要定一千多,甚至三千、五千相对应的测试方案。测试团队也是设计规范书的读者。文档团队,要让客户能够很方便的了解、熟悉你这个软件的产品,很要紧一点你要有所谓的专门使用手册,如果软件是推向市场的,给爷爷奶奶用,从来没有用过这个软件的,看一个说明书怎么样可以帮助这些没有技术水平的人在很短的时间内用这些软件。文档协作很重要,编辑的人也不懂计算机,只能描述这个产品,他们所需要的内容也是从这里来的。可用性团队,他们要用产品找一些客户到内部进行调查,他们怎么设计测试,可用性的案例?他们也是要根据设计规范书的内容决定。最后就是市场营销团队,当你有一个完整的设计规范书,营销产品的时候,当产品完了以后向市场进行推销的时候,营销人员会比较清楚的了解,这个产品到底有什么样的功能,可以完成什么样的任务,然后向广大市场描写这个产品有什么好处。所以你看到设计规范书一般是为这么多团队,这么多人服务的。还有给客户领导,在你产品还没有开发之前,在你和客户交流的时候,我们在某一个产品,为他们专门设计的软件,在开发之前,并不是签一个协议,告诉我写一个东西,然后就开发了。开发之前如果有一个很完整的规范书,让客户从头到尾把我整个开发的计划了解清楚,开发的内容,我要提供的功能,能够提供的,不能提供的写的很清楚的话,他看了以后就会知道符不符合他的要求。帮助客户了解整个开发的计划,他给你进行回馈,帮你做调整,领导可以根据这个对整个项目进行跟踪。如果你都写清楚了,作为企业的领导,可以从高层次领导整个开发的计划,跟你原来的计划,定的时间表可以知道什么时候可以完成。所以起一个很好的交流作用,帮助团队和领导之间保持一致。

    在写规范书通常要经过什么样的步骤,做什么事情可以达到最后的结果?在你正在写之前,首先需要确定你要解决的问题,最要紧的是从市场需求来了解,我这个软件到底该做什么,这个软件是为什么样人服务的,做什么样的事情。定出你所要的功能之前,首先先要了解使用方案,三步法,知道客户的使用方案,从那个得出你的需求到底是怎样的。然后根据体的需求总结,定出你要设计的功能到底是哪些。由这些需求、总结定出这些功能,最后根据三步法设计功能。这样你设计的功能都是为了解决客户具体的使用方案,而不是设计的功能是毫无作用的。你不按照这样的方法做,常常让开发工程师自己随意开发出一些功能,功能开发出来看起来很不错,我们叫做很酷,可是不在客户的使用方案里起到具体的作用,可以在某一个软件的菜单上按一下可以做一些什么事情,可是客户根本用不着这个,这种开发出来是一个很大的浪费。让功能的建立设计在了解使用方案的基础上,由此得出的需求上就能避免浪费。这样每个开发出来的功能都是有目的的。

    写之前,在很多比较大型的、复杂的系统上,开发团队希望能够有一定的时间做一些技术可行性的调查,先写一个样品。设计经理认为我应该有这样的功能,可是这个开发团队认为说,你设计的功能可能不见得达到你这样的要求,我要看在我现行的平台上,用我现行的技术,可不可以设计出你所要的技术。在之前先做一个简单的调查,看是不是可行。样品做出来了,团队花时间写最后的规范书之前,在四面围着玻璃窗的房间里,把客户请来,做调查。整个使用方案的流程,按这个键可以灌入这个数字,可以起这个效果,你把这个不是真正的软件,是一个虚假,甚至用图象拼起来的,先把这个东西让客户用一下,看一下是不是符合你的要求。他用了说很不错,你就知道你的设计方案是对的,如果有50%认为不符合自己的要求,你就知道你的设计方案出问题了。最后你才定下来写规范书。规范书不是写完一次就完了,也是好几个回复,我们先写一个出版,把开发团队人员叫来,开发团队的领队,测试师、工程师都叫来,大家一起审核,设计这个东西是不是合理的。第一次出稿回来以后马上推翻了,开发团队说完全是不合理的东西,没有办法开发,一定要重新设计。先有出版,做审核,然后再写正版。有一个回复,可以完了以后这边再倒回去,这是一个流程。我这边写出来重点,非常要紧一点,作为我们项目开发的领导,你会看到每一个具体工作都是要时间的,都需要人去做。要定一个项目开发计划都没有算时间,如果要来回走五遍,可是你只有一遍的时候,你的计划一定要出错。最后写正版,然后审核,全部通过大家签字,说这是我们可以开发的。在某些情况下让客户签字,客户也同意了说你这个设计完全符合我的想法。如果前面的事情都做到家了,对你后面的事情是起到很大的作用。

    提纲的内容,通常在微软一般包括先写一个前沿,或者梗概,用非常简单的一小段解释这是给领导看或者是给客户看。你对产品开发高层次的理解是不是很清楚,总结你所开发的产品软件到底怎么做,有什么功能。你对一个产品的功能理解,是不是能够精简到几句话,不光你作为一个项目经理可以说出来,让你开发团队所有成员都能够明确无误的说出来,这是非常要紧的。特别是客户要求,你这个文件给他读的时候,可以很清楚的知道,对客户要求的理解是不是很清楚。等规范不完的时候,最后回去做对照。看一下我原来定的总结是要完成这些任务,最后设计完以后,回去对照是不是跟原来的计划一样的。从高层次帮你指导整个开发方向应该是怎样的。

    除了简单开头以后,要有一个比较详细的总结,整个文档的总结。不光是描述规范书的内容,其实还要帮助很多第一次读规范书的读者,能够有效的读你的规范书。有的规范书很长,很复杂,有各种各样的符号标记,怎么样理解你用的这些符号。一般的总结包括作者、日期、版本,有时候好几个版本放到内部网站中,你可以告诉他,应该看第三版,而不是第二版。这些内容都是帮助读者了解,设计规范书中的版本改动的历史是非常要紧的,因为在整个版本改动过程中,虽然全部完了,定稿大家签字了,在真正实行的发现有些功能漏掉的,最后还要去加。你的产品开发完了以后,发现有问题,让你的设计要改,作为设计规范书要回去重写。改动的部分要很明确的标出来不同的,在前面的总结加一些版本该都历史。这样追踪整个软件在开发历程过程中,什么时候发生什么问题,都会起一个很好的参照作用。很大一个产品,并不是一个设计规范书可以解决的,有时候是好几个、十几个设计规范书,好几个不同的项目经理一起来做的,作为一个客户,光读一本可能是不够的,你要做一套,好几本设计规范书,规范书之间他们相互的联系,你读之前可能参照那本,或者读这个以后,再读那本,之间的参照的内容也要写在规范书里。所以在文档总结里,把这些内容写在里面。

    这个项目重要成员,项目总结,包括开发团队的成员,开发团队或者测试团队联系方法。发现问题不知道该找谁,特别是团队的领队都要写在前面,联系方法。还有时间表的总结,你总的产品开发,大的里程碑,几月几号完成怎么样。还有对外部团队的依赖因素,很多开发可能都要靠好几个团队向你提供一部分功能,最后整合起来。在你产品做的时候,9月3号要完成的东西,但是8月30号我要让别的团队向我提供这些东西我9月3号就能完成,如果不能提供我9月3号就完不成。全都写清楚了,你才能知道。

    在很多情况下可能要写一个开发的理由,为什么要开发这个软件?特别是作为一个公司开发很多不同的软件下,作为别的团队或者领导,或者是市场营业经理,可能先要了解你这个软件是干什么的,在整个企业的战略情况下,整个战略方向为企业起什么作用。很多产品在开发,技术可能是相互交错的,要讲清楚为什么这个团队花这么多钱、这么多精力,开发这个技术,为什么不用别的团队已经有的技术,或者类似的技术,他们要按照什么样的建议开发,所有的东西都要写出来。一般的内容,我们做如下的解释,开发的理由,如果我不开发这个,或者我用别人的,或者我的功能不开发,对公司长期企业的效果起什么影响,对我们市场竞争能力带来什么影响。如果我们不开发,我们的竞争对手六个月之后开发出来,我们的市场可能从第一位降到第五、第六,领导看了以后就会感觉不一样,你要用具体的数字帮你们证明,为什么要开发这样的功能。还有所需要的资源、消费,和不开发带来费用比较也是很要紧的。我要开发什么东西,我要花这么多、精力、人和资源的消费,可是我如果不开发,我市场损失是什么,这就帮助领导或者客户做决定,什么情况下多少钱、多少功能你该做的。对成功企业的影响,对整个市场的影响,要开发不开发,或者现在开发几个月后开发,这个时间是不同的。在描写具体功能之前,先要讲为什么要开发这些东西。要很清楚你开发的目标,我们叫做远景目标。开发的目的是干什么,到底是开发什么样的。为什么要开发,你要讲清楚开发什么样的软件。这是总结和列出来你要开发的远景目标,归根到底要完成什么任务,达成什么目标。

    撰写内容,首先对公司企业战略上的影响,市场上的影响,技术上、功能上,所有的东西从这些层次来描写,我们该完成什么样的任务。你在开发前把目标定义清楚,后来帮助你做解决,什么情况下开发时用什么技术,如果符合我的目标就做,如果不符合我的目标,到那时候做决定,有全面目标做了到那时候起到很大的作用。

    如果是为单个客户开发产品相对来说容易的多,一般情况下你的产品是成千成万人用。这时候就要考虑到,要照顾到不同的用户,他们使用的产品能力不是一样的。对于不同层次的人使用者,对他们要达到的目标是什么,都要写清楚。你对这些做了总结,帮助你在后来做设计的时候,比较容易做出决定,你这个设计功能该怎么样设计。往往这些功能写和不写没有太大区别,最后软件不起到什么关键影响,可是由于做了这些工作,你作为设计人员,项目经理,逼迫你去思考这些问题,如果事先这些问题都没有想过,希望后来设计的软件都能达到前面的功能是不可能的。如果你事先做了,做了思考,跟开发团队商量了,做的这些都是有目的的。

    前面讲的是比较高层次的总结,在你描写真正开发的功能之前,就会讲到很要紧的总结使用方案。客户是如何用你的软件解决他的问题的,谁来用,是什么样的人,他们怎么用法,他们使用软件顺序是怎么样的,描写清楚。通常我们是用讲故事的方法,长三来上班,大概机器灌入一个数字,存了文档,交给李四,李四存了文档,这样用讲故事的方式来描写。还有很要紧的一点,你这样的描写,对测试团队起到一个巨大的帮助。他测试的时候,内部测试团队人员可以把自己想象成一个客户,可以按照你所描写的使用方案,测试团队来测试这个软件。按照你所描写的使用方案,按照顺序进行测试。这个是对测试团队设计他们的测试的方案起到很大的作用。

    从客户使用软件具体的使用方案总结出你的功能需求,他是这样用的,因为张三打开机器要先按这个键,应该有一个输出、输入栏,灌数据,按了以后生成文档,正因为有这样的使用流程,你的需求功能非得有这个键,有数个数据栏、有功能生成文档。前面描写的故事怎么使用的,后来设计总结这些需求功能是符合你这个故事的,保证你设计出来的功能是能够满足客户按照这个步骤执行他的方案。我们在微软内部按照三步法开发软件,其实是有他的道理的,他要避免你开发出来的功能是和前面使用方案毫无关系的,开发的时候造成浪费。满足具体的使用方案,从使用方案总结出来,因为长三按这个键关入数字是这样的工作,做功能描述的时候才描述细节,但首先要有这个键、数据栏。对可有可无的功能要把它的优先顺序写持续。我们所有的功能都有P1、P2、P3,定出来哪些东西是对客户来说是赢得市场最要紧的,非要开发,哪些是可有可无,哪些是可以放到下一代产品再开发。开发之前把这个事情都做好。

    有了这些以后,你才描述具体的功能。这里描写如何使用,前面先讲为什么要开发,如何开发,讲了这个软件为什么用,最后来讲这个软件是如何被客户使用的。这部分对所有的功能,所有的界面设计做一个详细的叙述。对这部分内容可以按照使用方案,从头到尾把你使用的功能用图象画出来,可以用文章总结。使用大量的图象很要紧,因为你图象化以后,帮助测试人员怎么样测试,帮助开发人员开发出来的功能是要符合你设计的图象。你画出图象,可以让可用性的工程师,根据这个造样品,然后找客户做使用性的调查。这些东西帮助管理整个使用功能控制操作和质量。

    除此以外,还有很要紧的一点,在设计过程中间,常常有很多还没有解决的问题,在设计功能中间,并不是说什么东西解决了就可以开发了,产品已经在开发了,可是还有很多东西没有解决。某些技术性的问题,我等别的团队告诉我,或者有些技术性问题我等着调查,或者有些技术问题不知道,我买了硬件以后,做了平台以后做调试才知道,所谓这样都不能遗漏,为了防止这些问题都忘记,把这些问题也写到规范书里,有一个表格全部列到里面,有这样的方法就知道,整个开发过程中,让你可以随时回去看,这些没有解决的问题是不是已经被解决了,几月几号该被解决,哪些还要被调查,哪些还要被进一步决定。把没有解决的问题列出来,做个总结,谁对这个问题负责,比如某个技术调查问题是开发团队来做的,把这些该负责的人名字写在里面。目前他的状态到底有没有解决,有的已经解决或者是已经正在调查,在一个表里列出来,分成三档。有这样一个总结很明显的帮助你追踪没有解决的问题,在开发过程中状态是怎样的。如果项目过大的话,甚至可以把这个内容拿出来,专门再写一个额外的文件,一个专门的文档专门来总结这样的东西,给别的团队的人看,不见得一定在设计规范里,但是这些内容帮助你把该解决的问题记下来,帮助事后追踪管理这个过程。

    怎么写?我们有这个提纲内容,真正写提纲一般是这样的,首先是你组织内容材料,写之前保证我该写的内容写在里面,就象每一节对照提纲,把你的各种想法写出来。刚开始是用倾斜的方式,不见得写的非常完善,但是保证该写的内容在里面,然后回去慢慢再改。很注意要明确你读者的类型,刚刚提到规范书是由设计工程师、测试工程师看的,文档编辑要看,他们对设计规范书有他们的期望,他们了解的内容,你在写的时候要保持在脑子里,写的时候一定要把这些不同读者的内容写进去。最后写你的内容,把内容尽量写的清晰、简短,用大量的图象描述你软件开发的思路,比你用千万的句子来写更好,有一幅画定千万字的说法。

    增进版本的设计规范书,有时候我写一个规范书,并不是一个新的版本,我们公司已经有这个产品了,已经在市场上。我们现在这个公司正在做一个增订型的,做下一个版本,这个时候在以前已有的产品基础说我要做什么样的改变。要解决以前没有解决的问题,为什么现在开发,要解决以前没有解决的问题,我用什么样的设计,改变上一代的设计没有解决的问题。如果写崭新的产品就不会有这个问题,但是很多情况下我们的产品已经有了,我们只是要不停的增进,这种情况下要写这个内容。还有一点,设计界面的操作行为,不光是有一个图画,有一个键、数据栏、图象,还要很清楚的描述这个键我按了以后会发生什么情况,数字灌进去会发生什么情况,有时候用鼠标控制的,鼠标到底是左键按下去发生什么情况,右键按下去发生什么情况,这些都要列在里面。你盖一栋房子,描写的很清楚,用什么样的砖、瓦盖这个房子,用什么样的门窗、玻璃描写很清楚,盖出的房子一定是你所需要的,如果你画的是很大的很粗糙的草图,你盖的房子可能不是你所需要的。还有不要忘记一些基本的文章的结构不要忘记,包括标题、日记、版本数,还有页数,前面的目录、章节,不同的章节用什么标记表明的。别人读两三百页厚的设计版本会不会头脑发昏,怎么样让读者理解你的东西,都要写在里面。还有公司项目内部名称,如果公司项目很多的话,有时候项目有代号,代号太多可能读者搞不清楚,对项目内容做一个解释。很多情况下文档是内部使用,作为公司保密的,不能流传出去。你作为项目经理要写的很清楚,告诉团队成员,这个产品开发不能把这个文档公开给别人。在写一个完整的设计文档的时候,这些规范书里都要写在里面。

    软件设计规范书的图示,我们现在正在开发的软件,有一个图象表示里面各种软件组成部分是什么东西,除此以外会看到,用标记来标出来具体使用界面的元素到底是干什么的,按了这个键以后,每个键起什么作用。我现在做的设计,我觉得是把已有的软件拿来,配上画图的软件,把已有的软件使用界面的元素拼凑起来,设计出来的软件看起来好象真的一样。虽然现在没有这样的软件,但是已经有这样的图象,拿这个给测试人员、测试团队或者项目文档编辑人员看,他们就一目了然,知道这个软件怎么回事。但是这样的做法很多人觉得很麻烦,我不会画图。还有一个方法,微软里有一个使用界面设计的模板,这不是一个真的软件,但是画出来和真的差不多。描述每一个具体的功能里面到底做什么。

    需求总结,比较简单的方法就是用一栏,用数字,分成几个大的档次,比较通用的我们叫做第1,有这个数字可以比较容易,当设计有问题了,当和别人谈话的时候,读我的需求规范总结去读我的1A等等,可以找到。有菜单,上面有什么选择全在上面,菜单下面都有一个横杠,当时设计的时候没有这个,当时测试团队找我抱怨,说没有把这个标清楚,开发团队也没有测出来,我测试的时候也没有办法测试。所以我现在学会了,我都写的很清楚。某个菜单按右键,都写的很清楚。在早期设计的时候到后来的时候确定是错误的,需要去掉的。测试人员测试的时候看到原来设计是有的,后来决定没有,全部写在里面,让测试人员看得很清楚。然后描写所有使用界面,软件启动的时候看到怎么回事,详细的功能也会看到。储标键怎么用会有详细的描述,如果没有详细描述的话,测试人员不知道,有了这样功能详细的描述,对规范书进行审核的时候,大家都会了解,你这个设计原来是这样的,这个是合理或者是不合理的。每个软件使用界面的元素,都是用一个表格进行总结的。首先是干什么用的,很重要的一点他的行为是什么,然后把他的行为全部列出来,因为这些是帮助开发、测试团队测试开发出来的功能,能不能达到,行为能不能适合符合标准。抓放的过程在什么样的情况下发生什么情况,描述的很清楚。所有使用界面里元件是怎么样的,改用什么字标全部列出来。光标是什么形状,该用什么颜色,设计完以后,开发团队通过开发人员按照这个开发,就不会争论不清楚,不下来以后就避免理解的混乱。整个软件功能规范描述用很多图象标出来的话,就省得你花很多时间进行字的描述,但是关键的行为描述出来,关键的图象开发人员就可以轻松的按照你这个图象去开发。

     

     

     

     

    展开全文
  • MySQL 设计开发规范

    千次阅读 2015-09-19 01:32:11
    MySQL 经典设计与编写规范, 程序员必读规范之一...

    1 目的

          本规范的主要目的是希望规范数据库设计与开发,尽量避免由于数据库设计与开发不当而产生的麻烦;同时好的规范,在执行的时候可以培养出好的习惯,好的习惯是软件质量的很好保证。

     

    2 适用范围

         本规划的适用人员范围包括涉及数据库设计与开发的相关技术人员。

     

    3 术语约定

        本规范采用以下术语描述:

    ★规则:也称为强规范是编程时必须强制遵守的原则

    ★建议:编程时必须加以考虑的原则

    ★说明:对此规则或建议进行必要的解释

    ★示例:对此规则或建议从正、反两个方面给出

     

    4 规范及建议

    4.1 书写规范

    4.1.1 SQL书写规范

    规则1: 数据库代码中,关键字大写,其他内容小写;

    示例:

    如下代码不符合规范:(关键字未大写)

    select last_name ,job_id

    from employees;

     

    如下代码符合规范:

    SELECT last_name, job_id

    FROM employees;


    规则2:程序块应采用缩进风格书写,保证代码可读,风格一致,缩进格数统一为4格;

     

    规则3:代码中需要空位时,统一采用英文空格键输入,不允许用TAB键 产生空位;

    说明:不同的编辑器对TAB的空位格数设置不一致,会导致使用TAB键产生空位的代码格式混乱;

     

    规则4:同一条语句占用多行时,每一行的开始应是关键字, 且关键字应和第一行左对齐,如确实不能从关键字分行,则分行处应对其上一行被分行的同类代码的最左边;

    示例:

    如下代码不符合规范(分行书写时,其余行未和第一行左对齐)

    SELECT last_name,

    job_id

    FROM employees;

     

    如下代码也不符合规范(分行时,不是从关键字分行)

    SELECT last_name,

    job_id FROM employees;

     

    如下代码符合规范

    SELECT last_name, job_id

    FROM employees;

     

    如下代码符合规范

    SELECT last_name,

           first_name,

           job_id

    FROM employees;

     

    规则5:查询数据时,尽量不使用SELECT *,而是给出明确的字段,但该规则不包括SELECT COUNT(*)语 句;

    示例

    如下语句不符合规范(SELECT操作未给出字段)

    SELECT *

    FROM employees;

     

    如下语句符合规范

    SELECT last_name, first_name

    FROM employees;

     

    规则6:INSERT语句应该给出字段列表;

    示例

    如下语句不符合规范(INSERT操作未给出字段名称)

    INSERT INTO employees

    VALUES

    (

        'GUO',

        'DAVID',

        100

    );

    如下语句符合规范

    INSERT INTO employees

    (

        last_name,

        first_name,

        job_id

    )

    VALUES

    (

        'GUO',

        'DAVID',

        100

    );

     

    规则7:从表中同一笔记录中获取记录的字段值,须使用一SQL语句得到,不允许分多条SQL语句;

    示例

    如下语句不符合规范(从同一个表中取出记录,分成两条语句分别扫描)

    UPDATE employees_new

    SET last_name=

    (

        SELECT last_name

        FROM employees

        WHERE job_id = 100

    )

    WHERE job_id = 100;

     

    UPDATE employees_new

    SET first_name =

    (

        SELECT first_name

        FROM employees

        WHERE job_id = 100

    )

    WHERE job_id = 100;

     

    如下语句符合规范

    UPDATE employees_new

    SET first_name =

    (

        SELECT last_name

        FROM employees

        WHERE job_id = 100

    ),

    last_name =

    (

        SELECT first_name

        FROM employees

        WHERE job_id = 100

    )

    WHERE job_id = 100;

     

    规则8:SQL语句中的逗号后面应增加一个空格,以使得代码清晰;

    示例

    如下代码不符合规范(逗号后面没有空格)

    SELECT last_name,job_id

    FROM employees;

     

    如下代码符合规则

    SELECT last_name, job_id

    FROM employees;

     

    规则9:不允许将SQL语句写成一行,再短的SQL也应该在谓词处分行;

    示例

    如下代码不符合规范(未在谓词部分进行分行)

    SELECT last_name, job_id FROM employees WHERE job_id = 1;

     

    如下代码符合规范

    SELECT last_name, job_id

    FROM employees

    WHERE job_id = 1;

     

    规则10:运算符以及比较符左边或者右边只要不是括号,则空一格;

    示例

    如下代码不符合规范(运算符没有空格)

    SELECT CURRENT_DATE+INTERVAL 1 DAY

    FROM dual;

     

    如下代码符合规范

    SLEECT CURRENT_DATE + (INTERVAL 1 DAY)

    FROM dual;

     

    规则11:不同类型的操作符混合使用时,应使用括号明确的表达运算的先后关系;

    示例

    如下代码不符合规范(运算优先级关系易混淆)

    SELECT a*b/c+d*e

    FROM dual;

     

    如下代码符合规范

    SELECT ((a * b) / c) + (d * e)

    FROM dual;

     

    规则12:任何SQL书写单行不得超过120字符(含左边的缩进);

     

    建议1:对于INSERT…VALUES和UPDATE语句,一行写一个字段,每个字段相对于INSERT语句空4格,字段后面紧跟注释(注释语句左对齐),VALUES和INSERT左对齐,左括号和右括号与INSERT、VALUES左 对齐;

    示例:

    如下代码不符合建议(字段未和INSERT语句空格)

    INSERT INTO sm_user

    (

    user_id,   --用户ID,主键

    user_name, --用户名

    login_name --登录名

    )

    VALUES

    (

    p_user_id,

    p_user_name,

    p_login_name

    );

     

    如下代码符合建议

    INSERT INTO sm_user

    (

        user_id,   --用户ID,主键

        user_name, --用户名

        login_name --登录名

    )

    VALUES

    (

        p_user_id,

        p_user_name,

        p_login_name

    );

     

    建议2:INSERT…SELECT 语句时,应使每行的字段顺序对应,以每行最多不超过4个字段,以方便代码阅读,括号的内容另起一行缩进4格开始书写,关键字单词左对齐,左括号、右括号另起一行与左对齐;

    示例

    如下代码不符合建议(字段未和括号分行)

    INSERT INTO sm_duty_bak(duty_id, duty_name, created_by, creation_date,

    last_updated_by, last_update_date, disable_date)

    SELECT duty_id, duty_name, created_by, creation_date,

    last_updated_by, last_update_date, disable_date

    FROM sm_duty

    WHERE duty_id=88;

    如下代码符合建议

    INSERT INTO sm_duty_bak

    (

        duty_id, duty_name, created_by, creation_date,

        last_updated_by, last_update_date, disable_date

    )

    SELECT

        duty_id, duty_name, created_by, creation_date,

        last_updated_by, last_update_date, disable_date

    FROM sm_duty

    WHERE duty_id = 88;

     

    说明:

    1.SELECT 语句中每行的字段应与INSERT 语句对应。

    2.INSERT 语句中换行的字段名应缩进并与上一行的第一个字段名对齐。

    3.SELECT 语句中换行的字段名应缩进并与上一行的第一个字段名对齐。

     

    4.1.2 存储过程书写规范

    规则1:不允许将多行语句书写在同一行;

    示例

    如下代码不符合规范(将两行定义书写在同一行)

    SET v_count = 1; SET v_creation_date = CURRENT_DATE;

     

    如下代码符合规范

    SET v_count = 1;

    SET v_creation_date = CURRENT_DATE;

     

    规则2:相对独立的程序块之间应加空行;

    示例

    如下代码不符合规范(变量定义和程序段之间无空行)

    SET v_duty_id = 1;

    IF (v_disabled_date >  v_current_date) THEN

        SELECT duty_name

        into v_duty_name

        FROM sm_duty

        WHERE duty_id = :duty_id;

        …

    END IF;

    如下代码符合规范

    SET v_duty_id = 1;

     

    IF (v_disabled_date >  v_current_date) THEN

        SELECT duty_name

        into v_duty_name

        FROM sm_duty

        WHERE duty_id = :duty_id;

        …

    END IF;

     

    规则3:当一个SQL 语句中涉及到多个表时,始终使用别名来限定字段名,这使其它人阅读起来更方便,避免了含义模糊的引用,其中能够通过别名清晰地判断出表名;

    说明 : 别名命名时,尽量避免使用无意义的代号a、b 、c… , 而应该有意义( 如表mtl_system_items_b 对应别名为msi,po_headers_all 别名对应为pha)。

    示例

    如下语句不符合规范(未使用有明确含义的表别名)

    SELECT a.wip_entity_name, a.wip_entity_id, a.date_released

    FROM wip.wip_entities b,

    wip.wip_discrete_jobs a

    WHERE b.wip_entity_id = a.wip_entity_id

    AND a.status_type = 3

     

    如下语句符合规范

    SELECT wdj.we_entity_name, wdj.wip_entity_id, wdj.date_released

    FROM wip.wip_entities we,

               wip.wip_discrete_jobs wdj

    WHERE we.wip_entity_id = wdj.wip_entity_id

    AND we.status_type = 3

     

    规则4:确保变量/参数的类型和长度与表数据字段的类型和长度相匹配;

    说明:如果与表数据列宽度不匹配,则当较宽或较大的数据传进来时会产生运行异常。

    示例

    如下代码不符合规范(假定表wap_user的字段user_name的定义为VARCHAR(10))

    CREATE PROCEDURE ps_add()

    BEGIN

          DECLARE v_user_name VARCHAR(15); 

          UPDATE wap_user

          SET user_name = v_user_name

          WHERE sky_id = 100;

    END;

    如下代码符合规范

    CREATE PROCEDURE ps_add()

    BEGIN

          DECLARE v_user_name VARCHAR(10); 

          UPDATE wap_user

          SET user_name = v_user_name

          WHERE sky_id = 100;

    END;

     

    规则5:存储过程代码块必须有注释;

     

    建议1:减少控制语句的判断次数,比如在ELSE(IF…ELSE) 语句中,尽量将尽快能检测到结果的判断放在前面;

    示例

    如下语句不符合规范(假定v_count=1的条件大多数情况会满足)

    IF (v_count = 0) THEN

        NULL;

    ELSEIF (v_count = 1) THEN

        NULL;

    END IF;

     

    如下语句符合规范(假定v_count=1的条件大多数情况会满足)

    IF (v_count = 1) THEN

        NULL;

    ELSEIF (v_count = 0) THEN

        NULL;

    END IF;

     

    建议2:尽量避免使用嵌套的IF语句,在这种情况下应使用多个IF语句来判断其可能性;

    示例

    如下语句不符合规范(使用了嵌套的IF语句来进行判定)

    IF v_count = 0 THEN

        IF v_flag = 0 THEN

            NULL;

        ELSE

            NULL;

        END IF;

    ELSE v_count = 1 THEN

        IF v_flag = 0 THEN

            NULL;

        ELSE

            NULL;

        END IF;

    END IF;

     

    如下语句符合规范

    IF (v_count = 0) AND (v_flag = 0) THEN

        NULL;

    ELSEIF (v_count = 0 ) AND (v_flag = 1) THEN

        NULL;

    ELSEIF (v_count = 1) AND (v_flag = 0) THEN

        NULL;

    ELSEIF (v_count = 1) AND (v_flag = 1) THEN

        NULL;

    END IF;

     

    建议3:存储过程、函数、触发器、程序块中定义的变量和输入、输出参数在命名上有所区分;

    说明:

    用'v_ '开头代表程序块中定义的普通变量。

    用'p_ '开头代表输入参数变量。

    用'x_ '开头代表输入输出或输出参数变量。

    用'cur_'开头代表游标变量。存放游标记录集。

     

    4.2 对象命名规范

    4.2.1 通用规则

    规则1:任何数据库对象的命名,不得使用汉字;

    示例

    如下语句不符合规范(表明和字段名使用了汉字)

    CREATE TABLE 用户

    (

        用户名 VARCHAR(100),

        pass_word VARCHAR(16)

    );

     

    如下语句符合规范

    CREATE TABLE wap_user

    (

        user_name VARCHAR(100),

        pass_word VARCHAR(16)

    );

     

    规则2:库名,表名,字段名不得超过30个字符,用户名不得超过16个字符;

    库名,表名,字段名最多支持64个字符,为了统一规范、易于辨识以及减少传输量,必须不超过30个字符。

    示例

    如下语句不符合规范(表命名达到65位长度)(修改)

    CREATE TABLE wap_user_tel_number_region_user

    (

        user_name VARCHAR(100),

        pass_word VARCHAR(16)

    );

     

    如下语句符合规范

    CREATE TABLE wap_user_tel_number_region

    (

        user_name VARCHAR(100),

        pass_word VARCHAR(16)

    );

     

    规则3:用户对象命名应全部为小写,使用下划线“_”分割;

    说明:由于linux操作系统上的文件名是区分大小写的,所以MySQL表名是区分大小写的。

    示例

    如下语句不符合规范(表名应全部为小写)

    CREATE TABLE Wap_user_tel_number_region

    (

        user_name VARCHAR(100),

        pass_word VARCHAR(16)

    );

     

    如下语句符合规范

    CREATE TABLE wap_user_tel_number_region

    (

        user_name VARCHAR(100),

        pass_word VARCHAR(16)

    );

     

    规则4:命名应使用富有意义的英文,禁止使用拼音首字母, 一般情况下不建议使用拼音命名;

    示例

    如下语句不符合规范(表名使用了中文且字段使用了拼音首字母简写)

    CREATE TABLE wap_yonghu

    (

        yhm VARCHAR(100),

        pass_word VARCHAR(16)

    );

     

    如下语句符合规范

    CREATE TABLE wap_user

    (

        user_name VARCHAR(100),

        pass_word VARCHAR(16)

    );

     

    规则5:命名不得使用数据库保留字;

    说明:使用了数据库保留字,会导致需要访问该对象时,需要代码做特别的转换才能访问

    示例

    如下代码不符合规范(假定user为数据库保留字)

    CREATE TABLE wap_user

    (

        USER VARCHAR(100),

        pass_word VARCHAR(16)

    );

     

    如下代码符合规范

    CREATE TABLE wap_user

    (

        user_name VARCHAR(100),

        pass_word VARCHAR(16)

    );

     

    4.2.2 表

     

    规则1:同类业务的表,以相同的表示该类业务的英文开头;

    说明:同类业务的表以相同的英文开头,在逻辑上清晰,且可避免维护过程中对该类表的误操作

    示例

    如下语句不符合规范(假定表wap_user和表user_login_log都属于wap类业务)

    CREATE TABLE wap_user

    (

        user_name VARCHAR(100),

        pass_word VARCHAR(16)

    );

     

    CREATE TABLE user_login_log

    (

        user_name VARCHAR(100),

        login_date DATE

    );

     

    如下语句符合规范

    CREATE TABLE wap_user

    (

        user_name VARCHAR(100),

        pass_word VARCHAR(16)

    );

     

    CREATE TABLE wap_user_login_log

    (

        user_name VARCHAR(100),

        login_date DATE

    );

    说明:各子系统不用加子系统名称前缀,如POS系统的表不用都加pos_前缀,如果遇到需要同步其他系统的表的表名与本系统的表名相同时,用子系统名称做后缀的形式重命名其他子系统表名,如POS系统需要同步MDM表bill_item_dtl而POS系统也存在这样的表名,则把MDM的表名重新命名为bill_item_dtl_mdm。

     

    规则2:同类表,如果按照时间不同建立的表,后缀格式一般情况下应为’_YYYY[MM[DD]]’格式;

    示例

    如下语句不符合规范(将年份2010简写为10,导致含义模糊)

    CREATE TABLE wap_user_login_1004

    (

        user_name VARCHAR(100),

        login_date date

    );

     

    CREATE TABLE wap_user_login_1005

    (

        user_name VARCHAR(100),

        login_date DATE

    );

     

    如下语句符合规范

    CREATE TABLE wap_user_login_201004

    (

        user_name VARCHAR(100),

        login_date DATE

    );

     

    CREATE TABLE wap_user_login_201005

    (

        user_name VARCHAR(100),

        login_date DATE

    );

     

     

    4.2.3 字段

    规则1:字段命名应具有含义,能反映该字段存储的内容,且字段应增加字段备注;

    示例

    如下语句不符合规范(假定存储的字段为用户名和密码,如下的字段名毫无意义也没有备注)

    CREATE TABLE wap_user

    (

        col1 VARCHAR(100),

        col2 VARCHAR(16)

    );

     

    如下语句符合规范

    CREATE TABLE wap_user

    (

        user_name VARCHAR(100),

        pass_word VARCHAR(16)

    );

     

    如下语句是使用了无意义字段名,但增加了字段说明,不作为推荐方法,但确实字段名无法表述含义时,必须使用该方法;

    CREATE TABLE wap_user

    (

        col1 VARCHAR(100) comment 'username',

        pass_word VARCHAR(16) comment 'password'

    );

     

    规则2:同种用途的字段,在所有表中,应保持有同样的字段类型和字段长度,并尽量保持一致的字段命名;

    示例

    如下语句不符合规范(字段user_name在两个有业务关系的表中字段长度不一致,易导致业务接口冲突)

    CREATE TABLE wap_user

    (

        user_name VARCHAR(100),

        pass_word VARCHAR(16)

    );

     

    CREATE TABLE wap_user_login_log

    (

        user_name VARCHAR(80),

        login_date DATE

    );

     

    如下语句符合规范

    CREATE TABLE wap_user

    (

        user_name VARCHAR(100),

        pass_word VARCHAR2(16)

    );

     

    CREATE TABLE wap_user_login_log

    (

        user_name VARCHAR(100),

        login_date DATE

    );

     

    以下是建议的公共字段名称及类型

    create_user

    VARCHAR(32)

    建档人

    create_time

    datetime

    创建时间

    update_user

    VARCHAR(32)

    更新人

    update_time

    datetime

    更新时间

    remark

    VARCHAR(255)

    备注

    contact_name

    VARCHAR(32)

    联系人

    tel

    VARCHAR(20)

    电话号码

    mob

    VARCHAR(20)

    手机号码

    address

    VARCHAR(100)

    联系地址

    zip_code

    VARCHAR(10)

    邮编

    identity_card

    VARCHAR(25)

    身份证号

    fax

    VARCHAR(20)

    传真

    email

    VARCHAR(64)

    电邮

     

    建议1:   字段名建议不要用JAVA关键字来命名,;

     

    4.2.4 主键

    规则1:涉及到要做分库分表的表用有序UUID做主键,UUID主键类型选择CHAR(32);

    规则2:不涉及分库分表的表选用自增长ID做主键,主键类型使用unsigned int或unsigned big int;

    规则3:主键无特别要求的,字段名统一定义为 id;

     

    4.2.4 外键

    规则1:外键名应以”fk_”开头,后接表名;

    示例

    如下语句不符合规范(外键名未以fk_开头)

    alter table wap_user_login_log

    add constraint wap_user_login_log_f foreign key(user_name) REFERENCES tb_user_name(user_name)

    如下语句符合规范

    ALTER TABLE wap_user_login_log

    ADD CONSTRAINT fk_wap_user_login_log FOREIGN KEY(user_name) REFERENCES tb_user_name(user_name)

    规则2:不同的表的外键,如果引用的是相同表的相同字段,则外键字段名及类型应保持一致;

     

    4.2.5 索引

    规则1:唯一索引应以”uk_”+”表名_”+”字段名”命名;

    示例

    如下语句不符合规范(唯一索引未以uk_开头)

    ALTER TABLE wap_user

    ADD UNIQUE wap_user_username_u (username)

    如下语句符合规范

     ALTER TABLE wap_user

     ADD UNIQUE uk_wap_user_username (username)

     

    规则2:普通索引应以”idx_”+”表名_”+“字段名”命名;

    示例

    如下语句不符合规范(不符合索引命名规范)

    ALTER TABLE wap_user

    ADD INDEX wap_user_user_id_idx (user_id)

    如下语句符合规范

    ALTER TABLE wap_user

    ADD INDEX idx_wap_user_user_id (user_id)

     

    规则3:全文索引索引应以”fullidx_”+”表名_”+“字段名”命名;

     

    4.2.6 视图

    规则1:视图命名应以“v_”+“表名[_表名[_表名]]”命名,如果表名过多可以用“v_”+“功能描述”来命名;

    示例

    如下语句不符合规范(视图和表是不可以同名的,如下语句会引起错误且不符合规范)

    CREATE VIEW wap_user

    AS

    SELECT first_name, last_name, job_id

    FROM wap_user;

     

    如下语句符合规范

    CREATE VIEW v_wap_user

    AS

    SELECT first_name, last_name, job_id

    FROM wap_user;

     

    4.2.7 函数

    规则1:函数命名以”func_”开头,后接函数的功能;

    示例

    如下语句不符合规范(未以func_开头)

    CREATE FUNCTION get_money

    BEGIN

    ……

    END;

    如下语句符合规范

    CREATE FUNCTION func_get_money

    BEGIN

    ……

    END;

     

    4.2.8 存储过程

    规则1:存储过程以“proc_”开头,后接功能描述;

    示例

    如下语句不符合规范(未以proc_开头)

    CREATE PROCEDURE update_user

    BEGIN

    ……

    END;

     

    如下语句符合规范

    CREATE PROCEDURE proc_update_user

    BEGIN

    ……

    END;

     

    4.2.9 触发器

    规则1:触发器以“trig_”+表名+“_ins/del/upd”+”_before/after”命名;

    示例

    如下语句不符合规范(未遵循命名规范)

    CREATE TRIGGER trigger1

    AFTER DELETE ON wap_user

    BEGIN

    ……

    END;

     

    如下语句符合规范

    CREATE TRIGGER trig_wap_user_del_after

    AFTER DELETE ON wap_user

    BEGIN

    ……

    END;

     

    4.2.10 临时表

    规则1:临时表以“tmp_”开头,后接功能描述;

    示例

    如下语句不符合规范

    CREATE TEMPORARY TABLE tab_tmp1

    (

    user_name VARCHAR(100),

    pass_word VARCHAR(16)

    );

     

    如下语句符合规范

    CREATE TEMPORARY TABLE tmp_wap_user

    (

    user_name VARCHAR(100),

    pass_word VARCHAR(16)

    );

     

    规则2:如果是在上线/割接中被重命名的表,命名应是原表名+“_YYYYMMDD”;

    示例

    如下语句不符合规范(临时表以old结尾,而非日期结尾)

    RENAME TABLE wap_user TO wap_user_old;

    如下语句符合规范

    RENAME TABLE wap_user TO wap_user_20100416;

     

    4.2.11 用户及数据库名

    规则1: 数据库名:retail_前缀+模块名,如POS系统的数据库名为retail_pos,MDM的数据库名为retail_mdm,用户名与数据库名尽量一致;

    示例

    如下语句符合规范

    retail_pos    pos系统

    retail_mps    营促销系统

    retail_oc      订单中心

    retail_pms    采购管理系统

    retail_mdm    mdm

    retail_gms    货品管理系统

    retail_fms    财务管理系统

    4.3对象设计规范

    4.3.1 表设计

    规则1:数据库设计文档中,必须包含表数据保留时间;

    规则2:数据库设计文档中,必须包含表在最大保留时间下的数据量;

    规则3:数据库设计文档中,必须包含表的读写频率;

    规则4:和其他表有关联的表,和其他表功能一致的字段类型以及长度,尽量使用相同的列名;

    规则5: 每个表应设计一个主键;

    规则6:数据库字符集,表字符集,字段字符集统一选用UTF8字符集,校对规则统一使用大小写敏感的utf8_bin;

    规则7:表引擎选用INNODB引擎;

    规则8:必须要有表的注释,用于描述表的功能;

     

    建议1:对于需要同步到数据仓库的表,原则上必须包含同步频率以及同步机制;

    建议2:历史表后缀建议用“_hist”;

     

    4.3.2 字段

    规则1:字段必须要有注释信息,如果字段的值是有限的(如状态值只有“有效”、“无效”,如性别只有“男”、“女”等)必须在字段注释中对每个值表达的意思进行描述;

    规则2:定长字符列使用CHAR类型, 不定长字符型使用VARCHAR类型;

    规则3:日期字段只需要表达年月日的选用DATE类型,需要表达年月日时分秒的字段选用DATETIME类或TIMESTAMP类型,但请注意各自能表达的范围以及TIMESTAMP的时区特性;

    说明:MySQL中的DATETIME对应ORACLE的DATE类型,而MySQL的DATE类型只是ORACLE DATE类型的年月日部分不包括时分秒部分,MySQL TIME类型是ORACLE DATE 类型的时分秒部分,下表是MySQL各时间类型的格式样例

     

    Data Type

    “Zero” Value

    DATE

    '0000-00-00'

    TIME

    '00:00:00'

    DATETIME

    '0000-00-00 00:00:00'

    TIMESTAMP

    '0000-00-00 00:00:00'

    YEAR

    0000

         

    DATETIME与TIMESTAMP类型的区别

     

    DATETIME

    TIMESTAMP

    存储长度

    8字节

    4字节

    时区支持

    不支持

    支持

    表达范围

    1000-01-01 00:00:00 

    9999-12-31 23:59:59

    1970-01-01 00:00:01

    2038-01-19 03:14:07

    保存格式

    实际格式保存

    UTC格式

     

    规则4:ORACLE转MySQL之NUMBER字段类型转换;

    number(M,N)如果N是0则为整形,对应MySQL的整形类型,下面是MySQL的各整形类型的所需字节数及能表达的范围(摘抄至官网5.6),

    Type

    Storage

    Minimum Value

    Maximum Value

     

    (Bytes)

    (Signed/Unsigned)

    (Signed/Unsigned)

    TINYINT

    1

    -128

    127

     

     

    0

    255

    SMALLINT

    2

    -32768

    32767

     

     

    0

    65535

    MEDIUMINT

    3

    -8388608

    8388607

     

     

    0

    16777215

    INT

    4

    -2147483648

    2147483647

     

     

    0

    4294967295

    BIGINT

    8

    -9223372036854775808

    9223372036854775807

     

     

    0

    18446744073709551615

    如果number(M,N)中N大于0则对应MySQL的decimal类型,如oracle的number(5,2)则MySQL为decimal(5,2),值得注意的是,在超出范围的情况下ORACLE会报错,而MySQL会取它能表示的最大值来替代原来的值,如decimal(5,2)/number(5,2)能表达的范围为 -999.99-999.99 如果要插入1000的数据,oracle会提示超表达范围的错,而MySQL会以999.99来替代

     

    规则5:固定长度的字符串使用CHAR,单字符字段使用CHAR(1)类型;

    规则6:字段避免使用NULL值,用默认值来替代,修改时间,审核时间等用“0000-00-00 00:00:00”这样的默认值进行替代,备注用‘’的空字符进替代;

    规则7:不建议使用ENUM,SET类型,用TINYINT替代;

     

    建议1:   尽量不使用BLOB,TEXT类型,大字段建议单独设计表,通过关联进行查找;

    建议2:   建议使用UNSIGNED 存储非负数值;

    同样的字节数,存储的数值范围更大

    4.3.3 索引

    规则1:   无特别说明,每个表的索引不得超过5个;

    规则2:   单字段上的索引不得超过2个;(即一个单字段最多可在上面建立一个单字段索引和一个组合索引包含这个字段)

    规则3:   复合索引原则上不得超过3个字段;

    规则4:   外键列需要创建索引;

     

    建议1:   频繁出现在where子句里的字段建议建立索引;

    建议2:   用来和其他表关联的字段建议建立索引;

    建议3:   索引字段建议有高的选择性和过滤性(count(distinct)/count(*)>0.6);

    建议4:   建立索引的时候,建议考虑到SELECT和INSERT,UPDATE,DELETE的平衡;

    建议5:   一般建议在查询数据量10%以下使用索引;

    建议6:   WHERE子句的查询条件构成索引字段前导字段;

    建议7:   选择性更高的字段放在组合字段索引的前导字段;

    建议8:   如果字段选择性接近,则把频繁查询的字段放在前面;

    建议9:   进行GROUP BY或者是ORDER BY的字段应在组合字段索引的前导字段;


    4.3.6 视图

    规则1:视图中不允许出现ORDER BY排序;

    规则2:基于多表关联的视图,必须在字段名前指定表别名;

     

    建议1:视图的基础数据尽量从表中获取,尽量不要嵌套视图;

     

    4.3.7 存储过程

    规则1: 避免将业务逻辑放在存储过程中,那样容易将业务逻辑和DB耦合在一起;

    规则2: 存储过程,必须有异常捕获代码;

    规则3: 存储过程中严禁使用GOTO语句进行跳转;

    规则4: 有循环更新的存储过程,必须进行批量提交,且必须进行事务控制;

    说明:MySQL存储过程中必须用START TRANSACTION 来显示开始一个事务,否则会按默认的每个DML做个一个事务。

    规则5: 存储过程中如果使用了游标,则在存储过程正常或者异常退出必须关闭所有打开的游标;

    规则6: 存储过程中如果有更新,必须在异常捕获代码中做回退操作;

    规则7: 注释格式如下,存储过程说明放在在COMMENT中,其他用”##”进行注释说明;

    CREATE PROCEDURE prc_vendor

    COMMENT  '说明:同步下发接收; 参数:xxxx; 返回:标志0=成功;’

    ##建立:xxx 2012.07.17

    ## Modify by xxx 2012.08.08 增加供应商状态字段

    ##Modify by xxx 2012.11.10 增加供应商英文名称字段

    BEGIN

    ...

    END;

    建议1:存储过程每次被更新,应在注释中说明更新的内容,更新的日期,以及更新的责任人,并且在更新前保留旧版本代码

    建议2:尽量避免在存储过程中使用动态SQL。

     

    4.3.8 函数

    规则1: 避免将业务逻辑放在函数中,那样容易将业务逻辑和DB耦合在一起;

    规则2: 函数中,如果进行了事务处理,必须有异常捕获代码;

    规则3: 函数中严禁使用GOTO语句进行跳转;

    规则4: 有循环更新的函数,必须进行批量提交,且必须进行事务控制;

    规则5: 函数中如果使用了游标,则在函数正常或者异常退出必须关闭所有打开的游标;

    规则6: 函数中如果对数据进行了更新操作,必须在异常捕获代码中做回退操作;

    规则7: 注释格式如下

    CREATE FUNCTION func_get_serialno

    (

         p_request     VARCHAR       ###请求编号

    )

    return VARCHAR

    COMMENT  ’说明:产生序列号函数,通过serialno_config配置表响应产生序列号; 参数:p_requestid 请求编号 返回:返回需要的序列号‘

    ##建立:xxx 2013.07.02

    ##modified by xxx 2014-6-18 xxx

    BEGIN

    ...

    END;

     

    建议1:函数每次被更新,应在注释中说明更新的内容,更新的日期,以及更新的责任人,并且在更新前保留旧版本代码;

    建议2:函数尽量只是实现复杂的计算功能,不对数据库进行更新操作;

    4.3.9 触发器

    规范1:如无必要,不得设计触发器,任何触发器的设计,必须得到DBA批准;

    规范2:应用的完整性不应由触发器保证,而是通过代码的事务控制;

    建议1:有高度一致性依赖的逻辑,触发器应设计为BEFORE而非AFTER方式;

     

    4.4 开发规范

    4.4.1. 基本规范

     

    规则1:   避免使用存储过程、触发器、函数等,容易将业务逻辑和DB耦合在一起,并且MySQL的存储过程、触发器、函数中存在一定的BUG;

    规则2:   禁止进行字段数据类型的隐式转换,所有转换必须进行明确的数据类型转换;

    说明:隐式转换会导致字段上的索引失效, 最为常见的隐式类型转换常见于时间类型与字符串类型之间,建议所有时间类型字段在myBatis中均以时间类型传入,或者以字符串传入然后通过时间函数转换字符串为合法的时间格式 ,如下:    
    SELECT name

    FROM member

    WHERE vgmt_create=DATE_FORMATE('2009010101:02:03','%Y-%m-%d %H:%i:%s');  

    规则3:   禁止在多表关联的时候,在非索引字段上的关联;

    规则4:   进行模糊查询时,禁止条件中字符串直接以“%”开头;

    规则5:   在使用for update子句时一定注意限制条件,避免锁定全表或者不需要被锁定的行记录。如无必要锁定数据则应避免使用for update;

    规则6:   在进行结果集合并(union或union all)时, 如不需要进行结果去重,则必须使用union all,而不能使用union;且尽量减少进行数据集的去重;

    规则7:   除非必要,避免使用 != 等非等值操作符,会导致用不到索引;

    规则8:   禁止在 WHERE 条件中出现的过滤字段上使用任何函数进行类型或格式的转换;正确的做法是把传入的值转换为列类型所需要的;

    错误的写法:   

    SELECT username

    FROM gl_user

    WHERE DATE_FORMAT(gmt_create, %Y%m%d%H%i%s')='20090501022300‘;   

     

    正确的写法:   

    SELECT username

    FROM gl_user

    WHERE gmt_create=DATE_FORMAT('20090501022300', '%Y-%m-%d %H:%i:s');   

     

    规则9:   禁止使用order by rand();

    order by rand() 会将数据从磁盘中读取,进行排序,会消耗大量的IO和CPU。

    规则10:避免大使用大SQL,可以拆分成多个小SQL来替代;

     

    4.4.2. 绑定变量使用规范

    规则1: 应用端所有查询的 where 条件中的变量,都需要使用绑定变量来实现,以防SQL注入,同时性能也会更优;   

    规则2: 在 myBatis 的 SqlMap 文件中绑定变量使用 "#{var_name}"表示,替代变量使用"${var_name}";所有需要动态 Order By 条件的查询,在使用替代变量过程中,需要将可能传入的内容以枚举类写死在代码中,禁止接受任何外部传入内容;对于不变的常量条件,请使用常量而不是变量;   

    规则3: IN子句,使用"Iterate + 数组类型变量"的方式实现绑定变量而不是通过代码拼接 Query 语句;

    例如:   

        myBatis会生成user_level in (1,2,3,4,5 ...)的语句      

     

    4.4.3. 分页规范

    假如有类似下面分页语句:

    SELECT * FROM table ORDER BY create_time DESC LIMIT 10000,10;

    这种分页方式会导致大量的IO,因为MySQL使用的是提前读取策略。

    推荐分页方式:

    SELECT * FROM table WEHRE create_time < last_time ORDER BY create_time DESC LIMIT 10;

    SELECT * FROM table INNER JOIN (SELECT id FROM table ORDER BY create_time  LIMIT 10000,10) AS t USING(id);

     

    4.4.4. 建议

    建议1:   尽量使用if来简化SQL访问数据库的次数;

    示例:

    如下两个语句实现的功能

    SELECT  COUNT(*) , SUM(salary)

    FROM employees

    WHERE department_id = 20

    AND first_name LIKE 'SMITH%';

       

    SELECT COUNT(*) , SUM(salary)

    FROM employees

    WHERE  department_id = 30

    AND first_name LIKE 'SMITH%';

    可以使用IF改写为如下语句

    SELECT COUNT(IF(department_id=20, '*', NULL)) d20_count,

                  COUNT(IF(department_id=30, '*', NULL)) d30_count,

                  SUM(IF(department_id=20, salary, NULL)) d20_sal,

                 SUM(IF(department_id=30, salary, NULL)) d30_sal

    FROM employees

    WHERE first_name LIKE 'SMITH%';

    建议2:   避免使用HAVING子句, HAVING 只会在检索出所有记录之后才对结果集进行过滤. 这个处理需要排序,总计等操作. 如果能通过WHERE子句限制记录的数目,那就能减少这方面的开销;

    示例

    如下语句使用的是HAVING子句

    SELECT last_name, avg(salary)

    FROM employees

    GROUP BY last_name

    HAVING last_name != 'Grant'

    AND last_name !=  'Fay'

     

    改写使用WHERE的语句如下

    SELECT last_name, avg(salary)

    FROM employees

    WHERE last_name != 'Grant'

    AND last_name != 'Fay'

    GROUP BY last_name

    建议3:   尽量少用not exist/no in等反向写法。如果一定要用时,尽量选择not exist;

    建议4:   尽量少用is null/is not null等null的处理;

    建议5:   SQL语句中IN子句里的值不应超过300;

    建议6:   对于大表查询中的列项应尽量避免进行诸如CAST()或CONVERT()的转换;

    建议7:   尽量避免进行全表扫描,限制条件尽可能多,以便更快搜索到要查询的数据;

    建议8:   SELECT查询语句建议增加limit 1000 限定返回的行数;

    建议9:   进行数据库结构设计的时候,考虑适当的冗余,尽量确保应用读写数据的SQL简洁;

    建议10:  要返回MySQL自增序列的ID值,可以考虑使用函数LAST_INSERT_ID(),此函数只能返回同

    一个SESSION最近一次对有AUTO_INCREMENT属性表INSERT的ID值

    4.5.  开发实用技术

    4.5.1. CHAR(N)或VARCHAR(N)中的N解释

    MySQL中此两类字符串定义时候填写的长度N,不是字节数的意思 ,而是字符数的意思。

    我们MySQL所有数据库的字符集都为UTF8,字符集校对规则为UTF8_bin。对于中文汉字,实际存储的时候占三个字节,而数据或字母,则只占一个字节。例如:

    CREATE TABEL company_inventory (color VARCHAR(44) COMMENT '颜色');

    则color最多能存储40个字符。

    4.5.2. 日期操作函数

    获取当前时间:NOW(),CURDATE()、CURTIME()

    其中, NOW()函数精确到秒,  格式:YYYY-MM-DD HH:MM:SS

               CURDATE函数精确到天,格式:YYYY-MM-DD

               CURTIME函数精确到秒,格式:HH:MM:SS

     

    日期数值的加减函数:

          DATE_ADD(date,INTERVAL expr type)

          DATE_ SUB(date,INTERVAL expr type)

    常用的几种type类型:YEAR、MONTH、DAY、HOUR、MINUTE,其中expr可以为正数或负数,我们在开过程中,一般使用DATE_ADD()函数,若要作日期减去一个数字的方式,就使用负数。

          DATEDIFF(expr1,expr2),是返回 开始日期expr1与  结束日期expr2之间,相差的天数 ,返回值为正数或负数。

     

    返回日期某部分信息的函数:

    YEAR(expr1)  返回日期expr1部分的年份;

    MONTH(expr1) 返回日期expr1部分的月份;

    DAY(expr1)返回expr1部分的天数;

    WEEKDAY(expr1)返回expr1对应的星期数字

     

    4.5.3. 类型转换函数

       字符串转换成日期方式,DATE_FORMAT()或STR_TO_DATE(),

       两个函数的格式如下:

       DATE_FORMAT(expr1,format)

       STR_TO_DATE(expr1, format)

       常用的日期格式YYYY-MM-DD HH:MM:SS 对应的format为%Y-%m-%d %H:%i:%S

       通用的类型转换函数:

         CAST(expr AS type)

         CONVERT(expr,type)

         CONVERT(expr USING transcoding_name)

     

    4.5.4. INNODB与MYISAM的主要区别

     

    MyISAM

    InnoDB

    构 成上的区别:

    每个MyISAM表在磁盘上存储三个文件。文件的名字以表的名字开始,扩展名指出文件类型。

    .frm文件存储表定义。

    .MYD文件存储数据 (MYData)。

    .MYI文件存储索引 (MYIndex)。

    InnoDB表空间数据文件和日志文件,InnoDB表的大小只受限于操作系统文件的大小

    事务处理上方面:

    MyISAM类型的表强调的是性能,其执行速度比InnoDB类型更快,但是不提供事务支持

    InnoDB提供事务支持事务,外部键等高级 数据库功能

    SELECT UPDATE,INSERT,Delete操 作

    如果执行大量的SELECT,MyISAM是更好的选择

    1.如果你的数据执行大量的INSERT或UPDATE,出于性能方面的考虑,应该使用InnoDB表

    2.DELETE FROM table时,InnoDB不会重新建立表,而是一行一行的 删除。

    3.LOAD TABLE FROM MASTER操作对InnoDB是不起作用的,解决方法是首先把InnoDB表改成MyISAM表,导入数据后再改成InnoDB表,但是对于使用的额外的InnoDB特性(例如外键)的表不适用

    表的具体行数

    select count(*) from table,MyISAM只要简单的读出保存好的行数,注意的是,当count(*)语句包含 where条件时,两种表的操作是一样的

    InnoDB中不保存表的具体行数,也就是说,执行select count(*) from table时,InnoDB要扫描一遍整个表来计算有多少行

    表锁,MyISAM表锁读写互相阻塞,写锁优先级高于读锁。参数选项low_priority_updates设置写锁优先级比读锁低、参数选项concurrent_insert配置是否使用并发插入特性,concurrent_insert=0 表示不允许并发插入,concurrent_insert=1表示允许对没有空数据块的表使用并发插入(缺省),concurrent_insert=2表示对所有表允许并发插入

    提供行锁(locking on row level),提供与Oracle类型一致的不加锁读取(non-locking read in SELECTs)。MySQL的行锁是针对索引加的锁,不是针对记录加的锁,在不通过索引条件查询的时候,InnoDB使用的是表锁,而不是行锁。

    另外,即便在条件中使用了索引字段,但是否使用索引来检索数据是由MySQL通过判断不同执行计划的代价来决定的,如果MySQL认为全表扫描效率更高,比如对一些很小的表,它就不会使用索引,这种情况下InnoDB将使用表锁,而不是行锁

      

    展开全文
  • 软件设计开发规范(国标) (转)

    千次阅读 2007-06-24 20:52:00
    软件开发规范,包括:1-操作手册(GB8567——88).doc2-测试分析报告(GB8567——88).doc3-测试计划(GB8567——88).doc 4-概要设计说明书(GB8567——88).doc5-开发进度月报(GB8567——88).doc 6-可行性研究...
  • 软件开发流程规范

    千次阅读 2020-04-11 14:02:34
    为了规范互联网软件产品开发项目管理过程,指导开展项目研发、管理等活动,缩短开发周期,提高软件开发质量,降低开发成本,提高开发效率和效益,制定软件开发流程管理规范。     本规范的作用...
  • 华为软件开发行为规范

    千次阅读 2019-03-25 18:04:21
    https://wenku.baidu.com/view/3696dec3534de518964bcf84b9d528ea81c72f3f.html ... 软件开发行为规范-华为 软件开发行为规范 1软件需求分析 2软件项目计划 3概要设计 4详细设计 5编码 6需求管理 7...
  • 软件设计规范

    千次阅读 2004-07-13 21:07:00
    概述 软件设计是把需求转化为软件系统的最重要的环节,系统设计的优劣在根本上决定了软件系统的质量。 在此,主要阐述软件系统设计的5个核心内容:体系结构设计、用户界面设计、数据库设计、模块设计、数据结构和...
  • 软件开发文档编写规范

    千次阅读 2018-09-25 16:59:44
    对于软件工程学科的同学都知道,软件工程是一门技术含量高设计极其复杂的学科。为了控制好软件产品质量和规范,就必须用大量的文档约束软件工程的进度和状态。浩大的软件工程对于缺少工作和项目经验的人来说,必然是...
  • 软件开发编码规范总结

    千次阅读 2020-01-05 15:33:09
    意 ...3. 规范可以改善软件的可读性,可以让程序员尽快而彻底地理解新的设计和代码,节约了时间,提高了工作效率。 4. 良好的编码规范可以有效避免一些低级错误,赢得同事的夸奖和上司的认...
  • 软件开发编程规范及原则

    万次阅读 2016-12-07 22:05:54
    相信大家看到标题都应该能明白编程的规范及原则对于每一个软件开发的工程师来说是多么重要。   初学者编写测试程序、小的模块程序也许不能感受它的重要性;但有经验及大型项目开发的人就知道程序的规范性对...
  • 如何理解软件开发规范性与灵活性

    千次阅读 2012-08-08 20:12:15
    规范性是指在软件开发时所必须遵循的约定、规范和流程,用于规范软件开发过程中的管理方法、设计方法、编码方法。很长一段时间,在软件工程学科中认为规范性来源于人为约定,但这种认识无法解释“约定”的本源,如...
  • 软件开发需求分析规范

    千次阅读 2017-05-24 19:49:38
    软件需求规格说明书是软件开发过程需求分析阶段需要产出的文档,是为了使用户和软件开发者对软件的规格有一个共同的理解而撰写的,软件需求规格说明有标准的模板 其规范结构包括: 第一章是引言。 描述软件需求...
  • 软件安全开发 - 流程规范

    千次阅读 2019-03-20 15:37:20
    写一篇软件安全开发流程分享给大家,帮助从事软件开发,测试,管理的人员,规范操作,重视软件工程安全。 现今社会存在各种网络安全事件,比如勒索病毒导致许多网络系统瘫痪,大量注册用户个人数据泄露导致企业...
  • 软件开发文档-详细设计文档

    万次阅读 2019-06-21 11:22:34
    帮助开发人员理解项目的业务逻辑术语描述执行标准与相关文档 编码标准,文件管理标准,版本管理标准项目概述 1.背景 2.现状项目目标编码规范系统功能概述 系统功能总图系统总体介绍系统模块设计 模块结构图,...
  • 软件开发版本管理规范

    千次阅读 2018-06-28 10:06:02
    第一 目的 本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容,使软件项目版本管理流程化并规范化,确保在系统开发和实施过程中项目的完整性和一致性。第二章 适用范围 所有系统开发及...
  • 软件开发可行性分析规范

    千次阅读 2017-05-24 19:55:23
    目录1. 引言 1.1 项目背景 1.2 术语定义 1.3 参考资料 2. 市场可行性 ...4.2 软件资源 4.3 设备资源 4.4 时间资源 5. 经济可行性 5.1 投资规划 5.1.1 基础投资 5.1.2 直接投资 5.2 收益分析
  • 软件开发设计阶段

    千次阅读 2012-10-25 21:40:15
    在概要设计中最重要是体系结构设计软件的系统结构是以后进行详细设计的基础和根本依据。概要设计阶段体系的确立就是软件框架的建立,基本上就是产品的纸面原型,为接下来的详细设计定了位。 详细设计:数据...
  • 大多数开发人员随着经验的增长,会进入一个管理层的岗位(开发小组的组长,当然啦博主才毕业大半年,还不是开发组长,只是提前了解了一下分享给大家),需要负责软件系统的设计(系统功能设计和数据库设计)。...
  • 软件开发技术文档编写规范

    万次阅读 多人点赞 2017-12-29 09:40:14
     ◇可行性分析报告:说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性,评述为了合理地达到开发目标可供选择的各种可能实施方案,说明并论证所选定实施方案的理由。  ◇项目开发计划:为软件项目...
  •  软件开发方法是软件开发的方法学,通过软件开发方法研究,提高软件的质量、降低软件的成本。  软件开发方法包括:软件生命周期、软件开发模型、软件重用技术、逆向工程及形式化开发方法 一、软件生命周期  ...
  • web前端开发规范

    千次阅读 2018-05-22 17:49:07
    web前端开发规范麦子学院何虎老师的开发web前端开发规范课程笔记web前端开发规范的意义1、提高团队的协作能力 2、提高代码的复用利用率 3、可以写出质量更高,效率更好的代码 4、为后期维护提供更好的支持规范1、...
  • 软件版本号规范

    千次阅读 2016-04-28 14:43:53
    软件版本号规范
  • 第三方接口开发规范

    万次阅读 2017-01-17 09:32:11
    第三方接口开发规范 一、前言  最近公司业务需要希望能够连接东亚银行的接口直接对商家进行转账付款,但由于前期可行性研究的准备工作没有做好,导致在开发进入两周后才发现原先的设计存在重大安全漏洞,不得...
  • 1. 文件的梗概和介绍:总结:在设计规范书的开头,对整个开发项目做个总结,用简单几个段落从宏观的角度对整个项目的目的和它所开发的功能做一个描述; 范围:说明设计规范文件所叙述的范围,包括文件中各个部分的...
  • 软件开发设计原则和模式

    千次阅读 2010-12-05 15:52:00
    <br /> 软件开发是一项高强度的脑力劳动过程,到目前为止尚没有办法使软件开发完全机械化,只能靠人脑去设计,也无法保证一个软件完全没有错误。同硬件产品相比,一方面是同功能的软件产品不再需要一个生产...
  • 软件开发中的详细设计

    千次阅读 2016-02-03 17:00:08
    传统软件开发中的详细设计: 模块内的数据结构进行设计。比如模块中类、结构体的设计对数据结构进行物体设计。比如数据库表的设计,文件存储的设计,文件存储目录的设计每个模块进行详细算法设计。比如每个方法的...
  • 阿里开发规范(精简版)

    万次阅读 2018-03-14 10:28:56
    Java开发规范 命名 【规范】类名使用UpperCamelCase 风格,必须遵从驼峰形式,但以下情形例外: ( 领域模型的相关命名 )DO / BO / DTO / VO 等。 正例: MarcoPolo / UserDO / XmlService / TcpUdpDeal / ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 261,476
精华内容 104,590
关键字:

软件设计开发规范