软件工程模型.docx

软件开发的V模型的优缺点？V模型是最广为人知的测试模型最典型的V模型版本一般会在其开始部分对软件开发过程进行描述图1V模型的各级开发阶段这是古老的瀑布模型作为开发模型，在V模型中，测试过程被加在开发过程的后半部分，如下图所示：图2 V模型示意图单元测试所检测代码的开发是否符合详细设计的要求集成测试所检测此前测试过的各组 成部分是否能完好地结合到一起系统测试所检测已集成在一起的产品是否符合系统规格说 明书的要求而验收测试则检测产品是否符合最终用户的需求预验收测试可行性分析 > 验收测试\预系统测试/需求分析 > 系统测试\预集成测试/概要设计 > 集成测试\预单元测试/详细设计一 > 单元测试\ /编码这就是软件测试的V模型V模型的缺陷仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段忽视了测试对需求分析，系统设计的验证，一直到后期的验收测试才被发现W模型：上次说到V模型的局限性在于没有明确地说明早期的测试，无法体现“尽早地和不断地进行软 件测试”的原则在V模型中增加软件各开发阶段应同步进行的测试，演化为W模型在模 型中不难看出，开发是“V”，测试是与此并行的“V”基于“尽早地和不断地进行软件测试” 的原则，在软件的需求和设计阶段的测试活动应遵循IEEE1012-1998《软件验证与确认(V&V)》 的原则。

W模型由Evolutif公司提出，相对于V模型，W模型更科学W模型是V模型的发展，强调 的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样 要测试测试与开发是同步进行的，从而有利于尽早地发现问题W模型也有局限性W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活 动，无法支持迭代、自发性以及变更调整W模型也被称为双V模型，在每个开发阶段，测试都可以介入，并执行编写、评审、基线化 的过程 双V模型的第一条线代表开发，第二条线代表测试准备，第三条线是测试执行他的模型是这样的：SRS编写STP编写 SRS 评审STP评审ST系统测试SRS基线化STP基线化HLD编写ITP 编写HLD 评审ITP 评审IT 集成测试HLD 基线化ITP 基线化LLD 编写UTP编写LLD 评审UTP 评审UT 单元测试LLD基线化UTP基线化CodingH模型：H模型应该是横过来，将测试和开发作为两条平行的线，开发进行概要设计和详细设计的时 候，测试线就做各种准备活动如做测试计划、编写测试要点和详细的测试用例它将测试 活动作为一个独立的流程H中的横杠是一个节点，当开发活动进行完成，在这个节点上， 测试就可以执行测试活动了。

测试计划 测试要点 测试用例 测试执行 时间节点 各种的开发活动 H模型揭示了一个原理：软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进 行H模型指出软件测试要尽早准备，尽早执行不同的测试活动可以是按照某个次序先后 进行的，但也可能是反复的，只要某个测试达到准备就绪点，测试执行活动就可以开展瀑布模型：主要的软件过程模型有：瀑布模型，演化模型（如增量模型、原型模型、螺旋模型）喷泉模 型、基于构件的开发模型和形式方法模型等瀑布模型（waterfall model）是1970年有W.Royce提出的，它给出了软件生存周期活动的 固定顺序，上一阶段的活动完成后向下一阶段过渡，最终得到所开发的软件产品瀑布模型 如下图所示，有时也称为软件生存周期模型瀑布模型中，上一阶段的活动完成并经过评审后才能开始下一阶段的活动，其特征是：（1）接受上一阶段的结果作为本阶段活动的输入2） 依据上一阶段活动的结果实施本阶段应完成的活动3） 对本阶段的活动进行评审4） 将本阶段活动的结果作为输出，传递给下一阶段瀑布模型是最早出现的也是应用最广泛的过程模型，对确保软件开发的顺利进行、提高 软件项目的质量和开发效率起到重要作用。

在大量的实践过程中，瀑布模型也逐渐暴露出它的不足首先，客户常常难以清楚地描述所 有的要求，而且在开发过程中，用户的需求也常常会有所变化，使得不少软件的需求存在着 不确定性；在某个活动中发现的错误常常是由前一阶段活动的错误引起的，为了改正这一错 误必须回到前一阶段，这就导致了瀑布的倒流，也就是说，实际的软件开发很少能按瀑布模 型的顺序没有回流地顺流而下其次，瀑布模型使得客户在测试完成以后才能看到真正可运 行的软件，此时，如果发现不满足客户需求的问题（由于需求不确定性），那么修改软件的代 价是巨大的不是任何软件都可采用瀑布模型的，瀑布模型适合于结构化方法，也就是面向过程的软件开 发方法软件项目或产品选择瀑布模型必须满足下列条件：在开发时间内需求没有或很少变 化；分析设计人员应对应用领域很熟悉；低风险项目（对目标、环境很熟悉）用户使用环境 很稳定；用户除提出需求以外，很少参与开发工作2、 演化模型该模型主要针对事先不能完整定义需求的软件开发用户可以给出待开发系统的核心需求， 并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现软件开 发人员根据用户的需求，首先开发核心系统。

当该核心系统投入运行后，用户试用之，完成 他们的工作，并提出精化系统、增强系统能力的需求软件开发人员根据用户的反馈，实施 开发的迭代过程第一迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系 统增加一个可定义的、可管理的子集如图所示3、 螺旋模型瀑布模型与演化模型相结合，并加入两者所忽略的风险分析所建立的一种软件开发模型该 模型于1998年由美国TRW公司(B.W.Boehm)提出软件项目风险的大小作为指引软件过程 的一个重要因素，引入这一概念有可能使得软件开发被看作一种元模型，因为它能包容任何 一个开发过程模型螺旋模型基本的做法是在“瀑布模型”的每一个开发阶段之前，引入非常严格的风险识别、 风险分析和风险控制直到采取了消除风险的措施之后，才开始计划下一阶段的开发工作 否则，项目就很可能被取消另外，如果有充足的把握判断遗留的风险已降低到一定的程度，项目管理人员可作出决定让 余下的开发工作采用另外的生命周期模型，如“演化模型”，“瀑布模型”，或自定的混合模型优点：a. 强调严格的全过程风险管理b. 强调各开发阶段的质量c. 提供机会检讨项目是否有价值继续下去缺点：a.引入非常严格的风险识别，风险分析，和风险控制，这对风险管理的技能水平提出了 很高的要求。

这需要人员，资金，和时间的投入。