本书展示了系统设计和项目设计的结构化工程方法。本书的结构反映了方法论的两个部分：系统设计（通常称为架构）和项目设计。这两部分相辅相成，是成功的必要条件。附录提供了一些补充内容。
在大多数技术书籍中，每一章只针对一个主题并深入探讨，这样更容易编写，但这通常不是人们学习的方式。相比之下，在这本书中，讲解是螺旋式的。本书的两大部分中的每一
章都重申了前几章的观点，通过多方面的洞察来进行更深入的研究或观点的演进。这模仿了自然的学习过程，每一章都依赖于前面的章节，所以你应该按顺序阅读这些章节。本书的两大部分均包含了详细的案例研究，以展示这些观点以及其他方面。同时，为了保持迭代的简洁性，作为一般规则，我通常避免内容重复，因此即使是关键知识点，也只讨论一次。
以下是对各章和附录的简单介绍：
第1章 元设计方法
本章介绍了下列关键思想：要想成功，必须同时设计系统和用来构建系统的项目。这两种设计对于终成功都是不可或缺的。没有架构就无法设计项目，设计一个无法构建的系统是毫无意义的。
第2章 分解
本章致力于将系统分解为组成其架构的组件。大多数人以坏的方式来分解系统，所以本章首先解释了不该做什么。一旦这个观念建立起来，你将学会如何正确地分解系统，在该过程中掌握一组有用的、简单的分析工具并获得观察结果。
第3章 结构
本章提升了第2章的思想，引入了结构。你将看到如何捕获需求、如何对架构分层、架构组件的分类及相互关系、特定的分类指导原则以及一些相关的问题，如子系统设计。
第4章 组合
本章说明如何将系统组件组装成满足需求的有效组合。这简短的一章包含了本书的几个关键设计原则，并将前两章的内容转化为将在每个系统中使用的强大的思维工具。
第5章 系统设计示例
本章是一个广泛的案例研究，展示了迄今为止所讨论的系统设计思想。系统设计螺旋结构的后迭代提供了一个实际的系统，使系统设计与业务保持一致，并展示了如何生成架构并对其进行验证。
第6章 动机
由于大多数人从来没有听说过项目设计（更不用说实践了），本章介绍了项目设计的概念和参与项目设计的动机。这是项目设计螺旋的第0次迭代。
第7章 项目设计综述
本章概述了如何设计一个项目，首先定义了软件研发的成功，然后介绍了明智的决定、项目人员配备、项目网络图、关键路径、安排活动和项目费用等关键概念。本章涵盖了随后各章中使用的大多数思想和技术，后重点讨论了角色和责任。
第8章 网络和浮动时间
本章介绍了项目网络及其作为设计工具的使用。你将看到如何将项目建模为一个网络图，学习浮动时间的关键概念，了解如何在人员配备和调度中使用浮动时间，并了解浮动时间与风险的关系。
第9章 时间和成本
本章定义了在所有项目中时间和成本之间可能的权衡，并讨论了通过正确工作来加速所有项目的方法。除此之外，你还将学习压缩的关键概念、时间-成本曲线和成本要素。
第10章 风险
本章介绍了大多数项目中缺少的要素：量化风险。你将看到如何度量风险并将其映射到上一章的时间和成本概念中，以及如何基于网络计算风险。风险通常是评估选项的方式，也是一流的规划工具。
第11章 实践中的项目设计
本章通过对设计一个项目所涉及的步骤进行系统的演练，将前几章的所有概念付诸使用。其目标是演示设计项目时使用的思维过程，以及如何为业务决策者审查做准备。
第12章 高级技巧
遵循螺旋式学习模型，本章介绍了高级技巧和概念。这些技巧在各种复杂程度（从简单到具挑战性）的项目中都很有用，是对前几章的补充，而且经常会结合起来使用。
第13章 项目设计示例
本章是与第5章的系统设计示例相对应的项目设计示例。它也是一个案例研究，展示了设计项目端到端的过程。本章的重点是案例研究，而不是技巧。
第14章 总结
后一章从设计的技术方面进行了回顾，提供了一系列的指导、技巧、视角和开发过程思想。它从回答何时设计项目这个重要问题开始，以项目设计对质量的影响结束。
附录A 项目跟踪
附录A展示了如何在计划方面跟踪项目的进度，以及如何在需要时采取纠正措施。项目跟踪更多的是关于项目管理，而不是项目设计，但它对于确保你在工作开始后履行承诺至关重要。
附录B 服务契约设计
架构本身是粗略的，你必须设计其每个组件的细节，而这些细节中重要的是服务契约。附录B指出了设计服务契约的正确方法。此外，关于模块化、规模和成本的讨论也很好地契合了本书大多数章节的内容。
附录C 设计标准
附录C汇总了本书中提到的关键原则、指南和禁忌事项。该标准是简洁的，是关于什么，而不是为什么。这个标准背后的原理可以在本书的其余部分找到。
【前 言】
几乎没有人是被逼着进入软件开发行业的。相反，许多人爱上了编程并决定以此谋生。然而，大多数人所希望的职业生涯与软件开发那黑暗且令人沮丧的现实之间存在着巨大的差距。整个软件行业正处于一场深刻的危机之中。因为软件开发是多维的，所以导致了非常严重的危机，而软件开发的每个方面都被打破了：
成本。一个项目的预算与实际开发该系统的成本之间的相关性很弱。许多组织甚至不愿意解决成本问题，可能是因为它们根本不知道如何解决，也可能是因为它们认识到根本承担不起系统的高昂成本。即使新系统的个版本的成本是合理的，但由于设计不当和无法适应变化，整个生命周期的系统成本也往往会远高于预期。随着时间的推移，维护成本变得非常高，以至于公司通常会决定从头开始，新系统很快就会像之前一样陷入同样甚至更糟糕的局面。而其他任何行业都不会选择定期从头开始，因为这样做没有经济意义。航空公司维护大型喷气式飞机几十年，而一栋房子可能维护整整一个世纪。
进度。后期限（deadline）的设定通常是武断的、无法实现的，因为它与实际开发系统所需的时间几乎没有关系。对于大多数开发人员来说，后期限是无用的东西，它会在团队努力工作的时候呼啸而过。如果开发团队确实在后期限之前完成了任务，那么每个人都会感到惊讶，因为没有人指望它能按时完成。这也是一个糟糕的系统设计的直接结果，它会导致系统的变更和新工作的连锁反应，并使以前完成的工作失效。而且，这是一个非常低效的开发过程的结果，它忽略了活动之间的依赖关系和构建系统的快、安全的方式。不仅整个系统的上市时间相当长，而且单个功能的上市时间也可能很夸张。当项目的进度出现延误时，情况已经很糟了；当管理层和客户都不知道这个延误时，情况就更糟了，因为没有人知道这个项目的真实状况。
需求。开发人员往往终解决了错误的问题。终端客户或其内部环节参与者（如市场营销人员）与开发团队之间的沟通始终存在问题。大多数开发人员也无法适应他们未能捕获需求的情况。即使需求被完美地传达下去，它们也可能随着时间的推移而改变。此变更将使设计无效，并破坏团队试图构建的所有内容。
人员配备。即使是普通的软件系统也非常复杂，超出了人脑的理解能力。内部和外部的复杂性是系统架构不良的直接结果，这反过来又导致复杂的系统很难维护、扩展或重用。
维护。大多数软件系统不是由开发它们的人员来维护的。新员工不了解系统是如何运行的，因此他们在试图解决旧问题时不断地引入新问题。这很快就拉高了维护成本，推迟了上市时间，甚至导致工作停顿或项目取消。
质量。也许没有任何其他东西可以像质量那样破坏软件系统。软件有缺陷，软件这个词本身就是缺陷的同义词，开发人员无法想象没有缺陷的软件系统。修复缺陷通常会增加缺陷数，添加功能或简单维护也会增加缺陷数。质量差是由不易测试、理解或维护的系统架构直接导致的。同样重要的是，大多数项目没有考虑到基本的质量控制活动，也没有为每项活动分配足够的时间，使其可以无可挑剔地完成。
几十年前，业界开始开发解决世界问题的软件。今天，软件开发本身就是一个的问题。软件开发中的问题往往以非技术性的方式表现出来，如工作环境压力大、人员流动率高、工作倦怠、缺乏信任、自卑，甚至身体疾病等。
软件开发中的所有问题都不是新问题，甚至，有些人在其软件开发的整个职业生涯中都没有经历过一次正确的软件开发过程。这使他们相信这根本不可能做到，他们对任何试图解决这些问题的尝试都不屑一顾，因为事情就是这样的。他们甚至可能会与那些试图改进软件开发的人抗衡。他们已经得出结论，这个目标是不可能实现的，所以任何尝试取得更好结果的人，都是在试图做不可能的事，这侮辱了他们的智商。
我自己的过往经历是一个反例，表明开发人员可以成功地开发软件系统。我负责的每个项目均按时、按预算、零缺陷地交付。在创建IDesign之后，我继续保持了这一纪录，我们在该领域一次又一次地帮助客户兑现了他们的承诺。
这种持续、可重复的成功纪录绝非偶然。我在系统工程领域（包含物理系统和软件系统）接受了培训和教育，这使我很容易地认识到这两个系统的相似之处。将实践原则应用到软件设计中，其他工程领域的常识在软件系统中也是有意义的。我从来没有想过不把软件开发当作工程来对待，或者不经过设计或计划就开发一个系统。我认为没有必要在我的信念上妥协，也没有必要屈服于权宜之计，因为做正确的事情才行得通，而不这样做的可怕后果是显而易见的。我很幸运，能有出色的导师，在正确的时间、正确的地点看到哪些有效、哪些无效，并有机会在早期参与了一些重大而关键的项目，使之成为优秀案例的一部分。
近年来，我注意到该行业的问题越来越严重。越来越多的软件项目失败了。在时间和金钱上失败成本都变得越来越高，甚至已经完成的项目也往往偏离了初的承诺。这场危机加剧不仅仅是因为系统越来越大或者云计算的发展，也可能是激进的后期限或者更高的变更率。但我怀疑真正的原因是，开发队伍中越来越缺乏如何设计和开发软件系统的知识。之前大多数团队中都有一位资深人士，他指导年轻人并传授知识。如今，这些导师已经或即将退休。在他们缺席的情况下，普通人只能获得无限的信息，却得不到有用的知识。
我多希望有一个你做了就能解决软件危机的方法，比如使用过程、开发方法、工具或技术。不幸的是，要解决多维问题，就需要多维解决方案。在这本书中，我提供了一个统一的补救方法：软件架构之道（righting software）。
总之，我所建议的是使用工程原理来设计和开发软件系统。好消息是没有必要重新发明轮子，其他的工程学科是相当成功的，因此软件行业可以借用它们的关键通用设计思想并使其适用于软件。你将在本书中看到一套软件工程的基本原理，以及一套完整应用于软件系统和项目的工具与技术。要获得成功，我们必须从工程的角度出发，基于时间和风险方面的考虑，确保软件系统是可维护的、可扩展的、可重用的、可负担的和可行的，这些都是工程方面的问题，而不是技术方面的问题，而且可以直接追溯到系统和项目的设计环节。由于软件工程师通常指软件开发人员，所以出现了术语软件架构师来描述团队中负责项目所有设计方面的人。因此，我假定本书的读者是软件架构师。
本书中的一些想法并不是你要正确认识的事情，但它们肯定是一个良好的开端，因为它们触及了前面提到的问题的根源。根本原因是设计不当，无论是软件系统本身还是用于构建该系统的项目。你将看到，按计划、按预算交付软件以及设计满足所有可能需求的系统是完全可能的，开发出来的系统也是易维护、易扩展和易重用的。希望通过实践这些想法，你不仅能够学会软件系统构建之道，还能助力自己的职业生涯，并重新点燃对软件开发的热情。
【本书的组织结构】
本书展示了系统设计和项目设计的结构化工程方法。本书的结构反映了方法论的两个部分：系统设计（通常称为架构）和项目设计。这两部分相辅相成，是成功的必要条件。附录提供了一些补充内容。
在大多数技术书籍中，每一章只针对一个主题并深入探讨，这样更容易编写，但这通常不是人们学习的方式。相比之下，在这本书中，讲解是螺旋式的。本书的两大部分中的每一
章都重申了前几章的观点，通过多方面的洞察来进行更深入的研究或观点的演进。这模仿了自然的学习过程，每一章都依赖于前面的章节，所以你应该按顺序阅读这些章节。本书的两大部分均包含了详细的案例研究，以展示这些观点以及其他方面。同时，为了保持迭代的简洁性，作为一般规则，我通常避免内容重复，因此即使是关键知识点，也只讨论一次。
以下是对各章和附录的简单介绍：
第1章 元设计方法
本章介绍了下列关键思想：要想成功，必须同时设计系统和用来构建系统的项目。这两种设计对于终成功都是不可或缺的。没有架构就无法设计项目，设计一个无法构建的系统是毫无意义的。
第2章 分解
本章致力于将系统分解为组成其架构的组件。大多数人以坏的方式来分解系统，所以本章首先解释了不该做什么。一旦这个观念建立起来，你将学会如何正确地分解系统，在该过程中掌握一组有用的、简单的分析工具并获得观察结果。
第3章 结构
本章提升了第2章的思想，引入了结构。你将看到如何捕获需求、如何对架构分层、架构组件的分类及相互关系、特定的分类指导原则以及一些相关的问题，如子系统设计。
第4章 组合
本章说明如何将系统组件组装成满足需求的有效组合。这简短的一章包含了本书的几个关键设计原则，并将前两章的内容转化为将在每个系统中使用的强大的思维工具。
第5章 系统设计示例
本章是一个广泛的案例研究，展示了迄今为止所讨论的系统设计思想。系统设计螺旋结构的后迭代提供了一个实际的系统，使系统设计与业务保持一致，并展示了如何生成架构并对其进行验证。
第6章 动机
由于大多数人从来没有听说过项目设计（更不用说实践了），本章介绍了项目设计的概念和参与项目设计的动机。这是项目设计螺旋的第0次迭代。
第7章 项目设计综述
本章概述了如何设计一个项目，首先定义了软件研发的成功，然后介绍了明智的决定、项目人员配备、项目网络图、关键路径、安排活动和项目费用等关键概念。本章涵盖了随后各章中使用的大多数思想和技术，后重点讨论了角色和责任。
第8章 网络和浮动时间
本章介绍了项目网络及其作为设计工具的使用。你将看到如何将项目建模为一个网络图，学习浮动时间的关键概念，了解如何在人员配备和调度中使用浮动时间，并了解浮动时间与风险的关系。
第9章 时间和成本
本章定义了在所有项目中时间和成本之间可能的权衡，并讨论了通过正确工作来加速所有项目的方法。除此之外，你还将学习压缩的关键概念、时间-成本曲线和成本要素。
第10章 风险
本章介绍了大多数项目中缺少的要素：量化风险。你将看到如何度量风险并将其映射到上一章的时间和成本概念中，以及如何基于网络计算风险。风险通常是评估选项的方式，也是一流的规划工具。
第11章 实践中的项目设计
本章通过对设计一个项目所涉及的步骤进行系统的演练，将前几章的所有概念付诸使用。其目标是演示设计项目时使用的思维过程，以及如何为业务决策者审查做准备。
第12章 高级技巧
遵循螺旋式学习模型，本章介绍了高级技巧和概念。这些技巧在各种复杂程度（从简单到挑战性）的项目中都很有用，是对前几章的补充，而且经常会结合起来使用。
第13章 项目设计示例
本章是与第5章的系统设计示例相对应的项目设计示例。它也是一个案例研究，展示了设计项目端到端的过程。本章的重点是案例研究，而不是技巧。
第14章 总结
后一章从设计的技术方面进行了回顾，提供了一系列的指导、技巧、视角和开发过程思想。它从回答何时设计项目这个重要问题开始，以项目设计对质量的影响结束。
附录A 项目跟踪
附录A展示了如何在计划方面跟踪项目的进度，以及如何在需要时采取纠正措施。项目跟踪更多的是关于项目管理，而不是项目设计，但它对于确保你在工作开始后履行承诺至关重要。
附录B 服务契约设计
架构本身是粗略的，你必须设计其每个组件的细节，而这些细节中重要的是服务契约。附录B指出了设计服务契约的正确方法。此外，关于模块化、规模和成本的讨论也很好地契合了本书大多数章节的内容。
附录C 设计标准
附录C汇总了本书中提到的关键原则、指南和禁忌事项。该标准是简洁的，是关于什么，而不是为什么。这个标准背后的原理可以在本书的其余部分找到。
【关于读者的假设】
虽然本书是面向软件架构师的，但读者范围更广泛。读者可以是架构师、高级软件专业人员、项目经理或多重角色的人，也就是说，有志于提高自己技能的开发人员都将从本书中受益。无论你目前处于什么职位，本书都将为你的职业生涯打开一扇大门。当你初次阅读本书时，可能不是一个经验丰富的架构师，但是一旦你阅读并掌握了方法论，就将跻身世界之巅。
本书的技术和思想适用于各种编程语言（如C 、Java、C#和Python）、各种平台（如Windows、Linux、移动设备、本地环境和云）和各种项目规模（从小到的项目），还跨越所有行业（从医疗保健到国防）及所有商业模式和公司规模（从初创企业到大型公司）。
我对读者做出的重要假设是，你在深层次上关心自己的工作，而当前的失败和浪费使你感到苦恼。你想做得更好，但是缺乏指导，或者为不良的做法所困扰。
使用本书的要诀
阅读本书的先决条件是开放的心态，过去的失败经历和挫折是加分项。
其他在线资源
本书的网页提供了示例文件、附录和勘误表。可以通过以下网址访问此页：
http：//www.rightingsoftware.org
你可以在本书的下载支持文件链接下找到示例文件和相关的支持材料。
有关本书的其他信息，请访问informit.com/title/9780136524038。
书单推荐
