《软件方法业务建模和需求》内容摘要.docxVIP

《软件方法》是UML China首席专家潘加宇的力作，里面提了很多研发人员常见的知识误区，值得想要在需求分析、系统架构能力有突破的研发人员阅读。此文是本人在拜读此书后的一个知识要点总结，也可以作为大家阅读的参考。 （一）《软件方法》要阐述的核心命题是什么？ 《软件方法》主要关注软件研发的四个核心工作流：业务建模、需求、分析、设计，指出“不同工作流产生的工件（Artifact）之间的区别不在于形式，而在于内容，也就是思考的边界”。 组织要解决什么问题业务建模提升销售为了解决组织的问题，待开发系统应该提供什么功能和性能需求需求规约为了提供功能，系统内部应该有什么样的核心机制分析降低成本为了提供性能，系统的核心机制如何用选定技术实现设计UML元素可用于各工作流中，推荐用法如下： 工作流思考焦点可选UML元素推荐UML元素业务建模组织内系统之间用例图、类图、序列图、活动图用例图、类图、序列图需求系统边界用例图、序列图、状态机图、活动图、文本用例图、文本分析系统内核心域类图、序列图、状态机图、活动图、通信图、包图类图、序列图、状态机图（可选）设计系统内各域之间类图、序列图、状态机图、活动图、通信图、组件图、部署图、时间图、组合结构图、包图不画，代码即设计建模模型的组织方式应按照工作流组织，传统按视图来组织模型的方式容易混淆思考边界。 （二）什么是愿景？为什么要明确愿景？怎么明确愿景？ 什么是愿景：在老大看来，引进这个系统的目的是什么？ 为什么要明确愿景：缺乏清晰、共享的愿景往往是项目失败的主要原因。 怎么明确愿景： （1）寻找老大。要点和典型错误有： 要点：老大是买方典型错误：老大就是我们开发公司老总（或者研发总监、产品经理等）要点：系统改善哪个组织的流程？老大就是该组织的负责人。典型错误：老大是xx局信息中心主任李xx。要点：系统好坏的度量指标藏在他的大脑里吗？典型错误：老大是某位大领导（可能是集团董事长，也可能是省长，甚至是总理）做产品而不是项目时，老大就是产品所定位的具体组织和人群。（2）明确可度量的目标。要点有： - 愿景是改善组织的指标，不是做某事； - 不要把系统的功能当作愿景，而应回答这个系统对购买系统的组织有什么好处； - 采用恰当的愿景描述的粒度，不要把组织的目标当作系统的目标； - 必要的时候，需要揣摩“老大”的目标，并对目标排序。 （3）关注系统最重要涉众的利益，但不要盲从涉众的利益。 （三）业务建模的目的和步骤。 业务建模的目的：从组织的角度来定位系统应该提供的价值。缺乏系统的业务建模过程、拍脑袋需求是引起“需求容易变化”的根源之一。 核心概念： 业务执行者：在组织之外和组织交互的人群或组织。 业务工人：在组织里面，是组织可以替换的零件（可能被新的业务功能或业务实体替换）。 业务实体：在组织中的非人系统。 业务建模的步骤： （1）选定要改进的组织。 - 选定组织的范围要合适。 - 互联网产品要改进的组织，是该网站的目标人群。 （2）寻找业务执行者。拿着摄像机对准组织的边界。 （3）发现业务用例并建模。 - 业务用例是指业务执行者希望通过和组织交互达到的，而且组织能提供的价值。业务用例代表组织的本质价值，很难变化，改变的是业务用例的实现。从外部看，组织是一些价值的集合，我们可以用业务用例图表示。 - 强调业务用例思考的边界，寻找“执行者对组织的期望和组织对执行者的承诺”。 - 识别业务用例的两条路线：一条是从业务执行者开始，思考业务执行者和组织打交道的目的（主要路线）；另一条是通过观察组织的内部活动，一直问为什么，外推到组织外部的某个业务执行者（补漏路线）。 - 如果一时之间难以确定要改进的业务组织，难以思考组织的用例，可以先不画业务用例图，先画要重点改进的流程的业务序列图，再从中归纳出合适的待研究组织和业务用例。 （4）用业务序列图对业务流程现状进行建模。 - 应当避免的错误：把“现状”误解为“纯手工”，应把人和非人系统一致抽象；把“现状”误解为“规范”，规范不一定是真实的；或以待开发系统为中心拼凑流程。 - 使用业务序列图的要点：焦点是对象之间的责任和协作，消息应代表责任分配而不是数据流动；聚焦于系统之间的协作，建模抽象级别应一致；只画核心域相关的系统（核心域的判断依据：是否跟改进的流程无关）；把时间看作特殊的业务实体。 （5）改进业务序列图。 - 常见方法：物流变成信息流；改善信息流转；封装领域逻辑；阿布思考法（假设有充足的资源去解决问题，得到一个完美的方案；用手上现有