在本章中，你能够学到：
- 软件开发过程中的问题
- 解决软件开发过程通常问题的六个软件工程实践
- 软件工程过程为软件工程实践提供的支持
软件开发问题的症状：
- 用户或者业务需求没有被满足
- 需求的混杂
- 系统模块无法集成
- 系统很难维护
- 较晚的发现系统的缺陷
- 不好的质量或者不好的用户体验
- 不好的负载性能
- 非并行的团队工作
- 构建和发布版本的问题
软件工程的六个实践：
- 迭代开发
- 管理需求
- 基于组件的构架
- 可视化建模
- 持续的质量验证
- 管理变更
注释：迭代开发
迭代开发与瀑布型的开发方法不同，它将软件开发的过程划分为多个迭代，每个迭代都会生成一个反映系统某一部分的构建版本，到最后一个迭代时，整个系统的完全被实现。
每一个迭代都关注在某些需求集得识别、定义和分析上，并且基于这些需求的理解来设计、构建和测试软件。
瀑布型开发的特点 ：
瀑布型的开发从概念上讲是简单的，因为它只产生一个单一的交付产物，。这个开发方法的基本问题是它将风险的识别推迟到项目的后期，这样将会使出来风险的成本非常高
风险的分析
迭代开发首先产生系统的构架，允许集成作为设计阶段的“验证活动”，并且允许在项目的更早时期发现并解决设计的缺陷。贯穿于整个项目的持续的集成代替了在项目末期的一次性的重大集成。
管理需求：
管理需求包括将软件涉众的要求转换为关键涉众的需求和系统特性的集合。这些集合随后将被细化成为功能和非功能的需求说明。详细的说明被转化为设计、用户文档和测试。
对软件来说，需求是测试的关键输入。
用例概念
用例是一种以关注最终用户目标的角度定义需求的技术。他们在迭代式开发过程中被广泛的使用。例如RUP
参与者：不是系统的一部分、它代表了与系统交互的最终用户或者外部系统的角色。
------能够与系统交换信息
-------能够被动的 接收信息
====能够是信息的提供者
能够代表人、机器或者其他系统
用例： 说明了参与者与系统的对话
被一个参与者发起，调用系统的某个功能
是有意义的、流程相关的事件的集合；
产生有观察价值的结果。。
实践三：基于组件的架构
软件架构是一个软件开发的产品，它能够在质量、时间进度和成本上提供最大限度的投资回报。
该过程在全力以赴开发之前，关注于早期的开发和健壮可执行体系结构的基线。它描述了如何设计灵活的，可容纳修改的，直观便于理解的，并且促进有效软件重用的弹性结构。
有弹性的基于组件的架构
- 弹性
满足当前和未来的需求
改进扩展性
增强重用
封装系统依赖
- 基于组件
重用或者定制组件
从商业上得到的组件选择
增量式的进化已存在的软件
基于组件的架构的目地：
- 促进软件的重用
- 软件重用的级别
- 基于组件的架构可以促进项目的管理
实践四：可视化的建模UML
开发过程显示了对软件如何显示可视化建模，捕获体系结构和行为。
为什么要可视化建模呢？
- 帮助管理复杂性
- 保持设计和实现的一致性
- 促进沟通
捕获结构和行为
显示系统元素如何结合在一起
适当的隐藏或者展示细节
为所有的软件从业者提供一种语言
实践五：持续的质量验证
达到质量不仅仅是简单的“满足需求”或者生成满足用户需要和期望的产品。质量也包括确定测量方法和质量标准，也包括确保结构产品能够达到适当的质量要求的过程实现。
软件模型：
ＵＭＬ能够被用于产生代表软件系统不同方面和视图的一系列的模型。几个模型是对于完整的描述系统是非常有用的，不同的软件活动会产生这些模型。每个模型都是被多次的增量迭代开发出来的。
- 业务模型是代表什么样的业务过程和业务环境的模型。它主要被用来获得在业务环境下对软件需求的更好的理解
- 用例模型是表示外部用户与系统交互的模型，它描述了“系统提供的外部服务”
- 设计模型是描述软件如何“实现”被用例描述的服务的模型，它作为实现模型和它的源代码的概念模型服务的
- 实现模型代表物理的软件元素和包含他们的子系统的实现。
实践六：管理变更
统一变更管理（ＵＣＭ）是ＩＢＭＲａｔｉｏｎａｌ 软件在软件系统开发中（从需求到发布）管理变更的方法。
你想控制什么？？
- 工作空间管理
- 并行开发
- 过程集成
- 构建管理