《软件方法》章节试读

《软件方法》的笔记-第241页 - 忽悠汇总表一

评潘氏《软件方法》
UMLGreatChina 创始人、首席专家张恂老师评 UMLChina 创始人、首席专家潘加宇老师的名作。
以下列举了我们在该书中发现的一些主要的不可思议的错误，涉及 Stakeholder，Actor，用例的粒度和层次，需求、设计、实现的区别与联系等等。这些内容其实并非多么高深的高科技，而是 UML、Use Case、UP 等现代软件工程方法和技术培训中常见的一些基础概念与基本常识。
清晰版请看：http://www.zhangxun.com/?panmethod/errlist
《软件方法》忽悠汇总表一

《软件方法》的笔记-业务建模之业务用例图 - 业务建模之业务用例图

3.1 软件是组织的零件
业务建立的目的是从组织的角度来定位系统应该提供的价值 （可以理解为组织建模）
在进行IT系统需求调研时，应该对原有的系统进行分析（人肉系统也是重要的系统）,
业务建模能够得到有价值的需求。
3.2业务建模的步骤1-1:选定要改进的组织
确定研究范围：愿景涉及的、需要改进的组织（一个公司、一个部门、一群人（如车友））。
研究范围的确定需要多次试验。
组织的绝大数流程和改进不相干->范围太大
很多要改进的地方未涉及->范围太小
思路：
1.企业应用：
* 经可能列出责任可能被替换的系统，责任可能是部分替换或者全部替换，系统包含人肉系统和电脑系统
* 根据系统目标确定研究对象，得到的结果其实就是老大所代表的组织
2.互联网网站如何选择业务组织
目标人群为研究的组织。
从外部看，组织是一些价值的集合（业务用例图表示），从内部看，组织是一些系统的集合。
系统用例图里面组织里的用例应该理解为为业务执行者提供的价值而不是功能。
3.3业务建模步骤1-2:组织的业务用例图
3.3.1 业务执行者
寻找业务执行者(Business Actor),定义：在组织之外和组织交互的人群或组织
3.3.2业务工人和业务实体
业务工人(Business Worker):组织内的人肉系统
业务实体(Business Entity):组织内的非人系统
责任转移的思想由助于识别待开发系统的需求。
开发一个新系统意味着开发一个新的业务实体，取代现有业务工人或业务实体的一些责任。

《软件方法》的笔记-第146页 - 需求之系统用例图

开始说到价值了。太棒了，不仅是在讲“软件工程”，还是一个“产品工程”。这样的内容，在本书随处可见。