第一章 介绍

1.1 软件的定义（Software Definition）

• 程序：指令的集合（程序）通过这些指令来满足预期的特性、功能、需求
• 数据：数据结构。使程序可以良好的使用信息
• 文档：软件描述信息。以硬拷贝和虚拟形式存在，用来描述程序的操作和使用

1.2 软件的双重角色（Software’s Dual Roles）

• 软件既是产品也是产品交付的载体

1.3 软件与硬件的区别（软件特征，Software Features）

1.4 为什么要进行软件更新？（Software Updates）

• 新的商业需求
• 新的环境和技术
• 与其他软件的兼容和交互
• 新的计算环境

1.5 软件过程是什么？（Software Process）

• 软件过程是工作产品构建时所执行的一系列活动，动作和任务的集合。

  • 活动：实现宽泛目标(如与利益相关者沟通)
  • 动作：包含了主要工作产品生产过程中的一系列任务，如体系结构设计,包含很多任务
  • 任务：小而具体,如一个单元测试

• 软件过程定义了软件工程化中采用的方法（框架活动），但软件工程还包括该过程中的应用技术（技术方法和自动化工具），软件过程包含在软件工程中。

process framework：过程框架，

framework activities：框架活动，

work tasks：工作任务，

work prooducts：工作产品，

milestones&deliverables：里程式和可交付成果，

QA checkpoints：QA检查点

1.6 软件工程是什么？（Software Engineering）

• 软件工程是建立和使用一套合理的工程原则，以便经济地获得可靠的、可以在实际机器上高效运行的软件。
• 定义：将系统化、规范化、可量化的方法应用于软件的开发、运行和维护，即：将工程化的方法应用于软件开发以及对上述方法的研究。

1.7 遗留软件（Legacy Software）

特点：

• 不断地被修改以满足商业需要和计算平台的变化。
• 遗留软件系统的维护代价高昂且系统演化风险较高。
• 具有生命周期长以及业务关键性特点，但是质量差。

发生演化的原因：

• 软件需要进行适应性调整，从而可以满足新的计算环境或者技术的需求。
• 软件必须升级以实现新的商业需求。
• 软件必须扩展以使之具有与更多新的系统和数据库的互操作能力。
• 软件架构必须进行改建以使之能适应不断演化的计算环境。

1.8 软件神话（Software Myth）

• 软件神话：关于软件及其开发过程的一些被人盲目相信说法。

1.9 软件危机（Software Crisis）

• 计算机软件的开发和维护过程所遇到的一系列严重问题。

第二章 软件过程（Sofeware Process）

2.1 软件工程的层次（层次化，Hierarchical）

软件工程是层次化的结构：

• 工具：为Process过程和Method方法提供支持
• 方法：提供技术上的解决方法，指出如何构建
• 过程：基础，及时、合理地把技术结合在一起
• 质量关注点：根基，质量承诺

2.2 软件过程概述（Sofeware Process）

2.2.1 通用过程框架（ Generic process framework）

• 过程框架定义了若干个小的框架活动，为完整的软件开发过程建立了基础。这些框架活动可广泛应用于所有软件开发项目，过程框架还包括一些普适性活动。
• 通用的软件工程过程框架的5个活动：沟通、策划、建模、构建、部署。（Communication, planning, modeling, construction and deployment）
• 部署活动提供了反馈报告（ feedback report）

通用框架活动：

• 沟通：包含了与客户（和其他共利益者）之间大量的交流和写作，还包括需求获取以及其他相关活动。
• 策划：指为后续的软件工程工作制定计划。它描述了需要执行的技术任务、可能的风险、资源需求、工作产品和开发人员更好地理解软件需求；设计可以实现需求。
• 建模：它包括创建模型和设计两方面。创建模型有助于客户和开发人员更好地理解软件需求，设计可以实现需求。
• 构建：它包括编码（手写或自动生成）和测试。
• 部署：软件（全部或者完成的部分）交付到用户，用户对其进行评测并给出反馈意见。

注：
1）不同软件过程细节可能差别很大，但框架活动都是一致的。
2）对许多项目来说，随着项目的开展，框架活动可以迭代应用。即，在项目的多次迭代过程中，沟通、策划、建模、构建、部署等活动不断重复（迭代 -> 软件增量 -> 软件逐渐完善）。

2.2.2 普适性活动（umbrella activities）

• 软件项目跟踪和控制Software project management
• 技术评审Formal technical reviews
• 软件质量保障Software quality assurance
• 软件配置管理Software configuration management
• 工作产品的准备和生产Work product preparation and production
• 可复用管理Reusability management
• 测量Measurement
• 风险管理Risk management

2.2.3 过程评估和改进（Capability maturity Model，CMM等）

2.2.3.1 软件能力成熟度模型的五大等级

(1）初始级

软件过程的特点是无秩序或说无定规的，有时甚至是混乱的。软件过程定义几乎处于无章法、无步骤可循的状态，软件产品所取得的成功往往依赖于极个别人的努力和机遇。

(2）可重复级

已建立了基本的项目管理过程,可用于对成本、进度和功能特性进行跟踪。对类似的应用项目,有章可循并能重复以往所取得的成功。

(3）已定义级

用于管理的和工程的软件过程均已文档化、标准化，并形成了整个软件组织的标准软件过程。全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程来进行操作。

(4）已管理级

软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。

(5）优化级

通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地持续地对促进过程进行改进。

2.2.3.2 一些能力成熟度模型评估方法

• Standard CMMI Assessment Method for Process Improvement (SCAMPI)： 用于过程改进的CMMI标准评估方法。分五个评估阶段：起始、诊断、建立、行动和学习。

• CMM-Based Appraisal for Internal Process Improvement (CBA IPI)：用于组织内部过程改进的CMM评估。为评估软件组织的相对成熟度提供诊断技术、使用SEI-CMM作为评估的基础。

• SPICE—The SPICE (ISO/IEC15504) ：软件过程改进和能力测定（software process improvement and capability determination）。标准定义了软件过程评估的一组需求。本标准的目的是帮助组织对任何定义的软件过程的有效性进行客观的评估。

• ISO 9001:2000 for Software：国际标准化组织的软件开发标准。一种通用标准，适用于任何希望提高其提供的产品、系统或服务的总体质量的组织。因此，本标准直接适用于软件组织和公司。

• GB 国标，其中：

  • CMM最先出现，但后来得到了改进，并被CMMI所取代。
  • 不同的三坐标测量机存在重叠、矛盾、缺乏标准化等问题。CMMI后来解决了这些问题。
  • 最初，CMM专门描述软件工程，而CMMI描述集成过程和规程，因为它同时适用于软件和系统工程。
  • CMM/CMMI适用于大型项目。关注过程，而不是软件开发的人员和技术方面，这意味着实现它们并不能保证项目成功。
  • CMM/CMMI是一个综合的过程元模型，它描述了成熟软件过程中应该出现的特定目标、实践和能力。

2.3 过程流（Process flow，线性、迭代、演化、并行）

• 线性过程流：从沟通到部署顺序执行五个框架活动
• 迭代过程流：在执行下一个活动前，重复执行之前的一个或多个活动
• 演化过程流：采用循环的方式执行各个活动
• 并行过程流：将一个或多个活动与其他活动并行执行

2.4 过程模型（Process Model）

软件过程模型习惯上也称为软件开发模型，它是软件开发全部活动、动作和任务的结构框架。

2.5.1 瀑布模型（Waterfall Model）

即典型生命周期模型：沟通、策划、建模、构建、部署，如同瀑布流水逐级下落。

2.5.2 V模型（V-Shape Model）

V模型是瀑布模型的一个变体。V模型提供了一种将验证确认活动应用于早期软件工程工作中的方法。

2.5.3 增量模型（Incremental Model）

每个增量都是可提交运行的版本，（第一个增量往往是核心产品core product）

2.5.4 演化模型之概述（Evolutionary Model）

• 软件总是在持续改变，这些改变通常要求在非常短的期限内完成，在许多情况下，及时投入市场是最重要的要求（如果错过了，软件本身可能会变得毫无意义）。
• 软件团队面临的挑战是在这些关键项目、产品参数和客户满意度之间建立适当的平衡
• 在许多情况下，上市时间是最重要的管理要求。如果错过了一个市场窗口，软件项目本身可能毫无意义。
• 缺陷：
  • 不确定性
  • 演化速度的控制
  • 应侧重灵活性与扩展性
  • 演化模型是迭代的过程模型

2.5.5 演化模型之原型模型（Prototype Model）

原型是预期系统的一个可执行版本，反映了系统性质的一个选定的子集。一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型。

原型模型的过程：首先需要交流，从客户与开发者会议中识别出他们的需求和目标，其次是快速设计阶段，聚焦在更具有代表性的功能，将有形的设计原型给客户。一个原型出现后，再由客户与开发者反复改进，直至建立完整的新系统。

2.5.6 演化模型之螺旋模型（Spiral Model，风险驱动的过程模型）

• 螺旋模型是一种演化过程模型，它结合了原型的迭代性质和瀑布模型的系统性和可控性，注重风险控制（里程碑），适合大型项目开发。

• 螺旋模型两个显著特点：

  1. 采用循环的方式逐步加深系统定义和实现的深度
  2. 确定一系列里程碑，确保利益相关者都支持可行的和令人满意的系统解决方案

• 在每一次迭代的过程中，都要考虑风险、标记里程碑

• 分为几步：

  1. 制定计划：确定软件的目标，选定实施方案，明确项目开发的限制条件。
  2. 风险分析：分析所需的方案，识别风险，消除风险。
  3. 实施工程：实施软件开发，验证阶段性产品。
  4. 用户评估：评价开发工作，提出修正建议，建立下一个周期的开发计划。

2.5.7 并行开发模型（Concurrent Development Model）

协同开发模型，又叫做协同工程。可以表示一系列框架活动，软件工程动作和任务以及相应的状态。协同模型更适合于不同的工程团队共同开发的系统工程项目。尤其是大型的软件公司或者是跨国公司往往要用到这种模型来开发项目。

其它活动（比如沟通或编码等）、动作、任务都可以如下图方式表示，它们同时存在并处于不同的状态

2.5.8 喷泉模型（Fountain Model）

喷泉模型是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性。

优点：

• 提高软件项目的开发效率，节省开发时间。

缺点：

• 开发阶段是重叠的，开发过程中需要大量的开发人员，不利于项目的管理。
• 需要严格的管理文档，使得审核的难度加大。

2.5.9 其他模型

• 基于构建的开发
• 形式化方法模型
• AOSD（Aspect-Oriented Software Development）

2.5.10 总结

2.5 统一过程模型（Unified Process Model）

• 统一过程模型，迭代增量过程，用UML进行面向对象软件工程的框架和过程
• “用例驱动、以架构为核心、迭代和增量”的软件开发过程，关注风险。
• 统一过程模型尝试从传统的软件过程模型中挖掘最好的特征和性质，但是以敏捷软件开发中最好的原则来实现
• 统一过程模型是使用UML进行面向对象软件软件开发的理想的过程模型

第三章 敏捷开发（Agile Development ）

3.1 敏捷是什么？（Agile）

最简而言之：快速、增量（迭代）

• 快速交付产品
• 对变化的有效响应
• 客户加入团队，所有利益相关者之间的有效沟通
• 项目计划必须灵活
• 一个自组织团队，便于沟通

如何创建敏捷流程来管理不可预测性？

• 软件增量必须在短时间内交付

• 软件流程必须逐步适应变化

用户故事是敏捷开发中最小的工作单元。（包括角色，活动，价值三个方面）

3.2 敏捷宣言（Manifesto for Agile）

3.3 极限编程（eXtreme Programming, XP）

3.3.1 极限编程框架活动

• 极限编程是敏捷软件开发中的使用最广泛的一种方法。
• XP使用面向对象方法作为推荐的开发泛型。
• XP包含了策划、设计、编码和测试4个框架活动的规则和实践：
  • 策划：策划活动开始于建立一系列描述待开发软件必要特征与功能的“故事”。每个故事由客户书写并置于一张索引卡上，客户根据对应特征或功能的全局业务价值度标明权值。
  • 设计：XP设计严格遵循保持简洁原则，即使用简单而不是复杂的表述。另外，设计为故事提供不多也不少的实现原则，不鼓励额外功能性设计。
  • 编码：XP推荐的故事开发和基本设计完成之后，团队不应直接开始编码，而实开发一系列用于检测本次（软件增量）发布的包括所有故事的单元测试。XP编码活动中的关键概念之一是结对编程。
  • 测试：在编码开始之前建立单元测试是XP方法的关键因素。所建立的单元测试应当使用一个可以自动实施的框架，这种方式支持代码修改之后及时的回归测试策略。
  • 一旦将个人的单元测试组织到一个“通用测试集”，每天都可以进行系统的集成和确认测试。
  • XP验收测试，也称为客户测试，则客户规定技术条件，并且着眼于客户可见的、可评审的系统级的特征和功能。

3.3.2 极限编程的关键（价值观）

五个要素：

• 沟通（紧密的非正式口头协作，避免大量文档）
• 简单（只为眼前的需要而设计，不考虑未来的需要）
• 反馈（来自实施的软件本身、客户、其他软件团队成员）
• 勇气（今天的设计意味着未来的需求可能会发生巨大的变化，因此需要大量的返工）
• 尊重（IT成员之间、利益相关者之间）

3.3.3 工业极限编程（IXP）

• IXP是XP的一种有机进化。
• 它由XP的最低限要求、以客户为中心、测试驱动精神组成。
• 与原来XP最大差别在于管理具有更大的包容性。
• 合并了六个新实践：
  1. 准备评估
  2. 项目社区
  3. 项目承租
  4. 测试驱动管理
  5. 回顾
  6. 持续学习

3.4 其他敏捷过程

• Scrum
• 动态系统开发方法（DSDM）
• 敏捷建模（AM）
• 敏捷统一过程（AUP）

3.4.1 迭代式增量软件开发过程（Scrum）

• Scrum原则和敏捷宣言一致
• 组织小型团队达到“沟通最大化，负担最小化，非语言描述、非形式化知识”。
• 过程对技术和业务变化必须具有适应性，以“保证制造具有最好可能的产品”。
• 过程生产频繁发布“可检查、可调整、可测试、可文档化、可构建”的软件增量。
• 开发工作和开发人员划分为“清晰的、低耦合的部分或包”。
• 坚持在产品构建过程中进行测试和文档化。
• Scrum过程提供“在任何需要的情况下都能完成产品的能力“ 。
• Scrum强调使用一组”软件过程模式“，这些过程模式被证实在时间紧张的需求变化的和业务关键的项目中是有效的。
• 待定项（backlog） :一个能为用户提供商业价值的项目需求或特征的优先级列表。
• 冲刺（sprint） ：由一些工作单元组成，这些工作单元是达到待定项中定义的需求所必须的，并且必须在预定的时间段内完成。冲刺过程不允许有变更。
• Scrum例会：Scrum团队每天召开的短会。

3.4.2 动态系统开发方法（DSDM）

• DSDM是一种提供”通过在可控项目环境中使用增量原型开发模式完全满足对时间有约束的系统的构建和维护“的敏捷软件开发方法。

• DSDM协会定义了一个称为DSDM生命周期的敏捷过程模型。

• 该声明周期定义了3个不同的迭代循环，前面还加了2个生命周期活动：

  1. 业务需求和约束的可行性研究
  2. 业务研究
  3. 功能模型迭代
  4. 设计和构建迭代
  5. 实现

3.4.3 敏捷建模（AM）

• AM是一种用于对软件系统有效建模和文档化的实践方法学。
• AM是可以有效和以轻量级方式用于软件开发项目的软件建模价值、原则和实践的集合。
• 由于敏捷模型只是大致完善，而不要求完美，因此敏捷模型比传统的模型还要有效。

AM独具特色的建模原则：

• 有目的建模
• 使用多个模型
• 轻装上阵
• 内容重于表述形式
• 理解模型及工具
• 适应团队需要

3.4.4 敏捷统一过程AUP

• 敏捷统一过程采用了一个“全局串行”以及“局部迭代”的原理来构建系统。
• 采用经典UP阶段性活动（起始、细化、构建、转换），AUP提供一系列活动能够使团队为软件项目构想出一个全面的过程流。
• 然后，在每一个活动里，团队迭代使用敏捷，并且将有意义的软件增量尽可能快地交付给最终用户。
• 每个AUP迭代执行以下活动：
  • 建模
  • 实现
  • 测试
  • 部署
  • 配置及项目管理
  • 环境管理

3.4.5 注意

• 前面讲了很多软件过程模型，我们必须认识到每一个软件过程模型都有缺陷
• 尽管许多软件集构已经成功使用了敏捷，敏捷也是有缺点的，如：不规范、难量化、缺乏需求和设计的正规表示等等
• 实践中，关键是认识到一个过程的弱点在哪里，然后使其适应于组织集构的特定要求。