软件方法
出版社:清华大学出版社
出版日期:2013-9
ISBN:9787302330806
作者:潘加宇
页数:264页
内容概要
潘加宇，umlchina首席专家。在1999年还是一名程序员时，利用业余时间创建了umlchina，潜心研究需求和设计技能。2002年开始对外提供uml需求和设计的技术指导和训练服务，客户覆盖了各个领域的领袖企业。
书籍目录
《软件方法：上册，业务建模和需求》
第1章.建模和uml 1
1.1 粗放经营的时代已经远去 1
1.2 利润＝需求－设计 2
1.3 核心工作流 4
1.4 uml 简史 9
1.5 各工作流中的uml 12
1.6 基本共识上的沟通 14
1.7 沟通仅限于开发团队内部 16
1.8 方法和过程 18
1.9 案例介绍 20
1.10 模型的组织 21
1.11 工具操作 25
第2章 愿景27
2.1 最不可缺的工件 27
2.2 愿景的定义 28
2.3 老大 29
2.4 把产品当项目——定位具体的组织（人群） 31
2.5 寻找老大：要点和典型错误 34
2.6 可度量的目标 36
.2.7 揣摩目标度量 38
2.8 涉众利益 40
2.9 可以积累的财富 42
2.10 案例 45
2.11 工具操作 46
第3章.业务建模之业务用例图 47
3.1 软件是组织的零件 47
3.2 业务建模步骤1-1 ：选定要改进的组织 49
3.3 业务建模步骤1-2 ：组织的业务用例图 54
3.3.1 业务执行者 54
3.3.2 业务工人和业务实体 55
3.3.3 寻找业务执行者 57
3.3.4 业务用例 58
3.4 案例 65
3.5 工具操作67
3.6 总结 75
第4章.业务建模之业务序列图77
4.1 描述业务流程的手段 77
4.2 业务序列图要点 87
4.2.1 消息代表责任分配而不是数据流动 87
4.2.2 聚焦于系统之间的协作 88
4.2.3 只画核心域相关的系统 91
4.2.4 把时间看作特殊的业务实体 92
4.3 业务建模步骤1-3 ：现状业务序列图 92
4.3.1 错误：把“现状”误解为“纯手工”93
4.3.2 错误：把“现状”误解为“规范” 93
4.3.3 错误：以待开发系统为中心拼凑流程 94
4.4 案例 96
4.5 工具操作 100
4.6 业务建模步骤1-4 ：改进业务序列图117
4.6.1 改进一：物流变成信息流 118
4.6.2 改进二：改善信息流转 120
4.6.3 改进三：封装领域逻辑 121
4.6.4 阿布思考法123
4.7 案例 129
4.8 工具操作 131
第5章.需求之系统用例图139
5.1 系统执行者要点 139
5.2 需求步骤2-1 ：识别系统执行者 143
5.3 系统用例要点 146
5.4 需求步骤2-2 ：识别系统用例 154
5.5 用例的进一步讲解 157
5.5.1 错误：玩弄“复用” 157
5.5.2 错误：玩弄“层次”163
5.5.3 错误：玩弄“子系统” 163
5.5.4 错误：模糊的价值164
5.5.5 提示：大用例无妨小用例 167
5.5.6 提示：用例的命名167
5.6 案例 169
5.7 工具操作 170
5.8 总结 176
第6章.需求之系统用例规约177
6.1 需求步骤2-3 ：书写系统用例规约 177
6.1.1 前置条件和后置条件178
6.1.2 涉众利益183
6.1.3 基本路径 189
6.1.4 扩展路径196
6.1.5 补充约束 199
6.2 案例 206
6.3 工具操作 209
第7章.需求之需求启发 227
7.1 启发障碍 227
7.2 需求启发手段 229
7.2.1 研究资料229
7.2.2 问卷调查 230
7.2.3 访谈 230
7.2.4 观察 233
7.2.5 研究竞争对手234
7.3 需求工程师236
7.3.1 好奇心 236
7.3.2 探索力 237
7.3.3 沟通力 238
7.3.4 表达力 239
7.3.5 热情 240
作者简介
UMLChina 首席专家潘加宇的第一本书。作者在为软件组织提供建模咨询和培训服务超过十年后，把他的经验和感悟写成了本书。《软件方法：上册，业务建模和需求》从“利润＝需求－设计”开始，用市场经济的思想讲解软件开发中需求和设计的道理，以及统一建模语言UML 在需求和设计中的应用。本书还破解了软件开发领域流行的一些心灵鸡汤式宣传。
发布书评
精彩书评 (总计5条)
-
患者确实是医院的执行者 p.60储户来存钱，企业来贷款，人民银行要对它作监管，这些就是该商业银行的执行者 p.54...请问这些是中国人的语文吗？如此荒唐造句的原因在于作者固执地一定要把 Actor 译作“执行者”。而 UML 中的 Actor 其实代表了业务/系统的直接用户、外部参与者在参与 Use Case 活动中所承担的一种角色，根本不是系统的执行者！请分清系统的客户、请求者、被服务对象，与执行者、被请求者、服务者的方向好么？ -
于 p.205 潘老师说：“设计约束既不是功能需求，也不是非功能需求...设计约束是需求的一种，也一样要从涉众的视角描述。”我凌乱了，这么简单的二元逻辑（功能与非功能）也被扯成这样，新的第三种需求类型因为潘老师而诞生，真可谓中国UML江湖的又一大创举啊！我猜这与潘老师是搞化学的出身，大概没学过离散数学集合论有关吧。正确的说法是：既然设计约束不是功能需求，那么它必然也是一种非功能需求。 -
《软件方法上-业务建模和需求》如何做好一个软件？一个软件要做的工作可以量化么？如果能量化，那有流程么？如果有流程，那有方法么？大学学的是计算机，但是最不愿从事的行业就是软件。结果呢，出了校门现在，一干就是8年。我并不是在摆什么资质，因为我们应该清楚，一份工作你重复干了8年，你的经验并不是8年，而是一年而已。《软件方法》讲的是用UML语言来辅助我们进行软件的从0到1的过程。这个过程的结果并不是最终运行在电脑屏幕上的那个界面，而是一堆图纸，可视化的图纸。是的，确实是图纸。建筑行业有设计和施工图纸，电工行业有设计和实施图纸，城市规划有图纸··· ···任何你看得到的工程都有图纸，你要写的软件居然没有。“图纸在我脑子里呢”，我也曾经说过。直到看到这本书。这本书的直接受众应该有两类人：1.程序员这类人一般的工作思路就是提功能的人说要做什么，嗯嗯哦哦之后，迫不及待的打开编辑器开始写代码，调试，然后发现做完的东西，总是被告知要修改，没玩没了的改。2.项目管理者这类我们称之为“IT包工头”，他们既要跟客户聊需求，转头还要跟程序员转述。作为一个中间人，两边都要沟通，现实是两边都没沟通好。用户说的不就是这样的么？怎么做出来的东西就是不对呢！面对需求和变更，他们是最无奈的，因为他们面对的并不只是程序，而是公司的成本和效益。我甚至推荐产品经理也来看看这本书，因为一个产品到底要满足谁的需求，提供什么样的功能是一开始就要想清楚的事情。精益思想的逐步迭代改进是没错，但是也要求你在产品之初，能想明白你产品到底能带来什么样实实在在的客户价值。很庆幸能在工作的第8个年能看到这本书，更荣幸的是，和自己的团队在一起用了7个课时一起讨论学习，一起做作业。最让人兴奋的，是每一次在进行项目讨论的时候，我们都开始用《软件方法》中学到的知识，用新的方法在做我们每天都该去的的事情：内部沟通更加有条理了；需求变更更加谨慎了，和客户的沟通更加有效率了··· ···这是不只是一本书的作用，更是不断打破自己习以为常的工作方式的决心。希望大家一起加油！
精彩短评 (总计15条)
-
提供了一套可供uml建模执行的方式, 但就内容而言没评分那么高 -
很有启发，值得反复阅读和思考，如果能加上习题解析就更好了！ -
里头有些系统用例的错误使用值得参考 -
讲的不是方法，是工具，快餐书，谁都可以写书？ -
这才是软件工程正宗 逻辑推理严密 以前看的各种经典软工书籍都是点 这本书帮我打通任督二脉 墙裂推荐啊 -
业界领域专家的书籍一般比理论界的专家的书籍更加具体可操作，也更加贴近业界当前的实践。I hear and I forget. I see and I remember. I do and I understand。先见全局，再摸细节，力荐！ -
国内不错的关于uml的书，例子也很实用。 -
产品的意义是提高效率 -
UMLGreatChina首席专家张恂老师：读完潘老师的这本大作，总体感觉概念不清，用词不当，东拉西扯，逻辑错乱。全书有许多令人啼笑皆非的荒唐错误结论堪称中华名菜虾扯蛋（抑或重大理论创新？），如“涉众没资格、没责任提供需求”、“不要拿UML模型与涉众沟通”、“设计约束既不是功能需求，也不是非功能需求”、“患者是医院的执行者”、“用例的粒度并不存在，对开发人员的误导相当严重”、“人有眼睛不是需求”。。。我给全书的评价是将将及格，只达到了业余研究UML、需求分析的中等水平，潘老师作为UML中国业余的首席专家名至实归，恭喜恭喜！ -
书里废话太多，可能是为了增加数的趣味性吧。
觉得像这种工程类的书就不应该搞精装。 -
从需求到项目设计，再到代码设计 -
主要是用例图和序列图的画法，举例略啰嗦。 -
重塑思考产品的过程 -
说实话，这本书的废话比较多，但是确实讲了很多平时我们不会注意的痛点，总结问题的时候往往会忽略的点。。。 -
从“利润＝需求－设计”开始，用市场经济的思想讲解软件开发中需求和设计的道理，以及统一建模语言UML 在需求和设计中的应用。本书还破解了软件开发领域流行的一些心灵鸡汤式宣传。