计算机软件是由专业人员开发并长期维护的软件产品。完整的软件产品包括：可以在不同容量及系统结构的计算机上运行的程序，程序运行过程中产生的各种结果以及各种描述信息，这些信息可以以硬件拷贝或是各种电子媒介的存在。
人员：软件工程师开发软件并提供技术支持，产业界中几乎每个人都间接或直接的使用软件。
步骤：客户和利益相关者表达对计算机软件的要求，工程师构建软件产品，最后用户应用软件来解决特定的问题或满足特定的要求。
工作产品：在一种或多种特定的环境中运行并服务于一个或多个最终用户要求的计算机软件。
质量保证措施
软件工程师：应用软件思想。
最终用户：理解自己的要求和环境。
软件具有产品和产品交付载体的双重作用。作为产品，软件显示了有计算机硬件体现的计算能力，更广泛的说，显示的是由一个可被本地硬件设备访问的计算机网络体现的计算机潜力。扮演信息转换的角色。作为产品生产的载体，提供了计算机控制，信息通信以及应用程序开发和控制的基础平台。

定义软件

指令的集合（计算机程序），通过这些指令可以满足预期的特性，功能和性能需求。
数据结构，使得程序可以合理地利用信息。
软件描述信息，以硬拷贝和虚拟形式存在，用来描述程序的操作和使用。
软件是逻辑的而非物理的系统元素，软件不会磨损。
硬件的磨损

软件的失效率

在完整的生命周期里，软件将会面临变更，每次变更都可能引入新的错误，使得失效率向实际曲线那样陡然上升，在曲线回归到最初的稳定失效率状态前，新的变更会引起曲线的又一次上升，不断的变更是软件退化的根本原因。软件工程方法的的目的是降低曲线向上突起的幅度即实际失效曲线的斜率。

软件的应用领域

系统软件
应用软件
工程/科学软件
嵌入式软件
产品线软件：关注有限的及内部的市场或者大众消费市场。
Web/移动App
人工智能软件

遗留软件

制程核心的商业功能，生命周期长以业务的关键性。质量差：遗留系统的设计难以扩展，代码令人费解，文档混乱甚至没有，测试用例和结果并未归档，变更历史管理混乱。
若遗留软件可以满足用户的需求并且能够可靠运行，那么他就没有失效，不需要修改。
可能的变更原因：需要进行适应性调整，满足新的计算环境或技术的需求。必须升级已实现新的商业需求。必须扩展以使之具有新的系统和数据库的互操作能力。软件架构必须进行更改以使之适应不断演化的计算环境。

软件的变更本质

WebApp

连接在一起的超文本文件，使用文本和有限的图形来表示信息。
提供计算能力。
如今的WebApp不仅可以为最终用户提供独立的功能，而且已经同公司数据库可和业务应用系统集成在一起了。

移动App

包括用户接口，用户接口利用移动平台所提供的独特的交互机制，基于Web资源的互操作性提供与App相关的大量信息的访问，并具有本地处理能力，以最适合移动平台的方式收集，分析和格式化信息。
移动WebApp：允许移动设备通过针对移动平台的优点和弱点专门设计的浏览器获取基于Web内容的访问。
移动App可以直接访问设备的硬件特性提供本地处理和存储能力。

云计算

最简单的形式是外部计算设备通过Web浏览器或类似的软件访问云。云提供对存储在数据库或其他数据结构中的数据的访问
能使得任何用户在任何地点都可以使用计算设备来共享广泛的计算资源。
前段包括客户设备和应用软件，用于访问后端。
后端包括服务器和相关的计算资源，数据存储系统，服务器驻留应用程序和管理服务器。

产品线软件

定义：一系列软件密集型系统，可以共享一组公共的可管理的特性，这些特性可以满足特定市场或特定任务的特定需求，并以预定的方法从一组公共的核心资源开发出来。
使用相同的低层应用软件和数据体系结构来开发，并使用可在整个产品线中进行复用的一组软件构件来实现。
软件产品线共享一组资源，包括需求，体系结构，可重用构件，测试用例及其他如软件工程工作产品。

软件工程

软件工程包括过程，一系列方法和大量工具，专业人员借由这些来构建高质量的计算机软件
在确定软件方案之前需要共同努力来理解问题，设计已经成为关键活动，软件应该具有高质量，具备可维护性。各种形式，各个应用领域的软件都需要工程化。

定义软件工程学科

在这里插入图片描述

软件工程是将系统化的，规范的，可量化的方法应用于软件的开发，运行和维护，即将工程化的方法应用于软件。是一种层次化的技术。
任何工程方法必须构建在质量承诺的基础上，支持软件工程的根基在于质量关注点。
软件工程的基础是过程，软件过程将各个技术层次结合在一起，使得合理及时的开发出计算机软件成为可能。过程定义了一个框架，构建该框架是有效实施软件工程技术必不可少的。软件过程构成了软件项目管理控制的基础，建立了工作环境以便于应用技术方法，提交工作产品，建立里程碑，保证质量及正确的管理变更。
软件过程方法为构建软件提供技术上的解决方法。包括沟通，需求分析，程序构造，测试和技术支持。软件过程方法依赖于一组基本的原则，这些原则涵盖了软件工程所有技术领域，包括建模活动和其他描述性技术等。
软件过程工具为过程或方法提供自动化或半自动化的支持。这些工具可以集成起来，使得一个工具产生的信息可以被另外一个工具使用，这样就建立了软件开发的支撑系统，称为计算机辅助软件工程。

软件过程

软件过程是工作产品构建时所执行的一系列活动，动作和任务的集合。
活动：主要实现宽泛的目标，与应用领域，项目大小，结果复杂性或者实施软件工程的重要程度没有直接关系。
动作：包括主要工作产品生产过程中的一系列任务。
任务：关注小而明确的目标，能够产生实际产品。
过程不是严格规定，而是一种具有可适应性的调整方法。
目标：及时，高质量的交付软件。

过程框架

定义了若干个框架活动，为完整的软件工程过程建立了基础。框架活动可以迭代应用，每次迭代都会产生一个软件增量，每个软件增量实现了部分软件特性和功能。随着每一次增量的产生，软件逐渐完善。
沟通：理解利益相关者的项目目标，并收集需求以定义软件特性和功能。
策划：定义和描述了软件工程的工作，包括需要执行的任务，可能的风险，资源需求，工作产品和工作进度计划。
建模：
构建：编码和测试。
部署：交付用户，用户对其测评并给出反馈意见。

普适性活动

软件项目跟踪和控制：根据计划来评估项目进度，并且采取必要的措施保证项目按进度计划进行。
风险管理：对可能影响项目成果或产品质量的风险进行评估。
软件质量保证
技术评审：评估软件工程产品，尽量在错误传播到下一个活动之前发现并清除错误。
测量：定义和收集过程，项目及产品的度量，以帮助团队在发布软件时满足利益相关者的要求。可以与其他活动配合使用。
软件配置管理：管理变更所带来的影响。
可复用管理：定义工作产品复用的标准（包括软件构件），并建立构建复用机制。
工作产品的准备和生产：包括生成产品所需要的活动。

过程的适应性调整

不同项目的项目过程可能体现在：

活动，动作和任务的总体流程以及相互依赖关系。
在每一个框架活动中，动作和任务细化的程度。
各种产品的定义和要求的程度。
质量保证活动应用的方式。
项目跟踪和控制活动应用的方式。
过程描述的详细程度和严谨程度。
客户和利益相关者对项目的参与程度。
软件团队所赋予的自主权。
队伍组织和角色的明确程度。

软件工程实践

实践的精髓

理解问题：谁是利益相关者，那些数据，功能和特性是解决问题所必需的，是否可以描述为更小，更容易理解的问题，是否可以建模分析。
策划方案：在潜在的解决方案中，是否可以识别一些模式，是否已经有软件实现了所需要的数据，功能和特性。解决方案所包含的元素是否可以复用。能构建出设计模型么。
实施计划：源码是否可以追溯到设计模型（解决方案和计划是否一致）。设计和代码是否经过评审，或者采用更好的方式，算法是否经过正确性证明。
检查结果的正确性：是否实现了合理的测试策略，是否按照项目利益相关者的需求进行了确认。

通用原则

存在价值：一个软件系统因为能为用户提供价值而存在价值。
保持简洁：尽可能简洁但不是过于简化。有助于构建更易于理解和维护的系统。
保持愿景：保证系统实现始终与愿景保持一致。
关注使用者：通常软件系统由开发者以外的人员使用，维护和编制文档。
面向未来：适应各种变化。
提前计划复用：可以降低开发费用，并增加可复用构件以及构件化系统的价值。
认真思考：

误区

“软件开发宝典”并非真实存在，或无法提供我们需要了解的全部信息。
为赶进度而增加人手只能使进程更加延误。
外包并非是完全不管。
对项目目标模糊不清的描述会给项目的实施带来灾难。要得到清晰的需求描述只能通过持续有效的沟通。
软件不是可以随便变更的，框架可能会被修改。
交付即结束。
技术评审可以从项目启动就开始实行。
可以交付的工作成果包括可执行程序，模型，文档，计划等。
创建文档可以保证软件产品的开发质量。

软件过程结构

软件过程是一个为创建高质量软件所需要完成的活动，动作和任务的框架。
软件过程定义了软件工程化中采用的方法，但软件工程还包含该过程中应用的技术和自动化工具。

通用过程模型

过程定义为在工作产品构建过程中所需完成的工作活动，动作和任务的集合。这些活动，动作和任务的每一个都隶属于某一框架或模型，框架或模型定义了他们与过程之间或相互之间的关系。
每个框架活动有一系列软件工程动作构成，每个软件工程动作由任务集来定义，这个任务集明确了将要完成的工作任务，将要产生的工作产品，所需要的质量保证点，以及用于表明过程状态的里程碑。框架活动和普适性活动贯穿软件过程始终。
过程流描述了在执行顺序和执行时间上如何组织框架中的活动，动作和任务。

线性过程流

迭代过程流：在执行下一个活动前重复执行之前的一个或多个活动。

演化过程流

并行过程流

定义框架活动

针对给定的问题，开发人员和利益相关者，那些动作适合于框架活动。

明确任务集

每一个软件工程动作都由若干个任务集构成，每一个任务集都由软件工程工作任务，相关工作产品，质量保证点以及状态的里程碑组成。定义了为达到一个软件工程的目标所需要完成的工作。
需要选择最能满足项目需要并适合开发团队特点的任务集，即工程动作可以适当调整。

过程模式

过程模式描述了软件工程工作中遇到的过程相关的问题，明确了问题的环境并给出了针对该问题的一种或几种可证明的解决方法，即提供了一种模板，一种在软件过程的背景下统一描述问题解决方案的一种方法。
可以在不同的抽象层次上定义模式。在某些情况下，模式可以描述一个与完整过程模型（如原型开发）相关的问题；在其他情况下，模式可以描述一个与框架活动或框架活动中的一个动作相关的问题。
模式使得软件工程组织能够从高层次抽象（阶段模式）开始建立层次化的过程描述，然后每一个步骤模式由逐层细化为更详尽的任务模式。
过程模式一旦建立起来，就可以进行复用以定义各种过程变体。

过程模式的描述模板

模式名称
驱动力：模式的使用环境及主要问题。
类型：定义模式类型
步骤模式：定义了与过程的框架活动相关的问题。由于框架活动包括很多动作和工作任务，因此，步骤模式包括与步骤有关的许多任务模式。

任务模式：定义了与软件工程动作或是工作任务相关，关系软件工程实践成败的问题。

阶段模式：定义在过程中发生的框架活动序列，即使这些活动流本质上是迭代的。
启动条件：模式应用的前提条件。应用模式之前需要明确：在此之前，整个开发组织或是开发团队内已经有哪些活动。过程的进入状态是什么。已经有哪些软件工程信息或是项目。
问题：描述模式要解决的具体问题。
解决方案：描述如何成功实现模式。随着模式的启动，过程的初始状态是如何发生改变的。随着模式的成功执行，模式启动前所获得的软件工程信息和项目信息是如何变换的。
结果：描述模式成功执行之后的结果。模式完成时需要明确：
必须完成哪些开发组件或是开发团队相关的活动。过程的结束状态是什么。产生了哪些软件工程信息和项目信息。
相关模式：以层次化或其他图的方式列举与该模式相关的其他过程模式。
已知应用和实例：说明该模式可应用的具体实例。

过程模型

惯用的过程模型

惯用的过程模型力求达到软件开发的结构和秩序，其活动和任务都是按照过程的特定指引顺序进行的。

瀑布模型

线性工作流方式通常发生在需要对一个已经存在的系统进行明确定义的适应性调整或是增强的时候，也可能发生在很少数新的开发工作上。但需求必须是准确定义和相对稳定的。
瀑布模型又称为经典生命周期，提出了一个系统的，顺序的软件开发方法。
为项目提供了按阶段划分的检查点。当前一阶段完成后，只需要去关注后续阶段。可在迭代模型中应用瀑布模型。它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

缺点：各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
瀑布模型的一个变体称为V模型。描述了质量保证动作同沟通，建模相关动作以及早期构建相关的动作之间的关系。随着软件团队工作沿着V模型左侧步骤向下推进，基本问题需求逐步细化，形成了对问题及解决方案的详尽且技术性的描述。一旦编码结束，团队沿着V模型右侧的步骤向上推进工作，其本质上是执行了一系列测试（质量保证动作），这些测试验证了左侧的推进过程。
瀑布模型和V模型没有本质区别，V模型提供了一种将验证和确认动作应用于早期软件工程工作中的直观方法。
瀑布模型的问题
实际的模型很少遵循瀑布模型提出的顺序。虽然线性模型可以加入迭代，但他是用间接的方式实现的，结果是，随着项目组工作的推进，变更可能造成混乱。

难以适应很多项目在开始阶段必然存在的不确定性。在需求已经确定的情况下，瀑布模型是高效的。

客户只有在项目接近尾声时，才能得到可执行程序。对于系统中存在的重大缺陷，若在评审之前没有发现，可能造成惨重的损失。

由于任务之间的依赖性，并发团队的一些成员要等待另外一些成员工作的完成。

增量过程的模型

初始的软件需求有明确的定义，但整个开发过程却不宜单纯运用线性模型。可能需要为用户迅速提供一套功能有限的软件产品，然后在后续版本中进行细化和扩展。
综合了线性过程流和并行过程流的特征。随着时间的推移，增量模型在每个阶段都运用线性序列。每个系线性序列生产出软件的可交付增量。

第一个增量往往是核心产品，满足了基本的需求客户对其进行仔细的评估，然后制定下一个增量计划。每一个增量都会重复这个过程，直到最终产品的产生。将待开发的软件系统模块化，可以分批次的提交软件产品，使用户可以及时了解软件项目的进展。以组件为单位进行开发降低了软件开发的风险，一个开发周期内的错误不会影响到整个软件系统。开发顺序灵活，先完成需要稳定的核心组件，当组件的优先级发生变化时，还能及时的对实现顺序进行调整在软件开发过程中需求变化是不可避免的，增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速开发模型，但也很容易退化为边做边改模型，使软件过程的控制失去整体性。

演化过程模型

需求经常发生变化使得最终产品难以实现，严格的交付时间使开发团队不可能圆满完成综合性的软件产品，但必须交付有限的版本。虽然能够很好的理解核心产品和系统需求，但产品或系统扩展的细节没有定义。
是迭代的过程模型，使开发人员能够开发出更完整的软件版本。
构件产品需要的周期数目不确定。演化过程没有确定演化的最快速度。侧重灵活性和可延展性，而不是高质量。
原型开发。客户定义了软件的基本功能但是没有定义功能和特性的需求或开发人员对算法的效率，操作系统的适用性和人机交互的形式等情况没有把握。可以采用原型开发泛型。

原型可以作为一个独立的过程模型，更多时候是作为一种技术，可以在任何一个过程模型中应用。当需求模糊时，可以帮助开发人员和利益相关者更好地理解要做什么。始于沟通，定义软件的整体目标，明确已知的需求。在终端用户看得到的方面。产生一个原型，对原型进行部署，然后又利益相关者进行评估。根据反馈信息进一步精炼需求，在调整的过程冲采用迭代技术，同时使开发者逐步清除用户的需求。

在理想状况下，原型系统提供定义软件需求的机制。当需要构建可执行的原型系统时，开发人员可以利用已有的程序片段或应用工具快速产生可执行的程序。

原型可以作为第一个系统。通过它，客户对实际的系统有了更直观的认识，开发者也迅速建立了一些东西。

缺点：快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。利益相关者可能会不愿意重建以提高软件质量。软件工程师为了快速建立原型，可能会采用低效的算法，使得不完美的选择成为系统的组成部分。使用这个模型的前提是要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。不适合大型项目的研发。
螺旋模型：演进式软件过程模型。结合了原型的迭代性质和瀑布模型的可控性和系统特点。具有快速开发越来越完善的软件的能力。
风险驱动型过程模型生成器，对于软件集中的系统，他可以指导多个利益相关者的协同工作。
采用循环方式逐步加深系统定义和实现的深度，同时降低风险。
确定一系列的里程碑作为支撑点，确保利益相关者认可且令各方面满意的系统解决方案。
螺旋模型将软件开发为一系列演进版本。在早期的迭代中，软件可能是一个理论模型或原型，在后来的迭代中，产生一系列逐渐完整的系统版本。
螺旋模型被分割成一系列由软件工程团队定义的框架活动。每个框架活动代表螺旋上的一个片段。随着演进过程的开始，从圆心开始顺时针方向，执行螺旋上的一圈所代表的活动。在每次演进时，都要考虑系统风险。每个演进过程还要标记里程碑（沿螺旋路径到达的工作产品和条件的结合体）。
第一圈开发出产品的规格说明，接下来是原型系统，并在每次迭代中逐步完善。螺旋的每圈都会跨过策划区域，需要调整项目计划，并根据反馈调整预算，进度和迭代次数。
螺旋模型应用在计算机软件的整个生命周期。第一圈表示概念开发项，经过多个迭代，直到概念开发的结束。若被开发为实际产品，那么该过程继续向外伸展，称为新产品开发项目。新产品通过迭代不断演进，最后用一圈螺旋表示产品提高项目。螺旋模型将永远保持可操作性，直到软件产品的生命周期结束。过程经常会处于休止状态，每当有变更时，总能在合适的入口点启动。
适合于开发大型系统和软件。软件随着过程推进而变化，在每一个演进层次上，可以更好的理解和应对风险。螺旋模型把原型作为降低风险的机制，在产品演进的任何阶段均可使用原型方法。
保留了瀑布模型中系统逐渐细化的方法，把它纳入迭代框架之中。
要求在项目的所有阶段始终考虑技术风险，若适当的应用该方法，能够在风险变为难题之前将它化解。

并发模型

又叫做并发工程，允许软件团队描述任何过程模型中的迭代元素和并发元素。
并发模型定义了一系列事件，这些事件将触发软件工程活动，动作或者任务的状态转换。
可以用于所有类型的软件开发，能供提供精确地项目当前状态图。所有软件过程活动同时存在并处于不同的状态。不是把软件工程活动，动作和任务局限在一个事件的序列，而是定义了一个过程网络。网络上的而每个活动，动作和任务与其他活动，动作和任务同时存在。过程网络中某一点产生的事件可以触发与每一个活动相关的状态的转换。
适合于不同软件工程团队共同开发的产品工程项目。

演化过程的最终评述

演化侧重于灵活性和可扩展性，而不是高质量。
构建产品需要的周期数不确定，项目计划困难。
可以尽早的投入市场。

专用过程模型

应用面较窄且单一，只适用于某些特定的软件工程方法。

基于构件的开发

商业现货软件构件由厂家作为产品供应，通过良好定义的接口提供特定的功能，这些构件能够集成到正在构建的软件中。
基于构件的开发模型本质上是演化模型，需要以迭代的方式构建软件。不同之处在于基于构件的开发模型采用预先打包的软件构件来开发应用系统。
建模和构建活动开始于识别可选构件。
步骤
对于该问题的应用领域研究和评估可用的基于构件的产品。考虑构件的继承问题。设计软件架构以容纳这些构件。将构建集成到架构中。测试以保证功能正常。
能够减少开发周期并减少项目开发费用。

形式化方法模型

主要活动是生成计算机软件形式化的数学规格说明。使软件开发人员可以应用严格的数学符号来说明，开发和验证基于计算机的系统。
该方法的变形为净室软件工程。
使用形式化方法时，歧义性问题，不完整问题，不一致问题等更容易被发现和纠正（应用数学分析的方法）。形式化方法是程序验证的基础。
可以通过无缺陷的文件，耗时，成本高。需要大量培训。难以与客户沟通。

面向方面的软件开发

随着计算机系统的发展，某些关注点（客户需要的属性，技术兴趣点）已经体现在整个系统架构中。有些关注点是系统的高层属性，有些关注点影响了系统功能，有些关注点是系统性的。
若某个关注点设计系统多方面的功能，特性和信息，这些关注点通常称为横切关注点。
方面的需求定义那些对整个软件体系结构产生影响的横切关注点。
面向方面的软件开发（面向方面编程，面向方面构建工程）为定义，说明，设计和构建方面提供过程和方法，是对横切关注点进行局部表示的一种机制，超越了程序和继承方法。
方面是独立于局部的软件构件开发的，并且对构建的开发有直接影响，因此，在构建方面和构件的过程活动之间建立异步通信是非常重要的。

统一过程

用例驱动，以架构为核心，迭代并且增量。
尝试从传统的软件过程中挖掘最好的特征和性质，以敏捷软件开发中许多最好的原则来实现。强调软件体系结构的重要作用，帮助架构师专注于正确的目标。建立了迭代的，增量的过程流，提供了演进的特性。

统一过程的简史

UML统一建模语言，包含了大量用于面向对象系统建模和开发的符号。

统一过程UP的阶段

在这里插入图片描述

起始阶段：通过与利益相关者协作定义软件的业务需求，提出系统大致的架构，并制定开发计划以保证项目开发具有迭代和增量的特性。识别基本的业务需求，并初步用例描述每一类用户所需要的主要特性和功能。此时的体系结构仅是主要子系统及其功能，特性的试探性概括。体系结构随后被细化和扩充为一组模型，以描述系统的不同视图。策划阶段识别各种资源，评估主要风险，制定进度计划，并为其在软件增量开发的各个阶段中的应用建立基础。
细化阶段：
构建阶段：
转换阶段：
生产阶段：
五个UP阶段并不是顺序执行，而是阶段性的并发进行。软件工程的工作流分布在所有UP阶段。在U中，工作流类似于任务集。即工作流识别了完成一个重要的软件工程活动的必要任务，以及在成功完成任务之后所产生的工作产品。
并不是工作流中所识别的每一个任务都在所有的项目中应用。

产品和过程

如果过程很薄弱,则最终产品必将受到影响。但是对分过程的过分依赖也是很危险的。

把产品和过程分裂开来而不是作为辩证统一的一体注定要失败。如果仅仅将软件看作一个过程或是一个产品，那就永远都不能正确地理解软件,包括其背景、应用、意义和价值。对于一个可复用的部件,如果仅仅从产品或是仅仅从过程的角度考虑, 都不利于软件开发,这种片面的观点或者影响了人们对产品的应用环境和应用方法的认识, 或者忽略了该产品还可以作为其他开发活动的输入这一事实。
片面地强调某一方面的观点会极大地降低软件复用的可能性,也会大大减少工作的成就感。一个具有创造性的专业软件人员也应该从过程中获得满足,其程度不亚于最终的产品。产品和过程的二象性已经成为保留推动软件工程不断进步的创造性人才的一个重要因素。

敏捷开发

个人与他们之间的交流胜过了开发过程和工具，可运行的软件胜过了宽泛的文档，客户合作胜过了合同谈判，对变更的良好响应胜过遵循计划。
敏捷方法是为了克服传统软件工程中认识和实践的弱点而形成的，并不完全对立与传统软件工程实践，也不能用于所有软件工作。
敏捷方法不意味着不创建任何文件而是只在开发过程后期创建文件。
需要敏捷响应不断变化，无法确定的商业环境。能够通过软件过程来降低由变更所引起的代价。
要想过程模型可用，必须提供实际可行的机制来维持必要的纪律，宽容可能导致效率低下。

什么是敏捷

敏捷团队是能够适当响应变更的灵活团队，软件是由团队中所有人共同开发完成的，这些人的技能和合作能力是项目成功的关键。变更就是软件开发本身。普遍存在的变更是敏捷的基本动力。
敏捷鼓励能够使沟通更便利的团队结构和协作态度，强调可运行软件的快速交付而不那么看重中间产品，将客户作为开发团队的一部分开展工作，其项目计划是可以灵活调整的。
敏捷可以应用于任何软件。过程的设计应该使项目团队适应于任务，并且使任务流水线化，在了解敏捷开发方法的流动性的前提下进行计划的制定，保留最重要的工作产品并使其保持简洁，根据具体的产品类型和运行环境，尽可能快的将可工作的软件交付给客户。

敏捷及变更成本

软件开发的传统方法中，变更的成本随计划的进展成非线性增长。
一个良好的敏捷过程拉平了变更曲线，使软件开发团队在没有超常规的时间和费用影响的作用下，在软件项目后期能够适应各种变更。（因为产品以增量的方式发布，在增量内部，变更能够得到较好的控制）

什么是敏捷过程

敏捷开发过程必须增量的适应：敏捷团队需要客户的反馈，可执行原型或部分实现的可运行系统是客户反馈的最有效媒介，因此，应当使用增量式开发策略，必须在很短的时间间隔内交付软件增量来适应变更。这种迭代方式允许客户周期性的评价软件增量，向软件项目组提出必要的反馈，影响为了适应反馈而对过程进行的适应性修改。

敏捷原则

尽早，持续的交付有价值的软件。
欢迎需求变更。
经常交付可运行软件，交付的时间间隔越短越好。
业务人员和开发人员的紧密合作。
面对面交谈。
可运行软件是进度的首要度量标准。
可持续的开发速度。
优秀的技能和好的设计。
简单。
好的架构，需求和设计。
调整团队自己。

极限编程XP

敏捷软件开发过程中最广泛使用的方法。

极限编程过程

使用面向对象的方法作为开发的范型
策划活动：是一个需求收集活动，要使XP团队技术人员了解要求的输出，主要特性和主要功能。倾听产生一系列的故事，描述将要开发的软件所需要的输出，特性即功能。每个故事由客户书写并置于一张索引卡上，由客户标明故事的权值。XP开发团队针对每一个故事给出以开发周期数为度量单位的成本，若成本超过三个开发周期，则请客户将故事进一步细分。新故事可以在任何时刻书写。

客户和XP团队共同决定如何将故事分组，并置于下一个发行版本中。一旦认可对下一个版本的承诺，就以下列方式对待开发的故事进行排序：所有选定故事尽快实现。最高价值的故事首先实现。高风险故事首先实现。

项目的第一个版本交付之后，XP团队计算项目的速度。速度将用于：帮助估计后续版本的发布日期和进度安排。判断是否有过分承诺。若存在，则调整。

在开发过程中，客户可以增加故事，改变故事的权值，分解或去掉故事。由XP团队重新修改计划。
设计：
编码：
测试：