第一章
软件危机：软件危机指软件产品的质量低的通常不能解说，并且不能满足交付日期和预算限制。
传统生命周期模型的6个阶段：
- 需求阶段
- 分析（规格说明）阶段，在该阶段结束时制定出SPMP
- 设计阶段
- 实现阶段（单元测试、集成、验收测试）
- 交付后维护（分为纠错性维护和增强性维护），增强性维护分为完善性维护和适应性维护
- 退役
没有计划阶段、没有测试阶段、没有文档阶段，计划、测试和文档获得应当伴随着建造软件产品的所有其他活动进行。
第二章
迭代和递增：迭代和递增互相结合使用，即软件制品是一块一块制造的（递增），每个增加经过多个版本（迭代）。它们都是软件工程的一个固有特性。
生命周期模型：
第三章
软件过程：软件过程是我们生产软件的方式。它包括方法学和隐含的生命周期模型技术、所使用的工具，以及建造软件的人。
统一过程、统一建模语言（UML）
统一过程的五个核心工作流
- 需求流，需求流的目标是让开发组织确定客户的需求。
- 分析流，分析流的目标是分析和提取需求，以获得正确开发软件产品和易于维护它所必需的需求。
- 设计流
- 实现流
- 测试流，测试从始至终与其他工作流并行进行
统一过程的各阶段：开始阶段、细化阶段、构建阶段和转换阶段。
软件过程-能力成熟度模型概念：是一组用于改进软件过程的相关策略。成熟度概念是过程本身良好程度的度量。成熟度级别从低到高分为初始级、可重复级、定义级、管理级和最优级。关键过程区(KPA)是指一个组织在迈向下一个级别时要努力实现的目标。
第四章
民主小组：无我编程、无领导。主要优点是对查找错误的积极态度；缺点是经理和老程序员不能接受
主程序员小组：专业性，等级性。缺点：主程序员难找，不实用性。
其他小组：现代分级编程小组、同步-稳定小组、敏捷过程小组（结对）、开源小组
第五章
理论工具：
逐步求精法：尽可能讲细节的定义推延到最后，以便集中精力在重要的事项上。
成本-效益分析法：对比估计的未来收益和预测的未来成本。
软件度量：代码行(LOC)、职员的流动性等
软件工具（CASE）
修订版、变种版
配置的概念：产品的给定版本所赖以建造的每个制品的特定版本称为产品那个版本的配置。
基准：产品中所有制品的配置（版本集），若要寻找错误时，维护程序员需要把制品复制到个人工作台。
第六章
软件的质量：产品满足规格说明的程度
走查和审查之间的基本不同是走查比审查的步骤少且不那么正式，走查的过程有两步：准备、小组对文档进行分析；审查有五步：概要，准备，审查，修订和跟踪。
应该测试什么？实用性、可靠性、健壮性、性能、正确性
第七章
模块：一个或多个邻接的程序语句的集合，它有一个名称以便系统的其他部分调用它，并且最好具有自己专用的变量名集。
模块的特征：
- 内聚（即模块内部交互的程度）
- 耦合（两个模块之间交互的程度）
内聚从低（坏）到高（好）：偶然性内聚（执行多个完全不相关的操作）、逻辑性内聚（每个操作由调用模块来选择）、时间性内聚（与时间有关）、过程性内聚（与产品要遵循的步骤有关）、通信性内聚（与产品要遵循的步骤有关且对相同数据进行）、功能性内聚（只执行一个操作或只达到单一目标）、信息性内聚（相对独立。对相同数据结构操作）。
耦合从坏到好：内容耦合（直接引用其他模块的内容）、共用耦合（都可存取相同的全局数据）、控制耦合（给另一个模块传递控制要素）、印记耦合（把数据结构作为参数进行传递）、数据耦合（所有参数是同类数据项）。
第八章
可移植：很容易修改整个产品使其在另一个编译器-硬件-操作系统配置上运行。
可重用：使用一个产品中的组件来简化另一个功能不同的产品的开发。
第九章
计划：一个是贯穿项目始终的计划，另一个是完成规格说明之后必须产生的详细计划。
成本估算：
- 用类推法进行专家评判
- 自底向上的方法（把产品分成小的组件，单独进行周期和成本的估算，然后合起来）
- 算法成本估算模型（如COCOMO）
软件项目管理计划的框架
第十一章 需求
需求流真正的目标是确定客户需要什么
第一步是理解应用域
下一步建立业务模型（主要是访谈，其他如调查问卷、表格）
用例图（软件产品本身和软件产品使用者（参与者）之间的交互建立模型）
第十二章 传统的分析
规格说明文档是客户和开发者之间的一种合同，明确了产品必须做什么，以及对产品的约束。
数据流图（DFD）
规格说明采用有穷状态机（状态，事件，谓词）三元组描述，对于大的系统，需要用到状态图
第十三章 面向对象分析
分析流，统一过程有三个类：实体类、边界类、控制类
抽取实体类包括三个迭代和递增地完成的步骤
- 功能建模
- 实体类建模
- 动态建模
类图
250页状态图
267页顺序图
第十四章 设计
设计有面向操作设计（目标高内聚）和面向对象设计（进行详细设计，可用伪代码（PDL）来描述）
传统的设计阶段由三个活动组成：结构化设计、详细设计和设计测试。
第十五章 实现
良好的编程习惯：使用一致和有意义的变量名等
集成：
- 自顶向下的集成，优点：具有错误隔离手段，主要设计错误发现早；缺点：潜在可重用代码制品不能被充分地测试
- 自底向上的集成，优点：具有错误隔离手段，潜在可重用代码制品能被充分地测试；缺点：主要设计错误发现迟
- 三明治集成，优点：具有错误隔离手段，主要设计错误发现早，潜在可重用代码制品能被充分地测试
通过黑盒测试（功能测试）来设计测试的用例，一般要写8个以上（多个测试用例）
第十六章 交付后维护
为什么交付后的维护是必要的？
- 纠错性维护：需要纠正错误，包括分析错误、设计缺陷、编码错误、文档错误以及其他任何错误
- 完善性维护：提高产品的有效性，提高可维护性（客户希望给产品加功能，或使其运行速度更快）
- 适应性维护：为适应产品运行环境的变化需要对产品进行修改
第十七章
统一建模语言（UML）不是一种方法，是一种语言。
九种模型：类图、注解、用例图、交互图、状态图、活动图、包、组件图以及部署图
类图：聚合（局部和整体关系，菱形放在整体一端）、多重性（一个类和其他类关联的次数，1辆汽车有4~5个轮胎）、继承、关联