1. RMMM
2. 统一过程
3. 依赖倒置
4. 重构

1. 说说你对顺序图和状态图的使用的看法？
2. 面向对象测试，就是两个类继承自一个类，基类已经经过充分的测试，问两个子类要怎么测试？
3. 主观材料题，第一问是从社会、法律、环境、安全等等方面分析项目的可行性，第二问是问你要做这个软件你打算采用什么团队结构，比如随机式组织、开放式组织、封闭式组织。
4. 公司发现用户的需求不明确，所以在开始时故意报低价，在后面需求变更时再报高价，你觉得道德吗？

1. 给一个商品表，问你要实现上面的话，类图要怎么设计。第二问，现在打算做618促销活动，要怎么修改上一题的类图，使它以后添加其他促销活动（比如双十二促销活动）时比较合理，然后新设计的类图满足哪些面向对象的原则。
2. 挣值分析
3. 给一段程序，画程序流图（注意不是程序结构图），写出独立路径，再写测试用例
4. 给一段描述，画出用例图，画类图，再写第0层数据流图和第1层数据流图

软件工程知识点总结——第零部分

软件过程定义：
  为创建高质量软件所需要完成的活动、动作和任务的框架。

软件过程与软件工程的区别：
  软件过程定义了软件工程化中采用的方法，但软件工程还包含该过程中应用的技术——技术方法和自动化工具。软件工程是由有创造力、有知识的人完成的，他们根据产品构建的需要和市场需求来选取成熟的软件过程。

过程流类型：
线性过程流——从沟通到部署顺序执行五个框架活动

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

演化过程流——采用循环的方式执行各个活动，每次循环都能产生更为完善的软件版本

并行过程流——将一个或者多个活动与其他活动并行执行

过程模式的定义：
  过程模式描述了软件工程工作中遇到的过程相关的问题，明确了问题环境并给出了针对该问题的一种或者几种可证明的解决方案。

Ambler过程模式模板：
模式名称：应清楚地表达该模式在软件过程中的含义，比如，技术评审。
驱动力(目的)：模式使用环境及主要问题，以明确主要难点。
类型：步骤模式（定义框架活动）、任务模式 (定义软件工程动作或任务）、阶段模式（定义框架活动序列）{ ps：阶段模式是有序列的步骤模式的集合，步骤模式包括若干个任务模式 }
启动条件：模式应用前需满足的前提条件(输入) 。需要明确：
  （1）在此之前，整个开发组织或者开发团队内已有哪些活动？
  （2）已有哪些软件工程信息或是项目信息？
  （3）过程的进入状态是什么？
问题：描述模式将要解决的具体问题。
解决办法：描述如何成功实现模式。
结束条件：描述模式成功执行之后的结果(输出)。模式结束时需要明确：
  （1）必须完成哪些开发组织或是开发团队相关的活动？
  （2）过程的结束状态是什么？
  （3）产生了哪些软件工程信息或是项目信息？
相关模式：列举与该模式直接相关的其它过程模式。
已知应用实例：说明该模式可应用的具体实例。(什么场合使用)
具体示例：
回归测试过程模式
模式名称：回归测试 (指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误)。
目的：构造一种测试的过程。
类型：任务模式。
启动条件：在模式启动之前必须满足以下三个条件：（1）原来的测试用例；（2）更新后的软件；（3）针对更新部分的新测试用例。
问题：要测试模块。
解决方法：先用原来的测试用例测试软件，再用新测试用例测试软件。
结束条件：完成测试的软件。
相关模式：测试、单元测试、系统测试。
已知应用实例：更新软件后建议使用

惯用过程模型的概念
目标：使软件开发更加有序。
  所有的软件过程模型都支持通用框架活动，但是每一个模型都对框架活动有不同的侧重。也称软件生存周期模型

瀑布模型
定义：
  将软件生存周期的各项活动规定为依固定顺序连接（瀑布般）的若干阶段工作：即从用户需求规格说明开始，顺序地通过沟通、策划、建模、构建和部署过程，最终提供完整的软件和持续的技术支持。又称为经典生命周期。
前提：
  需求必须是 准确定义 和 相对稳定的。
特点：
  各个阶段间具有顺序性和依赖性；
  推迟实现的观点：前面步骤完成后才考虑实现；
  质量保证的观点：每一阶段都需要有文档以及经过评审；
问题：
  瀑布模型需要明确的客户需求，但客户难以准确表达所有需求。
  得到可执行程序的时间太迟，滞后的缺陷导致陷入困境。
  可能导致一些阻塞，浪费过多等待时间。
  过于理想化，难以应对开发过程中的各种不确定因素。
变体：
  V模型——瀑布模型与V模型没有本质区别，V模型提供了一种将验证确认动作应用于早期软件工程工作中的方法。

增量模型

定义：
  增量模型综合了线性过程流和并行过程流的特征：随着时间的推移，增量模型在每个阶段运用线性序列；每个线性序列以一种演化过程流的方式生产出软件的可交付增量。以迭代方式运用瀑布模式。
前提：
  需求不明确或迫切需要为用户迅速提供一套功能有限的软件产品，然后在后续版本中再进行细化和扩展功能。
特点：
  运用增量模型时，第一个增量往往是核心产品（core product），能够满足基本的需求，但是许多附加的特性（一些是已知的，一些是未知的）没有提供。客户通过使用该核心产品进行详细评价，并根据评价结果制定下一个增量计划。这份增量计划说明了需要对核心产品进行的修改，以便更好地满足客户的要求，也说明了需要增加的特性和功能。
问题：
  把用户需求转化为功能递增的不同版本可能比较难 (很多时候各个功能联系紧密，难以完全分开)
  难以确定所有版本共需的公用模块。(通常在进行设计时会先考虑设计公用模块，但是每一个增量只考虑局部的设计，因此，全局的公用模块很难确定)
变体：
  迭代式开发——迭代式开发是增量式开发的一种变体，不同于传统的增量开发（每次提交一个构件），迭代式开发开始提交所有的模块（部分模块有待优化），在其后的阶段逐渐优化。

  专用过程模型具有传统过程模型的一些特点，但是专用过程模型往往应用面较窄而专一，只适用某些特定的软件工程方法。

构件开发模型
概念：
  本质上是演化模型，具有多螺旋模型的特点，利用迭代方式构件软件；与演化模型不同，基于构件开发模型采用预先打包的软件构件开发应用系统；
内容：
  建模和构建活动开始于识别可选构件。这些构件有些设计成通用的软件模块，有些设计成面向对象的类或软件包。不考虑构件的开发技术，基于构件开发模型由以下步骤组成（采用演化方法）：
  1. 对于该问题领域研究和评估可用的基于构件的产品。
  2. 考虑构件集成的问题。
  3. 设计软件架构以容纳这些构件。
  4. 将构件集成到架构中。
  5. 进行充分的测试以保证功能正常。
优点：
  能够使软件复用，减少项目开发费用，缩短开发周期

形式化方法模型
概念：
  形式化方法模型的主要活动是生成计算机软件形式化的数学规格说明，使得软件开发人员可以应用严格的数学符号来说明、开发和验证系统。
优点：
  应用数学分析的方法，歧义性问题、不完整问题、不一致问题等都能够更容易地发现和改正。在设计阶段，形式化方法是程序验证的基础，使软件开发人员能够发现和改正一些往往被忽略的问题。
缺点：
  开发非常耗时，成本也很高；
  只有极少数程序员具有应用形式化的背景，需要大量的培训；
  对于技术水平不高的客户，很难用这种模型进行沟通。
应用：
  高度关注安全性的软件（飞行器、医疗设施、经济领域）

  由Booch、Jacobson及Rumbaugh提出，注重于客户沟通以及从用户的角度描述系统，强调软件体系结构的重要性。
   统一过程认识到与客户沟通以及从用户的角度描述系统并保持该描述的一致性的重要性。
特点：
  用例驱动，以架构为核心，迭代并且增量。

  UML包含了大量用于面向对象系统建模和开发的符号。到了1997年，UML已经变成了面向对象软件开发的实际标准。
  UML提供了支持面向对象软件工程实践必要的技术，但它没有提供指导项目团队使用该技术时的过程框架。接下来的几年中，Jacobson，Rumbaugh和Booch建立了统一过程模型，这是用UML进行面向对象软件工程的框架。目前，统一过程和UML广泛应用在各种各样的面向对象项目中。

  统一过程（UP，Unified Process）有5个阶段，分别是起始阶段、细化阶段、构建阶段、转换阶段和生产阶段。有可能在构建、转换和生产阶段的同时，下一个软件增量的工作已经开始。这就意味着五个UP阶段并不是顺序进行，而是阶段性地并发进行。

1.起始阶段（inception phase）
  包括客户沟通和策划活动。通过与利益相关者协作定义软件的业务需求，提出系统大致的架构，并制定开发计划以保证项目开发具有迭代和增量的特性。
  该阶段识别基本的业务需求，并初步用用例描述每一类用户所需要的主要特征和功能。此时的体系架构仅是主要子系统及其功能、特性的试探性概括。
  随后，体系结构将被细化和扩充成为一组模型，以描述系统的不同视图。策划识别各种资源，评估主要风险，制定进度计划，并为其在软件增量开发的各个阶段中的应用建立基础。

2.细化阶段（elaboration phase）
  包括沟通和通用过程模型的建模活动。细化阶段扩展了初始阶段定义的用例，并扩展了体系结构用以包括软件的五种视图——用例模型、需求模型、设计模型、实现模型和部署模型。
  在某些情况下，细化阶段建立了一个“可执行的体系结构基线”，这是建立可执行系统的“第一步”。
  体系结构基线证明了体系结构的可实现性，但没有提供系统使用所需的所有功能和特性。
  另外，在细化的最终阶段将评审项目计划以确保项目的范围、风险和交付日期的合理性。该阶段对项目计划进行修订。

3.构建阶段（construction phase）
  与通用软件过程中的构建活动相同。构建阶段采用体系结构模型作为输入，开发或是获取软件构件，使得最终用户能够操作用例。
  为达到上述目的，要对需求模型和设计模型加以完善，以反映出软件增量的最终版本。软件增量（例如发布的版本）所必须要求的特性和功能在源代码中实现。
  随着构件的实现，对每一个构件设计并实施单元测试。另外，还实施了其他集成活动（构件组装和集成测试）。
  用例被用来导出一组验收测试，以便在下个UP阶段开始前执行

4.转换阶段（transition phase）
  包括通用构建活动的后期阶段以及通用部署（交付和反馈）活动的第一部分。
  软件被提交给最终用户进行Beta测试，用户反馈报告缺陷及必要的变更。
  另外，软件开发团队创建系统发布所必要的支持信息（如用户手册、问题解决指南及安装步骤）。
  在转换阶段结束时，软件增量成为可用的发布版本。

5.生产阶段（production phase）
  与通用过程的部署活动一致。
  在该阶段，监控软件的持续使用，提供运行环境（基础设施）的支持，提交并评估缺陷报告和变更请求。

  如果过程很薄弱，则最终产品必将受到影响。但是对过程的过分依赖也是很危险的。所以产品（创造力、个性）和过程（按部就班，标准，流程）的二象性已经成为保留推动软件工程不断进步的创造性人才的一个重要因素。

1.请描述三个适用于瀑布模型的软件项目。
答：
  图书馆管理系统、学生信息管理系统、销售系统。（ps：大部分只要需求明确且需求相对稳定的软件系统都可以使用瀑布模型）

2.请描述三个适用于原型模型的软件项目。
答：
  一个位于火车站的交互式火车车次查询系统、Android可视化编程软件、图像编辑软件。（ps：人机交互和/或复杂计算机图形软件应用程序一般适用于原型模型开发）

3.如果将原型变成一个可发布的系统或者产品，应该如何调整过程？
答：
  将原型变成一个可发布的系统或产品，软件工程师和客户需要满足和定义软件的总体目标，识别已知的任何要求，对整体轮廓进一步的强制定义。

4.请描述三个适用于增量模型的软件项目。
答：
  文字处理软件、五子棋游戏、IT技术交流社区。（ps：大部分软件都可以满足增量模型，尤其是游戏）

5.可以合用几种过程模型吗？如果可以，请举例说明。
答：
  过程模型可以合用，比如开发图像编辑软件，可以先采用原型开发，设计出大体的软件界面，后面在采用增量模型，一步一步添加相关功能。

6.开发质量”足够好“的软件，其优点和缺点是什么？也就是说 当我们追求开发速度胜过产品质量的时候，会产生什么后果？
答：
  开发质量“足够好”的软件可能会碰到死亡线（截止时间），但质量会是比较好的。当追求开发速度超过了产品的质量，这可能会导致许多缺陷，该软件可能需要更多的测试，设计和实施工作。需求定义的不是很清楚，可能需要不断地改变。甚至可能导致无法检测到重大的项目风险，造成不必要的事故。

7.请描述三个适用于基于构件模型的软件项目。
答：
  外卖APP、银行管理系统、微博。（ps：大部分功能可以划分为模块的软件都可以用基于构件的开发模式，尤其是包含实名认证和定位的软件）

8.我们可以证明一个软件构件甚至整个程序的正确性，可是为什么并不是每个人都这样做？
答：
  这是可能的用数学技术来证明软件组件，甚至整个程序的正确性。然而，对于复杂的程序，这是一个非常耗时的过程。

9.统一过程和UML是同一概念吗？解释你的答案。
答：
  不是，统一过程是软件工程开发的一种软件过程，而UML是一种建模语言，是一种表示方法。

敏捷开发的定义：
  它是一种软件开发方法论，可以应对客户快速变更的需求。它强调以人为核心，采用迭代的方式，循序渐进地开发软件。

  软件开发的传统方法中（有几十年的开发经验作支持），变更的成本费用随着计划的进展成非线性增长。
  敏捷的拥护者认为，一个设计良好的敏捷过程“拉平”了变更成本曲线，使软件开发团队在没有超常规的时间和费用影响的情况下，在软件项目后期能够适应各种变化。
  敏捷过程包括增量交付。当增量交付与其他敏捷实践耦合时，例如连续单元测试及结对编程，引起变更的费用会衰减。
  虽然关于拉平曲线的程度的讨论仍然在进行，但是证据表明，敏捷变更费用显著降低。

敏捷过程的定义：
  基于敏捷原则进行的软件开发过程，视为敏捷过程。所谓“基于”，是指充分考虑，而不是全部包含。

敏捷过程的三大假设

1. 提前预测需求或变化很难，预测优先级也存在困难；
2. 理论上讲，是先有设计，后有构建。但实际上这两步是交替反复的，因为设计者是人，不是神；
3. 从客观角度和软件开发的经验来讲，软件开发的几大要素（分析、设计、构建和测试）都要不断的调整、变化，而这正是敏捷的内涵。

敏捷原则

1. 我们最优先要做的是通过尽早、持续地交付有价值的软件来使客户满意。
2. 即使在开发的后期，也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。
3. 经常交付可运行软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
4. 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5. 围绕有积极性的个人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
6. 在团队内部，最富有效果和效率的信息传递方法是面对面交谈。
7. 可运行软件是进度的首要度量标准。
8. 敏捷过程提倡可持续的开发速度。责任人（sponsor）、开发者和用户应该能够保持一个长期的、恒定的开发速度 。
9. 不断地关注优秀的技能和好的设计会增强敏捷能力。
10. 简单是必要的。
11. 最好的架构、需求和设计出自于自组织团队。
12. 每隔一定时间，团队会反省如何才能更有效地工作，并相应调整自己的行为。

★并不是每一个敏捷模型都同等使用这12项原则，一些模型可以选择忽略（或至少淡化）一个或多个原则的重要性。

  使用的最为广泛的敏捷过程。
三个特点：

1. 是一些相互关联的准则和惯例的集合；
2. 追求变更曲线平坦化；
3. 适合于小团队、高风险的项目

极限编程过程
  XP使用面向对象方法作为推荐的开发范型，它包含了策划、设计、编码和测试4个框架活动的规则和实践。

策划：
  建立一系列描述待开发软件必要特征与功能的“故事” (故事：由客户谈论系统应该完成什么功能，然后用通俗的自然语言，使用自己的语汇，将其写在卡片上)；
  评估每一个故事，并给出以开发周数为度量单位的成本；
  客户和XP团队共同决定如何对故事分组，并置于将要开发的下一个发行版本中（下一个软件增量）；
  形成关于一个发布版本的基本承诺；
  对有待开发的故事进行排序：（1）所有选定故事 (下一个增量)将在几周之内尽快实现；（2）具有最高权值的故事将移到进度表的前面并首先实现；（3）高风险故事将首先实现。
  在第一个版本发布之后，XP团队计算项目的速度。项目速度由第一个发行版本中实现的客户故事个数来决定。
  项目速度将用于： (1) 帮助估计后续发行版本的发布日期和进度安排；(2) 确定是否对整个开发项目中的所有故事有过分承诺。一旦发生过分承诺，则调整软件发行版本的内容或者改变最终交付日期。
  在开发过程中，客户可以增加故事，改变故事的权值，分解或者去掉故事。然后由XP团队重新考虑并修改计划。

设计：
  严格遵循KIS (Keep It Simple)原则，即使用简单而不是复杂的表述。不鼓励额外功能性（因开发者假定以后会用到）设计。
  鼓励使用CRC卡（类-责任-协作者）确定与当前软件增量相关的面向对象的类。
  在某个故事设计中遇到困难时，立即建立这部分设计的可执行原型，实现并评估设计原型 (Spike解决方案：让不明确的评估成为明确的评估)，其目的是在真正的实现开始时降低风险，对可能存在设计问题的故事确认其最初的估计。
  鼓励“重构”。【重构：是以不改变代码外部行为而改进其内部结构的方式来修改软件系统的过程。实质上，重构就是在编码完成之后改进代码设计 (设计优化，代码优化)。重构所需工作量随着应用软件规模的增长而急剧增长。】

编码：
  XP推荐在故事开发和初步设计完成之后，团队不是直接开始编码，而是开发一系列用于检测本次（软件增量）发布的包括所有故事的单元测试。一旦编码完成，就可以立即完成单元测试，从而向开发者提供即时的反馈。(先开发测试用例，然后再编码)
  结对编程。XP建议两个人面对同一台计算机共同为一个故事开发代码。这一方案提供了实时解决问题 (两个人总比一个人强)和实时质量保证的机制 (在代码写出后及时得到复审)，同时也使得开发者能集中精力于手头的问题。
  实施中不同成员担任的角色略有不同，例如，一名成员考虑设计特定部分的编码细节；而另一名成员确保编码遵循的标准。
  当结对的两人完成其工作，他们所开发的代码将与其他人的工作集成起来。有些情况下，团队(专人)进行集成。还有一些情况下，结对者自己负责集成，这种“连续集成”策略有助于避免兼容性和接口问题。

测试：
  建立的单元测试应当使用一个可以自动实施的框架（因此易于执行并可重复），这种方式支持代码修改之后即时的回归测试策略。
  将个人单元测试组织到一个“通用测试集”，与传统方式不同，每天都可以进行系统的集成和确认测试，可以为XP团队提供连续的进展指示，也可在一旦发生问题的时候及早提出预警。 “每几个小时修改一些小问题，比仅在最后截止期之前修正大问题要节省时间。”
  XP验收测试，也称为客户测试 (由客户主导)，由客户规定技术条件，并且着眼于客户可见的、可评审的系统级的特征和功能。验收测试根据本次软件发布中所实现的用户故事而确定。

工业极限编程
  工业极限编程（IXP）是XP的一种有机进化。IXP合并了六个新实践：1. 准备评估；2. 项目社区；3. 项目特许；4. 测试驱动管理；5. 回顾；6. 持续学习；

准备评估
  在IXP项目开始执行前，组织机构应进行准备评估(readiness assessment)。评估应确定是否：

1. 存在支持IXP的适合的开发环境；
2. 开发团队由合适的利益相关者组成；
3. 组织机构具有清晰的质量大纲并且支持连续的改进；
4. 组织文化会支持一个敏捷团队；
5. 组成较为广泛的项目社区 (大项目，人多)

项目社区
  经典XP建议选择适合的人员组成敏捷团队可以确保成功。就是说团队成员必须经过良好的训练，具有良好的适应性和技能，以及适宜的性格为自组织团队做出贡献。
  当在一个大型组织内将IXP应用于重要的项目，团队的概念就变成社区。一个社区可能拥有一个技术专家，处于项目成功核心地位的客户们，以及其他利益相关者（例如，法律人员、质量检验员、生产或销售人员），“他们通常位于IXP计划的周边，但在项目中他们扮演着重要的角色”。
  在IXP内，应明确定义社区成员和他们的角色，应建立社区成员之间交流和合作机制。

项目特许
  通过对项目本身进行评估来确定：(1) 对于项目的合适的商业调整是否存在；(2) 是否可以进一步深化组织机构的全部目标。

测试驱动管理
  需要可测量的标准来评估项目的状态和迄今为止的进展情况。

回顾
  IXP团队在一个软件增量交付之后要实施特定的技术评审。这种评审称为回顾，在软件增量过程中与全部软件的发布过程中复查“问题、事件以及教训”。这样做的目的是为了改善IXP过程。

持续学习
  由于学习是持续过程改进中至关重要的组成部分，因此，鼓励XP团队的成员去学习新的方法和技术来提高软件产品质量。

1.需求易变
  因为客户是XP团队的成员，对需求的改变不是正式地提出。结果是，项目的范围会发生变化，早期的工作或许要进行修改来适应当前的要求。

2.矛盾的客户需求
  许多项目都有众多客户，每个客户都有自己的一套需求。在XP中，团队自身需要吸纳不同客户的要求，这项工作可能超出了自己的职权范围。

3.需求的非正规表示
  批评者指出需要更正规的模型或规格说明来保证遗漏、不一致以及错误在系统建立前就被发现。
  拥护者则认为，需求的变化特性在其发展时使这些模型和规格说明变得过时。

4.正规设计的缺乏
  XP削弱了对体系结构的设计的要求，在许多案例建议所有类型的设计都不必那么正规。
  批评者主张当开发复杂的系统时，必须强调设计以保证软件的体系结构能够展示其质量和可维护性。
  拥护者指出XP过程的增量特性限制了复杂性（简单性是其核心价值），因此降低了扩展设计的必要性 (设计简单点，不考虑扩展性，用增量的方式来改进设计)。

Scrum
  Scrum得名于橄榄球比赛。
  Scrum原则与敏捷宣言是一致的，应用Scrum原则指导过程中的开发活动，过程由“需求、分析、设计、演化和交付”等框架性活动组成。
  每一个框架活动中，发生于一个过程模式中的工作任务称为一个冲刺（sprint）。冲刺中进行的工作（每一个框架活动中的冲刺的数目根据产品复杂度和规模大小而有所不同）适应于当前的问题，由Scrum团队规定并常常作实时修改。
  每一个过程模式定义一系列开发活动：

• 待定项(backlog)：
    能为用户提供商业价值的项目需求或特征的优先级列表。待定项中可以随时加入新项(即变更的引入)。产品经理根据需要评估待定项并修改优先级。
• 冲刺(sprint) (待定项的一部分，眼前具体的任务) 。
    由一些工作单元组成 ，并且必须能在预定的时间段 (time-box)内(一般情况下为30天)完成。冲刺过程中不允许有变更(例如，积压工作项)。因此，冲刺给开发团队成员的工作提供了短期但稳定的环境。
• Scrum例会。
    Scrum团队每天召开的短会（一般情况为15分钟），会上所有成员要回答三个问题：1.上次例会后做了什么？2.遇到了什么困难？3.下次例会前计划做些什么？
    团队领导（也称为Scrum主持人）主持会议并评价每个团队成员的表现。Scrum会议帮助团队尽早发现潜在的问题。同时，每日例会进一步促进自我组织团队的建设。

动态系统开发
  动态系统开发方法（Dynamic System Development Method，DSDM）提供一种框架，使其“通过在可控项目环境中使用增量原型开发模式来满足对时间有约束系统的构建和维护”。
  如果交付整个应用系统需用100%时间，那么80%的应用系统可以用20%的时间交付。
特点：
  每一个迭代都遵循80%原则，即每个增量只完成能够保证顺利进入下一增量的工作，剩余的细节则可以在知道更多业务需求或者提出并同意变更之后完成。
DSDM生命周期活动：

• 可行性研究
    建立要开发应用系统的业务需求和相关约束，并评估该应用系统采用DSDM过程是否可行。
• 业务研究
    建立能为应用系统提供业务价值所需要的功能和信息需求；同时，确定基本的应用系统架构并识别软件的可维护性需求。
• 功能模型迭代
    为客户开发一系列证明其功能的增量原型 (注意：所有DSDM原型都倾向于逐渐发展成可交付的应用系统 )。迭代的意图是在用户使用原型系统时诱导出反馈信息以获取其他的需求。
• 设计和构建迭代
    重新构建原型以确保每一个原型都以工程化方式实现，并能为最终用户提供可操作的业务价值。
• 实现
    将最终软件增量（一个可操作的原型）置于操作环境中。应当注意：（1）增量不见得100%完成；（2）增量置于操作环境以后可能需要改变。

敏捷建模
敏捷建模的原则：

• 有目的的模型
    在构建模型之前，开发者心中应当有明确的目标（如与客户沟通信息有助于更好地理解软件的某些方面），一旦确定模型的目标，该用哪种类型的表达方式以及所需要的具体细节程度都是显而易见的。
• 使用多个模型
    描述软件可以使用多种不同的模型和表示法，大多数项目只用到其中很小的部分就够了。AM建议从需要的角度看，每一种模型应当表达系统的不同侧面，并且应使用能够为那些预期的读者提供有价值的模型。
• 轻装上阵
    随着软件工程工作的进展，只保留那些能提供长期价值的模型，抛弃其余的模型。
    所以每次决定保留一个模型，都要在使用信息的便利性与敏捷性方面做权衡（即团队内部、团队与利益相关者增强沟通）。
• 内容重于表述形式
    一个有用的内容很少，但语法完美的模型不如一个有缺陷但能向读者提供有用内容的模型更有价值。
• 理解模型及工具
    理解每一个模型及其构建工具的优缺点。
• 适应本地需要
    建模方法应该适应敏捷团队的需要。

敏捷统一过程（AUP）
  采用了一个“全局串行”以及“局部迭代”的原理来构建基于计算机的系统。
  采用经典UP阶跃性活动—开始、加工、构建以及变迁。
  提供一系列覆盖（例如，软件工程活动的一个线性序列），能够使团队为软件项目构想出一个全面的过程流。
  在每一个活动里，一个团队迭代使用敏捷，并且将有意义的软件增量尽可能快地交付给最终用户。
每个AUP迭代执行以下活动：

• 建模
    UML建立了对商业和问题域的表述。然而，为了保持敏捷，应保证这些模型“足够好” 。
• 实现
    将模型翻译成源代码。
• 测试
    设计和执行一系列的测试来发现错误以保证源代码满足需求。
• 部署
    重点是对软件增量的交付以及获取最终用户的反馈信息。
• 配置及项目管理
    配置管理着眼于变更管理、风险管理以及对开发团队的任一常效产品的控制。项目管理追踪和控制开发团队的活动情况和工作进展。
• 环境管理
    协调过程基础设施，包括标准、工具以及适用于开发团队的支持技术。

1.用自己的话描述（用于软件项目的）敏捷性。
答：
  敏捷不仅仅是有效地响应变更，它鼓励能够使沟通更便利地团队结构和协作态度。它强调可运行软件地快速交付，它认为项目计划是可以灵活调整地。

2.为什么迭代过程更容易管理变更？只用一次迭代就能完成项目的敏捷过程是否存在？解释你的答案。
答：
  敏捷过程模型提供软件增量，然后是客户反馈和修订。因为增量很小，客户反馈很及时，所以在下一个软件增量中合并更改相对容易。
  存在，例如，敏捷软件开发（ASD）使用一个迭代过程，该过程包括适应性周期规划、相对严格的需求收集方法，以及一个迭代开发周期，该周期包括以客户为中心的小组和正式的技术评审，作为实时反馈机制。

3.为什么需求变更这么大？人们终究无法确定他们想要什么吗？
答：
  需求变化如此之大，以至于很难提前预测哪些软件需求将持续存在，哪些将发生变化。随着项目的进行，同样难以预测客户的优先级将如何变化。
  人们通常很难描述他们的软件需求，直到他们看到一个工作的原型意识到他们忘记了考虑一些重要的事情。

5.什么是XP的spike解决方案？
答：
  在某个故事设计中遇到困难时，立即建立这部分设计的可执行原型，实现并评估设计原型。其目的是在真正的实施开始时降低风险，并验证包含设计问题的故事的原始估计。

6.用自己的话描述XP的重构和结对编程的概念。
答：
  重构是不改变代码外部行为而改进其内部结构的方式来修改软件系统的过程。
  结对编程两个人面对同一台计算机共同为一个故事开发代码。

一个卓有成效的软件工程师要具备：

1. 责任感。这会让软件工程师去努力实现对同伴、其他利益相关者和管理者的承诺。为获得成功的结果，他会在需要的时候不遗余力地做他需要做的事情。
2. 对一些人的需求有敏锐的意识，这些人包括同团队的成员、利益相关者、掌控整个项目并能找到解决方法的管理者。他会观察人们工作的环境，并根据环境和人本身来调整自己的行为。
3. 坦诚。如果发现了有缺陷的设计，他会用诚实且有建设性的方式指出错误。
4. 展现抗压能力。前面我们提到，软件工程工作经常处在混乱的边缘。压力（以及由此产生的混乱）来自很多方面——需求和优先级的变更、要求苛刻的利益相关者或同伴、不切实际或者令人难以忍受的管理者。但一个卓有成效的软件工程师可以在不影响业绩的情况下很好地处理这些压力。
5. 有高度的公平感。他会乐于与同事分享荣誉，努力避免利益冲突并且绝不破坏他人劳动成果。
6. 注重细节。这并不意味着追求完美，而是说他会利用产品和项目已有的概括性标准（如性能、成本、质量），在日常工作基础上仔细思考，进而做出技术性决策。
7. 务实。他知道软件工程不是要恪守教条的宗教信仰，而是可根据当下情景需要进行调整的科学规则。

凝聚力：
  一个有凝聚力的团队是一组团结紧密的人，他们的整体力量大于个体力量的总和。
  同一般的团队相比，有凝聚力的团队成员具有更高的生产率和更大的动力。他们拥有统一的目标和共同的文化，而且在很多情况下，“精英意识”使得他们独一无二。

团队毒性
  应该避免“团队毒性”，5个培育潜在含毒团队的环境：

1. 狂乱的工作氛围。解决方法：项目经理应该确保团队可以获取完成工作所需的所有信息；而且，主要目标一旦确定下来，除非绝对必要，否则不应该修改。
2. 重大挫折使得团队成员产生摩擦。解决方法：给予软件团队尽可能多的决策权，增强团队信心。
3. 糟糕的软件过程 (碎片式的或协调很差)：解决方法：允许团队选择过程模型。
4. 成员角色模糊：导致责任不明，互相指责。解决方法：团队应该建立责任机制，并规定一系列当团队成员未能完成任务时的纠正方法。
5. 反复地失败：导致丧失自信，士气低下。解决方法：建立基于团队的信息反馈方法和解决问题的技术。

  团队结构取决于组织的管理风格、团队里的人员数目与技能水平，以及问题的总体难易程度。
规划软件工程团队结构应该考虑的7个项目因素：

1. 待解决问题的难度；
2. 开发程序的规模，以代码行或者功能点来度量；
3. 团队成员需要共同工作的时间 (团队生存期)；
4. 能够对问题做模块化划分的程度；
5. 待开发系统的质量要求和可靠性要求；
6. 交付日期的严格程度；
7. 项目所需要的友好交流的程度。

软件工程团队的四种组织模式：

什么是敏捷团队？

• 小型的充满活力的项目团队；
• 如果项目成员足够优秀，那么他们几乎可以采用任何一种过程来完成任务；如果项目成员不够优秀，那么没有任何一种过程可以弥补这个不足。“人员胜过过程”；
• 然而，如果缺乏用户和主管人员的支持，也可以毁掉一个项目，即“政策胜过人员”。缺乏支持可以阻止最好的人员完成任务；
• 成员相互信任，成员各有所长，优势互补；
• 为了保证凝聚力，将自行其事者清除出团队；
• 团队是“自组织的”：不必保持单一的团队结构，给予敏捷团队很大的自主权 (制定计划、手段选择)。

小组沟通的有效性：

• 小组规模：随着规模的扩大，要保证所有成员间的有效交流变得困难；
• 小组结构：没有正规组织结构的组织 (没有领导)，沟通比较有效；
• 小组构成：同类型的人易冲突；
• 小组的物理工作环境：工作场所是推动或阻滞沟通的主要因素。