软件危机事件(软件危机事件有哪些)

有哪些软件危机的案例?

比如,你打开一个软件,正准备使用.突然性关闭了.还有就是用到一半.又没保存也突然关闭了.

有谁有软件危机的案例啊?谢谢各路神仙啦

比如说最近的诺顿“误杀门”事件等等,

软件危机的例子

其实不用特别选例子,千年虫问题就是一个经典啊. 可以参考下面网站的软件部分: http://baike.baidu.com/view/9349.htm

关于诺顿危机你的看法~

诺顿杀毒软件说识别病毒吗,还是可以的有这么厉害的.查毒有这么厉害,杀毒主要靠隔离,如果你吧隔离区的文件恢复的话,诺顿立即删除了.诺顿这次误杀,给那些使用诺顿杀毒软件的人带来了特大的麻烦,看来国外的东西并不一定好,在以前卡巴斯基才来中国的时候,大家都说卡巴斯基好,现在呢?乌龙事件出了N次了.还不如使用国产来个安心呢.

千年虫问题

千年虫 Millennium Bug 计算机2000年问题，又叫做”2000年病毒”、”千年虫”、”电脑千禧年问题”或”千年病毒”.是指在某些使用了计算机程序的智能系统(包括计算机系统、自动控制芯片等)中，由于其中的年份只使用两位十进制数来表示，因此当系统进行(或涉及到)跨世纪的日期处理运算时(如多个日期之间的计算或比较等)，就会出现错误的结果，进而引发各种各样的系统功能紊乱甚至崩溃。另外，更广泛地讲，“千年虫”还包括以下两个方面的问题：一个是在一些计算机系统中，对于闰年的计算和识别出现问题，不能把2000年识别为闰年，即在该计算机系统的日历中没有2000年2月29日这一天，而是直接由2000年2月28日过渡到了2000年3月1 日；另一个是在一些比较老的计算机系统中，在程序中使用了数字串99(或99/99等)来表示文件结束、永久性过期、删除等一些特殊意义的自动操作，这样当1999年9月9日(或1999年4 月9日即1999年的第99天)来临时，计算机系统在处理到内容中有日期的文件时，就会遇到99 或99/99等数字串，从而将文件误认为已经过期或者将文件删除等错误操作，引发系统混乱甚至崩溃等故障。 “千年虫”问题的根源始于60年代。当时计算机存储器的成本很高，如果用四位数字表示年份，就要多占用存储器空间，就会使成本增加，因此为了节省存储空间，计算机系统的编程人员采用两位数字表示年份。随着计算机技术的迅猛发展，虽然后来存储器的价格降低了，但在计算机系统中使用两位数字来表示年份的做法却由于思维上的惯性势力而被沿袭下来，年复一年，直到新世纪即将来临之际，大家才突然意识到用两位数字表示年份将无法正确辨识公元2000年及其以后的年份。1997年，信息界开始拉起了“千年虫”警钟，并很快引起了全球关注。 “千年虫”影响是巨大的。从计算机系统包括PC机的BIOS、微码到操作系统、数据库软件、商用软件和应用系统等，到与计算机和自动控制有关的电话程控交换机、银行自动取款机、保安系统、工厂自动化系统等，乃至使用了嵌入式芯片技术的大量的电子电器、机械设备和控制系统，等等，都有可能受到“千年虫”的攻击。目前世界各国已纷纷由政府出面，全力围歼“千年虫”。

研究报告主要包括哪些内容

一个可行性研究报告的主要内容如下：

（1）引言：说明编写本文档的目的；项目的名称、背景；本文档用到的专门术语和参考资料。

（2）可行性研究前提：可行性研究前提。说明开发项目的功能、性能和基本要求；达到的目标；各种限制条件；可行性研究方法和决定可行性的主要因素。

（3）对现有系统的分析：说明现有系统的处理流程和数据流程；工作负荷；各项费用支出；所需要各类专业技术人员的数量；所需要各种设备；现有系统存在什么问题。

（4）所建议系统的技术可行性分析：所建议系统的简要说明；处理流程和数据流程；与现有的系统比较的优越性；采用所建议系统对用户的影响；对各种设备、现有软件、开发环境、运行环境的影响；对经费支出的影响；对技术可行性的评价。

（5）所建议系统的经济可行性分析：说明所建议系统的各种支出，各种效益；收益投资比；投资回收周期。

（6）社会因素可行性分析：说明法律因素，对合同责任、侵犯专利权、侵犯版权等问题的分析；说明用户使用可行性，是否满足用户行政管理、工作制度、人员素质的要求。

（7）其他可供选择方案：逐一说明其他可供选择的方案，并说明未被推荐的理由。

（8）结论意见：说明项目是否能开发；还需要什么条件才能开发；对项目目标有什么变动等。

〔解析〕做软件的可行性研究的目的就是用最小的代价在尽可能短的时间内确定该软件项目是否能够开发，是否值得去开发，其中的问题能否解决，报告共分为八个基本内容。

2.系统设计的内容是什么？

解：系统设计阶段先从高层入手，然后细化。系统设计要决定整个结构及风格，这种结构为后面设计阶段的更详细策略的设计提供了基础。

（1）系统分解。系统中主要的组成部分称为子系统，子系统既不是一个对象也不是一个功能，而是类、关联、操作、时间和约束的集合。每次分解的各子系统数目不能太多，最底层子系统称为模块。

（2）确定并发性。分析模型、现实世界及硬件中不少对象均是并发的。系统设计的一个重要目标就是确定哪些是必须同时动作的对象，哪些不是同时动作的对象。后者可以放在一起，而综合成单个控制线或任务。

（3）处理器及任务分配。各并发子系统必须分配给单个硬件单元，要么是一个一般的处理器，要么是一个具体的功能单元，必须完成下面的工作：估计性能要求和资源需求，选择实现子系统的硬软件，将软件子系统分配给各处理器以满足性能要求和极小化处理器之间的通信，决定实现各子系统的各物理单元的连接。

（4）数据存储管理。系统中的内部数据和外部数据的存储管理是一项重要的任务。通常各数据存储可以将数据结构、文件、数据库组合在一起，不同数据存储要在费用、访问时间、容量以及可靠性之间做折中考虑。

（5）全局资源的处理。必须确定全局资源，并且制定访问全局资源的策略。全局资源包括：物理资源，如处理器、驱动器等；空间，如盘空间、工作站屏等；逻辑名字，如对象标识符、类名、文件名等。

如果资源是物理对象，则可以通过建立协议实现对并发系统的访问，以达到自身控制；如果资源是逻辑实体，如对象标识符，那么在共享环境中有冲突访问的可能，如独立的事务可能同时使用同一个对象标识符，则各个全局资源都必须有一个保护对象，由保护对象来控制对该资源的访问。

（6）选择软件控制机制。分析模型中所有交互行为都表示为对象之间的事件。系统设计必须从多种方法中选择某种方法来实现软件的控制。

（7）人机交互接口设计。设计中的大部分工作都与稳定的状态行为有关，但必须考虑用户使用系统的交互接口。

〔解析〕系统设计是问题求解及建立解答的高级策略。必须制定解决问题的基本方法，系统的高层结构形式包括子系统的分解、它的固有并发性、子系统分配给硬软件、数据存储管理、资源协调、软件控制实现、人机交互接口。

3.什么是软件危机？软件危机的表现是什么？其产生的原因是什么？

解：软件发展第二阶段的末期，由于计算机硬件技术的进步，计算机运行速度、容量、可靠性有显著的提高，生产成本显著下降，这为计算机的广泛应用创造了条件。一些复杂的、大型的软件开发项目提出来了，但是，软件开发技术的进步一直未能满足发展的需要。在软件开发中遇到的问题找不到解决办法，使问题积累起来，形成了尖锐的矛盾，因而导致了软件危机。

软件危机表现在以下四个方面：

（1）经费预算经常突破，完成时间一再拖延。由于缺乏软件开发的经验和软件开发数据的积累，使得开发工作的计划很难制定。主观盲目制定计划，执行起来与实际情况有很大差距，使得开发经费一再突破。由于对工作量估计不足，对开发难度估计不足，进度计划无法按时完成，开发时间一再拖延。

（2）开发的软件不能满足用户要求。开发初期对用户的要求了解不够明确，未能得到明确的表达。开发工作开始后，软件人员和用户又未能及时交换意见，使得一些问题不能及时解决，导致开发的软件不能满足用户的要求，因而导致开发失败。

（3）开发的软件可维护性差。开发过程中没有同意的、公认的规范，软件开发人员按各自的风格工作，各行其是，开发过程无完整、规范的文档，发现问题后进行杂乱无章的修改。程序结构不好，运行时发现错误也很难修改，导致维护性差。

（4）开发的软件可靠性差。由于在开发过程中，没有确保软件质量的体系和措施，在软件测试时，又没有严格的、充分的、完全的测试，提交给用户的软件质量差，在运行中暴露出大量的问题。

造成软件危机的原因是：

（1）软件的规模越来越大，结构越来越复杂。

（2）软件开发管理困难而复杂。

（3）软件开发费用不断增加。

（4）软件开发技术落后。

（5）生产方式落后。

（6）开发工具落后，生产率提高缓慢。

〔解析〕由于软件危机的出现，人们才开始用工程化的思想来开发软件，从此，软件生产才步入了软件工程时代。

4.软件质量保证应做好哪几方面的工作？

解：软件质量保证是软件工程管理的重要内容，软件质量保证应做好以下几方面的工作：

（1）采用技术手段和工具。质量保证活动要贯彻开发过程始终，必须采用技术手段和工具，尤其是使用软件开发环境来进行软件开发。

（2）组织正式技术评审。在软件开发的每一个阶段结束时，都要组织正式的技术评审。国家标准要求单位必须采用审查、文档评审、设计评审、审计和测试等具体手段来保证质量。

（3）加强软件测试。软件测试是质量保证的重要手段，因为测试可发现软件中大多数潜在错误。

（4）推行软件工程规范（标准）。用户可以自己制定软件工程规范（标准），但标准一旦确认就应贯彻执行。

（5）对软件的变更进行控制。软件的修改和变更常常会引起潜伏的错误，因此必须严格控制软件的修改和变更。

（6）对软件质量进行度量。即对软件质量进行跟踪，及时记录和报告软件质量情况。

〔解析〕软件的质量保证是向用户及社会提供满意的高质量的产品，确保软件产品从诞生到消亡为止的所有阶段的质量的活动，是软件工程管理中的重要内容。

实施CMM/CMMI时必须解决的认识问题

在软件工程发展的历史进程中，人们为了解决软件危机，尝试了采用诸如形式化描述语言、结构化开发方法、CASE工具、构件化开发方法等等各种解决方案，但是效果并不那么显著，CMU SEI提出了软件过程能力成熟度模型（CMM/CMMI）基于过程的角度来解决软件危机。那么是否实施了CMM/CMMI，软件企业的开发能力就一定能提高，一定能带来经济效益呢？答案是否定的。如果企业里要带来经济效益必须要结合软件过程、工具、开发方法、人员等多种因素一起提高，才能保证带来经济效益，因为人员、技术和过程是支撑软件开发平台的三条腿，少了那一条都不行。大家也都知道木桶原理，一个木桶可存槠水的最大容量是由最短的那根木头决定的。在企业的开发能力中过程、技术(含工具、方法)、人员都是主要的因子，都需要全面提高，只关注一个方面，而忽略了其他方面，都是有害的。

在开始实施CMM/CMMI时，最容易犯的一个错误就是”唯管理论”或孤立地只抓过程改善，忽略了开发技术与人员的提高，过分强调管理的作用，实施了半年或一年后，发现企业的生产能力并没有得到明显的改善，这时反对的声音就会成为主流，过程改善就难以继续进行了。有的企业采用面向对象的开发方法进行软件开发，但是企业内并没有对面向对象技术真正了解的专家，虽然也采用RUP过程、也采用ROSE等开发工具，但是仅仅是形似，没有做到真正的OO方法，没有得到OO方法的精髓，这种问题仅仅依靠过程改善是无法解决的。还有的企业开发人员的积极性很差，工作热情很低，企业的激励机制没有起到很好的作用，这种问题也是依靠CMM/CMMI无法解决的。

管理就是预防，管理的作用是隐性的，不都是立竿见影的，大家要有耐心

在实施CMM/CMMI时，企业的管理层在开始时往往会对过程改善期望值太高，希望短时间内效果显著，上面我们谈到了，效果显著与否不是由一个方面的要素决定的，需要多个因素共同改善。而管理的最大作用是预防，防患于未然。

任何的管理的改善都是符合J曲线的，即在改善的初期企业的运行效率可能会下降，甚至可能会出现一些混乱的局面，不过渡过了这段时间就会看到效果。所以在改善的初期大家要有这个思想准备，要有耐心。

坚持活学活用，以我为主

机械照搬CMM/CMMI的条文是在实施CMM/CMMI时常犯的错误。在国内的软件企业中，都是从作坊式的软件组织逐步发展过来的，也没有经过软件工程化阶段，甚至也没有什么标准、规范。真正超过10年软件工程经验的人员更是比较少的，加上大家不愿从事管理，因而有的企业所组建SEPG的人员中可能在工程经验方面是有欠缺的，又没有真正的有实践经验的专家进行指导，所以对CMM/CMMI的理解就不可能一下就很深刻，不敢裁剪CMM/CMMI，容易机械照搬CMM/CMMI条文，其实这恰恰违背了CMM/CMMI的精神，CMM/CMMI是软件工程经验的集大成，是从实践中总结出来，用以指导实践的，CMM/CMMI本身也在更新版本，不断完善。每个企业都有自己的特点，就象微软的MSF，那是微软自己内部的管理过程标准，是微软的产品开发经验总结，有些内容是CMM/CMMI中没有的，完全可以借鉴过来使用，所以只要可以提高企业自己的软件管理水平，就应该大胆地来尝试。

在推行CMM/CMMI时，所以遇到的阻力，很大程度上是由于照搬CMM/CMMI的条文，不切合项目组的实际，没有具体情况具体分析。实际上，一线的管理人员、开发人员最了解实际。谁了解实际，谁有发言权。所以在制定CMM/CMMI规程标准时，尤其是在制定大家要执行的操作规程、模板和记录表样时，一定要得到执行者的认同，否则就容易造成执行和沟通的障碍，你硬要推，表面上看来似乎大伙也照规程做了，其实是表面文章，对改善没有实际帮助，以导致SPI工作受阻。

要改良式不要革命式

以革命的方式来实施CMM/CMMI，期望通过一场运动来解决过程能力的问题，一种可能是不懂CMM/CMMI，不晓得管理的改进是循序渐进的，一种可能是明知故犯，期望在短期内通过CMM/CMMI评估，单纯追求市场上的轰动效应。有的企业在短时间内虽通过了CMM/CMMI几级评估，我想恐怕由于没有实效而得不到大家的认同而难以将这种”水平”持续下去。一个企业引入CMM/CMMI之后会从本质上影响企业的文化，改变大家的思想与做事方法。有人曾形象得将过程改进比喻为减肥，你是可以依靠减肥药在短时间内减轻体重，但如果不从根本上改善饮食、生活、运动的习惯，那么体重将会在短时间内恢复到原来，我认为这个比喻是十分形象的。

革命的方式与改良的方式我都曾经尝试过，效果差异很大。所以我总结一条就是让大家在”小步快跑”中接受变革，这样风险最小，效果最好。

CMM/CMMI与企业的创新文化是不矛盾的

软件企业的有些管理人员，也包括一些开发人员往往抱怨或认为严格的管理会束缚他们的创新，他们认为在CMM/CMMI中提倡的一种按部就班，什么活动都要做计划、按规程标准来做，对企业的创新文化会起负面作用。在我遇到的开发人员中，越是技术钻研越深的人持这种观点的越多。我想形成这种观点主要有二个原因：一是企业在推行CMM/CMMI时，过分机械，没有从实际出发，不能与实践紧密结合，挫伤了开发人员的积极性。比如说在分析与设计阶段，需要开发人员能够发挥创意的成分更大一些，如果你要求他们一定就要按统一的文档标准来写文档，甚至字号大小、缩进格式一点也不能差，这的确很难做到，可能你需要在项目组配备文档支持人员，有他们来做这些完善工作，降低分析与设计人员的这些工作量。二是这类人员缺少真正的软件工程经验，做的大项目太少，经历的失败太少。关于这一点是不要争论的，CMM/CMMI是软件工程经验与教训的集大成，我们无需再去重复那些失败。

软件企业必须形成创新的文化，事实CMM/CMMI本身也一种软件工程管理的创新，而技术创新是必须进行管理才能使其有效地转化为生产力，转化为企业的实际效益，达到效益最大化，这是最根本的。

要勇于实践，也要允许犯错误

CMM/CMMI就是软件工程经验与教训的总结。在实施CMM/CMMI的过程中，肯定会走些弯路，甚至于要犯错误，由此许多人会议论纷纷，一直会反映到高层经理处，这时不要犹豫，要敢于尝试，更不能因为有困难就打退堂鼓，现在大家都是”摸着石头过河”，不下水，是没有办法过河的，临渊慕鱼不如退而结网。要少说不，少说难，勇于实践，有错就改。对于软件企业的领导尤其要注意这一点，不要因为在过程中的一些实践失败，就对项目经理、SEPG等人员有偏见，要提倡这种文化。

管理过程改进是组织内所有人的事情，而并非仅仅是SEPG的事情

按照CMM/CMMI专家的建议，在一个组织内专职从事软件过程改善的人数应为组织总人数的2-3%，根据这一建议，我们企业内一开始就配备专职的软件工程过程组（SEPG），这些员工专职负责企业的软件过程改善工作，另外我们根据需要组织一些技术任务组（TWG），他们会兼职的参与特定过程规程、标准的制定、试点和修改完善工作。在这种情况，可能会出现如下的问题：

SEPG成了最忙的人，TWG的任务往往会由于那些兼职的人员以工作忙为理由一拖再拖，最后还是由SEPG的成员替代TWG做工作；