1. 软件与软件危机
1.1. 软件的概念和特点
软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合。
其中，程序是按事先设计的功能和性能要求执行的指令序列；数据是使程序能正常操纵信息的数据结构；文档是与程序开发，维护和使用有关的图文材料。
与之相似的是，在1983年IEEE组织对软件下的定义是：计算机程序、方法、规则、相关的文档资料以及在计算机上运行程序时所必需的数据。
比软件定义更重要的是，必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。
软件有以下七个特点：
软件是一种逻辑实体，而不是具体的物理实体，因而它具有抽象性；
软件的生产与硬件不同，它没有明显的制造过程；
在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题。但就目前的软件工程环境应用而言，在不更新升级的情况下软件的平均寿命大约为5年，如果一个软件5年内没有任何更新，那么它将面临淘汰；
软件的开发和运行常常受到计算机系统的限制，对计算机系统有着不同程度的依赖性；
软件的开发至今尚未完全摆脱手工艺的开发方式；
软件本身是复杂的，这种复杂性可能来自它所反映的实际问题的复杂性，例如相当多的软件工作涉及到社会因素，复杂性也可能来自程序逻辑结构的复杂性；
软件成本相当昂贵
1.2. 软件规模的分类与发展阶段
软件的分类并没有一个绝对的标准，但一般情况下都会用软件规模来对软件进行分类，如下表：
软件发展的四个时期及其特点
程序设计的原始时期(1950~1950年代末)，这时既没有汇编语言也没有高级语言，程序员只能用机器指令编写程序；
基本软件期(1950年代末~1960年代末)，出现了汇编语言，并逐渐普及。随着高级语言的发展，编译技术也有较大的发展；
程序设计方法时代(1960 年代末~1970年代中期) 。 这一时期，与硬件费用下降相反，软件开发费急剧上升。于是人们提出了结构式程序设计和模块化程序设计等程序设计方法，设法降低软件的开发费用；
软件工程时期(1970年代中期~现在)。软件开发技术不再仅仅是程序设计技术，而是包括了与软件开发的各个阶段，如需求分析、设计、编码、单元测试、综合测试、使用和维护及其整体有关的各种管理技术。
1.3.1. 软件危机的表现
软件危机一般表现在以下五个大方面：
对软件开发成本和进度的估算很不准确。 实际成本比估计成本有可能高出一个数量级，实际进度比预期进度拖延几个月甚至几年的现象并不罕见。软件开发人员常常在对用户要求只有模糊的了解，甚至对所要解决的问题还没有确切认识的情况下，就匆忙着手编写程序；另外软件成本在计算机系统总成本中所占的比例逐年上升。由于微电子学技术的进步和生产自动化程度不断提高，硬件成本逐年下降，然而软件开发需要大量人力，软件成本随着通货膨胀以及软件规模和数量的不断扩大而持续土升。美国在1985年软件成本大约已占计算机系统总成本的90%。
软件产品不符合用户的实际需要。 通常情况下用户也不知道自己想要什么，导致开发时常常出现产品与预期不匹配的现象，实际上当前的软件技术已经十分发达，搞明白了需求基本上都能通过技术实现，如下图是软件技术与需求之前的增长关系：
软件产品质量不可靠。 软件可靠性和质量保证的确切的定量概念刚刚出现不久，软件质量保证技术(审查、复审和测试)还没有坚持不懈地应用到软件开发的全过程中，这些都导致软件产品发生质量问题;计算机软件不仅仅是程序，还应该有三整套文档资料。这些文档资料应该是在软件开发过程中产生出来的，而且应该是"最新式的"(即和程序代码完全一致的)。软件开发组织的管理人员可以使用这些文档资料作为“里程碑”，来管理和评价软件开发工程的进展状况:软件开发人员可以利用它们作为通信工具，在软件开发过程中准确地交流信息;对于软件维护人员而言，这些文档:资料更是必不可少的。
缺少软件文档，大型软件系统经常失败。 缺乏方法指导和工具支持导致很多程序中的错误是非常难改正的，甚至一旦换了一个新的硬件环境就不能正常运行，也不能根据用户的需要在原有程序中增加一些新的功能。"可重用的软件"还是一个没有完全做到的、正在努力追求的目标，人们仍然在重复开发类似的或基本类似的软件
软件开发效率不高，与计算机应用的迅速发展不匹配。 软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。软件产品"供不应求"的现象使人类不能充分利用现代计算机硬件提供的巨大潜力。
1.3.2. 软件危机产生的原因
客观原因：软件本身特点，例如逻辑部件复杂、规模庞大等等。
在软件开发和维护的过程中存在这么多严重问题，一方面与软件本身的特点有关，另一方面也和软件开发与维护的方法不正确有关。软件不同于硬件，它是计算机系统中的逻辑部件而不是物理部件，在运行过程中不会因为使用时间过长而被"用坏"，如果运行中发现了错误很可能是遇到了一个在开发时期引入的，在测试阶段没能检测出来的错误。
软件不同于一般程序，它的一个显著特点是规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。
主观原因：程序员不正确的开发方法，忽视需求分析，并且错误地认为软件开发等于程序编写，轻视软件维护。
主观上的错误认识和作法主要表现为忽视软件需求分析的重要性，认为软件开发就是写程序并设法使之运行，轻视软件维护等。目前相当多的软件专业人员对软件开发和维护还有不少其他的糊涂观念，在实践过程中或多或少地采用了错误的方法和技术，这可能是使软件问题发展成软件危机的主要原因。
对用户要求没有完整准确的认识就匆忙着手编写程序是许多软件开发工程失败的主要原因之一。另一方面还必须认识到程序只是完整的软件产品的一个组成部分，一个软件产品必须由一个完整的配置组成，主要包括程序、文档和数据等成分，他们缺一不可。
软件问题要尽早解决
作好软件定义时期的工作，是降低软件，成本提高软件质量的关键。在实际的软件开发中，在软件开发的不同阶段进行修改需要付出的代价是很不相同的，大约如下图所示，它表示了错误发现的越晚，付出的代价越高。
因此可以说，轻视维护是一个巨大的错误。统计数据表明，实际上用于软件维护的费用占软件总费用的55%~70%。软件工程学的一个重要目标就是提高软件的可维护性，减少软件维护的代价。
软件危机案例：
IBMOS/360操作系统被认为是一个典型的案例，到现在为止，它仍然被使用在360系列主机中。这个经历了数十年，极度复杂的软件项目甚至产生了一套不包括在原始设计方案之中的工作系统。
IBM公司开发OS/360系统，共有4000多个模块，约100万条指令，投入5000人年，耗资数亿美元，结果还是延期交付，在交付使用后的系统中仍发现大量（2000个以上）的错误，造成无法估计的安全隐患。
1.3.3. 软件危机如何解决
实际上就目前的手段而言，软件工程只能解决主观上造成软件危机的原因，对于软件本身特点，例如逻辑部件复杂、规模庞大等客观原因，软件工程是无能为力的。
主观危机的解决途径主要有两条：1、组织管理。2、技术措施
在组织管理可以采用工程项目管理方法；
在技术措施上提升软件开发技术与方法，灵活运用软件工具。应该推广使用在实践中总结出来的开发软件的成功的技术和方法，并且研究探索更好更有效的技术和方法，尽快消除在计算机系统早期发展阶段形成的一些错误概念和做法。并且应该开发和使用更好的软件工具，在软件开发的每个阶段都有许多繁琐重复的工作需要做，在适当的软件工具辅助下，开发人员可以把这类工作做得既快又好。
为了消除软件危机，首先应该对计算机软件有一个正确的认识，首当其冲的就是彻底消除"软件就是程序"的错误 观念，要明确一个软件必须由一个完整的配置组成，是程序、数据及相关文档的完整集合。
2. 软件工程学
2.1. 软件工程学的概念
软件工程学是在1968年，北约计算机科学会议上由Fritz Bauer提出的，他给出的软件工程学的定义为：用工程、科学和数学的原则与方法研制、维护计算机软件的有关技术及管理方法。其中包含了三个要素：方法、工具、过程。
软件工程学的中心思想是把软件当作一种工业产品，要求采用工程化的原理与方法对软件进行计划、开发和维护。因此可以说，软件工程学是一门指导计算机软件开发和维护的工程学科，它包含了开发技术和工程管理两方面。
2.2. 软件工程项目的基本目标
软件工程的目的是为了实现按预期的进度和经费完成软件生产计划，提高软件的生产率和可靠性。
具体来说就是要达到以下几个主要的目标：
付出较低的开发成本；
达到要求的软件功能；
取得较好的软件性能；
开发的软件易于移植；
需要较低的维护费用；
能按时完成开发工作，及时交付使用。
但是软件工程的各个目标是不可能全部满足的，下图表示了软件工程目标之间的关系，可见，软件工程的最终目标只能是实现一个均衡的系统。
2.3. 软件工程的八项原则
抽象
抽取事物最基本的特性和行为，忽略非基本的细节。采用分层次抽象，自顶向下、逐层分解的办法控制软件开发过程的复杂性。例如，软件瀑布模型、结构化分析方法、结构化设计方法，以及面向对象建模技术等都体现了抽象的原则。
封装(信息隐蔽)
将模块设计成“黑箱”，实现的细节隐藏在模块内部，不让模块的使用者直接访问。这就是信息封装，使用与实现分离的原则。使用者只能通过模块接口访问模块中封装的数据。
模块化
模块是程序中逻辑上相对独立的成分，是独立的编程单位，应有良好的接口定义。如C语言程序中的函数过程，C++语言程序中的类。模块化有助于信息隐蔽和抽象，有助于表示复杂的系统。
局部化
要求在一个物理模块内集中逻辑上相互关联的计算机资源，保证模块之间具有松散的耦合，模块内部具有较强的内聚。这有助于加强模块的独立性，控制解的复杂性。
确定性
软件开发过程中所有概念的表达应是确定的、无歧义性的、规范的。这有助于人们之间在交流时不会产生误解、
遗漏，保证整个开发工作协调致。
一致性
整个软件系统(包括程序、文档和数据)的各个模块应使用一致的概念、符号和术语。程序内部接口应保持一致。软件和硬件、操作系统的接口应保持一致。系统规格说明与系统行为应保持一致。用于形式化规格说明的公理系统应保持一致。
完备性
软件系统不丢失任何重要成分，可以完全实现系统所要求功能的程度。为了保证系统的完备性，在软件开发和运行过程中需要严格的技术评审。
可验证性
开发大型的软件系统需要对系统自顶向下逐层分解。系统分解应遵循系统易于检查、测试、评审的原则，以确保系统的正确性。
2.4. 软件工程的本质特征
软件工程关注于大型程序的构造
"大"与"小"的分界线并不十分清晰。通常把一个人在较短时间内写出的程序称为小型程序，而把多人合作用时半年以上才写出的程序称为大型程序。
软件工程的中心课题是控制复杂性
软件所解决的问题十分复杂，通常不得不把问题分解，使得分解出的每个部分是可理解的，而且各部分之间保持简单的通信关系。用这种方法并不能降低问题的整体复杂性，但是却可使它变成可以管理的。
软件经常变化
绝大多数软件都模拟了现实世界的某一部分。现实世界在不断变化，软件为了不被很快淘汰，必须随着所模拟的现实世界一起变化。因此，在软件系统交付使用后仍然需要耗费成本，而且在开发过程中必须考虑软件将来可能的变化。
开发软件的效率非常重要
目前，社会对新应用系统的需求超过了人力资源所能提供的限度，软件供不应求的现象日益严重。因此，软件工程的一个重要课题就是，寻求开发与维护软件的更好更有效的方法和工具。
和谐地合作是开发软件的关键
软件处理的问题十分庞大，必须多人协同工作才能解决这类问题。为了有效地合作，必须明确地规定每个人的责任和相互通信的方法。纪律是成功地完成软件开发项目的一个关键。
软件必须有效地支持它的用户
开发软件的目的是支持用户的工作。软件提供的功能应该能有效地协助用户完成他们的工作。
有效地支持用户意味着必须仔细地研究用户，以确定适当的功能需求、可用性要求及其他质量要求(例如，可靠
性、响应时间等)。有效地支持用户还意味着，软件开发不仅应该提交软件产品，而且应该写出用户手册和培训材料。
在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人
软件工程师是诸如Java程序设计、软件体系结构、测试或统一建模语言(UML)等方面的专家，他们通常并不是图书馆管理、航空控制或银行事务等领域的专家，但是他们却不得不为这些领域开发应用系统。缺乏应用领域的相关知识，是软件开发项目出现问题的常见原因。
有时候，软件开发者通过访谈、阅读书面文件等方法了解到用户组织的“正式”工作流程，然后用软件实现这个工作流程。但是，决定软件系统成功与否的关键问题是，用户组织是否真正遵守这个工作流程
