以体系结构为中心的软件项目计划（ACSPP）是计划软件项目的一个重要软件开发方法。在管理项目时采用软件体系结构，开发人员将会更好地体验按时在预算内完成项目的胜利，并且有效地实现项目需求。本书说明为了获得最后成功，如何利用软件体系结构设计进度表、进行估算、确定范围和管理开发小组。本书介绍了有关有效进行项目管理的每一个环节：计划、组织、实现和度量。本书专为项目经理和软件架构师而著，同时也适用于希望对项目小组中的工作有更深刻了解的软件开发人员。以体系结构为中心的软件项目计划(ACSPP)是计划软件项目的一种重要软件开发方法。在管理项目时采用软件体系结构，开发人员将会更有可能成功地按时在预算内完成项目，并且有效地实现项目需求。
此书专为项目经理和软件架构师而著，说明了取得最后的胜利，如何利用软件体系结构设计进度表、进行估算、确定范围以及管理开发小组。本书介绍了有关有效进行项目管理的每一个环节：计划、组织、 实现和度量。作者Daniel J.Paulish对下列主题提供了大量实际的和基本经验的建议：
◆采用体系结构定义项日的组织结构 ◆制定项目决策
◆制定切实可行的进度表 ◆风险管理和避免令人不快的意外
◆采用项日和测试计划的全局分析 ◆定义项目的目标
◆管理期望和决定交付日期 ◆采用全局开发的体系结构
◆创建项目文化和高效的项目小组
此外，通过实例分析进一步说明了本书所介绍的策略、方法和技术，可以帮助读者全面地理解在
软件开发过程中所面临的挑战和困难，掌握如何利用以体系结构为中心的方法更容易地排除常见障碍。
Daniel J．Paulish博士现为西门子公司研究中心的软件项目经理，负责软件体系结构计划，在软件工程管理方面有20多年的经验。他倡导在软件项目管理、过程改进方法和度量方面融合各国文化，并在西门子公司的产品开发中采用以体系结构为中心的方法。他是《Software Metrics：A Practitioner'sGuide to Improved Product Development》(IEEE Computer Society Press，1993)一书的作者之一。
随着计算机硬件以日益低廉的价格提供越来越多的功能，对新的应用软件的需求也在不断地膨胀。万维网以前所未有的速度为更多的人提供越来越多的信息，软件产品也必须更快地开发，并使其具有更好的功能、性能和质量。对于开发新产品并维护现有产品的软件工程师们来说，压力在不断增加。
要求软件项目经理既要实现进度计划，又交付高质量的功能产品，对于那些试图在二者之间周旋的项目经理，本书提供了一定的支持。通过观察和参与很多软件开发项目，我的经验是：好的设计和项目管理技巧对于项目的成功大有帮助。如果软件体系结构没有很好地设计，或者缺乏项目管理技巧，那么项目不可能成功，这一点是非常清楚的。关于好的软件体系结构与好的项目管理之间的关系，我曾经观察了很多项目，希望这里提供的一些技巧能有助于得到更好的产品。
动机
作为一个产业，我们还未能非常成功地管理成功的软件项目。成功的项目是指达到计划的开发进度、提供承诺的功能并交付高质量软件的项目。根据1995年Standish Group CHAOS的报告，他们对软件项目的研究表明：16%的软件项目完全成功，31%的项目被完全取消，53%的项目严重超出预算、延期并交付少于预期的功能。到1998年，成功的项目增多了：26%完全成功，28%被完全取消，46%超过预算、延期和缺少功能[Johnson 1999]。因此，情况在不断地改进，但是，对于成功完成的软件开发项目，业界的记录依旧很糟糕。
背景
在西门子管理软件设计和开发项目的过程中，我积累了编写这本书的经验。作为西门子软件体系结构研发计划的一部分，调查了很多西门子的项目，以获知西门子的软件架构师是如何设计软件系统的。在这项研究中所得到的知识已包括在四视图体系结构设计方法中，正如Christine Hofmeister, Rod Nord, and Dilip Soni[2000]所著的《Applied Software Architecture》（应用软件体系结构）一书中所描述的。随着四视图方法的制定，我们有幸作为体系结构设计小组成员参与了为西门子各种商业领域设计产品。在某些情况下，我们还被委任来计划和管理这些新产品的开发，并实现体系结构的子系统或是构件。因此，我们的项目计划和管理方法是与四视图设计方法并行开发的。
体系结构设计方法与项目计划方法之间相关联的一个实例，就是以体系结构为中心的软件项目计划（Architecture-Centered Software Project Planning, ACSPP）方法，如在第2章中所描述的。我们采用这种方法，根据软件体系结构来估算开发项目的费用和进度。自从我们深入地介入了软件体系结构设计小组，我们就开始对项目计划与设计并行的优点确信不疑。我们还常常作为复查人员被请到西门子公司，在那里经常可以看到项目的警告标志，上面指明或是没有计划好，或是缺乏可以同复查人员或开发人员容易交流的软件体系结构。
与此同时，软件产品和成功的开发经验的重要性增加了。我们开始发现我们的项目计划和管理方法产生了巨大的商业影响，它们有助于软件产品更快上市，并更具有可预见性。因此，我们最初的研究兴趣更集中在设计方法和工具上，但是，我们也开始认识到好的项目管理对实现项目目标的重要性。
随着我们开始介入真正的设计和开发项目，我们认识到有效地应用我们的方法的关键在于项目经理和首席架构师之间的工作关系。在本书的第8章及Hofmeister, Nord, and Soni[2000]一书的第12章中分别描述了这些角色。当首席架构师和项目经理组成决策制定小组共同工作时，在特定的开发项目中，更容易引入和裁剪我所描述的方法。对于多人组成的开发队伍，如果试图由一个人承担两方面的责任，我们还需认识到可能产生的问题。
并不是本书中所介绍的所有项目管理的技巧都直接与体系结构设计有关。但是，很多是相关的，而且我认为，好的软件架构师需要懂得一些基本的项目管理技术，以便在由首席架构师和项目经理共同领导的开发队伍中获得成功。好的架构师主要参与制定技术决策，但他们也要对重大项目涉及的软因素做出评价。对于任何影响开发人员士气的决策，他们常常是项目经理的传声筒或是批评家。进一步说，我认为项目经理应该为首席架构师和整个开发队伍提供支持环境，使得好的设计经验能够得到一致的应用。
在业界实验室工作的最大好处是有机会同时进行研究和开发。以我的经验，我曾经有机会对诸如本书中所介绍的方法进行研究，而且我还有机会将这些方法应用于实际的项目中。其结果是，这些方法被融合在一起，变得非常实用，使得它们可以相对简单地加以应用。在这个过程中，我有机会设计、计划和开发西门子的软件产品，这些产品已成功地在市场上销售。我尽量在例子和实例分析中隐藏这些产品的本体，因为我通常描述的是现实世界中必须克服的问题。但实际上，应用这些设计和项目管理方法的产品，绝大部分已成功开发并进入市场。
我工作的项目大多是中等规模的，典型情况下，有10～20个软件工程师。由于经验有限，我不能声称这些项目管理的方法适用于非常大或是非常小的项目。再者，软件开发项目有可能延续一年以上，即使就我曾经参与过的项目类型而言，我的个人经验也很有限。在我解释各种技巧和方法时，出于方便，忽略了以上这些事实，而使这些方法和技巧仿佛是每一个项目经理都应该做的重要事情。尽管我讨论的方法有时看起来很不错，但没有“银弹”。对于你来说，需要以“超越信任”（leap of faith）的态度，来实践我所介绍的方法。不幸的是，这是大多数软件工程的一个固有问题，因为真正的实践非常有限。因此，这里介绍的技巧在本质上大多数变成轶事。
如何使用本书
本书的主要读者是软件项目经理，第二类读者是必须与项目经理密切合作的软件架构师，第三类读者是部分软件开发人员，他们希望对如何在项目小组中工作有更深刻的了解，或是也许考虑职业的改变，想加入前两类队伍。本书主要搜集了一些可以用于软件开发项目的技巧，每一种技巧都必须经过裁剪，以适应项目所在的特定环境。
这些技巧大致是按照项目经理将要参与的顺序组织的：计划、组织、实现和度量。不管怎样，并没有应用这些步骤的严格的顺序，因为这些管理任务将是循环反复的，直至产品发布。
一旦你读完介绍的资料（第一部分），最好或许是读本书的第二部分，尤其是第2章中关于以体系结构为中心的软件项目计划（ACSPP）的介绍。在你了解了项目进度估算所包含的步骤之后，可以阅读其他的章节。第六部分的实例分析应该最后读。根据你所开发的软件的类型，这些可能是你感兴趣的，也可能不是。在本书的其他部分也包含实例分析项目的例子。
在我所研究的软件体系结构这一领域，一个基本假设就是：体系结构是开发软件系统的关键。体系结构是实现商业目标、达到软件质量品质的基础。这引起了我对为提高质量而设计软件体系结构以及如何评估体系结构是否完全实现它的质量目标的兴趣。
但是，我发现这是一个以技术为中心的观点。如果说体系结构是实现系统所要实现的商业目标的核心，那么，体系结构也必须成为项目经理和软件架构师的工作核心。在本书中，Dan Paulish探究了体系结构成为项目经理工作核心的具体含义。我知道，体系结构是任务分解结构和工作分配的基础，但是，除了将开发过程中的各部分工作分配给开发小组并监督其工作之外，项目经理还必须承担更多的工作。
因为，正如Dan所言，“在缺少高层体系结构的情况下，工作的时间进度和工作量的估算是毫无价值的。”因此，在产生高层体系结构之前，项目经理必须处于其他业务的更高管理位置，他同时必须保证高层体系结构在特定的期限内产生。Dan介绍了实现上述目标的技术和经验。
他对估算的经验—项目开发时间的40%用于设计（最多用3个月的时间进行高层设计，剩下的用于低层设计）；20%用于编码；40%用于测试—需要在研究小组内着重强调。可以开发何种技术来调节高层设计，以减少对低层设计和测试的需要？我们为什么在编码技术上花如此大量的研究时间？
一旦制定了切实可行的进度计划，项目经理必须基于进度计划管理期望。进度计划可用于激励开发小组，因为他们拥有该计划，并对公司其他任务的计划提供了基准。对体系结构的纵向分块使得系统能够增量式地添加其他功能，并调整功能以适应各种版本。
Dan指出，正如体系结构体现了各种质量之间的权衡，进度计划也体现了交付时间、质量和功能之间的权衡。他建议向开发小组明确三者之间的优先级，并利用进度的压力来避免对质量和功能的过度的强调。也就是说，通过较短周期（8周）的增量式提交，有可能开发优先销售的功能，并选取在一次增量开发时间内那些以可接受的质量实现的功能。
进度表依赖于体系结构，而增量式提交依赖于进度表。这种控制是以体系结构为基础的软件开发的根本特性。
在很大程度上，体系结构设计的技术来自于现有的设计技术，评估体系结构的技术来自于现有的评估技术。同理，以体系结构为中心的项目管理技术也不是与现有的管理技术相脱离的。制定明确的进度表、得到股东的支持、确定切实可行的期望值、对员工的弱点感觉敏锐，并且在动荡中保持冷静，在任何环境中，这些都是好的项目经理应具备的素质。明确地了解这些是非常有用的。
我是Dan所提到的实例之一（DPS2000）的评估者。作为一个评估人员，看到系统发生的一切，我感到很有趣。作为一个咨询顾问，我经常会看到开发工作的冰山一角，但很难知道故事的结局。这就像读一本小说的中间段落，有人会告诉你故事是如何开始的，但是，没有人告诉你故事是如何结束的。尽管对于一些小说来说，知道这些就足够了，但对于另一些事情，我希望知道故事的结局。DPS2000系统的开发就是这样一个故事，情节很有趣，角色表现完美，因此，很高兴看到其结局。
对于Dan对管理国际开发小组的介绍，我也有同感。各个小组所在地点之间的时差常常是最小的问题。节日、假期以及不同的工作态度都是需要克服的问题，以保证成功地建立一支由国际成员组成的开发小组。
总之，如果体系结构是开发工作的核心，那么，项目经理必须以核心工作对待它，必须根据它来制定进度计划、进行估算、管理人员。确定项目管理的各个不同的侧面，并以生动、亲切的方式加以讨论，这使得我非常欣赏这本书，并从中大有收获。
Len Bass
CMU SEI高级研究员
软件体系结构权威
（美）Daniel J.Paulish：暂无简介
白晓颖 邵忠岿：暂无简介
第一部分 概 述
第1章 简介 3
1.1 什么是项目管理 3
1.2 什么是软件体系结构 4
1.3 核心信念 4
1.4 项目管理过程 5
1.5 以体系结构为中心的项目管理 5
1.6 计划 7
1.7 组织 8
1.8 实现 9
1.9 度量 10
1.10 小结 11
第二部分 计 划
第2章 以体系结构为中心的软件项目计划 15
2.1 制定切实可行的进度计划 15
2.2 方法 16
2.2.1 高层设计 17
2.2.2 自顶向下的进度表 19
2.2.3 自底向上的估算 20
2.2.4 版本发布计划 23
2.2.5 项目进度表 24
2.2.6 软件开发计划 26
2.2.7 个人进度表 27
2.3 优点 28
2.4 经验 28
2.5 经验数据 29
2.6 小结 30
第3章 全局分析 31
3.1 什么是全局分析 31
3.2 全局分析活动 33
3.2.1 组织的影响因素 36
3.2.2 技术的影响因素 36
3.2.3 产品的影响因素 36
3.3 对项目计划采用全局分析 37
3.3.1 项目策略决定 37
3.3.2 体系结构评估 38
3.3.3 风险分析 39
3.3.4 开发项目策略 40
3.3.5 全局分析和版本发布计划 40
3.3.6 全局分析和软件开发计划 41
3.4 对测试计划采用全局分析 42
3.5 优点 42
第4章 管理期望 43
4.1 何时计划及何时提交 43
4.2 向上的管理 44
4.3 横向的管理 46
4.4 信息流 47
4.5 采用软件开发计划 48
4.6 小结 48
第三部分 组 织
第5章 项目组织 53
5.1 利用软件体系结构定义项目组织 53
5.2 在开发过程中体系结构小组的角色 55
5.3 支持开发的项目功能 57
5.3.1 支持功能矩阵 57
5.3.2 权力 58
5.3.3 构造测试与质量保证 58
5.3.4 处理市场问题 59
5.3.5 构造师 60
5.4 责任、角色、权限和所有权 60
5.5 小结 61
第6章 全局开发 62
6.1 为什么需要全局开发 62
6.1.1 全局分析 62
6.1.2 组织的影响因素 63
6.1.3 设计策略 63
6.2 支持全局开发的体系结构 63
6.3 全局开发的开发过程 64
6.3.1 分布式项目管理 64
6.3.2 项目跟踪 65
6.3.3 配置管理 66
6.3.4 会议 66
6.3.5 分布式代码审查 67
6.3.6 节假日 69
6.3.7 出差旅行 70
6.4 多文化的不确定因素 70
6.5 对全局开发小组的建议 71
6.6 结论 72
第7章 建立项目文化和小组 74
7.1 确定项目目标 74
7.2 成功小组的特点 75
7.3 建立项目文化 76
7.3.1 信任、公开与交流 76
7.3.2 消除隔阂与文化差异 77
7.3.3 处理个性冲突 78
7.3.4 “恳谈”会 78
7.3.5 树立信心 79
7.4 收集和统一意见 80
7.4.1 体系结构 80
7.4.2 项目计划 81
7.5 确定指导工作的量 81
7.6 小结 83
第8章 软件项目经理的角色 84
8.1 建立一种理念 84
8.2 训练 85
8.3 决策 85
8.4 协调 86
8.5 与项目小组成员协同工作 86
8.5.1 与首席软件架构师协同工作 86
8.5.2 小组成员的角色 87
8.6 软件项目管理是一种职业 88
8.7 小结 89
第四部分 实 现
第9章 权衡与项目决策 93
9.1 根据项目目标制定决策 93
9.2 管理功能蔓延和体系结构漂移 93
9.2.1 功能蔓延 94
9.2.2 体系结构漂移 94
9.3 承担责任 95
9.4 何时接受或拒绝修改 96
9.5 项目经理制定道德方面的决策 97
9.6 小结 99
第10章 增量式开发 100
10.1 建立软件开发计划的基线 100
10.2 构造计划和管理 101
10.3 让每一个人都参与工作 102
10.4 跟踪工作进展 102
10.5 增量式测试 104
10.6 版本发布标准会议 104
10.7 工具 105
10.8 小结 106
第11章 创建可视性与避免意外 107
11.1 风险管理 107
11.2 交流项目进展和存在的问题 109
11.3 在管理层建立良好的信誉 110
11.4 认可并庆祝成功 110
11.5 小结 111
第12章 在激烈的竞争中保持冷静 112
12.1 鼓励、微观管理和纪律 112
12.1.1 鼓励 113
12.1.2 微观管理 113
12.1.3 纪律 113
12.2 保持乐观的态度 114
12.3 打质量牌 116
12.4 提供支持和清除障碍 116
12.5 处理问题职员 117
12.6 情绪化及其避免方法 117
12.7 提高工作生活的质量 118
12.8 小结 118
第五部分 度 量
第13章 需关注的度量 121
13.1 项目经理的全局度量标准 121
13.1.1 规模 121
13.1.2 进度偏离 122
13.1.3 生产率 122
13.1.4 缺陷 123
13.1.5 用户需求变更 124
13.2 高层设计的阶段度量标准 124
13.3 未完成的成本 125
13.4 工程预算 126
13.5 监视测试结果 127
13.6 小结 128
第14章 什么是“出色的工作” 129
14.1 在进度、功能和质量之间进行权衡 129
14.2 成功项目的定义 130
14.3 度量小组成员的贡献 131
14.4 奖励 131
14.5 员工更替 133
14.6 小结 133
第六部分 实例分析
第15章 IS2000 137
15.1 背景 137
15.2 系统概述 137
15.3 项目计划 138
15.3.1 高层设计 139
15.3.2 自顶向下的进度表 139
15.3.3 版本发布计划 139
15.3.4 自底向上的估算 139
15.3.5 项目进度表 140
15.3.6 软件开发计划 140
15.3.7 个人进度表 140
15.4 项目管理 141
15.5 经验总结 142
第16章 DPS2000 144
16.1 背景 144
16.2 全局分析 145
16.2.1 组织的影响因素 145
16.2.2 技术的影响因素 145
16.2.3 产品的影响因素 146
16.3 产品线设计策略 146
16.4 DPS2000体系结构 147
16.5 项目计划 149
16.6 项目管理 150
16.7 经验总结 151
第17章 总结 152
17.1 分享最佳实践成果 152
17.2 优点 153
17.3 小结 154
第七部分 附 录
附录 一些有用的表格 157
缩略词表 163
参考文献 165
