软件工程理论的来源

A. 软件工程

开发软件并不简单只是编编程序（如果是那样，初、高中生就能完成了，要我们这些大学生干嘛），就象做生意（比如开商店），你总不会认为开商店就是站那儿卖货吧，你得先进行市场调研，再选店址，然后上货，卖货，当然还有售后服务），这是一个复杂的，系统的工程，一般包括以下几项：客户需求调查或市场调查、软件的框架设计、各框架的进一步细分，编写程序（内容很多，比如用什么语言，面向什么，设计模式等等），黑白盒测试，发布测试版，软件的交付以及售后服务，还有各阶段的文档总结（包括软件的帮助文件，注释等等），总之，就是一个软件从调研到最后发布的各中间过程，软件工程就是对这各种阶段的说明以及如何去实施各阶段，学好了它，对你今后的软件工程师之路是非常有用的，也是必需的。

B. 急需！简述你对软件工程理论的来源、作用和意义的认识。谢谢！

不知道是否正确
1995年,Standish
Group针对系统开发成功的研究表明,所有的开发项目中有32%的项目在它们结束之前被中止.此外多于一半的软件项目花费的成本相当于原来预算的2倍，只有42%的软件项目完成时达到了预期的范围和功能,事实上,许多系统只完成了部分预期的需求.因此,软件的开发是一个很困难的活动,要求很仔细的计划和执行.软件工程就是在这样的背景下,由许多计算机科学家经过多方面的探索和总结而成形的.软件工程是计算机专业的一门重要的专业基础课,它对于培养学生的软件素质,提高学生的软件开发能力与软件项目管理能力具有重要的意义. 近二十年来计算机软件已经成为现代科学研究和解决工程问题的基础,以及管理部门,生产部门,和服务行业中的关键因素,渗透到了各个领域,成为当今世界不可缺少的一部分.

C. 软件工程的原理

自从1968年提出“软件工程”这一术语以来，研究软件工程的专家学者们陆续提出了100多条关于软件工程的准则或信条。美国著名的软件工程专家巴利·玻姆（Barry Boehm）综合这些专家的意见，并总结了美国天合公司（TRW）多年的开发软件的经验，于1983年提出了软件工程的七条基本原理。
玻姆认为，这七条原理是确保软件产品质量和开发效率的原理的最小集合。它们是相互独立的，是缺一不可的最小集合；同时，它们又是相当完备的。人们当然不能用数学方法严格证明它们是一个完备的集合，但是可以证明，在此之前已经提出的100多条软件工程准则都可以有这七条原理的任意组合蕴含或派生。
下面简要介绍软件工程的七条原理：
用分阶段的生命周期计划严格管理
这一条是吸取前人的教训而提出来的。统计表明，50%以上的失败项目是由于计划不周而造成的。在软件开发与维护的漫长生命周期中，需要完成许多性质各异的工作。这条原理意味着，应该把软件生命周期分成若干阶段，并相应制定出切实可行的计划，然后严格按照计划对软件的开发和维护进行管理。
玻姆认为，在整个软件生命周期中应指定并严格执行6类计划：
项目概要计划、
里程碑计划、
项目控制计划、
产品控制计划、
验证计划、
运行维护计划。
坚持进行阶段评审
统计结果显示：大部分错误是在编码之前造成的，大约占63%错误发现的越晚，改正它要付出的代价就越大，要差2到3个数量级。 因此，软件的质量保证工作不能等到编码结束之后再进行，应坚持进行严格的阶段评审，以便尽早发现错误。
实行严格的产品控制
开发人员最痛恨的事情之一就是改动需求。但是实践告诉我们，需求的改动往往是不可避免的。这就要求我们要采用科学的产品控制技术来顺应这种要求。也就是要采用变动控制，又叫基准配置管理。当需求变动时，其它各个阶段的文档或代码随之相应变动，以保证软件的一致性。
采纳现代程序设计技术
从六、七十年代的结构化软件开发技术，到最近的面向对象技术，从第一、第二代语言，到第四代语言，人们已经充分认识到：方法大于气力。采用先进的技术既可以提高软件开发的效率，又可以减少软件维护的成本。
结果应能清楚地审查
软件是一种看不见、摸不着的逻辑产品。软件开发小组的工作进展情况可见性差，难于评价和管理。为更好地进行管理，应根据软件开发的总目标及完成期限，尽量明确地规定开发小组的责任和产品标准，从而使所得到的标准能清楚地审查。
开发小组的人员应少而精
开发人员的素质和数量是影响软件质量和开发效率的重要因素，应该少而精。这一条基于两点原因：高素质开发人员的效率比低素质开发人员的效率要高几倍到几十倍，开发工作中犯的错误也要少的多；当开发小组为N人时，可能的通信信道为N(N-1)/2, 可见随着人数N的增大，通讯开销将急剧增大。
承认不断改进软件工程实践的必要性
遵从上述六条基本原理，就能够较好地实现软件的工程化生产。但是，它们只是对现有的经验的总结和归纳，并不能保证赶上技术不断前进发展的步伐。因此，玻姆提出应把承认不断改进软件工程实践的必要性作为软件工程的第七条原理。根据这条原理，不仅要积极采纳新的软件开发技术，还要注意不断总结经验，收集进度和消耗等数据，进行出错类型和问题报告统计。这些数据既可以用来评估新的软件技术的效果，也可以用来指明必须着重注意的问题和应该优先进行研究的工具和技术。

D. 什么是软件工程的核心思想

软件工程的核心思想是：在给定成本、进度的前提下，开发出具有适用性、有效性、可修改性、可靠性、可理解性、可追踪性、可互操作性和满足用户需求的软件产品。

软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。

它涉及到程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。

但是软件工程一直以来都缺乏一个统一的定义，很多学者、组织机构都分别给出了自己的定义：

BarryBoehm：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。

FritzBauer：在NATO会议上给出的定义：建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。

(4)软件工程理论的来源扩展阅读：

软件工程有以下四项基本原则：

1、选取适宜开发范型。

在系统设计中，软件需求、硬件需求以及其他因素之间是相互制约、相互影响的，经常需要权衡。因此，必须认识需求定义的易变性，采用适宜的开发范型予以控制，以保证软件产品满足用户的要求。

2、采用合适的设计方法。

在软件设计中，通常要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征。合适的设计方法有助于这些特征的实现，以达到软件工程的目标。

3、提供高质量的工程支持。

在软件工程中，软件工具与环境对软件过程的支持颇为重要。软件工程项目的质量与开销直接取决于对软件工程所提供的支撑质量和效用。

4、重视开发过程的管理。

软件工程的管理，直接影响可用资源的有效利用，生产满足目标的软件产品，提高软件组织的生产能力等问题。因此，仅当软件过程得以有效管理时，才能实现有效的软件工程。

E. 软件工程 计算机软件与理论

你好，我念的是软件工程。事实上，楼上说的对，计算机科学与技术其实和软件工程开的课基本都是一样的（大多数课都一样，但是用的教材不同，我们院就是有些课软工是国外教材，计科是国内教材），出来找工作也是一样的。只是软件工程从大二就有实习，所以学费比计科贵的多。总的来说，都是一样的，不影响考研的。计科学的面会广些，软工实习多些。

F. 软件工程学科涉及哪些理论和方法

(一软件工程学科已发展为计算机科学与技术、数学、工程学、管理学等相关学科的交 叉性学科。传统的计算机科学与技术学科已经涵盖不了软件工程可归属的二级学科问题, 不适应软件产业对软件工程人才培养的需要。

(二软件工程学科已形成较完整的理论与工程技术体系,课程体系基本明确,高端人才 培养能力基本形成,创新型复合型人才的社会需求不断提高。

(三软件工程涉及软件产业、信息产业和现代服务业,代表未来社会产业发展方向。

(四现有软件工程人才培养体系不完整,需要通过进一步学科建设方能适应产业发展对 高端人才的需求。

G. 为什么需要软件工程理论

�匦路⑾秩砑�こ痰谋局省�acobson等撰写了三篇文章详细阐述Semat思想，本刊将陆续刊载，本文是其中第二篇。
这种行为可以从很多地方看出来，很多团队草率地丢弃昂贵的过程和工具的投资，甚至在尝试它们之前。每个项目都采用新方法。每次工作发生变化，在手头真正的工作取得进展前，他们必须学习新方法。这是没有效率的，人们不能从经验中学习，因为他们永远从头开始。底线是，没有什么新事物能够被适当地固定下来即使经过几种现代软件开发趋势，最流行的软件开发方法仍然是规范型的瀑布开发或自由hacking。作为一个行业，我们没有什么真正可以坚守的东西，而且一切似乎没有什么变化。
最新横扫行业的趋势是敏捷。现在，我们可以很明确地说，敏捷运动对软件产业做出了非常积极的 [1] 贡献。它提醒我们，软件开发中，人是第一位的，也是最重要的。事实上，这不是什么新观念，但这是重要的，而且这一点似乎被以前更加技术导向的趋势所忽视，比如说面向对象和Java编程。通过展现一系列优点，敏捷宣言创造了某种强健和适应力强的东西，可以抵挡下一次趋势带来的变革风浪。[2]许多声称支持敏捷哲学的敏捷方法，却没能做到这一点，这是非常让人遗憾的。对一项将人的价值放在过程和工具之上的运动来说，这确实带给了我们很多新的过程和工具。其中的大部分已经显示出效率，通过将团队带回到之前完成的开发软件工作。但在重新聚焦到这上面之前，许多人已经迷失或迷茫，因为将新术语引入旧事物后，让人觉得这一切似乎是全新的。这个对旧思想的不断重新包装和品牌重树让软件开发团队的工作方式剧烈摇摆。对他们的工作和产品任意命名，而不是让人们远离浪费时间的工作，将精力重新聚焦在对高质量软件的开发上。
即使有些方法能够像敏捷哲学一样正确、有益，但相关的信息可能会在摇摆和炒作中丢失。我们已经开始看到对敏捷的反弹，我们担心的是利益将会丢失，当早期使用者投入下一个趋势，而晚期大众则重新主张自己的权利，拒绝采纳这些显然不再流行的东西。
有可能会发生的事情是，我们增加更多时髦的词汇和相互冲突的名词，最终为这一切喧嚣所累!
很显然，我们需要停止对流行和永远令人失望的简单答案的追逐，同时不能阻碍创新和新想法。为了做到这一点，人们需要停止对旧思想不断重新包装和品牌重树。相反，他们应侧重于帮助人们了解如何建立优秀的软件。但我们如何才能重点推动这一变化?我们认为，这个理论就在眼前我们要做的只是抓住它。首先，我们应该从所有流行的方法、过程和实践开始，并从中提炼出软件工程的真理。然后，我们可以描述和捕捉一个最小集合的基本概念，以最小独立过程的形式我们将这个本质物的最小集合称之为内核。
然后以这个内核为出发点，我们可以分析现有的过程和方法，并确定它们所包含的实践。从内核开始，我们可以找到一种描述实践的方式，使它们能够进行比较和结合。
现在所说的这种创造理论的方法本身并不是理论。这是我们已经做过的事情。通过研究一些方法，包括XP、Scrum和统一过程，我们的团队已经确定了20多个内核元素，我们总是做的事情或产生的东西。从表面上看，在这些被研究的方法和我们的工作方式中，有可能会出现很大差异;但在实质上，它们有相同的DNA。举例来说，你可以捕捉功能或用例或用户故事的条件，你可以在没有生命周期与统一过程的生命周期，甚至瀑布生命周期(就像有些人仍然在坚持的那样)的情况下使用这些条件。这些方法肯定有一个共同基础，能够以小的简单的内核要素集的形式被捕获。
现在，还不能冒失地声称，我们的内核提供了必要的理论。需要有比我们更多、更大的头脑来做到这一点。但是，我们会将它作为一项证据，证明它的能力和我们需要的理论就近在眼前。
许多大公司都有自己的方法或过程，也就是一系列标准方法，搭配自己对更具体业务的想法。这些过程通常要用一本厚书或网站来介绍，大量资金被投入到归档工作中。有时，人们被训练使用这些过程，有时只是被简单告知它们在哪儿。在现实中，过程常常被忽视;仅有的被实际使用的部分是，组织中形成了口头传统的那些。这被解释成重新发现的自然法则：人们不看过程的书籍。新的思路引入到组织中，旧过程退出流行，而有关它们的书成为摆设。
在某些大公司甚至会出现多个过程。例如，大型系统集成商可能有十个或二十个不同的过程。有时它们很相似，但相似性背后隐藏着差异。
如果贵公司采用这种实践观，你就不需要因为一些新的性感的东西正成为流行，而抛弃整个工作方式。相反，你只需要对现有的工作方式进行改进，一次改进一个实践。你甚至可以采取那些被其他公司使用的实践，而不用丢掉似乎运作良好的现有实践。作为开始，你需要将现在的工作方式看作一个实践集合。然后寻找你的痛点，然后修补目前的工作方式，通过删除没用的实践，代之以解决这些薄弱环节的实践。一旦你理解了内核和它的使用，就很容易做到这一点。在具有多种不同工作方式的大型组织，你可以使用此方法先后改进每个工作方式，而不必强迫大家使用相同的方法或过程。
这种做法将使新实践更容易被采纳，而无须改变其他实践。想象一下，几年前，你已经引入了内核，并描述你的实践。然后，你将能够轻松引入Scrum，通过用Scrum取代项目管理中现有的实践，而无须对其他实践进行任何重大修改。展望未来，Scrum将很有可能被新的实践代替，你将能够很容易地做到这一点了。
如果我们的技术学院或大学教授学生软件工程基础知识，然后训练学生在一系列良好的实践中使用该基础，那将是非常棒的。教育将会更合乎逻辑，因为它着重以独特的想法，而不是特定的思想，来形成每个方法、过程或方法论。我相信学生们会喜欢的。这里也为相关研究留下了很多空间。记住Kurt Lewin的话：没有什么比一个好的理论更实用了。一个好的理论使得学习和开发你的知识更容易，而不会带来过分的崇拜。这将是聪明的。大多数大学教授们在学术生涯中，从来没有真正的机会来实践大规模的软件开发。但是他们仍然不得不教授软件工程，这当然是不容易或者只是依葫芦画瓢。他们只能这样做，因为这门课在课程表上，而不是因为他们确实有什么可教的。他们没有传授理论，只是一套想法或一个特定的方法。当被问及此事时，一名成功的计算机科学家、教授软件工程课程的教授说：令人惊讶的是，学生们喜欢沐浴在我们交给他们的烂泥塘里。我知道这么说并不严肃，但是可以肯定这位老师并不为他做的事情而感到自豪。
一个理论，将从根本上改变这种局面。学生将学习软件的基础知识。他们将得到一种语言，来沟通软件过程、实践、模式，等等。可以想象，他们将会得到一种以内核为语法的语言和描述过程构成成分的时间的语言结构。这样的语言需要是可执行的，这样实践才会变得生动。我说这些是为了表明这些实践不仅是规范，而且也可执行。当一个项目进行时，这些实践将开始运行，而且活动实例、工作产物，实例、技能角色将被真实物创造和填充。这些方面似乎能与实践模式很好地吻合，有非常有趣的语义规则需要确定和定义。向学生打开了一个全新的世界，可以帮助他们了解软件工程的基本原理。更不用说，为对实践和理论感兴趣的研究人员打开了一个全新的世界。
回顾自己1987年后的职业生涯，许多人建议我写一本有关方法论的书。当时Objectory有一些新的想法，比如说用例、用例驱动的开发(这是一个测试驱动设计、合作、序列图、组件和基于组件的开发)。其余的大部分内容都没什么特别的。实施、单元测试、系统测试、性能测试、配置、规划都是相当传统的。当然，我有整个生命周期的经验，但我不是所有事情的世界级专家。然而，为了写书，我不得不包含整个生命周期的内容，即使其中很多不是我的专长。随着我们寻找的新理论，没有任何必要再说明不包含创新的内容。你不需要写一本书来发布新想法，然后把软件开发团队需要做的一切都放进去，而只需要描述你的新实践或新模式，也许第二天你就能向全世界发布了。全世界的任何好点子都可以贡献出来并获得成功。
终于，软件团队将能够摆脱亦步亦趋地追随潮流所造成的无休止的摇摆，成为严格意义上的软件工程团队。团队在坚实的基础上通过优秀的软件开发实践建设和扩展知识。这个基础不会频繁变化，不会强迫你一遍又一遍学习同样的事情。它可以让你通过自己的总结，而不是出席的课程来展示专业。它可以让你轻松和无缝地引进新思路和新队友，而不会造成性能骤降或精力浪费。团队最终能够不断改进和适应他们的工作方式，迎接他们每天面对的挑战。他们将能够开发自己的知识和技能，以一种能够让他们顺利地和来自不同背景、团队和组织的其他人合作的方式，而不必一遍又一遍地重复学习同样的事情了。
最后的话我们对软件工程的了解缺乏一个基本理论。因此，我们不断用略有不同的词再造旧方法，掩盖了真正的创新，同时让抛弃旧的不好的部分，利用新的好的部分变得困难。该理论将帮助我们大大改进软件工程教育。这将帮助我们在面对身边涌现的新想法时的反应不那么天真。最后，它也将帮助我们更快地接受新的思想。这一理论的真正受益者将是软件行业，这一点已经在许多公司得到证明。我们将能够方便地教育我们的人员，让他们加快速度;改进我们生产产品的方式;系统地重新设计(比重构程度更强)我们的产品;不断改进我们的工作方式。其结果将是更好的软件、更快的速度和大幅降低的成本。正如上面提到的，我们需要齐心协力才能做到这一点。从Scott Ambler最近的一篇文章理论需要战略中可以看到这种势头已经开始，但仍有许多工作要做。
我们已经证明它的有效性，但我们仍然要做许多工作才能建立一个公认的标准，必须在一组专家和权威之间建立共识才能完成这点。我们期待着与这些专家的合作。

H. 软件工程三要素是什么

三要素是方法、工具、过程。

方法是完成软件开发的各项任务的技术方法，为软件开发提供“如何做”的技术。工具为运用方法而提供的自动的或半自动的软件工程的支撑环境。

过程是为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤，如何将软件工程方法与软件工具相结合，合理、及时地进行软件开发。

(8)软件工程理论的来源扩展阅读：

软件工程的目标：

1、可修改性：允许对系统进行修改而不增加原系统的复杂性。它支持软件的调试和维护，是一个难以达到的目标。

2、可靠性：能防止因概念、设计和结构等方面的不完善造成的软件系统失效，具有挽回因操作不当造成软件系统失效的能力。

3、可理解性：系统具有清晰的结构，能直接反映问题的需求。可理解性有助于控制系统软件复杂性，并支持软件的维护、移植或重用。

4、可维护性：软件交付使用后，能够对它进行修改，以改正潜伏的错误，改进性能和其它属性，使软件产品适应环境的变化等。软件维护费用在软件开发费用中占有很大的比重。可维护性是软件工程中一项十分重要的目标。

5、可重用性：把概念或功能相对独立的一个或一组相关模块定义为一个软部件。可组装在系统的任何位置，降低工作量。

6、可移植性：软件从一个计算机系统或环境搬到另一个计算机系统或环境的难易程度。

7、可追踪性：根据软件需求对软件设计、程序进行正向追踪，或根据软件设计、程序对软件需求的逆向追踪的能力。

I. 软件工程产生的背景

软件工程诞生背景：
几十年前，软件行业很不规范，小程序虽然个人能很好完成，但缺乏良好的代码管理；大程序设计人员多，工程复杂，由于缺乏相关理论知识和经验，导致很多失败的大项目产生，为了解决这种情况诞生了软件工程。建议你去读《人月神话》，能管窥一二。

软件工程专业诞生背景：
当年中国这片神奇的大地上缺少计算机方面刚毕业就能很好与企业接轨的人，因为高校供给企业的生源往往只知道理论知识，却不能又快又好地上手工作，企业又往往不愿意花费太多精力去培养这样的人，所以为了解决这种蛋疼的状况，中国的软件工程专业诞生了，更重视计算机实践方面的教学！

J. 软件工程的基本原理有哪些

软件工程的七条基本原理
1、用分阶段的生命周期计划严格管理有人经统计发现，在不成功的软件项目中有一半左右是由于计划不周造成的，可见把建立完善的计划作为第一条基本原理是吸取了前人的教训而提出来的。
在软件开发与维护的漫长的生命周期中，需要完成许多性质各异的工作。这条基本原理意味着，应该把软件生命周期划分成若干个阶段，并相应地制定出切实可行的计划，然后严格按照计划对软件的开发与维护工作进行管理。Boehm 认为，在软件的整个生命周期中应该制定并严格执行六类计划，它们是项目概要计划，里程碑计划，项目控制计划，产品控制计划，验证计划，运行维护计划。

不同层次的管理人员都必须严格按照计划各尽其职地管理软件开发与维护工作，绝不能受客户或上级人员的影响而擅自背离预定计划。

2、坚持进行阶段评审

当时已经认识到，软件的质量保证工作不能等到编码阶段结束之后再进行。这样说至少有两个理由：第一，大部分错误是在编码之前造成的，例如，根据Boehm 等人的统计，设计错误占软件错误的63%，编码仅占37%；第二，错误发现与改正得越晚，所需付出的代价也越高。因此，在每个阶段都进行严格的评审，以便尽早发现在软件开发过程中所犯的错误，是一条必须遵循的重要原则。

3、实行严格的产品控制
在软件开发过程中不应随意改变需求，因为改变一项需求往往需要付出较高的代价，但是，
在软件开发过程中改变需求又是难免的，由于外部环境的变化，相应地改变用户需求是一种客观需要，显然不能硬性禁止客户提出改变需求的要求，而只能依靠科学的产品控制技术来顺应这种要求。也就是说，当改变需求时，为了保持软件各个配置成分的一致性，
必须实行严格的产品控制，其中主要是实行基准配置管理。所谓基准配置又称基线配置，它们是经过阶段评审后的软件配置成分（各个阶段产生的文档或程序代码）。基准配置管理也称为变
动控制：
一切有关修改软件的建议，
特别是涉及到对基准配置的修改建议，必须按照严格的规程进行评审，获得批准以后才能实施修改。绝对不能谁想修改软件（包括尚在开发过程中的软件），就随意进行修改。

4、采用现代程序设计技术
从提出软件工程的概念开始，人们一直把主要精力用于研究各种新的程序设计技术。
60年代末提出的结构程序设计技术，已经成为绝大多数人公认的先进的程序设计技术。以后又进一步发展出各种结构分析（SA）与结构设计（SD）技术。实践表明，采用先进的技术既可
提高软件开发的效率，又可提高软件维护的效率。

5、结果应能清楚地审查

软件产品不同于一般的物理产品，它是看不峥摸不着的逻辑产品。软件开发人员
（或开发小组）
的工作进展情况可见性差，难以准确度量，从而使得软件产品的开发过程比一般产品的
开发过程更难于评价和管理。为了提高软件开发过程的可见性，更好地进行管理，应该根据
软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准，从而使得所得到的结
果能够清楚地审查。

6、开发小组的人员应该少而精
这条基本原理的含义是，软件开发小组的组成人员的素质应该好，而人数则不宜过多。
开发小组人员的素质和数量是影响软件产品质量和开发效率的重要因素。
素质高的人员的开发效率比素质低的人员的开发效率可能高几倍至几十倍，而且素质高的人员所开发的软件中的错误明显少于素质低的人员所开发的软件中的错误。此外，随着开发小组人员数目的增加，因为交流情况讨论问题而造成的通信开销也急剧增加。当开发小组人员数为N时，可能的通信路径有N（N?/FONT>1）/2条，可见随着人数N的增大，通信开销将急剧增加。因此，
组成少而精的开发小组是软件工程的一条基本原理。

7、承认不断改进软件工程实践的必要性遵循上述六条基本原理，就能够按照当代软件工程基本原理实现软件的工程化生产，但是，仅有上述六条原理并不能保证软件开发与维护的过程能赶上时代前进的步伐，能跟上技术的不断进步。
l
因此，Boehm提出应把承认不断改进软件工程实践的必要性作为软件工程的第七条基本原理。按照这条原理，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验，例如，收集进度和资源耗费数据，收集出错类型和问题报告数据等等。这些数据不仅可以用来评价新的软件技术的效果，而且可以用来指明必须着重开发的软件工具和应该优先研究的技术