软件工程概述
软件工程概述
软件工程的介绍
软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过实践考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它。
软件工程的定义
把系统的、规范的、可度量的途径应用于软件开发、运行、和维护过程，也就是把工程应用于软件。
软件工程的本质特性
软件工程关注大型程序的构造 ；通常把一个人在较短的时间内写出的程序称为小型程序，而把多人合作用时半年以上才写出的程序称为大型程序。
软件工程的中心课题是控制复杂性 ；人们不得不把问题分解，使得分解出的每个部分是可理解的，而且各个部分之间保持简单的通信关系。
软件经常变化 ；软件系统交付使用后仍然需要耗费成本，而且在开发过程中必须考虑软件将来可能法硕的变化。
开发软件效率非常重要 ；软件工程的一个重要课题就是，寻求开发与维护软件的更好更有效的方法和工具。
和谐地合作是开发软件的关键 ；软件处理的问题十分庞大，必须多人协同工作才能解决这类问题。
软件必须有效地支持它的用户 ；软件开发的目的就是支持用户工作。
在软件工程领域中通常由具有一种文化背景的人替具有另一种文化背景的人创造产品 ；软件工程师是诸如Java程序设计、软件体系结构、测试或统一建模语言等方面的专家，他们通常不是图书馆管理、航空控制等领域的专家，但是他们却不得不为这些领域开发应用系统。
软件工程的基本原理
用分阶段的生命周期计划严格管理 ；在软件开发与维护的漫长生命周期中，需要完成许多性质各异的工作。这条基本原理意味着，应该把软件生命周期划分为若干个阶段，并相应地制定出可行的计划，然后严格按照计划对软件的开发与维护工作进行管理。
坚持进行阶段评审 ；在每个阶段都进行严格的评审，以便尽早发现在软件开发过程中所犯的错误。
实行严格的产品控制 ；当需求发生改变时，为了保持软件各个配置成分的一致性，必须实行严格的产品控制，其中主要是实行基准配置管理。所谓的基准配置又称基线配置，它们是经过阶段评审后的软件配置成分（各个阶段产生的文档或程序代码）。基准配置管理也成为变动控制：一切有关修改软件的建议，特别是涉及对基准配置的修改建议，都必须按照严格的规程进行评审，获得了批准后才能实现修改。
实现现代程序设计技术 ；提高软件开发和维护的效率，而且可以提高软件产品的质量。
结果应能清楚地审查 ；软件产品不同于一般地，它是看不见摸不着的逻辑产品。为了提高软件开发的可见性，更高地进行管理，应该根据软件开发项目的总目标及完成期望，规定开发组织的责任和产品标准，从而使得所得到的结果能够清楚地审查。
开发小组的人员少而精 ；
承认不断改进软件工程实践的必要性 ；
软件生命周期
1.问题定义
问题定义阶段必须回答的关键问题是：“要解决的问题是什么？”通过对客户的访问调查，系统分析员扼要地写出关于问题性质、工程目标和工程规模的书面报告，经过讨论和必要的修改之后这份报告应该得到客户的确认。
2.可行性研究
这一阶段要回答的关键问题是：“对于上一阶段所确定的问题有行得通的解决办法吗？”为回答这一问题，系统分析员需要进行一次大大压缩和简化了的系统分析和设计过程，也就是在较抽象的高层次上进行的分析和设计过程。可行性分析的结果是客户作出是否继续进行这项工程的决定的重要依据。
3.需求分析
这个阶段的任务仍然不是具体的解决问题，而是准确地确定“为了解决这个问题，目标系统必须做什么”，主要是确定目标系统必须具备哪些功能。
用户了解他们所面对的问题，知道必须做什么，但是通常不能完整准确地表达出他们的要求，但是对特定用户的具体要求并不完全清楚。因此，系统分析员在需求分析阶段必须和用户密切配合，充分交流信息，以得出经过用户确认的系统逻辑模型。 这个阶段的一项重要任务，是用正式文档准确地记录目标系统的需求，这份文档通常称为规格说明书 。
4.总体设计
这一阶段要回答的关键问题是：“应该怎样实现目标系统？”总体设计又称概要设计。
首先，应该设计出实现目标系统的几种可能的反感。通常至少应该设计出低成本、中成本、高成本3种方案。软件工程师应该用适当的表达工具描述每种方案，分析每种方案的优缺点，并在充分权衡各种方案的利弊的基础上，推荐一个最佳方案。此外，还应该制定出实现最佳方案的详细计划。如果客户接受所推荐的方案，则应该进一步完成上述的另一项主要工作。
5.详细设计
详细设计阶段的任务就是把解法具体化，也就是回答下面这个关键问题“应该怎样具体地实现这个系统呢？”这个阶段的任务还不是编写程序，而是设计出程序的详细规格说明。这种规格说明的作用很类似于其他工程领域中工程师经常使用的工程蓝图，它们应该包含必要的细节，程序员可以根据它们写出实际的程序代码。详细设计也称模块设计。
6.编码和单元测试
这个阶段的关键任务就是写出正确的容易理解、容易维护的程序模块。
7.综合测试
这个阶段的关键任务是通过各种类型的测试使软件达到预定要求。
最基本的测试是集成测试和验收测试。所谓集成测试是根据设计的软件结构，把经过单元测试检验的模块按某种预定的策略装配起来，在装配过程中对程序进行必要的测试。所谓验收测试，则是按照规格说明书的规定（通常在需求分析阶段），由客户对目标程序进行验收。
8.软件维护
维护阶段的关键任务是，通过各种必要的维护活动使系统持久地满足用户的需要。
有4类维护活动：
1.改正性维护，诊断和改正使用过程中发现的软件错误。
2.适应性维护，即修改软件以适应环境的变化；
3.完善性维护，即根据用户的要求改进或补充软件使它更完善；
4.预防性维护，即修改软件，为将来的维护活动预先做准备。
软件过程
软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
1.瀑布模型
1.1传统的瀑布模型
传统的瀑布模型开发有以下几个特点。
阶段间具有顺序性和依赖性 ；必须等前一阶段的工作完成之后，才能开始后一阶段的工作；前一阶段的输出文档就是后一阶段的输入文档。因此只有前一阶段的输出文档正确，后一阶段的工作才能得到正确的结果。
推迟实现的观点 。实践表明，对于大规模的软件项目，往往编码开始得越早，最终完成开发所需要的时间反而越长，这是因为，前面阶段的工作没做成或做得不扎实，过早地考虑进行程序实现，往往导致大量返工，有时甚至发生无法弥补的问题。
质量保证的观点 ；软件工程的基本目标是优质、高产，为了保证所开发的软件的质量，在瀑布模型的每个阶段都应坚持两个重要做法。
1.每个阶段都必须完成规定的文档，没有交出合共的文档就是没有完成该阶段的任务。
2.每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。
实际的瀑布模型
传统的瀑布模型太过于理想化了，事实上，人在工作过程中不可能不犯错误。在设计阶段可能发现规格说明文档中的错误，而设计上的缺陷或错误可能在实现过程中显现出来。在综合测试阶段将发现需求分析、设计或编码阶段的许多错误。因此，实际的瀑布模型是带“反馈环”的。当在后面的阶段发现前面的阶段的错误时，需要沿途中左侧的反馈线返回前面的那个阶段，修正前面阶段的产品之后再回来继续完成后面阶段的任务。
瀑布阶段的优点：强迫开发人员采用规格方法；严格地规定了每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
“瀑布模型是由文档驱动的”这个事实也是它的一个主要缺点。在可运行的软件产品交付给用户之前，用户只能通过文档来了解产品是什么样的。而且事实证明，一旦一个用户开始使用一个软件，在他的头脑中关于该软件应该做什么的想法就或多或少地发生变化，这就使得最初提出的需求变得不完全适用了。
2.快速原型模型
所谓快速原型模型是快速建立起在计算机上可以运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。
快速原型模型的第一步是快速建立一个能反映用户主要需求的原型模型，让用户在计算机上试运行它，通过实践来了解目标系统的概貌。一般，用户试用完后，会提出大量修改意见，开发人员按照用户的意见快速地修改原型系统，然后再次请用户试用。一旦用户觉得这个原型系统能满足他们的需要，开发人员便根据此书写规格说明文档，根据这文档开发出的软件便可满足用户的真实需求。
快速原型模型是不带“反馈环”的，软件产品的开发基本上是线性顺序进行的。能基本上做到线性顺序开发的主要原因如下：
1.原型系统通过与客户交互而得到验证，据此产生的规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工。
2.开发人员通过建立原型系统已经学到了许多东西，因此在设计和编码阶段发生的错误的可能性比较小。
3.增量模型
增量模型也成渐增模型
使用增量模型开发软件时，把软件产品作为一系列的增量构建来设计、编码、集成和测试。每个构件由多个项目作用的模块构成，并且能够完成特定的功能。使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。把软件产品分解为增量构件时，应该使构建的规模适中，规模过大或过小都不好。最佳分解方法因软件产品特点和开发人员的习惯而异。分解时唯一必须遵守的约束条件是，当把新构件集成到现有软件中时，所形成的产品必须是可测试的。
采用瀑布模型或快速圆心模型开发软件时，目标都是一次就把一个满足所有需求的产品提交给用户。增量模型则与之相反，它分批地逐步向用户提交产品，整个软件产品被分解成多个增量构件，开发人员一个构件接着一个构件地向用户提交产品。显然，能在较短时间内向用户提交可完成部分工作的产品，是增量模型的一个优点。
增量模型的另一个优点是，逐步增加产品功能可以使用户有充裕的时间区学习和适用系产品，从而减少一个全新的软件可能给客户带来的冲击。
使用增量模型的困难是，在把每个新的增量构件集成到现有的软件体系结构中，必须不破坏原来已经开发出的产品。此外，还必须把软件体系结构设计得便于按照这种方式进行扩充，也就是说，软件体系结构必须是开放的。因此，采用增量模型比采用瀑布模型和快速原型模型要更精心的设计，但在设计阶段多付出的劳动将在维护阶段获得回报。
从某种意义上，增量模型本身是自相矛盾的。它一方面要求开发人员把软件看作一个整体，另一方面又要求开发人员把软件看成构建序列，每个构件本质上都独立于另一个构件。
4.螺旋模型
软件开发几乎总要冒一些风险。软件风险是任何软件开发项目中都普遍存在的实际问题，项目越大，软件越复杂，承担该项目所冒的风险也越大。软件风险可能在不同程度上损害软件开发过程和软件产品质量。因此，在软件开发过程中必须及时识别和分析风险，并且采取适当措施以消除或减少风险的危害。
构建快速原型是一种能使某些类型的风险降至最低的方法。对于某些类型的方法，快速原型模型也无能为力。
螺旋模型的基本思想是，使用原型及其他方法来尽量降低风险，理解这种模型的一个简便方法，是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型，如图所示。
完整的螺旋模型如下图所示。
螺旋模型有许多优点：对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；减少了过多测试或测试不足所带来的风险；更重要的是， 在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别。
螺旋模型主要适用于内部开发的大规模软件项目。如果进行风险分析的费用接近整个项目的经费预算，则风险分析是不可行的。事实上，项目越大，风险越大。因此，进行风险分析的必要性也越大。此外，只有内部开发的项目，才能在风险过大时方便地中止项目。
5.喷泉模型
迭代是软件开发过程中普遍存在的一种内在属性。经验表明，软件过程各个阶段之间的迭代或一个阶段内各个工作步骤之间的迭代，在面对对象范型比在结构化范型更常见。喷泉模型如下图所示。
喷泉模型体现了面向对象软件开发过程迭代和无缝的特性。