软件工程 架构驱动的软件开发pdf

软件工程 架构驱动的软件开发 内容简介

本书比较全面地介绍软件工程学科，展示软件工程原则与基于系统工程的软件实践，阐明与软件工程所用的严格方法相关的实践活动、原则、任务和工件。本书共分三部分：第一部分（软件工程基础）讨论在软件工程体系下的软件开发框架和项目构建；第二部分（软件工程实践）通过六项技术惯例传达一种理念——利用计算技术，应用科学原则以及激活设计软件产品结构的灵活性；第三部分（软件工程应用的阶段）讨论软件工程团队在软件开发项目中承担的角色，以便建立和控制软件产品架构。本书适合作为高等院校软件工程及相关课程的教材，也可作为软件开发人员和软件技术人员的参考书。

软件工程 架构驱动的软件开发 目录

第一部分 软件工程基础

第1章 软件工程简介

1.1 明确软件需求

1.2 软件架构

1.3 集成产品和过程开发

1.4 集成产品团队

1.5 工作分解结构

1.6 软件分解结构

1.7 规约树和文档树

1.8 集成总体方案和进度安排

1.9 评审与审核

1.10 配置管理和变更控制

1.11 权衡分析

1.12 风险管理

1.13 建模与仿真

第2章 通用软件开发框架

2.1 软件分解结构

2.2 软件开发过程

2.2.1 需求定义阶段

2.2.2 概要架构定义阶段

2.2.3 关键架构定义阶段

2.2.4 软件单元编码和测试阶段

2.2.5 软件组件的集成和测试阶段

2.2.6 产品测试阶段

2.2.7 验收测试阶段

2.3 总结

第3章 软件架构

3.1 涉众需求的关系和依赖性

3.2 软件需求基线的关系和依赖性

3.3 计算环境的关系和依赖性

3.4 测试和评估的关系及依赖性

3.5 功能架构的关系和依赖性

3.6 物理架构的关系和依赖性

3.7 开发后的过程的关系和依赖性

3.8 软件架构的动机

第4章 理解软件项目环境

4.1 集成产品团队

4.2 软件架构

4.3 复杂性控制机制

4.3.1 工作分解结构

4.3.2 产品分解结构

4.3.3 规约树

4.3.4 文档树

4.3.5 软件产品基线

4.3.6 需求可追踪性准则

4.3.7 权衡分析

4.3.8 软件复杂性度量

4.4 软件术语注册表

4.5 软件集成策略

4.6 项目和技术方案

4.6.1 技术组织规划

4.6.2 项目规划

第5章 软件集成产品和过程开发

5.1 IPPD在软件中的应用

5.1.1 客户至上

5.1.2 产品和进程的并行开发

5.1.3 早期的和连续的生命周期规划

5.1.4 最大化承包商独特方法的优化和使用灵活性

5.1.5 鼓励鲁棒设计，提高过程能力

5.1.6 事件驱动进度

5.1.7 多部门团队协作

5.1.8 授权

5.1.9 无缝管理工具

5.1.10 风险的主动识别和管理

5.2 软件工程和开发

第6章 软件设计阻碍

6.1 作为原材料的软件

6.2 软件技术的变革

6.2.1 软件开发方法和标准

6.2.2 敏捷宣言

6.3 架构驱动的软件开发

第二部分 软件工程实践

第7章 理解软件需求

7.1 第1步：征求涉众需求与期望

7.2 第2步：需求分析与规约

7.2.1 平衡和化解涉众需求的冲突

7.2.2 维护项目的范围

7.2.3 有经验的软件人员的参与

7.3 第3步：任务定义与安排

7.4 第4步：资源的确定、估算和分配

7.5 第5步：建立组织工作包

7.6 第6步：技术规划

7.7 第7步：项目规划

7.8 探索涉众的需求

第8章 软件需求分析实践

8.1 项目分析任务

8.1.1 分析项目目的和目标

8.1.2 确定开发成功标准

8.1.3 征求涉众需求和期望

8.1.4 对涉众需求按优先级排序

8.2 业务分析任务

8.2.1 确定业务概念

8.2.2 确定业务场景

8.2.3 确定计算环境特征

8.2.4 确定外部接口

8.3 产品分析任务

8.3.1 确定业务模式

8.3.2 确定功能行为

8.3.3 确定资源利用率需求

8.3.4 确定数据处理条件逻辑

8.3.5 确定数据持久性需求

8.3.6 确定数据安全性需求

8.3.7 确定数据存储事务

8.3.8 确定性能度量

8.4 维护分析任务

8.4.1 确定开发后的过程业务概念

8.4.2 确定开发后的过程业务场景

8.4.3 确定开发后的过程特征

8.4.4 确定架构的指导方针和原则

8.5 项目评估任务

8.5.1 评估需求敏感性

8.5.2 确定软件测试策略

8.5.3 评估已提议的变更

8.5.4 评估项目可行性

8.6 建立需求基线

第9章 软件需求管理

9.1 接受变更

9.1.1 时间是一种宝贵资源

9.1.2 变更影响分析

9.1.3 调整项目里程碑

9.2 明确需求

9.3 需求分解和分配

9.3.1 功能分析

9.3.2 性能分配

9.3.3 结构化单元综合

9.3.4 结构化组件综合

9.4 需求可追踪性

9.4.1 变更控制

9.4.2 配置审核

第10章 制定功能架构

10.1 功能架构的动机

10.2 功能架构本体论

10.2.1 功能组件

10.2.2 功能单元

10.2.3 数据项

10.2.4 功能接口

10.2.5 外部接口

10.2.6 控制结构

10.2.7 资源

10.2.8 数据存储

10.3 构想功能架构

10.4 记录功能架构

10.4.1 功能层次

10.4.2 行为模型

10.4.3 功能时限

10.4.4 资源利用率概述

10.4.5 功能规约

10.4.6 需求分配表

第11章 功能分析与分配实践

11.1 评估功能复杂性

11.2 行为分析

11.2.1 识别功能场景

11.2.2 识别功能序列

11.2.3 识别数据流

11.2.4 识别控制行为

11.2.5 识别数据处理过程

11.2.6 识别资源先决条件

11.2.7 识别失效条件

11.2.8 识别系统监控过程

11.2.9 识别数据保留能力需求

11.2.10 识别数据安全过程

11.2.11 识别数据持久性与保留功能

11.3 性能分配

11.3.1 分配性能预算

11.3.2 分配资源预算

11.4 架构评估

11.4.1 评估需求满足

11.4.2 评估软件性能

11.4.3 评估架构复杂性

11.4.4 评估优化机会

11.5 建立功能架构

第12章 物理架构配置

12.1 结构设计解决方案

12.1.1 定义结构单元

12.1.2 准备结构单元规约

12.1.3 建立软件集成策略

12.1.4 指定工程组套

12.1.5 准备软件技术数据包

12.2 结构设计考量

12.2.1 结构设计指导原则

12.2.2 使用建模与仿真

12.2.3 行为分析

12.2.4 结构权衡分析

12.2.5 软件产品性能评估

12.2.6 软件原型

第13章 软件设计综合实践

13.1 设计概念化

13.1.1 建立软件架构设计指导原则

13.1.2 识别抽象结构组件

13.1.3 识别抽象用户接口机制

13.2 设计解决方案

13.2.1 识别基本结构元素

13.2.2 识别集成组件

13.2.3 评估软件重用机会

13.3 设计相关性

13.3.1 建立性能基准

13.3.2 识别结构设计缺点

13.3.3 评估架构候选方案

13.3.4 评估软件实现挑战

13.3.5 评估软件维护挑战

13.3.6 评估架构完整性

13.4 设计表现

13.4.1 建立结构设计配置

13.4.2 说明结构配置元素

13.4.3 识别工程组套

13.5 准备软件技术数据包

第14章 软件分析实践

14.1 定义权衡研究

14.1.1 建立权衡研究领域

14.1.2 确定候选方案

14.1.3 建立成功标准

14.2 建立权衡研究环境

14.2.1 汇集实验机制

14.2.2 汇集数据收集和分析机制

14.2.3 建立权衡研究过程

14.3 执行分析

14.3.1 评估需求候选方案

14.3.2 评估功能候选方案

14.3.3 评估结构候选方案

14.4 评估项目影响

14.4.1 评估开发影响

14.4.2 评估项目影响

14.4.3 确定项目执行策略

14.5 评估权衡研究结果

14.5.1 为架构候选方案排序

14.5.2 确定优先行动路径

14.5.3 将权衡研究的决策文档化

14.5.4 优化执行策略

第15章 软件验证和确认实践

15.1 定义V＆V策略

15.1.1 建立V＆V范围

15.1.2 建立V＆V方法

15.1.3 建立V＆V过程

15.2 验证软件架构

15.2.1 验证需求基线

15.2.2 验证功能架构

15.2.3 验证物理架构

15.2.4 验证软件实现

15.3 确认物理架构

15.3.1 确认结构配置

15.3.2 确认集成软件配置

15.4 记录V＆V结果

第16章 软件控制实践

16.1 配置管理

16.1.1 识别架构元素

16.1.2 维护架构状态

16.2 处理工程变更包

16.2.1 记录工程变更请求和提议

16.2.2 准备变更评估包

16.3 变更评估

16.3.1 评估变更技术优点

16.3.2 评估架构影响

16.3.3 评估技术工作包影响

16.3.4 评估技术方案影响

16.4 变更同化

16.4.1 发布变更通知包

16.4.2 审核架构变更进展

16.4.3 评估项目现状

16.5 软件库控制

16.5.1 维护工程工件库

16.5.2 维护变更历史库

16.5.3 维护技术风险库

第三部分 软件工程应用的阶段

第17章 软件需求定义

17.1 软件需求定义的产品

17.2 软件工程集成产品团队（软件需求定义阶段）

17.3 软件实现（软件需求定义阶段）

17.4 计算环境准备（软件需求定义阶段）

17.5 开发后的过程实现（软件需求定义阶段）

17.6 软件测试和评估（软件需求定义阶段）

17.7 评审、里程碑和基线（软件需求定义阶段）

第18章 软件架构定义

18.1 概要架构定义

18.1.1 概要架构定义的产品

18.1.2 软件工程集成产品团队（概要架构定义阶段）

18.1.3 软件实现（概要架构定义阶段）

18.1.4 计算环境准备（概要架构定义阶段）

18.1.5 开发后的过程准备（概要架构定义阶段）

18.1.6 软件测试和评估（概要架构定义阶段）

18.1.7 评审与里程碑（概要架构定义阶段）

18.2 详细架构定义

18.2.1 详细架构定义的产品

18.2.2 软件工程集成产品团队（详细架构定义阶段）

18.2.3 软件实现（详细架构定义阶段）

18.2.4 计算环境准备（详细架构定义阶段）

18.2.5 开发后的过程准备（详细架构定义阶段）

18.2.6 软件测试和评估（详细架构定义阶段）

18.2.7 评审与里程碑（详细架构定义阶段）

18.2.8 建立分配基线

第19章 软件实现

19.1 软件实现的产品

19.2 软件工程任务（软件实现阶段）

19.3 软件实现任务（软件实现阶段）

19.4 计算环境任务（软件实现阶段）

19.5 开发后的过程任务（软件实现阶段）

19.6 软件测试和评估任务（软件实现阶段）

19.7 评审与里程碑（软件实现阶段）

第20章 软件验收测试

20.1 软件验收测试的产品

20.2 软件工程（软件验收测试阶段）

20.3 软件实现组织（软件验收测试阶段）

20.4 计算环境实现组织（软件验收测试阶段）

20.5 开发后的过程组织（软件验收测试阶段）

20.6 软件测试和评估（软件验收测试阶段）

20.7 评审与里程碑（软件验收测试阶段）

20.8 建立软件产品基线

索引

软件工程 架构驱动的软件开发 精彩文摘

随着产品配置被不断细化，产品和WBS势必会被扩展，从而为修改技术计划、进度安排和关键里程碑成果标准提供基础。

成本和进度目标迫使项目向着其最终成果发展。外部力量，例如客户和涉众的需求和期望、计算技术、竞争和市场条件，都会从确立方案开始就对项目施加压力使其不断发展。

这些断言表明，项目管理和软件工程实践应该以这样一种方式建立，即控制好这些截然相反的力量。开发项目目标驱动的本质是关注以及时并且保证成本效益的方式开发和交付软件产品。这授权了一种设想的策略来隔离项目与变更来源。市场的本质表明，软件开发项目必须认识到开发环境中不断变化的条件将会最终决定软件产品的可接受程度和成败。企业对项目的投资在于提供人员、设施、工具和设备，以及项目实施所必要的资源。由于他们的投资，企业希望了解该软件产品的利润，或者希望通过其可靠的软件开发组织提高其在行业中的知名度。

为了妥善处理变更的动态作用，核心软件工程理论必须支持一种技术性方法来促进以下原则：

1）变更是不可避免的！必须要能区分哪些变更是有利的，可以采纳；而哪些变更应该拒绝或者推迟，直到未来出现其他版本的产品并适用。

2）被采纳的变更必须要能以最小的返工量或进度中断数被纳入计划、预算和产品配置中。

3）每种变更都代表一次返工，除非这种变更是一个全新的需求，不需要与软件架构中任何其他的元素进行交互。然而，即使这个变更是独立的，也需要项目方案和进度表更新来将修正的工作范围纳入工作包中。

4）变更会影响涉及试图操作的软件产品或计算环境的软件架构。应该进行变更分析来理解某个变更引起的感知影响，以支持某个项目决定采用该变更。取决于软件开发工作的状态，涉及纳入变更的返工量将会发生显著的变化。在某些情况下，某种变更可能需要将已完成的工作重新进行。变更的范围可以通过评估受影响的软件架构中元素和接口的数量来确定。这将提供一种作为已有设计和必须返工的工作量的指示。规约树和文档树的评审将会支持变更影响决定。

5）在采纳变更之前，必须清楚工作包调整的范围以确保项目成本和进度目标仍然可以达到。软件工程IPT必须能确保提议中变更的影响能彻底明确地支持采取该变更的成本效益分析。

6）变更影响分析应该足够详细，以便于能够被软件架构、技术方案和进度表所纳入，并且不给项目的成功引入额外的风险。

对项目变更的期望可能来源于外部，比如客户、竞争或者计算技术的进步，又或者来源于技术团队对于软件架构方案的一种更深刻的理解。这些从内部提出的变更请求提供了一些可以改进解决方案或确定必要的修改方案来解决现有架构缺陷的机会。这些源于架构缺陷的变更应该主导技术变更控制委员会的关注方向，因此这些调整必须要在现有的技术范围内执行。