开发模型
瀑布模型
瀑布模型产生的历史背景是20世界70年代出现的软件危机,该模型将软件开发分为若干阶段,因为其相似于瀑布从上到下的过程,故称其为“瀑布模型”。
数据库
- 特色:
- 阶段间具备顺序性和依赖性:
- 前一阶段完成后,才能开始后一阶段
- 前一阶段的输出文本为后一阶段的输入文本
- 推迟实现的观点
- 质量保证:
- 每一个阶段必须交付出合格的文档
- 对文档进行审核
- 缺点:
开始须要把需求作到最全,害怕用户测试中的反馈,害怕需求变动。
V模型
V模型是在瀑布模型的基础上发展而来的。编程
RAD(Rap Application Development,快速应用开发)模型是软件开发过程当中的一个重
要模型,因为其模型构图形似字母V,因此又称软件测试的 V模型。它经过开发和测试同时进行的方式来缩短开发周期,提升开发效率。
数据结构
阶段步骤
V模型大致能够划分为如下几个不一样的阶段步骤:需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收测试。架构
- 需求分析:
首先要明确客户须要的是什么,须要软件做成什么样子,须要有哪几项功能,这一点上比较关键的是分析师和客户沟通时的理解能力与交互性。要求分析师能准确地把客户所须要达到的功能、实现方式等表述出来,给出分析结果,写出需求规格说明书。
- 概要设计:
主要是架构的实现,指搭建架构、表述各模块功能、模块接口链接和数据传递的实现等多项事务。
- 详细设计:
对概要设计中表述的各模块进行深刻分析、对各模块组合进行分析等,这一阶段要求达到伪代码级别,已经把程序的具体实现的功能、现象等表述出来。其中须要包含数据库设计说明。
- 软件编码:
按照详细设计好的模块功能表,编程人员编写出实际的代码。
- 单元测试:
按照设定好的最小测试单元进行按单元测试,主要是测试程序代码,为的是确保各单元模块被正确的编译。
单元的具体划分,依据不一样的单位、不一样的软件而有所不一样,好比有具体到模块的测试,也有具体到类、函数的测试等。
- 集成测试:
通过了单元测试后,将各单元组合成完整的体系,主要测试各模块间组合后的功能实现状况,以及模块接口链接的成功与否,数据传递的正确性等。
其主要目的是检查软件单位之间的接口是否正确。
根据集成测试计划,一边将模块或其余软件单位组合成系统,一边运行该系统,以分析所组成的系统是否正确,各组成部分是否合拍。
- 系统测试:
通过了单元测试和集成测试之后,咱们要把软件系统搭建起来,按照软件规格说明书中所要求,测试软件其性能、功能等是否和用户需求相符合,在系统中运行是否存在漏洞,等。
- 验收测试:
主要就是用户在拿到软件的时候,在使用现场,会根据前边所提到的需求,以及规格说明书来作相应测试,以肯定软件达到符合效果的。
缺陷及解决思路
缺陷:
V模型仅仅把测试过程做为在需求分析、系统设计及编码以后的一个阶段,忽视了测试对需求分析,系统设计的验证,需求的知足状况一直到后期的验收测试才被验证。框架
解决思路:
当一个软件开发的时候,研发人员和测试人员须要同时工做,测试在软件作需求分析的同时就会有测试用例的跟踪,这样,能够尽快找出程序错误和需求偏离,从而更高效的提升程序质量,最大可能的减小成本,同时知足用户的实际软件需求。数据库设计
适用范围
V模式是一种传统软件开发模型,通常适用于一些传统信息系统应用的开发;而一些高性能高风险的系统、互联网软件,或一个系统难以被具体模块化的时候,就比较难作成V模式所需的各类构件,须要更强调迭代的开发模型或者敏捷开发模型。模块化
W模型
W模型:由Evolutif公司提出,相对于V模型,W模型增长了软件开发各阶段中同步进行的验证和确认活动。

如图所示,由两个V字型模型组成,分别表明测试与开发过程,图中明确表示出了测试与开发的并行关系。函数
- 优势:
- 开发伴随着整个开发周期,需求和设计一样要测试;
- 更早的介入测试,能够发现初期的缺陷,修复成本低;
- 分阶段工做,方便项目总体管理。
- 缺点:
- 开发和测试依然是线性的关系,需求的变动和调整,依然不方便;
- 若是没有文档,根本没法执行w模型;对于项目组成员的技术要求更高!
软件生命周期
瀑布型生命周期
瀑布型生命周期包括可行性分析与开发项计划、需求分析、设计(概要设计和详细设计)、编码、测试、维护等阶段。性能
阶段步骤
- 问题的定义及规划:
此阶段是软件开发方与需求方共同讨论,主要肯定软件的开发目标及其可行性。
- 需求分析:
在肯定软件开发可行的状况下,对软件须要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段,这一阶段作得好,将为整个软件开发项目的成功打下良好的基础。"惟一不变的是变化自己。",一样需求也是在整个软件开发过程当中不断变化和深刻的,所以咱们必须制定需求变动计划来应付这种变化,以保护整个项目的顺利进行。
- 软件设计:
此阶段主要根据需求分析的结果,对整个软件系统进行设计,如系统框架设计,数据库设计等等。软件设计通常分为整体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。
- 程序编码:
此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必需要制定统一,符合标准的编写规范。以保证程序的可读性,易维护性,提升程序的运行效率。
- 软件测试:
在软件设计完成后要通过严密的测试,以发现软件在整个设计过程当中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程当中须要创建详细的测试计划并严格按照测试计划进行测试,以减小测试的随意性。
- 运行维护:
软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后,因为多方面的缘由,软件不能继续适应用户的要求。要延续软件的使用寿命,就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。
高内聚低耦合
- 内聚:是从功能角度来度量模块内的联系,一个好的内聚模块应当刚好作一件事。它描述的是模块内的功能联系;
- 耦合:是软件结构中各模块之间相互链接的一种度量,耦合强弱取决于模块间接口的复杂程度、进入或访问一个模块的点以及经过接口的数据。
- 耦合性:也称块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密,其耦合性就越强,模块的独立性则越差。模块间耦合高低取决于模块间接口的复杂性、调用的方式及传递的信息。
内聚性:又称块内联系。指模块的功能强度的度量,即一个模块内部各个元素彼此结合的紧密程度的度量。若一个模块内各元素(语名之间、程序段之间)联系的越紧密,则它的内聚性就越高。单元测试
- 所谓高内聚是指一个软件模块是由相关性很强的代码组成,只负责一项任务,也就是常说的单一责任原则。
对于低耦合,粗浅的理解是:一个完整的系统,模块与模块之间,尽量的使其独立存在。也就是说,让每一个模块,尽量的独立完成某个特定的子功能。模块与模块之间的接口,尽可能的少而简单。若是某两个模块间的关系比较复杂的话,最好首先考虑进一步的模块划分。这样有利于修改和组合。
耦合
耦合能够分为如下几种,它们之间的耦合度由高到低排列以下:
- 内容耦合:一个模块直接访问另外一模块的内容,则称这两个模块为内容耦合。
内容耦合可能在汇编语言中出现。大多数高级语言都已设计成不容许出现内容耦合。
这种耦合的耦合性最强,模块独立性最弱。
- 公共耦合:一组模块都访问同一个全局数据结构,则称之为公共耦合。
公共数据环境能够是全局数据结构、共享的通讯区、内存的公共覆盖区等。
若是模块只是向公共数据环境输入数据,或是只从公共数据环境取出数据,这属于比较松散的公共耦合;
若是模块既向公共数据环境输入数据又从公共数据环境取出数据,这属于较紧密的公共耦合。
- 外部耦合:一组模块都访问同一全局简单变量,并且不经过参数表传递该全局变量的信息,则称之为外部耦合。
- 控制耦合:模块之间传递的不是数据信息,而是控制信息例如标志、开关量等,一个模块控制了另外一个模块的功能。
- 标记耦合:调用模块和被调用模块之间传递数据结构,而不是简单数据,同时也称做特征耦合。
标记耦合的模块间传递的不是简单变量,而是像高级语言中的数据名、记录名和文件名等数据结果,这些名字即为标记,其实传递的是地址。
- 数据耦合:调用模块和被调用模块之间只传递简单的数据项参数。至关于高级语言中的值传递。
- 非直接耦合:两个模块之间没有直接关系,它们之间的联系彻底是经过主模块的控制和调用来实现的。
耦合度最弱,模块独立性最强。
总结:耦合是影响软件复杂程度和设计质量的一个重要因素,为提升模块的独立性,应创建模块间尽量松散的系统,在设计上咱们应采用如下原则:若模块间必须存在耦合,应尽可能使用数据耦合,少用控制耦合,慎用或有控制地使用公共耦合,并限制公共耦合的范围,尽可能避免内容耦合。
内聚
内聚有以下的种类,它们之间的内聚度由弱到强排列以下:
- 偶然内聚:一个模块内的各处理元素之间没有任何联系,只是偶然地被凑到一块儿。
这种模块也称为巧合内聚,内聚程度最低。
- 逻辑内聚:这种模块把几种相关的功能组合在一块儿,每次被调用时,由传送给模块参数来肯定该模块应完成哪种功能。
- 时间内聚:把须要同时执行的动做组合在一块儿,造成的模块称为时间内聚模块。
- 过程内聚:构件或者操做的组合方式是,容许在调用前面的构件或操做以后,立刻调用后面的构件或操做,即 使二者之间没有数据进行传递。
简单的说就是若是一个模块内的处理元素是相关的,并且必须以特定次序执行,则称为过程内聚。
- 通讯内聚(信息内聚):指模块内全部处理元素都在同一个数据结构上操做或全部处理功能都经过公用数据而发生关联(有时称之为信息内聚)。
即 指模块内各个组成部分都使用相同的数据数据或产生相同的数据结构。
- 顺序内聚:一个模块中各个处理元素和同一个功能密切相关,并且这些处理必须顺序执行,一般前一个处理元素的输出是后一个处理元素的输入。
例如,某模块完成工业产值求值的功能,前一个功能元素求总产值,后一个功能元素求平均产值,显然该模块内两部分紧密关联。
顺序内聚的内聚度比较高,但缺点是不如功能内聚易于维护。
- 功能内聚:模块内全部元素的各个组成部分所有都为完成同一个功能而存在,共同完成一个单一的功能,模块已不可再分。即 模块仅包括为完成某个功能所必须的全部成分,这些成分紧密联系、缺一不可。
功能内聚是最强的内聚,其优势是它的功能明确。判断一个模块是否功能内聚,通常从模块名称就能看出。
若是模块名称只有一个动词和一个特定的目标(单数名词),通常来讲就是功能内聚,如:“计算水费”、“计算产值”等模块。功能内聚通常出如今软件结构图的较低层次上。
功能内聚模块的一个重要特色是:他是一个“暗盒”,对于该模块的调用者来讲,只须要知道这个模块能作什么,而不须要知道这个模块是如何作的。
总结:在模块划分时,要遵循“一个模块,一个功能”的原则,尽量使模块达到功能内聚。
高内聚,低耦合的系统有什么好处呢? 事实上,短时间来看,并无很明显的好处,甚至短时间内会影响系统的开发进度,由于高内聚,低耦合的系统对开发设计人员提出了更高的要求。 高内聚,低耦合的好处体如今系统持续发展的过程当中,高内聚,低耦合的系统具备更好的重用性,维护性,扩展性,能够更高效的完成系统的维护开发,持续的支持业务的发展,而不会成为业务发展的障碍。