UML第二讲软件工程概述.ppt

《UML第二讲软件工程概述.ppt》由会员分享，可在线阅读，更多相关《UML第二讲软件工程概述.ppt（118页珍藏版）》请在三一办公上搜索。

1、1,第二讲软件工程概述,2,主要参考书,软件工程教程 张敬、宋广军、赵硕、王睿编著 北京航空航天大学出版社 2003.7软件可靠性何国伟 主编国防工业出版社 1998.1,3,主要内容,软件标准与规范,软件管理,4,作业,UML与软件工程谈谈你所参与过的软件开发项目中遇到的问题和解决的方法软件工程发展史综述软件需求分析方法综述以上任选一题，也可以自选题目。内容不少于1000字，2周内交。,5,作业要求,格式：题目作者摘要内容引言、问题、方法、结论参考文献提交地址：文件名：姓名+第几次作业,6,前言,软件开发现状与问题软件工程的目的和内容谁需要软件工程,7,规模大、功能复杂、分布式、并发、团体开

2、发等,软件开发现状,8,程序+数据+文档,软件常见的问题,什么是软件？1.程序存在的问题2.文档存在的问题3.管理存在的问题4.软件质量问题,9,程序存在的问题,一大：一个函数几百行、甚至5000行（多少行合适？）二乱：程序结构乱、乱修改三无：无注释、无控制、无管理（多少注释量合适？）三自：自编、自导、自演（1）透明度很差，没有齐全的技术资料；（2）软件交付系统联试前只靠自检，质量可靠性得不到保证；（3）用户对交付的软件可靠性缺乏信心。,10,文档存在的问题,三无：无需求说明书、无设计文档、无使用及操作手册按GJB438-88军用软件文档编制规范，文档有13种：1.可行性研究报告、2.软件项目

3、开发计划、3.软件需求说明、4.数据要求说明、5.概要设计说明、6.详细设计说明、7.数据库设计说明、8.用户手册、9.操作手册、10.程序维护手册、11.测试计划、12.测试分析报告、13.安装实施过程。后补文档：无用文档,11,管理存在的问题,三无管理：无计划、无控制、无改进人、经费、软硬件设备与平台、时间、过程、据统计60%项目延期，1030%项目失败！参与人员（单位）多：协同、管理进度不协调第三方测试仍有相当的阻力预算经费一再突破，研制周期一再拖延，产品质量没有保证甚至几乎不能用。,12,据IBM360操作系统研制的第一位负责人总结的经验，假设编写若干单独完成某功能的程序的工作量为1，

4、则把这些程序组成程序系统的工作量为3，而要把这个程序系统变成产品则工作量为9。,软件管理工作与项目规模的关系,13,软件质量问题,软件质量问题占软硬件问题总数的2/3与用户需求不符：（1）使用方提出的用户需求是不完整的，有遗漏的。（2）需求“误解”，软件工厂误解了使用方需求。（3）软件工厂没有完全实现使用方需求或潜在的需求。（4）概要设计没有完全实现需求规范，详细设计没有完全实现概要设计规范，编程没有完全实现详细设计规范等等。（5）选用了不完整或不正确的算法或判别逻辑等等。（6）人为疏漏。如抄录错误等等。,14,软件质量问题（续1）,错误数量居高不下著名案例：IBM OS/360，2000Bu

5、gs/Year，在花费了上千人年的开发成本以及不断修正后，该操作系统终因错误过多、性能不稳定而被放弃。这种现象在20世纪60年代引起了业内人士高度重视，导致软件工程研究的诞生，成为软件质量工作历程中的重要里程碑。IBM OS/400:改一个错误，出现三个错误,15,软件质量问题（续2）,我国的软件还没有像硬件那样有完善的检验体系，因此交付软件的质量不高。典型的统计表明，在开发阶段，平均每千行代码有5060个故障，交付后平均每千行代码有1518个故障。交付的软件有时留下很严重的隐患。据统计60%软件项目延期，10-30%项目失败！,16,软件质量造成影响的实例,海湾战争期间，“爱国者”防空系统有

6、一次未能成功地拦截“飞毛腿”导弹，造成军营被炸，28名英军死亡，其原因是其跟踪软件在运行100h后出现了一个0.36s的舍入误差。1996年6月4日，阿里安娜5型运载火箭在首次发射时，由于软件质量问题，在火箭升空约40s时，在大约4000m的高空，火箭开始偏离飞行轨道，随后发生爆炸。火箭碎片散落在发射塔以东约12km2的土地上，价值5亿英镑的火箭灰飞烟灭。中航某型号飞机首飞前航电系统在地面DSI平台上测试出了800个故障。其中：软件故障600个（占75%），元器件故障127个（占16%），其它故障73个（占9%）。,17,Software Engineering,预算经费一再突破，研制周期一再

7、拖延，产品质量没有保证甚至几乎不能用的现象在60年代迅速增多，严重影响了计算机应用的发展，终于在60年代末两次北大西洋公约组织的科技工作会议上，专家们明确指出了这是“软件危机”，集中研究了对策，明确提出，必须根本改变过去那种手工业作坊式的开发方式，而采用与机械工程类似的工程方法，人们称之为“软件工程”。,18,软件工程与软件危机,19,60年代编程特点,对软件开发的理解就是编程序。重视编程技巧，编程是在一种无序的、祟尚个人技巧的状态中完成的。软件规模相对较小。缺少有效方法与软件工具的支持。工作好的人与工作差的人，在软件(程序)生产效率上的比例是10：1，在程序处理速度和存储容量上的比例是5：1

8、。产品的结果是程序编程人员需要掌握的主要技术是数据结构和算法强调空间(内存)和时间(速度)祟尚个人编程技巧,20,70年代编制软件的特点,硬件性能价格比每十年提高一个数量级，导致计算机在应用上大量普级。软件规模开始加大。编制软件已不再是个人能够完成的事情，开始需要多人合作。产品的结果是软件编程人员需要掌握的主要技术除了数据结构和算法外还要加上文档(程序+文挡),21,80年代编制软件系统的特点,计算机性能越来越高，价格更加便宜，应用更加广泛。信息的作用和优势逐渐显现软件规模越来越大导致需求越来越复杂产品的结果是软件系统分析与设计方法,构造模型成为主流编程人员需要掌握的主要技术是软件开发方法(如

9、何做）,22,90年代复杂软件系统的特点,企业竞争越发明显社会变革速度加快、周期缩短。信息已作为有巨大价值的产品来对待导致需求越来越复杂和经常需要变更。产品的结果是复杂软件系统软件人员需要掌握的主要技术除了软件开发方法之外还需要学习和掌握软件过程的知识。,23,21世纪软件产品的特点,面向对象的软件开发概念及工具构件、接口、中间件技术软件复用软件开发过程及软件项目管理技术,24,软件产品发展的特征变化,时间特征产品特征技术特征知识特征行为特征,25,程序,软件,构件系统,软件系统,复杂系统,60年代 70年代 80年代 90年代 21世纪,数据结构+算法 程序+文档 开发方法 过程思维 自动化

10、生产,产品特征,时间特征,技术特征,时间空间编程技巧,软件可视化表示,概念工具过程管理,如何做软件建模技术,复用组装技术,个人行为,小组行为,组织行为,团队行为,行为特征,知识特征,软件系统的规模、需求复杂度与变更,26,过去软件生产方式存在的问题,程序制作过程全在开发者个人脑子里，别人看不见，摸不着，无法进行管理和控制，俗称“不透明”。依靠个人技巧的艺术品即使单独看来非常出色，但很难把这些各有特色的人和作品组合起来。忽视了软件产品开发中在编程前后更大量、更关键的工作。,27,软件危机的特点,软件危机：60年代末质量差成本高进度慢维护难管理弱,28,？,什么是好的软件产品？,29,软件质量,质

11、量：实体满足规定和潜在需要能力的特性之总和。软件质量：反映软件产品满足规定和潜在需要能力的特性的总和，描述和评价软件产品质量的一组属性叫“软件质量特性”。按ISO/IEC9126-91，软件质量可定义为六个特性及21个子特性。,30,软件质量,功能性(functionality)适用性(suitability)准确性(accuratens)互操作性(inter-operability)一致性(compliance)保密性(security),可靠性(reliability)成熟性(maturity)容错性(fault-tolerance)可恢复性(recoverability),易用性(usa

12、bility)易理解性(understandability)易学性(learnability)易操作性(operability),效率(efficiency)时间性能(time behavior)资源性能(resource behavior),可维护性(maintainability)可分析性(analyzability)易修改性(changeability)稳定性(stability)测试性(testability),可移植性(portability)适应性(adaptability)可安装性(installability)规范性(conformance)可换性(replaceability

13、),软件质量特性,31,技术混合,功能,成本,兼容性,20年之后的挑战不是速度、成本和性能，而是复杂度的问题了。Bill Raduchel,Sun微系统公司策略执行总裁,软件质量的影响因素,32,什么是软件工程,运用工程学的基本原理和方法来组织和管理软件生产。自软件项目立项起，经过开发、运行、维护直到最终引退的整个软件寿命周期内应用系统的工程技术、质量保证活动、配置管理方法来生产和维护软件产品。工程化方法过程规范化（可控制、可重复、可预测）文档标准化方法系统化管理科学化开发平台自动化,33,软件工程框架结构,软件体系结构,软件建模方法与建模过程,软件工程基础,软件需求工程,面向对象软件开发方法

14、,软件项目管理,软件过程及过程改进,泛化,组成,软件开发模型,结构化软件开发方法,软件项目管理,软件质量保证,软件测试方法,需求管理,需求开发,面向对象的概念,UML语法,面向对象的分析设计,面向对象的软件测试,软件项目估算,软件开发计划,项目风险管理,软件配置管理,软件质量管理,软件度量,软件过程管理,软件过程,软件过程工程,软件工程的目的和内容,目的：高效率、低成本地开发出高质量的软件产品内容：,34,谁需要软件工程?,开发方管理者技术人员：系统分析员、设计师、开发人员、程序员、测试者、维护者、培训人员营销人员用户方投资者使用者维护者,35,软件生命周期,需求（Requirement）计划

15、（Planning）开发（Development）需求分析（Requirements Analysis）设计（Design）编码（Coding）测试（Testing）运行维护（Maintenance),36,软件生产过程的特点,软件的产生通常经历一个“开发”过程，而不是“制造”过程；软件不会出现“磨损、老化”现象；软件投产过程仅仅是一个拷贝过程。,37,软件及其研制过程的特点,38,软件开发模型,瀑布模型（Waterfall Model）螺旋模型（Spiral Model）喷泉模型（Fountain Model）增量模型（Incremental Model）演化模型（Evolving Mode

16、l）统一过程模型（Rational Unified Process）,39,前提：明确的用户需求！,瀑布模型（Waterfall Model),40,在瀑布式生命周期中，只有到生命周期的后期才能确知周围是否存在风险。,瀑布模型的风险,41,原型,风险分析评价方案识别风险消除风险,设计 编码 单元测试 组装测试 系统测试验收测试,实施过程开发与验证,制定计划决定目标方案和限制,提交线,评审,客户评估,螺旋模型（Spiral Model),42,迭代式生命周期和瀑布式生命周期的风险比较,43,喷泉模型体现了软件创建所应有的迭代和无间隙特征。喷泉模型主要用于运行面向对象开发过程。,喷泉模型(Foun

17、tain Model),44,初始原型快速生成,评价/确认,实验性原型进化,最终确认,目标系统实现,目标系统测试,系统交付,原始用户需求,展示/理解/沟通,补充/确认/优化,增量模型实际指出了一个外围框架，它不限制增量开发过程中所使用的具体的过程模型和方法。,增量模型(Incremental Model),45,快速实现核心需求,评价/确认,增强能力、精化系统,用户试用,用户满意的系统,用户核心需求,展示/理解/沟通,补充/确认/优化,演化模型主要针对事先不能完整定义其需求的软件开发。,演化模型(Evolving Model),46,统一过程模型(Rational Unified Proces

18、s),统一过程模型由Rational公司提出，主要用于描述使用UML开发的过程。该过程有如下三个主要特点：用例（Use-case）驱动的软件开发过程以体系结构（Architecture）为中心的过程迭代（Iterative）增量（Incremental）式的过程,47,统一过程模型的生命周期阶段视图,48,统一过程模型的迭代视图,49,核心工作流和模型,50,迭代和工作流,51,软件计划,问题定义可行性分析制定项目计划开发周期投资,52,软件计划（续1）,软件工作域：任务与要求系统：功能、性能、接口（软硬件、人）开发：过程、规程、活动质量：可靠性指标等资源：人员,软硬件,场地,消耗性材料,时间

19、成本专家估算法类推估算法算式估算法进度,53,软件计划(续2）,确定软件需求=软件问题说明书制订开发计划=软件开发计划书管理评审=管理评审报告需求分析=需求规格说明书 用户手册（初稿）技术评审=技术评审报告计划评审=计划评审报告,54,进度计划与管理,进度表(Gantt Chart),55,0,1,2,3,4,5,6,7,8,6,8,6,8,8,8,6,9,7,5,A设计,A编码,7,A测试,B编码,C理解,C修改,B测试,AB组装测试,C测试,AC组装测试,ABC系统测试,任务网络图,进度计划与管理（续）,56,软件需求分析,需求分析的任务需求分析过程需求分析方法需求规格说明书,57,对软件

20、需求的认识,对软件需求的初级认识两个错误假设业界的当前状况项目失败的根本原因相对重要的软件问题需求错误的高昂代价软件需求的主要问题为什么会导致发生不合格的需求说明,58,对软件需求的初级认识,需求不是根本问题，编码才是软件开发工作。给我一个项目，无论需求多么复杂我一定能完成它。至少在初级软件开发人员的潜意识中需求不是那么可怕,编程技术才是重要的。需求很重要，但很容易搞清它。当这些问题与需求管理和处理技能不足以及缺乏易用工具等情况一同出现时，许多团队都对管理好需求不抱希望了。,59,两个错误假设,需求是固定的但实际上：用户会改变、问题会改变、技术基础会改变、市场会改变我们可以在实际开发前做出正确

21、的设计正确的含义包括：软件的所有质量特征,60,业界的当前状况,1998年美国软件业的一份报告：26%的项目是成功的46%的项目是存在问题的28%的项目是失败的平均超支89%平均超出进度计划122%新开发系统所提供功能的45%从来没有被使用过,61,项目失败的根本原因,不完整的需求缺乏用户介入不实际的客户期望需求和规范的变更缺乏高层的支持胜任的团队成员大少缺乏项目管理经验,62,相对重要的软件问题,一次调查以确定在产业中相对重要的软件问题,根据3800个被调查人的回答,大约半数的被调查者回答的两个最大问题是:1)需求规格说明2)管理客户需求相对而言,编码不是问题很显然,我们完全可以把需求当作导

22、致软件问题的最根本原因。,63,最大软件开发问题分类,64,缺陷来源 潜在缺陷 排除的效率 提交的缺陷 需求 1.00 77%0.23 设计 1.25 85%0.19 编码 1.75 95%0.09 建档 0.60 80%0.12 不恰当修复 0.40 70%0.12 合计 5.00 85%0.75,需求错误的频率,65,需求错误的频率,需求错误在提交缺陷(用户着到的缺陷)中是最高的,占了大约全部提交缺陷的三分之一。因此需求错误是系统开发错误中最常见的一类错误。,66,需求错误的高昂代价,如果把编码阶段发现和修复一个错误所需要的努力用1个成本单元表示的话,那么需求阶段的错误修复成本是它的5到1

23、0倍。而且,在维护阶段发现和修复一个错误的成本超过20倍。在项目的需求阶段发现错误所花费的成本与维护阶段发现错误的成本比例是200:1,67,在生命周期不同阶段修复缺陷的相对成本,20,5,2,1,0.5,0.1,需求,设计,编码,单元测试,验收测试,维护,68,结论,1.需求错误可能是最常见的错误。2.需求错误可能是修改花费最昂贵的错误。3.需求错误可能消耗整个项目预算的25%到40%。4.给定需求错误的频率及其“修改成本”的倍增效果因子,可以预言,需求错误将占去返工成本的70%或更多。5.返工通常会消耗项目预算的30%到50%,因此得出:需求错误很容易就消耗掉整个项目预算的25%到40%!

24、,69,软件需求的影响因素,70,对现代软件需求的认识,软件需求是领域知识的学习、经验积累的过程。软件需求是领域知识的传递过程。软件需求是在软件开发过程中迭代增量的认识过程。软件需求是不断变化的，我们要承认、适应这种变化。软件需求是软件开发过程中最关键的过程。,71,软件需求各组成部分之间的关系,72,为什么会导致发生不合格的需求说明,1.无足够用户参与 2.用户需求的不断增加 3.模棱两可的需求 4.不必要的特性 5.过于精简的规格说明 6.忽略了用户分类 7.不准确的计划,73,软件需求工程的概念,74,软件需求工程的概念,需求是对用户期望结果的描述，包括期望结果的外部特性(如产品或服务的

25、功能与质量)、进度和费用需求以及资源和技术约束等。需求工程是开发与验证需求规格说明的一种系统工程方法，它包括从问题分析至开发并验证需求规格说明的往返迭代过程。由此可见，需求工程所要解决的是对外界需求的识别和理解，是达到企事业目标的第一步。企事业在此基础上确定产品(或服务)的方向，进行生产(或服务)的组织和资源的配置。,75,软件需求工程,我们把所有与软件需求相关的活动通称为软件需求工程。需求工程中的活动可分为两大类:需求开发需求管理。,76,需求开发,需求开发包括三个知识和实践要点:1.需求获取2.需求分析3.需求定义,77,需求开发,需求开发可分为两个阶段：“用户需求调查阶段”和“产品需求定

26、义阶段”，“需求分析”则贯穿于上述两个阶段。需求调查阶段和需求定义阶段在逻辑上存在先后关系，实际工作中二者通常是迭代进行的。我们把从事需求开发工作的人员称为需求分析员（也叫系统分析员）,78,需求提出和分析的结果,79,需求管理,需求管理包括三个知识和实践要点1.需求确认2.需求跟踪3.需求变更控制,80,什么是需求管理,需求定义了系统必须具有的能力,一个项目的成功与否往往取决于它是否符合一系列的需求。因此,探讨需求的确切含义、把它们写下来、组织起来、跟踪它们的变更就显得非常有意义。需求管理定义为:一个为系统的需求进行启发、组织、建档的系统方法,一个建立和维护客户和项目团队之间关于变更系统需求

27、所达成的一致性的过程。,81,需求管理,任何曾经参与过复杂软件系统的人,无论是作为用户还是开发人员,都知道从用户和风险承担人那里获取需求的能力是非常关键的技能因为与一个系统相关的需求即使没有上千条,也至少有数百条,因此把它们合理地组织起来非常重要。因为我们无法永久记忆太多的信息,因此为需求建档能够有效支持风险承担人之间的沟通。必须把需求用可访问的介质来记录:文档,模型。,82,需求管理,需求管理与项目的大小和复杂度有关两个人、十条需求的项目,不需要管理需求。但是,如果要验证一个有500-1000条需求的软件产品,我们就面临着必须对这些需求进行组织、划定优先级、控制对它们的访问以及为它们提供存储

28、资源的问题。可以把需求管理看成处理重要的复杂项目需求的一系列理有组织的、标准化的、系统化的过程和技术。,83,需求工程的用例,84,需求开发过程,需求开发过程产生的主要文档 用户需求说明书。产品需求规格说明书,85,需求跟踪,需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。,86,需求确认,需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后做出书面承诺，使需求文档具有商业合同效果。,87,需求变更控制,需求变更控制是指依据“变更申请审批更改重新确认”的流程处理需求的变更，确保需求的变更不会失去控制而导致项目发

29、生混乱。,88,需求管理过程的主要文档,需求评审报告需求跟踪报告需求变更控制报告,89,需求工程的活动分类,90,需求工程的主要文档,用户需求说明书产品需求规格说明书需求评审报告需求跟踪报告需求变更控制报告,91,需求开发和需求管理的活动关系,92,软件需求工程小结,93,软件设计,任务：确定系统实现方案软件模块结构设计确定测试方案，制定软件测试计划编制总体设计文档总体设计复审步骤：概要设计概要设计复审详细设计详细设计复审方法：结构化设计方法、面向对象设计方法等。,94,软件设计（续）,概要设计：系统结构、数据结构、接口、设计约束概要设计说明书、测试计划评审详细设计：详细设计说明书、详细测试计

30、划、测试大纲评审,95,程序编码,程序设计语言源代码清单适当的注释,96,软件测试,基本概念软件测试的原则软件测试的方法测试用例的设计测试步骤调试技术,97,基本概念,软件测试：对软件需求分析、设计和编码的复审，通过充分测试以发现上述各阶段存在的问题。测试目标：尽可能以最少的代价找出软件潜在的错误和缺陷。在设计测试方案时要设计能暴露错误的方案，而不是证明系统无错误。测试是为了发现程序中的错误而执行程序的过程好的测试方案是极有可能发现迄今尚未发现的尽可能多的错误的方案成功的测试目标是发现迄今尚未发现的测试,98,软件测试的原则,程序员或程序设计机构不应测试自己设计的程序。在设计测试用例时，不仅要

31、有确定的输入数据，而且要有确定的预期输出结果。测试用例的设计不仅要有合理的输入数据，还要有不合理的输入数据。除了检查程序是否做完了它应做的事之外，还要检查它是否做了不应做的事。保留全部测试用例，并作为软件的组成部分之一。程序中存在错误的概率与在该段程序中已发现的错误数成比例。,99,软件测试的方法,白盒测试：测试者必须对程序内部结构和处理过程非常清楚，根据程序的内部结构进行程序测试，检查程序中的每条通路是否能完成预定要求工作。因此，白盒测试也称为结构测试。黑盒测试：着眼于程序的外部特征，而不考虑程序的内部结构。黑盒测试法将程序看成是一个黑盒子，只在程序接口上进行测试，主要看软件是否完成功能的要

32、求，因此黑盒测试也称为功能测试。,100,测试用例的设计,设计测试用例是测试阶段的关键技术。选择测试数据确定预期结果白盒测试：逻辑覆盖法语句覆盖判定覆盖条件覆盖判定/条件覆盖条件组合覆盖路径覆盖黑盒测试：等价分类法、边界值法、错误猜测法,101,测试用例的设计（续）,实用综合测试策略：任何情况下都使用边界值分析法，应该即包括输入边界情况，又包括输出的边界情况。必要时用等价分类法补充测试用例。必要时再使用错误猜测法补充测试用例。对照程序逻辑检查已设计测试用例的逻辑覆盖标准，根据程序可靠性要求，补充测试用例使之达到规定的覆盖标准。,102,测试步骤,单元测试集成测试系统测试,103,调试技术,调试

33、（即排错）与成功的测试是互相衔接的两个阶段。测试成功的标志是发现了错误。根据错误迹象确定错误原因和准确位置，并加以改正的任务主要依靠调试技术。测试的目的是尽可能发现错误。但是，发现错误的最终目的还是为了纠正错误。纠正错误的过程就是调试。,104,调试技术（续）,改正错误的原则：在出现错误的地方，很可能还有别的错误，因此在修改一个错误时，要检查一下它的附近是否还有别的错误。修改错误的一个常见失误是只修改了这个错误的征兆或这个错误的表现，而没有修改错误的本身。如果提出的修改不能解释与这个错误有关的全部线索，那就表明了只修改了错误的一部分。当心修正一个错误的同时有可能会引入新的错误，因此在修改了错误

34、之后，必须进行回归测试，以确认是否引进了新的错误。修改错误的过程将迫使人们暂时回到程序设计阶段。修改错误也是程序设计的一种形式。一般说来，在程序设计阶段所使用的任何方法都可以应用到错误修正的过程中来。,105,软件维护,软件维护的种类软件维护的特点软件的可维护性软件维护的副作用,106,软件维护的种类,完善性维护适应性维护纠错性维护预防性维护,107,需求分析,设计,编码,测试,维护,软件生命周期的花费比例,108,软件的可维护性,软件的可维护性：维护人员理解、改正和改动该软件的难易程度。影响软件可维护性的因素：可理解性、可测试性、可修改性、可靠性、可移植性、可用性和效率等。提高软件可维护性的

35、方法：建立软件质量目标和优先级；使用提高软件质量的技术和工具；进行明确的质量保证审查；选择可维护性好的程序设计语言；建立维护文档。,109,软件维护的特点,软件维护所需要的工作量和费用非常大。软件工程学的一个基本目标就是为了提高软件的可维护性，减少软件的维护工作量。软件维护的成本：M=P+K*exp(c-d)其中，M：维护所用总工作量P：生产性工作量K：经验常数c：复杂度d：对维护软件的熟悉程度,110,软件维护的副作用,软件维护的副作用：由于修改而导致的错误或其它多余动作的发生。修改软件是危险的！对于大型软件，每修改一次，都可能使潜在的错误增加。,111,软件标准与规范,国际标准ISO 86

36、31国家标准GB8566-88GB/T 14394-93GB/T 19000 3 94,112,软件标准与规范（续1）,行业标准IEEEGJB 437-88DOD-STD-2167A(1988)MIL-STD-498(1994)企业规范项目规范,113,软件标准与规范（续2）,中华人民共和国国家军用标准军用软件产品，GJB2255-94.军用软件项目管理规程，GJB2115-94.军用软件接口设计要求，GJB2041-94.军用软件软件验收，GJB1268-91.军用计算机软部件文档编写格式和内容，GJB 1566-92.军用软件维护，GJB 1267-91.军用软件开发规范，GJB437-8

37、8.军用软件文档编制规范，GJB438-88.军用软件质量保证规范，GJB439-88.,114,软件管理,软件的目标与项目计划成本估算进度计划人员分配软件配置管理软件质量,115,软件配置管理,软件配置管理是软件质量保证的重要一环，在软件开发过程中，它的主要任务是控制软件的修改，包括：（1）标识软件配置中各种对象（2）管理软件的各种版本（3）建立系统（4）控制对软件的修改（5）审计配置（6）报告配置状况,116,产品需求,产品,资源,管理！？！,高效率、低成本地 开发高质量的软件！,软件工程面对的挑战,117,软件工程：,产品,方法,工具,过程,人,进度经费资源,标准,小结,118,小结（续）,软件：文档+程序+数据软件生命周期：需求、设计、实现、测试、维护软件工程：工程化方法管理软件开发过程软件工程的目标：追求软件产品的正确性、可用性和软件生产的效率软件工程的关键：提高软件质量和生产效率软件过程改进,