软件危机与软件工程.pptx

《软件危机与软件工程.pptx》由会员分享，可在线阅读，更多相关《软件危机与软件工程.pptx（58页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、软件危机与软件工程软件危机与软件工程软件危机软件危机 0美元支票美元支票一位主管收到了一张由计算机开出的一位主管收到了一张由计算机开出的0美元的美元的账单，在嘲笑了账单，在嘲笑了“愚蠢的计算机愚蠢的计算机”后他将账单后他将账单丢进了垃圾桶，一个月后，又一张账单寄来了，丢进了垃圾桶，一个月后，又一张账单寄来了，还标志着还标志着30天的逾期，这样的情形持续了天的逾期，这样的情形持续了4个个月，最后还带来了一封信，警告如果再不付账月，最后还带来了一封信，警告如果再不付账的话，将会采取法律行动，由于担心自己的信的话，将会采取法律行动，由于担心自己的信用度，这个主管在一个软件工程师的建议下，用度，这个主

2、管在一个软件工程师的建议下，寄出了一张寄出了一张0美元的支票，最后一张美元的支票，最后一张0美元的收美元的收据送到了，该主管小心翼翼地将这张不同寻常据送到了，该主管小心翼翼地将这张不同寻常的收据保存起来以备将来查询。的收据保存起来以备将来查询。软件危机（续）软件危机（续） 有错误的爱国者导弹有错误的爱国者导弹1991年海湾战争中，一枚飞毛腿导弹穿过了爱年海湾战争中，一枚飞毛腿导弹穿过了爱国者反导弹的防御，击中了沙特阿拉伯的国者反导弹的防御，击中了沙特阿拉伯的Dhahran附件的一个兵营，造成附件的一个兵营，造成28名美国人死名美国人死亡，亡，98人受伤。这个错误是由累积的定时错误人受伤。这个错

3、误是由累积的定时错误引起的，爱国者导弹每次只能工作几小时，超引起的，爱国者导弹每次只能工作几小时，超过这个时间后，系统时钟就会复位。可悲的是过这个时间后，系统时钟就会复位。可悲的是新的软件第二天才运到。新的软件第二天才运到。软件危机（续）软件危机（续） 美国国内税收处美国国内税收处20世纪年代让世纪年代让Sperry公公司建立一套联邦税收表格自动处理系统，司建立一套联邦税收表格自动处理系统，该系统被证明不适合当前的工作量，花该系统被证明不适合当前的工作量，花费几乎是预算的费几乎是预算的2倍，到倍，到1996年，共花费年，共花费了了40亿美元，但情况并没改善。原因是亿美元，但情况并没改善。原因是

4、“没有充分计划就错误行事没有充分计划就错误行事”。软件危机的表现软件危机的表现 超出预算时间和成本超出预算时间和成本研究表明，每研究表明，每8个新的大型软件中就有个新的大型软件中就有2个会被个会被取消，软件开发时间平均超出计划的取消，软件开发时间平均超出计划的50%，而，而软件开发中的主要成本是人力资源成本，进度软件开发中的主要成本是人力资源成本，进度的落后意味着成本的增加的落后意味着成本的增加 用户对生产出的软件不满意用户对生产出的软件不满意开发人员往往不注重或不善于和客户交流，找开发人员往往不注重或不善于和客户交流，找出客户真正需要的东西，匆忙地进行开发，在出客户真正需要的东西，匆忙地进行

5、开发，在开地过程中又不能从客户那里得到反馈信息，开地过程中又不能从客户那里得到反馈信息，最后生产出的软件和客户想要的相差很远，难最后生产出的软件和客户想要的相差很远，难免出现纠纷。免出现纠纷。软件危机的表现（续）软件危机的表现（续） 软件有残存的错误软件有残存的错误研究表明，所有的大型系统中，大约有研究表明，所有的大型系统中，大约有3/4的系统有运行问题，要么不是像预料的系统有运行问题，要么不是像预料的工作，就是根本不能使用的工作，就是根本不能使用 软件产品不可维护软件产品不可维护不能改正错误不能改正错误在原有模块上不能增加新的功能在原有模块上不能增加新的功能不能增加新的模块不能增加新的模块软

6、件危机的表现（续）软件危机的表现（续） 文档资料不完整文档资料不完整软件文档是交流平台，管理工具，必须软件文档是交流平台，管理工具，必须和软件同步更新和软件同步更新 软件生产率的提高跟不上硬件的发展速软件生产率的提高跟不上硬件的发展速度度 摩尔定律：摩尔定律：每隔每隔 18 个月计算机硬件的运个月计算机硬件的运算速度提高一倍算速度提高一倍,价格下降一半价格下降一半 软件：手工开发为主软件：手工开发为主软件危机的表现（续）软件危机的表现（续） 软件成本在计算机系统总成本中的比例不断提软件成本在计算机系统总成本中的比例不断提高高 而软件而软件维护的成维护的成 本占软本占软 件的成件的成 本也越本也

7、越 来越高来越高引起软件危机的原因引起软件危机的原因 软件开发无计划性软件开发无计划性没有经过仔细考虑就匆忙开发没有经过仔细考虑就匆忙开发,出现问题出现问题才想办法补救才想办法补救,不能保证软件开发进度和不能保证软件开发进度和预算预算,不能保证软件质量，在进度落后时，不能保证软件质量，在进度落后时，盲目增加人手，结果适得其反盲目增加人手，结果适得其反引起软件危机的原因（续）引起软件危机的原因（续） 软件需求不充分软件需求不充分没有将问题搞清楚就匆忙上马，在开发没有将问题搞清楚就匆忙上马，在开发过程中又不能和客户有效地沟通，许多过程中又不能和客户有效地沟通，许多问题在交付软件时才集中地爆发出来，

8、问题在交付软件时才集中地爆发出来，这时候已经是大势已去，难以挽回了这时候已经是大势已去，难以挽回了（和数值计算软件和平时学习语言编写（和数值计算软件和平时学习语言编写的程序不同，在实际的软件开发中的程序不同，在实际的软件开发中,首先首先应该满足的是客户的需要应该满足的是客户的需要，开发软件不，开发软件不是为了展示个人的技巧。是为了展示个人的技巧。 ）引起软件危机的原因（续）引起软件危机的原因（续） 软件开发过程无规范软件开发过程无规范 开发过程没有统一的方法和规范开发过程没有统一的方法和规范 不重视文档不重视文档 各开发人员之间的接口没有统一规划各开发人员之间的接口没有统一规划引起软件危机的原

9、因（续）引起软件危机的原因（续） 软件产品无评测手段软件产品无评测手段 个人提交产品时没有进行测试个人提交产品时没有进行测试 模块之间接口没有测试模块之间接口没有测试 整个系统没有进行整体测试整个系统没有进行整体测试 忽略压力及性能测试忽略压力及性能测试软件危机解决之道软件危机解决之道:软件工程软件工程 1968年北大西洋公约组织的计算机科学家在联年北大西洋公约组织的计算机科学家在联邦德国召开的国际学术会议上第一次提出了邦德国召开的国际学术会议上第一次提出了“软件危机软件危机”(software crisis)这个名词。这个名词。 1968年秋季，北约的科技委员会召集了近年秋季，北约的科技委员

10、会召集了近50名名一流的编程人员、计算机科学家和工业界巨头，一流的编程人员、计算机科学家和工业界巨头，讨论和制定摆脱讨论和制定摆脱“软件危机软件危机”的对策。在那次的对策。在那次会议上第一次提出了软件工程（会议上第一次提出了软件工程（software engineering）这个概念这个概念 用工程化的理念、方法进行软件开发用工程化的理念、方法进行软件开发软件工程的定义软件工程的定义软件工程软件工程IEE93 将将系统的、规范的、可度量系统的、规范的、可度量的方法应用的方法应用于软件的开发、运行和维护的过程；于软件的开发、运行和维护的过程； 上述方法的研究上述方法的研究软件工程基本原理软件工程

11、基本原理 B.W.Boehm提出提出 7条原理，互相独立，最小集合条原理，互相独立，最小集合 其他软件工程原理在此基础上组合、蕴其他软件工程原理在此基础上组合、蕴含、派生含、派生软件工程基本原理软件工程基本原理-1 用分阶段的生命周期计划严格管理用分阶段的生命周期计划严格管理不成功的软件中有一半左右是由于计划不同不成功的软件中有一半左右是由于计划不同造成的造成的应该将软件生命周期划分成若干个阶段，并应该将软件生命周期划分成若干个阶段，并相应制定出切实可行的计划，并按计划对软相应制定出切实可行的计划，并按计划对软件的开发和维护进行管理件的开发和维护进行管理六类计划：项目概要计划，里程碑计划，项六

12、类计划：项目概要计划，里程碑计划，项目控制计划，产品控制计划，验证计划，运目控制计划，产品控制计划，验证计划，运行维护计划行维护计划软件工程基本原理软件工程基本原理-2 坚持进行阶段评审坚持进行阶段评审统计表明，大部分错误是在编码之前造成的统计表明，大部分错误是在编码之前造成的错误发现与改正越晚，所需付出的代价也越错误发现与改正越晚，所需付出的代价也越高（见下页）高（见下页）坚持阶段评审，可以避免错误的坚持阶段评审，可以避免错误的“水波效应水波效应”各阶段改正错误的相对花费各阶段改正错误的相对花费软件工程基本原理软件工程基本原理-3 实行严格的产品控制实行严格的产品控制尽量避免修改需求尽量避免

13、修改需求修改需求必须在严格的管理下进行修改需求必须在严格的管理下进行-配置配置管理管理软件工程基本原理软件工程基本原理-4 采用现代程序设计技术采用现代程序设计技术结构化程序设计技术结构化程序设计技术自顶向下，逐步求精自顶向下，逐步求精面向对象设计技术面向对象设计技术思想而非仅为技术思想而非仅为技术软件工程基本原理软件工程基本原理-5 结果应能清楚地审查结果应能清楚地审查度量是管理的基础度量是管理的基础形成自己的管理数据资料库，尽量精确地对形成自己的管理数据资料库，尽量精确地对系统进行计划、测量、修正系统进行计划、测量、修正软件工程基本原理软件工程基本原理-6 开发小组人员应少而精开发小组人员

14、应少而精 IBM的纽约时报项目（的纽约时报项目（1971）：）：22个月内写个月内写了了83000行程序，在行程序，在1年的运行过程中只找出年的运行过程中只找出了了25个错误，主要的程序员平均每年编写个错误，主要的程序员平均每年编写1个错误和个错误和10000行代码行代码 成功原因：成功原因： 该项目是该项目是IBM的样本项目的样本项目 每个程序员都是尖子中的尖子每个程序员都是尖子中的尖子 技术支持极为强大，编译器作者随叫随到技术支持极为强大，编译器作者随叫随到 项目领导项目领导F.Terry Baker是一个极好的管理者和是一个极好的管理者和领导者，领导者，“天才程序员天才程序员”软件工程基

15、本原理软件工程基本原理-6（续）（续） 一个好的程序员的效率是普通程序员的一个好的程序员的效率是普通程序员的4-5倍倍 开发小组人员增多，由于交流讨论问题开发小组人员增多，由于交流讨论问题所造成的通信开销急剧增加（特别是程所造成的通信开销急剧增加（特别是程序员使用其他程序员所开发的模块）序员使用其他程序员所开发的模块）软件工程基本原理软件工程基本原理-7 不断改进软件工程实践不断改进软件工程实践发展和采用新技术发展和采用新技术收集相关数据收集相关数据软件生产中的问题：软件生产中的问题： - -本质的和偶发的本质的和偶发的 硬件限制硬件限制光传播速度光传播速度制造工艺制造工艺 :电子能通过的最窄

16、的宽度为电子能通过的最窄的宽度为3个个原子的直径原子的直径 软件软件:没有银弹没有银弹软件开发中的困难软件开发中的困难 困难困难: :本质的（固有的）和偶发的（非固本质的（固有的）和偶发的（非固有的）有的） 软件的本质困难（软件的本质困难（每一种的原因及后果每一种的原因及后果）复杂性复杂性一致性一致性可变性可变性不可见性不可见性软件开发中的困难软件开发中的困难: :复杂性复杂性(1)(1) 原因原因:1.1.如果程序占如果程序占N个字，则可能的状态有个字，则可能的状态有216*N种种: :非线性增长非线性增长产品的不同块之间是要相互影响（如全局变产品的不同块之间是要相互影响（如全局变量）量）软

17、件开发中的困难软件开发中的困难: :复杂性复杂性(2)(2) 后果后果:软件产品很难理解软件产品很难理解,开发小组成员间不能进开发小组成员间不能进行良好的沟通行良好的沟通,造成开发超时和超支，并且造成开发超时和超支，并且造成说明文档中出现的错误、影响对软件过造成说明文档中出现的错误、影响对软件过程的管理程的管理 维护过程变得很复杂，除非维护人员对产品维护过程变得很复杂，除非维护人员对产品真正理解真正理解软件开发中的困难软件开发中的困难: :复杂性复杂性(3)(3) 对策对策: :结构化方法结构化方法: :自顶向下自顶向下, ,逐步求精逐步求精面向对象方法面向对象方法 :封装、消息驱动、继承、复

18、封装、消息驱动、继承、复用用 能够减少复杂性，从而提高可维护性，能够减少复杂性，从而提高可维护性，但并不能将软件复杂性完全消除但并不能将软件复杂性完全消除软件开发中的困难软件开发中的困难: :一致性一致性(1)(1) 设计软件时与现有系统的接口一致性设计软件时与现有系统的接口一致性 在设计新系统时，软件设计师与其它设在设计新系统时，软件设计师与其它设备的设计师之间的一致性备的设计师之间的一致性软件开发中的困难软件开发中的困难: :一致性一致性(2)(2) 原因：原因： 普遍存在的误解：软件是系统中一种最普遍存在的误解：软件是系统中一种最容易与别的设备进行接口的成分容易与别的设备进行接口的成分

19、后果：后果： 软件获得了一种不必要的复杂性，而这软件获得了一种不必要的复杂性，而这种复杂性不是由软件自身的结构引起的种复杂性不是由软件自身的结构引起的软件开发中的困难软件开发中的困难: :可变性可变性(1)(1) 软件需要改变的原因软件需要改变的原因: 1.软件是现实世界的模拟软件是现实世界的模拟,软件要随着现实软件要随着现实世界的改变而改变世界的改变而改变 用户对软件功能的扩展要求用户对软件功能的扩展要求,超越原来的设超越原来的设计计软件改变的最有吸引力的地方是软件比硬软件改变的最有吸引力的地方是软件比硬件更容易改变件更容易改变 成功的软件能够超越支持其运行的硬件的成功的软件能够超越支持其运

20、行的硬件的生存期生存期,在更换硬件后继续使用在更换硬件后继续使用 软件开发中的困难软件开发中的困难: :可变性可变性(2)(2) 后果后果: 从长远来看从长远来看,对产品进行大面积的维护是对产品进行大面积的维护是不明智的不明智的,从头开始对软件重新编码有进从头开始对软件重新编码有进成本更低成本更低,但人们对软件本质的忽视而常但人们对软件本质的忽视而常常要求对软件进行在的改动常要求对软件进行在的改动软件开发中的困难软件开发中的困难: :不可见性不可见性(1)(1) 原因原因(难以将代码与实际的软件对应起来难以将代码与实际的软件对应起来): 目前目前不存在不存在一种普遍接受的方法来对一一种普遍接受

21、的方法来对一个完整的软件产品进行描述，或者对产个完整的软件产品进行描述，或者对产品做出某种概述，现有的各种说明工具品做出某种概述，现有的各种说明工具（如（如UML、数据流图、程序结构图数据流图、程序结构图)极少极少有平面的，更别说是分层的，图表中有有平面的，更别说是分层的，图表中有太多的交叉，难以一下子给出软件的全太多的交叉，难以一下子给出软件的全貌貌软件开发中的困难软件开发中的困难: :不可见性不可见性(2)(2) 后果后果: 1.没有一种图表能将软件的各个方面都体没有一种图表能将软件的各个方面都体现出来，并且也没有一种方法能够确定现出来，并且也没有一种方法能够确定在使用一种形象化描述方法对

22、产品进行在使用一种形象化描述方法对产品进行描述时，我们遗漏了哪些描述时，我们遗漏了哪些 2.不能对软件进行形象化描述不仅使软件不能对软件进行形象化描述不仅使软件难于理解，而且极大地阻碍了软件专家难于理解，而且极大地阻碍了软件专家之间的沟通之间的沟通没有银弹没有银弹(1) 对于软件的本质问题，我们无法解决，对于软件的本质问题，我们无法解决，无法找到一种在生产上快速取得大数量无法找到一种在生产上快速取得大数量级提高的方法，即银弹级提高的方法，即银弹没有银弹没有银弹(2) 对于软件的偶发问题是可以解决的对于软件的偶发问题是可以解决的 Brooks认为生产软件的最困难的部分在认为生产软件的最困难的部分

23、在需求阶段、规格说明和设计阶段，而不需求阶段、规格说明和设计阶段，而不是实现阶段是实现阶段,建议我们改变软件的生产方建议我们改变软件的生产方式：式：在任何可能的情况下购买已经开发好的软件，在任何可能的情况下购买已经开发好的软件，而不是定制开发而不是定制开发 使用快速原型和增量式建造技术使用快速原型和增量式建造技术 培养伟大的设计者培养伟大的设计者改进软件过程改进软件过程(1) “软件开发的根本问题在于人们不能对软件过软件开发的根本问题在于人们不能对软件过程进行管理程进行管理” 美国国防部在位于匹兹堡的卡耐基美国国防部在位于匹兹堡的卡耐基.梅隆大学成梅隆大学成立了软件工程研究所（立了软件工程研究

24、所（software engineering Institute ,SEI） SEI的一个最主要的成功是建立了能力成熟度模的一个最主要的成功是建立了能力成熟度模型（型（Capability Maturity Model, CMM） 国际标准化组织（国际标准化组织（ISO）也制定了相应的也制定了相应的ISO-9000系列标准、系列标准、ISO/IEC 15504等等 改进软件过程改进软件过程(2) 能力成熟度模型能力成熟度模型 CMM是一组用于改进软件过是一组用于改进软件过程的相关策略，它与实际使用的软件生命周期程的相关策略，它与实际使用的软件生命周期模型没有关系（成熟度是对软件过程本身的度模型

25、没有关系（成熟度是对软件过程本身的度量），量），CMM模型包括：模型包括： 1.用于软件的用于软件的SWCMM 2.用于人力资源管理的用于人力资源管理的PCMM 3.用于系统工程的用于系统工程的SECMM 4.用于集成产品开发的用于集成产品开发的IPDCMM 5.用于软件收集的用于软件收集的SACMM 为避免不一致和冗余，为避免不一致和冗余，1997年将前年将前4个模型统个模型统一为一为CMMI 改进软件过程改进软件过程(3) 软件过程不仅包括软件生产的各种技术和工具，软件过程不仅包括软件生产的各种技术和工具，也包括技术方面和管理方面的内容也包括技术方面和管理方面的内容 SWCMM是基于以下观

26、点的：新技术本身并是基于以下观点的：新技术本身并不能导致产量和利润的增加，我们的问题主要不能导致产量和利润的增加，我们的问题主要出现在软件过程管理上出现在软件过程管理上 SWCMM模型的策略是改进软件过程的管理，模型的策略是改进软件过程的管理，相信技术的提高是一个自然的结果，软件过程相信技术的提高是一个自然的结果，软件过程做为一个整体所获得的改进将导致较高质量的做为一个整体所获得的改进将导致较高质量的软件的产生，并且将会有较少项目超时或超支软件的产生，并且将会有较少项目超时或超支 CMM 软件过程改进不可能在一夜之间实软件过程改进不可能在一夜之间实现现,SW-CMM模型对过程的改变是逐步的模型

27、对过程的改变是逐步的,该模型定义了该模型定义了5个成熟度级别个成熟度级别,一个软件组一个软件组织通过每一步的细微演变织通过每一步的细微演变,将自己的成熟将自己的成熟度级别提高到更高一级上度级别提高到更高一级上成熟度级别成熟度级别1 (初始级初始级) ) 有效的软件过程管理方法在本质上没有获有效的软件过程管理方法在本质上没有获得使用得使用,软件开发成功与否依赖于当前的软件开发成功与否依赖于当前的软件开发人员软件开发人员 整个开发过程没有计划整个开发过程没有计划,不可预测不可预测,软件开软件开发经常超时和超支发经常超时和超支 许多措施都是在软件开发遇到困难进采取许多措施都是在软件开发遇到困难进采取

28、的，而不是事先计划好的（在这样的组织的，而不是事先计划好的（在这样的组织里，里，“高技术高技术”只能引起更大的混乱）只能引起更大的混乱） 成熟度级别成熟度级别2（可重复级）（可重复级） 使用了基本的软件项目管理措施使用了基本的软件项目管理措施 1.根据从类似产品中获得的经验对新的产品进行根据从类似产品中获得的经验对新的产品进行计划和管理计划和管理 2.使用了基本的测量技术使用了基本的测量技术(包括对花费和工作进度包括对花费和工作进度表的仔细跟踪表的仔细跟踪 ) 3.项目中的测量为以后项目时间和费用表的制定项目中的测量为以后项目时间和费用表的制定提供现实的依据提供现实的依据 4.通过测量通过测量

29、,管理人员能够及时发现问题，并立刻管理人员能够及时发现问题，并立刻采取措施阻止这些问题演化成大的危机采取措施阻止这些问题演化成大的危机 成熟度级别成熟度级别3（已定义级）（已定义级） 软件开发过程的完全文档化软件开发过程的完全文档化 1.软件开发过程在所有的管理的技术方面软件开发过程在所有的管理的技术方面都有明确的定义都有明确的定义 2.在任何可能的地方不断努力改进软件开在任何可能的地方不断努力改进软件开发过程发过程 3.以以评审评审方式来保证软件质量方式来保证软件质量 4.引进引进CASE技术来进一步提高软件质量技术来进一步提高软件质量的软件生产力的软件生产力 成熟度级别成熟度级别4（已管理

30、级）（已管理级） 为每个项目设计了质量目标和生产目标为每个项目设计了质量目标和生产目标 1.在软件开发过程中对这两项指标在软件开发过程中对这两项指标不断进不断进行测量行测量，当与目标有不可接受的偏离时，当与目标有不可接受的偏离时，则能够纠正措施对其进行纠正则能够纠正措施对其进行纠正 2.设立统计质量控制（如每千行代码的设立统计质量控制（如每千行代码的错误数），确保管理者能够区别质量和错误数），确保管理者能够区别质量和生产标准的随机偏离及有意的违背生产标准的随机偏离及有意的违背 成熟度级别成熟度级别5（优化级）（优化级） 持续改进软件过程持续改进软件过程 1.人们用静态质量和过程控制技术对软人们

31、用静态质量和过程控制技术对软件组织进行指引，在每个项目中获取的件组织进行指引，在每个项目中获取的知识在以后的项目中可得到利用知识在以后的项目中可得到利用 2.开发过程形成了一个回馈性的良性循开发过程形成了一个回馈性的良性循环，从而使软件生产和软件质量获得不环，从而使软件生产和软件质量获得不断提高断提高 CMM总结总结(1) 软件组织改进自己的软件过程软件组织改进自己的软件过程,需要需要: 1.努力对组织当前的软件过程有一个理解努力对组织当前的软件过程有一个理解 2.对想要获得的软件过程进行明确的阐述对想要获得的软件过程进行明确的阐述 3.确定为实现过程提高要采取的措施，并确定为实现过程提高要采

32、取的措施，并确定措施实现的先后顺序确定措施实现的先后顺序 4.制定一个实现过程提高的计划并实施该制定一个实现过程提高的计划并实施该计划计划 CMM总结总结(2)CMM总结总结:KPA(1) 关键过程区关键过程区(KPA):组织在努力实现下一个组织在努力实现下一个级别进要努力实现的目标级别进要努力实现的目标 成熟度级别成熟度级别2的的KPA: 1.配置控制配置控制 2.软件质量保证软件质量保证 3.项目计划项目计划 4.项目追踪项目追踪 5.需求管理需求管理CMM总结总结:KPA(2) 级别级别5的的KPA 1.错误预防错误预防 2.技术更新技术更新 3.过程变化管理过程变化管理 级别级别2与级

33、别与级别5的的KPA比较比较 级别级别2:错误发现与纠正错误发现与纠正 级别级别5:错误预防错误预防 CMM提升经验提升经验(1) 花费时间花费时间: 从级别从级别1到级别到级别2: 3到到5年年 从级别从级别2到级别到级别3: 1.5年到年到3年年 SEI开发出一系列的调查表开发出一系列的调查表,做为评估的做为评估的基础基础,评估的目的是指出软件组织当前软评估的目的是指出软件组织当前软件过程中的不足件过程中的不足,并且指明软件组织改进并且指明软件组织改进其过程应采用的方法其过程应采用的方法CMM提升经验提升经验(2) 最初目标最初目标:美国国防部生产软件的合同商美国国防部生产软件的合同商的软

34、件过程进行评估的软件过程进行评估,到到1998年为止年为止,任何任何想与空军签订合同的软件商必须达到想与空军签订合同的软件商必须达到CMM3级以上级以上软件过程改进的其他努力软件过程改进的其他努力(1) ISO9000,ISO9001 1. ISO 9000的原则是的原则是:与该标准保持一致并不与该标准保持一致并不能保证生产出高质量的产品能保证生产出高质量的产品,但这样可以减少生但这样可以减少生产出质量低劣的产品的可能产出质量低劣的产品的可能 2.和和CMM有部分重叠有部分重叠,但并不完全相同但并不完全相同 3.不是过程改进不是过程改进,而强调使用文字和图片对整个而强调使用文字和图片对整个过程

35、进行记录以确保整个过程的一致性和可理过程进行记录以确保整个过程的一致性和可理解性解性,重量在测量方法和节奏重量在测量方法和节奏 4.与欧洲公司签定合同必通过与欧洲公司签定合同必通过ISO9000认证认证,越越来越多的美国公司也要求该认证来越多的美国公司也要求该认证,如通用公司如通用公司软件过程改进的其他努力软件过程改进的其他努力(2) ISO/IEC 15504 1.软件过程提高能力测定软件过程提高能力测定(SPIE):由英国由英国国防部门提出国防部门提出,1997年由国际标准化组织年由国际标准化组织委员会和国际电工学会接手委员会和国际电工学会接手,改称改称ISO/IEC 15504 2.包括

36、过程改进和软件采购包括过程改进和软件采购 3.扩展和实现了扩展和实现了CMM和和ISO9000 4.是一个框架而不是方法是一个框架而不是方法软件过程改进的成本和效益软件过程改进的成本和效益(1) 休斯飞机公司软件工程部门休斯飞机公司软件工程部门,从从CMM2提提升到升到CMM3(1987-1990),花费花费50万美元万美元,每每年能节省年能节省2000万美元万美元 位于位于Raytheon的装备部队从的装备部队从1988年的级年的级别别1增加到增加到1993年的级别年的级别3,产品增加了产品增加了2倍倍,用于过程改进的每用于过程改进的每1美元美元,能获得能获得7.70美元美元的回报的回报软件过程改进的成本和效益软件过程改进的成本和效益(2)SEI对对13个参加了个参加了CMM研究的大的软件组织的报告研究的大的软件组织的报告软件过程改进的成本和效益软件过程改进的成本和效益(3)34个摩托罗拉的政府电子部项目的统计结果个摩托罗拉的政府电子部项目的统计结果