软件工程第一章课件

上传人:小*** 文档编号:243151732 上传时间:2024-09-17 格式:PPT 页数:76 大小:662.50KB
返回 下载 相关 举报
软件工程第一章课件_第1页
第1页 / 共76页
软件工程第一章课件_第2页
第2页 / 共76页
软件工程第一章课件_第3页
第3页 / 共76页
点击查看更多>>
资源描述
单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,软件工程,电子信息工程学院 计算机系,宋晓莉:,song_xiaoli,13526993830,教材,教材,软件工程导论,第五版 张海藩编著 清华大学出版社,参考教材,软件工程,第八版 (英),Ian,Sommerville,著 程成译 机械工业出版社,软件工程 实践者的研究方法,第六版 (美),Roger S. Pressman,著 郑人杰译 机械工业出版社,实用软件工程,郑人杰编著 清华大学出版社,2,教学与考核,必修考试课,共,48,学时,其中理论,32,学时,实验,16,学时,平时(作业、考勤),20%,,实验,10%,,试卷,70%,授课,+,课程设计,2,周,3,第一个课堂作业,你的打算:,想学到什么知识?想找工作、考研?想过四六级?还是想混日子?,你准备找一个什么样的工作?该工作岗位可能需要什么技能?,你能分清机关、事业和企业性质的单位吗?,你估计一下软件工程这门课能教会你什么?,如果让你寻找一个软件项目你会找什么项目?,你和别人合作可能有什么障碍,?,4,例,:,美国,IBM,公司在,1963,年至,1966,年开发的,IBM360,机的操作系统。这一项目花了,5000,人一年的工作量,最多时有,1000,人投入开发工作,写出了近,100,万行源程序。,.,据统计,这个操作系统每次发行的新版本都是从前一版本中找出,1000,个程序错误而修正的结果,.,典型案例,1,5,这个项目的负责人,F. D. Brooks,事后总结了他在组织开发过程中的沉痛教训时说:,“,.,正像一只逃亡的野兽落到泥潭中做垂死的挣扎,越是挣扎,陷得越深,最后无法逃脱灭顶的灾难。,.,程序设计工作正像这样一个泥潭,,.,一批批程序员被迫在泥潭中拼命挣扎,,.,谁也没有料到问题竟会陷入这样的困境,.,”,。,IBM360,操作系统的历史教训成为软件开发项目的典型事例为人们所记取。,典型案例,1,6,1,人员,挫伤人员的积极性,人员素质低,对有问题的员工失控,个人英雄主义,项目后期加入人员,办公环境拥挤嘈杂,开发人员与客户之间产生摩擦,不现实的预期,缺乏有效的项目支持,缺乏各种角色的齐心协力,缺乏用户介入,政治高于物质,充满想象,典型错误,7,2,过程,过于乐观的计划,缺乏足够的风险管理,承包人导致的失败,缺乏计划,在压力下放弃计划,在模糊的项目前期浪费时间,前期活动不合要求,设计低劣,缺少质量保证措施,缺少管理控制,太早或过于频繁的集成,项目估算是遗漏了必要的任务,追赶计划,鲁莽编码,典型错误,8,3,产品,需求的镀金,功能蔓延,开发人员镀金,又推又拉的交易,研究导向的开发,典型错误,9,4,技术,使用不成熟的技术,使用不适合的技术,不恰当的使用,典型错误,10,处在十字路口的,中国软件产,业,主权大国必须建立基于自主技术的、,完整的软件产业体系。,软件本国提供率:中国,1/3,左右,美国,97%,“,印度模式”还是“中国模式”,软件人才,结构不合理,,,缺乏,中,高级,软,件人才,,软件人员缺乏软件工程化的概念。,“,软件工程,”,课程,与其它软件专业课的区别,(1),立足于系统的整体。,(2),讲授系统分析、系统设计、,测试及维护的理论和方法。,(3),构筑一,个软件,系统,,实践,软件开发全过程,。,“,软件工程,”,课程教学与实践,的目标,转变,对软件的认识:,上升,程序 系统,转变,思维定式:,上升,程序员 系统工程师,(,系统分析员,),工程化训练,系统分析员的地位,用户,分析员,程序员,软件,工程与一般工程的差异,软件是逻辑,产品,而不是,实物,产品,软件的功能依赖于硬件和软件的运行环境以及人们对它的操作,软件设计的复杂性,软件特征:功能的多样性,实现的多样性,能见度低,软件结构合理性差,智力密集及知识产权保护,软件工程,知识结构,软件需求,软件设计,软件构造,软件测试,软件维护,软件配置管理,软件工程管理,软件工程过程,软件工程工具和方法,软件质量,“,一个好的工业,应有一套良好的标准来配套,”,软件的工业化生产过程应具备的特点:,明确的工作步骤,详细具体的规范化文档,明确的质量评价标准,软件工程技术的明显特点,强调规范化,强调文档化,图书管理系统,针对的用户是中型图书室,藏书的种类包括中、英、俄、德、日文书籍,和期刊,读者的数量和来源仅限于本单位职工及通过馆际互借认可的读者。相应的需求有:,能够存储一定数量的图书信息,并方便有效的进行相应的书籍数据操作和管理,这主要包括:,19,图书信息的录入、删除及修改。,图书信息的多关键字检索查询。,图书的出借、返还和资料统计。,图书的远程预约和续借。,馆际互借(通过电子邮件或现场录入),能够对一定数量的读者进行相应的信息存储与管理,这其中包括:,20,读者信息的登记、删除及修改。,读者资料的统计与查询。,能够对需要的统计结果提供打印输出。,能够提供一定的安全机制,提供数据信息授权访问,防止随意删改,同时提供信息备份的服务。,21,应提交的文档,软件需求规格说明书,软件设计规格说明书,用户安装及使用手册,确认测试计划,程序测试计划,演示程序,22,第,1,章 软件工程学概述,1.1,软件危机,1.2,软件工程,1.3,软件生命周期,1.4,软件过程,1.5,小结,23,Evolution of software,早期,第二阶段 第三阶段 第四阶段,面向批处理,多用户,分布式系统,强大的桌面系统,有限的分布,实时,嵌入,“,智能,”,面向对象技术,自定义软件,数据库,低成本硬件,专家系,统,软件产品,消费者的影响,人工神经网络,并行计算,网络计算机,1950,1960,1970,1980,1990,2000,软件技术面临的问题,复杂性,生产率,例,:,Windows,95,有,1000,万行,代码,Windows,2000,有,5000,万行,代码,Exchange2000,和,Windows,2000,开发人员结构,Exchange2000,Windows,2000,项目经理,25,人,约,250,人,开发人员,140,人,约,1700,人,测试人员,350,人,约,3200,人,软件危机的主要特征,软件开发周期大大超过规定,日期,;,软件开发成本严重超标,;,软件质量,难于,保证。,改正一个问题需付出的代价,需,求,分,析,结构设计,详细设计,编码,集成测试,系统测试,现场,改正一个问题的估计费用,改正一个问题估计的工作量,20,200,2000,1000,5.0,2.5,0.05,0.5,(,美元,),(,人天,),成功的标准:,用户在,用,用户可很容易做完要做的事,失败的根本原因:,开发人员写出的东西达不到,用户要求,(,人的问题,.,技术问题,),1.1,软件危机,“软件危机” 成为计算机系统发展瓶颈。,为了更有效地开发与维护软件,消除软件危机,从而形成了一门新兴的工程学科,软件工程学。,1968,年由,NATO (,北大西洋公约组织,),在德国,Garmish,召开的学术会议上,,Feitz,Bauer,首先提出了“软件工程”概念。,30,软件危机典型表现,软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。,(1),对软件开发成本和进度的估计常常很不准确。,(2),用户对“已完成的”软件系统不满意的现象经常发生。,(3),软件产品的质量往往靠不住。,(4),软件常常是不可维护的。,31,(5),软件通常没有适当的文档资料。,(6),软件成本在计算机系统总成本中所占的比例逐年上升。,(7),软件开发生产率提高的速度,远远跟不上计算机应用迅速普及深入的趋势。,软件危机典型表现,32,产生软件危机的原因,与软件本身的特点有关,与软件开发与维护的方法不正确有关,软件专业人员有不少,错误认识(软件神话),软件开发就是写程序,急于编码,忽视软件需求分析的重要性,软件配置可有可无,软件可以随意变更,程序能够运行就可以交付了,无须测试,33,只有看到可运行的程序才能评价软件的质量,发现的错误不急于改正,以后再说,写文档太浪费时间,可有可无,程序交付之后,项目就完工了,轻视软件维护,进度延误,增加人手就行了,做软件是开发人员的事,与客户无关,在实践过程中采用了错误的方法和技术,软件危机的原因,34,消除软件危机的途径,彻底消除 “软件就是程序”的错误观念。,一个软件必须由一个完整的配置组成,软件是程序、数据及相关文档的完整集合。,使用在实践中总结出来的开发软件的成功的技术和方法。,应该开发和使用更好的软件工具。,组织良好、管理严密、各类人员协同配合、共同完成的工程项目。,35,1.2,软件工程,软件工程的定义,概括地说,软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件,把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来,以经济地开发出高质量的软件并有效地维护它,这就是软件工程。,36,软件工程,的定义,Fritz Bauer,在,NATO,会议,上给出的定义:,“,软件工程,是,为了经济地获得可靠的和能在实际机器上高效运行的软件,而确立和使用,的,健全,的工程,原理(方法),。,”,软件工程,的定义,IEEE,【IEE83】,给出的,软件工程,定义:,“,软件工程是,开发、运行、维护和修复软件的系统方法,。,”,软件工程,的定义,IEEE,【IEE93】,给出了一个更加综合的定义:,“,将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程,即将工程化应用于软件中,。,”,软件工程,的定义,软件工程是应用计算机科学、数学及管理科学等原理开发软件的工程。它借鉴传统工程的原则、方法,以提高质量,降低成本为目的。,软件工程是一门交叉学科,软件工程的主要研究内容,软件开发,技术,:,软件开发方法,学,软件开发过程,软件工具,和软件工程,环境,软件工程管理,:,软件管理,学,软件经济学,软件,心理学,软件工程的本质特征,软件工程关注于大型程序的构造,软件工程的中心课题是控制复杂性,软件经常变化,开发软件的效率非常重要,和谐地合作是开发软件的关键,软件必须有效地支持它的用户,在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人,42,用分阶段的生命周期计划严格管理,坚持进行阶段评审,据统计,设计错误占软件错误的,63%,,编码错误仅占,37%,;,错误发现与改正得越晚,所需付出的代价也越高。,尽早发现在软件开发过程中所犯的错误,是一条必须遵循的重要原则。,实行严格的产品控制,实行基准配置管理,软件工程的基本原理,43,采用现代程序设计技术,结果应能清楚地审查,开发小组的人员应该少而精,承认不断改进软件工程实践的必要性,软件工程的基本原理,44,软件工程方法学三个要素,工具,方法,过程,质量焦点,Software Engineering layers,1.,传统方法学,也称为,生命周期方法学,或,结构化范型,采用结构化技术,(,结构化分析、结构化设计和结构化实现,),开发,把软件生命周期的全过程依次划分为若干个顺序阶段,有依赖关系,从对问题的抽象逻辑分析开始进行开发,在每一个阶段结束之前都必须进行正式严格的技术审查和管理复审,46,2.,面向对象方法学,把数据和对数据的操作紧密地结合起来,4,个要点:,对象、类、继承、消息,开发过程是迭代无间隙的演化过程。,最终的软件产品由对象组成,大多数对象都与现实世界中的实体相对应,降低软件产品的复杂性,提高可理解性,简化开发维护,提高可重用性,47,1.3,软件生命周期,软件定义,问题定义,可行性研究,需求分析,软件开发,系统设计:总体设计、详细设计,系统实现:编码和单元测试、综合测试,运行维护,(,也称为软件维护,),48,各阶段基本任务,问题定义,“,要解决的问题是什么,?”,可行性研究,“对于上一个阶段所确定的问题有行得通的解决办法吗,?”,需求分析,“为了解决这个问题,目标系统必须做什么?”,总体设计(,概要设计,),“概括地说,应该怎样实现目标系统,?”,详细设计,“应该怎样具体地实现这个系统呢,?”,49,编码和单元测试,写出正确的容易理解、容易维护的程序模块。,综合测试,通过各种类型的测试,(,及相应的调试,),使软件达到预定的要求。,软件维护,通过各种必要的维护活动使系统持久地满足用户的需要。,各阶段基本任务,50,1.4,软件过程,软件过程,为了获得高质量软件所需要完成的一系列任务的框架,它规定了完成各项任务的工作步骤。,过程模型(生命周期模型),规定了把生命周期划分成哪些阶段及各个阶段的执行顺序。,不是针对某个特定项目,只能使用“通用的”阶段划分方法。,51,1.4.1,瀑布模型,52,瀑布模型特点,1.,阶段间具有顺序性和依赖性,2.,推迟实现的观点,3.,质量保证的观点,4.,文档驱动,5.,过于理想化,6.,不易于变更,53,改进的瀑布模型,54,1.4.2,快速原型模型,所谓快速原型是快速建立起来的可以在计算机上运行的程序,它所能完成的功能往往是最终产品能完成的功能的一个子集。,第一步是快速建立一个能反映用户主要需求的原型系统,用户试用,了解目标系统的概貌,根据用户反馈的意见快速地修改原型,线性开发,55,图,1.4,快速原型模型,56,1.4.3,增量模型(渐增模型),把软件产品作为一系列的增量构件来设计、编码、集成和测试。,每个构件由多个相互作用的模块构成,并且能够完成特定的功能。,使用增量模型时,第一个增量构件实现软件的基本需求,提供最核心的功能。,完成的增量逐步集成,难点在于如何划分增量,57,增量模型,1,58,增量模型,2,59,1.4.4,螺旋模型,基本思想:使用原型及其他方法来尽量降低风险。,增加了风险分析,主要适用于内部开发的大规模软件项目。,风险驱动,不易于把握,较为复杂,对经验要求较高,60,简化的螺旋模型,61,完整的螺旋模型,62,1.4.5,喷泉模型,进一步开发,实现和集成阶段,运行状态,实现阶段,面向对象设计阶段,计划阶段,面向对象分析阶段,需求阶段,维护期,喷泉模型特点,主要用于支持面向对象开发过程体现了软件创建所固有的,迭代,和,无间隙,的特征。,1.4.6 Rational,统一过程,最佳实践,迭代式开发,管理需求,基于构件的体系结构,可视化建模,验证软件质量,控制软件变更,2. RUP,软件开发生命周期,65,RUP,软件开发生命周期,66,1.4.7,敏捷过程与极限编程,敏捷过程,轻量级软件工程,个体和交互胜过过程和工具,可工作的软件胜过面面俱到的文档,客户合作胜过合同谈判,相应变化胜过遵循计划,67,极限编程,有效实践,客户是开发团队的成员,短交付周期,验收测试,结对编程,测试驱动开发,集体所有,持续集成,可持续的开发速度,及时调整计划,简单的设计,重构,使用隐喻,68,XP,项目的整体开发过程,69,XP,迭代开发过程,70,1.4.8,微软过程,微软过程准则,微软软件生命周期,71,微软过程的生命周期模型,72,可重用部件组装模型,使用重用技术的软件工程模型,构件,(,components,),:,可重用的软件成份,可复用性,(,Reusability,),(,可重用性),集成化软件开发环境,(,ISEE,),可重用部件组装模型,系统,A,的,软件构成,系统,C,的,软件构成,系统,B,的,软件构成,可重用,部 件,可重用,部 件,软件生产线,应用构件,提取车间,应用,构件库,构件生,产车间,构件库,组装,车间,领域,1,领域,2,应用,系统,.,1,2,3,4,1,基础构件,,2,功能构件,3,接口构件,,4,用户界面构件,75,思考题,教材,P32,习题,1,第,2,题、第,7,题,76,
展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 图纸专区 > 小学资料


copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!