笔记-软件方法-上册-业务建模和需求

这本书其实买了有两年了,还去参加了潘老师的公开课,限于能力,当时上课时领悟有限,最近因为Scanning打印系统做代码重构,要做代码框架设计,想借助于UML,以严谨一些,就翻出了这本书,重新看了一遍。

这本书其实并没涉及到具体软件架构设计要用的UML操作,诚如书名,侧重于需求分析。

以下是一些笔记,比较杂乱:

  • 利润=需求-设计:

这里的意思是,现在已经过了粗放经营的阶段了,企业需要搞清需求(产品好卖)和做好良好设计(降低成本),才能在激烈竞争中赢得优势。对于软件,我们更要注重代码重用带来的效率提高。

  • 基本共识上的沟通:

针对不少开发人员并不喜欢用UML,而是自造草图的情况,书里一针见血地指出是想通过”形式上的丑陋来遮掩内容上的丑陋”。大家对一些基本技能形成共识,可以“大大减少思考中的浪费”。

和涉众的交流内容应该聚焦涉众利益,而不是需求。

  • 愿景:

缺乏清晰、共享的愿景往往是项目失败的主要原因。(我们公司当前也缺乏愿景)

要避免无用的废话,例如PS可乐的目标客户是“卖给想喝可乐的人”。

系统的愿景应该是“买了这个系统,对组织有什么好处”。

由于编程语言的表达能力越来越强,针对某一段代码画流程图,变得没有必要。业务流程的描述,建议使用序列图。

  • 阿布思考法:
  1. 假设有足够的资源去解决问题,得到一个完美的方案。
  2. 用手上现有的资源去山寨这个完美方案。

许多伟大的创新,其实就是用廉价的替代方案来山寨过去富豪和高官的生活。

软件工程更接近于经济学,而非计算机科学。

需求是不考虑“复用”的,用同样的材料,变出更多可卖的功能,这是设计能力的体现。

大家可以尝试用“不这样行吗”这个标准去过滤我们的“需求”。

你可能感兴趣的:(笔记-软件方法-上册-业务建模和需求)