一、软件工程的定义
软件工程学是一门指导软件开发和维护的工程学科，是为了经济地获得能够在实际机器上有效运行的可靠软件而建立和使用的一系列完善的工程化原则。它应用计算机科学、数学及管理科学等原理，借鉴传统工程的原则、方法来生产软件，以达到提高质量、降低成本的目的。
软件工程包括3个要素：方法、工具和过程
二、软件工程的目标
软件工程研究的目标是“以较少的投资获取高质量的软件”。
即从技术和管理上采取多项措施以后，组织实施软件工程项目的最终目的是保证项目成功，即达到以下几个主要目标：
能按时完成开发工作，及时交付使用
在项目的实际开发中，使以上几个目标都达到理想的程度往往非常困难，而且上述目标很可能是相互冲突的。软件过程所实现的多目标中，有的是互补的，例如缩短开发期，显然可降低成本，维护是需要代价的，易于维护就可降低总成本。高性能与高可靠性是互补的。而有的目标则是互斥的，例如，要获得高的可靠性，通常要采取一些冗余的措施，往往成本会增加。
以上几个目标是判断软件开发方法或管理方法优劣的衡量尺度。在一种新的开发方法提出以后，人们关心的是它对满足哪些目标比现有的方法更为有利。实际上实施软件项目开发的过程就是在以上目标的冲突中取得一定程度平衡的过程。为了实现软件工程的多目标，要对软件的的各项质量指标进行综合考虑，以实现软件开发的“多！快！好！省！”的总目标。
三、软件工程的原则
1. 分解
分解是人类分析解决复杂问题的重要手段和基本原则，其基本思想是从时间上或是从空间上将一个复杂抽象问题分成若干个较小的、相对独立的、容易求解的子问题，然后分别求解。软件瀑布模型，结构化分析方法，结构化设计方法，Jackson方法，模块化设计都运用了分解的原则
2. 抽象和信息隐蔽
尽量将可变因素隐藏在一个模块内，将怎样做的细节隐藏在下层，而将做什么抽象到上一层做简化，从而保证模块的独立性。这就是软件设计独立性要遵守的基本原则。模块化和局部性的设计过程使用了抽象和信息隐蔽的原则。
3. 一致性
研究软件工程方法的目的之一，就是要使开发过程标准化，使软件产品设计有共同遵循的原则。要求软件文件格式一致，工作流程一致，软件开发过程要标准化，统一化。
4. 确定性
软件开发过程要用确定的形式表达需求，表达的软件功能应该是可预测的，用可测试性，易维护性，易理解性，高效率的指标来具体度量软件质量。
5. 完备性
软件系统不丢失任何重要成分，可以完全实现系统所要求的功能。为保证系统的完备性，在软件开发和运行过程中需要严格的技术评审。
6. 可验证性
开发大型的软件时需要对系统逐层分解，系统分解应遵循使系统易于检查、测试、评审的原则，以确保系统的正确性。
四、软件生存周期
同任何事物一样，软件也有一个孕育、诞生、成长、成熟和衰亡的生存过程。软件生存周期是指一个软件从提出开发要求开始直到该软件报废为止的整个时期。把整个生存周期划分为若干阶段，使得每个阶段有明确的任务，把规模大、结构复杂和管理复杂的软件开发变得容易控制和管理。
1. 问题定义及可行性研究
(1) 问题定义
问题定义要回答的关键问题是：“要解决的问题是什么?”，系统分析员应提出关于问题的性质、软件系统的目标和规模的书面报告。通过对系统的实际用户和使用部门负责人的访问调查，分析员要扼要地写出他对问题的理解，并在用户和使用部门负责人的会议上认真讨论这份书面报告，澄清含糊不清的地方，改正理解不正确的地方，最后得出一份双方都满意的文档。
(2) 可行性研究
可行性研究要回答的关键问题是：“对于定义的问题有行得通的解决办法吗?”。这个阶段的任务不是具体解决问题，而是研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法。这一阶段，系统分析员需在较短的时间内模拟进行系统分析和设计过程，即在较抽象的层次下进行分析和设计。系统分析员应对用户的需求和环境进行深入细致的调查，在此基础上进行技术上、经济上、法律上等多方面的可行性论证。
可行性研究的结果是使用部门负责人做出是否继续进行这项工程的决定的重要依据，一般说来，只有投资可能取得较大效益的那些工程项目才值得继续进行下去。不值得投资的工程项目要及时中止，避免更大的浪费。
2. 需求分析
需求分析阶段的任务不是具体地解决问题，而是准确地确定“软件系统必须做什么”，确定软件系统必须具备哪些功能。系统分析员在需求分析阶段必须和用户密切配合，充分交流信息，需要对用户的需求去粗取精、正确理解，然后把它用软件工程开发语言表达出来，以得出经过用户确认的系统逻辑模型。通常用数据流图、数据字典和简要的算法描述表示系统的逻辑模型。该模型必须准确全面地体现用户的需求，是以后设计系统的基础。该阶段的主要任务是：对用户提出的要求进行分析并给出详细的定义；编写软件需求说明书及初步的系统用户手册，提交管理机构评审。
3. 概要设计
概要设计阶段要解决的问题是：“应该如何宏观地实现系统功能？” 。把各项功能需求转换成需要的体系结构，在该体系结构中，每个成分都是意义明确的模块，即每个模块都和某些功能需求相对应，以比较抽象概括的方式提出了解决问题的办法。概要设计的主要任务是选择合适的设计方案，确定软件的结构，模块的功能和模块间的接口以及全局数据结构的设计。
4. 详细设计
详细设计阶段要完成的工作就是对每个模块要完成的功能进行具体描述，即把解决方法具体化。详细设计的任务是设计每个模块的实现细节和局部数据结构。这个阶段的任务还不是编写程序，而是设计出程序的详细规格说明。这种规格说明的作用很类似于其它工程领域中工程师经常使用的工程蓝图，它们应该包含必要的细节，程序员可以根据它们写出实际的程序代码。
5. 编码
编码阶段就是把每个模块的控制结构转换成计算机可接受的程序代码，即写成以某特定程序设计语言表示的“源程序清单”。程序员应该根据目标系统的性质和实际环境，选取一种适当的程序设计语言，把详细设计的结果翻译成用选定的语言书写的程序，并且仔细测试编写出的每一个模块。具体的工作包括以下两个方面：把软件设计转换成计算机可以接受的程序代码，即写成以某一种特定程序设计语言表示的“源程序清单”；写出的程序应当是结构良好、清晰易读，且与设计相一致的。
6. 测试
软件分析、设计、程序编写过程中难免有各种各样的错误，需要通过测试来查找和修改，以保证软件的质量。软件测试阶段的主要任务是：
单元测试：查找各模块在功能和结构上存在的问题并加以纠正；
组装测试：将已测试过的模块按一定顺序组装起来；
有效性测试：按规定的各项需求，逐项进行测试，决定已开发的软件是否合格，能否交付用户使用。
7. 维护
软件项目开发成功后，要投入运行。软件系统在运行过程中，受系统内、外环境变化及各种人为的、技术的、设备的影响，要求软件能够适应这种变化，不断地完善，这就要进行软件维护，以保证正常而可靠地运行，并能使软件不断地得到改善和提高，充分发挥其作用。
软件维护有四种类型，它们分别完成以下各自的任务：
改正性维护：运行中发现了软件中的错误而进行的修正工作；
适应性维护：为了适应变化了的软件工作环境，而做出适当的变更；
完善性维护：为了增强软件的功能而做出的变更；
预防性维护：为未来的修改与调整奠定更好的基础而进行的工作。
在软件工程中的每一个步骤完成后，为了确保活动的质量，必须进行评审。为了保证系统信息的完整性和软件使用的方便，还要有相应的详细文档。
在大部分文献中将生存周期划分为5个阶段，即要求定义、设计、编码、测试及维护。其中，要求定义阶段包括可行性研究和项目开发计划、需求分析，设计阶段包括概要设计和详细设计。
为了描述软件生存期的活动，提出了多种生存期模型。例如：瀑布模型、快速原型模型、增量模型、喷泉模型、螺旋模型等。
五、软件开发模型
为了反映软件生存周期内各种工作应如何组织及周期各个阶段应如何衔接，需要用软件开发模型给出直观的图示表达。软件开发模型是软件工程思想的具体化，是实施于过程模型中的软件开发方法和工具，是在软件开发实践中总结出来的软件开发方法和步骤。总的说来，软件开发模型是跨越整个软件生存周期的系统开发、运作、维护所实施的全部工作和任务的结构框架。
->瀑布模型
瀑布模型也称为“传统生命周期”或“线性顺序模型”。瀑布模型是将软件开发活动中的各项活动规定为依线性顺序联接的若干阶段工作，形如瀑布流水，最终得到软件系统或软件产品。瀑布模型提出了软件开发的系统化、结构化的方法，它是按照分析、设计、编码、测试和维护顺序进行的，借鉴了传统的工程周期。换句话说，它将软件开发过程划分成若干个互相区别而又彼此联系的阶段，每个阶段中的工作都以上一个阶段工作的结果为依据，同时作为下一个阶段的工作基础。
瀑布模型如图所示，从图中可以看出每项开发活动均应具有下述特征：
瀑布模型得到了广泛的应用，它在消除非结构化软件、降低软件的复杂性、促进软件开发工程化方面起了很大的作用。但在大量的仍然机软件开发实践中也逐渐暴露出它的缺点。由于瀑布模型是一种理想的线性开发模式，缺乏灵活性，也无法解决软件需求不准确或者不明确的问题。这些缺点对软件开发带来了严重影响，由于需求不明确，会导致开发的软件不符合用户的需求而夭折。另外，由于软件开发需要人们合作完成，因此人员之间的通讯和软件工具之间的联系以及开发工作之间的并行和串行等都是必要的，但瀑布模型中并没有体现出这一点。
->快速原型模型
快速原型模型如图所示，从需求分析开始。软件开发者和用户在一起定义软件的总目标，说明需求，并规划出定义的区域。然后快速设计软件中对用户/客户可见部分的表示。快速设计导致了原形的建造，原形由用户/客户评估，并进一步求精待开发软件的需求。逐步调整原形使之满足用户需，这个过程是迭代的。原型模型的优点和缺点如下所述。
1. 优点
快速原型模型法在得到良好的需求定义上比传统生存周期法好得多，不仅可以处理模糊需求，而且开发者和用户可充分通信。
快速原型模型系统可作为培训环境，有利于用户培训和开发同步，开发过程也是学习过程。
快速原型模型给用户以机会更改心中原先设想的、不尽合理的最终系统。
快速原型模型可以低风险开发柔性较大的计算机系统。
快速原型模型使系统更易维护、对用户更友好的机会。
快速原型模型使总的开发费用降低，时间缩短。
2. 缺点
“模型效应”或“管中窥豹”。对于开发者不熟悉的领域把次要部分当作主要框架，做出不切题的原型。
原型迭代不收敛于开发者预先的目标。为了消除错误，每次更改，次要部分越来越大，“淹没”了主要部分。
原型过快收敛于需求集合，而忽略了一些基本点。
资源规划和管理较为困难，随时更新文档也带来麻烦。
长期在原型环境上开发，只注意得到满意的原型，容易“遗忘”用户环境和原型环境的差异
3. 适用范围
4. 不适用范围
->增量模型
增量模型是一种非整体开发的模型。根据增量的方式和形式的不同，分为基于瀑布模型的渐增模型和基于原型的快速原型模型。
该模型具有较大的灵活性，适合于软件需求不明确、设计方案有一定风险的软件项目。增量模型和瀑布模型之间的本质区别是：瀑布模型属于整体开发模型，它规定在开始下一个阶段的工作之前，必须完成前一阶段的所有细节。而增量模型属于非整体开发模型，它推迟某些阶段或所有阶段中的细节，从而较早地产生工作软件
->喷泉模型
喷泉模型是由B.H.Sollers和J.M.Edwards于1990年提出的一种新的开发模型。主要用于采用对象技术的软件开发项目。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性。软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分，即为迭代的特性；而分析和设计活动等各项活动之间没有明显的边界，即为无间隙的特性。喷泉模型与传统的结构化生存期比较，具有更多的增量和迭代性质，生存期的各个阶段可以相互重叠和多次反复，而且在项目的整个生存期中还可以嵌入子生存期。就像水喷上去又可以落下来，可以落在中间，也可以落在最底部。
喷泉模型是以面向对象的软件开发方法为基础，以用户需求作为喷泉模型的源泉。从图中可以看出其特点如下：
(1) 喷泉模型规定软件开发过程有4个阶段，即分析、系统设计、软件设计和实现。
(2) 喷泉模型的各阶段相互重叠，它反映了软件过程并行性的特点。
(3) 喷泉模型以分析为基础，资源消耗成塔型，在分析阶段消耗的资源最多。
(4) 喷泉模型反映了软件过程迭代性的自然特性，从高层返回低层无资源消耗。
(5) 喷泉模型强调增量开发，它依据分析一点，设计一点的原则，并不要求一个阶段的彻底完成，整个过程是一个迭代的逐步提炼的过程
(6) 喷泉模型是对象驱动的过程，对象是所有活动作用的实体，也是项目管理的基本内容。
(7) 喷泉模型在实现时，由于活动不同，可分为系统实现和对象实现，这既反映了全系统的开发过程，也反映了对象族的开发和重用过程。
-> 螺旋模型
对于大型软件，只开发一个原型往往达不到要求。螺旋模型将瀑布模型和增量模型结合起来，并加入了风险分析。它是由TRW公司的B.Boehm于1988年提出的。
软件风险是普遍存在于任何软件开发项目中的实际问题。对于不同的项目，其差别只是风险有大有小而已，在制定软件开发计划时，系统分析员必须回答：项目的需求是什么，需要投入多少资源以及如何安排开发进度等一系列问题。然而，要他们当即给出准确无误的回答是不容易的，甚至几乎是不可能的。但系统分析员又不可能完全回避这一问题，凭借经验的估计出发给出初步的设想便难免带来一定风险。实践表明，项目规模越大，问题越复杂。资源、成本、进度等因素的不确定性越大，承担项目所冒的风险也越大。总之，风险是软件开发不可忽视的潜在不利因素，它可能在不同程度上损害到软件开发过程或软件产品的质量。软件风险驾驭的目标是在造成危害之前及时对风险进行识别、分析，采取对策，进而消除或减少风险的损害。
模型将开发划分为制定计划、风险分析、实施工程和客户评估四类活动。沿着螺旋线每转一圈，表示开发出一个更完善的新的软件版本。如果开发风险过大，开发机构和客户无法接受，项目有可能就此终止；多数情况下，会沿着螺旋线继续下去，自内向外逐步延伸，最终得到满意的软件产品。螺旋模型沿着螺线旋转，将开发过程分为几个螺旋周期，如图所示，每个螺旋周期可分为4 个工作步骤：
第一步，制定计划：确定目标、方案和限制条件；
第二步，风险分析：评估方案、标识风险和解决风险；
第三步，实施工程：开发确认产品；
第四步，客户评估：计划下一周期工作。
沿螺线自内向外每旋转一圈便开发出更为完善的一个新的软件版本。例如，在第一圈，确定了初步的目标、方案和限制条件以后，转入右上象限，对风险进行识别和分析。如果风险分析表明，需求有不确定性，那么在右下的工程象限内，所建的原型会帮助开发人员和客户，考虑其他开发模型，并对需求做进一步修正。客户对工程成果做出评价之后，给出修正建议。在此基础上需再次计划，并进行风险分析。在每一圈螺线上，做出风险分析的终点是否继续下去的判断。假如风险过大，开发者和用户无法承受，项目有可能终止。多数情况下沿螺线的活动会继续下去，自内向外，逐步延伸，最终得到所期望的系统。
如果软件开发人员对所开发项目的需求已有了较好的理解或较大的把握，则无需开发原型可采用普通的瀑布模型，这在螺旋模型中可认为是单圈螺线。与此相反，如果对所开发项目需求理解较差，则需要开发原型，甚至需要不止一个原型的帮助，那就需要经历多圈螺线。在种情况下，外圈的开发包含了更多的活动。也可能某些开发采用了不同的模型。
螺旋模型适合于大型软件的开发，应该说它是最为实际的方法，它吸收了软件工程“演化”既念，使得开发人员和客户对每个演化层出现的风险有所了解，继而做出应有的反映。螺旋模型的优越性比起其他模型来说是明显的，但并不是绝对的。要求许多客户接受和使用该模型并不容易。这个模型的使用需要具有相当丰富的风险评估经验和专门知识，如果项目风险较大，又未能及时发现，势必造成重大损失。此外，螺旋模型是出现较晚的新模型，远不及瀑布模型普及，要让广大软件人员和用户充分肯定它，还有待于更多的实践。
谢谢园友们能够看到这里，证明你们有一种对知识的渴望和求知的欲望，相信通过我们不断的学习，不管是理论知识还是实际开发技术，都会得到一个好的提升，重在坚持哦！加油！
