编辑推荐

这是一本首次将TRIZ创新方法应用于软件系统创新的书。

本书提供了包括从用户角度理解完美软件（P）、打破思维定式（E）、利用可用资源（R）、功能分析与替代（F）、系统复杂性分析（E）、解决矛盾（C）和系统迭代（T）七个方面的一整套系统化软件创新方法。

该方法通过引入问题模板、进化趋势、40条发明原理、认知映射，以及数字、技术、社会DNA之间的交互与组合，洞察系统及领域外之间的关系，寻找矛盾等一系列创新工具，帮助你识别出非线性问题，发现创新方向和突破点，获得解决矛盾的方法，跨领域、跨行业寻找问题的解决方案。

本书以语音识别、Design4Wow网站设计和软件测试三个完全不同的应用实例场景，系统化展示如何应用软件系统化创新方法将创新工具融入解决问题的过程中，为读者提供了一套逻辑清晰、内容丰富的系统化软件创新手册与工具。

本书特别适合企业、高校和其他社会组织中软件管理和创新领域的研究者、实践者、学生和创新方法爱好者阅读和使用。

内容简介

本书介绍了创新方法在软件设计领域中的应用。

全书分为12章：

第1章为综述部分，概要介绍了软件创新简史和七根完美的支柱等；

第2~8章对七根支柱——完美、摆脱、资源、功能、涌现、矛盾和乌龟进行了详细介绍；

第9章讲述了系统化创新流程；

第10章讲解了一些应用案例和场景；

第11章对前几章的内容进行了总括，明确现在要做什么、该怎么做等；

第12章预测了未来发展。

本书适合软件工程师、软件开发者以及其他软件从业人士阅读。

作者介绍

达雷尔·曼恩（Darrell Mann） 英国系统性创新专家，欧洲TRIZ学会创始会长，国际TRIZ协会会员，辅导过至少24个国家的近百家公司，是当前TRIZ系统性创新领域实务经验丰富且富有实务解题成效的学者。

译者简介
马建红　工学博士、博士生导师，河北工业大学人工智能与数据科学学院智能系统与控制工程系教授，计算机辅助创新软件研究所所长，中国计算机学会高级会员，创新方法研究会理事。
张满囤　工学博士，副教授，河北工业大学人工智能与数据科学学院智能系统与控制工程系副主任，硕士生导师，天津市图象图形学学会副秘书长。
于洋　工学博士，副教授，河北工业大学人工智能与数据科学学院智能系统与控制工程系教师，硕士生导师，天津市图象图形学学会会员。

目 录

第1章　引言—系统化（软件）创新1
11　软件创新简史5
12　软件工程—问题是什么10
13　七根完美的支柱16
14　本章小结23

第2章　七根完美的支柱之一—完美25
21　收益、有形和“足够好”26
22　定义“完美”，发现矛盾34
23　为什么我们要获得完美40
24　完美和“从哪入手”的策略42
25　自我45
26　我该怎么做46

第3章　七根完美的支柱之二—摆脱48
31　大脑不是为创新而设计的49
32　三种不同种类的心理惯性53
33　打破思维定式62
34　摆脱思维定式的工具68
35　我该怎么做79

第4章　七根完美的支柱之三—资源81
41　发现未利用的资源83
42　变废为宝88
43　杠杆91
44　趋势跳跃98
45　某人在某处已经解决了你的问题108
46　我该怎么做115

第5章　七根完美的支柱之四—功能117
51　为什么朝着现在的方向前进118
52　功能和属性分析125
53　技术替代—专利规避设计134
54　我该怎么做135

第6章　七根完美的支柱之五—涌现137
61　流：从哪里创新141
62　修复：认知映射147
63　修正：错误分析152
64　进化：紧急矛盾166
65　我该怎么做170

第7章　七根完美的支柱之六—矛盾173
71　解决矛盾很简单179
72　解决矛盾并不简单183
73　工具187
74　最大效率策略202
75　我该怎么做209

第8章　七根完美的支柱之七—乌龟211
81　通用S形曲线213
82　复杂性先增长后衰减218
83　结果迁移222
84　裁剪226
85　我该怎么做228

第9章　非连续的系统化流程230
91　当我们解决创新问题时会发生什么231
92　连续的“系统化创新流程”236
93　自校正240
94　我该怎么做244

第10章　案例和场景246
101　案例研究1：语音识别249
102　案例研究2：Design4Wow网站256
103　场景介绍264
104　测试264
105　再一次强调需求多样性法则270
106　度量272
107　我该怎么做277

第11章　总括278
111　现在要做什么279
112　将这种方法传授给他人285
113　常见问题292
114　我该怎么做294

第12章　预测未来296
121　真实世界—万物理论301
122　系统完整性法则304
123　系统软件创新策略315
124　软件创新工具和过程320
125　我该怎么做322

附录1　问题定义模板325
附录2　资源清单333
附录3　不间断的软件进化趋势343
附录4　软件矛盾矩阵372
附录5　40个发明（软件）原理与实例398

前　　言

“人有时会被真理绊倒，但大部分人爬起来就赶快走开了，对绊倒他的真理视而不见，就好像什么都没发生过。”
—温斯顿.丘吉尔

1985年，我写下了第100段Fortran代码。这段代码属于一个软件，该软件用于给工程师提供一个设计工具，让他们能设计出模拟喷气式发动机并使其“飞翔”。当我第一次完成这个软件时，总代码不到500 KB。2001年，我们签订了一份对该软件进行升级的合同，主要是添加一个友好的用户界面以及一两个新功能。从理论上讲，这个工作应该8周完成。第一个项目组（具有数十年软件编程经验的杰出团队）决定在原来的Fortran核心代码上建立图形界面。20周过去了，项目组反馈说这种策略并不奏效，说需要重写全部的Fortran代码。随后第二个项目组加入，又一个20周过去了，他们完成了优雅的35 MB的VB代码。虽然这份代码很优雅，却仍不奏效。当我们考虑是否就此终止这个项目时，项目组又请求延长几个月。4个月以后，我们依然一无所获。随即第三个项目组加入，这个项目组较之前两个项目组甚至拥有更多的经验，这些软件高手说他们将在8周内完成这个项目。然而直到2004年年末，该项目依旧没有完成。在2005年年中的时候，最后一个项目组宣布失败。到现在为止，我们依旧没有一个可运行的更新版。
这究竟是怎么回事？在1985年那个计算机不发达的年代，我究竟写了什么东西，以致三个不同项目组都无法复制？要知道这三个项目组都是由极其聪明的成员组成的，并且每个成员使用的工具都很复杂，问题究竟出在哪里？我倒希望是因为我是个天才。然而事实并非如此。最简单的事实是我和这三个项目组之间有两个明显的不同：第一，在我所处的编码年代所有软件资源都短缺，我不得不对算法进行巧妙构思和优化；第二，我对喷气式发动机的知识稍有了解—这也是出问题的更重要的原因。本书主要是关于这两个问题的：巧妙的构思和领域知识。
1985年我的第一个Fortran版本是在打孔带上完成的。本书的大部分读者恐怕从来没听说过打孔带吧？第一个版本中的每一行Fortran代码都用一张打孔带表示。看到地上堆着2000张那样的打孔带，顿时就会有种崩溃的感觉。在那种条件下，唯一能够有效缓解这种状况的，就是结束一天的工作后打扫地板的人，他会将地板上堆积的打孔带清理干净。因此，在忍受着制作和处理那些打孔带带来的痛苦时，我产生了一种强烈的需求，那就是尽可能使用较少的数字，而且我需要非常清楚每张打孔带是如何和其他打孔带相关联的。人们常说需求是创新之母。不幸的是，这并不完全正确，但和早期的软件设计思想息息相关。在成堆的打孔带带来的痛苦和苦恼的驱使下，我产生了强烈的需求，即用巧妙的构思来解决问题。没有人希望再次使用打孔带，人们的所有痛苦都随着可用的内存空间以及处理器速度的快速增长烟消云散了。因此，巧妙的构思对于我们来说也不那么重要了。不必担心代码运行过慢，因为在3个月内就会有新一代芯片问世。科技的进步固然重要，但本书讨论的第一个主题是，科技从来不是，也不会成为软件工程的终极目标。我依然认为，在某些方面，巧妙的构思仍占有一席之地。
过度依赖工具是一个巨大的陷阱，但还不是最大的陷阱。根据近几年我与许多世界顶级的软件从业者共同工作所积累的大量经验来看，最大的陷阱是习惯于将软件行业看作一个封闭的领域。封闭的领域意味着可以独立工作并且与现实世界分离。毫无疑问，这是那个喷气式发动机项目失败的主要原因。建立一个虚拟的喷气式发动机模型很简单，但是建立一个与现实世界的物理现实相结合的虚拟喷气式发动机就有点复杂了。现实世界充满了很多难解之谜，像物理和化学、机械压力和材料温度限制，以及可操作性、可靠性、鲁棒性。如果一名软件工程师认为他不需要知道这些，必将会导致唯一的结果，那就是带来麻烦。
以喷气式发动机建模来举例可能有点极端，但它却代表了所有软件项目的全部相关特征。确切地说，某些情况下软件工程是需要与外部领域交互的，无论这个外部领域是基于硬件定义的，还是由用户定义的，或是由另一个软件定义的，在某个地方都会需要一个接口，而这个接口恰好就是软件最初存在的主要原因。而且，在我与软件工程师一起解决大量问题时，工程师们经常抱怨我们想出来的解决方案不属于软件范畴，从而终止与我们合作。可是如果这样的问题不能算作软件范畴的问题，它又能算是什么问题呢？
本书完全是关于软件问题的。决定一种情境是否属于软件领域的第一步就是了解这种情境。因此本书的大部分内容是帮助读者去了解情境。一旦构建了某种可以通过软件进行改变的情境，本书的其余部分便会专注于帮助大家找出最好的可行方案。这里的“最好”指的是巧妙而可行。
欢迎来到另外一个世界。