本书介绍了创新方法在软件设计领域中应用。全书分为13章。第一章为综述部分；第二章 引入了7个完美的支柱。介绍了7个支柱之1：理想解；第三章 介绍7个完美支柱之2：打破思维定势；第四章介绍7个完美支柱之3：资源；第五章介绍7个完美支柱之4：功能；第六章7个完美支柱之5：暴露；第七章 7个完美支柱之6：冲突；第八章7个完美支柱之7：颠覆；第九章系统化创新过程；第十章应用案例；第十一章 集成方法；第十二章 未来发展。
你所面临的问题，其他人在其他地方或许已经解决
—— 打破思维惯性，寻找软件突破性创新的方法与工具
“人有时会被真理绊倒，但大部分人爬起来就赶快走开了，对绊倒他的真理视而不见，就好像什么都没发生过。”
—温斯顿·丘吉尔
1985年，我写下了第100段Fortran代码。这段代码属于一个软件，该软件用于给工程师提供一个设计工具，让他们能设计出模拟喷气式发动机并使其“飞翔”。当我第一次完成这个软件时，总代码不到500 KB。2001年，我们签订了一份对该软件进行升级的合同，主要是添加一个友好的用户界面以及一两个新功能。从理论上讲，这个工作应该8周完成。第一个项目组（具有数十年软件编程经验的杰出团队）决定在原来的Fortran核心代码上建立图形界面。20周过去了，项目组反馈说这种策略并不奏效，说需要重写全部的Fortran代码。随后第二个项目组加入，又一个20周过去了，他们完成了优雅的35 MB的VB代码。虽然这份代码很优雅，却仍不奏效。当我们考虑是否就此终止这个项目时，项目组又请求延长几个月。4个月以后，我们依然一无所获。随即第三个项目组加入，这个项目组较之前两个项目组甚至拥有更多的经验，这些软件高手说他们将在8周内完成这个项目。然而直到2004年年末，该项目依旧没有完成。在2005年年中的时候，最后一个项目组宣布失败。到现在为止，我们依旧没有一个可运行的更新版。
这究竟是怎么回事？在1985年那个计算机不发达的年代，我究竟写了什么东西，以致三个不同项目组都无法复制？要知道这三个项目组都是由极其聪明的成员组成的，并且每个成员使用的工具都很复杂，问题究竟出在哪里？我倒希望是因为我是个天才。然而事实并非如此。最简单的事实是我和这三个项目组之间有两个明显的不同：第一，在我所处的编码年代所有软件资源都短缺，我不得不对算法进行巧妙构思和优化；第二，我对喷气式发动机的知识稍有了解—这也是出问题的更重要的原因。本书主要是关于这两个问题的：巧妙的构思和领域知识。
1985年我的第一个Fortran版本是在打孔带上完成的。本书的大部分读者恐怕从来没听说过打孔带吧？第一个版本中的每一行Fortran代码都用一张打孔带表示。看到地上堆着2000张那样的打孔带，顿时就会有种崩溃的感觉。在那种条件下，唯一能够有效缓解这种状况的，就是结束一天的工作后打扫地板的人，他会将地板上堆积的打孔带清理干净。因此，在忍受着制作和处理那些打孔带带来的痛苦时，我产生了一种强烈的需求，那就是尽可能使用较少的数字，而且我需要非常清楚每张打孔带是如何和其他打孔带相关联的。人们常说需求是创新之母。不幸的是，这并不完全正确，但和早期的软件设计思想息息相关。在成堆的打孔带带来的痛苦和苦恼的驱使下，我产生了强烈的需求，即用巧妙的构思来解决问题。没有人希望再次使用打孔带，人们的所有痛苦都随着可用的内存空间以及处理器速度的快速增长烟消云散了。因此，巧妙的构思对于我们来说也不那么重要了。不必担心代码运行过慢，因为在3个月内就会有新一代芯片问世。科技的进步固然重要，但本书讨论的第一个主题是，科技从来不是，也不会成为软件工程的终极目标。我依然认为，在某些方面，巧妙的构思仍占有一席之地。
过度依赖工具是一个巨大的陷阱，但还不是最大的陷阱。根据近几年我与许多世界顶级的软件从业者共同工作所积累的大量经验来看，最大的陷阱是习惯于将软件行业看作一个封闭的领域。封闭的领域意味着可以独立工作并且与现实世界分离。毫无疑问，这是那个喷气式发动机项目失败的主要原因。建立一个虚拟的喷气式发动机模型很简单，但是建立一个与现实世界的物理现实相结合的虚拟喷气式发动机就有点复杂了。现实世界充满了很多难解之谜，像物理和化学、机械压力和材料温度限制，以及可操作性、可靠性、鲁棒性。如果一名软件工程师认为他不需要知道这些，必将会导致唯一的结果，那就是带来麻烦。
以喷气式发动机建模来举例可能有点极端，但它却代表了所有软件项目的全部相关特征。确切地说，某些情况下软件工程是需要与外部领域交互的，无论这个外部领域是基于硬件定义的，还是由用户定义的，或是由另一个软件定义的，在某个地方都会需要一个接口，而这个接口恰好就是软件最初存在的主要原因。而且，在我与软件工程师一起解决大量问题时，工程师们经常抱怨我们想出来的解决方案不属于软件范畴，从而终止与我们合作。可是如果这样的问题不能算作软件范畴的问题，它又能算是什么问题呢？
本书完全是关于软件问题的。决定一种情境是否属于软件领域的第一步就是了解这种情境。因此本书的大部分内容是帮助读者去了解情境。一旦构建了某种可以通过软件进行改变的情境，本书的其余部分便会专注于帮助大家找出最好的可行方案。这里的“最好”指的是巧妙而可行。
欢迎来到另外一个世界。
Darrel Mann
班加罗尔
2008年7月
IT文化
是一张图
[英]达雷尔·曼恩（Darrell Mann）著：达雷尔·曼恩（Darrell Mann），英国系统性创新专家、欧洲TRIZ协会创会主席、国际TRIZ协会会员，迄今辅导过至少24个国家的近百家公司，是当前TRIZ系统性创新领域实务经验丰富且富有实务解题成效的学者。
第一次看到由达雷尔·曼恩大师著的《软件系统化创新》英文版，是在2010年海峡两岸创新方法交流活动的书展上，如获至宝。软件创新艰难，这方面的著作也少，而本书介绍了软件领域的系统化创新方法，尤其珍贵。多年来创新理论在我国推广应用，大部分案例产生自传统产品的设计、制造过程，而在软件设计方面的创新应用案例极少，缺乏适合在软件领域推广的软件创新方法是很重要的原因之一。
TRIZ创新方法是从大量专利里总结、归纳、抽象出来的，对产品的创新设计具有很强的指导作用。软件也可以作为一种产品，其设计从抽象层次说与传统产品设计方法具有相通性，因此创新方法应用在软件设计领域也同样具有指导作用。但其设计在术语及方法上有别于传统产品设计。软件创新设计不仅仅关乎软件技术本身，也与其周围环境及操作用户直接相关。本书从发现软件问题、分析问题到正确地定义软件问题，再到选择解决问题的工具，最终获得解决方案这一整套系统化软件创新方法和工具来介绍，更易于软件设计者理解和掌握，对软件的系统化创新具有很好的指导作用。
各领域产品都有其领域设计规则或者规范被广泛应用，并取得了很好的效果。但这些规则都是从“优化”或者“平衡”的角度出发进行产品设计，而不是从“创新”的角度出发。创新设计的目的就是解决系统中存在的矛盾。当然这并不是说领域设计规则没有解决矛盾，例如软件设计领域里著名的“设计模式”，也是从设计实践中获得并被广泛应用的设计规则，这些模式的潜在逻辑也是为了解决矛盾，只是没有从创新设计的角度去定义问题。通过阅读本书，你会发现更多软件问题，并借助软件系统化创新方法框架得到更多样的解决方案。
非常感谢中国科学技术学会原总工程师李赤泉、台湾“清华大学”许栋梁博士的信任，使我有机会翻译本书。同样非常感谢出版社朱捷老师给予支持和积极协调，使本书的翻译工作得以完成。期间还有很多老师和同学为之付出努力，在此一并表示感谢，他们是吴鸿韬老师、张权博士、214实验室全体同学。因翻译水平有限，书中难免存在一些不准确的描述，敬请读者批评指正。
译者序
序
前言
第1章 引言—系统化（软件）创新1
1.1 软件创新简史5
1.2 软件工程—问题是什么10
1.3 七根完美的支柱16
1.4 本章小结23
第2章 七根完美的支柱之一—完美25
2.1 收益、有形和“足够好”26
2.2 定义“完美”，发现矛盾34
2.3 为什么我们要获得完美40
2.4 完美和“从哪入手”的策略42
2.5 自我45
2.6 我该怎么做46
第3章 七根完美的支柱之二—摆脱48
3.1 大脑不是为创新而设计的49
3.2 三种不同种类的心理惯性53
3.3 打破思维定式62
3.4 摆脱思维定式的工具68
3.5 我该怎么做79
第4章 七根完美的支柱之三—资源81
4.1 发现未利用的资源83
4.2 变废为宝88
4.3 杠杆91
4.4 趋势跳跃98
4.5 某人在某处已经解决了你的问题108
4.6 我该怎么做115
第5章 七根完美的支柱之四—功能117
5.1 为什么朝着现在的方向前进118
5.2 功能和属性分析125
5.3 技术替代—专利规避设计134
5.4 我该怎么做135
第6章 七根完美的支柱之五—涌现137
6.1 流：从哪里创新141
6.2 修复：认知映射147
6.3 修正：错误分析152
6.4 进化：紧急矛盾166
6.5 我该怎么做170
第7章 七根完美的支柱之六—矛盾173
7.1 解决矛盾很简单179
7.2 解决矛盾并不简单183
7.3 工具187
7.4 最大效率策略202
7.5 我该怎么做209
第8章 七根完美的支柱之七—乌龟211
8.1 通用S形曲线213
8.2 复杂性先增长后衰减218
8.3 结果迁移222
8.4 裁剪226
8.5 我该怎么做228
第9章 非连续的系统化流程230
9.1 当我们解决创新问题时会发生什么231
9.2 连续的“系统化创新流程”236
9.3 自校正240
9.4 我该怎么做244
第10章 案例和场景246
10.1 案例研究1：语音识别249
10.2 案例研究2：Design4Wow网站256
10.3 场景介绍264
10.4 测试264
10.5 再一次强调需求多样性法则270
10.6 度量272
10.7 我该怎么做277
第11章 总括278
11.1 现在要做什么279
11.2 将这种方法传授给他人285
11.3 常见问题292
11.4 我该怎么做294
第12章 预测未来296
12.1 真实世界—万物理论301
12.2 系统完整性法则304
12.3 系统软件创新策略315
12.4 软件创新工具和过程320
12.5 我该怎么做322
附录1 问题定义模板325
附录2 资源清单333
附录3 不间断的软件进化趋势343
附录4 软件矛盾矩阵372
附录5 40个发明（软件）原理与实例398
