软件工程总体介绍

软件工程总体介绍意外效应法则与计算机软件

某些新科技的发明创造会给其他一些看似无关的技术领域、给商务企业、给公众甚至整个社会文化带来深远而出人意料的影响和作用。这就是所谓的“意外效应法则（thelawofunintendedconsequences）”。计算机软件已经成为世界舞台上最为重要的科技领域，并且是“意外效应法则”的一个最好的体现。

软件的角色现在的软件具有产品和产品生产载体的双重作用。作为一个产品，它显示了由计算机硬件体现的计算能力。无论是在手机还是在大型计算机中，软件都扮演着信息转换的角色：产生、管理、查询、修改、显示或者传递各种不同的信息。 作为产品生产的载体，软件提供了计算机控制（操作系统）、信息通信（网络）、以及应用程序开发和控制（软件工具和环境）的基础平台。软件的特性软件是设计开发的，而不是传统意义上的生产制造。软件产品成本主要在于开发设计，不能像管理制造项目那样管理软件开发项目。软件不会“磨损”。磨损的硬件部件可以用备用的器件替换。而软件却不存在备用器件。每个软件的错误都暗示了设计的缺陷或者在从设计转化到机器可执行代码的过程中产生的错误。因此，软件维护比硬件维护更为复杂。虽然整个工业向着基于组件组装的构造模式发展，然而大多数软件仍是根据实际的顾客需求定制的。在硬件设计中，器件复用是工程进程中通用的方法。而在软件设计中，大规模的复用还刚刚开始尝试。软件的分类系统软件应用软件工程／科学软件嵌入式软件产品线软件Web应用软件人工智能软件

未来工程师将面临的挑战：普适计算:无线网络的快速发展也许将很快促成真正的分布式计算的实现。软件工程师所面临的挑战将是开发系统和应用软件，以使得小型设备、个人电脑和企业应用可以通过大量的网络设施进行通信。网络资源：万维网已经快速发展为一个计算引擎和内容提供平台。软件工程师新的任务是构建一个简单而智能的应用程序，为全世界的最终用户市场提供服务。开源软件：软件工程师面对的挑战是，开发可以自我描述的代码，而更重要的是，开发某种技术，以便于用户和开发人员都能够了解已经发生的改动，并且知道这些改动如何在软件中体现出来。“新经济”：90年代后期困扰金融市场的网络经济衰退以及21世纪初随之而来的讨论使得许多商业人士相信，新经济已经衰亡。现在，新经济体系依然健康地生存着，只是发展缓慢。它将朝着多点通信和分布式的方向发展。软件工程师面临的挑战是利用最新形成的理念，开发出便于大众传媒，产品发布的应用程序。

软件危机

软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这些问题绝不仅仅是不能正常运行的软件才具有的，实际上，几乎所有软件都不同程度地存在这些问题。

概括地说，软件危机包含下述两个方面的问题：如何开发软件，以满足对软件日益增长的需求；如何维护数量不断膨胀的已有软件。具体来说，软件危机主要有以下一些典型表现:对软件开发成本和进度的估计常常很不准确。用户对“已完成的”软件系统不满意的现象经常发生。软件产品的质量往往靠不住。软件常常是不可维护的。软件通常没有适当的文档资料。软件成本在计算机系统总成本中所占的比例逐年上升。软件开发生产率提高的速度，既跟不上硬件的发展速度，也远远跟不上计算机应用迅速普及深入的趋势。以上列举的仅仅是软件危机的一些明显的表现，与软件开发和维护有关的问题远远不止这些。如何摆脱软件危机?按工程化的原则和方法组织软件开发工作。软件生存期lifecycle软件有一个孕育、诞生、成长、成熟、衰亡的生存过程。这个过程即为计算机软件的生存期软件生存期的六个步骤，即制定计划、需求分析、设计、程序编码、测试及运行维护软件工程的定义Boehm：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料IEEE：软件工程是开发、运行、维护和修复软件的系统方法FritzBauer：建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法软件工程三要素：

方法、工具和过程软件工程方法为软件开发提供了“如何做”的技术软件工具为软件工程方法提供了自动的或半自动的软件支撑环境软件工程过程定义了:

方法使用的顺序要求交付的文档资料为保证质量和适应变化所需要的管理软件开发各个阶段完成的里程碑软件工程项目的基本目标付出较低的开发成本达到要求的软件功能取得较好的软件性能开发的软件易于移植需要较低的维护费用能按时完成开发工作，及时交付使用软件工程知识体(SoftwareEngineeringBodyofKnowledge,SWEBOK)

2001年由IEEE_CS发布的SWEBOK对软件工程学科的边界进行了定义，将软件工程划分为10个知识域（KA），并详细列出了每个知识域中的知识点，2004年IEEE_CS又发布了新版的SWEBOK的框架。

需求基础需求过程需求提取需求分析需求规范需求管理需求确认设计基础关键问题体系结构设计质量分析和评估测试基础测试级别测试技术SWEBOK指南软件需求软件设计软件构造

软件测试软件维护软件配置管理软件工程管理软件工程过程软件工程工具和方法软件质量软件设计符号软件设计策略方法测量措施测试过程维护基础维护过程关键问题维护技术SCM过程管理配置标识配置控制软件发行版本管理软件构造基础软件维护构造实践考虑配置状态报告启动域定义项目规划配置控制软件工程度量审核评估终止过程实施过程变更过程定义过程评估过程度量产品度量软件质量基础软件质量管理过程实践考虑软件工具软件方法需求工具设计工具构造工具测试工具配置工具工程管理工具过程管理工具质量管理工具其它工具启发式方法形式化方法原型法除了上述知识域之外，还列出了相关学科的知识域，主要包括：计算机工程、计算机科学、管理、数学、系统工程等。

软件神话引起软件危机的诸多原因可以追溯到软件开发的早期阶段产生的神话。软件神话具有一些特征使得它们很有欺骗性：例如，它们表面上看很有道理（有时含有一定真实的成分）；它们符合人的直觉；它们常常是有经验的实践者发布出来的。神话1：我们已经有了关于建造软件的标准和规程的书籍，难道它们不能给人们提供所有其需要知道的信息吗？事实：不错，关于标准的书籍已经存在，但真正用到了它们吗？软件实践者知道它们的存在吗？它们完整吗？很多情况下，对于这些问题的答案均是“不”。神话2：如果我们已经落后于计划，可以增加更多的程序员来赶上进度。事实：软件开发并非象制造一样是一个机械过程。用Brooks的话来说：“给一个已经延迟的软件项目增加人手只会使其更加延迟”。看起来，这句话与人的直觉正好相反。但实际上，增加新人