《需求工程导论》PPT课件.ppt

软件需求工程,计算机与信息工程学院蔡强新浪微博：钾肥猫gg微信：猫猫QQ：2309172238,课程介绍,本课程是软件工程专业的专业核心课程。课程内容包括需求工程的基础知识、软件需求的基础理论、常用的需求获取方法与技术、常用的需求分析方法、常用的需求分析模型与建模技术、需求管理知识和初步的需求工程过程管理知识。课程在整个软件工程的背景下介绍需求工程知识，试图让学生理解需求工程工作可能给后继软件项目工作带来的影响，并在此基础上全面深入的了解软件需求领域的各项方法、技术与工具。,2,课程体系,先修课程：计算机基础、编程语言专业核心课程群的龙头：软件需求工程、软件设计与体系结构、软件测试与质量、软件过程与管理软件2013级教学大纲,3,教材,需求工程-软件建模与分析(第2版)骆斌、丁二玉 高等教育出版社，2015年2月,2009-4-1,2015-2-1,4,主要参考资料,毋国庆等.软件需求工程.2版.机械工业出版社，2013于向东等.软件需求开发最佳实践.清华大学出版社，2014,5,参考资料,Wiegers K E.软件需求.2版.陆丽娜等译.机械工业出版社，2004.Kovitz B L.实用软件需求.机械工业出版社，2005.Leffingwell D,et al.软件需求管理统一方法.机械工业出版社，2002.Young R R.有效需求实践.机械工业出版社、中信出版社，2002.Hay D C.Requirement Analysis.影印版.清华大学出版社，2003.Larman C,Kruchten P.UML和模式应用.3版.机械工业出版社，2006.Booch G.面向对象分析与设计.2版.机械工业出版社，2003.Kendall K E,et al.系统分析与设计.6版.清华大学出版社，2006.Allen S.数据建模基础教程.清华大学出版社，2004.Brooks,Frederick P.Jr.,汪颖 译.人月神话.清华大学出版社.2002.林锐.软件工程思想.2000相关课程：http:/www.cs.toronto.edu/sme/CSC2106S/index.html.相关课程：需求工程论文汇总：需求管理工具：,6,软件工程相关网站,软件工程专家网：、中国UML：软件工程研究中心：UML软件工程组织：测试时代：测试管理中心：开放软件测试研究：硅谷动力：xunit：中国程序员：；中国系统分析员：中国知网：计算机世界：中国电子报：计算机应用文摘：,7,教材目录,第一部分 绪论 第1章 需求工程导论 第2章 需求基础 第3章 需求工程过程 第二部分 需求获取 第4章 需求获取概述 第5章 确定项目的前景与范围 第6章 涉众分析与硬数据采样 第7章 基于用例/场景模型展开用户需求获取第8章 需求获取方法之面谈 第9章 需求获取方法之原型 第10章 需求获取方法之观察与文档审查,8,教材目录,第三部分 需求分析 第11章 需求分析概述 第12章 过程建模 第13章 数据建模 第14章 面向对象建模 第四部分 需求的文档化和验证 第15章 需求规格说明 第16章 需求验证 第五部分 需求管理与工程管理 第17章 需求管理 第18章 需求工程的过程管理（*）第19章 需求工程中的项目管理（*）,9,教材目录,附录 附录一 IEEE SRS模板 附录二 重要的需求工程实践方法软件Visio 2003Rational Rose 2003（UML）,10,教学要求,认真听课，请勿喧哗，勿影响他人。请保持课堂安静。注意考勤，不要迟到、缺课，考勤影响期末考试资格课程警示。关闭手机或设置静音！作业、上机不要抄袭，自己动手、动脑。上机对号入座。每次上机记录前20名；,11,关于考核,1、期末闭卷考试成绩占70%；2、期中考试不考；3、平时成绩（含作业、实验、考勤）占30%（9次实验）；,12,教学日程安排,119周：每周一下午5/6节：上课，工2-105见教学日历、大纲,119周：每周一下午7/8节：单周延续，双周实验，在工2-401,13,14,第1章.需求工程导论,主要内容,软件的需求问题软件的发展软件生产状况调查需求问题的原因分析需求工程需求工程师,1.1软件的发展60年代的发展,无需求处理,草图分析,18,1.1软件的发展70年代的发展,无需求处理,草图分析,需求分析DFD/ERD,需求分析面向对象,19,1.1软件的发展90年代的发展,20,焦油坑（The Tar Pit）,From THE MYTHICAL MAN-MONTH（人月神话）,21,1.1软件的发展 软件危机与软件工程,“软件危机”(software crisis)。软件工程IEEE：（1）应用系统化的、学科化的、定量的方法，来开发、运行和维护软件，即，将工程应用到软件。（2）对（1）中各种方法的研究工程化生产方法需求分析：系统需求分析与软件需求分析,22,1.2 90年代的软件生产状况调查Standish Group 1995,365家公司的8380个项目成功项目Success：在预计的时间之内，在预算的成本之下，完成预期的所有功能问题项目Challenged：已经完成，软件产品能够正常工作，但在生产中或者超支，或者超期，或者实现的功能不全失败项目Impaired：因无法进行而被中途撤销，或者最终产品无法提交使用,23,1.2 90年代的软件生产状况调查 Standish Group 1995,大公司开发项目的平均成本是232.2万美元，中等公司是133.1万美元，小型公司是43.4万美元大约31的项目在完成之前被取消，52.7的项目成本是原来预算的189%大公司9%按预算交付，小公司16%按预算交付,24,1.2 90年代的软件生产状况调查 影响因素Standish Group 1995,25,1.2 90年代的软件生产状况调查 影响因素Standish Group 1995,26,1.2 90年代的软件生产状况调查 影响因素Standish Group 1995,27,1.2 90年代的软件生产状况调查 影响因素Standish Group 1995,需求因素用户参与（用户输入）高层管理支持清晰的需求说明切合实际的期望清晰的目标和前景需求变化额外的无用功能综合来看，需求因素对成功项目的影响指数为53.9对问题项目的影响指数为55.6对失败项目的影响指数为60.9,28,1.2 90年代的软件生产状况调查ESPITI，1996,欧洲软件协会ESI 欧洲软件过程改进培训计划项目ESPITI 17个国家的超过3800个组织,29,Standish Group,1.2 90年代的软件生产状况调查需求问题的典型案例Bray2002,PROMS（演出权益协会）,11M,1992,未能以常人能理解和检查的形式表述软件需求，软件规格说明也考虑不周RISP（西萨克斯地区信息系统计划）,43M,1990,缺少清晰的项目范围定义TAURUS(伦敦股票交易),75M(1.4B),1993,未能协调不一致的需求LASDS(伦敦救护车服务派遣系统),1992,社会服务领域糟糕的需求分析ATC(空中交通控制系统),1.8B,1998-2001,缺乏健壮的需求规格说明,32,冰山理论,表面需求：说得清潜在需求：无意识,33,主要内容,软件的需求问题需求问题的原因分析应用软件的模拟特性需求问题的技术原因分析需求工程需求工程师,34,2.1 应用软件的模拟特性软件的三种类型,35,2.1 应用软件的模拟特性软件的分析活动,36,2.1 应用软件的模拟特性软件模拟性的实践调查,对应用型软件的“模拟”特性理解及应用问题Capers JonesCapers1996在调查了几百个公司之后发现超过75的企业在需求处理环节存在不足。2000年Nikula等人在对芬兰的中小型公司进行需求处理实践情况评价时发现Nikula2000：在以30分为标准线的情况下，75%的公司竟然在10分以下。Hofmann等人在欧洲的需求工程实践调查中发现仅有约1/3的项目有明确的需求处理过程Hofmann2001。Juristo 等人在对欧洲的150多名RE实践者进行调查后发现，在需求处理的诸多技术当中，需求获取和冲突协商的技术没有得到充分的应用Juristo 2002。研究也发现当软件生产面临时间、市场等其他压力时，漠视“模拟”特性的情况就更为严重Lubars1993，Francisco2003,37,2.2 需求问题的技术原因分析,非技术性和社会性因素组织机构文化、社会背景、商业目标、利益协商关注软件系统和现实之间的互动效应 软件系统环境的组织机构文化、社会背景和系统涉众的目标与利益比软件内部的数据流与状态更应该得到重视解决方案和具体应用环境相关的 不能忽视具体应用环境中的相关因素，例如组织机构的文化、组织结构的规范、组织的行业规范、组织的社会背景等等单纯通过技术的运用来建立一个一致、完整的需求模型是不太可能的 面对冲突要能够分析社会原因和组织机构方面的原因，引导涉众进行利益协商,38,2.2 需求问题的技术原因分析,结构化分析和面向对象分析具有一定的先天缺陷 编程 设计分析设计和编程都有构建高质量（健壮性、可维护性、适应性等等）软件的共同目标，而且使用相同的概念和组织机制保证了从设计到编程的平滑过渡，所以，它们在设计领域的应用也取得了成功 但是需求分析除了拥有构建高质量软件的目标之外，还有一个更加重要的目标是理解现实,39,2.2 需求问题的技术原因分析,以“企业”为中心的软件反映了软件规模日益扩大 一方面提高了需求处理中非技术性和社会性因素的影响比重另一方面也进一步放大了传统技术在需求处理阶段的不适应性,40,软件开发时，一个错误发现得越晚，为改正它所付出的代价就越大。,在1970年代，GTE、TRW和IBM等三家公司对此问题做了独立研究，最后它们得到相似的结论：从表中可以看出，在需求分析阶段检查和修复一个错误所需的代价只有编码阶段所需代价的1/5到1/10，而在维护阶段做同样的工作所付出的代价却是编码阶段的20倍。那是需求阶段的多少倍？,41,2.2 需求问题的技术原因分析,需求错误的高代价性,42,主要内容,软件的需求问题需求问题的原因分析需求工程简介基本活动需求工程与系统工程需求工程特性需求工程师,43,3.1 需求工程,是软件工程的一个分支它关注于软件系统所应予实现的现实世界目标、软件系统的功能和软件系统应当遵守的约束同时它也关注以上因素和准确的软件行为规格说明之间的联系关注以上因素与其随时间或跨产品族而演化之后的相关因素之间的联系,44,3.2 需求工程的基本活动,45,3.3 需求工程与系统工程,46,需求工程与系统工程,1981年，Barry Boehm Boehm1981发现项目费用的6和时间的9-12被消耗在需求阶段。在20年之后，随着需求工程的发展，Hofmann2001发现项目对需求工程的投入也加大了许多：项目工作的15.7和时间的38.6被用于进行需求工程NASA(U.S.National Aeronautics and Space Administration)提供的数据显示 Young2002：当在需求工程当中投入项目总成本的8-14时，可以极大的降低项目的超支率。,3.4 需求工程的特性必要性,软件开发是这样一个工程问题利用通用的计算机结构，构建一个有用的软件系统，来满足人们的某些目的 计算机应用于现实世界的广泛性 新的问题和新的解决方案 定义问题就是需求工程的任务,48,3.4 需求工程的特性重要性,Frederick BrooksBrooks1987“开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。”容易忽略需求工程重要性的地方问题广为人知 电梯调度、图书管理 问题小而简单 出错也无所谓,49,3.4 需求工程的特性复杂性,处理范围广泛 现实世界和计算机世界 涉及诸多参与方 客户、用户、领域专家、需求工程师、软件开发者、系统维护者等 处理内容多样 功能需求、非功能需求、环境及其约束 处理活动互相交织 需求开发的各项活动虽然在理论上具有顺序处理的特性，但在实际执行过程中往往是迭代和互相交织的 处理结果要求苛刻 正确性、完整性和一致性,50,需求工程（RE）的研究与发展,20世纪80年代，成为软件工程的分支；90年代起，成为研究热点之一：1993年起，每2年1次国际研讨会（ISRE）；1994年起，每2年1次国际会议（ICRE）；1996年起，Springer-Verlag发行刊物Requirements Engineering；其他一些工作小组，如欧洲的RENOIR（Requirements Engineering Network of International Cooperating Research Groups）,51,主要内容,软件的需求问题需求问题的原因分析需求工程需求工程师知识要求技能要求,52,现实世界方面 与 技术方面 的桥梁,好的需求工程师更应该扮演好涉众代理的角色，站在涉众的立场想问题，替涉众跟踪和监控软件开发过程，保护涉众的利益,4.2 需求工程师需要具备的技能,软技能 交流观察 抽象分析和问题解决（抽象、整合、系统化）写作关系协调与团队工作,需求工程师行为,创新？团队,案例分析：法律法规与利益协商深圳手机打车软件被紧急叫停2013年05月23日11:03 深圳特区报,市交委认为，手机打车软件部分功能存在安全隐患并违反相关规定，影响了出租车行业运价体系和营运秩序，交通主管部门将依法进行监管和规范。出租车企业负责人表示由于打车软件功能设置和技术运用不够成熟，给行业监管带来了问题，如驾驶员注册准入缺乏认证、提供加价议价功能、操作方式存在行车安全隐患、投诉争议处理困难等，影 响了出租车行业运价体系和营运秩序。,案例分析：文化背景Twitter工程师眼中的新浪微博,Twitter之简约 vs.新浪微博之丰富新浪微博各式各样的新功能马不停蹄地上线(微刊，微人脉，微盘，微 视频，总之各种微)。新浪将微博极大地丰富了：微博，长微博，即时聊天，看新闻，参与热点讨论，交朋友，社交，看公知们争奇斗艳等等。在 Twitter工程师看来，新浪微博的整体设计原则却并不很清晰：改版很多次，几百个功能五花八门。相形之下，Twitter推崇的是至简原则，(Simplify是公司的10个核心价值之一)Twitter 无意在附加功能上做文章，而是希望把大家的注意力都引向正中间的推文上，这是信息实质的所在从诞生到现在，Twitter一直遵循一个产品逻辑，坚定地将自己定位成一个移动端信息广播平台满足大家伙儿的表达欲和分享欲，通过碎片化信息告诉世人“What are you doing?”(你在做什么)。,新浪社交装酷，Twitter专注新闻新浪在微博平台里人为加入了一些话题归纳和引导，比如“热门微博”和“风云榜”等等。抓住我们国人喜欢围观和跟风的心理，新浪微博通过极易操作的转发+评论等功能引导大家参与讨论，置身事内成就了自己的微论坛基因“新浪微博在设计上花了很多功夫让大家注意到一条微博，但并没有花太多心思去组织信息，不能引导大家以一种更客观的方式查看信息本身”。如此一来，大家倾向于肤浅地参与一些没有实质内涵的表演型讨论;你来我去，大家都在“消费情绪，而非真相”不知不觉养起了一堆说话似是而非的大号，充斥着很多情绪性的作秀文字。跟新浪微博不同，Twitter甚至在有意弱化自己的社交属性，致力于将大家的注意力最大限度地引向信息本身“Twitter花了更大力气优化信息搜索功能，努力呈现一个事件的客观发展”。,本章小结,从20世纪60年代末期软件工程产生起，需求分析就一直是软件开发的重要主题20世纪90年代的调查状况表明，单纯的需求分析已经不能很好的解决软件生产中的“需求”问题应用型软件的模拟性和一系列的技术原因表明：软件生产需要进行一个比需求分析更加复杂和完整的需求工程需求工程是软件工程当中一项重要和复杂的活动，需求工程需要具备一定的知识和技能才可以很好的执行需求工程活动,59,分组,85人，3-4人一组，自由组合。确定人员后，下周一上课时上报,60,思考题,对学校目前使用的一些系统，比如一卡通、学生贷款管理系统、教务管理系统的看法？尤其提出自己的意见和修改建议。IBM 360系统的开发到底是咋回事？下一页中的几个开发失败案例究竟因为什么？注：分组提交，下次课前抽查提问。,61,1.2 90年代的软件生产状况调查需求问题的典型案例Bray2002,PROMS（演出权益协会）,11M,1992,未能以常人能理解和检查的形式表述软件需求，软件规格说明也考虑不周RISP（西萨克斯地区信息系统计划）,43M,1990,缺少清晰的项目范围定义TAURUS(伦敦股票交易),75M(1.4B),1993,未能协调不一致的需求LASDS(伦敦救护车服务派遣系统),1992,社会服务领域糟糕的需求分析ATC(空中交通控制系统),1.8B,1998-2001,缺乏健壮的需求规格说明,62,第1章课堂延续：软件危机与软件工程,2023/8/3,问题,1、什么是软件？2、大家学过的编程语言有哪些？3、各种语言编写的代码量多少？4、编程遇到的困难？,64,软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合。程序是按事先设计的功能和性能要求执行的指令序列数据是使程序能正常操纵信息的数据结构文档是与程序开发，维护和使用有关的图文材料,什么是软件？,65,软件的特点,软件是一种逻辑实体，而不是具体的物理实体。因而它具有抽象性软件的生产与硬件不同，在它的开发过程中没有明显的制造过程在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题,66,软件失效曲线,67,软件的开发和运行常受到计算机系统的限制，对计算机系统有着不同程度的依赖性软件的开发至今尚未完全摆脱手工艺的开发方式软件本身是复杂的实际问题的复杂性程序逻辑结构的复杂性 软件成本相当昂贵相当多的软件工作涉及到社会因素,68,软件开发的3个阶段,自20世纪40年代中出现了世界上第一台计算机以后，就有了程序的概念。其后经历了几十年的发展，计算机软件经历了三个发展阶段：程序设计阶段，约为50至60年代程序系统阶段，约为60至70年代软件工程阶段，约为70年代以后,69,程序开发的变化,(1)人们改变了对软件的看法。50年代到60年代时，程序设计曾经被看做是一种任人发挥创造才能的技术领域。当时人们认为，写出的程序只要能在计算机上得出正确的结果，程序的写法可以不受任何约束。随着计算机的广泛使用，人们要求这些程序容易看懂、容易使用，并且容易修改和扩充。于是，程序便从个人按自己意图创造的“艺术品”转变为能被广大用户接受的工程化产品。,70,(2)软件的需求是软件发展的动力。早期的程序开发者只是为了满足自己的需要，这种自给自足的生产方式仍然是其低级阶段的表现。进入软件工程阶段以后，软件开发的成果具有社会属性，它要在市场中流通以满足广大用户的需要。(3)软件工作的范围从只考虑程序的编写扩展到涉及整个软件生存周期。,71,表1 软件规模的分类,72,例子-IBM360操作系统,研制人员最多时达1000多人，从1963年到1966年共花了四年时间才完成，总计耗费了5000多人年，以后又进行不断的修改和补充。据统计，这个操作系统每次发行的新版本都是从前一版本中找出1000个程序错误而修正的结果。该系统的整个研制费用为5亿美元，其中近一半花在软件上。,73,2023/8/3,软件危机,这个项目的负责人F.D.Brooks事后总结了他在组织开发过程中的沉痛教训时说：“.正像一只逃亡的野兽落到泥潭中做垂死的挣扎，越是挣扎，陷得越深，最后无法逃脱灭顶的灾难。.程序设计工作正像这样一个泥潭，.一批批程序员被迫在泥潭中拼命挣扎，.谁也没有料到问题竟会陷入这样的困境.”。IBM360操作系统的历史教训成为软件开发项目的典型事例为人们所记取。,Software Crisis!,2023/8/3,软件危机,问题出在哪里？项目没有被很好地理解；计划不周，最终导致进度拖延。,例1.In the late 1960s,a bright-eyed young engineer*was chosen to“write”a computer program for an automated manufacturing application.The reason for his selection was simple.He was the only person in his technical group who had attended a computer programming seminar.He knew the ins and outs of assembler language and Fortran,but nothing about software engineering and even less about project scheduling and tracking.*If youre wondering whether this story is autobiographical,it is!,2023/8/3,软件危机,His boss gave him the appropriate manuals and a verbal description of what had to be done.He was informed that the project must be completed in two months.He read the manuals,considered his approach,and began writing code.After two weeks,the boss called him into his office and asked how things were going.“Really great,”said the young engineer with youthful enthusiasm,“This was much simpler than I thought.Im probably close to 75 percent finished.”The boss smiled.“Thats really terrific,”he said.He then told the young engineer to keep up the good work and plan to meet again in a weeks time.,2023/8/3,软件危机,A week later the boss called the engineer into his office and asked,“Where are we?”“Everythings going well,”said the youngster,“but Ive run into a few small snags.Ill get them ironed out and be back on track soon.”“How does the deadline look?”the boss asked.“No problem,”said the engineer.“Im close to 90 percent complete.”If youve been working in the software world for more than a few years,you can finish the story.Itll come as no surprise that the young engineer stayed 90 percent complete for the entire project duration and only finished(with the help of others)one month late.,2023/8/3,软件危机,例2：In the early 1980s,the United States Internal Revenue Service(IRS)hired Sperry Corporation to build an automated federal income tax form processing system.According to the Washington Post,the“system has proved inadequate to the workload,cost nearly twice what was expected and must be replaced soon”(Sawyer 1985).In 1985,an extra$90 million was needed to enhance the original$103 million worth of Sperry equipment.In addition,because the problem prevented the IRS from returning refunds to taxpayers by the deadline,the IRS was forced to pay$40.2 million in interest and$22.3 million in overtime wages for its employees who were trying to catch up.,2023/8/3,软件危机,In 1996,the situation had not improved.The Los Angeles Times reported on March 29 that there was still no master plan for the modernization of IRS computers,only a six-thousand-page technical document.Congressman Jim Lightfoot called the project“a$4-billion fiasco that is floundering because of inadequate planning”(Vartabedian 1996).,Myth:If we get behind schedule,we can add more programmers and catch up.Reality:Software development is not a mechanistic process like manufacturing.In the words of Brooks,“adding people to a late software project makes it later.”,2023/8/3,软件危机,没有充分的文档资料(documentation)Myth:The only deliverable for a successful project is the working program.Reality:A working program is only one part of a software configuration that includes programs,documents,and data.Documentation forms the foundation for successful development and,more important,provides guidance for the software maintenance task.,Managers evaluate,track progress,.Programmers communicate to each otherMaintainers VITAL,人与人的交流比写程序困难得多。,2023/8/3,软件危机,软件可靠性(reliability)缺少度量的标准，质量无法保证。如何保证软件产品的质量，是非常复杂困难的问题。特别对于规模庞大的软件，如：The software supporting the American space shuttle consists of 3 million lines of code,including computers on the ground controlling the launch and the flight;there were one hundred thousand lines of code in the shuttle itself in 1985.President Reagans proposed Strategic Defense Initiative(SDI)is estimated to require 10 to 100 million lines of code.Many computer scientists and software engineers continue to believe there is no way to write and test the software to guarantee adequate reliability.,2023/8/3,软件危机,软件难以维护(maintainability)不易升级(evolvability),Myth:Once we write the program and get it to work,our job is done.Reality:Someone once said that“the sooner you begin writing code,the longer itll take you to get done.”Industry data indicate that between 50 and 70 percent of all effort expended on a program will be expended after it is delivered to the customer for the first time.,2023/8/3,软件危机,解决问题的想法：Better management Different team organizations Better languages&toolsUniform coding conventions 必须意识到：“软件”编程，它有自己的生命周期(life cycle)。大型软件系统的开发与其它工程项目如建造桥梁、制造飞机、轮船等的开发是同理的。,软件危机,人们把软件开发和维护中的各种问题称为“软件危机”。软件危机主要包含两方面的问题：如何开发软件以满足软件日益增长的需求；如何维护数量不断增长的已有软件。软件危机的表现：对软件开发成本和进度的估算很不准确。用户对完成的软件很不满意。软件产品的质量很不可靠。没有完整的文档。软件成本比重上升。软件开发生产效率低下，软件开发技术进步落后与需求的增长，造成“供不应求”的局面，,84,许多计算机和软件科学家尝试，把其它工程领域中行之有效的工程学知识运用到软件开发工作中来。经过不断实践和总结，最后得出一个结论：按工程化的原则和方法组织软件开发工作是有效的，是摆脱软件危机的一个主要出路。,85,2023/8/3,软件工程,1、原理(Principles):用分阶段的生命周期计划严格管理 项目概要计划 里程碑计划 项目控制计划 产品控制计划 验证计划 运行维护计划 坚持进行阶段评审 实行严格的产品控制基准配置管理(Baseline configuration management),86,2023/8/3,软件工程,采用现代程序设计技术 结果应能清楚地审查 set standards 开发小组的成员应该少而精1+1 2 承认不断改进软件工程实践的必要性,87,软件工程过程,软件规格说明：规定软件的功能及其运行的限制软件开发：产生满足规格说明的软件软件确认：确认软件能够完成客户提出的要求软件演进：为满足客户的变更要求，软件必须在使用的过程中演进,88,软件工程过程的特性,易理解性可见性可支持性可接受性,可靠性健壮性可维护性速度,89,软件生存期 life cycle,软件有一个孕育、诞生、成长、成熟、衰亡的生存过程。这个过程即为计算机软件的生存期软件生存期的六个步骤，即制定计划、需求分析、设计、程序编码、测试及运行维护,90,瀑布模型,RETURN,91,2023/8/3,瀑布模型(Waterfall Model),92,制定计划,确定要开发软件系统的总目标给出功能、性能、可靠性以及接口等方面的要求完成该软件任务的可行性研究估计可利用的资源(硬件，软件，人力等)、成本、效益、开发进度制定出完成开发任务的实施计划，连同可行性研究报告，提交管理部门审查,93,需求分析和定义,对用户提出的要求进行分析并给出详细的定义编写软件需求说明书或系统功能说明书及初步的系统用户手册提交管理机构评审,94,软件设计,概要设计 把各项需求转换成软件的体系结构。结构中每一组成部分都是意义明确的模块，每个模块都和某些需求相对应详细设计 对每个模块要完成的工作进行具体的描述，为源程序编写打下基础编写设计说明书，提交评审。,95,程序编写,把软件设计转换成计算机可以接受的程序代码，即写成以某一种特定程序设计语言表示的“源程序清单”写出的程序应当是结构良好、清晰易读的，且与设计相一致的,96,软件测试,单元测试，查找各模块在功能和结构上存在的问题并加以纠正组装测试，将已测试过的模块按一定顺序组装起来按规定的各项需求，逐项进行有效性测试，决定已开发的软件是否合格，能否交付用户使用,97,运行维护,改正性维护 运行中发现了软件中的错误需要修正适应性维护 为了适应变化了的软件工作环境，需做适当变更完善性维护 为了增强软件的功能需做变更,98,软件工程定义,1968年NATO(北大西洋公约组织)会议上首次提出Fritz Bauer：软件工程是建立和使用一套合理的工程原则，以便获得经济的软件，这种软件是可靠的，可以在实际机器上高效地运行IEEE：软件工程是：将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；在中所述方法的研究计算机科学技术百科全书：软件工程是应用计算机科学、数学及管理科学等原理，开发软件的工程。软件工程借鉴传统工程的原则、方法，以提高质量、降低成本为目的,99,软件工程三要素：方法、工具和过程,软件工程方法为软件开发提供了“如何做”的技术软件工具为软件工程方法提供了自动的或半自动的软件支撑环境,100,软件工程过程定义了:方法使用的顺序 要求交付的文档资料 为保证质量和适应变化所需要的管理 软件开发各个阶段完成的里程碑,101,软件工程项目的基本目标,付出较低的开发成本达到要求的软件功能取得较好的软件性能开发的软件易于移植需要较低的维护费用能按时完成开发工作，及时交付使用,102,在具体项目的实际开发中，企图让以上几个目标都达到理想的程度往往是非常困难的。,103,软件工程的框架,目标：生产具有正确性、可用性以及价格合宜的产品 正确性反映软件产品实现相应功能规约的程度 可用性反映软件的基本结构、实现及其文档为用户可用的程度 价格合宜反映软件开发与运行的总代价满足用户要求的程度