特别鸣谢：唐同学对于本章知识的总结与记录，对您所做的工作表示衷心的感谢，非常感谢您一直以来的支持与帮助，O(∩_∩)O谢谢
1. Chapter 1: The Nature of Software
1.1. Definition of software
软件是：
1) 指令的集合（计算机程序），通过执行这些指令可以满足预期的特征、功能和性能需求；
2) 数据结构，使得程序可以合理利用程序；
3) 软件描述信息，它以硬拷贝和虚拟形式存在，用来描述程序操作和使用。
1.2. Characteristics of Software
概括一下：抽象性、被设计开发的、无磨损、依赖性、半自动半手工、开发昂贵。
1.3. The difference of software and hardware
1) 软件是设计开发的，而不是传统意义上生产制作的；
2) 软件不会磨损，而硬件会；
3) 虽然整个工业向着基于构件的构造模式发展，然而大多数软件仍是根据实际的顾客需求定制的。
1.4. The changing nature of software
遗留软件会发生演化，因为：
1) 软件需要进行适应性的调整，从而可以满足新的计算环境或者技术的需要；
2) 软件必须升级以实现新的商业需求；
3) 软件必须拓展使之具有与更多新的系统和数据库的互操作能力。
4) 软件架构必须改建，使之能适应多样化的网络环境。
Chapter 2: Software Engineering
2.1. Software engineering – a layered technology:
2.2. The definition of Software engineering（与传统工程的区别）
1) 将系统化的、规范化的、可量化的方法应用于软件的开发、运行和维护，即将工程化的方法应用于软件。
2) 工程化的方法的研究。
2.3. The goal of Software engineering
2.4. Layer: tools, methods, process and a quality focus
软件工程师是一种层次化 技术。（软件工程层次图）
1) 支持软件工程的根基在于质量关注点（quality focus）
2) 软件工程的基础是过程层（process）
3) 软件工程方法（method）为构建软件提供技术上的解决方法。
4) 软件工程工具（tool）为过程和方法提供自动化或半自动化的支持。
2.5. A process framework 过程框架–定义了若干个框架活动（framework Activity）为实现完整的软件工程建立了基础。
一个通用的软件工程过程框架通常包含以下5个活动:
1) Communication沟通：目的是理解利益相关者的项目目标，并收集需求以定义软件的特性和功能。
2) Planning策划：定义和描述了软件工程工作，包括需要执行的技术任务、可能的风险、资源需求、工作产品和工作进度计划。
3) Modeling建模：利用模型更好的理解软件需求，并完成符合这些需求的软件设计。
4) Construction构建：包括编码和测试一发现编码中的错误。
5) Deployment部署：软件（全部或者部分增量）交付到用户，用户对其进行评测并给出反馈意见。
2.6. Software development myths
软件神话，即关于软件及其开发过程被人盲目相信的一些说法，可以追溯到计算机技术发展的初期。
1) 管理神话：软件经历经常依赖神话中的信条；
2) 客户神话：导致客户错误的期望，最终导致对开发者的不满：
3) 从业者神话：旧有的方式和态度根深蒂固。
3. Chapter 3: Software Process Structure
3.1. Prescriptive models
3.1.1. The function of process models
软件过程模型就是一种开发策略，这种策略针对软件工程的各个阶段提供了一套范形，使工程的进展达到预期的目的。
3.1.2. Understand the signification and characteristics of the process models（与软件质量的关系）
3.1.3. 过程模式
1) 定义：描述了软件工程工作中遇到的过程相关的问题，明确了问题环境并给出了针对该问题的一种或几种可证明的解决方案。
2) 一个过程模式应该具有:模式名称、目的、类型、启动条件、问题、解决办法、结束条件、相关的模式、已知应用和实例。
3) 过程模式类型
a. 步骤模式：定义了与过程框架活动相关的问题。Eg:建立沟通是一个步骤模式，可能包括需求获取等任务模式。
b. 任务模式：定义了与软件工程动作或是工作任务相关、关系软件工程实践成败的问题。Eg:需求获取。
c. 阶段模式：定义在过程中发生的框架活动序列。Eg：螺旋模型、原型开发。
3.1.4. 框架
1) 通用过程框架定义了五种框架活动–沟通、策划、建模、构建、部署。
2) 其他普适性活动–项目跟踪控制、风险管理、质量保证、配置管理、技术评审以及其他活动。
3.1.5. 过程流（process flow）
1) 描述了在执行顺序和执行时间上，如何组织框架中的活动、动作和任务。
2) 线性过程流、迭代过程流、演化过程流、并行过程流。
3.2. 惯用过程模型
3.2.1. The waterfall model
1) 又称经典生命周期，提出了一个系统的、顺序的软件开发方法。
2) 适合与需求清楚、熟悉的系统，从沟通到部署采用线性工作流方式。
3) 瀑布模型的一个变体—-V cycle model
描述了质量保证动作同沟通、建模相关动作以及早期构建相关的动作之间的关系。
提供了一种将验证动作应用于早期软件过程工作中的方法。
3.2.2. Incremental process models增量过程模型
1) 适合于周期比较短的项目。综合了线性过程流和并行过程流。第一个增量往往是核心产品。
2) OO-based
3) Why use incremental model?
需要迅速提供一套功能有限的软件产品，然后再后续版本中再进行细化和拓展功能，或早期开发人员不足
4) RAD model（rapid application development model）快速应用程序开发
侧重短暂开发周期的增量软件过程模型。是瀑布模型的“高速”变体，通过基于构件实现快速开发。适合需求明确、项目边界固定。
3.2.3. Evolutionary process mode演化过程模型—迭代的过程模型
1) 常用演化过程模型1–Prototyping原型开发
适用–客户提出基本功能，但没有详细定义功能和特性需求。或者开发人员对算法的效率、操作系统兼容性和人机交互的形式等情况并不确定。
2) 常用演化过程模型2–Spiral Model 螺旋模型
a. 是一种演进式软件过程模型；
b. 结合了原型的迭代性质和瀑布模型的系统性和可控性特点；
c. 适合开发大型系统和软件；
d. 具有快速开发越来越完善软件版本的潜力，每次演进会考虑风险、标记里程碑。
3.3. Specialized process models专用过程模型
3.3.1. Component based development基于构件的开发
本质是演化模型，迭代方式构件软件。不同之处在于，采用预先打包的软件构件开发应用系统，需要面向对象技术支持。
3.3.2. Object-oriented process models
3.4. Unified process model统一过程模型
5个阶段：Inception, Elaboration, Construction, Transition,production phase
1) Inception沟通阶段–客户沟通和策划活动
2) Elaboration细化阶段–沟通和通用过程模型的建模活动
3) Construction构建阶段–同通用软件过程的构建。
4) Transition转换阶段–交付、反馈和变更。
5) Production生产阶段–监控软件的持续使用，提供运行环境支持。
4. Chapter 4: Agile Development
4.1. What is Agility?
1) 有效响应变化；
2) 鼓励团队间沟通和协作态度
3) 强调可运行软件的快速交付，不太看重中间产品；
4) 客户作为开发团队的一员；
5) 项目计划灵活可调整。
4.2. Agile Process
4.2.1. XP–extreme programing极限编程
过程：
1) 策划：开始于倾听、产生用户故事、评估故事并给出成本、故事分组、加入下一个发行版本。
2) 设计：遵循KIS（keep it simple），简单表述、鼓励使用CRC（类-责任-协作者）卡确定相关类。
3) 编码：建立单元测试、编码（结对编程）完成后测试、报告反馈
4) 测试：单元测试加入到通用测试集，每天可以进行系统集成和确认测试；XP验收测试（客户测试）。
4.2.2. Scrum
1) 过程由“需求、分析、设计、演化和交付”等框架性活动组成。
2) 每一个过程模式定义一系列开发活动：
a. 待定项（backlog）–为用户提供商业价值的项目需求或特征的优先级列表。
b. 冲刺（sprint）–由工作单元组成，是达到待定项中定义的需求所必需的，必须在预定时间段完成。冲刺过程中不允许变更。
c. Scrum例会–每天开短会。上次例会后做了什么？遇到了什么困难？下次例会前计划做什么？
4.2.3. DSDM–dynamic system development method动态系统开发方法
1) 通过在可控环境中，使用增量原型开发模式，满足对时间有约束的系统的构建和维护。
2) 每一次迭代遵循80%原则–每个增量只完成能够保证顺利进入下一个增量的工作，剩余细节在知道更多需求和变更之后完成。
3) DSDM生命周期–一个敏捷过程模型，定义了2个生命周期活动和3个迭代周期：
a. 可行性研究–建立需求、约束，评估采用DSDM行不行；
b. 业务研究–确定功能和信息需求，基本应用系统架构、识别软件可维护性需求；
c. 功能模型迭代–开发增量原型；
d. 设计和构建迭代
e. 实现–将最终增量置于操作环境中。