歌者(37***50) 8:31:25 我们单位公文系统的组织，我定位是综合部文秘处，老大是该处处长。愿景是提升公文办理效率，方便员工尤其是领导办理公文。公司各级领导，员工，信息化部，各子公司领导员工信息化部是利益相关方，是涉众。以上差不多是愿景内容吧？涉众每个都要总结愿景写用例？ 潘加宇(3504847) 8:34:27 找出度量指标就可以 潘加宇(3504847) 8:36:27 另外，上面的问题把几个工作混在一起了，先复习一下，按课上或书里讲的做 歌者(37***50) 9:04:12 培训是n年前的事情喽。我现在正在看《软件方法》的书将已做完的系统重新分析。 歌者(37***50) 9:55:52
歌者(37***50) 9:56:31
公文系统的业务建模，感觉还是有不少问题。 歌者(37***50) 9:59:32 现在系统已做好。反推来看，需要明确愿景，愿景能塑造边界。明确组织，进一步塑造需求和系统的边界。之后具体的用例。用例多大多小？我看首先是要梳理出真正的核心的业务模型。其他的有了核心之后再围绕之。则我这个业务建模还是不够抽象。 歌者(37***50) 10:00:12 再看会书 歌者(37***50) 10:10:51 总体上，远景是在梳理需求，确定组织边界也是为了梳理需求。但考虑业务流程和业务模型，可能需要将这个组织"文秘处"放到公司整体的业务流程中去考虑。看它的价值在哪里。 歌者(37***50) 10:11:20 而不仅仅是单独考虑某个"执行者"对"文秘处"的需求。 歌者(37***50) 10:15:57 在整个公司来看，文秘处的职责是管理文档，或者说，信息流。但它隶属于综合部。它所管理的信息流主要还是比较正式的行政类信息。业务部门也可能自己建设自己的信息流系统，管理专业信息流动。行政类信息流，主要包含了审批、协作部分。以命令、协商为主。 歌者(37***50) 10:26:27 业务模型修改为：
歌者(37***50) 10:29:58
歌者(37***50) 10:29:59 再简化 歌者(37***50) 11:42:43 是我弄错了，业务建模应该不进行过度抽象吧。 歌者(37***50) 13:43:53 需求和之前业务建模等，不是设计。是拿给用户看的，用户想要的。自然要全面。之后设计的时候，再像人体重新组织成血液系统、神经系统那样抽象总结。我因为现有系统是有个抽象的核心业务模型，就以为业务建模应该抽象。 歌者(37***50) 13:50:06 《领域驱动设计》讲业务建模和系统建模的一致性。或者到分析阶段的时候，再做"抽象的业务建模" 歌者(37***50) 14:24:56 总体来看，梳理业务模型，我感觉也要有个具体到抽象、抽象再到具体，这样循环几遍的过程。本来组织中也是如此。有总体设计，再落实到人。 歌者(37***50) 14:28:15 我们做的系统是在旧系统之上的优化。一直在纠结是不是应该从有纸办公开始总结业务模型。潘总说的对，业务模型其实一直都那样，有没有系统一回事。所以还是按有旧系统之后来总结，之后抽象了，就和有纸办公一回事了。 潘加宇(3504847) 7:08:26 去观察和文秘处打交道的人群或组织，有哪些，然后设想问他们，你去文秘处干嘛，合适的回答"XXX"就是合适的用例。这个没有标准答案，需要去观察得到最佳答案。 歌者(37***50) 14:31:26 另外问题是，如果就按照已有系统来总结，是否组织就只是综合部文秘处？毕竟信息化还有承建和维护的职能... 潘加宇(3504847) 7:17:54 一时想不清楚，你可以先画愿景涉及的要改进的流程的业务序列图，弄清楚大概边界，在来定业务建模的范围 业务用例代表了改进的高度
