瀑布模型

计算机网络 练习（一百三十七） 在路由器的特权模式下键入命令setup，则路由器进入（）模式。 A. 设置对话状态 B. 接口配置状态 C. 特权命令状态 D. 局部配置状态 ---------------------------------------- 答案 ： A 解析 ： 开启路由器后，路由器首先进入用户模式。从特权模式进入设置模式需要键入 setup 命令，用户模式不允许配置被查看或修改，特权模式允许用户去查看并修改路由器的配置。在用户模式下可以通过键入命令 enable 及输入启用口令或启用加密口令进入特权模式，故选 A)。 实现 VPN 的关键技术主要有隧道技术、加解密技术、（）和身份认证技术。 A. 入侵检测技术 B. 病毒防治技术 C. 安全审计技术 D. 密钥管理技术 ---------------------------------------- 答案 ： D 解析 ： 实现 VPN 的关键技术主要有隧道技术、加解密技术、密钥管理技术和身份认证技术。 下列网络管理软件中不需要 SNMP 支持的是（）。 A. CiscoWorks B. Netview C. Solarwinds D. Wireshark ---------------------------------------- 答案 ： A 解析 ： 无 ITU V.90 调制解调器（Modem） （

现阶段正在看软工视频，大概看了十几集。第一感觉就是乱，我相信很多人第一遍看过去的时候都理不清头绪，很多的名词和图片，说的人天花乱坠。看完后感觉就像是狗熊掰棒子，掰一个扔一个，实在是让人绝望。不过还好有米老师的那句话在支撑着我，记是记不住的，你看过一遍至少有个印象。况且里面的一些知识理解不了也是正常的，这只是理论阶段的学习，后面还要写文档，等用到的时候再回过头来看一眼就可以了。随着视频集数的增加，难度也在变大，需要有前面的知识做基础，所以，阶段性的总结一下还是很有必要的。这样到最后再大总结时也不会太吃力。 （一） 第一章 软件工程学概述 第一章主要是对软件工程过程的概述，对于软件的分类，软件的特点，软件的生存周期以及软件开发的各种模型 做了简单的介绍。其中还阐述了什么是软件危机（指在计算机软件的开发和维护过程中所遇到的一系列严重问题）以 及解决软件危机的有效途径。除此之外还指明了软件工程的最高目标：以较少的投资获得易维护、易理解、可靠、高 效率的软件产品。 其中我感觉比较重要的就是软件开发模型，软件开发模型是跨越整个软件生存周期的系统开发、运行、维护所实 施的全部工作和任务的结构框架。它涵盖了软件开发的6个生存周期：制定计划、可行性研究及需求分析、软件设 计、编码、测试和维护。比较常用的模型有5中：瀑布模型、原型模型、渐增模型、螺旋模型、喷泉模型。感觉其中 最经典的就是瀑布模型那张图

软件生命周期 软件测试要经过一个什么样的过程呢，这就要从软件的生命周期开始说起了。 软件生命周期又称为软件生存周期或系统开发生命周期，是软件的产生直到报废的生命周期。 整个生命周期包括问题定义与规划、需求分析、系统设计、软件编程、软件测试、软件运维等阶段。 在周期内，无论是开发还是测试都依赖于某个模型进行作为依据，有效地提高开发、测试效率。 软件开发模型 在软件开发的实践中，总结了很多软件的开发模型来描述和表示一个复杂的开发过程，如果瀑布模型、快速原型模型、螺旋模型等。 软件测试与软件开发模式有着紧密的关系，作为一名测试人员，应该充分理解软件的开发模式，尽快的找准自己的位置，从而尽快的发挥自己的价值。 瀑布模型 瀑布模型是线性模型的一种，在所有的模型中占有重要的地位，是所有其他模型的一个基础。 瀑布模型如同工地里的建造盖房流程，使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求的输出，下一阶段的工作就不展开。 测试的切入点，开发完成后，必须留给测试足够的时间给测试人员，否则可能会导致测试不充分，导致很多问题到项目的后期才体现出来。 优点 明确划分了软件生命周期的各个环节。 强调早期软件计划，需求分析比较重要。 清晰的工作流程，便于分工协作。 适合需求稳定的产品开发。 每个阶段都有一个检查点。 缺点 线性的开发流程，存在巨大的风险。 依赖于早期的需求调查

1 瀑布模型怎么来的？ (1)所谓软件危机 瀑布模型算是现代软件工程的起源，软件工程的发展，很大部分都是构建于瀑布模型的基础之上的。在校期间做的项目相对简单，通常不会涉及到诸如性能测试等，通常为边写边改，但是一旦 项目变复杂，开发人员水平参差不齐，从而导致软件开发与维护过程中出现一系列严重问题，这个现象也被称之为“软件危机”。 (2)边写边改的缺点 开发的过程不可控 项目的人数多了以后，不方便协作分工 对需求分析的理解误差，导致返工，从而影响项目交付 没有有效的测试，上线问题一堆 (3)瀑布模型的诞生 　　1970 年，Winston Royce 博士借鉴了其他工程领域的思想，比如建筑工程，提出了瀑布开发模型，指出软件开发应有完整之周期，并将软件开发过程分成了若干阶段。像瀑布一样，从上往下，完成一个阶段继续下一个阶段 2 瀑布模型案例 按照一个我曾经毕业设计的案例 (1) 项目的定义和规划 　　毕业设计是做一个c++的网络嗅探器，所用库为libpcap，可行性没问题，老师大概给我说了下需要做哪些功能，然后说两个月完成吧。啊，你怕是在开玩笑，当时读本科一天天都是在摸鱼。。初步定下时间吧 需求分析——1 周； 　　软件设计——1周； 　　程序编码——4 周； 　　软件测试——1周。 的确如此，软件测试在当时开来就是功能测试，实现功能就完事，哎！！！ (2) 需求分析阶段 　

1 软件怎么被创造出来的 　　软件的出现，一般都是某个人或者某些人有想法有意图，想做个什么东西方便自己方便他人。张小龙的微信，乔布斯的IOS。这些伟大的软件需要很多人来协同完成。 比如微信，2010年立项，2011第一版上线，当时只能发送文本消息和照片，之后一个版本一个版本更新。 　　像这样有计划有步骤有人参与的产品------->工程。 2 软件危机是什么？ 　　工程的本质就是要做出有用的产品。造房子的建筑工程，造火箭的航天工程。同样，软件领域，也就是软件工程。不按照建筑工程去造房子是会出事故甚至死人的。 　　咋们看看建筑工程。设想一下建一座房子：首先要先立项、设定预算，然后画设计图，再是施工，施工完成后，有专业人士进行质量检查，质检合格后入住。 　　OS/360(上世纪60年代的大型软件项目)------->开发人员(1000)----->最终无法运行------><人月神话>详细的说明了此次事故。 　　当计算机才发明出来的时候，计算机的能力非常有限，不需要软件工程也可以开发简单的软件。但是随着项目越来越复杂，规模越来越大，软件项目开发维护过程中问题就出来了------> 　　软件产品质量低劣、软件维护工作量大、成本不断上升、进度不可控、程序人员无限度地增加。所以在 60 年代，“软件危机”的概念被提出来。 3 软件工程的历史 (1)软件工程几个阶段 　

1.按测试模式来分类 　　瀑布模型、敏捷模型、基于脚本的测试、基于风险的测试、探索式测试等 2.传统的瀑布模型 　　项目计划——需求分析——软件设计——程序开发——软件测试——集成维护 3.瀑布模型的优缺点 　　优点 　　　　①强调需求、设计的作用 　　　　②前一阶段完成后，只需要关注后续阶段 　　　　③为项目提供了按阶段划分的检查点，里程碑清晰 　　　　④文档规范 　　缺点 　　　　①难以适应需求的频繁变化 　　　　②项目周期后端才能看到结果 　　　　③强制的里程碑、完成时间点 　　　　④文档工作量大 4.V模型 　　需求分析/验收测试——概要设计/系统测试——详细设计/集成设计——软件编码/单元测试 5.W模型 　　用户需求/验收测试设计——需求分析/系统测试设计——概要设计/集成测试设计——详细设计/单元测试设计——编码/单元测试——集成/集测试——实施/系统设计——交付/验收测试　 6.敏捷测试的特点 　　①强调从用户角度进行测试 　　②重点关注迭代测试新功能，不再强调测试阶段 　　③尽早测试，不间断测试，具备条件即测试 　　④强调持续反馈 　　⑤预防缺陷重于发现缺陷 7.敏捷测试和传统测试 　　传统测试：测试是质量的最后保护者 　　　　　　　严格的变更管理 　　　　　　　预先的计划和细节的准备 　　　　　　　重量级文档 　　　　　　　各阶段测试严格的入口和出口标准 　　　

几种常见软件过程模型的比较 一、瀑布模型（Waterfall Model） 瀑布模型（经典生命模型）提出了软件开发的系统化的、顺序的方法。其流程从用户需求规格说明开始，通过策划、建模、构建和部署过程，最终提供一个完整的软件并提供持续的技术支持。 模型特点 ： 必须等前一阶段的工作完成之后，才能开始后一段的工作； 每一阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。 前一阶段的输出文档就是后一阶段的输入文档，因此，只有前一阶段的输出文档正确，后一阶段的工作才能得到正确的结果。 每个阶段结束前都要对所完成的文档进行评审，以便及早发现问题，改正错误。事实上越是早期阶段犯下的错误，暴露出来的时间就越晚，排除故障改正错误所需付出的代价也越高。因此，及时审查，是保证软件质量，降低软件成本的重要措施。 模型优点 ： 强调了开发的阶段性，各阶段具有顺序性和依赖性 强调早期调研和需求分析，推迟编码实现的观点 提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。 模型局限 ： 瀑布模型是一种线性模型，要求项目严格按规程推进，必须等到所有开发工作全部完成以后才能获得可以交付的软件产品。不能对软件系统进行快速创建，对于一些急于交付的软件系统的开发很不方便。 瀑布模型适合于需求明确，且无大的需求变更的软件开发（编译系统、操作系统等）

为了指导软件开发，可以用不同的方式将软件生命周期中的所有开发活动组织组织起来从而形成不同的开发模型。 瀑布模式 瀑布模型严格遵守软件生命周期各阶段的固定顺序:计划、分析、设计、编程、测试和维护，上一阶段完成才能进入到下一阶段，整个模型像一个飞流直下的瀑布一下，如图所示 特点: 阶段间具有顺序性和依赖性 前一阶段完成后,才能开始后一阶段 前一阶段的输出文本为后一阶段的输入文本 推迟实现的观点 质量保证: 每个阶段必须交付出合格的文档 对文档进行审核 缺点: 开始需要把需求做到最全 惧怕用户测试中的反馈,惧怕需求变更 过于理想化缺乏灵活性 螺旋模型 限制条件: 适应于内部的大规模软件开发:螺旋模型强调风险分析,许多客户都无法接受和相信这种分析因此 适合于大规模软件项目(执行风险分析将大大影响项目的利润,进行风险分析就毫无意义) 软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会带来更大的风险 优点: 设计上的灵活性,可以在项目的各个阶段进行变更. 以小的分段来构建大型系统,使成本计算变得简单容易 客户始终参为保证了项目不偏离正确方向以及项目的可控性 客户始终掌握项目的最新信息,从而他或她能够和管理层有效地交互. 客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品. 缺点: 很难让用户确信这种演化方法的结果是可以控制的.建设周期长,而软件技术发展比较快

软件过程模型 分类： 瀑布模型、 增量模型、演化模型（原型模型、螺旋模型）、喷泉模型、基于构件的开发模型、形式化方法模型 瀑布模型： 优点： 容易理解，管理成本低；强调开发的阶段性早期计划及需求调查和产品测试。 不足之处是，客户必须能够完整、正确和清晰地表达他们的需要；在开始的两个或3个阶段中，很难评估真正的进度状态;当接近项目结束时，出现了大量的集成和测试工作:直到项目结束之前，都不能演示系统的能力。 在瀑布模型中，需求或设计中的错误往往只有到了项目后期才能够被发现，对于项目风险的控制能力较弱，从而导致项目常常延期完成，开发费用超出预算。 缺点： （1）开发过程一般不能逆转，否则代价太大； （2）实际的项目开发很难严格按该模型进行； （3）客户往往很难清楚地给出所有的需求，而该模型却要求如此。 （4）软件的实际情况必须到项目开发的后期客户才能看到，这要求客户有足够的耐心。 适用于： （1）用户的需求非常清楚全面，且在开发过程中没有或很少变化； （2）开发人员对软件的应用领域很熟悉； （3）用户的使用环境非常稳定； （4）开发工作对用户参与的要求很低。 它是以文档作为驱动、适合于软件需求分明的软件项目的模型 增量模型： 优点： 作为瀑布模型的一个变体，具有瀑布模型的所有优点。此外，它还有以下优点: （1）第一个可交付版本所需要的成本和时间很少; （2

瀑布模型核心思想 瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采 瀑布模型 用结构化的分析与设计方法将逻辑实现与物理实现分开。将 软件生命周期 划分为制定计划、 需求分析 、 软件设计 、程序编写、 软件测试 和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。 布模型的重要地位 瀑布模型是最早出现的 软件开发模型 ，在 软件工程 中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。（采用瀑布模型的 软件过程 如图所示） 1、瀑布模型有以下优点 1）为项目提供了按阶段划分的检 瀑布模型 查点。 2）当前一阶段完成后，您只需要去关注后续阶段。 3）可在 迭代模型 中应用瀑布模型。 增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和 集成测试 。 2、瀑布模型有以下缺点 1）在项目各个阶段之间极少有反馈。 2）只有在 项目生命周期 的后期才能看到结果。 3