Download
1 / 79
790 likes | 935 Views
软件工程. 三个问题. 你会写程序吗？ 你会开发软件吗？ 你的未来是程序员？还是 IT 的管理人员？ 写程序 开发软件 要会开发软件，你必须了解 软件工程的知识. 主要内容. 软件工程学基本知识（第 1 章） 软件开发过程及其技术（第 1 章 ~ 第 8 章） 面向对象方法（第 9 章 ~ 第 12 章） 软件项目管理（第 13 章）. 第 1 章 软件工程. 1.1 软件危机 1.2 软件工程 1.3 软件生命周期 1.4 软件过程. 1.1 软件危机. 计算机系统的发展历程
E N D
三个问题 • 你会写程序吗？ • 你会开发软件吗？ • 你的未来是程序员？还是IT的管理人员？ • 写程序开发软件 • 要会开发软件，你必须了解 • 软件工程的知识
主要内容 • 软件工程学基本知识（第1章） • 软件开发过程及其技术（第1章~第8章） • 面向对象方法（第9章~第12章） • 软件项目管理（第13章）
第1章 软件工程 • 1.1 软件危机 • 1.2 软件工程 • 1.3 软件生命周期 • 1.4 软件过程
1.1 软件危机 • 计算机系统的发展历程 • 所谓计算机系统就是指适当地组织在一起的一系列系统元素的集合，这些系统元素互相配合、相互协作，通过对信息的处理而完成预先定义的目标。 • 迄今为止，计算机系统已经经历了四个不同的发展阶段。
60年代中期以前，是计算机系统发展的早期时代。 • 从60年代中期到70年代中期，是计算机系统发展的第二代。 • 计算机系统发展的第三代从20世纪70年代中期开始，并且跨越了整整10年。 • 在计算机系统发展的第四代已经不再看重单台计算机和程序，人们感受到的是硬件和软件的综合效果。
软件的分类: • 按软件的功能进行划分： • (1)系统软件:使计算机系统各个部件、相关软件和数据协调、高效地工作的软件 • 操作系统 • 数据库管理系统 • 设备驱动程序 • 通信处理程序等
(2)支撑软件:协助用户开发软件的工具软件 • 文本编辑程序 • 文件格式化程序 • 磁盘向磁带进行数据传输的程序 • 程序库系统 • 支持需求分析、设计、实现、测试和支持管理的软件
(3)应用软件 • 商业数据处理软件 • 工程与科学计算软件 • 计算机辅助设计／制造软件 • 系统仿真软件 • 智能产品嵌入软件 • 医疗、制药软件 • 事务管理、办公自动化软件 • 计算机辅助教学软件
按软件规模进行划分： • 类别 参加人员数 研制期限 源程序行数 • 微型 1 1～4周 0.5k • 小型1 1～6月 1k～2k • 数值计算或数据处理,通常没有与其它程序的接口。需要按一定的标准化技术、正规的资料书写以及定期的系统审查。只是没有大题目那样严格。 • 中型2～5 1～2年 5k～50k • 软件人员之间、与用户之间的联系、协调的配合关系。因而计划、资料书写以及技术审查需要比较严格地进行。应用程序和系统程序。系统的软件工程方法是完全必要的。
大型5～20 2～3年 50k～100k 编译程序、小型分时系统、实时控制系统等。二级管理，若干小组，每组5人以下。人员调整往往不可避免，新手的培训。采用统一的标准，实行严格的审查是绝对必要的。 甚大型100～1000 4～5年 1M(=1000k) 若干个子项目，每一个子项目都是一个大型软件。子项目之间具有复杂的接口。如远程通信系统、多任务系统、大型操作系统、大型数据库管理系统、军事指挥系统通常现有这样的规模。很显然，这类问题没有软件工程方法的支持，它的开发工作是不可想象的。 极大型2000～5000 5～10年 1M～10M 军事指挥、弹道导弹防御系统。 只是对软件工程技术依赖的程度不同而已。
按软件工作方式划分： • 实时处理软件 • 交互式软件 • 批处理软件
按软件服务对象的范围划分： • 项目软件 • 产品软件
软件失效的影响进行划分： • 高可靠性软件 • 一般可靠性软件
按使用的频度进行划分： • 一次使用 • 频繁使用
1.1.1 软件危机的含义 • “软件危机” 是1958年在NATO会议上作为一个正式的议题被提出来 • 软件项目不成功的例子比比即是： • 案例1:1999 年 10 月，耗资 1.25 亿美元的 NASA 的火星气象卫星失踪，据信这是由于简单的数据转换错误所导致的。人们发现卫星软件中，有些数据使用英制，它们应被转换成公制。这个卫星应当充当另一项任务中的火星极地着陆项目的通信转发器，那个任务也失败了，原因不明。
案例2: 美国IBM公司在1963年至1966年开发的IBM360机的操作系统。这一项目花了5000人一年的工作量，最多时有1000人投入开发工作，写出了近100万行源程序。......据统计，这个操作系统每次发行的新版本都是从前一版本中找出1000个程序错误而修正的结果。...... • 这个项目的负责人F. D. Brooks(人月神话，一代软件工程大师)事后总结了他在组织开发过程中的沉痛教训时说：“......正像一只逃亡的野兽落到泥潭中做垂死的挣扎，越是挣扎，陷得越深，最后无法逃脱灭顶的灾难。......程序设计工作正像这样一个泥潭，......一批批程序员被迫在泥潭中拼命挣扎，......谁也没有料到问题竟会陷入这样的困境......”。IBM360操作系统的历史教训成为软件开发项目的典型事例为人们所记取。
案例3:项目没有被很好地理解；计划不周，最终导致进度拖延。案例3:项目没有被很好地理解；计划不周，最终导致进度拖延。 • 一天，一位年青人被选来“写”一个用在自动化制造设备上的程序。选择他的理由很简单：他是技术小组中唯一参加过编程培训的人。他懂得汇编语言和Fortran语言，但是他不知道软件工程，更不知道软件计划和跟踪方面的知识。
他的老板给了他一些手册和对系统功能的口头描述。他被告知系统必须在两个月内开发完成。他读了手册，考虑了他的方法，然后开始编程，两个星期后，老板把他叫到了办公室并问他事情干得怎么样？ • “很好”， 雄心勃勃的年青的工程师说，“比我想像的要简单的多。我已经接近完成75％了。” 老板笑了，“真不可思议”， 然后他告诉这个年青人继续好好干，在下个星期他将再次会见他。
一个星期后，老板把年青人叫到了办公室，问“我们的进展如何？”一个星期后，老板把年青人叫到了办公室，问“我们的进展如何？” • “很顺利”，年青人说“但是我遇到了一些小难题，我将解决它们并且很快就能保持进度” • “那么，最终日期能保证吗？”老板问。 • “没问题,” 工程师说，“我已经快完成90％了。” • 如果你在软件界工作了几年，你可以完成这个故事。毫不惊奇，年青人在项目的90％处停滞不前，直到在别人的帮助下在一个月后完成了项目。
案例4:1999 年 8 月，在一个大型的商业高速数据网络里，软件的缺陷影响了 70000 个商业用户，时间长达八天。在受到影响的客户中，有美国最大的远期交易电子贸易系统，该系统中断服务长达一周 • 案例5: 1998 年 4 月，美国的一个重要的数据通讯网络出现了长达 24 小时的故障，使大部分美国的信用卡管理系统交易受到影响。受到影响的还一些大银行、零售商、和政府的数据系统。最后查出也是软件故障所致。
案例6:据报道，1997 年 8 月，美国一家最主要的消费信用卡报告公司的新网站刚开启两天，就因为软件问题而关闭了。这个新站点允许浏览者直接访问，只收取很少的费用就可以查询自己的信用卡使用情况。但是，最初的用户所看到的是别人的账单，而不是他们自己的。发怒的顾客使这件事流传全国。最后问题被归结为：“ … 未曾预料到的大量的客户需求，再加上导致把文件送到错误的计算机的软件毛病。”
一些数据： • 大约70％的软件开发项目超出了估算的时间，大型项目平均超出计划交付时间20％到50％，90％以上的软件项目开发费用超出预算，并且项目越大，超出项目计划的程度越高 • 美国政府审计局：只有不到2％的合同定购软件在发布时具有可用性——98％以上的项目都失败了
相关术语 • “两难境地（Crunch Mode）”：处于两难境地的项目面临着无法达到最初目标的威胁（费用、进度表、功能性等等），而项目团队在努力想要跨越该困境。 • “我们正处于两难境地，在半夜之前是不会回家的” • “死亡行军（Death March）”：用来描述其进度表几乎不可能完成的项目。 • “这是一个死亡行军项目，我希望自己不要参与进去”
更准确的说法：慢性痛苦（chronic affliction) Suggested by Prof. Daniel Tiechrow, University of Michigan • 尽管忍受痛苦，但是软件依然在我们这个世界起着越来越重要的作用，但是如果能够医治痛苦，那么软件业将发展得更加健康。 • 如何医治这种软件业的慢性痛苦？
软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这些问题绝不仅仅是不能正常运行的软件才具有的，实际上，几乎所有软件都不同程度地存在这些问题。软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这些问题绝不仅仅是不能正常运行的软件才具有的，实际上，几乎所有软件都不同程度地存在这些问题。
具体来说，软件危机主要有以下一些典型表现：具体来说，软件危机主要有以下一些典型表现： • · 对软件开发成本和进度的估计常常很不准确。实际成本地估计成本有可能高出一个数量级，实际进度比预期进度拖延几个月甚至几年的现象并不罕见 • · 用户对“已完成的”软件系统不满意的现象经常发生。软件开发人员通常在对用户要求只有模糊的了解，甚至对于所要解决的问题 还没有确切认识的情况下，就仓促上阵忙着着手编写程序；并且开发人员和用户之间的信息交流往往很不充分，“闭门造车”必然导致最终产品不符合用户的要求。
· 软件产品的质量往往靠不住。软件质量保证技术还没有坚持不懈地应用到软件开发的全过程中； • · 软件常常是不可维护的。 • · 软件通常没有适当的文档资料。（软件通常没有适当的文档资料。计算机软件不仅仅是程序，还应该包括一整套的文档资料。这些文档资料应该是在软件开发过程中产生的，并且应该是“最新式”的（即和程序代码完全一致）。软件管理人员可以使用这些文档资料作为“里程碑”来管理和评价软件开发工程的进展状况；软件开发人员可以利用它们作为通信工具，在软件开发过程中准确地交流信息；对于软件维护人员，这些文档资料更是至关重要。因此，缺乏必要的文档或者文档资料不合格，必然给软件的开发和维护带来许多严重的困难和问题。） • · 软件成本在计算机系统总成本中所占的比例逐年上升。由于微电子学技术的进步和生产自动化程度的不断提高，硬件成本逐年下降，然而软件开发所需要的大量的人力，随着软件规模的不断扩大而持续上升。美国在1985年软件成倍大约已占计算机系统总成本的90%。
· 软件开发生产率提高的速度，既跟不上硬件的发展速度，也远远跟不上计算机应用迅速普及深入的趋势。 • 以上列举的仅仅是软件危机的一些明显的表现，与软件开发和维护有关的问题远远不止这些。
1.1.2 产生软件危机的原因 • 在软件开发和维护的过程中存在这么多严重问题，一方面与软件本身的特点有关，另一方面也和软件开发与维护的方法不正确有关。 • 软件本身的特点： • 。缺乏可见性：在写出程序代码并在计算机上试运行之前，软件开发过程的进展情况较难衡量，软件的质量也较难评价。 • 。软件在运行过程中不会因为使用时间过长而被“用坏”，如果运行中发现错误，很可能是遇到了一个在开发时期引入而在测试阶段没有检查出来的错误。因此，软件的维护通常意味着修改原来的设计，这就在客观上使得软件较难维护。
。软件另一个特点是规模庞大，而且程序的复杂性将随着程序规模的增加而呈指数上升 。为了在预定时间内完成庞大的软件，必须由许多人分工协作。然而，如何保证每个人完成的工作合在一起确实能构成一个高质量的大型软件系统，是一个极端复杂的问题，不仅仅涉及到许多技术问题，诸如分析方法、设计方法、版本控制等，更重要的是必须有严格而科学的管理
软件本身的特点确实给开发和维护工作带来了一些客观的难度，但是还有很多问题是与软件开发和维护有关的许多错误认识和作法的形成。这种错误的认识可以归因于在计算机系统发展的早期阶段软件开发的个体化特点。错误的认识和作法主要表现为：软件本身的特点确实给开发和维护工作带来了一些客观的难度，但是还有很多问题是与软件开发和维护有关的许多错误认识和作法的形成。这种错误的认识可以归因于在计算机系统发展的早期阶段软件开发的个体化特点。错误的认识和作法主要表现为： • 。忽视软件需求分析的重要性，认为软件开发就是写程序并设法使之运行。对用户的要求没有完整准确的认识就开始编程序是许多软件项目失败的主要原因之一。如果软件开发人员在定义时期没有正确全面地理解用户的需求，直到测试阶段或者软件交付阶段才发现，则未时已晚。
图1.1引入同一变动付出的代价随时间变化的趋势图1.1引入同一变动付出的代价随时间变化的趋势 根据美国一些软件公司资料统计，在后期引入一个变动比在早期引入相同的变动所需要付出的代价高2-3个数量级
.轻视软件维护:许多软件的寿命长达10年甚至20年，在这样漫长的时期中不仅必须改正使用过程中发现的每一个潜伏的错误，而且当环境变化时，还必须相应地修改软件以适应新的环境，特别是必须经常改进或扩充原来的软件以满足用户不断变化的需要。所有这些都是维护工作，而且是在软件已经完成之后进行的，因此维护是极端艰巨复杂的工作。统计数据表明，实际上用于软件维护的费用占软件总费用的55%-70%。软件工程学的一个重要的目标就是要提高软件的可维护性，减少软件维护的代价。
.另一方面还必须认识到程序只是完整软件产品的一个组成部分，一个完整的软件产品必须包括：程序、文档、数据等成分。必须清楚只重视程序而忽视软件配置其余成分的糊涂观念
了解产生软件危机的原因，澄清错误认识，建立起关于软件开发和维护的正确概念，还仅仅是解决软件危机的开始，全面解决软件危机需要一系列综合措施。了解产生软件危机的原因，澄清错误认识，建立起关于软件开发和维护的正确概念，还仅仅是解决软件危机的开始，全面解决软件危机需要一系列综合措施。
1.1.3 消除软件危机的途径 • 为了消除软件危机，首先应该对计算机软件有一个正确的认识 • 更重要的是，必须充分认识到软件开发不是某个个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。应该推广使用在实践中总结出来的开发软件的成功的技术和方法，并且研究探索更好更有效的技术和方法，尽快消除在计算机系统早期发展阶段形成的一些错误概念和做法。 • 应该开发和使用更好的软件工具。 • 总之，为了消除软件危机，既要有技术措施(方法和工具)，又要有必要的组织管理措施。软件工程正是从管理和技术两方面研究如何更好地开发和维护计算机软件的一门新兴学科。
1.2 软件工程 • 1.2.1 什么是软件工程 • 概括地说，软件工程是指导计算机软件开发和维护的工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。
1.2.2软件工程的基本原理 • 1、用分阶段的生命周期计划严格管理 • 有人经统计发现，在不成功的软件项目中有一半左右是由于计划不周造成的。可见把建立完善的计划作为第1条基本原理是吸取了前人的教训而提出来的。 • 这条原理意味着应该把软件生命周期分为若干阶段，并相应的制定出切实可行的计划，然后严格按照计划对软件的开发和维护工作进行管理
2、坚持进行阶段评审 • 软件的质量保证工作不能等到编码阶段结束之后才进行。原因： • 第一：大部分的错误是在编码之前造成的 • 第二：错误发现的越晚，所需付出的代价也越高。 • 因此，每个阶段都要进行严格的评审，以便尽早发现软件开发过程中的问题。
3、实行严格的产品控制 • .由于外部环境的变化，相应的改变用户需求是一种客观需要，显然不能硬性禁止客户提出改变需求的要求，而只能依靠科学的产品控制技术来顺应这种要求。 • .产品控制主要是实行基准配置管理，基准配置是经过阶段评审后的软件培植成分，基准配置管理也称为变动控制，一切有关修改软件的建议，特别是涉及到对基准配置的修改建议，都必须按照严格的规程进行评审，获得批准后才能实施修改
4、采用现代程序设计技术 • .面向结构化的程序设计 • .面向对象的程序设计 • 5、结果应能清楚地审查 • 为了提高软件开发过程的可见性，应该根据软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准，从而使得所得到的结果能够清楚地审查。
6、开发小组的人员应该少而精 • 素质高的人员的开发效率比素质低的人员的开发效率可能高几倍甚至几十倍，软件中的错误也明显的少 • 此外，随着开发小组人员树木的增加，因为交流情况讨论问题而造成的通信开销也急剧增加，当开发小组人数为N是，可能的通信路径有N(N-1)/2 • 7、承认不断改进软件工程实践的必要性
1.2.3 软件工程方法学 • 软件工程包括： • 。管理方面：软件项目管理，就是通过计划、组织、控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。我们在第四篇将进行介绍 • 。技术方面：软件工程方法学，通常把在软件生命周期全过程中使用的一整套技术的集合称为方法学(methodology)，也称为范型(paradigm)。在软件工程范畴中，这两个词的含义基本相同。
软件工程方法学包括三个要素，这就是方法、工具和过程。软件工程方法学包括三个要素，这就是方法、工具和过程。 • .方法是完成软件开发的各项任务的技术方法，回答“如何做”的问题； • .过程是为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。 • .工具是为方法的运用提供自动的或半自动的软件支撑环境； • 目前使用得最广泛的软件工程方法学，分别是传统方法学和面向对象方法学。
软件工程的历史: • 起源于20世纪50年代 • 但是从学术的角度看，软件工程还是一个年轻的学科 • 第一次会议在20世纪60年代后期 • 而在80年代才从计算机科学分离开 • Wang Institute and Seattle University established SE graduate programs in the early 1980s • Southern Methodist（卫理教会） University • --define the curriculum topics and content • SEI of Carnegie Mellon University joined the fray
补充： 我国软件业的现状 • 2001年我国软件销售总额96．3亿美元，软件企业约5000家，从业人员29万。 • 2001年印度软件销售总额102．3亿美元，软件企业约6000家，从业人员40万。 • 2001年我国软件的出口额仅为7.2亿美元，2000年与1999年分别为4亿美元及2.5亿美元。 • 印度在软件出口方面，则一直保持高速的增长。1990年印度软件出口只有5000万美元，1999年就达到了39亿美元，2000年达到了62亿美元，而2001年印度软件出口额为77．8亿美元，已经占到了印度全部出口总额的10.5％。
