1.书籍信息

封面
书名	《软件方法（上）：业务建模和需求（第2版）》
作者	潘加宇
状态	已读完
简介	在软件开发中，需求工作致力于解决“提升销售”的问题，设计工作致力于解决“降低成本”的问题，二者不能相互取代。能低成本生产某个系统，不一定能保证它好卖。系统好卖，如果生产成本太高，最终还是赚不了多少钱。 如果需求和设计不分，利润就会缩水。从需求直接映射设计，会得到大量重复代码；如果从设计出发来定义需求，会得到一堆假的“需求”。 《软件方法（上）：业务建模和需求（第2版）》在主要思想不变的前提下，结合最近几年的发展，从文字到图形进行更新，每一章的内容更加细致，道理讲得更加严谨，例子和练习也更加丰富，希望能给读者提供帮助。
资源
评价（满6颗）	很好的一本书，非常推荐，是讲软件需求分析的 ⭐⭐⭐⭐⭐⭐

2.书摘

19个笔记
内容简介

本书要点：利润=需求-设计。


在软件开发中，需求工作致力于解决“提升销售”的问题，设计工作致力于解决“降低成本”的问题，二者不能相互取代。
1.1 粗放经营的时代已经远去

机会驱动、粗放经营的时代已经远去，为了在激烈的竞争中获得优势，软件开发组织需要从细节上提升技能。
1.5 UML应用于建模工作流

掌握用例图、类图、序列图这三种图基本上够用了，可以先重点学习这三种图，其他图形暂时不管
1.6 基本共识上的沟通

开发人员让我看他的模型时，如果开口说“我先来给你讲讲”，我都会拦住，“如果还需要你先讲讲，说明你所想的没有体现在模型中”。这种做法的本质是想通过形式上的丑陋来遮掩内容上的丑陋。


UML背后隐含着软件建模的一些基本共识，这些共识需要一定的训练才能掌握。


掌握统一的建模语言之后，开发团队在基本共识上沟通，会大大提高沟通的效率和深度，有意无意遮掩的脓包也会强制露出。


使用UML沟通仅限于软件组织内部，UML模型不是用来和涉众沟通的！
1.7 建模和敏捷（Agile）

本书内容针对的是影响软件质量的直接原因——缺少各种建模技能。
1.8 什么样的系统不需要建模

本书到现在为止，已经说了很多回“偷懒”，就是强调世上无易事，好的方法应该能强迫您思考，强迫您付出心血和汗水来获得竞争优势，反之就是忽悠，就像前些年一些甜得发腻的敏捷宣传。
2.1 什么是愿景（Vision）

愿景属于业务建模工作流的一部分。为了突出愿景的重要性，本书把它单独列为一章。
2.2 【步骤】定位目标组织和老大

竞争使得产品分类越来越细，不再有针对所有人的产品。


愿景实际上就是系统最重要涉众的利益。
3.1 软件是组织的零件

比喻有意思
对于软件开发来说，业务建模的目的是为了得到待引进软件系统的需求。软件系统只是组织的一个零件。组织里面还有很多系统，其中最值钱的是千百年来一直在使用，现在依然是最复杂的系统——人脑系统，它由“父母公司”开发，“老师公司”不断升级，组织以每人每月几千上万的租金租用。为了让组织更好地对外提供价值，不一定要引进新的软件系统，有时换新人更管用。


对于软件开发来说，业务建模的目的是为了得到待引进软件系统的需求。软件系统只是组织的一个零件。组织里面还有很多系统，其中最值钱的是千百年来一直在使用，现在依然是最复杂的系统——人脑系统，它由“父母公司”开发，“老师公司”不断升级，组织以每人每月几千上万的租金租用。为了让组织更好地对外提供价值，不一定要引进新的软件系统，有时换新人更管用。


开发人员有时会有意无意把自己的系统想得太重要，还喜欢起××云平台等很牛的名字，以为没有他们开发的系统，组织就玩不转了。有一次我到北京某公司讲课，开发人员在写某信贷风险系统的愿景时写道：本系统的目标是，银行风险部能够对贷款做风险评估。我问道：难道银行以前不能做风险评估吗？他认真地回答：不能啊，有我们的系统才行！其实想想就知道，银行都成立多少年了，该公司才成立几年？所以为了抵消开发人员这种“致命的自负”，有时我会故意将“系统”称为“马桶”，意思是这个零件和组织厕所里的马桶没有本质区别
3.2 【步骤】识别业务执行者

很好
责任转移的思想对识别待引入系统的需求很有帮助。开发人员说，“我在开发一个新系统”，其实说的就是“我在开发一个新的业务实体，取代现有业务工人或业务实体的一些责任”。这样，探索需求的思路就出来了——我们画好现状的业务序列图，然后寻找改进点改进业务序列图。在改进的业务序列图上，从外部指向所研究软件系统（业务实体）的消息，可以直接映射为该软件系统的用例


责任转移的思想对识别待引入系统的需求很有帮助。开发人员说，“我在开发一个新系统”，其实说的就是“我在开发一个新的业务实体，取代现有业务工人或业务实体的一些责任”。这样，探索需求的思路就出来了——我们画好现状的业务序列图，然后寻找改进点改进业务序列图。在改进的业务序列图上，从外部指向所研究软件系统（业务实体）的消息，可以直接映射为该软件系统的用例
3.3 【步骤】识别业务用例

业务用例是组织的价值，不会因为某个人脑系统或电脑系统的存在或消失而改变。
微信读书

3.读后感 & 点评

在学习领域驱动设计时，听人提到潘加宇的“领域驱动设计批评”文集（微信搜索） ，觉得里面说的有道理，但是又好像什么都没说 ，正好看到他出过一本《软件方法（上）》 遂过来看看如何
看之前是有人推荐的，说有水平， 看的时候还挺期待
看的过程中，开头几章感觉不错，很有水平， 但是越往后看越看不下去，get 不到点，感觉在学大学里的软件工程 uml 部分，内容基本差不多
相比《领域驱动设计：软件核心复杂性应对之道》，作为软件开发全流程的话太单薄了，只有 UML 建模部分撑不起来
当然，潘加宇老师他就专注于 UML 建模领域， 单纯的这部分看完就很有收获

4.相关资料

潘加宇：软件需求设计方法学全程实例剖析-概述
umlchina_01_overview.pdf

潘加宇：软件需求设计方法学全程实例剖析-愿景
umlchina_02_vision.pdf

潘加宇：软件需求设计方法学全程实例剖析-业务用例图和业务序列图
umlchina_03_bm.pdf

潘加宇：软件需求设计方法学全程实例剖析-系统用例图和用例规约
umlchina_04_req.pdf

潘加宇：软件需求设计方法学全程实例剖析-需求启发
umlchina_05_r.pdf