软件危机
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件危机
——科技的“危机”与重生
邓家龙 刘鑫 朱垚 应用六班
软件危机简介
软件危机历史
软件危机表现 软件危机案例
软件危机的原因分析
——软件危ቤተ መጻሕፍቲ ባይዱ简介
软件危机（英语：Software Crisis）是早期计算机科 学的一个术语 [1] ，是指在软件开发及维护的过程中所 遇到的一系列严重问题，这些问题皆可能导致软件产 品的寿命缩短、甚至夭折。 [2] 软件开发是一项高难度、 高风险的活动，由于它的高失败率，故有所谓“软件 危机”之说。 [3] 软件危机的本源是复杂、期望和改变。 这个术语用来描述正急遽增加之电脑的力量带来的冲 击和可能要处理的问题的复杂性。从本质上来说，它 谈到了写出正确、可理解、可验证的电脑程序的困难 。
随着事件的进展，最初诺顿的误杀已然演变成一场危机公关事 件。 记者就此事的危机公关过程欲采访赛门铁克公司时， 被对方以“目前以解决客户问题为先，公司没有太多时间和媒 体解释”为由拒绝了采访。对于赛门铁克的这种做法，危机处 理专家认为，这违背了危机处理原则之一——真诚沟通。
——软件危机的原因分析
用户需求不明确 在软件开发过程中，用户需求不明确问题主要体现在四个方面： 在软件开发出来之前，用户自己也不清楚软件开发的具体需求； 用户对软件开发需求的描述不精确，可能有遗漏、有二义性、甚至有错误； 在软件开发过程中，用户还提出修改软件开发功能、界面、支撑环境等方面 的要求； 软件开发人员对用户需求的理解与用户本来愿望有差异。 缺乏正确的理论指导 缺乏有力的方法学和工具方面的支持。由于软件开发不同于大多数其他工业 产品，其开发过程是复杂的逻辑思维过程，其产 品极大程度地依赖于开发人 员高度的智力投入。由于过分地依靠程序设计人员在软件开发过程中的技巧 和创造性，加剧软件开发产品的个性化，也是发生软件开发危 机的一个重要 原因。
——软件危机案例
诺顿危机公关不力 “误杀门”事件升级 ◎ 文/本报记 者 徐英 截至5月28日，跨国软件企业赛门铁克中国分公司仍 未就旗下产品诺顿“误杀门”事件对用户致歉。而这个时间被 危机处理专家认为是最后的化解危机时间。 5月18日，不少 使用诺顿杀毒软件的用户，遇到了重启电脑出现蓝屏无法启动 的状况，原来，5月17日升级的诺顿杀毒软件将两个简体中文版 本的Microsoft Windows系统文件当成病毒删除，从而让用户电 脑瘫痪。
谢谢欣赏 再见
——软件危机表现
软件危机其原因，衔接到硬件的整体复杂度，与软件开发流程。危机表现在几个 方面： 项目运行超出预算。 项目运行超过时间。 软件质量低落。 软件通常不符合需求。 项目无法管理，且代码难以维护。 硬件成长率每年大约30％，软件每年只勉强以4～7％速度在成长，信息系统的交 付日期一再延后，许多待开发的软件系统无法如期开始。1960年代软件开发成本 占总成本20％以下；1970年代软件成本已达总成本80％以上，软件维护费用在软 件成本中高达65％。1986年公布的数据，所有验收的外包软件中，竟然只有4％ 可用，其余96％却是不堪一用。大部分的企业自行开发的信息系统中，有四分之 三也是功败垂成。因此软件维护成本居高不下，软件产品质量低落是最主要的原 因
——软件危机案例
1995年，Standish Group研究机构以美国境内8000个软 件项目作为调查样本，调查结果显示，有84％软件计划无 法于既定时间、经费中完成，超过30％的项目于运行中被 取消，项目预算平均超出189％。 美国银行信托软件系统开发案
美国银行1982年进入信托商业领域，并规划发展信托 软件系统。项目原订预算2千万美元，开发时程9个月，预 计于1984年12月31日以前完成，后来至1987年3月都未能 完成该系统，期间已投入6千万美元。美国银行最终因为 此系统不稳定而不得不放弃，并将340亿美元的信托账户 转移出去，并失去了6亿美元的信托生意商机。 其他
——软件危机历史
1968年，北大西洋公约组织（NATO）在联邦德国的国际学术会议创造软件危机 （Software crisis）一词。[4][5]而1960年代中期开始爆发众所周知的软件危机，为 了解决问题，在1968、1969年连续召开两次著名的NATO会议，并同时提出软件工 程的概念。 1972年，艾兹赫尔· 戴克斯特拉于计算机协会图灵奖的演讲：
——软件危机原因分析
软件开发规模越来越大 随着软件开发应用范围的增广，软件开发规模愈来愈大。大型软件开 发项目需要组织一定的人力共同完成，而多数管理人员 缺乏开发大型 软件开发系统的经验，而多数软件开发人员又缺乏管理方面的经验。 各类人员的信息交流不及时、不准确、有时还会产生误解。软件开发 项目开发人员 不能有效地、独立自主地处理大型软件开发的全部关系 和各个分支，因此容易产生疏漏和错误。 软件开发复杂度越来越高 软件开发不仅仅是在规模上快速地发展扩大，而且其复杂性也急剧地 增加。软件开发产品的特殊性和人类智力的局限性，导 致人们无力处 理“复杂问题”。所谓“复杂问题”的概念是相对的，一旦人们采用 先进的组织形式、开发方法和工具提高了软件开发效率和能力，新的、 更大的、更 复杂的问题又摆在人们的面前。
软件危机的主要原因，把它很不客气地说：只要没有机器，编程是一点问题也没 有；当我们有几台微弱的电脑，编程就成为平和的问题，而现在我们有巨大的电脑， 编程已成为一个同样巨大的问题。 ——艾兹赫尔· 戴克斯特拉，《卑微的程序员》，《Communications of the ACM》
软件危机使人们认识到中大型软件系统与小型软件有着本质性差异：大型软件系统 开发周期长、费用昂贵、软件质量难以保证、生产率低，它们的复杂性已远超出人 脑能直接控制的程度 ，大型软件系统不能沿袭工作室的开发方式，就像制造小木 船的方法不能生产航空母舰一样。[9]它的存在已经有数十年的历史了，一直到了 1980年代的面向对象技术才解决了一部分在软件危机上的窘境。
1985年－1987年，导致病人死于Therac-25医疗线性加速器的 过量辐射。 1996年，亚利安五号原型爆炸。 1998年，波音Delta III火箭爆炸。
——软件危机案例
诺顿危机公关不力 “误杀门”事件升级 ◎ 文/本报记 者 徐英 截至5月28日，跨国软件企业赛门铁克中国分公 司仍未就旗下产品诺顿“误杀门”事件对用户致歉。而这个 时间被危机处理专家认为是最后的化解危机时间。 5月 18日，不少使用诺顿杀毒软件的用户，遇到了重启电脑出现 蓝屏无法启动的状况，原来，5月17日升级的诺顿杀毒软件 将两个简体中文版本的Microsoft Windows系统文件当成病毒 删除，从而让用户电脑瘫痪。 随着事件的进展，最初诺顿的误杀已然演变成一场危机公关 事件。 记者就此事的危机公关过程欲采访赛门铁克公司 时，被对方以“目前以解决客户问题为先，公司没有太多时 间和媒体解释”为由拒绝了采访。对于赛门铁克的这种做法， 危机处理专家认为，这违背了危机处理原则之一——真诚沟 通。
——软件危机案例
IBMOS/360 IBMOS/360操作系统被认为是一个典型的案例。到现在为止 ，它仍然被使用在360系列主机中。这个经历了数十年，极度 复杂的软件项目甚至产生了一套不包括在原始设计方案之中的 工作系统。OS/360是第一个超大型的软件项目，它使用了1000 人左右的程序员。佛瑞德· 布鲁克斯在随后他的大作《人月神 话》中曾经承认，在他管理这个项目的时候，他犯了一个价值 数百万美元的错误。
——软件危机的解决途径
软件工程诞生于60年代末期，它作为一个新兴的工程学科，主要研究软件生 产的客观规律性，建立与系统化软件生产有关 的概念、原则、方法、技术和 工具，指导和支持软件系统的生产活动，以期达到降低软件生产成本 、改进 软件产品质量、提高软件生产率水平的目标。软件工程学从硬件工程和其他 人类工程中吸收了许多成功的经验，明确提出了软件生命周期的模型，发展 了许多 软件开发与维护阶段适用的技术和方法，并应用于软件工程实践，取 得良好的效果。 在软件开发过程中人们开始研制和使用软件工具，用以辅助进行软件项目管 理与技术生产，人们还将软件生命周期各阶段使用的软件工具有机地集合成 为一个整体，形成能够连续支持软件开发与维护全过程的集成化软件支援环 境，以期从管理和技术两方面解决软件危机问题。 此外，人工智能与软件工程的结合成为80年代末期活跃的研究领域。基于程 序变换、自动生成和可重用软件等软件新技术 研究也已取得一定的进展，把 程序设计自动化的进程向前推进一步。在软件工程理论的指导下，发达国家 已经建立起较为完备的软件工业化生产体系，形成了强大的 软件生产能力 。 软件标准化与可重用性得到了工业界的高度重视，在避免重用劳动，缓解软 件危机方面起到了重要作用
——科技的“危机”与重生
邓家龙 刘鑫 朱垚 应用六班
软件危机简介
软件危机历史
软件危机表现 软件危机案例
软件危机的原因分析
——软件危ቤተ መጻሕፍቲ ባይዱ简介
软件危机（英语：Software Crisis）是早期计算机科 学的一个术语 [1] ，是指在软件开发及维护的过程中所 遇到的一系列严重问题，这些问题皆可能导致软件产 品的寿命缩短、甚至夭折。 [2] 软件开发是一项高难度、 高风险的活动，由于它的高失败率，故有所谓“软件 危机”之说。 [3] 软件危机的本源是复杂、期望和改变。 这个术语用来描述正急遽增加之电脑的力量带来的冲 击和可能要处理的问题的复杂性。从本质上来说，它 谈到了写出正确、可理解、可验证的电脑程序的困难 。
随着事件的进展，最初诺顿的误杀已然演变成一场危机公关事 件。 记者就此事的危机公关过程欲采访赛门铁克公司时， 被对方以“目前以解决客户问题为先，公司没有太多时间和媒 体解释”为由拒绝了采访。对于赛门铁克的这种做法，危机处 理专家认为，这违背了危机处理原则之一——真诚沟通。
——软件危机的原因分析
用户需求不明确 在软件开发过程中，用户需求不明确问题主要体现在四个方面： 在软件开发出来之前，用户自己也不清楚软件开发的具体需求； 用户对软件开发需求的描述不精确，可能有遗漏、有二义性、甚至有错误； 在软件开发过程中，用户还提出修改软件开发功能、界面、支撑环境等方面 的要求； 软件开发人员对用户需求的理解与用户本来愿望有差异。 缺乏正确的理论指导 缺乏有力的方法学和工具方面的支持。由于软件开发不同于大多数其他工业 产品，其开发过程是复杂的逻辑思维过程，其产 品极大程度地依赖于开发人 员高度的智力投入。由于过分地依靠程序设计人员在软件开发过程中的技巧 和创造性，加剧软件开发产品的个性化，也是发生软件开发危 机的一个重要 原因。
——软件危机案例
诺顿危机公关不力 “误杀门”事件升级 ◎ 文/本报记 者 徐英 截至5月28日，跨国软件企业赛门铁克中国分公司仍 未就旗下产品诺顿“误杀门”事件对用户致歉。而这个时间被 危机处理专家认为是最后的化解危机时间。 5月18日，不少 使用诺顿杀毒软件的用户，遇到了重启电脑出现蓝屏无法启动 的状况，原来，5月17日升级的诺顿杀毒软件将两个简体中文版 本的Microsoft Windows系统文件当成病毒删除，从而让用户电 脑瘫痪。
谢谢欣赏 再见
——软件危机表现
软件危机其原因，衔接到硬件的整体复杂度，与软件开发流程。危机表现在几个 方面： 项目运行超出预算。 项目运行超过时间。 软件质量低落。 软件通常不符合需求。 项目无法管理，且代码难以维护。 硬件成长率每年大约30％，软件每年只勉强以4～7％速度在成长，信息系统的交 付日期一再延后，许多待开发的软件系统无法如期开始。1960年代软件开发成本 占总成本20％以下；1970年代软件成本已达总成本80％以上，软件维护费用在软 件成本中高达65％。1986年公布的数据，所有验收的外包软件中，竟然只有4％ 可用，其余96％却是不堪一用。大部分的企业自行开发的信息系统中，有四分之 三也是功败垂成。因此软件维护成本居高不下，软件产品质量低落是最主要的原 因
——软件危机案例
1995年，Standish Group研究机构以美国境内8000个软 件项目作为调查样本，调查结果显示，有84％软件计划无 法于既定时间、经费中完成，超过30％的项目于运行中被 取消，项目预算平均超出189％。 美国银行信托软件系统开发案
美国银行1982年进入信托商业领域，并规划发展信托 软件系统。项目原订预算2千万美元，开发时程9个月，预 计于1984年12月31日以前完成，后来至1987年3月都未能 完成该系统，期间已投入6千万美元。美国银行最终因为 此系统不稳定而不得不放弃，并将340亿美元的信托账户 转移出去，并失去了6亿美元的信托生意商机。 其他
——软件危机历史
1968年，北大西洋公约组织（NATO）在联邦德国的国际学术会议创造软件危机 （Software crisis）一词。[4][5]而1960年代中期开始爆发众所周知的软件危机，为 了解决问题，在1968、1969年连续召开两次著名的NATO会议，并同时提出软件工 程的概念。 1972年，艾兹赫尔· 戴克斯特拉于计算机协会图灵奖的演讲：
——软件危机原因分析
软件开发规模越来越大 随着软件开发应用范围的增广，软件开发规模愈来愈大。大型软件开 发项目需要组织一定的人力共同完成，而多数管理人员 缺乏开发大型 软件开发系统的经验，而多数软件开发人员又缺乏管理方面的经验。 各类人员的信息交流不及时、不准确、有时还会产生误解。软件开发 项目开发人员 不能有效地、独立自主地处理大型软件开发的全部关系 和各个分支，因此容易产生疏漏和错误。 软件开发复杂度越来越高 软件开发不仅仅是在规模上快速地发展扩大，而且其复杂性也急剧地 增加。软件开发产品的特殊性和人类智力的局限性，导 致人们无力处 理“复杂问题”。所谓“复杂问题”的概念是相对的，一旦人们采用 先进的组织形式、开发方法和工具提高了软件开发效率和能力，新的、 更大的、更 复杂的问题又摆在人们的面前。
软件危机的主要原因，把它很不客气地说：只要没有机器，编程是一点问题也没 有；当我们有几台微弱的电脑，编程就成为平和的问题，而现在我们有巨大的电脑， 编程已成为一个同样巨大的问题。 ——艾兹赫尔· 戴克斯特拉，《卑微的程序员》，《Communications of the ACM》
软件危机使人们认识到中大型软件系统与小型软件有着本质性差异：大型软件系统 开发周期长、费用昂贵、软件质量难以保证、生产率低，它们的复杂性已远超出人 脑能直接控制的程度 ，大型软件系统不能沿袭工作室的开发方式，就像制造小木 船的方法不能生产航空母舰一样。[9]它的存在已经有数十年的历史了，一直到了 1980年代的面向对象技术才解决了一部分在软件危机上的窘境。
1985年－1987年，导致病人死于Therac-25医疗线性加速器的 过量辐射。 1996年，亚利安五号原型爆炸。 1998年，波音Delta III火箭爆炸。
——软件危机案例
诺顿危机公关不力 “误杀门”事件升级 ◎ 文/本报记 者 徐英 截至5月28日，跨国软件企业赛门铁克中国分公 司仍未就旗下产品诺顿“误杀门”事件对用户致歉。而这个 时间被危机处理专家认为是最后的化解危机时间。 5月 18日，不少使用诺顿杀毒软件的用户，遇到了重启电脑出现 蓝屏无法启动的状况，原来，5月17日升级的诺顿杀毒软件 将两个简体中文版本的Microsoft Windows系统文件当成病毒 删除，从而让用户电脑瘫痪。 随着事件的进展，最初诺顿的误杀已然演变成一场危机公关 事件。 记者就此事的危机公关过程欲采访赛门铁克公司 时，被对方以“目前以解决客户问题为先，公司没有太多时 间和媒体解释”为由拒绝了采访。对于赛门铁克的这种做法， 危机处理专家认为，这违背了危机处理原则之一——真诚沟 通。
——软件危机案例
IBMOS/360 IBMOS/360操作系统被认为是一个典型的案例。到现在为止 ，它仍然被使用在360系列主机中。这个经历了数十年，极度 复杂的软件项目甚至产生了一套不包括在原始设计方案之中的 工作系统。OS/360是第一个超大型的软件项目，它使用了1000 人左右的程序员。佛瑞德· 布鲁克斯在随后他的大作《人月神 话》中曾经承认，在他管理这个项目的时候，他犯了一个价值 数百万美元的错误。
——软件危机的解决途径
软件工程诞生于60年代末期，它作为一个新兴的工程学科，主要研究软件生 产的客观规律性，建立与系统化软件生产有关 的概念、原则、方法、技术和 工具，指导和支持软件系统的生产活动，以期达到降低软件生产成本 、改进 软件产品质量、提高软件生产率水平的目标。软件工程学从硬件工程和其他 人类工程中吸收了许多成功的经验，明确提出了软件生命周期的模型，发展 了许多 软件开发与维护阶段适用的技术和方法，并应用于软件工程实践，取 得良好的效果。 在软件开发过程中人们开始研制和使用软件工具，用以辅助进行软件项目管 理与技术生产，人们还将软件生命周期各阶段使用的软件工具有机地集合成 为一个整体，形成能够连续支持软件开发与维护全过程的集成化软件支援环 境，以期从管理和技术两方面解决软件危机问题。 此外，人工智能与软件工程的结合成为80年代末期活跃的研究领域。基于程 序变换、自动生成和可重用软件等软件新技术 研究也已取得一定的进展，把 程序设计自动化的进程向前推进一步。在软件工程理论的指导下，发达国家 已经建立起较为完备的软件工业化生产体系，形成了强大的 软件生产能力 。 软件标准化与可重用性得到了工业界的高度重视，在避免重用劳动，缓解软 件危机方面起到了重要作用