软件方法——业务建模和需求（好书推荐）

简介

许多伟大的创新，其实就是用廉价的替代方案来山寨过去富豪和高官的生活。软件工程更接近于经济学，而非计算机科学。需求是不考虑“复用”的，用同样的材料，变出更多可卖的功能，这是设计能力的体现。大家可以尝试用“不这样行吗”这个标准去过滤我们的“需求”。

推荐序

我从事软件开发已七年有余，在传统软件公司呆过，也在互联 公司任职过，期间做过普通开发人员，也带过团队。依我的经历看，绝大部分开发人员都缺少对开发技能的训练，更是缺少市场意识。

在软件开发过程中，我也一直在思索如何提升技能，让自己的工作变得更有效率，更有价值。初次结识潘老师，是在中科院的课堂上，他传授的软件方法理念和技能，让我有了眼前一亮的感觉，这些方法和思维在我职业生涯的每个阶段都让我深深受益。

 2007——2011 年，我在一家做数字出版的公司工作，当我还是一名普通开发人员时，有时接到开发需求，往往不知从何处下手，折腾一阵子之后，发现做出来的软件功能与客户的实际期望相差太远。通过与潘老师的学习交流后，才了解到这其中的原因之一是最初提出来的需求根本就不是“需求”！而仅仅是一个想法，或者素材，然而过于相信这种被产品经理、领导或者客户“加工”过的需求。

没有去深入挖掘其背后隐藏的各涉众的利益诉求，当然也就不会真正解决客户的问题，最后导致的真实场景就是总抱怨需求频繁变更，为了赶项目进度，不得已要经常熬夜加班。实际上，客户的需求从来就没有变过，只是我们一开始就没有揣摩出来！在后来的项目中，我便有意识地去实践愿景、业务建模和系统用例等这些招式，刚开始时是为了学而去练习，练起来稍微有点费劲。

最主要的难点在于思维的改变，以前是纯粹的技术思维，而练习这些招式需要换个角度，从用户的角度出发，从市场的角度去考虑问题，很不适应，但收到的效果也很明显，不再做无用的需求，通过练习“类图”、“序列图”等招式，分析和设计能力自然得到提升，基于领域知识的封装，让代码的复用度更高，也更加稳定可靠。

后来，我成了一个团队的 Leader，发现团队的开发效率不高，项目延期是常事；每个人的开发水平相差很大，有经验的上手很快，没有经验的却很难上路；Bug 总是改不完；自底向上的面向过程式思维设计；代码的共享度不高，最有价值的代码得不到沉淀，每次新人接手，很多是推倒重来……为什么会出现这些问题其原因，还是开发人员的开发技能不足引起的。

我遇到过很多人一接到需求，便开始做数据库设计，往往忽略了或者不屑于做业务建模、分析和软件本身的设计，以为做完数据库设计就万事大吉，特别是在互联 公司表现较为突出。最终导致的结果就是代码难以复用，互相看不懂别人写的代码，理解起来也很费劲，往往不如重写一遍，所以出现上面这些问题也就在所难免。为了解决这些问题，只有想办法提高开发人员的开发技能，没有捷径可走，于是在团队内部普及软件方法，由于大多是互联 产品，业务比较简单，所以省掉了业务建模这块，从需求-系统用例入手，刚开始时有的用例文档会直接切入到设计，因为他的思路还没有转变过来，仍然是技术思维，熟练之后，有些比较简单的用例，形成了套路，心里清楚即可，那些业务逻辑稍微复杂一点的，还必须经历各种招式。

随着一段时间的练习，团队情况有所好转，软件版本的发布周期有了改善，被良好封装的代码形成了系统的稳定中间态，系统也更加健壮。虽然还有部分人没能很好地掌握，我想这其中最主要的原因还是在于技术思维的转变。

如何让软件代码和设计得到最大程度地复用，从而缩短开发周期，降低开发成本。

对于第一个问题，我想可以借鉴《软件方法》里的“愿景“思维和建模等手段，”愿景“思维帮助我们寻找到所关注行业领域的”老大“，并揣摩出”老大“心中的利益诉求点，即我们要解决的问题，进一步通过业务建模来改进现有的业务流程，找到创新点，从而捕捉到公司应提供的最有价值和最有竞争力的服务，依此对该核心领域进行分析和设计得到的软件系统将是最有竞争优势和卖点的。

对于第二个问题，处于创业期的公司，由于资源少、人员少，缩短开发周期，降低开发成本是我们必然要考虑的，相比成熟公司也更加值得重视。潘加宇老师提出来的”利润=需求-设计“可以说道出了其中的真谛，我们可以通过对领域机制的分析和设计，封装出复用度很高的核心领域知识，而这些领域知识基本是稳固不变的，这正是公司的核心竞争力所在。

如果你对上面这些内容颇有同感，那么本书非常值得一读，而且当你深入阅读时，你将领略到该书不仅仅在软件领域对你起指导作用，提升你的开发技能，而且对你做事，甚至创业的思维和方法都有一定的启发和影响。

读后感

作为一个野路子过来的程序员（呵呵，一直自我标榜是程序员，为这个名字骄傲！），一直是自己学习，一直是自己摸索做软件。每次拿到一个所谓的“项目”吧，都是根据用户的需求，做点改动，改点做点。做了一些吧，感觉一方面开发工具使用来使用去，都是那些，开发包嘛都是别人的，拿过来研究研究API，先实现功能再说吧。时间长了，总觉得缺点什么东西，缺点什么东西呢户老是抱怨软件不是他要的，我也老是觉得用户在故意找问题；源代码乱七八糟， 上这找一段，那抄一段，东西倒是做出来了，但却没有什么积累；开发过程也很让人熬心，今天一个功能，明天一个功能，尽管功能不同，但好像很多是重复的，感觉只是在做无意义的机械拼凑；东西倒是好不容易做出来了，过一段时间，有类似的开发了，好像也找不到能够从以前的开发中能直接拿出来有用的东西。我觉得我应该去寻找软件开发本质的东西了。

问了很多人，人家说，软件工程和架构设计可能是你需要的答案，去寻找吧！那时， 上最多的是UML的介绍，于是，我感觉找到了目标一样，疯狂地找啊！那时基础也不好，就从最初的看起，电子书、视频资料找了不少，实物书也买了些看，知道了一些基本概念，学会了某些软件的一些基本操作，可是感觉还是不得劲，用不到开发中去。我似乎觉得可以在开发能够坚持的东西，我没有学到。直到我去年在偶然间从 上下载了潘加宇老师的这本《软件方法上册——业务建模和需求》，我读完第1章，就感觉这本书就是我想要的东西！对于我这种野路子程序员，想要在软件工程和架构设计方面提升自己，太需要一招一式地练好基本功了，而这本书，就是拳谱！如果说那些大师级的著作是《九阳神功》的话，那这本书，我觉得就是《武当长拳》了，练好它，从程序员升级到架构师才有基础。

第1章，是这本书的总纲（哈哈，让我想起了《七伤拳》的总纲），一下就点出了软件开发的三个本质。第一是用“利润=需求-设计”这一公式指出了软件开发中需求和设计这两个活动对商业利润的直接影响，并让这两个活动在软件开发当中泾渭分明；这让我认识到，软件工程的目标就是使从需求到设计的转化过程，更加明朗化、规范化；明朗化是使人清楚地知道做哪些事，规范化是如何标准地做这些事。第二是点出了软件过程的核心工作流及其思考边界；核心工作流倒还好说，但凡接触过一点软件开发都能说出个一二三，只是每个工作流的本质区别是什么，估计都不甚了了了，反正我是一个野路子程序员，对此更是不明白了，我读到此处时，收获就很大，一下子脑子就清晰了，原来每个核心工作流的本质区别就是其思考边界，或者说思考问题的目标不一样了；这就好像练武功的每一招所练的肌肉、或者穴位，都不一样。第三是在核心工作流中有效利用UML工具，并实现开发团队内部顺畅交流的问题；UML为我们提供了软件开发的利器，这就像武器架上排好了刀、枪、剑、戟、斧、钺、钩、叉，现在该你上场了，你该使用什么趁手的兵器（呵呵，千万不能像孙猴子那样说都不趁手哦！）个部分的讲解，就是一个师傅坐你旁边了，你新手上路，心里踏实呀！本章的最后，点出了软件开发团队实施过程容易陷入形式化的根源，就在于技能不足，所以，练好这一招一式吧！

第3、4章，表面上在讲如何研究业务，但实际上是在讲待开发系统与组织的关系。注意，这个时候，思考问题的边界是在组织与组织之间。第3章开头就指出软件只是组织的零件，这实质上是讲软件的定位问题，以前总觉得自己做的系统多牛、多好、多重要，但看到此处，原来自己的“宝贝”只是组织为了改进业务而加入的一个零件而已，呵呵，不要太自以为是了。然后，通过认识组织对外体现出的价值，识别出业务用例，最开始，我也读到此处也有些混了，业务用例好像是个新词，和开发系统时讲的用例有什么一样样之处，就是这个“价值”。第4章，开始认识要体现组织的价值，组织内部要做些什么事了，这就通过业务序列图来体现，认真研究业务序列图，从物流变信息流、信息流转改善、领域逻辑封装三个方面来改进业务，得到改进后的业务序列图，注意，得到了这个图，我们要开发的系统的定位、职责，就基本可以确定了。

第5-7章，是介绍使用用例技术来认识需求。此时，思考问题的边界转到组织内部的系统与系统之间了。系统用例的认识过程也是通过“价值”来体现的，这和前面类似。第6章，我觉得讲解得十分精彩，具体讲解到了用例规约技术中各个部分的意义和作用，这一点是我在其它书里面没有看到的，这让我在以后写用例规约时，觉得更有指导了。最后第7章，讲了些进行需求获取的方法。

引用

《软件方法-业务建模和需求》_休克柏的博客-CSDN博客_软件方法(上)业务建模和需求

软件方法（上）读书笔记 业务建模与需求_张贝雨的博客-CSDN博客_软件方法(上)业务建模和需求

《软件方法-业务建模和需求》_休克柏的博客-CSDN博客_软件方法(上)业务建模和需求

笔记-软件方法-上册-业务建模和需求_JINGYANG2015的博客-CSDN博客

一招一式练武功——读《软件方法上册——业务建模和需求》有感_陶朱子的博客-CSDN博客

软件方法：业务建模和需求札记-建模和UML_沉默王二的博客-CSDN博客

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91435 人正在系统学习中