1软件工程概述
一、软件的定义
计算机系统种的程序及其文档。
程序：计算机任务的处理对象和处理规则的描述。
文档：为了便于理解程序所需要的阐明性资料。
●软件是无形的、不可见的逻辑实体
●软件是设计开发的，而不是生产制造的
●软件在使用过程中没有磨损、老化的问题
●软件是定制开发的
●软件是复杂的
●软件的开发成本高
●软件易于复制
二、软件的分类
软件一般分为系统软件、支撑软件和应用软件三类。
支撑软件：支撑软件的开发、维护和运行的软件。
三、软件开发的含义
软件开发：实现问题域中的概念和处理逻辑到运行平台的概念和处理逻辑的映射。
软件开发的本质：
不同抽象层次术语之间的“映射”
不同抽象层处理逻辑之间的“映射”
建模是解决问题的一般途径！
四、软件工程的目标
软件工程可定义为三元组：
（1）给出了软件所涉及软件工程的工程要素
（2）给出了各要素之间的关系
（3）给出了软件工程学科所研究的主要内容
1、目标
生产具有正确性、可用性以及开销合宜的产品。
真确性：软件产品达到预期功能
可用性：软件基本结构、实现及文档为用户可用
开销合宜：软件开发、运行的整个开销满足用户要求
2、活动
——生产一个最终满足需求且达到工程目标的软件产品所需要的步骤。
——主要包括需求、设计、实现、确认和支持等活动。
需求：定义问题，即建立系统模型
需求获取、需求定义、需求规约、需求验证
设计：在需求分析的基础上，给出系统的软件设计方案。
总体设计和详细设计
五、重新定义软件
重新定义软件：软件是客观世界中问题空间与解空间的具体描述。
软件=程序+文档
六、软件过程
1、基本概念
软件生存周期：软件产品或系统的一系列活动的全周期。从形成概念开始，历经开发、交付使用、在使用中不断修订和烟花，直到最后被淘汰。
软件生存周期过程（软件过程）：软件生存周期中的一系列相关过程。
软件过程（Process）：活动的一个集合。
活动（Activity）：任务的一个集合。
任务（Task）:将输入转换为输出的操作。
2、过程分类
（1）基本过程（Primary Process）：是指那些与软件生产直接相关的活动集。
（2）支持过程（Supporting Process）：是指有关各方按其目标所从事的一系列支持活动集。
（3）组织过程（Institutional process）：是指那些与软件生产组织有关的活动集。
七、软件生存周期模型
（1）瀑布模型
·软件生存周期各项活动规定为依固定顺序而连接的若干阶段工作
·规定了每一阶段的输入，以及本阶段的工作成果，作为输出传入下一阶段
（2）增量模型：该模型有一个假设，即需求可以分段，成为一系列增量产品，每一增量可以分别地开发。
关于增量模型的几点说明:
A）增量模型的优点
作为瀑布模型的第一个变体，具有瀑布模型的所有优点。此外，它还有以下优点:
①第一个可交付版本所需要的成本和时间是很少的
②开发由增量表示的小系统所承担的风险是不大的
③由于很快发布了第一个版本，因此可以减少用户需求的变更
④允许增量投资，即在项目开始时，可以仅对一个或两个增量投资。
B）缺点
如果增量模型不适于某些项目，或使用有误，则有以下缺点:
①如果没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增彙的不稳定
②如果需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布;
③管理发生的成本、进度和配置的复杂性，可能会超出一些组织的能力。
（3）演化模型
是一种有弹性的过程模式，由一些小的开发步组成，每一步历经需求分析、设计、实现和验证，产生软件产品的一个增量。通过这些送代，完成最终软件产品的开发
（4）喷泉模型
特征：迭代、无缝
2需求
1、需求与需求获取
一个需求是一个有关“要予构造”的陈述，描述了待开发产品/系统功能上的能力、性能或者其他性质。
2、什么样的陈述可以作为需求
——需求的基本性质
①必要的。是要求的吗p>
②无歧义的。只能用一种方式解释吗p>
③可测的。可以对它进行测试吗p>
④可跟踪的。可以从一个开发阶段到另一个阶段对它进行跟踪吗p>
⑤可测量的。可以对它进行测量吗p>
3、需求的分类
①功能需求
规约了系统或系统构件必须执行的功能。
②性能需求
规约了一个系统或系统构件必须具有的性能特性。
③外部接口需求
规约了系统或系统构件必须与之交互的硬件、软件或数据库元素。
④设计约束
⑤质量属性
4、需求发现
①自悟
②交谈
③观察
④小组会
⑤提炼
5、需求规约
一个需求规约是一个软件项/产品/系统所有需求陈述的正式文档，是一个软件产品/系统的概念模型。
1、需求规约的基本性质：
①重要性和稳定性程度
②可修改的
③完整的
④一致的
2、需求规约格式
3、需求规约的作用具作用可概括为：
第一，是最重要的，作为软件开发组织和用户之间一份事实上的技术合同书;是产品功能及其环境的体现。
第二，对于项目的其余大多数工作，它是一个管理控制点。
第三，对于产品的设计，它是一个正式的、受控的起始点。
第四，是创建产品验收测试计划和用户指南的基础，即基于常求规约一般还会产生另外两个文档——初始测试计划和用户系统操作描述。
3 结构化分析方法 4结构化设计
1、什么是软件设计的启发规则些启发规则p>
1.改进软件结构提高模块独立性
2.模块规模应该适中
3.深度、宽度、扇出和扇入
扇入：有多少个上级模块直接调用它（不违背独立性条件下，扇入越大越好）
扇出：一个模块直接调用的下级模块数
4.模块的作用域在控制域内
作用域：一个模块所影响的所有模块
控制域：一个模块直接或间接控制的模块
5.力争降低模块接口的复杂程度
6.设计单入口单出口模块
7.模块功能应该可以预测
2、借鉴启发规则，理解将初始软件结构图（MSD）进一步精化的方法
变换型/事务性——确定输入/输出边界（孤立变换中心）——第一级分解（分配控制）——DFD中的每个处理映射成软件结构中一个适当的模块
3、知道接口设计的分类，理解人机交互界面设计的相关问题，用户界面应该具体的特性，界面设计应该遵循的原则
接口分类：①模块和软件构件之间 ②软件和其他软硬件系统之间 ③软件与用户之间
系统接口设计（包括用户界面设计与其他系统的接口设计）由穿过系统边界的数据流定义的。
用户界面的特性：可用性——灵活性——可靠性（苏老师ppt）
界面设计原则：一致性，操作步骤少，不要哑播放（有提示音），提供undo功能（反馈，“很多人，我做了，我就做了”），减少人脑记忆负担——提高学习效率
详细设计工具
1.伪码 类程序设计语言PDL，Program Design Language（作为注释，直接插在源程序中间）
2.程序流程图 直观，但缺乏全局观,不能逐步求精 描述模块内部的处理结构，但无数据结构
3.PAD图(problem analysis diagram，问题分析图) 逐步求精 PAD图是一种描述程序逻辑结构的工具
4.N-S图，盒图 逐步求精
5.判定表和判定树表 解决多重嵌套的条件选择
软件设计规约
3.1什么是软件设计规约 满足系统规约所指定的全部功能及性能要求
3.2软件规约的组成 概要设计规约和详细设计规约
概要设计规约：
（1）系统环境
（2）设计描述
（3）对每个模块的描述
（4）文件结构和全局数据
面向软件开发者的文档，主要作为软件项目管理人员、系统分析和设计人员之间交流的媒体
概要设计规约对应于系统的确认测试
详细设计规约：
（1）各过程的处理算法
（2）算法所涉及的全部数据结构的描述
详细设计规约主要作为软件设计人员与编程人员之间交流的媒体
详细设计规约对应于系统的单元测试
详细设计的任务：
定义每个模块的算法和数据格式
3.3设计规约格式
结构化方法总结
结构化方法的基本原则：
1）自顶向下功能分解
2）数据抽象
3）过程/功能抽象
4）模块化
结构化方法的抽象层：
1）需求分析层
2）设计层
3）实现层
结构化方法逐渐被面向对象方法所取代，存在问题：
1）分析阶段和设计阶段的术语空间不一致
2）解的结构没有保持原系统的结构
3）捕获的“过程”和“数据”都是易变的
软件设计评审
正式评审、非正式评审
概要设计评审，从需求到设计数据和体系结构的变换
详细设计评审，详细设计走查，注重算法的正确性
5UML
5.1面向对象方法
1引言
面向对象方法是一种以对象、对象关系等来构造软件系统模型的系统化方法。
面向对象方法的世界观：一切系统都是由对象构成的，它们相互作用、相互影响，构成了大千世界的各式各样系统。
UML，统一建模语言
●面向对象不仅仅是一种程序开发方法
使用面向对象程序设计语言
使用对象、类、继承、封装、消息等基本概念进行编程
●面向对象是一种软件方法学
如何看待软件系统与现实世界的关系
以什么观点进行求解
如何进行系统构造
面向对象方法学习什么b>
基本知识
●清晰、准确、熟练地掌握面向对象方法的主要思想、基本概念与原则
面向对象分析（OOA）
面向对象设计（OOD）
●了解OOA和OOD的主要概念与操作过程，会应用。
面向对象程序设计（OOP）
●了解OOP的基本思想，学会用C++语言实现面向对象的分析与设计方法建立的系统模型。
5.2UML概述
UML是一种可视化语言，用于：
（1）规约系统的制品——UML适用于对所有重要的分析、设计和实现决策进行详细描述。
（2）构造系统的制品——UML描述的模型可于各种编程语言直接相关联。
表达操作的完整语法格式为：
[可见性]操作名[(参数表)][:返回类型][｛性质串｝]
其中：
①可见性 如同属性的可见性一样，其值可以为：
+公有的 可供其它类访问之
#受保护的 其子类能访问之
-私有的 只有本类的操作才能访问之
~包内的 只有在同一包中声名的类才能访问之。
②操作名
?操作名一般是一动词或动词短语，通常以小写字母开头，左对齐
?如果操作名是动词短语，除第一个词外，其余每个词的第一个字母为大写，例如 isempty0
?若操作是一个抽象操作，则以斜体字表示之。
5.3接口
——体现功能抽象
（1）定义：
接口（interface）是一组操作的集合，其中每个操作描述了类或构件的一个服务。
（2）接口的基本作用：模型化系统中的“接缝”，即
①通过声明一个接口，表明一个类、构件、子系统提供了所需要的、且与实现无关的行为；
②表明一个类、构件、子系统所要得到的、且与实现无关的行为。
（3）接口的表示
①可以使用带有分栏和关键字>的矩形符 来表示接口。
④依赖
定义：依赖是一种使用关系，用于描述一个事物（如类Window）使用另一事物（如Event）的信息和服务。
5.12静态模型表达工具——类图
一、UML为不同抽象层提供了6种可对系统静态部分建模的图形工具
①类图
类图显示了类(及其接口)、类的内部结构以及与其他类的联系。是面向对象分析与设计所得到的最重要的模型。
②构件图
在转入实现阶段之前，可以用它表示如何组织构件。构件图描述了构件及构件之间的依赖关系。
③组合结构图
组合结构图展示了类或协作的内部结构
④对象图
展示了一组对象以及它们之间的关系。用对象图说明在类图中所发现的事物的实例的数据结构和静态快照。
⑤部署图
部署图展示运行时进行处理的结点和在结点上生存的制品的配置。部署图用来对系统的静态部署视图建模
⑥制品图
展示了一组制品以及其间依赖关系。利用制品图可以对系统的静态实现视图建模。
①类图：类图显示了类（及其接口）、类的内部结构以及与其他类的联系，是面向对象分析和设计所得到的最重要的模型。
作用：可视化的表达系统的静态结构模型。
二、UML为不同抽象层提供了7种可对系统动态部分建模的图形工具。
①用况图：需求模型
用况图是表现一组Use cases、Actors以及它们之间的关系的图。
用例图和数据流图b>
用例图是参与者（Actor）、用例（Use cases）以及它们之间关系的图，用以表达系统的各种形态。用例图的主要包含六个抽象，即主题（Subject）、用例（Use cases）、参与者（Actor）、依赖、关联、泛化。
用例图属于面向对象的分析方法的产物，主要是对系统内信息和操作的抽象分类，先将事物分类后，再考虑它们的功能和属性。已经这些类之间的相互关系。用例图更加面向于问题解决的方式和目的。
数据流图属于结构化的分析方法的产物，是将系统的功能模块化，然后自顶向下、逐步求精式的完善系统中各个模块的具体功能。各模块之间的关系在接口设计时才全盘考虑，而用例图是在系统建模时考虑各个类之间关系。
什么是用例建模b>
用例建模的策略：
①通过标志参与者，建立系统语境。
②考虑参与者对系统行为的需求，并把这些需求作为用况。
③提取用况的公共行为，形成泛化结构；分解异常行为，放入新的用况。
④各种关系模型化。
⑤通过注解、约束给出用况的非功能需求。
用例建模和数据流图的关联b>
用例建模和数据流图的关联，数据流图中我们需要根据各部分操作的相近程度，对系统进行模块划分。用例图中需要分解用况，提取公共行为，形成泛化结构。在原理上，这方面式相互关联的。
②状态图：当对象的行为比较复杂时可用状态图作为辅助模型描述对象的状态及其状态转移，从而更准确地定义对象的操作。
③活动图：注重从活动到活动的控制流，可用来描述对象的操作流程，也可以描述一组对象之间的协作行为或用户的业务流程
④顺序图：注重于消息的时间次序。可用来表示一组对象之间的交互情况
⑤通信图：注重于收发消息的对象的组织结构。可用来表示一组对象之间的交互情况。
⑥交互概观图：用于描述系统的宏观行为，是活动图和顺序图的混合物
⑦定时图：用于表示交互，它展现了消息跨越不同对象成角色的实际时间，而不仅仅关心消息的相对顺序
5.13UML总结
①对“自顶向下”的建模人员来讲：
——提供了跨越问题空间到目前“运行平台”之间丰富的建模元素。基于给定的术语，可确定不同抽象层次，支持“概念模型”和“软件建模”。
顺序图所包含的内容：
①交互各方：角色或对象
②交互方式：同步或异步
③交互内容：消息
5.15系统行为（生命周期）的建模工具-状态图
定义：状态图是显示一个状态机的图，其中强调了从一个状态到另一个状态的控制流。
状态分类：初态、终态和正常态。
6面向对象分析
6.1识别类、属性和操作
1、研究问题域和用户的需求
（1）研究用户需求、明确系统责任
阅读、交流、调查、记录和整理
（2）研究问题域
亲临现场调查，掌握第一手的资料
听取问题域专家的见解
阅读与问题域有关的材料
借鉴相同或类似问题域已有的系统开发经验及文档
（3）确定系统边界
2、策略与启发
（1）考虑问题域
人员
组织
物品
设备
抽象事物
事件
文件
结构
（2）考略系统边界
人员
设备
外系统
（3）审查与筛选
6.2识别属性
(1)策略与启发
按常识这个对象应该有哪些属性如人的姓名、职业、地址等)
*在当前的问题域中，对象应该有哪些属性如商品的条形码
*根据系统责任，这个对象应具有哪些属性卡人的使用地点)
*建立这个对象是为了保存和管理哪些信息p>
*对象为了实现操作的功能，需要增设哪些属性p>
*对象是否需要一个专设的属性描述其状态p>
*用什么属性表示聚合和关联p>
6.3识别操作
区别对象行为的类型
（1）系统行为
例：创建、删除、复制、转存
（2）对象自身的行为——算法简单的操作
例：读、写属性
（3）对象自身的行为——算法复杂的操作计算或监控
6.4识别对象之间的关系
1、识别继承（泛化）关系的策略
（1）学习当前领域的分类学知识
（2）按常识考虑事务的分类
（3）使用继承的定义
使用两种思路去发现继承关系:
(a)一种思路是把每个类看作是一个对象集合，分析这些集合之间的包含关系，如果一个类是另一个类的子集(例如“职员”是“人员＂的子集，“轿车”是“汽车＂的子集)，则它们应组织到同一个一般-特殊关系中。
(b)看一个类是不是具有另一个类的全部特征，这又包括以下两种情况
?一种是建立这些类时己经计划让某个类继承另一个类的全部属性与操作，现在应建立继承关系来落实
?另一种是起初只是孤立地建立每个类，现在发现一个类中定义的属性与操作全部在另一个类中重新出现，此时应考虑建立继承关系，把后者作为前者的特殊类，以简化其定义。
（4）考察属性与操作的适用范围
对系统中的每个类，从以下两个方面考略它们的属性与操作
?看一个类的属性与操作是否适合这个类的全部对象。
?检查是否有两个（或更多）的类包含有一些共同的属性与操作。
6.5识别关联
一、识别关联策略
（1）识别对象之间的静态联系
（2）识别关联的属性与操作
（3）分析并表示关联的多重性
（4）进一步分析关联的性质
二、命名与定位命名
关联可用动词或动宾结构
6.6识别聚合
1、识别聚合的策略
(1)物理上的整体事物和它的组成部分
例:机器、设备和它的零部件
(2)组织机构和的下级组织及部门
例:公司与子公司、部门
(3)团体(组织)与成员
例:公司与职员
(4)一种事物在空间上包容其它事物
例:生产车间与机器
(5)抽象事物的整体与部分
例:学科与分支学科、法律与法律条款
(6)具体事物和它的某个抽象方面
例:人员与身份、履历
(7)在材料上的组成关系
例如，面包由面粉、糖和酵母组成，汽车是由钢、塑料和玻璃组成。
2、审查与筛选
(1)是否属于问题域p>
例:公司职员与家庭
(2)是不是系统责任的需要p>
例:公司与工会
(3)部分对象是否有一个以上的属性p>
例:汽车与轮胎(规格)
(4)是否有明显的整体部分关系p>
例:学生与课程
6.7识别依赖
依赖是一种使用关系，用于描述一个事务（如Window）使用另一个事物（如类Event）的信息和服务。
6.8面向对象分析（Object-Oriented Analysis，OOA）
1、OOA的基本任务
运用面向对象方法，对问题域(被开发系统的应用领域)和系统责任(所开发系统应具备的职能)进行分析和理解，对其中的事物和它们之间的关系产生正确的认识，找出描述问题域和系统责任所需的类和对象，定义这些类和对象的属性和操作，以及它们之间所形成的各种关系。最终目的是产生一个符合用户需求，并能够直接反映问题域和系统责任的OOA模型及其规约。
2、OOA模型
对象层：给出所有问题域和系统责任有关的对象，用类表示
特征层：定义每个类的属性和操作
关系层：描述对象之间的关系
3、OOA过程
3.类别
纯面向对象语言
例如: Smalltalk、 Eiffel
较全面地支持O0概念
强调严格的封装
混合型面向对象语言
例如:C++、 Objective-c、 Object Pascal
在一种非OO语育基础上护充00成分
对封装采取灵活策略
结合人工智能的面向对象语言
例如: Flavors、 LOOPS、Clos
4、语言+类库+编程环境
三、为实现00模型选择编程语言
在OOD完成之后，选择什么编程语言实现OOD模型p>
1、一般原则
*基本原则——语言的选择完全从实际出发
主要考虑成本、进度、效率等实际因素
*OOPL是实现OOD的理想语言
它使源程序能很好的对应OOD模型
*带有类库、编程环境、权限管理的OOPL更好。
*用非OO语言也能实现OOD模型缺乏O0机制的保证和支持，
但若自觉遵循一定的原则，可以保持某些OO风格。
2、编程语言的评价标准
(1)能否描述类和对象
是否提供封装机制装有无可见性控制p>
(2)能否实现一般-特殊结构
支持多继承、单继承还是不支持继承p>
支持多继承时，是否能解决命名冲突p>
是否支持多态p>
(3)如何实现整体-部分结构
用什么实现表示多重性p>
(4)如何实现属性和操作
用什么表示属性p>
用什么描述操作p>
有无可见性控制p>
能否描述约束p>
是否支持动态绑定（Dynamic Binding）p>
(5)如何实现关联和消息通讯
用什么实现关联表示多重性实现消息通讯p>
(6)其它可考虑的因素(反映于具体的语言版本)
是否带有可视化编程环境是否带有类库
能否支持对象的永久存储
注释:
绑定:一个对象(或事物)与其某种属性建立某种联系的过程。如:一个变量与其类型或值建立联系，一个进程与一个处理器建立联系等。——《计算机科学技术百科全书(第二版)》
在计算机语言中有两种主要的绑定方式：
静态绑定发生于数据结构和数据结构间，程序执行之前。静态绑定发生于编译期，因此不能利用任何运行期的信息。它针对函数调用与函数的主体，或变量与内存中的区块。
动态绑定则针对运行期产生的访问请求，只用到运行期的可用信息。在面向对象的代码中，动态绑定意味着决定哪个方法被调用或哪个属性被访问，将基于这个类本身而不基于访问范围。
四、几种典型的面向对象的编程语言的简介
1、C++
①是C语言的超集
②是一种混合型的OOPL，保持C语言的高效率、可移植，与C兼容使广大程序员容易接受
③采用强类机制
④支持动态绑定
⑤是目前使用最广的OOPL
（1）类和对象
类Class 对象Object
对象的创建和删除：
创建：构造函数——类名（），（C++规定，每个类必须有默认的构造函数，没有构造函数就不能创建对象）
删除：析构函数——~类名（），（析构函数的定义：析构函数也是特殊的类成员函数，它没有返回类型，没有参数，不能随意调用，没有重载，只有在类对象的生命期结束的时候，由系统自动调用。）
静态对象（从程序开始执行到退出）
创建：类名 对象名
删除：程序退出时
动态对象（显示地创建和删除）
创建：对象指针 = new类名（参数）
删除：delete 对象指针
（2）一般一特殊结构
基类-派生类(Base- derived class)
支持单继承和多继承
用命名空间( namespace)解决命名冲突
支持多态和重载
在继承的同时可定义被继承内容的可见性
（3）整体-部分结构(聚合)
用指针或嵌套对象( nested object)实现聚合，用指针数组或指针链表等实现多重性。
2、Java
Java不使用指针，解释执行
Java对分布式和客户/服务器结构的支持，提供了丰富的类库和方便有效的开发环境，并提供了语言级的多线程、同步原语和并发控制机制。
(1)类和对象
定义类的关键字:Class
封装机制:有
对象的创建和删除构造函数:类名()
终止函数: finalize()
对象的静态声明和动态创建类似于C++
(2)属性和操作
属性:实例变量、类变量
可见性: private、 protected、 public和 friendly
操作:实例方法、类方法
可见性:同属性
(3)继承
超类/子类支持重载和多态
(4)关联、聚合
可用对象引用实现关联或聚合
五、用非OO编程语言事先OOD模型
1过程语言一一以C为例
(1)类，对象→无可以用结构定义对象，可通过指针说明应该有哪些函数(不封装)
(2)一般-特殊→无
可把一般结构嵌入特殊结构
(3)整体一部分→指针、嵌套的结构
(4)属性与操作→变量、函数
(5)关联→指针;消息→函数调用
9敏捷开发方法
敏捷开发概述
一、概念
敏捷软件开发，又称敏捷开发，是一种应对快速变化的需求的一种软件开发能力。
敏捷软件工程是 推崇“让客户满意和软件的早期增量发布，小而高度自主的项目团队，非正式的方法，最小化软件工程产品以及整体精简开发”的哲学理念和一系列开发指南的综合。
二、敏捷（Agile）联盟
一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则。
敏捷联盟宣言：
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
三、敏捷原则
———这是敏捷实践区别于重过程的特征所在
1)最优先要做的是：通过尽早地、持续地交付有价值的软件来使客户满意。——获取有质量软件的理念
2)即使到了开发后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。——关于态度的声明
3)经常交付可工作的软件，其时间间隔可以是几周到几个月。交付的时间间隔越短越好。——项目规划的理念（涉及如何处理文档和软件项目开发之间的关系）
4)在整个项目开发期间，业务人员和开发人员必须天天在一起工作。——团队组成和精神问题
5）不断激励开发人员，开展项目的有关工作。给他们提供所需要的环境和支持，并信任他们能够完成所承担的工作。——“领导”的含义-涉及管理功能
6)在团队内部，最有效果的、最有效率的传递信息的方法，就是面对面的交谈。——获取开发信息(需求、技术信息和项目信息等)的途径
7)首要的进度度量标准是工作的软件。——进度度量的理念
8)敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。——项目“持续发展”的能力
9)不断关注优秀的技能和设计，增强敏捷能力。——提高敏捷能力的一种途径
10)简单是根本的。——使未完成的工作最小化的艺术
11)最好的体系结构、需求和设计，出自自己组织的团队。——团队观念————一种软件项目管理的理念。
12)每隔一段时间，团队对如何才能有效的工作进行反省，然后对自己的行为进行适当的调整。自我调整和适应。
注:以上12条是敏捷开发的实践原则。实践的语义比过程更宽泛，包扩活动以及与活动相关的人和基础设施。
四、极限编程
极限编程（eXtreme Programming，简称XP），是敏捷方法中最显著的一个。它由一系列简单却相互依赖的实践组成。
1、极限编程包含的实践
（1）客户作为团队的成员
含义：客户与开发人员一起紧密的工作，相互了解所面临的问题，并共同解决之。
（2）“用户素材”（user stories）
含义：为了了解与项目需求有关的内容，采用“用户素材”（user stories）——需求谈话时的助记工具。
（3）短的交付周期
含义：每隔两周，就交付一次可工作的软件。
（4）验收测试
作用：通过验收测试，捕获用户素材的有关细节。
编写时间：要在实现该用户素材之前或实现该用户素材期间进行编写。
编写工具：编写验收测试，使用能够让它们自动、反复运行的某种脚本语言。
（5）结对编程
含义：共同设计、共同编写、功劳均等，以促进知识在全队的传播。
（6）测试驱动的开发
含义：首先对产品的某一功能编写一个单元测试。由于该功能还不存在，因此它一定会运行失败。然后编写这一功能的代码，使该测试得以通过。
益处:为了测试用例通过而编写代码，这样的代码称为可测试的代码。优点是:由于要独立对它进行测试，因此可激励解除模块之间的耦合，使模块之间具有低的耦合
（7）集体所有权
（8）持续集成
2、极限编程过程
CASE是一组工具和方法的集合。是辅助软件开发的任何计算机技术，其含义为：
在软件开发/维护中，提供计算机辅助支持
在软件开发/维护中，引入工程化的方法
2、CASE工具
狭义地说，是一类特殊的软件工具，用于辅助开发分析、测试、维护另一种计算机程序/文档
广义地说，是除了OS之外的所有软件工具的总称。
相关资源：…dummy:虚拟RPM,用于哑的oracle-instantclient软件包-其它代码…
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！