《软件方法》阅读笔记（一）
粗放经营的时代已经远去，为了在激烈的竞争中获得优势，软件开发组织需要从细节上提升技能，《软件方法》这本书把这种技能聚焦在两点上，“需求”和“设计”，软件开发中做需求是为了让产品更加好卖，软件开发中做设计的目的是为了降低开发、维护成本，但开发人员不能直接从需求映射到设计，也不能从设计映射到需求；
在软件行业里面，有一个公式：利润=需求-设计；需求和设计是两个不同的概念，如果需求和设计不分，利润就会缩水。从需求直接映射到设计，会导致功能分解，得到重复代码。如果从设计出发来定义需求，会得到一大堆假的“需求”， 需求是从卖的视角，设计是从做的视角，需求是具体的，而设计则是抽象的，需求是把产品当项目做，而设计是把项目当产品做，设计源于需求，高于需求；
要迈向“低成本制造好卖的产品”，我们要做好：1.业务建模2.需求（聚焦于待开发系统的边界，详细描述系统要卖出去必须具有的表现---功能和性能）3.分析（提炼系统内需要封装的核心领域机制）4.设计；我们一定要重视业务建模和分析，代码并不是一切，各工作流可以选用的UML元素以及推荐用法：
|
工作流 |
思考焦点 |
可选UML元素 |
推荐UML元素 |
|
业务建模 |
组织各系统之间 |
用例图、类图、序列图、活动图 |
用例图、类图、序列图 |
|
需求 |
系统边界 |
用例图、序列图、状态机图、文本 |
用例图、文本 |
|
分析 |
系统内核心域 |
类图、序列图、状态机图、活动图、通信图、包图 |
类图、序列图、状态机图（可选） |
|
设计 |
系统内各域之间 |
类图、序列图、状态机图、活动图、通信图、组件图、部署图、时间图、组合结构图、包图 |
不画，代码即设计 |
和涉众交流的内容应该聚焦于需求的素材-----涉众利益（涉众希望什么、担心什么），而不是需求，软件需求不是由涉众直接提供的，而是由需求工程师综合不同涉众的利益编造出来的。涉众没有资格、也没有责任提供需求；和涉众交流的形式应该采用视图，而不是模型；和涉众交流的内容应该聚焦涉众利益，而不是需求；
缺乏清晰、共享的愿景往往是项目失败的重要原因，1999年11月的《财富》杂志题为“20世纪企业家”的文章，评选出了最能代表20世纪企业家精神的企业家------Henry Ford，他的愿景是：让每个家庭都拥有一辆汽车！排名第二的是Bill Gates，他的愿景也非常相似：让每个桌面都有一台计算机！对于软件系统来说，愿景也是至关重要的；现在的许多系统，特别是互联网网站，服务的客户组织是一个人群，而不是一个具体的人，开发人员要学会从客户的角度看问题，而不是习惯于从自己的视角看问题，愿景是改善组织的指标，不是做某事；愿景是客户针对系统的目标，其他人的目标也是要关注的，我们把它叫做涉众利益。愿景实际上就是系统最重要涉众的利益；涉众指收到系统影响的各种人，涉众利益是团队可以积累的财富；
业务建模的目的是从组织的角度来定位系统应该提供的价值，需求为什么经常容易变更，根源之一是他们的来路不正，一开始的时候是拍脑袋得来的，没有把系统当做一个零件放在组织中来看，得到的系统当然和组织的其他零件格格不入，系统马上磨合后发现问题，自然需要更改，许多需求的变化是假的变化，真正的需求并没有变，只不过开发人员一开始捕获的需求是假的。如果能正确运用业务建模技能，大多数假的需求变化会消于无形；
业务建模步骤：1.选定要改进的组织
2.组织的业务用例图