1 软件危机与软件工程

1SoftwareEngineering张小洪Dr.Zhang，Xiaohong2006,FallSchoolofSoftwareEngineering,ChongqingUniversity2个人信息张小洪Email:[e-mail]TEL：[phone]（小灵通）办公地点：重庆大学A区主楼1003室研究方向：软件工程、机器视觉与数据挖掘等3软件工程的主要内容软件工程概述过程模型需求分析与分析建模软件设计原则软件体系结构设计软件测试软件维护可行性分析面向对象分析与设计4参考教材软件工程-实践者的研究方法（英文版第五版）RogerS.Pressman机械工业出版社5教材软件工程导论（第三版）张海藩清华大学出版社（1997）6第1讲软件危机与软件工程7内容提要软件的特点软件的分类软件工程产生的背景：软件危机与神话软件工程的概念软件工程现状计算机软件已经成为一种驱动力。它是进行商业决策的引擎；它是现代科学研究和工程问题寻求解答的基础；它也是鉴别现代产品和服务的关键因素。它被嵌入在各种类型的系统中：交通、医疗、电信、军事、工业生产过程、娱乐、办公、……难以穷举。软件在现代社会中确实是必不可少的。而且我们进入21世纪，软件将成为从基础教育到基因工程的所有领域新进展的驱动器。9什么是软件软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合程序是按事先设计的功能和性能要求执行的指令序列数据是使程序能正常操纵信息的数据结构文档是与程序开发，维护和使用有关的图文材料10软件的特点软件是一种逻辑实体，而不是具体的物理实体。因而它具有抽象性软件的生产与硬件不同，在它的开发过程中没有明显的制造过程在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题1112软件的特点软件的开发和运行常受到计算机系统的限制，对计算机系统有着不同程度的依赖性软件的开发至今尚未完全摆脱手工艺的开发方式软件本身是复杂的实际问题的复杂性程序逻辑结构的复杂性软件成本相当昂贵相当多的软件工作涉及到社会因素1314软件的分类按软件的功能进行划分：系统软件使计算机系统各个部件、相关软件和数据协调、高效地工作的软件操作系统数据库管理系统设备驱动程序通信处理程序等15软件的分类支撑软件协助用户开发软件的工具软件文本编辑程序文件格式化程序磁盘向磁带进行数据传输的程序程序库系统支持需求分析、设计、实现、测试和支持管理的软件16软件的分类应用软件商业数据处理软件工程与科学计算软件计算机辅助设计／制造软件系统仿真软件智能产品嵌入软件医疗、制药软件事务管理、办公自动化软件计算机辅助教学软件17软件的分类按软件规模进行划分：类别参加人员数研制期限源程序行数微型11～4周0.5k小型11～6月1k～2k数值计算或数据处理,通常没有与其它程序的接口。需要按一定的标准化技术、正规的资料书写以及定期的系统审查。只是没有大题目那样严格。中型2～51～2年5k～50k软件人员之间、与用户之间的联系、协调的配合关系。因而计划、资料书写以及技术审查需要比较严格地进行。应用程序和系统程序。系统的软件工程方法是完全必要的。18软件的分类•大型5～202～3年50k～100k•编译程序、小型分时系统、实时控制系统等。二级管理，若干小组，每组5人以下。人员调整往往不可避免，新手的培训。采用统一的标准，实行严格的审查是绝对必要的。•甚大型100～10004～5年1M(=1000k)•若干个子项目，每一个子项目都是一个大型软件。子项目之间具有复杂的接口。如远程通信系统、多任务系统、大型操作系统、大型数据库管理系统、军事指挥系统通常现有这样的规模。很显然，这类问题没有软件工程方法的支持，它的开发工作是不可想象的。•极大型2000～50005～10年1M～10M•军事指挥、弹道导弹防御系统。•只是对软件工程技术依赖的程度不同而已。19软件的分类按软件工作方式划分：实时处理软件交互式软件批处理软件分时软件20软件的分类按软件服务对象的范围划分：项目软件产品软件21软件的分类按使用的频度进行划分：一次使用频繁使用22软件的分类按软件失效的影响进行划分：高可靠性软件一般可靠性软件23软件的发展Late1950’s:Intheearlydays:“Software”=“Placeasequenceofinstructionstogethertogetthecomputertodosomethinguseful”.UserComputerComputerbecamecheaperandmorecommonHighlevellanguageswereinventedProgrammerUserComputereasier24软件的发展Early1960s:Veryfewlargesoftwareprojectsweredonebysomeexperts.Middletolate1960s:Trulylargesoftwaresystemswereattempted.After1968:SoftwareEngineering25软件的角色软件在社会上扮演了双重角色它本身是一种产品将计算机硬件的计算能力发挥出来同时，它也是一种传递产品的工具软件传递了我们这个时代最重要的产品：信息26计算机和软件的历史观70年代和80年代“新的工业革命”“工业社会将转变为信息社会”……（大批量生产带来的产品过剩）90年代“知识的民主化将改变旧的权力结构”21世纪“无所不在的信息”27软件危机•美国IBM公司在1963年至1966年开发的IBM360机的操作系统。这一项目花了5000人一年的工作量，最多时有1000人投入开发工作，写出了近100万行源程序。......据统计，这个操作系统每次发行的新版本都是从前一版本中找出1000个程序错误而修正的结果。......这个项目的负责人F.D.Brooks事后总结了他在组织开发过程中的沉痛教训时说：“......正像一只逃亡的野兽落到泥潭中做垂死的挣扎，越是挣扎，陷得越深，最后无法逃脱灭顶的灾难。......程序设计工作正像这样一个泥潭，......一批批程序员被迫在泥潭中拼命挣扎，......谁也没有料到问题竟会陷入这样的困境......”。IBM360操作系统的历史教训成为软件开发项目的典型事例为人们所记取。SoftwareCrisis!28软件危机⑴项目没有被很好地理解；计划不周，最终导致进度拖延。例在20世纪60年代后期，一位热情的年青工程师受命为一个自动化制造应用项目“编写”计算机程序。选择他的理由非常简单，因为在整个技术小组中他是唯一参加过计算机编程培训的人。这位工程师对汇编语言的IN和OUT指令以及Fortran语言有所了解，但是却根本不懂软件工程，更不要说项目进度安排和跟踪了。他的老板给了他一大堆相关的手册，以及需要做些什么的口头描述。年轻人被告知该项目必须在两个月之内完成。他阅读了这些手册，想好了解决方法，就开始编写代码。两周后，老板将他叫到办公室询问项目进展情况。问题出在哪里？29软件危机“非常好”工程师以年轻人的热情回答道，“这个项目远比我想像的简单。我差不多已经完成了75%的任务。老板笑了，说道：“真是太棒了”然后他嘱咐年轻人继续努力工作，准备好一周后再汇报一次工作进度。一周后老板将年轻人叫到办公室，问他说：“现在进度如何？”“一切顺利”年轻人回答说，“但是我遇到了一些小麻烦。我会排除这些困难，很快就可以回到正轨上来。”“你觉得在最后期限之前能否完成？”老板问道。“没有问题”工程师答道。“我差不多已经完成了90%”如果读者在软件领域中工作过几年，你一定可以将这个故事写完。毫不奇怪，年轻工程师在整个项目工期内始终停留在90%的进度上，（在别人的帮助下）直到交付期限之后一个月才做完30软件危机⑵没有充分的文档资料(documentation)人与人的交流比写程序困难得多。Managers——evaluate,trackprogress,......Programmers——communicatetoeachotherMaintainers——31软件危机⑶软件可靠性(reliability)缺少度量的标准，质量无法保证。如何保证软件产品的质量，是非常复杂困难的问题。特别对于规模庞大的软件，如：.ThesoftwaresupportingtheAmericanspaceshuttleconsistsof3millionlinesofcode,includingcomputersonthegroundcontrollingthelaunchandtheflight;therewereonehundredthousandlinesofcodeintheshuttleitselfin1985.PresidentReagan’sproposedStrategicDefenseInitiative(SDI)isestimatedtorequire10to100millionlinesofcode.Manycomputerscientistsandsoftwareengineerscontinuetobelievethereisnowaytowriteandtestthesoftwaretoguaranteeadequatereliability.32软件危机⑷软件难以维护(maintainability)不易升级(evolvability)33软件神话－管理神话负责软件的管理者像大多数其他行业的管理者一样，都有巨大的压力，要维持预算、保持进度，还要提高质量。就像溺水者抓住一根救命稻草，软件管理者常常抓住软件神话不放，这些神话能够缓解其压力的话（哪怕是暂时的）。神话1：我们已经有了关于建造软件的标准和规程的书籍，难道它们不能给人们提供所有它们需要知道的信息吗？现实：不错，关于标准的书籍已经存在，但真正使用它们了吗？软件实践者知道它们的存在吗？它们是否反映了现代软件工程实践？它们完备吗？它们对在保持关注质量的情况下改善交付时间是简便有效的吗？很多情况下，这些问题的答案是否定的。34软件神话－管理神话神话2：我们已经有了很多很好的软件开发工具，而且，我们为它们最新的的计算机。现实：计算机辅助软件工程（CASE）工具与硬件相对而言对于获得高质量和高生产率更为重要。神话3：如果我们已经落后于计划，可以增加更多的程序员赶上进度。现实：给一个已经延迟的软件项目增加人手只会使其更加延迟。神话4：如果我决定向第三方外包软件项目，我可以放松并让承包公司去建造它。现实：如果一个机构不了解如何在内部管理和控制软件项目，当它外包软件项目时将总是处于挣扎的境地。35软件神话－客户神话在许多情况下，客户相信关于软件的神话，因为负责软件开发的管理者和开发人员很少去纠正客户的错误理解。导致客户过高的期望值，并最终引起对开发人员的不满意。神话1：有了对目标的一般性描述就足以开始写程序了，我们可以以后再补充细节。现实：糟糕的系统定义是软件项目失败的主要原因。关于信息领域、功能、行为、性能、接口、设计约束及确认标准的形式化的、详细的描述是必要的。这些内容只有通过客户和开发者之间彻底地交流后才能确定。神话2：软件需求确实是经常变更的，但这些变更能够很容易地满足，因为软件是灵活的。现实：软件需求确实是变更的，但这些变更产生的影响会随着其被引入的时间而不同的。36软件神话－实践者神话在软件的早期阶段，程序设计被看成是一门艺术。神话1：一旦我们写出了程序并使其正常运行，我们的工作就结束了。现实：越早开始写代码，就要花越长的时间才能完成它。研究表明在一鼐软件上所投入的60%到80%的工作量是花费在软件第一次交付客户之后。神话2：在程序真正运行之前，没有办法