软件工程概述
一、软件工程概述
软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。
最主要的目的是为了解决软件危机。
二、软件危机
表现：
1．软件开发成本、进度的估计很不准确
软件开发机构制定的项目计划跟实际情况有很大差距，使得开发经费一再突破。由于对工
作量和开发难度估计不足，进度计划无法按时完成，开发时间一再拖延，这种现象严重降低了软件开发机构的信誉。
2．软件产品常常与用户的要求不一致
在开发过程中，软件开发人员和用户之间缺乏信息交流。开发人员常常是在对用户要求只
有模糊了解的情况下就仓促上阵，匆忙着手编写程序。由于这些问题的存在，导致开发出来的软件不能满足用户的实际应用需要。
3．软件产品质量可靠性差
软件开发过程中，没有建立起确实有效的质量保证体系。一些软件项目为了赶进度或降低
软件开发成本，甚至不惜降低软件质量标准、偷工减料。
4．软件文档不完整、不一致
计算机软件不仅仅是程序，在软件开发过程中还应该产生出一系列的文档资料。实际上，
软件开发非常依赖这些文档资料。在软件开发过程中，软件开发机构的管理人员需要使用这些文档资料来管理软件项目；技术人员则需要利用文档资料进行信息交流；用户也需要通过这些文档资料来认识软件，对软件进行验收，熟悉软件的安装、操作等。但是，由于软件项目管理工作的欠缺，软件文档往往不完整，对软件的描述经常不一致，很难通过文档去跟踪软件开发过程中软件产品规格的变更。
5．软件产品可维护性差
软件中的错误非常难改正，软件很难适应新的硬件环境，很难根据用户的需要在原有软件
中增加一些新的功能。这样的软件是不便于重用的，以前开发的软件，一旦过时就不得不完全丢弃。
6．软件生产率低
软件生产率跟不上硬件的发展速度，不能适应计算机应用的迅速普及，以致现代计算机硬
件提供的巨大潜力不能被充分利用。
三、危机产生的原因
看点历史：
观察软件的发展，可以发现软件生产有三个发展时代，即程序设计时代、程序系统时代和
软件工程时代。
1．程序设计时代（20 世纪50 年代）
这个时期的程序大多是自用，程序的编写者往往也就是使用者，软件还没有形成为产品。
由于早期程序大多是为某个具体应用而专门编写的，程序任务单一，因此，对程序的设计也就仅仅体现在单个程序的算法上。早期程序还往往只能在某台专门的计算机上工作，很难将程序由一台设备移植到另一台设备。
2．程序系统时代（20 世纪60 年代）
这个时期的软件开发更多地依赖于个人创作。由于软件开发的主要内容仍然是程序编写，
软件开发的核心问题仍是技术问题；于是，用户的意图被忽视了，除了程序之外的其他文档、
技术标准、软件在今后运行过程中的维护等问题，也往往被忽视了。
软件已经开始成为产品，但软件的生产方式则是跟产品并不适宜的作坊创作方式。于是，
随着软件规模的不断扩大，软件危机现象在这个时期最终爆发出来。
3．软件工程时代（20 世纪70 年代起）
1968 年在联邦德国召开的计算机国际会议上，专门针对软件危机问题进行了讨论，在这次
会议上正式提出并使用了“软件工程”术语。于是，软件工程作为一门新兴的工程学科诞生了。
在软件开发上，自20 世纪70 年代以来的30 年里，结构化的工程方法获得了广泛应用，
并已成为了一种成熟的软件工程方法学；而自20 世纪90 年代起，基于面向对象的工程方法，也已被应用于软件开发之中。应该说，采用工程的原理、技术和方法实施软件产品开发，以适应软件产业化发展的需要，成为了这个时期诸多软件企业的追求目标。
真正的原因：
1．软件的不可见特性
软件不同于硬件，它是计算机系统中的逻辑部件，缺乏“可见性”。硬件错误往往可以通
过它的物理现象直接反映出来，例如，出现不正常的发热、噪音现象等；但软件错误没有这些直观表现，例如，软件中存在的程序行错误，就必须等到这行程序执行时才有可能被发现。因此，软件错误比起硬件错误来更难发现。软件的不可见特性也使得对软件项目的量化管理更难实施，对软件质量的量化评价更难操作。
2．软件系统规模庞大
软件成为产品以后已不同于早期程序，随着它的功能的增多，其规模、复杂程度越来越大。
例如，1968 年美国航空公司订票系统达到30 万条指令；IBM360OS 第16 版达到100 万条指令；1973 年美国阿波罗计划达到1 000 万条指令。这些庞大规模的软件系统，其复杂程度已超过了人所能接受的程度；但是，面对不断复杂的软件系统，其开发手段却仍然需要依靠开发人员的个人创造与手工操作。
3．软件生产工程化管理程度低
软件生产的工程化管理是软件作为产品所必须的，这意味着软件也需要像硬件一样，在软
件分析、设计完成之后，才能考虑软件的实现。应该说，工程化管理能够降低解决问题的代价。但是，许多软件的开发则往往是在分析、设计没有完成的情况下，就已经进入编码实现阶段。由于前期准备工作不充分，致使软件项目管理纷乱，严重影响软件项目成本、开发进度。
4．对用户需求关心程度不够
软件开发机构不熟悉用户业务领域。软件技术人员所关注的仅仅是计算机技术，它们不太
愿意和用户沟通，轻视对用户的需求调查，也缺乏有效的用户调查策略、手段。由于这些问题的存在，使得用户的需求意愿不能充分反映，或被错误理解。
实际上，软件是为用户开发的，只有用户才能真正了解他们自己的需要。由于没有对用户
做大量深入细致的调查研究，以致软件需求规格定义不准确，并最终使得完成后的软件不能适应用户的应用需要。
5．对软件维护重视程度不够
软件开发缺乏统一的规范。在软件产品开发过程中，开发者很少考虑到这个软件今后还需
要提供维护。但是，软件的使用周期漫长，软件错误具有隐蔽性，许多年之后软件仍可能需要改错。另外，软件的工作环境也可能会在几年后发生改变；用户也可能在软件运行几年以后，要求对它增加新的功能。这些都是属于软件维护问题。实际上，软件的可维护性是衡量软件质量的一项重要指标，软件可维护性程度高，软件就便于修正、改版和升级，由此可以使软件具有更长的使用寿命。
6．软件开发工具自动化程度低
尽管软件开发工具比30 年前已经有了很大的进步，但直到今天，软件开发仍然离不开工
程人员的个人创造与手工操作，软件生产仍不可能像硬件设备的生产那样，达到高度的自
动化。
四、探讨如何解决危机
- 软件工程的主要环节有：人员管理、项目管理、可行性与需求分析、系统设计、程序设计、测试、维护
- 常见的软件工程模型有：线性模型（瀑布模型），渐增式模型，螺旋模型，快速原型模型，增量模型，喷泉模型等
最早出现的软件工程模型是线性模型（又称瀑布模型）。
瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用瀑布模型用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
优点
1）为项目提供了按阶段划分的检查点。
2）当前一阶段完成后，您只需要去关注后续阶段。
缺点
1）在项目各个阶段之间极少有反馈。
2）只有在项目生命周期的后期才能看到结果。
3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4)瀑布模型的突出缺点是不适应用户需求的变化.
线性模型太理想化，太单纯，已不再适合现代的软件开发模式，几乎被业界抛弃。但是复杂的“非线性”问题时，总是千方百计地将其分解或转化为一系列简单的线性问题。
螺旋模型：
基本做法是在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。
优点
1）设计上的灵活性,可以在项目的各个阶段进行变更。
2）以小的分段来构建大型系统,使成本计算变得简单容易。
3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。
4）随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。
5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。
缺点
很难让用户确信这种演化方法的结果是可以控制的。建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。
螺旋模型的项目适用：
对于新近开发，需求不明确的情况下，适合用螺旋模型进行开发，便于风险控制和需求变更！
快速原型模型
