给大家推荐一本好书《统一软件开发过程》

小希格玛

出版社：机械工业出版社
译作者：（美）Ivar Jacobson等著 周伯生等译
出版日期：2002年1月
定价：￥45
国标编号：
ISBN 7-111-07572-2/TP.1200
条形码：9787111075721
字数：　印张：24.25
印数：6001-10000　页数：361
开本：787*1092 1/16
　　本书是由UML的三位创始人Ivar Jacobson，Grady Booch，James Rumbaugh亲自撰写的。全书给出了一种以UML作为建模语言进行软件开发的过程指导。书中的内容不是UML固有的组成部分，因为UML只是一种建模语言，并不包括过程指导。实际上，UML独立于过程的特点可以使之用于不同的软件开发过程。但是本书介绍的软件开发过程是三位作者在开发UML时一直在头脑中思考的内容，因此很切合UML的特点。本书对于如何运用UML的概念进行软件开发提供了详细指导，适合参与软件开发的各类人员使用，尤其适合软件项目开发组成员阅读。

图书目录
译者序
译者简介
前言

第一部分 统一软件开发过程

第1章 统一过程的特点：用况驱动、以构架为中心、迭代和增量的

1.1 统一过程概述
1.2 统一过程是用况驱动的
1.3 统一过程是以构架为中心的
1.4 统一过程是迭代和增量的过程
1.5 统一过程的生命周期
1.5.1 产品
1.5.2 一次循环所包含的阶段
1.6 一个综合的过程

第2章 软件开发的四个要素：人员、项目、产品和过程

2.1 人员至关重要
2.1.1 开发过程影响人员
2.1.2 角色会发生变化
2.1.3 将“资源”转化为“工作人员”
2.2 项目创造产品
2.3 产品不仅仅是代码
2.3.1 什么是软件系统？
2.3.2 制品
2.3.3 系统包含一组模型
2.3.4 什么是模型？
2.3.5 每个模型是系统自包含的视图
2.3.6 模型的内部
2.3.7 模型间的关系
2.4 过程指导项目
2.4.1 过程：一个模板
2.4.2 相关活动组成工作流
2.4.3 过程具体化
2.4.4 过程的价值
2.5 工具对于过程不可或缺
2.5.1 工具对过程的影响
2.5.2 过程驱动工具
2.5.3 平衡过程和工具
2.5.4 支持UML的可视化建模
2.5.5 支持整个生命周期的工具
2.6 参考资料

第3章 用况驱动过程

3.1 用况驱动开发概述
3.2 为什么使用用况？
3.2.1 为了捕获附加在需求上的价值
3.2.2 为了驱动过程
3.2.3 为了设计构架以及其他
3.3 捕获用况
3.3.1 用况模型表示功能性需求
3.3.2 参与者是系统的环境
3.3.3 用况确定系统
3.4 实现用况的分析、设计和实现
3.4.1 根据用况建立分析模型
3.4.2 每个类必须履行其所有的协作角色
3.4.3 根据分析模型建立设计模型
3.4.4 按子系统对类分组
3.4.5 根据设计模型建立实现模型
3.5 用况的测试
3.6 小结
3.7 参考资料

第4章 以构架为中心的过程

4.1 构架概述
4.2 为什么需要构架？
4.2.1 理解系统
4.2.2 组织开发
4.2.3 鼓励重用
4.2.4 进化系统
4.3 用况和构架
4.4 建立构架的步骤
4.4.1 构架基线是一个“小的、皮包骨架的”系统
4.4.2 使用构架模式
4.4.3 描述构架
4.4.4 构架设计师创建构架
4.5 最后是构架描述！
4.5.1 用况模型的构架视图
4.5.2 设计模型的构架视图
4.5.3 实施模型的构架视图
4.5.4 实现模型的构架视图
4.6 三个应关注的概念
4.6.1 什么是构架？
4.6.2 如何获得构架？
4.6.3 如何描述构架？
4.7 参考资料

第5章 迭代和增量过程

5.1 迭代和增量概述
5.1.1 以细小的步骤开发
5.1.2 迭代不是什么
5.2 为什么采用迭代和增量的开发方法？
5.2.1 降低风险
5.2.2 获得一个健壮的构架
5.2.3 处理不断变化的需求
5.2.4 允许灵活改变
5.2.5 实现持续的集成
5.2.6 尽早得到有关知识
5.3 迭代方法是风险驱动的
5.3.1 迭代降低了技术风险
5.3.2 管理对非技术性风险负责
5.3.3 处理风险
5.4 通用迭代过程
5.4.1 迭代是什么
5.4.2 规划迭代过程
5.4.3 确定迭代次序
5.5 一次迭代产生一个增量结果
5.6 在整个生命周期上的迭代
5.7 由迭代过程来进化模型
5.8 迭代对开发组织具有挑战性
5.9 参考资料

第二部分 核心工作流

第6章 捕获需求：从构想到需求

6.1 为什么捕获需求很困难
6.2 需求工作流的目的
6.3 需求捕获概述
6.4 需求在软件生命周期中的作用
6.5 运用领域模型来理解系统的语境
6.5.1 什么是领域模型？
6.5.2 建立领域模型
6.5.3 领域模型的使用
6.6 使用业务模型来理解系统的语境
6.6.1 什么是业务模型？
6.6.2 如何建立业务模型
6.6.3 根据业务模型确定用况
6.7 补充需求
6.8 小结
6.9 参考资料

第7章 捕获需求作为用况

7.1 引言
7.2 制品
7.2.1 制品：用况模型
7.2.2 制品：参与者
7.2.3 用况
7.2.4 制品：构架描述（用况模型视图）
7.2.5 制品：术语表
7.2.6 制品：用户界面原型
7.3 工作人员
7.3.1 工作人员：系统分析人员
7.3.2 工作人员：用况描述人员
7.3.3 工作人员：用户界面设计人员
7.3.4 工作人员：构架设计师
7.4 工作流
7.4.1 活动：确定参与者和用况
7.4.2 活动：区分用况的优先级
7.4.3 活动：详细描述一个用况
7.4.4 活动：构造用户界面原型
7.4.5 活动：构造用况模型
7.5 需求工作流小结
7.6 参考资料

第8章 分析

8.1 引言
8.2 分析概述
8.2.1 为什么分析不同于设计与实现
8.2.2 分析目的：小结
8.2.3 何时使用分析的具体实例
8.3 分析在软件生命周期中的作用
8.4 制品
8.4.1 制品：分析模型
8.4.2 制品：分析类
8.4.3 制品：用况实现—分析
8.4.4 制品：分析包
8.4.5 制品：构架描述（分析模型的视图）
8.5 工作人员
8.5.1 工作人员：构架设计师
8.5.2 工作人员：用况工程师
8.5.3 工作人员：构件工程师
8.6 工作流
8.6.1 活动：构架分析
8.6.2 活动：分析用况
8.6.3 活动：分析类
8.6.4 活动：分析包
8.7 分析小结
8.8 参考资料

第9章 设计

9.1 引言
9.2 设计在软件生命周期中的作用
9.3 制品
9.3.1 制品：设计模型
9.3.2 制品: 设计类
9.3.3 制品：用况实现—设计
9.3.4 制品：设计子系统
9.3.5 制品：接口
9.3.6 制品：构架描述（设计模型的视图）
9.3.7 制品：实施模型
9.3.8 制品：构架描述（实施模型的视图）
9.4 工作人员
9.4.1 工作人员：构架设计师
9.4.2 工作人员：用况工程师
9.4.3 工作人员：构件工程师
9.5 工作流
9.5.1 活动：构架设计
9.5.2 活动：设计一个用况
9.5.3 活动：设计一个类
9.5.4 活动：设计一个子系统
9.6 设计小结
9.7 参考资料

第10章 实现

10.1 引言
10.2 实现在软件生命周期中的作用
10.3 制品
10.3.1 制品：实现模型
10.3.2 制品：构件
10.3.3 制品：实现子系统
10.3.4 制品：接口
10.3.5 制品：构架描述（实现模型的视图）
10.3.6 制品：集成构造计划
10.4 工作人员
10.4.1 工作人员：构架设计师
10.4.2 工作人员：构件工程师
10.4.3 工作人员：系统集成人员
10.5 工作流
10.5.1 活动：构架实现
10.5.2 活动：系统集成
10.5.3 活动：实现一个子系统
10.5.4 活动：实现一个类
10.5.5 活动：执行单元测试
10.6 实现小结
10.7 参考资料

第11章 测试

11.1 引言
11.2 测试在软件生命周期中的作用
11.3 制品
11.3.1 制品：测试模型
11.3.2 制品：测试用例
11.3.3 制品：测试规程
11.3.4 制品：测试构件
11.3.5 制品：制定测试计划
11.3.6 制品：缺陷
11.3.7 制品：评估测试
11.4 工作人员
11.4.1 工作人员：测试设计人员
11.4.2 工作人员：构件工程师
11.4.3 工作人员：集成测试人员
11.4.4 工作人员：系统测试人员
11.5 工作流
11.5.1 活动：制定测试计划
11.5.2 活动：设计测试
11.5.3 活动：实现测试
11.5.4 活动：执行集成测试
11.5.5 活动：执行系统测试
11.5.6 活动：评估测试
11.6 测试小结
11.7 参考资料

第三部分 迭代和增量的开发过程

第12章 一般的迭代工作流

12.1 对平衡的需要
12.2 阶段是开发工作的第一次划分
12.2.1 初始阶段确立系统可行性
12.2.2 细化阶段关注“做的能力”
12.2.3 构造阶段建造系统
12.2.4 移交阶段转移到用户环境
12.3 再论一般的迭代
12.3.1 在每次迭代中重复的核心工作流
12.3.2 参与到工作流中的工作人员
12.4 计划先于行动
12.4.1 制定四个阶段的计划
12.4.2 制定迭代计划
12.4.3 长远考虑
12.4.4 制定评估准则
12.5 影响项目计划的风险
12.5.1 管理风险清单
12.5.2 影响迭代计划的风险
12.5.3 风险处理进度安排
12.6 用况优先级排序
12.6.1 针对特定产品的风险
12.6.2 没有正确获得构架的风险
12.6.3 没有正确获得需求的风险
12.7 所需要的资源
12.7.1 项目间存在广泛的差异
12.7.2 一个典型的项目
12.7.3 复杂项目具有更大的需要
12.7.4 新的产品线要求经验
12.7.5 资源消耗所需费用的支付
12.8 迭代和阶段的评估
12.8.1 没有达标时的处理
12.8.2 准则本身
12.8.3 下一次迭代
12.8.4 模型集的进化

第13章 初始阶段启动项目

13.1 初始阶段概述
13.2 初始阶段初期
13.2.1 初始阶段开始之前
13.2.2 制定初始阶段计划
13.2.3 扩展系统构想
13.2.4 设立评价准则
13.3 原型的初始迭代工作流
13.3.1 五个核心工作流引言
13.3.2 把项目融入到开发环境中
13.3.3 找出关键风险
13.4 执行五个核心工作流—从捕获需求到测试
13.4.1 捕获需求
13.4.2 分析
13.4.3 设计
13.4.4 实现
13.4.5 测试
13.5 构造初始业务案例
13.5.1 对业务标书的勾画
13.5.2 对投资回报的估计
13.6 评估初始阶段中的迭代
13.7 制定细化阶段的计划
13.8 初始阶段的可交付内容

第14章 细化阶段构造构架基线

14.1 细化阶段概述
14.2 细化阶段初期
14.2.1 制定细化阶段计划
14.2.2 组建开发组
14.2.3 改变开发环境
14.2.4 设立评价准则
14.3 原型的细化迭代工作流
14.3.1 捕获并细化绝大多数需求
14.3.2 开发构架基线
14.3.3 开发组较小时的迭代
14.4 执行五个核心工作流—从捕获需求到测试
14.4.1 捕获需求
14.4.2 分析
14.4.3 设计
14.4.4 实现
14.4.5 测试
14.5 产生业务案例
14.5.1 准备业务标书
14.5.2 更新投资回报
14.6 评估细化阶段的迭代
14.7 制定构造阶段计划
14.8 关键的可交付内容

第15章 构造阶段形成初步可运行能力

15.1 构造阶段概述
15.2 构造阶段初期
15.2.1 本阶段人员安排
15.2.2 设立评价准则
15.3 原型的构造迭代工作流
15.4 执行五个核心工作流—从捕获需求到测试
15.4.1 捕获需求
15.4.2 分析
15.4.3 设计
15.4.4 实现
15.4.5 测试
15.5 控制业务案例
15.6 评估构造阶段的迭代
15.7 制定移交阶段计划
15.8 关键的可交付内容

第16章 移交阶段完成产品发布

16.1 移交阶段概述
16.2 移交阶段初期
16.2.1 制定移交阶段计划
16.2.2 移交阶段人员安排
16.2.3 设立评价准则
16.3 核心工作流在本阶段中扮演了很小的角色
16.4 在移交阶段要干些什么
16.4.1 发行beta版本
16.4.2 安装beta版本
16.4.3 响应测试结果
16.4.4 让产品适应不同的用户环境
16.4.5 完成制品
16.4.6 项目什么时候结束
16.5 业务案例的完成
16.5.1 控制进度
16.5.2 业务计划的审查
16.6 评估移交阶段
16.6.1 对迭代和阶段的评估
16.6.2 项目的事后分析
16.7 制定下一版本或升级版本开发计划
16.8 关键的可交付内容

第17章 统一过程的运用

17.1 统一过程帮助你解决复杂性问题
17.1.1 生命周期的目标
17.1.2 生命周期的构架
17.1.3 可初步运行的能力
17.1.4 产品发布
17.2 主题
17.3 通过管理引导向统一过程的转化
17.3.1 行动案例
17.3.2 重建工程指南的宣传和贯彻
17.3.3 实现转变
17.4 统一过程专题
17.4.1 裁剪过程
17.4.2 填充过程框架
17.5 联系更广泛的社团
17.6 采用统一过程的好处
17.7 参考资料

附录A UML综述

A.1 引言
A.1.1 词汇
A.1.2 扩展机制
A.2 图符
A.2.1 结构类的事物
A.2.2 行为类的事物
A.2.3 分组类的事物
A.2.4 注解类的事物
A.2.5 依赖关系
A.2.6 关联关系
A.2.7 泛化关系
A.2.8 扩展机制
A.3 术语表
A.4 参考资料

附录B 针对统一过程的UML扩展

B.1 引言
B.2 构造型
B.3 标记值
B.4 图符
B.5 参考资料

附录C 常用术语

C.1 引言
C.2 术语

索引

xxq

有电子版吗？

ldwlqy

最初的帖子在 xxq
[B]有电子版吗？ [/B]

小希格玛

　　我们已经习惯于常常听到类似的故事：软件项目工期延迟，费用超支。甚至更为严重的情况是项目即使不被取消，最终的软件产品也不符合用户的期望。造成这种结果的原因，很大程度上不是技术原因，而是开发过程问题。 软件开发过程包括项目的开发阶段、开发方法、技术等方面的决策以及与软件及其相关工件（如项目计划、文档、系统模型、源码、测试用例和使用手册等）的开发和维护相关的一系列活动。软件开发机构不仅需要一个软件开发过程，更需要一个适合自己需求的软件开发过程。

　　目前业界领先的面向对象开发过程有Rational Unified Process (RUP) , OPEN 和 Object-Oriented Software Process (OOSP) 等几种。另外还存在一些考虑到特定开发队伍背景的过程，如改进的结构化开发模型、适用于小型团队开发的XP (eXtreme Programming) 的开发过程等。在软件开发实践中获得广泛成功的开发过程，都有下面几个特点：

强调早期就能确定或获得稳定的软件体系结构，从而降低系统开发风险；
以用例 (use case) 作为系统需求的核心表示，并驱动整个开发过程的完成，从而保证最终得到的系统正是用户真实所需要的产品；
采用增量式、迭代式开发，缩短产品投放市场的时间，并能适应需求变化的要求。
　　 UML作为面向对象系统建模语言的国际标准，得到了众多国际上顶级软件开发商和开发工具供应商的采纳。鉴于RUP对UML支持的紧密性（因为二者来源于同一个公司）以及Rational系列软件工程支持工具和环境在业界的领先地位，RUP得到了广泛的关注。

小希格玛

谁找到也给我一份

清水湾

最初的帖子在 小希格玛
[B]谁找到也给我一份 [/B]

小希格玛

你的图象好难看哦
瞪一双大眼干吗？

carechen

最初的帖子在 小希格玛
[B]你的图象好难看哦
瞪一双大眼干吗？ [/B]

我想他把你当成一条鱼了。

黑色领带

MAIL一份给我 ，好吗 ？[email protected]
或者在那里下载阿？？

guopapa

那里有下