jeri 2020-3-31 19:42

关于系统的定义，《软件方法》一书给出了2个关键点，后来在答疑时补充了系统要满足充分,必要条件。现实中做系统增量开发时，并不是很好分辨。

先举个例子，IBM卖笔记本电脑，后来技术先进了，可以加一个USB插件，语言就转成文字了，先假设这个插件只有IBM能开发。

老用户去商店买USB插件，从卖的角度，USB插件就是一个系统，同时商店也有带插件的整机，你要是新用户，可以直接用带插件的整机。

对于买整机的用户来说，USB插件就不是一个系统。只能算子系统，这个从卖的角度，很好理解。

但是对于软件来说，并不好区分，举个例子：微信支付推出了一个功能，你说句话，如 向潘家于转100元，系统就转账了，里面有高科技，通过声音,地理分析等等，

这里是新开发一个语言转账系统，还是在原来的微信支付系统上增加了一个功能分包。

从卖角度，用户不会管你系统内部的交互，他要的是一个整体系统，但是从IBM的例子看，语言转账系统作为一个新系统是合理的。（作为功能分包与独立的系统在业务序列图上的交互是不一样的）

我们再从《软件方法》P146 分析

5.1.1 系统是独立对外提供服务的整体，对外提供服务，

对于买整机的用户来说，USB插件就不是一个系统。只能算子系统，这个从卖的角度，很好理解。

5.1.2 系统边界是责任的边界

书中提到积分兑换系统不是一个系统，数据是共享的，从语言转账系统看，用户数据都是微信支付系统系统的，语言转账系统并不成立，与之前也推论矛盾的。欢迎学员讨论

UMLChina潘加宇

这个问题说难一点都不难，如果没有掌握要点就很难，一辈子都想不通的大有人在。

要点还是书里面讲的

(1)认清竞争的残酷，抛开一厢情愿的想法和“我爸是李刚”的幻觉.

(2)在杀光所有设计人员的场景下思考。

张三买A+B，李四买A，王五买B，哪个场景（或者哪些）是IBM认为最符合自己当前的竞争态势，这是有最佳答案（注意：不是标准答案）的，这个最佳答案决定了谁是合适的目标客户（张三李四王五）以及需要卖的系统（A、B、AB、AAABBB...）。

另外要说的是，“子系统”不卖。目标客户加插件不是买“子系统”（这是设计人员没杀干净污染的），可能是为原系统增加功能（只不过碰巧这个功能以通用插件的方式实现，实际上如果专门给他贴心定制他更爽），可能是买了一个“系统”。同样，这里面有微妙的区别，哪一种才是商家在当前竞争态势希望看到的最佳场景，需要好好去思考。

就像钟表由零件组装而成，如果经过定位思考，认为卖钟表是本商家目前最佳策略，那么零件可以替换、外包，如果认为卖零件的战场也要占领，那么就要投入很多精力来研发能赢得竞争的零件。各个领域（钟表、零件、零件的零件、零件的零件的零件……）都有残酷的竞争，不能轻飘飘地说“如果我们是卖**的呢？”我们的爸爸不是李刚，实际上市场留给我们的选择并不多，需要花心血去找到能让我们活下来的最佳答案。

补充：一厢情愿不只是往“零件”方向想过头，还包括一厢情愿往“钟表”方向想过头。假如经过思考，本团队的适合定位是做零件，那么要满足的是做闹钟的团队（目标客户）的零件要求，不需要关心做闹钟的团队的各种决定是否正确，闹钟能不能卖出去。

jeri 2020-4-3 19:32

感谢潘老师回答

潘老师主要从组织建模的角度分析加功能，还是做新系统是最佳的选择

问题原意想讨论在分析工作流时，增加一个系统，还是增加一个系统用例(功能),本来这不属于分析工作流的内容,只是为了分配系统的职责去推导应有的业务序列图

以书上的积分兑换系统为例

分析/开发人员拿到积分兑换需求(包括了积分规则，兑换规则等等)，其实此需求并没有需求工作流那样完整，产品人员有自己的套路，软件方法只是在局部流程改进

分析/开发人员推导业务序列图后, 可能按 顾客->兑换积分(网店系统的用例) ，也可能按 顾客->兑换积分（积分兑换系统），即把系统用例当作系统来做，多了积分兑换系统与网店系统的系统间接口

是否从做的角度，这两种区别不大。主要核心域复用即可，怎样简单怎样做，但是从业务序列图的责任分配上，决定了系统提供的接口。对原有的系统改动还是有区别

UMLChina潘加宇

“问题原意想讨论在分析工作流时，增加一个系统，还是增加一个系统用例(功能),本来这不属于分析工作流的内容,只是为了分配系统的职责去推导应有的业务序列图”---这句话概念乱掉了……这是业务建模工作流的工作，离分析工作流差两格呢。

“是否从做的角度，这两种区别不大。主要核心域复用即可，”--需求有不同，分析设计会有一些不同，但工作量相同的可能性比较大。

这些思考实际上就是把“不这样不行”和“这样行”分开。如果没有体会到把这两个分开的重要性，很难得到正确的思考结果。

jeri 2020-4-3 19:38

我上面表述是 不属于分析工作流的内容，这个没问题吧

UMLChina潘加宇

没问题。分析设计人员杀干净了就不会有人讨论这些问题了。很多开发人员是情不自禁把自己带进来，医生自己躺在病床上。

jeri 2020-4-3 19:43

嗯，其实是相当于 需求别人给定了，在实现时 要画分析序列图，分析序列图从系统用例来， 就把系统用例找出来

UMLChina潘加宇

“定了”那是假的。边界还在扯皮，那就是没定，只是说反正我写了个“需求文档”扔给你，就是定了。

jeri 2020-4-3 19:48

软件方法的使用是局部的使用， 并不是按SRS的方法交付

UMLChina潘加宇

这个行政的问题，是另外一回事了。

就像考试一样，没考100分考60分或作弊也没关系，只要不骗自己（可以骗人）说自己真的到了100分水平就行了。

需求没做好，分析设计人员从自己利益出发，可以替他做好，也可以不管不顾照着做，也可以拒绝做，也可以歪着做。

但是，没做好就是没做好，不要骗自己说“他已经做好了”就可以。

jeri 2020-4-3 19:58

分析设计人员从自己利益出发，可以替他做好----就是这个意思，把业务序列图，需求规约重新做

UMLChina潘加宇

那就是业务建模和需求工作流，不是说做的人的职务是分析设计人员，所以工作流就是分析设计。

然后，按照每个工作流的要点做，不存在什么“从程序员的角度”做需求之类的东西。

jeri 2020-4-3 20:02

分析的工作人员从卖的角度去建模，是有难度的

UMLChina潘加宇

有难度就克服，克服不了拉倒。还是上面这个：就像考试一样，没考100分考60分或作弊也没关系，只要不骗自己（可以骗人）说自己真的到了100分水平就行了。

很多时候，考60分已经压过很多人了。所以，这个问题想到这里已经比很多团队要强了，想不透到底怎样才是“不这样不行”，得不到100分答案，也无所谓。