1.2软件工程过程和软件生存周期
1.2.1软件工程过程
软件工程过程规定了获取、供应、开发、操作和维护软件时，要实施的过程、活动和任务、其目的是为各种人员提供一个公共的框架，以便用相同的语言进行交流。
（这个框架有几个重要过程组成、这些主要过程含有用来获取、供应、开发、操作和维护软件所用的基本的一致的要求，该框架还有用来控制和管理软件的过程，各种组织和开发机构可以根据具体情况进行选择和裁剪，可在一个机构的内部和外部实施，软件工程没有规定一个特定的生产周期模型或软件开发方法，各软件开发机构可为其开发项目选择一种生产周期模型，并将软件工程过程所含的过程、活动和任务映射到该模型中，也可以选择和使用软件开发方法来资源是否与其软件的项目和活动任务。）
软件工程过程包含如下7个过程。
1.获取过程
（定义需方按合同获取一个系统，软件产品或服务的活动）
2.供应过程
（定义供方向需方提供合同中的系统，软件产品或服务所需的活动）
3.开发过程
（定义开发者和机构为了定义开发软件或提供服务所需的活动，使过程包括需求分析与设计，编码，集成，测试，软件安装和验收等活动）
4.操作过程
（定义操作者和机构为了在规定的运行环境中为其用户运行一个计算机系统所需要的活动）
5.维护过程
（定义维护者和机构为了修改和管理软件，使他处于良好运行状态所需要的活动）
6.管理过程
（定义软件工程过程中各项管理活动，包括项目开始和范围定义，项目管理计划实施和控制，评审和评价项目完成）
7.支持过程
（支持过程对项目的生产周期过程应予支持，它有助于项目的成功并能提高项目的质量）
1.2.2软件生成周期
软件生存周期是指一个软件从提出开发要求直到该软件报废为止的整个时期。
（软件生存周期是借用工程中产品生存周期的概念而来的，引入软件生存周期概念对于软件生产管理、进度控制有着非常重要的意义，使得软件生产有着相应的模式，相应的流程，相应的工序和步骤，软件生产周期是指一个软件从提出开发要求直到该软件报废为止的整个时期。把整个生产周期划分为若干阶段，使得每个阶段有明确的任务，使规模大，结果复杂和管理复杂的软件开发变得容易控制和管理，软件生存周期的各阶段有不同的划分，软件规模、种类、开发方式。开发环境以及开发使用方法都影响软甲生存周期的划分，在划分软件生存周期阶段，因遵循的一个基本原则是各阶段的任务应尽可能相对独立，同一阶段各项任务的性质尽可能相同，从而降低每个阶段任务的复杂度，简化不同阶段之间的联系，有利于软件项目开发的组织管理。）
通常，软件生存周期包括可行性分析和项目开发计划、需求分析、概要设计、详细设计、编码、测试、维护等活动，可以将这些活动以适当方式分配到不同阶段去完成、
1.可行性分析和项目开发计划
可行性分析和项目开发计划阶段必须要回答的问题是"要解决的问题是什么"。进行问题定义、可行性分析，制定项目开发计划。
（这个阶段必须要回答的问题是要解决的问题是什么，该问题有可行的解决方法吗，若有解决问题的办法，则需要多少费用，需要多少资源，需要多少时间。要回答这问题，就要进行问题定义，进行可行性分析，制定项目开发计划。当用户提出一个用户开发要求后，系统分析员首先解决该软件项目的性质是什么，他是数据处理问题还是实施控制问题，他是科学计算问题还是人工智能问题等等，还要明确该项目的目标是什么，该项目的规模如何等，通过系统分析员对用户和使用部门负责人等访问和调查，开会讨论就可以解决这些问题，在明确了问题的性质目标和规模后，还要确定该问题有没有可行的解决办法，系统分析员要进行样式或简化后的分析和设计，就是在高层次上进行分析和设计，探索这个问题是否值得去解决，是否有可行的解决办法，最后要要提交可行性研究报告，经过可行性分析后，确定该问题值得去解决，然后制定项目开发计划，根据开发项目的目标、功能、性能及规模估计项目需要的资源即需要的计算机硬件资源，需要的软件开发工具和应用软甲包，需要的开发人员数名即层次，还要对软件开发费用做出估算，对开发进度做出估算，制定完成开发任务的实施计划，最后将项目开发和计划可行性报告一起提交管理部门审查)
2.需求分析
需求分析阶段的任务不是具体地解决问题，而是准确地确定"软件系统必须做什么？"确定软件系统必须具备哪些功能。
（用户了解他们所面对的问题，知道必须做什么，但是通常不能完整、准确的表达出来，也不知道怎么用计算机解决他们问题，软件开发人员 知道怎样用软件完成人们提出的各种功能要求，但是对用户的具体业务和需求不完全清楚，这是需求分析的困难所在，系统分析员要和用户密切配合，充分交流自己的理解，充分理解用户的流程，完整地、全面地收集分析用户业务中的信息和处理，从中分析出用户要求的功能和性能，准确完整地表达出来，这一阶段要给出软件需求说明书)
3.概要设计
概要设计就是设计软件的结构，该结构由哪些模块组成，这些模块的层次结构是怎么样的，这些模块的调用关系是怎么样的。每个模块的功能是什么。同时还要设计该项目的应用系统的总体数据结构和数据库结构等
（这个阶段，开发人员要把 确定的各项功能需求转化成需要的体系结构，在该体系结构中，每个成员都是意义明确的模块，即每个模块都和某些功能需求相对应。)
4.详细设计
详细设计阶段就是为了每个模块完整的功能进行具体描述，要把功能描述转变为精确的、结构化的过程描述、
（这个阶段就是该模块的控制是怎样的，先做什么，再做什么，有什么样的条件判断，有些什么重复处理等等，利用相应的表示工具把这些控制结构表示出来，)
5.编码
编码阶段就是把每个模块的控制结构转化成计算机可接受的程序代码，即"源程序清单"。写出的程序应是结构好，清晰易读，并且与设计相一致。
6.测试
测试是保证软件质量的重要手段，其主要方法是在设计测试用例的基础上检验软件的各个组成部分。测试分为模块测试(单元测试)、组装测试（集成测试）、确认测试。
（集成测试是查找各模块在功能和结构上存在的问题，集成测试是将各模块按一定顺序组装起来进行测试，主要是查找各模块之间接口上存在的问题确认测试是按需求说明书上的功能逐项测试，发现不满足用户需求的问题，决定开发的软件是否合格，能否交互用户使用)
7.维护
已交付的软件投入正式使用后，便进入软件维护阶段，它可以持续几年甚至几十年，是软件生存周期时间最长的阶段，可能由于各方面的原因，需要对软件进行修改。
（修改可能是运行中发现了软件隐含的错误而需要修改，也可能是为了适应变化，有的软件工作环境而需要做适当的变更，也可能是因为用户业务发生变化而需要扩充和增强软件的功能，)
1.3软件生存周期模型、方法和工具
1.3.1软件生存周期模型
软件生存周期模型是描述软件开发过程中各种活动如何执行的模型。
（模型是为了理解事物而对事物做出一种抽象，他忽略不必要的细节，他也是事物的一种抽象形式，一个规划，一个程式。一个强有力的软件生存周期模型对软件开发提供强有力的支持，为软件开发过程中所有活动提供统一的政策保障，为参与软件开发的所有成员提供帮助和指导，他揭示了如何演绎软件过程的思想，他是软件生存周期模型化技术的基础，也是建立软件开发环境的核心，软件生存周期模型确立了软件开发和演绎中各阶段的次序限制以及各阶段活动的准则，确立开发过程所遵守的规定和限制，便于各种活动的协调，便于各种人员的有效通讯，有利于活动重用，有利于活动管理，软件生存周期模型能表示各种活动的实际工作，他能随情况的变化而演化，他能表示各种活动间的同步和制约关系，他能表示活动的动态特征，生存周期模型应该容易为软件开发过程中的各类人员所理解，他应该适应不同的软件项目，应该具有较强的灵活性，应该支持软件开发环境建立，)
目前有若种软件生存周期模型，如瀑布模型、增量模型、螺施模型、喷泉模型。变换模型和基于知识模型等。
1.瀑布模型
瀑布模型是将近软件生存周期各活动规定为依线性顺序联接的若干阶段的模型。它包括可行性分析、软件开发项目、需求分析、概要设计、详细设计、编码、测试和维护。
瀑布模型为软件开发提供了一种有效的管理模型。它是以文档作为驱动、适合于需求很明确的软件项目开发的模型。
瀑布模型严格按照生存周期各个阶段的目标、任务、文档和要求来进行开发。
（瀑布模型为软件开发提供了一种有效的管理模型，根据这个模式制定开发计划，进行成本预算，组织开发力量，以项目的阶段评审和文档控制为手段有效得对整个开发过程进行指导，所以它是以文档作为驱动、适合于需求很明确的软件项目开发的模型，二十多年来，瀑布模型得到了广泛的应用他是在消除非结构化软件，降低软件的复杂性，促进软件开发工程化起到了很大的作用，但是瀑布模型在大量的软件开发实践中也逐渐暴露出了他的严重缺点，它是一种理想的线性开发模式，缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题，这些缺点对软件开发带来了严重的影响，最终可能导致开发出的软件并不是用户真正需要的软件，并且这一点在开发过程完成之后才能发现，为时已晚，针对这些情况，无疑需要进行返工，或者在运行中进行打大量的修改，不管是返工还是大量修改，都必须付出巨大的代价，给软件开发带来不必要的损失，同时，随着软件爱开发项目的规模日益扩大，瀑布模型缺乏灵活性的缺点引发的问题更为严重，为克服瀑布模型的不足，现在已经提出了若干其他模型。)
（上图就是瀑布模型的图，有三个阶段，定义阶段包括两个：计划和需求分析,开发阶段也叫做设计阶段，包括设计、编码、测试、维护阶段就是运行和维护了，如第一个有两条线，回来的线表示当需求分析的时候发现不对，有问题，那么需要回头，就要看计划，如果在设计阶段发现问题的话就要找需求分析而不能直接找计划，所以它每一步这个时间的阶段的性非常，每个阶段的依赖性非常明显，第一阶段完成的形成的文档就是第二阶段的参考文档，第二阶段出现的问题一定是找第一阶段，所以这种瀑布模型开发出来的软件一般是比较严格的，但是他的缺点就可以看出来是周期比较长一些，另外还有一个不足这个程序要在运行时用户才能看到，所以在开始计划，设计，编码，调试过程当中我们还见不到程序的原貌，这种情况就跟用户见面比较晚，还有一个问题就是定义阶段主要是用户和设计人员一起来完成，就是开发人员要到现场听取用户的汇报，看用户的资源的，了解现有的现状，那么一旦形成了需求分析之后，开发阶段用户就很少过分了，全是设计人员，到现场调试时跟用户才见面，所以中间有一部分是用户和开发人员是分开的在，这样的问题就是用户有一些问题不能及时反映给开发人员，开发人员就完全按照这个路子来做)
2.增量模型
瀑布模型是一种整体开发模型。在开发过程中，用户看不到软件是什么样子，只有开发完成后，整个软件才全部展现在用户面前
增量模型是一种非整体开发的模型。软件在该模型中是"逐渐"开发出来的，开发出一部分，向用户展示一部分，可让用户及早看到部分软件，及早发现问题。或者先开发一个"原型"软件，完成部分主要功能，展示给用户并征求意见，然后逐步完善，最终获得满意的软件产品。该模型具有较大的灵活性，适合于软件需求不明确、设计方案有一定风险的软件项目
3.螺旋模型
螺旋模型将瀑布模型与增量模型结合起来，加入了两种模型均忽略了风险分析，弥补了这两种模型的不足
螺旋模型是一种风险驱动的模型。实践表明，项目越复杂，实际方案、资源、成本和进芳等因素的不确定性越大，项目开发的风险也越大。因此，应及时对风险进行识别。分析和采取对策，从而消除或减少风险的危害
螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合。每个螺旋周期可分为4个工作步骤。第一，制定计划；第二，风险分析；第三，开发实施；第四，用户评估、
螺旋模型适合于大型软件的开发，它吸收了软件工程"演化"的概念，使得开发人员和用户对每个螺旋周期出现的风险有所了解，从而做出相应的反应，但是，使用该模型需要有相当丰富的风险评估经验和专门的知识，这使得模型的应用受到一定限制。
（上图就是螺旋模型，就是从里面每转一圈，就经历4个阶段，产生一个圆形，首先左上角，确定计划就是确定我们的目标实施方案和限制，指定完了紧接着就是风险分析，所以注意是从起点向右边转，第二块第二部分就是风险分析，那就这里的主要问题是对我们指定的目标方案进行了风险评估，包括评价我们的方案识别风险和消除风险，我们每个方案都会存在一些风险，比如说我们的技术能不能可行，或者我们的进度能不能完成，我们的这个人力情况，设备情况都要对它进行风险评估，然后风险评估结束后，我们就开发一个原型，原型1，到了实施阶段就是软件开发阶段，还是遵循瀑布模型，设计编码测试需求分析，确认，设计验证等等还是遵循我们的传统的瀑布模型开发，开发完了之后客户评价，客户评价就是对我们开发的这些产品进行了运行和评价，评价就要产生一些修改意见，修改意见，又开始制定新的目标，对一个原型用户提出的问题包括风险分析提出的问题进行修正，反复这么做，就是每转一圈产生一个新的版本，一直到最后用户认可了，能够完成我们的需求分析才能交给用户使用，所以螺旋模型一般对大型的软件来讲，比较提倡使用，但有一个问题，一般需要专门的人员进行风险分析，而一些小的公司可能专门从事风险分析的人员水平不太高，所以一般大的公司开发大的项目经常专门的人员做风险分析，螺旋模型也是逐渐递增的)
4.喷泉模型
喷泉模型是一种以用户需求为动力，以对象作为驱动的模型。它适合于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性。系统某些部分常常重复工作多次，相关功能在每次迭代中随之加入演化的系统。无间隙是指在分析、设计和实现等开发活动之间不存在明显的边界。
（喷泉模型是以面向对象的软件开发方法学 为基础，以用户需求作为喷泉模型的源泉，看模型就是水往上喷，如果维护阶段出现了问题，这个水可以落到确认阶段，就是哪个阶段发现问题及遇到哪个阶段修改，他并不是维护阶段必须等到确认，到实践，同样，这些阶段的开发有的时候可以同时进行，所以它的特点是没有间隙，可以迭代，多个部分同时进行，)
5.基于知识的模型
基于知识的模型又称职能模型，它把瀑布模型和专家系统结合在一起。该模型在开发的各个阶段上都利用了相应的专家系统来帮助软件人员完成开发工作，使维护在系统需求说明一级上进行。为此，建立了各个阶段所需要的知识库，将模型、相应知识领域和软件工程知识存入数据库，以软件工程知识为基础的生成规则构成的专家系统与含有应用领域知识规则的其他专家系统相结合，构成了该应用领域的开发系统。
（在用户概念需求分析阶段有这个支持需求分析的专家系统，在概要设计何详细设计有支持设计的专家系统，在测试阶段有支持测试的专家系统，在维护阶段有维护的专家系统)
6.变换模型
变换模型是一种适合于形式化开发方法的模型。从软件需求形式化说明开始，经过一系列变换 ，最终得到系统的目标程序。