你的位置:首页 > ASP.net教程

[ASP.net教程]《软件方法》笔记


  计算机系统不只是简单地把纸上的东西往电脑里搬。

  客户的需求从来就没有变过,只是我们一开始就没有揣摩出来!

  利润 = 需求 - 设计,需求致力于解决"产品好卖“的问题,设计致力于解决”降低成本“的问题。代码和设计得到最大程度的复用,从而缩短开发周期,降低开发成本。

  从需求直接映射设计,会导致功能分解,得到重复代码。如果从设计出发来定义需求,会得到一大堆假的需求。

  如果能学会通过业务建模去推导新系统的需求,而不是拍脑袋得出需求,假的”需求变更“会大大减少。

  有的开发人员的”十年工作经验“实际上是”一年工作经验用了十年“,一直在热热闹闹的民工层次徘徊,没有积累和成长。

  建模的目的是帮开发团队思考,它可以指引开发团队发现到底需要向涉众了解什么,但不是直接拿着模型和涉众交流。开发人员把建模的目的理解成和涉众交流,背后的思想是”懒“字,因为这样,就有了推卸责任的机会:不是我不想建模,就算我建模,客户也不想看啊。

  第二章

  愿景是改善组织的目标,不是做某事,不是问系统有什么功能,而是回到买了这个系统,对组织有什么好处。

  愿景是组织的老大针对系统的目标,那其他人的目标难道不重要吗?其他人的目标也是要关注的,我们把它叫着涉众利益。

  需求是不断变化的,新系统肯定在功能或性能上和旧系统有所不同,否则还做什么新系统?但是背后的涉众利益要稳定的多。比如银行领域中的涉众利益:储户--希望方便,担心利益受损;银行负责人--希望安全;节约运营成本。这些涉众利益,适用于古代的钱庄柜台,适用于取款机,也适用于网上银行。

  第三章

  “需求变化剧烈”只是一个假象,许多需求的变化是假的变化,真正的需求并没有变,只不过开发人员一开始捕获的需求是假的。如果能正确运用业务建模技能,大多数假的需求变化会消于无形。遗憾的是,不少开发团队在改进的时候给自己开错了药房,以为应该通过提升设计的弹性来应变。设计是应对真正需求变化的手段,假的需求变化应该通过改进业务建模来应对。

  如果东西拿到客户面前,客户说:”好呀,正是我想要的!“,过来半年,客户又说:”形式变了,这个东西要改一下。“这是需求变了。如果东西拿到客户面前,客户说:“这不是我想要的!"这时硬要说”需求变了“,脸皮有点厚了。

  业务建模步骤1:选定要改进的组织

  实际工作中,经常会出现这样的现象:该研究目标人群时,建模人员却害怕去研究,千方百计要退回来研究网站组织。例如,要思考微博需要添加什么功能,应该去观察艺人的生活和工作,但这个太麻烦了,还是观察自己公司内部的运营吧!这就相当于在黑暗的地方丢了钥匙,却到明亮的地方找,因为这里亮堂,好找。

  选定组织后,我们需要从两方面来研究它。从外部看,组织是一些价值的集合,用业务用例图来表示;从内部看,组织是一些系统的集合,我们可以用业务序列图来表示。

   业务建模步骤2:组织的业务用例

  业务执行者:在组织外和组织交互的人群或组织,业务执行者是一个组织或人群,不是系统。

  业务工人:组织内的人肉系统。

业务执行者和业务工人的区别是,一个在组织外面,一个在组织里面,一个是组织不可替换的,一个组织可以替换的零件。业务工人可以能被新的业务工人替换,但跟多的可能是被新业务实体(BUSINESS ENTITY)替换。业务实体就是组织中的非人系统,如银行的取款机、点钞机。业务工人和业务实体不在业务用例图中出现,因为他们不是组织的价值而是成本。

  在识别业务执行者时,不需要画业务工人和业务实体,在接下来画业务用例的实现--业务序列图的时候加上就可以。

探索需求的思路--我们画好现状的业务序列图,然后把待开发的系统作为一个新的业务实体空降到序列图中,寻找改进点,得到该业务实体的责任,就可以直接映射到待开发系统的用例。

寻找业务执行者时,可以这样思考:拿着摄像机对准组织的边界,谁上门找它办事?谁打电话给它?谁发邮件给它?它出门找谁办事?打电话给谁?发邮件给谁。。。。可能就会找到它的供应商、客户。。。如果研究的组织是一个部门,那么其他部门就有可能成为它的执行者。

  业务用ishi为业务执行者 服务,不是为业务工人服务,业务用例表达组织的本质价值。在讨论”有哪些用例“的时候,必须说清楚研究对象,否则讨论没有意义,同理,不说清楚执行者是谁,讨论用例也是没有意义的。

  组织内部之所以有业务流程,是因为要实现业务用例。组织里发生的一切都是为了给业务执行者提供价值。

识别业务用例有两条路线:一条是从业务执行者开始,思考业务执行者和组织打交道的目的,执行者对组织的期望和组织对执行者的承诺;另一条是通过观察组织的内部活动,一直问为什么,向外推到组织外部的某个业务执行者,但不要将内部活动作为业务用例。

  为什么要研究组织的用例呢?因为我们想要把系统的价值和组织的价值挂上钩,给组织一个购买系统了理由。也就是说,业务用例不是思考系统提供什么“功能”,而是思考组织购买了这个系统,对组织本来就有哪些“功能“会带来一点帮助。

  

  

 

 

                                        ----以上摘自《软件方法》