系统分析与设计第四次作业

一.用例建模

  • a.阅读 Asg_RH 文档,绘制用例图。 按 Task1 要求,请使用工具 UMLet,截图格式务必是 png 并控制尺寸

系统分析与设计第四次作业_第1张图片

  • b.选择你熟悉的定旅馆在线服务系统(或移动 APP),如绘制用例图。并满足以下要求:
    • 对比 Asg_RH 用例图,请用色彩标注出创新用例或子用例
    • 尽可能识别外部系统,并用色彩标注新的外部系统和服务

选择的定宾馆在线服务系统为去哪儿网,绘制的用例图如下所示:

系统分析与设计第四次作业_第2张图片

  • c. 对比两个时代、不同地区产品的用例图,总结在项目早期,发现创新的思路与方法
    1. 各种事物变化很快,项目的设计要紧跟科技发展的潮流
    2. 要把握顾客的心理,适应顾客心理活动规律
  • d. 请使用 SCRUM 方法,在(任务b)用例图基础上,编制某定旅馆开发的需求 (backlog)
    1. 首先需要确定旅馆开发的Product Backlog(按优先顺序排列的一个产品需求列表),这个是由Product Owner 负责
    2. Scrum Team根据Product Backlog列表,做工作量的预估和安排
    3. 有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog
    4. Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成)
    5. 在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图)
    6. 做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员
    7. 当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消)
    8. 最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中

二.业务建模

  • a. 在(任务b)基础上,用活动图建模找酒店用例。简述利用流程图发现子用例的方法
      利用流程图发现子用例方法:沿着流程图的开始状态,选择流程图中任意一个的分支点到流程图的结束状态,就是一个子用例,比如下图中,从开始状态开始一直到Room Available这个分支点,选择yes,并且最终到达结束状态,这就是一个子用例


系统分析与设计第四次作业_第3张图片
  • b. 选择你身边的银行 ATM,用活动图描绘取款业务流程

系统分析与设计第四次作业_第4张图片

  • c. 查找淘宝退货业务官方文档,使用多泳道图,表达客户、淘宝网、淘宝商家服务系统、商家等用户和系统协同完成退货业务的过程。分析客户要完成退货业务,在淘宝网上需要实现哪些系统用例

系统分析与设计第四次作业_第5张图片

三.用例文本编写

  • 在大作业基础上,分析三种用例文本的优点和缺点
    • 优点:
      1. 简洁、直观,系统交互行为很清晰地表达出来。
      2. 规范、易理解。
      3. 需求与设计分离。因为用例文本是站在系统外的视角描述系统需求的,所以并没有介入到系统内部实现细节,这就让需求和设计工作分离开来,条理清晰
    • 缺点:
      1. 不能表达非功能需求。用例文本是描述用户功能需求的工具,对于可靠性、性能等非功能需求无能为力
      2. 对不懂UML的客户或程序员来说难以理解。对UML支持者来说,用例文本可能是规范的、清晰的、简单的、易理解的,但对并未掌握UML建模技术的人来说理解那些椭圆并非易事,再说还有一系列如同伪代码似的事件流
      3. 粗粒度。用例文本不涉及设计实现细节,只是一个功能划分,粒度非常粗,很多细节无从描述,需要用其他工具进行辅助说明

你可能感兴趣的:(系统分析与设计第四次作业)