软件工程课件之第1章

软件工程导论,主讲：何建军,软件工程导论,总学时数：48理论课：40上机课：8考试方式：理论考试+上机成绩+平时成绩,软件工程导论,软件工程导论,课程性质：,软件工程导论是数字媒体技术专业的一门专业基础课程，在数字媒体技术学科人才培养体系中占有重要的地位。,软件工程导论是一门软件开发的指导性理论学科！,软件工程导论,先谈谈“工程：”,十八世纪，欧洲创造了“工程”一词，其本来含义是兵器制造、军事目的的各项劳作，后扩展到许多领域，如建筑屋宇、制造机器、架桥修路等。,“工程”是科学的某种应用。通过这一应用，使自然界的物质和能源的特性能够通过各种结构、机器、产品、系统和过程，是以时间最短的和精而少的人力做出高效、可靠且对人类有用的东西。,随着人类文明的发展，人们可以建造出比单一产品更大、更复杂的产品，这些产品不再是结构或功能单一的东西，而是各种各样的所谓“人造系统”（比如建筑物、轮船、铁路工程、海上工程、飞机等等），于是工程的概念就产生了，并且它逐渐发展为一门独立的学科和技艺。,在现代社会中，“工程”一词有广义和狭义之分。就狭义而言，工程定义为“以某组设想的目标为依据，应用有关的科学知识和技术手段，通过一群人的有组织活动将某个（或某些）现有实体（自然的或人造的）转化为具有预期使用价值的人造产品过程”。就广义而言，工程则定义为由一群人为达到某种目的，在一个较长时间周期内进行协作活动的过程。,软件工程导论,软件正改变世界,软件无时无刻不存在于你的身边，你的家庭、你的身边！,你将永远跳离不脱软件的束缚！,软件正影响你的生活，我们的世界！,1992年，来自明尼苏达州怀俄明的玛丽收到一份幼儿园的入园通知，她当时是104岁。1988年2月29日，一家超市因出售过期一天的肉而被罚款1000美元。因为在肉的标签上打印保质期的计算机程序没有考虑到1988年是闰年。1990年4月10日，在伦敦地铁运营过程中，司机还没上车，地铁列车就驶离车站。当时司机按了启动键，正常情况下如果车门是开着的，系统就应该可以阻止列车起动。当时的问题是司机离开了列车去关一扇卡着的门，但当门终于关上时，列车还没有等到司机上车就开动了。在1995年，由于新丹佛尔国际机场自动行李系统的错误，造成旅客行李箱的损坏。机场则被迫推迟16个月再开放，且大部分采用手工行李系统，产生32亿美元超支。2002年的Swanick空运控制系统，包括英格兰和威尔士全部空运线路。在系统交付时，已延期6年且严重超支（实际花费6.23亿英傍，原计划花费3.5亿英镑）。麦克道尔道格拉斯的C-17货机因为控制系统的软件问题，而超支5亿美元。C-17含有19台机载计算机，80个微处理器以及6种不同的编程语言。,软件工程导论,软件带来的困惑或影响,软件工程导论,1967年8月23日，前苏联的联盟一号宇宙飞船在返回大气层时，突然发生了恶性事故-减速速降落伞无法打开。因一位小数点计算错误而导致飞船在穿过大气层时无法打开降落伞,最终机毁人亡。,挑战者号在1986年1月28日进行代号STS-51-L的第10次太空任务时，在升空后73秒时，爆炸解体坠毁。价值12亿美元的航天飞机，顷刻化为乌有，七名宇航员全部遇难。但据说程序设计上的一个循环语句错误造成,俄罗斯福布斯-土壤号火星探测器，探测器上搭载着中国首颗火星探测器“萤火一号”。2011年11月9日发射升空后一切顺利，与运载火箭成功分离，但此后出现探测器的推进装置没有点火的问题，导致其变轨失败。俄联邦航天署表示这可能是由于保障程序出现代码错误，或者定位系统出现技术故障导致的。2012年1月15日探测器残骸坠落地球。损失50亿卢布。,软件带来的灾难,软件工程导论,你编过软件吗？,对软件的认识：1950：程序1960：程序+文档（不包括管理文档）1970：程序+文档+数据1984：软件管理是过程管理，CMM1.0能力成熟度模型1996：UML统一建模语言（它是运用统一的、标准化的标记和定义实现对软件系统进行面向对象的描述和建模。）,软件工程导论,计算机系统4个不同的发展阶段：,软件工程导论,计算机软件4个不同的发展阶段：,软件工程导论,1.1软件危机1.2软件工程1.3软件生命周期1.4软件过程,第1章软件工程学概述,1.1软件危机,第1章软件工程学概述,软件生产的发展足迹:,1.1.1软件发展-软件危机,第1章软件工程学概述,1、程序设计时代（46年-56年）,个体手工方式；低级语言、编程效率低、难，编程是聪明人的事；追求编程技巧和程序运行效率；代码不规范，不易读，不易维护；只重视编码，不重视设计和文档；硬件资源紧缺；,第1章软件工程学概述,2、程序系统时代（56年-68年）,1.1.1软件发展-软件危机,作坊式小团队开发；出现高级语言，编程效率有所提高；追求写代码技巧，提出了结构化程序设计方法；软件复杂性增加，需求增加，但软件开发方法和软件项目管理技术跟不上，开发速度慢，与计算机硬件发展速度拉大距离；软件数量猛增，但质量差，可维护性差，维护成本急剧增加；,上述矛盾越来越显著，最终导致了软件危机；,软件危机,第1章软件工程学概述,“软件危机”的概念是在1968年北大西洋公约组织（NATO）的计算机科学家在联邦德国召开的国际学术会议上才第一次提出，软件开发长期以来存在“开发周期长和成本高、质量差、适应性差、难维护”这四大难题，在早期称它为“软件危机”，它是计算机科学发展进程的必然产物，只不过到后来这种现象日渐严重，已经影响到计算机事业的发展，因而才引起各界的关注。,首次提出：软件工程！,软件危机的典型表现：,第1章软件工程学概述,（1）对软件开发成本和进度的估计常常很不准确；,（2）用户对“已完成的”软件系统不满意的现象经常发生；,（3）软件产品的质量往往靠不住；,（4）软件常常是不可维护的；,（5）软件通常没有适当的文档资料；,（6）软件成本在计算机系统总成本中所占的比例逐年上升；,（7）软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。,第1章软件工程学概述,软件危机的典型实例：,该系统由4000个模块组成，共约100万条指令，工作量是5000个人年（人年：人数同工作年数乘积的总和，工作量），开发费用达数亿美元，但人们在使用时从操作系统的程序中发现2000个以上的错误，该系统的开发未达到预期的效果，而IBM公司在经济上蒙受巨大损失。,OS/360系统的负责人Brooks这样描述开发过程的困难和混乱：“像巨兽在泥潭中作垂死挣扎，挣扎得越猛，泥浆就沾得越多，最后没有一个野兽能够逃脱淹没在泥潭中的命运。”,在61年年底，IBM开始打算实施“360系统电子计算机计划”，据当时的估算，整个计划投资约需50亿美元（这可是在60年代初，十几年前的“曼哈顿工程”才花了20亿），这是不折不扣的大手笔，要知道，当时IBM的年营业额还不到这个数字。,例如，IBM公司60年代对OS/360操作系统的开发过程中遭受到挫折就是一个典型的例子。,所以如此花钱，是因为这项计划要做一些以前没人做过的事，这将是一个通用的系统（360就是360度的意思，表示该系统全面的应用范围），该系列不同型号的计算机将能享用同样的设备，如磁带机、打印机等，能使用同样的软件，并且可以相互连接，一起工作，这些在今天看来理所当然的事，在当时可是闻所未闻。该项目在硬件设计上很有创新，乃至IBM不得不自己动手设计制造芯片（因为买不到），但更大的困难却是在软件方面，要让所有的软件适用于所有的电脑（当然，仅限于360系列），这个理念让IBM的软件工程师们伤透脑筋，投入到这个项目中的软件工程师超过2000人（Windows2000也只动用了1700名），花费超过5亿美元，竟然超过了硬件研发的费用，所有这些都是创纪录的。,尽管软件开发工作未获全胜，但360项目还是取得了辉煌的成功，IBM在籍此在计算机行业几乎是一统天下，IBM/360更被誉为人类从原子能时代进入信息时代标志。此后IBM开发的大型机系列都保持了与360系统的兼容，直到最新的z系列，在360上写的程序仍可以不经修改的运行，“兼容”这一概念从此开始深入人心。360计划虽然是在61年开始启动，但等到完成己是1964年，它的主要部件采用了集成电路（IntergratedCircuit,IC），属于第三代计算机，它也是第三代计算机的标志产品。,第1章软件工程学概述,软件危机的典型实例：,布鲁克斯（Brooks）分别于1975和1987年出版了两本著名的软件工程知识著作“人月神话”和“没有银弹”（NoSilverBullet），Brooks的著名论断“软件工作是人类所从事的最复杂的工作.”,人月神话探索了达成一致性的困难和解决的方法，并探讨了软件工程管理的其他方面。,“没有银弹”（NoSilverBullet）,负责这项艰苦卓绝的开发任务的，是FrederickBrooks，当时年仅三十，他是世界上第一批获得计算机科学博士学位的人之一，有趣的是，当开发这个新型操作系统的计划提出时，Brooks本是最强硬的反对派，因为他觉得这个项目的难度骇人听闻，实在是不切实际。但当IBM的管理层拍下板来，要Brooks担当重任时，他居然慨然应允，高风亮节，实在是令人佩服。他本人更在99年获得了计算机领域的最高奖“图灵奖”。,该论述中强调真正的银弹并不存在，而所谓的银弹则是指没有任何一项技术或方法可以能让软件工程的生产力在十年内提高十倍。,第1章软件工程学概述,3、程序工程时代（68年-）,硬件向巨型机和微型机二个方向发展，出现了计算机网络，软件方面提出了软件工程，出现了“计算机辅助软件工程”（CASE）计算机的应用领域渗透到各个业务领域，出现了嵌入式应用，其特点是受制于它所嵌入的宿主系统,1.1.1软件发展-软件危机,开发方式逐步由个体合作方式转向工程方式软件工程方面的研究主要包括软件开发模型、软件开发方法及技术、软件工具与环境、软件过程、软件自动化系统等软件方面研究以智能化、自动化、集成化、并行化、以及自然化为标志的软件开发新技术,第1章软件工程学概述,1.1.2产生软件危机的原因,（1）与软件本身的特点有关,软件是逻辑部件。软件不会被“用坏”，如果发现了错误，很可能是开发时期引入。软件规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。,第1章软件工程学概述,1.1.2产生软件危机的原因,（2）与软件开发与维护的方法不正确有关忽视软件需求分析的重要性。对用户要求没有完整准确的认识就匆忙着手编写程序。越早开始写程序，完成它所需要用的时间往往越长。认为软件开发就是写程序并设法使之运行。程序只是完整的软件产品的一个组成部分。一个软件产品必须由一个完整的配置组成，软件配置主要包括程序、文档和数据等成分。,第1章软件工程学概述,1.1.2产生软件危机的原因,（2）与软件开发与维护的方法不正确有关轻视软件维护。维护是极端艰巨复杂的工作，需要花费很大代价。软件维护的费用占软件总费用的55%70%。软件工程学的一个重要目标就是提高软件的可维护性，减少软件维护的代价。,第1章软件工程学概述,1.1.3消除软件危机的途径,软件工程！,对计算机软件有正确的认识。软件程序！认识到软件开发是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。应该推广使用在实践中总结出来的开发软件的成功技术和方法，并继续研究探索。应该开发和使用更好的软件工具。总之，为了解决软件危机，既要有技术措施(方法和工具)，又要有必要的组织管理措施。,第1章软件工程学概述,1.2软件工程简介,软件工程：是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护。,软件工程的代表性定义：Boehm：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。FritzBauer：软件工程是为了经济地获得可靠的和能在实际机器上高效运行的软件而建立和使用的好的工程原则。IEEE：软件工程是（1）将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中；（2）研究（1）的中所述方法。计算机科学技术百科全书：软件工程是应用计算机科学、数学及管理科学等原理，以工程化的原则和方法制作软件的工程。,第1章软件工程学概述,1.2软件工程历史,软件工程的划代（无公认的定义）：1970年末之前，传统软件工程，瀑布模型。1980年后，面向对象软件工程，面向对象语言以Smalltalk-80的出现为标志。1984年后，软件过程工程，掀起软件过程运动，1991年出现的CMM是典型代表（指“能力成熟度模型”，其英文全称为CapabilityMaturityModelforSoftware，英文缩写为SW-CMM，简称CMM）。1990年后，构件工程，基于构件的软件开发方法，可重用的构件组装成新系统。,第1章软件工程学概述,1.2软件工程特征,软件工程的本质特性：软件工程关注于大型程序的构造软件工程的中心课题是控制复杂性软件经常变化开发软件的效率非常重要和谐地合作是开发软件的关键软件必须有效地支持它的用户在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品,第1章软件工程学概述,软件工程的本质特性：软件工程关注于大型程序的构造,“大”与“小”的分界线并不十分清晰。通常把一个人在较短时间内写出的程序称为小型程序，而把多人合作用时半年以上才写出的程序称为大型程序。传统的程序设计技术和工具是支持小型程序设计的，不能简单地把这些技术和工具用于开发大型程序。,第1章软件工程学概述,软件工程的本质特性：软件工程的中心课题是控制复杂性,软件所解决的问题十分复杂，以致于不能把问题放在一起试途一步解决。人们不得不把问题分解，使得分解出的每个部分是直观、明了、可理解的，而且各部分之间保持简单的联系。用这种方法并不能降低问题的整体复杂性，但是却可使它变成容易解决。许多软件的复杂性主要不是由问题的内在复杂性造成的，而是由必须处理的大量细节，让人看上去觉得很复杂。结论：分解的手法，是控制复杂性的主要手段。,控制复杂性的有效方法是分解：面向过程的方法，是按功能分解；面向对象的方法，是按责任分解。,第1章软件工程学概述,软件工程的本质特性：软件需求经常变化,绝大多数软件都模拟了现实世界的某一部分。现实世界不断变化，人们对其认识也有偏差，这就造成了软件需求经常变化的特性。这种变化不仅存在于开发过程中和也存在交付使用以后。前者要求在开发过程中，应能灵活调整设计方案，后者要求软件应具有可维护性。,需求变更是软件开发活动与生俱来的特性，不可避免。变更不是坏事，但它是软件开发面临的最大挑战。软件工程追求的是：封装变更，灵活设计，应对变更，通过好的设计方法，使变更对原有设计方案和已有代码影响最小。,第1章软件工程学概述,软件工程的本质特性：开发软件的效率非常重要,随着社会经济和文化的发展，网络及各类开发与应用平台的不断翻新，计算机硬件性能的不断提高，社会对软件的数量、规模和复杂性不断提高，软件的需求供不应求的现象依然日益严重。寻求开发与维护软件的更好、更有效的方法和工具，依然是软件工程的一个重要课题。不断提高软件开发效率非常重要,规范的开发过程好的开发环境和工具、提高软件复用是软件工程提高效率的有效办法。,第1章软件工程学概述,软件工程的本质特性：和谐地合作是开发软件的关键,软件处理的问题日益复杂和庞大，软件开发往往是多人协同工作的成果，明确的责任划分和有效的互通信团队成员协作的关键。事实上仅有上述规定还不够，每个人还必须严格地按规定行事。为了迫使团队成员遵守规定，应该运用标准和规程。通常，可以用工具来支持这些标准和规程。总之，纪律是成功地完成软件开发项目的一个关键。,团队合作是必须的，使用有效的工具，进行有效的沟通是关键。,第1章软件工程学概述,软件工程的本质特性：,软件必须有效地支持用户（功能、效能、手册、作用环境）。在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品：文化创造产品。,第1章软件工程学概述,1.2软件工程-基本原理,1983年，著名软件工程专家B.Boehm（勃姆）综合有关专家和学者的意见，并根据多年开发软件的经验，提出了软件工程的七条原理。,用分阶段的生命周期计划严格管理坚持进行阶段评审实行严格的产品控制采用现代程序设计技术结果应能清楚地审查开发小组的人员应该少而精承认不断改进软件工程实践的必要性,第1章软件工程学概述,1.2软件工程-软件工程方法学,软件工程包括技术和管理两方面的内容。提供如何完成过程活动的指南和准则。,管理：通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。如重用技术、项目管理技术。,技术(软件工程方法学)：通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学(methodology)，也称为范型(paradigm)。如面向对象分析、设计、实现与测试技术等。,第1章软件工程学概述,1.2.3软件工程方法学,软件工程方法学3要素：,过程：需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。,工具：是为运用方法而提供的自动的或半自动的软件工程支撑环境；如CASE(Computer-AidedSoftwareEngineering)工具。,方法：是完成软件开发的各项任务的技术方法，回答“怎样做”的问题；,第1章软件工程学概述,1.2.3软件工程方法学,1.传统方法学(生命周期方法学或结构化范型)强调自顶向下（1）采用结构化技术来完成软件；,结构化开发方法由结构化分析、结构化设计和结构化程序设计三部分（3S）有机组合而成的。这里所说的结构是指软件系统内各个组成要素之间的相互联系、相互作用的框架。,在本质上，结构化的软件开发方法是面向数据、面向过程、面向功能、面向数据流的观点来映射问题的。,第1章软件工程学概述,1.2.3软件工程方法学,（2）划分为若干个阶段，然后顺序地完成每个阶段的任务；每个阶段的任务相对独立，而且比较简单，降低了整个软件开发工程的困难程度（阶段性）；,当软件规模庞大，或者的需求模糊或随时间而变化时，传统方法学往往不成功；维护起来仍然很困难。,（4）每个阶段结束前必须从技术和管理两方面对这个阶段的开发成果进行严格的检查，通过之后这个阶段才算结束；保证质量，提高可维护性（阶段审查）；,（3）前一个阶段是后一个阶段的前提和基础，而后一阶段提出的解法更具体，细节更多（阶段衔接）；,第1章软件工程学概述,1.2.3软件工程方法学,2.面向对象方法学强调主动地多次反复迭代,面向对象方法：把数据和行为看成同等重要，它是一种以数据为主线，把数据和对数据的操作紧密地结合起来的方法。,面向对象方法学4个要点：,对象(object)：融合了数据及在数据上的操作行为。类(class)：类是对具有相同数据和相同操作的一组相似对象的定义。继承：按照父类与子类的关系，把若干个相关类组成一个层次结构的系统。消息：对象彼此间仅能通过发送消息互相联系。,第1章软件工程学概述,1.2.3软件工程方法学,面向对象方法学的优点：面向对象方法学的尽量模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界解决问题的方法与过程。面向对象方法学开发软件的过程，是一个主动地多次反复迭代的演化过程，保证了在各项开发活动之间的平滑过渡。促进了软件重用。最终的软件产品由许多较小的、基本上独立的对象组成，每个对象相当于一个微型程序，而且大多数对象都与现实世界中的实体相对应，降低了复杂性，提高了可理解性，简化了开发和维护工作。,第1章软件工程学概述,1.2.3软件工程方法学,软件四化：构架平台化组建业务化编码自动化管理工厂化以面向对象技术为手段，以可重用软件构件化和体系架构为基础，以工业化生产方式和管理支撑体系为核心的软件新变革。,第1章软件工程学概述,1.3软件生命周期,软件生命周期（SoftwareLifeCycle）定义：从软件开发需求被退出，启动可行性分析开始，经历软件开发过程，直到软件被开发出来、投入使用，最终被淘汰为止的整个时间。,生存周期理论：把整个生存周期划分为若干阶段，使得每个阶段有明确的任务，把规模大、活动多、管理复杂的软件开发活动变得容易控制和管理。,第1章软件工程学概述,1.3软件生命周期阶段划分,三个时期八个阶段：软件生命周期由软件定义、软件开发和运行维护(也称为软件维护)三个时期组成，每个时期又进一步划分成若干个阶段。,三个时期：,八个阶段：,软件生命周期,软件定义,软件开发,软件维护,运行维护,第1章软件工程学概述,1.3软件生命周期基本原则,每个阶段的工作均以前一阶段的结果为依据（输入），并作为下一阶段的前提（输出）。每个阶段结束时，都要有技术审查和管理复审，从技术和管理两方面对阶段性开发成果进行检查，及时决定系统的继续进行，还是停工或返工。每个阶段都进行复审，主要检查必备的文档资料的质量和有效性。前一阶段复审通过了，后一个阶段才能开始。应避免到开发后期才发现先期工作中存在的严重错误，造成不可挽回的损失或浪费。,软件生命周期模型,第1章软件工程学概述,1.3软件生命周期具体内容,1.问题定义,任务：问题是什么通过对客户的访问调查，系统分析员扼要地写出关于问题性质、工程目标和工程规模的书面报告。经过讨论和必要的修改之后这份报告应该得到客户的确认。结果：关于系统规模和目标的报告书（用户确认）,第1章软件工程学概述,1.3软件生命周期,2.可行性研究,任务：有可行的解吗系统分析员需要进行一次大大压缩和简化了的系统分析和设计过程（抽象层位上进行系统分析和设计）。研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法。结果：系统的高层逻辑模型（数据流图、成本效益分析）可行性论证报告（立即进行/推迟进行/不能或不值得进行）,第1章软件工程学概述,1.3软件生命周期,3.需求分析,任务：必须做什么主要是确定目标系统必须具备哪些功能。系统分析员必须和用户密切配合，充分交流信息，以得出经过用户确认的系统逻辑模型。结果：系统的逻辑模型（数据流图、数据字典、简要的算法描述）用规格说明书准确地记录对目标系统的需求,第1章软件工程学概述,1.3软件生命周期,4.总体设计,任务：如何解决已提出的问题设计出实现目标系统的几种可能的方案（低、中、高成本）。用适当的表达工具描述每种方案，分析优缺点，推荐一个最佳方案，制定出实现最佳方案的详细计划。设计程序的体系结构。结果：可能的解法（系统流程图、成本效益分析）推荐的系统体系结构（层次图或结构图）,第1章软件工程学概述,1.3软件生命周期,5.详细设计,任务：怎样具体实现该系统详细地设计每个模块，确定实现模块功能所需要的算法和数据结构。结果：每个模块的算法和数据结构(程序流程图、PAD图、N-S图等)。,第1章软件工程学概述,1.3软件生命周期,6.编码和单元测试,任务：得到正确的程序模块选取一种适当的高级程序设计语言(必要时用汇编语言)，把详细设计的结果翻译成用选定的语言书写的程序；并且仔细测试编写出的每一个模块。结果：代码和测试报告,第1章软件工程学概述,1.3软件生命周期,7.综合测试,任务：得到符合要求的软件通过集成测试、验收测试、现场测试、平行运行等方法对目标系统进一步测试检验。通过对软件测试结果的分析可以预测软件的可靠性；反之，根据对软件可靠性的要求，也可以决定测试和调试过程什么时候可以结束。结果：测试计划、详细测试方案以及实际测试结果完整一致的软件配置,第1章软件工程学概述,1.3软件生命周期,8.软件维护,任务：使系统持久地满足用户的需要改正性维护，诊断和改正在使用过程中发现的软件错误；适应性维护，修改软件以适应环境的变化；完善性维护，根据用户的要求改进或扩充软件；预防性维护，修改软件为将来的维护活动做准备。每一项维护活动实质上是经历了一次压缩和简化了的软件定义和开发的全过程。结果：完整准确的维护记录,第1章软件工程学概述,1.3软件生命周期,各类维护工作量所占比例,维护工作量在软件生命周期所占比例,第1章软件工程学概述,1.4软件过程定义,软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。,过程定义了运用方法的顺序、应该交付的文档资料、为保证软件质量和协调变化所需要采取的管理措施，以及标志软件开发各个阶段任务完成的里程碑。,第1章软件工程学概述,1.4软件过程原则,软件过程提供了一个框架，在该框架下可以建立一个软件开发的综合计划：若干框架活动：适用于所有软件项目，而不在乎其规模和复杂性。若干不同任务的集合：每一个集合都由任务、里程碑、交付物以及质量保证点组成。若干保护性活动：如软件质量保证、软件配置管理、测试与度量等。它们贯穿于整个过程模型之中。保护性活动独立于任何一个框架活动，且贯穿于整个过程之中。,里程碑：用来说明项目进展情况的事件。通常把一个开发活动的结束或一项开发任务的完成定义为一个里程碑。,第1章软件工程学概述,1.4软件过程描述方法,描述软件过程生命周期模型。建立软件开发过程模型的理论基础是软件生命周期理论和相关的软件工程原则，因此，软件过程模型又称软件生命周期模型（SoftwareLifeCycleModel）,过程模型化是为了便于理解和操作。,软件过程模型是对软件开发活动进行有效地组织、协调、管理与控制的一种策略。,其核心思想主张把软件过程划分成若干个阶段，每个阶段所包含的活动内容和性质具有“高内聚，低藕合”的特征。这样有助于简化问题、有助于验证阶段性的工作成果、有助于对软件工程的施工与管理。,第1章软件工程学概述,1.4软件过程具体模型,软件过程包括软件开发过程和软件维护过程。人们基于软件工程方法论和软件项目特点总结出了不同的软件过程模型。好的过程模型吸收了成功的软件工程经验和有效的软件工程原则，因此参考软件过程模型框架组织软件项目有利于提高工作效率、把握开发质量，总体上可以提高软件项目的成功率。为获得高质量的软件产品，软件过程必须科学、有效。没有一个适用于所有软件项目的任务集合。因此，科学、有效的软件过程应该定义一组适合于所承担的项目特点的任务集合。,第1章软件工程学概述,1.4.1瀑布模型,在20世纪80年代之前，瀑布模型一直是惟一被广泛采用的生命周期模型，现在它仍然是软件工程中应用得最广泛的过程模型。传统软件工程方法学的软件过程，基本上可以用瀑布模型来描述。,传统的瀑布模型,1970年温斯顿罗伊斯（WinstonRoyce）提出了著名的“瀑布模型”,一次性提供完整产品！,第1章软件工程学概述,1.4.1瀑布模型,瀑布模型的特点：,1.阶段间具有顺序性和依赖性前一阶段的工作完成之后，才能开始后一阶段的工作；前一阶段的输出文档就是后一阶段的输入文档。,3.质量保证的观点每个阶段都必须完成规定的文档，是“文档驱动”的模型；每个阶段结束前都要对所完成的文档进行评审，尽早发现问题，改正错误。,2.推迟实现的观点对于规模较大的软件项目来说，往往编码开始得越早最终完成开发工作所需要的时间反而越长。,第1章软件工程学概述,1.4.1瀑布模型,瀑布模型的优点：可强迫开发人员采用规范的方法；严格地规定了每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。,瀑布模型强调系统开发应有完整之周期，且必须完整的经历周期的每一开发阶段，由于该模式强调系统开发过程需有完整的规划、分析、设计、测试及文件等管理与控制，因此能有效的确保系统品质，它已经成为业界大多数软件开发的标准。,第1章软件工程学概述,1.4.1瀑布模型,瀑布模型的缺点：实际的项目很少按照该模型给出的顺序进行。项目初期用户常常难以清楚地给出所有需求，而这恰恰是线性顺序模型所必须给出的。只能通过文档了解产品，不经过实践的需求是不切实际的。用户必须有耐心，程序的运行版本要等到项目开发晚期才能得到。大的错误如果到检查运行程序时才被发现，后果可能是灾难性的。,第1章软件工程学概述,1.4.1瀑布模型,瀑布模型适用于：需求是预知的；软件实现方法是成熟的；项目周期较短。,第1章软件工程学概述,1.4.1瀑布模型,传统的瀑布模型过于理想化了，事实上，人在工作过程中不可能不犯错误。在设计阶段可能发现规格说明文档中的错误，而设计上的缺陷或错误可能在实现过程中显现出来，在综合测试阶段将发现需求分析、设计或编码阶段的许多错误。因此，实际的瀑布模型是带“反馈环”的。,瀑布模型的改进,当在后面阶段发现前面阶段的错误时，需要返回前面的阶段，修正前面阶段的产品之后再回来继续完成后面阶段的任务。,维护反馈,第1章软件工程学概述,1.4.2快速原型模型,快速原型：是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。,快速原型模型的特点：快速原型模型不带反馈环，软件产品的开发基本上是线性顺序进行的。快速原型的本质是“快速”。应该尽可能快地建造出原型系统，以加速软件开发过程，节约成本。,维护反馈,一次性提供完整产品！,第1章软件工程学概述,1.4.2快速原型模型,（1）原型系统已经通过与用户交互而得到验证，据此产生的规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工（无需反馈）。,（2）开发人员通过建立原型系统已经学到了许多东西（至少知道了“系统不应该做什么，以及怎样不去做不该做的事情”），因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。,软件产品一旦交付给用户使用之后，维护便开始了。根据所需完成的维护工作种类的不同，可能需要返回到需求分析、规格说明、设计或编码等不同阶段，如图中虚线箭头所示。,维护反馈,第1章软件工程学概述,1.4.3增量模型,增量模型：增量模型把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。,非一次性提供完整产品！,第1章软件工程学概述,1.4.3增量模型,第一个增量构件往往实现软件的基本需求，提供最核心的功能。第二个增量构件提供更完善的编辑和文档生成功能；第三个增量构件实现拼写和语法检查功能；第四个增量构件完成高级的页面排版功能。,把软件产品分解成增量构件时，应该使构件的规模适中，规模过大或过小都不好。最佳分解方法因软件产品特点和开发人员的习惯而异。分解时惟一必须遵守的约束条件是，当把新构件集成到现有软件中时，所形成的产品必须是可测试的。,增量模型构件特征（如文字处理软件）:,第1章软件工程学概述,1.4.3增量模型,人员分配灵活，刚开始不用投入大量人力资源。当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径。逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品。,增量模型的难点：软件体系结构必须是开放的。模型本身是自相矛盾的。整体独立构件。不同的构件并行地构建有可能加快工程进度，但是冒无法集成到一起的风险。,非一次性提供完整产品！,增量模型的优点：,第1章软件工程学概述,1.4.3增量模型,增量模型适用于：适用于需求经常改变的软件开发过程。如果在项目既定的商业要求期限之前不可能找到足够的开发人员，在这种情况下，增量模型显得特别有用。,第1章软件工程学概述,1.4.3增量模型,增量模型和瀑布模型之间的本质区别是：瀑布模型属于整体开发模型，它规定在开始下一个阶段的工作之前，必须完成前一阶段的所有细节。增量模型属于非整体开发模型，它推迟某些阶段或所有阶段小的细节，从而较早地产生工作软件。,增量模型和快速原型模型在产品提交的不同是：采用瀑布模型或快速原型模型开发软件时，目标都是一次就把一个满足所有需求的产品提交给用户。增量模型则与之相反，它分批地逐步向用户提交产品。,第1章软件工程学概述,1.4.4螺旋模型,软件风险是任何软件开发项目中都普遍存在的实际问题，项目越大，软件越复杂，承担该项目所冒的风险也越大。软件风险可能在不同程度上损害软件开发过程和软件产品质量。因此，在软件开发过程中必须及时识别和分析风险，并且采取适当措施以消除或减少风险的危害。,出现背景：,构建原型是一种能使某些类型的风险降至最低的方法。为了降低交付给用户的产品不能满足用户需要的风险，一种行之有效的方法是在需求分析阶段快速地构建一个原型。在后续的阶段中也可以通过构造适当的原型来降低某些技术风险。当然，原型并不能“包治百病”，对于某些类型的风险，原型方法是无能为力的。,1988年，巴利玻姆(BarryBoehm)正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。,第1章软件工程学概述,1.4.4螺旋模型,螺旋模型的基本思想：,简化的螺旋模型,把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。,使用原型及其他方法来尽量降低风险。,第1章软件工程学概述,1.4.4螺旋模型,对于大型软件，只开发一个原型往往达不到要求。螺旋模型将瀑布模型和增量模型结合起来，并加入了风险分析。该模型将开发过程划分为沟通、制定计划、风险分析、实施工程、构造与发布和系统评估6个活动。,第1章软件工程学概述,1.4.4螺旋模型,完整的螺旋模型,螺旋模型的优点：主要优势在于它是风险驱动的。对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；减少了过多测试或测试不足所带来的风险；维护只是模型的另一个周期，维护和开发之间没有本质区别。,第1章软件工程学概述,1.4.4螺旋模型,完整的螺旋模型,螺旋模型的缺点：它是风险驱动的，采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失。过多的迭代次数会增加开发成本，延迟提交时间。,螺旋模型适用于：特别适用于庞大、复杂并具有高风险的系统。适用于内部开发的大规模软件项目。,第1章软件工程学概述,1.4.5喷泉模型,喷泉模型：喷泉模型（fountainmodel）是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。,喷泉模型主要用于采用对象技术的软件开发项目。该模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性。软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分。无间隙指在各项活动之间无明显边界，如分析和设计活动之间没有明显的界限，由于对象概念的引入，表达分析、设计、实现等活动只用对象类和关系，从而可以较为容易地实现活动的迭代和无间隙，使其开发自然地包括复用。,第1章软件工程学概述,1.4.5喷泉模型（了解）,喷泉模型的优点：该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。多次反复地增加或明确目标系统，而不是本质性的改动，降低错误的可能性。,喷泉模型的缺点：由于喷泉模型在各个开发阶段是重叠