软件工程与计算II总结

软件工程与计算II

第一、二章 软件工程基础 软件工程的发展

名词解释：软件工程

1. 应用系统的、规范的、可量化的方法来开发、运行和维护软件，即将工程应用到软件。
2. 对1.中各种方法的研究。

简答：从1950s~2000s之间的特点

• 20世纪50年代：科学计算；以机器为中心进行编程；像生产硬件一样生产软件。
• 20世纪60年代：业务应用（批量数据处理和事务计算）；软件不同于硬件；用软件工艺的方式生产软件。
• 20世纪70年代：结构化方法；瀑布模型；强调规则与纪律。它们奠定了软件工程的基础。
• 20世纪80年代：追求生产力最大化，现代结构化方法/面向对象编程广泛应用；重视过程的作用。
• 20世纪90年代：企业为中心的大规模软件系统开发；追求快速开发、可变更性和用户价值；Web应用出现。
• 21世纪00年代：大规模Web应用；大量面向大众的Web产品；追求快速开发、可变更性、用户价值和创新。

第四章 项目管理基础

如何管理团队

建立团队章程；持续成功；和谐沟通；避免团队杀手

团队结构

1. 主程序员团队
   指定技术出色的一人为主程序员，带领团队。优缺点都体现在这种模式的交流路径上。
   如果项目规模小或主程序员能力出众，则取得很高的工作效率。
   项目复杂或主程序员能力不足，则会有瓶颈。
2. 民主团队
   没有集中的瓶颈，每个成员都可以发挥能动性，提高士气和成就感。
   工作效率不如主程序员团队，统一思想和解决冲突的代价不可小视。
   敏捷过程就采用这种形式。
3. 开放团队
   黑箱管理模式。注重自我管理，激励成员主动性，发挥成员创新能力。缺点是没有可视度

质量保障的措施

• 评审：评审有作者之外的其他人来检查产品问题，是静态分析手段。
• 测试
• 质量度量

1. 需求开发——需求评审和需求度量；
2. 体系结构——体系结构评审和集成测试(持续集成)；
3. 详细设计——详细设计评审、设计度量和集成测试(持续集成)；
4. 构造阶段——代码评审、代码度量、测试（测试驱动和持续集成）；
5. 测试阶段——测试、测试度量。

配置管理活动

配置管理：用技术与管理的指导监督方法，标识配置项的功能和物理特征，控制对这些特征的变更，记录和报告变更处理及其状态，验证与需求规格的一致性。

1. 标识配置项
2. 版本管理
3. 变更控制
4. 配置审计
5. 状态报告
6. 软件发布管理

第五章 软件需求基础

名词解释：需求

1. 用户为了解决问题或达到某些目标所需要的条件或能力。
2. 系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备的条件或能力。
3. 对1.或2.中的一种条件或能力的一种文档化表述。

需求的三个层次

1. 业务需求
   抽象层次最高的需求成为业务需求，是系统建立的 战略出发点 ，表现为高层次的 目标 ，它描述了为什么要开发系统。为了满足用户的业务需求，需要描述系统 高层次 的解决方案，定义系统应具备的 特性 。
2. 用户需求
   用户需求是执行实际工作的用户对系统所能完成的 具体任务 的期望，描述了系统能够帮助用户做些什么。
3. 系统级需求
   系统级需求是用户对 系统行为 的期望，每个系统级需求反映了一次外界与系统的交互行为，或者系统的一个实现细节。系统级需求可以直接映射为 系统行为 ，定义了系统中需要实现的功能，描述了开发人员需要 实现什么 。

需求的分类

1. 功能需求：是和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统能够执行的活动，这些活动可以帮助用户完成任务。
2. 性能需求：
   1. 速度：系统完成任务的时间
   2. 容量：系统所能储存的数据量
   3. 吞吐量：系统在连续的时间内完成的事物数量
   4. 负载：系统可以承载的并发工作量
   5. 实时性：严格的实时要求
3. 质量属性：
   1. 可靠性：在规定时间间隔内和规定条件下，系统或部件执行所要求功能的能力。
   2. 可用性：软件系统再投入使用时可操作和可访问程度或能实现其指定系统功能的概率。
   3. 安全性：软件组织对其程序和数据进行未授权访问的能力，未授权的访问可能是有意的，也可能是无意的。
   4. 可维护性：为排除故障、改进质量或适应环境变化而修改软件系统或部件的容易程度，包括可修改性和可扩展性。
   5. 可移植性：系统或部件能从一种硬件或软件环境转换至另外一种环境的特性。
   6. 易用性：与用户使用软件所花费的努力及其对使用的评价相关的特性。
4. 对外接口：用户界面、硬件接口、软件接口、网络通信接口
5. 约束：进行系统构造时需要遵守的约定。环境，标准，商业规则
6. 数据需求：功能需求的补充，是需要在数据库、文件或者其他介质中储存的数据描述。

第六章 需求分析方法

用例图

1. 基本元素：用例、参与者、关系和系统边界
2. 建立：
   1. 进行目标分析与确定解决方向
   2. 寻找参与者
   3. 寻找用例
   4. 细化用例
      用例粒度合适的判断标准是：用例描述了为应对 一个业务事件 ，由 一个用户发起 ，并在 一个连续时间段内完成，可以增加业务价值 的任务。

分析类图

UML的类图是面向对象分析方法的核心技术，它以对象和类的概念为基础，描述系统中的类（对象）和这些类（对象）之间的关系。分析阶段的类图与设计阶段的类图有所不同，他关注用户的业务领域，称为概念类图，又称为领域模型。类型、方法、可见性等复杂的软件构造细节都不会在概念类图中出现。

1. 基本元素：
   1. 对象：标识符、状态、行为
   2. 类
   3. 连接
   4. 关联（聚合）
   5. 继承
2. 建立：
   1. 对每个用例文本描述，尤其是场景描述，建立局部额概念类图。
      • 识别候选类
      • 确定概念类
      • 识别关联
      • 识别重要属性
   2. 将所有用例产生的局部概念类图进行合并，建立软件系统的整体概念类图

系统顺序图

1. 消息有同步消息、异步消息和返回消息
2. 系统顺序图是将整个系统看做一个黑箱的对象而描述的简单顺序图的形式，他强调外部参与者和系统的交互行为，重点展示系统级事件。
3. 建立：
   1. 确定上下文环境。
   2. 确定交互对象。
   3. 按照用例描述中的流程顺序，逐步添加消息。

状态图

1. 状态图常用简单元素包括：状态、开始状态、结束状态、时间、监护条件、活动和转换。
2. 建立：
   1. 确定上下文环境
   2. 识别状态
   3. 建立状态转换
   4. 补充详细信息

第七章 需求文档化与验证

为什么要求需求规格说明

软件开发的子任务与人员之间存在着错综复杂的关系，存在大量的沟通与交流，软件需求是项目中需要进行广泛交流的内容之一，所以需求开发阶段需要进行需求的文档化。

对给定的需求示例，判定并修正其错误

1. 技术文档写作要点：简洁、精确、易读（查询）、易修改
2. 需求书写要点：使用用户术语、可验证、可行性
3. 需求规格说明书写要点：
   1. 充分利用标准的文档模板，保持所有内容的位置得当
   2. 保持文档内的需求集具有完备性和一致性
   3. 为需求划分优先级

对给定的需求示例，设计功能测试用例

1. 以需求为线索，开发测试用例套件
2. 使用测试技术确定输入/输出数据。开发测试用例

第八章 软件设计基础

名词解释：软件设计

软件设计是关于软件对象的设计，是一种设计活动，具有设计的普遍特性。软件设计既指软件对象实现的规格说明，也指产生这个规格说明的过程。

软件设计的核心思想

抽象和分解是软件设计的核心思想。

分解 是横向上将系统分割为几个相对简单的 子系统 以及各子系统之间的关系。
抽象 是在纵向上聚焦各子系统的接口。

软件工程设计的三个层次，各层的主要思想

1. 高层设计 ：基于反应软件高层抽象的构件层次，描述系统的高层结构、关注点和设计决策；
2. 中层设计 ：更加关注组成构件的模块的划分、导入/导出、过程之间的调用关系或者类之间的协作；
3. 底层设计 ：深入模块和类的内部，关注具体的数据结构、算法、类型、语句和控制结构等；

第九、十章 软件体系结构

体系结构的概念

一个软件系统的体系结构规定了系统的计算部件和部件之间的交互。

体系结构的风格的优缺点

1. 主程序/子程序

   • 优点：
     1. 流程清晰，利于理解
     2. 更能控制程序的“正确性”
   • 缺点：
     1. 程序调度是一种强耦合的连接方式，非常依赖交互方的接口规格，这会使得系统难以修改和复用。
     2. 程序调用的连接方式限制了个部件之间的数据交互，可能会使得不同部件使用隐含的共享数据交流，产生不必要的公共耦合，进而破坏他的“正确性”的控制能力。

2. 面向对象式

   • 优点：
     1. 内部实现的可修改性
     2. 易开发、易理解、易复用的结构组织
   • 缺点：
     1. 无法消除接口的耦合性
     2. 标识的耦合性：一个对象要与其他对象交互，就必须知道
     3. 副作用，引入了面向对象的副作用。

3. 分层

   • 优点：
     1. 设计机制清晰，易于理解
     2. 支持并行开发
     3. 更好的可复用性与内部可修改性
   • 缺点：
     1. 交互协议难以修改
     2. 性能损失
     3. 难以确定层次数量和粒度

4. MVC（模型-视图-控制风格）

   • 优点：
     1. 易开发性
     2. 视图和控制的可修改性
     3. 适宜于网络系统开发的特征
   • 缺点：
     1. 复杂性
     2. 模型修改困难

体系结构设计的过程

1. 分析关键需求和项目约束
2. 选择体系结构风格
3. 进行软件体系结构逻辑（抽象）设计
4. 依赖逻辑设计进行软件体系结构物理（实现）设计
5. 完善软件体系结构设计
6. 定义构件接口
7. 迭代过程3.~6.

包的设计原则

1. REP：复用发布等价原则
   重用的粒度就是发布的粒度
2. CCP：共同封闭原则
   将会同时并且因为同样的原因进行修改的类放入一个模块中。
   将会在不同时期因为不同的原因进行修改的类放入不同的模块中。
3. CRP：共同复用原则
   不要依赖于你不需要的东西。
4. ACP：非循环依赖（单向依赖）
5. SDP：稳定依赖原则
   模块应该依赖于比自己更稳定的模块。
6. SAP：稳定抽象原则
   一个模块的抽象程度越高，它就越稳定。反之，具体的模块就不稳定。
   结合稳定依赖原则，沿着依赖的方向，模块应该更加抽象。

体系结构构件之间接口的定义

提供的服务（供接口）：语法、前置条件、后置条件
需要的服务（需接口）：服务名、服务

体系结构开发集成测试用例

1. 桩是在软件测试中用来替换某些模块的。桩一般和所替代的模块有相同的接口，并且模拟的实现了模块的功能。
2. 驱动模仿的是上层模块，用来测试下层。所以，驱动需要利用下层提供的接口，来实现其模仿的模块的功能。

第十一章 人机交互设计

名词解释：易用性

易用性是人机交互中一个既重要又复杂的概念。易用性不仅关注人使用系统的过程，同时还关注系统对使用它的人所产生的作用。易用性不是单维度的质量属性，而是多维度的质量属性，包括易学性、易记性、效率、出错率和主观满意度。

精神模型、差异性

精神模型就是用户进行人机交互时头脑中的任务模型。人机交互设计需要一句精神模型进行隐喻设计。隐喻又被称为视觉隐喻，是视觉上的图像，但会被用户映射为业务事物。

用户群体可以分为新手用户、专家用户、熟练用户。好的人机交互应该为不同的用户群体提供差异化的服务。

导航

导航的目的是为用户提供一个很好的完成任务的入口，好的导航会让这个入口非常符合人的精神模型。

导航有全局结构和局部结构两种方式：

• 全局结构按照任务模型将软件产品的功能组织起来，并区分不同的重要性和主题提供给不同的用户
• 局部结构通过安排界面布局细节，制造视觉上的线索来给用户提供导航。

反馈

• 反馈的目的是提示用户交互行为的结果，但不能打断用户工作时的意识流。
• 对时间的控制也是反馈设计的一个要点，它既要考虑计算时间，又要考虑用户的思考和反应时间。

协作式设计

人和计算机是人机交互的两方，其中人的因素是比较固定的，一定时期内不会发生大的变化，所以要让二者交互顺畅，就需要让计算机更多地适应人的因素，这也是人机交互设计以用户为中心的根本原因。这种调整计算机因素以更好地适应并帮助用户的设计方式被称为协作式设计。

界面设计的注意事项

1. 简洁设计
2. 一致性设计
3. 低出错率设计
4. 易记性设计
   • 减少短期记忆负担
   • 使用逐层递进的方式展示信息
   • 使用直观的快捷方式
   • 设置有意义的默认值

第十二章 详细设计的基础

详细设计的出发点

软件详细设计在软件体系结构设计之后进行，以 需求开发的结果 和 软件体系结构的结果 为出发点。

职责分配、协作和控制风格

设计模型的建立

1. 通过职责建立静态设计模型
   1. 抽象对象的职责：类的职责主要有两部分组成：属性职责和方法职责。属性主表现对象的状态，方法主要表示对象的行为。
   2. 抽象类之间的关系：依赖 < 关联 < 聚合 < 组合 < 继承
   3. 添加辅助类
2. 通过协作建立动态设计模型
   1. 抽象对象之间的协作
   2. 明确对象的创建
   3. 选择合适的控制风格：集中式、委托式、分散式
      1. 集中式控制风格中，做决策的往往只有一个对象，由这个对象决定怎么来分配职责，怎么来实现大的职责。所有其他对象都只和这个中心控制对象进行交互。
      2. 委托式控制风格中，做出决策的对象不止一个。这些对象分别承担一定的职责，做出一定的决策，从而共同实现大的职责。职责的分解层次决定了控制对象的层次没控制对象还可以再分解其职责到更低层次的控制对象，委托其完成相应的任务。
      3. 分散式控制风格中，则无法找到明确的控制对象，每个对象都只承担一个相对较小的职责，完全靠各个对象自治的方式来实现大的职责。

给定分析类图、系统顺序图和设计因素描述

建立设计类图


或者详细顺序图

协作的测试

类间协作的桩程序通常被称为Mock Object，它不同于体系结构集成的stub类型桩程序。Mock Object要求自身的测试代码更简单，可以不用测试就能保证正确性。

第十三章 详细设计中的模块化与信息隐藏

名词解释：耦合与内聚

• 耦合描述的是两个模块之间的关系的复杂程度。
• 内聚表达的是一个模块内部的联系的紧密性。

耦合

内聚

信息隐藏

1. 基本思想
   信息隐藏的核心设计思路是每个模块都隐藏一个重要的设计决策。每个模块都承担一定的职责，对外表现为一份契约，并且在这份契约之下隐藏着只有这个模块知道的设计决策或者秘密，决策实现的细节只有该模块自己知道。抽象出接口，隐藏实现。
2. 两种信息隐藏决策：按决策抽象，按算法抽象
   1. 从可修改性上来说，按决策抽象之后，所有的决策秘密都只限于一个模块，所以一旦发生变更也只会孤立在一个模块的内部。而按算法分解，则可能会设计多个方面。
   2. 从独立开发的角度来说，按算法分解必须先设计好所有的数据结构，建立复杂、准确的描述，然后才能并行开发，应为各个模块都共享数据结构。而按决策抽象则只需要定义好各个模块的接口，就可以进行独立的开发，描述也相对简单。
   3. 从可理解性上看按算法分解必须看到整体才能完全理解，而按决策抽象则不需要。
3. 对例子，说明其信息隐藏程度的好坏

第十四章 详细设计中面向对象方法下的模块化

模块化原则

1. 《全局变量有害》
2. 《显式的》
3. 《不要重复》
4. 针对接口编程
5. 访问耦合的合理范围/迪米特法则
6. 接口最小化/接口分离原则（ISP）
7. Liskov替换原则（LSP）
8. 使用组合代替继承
9. 单一职责原则（SRP）

第十五章 详细设计中面向对象方法下的信息隐藏

信息隐藏的含义

1. 封装类的职责，隐藏职责的实现
2. 预计将会发生的变更，抽象它的接口，隐藏它的内部机制

封装

封装的两方面含义：

1. 将数据和行为同时包含在类中
2. 分离对外接口与内部实现

封装的典型实现细节：

1. 封装数据和行为
2. 封装内部结构
3. 封装其他对象的引用
4. 封装类型信息
5. 封装潜在变更

封装变更/开闭原则（OCP）

开闭原则式对面向对象设计的一个指导性、方针性原则，具体内容是：

1. 好的设计应该对“扩展”开放
2. 好的设计应该对“修改”关闭

简单来说，开闭原则是指：在发生变更时，好的设计只需要添加新的代码而不需要修改原有的代码，就能够实现变更。

依赖倒置（DIP）

依赖倒置原则是指：

1. 抽象不应该依赖于细节，细节应该依赖于抽象。
2. 高层模块不应该依赖于底层模块，而是双方都依赖于抽象。

第十六章 详细设计的设计模式

如何实现可修改性、可扩展性、灵活性

为实现上述质量，需要能够将接口和实现分离。

策略模式

抽象工厂模式

单件模式

迭代器模式

给定场景，应用设计模式并写出代码

给出代码，要求用设计模式改写

第十七、十八章 软件构造 代码设计

软件构造包含的活动

软件构造的主要活动包括：详细设计、编程、测试、调试、代码评审、集成与构建、构造管理。

名词解释：重构、测试驱动开发、结对编程

1. 重构：修改软件系统的严谨方法，它在不改变代码的外部表现的情况下改进其内部结构。
2. 测试驱动开发：要求程序员在编写一段代码之前，优先完成这段代码的测试代码。
3. 结对编程：两个程序员挨着坐在一起，共同协作进行软件构造活动。

给定代码段示例例，对其进行改进或者发现其中的问题

1. 简洁性/可维护性
2. 使用数据结构消减复杂判定
3. 控制结构
4. 变量使用
5. 语句处理
6. How to write unmaintainable code
7. 防御与错误处理

单元测试用例的设计

契约式设计

前置条件满足，后置条件满足

异常：代码开始执行判断前置条件，结束执行后判断后置条件，不符合抛出异常（throw）。

断言：代码开始执行检查前置条件，结束执行后检查后置条件，不符合抛出异常（assert）。

防御式编程

外界发生错误，内部不受损害。会增加复杂度降低易读性和性能，但是增加了可靠性。

表驱动

prePointArray = { 1000, 2000, 5000 }
postPointArray = { 1000, 2000, 5000 }
levelArray = { 1, 2, 3 }
for (int i = 0; i <= 2; i++) {
   if ( (prePoint < prePointArray[i]) && (postPoint >= postPointArray[i]) ) {
      triggerGiftEvent(levelArray[i]);
   }
}

第十九章 软件测试

掌握白盒测试和黑盒测试的常见方法，并进行能够优缺点比较

黑盒测试：把测试对象看做一个黑盒子，完全基于输入和输出来判断测试对象的正确性。

• 优点 ：

  1. 比较简单，不需要了解程序的内部的代码及实现
  2. 与软件的内部实现无关
  3. 从用户的角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题
  4. 基于软件开发文档，所以也能知道软件实现了文档中的哪些功能
  5. 在做软件自动化测试时较为方便

• 缺点：不可能覆盖所有的代码

• 常用方法：

  1. 等价类划分
  2. 边界值分析
  3. 决策表
  4. 状态转换

白盒测试：把测试对象看做透明的，按照测试对象内部的程序结构来设计测试用例进行测试工作。

• 优点：帮助软件测试人员增大代码的覆盖率

• 缺点：

  1. 不可能覆盖所有的代码
  2. 测试基于代码，只能测试开发人员做的对不对，而不能知道设计是否正确，可能会漏掉一些功能需求
  3. 系统庞大时，测试开销会非常大

• 常用方法：

  1. 语句覆盖：保证每一行代码都至少执行一次。
  2. 条件覆盖：保证每个判断结果都至少满足一次。
  3. 路径覆盖：保证每条独立的执行路径都至少执行一次。

给出一个场景，判断应该使用哪种测试方法，如何去写（*）

• 对给定的场景和要求的测试⽅方法，设计测试用例
• 给出功能需求，则要求写功能测试用例
• 给出设计图，则要求写集成测试用例，Stub and Driver
• 给出方法的描述，则要求写单元测试用例，Mock Object
• JUnit基本使用方法

第二十、二十一章 软件交付、维护与演化

如何理解软件维护的重要性？

1. 由于会出现新的需求，如不维护软件将减小甚至失去服务用户的作用。
2. 随着软件产品的生命周期越来越长，在软件生存期内外界环境发生变化的可能性越来越大，因此，软件需要修改以适应外界环境的改变。
3. 软件产品或多或少的会有缺陷，当缺陷暴露出来时，必须予以及时的解决。

开发可维护软件的方法

1. 考虑软件的可变更性：分析需求的易变性、为变更进行设计。
2. 为降低维护困难而开发：编写详细的设计文档并保持及时更新、保证代码的可读性、维护需求跟踪链、维护回归测试基线。

演化式生命周期模型

初始开发-演化-服务-逐步淘汰-停止

1. 初始开发
   初始阶段的一个及其重要的工作是建立一个好的软件体系结构。
   初始阶段的详细设计也要关注软件系统的可扩展性和可修改性。
   初始阶段还有一个重要事项是整个开发团队要在该阶段建立对软件产品的整体理解。

2. 演化
   该阶段可能的演化增量有：

   • 预先安排的需求增量；
   • 因为问题变化或者环境变化产生的变更请求；
   • 修正已有的缺陷；
   • 随着用户与开发者之间越来越相互熟悉对方领域而新增加的需求。

   演化阶段的软件产品要具备两个特征：

   1. 软件产品具有较好的可演化性。
   2. 软件产品能够帮助用户实现较好的业务价值。

3. 服务
   服务阶段的软件产品不再持续的增加自己的价值，而只是周期性的修正已有的缺陷。

4. 逐步淘汰
   在逐步淘汰阶段，开发者已经不再提供软件产品的任何服务，也即不再继续维护该软件。

5. 停止
   一个软件正式退出使用状态之后就进行停止状态。开发者不再进行维护，用户也不再使用。

用户文档 系统文档

1. 用户文档：用户文档是指为用户编写参考指南或者操作教程，常见的如用户使用手册、联机帮助文档等。
   文档内容的组织应当支持其使用模式，常见的是指导模式和参考模式两种。指导模式根据用户的任务组织程序规程，相关的软件任务组织在相同的章节或主题。指导模式要先描述简单的、共性的任务，然后再以其为基础组织更加复杂的任务描述。
   参考模式按照方便随机访问独立信息单元的方式组织内容。例如，按字母顺序排列软件的命令或错误消息列表。如果文档需要同时包含两种模式，就需要将其清楚地区分成不同的章节或主题，或者在同一个章节或主题内区分为不同的格式。

2. 系统文档：更注重系统维护方面的内容，例如系统性能调整、访问权限控制、常见故障解决等等。因此，系统管理员文档需要详细介绍软硬件的配置方式、网络连接方式、安全验证与访问授权方法、备份与容灾方法、部件替换方法等等。

逆向工程、再工程

1. 逆向工程：
   分析目标系统，标识系统的部件及其交互关系，并且使用其它形式或者更高层的抽象创建系统表现的过程。

   逆向工程的基本原理是抽取软件系统的需求与设计而隐藏实现细节，然后在需求与设计的层次上描述软件系统，以建立对系统更加准确和清晰的理解。

2. 再工程：
   检查和改造一个目标系统，用新的模式式及其实现复原该目标系统。

   目的是对遗留软件系统进行分析和重新开发，以便进一步利用新技术来改善系统或促进现存系统的再利用。

   主要是两类活动：

   1. 改进人们对软件的理解；
   2. 改进软件自身，通常是提高其可维护性、可复用性和可演化性。

   常见具体活动有：重新文档化；重组系统的结构；将系统转换为更新的编程语言；修改数据的结构组织。

第二十二、二十三章 软件开发过程模型 软件工程职业基础

软件生命周期模型

人们将软件从生产到报废的生命周期分割为不同阶段，每个阶段有明确的典型输入/输出、主要活动和执行人。各个阶段形成明确的、连续的顺序结构，这些阶段划分就被称为软件生命周期模型。

典型的软件生命周期模型：
需求工程—软件设计—软件实现—软件测试—软件交付—软件维护

软件过程模型

题型：
解释与比较不同过程模型（要求、特征描述、优点、缺点）
对给定的场景，判定适用的开发过程模型

1. 构建-修复模型
   1. 特征：没有考虑最基本的生命周期模型，没有对需求真实性、设计结构质量、代码组织质量、质量保障等软件开发的复杂因素进行关注点分解。
   2. 缺点：
      • 没有对开发工作进行规范和组织，所以随着软件系统发的复杂提升，开发活动会超出个人的控制能力。
      • 没有分析需求的真实性，给软件开发带来很大的风险。
      • 没有考虑软件结构的质量，使得软件结构在不断的修改中变得越来越糟，直至无法修改。
      • 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。
   3. 适用场景：软件规模很小，只需要几百行程序，其开发复杂度是个人能力能够胜任的；软件对质量的要求不高，即使出错也无所谓；只关注开发活动，对后期维护的要求不高，甚至不需要进行维护。
2. 瀑布模型
   1. 特征：对于软件开发活动有明确的阶段划分，允许活动出现反复和迭代，每个活动的结果必须要进行验证，并且只有经过验证之后才能作为后续开发活动的基础。所以瀑布模型被看做是“文档驱动”的。
   2. 优点：为软件开发活动定义了清晰的阶段划分，这让开发者能够以关注点分离的方式更好地进行那些复杂的软件项目的开发活动。
   3. 缺点：
      • 对文档的过高期望。
      • 对开发活动的线性顺序假设。
      • 客户、用户参与不够。
      • 里程碑粒度过粗。
   4. 适用：需求非常成熟、稳定，没有不确定的内容，也不会发生变化；所需的技术成熟、可靠，没有不确定的技术难点，也没有开发人员不熟悉的技术问题；复杂度适中，不至于产生太大的文档负担和过粗的里程碑。
3. 增量迭代模型
   1. 特征：增量迭代模型在项目开始时，通过系统需求开发和核心体系结构设计活动完成项目对前景和范围的界定，然后再将后续的开发活动组织为多个迭代、并行的瀑布式开发活动。是“需求驱动”的。
   2. 优点：
      • 迭代式开发更加符合软件开发的实践情况，具有更好的实用性；
      • 并行开发可以帮助缩短软件产品的开发时间；
      • 渐进交付可以加强用户反馈，降低开发风险。
   3. 缺点：
      • 需要软件具备开放式的体系结构。
      • 需要一个完备、清晰的项目前景和范围以进行并行开发规划。
   4. 适用：比较成熟和稳定的领域
4. 演化模型
   1. 特征：演化模型每次迭代的需求不是独立的，设计和实现工作也是在前导迭代的基础上进行修改和扩展。是“需求驱动”的。
   2. 优点：
      • 迭代式开发具有更好的实用性，演化式迭代安排能够适用于那些需求变化比较频繁或不确定性较多的软件系统的开发；
      • 并行开发可以帮助缩短软件产品的开发时间；
      • 渐进交付可以加强用户反馈，降低开发风险。
   3. 缺点：
      • 无法在项目早期阶段确定项目范围
      • 容易让后续迭代忽略分析与设计工作
   4. 适用：不稳定领域的大规模软件系统开发
5. 原型模型
   1. 特征：将需求开发活动展开为抛弃式原型开发的迭代，充分利用抛弃式原型解决新颖领域的需求不确定问题。驱动原型模型的可以是需求，也可以是风险。
   2. 优点：
      • 对原型方法的使用加强了与客户、用户的交流
      • 适用于非常新颖的领域，这些领域有着大量的不确定性
   3. 缺点：
      • 原型方法能够解决风险，但自身也能带来新的风险，例如原型开发的成本较高，可能会耗尽项目的费用和时间
      • 实践中，很多项目负责人不舍得抛弃“抛弃式原型”，使得质量较差的代码进入了最终产品。
   4. 适用：有着大量不确定性的新颖领域
6. 螺旋模型
   1. 特点：基本思想是尽早解决比较高的风险，如果有些问题实在无法解决，那么早发现比项目结束时再发现要好，至少损失要小得多。螺旋模型是“风险驱动”的。
   2. 优点：可以降低风险，减少项目因风向造成的损失。
   3. 缺点：
      • 使用了原型手段，存在原型自身带来的风险。
      • 模型过于复杂，不利于管理者依据其组织软件开发活动。
   4. 适用：高风险的大规模软件系统开发。

软件工程知识体系的知识域

需求、设计、构造、测试、维护、配置管理、工程管理、工程过程、工程工具和方法、质量