软件工程-第1章：软件工程学概述

软件工程,课程简介,课程类型：专业课/考试课学时：48学分：3.5课程考核形成性考核30%终结性考核70%,形成性考核100,终结性考核：闭卷范围：课堂内容、作业要求：认真做笔记,9,2020/5/30,第一章软件工程概述,水利工程,建筑工程,机械工程,软件工程,传统工程,新兴工程,气象工程,生物工程,1.什么是软件？,Soft+ware,软制品(软体),软件是计算机系统中与硬件相互依存的另一部分是程序、数据及其相关文档的完整集合,2.软件特点,软件是一种逻辑实体，而不是具体的物理实体软件的生产方式与硬件不同不存在像硬件一样的磨损和老化问题,磨合调整,磨损用坏,修改点,实际曲线,理想曲线,成本昂贵软件技术的发展落后于需求软件成本比例增大,程序,3.软件的演变,软件,软件产品,传统软件开发,现代软件开发,计算机系统的发展经历了四个不同的时期，软件生产方式随着计算机系统的发展经历了三个阶段：,4.软件的生产方式的演变,个体化生产作坊式生产产业化生产,程序规模小、软件设计是一个隐含过程,软件危机产生,软件工程出现,开发软件并不一定很难，难就难在如何开发有用的软件。,微软凌小宁博士,我们研究的技术和产品有没有需求才是成功的关键,微软张益肇博士,美国IBM公司在1963年至1966年开发的IBM360机的操作系统。这一项目花了5000人一年的工作量，最多时有1000人投入开发工作，写出了近100万行源程序。.据统计，这个操作系统每次发行的新版本都是从前一版本中找出1000个程序错误而修正的结果。.,这个项目的负责人F.D.Brooks事后总结：“.正像一只逃亡的野兽落到泥潭中做垂死的挣扎，越是挣扎，陷得越深，最后无法逃脱灭顶的灾难。.程序设计工作正像这样一个泥潭，.一批批程序员被迫在泥潭中拼命挣扎，.谁也没有料到问题竟会陷入这样的困境.”。IBM360操作系统的历史教训成为软件开发项目的典型事例为人们所记取。,软件危机,软件危机,软件危机（softwarecrisis）是指在计算机软件的开发和维护过程中所遇到的一系列严重问题,1.1软件危机,1.软件危机的表现,（1）软件成本日益增长（2）软件开发进度难以控制（3）软件质量差（4）软件维护困难,美国空军计算机系统,（1）软件成本日益增长,IBMOS/360,5000多人，耗时4年(19631966)，耗资5亿美元,美国空军：1955年软件占总费用(计算机系统)的18%，70年60%，85年达到85,现在90%,美国全球军事指挥控制系统，硬件1亿美元，软件高达7.2亿美元,软件开发需建立庞大的逻辑体系用户需求变化等各种意想不到的情况层出不穷盲目增加软件开发人员并不能成比例地提高软件开发能力,（2）开发进度难以控制,案例：丹佛新国际机场该机场可全天侯同时起降三架喷气式客机；投资1.93亿美元建立了一个地下行李传送系统，总长21英里，有4,000台遥控车，可按不同线路在20家不同航空公司柜台、登机门和行李领取处之间发送和传递行李；该系统拥有5,000个电子眼、400台无线电接收机、56台条形码扫描仪和100台计算机。按原定计划要在1993年万圣节前启用，但一直到1995年2月28日，在延期16个月后开始启用。,据统计：只有15%的项目是按计划完成的,软件项目即使能按预定日期完成，结果却不尽人意。1955年至1970年，美国范登堡基地发射火箭多次失败，绝大部分故障是由应用程序错误造成的。在“软件作坊”里，由于缺乏工程化思想的指导，程序员习惯性地以自己的想法去代替用户对软件的需求，软件设计带有随意性，这是造成软件不能令人满意的重要因素。,（3）软件质量差,（4）软件维护困难,资料表明：维护软件支付的费用占全部硬件和软件费用的40%-75%,软件维护的多样性软件维护的复杂性软件维护的副作用,不重视早期修改，在软件开发的不同阶段进行修改需要付出的代价不同；,2.软件危机的原因,用户需求不明确缺乏正确的理论指导软件规模越来越大软件复杂度越来越高,用户不清楚软件的具体需求用户对软件需求的描述不精确在软件开发过程中，用户需求变化（功能、界面、支撑环境）开发人员与用户对需求的理解有差异,（1）用户需求不明确,缺乏有力的方法学和工具方面的支持。软件过程是复杂的逻辑思维过程，产品质量极大地依赖开发人员智力投入、技巧和创造性，这加剧软件产品的个性化。,（2）缺乏正确的理论指导,规模增大,范围增大,人员数量增加,开发人员不能有效地、独立自主地处理大型软件的全部关系和各个分支，容易产生疏漏和错误。,（3）软件规模越来越大,管理人员缺乏开发经验开发人员缺乏管理经验,信息交流不畅会产生误解,（4）软件复杂度越来越高,先进的组织形式开发方法和工具,新的、更大的更复杂的问题,认识：我们面临的不仅仅是技术问题，更重要的是管理问题,软件危机,3.如何克服软件危机,软件工程方法学:用工程的方法和技术研究软件开发与维护的方法、工具和管理的一门交叉学科程序设计方法学:用数学的方法研究程序的性质以及程序设计的理论和方法的学科,软件工程,方法,工具,过程,:技术手段-“如何做”的技术,:软件支撑环境,:将方法和工具综合起来,推广成功的技术和方法探索更有效的技术和方法,开发和使用更好的软件工具,良好的组织管理措施,什么是CASE,CASE（ComputerAidedSoftwareEngineering）是一组工具和方法的集合，用于辅助软件开发、维护、管理过程中的各项活动，促进软件过程的工程化和自动化。,CASE作用,系统模型的图形编辑器设计实体管理的数据字典用户界面GUI生成辅助生成系统文档的报告生成器支持程序纠错的调试器代码生成器,软件开发过程与管理,CASE的层次,分析设计工作台,集成化环境,程序设计工作台,测试工作台,CASE工具,IBMRational公司产品,-开发过程管理：RUP-需求管理：RequisitePro-可视化建模：Rose-自动测试：Robot,TestRealtime,TestManager,XDETester-项目管理：ProjectConsole-配置管理：ClearCase,ClearQuest,开源CASE工具（,-CVS:应用广泛的版本管理工具-UMLModeler:UML模型图形编辑工具-UML2EJB:将XML表示的UML模型转换成EJB代码的转换器,-SoftwareEngineering,1968年NATO组织在德国召开的一次会议上提出,是把软件当作一种工业产品，要求“采用工程化的原理与方法对软件进行计划、开发和维护”。,1.2软件工程,1.软件工程的介绍,软件工程学,软件开发技术,软件工程管理,软件开发方法学,软件工具,软件工程环境,软件工程管理学,软件经济学,软件工程学的范畴,微软企业文化宗旨部分内容,当我们每天早上醒来时，都要拥有这样的激情用技术去改变人们生活,WakeupeverydaywithafeelingofpassionforthedifferenttechnologywillmakeinpeoplesLife.,关注于大型程序的构造；中心课题是控制复杂性；软件经常变化；开发效率非常重要；和谐地合作是开发的关键；必须有效地支持它的用户；是具有一种文化背景的人替具有另一种文化背景的人创造产品。,2.软件工程的本质,3.软件工程的基本原理,分阶段的生命周期管理；坚持阶段评审；实行产品控制；采用现代程序设计技术；结果能清楚地审查；开发小组的人员应该少而精；持续不断地改进软件工程实践。,4.软件工程方法学通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学，也称为范型。,方法是主导，工具是辅助,软件工程：一种层次化技术,质量核心层,软件工程框架,（1）传统方法学也称为生命周期方法学或结构化范型。结构化方法（StructureMethod）有：1）结构化设计方法（SD）；2）结构化分析方法（SA）；3）结构化分析与设计技术（SADT）4）JACKSON方法5）WARNIER方法,（2）面向对象方法学把数据和对数据的操作紧密结合起来的方法，模拟人类认识世界解决问题的方法和过程。面向对象的方法=对象（属性与服务的封装）+分类+继承+通过消息的通讯,适用于实时事物处理系统的有限状态机方法（FSM）；适用于并发软件系统的Petri网方法；以数学概念和理论为基础的形式化方法，如SDC公司的形式化开发方法FDM：（FormalDevelopmentMethodology）IBM公司的维也纳开发方法VDM：（ViennaDevelopmentMethod）,（3）其它方法,软件生命周期组成：1）软件定义；A.问题定义B.可行性研究C.需求分析2）软件开发；D.总体设计E.详细设计F.编码和单元测试G.综合测试3）运行维护。,1.3软件生命周期,1.问题定义；2.可行性研究；3.需求分析；4.总体设计（概要设计）；5.详细设计；6.编码与单元测试；7.综合测试；8.维护。,软件生命周期各个阶段：,1.4软件过程,为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。,ISO9000的定义使用资源将输入转化为输出的活动所构成的系统输入：如软件需求输出：如软件产品,1.瀑布模型,1970年由W.Royce提出软件生存周期分为计划时期、开发时期、运行时期。提供了软件开发的基本框架，非常有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究与使用，从而大大提高了大型软件项目开发的质量和效率。,上一阶段的变换结果是下一阶段的变换的输入，相邻两个阶段具有因果关系，紧密相联。,需求分析,问题定义,可性行研究,概要设计,详细设计,编码,测试,运行与维护,（1）特点阶段间的顺序性、依赖性推迟实现的观点质量保证的观点文档驱动阶段性验证,传统的瀑布模型,开发期内需求基本不变对熟悉的应用领域风险低（熟悉的目标、环境）稳定的用户环境用户基本不参与开发,实际的瀑布模型,（2）选择模型的条件,（3）缺点可维护性差逆转性差，返工损失大错误的传递造成发散扩大测试是最后环节,2.快速原型模型,RapidPrototypeModel，简称原型模型,模型本意用户开始阶段提出的需求比较模糊，很难一次性把其真实的要求提交给软件公司。“样机”思想,原型系统仅包括未来系统的主要功能，以及系统的重要接口。为了尽快向用户提供原型，开发原型系统时应尽量使用能缩短开发周期的语言和工具。,模型原则,（1）选择模型的条件已有产品或产品的原型，只需客户化的项目；简单而熟悉的行业或领域；有快速原型开发工具；进行产品移植或升级。在熟悉的业务领域，制作投标书，讲标投标。后期再进行二次开发。,（2）优点需求驱动客户能很好理解软件原型能很好确认需求快速建模，快速修改反映软件本质开发的反复,（3）缺点功能的折中可能采用不合时宜的系统或语言交流频繁不利于开发人员的创新,3.增量模型,针对每个构件，完成设计、编码、集成和测试后交付用户,维护,模型的本意主体模块+增量模块搭积木式开发,风险更大的增量模型,规格说明,构件1,设计,编码集成,交付用户,规格说明,构件2,设计,编码集成,交付用户,规格说明,构件n,设计,编码集成,交付用户,任务或功能模块驱动，可以分阶段提交产品；多个任务单，这些多个任务单的集合，构成项目的一个总任务书(总用户需求报告)；短时间内能提交部分产品；用户有充裕的时间学习和适应新产品。,（1）模型的特点,在项目开发过程中，客户接受分阶段交付；开发人员对应用领域不熟悉，难以一步到位；工期过紧的中等或高风险项目；用户可参与到整个软件开发过程中；使用面向对象语言或第四代语言；软件公司自己有较好的类库、构件库。,（2）选择模型的条件,（3）模型的缺点以下情况不宜使用本模型:软件系统的组装和拆卸性不强；开发人员全局把握水平不高（没有数据库设计专家进行系统集成）；客户不同意分阶段提交产品；开发人员过剩。,4.RAD模型（V模型）,快速应用开发（RapApplicationDevelopment,RAD）,业务建模数据建模处理建模应用生成测试反复,顺序开发基于构件速度快,RAD改进模型（V模型）,需求分析,概要设计,详细设计,代码实现,验收测试,系统测试,集成测试,单元测试,确认测试集成,系统测试执行,集成测试执行,单元测试执行,组件测试执行,RAD改进模型（V模型）,需求分析,概要设计,详细设计,代码实现,验收测试,系统测试,集成测试,需求测试,概要设计测试,详细设计测试,单元测试,系统安装,系统构建,模块集成,RAD改进模型（W模型）,RAD改进模型（V模型）,（1）优点开发速度快，质量有保证；对信息系统特别有效。（2）缺点只能用于信息系统；较大的项目需要足够的人力资源去建造RAD组；沟通需要快速高效；对模块化要求较高；技术风险很高的情况下不适合这种模型。,5.螺旋模型,增加风险分析的快速原型模型,模型的本意：尽量降低风险,每一个周期都应用了原型模型排除风险；每旋转一个圈就前进一个次，得到一个新的版本；强调可选方案和约束条件有利于软件重用；减少测试过多或不足带来的风险；维护看成是模型的另一个周期；需要开发人员有丰富的风险评估经验和相关专门知识。,（1）特点,有利于已有软件的重用有助于把软件质量作为软件开发的目标减少了过多测试或测试不足所带来的风险软件维护与软件开发没有本质区别,（2）模型的优点,（3）模型的局限使用螺旋模型开发软件，要求软件开发人员具有丰富的风险评估知识和经验（4）模型的适用范围主要适用于内部开发的大型软件项目,6.喷泉模型,典型的OO软件开发过程模型过程迭代与无缝衔接活动间的交迭与无缝过渡活动内部的迭代求精维护时间明显减少找到一个线性目标,喷泉模型,（1）RUP软件开发经验迭代式开发需求管理基于构件的体系结构可视化建模贯穿于开发过程的质量验证变更控