软件工程Software Engineering,计算机学院 软件工程课程组,一、课程性质,计算机科学与技术专业 必修课 信息安全专业 选修课 54学时，3学分 二、 教学目的 从工程化角度培养学生从事大型软件特别是对象式系统开发方法、模型、软件测试、维护与管理的实际动手能力-软件工程师 讲授与学生选择实际软件项目按工程化方法实践相结合,教材,软件工程原理及应用 陈世鸿等 武汉大学出版社,参考书,软件工程导论 张海藩 清华大学出版社,SOFTWARE ENGINEERING A Practitioners Approach Roger S. Pressman 清华大学出版社,要求与评分,评分：总分=实践分30+考试( 闭卷)成绩70% 课程实习要求,分组：4人一组，组长一名、组员3名 选题：选择一个有实用背景的中、小型课题 完成的任务：软件开发计划、需求分析文档、概要设计文档、测试计划与测试报告 交选题时间：第2周星期5(项目名称，成员及分工),计算机系统,计算机系统的实质是模拟或延伸 人对主客观世界问题的求解 如何模拟与延伸主客观世界，其表示方法与工具(软件)是关键，其核心工具是语言。,裸 机,系 统,支持 软件,表示与处理,需求解 问题,计算机系统,硬件 摩尔法则(戈登-摩尔) 1929年出生,英特尔公司的创始人之一和名誉董事会主席，摩尔早在1965年就预言，半导体芯片上的晶体管数量，即芯片的总体性能将每两年增加一倍。随后摩尔又预言上述晶体管数量将每20个月增加一倍，这就是著名的“摩尔法则”。在此后的40年里，摩尔法则一直有效，而且成为推动计算机芯片业发展的一大动力. 摩尔法则至少未来十年内依然有效 . 计算机工程技术人员必须集中精力研究克服能量外泄和减少散热的 课题。 软件 开发生产率低，总不能跟上用户需求，质量差 难以维护,第1章绪论,什么是软件？有何特点？ 软件的发展？ 何谓软件危机？如何解决？ 软件工程？ 什么是软件的生存期？ 有哪些软件开发模型？,一、软件及其发展,软件的组成 软件的特点 软件的发展,软件工程里程碑,60多年前，计算机科学从电子学中脱颖而出 为克服以手工作坊方式生产软件带来的软件危机，1968年在原西德召开的北大西洋公约组织会议上，第一次提出了软件工程的概念。 软件从硬件中脱颖而出，软件工程从计算机体系结构中脱颖而出,1984年卡内基梅隆大学创立软件工程研究所 1985年我国科学院、北京大学、南京大学、武汉大学等筹建软件工程研究室。 软件工程国家重点实验室（武汉大学） 计算机软件新技术国家重点实验室（南京大学） 软件开发环境国家重点实验室（北京航空航天大学） 计算科学国家重点实验室（中科院软件所）,软件工程40年的尴尬,软件附属于硬件,现在,50年代,60年代,70年代,80年代,90年代,面向 过程,面向 对象,面向 构件,面向 领域,复杂系统 复杂网络,软件作为单独产品，催生软件工程,面向 大众,科学家们对软件工程的关注域总是“与时俱进” 网络时代迫使软件工程寻找新的解决办法,40年软件工程的发展一直以自我为中心,计算机以单机工作为主 软件开发从编码开始 程序规模由小到大 很少考虑本系统之外的事情,程序正确性证明在软件工程中没有彻底解决 软件工程师的知识和智能始终无法从编程过程中剥离出来 任何编程技巧都没有能够带来程序生产率成数量级的提高 软件全自动化生产没有能够实现,对软件开发工作量的再认识,10人 100个月 100人 10个月, 图灵奖获得者 Frederick P. Brooks,1. 软件的组成,程序按事先设计的功能和性能要求执行的指令序列 文档与程序开发，维护和使用有关的图文材料 数据使程序能正常操纵信息的数据结构,software = program software developing = programming/coding,1. 软件的组成,20世纪50年代：software = program 20世纪60年代：software = program + documents 20世纪70年代：software = program + documents + data,software = program + documents + data software developing programming/coding,文档,分类 开发文档 管理文档,作用 记录 通信和交流 管理和维护,2. 软件的特点,更依赖于人 开发成本、进度难估计 正确性难保证 维护困难 纠错性维护 完善性维护 适应性维护 预防性维护 不磨损、不老化,软件可长期使用,3. 软件开发的三个发展阶段,程序 用程序设计语言描述的，适合于计算机处理的语句序列,二、软件危机与软件工程,软件危机（Software Crisis） 计算机软件的开发和维护过程中所遇到的一系列严重问题。 软件萧条 depression 软件困扰 affliction 软件工程（Software Engineering，SE） 1968，NATO，Fritz Bauer提出,1. 软件危机,含义 表现 原因 克服危机的途径,（1）软件危机的含义,如何开发软件，满足需求 如何维护已有软件,（2）软件危机的表现,难于控制开发进度 进度拖延，成本失去控制 损害软件质量，引起用户不满 软件开发中人的因素导致,对项目进度和工作量估计的“二八定律”： 一般人主观上认为已经完成了80，但实际上只完成了20。,（2）软件危机的表现,软件工作量估计困难 如果有一个软件项目，估计需要12人月工作量。指定由3个人，在4个月内完成。假定第一个月的任务花了两个月才完成，则管理者该怎么办呢？ Brooks：“在已拖延的软件项目上，增加人力只会使其更难按期完成。 ”,(2) 软件质量现状,（2）软件危机的表现,软件修改、维护困难,19761981数据：维护成本约占总成本的67%,“纠正一个错误带来更多新错误 ” “错误发现得越晚，纠正错误所要付出的代价也就越大 ” 维护成本所占比例大,（3）原因,需求问题 用户描述不精确 开发人员理解不一致、随意性大 管理问题 “软件开发离不开管理！” 方法、工具问题 局限性,（4）克服危机的途径,工程的概念、原理、技术和方法 软件的开发、管理和维护,2. 软件工程,研究“大型”软件开发和维护的模型、技术、方法、工具、环境和管理的工程学科。,软件工程的定义,1983年IEEE：“软件工程是开发、运行、维护和修复软件的系统方法。” Fairly：“软件工程学是为了在成本限额以内按时完成开发和修改软件产品所需要的系统生产和维护技术及管理学科。” Fritz Bauer：“软件工程是为了经济地获得可靠的且能在实际机器上有效地运行的软件，而建立和使用的完善的工程化原则。” 1993年IEEE：软件工程是：把系统化的、规范的、可度量的途径应用于软件开发、运行和维护的过程，也就是把工程化应用于软件中；研究中提到的途径。,软件工程框架,软件工程三要素,以有组织的质量保证为基础 软件工程过程是进行一系列有组织的活动，从而能够合理地和及时地开发出计算机软件 软件工程方法为软件开发提供“如何做”的技术 软件工具为过程和方法提供自动的或半自动的支持 计算机辅助软件工程（CASE，Computer Aided Software Engineering）,三、软件的生存期（Software Life Cycle）,软件产品从形成概念开始，经过开发、使用和维护，直到最后退役的全过程。 生命周期方法学 “各个击破”、“分而治之”的思想 里程碑（Milestone） 软件生存期中各开发阶段末尾的特定点,软件生存期的3个时期、6个阶段,维护,软件的生存期,各阶段工作量百分比图,需求20,设计15,编码20,单元测试25,联合测试20,生命周期方法的特点,顺序性、依赖性 推迟程序的物理实现 质量保证的观点（利于尽早发现错误） 阶段文档 评审,错误的“积累效应”和“放大效应”,大部分的错误是在编码之前造成的 错误发现、改正得越晚，需付出的代价越高,发现并改正一个错误的开销,四、软件生产过程模型,软件开发全部过程、活动和任务的结构框架。 普遍适用的框架，而非具体的方法 作用 描述各阶段关系 为软件工程管理提供里程碑和进度表 为开发过程提供原则和方法,1. 编码修正模型（code and fix model）,软件开发只有两个阶段 编写程序代码 修改程序代码 作坊式生产方式 缺点 低估设计，代码结构差，难修改 不重视需求，开发风险大，用户不满意 难修改、难维护,2. 瀑布模型（Waterfall Model）,1970，W. Royce提出 软件生存周期模型，流水式过程模型 生命周期方法学 阶段划分方法 控制复杂性,Definition,Feasibility Study,Requirements Analysis,System Design,Program Design,Coding & Module Testing,Integration & System Testing,Delivery & Maintenance,System Lifecycle,Waterfall Model,传统的瀑布模型,瀑布模型的特点,基本思想：“分而治之” 优点 规范管理开发过程 文档驱动 缺点 初期系统的需求难于完全确定 文档驱动 周期长,传统的瀑布模型,带“反馈环”的瀑布模型,V型模型（瀑布模上加质量控制）,用户需求,需求分析文档,概要设计文档,详细设计与编码,环境（适应性）测试,系统测试,联合测试,单元测试,测试阶段,构造阶段,试用与维护,瀑布模型的特点,适用范围 结构化方法，面向过程的软件开发方法 需求变化少 开发人员熟悉应用领域 低风险项目 使用环境稳定,3. 原型模型（Prototyping Model）,针对：软件开发初期需求难以确定 工程上经常使用的“原型” 快速原型法（Rapid Prototyping） 基本思想：快速建立原型，完善用户需求,原型模型,Prototyping Model,需求的采集和细化,快速设计,建造原型,客户评价原型,针对原型 完善需求,生产样品,开始,停止,快速开发原型的途径,模拟软件系统的人机界面和人机交互方式 开发工作原型，实现软件系统的部分功能 找来正在运行的类似软件,原型模型的特点,优点 用户参与 快速 缺点 快速 对开发环境要求高,适用范围 已有产品（原型） 简单而熟悉的领域 有快速原型开发工具 进行产品移植或升级,软件开发的风险,产品交付给用户之后用户可能不满意 到了预定的交付日期软件可能还未开发出来 实际的开发成本可能超过预算 产品完成前一些关键的开发人员可能“跳槽”了 产品投入市场之前竞争对手发布了一个功能相近、价格更低的软件,4. 螺旋模型（Spiral Model）,1988，TRW公司BARRY W. Boehm提出 风险分析,Waterfall Model,Prototyping Model,Risk Analysis,Spiral Model,螺旋模型的特点,针对：前面的模型没有提供“驾驭软件风险”的功能 基本思想：降低风险 制定计划 planning 风险分析 risk analysis 实施工程 engineering, construction and release 客户评估 customer evaluation,PART ONE The Process,Spiral Model,Risk analy-sis,Prototype 1,Simulations, models, benchmarks,Requirements plan, life-cycle plan,Concept of operation,Prototype 2,Risk analysis,Software requ