新書推薦：
《
法国通史（全六卷）
》
售價：NT$
4488.0
《
慢慢变富66招
》
售價：NT$
245.0
《
战国竹书复原综论
》
售價：NT$
449.0
《
走出内心的深渊：快节奏人群心理疾病与健康指南（原书第3版）
》
售價：NT$
352.0
《
如何成为一家千亿公司
》
售價：NT$
347.0
《
趋势跟踪： 汤姆·巴索的交易谋略
》
售價：NT$
352.0
《
滚滚红尘（《滚滚红尘》电影原著）
》
售價：NT$
250.0
《
罗马之变（法语直译，再现罗马共和国走向罗马帝国的辉煌历史）
》
售價：NT$
500.0
|
| 編輯推薦： |
作者史蒂夫·麦康奈尔（SteveMcConnell）是国际公认的软件开发大师，被誉为计算机软件工程和项目管理领域的权威。他是软件工程经典书籍的缔造者，代表作有《代码大全》《快速开发》《软件估算的艺术》《软件项目的艺术》《软件开发的艺术》以及《卓有成效的敏捷》等。他与比尔·盖茨和林纳斯·托瓦兹齐名，被《软件开发》杂志的读者评选为“软件行业三大影响力人物”。在软件行业，他担任过很多重要的职务，包括《IEEE软件》杂志总编辑及 IEEE计算机协会专委会主席等。
《软件项目的艺术》详细描述成功的项目管理模型和分阶段发布流程，旨在帮助读者找到改进的方向。书中以软件项目的分阶段发布流程为主线，系统介绍了软件项目管理理念、不同阶段、结构、方法和工具。
《软件项目的艺术》分为 4 个部分共 19 章。
第Ⅰ部分“项目生存思维”介绍了软件项目生存测试、生存概念以及生存的重要方法。
第Ⅱ部分“项目生存准备”介绍了为软件项目生存而战所需的准备，如初始计划、开发用户需求、质量保证、软件架构等。
第Ⅲ部分“阶段成功”主要讨论分阶段流程的具体活动，包括阶段计划、详细设计、软件构建、系统测试、软件发布和阶
|
| 內容簡介： |
作为《代码大全》的作者，史蒂夫在本书中全面深入地介绍了软件项目管理的关键技巧。《软件项目的艺术》分为4 个部分，共19 章，通过一个项目生存测试问卷来展示项目管理全过程中每个关键节点的具体行动。《软件项目的艺术》以项目成功为核心导向，系统地讲解项目立项、执行、开发、集成、测试与发布等关键环节，尤其适合项目经理及项目成员阅读和参考。
《软件开发的艺术》共包含4 部分21 章，探讨了软件行业中个人、组织以及行业的现状，解释了如何以工匠精神来打造自己的专业软件开发职业路线。《软件开发的艺术》对软件行业的所有从业人员有较强的参考性和指导性，适合富有开拓精神的企业和团队阅读。
|
| 關於作者： |
史蒂夫·麦康奈尔（Steve McConnell）
代表作有《代码大全》（2019年被《福布斯》技术委员会评为“软件开发奠基之作”）。先后创办Construx Software 和 Rain Dog（目前主要为客户提供投资规划和管理服务以及开发投资预测和分析工具）。
此前作为 Construx Software 创始人兼首席软件工程师，他负责领导软件项目，也为其他公司提供软件项目咨询服务，他还通过著书立说的方式， 成为软件工程知识体系的布道者。他是《IEEE软件》和《软件从业者》杂志的编委会成员、《IEEE计算机》杂志资深审稿人、IEEE 计算机协会及 ACM 的重要贡献者。
作为社区与公共事务的积极参与者，他担任过贝尔维尤学校董事会主席、贝尔维尤扶轮社主席、洛克利文社区协会董事会成员、CDC Covid 预测模型的贡献者、IEEE专委会主席、《IEEE软件》杂志主编、软件工程知识体系专家组成员，惠特曼文理学院和西雅图大学计算机科学顾问委员会成员。
史蒂夫在惠特曼文理学院获得哲学和计算机科学的双学士学位，在西雅图大学获得了软件工程硕士学位。
方敏
就职于微软公司，担任首席测试总监期间，对必应搜索、中国创新项目、WindowsServer、SQLServer、COM 服务等产品和服务做出了重要的贡献。他拥有近三十年工程技术团队和项目管理经验，精通软件敏捷开发和传统软件项目管理。他注重创新，注重发挥团队优势。
方敏是微软美国华人协会的创始成员之一，该协会有几千名会员。他是美国西雅图地区知名的职场发展专家，热衷于提升在美华人的国际竞争力。曾经多次受邀为母校清华大学举办国际化职场发展和软件技能讲座。方敏毕业于清华大学，获得电子工程学士和硕士学位，后来在美国新墨西哥州矿业技术学院获得计算机科学硕士学位。
朱嵘
朱嵘早年就职于英国BAE系统公司，在其美国分支机构担任质量工程师，负责空客和波音多种机型的关键质量分析与故障维修。她毕业于哈尔滨工业大学，获得无线电工程系信息工程专业的学士学位。
|
| 目錄：
|
软件项目的艺术
详细目录
第Ⅰ部分 项目生存思维
第1章 欢迎加入项目生存训练营 3
1.1 生存需求 4
1.2 生存权利 7
1.3 生存检查清单：项目健康测试 9
生存检查清单 10
译者有话说 10
第2章 软件项目生存测试 11
2.1 生存测试题 11
2.2 生存测试问卷 11
2.2 生存测试问卷 12
2.3 生存测试结果解释 14
生存检查清单 16
译者有话说 16
第3章 项目生存的概念 17
3.1 软件开发流程的作用 17
3.1.1 对流程的误区 18
3.1.2 拯救流程 23
3.1.3 流程与团队的创新和士气 25
3.1.4 过渡到系统化流程的理由 27
3.2 流程的上游和下游 28
3.3 不确定性锥 30
生存检查清单 33
译者有话说 34
第4章 项目生存的关键方法 35
4.1 规划 35
软件规划示例 37
4.2 规划检查点的审查 38
4.2.1 两阶段筹资方法 38
4.2.2 准备规划检查点的审查 39
4.2.3 规划检查点审查议程 40
4.2.4 规划检查点审查的主要意义 41
4.3 风险管理 42
4.4 项目控制 43
4.5 项目的可见性 44
4.6 人件 45
4.6.1 开发人员的兴趣与工作分配要对齐 46
4.6.2 向开发人员表达诚挚的谢意 47
4.6.3 提供有利于思考的办公空间 47
4.6.4 避免开放式工作空间 47
4.7 用户参与 49
4.8 产品极简主义 51
4.9 专注于软件交付 52
生存检查清单 54
译者有话说 55
第5章 成功的软件项目知多少 57
5.1 研发阶段 57
5.2 项目流程 59
5.3 分阶段交付的好处 60
5.4 分阶段交付的成本 63
5.5 阶段计划 64
5.6 团队建设 66
5.7 代码量增长曲线 69
5.8 主要里程碑和可交付内容 71
生存检查清单 77
译者有话说 77
第Ⅱ部分 项目生存准备
第6章 拥抱变化，精准定位 81
6.1 变更控制过程 81
6.2 变更控制的好处 84
6.3 自动修订控制的好处 85
6.4 常见的变更控制问题 86
6.4.1 如何考虑变更 86
6.4.2 何时考虑变更 87
6.4.3 如何处理小的变更 88
6.4.4 如何进行人员管理 88
6.4.5 哪些工作产品要进行变更控制 89
6.5 致力于变更控制 91
生存检查清单 92
译者有话说 93
第7章 初步计划 95
7.1 项目愿景 95
7.1.1 定义要放弃的内容 97
7.1.2 致力于愿景 98
7.2 高管授权 98
7.3 项目规模目标 99
7.4 宣传计划和进展 101
7.5 宣传进度指标 102
7.6 风险管理 104
7.6.1 致力于风险管理 105
7.6.2 风险监督员 107
7.6.3 十大风险清单 108
7.6.4 支持风险跟踪的工具 112
7.6.5 详细的风险管理计划 112
7.6.6 匿名风险报告渠道 112
7.7 人员策略 114
7.7.1 人才发展 114
7.7.2 团队培养 115
7.7.3 新手开发人员：可用与胜任 115
7.7.4 团队动态 116
7.7.5 员工培养的关键问题 117
7.7.6 团队组织 117
7.7.7 项目团队的组织结构 118
7.7.8 “老虎队” 120
7.8 时间统计 121
7.9 软件开发计划 125
生存检查清单：初步计划 126
译者有话说 127
第8章 需求开发 129
8.1 需求开发流程概述 130
8.2 确定一组关键的最终用户 131
8.3 采访最终用户 132
8.4 构建简单的用户界面原型 132
8.4.1 如果条件允许，应使用情节串连故事板 134
8.4.2 不断修改原型直到最终用户对软件感兴趣 135
8.4.3 制定用户界面样式指南 136
8.4.4 全面扩展原型 136
8.4.5 请记住，原型是要废弃的 137
8.4.6 将全面扩展的原型作为基准规范 138
8.5 编写详细的最终用户手册 139
8.6 创建单独的、没有用户界面的需求文档 141
生存检查清单：需求开发 141
译者有话说 143
第9章 质量保证 145
9.1 为什么质量很重要 145
9.2 质量保证计划 146
质量保证计划的组成部分 147
9.6 缺陷跟踪 149
9.4 技术审查 151
9.4.1 常规审查模式 151
9.4.2 成功审查的要点 152
9.5 系统测试 154
9.6 Beta测试 157
9.7 质量保证计划涵盖的工作产品 160
9.8 质量保证的辅助活动 162
9.9 软件发布标准 162
生存检查清单 163
译者有话说 164
第10章 软件架构 165
10.1 启动架构阶段 166
10.2 好的架构有哪些特征 167
10.2.1 系统概述 167
10.2.2 概念的完整性 167
10.2.3 子系统和组织 168
10.2.4 表示法 170
10.2.5 适应场景变化与调整策略 171
10.2.6 分析可重用性，决定购买还是自己动手写 172
10.2.7 常用功能领域的策略 172
10.2.8 需求的可追溯性 174
10.2.9 支持分阶段交付计划 175
10.3 如何判断架构已完成 175
10.4 软件架构文档 176
生存检查清单 177
译者有话说 178
第11章 最后准备 179
11.1 项目估算 180
11.1.1 估算过程指南 180
11.1.2 里程碑目标 185
11.1.3 非技术性的估算考虑 186
11.2 分阶段交付计划 187
11.2.1 将项目划分为阶段 188
11.2.2 阶段主题 189
11.2.3 与分阶段交付相似的计划 191
11.2.4 发布版本 192
11.2.5 修订分阶段交付计划 193
11.3 持续进行规划活动 193
11.3.1 风险管理 194
11.3.2 项目愿景 194
11.3.3 决策机构 195
11.3.4 人员 195
11.3.5 更新软件开发计划 196
生存检查清单 196
译者有话说 197
第Ⅲ部分 阶段成功
第12章 阶段计划 201
12.1 为什么需要制定阶段计划 201
12.2 阶段计划介绍 203
12.2.1 需求更新 204
12.2.2 详细设计 204
12.2.3 软件构建 205
12.2.4 产生测试用例 205
12.2.5 用户文档更新 206
12.2.6 技术审查 206
12.2.7 修正缺陷 206
12.2.8 技术协调 207
12.2.9 风险管理 207
12.2.10 项目跟踪 208
12.2.11 集成和发布 208
12.2.12 阶段结束总结 209
12.3 微型里程碑 209
12.3.1 创建完整的里程碑列表 211
12.3.2 达到预期质量水平 212
12.3.3 定义微型里程碑 213
12.3.4 小型项目的微型里程碑 213
12.3.5 人员管理的考虑 214
12.3.6 项目如果错过了微型里程碑，怎么办 215
12.4 阶段计划和管理风格 216
生存检查清单 217
译者有话说 218
第13章 详细设计 219
13.1 重新审查架构 219
13.1.1 程序组织 219
13.1.2 分析重用 220
13.1.3 需求的解决方案 220
13.1.4 需求的可追溯性 220
13.1.5 软件构建计划 221
13.1.6 修正架构中的缺陷 221
13.1.7 项目需要做多少详细设计 221
13.2 技术审查 224
13.2.1 检测功能缺陷 225
13.2.2 检测需求缺陷 226
13.2.3 缺失需求 226
13.2.4 不需要的功能 227
13.2.5 审查项目目标 228
13.2.6 交叉培训 229
13.2.7 审查和生产力 230
13.3 详细设计文档 230
13.4 项目第一阶段的特殊考虑 231
生存检查清单：详细设计 232
译者有话说 234
第14章 软件构建 235
14.1 源代码质量 236
14.1.1 编程标准 236
14.1.2 项目目标 238
14.1.3 简洁 239
14.2 软件集成流程 239
14.2.1 完成意味着彻底完成 240
14.2.2 为其他开发人员提供稳定的基础 242
14.2.3 每日构建和冒烟测试 242
14.2.4 第一阶段的特殊考虑 245
14.2.5 避免过早开发基础设施 246
14.3 跟踪进度 246
14.3.1 收集状态信息 247
14.3.2 可见性 247
14.3.3 每周项目跟踪更新 248
14.3.4 与客户和上层管理人员沟通 249
14.4 控制变更 249
14.5 保持专注 251
14.6 软件构建是不是只有这些事儿 251
生存检查清单：软件构建 253
译者有话说 254
第15章 系统测试 255
15.1 测试的哲学 255
15.2 系统测试范围 257
15.3 测试组对每日构建的支持 257
15.4 开发人员对系统测试的支持 258
15.5 QA策略 259
生存检查清单：系统测试 259
译者有话说 260
第16章 软件发布 261
16.1 认真对待发布 261
16.2 何时发布 263
16.2.1 缺陷计数 264
16.2.2 统计每个缺陷的工作量 265
16.2.3 缺陷密度预测 265
16.2.4 缺陷集 267
16.2.5 缺陷播种 268
16.2.6 缺陷建模 270
16.2.7 软件发布决定 271
16.2.8 缺陷跟踪和宣传 272
16.3 发布清单 272
16.4 批准发布签字 275
生存检查清单：软件发布 277
译者有话说 278
第17章 阶段结束 279
17.1 举行变更委员会大型会议 280
17.2 重新校准估算 280
17.2.1 重新估算生产效率 281
17.2.2 “重新估算”还是“失误” 283
17.3 根据项目计划评估绩效 284
17.4 项目文件归档 285
17.5 更新软件项目日志 286
生存检查清单：阶段结束 287
译者有话说 288
第Ⅳ部分 项目完成
第18章 项目历史 291
18.1 收集项目数据 291
18.1.1 项目回顾会议 292
18.1.2 项目回顾调查问卷 292
18.2 软件项目历史文档 293
18.3 为未来项目准备项目历史结论 295
18.4 分发软件项目历史副本 296
生存检查清单：项目历史 296
译者有话说 297
第19章 项目生存急救包 299
19.1 NASA成功法则 299
19.1.1 项目取得成功的关键 300
19.1.2 绝对不做的事情 302
19.2 其他项目生存资源 303
19.2.1 书籍 304
19.2.2 互联网资源 307
结语 309
参考文献 310
软件项目术语表 311
软件开发的艺术
详细目录
第Ⅰ部分 软件“焦油坑”
第1 章 与恐龙搏斗 3
译者有话说 6
第2 章 假黄金 7
移动巨石 8
巨石和软件 10
边做边改的编程模式 11
注重质量 15
银弹造成的假象 17
软件不“软” 19
如何识别假黄金 21
译者有话说 22
第3 章 货物崇拜与软件工程 25
软件开发的效仿者 26
货物崇拜式的软件工程 28
真正的辩论 28
译者有话说 30
第4 章 软件工程不是计算机科学 31
“是”与“应该是” 32
工程与科学 33
抛开表面，审视实质 35
正确的问题 38
译者有话说 38
第5 章 软件工程知识体系 41
本质性与附属性 42
定义稳定核心 44
软件工程知识体系 47
树立里程碑 52
译者有话说 53
第6 章 软件新世界 55
职业定义 57
探索软件工程职业 58
穿越赫拉克勒斯神柱 64
译者有话说 65
第Ⅱ部分 个人专业化
第7 章 人尽其才 69
MBTI 人格测试 70
软件开发人员的MBTI 测试结果 71
伟大设计师的人格特征 73
全面和绝对的承诺 75
软件人口统计 77
教育 79
工作前景 80
编程高手和问题成员 82
关注人性 83
译者有话说 84
第8 章 提高软件意识水平 87
软件意识分级 88
对症下药 90
你有经验吗 91
译者有话说 92
第9 章 建设软件社区 93
译者有话说 97
第10 章 建筑师和木匠 99
职称分级 99
职业专业化 101
团队专业化 104
时间将会给出答案 105
译者有话说 105
第11 章 经验是写作的基础 107
译者有话说 112
第Ⅲ部分 软件组织专业化
第12 章 软件淘金热 115
软件淘金热 116
后淘金热时代的发展 118
淘金经济学的思维和不解 120
向上扩展和向下扩展 121
回到淘金热 122
译者有话说 123
第13 章 优秀软件实践案例 125
实际状况 126
软件实践改进后的收益 127
不同方法的投资回报率 130
了解软件估计 131
改进软件带来的间接效益 132
最佳的规模经济 133
软件组织的挑战 134
迈出关键的一步 135
10 个棘手的问题 135
译者有话说 136
第14 章 托勒密推理 139
SW-CMM 概述 140
提高成熟度级别 142
可以处理的所有风险 144
哪些人在用SW-CMM 145
完美兼顾软件开发 146
认真的承诺 148
组织评级 148
形式和本质 150
译者有话说 151
第15 章 量化人员因素 153
人员因素 153
低效率开发人员 155
具体工作环境 157
工作动机 157
资深员工的价值 159
重要的关注点 159
译者有话说 160
第16 章 Construx 专业发展体系 161
Construx 知识领域 163
能力水平 164
专业发展阶梯等级 166
职业发展阶梯 168
不同能力水平的CKA 要求 171
专业发展阶梯的经验教训 175
专业发展阶梯的优势 179
推广Construx 专业发展阶梯 180
译者有话说 181
第Ⅳ部分 行业专业化
第17 章 专业工程 185
我们需要工程 186
工程与艺术 187
工程学科的成熟过程 190
软件开发的科学 192
软件工程的责任 194
译者有话说 194
第18 章 软件工程历练 197
专业工程师的发展 201
第一步 202
学术认证 204
软件工程教育的差异 205
继续教育 207
一些观点 208
译者有话说 209
第19 章 证书的意义 211
认证 211
许可证 213
软件工程师可以获得许可证吗 215
许可证制度好吗 218
许可证的起步 221
获得证书的优势 223
获得证书 225
三条路径 225
铁戒指的意义 228
译者有话说 228
第20 章 职业道德准则 231
软件工程师的道德准则 232
道德准则的必要性 235
学习不能停的时代 238
译者有话说 238
第21 章 慧眼识珠 241
为什么需要技术转化 242
创新的传播 243
鸿沟 245
一些棘手的问题 246
风险在哪里 248
分级推广代理 250
站在巨人的肩上 253
译者有话说 254
|
| 內容試閱：
|
软件项目的艺术
在2000年左右，美国约有200万人参与了约30万个软件项目。这些项目中，有三分之一到三分之二在交付之前进度延后和预算超支。在最昂贵的软件项目中，约有一半因失控而被取消。还有更多的项目被弃如敝屣，未能实现其最初的目标和价值，或者因为赞助方遇到麻烦，仅是宣布项目成功便退出了项目，而没有留下任何可用的软件。无论是高级经理、高管、软件客户、用户代表还是项目负责人，都可以通过本书了解如何防止项目遭受这些后果。
软件项目失败通常有两个原因：项目团队既缺乏成功开展软件项目的知识，也缺乏有效开展项目的方案。本书虽然对解决方案帮助不大，但确实包含了成功开展软件项目所需要的大量知识。
软件项目的成功并不取决于专门的技术。有时软件项目被视为一个神秘的实体，其生存或消亡完全取决于开发人员的专业技术。当开发人员解释为何延迟交付组件时，他们可能会使用一些技术术语，让没有深度技术知识的人感到无法影响软件项目。
《软件项目的艺术》指出，软件项目的成功或失败取决于如何谨慎地规划项目以及如何精细地执行项目。如果项目的利益相关方了解决定项目成功的关键问题，就可以确保项目取得圆满成功。保持软件项目朝着正确方向前进的人可以是技术经理或软件开发人员，也可以是高级经理、客户、赞助方、终端用户代表或任何其他相关人员。
本书适用于影响软件项目结果的任何人，包括高层经理、行政主管、客户、投资人和最终用户代表。通常，非软件人员可能会被指派监督软件产品的开发，他们可能具有销售、会计、财务、法律、工程或其他领域的背景。如果项目开始出错，他们至少应发出警告。本书以通俗易懂的方式向他们讲述一个成功的项目应该是什么样的，并提供许多方法来提前判断项目的成败。
对于项目经理，尤其是那些没有经过专门软件项目管理培训的，本书将帮助你掌握需求管理、软件项目规划、项目跟踪、质量保证和变更控制等关键技术和管理技能。
对于技术主管、专业开发人员和自学成才的程序员，如果你是熟悉技术细节的专家，可能没有经历太多项目负责人需要关注的重大问题。本书可以视为带注释的项目计划，帮助你从专业技术人员过渡到高效率的项目负责人。书中描述的计划可以作为起点，根据特定项目的需要，合理地制定自己的项目策略。如果已经读过《快速开发》一书，本书的第Ⅰ部分将帮助你复习其中的部分内容。
本书涉及哪些类型的项目
本书的项目计划适用于商业系统、广泛的终端用户软件、垂直市场系统、科学系统等程序。该计划适用于客户端/服务器结构的项目，使用了现代软件开发实践，例如面向对象的设计和编程。这些计划可以很容易地应用于传统开发实践和大型计算机项目。
该计划面向的团队规模为3到25名成员，项目计划时间为3到18个月，这种规模的项目被认为是中型项目。如果你的项目比较小，可以适当精简本书推荐的一些做法。在整本书中，我会指出可以精简的地方。
本书主要面向目前处于规划阶段的项目。如果项目刚刚开始，可以使用该方法作为项目计划的基础。如果项目正处于中间阶段，第2章的生存测试和每章末尾的生存检查清单将帮助你确定项目的成功机会。
本书的计划可能不够正式或不够严谨，因此不适用于生命攸关或安全攸关的系统。但它适用于商业应用程序和商业软件，在许多数百万美元级别的项目中采用了这样的计划，已经取得了显著的改进。
资深技术型读者注意事项
《软件项目的艺术》介绍了执行软件项目的有效方法，但并不是唯一有效的方法。然而，知识渊博的技术主管提出的开发计划可能会比这里描述的通用解决方案更好、更全面、更有针对性。但是，这里描述的计划比匆忙凑出来的计划或者根本没有计划的情况要好得多，软件项目根本没有计划是最常见的状况。
以下章节描述的计划是为了解决软件项目面临的最常见问题而设计的。它大体上基于软件工程协会（SEI）所定义的SEI软件能力成熟度模型的第2级中的“关键过程领域”。SEI已将这些关键过程确定为使软件组织能够满足计划、预算、质量和其他目标的关键组成部分。大约85%的软件组织的绩效低于2级，我们的计划是指导这些软件组织明显地改进它们的现有状态。SEI如下定义第2级的关键流程领域：
项目计划；
需求管理；
项目跟踪和监督；
配置管理；
质量保证。
本书的主要参考资料
在撰写本书时，除了汲取众多资源之精华，我还珍藏了三个举足轻重的参考资料，它们无一不是价值连城的宝典。我试图从中去芜存菁，条分缕析，将其中的精华以最实用的方式呈现给大家。
第一份参考文献是软件工程研究所的《软件能力成熟度模型的关键实践》版本1.1（以下简称《关键实践》）。此书堪称一座金矿，来之不易的行业经验深藏其中，为新开发实践的实现确定了优先级的指导。尽管文献篇幅近500页，书中的信息却言简意赅。它不同于一般的教科书，对新手而言可能稍显晦涩。然而，对于已对其实践有所了解的读者来说，《关键实践》提供的总结和结构无异于指路的明灯。本书可在互联网上免费获取，网址为 http://www.sei.cmu.edu/，也可从弗吉尼亚州斯普林菲尔德的美国商务部国家技术信息服务中心获得。
第二份参考文献是美国国家航空航天局（NASA）的软件工程实验室（SEL）的《推荐的软件开发方法》（修订版3）——以下简称《推荐方法》。SEL荣获IEEE计算机学会颁发的过程成就奖，实至名归。《推荐方法》详细地描述了许多成功过程的关键因素，与SEI的文档相辅相成，后者虽描述了一套实践却未展示其在特定项目中的应用。可以从https://ntrs.nasa.gov/api/citations/19930009672/downloads/19930009672.pdf下载。
我手边最后一份参考资源是我的亲身实践。我的写作不追求空中楼阁式的理论架构，而是从实用的角度出发，致力于为读者打造一个实用性较强的参考指南。这里汇总的信息将使我在未来项目规划与实施上游刃有余，并向客户清晰阐释关键的成功因素。我期望本书能为读者带来这样的帮助。
软件开发的艺术
说起来容易，做起来难，总有一些事情如此。
——《IEEE 软件》
记得有一次，我们乘坐的飞机正在跑道上等待起飞，突然听到机长紧急播报：“飞机的空调系统有问题，无法向机舱正常供氧，我们需要在起飞之前确保空调系统能够恢复正常。我刚刚尝试了重启空调系统，但没有成功，现在必须重新启动整个飞机系统。众所周知，现代飞机由计算机控制，是不太靠谱的。”
飞机熄火，重新启动。随后，我们的航班顺利起飞了，没有发生任何异常。最后飞机落地，走出机舱的那一刻，我悬着的心终于放了下来。
这是一个最好的时代，也是一个最坏的时代。
优秀的软件组织能够有效控制项目，以达到既定的质量目标，并准确预测软件的交付时间，不论是年份还是月份。他们能在预算范围内完成软件项目，不断提升生产力，保持员工士气高涨，让客户非常满意。
● 一家电信公司需要修改大约3 000 行代码，而整个代码库大约有100 万行。他们需要小心翼翼地进行修改，确保至少一年内不会出现任何错误。他们总共花费了9 个小时来完成所有工作，包括需求、分析、设计、实现和测试。
● 一个为美国空军开发软件的团队承诺只需要1年时间和200万美元预算就能完成项目，而另一个知名团队对这个项目的报价却高达2 年和1 000 万美元。当低价中标的项目团队提前一个月交付项目时，项目经理透露了一个关键信息：团队的成功主要得益于使用了一种已存在多年但并不常用的技术。
● 一家航天公司采取固定价格合同策略为其他企业开发商业软件，结果表明，只有3% 的项目超出预算，97% 的项目都成功控制在预算之内。
● 一家致力于实现卓越品质的软件公司连续9 年每年平均产品缺陷率降低39%，累计减少99% 的缺陷率。
除了这些成功案例外，软件行业在经济上每年仍为全球带来超过10 亿美元的额外收入，无论是通过软件销售直接获得，还是间接通过提高效率和创造与软件相关的产品与服务实现。
创建良好软件所需的实践已经确立了，并且可以在今后的10 年至20 年或更长时间里使用。虽然某些项目取得了卓越成就，但软件行业整体未能充分挖掘出软件的全部潜力。平均项目水平与顶尖项目水平之间存在巨大差距，许多领域的软件实践要么严重过时，要么不够高效。软件项目的平均表现远远达不到预期，看看下面这些知名的失败案例。
● 美国国税局（IRS）在其软件现代化项目上浪费80 亿美元，导致美国纳税人每年损失高达500 亿美元。
● 美国联邦航空管理局的高级自动化系统计划的预算超支30 亿美元。
● 行李处理系统的问题导致丹佛国际机场的开放时间推迟了一年多。据估计，延误造成的损失高达每天110 万美元。
● 阿丽亚娜5 号火箭因为1 个软件错误导致火箭在首次发射时爆炸。
● B-2轰炸机（译注：这样的战略轰炸机最大起飞重量接近170 吨，但只有0.1 平方米的雷达反射面积，大小相当于普通鸟类。B-2 在设计上使用了诸多先进的隐身技术手段，如锯齿边缘的机翼和尾翼、特殊涂料吸收雷达波等。在作战能力方面，B-2 也具备长时间独立作战能力，其最大载弹量达20 吨，不加油的情况下作战半径可达1.2 万千米。如果可以进行一次空中加油，其作战半径将大幅提升至1.8 万千米，差不多可以覆盖全球大部分区域。此外，B-2 还配备了当时最先进的电子设备，如相控阵雷达、综合电子战系统等，因而可以在复杂环境下有效地执行任务。B-2 参与过多场实战考验，均保持零损失的记录。）因软件问题而未能按时执行首飞。
● 西雅图渡轮的计算机系统故障导致了十几次的码头碰撞，造成的损失超过700 万美元。华盛顿州计划投资超过300 万美元，将渡轮的自动控制系统改回手动控制。
● 虽然很多项目没有发生重大失误，但仍然引发了诸多问题。大约25% 的软件项目彻底失败，12 而项目在被取消时一般已经多花了一倍的预算，约50% 的项目经历了延期、超预算或被迫缩减功能。
在企业层面，这些失败的项目意味着巨大的机会损失。想象一下，如果在只花费了10% 的预算而不是200% 的预算时就能够识别出那些最终会失败的项目并提前砍掉它们，让公司把这些资源重新分配给那些有潜力成功的项目上。
在国家层面，这些被叫停的项目意味着巨大的浪费。粗略估计，这样的软件项目给美国经济造成了400 亿美元的损失。
即使项目成功，仍然可能给公共安全或公共福利带来风险。莲花（Lotus）公司的项目负责人曾经接到一位外科医生的电话，说他当时正在进行心脏手术，需要使用电子表格来分析患者数据。《新闻周刊》发表过一张照片，显示战场上的士兵们使用Excel 来规划军事行动。微软公司的Excel 技术支持团队确实接到过士兵们从前线打来的电话。
本书的目的
软件开发应该是可预测、可控制、经济上可行且可以管理的。通常，软件开发通常不会以满足这四个要求为目标，但它有潜力同时满足这些要求。本书主要聚焦于软件工程这一新兴行业的发展，探讨如何建立高效且经济的专业软件开发实践。
本书讨论了以下几个主题：
● 什么是软件工程？
● 软件工程与计算机科学有何关系？
● 为什么传统的计算机编程不够好？
● 为什么我们需要软件工程这一职业？
● 为什么要为软件开发专业设计最佳模型？
● 不同的项目或公司在采纳成功策略上存在哪些差异与共性？
● 软件组织可以采取哪些措施来支持专业软件开发方法？
● 软件开发人员如何成长为成熟的专业人士？
● 软件行业应该如何建立真正意义上的软件工程职业发展路线？
本书的组织
本书将从当前计算机编程实践的现状出发，逐步过渡到探索未来可能出现的软件工程职业。
第Ⅰ部分“软件‘焦油坑’”将阐述软件领域是如何发展到现在这种状态的。显然，软件领域的现状受到多种因素的影响，我们需要充分理解这些因素，从而促进而不是阻碍软件项目的革新，让人们主动为项目的成功而努力。
第Ⅱ部分“个人专业化”将介绍个人层面上可以采取哪些行动来进一步提高个人的软件专业化水平。
由于软件项目的复杂性，许多关键因素无法仅通过个人努力有效解决。第Ⅲ部分“软件组织专业化”深入讨论了实现软件项目专业化的实践方法。
第Ⅳ部分“行业专业化”将探讨整个软件行业必须采取哪些措施来推动个人层面和组织层面的专业化进程。
自1999年以来，我学到了什么
我从1999 年以来获得了下面这些经验教训。
● 对软件开发人员实行许可证制度的提议引发的争议远超我的预期。我依然认为，对一小部分软件工程师进行认证，是保护公众安全和福祉的重要步骤。我曾经试图解释，许可证是改善软件开发专业水平所需要的许多举措之一，但它不是最重要的。
● 软件工程师的培训不必与许可证申请紧密关联。在本科和研究生的教育课程中，可以培养软件开发人员的工程思维，但不必强迫他们成为持证专业工程师。事实上，如果只有不到5% 的软件开发人员需要获得许可证，那么将大部分教学的焦点集中在许可证上似乎不太合适。
● 当2000 年1 月1 日来临时，世界并未陷入混乱。尽管我不曾认为千年虫（Y2K，即日期从两位数扩展到四位数，比如从99 变为1999）会引发灾难，但我确实认为，解决Y2K 问题的过程比这个问题本身更重要。软件行业采取的补救措施比我预期的更有效。除此之外，Y2K 问题在某种意义上是软件成功开发实践的结果。如果有这么多软件系统的生命周期都超过预期，那么Y2K 一开始就应该成为问题。
● 现代软件开发在许多方面所取得的成果令人印象深刻，在讨论软件领域的专业化时，我们不应忘记领域内的众多成功案例。
我们必须留意，在改善那些有缺陷的做法时，不应该一并舍弃那些已被证明有效的方法。
谁应该阅读这本书
如果你以开发软件为生，可以通过本书了解如何才能成为一名真正的专业软件开发人员。
如果你是软件项目的管理者，可以通过本书了解好项目和不成功的项目之间的区别，探讨如何才能成功完成项目。
如果你是软件企业的管理者，可以通过本书了解系统化的软件开发方法有哪些好处以及如何获得这些效益。
如果你是一名希望在软件领域工作的学生，可以通过本书了解软件工程领域的知识体系，以及软件工程领域的职业前景。
软件开发的专业化
行业研究人员通过长期以来的观察发现，在同一行业内，不同组织的生产效率有高达10 倍的差异。最近的研究甚至显示，这种差异可能高达惊人的600 倍。18 那些最高效的软件组织的确表现优异。
真正的软件工程专业化所带来的好处是不言而喻的。传统观点认为，任何变化都伴随着巨大的风险。然而，在软件领域，最大的风险实际上是保持不变，并继续固守不健康的高成本开发实践，而不是开始采用那些多年前就已被证明更加有效的实践方法。
应该如何改变呢？这正是本书剩余部分的核心主题。
编注：为了方便广大读者进一步查阅和拓展相关资源，我们对本书英文版中的所有原文注释进行了统一处理。大家可以扫描二维码，查看和下载全书的所有注释。
|
|
購物車/收銀台(0) | 在線留言板
| 付款方式
| 聯絡我們
| 運費計算
| 幫助中心 |
加入書簽
HOME
新書上架
