特点： 瀑布模型+原型+风向分析 迭代过程 螺旋上的第一圈可能表示“概念开发项目” 最后，可以用一圈螺旋表示“产品提高项目” 流程： 确定目标，选择方案，选定完成目标的策略 风险角度分析该策略 启动一个开发阶段 评价前一步的结果，计划下一轮的工作

1.基于构件的开发 优点：能够使软件复用，减少项目开发费用，缩短开发周期 建模和构建活动开始于识别可选构件。这些构件有些设计成通用的软件模块，有些设计成面向对象的类或软件包。 步骤：   1.对于该问题领域研究和评估可用的基于构件的产品   2.考虑构件集成的问题   3.设计软件架构以容纳这些构件   4.将构件集成到架构中   5.进行充分的测试以保证功能正常

2.形式化方法模型 主要活动是生成计算机软件形式化的数学规格说明，使得软件开发人员可以应用严格的数学符号来说明、开发、和验证系统

3.面向方面的软件开发 方面的需求定义那些对整个软件体系结构产生影响的横切关注点。 横切关注点：某个关注点涉及系统多个方面的功能、特性和信息。

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

UML——统一建模语言 统一过程

1. 起始阶段 包括客户沟通和策划活动 定义软件的业务需求，提出系统大致的架构，制定开发计划
2. 细化阶段 包括沟通和通用过程模型的建模活动 扩展了体系结构
3. 构建阶段 与通用软件过程中的构建活动相同。 采用体系结构模型作为输入，开发或是获取软件构件，使得最终用户能够操作用例
4. 转换阶段 包括通用构件活动的后期阶段以及通用部署（交付和反馈）活动的第一部分
5. 生成阶段 与通用过程的部署活动一致 监控软件的持续使用，提供运行环境（基础设施）的支持，提交并评估缺陷报告和变更请求

产品（创造力、个性）和过程（按部就班，标准，流程）

在软件工程实践中，以下过程模型比较流行： 瀑布模型、原型模型、快速应用开发模型、增量模型、螺旋模型、形式化方法模型、敏捷过程模型、构件组装模型、并发开发模型等等

惯用过程模型存在的主要缺陷 敏捷

• 敏捷宣言：
  • 个体与交互 胜过 过程与工具
  • 可用的软件 胜过 完备的文档
  • 客户协作 胜过 合同谈判
  • 响应变化 胜过 遵循计划
• 敏捷价值观：
  • 沟通 简单 反馈 勇气 尊重（谦逊）
• 什么是敏捷开发： 它是一种软件开发方法论，可以应对客户快速变更的需求。它强调以人为核心，采用迭代的方式，循序渐进地开发软件

传统软件开发的变更：

• 变革的成本费用随着计划的进展成非线性增长（这种方法在软件开发团队收集需求时，即在项目的早期，相对容易适应变更）

敏捷的变更：

• 一个设计良好的敏捷过程“拉平”了变更成本曲线，使软件开发团队在没有超常规的时间和费用影响的情况下，在软件项目后期能够适应各种变化
• 敏捷过程包括增量交付。

基于敏捷原则进行的软件开发过程，视为敏捷过程

所谓“基于”，是指充分考虑，而不是全部包含

敏捷原则

敏捷过程的三大假设

1. 提前预测哪些需求是稳定的以及哪些需求会变更是非常困难的。同样，预测项目进行中客户优先级的变更也很困难。
2. 对很多软件来说，设计和构建是交错进行的。也就是两种活动应当顺序开展以保证通过构建实施来验证设计模型，而在通过构建验证之前很难估计应该设计到什么程度
3. 分析、设计、构建和测试并不像我们所设想的那么容易预测（从制定计划的角度来看）

敏捷过程必须具有可适应性，但是原地踏步式的连续适应性变更收效甚微，因而敏捷软件过程必须增量地适应。 换言之，有自适应和增量提高的过程即是敏捷过程

敏捷团队成员及团队本身必须具备以下一些特点：

• 基本能力
• 共同目标
• 精诚合作
• 决策能力
• 模糊问题解决能力
• 相互信任和尊重
• 自组织（组织团队、组织过程、组织进度）

极限编程Extreme Programming——使用的最为广泛的敏捷过程 三个特点：

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

极限编程过程 （1）策划 建立“故事” 评估“故事” 故事分组 形成基本承诺 对故事进行排序

故事：由客户谈论系统应该完成什么功能，然后用通俗的自然语言，使用自己的语汇，将其写在卡片上

（2）设计 严格遵循KIS（Keep It Simple）原则 鼓励使用CRC卡（类-责任-协作者）确定与当前软件增量相关的面向对象的类 建立可执行原型并评估 鼓励“重构”

KIS原则：即使用简单而不是复杂的表述。不鼓励额外功能性（因开发者假定以后会用到）设计。

（3）编码 先开发测试用例，然后再编码 结对编程（建议） 工作集成

（4）测试 单元测试应当使用一个可以自动实施的框架（因此易于执行并可重复），这种方法支持代码修改之后即时的回归测试策略 XP验收测试，也称客户测试（由客户主导）

工业极限编程（IXP） XP的一种有机进化，合并了六个新实践

• 准备评估
• 项目社区
• 项目特许
• 测试驱动管理
• 回顾
• 持续学习

关于XP的争论 批评意见：

• 需求易变
• 矛盾的客户需求
• 需求的非正规表示
• 正规设计的缺乏

• Scrum 每一个框架活动中，发生于一个过程模式中的工作任务被称为一个冲刺（sprint）。冲刺中进行的工作（每一个框架活动中的冲刺的数目根据产品复杂度和规模大小而有所不同）适应于当前问题，由Scrum团队规定并常常作实时修改

Scrum例会（每天召开的短会） 三个问题： 1.上次例会后做了什么 2.遇到了什么困难 3.下次例会前计划做些什么

• 动态系统开发方法（DSDM） 生命周期活动：

  • 可行性研究
  • 业务研究
  • 功能模型迭代
  • 设计和构建迭代
  • 实现

  应当注意： （1）增量不见得100%完成 （2）增量置于操作环境以后可能需要改变

• 敏捷建模（AM） 敏捷建模的原则：

  • 有目的的模型

  在构建模型之前，开发者心中应当有明确的目标（如与客户沟通信息有助于更好地理解软件的某些方面），一旦确定模型的目标，该用哪种类型的表达方式以及所需要的具体细节程度都是显而易见的

  • 使用多个模型

  描述软件可以使用多种不同的模型和表示法 ，大多数项目只用到其中很小的部分就够了。AM建议从需要的角度看，每一种模型应当表达系统的不同侧面，并且应使用能够为那些预期的读者提供有价值的模型 。

  • 轻装上阵
  • 内容重于表达形式
  • 理解模型及工具
  • 适应本地需要

• 敏捷统一过程（AUP） 每个AUP迭代执行以下活动：

  1. 建模
  2. 实现
  3. 测试
  4. 部署
  5. 配置及项目管理
  6. 环境管理

利用各种工具提升效率与产品质量

代表性工具 OnTime Ideogramic UML Together Tool Set

七种特质：

• 责任感
• 对一些人的需求有敏锐的意识
• 坦诚
• 展现抗压能力
• 有高度的公平感
• 注重细节
• 务实

• 在个人层面，软件工程心理学注重待解决的问题、解决问题所需的技能及在模型外层建立的限制内解决问题的动机。
• 在团队和项目层面，团队能动性成为主要因素。在这一层面，成功是由团队结构和社会因素决定的。团队交流、合作和协调同团队成员的技能同等重要。
• 在外部层面，有组织的行为控制着公司的行为及其对商业环境的应对方式

项目组成员形成团队，不仅是项目成功的保证，而且也能满足成员的需求

团队毒性 5个培育潜在含毒的环境

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

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

软件工程软对的四种组织模式

• 封闭模式（遵循传统的权力层级模式）
• 随机模式（松散地组织团队）
• 开放模式（既具有封闭式泛型的控制性，又包含随机式泛型的创新性的方式来组织团队）
• 同步模式（依赖问题的自然区分，不需要很多的交流就可以将成员组织起来共同解决问题）

最早的软件团队组织（封闭式模式） 主程序员团队 核心成员：

• 1个高级工程师（“主程序员”），负责计划、协调和评审团队的所有技术活动
• 技术人员（一般是2-5人），进行分析和开发活动
• 1个后备工程师，支持高级工程师的活动，并可以在项目进行过程中以最小的代价接替高级工程师的工作 优点：
  • 实现了项目人员分工专业化
  • 降低了管理的复杂性，提高了工作效率 缺点：
  • 现实社会中，缺乏同时具备高超管理才能和技术才能的“全才”

小组沟通的有效性：

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

挑选成员时考虑的因素：

• 应用领域方面的经验
• 编程语言与平台的经验
• 教育背景
• 沟通能力
• 适应性：主要反映学习能力
• 其它：工作态度、个性

开源项目：

• 团队主要由志愿者构成
• 沟通方式主要为电子邮件
• 成功关键：
  • 让志愿者对项目感兴趣：产品有用，对自己有提高
  • 核心成员应该是高手

1. 博客
2. 微博
3. 论坛
4. 社交网站
5. 社区
6. 网址收藏夹网站

例如Git，SVN

全球化软件开发（GSD）团队面临距离的挑战：

• 距离使交流复杂化
• 距离使得协调更困难
• 距离产生了由文化差异导致的障碍和复杂性
• 障碍和复杂性会减弱交流