第1章 软件工程概述

第1章软件工程概述11.1

软件的概念、特点和分类2软件的概念程序、软件与软件产品独唱

小合唱-->合唱-->万人大合唱

|||

简单程序较复杂程序软件软件是计算机系统中与硬件相互依存的另一部分,它包括程序、数据、相关文档的完整集合以及完善的售后服务。软件=程序+数据+文档+服务3软件的特点1.软件是一种逻辑实体，而不是具体的物理实体。2.软件的生产于硬件不同。3.在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题。失效率时间磨合调整磨损用坏硬件失效曲线失效率时间软件失效曲线理想曲线实际曲线4软件的特点4.软件的开发和运行常常受到计算机系统的限制，对计算机系统有着不同程度的依赖。5.软件的开发至今尚未完全摆脱手工业的开发方法。6.软件是复杂的，人类能够创造的最复杂的产物是计算机软件。7.软件成本相当昂贵。8.相当多的软件工作涉及到社会因素。5软件的分类1.按软件的功能划分⑴系统软件操作系统数据库管理系统设备驱动程序通信处理程序等6软件的分类⑵支撑软件文本编辑程序文件格式化程序磁盘向磁带向数据传输的程序程序库系统支持需求分析、设计、实现、测试和支持管理的软件7软件的分类⑶应用软件商业数据处理软件工程与科学计算软件计算机辅助设计／制造软件系统仿真软件智能产品嵌入软件医疗、制药软件事务管理、办公自动化软件计算机辅助教学软件8软件的分类2.按软件规模划分类别参加人员数研制期限源程序行数

微型 1 1～4周0.5k小型1 1～6月1k～2k中型2～5 1～2年5k～50k大型5～20 2～3年50k～100k甚大型100～10004～5年1M(=1000k)极大型2000～50005～10年1M～10M9软件的分类3.按软件工作方式划分

⑴实时处理软件

⑵交互式软件

⑶分时软件

⑷批处理软件4.按软件服务对象的范围划分

⑴项目软件

⑵产品软件10软件的分类5.按软件使用的频度划分

⑴仅供一次使用的软件

⑵频繁使用的软件6.按软件的失效⑴高可靠性软件。⑵一般可靠性软件。111.2

软件的发展和软件危机

12软件的发展软件的发展大体经历了如下三个阶段：

①程序设计阶段，约为50至60年代

特点：依赖于个人编程’技巧’，开发不规范，开发成本难控制，其交付的产品主要是程序。②程序系统阶段，约为60至70年代特点：软件开发是以小组的形式出现，提交的软件产品除了程序外还有相应的使用说明书。③软件工程阶段，约为70年代以后特点：开发方法遵循工程化的方法，按照软件生命周期分阶段开发软件，提交的软件产品除了程序之外，还有严格的文档。13计算机软件发展的三个时期及特点

时间特点程序设计程序系统软件工程软件所指程序程序及说明书程序、文档、数据、服务主要程序设计语言汇编及机器语言高级语言软件语言软件工作范围程序编写包括设计和测试软件生存期需求者程序设计本人少数用户市场用户开发软件的组织个人开发小组开发小组及大中型开发机构软件规模小型中小型大中小型决定质量的因素个人程序技术小组技术水平管理水平开发子程序程序库结构化程序设计数据库、开发工具、开发环境、工程化开发方法、标准和规范、网络和分布式开发、面向对象技术维护责任者程序设计者开发小组专职维护人员硬件特征价格高存储容量小工作可靠性差降价、速度、容量及工作可靠性有明显提高向超高速、大容量、微型化及网络化方向发展软件特征完全不受重视软件技术的发展不能满足需要，出现软件危机开发技术有进步，但未获突破性进展，价高，未完全摆脱软件危机14软件工程的发展的四个重要阶段1、第一代软件工程

—

传统的软件工程2、第二代软件工程

—对象工程3、第三代软件工程

—过程工程4、第四代软件工程

—构件工程

60年代末到70年代为了克服“软件危机”(Softwarecrisis)提出“软件工程”的名词,将软件开发纳入工程化的轨道，基本形成软件工程的概念、框架、技术和方法。称为传统的软件工程。15软件工程的发展的四个重要阶段1、第一代软件工程

—

传统的软件工程2、第二代软件工程

—对象工程3、第三代软件工程

—过程工程4、第四代软件工程

—构件工程

80年代中到90年代，面向对象的方法与技术得到发展，研究的重点转移到面向对象的分析与设计，演化为一种完整的软件开发方法和系统的技术体系，称为对象工程。16软件工程的发展的四个重要阶段1、第一代软件工程

—

传统的软件工程2、第二代软件工程

—对象工程3、第三代软件工程

—过程工程4、第四代软件工程

—构件工程

80年代中开始，人们在软件开发的实践过程中认识到：提高软件生产率，保证软件质量的关键是“软件过程”，是软件开发和维护中的管理和支持能力，逐步形成软件过程工程。17软件工程的发展的四个重要阶段1、第一代软件工程

—

传统的软件工程2、第二代软件工程

—对象工程3、第三代软件工程

—过程工程4、第四代软件工程

—构件工程

90起年代，基于构件（Component）的开发方法取得重要进展，软件系统的开发可通过使用现成的可复用构件组装完成，而无需从头开始构造，以此达到提高效率和质量，降低成本的目的。称为构件工程。18软件开发方法的模型随意编程面向过程面向对象面向组件面向配置组件面向WebService19什么是软件危机定义：软件危机是计算机软件在它的开发和维护过程中所遇到的一系列严重问题。主要包含两方面的问题：

⑴如何开发软件，怎样满足对软件日益增长的需求；

⑵如何维护数量不断膨胀的已有软件。20软件危机的现象⑴对软件开发成本和进度的估计常常很不准确。⑵用户对“已完成的”软件系统不满意的现象经常发生。⑶软件产品的质量往往靠不住。⑷软件常常是不可维护的。⑸软件通常没有适当的文档资料。计算机软件不仅仅是程序，还应该有一整套文档资料。⑹软件成本在计算机系统总成本中所占的比例逐年上升。⑺软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。21软件危机的原因⑴客观：软件本身特点软件的规模庞大、复杂性高。⑵主观：不正确的开发方法，软件开发和维护有许多错误的认识和作法。忽视需求分析软件开发=程序编写轻视软件维护22软件的神话——管理者的神话负责软件的管理者像大多数其他管理者一样，都有巨大的压力，要维持预算，保持进度和提高质量。神话：我们已经有了关于建造软件的标准和规程的书籍，难道它们不能给人们提供所有其需要知道的信息吗？事实：不错，关于标准的书籍已经存在，但真正用到了它们吗？软件实践者知道它们存在吗？它们是否反映了现代软件开发的过程？它们完整吗？很多情况下对于这些问题的答案是“否”。23软件的神话——管理者的神话神话：我们已经有了很多很好的软件开发工具，而且，我们为它们买了最新的计算机。事实：为了使用最新型号的计算机、工作站和PC机去开发高质量的软件，我们已经投入了太多的费用。实际上，计算机辅助软件工程（CASE）工具比起硬件而言，对于获得高质量和高生产率更为重要，但大多数软件开发者并未使用它们。24软件的神话——管理者的神话神话：如果我们已落后于计划，可以增加更多的程序员来赶上进度。事实：软件开发并非像制造一样是一个机械过程。用Brooks的话来说，“给一个已经延迟的软件项目增加人手只会使其更加延迟”。看起来，这句话与人的直觉正好相反。但实际上，增加新人，原来正在工作的开发者必须花时间来培训新人，这样就减少了他们花在项目开发上的时间。人手可以增加，但只能在计划周密、协调良好的情况下。25软件的神话——用户的神话需要计算机软件的用户可能就是邻桌，或是另一个技术组，也可能是市场／销售部门，或另一个公司。在许多情况下，用户相信关于软件的神话，因为负责软件的管理者和开发者很少去纠正用户的错误理解。神话导致了用户过高的期望值，并引起对开发者的极端不满。神话：有了对目标的一般描述就足以开始写程序了——我们可以以后补充细节。事实：不完善的系统定义是软件项目失败的主要原因。关于待开发项目的应用领域、功能、性能、接口、设计约束及确认标准的形式化的、详细的描述是必需要的。这些内容只有通过用户和开发者之间的通信交流才能确定。26软件的神话——用户的神话神话：项目需求总是在不断变化，但这些变化能够很容易地满足，因为软件是灵活的。事实：软件需求确实是经常变化的，但这些变化产生的影响会随着其引入的时间不同而不同。如果我们很注重早期的系统定义，这时需求变化就可很容易地适应。用户能够复审需求，并提出对修改建议，这时对成本的影响会相对较小。当在软件设计过程中才要求修改时，对成本的影响就会提高的很快。资源已经消耗了，设计框架已经建立了，这时的变化可能会引起大的改动，需要额外的资源和大量的设计修改：如额外的花费。实现阶段（编码和测试阶段）功能、性能、接口及其它方面的改变对成本会产生更大的影响。当软件已投入使用后再要求修改，这时所花费的代价比起较早阶段做同样修改所花的代价可能是几何级数级的增长。27例子某公园有一游船码头，负责人请一位软件开发人员实现计算机系统辅助游船管理系统，要求如下：当游客向租船处租船时，向租船处查询是否有可租用的船只，如果租船处有空船，管理员就准备好船只，帮助游客上船，并在联机终端上打入一个信息“S”，表示租船周期开始。计算机自动把当时时钟值送入信息域。当游客还船时，管理员打入另一个信息“E”，表示租船周期结束。由管理员向游客结算租船时间及费用。一天结束时，管理员要用一些管理信息总结每天工作状况，要求系统打印出租船次数=NNN

平均租船时间=MMM

显然，这样一个系统的功能包括二个部分：

⑴计算输入流的信息

⑵打印输出28确定算法我们知道平均租船时间就是总的时间除以租船次数总的时间=第一条船结束时间-第一条船开始时间+第二条船结束时间-第二条船开始时间+…

或总的时间=（第一条船结束时间+第二条船结束时间+…）-（第一条船开始时间+第二条船开始时间+…）29编写系统程序BEGINOPENMESSAGE_STREAMNUMBER=0TOTALTIME=0GETMESSAGEDOWHILENOTEND_OF_STREAMIFCODE=STHENNUMBER=NUMBER+1TOTAL_TIME=TOTAL_TIME-START_TIMEELSETOTAL_TIME=TOTAL_TIME+END_TIMEENDIFPRINT“NUMBEROFSESSION=”NUMBERIFNUMBER<>0THENPRINT“AVERAGESESSIONTIME=”TOTAL_TIME/NUMBERENDIFCLOSEMASSAGE_STREAMEND;30系统提出修改①找出一天中最长租用时间：

LONGGEST_SESSION_TIME=PPP②要求把每天的报告分成两个，一个是上午情况，另一个是下午情况。③通信线路出了毛病，丢掉了一些信息。要求修改系统——从计算报告中删除一切不完整的租船信息。对于上述的修改，除了把原系统废弃之外。实在无法对其作什么修改来满足这一新的要求。而时间及经费都不允许他这么做了。结论：并不是任意设计出来的软件都能够适应在软件寿命期内变化的要求，即软件的灵活性不是绝对的。31软件的神话——开发者的神话那些至今仍被软件开发者相信的神话是由几十年的程序设计文化培植起来的。而这种旧的观念和方式是很难改变的。神话：一旦我们写出了程序并使其正常运行，我们的工作就结束了。事实：有人说过：“越早开始写程序，就要花越长的时间完成它”，大量的数据表明在一个程序上所投入的50%到70%的努力是花在第一次将程序交给用户之后。32软件的神话——开发者的神话神话：在程序真正运行之前，没有办法评估其质量。事实：从项目一开始就可以应用的最有效的软件质量保证机制之一是正式的技术复审。软件复审是“质量的过滤器”，比起通过测试找到某类软件错误要有效的多。神话：一个成功的项目唯一应该提交的就是运行程序。事实：运行程序仅是仍软件配置的一部分，软件配置包括：程序、文档和数据。文档是成功开发的基础，更重要的是，文档为软件维护提供了指导。33软件危机解决途径组织管理工程项目管理方法技术措施软件开发技术与方法软件工具341.3

软件工程35软件工程的提出“软件工程”一词是1968年北大西洋公约组织（NATO）在联邦德国召开的一次会议上首次提出的，这个会议专门讨论了软件危机问题。它反映了软件人员认识到软件危机的出现及谋求解决这一危机的努力，因此，这次会议被看作是软件发展史上一个重要的里程碑。36软件工程定义采用工程的概念、原理、技术和方法来计划、开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以较经济的手段获得能在实际机器上运行的可靠软件的一系列方法。简言之：工程方法+管理技术+技术方法37软件工程原理著名的软件工程专家B.W.Boehm提出了软件工程的七条基本原理。这七条原理是确保软件产品质量和开发效率的原理的最小集合。这七条原理是互相独立的，其中任意六条原理的组合都不能代替另一条原理，因此，它们是缺一不可的最小集合，然而这七条原理又是相当完备的，人们虽然不能用数学方法严格证明它们是一个完备的集合，但是，可以证明在此之前已经提出的100多条软件工程原理都可以由这七条原理的任意组合蕴含或派生。38软件工程原理⒈用分阶段的生命周期计划严格管理不成功的软件项目中有一半左右是由于计划不周造成的。⒉坚持进行阶段评审软件的质量保证工作不能等到编码阶段结束之后再进行。⒊实行严格的产品控制在软件开发过程中不应随意改变需求，因为改变一项需求往往需要付出较高的代价。⒋采用现代程序设计技术采用先进的技术既可提高软件开发的效率，又可提高软件维护的效率。39软件工程原理⒌结果应能清楚地审查根据软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准，从而使得所得到的结果能够清楚地审查。⒍开发小组的人员应该少而精开发小组人员的素质和数量是影响软件产品质量和开发效率的重要因素。小组人员增加，交流情况和讨论问题而造成的通讯开销也急剧增加，人数为N，可能的通讯路径有N(N-1)。

⒎

承认不断改进软件工程实践的必要性不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验。40软件工程学的范畴软件工程学软件工程技术软件工程管理软件开发方法学软件工具软件工程环境软件经济学软件管理学41软件工程三要素软件工程包括三要素：方法、工具和过程。⑴软件工程方法为软件开发提供了“如何做”的技术。⑵软件工具为软件工程方法提供了自动的或半自动的软件支撑环境。⑶软件工程的过程则是将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。42什么是软件工程过程定义：软件工程过程是为获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动。针对不同类型的软件产品，同一软件开发机构也可能采用多个不同的软件工程过程。43软件工程过程的基本活动⑴软件规格说明：规定软件的功能及其运行的限制；⑵软件开发：产生满足规格说明的软件；⑶软件确认：确认软件能够完成客户提出的要求；⑷软件改进：为满足客户的变更要求，软件必须在使用的过程中改进。44软件工程过程的特性⑴易理解性。⑵可见性：每个过程活动均能以明确的结果告终，使过程的进展对外可见。⑶可支持性：易得到计算机辅助软件工程（CASE）工具的支持。⑷可接受性：易于为软件工程师接受和使用。⑸可靠性：不会出现过程错误，或发现在产品出现故障之前。⑹健壮性：不受意外发生的问题干扰。⑺可维护性：过程可随软件机构需求的变更或随认定的过程改进而演进。⑻速度：从规格说明起，就能较快地完成开发而交付。45软件工程项目的基本目标⑴付出较低的成本；⑵达到要求的软件功能；⑶取得较好的软件性能；⑷开发的软件易于移植；⑸需要较低的维护费用；⑹能按时完成开发工作，及时交付使用。46软件工程目标之间的关系47软件工程框架及原则1．选取适宜的开发模型；2．采用合适设计方法；3．提供高质量工程支持；4．重视开发过程管理。48软件工程面临的问题

(1)软件费用

(2)软件可靠性

(3)软件维护

(4)软件生产率

(5)软件重用491.4

软件生命周期50软件生命周期的定义定义：软件生命周期是指软件产品从考虑其概念开始到该软件产品不再能使用为止的整个时期。软件生命周期可分为三个阶段：即定义阶段、开发阶段和运行维护阶段，每个阶段需完成几个任务。51划分软件生命周期的目的和实质⑴便于控制开发工作的复杂性。⑵通过有限的步骤，把用户的需求从抽象的逻辑概念逐步转化为具体的物理实现。52软件生命周期各阶段的基本任务－定义阶段定义阶段主要集中于“做什么”，即在定义过程中，软件开发人员试图弄清楚要处理什么信息，预期完成什么样的功能和性能，希望有什么样的系统行为，建立什么样界面，有什么设计约束，以及定义一个成功系统的确认标准是什么。在本阶段需完成三项任务：53系统定义系统定义必须回答的关键问题是：“要解决的问题是什么？”如果不知道问题是什么就试图解决这个问题，显然是盲目的，只会白白浪费时间和金钱，最终得出的结果很可能是毫无意义的。尽管确切地定义问题的必要性是十分明显的，但是在实践中它却可能是最容易被忽视的一个步骤。系统定义是软件生命周期中最简短的任务，一般只需要一天甚至更少的时间。54可行性研究可行性研究要回答的关键问题是：“对于上一个阶段所确定的问题有行得通的解决办法吗？”为了回答这个问题，系统分析员需要进行一次大大压缩和简化了的系统分析和设计的过程，也就是在较抽象的高层次上进行的分析和设计的过程。可行性研究应该比较简短，这个阶段的任务不是具体解决问题，而是研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法。55需求分析需求分析的任务仍然不是具体地解决问题，而是准确地确定“为了解决这个问题，目标系统必须做什么”，主要是确定目标系统必须具备哪些功能。系统分析员在需求分析阶段必须和用户密切配合，充分交流信息，以得出经过用户确认的系统逻辑模型。通常用数据流图、数据字典和简要的算法表示系统的逻辑模型。56软件生命周期各阶段的基本任务－开发阶段开发阶段集中于“如何做”。即在开发过程中，软件工程师试图定义数据如何结构化，功能如何转换为软件体系结构，过程细节如何实现，界面如何表示，设计如何转换成程序设计语言，测试如何运行。在本阶段需完成四项任务：57总体设计总体设计必须回答的关键问题是：“概括地说，应该如何解决这个问题？”通常至少应该考虑下述几类可能的方案：①低成本的解决方案。系统只能完成最必要的工作，不能多做一点额外的工作。②中等成本的解决方案。这样的系统不仅能够很好地完成预定的任务，使用起来很方便，而且可能还具有用户没有具体指定的某些功能和特点。虽然用户没有提出这些具体要求，但是系统分析员根据自己的知识和经验断定，这些附加的能力在实践中将证明是很有价值的。③高成本的“十全十美”的系统。这样的系统具有用户可能希望有的所有功能和特点。58详细设计总体设计以比较抽象概括的方式提出了解决问题的办法。详细设计的任务就是把解法具体化，也就是回答下面这个关键问题：“应该怎样具体地实现这个系统呢？”通常用HIPO图（层次图加输入／处理／输出图）、PAD图或PDL语言（过程设计语言）描述详细设计的结果。59编码和单元测试编码和单元测试的关键任务是写出正确的容易理解、容易维护的程序模块。60综合测试综合测试的关键任务是通过各种类型的测试（及相应的调试），使软件达到预定的要求。最基本的测试是集成测试和验收测试。所谓集成测试是根据设计的软件结构，把经过单元测试检验的模块按某种选定的策略装配起来，在装配过程中对程序进行必要的测试。所谓验收测试则是按照规格说明书的规定（通常在需求分析阶段确定），由用户（或在用户积极参加下）对目标系统进行验收。必要时还可以再通过现场测试或平行运行等方法对目标系统进一步测试检验。为了使用户能够积极参加验收测试，并且在系统投入生产性运行以后能够正确有效地使用这个系统，通常需要以正式的或非正式的方式对用户进行培训。61软件生命周期各阶段的基本任务－软件维护维护阶段的关键任务是，通过各种必要的维护活动使系统持久地满足用户的需要。通常有四类维护活动：改正性维护，也就是诊断和改正在使用过程中发现的软件错误；适应性维护，即修改软件以适应环境的变化；完善性维护，即根据用户的要求改进或扩充软件使它更完善；预防性维护，即修改软件为将来的维护活动预先做准备。每一项维护活动都应该准确地记录下来，作为正式的文档资料加以保存。62软件生命周期各阶段任务一览表阶段关键问题结束标准系统定义问题是什么？关于规模和目标的报告书可行性研究有可行的解吗？系统的高级逻辑模型；数据流图成本／效益分析需求分析系统必须做什么？系统的逻辑模型；数据流图；数据字典；算法描述总体设计概括地说，应该如何解决这个问题？可能的解法：系统流程图；成本／效益分析；推荐的系统结构；层次图或结构图详细设计怎样具体地实现这个系统？编码规格说明：HIPO图或PDL编码和单元测试正确的程序模块源程序清单；单元测试方案和结果综合测试符号要求的软件综合测试方案和结果；完整一致的软件配置维护持久地满足用户需求的软件完整准确的维护记录631.5

软件开发模型64软件开发模型在整个软件开发的发展过程中，为了要从宏观上管理软件的开发和维护，就必须对软件的发展过程有总体的认识和描述，即要对软件过程建模。几十年来，软件开发生命周期模型的发展有了很大的变化，提出了一系列的模型以适应软件开发发展的需要。65编码--修正模型在软件开发早期，开发只有两个阶段，被简单的分成编写程序代码和修改程序代码。拿到项目，马上就根据需要，开始编写程序。编完代码，调试通过，就算基本完成任务，拿给用户用。如果应用中有什么错误，或有什么新的要求，要重新修改代码。66编码--修正模型的弊端1．代码缺少统一规划，低估了设计的重要性，使得代码结构随着修改的次数增加变得越来越坏。以至错误越来越难改，甚至无法改。2．即使有的软件计划很好，但往往其结果并非用户所需要的。造成软件开发的风险非常大。这主要是没有重视需求而造成的。3．由于对测试、维护修改方面考虑不周，使得代码维护修改非常困难。67瀑布模型由于吸取了开发早期的教训，人们开始将软件开发视为工程来管理。类似于其他的工程管理，软件开发也具有一定的工序。“软件生命周期”这一概念真正被提了出来，并将软件生命周期划分成：制定计划，需求分析、软件设计、程序编写、软件测试、运行与维护等六个部分。68瀑布模型69瀑布模型的特点⑴从上一项开发活动接受该项活动的工作对象，作为输入。⑵利用这一输入，实施该项活动应完成的工作内容。⑶给出该项活动的工作成果，作为输出传给下一项活动。⑷对该项目活动实施的工作成果进行评审。若工作得到确认，则继续进行下一次开发活动，否则返回前一项，甚至更前项的活动。70瀑布模型优点⑴消除非结构化软件。⑵降低软件的复杂度。⑶促进软件开发工程化。71瀑布模型存在的问题⑴阶段与阶段划分完全固定，阶段间产生的大量文档，极大地增加了工作量。⑵由于开发模型呈线性，所以当开发成果尚未经过测试时，用户无法看到软件的效果。这样，软件与用户见面的时间较长，也增加了一定的风险。⑶前面未发现的错误传到后面的开发活动中，可能会扩散，进而可能会造成更不理想的效果。72平行瀑布模型考虑对瀑布模型的进一步改进。对瀑布模型的各阶段之间的转换时，不一定要求完全按顺序进行。而是以适当的并行开展各阶段的工作。在上一阶段尚未完成结束前，就可以开设后一阶段的工作。根据不同的情况可有不同的并行度：⑴用户想法不稳定，如：每天都变换想法，要求不太清楚的话，则增加并行度。⑵短期显示成果的压力大，则可增加并行度。⑶如果可靠性要求高；要求各方面控制和配合很严格；资源及预算严密；技术错误的后果严重时，则需减少并行度。73原型模型常有这种情况，用户定义了软