第一章 软件工程本质

简单、实用 是软件工程的首要准则

• 软件工程金三角

  1. 人： 完成软件开发的主体
  2. 技术：提供了建造软件在技术上需要“如何做”的方法
  3. 管理：提供了质量管理、成本管理、时间管理、范围管理等知识和技能

过程：就是将人、技术、管理结合在一起的凝聚力

• 软件工程技术 6 大知识域

  1. 系统工程
  2. 软件需求
  3. 软件设计
  4. 软件构造
  5. 软件测试
  6. 软件维护

• 软件开发方法

  1. 形式化方法（Formal Method）
  2. 结构化方法（Structured Method）
  3. 面向对象方法（Object Oriented Method）
  4. 基于构件的软件开发方法（Component Based Software Development）
  5. 面向服务方法（Service Oriented Method）
  6. 模型驱动的开发方法（Model-Driven Development）
  7. 敏捷建模方法（Agile Modeling Method）

• 软件工程管理 3 大知识域

  软件工程管理、软件质量管理、软件配置管理

• 软件开发复杂性的 3 个控制方法

  抽象、分解、迭代

• 软件过程主要包括

  1. 软件开发过程
  2. 软件支持过程
  3. 软件运维服务过程
  4. 软件复用过程

• 软件过程分类

  按风格： 线性顺序模型，增量式模型，演化模型 按纪律性分：计划驱动的软件过程，敏捷软件过程

CMMI － 软件过程成熟度模型（Capability Maturity Model Integration）
TSP － 小组软件过程（Team Software Process）
PSP － 个体软件过程（Personal Software Process）

第二章 软件过程

软件过程追求“最佳实践”，过程是产品成本、进度和质量的主要决定因素

• 软件过程的 5 大核心元素

  1. 工件／产品：软件开发过程的中间或最后工作产品，包括文档、模型和程序
  2. 活动：一个过程分为多个活动，一个活动分为多个动作，一个动作分为多个任务
  3. 里程碑：特殊的活动，当时钟到达特定时间，就会触发里程碑检查本阶段的所有活动和工作是否按要求完成
  4. 资源和角色：人是最重要的资源。（硬件：开发系统，目标机器；软件：支持软件，投入时间）
  5. 关系

• 软件生存周期模型

  又称软件开发模型，是软件生命周期的一个框架，规定了软件开发、运作和维护等所需的过程、活动和任务。分类：

  1. 线性顺序模型（瀑布模型）：需求、设计、编码、测试、运维，强调严格线性的完备交付
  2. 增量式模型：构造一系列可执行的中间版本
  3. 演化模型：统一软件过程（RUP，Rational Unified Process），敏捷过程（SCRUM，XP），净室软件过程 演化模型是目前主流开发模型，子类：原型，螺旋模型，并发开发模型

  • RUP

    是由风险驱动的、基于UML和构件式架构的迭代、递增型开发过程，蕴涵了最佳实践准则，分四个阶段，每个阶段是一个里程碑：

    1. Inception 先启
    2. Elaboration 精化
    3. Construction 构建
    4. Transition 产品化

  • 敏捷过程

    强调迅速的自我调整，是一种经验性的过程，在保证软件开发有成功产出的前提下，尽量减少开发过程中的活动和制品（Just enough）－ 敏捷宣言

  敏捷过程核心理念：基于适应而非预测，以人为导向而非过程导向

  • 极限编程（XP）价值观

    沟通、反馈、简化、勇气。特点：测试成为开发的核心，纪律性与灵活性巧妙结合
    关键做法：现场客户、集体拥有代码、结对编程、测试驱动、持续集成等等

  • RUP 和 XP 共同点

    面向对象方法；重视代码、文档的最小化和设计的简化；采用动态适应变化的演进式迭代周期；需求和测试驱动；鼓励用户参与

  • RUP 和 XP 区别

    RUP 以架构为中心，细化阶段的主要目的就是构造一个可运行的架构原型。RUP适合各种规模项目。 XP 以代码为中心，编码与设计活动融为一体，弱化了架构概念，并且不包含建模、过程等概念，只适合小团队。

  • SCRUM（敏捷软件项目管理）核心原则

    自我管理 和 迭代开发

    四个核心工件：

    1. 产品待办事项列表：囊括了开发产品可能需要的所有事项的优先列表
    2. Sprint待办事项列表：包含了在一个Sprint內将产品待办事项列表转化为最终可交付产品增量的所有任务
    3. 发布燃尽图：衡量在一个发布计划的时间段内剩余的产品待办事项列表
    4. Sprint燃尽图：衡量在一个Sprint时间段内剩余的Sprint待办事项列表条目

• 过程的选择

  1. 不同项目需要不同过程
  2. 越大的团队需要越大的过程
  3. 越关键的系统在构建的正确性方面需要越多的透明度
  4. 过程大小或密度上相对小的增加会引起项目成本相对大的增长
  5. 最有效的沟通方式是面对面互动

• 软件过程评估

  个人经验、技术标准、推荐过程、参考模型、评估指南

第三章 软件开发方法

• 软件模型的 3 个层次

  1. 计算无关模型（CIM） － 业务模型
  2. 平台无关模型（PIM） － 分析模型
  3. 平台有关模型（PSM） － 设计模型

• 结构化方法（Structured Method）

  1. 核心：自顶向下，逐步求精
  2. 手段：分解（模块化）、抽象
  3. 需求建模（DFD数据流图，DD数据字典，ERD实体关系图，STD状态图）设计建模（概要设计：SC结构图，详细设计：流程图）

  • 结构图（Structured Chart）

    用来描述软件系统的体系结构，由哪些模块组成，以及模块之间的调用关系
    基本成分：模块，调用，数据

• 面向对象方法（Object Oriented Method）

  • 核心概念

    对象、类、继承、消息

  • 基本原则

    抽象、封装、模块化、层次

• 基于构件的软件开发方法（Component Based Software Development）

  • 构件

    1. 软件复用的重要手段，是核心和基础
    2. 由构件规约与构件实现两部分组成

  • 可复用构件的要求

    1. 通用性和可变性强
    2. 易于调整
    3. 易于组装
    4. 具有可见索性
    5. 经过充分的测试

  • 构件的获取

    1. 存在大量可复用的构件是复用的前提
    2. 获取构件途径：
    1. 从头开发：领域工程
    2. 从现有系统提炼：再工程
    3. 演化现有构件

  • 描述和规约模型

    1. 描述模型：REBOOT、ALOAF、UDM、BIDM模型等
    2. 规约模型：3C、RESOLVE、JBCOM模型等

  • 3C模型

    1. 概念：关于“构件做什么”的抽象描述，即构件的功能；包括接口规约和语义描述两部分
    2. 内容：概念的具体实现；描述构件如何完成概念所刻画的功能
    3. 周围环境：描述构件和外围环境在概念级和内容级的关系；刻画构件的应用环境，为构件的选用和适应性修改提供指导

  • 分类

    1. 枚举分类：通过定义一个层次结构来描述构件
    2. 属性－值分类：为领域中的所有构件定义一组属性
    3. 刻面分类法：从不同的角度（刻面）描述构件

• 面向服务方法（Service Oriented Method）

  • SOA应用的特征

    松散耦合、位置透明、协议独立

  • 服务的特征

    1. 抽象性（基于接口的编程）：服务是实际程序、数据库、业务过程等软件实体的抽象逻辑视图，实现平台透明性
    2. 自治性（实现分布式应用）
    3. 服务间的松耦合绑定，基于标准化信息进行通信
    4. 字描述行（支持动态发现与延迟绑定）
    5. 粗粒度（支持基于业务逻辑的积木式装配）

  • 服务分析

    1. 服务识别（自顶向下，自底向上）
    2. 服务粒度的确定（以对业务的精确掌握为基础；从随需应变出发）
    3. 服务组织（编制，编排）

  • 服务设计

    1. SOA 实现方案：CORBA，Web Service，OSGI，JINI
    2. SOA 中间件：ESB（企业服务总线），BPEL引擎，MQ

• 模型驱动的开发方法（Model-Driven Development）

  1. 将软件的开发集中于模型而不是程序（代码），从模型自动产生程序（代码），主要用来提高开发生产率和代码的可靠性
  2. OMG 定义模型驱动的体系结构（MDA）的初衷是定义一组标准来支持模型驱动的开发，UML 是 MDA 的基础之一
  3. 以模型为中心，基于两种技术：抽象，自动化

  • MDD 主要方法

    1. 可执行的 UML
    2. 从 PIM 到 PSM 或代码的（半）自动生成
    3. 基于 DSL 的开发方法

• 形式化方法（Formal Method）

  1. 基于数学的技术开发软甲，如集合论、模糊逻辑、函数、有限状态机、Petri-net等
  2. 好处：无二义性、一致性、正确性、完整性
  3. 不足：形式化规约 主要关注于功能和数据，而问题的时序、控制和行为等方面却更难于表示；难于学习；难以支持复杂系统

  • 形式化方法 3 部分

    形式化规约、形式化开发、形式化验证

• 软件产品线

  1. 共享一组公共受控特征，满足特定市场需要，并且按照预定方式在相关核心资产基础上开发而成的一系列软件系统
  2. 一条产品线是共享一组共同设计及标准的产品族，这些产品属于同一领域，具有公共需求集，可以根据特定的用户需求对产品线体系结构进行定制，在此基础上通过可复用构件和特定应用构件的组装得到。

第四章 需求工程

• 软件需求概念

  1. 需求：系统必须符合的条件或能力
  2. 软件需求：用户对目标软件系统在功能、行为、性能、设计约束等方面的期望，内容包括 FURPS+

  • FURPS+

    功能性需求： Functionality
    非功能性需求：Usability, Reliability, Performance, Supportability
    “+” 代表了补充需求，例如：

    1. 设计约束：规定或约束了系统的设计需求（选择设计方案）
    2. 实现需求：规定或约束了系统的编码或构建，如所需标准、编程语言、数据库完整性策略、资源限制和操作环境
    3. 借口需求：规定了系统必须与之交互操作的外部软件或硬件，以及对这种交互操作所使用的格式、时间或其他因素的约束
    4. 物理需求：规定了系统必须具备的物理特征，可用来代表硬件需求，如物理网络配置需求

  • 软件需求的三个层次

    系统需求：业务需求／产品需求

    1. 原始需求：项目干系人需求
    2. 概要需求：项目前景文档
    3. 详细需求：软件需求规约

  • 优秀需求的特性

    完整性、正确性、可行性、必要性、划分优先级、无二义性、可验证性 ｜ 可理解型、一致性、可跟踪性

需求工程的目标：让项目干系人对需求达成一致的、正确的理解，因此项目干系人是需求最主要的来源。

• 需求工程的 5 大阶段

  需求获取、需求分析和建模、需求定义，需求验证、需求管理

• 需求获取

  前景文档

  1. 分析问题及根源
  2. 识别项目干系人
  3. 识别项目的约束（环境、政治、经济、技术…）
  4. 术语
  5. 识别需求来源
  6. 收集需求（基本需求－没必要说的，期望需求－谈论的，兴奋需求－创新）
  7. 产品定位
  8. 撰写产品特性
  9. 定义质量范围 10.定义文档需求 11.建立项目范围 12.划分特性优先级

• 需求分析和建模

  对需求进行分析，并进行图形建模形成分析模型

  • 面向对象分析建模过程

    1. 用例模型
    2. 建立概念模型
    3. 识别用例实现
    4. 识别分析类（4-5循环，针对每个用例实现）
    5. 完成用例分析

• 需求定义和验证

  • 需求定义的任务

    1. 细化功能需求
    2. 细化非功能需求
    3. 细化约束条件
    4. 设计用户界面和接口

  软件需求规约（SRS）定义了系统的外在行为和属性（SRS模版）

  • 需求验证

    1. 原型确认
    2. 需求评审（4个阶段：准备计划、实施、检查再实施、总结）

• 需求管理

  1. 定义需求基线
  2. 需求跟踪
  3. 需求变更控制（建立新的需求基线）

第五章 设计工程

软件需求工程解决“做什么”的问题
软件设计工程解决“怎么做”的问题

• 软件设计工程概述

  • 设计的步骤

    1. 架构设计（又称概要设计，定义软件的全貌，记录最重要的设计决策，并成为随后设计与实现的战略指导原则）
    2. 详细设计（又称构件级设计，在软件架构的基础上定义各模块的内部细节，例如内部的数据结构、算法和控制流等，其所做的设计决策往往只影响单个模块的实现）

  • 架构设计

    1. 内容：定义软件架构的 部署、逻辑、数据、其他 视图
    2. 目标：使得软件系统在架构层面的设计上满足拟建系统功能性和非功能性需求

  • 详细设计

    细分模块，定义数据结构、算法细节、控制流、数据流等等

  • 软件设计原则 －－模块化

    1. 模块化 即把软件按照规定原则，划分一个个较小、相互独立又互相关联的部件，实际上是系统分解和抽象的过程
    2. 模块是数据说明、可执行语句等程序对象的集合，它是单独命名的，并且可以通过名字来访问（例如：子系统，过程，函数，子程序，宏，类 等）

  • 模块化的好处

    1. 把复杂问题变简单，更易实现
    2. 把易变部分和稳定部分分开，模块可插拔可替换，应对需求变更和技术升级
    3. 支持多人协同开发
    4. 支持迭代式开发
    5. 模块复用和模块组装，加快开发时间，节省开发费用，提高产品质量
    6. 促进形成大规模开发的软件产业 －－ 软件工场

  • 模块独立的衡量指标

    1. 内聚：一个模块内部各个元素彼此结合的紧密程度的度量，内聚性越高越好
    2. 耦合：模块之间的相对独立性的度量，耦合度越低越好

  • 软件设计的质量要求

    1. 模块化，高内聚，低耦合（支持多人合作开发，易于测试和修改，能够以演化过程实现）
    2. 设计应当包含数据、体系结构、接口和构件的清楚的表示
    3. 设计应根据软件需求才用可复用的方法进行
    4. 应使用能够有效传达其意义的表示法来表达设计模型

  • 7 种软件设计的坏味道

    1. 僵化性
    2. 脆弱性
    3. 牢固性
    4. 粘滞性
    5. 不必要的复杂性
    6. 不必要的重复
    7. 晦涩性

  • 软件设计的 5 大原则

    1. 单一职责原则（SRP）
    2. 开放封闭原则（OCP）
    3. LisKov替换原则（LSP）
    4. 依赖倒置原则（DIP）
    5. 接口隔离原则（ISP）

• 软件设计的复用

  模式，就是在一个上下文中同对一种问题的解决方案

  • 常用软件架构风格

    1. MVC
    2. 数据流风格：批处理序列、管道－过滤器风格
    3. 调用／返回风格：主程序／自程序、面向对象风格、多层
    4. 分布计算风格：多层、代理、C/S、P2P
    5. 独立构件风格：事件响应、消息总线、微服务
    6. 虚拟机风格：解释器、基于规则的系统
    7. 仓库风格：数据库系统、超文本系统、黑板系统
    8. 自适应风格：微内核、反射、控制反馈

• 面向对象的软件设计建模

  确定架构风格，确定设计模式

第六章 质量管理与软件测试

• 软件质量管理概述

  好的软件质量，是明确声明的功能和性能需求、明确文档化过的开发标准、以及专业人员开发的软件所应具有的所有隐含特征都得到满足。

  • 软件质量属性

    质量的三种视角：内部质量、外部质量、使用质量

  • 外部和内部质量模型

    1. 功能性
    2. 可靠性
    3. 易用性
    4. 效率
    5. 维护性
    6. 可移植性

  • 使用质量的模型

    1. 有效性
    2. 生产率
    3. 安全性
    4. 满意度

  • 质量管理

    1. 统计过程控制（SPC）
    2. 全面质量控制（TQC）
    3. 综合质量管理（TQM）

  现代质量观：质量管理必须基于整个过程（研发、生产、运营），软件质量改进相关标准：CMMI、ISO9001、SPICE、Six Sigma都是基于过程的

  • 质量成本

    1. 预防成本
    2. 评估成本
    3. 内部故障成本
    4. 外部故障成本
    5. 测量和测试设备成本

  • 软件质量管理

    1. ISO9000: 质量计划、质量控制、质量保证、质量改进
    2. ISO12207 和 SWEBOK： 软件质量保证、验证和确认、软件评审、软件审核、配置管理
    3. SQuBOK： 从组织级和项目级进行质量管理

  • 质量管理的常用 7 种工具

    1. 检查表
    2. 曾别法
    3. 控制图
    4. 因果图（又称鱼骨图）
    5. Pareto 图
    6. 散布图
    7. 直方图

• 软件测试

  • 6 大原则

    1. 穷尽测试是不可能的
    2. 测试工作具有创造性和挑战性
    3. 测试旨在发现存在的缺陷
    4. 测试是有风险的
    5. 测试需要有计划性
    6. 测试需要有独立性
    

  • 软件 6 个质量属性测试

    1. 功能性测试
    2. 可靠性测试
    3. 性能测试
    4. 易用性测试
    5. 可移植性测试
    6. 可维护性测试

• 软件评审

  • 评审目的

    1. 提高质量
    2. 减少软件开发/维护的时间和费用
    3. 提高生产率
    4. 提高估算准确性
    5. 培训

第六章 软件项目管理

• 项目管理知识体系（PMBOK）

  核心内容

  1. 五大过程组：启动，计划，执行，控制，收尾
  2. 十大知识领域：范围管理，人力资源管理，采购管理，时间管理，风险管理，沟通管理，费用管理，质量管理，干系人管理，整合管理

• 项目计划概述

  制定计划：

  1. 定义软件开发过程
  2. 软件估算
  3. 安排进度，确定里程碑
  4. 分配资源，商讨承诺
  5. 支持计划

项目规划 － 项目生命周期 － 计划大纲

• 进度安排

  1. 建立 PERT 图或网络图，确定关键路径，即决定项目开发时间的任务链
  2. 根据每个活动的工期估算值设置时间窗口（将节假日等非工作日除外）
  3. 考虑时间缓冲，按工期的百分比或固定时间
  4. 对活动时许关系设定 Lead 和 Lag 备：进度安排和人员分配常常同时进行，相互影响

• 人员分配

  Brooks 定律：向一个已经延期的项目追加开发人员，可能使它完成得更晚

• 项目计划变更管理

  • 变更原因

    1. 需求变化
    2. 资源变化
    3. 技术难题
    4. 计划细化
    5. 估算失误
    6. 等等…

• 项目跟踪与监控

  进度、范围、质量、费用、风险、变更、团队、合同

高层管理者 -> 定期审核项目的状态报告 项目经理 -> 负责跟踪和监督并定期报告项目 软件项目组 -> 实施《项目计划》并收集和提交数据

第七章 软件估算技术

• 软件估算概述

  参考历史数据 与 估算精确性的收敛图

当前最有效的估算方法是基于经验模型的参数估算法，如 COCOMO 模型

• 估算方法

  1. 工程方法：类比估算，参数估算
  2. 非工程方法：专家判断，Parkinson法则，从价格出发

• 参数估算

  1. 先估算规模（LOC 代码行，FP 功能点，对象点，用例点）
  2. 再根据规模，估算出工作量、进度和成本（生产率，经验模型）

• 大致估算

  可能的最短进度、有效进度、普通进度

第八章 软件风险管理

• 风险管理概念

  • 风险的特征

    1. 未来将要发生的事
    2. 变更
    3. 不确定
    4. 损失

  • 软件风险的类型

    1. 项目风险：威胁到项目计划，如进度、人力、资源、客户及需求等问题
    2. 技术风险：威胁到软件的质量及交付时间，如设计、实现、接口、验证和维护等问题
    3. 商业风险：威胁到软件的生存能力

  • 5 大商业风险

    市场风险、策略风险、销售风险、管理风险、预算风险

  • 风险策略

    1. 被动风险策略
    2. 主动风险策略（根据风险的投资回报率）

  • 风险管理的投资回报率

    1. 风险管理是一种投资，它是为减轻潜在的不利事件对项目的影响而采取的一项活动。
    2. 风险投资回报率（RIO） ＝ 收益/成本

• 风险管理的成熟度模型

  • 第一级：问题阶段

    危机管理、救火模式 － 风险直到演变成问题才着手处理

  • 第二级：缓和阶段

    引入了风险概念，但缺乏经验，没有计划地减缓风险

  • 第三级：防范阶段

    风险管理从经理的活动变为小组的活动，主动管、识别和消除风险根源

  • 第四级：预知阶段

    量化风险管理，主动迎接风险和评估备用方案

  • 第五级：机会阶段

    有风险的地方也蕴藏着机会（风险被看作节约费用和比计划做得更好的机会）

• 风险管理流程

  • 风险识别方法

    1. 核对清单
    2. 访谈
    3. 头脑风暴
    4. Delphi法
    5. 会议
    6. 评审
    7. 日常输入
    8. 调查
    9. 工作小组

  • 十大软件风险

    1. 需求误解
    2. 缺少上层的支持
    3. 需求变更失控
    4. 未能合理管理客户期望值
    5. 不现实的进度计划和成本预算
    6. 质量低劣
    7. 人员薄弱
    8. 技术和架构风险
    9. 软件外包失败 10.缺乏足够的用户参与

  • 风险分析内容

    1. 风险发生的概率和可能性
    2. 风险影响度（性能，成本，进度，支持）
    3. 风险暴露量 ＝ 发生概率 * 影响度
    4. 预测一组临界点以定义项目终止区域
    5. 建立预警阀值