2.5. 软件工程的七条基本原理
著名的软件工程专家B.W.Boehm综合学者们的意见，于1983年在一篇论文中提出了软件工程的七条基本原理。这七条原理是确保软件产品质量和开发效率的原理的最小集合。
这七条原理是互相独立的，其中任意6条原理的组合都不能代替另一条原理。同时这七条原理又是相当完备的，虽然不能用数学方法严格证明它们是一个完备的集合，但是可以证明在此之前已经提出的一百多条软件工程原理都可以由这七条原理的任意组合蕴含或派生。
七条基本原理：
用分阶段的生命周期计划严格管理
经统计发现，在不成功的软件项目中有一半左右是由于计划不周造成的。因此应该把软件生命周期划分成若千个阶段，并相应地制定出切实可行的计划，然后严格按照计划对软件的开发与维护工作进行管理。不同层次的管理人员都必须严格按照计划各尽其职地管理软件开发与维护工作，绝不能受客户或上级人员的影响而擅自背离预定计划；一般来说软件的生命周期分为定义阶段、可行性研究阶段、需求分析阶段、程序设计阶段、编码阶段、测试阶段、运行维护阶段。
坚持进行阶段评审
软件的质量保证工作不能等到编码阶段结束之后再进行，这样说至少有两个理由：
第一，大部分错误是在编码之前造成的，根据统计，设计错误占软件错误的63%，编码错误仅占37%；
第二，错误发现与改正得越晚，所需付出的代价也越高；
因此，在每个阶段都进行严格的评审，以便尽早发现在软件开发过程中所犯的错误，是一条必须遵循的重要原则。
实行严格的产品控制
在软件开发过程中改变需求是难免的，只能依靠科学的产品控制技术来顺应这种要求。也就是说，当改变需求时，为了保持软件各个配置成分的一致性，必须实行严格的产品控制，其中主要是实行基准配置管理。
所谓基准配置又称为基线配置，它们是经过阶段评审后的软件配置成分。基准配置管理也称为变动控制，指的是一切有关修改软件的建议，特别是涉及到对基准配置的修改建议，都必须按照严格的规程进行评审，获得批准以后才能实施修改。绝对不能谁想修改软件，就随意进行修改。
采用现代程序设计技术
从提出软件工程的概念开始，人们一直把主要精力用于研究各种新的程序设计技术，并进一步研究各种先进的软件开发与维护技术。实践表明，采用先进的技术不仅可以提高软件开发和维护的效率，而且可以提高软件产品的质量。
结果应能清楚地审查
软件产品不同于一般的物理产品，它是看不见摸不着的逻辑产品。软件开发人员的工作进展情况可见性差，难以准确度量，从而使得软件产品的开发过程比一般产品的开发过程更难于评价和管理。为了提高软件开发过程的可见性，更好地进行管理，应该根据软件开发项目的总目标及完成期限来规定开发组织的责任和产品标准，从而使得所得到的结果能够清楚地审查。
开发小组的人员应该少而精
软件开发小组的组成人员的素质应该好，而人数则不宜过多。素质高的人员的开发效率比素质低的人员的开发效率可能高几倍至几十倍，而且素质高的人员所开发的软件中的错误明显少于素质低的人员所开发的软件中的错误。
此外，随着开发小组人员数目的增加，因为交流情况讨论问题而造成的通信开销也急剧增加。当开发小组人员数为N时，可能的通信路径有N(N-1)/2条，可见随着大数N的增大，通信开销将急剧增加。
承认不断改进软件工程实践的必要性
遵循上述六条基本原理，就能够按照当代软件工程基本原理实现软件的工程化生产，但是，仅有上述6条原理并不能保证软件开发与维护的过程能赶上时代前进的步伐。因此，Boehm提出应把承认不断改进软件工程实践的必要性作为软件工程的第7条基本原理。按照这条原理，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验。
3. 软件工程方法学
3.1. 软件工程方法学的概念
软件工程包括技术和管理两方面的内容，是技术与管理紧密结合所形成的工程学科。通常把在软件生命周期全过程中使用的整套技术方法的集合称为方法学(Methodology)，也称为范型(Paradigm)。
软件工程方法学包含3个要素:
方法，是完成软件开发的各项任务的技术方法，回答"怎样做"的问题；
工具，是为运用方法而提供的自动的或半自动的软件工程支撑环境；
过程，是为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
3.2. 传统软件工程与面向对象软件工程
3.2.1. 传统软件工程与面向对象软件工程的对比
目前使用得最广泛的软件工程方法学有传统方法学（面向数据流/结构化方法学） 和 面向对象方法学。他们分别代表了两种程序设计方法：即结构化程序设计(程序=数据结构+算法) 和 面向对象程序设计(程序=对象+请求消息)
两种方法学的软件开发流程如下所示：
传统软件工程：软件分析→总体设计→详细设计→面向过程的编码→测试。会有一个清楚的流程体系。
面向对象软件工程：软件分析与对象抽取→对象详细设计→面向对象的编码→测试。
3.2.2. 传统软件工程的生命周期
所谓软件生命周期，软件从产生、发展到成熟，直至衰亡为止的整个过程。
它由八个小阶段组成：
国标《计算机软件开发规范》将软件生存周期分为可行性研究与计划、需求分析、总体设计、详细设计、实现(编码和单元测试)、集成测试、确认测试、使用和维护共八个小阶段
这八个小阶段又可以分为三个时期：
计划时期。问题定义、可行性分析
问题定义阶段必须回答的关键问题是"要解决的问题是什么?"如果不知道问题是什么就试图解决这个问题，显然是盲目的。尽管确切地定义问题的必要性是十分明显的，但是在实践中它却可能是最容易被忽视的一个步骤。通过对客户的访问调查，系统分析员扼要地写出关于问题性质、工程目标和工程规模的书面报告，经过讨论和必要的修改之后这份报告应该得到客户的确认。
可行性研究阶段的关键是明确要解决问题，找出行得通解决方法，并且给出粗略的计划。系统分析员需要从经济、技术、社会(操作)等方面对软件项目进行可行性分析。可行性研究应该比较简短，这个阶段的任务不是具体解决问题，而是研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法。可行性研究的结果是使用部门负责人作出是否继续进行这项工程的决定的重要依据。可行性研究以后的那些阶段将需要投入更多的人力物力。及时终止不值得投资的工程项目，可以避免更大的浪费。
开发时期。需求分析、软件设计(总体设计、详细设计)、编码、测试(单元测试和集成测试)
需求分析阶段需要确定目标系统的任务目标以及必须具备哪些功能。系统分析员必须和用户密切配合，充分交流信息以得出经过用户确认的系统逻辑模型。通常用数据流图、数据字典和简要的算法表示在需求分析阶段确定的系统逻辑模型是以后设计和实现系统的基础。这个阶段的一项重要任务，是用正式文档准确地记录对目标系统的需求，这份文档通常称为需求《规格说明书》。
总体设计阶段应该明确用什么方法去实现目标系统。首先，应该根据需求分析阶段的结果设计出实现目标系统的多种可选的方案。通常至少应该设计出低成本、中等成本和高成本等3种方案。软件工程师在充分权衡各种方案的利弊的基础上，推荐一个最佳方案。制定出实现最佳方案的详细计划。一个程序应该由若干个规模适中的模块按合理的层次结构组织而成。总体设计的另一项主要任务就是设计程序的体系结构，也就是确定程序由哪些模块组成以及模块间的关系，最终完成总体设计后需要记录在文档中，这份文档称为《总体设计说明书》。
详细设计阶段的任务就是把实现目标系统的方法具体化。详细设计也称为模块设计，在这个阶段将详细地设计每个模块，确定实现模块功能所需要的算法和数据结构，最终形成一份《详细规格说明》，这种规格说明应该包含必要的细节，程序员可以根据这些细节写出实际的程序代码。
编码和单元测试阶段的关键任务是写出正确的、容易理解、容易维护的程序模块。程序员应该根据目标系统的性质和实际环境，选取适当的程序设计语言，把详细设计的结果翻译成用选定的语言书写的程序，并且仔细测试(调试)编写出的每一个模块。
集成测试阶段的关键任务是通过各种类型的测试(及相立的调试)使软件达到预定的要求。最基本的测试是集成测试和验收测试。所谓集成测试是根据设计的软件结构，把经过单元测试检验的模块按某种选定的策略装配起来，在装配过程中对程序进行必要的测试；所谓验收测试则是按照规格说明书的规定，由用户对目标系统进行验收。必要时还可以再通过现场测试或平行运行等方法对目标系统进一步测试检验，集成测试和验收测试结束后应该形成文档《测试报告》，里面应当写明测试计划、测试方案和结果。
运行时期。软件维护
软件维护阶段是要通过各种必要的维护活动使系统持久地满足用户的需要"。通常有四类维护活动：改正性维护，也就是诊断和改正在使用过程中发现的软件错误；适应性维护，即修改软件以适应环境的变化，例如Windows迁移到Linux；完善性维护，即根据用户的要求改进或扩充软件使它更完善；预防性维护，即修改软件为将来的维护活动预先做准备。每一项维护活动都实质上是经历了一次压缩和简化了的软件定义和开发的全过程。
实际从事软件开发工作时，软件规模、类型、开发环境及技术方法等因素会影响到阶段划分，及各阶段的执行顺序，形成不同生存周期模型，又称过程模型。也就是说以上的三个时期所包含的阶段不一定非要按照国标来进行，应当按照实际情况灵活安排软件周期。
4. 软件开发模型
软件开发模型实际上是软件工程三要素中"过程"要素的展开，下面介绍几种经典的软件开发模型
4.1. 传统开发模型
4.1.1. 瀑布模型(waterfall model)
瀑布模型一直是唯一被广泛采用的生命周期模型，现在它仍然是软件工程中应用得最广泛的文档驱动的过程模型。如下图所示为传统的瀑布模型
瀑布模型区别与其他模型最大的特点有三个：
阶段间具有顺序性和依赖性
(1)必须等前一阶段的工作完成之后，才能开始后一阶段的工作；
(2)前一阶段的输出文档就是后一阶段的输入文档。因此，只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。
推迟实现
对于规模较大的软件项目来说，往往实现(编码和测试)开始得越早最终完成开发工作所需要的时间反而越长。这是因为，前面阶段的工作没做或做得不扎实，过早地考虑进行程序实现，往往带来灾难性后果瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，清楚地区分逻辑设计与物!理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要的指导思想
质量保证
软件工程的基本目标是优质、高产。为了保证所开发的软件的质量，在瀑布模型的每个阶段都应坚持两个重要做法:
(1)每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务；
(2)每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。
传统的瀑布模型过于理想化了，事实.上，人在工作过程中不可能不犯错误。实际的瀑布模型是带"反馈环"的，如下图所示。
实际的瀑布模型当在后面阶段发现前面阶段的错误时，需要沿图中左侧的反馈线返回前面的阶段，修正前面阶段的产品之后再回来继续完成后面阶段的任务。
4.1.2. 快速原型模型(rapid prototype model)
快速原型模型是低成本的，进行循环需求分析的一个快速开发模型。它的基本结构如图所示。
原型是值快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集，然后在用户的不断使用中探明用户需求，不断对原型进行改进，最终完成需求分析。
因此它的两个最大的优点就是：
原型系统已经通过与用户交互而得到验证，据此产生的规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工。
开发人员通过建立原型系统已经学到了许多东西，因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。
4.2. 演化开发模型
4.2.1. 增量模型(incremental model)
增量模型也称为渐增模型。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和
测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。开发流程如下图所示
下图是每一个增量构建的实现过程图：
增量模型能在较短时间内向用户提交可完成部分工作的产品。逐步增加产品功能可以使用户有较充裕的时间学
习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。
但是它也是有缺陷的，增量模型面临的最大困难就是必须保证在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便，也就是说，软件体系结构必须是开放的。
4.2.2. 螺旋模型(spiral model)
螺旋模型的基本思想是，使用原型及其他方法来尽量隆低风险。理解这种模型的一个简便方法，是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。从本质上来讲，螺旋模型就是一个加入了风险分析的快速原型模型。
螺旋模型的主要优势在于，它是风险驱动的。它的开发过程如图所示：
一个螺旋式周期包括下面4个完整步骤：
确定目标，选择方案，选定完成目标的策略
从风险角度分析该策略
启动一个开发阶段
评价前一步的结果，并计划下一轮的工作
4.3. 面向对象开发模型
4.3.1. 构件集成模型(component integration model)
构建集成模型是一个典型的面向对象开发模型，它的一个典例就是各种开发IDE，例如Visual Studio，可以查找加载各种构建。
构建集成模型有着以下五个特点：面向对象、基于构件库、融合螺旋模型特征、支持软件开发的迭代方法、软件重用
