软件危机的表现Word格式文档下载.docx
《软件危机的表现Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《软件危机的表现Word格式文档下载.docx（10页珍藏版）》请在冰豆网上搜索。
希罗克斯在总结该项目时无比沉痛地说：
“……正像一只逃亡的野兽落到泥潭中作垂死挣扎，越是挣扎，陷得越深，最后无法逃脱灭顶的灾难，……程序设计工作正像这样一个泥潭……一批批程序员被迫在泥潭中拼命挣扎，……，谁也没有料到问题竟会陷入这样的困境……。
”IBM360操作系统的历史教训已成为软件开发项目中的典型事例被记入历史史册。
如果开发的软件隐含错误，可靠性得不到保证，那么在运行过程中很可能对整个系统造成十分严重的后果，轻则影响到系统的正常工作，重则导致整个系统的瘫痪，乃至造成无可挽回的恶性事故。
如，银行的存款可能被化为乌有，甚至弄成赤字；
工厂的产品全部报废，导致工厂破产。
1963年，美国用于控制火星探测器的计算机软件中的一个“，”号被误写为“·
”，而致使飞往火星的探测器发生爆炸，造成高达数亿美元的损失。
为了克服这一危机，一方面需要对程序设计方法、程序的正确性和软件的可靠性等问题进行系列的研究；
另一方面，也需要对软件的编制、测试、维护和管理的方法进行研究，从而产生了程序设计方法学。
1968年，E·
W·
代克斯特拉首先提出“GOTO语句是有害的”论点，向传统程序设计方法提出了挑战，从而引起了人们对程序设计方法讨论的普遍重视。
众多著名的计算机科学家都参加了这种讨论。
程序设计方法学也正是在这种广泛而深入的讨论中逐渐产生和形成的。
什么是程序设计方法学呢？
简言之，程序设计方法学是讨论程序的性质、程序设计的理论和方法的一门学科。
它包含的内容比较丰富，例如，结构程序设计，程序正确性证明，程序变换，程序的形式说明与推导、程序综合、自动程序设计等。
在程序设计方法学中，结构程序设计占有十分重要的地位，可以说，程序设计方法学是在结构程序设计的基础上逐步发展和完善起来的。
什么是结构程序设计呢？
至今仍众说纷纭，还没有一个严格的，又能被大家普遍接受的定义。
1974年，D·
格里斯将已有的对结构程序设计的不同解释归结为13种，其中，比较有代表性的如下：
结构程序设计是避免使用GOTO语句的一种程序设计；
结构程序设计是自顶向下的程序设计；
结构程序设计是一种组织和编制程序的方法，利用它编制的程序易于理解、易于修改；
程序结构化的一个主要功能是使程序正确性的证明容易实现；
结构程序设计对设计过程中的每一步去验证其正确性，这样便自动导致自我说明和自我捍卫的程序设计风格；
总之，结构程序设计讨论了如何将大规模的和复杂的流程图转换成一种标准的形式，使得它们能够用几种标准的控制结构（通常是顺序、分支和重复）通过重复和嵌套来表示。
上述定义或解释从不同角度反映了结构程序设计所讨论的主要问题。
实质上，结构程序设计是一种进行程序设计的原则和方法，按照这种原则和方法可设计出结构清晰、容易理解、容易修改、容易验证的程序。
按照结构程序设计的要求设计出的程序设计语言称为结构程序设计语言。
利用结构程序设计语言，或者说按结构程序设计的思想和原则编制出的程序称为结构化程序。
在60年代末和70年代初，关于GOTO语句的用法的争论比较激烈。
主张从高级程序语言中去掉GOTO语句的人认为，GOTO语句是对程序结构影响最大的一种有害的语句，他们的主要理由是：
GOTO语句使程序的静态结构和动态结构不一致，从而使程序难以理解，难以查错。
去掉GOTO语句后，可直接从程序结构上反映程序运行的过程。
这样，不仅使程序结构清晰，便于理解，便于查错，而且也有利于程序的正确性证明。
持反对意见的人认为，GOTO语句使用起来比较灵活，而且有些情形能提高程序的效率。
若完全删去GOTO语句，有些情形反而会使程序过于复杂，增加一些不必要的计算量。
1974年，D·
E·
克努斯对于GOTO语句争论作了全面公正的评述，其基本观点是：
不加限制地使用GOTO语句，特别是使用往回跳的GOTO语句，会使程序结构难于理解，在这种情形，应尽量避免使用GOTO语句。
但在另外一些情况下，为了提高程序的效率，同时又不致于破坏程序的良好结构，有控制地使用一些GOTO语句也是必要的。
用他的话来说就是：
“在有些情形，我主张删掉GOTO语句；
在另外一些情形，则主张引进GOTO语句。
”从此，使这场长达10年之久的争论得以平息。
后来，G·
加科皮尼和C·
波姆从理论上证明了：
任何程序都可以用顺序、分支和重复结构表示出来。
这个结论表明，从高级程序语言中去掉GOTO语句并不影响高级程序语言的编程能力，而且编写的程序的结构更加清晰。
结构程序设计的思想体现在采用了一些比较行之有效的方法，在这些方法中较有代表性的是“逐步求精”方法。
所谓“逐步求精”方法，就是在编制一个程序时，首先考虑程序的整体结构而暂时忽略一些细节问题，然后逐步地一层一层地细化直至用所选用的语言完全描述每一个细节，即得到所期望的程序为止。
换言之，它是按照先全局后局部、先整体后细节、先抽象后具体的过程组织人们的思维活动，使得编写出的程序结构清晰、容易理解、容易验证、容易修改。
“逐步求精”方法与模块化设计方法既有联系又有区别。
粗略地讲，逐步求精主要指一个程序的设计过程，而模块化设计主要指比较大的系统的设计过程。
此外，面对“软件危机”，人们调查研究了软件生产的实际情况，逐步感到采用工程化的方法从事软件系统的研究和维护的必要性，于是与程序设计方法学密切相关的软件工程在1968年应运而生。
软件工程的主要对象是大型软件。
软件工程研究的内容主要包括：
软件质量保证和质量评价；
软件研制和维护的方法、工具、文档；
用户界面的设计以及软件管理等。
软件工程的最终目的是摆脱手工生产软件的状况，逐步实现软件研制和维护的自动化。
软件危机的主要表现：
1.对软件开发成本和进度的估计常常很不准确。
实际成本比估计成本有可能高出一个数量级，实际进度比预期进度拖延几个月甚至几年的现象并不罕见。
这种现象降低了开发组织的信誉。
为赶进度和节约成本所采取的权宜之计往往又损害了软件产品的质量，从而不可避免地引起用户的不满。
2.用户对“已完成的”软件系统不满意的现象经常发生。
软件开发人员常常在对用户需求只有模糊的了解，甚至对所要解决的问题还没有确切认识的情况下，就仓促上阵匆忙着手编写程序。
软件开发人员和用户之间的交流往往很不充分，“闭门造车”必然导致最终产品不符合用户实际需要。
3.软件产品的质量常常靠不住。
软件可靠性和质量保证的确切定量概念刚刚出现，软件质量保证技术（审查、复审和测试）还没有坚持不懈地应用到软件开发的全过程中，这些都会导致软件产品发生质量问题。
4.软件常常是不可维护的。
程序中的错误很难改正，实际上不可能使这些程序适应新的硬件环境，也不能根据用户的需求在原有程序中增加新的功能。
5.软件通常没有适当的文档资料。
软件不仅是程序，还应该有一整套文档资料。
这些文档资料是在软件开发过程中产生出来的，而且应该是“最新的”（与代码完全一致）。
缺乏文档必然给软件的开发和维护带来许多严重的困难和问题。
6.软件成本在计算机系统总成本中所占比例逐年上升。
随着微电子技术的进步和生产自动化程度的提高，硬件成本逐年下降，然而软件开发需要大量的人力，软件成本随着通货膨胀以及软件规模和数量的不断扩大而逐年上升。
美国在1995年的调查表明，软件成本大约已占计算机系统总成本的90%。
软件危机的出现，使得人们去寻找产生危机的内在原因，发现其原因可归纳为两方面，一方面是由软件生产本身存在着复杂性，另一方面却是与软件开发所使用的方法和技术有关。
软件工程正是为克服软件危机而提出的一种概念，并在实践中不断地探索它的原理，技术和方法。
在此过程中，人们研究和借鉴了工程学的某些原理和方法，并形成了一门新的学科─软件工程学，但可惜的是时至今日人们并没有完全克服软件危机。
软件危机softwarecrisis
落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。
概况
20世纪60年代以前，计算机刚刚投入实际使用，软件设计往往只是为了一个特定的应用而在指定的计算机上设计和编制，采用密切依赖于计算机的机器代码或汇编语言，软件的规模比较小，文档资料通常也不存在，很少使用系统化的开发方法，设计软件往往等同于编制程序，基本上是个人设计、个人使用、个人操作、自给自足的私人化的软件生产方式。
60年代中期，大容量、高速度计算机的出现，使计算机的应用范围迅速扩大，软件开发急剧增长。
高级语言开始出现；
操作系统的发展引起了计算机应用方式的变化；
大量数据处理导致第一代数据库管理系统的诞生。
软件系统的规模越来越大，复杂程度越来越高，软件可靠性问题也越来越突出。
原来的个人设计、个人使用的方式不再能满足要求，迫切需要改变软件生产方式，提高软件生产率，软件危机开始爆发。
1968年北大西洋公约组织的计算机科学家在联邦德国召开国际会议，第一次讨论软件危机问题，并正式提出“软件工程”一词，从此一门新兴的工程学科——软件工程学——为研究和克服软件危机应运而生。
现象
早期出现的软件危机主要表现在：
①软件开发费用和进度失控。
费用超支、进度拖延的情况屡屡发生。
有时为了赶进度或压成本不得不采取一些权宜之计，这样又往往严重损害了软件产品的质量。
②软件的可靠性差。
尽管耗费了大量的人力物力，而系统的正确性却越来越难以保证，出错率大大增加，由于软件错误而造成的损失十分惊人。
③生产出来的软件难以维护。
很多程序缺乏相应的文档资料，程序中的错误难以定位，难以改正，有时改正了已有的错误又引入新的错误。
随着软件的社会拥有量越来越大，维护占用了大量人力、物力和财力。
进入80年代以来，尽管软件工程研究与实践取得了可喜的成就，软件技术水平有了长足的进展，但是软件生产水平依然远远落后于硬件生产水平的发展速度。
软件危机不仅没有消失，还有加剧之势。
主要表现在：
①软件成本在计算机系统总成本中所占的比例居高不下，且逐年上升。
由于微电子学技术的进步和硬件生产自动化程度不断提高，硬件成本逐年下降，性能和产量迅速提高。
然而软件开发需要大量人力，软件成本随着软件规模和数量的剧增而持续上升。
从美、日两国的统计数字表明，1985年度软件成本大约占总成本的90％。
②软件开发生产率提高的速度远远跟不上计算机应用迅速普及深入的需要，软件产品供不应求的状况使得人类不能充分利用现代计算机硬件所能提供的巨大潜力。
原因
软件工程研究结果表明，软件危机的原因主要有两方面：
①与软件本身的特点有关。
软件不同于硬件，它是计算机系统中的逻辑部件而不是物理部件；
软件样品即是产品，试制过程也就是生产过程；
软件不会因使用时间过长而“老化”或“用坏”；
软件具有可运行的行为特性，在写出程序代码并在计算机上试运行之前，软件开发过程的进展情况较难衡量，软件质量也较难评价，因此管理和控制软件开发过程十分困难；
软件质量不是根据大量制造的相同实体的质量来度量，而是与每一个组成部分的不同实体的质量紧密相关，因此，在运行时所出现的软件错误几乎都是在开发时期就存在而一直未被发现的，改正这类错误通常意味着改正或修改原来的设计，这就在客观上使得软件维护远比硬件维护困难；
软件是一种信息产品，具有可延展性，属于柔性生产，与通用性强的硬件相比，软件更具有多样化的特点，更加接近人们的应用问题。
随着计算机应用领域的扩大，99％的软件应用需求已不再是定义良好的数值计算问题，而是难以精确描述且富于变化的非数值型应用问题。
因此，当人们的应用需求变化发展的时候，往往要求通过改变软件来使计算机系统满足新的需求，维护用户业务的延续性。
②危机原因来自于软件开发人员的如下弱点：
其一，软件产品是人的思维结果，因此软件生产水平最终在相当程度上取决于软件人员的教育、训练和经验的积累；
其二，对于大型软件往往需要许多人合作开发，甚至要求软件开发人员深入应用领域的问题研究，这样就需要在用户与软件人员之间以及软件开发人员之间相互通讯，在此过程中难免发生理解的差异，从而导致后续错误的设计或实现，而要消除这些误解和错误往往需要付出巨大的代价；
其三，由于计算机技术和应用发展迅速，知识更新周期加快，软件开发人员经常处在变化之中，不仅需要适应硬件更新的变化，而且还要涉及日益扩大的应用领域问题研究；
软件开发人员所进行的每一项软件开发几乎都必须调整自身的知识结构以适应新的问题求解的需要，而这种调整是人所固有的学习行为，难以用工具来代替。
软件生产的这种知识密集和人力密集的特点是造成软件危机的根源所在。
从软件开发危机的种种表现和软件开发作为逻辑产品的特殊性可以发现软件开发危机的原因：
（1）用户需求不明确
在软件开发过程中，用户需求不明确问题主要体现在四个方面：
在软件开发出来之前，用户自己也不清楚软件开发的具体需求；
用户对软件开发需求的描述不精确，可能有遗漏、有二义性、甚至有错误；
在软件开发过程中，用户还提出修改软件开发功能、界面、支撑环境等方面的要求；
软件开发人员对用户需求的理解与用户本来愿望有差异。
（2）缺乏正确的理论指导
缺乏有力的方法学和工具方面的支持。
由于软件开发不同于大多数其他工业产品，其开发过程是复杂的逻辑思维过程，其产品极大程度地依赖于开发人员高度的智力投入。
由于过分地依靠程序设计人员在软件开发过程中的技巧和创造性，加剧软件开发产品的个性化，也是发生软件开发危机的一个重要原因。
（3）软件开发规模越来越大
随着软件开发应用范围的增广，软件开发规模愈来愈大。
大型软件开发项目需要组织一定的人力共同完成，而多数管理人员缺乏开发大型软件开发系统的经验，而多数软件开发人员又缺乏管理方面的经验。
各类人员的信息交流不及时、不准确、有时还会产生误解。
软件开发项目开发人员不能有效地、独立自主地处理大型软件开发的全部关系和各个分支，因此容易产生疏漏和错误。
（4）软件开发复杂度越来越高
软件开发不仅仅是在规模上快速地发展扩大，而且其复杂性也急剧地增加。
软件开发产品的特殊性和人类智力的局限性，导致人们无力处理“复杂问题”。
所谓“复杂问题”的概念是相对的，一旦人们采用先进的组织形式、开发方法和工具提高了软件开发效率和能力，新的、更大的、更复杂的问题又摆在人们的面前。
解决途径
软件工程诞生于60年代末期，它作为一个新兴的工程学科，主要研究软件生产的客观规律性，建立与系统化软件生产有关的概念、原则、方法、技术和工具，指导和支持软件系统的生产活动，以期达到降低软件生产成本、改进软件产品质量、提高软件生产率水平的目标。
软件工程学从硬件工程和其他人类工程中吸收了许多成功的经验，明确提出了软件生命周期的模型，发展了许多软件开发与维护阶段适用的技术和方法，并应用于软件工程实践，取得良好的效果。
在软件开发过程中人们开始研制和使用软件工具，用以辅助进行软件项目管理与技术生产，人们还将软件生命周期各阶段使用的软件工具有机地集合成为一个整体，形成能够连续支持软件开发与维护全过程的集成化软件支援环境，以期从管理和技术两方面解决软件危机问题。
此外，人工智能与软件工程的结合成为80年代末期活跃的研究领域。
基于程序变换、自动生成和可重用软件等软件新技术研究也已取得一定的进展，把程序设计自动化的进程向前推进一步。
在软件工程理论的指导下，发达国家已经建立起较为完备的软件工业化生产体系，形成了强大的软件生产能力。
软件标准化与可重用性得到了工业界的高度重视，在避免重用劳动，缓解软件危机方面起到了重要作用。
软件危机的形成
1.硬件生产率大幅提高
如今，计算机的发展已进入一个新的历史阶段；
硬件产品已系列化、标准化，"
即插即用"
。
硬件产品的生产可以采用最高精尖的现代化工具和手段、自动成批生产。
生产效率几百万倍的提高。
生产能力过剩。
2.软件生产随规模增大复杂度增大
以美国宇航局的软件系统为例：
1963年水星计划系统200万条指令
1967年双子星座计划系统400万条指令
1973年阿波罗计划系统1000万条指令
1979年哥伦比亚航天飞机系统4000万条指令
假设1个人一年生产一万条有效指令，那么是否4000人生产一年，或400人生产10年就能完成任务呢？
答案是否定的。
一万条指令的复杂度决不仅仅是100条指令复杂度的100倍。
3.软件生产率很低
伴随计算机的普及，整个社会对计算机应用的需求越来越大。
但软件的生产却还沿用"
手工作坊"
的生产方式，人工编程生产。
生产效率仅提高了几倍。
生产能力极其低下。
4.硬、软件供需失衡
社会大量需求，生产成本高，生产过程控制复杂，生产效率低等等因素构成软件生产的恶性循环。
由此产生"
软件危机"
5.矛盾引发"
软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
为了研究、解决软件危机，诞生了一门新兴学科--软件工程学。
它把软件作为工程对象，从技术措施和组织管理两个方面来研究、解决软件危机。
软件危机的具体体现
1.软件开发进度难以预测
拖延工期几个月甚至几年的现象并不罕见，这种现象降低了软件开发组织的信誉。
以丹佛新国际机场为例:
该机场规模是曼哈顿机场的两倍，宽为希思机场的10倍，可以全天侯同时起降三架喷气式客机；
投资1.93亿美元建立了一个地下行李传送系统，总长21英里，有4，000台遥控车，可按不同线路在20家不同的航空公司柜台、登机门和行李领取处之间发送和传递行李；
支持该系统的是5，000个电子眼、400台无线电接受机、56台条形码扫描仪和100台计算机。
按原定计划要在1993年万圣节前启用，但一直到1994年6月，机场的计划者还无法预测行李系统何时能达到可使机场开放的稳定程度。
2.软件开发成本难以控制
投资一再追加，令人难于置信。
往往是实际成本比预算成本高出一个数量级。
而为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的质量，从而不可避免地会引起用户的不满。
3.用户对产品功能难以满足
开发人员和用户之间很难沟通、矛盾很难统一。
往往是软件开发人员不能真正了解用户的需求，而用户又不了解计算机求解问题的模式和能力，双方无法用共同熟悉的语言进行交流和描述。
在双方互不充分了解的情况下，就仓促上阵设计系统、匆忙着手编写程序，这?
quot;
闭门造车"
的开发方式必然导致最终的产品不符合用户的实际需要。
4.软件产品质量无法保证
系统中的错误难以消除。
软件是逻辑产品，质量问题很难以统一的标准度量，因而造成质量控制困难。
软件产品并不是没有错误，而是盲目检测很难发现错误，而隐藏下来的错误往往是造成重大事故的隐患。
5.软件产品难以维护
软件产品本质上是开发人员的代码化的逻辑思维活动，他人难以替代。
除非是开发者本人，否则很难及时检测、排除系统故障。
为使系统适应新的硬件环境，或根据用户的需要在原系统中增加一些新的功能，又有可能增加系统中的错误。
6.软件缺少适当的文档资料
文档资料是软件必不可少的重要组成部分。
实际上，软件的文档资料是开发组织和用户的之间权利和义务的合同书，是系统管理者、总体设计者向开发人员下达的任务书，是系统维护人员的技术指导手册，是用户的操作说明书。
缺乏必要的文档资料或者文档资料不合格，将给软件开发和维护带来许多严重的困难和问题。
最典型失败系统的例子是：
IBM公司开发OS/360系统，共有4000多个模块，约100万条指令，投入5000人年，耗资数亿美元，结果还是延期交付。
在交付使用后的系统中仍发现大量（2000个以上）的错误。
1968年在德国召开的NATO（NorthAtlanticTreatyOrganization,北大西洋公约组织）会议上首次提出了“软件工程”概念，希望用工程化的原则和方法来克服软件危机
WelcomeTo
Download
欢迎您的下载，资料仅供参考！
升级会员 