瀑布模型

软件工程导论笔记 1.1软件危机 1.2软件工程 1.4软件过程 1.4.1瀑布模型 1.4.2快速原型模型 1.4.3增量模型 1.4.4螺旋模型 1.4.5喷泉模型 1.4.6Rational统一过程（RUP） 1.4.7敏捷过程与极限编程 1.4.8微软过程 1.1软件危机 软件危机：软件开发和维护中遇到的一系列严重问题。 软件危机的典型表现： 软件开发的成本和进度常估计不准确 用户经常不满意已完成的软件 软件产品的质量常靠不住 软件常不可维护 没有文档 软件成本在计算机系统总成本中所占的比例逐年上升 软件开发生产效率提高的速度，跟不上计算机应用迅速普及深入的趋势 软件危机产生的原因： 与软件本身特点有关 1、软件不同于硬件，管理和控制软件开发过程相当困难。 2、软件在运行过程中不会因为使用过长而被“用坏”。如果运行中发现了错误，很可能是遇到了一个在开发时期引入的、在测试阶段没能检测出来的错误。 3、软件不同于一般程序，它的一个显著特点是规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。 4、事实上，对用户要求没有准确的认识就匆忙着手编写程序是许多软件开发工程失败的主要原因之一。 5、目前相当多的软件专业人员对软件开发和维护还有不少糊涂观念。在实践过程中或多或上地采用了错误的方法和技术，这可能是使软件问题发展成软件危机的主要原因。 6

关于“银弹” Brooks 在 No Silver Bullet 一文中开篇便提到 “There is no silver bullet”，并且从软件工程的本质上解释了为什么一个能够解决关键问题的“武器”在软件工程上不存在（软件工程的 Complexity;Conformity;Changeability;Invisibility）。之后作者又从这么多年软件工程的发展来解释为什么没有“银弹”，无论是高抽象的语言、合理的构建方法、面向对象的思想等等。这些都不能解决软件工程带来的根本性问题。我认为，作者这么说是有道理的。 而在另一篇关于“银弹”的文章中，作者以思辨的角度从历史和方法论的观点来对软件工程中是否有银弹做了分析： 面向对象的编程思想提供了一种编写复杂系统的方法（从小的组件开始写起（造轮子））；可复用的组件以及硬件的更新都推动了软件工程的发展。软件工程发展到了现在，确实还有问题需要解决，但是正是这些问题能够不断推动软件工程的发展。 所以，就从现在来说，软件工程中的“银弹”还未出现，但是随着方法、科技的不断进步，或许之后会产生。 关于“大泥球” 大泥球的定义： 在软件工程的整个结构方面，大泥球是这样被定义的：A BIG BALL OF MUD is a casually, even haphazardly, structured system. 在具体实现上面

银弹 我认为是没有银弹的。No silver bullet 感觉有点像机器学习中的No free lunch theorem，就是说没有一种算法对所有问题是都适用的，我们需要具体问题具体看待。在软件工程中，我也认为没有silver bullet可以去解决所有的问题，包括高级程序设计语言，包括面向对象建模方法，还有各种设计模式，都只能解决一部分问题，因为软件构建过程过于复杂，很多情况都不能很周全地考虑到。或许将来通过人工智能可以造出一个银弹，但目前来说，我们可能还是需要更多的“铜弹”。 大泥球 大泥球的出现是因为代码没有规范，随意编写，缺乏整体的设计，导致难以维护的代码产生。更深层次的原因是成本、时间等的限制。这导致软件开发中的不断迭代难以进行。 我们的项目中，上届留下的代码中有部分泥球。有些代码已经不再使用，但还留存着。 解决大泥球的方法就是前期尽量做好周全的设计，严格执行代码的规范。 大教堂和集市 大教堂：代码是开源的，但是每个版本的开发工作只能由一组开发人员来完成。 集市：源代码公之于众，所有人都可以提交自己的代码。 我们组的开发方式是大教堂，我们的项目在github上开源，但是只有我们组内的成员有权限去修改代码。 我们没有出现过迷失的情况，可能是因为我们构建的软件并不是非常复杂。 Worse？Better？ 为了以后更好地维护软件，我们需要维持良好的代码质量，但这需要时间

个人阅读作业2 作业要求：阅读关于软件开发本质和开发方法的博客/文章，结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。 No Silver Bullet - Essence and Accidents of Software Engineering这篇文章主要将软件工程存在很多问题与困难，并且解决的希望十分地渺茫。欧洲中世纪传说，有一种叫“人狼”的妖怪，它们专在月圆之夜袭击人类，传说中对“人狼”，普通子弹都伤不到也打不死它，只有一种用银制的特殊子弹才能把它杀死。引用此典故，用狼人来比喻在软件开发过程中所遇到的难题；用能够奇迹似地将狼人一枪毙命的银弹来比喻解决软件开发过程中难题的方法。软件工程发展到现在遇到了很多问题，其中软件工程开发所面临的本质问题是复杂性、整合性、易变性和不可视性。为了解决这些问题，人们探索了很多方法，比如高级语言、分时系统和统一编程环境等，但是这些都没软件工程的解决本质问题，只是从一些程度上减少了错误的发生率。最后作者写了一些可能的解决方案，如模块化编程、面向对象编程等，但是又认为解决本质问题的可能性似乎都很小。 There Is a Silver Bullet – Brad J Cox这篇文章与第一篇文章都在讨论软件工程中的silver bullet，本篇作者比第一篇作者要乐观的多，他认为面向对象、软件封装

百科名片 软件开发模型 软件 开发模型 (Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。 软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。对于不同的软件系统，可以采用不同的开 发方法、使用不同的 程序设计语言 以及各种不同技能的人员参与工作、运用不同的管理方法和手段等，以及允许采用不同的软件工具和不同的 软件工程 环境。 目录 类型简介 典型的开发模型 展开 编辑本段 类型简介 瀑布模型 　　最早出现的软件开发模型是1970年W·Royce提出的 瀑布模型 。 该模型给出了固定的顺序，将生存期活动从上一个阶段向下一个阶段逐级过渡，如同流水下泻，最终得到所开发的软件产品，投入使用。但计算拓广到统计分析、商 业事务等领域时，大多数程序采用高级语言(如FORTRAN、COBOL等)编写。瀑布模式模型也存在着缺乏灵活性、无法通过并发活动澄清本来不够确切的 需求等缺点。 常见模型 　　演化模型、螺旋模型、喷泉模型、 智能模型 等。 编辑本段 典型的开发模型 综述 　　典型的开发模型有：1. 边做边改模型 （Build-and-Fix Model）；2. 瀑布模型（Waterfall Model）；3. 快速原型模型

软件工程与UML笔记 第一章 面向对象软件工程概论 要求学习的内容： 软件危机 软件工程的由来 软件工程的定义 软件工程的范畴 软件工程实践的目标 软件开发包含的活动 软件维护的成本 修复bug的代价 一.软件危机 软件定义： 软件是程序以及开发、使用和维护程序所需要的所有文档。 软件危机定义： 软件开发和维护过程中遇到的一系列严重问题 表现： 对软件开发成本和进度的估计不准确； 软件产品质量很不可靠； 可维护性差，软件的文档资料不完整和不合格； 软件成本逐年上升； 软件开发生产率不高，不能满足客观需要。 软件危机原因： （1）人们对于软件概念与范畴的理解。 早期软件工程师崇尚个人英雄主义，整个软件开发通常处于一种无序的状态。他们大多认为编写程序就是软件开发的全部。这种观念会导致随着软件规模的增大，程序员对于文档的忽略与不重视，使得软件开发产品的不健全与维护困难。 （2）软件的规模日益增长、设计日益复杂。 Visual Studio/Office等（M->G） （3）软件开发组织发生变化。 在上述因素发生变化的同时，软件开发组织也在发生着变化。早期开发一款小型软件，可能1-2个开发人员就可以完成。然而随着软件规模的飞速增长，软件开发组织也在同比例增长，由单打独斗的状态改变为一个团队若干开发人员共同研发一款产品。人员由一个变成团队协同开发，这种组织形式的转变

在20世纪80年代之前，瀑布模型一致是唯一被广泛采用的生命周期模型，现在它仍然是软件工程中应用得最广泛的过程模型。传统软件工程方法学的软件过程，基本上可以用瀑布模型来描述。 一、按照传统的瀑布模型开发软件，有下述的几个特点： 1、阶段间具有顺序性和依赖性 这个特点有两重含义： （1）必须等前一阶段的工作完成之后，才能开始后一阶段的工作； （2）前一阶段的输出文档就是后一阶段的输入文档，因此，只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。 2、推迟实现的观点 实践表明，对于规模较大的软件项目来说，往往编码开始得越早，最终完成开发工作所需要的实践反而越长。这是因为，前面阶段的工作没做或做得不扎实，过早地考虑进行程序实现，往往导致大量返工，有时甚至发生无法弥补的问题，带来灾难性后果。 瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，分析与设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。 清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要的指导思想。 3、质量保证的观点 为了保证所开发软件的质量，在瀑布模型的每个阶段都应该坚持两个重要做法： （1）每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。 完整、准确的合格文档不仅是软件开发时期各类人员之间相互通信的媒介

个人阅读作业 M1/M2总结 本学期的软件工程课程我们小组完成可学霸系统的项目，经过一学期的团队合作，大家都有了很大的提高。 在M1阶段我们对学长的代码进行了移植处理，但是在这个过程中我们苦不堪言，因为学长的代码有很多漏洞，后台的数据库也存在很多问题。当时给我们造成了很大的困扰，一度让我们放弃移植这个项目，不过大家讨论之后还是积极地应对，分工合作，学习了C#,XML,TFS等等知识，大家也都很努力的尝试修改错误，在这个过程中提升自我，这也是我们当时每天的一项很重的任务。不过最终经过大家的不懈努力和默契配合，我们顺利的完成了学霸M1阶段的开发。 在M2阶段我们更是被弄得十分疲倦，这个时期是我们各门课程大作业的顶峰时期，很多课程也都在考期。不过在小组大家的互相鼓励和监督，我们抽出每天的时间间隙，不断的优化和改进项目。虽然我们的项目可能还会有不完善的地方，不过我们大家的努力还是取得了应有的收获。 链接到以前提问题的博客 链接： http://www.cnblogs.com/lhm924/p/4830972.html 敏捷开发中有哪些常用的方法？ 水晶方法Crystal,XP极限编程，SCRUM,FDD特性驱动，DSDM,ASD等 瀑布模型是否已经不适应现在的软件开发模式？ 由于瀑布模型过于强调文档的作用，在每个阶段讲究仔细地验证，过于理想化了。存在许多现实问题：1）

4.1 软件工程概述 4.1.3 软件生存周期 （1）可行性分析 确定开发目标及可行性，需要多少钱，多少时间，多少资源 参与人员：用户、项目负责人、系统分析师 文档：可行性分析报告、项目开发计划 （2）需求分析 不具体解决问题，确定软件系统必须、做什么确定软件系统的功能、性能、数据、界面，从而确定系统逻辑模型 参与人员：用户、项目负责人、系统分析师 文档：软件需求说明书 （3）概要设计 设计软件结构，明确软件由哪些模块组成，层次结构，模块功能、模块调用关系。设计系统总结结构和数据结构 参与人员：系统分析师、软件设计师 文档：概要设计说明书 （4）详细设计 对每个模块进行具体设计 参与人员：软件设计师、程序员 （5）编码 （6）测试 参与人员：另一个部门软件设计师或系统分析师 文档：软件测试计划、测试用例、软件测试报告 （7）维护 4.2 软件过程模型 软件过程模型也叫软件开发模型。软件开发全部过程、活动和任务的结构框架 4.2.1 瀑布模型 瀑布模型是将软件生存周期中的各个活动规定为依线性顺序连接的若干阶段的模型 它是以文档作为驱动、适合与软件需求很明确的软件项目模型 优点：容易理解，管理成本低，强调开发的阶段性早期计划及需求和产品测试 缺点：客户必须能够完整、正确和清晰地表达他们的需要，错误到了后期才能发现 4.2.2 增量模型 融合了瀑布模型的基本成本和原型实现的迭代特征

软件工程--软件过程模型 软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。通常使用生命周期模型简洁地描述软件过程。生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序，因此，也称为过程模型。常见的过程模型有瀑布模型、快速原型模型、增量模型、螺旋模型、喷泉模型等。 1.瀑布模型 这个特点有两重含义： 1.必须等前一阶段的工作完成之后，才能开始后一阶段的工作； 2.前一阶段的输出文档就是后一阶段的输入文档，因此，只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。 瀑布模型每个阶段都应坚持两个重要做法： 1.每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。完整、准确的合格文档是软件开发时期各类人员之间相互通信的媒介，也是运行时期对软件进行维护的重要依据。 2.每个阶段结束前都要对所完成的文档进行评审，以便迟早发现问题，改正错误。事实上越是早期阶段犯下的错误，暴露出来的时间就越晚，排除故障改正错误所需付出的代价也越高。因此，及时审查，是保证软件质量，降低软件成本的重要措施。 可以说瀑布模型是由文档驱动的。这个事实也是它的一个缺点，在可运行的软件产品交付给用户之前，用户只能通过文档来了解产品是什么样的。瀑布模型历史悠久、广为人知的，它的优势在于它是规范的、文档驱动的方法；这种模型的问题是