软件方法(一)

前置问题: 利润 = 需求 - 设计。
  需求:从卖的视角、具体的实际问题来考虑,将产品当做项目来做一步一步来走。
  设计:从做的角度、抽象的问题模型来考虑,将项目当做产品来做尽力做出彩。
  综述:设计源于需求而又高于需求。
   
  需求规约(如何考虑):
  组织要解决什么问题 => 业务建模
  为了解决组织的问题,待开发的系统应该提供什么功能和性能 => 需求以上2部分考虑如何提升销售的问题

0-愿景:确定一个从系统角度出发的非功能描述的范围合理的具体的目标。
  关键点:系统角度、非功能性描述、范围切记太大、一定要具体的目标不要说宽泛的废话。
  愿景格式如下:
  系统:xxxx系统(从系统角度出发,别放大到整个组织)
  老大:xx部门总监(老大指会花钱买这个系统的人,或对购买起着关键作用的决定人)
  目标(度量指标):(勿拿组织目标当系统目标太宽泛)
  提高xxx人员的工作效率
  减少xxx人员的错误率
  提高xxx工作的准确性

 

1-组织建模(业务建模): 记住你开发的系统只是要替换掉组织中的人工成本,所以建模的对象是组织而不是系统。
  关键步骤:
  1.确定建模组织:(组织的选取需要站在主要利益方和渉利群众的角度考虑,勿草率选取公司这种大范围的组织。对于互联网项目,应该选取项目的目标人群做组织。)画一个圈,把大多数责任可能被(部分/全部)替换的系统(人肉系统/电脑系统...)包在里边。
   
  2.画出组织(业务)用例图和序列图:(从外部看,可以用业务用例图表示组织。从内部看,可以用业务序列图表示组织。)
  研究组织的目的:把系统的价值和组织的价值挂上钩,给组织一个购买系统的理由。
   
 1). 业务用例图:
  a.确定业务执行者:寻找组织的执行者(业务执行者),在组织之外和组织交互的人。(业务执行者是一个组织或人群,而非系统。)
  思考方式:摄像机对准组织边界,谁找组织办事、谁发邮件给组织...等等,谁就有可能是业务执行者。
  b.确定业务工人和业务实体:业务工人是位于组织内部(业务执行者在组织外部)的人肉系统,即组织内的工人,而业务实体就是组织内部的非人工的系统。
  业务工人和业务实体是组织的成本而非价值,所以其不在业务用例图中出现,而是放在“业务对象”的包里。识别业务执行者时不需要画业务工人和业务实体,在画业务序列图时候加上即可。
  c.业务用例和业务流程:把业务流程看作是业务用例的实现,将其组织在业务用例下面。组织里发生的一切都为了给业务执行者提供价值。
  识别业务用例:第一条路线,也是主要路线,方法是从业务执行者开始,思考业务执行和组织打交道的目的。思考的焦点是“执行者对组织的期望和组织对执行者的承诺”的平衡点。第二条路是通过观察组织的内部活动,一直问为什么,向外推到组织外部的某个业务执行者。
  主要执行者和次要执行者:执行者指向用例,这种执行者为主要执行者;用例指向执行者则为次要执行者。如:“出版社→推广书籍→外部译者”可以这样解读:为了给出版社提供推广书籍的服务,组织靠自己的力量不足以完成,需要找外部译者帮忙。
  注意:业务用例是组织为组织服务,在不同的场景中,两个组织的系统形成不同的交互。业务用例是组织的,而不是组织内某个系统的用例。
       

   2). 业务序列图:业务流程有三种描述方式:文本方式、业务活动图方式、业务序列图方式。文本方式生动感欠佳不推荐,业务活动图是主流方式,但推荐的是业务序列图。UML的交互概述图是采用活动图的形式将各个场景的序列图串起来,相当于结合了活动图和序列图的特点。

你可能感兴趣的:(软件方法(一))