《软件工程与开发环境》第一章软件危机与软件工程

1自从20世纪40年代中期出现第一台计算机开始，就有程序的概念。计算机硬件：经历了电子管、晶体管、大规模集成电路、超大规模集成电路四代，并以1.5年为更新周期的速度发展。软件经历了由个体化生产、作坊式生产、软件工厂的发展过程。计算机硬件性能／价格比平均每十年提高二个数量级，而且质量稳步提高；与此同时，计算机软件成本却在逐年上升，质量没有可靠的保证，软件开发的生产率也远远跟不上普及计算机应用的要求。软件已经成为限制计算机系统发展的关键因素。第一章软件危机与软件工程21．1软件危机在计算机系统发展的早期时代的一些错误概念和做法，已经严重地阻碍了计算机软件的开发。用错误方法开发出来的许多大型软件几乎根本无法维护和升级，只好提前报废，造成大量人力、物力的浪费。在计算机系统发展的早期时代(60年代中期以前)，通用硬件相当普遍，软件却是个体编写，编写的程序技巧越多越好，可读性极差。从60年代中期到70年代中期是计算机系统发展的第二代时期。重要特征：是“软件作坊”。基本上仍然沿用早期形成的个体化软件开发方法。广泛使用产品软件。3随着计算机应用的日益普及，软件数量急剧膨胀。软件维护工作以令人吃惊的比例耗费资源。更严重的是，许多程序的个体化特性使得它们最终成为不可维护的。“软件危机”就这样开始出现了。在1968年和1969年北大西洋公约组织成员国软件工作者两次召开会议（NATO会议），讨论摆脱软件危机的办法，提出了软件工程的概念。1972年IEEE的计算机协会第一次出版了《软件工程学报》，软件工程术语被接受、流行。4

1．l.1什么是软件危机软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。概括地说，软件危机包含下述两方面的问题：如何开发软件；如何维护软件。软件危机主要有下述一些表现：

(1)对软件开发成本和进度的估计常常很不准确。这种现象降低了软件开发组织的信誉。损害软件产品的质量，用户的不满。

(2)用户对“已完成的”软件系统不满意的现象经常发生。对用户要求了解有限，交流不充分，仓促编写程序。

“闭门造车”必然导致最终的产品不符合用户的实际需要。5

(3)软件产品的质量往往靠不住。软件质量保证技术(审查、复审和测试)还没有坚持不懈地应用到软件开发的全过程中，这些都导致软件产品发生质量问题。

(4)软件常常是不可维护的。很多程序中的错误是非常难改正的。“可重用的软件”还是一个没有完全做到的、正在努力追求的目标，人们仍然在重复开发类似的或基本类似的软件。(5)软件通常没有适当的文档资料。(6)软件成本在计算机系统总成本中所占的比例逐年上升。美国在1985年软件成本大约已占计算机系统总成本的90％。

(7)软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。软件产品“供不应求”的现象使人类不能充分利用现代计算机硬件提供的巨大潜力．61．1．2产生软件危机的原因一方面与软件本身的特点有关，另一方面也和软件开发与维护的方法不正确有关。

软件不同于硬件，它是计算机系统中的逻辑部件而不是物理部件。软件的一个显著特点是规模庞大。美国70年代末穿梭号宇宙飞船的软件包含4000万行目标代码。假设一个人一年开发一万行的程序，为了开发一个4000万行的软件，是否集中4000人的力量一年就可以完成呢?绝对做不到!因为代码长度增加丁4000倍，程序复杂程度的增加远远超过4000倍。7不仅涉及许多技术问题，诸如分析方法、设计方法、形式说明方法、版本控制等，更重要的是必须有严格而科学的管理。目前相当多的软件专业人员对软件开发和维护还有不少糊涂观念，忽视软件需求分析的重要性，认为软件开发就是写程序并设法使之运行，轻视软件维护等。在实践过程中或多或少地采用了错误的方法和技术，这可能是使软件问题发展成软件危机的主要原因。一个软件从定义、开发、使用和维护，直到最终被废弃，要经历一个漫长的时期，这就如同一个人要经过胎儿、儿童、青年、中年、老年，直到最终死亡的漫长时期一样。通常把软件经历的这个漫长的时期称为生命周期。8

严重的问题是，在软件开发的不同阶段进行修改需要付出的代价是很不相同的。根据美国一些软件公司的统计资料，在后期引入一个变动比在早相期引入同变动所需付出的代价高2--3个数量级。图1．2是美国贝尔实验室统计得出的定量结果。统计数据表明，实际上用于软件维护的费用占软件总费用的55％--70％。软件工程学的一个重要目标就是提高软件的可维护性，减少软件维护的代价。

图1.2改正一个问题的代价(越早代价越小)9引入同一变动付出的代价随时间变化的趋势101．1．3解决软件危机的途径1983年IEEE定义--软件：计算机程序、方法、规则、相关的文档资料以及在计算机上运行程序时所必需的数据。定义中列出了软件的5个配置成分。

软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。解决软件危机，既要有技术措施(方法和工具)，又要有必要的组织管理措施。软件工程=管理+技术蓬勃发展学科11softwarecrisis

Themajorcauseofthesoftwarecrisisisthatthemachineshavebecomeseveralordersofmagnitudemorepowerful!

Toputitquitebluntly:

aslongastherewerenomachines,programmingwasnoproblematall;whenwehad

afewweakcomputers,programmingbecame

amildproblem,andnowwehave

gigantic

computers,programminghasbecomeanequally

giganticproblem."

EdsgerDijkstra:TheHumbleProgrammer

12Howexpensive!--Astaggering31.1%ofprojectswillbecanceledbeforetheyevergetcompleted.--Furtherresultsindicate52.7%ofprojectswillcost189%oftheiroriginalestimates.·--InUSA,morethan$250billioneachyearfor175,000projects.--31%arecancelled,53%arechallenged,16%successful.--Theaveragecostofaprojectforalargecompanyis$2,322,000;--Foramediumcompany,itis$1,331,000;--Forasmallcompany,itis$434,00013projectstypes:

TheStandishGroupclassifiesprojectsintothreeresolutiontypes:

·Successful:Theprojectiscompletedontimeandonbudget,withallfeaturesandfunctionsasoriginallyspecified.·Challenged:Theprojectiscompletedandoperational,butoverbudget,overthetimeestimated,andwithfewerfeaturesandfunctionsthaninitiallyspecified.

·Failed:Theprojectiscancelledbeforecompletion.14NASANASA,forexample,carriedoutaprojecttodevelop"perfect"software,softwarethatisclosetoerror-free.Itsucceeded,atacostof$1,000perlineofprogramcode.Thecostforacommercialorganizationistypicallybetween$20and$50perline.NASAreportedthatitfoundnohigh-techtoolsornewtechniquesthatensuredthelevelofqualityitsought;itsapproachwasthetriedandtrue"inspect,test,retest."PeterKeen-ManagingtheEconomicsofInformationCapital

151.2软件工程1.2.1软件工程简介 软件工程是工程学科。1968年第一届NATO会议定义: 软件工程：采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，这就是软件工程。161993年IEEE进一步给出了一个更全面更具体的定义：“软件工程是：①把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件；②研究①中提到的途径。”17软件工程的本质特性:1.软件工程关注于大型程序的构造“大”与“小”的分界线不十分清晰小型程序大型程序传统的程序设计技术和工具支持小型程序设计，不能简单地用于开发大型程序。大粒度软件复用技术，软件架构，组件复用等。182.软件工程的中心课题是控制复杂性软件所解决的问题十分复杂，没有办法作为一个整体通盘考虑。不得不分解，分解出的每个部分可理解，且保持简单通信关系。不能降低问题的整体复杂性，但是却可使它变成可以管理。注意，许多软件的复杂性主要不是由问题的内在复杂性造成的，而是由必须处理的大量细节造成的。193.软件经常变化软件必须随着所模拟的现实世界一起变化。投产软件仍然需要耗费成本。在开发过程中必须考虑将来可能的变化。4.开发软件的效率非常重要软件供不应求的现象日益严重。寻求开发与维护软件的更好更有效的方法和工具。205.和谐地合作是开发软件的关键软件庞大，必须多人合作。有效：明确责任，相互沟通。严格按规定行事。运用标准和规程。用工具来支持标准和规程。纪律关键！6.软件必须有效地支持它的用户目的：是有效地协助用户完成其工作。用户不满意，弃用系统，或立即提新需求。仅用正确方法不够，还必须构造出正确系统。217.在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人工作软件工程师是诸如Java程序设计等方面专家，他们不是图书馆管理、航空控制或银行事务等领域的专家，他们却不得不为这些领域开发应用系统。缺乏应用领域的相关知识，是软件开发项目出现问题的常见原因。22访谈、阅读，了解应用领域知识。然后用软件实现。决定软件系统成功与否的关键问题：用户组织是否真正遵守这个工作流程。对于局外人来说，这个问题更难回答。23

1．2．2软件工程的基本原理1968年在联邦德国召开的国际会议上正式提出井使用了“软件工程”以来，陆续提出了100多条关于软件工程的准则或“信条”。著名的软件工程专家N．W．Boehm综合各种意见和多方软件开发经验，于1983年在一篇论文中提出了软件工程的七条基本原理。他认为这七条原理是确保软件产品质量和开发效率的原理的最小集合。24软件工程的七条基本原理：1、用分阶段的生命周期计划严格管理。不成功项目中有一半左右是由于计划不周造成的。制定并严格执行六类计划：项目概要计划，里程碑计划，项目控制计划，产品控制计划，验证计划，运行维护计划。必须严格按照计划各尽其职。绝不能受客户或上级人员的影响而擅自背离预定计划。252．坚持进行阶段评审两个理由：第一，大部分错误是在编码之前造成的。Boehm等人的统计，设计错误占软件错误的63％，编码错误仅占37％；第二，错误发现与改正得越晚，所需付出的代价也越高。

263．实行严格的产品控制不应随意改变需求。改变要付出较高的代价，必须实行严格的产品控制。一切有关修改软件的建议，都必须按照严格的规程进行评审，获得批准以后才能实施修改。绝对不能谁想修改软件(包括尚在开发过程中的软件)，就随意进行修改。4．采用现代程序设计技术275．结果应能清楚地审查规定责任和产品标准，结果能够清楚地审查。6．开发小组的人员应该少而精组成少而精的开发小组是软件工程的一条基本原理。7．承认不断改进软件工程实践的必要性采纳新技术，总结新经验。28

这七条原理是互相独立的，其中任意六条原理的组合都不能代替另一条原理。缺一不可。相当完备。虽然不能用数学方法严格证明，但是，七条原理的组合可以蕴含或派生出那100多条原理。29软件工程：技术和管理，二者结合的工程学科。管理：通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。通常把在软件生命周期全过程中使用的一整套技术方法的集合称为：方法学(methodology)，也称为范型(paradigm)。两个属于基本相同。1.2.3软件工程方法学30软件工程方法学包含3个要素：方法、工具和过程。其中：方法:完成各项任务的技术方法，回答“怎样做”的问题；工具:为运用方法而提供的自动的或半自动的支撑环境；过程:为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。常用：传统方法学和面向对象方法学。311.传统方法学传统方法学也称为生命周期方法学或结构化范型。它采用结构化技术(结构化分析SA、结构化设计SD和结构化实现SP)来完成软件开发的各项任务，并使用适当的软件工具或软件工程环境来支持结构化技术的运用。依次划分为若干个阶段，顺序地完成。322.面向对象方法学概括地说，该方法学具有下述4个要点：(1)对象(object):任何感性趣的事物。如小轿车、电影、一节课等。(2)类(class):相同属性对象的集合。客车类小轿车大客车中型客车33(3)类等级:按照父类(或称为基类)与子类(或称为派生类)的关系，把若干个相关类组成一个层次结构的系统。

(4)消息联系:对象彼此间仅能通过发送消息互相联系。34面向对象方法学出发点和基本原则:尽量模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界解决问题的方法与过程，从而使描述问题的问题空间(也称为问题域)与实现解法的解空间(也称为求解域)在结构上尽可能一致。351．3软件生命周期软件生命周期：定义期、开发期、维护期淘汰！！生命周期方法学：从时间角度把软件生命的漫长周期依次划分为若干个阶段，每个阶段的任务相对独立；在每个阶段结束之前都从技术和管理两个角度进行严格的审查，合格之后才开始下一阶段的工作。361.3.1生命周期各阶段的基本任务软件生命周期阶段划分的基本原则：使各阶段的任务彼此间尽可能相对独立，同一阶段各项任务的性质尽可能相同，降低复杂程度，简化联系，便于组织管理。软件生命周期:软件定义期、软件开发期和软件维护期。每个时期又进一步划分成若干个阶段。37软件定义期(系统分析):确定软件开发工程必须完成的总目标；确定工程的可行性；导出实现工程目标应该采用的策略及系统必须完成的功能；估计完成该项工程需要的资源和成本，并且制定工程进度表。定义期三个阶段:问题定义、可行性研究和需求分析。38开发时期：总体设计，详细设计，编码和单元测试，综合测试。其中前两个阶段又称为系统设计，后两个阶段又称为系统实现。维护时期：主要任务是使软件持久地满足用户的需要。具体说：改正错误；适应新的环境；满足新的需要.39如果记软件开发全部工作量为100%，那么测试工作量通常占全部工作量的40％--50％。编写程序工作量只占全部工作量的l0％--20％。

401．问题定义:要解决的问题是什么?2．可行性研究：对确定的问题有可行的解决办法吗?或者说条件具备吗？3．需求分析:确定目标系统必须具备哪些功能和性能。4．总体设计：“概括地说，应该如何解决这个问题?”软件生命周期方法学简述415．详细设计：“应该怎样具体地实现这个系统呢?”6．编码和单元测试:写出正确的容易理解、容易维护的程序模块。7．综合测试:关键任务是通过各种类型的测试(及相应的调试)使软件达到预定的要求。8．软件维护:关键任务是通过各种必要的维护活动使系统持久地满足用户的需要。421.4软件过程软件过程：为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。ISO9000把过程定义为:“使用资源将输入转化为输出的活动所构成的系统。”43过程定义了运用方法的顺序、应该交付的文档资料、为保证软件质量和协调变化所需要采取的管理措施，以及标志软件开发各个阶段任务完成的里程碑。精品求于过程!一个任务集合包括一组软件工程任务、里程碑和应该交付的产品。生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序，也称为过程模型。44在20世纪80年代之前，瀑布模型一直是唯一被广泛采用的生命周期模型，现在它仍然是应用得最广泛的过程模型。传统软件工程方法学的软件过程，基本上可以用瀑布模型来描述。1.4.1瀑布模型45图1.2传统的瀑布模型46三个特点：特点1.阶段间具有顺序性和依赖性两重含义：①前一阶段工作完成后，才能开始后一阶段工作；②前一阶段的输出文档是后一阶段的输入文档.

特点2.推迟实现的观点规模较大项目，编码越早，完成的时间越长。不扎实，过早考虑程序实现，大量返工，无法弥补，带来灾难。47瀑布模型在分析与设计阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要的指导思想。特点3.质量保证的观点软件工程的基本目标是优质、高产。48在每个阶段都应坚持两个重要做法：（1）每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。里程碑?!（2）每个阶段结束前都要对所完成的文档进行评审.尽早发现问题，改正错误。越是早期阶段犯下的错误，暴露出来的时间就越晚，排除故障改正错误所需付出的代价也越高。及时审查！

49图1.3实际的瀑布模型50优点：可强迫开发人员采用规范的方法（例如，结构化技术）；严格地规定了每个阶段必须提交的文档；交出的所有产品都必须经过质量保证小组的仔细验证;文档约束，将使维护变得比较容易;瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型。51“文档驱动”也是瀑布模型的一个主要缺点。在产品提交前，用户只能通过文档来了解产品。静态的规格说明，与动态表现很难统一。用户用软件前后想法可能会不一致。要求用户不经过实践提出完整准确需求，不切实际。完全依赖于规格说明，有可能导致最终产品不能真正满足用户的需要。52Vmodelrequirementsanalysissystemdesignprogramdesigncodingunit&inte-grationtestingsystemtestingoperation&maintenanceacceptancetestingavariationofthewaterfallmodelverifydesign531.4.2快速原型模型快速建立运行程序；功能子集试用了解目标系统的概貌。建立、试用、修改，反复到满意；线性、不带反馈环54

快速原型的本质是“快速”。应该尽可能快地建造出原型系统，以加速开发过程，节约成本。

原型的用途是获知用户的真正需求，一旦需求确定了，原型将被抛弃。重要的是，必须迅速地构建原型和修改原型。UNIXShell和超文本第四代语言（4GL）构建快速原型。METLAB等。55增量模型也称为渐增模型。把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。1.4.3增量模型构件规模适中。最佳分解方法因软件产品特点和开发人员的习惯而异。56分解成增量构件约束条件：当把新构件集成到现有软件中时，所形成的